(57)【要約】  ユーザ管理情報を得るための方法、システム、および装置を提供する。この方法は、端末により送信される、ユーザ管理情報を運ぶメッセージを受信するステップと、メッセージから端末のユーザ管理情報を得るステップと、ユーザ管理情報に関する情報を処理するステップとを含む。このシステムは、端末により送信されるユーザ管理情報を受信し、得られる端末のユーザ管理情報を記憶するためのサーバと、ユーザ管理情報をサーバに伝送するための端末とを含む。
2010541345.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ管理情報を得るための方法であって、
ユーザ管理情報を運ぶメッセージを端末から受信するステップと、
前記メッセージから、前記端末の前記ユーザ管理情報を得るステップと、
前記ユーザ管理情報を処理するステップと、
を含む方法。
【請求項２】
前記ユーザ管理情報が、
メッセージ型ＩＤ、メッセージ送信時間、端末ＩＤ、サービスＩＤ、番組ＩＤ、前記端末のオンライン状態またはオフライン状態、端末識別コード、ユーザＩＤ情報、およびチャネルＩＤのうちの少なくとも１種類を含み、前記メッセージ型ＩＤが、ログインメッセージＩＤ、およびログアウトメッセージＩＤを含む、
請求項１に記載の方法。
【請求項３】
前記ユーザ管理情報を処理するステップが、
ユーザログイン状態情報を記録する操作、前記ユーザが見る番組の状態情報を記録する操作、前記ユーザが更新する必要のあるサービス情報を記録する操作
のうちの少なくとも１つを含み、
前記ユーザログイン状態が、端末ＩＤ、ユーザＩＤ、サービス申し込み関係、ログイン時間、ログイン方式、およびユーザ鍵有効期間のうちの少なくとも１種類を含み、
前記ユーザが見る前記番組の前記状態情報が、前記ユーザが見る前記番組のＩＤ、前記ユーザが見るチャネルのＩＤ、前記ユーザが前記チャネルを見るときの時間、および前記ユーザが前記チャネルからログアウトするときの時間のうちの少なくとも１つを含み、
前記ユーザが更新する必要のある前記サービス情報が、前記ユーザ鍵が更新される必要があるかどうか、前記ユーザの対話情報が更新される必要があるかどうか、前記ユーザのサービスガイド（ＳＧ）が更新される必要があるかどうかのうちの少なくとも１つを含む、
請求項１に記載の方法。
【請求項４】
前記ユーザ管理情報を処理するステップが、
前記ユーザ管理情報で運ばれる前記メッセージ送信時間、または、前記端末により送信される、番組の最初のフレーム時間、および最後のフレーム時間に従ってチャネルの番組を見ている時間を得るステップ、
をさらに含む、請求項１に記載の方法。
【請求項５】
前記ユーザ管理情報を処理するステップが、
チャネルまたは番組の視聴率を得るステップ、
をさらに含む、請求項１に記載の方法。
【請求項６】
前記チャネルまたは番組の前記視聴率を得るステップが、
統計のもとで前記チャネルまたは番組にＩＤを設定するステップと、
前記チャネルまたは番組のコンテンツを受信するとき、またはそこからログアウトするときに、前記端末が送信するメッセージを受信するステップと、
前記メッセージに従って前記チャネルまたは番組の前記視聴率を得るステップと、
を含む、請求項５に記載の方法。
【請求項７】
前記チャネルまたは番組の前記視聴率を得るステップが、
指定されたチャネルまたは番組を見るか否かに関するメッセージをすべての端末、または指定された端末に送信するステップと、
前記指定されたチャネルまたは番組を見ている端末からの応答を受信するステップと、
前記応答に従って前記チャネルまたは番組の前記視聴率を得るステップと、
を含む、請求項５に記載の方法。
【請求項８】
前記メッセージから前記端末の前記ユーザ管理情報を得た後に、
対話型番組の統計値情報を得るステップ、
をさらに含む、請求項１または請求項２に記載の方法。
【請求項９】
対話型番組の統計値情報を得るステップが、
前記端末の前記ユーザ管理情報を受信した後に、対話情報、および対話更新情報のうちの少なくとも１つを含む対話型番組を前記端末に送信するステップと、
前記端末から対話情報応答を受信するステップと、
前記対話情報応答に従って前記対話型番組の統計値情報を得るステップと、
を含む、請求項８に記載の方法。
【請求項１０】
ユーザ管理情報を運ぶ前記メッセージを前記端末から受信するステップが、
前記端末が起動されたとき、もしくは、見られる番組またはチャネルを切り換えるときに、前記端末から前記ユーザ管理情報を受信するステップ、
を含む、請求項１に記載の方法。
【請求項１１】
前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
前記端末が起動されたとき、もしくは、見られる番組またはチャネルを切り換えるときに、前記端末から送信された認証要求に従って前記端末を認証するステップ、
をさらに含む、請求項１０に記載の方法。
【請求項１２】
前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
前記端末により選択された番組コンテンツを前記端末に送信するステップと、
前記端末の番組コンテンツ受信時間が、前もってセットされた時間を超過したと判断した後に、前記端末を認証するステップと、
をさらに含む、請求項１に記載の方法。
【請求項１３】
前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
サービスガイド（ＳＧ）に含まれる選択番組を前記端末に提供するステップ、
をさらに含む、請求項１に記載の方法。
【請求項１４】
前記ＳＧに含まれる選択番組を前記端末に提供した後に、
前記ＳＧに含まれる選択番組を前記端末が申し込む、またはその申し込みを取り消すのを受け入れるステップと、
前記端末により申し込まれた番組に変更がある場合に、前記端末の更新された番組申し込み情報を受信するステップと、
をさらに含む、請求項１３に記載の方法。
【請求項１５】
ユーザ管理情報を得るためのシステムであって、
ユーザ管理情報を端末から受信し、前記端末の前記得られたユーザ管理情報を記憶するように適合されたサーバと、
前記ユーザ管理情報を前記サーバに送信するように適合された前記端末と、
を含むシステム。
【請求項１６】
前記サーバが、
前記端末から送信される前記ユーザ管理情報を受信するように適合された受信モジュールと、
前記受信モジュールにより得られる、前記端末の前記ユーザ管理情報を記憶するように適合された統計値モジュールと、
をさらに含む、請求項１５に記載のシステム。
【請求項１７】
前記端末が、
前記ユーザ管理情報を前記サーバに送信するように適合されたユーザ管理情報送信モジュール、
をさらに含む、請求項１５に記載のシステム。
【請求項１８】
ユーザ管理情報を得るように適合されたサーバであって、
端末から送信されるユーザ管理情報を受信するように適合された受信モジュールと、
前記受信モジュールにより得られる、前記端末の前記ユーザ管理情報を記憶するように適合された統計値モジュールと、
を含むサーバ。
【請求項１９】
サービスガイド（ＳＧ）に含まれる選択番組を前記端末が申し込む、またはその申し込みを取り消すのを受け入れ、申し込み結果、または申し込み取り消し結果に従って、前記端末のローカルの番組申し込み情報を更新するように適合された番組申し込みモジュール
をさらに含む、請求項１８に記載のサーバ。
【請求項２０】
番組を見ることを要求する端末を認証するように適合された認証モジュール
をさらに含む、請求項１８に記載のサーバ。
【請求項２１】
対話型番組で前記端末との対話を実現するように適合された対話型番組処理モジュール
をさらに含む、請求項１８に記載のサーバ。
【請求項２２】
サーバにユーザ管理情報を送信するように適合された端末であって、
ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュールと、
前記生成されたユーザ管理情報をメッセージの形で送信するように適合されたユーザ管理情報送信モジュールと、
を含む端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照により本明細書に全部組み込まれる、２００７年９月３０日に中国特許庁に出願された「ユーザ管理情報を得るための方法、システム、および装置」と題する中国特許出願第２００７１０１６２７５９．Ｘ号の優先権を主張する。
【０００２】
本発明は、移動体通信分野に関し、詳細には、ユーザ管理情報を得るための方法、システム、および装置に関する。
【背景技術】
【０００３】
モバイルテレビ放送（ＴＶ）サービスにより、ユーザが、オペレーティングシステムおよびビデオ機能の付いたインテリジェント携帯電話を介してＴＶを視聴することができるようになる。携帯電話の人気が高く、かつ携帯性が高いので、モバイルＴＶサービスには通常のＴＶサービスよりも広範な影響力がある。
【０００４】
現在、モバイルＴＶサービスは、以下の３つの方式で実現されている。第１の方式は移動ネットワークに基づいており、たとえばチャイナモバイル社がモバイルＴＶサービスを展開した。第２の方式は衛星放送に基づいており、たとえば、韓国の運営者がモバイルＴＶサービスを提供した。第３の方式は携帯電話の中に実装されたデジタルＴＶ受信モジュールに基づいており、このモジュールがデジタルＴＶ信号を直接受信することができる。
【０００５】
現在、移動ネットワークに基づくモバイルＴＶサービスが、チャイナモバイル社により展開され、汎用パケット無線サービス（ＧＰＲＳ）移動ネットワークに依存している。実際には、このモバイルＴＶサービスは、ストリーミング技術を使用することによりデータサービスとして展開されている。しかし、ユーザが、オペレーティングシステムを有する移動端末（一般には、携帯情報端末（ＰＤＡ））の中にプレーヤをダウンロードしてインストールする必要がある。チャイナモバイル社およびコンテンツ提供業者（サービス提供業者（ＳＰ））が協力することにより、関連するＴＶ番組コンテンツが提供される。
【０００６】
衛星ネットワークに基づくモバイルＴＶサービスを実現することは新しい考え方である。すなわち、衛星から放送されるＴＶ番組信号を受信するために、携帯電話が使用される。現在、韓国でだけデジタルマルチメディア放送（ＤＭＢ）受信機が展開されている。韓国によれば、ＤＭＰ受信機は高品質画像を提供することができ、この受信機を介して、ユーザが地上無線ＴＶ放送信号、および衛星ＴＶ放送信号を同時に受信することができる。
【０００７】
しかし、従来技術のモバイルＴＶサービスでは、サーバが端末状態情報を得ることができない、またはコンテンツの統計値を作成することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来技術には以下の欠点がある。すなわち、端末が放送方式でサーバから送信される番組コンテンツを得ることができるが、放送方式では大量の端末情報を管理することが困難である。たとえば、視聴率、および視聴されているＴＶ番組に関する対話文書を更新する処理を管理することが困難である。さらに、サービスガイド（ＳＧ）を更新した後に、更新したコンテンツを適切なユーザに即座に送信することができず、サーバはユーザ状態（たとえば、オンライン、および視聴中）を即座に得ることができない。
【課題を解決するための手段】
【０００９】
本発明の実施形態が、ユーザ管理情報を得るための方法、システム、および装置を提供して、端末のユーザ管理情報の統計値を作成する。
【００１０】
本発明の一実施形態におけるユーザ管理情報を得る方法は、
端末からのユーザ管理情報を運ぶメッセージを受信するステップと、
そのメッセージから端末のユーザ管理情報を得るステップと、
そのユーザ管理情報を処理するステップと、
を含む。
【００１１】
本発明の一実施形態におけるユーザ管理情報を得るシステムは、
端末からユーザ管理情報を受信し、端末の得られたユーザ管理情報を記憶するように適合されたサーバと、
サーバにユーザ管理情報を送信するように適合された端末と、
を含む。
【００１２】
本発明の一実施形態で提供されるサーバは、ユーザ管理情報を得るように適合され、
端末から送信されるユーザ管理情報を受信するように適合された受信モジュールと、
受信モジュールにより得られる、端末のユーザ管理情報を記憶するように適合された統計値モジュールと、
を含む。
【００１３】
本発明の一実施形態で提供される端末は、ユーザ管理情報をサーバに送信するように適合され、
ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュールと、
生成されたユーザ管理情報をメッセージの形式で送信するように適合されたユーザ管理情報送信モジュールと、
を含む。
【００１４】
従来技術と比較して、本発明の実施形態には以下の長所がある。
【００１５】
すなわち、本発明の実施形態は、端末とサーバの間の対話による、ユーザ管理情報統計値、対話更新、および視聴率統計値などの情報インターワーキングを実現する。
【図面の簡単な説明】
【００１６】
【図１】図１は、本発明の第１の実施形態におけるユーザ管理情報を得る方法の流れ図である。
【図２】図２は、本発明の第２の実施形態におけるユーザ管理情報を得る方法の流れ図である。
【図３】図３は、本発明の第３の実施形態におけるユーザ管理情報を得る方法の流れ図である。
【図４】図４は、本発明の第４の実施形態におけるユーザ管理情報を得る方法の流れ図である。
【図５】図５は、本発明の第５の実施形態におけるユーザ管理情報を得るためのシステムの構成を示す図である。
【発明を実施するための形態】
【００１７】
添付図面、および例示的実施形態を参照して本発明を以下に詳細に述べる。
【００１８】
図１に示すように、本発明の第１の実施形態におけるユーザ管理情報を得る方法は、以下のステップを含む。
【００１９】
Ｓ１０１．  ユーザ管理情報を運ぶメッセージを端末から受信する。
【００２０】
Ｓ１０２．  メッセージから端末のユーザ管理情報を得る。
【００２１】
Ｓ１０３．  ユーザ管理情報を処理する。
【００２２】
具体的には、本発明の第１の実施形態では、対話更新、視聴率の統計、および他の情報のインターワーキングが、端末とサーバの間の対話により実現される。端末とサーバの間の対話メッセージが、ある種の形式に準拠し、わずかな必要情報を運ぶように指定されることもある。そのようなメッセージは、サーバにより処理しやすく、したがって、サーバの負荷を軽減する。サーバは、ある種の方針に従って端末情報を記録し、その統計値を作成することができる。サーバはまた、その方針に従って端末から報告される対話情報を処理することもできる。
【００２３】
本発明で提供される方法は以下の通りである。すなわち、ユーザがチャネルにログインするときに、端末がサービスＩＤ、およびユーザＩＤなどのユーザ管理情報をローカルに記憶する必要がある。番組を一定期間、受信した後に、端末はサービスＩＤ、ユーザＩＤ、およびチャネルＩＤなどのユーザ管理情報をサーバに送信する必要がある。端末がこの番組からログアウトした後に、端末はまた、サービスＩＤ、チャネルＩＤ、およびユーザＩＤなどのユーザ管理情報をサーバに送信する必要がある。そのとき、ログアウトが終了する。ログインおよびログアウトの目的は、端末のユーザ管理情報をサーバに提供することである。この情報は、サーバが視聴率統計値を作成し、端末の視聴行為を明確にする証拠として役立てることができる。
【００２４】
ユーザがチャネルにログインした後に、端末が、一定期間チャネルの番組が受信されるのを待たずに、サービスＩＤおよびユーザＩＤなどのユーザ管理情報をサーバに直接送信することができる。前述の事例では、ユーザ管理情報は、チャネル情報、すなわちチャネルＩＤを含まない。端末が番組からログアウトした後に、端末はサービスＩＤ、チャネルＩＤ、およびユーザＩＤなどのユーザ管理情報をサーバに送信することができる。そのとき、ログアウトが終了する。
【００２５】
端末のユーザ管理情報を得た後に、サーバはまた、受け取ったユーザ管理情報を処理することもでき、この処理は、ユーザのログイン状態情報を記録する操作、ユーザが見る番組の状態情報を記録する操作、およびユーザが更新する必要があるサービス情報を記録する操作のうちの少なくとも１つを含み、
【００２６】
ユーザログイン状態情報は、端末ＩＤ、ユーザＩＤ、サービス申し込み関係、ログイン時間、ログイン方式、およびユーザキー有効期間のうちの少なくとも１つを含み、ユーザが見る番組の状態情報は、ユーザが見る番組のＩＤ、ユーザが見るチャネルのＩＤ、ユーザがそのチャネルを見始める時間、およびユーザがそのチャネルからログアウトする時間のうちの少なくとも１つを含み、ユーザが更新する必要のあるサービス情報は、ユーザキーが更新される必要があるかどうか、ユーザの対話情報が更新される必要があるかどうか、およびユーザのＳＧが更新される必要があるかどうかのうちの少なくとも１つを含む。
【００２７】
端末のユーザ管理情報を得た後に、サーバはまた、ユーザ管理情報で運ばれるメッセージが送信されたときの時間、またはサーバが、番組の最初のフレームまたは最後のフレームを端末に送信したときの時間に従って、チャネルの番組を見ている時間を得ることもできる。
【００２８】
端末のユーザ管理情報を得た後に、サーバはまた、チャネルまたは番組の視聴率を得ることもできる。チャネルまたは番組の視聴率を得る処理は、統計のもとでチャネルまたは番組のＩＤを設定するステップと、チャネルまたは番組のコンテンツを受信するときに、またはそれからログアウトするときに端末が送信するメッセージを受信するステップと、そのメッセージに従ってチャネルまたは番組の視聴率を得るステップとを含んでもよい。チャネルまたは番組の視聴率を得る処理はまた、すべての端末、または指定された端末に、指定されたチャネルまたは番組を見るべきかどうかに関するメッセージを送信するステップと、指定されたチャネルまたは番組を見ている端末からの応答を受信するステップと、その応答に従ってチャネルまたは番組の視聴率を得るステップとを含むことがある。
【００２９】
端末が番組チャネルにログインするとき、及び視聴した番組からログアウトするときに、サーバによりユーザ管理情報を得る方法を、本発明の第２の実施形態が提供する。ユーザ管理情報は、メッセージ型ＩＤ、メッセージ送信時間、端末ＩＤ、サービスＩＤ、番組ＩＤ、端末のオンライン状態またはオフライン状態、端末識別コード、ユーザＩＤ情報、およびチャネルＩＤのうちの、１つまたは複数を含む。メッセージ型ＩＤは、ログインメッセージＩＤ、およびログアウトメッセージＩＤを含む。チャネルを申し込んだ後に、端末はサーバにメッセージを何も送信しない。サーバは端末状態、ユーザ情報、および申し込まれたチャネルの更新詳細について何もわからない。したがって、この問題を解決する方法を提供しなければならない。この解決策は、端末がどのようにして番組を受信し、対話を行うかをサーバがさらに知る方法を提供する。
【００３０】
図２に示すように、この解決策の考え方は、端末ユーザが特定の時間に番組を見るときに、端末がその番組を放送するチャネルにログインすることがあるということにある。ログインするときに、端末は、サービスＩＤ、およびユーザＩＤなどのユーザ管理情報をサーバに送信することができる。ユーザ管理情報は、複数の方式でサーバに送信されてもよい。サーバは、ユーザ管理情報を記憶し、受信したメッセージに応答することができる。端末が、受信した番組からログアウトした後に、以下のようにサーバと対話する。すなわち、端末は、サービスＩＤ、チャネルＩＤ、およびユーザＩＤなどのログアウトの場合のユーザ管理情報をサーバに送信する。サーバは、ユーザ管理情報に従って、端末がログインする番組の保存された全詳細を記録する。
【００３１】
図２に示すように、この処理は以下のステップを含む。
【００３２】
Ｓ２０１．  端末が起動され、サーバにＬｏｇＩｎＩｎｆｏメッセージを送信する。
【００３３】
ＬｏｇＩｎＩｎｆｏメッセージの内容を以下に列挙する。
【００３４】
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"/>
【００７８】
この実施形態では、ＨＴＴＰ  ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、ステップ４での意味と同じである。ＬｏｇＯｕｔＩｎｆｏメッセージ中のＸＭＬデータは、メッセージボディにある。
【００７９】
ＬｏｇＯｕｔＩｎｆｏメッセージは、サービスＩＤおよびユーザＩＤを運ぶ。サーバは端末のログアウト時間、すなわち終了時間を記録する。端末のＬｏｇＯｕｔＩｎｆｏメッセージは、図３に示す形式を使用することがある。このメッセージは対話型チャネルを介して送信される。ＬｏｇＯｕｔＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。
【００８０】
ＬｏｇＯｕｔＩｎｆｏメッセージをＨＴＴＰ方式でサーバに送信することもある。このときに、サーバはＬｏｇＯｕｔＩｎｆｏメッセージを処理し、それをデータベースに追加する。ＬｏｇＯｕｔＩｎｆｏメッセージはまた、ショート・メッセージ・サービス（ＳＭＳ）方式で送信されることも、他の方式で送信されることもある。ＨＴＴＰ  ＰＯＳＴ方式は一例でしかなく、他のキャリア方式に置き換えることもできる。しかし、その原理および考え方は同じである。
【００８１】
Ｓ２１１．  ＬｏｇＯｕｔＩｎｆｏメッセージを適切に受信した後に、サーバが２００  ＯＫメッセージを端末に送り返す。
【００８２】
２００  ＯＫメッセージを対話型チャネルにより送り返すことも、他の方式により送り返すこともある。この実施形態では、２００  ＯＫは、ＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信することに成功したことを示す。異なるネットワーク環境で、他の確認方式を使用することもできるが、その考え方および原理は同じである。
【００８３】
Ｓ２１２．  端末が番組からログアウトした後に、サーバがその端末の状態情報を記憶する。
【００８４】
サーバは、端末から報告されたＬｏｇＩｎＩｎｆｏ状態情報、およびＬｏｇＯｕｔＩｎｆｏ状態情報をローカルデータベース、または他のサーバに追加する。サーバは、必要とされるデータをＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージから得る。サーバは、そのようなデータに従って、端末の申し込み、および端末が見た番組についての一般的な理解を得る。サーバのデータベース内に記憶された状態情報は、表４と同じこともあれば、似ていることもある。
【００８５】
移動端末を使用することによりユーザがチャネルの番組を受信するときに、より良い方法は、ＳＧを介してチャネルリストを表示することである。この場合、端末はチャネルを選択し、見ることができる。端末がＳＧに示されるチャネルリスト内のチャネルにログインするときに、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含む現在のユーザ管理情報を記録することができる。端末が一定期間（たとえば、１分）チャネルの番組にログインするときには、ユーザはその番組を見ている。この場合、端末はユーザ管理情報をサーバに送信する必要がある。端末がチャネルまたは番組からログアウトするときに、端末は、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含むログアウトの場合のユーザ管理情報を記録することができる。サーバは対話型サーバのことも、端末情報を記録するための特別なサーバのこともある。
【００８６】
たとえば、ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージが、以下の表１に示すデータ構造を使用することもある。
【００８７】
【表１】
2010541345.tif 000003
【００８８】
ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージは必須である。方向は端末からサーバである。
【００８９】
表２、および表３はそれぞれＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージのデータ構造要素を示す。
【００９０】
【表２】
2010541345.tif 000004
【００９１】
【表３】
2010541345.tif 000005
【００９２】
スキーマにより表されたデータ構造を以下に示す。
【００９３】
<?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>
【００９４】
上記のメッセージが端末によりサーバに送信され、サーバにより記憶される。記録すべき状態情報を記憶するように、データ構造をサーバ内で表４に示すように構成することもできる。
【００９５】
【表４】
2010541345.tif 000006
【００９６】
データ構造のスキーマを以下に示す。
【００９７】
<?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"/>
【０１５３】
この実施形態では、ＨＴＴＰ  ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、ステップ４での意味と同じである。ＬｏｇＯｕｔＩｎｆｏメッセージ中のＸＭＬデータは、メッセージボディにある。
【０１５４】
ＬｏｇＯｕｔＩｎｆｏメッセージは、サービスＩＤ、ユーザＩＤ、および現在のログアウト時間、すなわち終了時間を運ぶ。端末のＬｏｇＯｕｔＩｎｆｏメッセージは、図３に示す形式を使用することがある。このメッセージは対話型チャネルを介して送信される。ＬｏｇＯｕｔＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。
【０１５５】
ＬｏｇＯｕｔＩｎｆｏメッセージをＨＴＴＰ方式でサーバに送信することもある。このときに、サーバはＬｏｇＯｕｔＩｎｆｏメッセージを処理し、それをデータベースに追加する。ＬｏｇＯｕｔＩｎｆｏメッセージはまた、ＳＭＳ方式で送信されることも、他の方式で送信されることもある。ＨＴＴＰ  ＰＯＳＴ方式は一例でしかなく、他のキャリア方式に置き換えることもできる。しかし、その原理および考え方は同じである。
【０１５６】
Ｓ３１１．  ＬｏｇＯｕｔＩｎｆｏメッセージを適切に受信した後に、サーバが２００  ＯＫメッセージを端末に送り返す。
【０１５７】
２００  ＯＫメッセージを対話型チャネルにより送り返すことも、他の方式により送り返すこともある。この実施形態では、２００  ＯＫは、ＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信することに成功したことを示す。異なるネットワーク環境で、他の確認方式を使用することもできるが、その考え方および原理は同じである。
【０１５８】
Ｓ３１２．  端末が番組からログアウトした後に、サーバがその端末の状態情報を記憶し、統計値を作成する。
【０１５９】
サーバは、端末から報告されたＬｏｇＩｎＩｎｆｏおよびＬｏｇＯｕｔＩｎｆｏの状態情報に従ってチャネルまたは番組の視聴率の統計値を作成する。
【０１６０】
視聴率の統計値を作成する方法を２つ以下に記載する。
【０１６１】
Ａ．  ＳＧがチャネルＩＤを含むことがある。この場合、サーバが、ある時間区切り内でチャネルの視聴率の統計値を作成する必要があるときに、そのＳＧで統計値が作成されることを示すチャネルＩＤを設定する。たとえば、ＣＣＴＶ２  ｓｔａｔ＝ＴＲＵＥ  ２００７−０８−０９  １２：００−１３：００は、２００７年８月９日の１２：００〜１３：００の時間区切り内にＣＣＴＶ２チャネルがあることを示す。ユーザがＣＣＴＶ２を選択する場合、そのチャネルを見ている、または見終わったことを示すメッセージをサーバに送る必要がある。それに基づいて、サーバが視聴率の統計値を作成する、または他の関連する統計値を作成する。
【０１６２】
Ｂ．  サーバが、オンラインユーザ端末のうちのすべて、または一部に、これらのユーザがそのチャネルを見ているかどうかフィードバックするよう彼らに要求するメッセージを送信する。ユーザ端末はこのメッセージに応答し、サーバの要求に対する返答を示す関連情報を運ぶ。この場合、関連データの統計値をサーバ内で作成することができる。
【０１６３】
さらに、サーバが、ユーザの番組の好みについての統計値を作成することができる。サーバが、端末が番組を見るときの記録された開始時間および終了時間に従って、ユーザが番組を見た全期間を計算する。サーバは、様々な番組に応じて、どの番組ＩＤが大多数のユーザを伴っているか、およびどのサービスＩＤが大多数のユーザを伴っているかを、計算により明らかにすることができる。さらに、サーバは、ユーザがサーバ内に記憶する、以前のデータに従って、ユーザの好みについての統計値を作成し、どの番組ＩＤおよびサービスＩＤが大多数のユーザを伴っているかを明らかにすることができる。ＣＰは、そのデータに従ってユーザに月額料金サービスを提供することができる。ユーザがサーバ内に記憶する状態情報は、表８のものと似ていることがある。
【０１６４】
移動端末を使用することによりユーザがチャネルの番組を受信するときに、より良い方法は、ＳＧを介してチャネルリストを表示することである。この場合、端末はチャネルを選択し、見ることができる。端末がＳＧに示されるチャネルリスト内のチャネルにログインするときに、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含む現在のユーザ管理情報を記録することができる。端末が一定期間（たとえば、１分）チャネルの番組にログインするときには、ユーザはその番組を見ている。この場合、端末はユーザ管理情報をサーバに送信する必要がある。端末がチャネルまたは番組からログアウトするときに、端末は、ユーザＩＤ、サービスＩＤ、および番組ＩＤを含む、ログアウトの場合のユーザ管理情報を記録することができる。サーバは対話型サーバであることも、端末情報を記録するための特別なサーバであることもある。表５は、ＬｏｇＩｎＩｎｆｏメッセージおよびＬｏｇＯｕｔＩｎｆｏメッセージのデータ構造を示す。
【０１６５】
【表５】
2010541345.tif 000007
【０１６６】
ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージは必須である。端末からサーバへの方向である。
【０１６７】
表６、および表７は、ＬｏｇＩｎＩｎｆｏメッセージ、およびＬｏｇＯｕｔＩｎｆｏメッセージのデータ構造要素を示す。
【０１６８】
【表６】
2010541345.tif 000008
【０１６９】
【表７】
2010541345.tif 000009
【０１７０】
スキーマにより表されたデータ構造を以下に示す。
【０１７１】
<?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>
【０１７２】
上記のメッセージが端末によりサーバに送信され、サーバにより記憶される。記録すべき状態情報（ユーザ管理情報）を記憶するように、データ構造をサーバ内で構成することもできる。
【０１７３】
【表８】
2010541345.tif 000010
【０１７４】
データ構造のスキーマを以下に示す。
【０１７５】
<?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"/>
【０２４１】
この実施形態では、ＨＴＴＰ  ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、Ｓ４０４での意味と同じである。メッセージボディが、ＬｏｇＯｕｔＩｎｆｏメッセージのＸＭＬデータを含む。
【０２４２】
ＬｏｇＯｕｔＩｎｆｏメッセージは、サービスＩＤおよびユーザＩＤを運ぶ。サーバは端末のログアウト時間、すなわち終了時間を記録する。端末のＬｏｇＯｕｔＩｎｆｏメッセージは、図７に示す形式を使用することがある。このメッセージは対話型チャネルを介して送信される。ＬｏｇＯｕｔＩｎｆｏメッセージは、対話型サーバ内に記憶されることも、統計値データを記録するための特別なサーバ内に記憶されることもある。
【０２４３】
ＬｏｇＯｕｔＩｎｆｏメッセージがＨＴＴＰ  ＰＯＳＴ方式でサーバに送信されることもある。このときに、サーバはＬｏｇＯｕｔＩｎｆｏメッセージを処理し、それをデータベースに追加する。ＬｏｇＯｕｔＩｎｆｏメッセージはまた、ＳＭＳ方式で送信されることもある。ＨＴＴＰ  ＰＯＳＴ方式は一例でしかなく、他のキャリア方式に置き換えることもできる。しかし、その原理および考え方は同じである。
【０２４４】
Ｓ４１５．  ＬｏｇＯｕｔＩｎｆｏメッセージを適切に受信した後に、サーバが２００  ＯＫメッセージを端末に送り返す。
【０２４５】
２００  ＯＫメッセージは、対話型チャネルにより送り返されることも、他の方式によりを送り返されることもある。たとえば、サーバは、応答をピアツーピア方式で端末に送信することも、端末にプッシュすることもある。この実施形態では、２００  ＯＫメッセージは、ＬｏｇＯｕｔＩｎｆｏメッセージをサーバに送信することに成功したことを示す。異なるネットワーク環境で、他の確認方式を使用することもできるが、その考え方および原理は同じである。
【０２４６】
Ｓ４１６．  端末が番組からログアウトした後に、サーバがユーザの対話情報を記憶し、対話型番組にユーザが参加した情報の統計値を作成する。
【０２４７】
サーバは、ユーザが対話型番組を放送している間に送信する対話情報を記憶し、番組終了後にユーザの対話情報の統計値を作成する。最後に、サーバは、ユーザに統計結果をフィードバックすることがある。統計値の内容は、番組に参加した詳細であることも、番組の全対話結果であることもある。たとえば、選択的な対話型番組が終了した後に、対話型サーバが、Ａを選択する視聴者、およびＢを選択する視聴者を数えることができる。この例は、対話更新の結果および形式をより明確に説明することを意図している。
【０２４８】
Ｓ４１７．  サーバが対話型番組の最終的な統計値結果をユーザに送信する。
【０２４９】
端末ユーザは、番組に参加した後に参加結果を得ることができる。この場合、参加結果は、その端末ユーザの参加結果、および番組全体の参加結果を含むことがある。この実施形態では、破線が最終結果の伝送を示し、これは、このステップが任意選択であることを意味する。
【０２５０】
端末が、番組コンテンツを受信している間に対話型番組へのフィードバックを与え、ユーザが行う選択にサーバが応答し、したがって、対話更新が達成される。この実施形態で使用されるメッセージ運搬方式、およびメッセージ伝送方式を他の運搬方式および伝送方式に置き換えることができるが、その原理および考え方は同じである。
【０２５１】
この実施形態では、端末が番組を見ている情報についての統計値を作成できるように、ＬｏｇＯｕｔＩｎｆｏメッセージおよびＬｏｇＩｎＩｎｆｏメッセージがサーバ内に記憶されることがある。そのデータ構造を、表８に似た表、または表８と同じ表の形で記憶することができる。表はサーバに記憶されることも、統計値結果を記録するための特別なデータベースに記憶されることもある。
【０２５２】
モバイルＴＶサービスでのユーザ管理情報を得るためのシステムを本発明の第５の実施形態が提供する。図５に示すように、このシステムは、
ＳＧに含まれる選択番組を端末２０に提供し、認証に成功した後に、端末２０により選択された番組コンテンツを端末２０に送信し、端末２０のユーザ管理情報を記憶するように適合されたサーバ１０と、
起動された場合に、ユーザ管理情報をサーバ１０に送信するように適合された端末２０と
を含む。
【０２５３】
具体的には、サーバ１０は、
端末２０から送信されたユーザ管理情報を受信するように適合された受信モジュール１１と、
番組を見ることを要求する端末２０を認証するように適合された認証モジュール１２と、
端末２０により選択された番組コンテンツを、認証モジュールにより認証された端末２０に送信するように適合された番組送信モジュール１３と、
受信モジュール１１内に記憶された内容に従って端末２０のユーザ管理情報を得るように適合された統計値モジュール１４と、
ＳＧに含まれる選択番組への端末の申し込み、またはその申し込み取り消しを受け入れ、申し込み結果、または申し込み取り消し結果に従って、端末２０のローカルの番組申し込み情報を更新するように適合された番組申し込みモジュール１５と、
対話型番組で端末２０との対話を実現するように適合された対話型番組処理モジュール１６と、
をさらに含む。
【０２５４】
対話型番組処理モジュール１６は、
端末２０に伝送するための番組送信モジュールに対話情報、および／または対話更新情報を追加するように適合された対話情報追加サブモジュール１６１と、
対話情報追加サブモジュール１７１から送信される対話情報、および／または対話更新情報に従って、端末２０により送り返される対話情報応答を受信するように適合された対話応答受信サブモジュール１６２と、
対話応答受信サブモジュール１７２により受信された対話情報応答を処理し、端末２０の対話参加結果を得るように適合された対話結果取得サブモジュール１６３と
をさらに含む。
【０２５５】
端末２０は、
ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュール２１と、
生成されたユーザ管理情報をメッセージの形で送信するように適合されたユーザ管理情報送信モジュール２２と、
をさらに含む。
【０２５６】
前述の実施形態の説明を通じて、ソフトウェア、および必要な一般のハードウェアプラットフォームにより、またはハードウェアだけにより、本発明の実施形態を実現することができることが、当業者には理解することができる。しかし、ほとんどの場合、ソフトウェア、および一般のハードウェアプラットフォームが好まれる。この理解に基づき、本発明の技術的解決策、または従来技術への貢献をソフトウェア成果により実現することができる。ソフトウェア成果は、記憶媒体に記憶され、本発明の実施形態で提供された方法を実行するようネットワーク装置に指示する複数の命令を含む。
【０２５７】
本発明をいくつかの例示的実施形態により説明してきたが、本発明はそのような実施形態に限定されるものではない。当業者が本発明の精神および範囲から逸脱することなく本発明に様々な修正および変形を行うことができることは明らかである。本発明は、修正および変形が添付の特許請求の範囲、またはその均等物により定義される保護の範囲に収まるという前提で、修正および変形を含むものである。
【図１】
2010541345.tif 000011
【図２】
2010541345.tif 000012
【図３】
2010541345.tif 000013
【図４】
2010541345.tif 000014
【図５】
2010541345.tif 000015
【手続補正書】
【提出日】平成22年5月10日(2010.5.10)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
現在、移動ネットワークに基づくモバイルＴＶサービスが、チャイナモバイル社により展開され、汎用パケット無線サービス（ＧＰＲＳ）移動ネットワークに依存している。実際には、このモバイルＴＶサービスは、ストリーミング技術を使用することによりデータサービスとして展開されている。しかし、ユーザが、オペレーティングシステムを有する移動端末（一般には、携帯情報端末（ＰＤＡ））の中にプレーヤをダウンロードしてインストールする必要がある。チャイナモバイル社およびコンテンツ提供業者（ＣＰ）が協力することにより、関連するＴＶ番組コンテンツが提供される。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００７８
【補正方法】変更
【補正の内容】
【００７８】
この実施形態では、ＨＴＴＰ  ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、ステップ２０１での意味と同じである。ＬｏｇＯｕｔＩｎｆｏメッセージ中のＸＭＬデータは、メッセージボディにある。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０１１１
【補正方法】変更
【補正の内容】
【０１１１】
Ｓ３０２．  申し込み済みのチャネルのない端末は、得たＳＧに従ってチャネルを申し込む。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０２４１
【補正方法】変更
【補正の内容】
【０２４１】
この実施形態では、ＨＴＴＰ  ＰＯＳＴ方式を使用して、ＬｏｇＯｕｔＩｎｆｏメッセージでＸＭＬデータ情報をサーバに送信する。ＰＯＳＴメッセージの意味は、Ｓ４０１での意味と同じである。メッセージボディが、ＬｏｇＯｕｔＩｎｆｏメッセージのＸＭＬデータを含む。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０２５４
【補正方法】変更
【補正の内容】
【０２５４】
対話型番組処理モジュール１６は、
端末２０に伝送するための番組送信モジュールに対話情報、および／または対話更新情報を追加するように適合された対話情報追加サブモジュール１６１と、
対話情報追加サブモジュール１６１から送信される対話情報、および／または対話更新情報に従って、端末２０により送り返される対話情報応答を受信するように適合された対話応答受信サブモジュール１６２と、
対話応答受信サブモジュール１６２により受信された対話情報応答を処理し、端末２０の対話参加結果を得るように適合された対話結果取得サブモジュール１６３と
をさらに含む。
【手続補正６】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サーバがユーザ管理情報を得るための方法であって、
前記サーバによって、ユーザ管理情報を運ぶメッセージを端末から受信するステップと、
前記サーバによって、前記メッセージから、前記端末の前記ユーザ管理情報を得るステップと、
前記サーバによって、前記ユーザ管理情報を処理するステップと、
を含む方法。
【請求項２】
前記ユーザ管理情報を処理するステップが、
前記サーバによってユーザログイン状態情報を記録する操作、前記サーバによって前記ユーザが見る番組の状態情報を記録する操作、前記サーバによって前記ユーザが更新する必要のあるサービス情報を記録する操作
のうちの少なくとも１つを含み、
前記ユーザログイン状態が、端末ＩＤ、ユーザＩＤ、サービス申し込み関係、ログイン時間、ログイン方式、およびユーザ鍵有効期間のうちの少なくとも１種類を含み、
前記ユーザが見る前記番組の前記状態情報が、前記ユーザが見る前記番組のＩＤ、前記ユーザが見るチャネルのＩＤ、前記ユーザが前記チャネルを見るときの時間、および前記ユーザが前記チャネルからログアウトするときの時間のうちの少なくとも１つを含み、
前記ユーザが更新する必要のある前記サービス情報が、前記ユーザ鍵が更新される必要があるかどうか、前記ユーザの対話情報が更新される必要があるかどうか、前記ユーザのサービスガイド（ＳＧ）が更新される必要があるかどうかのうちの少なくとも１つを含む、
請求項１に記載の方法。
【請求項３】
前記ユーザ管理情報を処理するステップが、
前記サーバによって、前記ユーザ管理情報で運ばれる前記メッセージ送信時間、または、前記端末により送信される、番組の最初のフレーム時間、および最後のフレーム時間に従ってチャネルの番組を見ている時間を得るステップ、
をさらに含む、請求項１に記載の方法。
【請求項４】
前記ユーザ管理情報を処理するステップが、
前記サーバによって、チャネルまたは番組の視聴率を得るステップ、
をさらに含む、請求項１に記載の方法。
【請求項５】
前記チャネルまたは番組の前記視聴率を得るステップが、
前記サーバによって、統計のもとで前記チャネルまたは番組にＩＤを設定するステップと、
前記チャネルまたは番組のコンテンツを受信するとき、またはそこからログアウトするときに、前記サーバによって、前記端末が送信するメッセージを受信するステップと、
前記サーバによって、前記メッセージに従って前記チャネルまたは番組の前記視聴率を得るステップと、
を含む、請求項４に記載の方法。
【請求項６】
前記チャネルまたは番組の前記視聴率を得るステップが、
前記サーバによって、指定されたチャネルまたは番組を見るか否かに関するメッセージをすべての端末、または指定された端末に送信するステップと、
前記サーバによって、前記指定されたチャネルまたは番組を見ている端末からの応答を受信するステップと、
前記サーバによって、前記応答に従って前記チャネルまたは番組の前記視聴率を得るステップと、
を含む、請求項４に記載の方法。
【請求項７】
前記メッセージから前記端末の前記ユーザ管理情報を得た後に、
前記サーバによって、対話型番組の統計値情報を得るステップ、
をさらに含む、請求項１または請求項２に記載の方法。
【請求項８】
対話型番組の統計値情報を得るステップが、
前記端末の前記ユーザ管理情報を受信した後に、前記サーバによって、対話情報、および対話更新情報のうちの少なくとも１つを含む対話型番組を前記端末に送信するステップと、
前記サーバによって、前記端末から対話情報応答を受信するステップと、
前記サーバによって、前記対話情報応答に従って前記対話型番組の統計値情報を得るステップと、
を含む、請求項７に記載の方法。
【請求項９】
ユーザ管理情報を運ぶ前記メッセージを前記端末から受信するステップが、
前記端末が起動されたとき、もしくは、見られる番組またはチャネルを切り換えるときに、前記サーバによって、前記端末から前記ユーザ管理情報を受信するステップ、
を含む、請求項１に記載の方法。
【請求項１０】
前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
前記端末が起動されたとき、もしくは、見られる番組またはチャネルを切り換えるときに、前記サーバによって、前記端末から送信された認証要求に従って前記端末を認証するステップ、
をさらに含む、請求項９に記載の方法。
【請求項１１】
前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
前記サーバによって、前記端末により選択された番組コンテンツを前記端末に送信するステップと、
前記端末の番組コンテンツ受信時間が、前もってセットされた時間を超過したと判断した後に、前記サーバによって、前記端末を認証するステップと、
をさらに含む、請求項１に記載の方法。
【請求項１２】
前記端末の前記ユーザ管理情報を前記メッセージから得た後に、
前記サーバによって、サービスガイド（ＳＧ）に含まれる選択番組を前記端末に提供するステップ、
をさらに含む、請求項１に記載の方法。
【請求項１３】
前記ＳＧに含まれる選択番組を前記端末に提供した後に、
前記サーバによって、前記ＳＧに含まれる選択番組を前記端末が申し込む、またはその申し込みを取り消すのを受け入れるステップと、
前記端末により申し込まれた番組に変更がある場合に、前記サーバによって、前記端末の更新された番組申し込み情報を受信するステップと、
をさらに含む、請求項１２に記載の方法。
【請求項１４】
ユーザ管理情報を得るためのシステムであって、
ユーザ管理情報を端末から受信し、前記端末の前記得られたユーザ管理情報を記憶するように適合されたサーバと、
前記ユーザ管理情報を前記サーバに送信するように適合された前記端末と、
を含むシステム。
【請求項１５】
前記サーバが、
前記端末から送信される前記ユーザ管理情報を受信するように適合された受信モジュールと、
前記受信モジュールにより得られる、前記端末の前記ユーザ管理情報を記憶するように適合された統計値モジュールと、
をさらに含む、請求項１４に記載のシステム。
【請求項１６】
前記端末が、
前記ユーザ管理情報を前記サーバに送信するように適合されたユーザ管理情報送信モジュール、
をさらに含む、請求項１４に記載のシステム。
【請求項１７】
ユーザ管理情報を得るように適合されたサーバであって、
端末から送信されるユーザ管理情報を受信するように適合された受信モジュールと、
前記受信モジュールにより得られる、前記端末の前記ユーザ管理情報を記憶するように適合された統計値モジュールと、
を含むサーバ。
【請求項１８】
サービスガイド（ＳＧ）に含まれる選択番組を前記端末が申し込む、またはその申し込みを取り消すのを受け入れ、申し込み結果、または申し込み取り消し結果に従って、前記端末のローカルの番組申し込み情報を更新するように適合された番組申し込みモジュール
をさらに含む、請求項１７に記載のサーバ。
【請求項１９】
番組を見ることを要求する端末を認証するように適合された認証モジュール
をさらに含む、請求項１７に記載のサーバ。
【請求項２０】
対話型番組で前記端末との対話を実現するように適合された対話型番組処理モジュール
をさらに含む、請求項１７に記載のサーバ。
【請求項２１】
サーバにユーザ管理情報を送信するように適合された端末であって、
ユーザ管理情報を生成するように適合されたユーザ管理情報生成モジュールと、
前記生成されたユーザ管理情報をメッセージの形で送信するように適合されたユーザ管理情報送信モジュールと、
を含む端末。
【国際調査報告】
2010541345.tif 000016
2010541345.tif 000017
2010541345.tif 000018
2010541345.tif 000019