JP3474459B2 - 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、送信装置および送
信方法、受信装置および受信方法、並びに送受信装置お
よび送受信方法に関し、特に、例えば、分散型データベ
ースにおける多数のデータベースへのデータの配信を行
う場合や、ＩＰ（Internet Protocol）マルチキャスト
によりデータを配信する場合、その他データを不特定多
数に配信する場合などに用いて好適な送信装置および送
信方法、受信装置および受信方法、並びに送受信装置お
よび送受信方法に関する。

【０００２】

【従来の技術】データの配信手法としては、種々の手法
が提案されているが、例えば、現在のインターネット上
においては、http（Hyper Text Transfer Protocol）の
ようなＴＣＰ／ＩＰ（Transmission Control Protocol/
Internet Protocol）を基本とするプロトコルが採用さ
れている。ＴＣＰ／ＩＰでは、データの配信を受ける受
信側から、データの送信側に対して、発呼が行われ、さ
らに、データの送受信を行うごとに、送信側と受信側と
の間で、コネクションが確立されるので、信頼性の高い
データの配信を行うことができる。しかしながら、その
反面、送信側やネットワークの負荷が大きくなり、効率
的なデータ配信を行うことが困難になる場合があった。

【０００３】即ち、データの提供を受ける端末が増大
し、データを提供するサーバへのアクセスが集中する
と、サーバやネットワークに多大な負荷がかかり、デー
タを要求しても、そのデータを得るまでに、多大な時間
を要することがあった。

【０００４】そこで、データの配信を、例えば、広い地
域に亘って、一斉同報が可能な衛星回線やＣＡＴＶ網な
どを用いて行う方法が提案されている。この場合、端末
の増加によって、サーバやネットワークに対する負荷が
影響を受けることはない。

【０００５】

【発明が解決しようとする課題】ところで、衛星回線な
どを用いて、データの配信を行う場合、受信側では、所
望のデータが、どのチャンネル（衛星回線であれば、ど
のトランスポンダの、どの周波数帯域か）で、さらに
は、いつ放送されてくるか分からないため、常時、すべ
てのチャンネルを監視している必要があり、受信側の負
担が大になる。

【０００６】本発明は、このような状況に鑑みてなされ
たものであり、受信側の負担の増加を抑制することがで
きるようにするものである。

【０００７】

【課題を解決するための手段】本発明の送信装置は、コ
ンテンツの更新を報知するための報知データであって、
その報知データを取捨選択するための基準として用いる
ことのできる選択基準情報、およびその選択基準情報と
同一の選択基準情報が配置される報知データを認識する
ための認識情報を、少なくとも配置したものを構成する
構成手段と、報知データを送信する送信手段とを備え、
報知データに配置された認識情報は、その報知データが
送信された後、そこに配置された選択基準情報と同一の
選択基準情報が配置された報知データの送信が開始され
る送信時刻を含むことを特徴とする。構成手段は、コン
テンツの更新を行うための更新データが送信される送信
帯域をさらに配置したものを構成するようにすることが
できる。

【０００８】本発明の送信方法は、コンテンツの更新を
報知するための報知データであって、その報知データを
取捨選択するための基準として用いることのできる選択
基準情報、およびその選択基準情報と同一の選択基準情
報が配置される報知データを認識するための認識情報
を、少なくとも配置したものを構成し、報知データを送
信し、報知データに配置された認識情報は、その報知デ
ータが送信された後、そこに配置された選択基準情報と
同一の選択基準情報が配置された報知データの送信が開
始される送信時刻を含むことを特徴とする。

【０００９】本発明の受信装置は、コンテンツの更新を
報知するための報知データであって、その報知データを
取捨選択するための基準として用いることのできる選択
基準情報、およびその選択基準情報と同一の選択基準情
報が配置される報知データを認識するための認識情報
を、少なくとも配置したものを受信する受信手段と、選
択基準情報に基づき、報知データを選択する選択処理を
行うとともに、認識情報に基づき、選択処理を制御する
選択手段と、選択処理によって選択された報知データに
基づいて、コンテンツを更新するための処理を行う処理
手段とを備え、報知データに配置された認識情報は、そ
の報知データが送信された後、そこに配置された選択基
準情報と同一の選択基準情報が配置された報知データの
送信が開始される送信時刻を含み、選択手段は、所定の
報知データを選択した後、その報知データに配置された
認識情報に含まれる送信開始時刻まで、選択処理を中断
することを特徴とする。

【００１０】本発明の受信方法は、コンテンツの更新を
報知するための報知データであって、その報知データを
取捨選択するための基準として用いることのできる選択
基準情報、およびその選択基準情報と同一の選択基準情
報が配置される報知データを認識するための認識情報
を、少なくとも配置したものを受信し、選択基準情報に
基づき、報知データを選択する選択処理を行うととも
に、認識情報に基づき、選択処理を制御し、選択処理に
よって選択された報知データに基づいて、コンテンツを
更新するための処理を行い、報知データに配置された認
識情報は、その報知データが送信された後、そこに配置
された選択基準情報と同一の選択基準情報が配置された
報知データの送信が開始される送信時刻を含み、所定の
報知データを選択した後、その報知データに配置された
認識情報に含まれる送信開始時刻まで、選択処理を中断
することを特徴とする。

【００１１】本発明の送受信装置は、送信装置が、コン
テンツの更新を報知するための報知データであって、そ
の報知データを取捨選択するための基準として用いるこ
とのできる選択基準情報、およびその選択基準情報と同
一の選択基準情報が配置される報知データを認識するた
めの認識情報を、少なくとも配置したものを構成する構
成手段と、報知データを送信する送信手段とを備え、受
信装置が、報知データを受信する受信手段と、選択基準
情報に基づき、報知データを選択する選択処理を行うと
ともに、認識情報に基づき、選択処理を制御する選択手
段と、選択処理によって選択された報知データに基づい
て、コンテンツを更新するための処理を行う処理手段と
を備え、報知データに配置された認識情報は、その報知
データが送信された後、そこに配置された選択基準情報
と同一の選択基準情報が配置された報知データの送信が
開始される送信時刻を含み、選択手段は、所定の報知デ
ータを選択した後、その報知データに配置された認識情
報に含まれる送信開始時刻まで、選択処理を中断するこ
とを特徴とする。

【００１２】本発明の送受信方法は、コンテンツの更新
を報知するための報知データであって、その報知データ
を取捨選択するための基準として用いることのできる選
択基準情報、およびその選択基準情報と同一の選択基準
情報が配置される報知データを認識するための認識情報
を、少なくとも配置したものを構成し、報知データを送
信する一方、報知データを受信し、選択基準情報に基づ
き、報知データを選択する選択処理を行うとともに、認
識情報に基づき、選択処理を制御し、選択処理によって
選択された報知データに基づいて、コンテンツを更新す
るための処理を行い、報知データに配置された認識情報
は、その報知データが送信された後、そこに配置された
選択基準情報と同一の選択基準情報が配置された報知デ
ータの送信が開始される送信時刻を含み、所定の報知デ
ータを選択した後、その報知データに配置された認識情
報に含まれる送信開始時刻まで、選択処理を中断するこ
とを特徴とする。

【００１３】本発明の送信装置および送信方法において
は、コンテンツの更新を報知するための報知データであ
って、その報知データを取捨選択するための基準として
用いることのできる選択基準情報、およびその選択基準
情報と同一の選択基準情報が配置される報知データを認
識するための認識情報を、少なくとも配置したものが構
成され、報知データが送信される。なお、認識情報に
は、その報知データが送信された後、そこに配置された
選択基準情報と同一の選択基準情報が配置された報知デ
ータの送信が開始される送信時刻が含まれている。

【００１４】

【００１５】本発明の受信装置および受信方法において
は、コンテンツの更新を報知するための報知データであ
って、その報知データを取捨選択するための基準として
用いることのできる選択基準情報、およびその選択基準
情報と同一の選択基準情報が配置される報知データを認
識するための認識情報を、少なくとも配置したものが受
信され、選択基準情報に基づき、報知データを選択する
選択処理が行われるとともに、認識情報に基づき、選択
処理が制御され、選択処理によって選択された報知デー
タに基づいて、コンテンツを更新するための処理が行な
われる。そして、報知データに配置された認識情報は、
その報知データが送信された後、そこに配置された選択
基準情報と同一の選択基準情報が配置された報知データ
の送信が開始される送信時刻を含み、所定の報知データ
を選択した後、その報知データに配置された認識情報に
含まれる送信開始時刻まで、選択処理が中断される。

【００１６】

【００１７】本発明の送受信装置および送受信方法にお
いては、コンテンツの更新を報知するための報知データ
であって、その報知データを取捨選択するための基準と
して用いることのできる選択基準情報、およびその選択
基準情報と同一の選択基準情報が配置される報知データ
を認識するための認識情報を、少なくとも配置したもの
が構成され、報知データが送信され、受信される。そし
て、選択基準情報に基づき、報知データを選択する選択
処理が行われるとともに、認識情報に基づき、選択処理
が制御され、選択処理によって選択された報知データに
基づいて、コンテンツを更新するための処理が行なわれ
る。そして、報知データに配置された認識情報は、その
報知データが送信された後、そこに配置された選択基準
情報と同一の選択基準情報が配置された報知データの送
信が開始される送信時刻を含み、所定の報知データを選
択した後、その報知データに配置された認識情報に含ま
れる送信開始時刻まで、選択処理が中断される。

【００１８】

【００１９】

【発明の実施の形態】図１は、本発明を適用したデータ
配信システム（本明細書中において、システムとは、複
数の装置が論理的に集合した物をいい、各構成の装置が
同一筐体中にあるか否かは問わない）の一実施の形態の
構成例を示している。

【００２０】情報提供者Ａ乃至Ｃは、各種のデータが記
憶されたデータベース１ａ乃至１ｃを有している。な
お、データベース１ａ乃至１ｃには、例えば、交通情
報、天気情報、株価情報その他のリアルタイムで変化す
るデータや、そのようにリアルタイムでは変化しないも
の、さらには、テキストデータ、画像データ、音声デー
タ、コンピュータプログラムなどのあらゆるもの（ポイ
ントキャストによって提供されるフォーマットのデータ
や、ＷＷＷ（World Wide Web）で提供されるホームペー
ジを構成するデータなども含む）を記憶させることがで
きるようになされている。ここで、例えば、交通情報
や、天気情報などのひとまとまりの情報（例えば、１の
ファイル）を、以下、適宜、コンテンツ（contents）ま
たはオブジェクト（object）という。

【００２１】データベース１ａ乃至１ｃに記憶されたオ
ブジェクト（コンテンツ）が更新されると、即ち、デー
タベース１ａ乃至１ｃに記憶されたオブジェクトが変更
されたり、また、そこにオブジェクトが新規に登録され
たり、あるいは、そこに記憶されているオブジェクトが
削除されると、その更新を行うための更新オブジェクト
情報が、放送局を構成するサーバ２に送信され、サーバ
２では、その更新オブジェクト情報に基づいて、データ
ベース３が更新される。

【００２２】ここで、更新オブジェクト情報としては、
オブジェクトが変更された場合は、例えば、その変更後
のオブジェクトが、新規のオブジェクトが登録された場
合は、例えば、その新規のオブジェクトが、オブジェク
トが削除された場合は、例えば、そのオブジェクトの削
除指令が、それぞれデータベース１ａ乃至１ｃからサー
バ２に対して送信される。なお、この場合、更新オブジ
ェクト情報は、オブジェクトが変更されたときには、そ
の変更後のオブジェクトに等しく、また、新規のオブジ
ェクトが登録されたときには、その新規のオブジェクト
に等しい。

【００２３】サーバ２は、更新オブジェクト情報に基づ
き、データベース３の登録内容を更新すると、その更新
オブジェクト情報を、例えば、アナログ公衆網や、ＩＳ
ＤＮ（Integrated Services Digital Network）、イン
ターネット、その他の、少なくとも双方向通信が可能な
ネットワークである通信ネットワーク６や専用線などを
介してミラーサーバ７に送信する。ミラーサーバ７は、
サーバ２からの更新オブジェクト情報を受信し、その更
新オブジェクト情報に基づいて、データベース８を更新
する。従って、データベース３と８との登録内容は、常
時、同一になるようになされている。

【００２４】さらに、サーバ２は、データベース３の登
録内容を更新すると、更新オブジェクト情報に、その更
新オブジェクト情報によって更新されるオブジェクトを
識別するための識別子を付加したデータ（以下、適宜、
サブジェクト（subject）という）（更新データ）を生
成する。即ち、データベース３に記憶されたオブジェク
トには、各オブジェクトを識別するための識別子が対応
付けられており、更新オブジェクト情報によって更新さ
れるオブジェクトの識別子が、更新オブジェクト情報に
付加されることで、サブジェクトが生成される。

【００２５】また、サーバ２では、サブジェクトを取得
するためのデータも生成される。即ち、サブジェクト
は、後述するように、サーバ２から放送ネットワーク４
を介して送信される場合があり、この場合、サブジェク
トを取得するには、サブジェクトが放送される時刻やチ
ャンネルなどが必要となる。また、サブジェクトは、後
述するように、ＵＲＬ（Uniform Resorce Locator）な
どと対応付けられ、サーバ２やミラーサーバ７で管理さ
れる場合があり、この場合、サブジェクトを取得するに
は、そのＵＲＬが必要となる。そこで、サーバ２では、
このような情報が、サブジェクトを取得するためのデー
タとして生成される。

【００２６】さらに、サーバ２は、サブジェクトを取得
するためのデータに、そのデータに基づいて取得される
サブジェクトによって更新されるオブジェクトの識別子
を付加したデータ（以下、適宜、イベント（event）と
いう）（報知データ）を生成する。ここで、サブジェク
トの生成は、オブジェクトの更新が生じることにより行
われるから、そのようなサブジェクトを取得するための
イベントは、サブジェクトを取得するためのデータであ
ると同時に、オブジェクトの更新を報知するデータであ
るということができる。

【００２７】サーバ２において、サブジェクトと、その
サブジェクトの取得するためのイベントが生成される
と、これらは、所定の送信スケジュールにしたがい、例
えば、衛星回線や、ＣＡＴＶ網、地上波、その他の、少
なくとも、多数のユーザに一斉同報が可能な一方向（双
方向でもよい）のネットワークである放送ネットワーク
４を介して、例えば、ＩＲＤ（Integrated Receiver an
d Decoder）やＳＴＢ(Set Top Box)などでなる受信端末
５に対して送信される。

【００２８】即ち、サブジェクトが生成され、その取得
のためのイベント（そのサブジェクトと同一の識別子が
付加されたイベント）が生成されると、基本的には、ま
ず最初に、イベントが、放送ネットワーク４を介して送
信される。さらに、このようにして送信されたイベント
の中に、サブジェクトの放送時刻やチャンネルなどが記
述されたものがある場合には、その放送時刻に、そのチ
ャンネルで、サブジェクトが、放送ネットワーク４を介
して送信される。

【００２９】ここで、サーバ２においては、例えば、サ
ブジェクトの送信スケジュールがたてられ（放送時刻お
よび放送チャンネルなどが決められ）、その送信スケジ
ュールにしたがって、イベントに、そのサブジェクトの
放送時刻や放送チャンネルなどが記述される。そして、
そのイベントの送信スケジュールがたてられる。

【００３０】また、サブジェクトが、例えば、ＵＲＬに
対応付けられ、サーバ２やミラーサーバ７の管理下にお
かれる場合には、そのＵＲＬを含むイベントが生成さ
れ、放送ネットワーク４を介して送信される。即ち、サ
ブジェクトがサーバ２またはミラーサーバ７の管理下に
おかれる場合には、それぞれ、サーバ２またはミラーサ
ーバ７のＩＰアドレスをドメイン名として有するＵＲＬ
を含むイベントが生成されて送信される。

【００３１】以上のようにして放送ネットワーク４を介
して送信（配信）されてくるイベントは、ユーザの受信
端末５で受信される。受信端末５では、受信したイベン
トのうち、ユーザが所望するオブジェクトについてのも
のが選択され、その選択されたイベントに基づいて、サ
ブジェクトが取得される。

【００３２】即ち、例えば、イベントに、サブジェクト
の放送時刻やチャンネルが含まれている場合には、サー
バ２において、上述したように、その放送時刻に、その
チャンネルで、サブジェクトが、放送ネットワーク４を
介して送信されてくるから、受信端末５では、そのよう
にして送信されてくるサブジェクトが受信される。

【００３３】また、例えば、イベントに、サブジェクト
に対応付けられたＵＲＬが含まれている場合には、受信
端末５は、そのＵＲＬのドメイン名に対応するサーバに
対して、通信ネットワーク６を介してアクセスし、サブ
ジェクトを要求して受信する。

【００３４】具体的には、イベントに含まれるＵＲＬの
ドメイン名に対応するサーバが、例えば、サーバ２であ
れば、サブジェクトは、サーバ２の管理下におかれてい
るから、受信端末５は、通信ネットワーク６を介して、
サーバ２にアクセスし、サブジェクトを取得する。

【００３５】また、イベントに含まれるＵＲＬのドメイ
ン名に対応するサーバが、例えば、ミラーサーバ７であ
れば、サブジェクトは、ミラーサーバ７の管理下におか
れているから、受信端末５は、通信ネットワーク６を介
して、ミラーサーバ７にアクセスし、サブジェクトを取
得する。

【００３６】受信端末５は、以上のようにしてサブジェ
クトを取得した後、そのサブジェクトに基づいて、自身
が記憶しているオブジェクトを更新する。

【００３７】なお、サブジェクトは、サーバ２から放送
ネットワーク４を介して送信されるとともに、サーバ２
やミラーサーバ７の管理下にもおかれることがある。さ
らに、図１の実施の形態では、１のミラーサーバ７だけ
を図示してあるが、ミラーサーバ７と同様の処理を行う
ミラーサーバは、通信ネットワーク６上に複数台設ける
ことができ、この場合、サブジェクトは、その複数のミ
ラーサーバの管理下におくこともできる。また、サブジ
ェクトは、サーバ２から放送ネットワーク４を介して、
あるチャンネルの、ある時刻においてだけ送信されるの
ではなく、複数のチャンネルや複数の時刻に送信される
場合もある。

【００３８】このように、あるサブジェクトを取得する
方法が複数ある場合には、イベントには、その複数の方
法それぞれについての情報（放送時刻や、放送チャンネ
ル、ＵＲＬなど）が含められるが、このうちのいずれの
方法によってサブジェクトを取得するかは、受信端末５
において決定される。即ち、例えば、イベントに、放送
ネットワーク４を介してサブジェクトを送信する時刻が
複数含まれている場合には、受信端末５では、例えば、
現在時刻に最も近い時刻に放送されてくるサブジェクト
が受信されることで、サブジェクトが取得される。ま
た、例えば、イベントに、複数のＵＲＬが含まれている
場合には、受信端末５から最も近い位置にあるサーバの
ものが選択され、そのサーバに対して、通信ネットワー
ク６を介して、サブジェクトの要求が行われることによ
り、サブジェクトが取得される。さらに、例えば、イベ
ントに、放送ネットワーク４を介してサブジェクトを送
信する時刻と、ＵＲＬとが含まれている場合において、
例えば、放送ネットワーク４の回線状態が悪いとき（Ｓ
／Ｎ（Signal/Noise）が低いときなど）には、ＵＲＬに
基づき、上述したようにして、サブジェクトが取得され
る。また、その他、いずれの方法によってサブジェクト
を取得するかは、受信端末５のユーザの操作などに基づ
いて決定するようにすることもできる。

【００３９】以上のようなデータ配信システムによれ
ば、サブジェクトの取得方法が記述されたイベントが、
放送ネットワーク４を介して配信され、受信端末５にお
いて、そのイベントに基づき、サブジェクトが取得さ
れ、オブジェクトの更新が行われるので、受信端末５の
負荷の増大を抑えつつ、効率的なデータ配信を行うこと
ができる。

【００４０】即ち、一般に、オブジェクトの更新（特
に、オブジェクトの変更と新規登録）のための更新オブ
ジェクト情報を含むサブジェクトのデータ量は多く、さ
らに、サブジェクトは、オブジェクトの更新に対応して
生成されるため、いつ発生するか分からない。従って、
そのような不定期に発生し、かつデータ量の多いサブジ
ェクトだけを、なるべく早期に、放送ネットワーク４を
介して送信するとすれば、サーバ２は、現時点において
空いているチャンネルを使用して、サブジェクトを送信
する必要がある。しかしながら、この場合、受信端末５
では、いつ、どのチャンネルで送信されてくるか分から
ないサブジェクトを待つ必要があり、負担が大になる。

【００４１】これに対して、イベントは、サブジェクト
の取得方法の記述を含むものであるから、一般に、その
データ量は、更新オブジェクト情報を含むサブジェクト
よりも、はるかに少なく、このため、例えば、ある狭帯
域のチャンネルの、さらには、決まった時間において送
信することが可能である。従って、この場合、受信端末
５では、そのチャンネルにおいて（さらには、決まった
時間に送信されてくる）イベントを受信すれば良く、そ
の負荷は、サブジェクトの送信を待つ場合に比較して、
はるかに小さくなる。

【００４２】さらに、本実施の形態では、イベントが、
広い地域に亘って一斉同報が可能な放送ネットワーク４
を介して送信されるため、受信端末５の数の増加が、サ
ーバ２や放送ネットワーク４の負荷に影響を与えること
もない。

【００４３】そして、本実施の形態では、サブジェクト
は、通信ネットワーク６を介して提供されるだけでな
く、放送ネットワーク４を介しても提供されるので、サ
ブジェクトの取得のために、サーバ２やミラーサーバ７
にアクセスが集中することはほとんどなく、従って、サ
ブジェクトの効率的な配信が可能となる。

【００４４】なお、放送ネットワーク４と通信ネットワ
ーク６とは、物理的に別々のネットワークである必要は
ない。即ち、放送ネットワーク４を、例えば、ＣＡＴＶ
網で構成する場合においては、そのＣＡＴＶ網は通信ネ
ットワーク６として利用することも可能である。また、
放送ネットワーク４によるデータの配信を、例えば、イ
ンターネットなどを利用したＩＰ（Internet Protoco
l）マルチキャストで行う場合においては、通信ネット
ワーク６は、そのインターネットで構成することも可能
である。

【００４５】さらに、サーバ２からの受信端末５へのデ
ータ（イベントおよびサブジェクト）の送信は、例え
ば、スクランブルをかけて行い、これにより、特定のユ
ーザ（受信契約を結んだユーザ）のみ、データの受信が
可能なようにすることも可能である。

【００４６】次に、図２は、図１のサーバ２の構成例を
示している。

【００４７】通信制御部１１は、例えば、モデムや、Ｔ
Ａ（Terminal Adapter）などで構成され、通信ネットワ
ーク６を介しての通信を制御するようになされている。
資源割当部１２は、放送ネットワーク４を介してのデー
タの送信のための資源割当を行うようになされている。
即ち、資源割当部１２は、登録部１５からのオブジェク
トの更新の知らせを受け、その更新に伴い、イベントお
よびサブジェクトを、放送ネットワーク４を介して送信
するための資源の割当（例えば、イベントおよびオブジ
ェクトの送信チャンネルや、送信時刻（時間）、データ
レート、送信回数（送信頻度）などの決定）を行うよう
になされている。資源割当部１２によるイベントおよび
サブジェクトの送信のための資源の割当結果は、データ
構成部１７および伝送部１８に供給されるようになされ
ている。

【００４８】データ検索部１３は、通信ネットワーク６
を介して受信端末５から送信されているサブジェクトの
要求を、通信制御部１１から受信し、そのサブジェクト
を構成する更新オブジェクト情報を、データベース３か
ら検索する。そして、データ検索部１３は、後述するデ
ータ構成部１７と同様にして、サブジェクトを構成し、
通信制御部１１に供給するようになされている。複製管
理部１４は、ミラーサーバ７（さらには、通信ネットワ
ーク６上の、図示せぬミラーサーバ）を特定するための
情報を管理している。即ち、複製管理部１４は、例え
ば、通信ネットワーク４がインターネットである場合に
は、ミラーサーバ７のＩＰアドレスを記憶している。そ
して、複製管理部１４は、登録部１５からのオブジェク
トの更新の知らせを受けると、その更新のための更新オ
ブジェクト情報を、データベース３から読み出し、通信
制御部１１を制御することで、その更新オブジェクト情
報を、例えば、ミラーサーバ７その他の自身が管理して
いるＩＰアドレスの、通信ネットワーク６上のサーバに
送信するようになされている。なお、複製管理部１４
は、自身が管理している情報を、必要に応じて、データ
構成部１７に供給するようにもなされている。

【００４９】登録部１５は、情報提供者Ａ乃至Ｃのデー
タベース１ａ乃至１ｃから供給される更新オブジェクト
情報を受信し、その更新オブジェクト情報に基づいて、
オブジェクト（データベース３）を更新するようになさ
れている。即ち、情報提供者Ａ乃至Ｃのデータベース１
ａ乃至１ｃからは、更新オブジェクト情報とともに、そ
の更新オブジェクト情報によって更新されるオブジェク
トの識別子も供給されるようになされている。登録部１
５は、この更新オブジェクト情報および識別子を受信
し、その識別子に対応するオブジェクトを、データベー
ス３から検索する。さらに、登録部１５は、そのように
して検索したオブジェクトを、更新オブジェクト情報に
基づいて更新し、その後、オブジェクトを更新した旨
を、資源割当部１２、複製管理部１４、およびデータ構
成部１７に出力する。なお、登録部１５は、データベー
ス１ａ乃至１ｃからの更新オブジェクト情報および識別
子も、データベース３に登録するようになされている。

【００５０】データ構成部１７は、登録部１５からオブ
ジェクトを更新した旨を受信すると、その更新がなされ
たオブジェクトについての更新オブジェクト情報を、デ
ータベース３から読み出し、その更新オブジェクト情報
が配置されたサブジェクトを生成して、伝送部１８に出
力するようになされている。さらに、データ構成部１７
は、そのサブジェクトを取得するためのイベントも生成
し、伝送部１８に出力するようになされている。なお、
データ構成部１７において、イベントの生成は、資源割
当部１２による資源の割当結果や、複製管理部１４から
供給される情報を用いて行われるようになされている。
即ち、データ構成部１７は、サブジェクトが送信される
チャンネルや時刻、データレート、さらには、それを管
理するサーバに関する情報その他を、資源割当部１２に
よる資源の割当結果や、複製管理部１４からの情報から
認識し、イベントに含めるようになされている。

【００５１】伝送部１８は、データ構成部１７からのイ
ベントやサブジェクトを、資源割当部１２の資源の割当
結果にしたがって、即ち、例えば、所定のチャンネル
で、所定の時刻に、所定のデータレートなどで、放送ネ
ットワーク４を介して送信するようになされている。

【００５２】次に、図３は、図１のミラーサーバ７の構
成例を示している。なお、図中、図２のサーバ２におけ
る場合と対応する部分については、同一の符号を付して
ある。即ち、ミラーサーバ７は、資源割当部１２、複製
管理部１４、データ構成部１７、および伝送部１８が設
けられていない他は、基本的に、サーバ２と同様に構成
されている。なお、ミラーサーバ７を構成する登録部１
５には、サーバ２を構成する複製管理部１４が、通信制
御部１１を制御することにより、通信ネットワーク６な
どを介して送信されてくる更新オブジェクト情報が供給
されるようになされている。

【００５３】次に、サーバ２では、データベース３にデ
ータを登録（データベースの登録内容を更新）する登録
処理、サブジェクトおよびイベントを生成し、放送ネッ
トワーク４を介して伝送するデータ伝送処理、および受
信端末５から通信ネットワーク６を介してサブジェクト
の要求があった場合に、そのサブジェクトを通信ネット
ワーク６を介して送信する要求データ送信処理などが行
われ、また、ミラーサーバ７では、登録処理および要求
データ送信処理などが行われるようになされている。

【００５４】まず、図４のフローチャートを参照して、
サーバ２が行う登録処理について説明する。

【００５５】登録処理では、まず最初に、ステップＳ１
において、情報提供者Ａ乃至Ｃのデータベース１ａ乃至
１ｃのうちのいずれかから更新オブジェクト情報と識別
子が配信されてきたか否かが、登録部１５によって判定
され、配信されてきていないと判定された場合、ステッ
プＳ１に戻る。また、ステップＳ１において、更新オブ
ジェクト情報および識別子が配信されてきたと判定され
た場合、ステップＳ２に進み、登録部１５は、例えば、
その更新オブジェクト情報に、その識別子を付加し、デ
ータベース３に登録する。

【００５６】ここで、データベース１ａ乃至１ｃから
は、更新オブジェクト情報と識別子とが、例えば、図５
に示すようなフォーマットで供給されるようになされて
いる。

【００５７】識別子は、ここでは、例えば、交通情報
や、天気情報、株価情報、さらには、それらの情報を構
成する構成要素などのオブジェクトの種類ごとにあらか
じめ割り当てられているユニークなＩＤ（Identifie
r）、およびオブジェクトの新しさを示すバージョン情
報などからなる。バージョン情報は、例えば、オブジェ
クトが更新されるごとに１ずつインクリメントされる整
数値などが用いられるようになされており、従って、同
一のＩＤが付加されているオブジェクトについては、そ
のバージョン情報を比較することで、最新のオブジェク
トを認識することができる。

【００５８】なお、ＩＤおよびバージョン情報は、ここ
では、例えば、ともに固定長とされている。

【００５９】登録部１５は、データベース１ａ乃至１ｃ
から配信されてきた更新オブジェクト情報に、同じくデ
ータベース１ａ乃至１ｃから配信されてきた識別子を付
加する（対応付ける）と、さらに、ステップＳ２におい
て、その識別子を構成するＩＤと同一のＩＤを有する識
別子が付加されているオブジェクトを、データベース３
から検索し、更新オブジェクト情報に基づいて更新す
る。そして、登録部１５は、その更新したオブジェクト
に付加されている識別子のバージョン情報を、例えば、
１だけインクリメントする。

【００６０】その後、登録部１５は、ステップＳ３にお
いて、オブジェクトが更新された旨を、資源割当部１
２、複製管理部１４、およびデータ構成部１７に出力
し、ステップＳ１に戻る。

【００６１】以上のようにして供給されるオブジェクト
が更新された旨を受信した複製管理部１４では、ステッ
プＳ２でデータベース３に登録された更新オブジェクト
情報およびそれに付加されている識別子が読み出され、
自身が管理しているサーバ、即ち、ここでは、例えば、
ミラーサーバ７に対し、通信ネットワーク６を介して送
信される。また、複製管理部１４は、更新オブジェクト
情報および識別子を送信したサーバを特定するための特
定情報、即ち、ここでは、例えば、ミラーサーバ７のＩ
Ｐアドレスを、データ構成部１７に出力する。

【００６２】なお、ミラーサーバ７では、図４のステッ
プＳ１乃至Ｓ３のうちのステップＳ３を除いた処理が、
登録処理として行われる。即ち、ミラーサーバ７では、
ステップＳ１において、サーバ２から更新オブジェクト
情報と識別子が配信されてきたか否かが、登録部１５に
よって判定され、配信されてきていないと判定された場
合、ステップＳ１に戻る。また、ステップＳ１におい
て、更新オブジェクト情報および識別子が配信されてき
たと判定された場合、ステップＳ２に進み、ミラーサー
バ７の登録部１５は、更新オブジェクト情報に、識別子
を付加し、データベース８に登録する。さらに、ミラー
サーバ７の登録部１５は、ステップＳ２において、サー
バ２から受信した識別子を構成するＩＤと同一のＩＤを
有する識別子が付加されているオブジェクトを、データ
ベース８から検索し、そのオブジェクトを、サーバ２か
ら受信した更新オブジェクト情報に基づいて更新する。
そして、ミラーサーバ７の登録部１５は、その更新した
オブジェクトに付加されている識別子のバージョン情報
を、１だけインクリメントし、ステップＳ３をスキップ
して、ステップＳ１に戻る。

【００６３】サーバ２において、図４の登録処理が行わ
れることにより、そのステップＳ３において登録部１５
が出力するオブジェクトが更新された旨は、上述したよ
うに、複製管理部１４に供給される他、資源割当部１２
およびデータ構成部１７にも供給される。

【００６４】資源割当部１２は、オブジェクトが更新さ
れた旨を受信すると、その更新に関するイベントおよび
サブジェクトを、放送ネットワーク４を介して送信する
ための資源の割当を行い、その割当結果を、データ構成
部１７および伝送部１８に出力する。データ構成部１７
は、オブジェクトが更新された旨を受信すると、その更
新がなされたオブジェクトについての更新オブジェクト
情報を、データベース３から読み出し、サブジェクトを
生成して、伝送部１８に出力する。さらに、データ構成
部１７は、そのサブジェクトを取得するためのイベント
を、資源割当部１２の資源割当結果や、複製管理部１４
からの情報（例えば、上述したように、ミラーサーバ７
のＩＰアドレス）を用いて生成し、伝送部１８に出力す
る。そして、伝送部１８では、データ構成部１７からの
イベントやサブジェクトが、資源割当部１２の資源の割
当結果にしたがって、放送ネットワーク４を介して送信
される。即ち、資源割当部１２、データ構成部１７、お
よび伝送部１８では、図６に示すようなデータ伝送処理
が行われる。

【００６５】即ち、データ伝送処理では、まず最初に、
ステップＳ１１において、資源割当処理が行われる。具
体的には、ステップＳ１１では、資源割当部１２におい
て、オブジェクトが更新された旨を受信すると、その更
新に関するイベントおよびオブジェクトを、放送ネット
ワーク４を介して送信するための放送チャンネルや、放
送時刻、データレート、送信回数などを決定する。これ
らの資源割当結果は、データ構成部１７および伝送部１
８に供給される。

【００６６】そして、ステップＳ１２において、データ
構成部１７は、イベントおよびサブジェクトを生成す
る。即ち、データ構成部１７は、データベース３から、
オブジェクトの更新に用いられた更新オブジェクト情報
と、それに付加されている識別子とを読み出し、例え
ば、図７（Ａ）に示すようなサブジェクトを構成する。
なお、図７（Ａ）においては（同図（Ｂ）においても同
様）、バージョン情報の直後に、判別フラグが配置され
ているが、この判別フラグは、データがサブジェクトま
たはイベントのうちのいずれであるかを表す。

【００６７】また、データ構成部１７は、サブジェクト
について、そのサブジェクトに付加されている識別子と
同一の識別子を付加した、例えば、図７（Ｂ）に示すよ
うなイベントを構成する。即ち、イベントは、サブジェ
クトに付加されている識別子と同一の識別子に、判別フ
ラグ、放送スケジュール情報、およびサーバアクセス情
報を順次配置して構成される。

【００６８】放送スケジュール情報は、サブジェクト
が、放送ネットワーク４を介して放送される場合に、そ
れを受信するのに必要な情報で、これには、資源割当部
１２からの資源割当結果であるサブジェクトの放送チャ
ンネル、放送時刻（時間）、データレート、送信回数な
どが含まれる。従って、イベントを構成する放送スケジ
ュール情報を参照することで、そのイベントを構成する
識別子のオブジェクトを更新するためのサブジェクトの
放送チャンネルや放送時刻などを認識することができ、
これにより、そのサブジェクトを受信することが可能と
なる。

【００６９】サーバアクセス情報は、サブジェクトが、
サーバ２やミラーサーバ７から通信ネットワーク６を介
して送信される場合に、通信ネットワーク６を介して、
そのサブジェクトを要求するのに必要な情報で、これに
は、例えば、サーバ２やミラーサーバ７のＩＰアドレス
などが含まれる。そして、このＩＰアドレスなどは、サ
ーバ２やミラーサーバ７を特定するための特定情報とし
て、複製管理部１４からデータ構成部１７に供給される
ようになされている。

【００７０】即ち、サーバ２やミラーサーバ７は、デー
タベース３や８に記憶された更新オブジェクト情報およ
びそれに付加されている識別子とから、図７（Ａ）に示
したサブジェクトを構成し、受信端末５からの要求に対
応して、そのサブジェクトを、通信ネットワーク６を介
して送信するようになされており、このようにして、サ
ブジェクトを取得する場合に、受信端末５において、サ
ーバアクセス情報が参照される。

【００７１】ここで、サーバ２やミラーサーバ７におい
ては、更新オブジェクト情報およびそれに付加されてい
る識別子から構成されるサブジェクトに、例えば、その
識別子をＩＰアドレスに付加して構成されるＵＲＬを対
応付けて、サブジェクトの管理が行われるようになされ
ている。この場合、イベントを受信した受信端末５で
は、そのイベントを構成するサーバアクセス情報と識別
子とから、そのイベントと同一の識別子が付加されてい
るサブジェクトのＵＲＬを認識することができる。

【００７２】なお、サブジェクトは、放送ネットワーク
４を介してのみ提供することが可能であるが、この場合
には、そのサブジェクトについてのイベントには、サー
バアクセス情報は配置されない。逆に、サブジェクト
は、通信ネットワーク６を介してのみ提供することも可
能であるが、この場合には、そのサブジェクトについて
のイベントには、放送スケジュール情報は配置されな
い。

【００７３】また、サブジェクトが、放送ネットワーク
４を介して、複数のチャンネルや、複数の時刻に送信さ
れる場合には、そのサブジェクトについてのイベントに
は、その複数のチャンネルや複数の時刻それぞれに対応
する放送スケジュール情報が配置される。同様に、サブ
ジェクトが、通信ネットワーク６を介して、複数のサー
バから提供され得る場合には、そのサブジェクトについ
てのイベントには、その複数のサーバそれぞれに対応す
るサーバアクセス情報が配置される。

【００７４】なお、放送スケジュール情報とサーバアク
セス情報の両方が存在する場合や、放送スケジュール情
報またはサーバアクセス情報が複数存在する場合には、
それらのすべてを、１のイベントに含めるのではなく、
それらの１つごとに、イベントを生成しても良い。

【００７５】図６に戻り、ステップＳ１２において、以
上のようなイベントおよびサブジェクトが生成される
と、そのイベントやサブジェクトは、データ構成部１７
から伝送部１８に供給される。伝送部１８では、ステッ
プＳ１３において、データ構成部１７からのイベントや
サブジェクトが、資源割当部１２からの資源割当結果に
したがって、放送ネットワーク４を介して送信される。
即ち、イベントやサブジェクトは、例えば、所定の送信
チャンネルで、所定の送信時刻に、所定のデータレート
で、放送ネットワーク４を介して送信され、ステップＳ
１４に進む。

【００７６】ステップＳ１４では、データ構成部１７か
らのイベントやサブジェクトの送信を、資源割当部１２
からの資源割当結果に含まれる送信回数だけ繰り返し行
ったかどうかが、伝送部１８によって判定され、行って
いないと判定された場合、ステップＳ１３に戻り、イベ
ントやサブジェクトの伝送が繰り返される。即ち、放送
ネットワーク４によるデータの送信は、サーバ２から受
信端末５の一方向にのみ行われるため（いわゆるハンド
シェイク等で行われるものではないため）、それらの間
で、データの送受信が正確に行われたかどうかの確認を
行うことができない。そこで、サーバ２では、データの
送信が、資源割当部１２による資源の割当結果である送
信回数だけ繰り返されるようになされており、これによ
り、受信端末５において、正確なデータの受信が行われ
る確率を向上させるようになされている。

【００７７】一方、ステップＳ１４において、データ構
成部１７からのイベントやサブジェクトの送信を、資源
割当部１２からの資源割当結果に含まれる送信回数だけ
繰り返し行ったと判定された場合、データ伝送処理を終
了する。

【００７８】なお、上述したように、一般に、イベント
はデータ量が少なく、サブジェクトはデータ量が多いか
ら、資源割当部１２では、送信回数は、基本的に、イベ
ントについては多くなり、サブジェクトについては少な
くなるように、資源割当が行われる。従って、受信端末
５において、放送ネットワーク４を介して送信されてく
るイベントを取りこぼす確率（受信できない確率）は小
さくなり、さらに、イベントを正常受信することができ
れば、例えば、それに含まれる放送スケジュール情報を
参照することで、サブジェクトが、放送ネットワーク４
を介して送信されてくるチャンネルや時刻などを認識す
ることができ、その結果、送信回数の少ないイベントを
取りこぼす確率も小さくすることができる。また、仮
に、イベントに基づいて、放送チャンネルや放送時刻な
どを認識したサブジェクトの受信に失敗した場合であっ
ても、あるいは、放送時刻より先に、サブジェクトを必
要とする場合などであっても、イベントに、サーバアク
セス情報が含まれていれば、そのサーバアクセス情報に
基づき、通信ネットワーク６を介して、サーバ２やミラ
ーサーバ７にアクセスすることで、サブジェクトを、早
期、かつ確実に取得することができる。

【００７９】次に、図８のフローチャートを参照して、
サーバ２やミラーサーバ７で行われる要求データ送信処
理について説明する。

【００８０】この場合、ステップＳ２１において、受信
端末５から通信ネットワーク６を介して、サブジェクト
の要求としての、例えば、ＵＲＬが送信されてきたかど
うかが、通信制御部１１によって判定され、送信されて
きていないと判定された場合、ステップＳ２１に戻る。
また、ステップＳ２１において、ＵＲＬが送信されてき
たと判定された場合、通信制御部１１は、そのＵＲＬ
を、データ検索部１３に転送する。データ検索部１３
は、ＵＲＬを受信すると、ステップＳ２２において、そ
のＵＲＬを構成するデータ識別子と同一の識別子が付加
されている更新オブジェクト情報を検索する（サーバ２
では、データベース２から検索し、ミラーサーバ７で
は、データベース８から検索する）。

【００８１】即ち、本実施の形態では、上述したよう
に、イベントを受信した受信端末５において、そのイベ
ントを構成するサーバアクセス情報としてのＩＰアドレ
スと、識別子とから、そのイベントと同一の識別子が付
加されているサブジェクトのＵＲＬが認識されるように
なされている。そして、受信端末５は、通信ネットワー
ク６を介して、サブジェクトを要求する場合には、その
ＵＲＬを送信するようになされている。従って、受信端
末５からのＵＲＬには、識別子が含まれており、サーバ
２やミラーサーバ７では、この識別子を、いわば、更新
オブジェクト情報のファイル名として、その検索が行わ
れる。

【００８２】ステップＳ２２において、更新オブジェク
ト情報が検索されると、データ検索部１３は、その更新
オブジェクトに、それとともに記憶されていた識別子を
付加することにより、サブジェクトを構成し、通信制御
部１１に供給する。通信制御部１１は、データ検索部１
３からのサブジェクトを受信し、ステップＳ２３におい
て、それを、ＵＲＬを送信してきた受信端末（ここで
は、受信端末５）に、通信ネットワーク６を介して送信
して、ステップＳ２１に戻る。

【００８３】次に、図９は、図１の受信端末５の構成例
を示している。

【００８４】受信部２１は、サーバ２から放送ネットワ
ーク４を介して送信されてくるデータ、即ち、ここで
は、イベントやサブジェクトを受信し、選択部２２に出
力するようになされている。選択部２２は、受信部２１
からのイベントやサブジェクトの選択を行うようになさ
れている。さらに、選択部２２は、選択したイベントを
データベース２３に一時記憶させるようにもなされてい
る。また、選択部２２は、選択したサブジェクトに含ま
れる識別子と同一の識別子が付加されているオブジェク
トを、データベース２３から検索し、そのサブジェクト
に含まれる更新オブジェクト情報に基づいて更新するよ
うにもなされている。

【００８５】データベース２３は、例えば、大容量のハ
ードディスクや光磁気ディスク、その他の記録媒体で構
成され、オブジェクトを記憶し、また、選択部２２から
のイベントを一時記憶するようになされている。

【００８６】通信制御部２４は、通信ネットワーク６を
介しての通信制御を行うようになされており、これによ
り、要求部２５からのサブジェクトの要求を、通信ネッ
トワーク６を介してサーバ２やミラーサーバ７などに送
信したり、また、サーバ２やミラーサーバ７などから通
信ネットワーク６を介して送信されてくるサブジェクト
を受信するようになされている。

【００８７】要求部２５は、データベース２３に記憶さ
れているイベントに含まれる放送スケジュール情報にし
たがって、放送ネットワーク４を介して送信されてくる
サブジェクトを受信するように、受信部２１を制御する
ようになされている。また、要求部２５は、データベー
ス２３に記憶されたイベントに含まれるサーバアクセス
情報にしたがい、通信ネットワーク６を介して、サーバ
２やミラーサーバ７に、サブジェクトを要求し、その要
求に対応して、サーバ２やミラーサーバ７から、通信ネ
ットワーク６を介して送信されてくるサブジェクトを受
信するように、通信制御部２４を制御するようにもなさ
れている。さらに、要求部２５は、通信制御部２４に受
信させたサブジェクトに含まれる識別子に対応するオブ
ジェクトを、データベース２３から検索し、そのサブジ
ェクトに含まれる更新オブジェクト情報に基づいて更新
するようにもなされている。なお、要求部２５は、以上
のような処理を、例えば、定期的に行う他、読み出し部
２６から、オブジェクトの更新の要求があった場合など
にも行うようになされている。

【００８８】読み出し部２６は、操作部２８の操作に対
応して、データベース２３に記憶されたオブジェクトを
読み出し、出力部２７に供給するようになされている。
出力部２７は、例えば、ディスプレイやスピーカなどで
構成され、読み出し部２６などからのオブジェクトを表
示し、または音声として出力するようになされている。
操作部２８は、読み出し部２６に対して、所定の入力を
与える場合などに操作される。

【００８９】以上のように構成される受信端末５では、
サーバ２から放送ネットワーク４を介して送信されてく
るデータを受信する受信処理、データベース２３に記憶
されたイベントに基づいて、サブジェクトを要求するデ
ータ要求処理、およびデータベース２３に登録されたデ
ータを出力する出力処理などが行われるようになされて
いる。

【００９０】まず、図１０のフローチャートを参照し
て、受信処理について説明する。

【００９１】サーバ２から放送ネットワーク４を介して
データが送信されてくると、受信部２１では、ステップ
Ｓ３１において、そのデータ、即ち、イベントまたはサ
ブジェクトが受信され、選択部２２に供給される。選択
部２２では、ステップＳ３２において、受信部２１から
のイベントまたはサブジェクトが選択すべきものである
かどうかが判定される。

【００９２】即ち、サーバ２から放送ネットワーク４を
介して送信されてくるすべてのイベントやサブジェクト
を受信するとした場合には、データベース２３として、
記憶容量の膨大なものが必要となる。また、ユーザには
好みがあり、各ユーザが、サーバ２のデータベース３に
記憶されたオブジェクトすべてを必要としていることは
ほとんどない。それにもかかわらず、サーバ２のデータ
ベース３の登録内容すべてを、データベース２３に反映
するのは好ましくない。

【００９３】そこで、選択部２２に、例えば、ユーザが
所望するオブジェクトについてのＩＤ（上述した識別子
を構成するＩＤ）を登録しておくと、選択部２２は、そ
のＩＤと同一のＩＤを有するイベントおよびオブジェク
トだけを選択するようになされている。従って、ステッ
プＳ３２における判定は、ユーザが登録したＩＤと、受
信部２１から供給されるイベントやサブジェクトの識別
子を構成するＩＤとを比較することで行われる。

【００９４】ステップＳ３２において、受信部２１から
のイベントまたはサブジェクトが選択すべきものでない
と判定された場合、即ち、例えば、ユーザが登録したＩ
Ｄと、受信部２１から供給されたイベントまたはサブジ
ェクトに記述されているＩＤとが一致しない場合、次の
イベントまたはサブジェクトが、放送ネットワーク４を
介して送信されてくるのを待って、ステップＳ３１に戻
る。従って、この場合、イベントはデータベース２３に
記憶されず、また、サブジェクトに基づくデータベース
２３の更新も行われない。

【００９５】一方、ステップＳ３２において、受信部２
１からのイベントまたはサブジェクトが選択すべきもの
であると判定された場合、即ち、例えば、ユーザが登録
したＩＤと、受信部２１から供給されたイベントまたは
サブジェクトに記述されているＩＤとが一致する場合、
ステップＳ３３に進み、選択部２２は、そのイベントま
たはサブジェクトが、新規のオブジェクトに関するもの
かどうかを判定する。

【００９６】ステップＳ３３において、ステップＳ３２
で選択されたイベントまたはサブジェクトが、新規のオ
ブジェクトに関するものであると判定された場合、即
ち、そのイベントまたはサブジェクトに含まれているＩ
Ｄと同一のＩＤのオブジェクトが、データベース２３に
登録されていない場合、ステップＳ３４をスキップし
て、ステップＳ３５に進む。

【００９７】また、ステップＳ３３において、ステップ
Ｓ３２で選択されたイベントまたはサブジェクトが、新
規のオブジェクトに関するものでないと判定された場
合、即ち、そのイベントまたはサブジェクトに含まれて
いるＩＤと同一のＩＤのオブジェクトが、データベース
２３に登録されている場合、ステップＳ３４に進み、選
択部２２において、その既にデータベース２３に登録さ
れているオブジェクト（以下、適宜、既登録オブジェク
トという）の識別子に記述されているバージョン情報
が、ステップＳ３２で選択されたイベントまたはサブジ
ェクトの識別子に記述されているバージョン情報と等し
いかどうかが判定される。

【００９８】ステップＳ３４において、既登録オブジェ
クトに記述されているバージョン情報が、ステップＳ３
２で選択されたイベントまたはサブジェクトに記述され
ているバージョン情報と等しい場合、即ち、ここでは、
図６のデータ伝送処理で説明したように、信頼性を向上
させるため、サーバ２からは、同一のサブジェクトが放
送ネットワーク４を介して繰り返し送信されるが、その
ように繰り返し行われる送信のうちの、過去に行われた
送信によるサブジェクトによって、既登録オブジェクト
の更新が、既に行われている場合、ステップＳ３５乃至
Ｓ３７をスキップし、次に、イベントまたはサブジェク
トが送信されてくるのを待って、ステップＳ３１に戻
る。従って、この場合、イベントは、データベース２３
に記憶されず、また、サブジェクトに基づくデータベー
ス２３の更新も行われない。

【００９９】一方、ステップＳ３４において、既登録オ
ブジェクトに記述されているバージョン情報が、ステッ
プＳ３２で選択されたイベントまたはサブジェクトに記
述されているバージョン情報と等しくないと判定された
場合、即ち、イベントまたはサブジェクトが、新たなバ
ージョンのオブジェクトに関するものである場合、ステ
ップＳ３５に進み、選択部２２において、ステップＳ３
２で選択されたデータが、イベントまたはサブジェクト
のうちのいずれであるかが、判別フラグを参照すること
で判定される。

【０１００】ステップＳ３５において、ステップＳ３２
で選択されたデータがサブジェクトであると判定された
場合、ステップＳ３６に進み、選択部２２は、そのサブ
ジェクトに基づき、データベース２３を更新する。

【０１０１】即ち、サブジェクトにおいて、更新オブジ
ェクト情報として、新規のオブジェクトが配置されてい
る場合には、サブジェクトに含まれる識別子に、その新
規のオブジェクトが対応付けられ、データベース２３に
新規登録される。

【０１０２】また、サブジェクトにおいて、更新オブジ
ェクト情報として、更新後のオブジェクトが配置されて
いる場合には、サブジェクトに含まれるＩＤと同一のＩ
Ｄを有する識別子が対応付けられたオブジェクトが、デ
ータベース２３から検索され、その検索されたオブジェ
クトが、更新後のオブジェクトに変更される。さらに、
そのオブジェクトに対応付けられていたバージョン情報
が、例えば、１だけインクリメントされる。

【０１０３】さらに、サブジェクトにおいて、更新オブ
ジェクト情報として、オブジェクトの削除指令が配置さ
れている場合には、サブジェクトに含まれるＩＤと同一
のＩＤを有する識別子が対応付けられたオブジェクト
が、データベース２３から検索され、そのオブジェクト
に対応付けられている識別子とともに削除される。

【０１０４】なお、上述の図４で説明した登録処理のス
テップＳ２において行われる、更新オブジェクト情報に
基づくオブジェクトの更新も、これと同様にして行われ
る。

【０１０５】ステップＳ３６において、以上のようにし
て、データベース２３の更新が行われた後は、次に、イ
ベントまたはサブジェクトが送信されてくるのを待っ
て、ステップＳ３１に戻る。

【０１０６】一方、ステップＳ３５において、ステップ
Ｓ３２で選択されたデータがイベントであると判定され
た場合、ステップＳ３７に進み、選択部２２は、そのイ
ベントを、データベース２３に供給して一時記憶させ
る。そして、次に、イベントまたはサブジェクトが送信
されてくるのを待って、ステップＳ３１に戻る。

【０１０７】なお、ステップＳ３７において、データベ
ース２３に記憶されたイベントは、後述するデータ要求
処理（図１１）や、データ出力処理（図１２）におい
て、要求部２５によって、データベース２３から読み出
された後に消去されるようになされている。

【０１０８】次に、図１１を参照して、データ要求処理
について説明する。なお、このデータ要求処理は、受信
端末５において、例えば定期的に行われる。但し、デー
タ要求処理は、不定期に行うことも可能である。

【０１０９】データ要求処理では、まず最初に、ステッ
プＳ４１において、データベース２３の登録内容が、要
求部２５によって検索され、ステップＳ４２に進み、デ
ータベース２３に、イベントが記憶されているかどうか
が判定される。ステップＳ４２において、イベントが記
憶されていないと判定された場合、データ要求処理を終
了する。

【０１１０】また、ステップＳ４２において、データベ
ース２３にイベントが記憶されていると判定された場
合、そのイベントが読み出され（複数のイベントが記憶
されている場合には、そのうちの１つが読み出され）、
ステップＳ４３に進み、要求部２５において、そのイベ
ントに基づくサブジェクトの受信を、同報可能な放送ネ
ットワーク４または双方向通信が可能な通信ネットワー
ク６のうちのいずれを介して行うのが有利かが判定され
る。

【０１１１】ここで、ステップＳ４３の判定は、例え
ば、次のようにして行われる。

【０１１２】即ち、要求部２５では、イベントに含まれ
る放送スケジュール情報を参照することにより、そのイ
ベントに付加されている識別子と同一の識別子のサブジ
ェクトが送信されてくる送信回数（送信頻度）や、送信
時刻が認識される。そして、例えば、送信回数が多い場
合や、送信時刻が、現在時刻に近い場合には、サブジェ
クトの受信時間その他の受信のためのコストが低いと予
想される放送ネットワーク４を介して、サブジェクトの
受信を行うのが有利であると判定される。

【０１１３】また、例えば、送信回数が少ない場合や、
送信時刻が、現在時刻から離れている場合には、通信ネ
ットワーク６を介して、サブジェクトの受信を行うのが
有利であると判定される。

【０１１４】なお、その他、例えば、イベントに含まれ
る放送スケジュール情報に、サブジェクトのデータ量が
記述されている場合には（データ量そのものが記述され
ていなくても、データレートと、送信に要する時間とが
記述されていれば、データ量を認識することができ
る）、そのデータ量に基づき、放送ネットワーク４また
は通信ネットワーク６のうちのいずれを介して、サブジ
ェクトの受信を行うのが有利であるのかを判定すること
も可能である。

【０１１５】さらに、放送ネットワーク４または通信ネ
ットワーク６のうちのいずれを介して、サブジェクトの
受信を行うのが有利であるのかは、ユーザに操作部２８
を操作してもらい、その操作に対応して決定することも
可能である。

【０１１６】また、通信ネットワーク６を介してサブジ
ェクトを受信する場合において、通信ネットワーク６
が、複数の伝送レートに対応しており、受信端末５が、
そのような複数の伝送レートの回線を介しての通信の可
能なものであるときには、サブジェクトのデータ量によ
って、使用する回線を変えるようにすることも可能であ
る。

【０１１７】ここで、上述したように、イベントには、
放送スケジュール情報またはサーバアクセス情報のうち
のいずれか一方しか含まれていない場合がある。イベン
トに、放送スケジュール情報しか含まれていない場合、
ステップＳ４３では、放送ネットワーク４を介して、サ
ブジェクトの受信を行うのが有利であると判定される。
また、逆に、イベントに、サーバアクセス情報しか含ま
れていない場合は、ステップＳ４３では、通信ネットワ
ーク６を介して、サブジェクトの受信を行うのが有利で
あると判定される。

【０１１８】ステップＳ４３において、放送ネットワー
ク４を介して、サブジェクトの受信を行うのが有利であ
ると判定された場合、ステップＳ４４に進み、要求部２
５は、受信部２１が動作可能な状態であるかどうか（例
えば、電源が供給されているかどうか（スリープ状態に
ないかどうか））を判定する。ステップＳ４４におい
て、受信部２１が動作可能な状態にないと判定された場
合、ステップＳ４５に進み、要求部２５は、例えば、イ
ベントの放送スケジュール情報に配置されているサブジ
ェクトの送信時刻の直前まで待って、受信部２１を動作
可能な状態にし、ステップＳ４６に進む。

【０１１９】また、ステップＳ４４において、受信部２
１が動作可能な状態にあると判定された場合、ステップ
Ｓ４５をスキップして、ステップＳ４６に進み、要求部
２１は、受信部２１を制御することにより、データベー
ス２３から読み出したイベントの放送スケジュール情報
に配置されている送信チャンネルで、同じくその放送ス
ケジュール情報に配置されている送信時刻に、放送ネッ
トワーク４を介して送信されてくるサブジェクト、即
ち、イベントに付加されている識別子と同一の識別子の
サブジェクトを受信させ、選択部２２に供給させる。そ
して、ステップＳ４７において、選択部２２では、図１
０のステップＳ３６における場合と同様にして、受信部
２１からのサブジェクトに基づき、データベース２３の
更新が行われ、データ要求処理を終了する。

【０１２０】ここで、受信端末５において、データの取
りこぼしは、受信部２１の電源がオフ状態になっている
ことに起因して生じることが多い。そこで、上述のよう
に、受信部２１が動作可能な状態になっているかどうか
を判定し、なっていない場合には、受信部２１を動作可
能な状態にすることで、受信部２１の電源がオフ状態に
なっていることに起因するサブジェクトの取りこぼしを
防止することができる。

【０１２１】一方、ステップＳ４３において、通信ネッ
トワーク６を介して、サブジェクトを受信するのが有利
であると判定された場合、ステップＳ４８に進み、要求
部２５は、通信制御部２４を制御することで、データベ
ース２３から読み出したイベントに含まれる識別子と同
一の識別子が付加されているサブジェクトを、通信ネッ
トワーク６を介して、サーバ２やミラーサーバ７に要求
させる。

【０１２２】即ち、要求部２５は、データベース２３か
ら読み出したイベントに含まれる識別子と、同じくそこ
に含まれるサーバアクセス情報（ここでは、上述したよ
うに、ＩＰアドレス）とから、その識別子と同一の識別
子が付加されているサブジェクトに対応付けられている
ＵＲＬを構成し、通信制御部２４を制御することで、通
信ネットワーク６を介して、サーバ２やミラーサーバ７
に送信させる。

【０１２３】ＵＲＬが送信されたサーバ２やミラーサー
バ７では、図８で説明した要求データ送信処理が行わ
れ、これにより、そのＵＲＬに対応付けられているサブ
ジェクトが、通信ネットワーク６を介して送信されてく
る。このサブジェクトは、ステップＳ４９において、通
信制御部２４によって受信され、要求部２５に供給され
る。要求部２５は、通信制御部２４からサブジェクトを
受信すると、ステップＳ４７に進み、上述したようにし
て、そのサブジェクトに基づき、データベース２３の更
新を行い、データ要求処理を終了する。

【０１２４】以上のように、サブジェクトを、放送ネッ
トワーク４または通信ネットワーク６のうちのいずれを
介して受信する方が有利かどうかを判定し、有利な方を
介して送信されるサブジェクトを受信するようにしたの
で、受信端末５では、効率的に、サブジェクトの受信、
およびオブジェクトの更新を行うことが可能となる。

【０１２５】なお、サブジェクトを、放送ネットワーク
４を介して受信する場合において、イベントの放送スケ
ジュール情報に、複数の送信時刻が配置されているとき
には、例えば、そのうちの、現在時刻に最も近い送信時
刻（但し、現在時刻よりも前（過去）の時刻を除く）に
送信されてくるサブジェクトが受信される。但し、ユー
ザに操作部２８を操作してもらい、送信時刻を選択させ
ることも可能である。

【０１２６】また、サブジェクトを、通信ネットワーク
６を介して要求、受信する場合において、イベントのサ
ーバアクセス情報に、複数のサーバのＩＰアドレスが配
置されているときには、例えば、そのうちの、受信端末
５に最も近い位置にあるサーバのＩＰアドレスを用いて
ＵＲＬが構成される。但し、ユーザに操作部２８を操作
してもらい、サーバを選択させることも可能である。

【０１２７】次に、図１２のフローチャートを参照し
て、データ出力処理について説明する。なお、データ出
力処理も、例えば、図１１のデータ要求処理と同様に、
基本的には、定期的に起動されるようになされている。

【０１２８】データ出力処理では、まず最初に、ステッ
プＳ５１において、操作部２８が、データ（本実施の形
態では、オブジェクト）を出力するように操作されたか
否かが、読み出し部２６によって判定され、そのように
は操作されていないと判定された場合、データ出力処理
を終了する。

【０１２９】また、ステップＳ５１において、操作部２
８が、オブジェクトを出力するように操作されたと判定
された場合、ステップＳ５２に進み、出力の要求された
オブジェクトについてのイベント、即ち、そのオブジェ
クトの識別子と同一の識別子が付加されているイベント
が、データベース２３に記憶されているかどうかが、読
み出し部２６によって判定される。ステップＳ５２にお
いて、出力の要求されたオブジェクトについてのイベン
トが、データベース２３に記憶されていないと判定され
た場合、即ち、出力の要求されたオブジェクトとして
は、いまデータベース２３に記憶されているものが最新
のものである場合（但し、イベントの取りこぼしがない
ものとする）、ステップＳ５３に進み、読み出し部２６
は、出力の要求されたオブジェクトを、データベース２
３から読み出し、出力部２７に供給する。出力部２７で
は、読み出し部２６からのオブジェクトが表示、または
音声で出力され、データ出力処理を終了する。

【０１３０】また、ステップＳ５２において、出力の要
求されたオブジェクトについてのイベントが、データベ
ース２３に記憶されていると判定された場合、即ち、出
力の要求されたオブジェクトは、サーバ２では更新され
ているが、受信端末５では、まだ更新されていない場
合、ステップＳ５４に進み、そのオブジェクトの更新を
行うかどうかが、読み出し部２６によって判定される。

【０１３１】即ち、ステップＳ５４では、読み出し部２
６は、オブジェクトの更新を行うかどうかを問い合わせ
るメッセージを、出力部２７に表示させ、ユーザに、操
作部２８の操作を促す。そして、ステップＳ５４では、
操作部２８の操作に対応して、オブジェクトの更新を行
うかどうかが判定される。

【０１３２】あるいは、また、ステップＳ５４では、出
力の要求されたオブジェクトについてのイベントの放送
スケジュール情報が参照され、そのオブジェクトを更新
するためのサブジェクトが、放送ネットワーク４を介し
て送信されてくる送信時刻のうち、現在時刻に最も近い
ものが認識される。そして、ステップＳ５４では、その
現在時刻に最も近い送信時刻が、現在時刻から、あらか
じめ受信端末５に設定された所定の時間内であるかどう
かに対応して、オブジェクトの更新を行うかどうかが判
定される（例えば、送信時刻が、現在時刻から所定の時
間内である場合には、オブジェクトの更新を行うと判定
される）。

【０１３３】ステップＳ５４において、出力の要求され
たオブジェクトの更新を行わないと判定された場合、ス
テップＳ５５に進み、読み出し部２６は、出力の要求さ
れたオブジェクト、即ち、更新前のオブジェクトを、デ
ータベース２３から読み出し、以下、ステップＳ５３に
おける場合と同様にして、出力部２７に出力させて、デ
ータ出力処理を終了する。なお、この場合、出力部２７
には、オブジェクトを出力させるとともに、そのオブジ
ェクトが更新前のものである旨のメッセージを表示させ
るようにしても良い。

【０１３４】一方、ステップＳ５４において、出力の要
求されたオブジェクトの更新を行うと判定された場合、
ステップＳ５６に進み、そのオブジェクトの更新するた
めのデータベース更新処理が行われる。即ち、ステップ
Ｓ５６では、出力の要求されたオブジェクトについての
イベントを用いて、図１１のデータ要求処理のステップ
Ｓ４３乃至Ｓ４９における場合と同様の処理が行われ、
これにより、出力の要求されたオブジェクトが更新され
る。そして、ステップＳ５３に進み、その更新後のオブ
ジェクトが、上述したようにして、出力部２７から出力
され、データ出力処理を終了する。

【０１３５】ところで、イベントのサーバアクセス情報
に、複数のサーバのＩＰアドレスが配置されている場合
において、いずれのサーバに、サブジェクトを要求する
かを、例えば、上述したように、受信端末５からの位置
や、ユーザによる操作部２８の操作に対応して決定した
のでは、あるサーバへのアクセスが集中することがあ
る。

【０１３６】そこで、通信ネットワーク６を介して、受
信端末５に対してサブジェクトを送信するサーバが複数
存在する場合（例えば、図１に示すように、サーバ２以
外に、ミラーサーバ７が存在する場合や、ミラーサーバ
７以外のミラーサーバがさらに存在する場合など）に
は、サーバへのアクセスを分散させるために（１のサー
バにアクセスを集中させないために）、受信端末５また
はそのユーザに、固有のＩＤ（以下、適宜、ユーザＩＤ
という）を与え、サーバ２には、各サーバのＩＰアドレ
スを、所定のユーザＩＤと対応付け、サーバアクセス情
報として、イベントに配置する処理（以下、適宜、負荷
分散処理という）を行わせてから、イベントを送信させ
るようにすることができる。一方、受信端末５には、自
身のユーザＩＤと対応付けられているＩＰアドレスのサ
ーバを認識する処理（以下、適宜、アクセスサーバ決定
処理）を行わせてから、そのサーバに、サブジェクトを
要求させるようにすることができる。

【０１３７】図１３は、サーバ２が行う負荷分散処理の
フローチャートを示している。なお、この負荷分散処理
は、受信端末５に対して、通信ネットワーク６を介し
て、サブジェクトを送信するサーバが複数存在する場合
（サーバ２以外に、通信ネットワーク６を介して、サブ
ジェクトを送信することのできるサーバが存在する場
合）に、例えば、図６のデータ伝送処理におけるステッ
プＳ１２の処理の一部として行われる。

【０１３８】負荷分散処理では、まず最初に、ステップ
Ｓ６１において、通信ネットワーク６を介して、サブジ
ェクトを送信する１のサーバに割り当てる受信端末の数
（以下、適宜、割当数という）Ｎが算出される。即ち、
ステップＳ６１では、例えば、受信端末の総数が、サブ
ジェクトを通信ネットワーク６を介して送信するサーバ
の総数で除算され、その除算値（小数点以下は、例え
ば、切り上げ）が、割当数Ｎとされる。なお、サーバ２
では、受信端末の総数が管理されているものとする。ま
た、サーバ２では、サブジェクトを通信ネットワーク６
を介して送信するサーバの総数は、複製管理部１４で管
理されている情報から認識されるようになされている。

【０１３９】その後、ステップＳ６２において、通信ネ
ットワーク６を介して、サブジェクトを送信する複数の
サーバのうちの１が選択され（この選択されたサーバ
を、以下、適宜、選択サーバという）、ステップＳ６３
に進み、例えば、その選択サーバに近い位置にある受信
端末が、割当数Ｎだけ検出される。なお、選択サーバお
よび受信端末５の位置は、サーバ２において管理されて
いるものとする。

【０１４０】そして、ステップＳ６４に進み、選択サー
バのＩＰアドレスに、ステップＳ６３で検出されたＮ個
の受信端末それぞれのユーザＩＤが対応付けられ、その
ＩＰアドレスとＮ個のユーザＩＤとの組が、サーバアク
セス情報として、イベントに配置される。その後、ステ
ップＳ６５に進み、通信ネットワーク６を介して、サブ
ジェクトを送信する複数のサーバすべてを、選択サーバ
として、ステップＳ６２乃至Ｓ６４の処理を行ったかど
うかが判定される。ステップＳ６５において、複数のサ
ーバすべてを、まだ、選択サーバとして処理していない
と判定された場合、ステップＳ６２に戻り、まだ選択サ
ーバとして選択されていないサーバが、新たに選択サー
バとされ、以下、同様の処理を繰り返す。一方、ステッ
プ６５において、複数のサーバすべてを選択サーバとし
て処理を行ったと判定された場合、負荷分散処理を終了
する。

【０１４１】以上のようにして、負荷分散処理では、１
のサーバに、Ｎ個（またはＮ−１個）の受信端末が割り
当てられる。

【０１４２】なお、上述の場合においては、単純に、受
信端末の総数を、サブジェクトを通信ネットワーク６を
介して送信するサーバの総数で除算した除算値を、１の
サーバに割り当てる受信端末の数としたが、複数のサー
バそれぞれに割り当てる受信端末の数は、例えば、さら
に、各サーバの処理能力などを考慮して決めても良い。

【０１４３】次に、図１４のフローチャートを参照し
て、受信端末５が行うアクセスサーバ決定処理について
説明する。なお、このアクセスサーバ決定処理は、受信
端末５において、例えば、図１１のデータ要求処理のス
テップＳ４８で送信するＵＲＬを構成する前に行われ
る。

【０１４４】アクセスサーバ決定処理では、ステップＳ
７１において、受信端末５は、イベントのサーバアクセ
ス情報の中から、自身に割り当てられているユーザＩＤ
を検索し、ステップＳ７２に進む。ステップＳ７２で
は、自身のユーザＩＤに対応付けられているＩＰアドレ
ス、即ち、サブジェクトを要求すべきサーバが認識さ
れ、アクセスサーバ決定処理を終了する。

【０１４５】そして、受信端末５では、図１１で説明し
たように、ステップＳ４８において、ステップＳ７２で
認識されたＩＰアドレスを用いてＵＲＬが構成されて送
信される。

【０１４６】以上のように、サーバ２または受信端末５
において、負荷分散処理またはアクセスサーバ決定処理
をそれぞれ行うことで、受信端末からのサブジェクトの
要求を、複数のサーバに分散させることができ、効率の
良いサブジェクトの配信が可能となる。

【０１４７】なお、上述の場合においては、受信端末の
ユーザＩＤとＩＰアドレスとを対応付け、受信端末がア
クセスすべきサーバを制限するようにしたが、その他、
例えば、受信端末のユーザＩＤと、サーバに対して通信
ネットワーク６を介してアクセス可能な時間帯（要求タ
イミング情報）とを対応付け、受信端末がサーバにアク
セスする時間帯を制限するようにすることなどによって
も、サーバに対するアクセスを分散させることが可能で
ある。

【０１４８】以上、本発明を適用したデータ配信システ
ムについて説明したが、このようなデータ配信システム
は、例えば、分散型データベースにおける多数のデータ
ベースへのデータの配信を行う場合や、ＩＰマルチキャ
ストによりデータを配信する場合、その他、データを不
特定多数に配信する場合に、特に有用である。

【０１４９】なお、本実施の形態では、イベントは、放
送ネットワーク４を介して送信するようにしたが、その
他、例えば、受信端末５からの要求に応じて、通信ネッ
トワーク６を介して送信するようにしても良い。さら
に、本発明において、放送ネットワーク４および通信ネ
ットワーク６の両方を備えることは必須ではない。即
ち、本発明は、放送ネットワーク４または通信ネットワ
ーク６のいずれか１つだけを備えるシステムにも適用可
能である。

【０１５０】また、本実施の形態では、サーバアクセス
情報に、サーバ２やミラーサーバ７のＩＰアドレスを配
置するようにしたが、サーバアクセス情報には、その
他、例えば、サーバ２やミラーサーバ７で管理されてい
るサブジェクトのＵＲＬや、サーバ２やミラーサーバ７
へアクセスするための電話番号などを配置することも可
能である。

【０１５１】また、ミラーサーバ７には、受信端末５と
同様にして、イベントやサブジェクトを受信させて、デ
ータベース８の更新を行わせるようにすることが可能で
ある。

【０１５２】さらに、本実施の形態では、サブジェクト
に含める更新オブジェクト情報として、更新後のオブジ
ェクトそのものなどを配置するようにしたが、更新オブ
ジェクト情報としては、その他、例えば、更新前のオブ
ジェクトに、更新後のオブジェクトへの変更内容を反映
させるためのデータ（例えば、更新前のオブジェクト
を、更新後のオブジェクトに変更する実行形式のコンピ
ュータプログラムや、更新後のオブジェクトと更新前の
オブジェクトとの差分など）などを配置することも可能
である。

【０１５３】次に、図７においては、データ構成部１７
において生成されるイベントのデータ構造の概要を説明
したが、このデータ構成部１７で構成されるイベント
を、例えば、任意のトランスポートプロトコル上で実現
するためのフォーマットについて詳述する。

【０１５４】なお、ここでは、イベントのフォーマット
を、ＡＮＳ．１（Abstract SyntaxNotation One）を用
いた抽象構文表現によって表すこととする。

【０１５５】ここで、ＡＮＳ．１によって表されたフォ
ーマットは、ＡＳＮ．１の符号化規則ＢＥＲ（Basic En
coding Rules），ＣＥＲ（Canonical Encoding Rule
s），ＤＥＲ（Distinguished Encoding Rules），ＰＥ
Ｒ（Packed Encoding Rules）に基づき、一意に符号化
（ビット列（転送構文）に変換）することができる。ま
た、その符号化や、符号化結果の復号を行うための処理
系は、ＡＳＮ．１準拠の商用／パブリックドメインソフ
トウェアのツールＳｎａｃｃ（Sample Neufeld Asn.1 t
o C Compiler）などを利用することで、容易に構成する
ことができる。

【０１５６】なお、ＡＮＳ．１による抽象構文について
は、例えば、「プロトコル構文規定言語ＡＳＮ．１」、
カットシステム発行などに、符号化規則ＢＥＲ，ＣＥ
Ｒ，ＤＥＲについては、例えば、ISO/IEC 8825-1:ASN.1
Encoding Rules:Specification of Basic Encoding Ru
les(BER), Canonical Encoding Rules(CER), and Disti
nguished Encoding Rules(DER)などに、符号化規則ＰＥ
Ｒについては、例えば、ISO/IEC 8825-1:ASN.1 Encodin
g Rules:Specification of Packed Encoding Rules(PE
R)などに、その詳細が開示されている。

【０１５７】イベントEventMessageは、例えば、次のよ
うに定義される。

【０１５８】

【０１５９】ここで、SEQUENCE{}は、イベント（イベン
トの型）EventMessageが、かっこ｛｝内で定義されてい
る変数formatVersion,FormatVersion,filteringMasks,t
imeToLive,objectIdentifier,objectVersion,subjectLi
nksの順序列で表現されることを表す。また、かっ
こ｛｝内の左から２番目に配置されているFormatVersio
n,FilteringMasks,UTCTime,ObjectIdentifier,INTEGER,
SubjectLinksは、その左に配置されている変数の型を表
す。また、かっこ｛｝内の左から３番目に配置されてい
るOPTIONALは、その行で定義されている変数が、任意的
変数（省略可能な変数）であることを表す。従って、こ
こでは、イベントEventMessageは、少なくとも、フォー
マットバージョンformatVersion、生存時間timeToLiv
e、オブジェクト識別子objectIdentifierを必須のメン
バとして構成される。

【０１６０】なお、型FormatVersion,FilteringMasks,U
TCTime,ObjectIdentifier,INTEGER,SubjectLinksのう
ち、INTEGERは整数を、UTCTimeは国際標準時刻またはロ
ーカル時刻（例えば、少なくとも、秒の精度を有する）
を、それぞれ表す。他の型の定義については、後述す
る。

【０１６１】イベントEventMessageにおいて、フォーマ
ットバージョンformatVersionは、そのイベントEventMe
ssageのフォーマットのバージョンを表す。即ち、イベ
ントEventMessageのフォーマットを、将来拡張すること
を考えると、受信端末５において、イベントEventMessa
geを処理するには、そのフォーマットを認識する必要が
ある。フォーマットバージョンformatVersionは、イベ
ントEventMessageのフォーマットを特定するための情報
（フォーマット情報）で、受信端末５では、このフォー
マットバージョンformatVersionによって、受信したイ
ベントEventMessageのフォーマットが認識されて処理さ
れる。

【０１６２】フォーマットバージョンformatVersionの
型FormatVersionは、例えば、次のように定義される。

【０１６３】

【０１６４】即ち、フォーマットバージョンformatVers
ionは、ここでは、メジャーバージョンmajorVersionお
よびマイナーバージョンminorVersionと呼ばれる２つの
整数（INTEGER）で表される。なお、メジャーバージョ
ンmajorVersionおよびマイナーバージョンminorVersion
の使い分けや、数字の割り当て方などは、データ配信シ
ステムの運用者が任意に定義可能とすることもできる
が、ここでは、例えば、メジャーバージョンmajorVersi
onには、イベントとサブジェクトを区別するための情報
を配置することとする。即ち、例えば、イベントについ
てのメジャーバージョンmajorVersionとしては、所定値
以上を用い、サブジェクトについてのメジャーバージョ
ンmajorVersionとしては、所定値未満を用いることとす
る。この場合、フォーマットバージョンformatVersion
は、イベントEventMessageのフォーマットのバージョン
を表す他、図７で説明した判別フラグとしての役割も果
たす。

【０１６５】ここで、イベントとサブジェクトを区別す
る情報は、メジャーバージョンmajorVersionに配置する
他、トランスポートレイヤより上位の、例えば、アプリ
ケーションレイヤやプレゼンテーションレイヤなどにお
いて定義することも可能である。

【０１６６】イベントEventMessageにおけるフィルタマ
スクfilteringMasksは、受信端末５において、そのイベ
ントEventMessageを取捨選択するための基準として用い
ることのできる情報（選択基準情報）で、その型Filter
ingMasksは、例えば、次のように定義される。

【０１６７】 FilteringMasks::=SEQUENCE OF{ filteringMaskIdentifier INTEGER, filteringMaskField ANY DEFINED BY filteringMaskIdentifiler }

【０１６８】ここで、SEQUENCE OF{}は、フィルタマス
ク（フィルタマスクfilteringMasksの型）FilteringMas
ksが、かっこ｛｝内で定義されている変数filteringMas
kIdentifierとfilteringMaskFieldとの組み合わせの順
序列で表現されることを表す。従って、フィルタマスク
filteringMasksは、変数filteringMaskIdentifierとfil
teringMaskFieldとの組み合わせを１つだけでなく、複
数配置して構成することができる。また、変数filterin
gMaskFieldの型ANY DEFINED BYは、BYの後に配置されて
いる変数に依存する任意の型（任意型）であることを表
す。従って、変数filteringMaskFieldの型は、その前の
行に配置されている変数filteringMaskIdentifilerに対
応した任意の型を取り得る。

【０１６９】フィルタマスクfilteringMasksにおけるマ
スク識別子filteringMaskIdentifierは、マスクフィー
ルドfilteringMaskFieldを識別するためのもので、ここ
では、マスクフィールドfilteringMaskFieldごとに、ユ
ニークな整数が用いられるようになされている。

【０１７０】フィルタマスクfilteringMasksにおけるマ
スクフィールドｆｉｌｔｅｒｉｎｇＭａｓｋＦｉｅｌｄ
は、イベントＥｖｅｎｔＭｅｓｓａｇｅに対応するオブ
ジェクト（イベントEventMessageに基づいて取得される
サブジェクトによって更新されるオブジェクト）を取捨
選択するための基準として用いることのできる情報で、
そこには、例えば、そのオブジェクトのカテゴリや、オ
ブジェクトを視聴するにあたっての年齢制限、オブジェ
クトの視聴することの契約内容などに関する情報が配置
される。

【０１７１】即ち、マスクフィールドfilteringMaskFie
ldには、例えば、オブジェクトが、スポーツに関するも
のであるとか、天気予報に関するものであるとかを表す
情報を配置し、さらに、オブジェクトが、スポーツに関
するものであるという情報が配置される場合には、その
オブジェクトが、スポーツのうちの、野球に関するもの
であるとか、サッカーに関するものであるとかを表す情
報を配置することができる。この場合、受信端末５にお
ける選択部２２に、例えば、ユーザの所望するカテゴリ
を設定しておき（カテゴリの設定は、例えば、ユーザに
行わせるようにしても良いし、受信端末５において、ユ
ーザによるオブジェクトの視聴履歴を記憶するようにし
て、その視聴履歴に基づいて行うようにしても良い）、
そのカテゴリを、マスクフィールドfilteringMaskField
と比較させることで、ユーザの所望するカテゴリのオブ
ジェクトに対応するイベントだけを選択させることなど
が可能となり、その結果、ユーザの所望するカテゴリの
オブジェクトだけの提供を受けることが可能となる。な
お、逆に、受信端末５における選択部２２に、ユーザが
所望しないカテゴリを設定しておき、そのカテゴリを、
マスクフィールドfilteringMaskFieldと比較させること
で、ユーザの所望しないカテゴリを除くカテゴリのオブ
ジェクトに対応するイベントだけを選択させるようにす
ることも可能である。

【０１７２】また、マスクフィールドfilteringMaskFie
ldには、例えば、オブジェクトが、何歳以上向けである
といった年齢制限に関する情報を配置することも可能で
ある。この場合、受信端末５における選択部２２に、例
えば、年齢を設定しておき、その年齢を、マスクフィー
ルドfilteringMaskFieldと比較させることで、成人向け
のオブジェクトに対応するイベントを選択しないように
することなどが可能となる。

【０１７３】さらに、マスクフィールドfilteringMaskF
ieldには、オブジェクトが、高額の契約料を支払う契約
内容のユーザ向けとか、低額の契約料を支払う契約内容
のユーザ向けといった契約内容に関する情報を配置する
ことも可能である。この場合、受信端末５における選択
部２２に、契約内容を設定しておき、その契約内容を、
マスクフィールドfilteringMaskFieldと比較させること
で、オブジェクトの視聴にあたっての契約内容に応じた
オブジェクトの選択を行うようにすることなどが可能と
なる。

【０１７４】ここで、フィルタマスクfilteringMasks
は、上述したように、マスク識別子filteringMaskIdent
ifierとマスクフィールドfilteringMaskFieldとの組み
合わせを１以上配置して構成することができるから、そ
こには、例えば、オブジェクトのカテゴリと、オブジェ
クトを視聴するにあたっての年齢制限がそれぞれ配置さ
れた２つのマスクフィールドfilteringMaskFieldを、対
応するマスク識別子filteringMaskIdentifierと組み合
わせて順次記述することが可能である。この場合、選択
部２２では、所定のカテゴリに属し、かつ所定の年齢向
けのオブジェクトに対応するイベントのみを選択した
り、また、所定のカテゴリに属するオブジェクトと、所
定の年齢向けのオブジェクトとのうちのいずれかに対応
するオブジェクトを選択するようにすることが可能とな
る。なお、この場合、選択部２２では、フィルタマスク
filteringMasksに配置された２つのマスクフィールドfi
lteringMaskFieldそれぞれが、オブジェクトのカテゴリ
に関するものか、またはオブジェクトを視聴するにあた
っての年齢制限に関するものであるかは、それぞれに対
応するマスク識別子filteringMaskIdentifierに基づい
て認識される。

【０１７５】また、マスク識別子filteringMaskIdentif
ierは、マスクフィールドfilteringMaskFieldに配置さ
れる情報が異なれば、異なる値とされるが、同一の情報
が配置される場合でも、異なる値とされることがある。
即ち、例えば、マスクフィールドfilteringMaskField
に、オブジェクトのカテゴリに関する情報を配置する場
合に、カテゴリ数が増加し、その増加したカテゴリを表
現するために、マスクフィールドfilteringMaskFieldに
割り当てるビット数を増加する必要が生じることがあ
る。具体的には、マスクフィールドfilteringMaskField
が、例えば、当初は８ビットであったのに、１６ビット
に増加される場合がある。このような場合には、８ビッ
トのマスクフィールドfilteringMaskFieldと、１６ビッ
トのマスクフィールドfilteringMaskFieldとで、異なる
マスク識別子filteringMaskIdentifierが対応付けられ
る。これは、受信端末５において、マスクフィールドfi
lteringMaskFieldに割り当てられているビット数を認識
することができるようにするためである。

【０１７６】以上のようなフィルタマスクfilteringMas
ksを、イベントEventMessageに配置することで、選択部
２２において、イベントEventMessageの取捨選択が可能
となり、その結果、サブジェクトに、フィルタマスクfi
lteringMasksを含ませなくても、サブジェクトの取捨選
択が可能となる。即ち、サブジェクトは、イベントEven
tMessageに基づいて取得されるから、イベントEventMes
sageの取捨選択を行うことで、結果的に、サブジェクト
の取捨選択も行われる。さらに、それにより、サブジェ
クトによって更新されるオブジェクトの取捨選択も行わ
れる。

【０１７７】次に、イベントEventMessageにおける生存
時間（期限情報）timeToLiveは、イベントEventMessage
の有効期限を表す。即ち、受信端末５においては、放送
ネットワーク４を介して送信されてくるイベントEventM
essageが受信されるが、例えば、受信端末５では、受信
されたイベントEventMessageが、一旦、データベース２
３に記憶されるので、即座に処理されるとは限らない。
このため、イベントEventMessageを対象に、図１１のデ
ータ要求処理を行おうとするときには、そのイベントEv
entMessageが、既に、使用不能の状態になっていること
がある。

【０１７８】即ち、例えば、イベントEventMessageに、
サブジェクトの放送時刻などが配置されている場合にお
いて、図１１のデータ要求処理の開始時刻が、その放送
時刻を過ぎていることがある。この場合、図１１のデー
タ要求処理を行ったとしても、既にサブジェクトの放送
は終了しているから、受信端末５において、そのサブジ
ェクトを受信することはできない。従って、そのような
使用不能のイベントEventMessageを、データベース２３
に記憶させておくのは、記憶容量の無駄であり、好まし
くない。

【０１７９】また、イベントEventMessageは、受信端末
５に対して、例えば、衛星回線などの放送ネットワーク
４を介して送信する他、上述したように、例えば、イン
ターネットなどの通信ネットワーク６を介して送信する
こともできるが、イベントEventMessageを通信ネットワ
ーク６を介して送信する場合には、回線の混み具合（ト
ラフィック）などに起因して、受信端末５でイベントEv
entMessageを受信するのが、サーバ２による送信がなさ
れてから、相当の時間が経過した後になることがある。
このような場合も、イベントEventMessageが、既に、使
用不能の状態になっていることがある。

【０１８０】そこで、生存時間timeToLiveには、いわ
ば、イベントEventMessageの鮮度を表す指標として、そ
のイベントEventMessageを廃棄する時刻が配置される。

【０１８１】この場合、受信端末５では、イベントの受
信時刻や、データベース２３に記憶されたイベントを参
照した時刻などが、生存時間timeToLiveに配置された時
刻を経過していた場合、そのイベントは使用不能である
として廃棄される（受信したイベントはデータベース２
３に記憶されず、また、参照されたイベントはデータベ
ース２３から削除される）。

【０１８２】なお、サーバ２では、生存時間timeToLive
は、例えば、次のようにして設定される。即ち、サーバ
２のデータ構成部１７では、イベントEventMessageに対
応するオブジェクトの更新間隔（オブジェクトが更新さ
れてから、次に更新されるまでの時間）の平均値などが
求められ、その平均値の整数倍によって表される時間
を、イベントEventMessageの作成時刻に加算して得られ
る時刻が、生存時間timeToLiveに配置される。なお、生
存時間timeToLiveの設定方法は、これに限定されるもの
ではない。

【０１８３】次に、イベントEventMessageにおけるオブ
ジェクト識別子objectIdentifierは、そのイベントEven
tMessageが更新を報知するオブジェクトが存在する位置
に関する情報（位置情報）で、受信端末５では、このオ
ブジェクト識別子objectIdentifierに基づいて、更新さ
れたオブジェクトが特定、認識される。サーバ２におい
て、データベース３のオブジェクトが更新された場合、
そのオブジェクトの更新に対応して、イベントEventMes
sageが作成されるから、その更新されたオブジェクトを
特定するオブジェクト識別子objectIdentifierによれ
ば、その更新を報知するイベントEventMessageを特定す
ることができ、従って、オブジェクト識別子objectIden
tifierは、図７に示したＩＤに相当する。

【０１８４】オブジェクト識別子objectIdentifierの型
ObjectIdentifierは、例えば、次のように定義される。

【０１８５】

【０１８６】取得可能時間avairableTimeは、更新が報
知されたオブジェクトが存在する時間的な位置、即ち、
例えば、その更新後のオブジェクトが、データベース３
に登録された時間や、データベース３に登録されている
時間（オブジェクトが更新されてから、次に更新される
までの時間）などの、オブジェクトが有効に存在する時
間を表す。取得可能時間avairableTimeは、OPTIONALで
あるから、記述しても、またしなくても良く、その型Av
airableTimeは、例えば、次のように定義される。

【０１８７】

【０１８８】開始時刻startTimeは、ここでは、例え
ば、更新後のオブジェクトがデータベース３に登録され
た時刻を表す。また、終了時刻endTimeは、ここでは、
例えば、更新後のオブジェクトが、次に更新される時刻
を表す。なお、取得可能時間avairableTimeを記述する
場合、開始時刻startTimeの記述は必須であるが、終了
時刻endTimeの記述は任意（OPTIONAL）である。

【０１８９】オブジェクト識別子objectIdentifierにお
けるロケータlocatorは、更新が報知されたオブジェク
トが存在する地理的または論理的な位置を表す。ここ
で、オブジェクトの地理的な位置とは、例えば、オブジ
ェクトを管理するサーバ２のインターネットアドレスな
どのネットワーク上の位置を特定するための情報を意味
する。また、論理的な位置とは、オブジェクトが、ある
テーブルやデータ構造などの一部を構成している場合に
おける、そのテーブルやデータ構造中のオブジェクトの
位置を意味する。具体的には、例えば、オブジェクト
が、ＥＰＧ（Electric Program Guide）の、あるチャン
ネルにおける、ある時間帯のテレビジョン放送番組を紹
介する欄を構成している場合には、ＥＰＧ上の、その欄
の位置が、そのオブジェクトの論理的な位置となる。

【０１９０】ロケータlocatorの型Locatorは、例えば、
次のように定義される。

【０１９１】

【０１９２】ここで、CHOICE{}は、かっこ｛｝内で定義
されている変数netLocatorとdvbSpecificLocatorのうち
のいずれかが選択されること（従って、Locatorが選択
型であること）を意味する。

【０１９３】ネットロケータnetLocatorは、インターネ
ットプロトコルによりアクセス可能なドメインのリソー
スを特定するもので、その型NETLocatorは、例えば、以
下のように定義される。

【０１９４】 NETLocator::=SEQUENCE{ nsapSpecificLocator NSAPSpecificLocator OPTIONAL, universalResourceIdentifier EXTERNAL }

【０１９５】ここで、EXTERNALは、ＡＳＮ．１モジュー
ルのスコープ外で定義されるデータ型（外部型）である
ことを意味し、その定義は、ＡＳＮ．１の構文にしたが
った定義でなくても良い。

【０１９６】ＮＳＡＰロケータnsapSpecificLocator
は、ＮＳＡＰ（Networks Service Access Point）を特
定するのに用いられるもので、その型NSAPSpecificLoca
torは、例えば、次のように定義される。

【０１９７】

【０１９８】ＮＳＡＰアドレスnsapAddressは、外部型
（EXTERNAL）であり、そのシンタクスとしては、例え
ば、E.164NSAPformatや、ＡＥＳＡ（ATM(Asynchronous
Transfer Mode) End System Address）のNSAPencodeE.1
64formatなどを採用することができる。なお、E.164NSA
Pformatについては、例えば、ISO/IEC8348:Network Ser
vice Definitionに、AESAのNSAPencodeE.164formatにつ
いては、例えば、ATM User-Network Interface(UNI) Sp
ecification 3.0/3.1に、それぞれ、その定義が記載さ
れている。

【０１９９】付加情報additionalInfoは、ＮＳＡＰアド
レスnsapAddressにアクセスする際に必要となる、例え
ば、ＰＰＰ（Point to Point Protocol）を選択するこ
とを示すプロトコル識別情報や、認証プロトコルに必要
な情報、モデム設定コマンドシーケンス（ヘイズATコマ
ンド）などの付加情報であり、その型は任意（任意型）
（ANY）とされている。なお、付加情報additionalInfo
の記述は任意である。

【０２００】ネットロケータnetLocatorにおけるリソー
ス識別子universalResourceIdentifierは、いわゆるＵ
ＲＩ（Universal Resource Identifier）を意味する。
ＵＲＩによれば、ＷＷＷにおいて提供されるリソースを
一意に識別することができ、それは、ユーザがインター
ネットに直接接続することができる場合（受信端末５
が、インターネットに直接接続される場合）に利用され
る。ここで、リソース識別子universalResourceIdentif
ierのシンタクスとしては、例えば、RFC1630:Universal
Resource Identifiers in WWW: A Unifying Syntax fo
r the Expression of Names and Addresses of Objects
on the Network as used in the World-Wide Webに定
義されているものを利用することができる。

【０２０１】なお、ネットロケータnetLocatorとして、
ＵＲＩと、ＮＳＡＰロケータnsapSpecificLocatorとの
両方を利用可能としたのは、例えば、X.25や公衆網を利
用したダイヤルアップ接続（ＡＴＭ接続も含む）によっ
てアクセス可能な、孤立したインターネットのドメイン
におけるオブジェクトにアクセスすることができるよう
にするためである。

【０２０２】ロケータlocatorにおけるＤＶＢロケータd
vbSpecificLocatorは、ＤＶＢ（Digital Video Broadca
sting）互換のディジタル放送によるストリーム上のリ
ソースを特定するもので、その型DVBSpecificLocator
は、例えば、次のように定義される。

【０２０３】

【０２０４】プリミティブロケータdvbPrimitiveLocato
rは、ＤＶＢにおいて定義されているデータ構造／スト
リームを特定するもので、これにより、例えば、ＤＶＢ
−ＳＩに規定されているディジタル放送によるＥＰＧ上
の任意のテーブルを指定することができる。従って、イ
ベントEventMessageは、例えば、ＤＶＢ−ＳＩに規定さ
れているフォーマットにより放送されるＥＰＧテーブル
の内容の更新にも利用することができる。なお、ＤＶＢ
−ＳＩについては、例えば、ETC300 468:Digital broad
casting systems for television, sound and data ser
vices;Specification for Service Information(SI) in
Digital Video Broadcasting(DVB) systemsに、その詳
細が記載されている。

【０２０５】プリミティブロケータdvbPrimitiveLocato
rの型DVBPrimitiveLocatorは、例えば、次のように定義
される。

【０２０６】

【０２０７】ここで、かっこ［］とその中に配置されて
いる数字は、構造型を構成する同一の型の複数の変数そ
れぞれを識別するためのタグである。

【０２０８】なお、NetworkID, TransportID, packetI
D, serviceID, tableID, tableIDExtention, sectionNu
mber, eventID, componentTagについては、例えば、ISO
/IEC13818-1:Infomation technology-Generic coding o
f moving pictures and associated audio information
-Part1:Systems-International Standard(IS)、およびE
TC300 468:Digital broadcasting systems for televis
ion, sound and data services;Specification for Ser
vice Information(SI) in Digital Video Broadcasting
(DVB) systemsに、その詳細が記載されているので、こ
こでは、説明を省略する。

【０２０９】ＤＶＢロケータDVBSpecificLocatorにおけ
るデータカルーセルロケータdvbDataCarouselLocator
は、データカルーセル（Data Carousel）と呼ばれるデ
ータ構造を特定するもので、その型DVBDataCarouselLoc
atorは、例えば、次のように定義される。

【０２１０】

【０２１１】また、ＤＶＢロケータDVBSpecificLocator
におけるオブジェクトカルーセルロケータdvbObjectCar
ouselLocatorは、オブジェクトカルーセル（Object Car
ousel）と呼ばれるデータ構造を特定するもので、その
型DVBObjectCarouselLocatorは、例えば、次のように定
義される。

【０２１２】

【０２１３】なお、データカルーセル、オブジェクトカ
ルーセル、groupID, moduleID, carouselID, objectKey
については、例えば、Digital Video Broadcasting:DVB
Specification for Data Broadcasting-Final Draft 1
2/02/97、およびImplementation Guidelines for Datab
roadcasting(SI-DAT382 Rev.3)に、その詳細が記載され
ているので、ここでは、説明を省略する。

【０２１４】次に、イベントEventMessageにおけるオブ
ジェクトバージョンobjectVersionは、そのイベントEve
ntMessageに基づいて取得されるサブジェクトによって
更新されるオブジェクトの、その更新後のバージョンを
表し、図７におけるバージョン情報に相当する。オブジ
ェクトバージョンobjectVersionとしては、例えば、オ
ブジェクトが更新される度にインクリメントされる整数
値や、更新後のオブジェクトのハッシュ値などを用いる
ことができる。

【０２１５】イベントEventMessageにおけるサブジェク
トリンクsubjectLinksは、そのイベントEventMessageに
基づいて取得されるサブジェクト（オブジェクト識別子
objectIdentifierによって特定されるオブジェクトを更
新するためのサブジェクト）を特定するためのもので、
その型SubjectLinksは、例えば、次のように定義され
る。

【０２１６】

【０２１７】サブジェクト識別子subjectIdentifier
は、上述のオブジェクト識別子objectIdentifierと同一
の型ObjectIdentifierを有し、そこには、サブジェクト
が存在する位置に関する情報（位置情報）が配置され
る。従って、受信端末５では、このサブジェクト識別子
subjectIdentifierに基づいて、オブジェクトを更新す
るためのサブジェクトが取得される。

【０２１８】なお、サブジェクト識別子subjectIdentif
ierは、ObjectIdentifier型であるから、取得可能時間a
vairableTimeを有する場合があるが、これは、図７で説
明した放送スケジュール情報の中の放送時刻に相当す
る。また、サブジェクト識別子subjectIdentifierは、
ロケータlocatorを有するが、これは、図７で説明した
サーバアクセス情報（サーバ２などのＩＰアドレス）
（サブジェクトの地理的位置）や、放送スケジュール情
報の中の放送チャンネル（サブジェクトの論理的位置）
に相当する。

【０２１９】サブジェクトバージョンsubjectVersion
は、整数型（INTEGER）で、サブジェクトのバージョン
を表す。即ち、例えば、サブジェクトに、いわゆるバグ
があり、その修復がされたサブジェクトが新たに作成さ
れる場合がある。また、サブジェクトの内容は同一のま
まで、そのシンタクスが変更される場合がある。そのよ
うな場合において、バグの修正前のサブジェクトと修正
後のサブジェクトとを区別したり、シンタクスの変更前
のサブジェクトと変更後のサブジェクトとを区別するた
めなどに、サブジェクトバージョンsubjectVersionは用
いられる。

【０２２０】サービス仕様qosSpecificationには、サブ
ジェクトを、サブジェクト識別子subjectIdentifierに
基づいて取得するかどうかを決めるための基準として用
いることのできる情報（取得決定基準情報）が配置され
る。即ち、サブジェクトリンクSubjectLinksは、SEQUEN
CE OF{}で定義されているから、かっこ｛｝内で定義さ
れている変数の組み合わせが、１以上配置されて構成さ
れる。具体的には、例えば、サブジェクトが、放送ネッ
トワーク４を介して放送されるとともに、サーバ２にお
いて、受信端末５からの要求に応じて、通信ネットワー
ク６を介して送信される場合には、放送ネットワーク４
を介して放送されるサブジェクトと、通信ネットワーク
６を介して送信されるサブジェクトとのそれぞれについ
て、サブジェクトリンクSubjectLinksを規定するsubjec
tIdentifier, subjectVersion, qosSpecification, cli
entIdentifierが記述される。このような場合におい
て、サービス仕様qosSpecificationは、サブジェクト
を、放送ネットワーク４または通信ネットワーク６のう
ちのいずれを利用して受信するのかを決定するために参
照される。

【０２２１】サービス仕様qosSpecificationの型QOSSpe
cificationは、例えば、次のように定義される。

【０２２２】

【０２２３】ＱＯＳタイプqosSpecTypeには、サブジェ
クトを、サブジェクト識別子subjectIdentifierに基づ
いて取得するかどうかを決めるための基準として用いる
情報の種別を表す整数値が配置される。即ち、ＱＯＳタ
イプqosSpecTypeは、それと組になっているＱＯＳ値qos
SpecValueが、どのような情報の値であるのかを表す。

【０２２４】ＱＯＳ値qosSpecValueには、サブジェクト
識別子subjectIdentifierに基づいて、サブジェクトを
取得するかどうかを決めるための基準として用いる情報
としての、例えば、サーバ２側にかかっている負荷の状
況や、サブジェクトのデータ量、通信ネットワーク６の
混み具合などに対応する整数値が配置される。

【０２２５】例えば、ＱＯＳ値qosSpecValueが、サーバ
２側にかかっている負荷が大きいことを表している場合
には、サブジェクトを、通信ネットワーク６を介して要
求したのでは、サブジェクトが送信されてくるのに時間
を要すると予想されるから、放送ネットワーク４を介し
て放送されてくるのを待って受信した方が良いとの判断
の基準にすることができる。また、例えば、ＱＯＳ値qo
sSpecValueが、サブジェクトのデータ量が多いことを表
している場合には、サブジェクトを、通信ネットワーク
６を介して要求したのでは、データ量の多いサブジェク
トを受信するのに通信コストが多くかかると予想される
から、放送ネットワーク４を介して放送されてくるのを
待って受信した方が良いとの判断の基準にすることがで
きる。さらに、例えば、ＱＯＳ値qosSpecValueが、通信
ネットワーク６のトラフィック量が少ないことを表して
いる場合には、サブジェクトを、即座に、かつ短い時間
で取得することができると予想されるから、通信ネット
ワーク６を介して受信した方が良いとの判断の基準にす
ることができる。

【０２２６】ここで、以上のようなことから、ＱＯＳ値
qosSpecValueは、サブジェクトの提供サービスの質を表
しているということもできる。

【０２２７】サブジェクトリンクsubjectLinksにおける
クライアント識別子clientIdentifierには、サブジェク
トの取得が許可されているユーザに関する情報（ユーザ
情報）が配置され、その型ClientIdentfierは、例え
ば、次のように定義される。

【０２２８】

【０２２９】グループ識別子clientGroupIdentifierに
は、ある複数の受信端末のグループを特定する整数値が
配置される。グループ識別子clientGroupIdentifierに
よれば、それによって特定される複数の受信端末だけ
に、サブジェクトを取得させることが可能となる。

【０２３０】クライアント識別子clientIdentifiersに
は、１以上の受信端末のユーザＩＤ（図１３および図１
４で説明したユーザＩＤ）が配置される。クライアント
識別子clientIdentifiersによれば、それによって特定
される１以上の受信端末だけに、サブジェクトを取得さ
せることが可能となる。なお、クライアント識別子clie
ntIdentifiersの型であるSET OF INTEGERは、整数型の
集合（集合型）を表す。

【０２３１】以上のように、クライアント識別子client
Identifierによれば、サブジェクトを取得させる受信端
末を制限することができるので、例えば、１のサーバ
に、サブジェクトの要求が集中することなどを防止する
ことができる。

【０２３２】以上、イベントを、任意のトランスポート
プロトコル上で実現するためのフォーマットを、ＡＮ
Ｓ．１を用いた抽象構文表現によって表したが、このよ
うなフォーマットのイベントの符号化を、例えば、ＡＳ
Ｎ．１準拠の商用／パブリックドメインソフトウェアの
ツールＳｎａｃｃを利用して行う場合には、例えば、以
下のようなファイルを、その入力として与えてやればよ
い。

【０２３３】 EventMessage DEFINITIONS::= BEGIN EventMessage::=SEQUENCE{ formatVersion FormatVersion, filteringMasks FilteringMasks OPTIONAL, timeToLive UTCTime, objectIdentifier ObjectIdentifier, objectVersion INTEGER OPTIONAL, subjectLinks SubjectLinks OPTIONAL } FormatVersion::=SEQUENCE{ majorVersion INTEGER, minorVersion INTEGER } FilteringMasks::=SEQUENCE OF{ filteringMaskIdentifier INTEGER, filteringMaskField ANY DEFINED BY filteringMaskIdentifiler } ObjectIdentifier::=SEQUENCE{ avairableTime AvairableTime OPTIONAL, locator Locator } AvairableTime::=SEQUENCE{ startTime UTCTime, endTime UTCTime OPTIONAL } Locator::=CHOICE{ netLocator NETLocator dvbSpecificLocator DVBSpecificLocator } NETLocator::=SEQUENCE{ nsapSpecificLocator NSAPSpecificLocator OPTIONAL, universalResourceIdentifier EXTERNAL } NSAPSpecificLocator::=SEQUENCE{ nsapAddress EXTERNAL, additionalInfo ANY OPTIONAL } DVBSpecificLocator::=CHOICE{ dvbPrimitiveLocator DVBPrimitiveLocator, dvbDataCarouselLocator DVBDataCarouselLocator, dvbObjectCarouselLocator DVBObjectCarouselLocator } DVBPrimitiveLocator::=SEQUENCE{ networkID [0] INTEGER OPTIONAL, transportStreamID [1] INTEGER OPTIONAL, packetID [2] INTEGER OPTIONAL, serviceID [3] INTEGER OPTIONAL, tableID [4] INTEGER OPTIONAL, tableIDExtention [5] INTEGER OPTIONAL, sectionNumber [6] INTEGER OPTIONAL, eventID [7] INTEGER OPTIONAL, componentTag [8] INTEGER OPTIONAL } DVBDataCarouselLocator::=SEQUENCE{ dvbPrimitiveLocator DVBPrimitiveLocator, groupID [0] INTEGER OPTIONAL, moduleID [1] INTEGER OPTIONAL } DVBObjectCarouselLocator::=SEQUENCE{ dvbPrimitiveLocator DVBPrimitiveLocator, carouselID [0] INTEGER OPTIONAL, moduleID [1] INTEGER OPTIONAL, objectKey [2] INTEGER OPTIONAL } SubjectLinks::=SEQUENCE OF{ subjectIdentifier ObjectIdentifier, subjectVersion INTEGER OPTIONAL, qosSpecification QOSSpecification OPTIONAL, clientIdentifer ClientIdentifier OPTIONAL } QOSSpecification::=SEQUENCE OF{ qosSpecType INTEGER, qosSpecValue INTEGER } ClientIdentifier::=CHOICE{ clientGroupIdentifier INTEGER, clientIdentifiers SET OF INTEGER } END

【０２３４】次に、上述の場合においては、受信端末５
が、サーバ２が送信するイベントを受信し、そのイベン
トに配置されたフィルタマスクfilteringMasksに基づい
て、その取捨選択、即ち、いわばイベントのフィルタリ
ングを行い、選択されたイベントに基づいて、オブジェ
クトの更新を行うようになされている。

【０２３５】ここで、フィルタマスクfilteringMasks
は、上述したように、マスク識別子filteringMaskIdent
ifierと、マスクフィールドfilteringMaskFieldとから
構成されるが、マスクフィールドfilteringMaskFieldと
しては、例えば、本件発明者が先に提案した特願平１０
−１３０３９２号（以下、適宜、文献１という）に記載
されているようなフィーマットのものを用いることがで
きる。

【０２３６】即ち、文献１では、あるメタデータから抽
出した情報の一部または全部をフィルタリングに適した
フォーマットに変換して、マスクフィールドfilteringM
askFieldとして用いる例が示されている。

【０２３７】この例を応用した場合、サーバ２では、更
新されるオブジェクト（イベントの中のオブジェクト識
別子objectIdentifierで特定されるオブジェクト）のメ
タ情報を、文献１で例示されているメタデータシンタク
ス（ＰＩＣＳや、ＲＤＦ／ＸＭＬなど）で記述し、それ
を、やはり文献１で例示されている方法で抽出、変換し
て、マスクフィールドfilteringMaskFieldに配置する値
を生成する。なお、このマスクフィールドfilteringMas
kFieldを解釈するためのスキーマは、文献１で例示され
ているフォーマットで記述され、そのマスクフィールド
filteringMaskFieldが送信される前に、あるいは同時
に、受信端末５に送信しておく（または、受信端末５
が、httpなどの所定のプロトコルによって、マスクフィ
ールドfilteringMaskFieldを解釈するためのスキーマを
取得しておく）。一方、受信端末５では、そのスキーマ
を参照し、マスクフィールドfilteringMaskFieldを解釈
して、イベントのフィルタリングを行う。

【０２３８】具体的には、サーバ２において、例えば、
図１５に示すようなディレクトリ構造で、オブジェクト
が管理されている場合を考えると、イベントのフィルタ
リングは、次のようにして行われる。なお、図１５にお
いては、ディレクトリ（ディレクトリノード）を○印
で、オブジェクトとしてのディレクトリエントリを●印
で、それぞれ示してある。また、図１５においては、ル
ートディレクトリ（root）は、２つの下位ディレクトリ
ａおよびｂを有し、ディレクトリａは、３つの下位ディ
レクトリａａ，ａｂ，ａｃを有している。そして、ディ
レクトリａａ，ａｂ，ａｃそれぞれは、幾つかのオブジ
ェクトを有している。また、ディレクトリｂは、２つの
下位ディレクトリｂａおよびｂｂを有しており、ディレ
クトリｂａ，ｂｂそれぞれは、幾つかのオブジェクトを
有している。ここで、図１５における各ディレクトリ
は、その下位階層にあるオブジェクトの、例えばカテゴ
リに相当する。

【０２３９】図１５のディレクトリ構造において、ルー
トディレクトリが有する２つのディレクトリａまたはｂ
それぞれには、例えば、ビット０または１が割り当てら
れている。また、ディレクトリａが有する３つのディレ
クトリａａ，ａｂ，ａｃそれぞれには、例えば、ビット
００，０１，１０が割り当てられている。さらに、ディ
レクトリｂが有する２つのディレクトリｂａまたはｂｂ
それぞれには、例えば、ビット０または１が割り当てら
れている。

【０２４０】このような場合に、各ディレクトリを、ル
ートディレクトリから下位階層への最短のパスを考えた
ときに通るディレクトリに割り当てられたビット（また
はビット列）を、上位ビットから順次配置した、例え
ば、１バイト（８ビット）のビット列で表すこととす
る。

【０２４１】この場合、ルートディレクトリの下位階層
のディレクトリａは、「0*******」で、ディレクトリａ
の下位階層のディレクトリａａ（以下、適宜、ａ．ａａ
と記述する）は、「000*****」で、ディレクトリａの下
位階層のディレクトリａｂ（以下、適宜、ａ．ａｂと記
述する）は、「001*****」で、ディレクトリａの下位階
層のディレクトリａｃ（以下、適宜、ａ．ａｃと記述す
る）は、「010*****」で、それぞれ表される。また、ル
ートディレクトリの下位階層のディレクトリｂは、「1*
******」で、ディレクトリｂの下位階層のディレクトリ
ｂａ（以下、適宜、ｂ．ｂａと記述する）は、「10****
**」で、ディレクトリｂの下位階層のディレクトリｂｂ
（以下、適宜、ｂ．ｂｂと記述する）は、「11******」
で、それぞれ表される。なお、*印は、ドントケア（do
n't care）を表す。

【０２４２】そして、フィルタマスクfilteringMasks
（のマスクフィールドfilteringMaskField）には、それ
が配置されているイベントが更新を報知するオブジェク
トが属しているディレクトリを表す、上述のようなビッ
ト列を配置する。従って、ここでは、フィルタマスクfi
lteringMasksは、１バイトのワードとなる。

【０２４３】一方、受信端末５では、フィルタマスクfi
lteringMasksによってイベントをフィルタリングするた
めのマスク値が設定される。即ち、受信端末５におい
て、例えば、ディレクトリｂ．ｂｂが有するオブジェク
トに対するアクセス頻度が高い場合には（従って、ユー
ザは、そのオブジェクトに高い関心を持っている）、そ
のディレクトリｂ．ｂｂ以外をマスクするためのマスク
値「11xxxxxx」が設定される。

【０２４４】この場合、受信端末５では、マスク値のう
ちのｘの部分は無視され、１または０となっている部分
（以下、適宜、有効ビットという）が一致するフィルタ
マスクfilteringMasksを有するイベントだけが選択され
る。従って、マスク値が、上述のように「11xxxxxx」で
ある場合には、上位２ビットがいずれも１のフィルタマ
スクfilteringMasksが配置されたイベントだけ、即ち、
ここでは、ディレクトリｂ．ｂｂを表すビット列がフィ
ルタマスクfilteringMasksに配置されているイベントだ
けが選択される。その結果、アクセス頻度の高い、ディ
レクトリｂ．ｂｂが有するオブジェクトだけが更新され
る。

【０２４５】また、受信端末５において、例えば、ディ
レクトリａ．ａｂが有するオブジェクトに対するアクセ
ス頻度が高い場合には、そのディレクトリａ．ａｂ以外
をマスクするためのマスク値「001xxxxx」が設定され
る。

【０２４６】この場合、受信端末５では、上位３ビット
それぞれが０，０，１となっているフィルタマスクfilt
eringMasksが配置されたイベントだけ、即ち、ここで
は、ディレクトリａ．ａｂを表すビット列がフィルタマ
スクfilteringMasksに配置されているイベントだけが選
択される。その結果、アクセス頻度の高い、ディレクト
リａ．ａｂが有するオブジェクトだけが更新される。

【０２４７】また、例えば、受信端末５において、ディ
レクトリａ．ａａが有するオブジェクト、ディレクトリ
ａ．ａｂが有するオブジェクト、およびディレクトリ
ａ．ａｃが有するオブジェクト、即ち、ディレクトリａ
を共通のディレクトリとして有するオブジェクトに対す
るアクセス頻度が高い場合には、そのディレクトリａ以
外をマスクするためのマスク値「0xxxxxxx」が設定され
る。

【０２４８】この場合、受信端末５では、最上位ビット
が０となっているフィルタマスクfilteringMasksが配置
されたイベントだけ、即ち、ここでは、ディレクトリ
ａ，ａ．ａａ，ａ．ａｂ，ａ．ａｃのうちのいずれかを
表すビット列がフィルタマスクfilteringMasksに配置さ
れているイベントだけが選択される。その結果、やは
り、アクセス頻度の高い部分だけが更新される。

【０２４９】ところで、上述した場合では、受信端末５
において、イベントのフィルタリングは、イベントを受
信するごとに行われるようになされている。

【０２５０】しかしながら、受信端末５において受信し
たイベントすべてを対象にフィルタリングを行うという
ことは、いわば、サーバ２から送信されてくるイベント
すべてを、常時監視していなければならず、このよう
に、イベントを常時監視することは、受信端末５に多大
な負荷をかけることになり、受信端末５のリソースの効
率的な活用の観点から望ましいとはいえない。即ち、受
信端末５において、例えば、図９に示した各ブロックに
相当する処理を行うプロセッサ（図示せず）の処理能力
や、データの記憶容量、電源がバッテリから供給される
場合のバッテリの容量などのリソースの制約がある場合
（例えば、特に、受信端末５が移動体通信が可能な携帯
型の端末である場合）には、イベントを常時監視するこ
とは、受信端末５にとって大きな負担となる。

【０２５１】そこで、サーバ２を有する放送局には、送
信しようとしているイベントに、そこに配置されたフィ
ルタマスクfilteringMasksと同一のフィルタマスクfilt
eringMasksが配置された他の１以上のイベントを認識す
るための認識情報を配置させるようにすることができ
る。

【０２５２】この場合、受信端末５では、あるイベント
を受信すると、そこに配置された認識情報から、そのイ
ベントと同一のフィルタマスクfilteringMasksが配置さ
れたイベントを認識することが可能となる。

【０２５３】即ち、認識情報として、例えば、その認識
情報が配置されたイベントの次に、そのイベントと同一
のフィルタマスクfilteringMasksが配置されたイベント
の送信が開始される送信開始時刻を含む情報を採用す
る。この場合、受信端末５では、あるイベントを受信す
ると、そこに配置された認識情報から、そのイベントと
同一のフィルタマスクfilteringMasksが配置されたイベ
ントが送信されてくる送信開始時刻を認識することが可
能となり、従って、あるイベントを受信し、フィルタリ
ングによって、そのイベントを選択した場合には、認識
情報から得られる送信開始時刻となるまで、イベントの
フィルタリングを中断することが可能となる。その結
果、受信端末５において、イベントを常時監視する必要
がなくなり、受信端末５における処理の負荷を軽減する
ことができる。

【０２５４】具体的には、放送局では、例えば、ディレ
クトリｂ．ｂｂに属するオブジェクトの変更を報知する
イベントには、フィルタマスクfilteringMasks「11****
**」が配置される。さらに、そのイベントには、その次
に、同一のフィルタマスクfilteringMasks「11******」
が配置されて送信されるイベントの認識情報も配置さ
れ、送信される。

【０２５５】この場合、受信端末５において、例えば、
ディレクトリｂ．ｂｂ以外をマスクするためのマスク値
「11xxxxxx」が設定されている場合には、上位２ビット
がいずれも１のフィルタマスクfilteringMasksが配置さ
れたイベント、即ち、ここでは、ディレクトリｂ．ｂｂ
を表すビット列がフィルタマスクfilteringMasksに配置
されているイベントが受信され、選択される。この選択
されたイベントには、上述したように、その次に、フィ
ルタマスクfilteringMasks「11******」が配置されて送
信されるイベントの認識情報が配置されており、受信端
末５は、この認識情報から、フィルタマスクfilteringM
asks「11******」が配置されたイベントの送信が、次に
開始される時刻を認識し、その時刻まで、イベントのフ
ィルタリングを中断する（イベントの取捨選択するため
の処理を行わない）ようにすることができる。

【０２５６】あるいは、放送局では、例えば、ディレク
トリａに属するオブジェクトの変更を報知するイベント
には、フィルタマスクfilteringMasks「0*******」が配
置される。即ち、図１５では、ディレクトリａに属する
オブジェクトは、その下位ディレクトリａａ，ａｂ，ａ
ｃに属するオブジェクトであるから、そのオブジェクト
の変更を報知するイベントには、ディレクトリａに対応
するビット０を最上位ビットとし、それに続けて、ディ
レクトリａａ，ａｂ，ａｃに対応するビット００，０
１，１０を付加した３つの「000*****」、「001****
*」、「010*****」のうちのいずれかがフィルタマスクf
ilteringMasksとして配置され、さらに、その３つのい
ずれかがフィルタマスクfilteringMasksとして配置され
たイベントには、その次に、同一のフィルタマスクfilt
eringMasksが配置されて送信されるイベントの認識情報
も配置され、送信される。

【０２５７】なお、この場合の「同一」のフィルタマス
クfilteringMasksには、フィルタマスクfilteringMasks
が完全に一致する場合の他、フィルタマスクfilteringM
asksの上位１ビット以上だけが一致する場合も含ませる
ことができる。即ち、「000*****」、「001*****」、
「010*****」のうちのいずれかがフィルタマスクfilter
ingMasksとして配置されたイベントには、その次に、そ
の３つのうちのいずれかがフィルタマスクfilteringMas
ksとして配置されて送信されるイベントの認識情報を配
置して送信するようにすることができる。

【０２５８】この場合、受信端末５において、例えば、
ディレクトリａ以外をマスクするためのマスク値「0xxx
xxxx」が設定されている場合には、最上位ビットが１の
フィルタマスクfilteringMasksが配置されたイベント、
即ち、ここでは、ディレクトリａ，ａ．ａａ，ａ．ａ
ｂ，ａ．ａｃのうちのいずれかを表すビット列がフィル
タマスクfilteringMasksに配置されているイベントが受
信され、選択される。この選択されたイベントには、上
述したように、その次に、「000*****」、「001****
*」、「010*****」のうちのいずれかがフィルタマスクf
ilteringMasksとして配置されて送信されるイベントの
認識情報が配置されており、受信端末５は、この認識情
報から、その３つのうちのいずれかがフィルタマスクfi
lteringMasksとして配置されたイベントの送信が、次に
開始される時刻を認識し、その時刻まで、イベントのフ
ィルタリングを中断する（イベントの取捨選択するため
の処理を行わない）ようにすることができる。

【０２５９】以上のようにすることで、受信端末５で
は、必要なタイミングにおいて、イベントを監視するだ
けで済むようになり、処理負担の抑制を図ることができ
る。

【０２６０】次に、図１６は、以上のようにして受信端
末５の処理負担の軽減を図る場合の、図１の放送局の構
成例を示している。なお、図１６においては、イベント
に関する処理に関係する部分だけを図示してあり、その
他の、例えば、サブジェクトの処理に関する部分等は、
図２のサーバ２における場合と同様であるため、その図
示は省略してある。

【０２６１】送信側マスタデータベース３１は、図１の
データベース３に相当し、各種のオブジェクトを記憶し
ている。更新検出装置３２は、送信側マスタデータベー
ス３１におけるオブジェクトの更新を検出し、オブジェ
クトの更新があった旨を、イベントメッセージ／フィル
タリングマスク（eventMessage/filteringMask）生成装
置（以下、適宜、生成装置という）３３に知らせるよう
になされている。生成装置３３（構成手段）は、更新検
出装置３２からオブジェクトの更新があった旨を受信す
ると、送信側マスタデータベース３１を参照すること
で、その更新を報知するためのイベントeventMessageを
構成（生成）し、イベントメッセージ（eventMessage）
データベース（以下、適宜、単に、データベースとい
う）３４に供給するようになされている。データベース
３４は、生成装置３３からのイベントeventMessageを一
時記憶するようになされている。

【０２６２】イベントメッセージ（eventMessage）スケ
ジューリング装置（以下、適宜、スケジューリング装置
という）３５は、データベース３４に記憶されたイベン
トeventMessageの送信スケジュールを設定するようにな
されている。この送信スケジュールは、イベントリンク
（eventLink）設定装置（以下、適宜、設定装置とい
う）３６、およびイベントメッセージ（eventMessage）
放送装置（以下、適宜、放送装置という）３７に供給さ
れるようになされている。

【０２６３】設定装置３６（構成手段）は、スケジュー
リング装置３５からの送信スケジュールに基づいて、上
述の認識情報に相当するイベントリンクeventLinkを生
成し、データベース３４に記憶されたイベントeventMes
sageの中に配置（設定）するようになされている。

【０２６４】放送装置３７（送信手段）は、スケジュー
リング装置３５からの送信スケジュールにしたがい、デ
ータベース３４に記憶されたイベントeventMessageを読
み出し、放送ネットワーク４を介して送信するようにな
されている。

【０２６５】以上のように構成される放送局では、スケ
ジューリング装置３５において送信スケジュールを設定
した後、設定装置３６において、データベース３４に記
憶されたイベントeventMessageに配置されたフィルタマ
スクfilteringMaskが解析される。さらに、フィルタマ
スクfilteringMaskのフォーマットが同一のスキーマに
基づいている場合には、設定装置３６において、同一の
フィルタマスクfilteringMaskが配置されたイベントの
中に、イベントリンクeventLinkメンバが追加され、そ
のイベントリンクeventLink構造に、次に、同一のフィ
ルタマスクfilteringMaskが配置されたイベントが送信
される送信開始時刻avairableTimeが埋め込まれる。

【０２６６】即ち、ここでは、イベントEventMessage
は、例えば、上述の定義にイベントリンクeventLinkを
追加して、次のように定義される。

【０２６７】

【０２６８】イベントEventMessageに、新たに追加され
たeventLinksは、それが配置されるイベントeventMessa
geに配置されたフィルタマスクfilteringMasksと同一の
フィルタマスクfilteringMasksが配置されるイベントev
entMessageの、いわば所在を認識するための認識情報
で、その型EventLinksは、例えば、次のように定義され
る。

【０２６９】

【０２７０】イベントリンクeventLinksのフィルタマス
クfilteringMasksには、イベントeventMessageのフィル
タマスクfilteringMasksと同一の値が配置される。ま
た、eventIdentifierは、上述した型ObjectIdentifier
を有し、そこには、イベントリンクeventLinksのフィル
タマスクfilteringMasksと同一の値が（イベントの）フ
ィルタマスクfilteringMasksに配置されたイベントeven
tMessageが存在する位置に関する情報（位置情報）が配
置される。

【０２７１】なお、上述したように、型ObjectIdentifi
erは、avairableTimeをメンバとして有し、さらに、ava
irableTimeは、startTimeおよびendTimeを有する。本実
施の形態では、例えば、イベントリンクeventLinksのフ
ィルタマスクfilteringMasksと同一の値が（イベント
の）フィルタマスクfilteringMasksに配置されたイベン
トeventMessageの送信開始時刻または送信終了時刻が、
それぞれstartTimeまたはendTimeに設定されるようにな
されている。

【０２７２】次に、図１７のフローチャートを参照し
て、図１６の放送局の処理について説明する。

【０２７３】まず、更新検出装置３２では、ステップＳ
８１において、送信側マスタデータベース３１における
オブジェクトに更新があったかどうかが判定され、なか
ったと判定された場合、ステップＳ８１に戻る。また、
ステップＳ８１において、オブジェクトの更新があった
と判定された場合、即ち、更新検出装置３２において、
送信側マスタデータベース３１におけるオブジェクトの
更新が検出された場合、その旨が、生成装置３３に供給
される。

【０２７４】生成装置３３は、更新検出装置３２から、
オブジェクトが更新された旨を受信すると、ステップＳ
８２に進み、送信側マスタデータベース３１を参照する
ことで、その更新を報知するためのイベントeventMessa
geを構成する。即ち、生成装置３３は、例えば、format
Versionや、filteringMasks，timeToLiveなどのメンバ
を配置して、イベントeventMessageを構成する。なお、
生成装置３３は、その時点で値の分かっているメンバ
（変数）だけを配置することで、イベントeventMessage
を構成する。即ち、イベントeventMessageを構成するメ
ンバのうち、例えば、設定装置３６で設定されるイベン
トリンクeventLinks等は、ここでは、イベントeventMes
sageに配置されない。

【０２７５】生成装置３３で得られたイベントeventMes
sageは、データベース３４に供給されて記憶される。そ
の後、スケジューリング装置３５は、ステップＳ８３に
おいて、データベース３４に記憶されたイベントeventM
essageの送信スケジュールを設定し、その送信スケジュ
ールを、設定装置３６および放送装置３７に供給する。

【０２７６】設定装置３６は、データベース３４に記憶
されたイベントeventMessageの送信スケジュールを受信
すると、ステップＳ８４において、その送信スケジュー
ルに基づき、データベース３４に記憶されたイベントev
entMessageの中で、ある一定時間内に送信されるイベン
トeventMessageを認識する。さらに、設定装置３６は、
その認識したイベントeventMessageに配置されたフィル
タマスクfilteringMasksを抽出し、ステップＳ８５に進
む。

【０２７７】ステップＳ８５では、設定装置３６は、ス
テップＳ８４で抽出したフィルタマスクfilteringMasks
の値を判定することで、それらの中から、値が同一（上
述した意味の「同一」）のものどうしのフィルタマスク
filteringMasksが配置されたイベント（以下、適宜、同
一カテゴリイベントという）eventMessageを検出する。
そして、設定装置３６は、同一カテゴリイベントeventM
essageについて、イベントリンクeventLinksを生成し、
その同一カテゴリイベントeventMessageに配置する。以
上のようにして、データベース３４には、イベントリン
クeventLinksが配置されたイベントeventMessageが記憶
される。

【０２７８】その後、ステップＳ８６に進み、放送装置
３７は、スケジューリング装置３５からの送信スケジュ
ールにしたがい、データベース３４に記憶されたイベン
トeventMessageを読み出し、放送ネットワーク４を介し
て送信し、ステップＳ８１に戻る。

【０２７９】以上の処理により、放送局では、例えば、
次のようなイベントeventMessageが構成されて送信され
る。

【０２８０】即ち、いま、送信側マスターデータベース
３１において、例えば、図１５に示したようなディレク
トリ構造でオブジェクトが記憶されており、ディレクト
リａ．ａｂに属するある１のオブジェクトdata1と、他
の１のオブジェクトdata3が更新され、さらに、ディレ
クトリｂ．ｂｂに属するある１のオブジェクトdata2
と、他の１のオブジェクトdata4が更新されたとする。

【０２８１】この場合、生成装置３３において、オブジ
ェクトdata1乃至data4それぞれの更新を報知するための
イベントeventMessage１，eventMessage２，eventMessa
ge3，eventMessage4が構成される。

【０２８２】さらに、スケジューリング装置３５では、
例えば、その４つのイベントeventMessage１乃至eventM
essage4を送信する送信スケジュール（例えば、送信開
始時刻、送信終了時刻、送信レート（転送レート）、さ
らには、送信を繰り返し行う場合には、その周期や回数
など）が設定される。

【０２８３】そして、その後、設定装置３６において、
必要なイベントリンクeventLinksが生成され、イベント
eventMessage１，eventMessage２，eventMessage3，eve
ntMessage4に、必要に応じて配置される。

【０２８４】ここで、いま、スケジューリング装置３５
において、図１８に示すように、イベントeventMessage
１については、例えば、１２時３４分乃至１２時３５分
と、１８時３４分乃至１８時３５分が、eventMessage２
については、例えば、１３時４２分乃至１３時４３分
が、eventMessage3については、例えば、１５時２７分
乃至１５時２８分が、eventMessage4については、１６
時４２分乃至１６時４３分が、それぞれ送信時刻（送信
時間）として設定されたとする。

【０２８５】この場合、１２時３４分から送信が開始さ
れ、１２時３５分で送信が終了するイベントeventMessa
ge１としては、例えば、次のようなものが構成される。

【０２８６】 eventMessage１{ formatVersion(?), filteringMasks(ディレクトリａ．ａｂを表すビット列「001*****」), timeToLive(?), objectIdentifier(data1の識別子), objectVersion(?), subjectLinks(?), eventLinks eventLinks{ filteringMasks(ディレクトリａ．ａｂを表すビット列「001*****」), eventIdentifier{ avairableTime{ startTime(１５時２７分),endTime(１５時２８分) }, locator{ dvbSpecificLocator(?) } } } } }

【０２８７】なお、上述のイベントeventMessage1（後
述するeventMessage２，eventMessage3，eventMessage4
についても同様）におけるメンバの後に配置したカッコ
（）内の記述は、そのメンバに設定された値を示してい
る。また、カッコ（）内の記述が？になっているのは、
設定装置３６の処理に関係のないメンバを表している。

【０２８８】１２時３４分乃至１２時３５分の間に送信
されるイベントeventMessage1に配置されたフィルタマ
スクfilteringMasksと同一のフィルタマスクfilteringM
asksが配置されたイベントのうち、イベントeventMessa
ge1の送信後に最も早く（次に）送信されるのは、ここ
では、１５時２７分乃至１５時２８分の間に送信される
イベントeventMessage3であり（図１８）、このため、
イベントeventMessage1のイベントリンクeventLinksを
構成するavairableTimeのstartTimeまたはendTimeに
は、そのイベントeventMessage3の送信開始時刻である
１５時２７分、または送信終了時刻である１５時２８分
が、それぞれ配置される。

【０２８９】次に、１３時４２分から送信が開始され、
１３時４３分で送信が終了するイベントeventMessage2
としては、例えば、次のようなものが構成される。

【０２９０】 eventMessage2{ formatVersion(?), filteringMasks(ディレクトリｂ．ｂｂを表すビット列「11******」), timeToLive(?), objectIdentifier(data2の識別子), objectVersion(?), subjectLinks(?), eventLinks eventLinks{ filteringMasks(ディレクトリｂ．ｂｂを表すビット列「11******」), eventIdentifier{ avairableTime{ startTime(１６時４２分),endTime(１６時４３分) }, locator{ dvbSpecificLocator(?) } } } } }

【０２９１】１３時４２分乃至１３時４３分の間に送信
されるイベントeventMessage2に配置されたフィルタマ
スクfilteringMasksと同一のフィルタマスクfilteringM
asksが配置されたイベントのうち、イベントeventMessa
ge2の送信後に最も早く送信されるのは、ここでは、１
６時４２分乃至１６時４３分に送信されるイベントeven
tMessage4であり（図１８）、このため、イベントevent
Message2のイベントリンクeventLinksを構成するavaira
bleTimeのstartTimeまたはendTimeには、そのイベントe
ventMessage4の送信開始時刻である１６時４２分、また
は送信終了時刻である１６時４３分が、それぞれ配置さ
れる。

【０２９２】次に、１５時２７分から送信が開始され、
１５時２８分で送信が終了するイベントeventMessage3
としては、例えば、次のようなものが構成される。

【０２９３】 eventMessage3{ formatVersion(?), filteringMasks(ディレクトリａ．ａｂを表すビット列「001*****」), timeToLive(?), objectIdentifier(data3の識別子), objectVersion(?), subjectLinks(?), eventLinks eventLinks{ filteringMasks(ディレクトリａ．ａｂを表すビット列「001*****」), eventIdentifier{ avairableTime{ startTime(１８時３４分),endTime(１８時３５分) }, locator{ dvbSpecificLocator(?) } } } } }

【０２９４】１５時２７分乃至１５時２８分の間に送信
されるイベントeventMessage3に配置されたフィルタマ
スクfilteringMasksと同一のフィルタマスクfilteringM
asksが配置されたイベントのうち、イベントeventMessa
ge3の送信後に最も早く送信されるのは、ここでは、１
８時３４分乃至１８時３５分に送信されるイベントeven
tMessage1であり（図１８）、このため、イベントevent
Message3のイベントリンクeventLinksを構成するavaira
bleTimeのstartTimeまたはendTimeには、そのイベントe
ventMessage1の送信開始時刻である１８時３４分、また
は送信終了時刻である１８時３５分が、それぞれ配置さ
れる。

【０２９５】次に、１６時４２分から送信が開始され、
１６時４３分で送信が終了するイベントeventMessage4
としては、例えば、次のようなものが構成される。

【０２９６】 eventMessage4{ formatVersion(?), filteringMasks(ディレクトリｂ．ｂｂを表すビット列「11******」), timeToLive(?), objectIdentifier(data4の識別子), objectVersion(?), subjectLinks(?) }

【０２９７】１６時４２分乃至１６時４３分の間に送信
されるイベントeventMessage4に配置されたフィルタマ
スクfilteringMasksと同一のフィルタマスクfilteringM
asksが配置されたイベントのうち、イベントeventMessa
ge4の送信後に送信されるものは、ここでは存在しない
ため、イベントeventMessage4には、イベントリンクeve
ntLinksは配置されない。

【０２９８】以上のように、あるイベントeventMessage
に配置されたフィルタマスクfilteringMasksと同一のフ
ィルタマスクfilteringMasksが配置された同一カテゴリ
イベントの送信が行われる予定がある場合があるには、
あるイベントeventMessageには、そのイベントeventMes
sageの次に送信される同一カテゴリイベントの送信時刻
が設定されたイベントリンクeventLinksが配置される。
なお、図１８における点線の矢印は、イベントリンクev
entLinksによって送信時刻が表されているイベントを指
している。

【０２９９】次に、図１９は、上述したようなイベント
リンクeventLinksを導入したイベントeventMessageが送
信されてくる場合の、図１の受信端末５の構成例を示し
ている。

【０３００】ブロードキャスト受信装置４１（受信手
段）は、放送ネットワーク４を介して送信されてくるイ
ベントやサブジェクトなどを受信するようになされてお
り、イベントは、フィルタリング処理装置４２に、サブ
ジェクトは、更新情報取得装置４７に、それぞれ供給さ
れるようになされている。

【０３０１】フィルタリング処理装置４２（選択手段）
は、フィルタリングマスク（filteringMask）設定装置
（以下、適宜、設定装置という）４３に設定されている
マスク値に基づいて、ブロードキャスト受信装置４１か
ら供給されるイベントを取捨選択する選択処理を行うよ
うになされている。なお、フィルタリング処理装置４２
は、タイマ装置４６の出力に基づいて、自身が行う選択
処理の制御も行うようになされている。

【０３０２】フィルタリング処理装置４２で選択された
イベントは、イベントメッセージ（eventMessage）デー
タベース（以下、適宜、データベースという）４４に供
給されるようになされており、データベース４４は、フ
ィルタリング処理装置４２からのイベントを、一時記憶
するようになされている。

【０３０３】タイマ設定装置４５は、データベース４４
に記憶されたイベントeventMessageに配置されたイベン
トリンクeventLinksを参照し、タイマ装置４６に計時さ
せるタイマ時間を設定するようになされている。タイマ
装置４６は、タイマ設定装置４５によって設定されたタ
イマ時間を計時し、その計時結果を、フィルタリング装
置４２に供給するようになされている。

【０３０４】更新情報取得装置４７（処理手段）は、デ
ータベース４４に記憶されたイベントを読み出し、その
イベントによって更新が報知されたオブジェクトを更新
するためのサブジェクトを取得するようになされてい
る。即ち、更新情報取得装置４７には、上述したよう
に、ブロードキャスト受信装置４１からサブジェクトが
供給されるようになされており、更新情報取得装置４７
は、データベース４４から読み出したイベントに対応す
るサブジェクトを、ブロードキャスト受信装置４１から
のサブジェクトの中から選択する。また、更新情報取得
装置４７は、双方向通信型データ取得装置４８を制御
し、データベース４４から読み出したイベントに対応す
るサブジェクトを、通信ネットワーク６を介して要求、
受信させることで取得する。そして、更新情報取得装置
４７は、取得したサブジェクトに基づいて、受信側ロー
カルデータベース４９におけるオブジェクトを更新する
ようになされている。

【０３０５】受信側ローカルデータベース４９は、図９
のデータベース２３に相当し、オブジェクトを記憶する
ようになされている。

【０３０６】次に、図２０および図２１のフローチャー
トを参照して、図１９の受信端末５の処理について説明
する。

【０３０７】図２０のフローチャートに示すように、受
信装置５では、まず最初に、ステップＳ９１において、
ユーザの嗜好等に基づいて、マスク値ＦＭが設定され
る。即ち、設定装置４３は、例えば、ユーザが、受信側
ローカルデータベース４９にアクセスしたアクセス履歴
（視聴履歴）を管理しており、そのアクセス履歴に基づ
いて、ユーザが興味を持っているカテゴリを認識し、そ
の認識結果に基づいて、マスク値ＦＭを設定する。設定
装置４３において設定されたマスク値ＦＭは、フィルタ
リング処理装置４２に供給される。

【０３０８】ここで、放送局において、例えば、図１５
に示したようなディレクトリ構造でオブジェクトが管理
されている場合に、設定装置４３において、ユーザが興
味を持っているカテゴリが、例えば、ディレクトリａ．
ａｂに対応するカテゴリであると認識されたときには、
マスク値として、「001xxxxx」が設定される。また、ユ
ーザが興味を持っているカテゴリが、例えば、ディレク
トリｂ．ｂｂまたはａに対応するカテゴリであると認識
されたときには、マスク値ＦＭとして、「11xxxxxx」ま
たは「0xxxxxxx」が、それぞれ設定される。

【０３０９】その後、ブロードキャスト受信装置４１で
イベントが受信されると、そのイベントは、フィルタリ
ング処理装置４２に供給される。フィルタリング処理装
置４２では、ステップＳ４２において、ブロードキャス
ト受信装置４１からのイベントが、設定装置４３からの
マスク値ＦＭに基づいて取捨選択され、データベース４
４に供給されて記憶される。即ち、フィルタリング処理
装置４２は、ブロードキャスト受信装置４１からのイベ
ントに配置されているフィルタマスクfilteringMasks
と、設定装置４３からのマスク値ＦＭとを、有効ビット
について比較し、それらが一致する場合には、ブロード
キャスト受信装置４１からのイベントを、データベース
４４に供給して記憶させ、一致しない場合には破棄す
る。

【０３１０】ここで、上述したような送信スケジュール
で、イベントeventMessage1，eventMessage2，eventMes
sage3，eventMessage4が送信されてくる場合において、
マスク値として、例えば、上述したように「001xxxx
x」、「11xxxxxx」、または「0xxxxxxx」が設定されて
いるときには、フィルタリング処理装置４２では、最初
に、１２時３４分に送信が開始されたeventMessage1、
１３時４２分に送信が開始されたeventMessage2、また
は１２時３４分に送信が開始されたeventMessage1が、
それぞれ選択されることになる。

【０３１１】そして、ステップＳ９３に進み、タイマ設
定装置４５は、データベース４４に記憶されたイベント
を読み出し、そのイベントに、イベントリンクeventLin
ksが配置されているかどうかを判定する。ステップＳ９
３において、イベントに、イベントリンクeventLinksが
配置されていると判定された場合、ステップＳ９４に進
み、タイマ設定装置４５は、現在時刻から、そのイベン
トリンクeventLinksのavairableTimeの中のstartTimeま
での時間をタイマ時間として設定する。そして、タイマ
設定装置４５は、そのタイマ時間を、タイマ装置４６に
供給し、ステップＳ９５に進む。なお、タイマ装置４６
は、タイマ設定装置４５からタイマ時間を受信すると、
その計時を開始する。

【０３１２】一方、ステップＳ９３において、イベント
に、イベントリンクeventLinksが配置されていないと判
定された場合、ステップＳ９４をスキップして、ステッ
プＳ９５に進み、タイマ装置４６に、計時すべきタイマ
時間が設定されている（従って、タイマ装置４６におい
て、そのタイマ時間の計時が行われている）かどうかが
判定され、設定されていないと判定された場合、即ち、
タイマ装置４６がタイマ時間の計時を行っていない場
合、ステップＳ９６に進み、タイマ設定装置４５は、所
定の短い時間をタイマ時間として設定し、タイマ装置４
６に供給して、ステップＳ９７に進む。

【０３１３】また、ステップＳ９５において、タイマ装
置４６に、計時すべきタイマ時間が設定されている（従
って、タイマ装置４６において、そのタイマ時間の計時
が行われている）と判定された場合、即ち、タイマ装置
４６がタイマ時間の計時を行っている場合、ステップＳ
９６をスキップして、ステップＳ９７に進み、タイマ装
置４６が、そのタイマ時間の計時を終了するまで、待ち
時間がおかれる。そして、タイマ装置４６におけるタイ
マ時間の計時が終了すると、ステップＳ９２に戻り、以
下、同様の処理が繰り返される。

【０３１４】即ち、タイマ装置４６は、タイマ時間の計
時を開始するとき、フィルタリング処理装置４２に対し
て、計時を開始する旨の計時開始メッセージを送信し、
フィルタリング処理装置４２は、この計時開始メッセー
ジを受信すると、処理を中断する。そして、タイマ装置
４６は、タイマ時間の計時を終了すると、フィルタリン
グ処理装置４２に対して、計時を終了した旨の計時終了
メッセージを送信し、フィルタリング処理装置４２は、
この計時終了メッセージを受信すると、処理を再開す
る。従って、フィルタリング処理装置４２は、タイマ装
置４６において、タイマ時間の計時が行われている最中
は、処理を中断しており、その結果、その間、ブロード
キャスト受信装置４１から出力されるイベントは、フィ
ルタリング処理装置４２において取捨選択の対象とされ
ず、単に破棄される。

【０３１５】以上のような処理が行われることにより、
例えば、フィルタリング処理装置４２において、最初
に、図１８に示した１２時３４分に送信が開始されたイ
ベントeventMessage1が選択された場合には、その後、
そのイベントeventMessage1に配置されたイベントリン
クeventLinksのavairableTimeの中のstartTimeに設定さ
れた１５時２７分まで、即ち、イベントeventMessage1
が更新を報知するオブジェクトと同一カテゴリの他のオ
ブジェクトの更新を報知するイベントeventMessage3の
送信が開始される１５時２７分まで、フィルタリング処
理装置４２は、動作を停止する（例えば、いわゆるスリ
ープ状態になる）。そして、１５時２７分にあると、フ
ィルタリング処理装置４２は、再び、動作状態となる。

【０３１６】また、例えば、フィルタリング処理装置４
２において、最初に、図１８に示した１３時４２分に送
信が開始されたイベントeventMessage2が選択された場
合には、その後、そのイベントeventMessage2に配置さ
れたイベントリンクeventLinksのavairableTimeの中のs
tartTimeに設定された１６時４２分まで、即ち、イベン
トeventMessage2が更新を報知するオブジェクトと同一
カテゴリの他のオブジェクトの更新を報知するイベント
eventMessage4の送信が開始される１６時４２分まで、
フィルタリング処理装置４２は、動作を停止する。そし
て、１６時４２分にあると、フィルタリング処理装置４
２は、再び、動作状態となる。

【０３１７】従って、フィルタリング処理装置４２で
は、イベントを常時監視せずに済み、その結果、その処
理負担を軽減することができる。

【０３１８】次に、図１９の受信端末５では、データベ
ース４４にイベントが記憶されると、図２１のフローチ
ャートにしたがった処理が必要に応じて行われる。

【０３１９】即ち、更新情報取得装置４７は、ステップ
Ｓ１０１において、データベース４４に記憶されたイベ
ントを読み出し、そのイベントによって更新が報知され
たオブジェクトを更新するためのサブジェクトを取得す
る。即ち、更新情報取得装置４７は、データベース４４
から読み出したイベントに対応するサブジェクトを、ブ
ロードキャスト受信装置４１が受信したサブジェクトの
中から選択する。あるいは、更新情報取得装置４７は、
双方向通信型データ取得装置４８を制御し、データベー
ス４４から読み出したイベントに対応するサブジェクト
を、要求、受信させることで取得する。そして、更新情
報取得装置４７は、ステップＳ１０２において、取得し
たサブジェクトに基づいて、受信側ローカルデータベー
ス４９におけるオブジェクトを更新し、処理を終了す
る。なお、図２１のフローチャートにしたがった処理
は、データベース４４に、まだ処理の対象とされていな
いイベントが記憶されている場合には、そのイベント
を、新たに処理の対象として、再度行われる。

【０３２０】ここで、イベントリンクeventLinksを導入
したイベントeventMessageの符号化を、ＡＳＮ．１準拠
の商用／パブリックドメインソフトウェアのツールＳｎ
ａｃｃを利用して行う場合には、例えば、以下のような
ファイルを、その入力として与えてやればよい。なお、
以下においては、上述の、イベントリンクeventLinksを
導入する前のイベントeventMessageに対して、新たに追
加された部分には、その行末に＊印を付してある。

【０３２１】 EventMessage DEFINITIONS::= BEGIN EventMessage::=SEQUENCE{ formatVersion FormatVersion, filteringMasks FilteringMasks OPTIONAL, timeToLive UTCTime, objectIdentifier ObjectIdentifier, objectVersion INTEGER OPTIONAL, subjectLinks SubjectLinks OPTIONAL, eventLinks EventLinks OPTIONAL ＊ } FormatVersion::=SEQUENCE{ majorVersion INTEGER, minorVersion INTEGER } FilteringMasks::=SEQUENCE OF{ filteringMaskIdentifier INTEGER, filteringMaskField ANY DEFINED BY filteringMaskIdentifiler } ObjectIdentifier::=SEQUENCE{ avairableTime AvairableTime OPTIONAL, locator Locator } AvairableTime::=SEQUENCE{ startTime UTCTime, endTime UTCTime OPTIONAL } Locator::=CHOICE{ netLocator NETLocator dvbSpecificLocator DVBSpecificLocator } NETLocator::=SEQUENCE{ nsapSpecificLocator NSAPSpecificLocator OPTIONAL, universalResourceIdentifier EXTERNAL } NSAPSpecificLocator::=SEQUENCE{ nsapAddress EXTERNAL, additionalInfo ANY OPTIONAL } DVBSpecificLocator::=CHOICE{ dvbPrimitiveLocator DVBPrimitiveLocator, dvbDataCarouselLocator DVBDataCarouselLocator, dvbObjectCarouselLocator DVBObjectCarouselLocator } DVBPrimitiveLocator::=SEQUENCE{ networkID [0] INTEGER OPTIONAL, transportStreamID [1] INTEGER OPTIONAL, packetID [2] INTEGER OPTIONAL, serviceID [3] INTEGER OPTIONAL, tableID [4] INTEGER OPTIONAL, tableIDExtention [5] INTEGER OPTIONAL, sectionNumber [6] INTEGER OPTIONAL, eventID [7] INTEGER OPTIONAL, componentTag [8] INTEGER OPTIONAL } DVBDataCarouselLocator::=SEQUENCE{ dvbPrimitiveLocator DVBPrimitiveLocator, groupID [0] INTEGER OPTIONAL, moduleID [1] INTEGER OPTIONAL } DVBObjectCarouselLocator::=SEQUENCE{ dvbPrimitiveLocator DVBPrimitiveLocator, carouselID [0] INTEGER OPTIONAL, moduleID [1] INTEGER OPTIONAL, objectKey [2] INTEGER OPTIONAL } SubjectLinks::=SEQUENCE OF{ subjectIdentifier ObjectIdentifier, subjectVersion INTEGER OPTIONAL, qosSpecification QOSSpecification OPTIONAL, clientIdentifer ClientIdentifier OPTIONAL } QOSSpecification::=SEQUENCE OF{ qosSpecType INTEGER, qosSpecValue INTEGER } ClientIdentifier::=CHOICE{ clientGroupIdentifier INTEGER, clientIdentifiers SET OF INTEGER } EventLinks::=SET OF EventLink; ＊ EventLink::=SEQUENCE{ ＊ filteringMasks FilteringMasks, ＊ eventIdentifier ObjectIdentifier ＊ } ＊ END

【０３２２】なお、本実施の形態では、イベントのイベ
ントリンクeventLinksに、そのイベントの次に送信され
る同一カテゴリイベントだけの送信時刻を配置するよう
にしたが、イベントリンクeventLinksには、例えば、さ
らに、その次に送信される同一カテゴリイベントの送信
時刻も配置する、即ち、複数の同一カテゴリイベントの
送信時刻を配置するようにすることなども可能である。

【０３２３】

【発明の効果】以上の如く、第１の本発明によれば、受
信側において、報知データを取捨選択する処理負担を軽
減することが可能となる。

【０３２４】また、第２の本発明によれば、選択処理の
処理負担を軽減することが可能となる。

【０３２５】さらに、第３の本発明によれば、受信側に
おける選択処理の処理負担を軽減することが可能とな
る。

【図面の簡単な説明】

【図１】本発明を適用したデータ配信システムの一実施
の形態の構成例を示す図である。

【図２】図１のサーバ２の構成例を示すブロック図であ
る。

【図３】図１のミラーサーバ７の構成例を示すブロック
図である。

【図４】サーバ２が行う登録処理を説明するためのフロ
ーチャートである。

【図５】図１のデータベース１ａ乃至１ｃから供給され
るデータのフォーマットを示す図である。

【図６】サーバ２が行うデータ伝送処理を説明するため
のフローチャートである。

【図７】サブジェクトおよびイベントのフォーマットを
示す図である。

【図８】サーバ２が行う要求データ送信処理を説明する
ためのフローチャートである。

【図９】図１の受信端末５の構成例を示すブロック図で
ある。

【図１０】受信端末５が行う受信処理を説明するための
フローチャートである。

【図１１】受信端末５が行うデータ要求処理を説明する
ためのフローチャートである。

【図１２】受信端末５が行うデータ出力処理を説明する
ためのフローチャートである。

【図１３】サーバ２が行う負荷分散処理を説明するため
のフローチャートである。

【図１４】受信端末５が行うアクセスサーバ決定処理を
説明するためのフローチャートである。

【図１５】ディレクトリに対するビットアサインを示す
図である。

【図１６】図１の放送局の構成例を示すブロック図であ
る。

【図１７】図１６の放送局の処理を説明するためのフロ
ーチャートである。

【図１８】イベントの送信スケジュールを示す図であ
る。

【図１９】図１の受信端末５の他の構成例を示すブロッ
ク図である。

【図２０】図１９の受信端末５の処理を説明するための
フローチャートである。

【図２１】図１９の受信端末５の処理を説明するための
フローチャートである。

【符号の説明】

１ａ乃至１ｃ データベース， ２ サーバ， ３ デ
ータベース， ４ 放送ネットワーク， ５ 受信端
末， ６ 通信ネットワーク， ７ ミラーサーバ，
８ データベース， １１ 通信制御部， １２ 資源
割当部， １３データ検索部， １４ 複製管理部，
１５ 登録部， １７ データ構成部，１８ 伝送部，
２１ 受信部， ２２ 選択部， ２３ データベー
ス，２４ 通信制御部， ２５ 要求部， ２６ 読み
出し部， ２７ 出力部，２８ 操作部， ３１ 送信
側マスタデータベース， ３２ 更新検出装置，３３
イベントメッセージ／フィルタリングマスク生成装置
（構成手段）， ３４ イベントメッセージデータベー
ス， ３５ イベントメッセージスケジューリング装
置， ３６ イベントリンク設定装置（構成手段），
３７ イベントメッセージ放送装置（送信手段）， ４
１ ブロードキャスト受信装置（受信手段）， ４２
フィルタリング処理装置（選択手段）， ４３ フィル
タリングマスク設定装置， ４４ イベントメッセージ
データベース， ４５ タイマ設定装置， ４６ タイ
マ装置， ４７ 更新情報取得装置（処理手段）， ４
８双方向通信型データ取得装置， ４９ 受信側ローカ
ルデータベース

───────────────────────────────────────────────────── フロントページの続き (72)発明者 原岡 和生 東京都品川区北品川６丁目７番35号 ソ ニー株式会社内 (72)発明者 西尾 郁彦 東京都品川区北品川６丁目７番35号 ソ ニー株式会社内 (56)参考文献 特開 平９−81447（ＪＰ，Ａ) 特開 平５−75984（ＪＰ，Ａ) 特開 平11−306069（ＪＰ，Ａ) 特開 平11−306068（ＪＰ，Ａ) 特開 平11−306059（ＪＰ，Ａ) 特開 平11−220493（ＪＰ，Ａ) 特開 平11−219330（ＪＰ，Ａ) 特開 平10−303983（ＪＰ，Ａ) 特開 平10−22950（ＪＰ，Ａ) 特開 平８−37506（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/18 G06F 12/00 545 G06F 13/00 540 H04H 1/00

Claims (7)

(57)【特許請求の範囲】
1. 【請求項１】 コンテンツの提供のためのデータの送信
   を行う送信装置において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データを取捨選択するための基準として
   用いることのできる選択基準情報、およびその選択基準
   情報と同一の選択基準情報が配置される報知データを認
   識するための認識情報を、少なくとも配置したものを構
   成する構成手段と、 前記報知データを送信する送信手段とを備え、 前記報知データに配置された前記認識情報は、その報知
   データが送信された後、そこに配置された選択基準情報
   と同一の選択基準情報が配置された報知データの送信が
   開始される送信時刻を含む ことを特徴とする送信装置。
2. 【請求項２】 前記構成手段は、前記コンテンツの更新
   を行うための更新データが送信される送信帯域をさらに
   配置したものを構成する ことを特徴とする請求項１に記
   載の送信装置。
3. 【請求項３】 コンテンツの提供のためのデータの送信
   を行う送信方法において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データを取捨選択するための基準として
   用いることのできる選択基準情報、およびその選択基準
   情報と同一の選択基準情報が配置される報知データを認
   識するための認識情報を、少なくとも配置したものを構
   成し、 前記報知データを送信し、 前記報知データに配置された前記認識情報は、その報知
   データが送信された後、そこに配置された選択基準情報
   と同一の選択基準情報が配置された報知データの送信が
   開始される送信時刻を含む ことを特徴とする送信方法。
4. 【請求項４】 コンテンツの提供を受けるためのデータ
   の受信を行う受信装置において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データを取捨選択するための基準として
   用いることのできる選択基準情報、およびその選択基準
   情報と同一の選択基準情報が配置される報知データを認
   識するための認識情報を、少なくとも配置したものを受
   信する受信手段と、 前記選択基準情報に基づき、前記報知データを選択する
   選択処理を行うとともに、前記認識情報に基づき、前記
   選択処理を制御する選択手段と、 前記選択処理によって選択された前記報知データに基づ
   いて、コンテンツを更新するための処理を行う処理手段
   とを備え、 前記報知データに配置された認識情報は、その報知デー
   タが送信された後、そこに配置された選択基準情報と同
   一の選択基準情報が配置された報知データの送信が開始
   される送信時刻を含み、 前記選択手段は、所定の報知データを選択した後、その
   報知データに配置された認識情報に含まれる送信開始時
   刻まで、前記選択処理を中断する ことを特徴とする受信
   装置。
5. 【請求項５】 コンテンツの提供を受けるためのデータ
   の受信を行う受信方法において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データを取捨選択するための基準として
   用いることのできる選択基準情報、およびその選択基準
   情報と同一の選択基準情報が配置される報知データを認
   識するための認識情報を、少なくとも配置したものを受
   信し、 前記選択基準情報に基づき、前記報知データを選択する
   選択処理を行うとともに、前記認識情報に基づき、前記
   選択処理を制御し、 前記選択処理によって選択された前記報知データに基づ
   いて、コンテンツを更新するための処理を行い、 前記報知データに配置された認識情報は、その報知デー
   タが送信された後、そこに配置された選択基準情報と同
   一の選択基準情報が配置された報知データの送信が開始
   される送信時刻を含み、 所定の報知データを選択した後、その報知データに配置
   された認識情報に含まれる送信開始時刻まで、前記選択
   処理を中断する ことを特徴とする受信方法。
6. 【請求項６】 コンテンツの提供のためのデータの送信
   を行う送信装置と、 前記送信装置からのデータを受信する受信装置と を備える送受信装置であって、 前記送信装置は、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データを取捨選択するための基準として
   用いることのできる選択基準情報、およびその選択基準
   情報と同一の選択基準情報が配置される報知データを認
   識するための認識情報を、少なくとも配置したものを構
   成する構成手段と、 前記報知データを送信する送信手段と を備え、 前記受信装置は、 前記報知データを受信する受信手段と、 前記選択基準情報に基づき、前記報知データを選択する
   選択処理を行うとともに、前記認識情報に基づき、前記
   選択処理を制御する選択手段と、 前記選択処理によって選択された前記報知データに基づ
   いて、コンテンツを更新するための処理を行う処理手段
   とを備え、 前記報知データに配置された認識情報は、その報知デー
   タが送信された後、そこに配置された選択基準情報と同
   一の選択基準情報が配置された報知データの送信が開始
   される送信時刻を含み、 前記選択手段は、所定の報知データを選択した後、その
   報知データに配置された認識情報に含まれる送信開始時
   刻まで、前記選択処理を中断する ことを特徴とする送受
   信装置。
7. 【請求項７】 コンテンツの提供のためのデータの送信
   を行う送信装置と、 前記送信装置からのデータを受信する受信装置と を備える送受信装置の送受信方法であって、 前記送信装置において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データを取捨選択するための基準として
   用いることのできる選択基準情報、およびその選択基準
   情報と同一の選択基準情報が配置される報知データを認
   識するための認識情報を、少なくとも配置したものを構
   成し、 前記報知データを送信し、 前記受信装置において、 前記報知データを受信し、 前記選択基準情報に基づき、前記報知データを選択する
   選択処理を行うとともに、前記認識情報に基づき、前記
   選択処理を制御し、 前記選択処理によって選択された前記報知データに基づ
   いて、コンテンツを更新するための処理を行い、 前記報知データに配置された認識情報は、その報知デー
   タが送信された後、そこに配置された選択基準情報と同
   一の選択基準情報が配置された報知データの送信が開始
   される送信時刻を含み、 所定の報知データを選択した後、その報知データに配置
   された認識情報に含まれる送信開始時刻まで、前記選択
   処理を中断する ことを特徴とする送受信方法。