CN101399958A - 获取用户管理信息的方法、系统和设备 - Google Patents

获取用户管理信息的方法、系统和设备 Download PDF

Info

Publication number
CN101399958A
CN101399958A CN200710162759.XA CN200710162759A CN101399958A CN 101399958 A CN101399958 A CN 101399958A CN 200710162759 A CN200710162759 A CN 200710162759A CN 101399958 A CN101399958 A CN 101399958A
Authority
CN
China
Prior art keywords
server
terminal
program
management information
customer management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200710162759.XA
Other languages
English (en)
Other versions
CN101399958B (zh
Inventor
杨健
陈国乔
王雷
董挺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN200710162759.XA priority Critical patent/CN101399958B/zh
Priority to KR1020107008233A priority patent/KR101159556B1/ko
Priority to JP2010526139A priority patent/JP5242690B2/ja
Priority to PCT/CN2008/072554 priority patent/WO2009046671A1/zh
Priority to EP08837169A priority patent/EP2190231A4/en
Publication of CN101399958A publication Critical patent/CN101399958A/zh
Priority to US12/749,104 priority patent/US20100186044A1/en
Application granted granted Critical
Publication of CN101399958B publication Critical patent/CN101399958B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/509—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to media content delivery, e.g. audio, video or TV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Graphics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明提供一种手机电视业务中获取用户管理信息的方法，包括如下步骤：服务器接收终端发送的用户管理信息；所述服务器保存获取的所述终端的用户管理信息。本发明还提供一种手机电视业务中获取用户管理信息的系统和设备。通过使用本发明，通过终端与服务器间的消息交互，实现了对用户管理信息的统计、交互更新以及收视率的统计等信息的互通的目的。

Description

获取用户管理信息的方法、系统和设备
技术领域
本发明涉及移动通信领域，特别是一种手机电视业务中获取用户管理信息的方法、系统和设备。
背景技术
SMIL(Synchronized Multimedia Integration Language，同步多媒体集成语言)是由3W(World Wide Web Consortium，万维网联盟)组织规定的多媒体操纵语言。SMIL与我们网页上用的HTML(Hypertext Markup Language，超文本标识语言)的语法格式非常相似。后者主要针对普通的网络媒体文件进行操纵(文字、图片、声音、动画、视频的机械堆砌)，而前者则操纵多媒体片断(对多媒体片断的有机的、智能的组合)。
SMIL语言是一套已经规定好的而且非常简单的标记。它用来规定多媒体片断(包括的范围有：声音文件、视频文件、动画、图片、文字等)在什么时候、在什么地方、以什么样的方式播放。SMIL的优点有如下这些：
避免使用统一的包容文件格式。可以用SMIL来组织多媒体文件，那么可以在不对源文件进行任何修改的情况下获得想要的效果；
可用用SMIL同时播放不同服务器上的多媒体片段；
可以很容易的对播放的多媒体文件的播放时间进行控制；
对整个演示进行布局；
可以简易地实现多语言选择和多带宽选择支持。
所谓“手机电视业务”，就是利用具有操作系统和视频功能的智能手机观看电视的业务。显然，由于手机用户普及率高且手机拥有携带方便等特性，手机电视业务显示出了比普通电视更广泛的影响力。
在韩国、欧美以及日本，手机电视正在大规模的推广及应用。韩国的SK集团斥巨资投入视频和音频节目的DMB(Digital Multimedia Broadcasting，数字媒体广播)业务，向用户提供个性化的电视节目；在美国，FCC(FederalCommunications Commission，美国通信委员会)开放了1670MHz～1675MHz的5MHz频带，以提供面向移动终端的多媒体服务，并且传送影像的画面质量也已经有了很大幅度的提升；而在日本，在各方力量的努力下，数字电视手机技术有了突破性进展，已有很多运营商提供了这种业务的支持。
目前，手机电视业务的实现方式主要有三种。第一种是利用移动网络实现的方式，如中国移动推出的手机电视业务。第二是利用卫星广播的方式，韩国的运营商计划采用这种方式。第三种是在手机中安装数字电视的接收模块，直接接收数字电视信号。利用移动网络实现的方式有目前中国移动推出的手机电视业务，主要是依靠现有的GPRS(General Packet Radio Service，通用分组无线服务)移动网络实现的。这种手机电视业务实际上是利用流媒体技术，把手机电视作为一种数据业务推出来。不过，客户需要在安装有操作系统的手机终端(一般是PDA(Personel Digital Assisitan，个人数字助理)手机等高档产品)上再下载安装相应的播放软件，而相应的电视节目内容则由中国移动与内容提供商SP(Service Provider，服务供应商)合作提供。
利用卫星网络实现的方式即利用手机来接受卫星播发的电视节目信号是一个非常新颖的想法。目前只有韩国在力推这种手机电视广播方式DMB。据SK称，这种DMB接收机能提供高质量的图像，使用该接收机模块能使用户能够同时接收地面无线电视广播和卫星电视广播的信号。手机中安装数字电视接收模块的方式
目前最被看好的手机电视技术方式是通过整合数字电视和移动电话的方式。这种方式需要在手机终端上安装微波数字电视接收模块，可以不通过移动通信网络的链路，直接获得数字电视信号。目前，手机数字电视标准只有欧洲的DVB-H(Digital Video Broadcasting Handheld，广播的数字化的录像手提式)和日本的单频段转播标准。
阻碍手机电视发展的因素主要有以下几个方面：
1.管制问题：目前手机电视业务面临的最大问题恐怕主要是管制方面的问题。这是因为，各国在广播和通信领域一般都有不同的政策，并由不同的政府部门来管理，对相应领域的企业也有着严格的限制。
2.技术成熟性问题：手机电视业务还需要解决一系列的技术问题，比如网络传输速率、电池寿命短、终端小型化等问题，同时还要制订相关技术标准，与内容服务商协调发展。
3.资费问题：当前具备手机电视功能的手机种类还很少，并且价格相对较高。用户在使用一个业务前首先考虑的问题会是价格与资费，将来运营商采用什么样的收费方式既让用户能接受，又能赚钱，确实是一个难题。
尽管手机电视业务的发展还面临许多困难，但是从长远来看，随着移动通信网络带宽的加大，业务资费水平的下降，具有视频功能手机的日益普及，手机电视业务将会获得快速发展，并形成相当大的市场规模。
现有的技术方案如下：
在手机电视业务中，服务器获得终端状态以及进行内容统计等管理手段目前没有方法实现。在非手机电视业务领域，对于媒体的播放等内容下发可以通过广播方式，因此也就有了当终端接收到广播消息的时候对服务器进行反馈的方式。
在非手机电视业务领域，由于现有的媒体播放实现技术多是由地面数字广播电视技术发展而来的，因此在音视频的下行传输方面相对比较完善。目前已有多个国家和地区开始进行实验或试商用，但由于传统的广播电视网络通常都没有上行链路，因此基于数字广播网的实现技术在实现上行传输时一般都考虑依靠移动通信网络的协助来完成。这样才能够提供手机电视业务所需的用户业务认证、用户的管理以及互动应用等能力。但是通过怎样的手段来达到认证、管理及互动应用则没有相应的方法。
现有技术的缺点在于，通过广播的方式可以使终端获取服务器发送来的节目内容，但是有很多的终端信息，采用广播的方式是无法进行管理的。比如收视率的统计以及针对正在观看电视的互动文档的更新的过程。另外，当服务指南SG更新后，无法及时将更新内容发送到合适的用户；且服务器无法及时的获知用户的状态(在线online状态，观看频道状态等)。
发明内容
本发明的实施例提供一种手机电视业务中获取用户管理信息的方法、系统和设备，用于实现对终端用户管理信息的准确统计。
为达到上述目的，本发明的实施例提供一种手机电视业务中获取用户管理信息的方法，包括以下步骤：
终端向服务器发送用户管理信息；
服务器保存获取的所述终端的用户管理信息。
本发明的实施例还提供一种手机电视业务中获取用户管理信息的系统，包括：
服务器，用于接收终端发送的用户管理信息，并保存所获取的所述终端的用户管理信息；
终端，用于向所述服务器发送用户管理信息。
本发明的实施例还提供一种手机电视业务中的服务器，用于获取用户管理信息，包括：
接收模块，用于接收终端发送的用户管理信息；
统计模块，用于保存所述接收模块获取的所述终端的用户管理信息。
与现有技术相比，本发明的实施例具有以下优点：
通过终端与服务器间的消息交互，实现了对终端用户管理信息的统计、交互更新以及收视率的统计等信息的互通的目的。
附图说明
图1为本发明的实施例一中获取用户管理信息的方法的流程图；
图2为本发明的实施例二中获取用户管理信息的方法的流程图；
图3为本发明的实施例三中获取用户管理信息的方法的流程图；
图4为本发明的实施例四中获取用户管理信息的方法的流程图；
图5为本发明的实施例五中获取用户管理信息的系统的结构图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述：
本发明的实施例一中，一种获取用户管理信息的方法如图1所示，包括以下步骤：
步骤s101、终端向服务器发送用户管理信息。
步骤s102、服务器接收终端发送的用户管理信息。
步骤s103、服务器保存所获取的终端的用户管理信息。
具体的，本发明的实施例中，通过终端与服务器间的消息交互，达到交互更新以及收视率的统计和其它相应信息的互通的目的。终端与服务器间的交互消息可以进行规定，满足一定的格式并携带少数必要的信息即可，这样的消息有利于服务器处理，也有助于减小服务器负担。服务器对终端信息的记录以及统计的结果可以按照一定的策略完成，并且服务器处理终端上报的互动信息也根据策略来完成。
本发明的主要实施方法在于：当用户接入(Login)某频道后，终端要将Service ID、User ID、等信息保存在本地，当接收节目达到一定时间后，终端要将这些信息发送到服务器。当终端退出节目后，还要将Service ID、ChannelID、User ID等信息发送到服务器，这样才完成一次退出(Logout)。Login与Logout的作用主要在于为服务器提供了终端的用户管理信息，而这样的信息为服务器统计收视率、界定终端的观看行为提供依据。
本发明的实施例二提供了一种将终端接入节目频道(Login)和终端退出播放节目(Logout)时服务器获取用户管理信息的方法。对于服务器而言，终端在订阅了频道后不会有任何消息发送到服务器。终端的状态、用户的情况、订阅频道的更新情况等对服务器来说都是不知道的，因此需要提供一种方法来解决这样的问题。本方案提供的方法可以为服务器进一步掌握终端接收节目的情况和交互提供手段。
请参照流程图图2，该方案的实施思想主要在于，当终端用户收看某一时刻的节目时，终端会接入(Login)到播放该节目的频道。接入后的用户管理信息，包括Service ID、User ID、等用户管理信息会被终端发送到服务器。用户管理信息的形式可以通过多种方式发送到服务器上。服务器会保存用户管理信息并对接收到的消息做出响应。当终端退出(Logout)接收节目后，还会与服务器进行一次交互：终端将退出时的用户管理信息，包括，Service ID、Channel ID、User ID等信息发给服务器。服务器根据退出的用户管理信息对保存的终端接入节目的情况进行一次综合记录。
本实施例具体流程如图2所示，步骤如下：
步骤s201，终端启动，并向服务器发送LogInInfo消息。
LogInInfo消息的内容可以如下所示：
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 XMLSPY v5 rel.4U(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＝＂LogInInfo＂/>
<User_ID User_ID_Type＝＂abc＂/>
<Service_ID Service_ID_Type＝＂01＂/>
<Program_ID Program_ID_Type＝＂11＂/>
本实施例中，LogInInfo消息以XML(Extensible Markup Language，可扩展标记语言)的形式作为消息体加在HTTP(Hyper Text Transfer Protocol，超文本传输协议)POST头的后面，带到服务器上。消息头和消息体间用回车<CR>间隔开，回车上面的为消息头，下面的为消息体。消息头中描述了要请求的主机和端口，连接方式为close，表示不必持续连接，HTTP1.1支持非持续连接。
LogInInfo消息包括了Service ID(Identification，标识符)、User ID(例如：IMSI(International Mobile Subscriber Identification Number，客户识别码)信息)、以及其它接入用户管理信息。终端的LogInInfo消息具有某种格式，例如如图2所示。消息的发送是通过交互信道完成的。保存LogInInfo消息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服务器。本实施例中LogInInfo以html的形式发送到服务器上。
发送LogInInfo的方法可以是通过多种方法，例如HTTP POST方法。这里只是举例说明，如有其它方式可以替代，其原理与思想是一致的。
Client启动时会将Login的消息LogInInfo上报给Server，同时服务器将该用户状态制成online。Client到服务器上取SG以及其他相关数据。而当Server上的这些相关数据有更新的时候，此时服务器可以向已经在线的用户进行数据更新的通知Push消息发送给online的Client，则Client可以及时感知服务器上的数据变化，及时取回数据。
步骤s202，获取SG。
手机电视终端接收频道节目的前提是该Client已经注册在Server上，并且已经激活，可以接入频道接收节目。
步骤s203，未定购频道的终端根据获取的SG重新建立频道定购。
确定的定购关系描述的是用户对SG中频道订阅的情况。它可以是以表的方式保存在Server端。以Server来同步Client。
A 定购的方式可以是外部的：例如通过上网或拨打电话的方式来完成。定购的结果会记录到服务器上；
B 也可以是内部的：通过Client在SG上进行定购。每当Client定购或退定一个频道，Server上的定购关系表都会进行一次修改，并随后同步给Client。
C：定购关系可以是Server向Client同步，服务器会在Client启动时将定购关系与online状态的用户进行同步，也可根据服务器策略定期同步；定购关系也可以是终端来维护，向服务器进行同步，当用户进行定购以后，本地的定购关系会通过HTTP的POST方式发到服务器上与服务器同步。
用户接入频道后可以接收SG(Service Guide，服务指南)。SG中有频道内容的预告。通过SG Client可以获得相关的频道列表，并根据该频道列表提供的频道接收节目内容。
如果采用广播接收的方式，终端根据之前收到的手机频道导航SG，选择希望收看的频道。通过SG上显示的频道标识，用户终端在选择后，终端会开始节目的接收。
步骤s204，服务器端向终端发送节目内容。
服务器可以采用广播的方式将内容发送出去，也可以用流媒体的方式发送内容。
如果终端在接收到节目内容一段时间后(可以设定为1分钟)没有退出，那么该信息就将被发送到服务器。服务器可以记录终端接入时间。
终端侧接入到频道后的处理首先要在本地记录当前的状态信息，规定的一段时间可以是网络设定的，也可以是内容提供商设定的。该时间被终端用来判定是否要向服务器发送统计信息。如果终端接入频道的时间超过了该设定时间，则可以认为用户是在观看节目；否则，如果在这段时间内终端退出了该频道，则认为用户没有收看该频道节目。
步骤s205，服务器对终端进行鉴权。
鉴权消息的内容可以如下所示：
HTTP/1.1401 Unauthorized
Server:Microsoft-IIS/5.1
WWW-Authenticate:Digest
realm＝＂testrealm@host.com＂，
qop＝＂auth，auth-int＂，
nonce＝＂dcd98b7102dd2f0e8b11d0f600bfb0c093＂，
opaque＝＂5ccc069c403ebaf9f0171e9517f40e41＂
<CR>
服务器收到终端发来的POST消息，对终端要进行一次认证，服务器会发质询给终端。所谓“发出质询”，就是给客户端发送一个HTTP响应，其状态码为401(Unauthorized)，并且包含消息头WWW-Authenticate，客户端看到这个响应就知道这个URI(Uniform Resource Identifier，通用资源标志符)需要认证。
domain：一个URI列表，指示要保护的域。可能是一个列表，提示用户这些URI采用一样的认证，如果为空或忽略则为整个服务器。
nonce：随机字符串，每次401都不一样。跟算法有关。算法类似Base64加密：time-stamp H(time-stamp＂:＂ETag＂:＂private-key)。time-stamp为服务器时钟，ETag为请求的Etag头。
opaque：服务器产生的由客户发送请求时原样返回。最好是Base64串或十六进制字符串。realm-value是一个两端加引号的大小写相关的字符串，表示要求认证的“领域(realm)”。领域是由服务器自己决定的，不同的服务器可以设置自己的领域，同一个服务器也可以有多个领域。质询中包含领域信息是为了让客户端知道哪个范围的用户名是合法的。服务器对终端进行鉴权的消息可以没有消息体。
服务器为了获得终端接入用户的身份，需要对终端刚接入时或切换节目或频道时进行认证。这个认证与用户注册时认证目的不同，这个对接入用户的认证可以保证观看节目的用户为接入用户，可以保证收视率统计的客观性。认证的方式有多种，例如HTTP的摘要认证方式。
服务器接收到用户发来的LogInInfo，在将该消息中的数据写入数据库前，为了确定接入节目的用户的身份，及LogInInfo的合理性，必须对用户进行一次认证。因为用户在发送LogInInfo的时候不知道是否认证，因此服务在收到LogInInfo时会发送一个HTTP的401消息，该消息包括了一个挑战(challenge)，challenge需要用户名及密码等相关认证信息以加密的方式发到服务器。
步骤s206，终端向服务器发送一个对认证的响应。
响应消息的内容可以如下所示：
Authorization：Digest username＝＂Mufasa＂，
realm＝＂testrealm@host.com＂，
nonce＝＂dcd98b7102dd2f0e8b11d0f600bfb0c093＂，
uri＝＂/xxx/index.html＂，
qop＝auth，
nc＝00000001，
cnonce＝＂0a4f13b＂，
response＝＂6629fae49393a05397450978507c4efl＂，
opaque＝＂5ccc069c403ebaf9f0171e9517f40e41＂
终端在收到Challenge消息后会将自己的用户名及密码和Challenge一起加密传给服务器。这样的好处是可以不用明文发送密码。
当认证成功后服务器会保持之前终端的接收；如果终端认证未通过，用户也可以继续观看节目，但对于服务器统计LogInInfo是无效的。
步骤s201-s206为标准的HTTP摘要认证的方式，其中的各字段可参考RFC2617。摘要认证的方法在这里只是举例说明。
步骤s207，服务器发送200OK消息到终端。
终端的用户名及密码通过服务器的认证，服务器发送200Ok到终端；本实施例中是以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
LogInInfo
用户退出当前观看节目的时间是任意的，可以在节目结束后，也可以在播放途中退出。当用户退出后将触发终端发送状态消息到服务器。
步骤s210，终端发送一条LogOutInfo消息到服务器。
LogOutInfo消息的内容可以如下所示：
POST/HTTP/1.1
Date:Sat，20Jul200720:55:22GMT
Aceept-Ranges:bytes
Accept-Language:zh-cn
Content-Length：1205
Content-Type:text/xml
Host:host:www.samp.com:8080
Connection:close
<CR>
<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>
<！--edited with XMLSPY v5 rel.4U(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 MessageType_Type＝＂LogOutInfo＂/>
 <User_ID User_ID_Type＝＂abc＂/>
 <Service_ID Service_ID_Type＝＂01＂/>
 <Program_ID Program_ID_Type＝＂11＂/>
本实施例用HTTP的POST方法将LogOutInfo的XML数据信息发到服务器上，POST消息中的含义与第4步相同。LogOutInfo的XML形式数据为消息体。
该消息包括了Service ID、User ID，服务器记录终端退出时间End Time。终端的LogOutInfo消息具有某种格式，例如如图3所示。消息的发送是通过交互信道完成的。保存LogOutInfo消息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服务器。
LogOutInfo消息可以用HTTP方式将消息带到服务器由服务器来完成处理并加入数据库中，也可以用SMS(Short Message Service，短消息业务)或其它方式。本例中通过HTTP POST方法将消息带到服务器的方式只是举例说明，也可以用其它的承载手段代替，但所涉及的原理和思想是一致的。
步骤s211，当服务器正确接收的LogOutInfo消息后返回200OK消息给终端。
返回应答可以通过交互信道，也可以通过其它的方式。本例中用200OK代表发送内容成功到达。在不同的网络环境中也可以采用其它的应答方式，所涉及的思想和原理都是一样的。
步骤s212，服务器在终端退出节目后对终端的状态信息进行保存。
服务器将终端上报的LogInInfo和LogOutInfo状态信息加入到本地数据库中或保存在其它的服务器中。服务器从LogInInfo和LogOutInfo消息中获得需要的数据。根据这些数据，服务器可以对终端的订阅以及观看节目的情况有基本的了解。服务器数据库中保存的状态信息可以是与表4统计表相同或类似。
手机终端在收看某频道节目内容的时候，比较可行的方式是通过SG，呈现出频道列表，终端可以选择一个频道的节目进入观看。当终端通过SG提供的频道列表接入频道观看时，终端会记录下当前接入的用户管理信息，包括接入的用户(User ID)、业务(Service ID)、节目(Program ID)等。当终端接入该频道的一个节目一定时间后(例如一分钟)，则可以认为用户是在观看该节目，此时终端需要将用户管理信息发送到服务器。当终端退出该频道或退出观看节目的时候，终端会记录下当前退出的用户管理信息，包括接入的用户(User ID)、业务(Service ID)、节目(Program ID)等。该服务器可以是交互服务器也可以是专门用来记录终端信息的服务器。
例如LogInInfo和LogOutInfo消息可以是如下表1的数据结构形式：
 
消息 必要性 方向
LogInInfo 强制 Client→Server
LogOutInfo 强制 Client→Server
表1 本发明涉及到的终端与服务器间的消息类型
LogInInfo消息和LogOutInfo消息都是强制必须的消息。方向都是从终端到服务器。
LogInInfo和LogOutInfo消息的数据结构组成如下表2和3所示：
 
InformationElement      Req Type Description
Message-Type Mandatory String 消息类型标识“LogInInfo”
User ID Mandatory String 终端用户ID
Service ID Mandatory String 业务的ID(i.e ChannelID)
Program ID Mandatory String 观看的节目ID
Online state Mandatory String 在线状态
 
IMSI Mandatory String 客户识别码(IMSI)
Channel stat Mandatory String 频道标识，用来标帜该频道的统计情况              
表2 LogInInfo消息组成
 
InformationElement      Req Type Description
Message-Type Mandatory String 消息类型标识“LogInInfo”
User ID Mandatory String 终端用户ID
Service ID Mandatory String 业务的ID(i.e ChannelID)
Program ID Mandatory String 观看的节目ID
Online state Mandatory String 在线状态
IMSI Mandatory String 客户识别码(IMSI)
Channel stat Mandatory String 频道标识，用来标帜该频道的统计情况                  
表3 LogOutInfo消息组成
用schema表示该数据结构如下：
<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>
<！--edited with XMLSPY v5 rel.4U(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＂/>
       <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＂/>
                                    <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:attributen   ame＝＂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 011 10：50 11：30
02462 01 011 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 generate 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的用户都在观看ServiceID为01的频道，所看节目内容相同，他们观看的节目Program ID为011。他们的观看时间分别从10:50和10:20开始。User ID为55208的用户和UserID为49653的用户都在观看Service ID为02的频道，说观看的节目也相同，都是Program ID为021，但是前者12:05接入观看，而后者从12:15开始观看，节目结束后他们都停止了观看，因此EndTime都是12:25。
服务器上保存记录形式可以多样，本方案只是举例说明，可以用其它的数据结构组织这些统计数据，但所涉及的思想与方法都是相同的。
表4中一个频道对应一个Service。同一时间相同频道只有一个节目。Service ID、Program ID由提供节目的内容提供商规定。也可以是一个频道在一段时间内只提供一个节目给用户观看。User ID、Service ID、Program ID、EndTime、StartTime这些属性只是举例说明终端观看节目的状态信息，如果需要可以进行修改与扩展。
本实施例中的服务器可以是互动服务器，也可以是专门用来保存统计信息的服务器。由于本实施例中的消息相对内容少，数据易统计，因此对服务器的负担小。此外，对于本例中的服务器，如果能够支持一定量的用户数量，增加这样的统计后并不会对支持的用户数有太多的改变。
本实施例中所涉及的发送用户管理信息的消息LogInInfo、LogOutInfo只是举例说明，其他类似携带状态信息的消息方法也可以完成状态信息的发送，所涉及的原理与思想都是一致的。
本发明的实施例三提供了一种将终端接入节目频道(Login)和终端退出播放节目(Logout)时将用户管理信息发送到服务器，由服务器根据用户管理信息对节目或用户偏好做统计的方法。该方法可以为服务器进一步掌握终端接收节目和频道的情况提供手段。
请参照流程图图3，该方案的实施思想主要在于，当终端用户收看某一时段的节目时，终端会接入(Login)到播放该节目的频道。接入后的用户管理信息，包括Service ID、Program ID、User ID、等信息会被终端发送到服务器。用户管理信息可以以消息的方式发送到服务器上。服务器会根据本地策略判断是否要接收到的终端用户管理信息并进行保存，做出相应的回答。当终端退出(Logout)接收节目后，还会与服务器进行一次交互：终端将退出时的用户管理信息，包括，Service ID、Program ID、User ID等信息发给服务器。
服务器根据退出的用户管理信息对保存的终端接入节目的情况进行统计。服务器可以根据记录的终端Login和Logout的时间算出用户接入该节目的总时长，服务器还会根据User ID和Service ID、Program ID统计出关注度最高的频道，以及关注度最高的节目内容。根据这样的统计，服务器可以对那些关注度高的频道和节目增加更多的网络资源，保证这些节目在用户观看时的观看质量；内容提供商也可以根据这样的统计对提供的频道和节目做一定的调整，增加关注度高的节目的播放，根据用户的兴趣开发节目。
本实施例具体流程如图3所示，步骤如下：
步骤s301，终端启动，并向服务器发送LogInInfo消息。
LogInInfo消息的内容可以如下所示：
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 XMLSPY v5 rel.4U(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＝＂LogInInfo＂/>
     <User_ID User_ID_Type＝＂abc＂/>
     <Service_ID Service_ID_Type＝＂01＂/>
     <Program_ID Program_ID_Type＝＂11＂/>
本实施例中，LogInInfo消息以XML(Extensible Markup Language，可扩展标记语言)的形式作为消息体加在HTTP(Hyper Text Transfer Protocol，超文本传输协议)POST头的后面，带到服务器上。消息头和消息体间用回车<CR>间隔开，回车上面的为消息头，下面的为消息体。消息头中描述了要请求的主机和端口，连接方式为close，表示不必持续连接，HTTP1.1支持非持续连接。
LogInInfo消息包括了Service ID、User ID(例如：IMSI信息)、以及其它接入状态信息。终端的LogInInfo消息具有某种格式，例如如图2所示。消息的发送是通过交互信道完成的。保存LogInInfo消息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服务器。本实施例中LogInInfo以html的形式发送到服务器上。
发送LogInInfo的方法可以是通过多种方法，例如HTTP POST方法。这里只是举例说明，如有其它方式可以替代，其原理与思想是一致的。
Client启动时会将Login的消息LogInInfo上报给Server，同时服务器将该用户状态制成online。Client到服务器上取SG以及其他相关数据。而当Server上的这些相关数据有更新的时候，此时服务器可以向已经在线的用户进行数据更新的通知Push消息发送给online的Client，则Client可以及时感知服务器上的数据变化，及时取回数据。
步骤s302，获取SG。
手机电视终端接收频道节目的前提是该Client已经注册在Server上，并且已经激活，可以接入频道接收节目。
步骤s203，未定购频道的终端根据获取的SG重新建立频道定购。
确定的定购关系描述的是用户对SG中频道订阅的情况。它可以是以表的方式保存在Server端。以Server来同步Client。
A 定购的方式可以是外部的：例如通过上网或拨打电话的方式来完成。定购的结果会记录到服务器上；
B 也可以是内部的：通过Client在SG上进行定购。每当Client定购或退定一个频道，Server上的定购关系表都会进行一次修改，并随后同步给Client。
C 定购关系可以是Server向Client同步，服务器会在Client启动时将定购关系与online状态的用户进行同步，也可根据服务器策略定期同步；定购关系也可以是终端来维护，向服务器进行同步，当用户进行定购以后，本地的定购关系会通过HTTP的POST方式发到服务器上与服务器同步。
用户接入频道后可以接收SG(Service Guide，服务指南)。SG中有频道内容的预告。通过SG Client可以获得相关的频道列表，并根据该频道列表提供的频道接收节目内容。
如果采用广播接收的方式，终端根据之前收到的手机频道导航SG，选择希望收看的频道。通过SG上显示的频道标识，用户终端在选择后，终端会开始节目的接收。
步骤s304，服务器端向终端发送节目内容。
服务器可以采用广播的方式将内容发送出去，也可以用流媒体的方式发送内容。
如果终端在接收到节目内容一段时间后(可以设定为1分钟)没有退出，那么该信息就将被发送到服务器。服务器可以记录终端接入时间。
终端侧接入到频道后的处理首先要在本地记录当前的用户管理信息，规定的一段时间可以是网络设定的，也可以是内容提供商设定的。该时间被终端用来判定是否要向服务器发送统计信息。如果终端接入频道的时间超过了该设定时间，则可以认为用户是在观看节目；否则，如果在这段时间内终端退出了该频道，则认为用户没有收看该频道节目。
步骤s305，服务器对终端进行鉴权。
鉴权消息的内容可以如下所示：
HTTP/1.1401 Unauthorized
Server：Microsoft-IIS/5.1
WWW-Authenticate：Digest
realm＝＂testrealm@host.com＂，
qop＝＂auth，auth-int＂，
nonce＝＂dcd98b7102dd2f0e8b11d0f600bfb0c093＂，
opaque＝＂5ccc069c403ebaf9f0171e9517f40e41＂
<CR>
服务器收到终端发来的POST消息，对终端要进行一次认证，服务器会发质询给终端。所谓“发出质询”，就是给客户端发送一个HTTP响应，其状态码为401(Unauthorized)，并且包含消息头WWW-Authenticate，客户端看到这个响应就知道这个URI(Uniform Resource Identifier，通用资源标志符)需要认证。
domain：一个URI列表，指示要保护的域。可能是一个列表，提示用户这些URI采用一样的认证，如果为空或忽略则为整个服务器。
nonce：随机字符串，每次401都不一样。跟算法有关。算法类似Base64加密：time-stamp H(time-stamp＂:＂ETag＂:＂private-key)。time-stamp为服务器时钟，ETag为请求的Etag头。
opaque：服务器产生的由客户发送请求时原样返回。最好是Base64串或十六进制字符串。realm-value是一个两端加引号的大小写相关的字符串，表示要求认证的“领域(realm)”。领域是由服务器自己决定的，不同的服务器可以设置自己的领域，同一个服务器也可以有多个领域。质询中包含领域信息是为了让客户端知道哪个范围的用户名是合法的。服务器对终端进行鉴权的消息可以没有消息体。
服务器为了获得终端接入用户的身份，需要对终端进行一次认证。这个认证与用户注册时认证目的不同，这个对接入用户的认证可以保证观看节目的用户为接入用户，可以保证收视率统计的客观性。认证的方式有多种，例如HTTP的摘要认证方式。
服务器接收到用户发来的LogInInfo，在将该消息中的数据写入数据库前，为了确定接入节目的用户的身份，及LogInInfo的合理性，必须对用户进行一次认证。因为用户在发送LogInInfo的时候不知道是否认证，因此服务在收到LogInInfo时会发送一个HTTP的401消息，该消息包括了一个挑战(challenge)，challenge需要用户名及密码等相关认证信息以加密的方式发到服务器。
步骤s306，终端向服务器发送一个对认证的响应；
响应消息的内容可以如下所示：
Authorization：Digest username＝＂Mufasa＂，
realm＝＂testrealm@host.com＂，
nonce＝＂dcd98b7102dd2foe8b11d0f600bfb0c093＂，
uri＝＂/xxx/index.html＂，
qop＝auth，
nc＝00000001，
cnonce＝＂0a4f13b＂，
response＝＂6629fae49393a05397450978507c4efl＂，
opaque＝＂5ccc069c403ebaf9f0171e9517f40e41＂
终端在收到Challenge消息后会将自己的用户名及密码和Challenge一起加密传给服务器。这样的好处是可以不用明文发送密码。
当认证成功后服务器会保持之前终端的接收；如果终端认证未通过，用户也可以继续观看节目，但对于服务器统计LogInInfo是无效的。
步骤s301-s306为标准的HTTP摘要认证的方式，其中的各字段可参考RFC2617。摘要认证的方法在这里只是举例说明。
步骤s307，服务器发送200 OK消息到终端。
终端的用户名及密码通过服务器的认证，服务器发送200 Ok到终端；本实施例中是以HTTP方式举例说明，因此这里用200 OK表示认证成功。
步骤s308，服务器向终端正常发送节目内容；
终端接入到频道后如果不在规定的时间内退出，继续接收节目内容，则服务器可以采用广播发送的方式，也可以采用其它的发送方式发送节目内容。如果服务器采用广播的方式发送节目内容，终端从该频道的广播中接收内容。如果采用其它方式(例如流媒体)，服务器可以在与终端建立的链路上发送内容。对于流媒体方式可以用单播，也可以用组播发送节目内容；
步骤s309，终端退出当前观看的节目。
用户退出当前观看节目的时间是任意的，可以在节目结束后，也可以在播放途中退出。当用户退出后将触发终端发送状态消息到服务器。
步骤s310，终端发送一条LogOutInfo消息到服务器。
LogOutInfo消息的内容可以如下所示：
   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.samp.com:8080
   Connection:close
   <CR>
   <？xml version＝＂1.0＂encoding＝＂UTF-8＂？>
   <!--edited with XMLSPY 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方法将LogOutInfo的XML数据信息发到服务器上，POST消息中的含义与第4步相同。消息体为LogOutInfo的XML形式数据。
该消息包括了Service ID、User ID、以及当前退出时间EndTime等。终端的LogOutInfo消息具有某种格式，例如如图3所示。消息的发送是通过交互信道完成的。保存LogOutInfo消息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服务器。
LogOutInfo消息可以用HTTP方式将消息带到服务器由服务器来完成处理并加入数据库中，也可以用SMS或其它方式。本例中通过HTTP POST方法将消息带到服务器的方式只是举例说明，也可以用其它的承载手段代替，但所涉及的原理和思想是一致的。
步骤s311，当服务器正确接收的LogOutInfo消息后返回200OK消息给终端。
返回应答可以通过交互信道，也可以通过其它的方式。本例中用200OK代表发送内容成功到达。在不同的网络环境中也可以采用其它的应答方式，所涉及的思想和原理都是一样的。
步骤s312，服务器在终端退出节目后对终端的状态信息进行保存，并进行统计。
服务器根据终端上报的LogInInfo和LogOutInfo状态信息进行频道的收视率统计或节目的收视率统计；
收视率统计的两种方式：
A SG中可以包括频道标识，这样当Server需要对某时间段的某个频道做收视率统计的时候，可以在SG中该频道设置需要进行收视率统计的标识，例如CCTV2 stat＝TRUE2007-08-09 12:00～13:00，表明CCTV2这个频道在2007-08-09 12:00～13:00，如果用户选择的该频道，则需要向服务器发送消息，以表明该用户正在收看或收看结束这样动作，服务器以此来进行收视率的统计，或进行其他相关的统计操作。
B 另一种收视率统计的方式是：服务器向目前在线的所有用户或其中一部分用户Client发送消息，要求该用户反馈当前是否在收看该频道，用户Client回复该消息，并携带相关信息，以表明对该服务器请求的答复，这样可以实现服务器上进行相关数据的统计工作；
并且可以统计该用户对节目的偏好。服务器从记录的终端观看节目的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)等。该服务器可以是交互服务器也可以是专门用来记录终端信息的服务器。例如LogInInfo和LogOutInfo消息的定义数据结构形式如下表5所示。
 
消息 必要性 方向
LogInInfo 强制 Client→Server
LogOutInfo 强制 Client→Server
表格5 本发明涉及到的终端与服务器间的消息类型
LogInInfo消息和LogOutInfo消息都是强制必须的消息。方向都是从终端到服务器。
LogInInfo和LogOutInfo消息的数据组成入下表6和7所示：
 
Information Req Type Description
 
Element
Message-Type Mandatory String 消息类型标识“LogInInfo”
User ID Mandatory String 终端用户ID
Service ID Mandatory String 业务的ID(i.e ChannelID)
Program ID Mandatory String 观看的节目ID
Online state Mandatory String 在线状态
IMSI Mandatory String 客户识别码(IMSI)
Channel stat Mandatory String 频道标识，用来标帜该频道的统计情况              
表6 LogInInfo消息组成
 
InformationElement Req Type Description
Message-Type Mandatory String 消息类型标识“LogInInfo”
User ID Mandatory String 终端用户ID
Service ID Mandatory String 业务的ID(i.e ChannelID)
Program ID Mandatory String 观看的节目ID
Online state Mandatory String 在线状态
IMSI Mandatory String 客户识别码(IMSI)
Channel stat Mandatory String 频道标识，用来标帜该频道的统计情况
表7 LogOutInfo消息组成
用schema表示该数据结构：
<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>
<！--edited with XMLSPY v5 rel.4U(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＂/>
             <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＂/>
                                   <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:attributen  ame＝＂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>
以上的消息都由终端发送到服务器，并由服务器保存。在服务器侧也可以构造一个类似下面的数据结构来保存需要记录的状态信息(用户管理信息)：
 
User ID Service ID Program ID StartTime End Time Time
1234 01 11 10:50 11:?30 40m
2462 01 11 10:20 11:15 55m
55208 02 21 12:05 12:25 20m
4567 03 32 12:00 12:30 30m
49653 02 21 12:15 12:25 10m
表6 统计表
该数据结构的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。同一时间相同频道只有一个节目。Service ID、Program ID由提供节目的内容提供商规定。也可以是一个频道在一段时间内只提供一个节目给用户观看。User ID、Service ID、Program ID、EndTime、StartTime这些属性只是举例说明终端观看节目的状态信息，如果需要可以进行修改与扩展。
StartTime和EndTime是服务器记录的终端接入和退出频道时的时间，该时间是终端记录当前播发的节目内容的时间，Time为二者差值，表示用户连续观看该节目的时长。因为每个节目内容都是由服务器以数据包的形式一帧一帧的发送到终端的，每一帧都会有一个时间戳信息，这个时间戳是由服务器加上的，因此可以从第一帧的数据包中提取接入时间，从最后一帧提取退出时间，所得差值为终端接入频道的持续时长。数据包的时间是与终端本地时间无关的网络时间，由服务器决定，因此无论终端本地时间是否准确都不会影响终端接入频道的时长。这样的时间记录对于统计用户观看时间是比较合理的，基本可以保证记录时间就是观看时间。并且对于服务器而言能够获得比较准确的统计。
本实施例中的服务器可以是互动服务器，也可以是专门用来保存统计信息的服务器。由于本实施例中的消息相对内容少，数据易统计，因此对服务器的负担小。此外，对于本例中的服务器，如果能够支持一定量的用户数量，增加这样的统计后并不会对支持的用户数有太多的改变。
本实施例中所涉及的发送用户管理信息(状态信息)的消息LogInInfo、LogOutInfo只是举例说明，其他类似携带用户管理信息的消息方法也可以完成状态信息的发送，所涉及的原理与思想都是一致的。
本发明的实施例四提供了一种将终端接入节目频道(Login)和终端退出播放节目(Logout)时将用户管理信息发送到服务器，由服务器根据用户管理信息完成与终端的交互更新的方法。用户成功订阅了频道后，在观看一个频道的过程中可能会参与节目的互动，例如互动话题的讨论，互动游戏等等。通过终端与服务器的交互更新可以达到在本地终端就能同时完成节目观看与互动参与的效果。
请参照流程图图3，该方案的主要思想在于，终端在接入观看一个节目的过程中，如果该节目中有互动参与的部分，那么服务器可以给终端发送该节目互动信息，如果在该节目的播放过程中互动信息发生了更新，那么服务器可以根据终端的状态信息将互动的更新信息发给终端。通常在观看一个互动节目的时候会有互动信息的下发与更新两种情况，互动信息可以与节目内容一起下发到终端，但是互动信息的类型在一个节目当中的形式等都会是一致的，因此只要对节目的互动信息进行更新，用户就可以不断的参与到该互动节目中来。而这样的互动信息的更新是根据终端发给服务器的状态信息进行发送的。
实施例四的具体流程如图4所示，步骤如下:
步骤s401，终端启动，并向服务器发送LogInInfo消息。
LogInInfo消息的内容可以如下所示:
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 XMLSPY 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＝＂LogInInfo＂/>
  <User_ID User_ID_Type＝＂abc＂/>
  <Service_ID Service_ID_Type＝＂01＂/>
  <Program_ID Program_ID_Type＝＂11＂/>
本实施例中，LogInInfo消息以XML(Extensible Markup Language，可扩展标记语言)的形式作为消息体加在HTTP(Hyper Text Transfer Protocol，超文本传输协议)POST头的后面，带到服务器上。消息头和消息体间用回车<CR>间隔开，回车上面的为消息头，下面的为消息体。消息头中描述了要请求的主机和端口，连接方式为close，表示不必持续连接，HTTP1.1支持非持续连接。
LogInInfo消息包括了Service ID、User ID(例如：IMSI信息)、以及其它接入状态信息。终端的LogInInfo消息具有某种格式，例如如图2所示。消息的发送是通过交互信道完成的。保存LogInInfo消息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服务器。本实施例中LogInInfo以html的形式发送到服务器上。
发送LogInInfo的方法可以是通过多种方法，例如HTTP POST方法。这里只是举例说明，如有其它方式可以替代，其原理与思想是一致的。
Client启动时会将Login的消息LogInInfo上报给Server，同时服务器将该用户状态制成online。Client到服务器上取SG以及其他相关数据。而当Server上的这些相关数据有更新的时候，此时服务器可以向已经在线的用户进行数据更新的通知Push消息发送给online的Client，则Client可以及时感知服务器上的数据变化，及时取回数据。
步骤s402，获取SG。
手机电视终端接收频道节目的前提是该Client已经注册在Server上，并且已经激活，可以接入频道接收节目。
步骤s403，未定购频道的终端根据获取的SG重新建立频道定购。
确定的定购关系描述的是用户对SG中频道订阅的情况。它可以是以表的方式保存在Server端。以Server来同步Client。
A定购的方式可以是外部的：例如通过上网或拨打电话的方式来完成。定购的结果会记录到服务器上；
B也可以是内部的：通过Client在SG上进行定购。每当Client定购或退定一个频道，Server上的定购关系表都会进行一次修改，并随后同步给Client。
C定购关系可以是Server向Client同步，服务器会在Client启动时将定购关系与online状态的用户进行同步，也可根据服务器策略定期同步；定购关系也可以是终端来维护，向服务器进行同步，当用户进行定购以后，本地的定购关系会通过HTTP的POST方式发到服务器上与服务器同步。
用户接入频道后可以接收SG(Service Guide，服务指南)。SG中有频道内容的预告。通过SG Client可以获得相关的频道列表，并根据该频道列表提供的频道接收节目内容。
如果采用广播接收的方式，终端根据之前收到的手机频道导航SG，选择希望收看的频道。通过SG上显示的频道标识，用户终端在选择后，终端会开始节目的接收。
步骤s404，服务器端向终端发送节目内容。
服务器可以采用广播的方式将内容发送出去，也可以用流媒体的方式发送内容。
如果终端在接收到节目内容一段时间后(可以设定为1分钟)没有退出，那么该信息就将被发送到服务器。服务器可以记录终端接入时间。
终端侧接入到频道后的处理首先要在本地记录当前的状态信息，规定的一段时间可以是网络设定的，也可以是内容提供商设定的。该时间被终端用来判定是否要向服务器发送统计信息。如果终端接入频道的时间超过了该设定时间，则可以认为用户是在观看节目；否则，如果在这段时间内终端退出了该频道，则认为用户没有收看该频道节目。
步骤s405，服务器对终端进行鉴权。
鉴权消息的内容可以如下所示：
HTTP/1.1401Unauthorized
Server:Microsoft-IIS/5.1
WWW-Authenticate:Digest
realm＝＂testrealm@host.com＂，
qop＝＂auth，auth-int＂，
nonce＝＂dcd98b7102dd2f0e8b11d0f600bfb0c093＂，
opaque＝＂5ccc069c403ebaf9f0171e9517f40e41＂
<CR>
服务器收到终端发来的POST消息，对终端要进行一次认证，服务器会发质询给终端。所谓“发出质询”，就是给客户端发送一个HTTP响应，其状态码为401(Unauthorized)，并且包含消息头WWW-Authenticate，客户端看到这个响应就知道这个URI(Uniform Resource Identifier，通用资源标志符)需要认证。
domain：一个URI列表，指示要保护的域。可能是一个列表，提示用户这些URI采用一样的认证，如果为空或忽略则为整个服务器。
nonce：随机字符串，每次401都不一样。跟算法有关。算法类似Base64加密：time-stamp H(time-stamp＂:＂ETag＂:＂private-key)。time-stamp为服务器时钟，ETag为请求的Etag头。
opaque：服务器产生的由客户发送请求时原样返回。最好是Base64串或十六进制字符串。realm-value是一个两端加引号的大小写相关的字符串，表示要求认证的“领域(realm)”。领域是由服务器自己决定的，不同的服务器可以设置自己的领域，同一个服务器也可以有多个领域。质询中包含领域信息是为了让客户端知道哪个范围的用户名是合法的。服务器对终端进行鉴权的消息可以没有消息体。
服务器为了获得终端接入用户的身份，需要对终端进行一次认证。这个认证与用户注册时认证目的不同，这个对接入用户的认证可以保证观看节目的用户为接入用户，可以保证收视率统计的客观性。认证的方式有多种，例如HTTP的摘要认证方式。
服务器接收到用户发来的LogInInfo，在将该消息中的数据写入数据库前，为了确定接入节目的用户的身份，及LogInInfo的合理性，必须对用户进行一次认证。因为用户在发送LogInInfo的时候不知道是否认证，因此服务在收到LogInInfo时会发送一个HTTP的401消息，该消息包括了一个挑战(challenge)，challenge需要用户名及密码等相关认证信息以加密的方式发到服务器。
步骤s406，终端向服务器发送一个对认证的响应；
响应消息的内容可以如下所示：
Authorization：Digest username＝＂Mufasa＂，
realm＝＂testrealm@host.com＂，
nonce＝＂dcd98b7102dd2f0e8b11d0f600bfb0c093＂，
uri＝＂/xxx/index.html＂，
qop＝auth，
nc＝00000001，
cnonce＝＂0a4fl13b＂，
response＝＂6629fae49393a05397450978507c4efl＂，
opaque＝＂5ccc069c403ebaf9fo171e9517f40e41＂
终端在收到Challenge消息后会将自己的用户名及密码和Challenge一起加密传给服务器。这样的好处是可以不用明文发送密码。
当认证成功后服务器会保持之前终端的接收；如果终端认证未通过，用户也可以继续观看节目，但对于服务器统计LogInInfo是无效的。
步骤s401-s406为标准的HTTP摘要认证的方式，其中的各字段可参考RFC2617。摘要认证的方法在这里只是举例说明。
步骤s407，服务器发送200OK消息到终端。
终端的用户名及密码通过服务器的认证，服务器发送200Ok到终端；本实施例中是以HTTP方式举例说明，因此这里用200OK表示认证成功。
步骤s408，服务器向终端发送节目内容及互动信息。
终端接入到频道后如果不在规定的时间内退出，继续接收节目内容，则服务器可以采用广播发送的方式，也可以采用其它的发送方式发送节目内容。如果服务器采用广播的方式发送节目内容，终端从该频道的广播中接收内容。如果采用其它方式(例如流媒体)，服务器可以在与终端建立的链路上发送内容。对于流媒体方式可以用单播，也可以用组播发送节目内容；
交互媒体文档及包含的交互媒体对象可以随节目内容一起下发，也可以在收看节目内容之前下发。
步骤s409，服务器向终端发送互动更新。
当互动节目的互动信息发生改变时，服务器可以将互动信息的更新发送到终端。服务器在发送前需要根据终端上报的LogInInfo信息对终端的观看情况做出判断，比如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.samp.com:8080
Connection:close
<CR>
(用户互动信息)
当节目播放过程中出现互动参与时，用户可以通过HTTP POST方法将节目互动过程中个人的选择以消息体的形式发送到服务器，也可以在互动话题讨论的过程中以SMS方式将讨论的内容发送到服务器，达到完成节目互动的目的。用户编辑消息的过程可以是一个简单的选择，也可以是以文字描述的形式发表意见，这些操作都不会影响终端继续接收服务器发送的节目内容。因此在互动参与期间用户可以不终断节目的观看就完成互动的操作。
步骤s411，服务收到用户发来的互动信息，并进行处理。
互动服务器接收到用户发来的互动信息，根据互动服务器的策略，可以将此信息进行实时的处理，也可以在节目结束后处理。互动服务器会提取用户的互动信息，并根据信息内容向用户发送互动内容。比如，当用户在互动节目的选择中选择了A片段，那么接下来互动服务器会根据用户的互动选择播放A片段。
步骤s412，服务器将当前处理完毕的互动参与结果连同节目内容一起发送到终端。
用户可以在参与一次互动后就立刻将服务器处理的互动统计结果发送到终端用户，使终端用户可以立刻知道参与后的结果，或当前该互动节目的整体参与情况。因此发送的当前互动参与结果可以是用户参与完毕后个人的结果，也可以是当前所有参与者的整体参与结果。
这样的互动过程在一个互动节目中可以有多次。本例中用虚线表示返回的参与结果，意味着参与结果可以返回给用户也可以不返回。这是根据互动服务器及该互动节目的策略所制定。
步骤s413，终端退出当前观看的节目。
用户退出当前观看节目的时间是任意的，可以在节目结束后，也可以在播放途中退出。当用户退出后将触发终端发送状态消息到服务器。
步骤s414，终端发送一条LogOutInfo消息到服务器。
LogOutInfo消息的内容可以如下所示：
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.samp.com:8080
Connection:close
<CR>
<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>
<!--edited with XMLSPY 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方法将LogOutInfo的XML数据信息发到服务器上，POST消息中的含义与步骤s404相同。消息体的内容为LogOutInfo的XML形式的数据。
该消息包括了Service ID、User ID，服务器此时可以记录当前退出时间EndTime。终端的LogOutInfo消息具有一定的格式如图7所示。消息的发送是通过互动信道完成的。保存LogOutInfo消息的服务器可以是交互服务器，也可以是专门用来记录统计数据的服务器。
LogOutInfo消息可以用HTTP POST方法将消息带到服务器由服务器来完成处理并加入数据库中，也可以用SMS的承载方式。本例中通过HTTP POST方法将消息带到服务器的方式只是举例说明，也可以用其它的承载手段代替，但所涉及的原理和思想是一致的。
步骤s415，当服务器正确接收的LogOutInfo消息后返回200OK消息给终端。
返回应答可以通过互动信道，也可以通过其它的方式。比如服务器可以端对端的将应答发送的终端，也可以Push到终端。本例中用200OK代表发送内容成功到达。在不同的网络环境中也可以采用其它的应答方式，所涉及的思想和原理都是一样的。
步骤s416，服务器在终端退出节目后对用户的互动信息进行保存，并根据互动节目中用户的参与进行统计。
服务器保存用户在互动节目中发送的互动信息，在节目完毕后对用户的互动信息进行统计。最后可以将统计的结果反馈给用户。统计的内容可以是节目的参与度或者该节目的整体互动的结果。比如，在一个选择性的互动节目结束后，互动服务器会统计选择A的观众与选择B的观众人数。这样的举例只是为了更明确的说明互动更新的结果和形式。
步骤s417，服务器将最终的互动节目统计结果发送给用户。
终端用户参与完毕一个节目后可以得到一个参与的结果，该结果可以包括该终端用户的参与结果以及整体节目的参与结果。本实施例用虚线表示最终结果的发送，表示这一步是可选的。
通过终端在接收节目内容的过程中对互动节目的反馈，以及服务器对用户的选择做出的相应可以达到互动更新的目的。本实施例中所用到的消息承载以及消息发送方式只是举例，可以用其它的承载方式及发送方式替代，但其原理和思想是一致的。
本实施例中的LogOutInfo和LogInInfo消息可以保存在服务器上，用以对终端的节目观看信息进行统计。保存的数据结构形式可以用与表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，用于向服务器10发送本终端的用户管理信息。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得网络设备执行本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (20)

1、一种手机电视业务中获取用户管理信息的方法，其特征在于，包括如下步骤：
服务器接收终端发送的用户管理信息；
所述服务器保存获取的所述终端的用户管理信息。
2、如权利要求1所述获取用户管理信息的方法，其特征在于，所述用户管理信息包括以下信息中的一种或多种：
消息类型标识、消息发送时间、终端标识、业务标识、节目标识、终端是否在线的状态、终端识别码、用户标识信息以及频道标识，所述消息类型标识包括登录消息标识和注销消息标识。
3、如权利要求1所述获取用户管理信息的方法，其特征在于，还包括如下的步骤：
所述服务器对所获取的用户管理信息进行处理。
4、如权利要求3所述获取用户管理信息的方法，其特征在于，对用户管理信息的处理方法包括如下的一种或几种：
记录用户登录状态；记录用户观看节目状态信息；记录用户需要更新的业务信息；
其中，所述用户的登录状态的记录包括如下信息的一种或几种的记录：终端标识、用户标识、业务订阅关系、登陆时间、登陆方式、用户密钥的有效期；
所述用户观看节目状态的记录包括如下信息的一种或几种的记录：用户观看的节目标识、用户观看的频道标识、用户收看频道的开始时间、用户观看频道的退出时间；
所述用户需要更新的业务信息的记录包括如下信息的一种或几种的记录：用户密钥是否需要更新、用户互动信息是否需要更新、用户业务SG是否需要更新。
5、如权利要求4所述获取用户管理信息的方法，其特征在于，所述频道的节目收看时间的获取方法为：
根据所述用户管理信息中携带的消息发送时间获取；或
根据所述服务器向所述终端发送节目第一帧和最后一帧的时间获取。
6、如权利要求1或2所述获取用户管理信息的方法，其特征在于，所述获取频道或节目的收视率的步骤具体为：
所述服务器对需要进行统计的频道或节目设置标识；
终端在接收或退出所述频道或节目的内容时，根据所述标识向所述服务器发送消息；
所述服务器根据所述消息获取频道或节目的收视率。
7、如权利要6所述获取用户管理信息的方法，其特征在于，所述获取频道或节目的收视率的步骤具体为：
所述服务器向所有终端或特定的终端发送是否在收看特定频道或节目的消息；
正在收看所述特定频道或节目的终端向所述服务器发送响应消息；
所述服务器根据所述响应消息获取频道或节目的收视率。
8、如权利要求1或2所述获取用户管理信息的方法，其特征在于，所述互动节目统计信息的获取方法具体为：
所述服务器接收到终端发送的用户管理信息后，向所述终端发送互动节目，所述互动节目内容中包括互动信息和/或互动更新信息；
所述服务器接收所述终端发送的互动信息响应；
所述服务器根据所述互动信息响应，处理得到互动节目的统计信息。
9、如权利要求1或2所述获取用户管理信息的方法，其特征在于，所述终端向所述服务器发送用户管理信息的步骤具体为：
所述终端在启动时、或切换所观看的节目或频道时，向所述服务器发送用户管理信息。
10、如权利要求9所述获取用户管理信息的方法，其特征在于，所述服务器接收终端发送的用户管理信息后，还包括步骤：
所述服务器根据所述终端在接收到启动时、或切换所观看的节目或频道时发送的鉴权请求，发起对所述终端的鉴权。
11、如权利要求9所述获取用户管理信息的方法，其特征在于，所述服务器接收终端发送的用户管理信息后，还包括步骤：
所述服务器向所述终端发送所述终端选择的节目内容；
所述服务器判断所述终端接收所述节目内容超过预设时间时，发起对所述终端的鉴权。
12、如权利要求1所述获取用户管理信息的方法，其特征在于，所述服务器接收终端发送的用户管理信息后，还包括步骤：
所述服务器向所述终端提供服务指南中包括的可选节目。
13、如权利要求12所述获取用户管理信息的方法，其特征在于，所述服务器向所述终端提供服务指南中包括的可选节目后，还包括步骤：
所述服务器接受所述终端对所述服务指南中包括的可选节目的订购或退订；
所述终端订购的节目发生变化时，更新所述服务器和所述终端上存储的终端订购节目信息。
14、一种手机电视业务中获取用户管理信息的系统，其特征在于，包括：
服务器，用于接收终端发送的用户管理信息，并保存所获取的所述终端的用户管理信息；
终端，用于向所述服务器发送用户管理信息。
15、如权利要求14所述获取用户管理信息的系统，其特征在于，所述服务器进一步包括：
接收模块，用于接收所述终端发送的用户管理信息；
统计模块，用于保存所述接收模块获取的所述终端的用户管理信息。
16、如权利要求14所述获取用户管理信息的系统，其特征在于，所述终端进一步包括：
用户管理信息发送模块，用于向所述服务器发送本终端的用户管理信息。
17、一种手机电视业务中的服务器，用于获取用户管理信息，其特征在于，包括：
接收模块，用于接收终端发送的用户管理信息；
统计模块，用于保存所述接收模块获取的所述终端的用户管理信息。
18、如权利要求17所述手机电视业务中的服务器，其特征在于，还包括：
节目订购模块，用于接受所述终端对服务指南中包括的可选节目的订购或退订，并根据订购或退订结果更新本地存储的终端订购节目信息。
19、如权利要求17所述手机电视业务中的服务器，其特征在于，还包括：
鉴权模块，用于对请求收看节目的终端进行鉴权。
20、如权利要求17所述手机电视业务中的服务器，其特征在于，还包括：
互动节目处理模块，用于进行互动节目中与所述终端的互动功能的实现。
CN200710162759.XA 2007-09-30 2007-09-30 获取用户管理信息的方法、系统和设备 Active CN101399958B (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN200710162759.XA CN101399958B (zh) 2007-09-30 2007-09-30 获取用户管理信息的方法、系统和设备
KR1020107008233A KR101159556B1 (ko) 2007-09-30 2008-09-26 사용자 관리 정보를 획득하는 방법, 시스템 및 장치
JP2010526139A JP5242690B2 (ja) 2007-09-30 2008-09-26 ユーザ管理情報を得るための方法、システム、および装置
PCT/CN2008/072554 WO2009046671A1 (fr) 2007-09-30 2008-09-26 Procédé, système et appareil pour obtenir des informations de gestion d'utilisateur
EP08837169A EP2190231A4 (en) 2007-09-30 2008-09-26 A PROCESS, SYSTEM AND DEVICE FOR OBTAINING USER MANAGEMENT INFORMATION
US12/749,104 US20100186044A1 (en) 2007-09-30 2010-03-29 Method, system, and device for obtaining user management information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200710162759.XA CN101399958B (zh) 2007-09-30 2007-09-30 获取用户管理信息的方法、系统和设备

Publications (2)

Publication Number Publication Date
CN101399958A true CN101399958A (zh) 2009-04-01
CN101399958B CN101399958B (zh) 2010-11-03

Family

ID=40518172

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200710162759.XA Active CN101399958B (zh) 2007-09-30 2007-09-30 获取用户管理信息的方法、系统和设备

Country Status (6)

Country Link
US (1) US20100186044A1 (zh)
EP (1) EP2190231A4 (zh)
JP (1) JP5242690B2 (zh)
KR (1) KR101159556B1 (zh)
CN (1) CN101399958B (zh)
WO (1) WO2009046671A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101998153B (zh) * 2009-08-17 2013-04-03 中国移动通信集团公司 基于广播式移动多媒体业务上报收看频道的方法及装置
CN103546770A (zh) * 2012-07-11 2014-01-29 上海曜铂信息科技有限公司 智能收视率采集方法
CN104486645A (zh) * 2014-11-20 2015-04-01 小米科技有限责任公司 确定节目收视率的方法、播放设备、服务器及装置
CN105100932A (zh) * 2015-08-29 2015-11-25 天脉聚源（北京）科技有限公司 显示参与互动的用户信息的方法和装置
CN105228012A (zh) * 2015-09-28 2016-01-06 天脉聚源（北京）科技有限公司 一种管理互动电视系统用户信息的方法及装置
CN105245963A (zh) * 2015-09-24 2016-01-13 天脉聚源（北京）科技有限公司 一种处理电视互动系统互动信息的方法及装置
CN105307039A (zh) * 2015-10-28 2016-02-03 天脉聚源（北京）科技有限公司 一种用于电视互动系统电视节目管理的方法及装置
CN106470347A (zh) * 2015-08-21 2017-03-01 北京国双科技有限公司 基于iptv的订购信息统计方法、服务器及视频播放器
WO2018018455A1 (zh) * 2016-07-27 2018-02-01 黄新勇 用户观看内容的统计方法及系统
WO2018018453A1 (zh) * 2016-07-27 2018-02-01 黄新勇 电视广播中观看时间统计方法及系统
WO2018018456A1 (zh) * 2016-07-27 2018-02-01 黄新勇 电视广播的片源统计方法及系统
CN107801186A (zh) * 2016-09-06 2018-03-13 普天信息技术有限公司 一种集群通信系统中非接入层摘要鉴权方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5166544B2 (ja) * 2008-10-07 2013-03-21 シャープ株式会社 デジタル放送受信装置、及び受信方法
US10776839B1 (en) * 2015-05-29 2020-09-15 Intuit Inc. Photo transactions for financial applications
JP6769106B2 (ja) * 2016-05-18 2020-10-14 富士通株式会社 ストレージ制御方法、ストレージ制御プログラムおよび情報処理装置
CN105979300A (zh) * 2016-06-27 2016-09-28 乐视控股（北京）有限公司 身份识别方法及装置
CN106131677A (zh) * 2016-07-27 2016-11-16 黄新勇 用户观看内容的统计方法及系统

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3328951B2 (ja) * 1992-02-07 2002-09-30 ソニー株式会社 Ｔｖ受像機及び選局方法
US5758257A (en) * 1994-11-29 1998-05-26 Herz; Frederick System and method for scheduling broadcast of and access to video programs and other data using customer profiles
US5796952A (en) * 1997-03-21 1998-08-18 Dot Com Development, Inc. Method and apparatus for tracking client interaction with a network resource and creating client profiles and resource database
US6353929B1 (en) * 1997-06-23 2002-03-05 One River Worldtrek, Inc. Cooperative system for measuring electronic media
US7260823B2 (en) * 2001-01-11 2007-08-21 Prime Research Alliance E., Inc. Profiling and identification of television viewers
JP2001197478A (ja) * 2000-01-17 2001-07-19 Canon Inc 放送管理システム、放送管理装置、受信装置及びそれらの制御方法、コンピュータ可読メモリ
JP2002057645A (ja) * 2000-08-10 2002-02-22 Ntt Docomo Inc データ転送方法および移動体サーバー
US7370073B2 (en) * 2000-11-28 2008-05-06 Navic Systems, Inc. Using viewership profiles for targeted promotion deployment
JP2002223427A (ja) * 2001-01-26 2002-08-09 Ntt Comware Corp 番組視聴関連情報取得方法及び番組視聴関連情報取得装置及び番組視聴関連情報取得システムならびにそのプログラム及びこのプログラムを記録した記録媒体
JP2002271283A (ja) * 2001-03-09 2002-09-20 Tomo-Digi Corp デジタル放送番組を構成するデータ放送データおよびデジタル放送番組の放送方法
JP2003061065A (ja) * 2001-08-10 2003-02-28 Nippon Telegraph & Telephone East Corp 視聴者参加型ストリーミング配信方法ならびにアンケート管理サーバおよび視聴者端末装置
US20030110500A1 (en) * 2001-12-06 2003-06-12 Rodriguez Arturo A. Prediction-based adaptative control of television viewing functionality
JP3853663B2 (ja) * 2002-02-04 2006-12-06 富士通株式会社 抽選方法及び抽選プログラム
CN100512417C (zh) * 2003-02-24 2009-07-08 华为技术有限公司 交互数字广播电视网络系统及其前端和终端装置
JP2005056246A (ja) * 2003-08-06 2005-03-03 Sony Corp 情報端末装置、サーバ装置およびプログラム
JP2006005767A (ja) * 2004-06-18 2006-01-05 Omron Entertainment Kk 端末装置、サーバ装置、通信ネットワークシステム、端末装置の制御方法、サーバ装置の制御方法、プログラム、および、プログラムを記録した記録媒体
JP4334426B2 (ja) * 2004-07-09 2009-09-30 シャープ株式会社 Ｕｉコンテンツ生成方法、ｕｉコンテンツ生成装置及びｕｉコンテンツ生成システム
CN100556128C (zh) * 2004-07-14 2009-10-28 上海微小卫星工程中心 电视收视率自动采集和统计方法及系统
US8402506B2 (en) * 2005-01-05 2013-03-19 Yahoo! Inc. Informational alert messaging for digital home services
WO2006072825A1 (en) * 2005-01-07 2006-07-13 Nortel Networks Limited Systems and methods for distributing content in wireless networks
JP4727246B2 (ja) * 2005-02-08 2011-07-20 三菱電機株式会社 視聴率集計システム
KR100898226B1 (ko) * 2005-04-08 2009-05-18 티유미디어 주식회사 시청률 조사 시스템 및 그 방법
US8141138B2 (en) * 2005-10-17 2012-03-20 Oracle International Corporation Auditing correlated events using a secure web single sign-on login
US20070099560A1 (en) * 2005-11-02 2007-05-03 Sony Ericsson Mobile Communications Ab Mobile device control of mobile television broadcast signals to alternate destinations
US7694322B2 (en) * 2005-12-20 2010-04-06 Sony Ericsson Mobile Communications Ab Efficient streamed content delivery to portable communications device
KR20070074153A (ko) * 2006-01-06 2007-07-12 에스케이 텔레콤주식회사 위성 ｄｍｂ 시청율 조사 서비스 시스템 및 방법
JP2007202031A (ja) * 2006-01-30 2007-08-09 Kyocera Corp 移動型放送受信装置及び視聴情報送信方法
JP2007272868A (ja) * 2006-03-07 2007-10-18 Sony Corp 情報処理装置、情報通信システム、および情報処理方法、並びにコンピュータ・プログラム
CN2938648Y (zh) * 2006-04-30 2007-08-22 朱大为 一种手机电视终端
CN100433627C (zh) * 2006-06-21 2008-11-12 华为技术有限公司 实现移动多媒体广播组播的系统及方法
KR100758507B1 (ko) * 2007-03-14 2007-09-13 주식회사 셀런 쌍방향 방송 시스템에서 광고 시청자의 반응을 유도하여광고시청을 활성화하고 광고 시청률을 조사하는 방법

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101998153B (zh) * 2009-08-17 2013-04-03 中国移动通信集团公司 基于广播式移动多媒体业务上报收看频道的方法及装置
CN103546770A (zh) * 2012-07-11 2014-01-29 上海曜铂信息科技有限公司 智能收视率采集方法
CN104486645A (zh) * 2014-11-20 2015-04-01 小米科技有限责任公司 确定节目收视率的方法、播放设备、服务器及装置
CN106470347A (zh) * 2015-08-21 2017-03-01 北京国双科技有限公司 基于iptv的订购信息统计方法、服务器及视频播放器
CN105100932A (zh) * 2015-08-29 2015-11-25 天脉聚源（北京）科技有限公司 显示参与互动的用户信息的方法和装置
CN105245963A (zh) * 2015-09-24 2016-01-13 天脉聚源（北京）科技有限公司 一种处理电视互动系统互动信息的方法及装置
CN105228012A (zh) * 2015-09-28 2016-01-06 天脉聚源（北京）科技有限公司 一种管理互动电视系统用户信息的方法及装置
CN105307039A (zh) * 2015-10-28 2016-02-03 天脉聚源（北京）科技有限公司 一种用于电视互动系统电视节目管理的方法及装置
WO2018018455A1 (zh) * 2016-07-27 2018-02-01 黄新勇 用户观看内容的统计方法及系统
WO2018018453A1 (zh) * 2016-07-27 2018-02-01 黄新勇 电视广播中观看时间统计方法及系统
WO2018018456A1 (zh) * 2016-07-27 2018-02-01 黄新勇 电视广播的片源统计方法及系统
CN107801186A (zh) * 2016-09-06 2018-03-13 普天信息技术有限公司 一种集群通信系统中非接入层摘要鉴权方法
CN107801186B (zh) * 2016-09-06 2020-10-30 普天信息技术有限公司 一种集群通信系统中非接入层摘要鉴权方法

Also Published As

Publication number Publication date
WO2009046671A1 (fr) 2009-04-16
JP2010541345A (ja) 2010-12-24
CN101399958B (zh) 2010-11-03
JP5242690B2 (ja) 2013-07-24
EP2190231A1 (en) 2010-05-26
KR20100056562A (ko) 2010-05-27
US20100186044A1 (en) 2010-07-22
KR101159556B1 (ko) 2012-06-25
EP2190231A4 (en) 2011-03-09

Similar Documents

Publication Publication Date Title
CN101399958B (zh) 获取用户管理信息的方法、系统和设备
CN102210163B (zh) 用于在移动广播网络中实现互动的方法和系统
KR101494111B1 (ko) 사용자 입력에 기초하여 콘텐츠를 브로드캐스팅하는 방법들 및 시스템들
KR101729551B1 (ko) 브로드캐스트 서비스 및 브로드캐스트 콘텐츠 중 하나 이상에 대한 시청률을 단말 내에서 조사하는 방법
US20050090235A1 (en) Apparatus, system, method and computer program product for service selection and sorting
KR20060104995A (ko) 서비스 선택 및 분류를 위한 장치, 시스템, 방법 및 컴퓨터프로그램 생성물
CN101404747A (zh) 一种实现互动通信的终端、网络服务器、系统及方法
CN101267589A (zh) 实现互动业务的系统及方法
CN102932681A (zh) 电视节目推荐的实现方法及系统
CN101605227B (zh) 一种应用于cmmb终端间的节目通知方法及系统
CN102905168B (zh) 一种实时提供电视节目单的方法及系统
KR100777405B1 (ko) 디지털 멀티미디어 방송의 유료 컨텐츠 제공방법
CN101465992A (zh) 一种手机电视业务的电视节目通知方法及系统
JP2013115468A (ja) 構内インターネット構築システム
KR100731666B1 (ko) Ｃｂｓ 메시지를 이용한 디지털 멀티미디어 방송 컨텐츠제공 시스템 및 그 제공방법
KR101294147B1 (ko) 타 서비스 사용자와 인터랙션을 제공하는 방송 서비스 시스템 및 방법
CN101120597B (zh) 用于业务选择和分类的设备、系统、方法
KR100978821B1 (ko) 서비스 선택 및 분류를 위한 장치, 시스템, 방법 및 컴퓨터프로그램 생성물
WO2008082183A1 (en) Inquiring system for alteration result of subscriber information in digital multimedia broadcas(conditional access system)ting service using ota wireless communication network
KR101618781B1 (ko) 브로드캐스트 서비스 및 브로드캐스트 콘텐츠 중 하나 이상에 대한 시청률을 단말 내에서 조사하는 방법
KR101303257B1 (ko) 네트워크 연동형 프로그램 안내장치 및 방법
KR20110026322A (ko) 인터넷 텔레비전에서의 쿠폰 서비스 제공 방법
CN102026094A (zh) 彩信业务的处理方法、彩信中心、移动通信系统
KR20120037312A (ko) 시청 정보 처리 시스템

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant