JP2003304511A - 通信端末、サーバ装置、中継装置、放送通信システム、放送通信方法及びプログラム - Google Patents

Abstract

(57)【要約】 【課題】 放送メディアの放送に伴うオーバーヘッドを
抑えつつ、放送メディアを素早く再生することを可能と
することを目的とする。 【解決手段】 本発明に係る放送通信システム１は、サ
ーバ装置１０から通信端末２０に放送メディアを送信す
るものであって、サーバ装置１０は、少なくとも一つの
放送メディアを指定する放送通知情報（ＳＡＰメッセー
ジ）を送信し、通信端末２０による放送メディアの再生
に先立って、指定された放送メディアの再生方法を示す
再生情報を送信し、通信端末２０は、放送通知情報を受
信した場合に、再生情報に基づいて、放送通知情報（Ｓ
ＡＰメッセージ）により指定された放送メディアを再生
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、映像（ビデオ）情
報、音声（オーディオ）情報等の放送メディアを放送す
るための放送通信システム、放送通信方法、及び、これ
らに用いて好適な通信端末、サーバ装置、中継装置及び
プログラムに関する。

【０００２】

【従来の技術】近年、デジタル衛星放送通信システムの
普及が進んでいる。デジタル衛星放送通信システムで
は、大容量の通信帯域を利用して多チャンネル化がなさ
れており、スポーツ、映画、音楽、ニュース等の専門チ
ャネルが多数用意されている。これらの専門チャンネル
では、それぞれの専門の企画、内容に応じた番組コンテ
ンツが放送されている。そして、上記デジタル衛星放送
通信システムを利用して、かかる番組コンテンツの再生
を可能とする放送メディアの放送が行われている。

【０００３】このような映像情報、音声情報等の放送メ
ディアを放送する放送通信方式として、特開２０００-
３５８０６２号公報には、ＭＰＥＧ-２システム規格の
データ送信フォーマットを用いて放送メディア等の各種
データを送信する「デジタルデータ送受信システム及び
その方法」が開示されている。

【０００４】また、放送メディア等の各種データを繰り
返し伝送する放送通信方式として、特開２００１-５３
６９６号公報には、ＩＳＯ/ＩＥＣ１３８１８-６で規定
された「ＤＳＭ-ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇ
ｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒ
ｏｌ）データカルーセル方式」を用いて放送メディア等
の各種データを放送する方式、すなわち、放送メディア
等の各種データがＩＳＯ/ＩＥＣ１３８１８-１で規定さ
れたセクション形式に準拠した形式で繰り返し伝送され
る「デジタル放送におけるセクション送出装置及びセク
ション送出方法」が開示されている。

【０００５】一方、インターネットにおける放送通信方
式としては、放送通知情報として「ＳＡＰ（Ｓｅｓｓｉ
ｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）
メッセージ」を用いて「放送メディアを再生するために
必要な情報（発信元のＩＰアドレス情報や送信先のＩＰ
アドレス情報等）」を通知して、音声情報や映像情報等
の放送メディアの放送を行う放送通信方式が考えられて
いる。

【０００６】ＳＡＰメッセージは、予め決められた「Ｉ
Ｐアドレス」及び「ポート番号」にて伝送される。ま
た、ＳＡＰメッセージは、ＳＡＰメッセージ内に含まれ
る「当該ＳＡＰメッセージの発信元のＩＰアドレス情報
（ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ）」及び「当
該発信元によって送信されるＳＡＰメッセージを一意に
特定するメッセージＩＤ（ｍｓｇ ｉｄ ｈａｓｈ）」
によって、一意に識別される。

【０００７】インターネットにおけるＳＡＰメッセージ
を用いた放送通信方式では、ＳＡＰメッセージ内の「Ｓ
ＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒ
ｏｔｏｃｏｌ）情報」内の「ｃフィールド」に、放送メ
ディアが送信されている「マルチキャストアドレス（送
信先のＩＰアドレス情報）」を指定するのが一般的であ
る。受信者は、当該「ｃフィールド」により放送メディ
アが送信されている「マルチキャストアドレス（送信先
のＩＰアドレス情報）」を知り、当該放送メディアを視
聴することが可能となる。

【０００８】図４５に、従来の放送通信システムにおい
て、２つの放送メディアを送信する例を示す。

【０００９】具体的には、図４５は、１つのチャネル上
で、２つの「ＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ
２）」と、各ＳＡＰメッセージに対応する「ＲＴＰ（Ｒ
ｅａｌ-ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃ
ｏｌ：ＲＦＣ１８８９）パケット（ＲＴＰ１-ａ及びＲ
ＴＰ１-ｂ，ＲＴＰ２-ａ及びＲＴＰ-ｂ）」とを送信す
る例である。

【００１０】図４６は、ＳＡＰメッセージ内での「ＳＤ
Ｐ情報」の記述例である。図４６では、「ｃ＝ＩＮ Ｉ
Ｐ４ ２２４．２．１７．１２/１２７」の部分で、放
送メディアの「マルチキャストアドレス（送信先のＩＰ
アドレス情報）」が示されている。したがって、このＳ
ＡＰメッセージを受信した受信端末は、かかるマルチキ
ャストアドレスにより放送メディアが放送されることが
判断できる。

【００１１】また、パケット型通信方式では、音声情報
及び映像情報を含むパケットは、ＲＴＰパケットとして
伝送される。ＲＴＰパケットには、ヘッダとして「ＲＴ
Ｐ／ＵＤＰ／ＩＰヘッダ」が付加されることになり、そ
のオーバーヘッドが非常に大きい。

【００１２】ＲＴＰ／ＵＤＰ／ＩＰヘッダのオーバーヘ
ッドを低減（圧縮）する方法としては、ＩＥＴＦのＲＦ
Ｃ２５０８で規定される「ＣＲＴＰ」やＲＦＣ３０９５
で規定される「ＲＯＨＣ」が知られている。

【００１３】いずれのヘッダ圧縮方法も、最初に、ヘッ
ダ圧縮状態を初期化する「ヘッダ圧縮リフレッシュパケ
ット」を送信した後、ヘッダの圧縮された「ヘッダ圧縮
パケット」を送信する。「ＣＲＴＰ」では、「ＦＵＬＬ
＿ＨＥＡＤＥＲ」が、ヘッダ圧縮リフレッシュパケット
に当たり、「ＲＯＨＣ」では、「ＩＲヘッダ」が、ヘッ
ダ圧縮リフレッシュパケットに当たる。

【００１４】

【特許文献１】特開２０００-３５８０６２号公報

【００１５】

【特許文献２】特開２００１-５３６９６号公報

【００１６】

【発明が解決しようとする課題】一般的に、大容量の通
信帯域を有するデジタル衛星放送通信システムやインタ
ーネットにおける放送通信システムにおいては、放送メ
ディアの繰り返し送信におけるオーバーヘッドにも寛容
である。

【００１７】しかしながら、比較的小容量（低ビットレ
ート）の通信帯域しか利用できない移動通信端末等を受
信端末とする放送通信システムにおいては、上述のオー
バーヘッドにより、音声情報や映像情報等の伝送容量の
圧迫がより顕著に表れるという問題点があった。

【００１８】また、上述のオーバーヘッドを抑えるため
に、上記で説明したヘッダ圧縮方法を単純にパケット型
放送通信システムに適用した場合、放送メディアの放送
の途中から視聴を始めた受信端末では、ヘッダ圧縮パケ
ットを受信しても、ヘッダ圧縮状態が分からないため、
当該パケットを復元することができないという問題点が
あった。

【００１９】また、従来のインターネットにおけるＳＡ
Ｐメッセージを用いた放送通信方式では、放送メディア
の送信に用いられる「物理チャネル」が１つしかないた
め、ＳＡＰメッセージ内の「ＳＤＰ情報」の「ｃフィー
ルド」に記述されたＩＰアドレスの指定で、放送メディ
アを視聴することができるが、移動通信端末を用いた放
送通信方式では、複数の無線チャネル（物理チャネル）
を用いて複数の放送メディアを放送することが考えられ
るため、上述のＩＰアドレスの指定だけでは、どの無線
チャネルに放送メディアが流れているかを特定すること
ができないという問題点があった。

【００２０】すなわち、移動通信端末を用いた放送通信
方式では、放送メディアの放送に用いる「物理チャネ
ル」と「論理アドレス（ＩＰアドレス）」とを、どのよ
うに対応付けるかという課題が生じる。

【００２１】さらに、受信端末からの指示によってマル
チメディア情報を受信して再生する通信方式と違って、
放送通信方式におけるマルチメディア情報（放送メディ
ア）の受信及び再生では、放送メディア提供者（発信
元）は、受信者がどのタイミングで受信を始めるか知る
ことができず、受信者に放送メディアを確実に再生させ
ることができない場合があるという問題点があった。

【００２２】本発明は、かかる問題点に鑑みてなされた
もので、放送メディアの放送に伴うオーバーヘッドを抑
えつつ、放送メディアを素早く再生することを可能とす
ることを目的とする。

【００２３】また、本発明は、放送通知情報（ＳＡＰメ
ッセージ又はＨ.２４５メッセージ）を送信した直後に
送信する放送メディアを、ヘッダ圧縮リフレッシュパケ
ットによって送信することによって、放送メディアの放
送の途中から視聴を始めた受信端末であっても、直ちに
放送メディアを再生することを可能とすることを目的と
する。

【００２４】このことにより、放送通知情報を受信し、
放送メディアの放送の途中から視聴を始めた受信端末で
あっても、ヘッダ圧縮リフレッシュパケットによって送
信された放送メディアを受信した後、ヘッダ圧縮パケッ
トによって送信された放送メディアを再生することが可
能となり、すばやい再生と伝送のオーバーヘッドの削減
を実現することが可能となる。

【００２５】また、本発明は、放送メディアの放送に用
いる「物理チャネル」と「論理アドレス（ＩＰアドレ
ス）」とを対応付け、受信端末に通知することを目的と
する。

【００２６】さらに、本発明は、放送メディア提供者が
意図する再生方法を、受信端末に指示することを可能と
し、受信端末が当該指示に従って放送メディアを再生す
ることを目的とする。

【００２７】

【課題を解決するための手段】本発明の第１の特徴は、
受信した放送メディアを再生する通信端末であって、前
記放送メディアの再生に先立って、該放送メディアの再
生方法を示す再生情報を取得し、少なくとも一つの前記
放送メディアを指定する放送通知情報を受信した場合、
前記再生情報に基づいて、指定された該放送メディアを
再生することを要旨とする。

【００２８】かかる発明によれば、通信端末が、再生情
報に基づいて放送メディアを再生するため、放送メディ
アの提供者が意図する再生方法に従って、任意の放送メ
ディアを素早く再生することが可能となる。また、事前
に取得した再生情報（予め保持しているもの等）を用い
ることによって、無線チャネルを介して全ての再生情報
を受信する前に放送メディアを再生することが可能とな
る。

【００２９】本発明の第１の特徴において、前記放送メ
ディアの再生に先立って、前記再生情報に関連付けられ
た参照情報を取得し、前記参照情報を用いて前記再生情
報を取得することが好ましい。

【００３０】また、本発明の第１の特徴において、前記
再生情報が、前記放送メディアの再生の際に用いられる
レイアウト情報を含むことが好ましい。

【００３１】かかる発明によれば、通信端末の表示部に
おいて、放送メディアを表示するレイアウトを自由に変
更することが可能となる。

【００３２】また、本発明の第１の特徴において、前記
再生情報が、前記放送メディアの再生の際に用いられる
タイミング情報を含むことが好ましい。

【００３３】かかる発明によれば、通信端末において、
放送メディアの再生についての時間同期制御、例えば、
映像情報とテキスト情報の同期処理等を行うことが可能
となる。

【００３４】また、本発明の第１の特徴において、前記
放送メディアの再生に先立って、必ず行うべき必須処理
を示す必須処理情報を受信した場合に、前記必須処理を
行った後で該放送メディアを再生することが好ましい。

【００３５】かかる発明によれば、放送メディアの提供
者の意図を、通信端末における放送メディアの再生によ
り詳細に反映させることが可能となる。

【００３６】また、本発明の第１の特徴において、前記
必須処理情報が、放送通知情報に含まれていることが好
ましい。

【００３７】かかる発明によれば、配信データが欠落す
る環境においても、通信端末において、放送メディア再
生のための再生情報を処理する前に必須処理情報を取得
することができ、放送メディア提供者の意図を反映する
ことが可能となる。

【００３８】また、本発明の第１の特徴において、前記
必須処理情報が、前記放送メディアの再生と同時に行う
べき処理内容を示すものであり、前記通信端末が、前記
放送メディアの再生と同時に前記必須処理を行うことが
好ましい。

【００３９】また、本発明の第１の特徴において、無線
チャネルを介して受信した前記放送メディアを再生する
場合であって、前記放送通知情報に、前記放送メディア
が送信される物理チャネル識別情報と論理チャネル識別
情報との対応情報とが含まれている場合に、該対応情報
に基づいて、該放送メディアを再生することが好まし
い。

【００４０】かかる発明によれば、通信端末において、
放送メディアの放送に用いる「物理チャネル」と「論理
アドレス（ＩＰアドレス）」とを対応付けることが可能
となる。

【００４１】また、本発明の第１の特徴において、前記
論理チャネル識別情報は、ＩＰアドレスであることが好
ましい。また、本発明の第１の特徴において、前記物理
チャネル識別情報が、ＣＤＭＡ通信方式のチャネライゼ
ーションコードであることが好ましい。また、本発明の
第１の特徴において、前記物理チャネル識別情報は、周
波数値であることが好ましい。

【００４２】また、本発明の第１の特徴において、前記
放送通知情報が、前記放送メディアを識別する放送メデ
ィア識別情報を含み、前記再生情報として、前記放送メ
ディア識別情報を用いることが好ましい。

【００４３】本発明の第２の特徴は、放送メディアを通
信端末に配信するサーバ装置であって、少なくとも一つ
の放送メディアを指定する放送通知情報を送信し、前記
通信端末による前記放送メディアの再生に先立って、該
放送通知情報によって指定された前記放送メディアの再
生方法を示す再生情報を送信することを要旨とする。

【００４４】本発明の第２の特徴において、前記通信端
末による前記放送メディアの再生に先立って、前記再生
情報に関連付けられた参照情報を送信することが好まし
い。

【００４５】かかる発明によれば、サーバ装置が、再生
情報の代わりに参照情報を送信するため、サーバ装置
が、再生情報を送信することなく、放送メディアの提供
者が意図する再生方法を通信端末に送信することが可能
となると共に、サーバ装置から通信端末に送信するデー
タ量を削減することも可能となる。

【００４６】本発明の第２の特徴において、放送通知情
報を周期的に繰り返し送信し、前記放送通知情報を送信
した直後に、カルーセルデータによって、前記再生情報
を送信することが好ましい。

【００４７】かかる場合、放送通知情報（ＳＡＰメッセ
ージ）及びカルーセルデータにより繰り返し送信される
再生情報（ＳＭＩＬ）によって、放送メディアの放送の
途中から視聴を始めた通信端末であっても、放送メディ
アを再生することが可能となる。

【００４８】また、本発明の第２の特徴において、前記
放送通知情報が、前記カルーセルデータによって前記再
生情報を送信することを示すことが好ましい。

【００４９】かかる発明によれば、カルーセルデータに
よって送信される再生情報（ＳＭＩＬ）を変更すること
によって、放送通知情報（ＳＡＰメッセージ）を変更す
ることなく、放送メディアの送信を継続することが可能
となる。

【００５０】また、本発明の第２の特徴において、前記
再生情報が、前記放送メディアの再生の際に用いられる
レイアウト情報を含むことが好ましい。

【００５１】また、本発明の第２の特徴において、前記
再生情報が、前記放送メディア再生の際に用いられるタ
イミング情報を含むことが好ましい。

【００５２】また、本発明の第２の特徴において、前記
通信端末による前記放送メディアの再生に先立って、該
通信端末が必ず行うべき必須処理を示す必須処理情報を
送信することが好ましい。

【００５３】また、本発明の第２の特徴において、前記
必須処理情報が、前記放送通知情報に含まれることが好
ましい。

【００５４】また、本発明の第２の特徴において、前記
必須処理情報が、前記通信端末によって前記放送メディ
アの再生と同時に行われるべき処理内容を示すものであ
ることが好ましい。

【００５５】また、本発明の第２の特徴において、無線
チャネルを介して放送メディアを通信端末に配信する場
合に、前記放送通知情報によって、前記放送メディアが
送信される物理チャネル識別情報と論理チャネル識別情
報との対応情報を送信することが好ましい。

【００５６】また、本発明の第２の特徴において、前記
論理チャネル識別情報が、ＩＰアドレスであることが好
ましい。また、本発明の第２の特徴において、前記物理
チャネル識別情報が、ＣＤＭＡ通信方式のチャネライゼ
ーションコードであることが好ましい。また、本発明の
第２の特徴において、前記物理チャネル識別情報が、周
波数値であることが好ましい。

【００５７】また、本発明の第２の特徴において、前記
放送通知情報の送信後、最初に、他の放送メディアを参
照することなく再生可能な形式で、前記放送メディアを
前記通信端末に送信することが好ましい。

【００５８】また、本発明の第２の特徴において、前記
放送通知情報の送信後、最初に、予測符号化を行うこと
なく再生可能な形式で（ヘッダ圧縮リフレッシュパケッ
トやＩピクチャフレーム等によって）、前記放送メディ
アを前記通信端末に送信することが好ましい。

【００５９】かかる発明によれば、通信端末は、放送通
知情報の送信後に最初に送信された放送メディアを受信
した場合、他の放送メディア（ヘッダ圧縮リフレッシュ
パケットやＩピクチャフレーム等によって送信される放
送メディア）の受信を待つまでもなく、直ちに当該放送
メディアを再生することが可能となる。

【００６０】また、本発明の第２の特徴において、前記
放送通知情報の送信後に最初に送信する放送メディアと
その旨を示す識別情報とを関連付けて送信することが好
ましい。

【００６１】また、本発明の第２の特徴において、前記
放送メディアを識別する放送メディア識別情報を含む前
記放送通知情報を送信し、前記メディア識別情報と前記
再生情報とを関連付けて送信するように機能させること
が好ましい。

【００６２】本発明の第３の特徴は、サーバ装置から送
信された放送メディアを通信端末に中継する中継装置で
あって、前記サーバ装置によって放送通知情報が送信さ
れた後に最初に送信された少なくとも１つの放送メディ
アを、他の放送メディアを参照することなく再生可能な
形式で前記通信端末に中継することを要旨とする。

【００６３】かかる発明によれば、中継装置が、放送通
知情報（ＳＡＰメッセージやＨ.２４５メッセージ）の
後に最初に受信した放送メディア以外の放送メディア
を、ヘッダ圧縮パケット又はＩピクチャフレーム等とし
て通信端末に中継するため、オーバーヘッドを削減する
ことが可能となる。

【００６４】また、かかる発明によれば、中継装置が、
放送通知情報（ＳＡＰメッセージやＨ.２４５メッセー
ジ）の後に最初に受信した放送メディア以外の放送メデ
ィアを、ヘッダ圧縮パケット又はＩピクチャフレーム等
として通信端末に中継するため、放送メディアの放送の
途中から視聴を始めた通信端末であっても、素早く放送
メディアを再生することを可能となる。

【００６５】また、本発明の第４の特徴は、サーバ装置
から送信された放送メディアを通信端末に中継する中継
装置であって、前記サーバ装置から受信した前記放送メ
ディアに、該放送メディアが放送通知情報の送信後に最
初に送信するものである旨を示す識別情報が関連付けら
れている場合に、他の放送メディアを参照することなく
再生可能な形式で、該放送メディアを前記通信端末に中
継することを要旨とする。

【００６６】かかる発明によれば、放送通知情報の送信
後に最初に送信するものである旨を示す識別情報に関連
付けられた放送メディアについては、他の放送メディア
を参照することなく再生可能な形式で（例えば、ヘッダ
圧縮リフレッシュパケット）として中継するため、放送
メディアの放送の途中から視聴を始めた通信端末であっ
ても、素早く放送メディアを再生することが可能とな
る。

【００６７】また、本発明の第５の特徴は、サーバ装置
から送信された放送メディアを通信端末に中継する中継
装置であって、前記サーバ装置から受信した前記放送メ
ディアに、該放送メディアが放送通知情報の送信後に最
初に送信するものである旨を示す識別情報が関連付けら
れている場合に、該放送メディアを、予測符号化を行う
ことなく再生可能な形式で、該放送メディアを前記通信
端末に中継することを要旨とする。

【００６８】かかる発明によれば、放送通知情報の送信
後に最初に送信するものである旨を示す識別情報に関連
付けられた放送メディアについては、予測符号化を行う
ことなく再生可能な形式で、（例えば、Ｉピクチャフレ
ーム等）として中継するため、放送メディアの放送の途
中から視聴を始めた通信端末であっても、素早く放送メ
ディアを再生することが可能となる。

【００６９】本発明の第６の特徴は、サーバ装置から通
信端末に放送メディアを送信する放送通信システムであ
って、前記サーバ装置が、少なくとも一つの放送メディ
アを指定する放送通知情報を送信し、前記通信端末によ
る放送メディアの再生に先立って、前記放送通知情報に
よって指定された前記放送メディアの再生方法を示す再
生情報を送信し、前記通信端末が、前記放送通知情報を
受信した場合に、前記再生情報に基づいて、該放送通知
情報によって指定された前記放送メディアを再生するこ
とを要旨とする。

【００７０】本発明の第７の特徴は、中継装置がサーバ
装置からの放送メディアを通信端末に中継する放送通信
システムであって、前記中継装置が、前記サーバ装置に
よって放送通知情報が送信された後に最初に送信された
少なくとも１つの放送メディアを、他の放送メディアを
参照することなく再生可能な形式で前記通信端末に中継
することを要旨とする。

【００７１】本発明の第８の特徴は、中継装置がサーバ
装置からの放送メディアを通信端末に中継する放送通信
システムであって、前記サーバ装置が、放送通知情報の
送信後に最初に送信するものであるか否かを示す識別情
報を前記放送メディアに関連付けて送信し、前記中継装
置が、前記識別情報に関連付けられた前記放送メディア
を受信した場合に、他の放送メディアを参照することな
く再生可能な形式で、該放送メディアを前記通信端末に
中継することを要旨とする。

【００７２】本発明の第９の特徴は、中継装置がサーバ
装置からの放送メディアを通信端末に中継する放送通信
システムであって、前記サーバ装置が、放送通知情報の
送信後に最初に送信するものであるか否かを示す識別情
報を前記放送メディアに関連付けて送信し、前記中継装
置が、前記識別情報に関連付けられた前記放送メディア
を受信した場合に、予測符号化を行うことなく再生可能
な形式で、該放送メディアを前記通信端末に中継するこ
とを要旨とする。

【００７３】本発明の第１０の特徴は、サーバ装置から
通信端末に放送メディアを送信する放送通信方法であっ
て、前記サーバ装置において、前記サーバ装置におい
て、少なくとも一つの放送メディアを指定する放送通知
情報を送信し、前記通信端末による放送メディアの再生
に先立って、前記放送通知情報によって指定された前記
放送メディアの再生方法を示す再生情報を送信し、前記
通信端末において、前記放送通知情報を受信した場合
に、前記再生情報に基づいて、該放送通知情報によって
指定された前記放送メディアを再生することを要旨とす
る。

【００７４】本発明の第１１の特徴は、中継装置がサー
バ装置からの放送メディアを通信端末に中継する放送通
信方法であって、前記中継装置において、前記サーバ装
置によって放送通知情報が送信された後に最初に送信さ
れた少なくとも１つの放送メディアを、他の放送メディ
アを参照することなく再生可能な形式で該放送メディア
を前記通信端末に中継することを要旨とする。

【００７５】本発明の第１２の特徴は、中継装置がサー
バ装置からの放送メディアを通信端末に中継する放送通
信方法であって、前記サーバ装置において、放送通知情
報の送信後に最初に送信するものであるか否かを示す識
別情報を前記放送メディアに関連付けて送信し、前記中
継装置において、前記識別情報に関連付けられた前記放
送メディアを受信した場合に、他の放送メディアを参照
することなく再生可能な形式で該放送メディアを前記通
信端末に中継することを要旨とする。

【００７６】本発明の第１３の特徴は、中継装置がサー
バ装置からの放送メディアを通信端末に中継する放送通
信方法であって、前記サーバ装置において、放送通知情
報の送信後に最初に送信するものであるか否かを示す識
別情報を前記放送メディアに関連付けて送信し、前記中
継装置において、前記識別情報に関連付けられた前記放
送メディアを受信した場合に、予測符号化を行うことな
く再生可能な形式で該放送メディアを前記通信端末に中
継することを要旨とする。

【００７７】本発明の第１４の特徴は、受信した放送メ
ディアを再生する通信端末を、前記放送メディアの再生
に先立って、該放送メディアの再生方法を示す再生情報
を取得し、少なくとも一つの前記放送メディアを指定す
る放送通知情報を受信した場合、前記再生情報に基づい
て、指定された該放送メディアを再生するように機能さ
せるためのプログラムであることを要旨とする。

【００７８】本発明の第１５の特徴は、放送メディアを
通信端末に配信するサーバ装置を、少なくとも一つの放
送メディアを指定する放送通知情報を送信し、前記通信
端末による前記放送メディアの再生に先立って、該放送
通知情報によって指定された前記放送メディアの再生方
法を示す再生情報を送信するように機能させるプログラ
ムであることを要旨とする。

【００７９】

【発明の実施の形態】以下、本発明の実施形態につい
て、図１乃至図４４を参照しながら、詳細に説明する。
図１は、本発明の実施形態における放送通信システムの
概略構成図である。

【００８０】図１に示すように、本実施形態に係る放送
通信システム１は、放送メディアを配信（送信）するコ
ンテンツ送信サーバ１０と、配信（送信）された放送メ
ディアを受信して再生する受信端末２０と、無線制御装
置４０及び基地局５０から構成される中継装置３０とを
具備する。

【００８１】本実施形態では、放送メディアとは、例え
ば、ＲＴＰパケットやＩピクチャフレームやＰピクチャ
フレーム等を用いたストリーミング形式で送信される音
声情報（ＡＭＲ）や映像情報（ＭＰＥＧ-４）等を指す
ものとする。

【００８２】以下、受信端末２０として移動通信端末を
用いる場合について説明するが、本発明は、移動通信端
末以外の端末を用いた場合にも適用可能である。

【００８３】コンテンツ送信サーバ１０は、インターネ
ット２と中継装置３０と無線チャネルとを介して、放送
メディアをストリーミング形式で受信端末２０に配信す
るサーバ装置である。受信端末２０は、無線チャネルを
介して受信した放送メディアを再生する移動通信端末で
ある。中継装置３０は、必要に応じて、伝送路の物理条
件に合わせたプロトコル/フォーマット変換を行うもの
である。

【００８４】（第１の実施形態）本発明の第１の実施形
態について図１から図１１を用いて説明する。本実施形
態では、インターネットプロトコルである「ＲＴＰ/Ｕ
ＤＰ/ＩＰ」パケット（放送メディアパケット）の形式
で、音声情報や映像情報等を含む放送メディアを伝送す
る放送通信システム１について説明する。

【００８５】本実施形態では、受信端末２０は、音声情
報や映像情報等の放送メディアの再生に先立って、該放
送メディアの再生方法を示す再生情報を取得し、放送通
知情報（ＳＡＰメッセージ）を受信した場合に、前記再
生情報に基づいて放送メディアを再生する。ここで、放
送通知情報（ＳＡＰメッセージ）は、少なくとも一つの
放送メディアを指定するものである。

【００８６】コンテンツ送信サーバ１０は、受信端末２
０による放送メディアの再生に先立って、放送通知情報
（ＳＡＰメッセージ）によって指定されている放送メデ
ィアの再生方法を示す再生情報を送信する。

【００８７】コンテンツ送信サーバ１０は、放送通知情
報（ＳＡＰメッセージ）によって指定される放送メディ
ア（ＡＭＲを含むＲＴＰパケットやＭＰＥＧ４を含むＲ
ＴＰパケット）を送信する前に、放送メディアの再生方
法を示す再生情報を送信する。

【００８８】例えば、コンテンツ送信サーバ１０は、放
送通知情報（ＳＡＰメッセージ）を周期的に繰り返し送
信して、放送通知情報（ＳＡＰメッセージ）を送信した
直後に、カルーセルデータによって再生情報を送信する
ことができる。ここで、カルーセルデータとは、同じデ
ータを繰り返し送信する方式（データカルーセル方式）
によって伝送されるデータのことをいう。

【００８９】ここで、再生情報は、ＳＡＰメッセージの
「ｐａｙｌｏａｄ（ペイロード）」内に記述されている
「ＳＤＰ情報（図４参照）」や、データカルーセル方式
によって送信される「ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚ
ｅｄ ＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎ
Ｌａｎｇｕａｇｅ）（図８参照）」等に含まれている。

【００９０】また、再生情報は、放送メディアの再生の
際に用いられる「レイアウト情報」や、放送メディアの
再生の際に用いられる「タイミング情報」を含むことが
できる。

【００９１】図２は、本実施形態における放送通信シス
テム１におけるコンテンツ送信サーバ１０と受信端末２
０との間のシーケンス図である。

【００９２】図２に示すように、ステップ２０１におい
て、コンテンツ送信サーバ１０が、放送通知情報である
「ＳＡＰメッセージ」を、受信端末２０に送信する。Ｓ
ＡＰメッセージの内容については、後述の図３及び図４
において詳細に説明する。ここで、ＳＡＰメッセージが
通知される「ＩＰアドレス」及び「ポート番号」は、受
信端末２０に既知のものとする。

【００９３】ステップ２０２において、コンテンツ送信
サーバ１０が、「ＳＭＩＬ」を含むカルーセルデータを
受信端末２０に送信する。また、ステップ２０３におい
て、コンテンツ送信サーバ１０が、ＨＴＭＬ形式のテキ
スト情報やアンカー情報を含むカルーセルデータを受信
端末２０に送信する。

【００９４】例えば、ＪＰＥＧ等の静止画像情報やＸＭ
Ｌ形式の構造化データは、ＵＤＰ上でデータを繰り返し
送るデータカルーセル方式にて伝送される（図３５参
照）。データカルーセル方式については、後述の図５乃
至図７の説明において詳細に説明する。

【００９５】ステップ２０４乃至２０７において、コン
テンツ送信サーバ１０が、音声情報（ＡＭＲ）や映像情
報（ＭＰＥＧ-４）を含むＲＴＰパケット（放送メディ
アパケット）を受信端末２０に送信する。

【００９６】ここで、ＳＡＰメッセージ及びカルーセル
データは、ＵＤＰ/ＩＰパケットによって伝送され、音
声情報及び映像情報は、ＵＤＰ/ＩＰ上のＲＴＰパケッ
トによって伝送される（図３５参照）。

【００９７】そして、コンテンツ送信サーバ１０は、Ｓ
ＡＰメッセージを、所定間隔をもって周期的に繰り返し
伝送する。受信端末２０は、ＳＡＰメッセージを受信す
ることにより、放送メディアの再生を開始するので、Ｓ
ＡＰメッセージは、できうる限り短い周期にて伝送する
ことが望ましい。

【００９８】次に、図３及び図４を用いて、ＳＡＰメッ
セージについて説明する。図３は、ＳＡＰメッセージの
フォーマットを示すものである。

【００９９】図３において、「Ｖ」は、バージョン情報
を示す。「Ａ」は、アドレスタイプを示し、Ａ＝０の
時、ＩＰｖ４であり、Ａ＝１の時、ＩＰｖ６である。
「Ｒ」は、「Ｒｅｓｅｒｖｅｄ」である。

【０１００】「Ｔ」は、メッセージタイプを示し、Ｔ＝
０の時、放送開始を示す放送通知情報であることを意味
し、Ｔ＝１の時、放送終了を示す放送通知情報であるこ
とを意味する。

【０１０１】「Ｅ」は、「Ｅｎｃｒｙｐｔｉｏｎ ｂｉ
ｔ」である。「Ｃ」は、「Ｃｏｍｐｒｅｓｓｉｏｎ ｂ
ｉｔ」である。「ａｕｔｈ ｌｅｎ」は、「ｏｐｔｉｏ
ｎａｌ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ」の
サイズを示す。

【０１０２】「ｍｓｇ ｉｄ ｈａｓｈ」は、「ｏｒｉ
ｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」に記述されたＩＰア
ドレスで示される発信元（コンテンツ送信サーバ１０
等）によって送信されるＳＡＰメッセージを一意に特定
するメッセージＩＤである。

【０１０３】「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃ
ｅ」は、ＳＡＰメッセージの発信元のＩＰアドレスであ
る。

【０１０４】ここで、「ｍｓｇ ｉｄ ｈａｓｈ」と
「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」との組み合
わせによって、ＳＡＰメッセージを一意に特定すること
ができる。

【０１０５】「ｏｐｔｉｏｎａｌ ｐａｙｌｏａｄ ｔ
ｙｐｅ」は、「ｐａｙｌｏａｄ」のデータタイプを示
す。「ｐａｙｌｏａｄ」については、図４において詳細
に説明する。

【０１０６】図４は、本実施形態におけるＳＡＰメッセ
ージ内の「ｐａｙｌｏａｄ」に記述された「ＳＤＰ情
報」の例を示す。

【０１０７】「ｖ＝０」は、「ｐａｙｌｏａｄ」のバー
ジョンを示すものであり、「ｐａｙｌｏａｄ」を記述す
るルールを規定するための情報を示している。

【０１０８】「ｏ＝」は、発信元情報であり、発信元の
ＩＰアドレス情報（１２６．１６．６４．４）を含む。
「ｓ＝」は、放送メディアのセッション名である。「ｃ
＝」は、放送メディアを送信しているマルチキャストア
ドレス（送信先のＩＰアドレス情報）である。「ｔ＝」
は、放送メディアの有効期間を示すものである。

【０１０９】「ｍ＝」は、当該ＳＡＰメッセージによっ
て指定されている放送メディアを示す情報であり、図４
に示すＳＡＰメッセージは、放送メディアとして、１つ
の音声情報と１つの映像情報と１つのカルーセルデータ
を指定している。

【０１１０】すなわち、第１の放送メディアを指定する
「ｍ＝ａｕｄｉｏ ３４５６ ＲＴＰ/ＡＶＰ ０」と
いう記述は、音声情報を「３４５６」で特定されるポー
ト番号にて、ＲＴＰパケットによって伝送することを示
している。

【０１１１】また、第２の放送メディアを指定する「ｍ
＝ｖｉｄｅｏ ２２３２ ＲＴＰ/ＡＶＰ ９８」とい
う記述は、映像情報を「２２３２」で特定されるポート
番号にて、ＲＴＰパケットによって伝送することを示し
ている。

【０１１２】また、「ｍ＝ａｐｐｌｉｃａｔｉｏｎ ３
２４１６ ｕｄｐ ｄｃ」という記述は、繰り返し送信
するカルーセルデータを、ＵＤＰパケットを用いて伝送
することを示している。

【０１１３】次に、図５乃至図７を用いて、データカル
ーセル方式にて伝送されるカルーセルデータについて説
明を行う。図５は、本実施形態において用いられるデー
タカルーセル方式を用いたデータ伝送方式の概要を示し
ている。

【０１１４】カルーセルデータは、「ＤＩＩ（Ｄｏｗｎ
ｌｏａｄ ＩｎｆｏｒｍａｔｉｏｎＩｎｄｉｃａｔｉｏ
ｎ）」を含むカルーセルデータパケットと、１つ以上の
「ＤＤＢ（Ｄｏｗｎｌｏａｄ Ｄａｔａ Ｂｌｏｃ
ｋ）」を含むカルーセルデータパケットとによって構成
される。

【０１１５】「ＤＩＩ」は、後続のカルーセルデータパ
ケット（ＤＤＢ）についての情報を含み、「ＤＤＢ」
は、実データ（ブロック単位に分割されたモジュール）
を含む。「ＤＩＩ」については、後述の図６の説明にて
詳細に説明する。

【０１１６】図５は、「ＤＤＢ」が、ブロック単位に分
割された３つのモジュール（「ＳＭＩＬ」と「テキスト
情報（テロップ）」と「アンカー情報（ＵＲＬ）」）を
それぞれ含む場合の例を示している。それぞれのモジュ
ール（ファイル）の内容については、後述の図８乃至図
１０を参照して詳細に説明する。

【０１１７】図５に示すように、各モジュールは、それ
ぞれブロック単位に分割される。さらに、ブロック単位
に分割されたモジュールに、それぞれ「データカルーセ
ルヘッダ」が付加されて、「カルーセルデータ」を構成
する「カルーセルデータパケット」となる。

【０１１８】図６は、本実施形態のデータカルーセル方
式で送信される「ＤＩＩ」の内容について示している。
図６に示すように、「ＤＩＩ」は、「データカルーセル
ヘッダ」と「メッセージ本体データ」と誤り検出のため
の「ＣＲＣ」とから構成される。

【０１１９】「データカルーセルヘッダ」は、「メッセ
ージ種別」と、「データカルーセル識別子」と、「セク
ション番号」と、「最終セクション番号」と、「コンテ
ンツ識別子」と、「有効時間情報」と、「メッセージ本
体サイズ」とで構成される。

【０１２０】「メッセージ種別」は、当該カルーセルデ
ータパケットが、「ＤＩＩ」を含むものか「ＤＤＢ」を
含むものかについて示す情報である。

【０１２１】「データカルーセル識別子」は、当該カル
ーセルデータを一意に特定する識別情報である。「セク
ション番号」は、当該カルーセルデータを構成する「カ
ルーセルデータパケット」を一意に特定する識別情報で
ある。

【０１２２】「最終セクション番号」は、当該カルーセ
ルデータ内のカルーセルデータパケットの数を表す情報
である。「コンテンツ識別子」は、当該カルーセルデー
タパケットの内容（コンテンツ）が更新されるとインク
リメントされるバージョン情報である。

【０１２３】「有効時間情報」は、当該カルーセルデー
タを構成するカルーセルデータパケットが有効である時
間情報を表し、有効時間の開始及び終了を特定する情報
によって構成される。本実施形態では、「有効時間情
報」として「ＮＴＰタイム」を用いている。なお、有効
時間を示す必要の無いときには、明示的に「有効時間情
報」を設定しなくても良い。

【０１２４】「メッセージ本体データ」は、「モジュー
ル数」と、当該モジュール数で示される数分の「モジュ
ール情報１〜Ｎ」とで構成される。

【０１２５】「モジュール数」とは、意味的にまとまっ
た単位であるモジュールの数を表すものである。図５に
示すように、本実施形態に係るモジュールは、「ＳＭＩ
Ｌ」や「テキスト情報（テロップ）」や「アンカー情報
（ＵＲＬ）」等の１つのファイルに対応するものであ
る。

【０１２６】「モジュール情報」は、「モジュールＩ
Ｄ」と、「モジュールサイズ」と、「モジュールバージ
ョン」と、「モジュールのコンテンツタイプ情報」とで
構成される。

【０１２７】「モジュールＩＤ」は、当該カルーセルデ
ータ内で、モジュールを一意に特定する識別情報であ
る。「モジュールサイズ」は、モジュールのデータサイ
ズである。「モジュールバージョン」は、モジュールの
更新情報である。「モジュールのコンテンツタイプ情
報」は、モジュールが含むコンテンツタイプ（例えば、
平文形式のテキスト情報やＨＴＭＬ形式のテキスト情報
等）を示すものである。

【０１２８】図７は、本実施形態でのデータカルーセル
方式で送信される「ＤＤＢ」の内容を示している。図７
に示すように、「ＤＤＢ」は、「データカルーセルヘッ
ダ」と「メッセージ本体データ」と誤り検出に使用され
る「ＣＲＣ」とから構成される。

【０１２９】「データカルーセルヘッダ」は、図６にお
いて説明した「ＤＩＩ」における「データカルーセルヘ
ッダ」と同様に、「メッセージ種別」と、「データカル
ーセル識別子」と、「セクション番号」と、「最終セク
ション番号」と、「コンテンツ識別子」と、「有効時間
情報」と、「メッセージ本体サイズ」とで構成される。

【０１３０】「メッセージ本体データ」は、「モジュー
ルＩＤ」と、「モジュールサイズ」と、「ブロック番
号」と、「最終ブロック番号」と、「ブロックサイズ」
と、「ブロックデータ」とから構成される。

【０１３１】「モジュールＩＤ」は、当該カルーセルデ
ータ内で、モジュールを一意に特定する識別情報であ
る。「モジュールサイズ」は、モジュールのデータサイ
ズである。「ブロック番号」は、当該モジュールが分割
されたブロックを一意に識別する識別子である。「最終
ブロック番号」は、当該モジュールが分割されたブロッ
ク数を示す。「ブロックサイズ」は、後続のブロックの
データサイズを示す。「ブロックデータ」は、ブロック
単位に分割されたモジュールのデータである。

【０１３２】次に、本実施形態において、データカルー
セル方式にて伝送される各モジュール（ファイル）につ
いて説明する。

【０１３３】図８は、本実施形態において、データカル
ーセル方式にて伝送される「ＳＭＩＬ」の記述例を示
す。「ＳＭＩＬ」は、複数の放送メディア間で時間同期
処理を行うために用いられる「タイミング情報」や通信
端末の表示部における放送メディアの表示を変更するた
めの「レイアウト情報」等の再生情報を含む。「ＳＭＩ
Ｌ」は、データカルーセル方式にて伝送されるファイル
（モジュール）として位置付けられる。

【０１３４】図８に示す「ＳＭＩＬ」は、１つの音声情
報と１つの映像情報と２つのテキスト情報とが、同期し
て同時に再生されることを示す。

【０１３５】「＜ａｕｄｉｏ ｓｒｃ＝“：＜ｐｏｒｔ
-ａ０１＞/”/＞」という記述により、ＳＡＰメッセー
ジに示される音声情報用のポートを参照すべき旨が示さ
れている。

【０１３６】「＜ｖｉｄｅｏ ｓｒｃ＝“：＜ｐｏｒｔ
-ｖ０１＞/”ｒｅｇｉｏｎ＝”ａ”/＞」という記述に
より、ＳＡＰメッセージに示される映像情報用のポート
を参照すべき旨が示されている。

【０１３７】「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌ
ｅ０１”ｒｅｇｉｏｎ＝”ｂ”/＞」という記述によ
り、「ＳＭＩＬ」が伝送されるカルーセルデータに含ま
れる「ｍｏｄｕｌｅ０１」で示されるテキスト情報を参
照すべき旨が示されている。

【０１３８】「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌ
ｅ０２“ｒｅｇｉｏｎ＝”ｃ”/＞」という記述によ
り、「ＳＭＩＬ」が伝送されるカルーセルデータに含ま
れる「ｍｏｄｕｌｅ０２」で示されるテキスト情報を参
照すべき旨が示されている。

【０１３９】また、「＜ｌａｙｏｕｔ＞〜＜/ｌａｙｏ
ｕｔ＞」という記述には、音声情報や映像情報やテキス
ト情報を、受信端末２０の表示部に表示するレイアウト
（表示領域）を指定する「レイアウト情報」が示されて
いる。

【０１４０】図９は、図８の「ＳＭＩＬ」における「＜
ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌｅ０１“ｒｅｇｉ
ｏｎ＝”ｂ”/＞」という記述によって参照されるテキ
スト情報（テロップ）の記述例である。

【０１４１】図１０は、図８の「ＳＭＩＬ」における
「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌｅ０２“ｒｅ
ｇｉｏｎ＝”ｃ”/＞」という記述によって参照される
アンカー情報（ＵＲＬ）の記述例である。

【０１４２】なお、データカルーセル方式は、同一のデ
ータを繰り返し伝送するものであり、各放送メディア間
の同期に係るタイミング情報、レイアウト情報、字幕や
アップリンクと連携したアンカー情報（ＵＲＬ）、静止
画像情報、テキスト情報（テロップ・静止文字）、動画
像情報、音声情報等を、繰り返し伝送されるデータとし
てファイル化して伝送することが可能である。

【０１４３】次に、ＳＡＰメッセージを受信する受信端
末２０の動作を説明する。具体的には、受信端末２０に
おいて、ＳＡＰメッセージを受信した後、受信した放送
メディアを再生するまでの動作を説明する。

【０１４４】第１に、ＳＡＰメッセージを受信した受信
端末２０は、ＳＡＰメッセージ（放送通知情報）の受信
をきっかけとして放送メディア（ＲＴＰパケット）の受
信を開始する。

【０１４５】第２に、受信端末２０は、ＳＡＰメッセー
ジを参照することにより、音声情報や映像情報やカルー
セルデータ等の放送メディアが送信されている「ＩＰア
ドレス」や、各放送メディアを再生するために必要な
「ポート番号」や「ＲＴＰペイロードタイプ」等の再生
情報を取得する。

【０１４６】例えば、図４に示すＳＡＰメッセージを受
信した受信端末２０は、「ｃ＝ＩＮＩＰ４ ２２４．
２．１７.１２/１２７」という記述により、各放送メデ
ィアが送信されている「ＩＰアドレス（マルチキャスト
アドレス）」を取得する。

【０１４７】また、受信端末２０は、第１の放送メディ
アを指定する「ｍ＝ａｕｄｉｏ ３４５６ ＲＴＰ/Ａ
ＶＰ ０」という記述により、音声情報が、ポート番号
「３４５６」によってＲＴＰパケットを用いて送信され
ると解析する。

【０１４８】また、受信端末２０は、第２の放送メディ
アを指定する「ｍ＝ｖｉｄｅｏ ２２３２ ＲＴＰ/Ａ
ＶＰ ９８」という記述により、映像情報が、ポート番
号「２２３２」によってＲＴＰパケットを用いて送信さ
れると解析する。

【０１４９】さらに、受信端末２０は、「ｍ＝ａｐｐｌ
ｉｃａｔｉｏｎ ３２４１６ ｕｄｐ ｄｃ」という記
述より、ポート番号「３２４１６」によって、ＵＤＰパ
ケット上で、カルーセルデータが送信されると解析す
る。

【０１５０】第３に、上述の放送メディアについての解
析を行った受信端末２０は、各放送メディアの受信処理
の準備を行い、放送メディアが放送されるのを待つ。

【０１５１】第４に、本実施形態では、ＳＡＰメッセー
ジに引き続き、時間同期情報（タイミング情報）である
「ＲＴＣＰ（ＲＴＰ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏ
ｌ）メッセージ」が送信される。

【０１５２】第５に、ＲＴＣＰメッセージを受信した受
信端末２０は、ＲＴＣＰメッセージに含まれる「ＮＴＰ
タイムスタンプ」と「ＲＴＰタイムスタンプ」との対応
情報（ＮＴＰ-ＲＴＰ関連情報）により、各放送メディ
ア間の時間同期情報（タイミング情報）を得る。これに
より、音声情報と映像情報の放送メディア間の時間同期
情報（タイミング情報）が得られる。

【０１５３】第６に、複数のブロック単位に分割された
カルーセルデータが送信され、受信端末２０が、当該カ
ルーセルデータを受信すると、当該カルーセルデータの
解析を行う。受信端末２０は、複数のブロック単位に分
割された全てのカルーセルデータの受信を行う。なお、
本実施形態では、カルーセルデータは、音声情報及び映
像情報の放送の合間に放送される。

【０１５４】第７に、受信端末２０は、ＲＴＰパケット
にて伝送される音声情報及び映像情報を受信したなら
ば、ＮＴＰタイムスタンプで用いられている時間軸（Ｎ
ＴＰタイム）を基準にして、各放送メディア間の同期を
取りつつ、ストリーミング形式で再生処理を行う。

【０１５５】なお、受信端末２０において、カルーセル
データにて放送されるレイアウト情報を受信する前に、
すばやく映像情報の再生を行いたい場合は、一旦、あら
かじめ決められたレイアウト情報により再生を開始した
後、レイアウト情報を受信し、解析の結果により、レイ
アウトが確定すれば再レイアウトを行えばよい。

【０１５６】なお、コンテンツ送信サーバ１０は、音声
情報及び映像情報の放送の合間にカルーセルデータを放
送してもよいし、ＳＡＰメッセージ送信後、音声情報及
び映像情報の放送に先立ち、カルーセルデータを放送し
てもよい。後者の場合、放送メディアを受信する受信端
末２０が、音声情報及び映像情報の放送メディアの受信
に先立ち、放送メディアの再生に関する制御情報を処理
することが可能となる。

【０１５７】また、音声情報及び映像情報に先立って受
信端末２０が受信するカルーセルデータは、カルーセル
データ全体でなくとも良く、放送メディア再生において
重要な情報を放送メディア再生に先立ち放送しても良
い。ここで、重要な情報とは、映像情報の再生における
レイアウト情報等である。

【０１５８】次に、定期的に繰り返し送信されるＳＡＰ
メッセージを繰り返し受信する受信端末２０での動作を
説明する。

【０１５９】第１に、受信端末２０は、ＳＡＰメッセー
ジに含まれる「ｍｓｇ ｉｄ ｈａｓｈ（メッセージＩ
Ｄ）」及び「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」
を確認することにより、ＳＡＰメッセージが更新されて
いるか否かを判断する。

【０１６０】ここで、放送メディアに関して変更があっ
た場合には、ＳＡＰメッセージに含まれる「メッセージ
ＩＤ」が更新される。「メッセージＩＤ」は、同一の
「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」から送信さ
れるＳＡＰメッセージを一意に識別する情報である。

【０１６１】第２に、ＳＡＰメッセージの更新が示され
ていたならば、ＳＡＰメッセージに含まれる「ｐａｙｌ
ｏａｄ」の確認を行う。

【０１６２】例えば、音声情報や映像情報を伝送する
「ポート番号」や「コーディックタイプ」が変更された
りした場合には、ＳＡＰメッセージに含まれる「メッセ
ージＩＤ」が変更される。

【０１６３】なお、図２には示していないが、本実施形
態では、ＲＴＣＰメッセージを用いて、ＮＴＰタイムと
ＲＴＰタイムとを関連付ける時間同期情報（タイミング
情報）を送っている。

【０１６４】ここで、受信端末２０において、データカ
ルーセル方式にて送られたデータ（ＨＴＭＬ等）と、Ｒ
ＴＰパケットにて送られた映像情報及び音声情報を時間
的に関連付ける方法を示す。

【０１６５】受信端末２０は、各ＲＴＰパケットに対応
するＲＴＣＰメッセージより、ＮＴＰタイムとＲＴＰタ
イムとを関連付けるＮＴＰ-ＲＴＰ関連情報を取得す
る。

【０１６６】データカルーセル方式より、カルーセルデ
ータが有効である時間を示す「有効時間情報（ＮＴＰタ
イムスタンプ）」を取得する。かかる「ＮＴＰタイムス
タンプ」には、有効となる時間を示す「開始ＮＴＰタイ
ムスタンプ」及び無効となる時間を示す「終了ＮＴＰタ
イムスタンプ」とが含まれる。

【０１６７】第３に、音声情報及び映像情報のＲＴＰパ
ケットを受け取った受信端末２０は、ＲＴＰパケットに
含まれるＲＴＰタイムスタンプより、ＮＴＰ-ＲＴＰ関
連情報に基づいて、ＮＴＰタイムスタンプで用いられて
いる時間軸（ＮＴＰタイム）と同期させて、該ＲＴＰパ
ケットに含まれる音声情報又は映像情報を再生処理す
る。

【０１６８】また、受信端末２０は、音声情報及び映像
情報の再生処理において、データカルーセル方式にて受
信したカルーセルデータ（テキスト情報等）が有効とな
る「有効時間情報（ＮＴＰタイムスタンプ）」に応じて
当該カルーセルデータを表示する等のデータ処理を行
う。

【０１６９】なお、「終了ＮＴＰタイムスタンプ」は、
カルーセルデータが無効となる時間を示す時間情報では
なく、カルーセルデータの有効期間を表す期間情報であ
っても良い。

【０１７０】図１１は、本実施形態における受信端末２
０での表示イメージ図である。図１１に示すように、映
像情報と音声情報の再生処理に合わせて、テキスト情報
（テロップや静止文字）やアンカー情報（ＵＲＬ）が同
期して表示されている。

【０１７１】なお、本実施形態では、インターネットと
の親和性を考慮して、ＲＴＣＰメッセージにて、ＮＴＰ
タイムとＲＴＰタイムとを関連付ける「ＮＴＰ-ＲＴＰ
関連情報」を通知しているが、ＲＴＣＰメッセージを用
いずに、ＳＡＰメッセージ内に「ＮＴＰ-ＲＴＰ関連情
報」を含めて通知する等、受信端末２０にて各放送メデ
ィア間の同期処理等の時間に関する処理が可能となるの
であれば、他の方法を用いても良い。

【０１７２】例えば、ＳＡＰメッセージに各放送メディ
ア間の時間同期情報（タイミング情報）を含めても良い
し、当該時間同期情報（タイミング情報）を「ＳＭＩ
Ｌ」に含めても良い。

【０１７３】（第２の実施形態）本発明の第２の実施形
態では、受信端末２０が、放送メディアの再生に先立っ
て、必ず行うべき必須処理を示す必須処理情報を含む
「ＳＡＰメッセージ」を受信する場合の実施例を示す。

【０１７４】ここで、図４に示す「ｐａｙｌｏａｄ」を
有するＳＡＰメッセージの替わりに、図１２に示す「ｐ
ａｙｌｏａｄ」を有するＳＡＰメッセージを受信した場
合の受信端末２０の動作を説明する。

【０１７５】図１２に示す「ｐａｙｌｏａｄ」を有する
ＳＡＰメッセージには、必須処理情報を示す「ｒｅｑｕ
ｉｒｅ＝ｍｉｄ：３；“ｍｏｄｕｌｅ００”＝“ｈｔｔ
ｐ：//ｄｏｃｏｍｏ.ｎｅ.ｊｐ/ｌａｙｏｕｔ０１.ｓｍ
ｉｌ”」という記述が含まれている。

【０１７６】この必須処理情報により示される必須処理
は、放送メディア識別情報「ｍｉｄ：３」で識別される
放送メディアについての処理を行うことが示されてお
り、特に、当該放送メディアについて「ｍｏｄｕｌｅ０
０」を処理することが示されている。ここで、「ｍｉ
ｄ：３」で識別される放送メディアは、カルーセルデー
タであり、「ｍｏｄｕｌｅ００」は、「ＳＭＩＬ」であ
る。

【０１７７】図１３は、必須処理情報を含むＳＡＰメッ
セージを処理する受信端末２０の構成を示す。

【０１７８】図１３に示すように、受信端末２０は、放
送メディアを受信する受信処理部２１と、必須処理情報
処理部２２と、再生処理部２３と、出力部２４とによっ
て構成される。

【０１７９】ここで、再生処理部２３は、放送メディア
同期再生制御部２３ａと、音声情報再生処理部２３ｂ
と、映像情報再生処理部２３ｃと、テキスト・静止画像
情報再生処理部２３ｄとによって構成される。また、出
力部２４は、再生された情報を出力するスピーカ２４ａ
やディスプレイ２４ｂによって構成される。

【０１８０】必須処理情報処理部２２は、受信処理部２
１が受信した放送通知情報（ＳＡＰメッセージ）に必須
処理情報が含まれるか否かを判定し、必須処理情報が含
まれる場合には、放送メディア同期再生制御部２３ａに
おける各放送メディアの再生処理に先立ち、必須処理を
行うことを指示する。

【０１８１】次に、図１４を用いて、図１２に示す必須
処理情報を含むＳＡＰメッセージを受信する場合の受信
端末２０での処理フローを説明する。

【０１８２】図１４に示すように、ステップ１４０１に
おいて、受信処理部２１が、ＳＡＰメッセージを受信し
て、放送メディアが放送されるＩＰアドレス情報（マル
チキャストアドレス）や時間同期情報（タイミング情
報）や各放送メディアの再生情報を取得する。

【０１８３】ステップ１４０２において、必須処理情報
処理部２２が、ＳＡＰメッセージに必須処理情報が含ま
れているか否かの判定を行う。必須処理情報が含まれて
いる場合、必須処理情報処理部２２が、必須処理情報の
解析を行い、解析内容を放送メディア同期再生処理部２
３ａに通知して、本フローは、ステップ１４０３に進
む。一方、必須処理情報が含まれていない場合、本フロ
ーは、ステップ１４０５に進む。

【０１８４】ステップ１４０３において、放送メディア
同期再生処理部２３ａが、通知された必須処理情報に示
された必須処理を実行する。そして、放送メディア同期
再生処理部２３ａが、各放送メディアを順次受信した時
に、必須処理情報及び各放送メディアの再生情報を参照
しながら、各再生処理部２３ｂ乃至２３ｄに再生の指示
を行う。放送メディア同期再生処理部２３ａは、必須処
理情報及び各放送メディアの再生情報を保持しておく。

【０１８５】ステップ１４０４及び１４０５において、
再生指示を受けた再生処理部２３ｂ乃至２３ｄは、放送
メディアの再生処理を行う。

【０１８６】本実施形態における必須処理情報は、ＳＭ
ＩＬの処理を行うことを示すものであり、音声情報や映
像情報の各放送メディアの再生しようとする場合に、Ｓ
ＭＩＬの処理を既に行っていれば該放送メディアの再生
を行い、そうでなければ該放送メディアの再生を開始し
ない。

【０１８７】なお、本実施形態では、必須処理が示され
るファイル（必須処理情報）を一意に特定するＩＤとし
て、ＵＲＬ情報である「ｈｔｔｐ：//ｄｏｃｏｍｏ.ｎ
ｅ.ｊｐ/ｌａｙｏｕｔ０１.ｓｍｉｌ」を用いている。
このように、ＳＡＰメッセージに必須処理情報を一意に
特定するＩＤを含めることにより、必須処理情報が示さ
れているファイル（例えば「ＳＭＩＬ」等）の受信を完
了せずとも必須処理を特定することが可能となり、再生
をすばやく始めることが可能となる。

【０１８８】また、上述のＩＤとして、ＵＲＬ情報を用
いることにより、事前に必須処理情報を保持していなく
とも、ネットワークで接続される他の装置にアクセスす
ることにより、必須処理情報を取得することが可能とな
る。ＵＲＬ情報を用いることにより、必須処理情報に限
らない任意の処理に対する必要な情報を放送により取得
することに限らず、ネットワークで接続される他の装置
から必要に応じて取得することを可能とするものであ
る。

【０１８９】（第３の実施形態）本発明に係る第３の実
施形態では、受信端末２０が、放送メディアの再生に先
立って、再生情報としてのレイアウト情報を含むＳＡＰ
メッセージを受信する場合の実施例を示す。

【０１９０】図１５は、レイアウト情報を含むＳＡＰメ
ッセージ内の「ＳＤＰ情報」における「ｐａｙｌｏａ
ｄ」の記述例である。

【０１９１】図１５に示すように、「ｌａｙｏｕｔ＝
“ｈｔｔｐ：//ｄｏｃｏｍｏ.ｎｅ.ｊｐ/ｌａｙｏｕｔ
０１.ｓｍｉｌ”；ｃｉｄ＝ｄｏｃｏｍｏ０１２３」と
いう記述により、放送メディアの再生の際に用いられる
レイアウト情報が一意に特定される。

【０１９２】図１６は、本実施形態における受信端末２
０の構成図である。

【０１９３】図１６に示すように、受信端末２０は、放
送メディアを受信する受信処理部２１と、レイアウト情
報判定処理部２５と、再生処理部２３と、出力部２４と
によって構成される。

【０１９４】ここで、再生処理部２３は、放送メディア
同期再生制御部２３ａと音声情報再生処理部２３ｂと映
像情報再生処理部２３ｃとテキスト・静止画像情報再生
処理部２３ｄとによって構成される。また、出力部２４
は、再生情報を出力するスピーカ２４ａやディスプレイ
２４ｂによって構成される。

【０１９５】レイアウト情報判定処理部２５は、受信処
理部２１が受信した放送通知情報（ＳＡＰメッセージ）
にレイアウト情報が含まれるか否かを判定し、レイアウ
ト情報が含まれる場合には、放送メディア同期再生制御
部２３ａにその旨を通知する。

【０１９６】ここで、図１７に示すフローチャートを用
いて、図１５で示すレイアウト情報を含むＳＡＰメッセ
ージを受信した時の受信端末２０の動作を説明する。

【０１９７】図１７に示すように、ステップ１７０１に
おいて、ＳＡＰメッセージを受信した受信端末２０の受
信処理部２１は、ＳＡＰメッセージであることの判断及
び当該ＳＡＰメッセージの解析を行う。ここで、受信処
理部２１は、ＳＡＰメッセージより、以降受信する放送
メディアのアドレス情報や再生情報を取得する。

【０１９８】ステップ１７０２において、レイアウト情
報判定処理部２５は、受信したＳＡＰメッセージに、放
送メディアに係るレイアウト情報のＩＤが含まれている
か否かの判定を行う。

【０１９９】レイアウト情報のＩＤが含まれている場
合、ステップ１７０３において、レイアウト情報判定処
理部２５は、該ＩＤによって示されるレイアウト情報を
既に受信端末２０にて保持しているか否かの判定を行
う。

【０２００】すでに、当該レイアウト情報を保持してい
るのであれば、ステップ１７０４において、レイアウト
情報判定処理部２５は、保持するレイアウト情報を放送
メディア同期再生制御部２３ａに通知する。そして、放
送メディア同期再生制御部２３ａは、通知されたレイア
ウト情報に基づきレイアウト処理を行う。

【０２０１】ステップ１７０５において、各再生処理部
２３ｂ乃至２３ｄが、ディスプレイに表示を行う各放送
メディアを受信した場合には、既に処理済みのレイアウ
ト情報に基づき再生表示が行われる。

【０２０２】なお、上述のＩＤによって示されるレイア
ウト情報を受信端末２０にて保持していない場合、ステ
ップ１７０６において、受信端末２０は、当該レイアウ
ト情報を、後続の放送される情報より取得するか、もし
くはネットワークを介して他の装置から取得することが
考えられる。

【０２０３】レイアウト情報のＩＤとして、ＵＲＬ情報
を用いることにより、Ｗｅｂで一般的に用いられている
ＨＴＴＰを用いて容易にデータ取得することが可能であ
る。

【０２０４】（第４の実施形態）本発明の第４の実施形
態では、図１８及び図１９を用いて、複数の放送メディ
ア間で関連して行われる必須処理を指定する例を示す。

【０２０５】図１８は、データカルーセル方式にて伝送
される「ＳＭＩＬ」を示すものであり、「ｒｅｑｕｉｒ
ｅ＝“ｉｄ：ｖ１”」という記述によって、第２のテキ
スト情報を表示すると同時に、「ｉｄ＝“ｖ１”」で識
別される映像情報を再生表示することを必須処理とする
ことが示される。

【０２０６】図１９は、本実施形態での受信端末２０の
構成図である。

【０２０７】受信端末２０は、放送メディアを受信する
受信処理部２１と、再生処理部２３と、出力部２４とに
よって構成される。

【０２０８】ここで、再生処理部２３は、放送メディア
同期再生制御部２３ａと音声情報再生処理部２３ｂと映
像情報再生処理部２３ｃとテキスト・静止画像情報再生
処理部２３ｄと必要条件判定処理部２３ｅとによって構
成される。また、出力部２４は、再生情報を出力するス
ピーカ２４ａやディスプレイ２４ｂで構成される必要条
件判定処理部２３ｅは、放送メディア同期再生制御部２
３ａが、受信処理部２１により受信された「ＳＭＩＬ」
に基づいて、各放送メディアの同期再生処理を行う場合
に、ある特定の放送メディアの再生と同時に行うべき内
容（必須処理）を判定する。本実施形態では、第２のテ
キスト情報を再生する場合には、同時に必須処理として
映像情報の再生が要求されることを判定する。

【０２０９】すなわち、本実施形態では、図１８に示す
「ＳＭＩＬ」の「ｒｅｑｕｉｒｅ＝“ｉｄ：ｖ１”」と
いう記述が、受信端末２０が放送メディアの再生と同時
に行うべき処理内容（すなわち、必須処理情報）に該当
する。

【０２１０】（第５の実施の形態）本実施の形態では、
図１、図２０乃至図２２を用いて、ＳＡＰメッセージの
伝送と同期して、予測符号化を行わない映像情報パケッ
トである「Ｉピクチャフレーム」を伝送する例を示す。

【０２１１】図２０は、コンテンツ送信サーバ１０が、
受信端末２０に映像情報を放送する動作を示すシーケン
ス図である。

【０２１２】図２０に示すように、コンテンツ送信サー
バ１０は、放送メディアと当該放送メディアの再生方法
を示す再生情報等を有するＳＡＰメッセージとを、受信
端末２０に対して繰り返し送信する。受信端末２０は、
ＳＡＰメッセージを受信することにより、音声情報や映
像情報等の各放送メディアの再生情報を取得することが
できる。

【０２１３】映像情報の符号化方法として、前のフレー
ム画像又は隣接するフレーム画像（他の放送メディア）
を参照することにより現在のフレーム画像を再生可能な
方法として「予測符号化」が知られている。例えば、
「Ｐピクチャフレーム」が、「予測符号化」を用いて符
号化されたフレーム画像である。

【０２１４】一方、「Ｉピクチャフレーム」が、「予測
符号化」を行うことなく現在のフレーム画像のみで再生
可能な映像情報フレームである。すなわち、「Ｉピクチ
ャフレーム」は、他の放送メディアを参照することなく
再生可能なものである。

【０２１５】つまり、映像情報フレームを復号化するた
めには、当該映像情報フレームの他の映像情報フレーム
に対する依存関係を知る必要があり、放送メディアの受
信開始直後に受信した放送メディアを必ずしも正しく復
号化できるとは限らない。

【０２１６】例えば、ＭＰＥＧを想定した場合、Ｉピク
チャフレームは、当該Ｉピクチャフレームだけで復号化
することができるものの、Ｐピクチャフレームは、一つ
前の映像情報フレームからの差分情報であるため、当該
Ｐピクチャフレームを復号化するには、一つ前の映像情
報フレームが正しく復号化されている必要がある。

【０２１７】したがって、ＳＡＰメッセージを受信した
直後にＰピクチャフレームで構成される放送メディアを
受信しても、映像情報フレームを直ちに復号化すること
ができず、次にＩピクチャフレームが送信されるまで、
受信端末２０は、放送メディアの再生を待たなければな
らない。

【０２１８】このような待ち時間を低減するためには、
コンテンツ送信サーバ１０は、ＳＡＰメッセージを送信
した後、次に送信する映像情報をＩピクチャフレームで
構成される放送メディアとする。

【０２１９】ＳＡＰメッセージを送信した直後の放送メ
ディアを「Ｉピクチャフレーム」で構成する実施例とし
て、コンテンツ送信サーバ１０において、リアルタイム
に映像情報を符号化する場合と、予め用意された映像情
報に合わせてＳＡＰメッセージを送信する場合の実施例
を示す。

【０２２０】まず、図２１のフローチャートを用いて、
コンテンツ送信サーバ１０が、リアルタイムに映像情報
を符号化する場合の例を示す。図２１は、コンテンツ送
信サーバが、リアルタイムに映像情報フレームの符号化
を行う場合の制御例を示す。

【０２２１】図２１に示すように、ステップ２１０１に
おいて、コンテンツ送信サーバ１０は、ＳＡＰメッセー
ジの送信タイミングになると、ＳＡＰメッセージを生成
する。

【０２２２】ステップ２１０２において、コンテンツ送
信サーバ１０は、映像情報フレームのフローを「リフレ
ッシュ状態（Ｒｅｆｒｅｓｈ＝１）」にセットする。ス
テップ２０１３において、コンテンツ送信サーバ１０
は、ＳＡＰメッセージを受信端末２０に送信する。

【０２２３】一方、ステップ２１１１において、コンテ
ンツ送信サーバ１０は、送信すべき映像情報フレームを
取得する。ステップ２１１２において、コンテンツ送信
サーバ１０は、取得した映像情報フレームが「リフレッ
シュ状態（Ｒｅｆｒｅｓｈ＝１）」であるか否かを判定
する。

【０２２４】コンテンツ送信サーバ１０は、取得した映
像情報フレームが「リフレッシュ状態（Ｒｅｆｒｅｓｈ
＝１）」である場合、ステップ２１１３において、当該
映像情報フレームを「Ｉピクチャフレーム」に符号化し
て、映像情報フローを「非リフレッシュ状態（Ｒｅｆｒ
ｅｓｈ＝０）」にセットする。

【０２２５】一方、コンテンツ送信サーバ１０は、当該
映像情報フレームが「非リフレッシュ状態（Ｒｅｆｒｅ
ｓｈ＝０）」である場合、当該映像情報フレームをＰピ
クチャフレームもしくはＢピクチャフレームに符号化す
る。

【０２２６】なお、本実施形態では、ＳＡＰメッセージ
を用いた例を示したが、本発明は、この場合に限定され
ず、後述する回線交換放送通信方式において、ＳＡＰメ
ッセージの代わりに、Ｈ．２４５メッセージを用いる場
合にも適用することができる。この場合、Ｈ．２４５メ
ッセージを契機として映像情報フレームをＩピクチャフ
レームに符号化することになる。すなわち、この場合
も、放送通知情報（Ｈ．２４５メッセージ）と同期して
映像情報フレームをＩピクチャフレームに符号化する。
この例、すなわち、コンテンツ送信サーバ１０が、Ｈ．
２４５メッセージを送信した後に、Ｉピクチャフレーム
を送信するシーケンスを、後述の図３４に示す。

【０２２７】次に、図２２のフローチャートを用いて、
予め用意された映像情報（放送メディア）に合わせて、
ＳＡＰメッセージを送信する場合の実施例を示す。図２
２は、予め映像情報（放送メディア）が符号化されてい
る場合のコンテンツ送信サーバ１０での処理フローを示
す。

【０２２８】図２２に示すように、ステップ２２０１に
おいて、コンテンツ送信サーバ１０は、コンテンツファ
イルから次に送信しようとする映像情報フレームを検索
する。ステップ２２０２において、コンテンツ送信サー
バ１０は、検索した次に送信しようとする映像情報フレ
ームが、Ｉピクチャフレームか、それ以外かを判別す
る。

【０２２９】当該映像情報フレームがＩピクチャフレー
ムでなければ、ステップ２２０３において、コンテンツ
送信サーバ１０は、当該映像情報フレームをそのまま送
信する。

【０２３０】一方、当該映像情報フレームがＩピクチャ
フレームの場合には、ステップ２２０４において、コン
テンツ送信サーバ１０は、当該映像情報フレームの送信
前にＳＡＰメッセージを生成する。コンテンツ送信サー
バ１０は、ステップ２２０５において、ＳＡＰメッセー
ジ送信後、ステップ２２０３において、Ｉピクチャフレ
ームの映像情報フレームを送信する。

【０２３１】このような制御により、ＳＡＰメッセージ
の送信頻度を必要最低限に抑えることができるととも
に、受信端末２０は、ＳＡＰメッセージ受信後、直ちに
映像情報フレームの復号化を開始することができ無駄が
ない。

【０２３２】なお、本実施形態では、ＳＡＰメッセージ
での例を示したが、本発明は、この例に限定されず、回
線交換放送通信方式の場合には、ＳＡＰメッセージの代
わりに、Ｈ．２４５メッセージを用いてもよい。この場
合、Ｈ．２４５メッセージが、Ｉピクチャフレームの送
信直前に生成され送信されることになる。

【０２３３】なお、本実施形態では、コンテンツ送信サ
ーバ１０において、ＳＡＰメッセージと映像情報フレー
ムのＩピクチャフレームとを同期させる方法を示した
が、中継装置３０にてこれらを同期させる処理を行って
も良い。

【０２３４】（第６の実施形態）本発明の第６の実施形
態では、パケット型放送通信方式において、「ＲＴＰ/
ＵＤＰ/ＩＰ」パケットのヘッダ圧縮を行う例を、図
１、図２３乃至図２６を用いて説明する。図２３は、コ
ンテンツ送信サーバ１０が、繰り返し送信されるＳＡＰ
メッセージとヘッダ圧縮パケットとを、中継装置３０を
介して受信端末２０に送信する動作を示すシーケンス図
である。

【０２３５】本実施形態におけるパケット型放送通信方
式において、音声情報及び映像情報等の放送メディア
は、ＲＴＰパケットとして伝送される。ＲＴＰパケット
には、ヘッダとして「ＲＴＰ/ＵＤＰ/ＩＰヘッダ」が付
加されることになり、そのオーバーヘッドが非常に大き
い。

【０２３６】本実施形態においては、図２３に示すよう
に、コンテンツ送信サーバ１０と中継装置３０の間で
は、ＲＴＰ/ＵＤＰ/ＩＰヘッダについて圧縮することな
しに伝送している。

【０２３７】中継装置３０は、コンテンツ送信サーバ１
０から受信したＲＴＰパケットが、ＳＡＰメッセージを
中継した直後のＲＴＰパケット（図２３におけるステッ
プ２３０１及び２３０２で送信されるＲＴＰパケット）
の場合、ヘッダ圧縮リフレッシュパケットとして当該Ｒ
ＴＰパケットを受信端末２０に送信する。一方、中継装
置３０は、コンテンツ送信サーバ１０から受信したＲＴ
Ｐパケットが、その他のＲＴＰパケットである場合、ヘ
ッダ圧縮パケットとして当該ＲＴＰパケットを送信す
る。

【０２３８】すなわち、図２３において、中継装置３０
は、放送通知情報（ＳＡＰメッセージ）を、コンテンツ
送信サーバ１０から受信した後に最初に受信した少なく
とも１つの放送メディア（ステップ２３０１及び２３０
２で送信されるＲＴＰパケット）を、他の放送メディア
を参照することなく再生可能な形式で（ヘッダ圧縮リフ
レッシュパケットとして）、受信端末２０に中継する。

【０２３９】このことにより、パケット型放送通信方式
において、中継装置３０と受信端末２０との間にヘッダ
圧縮処理を適用した場合、放送メディアの放送の途中か
ら視聴を開始した受信端末２０は、ＳＡＰメッセージを
受信した直後に伝送されるＲＴＰパケットがヘッダ圧縮
パケットであるため、ヘッダ圧縮状態を把握することが
できず、当該ＲＴＰパケットを復元することができない
という問題点を解消することができる。

【０２４０】なお、ここでは、ＲＴＰパケット（ＲＴＰ
/ＵＤＰ/ＩＰヘッダ）についてヘッダ圧縮する場合を説
明したが、ＵＤＰパケット（ＵＤＰ／ＩＰヘッダ）やＩ
Ｐパケット（ＩＰヘッダ）についてヘッダ圧縮を行って
も良い。

【０２４１】次に、図２４を用いて、図２３に示す中継
装置３０におけるヘッダ圧縮処理の具体例を示す。図２
４は、中継装置３０におけるヘッダ圧縮処理を示すフロ
ーチャートである。

【０２４２】図２４に示すように、中継装置３０が、ス
テップ２４０１において、コンテンツ送信サーバ１０か
らパケットを受信し、ステップ２４０２において、次に
送信するパケットがＳＡＰメッセージかどうかを検査す
る。

【０２４３】中継装置３０は、当該パケットがＳＡＰメ
ッセージの場合には、ステップ２４０３において、全て
のＲＴＰパケットのフローｎを「リフレッシュ状態（Ｒ
ｅｆｒｅｓｈ＿ｎ＝１）」にセットし、ステップ２４０
４において、ＳＡＰメッセージをそのままの状態で受信
端末２０送信する。

【０２４４】一方、中継装置３０は、当該パケットがＳ
ＡＰメッセージでない場合には、ステップ２４０５にお
いて、当該パケットがＲＴＰパケットか否かを検査す
る。中継装置３０は、当該パケットがＲＴＰパケットで
なければ、ステップ２４０６において、そのままの状態
で当該パケットを受信端末２０に送信する。

【０２４５】一方、中継装置３０は、当該パケットがＲ
ＴＰパケットである場合には、ステップ２４０７におい
て、当該ＲＴＰパケットの「ＩＰアドレス」、「ポート
番号」及び「ＲＴＰのＳＳＲＣ識別子」から、当該ＲＴ
Ｐパケットがどのフローに当たるのか判断する。本実施
形態では、当該ＲＴＰパケットが「フローｉ」と判定さ
れたとする。

【０２４６】ステップ２４０８において、中継装置３０
は、フローｉが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿
ｉ＝１）」であるかどうかを検査する。フローｉが「リ
フレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝１）」であれ
ば、中継装置３０は、ステップ２４０９において、当該
ＲＴＰパケットをヘッダ圧縮リフレッシュパケットに変
換するとともに、フローｉを「非リフレッシュ状態（Ｒ
ｅｆｒｅｓｈ＿ｉ＝０）」にセットする。そして、ステ
ップ２４１０において、中継装置３０は、当該ヘッダ圧
縮リフレッシュパケットを受信端末２０に送信する。

【０２４７】一方、フローｉが「非リフレッシュ状態
（Ｒｅｆｒｅｓｈ＿ｉ＝０）」であれば、中継装置３０
は、ステップ２４１１において、当該ＲＴＰパケットを
ヘッダ圧縮パケットに変換して、ステップ２４１２にお
いて、受信端末２０に送信する。

【０２４８】なお、本実施形態では、ＲＴＰパケット
（ＲＴＰ/ＵＤＰ/ＩＰヘッダ）についてヘッダ圧縮を行
う場合を説明したが、本発明は、この場合に限定される
ものではなく、ＵＤＰパケット（ＵＤＰ/ＩＰヘッダ）
やＩＰパケット（ＩＰヘッダ）についてヘッダ圧縮を行
う場合にも適用される。

【０２４９】次に、図２５及び図２６を用いて、コンテ
ンツ送信サーバ１０と中継装置３０とが連携したヘッダ
圧縮方法を説明する。

【０２５０】図２５は、コンテンツ送信サーバ１０での
ヘッダ圧縮に関する情報を付加する動作を示すフローチ
ャートである。

【０２５１】図２５に示すように、コンテンツ送信サー
バ１０は、ステップ２５０１において、ＳＡＰメッセー
ジを生成し、ステップ２５０２において、全てのパケッ
トのフローｎを「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿
ｎ＝１）」にセットし、ステップ２５０３において、当
該ＳＡＰメッセージを中継装置３０に送信する。

【０２５２】また、コンテンツ送信サーバ１０は、ステ
ップ２５１１において、フローｉのＲＴＰパケットを生
成し、ステップ２５１２において、当該フローｉが「リ
フレッシュ状態（Ｒｅｆｒｅｓｈ＿ｎ＝１）」であるか
否かについて判定する。

【０２５３】コンテンツ送信サーバ１０は、当該フロー
ｉが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝１）」
である場合、ステップ２５１３において、当該ＲＴＰパ
ケットのＩＰヘッダ内の「ＴＯＳ（Ｔｙｐｅ ｏｆ Ｓ
ｅｒｖｉｃｅ）フィールド」を「０ｘＦＦ」に変更する
とともに、当該フローｉを「非リフレッシュ状態（Ｒｅ
ｆｒｅｓｈ＿ｉ＝０）」に設定し、ステップ２５１４に
おいて、「ＴＯＳフィールド」が「０ｘＦＦ」に設定さ
れたＲＴＰパケットを中継装置３０に送信する。

【０２５４】一方、コンテンツ送信サーバ１０は、当該
フローｉが「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ
＝０）」である場合、「ＴＯＳフィールド」はそのまま
で、ステップ２５１４において、当該ＲＴＰパケットを
中継装置３０に送信する。

【０２５５】図２６は、無線制御装置４０及び基地局５
０からなる中継装置３０における、図２５において説明
したコンテンツ送信サーバ１０から受信したパケット処
理に関する動作を示すフローチャートである。

【０２５６】図２６に示すように、中継装置３０は、ス
テップ２６０１において、コンテンツ送信サーバ１０か
らＲＴＰパケットを受信し、ステップ２６０２におい
て、当該ＲＴＰパケットの「ＴＯＳフィールド」が「０
ｘＦＦ」であるか否かについて検査する。

【０２５７】中継装置３０は、当該ＲＴＰパケットの
「ＴＯＳフィールド」が「０ｘＦＦ」である場合、ステ
ップ２６０３において、当該ＲＴＰパケットをヘッダ圧
縮リフレッシュパケットに変換して、ステップ２６０４
において、受信端末２０に送信する。

【０２５８】一方、中継装置３０は、当該ＲＴＰパケッ
トの「ＴＯＳフィールド」が「０ｘＦＦ」でない場合、
ステップ２６０５において、当該ＲＴＰパケットをヘッ
ダ圧縮パケットに変換して、ステップ２６０６におい
て、受信端末２０に送信する。

【０２５９】すなわち、図２５及び図２６において、コ
ンテンツ送信サーバ１０は、放送通知情報（ＳＡＰメッ
セージ）の送信後に最初に送信する放送メディア（ＲＴ
Ｐパケットとその旨を示す識別情報（ヘッダ圧縮に関す
る情報）とを関連付けて送信する（すなわち、ＲＴＰパ
ケットの「ＴＯＳフィールド」を「０ｘＦＦ」に設定し
て送信する）。

【０２６０】また、中継装置３０は、放送通知情報（Ｓ
ＡＰメッセージ）の送信後に最初に送信するものである
旨を示す識別情報に関連付けられた放送メディア（「Ｔ
ＯＳフィールド」が「０ｘＦＦ」に設定されたＲＴＰパ
ケット）を受信した場合に、放送メディア（ＲＴＰパケ
ット）を、他の放送メディアを参照することなく再生可
能な形式で（ヘッダ圧縮リフレッシュパケットとし
て）、受信端末２０に中継する。

【０２６１】この結果、ＳＡＰメッセージの直後のＲＴ
Ｐパケットがヘッダ圧縮リフレッシュパケットとして送
信され、受信端末２０は当該ＲＴＰパケットを正しく復
元することが可能となる。

【０２６２】なお、本実施形態では、ＲＴＰパケット
（ＲＴＰ/ＵＤＰ/ＩＰヘッダ）についてヘッダ圧縮する
場合を説明したが、本発明は、これに限定されるもので
はなく、ＵＤＰパケット（ＵＤＰ/ＩＰヘッダ）やＩＰ
パケット（ＩＰヘッダ）についてヘッダ圧縮を行う場合
に適用することもできる。

【０２６３】なお、コンテンツ送信サーバ１０で変更す
るフィールド（すなわち、中継装置３０で検査するフィ
ールド）は、「ＴＯＳフィールド」以外に、ＩＰヘッダ
内の「ＩＤフィールド」やＲＴＰヘッダ内の「ＲＴＰマ
ーカービット」などでもよい。すなわち、コンテンツ送
信サーバ１０及び中継装置３０の間で取り決めた共通認
識される情報であれば良い。また、「ＴＯＳフィール
ド」において変更される値は「０ｘＦＦ」以外でもよ
い。

【０２６４】なお、「ＴＯＳフィールド」の優先度を利
用する方法としては、優先度によりデータカルーセル方
式にて伝送するデータの繰り返し送出回数を制御し、優
先度の高いデータカルーセル方式のデータは、他のデー
タよりも送出回数を多くするということが可能である。
このことにより、重要なデータをより確実に受信端末２
０に通知することが可能となる。

【０２６５】（第７の実施形態）本発明の第７の実施形
態では、コンテンツ送信サーバ１０が、複数の無線チャ
ネルを介して放送メディアをストリーミング配信する場
合の例を、図２７乃至図２９を参照して説明する。

【０２６６】図２７の例では、コンテンツ送信サーバ１
０が、ＳＡＰメッセージ用チャネルを介してＳＡＰメッ
セージ（ＳＡＰ１、ＳＡＰ２）を伝送し、番組１用チャ
ネルを介して第１の放送メディア（ＲＴＰ１-ａ、ＲＴ
Ｐ１-ｂ）を伝送し、番組２用チャネルを介して第２の
放送メディア（ＲＴＰ２-ａ、ＲＴＰ２-ｂ）を伝送して
いる。すなわち、図２７の例では、コンテンツ送信サー
バ１０は、番組毎に異なる無線チャネルを使用してい
る。

【０２６７】この場合、コンテンツ送信サーバ１０は、
ＳＡＰメッセージにおいて放送メディア（番組）のＩＰ
アドレス（論理チャネル識別情報）だけ指定したのでは
不十分であり、どの無線チャネルにどの放送メディアが
流れているかについても特定する必要がある。そこで、
コンテンツ送信サーバ１０は、ＳＡＰメッセージ内のＳ
ＤＰ情報の中で、無線チャネルを特定する情報（物理チ
ャネル識別情報）を通知する。

【０２６８】例えば、コンテンツ送信サーバ１０は、図
２８に示すように、ＳＤＰの「ｃフィールド」の中で
「ｃ＝Ｃｈａｎｎｅｌ ＡＢＣＤＥ」というように無線
チャネルを特定する情報を通知する。無線チャネルを特
定する情報としては、ＣＤＭＡ通信方式のチャネライゼ
ーションコードや周波数値等が考えられる。

【０２６９】受信端末２０は、この無線チャネルを特定
する情報に基づいて、放送メディアの流れている無線チ
ャネルを特定し、当該放送メディアを視聴することが可
能となる。

【０２７０】すなわち、本実施形態では、放送通知情報
（ＳＡＰメッセージ）内のＳＤＰ情報に、放送メディア
が送信される物理チャネル識別情報（ＣＤＭＡ通信方式
のチャネライゼーションコードや周波数値等の無線チャ
ネルを特定する情報）と論理チャネル識別情報（放送メ
ディアのＩＰアドレス）との対応情報とが含まれてい
る。

【０２７１】なお、本実施形態では、各放送メディアに
係るＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）をＳＡＰ
メッセージ用チャネルを介して放送する例を示したが、
図２９に示すように、各無線チャネルに対応するＳＡＰ
メッセージ（ＳＡＰ１，ＳＡＰ２）は、各番組用チャネ
ルを介して放送し、共通チャネル（ＳＡＰメッセージ用
チャネル）には、各放送メディアのＩＰアドレス（マル
チキャストアドレス）と無線チャネルを特定する情報と
を関連付ける情報（ＳＡＰ０）を放送するようにしても
良い。

【０２７２】（第８の実施形態）本発明の第８の実施形
態では、Ｈ.２２３多重化フレーム方式を用いて放送メ
ディアを放送する実施例を、図５乃至図９、図３０乃至
図３３を用いて示す。以後、Ｈ.２２３多重化フレーム
方式を回線放送通信方式と呼ぶ。図３０は、回線放送通
信方式での放送通信シーケンス概略図である。ここで、
コンテンツ送信サーバ１０は、Ｈ.２２３多重化フレー
ムのレベルと、受信端末２０の受信能力及び多重分離能
力と、受信端末２０が「Ｓｌａｖｅ端末」であることを
知っているものとする。

【０２７３】図３０に示すように、ステップ３００１に
おいて、受信端末２０は、放送通知情報である「Ｈ.２
４５メッセージ」を受信することにより、「放送メディ
アの論理チャネル情報（論理チャネルパラメータ）」及
び「Ｈ.２２３多重化テーブル」を検出する。

【０２７４】その後、中継装置３０は、音声情報、映像
情報及びカルーセルデータを、Ｈ.２４５メッセージで
記述されたＨ.２２３多重化フレームに従って伝送す
る。

【０２７５】図３１は、回線放送通信方式におけるＨ.
２２３多重化フレームの送信例である。図３１に示すよ
うに、Ｈ．２４５メッセージは、論理チャネルパラメー
タ３１０１及びＨ.２２３多重化テーブル３１０２を含
んでいる。

【０２７６】本実施形態において、論理チャネルパラメ
ータ３１０１は、第１の論理チャネル（ＬＣＮ１）でカ
ルーセルデータが伝送され、第２の論理チャネル（ＬＣ
Ｎ２）で音声情報（ＡＭＲ）が伝送され、第３の論理チ
ャネル（ＬＣＮ３）で映像情報（ＭＰＥＧ-４）が伝送
され、第４の論理チャネル（ＬＣＮ４）でメディア同期
情報が伝送されることを示している。

【０２７７】図３１に示すＨ.２２３多重化テーブル３
１０２の記述｛ＬＣＮ０，ＡＬＬ｝によれば、Ｈ.２２
３多重化フレーム０（Ｅｎｔｒｙ０）は、全て論理チャ
ネルＬＣＮ０によって構成されている。

【０２７８】図３１に示すＨ.２２３多重化テーブル３
１０２の記述｛ＬＣＮ４，１ｂｙｔ｝｛ＬＣＮ１，ＡＬ
Ｌ｝によれば、Ｈ.２２３多重化フレーム１（Ｅｎｔｒ
ｙ１）は、１バイトが第４の論理チャネルＬＣＮ４によ
って構成されており、残りが第１の論理チャネルＬＣＮ
１によって構成されている。

【０２７９】図３１に示すＨ.２２３多重化テーブル３
１０２の記述｛ＬＣＮ４，１ｂｙｔ｝｛ＬＣＮ２，３１
ｂｙｔｅ｝｛ＬＣＮ１、ＡＬＬ｝によれば、Ｈ.２２３
多重化フレーム２（Ｅｎｔｒｙ２）は、１バイトが第４
の論理チャネルＬＣＮ４によって構成されており、３１
バイトが第２の論理チャネルＬＣＮ２によって構成され
ており、残りが第１の論理チャネルＬＣＮ１によって構
成されている。

【０２８０】以下、Ｈ.２２３多重化フレーム３（Ｅｎ
ｔｒｙ３）等の構成についても同様に理解できる。

【０２８１】図３１に示すＨ.２２３多重化フレームの
例では、最初に、Ｈ.２４５メッセージ（ＭＣ＝０）が
伝送され、その後、メディア同期情報（ＬＣＮ４）及び
カルーセルデータ（ＬＣＮ１）が多重化されたＨ.２２
３多重化フレーム１（Ｅｎｔｒｙ１）が伝送されること
を示している。

【０２８２】図３２は、受信端末２０において、上述の
Ｈ.２２３多重化フレームによって伝送されるカルーセ
ルデータと、音声情報及び映像情報とを同期処理する動
作を示すフローチャートである。

【０２８３】図３２に示すように、ステップ３２０１に
おいて、受信端末２０は、Ｈ.２２３多重化フレームに
よって受信したカルーセルデータと、当該Ｈ.２２３多
重化フレームに含まれるメディア同期情報（ｓｙｎｃ
１）とを関連付けて記憶する。

【０２８４】受信端末２０は、ステップ３２０２におい
て、Ｈ.２２３多重化フレームによって音声情報若しく
は映像情報を受信し、ステップ３２０３において、当該
Ｈ.２２３多重化フレームに含まれるメディア同期情報
（ｓｙｎｃ２）を検出する。

【０２８５】受信端末２０は、ステップ３２０４におい
て、カルーセルデータを受信した時に記憶していたメデ
ィア同期情報（ｓｙｎｃ１）と当該メディア同期情報
（ｓｙｎｃ２）が一致するか否かについて判定する。

【０２８６】受信端末２０は、「ｓｙｎｃ１」と「ｓｙ
ｎｃ２」とが一致する場合、ステップ３２０５におい
て、「ｓｙｎｃ１」に関連付けられたカルーセルデータ
を、有効であると判断し、音声情報若しくは映像情報の
再生と同期して処理される。

【０２８７】受信端末２０は、「ｓｙｎｃ１」と「ｓｙ
ｎｃ２」とが一致しない場合、ステップ３２０６におい
て、「ｓｙｎｃ１」に関連付けられたカルーセルデータ
を無効と判断する。

【０２８８】ここで、カルーセルデータは、図５乃至図
７で示したカルーセルデータの仕様と同じものである。
また、カルーセルデータ内のテキスト情報やアンカー情
報等については、それぞれ図９及び図１０で示したもの
と同様とする。

【０２８９】図３３は、本実施形態における「ＳＭＩ
Ｌ」の記述例である。本実施形態に係る「ＳＭＩＬ」
は、１つの音声情報と、１つの映像情報と、２つのテキ
スト情報と、レイアウト情報と、時間同期情報（タイミ
ング情報）とを示している。

【０２９０】ここで、「ＬＣＮ２」は、第２の論理チャ
ネルＬＣＮ２を表し、図３１で説明したように、音声情
報である。「ＬＣＮ３」は、第３の論理チャネルＬＣＮ
３を表し、図３１で説明したように、映像情報である。
「〜/ｍｏｄｕｌｅ０１」は、第１の論理チャネル（Ｌ
ＣＮ１）内で特定されるモジュール（モジュール０１）
を示している。ここで、モジュール０１は、テキスト情
報（テロップ）である。「〜/ｍｏｄｕｌｅ０２」は、
第１の論理チャネル（ＬＣＮ１）内で特定されるモジュ
ール（モジュール０２）を示している。ここで、モジュ
ール０２は、アンカー情報（ＵＲＬ）である。

【０２９１】なお、図３３に示される「ＳＭＩＬ」は、
第１の論理チャネル（ＬＣＮ１）内の特定モジュール
（モジュール００）である。第１の論理チャネル（ＬＣ
Ｎ１）は、図３１で説明したように、カルーセルデータ
である。

【０２９２】本実施形態によれば、伝送されるＨ.２２
３多重化フレームに抜けが生じた場合、データカルーセ
ル方式にて伝送されるデータ（カルーセルデータ）と、
音声情報及び映像情報との意図しない同期再生処理が行
われることが無くなる。

【０２９３】本実施形態において、上述のように、コン
テンツ送信サーバ１０は、放送通知情報であるＨ.２４
５メッセージを周期的に繰り返し送信し、カルーセルデ
ータをＨ.２４５メッセージの送信後に繰り返し送信す
る。

【０２９４】また、コンテンツ送信サーバ１０は、Ｈ.
２４５メッセージの論理チャネルパラメータ及びＨ.２
２３多重化テーブルや、カルーセルデータである「ＳＭ
ＩＬ」によって、放送メディアの再生方法を示す再生情
報を送信する。

【０２９５】（第９の実施形態）本発明の第９の実施形
態では、放送通知情報としてＨ.２４５メッセージを送
出した後の映像情報メッセージをＩピクチャフレームと
する例を示す。本実施形態は、上述の第５の実施形態で
示した「ＳＡＰメッセージ」を「Ｈ．２４５メッセー
ジ」に変更して、回線放送通信方式に適用したものであ
る。

【０２９６】図３４は、コンテンツ送信サーバ１０が、
データ（Ｈ.２４５メッセージ及び映像情報）を放送す
る動作を示すシーケンス図である。

【０２９７】回線放送通信方式において、コンテンツ送
信サーバ１０は、Ｈ．２４５メッセージを繰り返し送信
する。受信端末２０は、Ｈ．２４５メッセージを受信す
ることにより初めて音声情報や映像情報等の放送メディ
アを受信できるようになる。

【０２９８】ここで、放送メディアが映像情報の場合、
受信端末２０は、映像情報フレームを復号化する際、映
像情報フレーム間の依存関係を必要とするため、放送メ
ディアを受信開始直後に、必ずしも正しく映像情報フレ
ームを復号化できるとは限らない。

【０２９９】例えば、ＭＰＥＧ符号化を想定した場合、
Ｉピクチャフレームは、それだけで復号化することがで
きるものの、Ｐピクチャフレームは、一つ前の映像情報
フレームからの差分情報であるため、一つ前の映像情報
フレームが正しく復号化されている必要がある。したが
って、受信端末２０は、Ｈ.２４５メッセージを受信し
た直後にＰピクチャフレームで構成される放送メディア
を受信しても、当該映像情報を直ちに復号化することが
できず、次にＩピクチャフレームが送信されるまで待た
なければならない。

【０３００】このような待ち時間を低減するために、コ
ンテンツ送信サーバ１０は、Ｈ.２４５メッセージを送
信した後、次に送信する映像情報パケットを、必ずＩピ
クチャフレームで構成される映像情報とする。

【０３０１】リアルタイム符号化の場合、コンテンツ送
信サーバ１０は、Ｈ.２４５メッセージの送信を検出し
たときに、その直後に符号化する映像情報フレームをＩ
ピクチャフレームに変換する。

【０３０２】一方、予め映像情報が生成されている場
合、コンテンツ送信サーバ１０は、映像情報の符号化に
おけるＩピクチャフレームの出現周期を、Ｈ.２４５メ
ッセージの繰り返し周期と等しくして符号化する。この
結果、受信端末２０は、Ｈ.２４５メッセージを受信し
た直後の映像情報としてＩピクチャフレームを受信し、
復号化することが可能となるため、映像情報が表示され
るまでの待ち時間を短縮することができる。

【０３０３】（第１０の実施形態）本発明の第１０の実
施形態では、図１、図８、図３３、図３５乃至図３８を
参照して、コンテンツ送信サーバ１０から受信端末２０
へ放送メディアを送信する場合に、放送メディアを中継
する中継装置３０において、伝送プロトコル変換を行う
例を示す。

【０３０４】具体的には、中継装置３０は、コンテンツ
送信サーバ１０からＩＰパケットによって送信された放
送メディアを、Ｈ.２２３多重化フレーム方式に基づく
回線放送通信用プロトコルで送信可能な放送メディアへ
変換し、受信端末２０へ送信する例を示す。

【０３０５】図３５は、本実施形態におけるコンテンツ
送信サーバ１０と中継装置３０との間におけるＩＰパケ
ット型放送通信方式のプロトコルスタックを示す構成図
である。

【０３０６】音声情報（Ｓｐｅｅｃｈ ｃｏｄｉｎｇ、
Ａｕｄｉｏ ｃｏｄｉｎｇ）３５０２、３５０３及び映
像情報（Ｖｉｄｅｏ ｃｏｄｉｎｇ）３５０１の放送メ
ディアは、ストリーミング形式の「ＲＴＰ（３５１０）
/ＵＤＰ（３５１１）/ＩＰ（３５１２）パケット」によ
って伝送される。

【０３０７】カルーセルデータ３５０４は、「ＵＤＰ
（３５１１）/ＩＰ（３５１２）パケット」によって伝
送される。カルーセルデータ３５０４によって伝送され
るデータは、静止画像情報（Ｉｍａｇｅ ｃｏｄｉｎ
ｇ）３５０５やテキスト情報（Ｔｅｘｔ ｄｅｓｃｒｉ
ｐｔｉｏｎ）３５０６やレイアウト情報及び時間同期情
報（Ｌａｙｏｕｔ ＆ Ｓｙｎｃ ｄｅｓｃｒｉｐｔｉ
ｏｎ）３５０８が含まれる。放送通知情報（Ｓｅｓｓｉ
ｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ）３５０９を通知する
ＳＡＰメッセージ３５０７は、「ＵＤＰ（３５１１）/
ＩＰ（３５１２）パケット」によって伝送される。

【０３０８】図３６は、本実施形態における中継装置３
０と受信端末２０との間における回線放送通信方式のプ
ロトコルスタックを示す構成図である。

【０３０９】各放送メディアは、Ｈ.２２３多重化フレ
ーム３６１４により伝送される。音声情報３６０２、３
６０３及び映像情報３６０１は、Ｈ.２２３多重化フレ
ーム上のＡＬ２（３６１１）により伝送される。

【０３１０】カルーセルデータ（３６０４）は、Ｈ.２
２３多重化フレーム上のＡＬ１（３６１２）により伝送
される。カルーセルデータ３６０４によって伝送される
データは、静止画像情報（Ｉｍａｇｅ ｃｏｄｉｎｇ）
３６０６やテキスト情報（Ｔｅｘｔ ｄｅｓｃｒｉｐｔ
ｉｏｎ）３６０５やレイアウト情報及び時間同期情報
（Ｌａｙｏｕｔ ＆ Ｓｙｎｃ ｄｅｓｃｒｉｐｔｉｏ
ｎ）３６０９が含まれる。放送メディアや伝送方式に関
する放送通知情報（Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅ
ｍｅｎｔ）３６０７は、ＡＬ２（３６１３）上のＨ.２
４５メッセージ３６０８により伝送される。なお、Ｈ.
２４５メッセージは、論理チャネル０（ＬＣＮ＝０）に
含まれる。

【０３１１】図３７を参照して、本実施形態における中
継装置３０が、パケット型放送通信方式から回線放送通
信方式へのプロトコル変換を行う動作仕様を説明する。

【０３１２】図３７に示すように、中継装置３０は、ス
テップ３７０１において、コンテンツ送信サーバ１から
パケットを受信し、ステップ３７０２において、受信し
たパケットがＳＡＰメッセージであるか否かについて判
定する。

【０３１３】中継装置３０は、受信したパケットがＳＡ
Ｐメッセージである場合、ステップ３７０３において、
ＳＡＰメッセージ内の放送に関する記述（ＳＤＰ情報）
に基づいて、論理チャネルパラメータ及び多重化テーブ
ルを作成し、ステップ３７０４において、Ｈ.２４５メ
ッセージを生成して、受信端末２０に送信する。

【０３１４】また、中継装置３０は、受信したパケット
がＳＡＰメッセージでない場合、ステップ３７０５にお
いて、受信したパケットがＲＴＣＰメッセージであるか
否かについて判定する。

【０３１５】中継装置３０は、受信したパケットがＲＴ
ＣＰメッセージである場合、ステップ３７０６におい
て、当該ＲＴＣＰメッセージに含まれるＮＴＰタイムス
タンプとＲＴＰタイムスタンプとを関係付ける情報を取
得して記憶する。

【０３１６】また、中継装置３０は、受信したパケット
がＲＴＣＰメッセージでない場合、ステップ３７０７に
おいて、受信したパケットがカルーセルデータであるか
否かについて判定する。

【０３１７】中継装置３０は、受信したパケットがカル
ーセルデータである場合、ステップ３７０８において、
Ｈ.２２３多重化フレームにおけるＡＬ１（図３６の３
６１２）により当該カルーセルデータを受信端末２０に
送信する。

【０３１８】さらに、中継装置３０は、受信したパケッ
トがカルーセルデータでない場合、ステップ３７０９に
おいて、受信したパケットがＲＴＰパケットであると判
断し、ステップ３７１０において、ＲＴＣＰメッセージ
受信時に関連付けられたＲＴＰタイムスタンプとＮＴＰ
タイムスタンプとの対応関係に基づいて、ＲＴＰパケッ
トにて受信した各放送メディアにＮＴＰタイムスタンプ
をマッピングする。

【０３１９】ステップ３７１１において、中継装置３０
は、ＮＴＰタイムスタンプとそのＮＴＰタイムスタンプ
に対応する音声情報又は映像情報を、Ｈ.２２３多重化
フレームの同一フレーム内にて送信する。

【０３２０】図３８は、第１の実施形態にて示した放送
メディアを中継装置３０が受信した場合に生成される論
理チャネルパラメータとＨ.２２３多重化テーブルとＨ.
２２３多重化フレームの一例を示すものである。

【０３２１】図４に示すＳＡＰメッセージを受信した中
継装置３０は、伝送される各放送メディアに係る情報を
取得し、論理チャネルパラメータ及びＨ.２２３多重化
テーブルを作成し、受信端末２０にＨ．２４５メッセー
ジを送信する。中継装置３０は、カルーセルデータを受
信した場合、Ｈ.２２３多重化フレーム１（ＭＣ＝１）
にて当該カルーセルデータを受信端末２０へ送信する。

【０３２２】なお、本実施形態において、図５乃至図８
に示すカルーセルデータの構成に変更点はない。ただ
し、「ＳＭＩＬ」が変更された場合のデータサイズの変
更などは起こりうる。

【０３２３】また、本実施形態では、図８に示す「ＳＭ
ＩＬ」が、図３３に示す「ＳＭＩＬ」に変換されてい
る。すなわち、音声情報に対応するＲＴＰメッセージを
受信するための「ポート番号：３４５６」が「論理チャ
ネル：ＬＣＮ２」に変更され、映像情報に対応するＲＴ
Ｐメッセージを受信するための「ポート番号：２２３
２」が「論理チャネル：ＬＣＮ３」に変更される。

【０３２４】その後、音声情報及び映像情報を含むＲＴ
Ｐパケットを受信した中継装置３０は、ＮＴＰタイムス
タンプを基準として、Ｈ.２２３多重化フレーム２（Ｍ
Ｃ＝２）によって当該ＲＴＰパケットを受信端末２０へ
送信する。ここで、メディア同期情報は、ＮＴＰタイム
スタンプとしている。

【０３２５】なお、カルーセルデータ方式で送信される
データを中継装置３０は、無線区間の電波状況や重み付
け係数等によって、当該データの繰り返し送信回数を変
更することができる。

【０３２６】また、中継装置３０は、Ｈ.２４５メッセ
ージの繰り返し周期を短くするために、受信した１つの
ＳＡＰメッセージに対して複数のＨ.２４５メッセージ
を生成し、受信端末２０に繰り返し送信することも可能
である。逆に、受信したＳＡＰメッセージに変更点がな
ければ、送信すべきＨ.２４５メッセージを間引くこと
も可能である。

【０３２７】（第１１の実施形態）本発明の第１１の実
施形態は、図１、図３９及び図４０を参照して説明す
る。本実施形態では、中継装置３０が、コンテンツ送信
サーバ１０からＩＰパケットにて送信されたデータを、
回線交換型プロトコルで送信可能なデータに変換して受
信端末２０へ放送する場合に、複数の放送メディアに対
応する複数のＳＡＰメッセージを伝送する。

【０３２８】本実施形態を実現する第１の方法は、中継
装置３０が、ＳＡＰメッセージを無線チャネル（物理チ
ャネル）にそれぞれ割り当てることによって、複数の無
線チャネルによって複数の放送メディアを放送するもの
である。第１の方法は、複数の物理チャネルが存在する
場合に採用可能な方法である。

【０３２９】本実施形態を実現する第２の方法は、１つ
の無線チャネル（物理チャネル）によって複数の放送メ
ディアを放送するものである。

【０３３０】図３９は、第１０の実施形態で示した放送
メディアの放送が行われている場合に、別の放送メディ
アの放送を同時に行う場合の中継装置の動作を示すフロ
ーチャート図である。ここで、図３８に示す放送メディ
アの放送は、既に行われているものとする。

【０３３１】図３９に示すように、ステップ３８０１に
おいて、中継装置３０は、コンテンツ送信サーバ１０よ
り、現在放送されている第１の放送メディアに係る第１
のＳＡＰメッセージとは別であると識別できる第２のＳ
ＡＰメッセージを受け取る。

【０３３２】中継装置３０は、ステップ３８０２におい
て、第２のＳＡＰメッセージの内容を取得して、既に記
憶している第１のＳＡＰメッセージの内容とあわせて記
憶し、論理チャネルパラメータの更新と、Ｈ.２２３多
重化テーブルの更新を行う。

【０３３３】ステップ３８０３において、中継装置３０
は、新たなＨ.２４５メッセージを生成し、受信端末２
０に送信する。

【０３３４】図４０に、更新されたＨ．２４５メッセー
ジの論理チャネルパラメータと、Ｈ.２２３多重化テー
ブルと、受信端末２０に伝送されるＨ.２２３多重化フ
レームとを示す。

【０３３５】論理チャネルパラメータは、図３８で示さ
れる第１の放送メディアに関する情報（ＬＣＮ１乃至Ｌ
ＣＮ４参照）に第２の放送メディアに関する情報（ＬＣ
Ｎ５乃至ＬＣＮ８参照）が追加されている。また、Ｈ.
２２３多重化テーブルについても、第１の放送メディア
に関する情報に第２の放送メディアに関する情報が追加
されている。

【０３３６】なお、図３８及び図４０では、ＭＣ＝１，
ＭＣ＝２，ＭＣ＝３，ＭＣ＝４の順でＨ.２２３多重化
フレームを送信する例を示しているが、この順番で送信
しなければならないことはない。また、コンテンツ送信
サーバ１０は、複数存在しても良い。

【０３３７】（第１２の実施形態）本発明の第１２の実
施形態について、図４１乃至４３を参照して説明する。
本実施形態に係る放送通信システムは、放送通知情報
（ＳＡＰメッセージ）に含まれる「メディア識別情報
（ｍｉｄ）」を用いて放送メディアの同期再生を可能と
するものである。

【０３３８】図４１は、ＳＡＰメッセージ内の「ｐａｙ
ｌｏａｄ」内容の一例である。ここで、放送メディア
（音声情報や映像情報や「ＳＭＩＬ」や静止画像情報や
テキスト情報）のそれぞれに対して、メディア識別情報
（ｍｉｄ）が指定されている。

【０３３９】図４１の例では、音声情報（ｍ＝ａｕｄｉ
ｏ）は、「ａ＝ｍｉｄ：１」という記述によって指定さ
れており、映像情報（ｍ＝ｖｉｄｅｏ）は、「ａ＝ｍｉ
ｄ：２」という記述によって指定されている。

【０３４０】また、「ＳＭＩＬ」は、「ａ＝ｍｉｄ：
３」によって指定される放送メディアとして伝送され
る。ここで、「ａ＝ｒｔｐｍａｐ：１００ Ｘ-ｄｃ/８
０００」という記述は、コーデックタイプが「Ｘ-ｄ
ｃ」で、カルーセルデータであることを示し、クロック
周波数が「８０００」であることを示す。また、「ａ＝
ｆｍｔｐ」の行によって、「ｃｏｎｔｅｎｔ-ｔｙｐ
ｅ」がＭＩＭＥ形式で「ＳＭＩＬ」であることが示され
ている。

【０３４１】同様に、「ａ＝ｍｉｄ：４」によって指定
される放送メディアとして静止画像情報（ＪＰＥＧ）が
伝送され、「ａ＝ｍｉｄ：５」によって指定される放送
メディアとしてテキスト情報（ＨＴＭＬ）が伝送される
ことが示されている。

【０３４２】図４２は、本実施形態に係る放送通信シス
テムで使用される「ＳＭＩＬ」の一例を示すものであ
る。ここで、「ａｕｄｉｏ ｓｒｃ＝“ｍｉｄ＝１”」
という記述によって、当該「ＳＭＩＬ」は、ＳＡＰメッ
セージ内の「ｍｉｄ：１」によって指定される放送メデ
ィア（図４１の例では、音声情報）とリンクする。

【０３４３】同様に、当該「ＳＭＩＬ」は、映像情報
（ｍｉｄ：２）や静止画像情報（ｍｉｄ：４）やテキス
ト情報（ｍｉｄ：５）にそれぞれリンクする。

【０３４４】以上のように、本実施形態では、「ＳＭＩ
Ｌ」において、放送メディアの参照は、ＳＡＰメッセー
ジ内のメディア識別情報「ｍｉｄ」によって行われてい
る。この結果、放送メディアの再生情報を、ＳＡＰメッ
セージから取得することが可能となる。

【０３４５】図４３は、「ｍｉｄ：５」によって指定さ
れるテキスト情報（ＨＴＭＬ）内に含まれるリンク情報
の一例を示すものである。ここで、「＜ａ ｈｒｅｆ
＝”ｂｃ-ｌｉｎｋ：// <<ＵＳＥＲ＿ＮＡＭＥ>>；<<
ＳＥＳＳＩＯＮ＿ＩＤ>>/”＞」という記述は、放送通
知情報（ＳＡＰメッセージ）内の「ｏフィールド」で示
される「ユーザ名（図４１の例では“ＤｏＣｏＭ
ｏ”）」と「セッションＩＤ」とに対応する放送通知情
報（ＳＡＰメッセージ）を指定している。

【０３４６】ユーザが、上述のユーザ名とセッションＩ
Ｄとを指定した場合、当該ユーザの受信端末１０が、当
該ユーザ名とセッションＩＤとによって指定されるＳＡ
Ｐメッセージに対応する放送メディアを再生する。

【０３４７】図４３に示す「＜ａ ｈｒｅｆ＝”ｂｃ-
ｌｉｎｋ：// <<ＵＳＥＲ＿ＮＡＭＥ>>；<<ＳＥＳＳＩ
ＯＮ＿ＩＤ>>/”＞」という記述によって、図４１に示
すＳＡＰメッセージが一意に特定され、当該ＳＡＰメッ
セージに対応する放送メディアが指定される。

【０３４８】本実施形態に係る放送通信システムによれ
ば、放送通知情報（ＳＡＰメッセージ）を指定すること
が可能となり、他の放送メディアの放送への切り替えを
行うこと（他の放送メディアによる番組コンテンツにジ
ャンプすること）が可能となる。

【０３４９】（その他）また、本明細書に記載された全
ての実施形態において、コンテンツ送信サーバ１０と中
継装置３０は、別の構成として説明したが、中継装置３
０がコンテンツ送信サーバ１０の機能を併せ持っても良
い。

【０３５０】また、コンピュータ４１０１に、本明細書
に記載されたコンテンツ送信サーバ１０、受信端末２
０、中継装置３０の機能を実行させるためのプログラム
を、コンピュータ読み取り可能な記録媒体に記録するこ
とができる。このコンピュータ読み取り可能な記録媒体
は、図４４に示すように、例えば、フロッピィーディス
ク４１０２、コンパクトディスク４１０３、ＩＣチップ
４１０４、カセットテープ４１０５等が挙げられる。ま
た、上述のコンピュータ４１０１には、デスクトップ型
ＰＣの他、ノート型ＰＣや携帯情報端末等も含まれる。

【０３５１】

【発明の効果】本発明によれば、受信端末２０が、放送
メディアの再生方法を示す再生情報（ＳＡＰメッセージ
内のＳＤＰ情報やデータカルーセル方式で送信されるＳ
ＭＩＬの記述）に基づいて放送メディア（音声情報や映
像情報等）を再生するため、放送メディアの提供者が意
図する再生方法に従って、任意の放送メディアを素早く
再生することが可能となる。

【０３５２】また、本発明によれば、再生情報としてレ
イアウト情報を送信することによって、放送メディアの
提供者は、受信端末２０のディスプレイにおける放送メ
ディアの表示を自由に変更することが可能となる。

【０３５３】また、本発明によれば、放送メディアの提
供者は、放送メディアの再生についてのタイミング制
御、例えば、映像情報とテキスト情報との時間同期処理
等を行うことが可能となる。

【０３５４】また、事前に取得した再生情報（予め保持
しているもの等）を用いることによって、受信端末２０
は、再生情報（ＳＭＩＬ）を、全て無線チャネルを介し
て受信する前に放送メディアを再生することが可能とな
る。

【０３５５】また、本発明によれば、受信端末２０にお
いて、放送メディアの放送に用いる物理チャネル（無線
チャネル）と、論理アドレスであるＩＰアドレスとを対
応付けることが可能となる。

【０３５６】また、本発明によれば、コンテンツ送信サ
ーバ１０が、再生情報の代わりに参照情報を送信するた
め、放送メディアの提供者が意図する再生方法を受信端
末２０に送信することが可能となると共に、送信するデ
ータ量を削減することも可能となる。

【０３５７】また、本発明によれば、繰り返し送信され
る放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッ
セージ）と再生情報（又は参照情報）によって、放送メ
ディアの放送の途中から視聴を始めた受信端末２０であ
っても、放送メディアを素早く再生することが可能とな
る。

【０３５８】また、本発明によれば、カルーセルデータ
内の情報が変わろうともＳＡＰメッセージ（又はＨ.２
４５メッセージ）は変わることがなく、放送メディアの
送信を継続することが可能となる。

【０３５９】また、本発明によれば、受信端末２０は、
放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセ
ージ）の直後に受信した第１の放送メディア（ＲＴＰパ
ケットや映像情報フレーム）について、他の放送メディ
ア（映像情報フレーム）を参照することなく再生可能で
あるため、第１の放送メディアの受信後、他の放送メデ
ィアの受信を待つまでもなく、直ちに第１の放送メディ
アを再生することが可能となる。

【０３６０】また、本発明によれば、基本的に、ヘッダ
圧縮処理を行った放送メディア（再生するために他の放
送メディアを参照することが必要な放送メディア）を受
信端末２０に中継するため、オーバーヘッドを削減する
ことが可能となる。

【０３６１】また、本発明によれば、放送通知情報（Ｓ
ＡＰメッセージ又はＨ.２４５メッセージ）を受信した
後に最初に受信した少なくとも１つの放送メディアを、
他の放送メディアを参照することなく再生可能な放送メ
ディア（ヘッダ圧縮リフレッシュパケット）とするた
め、放送メディアの放送の途中から視聴を始めた受信端
末２０であっても、当該放送メディアを素早く再生する
ことを可能となる。

【０３６２】また、本発明によれば、中継装置３０は、
放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセ
ージ）の送信後に最初に送信するものである旨を示す識
別情報に関連付けられた（「ＴＯＣフィールド」が「０
ｘＦＦ」と設定された）放送メディアを、他の放送メデ
ィアを参照することなく再生可能な放送メディア（ヘッ
ダ圧縮リフレッシュパケット）とするため、放送メディ
アの放送の途中から視聴を始めた受信端末２０であって
も、放送メディアを再生することを可能となる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係る放送通信システムの
概略構成図である。

【図２】本発明の一実施形態に係る放送通信方式のシー
ケンス図である。

【図３】本発明の一実施形態に係る放送通信システムで
用いられるＳＡＰメッセージを示す図である。

【図４】本発明の一実施形態に係る放送通信システムで
用いられるＳＡＰメッセージ内のＳＤＰ情報を示す図で
ある。

【図５】本発明の一実施形態に係る放送通信システムで
用いられるデータカルーセル方式を用いたデータ伝送方
式を説明するための図である。

【図６】本発明の一実施形態に係る放送通信システムで
用いられるカルーセルデータパケット（ＤＩＩ）を示す
図である。

【図７】本発明の一実施形態に係る放送通信システムで
用いられるカルーセルデータパケット（ＤＤＢ）を示す
図である。

【図８】本発明の一実施形態に係る放送通信システムで
用いられるＳＭＩＬを示す図である。

【図９】本発明の一実施形態に係る放送通信システムで
用いられるテキスト情報の記述例を示す図である。

【図１０】本発明の一実施形態に係る放送通信システム
で用いられるアンカー情報の記述例を示す図である。

【図１１】本発明の一実施形態に係る通信端末における
放送メディアの表示イメージを示す図である。

【図１２】本発明の一実施形態に係る放送通信システム
で用いられるＳＡＰメッセージ内のＳＤＰを示す図であ
る。

【図１３】本発明の一実施形態に係る移動通信端末の機
能ブロック図である。

【図１４】本発明の一実施形態に係る移動通信端末の動
作を示すフローチャート図である。

【図１５】本発明の一実施形態に係る放送通信システム
で用いられるＳＡＰメッセージ内のＳＤＰを示す図であ
る。

【図１６】本発明の一実施形態に係る通信端末の機能ブ
ロック図である。

【図１７】本発明の一実施形態に係る通信端末の動作を
示すフローチャート図である。

【図１８】本発明の一実施形態に係る放送通信システム
で用いられるＳＭＩＬを示す図である。

【図１９】本発明の一実施形態に係る通信端末の機能ブ
ロック図である。

【図２０】本発明の一実施形態に係る放送通信方式のシ
ーケンス図である。

【図２１】本発明の一実施形態に係るサーバ装置の動作
を示すフローチャート図である。

【図２２】本発明の一実施形態に係るサーバ装置の動作
を示すフローチャート図である。

【図２３】本発明の一実施形態に係る放送通信方式のシ
ーケンス図である。

【図２４】本発明の一実施形態に係る中継装置の動作を
示すフローチャート図である。

【図２５】本発明の一実施形態に係るサーバ装置の動作
を示すフローチャート図である。

【図２６】本発明の一実施形態に係る中継装置の動作を
示すフローチャート図である。

【図２７】本発明の一実施形態に係る放送通信システム
において、複数の放送メディアを伝送する様子を示す図
である。

【図２８】本発明の一実施形態に係る放送通信システム
で用いられるＳＡＰメッセージ内のＳＤＰを示す図であ
る。

【図２９】本発明の一実施形態に係る放送通信システム
において、複数の放送メディアを伝送する様子を示す図
である。

【図３０】本発明の一実施形態に係る放送通信方式のシ
ーケンス図である。

【図３１】本発明の一実施形態に係る放送通信システム
で用いられるＨ.２２３多重化フレームの構成を示す図
である。

【図３２】本発明の一実施形態に係る通信端末の動作を
示すフローチャート図である。

【図３３】本発明の一実施形態に係る放送通信システム
で用いられるＳＭＩＬを示す図である。

【図３４】本発明の一実施形態に係る放送通信方式のシ
ーケンス図である。

【図３５】本発明の一実施形態に係る放送通信方式で用
いられるプロトコルスタックを示す図である。

【図３６】本発明の一実施形態に係る放送通信方式で用
いられるプロトコルスタックを示す図である。

【図３７】本発明の一実施形態に係る中継装置の動作を
示すフローチャート図である。

【図３８】本発明の一実施形態に係る放送通信システム
で用いられるＨ.２２３多重化フレームの構成を示す図
である。

【図３９】本発明の一実施形態に係る中継装置の動作を
示すフローチャート図である。

【図４０】本発明の一実施形態に係る放送通信システム
で用いられるＨ.２２３多重化フレームの構成を示す図
である。

【図４１】本発明の一実施形態に係る放送通信システム
で用いられるＳＡＰメッセージ内のＳＤＰを示す図であ
る。

【図４２】本発明の一実施形態に係る放送通信システム
で用いられるＳＭＩＬを示す図である。

【図４３】本発明の一実施形態に係る放送通信システム
で用いられるテキスト情報（ＨＴＭＬ）の記述例を示す
図である。

【図４４】本発明の一実施形態に係るサーバ装置、中継
装置、移動通信端末の機能を実行するためのプログラム
を記録するコンピュータ読み取り可能な記録媒体を示す
図である。

【図４５】従来技術に係る放送通信システムにおいて、
複数の放送メディアを伝送する様子を示す図である。

【図４６】従来技術に係る放送通信システムで用いられ
るＳＡＰメッセージ内のＳＤＰを示す図である。

【符号の説明】

１…放送通信システム ２…インターネット １０…コンテンツ送信サーバ ２０…受信端末 ２１…受信処理部 ２２…必須処理情報処理部 ２３…再生処理部 ２３ａ…放送メディア同期再生処理部 ２３ｂ…音声情報再生処理部 ２３ｃ…映像情報再生処理部 ２３ｄ…テキスト・静止画像情報再生処理部 ２３ｅ…必要条件判定処理部 ２４…出力部 ２４ａ…スピーカ ２４ｂ…ディスプレイ ２５…レイアウト情報判定処理部 ３０…中継装置 ４０…無線制御装置 ５０…基地局

───────────────────────────────────────────────────── フロントページの続き (72)発明者 栄藤 稔 東京都千代田区永田町二丁目11番１号 株 式会社エヌ・ティ・ティ・ドコモ内 (72)発明者 鈴木 敬 東京都千代田区永田町二丁目11番１号 株 式会社エヌ・ティ・ティ・ドコモ内 Ｆターム(参考） 5C063 AB03 AB05 AC01 AC10 CA23 CA36 CA40 DA07 DA13 5K030 HA08 HB01 HB02 JL01 LA07 LD07 5K101 KK18 LL12 MM07 NN18 SS07 TT06

Claims (73)

【特許請求の範囲】
1. 【請求項１】 受信した放送メディアを再生する通信端
   末であって、 前記放送メディアの再生に先立って、該放送メディアの
   再生方法を示す再生情報を取得し、 少なくとも一つの前記放送メディアを指定する放送通知
   情報を受信した場合、前記再生情報に基づいて、指定さ
   れた該放送メディアを再生することを特徴とする通信端
   末。
2. 【請求項２】 前記放送メディアの再生に先立って、前
   記再生情報に関連付けられた参照情報を取得し、前記参
   照情報を用いて前記再生情報を取得することを特徴とす
   る請求項１に記載の通信端末。
3. 【請求項３】 前記再生情報は、前記放送メディアの再
   生の際に用いられるレイアウト情報を含むことを特徴と
   する請求項１に記載の通信端末。
4. 【請求項４】 前記再生情報は、前記放送メディアの再
   生の際に用いられるタイミング情報を含むことを特徴と
   する請求項１に記載の通信端末。
5. 【請求項５】 前記放送メディアの再生に先立って、必
   ず行うべき必須処理を示す必須処理情報を受信した場合
   に、前記必須処理を行った後で該放送メディアを再生す
   ることを特徴とする請求項１に記載の通信端末。
6. 【請求項６】 前記必須処理情報は、前記放送通知情報
   に含まれていることを特徴とする請求項５に記載の通信
   端末。
7. 【請求項７】 前記必須処理情報は、前記放送メディア
   の再生と同時に行うべき処理内容を示すものであり、 前記放送メディアの再生と同時に前記必須処理を行うこ
   とを特徴とする請求項５に記載の通信端末。
8. 【請求項８】 無線チャネルを介して受信した前記放送
   メディアを再生する通信端末であって、 前記放送通知情報に、前記放送メディアが送信される物
   理チャネル識別情報と論理チャネル識別情報との対応情
   報とが含まれている場合に、該対応情報に基づいて、該
   放送メディアを再生することを特徴とする請求項１に記
   載の通信端末。
9. 【請求項９】 前記論理チャネル識別情報は、ＩＰアド
   レスであることを特徴とする請求項８に記載の通信端
   末。
10. 【請求項１０】 前記物理チャネル識別情報は、ＣＤＭ
    Ａ通信方式のチャネライゼーションコードであることを
    特徴とする請求項８に記載の通信端末。
11. 【請求項１１】 前記物理チャネル識別情報は、周波数
    値であることを特徴とする請求項８に記載の通信端末。
12. 【請求項１２】 前記放送通知情報は、前記放送メディ
    アを識別する放送メディア識別情報を含んでおり、 前記メディア識別情報を用いて、前記再生情報を取得す
    ることを特徴とする請求項１に記載の通信端末。
13. 【請求項１３】 放送メディアを通信端末に配信するサ
    ーバ装置であって、少なくとも一つの放送メディアを指
    定する放送通知情報を送信し、前記通信端末による前記
    放送メディアの再生に先立って、該放送通知情報によっ
    て指定された前記放送メディアの再生方法を示す再生情
    報を送信することを特徴とするサーバ装置。
14. 【請求項１４】 前記通信端末による前記放送メディア
    の再生に先立って、前記再生情報に関連付けられた参照
    情報を送信することを特徴とする請求項１３に記載のサ
    ーバ装置。
15. 【請求項１５】 前記放送通知情報を周期的に繰り返し
    送信し、 前記放送通知情報を送信した直後に、カルーセルデータ
    によって前記再生情報を送信することを特徴とする請求
    項１３に記載のサーバ装置。
16. 【請求項１６】 前記放送通知情報は、前記カルーセル
    データによって前記再生情報を送信することを示すこと
    を特徴とする請求項１４に記載のサーバ装置。
17. 【請求項１７】 前記再生情報は、前記放送メディアの
    再生の際に用いられるレイアウト情報を含むことを特徴
    とする請求項１３に記載のサーバ装置。
18. 【請求項１８】 前記再生情報は、前記放送メディアの
    再生の際に用いられるタイミング情報を含むことを特徴
    とする請求項１３に記載のサーバ装置。
19. 【請求項１９】 前記通信端末による前記放送メディア
    の再生に先立って、該通信端末が必ず行うべき必須処理
    を示す必須処理情報を送信することを特徴とする請求項
    １３に記載のサーバ装置。
20. 【請求項２０】 前記必須処理情報は、前記放送通知情
    報に含まれていることを特徴とする請求項１９に記載の
    サーバ装置。
21. 【請求項２１】 前記必須処理情報は、前記通信端末に
    よって前記放送メディアの再生と同時に行われるべき処
    理内容を示すものであることを特徴とする請求項１９に
    記載のサーバ装置。
22. 【請求項２２】 無線チャネルを介して前記放送メディ
    アを配信するサーバ装置であって、 前記放送通知情報によって、前記放送メディアが配信さ
    れる物理チャネル識別情報と論理チャネル識別情報との
    対応情報を送信することを特徴とする請求項１３に記載
    のサーバ装置。
23. 【請求項２３】 前記論理チャネル識別情報は、ＩＰア
    ドレスであることを特徴とする請求項２２に記載のサー
    バ装置。
24. 【請求項２４】 前記物理チャネル識別情報は、ＣＤＭ
    Ａ通信方式のチャネライゼーションコードであることを
    特徴とする請求項２２に記載のサーバ装置。
25. 【請求項２５】 前記物理チャネル識別情報は、周波数
    値であることを特徴とする請求項２２に記載のサーバ装
    置。
26. 【請求項２６】 前記放送通知情報の送信後、最初に、
    他の放送メディアを参照することなく再生可能な形式
    で、前記放送メディアを送信することを特徴とする請求
    項１３に記載のサーバ装置。
27. 【請求項２７】 前記放送通知情報の送信後、最初に、
    予測符号化を行うことなく再生可能な形式で、前記放送
    メディアを送信することを特徴とする請求項１３に記載
    のサーバ装置。
28. 【請求項２８】 前記放送通知情報の送信後に最初に送
    信する前記放送メディアとその旨を示す識別情報とを関
    連付けて送信することを特徴とする請求項１３に記載の
    サーバ装置。
29. 【請求項２９】 前記放送メディアを識別する放送メデ
    ィア識別情報を含む前記放送通知情報を送信し、 前記メディア識別情報と前記再生情報とを関連付けて送
    信することを特徴とする請求項１３に記載のサーバ装
    置。
30. 【請求項３０】 サーバ装置から送信された放送メディ
    アを、通信端末に中継する中継装置であって、 前記サーバ装置によって放送通知情報が送信された後に
    最初に送信された少なくとも１つの放送メディアを、他
    の放送メディアを参照することなく再生可能な形式で前
    記通信端末に中継することを特徴とする中継装置。
31. 【請求項３１】 サーバ装置から送信された放送メディ
    アを、通信端末に中継する中継装置であって、 前記サーバ装置から受信した前記放送メディアに、該放
    送メディアが放送通知情報の送信後に最初に送信するも
    のである旨を示す識別情報が関連付けられている場合
    に、他の放送メディアを参照することなく再生可能な形
    式で、該放送メディアを前記通信端末に中継することを
    特徴とする中継装置。
32. 【請求項３２】 サーバ装置から送信された放送メディ
    アを、通信端末に中継する中継装置であって、 前記サーバ装置から受信した前記放送メディアに、該放
    送メディアが放送通知情報の送信後に最初に送信するも
    のである旨を示す識別情報が関連付けられている場合
    に、予測符号化を行うことなく再生可能な形式で、該放
    送メディアを前記通信端末に中継することを特徴とする
    中継装置。
33. 【請求項３３】 サーバ装置から通信端末に放送メディ
    アを送信する放送通信システムであって、 前記サーバ装置は、少なくとも一つの放送メディアを指
    定する放送通知情報を送信し、前記通信端末による放送
    メディアの再生に先立って、前記放送通知情報によって
    指定された前記放送メディアの再生方法を示す再生情報
    を送信し、 前記通信端末は、前記放送通知情報を受信した場合に、
    前記再生情報に基づいて、該放送通知情報によって指定
    された前記放送メディアを再生することを特徴とする放
    送通信システム。
34. 【請求項３４】 前記サーバ装置は、前記通信端末によ
    る前記放送メディアの再生に先立って、前記再生情報に
    関連付けられた参照情報を送信し、 前記通信端末は、前記参照情報を用いて前記再生情報を
    取得することを特徴とする請求項３３に記載の放送通信
    システム。
35. 【請求項３５】 前記サーバ装置は、前記通信端末によ
    る前記放送メディアの再生に先立って、該通信端末が必
    ず行うべき必須処理を示す必須処理情報を送信し、 前記通信端末は、前記必須処理を行った後で前記放送メ
    ディアを再生することを特徴とする請求項３３に記載の
    放送通信システム。
36. 【請求項３６】 前記必須処理情報は、前記放送通知情
    報に含まれていることを特徴とする請求項３５に記載の
    放送通信システム。
37. 【請求項３７】 前記必須処理情報は、前記通信端末に
    よって前記放送メディアの再生と同時に行われるべき処
    理内容を示すものであり、 前記通信端末は、前記放送メディアの再生と同時に前記
    必須処理を行うことを特徴とする請求項３５に記載の放
    送通信システム。
38. 【請求項３８】 無線チャネルを介して前記サーバ装置
    から前記通信端末に前記放送メディアを送信する放送通
    信システムであって、 前記サーバ装置は、前記放送通知情報によって、前記放
    送メディアが送信される物理チャネル識別情報と論理チ
    ャネル識別情報との対応情報を送信し、 前記通信端末は、前記対応情報に基づいて前記放送メデ
    ィアを再生することを特徴とする請求項３３に記載の放
    送通信システム。
39. 【請求項３９】 前記サーバ装置は、前記放送通知情報
    を周期的に繰り返し送信し、前記放送通知情報を送信し
    た直後に、カルーセルデータによって、前記再生情報を
    送信することを特徴とする請求項３３に記載の放送通信
    システム。
40. 【請求項４０】 前記サーバ装置は、前記放送通知情報
    の送信後、最初に、他の放送メディアを参照することな
    く再生可能な形式で、前記放送メディアを前記通信端末
    に送信することを特徴とする請求項３３に記載の放送通
    信システム。
41. 【請求項４１】 前記サーバ装置は、前記放送通知情報
    の送信後、最初に、予測符号化を行うことなく再生可能
    な形式で、前記放送メディアを前記通信端末に送信する
    ことを特徴とする請求項３３に記載の放送通信システ
    ム。
42. 【請求項４２】 前記サーバ装置は、前記放送メディア
    を識別する放送メディア識別情報を含む前記放送通知情
    報を送信し、 前記通信端末は、前記放送メディア識別情報を用いて前
    記再生情報を取得することを特徴とする請求項３３に記
    載の放送通信システム。
43. 【請求項４３】 中継装置がサーバ装置からの放送メデ
    ィアを通信端末に中継する放送通信システムであって、 前記中継装置は、前記サーバ装置によって放送通知情報
    が送信された後に最初に送信された少なくとも１つの放
    送メディアを、他の放送メディアを参照することなく再
    生可能な形式で、前記通信端末に中継することを特徴と
    する放送通信システム。
44. 【請求項４４】 中継装置がサーバ装置からの放送メデ
    ィアを通信端末に中継する放送通信システムであって、 前記サーバ装置は、放送通知情報の送信後に最初に送信
    するものであるか否かを示す識別情報を前記放送メディ
    アに関連付けて送信し、 前記中継装置は、前記識別情報に関連付けられた前記放
    送メディアを受信した場合に、他の放送メディアを参照
    することなく再生可能な形式で、該放送メディアを前記
    通信端末に中継することを特徴とする放送通信システ
    ム。
45. 【請求項４５】 中継装置がサーバ装置からの放送メデ
    ィアを通信端末に中継する放送通信システムであって、 前記サーバ装置は、放送通知情報の送信後に最初に送信
    するものであるか否かを示す識別情報を前記放送メディ
    アに関連付けて送信し、 前記中継装置は、前記識別情報に関連付けられた前記放
    送メディアを受信した場合に、予測符号化を行うことな
    く再生可能な形式で、該放送メディアを前記通信端末に
    中継することを特徴とする放送通信システム。
46. 【請求項４６】 サーバ装置から通信端末に放送メディ
    アを送信する放送通信方法であって、 前記サーバ装置において、少なくとも一つの放送メディ
    アを指定する放送通知情報を送信し、前記通信端末によ
    る放送メディアの再生に先立って、前記放送通知情報に
    よって指定された前記放送メディアの再生方法を示す再
    生情報を送信し、 前記通信端末において、前記放送通知情報を受信した場
    合に、前記再生情報に基づいて、該放送通知情報によっ
    て指定された前記放送メディアを再生することを特徴と
    する放送通信方法。
47. 【請求項４７】 前記サーバ装置において、前記通信端
    末による放送メディアの再生に先立って、前記再生情報
    に関連付けられた参照情報を送信し、 前記通信端末において、前記参照情報を用いて前記再生
    情報を取得することを特徴とする請求項４６に記載の放
    送通信方法。
48. 【請求項４８】 前記サーバ装置において、前記通信端
    末による放送メディアの再生に先立って、該通信端末が
    必ず行うべき必須処理を示す必須処理情報を送信し、 前記通信端末において、前記必須処理を行った後で前記
    放送メディアを再生することを特徴とする請求項４６に
    記載の放送通信方法。
49. 【請求項４９】 前記必須処理情報は、前記放送通知情
    報に含まれていることを特徴とする請求項４８に記載の
    放送通信方法。
50. 【請求項５０】 前記必須処理情報は、前記通信端末に
    よって前記放送メディアの再生と同時に行われるべき処
    理内容を示すものであり、 前記通信端末において、前記放送メディアの再生と同時
    に前記必須処理を行うことを特徴とする請求項４８に記
    載の放送通信方法。
51. 【請求項５１】 無線チャネルを介してサーバ装置から
    通信端末に放送メディアを送信する放送通信方法であっ
    て、 前記サーバ装置において、前記放送通知情報によって、
    前記放送メディアが送信される物理チャネル識別情報と
    論理チャネル識別情報との対応情報を送信し、 前記通信端末において、前記対応情報に基づいて前記放
    送メディアを再生することを特徴とする請求項４６に記
    載の放送通信方法。
52. 【請求項５２】 前記サーバ装置において、前記放送通
    知情報を周期的に繰り返し送信し、前記放送通知情報を
    送信した直後に、カルーセルデータによって、前記再生
    情報を送信することを特徴とする請求項４６に記載の放
    送通信方法。
53. 【請求項５３】 前記サーバ装置において、前記放送通
    知情報の送信後、最初に、他の放送メディアを参照する
    ことなく再生可能な形式で、前記放送メディアを前記通
    信端末に送信することを特徴とする請求項４６に記載の
    放送通信方法。
54. 【請求項５４】 前記サーバ装置において、前記放送通
    知情報の送信後、最初に、予測符号化を行うことなく再
    生可能な形式で、前記放送メディアを前記通信端末に送
    信することを特徴とする請求項４６に記載の放送通信方
    法。
55. 【請求項５５】 前記サーバ装置は、前記放送メディア
    を識別する放送メディア識別情報を含む前記放送通知情
    報を送信し、 前記通信端末は、前記放送メディア識別情報を用いて前
    記再生情報を取得することを特徴とする請求項４６に記
    載の放送通信方法。
56. 【請求項５６】 中継装置がサーバ装置からの放送メデ
    ィアを通信端末に中継する放送通信方法であって、 前記中継装置において、前記サーバ装置によって放送通
    知情報が送信された後に最初に送信された少なくとも１
    つの放送メディアを、他の放送メディアを参照すること
    なく再生可能な形式で、前記通信端末に中継することを
    特徴とする放送通信方法。
57. 【請求項５７】 中継装置がサーバ装置からの放送メデ
    ィアを通信端末に中継する放送通信方法であって、 前記サーバ装置において、放送通知情報の送信後に最初
    に送信するものであるか否かを示す識別情報を前記放送
    メディアに関連付けて送信し、 前記中継装置において、前記識別情報に関連付けられた
    前記放送メディアを受信した場合に、他の放送メディア
    を参照することなく再生可能な形式で、該放送メディア
    を前記通信端末に中継することを特徴とする放送通信方
    法。
58. 【請求項５８】 中継装置がサーバ装置からの放送メデ
    ィアを通信端末に中継する放送通信方法であって、 前記サーバ装置において、放送通知情報の送信後に最初
    に送信するものであるか否かを示す識別情報を前記放送
    メディアに関連付けて送信し、 前記中継装置において、前記識別情報に関連付けられた
    前記放送メディアを受信した場合に、予測符号化を行う
    ことなく再生可能な形式で、該放送メディアを前記通信
    端末に中継することを特徴とする放送通信方法。
59. 【請求項５９】 受信した放送メディアを再生する通信
    端末を、 前記放送メディアの再生に先立って、該放送メディアの
    再生方法を示す再生情報を取得し、 少なくとも一つの前記放送メディアを指定する放送通知
    情報を受信した場合、前記再生情報に基づいて、指定さ
    れた該放送メディアを再生するように機能させることを
    特徴とするプログラム。
60. 【請求項６０】 前記通信端末を、 前記放送メディアの再生に先立って、前記再生情報に関
    連付けられた参照情報を取得し、 前記参照情報を用いて前記再生情報を取得するように機
    能させることを特徴とする請求項５９に記載のプログラ
    ム。
61. 【請求項６１】 前記通信端末を、 前記放送メディアの再生に先立って、必ず行うべき必須
    処理を示す必須処理情報を受信した場合に、前記必須処
    理を行った後で該放送メディアを再生するように機能さ
    せることを特徴とする請求項５９に記載のプログラム。
62. 【請求項６２】 前記必須処理情報は、前記放送通知情
    報に含まれていることを特徴とする請求項５９に記載の
    プログラム。
63. 【請求項６３】 前記通信端末を、 前記放送通知情報に、前記放送メディアが送信される物
    理チャネル識別情報と論理チャネル識別情報との対応情
    報とが含まれている場合に、該対応情報に基づいて、該
    放送メディアを再生するように機能させることを特徴と
    する請求項５９に記載のプログラム。
64. 【請求項６４】 前記放送通知情報は、前記放送メディ
    アを識別する放送メディア識別情報を含んでおり、 前記通信端末を、前記メディア識別情報を用いて、前記
    再生情報を取得するように機能させることを特徴とする
    請求項５９に記載のプログラム。
65. 【請求項６５】 放送メディアを通信端末に配信するサ
    ーバ装置を、 少なくとも一つの放送メディアを指定する放送通知情報
    を送信し、前記通信端末による前記放送メディアの再生
    に先立って、該放送通知情報によって指定された前記放
    送メディアの再生方法を示す再生情報を送信するように
    機能させることを特徴とするプログラム。
66. 【請求項６６】 前記サーバ装置を、 前記通信端末による前記放送メディアの再生に先立っ
    て、前記再生情報に関連付けられた参照情報を送信する
    ように機能させることを特徴とする請求項６５に記載の
    プログラム。
67. 【請求項６７】 前記サーバ装置を、 前記放送通知情報を周期的に繰り返し送信し、前記放送
    通知情報を送信した直後に、カルーセルデータによっ
    て、前記再生情報を送信することを特徴とする請求項６
    ５に記載のプログラム。
68. 【請求項６８】 前記サーバ装置を、 前記通信端末による前記放送メディアの再生に先立っ
    て、該通信端末が必ず行うべき必須処理を示す必須処理
    情報を送信するように機能させることを特徴とする請求
    項６５に記載のプログラム。
69. 【請求項６９】 前記必須処理情報は、前記放送通知情
    報に含まれていることを特徴とする請求項６５に記載の
    プログラム。
70. 【請求項７０】 前記サーバ装置を、 前記放送通知情報の送信後、最初に、他の放送メディア
    を参照することなく再生可能な形式で、前記放送メディ
    アを前記通信端末に送信するように機能させることを特
    徴とする請求項６５に記載のプログラム。
71. 【請求項７１】 前記サーバ装置を、 前記放送通知情報の送信後、最初に、予測符号化を行う
    ことなく再生可能な形式で、前記放送メディアを前記通
    信端末に送信するように機能させることを特徴とする請
    求項６５に記載のプログラム。
72. 【請求項７２】 前記サーバ装置を、 前記放送通知情報の送信後に最初に送信する前記放送メ
    ディアとその旨を示す識別情報とを関連付けて送信する
    ように機能させることを特徴とする請求項６５に記載の
    プログラム。
73. 【請求項７３】 前記サーバ装置を、 前記放送メディアを識別する放送メディア識別情報を含
    む前記放送通知情報を送信し、 前記メディア識別情報と前記再生情報とを関連付けて送
    信するように機能させることを特徴とする請求項６５に
    記載のプログラム。