JP2010541345A - ユーザ管理情報を得るための方法、システム、および装置 - Google Patents

ユーザ管理情報を得るための方法、システム、および装置 Download PDF

Info

Publication number
JP2010541345A
JP2010541345A JP2010526139A JP2010526139A JP2010541345A JP 2010541345 A JP2010541345 A JP 2010541345A JP 2010526139 A JP2010526139 A JP 2010526139A JP 2010526139 A JP2010526139 A JP 2010526139A JP 2010541345 A JP2010541345 A JP 2010541345A
Authority
JP
Japan
Prior art keywords
terminal
program
user
server
message
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
JP2010526139A
Other languages
English (en)
Other versions
JP5242690B2 (ja
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
Publication of JP2010541345A publication Critical patent/JP2010541345A/ja
Application granted granted Critical
Publication of JP5242690B2 publication Critical patent/JP5242690B2/ja
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

Abstract

ユーザ管理情報を得るための方法、システム、および装置を提供する。この方法は、端末により送信される、ユーザ管理情報を運ぶメッセージを受信するステップと、メッセージから端末のユーザ管理情報を得るステップと、ユーザ管理情報に関する情報を処理するステップとを含む。このシステムは、端末により送信されるユーザ管理情報を受信し、得られる端末のユーザ管理情報を記憶するためのサーバと、ユーザ管理情報をサーバに伝送するための端末とを含む。

Description

本出願は、参照により本明細書に全部組み込まれる、２００７年９月３０日に中国特許庁に出願された「ユーザ管理情報を得るための方法、システム、および装置」と題する中国特許出願第２００７１０１６２７５９．Ｘ号の優先権を主張する。
本発明は、移動体通信分野に関し、詳細には、ユーザ管理情報を得るための方法、システム、および装置に関する。
モバイルテレビ放送（ＴＶ）サービスにより、ユーザが、オペレーティングシステムおよびビデオ機能の付いたインテリジェント携帯電話を介してＴＶを視聴することができるようになる。携帯電話の人気が高く、かつ携帯性が高いので、モバイルＴＶサービスには通常のＴＶサービスよりも広範な影響力がある。
現在、モバイルＴＶサービスは、以下の３つの方式で実現されている。第１の方式は移動ネットワークに基づいており、たとえばチャイナモバイル社がモバイルＴＶサービスを展開した。第２の方式は衛星放送に基づいており、たとえば、韓国の運営者がモバイルＴＶサービスを提供した。第３の方式は携帯電話の中に実装されたデジタルＴＶ受信モジュールに基づいており、このモジュールがデジタルＴＶ信号を直接受信することができる。
現在、移動ネットワークに基づくモバイルＴＶサービスが、チャイナモバイル社により展開され、汎用パケット無線サービス（ＧＰＲＳ）移動ネットワークに依存している。実際には、このモバイルＴＶサービスは、ストリーミング技術を使用することによりデータサービスとして展開されている。しかし、ユーザが、オペレーティングシステムを有する移動端末（一般には、携帯情報端末（ＰＤＡ））の中にプレーヤをダウンロードしてインストールする必要がある。チャイナモバイル社およびコンテンツ提供業者（サービス提供業者（ＳＰ））が協力することにより、関連するＴＶ番組コンテンツが提供される。
衛星ネットワークに基づくモバイルＴＶサービスを実現することは新しい考え方である。すなわち、衛星から放送されるＴＶ番組信号を受信するために、携帯電話が使用される。現在、韓国でだけデジタルマルチメディア放送（ＤＭＢ）受信機が展開されている。韓国によれば、ＤＭＰ受信機は高品質画像を提供することができ、この受信機を介して、ユーザが地上無線ＴＶ放送信号、および衛星ＴＶ放送信号を同時に受信することができる。
しかし、従来技術のモバイルＴＶサービスでは、サーバが端末状態情報を得ることができない、またはコンテンツの統計値を作成することができない。
従来技術には以下の欠点がある。すなわち、端末が放送方式でサーバから送信される番組コンテンツを得ることができるが、放送方式では大量の端末情報を管理することが困難である。たとえば、視聴率、および視聴されているＴＶ番組に関する対話文書を更新する処理を管理することが困難である。さらに、サービスガイド（ＳＧ）を更新した後に、更新したコンテンツを適切なユーザに即座に送信することができず、サーバはユーザ状態（たとえば、オンライン、および視聴中）を即座に得ることができない。
本発明の実施形態が、ユーザ管理情報を得るための方法、システム、および装置を提供して、端末のユーザ管理情報の統計値を作成する。
本発明の一実施形態におけるユーザ管理情報を得る方法は、
端末からのユーザ管理情報を運ぶメッセージを受信するステップと、
そのメッセージから端末のユーザ管理情報を得るステップと、
そのユーザ管理情報を処理するステップと、
を含む。
本発明の一実施形態におけるユーザ管理情報を得るシステムは、
端末からユーザ管理情報を受信し、端末の得られたユーザ管理情報を記憶するように適合されたサーバと、
サーバにユーザ管理情報を送信するように適合された端末と、
を含む。
本発明の一実施形態で提供されるサーバは、ユーザ管理情報を得るように適合され、
端末から送信されるユーザ管理情報を受信するように適合された受信モジュールと、
受信モジュールにより得られる、端末のユーザ管理情報を記憶するように適合された統計値モジュールと、
を含む。
本発明の一実施形態で提供される端末は、ユーザ管理情報をサーバに送信するように適合され、
ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュールと、
生成されたユーザ管理情報をメッセージの形式で送信するように適合されたユーザ管理情報送信モジュールと、
を含む。
従来技術と比較して、本発明の実施形態には以下の長所がある。
すなわち、本発明の実施形態は、端末とサーバの間の対話による、ユーザ管理情報統計値、対話更新、および視聴率統計値などの情報インターワーキングを実現する。
図１は、本発明の第１の実施形態におけるユーザ管理情報を得る方法の流れ図である。 図２は、本発明の第２の実施形態におけるユーザ管理情報を得る方法の流れ図である。 図３は、本発明の第３の実施形態におけるユーザ管理情報を得る方法の流れ図である。 図４は、本発明の第４の実施形態におけるユーザ管理情報を得る方法の流れ図である。 図５は、本発明の第５の実施形態におけるユーザ管理情報を得るためのシステムの構成を示す図である。
添付図面、および例示的実施形態を参照して本発明を以下に詳細に述べる。
図１に示すように、本発明の第１の実施形態におけるユーザ管理情報を得る方法は、以下のステップを含む。
Ｓ１０１． ユーザ管理情報を運ぶメッセージを端末から受信する。
Ｓ１０２． メッセージから端末のユーザ管理情報を得る。
Ｓ１０３． ユーザ管理情報を処理する。
具体的には、本発明の第１の実施形態では、対話更新、視聴率の統計、および他の情報のインターワーキングが、端末とサーバの間の対話により実現される。端末とサーバの間の対話メッセージが、ある種の形式に準拠し、わずかな必要情報を運ぶように指定されることもある。そのようなメッセージは、サーバにより処理しやすく、したがって、サーバの負荷を軽減する。サーバは、ある種の方針に従って端末情報を記録し、その統計値を作成することができる。サーバはまた、その方針に従って端末から報告される対話情報を処理することもできる。
本発明で提供される方法は以下の通りである。すなわち、ユーザがチャネルにログインするときに、端末がサービスＩＤ、およびユーザＩＤなどのユーザ管理情報をローカルに記憶する必要がある。番組を一定期間、受信した後に、端末はサービスＩＤ、ユーザＩＤ、およびチャネルＩＤなどのユーザ管理情報をサーバに送信する必要がある。端末がこの番組からログアウトした後に、端末はまた、サービスＩＤ、チャネルＩＤ、およびユーザＩＤなどのユーザ管理情報をサーバに送信する必要がある。そのとき、ログアウトが終了する。ログインおよびログアウトの目的は、端末のユーザ管理情報をサーバに提供することである。この情報は、サーバが視聴率統計値を作成し、端末の視聴行為を明確にする証拠として役立てることができる。
ユーザがチャネルにログインした後に、端末が、一定期間チャネルの番組が受信されるのを待たずに、サービスＩＤおよびユーザＩＤなどのユーザ管理情報をサーバに直接送信することができる。前述の事例では、ユーザ管理情報は、チャネル情報、すなわちチャネルＩＤを含まない。端末が番組からログアウトした後に、端末はサービスＩＤ、チャネルＩＤ、およびユーザＩＤなどのユーザ管理情報をサーバに送信することができる。そのとき、ログアウトが終了する。
端末のユーザ管理情報を得た後に、サーバはまた、受け取ったユーザ管理情報を処理することもでき、この処理は、ユーザのログイン状態情報を記録する操作、ユーザが見る番組の状態情報を記録する操作、およびユーザが更新する必要があるサービス情報を記録する操作のうちの少なくとも１つを含み、
ユーザログイン状態情報は、端末ＩＤ、ユーザＩＤ、サービス申し込み関係、ログイン時間、ログイン方式、およびユーザキー有効期間のうちの少なくとも１つを含み、ユーザが見る番組の状態情報は、ユーザが見る番組のＩＤ、ユーザが見るチャネルのＩＤ、ユーザがそのチャネルを見始める時間、およびユーザがそのチャネルからログアウトする時間のうちの少なくとも１つを含み、ユーザが更新する必要のあるサービス情報は、ユーザキーが更新される必要があるかどうか、ユーザの対話情報が更新される必要があるかどうか、およびユーザのＳＧが更新される必要があるかどうかのうちの少なくとも１つを含む。
端末のユーザ管理情報を得た後に、サーバはまた、ユーザ管理情報で運ばれるメッセージが送信されたときの時間、またはサーバが、番組の最初のフレームまたは最後のフレームを端末に送信したときの時間に従って、チャネルの番組を見ている時間を得ることもできる。
端末のユーザ管理情報を得た後に、サーバはまた、チャネルまたは番組の視聴率を得ることもできる。チャネルまたは番組の視聴率を得る処理は、統計のもとでチャネルまたは番組のＩＤを設定するステップと、チャネルまたは番組のコンテンツを受信するときに、またはそれからログアウトするときに端末が送信するメッセージを受信するステップと、そのメッセージに従ってチャネルまたは番組の視聴率を得るステップとを含んでもよい。チャネルまたは番組の視聴率を得る処理はまた、すべての端末、または指定された端末に、指定されたチャネルまたは番組を見るべきかどうかに関するメッセージを送信するステップと、指定されたチャネルまたは番組を見ている端末からの応答を受信するステップと、その応答に従ってチャネルまたは番組の視聴率を得るステップとを含むことがある。
端末が番組チャネルにログインするとき、及び視聴した番組からログアウトするときに、サーバによりユーザ管理情報を得る方法を、本発明の第２の実施形態が提供する。ユーザ管理情報は、メッセージ型ＩＤ、メッセージ送信時間、端末ＩＤ、サービスＩＤ、番組ＩＤ、端末のオンライン状態またはオフライン状態、端末識別コード、ユーザＩＤ情報、およびチャネルＩＤのうちの、１つまたは複数を含む。メッセージ型ＩＤは、ログインメッセージＩＤ、およびログアウトメッセージＩＤを含む。チャネルを申し込んだ後に、端末はサーバにメッセージを何も送信しない。サーバは端末状態、ユーザ情報、および申し込まれたチャネルの更新詳細について何もわからない。したがって、この問題を解決する方法を提供しなければならない。この解決策は、端末がどのようにして番組を受信し、対話を行うかをサーバがさらに知る方法を提供する。
図２に示すように、この解決策の考え方は、端末ユーザが特定の時間に番組を見るときに、端末がその番組を放送するチャネルにログインすることがあるということにある。ログインするときに、端末は、サービスＩＤ、およびユーザＩＤなどのユーザ管理情報をサーバに送信することができる。ユーザ管理情報は、複数の方式でサーバに送信されてもよい。サーバは、ユーザ管理情報を記憶し、受信したメッセージに応答することができる。端末が、受信した番組からログアウトした後に、以下のようにサーバと対話する。すなわち、端末は、サービスＩＤ、チャネルＩＤ、およびユーザＩＤなどのログアウトの場合のユーザ管理情報をサーバに送信する。サーバは、ユーザ管理情報に従って、端末がログインする番組の保存された全詳細を記録する。
図２に示すように、この処理は以下のステップを含む。
Ｓ２０１． 端末が起動され、サーバにＬｏｇＩｎＩｎｆｏメッセージを送信する。
ＬｏｇＩｎＩｎｆｏメッセージの内容を以下に列挙する。
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\Desktop\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"/>
この実施形態では、ＬｏｇＩｎＩｎｆｏメッセージが、拡張可能なマーク付け言語（ＸＭＬ）形式でメッセージボディとしてハイパテキスト転送プロトコル（ＨＴＴＰ）ＰＯＳＴヘッダの後ろに追加され、サーバに送信される。メッセージヘッダは、＜ＣＲ＞シンボル入力によりメッセージボディと分離される。上の部分がメッセージヘッダで、下の部分がメッセージボディである。メッセージヘッダは、要求されたホストおよびポートを記述する。接続状態が「クローズ」のときに、連続して接続する必要はない。ＨＴＴＰ１．１は不連続接続をサポートする。
ＬｏｇＩｎＩｎｆｏメッセージは、サービスＩＤ、ユーザＩＤ（たとえば、国際移動加入者識別番号（ＩＭＳＩ）情報）、および他のユーザ管理情報を含む。端末のＬｏｇＩｎＩｎｆｏメッセージは図２に示す形式を使用することがある。ＬｏｇＩｎＩｎｆｏメッセージは、対話型チャネルを使用して送信される。ＬｏｇＩｎＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。この実施形態では、ＬｏｇＩｎＩｎｆｏメッセージはＨＴＭＬ形式でサーバに送信される。
ＬｏｇＩｎＩｎｆｏメッセージは、たとえばＨＴＴＰ ＰＯＳＴ方法など、複数の方法により送信されることがある。これは一例にすぎない。他の方法が利用可能な場合でも、その原理および考え方は同じである。
端末が起動されたときに、端末がサーバにＬｏｇＩｎＩｎｆｏメッセージを報告する。一方、サーバはユーザ状態をオンラインに設定する。端末は、ＳＧ、および他の関連データをサーバから得る。サーバ内の関連データが更新されたときに、サーバは更新データをオンラインユーザに通知することができ、その通知はオンライン端末にプッシュされることもある。この場合、端末はサーバ内のデータ変更を知り、そのデータを即座に取り出すことができる。
Ｓ２０２． 端末がＳＧを得る。
モバイルＴＶ端末は、端末が既にサーバに登録され、かつ既に起動されて、チャネルの番組にログインしているときだけ、チャネルの番組を受信することができる。
Ｓ２０３． 申し込み済みのチャネルのない端末は、得たＳＧに従ってチャネルを申し込む。
所定の申し込み関係が、ユーザがＳＧで申し込むチャネルを示す。それは、端末と同期をとるためにサーバ内に表の形式で記憶されることがある。
Ａ． 申し込み方式は、外部方式でもよい。たとえば、ネットワークからのアクセス、または電話からのダイヤルアップにより申し込みが行われることがある。申し込み結果はサーバ内に記録されることがある。
Ｂ． 申し込み方式は、内部方式でもよい。ＳＧで端末が申し込みを行うことがある。端末がチャネルに申し込む、またはチャネルの申し込みを取り消すときに、サーバ内の申し込み関係表を変更し、端末と同期させることができる。
Ｃ． サーバは端末と申し込み関係を同期させることができる。端末が起動したときに、またはサーバの方針に従い定期的に、サーバはオンラインユーザと申し込み関係を同期させることができる。申し込み関係は、端末により保持されることも、サーバと同期をとられることもある。ユーザが申し込みを実行したときに、ローカルの申し込み関係がＨＴＴＰ ＰＯＳＴ方式でサーバに送信されて、サーバと同期することができる。
チャネルにログインした後に、ユーザはＳＧを受信することができる。ＳＧにはチャネルコンテンツの予報がある。端末はＳＧを介してチャネルリストを得て、チャネルリスト内のチャネルに従って番組コンテンツを受信することができる。
端末が放送方式で番組コンテンツを受信する場合、受信したＳＧに従って所望のチャネルを選択する。ユーザ端末がＳＧ内のチャネルＩＤを選択した後に、端末は番組を受信し始める。
Ｓ２０４． サーバが番組コンテンツを端末に送信する。
サーバはコンテンツを放送方式で送信することも、ストリーミング方式で送信することもある。
端末が一定期間（１分に設定されていることもある）、番組コンテンツを受信した後に、ログアウトしない場合、その情報がサーバに送信される。サーバは端末のログイン時間を記録することができる。
チャネルにログインした後に、端末は現在の状態情報をローカルに記録する必要がある。ネットワークまたはコンテンツ提供業者（ＣＰ）が、指定された時間を前もってセットすることができる。端末はこの時間を使用して、サーバに統計値情報を送信すべきかどうか判断する。端末のチャネルログイン時間が前もってセットされた時間を超過した場合、ユーザは番組を見ている。前もってセットされた時間内に端末がチャネルからログアウトする場合、ユーザはチャネルの番組を見ていない。
Ｓ２０５． サーバが端末を認証する。
認証メッセージの内容を以下に列挙する。
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/5.1
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
<CR>
端末からＰＯＳＴメッセージを受信した後に、サーバはチャレンジをその端末に送信することによりその端末を認証する必要がある。チャレンジを送信することは、クライアントにＨＴＴＰレスポンスを与えることであり、このレスポンスの状態コードは４０１（非認証）であり、このレスポンスはメッセージヘッダＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅを運ぶ。クライアントはＨＴＴＰレスポンスを受信したときに、ＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）が認証される必要があることがわかる。
ドメイン： ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）リストであり、保護されるべきドメインを示す。それはリストのことであり、これらのＵＲＩが同じ方法で認証されるべきであることをユーザに伝える。ドメインフィールドが存在しない、または無視される場合、サーバ内のすべてのＵＲＩが認証される必要がある。
ｎｏｎｃｅ： ランダム文字列であり、毎回変わる。ｎｏｎｃｅフィールドは、アルゴリズムと関連がある。本アルゴリズムはＢａｓｅ６４暗号化に似ている。すなわち、ｔｉｍｅ−ｓｔａｍｐ Ｈ（ｔｉｍｅ−ｓｔａｍｐ”：”ＥＴａｇ”：”ｐｒｉｖａｔｅ−ｋｅｙ）であり、ここで、ｔｉｍｅ−ｓｔａｍｐはサーバクロックであり、ＥＴａｇは要求されたＥｔａｇヘッダである。
ｏｐａｑｕｅ： サーバにより生成され、クライアントにより送信された要求と共に送り返される。ｏｐａｑｕｅフィールドは、Ｂａｓｅ６４ストリング、または１６進文字列である。ｒｅａｌｍ値は、大文字と小文字を識別する文字列であり、両側に引用符を伴い、認証されるべきｒｅａｌｍを示す。ｒｅａｌｍは、サーバにより決定される。様々なサーバが自分のｒｅａｌｍを設定することがある。１つのサーバが、複数のｒｅａｌｍを持つこともある。チャレンジにｒｅａｌｍ情報を含む目的は、クライアントにどの範囲のユーザ名が合法かをわからせることである。サーバが端末を認証するために使用するメッセージは、メッセージボディを運ばないこともある。
端末ユーザのＩＤを得るには、その端末ユーザがチャネルにログインしたときに、または番組またはチャネルを切り換えたときに、サーバがその端末を認証する必要がある。ユーザ登録の場合に行われる認証とは異なり、この認証は、番組を見ているユーザがログインユーザであることを保証することができ、したがって、視聴率統計値の客観性を保証する。たとえば、ＨＴＴＰダイジェスト認証などの様々な認証方式を利用することが可能である。
サーバがユーザからＬｏｇＩｎＩｎｆｏメッセージを受信した後に、ユーザが認証されなければならない。その結果、番組にログインするユーザのＩＤ、およびＬｏｇＩｎＩｎｆｏメッセージの妥当性が判断され、その後、ＬｏｇＩｎＩｎｆｏメッセージがデータベースに書き込まれる。ユーザは、ＬｏｇＩｎＩｎｆｏメッセージを送信しているときに、彼／彼女が認証されることになるかどうかわからない。したがって、サーバは、ＬｏｇＩｎＩｎｆｏメッセージを受信しているときに、チャレンジを運ぶＨＴＴＰ ４０１メッセージを送信することがある。この場合、チャレンジは、暗号化方式でサーバに送信されるべき、ユーザ名およびパスワードなどの関連する認証情報を必要とする。
Ｓ２０６． 端末が認証レスポンスをサーバに送信する。
レスポンスの内容を以下に列挙する。
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce=" dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/xxx/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
チャレンジメッセージを受信した後に、端末は自身のユーザ名およびパスワード、ならびにチャレンジメッセージを暗号化し、次に、暗号化された情報をサーバに送信することができる。これにより、パスワードを平文で送信する必要性をなくすことができる。
認証が成功した後に、サーバは端末から受信したメッセージを保存する。端末が認証に失敗した場合、ユーザは番組を見続けることができるが、そのＬｏｇＩｎＩｎｆｏはサーバの統計値に有効ではない。
Ｓ２０１からＳ２０６までは、標準的なＨＴＴＰダイジェスト認証方式であり、その各フィールドがＲＦＣ２６１７で定義されている。このダイジェスト認証方式は一例でしかない。
Ｓ２０７． サーバが２００ ＯＫメッセージを端末に送信する。
端末のユーザ名およびパスワードが、サーバにより認証成功した場合、サーバは２００ ＯＫメッセージを端末に送信する。この実施形態では、ＨＴＴＰ方式に基づいている。したがって、２００ ＯＫは、認証が成功したことを示す。
Ｓ２０８． サーバが番組コンテンツを端末に送信する。
端末が、チャネルにログインした後に、チャネルからログアウトせずに、指定された時間内に番組コンテンツを受信し続ける場合、サーバは番組コンテンツを放送方式で送信することも、他の方式で送信することもある。サーバが番組コンテンツを放送方式で送信する場合、端末はコンテンツをチャネルの放送から受信する。他の方式（たとえば、ストリーミング）を使用する場合、サーバはコンテンツを端末とのリンク上に送信する。ストリーミング方式では、サーバはユニキャストまたはマルチキャストにより番組コンテンツを送信することができる。
Ｓ２０９． 端末が現在の番組からログアウトする。
ログアウトメッセージの内容を以下に列挙する。
Http/1.1 200OK
Server:Microsoft-IIS/5.0
Date:Sat,20Jul200720:31:22GMT
Accept-Ranges:bytes
Content-Length: 1205
Content-Type:text/html
Options:Post
LogInInfo
ユーザは現在の番組からいつでもログアウトすることができる。すなわち、ユーザは現在の番組から番組が終了したときにログアウトすることも、番組の最中にログアウトすることもある。ユーザがログアウトするときに、端末が状態メッセージをサーバに送信するようトリガされることがある。
Ｓ２１０． 端末がＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信する。
ＬｏｇＯｕｔＩｎｆｏメッセージの内容を以下に列挙する。
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\Desktop\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"/>
この実施形態では、ＨＴＴＰ ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、ステップ４での意味と同じである。ＬｏｇＯｕｔＩｎｆｏメッセージ中のＸＭＬデータは、メッセージボディにある。
ＬｏｇＯｕｔＩｎｆｏメッセージは、サービスＩＤおよびユーザＩＤを運ぶ。サーバは端末のログアウト時間、すなわち終了時間を記録する。端末のＬｏｇＯｕｔＩｎｆｏメッセージは、図３に示す形式を使用することがある。このメッセージは対話型チャネルを介して送信される。ＬｏｇＯｕｔＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。
ＬｏｇＯｕｔＩｎｆｏメッセージをＨＴＴＰ方式でサーバに送信することもある。このときに、サーバはＬｏｇＯｕｔＩｎｆｏメッセージを処理し、それをデータベースに追加する。ＬｏｇＯｕｔＩｎｆｏメッセージはまた、ショート・メッセージ・サービス（ＳＭＳ）方式で送信されることも、他の方式で送信されることもある。ＨＴＴＰ ＰＯＳＴ方式は一例でしかなく、他のキャリア方式に置き換えることもできる。しかし、その原理および考え方は同じである。
Ｓ２１１． ＬｏｇＯｕｔＩｎｆｏメッセージを適切に受信した後に、サーバが２００ ＯＫメッセージを端末に送り返す。
２００ ＯＫメッセージを対話型チャネルにより送り返すことも、他の方式により送り返すこともある。この実施形態では、２００ ＯＫは、ＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信することに成功したことを示す。異なるネットワーク環境で、他の確認方式を使用することもできるが、その考え方および原理は同じである。
Ｓ２１２． 端末が番組からログアウトした後に、サーバがその端末の状態情報を記憶する。
サーバは、端末から報告されたＬｏｇＩｎＩｎｆｏ状態情報、およびＬｏｇＯｕｔＩｎｆｏ状態情報をローカルデータベース、または他のサーバに追加する。サーバは、必要とされるデータをＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージから得る。サーバは、そのようなデータに従って、端末の申し込み、および端末が見た番組についての一般的な理解を得る。サーバのデータベース内に記憶された状態情報は、表４と同じこともあれば、似ていることもある。
移動端末を使用することによりユーザがチャネルの番組を受信するときに、より良い方法は、ＳＧを介してチャネルリストを表示することである。この場合、端末はチャネルを選択し、見ることができる。端末がＳＧに示されるチャネルリスト内のチャネルにログインするときに、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含む現在のユーザ管理情報を記録することができる。端末が一定期間（たとえば、１分）チャネルの番組にログインするときには、ユーザはその番組を見ている。この場合、端末はユーザ管理情報をサーバに送信する必要がある。端末がチャネルまたは番組からログアウトするときに、端末は、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含むログアウトの場合のユーザ管理情報を記録することができる。サーバは対話型サーバのことも、端末情報を記録するための特別なサーバのこともある。
たとえば、ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージが、以下の表１に示すデータ構造を使用することもある。
Figure 2010541345
ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージは必須である。方向は端末からサーバである。
表２、および表３はそれぞれＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージのデータ構造要素を示す。
Figure 2010541345
Figure 2010541345
スキーマにより表されたデータ構造を以下に示す。
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY 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"/>
<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: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>
上記のメッセージが端末によりサーバに送信され、サーバにより記憶される。記録すべき状態情報を記憶するように、データ構造をサーバ内で表４に示すように構成することもできる。
Figure 2010541345
データ構造のスキーマを以下に示す。
<?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>
上表では、一部のデータが、サーバ内に記憶される情報コンテンツを示すようにシミュレートされている。この例では、各ユーザには固有のユーザＩＤがあり、異なるチャネルには異なるサービスＩＤがある。たとえば、上表では、ユーザＩＤ０１２３４を有するユーザ、およびユーザＩＤ０２４６２を有するユーザが、サービスＩＤ０１を有する同じチャネルを見ている。彼らはまた、番組ＩＤ０１１を有する同じ番組も見ている。彼らは、この番組を、それぞれ午前１０：５０、および午前１０：２０に見始めている。ユーザＩＤ５５２０８を有するユーザ、およびユーザＩＤ４９６５３を有するユーザが、サービスＩＤ０２を有するチャネルを見ており、これは、彼らが番組ＩＤ０２１を有する同じ番組を見ていることも示す。しかし、前者のユーザはその番組を１２：０５に見始めており、一方で、後者のユーザはその番組を１２：１５に見始めている。この番組が終了した後に、両方のユーザが見るのを止めている。したがって、両方のユーザの終了時間が１２：２５となっている。
サーバは、様々な形式で記録を記憶することができる。この解決策では、一例を示したにすぎない。統計値データはまた、他のデータ構造で構成することもできるが、その考え方および方法は同じである。
表４では、チャネルがサーバに関連付けられている。１つのチャネルにはある時点に１つの番組しかない。サーバＩＤおよび番組ＩＤはＣＰにより指定される。１つのチャネルはまた、一定期間内に１つの番組しかユーザに提供することができない。ユーザＩＤ、サービスＩＤ、番組ＩＤ、終了時間、および開始時間などの属性は、端末が見る番組の状態情報の例でしかなく、必要なときには変更され、拡張されることがある。
この実施形態では、サーバは対話型サーバであることも、統計値情報を記憶するための特別なサーバであることもある。この実施形態では、メッセージ内容はほとんどなく、データの統計値を容易に作成することができ、それにより、サーバ負荷が減る。さらに、サーバが一定数のユーザをサポートすることができる場合、そのような統計値を追加することで、サーバがサポートするユーザ数は変わらない。
この実施形態では、ユーザ管理情報の伝送に関与するＬｏｇＩｎＩｎｆｏメッセージおよびＬｏｇＯｕｔＩｎｆｏメッセージは、例でしかない。メッセージの形で状態情報を運ぶ他の同様の方法もまた、状態情報を伝送するために使用することができるが、その原理および考え方は同じである。
端末が番組にログインし、その番組からログアウトするときに、ユーザ管理情報をサーバに送信し、ユーザ管理情報に従ってサーバにより番組の統計値、またはユーザの好みの統計値を作成するための方法を本発明の第３の実施形態が提供する。この方法を用い、サーバは、端末が見た番組およびチャネルに関する詳細をさらに知ることができる。
図３に示すように、端末ユーザが、あるときに、ある番組を見るときに、端末は、その番組が配置されているチャネルにログインすることができる。端末が一定の期間、番組を受信するときに、サービスＩＤ、番組ＩＤ、ユーザＩＤ、およびチャネルＩＤなどの、端末のユーザ管理情報をサーバに送信することができる。ユーザ管理情報は、メッセージの形でサーバに送信されることがある。サーバはローカルの方針に従って、端末の受信したユーザ管理情報を記憶するべきかどうか判断し、応答を渡すことができる。受信した番組からログアウトした後に、端末はサーバと以下のように対話することがある。すなわち、端末が、サービスＩＤ、番組ＩＤ、ユーザＩＤ、およびチャネルＩＤなどの、ログアウトの場合のユーザ管理情報をサーバに送信する。
サーバは、ユーザ管理情報に従って、端末がログインする、記憶された番組の統計値を作成する。
サーバは、端末の記録されたログイン時間およびログアウト時間に従って、ユーザの番組ログイン総期間を計算することができる。サーバはまた、ユーザＩＤ、サービスＩＤ、番組ＩＤ、およびチャネルＩＤに従って、最高視聴率のチャネルおよび番組を計算により明らかにすることもできる。
そのような統計値に従って、サーバは、より多くのネットワーク資源を最高視聴率のチャネルおよび番組に追加して、番組を見る品質を保証することができる。ＣＰはまた、そのような統計値に従ってチャネルおよび番組を調整することができる。たとえば、ＣＰは、最高視聴率の番組をより長い時間放送することも、ユーザの興味に従って番組を制作することもある。
図３に示すように、この処理は以下のステップを含む。
Ｓ３０１． 端末が起動され、ＳＧを得る。
端末が既にサーバに登録され、かつ既に活性化されて、チャネルの番組にログインしているときだけ、モバイルＴＶ端末はチャネルの番組を受信することができる。
Ｓ３０２． 申し込み済みのチャネルのない端末は、得たＳＧに従ってチャネルを再び申し込む。
所定の申し込み関係が、ユーザがＳＧで申し込むチャネルを示す。それは、端末と同期をとるためにサーバ内に表の形式で記憶されることがある。
Ａ． 申し込み方式は、外部方式でもよい。たとえば、ネットワークからのアクセス、または電話からのダイヤルアップにより申し込みが行われることがある。申し込み結果はサーバ内に記録されることがある。
Ｂ． 申し込み方式は、内部方式でもよい。ＳＧで端末が申し込みを行うことがある。端末がチャネルに申し込む、またはチャネルの申し込みを取り消すときに、サーバ内の申し込み関係表を変更し、端末と同期させることができる。
Ｃ． サーバは端末と申し込み関係を同期させることができる。端末が起動したときに、またはサーバの方針に従い定期的に、サーバはオンラインユーザと申し込み関係を同期させることができる。申し込み関係は、端末により保持されることも、サーバと同期をとられることもある。ユーザが申し込みを実行したときに、ローカルの申し込み関係がＨＴＴＰ ＰＯＳＴ方式でサーバに送信されて、サーバと同期することができる。
チャネルにログインした後に、ユーザはＳＧを受信することができる。ＳＧにはチャネルコンテンツの予報がある。端末はＳＧを介してチャネルリストを得て、チャネルリスト内のチャネルに従って番組コンテンツを受信することができる。
端末が放送方式で番組コンテンツを受信する場合、その端末は受信したＳＧに従って所望のチャネルを選択する。ユーザ端末がＳＧ内のチャネルＩＤを選択した後に、端末は番組を受信し始める。
Ｓ３０３． サーバが番組コンテンツを端末に送信する。
サーバはコンテンツを放送方式で送信することも、ストリーミング方式で送信することもある。
番組コンテンツを受信した後に、端末が一定期間（１分に設定されていることもある）、ログアウトしない場合、その情報がサーバに送信される。サーバは端末のログイン時間を記録することができる。
チャネルにログインした後に、端末は現在のユーザ管理情報をローカルに記録する必要がある。指定された時間がネットワークまたはＣＰにより前もってセットされることがある。端末はこの時間を使用して、サーバに統計値情報を送信すべきかどうか判断する。端末のチャネルログイン時間が前もってセットされた時間を超過する場合、ユーザは番組を見ている。前もってセットされた時間以内に端末がチャネルからログアウトする場合、ユーザはチャネルの番組を見ていない。
Ｓ３０４． 端末がサーバにＬｏｇＩｎＩｎｆｏメッセージを送信する。
ＬｏｇＩｎＩｎｆｏメッセージの内容を以下に列挙する。
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\Desktop\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"/>
この実施形態では、ＬｏｇＩｎＩｎｆｏメッセージが、ＸＭＬ形式でメッセージボディとしてＨＴＴＰ ＰＯＳＴヘッダの後ろに追加され、サーバに送信される。メッセージヘッダは、＜ＣＲ＞シンボル入力によりメッセージボディと分離される。上の部分がメッセージヘッダで、下の部分がメッセージボディである。メッセージヘッダは、要求されたホストおよびポートを記述する。接続状態が「クローズ」のときに、連続して接続する必要はない。ＨＴＴＰ１．１は不連続接続をサポートする。
ＬｏｇＩｎＩｎｆｏメッセージは、サービスＩＤ、ユーザＩＤ（たとえば、ＩＭＳＩ情報）、および他のログイン状態情報を運ぶ。端末のＬｏｇＩｎＩｎｆｏメッセージは図２に示す形式を使用することがある。ＬｏｇＩｎＩｎｆｏメッセージは、対話型チャネルを使用して送信される。ＬｏｇＩｎＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。この実施形態では、ＬｏｇＩｎＩｎｆｏメッセージはＨＴＭＬ形式でサーバに送信される。
ＬｏｇＩｎＩｎｆｏメッセージは、たとえばＨＴＴＰ ＰＯＳＴ方法など、複数の方法により送信されることがある。これは一例にすぎない。他の方法が利用可能な場合でも、その原理および考え方は同じである。
端末が一定期間、番組を受信するときに、サーバにＬｏｇＩｎＩｎｆｏメッセージを報告することができる。一方、サーバはユーザ状態をオンラインに設定する。端末は、ＳＧ、および他の関連データをサーバから得る。サーバ内の関連データが更新されたときに、サーバは更新データをオンラインユーザに通知することができ、その通知はオンライン端末にプッシュされることもある。この場合、端末はサーバ内のデータ変更を知り、そのデータを即座に取り出すことができる。
Ｓ３０５． サーバが端末を認証する。
認証メッセージの内容を以下に列挙する。
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/5.1
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
<CR>
端末からＰＯＳＴメッセージを受信した後に、サーバはチャレンジをその端末に送信することによりその端末を認証する必要がある。チャレンジを送信することは、クライアントにＨＴＴＰレスポンスを与えることであり、このレスポンスの状態コードは４０１（非認証）であり、このレスポンスはメッセージヘッダＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅを運ぶ。クライアントは、ＨＴＴＰレスポンスを受信したときに、ＵＲＩが認証される必要があることがわかる。
ドメイン： ＵＲＩリストであり、保護されるべきドメインを示す。それはリストのことであり、これらのＵＲＩが同じ方法で認証されるべきであることをユーザに伝える。ドメインフィールドが存在しない、または無視される場合、サーバ内のすべてのＵＲＩが認証される必要がある。
ｎｏｎｃｅ： ランダム文字列であり、毎回変わる。ｎｏｎｃｅフィールドは、アルゴリズムと関連がある。本アルゴリズムはＢａｓｅ６４暗号化に似ている。すなわち、ｔｉｍｅ−ｓｔａｍｐ Ｈ（ｔｉｍｅ−ｓｔａｍｐ”：”ＥＴａｇ”：”ｐｒｉｖａｔｅ−ｋｅｙ）であり、ここで、ｔｉｍｅ−ｓｔａｍｐはサーバクロックであり、ＥＴａｇは要求されたＥｔａｇヘッダである。
ｏｐａｑｕｅ： サーバにより生成され、クライアントにより送信された要求と共に送り返される。ｏｐａｑｕｅフィールドは、Ｂａｓｅ６４ストリング、または１６進文字列である。ｒｅａｌｍ値は、大文字と小文字を識別する文字列であり、両側に引用符を伴い、認証されるべきｒｅａｌｍを示す。ｒｅａｌｍは、サーバにより決定される。様々なサーバが自分のｒｅａｌｍを設定することがある。１つのサーバが、複数のｒｅａｌｍを持つこともある。チャレンジにｒｅａｌｍ情報を含む目的は、クライアントにどの範囲のユーザ名が合法かをわからせることである。サーバが端末を認証するために使用するメッセージは、メッセージボディを運ばないこともある。
サーバは、チャネルにログインしている端末ユーザのＩＤを得るために、その端末を認証する必要がある。ユーザ登録の場合に行われる認証とは異なり、この認証は、番組を見ているユーザがログインユーザであることを保証することができ、したがって、視聴率統計値の客観性を保証する。たとえば、ＨＴＴＰダイジェスト認証などの様々な認証方式を利用することが可能である。
サーバがユーザからＬｏｇＩｎＩｎｆｏメッセージを受信した後に、ユーザが認証されなければならない。その結果、番組にログインするユーザのＩＤ、およびＬｏｇＩｎＩｎｆｏメッセージの妥当性が判断され、その後、ＬｏｇＩｎＩｎｆｏメッセージがデータベースに書き込まれる。ユーザは、ＬｏｇＩｎＩｎｆｏメッセージを送信しているときに、彼／彼女が認証されることになるかどうかわからない。したがって、サーバは、ＬｏｇＩｎＩｎｆｏメッセージを受信しているときに、チャレンジを運ぶＨＴＴＰ ４０１メッセージを送信することがある。この場合、チャレンジは、暗号化方式でサーバに送信されるべき、ユーザ名およびパスワードなどの関連する認証情報を必要とする。
Ｓ３０６． 端末が認証レスポンスをサーバに送信する。
レスポンスの内容を以下に列挙する。
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce=" dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/xxx/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
チャレンジメッセージを受信した後に、端末は自身のユーザ名およびパスワード、ならびにチャレンジメッセージを暗号化し、次に、暗号化された情報をサーバに送信することができる。これにより、パスワードを平文で送信する必要性をなくすことができる。
認証が成功した後に、サーバは端末から受信したメッセージを保存する。端末が認証に失敗した場合、ユーザは番組を見続けることができるが、そのＬｏｇＩｎＩｎｆｏはサーバの統計値に有効ではない。
Ｓ３０１からＳ３０６までは、標準的なＨＴＴＰダイジェスト認証方式であり、その各フィールドがＲＦＣ２６１７で定義されている。このダイジェスト認証方式は一例でしかない。
Ｓ３０７． サーバが２００ ＯＫメッセージを端末に送信する。
端末のユーザ名およびパスワードが、サーバにより認証成功した場合、サーバは２００ ＯＫメッセージを端末に送信する。この実施形態では、ＨＴＴＰ方式に基づいている。したがって、２００ ＯＫは、認証が成功したことを示す。
Ｓ３０８． サーバが番組コンテンツを端末に送信する。
端末が、チャネルにログインした後に、チャネルからログアウトせずに、指定された時間内に番組コンテンツを受信し続ける場合、サーバは番組コンテンツを放送方式で送信することも、他の方式で送信することもある。サーバが番組コンテンツを放送方式で送信する場合、端末はコンテンツをチャネルの放送から受信する。他の方式（たとえば、ストリーミング）を使用する場合、サーバはコンテンツを端末とのリンク上に送信することができる。ストリーミング方式では、サーバはユニキャストまたはマルチキャストにより番組コンテンツを送信することができる。
Ｓ３０９． 端末が現在の番組からログアウトする。
ユーザは現在の番組からいつでもログアウトすることができる。すなわち、ユーザは現在の番組から番組が終了したときにログアウトすることも、番組の最中にログアウトすることもある。ユーザが番組をログアウトするときに、端末が状態メッセージをサーバに送信するようトリガされることがある。
Ｓ３１０． 端末がＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信する。
ＬｏｇＯｕｔＩｎｆｏメッセージの内容を以下に列挙する。
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\Desktop\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"/>
この実施形態では、ＨＴＴＰ ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、ステップ４での意味と同じである。ＬｏｇＯｕｔＩｎｆｏメッセージ中のＸＭＬデータは、メッセージボディにある。
ＬｏｇＯｕｔＩｎｆｏメッセージは、サービスＩＤ、ユーザＩＤ、および現在のログアウト時間、すなわち終了時間を運ぶ。端末のＬｏｇＯｕｔＩｎｆｏメッセージは、図３に示す形式を使用することがある。このメッセージは対話型チャネルを介して送信される。ＬｏｇＯｕｔＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。
ＬｏｇＯｕｔＩｎｆｏメッセージをＨＴＴＰ方式でサーバに送信することもある。このときに、サーバはＬｏｇＯｕｔＩｎｆｏメッセージを処理し、それをデータベースに追加する。ＬｏｇＯｕｔＩｎｆｏメッセージはまた、ＳＭＳ方式で送信されることも、他の方式で送信されることもある。ＨＴＴＰ ＰＯＳＴ方式は一例でしかなく、他のキャリア方式に置き換えることもできる。しかし、その原理および考え方は同じである。
Ｓ３１１． ＬｏｇＯｕｔＩｎｆｏメッセージを適切に受信した後に、サーバが２００ ＯＫメッセージを端末に送り返す。
２００ ＯＫメッセージを対話型チャネルにより送り返すことも、他の方式により送り返すこともある。この実施形態では、２００ ＯＫは、ＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信することに成功したことを示す。異なるネットワーク環境で、他の確認方式を使用することもできるが、その考え方および原理は同じである。
Ｓ３１２． 端末が番組からログアウトした後に、サーバがその端末の状態情報を記憶し、統計値を作成する。
サーバは、端末から報告されたＬｏｇＩｎＩｎｆｏおよびＬｏｇＯｕｔＩｎｆｏの状態情報に従ってチャネルまたは番組の視聴率の統計値を作成する。
視聴率の統計値を作成する方法を２つ以下に記載する。
Ａ． ＳＧがチャネルＩＤを含むことがある。この場合、サーバが、ある時間区切り内でチャネルの視聴率の統計値を作成する必要があるときに、そのＳＧで統計値が作成されることを示すチャネルＩＤを設定する。たとえば、ＣＣＴＶ２ ｓｔａｔ＝ＴＲＵＥ ２００７−０８−０９ １２：００−１３：００は、２００７年８月９日の１２：００〜１３：００の時間区切り内にＣＣＴＶ２チャネルがあることを示す。ユーザがＣＣＴＶ２を選択する場合、そのチャネルを見ている、または見終わったことを示すメッセージをサーバに送る必要がある。それに基づいて、サーバが視聴率の統計値を作成する、または他の関連する統計値を作成する。
Ｂ． サーバが、オンラインユーザ端末のうちのすべて、または一部に、これらのユーザがそのチャネルを見ているかどうかフィードバックするよう彼らに要求するメッセージを送信する。ユーザ端末はこのメッセージに応答し、サーバの要求に対する返答を示す関連情報を運ぶ。この場合、関連データの統計値をサーバ内で作成することができる。
さらに、サーバが、ユーザの番組の好みについての統計値を作成することができる。サーバが、端末が番組を見るときの記録された開始時間および終了時間に従って、ユーザが番組を見た全期間を計算する。サーバは、様々な番組に応じて、どの番組ＩＤが大多数のユーザを伴っているか、およびどのサービスＩＤが大多数のユーザを伴っているかを、計算により明らかにすることができる。さらに、サーバは、ユーザがサーバ内に記憶する、以前のデータに従って、ユーザの好みについての統計値を作成し、どの番組ＩＤおよびサービスＩＤが大多数のユーザを伴っているかを明らかにすることができる。ＣＰは、そのデータに従ってユーザに月額料金サービスを提供することができる。ユーザがサーバ内に記憶する状態情報は、表８のものと似ていることがある。
移動端末を使用することによりユーザがチャネルの番組を受信するときに、より良い方法は、ＳＧを介してチャネルリストを表示することである。この場合、端末はチャネルを選択し、見ることができる。端末がＳＧに示されるチャネルリスト内のチャネルにログインするときに、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含む現在のユーザ管理情報を記録することができる。端末が一定期間（たとえば、１分）チャネルの番組にログインするときには、ユーザはその番組を見ている。この場合、端末はユーザ管理情報をサーバに送信する必要がある。端末がチャネルまたは番組からログアウトするときに、端末は、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含む、ログアウトの場合のユーザ管理情報を記録することができる。サーバは対話型サーバであることも、端末情報を記録するための特別なサーバであることもある。表５は、ＬｏｇＩｎＩｎｆｏメッセージおよびＬｏｇＯｕｔＩｎｆｏメッセージのデータ構造を示す。
Figure 2010541345
ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージは必須である。端末からサーバへの方向である。
表６、および表７は、ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージのデータ構造要素を示す。
Figure 2010541345
Figure 2010541345
スキーマにより表されたデータ構造を以下に示す。
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY 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"/>
<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: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>
上記のメッセージが端末によりサーバに送信され、サーバにより記憶される。記録すべき状態情報（ユーザ管理情報）を記憶するように、データ構造をサーバ内で構成することもできる。
Figure 2010541345
データ構造のスキーマを以下に示す。
<?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>
表８では、一部のデータが、サーバ内に記憶される情報コンテンツを示すようにシミュレートされている。この例では、各ユーザには固有のユーザＩＤがあり、異なるチャネルには異なるサービスＩＤがある。たとえば、上表では、ユーザＩＤ０１２３４を有するユーザ、およびユーザＩＤ０２４６２を有するユーザが、サービスＩＤ０１を有するチャネルを見ている。彼らはまた、番組ＩＤ０１１を有する同じ番組も見ている。彼らは、この番組を、それぞれ１０：５０、および１０：２０に見始めている。ユーザＩＤ５５２０８を有するユーザ、およびユーザＩＤ４９６５３を有するユーザが、サービスＩＤ０２を有するチャネルを見ている。彼らはまた、番組ＩＤ０２１を有する同じ番組を見ている。しかし、ユーザＩＤ５５２０８を有するユーザはその番組を１２：０５に見始めており、一方で、ユーザＩＤ４９６５３を有するユーザはその番組を１２：１５に見始めている。この番組が終了した後に、両方のユーザが見るのを止めている。したがって、両方のユーザの終了時間が１２：２５となっている。時間属性は、ユーザが番組を見ている期間を示す。表８は、ユーザＩＤ５５２０８を有するユーザが見ている期間が、ユーザＩＤ４９６５３を有するユーザの期間と同じであることを示している。
サーバは、様々な形式で記録を記憶することができる。この解決策では、一例を示したにすぎない。統計値データはまた、他のデータ構造で構成することもできるが、その考え方および方法は同じである。
表８では、チャネルがサーバに関連付けられている。１つのチャネルにはある時点に１つの番組しかない。サーバＩＤおよび番組ＩＤは番組ＣＰにより指定される。１つのチャネルはまた、一定期間内に１つの番組しかユーザに提供することができない。ユーザＩＤ、サービスＩＤ、番組ＩＤ、終了時間、および開始時間などの属性は、端末が見る番組の状態情報の例でしかなく、必要なときには変更され、拡張されることがある。
開始時間および終了時間は、サーバ内に記録された、端末のログイン時間およびログアウト時間を示す。開始時間および終了時間は、現在放送される番組コンテンツを端末が記録する期間を定義する。この期間の時間値は、開始時間と終了時間の差に等しく、ユーザが連続して番組を見ている継続時間を示す。各番組は、サーバによりパケットの形式でフレーム毎に端末に送信される。パケットの各フレームには、サーバにより追加されるタイムスタンプを有する。したがって、ログイン時間をパケットの最初のフレームから抽出することができ、ログアウト時間をパケットの最終フレームから抽出することができる。ログイン時間とログアウト時間の差が、端末のチャネルログイン継続時間である。パケットの時間は、ネットワーク時間であり、ネットワーク時間は端末のローカルタイムとは独立しており、サーバにより決定される。したがって、端末のローカルタイムは、端末のチャネルログイン継続時間に影響を及ぼさない。これは、ユーザが見ている時間の統計値には道理にかなっており、記録された時間が見ている時間であることを保証することができる。さらに、サーバは正確な統計値結果を得ることができる。
この実施形態では、サーバは対話型サーバであることも、統計値情報を記憶するための特別なサーバであることもある。この実施形態では、メッセージ内容はほとんどなく、データの統計値を容易に作成することができ、それにより、サーバ負荷が減る。さらに、サーバが一定数のユーザをサポートすることができる場合、そのような統計値を追加することで、サーバがサポートするユーザ数は変わらない。
この実施形態では、ユーザ管理情報（状態情報）の伝送に関与するＬｏｇＩｎＩｎｆｏメッセージおよびＬｏｇＯｕｔＩｎｆｏメッセージは、例でしかない。メッセージの形で状態情報を運ぶ他の同様の方法もまた、状態情報を伝送するために使用することができるが、その原理および考え方は同じである。
端末が番組にログインし、番組からログアウトするときのユーザ管理情報に従って、ユーザ管理情報をサーバに送信し、サーバにより端末との対話更新を完了するための方法を本発明の第４の実施形態が提供する。ユーザが、チャネルに申し込むことに成功した後に、たとえば、対話型の話題についての議論、および対話型ゲームなど、見ている過程の間に番組の対話に参加することがある。端末とサーバの間の対話更新により、ユーザが番組を見て、ローカルの端末で対話に参加することができるようにすることがある。
図３に示すように、端末が番組にログインするときに、サーバは、その番組が対話型の話題を含む場合、番組の対話情報を端末に送信することができる。番組を放送している間に対話情報が更新された場合、サーバは、端末の状態情報に従って、更新された対話情報を端末に送信することができる。一般に、対話型番組を見ている間に、対話情報を引き渡す、または更新することができる。対話情報を番組コンテンツと一緒に端末に引き渡すことができるが、対話情報の型は番組で常に同じである。したがって、ユーザは、番組の対話情報が更新される限り、対話型番組に連続して参加することができる。この場合、端末がサーバに送信する状態情報に従って、更新された対話情報を送信することができる。
図４に示すように、この処理は以下のステップを含む。
Ｓ４０１． 端末が起動され、ＬｏｇＩｎＩｎｆｏメッセージをサーバに送信する。
ＬｏｇＩｎＩｎｆｏメッセージの内容を以下に列挙する。
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\Desktop\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"/>
この実施形態では、ＬｏｇＩｎＩｎｆｏメッセージが、ＸＭＬ形式でメッセージボディとしてＨＴＴＰ ＰＯＳＴヘッダの後ろに追加され、サーバに送信される。メッセージヘッダは、＜ＣＲ＞シンボル入力によりメッセージボディと分離される。上の部分がメッセージヘッダで、下の部分がメッセージボディである。メッセージヘッダは、要求されたホストおよびポートを記述する。接続状態が「クローズ」のときに、連続して接続する必要はない。ＨＴＴＰ１．１は不連続接続をサポートする。
ＬｏｇＩｎＩｎｆｏメッセージは、サービスＩＤ、ユーザＩＤ（たとえば、ＩＭＳＩ情報）、および他のログイン状態情報を運ぶ。端末のＬｏｇＩｎＩｎｆｏメッセージは図２に示す形式を使用することがある。ＬｏｇＩｎＩｎｆｏメッセージは、対話型チャネルを使用して送信される。ＬｏｇＩｎＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。この実施形態では、ＬｏｇＩｎＩｎｆｏメッセージはＨＴＭＬ形式でサーバに送信される。
ＬｏｇＩｎＩｎｆｏメッセージは、たとえばＨＴＴＰ ＰＯＳＴ方法など、複数の方法により送信されることがある。これは一例にすぎない。他の方法が利用可能な場合でも、その原理および考えは同じである。
端末が起動されたときに、端末がサーバにＬｏｇＩｎＩｎｆｏメッセージを報告する。一方、サーバはユーザ状態をオンラインに設定する。端末は、ＳＧ、および他の関連データをサーバから得る。サーバ内の関連データが更新されたときに、サーバは更新データをオンラインユーザに通知することができ、その通知はオンライン端末にプッシュされることもある。この場合、端末はサーバ内のデータ変更を知り、そのデータを即座に取り出すことができる。
Ｓ４０２． 端末がＳＧを得る。
モバイルＴＶ端末は、端末が既にサーバに登録され、かつ既に起動されて、チャネルの番組にログインしているときだけ、チャネルの番組を受信することができる。
Ｓ４０３． 申し込み済みのチャネルのない端末は、得たＳＧに従ってチャネルを申し込む。
所定の申し込み関係が、ユーザがＳＧで申し込むチャネルを示す。それは、端末と同期をとるためにサーバ内に表の形式で記憶されることがある。
Ａ． 申し込み方式は、外部方式でもよい。たとえば、ネットワークからのアクセス、または電話からのダイヤルアップにより申し込みが行われることがある。申し込み結果はサーバ内に記録されることがある。
Ｂ． 申し込み方式は、内部方式でもよい。ＳＧで端末が申し込みを行うことがある。端末がチャネルに申し込む、またはチャネルの申し込みを取り消すときに、サーバ内の申し込み関係表を変更し、端末と同期させることができる。
Ｃ． サーバは端末と申し込み関係を同期させることができる。端末が起動したときに、またはサーバの方針に従い定期的に、サーバはオンラインユーザと申し込み関係を同期させることができる。申し込み関係は、端末により保持され、かつサーバと同期をとられることがある。ユーザが申し込みを実行したときに、ローカルの申し込み関係がＨＴＴＰ ＰＯＳＴ方式でサーバに送信されて、サーバと同期することができる。
チャネルにログインした後に、ユーザはＳＧを受信することができる。ＳＧにはチャネルコンテンツの予報がある。端末はＳＧを介してチャネルリストを得て、チャネルリスト内のチャネルに従って番組コンテンツを受信することができる。
端末が放送方式で番組コンテンツを受信する場合、受信したＳＧに従って所望のチャネルを選択する。ユーザ端末がＳＧ内のチャネルＩＤを選択した後に、端末は番組を受信し始める。
Ｓ４０４． サーバが番組コンテンツを端末に送信する。
サーバはコンテンツを放送方式で送信することも、ストリーミング方式で送信することもある。
端末が一定期間（１分に設定されていることもある）、番組コンテンツを受信した後に、ログアウトしない場合、その情報がサーバに送信される。サーバは端末のログイン時間を記録することができる。
チャネルにログインした後に、端末は現在の状態情報をローカルに記録する必要がある。一定期間がネットワークまたはＣＰにより前もってセットされることがある。端末はこの時間を使用して、サーバに統計値情報を送信すべきかどうか判断する。端末のチャネルログイン時間が前もってセットされた時間を超過した場合、ユーザは番組を見ている。前もってセットされた時間内に端末がチャネルからログアウトする場合、ユーザはチャネルの番組を見ていない。
Ｓ４０５． サーバが端末を認証する。
認証メッセージの内容を以下に列挙する。
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/5.1
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
<CR>
端末からＰＯＳＴメッセージを受信した後に、サーバはチャレンジをその端末に送信することによりその端末を認証する必要がある。チャレンジを送信することは、クライアントにＨＴＴＰレスポンスを与えることであり、このレスポンスの状態コードは４０１（非認証）であり、このレスポンスはメッセージヘッダＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅを運ぶ。クライアントはＨＴＴＰレスポンスを受信したときに、ＵＲＩが認証される必要があることがわかる。
ドメイン： ＵＲＩリストであり、保護されるべきドメインを示す。それはリストのことがあり、これらのＵＲＩが同じ方法で認証されるべきであることをユーザに伝える。ドメインフィールドが存在しない、または無視される場合、サーバ内のすべてのＵＲＩが認証される必要がある。
ｎｏｎｃｅ： ランダム文字列であり、毎回変わる。ｎｏｎｃｅフィールドは、アルゴリズムと関連がある。本アルゴリズムはＢａｓｅ６４暗号化に似ている。すなわち、ｔｉｍｅ−ｓｔａｍｐ Ｈ（ｔｉｍｅ−ｓｔａｍｐ”：”ＥＴａｇ”：”ｐｒｉｖａｔｅ−ｋｅｙ）であり、ここで、ｔｉｍｅ−ｓｔａｍｐはサーバクロックであり、ＥＴａｇは要求されたＥｔａｇヘッダである。
ｏｐａｑｕｅ： サーバにより生成され、クライアントにより送信された要求と共に送り返される。ｏｐａｑｕｅフィールドは、Ｂａｓｅ６４ストリング、または１６進文字列である。ｒｅａｌｍ値は、大文字と小文字を識別する文字列であり、両側に引用符を伴い、認証されるべきｒｅａｌｍを示す。ｒｅａｌｍは、サーバにより決定される。様々なサーバが自分のｒｅａｌｍを設定することがある。１つのサーバが、複数のｒｅａｌｍを持つこともある。チャレンジにｒｅａｌｍ情報を含む目的は、クライアントにどの範囲のユーザ名が合法かをわからせることである。サーバが端末を認証するために使用するメッセージは、メッセージボディを運ばないこともある。
サーバは、チャネルにログインしている端末ユーザのＩＤを得るために、その端末を認証する必要がある。ユーザ登録の場合に行われる認証とは異なり、この認証は、番組を見ているユーザがログインユーザであることを保証することができ、したがって、視聴率統計値の客観性を保証する。たとえば、ＨＴＴＰダイジェスト認証などの様々な認証方式を利用することが可能である。
サーバがユーザからＬｏｇＩｎＩｎｆｏメッセージを受信した後に、ユーザが認証されなければならない。その結果、番組にログインするユーザのＩＤ、およびＬｏｇＩｎＩｎｆｏメッセージの妥当性が判断され、その後、ＬｏｇＩｎＩｎｆｏメッセージがデータベースに書き込まれる。ユーザは、ＬｏｇＩｎＩｎｆｏメッセージを送信しているときに、彼／彼女が認証されることになるかどうかわからない。したがって、サーバは、ＬｏｇＩｎＩｎｆｏメッセージを受信しているときに、チャレンジを運ぶＨＴＴＰ ４０１メッセージを送信することがある。この場合、チャレンジは、暗号化方式でサーバに送信されるべき、ユーザ名およびパスワードなどの関連する認証情報を必要とする。
Ｓ４０６． 端末が認証レスポンスをサーバに送信する。
レスポンスの内容を以下に列挙する。
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce=" dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/xxx/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
チャレンジメッセージを受信した後に、端末は自身のユーザ名およびパスワード、ならびにチャレンジメッセージを暗号化し、次に、暗号化された情報をサーバに送信することができる。これにより、パスワードを平文で送信する必要性をなくすことができる。
認証が成功した後に、サーバは端末から受信したメッセージを保存する。端末が認証に失敗した場合、ユーザは番組を見続けることができるが、そのＬｏｇＩｎＩｎｆｏは有効ではない。
Ｓ４０１からＳ４０６までは、標準的なＨＴＴＰダイジェスト認証方式であり、その各フィールドがＲＦＣ２６１７で定義されている。このダイジェスト認証方式は一例でしかない。
Ｓ４０７． サーバが２００ ＯＫメッセージを端末に送信する。
端末のユーザ名およびパスワードが、サーバによりうまく認証された場合、サーバは２００ ＯＫメッセージを端末に送信する。この実施形態では、ＨＴＴＰ方式に基づいている。したがって、２００ ＯＫは、認証が成功したことを示す。
Ｓ４０８． サーバが番組コンテンツ、および対話情報を端末に送信する。
端末が、チャネルにログインした後に、チャネルからログアウトせずに、指定された時間内に番組コンテンツを受信し続ける場合、サーバは番組コンテンツを放送方式で送信することも、他の方式で送信することもある。サーバが番組コンテンツを放送方式で送信する場合、端末はコンテンツをチャネルの放送から受信する。他の方式（たとえば、ストリーミング）を使用する場合、サーバはコンテンツを端末とのリンク上に送信する。ストリーミング方式では、サーバはユニキャストまたはマルチキャストにより番組コンテンツを送信することができる。
対話型メディア文書、およびその対話型メディアオブジェクトを番組コンテンツと一緒に引き渡すことも、ユーザが番組コンテンツを見る前に引き渡すこともできる。
Ｓ４０９． サーバが対話更新メッセージを端末に送信する。
対話型番組の対話情報が変更されたときに、サーバは更新された対話情報を端末に送信することができる。更新された対話情報を送信する前に、サーバは端末により報告されたＬｏｇＩｎＩｎｆｏ情報に従って、端末が見ている詳細（たとえば、チャネルＩＤおよびユーザＩＤ）を判断する必要がある。そのような情報を使い、サーバは、番組を見ているユーザに更新された対話情報をより正確に送信することができる。更新された対話情報を様々な方法で送信することができる。たとえば、それはメッセージボディの中で運ばれることも、短いメッセージにより送信されることもあるが、その原理および考え方は同じである。
Ｓ４１０では、端末ユーザが対話情報をサーバに送信する。
対話情報の内容を以下に列挙する。
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>
（ユーザ対話情報）
番組の放送過程の間に対話型の話題があるときに、ユーザは、番組の対話の目的を達成するために、ＨＴＴＰ ＰＯＳＴ方法を使用することにより、メッセージボディの形で彼／彼女の選択をサーバに送信することも、ＳＭＳ方式で彼／彼女の議論内容をサーバに送信することもある。ユーザは、メッセージを編集して、簡単な選択をする、または詳細な説明を提供することにより意見を述べることができる。これは、端末がサーバからその後の番組コンテンツを受信するのに影響を及ぼさない。したがって、対話期間に、ユーザは番組を中断することなく対話操作を実行することができる。
Ｓ４１１． サーバがユーザから対話情報を受信し、受信した対話情報を処理する。
ユーザから対話情報を受信した後に、対話型サーバが、その方針に従って、対話情報を即座に処理することも、番組が終了した後に処理することもある。対話型サーバは、ユーザの対話情報を抽出し、対話情報の内容に従って対話内容をユーザに送信することができる。たとえば、ユーザが、選択する対話型番組でＡ部分を選択するときに、対話型サーバはユーザの選択に従ってＡ部分を放送することができる。
Ｓ４１２． サーバが、完全に処理された対話結果を番組コンテンツと一緒に端末に送信する。
ユーザは、対話終了後に、サーバにより処理された対話統計値結果を即座に端末ユーザに送信することができ、その結果、端末ユーザは、対話結果、または対話型番組についての全ユーザの参加詳細を即座に知ることができる。したがって、送信される現在の対話結果が、個人の対話結果のことも、すべての参加者の対話結果のこともある。
対話型番組は、複数の対話処理を含むことがある。この実施形態では、破線が、送り返される参加結果を示し、その参加結果がユーザに送り返されることも、送り返されないこともあることを意味する。これは、対話型サーバおよび対話型番組の方針により決定される。
Ｓ４１３． 端末が現在の番組からログアウトする。
ユーザは現在の番組からいつでもログアウトすることができる。すなわち、ユーザは現在の番組から番組が終了したときにログアウトすることも、番組の最中にログアウトすることもある。ユーザがログアウトするときに、端末がサーバに状態メッセージを送信するようトリガされることがある。
Ｓ４１４． 端末がＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信する。
ＬｏｇＯｕｔＩｎｆｏメッセージの内容を以下に列挙する。
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\Desktop\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"/>
この実施形態では、ＨＴＴＰ ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、Ｓ４０４での意味と同じである。メッセージボディが、ＬｏｇＯｕｔＩｎｆｏメッセージのＸＭＬデータを含む。
ＬｏｇＯｕｔＩｎｆｏメッセージは、サービスＩＤおよびユーザＩＤを運ぶ。サーバは端末のログアウト時間、すなわち終了時間を記録する。端末のＬｏｇＯｕｔＩｎｆｏメッセージは、図７に示す形式を使用することがある。このメッセージは対話型チャネルを介して送信される。ＬｏｇＯｕｔＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。
ＬｏｇＯｕｔＩｎｆｏメッセージがＨＴＴＰ ＰＯＳＴ方式でサーバに送信されることもある。このときに、サーバはＬｏｇＯｕｔＩｎｆｏメッセージを処理し、それをデータベースに追加する。ＬｏｇＯｕｔＩｎｆｏメッセージはまた、ＳＭＳ方式で送信されることもある。ＨＴＴＰ ＰＯＳＴ方式は一例でしかなく、他のキャリア方式に置き換えることもできる。しかし、その原理および考え方は同じである。
Ｓ４１５． ＬｏｇＯｕｔＩｎｆｏメッセージを適切に受信した後に、サーバが２００ ＯＫメッセージを端末に送り返す。
２００ ＯＫメッセージは、対話型チャネルにより送り返されることも、他の方式によりを送り返されることもある。たとえば、サーバは、応答をピアツーピア方式で端末に送信することも、端末にプッシュすることもある。この実施形態では、２００ ＯＫメッセージは、ＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信することに成功したことを示す。異なるネットワーク環境で、他の確認方式を使用することもできるが、その考え方および原理は同じである。
Ｓ４１６． 端末が番組からログアウトした後に、サーバがユーザの対話情報を記憶し、対話型番組にユーザが参加した情報の統計値を作成する。
サーバは、ユーザが対話型番組を放送している間に送信する対話情報を記憶し、番組終了後にユーザの対話情報の統計値を作成する。最後に、サーバは、ユーザに統計結果をフィードバックすることがある。統計値の内容は、番組に参加した詳細であることも、番組の全対話結果であることもある。たとえば、選択的な対話型番組が終了した後に、対話型サーバが、Ａを選択する視聴者、およびＢを選択する視聴者を数えることができる。この例は、対話更新の結果および形式をより明確に説明することを意図している。
Ｓ４１７． サーバが対話型番組の最終的な統計値結果をユーザに送信する。
端末ユーザは、番組に参加した後に参加結果を得ることができる。この場合、参加結果は、その端末ユーザの参加結果、および番組全体の参加結果を含むことがある。この実施形態では、破線が最終結果の伝送を示し、これは、このステップが任意選択であることを意味する。
端末が、番組コンテンツを受信している間に対話型番組へのフィードバックを与え、ユーザが行う選択にサーバが応答し、したがって、対話更新が達成される。この実施形態で使用されるメッセージ運搬方式、およびメッセージ伝送方式を他の運搬方式および伝送方式に置き換えることができるが、その原理および考え方は同じである。
この実施形態では、端末が番組を見ている情報についての統計値を作成できるように、ＬｏｇＯｕｔＩｎｆｏメッセージおよびＬｏｇＩｎＩｎｆｏメッセージがサーバ内に記憶されることがある。そのデータ構造を、表８に似た表、または表８と同じ表の形で記憶することができる。表はサーバに記憶されることも、統計値結果を記録するための特別なデータベースに記憶されることもある。
モバイルＴＶサービスでのユーザ管理情報を得るためのシステムを本発明の第５の実施形態が提供する。図５に示すように、このシステムは、
ＳＧに含まれる選択番組を端末２０に提供し、認証に成功した後に、端末２０により選択された番組コンテンツを端末２０に送信し、端末２０のユーザ管理情報を記憶するように適合されたサーバ１０と、
起動された場合に、ユーザ管理情報をサーバ１０に送信するように適合された端末２０と
を含む。
具体的には、サーバ１０は、
端末２０から送信されたユーザ管理情報を受信するように適合された受信モジュール１１と、
番組を見ることを要求する端末２０を認証するように適合された認証モジュール１２と、
端末２０により選択された番組コンテンツを、認証モジュールにより認証された端末２０に送信するように適合された番組送信モジュール１３と、
受信モジュール１１内に記憶された内容に従って端末２０のユーザ管理情報を得るように適合された統計値モジュール１４と、
ＳＧに含まれる選択番組への端末の申し込み、またはその申し込み取り消しを受け入れ、申し込み結果、または申し込み取り消し結果に従って、端末２０のローカルの番組申し込み情報を更新するように適合された番組申し込みモジュール１５と、
対話型番組で端末２０との対話を実現するように適合された対話型番組処理モジュール１６と、
をさらに含む。
対話型番組処理モジュール１６は、
端末２０に伝送するための番組送信モジュールに対話情報、および／または対話更新情報を追加するように適合された対話情報追加サブモジュール１６１と、
対話情報追加サブモジュール１７１から送信される対話情報、および／または対話更新情報に従って、端末２０により送り返される対話情報応答を受信するように適合された対話応答受信サブモジュール１６２と、
対話応答受信サブモジュール１７２により受信された対話情報応答を処理し、端末２０の対話参加結果を得るように適合された対話結果取得サブモジュール１６３と
をさらに含む。
端末２０は、
ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュール２１と、
生成されたユーザ管理情報をメッセージの形で送信するように適合されたユーザ管理情報送信モジュール２２と、
をさらに含む。
前述の実施形態の説明を通じて、ソフトウェア、および必要な一般のハードウェアプラットフォームにより、またはハードウェアだけにより、本発明の実施形態を実現することができることが、当業者には理解することができる。しかし、ほとんどの場合、ソフトウェア、および一般のハードウェアプラットフォームが好まれる。この理解に基づき、本発明の技術的解決策、または従来技術への貢献をソフトウェア成果により実現することができる。ソフトウェア成果は、記憶媒体に記憶され、本発明の実施形態で提供された方法を実行するようネットワーク装置に指示する複数の命令を含む。
本発明をいくつかの例示的実施形態により説明してきたが、本発明はそのような実施形態に限定されるものではない。当業者が本発明の精神および範囲から逸脱することなく本発明に様々な修正および変形を行うことができることは明らかである。本発明は、修正および変形が添付の特許請求の範囲、またはその均等物により定義される保護の範囲に収まるという前提で、修正および変形を含むものである。

Claims (22)

  1. ユーザ管理情報を得るための方法であって、
    ユーザ管理情報を運ぶメッセージを端末から受信するステップと、
    前記メッセージから、前記端末の前記ユーザ管理情報を得るステップと、
    前記ユーザ管理情報を処理するステップと、
    を含む方法。
  2. 前記ユーザ管理情報が、
    メッセージ型ＩＤ、メッセージ送信時間、端末ＩＤ、サービスＩＤ、番組ＩＤ、前記端末のオンライン状態またはオフライン状態、端末識別コード、ユーザＩＤ情報、およびチャネルＩＤのうちの少なくとも１種類を含み、前記メッセージ型ＩＤが、ログインメッセージＩＤ、およびログアウトメッセージＩＤを含む、
    請求項１に記載の方法。
  3. 前記ユーザ管理情報を処理するステップが、
    ユーザログイン状態情報を記録する操作、前記ユーザが見る番組の状態情報を記録する操作、前記ユーザが更新する必要のあるサービス情報を記録する操作
    のうちの少なくとも１つを含み、
    前記ユーザログイン状態が、端末ＩＤ、ユーザＩＤ、サービス申し込み関係、ログイン時間、ログイン方式、およびユーザ鍵有効期間のうちの少なくとも１種類を含み、
    前記ユーザが見る前記番組の前記状態情報が、前記ユーザが見る前記番組のＩＤ、前記ユーザが見るチャネルのＩＤ、前記ユーザが前記チャネルを見るときの時間、および前記ユーザが前記チャネルからログアウトするときの時間のうちの少なくとも１つを含み、
    前記ユーザが更新する必要のある前記サービス情報が、前記ユーザ鍵が更新される必要があるかどうか、前記ユーザの対話情報が更新される必要があるかどうか、前記ユーザのサービスガイド（ＳＧ）が更新される必要があるかどうかのうちの少なくとも１つを含む、
    請求項１に記載の方法。
  4. 前記ユーザ管理情報を処理するステップが、
    前記ユーザ管理情報で運ばれる前記メッセージ送信時間、または、前記端末により送信される、番組の最初のフレーム時間、および最後のフレーム時間に従ってチャネルの番組を見ている時間を得るステップ、
    をさらに含む、請求項１に記載の方法。
  5. 前記ユーザ管理情報を処理するステップが、
    チャネルまたは番組の視聴率を得るステップ、
    をさらに含む、請求項１に記載の方法。
  6. 前記チャネルまたは番組の前記視聴率を得るステップが、
    統計のもとで前記チャネルまたは番組にＩＤを設定するステップと、
    前記チャネルまたは番組のコンテンツを受信するとき、またはそこからログアウトするときに、前記端末が送信するメッセージを受信するステップと、
    前記メッセージに従って前記チャネルまたは番組の前記視聴率を得るステップと、
    を含む、請求項５に記載の方法。
  7. 前記チャネルまたは番組の前記視聴率を得るステップが、
    指定されたチャネルまたは番組を見るか否かに関するメッセージをすべての端末、または指定された端末に送信するステップと、
    前記指定されたチャネルまたは番組を見ている端末からの応答を受信するステップと、
    前記応答に従って前記チャネルまたは番組の前記視聴率を得るステップと、
    を含む、請求項５に記載の方法。
  8. 前記メッセージから前記端末の前記ユーザ管理情報を得た後に、
    対話型番組の統計値情報を得るステップ、
    をさらに含む、請求項１または請求項２に記載の方法。
  9. 対話型番組の統計値情報を得るステップが、
    前記端末の前記ユーザ管理情報を受信した後に、対話情報、および対話更新情報のうちの少なくとも１つを含む対話型番組を前記端末に送信するステップと、
    前記端末から対話情報応答を受信するステップと、
    前記対話情報応答に従って前記対話型番組の統計値情報を得るステップと、
    を含む、請求項８に記載の方法。
  10. ユーザ管理情報を運ぶ前記メッセージを前記端末から受信するステップが、
    前記端末が起動されたとき、もしくは、見られる番組またはチャネルを切り換えるときに、前記端末から前記ユーザ管理情報を受信するステップ、
    を含む、請求項１に記載の方法。
  11. 前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
    前記端末が起動されたとき、もしくは、見られる番組またはチャネルを切り換えるときに、前記端末から送信された認証要求に従って前記端末を認証するステップ、
    をさらに含む、請求項１０に記載の方法。
  12. 前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
    前記端末により選択された番組コンテンツを前記端末に送信するステップと、
    前記端末の番組コンテンツ受信時間が、前もってセットされた時間を超過したと判断した後に、前記端末を認証するステップと、
    をさらに含む、請求項１に記載の方法。
  13. 前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
    サービスガイド（ＳＧ）に含まれる選択番組を前記端末に提供するステップ、
    をさらに含む、請求項１に記載の方法。
  14. 前記ＳＧに含まれる選択番組を前記端末に提供した後に、
    前記ＳＧに含まれる選択番組を前記端末が申し込む、またはその申し込みを取り消すのを受け入れるステップと、
    前記端末により申し込まれた番組に変更がある場合に、前記端末の更新された番組申し込み情報を受信するステップと、
    をさらに含む、請求項１３に記載の方法。
  15. ユーザ管理情報を得るためのシステムであって、
    ユーザ管理情報を端末から受信し、前記端末の前記得られたユーザ管理情報を記憶するように適合されたサーバと、
    前記ユーザ管理情報を前記サーバに送信するように適合された前記端末と、
    を含むシステム。
  16. 前記サーバが、
    前記端末から送信される前記ユーザ管理情報を受信するように適合された受信モジュールと、
    前記受信モジュールにより得られる、前記端末の前記ユーザ管理情報を記憶するように適合された統計値モジュールと、
    をさらに含む、請求項１５に記載のシステム。
  17. 前記端末が、
    前記ユーザ管理情報を前記サーバに送信するように適合されたユーザ管理情報送信モジュール、
    をさらに含む、請求項１５に記載のシステム。
  18. ユーザ管理情報を得るように適合されたサーバであって、
    端末から送信されるユーザ管理情報を受信するように適合された受信モジュールと、
    前記受信モジュールにより得られる、前記端末の前記ユーザ管理情報を記憶するように適合された統計値モジュールと、
    を含むサーバ。
  19. サービスガイド（ＳＧ）に含まれる選択番組を前記端末が申し込む、またはその申し込みを取り消すのを受け入れ、申し込み結果、または申し込み取り消し結果に従って、前記端末のローカルの番組申し込み情報を更新するように適合された番組申し込みモジュール
    をさらに含む、請求項１８に記載のサーバ。
  20. 番組を見ることを要求する端末を認証するように適合された認証モジュール
    をさらに含む、請求項１８に記載のサーバ。
  21. 対話型番組で前記端末との対話を実現するように適合された対話型番組処理モジュール
    をさらに含む、請求項１８に記載のサーバ。
  22. サーバにユーザ管理情報を送信するように適合された端末であって、
    ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュールと、
    前記生成されたユーザ管理情報をメッセージの形で送信するように適合されたユーザ管理情報送信モジュールと、
    を含む端末。
JP2010526139A 2007-09-30 2008-09-26 ユーザ管理情報を得るための方法、システム、および装置 Active JP5242690B2 (ja)

Applications Claiming Priority (3)

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

Publications (2)

Publication Number Publication Date
JP2010541345A true JP2010541345A (ja) 2010-12-24
JP5242690B2 JP5242690B2 (ja) 2013-07-24

Family

ID=40518172

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010526139A Active JP5242690B2 (ja) 2007-09-30 2008-09-26 ユーザ管理情報を得るための方法、システム、および装置

Country Status (6)

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

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2346249A1 (en) * 2008-10-07 2011-07-20 Sharp Kabushiki Kaisha Digital broadcast reception device and reception method
CN101998153B (zh) * 2009-08-17 2013-04-03 中国移动通信集团公司 基于广播式移动多媒体业务上报收看频道的方法及装置
CN103546770A (zh) * 2012-07-11 2014-01-29 上海曜铂信息科技有限公司 智能收视率采集方法
CN104486645A (zh) * 2014-11-20 2015-04-01 小米科技有限责任公司 确定节目收视率的方法、播放设备、服务器及装置
US10776839B1 (en) * 2015-05-29 2020-09-15 Intuit Inc. Photo transactions for financial applications
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 天脉聚源（北京）科技有限公司 一种用于电视互动系统电视节目管理的方法及装置
JP6769106B2 (ja) * 2016-05-18 2020-10-14 富士通株式会社 ストレージ制御方法、ストレージ制御プログラムおよび情報処理装置
CN105979300A (zh) * 2016-06-27 2016-09-28 乐视控股（北京）有限公司 身份识别方法及装置
WO2018018456A1 (zh) * 2016-07-27 2018-02-01 黄新勇 电视广播的片源统计方法及系统
WO2018018453A1 (zh) * 2016-07-27 2018-02-01 黄新勇 电视广播中观看时间统计方法及系统
CN106131677A (zh) * 2016-07-27 2016-11-16 黄新勇 用户观看内容的统计方法及系统
WO2018018455A1 (zh) * 2016-07-27 2018-02-01 黄新勇 用户观看内容的统计方法及系统
CN107801186B (zh) * 2016-09-06 2020-10-30 普天信息技术有限公司 一种集群通信系统中非接入层摘要鉴权方法

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197478A (ja) * 2000-01-17 2001-07-19 Canon Inc 放送管理システム、放送管理装置、受信装置及びそれらの制御方法、コンピュータ可読メモリ
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 視聴者参加型ストリーミング配信方法ならびにアンケート管理サーバおよび視聴者端末装置
JP2003230163A (ja) * 2002-02-04 2003-08-15 Fujitsu Ltd 抽選方法及び抽選プログラム
JP2006005767A (ja) * 2004-06-18 2006-01-05 Omron Entertainment Kk 端末装置、サーバ装置、通信ネットワークシステム、端末装置の制御方法、サーバ装置の制御方法、プログラム、および、プログラムを記録した記録媒体
JP2006024137A (ja) * 2004-07-09 2006-01-26 Sharp Corp Ｕｉコンテンツ生成方法、ｕｉコンテンツ生成装置及びｕｉコンテンツ生成システム
JP2006222574A (ja) * 2005-02-08 2006-08-24 Mitsubishi Electric Corp デジタル放送受信端末
JP2007202031A (ja) * 2006-01-30 2007-08-09 Kyocera Corp 移動型放送受信装置及び視聴情報送信方法
WO2007105460A1 (ja) * 2006-03-07 2007-09-20 Sony Corporation 情報処理装置、情報通信システム、および情報処理方法、並びにコンピュータ・プログラム

Family Cites Families (21)

* 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
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
US20030110500A1 (en) * 2001-12-06 2003-06-12 Rodriguez Arturo A. Prediction-based adaptative control of television viewing functionality
CN100512417C (zh) * 2003-02-24 2009-07-08 华为技术有限公司 交互数字广播电视网络系统及其前端和终端装置
JP2005056246A (ja) * 2003-08-06 2005-03-03 Sony Corp 情報端末装置、サーバ装置およびプログラム
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
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 에스케이 텔레콤주식회사 위성 ｄｍｂ 시청율 조사 서비스 시스템 및 방법
CN2938648Y (zh) * 2006-04-30 2007-08-22 朱大为 一种手机电视终端
CN100433627C (zh) * 2006-06-21 2008-11-12 华为技术有限公司 实现移动多媒体广播组播的系统及方法
KR100758507B1 (ko) * 2007-03-14 2007-09-13 주식회사 셀런 쌍방향 방송 시스템에서 광고 시청자의 반응을 유도하여광고시청을 활성화하고 광고 시청률을 조사하는 방법

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197478A (ja) * 2000-01-17 2001-07-19 Canon Inc 放送管理システム、放送管理装置、受信装置及びそれらの制御方法、コンピュータ可読メモリ
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 視聴者参加型ストリーミング配信方法ならびにアンケート管理サーバおよび視聴者端末装置
JP2003230163A (ja) * 2002-02-04 2003-08-15 Fujitsu Ltd 抽選方法及び抽選プログラム
JP2006005767A (ja) * 2004-06-18 2006-01-05 Omron Entertainment Kk 端末装置、サーバ装置、通信ネットワークシステム、端末装置の制御方法、サーバ装置の制御方法、プログラム、および、プログラムを記録した記録媒体
JP2006024137A (ja) * 2004-07-09 2006-01-26 Sharp Corp Ｕｉコンテンツ生成方法、ｕｉコンテンツ生成装置及びｕｉコンテンツ生成システム
JP2006222574A (ja) * 2005-02-08 2006-08-24 Mitsubishi Electric Corp デジタル放送受信端末
JP2007202031A (ja) * 2006-01-30 2007-08-09 Kyocera Corp 移動型放送受信装置及び視聴情報送信方法
WO2007105460A1 (ja) * 2006-03-07 2007-09-20 Sony Corporation 情報処理装置、情報通信システム、および情報処理方法、並びにコンピュータ・プログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JPN6012061518; Ｊｉｈｙｅ　Ｌｙｕ　ｅｔ　ａｌ．: 'Ｄｅｓｉｇｎ　ｏｆ　Ｏｐｅｎ　ＡＰＩｓ　ｆｏｒ　Ｐｅｒｓｏｎａｌｉｚｅｄ　ＩＰＴＶ　Ｓｅｒｖｉｃｅ' Ｔｈｅ　９ｔｈ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ａｄｖａｎｃｅｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ　（ＩＣＡＣＴ２００７） Ｖｏｌ．１, 200702, ｐｐ．３０５-３１０, ＩＥＥＥ *
JPN6012061520; Ａｄｅｌ　Ａｌ-Ｈｅｚｍｉ　ｅｔ　ａｌ．: 'Ｔｏｗａｒｄｓ　ａｎ　Ｉｎｔｅｒａｃｔｉｖｅ　ＩＰＴＶ　ｆｏｒ　Ｍｏｂｉｌｅ　Ｓｕｂｓｃｒｉｂｅｒｓ' Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｄｉｇｉｔａｌ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　（ＩＣＤＴ　２００６） , 200608, ｐｐ．４５-４９, ＩＥＥＥ *

Also Published As

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

Similar Documents

Publication Publication Date Title
JP5242690B2 (ja) ユーザ管理情報を得るための方法、システム、および装置
EP2392115B1 (en) Method and user equipment for facilitating service provision
US8245309B2 (en) Content viewing system, content viewing apparatus, and viewing approval apparatus
US8290534B2 (en) Method and system for subscribing to digital broadcasting service through mobile communication network
US8176147B2 (en) Method and messaging system for managing media contents in uniform storage
US20110035768A1 (en) Method and Arrangements for Control of Consumption of Content Services
CN102047628B (zh) 通信网络中的iptv安全性
WO2008040201A1 (fr) Procédé d&#39;obtention d&#39;une clé à long terme (ltk) et serveur de gestion d&#39;abonnement associé
EP2515551A1 (en) System and method providing remote video-on-demand (VOD)
US9350720B2 (en) Delegating authorizations
CN101582730B (zh) 提供mbms服务的方法、系统、相应装置及通信终端
CN101355676B (zh) 提供网络电视业务信息的方法和网络电视业务系统
US20090276818A1 (en) Method for providing iptv service and internet broadcasting system therefor
US8625755B2 (en) Method and apparatus for managing contact books
US9036812B2 (en) Method and apparatus for selecting communication identifiers
US20110119757A1 (en) Method and apparatus for performing login by mobile station in wireless communication system
EP2274927A1 (en) Service reporting
KR100958931B1 (ko) 메시지 채널 가입 지원 방법 및 메시지 서비스 제공 방법
KR20060082245A (ko) Ｃｂｓ 메시지를 이용한 디지털 멀티미디어 방송 컨텐츠제공 시스템 및 그 제공방법
KR101618781B1 (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
WO2009076825A1 (zh) 设置临时权限、实现好友电视业务的方法、系统和设备
JP2012227671A (ja) データ処理システム、そのデータ処理方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120529

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120605

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120903

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121127

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130227

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130326

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130403

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160412

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 5242690

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250