JPH11306068A - 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 - Google Patents

Abstract

(57)【要約】 【課題】 受信側の負担の増加を抑えつつ、効率的なデ
ータ配信を行う。 【解決手段】 サーバ２において、データベース３に登
録されたオブジェクトが更新されると、その更新を行う
ためのデータであるサブジェクトと、そのサブジェクト
を取得するためのデータであるイベントとが生成され、
例えば、衛星回線などの放送ネットワーク４を介して送
信される。一方、受信端末５では、イベントが受信さ
れ、そのイベントに基づき、サブジェクトが取得され
る。そして、そのサブジェクトに基づき、オブジェクト
が更新される。この場合において、イベントには、その
イベントのフォーマットを特定するためのフォーマット
情報、そのイベントの有効期限に関する期限情報、およ
びそのイベントによって更新が報知されるオブジェクト
が存在する位置に関する位置情報が、少なくとも含まれ
ている。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】データの配信手法としては、種々の手法
が提案されているが、例えば、現在のインターネット上
においては、ＨＴＴＰ（Hyper Text Transfer Protoco
l）のようなＴＣＰ／ＩＰ（Transmission Control Prot
ocol/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は、例えば、次のよ
うに定義される。

【０１６３】 EventMessage::=SEQUENCE{ formatVersion FormatVersion, filteringMasks FilteringMasks OPTIONAL, timeToLive UTCTime, objectIdentifier ObjectIdentifier, objectVersion INTEGER OPTIONAL, subjectLinks SubjectLinks OPTIONAL }

【０１６４】ここで、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は、例えば、次のように定義される。

【０１６８】 FormatVersion::=SEQUENCE{ majorVersion INTEGER, minorVersion INTEGER }

【０１６９】即ち、フォーマットバージョン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におけるマ
スクフィールドfilteringMaskFieldは、イベントEventM
essageに対応するオブジェクト（イベント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は、例えば、次のように定義される。

【０１９０】 ObjectIdentifier::=SEQUENCE{ avairableTime AvairableTime OPTIONAL, locator Locator }

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

【０１９２】 AvairableTime::=SEQUENCE{ startTime UTCTime, endTime UTCTime OPTIONAL }

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

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

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

【０１９６】 Locator::=CHOICE{ netLocator NETLocator dvbSpecificLocator DVBSpecificLocator }

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

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

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

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

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

【０２０２】 NSAPSpecificLocator::=SEQUENCE{ nsapAddress EXTERNAL, additionalInfo ANY OPTIONAL }

【０２０３】ＮＳＡＰアドレス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）を意味する。
ＵＲＩは、ＷＷＷにおいて提供されるリソースを一意に
識別することができ、ユーザが、インターネットに、直
接接続することができる場合（受信端末５が、インター
ネットに直接接続される場合）に利用される。ここで、
リソース識別子universalResourceIdentifierのシンタ
クスとしては、例えば、RFC1630:Universal Resource I
dentifiers in WWW: A Unifying Syntax for the Expre
ssion of Names and Addresses of Objects on the Net
work as used in the World-Wide Webに定義されている
ものを利用することができる。

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

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

【０２０８】 DVBSpecificLocator::=CHOICE{ dvbPrimitiveLocator DVBPrimitiveLocator, dvbDataCarouselLocator DVBDataCarouselLocator, dvbObjectCarouselLocator DVBObjectCarouselLocator }

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

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

【０２１１】 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 }

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

【０２１３】なお、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は、例えば、次のように定義される。

【０２１５】 DVBDataCarouselLocator::=SEQUENCE{ dvbPrimitiveLocator DVBPrimitiveLocator, groupID [0] INTEGER OPTIONAL, moduleID [1] INTEGER OPTIONAL }

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

【０２１７】 DVBObjectCarouselLocator::=SEQUENCE{ dvbPrimitiveLocator DVBPrimitiveLocator, carouselID [0] INTEGER OPTIONAL, moduleID [1] INTEGER OPTIONAL, objectKey [2] INTEGER OPTIONAL }

【０２１８】なお、データカルーセル、オブジェクトカ
ルーセル、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は、例えば、次のように定義され
る。

【０２２１】 SubjectLinks::=SEQUENCE OF{ subjectIdentifier ObjectIdentifier, subjectVersion INTEGER OPTIONAL, qosSpecification QOSSpecification OPTIONAL, clientIdentifer ClientIdentifier OPTIONAL }

【０２２２】サブジェクト識別子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は、例えば、次のように定義される。

【０２２７】 QOSSpecification::=SEQUENCE OF{ qosSpecType INTEGER, qosSpecValue INTEGER }

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

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

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

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

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

【０２３３】 ClientIdentifier::=CHOICE{ clientGroupIdentifier INTEGER, clientIdentifiers SET OF INTEGER }

【０２３４】グループ識別子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

【０２３９】

【発明の効果】以上の如く、本発明の送信装置および送
信方法によれば、コンテンツの更新を報知するための報
知データであって、その報知データのフォーマットを特
定するためのフォーマット情報、その報知データの有効
期限に関する期限情報、およびその報知データによって
更新が報知されるコンテンツが存在する位置に関する位
置情報を、少なくとも含むものが作成される。従って、
報知データを受信する受信側において、その報知データ
に利用して、コンテンツの更新を効率的に行うことが可
能となる。

【０２４０】本発明の受信装置および受信方法によれ
ば、コンテンツの更新を報知するための報知データであ
って、その報知データのフォーマットを特定するための
フォーマット情報、その報知データの有効期限に関する
期限情報、およびその報知データによって更新が報知さ
れるコンテンツが存在する位置に関する位置情報を、少
なくとも含むものが受信され、その報知データに基づい
て、コンテンツを更新するための処理が行われる。従っ
て、報知データに基づき、コンテンツの更新を、容易か
つ効率的に行うことが可能となる。

【０２４１】本発明の送受信システムおよび送受信方法
によれば、送信装置において、コンテンツの更新を報知
するための報知データであって、その報知データのフォ
ーマットを特定するためのフォーマット情報、その報知
データの有効期限に関する期限情報、およびその報知デ
ータによって更新が報知されるコンテンツが存在する位
置に関する位置情報を、少なくとも含むものが作成さ
れ、受信装置において、報知データが受信され、その報
知データに基づいて、コンテンツを更新するための処理
が行われる。従って、コンテンツの更新を効率的に行う
ことが可能となる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

１ａ乃至１ｃ データベース， ２ サーバ， ３ デ
ータベース， ４ 放送ネットワーク， ５ 受信端
末， ６ 通信ネットワーク， ７ ミラーサーバ，
８ データベース， １１ 通信制御部， １２ 資源
割当部， １３データ検索部， １４ 複製管理部，
１５ 登録部， １７ データ構成部，１８ 伝送部，
２１ 受信部， ２２ 選択部， ２３ データベー
ス，２４ 通信制御部， ２５ 要求部， ２６ 読み
出し部， ２７ 出力部，２８ 操作部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｈ０４Ｌ 12/54 Ｇ０６Ｆ 15/401 ３４０Ａ 12/58 Ｈ０４Ｌ 11/18 Ｈ０４Ｎ 7/173 11/20 １０１Ｂ (72)発明者 西尾 郁彦 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内

Claims (18)

【特許請求の範囲】
1. 【請求項１】 コンテンツの提供のためのデータの送信
   を行う送信装置において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データのフォーマットを特定するための
   フォーマット情報、その報知データの有効期限に関する
   期限情報、およびその報知データによって更新が報知さ
   れる前記コンテンツが存在する位置に関する位置情報
   を、少なくとも含むものを作成する作成手段と、 前記取得データを送信する送信手段とを備えることを特
   徴とする送信装置。
2. 【請求項２】 前記位置情報は、前記コンテンツが存在
   する地理的位置、論理的位置、または時間的位置に関す
   るものであることを特徴とする請求項１に記載の送信装
   置。
3. 【請求項３】 前記報知データは、その報知データを取
   捨選択するための基準として用いることのできる選択基
   準情報をさらに含むことを特徴とする請求項１に記載の
   送信装置。
4. 【請求項４】 前記報知データは、前記コンテンツの更
   新を行うための更新データが存在する位置に関する位置
   情報をさらに含むことを特徴とする請求項１に記載の送
   信装置。
5. 【請求項５】 前記位置情報は、前記更新データが存在
   する地理的位置、論理的位置、または時間的位置に関す
   るものであることを特徴とする請求項４に記載の送信装
   置。
6. 【請求項６】 前記報知データは、前記更新データが複
   数の位置に存在する場合に、その更新データを、前記複
   数の位置のうちのいずれから取得するかを決めるための
   基準として用いることのできる取得決定基準情報をさら
   に含むことを特徴とする請求項４に記載の送信装置。
7. 【請求項７】 前記報知データは、前記更新データの取
   得が許可されているユーザに関するユーザ情報をさらに
   含むことを特徴とする請求項４に記載の送信装置。
8. 【請求項８】 コンテンツの提供のためのデータの送信
   方法において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データのフォーマットを特定するための
   フォーマット情報、その報知データの有効期限に関する
   期限情報、およびその報知データによって更新が報知さ
   れる前記コンテンツが存在する位置に関する位置情報
   を、少なくとも含むものを作成し、 前記取得データを送信することを特徴とする送信方法。
9. 【請求項９】 コンテンツの提供を受けるためのデータ
   の受信を行う受信装置において、 前記コンテンツの更新を報知するための報知データであ
   って、その報知データのフォーマットを特定するための
   フォーマット情報、その報知データの有効期限に関する
   期限情報、およびその報知データによって更新が報知さ
   れる前記コンテンツが存在する位置に関する位置情報
   を、少なくとも含むものを受信する受信手段と、 前記報知データに基づいて、コンテンツを更新するため
   の処理を行う処理手段とを備えることを特徴とする受信
   装置。
10. 【請求項１０】 前記位置情報は、コンテンツが存在す
    る地理的位置、論理的位置、または時間的位置に関する
    ものであることを特徴とする請求項９に記載の受信装
    置。
11. 【請求項１１】 前記報知データは、その報知データを
    取捨選択するための基準として用いることのできる選択
    基準情報をさらに含み、 前記処理手段は、前記選択基準情報に基づき、前記報知
    データを取捨選択する処理も行うことを特徴とする請求
    項９に記載の受信装置。
12. 【請求項１２】 前記報知データは、コンテンツの更新
    を行うための更新データが存在する位置に関する更新デ
    ータ位置情報をさらに含み、 前記処理手段は、前記更新データ位置情報に基づいて、
    前記更新データを取得し、その更新データに基づいて、
    コンテンツを更新することを特徴とする請求項９に記載
    の受信装置。
13. 【請求項１３】 前記位置情報は、前記更新データが存
    在する地理的位置、論理的位置、または時間的位置に関
    するものであることを特徴とする請求項１２に記載の受
    信装置。
14. 【請求項１４】 前記報知データは、前記更新データが
    複数の位置に存在する場合に、その更新データを、前記
    複数の位置のうちのいずれから取得するかを決めるため
    の基準として用いることのできる取得決定基準情報をさ
    らに含み、 前記処理手段は、前記取得決定基準情報に基づいて、前
    記複数の位置のうちのいずれかから、前記更新データを
    取得することを特徴とする請求項１２に記載の受信装
    置。
15. 【請求項１５】 前記報知データは、前記更新データの
    取得が許可されているユーザに関するユーザ情報をさら
    に含み、 前記処理手段は、前記ユーザ情報によって前記更新デー
    タの取得が許可されている場合にのみ、その更新データ
    を取得することを特徴とする請求項１２に記載の受信装
    置。
16. 【請求項１６】 コンテンツの提供を受けるためのデー
    タの受信方法において、 前記コンテンツの更新を報知するための報知データであ
    って、その報知データのフォーマットを特定するための
    フォーマット情報、その報知データの有効期限に関する
    期限情報、およびその報知データによって更新が報知さ
    れる前記コンテンツが存在する位置に関する位置情報
    を、少なくとも含むものを受信し、 前記報知データに基づいて、前記コンテンツを更新する
    ための処理を行うことを特徴とする受信方法。
17. 【請求項１７】 コンテンツの提供のためのデータの送
    信を行う送信装置と、 前記送信装置からのデータを受信する受信装置とを備え
    る送受信システムであって、 前記送信装置は、 前記コンテンツの更新を報知するための報知データであ
    って、その報知データのフォーマットを特定するための
    フォーマット情報、その報知データの有効期限に関する
    期限情報、およびその報知データによって更新が報知さ
    れる前記コンテンツが存在する位置に関する位置情報
    を、少なくとも含むものを作成する作成手段と、 前記取得データを送信する送信手段とを有し、 前記受信装置は、 前記報知データを受信する受信手段と、 前記報知データに基づいて、コンテンツを更新するため
    の処理を行う処理手段とを有することを特徴とする送受
    信システム。
18. 【請求項１８】 コンテンツの提供のためのデータの送
    信を行う送信装置と、 前記送信装置からのデータを受信する受信装置とを備え
    る送受信システムの送受信方法であって、 前記送信装置において、 前記コンテンツの更新を報知するための報知データであ
    って、その報知データのフォーマットを特定するための
    フォーマット情報、その報知データの有効期限に関する
    期限情報、およびその報知データによって更新が報知さ
    れる前記コンテンツが存在する位置に関する位置情報
    を、少なくとも含むものを作成し、 前記取得データを送信し、 前記受信装置において、 前記報知データを受信し、 前記報知データに基づいて、前記コンテンツを更新する
    ための処理を行うことを特徴とする送受信方法。