JP2010507953A - 単方向データ伝送システムにおけるシーンデータの伝送方法 - Google Patents

Abstract

本発明は、単方向データ伝送システム（１）の送信装置（２）から少なくとも１つの受信装置（３）へ、少なくとも１つのシーンを記述する複数のシーンデータファイル（ＳＦ１〜ＳＦ４）をデータカルーセルによって伝送する方法に関する。本発明によれば、データカルーセルにより受信装置（３）へインデックスファイル（ＩＦ）が伝送され、このインデックスファイル（ＩＦ）には、シーンのグラフィック表示および／またはデコーディングのためにシーンデータファイル（ＳＦ１〜ＳＦ４）の時間的配置がデータ技術的にコーディングされている。

Description

本発明は通信技術の分野に係わるものであり、データカルーセル（data carousel）の単方向データ伝送システム手段におけるシーンデータの伝送に関する。

従来の技術
単方向データ伝送システム（ブロードキャストシステム）の場合、データは送信側から１つまたは複数の受信側へプッシュ方式により伝送される。ブロードキャストシステムの場合、データはたとえばストリーミング方式により連続的なデータストリームとして伝送される。このことにより得られる利点とは、たとえばデータレートが受信側のシステムクロックに結合される場合、データレートの精度に対する高度な要求を満たすことができる点である。したがって今日、オーディオ・ビデオデータストリームは一般に受信側へストリーミングされ、その際、データにはそれぞれ、プレゼンテーションおよび／またはデコーディングのためにどの時点でそれらのデータが関連づけられるかを表すタイムマーカが設けられる。ストリーミング方式の欠点は、受信側が受信し逃すかエラーを伴って受信したデータは受信側に新たに伝送できないことである。

さらにブロードキャストシステムにおいてダウンロード方式によるデータ伝送が知られており、これによればデータはデータファイルもしくはデータオブジェクトとして送信側から受信側へ伝送されて、受信側に格納される。これまで、１つの同じデータ伝送セッションにおけるオーティオデータストリームとビデオデータストリームに該当する付加データたとえば電子プログラム情報ないしは電子番組ガイド（EPG = Electronic Program Guide）等だけが、ダウンロード方式で受信側へ伝送されていた。その理由は、この種の付加データは時間的にクリティカルなものではないので、それらの付加データをプレゼンテーションのためにストリーミング方式で伝送されるオーディオ・ビデオデータストリームと同期合わせする必要がないからである。

ただしこのような状況は、グラフィックシーンが記述されるいわゆるリッチメディアアプリケーション（rich media application）の分野において根本的に変わった。比較的長い期間にわたって有効な状態にある可能性のあるグラフィックシーン各々は、このようなアプリケーションの場合、オーディオデータとビデオデータとシーンデータ（グラフィックデータおよびテキストデータ）から合成される（たとえばMPEG-Standard "LASeR" Lightweight Application Scene Representation参照、これはかつてはMPEG 4, Part 20もしくはISO/IEC 14496-20と呼ばれたものであり、そこにおいてグラフィックシーン記述フォーマットが指定されている）。シーンデータにより記述される１つのシーンの状態は時間的にクリティカルなものであるため、シーンデータをオーディオ・ビデオデータストリームと同期合わせさせる必要がある。

送信側と受信側との間におけるデータ伝送がポイント・ツー・ポイント・コネクションによって行われる場合、シーンデータとメディアデータ（オーディオデータとビデオデータ）をパラレルにないしは同時に受信側にストリーミングすることができるので、それらのデータが有効状態にある時間範囲の始点でそれらを受信側が利用可能となる。しかしながらブロードキャスト方式の場合には、個々のシーンが有効となる時間範囲の始点で受信側がすでにデータストリームを受信しているということを保証できないので、あとになってはじめてスイッチオン状態となる受信側もシーンデータを受信できるよう、１つのシーンが有効である時間範囲中にシーンデータをたえず繰り返し伝送しなければならない。シーンは複数のシーンデータファイルもしくはシーンデータファイル内に含まれる複数のシーンオブジェクトから成る可能性があり、この場合、それらのシーンデータファイルもしくはシーンオブジェクトのいずれが１つの特定のシーンに属するかの割り当ては、シーンもしくはいわゆるディレクトリ構造のルート要素の解釈を通してはじめて明らかになる。したがってシーンデータファイルもしくはシーンオブジェクトの簡単なキャッシングまたはパーシングないしは構文解析は、シーンを解釈しなければ不可能である。同様に、複数のシーンにおいて用いられるシーンに該当するシーンデータファイルもしくはシーンオブジェクトのキャッシングも不可能である。

このような問題を解消しようとする１つのアプローチはこれまで、ＥＢＵ（= European Broadcasting Union）の国際ＤＶＢ（= Digital Video Broadcasting）プロジェクトにより策定された標準"Multimedia Home Platform" (MHP = Multi Media Home Platform)によってのみ知られている。これによればインタラクティブなコンテンツの伝送と表示がプログラミング言語Javaをベースに標準化されている。この標準の現行バージョンであるMHP v1.1によれば、ディレクトリ構造を通して複数のアプリケーションオブジェクトの関係を通知することができる。どの程度の期間にわたりオブジェクトをキャッシングしなければならないのかの通知あるいはシーン状態の同期合わせはMHP v1.1によれば、記述すべきーシーンのシーンデータにおいてオーディオ・ビデオデータストリームのタイムマーカが参照されることによって実現されている。

基本的に、ＩＥＴＦ（Internet Engineering Task Force）により標準化されたトランスポートプロトコルRFC 3926 "Flute" (Flute = File Delivery over Unidirectional Transport)によっても、データファイルをグループ分けすることができる。しかしながらそこに記載されているグループ分けによれば、１つのグループにおけるすべてのファイルが受信されたときにはじめて、それらのファイルがアプリケーションに引き渡されるにすぎない。

したがってこれまでの解決手法によれば、シーンデータファイルもしくはシーンオブジェクトをどのくらいの期間にわたってキャッシングすべきであるのかのコンテンツのシグナリングは行われておらず、シーンデータファイルもしくはシーンオブジェクトを複数のシーンで利用することはできず、１つの同じシーンに属する複数のシーンデータファイルもしくはシーンオブジェクトの識別は行われない。

発明の概要
発明が解決しようとする課題
したがって本発明の課題は、１つのシーンを記述する複数のシーンデータファイルもしくはシーンオブジェクトを１つの送信側と１つまたは複数の受信側との間においてプッシュ方式で単方向伝送するための方法を提供することにあり、その際、どの時点でおよび／またはどのぐらいの期間にわたりシーンデータファイルもしくはシーンオブジェクトをキャッシングすべきであるのかに関してシグナリングを行えるようにし、シーンデータファイルもしくはシーンオブジェクトを複数のシーンにおいて利用できるようにし、さらに１つの同じシーンに属する複数のシーンデータファイルもしくはシーンオブジェクトを識別できるようにすることにある。

課題を解決するための手段
この課題は、少なくとも１つのシーンを記述する複数のシーンデータファイルを単方向データ伝送システムにおいて伝送するための請求項１記載の特徴を備えた方法によって解決される。本発明の有利な実施形態が従属請求項の特徴として挙げられている。

本発明によれば、単方向データ伝送システムにおいて少なくとも１つのシーンを記述する複数のシーンデータファイルを伝送する方法に関する。その際、単方向データ伝送システムには、シーンデータファイルを送信する送信装置と少なくとも１つの受信装置が設けられている。単方向データ伝送システムをブロードキャストデータ伝送システム、マルチキャストデータ伝送システムまたはユニキャストデータ伝送システムとすることができる。

単方向データ伝送システムによればシーンデータファイルがデータカルーセルにより受信装置へ送信され、この受信装置はシーンデータファイルもしくはシーンデータファイルに含まれるシーンデータオブジェクトを周期的な反復で少なくとも１つの受信装置へ伝送するのに適している。データカルーセルdata carouselはいわゆるデータオブジェクトカルーセルdata object carouselの形式で構成されており、したがってファイルだけでなくディレクトリ構造も周期的に繰り返して伝送することができる。データを周期的に繰り返して送信するためのデータカルーセルもしくはデータオブジェクトカルーセルは、たとえば標準DSM-CC (DSM-CC = Data Storage Media Command and Control)において仕様が定められており、それゆえ当業者にはよく知られているので、ここではこれ以上詳しくは言及しない。データカルーセルをFlueおよび／またはALC (Asychronous Layer Coding)および／またはLCT (Layer Coding Transport)をベースとすることができる。

本発明による方法の１つの基本的な特徴によれば、データカルーセルにインデックスファイルが含まれており、このインデックスファイルは少なくとも１つの受信装置へ伝送され、このインデックスファイルには、シーンのグラフィック表示（プレゼンテーション）および／またはデコーディングのためのシーンデータファイルもしくはそこに含まれているシーンデータオブジェクトの時間的配置が、データ技術的にないしはデータシステム的にコーディングされている。

したがって有利には少なくとも１つの受信装置に伝送されるインデックスファイルによって、いずれのシーンデータファイルもしくはその中に含まれているシーンデータオブジェクトがシーンのプレゼンテーションおよび／またはデコーディングのために所定の期間にわたり必要とされるのかに関する情報を受信装置に伝送することができるので、シーンをまえもって解釈することなく、インデックスファイルに基づくだけで受信装置によりシーンデータファイルのキャッシングを制御することができる。たとえばシーンデータファイルもしくはその中に含まれているシーンデータオブジェクトを、新たにロードすることなく再び使用することができる。

本発明による方法の１つの有利な実施形態によれば、シーンのグラフィック表示および／またはデコーディングのためのスタート時点がインデックスファイルにデータ技術的にコーディングされている。これにより有利には、シーンデータファイルもしくはその中に含まれているシーンデータオブジェクトのキャッシングを、表示すべきおよび／またはデコーディングすべきシーンのスタート時点に関して調整することができる。

本発明による方法の１つの別の有利な実施形態によれば、シーンのディレクトリ構造のためのルート要素がいずれのシーンデータファイルに含まれているのかに関する情報が、インデックスファイルにデータ技術的にコーディングされており、これによって有利にはこの情報もシーンのプレゼンテーションおよび／またはデコーディングの前にシーンデータファイルのキャッシングのために使用することができる。

本発明による方法のさらに別の有利な実施形態によれば、すべてのシーンデータファイルをいずれの時点まで受信装置においてキャッシングすべきであるのかの情報が、インデックスファイルにデータ技術的にコーディングされており、したがって有利には、シーンデータファイルに記述されているシーンのグラフィック表示および／またはデコーディングのスタート時点までに、それらのシーンを記述するすべてのシーンデータファイルもしくはその中に含まれているすべてのシーンデータオブジェクトが受信装置に存在するようになる。

本発明による方法の別の有利な実施形態によれば、グラフィック表示のために使用されるいわゆるレンダリングツリーRendering-Treeおよび／またはシャドウツリーShadow Tree（SVG 1.2 W3C Working Draft 29.4.2003参照）にシーンデータファイルをいずれの時点まで残しておくべきかの情報が、インデックスファイルにデータ技術的にコーディングされており、したがって有利には、受信装置においてシーンデータファイルもしくはその中に含まれているシーンデータオブジェクトを、もはや不要となった場合には消去することができるし、あるいは繰り返し利用することが意図されているならば、引き続き記憶させたままにしておくことができる。本発明による方法の別の有利な実施形態によれば、インデックスファイルはFluteデータ伝送セッションのFDT（FDT = File Delivery Table）をベースとするものであり、したがって有利には、更新後にFluteデータカルーセルを僅かな頻度でチェックすればよい。

本発明による方法のさらに別の有利な実施形態によれば、少なくとも１つのシーンを識別する少なくとも１つの識別子がインデックスファイルに含まれている。これにより外部の参照ないしは外部からの参照のためにインデックスファイルによりシーンを識別できるようになり、このことにより外部でシーンを参照指示できるという利点が得られる。

本発明による方法のさらに別の有利な実施形態によれば、インデックスファイルには外部のリソースへのシーンデータファイルの参照が含まれている。この種の参照の例はＵＲＩ（URI = Uniform Resource Identifier）またはＵＲＬ（URL = Uniform Resource Locator）である。したがってこの場合、シーン内で参照されるリソースたとえばオーディオデータストリームおよび／またはビデオデータストリームまたはデータファイルもしくはデータオブジェクトをインデクシングするためにも、インデックスファイルが利用される。これにより得られる利点とは、データファイルもしくはデータオブジェクトのいずれのセットがシーンのために必要とされるのかを突き止めるために、シーンを解釈する必要がないことである。換言すれば、シーンの表示および／またはデコーディングに必要とされるすべてのリソースが受信装置においてすでに受信されているか否かを、シーンデータファイルを読み取ることもなくすでに確認することができる。

本発明はさらに、送信装置および少なくとも１つの受信装置を備えた単方向データ伝送システムにも関する。この場合、送信装置と受信装置はこれまで述べてきた方法を実施するのに適したかたちで構成されている。

さらに本発明は、上述の単方向データ伝送システムにおける送信装置にも関する。この送信装置においてマシン読み出し可能ないしはコンピュータで読み取り可能なプログラムコードが実行され、もしくは実行可能であり、このプログラムコードには送信装置に対し既述の方法を実施させる制御命令が含まれている。さらに本発明は、この種の送信装置のためのマシン読み取り可能ないしはコンピュータ読み取り可能なプログラムコード（コンピュータプログラム）にも関する。このプログラムコードには、送信装置に対し既述の方法を実施させるための制御命令が含まれている。さらに本発明は、この種のコンピュータ読み出し可能なプログラムコードが記録された記憶媒体（コンピュータプログラム製品）にも関する。

さらに本発明は、上述の単方向データ伝送システムにおける受信装置にも関する。この受信装置において、マシン読み取り可能ないしはコンピュータ読み出し可能なプログラムコードが実行され、もしくは実行可能であり、このプログラムコードには、受信装置に対し既述の方法を実施させる制御命令が含まれている。さらに本発明は、この種の受信装置のためのマシン読み取り可能ないしはコンピュータ読み取り可能なプログラムコード（コンピュータプログラム）にも関する。このプログラムコードには、受信装置に対し既述の方法を実施させるための制御命令が含まれている。さらに本発明は、この種のコンピュータ読み出し可能なプログラムコードが記録された記憶媒体（コンピュータプログラム製品）にも関する。

次に、添付の図面を参照しながら実施例に基づき本発明について詳しく説明する。

本発明による方法の１つの実施形態を表す単方向データ伝送システムの実施例

発明を実施するための形態
図１には、参照１により本発明による単方向データ伝送システムの実施例が示されている。データ伝送システム１には送信装置２と複数の受信装置３が含まれており、これら複数の受信装置３のうち図１にはただ１つの受信装置だけが描かれている。送信装置２と受信装置３との間のデータはブロードキャスト方式で伝送され、つまり送信装置２から受信装置３へプッシュ方式で送信される。データ伝送をワイヤレスまたはケーブル接続とすることができ、このことは図１には詳しくは示されていない。

送信装置２はデータカルーセルdata carouselもしくはデータオブジェクトカルーセルdata object carouselを利用して、データファイルを受信装置３へ送信する。送信装置２のデータカルーセルもしくはデータオブジェクトカルーセルは、たとえば標準フォーマットDSM-CCに従って仕様を定めることができ、あるいはFluteおよび／またはALC (Asychronous Layer Coding)および／またはLCT (Layer Coding Transport)をベースとすることができ、そこには複数のシーンデータファイルＳＦ１〜ＳＦ４が設けられており、これら複数のシーンデータファイルは、１つの同一のグラフィックシーンを記述するためのそれぞれ１つまたは複数のシーンデータオブジェクトを有しており、周期的な反復で受信装置３へ伝送される。

図１には、わかりやすく表現するために１つのリングの周囲にそれぞれ異なるシーンデータファイルＳＦ１〜ＳＦ４が配分されており、その際、データカルーセルの回転方向をシンボリックに表す矢印と、リング上のシーンデータファイルＳＦ１〜ＳＦ４の配置とによって、受信側へのシーンデータファイルＳＦ１〜ＳＦ４の周期的送信に関する時間順序が示されている。したがって第１のシーンデータファイルＳＦ１の後に第２のシーンデータファイルＳＦ２が送信され、第２のシーンデータファイルＳＦ２の後に第３のシーンデータファイルＳＦ４が、さらに第３のシーンデータファイルＳＦ３の後に第４のシーンデータファイルＳＦ４が送信される。ついで第１〜第４のシーンデータファイルＳＦ１〜ＳＦ４の送信がこの順序で、シーンデータファイルＳＦ１〜ＳＦ４のシーンデータオブジェクトに記述されたシーンのプレゼンテーションおよび／またはデコーディングのために有効である選択可能な時間範囲において繰り返される。

ＦＥＣメカニズム（FEC = Forward Error Correction）を利用した場合には殊に、これが理想的な表示であること、データファイルの順序は受信側によってのみ解釈できることが知られている。

さらに送信装置２のデータカルーセルにはインデックスファイルＩＦが含まれており、このインデックスファイルはここでは一例として第１のシーンデータファイル１と第２のシーンデータファイル２との間に挿入されており、このポジションにおいて第１のシーンデータファイル１と第２のシーンデータファイル２との間の時間的配置で送信される。

インデックスファイルＩＦには、シーンデータファイルＳＦ１〜ＳＦ４の時間順序に関する情報がデータ技術的コーディングで含まれており、つまりシーンのグラフィック表示および／またはデコーディング、受信装置３におけるシーンのグラフィック表示および／またはデコーディングのスタート時点に関して、シーンデータファイルＳＦ１〜ＳＦ４を受信するための時間順序に関する情報が含まれている。

図１には時間軸ｔがシンボリックに示されており、シーンデータファイルＳＦ１〜ＳＦ４の時間順序に関してインデックスファイルＩＦに含まれている情報がこの時間軸ｔで表されている。シーンデータファイルの時間順序を、たとえばシーンデータファイルＳＦ１〜ＳＦ４に割り当てられたタイムマーカによって実現することができる。したがってインデックスファイルＩＦには、シーンデータファイルＳＦ１〜ＳＦ４に記述されているシーンのプレゼンテーションのために、第３のシーンデータファイルＳＦ３を第２のシーンデータファイルＳＦ２よりも前の時間順序で受信すべきこと、第２のシーンデータファイルＳＦ２を第１のシーンデータファイルＳＦ１よりも前の時間順序で受信すべきこと、第１のシーンデータファイルＳＦ１を第４のシーンデータファイルＳＦ４よりも前の時間順序で受信すべきことがコーディングされている。

受信装置３がインデックスファイルＩＦを受信したとき、たとえば受信装置３がシーンのグラフィック表示の開始まですべてのシーンデータファイルＳＦ１〜ＳＦ４を完全には受信できないならば、受信装置３はインデックスファイルＩＦの時間的配置により定められているシーンデータファイルＳＦ１〜ＳＦ４の時間順序でのシーンデータファイルの受信を所期のように制御することができ、それによって最初のデータファイルとして第３のデータファイルＳＦ３が受信されて記憶されるようにし、ついで第２のシーンデータファイルＳＦ２が、その後、第１のシーンデータファイルＳＦ１が、さらにそれに続いて第４のシーンデータファイルＳＦ４が受信され記憶されるようにする。したがって１つのシーンデータファイルを新たに使おうとする場合に、新たにロードすることなくそれを行うことができる。

図１には送信装置２のデータカルーセルにただ１つのインデックスファイルＩＦしか示されていないけれども本発明によれば、すべてのシーンデータファイルＳＦ１〜ＳＦ４が受信装置へ１回伝送されるデータカルーセルの同一のサイクル中、インデックスファイルＩＦがシーンデータファイルＳＦ１〜ＳＦ４よりも高い頻度で受信装置３へ伝送されるよう意図されており、その目的はこのようにすることで、シーンデータファイルＳＦ１〜ＳＦ４の時間的配置に関してインデックスファイルＩＦにおいてコーディングされた情報が、受信装置３におけるグラフィック表示および／またはシーンデコーディングのスタート時点よりも手前の比較的早い時点で得られるようにするためである。このことは、シーンデータファイルＳＦ１〜ＳＦ４を送信するための同一サイクル中、シーンデータファイルＳＦ１〜ＳＦ４を有するデータカルーセルによりインデックスファイルＩＦを何度も送信することによって行うことができる。これに対する代案として可能であるのは、シーンデータファイルＳＦ１〜ＳＦ４を有するデータカルーセルよりも短いサイクルタイムをもつ別個のデータカルーセルにおいてインデックスファイルＩＦを伝送することである。

さらにインデックスファイルＩＦはデータ技術的コーディングにより、シーンデータファイルＳＦ１〜ＳＦ４のいずれにシーンのディレクトリ構造のためのルート要素が含まれているかに関する情報を有しており、したがってこのシーンデータファイルを受信して記憶するのが有利であり、これによってシーンのグラフィック表示スタート時点よりも早い時点にシーンデータファイルを含むディレクトリ構造に関する情報を受け取ることができるようになる。

さらにインデックスファイルＩＦはデータ技術的コーディングにより、すべてのシーンデータファイルＳＦ１〜ＳＦ４を受信装置３においてどの時点までキャッシングすべきであるのかに関する情報を有しており、したがって受信側においてグラフィック表示および／またはシーンのデコーディングのスタート時点までに、すべてのシーンデータファイルＳＦ１〜ＳＦ４を受信装置３で受信して記憶することができるようになる。

さらにインデックスファイルはデータ技術的コーディングにより、シーンデータファイルＳＦ１〜ＳＦ４をレンダリングツリーRendering-Treeまたはシャドウツリー Shadow-Treeにどの時点までそのままにしておくべきかの情報を有しており、したがってシーンデータファイルＳＦ１〜ＳＦ４を受信側において後の時点で使用するために記憶させたままにしておくことができ、そうでなければ消去することができる。

さらにインデックスファイルには、少なくとも１つのシーンを識別する少なくとも１つの識別子が含まれており、これによって外部からの参照ならびに外部のリソースに対するシーンデータファイルの参照のためにシーンの識別が可能となり、したがってあるシーンのために複数のデータファイルもしくはデータオブジェクトのいずれのセットがそのシーンのために必要とされるかを突き止めるためにシーンを解釈する必要がない。

図１に示した実施例の場合、インデックスファイルＩＦはFluteデータ伝送セッションのＦＤＴをベースとしており、有利なことにこれによって実現されるのは、更新後に慣用のFluteデータカルーセルよりも少ない頻度でデータカルーセルをチェックすればよいことである。

Claims (15)

1. 単方向データ伝送システム（１）の送信装置（２）から少なくとも１つの受信装置（３）へ、少なくとも１つのシーンを記述する複数のシーンデータファイル（ＳＦ１〜ＳＦ４）をデータカルーセルによって伝送する方法において、
   前記データカルーセルにより前記受信装置（３）へインデックスファイル（ＩＦ）が伝送され、該インデックスファイル（ＩＦ）には、前記シーンのグラフィック表示および／またはデコーディングのために前記シーンデータファイル（ＳＦ１〜ＳＦ４）の時間的配置がデータ技術的にコーディングされていることを特徴とする、
   複数のシーンデータファイル（ＳＦ１〜ＳＦ４）をデータカルーセルによって伝送する方法。
2. 前記インデックスファイル（ＩＦ）には、表示すべきおよび／またはデコーディングすべきシーンのグラフィック表示および／またはデコーディングのためのスタート時点がデータ技術的にコーディングされている、請求項１記載の方法。
3. 前記インデックスファイル（ＩＦ）には、前記シーンのディレクトリ構造におけるルート要素がいずれのシーンデータファイルに含まれているのかがデータ技術的にコーディングされている、請求項１または２記載の方法。
4. 前記インデックスファイル（ＩＦ）には、前記シーンを記述するすべてのシーンデータファイル（ＳＦ１〜ＳＦ４）を前記受信装置（３）においてどの時点でキャッシングすべきであるかがデータ技術的にコーディングされている、請求項１から３のいずれか１項記載の方法。
5. 前記インデックスファイル（ＩＦ）には、前記シーンを記述するシーンデータファイル（ＳＦ１〜ＳＦ４）を前記シーンのグラフィック表示および／またはデコーディングのために用いられるレンダリングツリーまたはシャドウツリーにいずれの時点まで残しておくべきかがデータ技術的にコーディングされている、請求項１から４のいずれか１項記載の方法。
6. 前記インデックスファイル（ＩＦ）はFluteセッション（Flute-Session）のファイルデリバリテーブル（File Delivery Table, FDT）をベースとする、請求項１から５のいずれか１項記載の方法。
7. 前記インデックスファイル（ＩＦ）には、少なくとも１つのシーンを識別する少なくとも１つの識別子が含まれている、請求項１から６のいずれか１項記載の方法。
8. 前記インデックスファイル（ＩＦ）には、外部のリソースに対する前記シーンデータファイル（ＳＦ１〜ＳＦ４）の参照が含まれている、請求項１から７のいずれか１項記載の方法。
9. 送信装置（２）と少なくとも１つの受信装置（３）を備えた単方向データ伝送システム（１）において、
   前記送信装置（２）および前記受信装置（３）は請求項１から８のいずれか１項記載の方法を実施するために構成されていることを特徴とする単方向データ伝送システム。
10. 単方向データ伝送システム（１）の送信装置（２）において、
    コンピュータ読み取り可能なプログラムコードが実行され、
    該プログラムコードには、請求項１から８のいずれか１項記載の方法を前記送信装置（２）に実行させる制御命令が含まれていることを特徴とする送信装置。
11. 請求項１０記載の単方向データ伝送システム（１）における送信装置（２）のためのコンピュータ読み取り可能なプログラムコードにおいて、
    請求項１から８のいずれか１項記載の方法を前記送信装置（２）に実行させる制御命令が含まれていることを特徴とするプログラムコード。
12. 請求項１１記載のコンピュータ読み取り可能なプログラムコードが格納されている記憶媒体。
13. 単方向データ伝送システム（１）の受信装置（３）において、
    コンピュータ読み取り可能なプログラムコードが実行され、
    該プログラムコードには、請求項１から８のいずれか１項記載の方法を前記受信装置（３）に実行させる制御命令が含まれていることを特徴とする受信装置。
14. 請求項１３記載の単方向データ伝送システム（１）における受信装置（３）のためのコンピュータ読み取り可能なプログラムコードにおいて、
    請求項１から８のいずれか１項記載の方法を前記受信装置（３）に実行させる制御命令が含まれていることを特徴とするプログラムコード。
15. 請求項１４記載のコンピュータ読み取り可能なプログラムコードが格納されている記憶媒体。

Images