JP2001136508A

JP2001136508A - サーバ装置及び視聴管理システム

Info

Publication number: JP2001136508A
Application number: JP31532299A
Authority: JP
Inventors: Hiroshi Terasaki; 浩寺崎
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1999-11-05
Filing date: 1999-11-05
Publication date: 2001-05-18

Abstract

(57)【要約】【課題】映像・音楽のデータを、例えばＩＥＥＥ１３
９４バスでネットワーク化された宅内に提供するシステ
ムにおいて、バスに接続された複数の記録媒体に記録さ
れた映像・音楽情報の視聴管理を行うシステムを提供す
る。【解決手段】コンテンツ提供者から送信された映像・
音楽情報のデータを、ネットワークを介して複数の録画
機器に送信するサーバ装置であって、前記ネットワーク
に接続された受信端末と前記複数の録画機器との間のデ
ータの送受信を監視する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

【従来の技術】ビデオオンデマンド（以下、ＶＯＤとい
う）システムでは、映像・音楽のデータを１つのビデオ
サーバーに記録しているものであった。そのため、視聴
の管理（課金等）を行う際には、このビデオサーバーの
みを監視していた。一方、近年、デジタル放送サービス
への注目度が大きくなり、例えばＩＥＥＥ１３９４のよ
うに宅内でも容易にネットワークを構築することができ
る技術の進展とともに、デジタル放送のデータを宅内で
共有するニーズが高まってきていた。

【０００２】ここで、ＩＥＥＥ１３９４とは、米国電気
電子技術者協会（ＩＥＥＥ）が規格化したリアルタイム
伝送の機能を備えるシリアルインタフェース高速伝送路
である。ＩＥＥＥ１３９４の特徴としては、１００Ｍｂ
ｐｓ、２００Ｍｂｐｓ、４００Ｍｂｐｓなどといった高
速な通信が可能という点が挙げられる。

【０００３】

【発明が解決しようとする課題】従来のVODシステムで
は、基本的に１つのビデオサーバからデータを出力する
形態を取り、そのビデオサーバのみを監視することで視
聴管理を行ってきたため、視聴の管理が容易であるとい
う利点はある。しかしながら、このＶＯＤシステムで
は、宅内システムにおいて視聴管理をすることができな
い。なぜならば、宅内には、ビデオデッキやパーソナル
コンピュータなどの記録機器が複数個存在するため、各
記録機器から、いつ、何のコンテンツが、何回、読み出
されたのかを認識し、管理することができないからであ
る。また、従来のＶＯＤシステムでは、データを複数の
記録機器に分散して保存させることもできない。

【０００４】そこで、本発明では、映像・音楽のデータ
を、例えばＩＥＥＥ１３９４バスでネットワーク化され
た宅内に提供するシステムにおいて、バスに接続された
複数の記録媒体に記録された映像・音楽情報の視聴管理
を行うシステムを提供する。

【０００５】

【課題を解決するための手段】本発明は、ＣＳディジタ
ル、ＢＳディジタル、地上波(アナログまたはディジタ
ル)放送、ケーブルテレビ放送、加入者系光ファイバー
通信、ATM通信、無線通信など様々な放送網・通信網を
介して家庭に送信される映像・音声情報を、宅内サーバ
を経由させて宅内の受信端末に配信する際に、視聴管理
を行う。そのために、宅内サーバーは、宅内の記録機器
へデータを送信する前に、送信するデータに管理対象の
情報を埋め込み、かつ、その管理対象の情報の履歴を記
録し、さらには、ネットワーク上を常時監視することに
より、ネットワーク上に流れているデータを監視する。

【０００６】

【発明の実施の形態】図１は、本発明の第一の実施の形
態を示すブロック図である。図１において、宅外のコン
テンツ提供者から送信された映像・音楽情報のデータ
は、宅内の受信チューナ１で受信される。受信チューナ
１は、そのデータを宅内サーバ２に送信する。宅内サー
バ２は、ＩＥＥＥ１３９４バス等の家庭内ネットワーク
に接続されている録画機器３に受信データを送出する。
このとき、宅内サーバ２による視聴管理機能の実現を容
易にするため、宅内サーバー２は、データを送信する
際、視聴管理対象データであることを示す情報を送信デ
ータの中に埋め込み、さらに、データの情報（例えば、
データの内容、種類、日時等）を自己のデータベース６
に登録する。録画機器３は宅内サーバ２から送信された
データを受信し、記録する。一方、受信端末４ａ、４
ｂ、４ｃは随時、宅内サーバ２のデータベースにアクセ
スし、どの記録媒体に何のデータがあるのかを検索し、
その検索結果に基づいて、録画機器からデータを読み込
む。宅内サーバー２は、録画機器３から受信端末４ａ、
４ｂ、４ｃ、４ｄへのデータの流れを常に監視し、デー
タ中に埋め込まれた課金情報等を抽出する。

【０００７】次に、この実施の形態における動作を説明
する。

【０００８】図１において、宅内サーバ２は、チューナ
１から送信されたデータを録画機器３に送出する際に１
３ビットのＰＩＤの値を変更する。ここで、ＰＩＤにつ
いてまず説明する。

【０００９】例えば、コンテンツ提供者から提供される
データが、MPEG2(Moving Picture Experts Group Phase
2)などの圧縮映像・音声データ形式であるとする。MPEG
2規格では、デジタル放送への応用を考慮し、複数番組
の時分割多重伝送を行うトランスポート・ストリーム
（以下、MPEG2-TSという）が規定されている。これによ
り、従来のアナログ放送では、通信衛星の１つのトラン
スポンダ（１チャンネル）で１番組しか放送できなかっ
たのに対し、MPEG2-TSを利用したデジタル放送では、複
数の番組を時分割多重放送ができる。そのため、受信端
末のチューナにおけるチャンネル選択だけで、所望の番
組を視聴することができる。つまり、MPEG2-TS形式で時
分割多重されて送られてくる複数の番組から選択分離を
行う必要がある。

【００１０】MPEG2-TSは、図４に示す１８８バイト固定
長のTSパケットで構成され、TSパケットは、４バイトの
パケットヘッダと１８４バイトのデータ領域から構成さ
れており、パケットヘッダには、同期パターンを先頭
に、１３ビットのパケット識別子ＰＩＤ（Packet Ident
ifier）などの情報が含まれている。データ領域には、
各種データがTSパケット単位で格納される。

【００１１】例えば、図１５に示すように、１チャンネ
ル当たり２つの番組を時分割多重して放送する場合を示
す。番組データは、時分割多重して放送する各番組の映
像・音声データであり、具体的には、各番組に対応した
MPEG2のビデオデータとMPEG2のオーディオデータであ
る。

【００１２】プログラム仕様情報であるPSI（Program S
pecific Information）データは、受信端末で前記番組
選択を容易に行なうことができるようにするための情報
であり、具体的には、PAT（Program Association Tabl
e），各番組に対応したPMT（Program Map Table）及びN
IT（Network Information Table）などである。

【００１３】これら番組データとPSIデータには、各々
固有のPIDが割り当てられ、TSパケット単位で時分割多
重される。このため、TSパケットのPIDにより、当該TS
パケットのデータ領域に格納されているデータ種別を識
別できるようになっている。

【００１４】PATには、MPEG2-TSで時分割多重して放送
される全ての番組に対応するPMTのPIDがプログラム番号
と対に記載されている。図１６に示す例では、プログラ
ム番号「１」が付された番組１に対応するPMTのPID（＝
「１１」）と、プログラム番号「２」が付された番組２
に対応するPMTのPID（＝「１２」）が記載される。さら
に、PATには、NITのPIDが記載される。MPEG2規格によ
り、NITに対しては固定的にプログラム番号「０」が割
り当てられているため、プログラム番号「０」と対にNI
TのPIDが記載されるPMTは各番組毎に存在し、階層的に
は、PATの下に位置する。従って、図１６に示す例で
は、番組１のPMTと番組２のPMTが存在することになる。
各番組のPMTには、各番組固有のプログラム番号ととも
に、その番組を構成する映像情報及び音声情報が伝送さ
れるTSパケットのPIDが記載されている。このように、P
ATやPMTはMPEG2規格でデータ構成の詳細が定義されてい
る。

【００１５】さて、変更後のPIDの値を、以後、コンテ
ンツIDと称する。変更方法としては、例えば、１３ビッ
トのコンテンツＩＤのうち、先頭のビットを視聴管理対
象であることを示すビットと定義した場合、図２に示す
ように視聴管理対象である番組のＰＩＤの先頭１ビット
が「０」であれば、「１」に変更し、視聴管理対象でな
い番組のＰＩＤの先頭１ビットが「１」であれば、
「０」にする。

【００１６】これと同時に、宅内サーバ２は、記録機器
３にデータを送信する前に、図３に示すフォーマットの
番組の情報（例えば、コンテンツID、日時、番組名、記
録場所、視聴回数等）テーブルを、自己のデータベース
６に登録し、その内容を随時更新する。録画機器３は、
宅内サーバ２から送信されたデータを受信し、保存す
る。

【００１７】一方、ユーザは、受信端末４ａ、４ｂ、４
ｃのいずれかから録画機器３にあるデータを取得する
際、まず、データベース６にアクセスし、どの記録媒体
に何のデータがあるかを検索する。ユーザは、その検索
結果をもとに、必要な情報が保存されている記録機器を
選択し、そこからデータを読み込む。

【００１８】また、宅内サーバ２は、ＩＥＥＥ１３９４
で接続されている録画機器と受信端末との間のデータ送
受信を監視する。監視中、ＩＥＥＥ１３９４を流れるデ
ータが視聴管理対象のデータであれば、視聴管理処理を
行う。すなわち、宅内サーバー２は、どの記録機器がど
のようなデータ（コンテンツID、日時、番組名、記録場
所、視聴回数など）を送信し、どの受信端末がどのよう
なデータを受信しているのかを監視し、随時、データベ
ース上の視聴回数等を更新する。なお、視聴管理対象の
データであるか否かは、コンテンツIDの先頭ビットを見
ることにより容易に判別できる。

【００１９】次に、本発明の第二の実施の形態について
説明する。

【００２０】第二の実施の形態では、ＰＩＤに埋め込ん
でいた視聴管理情報を電子透かしで実現する。電子透か
しは、コンテンツ自体に情報を埋め込む技術であり、透
かし情報は、コンテンツ全域にわたり分散配置され、編
集、圧縮、伝送などの処理に対して変質、もしくは消失
しないという特徴がある。宅内サーバ２から録画機器３
にデータを送信する際、この電子透かしをMPEG2-TSに埋
め込む。つまり、図４のデータ領域に埋め込む。その
後、サーバーは、受信端末と録画機器間との間のデータ
のやりとりを監視し、ネットワーク上に流れているデー
タに対し、電子透かし抽出処理を施すことで視聴管理を
行う。電子透かしの手法の一例は、松井著「電子透かし
の基礎」、森北出版等で紹介されている。ここで、本発
明の趣旨からは多少はずれるが、参考までに、MPEG2に
電子透かしを埋め込む例を示す。MPEG2では、コンシー
ルメント動きベクトルと呼ばれるイントラマクロブロッ
クに動きベクトル情報を含むことができる。これによ
り、伝送情報のエラーによって復号不能なマクロブロッ
クが発生したときに、周辺のマクロブロックから近似的
に再生する場合にこの情報を利用する。この概念を透か
しに適用すると、MPEG2では、動きベクトルを図５に示
すように画素A,B,C,D間を直線補間した仮想的な0.5画素
の精度を用いて動き補償予測方式で推定している。そこ
で、同図の○印と×印の画素について次の選択基準を導
入する（図６）。もし、透かしビットが0ならば、○印
の画素の中で最も近くにあるものをベクトルの予測方向
に採用し、一方、透かしビットが1ならば、×印の画素
の中で最も近くにあるものを採用することに規定する。
実際は、マクロブロック単位にこの原理を適用する。ま
ず1画素単位に縦(i)と横(j)について-15から+15の画素
を探索してフレーム間差分量、すなわち、(i,j)座標の
画素値をx_i,jで表すとき、

【００２１】

【数１】

【００２２】を満たす画素位置(a₀,b₀)を求める。ただ
し、(f-1)は被参照フレーム、(f)は参照フレームを示
す。この(a₀,b₀)がフレームfにおけるこのブロックの最
適動きベクトルを表している。さらに、半画素単位で動
きベクトルを求めるために、参照画素の周囲の8この半
画素の中から次の条件に従って新しい動きベクトルを探
索する。すなわち、もし透かしビットが0ならば、

【数２】について

【数３】を満たす画素位置(m₀,n₀)を求める。一方、もし透かし
ビットが1ならば、

【００２３】

【数４】

【００２４】について上記と同じ探索を実行し最小値と
なる画素位置(m₀,n₀)を求める。この結果、微調整され
た画素位置(a₀+m₀,b₀+n₀)をもって透かしビットを埋め
込んだ新しいベクトルとして扱う。この方法では、動き
ベクトルを送った後で、差分データを送るので劣化が少
ない。また、埋め込み可能なデータ量は動きベクトルの
数に比例するので、動きの激しい画像ほど多くなるとい
った特徴がある。

【００２５】次に、本発明の第一の実施例について説明
する。第一の実施の形態と第二の実施の形態において、
ＩＥＥＥ１３９４のコンテンツ保護規格（以下、ＤＴＣ
Ｐという）により、コンテンツが暗号化されている場合
がある。暗号化されているか否かは、図７にようにIEEE
1394のIsochronousパケットヘッダの先頭から29ビット
目と30ビット目の2ビット（以下、EMIとよぶ）で判定を
行う。ここで、ＤＣＴＰについて、簡単に説明する。Ｉ
ＥＥＥ１３９４には、制御コマンドの転送に適した転送
方法（以下、Asynchronous転送と呼ぶ）とリアルタイム
転送に適した転送方法（以下、Isochronous転送と呼
ぶ）が存在する。MPEG2-TSのようなリアルタイム性が求
められるデータの転送には、後者のIsochronous転送を
用いる。このIsochronous転送においては、ＩＥＥＥ１
３９４シリアルバスに接続されている機器は、どのよう
なデータが流れているのか知ることができる。そのた
め、コンテンツの著作権保護のために、ＤＴＣＰ（Digi
tal Transmission Content Protection）が規格化され
た。ＤＴＣＰでは、送信機器と受信機器間で認証を行
い、１つの鍵を共有する。ＤＴＣＰとは、共有した鍵に
よって、送信側が、図８(b),(c)に示すように、ＴＳパ
ケット全体、または、データ領域を暗号化する規格であ
る。

【００２６】さて、このEMIの2ビットが「11」なら、コ
ンテンツのコピー禁止、「10」なら1度だけコピー可、
「01」なら、これ以上のコピー不可、「00」ならコピー
可と定義されており、EMIが「11」、「10」、「01」の
場合は、送信機器から暗号化されてデータが送信されて
いる。EMIが「00」の場合は、データがそのままIEEE139
4上を伝送していることを示している。データが暗号化
されている場合、つまり、EMIの値が「11」、「10」、
「01」の場合、送信機器と認証・鍵交換を行い、鍵を取
得する。

【００２７】認証の方法としては、図９に記載する２種
類の方法が考えられる。一つは、宅内サーバ２が送信機
器と受信機器の中間的な役割を果たす場合である（図９
（ａ））。これは、送信機器と宅内サーバ、受信機器と
宅内サーバがそれぞれ認証を行い、送信機器から出力さ
れた暗号データを宅内サーバが送信機器と共有した鍵で
暗号の解除を行い、そのデータに対して、サーバが受信
機器と共有した鍵で暗号化を行い、送信する。なお、送
信機器と共有した鍵と受信機器と共有した鍵が同一でも
構わない。もう一つは、送信機器と認証を行い、送信機
器と共有した鍵を共有する（図９（ｂ））。ここでは、
送信機器が受信機器に送信しているデータを暗号化する
鍵と送信機器と共有した鍵が同一でなくてはならないと
いう条件がある。暗号化されている箇所を、以下の3通
りの場合について、視聴監視の手順を記述する。

【００２８】送信機器がIEEE1394のIsochronousパケッ
トのデータ領域全体を暗号化する場合（図８(a) ）、第
一の実施の形態、第二の実施の形態のいずれにおいて
も、コンテンツIDを付加した箇所が暗号化されているた
め、サーバが送信機器と認証を行い、鍵を共有する。こ
の鍵を使用し、付加されたコンテンツIDを取得する。MP
EG2-TSのTSパケット全体(188バイト)である場合（図８
(b) ）、第一の実施の形態、第二の実施の形態のいずれ
においても、コンテンツIDを付加した箇所が暗号化され
ているため、サーバが送信機器と認証を行い、鍵を共有
する。この鍵を使用し、付加されたコンテンツIDを取得
する。TSパケットのデータ領域(184バイト)である場合
（図８(c) ）、第一の実施の形態では、コンテンツIDが
暗号化されていないため、そのまま取得可能である。第
二の実施の形態では、コンテンツIDを付加した箇所が暗
号化されているため、サーバが送信機器と認証を行い、
鍵を共有する。この鍵を使用し、付加されたコンテンツ
IDを取得する。

【００２９】第二の実施例では、第一の実施の形態と第
二の実施の形態を同時に行う。つまり、コンテンツIDを
PIDの箇所に付加し、データ部に電子透かしを挿入す
る。この場合、第一の実施例で記述した３つの場合のう
ち、暗号箇所がTSパケットのデータ領域(184バイト)で
ある場合（図８(c) ）、第一の実施の形態では、コンテ
ンツIDがそのまま表されているが、第二の実施の実施の
形態では、暗号化されている。そのため、サーバが送信
機器と認証を行い、鍵を共有する（図９）。この鍵を使
用し、付加されたコンテンツIDを取得する。

【００３０】第三の実施例では、宅内サーバがデータを
記録媒体に送信する際、後述する視聴管理パケットと呼
ぶパケットを、あらかじめ決めていた間隔もしくはラン
ダムな間隔で送信し、記録媒体自体に記録する方法が考
えられる（図１０）。例えば、視聴管理パケットをＰＩ
Ｄの１３ビットがすべて「０」と定義した場合、サーバ
へに入力されるデータのＰＩＤのビットがすべて「０」
であった場合、少なくても１３ビットのうち１ビットを
「１」に変更する。サーバは、図３のように、視聴管理
パケット「０」、ビデオパケット「１」、音声パケット
「２」（「」内は、ＰＩＤの値とする）を記録媒体へ出
力する。録画機器側は、視聴管理パケット「０」、ビデ
オパケット「１」、音声パケット「２」の３種類を記録
する。これにより、録画機器から出力されるパケット
は、サーバが変更した３種類のＰＩＤが存在し、視聴管
理パケット「０」を監視することで視聴管理対象である
ことを判別できる。

【００３１】第四の実施例では、本発明を課金管理に利
用する。サーバでコンテンツIDを付加するため、サーバ
から入力されるデータについて管理が可能となる。バス
上を流れるデータのコンテンツIDを常に監視することに
より、どの番組をどの端末が何回視聴したのかがわか
る。例えば、視聴回数に応じた課金方法では、本発明が
有効な手法となる。

【００３２】第五の実施例では、Asynchronous転送で送
信機器側に問合せを行う。この方法を適用すると、暗号
化されていてもコンテンツＩＤを取得できる。図１１に
示すように、送信機器、または、受信機器に現在、転送
を行っているデータのコンテンツＩＤを問い合わせるも
のである。サーバから送信機器にコンテンツＩＤを問い
合わせる場合、送信機器は、あらかじめデータを送信す
るとき、もしくはコンテンツＩＤの送信要求があった
時、コンテンツＩＤを取得し、送信機器に搭載されてい
るメモリ等の記録媒体にコンテンツＩＤを記録する。サ
ーバからコンテンツＩＤの要求があった場合、この記録
媒体からコンテンツＩＤを読み出し、Asynchronous転送
でサーバに送信する。

【００３３】サーバから受信機器にコンテンツＩＤを問
い合わせる場合、受信機器は、データを受信する際にコ
ンテンツＩＤを取得し、受信機器に搭載されているメモ
リ等の記録媒体にコンテンツＩＤを記録する。サーバか
らコンテンツＩＤの要求があった場合、この記録媒体か
らコンテンツＩＤを読み出し、Asynchronous転送でサー
バに送信する。

【００３４】第六の実施例では、例えば、Isochronous
パケットのヘッダ領域（図１２）、または、データ領域
（図１３）にコンテンツＩＤを表す領域を規定する。デ
ータ領域にコンテンツＩＤを追加する場合、第一の実施
例でも述べたＩＥＥＥ１３９４のコンテンツ保護技術
（ＤＴＣＰ）により暗号化される場合がある、その場合
は、第一の実施例に従い、送信機器との認証・鍵交換で
暗号を解除できる鍵を共有し、暗号を解除してコンテン
ツＩＤを取得する。

【００３５】第七の実施例では、サーバが複数存在する
場合、外部から入力したデータ情報を他のサーバに送信
または受信する（図１４）。これにより、管理精度の向
上が期待される。

【００３６】第八の実施例では、サーバが所有する課金
情報を情報提供者へ通知する場合がある。情報を受信す
る側のサーバは、電話回線・ＩＳＤＮ等の通信網を使用
し情報提供者が用意したサーバへ課金情報を送信する。

【００３７】第九の実施例では、第十の実施例で情報提
供者へ課金情報等を通知する際、情報提供者が用意した
サーバと課金情報を所有するサーバ間で認証を行いデー
タを暗号化する鍵を共有する。受信側のサーバは、情報
提供者へ課金情報等を通知する際、共有した鍵により送
信データを暗号化することで課金情報等を第三者に知ら
れないようにすることができる。

【００３８】第十の実施例では、サーバがネットワーク
上に流れるコンテンツのタイプ・視聴回数等の情報を監
視し、その情報を電話回線・ＩＳＤＮ等の通信網を使用
し情報提供者が用意したサーバへ送信する。これによ
り、情報提供者は、人気のあるコンテンツ、複数回視聴
されることが多いコンテンツ等のさまざまなま情報を取
得することができ、効率的なコンテンツ提供が可能とな
る。

【００３９】

【発明の効果】第一の効果は、宅内における視聴管理が
可能になるという点である。その理由は、視聴管理サー
バが常にネットワーク上のデータの流れを監視している
ため、いつどのようなデータをどの端末がデータを送受
信しているのかがわかるからである。

【００４０】第二の効果は、デジタル著作物を分割して
保管できるという点である。その理由は、複数の記録媒
体が存在する場合でもデータの流れが常に監視されてい
るため、複数に分割記録することができるからである。

【００４１】第三の効果は、設置コストを抑えることが
できるという点である。その理由は、宅内に大規模なビ
デオサーバを導入せずに宅内に存在するパーソナルコン
ピュータ、ビデオデッキ等で実現することが可能である
からである。

【００４２】第四の効果は、ユーザが視聴したコンテン
ツのタイプ・視聴回数等を情報提供者が取得できるとい
う点である。その理由は、サーバがネットワーク上に流
れるコンテンツを監視し、その結果を情報提供者にフィ
ードバックできるためである。

【図面の簡単な説明】

【図１】本発明の第一の実施の形態を示すブロック図

【図２】視聴管理対象データのＰＩＤ

【図３】番組の情報テーブル

【図４】ＭＰＥＧ２−ＴＳのＴＳパケットの構成

【図５】ＭＰＥＧ２に電子透かしを埋め込む例

【図６】ＭＰＥＧ２に電子透かしを埋め込む例

【図７】ＩＥＥＥ１３９４のパケットヘッダ

【図８】暗号化する領域を示す図

【図９】認証を行う方法を示す図

【図１０】視聴管理パケットの例

【図１１】コンテンツＩＤの取得方法を示す図

【図１２】コンテンツＩＤを表す領域

【図１３】コンテンツＩＤを表す領域

【図１４】複数のサーバ装置が存在する場合のシステ
ム構成例

【図１５】１チャンネル当たり２つの番組を時分割多
重して放送する場合のＰＩＤの例

【図１６】ＰＡＴの例

【符号の説明】

１受信チューナ２サーバ装置３録画機器４受信端末６データベース

Claims

【特許請求の範囲】

【請求項１】コンテンツ提供者から送信された映像・
音楽情報のデータを、ネットワークを介して複数の録画
機器に送信するサーバ装置であって、前記ネットワーク
に接続された受信端末と前記複数の録画機器との間のデ
ータの送受信を監視することを特徴とするサーバ装置。
【請求項２】前記サーバ装置は、データ中から課金情
報を抽出することを特徴とする請求項１記載のサーバ装
置。
【請求項３】前記サーバ装置は、データベースを備
え、データを送信する際に、視聴管理対象データである
ことを示す情報を送信データの中に埋め込むとともに、
送信データの種別を表す情報を前記データベースに登録
し、前記ネットワーク上のデータの流れに応じて、当該
データベース上の情報を更新することを特徴とする請求
項１又は２に記載のサーバ装置。
【請求項４】コンテンツ提供者から送信された映像・
音楽情報のデータを受信する受信チューナと、受信端末
及び録画機器を接続したネットワークと、前記映像・音
楽情報のデータを前記受信チューナから受信し、前記録
画機器に送出するサーバ装置と、前記録画機器から前記
映像・音楽情報を読み込む前記受信端末とから構成され
る視聴管理システムにおいて、前記サーバ装置は、前記受信端末と前記録画機器との間
のデータの送受信を監視することを特徴とする視聴管理
システム。
【請求項５】前記サーバ装置は、データ中から課金情
報を抽出することを特徴とする請求項４記載の視聴管理
システム。
【請求項６】前記サーバ装置は、データベースを備
え、データを送信する際に、視聴管理対象データである
ことを示す情報を送信データの中に埋め込むとともに、
送信データの種別を表す情報を前記データベースに登録
し、前記ネットワーク上のデータの流れに応じて、当該
データベース上の情報を更新することを特徴とする請求
項４又は５に記載の視聴管理システム。
【請求項７】前記ネットワークは、ＩＥＥＥ１３９４
シリアルバスであることを特徴とする請求項１、２又は
３に記載のサーバ装置。
【請求項８】前記ネットワークは、ＩＥＥＥ１３９４
シリアルバスであることを特徴とする請求項４、５又は
６に記載の視聴管理システム。
【請求項９】前記映像・音楽情報のデータが、ＭＰＥ
Ｇ２による圧縮データであることを特徴とする請求項
１、２、３又は７に記載のサーバ装置。
【請求項１０】前記映像・音楽情報のデータが、ＭＰ
ＥＧ２による圧縮データであることを特徴とする請求項
４、５、６又は８に記載の視聴管理システム。
【請求項１１】前記映像・音楽情報のデータが、ＭＰ
ＥＧ２による圧縮データであり、前記視聴管理対象デー
タであることを示す情報をパケット識別子に挿入するこ
とを特徴とする請求項３記載のサーバ装置。
【請求項１２】前記映像・音楽情報のデータが、ＭＰ
ＥＧ２による圧縮データであり、前記視聴管理対象デー
タであることを示す情報を電子透かしとして挿入するこ
とを特徴とする請求項３記載のサーバ装置。
【請求項１３】前記送信データが暗号化されているこ
とを特徴とする請求項７に記載のサーバ装置。
【請求項１４】前記送信データが暗号化されているこ
とを特徴とする請求項８に記載の視聴管理システム。
【請求項１５】前記サーバ装置が複数個存在し、一の
サーバ装置が、コンテンツ提供者から送信された映像・
音楽情報のデータを、ネットワークを介して、他のサー
バ装置に送信することを特徴とする請求項４、５又は６
に記載の視聴管理システム。