JP2005039764A - メディアデータ送信装置およびメディアデータ受信装置 - Google Patents

Abstract

【課題】 限られた伝送帯域の中で、受信端末がコンテンツを表示する、または、動作させるまでの待ち時間を短くすること。
【解決手段】 本発明は、コンテンツを複数のデータから構成し、コンテンツを送信する際にコンテンツを構成するデータの重要性・必要性、データの目的に応じて、データの送信周期などを変更するようにした。これにより、例えば、必要性が高いデータは、低いデータより送信周期を短く設定し、要約情報など早く閲覧したい情報は、詳細情報よりも送信周期を短く設定するようにできる。
【選択図】 図１

Description

本発明は、プログラムや、画像データや、テキストデータや、音声データや、音楽データや、プログラムの動作を規定する動作ルールや、プログラムの一部として動作するサブプログラムなどの複数のメディアデータを含むコンテンツを伝送するメディアデータ送信装置およびメディアデータ受信装置に関する。

受信端末へのプログラムの配信方法として、受信端末がプログラムの配信サーバへ接続してプログラムをダウンロードする通信型の方法と、配信サーバより受信端末へデータを一方向送信し、受信端末がそのプログラムを受信する放送型の配信法がある。

通信型のプログラム配信は、受信端末に格納したいプログラムが端末毎に異なる場合には有効な手段であり、通信型のプログラム配信方式は、現在のインターネット上で通常用いられる方式である。

一方、放送型のプログラム配信は、多数の受信端末に同じプログラムを送信する場合には、通信型に比べて、伝送帯域を有効に利用することができ、また、プログラムの配布が開始されたことを即時に受信端末側で知ることができる（通信型の場合、送信端末に問い合わせを行わないとプログラムの配布が開始されたかどうかがわからない）。

放送型のプログラムの送信の従来例として、非特許文献１が挙げられる。この例では、プログラム自身は伝送しないものの、プログラムの動作を規定する動作ルール（ＥＣＡルール）を送信することで、プログラムの動作を変化させることができる。

また、放送型のコンテンツ（例えば、映像、音声、テキスト、プログラムなどのメディアデータ）の送信においては、一般に、送信周期が長くなると、コンテンツが表示される、または、動作するまでの待ち時間が長くなってしまうという課題がある。しかし、限られた伝送帯域の中で、全てのコンテンツに対して、送信周期を短くすることは難しい。

このため、重要なコンテンツの送信周期を短く設定する方式が提案されている。例えば、非特許文献２では、視聴率の高いコンテンツの送信周期を短く設定するようにしている。これによれば、視聴率の高いコンテンツを表示する時間が短くできる。

また、特許文献１では、送信する情報を、その情報の更新頻度・緊急度に応じてカテゴリーに分類し、カテゴリーごとに送信するタイミングを設定して送信する方法を開示している。これにより、更新頻度の高い情報や緊急度の高い情報を優先的に受信者に送信することができる。
特開２００１−２６８０２６号公報 寺田努、外２名、"放送型データ受信のためのアクティブデータベースシステムの設計と実装" 電子情報通信学会論文誌、Ｄ−１ Ｖｏｌ．Ｊ８３−Ｄ−１， Ｎｏ１２ ｐｐ１２７２−１２８３、２００２年１２月 青野正宏、外４名、"プッシュ型とプル型通信の動的統合による応答時間の短縮" 情報処理学会論文誌、Ｖｏｌ．４２、Ｎｏ．６、ｐｐ．１６９５−１７０２（２００１）

コンテンツの中にはコンテンツの受信者にとって必要性の高いメディアデータもあれば必要性の低いメディアデータもある。例えば、ＴＶ放送のような映像コンテンツの受信・視聴を移動体端末で行う場合、コンテンツの受信者は、現在自分のいる地域でどのようなコンテンツが配信されているかをまず知る必要がある。したがって、コンテンツの視聴者にとって、最も必要性が高いのは番組の概要を示す要約情報（例えばテキスト数百文字と静止画１枚程度の情報であり、ドラマであればあらすじやキャスト、バラエティー番組であれば司会やゲストなどが記される）であり、これをすばやくコンテンツの受信者に提示する必要がある。

しかしながら、特許文献１の方法では、送信する情報の更新頻度、緊急性に基づいて送信のタイミングを決定しているが、ユーザにとっての必要性を考慮しておらず、上記で示したような例に対して適用することは困難である。

また、非特許文献２の方法、視聴率の高いコンテンツに含まれるすべてデータの送信周期を一律で短くしている、コンテンツの閲覧者にとって必要性の低いメディアデータに関しても送信周期を短くして送信することになる。

このため、限られた伝送帯域を有効利用できず、他のコンテンツを構成している必要性の高いメディアデータの送信周期を短くできないという場合も発生する。よって、コンテンツの受信端末において、頻繁に更新する必要性の高いデータを受信する待ち時間が長くなり、コンテンツが表示される、または動作するまでの待ち時間が長くなってしまうという問題がある。

以上のように、従来の方法では、限られた伝送帯域の中で、受信端末が必要性の高いコンテンツを表示するまでの待ち時間が長くなるという課題を有している。

本発明は、かかる点に鑑みてなされたものであり、限られた伝送帯域の中で、受信端末が必要性の高いコンテンツを表示する、または、動作させるまでの待ち時間を短くすることを目的とする。

本発明は、コンテンツを複数のデータから構成し、コンテンツを送信する際にコンテンツを構成するメディアデータの必要性に応じて、メディアデータの送信周期、送信するデータの情報量を変更するようにした。

本発明により、例えば、必要性の高いメディアデータは、必要性の低いメディアデータより、送信周期を短く設定し、必要性が高いメディアデータは、低いメディアデータより送信周期を短く設定し、要約情報など早く閲覧したい情報は、詳細情報よりも送信周期を短く設定するようにできる。この結果、限られた伝送帯域の中で、受信端末が、コンテンツを受信し始めたときや、受信端末の条件が変わった場合に、必要なデータをより早く更新することができるように、メディアデータを送信することができる。また、必要性の高いメディアデータの情報量を、必要性の低いメディアデータの情報量よりも多くすることで、限られた伝送帯域の中で、例えば、ユーザの近隣の地図を詳細に提示し、ユーザの遠隔の地図は大まかに提示するなど、ユーザにとっての必要性に応じた情報提示を可能とした。

本発明の第１の態様にかかるメディアデータ送信装置は、第１のデータと第２のデータから構成されるコンテンツを蓄積する蓄積部と、前記蓄積部から前記第１のデータと第２のデータを取得する送信管理部と、前記第１のデータの送信周期を、前記第２のデータの送信周期よりも短く設定する送信管理部と、設定された前記送信周期を用いて前記第１のデータおよび前記第２のデータを個別に繰り返し送信する伝送部と、を有するメディアデータ送信装置であって、前記第１のデータは必要性の高い高必要データであり、前記第２のデータは前記高必要データと比較して必要性の低い低必要データである。

このように、第１のデータの送信周期を第２のデータの送信周期より短くすることにより、受信側が第１のデータをすばやく受信することができるようになり、第１のデータの更新待ち時間を削減することができる。これにより、受信側において必要性の高いデータをすばやく受信することができる。

本発明の第２の態様は、第１の態様にかかるメディアデータ送信装置において、前記送信管理部は、前記第１のデータの送信周期もしくは第２のデータの送信周期の少なくともどちらか一方を前記第１のデータの配信されるエリアもしくは第２のデータの配信されるエリアの広さに基づいて決定する機能を有する。

これにより、受信側において受信を完了している可能性の低い、狭い範囲に配信されるメディアデータを送信する送信周期を短くすることができる。この結果、受信側において必要なデータをすばやく受信することができる。

本発明の第３の態様は、第１の態様にかかるメディアデータ送信装置において、前記第２のデータは前記第１のデータと比較して情報量が多い。

これにより、受信側において情報量の多い、つまり必要な情報を詳細に取得することができる。

本発明の第４の態様は、第１の態様にかかるメディアデータ送信装置において、前記第１のデータはコンテンツの要約情報のデータであり、前記第２のデータはコンテンツの詳細情報のデータである。

これにより、要約情報をすばやく受信して、受信端末のユーザにコンテンツの概要をすばやく提示することができ、ユーザのコンテンツ受信待ち時間によるストレスを少なくすることができる。

本発明の第５の態様は、第４の態様にかかるメディアデータ送信装置において、前記詳細情報のデータに電子署名を付与する電子署名付与部を具備し、前記伝送管理部は前記要約情報のデータに公開鍵証明書を付与する機能を有する。

これにより、送信先において、不正なメディアデータを起動して、送信先の端末が不正な動作を行うことがなくなる。

本発明の第６の態様は、第１の態様から第５の態様のいずれかにかかるメディアデータ送信装置において、前記高必要データと、前記低必要データと、に互いを対応付ける識別子を付与して送信する。

これにより、送信先で、同じ番号を付けた識別子が付与された高必要データと低必要データの間に対応関係があることがわかるようになる。

本発明の第７の態様は、第２の態様にかかるメディアデータ送信装置において、前記第１のデータは送信先エリアの詳細な地図データであり、前記低必要データは前記エリアに隣接するエリアのおおまかな地図データである。

これにより、送信先が現在必要とする可能性が高い送信先エリアについては詳細な地図を、送信先が現在必要とする可能性の低い送信先エリアの周辺の地図についてはおおまかな地図を送信することができる。これにより、限られた伝送帯域でも、送信先端末のユーザに、ユーザが必要とする情報を適切に提示することができる。

本発明の第８の態様にかかるメディアデータ受信装置は、第１の態様のメディアデータ送信装置から送られる、前記第１のデータおよび前記第２のデータを受信する伝送部と、受信した前記第１のデータおよび前記第２のデータを対応させて蓄積する蓄積管理部と、前記第２のデータと前記第２のデータに対応する前記第１のデータとを用いて所定の処理を行う実行部と、を有する。

これにより、第１のデータをすばやく受信でき、コンテンツ全体を更新しなくても、コンテンツを最新の状態に保つことができる。

本発明の第９の態様は、第８の態様にかかるメディアデータ受信装置において、前記第１のデータもしくは前記第２のデータを受信した際に、前記第１のデータもしくは前記第２のデータの受信動作を停止する。

これにより、既に受信したデータと同じデータを引き続き受信することを防止でき、コンテンツ受信のための電力を削減することができる。

本発明の第１０の態様は、第９の態様にかかるメディアデータ受信装置において、前記第１のデータもしくは前記第２のデータの受信動作を停止後に、受信動作を停止したことを利用者に通知する。

これにより、利用者が、更新した最新のデータがあることを認識でき、現在使っているデータではなく更新したデータを用いるようにできる。

本発明の第１１の態様にかかるメディアデータ受信装置は、第５の態様のメディアデータ送信装置から送られる、要約情報のデータおよび詳細情報のデータを受信する伝送部と、前記要約情報のデータから公開鍵証明書を取得し、前記詳細情報のデータから電子署名を取得し、前記公開鍵証明書と、前記詳細情報のデータと、前記電子署名を用いて前記詳細情報が改ざんされていないことを確認する認証部を有する。

これにより、不正なメディアデータを起動して、端末が不正な動作を行うことがなくなる。

本発明の第１２の態様は、第１の態様のメディアデータ送信装置から個別に送られる、前記第１のデータおよび前記第２のデータを受信するステップと、受信した前記第１のデータおよび前記第２のデータを対応させて蓄積するステップと、前記第２のデータと前記第２のデータに対応する前記第１のデータとを用いて所定の処理を行うステップと、を有することを特徴とするメディアデータ受信方法である。

これにより、第１のデータをすばやく受信でき、コンテンツ全体を更新しなくても、コンテンツを最新の状態に保つことができる。

本発明の第１３の態様は、第１２の態様にかかるメディアデータ送信方法において、前記第１のデータもしくは前記第２のデータを受信した際に、前記第１のデータもしくは前記第２のデータの受信動作を停止するステップを有する。

これにより、既に受信したデータと同じデータを引き続き受信することを防止でき、コンテンツ受信のための電力を削減することができる。

本発明の第１４の態様は、第１３の態様にかかるメディアデータ受信方法において、前記第１のデータもしくは前記第２のデータの受信動作を停止後に、受信動作を停止したことを利用者に通知するステップを有する。

これにより、利用者が、更新した最新のデータがあることを認識でき、現在使っているデータではなく更新したデータを用いるようにできる。

本発明の第１５の態様は、第１の態様のメディアデータ送信装置と、第８の態様のメディアデータ受信装置と、を具備したことを特徴とするコンテンツ配信システムである。

（実施の形態１）
以下、本発明の実施の形態１にかかるコンテンツ配信システムについて添付図面を用いて説明する。まず、実施の形態１にかかるコンテンツ配信システムの通信網の利用形態について、図１（ａ）〜図１（ｃ）を用いて説明する。図１（ａ）〜図１（ｃ）は、実施の形態１における通信網の利用形態を示す構成図である。

図１（ａ）に示すように、実施の形態１にかかるメディア配信システムは、メディアデータ送信装置であるサーバ１０２から、チャンネル情報とコンテンツを送信し、メディアデータ受信装置である受信端末１０４は、まず、チャンネル情報を受信し、そのチャンネル情報に基づいてコンテンツを受信する。

実施の形態１では、伝送するコンテンツは、プログラム、プログラムの動作ルール、プログラムが入力として利用するプログラム用データ、動画、音声、音楽、テキスト、静止画やメディアをどのように配置するかを決定するレイアウト情報などを含んでいる。

チャンネル情報は、規定のチャンネルに送信される、コンテンツを受信するために必要なコンテンツを構成する各メディアデータを受信する受信ポートを表す情報を含んでいる。チャンネル情報は、さらに、セッションタイトル、セッションの開始時刻、終了時刻、コンテンツとして送信しているデータの種別、あて先チャンネル、送信される各メディアデータの名前、メディアデータに付与された電子署名を作成する際に用いた秘密鍵に対応する公開鍵の証明書、もしくは証明書へのリンク情報といった情報を含んでいる。

通信網１０１は、有線網（例えば、ＡＤＳＬ、ＩＳＤＮ、ＡＴＭ、ＦＴＴＨなど）であっても無線網（例えば、携帯電話、無線ＬＡＮなど）であってもよい。また、図１（ｂ）に示すように、通信網１０１は、有線網と無線網が相互接続された通信網であってもよい。

さらに、図１（ｃ）に示すように、サーバ１０８が各所に存在し、近傍の領域にデータをブロードキャストし、受信端末１０９がデータを受信する通信形態であってもよい。このような通信形態の場合には、伝送プロトコルとして、ＢｌｕｅＴｏｏｔｈ、無線ＬＡＮなどを利用する。

また、実施の形態１で用いる伝送プロトコルは、インターネット・プロトコルを用い、通信機器（サーバ１０２、受信端末１０４）はルータやＧＷ（ゲートウェイ）といった中継ノード１０３で相互接続される。ルータやＧＷは、ブロードキャストやマルチキャスト機能を備え、ルータやＧＷでデータパケットを複製することができる。

また、コンテンツの伝送方法としては、サーバ１０２と受信端末１０４間で１対１型の通信を行ってもよいし、ブロードキャストやマルチキャスト機能を用いて、１対Ｎ型の通信を行ってもよい。

受信端末１０４は、携帯電話、ＴＶ、ＰＤＡ、パソコンなどである。また、受信端末１０４は、携帯電話、ＴＶ、ＰＤＡ、パソコンなど表示解像度や処理能力が異なる受信端末が同時に複数存在しても良い。

また、コンテンツを配信するサーバ１０２も、複数存在し、受信端末１０４で、複数のサーバ１０２から同時にコンテンツを受信してもよい。さらに、受信端末１０４は、複数の伝送路に接続する機能を有することもできる。

さらに、通信網１０１だけではなく、放送網（例えば、地上波デジタル放送、衛星デジタル放送など）や、放送網と通信網を融合したシステム構成であってもよい。

また、携帯電話のように、移動する受信端末へコンテンツを放送する場合、地域毎に、異なるコンテンツを放送したいという要望もある。その場合、サーバから複数の受信端末に、ブロードキャストもしくは、マルチキャストした場合、位置に応じて、放送内容を変更するのは容易ではない。

そこで、位置に応じた放送を実現するために、図１（ｂ）の例では、サーバ１０５と中継ノード１０６間は１対１のユニキャストで通信し（有線網の区間）、中継ノード１０６と受信端末１０７間は、無線網を用いたブロードキャスト機能を利用して配信する。ブロードキャスト機能を実現する中継ノード１０６は、他の中継ノード１０６をまたがって、パケットをブロードキャストすることはない。

次に、実施の形態１にかかるコンテンツ配信システムのコンテンツ配信の概要について図２を用いて説明する。図２は、実施の形態１にかかるコンテンツ配信システムの利用形態を示す図である。

なお、以下の説明では、中継ノード１０３、受信端末１０４を用いて説明をするが、中継ノード１０６、受信端末１０７、１０９であっても良い。

中継ノード１０３ａ〜１０３ｃは、それぞれ配信エリア１１３０〜１１３２へデータを配信している。

メディアデータ送信装置であるサーバ（送信端末）１０２は、中継ノード１０３ａにプログラム１１０１と動作ルール１（１１０２）を送信し、中継ノード１０３ｂにプログラム１１０１と動作ルール２（１１０３）を送信し、中継ノード１０３ｃにプログラム１１０１と動作ルール３（１１０４）を送信する。

このとき、動作ルール１〜３（１１０２〜１１０４）は、プログラム１１０１から参照される、異なる動作ルールである。

また、チャンネル情報、中継ノード１０３ａ〜１０３ｃで共通のデータを送信するものとする。

このような送信を行った場合、共通データであるプログラム１１０１は、全ての配信エリア１１３０〜１１３２で使用できる。例えば、配信エリア１１３０で受信したプログラム１１０１は、配信エリア１１３１、１１３２で流用することができるようになる。

したがって、受信端末１０４が、配信エリア１１３０から配信エリア１１３１、１１３２に移動した際に、受信端末１０４は共通のデータであるプログラム１１０１を流用できるので、更新すべきデータが少なくてすむ。

また、伝送路上でパケットがロスすることを考慮すると、更新すべきデータの量が少ないほうが、全てのデータを完全に受信するまでの時間が短くなる。このため、図２のように配信することで、受信待ち時間が短くなる。

また、本コンテンツ配信システムは、メディアデータの配信エリアが狭いほどそのメディアデータの送信周期を短く設定する。すなわち、図２に示す例では、プログラム１１０１の送信周期を長く設定し、動作ルール１１０２〜１１０４の送信周期を短く設定する。受信端末１０４が移動しながらコンテンツを受信する場合を考えると、受信端末からはプログラム１１０１は変化せず、動作ルール１１０２〜１１０４は変化するように見える。よって、メディアデータの配信エリアが狭いほどそのメディアデータの送信周期を短く設定することで、受信端末にとって更新頻度が高く見える動作ルール１１０２〜１１０４の送信頻度が高くなり、受信端末にとって頻繁に更新するデータである動作ルール１〜３（１１０２〜１１０４）を受信するための待ち時間がより短くなる。これにより、受信端末は、コンテンツをすばやく最新の状態に保つことができるようになる。

次に、実施の形態１にかかるコンテンツ配信システムの構成について図３を用いて説明する。図３は、実施の形態１にかかるコンテンツ配信システムの構成図である。

このシステムにおいて、受信端末１０４は、まず、チャンネル情報を規定のチャンネルより受信し、チャンネル情報に記載されるコンテンツの受信用チャンネルをオープンし、コンテンツを受信する。

また、チャンネルは、あて先アドレスとあて先ポート番号の組で表される。

また、メディアデータ送信装置であるサーバ（送信端末）１０２は、複数のコンテンツの送信を管理するものとする。

次に、サーバ１０２の構成について説明する。

送信データ蓄積部２０１は、コンテンツ２０１ａと、受信端末１０４においてコンテンツ２０１ａの認証を行う際に必要となる証明書２０１ｂ、および、証明書２０１ｂに含まれる公開鍵に対応する秘密鍵２０１ｃを蓄積する手段である。具体的には、送信データ蓄積部２０１は、ハードディスクドライブに代表される蓄積媒体である。

コンテンツ２０１ａは、エリアによらず共通なデータであるプログラムと、エリアによって異なる動作ルールおよびプログラム用データとからなる。プログラム用データは、画像データや、テキストデータや、音声データや、音楽データなどである。

また、証明書２０１ｂは、公開鍵証明書のことであり、公開鍵データ（電子署名の暗号を復号するのに用いる）、公開鍵所有者の情報、証明書の有効期間、証明書を発行した認証局の情報などを組み合わせたものに、ベリサイン（ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｓｉｇｎ．ｃｏ．ｊｐ／）などの認証局が電子署名を行ったものである。これにより、公開鍵の所有者の正当性が、認証局によって保証される。

送信管理部２０２は、コンテンツの放送スケジュールを管理する手段である。送信管理部２０２は、予め指定された各コンテンツの放送開始時刻になると、送信データ蓄積部２０１からコンテンツ２０１ａを構成する各メディアデータを個別に取得し、メディアデータ毎に、一定のサイズに分割して、署名付与部２０３に送信する。

また、本実施の形態にかかるコンテンツ配信システムでは、ＤＳＭ−ＣＣのように、コンテンツを定められた送信周期で繰り返し送信する。送信管理部２０２は、コンテンツの送信周期を決定する。メディアデータの送信周期は、そのメディアデータの配信エリアが広いほど長くなるよう決定される。例えば、（送信周期定数）×（配信先基地局の数）といった式により決定する。ここで、送信周期定数は送信装置の管理者により設定される値であり、配信エリアが１だったときの送信周期である。また、配信エリアの数は、そのメディアデータを配信する中継装置１０３ａ、１０３ｂ、１０３ｃの数を表している。図２の例では、プログラム１１０１は配信エリアの数が３であり、動作ルール（１１０２〜１１０４）は配信エリアの数が１である。したがって、この例では、プログラム１１０１は動作ルール１１０２〜１１０４の３倍の周期で送信されることになる。

また、送信管理部２０２は、終了時刻になると、コンテンツの送信を終了する。また、送信管理部２０２は、コンテンツ送信開始時に、送信を開始したコンテンツの情報（コンテンツのタイトル、送信開始時刻、終了時刻、コンテンツとして送信する各メディアデータの種別、名前）をチャンネル情報生成部２０６に送信し、コンテンツ送信終了時に、そのコンテンツの送信終了を伝送部２０５に通知する機能を有する。

なお、コンテンツの送信開始時刻、送信終了時刻および、コンテンツとして送信するデータのファイル名、コンテンツを構成する各メディアデータの配信エリア、送信周期定数は、設定ファイルなどを用いて指定してもよいし、ＧＵＩなどを用いて指定する仕組みとしてもよい。

署名付与部２０３は、送信管理部２０２から送信されるメディアデータに、電子署名を生成し、データに付与する手段である。署名付与部２０３が、電子署名を生成するために使用する秘密鍵２０１ｃは、送信データ蓄積部２０１より取得する。なお、電子署名は、署名付与部２０３で生成しなくても、コンテンツ作成者が予め生成して用意しておいてもかまわない。

ここで、電子署名とは、コンテンツが正当な発信者によって作成・配信され、途中で改ざんなどが行われていないことを示すためのものである。具体的にはハッシュ関数（例えば、ＭＤ５やＳＨＡ）を用いてコンテンツデータからハッシュ値を生成し、コンテンツ発信者の持つ秘密鍵を用いて暗号化したものである。また、電子署名の方式としては、ＭＤ５、ＳＨＡなどの方式を用いることを想定している。証明書と電子署名を配信することにより、受信端末が、不正なコンテンツを起動して、端末が不正な動作を行うことがなくなる。

識別子付与部２０４は、署名付与部２０３から送信されたコンテンツ２０１ａのプログラム、動作ルール、プログラム用データに、対応関係（プログラムがどの動作ルールを参照するか、どのデータを参照するか）を示す識別子を付与する。

識別子付与部２０４は、識別子として、対応するプログラム、動作ルール、プログラム用データに、同じ番号を付与する。言い換えると、識別子付与部２０４は、コンテンツ毎に異なる番号を付与する。

これにより、受信端末１０４において、同じ番号を付与されたプログラム、動作ルール、プログラムの間に、対応関係があることがわかるようになる。

また、識別子付与部２０４は、識別子を付与したデータを伝送部２０５に送信する機能を有する。

チャンネル情報生成部２０６は、送信管理部２０２から通知された情報と、送信データ蓄積部２０１に蓄積された証明書２０１ｂに基づき、各コンテンツ２０１ａのチャンネル情報を生成する手段である。

チャンネル情報は、セッションタイトル、セッションの開始時刻、終了時刻、コンテンツとして送信しているデータの種別、あて先チャンネル、送信される各メディアデータの名前、メディアデータに付与された電子署名を作成する際に用いた秘密鍵に対応する公開鍵の証明書、もしくは証明書へのリンク情報といった情報を含んでいる。

チャンネル情報記述用のプロトコルとしては、ＳＤＰに代表されるセッション記述用のプロトコルを想定している。具体的なチャンネル情報の例は後述する。

また、チャンネル情報も、定期的に繰り返し送信されるものとする。

このように、サーバ１０２が受信端末１０４に対してメディアデータと共にチャンネル情報を用いてあて先チャンネルを送信することにより、サーバ１０２がメディアデータを任意のチャンネルに送信しても、受信端末１０４がチャンネル情報のあて先チャンネルを用いてメディアデータを受信することが可能となる。

また、チャンネル情報は、セッションタイトル、セッションの開始時刻、終了時刻、コンテンツとして送信しているデータの種別、送信される各メディアデータの名前、といった情報を含んでいるので、サーバ１０２から受信端末１０４にチャンネル情報を送ることにより、サーバ１０２がコンテンツに含まれるメディアデータを任意のチャンネルに送信しても、受信端末１０４においてコンテンツに含まれるメディアデータを対応させることができ、コンテンツに含まれるプログラムが正しく対応する動作ルール、プログラム用データなどを受信することが可能となる。

伝送部２０５は、ネットワーク（通信網）１０１に接続するインターフェース機能を有する。また、識別子付与部２０４から受信したデータをパケット化し、ネットワーク１０１に送信する機能を有する。また、伝送部２０５は、送信管理部２０２が設定した送信周期でデータを送信する。

サーバ１０２は、以上のような構成からなる。

次に、受信端末１０４の構成について説明する。

伝送部２１１は、ネットワーク１０１よりチャンネル情報およびコンテンツ２０１ａを受信し、パケットをほどく。そして、伝送部２１１は、受信したデータがチャンネル情報であれば受信チャンネル選択部２１２に、コンテンツ２０１ａであれば蓄積管理部２１４に送信する手段である。

また、伝送部２１１は、受信チャンネル選択部２１２の指示により、コンテンツ２０１ａの受信チャンネルをオープンする機能を有する。また、伝送部２１１は、受信チャンネル選択部２１２から指定されたチャンネルが、ＵＲＬであった場合には、ＵＲＬに基づいてデータをＵＲＬで示されるサーバから取得する手段である。

受信チャンネル選択部２１２は、伝送部２１１から通知される複数のチャンネル情報から、受信するコンテンツ２０１ａを選択する手段である。受信チャネル選択部２１２のチャンネル選択の方法としては、チャンネル情報のうち、コンテンツ２０１ａのタイトルをユーザに提示し、ユーザにコンテンツ２０１ａを選択させる方法であってもよいし、最初に受信したチャンネル情報のコンテンツ２０１ａを受信するなど自動的に選択することとしてもよい。

また、受信チャンネル選択部２１２は、コンテンツ２０１ａを選択した際に、チャンネル情報に記載されるチャンネル情報に基づいて、オープンするチャンネルを伝送部２１１に通知する。また、受信チャンネル選択部２１２は、プログラム実行部２１６から、ＵＲＬを受信した場合には、ＵＲＬに基づいてサーバからデータを取得する。

また、受信チャンネル選択部２１２は、チャンネル情報にコンテンツ認証用の証明書２０１ｂが含まれている場合には、認証部２１３に選択されたチャンネルの証明書２０１ｂを送信する機能を有する。

また、受信チャンネル選択部２１２は、蓄積管理部２１４から、プログラム、動作ルール、プログラム用データの受信完了通知を受信すると、データの受信を停止するよう設定されていて、プログラム、動作ルール、プログラム用データの受信用チャンネルをクローズして受信を終了する機能を有する。

蓄積管理部２１４は、受信したメディアデータを受信データ蓄積部２１５に蓄積する。蓄積管理部２１４は、受信したメディアデータの蓄積を行う際には、メディアデータに付与された識別子に基づいて、プログラム、動作ルール、プログラム用データを対応付けて蓄積する。

ここで、対応付けて蓄積するとは、同じ識別子を付与されたプログラムと動作データとプログラム用データとが同じコンテンツを構成することがわかるように蓄積することである。例えば、蓄積管理部２１４は、プログラムと、動作ルール、プログラム用データを識別子と同じ名前のディレクトリに蓄積する。また、蓄積管理部２１４は、保存時の各メディアデータのファイル名を、チャンネル情報に記載された、メディアデータの名前とする。

また、蓄積管理部２１４は、メディアデータに電子署名データが付与されていた場合には、その電子署名データもメディアデータと対応付けて保存しておく。

ここで、電子署名データをメディアデータに対応付けて保存するとは、電子署名データが、どのメディアデータの電子書名であるかがわかるように保存することである。例えば、“（メディアデータ名）＿Ｓｉｇｎ”といった名前で、メディアデータと同じディレクトリに保存することを意味する。

また、蓄積管理部２１４は、分割されたメディアデータを全て受信した場合には、分割されたデータを結合する。そして、蓄積管理部２１４は、メディアデータに付与されている電子署名とメディアデータを認証部２１３に送信し、認証部２１３から認証成功の通知を受信した場合には、そのメディアデータをプログラム実行部２１６に送信する機能を有する。

また、蓄積管理部２１４は、プログラム、動作ルールを受信完了した際に、受信チャンネル選択部２１２に受信完了通知を送信する。

認証部２１３は、受信チャンネル選択部２１２からの証明書データを受け取って、蓄積管理部２１４からメディアデータと対応する電子署名を受け取り、コンテンツ２０１ａが確かにその証明書２０１ｂを発行された組織により生成（もしくは送信）されたものであることを認証し、認証結果を蓄積管理部２１４に通知する。

プログラム実行部２１６は、蓄積管理部２１４から通知されたプログラムを受信して実行する。このとき、プログラム実行部２１６は、プログラムに動作ルールへの参照が含まれている場合には、蓄積管理部２１４に参照プログラムを送信するよう要求する。

また、プログラム実行部２１６は、プログラムがＵＲＬで示されるコンテンツにアクセスしようとした場合には、まず、プロファイル設定・格納部２１７に格納されるセキュリティプロファイル（ネットワークへの接続許可）を参照する。そして、プログラム実行部２１６は、そのＵＲＬへのアクセスがセキュリティプロファイルに違反しなければ、ＵＲＬを受信チャンネル選択部２１２に送信して、ＵＲＬのデータを取得するよう通知する。

また、プログラム実行部２１６は、ユーザプロファイルへのアクセスを行う記述がなされている場合には、まず、セキュリティプロファイル（ユーザプロファイルへのアクセス許可）を参照する。そして、プログラム実行部２１６は、そのユーザプロファイルへのアクセスがセキュリティプロファイルに違反しなければ、プロファイル設定・格納部２１７に格納されるユーザプロファイルを参照する。

また、プログラム実行部２１６は、受信端末の現在位置を取得するよう記述されている場合には、セキュリティプロファイル（位置情報へのアクセス許可）を参照する。そして、プログラム実行部２１６は、位置情報へのアクセスがセキュリティプロファイルに違反しなければ、位置情報取得部２１８より現在位置の情報を取得する。

表示部２１９は、ユーザにプログラムの処理結果を提示する手段である。具体的にはＣＲＴやＬＣＤなどの映像表示手段やスピーカなどの音声出力手段、さらに、携帯電話などに搭載されるバイブレータなどである。また、コンテンツをユーザに選択させる場合には、表示部２１９は、受信チャンネル選択部２１２がチャンネル情報を表示するためにも用いられる。

プロファイル設定・格納部２１７は、端末プロファイル、ユーザプロファイル、セキュリティプロファイルなどの各種プロファイルを設定、格納する手段である。

ユーザプロファイル、セキュリティプロファイル設定は、例えば、図４に示すＧＵＩを用いて行う。図４は、実施の形態１にかかるプロファイルの設定方法を説明する図である。

図４に示すＧＵＩでは、ユーザプロファイル３０１として、書籍、音楽、アウトドア、車、映画、ゲーム、野球、サッカーなどユーザの興味の対象である項目が表示されている。

そして、ユーザが、ユーザプロファイル３０１の項目のチェックボックスにチェックを入力することで、ユーザプロファイル３０１を設定する。

また、図４に示すＧＵＩにはセキュリティプロファイル３０２として、ネットワーク、ファイル、ユーザプロファイル、位置情報へのアクセスを許可する項目が表示されている。

ユーザが、プログラム実行の際の各資源（ネットワーク、ファイル、ユーザプロファイル、位置情報）へのアクセスを許可する項目にチェックを入力することでセキュリティプロファイル３０２の設定を行う。

位置情報取得部２１８は、受信端末１０４の現在位置を取得する手段である。具体的には、ＧＰＳや、携帯電話や無線ＬＡＮの基地局情報や、ＲＦ−ＩＤタグ、無線ビーコンなどの発する電波などを利用した位置特定手段である。また、位置情報取得部２１８は、取得した位置情報をプログラム実行部２１６に送信する機能を有する。位置情報としては、緯度・経度の情報や、ＧＰＳデータや、関連するエリアの基地局の番号や、住所・地名や、郵便番号や、電話番号などを用いる。

このように受信端末１０４は構成されている。

次に、サーバ１０２が、コンテンツとして、プログラム、動作ルール、プログラム用データを送信する場合のチャンネル情報について図５を用いて説明する。図５は、実施の形態１にかかるチャンネル情報を記述した図である。

図５に示すチャンネル情報８００は、ＳＤＰを用いて記述されている。

チャンネル情報８００の８０１で示される部分は、ＳＤＰの仕様のとおりである。したがって、“ｃ＝”フィールドに記載されるＩＰアドレスあてに番組データが送信されることを示している。

チャンネル情報８００の８０２で示される部分は、証明書データのＵＲＬを示すものであり、このＵＲＬよりコンテンツを認証することができることを示している。また、この例では証明書はＵＲＬにより取得することになっているが、この部分８０２にＵＲＬではなく、証明書データ自体を付与することとしてもよい。

また、チャンネル情報８００の８０３で示される部分は、プログラムの配信に関する情報を示すデータである。

また、チャンネル情報８００の８０４で示される部分は、データをＲＴＰ／ＵＤＰ／ＩＰプロトコルを用いて、ＲＴＰのペイロードタイプを１００として、ポート番号１００００に送信することを示している。

また、チャンネル情報８００の８０５で示される部分は、ＲＴＰのペイロードタイプが１００のパケットは、Ｊａｖａ（Ｒ）プログラムであり、ＲＴＰのタイムスタンプのクロックレートが８０００であることを表している。

また、チャンネル情報８００の８０６で示される部分は、このアプリケーションの名前が“ｍａｉｎ”であることを示している。“ｍａｉｎ”は特別な意味を持つ名前であり、このｍａｉｎという名前が付与されたデータをまず最初にプログラムとして実行するというルールとなっている。

また、チャンネル情報８００の８０７で示される部分は、テキスト（プログラムの動作ルール）の配信に関する情報であり、フォーマットは８０３で示される部分と同等である。プログラムは、この動作ルールの名前（この例では、“ｒｕｌｅ”）を知っており、この名前に基づいて、動作ルールにアクセスすることができる。

また、チャンネル情報８００の８０８で示される部分は、テキスト（プログラム用データ）の配信に関する情報である。プログラムは、このプログラム用データの名前（この例では、“ｄａｔａ”）を知っており、この名前に基づいて、プログラム用データにアクセスすることができる。

以上のように、チャンネル情報８００は、チャンネルであるあて先ポート番号やペイロードタイプなど、コンテンツを受信するために必要な情報を含んだ構成になっている。

次に、プログラム、動作ルール、プログラム用データを送信するための伝送フォーマットについて、図６を用いて説明する。図６は、実施の形態１にかかる伝送フォーマットのヘッダを示す図である。

図６に示すヘッダ５００は、ＲＴＰのペイロードヘッダとして記述されている。

このペイロードフォーマットは、まず、ヘッダタイプ（Ｈｄ．Ｔｙｐｅ）によりヘッダの種別を区別し、続いて各ヘッダタイプの情報を格納する形になっている。また、各ヘッダタイプに関しては、固定長のものは、ヘッダ長が予め規定されており、固定長でないものは、ヘッダタイプフィールドより後方にヘッダ長を入力する。

ヘッダ５００の９０１で示される部分は、通常のＲＴＰヘッダ部である。

ヘッダ５００の９０２で示される部分は、ＩＤ情報ヘッダであることを示すフィールドである。図の例では、“１”という値がＩＤ情報ヘッダであることを表している。

ヘッダ５００の９０３で示される部分は、ＩＤ情報の長さをバイト単位で示している。図の例では、ＩＤ情報は３バイトなので、値は“３”となっている。

ヘッダ５００の９０４で示される部分は、コンテンツを一意に示すＩＤであり、１つのコンテンツ中で、プログラム、動作データ、プログラム用データ全てに共通の値を入力する部分である。

また、ヘッダ５００の９０５で示される部分は、データの種別を表すフィールドであり、プログラムならば“１”、動作ルールなら“２”、プログラムデータなら“３”といったように、各データの種別毎の予め規定された値を入力する部分である。

ヘッダ５００の９０６で示される部分は、バージョンフィールドであり、各メディアデータが更新された際に１ずつインクリメントされる。

ヘッダ５００の９０７で示される部分は、パケット数ヘッダであることを示すフィールドである。図の例では“５”がパケット数ヘッダであることを示す。

ヘッダ５００の９０９で示される部分は、このメディアデータが、いくつのパケットからなるかを示す。

ヘッダ５００の９０８で示される部分は、メディアデータを構成する複数のパケットのうち、このパケットが、先頭を１番として何番目のパケットにあたるかを示している。この情報９０８により、メディアデータパケットの輻輳やパケットロスによる欠落を周期的送信により補完することができる。

また、ヘッダ５００の９１１で示される部分は、有効化・無効化時刻ヘッダであることを示している。図の例では“１３０”が有効化時刻、無効化時刻ヘッダであることを示す。

また、ヘッダ５００の９１０で示される部分は、有効化時刻フィールドである。また、ヘッダ５００の９１２で示される部分は、無効化時刻フィールドである。有効化時刻フィールド９１０は、メディアデータがいつ有効になるかを示し、無効化時刻フィールド９１２は、メディアデータがいつ無効になるかをＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）時間により示している。

メディアデータが有効になるとは、プログラムであれば、プログラムが実行される時刻を表し、プログラムでなければ、そのメディアデータがプログラムに渡される時刻を示している。このフィールドが省略された場合には、そのメディアデータは、データ受信完了と共に有効化され、無効化はされないものとする。

ヘッダ５００の９１３で示される部分は、電子署名ヘッダであることを示すヘッダである。図の例では“１３１”が電子署名ヘッダであることを示す。

ヘッダ５００の９１４で示される部分は、電子署名のタイプ（ＭＤ５、ＳＨＡなど）を表すフィールドである。また、ヘッダ５００の９１５で示される部分は、電子署名データの長さを入力するフィールドである。

また、ヘッダ５００の９１６で示される部分は、電子署名データを入力する部分である。このデータ９１６は、受信端末がメディアデータを認証する際に用いられる。電子署名の情報は、ペイロードヘッダではなく、ペイロード本体に格納してもかまわない。この場合、ＲＴＰのペイロードタイプを用いて、メディアデータなのか電子署名データなのかを区別する方法がある。

また、プログラムの配信について、シーケンス番号が最大または、最小のパケットなど、一連のパケットの内どれか特定のパケットを予め選んでおき、そのパケットのペイロードを電子署名の情報にしてもかまわない。

その他、ＲＴＰのペイロードの中身がメディアデータなのか電子署名データなのかを区別する方法としては、チャンネル情報に記述する方法もある。その方法について、図７を用いて説明する。

図７に示すチャンネル情報２４０の２４００で示される部分は、プログラムの配信に関する情報を示すデータである。

チャンネル情報２４０の２４０１で示される部分は、データをＲＴＰ／ＵＤＰ／ＩＰプロトコルを用いて、ＲＴＰのペイロードタイプを９９、および、１００として、チャンネルであるポート番号１００００に送信することを示している。

チャンネル情報２４０の２４０２で示される部分は、ＲＴＰのペイロードタイプが９９のパケットは、Ｊａｖａ（Ｒ）プログラムであり、ＲＴＰのタイムスタンプのクロックレートが８０００であることを示している。

チャンネル情報２４０の２４０３で示される部分は、ＲＴＰのペイロードタイプが１００のパケットは、電子署名であり、ＲＴＰのスタンプのクロックレートが８０００であることを示している。

チャンネル情報２４０の２４０１で示される部分は、プログラムと電子署名を送るチャンネルに関する情報である。

このようにしても、ＲＴＰのペイロードの中身がメディアデータなのか電子署名データなのかを区別することができる。

なお、電子署名をペイロード本体に格納する場合、ＲＴＰペイロードヘッダ５００のフィールドの内、９１３〜９１６で示されるフィールドはなくなる。

ヘッダ５００の９１７で示される部分は、動作ルールヘッダであることを示している。図の例では、“１３２”が動作ルールヘッダであることを示す。

ヘッダ５００の９２１で示される部分は、アクションを表すフィールドであり、過去に送付した動作ルールに対して、追加するものなのか、上書きするものなのかを示すためのフィールドである。

また、ヘッダ５００の９１８で示される部分は、プログラムバージョンを示すフィールドであり、この動作ルールを適用できるプログラムのバージョンを示している。このフィールド９１８の値と、受信端末の保持しているプログラムを受信した際の、９０６のフィールドの値を比較し、９０６のフィールドの値（すなわち、受信端末の保持しているプログラムのバージョン）がこのフィールドの値を上回っている場合には、このパケットで送信される動作データを適用することができる。

ヘッダ５００の９１９で示される部分は、動作ルールヘッダであることを示している。図の例では、“０”が動作ルールヘッダであることを示す。また、ヘッダ５００の９２０で示される部分は、ペイロードデータを示している。

以上のようなヘッダ５００を用いて、プログラム、動作ルール、プログラム用データを送信する。

なお、上記フィールドは、パケット数フィールド以外はメディアデータに共通の値を持つヘッダとなるため、これらのヘッダは、全てのパケットに付与する必要はなく、メディアデータを構成するデータパケットうち、少なくとも１つ以上のデータパケットに付与すればよい。

次に、実施の形態１にかかる動作ルールについて図８を用いて説明する。図８は、実施の形態１にかかる動作ルールについてＳＱＬ記述を拡張して記述した例を示した図である。

動作ルール１０００の１００１で示される部分は、ｄａｔａという名前（名前はチャンネル情報に記載されている）のデータが更新された際に、“Ｂａｃｋｕｐ（）”という関数を“ＯＬＤ”を引数として呼び出すように規定している。

“Ｂａｃｋｕｐ（）”は、プログラムに実装される関数であり、引数で渡されたデータをバックアップとして保存する動作が記述されているものとする。また、“ＯＬＤ”は、データが更新される前のデータを示している。したがって、１００１で示される部分全体として、データ受信時に、前のデータのバックアップを取ることを示している。

また、動作ルール１０００の１００２で示される部分は、データ新しいデータを受信した際に、プログラムを再起動することを示している。

また、動作ルール１０００の１００３で示される部分は、２００３年０６月２３日２２時０９分００秒０００にプログラムを一時停止することを示している。

また、動作ルール１０００の１００４で示される部分は、北緯３５度１２分３４．００００秒００、東経１３５度１２分３４．００００秒に１０メートル以内に近づいた場合に、ユーザプロファイルとして、書籍に興味がある場合には、Ｓｔａｒｔ（）という関数を呼び出すことを示している。

Ｓｔａｒｔは、データの受信を開始する関数であり、“Ａ＿Ｓｔｏｒｅ”という名前のプログラム用データの受信を開始することを示している。

以上のように、動作ルール１０００は構成されている。

次に、サーバ１０２のコンテンツ配信動作について図９を用いて説明する。図９は、実施の形態１にかかるサーバ１０２のコンテンツ配信の動作フローチャートである。

サーバ１０２は、コンテンツ配信動作を、コンテンツの送信時刻になったときに起動する。

まず、サーバ１０２の送信管理部２０２がコンテンツを送信する地域（エリア）を選択する（ステップ４００）。

次に、サーバ１０２の送信管理部２０２が、他のコンテンツと重ならない識別子を生成する（ステップ４０１）。

続いて、サーバ１０２の送信管理部２０２が、コンテンツに含まれるメディアデータの送信周期を決定する（ステップ４３１）。

メディアデータの送信周期は、そのメディアデータの配信エリアが広いほど長くなるよう決定される。

例えば、（送信周期定数）×（配信先基地局の数）といった式により決定する。ここで、送信周期定数は送信装置の管理者により設定される値であり、配信エリアが１だったときの送信周期である。また、配信エリアの数は、そのメディアデータを配信する中継装置１０３ａ、１０３ｂ、１０３ｃの数を表している。図２の例では、プログラム１１０１は配信エリアの数が３であり、動作ルール（１１０２〜１１０４）は配信エリアの数が１である。したがって、この例では、プログラム１１０１は動作ルール１１０２〜１１０４の３倍の周期で送信されることになる。

このように、メディアデータの送信周期を、そのメディアデータの配信エリアが広いほど長くなるよう決定する。広い範囲に配信されているメディアデータは、多くの人がすでに受信している可能性が高いのに対して、狭いエリアに配信されているメディアデータはほとんどのユーザが受信していない可能性が高い。したがって、配信エリアの狭いデータの送信周期を短くすると、まだ受信していないデータの送信周期が短くなるため、受信待ち時間が短くなり、受信側において必要なデータをすばやく受信することができる。

続いて、送信管理部２０２は、送信データ蓄積部２０１を参照し、ステップ４００において選択したエリアに送信するコンテンツを形成する、プログラム、動作ルール、プログラム用データ、チャンネル情報を個別に送信する処理に入る（ステップ４２７）。

ここで、ステップ４２７は、ステップ４２７より垂直に降りる直線により表される各処理が、並列に動作することを表している。

プログラムの送信処理として、まず、送信管理部２０２は、送信データ蓄積部２０１から、ステップ４００で決定した配信エリアに送信するプログラムを取得する（ステップ４０２）。なお、プログラムは全てのエリアに対して配信する共通のデータであるので、ここで送信管理部２０２が取得するプログラムは他のエリアに対する処理で取得するプログラムと同一である。

次に、サーバ１０２の署名付与部２０３が、ステップ４０２において取得したプログラムの電子署名データを生成する（ステップ４０３）。

その後、サーバの送信管理部２０２は、ステップ４０２において取得したプログラムを分割する（ステップ４０４）。次に、署名付与部２０３が、分割したデータ毎に、ステップ４０３において生成した電子署名を付与する（ステップ４０５）。

なお、本実施の形態では、全てのデータに電子署名を付与しているが、代表されるデータだけに電子署名を付与して送信してもかまわない。また、電子署名のデータだけのパケットを送信してもかまわない。以下のルールやプログラム用データの送信についても同様である。

このように、プログラムに電子署名を付与することにより、チャンネル情報に付与されてくる証明書を用いて、受信端末１０４がプログラムを認証することが可能になり、不正なプログラムを起動して、端末が不正な動作を行うことがなくなる。

次に、署名付与部２０３が、ステップ４０５において電子署名を付与したデータに、ステップ４０１で生成した識別子を付与する（ステップ４０６）。そして、伝送部２０５が、ステップ４０６において識別子を付与したデータに、必要なパケットヘッダを付与し、送信管理部２０２が設定した送信周期で送信する（ステップ４０７）。

次に、サーバ１０２は、終了時刻を過ぎていなければ（ステップ４０８）、ステップ４０５の処理へ戻る。そして、サーバ１０２は、終了時刻になるまでステップ４０５からステップ４０８までを繰り返し、終了時刻になった時点で、処理を終了する。

次に、サーバ１０２の動作ルールの送信処理について説明する。

動作ルールの送信処理として、まず、送信管理部２０２は、送信データ蓄積部２０１から、ステップ４００で選択したエリアに対応する動作ルールを取得する（ステップ４０９）。なお、動作ルールはエリア毎に異なるデータであるので、ここで送信管理部２０２が取得する動作ルールと、他のエリアに対する処理で取得する動作ルールとは異なる。

次に、サーバ１０２の署名付与部２０３が、ステップ４０９において取得した動作ルールの電子署名データを生成する（ステップ４１０）。

その後、サーバの送信管理部２０２は、ステップ４０９において取得した動作ルールを分割する（ステップ４１１）。次に、署名付与部２０３が、分割したデータ毎に、ステップ４１０において生成した電子署名を付与する（ステップ４１２）。

このように、動作ルールに電子署名を付与することにより、チャンネル情報に付与されてくる証明書を用いて、受信端末１０４が動作ルールを認証することが可能になり、不正な動作ルールを使用して、端末が不正な動作を行うことがなくなる。

次に、署名付与部２０３が、ステップ４１２において電子署名を付与したデータに、ステップ４０１で生成した識別子を付与する（ステップ４１３）。そして、伝送部２０５が、ステップ４１３において識別子を付与したデータに、必要なパケットヘッダを付与し、送信管理部２０２が設定した送信周期で送信する（ステップ４１４）。

また、伝送部２０５は、ステップ４１４において、動作ルールの送信周期をプログラムの送信周期より短く設定することもできる。これにより、受信端末１０４は、受信端末１０４の移動に伴って更新が必要、つまり更新の頻繁な動作ルールをすばやく受信することができるようになり、更新の待ち時間を削減することができる。

次に、サーバ１０２は、終了時刻を過ぎていなければ（ステップ４１５）、ステップ４１２の処理へ戻る。そして、サーバ１０２は、終了時刻になるまでステップ４１２からステップ４１５までを繰り返し、終了時刻になった時点で、処理を終了する。

次に、サーバ１０２のプログラム用データ送信処理について説明する。

プログラム用データの送信処理として、まず、送信管理部２０２は、送信データ蓄積部２０１から、ステップ４００で選択したエリアに対応するプログラム用データを取得する（ステップ４１６）。なお、プログラム用データはエリア毎に異なるデータであるので、ここで送信管理部２０２が取得するプログラム用データと、他のエリアに対する処理で取得するプログラム用データとは異なる。

次に、サーバ１０２の署名付与部２０３が、ステップ４１６において取得したプログラム用データの電子署名データを生成する（ステップ４１７）。

その後、サーバの送信管理部２０２は、ステップ４１６において取得したプログラム用データを分割する（ステップ４１８）。次に、署名付与部２０３が、分割したデータ毎に、ステップ４１７において生成した電子署名を付与する（ステップ４１９）。

このように、プログラム用データに電子署名を付与することにより、チャンネル情報に付与されてくる証明書を用いて、受信端末１０４がプログラム用データを認証することが可能になり、不正なプログラム用データを使用して、受信端末１０４が不正な動作を行うことがなくなる。

次に、署名付与部２０３が、ステップ４１９において電子署名を付与したデータに、ステップ４０１で生成した識別子を付与する（ステップ４２０）。そして、伝送部２０５が、ステップ４２０において識別子を付与したデータに、必要なパケットヘッダを付与して送信する（ステップ４２１）。

また、伝送部２０５は、ステップ４２１において、プログラム用データの送信周期をプログラムの送信周期より短く設定することもできる。これにより、受信端末１０４は、受信端末１０４の移動に伴って更新が必要、つまり更新の頻繁なプログラム用データをすばやく受信することができるようになり、更新の待ち時間を削減することができる。

次に、サーバ１０２は、終了時刻を過ぎていなければ（ステップ４２２）、ステップ４１９の処理へ戻る。そして、サーバ１０２は、終了時刻になるまでステップ４１９からステップ４２２までを繰り返し、終了時刻になった時点で、処理を終了する。

次に、サーバ１０２の、チャンネル情報送信処理について説明する。

サーバ１０２は、送信データ蓄積部２０１から電子署名を認証するための証明書データを取得する（ステップ４２３）。

次に、サーバ１０２は、チャンネル情報を生成するのに必要なデータを取得し、ステップ４２３で取得した証明書データをあわせて、チャンネル情報を生成する（ステップ４２４）。その後、サーバ１０２は、伝送部２０５において、チャンネル情報をパケット化して送信する（ステップ４２５）。

このように、チャンネル情報に証明書を付与することにより、各メディアデータに付与された電子署名を用いて、受信端末１０４が、メディアデータの正当性を把握でき、不正なコンテンツを起動して、端末が不正な動作を行うことがなくなる。

そして、サーバ１０２は、終了時刻を過ぎていなければ（ステップ４２６）、ステップ４２５へ戻る。終了時刻がくるまでステップ４２５を繰り返し、処理を終了する。

このように、サーバ１０２は、プログラムと、動作ルールと、プログラム用データと、チャンネル情報を送信する。これにより、受信端末１０４が、チャンネル情報に基づいてプログラムと、動作ルールと、プログラム用データとを所定のチャンネルで受信できる。

また、サーバ１０２は、対応する、プログラムと、動作ルールと、プログラム用データと、チャンネル情報に共通の識別子を付けて送るので、受信端末１０４において、受信したプログラムと、動作ルールと、プログラム用データと、チャンネル情報の対応がとれる。また、識別子は、コンテンツ毎に異なるので、受信端末１０４が複数のコンテンツを同時に受信した場合でも、コンテンツを混同することなく受信して使用することができる。

なお、ステップ４２８は、ステップ４２８に入力する各処理が、全て完了した時点で、ステップ４２８より下に記述される処理に移行することを現す。

このようにして、サーバ１０２は、全てのエリアに対して共通なプログラムと、エリア毎に異なる動作ルールおよびプログラム用データと、チャンネル情報を送信する（ステップ４２９、ステップ４３０）。

次に、受信端末１０４のコンテンツ受信動作について説明する。まず、受信端末１０４がユーザにチャンネルを選択させる選択方法である場合の、チャンネル情報を取得して表示する動作について図１０を用いて説明する。図１０は、実施の形態１にかかる受信端末１０４がチャンネル情報を取得して表示する動作フローチャートである。

まず、受信端末１０４の受信チャンネル選択部２１２が、チャンネル情報を受信するためのチャンネルをオープンする（ステップ５０１）。このチャンネルは、予め規定されており、必ずこのチャンネルでチャンネル情報を受信できるものとする。

その後、受信チャンネル選択部２１２は、チャンネル情報受信まで待機し、送信されてきたチャンネル情報を受信し（ステップ５０２）、チャンネル情報からタイトル情報を抜き出して、ユーザに提示する（ステップ５０３）。

続いて、受信チャンネル選択部２１２は、ステップ５０２に戻り、次のチャンネル情報を受信するまで待機する。

次に、受信端末１０４が、受信するチャンネルを選択した際の動作について図１１を用いて説明する。図１１は、実施の形態１にかかる受信端末１０４がチャンネルを選択した際の動作フローチャートである。

まず、ユーザが表示部２１９に表示されたコンテンツを選択すると（ステップ６０１）、受信チャンネル選択部２１２は、選択されたコンテンツのチャンネル情報から各メディアデータの受信チャンネルを取得し、各メディアデータの受信チャンネルをオープンする（ステップ６０２）。

続いて、受信端末１０４の伝送部２１１が、オープンしたチャンネルからコンテンツデータ（プログラム、動作ルール、プログラム用データ）を受信し（ステップ６０３）、蓄積管理部２１４が受信したコンテンツを受信データ蓄積部２１５に蓄積する（ステップ６０４）。

次に、蓄積管理部２１４を全て受信したか判断する（ステップ６０５）。そして、コンテンツデータを全て受信した場合には、伝送部２１１はコンテンツデータの受信動作を停止する。

これにより、受信端末１０４は、既に受信したデータと同じデータを引き続き受信することを防止でき、コンテンツ受信のための電力を削減することができる。

一方、コンテンツデータを全て受信した場合には（ステップ６０５）、認証部２１３が、プログラムの認証を行う（ステップ６０６）。

このように、プログラムの認証を行うことにより、受信端末１０４が、プログラムの正当性を把握でき、不正なプログラムを起動して、端末が不正な動作を行うことがなくなる。

そして、認証部２１３による認証が失敗した場合には（ステップ６０７）、プログラム実行部２１６は、プログラムの実行は行わずに終了する（ステップ６０８）。

一方、認証結果が成功であった場合には、プログラム実行部２１６は、プログラムの有効化時刻を過ぎているかどうかをチェックする（ステップ６０９）。

有効化時刻を過ぎていなければ、プログラム実行部２１６は、有効化時刻まで停止する（ステップ６１０）。

一方、有効化時刻を過ぎていれば、プログラム実行部２１６は、続いて無効化時刻を過ぎていないかどうかをチェックする（ステップ６１１）。

そして、プログラム実行部２１６は、無効化時刻を過ぎていた場合には終了し（ステップ６１２）、無効化時刻を過ぎていない場合には、プログラムを実行する（ステップ６１３）。

次に、プログラム実行部２１６は、受信するコンテンツが、プログラムを含めて更新される可能性があるため、メディアデータの更新を監視し（ステップ６１４）、メディアデータの変化があった場合にはステップ６０３に戻る。

メディアデータの変化があった場合には、プログラム実行部２１６は、ステップ６０３において、変化のあったメディアデータのみを受信するようにする。

このように、更新する必要のあるメディアデータのみを更新することにより、コンテンツ受信動作の高速化が図れる。

また、受信端末１０４は、変化したメディアデータの受信動作停止後に、受信動作を停止したことを利用者に通知する。

これにより、利用者が、更新した最新のメディアがあることを認識でき、現在使っているメディアデータではなく更新したメディアを用いてプログラム再生を行えるようにできる。

なお、プログラム実行部２１６がメディアデータの更新を検出する方法としては、データパケットのヘッダ部分にメディアデータを一意に決定する識別子を付与し、識別子の変化に基づいて、検出する方法を想定している。

また、動作データおよびプログラム用データは、エリア毎に異なるデータであるので、位置情報取得部２１８が受信端末１０４の存在するエリアが変わってことを検出した場合に、動作データおよびプログラム用データが更新されたとしても良い。

また、伝送部２１１がプログラム用データを受信した場合（ステップ６１５）には、蓄積管理部２１４は、プログラム実行部２１６にデータを渡す（ステップ６１６）。

また、プログラム実行部２１６は、プログラムの無効化時刻を過ぎた場合には（ステップ６１７）、プログラムを停止し、必要ならば削除する（ステップ６１８）。

なお、上記動作において、認証失敗や無効化時間を過ぎておりプログラムを実行できなかった場合、必要であれば、ユーザにプログラムの実行に失敗したことを通知することとしてもよい。

このように、受信端末１０４は、プログラムを実行する。また、受信端末１０４は、メディアデータの更新があった場合は、更新しプログラムを実行する。

次に、受信端末１０４が、プログラムを実行する処理（ステップ６１３で起動される処理）について図１２を用いて説明する。図１２は、実施の形態１にかかる受信端末１０４のプログラム実行のフローチャートである。

まず、プログラム実行部２１６は、引数として渡されるプログラムの起動処理を実行する（ステップ７０１）。次に、プログラム実行部２１６は、ルール参照があったか判断し（ステップ７０２）、ルール参照がある場合には、参照されている動作ルールが蓄積されているかどうかを確認する（ステップ７０３）。

蓄積されていない場合には、プログラム実行部２１６は、その動作ルールの受信待ちを行う（ステップ７０４）。

ルール受信完了後、プログラム実行部２１６は、受信動作完了設定がＯＮになっている場合には（ステップ７０５）、受信チャンネルをクローズして、受信処理を終了し、受信処理を停止したことを受信端末の利用者に通知する（ステップ７０６）。

受信処理完了設定は、ユーザが設定してもよいし、受信端末の残り電力を判定し、残り電力がある閾値よりも少ない場合に自動的にＯＮに設定されるものとしてもよい。受信処理の終了は、データの受信分の消費電力を節約することができ、特に移動体端末に対して有効である。

その後、プログラム実行部２１６は、動作ルールの認証処理を行い（ステップ７０７）、認証に失敗した場合には（ステップ７０８）、処理を終了する（ステップ７０９）。

このように、動作ルールの認証を行うことにより、不正な動作ルールを使用して、端末が不正な動作を行うことがなくなる。

一方、認証に成功した場合には、プログラム実行部２１６は、動作ルールを読み込んで解釈する（ステップ７１０）。

動作ルールには、イベント駆動型の動作ルールが記述されており、プログラム実行部２１６は、イベントを登録し（ステップ７１１）、イベントが発生すると（ステップ７１２）、イベントに対応した動作を動作ルールに従って行う（ステップ７１３）。

また、プログラム実行部２１６は、プログラムの実行終了指示を受信したかどうかを確認し（ステップ７１４）、イベントが発生していない場合には、ステップ７１２に戻る。

そして、プログラム実行部２１６は、プログラムの実行終了処理を受信すると、プログラムの実行を終了する（ステップ７１５）。

なお、発生するイベントとしては、タイマーイベント（指定された時刻、もしくは一定時間後に発生するイベント）、位置イベント（指定された領域に入った、もしくは出た際に発生するイベント）、データ受信イベント（指定したデータを受信した際に発生するイベント）、データアクセスイベント（指定されたデータにアクセスされた際に発生するイベント）などを想定している。

また、ステップ７０２において、ルール参照がない場合には、ステップ７１１の処理に移行する。

このようにして、プログラム実行部２１６は、プログラムを実行する。

以上説明したように実施の形態１によれば、サーバ１０２が、全てのエリアに対して共通、つまりあまり更新が頻繁でない少更新データ、言い換えればあまり更新の必要性の高くなり低必要データであるプログラムを複数の配信エリアに、エリア毎に異なる、つまり更新が頻繁な多更新データ、言い換えれば更新の必要な高必要データである動作ルールおよびプログラム用データを個々の配信エリアに伝送することができる。このように、全てのエリアに共通なプログラムと、エリア毎に異なるデータである動作ルールおよびプログラム用データを個別に送信することにより、受信端末１０４の移動に伴って、更新の頻繁な動作ルールおよびプログラム用データのみを、受信端末１０４で更新することができる。そして、受信端末１０４が、既に受信してあるプログラムを流用することにより、コンテンツ全体（プログラム、動作ルール、プログラム用データ）を更新しなくても、コンテンツを現在の位置に適応した最新の状態に保つことができ、動作するプログラムを最新の状態に保つことができる。

また、伝送路上でパケットがロスすることを考慮すると、実施の形態１のように、更新すべきデータの量が少ないほうが、全てのデータを完全に受信するまでの時間が短くなるため、受信待ち時間が短くなる。

また、実施の形態１によれば、頻繁に更新する必要のある動作ルールおよびプログラム用データの送信周期を、あまり更新する必要のないプログラムの送信周期より短くできる。これにより、受信端末１０４は、頻繁に更新するデータをすばやく受信でき、コンテンツの更新をスムーズに行うことができる。

なお、実施の形態１では、コンテンツを位置に関わらず共通なデータ（プログラム）と、位置に応じて異なるデータ（動作ルールおよびプログラム用データ）から構成したが、コンテンツを所定の条件に関わらず共通な共通データと、所定の条件に適応した条件適応データとから構成しても良い。そして、サーバが、共通データと、所定の条件に応じた条件適応データを、個別に送信するようにしても良い。

所定の条件としては、端末情報、ユーザ情報、時間情報などが考えられる。

また、共通データはプログラム以外であってもよく、条件適応データも動作ルールおよびプログラム用データでなくても良い。

例えば、必要性の高い高必要データである共通データをコンテンツの詳細情報、条件よっては必要でない、つまり必要性が低い低必要データである条件適応データをコンテンツの要約情報としても良い。この場合、要約情報は、専用のデータを用意してもかまわないし、テキストデータや、静止画など、コンテンツを構成するメディアの一部や、コンテンツの名前（番組タイトルやプログラムの名前）を要約情報として用いてもかまわない。また、この場合、要約情報の送信周期を詳細情報の送信周期より短くしてもよい。これにより、ユーザは短い待ち時間で、コンテンツの要約情報を表示させる、または、動作させることができるようになる。

（実施の形態２）
実施の形態２は、パケット網における放送型のデータ配信において、コンテンツであるプログラム、および、そのコンテンツの一部であるサブプログラムの配信を行うものである。以下、実施の形態２にかかるコンテンツ配信システムについて説明する。

まず、実施の形態２にかかるコンテンツ配信システムの利用形態について、図１３を用いて説明する。図１３は、実施の形態２にかかるコンテンツ配信システムの利用形態を示す図である。なお、既に説明した部分と同一の部分には、同一の符号を付与し詳細な説明を省略する。

実施の形態２にかかるメディアデータ送信装置であるサーバ（送信端末）１３００は、中継装置１０３ａにデータ１（１９０１）およびデータ２（１９０２）を送信し、中継装置１０３ｂにデータ１（１９０１）およびデータ３（１９０３）を送信し、中継装置１０３ｃにデータ１（１９０１）およびデータ４（１９０４）を送信する。

このとき、データ１（１９０１）は、各中継装置１０３ａ〜１０３ｃに共通、つまり各エリア１１３０〜１１３２に共通の番組データでありメインのプログラムである。また、データ２（１９０２）、３（１９０３）、４（１９０４）は、データ１（１９０１）から参照される、各中継装置１０３ａ〜１０３ｃ、つまり各エリア１１３０〜１１３２で異なる番組データであり、サブプログラムである。

番組データは、ＤＳＭ−ＣＣのように、予め定められた送信周期で繰り返し送信するものとする。

また、サーバ１３００は、チャンネル情報を、中継装置１０３ａ〜１０３ｃに共通のデータを送信するものとする。

チャンネル情報とは、セッションタイトル、セッションの開始時刻、終了時刻、番組データとして送信しているデータの種別、送信チャンネルといった情報を含んでいる。チャンネル情報記述用のプロトコルとしては、ＳＤＰに代表されるセッション記述用のプロトコルを想定している。具体的なチャンネル情報の例は後述する。チャンネル情報も、定期的に繰り返し送信されるものとする。

このような送信を行った場合、共通データである番組データ１９０１は、例えば受信エリア１１３０で受信したものを受信エリア１１３１で流用することができるようになる。したがって、受信端末１３０６ａが受信エリア１１３０から受信エリア１１３１に移動した際に、受信端末１３０６ａにおいて更新すべきデータが少なくてすむ。

また、伝送路上でパケットがロスすることを考慮すると、更新すべきデータの量が少ないほうが、受信端末１３０６ａ〜１３０６ｃが全てのデータを完全に受信するまでの時間が短くなるため、受信待ち時間が短くなる。

また、実施の形態２では、データ１（１９０１）の送信周期に比べて、データ２（１９０２）、３（１９０３）、４（１９０４）の送信周期を短く設定している。これにより、受信端末１０３ａ〜１０３ｃが移動した場合に、更新する必要のあるデータであるデータ２（１９０２）、３（１９０３）、４（１９０４）の受信を早く行うことができ、データの更新の待ち時間が速くなる。

なお、上記の例では、エリアに共通のデータと、エリア毎異なるデータを送信するという場合について述べたが、同一エリア内で、更新頻度の高いプログラムと更新頻度の低いプログラムにプログラムを分割しても、同様の効果を得ることができる。その場合も、更新頻度の高いプログラムの送信周期を、更新頻度の低いプログラムの送信周期と比較して短く設定すると、さらにデータの更新待ち時間が短くなる。

次に、実施の形態２にかかるサーバ１３００が送信するデータ１９０１〜１９０３について図１４を用いて説明する。図１４（ａ）〜図１４（ｃ）は、実施の形態２にかかるサーバ１３００の送信するデータを示す図である。

図１４（ａ）はデータ１（１９０１）、図１４（ｂ）はデータ２（１９０２）、図１４（ｃ）はデータ３（１９０３）を示している。

データ１（１９０１）は、ユーザプロファイル（ユーザの興味のある対象を示すデータであるものとする。この情報は端末に格納されている。）を取得し、ユーザプロファイルに書籍（Ｂｏｏｋ）が登録されている場合には、書店の情報を表示するよう記述されている。

図中２００１で示される部分は、他のプログラムへの参照を示しており “ＢｏｏｋＳｔｏｒｅ”という名前のプログラムを取得するように示している。また、他の部分も同様に、ユーザプロファイルに音楽（ＭＵＳＩＣ）が登録されている場合には、ＣＤショップの情報を提示する記述となっている。どちらでもなければ、デフォルトの情報（“ｄｅｆａｕｌｔ”という名前のプログラム）を表示するよう記述されている。このようなエリアに依存しない共通データは、広域に配信される。

データ２（１９０２）は、書店「Ａ＿Ｓｔｏｒｅ」に関する情報である（受信エリア１９３０で最も近い書店）。データ２（１９０２）は、受信端末１０４の解像度を取得し、端末の解像度１０４がＣＩＦサイズ以上であれば、高解像度の画像を表示する。また、端末の解像度がＣＩＦよりも小さければ、低解像度のデータ表示を行う。

データ３（１９０３）は、書店「Ｂ＿Ｓｔｏｒｅ」の情報である。データ３（１９０３）は、受信端末１０４に設定されるセキュリティプロファイルを参照し、通信による情報取得が許可されているならば、ＵＲＬを参照してデータを取得する。また、データ３（１９０３）は、通信による情報取得が許可されていないならば、放送により配信される画像データ（“Ｂ＿Ｓｔｏｒｅ．ｇｉｆ”）を表示する。

データ２（１９０２）、データ３（１９０３）に記載される情報は、書店によってユーザに提示したい情報が異なるという点と、受信エリア毎に近い書店が異なるという点から、エリア毎に異なる情報となるため、対応するエリア毎に配信される。

次に、実施の形態２にかかるチャンネル情報について図１５を用いて説明する。図１５は、実施の形態２にかかるデータを配信する際のチャンネル情報を示す図である。この例では、ＳＤＰを拡張して記述している。

チャンネル情報２１００の２１０１で示される部分は、従来のＳＤＰと同様である。したがって、“ｃ＝”フィールドに記載されるＩＰアドレスあてに番組データが送信されることを示している。

チャンネル情報２１００の２１０２で示される部分は、ＨＴＭＬをポート番号１００００あてに送信することを示している。

また、チャンネル情報２１００の２１０３で示される部分は、メディアデータの名前を示すフィールドである。本フィールドに記載される名前情報が、図１４で説明したメディアデータの名前にあたる。なお、本フィールドに“Ｍａｉｎ”と記載されるメディアデータが、番組の画面構成を決定するメディアデータとなる。

また、チャンネル情報２１００の２１０４および２１０５で示される部分は、前述と同様の記述でありプログラム（Ｓｃｒｉｐｔ）を送信することを示している。

また、チャンネル情報２１００の２１０６で示される部分は、プログラム中で参照される画像データの記述である。これらの画像データは、その情報が必要とされるエリアでのみ配信される。

次に、実施の形態２にかかるコンテンツ配信システムの構成について、図１６を用いて説明する。図１６は、実施の形態２にかかるコンテンツ配信システムの構成を説明する図である。

本システムでは、サーバ１３００は、中継装置１０３ａ〜１０３ｃにチャンネル情報、番組データを送信する（送信先の中継装置は複数であってもよい）。

中継装置１０３ａ〜１０３ｃは、受信したデータをブロードキャスト、もしくはマルチキャストで受信端末１３０６に送信する。

受信端末１３０６は、まず、チャンネル情報を規定の共通チャンネル（ここで、チャンネルとは、あて先アドレスとあて先ポート番号の組で表されるものとする。）から受信し、チャンネル情報に記載される各データが送信されているチャンネルに基づいて、チャンネルをオープンし、番組データ（実行可能コンテンツ）を受信して、ユーザに情報を提示するシステムを想定している。

なお、サーバ１３００は、複数の番組の送信を管理するものとする。

サーバ１３００は、以下の各部より構成される。

送信データ蓄積部１３０１は、ネットワークに伝送される番組データを蓄積する手段である。具体的には、ハードディスクドライブに代表される蓄積媒体である。

放送管理部１３０２は、番組の放送スケジュールを管理する手段である。予め指定された各番組の放送開始時刻になると、送信データ蓄積部１３０１から番組データを取得し、一定のサイズに分割して、伝送部１３０４に送信する。

また、放送管理部１３０２は、終了時刻になると、番組データの送信を終了する。また、放送管理部１３０２は、番組送信開始時に、送信を開始した番組の番組データの情報（ＨＴＭＬ、ＧＩＦ、ＪＰＥＧといったコンテンツの種別と、番組のタイトル、放送開始時刻、終了時刻）を番組情報生成部１３０３に通知し、番組送信終了時に、その番組の送信終了を番組情報生成部１３０３に通知する機能を有する。

なお、番組データの送信開始時刻、送信終了時刻および、番組データとして送信するデータのファイル名は、設定ファイルなどを用いて指定してもよいし、ＧＵＩなどを用いて指定する仕組みとしてもよい。

番組情報生成部１３０３は、放送管理部１３０２から通知された情報に基づき、各番組のチャンネル情報を生成する手段である。

伝送部１３０４は、ネットワークに接続するインターフェース機能を有する。また、伝送部１３０４は、放送管理部１３０２から受信したデータをパケット化し、中継装置１０３ａ〜１０３ｃあてに送信する機能を有する。また、伝送部１３０４は、サブプログラムであるデータ２（１９０２）、３（１９０３）、４（１９０４）の送信周期を、メインプログラムであるデータ１（１９０１）の送信周期より短くする。これにより、受信端末１３０６がエリアに応じて更新することが必要なデータ２（１９０２）、３（１９０３）、４（１９０４）を早く受信できるようになる。

中継装置１０３ａ〜１０３ｃは、サーバ１３００から送信されたチャンネル情報、番組データを受信し、受信端末１３０６の存在するネットワークに転送する機能を有する。この際、中継装置１０３ａ〜１０３ｃは、受信端末１３０６側ネットワークへの転送は、チャンネル情報に記載されるチャンネルあてに行うものとする。

具体的には、中継装置１０３ａ〜１０３ｃは、例えばチャンネル情報がＳＤＰで記載されている場合には、”Ｃ＝”フィールドに記載されるＩＰアドレスと各“ｍ＝”フィールドに記載されるポート番号あてに番組データを構成する各メディアデータを送信するものとする。

受信端末１３０６は、以下の各部より構成される。

伝送部１３０８は、中継装置１０３ｃからのチャンネル情報、番組データを受信し、パケットをほどき、チャンネル情報であれば番組選択部１３１２に、番組データであれば蓄積管理部１３０９に送信する手段である。

また、受信チャンネル選択部１３１３の指示により、番組データの受信チャンネルをオープンする機能を有する。また、受信チャンネル選択部１３１３は、指定されたチャンネルが、ＵＲＬであった場合には、ＵＲＬに基づいてデータをＵＲＬで示されるサーバから取得する手段である。

番組選択部１３１２は、伝送部１３０８からのチャンネル情報のうち、番組タイトルをユーザに提示し、ユーザに番組を選択させる機能を有する。また、番組選択部１３１２は、ユーザが番組を選択した際に、選択した番組のチャンネル情報を受信チャンネル選択部１３１３に通知する。

受信チャンネル選択部１３１３は、チャンネル情報に記載される各データが送信されているチャンネルに基づいて、オープンするチャンネルを伝送部１３０８に通知する手段である。また、受信チャンネル選択部１３１３は、プログラム解釈部１３１４から、ＵＲＬを受信した場合には、ＵＲＬに基づいてサーバからデータを取得する手段である。

蓄積管理部１３０９は、受信したデータを受信データ蓄積部１３０７に蓄積する。また、蓄積管理部１３０９は、分割されたメディアデータを全て受信した場合には、分割されたデータを結合し、記述解釈部１３１０に通知する機能を有する。また、プログラム解釈部１３１４からの要求を受けて、プログラムを受信データから取得してプログラム解釈部に送信する手段である。

記述解釈部１３１０は、ＨＴＭＬを解釈し、表示データを生成する。また、記述解釈部１３１０は、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ、Ｊａｖａ（Ｒ）ＡｐｐｌｅｔといったプログラムがＨＴＭＬに含まれている場合には、その部分を取り出してプログラム解釈部１３１４に送信する。

プログラム解釈部１３１４は、記述解釈部１３１０から通知されたプログラムを受信して解釈し、解釈結果を記述解釈部１３１０に通知する。このとき、プログラム解釈部１３１４は、プログラムに他のプログラムへの参照が含まれている場合には、蓄積管理部１３０９に参照プログラムを送信するよう要求する。

また、プログラム解釈部１３１４は、プログラムにＵＲＬが含まれている場合には、まず、プロファイル設定・格納部１３１６に格納されるセキュリティプロファイル（ネットワークへの接続許可）を参照し、セキュリティプロファイルに違反しなければ、ＵＲＬを受信チャンネル選択部１３１３に送信して、ＵＲＬのデータを取得するよう通知する。

また、プログラム解釈部１３１４は、プログラムにイベント登録を行うよう記述されている場合には、まず、プロファイル設定・格納部１３１６に格納されるセキュリティプロファイル（イベント登録許可、位置情報に関するイベントであれば、加えて位置情報へのアクセス許可）を参照し、セキュリティプロファイルに違反しなければ、イベント登録部１３１５にイベントを登録する。

また、プログラム解釈部１３１４は、プログラムにユーザプロファイルへのアクセスを行う記述がなされている場合には、まず、セキュリティプロファイル（ユーザプロファイルへのアクセス許可）を参照し、セキュリティプロファイルに違反しなければ、プロファイル設定・格納部１３１６に格納されるユーザプロファイルを参照する。

また、プログラム解釈部１３１４は、プログラムにある地点と現在地の距離情報を取得するよう記述されている場合には、セキュリティプロファイル（位置情報へのアクセス許可）を参照し、セキュリティプロファイルに違反しなければ、距離計測部１３１７より取得する。

表示部１３１１は、ユーザに番組を提示する手段である。具体的にはＣＲＴやＬＣＤなどの映像表示手段である。

プロファイル設定・格納部１３１６は、端末プロファイル、ユーザプロファイル、セキュリティプロファイルを設定、格納する手段である。

ユーザプロファイル、セキュリティプロファイル設定は、例えば、図１４に示すＧＵＩを用いて行う。この例では、ユーザプロファイルとして、ユーザの興味の対象である項目のチェックボックスにチェックを入力することで、ユーザプロファイルを設定する。また、セキュリティプロファイルは、プログラム実行の際の各資源（ネットワーク、ファイル、ユーザプロファイル、位置情報）へのアクセスを許可する項目にチェックを入力することで設定を行う。

位置情報取得部１３１８は、受信端末１３０６の現在位置を取得する手段である。具体的には、ＧＰＳや、携帯電話や無線ＬＡＮの基地局情報や、ＲＦ−ＩＤタグ、無線ビーコンなどの発する電波などを利用した位置特定手段である。また、取得した位置情報を距離計測部１３１７に送信する機能を有する。

距離計測部１３１７は、位置情報取得部１３１８からの現在位置情報を受信し、イベント登録部１３１５からの位置情報で示される地点と現在位置との距離を計算する。距離の計算結果はイベント登録部１３１５に送信される。

イベント登録部１３１５は、プログラム解釈部１３１４からのイベント登録指示に従ってイベントを登録する。

登録されるイベントとしては、タイマーイベント（指定された時間経過後に発生するイベント）、位置イベント（指定された領域に入った、もしくは出た際に発生するイベント）、データ受信イベント（指定したデータを受信した際に発生するイベント）、データアクセスイベント（指定されたデータにアクセスされた際に発生するイベント）などが挙げられる。また、イベントが発生した際に、イベント登録時に登録された関数を呼び出す機能を有する。

次に、実施の形態２にかかる受信端末１３０６の動作のうち、チャンネル情報を取得して表示する動作について図１７を用いて説明する。図１７は、実施の形態２にかかる受信端末１３０６のチャンネル情報を取得して表示する動作フローチャートである。

まず、受信端末１３０６の伝送部１３０８が、チャンネル情報を受信するチャンネルをオープンする（ステップ１５０１）。

このチャンネルは、予め規定されており、必ずこのチャンネルでチャンネル情報を受信できるものとする。

その後、伝送部１３０８は、送信されてきたチャンネル情報を受信し（ステップ１５０２）、番組選択部１３１２に送る。

次に、番組選択部１３１２は、チャンネル情報からタイトル情報を抜き出して、ユーザに提示する（ステップ１５０３）。続いて、番組選択部１３１２は、ステップ１５０２に戻り、別のチャンネル情報を受信するまで待機する。

このように、受信端末１３０６は、チャンネル情報を取得し、番組タイトルを表示部１３１１に表示する。

次に、受信端末１３０６の動作のうち、ユーザが番組を選択した際の受信端末１３０６の動作について図１８を用いて説明する。図１８は、実施の形態２にかかる受信端末１３０６のユーザにより番組が選択された後の動作フローチャートである。

まず、番組選択部１３１２は、ユーザが番組選択をした旨の情報を受信すると（ステップ１６０１）、選択された番組のチャンネル情報に基づいて各メディアデータの受信チャンネルをオープンする（ステップ１６０２）。

次に、伝送部１３０８が、オープンしたチャンネルを用いて番組データを受信し（ステップ１６０３）、蓄積管理部１３０９に送る。

蓄積管理部１３０９は、受信データ蓄積部１３０７に、番組の画面構成を決定するメディアデータ（ＨＴＭＬデータやＳＭＩＬデータ）を蓄積する（ステップ１６０４）。

ステップ１６０４においてメディアデータを全て受信（ステップ１６０５）した場合には、記述解析部１３１０がそのメディアデータを取り出し、プログラム部分を抽出し、解釈を行う（ステップ１６０６）。

次に、メディアデータにプログラムが含まれる場合（ステップ１６０７）、記述解釈部１３１０は、そのプログラムを引数として、プログラム解釈部１３１４による、プログラム解釈処理（後述する）を呼び出し（ステップ１６０８）、処理結果を戻り値として取得する（ステップ１６０９）。

その後、記述解釈部１３１０は、解釈結果を表示する（ステップ１６１０）。受信するメディアデータが表示中に交信される可能性があるため、記述解釈部１３１０は、メディアデータの更新を監視して待機し（ステップ１６１１）、メディアデータの変化があった場合にはステップ１６０３に戻り、変化したデータを取得して表示する処理を繰り返す。

なお、メディアデータの更新を検出する方法としては、データパケットのヘッダ部分にメディアデータを一意に決定する識別子を付与し、識別子の変化に基づいて、検出する方法を想定している。

次に、受信端末１３０６の動作のうち、プログラム部分を解釈する解釈処理について図１９を用いて説明する。図１９は、実施の形態２にかかる受信端末１３０６のプログラム部分を解釈するフローチャートである。

解釈処理は、プログラムを引数として再帰的に呼び出される。これにより、参照構造になっているプログラムを解釈することが可能となっている。

まず、プログラム解釈部１３１４は、引数として渡されるプログラムを解釈する（ステップ１７０１）。

プログラムがイベント登録の必要がある場合には（ステップ１７０２）、プログラム解釈部１３１４は、イベントを登録する（ステップ１７０３）。

プログラムが他のプログラムを参照している箇所があった場合には（ステップ１７０４）、プログラム解釈部１３１４は、参照されているプログラムが蓄積されているかどうかを確認し（ステップ１７０５）、蓄積されていない場合には、その参照プログラムの受信待ちを行う（ステップ１７０６）。

その後、プログラム解釈部１３１４は、参照プログラムを取得し、取得したプログラムを引数としてプログラムの解釈処理を呼び出す（ステップ１７０７）。最後に、処理結果を返り値として処理を終了する（ステップ１７０８）。

次に、受信端末１３０６の動作のうち、登録されたイベントを監視する際の動作について図２０を用いて説明する。図２０は、実施の形態２にかかる受信端末１３０６が登録されたイベントを監視する際の動作フローチャートである。

図２０の例では、受信端末１３０６が、位置イベントを処理する場合を示している。

また、受信端末１３０６が、位置イベントを登録する際には、地点を表す情報、距離を表す情報、位置イベントの種別（領域に侵入した場合に発生するイベントなのか、領域から出たときに発生するイベントなのかを示す）、イベントが発生した際に呼び出される関数を登録するものとする。

まず、受信端末の位置情報取得部１３１８が、現在位置情報を受信し（ステップ１８０１）、続いて、距離計測部１３１７が現在位置情報を用いてイベント登録の際に登録された地点との距離を計算する（ステップ１８０２）。

次に、プログラム解釈部１３１４が、ステップ１８０２における計算結果から、イベント条件を満たすかどうかを判定し（ステップ１８０３）、満たしていないのであれば、ステップ１８０１に戻る。

ここで、イベント条件とは、例えば、「登録された地点と現在地の間の距離がイベント登録の際に登録された距離よりも短くなり、かつ、イベント種別がその領域への侵入により発生するものである」という条件や、「登録された地点と現在地の間の距離がイベント登録の際に登録された距離よりも長く、かつ、イベント種別その領域により出た際に発生するものである」という条件を表す。

一方、イベント条件が満たされた場合には、プログラム解釈部１３１４は、登録された関数を呼び出し、関数を実行する（ステップ１８０４）。

続いて、プログラム解釈部１３１４は、実行結果を対応するプログラム部分と差し替えて埋め込み、解釈処理を実行する（ステップ１８０５）。そして、プログラム解釈部１３１４は、解釈結果を表示部１３１１に表示して終了する（ステップ１８０６）。

以上説明したしたように、実施の形態２によれば、パケット網における放送型のデータ配信において、全てのエリアに対して共通、つまり少更新データ、言い換えれば更新の必要性の低い低必要データであるプログラムと、エリア毎に異なる、つまり多更新データ、言い換えれば更新の必要性の高い高必要データであるサブプログラムの配信を個別に配信することができる。これにより、受信端末１３０６の移動に伴って、更新の頻繁なサブプログラムのみを、受信端末１３０６で更新し、プログラムについては既に蓄積してあるものを流用することができる。

また、実施の形態２によれば、多更新データであるサブプログラムの送信周期を、少更新データであるプログラムの送信周期より短くできる。これにより、受信端末１３０６は、多更新データをすばやく受信でき、コンテンツの更新をすばやくできる。

（実施の形態３）
発明の実施の形態３は、実施の形態１におけるコンテンツ配信システムを地図配信に適用したものである。

次に、実施の形態３にかかる地図配信システムについて図２１を用いて説明する。図２１は、実施の形態３にかかる地図配信システムの利用形態を示す図である。なお、既に説明した部分と同一の部分には、同一の符号を付与する。

中継ノード（中継装置）１０３ａ〜１０３ｃは、それぞれ、配信エリア１１３０〜１１３２へ地図データを配信している。

メディアデータ送信装置であるサーバ２００は、中継ノード１０３ａに配信エリア１１３０に関する地図データ（２２０１）と、配信エリア１１３０の隣の配信エリア１１３１に関する地図データ（２２０２）を送信し、中継ノード１０３ｂに配信エリア１１３１に関する地図データ（２２０３）と、配信エリア１１３１の隣の配信エリア１１３０に関する地図データ（２２０４）と、配信エリア１１３１の隣の配信エリア１１３２に関する地図データ（２２０５）を送信し、中継ノード１０３ｃに配信エリア１１３２に関する地図データ（２２０６）と、配信エリア１１３２の隣の配信エリア１１３１に関する地図データ（２２０７）を送信する。

このとき、サーバ２００は、エリアによらず共通なデータである、地図を表示するプログラム２２００を配信する。

また、地図データ２２０１〜２２０７は、地図表示プログラム２２００と同じＯｂｊｅｃｔ ＩＤを持ったプログラム用データである。これにより、地図データ２２０１〜２２０７が地図表示プログラム２２００と同じＯｂｊｅｃｔ ＩＤを持つことにより、地図表示プログラムと地図データを正しく対応付けして動作させることができる。

なお、地図表示プログラム２２００は、本実施例のコンテンツ配信システムを用いて配信してもよいし、本実施例のコンテンツ配信システムでは配信を行わず、受信端末２１０の使用者が、どこかのＵＲＬから予めダウンロードしてきておいてもかまわないし、メモリーカードのような媒体や種々の通信媒体を通してＰＣなどからインストールしてもかまわない。

また、サーバ２００は、チャンネル情報として、中継ノード１０３ａ〜１０３ｃに共通のデータを送信するものとする。ここで、サーバ２００は、データが配信されているエリアに関する地図データ、つまり必要性の高い高必要データの送信周期を短く設定し、周辺配信エリアの地図データ、つまり必要性の低い低必要データの送信周期を長く設定する。

このように、サーバ２００が地図データの送信を行った場合、受信端末２１０がいる配信エリアに関する地図データ、つまり高必要データの受信待ち時間が短くなる。これにより、受信端末２１０が現在いるエリアに関する地図を表示するまでの時間を短縮することができる。

以上説明したように、実施の形態３によれば、サーバ２００が、受信端末２１０ａ〜２１０ｃに対して、受信端末２１０ａ〜２１０ｃが存在するエリア１１３０〜１１３２周辺のエリアの地図データを送信することで、受信端末２１０ａ〜２１０ｃが、配信エリア１１３０〜１１３２から他の配信エリア１１３０〜１１３２に移動した際に、前もって他の配信エリア１１３０〜１１３２に関する地図データを受信しておくことができる。この結果、受信端末２１０ａ〜２１０ｃは、移動した際に他の配信エリア１１３０〜１１３２に関する地図情報をすぐに表示することができる。

また、実施の形態３によれば、受信端末２１０が移動した場合にも、エリアによらず共通のデータである地図表示プログラム２２００を流用できる。

なお、サーバ２００は、受信端末２１０の自配信エリアに関する地図データをデータ量の大きい詳細な地図データとし、周辺配信エリアに関する地図データを自配信エリアに関する地図データに比べてデータ量の少ない簡単な地図データにして配信してもよい。

こうすることにより、受信端末２１０が現在いる配信エリアに関して、より詳しい地図を表示することが可能になる。

また、この際、受信端末２１０は、周辺配信エリアで送信されている簡単な地図データが、自配信エリアに向けて送信している詳細な地図データの一部分であれば、周辺配信エリアで送信されている地図データを流用することができる。

例えば、受信端末２１０が、配信エリア１１３０から配信エリア１１３１に移動した場合、地図データ２２０４と地図データ２２０２の差分のデータだけを受信すれば配信エリア１１３１に関する詳細な地図データを得ることができる。したがって、受信端末２１０において更新すべきデータが少なくてすむので、詳細な地図を表示するまでの時間を短縮することができる。

受信端末２１０が、差分を取って受信する方法としては、ＲＴＰヘッダのＢｌｏｃｋ Ｎｏ（図６の９０８）を確認して、まだ受信していないデータのみを保存するようにしてもかまわないし、図２１のように地図データ２２０４を配信するのではなく、地図データ２２０４と地図データ２２０２の差分データ２２０７と、地図データ２２０４を別々の番組として配信する、または、地図データ２２０４と差分地図データ２２０７とを同一番組内の違うポートに配信することにより、差分地図データだけを効率よく受信できるようにしてもかまわない。

また、配信する地図データを、配信エリア１１３０、１１３１、１１３２全体の簡易地図データと、配信エリア毎の詳細な地図のデータに分けて配信してもよい。全体の簡易地図データは、配信エリア１１３０、１１３１、１１３２の全ての配信エリアで配信し、各配信エリア毎の詳細な地図データはそれぞれの配信エリアで配信する。

また、この場合には、全体の簡易地図データの送信周期を短く設定し、配信エリア毎の詳細な地図データの送信周期を長く設定する。こうすることにより、配信エリア１１３０で受信した全体の簡易地図データを、配信エリア１１３１、１１３２で流用することができる。

これにより、受信端末が配信エリア１１３０から配信エリア１１３１へ移動した場合は、配信エリア１１３１の詳細な地図データだけを受信すればいいので、詳細な地図を表示するまでの時間を短縮することができる。

（実施の形態４）
発明の実施の形態４は、実施の形態１におけるコンテンツ配信システムを位置依存型ゲーム配信システムに適用したものである。

次に、実施の形態４にかかる位置依存型ゲ−ム配信システムについて図２２を用いて説明する。図２２は、実施の形態４にかかる位置依存型ゲ−ム配信システムの利用形態を示す図である。なお、既に説明した部分と同一の部分には、同一の符号を付与する。

中継ノード１０３ａ〜１０３ｃは、配信エリア１１３０、１１３１、１１３２へゲームのメインプログラム、プログラムの動作を規定するルール、およびサブプログラム、または、プログラムが使用するデータなどを配信している。

サーバ２００は、中継ノード１０３ａ〜１０３ｃにエリア１１３０〜１１３２によらず共通のデータであるゲームのメインプログラム（２３０１）を送信し、中継ノード１０３ａに配信エリア１１３０で用いられるルール（２３０２）を送信する。

ルールというのは、例えば、「配信エリア１１３０では、魔法が使えなくなる」、「配信エリア１１３０では、力が２倍になる」といったものである。

中継ノード１０３ｂには、配信エリア１１３１で用いられるデータ（２３０３）を送信する。

データというのは、例えば、配信エリア１１３１だけに出てくるキャラクターの情報であったり、配信エリア１１３１で用いるマップデータといったものである。

また、中継ノード１０３ｃには配信エリア１１３２で用いられるサブプログラム（２３０６）を送信する。

サブプログラムというのは、例えば、配信エリア１１３２だけで楽しめるカジノゲームのプログラムであったり、配信エリア１１３２だけで起こるイベント用のプログラムといったものである。

ルール２３０２と、データ２３０３と、サブプログラム２３０６は、ゲームのメインプログラム２３０１と同じＯｂｊｅｃｔ ＩＤを持っており、これにより、ゲームのメインプログラムと正しく対応付けして動作させることができる。

また、サーバ２００は、チャンネル情報として、中継ノード１０３ａ〜１０３ｃに共通のデータを送信するものとする。

また、サーバ２００は、ゲームのメインプログラム２３０１の送信周期を長く設定し、ルール２３０２と、データ２３０３と、サブプログラム２３０６の送信周期を短く設定する。

このように送信を行った場合、共通データであるゲームのメインプログラム２３０１は、配信エリア１１３０で受信したものを配信エリア１１３１、１１３２で利用することができる。したがって、配信エリア１１３１、１１３２では、配信エリア１１３１、１１３２用のデータ２３０３、２３０６、サブプログラム２３０４、２３０７のみを受信すればよく、受信端末２１０ａ〜２１０ｃにおいて更新すべきデータが少なくてすむ。これにより受信待ち時間が短くなる。また、データ２３０３、２３０６、サブプログラム２３０４、２３０７の送信周期を短く設定しているため、さらに受信待ち時間を短縮することができる。

また、ゲームのメインプログラム２３０１は、配信システムを用いて配信するのではなく、予めどこかのＵＲＬからダウンロードしてきておいてもかまわないし、メモリーカードのような媒体や種々の通信媒体を通してＰＣなどからインストールしてもかまわない。この場合でも、ゲームのメインプログラムと、データ、ルール、サブプログラムなどは、同じＯｂｊｅｃｔ ＩＤを持つことにより相互に整合がとれる。

以上説明したように、実施の形態４によれば、エリアに応じたゲーム配信ができる。また、エリアによらず共通なデータ、つまり少更新データ（更新の必要性の低い低必要データ）であるメインプログラム２３０１と、エリアにより異なるデータ、つまり多更新データ（更新の必要性の高い高必要データ）であるルール（２３０２）、データ（２３０３）、サブプログラム（２３０６）とを、個別に送信することができる。これにより、受信端末２１０は、メインプログラムをエリアによらず流用することができる。

また、実施の形態４によれば、多更新データであるルール（２３０２）、データ（２３０３）、サブプログラム（２３０６）の送信周期を、少更新データであるメインプログラム２３０１の送信周期より短くできる。これにより、受信端末が、多更新データであるルール（２３０２）、データ（２３０３）、サブプログラム（２３０６）をすばやく受信でき、コンテンツの更新をすばやく行える。

（実施の形態５）
発明の実施の形態５では、他のメディア（映像、音声、静止画、テキスト）と同期してプログラム動作させる実施の形態を示す。

以下、実施の形態５にかかる受信端末について、図２３を用いて説明する。図２３は、実施の形態５にかかる受信端末の構成図である。なお、既に説明した部分と同一の部分には、同一の符号を付与してある。

実施の形態５にかかる受信端末１２００は、他のメディア（映像、音声、静止画、テキスト）と同期して実行可能コンテンツを表示する。

受信端末１２００は、実施の形態１にかかる受信端末１０４の各手段に加えて、復号化部１２０１と同期再生部１２０２を有する。

復号化部１２０１は、符号化された映像、音声、静止画といった情報を復号化し、同期再生部２１０２に送信する手段である。また、復号化部１２０１は、ＨＴＭＬなどテキストデータを、必要であれば解釈し、同期再生部１２０２に送信する手段である。また、復号化部１２０１は、プログラム実行部の要求により、コンテンツの現在の再生時間をプログラム実行部に通知する機能を有する。

同期再生部１２０２は、復号、解釈されたデータを、同期を取って合成する手段である。同期再生部１２０２が用いる同期方法としては、ＲＴＰのように、伝送データにタイムスタンプを付与し、タイムスタンプに基づいてデータを再生する方法が挙げられる。

プログラム実行部１２０３は、プログラム実行部２１６に以下の機能を追加する。プログラム実行部１２０３は、プログラム実行を行う際に、現在のコンテンツの再生時刻を参照し、動作ルールに記述された再生時刻と比較して、その時刻を過ぎた場合には、それをタイムアウトイベントとして取り扱う。プログラム実行部１２０３は、タイムアウトイベントが発生すると、その後に規定された動作をプログラムが実行するため、コンテンツの表示と同期して、プログラムが動作をすることができるようになる。

以上説明したように実施の形態５によれば、一つのコンテンツが複数のメディアデータに分割されて配信された場合にも、それらのメディアデータの同期を取って再生することができる。これにより、一つのコンテンツが複数のメディアデータに分割されて配信された場合にも、受信端末の使用者は、一つのコンテンツデータをまとめて受信した時と同じようにコンテンツデータを楽しむことができるようになる。

以上説明したように、本発明によれば、例えば、必要性が高いメディアデータは、低いメディアデータより送信周期を短く設定することで、要約情報など早く閲覧したい情報は、詳細情報よりも送信周期を短く設定するようにできる。この結果、限られた伝送帯域の中で、受信端末が、コンテンツを受信し始めたときや、受信端末の条件が変わった場合に、必要なメディアデータをより早く更新することができるように、メディアデータを送信することができ、受信端末におけるコンテンツ表示・再生の待ち時間を短縮することができ、配信サーバより受信端末へデータを一方向の配信システムや受信端末がそのプログラムを受信する放送型配信システム等に適応できる。

（ａ）本発明の実施の形態１における通信網の利用形態を示す第１の構成図、（ｂ）実施の形態１における通信網の利用形態を示す第２の構成図、（ｃ）実施の形態１における通信網の利用形態を示す第３の構成図 実施の形態１にかかるコンテンツ配信システムの利用形態を示す図 実施の形態１にかかるコンテンツ配信システムの構成図 実施の形態１にかかるプロファイルの設定方法を説明する図 実施の形態１にかかるチャンネル情報を記述した図 実施の形態１にかかる伝送フォーマットのヘッダを示す図 実施の形態１にかかるチャンネル情報をＳＤＰにより記述した例を示す図 実施の形態１にかかる動作ルールを、ＳＱＬ記述を拡張して記述した例を示した図 実施の形態１にかかるサーバのコンテンツ配信の動作フローチャート 実施の形態１にかかる受信端末がチャンネル情報を取得して表示する動作フローチャート 実施の形態１にかかる受信端末がチャンネルを選択した際の動作フローチャート 実施の形態１にかかる受信端末のプログラム実行のフローチャート 本発明の実施の形態２にかかるコンテンツ配信システムの利用形態を示す図 （ａ）実施の形態２にかかるサーバの送信する第１のデータを示す図、（ｂ）実施の形態２にかかるサーバの送信する第２のデータを示す図、（ｃ）実施の形態２にかかるサーバの送信する第３のデータを示す図 実施の形態２にかかるデータを配信する際のチャンネル情報を示す図 実施の形態２にかかるコンテンツ配信システムの構成を説明する図 実施の形態２にかかる受信端末のチャンネル情報を取得して表示する動作フローチャート 実施の形態２にかかる受信端末のユーザにより番組が選択された後の動作フローチャート 実施の形態２にかかる受信端末のプログラム部分を解釈する際のフローチャート 実施の形態２にかかる受信端末が登録されたイベントを監視する際の動作フローチャート 本発明の実施の形態３にかかる地図配信システムの利用形態を示す図 本発明の実施の形態４にかかる位置依存型ゲ−ム配信システムの利用形態を示す図 本発明の実施の形態５にかかる受信端末の構成図

符号の説明

１０１ 通信網
１０２、１３００ サーバ
１０３、１０６ 中継ノード
１０４、１３０６ 受信端末
２０１、１３０１ 送信データ蓄積部
２０２ 送信管理部
２０３ 署名付与部
２０４ 識別子付与部
２０５、２１１、１３０４、１３０８ 伝送部
２０６ チャンネル情報生成部
２１２、１３１３ 受信チャンネル選択部
２１３ 認証部
２１４、１３０９ 蓄積管理部
２１５、１３０７ 受信データ蓄積部
２１６ プログラム実行部
２１７ プロファイル設定・格納部
２１８、１３１８ 位置情報取得部
２１９、１３１１ 表示部
１２０１ 復号化部
１２０２ 同期再生部
１３０２ 放送管理部
１３０３ 番組情報生成部
１３１０ 記述解釈部
１３１２ 番組選択部
１３１４ プログラム解釈部
１３１５ イベント登録部
１３１７ 距離計測部

Claims (15)

1. 第１のデータと第２のデータから構成されるコンテンツを蓄積する蓄積部と、前記蓄積部から前記第１のデータと第２のデータを取得する送信管理部と、前記第１のデータの送信周期を、前記第２のデータの送信周期よりも短く設定する送信管理部と、設定された前記送信周期を用いて前記第１のデータおよび前記第２のデータを個別に繰り返し送信する伝送部と、を有するメディアデータ送信装置であって、前記第１のデータは必要性の高い高必要データであり、前記第２のデータは前記高必要データと比較して必要性の低い低必要データであることを特徴とするメディアデータ送信装置。
2. 前記送信管理部は、前記第１のデータの送信周期もしくは第２のデータの送信周期の少なくともどちらか一方を前記第１のデータの配信されるエリアもしくは第２のデータの配信されるエリアの広さに基づいて決定する機能を有することを特徴とする請求項１記載のメディアデータ送信装置。
3. 前記第２のデータは前記第１のデータと比較して情報量が多いことを特徴とする請求項１記載のメディアデータ送信装置。
4. 前記第１のデータはコンテンツの要約情報のデータであり、前記第２のデータはコンテンツの詳細情報のデータであることを特徴とする請求項１記載のメディアデータ送信装置。
5. 前記詳細情報のデータに電子署名を付与する電子署名付与部を具備し、
   前記伝送管理部は前記要約情報のデータに公開鍵証明書を付与する機能を有することを特徴とする請求項４記載のメディアデータ送信装置。
6. 前記高必要データと、前記低必要データと、に互いを対応付ける識別子を付与して送信することを特徴とする請求項１から請求項５のいずれかに記載のメディア送信装置。
7. 前記第１のデータは送信先エリアの詳細な地図データであり、前記低必要データは前記エリアに隣接するエリアのおおまかな地図データであることを特徴とする請求項２記載のメディアデータ送信装置。
8. 請求項１記載のメディアデータ送信装置から送られる、前記第１のデータおよび前記第２のデータを受信する伝送部と、受信した前記第１のデータおよび前記第２のデータを対応させて蓄積する蓄積管理部と、前記第２のデータと前記第２のデータに対応する前記第１のデータとを用いて所定の処理を行う実行部と、を有することを特徴とするメディアデータ受信装置。
9. 前記第１のデータもしくは前記第２のデータを受信した際に、前記第１のデータもしくは前記第２のデータの受信動作を停止することを特徴とする請求項８記載のメディアデータ受信装置。
10. 前記第１のデータもしくは前記第２のデータの受信動作を停止後に、受信動作を停止したことを利用者に通知することを特徴とする請求項９記載のメディアデータ受信装置。
11. 請求項５に記載のメディアデータ送信装置から送られる、要約情報のデータおよび詳細情報のデータを受信する伝送部と、前記要約情報のデータから公開鍵証明書を取得し、前記詳細情報のデータから電子署名を取得し、前記公開鍵証明書と、前記詳細情報のデータと、前記電子署名を用いて前記詳細情報が改ざんされていないことを確認する認証部を有することを特徴とするメディアデータ受信装置。
12. 請求項１記載のメディアデータ送信装置から個別に送られる、前記第１のデータおよび前記第２のデータを受信するステップと、受信した前記第１のデータおよび前記第２のデータを対応させて蓄積するステップと、前記第２のデータと前記第２のデータに対応する前記第１のデータとを用いて所定の処理を行うステップと、を有することを特徴とするメディアデータ受信方法。
13. 前記第１のデータもしくは前記第２のデータを受信した際に、前記第１のデータもしくは前記第２のデータの受信動作を停止するステップを有することを特徴とする請求項１２記載のメディアデータ受信方法。
14. 前記第１のデータもしくは前記第２のデータの受信動作を停止後に、受信動作を停止したことを利用者に通知するステップを有することを特徴とする請求項１３記載のメディアデータ受信方法。
15. 請求項１記載のメディアデータ送信装置と、請求項８記載のメディアデータ受信装置と、を具備したことを特徴とするコンテンツ配信システム。

Images