(57)【特許請求の範囲】
【請求項１】
配布される複数の装置宛ての複数の異なる常駐ソフトウェアバージョンを有する配布データ構造を構成する方法であって、当該方法は装置によって行われ、
前記複数の異なる常駐ソフトウェアバージョン内で、該異なる常駐ソフトウェアバージョンの少なくとも２つに共通する部分を、該部分の各々の宛先を指定するパラメータのセットを解析することによって、特定するステップと、
前記複数の異なる常駐ソフトウェアバージョンを該複数の異なる常駐ソフトウェアバージョンに属するコードのバイナリセグメントに分割し、該コードのバイナリセグメントの各々に対して該コードのバイナリセグメントをそのコードのバイナリセグメントに対応する前記パラメータのセットによってマーク付けするステップと、
前記少なくとも２つの異なる常駐ソフトウェアバージョンに共通すると特定される部分の前記コードのバイナリセグメント（以下、共通コードバイナリセグメントと称する）の各々に対して、前記パラメータのセットの少なくとも１つのパラメータを特定の値に設定することによって前記共通コードバイナリセグメントをマーク付けするステップであって、前記特定の値は前記共通コードバイナリセグメントが前記複数の装置の全てのハードウェアプラットフォームに指定されていることを示す、該ステップと、
前記配布データ構造内の前記コードのバイナリセグメントを構成するステップであって、前記共通コードバイナリセグメントは前記配布データ構造内で１度のみ検出される、該ステップと、
含む、前記方法。
【請求項２】
各コードのバイナリセグメントを、該コードのバイナリセグメントが部分となる前記常駐ソフトウェアバージョンによって対象とされる前記複数の装置を特定することによってマーク付けするステップをさらに含む、請求項１記載の方法。
【請求項３】
前記複数の装置は、複数のデジタルテレビ受信装置である、請求項２記載の方法。
【請求項４】
前記配布データ構造は、ＭＰＥＧトランスポートストリームである、請求項３記載の方法。
【請求項５】
複数の装置宛の複数の異なる常駐ソフトウェアバージョンを有する配布データへのアクセス手段を有する装置であって、
前記異なる常駐ソフトウェアバージョンは、前記配布データ内の複数のコードのバイナリセグメントに分割され、前記コードのバイナリセグメントは、前記複数の異なる常駐ソフトウェアバージョンに属し、
当該装置は、前記配布データ内から前記コードのバイナリセグメントをダウンロードする手段と、前記ダウンロードしたコードのバイナリセグメントを格納する手段とを有し、
当該装置は、前記複数のコードのバイナリセグメントのうち当該装置宛ての常駐ソフトウェアバージョンの部分となる前記コードのバイナリセグメントを特定する手段であって、前記特定する手段が、前記パラメータのセットのパラメータが特定の値を有するかを解析することによって、少なくとも２つの異なる常駐ソフトウェアバージョンに共通する前記コードのバイナリセグメント（以下、共通コードバイナリセグメントと称する）を特定することを含み、前記特定の値は前記共通コードバイナリセグメントが前記複数の装置の全てのハードウェアプラットフォームに指定されていることを示し、前記共通コードバイナリセグメントは前記配布データ内で１度のみ検出される、前記特定する手段を有する、前記装置。
【請求項６】
当該装置は、
当該装置のタイプ及び利用を符号化する識別子セットと、
前記識別子セットと、前記配布データ内の各コードのバイナリセグメントに存在し、前記コードのバイナリセグメントが属する常駐ソフトウェアバージョンによって対象とされる装置を特定する識別子セットとを比較する手段と、
を有する、請求項５記載の装置。
【請求項７】
前記配布データへのアクセス手段は、ＭＰＥＧトランスポートストリームへのアクセス手段である、請求項６記載の装置。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
本発明は、装置に含まれる常駐するソフトウェアの更新に関する。その状況は、より詳細には、装置の管理ソフトウェアのフローにおける配布による更新である。
【０００２】
特に、テレビデジタルデコーダと通常呼ばれるデジタルテレビ受信装置の分野では、ＭＰＥＧトランスポートストリームタイプのフローにおいて（ＭＰＥＧ−２  Ｓｙｓｔｅｍ：ＩＳＯ／ＩＥＣ，１９９４．Ｇｅｎｅｒｉｃ  Ｃｏｄｉｎｇ  ｏｆ  Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅｓ  ａｎｄ  Ａｓｓｏｃｉａｔｅｄ  Ａｕｄｉｏ：Ｓｙｓｔｅｍｓ，（ＭＰＥＧ−２  Ｓｙｓｔｅｍｓ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ），Ｎｏｖｅｍｂｅｒ，ＩＳＯ／ＩＥＣ  １３８１８−１）、デコーダ内の常駐ソフトウェアの更新されたバージョンを配布することが知られている。常駐ソフトウェアは、当該装置を動作させるのに使用される装置内のすべてのオンボードソフトウェアを意味すると理解される。この分野では、常駐ソフトウェアの所与のバージョンが、一般には、当該デコーダのハードウェアバージョン、当該デコーダを管理するオペレータ又は当該デコーダに対して意図された利用などに従って、デコーダに適用される。デコーダの明確に規定されたタイプを更新するよう設計された常駐ソフトウェアのあるバージョンを含むダウンローディングストリームと呼ばれるＭＰＥＧフローを構成することが一般的である。
【０００３】
デジタルデコーダの配置の開始時に、各更新フローは、機能ソフトウェアを構成するすべてのセグメントをトランスポートし、あるタイプのプラットフォームに送信されている。加入者数が増加するに従って、オペレータはしばしば、新たなメーカーに自分のデコーダの供給業者を分散するよう助言する。これらの供給業者は自ら、新たなハードウェアバージョンに基づく新たなデコーダを供給することによって、装置のコストを低減しようとする。このとき、ハードウェア装置は、同質性がなくなり、ダウンローディングストリームに割り当てられる帯域幅要求はより大きなものとなる。
【０００４】
同時に、メーカーがオペレータに供給する異なるハードウェアバージョンのデコーダに対して、対応するソフトウェアバージョンはしばしば、共通のコードセグメントを共有している。これらのセグメントは、一般には特にソフトウェアアーキテクチャの上位レイヤに配置されている（プロトコルスタック、アプリケーション、インタフェースなど）。
【０００５】
同じ問題が、製造段階においてソフトウェアダウンローディングを使用するメーカーにより認識されている。実際、所与の時点において、メーカーは、同一の製造ライン上で同一の装置ハードウェアバージョンから、共通のコードセグメントを共有する異なるソフトウェアバージョンによりダウンロードされる異なるオペレータに対するデコーダを製造することが要求される可能性がある。これらのセグメントは、一般には特にソフトウェアアーキテクチャの下位レイヤに配置される（オペレーティングシステム、ドライバなど）。
【０００６】
従って、技術的問題は、ダウンローディングストリームに割り当てられる帯域幅要求を低減することに関し、これは、オペレータとメーカーの双方に対するものである。上記問題は、以下のように表現されるかもしれない。
【０００７】
異なるプラットフォームに専用の異なるソフトウェアバージョンをトランスポートするフローに割り当てられたビットレートを、これら異なるソフトウェアバージョンが共通のコードセグメントを共有するとき（プロトコルスタック、アプリケーション、インタフェースなど）、オペレータはどのようにして低下させることができるか。
【０００８】
上記フローが単一のプラットフォーム上で異なるオペレータに専用とされる共通のコードセグメントを有する異なるソフトウェアバージョンをダウンロードするのに使用されるとき、メーカーの製造施設に送られるダウンローディングストリームに割り当てられるビットレートを低下させることによって、メーカーはどのようにして製造プロセスを向上させることができるか（オペレーティングシステム、ドライバなど）。
【０００９】
上記問題の系として、ユーザの体感を向上させるため、ダウンローディング時間をどのように短縮させることができるか追加することができる。
【００１０】
本発明は、異なるデコーダに対して設計された異なるソフトウェアバージョンが同じフローに混合されることを可能にする。その原理は、複数のバージョンの常駐ソフトウェアのバイナリセグメントをトランスポートするフローからデコーダの更新を可能にする独自のデータフォーマットを規定することである。これらのバイナリセグメントは、複数のバージョンのソフトウェアに共通するセグメントと、各ソフトウェアバージョンに固有のセグメントから構成される。
【００１１】
１つの系として、デコーダハードウェアバージョンに専用のコードセグメントを復元するためローダにより実現される処理は、より複雑である。にもかかわらず、当該処理は、ローダのみが更新の必要があるコードセグメントを復元するため検索するような方法により向上させることが可能となる。
【００１２】
本発明は、複数の装置のための複数の常駐ソフトウェアバージョンを有する配布媒体を構成する方法であって、少なくとも２つの常駐ソフトウェアバージョンに共通する複数の部分を構成する前記常駐ソフトウェアバージョン内で特定するステップと、前記複数の部分を構成する前記常駐ソフトウェアバージョンをセグメントに分割するステップと、配布媒体内に少なくとも２つのバージョンに共通する、１度のみ検出される部分を含むセグメントを前記配布媒体内に構成するステップとを少なくとも有する方法に関する。
【００１３】
一実施例によると、本発明はまた、各セグメントを、該セグメントが部分となる前記常駐ソフトウェアバージョンによって対象とされる装置を特定することによってマーク付けするステップをさらに有する。
【００１４】
本発明の一実施例によると、前記複数の装置は、複数のデジタルテレビ受信装置である。
【００１５】
本発明の一実施例によると、前記配布媒体は、ＭＰＥＧトランスポートストリームである。
【００１６】
本発明はまた、配信ネットワークによって配信される配布媒体へのアクセス手段を有する装置によって常駐ソフトウェアバージョンのすべて又は一部を取得する方法であって、前記装置のための少なくとも１つのセグメントを前記配布媒体において特定するステップと、前記配布媒体から前記装置において特定された前記セグメントをダウンロードするステップと、前記セグメントをメモリに格納するステップとを少なくとも有する方法に関する。
【００１７】
本発明の一実施例によると、前記特定するステップは、各セグメントにおいて該セグメントが属する常駐ソフトウェアバージョンによって対象とされる前記装置を特定する識別子セットと、前記装置並びにそれのタイプ及び利用の符号化に関する常駐識別子セットとを比較するステップを有する。
【００１８】
本発明の一実施例によると、前記識別子セットは、前記装置の特定タイプのハードウェアバージョンを特定する少なくとも１つのプラットフォーム識別子と、前記装置を操作するオペレータを特定する製品識別子と、前記装置の意図される利用を特定する利用識別子とを有する。
【００１９】
本発明の一実施例によると、前記装置は、デジタルテレビ受信機であり、前記配布媒体は、ＭＰＥＧトランスポートストリームである。
【００２０】
本発明はまた、複数の装置のため構成され、セグメントに分割される複数の常駐ソフトウェアバージョンの配布媒体であって、当該配布媒体は、前記複数の常駐ソフトウェアバージョンのセグメントであって、当該媒体上に少なくとも２つのソフトウェアバージョンに共通する、１度のみ存在するセグメントを収集する媒体に関する。
【００２１】
本発明の一実施例によると、各セグメントは、該セグメントが属する前記常駐ソフトウェアバージョンにより対象とされる装置を前記セグメントにおいて特定する識別子セットを有する。
【００２２】
本発明の一実施例によると、前記識別子セットは、前記装置の特定タイプのハードウェアバージョンを特定する少なくとも１つのプラットフォーム識別子と、前記装置を操作するオペレータを特定する製品識別子と、前記装置の意図される利用を特定する利用識別子とを有する。
【００２３】
本発明の一実施例によると、ＭＰＥＧトランスポートストリームの形式を有する。
【００２４】
本発明はまた、複数の装置に対して構成される複数の常駐ソフトウェアバージョンを有する配布媒体へのアクセス手段を有する装置であって、前記バージョンは、前記配布媒体内の複数のセグメントに分割され、当該装置は、前記配布媒体内に存在する前記セグメントをダウンロードする手段と、前記セグメントを格納する手段とを有し、当該装置は、前記配布媒体内に存在する前記複数のセグメントのうちで当該装置のための常駐ソフトウェアバージョンの一部となるセグメントを決定する手段を有する装置に関する。
【００２５】
本発明の一実施例によると、当該装置は、それのタイプ及び利用を符号化する識別子セットと、該識別子セットと、前記配布媒体内の各セグメントに存在し、前記セグメントが属する常駐ソフトウェアバージョンによって対象とされる装置を特定する識別子セットとを比較する手段とを有する。
【００２６】
本発明の一実施例によると、前記配布媒体へのアクセス手段は、ＭＰＥＧトランスポートストリームへのアクセス手段である。
【００２７】
本発明の実施例が説明される。当該実施例は、デジタルテレビデコーダの分野の範囲内にあるが、本発明は、一般的な配布手段を介し更新可能な常駐ソフトウェアを有する任意の装置に適用可能である。一例として、異なるプラットフォーム又は他の要素のためのソフトウェアバージョンを含む１つのＤＶＤによって更新されるＤＶＤプレーヤーがあげられる。
【００２８】
図７は、本発明の一実施例による７．１により参照されるデコーダの構成を示す。当該デコーダは、音声及び映像サービスを含むフローの受信を可能にする７．７により参照されるチューナにより構成される。当該モジュールは、衛星、ケーブル、地上波モジュール、又はＩＰタイプのネットワーク接続インタフェースとすることができる。このとき、このチューナからのフローは、７．６により参照されるＭＰＥＧデマルチプレクサ／デコーダにより処理される。当該モジュールは、権利を認証し、必要に応じて、フローを解読するためのものである。このとき、要求されたサービスがフローにおいて分離される。実際には、１つのフローが複数の音声及び映像サービスの多重化を含む可能性がある。要求されたサービスが分離されると、異なる基本フローがそこから抽出される。これらのフローは、一般には、現在はＭＰＥＧ−２に従って圧縮された映像フロー及び音声フローから構成されるが、本発明は、ＭＰＥＧ−４などサービスのフォーマットとは無関係に動作する。従って、これらのフローは解凍され、その後、映像出力及び音声出力を提供するためアナログ信号に変換される。これらすべての処理は、７．４により参照されるＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）と７．３により参照される書き換え可能な不揮発性メモリとの間で分散的に格納されている常駐ソフトウェアにより制御される。７．２により参照されるＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）について、それは常駐ソフトウェアを実行するためのワーキングメモリとして利用される。
【００２９】
図２は、本発明の実施例に提供される常駐ソフトウェアを構成するのに使用される各種ブロックを図示する。この常駐ソフトウェアは、上述した２．８により参照されるハードウェア上で動作する。それは２つのパートから構成され、２．５により参照される第１のパートは、２．６により参照されるローダと、２．７により参照される当該ローダを動作可能にする最小限のドライバセットから構成される。典型的には、ローダとそのドライバは、経時的にそれらのインテグリティを保証するため、書き換え不可な不揮発性メモリに格納される。実際、このローダの機能は、デコーダのソフトウェアの更新を可能にすることであり、書き換え可能メモリに格納されている常駐ソフトウェアの状態とは無関係に何れのケースにおいても動作可能となっていなければならず、損傷不可とされなければならない。
【００３０】
２．１により参照される常駐ソフトウェアの他方のパートは、２．４により参照されるハードウェアの管理を可能にする完全なドライバセットから構成される。これらのドライバの上位には、ドライバに応じた汎用機能セットを提供する２．３により参照されるオペレーティングシステムがある。２．２により参照されるアプリケーションは、ユーザにユーザのデコーダの各機能を提供するハイレベルソフトウェアを有する。それは、マンマシーンインタフェースから構成され、サービスの変更、可能な相互作用性エンジンの管理、インタラクティブアプリケーション、他の機能などの各機能を実現する。当該パートはまた、２．９により参照され、２．１により参照されるソフトウェアグループの更新を可能にするローダを有することが一般的である。このローダは自ら更新可能である。実際、それがソフトウェアシステムの新たなバージョンをダウンロードするとき、当該バージョンは、２．９により参照されるローダの代わりにメモリに置かれる当該ローダの新たなバージョンを含めることが可能である。この更新中に問題が発生した場合、不揮発性メモリに格納されている２．６により参照されるローダが、この問題を解決し、２．１により参照されるソフトウェアパートとそれの一部である２．９により参照されるローダの動作バージョンを求めるソフトウェアの新たな更新を常に可能にする。
【００３１】
デコーダにソフトウェアをダウンロードする要求は、いくつかの理由を有している可能性がある。第１の理由は、インストールされたソフトウェアの損傷である。実際、２．１により参照されるソフトウェアパートが書き換え可能メモリに格納されると、常に損傷する可能性が生じうる。この場合、損傷は、ＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）システムによりソフトウェアを有するモジュールのインテグリティをチェックする装置を次に起動させたときに検出される。ローダ以外のモジュールにおいて損傷が検出されると、ローダはソフトウェアの新たな完全なバージョンをダウンロードするのに利用される。損傷しているとして検出されたモジュール又は新たなフルバージョンのシステムソフトウェアを更新することが可能である。ローダが自ら損傷していると検出されると、更新は、２．６により参照される常駐ローダに委託される。
【００３２】
ダウンローディングのための他の理由は、新たなバージョンの常駐ソフトウェアの利用性である。この新たなバージョンは、現在のバージョンに存在するエラーを訂正し、及び／又は新たな機能を常駐ソフトウェアに加えることが可能である。この場合、それの起動段階において、デコーダによる新たなバージョンの検出は、おそらくある状況下において、当該新規なバージョンを２．９により参照されるローダによりダウンロードさせ、デコーダにインストールさせる。
【００３３】
また一般には、所与のソフトウェアバージョンのダウンローディング及びインストールを実行させることが可能である。この場合、ユーザ又はプロテクトされたシステムのアンロック後の認証されたエンジニアは、装置へのインストール及びダウンロードを要求する常駐ソフトウェアを指定することが可能である。これは、メンテナンス作業中又は配送前の向上における装置の準備中に実行することが可能である。このように、装置が意図される用途に従って、選択されたシステムソフトウェアバージョンにより装置を設定することが常に可能である。
【００３４】
図１において、典型的なダウンローディングインフラストラクチャが示される。装置のためのソフトウェアバージョンの全体は、ドライバ、オペレーティングシステム及びアプリケーションレイヤなどを構成する各種モジュールにより構成される。１．１、１．２及び１．３により参照される上記モジュールは、１．４により参照されるミキサを介しＭＰＥＧトランスポートストリームにおいて構成及びミキシングされる。当該フローは、１．５により参照れる送信ステーションによって、１．７〜１．１０により参照されるデコーダにそれを配布する１．６により参照される衛星に送信される。ここに記載されるインフラストラクチャは、衛星配信のものであるが、ケーブル、地上波ネットワーク又は製造施設内の内部ネットワークとすることが可能な他のタイプの配布に対しても同様の図となる。この場合、１．４により参照されるミキサにより計算されるフローは、デコーダのための信号を生成するサーバにより送信される。標準的には、構成されるダウンローディングストリームは、所与のタイプのデコーダのためのソフトウェアのバージョンを含むが、本発明に関して、複数のソフトウェアバージョンに属するモジュールを当該フローにミキシングすることが可能である。
【００３５】
ある数の識別子が、常駐ソフトウェアのバージョンをマーク付けし、関連するデコーダを決定するのに利用される。以下の識別子が主として検出され、ダウンローディングプロセスを決定するのに重要な役割を担う。
・実際には、デコーダモデルに対応するプラットフォームのタイプを示すＰＴと、プラットフォームタイプのバージョン番号を指定するＰＶの２つの識別子の集合体から構成されるプラットフォーム識別子  当該識別子は、デコーダハードウェアモデルの正確な特定を可能にする。
・デコーダを使用するエペレータを一般に特定する製品識別子ＰＲ  実際、同じハードウェアデコーダは、それを配置するオペレータに依存して同じソフトウェアを使用しない。
・同一プラットフォーム及び同一製品がプラットフォームから構成される利用を区別することを可能にする利用識別子ＵＳ  これにより、例えば、加入者用に構成されたプラットフォームとテスト又は他の用途に構成されたプラットフォームとを区別することが可能となる。
【００３６】
正確なプラットフォームモデル、オペレータ及び当該デコーダが構成された用途の知識を提供するこれらの識別子のセットが、デコーダに格納される。ダウンローディングストリームはまた、含まれているソフトウェアが何れのために生成されたものであるかデコーダが知ることを可能にする上記識別子セットを有する。本発明に関して、各セグメントは、それ自身のパラメータセットを有する。
【００３７】
上述した理由によりデコーダが新たなソフトウェアバージョンにより更新される必要がある既知の方法では、それは、自らのために設計されたソフトウェアバージョンを含むフローを特定することを可能にする内部パラメータを利用する。従って、それは当該フローに接続し、フローに含まれるプラットフォーム、製品及び利用識別子が、それが所有する識別子に一致しているかチェックする。この場合、それは、フローに含まれるソフトウェアをダウンロードし、格納する。
【００３８】
本発明の実施例に関して、上記更新機構は、３．３により参照されるバイナリセグメントの送信に基づいている。これらのセグメントは、フローに合成されることが要求される各種常駐ソフトウェアバージョンの３．１により参照されるメモリダンプの分割に対応する。これらのセグメントは、常駐ソフトウェアの各バージョンから構成される各種モジュールに直接対応させることが可能であり、又は他の分割モードの結果とすることも可能である。これらのコードセグメントは、配布されるすべてのコードセグメントを記述する３．２により参照されるヘッダセグメントに後続する。これらすべてのセグメントは、３．４により参照されるＭＰＥＧセクションによりトランスポートされる。実際、ＭＰＥＧトランスポートストリームは、連続する１８８バイトセクションから構成される。
【００３９】
図４に示される「ヘッダ」セグメントは「ヘッダ」から構成され、ループはフローに含まれる各コードセグメントを記述子、シグネチャフィールドは当該ヘッダセグメントとそれのコンテンツを認証する。
【００４０】
「ヘッダ」セグメントのヘッダは、以下のフィールドから構成される。
・“ＯＵＩ”（Ｕｎｉｑｕｅ  Ｏｒｇａｎｉｓａｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）：ＤＶＢ（デジタル配信規格を規定するコンソーシアムである“Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔ”）により指定され、ヘッダにより記述される各メーカー及び各セグメントを一意的に識別する
・“Ｋｅｙ  Ｉｎｄｅｘ”：公開鍵に基づくアルゴリズムが使用されるとき、フローを認証するのに要求される  それは、フローを認証するのに使用されるべき公開鍵を特定する。
・“ＦｌｏｗＶｅｒｓｉｏｎＩｄ”：フローのコンテンツの変更を知ることを可能にする  当該情報は、信号配信可能であり、デコーダが変更のたびにダウンロード処理を開始することを可能にする。
・“ＥｎｃｒｙｐｔｅｄＳｅｅｄ，ＩｎｉｔｉａｌＶａｌｕｅ”：セグメントを解読するのに要求される情報
各セグメントに対して、以下の情報が検出される。
・“ＰｌａｔｆｏｒｍＴｙｐｅ，ＰｌａｔｆｏｒｍＶｅｒｓｉｏｎ”は、セグメントがロードされる必要があるハードウェアプラットフォームを特定する。すべてのプラットフォームに共通するセグメントは、“（ＰｌａｔｆｏｒｍＴｙｐｅ，ＰｌａｔｆｏｒｍＶｅｒｓｉｏｎ）＝ａｎｙ”ペアにより一意的に特定される。
・“ＰｒｏｄｕｃｔＩｄ”は、製品又はクライアントを特定する。すべての製品に共通するセグメントは、“ＰｒｏｄｕｃｔＩｄ＝ａｎｙ”により一意的に特定される。
・“ＵｓａｇｅＩｄ”は、装置グループのデコーダの利用を特定する（加入者、テストなど）。すべての利用に共通するセグメントは、“ＵｓａｇｅＩｄ＝ａｎｙ”により一意的に特定される。
・“ＳｅｇｍｅｎｔＶｅｒｓｉｏｎＩｄ”は、セグメントのバージョンを特定する。それは、デコーダにセグメントがすでに存在するか、ダウンロードされる必要がないか判断するのに利用される。
・“ＳｅｇｍｅｎｔＴｙｐｅ，ＳｅｇｍｅｎｔＩｄ”は、セグメントのタイプと当該タイプにおけるそれの識別子とにそれぞれ対応する（オペレーティングシステム、ドライバ、インタフェースなど）。
・“ＣｒｃＭｅｍｏｒｙＴｙｐｅ”：メモリに格納されているセグメントに対して計算されたＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）タイプ
・“ＨａｓｈＭｅｍｏｒｙＴｙｐｅ”：メモリに格納されているセグメントに対して計算されたハッシュタイプ  フロー認証をチェックするのに要求される
・“ＳｅｇＳｔｏｒａｇｅＡｄｒｅｓｓ”：メモリにおけるセグメントの格納アドレス
・“ＳｅｇＳｉｚｅＭｅｍｏｒｙ”：メモリにおけるセグメントのサイズ（圧縮されていないセグメント）
・“ＣｒｃＦｌｏｗＴｙｐｅ”：フローによりトランスポートされるセグメントに対して計算されたＣＲＣタイプ  受信中のセグメントのインテグリティをチェックするのに要求される
・“ＣｏｍｐｒｅｓｓｉｏｎＴｙｐｅ”：フローによりトランスポートされるセグメントに対して計算される圧縮タイプ  セグメントが圧縮されているか、何れの圧縮アルゴリズムが利用されたか決定する
・“ＥｎｃｒｙｐｔｉｏｎＴｙｐｅ”：フローによりトランスポートされるセグメントに対する暗号化タイプ  セグメントが暗号化されているか、何れの暗号化アルゴリズムが利用されたか決定する
・“ＣｒｃＦｌｏｗ”：フローによりトランスポートされるセグメントのＣＲＣ
最後に、フローの認証を可能にする情報である“Ｓｉｇｎａｔｕｒｅ”がある。
【００４１】
トランスポートフォーマットは、図５に示されるＭＰＥＧセクションにおけるトランスポートフォーマットに基づく。それは、上述した“ＯＵＩ”、“ＳｅｇｍｅｎｔＮｂ”、“ＦｌｏｗＶｅｒｓｉｏｎＩｄ”情報を含む。当該情報は、フローにより送信されるデータを復元するのに使用される。
【００４２】
このように、常駐ソフトウェアの各種バージョンに対応する異なるメモリダンプに属する各セグメントを同一のフローに合成することができる。各セグメントは、ＰＴ、ＰＶＰＲ及びＵＳの自らのパラメータセットを有し、各セグメントの宛先が規定される。さらに、“ａｎｙ”という値をこれらのパラメータの一部に与えるという事実は、各ソフトウェアバージョンの間で共有するセグメントを重複しない。実際、すべてのハードウェアプラットフォームのための所与の製品の各ソフトウェアバージョンの間で共有されるセグメントは、製品の値に等しいＰＲと、“ａｎｙ”に等しい（ＰＴ，ＰＶ）と、その他のパラメータに対して同一なものによりマーク付けされる。これは、フローにおいて構成される各種常駐ソフトウェアバージョンにおいて、これらのバージョンの少なくとも２つに共通する部分を特定することによって開始される。各モジュールは、実際、それの宛先を指定するパラメータＰＴ、ＰＶ、ＰＲ及びＵＳのセットによる設定又は他の手段によってマーク付けされる。これらのパラメータの解析は、複数のバージョンに共通したモジュールを特定する。その後、これらのモジュールがセグメントに分割されると、各セグメントは、それに対応するパラメータＰＴ、ＰＶ、ＰＲ及びＵＳによりマーク付けされ、共通するセグメントは、ここではＭＰＥＧフローである配布媒体の構成中に複製されない。
【００４３】
図６において、主要なダウンローディングステップが示される。
【００４４】
Ｅ１により参照される第１ステップは、“ＴａｂｌｅＩｄ，ＳｅｇｍｅｎｔＮｂ＝０，ＯＵＩ，ＳｅｃｔｉｏｎＳｙｎｔａｘＶｅｒｓｉｏｎ，ＦｌｏｗＶｅｒｓｉｏｎＩｄ”のフィールド上でのセクションフィルタリングによってヘッダセグメントを取得することから構成される。
【００４５】
Ｅ２により参照される第２ステップは、それのシグネチャを用いて当該ヘッダセグメントの認証をチェックすることから構成される。
【００４６】
Ｅ３により参照される第３ステップは、
１．ダウンローディングを実行するデコーダのプラットフォーム（ＰＴ，ＰＶ）、製品ＰＲ及び利用ＵＳに専用のセグメント
２．プラットフォーム、製品、ＵＳ＝ａｎｙに専用のセグメント
３．（ＰＴ，ＰＶ）＝ａｎｙとなるプラットフォームに専用のセグメント  この場合、ＵＳの値は無視される。
４．製品、利用、（ＰＴ，ＰＶ）＝ａｎｙに専用のセグメント
５．製品、（ＰＴ，ＰＶ）＝ａｎｙ、ＵＳ＝ａｎｙに専用のセグメント
６．ジェネリックセグメント  すなわち、（ＰＴ，ＰＶ）＝ａｎｙ、ＰＲ＝ａｎｙ、ＵＳの値に無関係である。
を連続的に抽出することによって（以下のテーブルを参照されたい）、ダウンローディングを実行するデコーダに対応するセグメントのリストを構成することから構成される。
【００４７】
【表１】
0005995394.tif 000002
Ｅ４により参照される第４ステップは、新たなソフトウェアバージョンが利用可能になることによる更新のため、メモリに格納され、前の更新に対応する“ＳｅｇＶｅｒｓｉｏｎＩｄ”と異なる“ＳｅｇＶｅｒｓｉｏｎＩｄ”に対するセグメントを当該リストから単に抽出することから構成される。ダウンローディングがデコーダにおける一部のセグメントの損傷によるものである場合、復元されるバージョンは、すでに存在したものと同じであり、損傷していると特定されたセグメントが復元される。
【００４８】
第５ステップは、各セグメントのＣＲＣを利用して復元される各セグメントのインテグリティをチェックすることから構成される。
【００４９】
第６ステップは、メモリにダウンロードされたセグメントを格納することから構成される。
【００５０】
本発明の上記実施例はデジタルテレビデコーダのフレームワークの範囲内のものであるが、当業者には、本発明がデータ配信ネットワークを介しそれらの常駐ソフトウェアの更新機能を有するすべての装置に適用可能であるということが理解されるであろう。
【図面の簡単な説明】
【００５１】
【図１】図１は、ダウンローディングソフトウェアをデコーダセットに配布するシステムの既知の構成を示す。
【図２】図２は、デコーダのソフトウェア構成の一例を示す。
【図３】図３は、本発明の実施例による常駐ソフトウェアの各種分割レベルを示す。
【図４】図４は、本発明の実施例によるヘッダセグメントを示す。
【図５】図５は、本発明の実施例によるＭＰＥＧセクションのフォーマットを示す。
【図６】図６は、本発明の実施例によるダウンロードの必要があるセグメントを検出ため、デコーダによって利用される方法の各ステップを示す。
【図７】図７は、本発明の実施例によるデコーダの構成を示す。
【図１】
0005995394.tif 000003
【図２】
0005995394.tif 000004
【図３】
0005995394.tif 000005
【図４】
0005995394.tif 000006
【図５】
0005995394.tif 000007
【図６】
0005995394.tif 000008
【図７】
0005995394.tif 000009