JP4337150B2 - 受信装置および受信方法 - Google Patents
受信装置および受信方法 Download PDFInfo
- Publication number
- JP4337150B2 JP4337150B2 JP11473098A JP11473098A JP4337150B2 JP 4337150 B2 JP4337150 B2 JP 4337150B2 JP 11473098 A JP11473098 A JP 11473098A JP 11473098 A JP11473098 A JP 11473098A JP 4337150 B2 JP4337150 B2 JP 4337150B2
- Authority
- JP
- Japan
- Prior art keywords
- subject
- content
- data
- event
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、受信装置および受信方法に関し、特に、例えば、分散型データベースにおける多数のデータベースへのデータの配信を行う場合や、ＩＰ（Internet Protocol）マルチキャストによりデータを配信する場合、その他データを不特定多数に配信する場合などに用いて好適な受信装置および受信方法に関する。
【０００２】
【従来の技術】
データの配信手法としては、種々の手法が提案されているが、例えば、現在のインターネット上においては、ＨＴＴＰ（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 and Decoder）やＳＴＢ(Set Top Box)などでなる受信端末５に対して送信される。
【００３３】
即ち、サブジェクトが生成され、その取得のためのイベント（そのサブジェクトと同一の識別子が付加されたイベント）が生成されると、基本的には、まず最初に、イベントが、放送ネットワーク４を介して送信される。さらに、このようにして送信されたイベントの中に、サブジェクトの放送時刻やチャンネルなどが記述されたものがある場合には、その放送時刻に、そのチャンネルで、サブジェクトが、放送ネットワーク４を介して送信される。
【００３４】
ここで、サーバ２においては、例えば、サブジェクトの送信スケジュールがたてられ（放送時刻および放送チャンネルなどが決められ）、その送信スケジュールにしたがって、イベントに、そのサブジェクトの放送時刻や放送チャンネルなどが記述される。そして、そのイベントの送信スケジュールがたてられる。
【００３５】
また、サブジェクトが、例えば、ＵＲＬに対応付けられ、サーバ２やミラーサーバ７の管理下におかれる場合には、そのＵＲＬを含むイベントが生成され、放送ネットワーク４を介して送信される。即ち、サブジェクトがサーバ２またはミラーサーバ７の管理下におかれる場合には、それぞれ、サーバ２またはミラーサーバ７のＩＰアドレスをドメイン名として有するＵＲＬを含むイベントが生成されて送信される。
【００３６】
以上のようにして放送ネットワーク４を介して送信（配信）されてくるイベントは、ユーザの受信端末５で受信される。受信端末５では、受信したイベントのうち、ユーザが所望するオブジェクトについてのものが選択され、その選択されたイベントに基づいて、サブジェクトが取得される。
【００３７】
即ち、例えば、イベントに、サブジェクトの放送時刻やチャンネルが含まれている場合には、サーバ２において、上述したように、その放送時刻に、そのチャンネルで、サブジェクトが、放送ネットワーク４を介して送信されてくるから、受信端末５では、そのようにして送信されてくるサブジェクトが受信される。
【００３８】
また、例えば、イベントに、サブジェクトに対応付けられたＵＲＬが含まれている場合には、受信端末５は、そのＵＲＬのドメイン名に対応するサーバに対して、通信ネットワーク６を介してアクセスし、サブジェクトを要求して受信する。
【００３９】
具体的には、イベントに含まれるＵＲＬのドメイン名に対応するサーバが、例えば、サーバ２であれば、サブジェクトは、サーバ２の管理下におかれているから、受信端末５は、通信ネットワーク６を介して、サーバ２にアクセスし、サブジェクトを取得する。
【００４０】
また、イベントに含まれるＵＲＬのドメイン名に対応するサーバが、例えば、ミラーサーバ７であれば、サブジェクトは、ミラーサーバ７の管理下におかれているから、受信端末５は、通信ネットワーク６を介して、ミラーサーバ７にアクセスし、サブジェクトを取得する。
【００４１】
受信端末５は、以上のようにしてサブジェクトを取得した後、そのサブジェクトに基づいて、自身が記憶しているオブジェクトを更新する。
【００４２】
なお、サブジェクトは、サーバ２から放送ネットワーク４を介して送信されるとともに、サーバ２やミラーサーバ７の管理下にもおかれることがある。さらに、図１の実施の形態では、１のミラーサーバ７だけを図示してあるが、ミラーサーバ７と同様の処理を行うミラーサーバは、通信ネットワーク６上に複数台設けることができ、この場合、サブジェクトは、その複数のミラーサーバの管理下におくこともできる。また、サブジェクトは、サーバ２から放送ネットワーク４を介して、あるチャンネルの、ある時刻においてだけ送信されるのではなく、複数のチャンネルや複数の時刻に送信される場合もある。
【００４３】
このように、あるサブジェクトを取得する方法が複数ある場合には、イベントには、その複数の方法それぞれについての情報（放送時刻や、放送チャンネル、ＵＲＬなど）が含められるが、このうちのいずれの方法によってサブジェクトを取得するかは、受信端末５において決定される。即ち、例えば、イベントに、放送ネットワーク４を介してサブジェクトを送信する時刻が複数含まれている場合には、受信端末５では、例えば、現在時刻に最も近い時刻に放送されてくるサブジェクトが受信されることで、サブジェクトが取得される。また、例えば、イベントに、複数のＵＲＬが含まれている場合には、受信端末５から最も近い位置にあるサーバのものが選択され、そのサーバに対して、通信ネットワーク６を介して、サブジェクトの要求が行われることにより、サブジェクトが取得される。さらに、例えば、イベントに、放送ネットワーク４を介してサブジェクトを送信する時刻と、ＵＲＬとが含まれている場合において、例えば、放送ネットワーク４の回線状態が悪いとき（Ｓ／Ｎ（Signal/Noise）が低いときなど）には、ＵＲＬに基づき、上述したようにして、サブジェクトが取得される。また、その他、いずれの方法によってサブジェクトを取得するかは、受信端末５のユーザの操作などに基づいて決定するようにすることもできる。
【００４４】
以上のようなデータ配信システムによれば、サブジェクトの取得方法が記述されたイベントが、放送ネットワーク４を介して配信され、受信端末５において、そのイベントに基づき、サブジェクトが取得され、オブジェクトの更新が行われるので、受信端末５の負荷の増大を抑えつつ、効率的なデータ配信を行うことができる。
【００４５】
即ち、一般に、オブジェクトの更新（特に、オブジェクトの変更と新規登録）のための更新オブジェクト情報を含むサブジェクトのデータ量は多く、さらに、サブジェクトは、オブジェクトの更新に対応して生成されるため、いつ発生するか分からない。従って、そのような不定期に発生し、かつデータ量の多いサブジェクトだけを、なるべく早期に、放送ネットワーク４を介して送信するとすれば、サーバ２は、現時点において空いているチャンネルを使用して、サブジェクトを送信する必要がある。しかしながら、この場合、受信端末５では、いつ、どのチャンネルで送信されてくるか分からないサブジェクトを待つ必要があり、負担が大になる。
【００４６】
これに対して、イベントは、サブジェクトの取得方法の記述を含むものであるから、一般に、そのデータ量は、更新オブジェクト情報を含むサブジェクトよりも、はるかに少なく、このため、例えば、ある狭帯域のチャンネルの、さらには、決まった時間において送信することが可能である。従って、この場合、受信端末５では、そのチャンネルにおいて（さらには、決まった時間に送信されてくる）イベントを受信すれば良く、その負荷は、サブジェクトの送信を待つ場合に比較して、はるかに小さくなる。
【００４７】
さらに、本実施の形態では、イベントが、広い地域に亘って一斉同報が可能な放送ネットワーク４を介して送信されるため、受信端末５の数の増加が、サーバ２や放送ネットワーク４の負荷に影響を与えることもない。
【００４８】
そして、本実施の形態では、サブジェクトは、通信ネットワーク６を介して提供されるだけでなく、放送ネットワーク４を介しても提供されるので、サブジェクトの取得のために、サーバ２やミラーサーバ７にアクセスが集中することはほとんどなく、従って、サブジェクトの効率的な配信が可能となる。
【００４９】
なお、放送ネットワーク４と通信ネットワーク６とは、物理的に別々のネットワークである必要はない。即ち、放送ネットワーク４を、例えば、ＣＡＴＶ網で構成する場合においては、そのＣＡＴＶ網は通信ネットワーク６として利用することも可能である。また、放送ネットワーク４によるデータの配信を、例えば、インターネットなどを利用したＩＰ（Internet Protocol）マルチキャストで行う場合においては、通信ネットワーク６は、そのインターネットで構成することも可能である。
【００５０】
さらに、サーバ２からの受信端末５へのデータ（イベントおよびサブジェクト）の送信は、例えば、スクランブルをかけて行い、これにより、特定のユーザ（受信契約を結んだユーザ）のみ、データの受信が可能なようにすることも可能である。
【００５１】
次に、図２は、図１のサーバ２の構成例を示している。
【００５２】
通信制御部１１は、例えば、モデムや、ＴＡ（Terminal Adapter）などで構成され、通信ネットワーク６を介しての通信を制御するようになされている。資源割当部１２は、放送ネットワーク４を介してのデータの送信のための資源割当を行うようになされている。即ち、資源割当部１２は、登録部１５からのオブジェクトの更新の知らせを受け、その更新に伴い、イベントおよびサブジェクトを、放送ネットワーク４を介して送信するための資源の割当（例えば、イベントおよびオブジェクトの送信チャンネルや、送信時刻（時間）、データレート、送信回数（送信頻度）などの決定）を行うようになされている。資源割当部１２によるイベントおよびサブジェクトの送信のための資源の割当結果は、データ構成部１７および伝送部１８に供給されるようになされている。
【００５３】
データ検索部１３は、通信ネットワーク６を介して受信端末５から送信されているサブジェクトの要求を、通信制御部１１から受信し、そのサブジェクトを構成する更新オブジェクト情報を、データベース３から検索する。そして、データ検索部１３は、後述するデータ構成部１７と同様にして、サブジェクトを構成し、通信制御部１１に供給するようになされている。複製管理部１４は、ミラーサーバ７（さらには、通信ネットワーク６上の、図示せぬミラーサーバ）を特定するための情報を管理している。即ち、複製管理部１４は、例えば、通信ネットワーク４がインターネットである場合には、ミラーサーバ７のＩＰアドレスを記憶している。そして、複製管理部１４は、登録部１５からのオブジェクトの更新の知らせを受けると、その更新のための更新オブジェクト情報を、データベース３から読み出し、通信制御部１１を制御することで、その更新オブジェクト情報を、例えば、ミラーサーバ７その他の自身が管理しているＩＰアドレスの、通信ネットワーク６上のサーバに送信するようになされている。なお、複製管理部１４は、自身が管理している情報を、必要に応じて、データ構成部１７に供給するようにもなされている。
【００５４】
登録部１５は、情報提供者Ａ乃至Ｃのデータベース１ａ乃至１ｃから供給される更新オブジェクト情報を受信し、その更新オブジェクト情報に基づいて、オブジェクト（データベース３）を更新するようになされている。即ち、情報提供者Ａ乃至Ｃのデータベース１ａ乃至１ｃからは、更新オブジェクト情報とともに、その更新オブジェクト情報によって更新されるオブジェクトの識別子も供給されるようになされている。登録部１５は、この更新オブジェクト情報および識別子を受信し、その識別子に対応するオブジェクトを、データベース３から検索する。さらに、登録部１５は、そのようにして検索したオブジェクトを、更新オブジェクト情報に基づいて更新し、その後、オブジェクトを更新した旨を、資源割当部１２、複製管理部１４、およびデータ構成部１７に出力する。なお、登録部１５は、データベース１ａ乃至１ｃからの更新オブジェクト情報および識別子も、データベース３に登録するようになされている。
【００５５】
データ構成部１７は、登録部１５からオブジェクトを更新した旨を受信すると、その更新がなされたオブジェクトについての更新オブジェクト情報を、データベース３から読み出し、その更新オブジェクト情報が配置されたサブジェクトを生成して、伝送部１８に出力するようになされている。さらに、データ構成部１７は、そのサブジェクトを取得するためのイベントも生成し、伝送部１８に出力するようになされている。なお、データ構成部１７において、イベントの生成は、資源割当部１２による資源の割当結果や、複製管理部１４から供給される情報を用いて行われるようになされている。即ち、データ構成部１７は、サブジェクトが送信されるチャンネルや時刻、データレート、さらには、それを管理するサーバに関する情報その他を、資源割当部１２による資源の割当結果や、複製管理部１４からの情報から認識し、イベントに含めるようになされている。
【００５６】
伝送部１８は、データ構成部１７からのイベントやサブジェクトを、資源割当部１２の資源の割当結果にしたがって、即ち、例えば、所定のチャンネルで、所定の時刻に、所定のデータレートなどで、放送ネットワーク４を介して送信するようになされている。
【００５７】
次に、図３は、図１のミラーサーバ７の構成例を示している。なお、図中、図２のサーバ２における場合と対応する部分については、同一の符号を付してある。即ち、ミラーサーバ７は、資源割当部１２、複製管理部１４、データ構成部１７、および伝送部１８が設けられていない他は、基本的に、サーバ２と同様に構成されている。なお、ミラーサーバ７を構成する登録部１５には、サーバ２を構成する複製管理部１４が、通信制御部１１を制御することにより、通信ネットワーク６などを介して送信されてくる更新オブジェクト情報が供給されるようになされている。
【００５８】
以上のように構成されるサーバ２では、データベース３にデータを登録（データベースの登録内容を更新）する登録処理、サブジェクトおよびイベントを生成し、放送ネットワーク４を介して伝送するデータ伝送処理、および受信端末５から通信ネットワーク６を介してサブジェクトの要求があった場合に、そのサブジェクトを通信ネットワーク６を介して送信する要求データ送信処理などが行われ、また、ミラーサーバ７では、登録処理および要求データ送信処理などが行われるようになされている。
【００５９】
まず、図４のフローチャートを参照して、サーバ２が行う登録処理について説明する。
【００６０】
登録処理では、まず最初に、ステップＳ１において、情報提供者Ａ乃至Ｃのデータベース１ａ乃至１ｃのうちのいずれかから更新オブジェクト情報と識別子が配信されてきたか否かが、登録部１５によって判定され、配信されてきていないと判定された場合、ステップＳ１に戻る。また、ステップＳ１において、更新オブジェクト情報および識別子が配信されてきたと判定された場合、ステップＳ２に進み、登録部１５は、例えば、その更新オブジェクト情報に、その識別子を付加し、データベース３に登録する。
【００６１】
ここで、データベース１ａ乃至１ｃからは、更新オブジェクト情報と識別子とが、例えば、図５に示すようなフォーマットで供給されるようになされている。
【００６２】
識別子は、ここでは、例えば、交通情報や、天気情報、株価情報、さらには、それらの情報を構成する構成要素などのオブジェクトの種類ごとにあらかじめ割り当てられているユニークなＩＤ（Identifier）、およびオブジェクトの新しさを示すバージョン情報などからなる。バージョン情報は、例えば、オブジェクトが更新されるごとに１ずつインクリメントされる整数値などが用いられるようになされており、従って、同一のＩＤが付加されているオブジェクトについては、そのバージョン情報を比較することで、最新のオブジェクトを認識することができる。
【００６３】
なお、ＩＤおよびバージョン情報は、ここでは、例えば、ともに固定長とされている。
【００６４】
登録部１５は、データベース１ａ乃至１ｃから配信されてきた更新オブジェクト情報に、同じくデータベース１ａ乃至１ｃから配信されてきた識別子を付加する（対応付ける）と、さらに、ステップＳ２において、その識別子を構成するＩＤと同一のＩＤを有する識別子が付加されているオブジェクトを、データベース３から検索し、更新オブジェクト情報に基づいて更新する。そして、登録部１５は、その更新したオブジェクトに付加されている識別子のバージョン情報を、例えば、１だけインクリメントする。
【００６５】
その後、登録部１５は、ステップＳ３において、オブジェクトが更新された旨を、資源割当部１２、複製管理部１４、およびデータ構成部１７に出力し、ステップＳ１に戻る。
【００６６】
以上のようにして供給されるオブジェクトが更新された旨を受信した複製管理部１４では、ステップＳ２でデータベース３に登録された更新オブジェクト情報およびそれに付加されている識別子が読み出され、自身が管理しているサーバ、即ち、ここでは、例えば、ミラーサーバ７に対し、通信ネットワーク６を介して送信される。また、複製管理部１４は、更新オブジェクト情報および識別子を送信したサーバを特定するための特定情報、即ち、ここでは、例えば、ミラーサーバ７のＩＰアドレスを、データ構成部１７に出力する。
【００６７】
なお、ミラーサーバ７では、図３のステップＳ１乃至Ｓ３のうちのステップＳ３を除いた処理が、登録処理として行われる。即ち、ミラーサーバ７では、ステップＳ１において、サーバ２から更新オブジェクト情報と識別子が配信されてきたか否かが、登録部１５によって判定され、配信されてきていないと判定された場合、ステップＳ１に戻る。また、ステップＳ１において、更新オブジェクト情報および識別子が配信されてきたと判定された場合、ステップＳ２に進み、ミラーサーバ７の登録部１５は、更新オブジェクト情報に、識別子を付加し、データベース８に登録する。さらに、ミラーサーバ７の登録部１５は、ステップＳ２において、サーバ２から受信した識別子を構成するＩＤと同一のＩＤを有する識別子が付加されているオブジェクトを、データベース８から検索し、そのオブジェクトを、サーバ２から受信した更新オブジェクト情報に基づいて更新する。そして、ミラーサーバ７の登録部１５は、その更新したオブジェクトに付加されている識別子のバージョン情報を、１だけインクリメントし、ステップＳ３をスキップして、ステップＳ１に戻る。
【００６８】
サーバ２において、上述したような登録処理が行われることにより、そのステップＳ３において登録部１５が出力するオブジェクトが更新された旨は、複製管理部１４に供給される他、資源割当部１２およびデータ構成部１７にも供給される。
【００６９】
資源割当部１２は、オブジェクトが更新された旨を受信すると、その更新に関するイベントおよびサブジェクトを、放送ネットワーク４を介して送信するための資源の割当を行い、その割当結果を、データ構成部１７および伝送部１８に出力する。データ構成部１７は、オブジェクトが更新された旨を受信すると、その更新がなされたオブジェクトについての更新オブジェクト情報を、データベース３から読み出し、サブジェクトを生成して、伝送部１８に出力する。さらに、データ構成部１７は、そのサブジェクトを取得するためのイベントを、資源割当部１２の資源割当結果や、複製管理部１４からの情報（例えば、上述したように、ミラーサーバ７のＩＰアドレス）を用いて生成し、伝送部１８に出力する。そして、伝送部１８では、データ構成部１７からのイベントやサブジェクトが、資源割当部１２の資源の割当結果にしたがって、放送ネットワーク４を介して送信される。即ち、資源割当部１２、データ構成部１７、および伝送部１８では、図６に示すようなデータ伝送処理が行われる。
【００７０】
即ち、データ伝送処理では、まず最初に、ステップＳ１１において、資源割当処理が行われる。具体的には、ステップＳ１１では、資源割当部１２において、オブジェクトが更新された旨を受信すると、その更新に関するイベントおよびオブジェクトを、放送ネットワーク４を介して送信するための放送チャンネルや、放送時刻、データレート、送信回数などを決定する。これらの資源割当結果は、データ構成部１７および伝送部１８に供給される。
【００７１】
そして、ステップＳ１２において、データ構成部１７は、イベントおよびサブジェクトを生成する。即ち、データ構成部１７は、データベース３から、オブジェクトの更新に用いられた更新オブジェクト情報と、それに付加されている識別子とを読み出し、例えば、図７（Ａ）に示すようなサブジェクトを構成する。なお、図７（Ａ）においては（同図（Ｂ）においても同様）、バージョン情報の直後に、判別フラグが配置されているが、この判別フラグは、データがサブジェクトか、またはイベントであるかを表す。
【００７２】
また、データ構成部１７は、サブジェクトについて、そのサブジェクトに付加されている識別子と同一の識別子を付加した、例えば、図７（Ｂ）に示すようなイベントを構成する。即ち、イベントは、サブジェクトに付加されている識別子と同一の識別子に、判別フラグ、放送スケジュール情報、およびサーバアクセス情報を順次配置して構成される。
【００７３】
放送スケジュール情報は、サブジェクトが、放送ネットワーク４を介して放送される場合に、それを受信するのに必要な情報で、これには、資源割当部１２からの資源割当結果であるサブジェクトの放送チャンネル、放送時刻（時間）、データレート、送信回数などが含まれる。従って、イベントを構成する放送スケジュール情報を参照することで、そのイベントを構成する識別子のオブジェクトを更新するためのサブジェクトの放送チャンネルや放送時刻などを認識することができ、これにより、そのサブジェクトを受信することが可能となる。
【００７４】
サーバアクセス情報は、サブジェクトが、サーバ２やミラーサーバ７から通信ネットワーク６を介して送信される場合に、通信ネットワーク６を介して、そのサブジェクトを要求するのに必要な情報で、これには、例えば、サーバ２やミラーサーバ７のＩＰアドレスなどが含まれる。そして、このＩＰアドレスなどは、サーバ２やミラーサーバ７を特定するための特定情報として、複製管理部１４からデータ構成部１７に供給されるようになされている。
【００７５】
即ち、サーバ２やミラーサーバ７は、データベース３や８に記憶された更新オブジェクト情報およびそれに付加されている識別子とから、図７（Ａ）に示したサブジェクトを構成し、受信端末５からの要求に対応して、そのサブジェクトを、通信ネットワーク６を介して送信するようになされており、このようにして、サブジェクトを取得する場合に、サーバアクセス情報が参照される。
【００７６】
ここで、サーバ２やミラーサーバ７においては、更新オブジェクト情報およびそれに付加されている識別子から構成されるサブジェクトに、例えば、その識別子をＩＰアドレスに付加して構成されるＵＲＬを対応付けて、サブジェクトの管理が行われるようになされている。この場合、イベントを受信した受信端末５では、そのイベントを構成するサーバアクセス情報と識別子とから、そのイベントと同一の識別子が付加されているサブジェクトのＵＲＬを認識することができる。
【００７７】
なお、サブジェクトは、放送ネットワーク４を介してのみ提供することが可能であるが、この場合には、そのサブジェクトについてのイベントには、サーバアクセス情報は配置されない。逆に、サブジェクトは、通信ネットワーク６を介してのみ提供することも可能であるが、この場合には、そのサブジェクトについてのイベントには、放送スケジュール情報は配置されない。
【００７８】
また、サブジェクトが、放送ネットワーク４を介して、複数のチャンネルや、複数の時刻に送信される場合には、そのサブジェクトについてのイベントには、その複数のチャンネルや複数の時刻それぞれに対応する放送スケジュール情報が配置される。同様に、サブジェクトが、通信ネットワーク６を介して、複数のサーバから提供され得る場合には、そのサブジェクトについてのイベントには、その複数のサーバそれぞれに対応するサーバアクセス情報が配置される。
【００７９】
なお、放送スケジュール情報とサーバアクセス情報の両方が存在する場合や、放送スケジュール情報またはサーバアクセス情報が複数存在する場合には、それらのすべてを、１のイベントに含めるのではなく、それらの１つごとに、イベントを生成しても良い。
【００８０】
図６に戻り、ステップＳ１２において、以上のようなイベントおよびサブジェクトが生成されると、そのイベントやサブジェクトは、データ構成部１７から伝送部１８に供給される。伝送部１８では、ステップＳ１３において、データ構成部１７からのイベントやサブジェクトが、資源割当部１２からの資源割当結果にしたがって、放送ネットワーク４を介して送信される。即ち、イベントやサブジェクトは、例えば、所定の送信チャンネルで、所定の送信時刻に、所定のデータレートで、放送ネットワーク４を介して送信され、ステップＳ１４に進む。
【００８１】
ステップＳ１４では、データ構成部１７からのイベントやサブジェクトの送信を、資源割当部１２からの資源割当結果に含まれる送信回数だけ繰り返し行ったかどうかが、伝送部１８によって判定され、行っていないと判定された場合、ステップＳ１３に戻り、イベントやサブジェクトの伝送が繰り返される。即ち、放送ネットワーク４によるデータの送信は、サーバ２から受信端末５の一方向にのみ行われるため、それらの間で、データの送受信が正確に行われたかどうかの確認を行うことができない。そこで、サーバ２では、データの送信が、資源割当部１２による資源の割当結果である送信回数だけ繰り返されるようになされており、これにより、受信端末５において、正確なデータの受信が行われる確率を向上させるようになされている。
【００８２】
一方、ステップＳ１４において、データ構成部１７からのイベントやサブジェクトの送信を、資源割当部１２からの資源割当結果に含まれる送信回数だけ繰り返し行ったと判定された場合、データ伝送処理を終了する。
【００８３】
なお、上述したように、一般に、イベントはデータ量が少なく、サブジェクトはデータ量が多いから、資源割当部１２では、送信回数は、基本的に、イベントについては多くなり、サブジェクトについては少なくなるように、資源割当が行われる。従って、受信端末５において、放送ネットワーク４を介して送信されてくるイベントを取りこぼす確率（受信できない確率）は小さくなり、さらに、イベントを正常受信することができれば、例えば、それに含まれる放送スケジュール情報を参照することで、サブジェクトが、放送ネットワーク４を介して送信されてくるチャンネルや時刻などを認識することができ、その結果、送信回数の少ないイベントを取りこぼす確率も小さくすることができる。また、仮に、イベントに基づいて、放送チャンネルや放送時刻などを認識したサブジェクトの受信に失敗した場合であっても、あるいは、放送時刻より先に、サブジェクトを必要とする場合などであっても、イベントに、サーバアクセス情報が含まれていれば、そのサーバアクセス情報に基づき、通信ネットワーク６を介して、サーバ２やミラーサーバ７にアクセスすることで、サブジェクトを、早期、かつ確実に取得することができる。
【００８４】
次に、図８のフローチャートを参照して、サーバ２やミラーサーバ７で行われる要求データ送信処理について説明する。
【００８５】
この場合、ステップＳ２１において、受信端末５から通信ネットワーク６を介して、サブジェクトの要求としての、例えば、ＵＲＬが送信されてきたかどうかが、通信制御部１１によって判定され、送信されてきていないと判定された場合、ステップＳ２１に戻る。また、ステップＳ２１において、ＵＲＬが送信されてきたと判定された場合、通信制御部１１は、そのＵＲＬを、データ検索部１３に転送する。データ検索部１３は、ＵＲＬを受信すると、ステップＳ２２において、そのＵＲＬを構成するデータ識別子と同一の識別子が付加されている更新オブジェクト情報を検索する（サーバ２では、データベース２から検索し、ミラーサーバ７では、データベース８から検索する）。
【００８６】
即ち、本実施の形態では、上述したように、イベントを受信した受信端末５において、そのイベントを構成するサーバアクセス情報としてのＩＰアドレスと、識別子とから、そのイベントと同一の識別子が付加されているサブジェクトのＵＲＬが認識されるようになされている。そして、受信端末５は、通信ネットワーク６を介して、サブジェクトを要求する場合には、そのＵＲＬを送信するようになされている。従って、受信端末５からのＵＲＬには、識別子が含まれており、サーバ２やミラーサーバ７では、この識別子を、いわば、更新オブジェクト情報のファイル名として、その検索が行われる。
【００８７】
ステップＳ２２において、更新オブジェクト情報が検索されると、データ検索部１３は、その更新オブジェクトに、それとともに記憶されていた識別子を付加することにより、サブジェクトを構成し、通信制御部１１に供給する。通信制御部１１は、データ検索部１３からのサブジェクトを受信し、ステップＳ２３において、それを、ＵＲＬを送信してきた受信端末（ここでは、受信端末５）に、通信ネットワーク６を介して送信して、ステップＳ２１に戻る。
【００８８】
次に、図９は、図１の受信端末５の構成例を示している。
【００８９】
受信部２１は、サーバ２から放送ネットワーク４を介して送信されてくるデータ、即ち、ここでは、イベントやサブジェクトを受信し、選択部２２に出力するようになされている。選択部２２は、受信部２１からのイベントやサブジェクトの選択を行うようになされている。さらに、選択部２２は、選択したイベントをデータベース２３に一時記憶させるようにもなされている。また、選択部２２は、選択したサブジェクトに含まれる識別子と同一の識別子が付加されているオブジェクトを、データベース２３から検索し、そのサブジェクトに含まれる更新オブジェクト情報に基づいて更新するようにもなされている。
【００９０】
データベース２３は、例えば、大容量のハードディスクや光磁気ディスク、その他の記録媒体で構成され、オブジェクトを記憶し、また、選択部２２からのイベントを一時記憶するようになされている。
【００９１】
通信制御部２４は、通信ネットワーク６を介しての通信制御を行うようになされており、これにより、要求部２５からのサブジェクトの要求を、通信ネットワーク６を介してサーバ２やミラーサーバ７などに送信したり、また、サーバ２やミラーサーバ７などから通信ネットワーク６を介して送信されてくるサブジェクトを受信するようになされている。
【００９２】
要求部２５は、データベース２３に記憶されているイベントに含まれる放送スケジュール情報にしたがって、放送ネットワーク４を介して送信されてくるサブジェクトを受信するように、受信部２１を制御するようになされている。また、要求部２５は、データベース２３に記憶されたイベントに含まれるサーバアクセス情報にしたがい、通信ネットワーク６を介して、サーバ２やミラーサーバ７に、サブジェクトを要求し、その要求に対応して、サーバ２やミラーサーバ７から、通信ネットワーク６を介して送信されてくるサブジェクトを受信するように、通信制御部２４を制御するようにもなされている。さらに、要求部２５は、通信制御部２４に受信させたサブジェクトに含まれる識別子に対応するオブジェクトを、データベース２３から検索し、そのサブジェクトに含まれる更新オブジェクト情報に基づいて更新するようにもなされている。なお、要求部２５は、以上のような処理を、例えば、定期的に行う他、読み出し部２６から、オブジェクトの更新の要求があった場合などにも行うようになされている。
【００９３】
読み出し部２６は、操作部２８の操作に対応して、データベース２３に記憶されたオブジェクトを読み出し、出力部２７に供給するようになされている。出力部２７は、例えば、ディスプレイやスピーカなどで構成され、読み出し部２６などからのオブジェクトを表示し、または音声として出力するようになされている。操作部２８は、読み出し部２６に対して、所定の入力を与える場合などに操作される。
【００９４】
以上のように構成される受信端末５では、サーバ２から放送ネットワーク４を介して送信されてくるデータを受信する受信処理、データベース２３に記憶されたイベントに基づいて、サブジェクトを要求するデータ要求処理、およびデータベース２３に登録されたデータを出力する出力処理などが行われるようになされている。
【００９５】
まず、図１０のフローチャートを参照して、受信処理について説明する。
【００９６】
サーバ２から放送ネットワーク４を介してデータが送信されてくると、受信部２１では、ステップＳ３１において、そのデータ、即ち、イベントまたはサブジェクトが受信され、選択部２２に供給される。選択部２２では、ステップＳ３２において、受信部２１からのイベントまたはサブジェクトが選択すべきものであるかどうかが判定される。
【００９７】
即ち、サーバ２から放送ネットワーク４を介して送信されてくるすべてのイベントやサブジェクトを受信するとした場合には、データベース２３として、記憶容量の膨大なものが必要となる。また、ユーザには好みがあり、各ユーザが、サーバ２のデータベース３に記憶されたオブジェクトすべてを必要としていることはほとんどない。それにもかかわらず、サーバ２のデータベース３の登録内容すべてを、データベース２３に反映するのは好ましくない。
【００９８】
そこで、選択部２２に、例えば、ユーザが所望するオブジェクトについてのＩＤ（上述した識別子を構成するＩＤ）を登録しておくと、選択部２２は、そのＩＤと同一のＩＤを有するイベントおよびオブジェクトだけを選択するようになされている。従って、ステップＳ３２における判定は、ユーザが登録したＩＤと、受信部２１から供給されるイベントやサブジェクトの識別子を構成するＩＤとを比較することで行われる。
【００９９】
ステップＳ３２において、受信部２１からのイベントまたはサブジェクトが選択すべきものでないと判定された場合、即ち、例えば、ユーザが登録したＩＤと、受信部２１から供給されたイベントまたはサブジェクトに記述されているＩＤとが一致しない場合、次のイベントまたはサブジェクトが、放送ネットワーク４を介して送信されてくるのを待って、ステップＳ３１に戻る。従って、この場合、イベントはデータベース２３に記憶されず、また、サブジェクトに基づくデータベース２３の更新も行われない。
【０１００】
一方、ステップＳ３２において、受信部２１からのイベントまたはサブジェクトが選択すべきものであると判定された場合、即ち、例えば、ユーザが登録したＩＤと、受信部２１から供給されたイベントまたはサブジェクトに記述されているＩＤとが一致する場合、ステップＳ３３に進み、選択部２２は、そのイベントまたはサブジェクトが、新規のオブジェクトに関するものかどうかを判定する。
【０１０１】
ステップＳ３３において、ステップＳ３２で選択されたイベントまたはサブジェクトが、新規のオブジェクトに関するものであると判定された場合、即ち、そのイベントまたはサブジェクトに含まれているＩＤと同一のＩＤのオブジェクトが、データベース２３に登録されていない場合、ステップＳ３４をスキップして、ステップＳ３５に進む。
【０１０２】
また、ステップＳ３３において、ステップＳ３２で選択されたイベントまたはサブジェクトが、新規のオブジェクトに関するものでないと判定された場合、即ち、そのイベントまたはサブジェクトに含まれているＩＤと同一のＩＤのオブジェクトが、データベース２３に登録されている場合、ステップＳ３４に進み、選択部２２において、その既にデータベース２３に登録されているオブジェクト（以下、適宜、既登録オブジェクトという）の識別子に記述されているバージョン情報が、ステップＳ３２で選択されたイベントまたはサブジェクトの識別子に記述されているバージョン情報と等しいかどうかが判定される。
【０１０３】
ステップＳ３４において、既登録オブジェクトに記述されているバージョン情報が、ステップＳ３２で選択されたイベントまたはサブジェクトに記述されているバージョン情報と等しい場合、即ち、ここでは、図６のデータ伝送処理で説明したように、信頼性を向上させるため、サーバ２からは、同一のサブジェクトが放送ネットワーク４を介して繰り返し送信されるが、そのように繰り返し行われる送信のうちの、過去に行われた送信によるサブジェクトによって、既登録オブジェクトの更新が、既に行われている場合、ステップＳ３５乃至Ｓ３７をスキップし、次に、イベントまたはサブジェクトが送信されてくるのを待って、ステップＳ３１に戻る。従って、この場合、イベントは、データベース２３に記憶されず、また、サブジェクトに基づくデータベース２３の更新も行われない。
【０１０４】
一方、ステップＳ３４において、既登録オブジェクトに記述されているバージョン情報が、ステップＳ３２で選択されたイベントまたはサブジェクトに記述されているバージョン情報と等しくないと判定された場合、即ち、イベントまたはサブジェクトが、新たなバージョンのオブジェクトに関するものである場合、ステップＳ３５に進み、選択部２２において、ステップＳ３２で選択されたデータが、イベントまたはサブジェクトのうちのいずれであるかが、判別フラグを参照することで判定される。
【０１０５】
ステップＳ３５において、ステップＳ３２で選択されたデータがサブジェクトであると判定された場合、ステップＳ３６に進み、選択部２２は、そのサブジェクトに基づき、データベース２３を更新する。
【０１０６】
即ち、サブジェクトにおいて、更新オブジェクト情報として、新規のオブジェクトが配置されている場合には、サブジェクトに含まれる識別子に、その新規のオブジェクトが対応付けられ、データベース２３に新規登録される。
【０１０７】
また、サブジェクトにおいて、更新オブジェクト情報として、更新後のオブジェクトが配置されている場合には、サブジェクトに含まれるＩＤと同一のＩＤを有する識別子が対応付けられたオブジェクトが、データベース２３から検索され、その検索されたオブジェクトが、更新後のオブジェクトに変更される。さらに、そのオブジェクトに対応付けられていたバージョン情報が、例えば、１だけインクリメントされる。
【０１０８】
さらに、サブジェクトにおいて、更新オブジェクト情報として、オブジェクトの削除指令が配置されている場合には、サブジェクトに含まれるＩＤと同一のＩＤを有する識別子が対応付けられたオブジェクトが、データベース２３から検索され、そのオブジェクトに対応付けられている識別子とともに削除される。
【０１０９】
なお、上述の図４で説明した登録処理のステップＳ２において行われる、更新オブジェクト情報に基づくオブジェクトの更新も、これと同様にして行われる。
【０１１０】
ステップＳ３６において、以上のようにして、データベース２３の更新が行われた後は、次に、イベントまたはサブジェクトが送信されてくるのを待って、ステップＳ３１に戻る。
【０１１１】
一方、ステップＳ３５において、ステップＳ３２で選択されたデータがイベントであると判定された場合、ステップＳ３７に進み、選択部２２は、そのイベントを、データベース２３に供給して一時記憶させる。そして、次に、イベントまたはサブジェクトが送信されてくるのを待って、ステップＳ３１に戻る。
【０１１２】
なお、ステップＳ３７において、データベース２３に記憶されたイベントは、後述するデータ要求処理（図１１）や、データ出力処理（図１２）において、要求部２５によって、データベース２３から読み出された後に消去されるようになされている。
【０１１３】
次に、図１１を参照して、データ要求処理について説明する。なお、このデータ要求処理は、受信端末５において定期的に行われる。但し、データ要求処理は、不定期に行うことも可能である。
【０１１４】
データ要求処理では、まず最初に、ステップＳ４１において、データベース２３の登録内容が、要求部２５によって検索され、ステップＳ４２に進み、データベース２３に、イベントが記憶されているかどうかが判定される。ステップＳ４２において、イベントが記憶されていないと判定された場合、データ要求処理を終了する。
【０１１５】
また、ステップＳ４２において、データベース２３にイベントが記憶されていると判定された場合、そのイベントが読み出され（複数のイベントが記憶されている場合には、そのうちの１つが読み出され）、ステップ４３に進み、要求部２５において、そのイベントに基づくサブジェクトの受信を、同報可能な放送ネットワーク４または双方向通信が可能な通信ネットワーク６のうちのいずれを介して行うのが有利かが判定される。
【０１１６】
ここで、ステップＳ４３の判定は、例えば、次のようにして行われる。
【０１１７】
即ち、要求部２５では、イベントに含まれる放送スケジュール情報を参照することにより、そのイベントに付加されている識別子と同一の識別子のサブジェクトが送信されてくる送信回数（送信頻度）や、送信時刻が認識される。そして、例えば、送信回数が多い場合や、送信時刻が、現在時刻に近い場合には、サブジェクトの受信時間その他の受信のためのコストが低いと予想される放送ネットワーク４を介して、サブジェクトの受信を行うのが有利であると判定される。
【０１１８】
また、例えば、送信回数が少ない場合や、送信時刻が、現在時刻から離れている場合には、双方向ネットワーク６を介して、サブジェクトの受信を行うのが有利であると判定される。
【０１１９】
なお、その他、例えば、イベントに含まれる放送スケジュール情報に、サブジェクトのデータ量が記述されている場合には（データ量そのものが記述されていなくても、データレートと、送信に要する時間とが記述されていれば、データ量を認識することができる）、そのデータ量に基づき、放送ネットワーク４または通信ネットワーク６のうちのいずれを介して、サブジェクトの受信を行うのが有利であるのかを判定することも可能である。
【０１２０】
さらに、放送ネットワーク４または通信ネットワーク６のうちのいずれを介して、サブジェクトの受信を行うのが有利であるのかは、ユーザに操作部２８を操作してもらい、その操作に対応して決定することも可能である。
【０１２１】
また、双方向ネットワーク６を介してサブジェクトを受信する場合において、双方向ネットワーク６が、複数の伝送レートに対応しており、受信端末５が、そのような複数の伝送レートの回線を介しての通信の可能なものであるときには、サブジェクトのデータ量によって、使用する回線を変えるようにすることも可能である。
【０１２２】
ここで、上述したように、イベントには、放送スケジュール情報またはサーバアクセス情報のうちのいずれか一方しか含まれていない場合がある。イベントに、放送スケジュール情報しか含まれていない場合、ステップＳ４３では、放送ネットワーク４を介して、サブジェクトの受信を行うのが有利であると判定される。また、逆に、イベントに、サーバアクセス情報しか含まれていない場合は、ステップＳ４３では、通信ネットワーク６を介して、サブジェクトの受信を行うのが有利であると判定される。
【０１２３】
ステップＳ４３において、放送ネットワーク４を介して、サブジェクトの受信を行うのが有利であると判定された場合、ステップＳ４４に進み、要求部２５は、受信部２１が動作可能な状態であるかどうか（例えば、電源が供給されているかどうか（スリープ状態にないかどうか））を判定する。ステップＳ４４において、受信部２１が動作可能な状態にないと判定された場合、ステップＳ４５に進み、要求部２５は、例えば、イベントの放送スケジュール情報に配置されているサブジェクトの送信時刻の直前まで待って、受信部２１を動作可能な状態にし、即ち、受信部２１がスリープ状態になっている場合には、電源の供給を開始し、ステップＳ４６に進む。
【０１２４】
また、ステップＳ４４において、受信部２１が動作可能な状態にあると判定された場合、ステップＳ４５をスキップして、ステップＳ４６に進み、要求部２１は、受信部２１を制御することにより、データベース２３から読み出したイベントの放送スケジュール情報に配置されている送信チャンネルで、同じくその放送スケジュール情報に配置されている送信時刻に、放送ネットワーク４を介して送信されてくるサブジェクト、即ち、イベントに付加されている識別子と同一の識別子のサブジェクトを受信させ、選択部２２に供給させる。そして、ステップＳ４７において、選択部２２では、図１０のステップＳ３６における場合と同様にして、受信部２１からのサブジェクトに基づき、データベース２３の更新が行われ、データ要求処理を終了する。
【０１２５】
ここで、受信端末５において、データの取りこぼしは、受信部２１の電源がオフ状態になっていることに起因して生じることが多い。そこで、上述のように、受信部２１が動作可能な状態になっているかどうかを判定し、なっていない場合には、受信部２１を動作可能な状態にすることで、受信部２１の電源がオフ状態になっていることに起因するサブジェクトの取りこぼしを防止することができる。
【０１２６】
一方、ステップＳ４３において、双方向ネットワーク６を介して、サブジェクトを受信するのが有利であると判定された場合、ステップＳ４８に進み、要求部２５は、通信制御部２４を制御することで、データベース２３から読み出したイベントに含まれる識別子と同一の識別子が付加されているサブジェクトを、通信ネットワーク６を介して、サーバ２やミラーサーバ７に要求させる。
【０１２７】
即ち、要求部２５は、データベース２３から読み出したイベントに含まれる識別子と、同じくそこに含まれるサーバアクセス情報（ここでは、上述したように、ＩＰアドレス）とから、その識別子と同一の識別子が付加されているサブジェクトに対応付けられているＵＲＬを構成し、通信制御部２４を制御することで、通信ネットワーク６を介して、サーバ２やミラーサーバ７に送信させる。
【０１２８】
ＵＲＬが送信されたサーバ２やミラーサーバ７では、図８で説明した要求データ送信処理が行われ、これにより、そのＵＲＬに対応付けられているサブジェクトが、通信ネットワーク６を介して送信されてくる。このサブジェクトは、ステップＳ４９において、通信制御部２４によって受信され、要求部２５に供給される。要求部２５は、通信制御部２４からサブジェクトを受信すると、ステップＳ４７に進み、上述したようにして、そのサブジェクトに基づき、データベース２３の更新を行い、データ要求処理を終了する。
【０１２９】
以上のように、サブジェクトを、放送ネットワーク４または通信ネットワーク３６のうちのいずれを介して受信する方が有利かどうかを判定し、有利な方を介して送信されるサブジェクトを受信するようにしたので、受信端末５では、効率的に、サブジェクトの受信、およびオブジェクトの更新を行うことが可能となる。
【０１３０】
なお、サブジェクトを、放送ネットワーク４を介して受信する場合において、イベントの放送スケジュール情報に、複数の送信時刻が配置されているときには、例えば、そのうちの、現在時刻に最も近い送信時刻（但し、現在時刻よりも前（過去）の時刻を除く）に送信されてくるサブジェクトが受信される。但し、ユーザに操作部２８を操作してもらい、送信時刻を選択させることも可能である。
【０１３１】
また、サブジェクトを、通信ネットワーク６を介して要求、受信する場合において、イベントのサーバアクセス情報に、複数のサーバのＩＰアドレスが配置されているときには、例えば、そのうちの、受信端末５に最も近い位置にあるサーバのＩＰアドレスを用いてＵＲＬが構成される。但し、ユーザに操作部２８を操作してもらい、サーバを選択させることも可能である。
【０１３２】
次に、図１２のフローチャートを参照して、データ出力処理について説明する。なお、データ出力処理も、例えば、図１１のデータ要求処理と同様に、基本的には、定期的に起動されるようになされている。
【０１３３】
データ出力処理では、まず最初に、ステップＳ５１において、操作部２８が、データ（本実施の形態では、オブジェクト）を出力するように操作されたか否かが、読み出し部２６によって判定され、そのようには操作されていないと判定された場合、データ出力処理を終了する。
【０１３４】
また、ステップＳ５１において、操作部２８が、オブジェクトを出力するように操作されたと判定された場合、ステップＳ５２に進み、出力の要求されたオブジェクトについてのイベント、即ち、そのオブジェクトの識別子と同一の識別子が付加されているイベントが、データベース２３に記憶されているかどうかが、読み出し部２６によって判定される。ステップＳ５２において、出力の要求されたオブジェクトについてのイベントが、データベース２３に記憶されていないと判定された場合、即ち、出力の要求されたオブジェクトとしては、いまデータベース２３に記憶されているものが最新のものである場合（但し、イベントの取りこぼしがないものとする）、ステップＳ５３に進み、読み出し部２６は、出力の要求されたオブジェクトを、データベース２３から読み出し、出力部２７に供給する。出力部２７では、読み出し部２６からのオブジェクトが表示、または音声で出力され、データ出力処理を終了する。
【０１３５】
また、ステップＳ５２において、出力の要求されたオブジェクトについてのイベントが、データベース２３に記憶されていると判定された場合、即ち、出力の要求されたオブジェクトは、サーバ２では更新されているが、受信端末５では、まだ更新されていない場合、ステップＳ５４に進み、そのオブジェクトの更新を行うかどうかが、読み出し部２６によって判定される。
【０１３６】
即ち、ステップＳ５４では、読み出し部２６は、オブジェクトの更新を行うかどうかを問い合わせるメッセージを、出力部２７に表示させ、ユーザに、操作部２８の操作を促す。そして、ステップＳ５４では、操作部２８の操作に対応して、オブジェクトの更新を行うかどうかが判定される。
【０１３７】
あるいは、また、ステップＳ５４では、出力の要求されたオブジェクトについてのイベントの放送スケジュール情報が参照され、そのオブジェクトを更新するためのサブジェクトが、放送ネットワーク４を介して送信されてくる送信時刻のうち、現在時刻に最も近いものが認識される。そして、ステップＳ５４では、その現在時刻に最も近い送信時刻が、現在時刻から、あらかじめ受信端末５に設定された所定の時間内であるかどうかに対応して、オブジェクトの更新を行うかどうかが判定される（送信時刻が、現在時刻から所定の時間内である場合には、オブジェクトの更新を行うと判定される）。
【０１３８】
ステップＳ５４において、出力の要求されたオブジェクトの更新を行わないと判定された場合、ステップＳ５５に進み、読み出し部２６は、出力の要求されたオブジェクト、即ち、更新前のオブジェクトを、データベース２３から読み出し、以下、ステップＳ５３における場合と同様にして、出力部２７に出力させて、データ出力処理を終了する。なお、この場合、出力部２７には、オブジェクトを出力させるとともに、そのオブジェクトが更新前のものである旨のメッセージを表示させるようにしても良い。
【０１３９】
一方、ステップＳ５４において、出力の要求されたオブジェクトの更新を行うと判定された場合、ステップＳ５６に進み、そのオブジェクトの更新するためのデータベース更新処理が行われる。即ち、ステップＳ５６では、出力の要求されたオブジェクトについてのイベントを用いて、図１１のデータ要求処理のステップＳ４３乃至Ｓ４９における場合と同様の処理が行われ、これにより、出力の要求されたオブジェクトが更新される。そして、ステップＳ５３に進み、その更新後のオブジェクトが、上述したようにして、出力部２７から出力され、データ出力処理を終了する。
【０１４０】
ところで、イベントのサーバアクセス情報に、複数のサーバのＩＰアドレスが配置されている場合において、いずれのサーバに、サブジェクトを要求するかを、例えば、上述したように、受信端末５からの位置や、ユーザによる操作部２８の操作に対応して決定したのでは、あるサーバへのアクセスが集中することがある。
【０１４１】
そこで、通信ネットワーク６を介して、受信端末５に対してサブジェクトを送信するサーバが複数存在する場合（例えば、図１に示すように、サーバ２以外に、ミラーサーバ７が存在する場合や、ミラーサーバ７以外のミラーサーバがさらに存在する場合など）には、サーバへのアクセスを分散させるために（１のサーバにアクセスを集中させないために）、受信端末５またはそのユーザに、固有のＩＤ（以下、適宜、ユーザＩＤという）を与え、サーバ２には、各サーバのＩＰアドレスを、所定のユーザＩＤと対応付け、サーバアクセス情報として、イベントに配置する処理（以下、適宜、負荷分散処理という）を行わせてから、イベントを送信させるようにすることができる。一方、受信端末５には、自身のユーザＩＤと対応付けられているＩＰアドレスのサーバを認識する処理（以下、適宜、アクセスサーバ決定処理）を行わせてから、そのサーバに、サブジェクトを要求させるようにすることができる。
【０１４２】
図１３は、サーバ２が行う負荷分散処理のフローチャートを示している。なお、この負荷分散処理は、受信端末５に対して、通信ネットワーク６を介して、サブジェクトを送信するサーバが複数存在する場合（サーバ２以外に、通信ネットワーク６を介して、サブジェクトを送信することのできるサーバが存在する場合）に、例えば、図６のデータ伝送処理におけるステップＳ１２の処理の一部として行われる。
【０１４３】
負荷分散処理では、まず最初に、ステップＳ６１において、通信ネットワーク６を介して、サブジェクトを送信する１のサーバに割り当てる受信端末の数（以下、適宜、割当数という）Ｎが算出される。即ち、ステップＳ６１では、例えば、受信端末の総数が、サブジェクトを通信ネットワーク６を介して送信するサーバの総数で除算され、その除算値（小数点以下は、例えば、切り上げ）が、割当数Ｎとされる。なお、サーバ２では、受信端末の総数が管理されているものとする。また、サーバ２では、サブジェクトを通信ネットワーク６を介して送信するサーバの総数は、複製管理部１４で管理されている情報から認識されるようになされている。
【０１４４】
その後、ステップＳ６２において、通信ネットワーク６を介して、サブジェクトを送信する複数のサーバのうちの１が選択され（この選択されたサーバを、以下、適宜、選択サーバという）、ステップＳ６３に進み、例えば、その選択サーバに近い位置にある受信端末が、割当数Ｎだけ検出される。なお、選択サーバおよび受信端末５の位置は、サーバ２において管理されているものとする。
【０１４５】
そして、ステップＳ６４に進み、選択サーバのＩＰアドレスに、ステップＳ６３で検出されたＮ個の受信端末それぞれのユーザＩＤが対応付けられ、そのＩＰアドレスとＮ個のユーザＩＤとの組が、サーバアクセス情報として、イベントに配置される。その後、ステップＳ６５に進み、通信ネットワーク６を介して、サブジェクトを送信する複数のサーバすべてを、選択サーバとして、ステップＳ６２乃至Ｓ６４の処理を行ったかどうかが判定される。ステップＳ６５において、複数のサーバすべてを、まだ、選択サーバとして処理していないと判定された場合、ステップＳ６２に戻り、まだ選択サーバとして選択されていないサーバが、新たに選択サーバとされ、以下、同様の処理を繰り返す。一方、ステップ６５において、複数のサーバすべてを選択サーバとして処理を行ったと判定された場合、負荷分散処理を終了する。
【０１４６】
以上のようにして、負荷分散処理では、１のサーバに、Ｎ個（またはＮ−１個）の受信端末が割り当てられる。
【０１４７】
なお、上述の場合においては、単純に、受信端末の総数を、サブジェクトを通信ネットワーク６を介して送信するサーバの総数で除算した除算値を、１のサーバに割り当てる受信端末の数としたが、複数のサーバそれぞれに割り当てる受信端末の数は、例えば、さらに、各サーバの処理能力などを考慮して決めても良い。
【０１４８】
次に、図１４のフローチャートを参照して、受信端末５が行うアクセスサーバ決定処理について説明する。なお、このアクセスサーバ決定処理は、受信端末５において、例えば、図１１のデータ要求処理のステップＳ４８で送信するＵＲＬを構成する前に行われる。
【０１４９】
アクセスサーバ決定処理では、ステップＳ７１において、受信端末５は、イベントのサーバアクセス情報の中から、自身に割り当てられているユーザＩＤを検索し、ステップＳ７２に進む。ステップＳ７２では、自身のユーザＩＤに対応付けられているＩＰアドレス、即ち、サブジェクトを要求すべきサーバが認識され、アクセスサーバ決定処理を終了する。
【０１５０】
そして、受信端末５では、図１１で説明したように、ステップＳ４８において、ステップＳ７２で認識されたＩＰアドレスを用いてＵＲＬが構成されて送信される。
【０１５１】
以上のように、サーバ２または受信端末５において、負荷分散処理またはアクセスサーバ決定処理をそれぞれ行うことで、受信端末からのサブジェクトの要求を、複数のサーバに分散させることができ、効率の良いサブジェクトの配信が可能となる。
【０１５２】
なお、上述の場合においては、受信端末のユーザＩＤとＩＰアドレスとを対応付け、受信端末がアクセスすべきサーバを制限するようにしたが、その他、例えば、受信端末のユーザＩＤと、サーバに対して通信ネットワーク６を介してアクセス可能な時間帯（要求タイミング情報）とを対応付け、受信端末がサーバにアクセスする時間帯を制限するようにすることなどによっても、サーバに対するアクセスを分散させることが可能である。
【０１５３】
以上、本発明を適用したデータ配信システムについて説明したが、このようなデータ配信システムは、例えば、分散型データベースにおける多数のデータベースへのデータの配信を行う場合や、ＩＰマルチキャストによりデータを配信する場合、その他、データを不特定多数に配信する場合に、特に有用である。
【０１５４】
なお、本実施の形態では、イベントは、放送ネットワーク４を介して送信するようにしたが、その他、例えば、受信端末５からの要求に応じて、通信ネットワーク６を介して送信するようにしても良い。さらに、本発明において、放送ネットワーク４および通信ネットワーク６の両方を備えることは必須ではない。即ち、本発明は、放送ネットワーク４または通信ネットワーク６のいずれか１つだけを備えるシステムにも適用可能である。
【０１５５】
また、本実施の形態では、サーバアクセス情報に、サーバ２やミラーサーバ７のＩＰアドレスを配置するようにしたが、サーバアクセス情報には、その他、例えば、サーバ２やミラーサーバ７で管理されているサブジェクトのＵＲＬや、サーバ２やミラーサーバ７へアクセスするための電話番号などを配置することも可能である。
【０１５６】
また、ミラーサーバ７には、受信端末５と同様にして、イベントやサブジェクトを受信させて、データベース８の更新を行わせるようにすることが可能である。
【０１５７】
さらに、本実施の形態では、サブジェクトに含める更新オブジェクト情報として、更新後のオブジェクトそのものなどを配置するようにしたが、更新オブジェクト情報としては、その他、例えば、更新前のオブジェクトに、更新後のオブジェクトへの変更内容を反映させるためのデータ（例えば、更新前のオブジェクトを、更新後のオブジェクトに変更する実行形式のコンピュータプログラムや、更新後のオブジェクトと更新前のオブジェクトとの差分など）などを配置することも可能である。
【０１５８】
次に、図７においては、データ構成部１７において生成されるイベントのデータ構造の概要を説明したが、このデータ構成部１７で構成されるイベントを、例えば、任意のトランスポートプロトコル上で実現するためのフォーマットについて詳述する。
【０１５９】
なお、ここでは、イベントのフォーマットを、ＡＮＳ．１（Abstract Syntax Notation One）を用いた抽象構文表現によって表すこととする。
【０１６０】
ここで、ＡＮＳ．１によって表されたフォーマットは、ＡＳＮ．１の符号化規則ＢＥＲ（Basic Encoding Rules），ＣＥＲ（Canonical Encoding Rules），ＤＥＲ（Distinguished Encoding Rules），ＰＥＲ（Packed Encoding Rules）に基づき、一意に符号化（ビット列（転送構文）に変換）することができる。また、その符号化や、符号化結果の復号を行うための処理系は、ＡＳＮ．１準拠の商用／パブリックドメインソフトウェアのツールＳｎａｃｃ（Sample Neufeld Asn.1 to C Compiler）などを利用することで、容易に構成することができる。
【０１６１】
なお、ＡＮＳ．１による抽象構文については、例えば、「プロトコル構文規定言語ＡＳＮ．１」、カットシステム発行などに、符号化規則ＢＥＲ，ＣＥＲ，ＤＥＲについては、例えば、ISO/IEC 8825-1:ASN.1 Encoding Rules:Specification of Basic Encoding Rules(BER), Canonical Encoding Rules(CER), and Distinguished Encoding Rules(DER)などに、符号化規則ＰＥＲについては、例えば、ISO/IEC 8825-1:ASN.1 Encoding Rules:Specification of Packed Encoding Rules(PER)などに、その詳細が開示されている。
【０１６２】
イベントEventMessageは、例えば、次のように定義される。
【０１６３】
【０１６４】
ここで、SEQUENCE{}は、イベント（イベントの型）EventMessageが、かっこ｛｝内で定義されている変数formatVersion,FormatVersion,filteringMasks,timeToLive,objectIdentifier,objectVersion,subjectLinksの順序列で表現されることを表す。また、かっこ｛｝内の左から２番目に配置されているFormatVersion,FilteringMasks,UTCTime,ObjectIdentifier,INTEGER,SubjectLinksは、その左に配置されている変数の型を表す。また、かっこ｛｝内の左から３番目に配置されているOPTIONALは、その行で定義されている変数が、任意的変数（省略可能な変数）であることを表す。従って、ここでは、イベントEventMessageは、少なくとも、フォーマットバージョンformatVersion、生存時間timeToLive、オブジェクト識別子objectIdentifierで構成される。
【０１６５】
なお、型FormatVersion,FilteringMasks,UTCTime,ObjectIdentifier,INTEGER,SubjectLinksのうち、INTEGERは整数を、UTCTimeは国際標準時刻またはローカル時刻（少なくとも、秒の精度を有する）を、それぞれ表す。他の型の定義については、後述する。
【０１６６】
イベントEventMessageにおいて、フォーマットバージョンformatVersionは、そのイベントEventMessageのフォーマットのバージョンを表す。即ち、イベントEventMessageのフォーマットを、将来拡張することを考えると、受信端末５において、イベントEventMessageを処理するには、そのフォーマットを認識する必要がある。フォーマットバージョンformatVersionは、イベントEventMessageのフォーマットを特定するための情報（フォーマット情報）で、受信端末５では、このフォーマットバージョンformatVersionによって、受信したイベントEventMessageのフォーマットが認識されて処理される。
【０１６７】
フォーマットバージョンformatVersionの型FormatVersionは、例えば、次のように定義される。
【０１６８】
【０１６９】
即ち、フォーマットバージョンformatVersionは、ここでは、メジャーバージョンmajorVersionおよびマイナーバージョンminorVersionと呼ばれる２つの整数（INTEGER）で表される。なお、メジャーバージョンmajorVersionおよびマイナーバージョンminorVersionの使い分けや、数字の割り当て方などは、データ配信システムの運用者が任意に定義可能とすることもできるが、ここでは、例えば、メジャーバージョンmajorVersionには、イベントとサブジェクトを区別するための情報を配置することとする。即ち、例えば、イベントについてのメジャーバージョンmajorVersionとしては、所定値以上を用い、サブジェクトについてのメジャーバージョンmajorVersionとしては、所定値未満を用いることとする。この場合、フォーマットバージョンformatVersionは、イベントEventMessageのフォーマットのバージョンを表す他、図７で説明した判別フラグとしての役割も果たす。
【０１７０】
ここで、イベントとサブジェクトを区別する情報は、メジャーバージョンmajorVersionに配置する他、トランスポートレイヤより上位の、例えば、アプリケーションレイヤやプレゼンテーションレイヤなどにおいて定義することも可能である。
【０１７１】
イベントEventMessageにおけるフィルタマスクfilteringMasksは、受信端末５において、そのイベントEventMessageを取捨選択するための基準として用いることのできる情報（選択基準情報）で、その型FilteringMasksは、例えば、次のように定義される。
【０１７２】
【０１７３】
ここで、SEQUENCE OF{}は、フィルタマスク（フィルタマスクfilteringMasksの型）FilteringMasksが、かっこ｛｝内で定義されている変数filteringMaskIdentifierとfilteringMaskFieldとの組み合わせの順序列で表現されることを表す。従って、フィルタマスクfilteringMasksは、変数filteringMaskIdentifierとfilteringMaskFieldとの組み合わせを１つだけでなく、複数配置して構成することができる。また、変数filteringMaskFieldの型ANY DEFINED BYは、BYの後に配置されている変数に依存する任意の型（任意型）であることを表す。従って、変数filteringMaskFieldの型は、その前の行に配置されている変数filteringMaskIdentifilerに対応した任意の型を取り得る。
【０１７４】
フィルタマスクfilteringMasksにおけるマスク識別子filteringMaskIdentifierは、マスクフィールドfilteringMaskFieldを識別するためのもので、ここでは、マスクフィールドfilteringMaskFieldごとに、ユニークな整数が用いられるようになされている。
【０１７５】
フィルタマスクfilteringMasksにおけるマスクフィールドfilteringMaskFieldは、イベントEventMessageに対応するオブジェクト（イベントEventMessageに基づいて取得されるサブジェクトによって更新されるオブジェクト）を取捨選択するための基準として用いることのできる情報で、そこには、例えば、そのオブジェクトのカテゴリや、オブジェクトを視聴するにあたっての年齢制限、オブジェクトの視聴することの契約内容などに関する情報が配置される。
【０１７６】
即ち、マスクフィールドfilteringMaskFieldには、例えば、オブジェクトが、スポーツに関するものであるとか、天気予報に関するものであるとかを表す情報を配置し、さらに、オブジェクトが、スポーツに関するものであるという情報が配置される場合には、そのオブジェクトが、スポーツのうちの、野球に関するものであるとか、サッカーに関するものであるとかを表す情報を配置することができる。この場合、受信端末５における選択部２２に、例えば、ユーザの所望するカテゴリを設定しておき（カテゴリの設定は、例えば、ユーザに行わせるようにしても良いし、受信端末５において、ユーザによるオブジェクトの視聴履歴を記憶するようにして、その視聴履歴に基づいて行うようにしても良い）、そのカテゴリを、マスクフィールドfilteringMaskFieldと比較させることで、ユーザの所望するカテゴリのオブジェクトに対応するイベントだけを選択させることなどが可能となり、その結果、ユーザの所望するカテゴリのオブジェクトだけの提供を受けることが可能となる。なお、逆に、受信端末５における選択部２２に、ユーザが所望しないカテゴリを設定しておき、そのカテゴリを、マスクフィールドfilteringMaskFieldと比較させることで、ユーザの所望しないカテゴリを除くカテゴリのオブジェクトに対応するイベントだけを選択させるようにすることも可能である。
【０１７７】
また、マスクフィールドfilteringMaskFieldには、例えば、オブジェクトが、何歳以上向けであるといった年齢制限に関する情報を配置することも可能である。この場合、受信端末５における選択部２２に、例えば、年齢を設定しておき、その年齢を、マスクフィールドfilteringMaskFieldと比較させることで、成人向けのオブジェクトに対応するイベントを選択しないようにすることなどが可能となる。
【０１７８】
さらに、マスクフィールドfilteringMaskFieldには、オブジェクトが、高額の契約料を支払う契約内容のユーザ向けとか、低額の契約料を支払う契約内容のユーザ向けといった契約内容に関する情報を配置することも可能である。この場合、受信端末５における選択部２２に、契約内容を設定しておき、その契約内容を、マスクフィールドfilteringMaskFieldと比較させることで、オブジェクトの視聴にあたっての契約内容に応じたオブジェクトの選択を行うようにすることなどが可能となる。
【０１７９】
ここで、フィルタマスクfilteringMasksは、上述したように、マスク識別子filteringMaskIdentifierとマスクフィールドfilteringMaskFieldとの組み合わせを１以上配置して構成することができるから、そこには、例えば、オブジェクトのカテゴリと、オブジェクトを視聴するにあたっての年齢制限がそれぞれ配置された２つのマスクフィールドfilteringMaskFieldを、対応するマスク識別子filteringMaskIdentifierと組み合わせて順次記述することが可能である。この場合、選択部２２では、所定のカテゴリに属し、かつ所定の年齢向けのオブジェクトに対応するイベントのみを選択したり、また、所定のカテゴリに属するオブジェクトと、所定の年齢向けのオブジェクトとのうちのいずれかに対応するオブジェクトを選択するようにすることが可能となる。なお、この場合、選択部２２では、フィルタマスクfilteringMasksに配置された２つのマスクフィールドfilteringMaskFieldそれぞれが、オブジェクトのカテゴリに関するものか、またはオブジェクトを視聴するにあたっての年齢制限に関するものであるかは、それぞれに対応するマスク識別子filteringMaskIdentifierに基づいて認識される。
【０１８０】
また、マスク識別子filteringMaskIdentifierは、マスクフィールドfilteringMaskFieldに配置される情報が異なれば、異なる値とされるが、同一の情報が配置される場合でも、異なる値とされることがある。即ち、例えば、マスクフィールドfilteringMaskFieldに、オブジェクトのカテゴリに関する情報を配置する場合に、カテゴリ数が増加し、その増加したカテゴリを表現するために、マスクフィールドfilteringMaskFieldに割り当てるビット数を増加する必要が生じることがある。具体的には、マスクフィールドfilteringMaskFieldが、例えば、当初は８ビットであったのに、１６ビットに増加される場合がある。このような場合には、８ビットのマスクフィールドfilteringMaskFieldと、１６ビットのマスクフィールドfilteringMaskFieldとで、異なるマスク識別子filteringMaskIdentifierが対応付けられる。これは、受信端末５において、マスクフィールドfilteringMaskFieldに割り当てられているビット数を認識することができるようにするためである。
【０１８１】
以上のようなフィルタマスクfilteringMasksを、イベントEventMessageに配置することで、選択部２２において、イベントEventMessageの取捨選択が可能となり、その結果、サブジェクトに、フィルタマスクfilteringMasksを含ませなくても、サブジェクトの取捨選択が可能となる。即ち、サブジェクトは、イベントEventMessageに基づいて取得されるから、イベントEventMessageの取捨選択を行うことで、結果的に、サブジェクトの取捨選択も行われる。さらに、それにより、サブジェクトによって更新されるオブジェクトの取捨選択も行われる。
【０１８２】
次に、イベントEventMessageにおける生存時間（期限情報）timeToLiveは、イベントEventMessageの有効期限を表す。即ち、受信端末５においては、放送ネットワーク４を介して送信されてくるイベントEventMessageが受信されるが、例えば、受信端末５では、受信されたイベントEventMessageが、一旦、データベース２３に記憶されるので、即座に処理されるとは限らない。このため、イベントEventMessageを対象に、図１１のデータ要求処理を行おうとするときには、そのイベントEventMessageが、既に、使用不能の状態になっていることがある。
【０１８３】
即ち、例えば、イベントEventMessageに、サブジェクトの放送時刻などが配置されている場合において、図１１のデータ要求処理の開始時刻が、その放送時刻を過ぎていることがある。この場合、図１１のデータ要求処理を行ったとしても、既にサブジェクトの放送は終了しているから、受信端末５において、そのサブジェクトを受信することはできない。従って、そのような使用不能のイベントEventMessageを、データベース２３に記憶させておくのは、記憶容量の無駄であり、好ましくない。
【０１８４】
また、イベントEventMessageは、受信端末５に対して、例えば、衛星回線などの放送ネットワーク４を介して送信する他、上述したように、例えば、インターネットなどの通信ネットワーク６を介して送信することもできるが、イベントEventMessageを通信ネットワーク６を介して送信する場合には、回線の混み具合（トラフィック）などに起因して、受信端末５でイベントEventMessageを受信するのが、サーバ２による送信がなされてから、相当の時間が経過した後になることがある。このような場合も、イベントEventMessageが、既に、使用不能の状態になっていることがある。
【０１８５】
そこで、生存時間timeToLiveには、いわば、イベントEventMessageの鮮度を表す指標として、そのイベントEventMessageを廃棄する時刻が配置される。
【０１８６】
この場合、受信端末５では、イベントの受信時刻や、データベース２３に記憶されたイベントを参照した時刻などが、生存時間timeToLiveに配置された時刻を経過していた場合、そのイベントは使用不能であるとして廃棄される（受信したイベントはデータベース２３に記憶されず、また、参照されたイベントはデータベース２３から削除される）。
【０１８７】
なお、サーバ２では、生存時間timeToLiveは、例えば、次のようにして設定される。即ち、サーバ２のデータ構成部１７では、イベントEventMessageに対応するオブジェクトの更新間隔（オブジェクトが更新されてから、次に更新されるまでの時間）の平均値などが求められ、その平均値の整数倍によって表される時間を、イベントEventMessageの作成時刻に加算して得られる時刻が、生存時間timeToLiveに配置される。なお、生存時間timeToLiveの設定方法は、これに限定されるものではない。
【０１８８】
次に、イベントEventMessageにおけるオブジェクト識別子objectIdentifierは、そのイベントEventMessageが更新を報知するオブジェクトが存在する位置に関する情報（位置情報）で、受信端末５では、このオブジェクト識別子objectIdentifierに基づいて、更新されたオブジェクトが特定、認識される。サーバ２において、データベース３のオブジェクトが更新された場合、そのオブジェクトの更新に対応して、イベントEventMessageが作成されるから、その更新されたオブジェクトを特定するオブジェクト識別子objectIdentifierによれば、その更新を報知するイベントEventMessageを特定することができ、従って、オブジェクト識別子objectIdentifierは、図７に示したＩＤに相当する。
【０１８９】
オブジェクト識別子objectIdentifierの型ObjectIdentifierは、例えば、次のように定義される。
【０１９０】
【０１９１】
取得可能時間avairableTimeは、更新が報知されたオブジェクトが存在する時間的な位置、即ち、例えば、その更新後のオブジェクトが、データベース３に登録された時間や、データベース３に登録されている時間（オブジェクトが更新されてから、次に更新されるまでの時間）などの、オブジェクトが有効に存在する時間を表す。取得可能時間avairableTimeは、記述しても、またしなくても良く、その型AvairableTimeは、例えば、次のように定義される。
【０１９２】
【０１９３】
開始時刻startTimeは、ここでは、例えば、更新後のオブジェクトがデータベース３に登録された時刻を表す。また、終了時刻endTimeは、ここでは、例えば、更新後のオブジェクトが、次に更新される時刻を表す。なお、取得可能時間avairableTimeを記述する場合、開始時刻startTimeの記述は必須であるが、終了時刻endTimeの記述は任意（OPTIONAL）である。
【０１９４】
オブジェクト識別子objectIdentifierにおけるロケータlocatorは、更新が報知されたオブジェクトが存在する地理的または論理的な位置を表す。ここで、オブジェクトの地理的な位置とは、例えば、オブジェクトを管理するサーバ２のインターネットアドレスなどのネットワーク上の位置を特定するための情報を意味する。また、論理的な位置とは、オブジェクトが、あるテーブルやデータ構造などの一部を構成している場合における、そのテーブルやデータ構造中のオブジェクトの位置を意味する。具体的には、例えば、オブジェクトが、ＥＰＧ（Electric Program Guide）の、あるチャンネルにおける、ある時間帯のテレビジョン放送番組を紹介する欄を構成している場合には、ＥＰＧ上の、その欄の位置が、そのオブジェクトの論理的な位置となる。
【０１９５】
ロケータlocatorの型Locatorは、例えば、次のように定義される。
【０１９６】
【０１９７】
ここで、CHOICE{}は、かっこ｛｝内で定義されている変数netLocatorとdvbSpecificLocatorのうちのいずれかが選択されること（従って、Locatorが選択型であること）を意味する。
【０１９８】
ネットロケータnetLocatorは、インターネットプロトコルによりアクセス可能なドメインのリソースを特定するもので、その型NETLocatorは、例えば、以下のように定義される。
【０１９９】
【０２００】
ここで、EXTERNALは、ＡＳＮ．１モジュールのスコープ外で定義されるデータ型（外部型）であることを意味し、その定義は、ＡＳＮ．１の構文にしたがった定義でなくても良い。
【０２０１】
ＮＳＡＰロケータnsapSpecificLocatorは、ＮＳＡＰ（Networks Service Access Point）を特定するのに用いられるもので、その型NSAPSpecificLocatorは、例えば、次のように定義される。
【０２０２】
【０２０３】
ＮＳＡＰアドレスnsapAddressは、外部型（EXTERNAL）であり、そのシンタクスとしては、例えば、E.164NSAPformatや、ＡＥＳＡ（ATM(Asynchronous Transfer Mode) End System Address）のNSAPencodeE.164formatなどを採用することができる。なお、E.164NSAPformatについては、例えば、ISO/IEC8348:Network Service Definitionに、AESAのNSAPencodeE.164formatについては、例えば、ATM User-Network Interface(UNI) Specification 3.0/3.1に、それぞれ、その定義が記載されている。
【０２０４】
付加情報additionalInfoは、ＮＳＡＰアドレスnsapAddressにアクセスする際に必要となる、例えば、ＰＰＰ（Point to Point Protocol）を選択することを示すプロトコル識別情報や、認証プロトコルに必要な情報、モデム設定コマンドシーケンス（ヘイズATコマンド）などの付加情報であり、その型は任意（任意型）（ANY）とされている。なお、付加情報additionalInfoの記述は任意である。
【０２０５】
ネットロケータnetLocatorにおけるリソース識別子universalResourceIdentifierは、いわゆるＵＲＩ（Universal Resource Identifier）を意味する。ＵＲＩは、ＷＷＷにおいて提供されるリソースを一意に識別することができ、ユーザが、インターネットに、直接接続することができる場合（受信端末５が、インターネットに直接接続される場合）に利用される。ここで、リソース識別子universalResourceIdentifierのシンタクスとしては、例えば、RFC1630:Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Webに定義されているものを利用することができる。
【０２０６】
なお、ネットロケータnetLocatorとして、ＵＲＩと、ＮＳＡＰロケータnsapSpecificLocatorとの両方を利用可能としたのは、例えば、X.25や公衆網を利用したダイヤルアップ接続（ＡＴＭ接続も含む）によってアクセス可能な、孤立したインターネットのドメインにおけるオブジェクトにアクセスすることができるようにするためである。
【０２０７】
ロケータlocatorにおけるＤＶＢロケータdvbSpecificLocatorは、ＤＶＢ（Digital Video Broadcasting）互換のディジタル放送によるストリーム上のリソースを特定するもので、その型DVBSpecificLocatorは、例えば、次のように定義される。
【０２０８】
【０２０９】
プリミティブロケータdvbPrimitiveLocatorは、ＤＶＢにおいて定義されているデータ構造／ストリームを特定するもので、これにより、例えば、ＤＶＢ−ＳＩに規定されているディジタル放送によるＥＰＧ上の任意のテーブルを指定することができる。従って、この場合、イベントEventMessageは、例えば、ＤＶＢ−ＳＩに規定されているフォーマットにより放送されるＥＰＧテーブルの内容の更新にも利用することができる。なお、ＤＶＢ−ＳＩについては、例えば、ETC300 468:Digital broadcasting systems for television, sound and data services;Specification for Service Information(SI) in Digital Video Broadcasting(DVB) systemsに、その詳細が記載されている。
【０２１０】
プリミティブロケータdvbPrimitiveLocatorの型DVBPrimitiveLocatorは、例えば、次のように定義される。
【０２１１】
【０２１２】
ここで、かっこ［］とその中に配置されている数字は、構造型を構成する同一の型の複数の変数それぞれを識別するためのタグである。
【０２１３】
なお、NetworkID, TransportID, packetID, serviceID, tableID, tableIDExtention, sectionNumber, eventID, componentTagについては、例えば、ISO/IEC13818-1:Infomation technology-Generic coding of moving pictures and associated audio information-Part1:Systems-International Standard(IS)、およびETC300 468:Digital broadcasting systems for television, sound and data services;Specification for Service Information(SI) in Digital Video Broadcasting(DVB) systemsに、その詳細が記載されているので、ここでは、説明を省略する。
【０２１４】
ＤＶＢロケータDVBSpecificLocatorにおけるデータカルーセルロケータdvbDataCarouselLocatorは、データカルーセル（Data Carousel）と呼ばれるデータ構造を特定するもので、その型DVBDataCarouselLocatorは、例えば、次のように定義される。
【０２１５】
【０２１６】
また、ＤＶＢロケータDVBSpecificLocatorにおけるオブジェクトカルーセルロケータdvbObjectCarouselLocatorは、オブジェクトカルーセル（Object Carousel）と呼ばれるデータ構造を特定するもので、その型DVBObjectCarouselLocatorは、例えば、次のように定義される。
【０２１７】
【０２１８】
なお、データカルーセル、オブジェクトカルーセル、groupID, moduleID, carouselID, objectKeyについては、例えば、Digital Video Broadcasting:DVB Specification for Data Broadcasting-Final Draft 12/02/97、およびImplementation Guidelines for Databroadcasting(SI-DAT382 Rev.3)に、その詳細が記載されているので、ここでは、説明を省略する。
【０２１９】
次に、イベントEventMessageにおけるオブジェクトバージョンobjectVersionは、そのイベントEventMessageに基づいて取得されるサブジェクトによって更新されるオブジェクトの、その更新後のバージョンを表し、図７におけるバージョン情報に相当する。オブジェクトバージョンobjectVersionとしては、例えば、オブジェクトが更新される度にインクリメントされる整数値や、更新後のオブジェクトのハッシュ値などを用いることができる。
【０２２０】
イベントEventMessageにおけるサブジェクトリンクsubjectLinksは、そのイベントEventMessageに基づいて取得されるサブジェクト（オブジェクト識別子objectIdentifierによって特定されるオブジェクトを更新するためのサブジェクト）を特定するためのもので、その型SubjectLinksは、例えば、次のように定義される。
【０２２１】
【０２２２】
サブジェクト識別子subjectIdentifierは、上述のオブジェクト識別子objectIdentifierと同一の型ObjectIdentifierを有し、そこには、サブジェクトが存在する位置に関する情報（位置情報）が配置される。従って、受信端末５では、このサブジェクト識別子subjectIdentifierに基づいて、オブジェクトを更新するためのサブジェクトが取得される。
【０２２３】
なお、サブジェクト識別子subjectIdentifierは、ObjectIdentifier型であるから、取得可能時間avairableTimeを有する場合があるが、これは、図７で説明した放送スケジュール情報の中の放送時刻に相当する。また、サブジェクト識別子subjectIdentifierは、ロケータlocatorを有するが、これは、図７で説明したサーバアクセス情報（サーバ２などのＩＰアドレス）（サブジェクトの地理的位置）や、放送スケジュール情報の中の放送チャンネル（サブジェクトの論理的位置）に相当する。
【０２２４】
サブジェクトバージョンsubjectVersionは、整数型（INTEGER）で、サブジェクトのバージョンを表す。即ち、例えば、サブジェクトに、いわゆるバグがあり、その修復がされたサブジェクトが新たに作成される場合がある。また、サブジェクトの内容は同一のままで、そのシンタクスが変更される場合がある。そのような場合において、バグの修正前のサブジェクトと修正後のサブジェクトとを区別したり、シンタクスの変更前のサブジェクトと変更後のサブジェクトとを区別するためなどに、サブジェクトバージョンsubjectVersionは用いられる。
【０２２５】
サービス仕様qosSpecificationには、サブジェクトを、サブジェクト識別子subjectIdentifierに基づいて取得するかどうかを決めるための基準として用いることのできる情報（取得決定基準情報）が配置される。即ち、サブジェクトリンクSubjectLinksは、SEQUENCE OF{}で定義されているから、かっこ｛｝内で定義されている変数の組み合わせが、１以上配置されて構成される。具体的には、例えば、サブジェクトが、放送ネットワーク４を介して放送されるとともに、サーバ２において、受信端末５からの要求に応じて、通信ネットワーク６を介して送信される場合には、放送ネットワーク４を介して放送されるサブジェクトと、通信ネットワーク６を介して送信されるサブジェクトとのそれぞれについて、サブジェクトリンクSubjectLinksを規定するsubjectIdentifier, subjectVersion, qosSpecification, clientIdentifierが記述される。このような場合において、サービス仕様qosSpecificationは、サブジェクトを、放送ネットワーク４または通信ネットワーク６のうちのいずれを利用して受信するのかを決定するために参照される。
【０２２６】
サービス仕様qosSpecificationの型QOSSpecificationは、例えば、次のように定義される。
【０２２７】
【０２２８】
ＱＯＳタイプqosSpecTypeには、サブジェクトを、サブジェクト識別子subjectIdentifierに基づいて取得するかどうかを決めるための基準として用いる情報の種別を表す整数値が配置される。即ち、ＱＯＳタイプqosSpecTypeは、それと組になっているＱＯＳ値qosSpecValueが、どのような情報の値であるのかを表す。
【０２２９】
ＱＯＳ値qosSpecValueには、サブジェクト識別子subjectIdentifierに基づいて、サブジェクトを取得するかどうかを決めるための基準として用いる情報としての、例えば、サーバ２側にかかっている負荷の状況や、サブジェクトのデータ量、通信ネットワーク６の混み具合などに対応する整数値が配置される。
【０２３０】
例えば、ＱＯＳ値qosSpecValueが、サーバ２側にかかっている負荷が大きいことを表している場合には、サブジェクトを、通信ネットワーク６を介して要求したのでは、サブジェクトが送信されてくるのに時間を要すると予想されるから、放送ネットワーク４を介して放送されてくるのを待って受信した方が良いとの判断の基準にすることができる。また、例えば、ＱＯＳ値qosSpecValueが、サブジェクトのデータ量が多いことを表している場合には、サブジェクトを、通信ネットワーク６を介して要求したのでは、データ量の多いサブジェクトを受信するのに通信コストが多くかかると予想されるから、放送ネットワーク４を介して放送されてくるのを待って受信した方が良いとの判断の基準にすることができる。さらに、例えば、ＱＯＳ値qosSpecValueが、通信ネットワーク６のトラフィック量が少ないことを表している場合には、サブジェクトを、即座に、かつ短い時間で取得することができると予想されるから、通信ネットワーク６を介して受信した方が良いとの判断の基準にすることができる。
【０２３１】
ここで、以上のようなことから、ＱＯＳ値qosSpecValueは、サブジェクトの提供サービスの質を表しているということもできる。
【０２３２】
サブジェクトリンクsubjectLinksにおけるクライアント識別子clientIdentifierには、サブジェクトの取得が許可されているユーザに関する情報（ユーザ情報）が配置され、その型ClientIdentfierは、例えば、次のように定義される。
【０２３３】
【０２３４】
グループ識別子clientGroupIdentifierには、ある複数の受信端末のグループを特定する整数値が配置される。グループ識別子clientGroupIdentifierによれば、それによって特定される複数の受信端末だけに、サブジェクトを取得させることが可能となる。
【０２３５】
クライアント識別子clientIdentifiersには、１以上の受信端末のユーザＩＤ（図１３および図１４で説明したユーザＩＤ）が配置される。クライアント識別子clientIdentifiersによれば、それによって特定される１以上の受信端末だけに、サブジェクトを取得させることが可能となる。なお、クライアント識別子clientIdentifiersの型であるSET OF INTEGERは、整数型の集合（集合型）を表す。
【０２３６】
以上のように、クライアント識別子clientIdentifierによれば、サブジェクトを取得させる受信端末を制限することができるので、例えば、１のサーバに、サブジェクトの要求が集中することなどを防止することができる。
【０２３７】
以上、イベントを、任意のトランスポートプロトコル上で実現するためのフォーマットを、ＡＮＳ．１を用いた抽象構文表現によって表したが、このようなフォーマットのイベントの符号化を、例えば、ＡＳＮ．１準拠の商用／パブリックドメインソフトウェアのツールＳｎａｃｃを利用して行う場合には、例えば、以下のようなファイルを、その入力として与えてやればよい。
【０２３８】
【０２４０】
【発明の効果】
以上の如く、本発明の受信装置および受信方法によれば、放送ネットワークを介してデータカルーセル方式で繰り返し送信されるコンテンツ、および、コンテンツの更新を報知するための報知データが受信され、受信されたコンテンツが記憶され、受信された報知データに記述されている、コンテンツの新しさを表すバージョン情報の更新が検出され、バージョン情報の更新が検出された場合、新たに受信されるコンテンツであって、報知データに記述されている、コンテンツが存在する位置に関する位置情報に対応付けられている更新コンテンツが要求され、記憶されているコンテンツが、更新コンテンツに更新される。従って、報知データに基づき、コンテンツの更新を、容易かつ効率的に行うことが可能となる。
【図面の簡単な説明】
【図１】本発明を適用したデータ配信システムの一実施の形態の構成例を示す図である。
【図２】図１のサーバ２の構成例を示すブロック図である。
【図３】図１のミラーサーバ７の構成例を示すブロック図である。
【図４】サーバ２が行う登録処理を説明するためのフローチャートである。
【図５】図１のデータベース１ａ乃至１ｃから供給されるデータのフォーマットを示す図である。
【図６】サーバ２が行うデータ伝送処理を説明するためのフローチャートである。
【図７】サブジェクトおよびイベントのフォーマットを示す図である。
【図８】サーバ２が行う要求データ送信処理を説明するためのフローチャートである。
【図９】図１の受信端末５の構成例を示すブロック図である。
【図１０】受信端末５が行う受信処理を説明するためのフローチャートである。
【図１１】受信端末５が行うデータ要求処理を説明するためのフローチャートである。
【図１２】受信端末５が行うデータ出力処理を説明するためのフローチャートである。
【図１３】サーバ２が行う負荷分散処理を説明するためのフローチャートである。
【図１４】受信端末５が行うアクセスサーバ決定処理を説明するためのフローチャートである。
【符号の説明】
１ａ乃至１ｃ データベース， ２ サーバ， ３ データベース， ４ 放送ネットワーク， ５ 受信端末， ６ 通信ネットワーク， ７ ミラーサーバ， ８ データベース， １１ 通信制御部， １２ 資源割当部， １３ データ検索部， １４ 複製管理部， １５ 登録部， １７ データ構成部，１８ 伝送部， ２１ 受信部， ２２ 選択部， ２３ データベース， ２４ 通信制御部， ２５ 要求部， ２６ 読み出し部， ２７ 出力部， ２８ 操作部
【発明の属する技術分野】
本発明は、受信装置および受信方法に関し、特に、例えば、分散型データベースにおける多数のデータベースへのデータの配信を行う場合や、ＩＰ（Internet Protocol）マルチキャストによりデータを配信する場合、その他データを不特定多数に配信する場合などに用いて好適な受信装置および受信方法に関する。
【０００２】
【従来の技術】
データの配信手法としては、種々の手法が提案されているが、例えば、現在のインターネット上においては、ＨＴＴＰ（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 and Decoder）やＳＴＢ(Set Top Box)などでなる受信端末５に対して送信される。
【００３３】
即ち、サブジェクトが生成され、その取得のためのイベント（そのサブジェクトと同一の識別子が付加されたイベント）が生成されると、基本的には、まず最初に、イベントが、放送ネットワーク４を介して送信される。さらに、このようにして送信されたイベントの中に、サブジェクトの放送時刻やチャンネルなどが記述されたものがある場合には、その放送時刻に、そのチャンネルで、サブジェクトが、放送ネットワーク４を介して送信される。
【００３４】
ここで、サーバ２においては、例えば、サブジェクトの送信スケジュールがたてられ（放送時刻および放送チャンネルなどが決められ）、その送信スケジュールにしたがって、イベントに、そのサブジェクトの放送時刻や放送チャンネルなどが記述される。そして、そのイベントの送信スケジュールがたてられる。
【００３５】
また、サブジェクトが、例えば、ＵＲＬに対応付けられ、サーバ２やミラーサーバ７の管理下におかれる場合には、そのＵＲＬを含むイベントが生成され、放送ネットワーク４を介して送信される。即ち、サブジェクトがサーバ２またはミラーサーバ７の管理下におかれる場合には、それぞれ、サーバ２またはミラーサーバ７のＩＰアドレスをドメイン名として有するＵＲＬを含むイベントが生成されて送信される。
【００３６】
以上のようにして放送ネットワーク４を介して送信（配信）されてくるイベントは、ユーザの受信端末５で受信される。受信端末５では、受信したイベントのうち、ユーザが所望するオブジェクトについてのものが選択され、その選択されたイベントに基づいて、サブジェクトが取得される。
【００３７】
即ち、例えば、イベントに、サブジェクトの放送時刻やチャンネルが含まれている場合には、サーバ２において、上述したように、その放送時刻に、そのチャンネルで、サブジェクトが、放送ネットワーク４を介して送信されてくるから、受信端末５では、そのようにして送信されてくるサブジェクトが受信される。
【００３８】
また、例えば、イベントに、サブジェクトに対応付けられたＵＲＬが含まれている場合には、受信端末５は、そのＵＲＬのドメイン名に対応するサーバに対して、通信ネットワーク６を介してアクセスし、サブジェクトを要求して受信する。
【００３９】
具体的には、イベントに含まれるＵＲＬのドメイン名に対応するサーバが、例えば、サーバ２であれば、サブジェクトは、サーバ２の管理下におかれているから、受信端末５は、通信ネットワーク６を介して、サーバ２にアクセスし、サブジェクトを取得する。
【００４０】
また、イベントに含まれるＵＲＬのドメイン名に対応するサーバが、例えば、ミラーサーバ７であれば、サブジェクトは、ミラーサーバ７の管理下におかれているから、受信端末５は、通信ネットワーク６を介して、ミラーサーバ７にアクセスし、サブジェクトを取得する。
【００４１】
受信端末５は、以上のようにしてサブジェクトを取得した後、そのサブジェクトに基づいて、自身が記憶しているオブジェクトを更新する。
【００４２】
なお、サブジェクトは、サーバ２から放送ネットワーク４を介して送信されるとともに、サーバ２やミラーサーバ７の管理下にもおかれることがある。さらに、図１の実施の形態では、１のミラーサーバ７だけを図示してあるが、ミラーサーバ７と同様の処理を行うミラーサーバは、通信ネットワーク６上に複数台設けることができ、この場合、サブジェクトは、その複数のミラーサーバの管理下におくこともできる。また、サブジェクトは、サーバ２から放送ネットワーク４を介して、あるチャンネルの、ある時刻においてだけ送信されるのではなく、複数のチャンネルや複数の時刻に送信される場合もある。
【００４３】
このように、あるサブジェクトを取得する方法が複数ある場合には、イベントには、その複数の方法それぞれについての情報（放送時刻や、放送チャンネル、ＵＲＬなど）が含められるが、このうちのいずれの方法によってサブジェクトを取得するかは、受信端末５において決定される。即ち、例えば、イベントに、放送ネットワーク４を介してサブジェクトを送信する時刻が複数含まれている場合には、受信端末５では、例えば、現在時刻に最も近い時刻に放送されてくるサブジェクトが受信されることで、サブジェクトが取得される。また、例えば、イベントに、複数のＵＲＬが含まれている場合には、受信端末５から最も近い位置にあるサーバのものが選択され、そのサーバに対して、通信ネットワーク６を介して、サブジェクトの要求が行われることにより、サブジェクトが取得される。さらに、例えば、イベントに、放送ネットワーク４を介してサブジェクトを送信する時刻と、ＵＲＬとが含まれている場合において、例えば、放送ネットワーク４の回線状態が悪いとき（Ｓ／Ｎ（Signal/Noise）が低いときなど）には、ＵＲＬに基づき、上述したようにして、サブジェクトが取得される。また、その他、いずれの方法によってサブジェクトを取得するかは、受信端末５のユーザの操作などに基づいて決定するようにすることもできる。
【００４４】
以上のようなデータ配信システムによれば、サブジェクトの取得方法が記述されたイベントが、放送ネットワーク４を介して配信され、受信端末５において、そのイベントに基づき、サブジェクトが取得され、オブジェクトの更新が行われるので、受信端末５の負荷の増大を抑えつつ、効率的なデータ配信を行うことができる。
【００４５】
即ち、一般に、オブジェクトの更新（特に、オブジェクトの変更と新規登録）のための更新オブジェクト情報を含むサブジェクトのデータ量は多く、さらに、サブジェクトは、オブジェクトの更新に対応して生成されるため、いつ発生するか分からない。従って、そのような不定期に発生し、かつデータ量の多いサブジェクトだけを、なるべく早期に、放送ネットワーク４を介して送信するとすれば、サーバ２は、現時点において空いているチャンネルを使用して、サブジェクトを送信する必要がある。しかしながら、この場合、受信端末５では、いつ、どのチャンネルで送信されてくるか分からないサブジェクトを待つ必要があり、負担が大になる。
【００４６】
これに対して、イベントは、サブジェクトの取得方法の記述を含むものであるから、一般に、そのデータ量は、更新オブジェクト情報を含むサブジェクトよりも、はるかに少なく、このため、例えば、ある狭帯域のチャンネルの、さらには、決まった時間において送信することが可能である。従って、この場合、受信端末５では、そのチャンネルにおいて（さらには、決まった時間に送信されてくる）イベントを受信すれば良く、その負荷は、サブジェクトの送信を待つ場合に比較して、はるかに小さくなる。
【００４７】
さらに、本実施の形態では、イベントが、広い地域に亘って一斉同報が可能な放送ネットワーク４を介して送信されるため、受信端末５の数の増加が、サーバ２や放送ネットワーク４の負荷に影響を与えることもない。
【００４８】
そして、本実施の形態では、サブジェクトは、通信ネットワーク６を介して提供されるだけでなく、放送ネットワーク４を介しても提供されるので、サブジェクトの取得のために、サーバ２やミラーサーバ７にアクセスが集中することはほとんどなく、従って、サブジェクトの効率的な配信が可能となる。
【００４９】
なお、放送ネットワーク４と通信ネットワーク６とは、物理的に別々のネットワークである必要はない。即ち、放送ネットワーク４を、例えば、ＣＡＴＶ網で構成する場合においては、そのＣＡＴＶ網は通信ネットワーク６として利用することも可能である。また、放送ネットワーク４によるデータの配信を、例えば、インターネットなどを利用したＩＰ（Internet Protocol）マルチキャストで行う場合においては、通信ネットワーク６は、そのインターネットで構成することも可能である。
【００５０】
さらに、サーバ２からの受信端末５へのデータ（イベントおよびサブジェクト）の送信は、例えば、スクランブルをかけて行い、これにより、特定のユーザ（受信契約を結んだユーザ）のみ、データの受信が可能なようにすることも可能である。
【００５１】
次に、図２は、図１のサーバ２の構成例を示している。
【００５２】
通信制御部１１は、例えば、モデムや、ＴＡ（Terminal Adapter）などで構成され、通信ネットワーク６を介しての通信を制御するようになされている。資源割当部１２は、放送ネットワーク４を介してのデータの送信のための資源割当を行うようになされている。即ち、資源割当部１２は、登録部１５からのオブジェクトの更新の知らせを受け、その更新に伴い、イベントおよびサブジェクトを、放送ネットワーク４を介して送信するための資源の割当（例えば、イベントおよびオブジェクトの送信チャンネルや、送信時刻（時間）、データレート、送信回数（送信頻度）などの決定）を行うようになされている。資源割当部１２によるイベントおよびサブジェクトの送信のための資源の割当結果は、データ構成部１７および伝送部１８に供給されるようになされている。
【００５３】
データ検索部１３は、通信ネットワーク６を介して受信端末５から送信されているサブジェクトの要求を、通信制御部１１から受信し、そのサブジェクトを構成する更新オブジェクト情報を、データベース３から検索する。そして、データ検索部１３は、後述するデータ構成部１７と同様にして、サブジェクトを構成し、通信制御部１１に供給するようになされている。複製管理部１４は、ミラーサーバ７（さらには、通信ネットワーク６上の、図示せぬミラーサーバ）を特定するための情報を管理している。即ち、複製管理部１４は、例えば、通信ネットワーク４がインターネットである場合には、ミラーサーバ７のＩＰアドレスを記憶している。そして、複製管理部１４は、登録部１５からのオブジェクトの更新の知らせを受けると、その更新のための更新オブジェクト情報を、データベース３から読み出し、通信制御部１１を制御することで、その更新オブジェクト情報を、例えば、ミラーサーバ７その他の自身が管理しているＩＰアドレスの、通信ネットワーク６上のサーバに送信するようになされている。なお、複製管理部１４は、自身が管理している情報を、必要に応じて、データ構成部１７に供給するようにもなされている。
【００５４】
登録部１５は、情報提供者Ａ乃至Ｃのデータベース１ａ乃至１ｃから供給される更新オブジェクト情報を受信し、その更新オブジェクト情報に基づいて、オブジェクト（データベース３）を更新するようになされている。即ち、情報提供者Ａ乃至Ｃのデータベース１ａ乃至１ｃからは、更新オブジェクト情報とともに、その更新オブジェクト情報によって更新されるオブジェクトの識別子も供給されるようになされている。登録部１５は、この更新オブジェクト情報および識別子を受信し、その識別子に対応するオブジェクトを、データベース３から検索する。さらに、登録部１５は、そのようにして検索したオブジェクトを、更新オブジェクト情報に基づいて更新し、その後、オブジェクトを更新した旨を、資源割当部１２、複製管理部１４、およびデータ構成部１７に出力する。なお、登録部１５は、データベース１ａ乃至１ｃからの更新オブジェクト情報および識別子も、データベース３に登録するようになされている。
【００５５】
データ構成部１７は、登録部１５からオブジェクトを更新した旨を受信すると、その更新がなされたオブジェクトについての更新オブジェクト情報を、データベース３から読み出し、その更新オブジェクト情報が配置されたサブジェクトを生成して、伝送部１８に出力するようになされている。さらに、データ構成部１７は、そのサブジェクトを取得するためのイベントも生成し、伝送部１８に出力するようになされている。なお、データ構成部１７において、イベントの生成は、資源割当部１２による資源の割当結果や、複製管理部１４から供給される情報を用いて行われるようになされている。即ち、データ構成部１７は、サブジェクトが送信されるチャンネルや時刻、データレート、さらには、それを管理するサーバに関する情報その他を、資源割当部１２による資源の割当結果や、複製管理部１４からの情報から認識し、イベントに含めるようになされている。
【００５６】
伝送部１８は、データ構成部１７からのイベントやサブジェクトを、資源割当部１２の資源の割当結果にしたがって、即ち、例えば、所定のチャンネルで、所定の時刻に、所定のデータレートなどで、放送ネットワーク４を介して送信するようになされている。
【００５７】
次に、図３は、図１のミラーサーバ７の構成例を示している。なお、図中、図２のサーバ２における場合と対応する部分については、同一の符号を付してある。即ち、ミラーサーバ７は、資源割当部１２、複製管理部１４、データ構成部１７、および伝送部１８が設けられていない他は、基本的に、サーバ２と同様に構成されている。なお、ミラーサーバ７を構成する登録部１５には、サーバ２を構成する複製管理部１４が、通信制御部１１を制御することにより、通信ネットワーク６などを介して送信されてくる更新オブジェクト情報が供給されるようになされている。
【００５８】
以上のように構成されるサーバ２では、データベース３にデータを登録（データベースの登録内容を更新）する登録処理、サブジェクトおよびイベントを生成し、放送ネットワーク４を介して伝送するデータ伝送処理、および受信端末５から通信ネットワーク６を介してサブジェクトの要求があった場合に、そのサブジェクトを通信ネットワーク６を介して送信する要求データ送信処理などが行われ、また、ミラーサーバ７では、登録処理および要求データ送信処理などが行われるようになされている。
【００５９】
まず、図４のフローチャートを参照して、サーバ２が行う登録処理について説明する。
【００６０】
登録処理では、まず最初に、ステップＳ１において、情報提供者Ａ乃至Ｃのデータベース１ａ乃至１ｃのうちのいずれかから更新オブジェクト情報と識別子が配信されてきたか否かが、登録部１５によって判定され、配信されてきていないと判定された場合、ステップＳ１に戻る。また、ステップＳ１において、更新オブジェクト情報および識別子が配信されてきたと判定された場合、ステップＳ２に進み、登録部１５は、例えば、その更新オブジェクト情報に、その識別子を付加し、データベース３に登録する。
【００６１】
ここで、データベース１ａ乃至１ｃからは、更新オブジェクト情報と識別子とが、例えば、図５に示すようなフォーマットで供給されるようになされている。
【００６２】
識別子は、ここでは、例えば、交通情報や、天気情報、株価情報、さらには、それらの情報を構成する構成要素などのオブジェクトの種類ごとにあらかじめ割り当てられているユニークなＩＤ（Identifier）、およびオブジェクトの新しさを示すバージョン情報などからなる。バージョン情報は、例えば、オブジェクトが更新されるごとに１ずつインクリメントされる整数値などが用いられるようになされており、従って、同一のＩＤが付加されているオブジェクトについては、そのバージョン情報を比較することで、最新のオブジェクトを認識することができる。
【００６３】
なお、ＩＤおよびバージョン情報は、ここでは、例えば、ともに固定長とされている。
【００６４】
登録部１５は、データベース１ａ乃至１ｃから配信されてきた更新オブジェクト情報に、同じくデータベース１ａ乃至１ｃから配信されてきた識別子を付加する（対応付ける）と、さらに、ステップＳ２において、その識別子を構成するＩＤと同一のＩＤを有する識別子が付加されているオブジェクトを、データベース３から検索し、更新オブジェクト情報に基づいて更新する。そして、登録部１５は、その更新したオブジェクトに付加されている識別子のバージョン情報を、例えば、１だけインクリメントする。
【００６５】
その後、登録部１５は、ステップＳ３において、オブジェクトが更新された旨を、資源割当部１２、複製管理部１４、およびデータ構成部１７に出力し、ステップＳ１に戻る。
【００６６】
以上のようにして供給されるオブジェクトが更新された旨を受信した複製管理部１４では、ステップＳ２でデータベース３に登録された更新オブジェクト情報およびそれに付加されている識別子が読み出され、自身が管理しているサーバ、即ち、ここでは、例えば、ミラーサーバ７に対し、通信ネットワーク６を介して送信される。また、複製管理部１４は、更新オブジェクト情報および識別子を送信したサーバを特定するための特定情報、即ち、ここでは、例えば、ミラーサーバ７のＩＰアドレスを、データ構成部１７に出力する。
【００６７】
なお、ミラーサーバ７では、図３のステップＳ１乃至Ｓ３のうちのステップＳ３を除いた処理が、登録処理として行われる。即ち、ミラーサーバ７では、ステップＳ１において、サーバ２から更新オブジェクト情報と識別子が配信されてきたか否かが、登録部１５によって判定され、配信されてきていないと判定された場合、ステップＳ１に戻る。また、ステップＳ１において、更新オブジェクト情報および識別子が配信されてきたと判定された場合、ステップＳ２に進み、ミラーサーバ７の登録部１５は、更新オブジェクト情報に、識別子を付加し、データベース８に登録する。さらに、ミラーサーバ７の登録部１５は、ステップＳ２において、サーバ２から受信した識別子を構成するＩＤと同一のＩＤを有する識別子が付加されているオブジェクトを、データベース８から検索し、そのオブジェクトを、サーバ２から受信した更新オブジェクト情報に基づいて更新する。そして、ミラーサーバ７の登録部１５は、その更新したオブジェクトに付加されている識別子のバージョン情報を、１だけインクリメントし、ステップＳ３をスキップして、ステップＳ１に戻る。
【００６８】
サーバ２において、上述したような登録処理が行われることにより、そのステップＳ３において登録部１５が出力するオブジェクトが更新された旨は、複製管理部１４に供給される他、資源割当部１２およびデータ構成部１７にも供給される。
【００６９】
資源割当部１２は、オブジェクトが更新された旨を受信すると、その更新に関するイベントおよびサブジェクトを、放送ネットワーク４を介して送信するための資源の割当を行い、その割当結果を、データ構成部１７および伝送部１８に出力する。データ構成部１７は、オブジェクトが更新された旨を受信すると、その更新がなされたオブジェクトについての更新オブジェクト情報を、データベース３から読み出し、サブジェクトを生成して、伝送部１８に出力する。さらに、データ構成部１７は、そのサブジェクトを取得するためのイベントを、資源割当部１２の資源割当結果や、複製管理部１４からの情報（例えば、上述したように、ミラーサーバ７のＩＰアドレス）を用いて生成し、伝送部１８に出力する。そして、伝送部１８では、データ構成部１７からのイベントやサブジェクトが、資源割当部１２の資源の割当結果にしたがって、放送ネットワーク４を介して送信される。即ち、資源割当部１２、データ構成部１７、および伝送部１８では、図６に示すようなデータ伝送処理が行われる。
【００７０】
即ち、データ伝送処理では、まず最初に、ステップＳ１１において、資源割当処理が行われる。具体的には、ステップＳ１１では、資源割当部１２において、オブジェクトが更新された旨を受信すると、その更新に関するイベントおよびオブジェクトを、放送ネットワーク４を介して送信するための放送チャンネルや、放送時刻、データレート、送信回数などを決定する。これらの資源割当結果は、データ構成部１７および伝送部１８に供給される。
【００７１】
そして、ステップＳ１２において、データ構成部１７は、イベントおよびサブジェクトを生成する。即ち、データ構成部１７は、データベース３から、オブジェクトの更新に用いられた更新オブジェクト情報と、それに付加されている識別子とを読み出し、例えば、図７（Ａ）に示すようなサブジェクトを構成する。なお、図７（Ａ）においては（同図（Ｂ）においても同様）、バージョン情報の直後に、判別フラグが配置されているが、この判別フラグは、データがサブジェクトか、またはイベントであるかを表す。
【００７２】
また、データ構成部１７は、サブジェクトについて、そのサブジェクトに付加されている識別子と同一の識別子を付加した、例えば、図７（Ｂ）に示すようなイベントを構成する。即ち、イベントは、サブジェクトに付加されている識別子と同一の識別子に、判別フラグ、放送スケジュール情報、およびサーバアクセス情報を順次配置して構成される。
【００７３】
放送スケジュール情報は、サブジェクトが、放送ネットワーク４を介して放送される場合に、それを受信するのに必要な情報で、これには、資源割当部１２からの資源割当結果であるサブジェクトの放送チャンネル、放送時刻（時間）、データレート、送信回数などが含まれる。従って、イベントを構成する放送スケジュール情報を参照することで、そのイベントを構成する識別子のオブジェクトを更新するためのサブジェクトの放送チャンネルや放送時刻などを認識することができ、これにより、そのサブジェクトを受信することが可能となる。
【００７４】
サーバアクセス情報は、サブジェクトが、サーバ２やミラーサーバ７から通信ネットワーク６を介して送信される場合に、通信ネットワーク６を介して、そのサブジェクトを要求するのに必要な情報で、これには、例えば、サーバ２やミラーサーバ７のＩＰアドレスなどが含まれる。そして、このＩＰアドレスなどは、サーバ２やミラーサーバ７を特定するための特定情報として、複製管理部１４からデータ構成部１７に供給されるようになされている。
【００７５】
即ち、サーバ２やミラーサーバ７は、データベース３や８に記憶された更新オブジェクト情報およびそれに付加されている識別子とから、図７（Ａ）に示したサブジェクトを構成し、受信端末５からの要求に対応して、そのサブジェクトを、通信ネットワーク６を介して送信するようになされており、このようにして、サブジェクトを取得する場合に、サーバアクセス情報が参照される。
【００７６】
ここで、サーバ２やミラーサーバ７においては、更新オブジェクト情報およびそれに付加されている識別子から構成されるサブジェクトに、例えば、その識別子をＩＰアドレスに付加して構成されるＵＲＬを対応付けて、サブジェクトの管理が行われるようになされている。この場合、イベントを受信した受信端末５では、そのイベントを構成するサーバアクセス情報と識別子とから、そのイベントと同一の識別子が付加されているサブジェクトのＵＲＬを認識することができる。
【００７７】
なお、サブジェクトは、放送ネットワーク４を介してのみ提供することが可能であるが、この場合には、そのサブジェクトについてのイベントには、サーバアクセス情報は配置されない。逆に、サブジェクトは、通信ネットワーク６を介してのみ提供することも可能であるが、この場合には、そのサブジェクトについてのイベントには、放送スケジュール情報は配置されない。
【００７８】
また、サブジェクトが、放送ネットワーク４を介して、複数のチャンネルや、複数の時刻に送信される場合には、そのサブジェクトについてのイベントには、その複数のチャンネルや複数の時刻それぞれに対応する放送スケジュール情報が配置される。同様に、サブジェクトが、通信ネットワーク６を介して、複数のサーバから提供され得る場合には、そのサブジェクトについてのイベントには、その複数のサーバそれぞれに対応するサーバアクセス情報が配置される。
【００７９】
なお、放送スケジュール情報とサーバアクセス情報の両方が存在する場合や、放送スケジュール情報またはサーバアクセス情報が複数存在する場合には、それらのすべてを、１のイベントに含めるのではなく、それらの１つごとに、イベントを生成しても良い。
【００８０】
図６に戻り、ステップＳ１２において、以上のようなイベントおよびサブジェクトが生成されると、そのイベントやサブジェクトは、データ構成部１７から伝送部１８に供給される。伝送部１８では、ステップＳ１３において、データ構成部１７からのイベントやサブジェクトが、資源割当部１２からの資源割当結果にしたがって、放送ネットワーク４を介して送信される。即ち、イベントやサブジェクトは、例えば、所定の送信チャンネルで、所定の送信時刻に、所定のデータレートで、放送ネットワーク４を介して送信され、ステップＳ１４に進む。
【００８１】
ステップＳ１４では、データ構成部１７からのイベントやサブジェクトの送信を、資源割当部１２からの資源割当結果に含まれる送信回数だけ繰り返し行ったかどうかが、伝送部１８によって判定され、行っていないと判定された場合、ステップＳ１３に戻り、イベントやサブジェクトの伝送が繰り返される。即ち、放送ネットワーク４によるデータの送信は、サーバ２から受信端末５の一方向にのみ行われるため、それらの間で、データの送受信が正確に行われたかどうかの確認を行うことができない。そこで、サーバ２では、データの送信が、資源割当部１２による資源の割当結果である送信回数だけ繰り返されるようになされており、これにより、受信端末５において、正確なデータの受信が行われる確率を向上させるようになされている。
【００８２】
一方、ステップＳ１４において、データ構成部１７からのイベントやサブジェクトの送信を、資源割当部１２からの資源割当結果に含まれる送信回数だけ繰り返し行ったと判定された場合、データ伝送処理を終了する。
【００８３】
なお、上述したように、一般に、イベントはデータ量が少なく、サブジェクトはデータ量が多いから、資源割当部１２では、送信回数は、基本的に、イベントについては多くなり、サブジェクトについては少なくなるように、資源割当が行われる。従って、受信端末５において、放送ネットワーク４を介して送信されてくるイベントを取りこぼす確率（受信できない確率）は小さくなり、さらに、イベントを正常受信することができれば、例えば、それに含まれる放送スケジュール情報を参照することで、サブジェクトが、放送ネットワーク４を介して送信されてくるチャンネルや時刻などを認識することができ、その結果、送信回数の少ないイベントを取りこぼす確率も小さくすることができる。また、仮に、イベントに基づいて、放送チャンネルや放送時刻などを認識したサブジェクトの受信に失敗した場合であっても、あるいは、放送時刻より先に、サブジェクトを必要とする場合などであっても、イベントに、サーバアクセス情報が含まれていれば、そのサーバアクセス情報に基づき、通信ネットワーク６を介して、サーバ２やミラーサーバ７にアクセスすることで、サブジェクトを、早期、かつ確実に取得することができる。
【００８４】
次に、図８のフローチャートを参照して、サーバ２やミラーサーバ７で行われる要求データ送信処理について説明する。
【００８５】
この場合、ステップＳ２１において、受信端末５から通信ネットワーク６を介して、サブジェクトの要求としての、例えば、ＵＲＬが送信されてきたかどうかが、通信制御部１１によって判定され、送信されてきていないと判定された場合、ステップＳ２１に戻る。また、ステップＳ２１において、ＵＲＬが送信されてきたと判定された場合、通信制御部１１は、そのＵＲＬを、データ検索部１３に転送する。データ検索部１３は、ＵＲＬを受信すると、ステップＳ２２において、そのＵＲＬを構成するデータ識別子と同一の識別子が付加されている更新オブジェクト情報を検索する（サーバ２では、データベース２から検索し、ミラーサーバ７では、データベース８から検索する）。
【００８６】
即ち、本実施の形態では、上述したように、イベントを受信した受信端末５において、そのイベントを構成するサーバアクセス情報としてのＩＰアドレスと、識別子とから、そのイベントと同一の識別子が付加されているサブジェクトのＵＲＬが認識されるようになされている。そして、受信端末５は、通信ネットワーク６を介して、サブジェクトを要求する場合には、そのＵＲＬを送信するようになされている。従って、受信端末５からのＵＲＬには、識別子が含まれており、サーバ２やミラーサーバ７では、この識別子を、いわば、更新オブジェクト情報のファイル名として、その検索が行われる。
【００８７】
ステップＳ２２において、更新オブジェクト情報が検索されると、データ検索部１３は、その更新オブジェクトに、それとともに記憶されていた識別子を付加することにより、サブジェクトを構成し、通信制御部１１に供給する。通信制御部１１は、データ検索部１３からのサブジェクトを受信し、ステップＳ２３において、それを、ＵＲＬを送信してきた受信端末（ここでは、受信端末５）に、通信ネットワーク６を介して送信して、ステップＳ２１に戻る。
【００８８】
次に、図９は、図１の受信端末５の構成例を示している。
【００８９】
受信部２１は、サーバ２から放送ネットワーク４を介して送信されてくるデータ、即ち、ここでは、イベントやサブジェクトを受信し、選択部２２に出力するようになされている。選択部２２は、受信部２１からのイベントやサブジェクトの選択を行うようになされている。さらに、選択部２２は、選択したイベントをデータベース２３に一時記憶させるようにもなされている。また、選択部２２は、選択したサブジェクトに含まれる識別子と同一の識別子が付加されているオブジェクトを、データベース２３から検索し、そのサブジェクトに含まれる更新オブジェクト情報に基づいて更新するようにもなされている。
【００９０】
データベース２３は、例えば、大容量のハードディスクや光磁気ディスク、その他の記録媒体で構成され、オブジェクトを記憶し、また、選択部２２からのイベントを一時記憶するようになされている。
【００９１】
通信制御部２４は、通信ネットワーク６を介しての通信制御を行うようになされており、これにより、要求部２５からのサブジェクトの要求を、通信ネットワーク６を介してサーバ２やミラーサーバ７などに送信したり、また、サーバ２やミラーサーバ７などから通信ネットワーク６を介して送信されてくるサブジェクトを受信するようになされている。
【００９２】
要求部２５は、データベース２３に記憶されているイベントに含まれる放送スケジュール情報にしたがって、放送ネットワーク４を介して送信されてくるサブジェクトを受信するように、受信部２１を制御するようになされている。また、要求部２５は、データベース２３に記憶されたイベントに含まれるサーバアクセス情報にしたがい、通信ネットワーク６を介して、サーバ２やミラーサーバ７に、サブジェクトを要求し、その要求に対応して、サーバ２やミラーサーバ７から、通信ネットワーク６を介して送信されてくるサブジェクトを受信するように、通信制御部２４を制御するようにもなされている。さらに、要求部２５は、通信制御部２４に受信させたサブジェクトに含まれる識別子に対応するオブジェクトを、データベース２３から検索し、そのサブジェクトに含まれる更新オブジェクト情報に基づいて更新するようにもなされている。なお、要求部２５は、以上のような処理を、例えば、定期的に行う他、読み出し部２６から、オブジェクトの更新の要求があった場合などにも行うようになされている。
【００９３】
読み出し部２６は、操作部２８の操作に対応して、データベース２３に記憶されたオブジェクトを読み出し、出力部２７に供給するようになされている。出力部２７は、例えば、ディスプレイやスピーカなどで構成され、読み出し部２６などからのオブジェクトを表示し、または音声として出力するようになされている。操作部２８は、読み出し部２６に対して、所定の入力を与える場合などに操作される。
【００９４】
以上のように構成される受信端末５では、サーバ２から放送ネットワーク４を介して送信されてくるデータを受信する受信処理、データベース２３に記憶されたイベントに基づいて、サブジェクトを要求するデータ要求処理、およびデータベース２３に登録されたデータを出力する出力処理などが行われるようになされている。
【００９５】
まず、図１０のフローチャートを参照して、受信処理について説明する。
【００９６】
サーバ２から放送ネットワーク４を介してデータが送信されてくると、受信部２１では、ステップＳ３１において、そのデータ、即ち、イベントまたはサブジェクトが受信され、選択部２２に供給される。選択部２２では、ステップＳ３２において、受信部２１からのイベントまたはサブジェクトが選択すべきものであるかどうかが判定される。
【００９７】
即ち、サーバ２から放送ネットワーク４を介して送信されてくるすべてのイベントやサブジェクトを受信するとした場合には、データベース２３として、記憶容量の膨大なものが必要となる。また、ユーザには好みがあり、各ユーザが、サーバ２のデータベース３に記憶されたオブジェクトすべてを必要としていることはほとんどない。それにもかかわらず、サーバ２のデータベース３の登録内容すべてを、データベース２３に反映するのは好ましくない。
【００９８】
そこで、選択部２２に、例えば、ユーザが所望するオブジェクトについてのＩＤ（上述した識別子を構成するＩＤ）を登録しておくと、選択部２２は、そのＩＤと同一のＩＤを有するイベントおよびオブジェクトだけを選択するようになされている。従って、ステップＳ３２における判定は、ユーザが登録したＩＤと、受信部２１から供給されるイベントやサブジェクトの識別子を構成するＩＤとを比較することで行われる。
【００９９】
ステップＳ３２において、受信部２１からのイベントまたはサブジェクトが選択すべきものでないと判定された場合、即ち、例えば、ユーザが登録したＩＤと、受信部２１から供給されたイベントまたはサブジェクトに記述されているＩＤとが一致しない場合、次のイベントまたはサブジェクトが、放送ネットワーク４を介して送信されてくるのを待って、ステップＳ３１に戻る。従って、この場合、イベントはデータベース２３に記憶されず、また、サブジェクトに基づくデータベース２３の更新も行われない。
【０１００】
一方、ステップＳ３２において、受信部２１からのイベントまたはサブジェクトが選択すべきものであると判定された場合、即ち、例えば、ユーザが登録したＩＤと、受信部２１から供給されたイベントまたはサブジェクトに記述されているＩＤとが一致する場合、ステップＳ３３に進み、選択部２２は、そのイベントまたはサブジェクトが、新規のオブジェクトに関するものかどうかを判定する。
【０１０１】
ステップＳ３３において、ステップＳ３２で選択されたイベントまたはサブジェクトが、新規のオブジェクトに関するものであると判定された場合、即ち、そのイベントまたはサブジェクトに含まれているＩＤと同一のＩＤのオブジェクトが、データベース２３に登録されていない場合、ステップＳ３４をスキップして、ステップＳ３５に進む。
【０１０２】
また、ステップＳ３３において、ステップＳ３２で選択されたイベントまたはサブジェクトが、新規のオブジェクトに関するものでないと判定された場合、即ち、そのイベントまたはサブジェクトに含まれているＩＤと同一のＩＤのオブジェクトが、データベース２３に登録されている場合、ステップＳ３４に進み、選択部２２において、その既にデータベース２３に登録されているオブジェクト（以下、適宜、既登録オブジェクトという）の識別子に記述されているバージョン情報が、ステップＳ３２で選択されたイベントまたはサブジェクトの識別子に記述されているバージョン情報と等しいかどうかが判定される。
【０１０３】
ステップＳ３４において、既登録オブジェクトに記述されているバージョン情報が、ステップＳ３２で選択されたイベントまたはサブジェクトに記述されているバージョン情報と等しい場合、即ち、ここでは、図６のデータ伝送処理で説明したように、信頼性を向上させるため、サーバ２からは、同一のサブジェクトが放送ネットワーク４を介して繰り返し送信されるが、そのように繰り返し行われる送信のうちの、過去に行われた送信によるサブジェクトによって、既登録オブジェクトの更新が、既に行われている場合、ステップＳ３５乃至Ｓ３７をスキップし、次に、イベントまたはサブジェクトが送信されてくるのを待って、ステップＳ３１に戻る。従って、この場合、イベントは、データベース２３に記憶されず、また、サブジェクトに基づくデータベース２３の更新も行われない。
【０１０４】
一方、ステップＳ３４において、既登録オブジェクトに記述されているバージョン情報が、ステップＳ３２で選択されたイベントまたはサブジェクトに記述されているバージョン情報と等しくないと判定された場合、即ち、イベントまたはサブジェクトが、新たなバージョンのオブジェクトに関するものである場合、ステップＳ３５に進み、選択部２２において、ステップＳ３２で選択されたデータが、イベントまたはサブジェクトのうちのいずれであるかが、判別フラグを参照することで判定される。
【０１０５】
ステップＳ３５において、ステップＳ３２で選択されたデータがサブジェクトであると判定された場合、ステップＳ３６に進み、選択部２２は、そのサブジェクトに基づき、データベース２３を更新する。
【０１０６】
即ち、サブジェクトにおいて、更新オブジェクト情報として、新規のオブジェクトが配置されている場合には、サブジェクトに含まれる識別子に、その新規のオブジェクトが対応付けられ、データベース２３に新規登録される。
【０１０７】
また、サブジェクトにおいて、更新オブジェクト情報として、更新後のオブジェクトが配置されている場合には、サブジェクトに含まれるＩＤと同一のＩＤを有する識別子が対応付けられたオブジェクトが、データベース２３から検索され、その検索されたオブジェクトが、更新後のオブジェクトに変更される。さらに、そのオブジェクトに対応付けられていたバージョン情報が、例えば、１だけインクリメントされる。
【０１０８】
さらに、サブジェクトにおいて、更新オブジェクト情報として、オブジェクトの削除指令が配置されている場合には、サブジェクトに含まれるＩＤと同一のＩＤを有する識別子が対応付けられたオブジェクトが、データベース２３から検索され、そのオブジェクトに対応付けられている識別子とともに削除される。
【０１０９】
なお、上述の図４で説明した登録処理のステップＳ２において行われる、更新オブジェクト情報に基づくオブジェクトの更新も、これと同様にして行われる。
【０１１０】
ステップＳ３６において、以上のようにして、データベース２３の更新が行われた後は、次に、イベントまたはサブジェクトが送信されてくるのを待って、ステップＳ３１に戻る。
【０１１１】
一方、ステップＳ３５において、ステップＳ３２で選択されたデータがイベントであると判定された場合、ステップＳ３７に進み、選択部２２は、そのイベントを、データベース２３に供給して一時記憶させる。そして、次に、イベントまたはサブジェクトが送信されてくるのを待って、ステップＳ３１に戻る。
【０１１２】
なお、ステップＳ３７において、データベース２３に記憶されたイベントは、後述するデータ要求処理（図１１）や、データ出力処理（図１２）において、要求部２５によって、データベース２３から読み出された後に消去されるようになされている。
【０１１３】
次に、図１１を参照して、データ要求処理について説明する。なお、このデータ要求処理は、受信端末５において定期的に行われる。但し、データ要求処理は、不定期に行うことも可能である。
【０１１４】
データ要求処理では、まず最初に、ステップＳ４１において、データベース２３の登録内容が、要求部２５によって検索され、ステップＳ４２に進み、データベース２３に、イベントが記憶されているかどうかが判定される。ステップＳ４２において、イベントが記憶されていないと判定された場合、データ要求処理を終了する。
【０１１５】
また、ステップＳ４２において、データベース２３にイベントが記憶されていると判定された場合、そのイベントが読み出され（複数のイベントが記憶されている場合には、そのうちの１つが読み出され）、ステップ４３に進み、要求部２５において、そのイベントに基づくサブジェクトの受信を、同報可能な放送ネットワーク４または双方向通信が可能な通信ネットワーク６のうちのいずれを介して行うのが有利かが判定される。
【０１１６】
ここで、ステップＳ４３の判定は、例えば、次のようにして行われる。
【０１１７】
即ち、要求部２５では、イベントに含まれる放送スケジュール情報を参照することにより、そのイベントに付加されている識別子と同一の識別子のサブジェクトが送信されてくる送信回数（送信頻度）や、送信時刻が認識される。そして、例えば、送信回数が多い場合や、送信時刻が、現在時刻に近い場合には、サブジェクトの受信時間その他の受信のためのコストが低いと予想される放送ネットワーク４を介して、サブジェクトの受信を行うのが有利であると判定される。
【０１１８】
また、例えば、送信回数が少ない場合や、送信時刻が、現在時刻から離れている場合には、双方向ネットワーク６を介して、サブジェクトの受信を行うのが有利であると判定される。
【０１１９】
なお、その他、例えば、イベントに含まれる放送スケジュール情報に、サブジェクトのデータ量が記述されている場合には（データ量そのものが記述されていなくても、データレートと、送信に要する時間とが記述されていれば、データ量を認識することができる）、そのデータ量に基づき、放送ネットワーク４または通信ネットワーク６のうちのいずれを介して、サブジェクトの受信を行うのが有利であるのかを判定することも可能である。
【０１２０】
さらに、放送ネットワーク４または通信ネットワーク６のうちのいずれを介して、サブジェクトの受信を行うのが有利であるのかは、ユーザに操作部２８を操作してもらい、その操作に対応して決定することも可能である。
【０１２１】
また、双方向ネットワーク６を介してサブジェクトを受信する場合において、双方向ネットワーク６が、複数の伝送レートに対応しており、受信端末５が、そのような複数の伝送レートの回線を介しての通信の可能なものであるときには、サブジェクトのデータ量によって、使用する回線を変えるようにすることも可能である。
【０１２２】
ここで、上述したように、イベントには、放送スケジュール情報またはサーバアクセス情報のうちのいずれか一方しか含まれていない場合がある。イベントに、放送スケジュール情報しか含まれていない場合、ステップＳ４３では、放送ネットワーク４を介して、サブジェクトの受信を行うのが有利であると判定される。また、逆に、イベントに、サーバアクセス情報しか含まれていない場合は、ステップＳ４３では、通信ネットワーク６を介して、サブジェクトの受信を行うのが有利であると判定される。
【０１２３】
ステップＳ４３において、放送ネットワーク４を介して、サブジェクトの受信を行うのが有利であると判定された場合、ステップＳ４４に進み、要求部２５は、受信部２１が動作可能な状態であるかどうか（例えば、電源が供給されているかどうか（スリープ状態にないかどうか））を判定する。ステップＳ４４において、受信部２１が動作可能な状態にないと判定された場合、ステップＳ４５に進み、要求部２５は、例えば、イベントの放送スケジュール情報に配置されているサブジェクトの送信時刻の直前まで待って、受信部２１を動作可能な状態にし、即ち、受信部２１がスリープ状態になっている場合には、電源の供給を開始し、ステップＳ４６に進む。
【０１２４】
また、ステップＳ４４において、受信部２１が動作可能な状態にあると判定された場合、ステップＳ４５をスキップして、ステップＳ４６に進み、要求部２１は、受信部２１を制御することにより、データベース２３から読み出したイベントの放送スケジュール情報に配置されている送信チャンネルで、同じくその放送スケジュール情報に配置されている送信時刻に、放送ネットワーク４を介して送信されてくるサブジェクト、即ち、イベントに付加されている識別子と同一の識別子のサブジェクトを受信させ、選択部２２に供給させる。そして、ステップＳ４７において、選択部２２では、図１０のステップＳ３６における場合と同様にして、受信部２１からのサブジェクトに基づき、データベース２３の更新が行われ、データ要求処理を終了する。
【０１２５】
ここで、受信端末５において、データの取りこぼしは、受信部２１の電源がオフ状態になっていることに起因して生じることが多い。そこで、上述のように、受信部２１が動作可能な状態になっているかどうかを判定し、なっていない場合には、受信部２１を動作可能な状態にすることで、受信部２１の電源がオフ状態になっていることに起因するサブジェクトの取りこぼしを防止することができる。
【０１２６】
一方、ステップＳ４３において、双方向ネットワーク６を介して、サブジェクトを受信するのが有利であると判定された場合、ステップＳ４８に進み、要求部２５は、通信制御部２４を制御することで、データベース２３から読み出したイベントに含まれる識別子と同一の識別子が付加されているサブジェクトを、通信ネットワーク６を介して、サーバ２やミラーサーバ７に要求させる。
【０１２７】
即ち、要求部２５は、データベース２３から読み出したイベントに含まれる識別子と、同じくそこに含まれるサーバアクセス情報（ここでは、上述したように、ＩＰアドレス）とから、その識別子と同一の識別子が付加されているサブジェクトに対応付けられているＵＲＬを構成し、通信制御部２４を制御することで、通信ネットワーク６を介して、サーバ２やミラーサーバ７に送信させる。
【０１２８】
ＵＲＬが送信されたサーバ２やミラーサーバ７では、図８で説明した要求データ送信処理が行われ、これにより、そのＵＲＬに対応付けられているサブジェクトが、通信ネットワーク６を介して送信されてくる。このサブジェクトは、ステップＳ４９において、通信制御部２４によって受信され、要求部２５に供給される。要求部２５は、通信制御部２４からサブジェクトを受信すると、ステップＳ４７に進み、上述したようにして、そのサブジェクトに基づき、データベース２３の更新を行い、データ要求処理を終了する。
【０１２９】
以上のように、サブジェクトを、放送ネットワーク４または通信ネットワーク３６のうちのいずれを介して受信する方が有利かどうかを判定し、有利な方を介して送信されるサブジェクトを受信するようにしたので、受信端末５では、効率的に、サブジェクトの受信、およびオブジェクトの更新を行うことが可能となる。
【０１３０】
なお、サブジェクトを、放送ネットワーク４を介して受信する場合において、イベントの放送スケジュール情報に、複数の送信時刻が配置されているときには、例えば、そのうちの、現在時刻に最も近い送信時刻（但し、現在時刻よりも前（過去）の時刻を除く）に送信されてくるサブジェクトが受信される。但し、ユーザに操作部２８を操作してもらい、送信時刻を選択させることも可能である。
【０１３１】
また、サブジェクトを、通信ネットワーク６を介して要求、受信する場合において、イベントのサーバアクセス情報に、複数のサーバのＩＰアドレスが配置されているときには、例えば、そのうちの、受信端末５に最も近い位置にあるサーバのＩＰアドレスを用いてＵＲＬが構成される。但し、ユーザに操作部２８を操作してもらい、サーバを選択させることも可能である。
【０１３２】
次に、図１２のフローチャートを参照して、データ出力処理について説明する。なお、データ出力処理も、例えば、図１１のデータ要求処理と同様に、基本的には、定期的に起動されるようになされている。
【０１３３】
データ出力処理では、まず最初に、ステップＳ５１において、操作部２８が、データ（本実施の形態では、オブジェクト）を出力するように操作されたか否かが、読み出し部２６によって判定され、そのようには操作されていないと判定された場合、データ出力処理を終了する。
【０１３４】
また、ステップＳ５１において、操作部２８が、オブジェクトを出力するように操作されたと判定された場合、ステップＳ５２に進み、出力の要求されたオブジェクトについてのイベント、即ち、そのオブジェクトの識別子と同一の識別子が付加されているイベントが、データベース２３に記憶されているかどうかが、読み出し部２６によって判定される。ステップＳ５２において、出力の要求されたオブジェクトについてのイベントが、データベース２３に記憶されていないと判定された場合、即ち、出力の要求されたオブジェクトとしては、いまデータベース２３に記憶されているものが最新のものである場合（但し、イベントの取りこぼしがないものとする）、ステップＳ５３に進み、読み出し部２６は、出力の要求されたオブジェクトを、データベース２３から読み出し、出力部２７に供給する。出力部２７では、読み出し部２６からのオブジェクトが表示、または音声で出力され、データ出力処理を終了する。
【０１３５】
また、ステップＳ５２において、出力の要求されたオブジェクトについてのイベントが、データベース２３に記憶されていると判定された場合、即ち、出力の要求されたオブジェクトは、サーバ２では更新されているが、受信端末５では、まだ更新されていない場合、ステップＳ５４に進み、そのオブジェクトの更新を行うかどうかが、読み出し部２６によって判定される。
【０１３６】
即ち、ステップＳ５４では、読み出し部２６は、オブジェクトの更新を行うかどうかを問い合わせるメッセージを、出力部２７に表示させ、ユーザに、操作部２８の操作を促す。そして、ステップＳ５４では、操作部２８の操作に対応して、オブジェクトの更新を行うかどうかが判定される。
【０１３７】
あるいは、また、ステップＳ５４では、出力の要求されたオブジェクトについてのイベントの放送スケジュール情報が参照され、そのオブジェクトを更新するためのサブジェクトが、放送ネットワーク４を介して送信されてくる送信時刻のうち、現在時刻に最も近いものが認識される。そして、ステップＳ５４では、その現在時刻に最も近い送信時刻が、現在時刻から、あらかじめ受信端末５に設定された所定の時間内であるかどうかに対応して、オブジェクトの更新を行うかどうかが判定される（送信時刻が、現在時刻から所定の時間内である場合には、オブジェクトの更新を行うと判定される）。
【０１３８】
ステップＳ５４において、出力の要求されたオブジェクトの更新を行わないと判定された場合、ステップＳ５５に進み、読み出し部２６は、出力の要求されたオブジェクト、即ち、更新前のオブジェクトを、データベース２３から読み出し、以下、ステップＳ５３における場合と同様にして、出力部２７に出力させて、データ出力処理を終了する。なお、この場合、出力部２７には、オブジェクトを出力させるとともに、そのオブジェクトが更新前のものである旨のメッセージを表示させるようにしても良い。
【０１３９】
一方、ステップＳ５４において、出力の要求されたオブジェクトの更新を行うと判定された場合、ステップＳ５６に進み、そのオブジェクトの更新するためのデータベース更新処理が行われる。即ち、ステップＳ５６では、出力の要求されたオブジェクトについてのイベントを用いて、図１１のデータ要求処理のステップＳ４３乃至Ｓ４９における場合と同様の処理が行われ、これにより、出力の要求されたオブジェクトが更新される。そして、ステップＳ５３に進み、その更新後のオブジェクトが、上述したようにして、出力部２７から出力され、データ出力処理を終了する。
【０１４０】
ところで、イベントのサーバアクセス情報に、複数のサーバのＩＰアドレスが配置されている場合において、いずれのサーバに、サブジェクトを要求するかを、例えば、上述したように、受信端末５からの位置や、ユーザによる操作部２８の操作に対応して決定したのでは、あるサーバへのアクセスが集中することがある。
【０１４１】
そこで、通信ネットワーク６を介して、受信端末５に対してサブジェクトを送信するサーバが複数存在する場合（例えば、図１に示すように、サーバ２以外に、ミラーサーバ７が存在する場合や、ミラーサーバ７以外のミラーサーバがさらに存在する場合など）には、サーバへのアクセスを分散させるために（１のサーバにアクセスを集中させないために）、受信端末５またはそのユーザに、固有のＩＤ（以下、適宜、ユーザＩＤという）を与え、サーバ２には、各サーバのＩＰアドレスを、所定のユーザＩＤと対応付け、サーバアクセス情報として、イベントに配置する処理（以下、適宜、負荷分散処理という）を行わせてから、イベントを送信させるようにすることができる。一方、受信端末５には、自身のユーザＩＤと対応付けられているＩＰアドレスのサーバを認識する処理（以下、適宜、アクセスサーバ決定処理）を行わせてから、そのサーバに、サブジェクトを要求させるようにすることができる。
【０１４２】
図１３は、サーバ２が行う負荷分散処理のフローチャートを示している。なお、この負荷分散処理は、受信端末５に対して、通信ネットワーク６を介して、サブジェクトを送信するサーバが複数存在する場合（サーバ２以外に、通信ネットワーク６を介して、サブジェクトを送信することのできるサーバが存在する場合）に、例えば、図６のデータ伝送処理におけるステップＳ１２の処理の一部として行われる。
【０１４３】
負荷分散処理では、まず最初に、ステップＳ６１において、通信ネットワーク６を介して、サブジェクトを送信する１のサーバに割り当てる受信端末の数（以下、適宜、割当数という）Ｎが算出される。即ち、ステップＳ６１では、例えば、受信端末の総数が、サブジェクトを通信ネットワーク６を介して送信するサーバの総数で除算され、その除算値（小数点以下は、例えば、切り上げ）が、割当数Ｎとされる。なお、サーバ２では、受信端末の総数が管理されているものとする。また、サーバ２では、サブジェクトを通信ネットワーク６を介して送信するサーバの総数は、複製管理部１４で管理されている情報から認識されるようになされている。
【０１４４】
その後、ステップＳ６２において、通信ネットワーク６を介して、サブジェクトを送信する複数のサーバのうちの１が選択され（この選択されたサーバを、以下、適宜、選択サーバという）、ステップＳ６３に進み、例えば、その選択サーバに近い位置にある受信端末が、割当数Ｎだけ検出される。なお、選択サーバおよび受信端末５の位置は、サーバ２において管理されているものとする。
【０１４５】
そして、ステップＳ６４に進み、選択サーバのＩＰアドレスに、ステップＳ６３で検出されたＮ個の受信端末それぞれのユーザＩＤが対応付けられ、そのＩＰアドレスとＮ個のユーザＩＤとの組が、サーバアクセス情報として、イベントに配置される。その後、ステップＳ６５に進み、通信ネットワーク６を介して、サブジェクトを送信する複数のサーバすべてを、選択サーバとして、ステップＳ６２乃至Ｓ６４の処理を行ったかどうかが判定される。ステップＳ６５において、複数のサーバすべてを、まだ、選択サーバとして処理していないと判定された場合、ステップＳ６２に戻り、まだ選択サーバとして選択されていないサーバが、新たに選択サーバとされ、以下、同様の処理を繰り返す。一方、ステップ６５において、複数のサーバすべてを選択サーバとして処理を行ったと判定された場合、負荷分散処理を終了する。
【０１４６】
以上のようにして、負荷分散処理では、１のサーバに、Ｎ個（またはＮ−１個）の受信端末が割り当てられる。
【０１４７】
なお、上述の場合においては、単純に、受信端末の総数を、サブジェクトを通信ネットワーク６を介して送信するサーバの総数で除算した除算値を、１のサーバに割り当てる受信端末の数としたが、複数のサーバそれぞれに割り当てる受信端末の数は、例えば、さらに、各サーバの処理能力などを考慮して決めても良い。
【０１４８】
次に、図１４のフローチャートを参照して、受信端末５が行うアクセスサーバ決定処理について説明する。なお、このアクセスサーバ決定処理は、受信端末５において、例えば、図１１のデータ要求処理のステップＳ４８で送信するＵＲＬを構成する前に行われる。
【０１４９】
アクセスサーバ決定処理では、ステップＳ７１において、受信端末５は、イベントのサーバアクセス情報の中から、自身に割り当てられているユーザＩＤを検索し、ステップＳ７２に進む。ステップＳ７２では、自身のユーザＩＤに対応付けられているＩＰアドレス、即ち、サブジェクトを要求すべきサーバが認識され、アクセスサーバ決定処理を終了する。
【０１５０】
そして、受信端末５では、図１１で説明したように、ステップＳ４８において、ステップＳ７２で認識されたＩＰアドレスを用いてＵＲＬが構成されて送信される。
【０１５１】
以上のように、サーバ２または受信端末５において、負荷分散処理またはアクセスサーバ決定処理をそれぞれ行うことで、受信端末からのサブジェクトの要求を、複数のサーバに分散させることができ、効率の良いサブジェクトの配信が可能となる。
【０１５２】
なお、上述の場合においては、受信端末のユーザＩＤとＩＰアドレスとを対応付け、受信端末がアクセスすべきサーバを制限するようにしたが、その他、例えば、受信端末のユーザＩＤと、サーバに対して通信ネットワーク６を介してアクセス可能な時間帯（要求タイミング情報）とを対応付け、受信端末がサーバにアクセスする時間帯を制限するようにすることなどによっても、サーバに対するアクセスを分散させることが可能である。
【０１５３】
以上、本発明を適用したデータ配信システムについて説明したが、このようなデータ配信システムは、例えば、分散型データベースにおける多数のデータベースへのデータの配信を行う場合や、ＩＰマルチキャストによりデータを配信する場合、その他、データを不特定多数に配信する場合に、特に有用である。
【０１５４】
なお、本実施の形態では、イベントは、放送ネットワーク４を介して送信するようにしたが、その他、例えば、受信端末５からの要求に応じて、通信ネットワーク６を介して送信するようにしても良い。さらに、本発明において、放送ネットワーク４および通信ネットワーク６の両方を備えることは必須ではない。即ち、本発明は、放送ネットワーク４または通信ネットワーク６のいずれか１つだけを備えるシステムにも適用可能である。
【０１５５】
また、本実施の形態では、サーバアクセス情報に、サーバ２やミラーサーバ７のＩＰアドレスを配置するようにしたが、サーバアクセス情報には、その他、例えば、サーバ２やミラーサーバ７で管理されているサブジェクトのＵＲＬや、サーバ２やミラーサーバ７へアクセスするための電話番号などを配置することも可能である。
【０１５６】
また、ミラーサーバ７には、受信端末５と同様にして、イベントやサブジェクトを受信させて、データベース８の更新を行わせるようにすることが可能である。
【０１５７】
さらに、本実施の形態では、サブジェクトに含める更新オブジェクト情報として、更新後のオブジェクトそのものなどを配置するようにしたが、更新オブジェクト情報としては、その他、例えば、更新前のオブジェクトに、更新後のオブジェクトへの変更内容を反映させるためのデータ（例えば、更新前のオブジェクトを、更新後のオブジェクトに変更する実行形式のコンピュータプログラムや、更新後のオブジェクトと更新前のオブジェクトとの差分など）などを配置することも可能である。
【０１５８】
次に、図７においては、データ構成部１７において生成されるイベントのデータ構造の概要を説明したが、このデータ構成部１７で構成されるイベントを、例えば、任意のトランスポートプロトコル上で実現するためのフォーマットについて詳述する。
【０１５９】
なお、ここでは、イベントのフォーマットを、ＡＮＳ．１（Abstract Syntax Notation One）を用いた抽象構文表現によって表すこととする。
【０１６０】
ここで、ＡＮＳ．１によって表されたフォーマットは、ＡＳＮ．１の符号化規則ＢＥＲ（Basic Encoding Rules），ＣＥＲ（Canonical Encoding Rules），ＤＥＲ（Distinguished Encoding Rules），ＰＥＲ（Packed Encoding Rules）に基づき、一意に符号化（ビット列（転送構文）に変換）することができる。また、その符号化や、符号化結果の復号を行うための処理系は、ＡＳＮ．１準拠の商用／パブリックドメインソフトウェアのツールＳｎａｃｃ（Sample Neufeld Asn.1 to C Compiler）などを利用することで、容易に構成することができる。
【０１６１】
なお、ＡＮＳ．１による抽象構文については、例えば、「プロトコル構文規定言語ＡＳＮ．１」、カットシステム発行などに、符号化規則ＢＥＲ，ＣＥＲ，ＤＥＲについては、例えば、ISO/IEC 8825-1:ASN.1 Encoding Rules:Specification of Basic Encoding Rules(BER), Canonical Encoding Rules(CER), and Distinguished Encoding Rules(DER)などに、符号化規則ＰＥＲについては、例えば、ISO/IEC 8825-1:ASN.1 Encoding Rules:Specification of Packed Encoding Rules(PER)などに、その詳細が開示されている。
【０１６２】
イベントEventMessageは、例えば、次のように定義される。
【０１６３】
ここで、SEQUENCE{}は、イベント（イベントの型）EventMessageが、かっこ｛｝内で定義されている変数formatVersion,FormatVersion,filteringMasks,timeToLive,objectIdentifier,objectVersion,subjectLinksの順序列で表現されることを表す。また、かっこ｛｝内の左から２番目に配置されているFormatVersion,FilteringMasks,UTCTime,ObjectIdentifier,INTEGER,SubjectLinksは、その左に配置されている変数の型を表す。また、かっこ｛｝内の左から３番目に配置されているOPTIONALは、その行で定義されている変数が、任意的変数（省略可能な変数）であることを表す。従って、ここでは、イベントEventMessageは、少なくとも、フォーマットバージョンformatVersion、生存時間timeToLive、オブジェクト識別子objectIdentifierで構成される。
【０１６５】
なお、型FormatVersion,FilteringMasks,UTCTime,ObjectIdentifier,INTEGER,SubjectLinksのうち、INTEGERは整数を、UTCTimeは国際標準時刻またはローカル時刻（少なくとも、秒の精度を有する）を、それぞれ表す。他の型の定義については、後述する。
【０１６６】
イベントEventMessageにおいて、フォーマットバージョンformatVersionは、そのイベントEventMessageのフォーマットのバージョンを表す。即ち、イベントEventMessageのフォーマットを、将来拡張することを考えると、受信端末５において、イベントEventMessageを処理するには、そのフォーマットを認識する必要がある。フォーマットバージョンformatVersionは、イベントEventMessageのフォーマットを特定するための情報（フォーマット情報）で、受信端末５では、このフォーマットバージョンformatVersionによって、受信したイベントEventMessageのフォーマットが認識されて処理される。
【０１６７】
フォーマットバージョンformatVersionの型FormatVersionは、例えば、次のように定義される。
【０１６８】
即ち、フォーマットバージョンformatVersionは、ここでは、メジャーバージョンmajorVersionおよびマイナーバージョンminorVersionと呼ばれる２つの整数（INTEGER）で表される。なお、メジャーバージョンmajorVersionおよびマイナーバージョンminorVersionの使い分けや、数字の割り当て方などは、データ配信システムの運用者が任意に定義可能とすることもできるが、ここでは、例えば、メジャーバージョンmajorVersionには、イベントとサブジェクトを区別するための情報を配置することとする。即ち、例えば、イベントについてのメジャーバージョンmajorVersionとしては、所定値以上を用い、サブジェクトについてのメジャーバージョンmajorVersionとしては、所定値未満を用いることとする。この場合、フォーマットバージョンformatVersionは、イベントEventMessageのフォーマットのバージョンを表す他、図７で説明した判別フラグとしての役割も果たす。
【０１７０】
ここで、イベントとサブジェクトを区別する情報は、メジャーバージョンmajorVersionに配置する他、トランスポートレイヤより上位の、例えば、アプリケーションレイヤやプレゼンテーションレイヤなどにおいて定義することも可能である。
【０１７１】
イベントEventMessageにおけるフィルタマスクfilteringMasksは、受信端末５において、そのイベントEventMessageを取捨選択するための基準として用いることのできる情報（選択基準情報）で、その型FilteringMasksは、例えば、次のように定義される。
【０１７２】
ここで、SEQUENCE OF{}は、フィルタマスク（フィルタマスクfilteringMasksの型）FilteringMasksが、かっこ｛｝内で定義されている変数filteringMaskIdentifierとfilteringMaskFieldとの組み合わせの順序列で表現されることを表す。従って、フィルタマスクfilteringMasksは、変数filteringMaskIdentifierとfilteringMaskFieldとの組み合わせを１つだけでなく、複数配置して構成することができる。また、変数filteringMaskFieldの型ANY DEFINED BYは、BYの後に配置されている変数に依存する任意の型（任意型）であることを表す。従って、変数filteringMaskFieldの型は、その前の行に配置されている変数filteringMaskIdentifilerに対応した任意の型を取り得る。
【０１７４】
フィルタマスクfilteringMasksにおけるマスク識別子filteringMaskIdentifierは、マスクフィールドfilteringMaskFieldを識別するためのもので、ここでは、マスクフィールドfilteringMaskFieldごとに、ユニークな整数が用いられるようになされている。
【０１７５】
フィルタマスクfilteringMasksにおけるマスクフィールドfilteringMaskFieldは、イベントEventMessageに対応するオブジェクト（イベントEventMessageに基づいて取得されるサブジェクトによって更新されるオブジェクト）を取捨選択するための基準として用いることのできる情報で、そこには、例えば、そのオブジェクトのカテゴリや、オブジェクトを視聴するにあたっての年齢制限、オブジェクトの視聴することの契約内容などに関する情報が配置される。
【０１７６】
即ち、マスクフィールドfilteringMaskFieldには、例えば、オブジェクトが、スポーツに関するものであるとか、天気予報に関するものであるとかを表す情報を配置し、さらに、オブジェクトが、スポーツに関するものであるという情報が配置される場合には、そのオブジェクトが、スポーツのうちの、野球に関するものであるとか、サッカーに関するものであるとかを表す情報を配置することができる。この場合、受信端末５における選択部２２に、例えば、ユーザの所望するカテゴリを設定しておき（カテゴリの設定は、例えば、ユーザに行わせるようにしても良いし、受信端末５において、ユーザによるオブジェクトの視聴履歴を記憶するようにして、その視聴履歴に基づいて行うようにしても良い）、そのカテゴリを、マスクフィールドfilteringMaskFieldと比較させることで、ユーザの所望するカテゴリのオブジェクトに対応するイベントだけを選択させることなどが可能となり、その結果、ユーザの所望するカテゴリのオブジェクトだけの提供を受けることが可能となる。なお、逆に、受信端末５における選択部２２に、ユーザが所望しないカテゴリを設定しておき、そのカテゴリを、マスクフィールドfilteringMaskFieldと比較させることで、ユーザの所望しないカテゴリを除くカテゴリのオブジェクトに対応するイベントだけを選択させるようにすることも可能である。
【０１７７】
また、マスクフィールドfilteringMaskFieldには、例えば、オブジェクトが、何歳以上向けであるといった年齢制限に関する情報を配置することも可能である。この場合、受信端末５における選択部２２に、例えば、年齢を設定しておき、その年齢を、マスクフィールドfilteringMaskFieldと比較させることで、成人向けのオブジェクトに対応するイベントを選択しないようにすることなどが可能となる。
【０１７８】
さらに、マスクフィールドfilteringMaskFieldには、オブジェクトが、高額の契約料を支払う契約内容のユーザ向けとか、低額の契約料を支払う契約内容のユーザ向けといった契約内容に関する情報を配置することも可能である。この場合、受信端末５における選択部２２に、契約内容を設定しておき、その契約内容を、マスクフィールドfilteringMaskFieldと比較させることで、オブジェクトの視聴にあたっての契約内容に応じたオブジェクトの選択を行うようにすることなどが可能となる。
【０１７９】
ここで、フィルタマスクfilteringMasksは、上述したように、マスク識別子filteringMaskIdentifierとマスクフィールドfilteringMaskFieldとの組み合わせを１以上配置して構成することができるから、そこには、例えば、オブジェクトのカテゴリと、オブジェクトを視聴するにあたっての年齢制限がそれぞれ配置された２つのマスクフィールドfilteringMaskFieldを、対応するマスク識別子filteringMaskIdentifierと組み合わせて順次記述することが可能である。この場合、選択部２２では、所定のカテゴリに属し、かつ所定の年齢向けのオブジェクトに対応するイベントのみを選択したり、また、所定のカテゴリに属するオブジェクトと、所定の年齢向けのオブジェクトとのうちのいずれかに対応するオブジェクトを選択するようにすることが可能となる。なお、この場合、選択部２２では、フィルタマスクfilteringMasksに配置された２つのマスクフィールドfilteringMaskFieldそれぞれが、オブジェクトのカテゴリに関するものか、またはオブジェクトを視聴するにあたっての年齢制限に関するものであるかは、それぞれに対応するマスク識別子filteringMaskIdentifierに基づいて認識される。
【０１８０】
また、マスク識別子filteringMaskIdentifierは、マスクフィールドfilteringMaskFieldに配置される情報が異なれば、異なる値とされるが、同一の情報が配置される場合でも、異なる値とされることがある。即ち、例えば、マスクフィールドfilteringMaskFieldに、オブジェクトのカテゴリに関する情報を配置する場合に、カテゴリ数が増加し、その増加したカテゴリを表現するために、マスクフィールドfilteringMaskFieldに割り当てるビット数を増加する必要が生じることがある。具体的には、マスクフィールドfilteringMaskFieldが、例えば、当初は８ビットであったのに、１６ビットに増加される場合がある。このような場合には、８ビットのマスクフィールドfilteringMaskFieldと、１６ビットのマスクフィールドfilteringMaskFieldとで、異なるマスク識別子filteringMaskIdentifierが対応付けられる。これは、受信端末５において、マスクフィールドfilteringMaskFieldに割り当てられているビット数を認識することができるようにするためである。
【０１８１】
以上のようなフィルタマスクfilteringMasksを、イベントEventMessageに配置することで、選択部２２において、イベントEventMessageの取捨選択が可能となり、その結果、サブジェクトに、フィルタマスクfilteringMasksを含ませなくても、サブジェクトの取捨選択が可能となる。即ち、サブジェクトは、イベントEventMessageに基づいて取得されるから、イベントEventMessageの取捨選択を行うことで、結果的に、サブジェクトの取捨選択も行われる。さらに、それにより、サブジェクトによって更新されるオブジェクトの取捨選択も行われる。
【０１８２】
次に、イベントEventMessageにおける生存時間（期限情報）timeToLiveは、イベントEventMessageの有効期限を表す。即ち、受信端末５においては、放送ネットワーク４を介して送信されてくるイベントEventMessageが受信されるが、例えば、受信端末５では、受信されたイベントEventMessageが、一旦、データベース２３に記憶されるので、即座に処理されるとは限らない。このため、イベントEventMessageを対象に、図１１のデータ要求処理を行おうとするときには、そのイベントEventMessageが、既に、使用不能の状態になっていることがある。
【０１８３】
即ち、例えば、イベントEventMessageに、サブジェクトの放送時刻などが配置されている場合において、図１１のデータ要求処理の開始時刻が、その放送時刻を過ぎていることがある。この場合、図１１のデータ要求処理を行ったとしても、既にサブジェクトの放送は終了しているから、受信端末５において、そのサブジェクトを受信することはできない。従って、そのような使用不能のイベントEventMessageを、データベース２３に記憶させておくのは、記憶容量の無駄であり、好ましくない。
【０１８４】
また、イベントEventMessageは、受信端末５に対して、例えば、衛星回線などの放送ネットワーク４を介して送信する他、上述したように、例えば、インターネットなどの通信ネットワーク６を介して送信することもできるが、イベントEventMessageを通信ネットワーク６を介して送信する場合には、回線の混み具合（トラフィック）などに起因して、受信端末５でイベントEventMessageを受信するのが、サーバ２による送信がなされてから、相当の時間が経過した後になることがある。このような場合も、イベントEventMessageが、既に、使用不能の状態になっていることがある。
【０１８５】
そこで、生存時間timeToLiveには、いわば、イベントEventMessageの鮮度を表す指標として、そのイベントEventMessageを廃棄する時刻が配置される。
【０１８６】
この場合、受信端末５では、イベントの受信時刻や、データベース２３に記憶されたイベントを参照した時刻などが、生存時間timeToLiveに配置された時刻を経過していた場合、そのイベントは使用不能であるとして廃棄される（受信したイベントはデータベース２３に記憶されず、また、参照されたイベントはデータベース２３から削除される）。
【０１８７】
なお、サーバ２では、生存時間timeToLiveは、例えば、次のようにして設定される。即ち、サーバ２のデータ構成部１７では、イベントEventMessageに対応するオブジェクトの更新間隔（オブジェクトが更新されてから、次に更新されるまでの時間）の平均値などが求められ、その平均値の整数倍によって表される時間を、イベントEventMessageの作成時刻に加算して得られる時刻が、生存時間timeToLiveに配置される。なお、生存時間timeToLiveの設定方法は、これに限定されるものではない。
【０１８８】
次に、イベントEventMessageにおけるオブジェクト識別子objectIdentifierは、そのイベントEventMessageが更新を報知するオブジェクトが存在する位置に関する情報（位置情報）で、受信端末５では、このオブジェクト識別子objectIdentifierに基づいて、更新されたオブジェクトが特定、認識される。サーバ２において、データベース３のオブジェクトが更新された場合、そのオブジェクトの更新に対応して、イベントEventMessageが作成されるから、その更新されたオブジェクトを特定するオブジェクト識別子objectIdentifierによれば、その更新を報知するイベントEventMessageを特定することができ、従って、オブジェクト識別子objectIdentifierは、図７に示したＩＤに相当する。
【０１８９】
オブジェクト識別子objectIdentifierの型ObjectIdentifierは、例えば、次のように定義される。
【０１９０】
取得可能時間avairableTimeは、更新が報知されたオブジェクトが存在する時間的な位置、即ち、例えば、その更新後のオブジェクトが、データベース３に登録された時間や、データベース３に登録されている時間（オブジェクトが更新されてから、次に更新されるまでの時間）などの、オブジェクトが有効に存在する時間を表す。取得可能時間avairableTimeは、記述しても、またしなくても良く、その型AvairableTimeは、例えば、次のように定義される。
【０１９２】
開始時刻startTimeは、ここでは、例えば、更新後のオブジェクトがデータベース３に登録された時刻を表す。また、終了時刻endTimeは、ここでは、例えば、更新後のオブジェクトが、次に更新される時刻を表す。なお、取得可能時間avairableTimeを記述する場合、開始時刻startTimeの記述は必須であるが、終了時刻endTimeの記述は任意（OPTIONAL）である。
【０１９４】
オブジェクト識別子objectIdentifierにおけるロケータlocatorは、更新が報知されたオブジェクトが存在する地理的または論理的な位置を表す。ここで、オブジェクトの地理的な位置とは、例えば、オブジェクトを管理するサーバ２のインターネットアドレスなどのネットワーク上の位置を特定するための情報を意味する。また、論理的な位置とは、オブジェクトが、あるテーブルやデータ構造などの一部を構成している場合における、そのテーブルやデータ構造中のオブジェクトの位置を意味する。具体的には、例えば、オブジェクトが、ＥＰＧ（Electric Program Guide）の、あるチャンネルにおける、ある時間帯のテレビジョン放送番組を紹介する欄を構成している場合には、ＥＰＧ上の、その欄の位置が、そのオブジェクトの論理的な位置となる。
【０１９５】
ロケータlocatorの型Locatorは、例えば、次のように定義される。
【０１９６】
ここで、CHOICE{}は、かっこ｛｝内で定義されている変数netLocatorとdvbSpecificLocatorのうちのいずれかが選択されること（従って、Locatorが選択型であること）を意味する。
【０１９８】
ネットロケータnetLocatorは、インターネットプロトコルによりアクセス可能なドメインのリソースを特定するもので、その型NETLocatorは、例えば、以下のように定義される。
【０１９９】
ここで、EXTERNALは、ＡＳＮ．１モジュールのスコープ外で定義されるデータ型（外部型）であることを意味し、その定義は、ＡＳＮ．１の構文にしたがった定義でなくても良い。
【０２０１】
ＮＳＡＰロケータnsapSpecificLocatorは、ＮＳＡＰ（Networks Service Access Point）を特定するのに用いられるもので、その型NSAPSpecificLocatorは、例えば、次のように定義される。
【０２０２】
ＮＳＡＰアドレスnsapAddressは、外部型（EXTERNAL）であり、そのシンタクスとしては、例えば、E.164NSAPformatや、ＡＥＳＡ（ATM(Asynchronous Transfer Mode) End System Address）のNSAPencodeE.164formatなどを採用することができる。なお、E.164NSAPformatについては、例えば、ISO/IEC8348:Network Service Definitionに、AESAのNSAPencodeE.164formatについては、例えば、ATM User-Network Interface(UNI) Specification 3.0/3.1に、それぞれ、その定義が記載されている。
【０２０４】
付加情報additionalInfoは、ＮＳＡＰアドレスnsapAddressにアクセスする際に必要となる、例えば、ＰＰＰ（Point to Point Protocol）を選択することを示すプロトコル識別情報や、認証プロトコルに必要な情報、モデム設定コマンドシーケンス（ヘイズATコマンド）などの付加情報であり、その型は任意（任意型）（ANY）とされている。なお、付加情報additionalInfoの記述は任意である。
【０２０５】
ネットロケータnetLocatorにおけるリソース識別子universalResourceIdentifierは、いわゆるＵＲＩ（Universal Resource Identifier）を意味する。ＵＲＩは、ＷＷＷにおいて提供されるリソースを一意に識別することができ、ユーザが、インターネットに、直接接続することができる場合（受信端末５が、インターネットに直接接続される場合）に利用される。ここで、リソース識別子universalResourceIdentifierのシンタクスとしては、例えば、RFC1630:Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Webに定義されているものを利用することができる。
【０２０６】
なお、ネットロケータnetLocatorとして、ＵＲＩと、ＮＳＡＰロケータnsapSpecificLocatorとの両方を利用可能としたのは、例えば、X.25や公衆網を利用したダイヤルアップ接続（ＡＴＭ接続も含む）によってアクセス可能な、孤立したインターネットのドメインにおけるオブジェクトにアクセスすることができるようにするためである。
【０２０７】
ロケータlocatorにおけるＤＶＢロケータdvbSpecificLocatorは、ＤＶＢ（Digital Video Broadcasting）互換のディジタル放送によるストリーム上のリソースを特定するもので、その型DVBSpecificLocatorは、例えば、次のように定義される。
【０２０８】
プリミティブロケータdvbPrimitiveLocatorは、ＤＶＢにおいて定義されているデータ構造／ストリームを特定するもので、これにより、例えば、ＤＶＢ−ＳＩに規定されているディジタル放送によるＥＰＧ上の任意のテーブルを指定することができる。従って、この場合、イベントEventMessageは、例えば、ＤＶＢ−ＳＩに規定されているフォーマットにより放送されるＥＰＧテーブルの内容の更新にも利用することができる。なお、ＤＶＢ−ＳＩについては、例えば、ETC300 468:Digital broadcasting systems for television, sound and data services;Specification for Service Information(SI) in Digital Video Broadcasting(DVB) systemsに、その詳細が記載されている。
【０２１０】
プリミティブロケータdvbPrimitiveLocatorの型DVBPrimitiveLocatorは、例えば、次のように定義される。
【０２１１】
ここで、かっこ［］とその中に配置されている数字は、構造型を構成する同一の型の複数の変数それぞれを識別するためのタグである。
【０２１３】
なお、NetworkID, TransportID, packetID, serviceID, tableID, tableIDExtention, sectionNumber, eventID, componentTagについては、例えば、ISO/IEC13818-1:Infomation technology-Generic coding of moving pictures and associated audio information-Part1:Systems-International Standard(IS)、およびETC300 468:Digital broadcasting systems for television, sound and data services;Specification for Service Information(SI) in Digital Video Broadcasting(DVB) systemsに、その詳細が記載されているので、ここでは、説明を省略する。
【０２１４】
ＤＶＢロケータDVBSpecificLocatorにおけるデータカルーセルロケータdvbDataCarouselLocatorは、データカルーセル（Data Carousel）と呼ばれるデータ構造を特定するもので、その型DVBDataCarouselLocatorは、例えば、次のように定義される。
【０２１５】
また、ＤＶＢロケータDVBSpecificLocatorにおけるオブジェクトカルーセルロケータdvbObjectCarouselLocatorは、オブジェクトカルーセル（Object Carousel）と呼ばれるデータ構造を特定するもので、その型DVBObjectCarouselLocatorは、例えば、次のように定義される。
【０２１７】
なお、データカルーセル、オブジェクトカルーセル、groupID, moduleID, carouselID, objectKeyについては、例えば、Digital Video Broadcasting:DVB Specification for Data Broadcasting-Final Draft 12/02/97、およびImplementation Guidelines for Databroadcasting(SI-DAT382 Rev.3)に、その詳細が記載されているので、ここでは、説明を省略する。
【０２１９】
次に、イベントEventMessageにおけるオブジェクトバージョンobjectVersionは、そのイベントEventMessageに基づいて取得されるサブジェクトによって更新されるオブジェクトの、その更新後のバージョンを表し、図７におけるバージョン情報に相当する。オブジェクトバージョンobjectVersionとしては、例えば、オブジェクトが更新される度にインクリメントされる整数値や、更新後のオブジェクトのハッシュ値などを用いることができる。
【０２２０】
イベントEventMessageにおけるサブジェクトリンクsubjectLinksは、そのイベントEventMessageに基づいて取得されるサブジェクト（オブジェクト識別子objectIdentifierによって特定されるオブジェクトを更新するためのサブジェクト）を特定するためのもので、その型SubjectLinksは、例えば、次のように定義される。
【０２２１】
サブジェクト識別子subjectIdentifierは、上述のオブジェクト識別子objectIdentifierと同一の型ObjectIdentifierを有し、そこには、サブジェクトが存在する位置に関する情報（位置情報）が配置される。従って、受信端末５では、このサブジェクト識別子subjectIdentifierに基づいて、オブジェクトを更新するためのサブジェクトが取得される。
【０２２３】
なお、サブジェクト識別子subjectIdentifierは、ObjectIdentifier型であるから、取得可能時間avairableTimeを有する場合があるが、これは、図７で説明した放送スケジュール情報の中の放送時刻に相当する。また、サブジェクト識別子subjectIdentifierは、ロケータlocatorを有するが、これは、図７で説明したサーバアクセス情報（サーバ２などのＩＰアドレス）（サブジェクトの地理的位置）や、放送スケジュール情報の中の放送チャンネル（サブジェクトの論理的位置）に相当する。
【０２２４】
サブジェクトバージョンsubjectVersionは、整数型（INTEGER）で、サブジェクトのバージョンを表す。即ち、例えば、サブジェクトに、いわゆるバグがあり、その修復がされたサブジェクトが新たに作成される場合がある。また、サブジェクトの内容は同一のままで、そのシンタクスが変更される場合がある。そのような場合において、バグの修正前のサブジェクトと修正後のサブジェクトとを区別したり、シンタクスの変更前のサブジェクトと変更後のサブジェクトとを区別するためなどに、サブジェクトバージョンsubjectVersionは用いられる。
【０２２５】
サービス仕様qosSpecificationには、サブジェクトを、サブジェクト識別子subjectIdentifierに基づいて取得するかどうかを決めるための基準として用いることのできる情報（取得決定基準情報）が配置される。即ち、サブジェクトリンクSubjectLinksは、SEQUENCE OF{}で定義されているから、かっこ｛｝内で定義されている変数の組み合わせが、１以上配置されて構成される。具体的には、例えば、サブジェクトが、放送ネットワーク４を介して放送されるとともに、サーバ２において、受信端末５からの要求に応じて、通信ネットワーク６を介して送信される場合には、放送ネットワーク４を介して放送されるサブジェクトと、通信ネットワーク６を介して送信されるサブジェクトとのそれぞれについて、サブジェクトリンクSubjectLinksを規定するsubjectIdentifier, subjectVersion, qosSpecification, clientIdentifierが記述される。このような場合において、サービス仕様qosSpecificationは、サブジェクトを、放送ネットワーク４または通信ネットワーク６のうちのいずれを利用して受信するのかを決定するために参照される。
【０２２６】
サービス仕様qosSpecificationの型QOSSpecificationは、例えば、次のように定義される。
【０２２７】
ＱＯＳタイプqosSpecTypeには、サブジェクトを、サブジェクト識別子subjectIdentifierに基づいて取得するかどうかを決めるための基準として用いる情報の種別を表す整数値が配置される。即ち、ＱＯＳタイプqosSpecTypeは、それと組になっているＱＯＳ値qosSpecValueが、どのような情報の値であるのかを表す。
【０２２９】
ＱＯＳ値qosSpecValueには、サブジェクト識別子subjectIdentifierに基づいて、サブジェクトを取得するかどうかを決めるための基準として用いる情報としての、例えば、サーバ２側にかかっている負荷の状況や、サブジェクトのデータ量、通信ネットワーク６の混み具合などに対応する整数値が配置される。
【０２３０】
例えば、ＱＯＳ値qosSpecValueが、サーバ２側にかかっている負荷が大きいことを表している場合には、サブジェクトを、通信ネットワーク６を介して要求したのでは、サブジェクトが送信されてくるのに時間を要すると予想されるから、放送ネットワーク４を介して放送されてくるのを待って受信した方が良いとの判断の基準にすることができる。また、例えば、ＱＯＳ値qosSpecValueが、サブジェクトのデータ量が多いことを表している場合には、サブジェクトを、通信ネットワーク６を介して要求したのでは、データ量の多いサブジェクトを受信するのに通信コストが多くかかると予想されるから、放送ネットワーク４を介して放送されてくるのを待って受信した方が良いとの判断の基準にすることができる。さらに、例えば、ＱＯＳ値qosSpecValueが、通信ネットワーク６のトラフィック量が少ないことを表している場合には、サブジェクトを、即座に、かつ短い時間で取得することができると予想されるから、通信ネットワーク６を介して受信した方が良いとの判断の基準にすることができる。
【０２３１】
ここで、以上のようなことから、ＱＯＳ値qosSpecValueは、サブジェクトの提供サービスの質を表しているということもできる。
【０２３２】
サブジェクトリンクsubjectLinksにおけるクライアント識別子clientIdentifierには、サブジェクトの取得が許可されているユーザに関する情報（ユーザ情報）が配置され、その型ClientIdentfierは、例えば、次のように定義される。
【０２３３】
グループ識別子clientGroupIdentifierには、ある複数の受信端末のグループを特定する整数値が配置される。グループ識別子clientGroupIdentifierによれば、それによって特定される複数の受信端末だけに、サブジェクトを取得させることが可能となる。
【０２３５】
クライアント識別子clientIdentifiersには、１以上の受信端末のユーザＩＤ（図１３および図１４で説明したユーザＩＤ）が配置される。クライアント識別子clientIdentifiersによれば、それによって特定される１以上の受信端末だけに、サブジェクトを取得させることが可能となる。なお、クライアント識別子clientIdentifiersの型であるSET OF INTEGERは、整数型の集合（集合型）を表す。
【０２３６】
以上のように、クライアント識別子clientIdentifierによれば、サブジェクトを取得させる受信端末を制限することができるので、例えば、１のサーバに、サブジェクトの要求が集中することなどを防止することができる。
【０２３７】
以上、イベントを、任意のトランスポートプロトコル上で実現するためのフォーマットを、ＡＮＳ．１を用いた抽象構文表現によって表したが、このようなフォーマットのイベントの符号化を、例えば、ＡＳＮ．１準拠の商用／パブリックドメインソフトウェアのツールＳｎａｃｃを利用して行う場合には、例えば、以下のようなファイルを、その入力として与えてやればよい。
【０２３８】
【発明の効果】
以上の如く、本発明の受信装置および受信方法によれば、放送ネットワークを介してデータカルーセル方式で繰り返し送信されるコンテンツ、および、コンテンツの更新を報知するための報知データが受信され、受信されたコンテンツが記憶され、受信された報知データに記述されている、コンテンツの新しさを表すバージョン情報の更新が検出され、バージョン情報の更新が検出された場合、新たに受信されるコンテンツであって、報知データに記述されている、コンテンツが存在する位置に関する位置情報に対応付けられている更新コンテンツが要求され、記憶されているコンテンツが、更新コンテンツに更新される。従って、報知データに基づき、コンテンツの更新を、容易かつ効率的に行うことが可能となる。
【図面の簡単な説明】
【図１】本発明を適用したデータ配信システムの一実施の形態の構成例を示す図である。
【図２】図１のサーバ２の構成例を示すブロック図である。
【図３】図１のミラーサーバ７の構成例を示すブロック図である。
【図４】サーバ２が行う登録処理を説明するためのフローチャートである。
【図５】図１のデータベース１ａ乃至１ｃから供給されるデータのフォーマットを示す図である。
【図６】サーバ２が行うデータ伝送処理を説明するためのフローチャートである。
【図７】サブジェクトおよびイベントのフォーマットを示す図である。
【図８】サーバ２が行う要求データ送信処理を説明するためのフローチャートである。
【図９】図１の受信端末５の構成例を示すブロック図である。
【図１０】受信端末５が行う受信処理を説明するためのフローチャートである。
【図１１】受信端末５が行うデータ要求処理を説明するためのフローチャートである。
【図１２】受信端末５が行うデータ出力処理を説明するためのフローチャートである。
【図１３】サーバ２が行う負荷分散処理を説明するためのフローチャートである。
【図１４】受信端末５が行うアクセスサーバ決定処理を説明するためのフローチャートである。
【符号の説明】
１ａ乃至１ｃ データベース， ２ サーバ， ３ データベース， ４ 放送ネットワーク， ５ 受信端末， ６ 通信ネットワーク， ７ ミラーサーバ， ８ データベース， １１ 通信制御部， １２ 資源割当部， １３ データ検索部， １４ 複製管理部， １５ 登録部， １７ データ構成部，１８ 伝送部， ２１ 受信部， ２２ 選択部， ２３ データベース， ２４ 通信制御部， ２５ 要求部， ２６ 読み出し部， ２７ 出力部， ２８ 操作部
Claims (7)
- 放送ネットワークを介してデータカルーセル方式で繰り返し送信されるコンテンツ、および、前記コンテンツの更新を報知するための報知データを受信する受信手段と、
前記受信手段によって受信された前記コンテンツを記憶する記憶手段と、
前記受信手段によって受信された前記報知データに記述されている、前記コンテンツの新しさを表すバージョン情報の更新を検出する検出手段と、
前記検出手段によって前記バージョン情報の更新が検出された場合、前記受信手段によって新たに受信されるコンテンツであって、前記報知データに記述されている、コンテンツが存在する位置に関する位置情報に対応付けられている更新コンテンツを要求し、前記記憶手段に記憶されている前記コンテンツを、前記更新コンテンツに更新する更新手段と
を備えることを特徴とする受信装置。 - 前記報知データは、生存時間をさらに含み、
前記生存時間を経過した場合、前記記憶手段に記憶されている前記コンテンツを消去する消去手段をさらに備える
ことを特徴とする請求項１に記載の受信装置。 - 前記位置情報は、コンテンツが存在する地理的位置、論理的位置、または時間的位置に関するものである
ことを特徴とする請求項１に記載の受信装置。 - 前記報知データは、その報知データを取捨選択するための基準として用いることのできる選択基準情報をさらに含み、
前記更新手段は、前記選択基準情報に基づき、前記報知データを取捨選択する処理を行う
ことを特徴とする請求項１に記載の受信装置。 - 前記報知データは、前記更新コンテンツが複数の位置に存在する場合に、その更新コンテンツを、前記複数の位置のうちのいずれから取得するかを決めるための基準として用いることのできる取得決定基準情報をさらに含み、
前記更新手段は、前記取得決定基準情報に基づいて、前記複数の位置のうちのいずれかから、前記更新コンテンツを取得する
ことを特徴とする請求項１に記載の受信装置。 - 前記報知データは、前記更新コンテンツの取得が許可されているユーザに関するユーザ情報をさらに含み、
前記更新手段は、前記ユーザ情報によって前記更新コンテンツの取得が許可されている場合にのみ、その更新コンテンツを取得する
ことを特徴とする請求項１に記載の受信装置。 - 放送ネットワークを介してデータカルーセル方式で繰り返し送信されるコンテンツ、および、前記コンテンツの更新を報知するための報知データを受信し、
受信された前記コンテンツを記憶し、
受信された前記報知データに記述されている、前記コンテンツの新しさを表すバージョン情報の更新を検出し、
前記バージョン情報の更新が検出された場合、新たに受信されるコンテンツであって、前記報知データに記述されている、コンテンツが存在する位置に関する位置情報に対応付けられている更新コンテンツを要求し、記憶されている前記コンテンツを、前記更新コンテンツに更新する
ことを特徴とする受信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11473098A JP4337150B2 (ja) | 1998-04-24 | 1998-04-24 | 受信装置および受信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11473098A JP4337150B2 (ja) | 1998-04-24 | 1998-04-24 | 受信装置および受信方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008121631A Division JP4605479B2 (ja) | 2008-05-07 | 2008-05-07 | 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11306068A JPH11306068A (ja) | 1999-11-05 |
| JP4337150B2 true JP4337150B2 (ja) | 2009-09-30 |
Family
ID=14645199
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11473098A Expired - Fee Related JP4337150B2 (ja) | 1998-04-24 | 1998-04-24 | 受信装置および受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4337150B2 (ja) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11340975A (ja) * | 1998-05-28 | 1999-12-10 | Nippon Telegr & Teleph Corp <Ntt> | 複数端末への同一データ配信方法及びデータ配信システム装置 |
| JP3474459B2 (ja) * | 1998-09-30 | 2003-12-08 | 松下電器産業株式会社 | 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法 |
| CN100375526C (zh) * | 2000-04-06 | 2008-03-12 | 皇家菲利浦电子有限公司 | 对象条件访问系统 |
| JP3732069B2 (ja) * | 2000-04-26 | 2006-01-05 | シャープ株式会社 | サーバー及び情報提供システム |
| JP3970500B2 (ja) * | 2000-06-08 | 2007-09-05 | 東日本電信電話株式会社 | 利用者端末の遠隔制御方法ならびにシステム |
| WO2002011448A1 (fr) * | 2000-07-27 | 2002-02-07 | Kabushiki Kaisha Infocity | Dispositif d'acces a des informations et procede, et dispositif distributeur d'informations et procede |
| JP2002215664A (ja) * | 2001-01-12 | 2002-08-02 | Ns Solutions Corp | デジタルデータ配信システム、データ受信端末装置、データ配信装置及び記録媒体 |
| PL370109A1 (en) * | 2001-10-24 | 2005-05-16 | The Fantastic Corporation | Methods for multicasting content |
| JP2003134495A (ja) | 2001-10-29 | 2003-05-09 | Nec Corp | インターネット衛星通信及び無線放送システム |
| US8301884B2 (en) | 2002-09-16 | 2012-10-30 | Samsung Electronics Co., Ltd. | Method of managing metadata |
| JP3957220B2 (ja) | 2003-11-10 | 2007-08-15 | 株式会社イース | 集計システム |
| JP4605479B2 (ja) * | 2008-05-07 | 2011-01-05 | ソニー株式会社 | 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 |
| JP5511707B2 (ja) * | 2011-02-17 | 2014-06-04 | 日本電信電話株式会社 | マルチキャスト通信システム及びマルチキャスト通信制御方法 |
| JP2013098769A (ja) * | 2011-11-01 | 2013-05-20 | Kotobuki Solution Co Ltd | 告知情報に関するユニキャストデータ配信方法 |
| WO2014002184A1 (ja) * | 2012-06-26 | 2014-01-03 | 三菱電機株式会社 | 設備管理システム及びプログラム |
-
1998
- 1998-04-24 JP JP11473098A patent/JP4337150B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11306068A (ja) | 1999-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7228349B2 (en) | System and method for interacting with users over a communications network | |
| JP3498887B2 (ja) | 送信装置および送信方法、並びに受信装置および受信方法 | |
| JP4337150B2 (ja) | 受信装置および受信方法 | |
| JP3285841B2 (ja) | コンテンツ提供装置およびコンテンツ提供方法、受信装置および受信方法、並びに通信システムおよび通信方法 | |
| US8813155B2 (en) | Method for receiving service information data and an IPTV receiver | |
| US8112775B2 (en) | IPTV receiver and method of providing channel details information | |
| JP2004193920A (ja) | 番組配信システム及び受信装置 | |
| US7665108B2 (en) | Broadcasting program viewing method using electronic program guide and system thereof | |
| US6484028B2 (en) | Information delivery system using satellite communication | |
| JP5640807B2 (ja) | コンテンツ提供システム | |
| US20090158348A1 (en) | IPTV receiver and method of discovering an IPTV service | |
| KR101351715B1 (ko) | 계승 통신 관리 장치 | |
| JP4571937B2 (ja) | アクセスシステム及びアクセス方法 | |
| CN1468492A (zh) | 内容数据的分配装置 | |
| JP3474459B2 (ja) | 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法 | |
| WO2005010764A1 (ja) | コンテンツ同報配信システムとそれに用いる送信装置と受信装置ならびにコンテンツ同報配信方法 | |
| JP3497370B2 (ja) | 送信装置および送信方法、並びに受信装置および受信方法 | |
| KR100884490B1 (ko) | 데이터 처리 장치, 방송 비디오 레코더, 콘텐트 액세스 데이터를 얻는 방법, 방송 콘텐트 캡쳐 방법, 및 콘텐트 액세스 데이터를 사용자에게 공급하는 방법 | |
| US7441014B1 (en) | Broadcast distribution using low-level objects and locator tables | |
| JPH11306069A (ja) | 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 | |
| JP4605479B2 (ja) | 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 | |
| WO2008013385A1 (en) | System and method for continuous display of grouped multiple independent contents | |
| EP1773056A2 (en) | Apparatus and method for providing VOD service | |
| JPH11220493A (ja) | 送信装置および送信方法、受信装置および受信方法、並びに送受信システムおよび送受信方法 | |
| JP4023602B2 (ja) | 送信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041221 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080306 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080507 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081211 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090609 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090622 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120710 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130710 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |