JP4550900B2 - データストリームを受信するクライアント及びデータストリーム受信方法 - Google Patents

Description

本発明は、伝送コードセットのシグナリング方法及び装置に係り、より詳細には、オブジェクトカルーゼルメッセージ内の経路名（Ｐａｔｈｎａｍｅ）の文字エンコーディングシステムに関する情報を伝送することによって、多様な言語による経路名の命名を可能にする伝送コードセットのシグナリング方法及び装置に関する。

デジタル放送は、既存のアナログ放送とは違って、双方向運用、再生、蓄積が可能な先端放送技術であって、情報信号を符号化して記録できる、デジタル形態にＴＶ信号を圧縮／送出する放送を意味する。デジタル放送は、既存の伝送信号より６倍以上の信号を伝達でき、これにより、最小２倍以上の解像度を提供できる。一つの電波に複数の映像及び音声を含めて送ることができるので、既存放送の一つのチャンネルに該当する帯域幅を利用して６〜８個のチャンネルを運用できる。換言すれば、デジタル放送は、通信やコンピュータで使用する技術で映像及び音声を圧縮し、あらゆる信号を変調する総合情報媒体時代の核心的媒体である。このようなデジタル放送環境がもたらす変化は、伝統的に受動的であったＴＶを、さらに能動的かつ双方向的なコンピュータのような知能を持つ真のマルチメディアに変革させていることである。

最近急浮上しつつあるデータ放送は、直ちにそうしたデジタル放送の核心をなしている。
データ放送は、映像、音声、ソフトウェア、ストリーミング情報以外にデジタル／マルチメディアに結合された放送コンテンツを、ＰＣとデジタルセットトップボックス、個人携帯用端末機などのように情報処理能力を持つ装置に持続的に伝送する概念である。また、放送であるためにリターン経路が必ずしも必要ではなく、コンテンツは要請しなくても受信される。したがって、データ放送は、既存放送サービスの単純性及びインターネットサービス容量の限界性を同時に解決できる新たなメディアコミュニケーションの代案といえる。言い換えれば、技術的側面でのデータ放送は、インターネットで楽しめる双方向的マルチメディアコンテンツを超高速に大量伝送できる放送の長所を利用して、視聴者に伝達する、放送、インターネット及び通信が結合された最先端技術であって、既存放送の一方性及び単純性はもとより、インターネット放送が持つ画質と音質、容量などの限界性までデジタル放送の伝送方式で乗り越えられる応用技術といえる。

このようなデジタル放送の伝送方式には、地上波受信方式で米国のＡＴＳＣ方式とヨーロッパのＤＶＢ−Ｔ方式とがあり、ケーブル受信方式で米国のＯｐｅｎＣａｂｌｅ方式とヨーロッパのＤＶＢ−Ｃ方式とがある。デジタル放送の受信のためのミドルウェアに関する標準規格には、ＤＶＢ−ＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ）、ＯＣＡＰ（ＯｐｅｎＣａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）、ＡＣＡＰ（Ａｄｖａｎｃｅｄ Ｃｏｍｍｏｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）などがある。ＤＶＢ−ＭＨＰは、ＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）プロジェクトによりデザインされた、ヨーロッパ式デジタルＴＶ受信のためのミドルウェアシステムであり、ＯＣＡＰは、米国のケーブル事業者により採用されたデジタルケーブルテレビセットトップボックス、及び他のデジタルディバイスのためのミドルウェアソフトウェアである。ＡＣＡＰは、ケーブル放送と地上波放送とが、ケーブル放送標準（ＯＣＡＰ）と地上波放送標準（ＤＡＳＥ）という相異なるデータ放送ミドルウェアを採択したことを、一つに統合しようとする動きから作られた。

ＤＶＢ−ＭＨＰ、ＯＣＡＰ、ＡＣＡＰなどの標準規格は、ＩＳＯ／ＩＥＣ １３８１８−６標準規格により定義されたオブジェクトカルーゼルを採用している。ところが、このオブジェクトカルーゼルは、情報、特にディレクトリやファイルを命名するために使われる経路名コンポーネントを交換するために、ＣＯＲＢＡ／ＩＩＯＰ ２．１で定義されたＣＯＲＢＡストリングを使用しており、ＣＯＲＢＡストリングでは、文字エンコーディング情報が明示されていなければ、エンコーディングシステムとしてＩＳＯ ８８５９−１（ＩＳＯ Ｌａｔｉｎ１）による。したがって、オブジェクトカルーゼルを使用しているＤＶＢ−ＭＨＰ、ＯＣＡＰ、ＡＣＡＰなどのオブジェクトカルーゼルを使用するミドルウェアでは、経路名、すなわち、ファイル名及びディレクトリ名のための基本エンコーディングシステムとして、ＩＳＯ ８８５９−１を使用している。これは、ＤＶＢ−ＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ）、ＯＣＡＰ（ＯｐｅｎＣａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）、ＡＣＡＰ（Ａｄｖａｎｃｅｄ Ｃｏｍｍｏｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）では、経路名として西洋言語（Ｗｅｓｔｅｒｎ Ｌａｎｇｕａｇｅ）のみを支援して、それ以外の言語では経路名を表せない限界がある。

本発明は、オブジェクトカルーゼルを使用するシステムで多様な言語で経路情報を表しうるように、エンコーディングシステムに関する情報を知らせる方法及び装置を提供するところにその目的がある。

前記目的を達成するために、本発明の実施例による伝送コードセットのシグナリング方法を使用するクライアントは、サーバーからブロードキャストされる放送ストリームを受信するシステムインターフェース、システムインターフェースにより受信された放送ストリームから、ユーザーにより選択されたプログラムに該当するＰＥＳ（Ｐａｃｋｅｔｉｓｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）パケットを、フィルタを利用して選択するデマルチプレクサ、デマルチプレクサにより選択された映像のためのＰＥＳをデコーディングする映像デコーダ、デマルチプレクサにより選択された音声のためのＰＥＳをデコーディングする音声デコーダ、映像デコーダによりデコーディングされた映像データを出力する映像出力部、音声デコーダによりデコーディングされた音声データを出力する音声出力部、デマルチプレクサにより選択されたＰＥＳまたはデコーディングされた映像データまたはデコーディングされた音声データを保存するメモリ、及びデマルチプレクサにより選択されたメッセージＰＥＳを処理し、メッセージからオブジェクトカルーゼルメッセージ内のＣＯＲＢＡストリングに使われた文字エンコーディングシステムに関する情報を抽出し、文字エンコーディングシステムによってＣＯＲＢＡストリングをデコーディングするＣＰＵを含む。

一方、本発明の実施例による伝送コードセットのシグナリング方法を使用するサーバーは、映像データをエンコーディングして映像ビットストリームを生成する映像エンコーダと、音声データをエンコーディングして音声ビットストリームを生成する音声エンコーダと、前記映像ビットストリーム及び音声ビットストリームをマルチプレクシングして伝送ストリームを生成するマルチプレクサと、前記伝送ストリームを出力可能な信号に変調するＲＦ信号処理部と、前記映像エンコーダ、前記音声エンコーダ、前記マルチプレクサ及び前記ＲＦ信号処理部を制御し、前記伝送ストリームに送出するオブジェクトカルーゼルメッセージを生成し、前記メッセージ内に使われた文字列の伝送コードセットに関する情報を含むメッセージを生成して伝送するＣＰＵを含む。

前記目的を達成するために、本発明の実施例による伝送コードセットのシグナリング方法は、サーバーからオブジェクトカルーゼルメッセージ内に使われた文字列の伝送コードセットに関する情報を含むメッセージを受信する段階、前記受信したメッセージから前記伝送コードセットに関する情報を抽出する段階、前記伝送コードセットに関する情報によって、前記オブジェクトカルーゼルメッセージ内に使われた文字列をデコーディングする段階を含む。
その他の実施例の具体的な事項は詳細な説明及び図面に含まれている。

本発明の伝送コードセットのシグナリング方法及び装置によれば、次のような効果が一つあるいはそれ以上ある。
オブジェクトカルーゼルを使用するシステムで、サーバーとクライアントとの間に伝送コードセットに関する情報を共有することによって、多様な言語で経路情報を表しうる。

本発明の利点及び特徴、そしてこれを達成する方法は添付された図面に基づいて詳細に後述されている実施例を参照すれば明確になる。しかし、本発明は以下で開示される実施例に限定されるものではなく、この実施例から外れて多様な形に具現でき、本明細書で説明する実施例は本発明の開示を完全にし、本発明が属する技術分野で当業者に発明の範ちゅうを完全に報せるために提供されるものであり、本発明は請求項及び発明の詳細な説明により定義されるだけである。一方、明細書全体に亙って同一な参照符号は同一な構成要素を示す。

以下、添付された図面を参照して本発明の望ましい実施例を詳細に説明する。
ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）標準規格は、マルチメディア広域サービスの伝送のために提案された標準規格であり、ＭＰＥＧ−１及びＭＰＥＧ−２ビットストリームを管理するための制御関数及び演算を提供するプロトコルの集合である。オブジェクトカルーゼルの概念は、ＤＳＭ−ＣＣ標準規格で定義され、これはＤＶＢスペックに反映され、以後にデジタル放送のためのミドルウェアスペックであるＤＶＢ−ＭＨＰ、ＯＣＡＰ、ＡＣＡＰに採用された。

図１は、ＤＳＭ−ＣＣモデルの概念を示す図面である。
ＤＳＭ−ＣＣモデルでは、サーバーにより生成されたストリームがクライアントに伝送され、サーバーとクライアントとはいずれもユーザーと見なされる。クライアント１１０は、一般的にマルチメディアコンテンツを消費するセットトップボックス、ＰＣ、個人携帯型端末機のような装置である。サーバー１２０は、マルチメディアコンテンツ及びサービスを提供する存在である。ネットワーク１３０は、ユーザー間の連結を提供する通信要素の集合を意味する。図１は、ユーザーとネットワークとの間（Ｕｓｅｒ−ｔｏ−Ｎｅｔｗｏｒｋ；以下、Ｕ−Ｎ）の情報の運搬のための連結１３６、及びユーザーとユーザーとの間（Ｕｓｅｒ−ｔｏ−Ｕｓｅｒ；以下、Ｕ−Ｕ）情報の運搬のための連結１３４を示している。Ｕ−Ｕ情報のフローは、クライアントとサーバーとの間に使われ、Ｕ−Ｎ情報のフローは、ネットワークとクライアントまたはネットワークとサーバーとの間に使われる。ＤＳＭ−ＣＣは、ＳＲＭ（Ｓｅｓｓｉｏｎ ａｎｄ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ）と呼ばれる論理個体を定義するが、ＳＲＭ １３２は、セッションとネットワーク資源との中央集中管理（Ｃｅｎｔｒａｌｉｚｅｄ Ｍａｎａｇｅｍｅｎｔ）を提供する。

ＤＶＢシステムは、ＤＳＭ−ＣＣスペックのうちＵ−Ｕ連結に関する事項を採用して、多様な伝送媒体を通じたＭＰＥＧ−２伝送ストリーム（Ｔｒａｓｎｐｏｒｔ Ｓｔｒｅａｍ；ＴＳ）を伝送する手段を提供する。元来ＭＰＥＧ−２ＴＳは、ＭＰＥＧ−２ビデオ及びオーディオを含んでいた。データ放送は、ＭＰＥＧ−２基盤ＤＶＢ伝送標準の重要な拡張と見られる。データ放送の例は、衛星、ケーブルまたは地上リンクを通じたソフトウェアダウンロード、ブロードキャストチャンネルを通じたインターネットサービスの伝送、対話形ＴＶ（Ｉｎｔｅｒａｃｔｉｖｅ ＴＶ）などである。データ情報は、いろいろな方法でＭＰＥＧ−２ＴＳ内に含まれて伝送されうる。そのデータの伝送方法は、データパイピング、データストリーミング、多重プロトコルカプセル充填（Ｍｕｌｔｉｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｉｏｎ）、データカルーゼル（Ｄａｔａ Ｃａｒｏｕｓｅｌ）、オブジェクトカルーゼル（Ｏｂｊｅｃｔ Ｃａｒｏｕｓｅｌ）である。

図２は、ＤＶＢサービスにオブジェクトカルーゼルスペックを含んでいる例を示す図面である。
オブジェクトカルーゼルは、ＤＳＭ−ＣＣにより定義され、ディレクトリ客体、ファイル客体及びストリーム客体を使用する放送サーバーから放送受信者への構造化された客体グループの伝送を助けるデータ構造である。実際ディレクトリ及びコンテンツはサーバーに位置する。オブジェクトカルーゼルスペックは、ＤＶＢ互換ブロードキャストネットワークを通じたＤＳＭ−ＣＣユーザー間の客体（Ｕｓｅｒ−ｔｏ−Ｕｓｅｒ Ｏｂｊｅｃｔ）の周期的なブロードキャスティングを要求するデータ放送サービスを支援する。サーバーは、言及された客体をオブジェクトカルーゼルプロトコルを使用するＤＶＢ互換ＭＰＥＧ−２ＴＳに反復的に挿入する。伝送されたディレクトリ客体２１０及びファイル客体２２０は、客体の内容を含む一方、伝送されたストリーム客体２３０は、放送の他のストリームについての参照である。また、ストリーム客体２４０は、特定ストリーム内でブロードキャストされるＤＳＭ−ＣＣイベントに関する情報も含みうる。ＤＳＭ−ＣＣイベントは、普通のストリームデータと共にブロードキャストされ、ＤＳＭ−ＣＣアプリケーションをトリガーするために使われうる。複数のクライアントは、反復的に伝送されるカルーゼルデータを読み取ることによって、まるでサーバー上の客体がクライアントの客体具現であるように装うことによって客体具現を復旧できる。カルーゼルの客体は、クライアントにあたかもサーバーと相互作用する連結があったかのように、アプリケーション及びアプリケーションにより使われるコンテンツに接近する方法を提供する。

オブジェクトカルーゼル内のＵ−Ｕ客体のデータ及び属性は、一つのメッセージに伝送される。このメッセージフォーマットは、ＢＩＯＰ（Ｂｒｏａｄｃａｓｔ Ｉｎｔｅｒ ＯＲＢ Ｐｒｏｔｏｃｏｌ）で記述される。図３は、ＢＩＯＰメッセージのフォーマットを示す。ＢＩＯＰメッセージは、メッセージヘッダ、メッセージサブヘッダ、メッセージ本体で構成される。メッセージヘッダ３１２は、ＢＩＯＰプロトコルのバージョン及びＢＩＯＰメッセージの長さに関する情報を提供する。メッセージサブヘッダ３１４は、客体類型（ファイル、ストリーム、ディレクトリ）、客体キーのような伝送される客体に関する情報を含む。メッセージ本体３１６は、実際Ｕ−Ｕ客体のデータを含む。

ＢＩＯＰメッセージは、データカルーゼルのモジュール３２０の形でブロードキャストされる。一つのモジュール３２０は、一つ以上の連結されたＢＩＯＰメッセージで形成される。モジュール内で各客体は、客体キーで識別される。ＤＳＭ−ＣＣデータカルーゼルスペックによれば、各モジュールは、一つ以上のブロックに断片化される。このブロックは、ＤｏｗｎｌｏａｄＤａｔａＢｌｏｃｋ（以下、ＤＤＢ）３３０メッセージに伝送される。各ＤＤＢメッセージは、順次にＭＰＥＧ−２セクション３４０の形で伝送される。ブロックは、デマルチプレクサのハードウェアフィルタを使用してＴＳから直接獲得されうる。ブロードキャストネットワークから一つの客体を獲得するためには、その客体が含んでいるモジュールをいずれも獲得せねばならない。したがって、モジュールバージョン、モジュールサイズ、ブロックサイズ、タイミング、ブロードキャストチャンネルのようなモジュールの伝送パラメータを知らねばならない。このパラメータは、ＤｏｗｎｌｏａｄＩｎｆｏＩｎｄｉｃａｔｉｏｎ（ＤＩＩ）メッセージに伝送されるので、モジュールを獲得するためにはＤＩＩメッセージを先ず獲得せねばならない。結局、放送ネットワークから客体を獲得する過程は、ＤＩＩメッセージ獲得及びモジュール獲得の２段階を経る。

放送ストリームで伝送される客体を取得するためには、先ずＤＳＩ（ＤｏｗｎｌｏａｄＳｅｒｖｅｒＩｎｉｔｉａｔｅ）メッセージを取得して、その中に含まれているＳｅｒｖｉｃｅＧａｔｅｗａｙＩｎｆｏ構造を解釈する。一つ以上のモジュールが集まってグループを生成し、一つ以上のグループが集まってスーパーグループを生成するが、ＤＳＩメッセージは、スーパーグループ内のグループに関する情報を含む。

図４は、ＳｅｒｖｉｃｅＧａｔｅｗａｙＩｎｆｏ構造の文法を示す図面である。
オブジェクトカルーゼルは、特定サービスドメインを表すが、サービスドメインは、ＤＶＢネットワーク内のＤＳＭ−ＣＣＵ−Ｕ客体の集合で構成される。サービスドメインは、サービスゲートウェイを持つが、サービスゲートウェイは、サービス名及び客体の名称のグラフを受信者に提供する。

クライアントは、ＳｅｒｖｉｃｅＧａｔｅｗａｙＩｎｆｏからＩＯＲ（Ｉｎｔｅｒ Ｏｐｅｒａｂｌｅ Ｒｅｆｅｒｅｎｃｅ）を獲得するが、ＩＯＲ４１０は、客体の位置を表す。ＳｅｒｖｉｃｅＧａｔｅｗａｙＩｎｆｏにあるＩＯＲはＳｅｒｖｉｃｅＧａｔｅｗａｙ、すなわち、あるサービスドメイン内のオブジェクトのグラフのルートオブジェクトの位置情報を持っている。一つのサービスドメインのルートオブジェクトを取得するためには、ルートオブジェクトが含まれているモジュールを獲得せねばならないので、前述したようにＤＩＩメッセージ及びＤＤＢメッセージを順次に獲得して、ルートオブジェクト（ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅ）を取得する。

図５は、ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅの形式を示す図面である。
ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅは、ルートオブジェクトに属するオブジェクトの位置（ＩＯＲ）と名称、属性などを持っている。ＩＯＲフィールド５１０がオブジェクトの位置情報を含み、ｉｄ＿ｄａｔａ＿ｂｙｔｅフィールド５２０がオブジェクトの名称情報を持つ。オブジェクトＫｉｎｄ＿ｄａｔａフィールド５４０は、メッセージの類型を区分する値を持っており、ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅは、この値として“ｄｉｒ”を持つ。

一方、オブジェクトＫｉｎｄ＿ｄａｔａフィールド５４０の値が“ｓｒｇ”である場合、このメッセージはＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージとなり、このメッセージは、ルートオブジェクトに属するオブジェクト情報を持っている。したがって、ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージは、ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅとｏｂｊｅｃｔＫｉｎｄ＿ｄａｔａフィールド５４０との値を除いては、同じフォーマットを持つ。ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージのｓｅｒｖｉｃｅＣｏｎｔｅｘｔＬｉｓｔ＿ｄａｔａ＿ｂｙｔｅフィールド５３０は、ＣＯＲＢＡストリングの伝送コードセットに関する情報を含むＣＯＲＢＡ ＧＩＯＰコードセットコンテキスト構造を含みうる。ＣＯＲＢＡ ＧＩＯＰコードセットコンテキスト構造については、図７を参照して後述する。

図６は、ＢＩＯＰ：：ＦｉｌｅＭｅｓｓａｇｅの形式を示す図面である。
ＢＩＯＰ：：ＦｉｌｅＭｅｓｓａｇｅは、実際ファイルコンテンツを含むメッセージであって、データメッセージである。

クライアントは、このような一連のＩＯＲ取得過程を通じて所望のオブジェクトを取得する。

図７は、本発明の実施例によるサーバーの構成を示すブロック図である。
本実施例によるサーバー７００は、データをエンコーディングする部分として映像エンコーダ７１０、音声エンコーダ７２０を含み、マルチプレクサ７３０、ＲＦ信号処理部７４０、及びＴＳ出力部７５０、及びＣＰＵ７６０からなる。映像エンコーダ７１０は、映像データをエンコーディングし、映像ビットストリームを生成してマルチプレクサ７３０に提供する。音声エンコーダ７２０は、音声データをエンコーディングし、音声ビットストリームを生成してマルチプレクサ７３０に提供する。マルチプレクサ７３０は、各エンコーダによりエンコーディングされたビットストリームをマルチプレクシングし、一つまたは複数のＴＳを生成してＲＦ信号処理部７４０に提供する。ＲＦ信号処理部７４０は、ＴＳを出力可能な信号に変調してＴＳ出力部７５０に伝達する。ＴＳ出力部７５０は、伝達されたＴＳを伝送する。ＣＰＵ７６０は、各装置の動作を制御し、ＴＳ上に送出するＤＳＩメッセージ、ＤＩＩメッセージ、ＤＢＢメッセージなどのオブジェクトカルーゼルメッセージを生成する。本実施例によるサーバーのＣＰＵは、生成されるオブジェクトメッセージ内で使われる文字列で、ＩＳＯ ８８５９−１ではない他の伝送コードセットを使用する場合、伝送コードセットに関する情報を挿入したＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージを生成する。

オブジェクトカルーゼルでの文字列伝送は、ＣＯＲＢＡ／ＩＩＯＰ ２．１で定義されたＣＯＲＢＡストリングによる。ＣＯＲＢＡ／ＩＩＯＰ ２．１によれば、ＣＯＲＢＡストリングでは、伝送コードセットに関する情報が明示されていなければ、ＩＳＯ ８８５９−１（ＩＳＯ Ｌａｔｉｎ１）による。したがって、現在オブジェクトカルーゼルを使用するＤＶＢ ＭＨＰ、ＯＣＡＰ、ＡＣＡＰなどでは、ファイル名及びディレクトリ名のために、ＩＳＯ ８８５９−１を基本伝送コードセットとして使用している。したがって、ＣＯＲＢＡストリングで他の伝送コードセット、例えば、ＵＴＦ−８を使用するためには、使われた伝送コードセットに関する情報をメッセージに伝送する必要がある。

特定ＣＯＲＢＡストリングインスタンスに適用される文字エンコーディング規則の決定は、次の３つのパラメータに基づく。１）ストリングインスタンスが狭ストリング（Ｎａｒｒｏｗ Ｓｔｒｉｎｇ）または広ストリング（Ｗｉｄｅ Ｓｔｒｉｎｇ）であるか、２）狭文字伝送コードセット（Ｎａｒｒｏｗ Ｃｈａｒ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｄｅ Ｓｅｔ；以下、ＴＣＳ−Ｃ）の値、３）広文字伝送コードセット（Ｗｉｄｅ Ｃｈａｒ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｄｅ Ｓｅｔ；以下、ＴＣＳ−Ｗと咸）の値。ＴＣＳ−Ｃの値が知られていない場合、基本値であるＩＳＯ ８８５９−１が適用される。ＴＣＳ−Ｗ値が知られていない場合には基本値がないので、広ストリングをエンコーディングするか、またはデコーディングすれば、エラーが発生する。次は、ＧＩＯＰ Ｃｏｄｅ Ｓｅｔ Ｓｅｒｖｉｃｅ Ｃｏｎｔｅｘｔ構造のＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）表現である。

Ｍｏｄｕｌｅ ＣＯＮＶ＿ＦＲＡＭＥ｛
Ｔｙｐｅｄｅｆ ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＣｏｄｅＳｅｔＩｄ；
Ｓｔｒｕｃｔ ＣｏｄｅＳｅｔＣｏｎｔｅｘｔ｛
ＣｏｄｅＳｅｔＩｄ ｃｈａｒ＿ｄａｔａ；
ＣｏｄｅＳｅｔＩｄ ｗｃｈａｒ＿ｄａｔａ；
｝
｝

ＣＯＲＢＡ／ＩＩＯＰ ２．１によれば、ＴＣＳ−Ｃ及びＴＣＳ−Ｗの値はＧＩＯＰ Ｃｏｄｅ Ｓｅｔ Ｓｅｒｖｉｃｅ Ｃｏｎｔｅｘｔを使用して割当てられる。したがって、本発明による一実施例では、オブジェクトカルーゼルのＣＯＲＢＡストリングの伝送コードセットに関する情報をクライアントに知らせるために、ＣＯＲＢＡ／ＩＩＯＰ ２．１のＧＩＯＰ Ｃｏｄｅ Ｓｅｔ Ｓｅｒｖｉｃｅ Ｃｏｎｔｅｘｔ構造を、オブジェクトカルーゼルのＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージのｓｅｒｖｉｃｅＣｏｎｔｅｘｔＬｉｓｔ＿ｄａｔａ＿ｂｙｔｅフィールド５３０に選択的に挿入できる。すなわち、ＣＯＲＢＡストリングのためにＩＳＯ ８８５９−１以外の伝送コードセット、例えば、ＵＴＦ−８伝送コードセットを使用しようとする場合、ＴＣＳ−Ｃ値をＵＴＦ−８と設定し、ＴＣＳ−Ｗ値は定義しないＧＩＯＰ Ｃｏｄｅ Ｓｅｔ Ｓｅｒｖｉｃｅ Ｃｏｎｔｅｘｔ構造を、ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージのｓｅｒｖｉｃｅＣｏｎｔｅｘｔＬｉｓｔ＿ｄａｔａ＿ｂｙｔｅフィールド５３０に挿入できる。さらに、オブジェクトカルーゼルメッセージに現れるあらゆるＣＯＲＢＡストリングは、狭ストリングのＣＯＲＢＡ定義によって解釈されうる。

図８は、本発明の実施例によるクライアントの構成を示すブロック図である。
図８は、データ放送において、クライアントの一実施例としてセットトップボックスの構成を示している。本実施例によるセットトップボックス８００は、システムインターフェース８１０、デマルチプレクサ（Ｄｅｍｕｌｔｉｐｌｅｘｅｒ）８２０、デコーディング部として映像デコーダ８３０、音声デコーダ８４０、ＣＰＵ８８０、メモリ８５０、映像出力部８６０、及び音声出力部８７０を含む。

システムインターフェース８１０は、低い周波数に変換された映像音声信号を受信してＴＶに送出するための映像音声信号を変換し、変調された映像音声信号をデスクランブリングして生成されたＴＳを、デマルチプレクサ８２０に伝達する。デマルチプレクサ８２０は、いろいろなＰＥＳがマルチプレクシングされたＴＳから、ユーザーにより選択されたプログラムに該当するＰＥＳパケットを、フィルタを利用して選択する。映像デコーダ８３０及び音声デコーダ８４０は、デマルチプレクサにより選択されたＰＥＳをデコーディングして出力可能な形式に変換して、映像出力部８６０及び音声出力部８７０を通じてデータ放送を出力する。メモリ８５０は、デマルチプレクサにより選択されたＰＥＳまたはデコーディングされた映像信号または音声信号を保存する。ＣＰＵ８８０は、他の構成部分の動作を制御し、サーバーから伝送されるオブジェクトカルーゼルメッセージ（ＤＳＩメッセージ、ＤＩＩメッセージ、ＤＢＢメッセージなど）を解釈する。特に、ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージを受信した場合、これよりオブジェクトカルーゼルメッセージ内に使われた文字列の伝送コードセットに関する情報を抽出して、伝送コードセットに該当する適切なデコーダを使用して、メッセージ内の文字列をデコーディングする。

図７及び図８の各構成部分は、ハードウェア及びソフトウェアいずれでも具現できるということは、当業者に明らかである。

図９は、本発明の実施例による伝送コードセットに関する情報を共有する過程を示すフローチャートである。
サーバーがオブジェクトカルーゼルメッセージ内に使われたＣＯＲＢＡストリングの伝送コードセットに関する情報を含むＧＩＯＰコードセットサービスコンテキストを、ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージのｓｅｒｖｉｃｅＣｏｎｔｅｘｔＬｉｓｔ＿ｄａｔａ＿ｂｙｔｅフィールド５３０に挿入して伝送（Ｓ９１０）すれば、クライアントは、ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージを受信（Ｓ９２０）する。クライアントのＣＰＵ８８０は、ＢＩＯＰ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージからＧＩＯＰコードセットサービスコンテキストを抽出して、使われた伝送コードセット情報を抽出（Ｓ９３０）する。クライアントのＣＰＵ８８０は、抽出された伝送コードセット情報によって、適切な文字デコーダを利用してメッセージ内の経路名をデコーディング（Ｓ９４０）する。

以上、添付図を参照して本発明の実施例を説明したが、本発明が属する技術分野で当業者ならば本発明がその技術的思想や必須特徴を変更せずとも他の具体的な形に実施されうるということが理解できるであろう。したがって、前述した実施例は全ての面で例示的なものであって、限定的なものではないと理解せねばならない。

ＤＳＭ−ＣＣモデルの概念を示す図である。 ＤＶＢサービスにオブジェクトカルーゼルスペックを含んでいる例を示す図である。 ＢＩＯＰメッセージのフォーマットを示す図である。 ＤＳＩメッセージのＳｅｒｖｉｃｅＧａｔｅｗａｙＩｎｆｏ（）のフォーマットを示す図である。 ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅのフォーマットを示す図である。 ＢＩＯＰ：：ＦｉｌｅＭｅｓｓａｇｅのフォーマットを示す図である。 本発明の実施例によるサーバーの構成を示すブロック図である。 本発明の実施例によるクライアントの構成を示すブロック図である。 本発明の実施例による伝送コードセットのシグナリング方法を示すフローチャートである。

Claims (16)

1. 放送（ｂｒｏａｄｃａｓｔｉｎｇ）を通してデータストリームを受信するクライアントにおいて、
   データとＢＩＯＰ（Ｂｒｏａｄｃａｓｔ Ｉｎｔｅｒ ＯＲＢ Ｐｒｏｔｏｃｏｌ）メッセージを含むオブジェクトカルーセルを受信する受信部と、
   前記ＢＩＯＰメッセージのＢＩＯＰ：ServiceGatewayメッセージに前記ＢＩＯＰメッセージのオブジェクトに対する経路名を表す文字列を解釈するための命令を提供する伝送コードセット情報を前記ＢＩＯＰ：ServiceGatewayメッセージのうちＧＩＯＰ(General Inter ORB Protocol)コードセットサービスコンテキストから抽出するプロセッサ、および
   前記伝送コードセット情報によって提供される命令に基づいて前記文字列をデコーディングするデコーダを含み、
   前記文字列は、ＣＯＲＢＡ／ＩＩＯＰ２．１によって定義されたＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）文字列であり、前記プロセッサは前記デコーディングされた文字列に基づき前記ＢＩＯＰメッセージのうち前記オブジェクトに対する経路名を決定することを特徴とするクライアント。
2. 前記オブジェクトカルーセルは、ＩＳＯ−ＩＥＣ１３８３８−６によって定義されることを特徴とする、請求項１に記載のクライアント。
3. 前記プロセッサは、前記ＢＩＯＰ：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージでＣＯＲＢＡ／ＩＩＯＰ２．１のＧＩＯＰコードセットサービスコンテキストにある前記伝送コードセット情報を抽出することを特徴とする、請求項１に記載のクライアント。
4. 前記伝送コードセット情報は、前記ＧＩＯＰコードセットサービスコンテキストのｃｈａｒ＿ｄａｔａフィールドで表現されることを特徴とする、請求項３に記載のクライアント。
5. 前記伝送コードセット情報は、ＩＳＯ８８５９−１またはＵＴＦ−８に基づいてエンコーディングされた文字列を表すことを特徴とする、請求項４に記載のクライアント。
6. 前記デコーダは、前記伝送コードセット情報にエンコーディングシステムが明示的に記述されなければＩＳＯ８８５９−１に基づいて前記エンコーディングされた文字列をデコーディングする、請求項５に記載のクライアント。
7. Ｗｉｄｅ Ｃｈａｒ伝送コードセットのための前記ＧＩＯＰコードセットサービスコンテキストが定義されないことを特徴とする、請求項６に記載のクライアント。
8. ｗｃｈａｒ＿ｄａｔａフィールドが前記メッセージ内にある文字列のエンコーディングシステムを決定するに使用されないことを特徴とする、請求項７に記載のクライアント。
9. 放送(broadcasting)を通じてデータストリームを受信する方法において、
   データとＢＩＯＰ（Broadcast Inter ORB Protocol）メッセージを含むオブジェクトカルーセルを受信する段階と、
   前記ＢＩＯＰメッセージのＢＩＯＰ：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージ内に前記ＢＩＯＰメッセージのオブジェクトに対する経路名を表す文字列を解釈するための命令を提供する伝送コードセット情報が存在すれば、前記ＢＩＯＰ：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージのうちＧＩＯＰコードセットサービスコンテキストから前記伝送コードセット情報を抽出する段階、および
   前記決定された情報によって前記文字列をデコーディングする段階を含み、
   前記文字列はＣＯＲＢＡ／ＩＩＯＰ２．１によって定義されたＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）文字列であり、前記デコーディングされた文字列に基づき前記ＢＩＯＰメッセージのうち前記オブジェクトに対する経路名が決定されることを特徴とする、データストリーム受信方法。
10. 前記オブジェクトカルーセルはＩＳＯ−ＩＥＣ１３８３８−６によって定義されることを特徴とする、請求項９に記載のデータストリーム受信方法。
11. 前記伝送コードセット情報を抽出する段階は、
    前記ＢＩＯＰ：ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージでＣＯＲＢＡ／ＩＩＯＰのＧＩＯＰコードセットサービスコンテキストにある前記情報を抽出することを特徴とする、請求項９に記載のデータストリーム受信方法。
12. 前記情報は、前記ＧＩＯＰコードセットサービスコンテキストのｃｈａｒ＿ｄａｔａフィールドで表現されることを特徴とする、請求項１１に記載のデコーディング方法。
13. 前記情報はＩＳＯ ８８５９−１またはＵＴＦ−８を基礎でエンコーディングされた前記文字列を表すことを特徴とする、請求項１２に記載のデータストリーム受信方法。
14. 前記情報に前記エンコーディングシステムが明示的に記述されなければＩＳＯ−８８５９−１に基づいて前記文字列をデコーディングする段階をさらに含む、請求項１３に記載のデータストリーム受信方法。
15. Ｗｉｄｅ Ｃｈａｒ伝送コードセットのための前記ＧＩＯＰコードセットサービスコンテキストが定義されないことを特徴とする、請求項１４に記載のデータストリーム受信方法。
16. ｗｃｈａｒ＿ｄａｔａフィールドが前記メッセージ内にある文字列のエンコーディングシステムを決定するに使用されないことを特徴とする、請求項１５に記載のデータストリーム受信方法。

Images