JP2012515496A - 放送システムにおいてリッチメディアを利用したサービスガイド提供方法及びシステム - Google Patents

Abstract

リッチメディアを利用したサービスガイドを配布するためのサービスガイド提供方法及びシステムが提供される。デジタル放送サービスのためのリッチメディアを利用したサービスガイド提供方法は、サービスガイドフラグメント情報を参照してサービスガイドのためのリッチメディアソリューション（ＲＭＳ；Ｒｉｃｈ Ｍｅｄｉａ Ｓｏｌｕｔｉｏｎ）テンプレートを生成する段階と；サービスガイドフラグメントにサービスガイドフラグメント情報を含むサービスガイド伝送記述子を生成する段階と；サービスガイドフラグメント、ＲＭＳテンプレート及びサービスガイド伝送記述子をブロードキャストする段階と；を含む。

Description

本発明は、デジタル放送サービスに関し、特に、リッチメディアを利用したサービスガイドの配布が可能なデジタル放送サービスのためのサービスガイド提供方法及びシステムに関する。

一般的に、放送サービスは、端末を有するすべてのユーザに提供されることを目的としたサービスである。このような放送サービスは、音声のみを提供するラジオ放送のようなオーディオ放送サービスと、音声及びビデオサービスを提供するテレビのような映像中心の放送サービスと、音声、ビデオ及びデータサービスを包括するマルチメディア放送サービスとに分けられる。このような放送サービスは、アナログ方式を基本にしており、技術の飛躍的な発展に伴い、デジタル放送化が行われている。また、放送サービスは、有線で高画質及び高速のデータを一緒に提供する有線ネットワークのマルチメディアサービスと、人工衛星または無線ネットワークを利用してマルチメディアサービスを提供する方式と、有線、無線ネットワーク及び人工衛星を同時に利用する方式などの多様な方式に発展している。

また、移動通信市場は、既存技術の組み替えまたは統合を通じて新しいサービスを創出する必要に迫られており、近年、通信及び放送技術の発達に伴い、従来の放送システムまたは移動通信システムにおいて 携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）など携帯端末（以下、“移動端末”という）を通じて放送サービスを提供する段階にある。このような潜在的で且つ実在的な市場需要とマルチメディアサービスに対して急増するユーザ要求、既存の音声サービス以外に放送サービスなど新しいサービスを提供しようとする事業者の戦略、そして需要者の要求に応じて移動通信事業を強化しているＩＴ企業らの利害関係がからみ合って、移動通信サービスとＩＰの融合は、次世代移動通信技術開発の大きい流れとして位置付けられている。これは、移動通信市場だけでなく、一般有線市場においても無線または放送などに存在する多様なサービスを導入、適用させるに至り、このような全方位的な融合は、有線、無線放送などに関係なく、多様なサービスに対して同一の消費環境を作るようになった。

一方、オープンモバイルアライアンス（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ、ＯＭＡ）は、個別モバイルソリューションの相互連動のための標準を研究する団体であって、移動通信用ゲーム、インターネットサービスなどに対する多様なアプリケーション標準を決定する役目を主に果たしている。特に、上記ＯＭＡのワーキンググループのうちＯＭＡ ＢＣＡＳＴ（Ｍｏｂｉｌｅ Ｂｒｏａｄｃａｓｔ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ）では、移動端末を利用して放送サービスを提供する技術標準を策定している。ＯＭＡ ＢＣＡＳＴは、サービスガイド、ダウンロード及びストリーミング伝送技術、サービス及びコンテンツ保護技術、サービス加入、ローミングなど携帯端末環境でＩＰ基盤の放送サービスを提供するための技術を標準化している。

上記説明した有線無線環境の融合による統合サービス提供の市場流れに伴い、ＯＭＡ ＢＣＡＳＴなど携帯放送技術もモバイル環境を越えて有線無線統合環境でサービスを提供することができるように進化する。
上述された既存の携帯放送システムでは、特定の放送送出システムを通じて受信するように設計された端末のみのために、サービスガイドを設定し、サービス受信のための情報を提供する。

このような携帯放送システムでは、サービスガイドの情報は定義するが、表示方法は定義していないため、表示形式は各端末の実装に委ねられている。すなわち、事業者が提供するすべてのサービスに対する開始点であるサービスガイドの表示が、各製造メーカ別に、または各モデル別に異なることがあるので、事業者は、ユーザに一様なサービスアクセシビリティを提供することができなかった。このような問題を克服するために、端末画面上の表示を多様に定義することができるようにするリッチメディア（ｒｉｃｈ ｍｅｄｉａ）技術が存在し、ＭＰＥＧ ＬＡＳｅＲ、３ＧＰＰ ＤＩＭＳ及びＯＭＡ ＲＭＥが代表的な統合ソリューションである。しかし、サービスガイドにリッチメディア技術を適用する場合、すべての端末にリッチメディア技術が搭載されなければならない互換性に対する問題が発生するので、リッチメディアを選択的に適用できる方法が要求される。

本発明は、前述のような従来の要求に鑑みてなされたもので、その目的は、リッチメディアを利用してサービスガイドを提供する方法及びそのためのシステムを提供することにある。

本発明の他の目的は、互換性に問題がないようにリッチメディアを提供するためのテンプレートを別に提供し、リッチメディアによるサービスガイドを提供する方法及びそのためのシステムを提供することにある。

上記目的を達成するために、本発明の好ましい実施形態によるデジタル放送システムにおいてリッチメディアを利用したサービスガイド提供方法は、サービスガイドフラグメントを構成し、構成したサービスガイドフラグメントを参照してサービスガイドを生成するＲＭＳテンプレートを生成する過程と、前記ＲＭＳテンプレートに対する情報であるＲＭＳ情報及びサービスガイドフラグメントに対する情報を含むサービスガイド伝送記述子を生成する過程と、前記サービスガイドフラグメント、前記ＲＭＳテンプレート及びサービスガイド伝送記述子をブロードキャストする過程とを含む。

本発明の好ましい実施形態によるデジタル放送システムにおいてリッチメディアを利用したサービスガイド提供方法は、サービスガイド伝送記述子を受信する過程と、前記サービスガイド伝送記述子のサービスガイドフラグメントに対する情報を参照してサービスガイドフラグメントを抽出する過程と、前記サービスガイド伝送記述子のＲＭＳ情報を参照してＲＭＳテンプレートを受信する過程と、前記ＲＭＳテンプレートを利用してサービスガイドフラグメントからサービスガイドを抽出して出力する過程とを含む。
本発明の好ましい実施形態によるデジタル放送システムにおいてリッチメディアを利用したサービスガイド提供のためのシステムは、サービスガイドフラグメント、ＲＭＳテンプレート、サービスガイドフラグメントに対する情報及び前記ＲＭＳテンプレートに対する情報を有するサービスガイド伝送記述子を伝送する放送サービス配信／調整部と；前記サービスガイド伝送記述子のサービスガイドフラグメントに対する情報を参照してサービスガイドフラグメントを抽出し、前記サービスガイド伝送記述子のＲＭＳ情報を参照してＲＭＳテンプレートを受信し、前記ＲＭＳテンプレートを利用してサービスガイドフラグメントからサービスガイドを抽出して出力する端末と；を含む。

本発明によれば、ＲＭＳテンプレートを利用してサービスガイドを提供することによって、互いに異なる端末に事業者が意図するサービスを提供することができる。また、リッチメディアをサポートしない端末に対する互換性の問題を解決することができる。

本発明の実施形態によるデジタル放送通信システムの構成を説明するための図である。 本発明の実施形態によるサービスガイド生成のためのデータモデルを説明するための図である。 本発明の実施形態による端末のサービスガイド受信方法を説明するための図である。 本発明の実施形態によるＲＭＳ伝送方法を説明するための図である。 本発明の実施形態による端末のＲＭＳテンプレート受信方法を説明するための図である。 本発明の実施形態による端末の構成を説明するための図である。 リッチメディアに基盤したサービスガイドデータモデルを示すブロック構成図である。

以下、本発明の好ましい実施形態を、添付の図面を参照して詳細に説明する。図面において、同一の構成は、できるだけ同一の符号を示していることを留意しなければならない。

また、下記説明では、具体的な特定事項が示されているが、これは、本発明のより全般的な理解を助けるために提供されたものに過ぎず、このような特定事項無しに本発明が実施され得ることは、この技術分野における通常の知識を有する者に自明であろう。また、本発明を説明するにあたって、関連された公知の機能あるいは構成に対する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、詳細な説明を省略する。
後述する詳細な説明には、前述した目的を達成するための本発明の代表的な実施形態を提示する。また、本発明の説明の便宜のために、非同期移動通信の標準化団体である３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）あるいは移動端末のアプリケーションの標準化団体であるＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）のＢＣＡＳＴで定義している用語と同一の名称を使用するが、このような標準及び名称が本発明の範囲を限定するものではなく、類似の技術的背景を有するシステムに適用可能であることは勿論である。

まず、本発明の実施形態によるデジタル放送ネットワークについて説明する。特に、本発明の説明において、具体例として携帯放送技術標準の１つであるＯＭＡ ＢＣＡＳＴ技術を利用して説明するが、このような説明が本発明の内容を限定するわけではない。

図１は、本発明の実施形態によるデジタル放送通信システムの構成を説明するための図である。
まず、図１に示された論理要素を説明する。ＯＭＡ ＢＣＡＳＴサービスガイド機能の論理構成は、コンテンツ制作者（ＣＣ、Ｃｏｎｔｅｎｔ Ｃｒｅａｔｉｏｎ）１０１、放送サービスアプリケーション（ＢＣＡＳＴ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ）１０２、放送サービス配信／調整部（ＢＣＡＳＴ Ｓｅｒｖｉｃｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ／Ａｄａｐｔａｔｉｏｎ、以下、”ＢＳＤＡ”という）１０３、放送加入管理部（ＢＣＡＳＴ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）１０４、端末（Ｔｅｒｍｉｎａｌ）１０５、ＢＤＳサービス配信部（ＢＤＳ Ｓｅｒｖｉｃｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ）１１１、放送配信システム（Ｂｒｏａｄｃａｓｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）１１２及び連動ネットワーク（Ｉｎｔｅｒａｃｔｉｏｎ Ｎｅｔｗｏｒｋ）１１３を含む。

コンテンツ制作者（Ｃｏｎｔｅｎｔ Ｃｒｅａｔｉｏｎ：ＣＣ）１０１は、ＢＣＡＳＴサービスの基礎となるコンテンツを供給し、このようなコンテンツは、例えば、映画データ、オーディオデータ、ビデオデータのような、一般的な放送サービスのためのファイルである。また、前記コンテンツ制作者１０１は、サービスガイド生成及び前記サービスが伝送される伝送ベアラーを決定するためのコンテンツに対する属性（Ａｔｔｒｉｂｕｔｅ）を放送サービスアプリケーション（ＢＣＡＳＴ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ）１０２に提供する。

放送サービスアプリケーション１０２は、前記コンテンツ制作者１０１から放送（ＢＣＡＳＴ）サービスのデータを供給され、これを利用してメディアエンコード、コンテンツ保護、双方向サービスなどを提供するのに適した形態に加工する。また、前記コンテンツ制作者１０１から供給された前記コンテンツに対する属性を放送サービス配信／調整部１０３と放送加入管理部１０４に提供する。

放送サービス配信／調整部１０３は、放送サービスアプリケーション１０２から供給された放送（ＢＣＡＳＴ）サービスデータを利用してファイル及びストリーミング伝送、サービス収集、サービス保護、サービスガイド生成及び伝送、サービス通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）のような作業を行う。また、放送サービス配信／調整部１０３は、サービスを放送配信システム（Ｂｒｏａｄｃａｓｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）１１２に適合するように調整する。

特に、本発明の実施形態による放送サービス配信／調整部１０３は、ＲＭＳ（Ｒｉｃｈ Ｍｅｄｉａ Ｓｏｌｕｔｉｏｎ）テンプレートを生成し、生成したＲＭＳテンプレートの情報及びＲＭＳテンプレートを端末１０５に伝送する。

放送加入管理部１０４は、放送（ＢＣＡＳＴ）サービスユーザの加入及び課金機能のようなサービスプロビジョニング、放送サービスに使用される情報プロビジョニング、及び、放送サービスを提供される端末１０５を、ハードウェアまたはソフトウェアを通じて、管理する。
端末（Ｔｅｒｍｉｎａｌ）１０５は、コンテンツ及びサービスガイドと、コンテンツ保護などの番組サポート情報を受信し、ユーザに放送サービスを提供する。特に、本発明の実施形態による端末１０５は、ＲＭＳ情報を受信し、ＲＭＳ情報によってＲＭＳテンプレートを受信することができる。また、端末１０５は、サービスガイドを受信し、ＲＭＳテンプレートを利用して受信したサービスガイドを出力する。

ＢＤＳサービス配信部（ＢＤＳ Ｓｅｒｖｉｃｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ）１１１は、前記放送配信システム１１２及び連動ネットワーク（Ｉｎｔｅｒａｃｔｉｏｎ Ｎｅｔｗｏｒｋ）１１３と相互通信を通じて携帯放送サービスを多数の端末に伝送する。
放送配信システム１１２は、放送チャネルを通じた携帯放送サービスを伝送し、例えば、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐｒｏｊｅｃｔ Ｐａｒｔｎｅｒｓｈｉｐ）のＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）、３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐｒｏｊｅｃｔ Ｐａｒｔｎｅｒｓｈｉｐ ２）のＢＣＭＣＳ（Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）、デジタル放送標準化団体であるＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）のＤＶＢ−Ｈ（ＤＶＢ−Ｈａｎｄｈｅｌｄ）またはＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）基盤の放送／通信ネットワークなどを含む。連動ネットワーク１１３は、双方向チャネルを提供し、例えば、セルラネットワークなどを含む。

次に、前記論理要素間の連結通路である参照ポイント（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）を説明する。参照ポイントは、目的によって多数のインターフェースを有し、このようなインターフェースは、所定の目的のために２個以上の論理要素間の通信のために使用される。当該インターフェースには、この通信のためのメッセージ形式とプロトコルなどが適用される。

ＢＣＡＳＴ−１ １２１は、コンテンツ及びコンテンツ属性の伝送路であり、ＢＣＡＳＴ−２ １２２は、コンテンツ保護（Ｃｏｎｔｅｎｔ−ｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービスか、コンテンツ非保護（Ｃｏｎｔｅｎｔ−ｕｎｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービスのいずれかと前記放送サービスの属性及びコンテンツ属性の伝送路である。

ＢＣＡＳＴ−３ １２３は、放送（ＢＣＡＳＴ）サービスの属性、コンテンツ属性、ユーザ嗜好（Ｕｓｅｒ ｐｒｅｆｅｒｅｎｃｅ）及び加入（Ｓｕｂｓｃｒｉｐｔｉｏｎ）情報、ユーザ要求、前記要求に対する応答の伝送路である。ＢＣＡＳＴ−４ １２４は、通知メッセージ（Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ）、サービスガイドに使用される属性、コンテンツ保護（Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）及びサービス保護（Ｓｅｒｖｉｃｅ Ｐｒｏｔｅｃｔｉｏｎ）に使用されるキー（Ｋｅｙ）の伝送路である。

ＢＣＡＳＴ−５ １２５は、保護された（Ｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、保護されない（Ｕｎｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、コンテンツが保護された（Ｃｏｎｔｅｎｔ−ｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、コンテンツが保護されない（Ｃｏｎｔｅｎｔ−ｕｎｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、放送（ＢＣＡＳＴ）サービス属性、コンテンツ属性、通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）、サービスガイド、放送（ＢＣＡＳＴ）サービスの保護（ｐｒｏｔｅｃｔｉｏｎ）に使用されるＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）ＲＯ（Ｒｉｇｈｔｓ Ｏｂｊｅｃｔ）及びキー値などのセキュリティ要素（Ｓｅｃｕｒｉｔｙ ｍａｔｅｒｉａｌ）、放送（Ｂｒｏａｄｃａｓｔ）チャネルを通じて伝送されるすべてのデータ及びシグナリングの伝送路である。

ＢＣＡＳＴ−６ １２６は、保護された（Ｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、保護されない（Ｕｎｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、コンテンツが保護された（Ｃｏｎｔｅｎｔ−ｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、コンテンツが保護されない（Ｃｏｎｔｅｎｔ−ｕｎｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、放送（ＢＣＡＳＴ）サービス属性、コンテンツ属性、通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）、サービスガイド、放送（ＢＣＡＳＴ）サービスの保護（ｐｒｏｔｅｃｔｉｏｎ）に使用されるＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）ＲＯ及びキー値などのセキュリティ要素（Ｓｅｃｕｒｉｔｙ ｍａｔｅｒｉａｌ）、連動（Ｉｎｔｅｒａｃｔｉｏｎ）チャネルを通じて伝送されるすべてのデータ及びシグナリングの伝送路である。

ＢＣＡＳＴ−７ １２７は、サービスプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）、加入（Ｓｕｂｓｃｒｉｐｔｉｏｎ）情報、デバイスマネジメント（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）、放送（ＢＣＡＳＴ）サービスの保護（ｐｒｏｔｅｃｔｉｏｎ）に使用されるＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）ＲＯ及びキー値などのセキュリティ要素（Ｓｅｃｕｒｉｔｙ ｍａｔｅｒｉａｌ）などの受信に関連した制御情報の連動（Ｉｎｔｅｒａｃｔｉｏｎ）チャネルを通じて伝送されるユーザ嗜好（ｐｒｅｆｅｒｅｎｃｅ）情報の伝送路である。

ＢＣＡＳＴ−８ １２８は、ＢＣＡＳＴサービスに対するユーザのデータが連動される（Ｉｎｔｅｒａｃｔｅｄ）伝送路である。ＢＤＳ−１ １２９は、保護された（ｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、保護されない（Ｕｎｐｒｏｔｅｃｔｅｄ）放送（ＢＣＡＳＴ）サービス、放送（ＢＣＡＳＴ）サービス属性、コンテンツ属性、通知（ｎｏｔｉｆｉｃａｔｉｏｎ）、サービスガイド及び放送（ＢＣＡＳＴ）サービスの保護（ｐｒｏｔｅｃｔｉｏｎ）に使用されるＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）ＲＯ及びキー値などのセキュリティ要素（Ｓｅｃｕｒｉｔｙ ｍａｔｅｒｉａｌ）の伝送路である。
ＢＤＳ−２ １３０は、サービスプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）、加入（Ｓｕｂｓｃｒｉｐｔｉｏｎ）情報、デバイスマネジメント（Ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）及び放送（ＢＣＡＳＴ）サービスの保護（ｐｒｏｔｅｃｔｉｏｎ）に使用されるＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）ＲＯ及びキー値などのセキュリティ要素（Ｓｅｃｕｒｉｔｙ ｍａｔｅｒｉａｌ）の伝送路である。
Ｘ−１ １３１は、前記ＢＤＳサービス配信部１１１と放送配信システム１１２との間の参照（ｒｅｆｅｒｅｎｃｅ）ポイントである。Ｘ−２ １３２は、前記ＢＤＳサービス配信部１１１と連動ネットワーク１１３との間の参照（ｒｅｆｅｒｅｎｃｅ）ポイントである。Ｘ−３ １３３は、放送配信システム１１２と端末１０５との間の参照（ｒｅｆｅｒｅｎｃｅ）ポイントである。Ｘ−４ １３４は、ＢＤＳサービス配信部１１１と放送チャネルを通じた端末１０５との間の参照（ｒｅｆｅｒｅｎｃｅ）ポイントである。Ｘ−５ １３５は、ＢＤＳサービス配信部１１１と連動（ｉｎｔｅｒａｃｔｉｏｎ）チャネルを通じた前記端末１０５との間の参照（ｒｅｆｅｒｅｎｃｅ）ポイントである。Ｘ−６ １３６は、連動ネットワーク１１３と端末１０５との間の参照（ｒｅｆｅｒｅｎｃｅ）ポイントである。

次に、本発明の実施形態によるサービスガイド（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を提供するためのサービスガイドデータモデル（Ｄａｔａ Ｍｏｄｅｌ）を説明する。これは、ＯＭＡ ＢＣＡＳＴを例示して説明する。

図２は、本発明の実施形態によるサービスガイド生成のためのサービスガイドデータモデルを説明するための図である。ここで、各ブロックをフラグメント（ｆｒａｇｍｅｎｔ）と言い、各フラグメントを連結する実線は、フラグメント間の相互参照を意味する。

図２を参照すれば、サービスガイドデータ（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄａｔａ）モデルは、全体サービスガイドの基礎的情報を提供する管理グループ（Ａｄｍｉｎｉｓｔｒａｔｉｖｅ）２００、サービス、コンテンツ、スケジュールなどサービスガイドの核心部分であるコアグループ（Ｃｏｒｅ）２２０、サービスまたはコンテンツに接続することができるように接続情報を提供するアクセスグループ（Ａｃｃｅｓｓ）２３０、及び加入及び購買情報を含むプロビジョニンググループ（Ｐｒｏｖｉｓｉｏｎｉｎｇ）２１０で構成される。

これに対する各々の構成要素は、管理グループ２００は、サービスガイド伝送記述子（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ、以下、“ＳＧＤＤ”という）２０１を含む。
プロビジョニンググループ２１０は、購入アイテム（Ｐｕｒｃｈａｓｅ Ｉｔｅｍ）２１１、購入データ（Ｐｕｒｃｈａｓｅ Ｄａｔａ）２１２、及び購入チャネル（Ｐｕｒｃｈａｓｅ Ｃｈａｎｎｅｌ）２１３を含む。

コアグループ２２０は、サービス（Ｓｅｒｖｉｃｅ）２２１、スケジュール（Ｓｃｈｅｄｕｌｅ）２２２、及びコンテンツ（Ｃｏｎｔｅｎｔ）２２３を含む。
アクセスグループ２３０は、アクセス（Ａｃｃｅｓｓ）２３１、セッション記述（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）２３２を含む。

その他、サービスガイドは、前述した４個のグループ以外にプレビューデータ（Ｐｒｅｖｉｅｗ Ｄａｔａ）２４１及び相互データ（Ｉｎｔｅｒａｃｔｉｖｉｔｙ Ｄａｔａ）２５１をさらに含む。

前述した各構成を、サービスガイドを構成する最小単位であるフラグメント（Ｆｒａｇｍｅｎｔ）と言う。

以下、サービスガイドデータモデルの各フラグメント構成要素を説明する。ＳＧＤＤ ２０１は、サービスガイド伝送ユニット（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｕｎｉｔ、以下、“ＳＧＤＵ”という）が位置する伝送セッション情報を通知する。ここで、ＳＧＤＵは、前述したようなサービスガイド構成に必要なフラグメント２１１、２１２、２１３、２２１、２２２、２２３、２３１、２３２、２４１、２５１を収納するコンテナである。また、ＳＧＤＤ２０１は、ＳＧＤＵに対するグルーピング（Ｇｒｏｕｐｉｎｇ）情報及び通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージを受信するための入口（Ｅｎｔｒｙ Ｐｏｉｎｔ）に関する情報を通知する。
サービス（Ｓｅｒｖｉｃｅ）フラグメント２２１は、全体サービスガイドを中心に放送サービスに含まれるコンテンツ（Ｃｏｎｔｅｎｔ）の上位集合体であって、サービスの内容、ジャンル、サービス地域などの情報を含む。

スケジュール（Ｓｃｈｅｄｕｌｅ）フラグメント２２２は、ストリーミング（Ｓｔｒｅａｍｉｎｇ）、ダウンローディング（Ｄｏｗｎｌｏａｄｉｎｇ）などサービスに含まれたコンテンツ各々の時間情報を示す。コンテンツ（Ｃｏｎｔｅｎｔ）フラグメント２２３は、放送されるコンテンツに対する詳細な説明、ターゲットユーザーグループ、サービス地域、ジャンルなどを含む。
アクセス（Ａｃｃｅｓｓ）フラグメント２３１は、サービスを見ることができるように接続と関連した情報を提供し、当該接続セッションに対する伝送方法、セッション情報などを提供する。

セッション記述（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）フラグメント２３２は、アクセスフラグメント（Ａｃｃｅｓｓ）２３１に含ませてもよく、ＵＲＩ形態で位置情報を通知し、端末が当該セッション記述（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｉｏｎ）フラグメント２３２情報を確認することができる。セッション記述フラグメント２３２は、当該セッションに存在するマルチメディアコンテンツに対するアドレス情報、コーデック情報などを提供する。

購入アイテム（Ｐｕｒｃｈａｓｅ Ｉｔｅｍ）フラグメント２１１は、サービス、コンテンツ、時間などのバンドル（Ｂｕｎｄｌｅ）を提供し、ユーザが当該購入アイテム（Ｐｕｒｃｈａｓｅ Ｉｔｅｍ）フラグメント２１１を加入または購買することができるように補助する。

購入データ（Ｐｕｒｃｈａｓｅ Ｄａｔａ）フラグメント２１２は、サービスあるいはサービスバンドルに対する価格情報、プロモーション情報など購買、加入に対する具体的な情報を含む。

購入チャネル（Ｐｕｒｃｈａｓｅ Ｃｈａｎｎｅｌ）フラグメント２１３は、加入あるいは購買のための接続情報を通知する。
また、サービスガイド（ＳＧ、Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）は、プレビューデータ（Ｐｒｅｖｉｅｗ Ｄａｔａ）フラグメント２４１を通じてサービス、スケジュール、コンデンツに対するプレビュー（Ｐｒｅｖｉｅｗ）情報を提供するか、または相互データ（Ｉｎｔｅｒａｃｔｉｖｉｔｙ Ｄａｔａ）フラグメント２５１を通じて当該サービス、スケジュール、コンテンツによって放送中に双方向（Ｉｎｔｅｒａｃｔｉｖｅ）サービスを提供することもできる。

サービスガイドに対する具体的な情報は、図２の上位データモデルを基盤にして詳細内容及び値を提供するための多様な要素値（Ｅｌｅｍｅｎｔ）及び属性（Ａｔｔｒｉｂｕｔｅ）値を通じて定義されうる。

また、サービスガイドの各々のフラグメントは、そのフラグメントの目的を遂行するための要素値及び属性値を含む。
次に、本発明の実施形態によるメッセージスキーマテーブルについて説明する。本発明の実施形態においてＳＧＤＤ２０１を通じて伝送される情報は、メッセージスキーマテーブル形態で伝送されうる。

次の表１は、本発明の実施形態によるスキーマテーブルを説明するためのものである。

表１に示されたように、スキーマテーブルは、名前（Ｎａｍｅ）、タイプ（Ｔｙｐｅ）、範疇（Ｃａｔｅｇｏｒｙ）、カーディナリティ（Ｃａｒｄｉｎａｌｉｔｙ）、説明（Ｄｅｓｃｒｉｐｔｉｏｎ）及びデータタイプ（Ｄａｔａ ｔｙｐｅ）を含む。

名前（Ｎａｍｅ）は、当該メッセージを構成する要素値と属性値に対する名称を示す。タイプ（Ｔｙｐｅ）は、当該名前が要素値あるいは属性値のうちいずれかの形態であるかを意味する。要素値は、Ｅ１、Ｅ２、Ｅ３、Ｅ４のような値を有し、Ｅ１は、全体メッセージに対する上位要素値を意味し、Ｅ２は、Ｅ１の下位要素値、Ｅ３は、Ｅ２の下位要素値、Ｅ４は、Ｅ３の下位要素値を示す。属性値はＡで表示し、Ａは、当該要素の属性値を示す。例えば、Ｅ１の下側のＡは、Ｅ１の属性値を示す。
範疇（Ｃａｔｅｇｏｒｙ）は、当該要素値あるいは属性値が必須内容であるか否かを区分するために使用され、必須の場合、Ｍ値を有し、オプションの場合、Ｏ値を有する。
カーディナリティ（Ｃａｒｄｉｎａｌｉｔｙ）は、要素間の関係を示し、各々“０”、“０．．１”、“１”、“０．．ｎ”、及び“１．．ｎ”の値を有する。ここで、０は、オプションを意味し、１は、必須関係を意味し、ｎは、多数の値を有することができることを意味する。例えば、０．．ｎは、当該要素値がなくてもよく、ｎ個の値を有することもできることを意味する。

説明（Ｄｅｓｃｒｉｐｔｉｏｎ）は、当該要素または属性値が意味するものを記述し、データタイプ（Ｄａｔａ Ｔｙｐｅ）は、当該要素値あるいは属性値に対するデータ形態を示す。

次に、本発明の実施形態によるサービスガイド受信方法を説明する。図３は、本発明の実施形態による端末のサービスガイド受信方法を説明するための図である。
図３を参照すれば、ＳＧＤＤ３０１（図２の２０１）は、サービス情報を含むすべてのフラグメントに対する伝送において伝送されるセッション情報及びグループ情報、通知メッセージ接続情報などを含む。特に、本発明の実施形態によるＳＧＤＤ３０１は、ＲＭＳテンプレートに対する情報を含む。このようなＲＭＳテンプレートに対する情報は、下記でさらに詳しく説明し、図３では、その説明を省略する。

携帯放送サービスを提供する端末は、端末電源がオンとされるか、あるいはサービスガイド受信動作を開始すれば、まず、サービスガイド宣言チャネル（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ、ＳＧ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｃｈａｎｎｅｌ、以下、“ＳＧ宣言チャネル”という）３００に接続する。
端末が接続した当該ＳＧ宣言チャネル３００には、ＳＧＤＤサービスガイド伝達記述子（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ：ＳＧＤＤ）３０１が少なくとも１つ存在し（ＳＧＤＤ＃１、…、ＳＧＤＤ＃２、…、ＳＧＤＤ＃３）、ＳＧＤＤ３０１が伝送する情報は、次の表２のような内容が含まれる。

表２は、フラグメントの１つであるＳＧＤＤ３０１を構成する要素及び属性値を記述するものである。ＳＧＤＤ３０１は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）スキーマで表現される。また、表２は、１つの表を便宜上複数の部分に区分して示したものであって、各部分において各項目の定義は、表２の定義による。

また、ＳＧＤＤ３０１の内容によって実際のデータは、ＸＭＬフォーマットで提供される。このような情報は、放送システムによって、要素値及び属性値が対応する値に設定された、様々なデータフォーマットで提供されることもできる。
ＳＧ宣言チャネル３００を通じて受信されたＳＧＤＤ３０１は、説明エントリー（Ｄｅｓｃｒｉｐｔｏｒ Ｅｎｔｒｙ）３０２を含む。説明エントリー３０２は、フラグメント情報を収納しているＳＧＤＵ３１２に対する伝送情報を有し、端末は、説明エントリー３０２を通じてＳＧＤＵ３１２の伝送情報を確認する。表２に示されたように、説明エントリー３０２は、“ＧｒｏｕｐｉｎｇＣｒｉｔｅｒｉａ”、“ＳｅｒｖｉｃｅＧｕｉｄｅＤｅｌｉｖｅｒｙＵｎｉｔ”、“Ｔｒａｎｓｐｏｒｔ”、及び“ＡｌｔｅｒｎａｔｉｖｅＡｃｃｅｓｓＵＲＩ”などを含む。

“Ｔｒａｎｓｐｏｒｔ”あるいは“ＡｌｔｅｒｎａｔｉｖｅＡｃｃｅｓｓＵＲＩ”は、伝送と関連したチャネル情報を提供し、当該チャネルで伝送される実際の値は、ＳＧＤＵ３１２を通じて提供される。

ここで、“ＧｒｏｕｐｉｎｇＣｒｉｔｅｒｉａ”を通じて“Ｓｅｒｖｉｃｅ”、“Ｇｅｎｒｅ”など当該ＳＧＤＵ３１２に対する上位グループ（Ｇｒｏｕｐ）情報が提供されてもよく、端末１０５は、すべてのＳＧＤＵ３１２を受信し、当該グループ（Ｇｒｏｕｐ）情報によってユーザに表示することができる。
伝送情報を確認した端末１０５は、ＳＧ伝送チャネル（Ｄｅｌｉｖｅｒｙ Ｃｈａｎｎｅｌ）３１０を通じてＳＧＤＤ３０１から得たすべての伝送チャネル（Ｄｅｌｉｖｅｒｙ Ｃｈａｎｎｅｌ）に接続し、実際ＳＧＤＵ３１２を受信するようになる。
このような伝送チャネル３１０は、”ＧｒｏｕｐｉｎｇＣｒｉｔｅｒｉａ”を利用することによって特定される。例えば、図３に示されたように、時間単位チャネル（Ｈｏｕｒｌｙ ＳＧ Ｃｈａｎｎｅｌ）、日単位チャネル（Ｄａｉｌｙ ＳＧ Ｃｈａｎｎｅｌ）などのタイムベースの伝送チャネルによってＳＧＤＵが送信される。
これにより、端末１０５は、必要なチャネルにだけ接続し、当該チャネルに存在するすべてのＳＧＤＵを受信するようにできる。端末１０５は、ＳＧ伝送チャネル３１０を通じてＳＧＤＵ３１２をすべて受信するようになれば、全ＳＧフラグメント３２０（図２の２１１、２１２、２１３、２２１、２２２、２２３、２３１、２３２、２４１、２５１）を確認した後、ＳＧフラグメントを結合して実際のサービスガイドをユーザに出力する。
本発明の実施形態によれば、前述したすべてのサービスガイドフラグメントをＲＭＳテンプレートを通じてユーザに出力する。以下では、本発明の実施形態によるＲＭＳテンプレートを利用したサービスガイド提供方法について説明する。

“ＲＭＳ”は、“Ｒｉｃｈ Ｍｅｄｉａ Ｓｏｌｕｔｉｏｎ”の略字であって、ＯＭＡ ＢＣＡＳＴでリッチメディア（ｒｉｃｈ ｍｅｄｉａ）技術を包括的に表現するために定義した名称である。
サービスガイド表示のためにＲＭＳをサービスガイドの情報が含まれたサービスガイドフラグメントに直接適用する場合、既存のＢＣＡＳＴ端末は、新規サービスガイドを解釈し処理するのに互換性などの問題が発生することがある。したがって、本発明の実施形態では、別にサービスガイド表示のためのＲＭＳテンプレートを提供することによってＲＭＳをサポートする端末に限って、ＲＭＳテンプレートを利用してサービスガイドを表示することができるようにする。一方、ＲＭＳをサポートしない端末は、自らの表示方式に合わせてサービスガイドを表示することができる。
このようなＲＭＳテンプレートに対する情報（以下、”ＲＭＳ情報”という）は、ＳＧＤＤを通じて伝送される。本発明の実施形態によるＳＧＤＤは、表２のような情報に加え、下記で説明される図７、表３のようなＲＭＳ情報をさらに含む。
次の表３は、本発明の第１実施形態によるＲＭＳ情報を説明するためのものである。

表３において、表１で説明したようなデータタイプ（Ｄａｔａ Ｔｙｐｅ）を省略した。

表３を参照すれば、本発明の第１実施形態によるＲＭＳ情報は、ＲＭＳテンプレート存在有無を示す情報、ＲＭＳテンプレートに対する情報、ＲＭＳテンプレート実行のための要求事項に対する情報、及びＲＭＳテンプレート伝送に対する情報を含む。
このようなＲＭＳ情報は、その要素として、ＲＭＳ、ＲＭＳＴｅｍｐｌａｔｅ、Ｔｙｐｅ、ｖｅｒｓｉｏｎ、ＳｃｒｅｅｎＳｉｚｅ、Ｖａｌｕｅ、Ｃｏｍｐｒｅｓｓｉｏｎ、Ｔｒａｎｓｐｏｒｔ、ＩｐＡｄｄｒｅｓｓ、ｐｏｒｔ、ｓｒｃＩｐＡｄｄｒｅｓｓ、ＴｒａｎｓｍｉｓｓｉｏｎＳｅｓｓｉｏｎＩＤ、ｈａｓＦＤＴ、ＴｒａｎｓｍｉｓｓｉｏｎＯｂｊｅｃｔＩＤ、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ、及びＡｌｔｅｒｎａｔｉｖｅＵＲＬ要素を含む。

ＲＭＳ要素は、サービスガイド表示時に使用するＲＭＳテンプレートの存在有無を通知するための要素であって、最上位要素である。

ＲＭＳＴｅｍｐｌａｔｅ要素は、多様な種類のＲＭＳ技術が存在するので、事業者が各々の技術に対してテンプレートを提供しようとする場合、各々の情報を区別して提供するための要素である。

Ｔｙｐｅは、テンプレートを生成するために使用されるＲＭＳの技術名を示巣属性であり、ｖｅｒｓｉｏｎは、使用されたＲＭＳのバージョン情報を示す属性である。
表３で記述するＲＭＳ技術のうち‘Ｗ３Ｃ ＳＶＧ Ｔｉｎｙ’は、必ずＳＶＧ Ｔｉｎｙに限定するものではなく、ＳＶＧ、ＳＶＧ Ｂａｓｉｃ、ＳＶＧ ｍｏｂｉｌｅなどのＳＶＧから派生したすべての技術を含む。

ＳｃｒｅｅｎＳｉｚｅ要素は、多様な端末画面サイズを考慮して各々に適したテンプレートを提供するために端末が自分に適したＲＭＳテンプレートを獲得するように通知するための要素である。

Ｖａｌｕｅは、ＲＭＳテンプレートが適用されるために必要な最小限の端末画面解像度を示す属性である。表では、Ｖａｌｕｅ要素の値として画面の‘ｗｉｄｔｈ＊ｈｅｉｇｈｔ’で表現したが、これは、画面解像度（ｐｉｘｅｌ ｒｅｓｏｌｕｔｉｏｎ）、端末画面の対角線長、ＣＩＦ／ＱＣＩＦなどで表現する標準化されたフォーマットなどで表現されることができることは勿論である。

Ｃｏｍｐｒｅｓｓｉｏｎは、ＲＭＳテンプレートの圧縮有無及び使用圧縮アルゴリズムを示す属性である。

Ｔｒａｎｓｐｏｒｔ要素は、ＲＭＳテンプレートを送信する通信セッションのポインタを示す要素である。

ＩｐＡｄｄｒｅｓｓは、伝送セッションにおける送信先アドレスのｉｐアドレスを示す属性であり、ｐｏｒｔは、伝送セッションにおける送信先のポート番号を示す属性である。

ｓｒｃＩｐＡｄｄｒｅｓｓは、伝送セッションの送信元アドレスの情報、すなわち送信元特有の（ｓｏｕｒｃｅ ｓｐｅｃｉｆｉｃ）マルチキャスティング時に必要なＩＰアドレスを提供する属性である。

また、ＴｒａｎｓｍｉｓｓｉｏｎＳｅｓｓｉｏｎＩＤは、伝送セッションＩＤを示す属性である。
ｈａｓＦＤＴは、ＲＭＳを伝送する伝送セッションでＦＤＴを使用するか否かを示す属性であり、この属性がｔｒｕｅである場合には、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ属性を使用してＲＭＳテンプレートのファイル名を指定し、端末１０５がＲＭＳテンプレートを受信するようにすることができる。
ＴｒａｎｓｍｉｓｓｉｏｎＯｂｊｅｃｔＩＤは、伝送セッション中のＲＭＳテンプレートの識別子を示す属性である。

最後に、ＡｌｔｅｒｎａｔｉｖｅＵＲＬ要素は、放送ではない双方向（ｉｎｔｅｒａｃｔｉｏｎ）チャネルを使用して一対一通信でＲＭＳテンプレートを受信しようとする時に使用される情報である。
本発明の実施形態によれば、前述したＲＭＳ情報は、ＳＧＤＤを通じて伝送され、端末は、ＲＭＳ情報を利用してＲＭＳテンプレートを受信する。また、端末は、図２、図３及び図７で説明したように、サービスガイド（サービスガイドフラグメント）を受信し、受信したサービスガイドを、ＲＭＳテンプレートを利用してユーザに出力する。
本発明の第２実施形態において、ＳＧＤＤは、表２に含まれた情報に加えて図７及び表４に含まれたＲＭＳ情報を含む。次の表４は、本発明の第２実施形態によるＲＭＳ情報を説明するためのものである。下記の表４は、多くのＢＳＭがＳＧＤＤを共有する場合をサポートするために定義されたＲＭＳ情報を含む。

第２実施形態のＲＭＳ情報は、多数の事業者が１つの網を共有する場合を想定したものである。したがって、本発明の第２実施形態によるＲＭＳ情報は、１つの網を共有する事業者が存在する場合、各事業者によるリッチメディアサービスガイドテンプレートを提供することができる。

表４を参照すれば、ＳＧＤＤを様々なＢＳＭ（Ｂｒｏａｄｃａｓｔ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）が共有する場合、表４のように、これをＳＧＤＤのＢＳＭＬｉｓｔ要素の下位要素であるＢＳＭＳｅｌｅｃｔｏｒ要素を通じて通知する。また、本発明では、ＲＭＳテンプレートの存在有無を前記ＢＳＭＳｅｌｅｃｔｏｒ要素の情報に追加して通知する。

したがって、表４においてＲＭＳ要素は、ＢＳＭＳｅｌｅｃｔｏｒ要素に属し、ＲＭＳＴｅｍｐｌａｔｅ要素を含む。
ＲＭＳＴｅｍｐｌａｔｅ要素は、Ｃｒｉｔｅｒｉａ、Ｃａｐａｂｉｌｉｔｉｅｓ、Ｔｒａｎｓｐｏｒｔ、ＡｌｔｅｒｎａｔｉｖｅＵＲＬ及びＧｌｏｂａｌＣｏｎｔｅｎｔＩｄ要素を含む。

ＢＳＭＳｅｌｅｃｔｏｒは、ＢＣＡＳＴで事業者を識別するための情報を示す要素として使用される。ＢＳＭＳｅｌｅｃｔｏｒは、ＳＧＤＤを共有して様々な事業者がサービスガイドを提供しようとする場合、重要な分類基準となる。そのため、各事業者別にサービスガイドテンプレートをサポートするためにＢＳＭＳｅｌｅｃｔｏｒの下位要素としてＲＭＳＴｅｍｐｌａｔｅが追加されている。また、ＳＧＤＤにＲＭＳ要素を追加することによって、端末は、事前にサービスガイドフラグメントを通じて伝達されるメタデータを受けとる前にＲＭＳ処理のための準備を行うことができるので、さらに迅速にリッチメディアが反映されたサービスガイドを表示することができる。

Ｃｒｉｔｅｒｉａ要素は、特定の条件を満足する端末だけがＲＭＳテンプレートを受信するフィルタリング規則を提供する。

Ｃｒｉｔｅｒｉａ要素は、事業者が必要な様々な条件を定義できるように、仕様上詳細に定義されておらず、ｔｅｍｐｌａｔｅＶｅｒｓｉｏｎ、ａｔｔｒｉｂｕｔｅＮａｍｅ及びａｔｔｒｉｂｕｔｅＶａｌｕｅ属性を含む。ここで、ｔｅｍｐｌａｔｅＶｅｒｓｉｏｎ属性は、時間情報を基準にして新規ＲＭＳテンプレート適用のための機能を提供する。ａｔｔｒｉｂｕｔｅＮａｍｅ及びａｔｔｒｉｂｕｔｅＶａｌｕｅ属性は、事業者別に個別定義することができるように提供される。

Ｃａｐａｂｉｌｉｔｉｅｓ要素は、当該ＲＭＳテンプレートを表示するための端末の必要性能を定義する。端末が前記Ｃａｐａｂｉｌｉｔｉｅｓ要素の条件を充足させない場合には、ＲＭＳテンプレート処理に問題が発生し得るので、端末は、Ｃａｐａｂｉｌｉｔｉｅｓ要素に該当する条件が充足されない時には、テンプレートを受信しない。

Ｔｒａｎｓｐｏｒｔ要素は、ＲＭＳテンプレートを、放送を通じて端末１０５が受信時に必要な情報を有する。これは、表３による第１の実施形態と同じである。

ＡｌｔｅｒｎａｔｉｖｅＵＲＬ要素は、一対一接続でＲＭＳテンプレートを直接受信することができるアドレス情報である。
ＧｌｏｂａｌＣｏｎｔｅｎｔＩｄ要素は、事業者がＲＭＳテンプレートをコンデンツとして提供しようとする場合、そのコンテンツフラグメントの識別子である。

前記方法で使用する場合には、既存のＢＣＡＳＴのファイル伝送方法により、ＲＭＳテンプレートが転送されるが、端末でＲＭＳテンプレートを利用してたサービスガイド表示するのは、直接ＳＧＤＤにあるＴｒａｎｓｐｏｒｔ要素を使用することより遅いことがある。

次に、本発明の第３実施形態に係るＲＭＳ情報を説明する。図７及び次の表５は、本発明の第３実施形態に係るＲＭＳ情報を説明するためのものである。本発明の第３実施形態は、様々なＢＳＭ ＳＧＤＤを共有する場合を支援するために定義されたＲＭＳ情報を含むことは第２の実施形態と同じであるが前記ＲＭＳ情報内にＢＳＭ情報を含むようにすることが第２の実施形態と異なる。

表５に示された要素は、表４と同一なので、その説明を省略する。ここでは、表４に存在せず、表５に新しく追加された要素だけを説明する。
ＢＳＭＳｅｌｅｃｔｏｒ要素は、事業者を示すＢＳＭ値を指定できるようにする要素であって、下位要素であるｉｄに事業者値を入れる。前記ｉｄ値によって事業者によるＲＭＳテンプレート適用可否が決定される。

以下、本発明の実施形態による伝送装置のＲＭＳ伝送方法について説明する。

図４は、本発明の実施形態によるＲＭＳ伝送方法を説明するためのフローチャートである。

図４を参照すれば、ＢＳＤＡ１０３は、ステップＳ４０１で、サービスガイド（ＳＧ）を必要なサービスガイドフラグメント形態で生成する。

サービスガイドを生成したＢＳＤＡ１０３は、ステップＳ４０３で、端末１０５がサービスガイドを表示することができるようにするＲＭＳテンプレートを生成する。
ステップＳ４０３で、ＢＳＤＡ１０３は、ＲＭＳテンプレート生成に使用するＲＭＳ技術を、Ｗ３Ｃ ＳＶＴ Ｔｉｎｙ、ＯＭＡ ＲＭＥ、ＭＰＥＧ ＬＡＳｅＲまたは３ＧＰＰ ＤＩＭＳから選択する。

この際、ＲＭＳテンプレートがない場合、ＢＳＤＡ１０３は、新たに生成することもでき、既に作られたＲＭＳテンプレートがある場合、ＢＳＤＡ１０３は、サービスガイド表示のためのＲＭＳテンプレートを選択する動作を行う。

ＲＭＳテンプレートを生成するか選択したＢＳＤＡ１０３は、ステップＳ４０５で、ＳＧＤＤを生成する。このようなＳＧＤＤは、ＲＭＳ情報を含む。ＲＭＳ情報は、前述した表３及び表４及び表５のうちいずれか１つのフォーマットで提供される。すなわち、ＢＳＤＡ１０３は、ＳＧＤＤを生成する時、表２で説明したようなサービスガイド構成に必要なサービスガイドフラグメントに対する情報と共に、表３または表４または表５で説明されたようなＲＭＳ情報を含む。

ＢＳＤＡ１０３は、ステップＳ４０７で、ＳＧＤＤ、サービスガイド、及びＲＭＳテンプレートを端末１０５が受信することができるようにブロードキャストする。
一方、双方向チャネルを通じてＲＭＳテンプレートが伝送される場合、ＢＳＤＡ１０３は、ステップＳ４０５で、ＲＭＳテンプレートが双方向チャネルを通じて伝送されることを通知するＲＭＳ情報をＳＧＤＤに加える。ステップＳ４０７で、ＢＳＤＡ１０３は、ＳＧＤＤ、サービスガイドフラグメントをブロードキャストし、双方向チャネルを通じてＲＭＳテンプレートを伝送する。

次に、前述したように伝送されるサービスガイドを、ＲＭＳテンプレートを通じて受信する端末の受信方法について説明する。

図５は、本発明の実施形態による端末のＲＭＳテンプレート受信方法を説明するための図である。

図５を参照すれば、端末１０５は、ステップＳ５０１で、ＢＳＤＡ１０３からＳＧＤＤを受信する。この際、端末１０５は、ＢＳＤＡ１０３から伝送されるＳＧＤＤをＳＧ宣言チャネル３００に接続して受信する。図３で説明したように、ＳＧ宣言チャネル３００を通じて少なくとも１つのＳＧＤＤが伝送され、端末１０５は、このようなＳＧＤＤのうち自分のＳＧＤＤを選択して受信する。

その後、端末１０５は、ステップＳ５０３で受信したＳＧＤＤを参照して自分のＳＧＤＵを受信し、ステップＳ５０５で受信したＳＧＤＵからサービスガイドフラグメントを抽出する。このようなサービスガイドフラグメントは、メタデータとされてもよい。
その後、端末１０５は、ステップＳ５０７でＳＧＤＤを分析し、ＳＧＤＤに表３または表４または表５のようなＲＭＳ情報が存在するか否かを判断する。この判断の結果、ＲＭＳ情報が存在すれば、ステップＳ５０９に移行し、ＲＭＳ情報が存在しなければ、ステップＳ５１５に移行する。

ＲＭＳ情報が存在することを確認した端末１０５は、ステップＳ５０９で、ＳＧＤＤ内にあるＲＭＳテンプレートをサポートするか否かを判断する。
このような判断は、表３及び表４及び表５のＲＭＳ情報に基づいて行われる。例えば、ＲＭＳ情報が表３の場合、“ｔｙｐｅ”または“ｖｅｒｓｉｏｎ”要素などを参照して、端末１０５は、自身当該ＲＭＳテンプレートをサポートするか否かを判断することができる。

一方、ＲＭＳ情報が表４の場合、Ｃｒｉｔｅｒｉａ及びＣａｐａｂｉｌｉｔｉｅｓ要素の情報を参照して、端末１０５は、自身が当該ＲＭＳテンプレートをサポートするか否かを判断することができる。
ステップＳ５９０の判断の結果、端末１０５が当該ＲＭＳテンプレートをサポートする場合、端末１０５は、ステップＳ５１１において、ＲＭＳテンプレートを受信する。

ここで、ＲＭＳ情報は、伝送に関する情報であり、このような伝送に関する情報は、表３及び表４及び表５に示されたように、Ｔｒａｎｓｐｏｒｔ要素（ＩｐＡｄｄｒｅｓｓ属性、ｐｏｒｔ属性、ｓｒｃＩｐＡｄｄｒｅｓｓ属性、ＴｒａｎｓｍｉｓｓｉｏｎＳｅｓｓｉｏｎＩＤ属性、ｈａｓＦＤＴ属性、ｃｏｎｔｅｎｔＬｏｃａｔｉｏｎ属性、ＴｒａｎｓｍｉｓｓｉｏｎＯｂｊｅｃｔＩＤ属性を含む）、及びＡｌｔｅｒｎａｔｉｖｅＵＲＬ要素を含む。したがって、端末１０５は、このようなＲＭＳ情報の世要素及び属性を参照してＲＭＳテンプレートを受信する。

その後、端末１０５は、ステップＳ５１３でステップＳ５０５において受信したサービスガイド（サービスガイドフラグメント）をＲＭＳテンプレートを利用してユーザに表示する。これにより、端末１０５は、事業者が希望する環境によってサービスガイドを出力することができる。

一方、ステップＳ５０７においてＳＧＤＤにＲＭＳ情報がないか、または、ステップＳ５０９においてＲＭＳ情報があるが当該ＲＭＳテンプレートをサポートしない場合、端末１０５は、ステップＳ５１５においてサービスガイドを端末１０５固有の方法を通じてユーザに出力する。

次に、本発明の実施形態によるＲＭＳテンプレートを利用したサービスガイドを提供のための端末の構成について説明する。図６は、本発明の実施形態による端末の構成を説明するための図である。

図６を参照すれば、本発明の実施形態による端末１０５は、受信モジュール６０１、ＲＭＳエンジン（ＲＭＳ Ｅｎｇｉｎｅ）６０３及び放送クライアント（ＢＣＡＳＴ Ｃｌｉｅｎｔ）６０５を含む。

放送受信モジュール６０１は、ＳＧＤＤを受信し、ＳＧＤＤを参照してＳＧＤＵを受信し、受信したＳＧＤＵからサービスガイドフラグメントを抽出する。また、放送受信モジュール６０１は、ＳＧＤＤのＲＭＳ情報を参照してＲＭＳテンプレートを受信する。
ＲＭＳエンジン６０３は、ＲＭＳテンプレートを解釈し、放送クライアント６０５に伝達する。

放送クライアント６０５は、サービスガイドフラグメントを解釈し、また、ＲＭＳエンジン６０３から伝達されたＲＭＳテンプレートを利用して解釈したサービスガイドを出力する。

このようなサービスガイドを表示するＲＭＳエンジン６０３についてさらに詳しく説明する。本発明では、ＲＭＳエンジン６０３のうちＬＡＳｅＲ（Ｌｉｇｈｔｗｅｉｇｈｔ Ａｐｐｌｉｃａｔｉｏｎ ｆｏｒ Ｓｃｅｎｅ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）エンジンを基盤とする端末を実施例として例示し、その他のＲＭＳエンジン基盤端末１０５では、ＬＡＳｅＲエンジンを基盤とする端末の実施例に基づいて同様に適用可能である。但し、端末に適用されるＲＭＳエンジン６０３あるいはシステムが変わる場合には、ＬＡＳｅＲエンジン以外に各ＲＭＳエンジンあるいはシステムで固有に使用する名称へのＲＭＳエンジンの転換が必要であり、これらは、当業者に自明である。

本発明の実施例によるＲＭＳエンジン６０３は、受信されたＲＭＳテンプレートであるＬＡＳｅＲテンプレートを復号化（Ｄｅｃｏｄｉｎｇ）する。この際、ＬＡＳｅＲテンプレートが符号化過程を経らないサービスコンテンツの場合、当該過程を行わなくてもよい。

また、ＲＭＳエンジン６０３は、復号化されたＬＡＳｅＲテンプレートでＬＡＳｅＲ命令語を確認して実行する。
ＬＡＳｅＲ命令語は、場面の変化を宣言的方法で表現するものであって、新しい場面を描きなさいという命令語である‘ＮｅｗＳｃｅｎｅ’要素、及び、属性を挿入しなさいという命令語である‘Ｉｎｓｅｒｔ’要素、及び、属性を削除しなさいという命令語である‘Ｄｅｌｅｔｅ’などがある。
ＬＡＳｅＲによる場面を構成するための要素は、場面を構成するメディア及びグラフィック個体を宣言的方法で表現するエレメント（ｅｌｅｍｅｎｔ）と各エレメントの属性を表現するアトリビュート（ａｔｔｒｉｂｕｔｅ）、及び、イベントとスクリプトなどが含まれる。

また、ＬＡＳｅＲテンプレートは、ＳＧＤＵを通じて獲得したサービスガイドフラグメントに収容されている情報に適用して画面に表示するための連携及び参照情報を含む。したがって、ＲＭＳエンジン６０３は、ＬＡＳｅＲテンプレートの連携及び参照情報を解釈し、解釈した情報に基づいてサービスガイドフラグメントに収容されている情報を確認する。

ＬＡＳｅＲエンジン６０３は、サービスガイドフラグメントに収容されている情報を利用してユーザに提供可能な形態でＬＡＳｅＲコンテンツを構成する。また、ＬＡＳｅＲエンジン６０３は、映像または音響などを支援するユーザインターフェース手段を通じて、前記構成されたサービスガイドを出力する。
サービスガイドフラグメントに収容されている情報は、サービスガイドを出力するためのメタデータ（ｍｅｔａｄａｔａ）であり、このようなサービスガイドメタデータ（以下、“ＳＧメタデータ”という）について説明する。
次の表６は、本発明の一実施例によるＳＧメタデータを説明するためのものである。

表６は、ＬＡＳｅＲテンプレートを通じて表示されるサービスガイドのメタデータ（ＳＧｍｅｔａｄａｔａ）の一例を示すものであり、これは、ＸＭＬ形式の構造化されたデータで表現されている。
前述したように、このようなＳＧメタデータは、ＲＭＳテンプレートを通じてユーザに出力される。次の表７は、本発明の一実施例によるＲＭＳテンプレートを示す。

表７は、サービスガイドフラグメントに収容されている情報、すなわち表６のＳＧメタデータを表示するためのＲＭＳテンプレートのうちＬＡＳｅＲテンプレートの一部を例示したものである。
ここで、ＬＡＳｅＲテンプレートは、‘ｉｄ’属性の属性値が‘Ｇｅｎｒｅ’である‘ｔｅｘｔ’と‘ｉｄ’属性の属性値が‘ＳｅｒｖｉｃｅＢｕｎｄｌｅＩｍａｇｅ’である‘ｉｍａｇｅ’を含む。

表７で説明したＲＭＳテンプレートのように、“ｔｅｘｔ”及び“ｉｍａｇｅ”要素の実際のデータ及び映像ファイルを示すために、映像ファイルのファイル名か、または映像ファイルのファイルパスを通知することができる。例えば、“ａ．ｊｐｇ”のように映像ファイルの名前を通知するか、または“．.／．.／．.／ａ．ｊｐｇ”、あるいは“ｈｔｔｐ：／／ｗｗｗ．.ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ／ａ．ｊｐｇ”のように映像ファイルのパスを通知する方法を使用することができる。すなわち、獲得したサービスガイドフラグメントに収容されている情報をＬＡＳｅＲのようなＲＭＳエンジン６０３を通じて表示するために、当該ファイルに接近することができるように、ＲＭＳエンジン６０３にファイル名前、ファイルパス、及び位置を通知する。
表７のように、ＬＡＳｅＲエンジンは、“ｔｒｅｆ”属性を利用して外部のデータを参照して、参照したデータをＬＡＳｅＲサービスコンテンツの‘ｔｅｘｔ’データで表示する。

また‘ｉｍａｇｅ’や‘ｖｉｄｅｏ’、‘ａｕｄｉｏ’のようにデータをリンクして、参照するための‘ｘｌｉｎｋ：ｈｒｅｆ’という属性を利用して‘ｘｌｉｎｋ：ｈｒｅｆ＝‘ＥＳＧ。ｘｍｌ＃ｘｍｌｎｓ（ＥＳＧＭａｉｎ／ＥＳＧ／ＰｕｒｃｈａｓｅＴａｂｌｅ／Ｐｕｒｃｈａｓｅ／ＭｅｄｉａＴｉｔｌｅ／ｍｐｅｇ７：ＴｉｔｌｅＩｍａｇｅ／ｍｐｅｇ７：ＭｅｄｉａＵｒｉ／ｔｅｘｔ（））’のように外部のデータの参照する情報を利用してＬＡＳｅＲサービスコンテンツの構成要素として表示する。
この場合、表７のＬＡＳｅＲテンプレートが画面に出力される時、‘ｉｄ’属性の属性値が‘Ｇｅｎｒｅ’である‘ｔｅｘｔ’のデータは、サービスガイドフラグメントに収容されている情報である‘ＮＯＮ＿ＦＩＣＴＩＯＮ’になる。また、‘ｉｄ’属性の属性値が’ＳｅｒｖｉｃｅＢｕｎｄｌｅＩｍａｇｅ’である‘ｉｍａｇｅ’の具体的な映像ファイルは、サービスガイドフラグメントに収容されている情報である‘ＥａｓｔｅｒＴｉｔｌｅ．ｊｐｇ’になる。

次の表８は、本発明の他の実施例によるＲＭＳテンプレートを説明するためのものである。

表８は、ＲＭＳテンプレートがＷ３Ｃ ＳＶＧテンプレートの場合の例を示すもので、表７で説明したＬＡＳｅＲテンプレートの結果と同じである。
ここで、ＲＭＳエンジン６０３が外部のデータを参照する方法は、Ｘｐａｔｈの構文を利用することもでき、Ｘｐｏｉｎｔｅｒ、ＸＳＬＴ（ＸＳＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｓｔｙｌｅｓｈｅｅｔ Ｌａｎｇｕａｇｅ）Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ）で表現するなど、サービスガイドのようなデータ情報を参照して表現するための多様な表現方法及び探索方法を利用するか、活用することができる。
本発明では、ＲＭＳエンジン６０３でＳＧメタデータを参照する方法を限定せず、これは、各システムやＲＭＳエンジン６０３でサービスガイドのようなデータを参照する多様な方法を活用することができることを意味する。
前述した図６を説明するにあたって、表３によるＲＭＳ情報を使用して説明したが、本発明の表４及び表５によるＲＭＳ情報を利用する場合にも同様に適用することができることは当然である。

以上、本発明をいくつかの好ましい実施形態を使用して説明したが、これらの実施形態は、例示的なものであって、限定的なものではない。このように、本発明の属する技術分野における通常の知識を有する者なら、本発明の思想と添付の特許請求の範囲に提示された権利範囲を逸脱しない範囲内で均等論によって多様な変化と修正を加えることができることを理解できるはずである。

Claims (14)

1. デジタル放送サービスにおけるリッチメディアを利用したサービスガイド生成方法において、
   ユーザデバイスに伝送される１つ以上の放送サービスに対するコンテンツ情報を収集する段階と；
   前記収集されたコンテンツ情報に基づいたサービスガイド伝送記述子（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ、ＳＧＤＤ）を生成する段階と；
   前記サービスガイド伝送記述子を前記ユーザデバイスにブロードキャストする段階と；を含み、
   前記サービスガイド伝送記述子は、リッチメディアコンテンツ情報を含み、
   前記リッチメディアコンテンツ情報は、ユーザデバイスの能力を示すデータを含むことを特徴とするサービスガイド生成方法。
2. 前記ユーザデバイスの能力を示すデータは、リッチメディアソリューション（Ｒｉｃｈ Ｍｅｄｉａ Ｓｏｌｕｔｉｏｎ、ＲＭＳ）テンプレート記述子に提供されることを特徴とする請求項１に記載のサービスガイド生成方法。
3. 前記ＲＭＳテンプレート記述子は、ユーザデバイスにおいてリッチメディアを利用したサービスガイドをレンダリングするためのＲＭＳテンプレートに対する伝送ポインタ（ｔｒａｎｓｐｏｒｔ ｐｏｉｎｔｅｒ）を含むことを特徴とする請求項２に記載のサービスガイド生成方法。
4. 前記伝送ポインタは、送信先アドレス、ポートナンバー、送信元アドレス、伝送セッション識別子のうち少なくとも１つを含むことを特徴とする請求項３に記載のサービスガイド生成方法。
5. 前記リッチメディアコンテンツ情報は、前記リッチメディアを利用したサービスガイドをレンダリングするためのＲＭＳテンプレートと連携されたＢＳＭ（Ｂｒｏａｄｃａｓｔ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ、ＢＳＭ）を識別する放送加入管理部識別子をさらに含むことを特徴とする請求項１に記載のサービスガイド生成方法。
6. デジタル放送サービスにおいてユーザデバイスのリッチメディアサービスガイドレンダリング方法であって、
   ユーザデバイスに伝送される１つ以上の放送サービスのコンテンツ情報基づいたサービスガイド伝送記述子（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ、ＳＧＤＤ）を受信する段階と；
   前記リッチメディアコンテンツ情報を利用して前記ユーザデバイスの互換性を決定する段階と；
   前記ユーザデバイスが前記リッチメディアコンテンツ情報と互換可能であると判断される場合、前記ＳＧＤＤに基づいて前記ユーザデバイスにおいて前記リッチメディアガイドをレンダリングする段階と；を含み、
   前記サービスガイド伝送記述子は、リッチメディアコンテンツ情報を含み、
   前記リッチメディアコンテンツ情報は、ユーザデバイスの能力を示すデータを含むことを特徴とするレンダリング方法。
7. 前記ユーザデバイスの能力を示すデータは、リッチメディアソリューション（Ｒｉｃｈ Ｍｅｄｉａ Ｓｏｌｕｔｉｏｎ、ＲＭＳ）テンプレート記述子に提供されることを特徴とする請求項６に記載のレンダリング方法。
8. 前記ＲＭＳテンプレート記述子は、ユーザデバイスにおいてリッチメディアを利用したサービスガイドをレンダリングするためのＲＭＳテンプレートに対する伝送ポインタ（ｔｒａｎｓｐｏｒｔ ｐｏｉｎｔｅｒ）を含むことを特徴とする請求項７に記載のレンダリング方法。
9. 前記伝送ポインタは、送信先アドレス、ポートナンバー、送信元アドレス、伝送セッション識別子のうち少なくとも１つを含むことを特徴とする請求項８に記載のレンダリング方法。
10. 前記リッチメディアコンテンツ情報は、前記リッチメディアを利用したサービスガイドをレンダリングするためのＲＭＳテンプレートと連携されたＢＳＭ（Ｂｒｏａｄｃａｓｔ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ、ＢＳＭ）を識別する放送加入管理部識別子をさらに含むことを特徴とする請求項６に記載のレンダリング方法。
11. デジタル放送サービスにおいてリッチメディアを利用したサービスガイドのためのプロセッサが読み取り可能な媒体に含まれたデータ構造であって、
    ユーザデバイスに伝送される１つ以上の放送サービスに対するコンテンツ情報に基づいたサービスガイド伝送記述子（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ Ｄｅｌｉｖｅｒｙ Ｄｅｓｃｒｉｐｔｏｒ、ＳＧＤＤ）と；
    前記リッチメディアを利用したサービスガイドに対するリッチメディアコンテンツ情報を含むリッチメディアソリューション（Ｒｉｃｈ Ｍｅｄｉａ Ｓｏｌｕｔｉｏｎ、ＲＭＳ）フラグメントと；
    前記リッチメディアコンテンツ情報を利用して前記ユーザデバイスの互換性を決定するためのユーザデバイスの能力を示すデータを含むＲＭＳテンプレート記述子と；を含むことを特徴とするデータ構造。
12. ユーザデバイスにおいて、リッチメディアを利用したサービスガイドをレンダリングするためのＲＭＳテンプレートに対する伝送ポインタ（ｔｒａｎｓｐｏｒｔ ｐｏｉｎｔｅｒ）をさらに含むことを特徴とする請求項１１に記載のデータ構造。
13. 前記伝送ポインタは、送信先アドレス、ポートナンバー、送信元アドレス、伝送セッション識別子のうち少なくとも１つを含むことを特徴とする請求項１２に記載のデータ構造。
14. 前記リッチメディアを利用したサービスガイドをレンダリングするためのＲＭＳテンプレートと連携されたＢＳＭ（Ｂｒｏａｄｃａｓｔ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ、ＢＳＭ）を識別する放送加入管理部識別子をさらに含むことを特徴とする請求項１１に記載のデータ構造。

Images