(57)【要約】  デジタル受信装置のソフトウェアのアップデート方法は、ソフトウェアのアップデートの目的受信装置の拡張された識別子及び拡張されたソフトウェアバージョンを含む情報を、データサービス報知を利用してブロードキャストするステップ、及びソフトウェア伝送条件が満足する時、前記拡張された識別子を持つ受信装置に前記ソフトウェアを伝送するステップを含む。本発明によれば、既存のデジタルデータ放送の標準をほとんど修正せずにＵＵＩＤを使用して、受信装置を唯一区別してソフトウェアのアップデートサービスを提供できる。
2007515102.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアのアップデートの目的受信装置の拡張された識別子と拡張されたソフトウェアバージョンとを含む情報をデータサービス報知を利用してブロードキャストするステップと、
ソフトウェア伝送条件が満足する時、前記拡張された識別子を持つ受信装置に前記ソフトウェアを伝送するステップと、を含む拡張された識別子を利用したデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項２】
前記拡張された識別子は、ユニバーサルにユニークな識別子である請求項１に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項３】
前記拡張されたソフトウェアバージョンは、少なくとも２個のサブバージョンからなる請求項１に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項４】
前記拡張されたソフトウェアバージョンは、少なくとも２個のサブバージョンからなる請求項２に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項５】
前記サブバージョンは、少なくとも主バージョンと副バージョン及びマイクロバージョンの３階層のバージョン体系からなり、前記主バージョンと副バージョン及びマイクロバージョンはそれぞれ１６ビットで表示される請求項３に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項６】
前記サブバージョンは、少なくとも主バージョンと副バージョン及びマイクロバージョンの３階層のバージョン体系からなり、前記主バージョンと副バージョン及びマイクロバージョンは、それぞれ１６ビットで表示される請求項４に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項７】
前記データサービス報知は、ソフトウェアのアップデート時期情報を含んでおり、前記ソフトウェア伝送条件は、前記ソフトウェアのアップデート時期になる時に満足される請求項１に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項８】
前記データサービス報知は、ソフトウェアのアップデート時期情報を含んでおり、前記ソフトウェア伝送条件は、前記ソフトウェアのアップデート時期になる時に満足される請求項２に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項９】
前記データサービス報知に含まれたソフトウェアのアップデート時期情報は、アップデート時期が所定の時間内になされる場合と、所定の時間が過ぎた後になされる場合のうち少なくとも一つに関連した情報を含む請求項７に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項１０】
前記データサービス報知に含まれたソフトウェアのアップデート時期情報は、アップデート時期が所定の時間内になされる場合と、所定の時間が過ぎた後になされる場合のうち少なくとも一つに関連した情報を含む請求項８に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【請求項１１】
前記ソフトウェアは、拡張された識別子と前記ソフトウェアバージョンを含む前記情報と共に、サービス叙述フレームワークを使用して信号化する請求項１に記載のソフトウェアのアップデート方法。
【請求項１２】
前記ソフトウェアは、拡張された識別子と前記ソフトウェアバージョンを含む前記情報と共に、サービス叙述フレームワークを使用して信号化する請求項２に記載のソフトウェアのアップデート方法。
【請求項１３】
拡張された識別子を利用したデジタル放送受信装置のソフトウェアのアップデート方法を行うためのコンピュータで読み取り可能なプログラムを記録したコンピュータで読み取り可能な記録媒体において、前記方法は、
ソフトウェアのアップデートの目的受信装置の拡張された識別子及び拡張されたソフトウェアバージョンを含む情報を、データサービス報知を利用してブロードキャストするステップと、
ソフトウェア伝送条件が満足する時、前記拡張された識別子を持つ受信装置に前記ソフトウェアを伝送するステップと、を含む記録媒体。
【請求項１４】
前記拡張された識別子は、ユニバーサルにユニークな識別子である請求項１３に記載のデジタル放送受信装置のソフトウェアのアップデート方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル放送で受信装置のソフトウェアのアップグレード方法に係り、より詳細には、受信装置のうちソフトウェアのアップデート対象となる受信装置を区別したソフトウェアのアップデート方法に関する。
【背景技術】
【０００２】
最近、デジタル放送に関する関心が増幅しつつある。デジタル放送は、文字通りビデオ、オーディオ及びデータなどあらゆることをデジタル処理した後、デジタル伝送方式によって伝送する放送形態をいい、これは、既存のアナログ放送と区別される概念である。デジタル処理とは、高度のデジタル技術を利用してアナログ信号を０と１で構成されたデジタル信号に変換することをいうが、変換された信号は、他の情報と共に圧縮された後、デジタル伝送方式によって伝送される。伝送された信号は、セットトップボックスとも呼ばれる受信装置で再び元来のビデオ及びオーディオに復元される。
【０００３】
デジタル技術は、一般的にアナログ信号に比べて雑音に強くて送信電力が少なく、エラー訂正技術を使用できて伝送、コピー、及び蓄積による劣化が少ないという特徴を持つ。また、ＭＰＥＧ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）のような圧縮アルゴリズムを使用できるので、ビデオおよび音声信号を大幅に圧縮して情報量を減らすことができる。それ以外にも情報の検索、加工、及び編集が容易であるという点や、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｒｇｒａｔｉｏｎ）技術の活用が容易であるという特徴がある。デジタル放送は、デジタル技術のこのような長所を持っているために、雑音に強くて効率的な情報伝送ができるなど、既存アナログＴＶに比べて多様な長所を持つ。現在実用化されるか、実用化段階にあるデジタル放送は、画質面で既存のアナログＴＶより２倍以上鮮明な高画質放送が支援される。音質面では、５．１チャンネルの立体音響が支援されて臨場感のある音響を聴取できる。画面比率は１６：９であって、映画館と同じ比率のワイド画面を基本としているので、デジタルＴＶで映画を鑑賞する時にフルモードで映画を見ることができる。また、デジタルＴＶは、ＰＣはもとよりデジタル方式で信号を処理するデジタル多機能ディスク（ＤＶＤ）プレーヤー、デジタルカムコーダ、デジタルＶＣＲなどの多様な家電機器と直列インターフェースでデータを送受信できる。最近サービス段階にある双方向ネットワークを利用したデジタル放送サービスは、インターネット検索はもとよりホームショッピング、ホームバンキングなど多様な双方向付加サービスを提供できる。
【０００４】
図１は、対話形デジタル放送システムの構成を示す機能性ブロック図である。
デジタル放送システムは、大きく、デジタル放送サービス提供者１００とデジタル放送サービス提供者１００が提供するデジタル放送を受信する複数の受信装置２００とで構成される。デジタル放送サービス提供者１００は、デジタル放送信号を送出する放送局がこれに該当する。デジタル放送サービス提供者１００は、自体的に製作したコンテンツを放送するか、または、コンテンツ提供者（図示せず）が製作した放送用コンテンツを放送する。デジタル放送サービス提供者１００は、アナログ放送のように、受信装置２００への一方的データ伝達のみが可能なブロードキャスト媒体を通じた放送をすることもでき、双方向ネットワークを通じた双方向サービスを提供することもできる。双方向媒体を利用する場合に、ユーザは、双方向デジタル放送用受信装置２００を利用して、デジタル放送サービス提供者１００に注文型ビデオ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サービスを要請することもでき、ＴＶ視聴中に俳優が着た服やアクセサリーの購入を要請することもできる。
【０００５】
現在デジタル放送方式は、米国のデジタルＴＶ標準を開発して研究するためのＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ）により提案されたＡＴＳＣ方式と、ヨーロッパ放送連盟（Ｅｕｒｏｐｅ Ｂｒｏａｄｃａｓｔｉｎｇ Ｕｎｉｏｎ；ＥＢＵ）により誕生したＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）方式とに大別される。
【０００６】
ＤＶＢは、直交周波数分割多重化（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ；以下、ＯＦＤＭ）方式を使用しており、ＤＱＰＳＫ（Ｄｉｆｆｅｒｅｎｔｉａｌ Ｑｕａｄｒａｔｕｒｅ Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）またはｎ−ＱＡＭ（Ｑｕａｄｒａｔｕｒｅ Ａｍｐｌｉｔｕｄｅ Ｍｏｄｕｌａｔｉｏｎ）方式で変調する。ＤＶＢ放送システムは、基本的にソースコーディング及び多重化部と、チャンネルコーディング及び変調部と、伝送媒体、復調及びデコーディング部、及びディスプレイで構成される。ソースコーディング及び多重化部は、デジタル映像及び音響を所望の伝送速度に圧縮して必要帯域幅を減らすが、そのためにＭＰＥＧ−２を使用する。チャンネルコーディング及び変調部は、チャンネルコーディングされたＭＰＥＧ−２ストリームに剰余データを追加して、信号の伝送中に発生しうるエラーに備える。チャンネルコーディングが終われば、チャンネルコーディングされた信号を伝送媒体の状態に合わせて適当に変調する。伝送媒体は、衛星、ケーブル、地上波など多様な形態がある。復調及びデコーディング部は、伝送媒体を通じて伝送されたＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｃｙ）信号から基底帯域信号を復元する。ディスプレイ部は、復元された信号をディスプレイする。
【０００７】
ＡＴＳＣは、ビットストリームコンテンツとトランスポート、そして６ＭＨｚ ＲＦチャンネルでのデジタル伝送を規定している地上波伝送標準であって、公式的なビット伝送速度は１９．４Ｍｂｐｓである。ＡＴＳＣシステムは、多重画像フォーマット、デジタルオーディオ／ビデオ圧縮、パケット化及びシングルキャリアを利用する８ＶＳＢ（Ｖｅｒｓｔｉｌｅ Ｓｉｄｅ Ｂａｎｄ）方式のＲＦ変調方式を使用する。
【０００８】
デジタル放送を通じてデータ放送も可能であるが、現在大韓民国データ放送で地上波デジタルＴＶの伝送標準はＡＴＳＣ−Ａ／９０であり、サービス標準はＡＴＳＣ−ＤＡＳＥ（ＤＴＶ Ａｐｐｌｉｃａｔｉｏｎ Ｓｏｆｔｗａｒｅ Ｅｎｖｉｒｏｎｍｅｎｔ）である。デジタル衛星放送の伝送標準は、ヨーロッパ通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ；ＥＴＳＩ）によるＥＴＳＩ−ＥＮ ３０１ １９２であり、サービス標準はＤＶＢ−ＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ）である。デジタルケーブル放送の場合には、ＯｐｅｎＣａｌｂｅ−ＯＣＡＰ（ＯｐｎｅＣａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）であるが、ＯＣＡＰは、ＭＨＰ基盤であって、ＭＨＰとのコンテンツ互換が可能である。ＡＴＳＣ−ＤＡＳＥとＤＶＢ−ＭＨＰとのコンテンツ互換は、現在は不可能であり、これについて研究中である。
【０００９】
ＡＴＳＣデータ放送で伝送プロトコルは、ＡＴＳＣ−Ａ／９０の規格（ｗｗｗ．ａｔｓｃ．ｏｒｇ／ｓｔａｎｄａｒｄｓ／Ａ９０−ｗｉｔｈ−ａｔｔ．ｐｄｆ）による。データは、プロトコルカプセル化（Ｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｉｏｎ）された後、ＭＰＥＧ−２伝送ストリーム構造中に多重化されて伝送される。サービスプロトコルはＡＴＳＣ−ＤＡＳＥ規格によるが、受信装置の製造企業は、固有のハードウェアプラットフォーム、運用体系、デバイスドライバを提供可能にする。
【００１０】
現在のＡＴＳＣデータ放送を通じて、受信装置の製造企業は特定のモデルの受信装置のソフトウェアをアップデートできるが、総１６ビットのモデルフィールドのみでは、多くの受信装置の製造企業の多くのモデルの受信装置をいちいち区別するには足りない。また同じモデルの受信装置であっても、受信装置に搭載されたソフトウェアのバージョンは時期別に若干ずつ異なる。また、ソフトウェアのバージョンを区別するための１６ビットのバージョンフィールドだけでは、ソフトウェアのバージョンを細部的に区別し難い。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、前述した問題点に鑑みてなされたものであり、本発明は、デジタル放送受信装置を区別できる拡張されたモデルフィールドと、アップデートのためのソフトウェアのバージョンをさらに細部的に区別可能にする拡張されたバージョンフィールドとを定義し、拡張されたモデルフィールド及びバージョンフィールドを利用して、アップデート対象となる受信装置を区別してソフトウェアのアップデートサービス方法を提供することをその技術的課題とする。
【課題を解決するための手段】
【００１２】
前記技術的課題を達成するために、本発明によるデジタル放送受信装置のソフトウェアのアップデート方法は、ソフトウェアのアップデートの目的受信装置の拡張された識別子と拡張されたソフトウェアバージョンを含む情報をデータサービス報知を利用してブロードキャストするステップと、ソフトウェア伝送条件が満足する時、前記拡張された識別子を持つ受信装置に前記ソフトウェアを伝送するステップと、を含む。
【００１３】
望ましくは、前記拡張された識別子は、ユニバーサルにユニークな識別子（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ；ＵＵＩＤ）を使用する。また、前記拡張されたソフトウェアバージョンは、少なくとも２個のサブバージョンからなり、前記サブバージョンは、少なくとも主バージョンと副バージョン及びマイクロバージョンの３階層のバージョン体系からなることが望ましい。
【００１４】
前記データサービス報知は、ソフトウェアのアップデート時期情報を含んでおり、前記ソフトウェア伝送条件は、前記ソフトウェアのアップデート時期になる時に満足されることを特徴とする。前記データサービス報知に含まれたソフトウェアのアップデート時期情報は、アップデート時期が所定の時間内になされる場合と、所定の時間が過ぎた後になされる場合のうち少なくとも一つに関連する。
【発明を実施するための最良の形態】
【００１５】
以下、添付された図面を参照して本発明の望ましい実施形態を詳細に説明する。
図２は、本発明の実施形態によるソフトウェアのアップデート過程を示すフローチャートである。
【００１６】
まず、セットトップボックス製造企業がソフトウェアのアップデートサービスを受ける対象となるセットトップボックスを決定する。特定モデルのセットトップボックスのソフトウェアをアップデートする必要があるか、特定の期間に販売されたセットトップボックスのソフトウェアをアップデートする必要がある場合に、該当セットトップボックスを他のセットトップボックスと区別できるように、セットトップボックス製造企業は該当セットトップボックス固有の識別子を確認する。セットトップボックス製造企業は、セットトップボックスを生産する時に個別的な装置やモデルに固有な識別子を付与するが、本発明の実施形態で固有の識別子は、マイクロソフト社で提案したＵＵＩＤを使用する。ＵＵＩＤは、マイクロソフトがワード文書のような実体に固有な正体性を付与するためにプログラムで生成する固有番号を称する用語である。従来の大部分のプログラミング言語は、識別子として名前を使用したが、このような名前は、自身の領域範囲内で唯一でなければならなかった。それで登場したのが、ＧＵＩＤ（Ｇｏｌｂａｌ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）とＵＵＩＤとであるが、二つは同じ意味である。ＧＵＩＤあるいはＵＵＩＤは、１２８ビットサイズの構造体であり、ＵｕｉｄＣｒｅａｔｅ（）関数で生成すれば、常に唯一のＩＤを生成させる。このような唯一性は全世界的であり、時間と場所にこだわらないという特徴を持つ。したがって、ＵＵＩＤを使用することによって、セットトップボックス製造企業は、他のセットトップボックス製造企業のセットトップボックスと区別される固有な識別子を持つセットトップボックスを製造できる。
【００１７】
セットトップボックス製造企業は、ソフトウェアのアップデート対象となるセットトップボックスを決定すれば、アップデート時期と、アップデート対象となるセットトップボックスのＵＵＩＤ、及びソフトウェアのバージョンをデジタル放送サービス企業に提供する。デジタル放送サービス提供者は、アップデート時期と、アップデート対象セットトップボックスのＵＵＩＤ、及びソフトウェアのバージョンについての情報をブロードキャストするアップデート予告を通じて視聴者に知らせる。セットトップボックスは、ブロードキャストされるアップデート予告に含まれたＵＵＩＤが自身のＵＵＩＤと一致し、ソフトウェアのバージョンが現在自身のバージョンより高い場合に、セットトップボックスはアップデート時点を記憶して該当時点になった時にアップデートを準備する。
【００１８】
アップデート時点になれば、セットトップボックス製造企業はアップデートソフトウェアをデジタル放送サービス提供者に提供し、デジタル放送サービス提供者はソフトウェアをブロードキャストする。ブロードキャストされたソフトウェアを受信したセットトップボックスはソフトウェアのアップデートをする。報知（ａｎｎｏｕｎｃｅｍｅｎｔ）と信号化（ｓｉｇｎａｌｉｎｇ）及びカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）については、図４ないし図７を通じて説明する。
【００１９】
図３は、本発明の他の実施によるソフトウェアのアップデート過程を示すフローチャートである。
図３のソフトウェアのアップデートは、双方向ネットワークを基盤とする。まずセットトップボックス製造企業は、ソフトウェアのアップデート対象となるセットトップボックスを決定して該当セットトップボックスのＵＵＩＤを確認する。次いで、セットトップボックス製造企業は、デジタル放送サービス提供者にソフトウェアと、対象セットトップボックスのＵＵＩＤ、及びソフトウェアのバージョンについての情報を提供する。デジタル放送サービス提供者は、ブロードキャストでアップデート予告をして、セットトップボックスにアップデート対象となるセットトップボックス及びソフトウェアのバージョンを知らせる。アップデート予告を受けたセットトップボックスは、自身のＵＵＩＤとアップデート予告のＵＵＩＤとが同一であるかどうかと、ソフトウェアのバージョンが新バージョンであるかどうかを判断する。セットトップボックスは、自信に対するソフトウェアアップグレード予告である場合にデジタル放送サービス提供者にアップデート要求をし、アップデートを要求されたデジタル放送サービス提供者はソフトウェアをセットトップボックスに伝送する。ソフトウェアを伝送されたセットトップボックスは、ソフトウェアをアップデートする。図３のデジタル放送サービス提供者がアップデート予告をする時、アップデート対象となるソフトウェアのアドレス（ＵＲＬ）を共に送ることができるが、このような場合にセットトップボックスは、該当アドレスからソフトウェアを伝送されてソフトウェアをアップデートする。
【００２０】
図４は、ＡＴＳＣデータブロードキャスト標準（Ａ／９０）のＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄａｎｄ Ｃｏｎｔｒｏｌ）の互換性叙述子（Ｃｏｍｐａｔｉｂｉｌｉｔｙ Ｄｅｓｃｒｉｐｔｏｒ）の構文を示す表である。図４でｕｉｍｓｂｆは、ｕｎｓｉｇｎｅｄ ｉｎｔｅｇｅｒ ｍｏｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔ ｆｉｒｓｔの略字である。
【００２１】
互換性叙述子でｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、１６ビットを持つフィールドであって、ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈを表す長さを除外したｄｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドを含む叙述子の総長さを示す。ｄｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドは、１６ビットフィールドであって、叙述子の数を特定する。ｄｅｓｃｒｉｐｔｏｒＴｙｐｅは、８ビットフィールドであって、ハードウェアまたはソフトウェアのタイプを区別するところに使われる。ｄｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは８ビットフィールドであって、ｄｅｓｃｒｉｐｔｏｒＴｙｐｅ及びｄｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈを除外した総長さを示すフィールドである。
【００２２】
ｓｐｅｃｉｆｉｅｒＴｙｐｅは、８ビットフィールドであって、ｓｐｅｃｉｆｉｅｒＤａｔａフィールドのフォーマットを区別するところに使われるフィールドである。ｓｐｅｃｉｆｉｅｒＤａｔａは、２４ビットフィールドであって、一つの組織を唯一に識別する。このフィールドに割り当てられた値は、ｓｐｅｃｉｆｉｅｒＴｙｐｅフィールドに従属的である。
【００２３】
ｍｏｄｅｌは、１６ビットフィールドであって、組織により定義された多様なモデル間を区別するために使われるが、本発明の実施形態は、ｍｏｄｅｌフィールドを拡張して１２８ビットのＵＵＩＤを使用するが、これについては後述する。ｖｅｒｓｉｏｎは、１６ビットフィールドであって、組織により定義されたモデルの他のバージョン間を区別するために使われる。本発明の実施形態は、ｖｅｒｓｉｏｎフィールドを拡張してバージョンを細分化して区別可能にするが、これについては後述する。
【００２４】
ｓｕｂＤｅｓｃｒｉｐｔｏｒＣｏｕｎｔは８ビットフィールドであって、ｓｕｂＤｅｓｃｒｉｐｔｏｒの数を代表するフィールドである。
【００２５】
本発明の実施形態で（１）ｄｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドは、２個の叙述子を持つということを表示するように０×０００２値を持つ。（２）ｄｅｓｃｒｉｐｔｏｒＴｙｐｅフィールドは、システムハードウェアを示すように０×０１値を持つ。（３）ｓｐｅｃｉｆｉｅｒＴｙｐｅフィールドは、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）ＯＵＩを意味するように０×０１値を持つ。（４）ｓｐｅｃｉｆｉｅｒＤａｔａフィールドの最初の叙述子は、ＩＥＥＥがソフトウェアのアップデートが意図される端末装置の製造企業のために割り当てられた唯一の値を持っていなければならない。
【００２６】
（５）０×００００及び０×ＦＦＦＦの場合を除いては、最初の叙述子のｍｏｄｅｌ及びｖｅｒｓｉｏｎフィールドは端末装置の製造企業により定義されるねばならないが、これはソフトウェアのアップデートに使われる。（６）最初の叙述子のｍｏｄｅｌフィールドの値が０×００００ならば、本発明の実施形態によるｅｘｔｅｎｄｅｄＭｏｄｅｌＳｕｂＤｅｓｃｒｉｐｔｏｒは、図５のように定義されて叙述子中になければならない。（７）もし、最初の叙述子のｍｏｄｅｌフィールド値が０×ＦＦＦＦならば、特定製造企業のあらゆるモデルにソフトウェアのアップデートが適用される。（８）最初の叙述子のｖｅｒｓｉｏｎフィールド値が０×００００ならば、本発明の実施形態によるｅｘｔｅｎｄｅｄＶｅｒｓｉｏｎＳｕｂＤｅｓｃｒｉｐｔｏｒは、図６のように定義されて叙述子中になければならない。（９）もし、最初の叙述子のｖｅｒｓｉｏｎフィールド値が０×ＦＦＦＦならば、特定製造企業により特定されたモデルのあらゆるバージョンにソフトウェアのアップデートが適用される。
【００２７】
（１０）最初の叙述子のｓｕｂＤｅｓｃｒｉｐｔｏｒＣｏｕｎｔフィールドは２より大きいことがあるが、そうした場合に端末装置は、ｓｕｂＤｅｓｃｒｉｐｔｏｒＴｙｐｅフィールドが０×０１や０×０２に特定されていないいかなる副叙述子も無視する。（１１）２番目の叙述子のｄｅｓｃｒｉｐｔｏｒＴｙｐｅフィールドは０×０２値を持つが、これはシステムソフトウェアであることを表す。（１２）前記（３）から（１０）の限定は、端末装置のハードウェアよりはアップデートされるソフトウェアコンポーネントを特定するのに使われる製造企業とモデル及びバージョンを除いては２番目の叙述子に適用される。
【００２８】
図５は、本発明の実施形態による拡張されたモデル副叙述子（Ｅｘｔｅｎｄｅｄ Ｍｏｄｅｌ Ｓｕｂ−Ｄｅｓｃｒｉｐｔｏｒ）の構文を示す表である。
拡張されたモデル副叙述子は、ハードウェアまたはソフトウェアモデルを特定するために製造企業により割り当てられたＵＵＩＤを使用する。本発明の実施形態は、ＵＵＩＤを使用することによって、ＤＳＭ−ＣＣ互換叙述子の１６ビットモデルフィールドよりハードウェアまたはソフトウェアを区別するためのはるかに大きい空間を持つことができる。
【００２９】
ｓｕｂＤｅｓｃｒｉｐｔｏｒＴｙｐｅは、副叙述子のタイプを示す値である。本副叙述子のタイプを表す値は０×０１を持つ。ｓｕｂＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、本フィールド後の副叙述子中にあるバイトの数を表す値である。このフィールド値は０×１０を持つ。ｕｕｉｄ（）は製造企業が決定したＵＵＩＤを特定するフィールドであるが、ＵＵＩＤは、ハードウェアまたはソフトウェアモデルを唯一に識別させる。
【００３０】
図６は、本発明の実施形態による拡張されたバージョン副叙述子の構文を示す表である。
拡張されたバージョン副叙述子は、ハードウェアまたはソフトウェアバージョンを特定するのに使われるが、製造企業が割り当てた主バージョン、副バージョン、及びマイクロバージョン数字を持つ。本発明の実施形態による拡張されたバージョン副叙述子は、ハードウェア装置バージョンまたはソフトウェアコンポーネントバージョンを識別するためのさらに拡張性のあるメカニズムを提供する。
【００３１】
ｓｕｂＤｅｓｃｒｉｐｔｏｒＴｙｐｅは、副叙述子のタイプを示すフィールドである。本副叙述子のタイプを示す値は０×０２である。ｓｕｂＤｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、本副叙述子による副叙述子中のバイト数を示すフィールドである。ｍａｊｏｒは、製造企業により決定された主バージョン数を特定する。ｍｉｎｏｒは副バージョン数を特定し、ｍｉｃｒｏはマイクロバージョン数を特定する。各バージョンで０×ＦＦＦＦ値を持つ場合には、各バージョンのあらゆるバージョンを表すのに使用する。
【００３２】
図７は、本発明の実施形態によるソフトウェアのアップデート情報叙述子の構文を示す表である。
基本的にソフトウェアのアップデートデータサービスは、ＡＴＳＣ−Ａ／９０により定義されたデータサービス報知（Ｄａｔａ Ｓｅｒｖｉｃｅ Ａｎｎｏｕｎｃｅｍｅｎｔ）を使用して知らせる。限定的な内容は図７を参照して説明する。ソフトウェアのアップデート情報叙述子は、ソフトウェアのアップデートデータサービス報知の文脈（ｃｏｎｔｅｘｔ）でソフトウェアのアップデートについての情報を提供するところに使用する。これについての構文を説明する。
【００３３】
ｄｅｓｃｒｉｐｔｏｒ Ｔａｇは、叙述子のタイプを表すフィールドであって、このフィールドは８ビットの定数値を持つ。ｄｅｓｃｒｉｐｔｏｒＬｅｎｇｔｈは、本叙述子でこのフィールドについているバイトの数を表すが、使われるフィールドとして８ビット値を持つ。ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒは、前記図４ないし図６を通じて説明した互換性叙述子を特定するところに使用するフィールドである。
【００３４】
ソフトウェアのアップデートサービスは、ブロードキャストのためにはスケジューリングされねばならない。現在から１６日（３８４時間）以内にブロードキャストする場合には、ＡＴＳＣ−Ａ／９０により特定されたデータイベントテーブル（Ｄａｔａ Ｅｖｅｎｔ Ｔａｂｌｅ；ＤＥＴ）を使用して知らせる。具体的に説明すれば、（１）ｄｅｓｔｃｒｉｔｐｔｏｒ（）は、ソフトウェアのアップデートデータサービスを知らせる構造体ｄａｔａ＿ｅｖｅｎｔ＿ｔａｂｌｅ＿ｓｅｃｔｉｏｎ（）のエントリーの内部叙述子ループの構造体であって、一つまたはそれ以上のソフトウェアのアップデート情報叙述子を含む。一つより多くのソフトウェアのアップデート情報叙述子が構造体ｄａｔａ＿ｅｖｅｎｔ＿ｔａｂｌｅ＿ｓｅｃｔｉｏｎ（）の同一エントリーにある場合に、前記ソフトウェアのアップデート情報叙述子は異なる叙述子でなければならない。
【００３５】
現在の周期に後続する１６日以内にソフトウェアのアップデートデータサービスを放送するためにスケジュールする場合には、ＡＴＳＣ−Ａ／９０により特定された長期サービステーブル（Ｌｏｎｇ−Ｔｅｒｍ Ｓｅｒｖｉｃｅ Ｔａｂｌｅ；ＬＴＳＴ）を使用して知らせる。（２）ｄｅｓｔｃｒｉｔｐｔｏｒ（）は、ソフトウェアのアップデートデータサービスを知らせる構造体ｌｏｎｇ＿ｔｅｒｍ＿ｓｅｒｖｉｃｅ＿ｔａｂｌｅ（）のエントリーの内部叙述子ループの構造体であって、一つまたはそれ以上のソフトウェアのアップデート情報叙述子を含む。一つより多くのソフトウェアのアップデート情報叙述子が構造体ｌｏｎｇ＿ｔｅｒｍ＿ｓｅｒｖｉｃｅ＿ｔａｂｌｅ（）の同一エントリーにある場合に、前記ソフトウェアのアップデート情報叙述子は異なる叙述子でなければならない。
【００３６】
ソフトウェアのアップデートサービスは、ＡＴＳＣ−Ａ／９０により定義されたサービス叙述フレームワーク（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）を使用して信号化する。次いで、データサービステーブル（ＤＳＴ）の各アプリケーションエントリーに適用される限定であるが、データサービステーブルは、ソフトウェアのアップデートデータアプリケーションを説明する。
【００３７】
（１）ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（）は、前記図４ないし図６を通じて説明した互換性叙述子の特定に使用する構造体である。
（２）ａｐｐ＿ｉｄ＿ｂｙｔｅ＿ｌｅｎｇｔｈフィールドは０×００１２値を持つ。
（３）ａｐｐ＿ｉｄ＿ｄｅｓｃｒｉｐｔｉｏｎフィールドは０×０００１値を持つ。
（４）ａｐｐ＿ｉｄ＿ｂｙｔｅ（）フィールドはバイナリコーディングされたＵＵＩＤであるが、ＵＵＩＤは、パラメータスペース＜ｄｅｖｉｃｅＭａｎｕｆａｃｔｕｒｅｒ、ｄｅｖｉｃｅＭｏｄｅｌ、ｄｅｖｉｃｅＶｅｒｓｉｏｎ、ｓｏｆｔｗａｒｅＣｏｍｐｏｎｅｎｔ、ｓｏｆｔｗａｒｅＣｏｍｐｏｎｅｎｔＶｅｒｓｉｏｎ＞に対して唯一であるが、このようなパラメータは互換性叙述子のコンテンツにより決定される。
【００３８】
（５）ｔａｐ＿ｃｏｕｎｔフィールドは０より大きい。
（６）各タップエントリーのｐｒｏｔｏｃｏｌ＿ｅｎｃａｐｓｕｌａｔｉｏｎフィールドは、０×０Ｄ（ＤＳＭ−ＣＣダウンロードプロトコルの非同期的ｃａｒｏｕｓｅｌシナリオを意味する）である。
（７）各タップエントリーのａｃｔｉｏｎ＿ｔｙｐｅフィールドは、０×００（ランタイムデータを意味する）である。
（８）各タップエントリーのｒｅｓｏｕｒｃｅ＿ｌｏｃａｔｉｏｎフィールドは、０（ＰＭＴ中の結合タグを意味する）である。
（９）各タップエントリーのｔａｐ＿ｉｄフィールドは、単一ソフトウェアのアップデートアプリケーションのコンテクスト中で唯一の値を持つ。
（１０）各タップエントリーのｕｓｅフィールドは、０×００００値を持つ。
【００３９】
（１１）各タップエントリーのａｓｓｏｃｉａｔｉｏｎ＿ｔａｇフィールドは、ソフトウェアのアップデートペイロードをカプセル化したプログラムエレメンタリーストリーム（Ｐｒｏｇｒａｍ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）と結合した結合タグのような値を持つ。
（１２）各タップの構造体ｓｅｌｅｃｔｏｒ（）のｓｅｌｅｃｔｏｒ＿ｌｅｎｇｔｈフィールドは、０、４、６、または８値を持つ。
（１３）各タップの構造体ｓｅｌｅｃｔｏｒ（）のｓｅｌｅｃｔｏｒ＿ｔｙｐｅフィールドは、ｓｅｌｅｃｔｏｒ＿ｌｅｎｇｔｈフィールドが０、４、６、または８値を持つ時、それぞれ０×０１０１、０×０１０７、または０×０１０８を持つ。
【００４０】
（１４）各タップエントリーのｔａｐ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドは０でないこともある。前記ｔａｐ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドが０である場合に、端末装置は知らないタップエントリー中の直ちに後続する叙述子を無視する。
（１５）ａｐｐ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドは０でないこともある。前記ａｐｐ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドが０である場合に、端末装置は知らないタップエントリー中の直ちに後続する叙述子を無視する。
（１６）ａｐｐ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドは０でないこともある。前記ａｐｐ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドが０である場合に、端末装置は直ちに後続するａｐｐ＿ｄａｔａ＿ｂｙｔｅ（）フィールドを無視する。そのような場合に端末装置は、前記フィールドに対して非標準意味を判断しない。
【００４１】
前記とともに、ソフトウェアのアップデートサービスが信号化されるデータサービステーブルセクションの構造体ｄａｔａ＿ｓｅｒｖｉｃｅ＿ｔａｂｌｅ＿ｂｙｔｅｓ（）に適用される限定は次の通りである。
【００４２】
（１７）ｓｅｒｖｉｃｅ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドは０でないこともある。前記ｓｅｒｖｉｃｅ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドが０である場合に、端末装置は知らない直ちに後続する叙述子を無視する。
（１８）ｓｅｒｖｉｃｅ＿ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドは０でなくありえる。前記ｓｅｒｖｉｃｅ＿ｐｒｉｖａｔｅ＿ｄａｔａ＿ｌｅｎｇｔｈフィールドが０である場合に端末装置は直ちに後続するｓｅｒｖｉｃｅ＿ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅ（）フィールドを無視する。そのような場合に端末装置は、前記フィールドに対して非標準意味を判断しない。
【００４３】
ソフトウェアのアップデートペイロードは、ＤＳＭ−ＣＣ７枚、ユーザからネットワークへのダウンロード（Ｕｓｅｒ−ｔｏ−Ｎｅｔｗｏｒｋ Ｄｏｗｎｌｏａｄ）に定義された一つまたはそれ以上のモジュールでカプセル化される。単一及び二重レベル制御構造体はいずれも許容される。ソフトウェアのアップデートペイロードをカプセル化させるモジュール及び構成は、個別的な製造企業なら定義できる。
【００４４】
当業者は、本発明がその技術的思想や必須な特徴を変更せずに他の具体的な形態に実施できるということを理解できるであろう。したがって、以上で記述した実施形態はあらゆる面で例示的なものであり、限定的でないと理解せねばならない。本発明の範囲は、前記詳細な説明よりは特許請求の範囲により現れ、特許請求の範囲の意味及び範囲、そしてその均等概念から導出されるあらゆる変更または変形された形態は、本発明の範囲に含まれると解釈されねばならない。
【産業上の利用可能性】
【００４５】
本発明によれば、既存のデジタルデータ放送の標準をほとんど修正せずにもＵＵＩＤを使用して受信装置を唯一に区別して、ソフトウェアのアップデートサービスを提供できる。また本発明によれば、ソフトウェアのバージョン情報を従来のデジタル放送とは違って細分化できる。
【図面の簡単な説明】
【００４６】
【図１】対話形デジタル放送システムの構成を概略的に示すブロック図である。
【図２】本発明の実施形態によるソフトウェアのアップデート過程を示すフローチャートである。
【図３】本発明の他の実施形態によるソフトウェアのアップデート過程を示すフローチャートである。
【図４】ＡＴＳＣデータブロードキャスト標準（Ａ／９０）のＤＳＭ−ＣＣの互換性叙述子の構文を示す表である。
【図５】本発明の実施形態による拡張されたモデル副叙述子の構文を示す表である。
【図６】本発明の実施形態による拡張されたバージョン副叙述子の構文を示す表である。
【図７】本発明の実施形態によるソフトウェアのアップデート情報叙述子の構文を示す表である。
【符号の説明】
【００４７】
１００      デジタル放送サービス提供者
２００      受信装置
【図２】
2007515102.tif 000003
【図３】
2007515102.tif 000004
【図４】
2007515102.tif 000005
【図５】
2007515102.tif 000006
【図６】
2007515102.tif 000007
【図７】
2007515102.tif 000008
【図１】
2007515102.tif 000009
【国際調査報告】
2007515102.tif 000010
2007515102.tif 000011