JP2007528534A - システムソフトウェア更新サービスを通知するためのローダの利用 - Google Patents

Abstract

通信インタフェースを介しアップグレード可能な不揮発性メモリ内に含まれるソフトウェアを有する受信機。当該受信機は、ソフトウェア更新を検索し、ロードするとう動作モードと共に機能するスタンバイモードを提供する。利用可能な更新が検出されると、受信機はソフトウェア更新が当該更新のロード及びインストールを可能にするのに利用可能であるという表示を記録する。受信機は、スタンバイモードにおいて更新を特定することが可能であり、動作モードへの移行により、ソフトウェア更新が利用可能であるという表示が特定され、その後、システムソフトウェアが新しいソフトウェア更新をロードするという表示を受信機のために生成することが可能である。受信機は、動作モード中ソフトウェア更新を検索することが可能であり、利用可能な更新が検出されると、受信機はそれをメモリにロードし、スタンバイモードに再移行すると、メモリに格納されている更新が、次の動作モード移行時に利用可能となるように、所定の不揮発性メモリに配置される。

Description

本発明は、受信装置に関し、より詳細には、セットトップボックスのソフトウェアアップグレードに関する。

セットトップボックスの現在の実現形態では、セットトップボックス内の受信機は、システムソフトウェアの更新を検索することに関する機能を有する。典型的には、セットトップボックスは、セットトップボックスの通常の配信受信機能を実行するシステムソフトウェアを有するであろう。さらに、システムソフトウェアアップグレードを実行するよう更新サービスを検出するため、受信機の内部にローダが実現される。受信機は、システムソフトウェアの更新（新たなシステムソフトウェアの記述、バージョン番号、システムソフトウェア更新の配信スタート時及びエンド時、システムソフトウェア更新の予測される期間など）に関するデータを取得するため、このシステムソフトウェア更新サービスを検出することが可能であることが必要とされる。上記従来の実現形態の問題点は、ローダとシステムソフトウェア内のシステムソフトウェア検索機能が、使用されている符号について異なるものとすることができ（ローダが第三者から購入される場合に生じうる状況）、システムソフトウェアとローダとの間の非互換性を生じさせるということである。これらの状況は、システムソフトウェアとローダとの間のシステムソフトウェアの更新を処理するのに、不整合性を導く可能性がある。例えば、システムソフトウェアは、システムソフトウェア更新サービスを検出し、ユーザにシステムソフトウェアの更新が開始されることを通知するかもしれない。しかしながら、ローダが通信又は基本的互換性の欠落によりシステムソフトウェア更新サービスを検出しない場合、システムソフトウェアの更新は行われないであろう。

上記説明から、システムソフトウェアを整合的に更新可能なシステムソフトウェアとローダ構成について、セットトップボックスの技術分野内で必要とされていることは明らかである。

本発明は、少なくとも第１モードが受信機の通常の動作モードであり、第２モードが受信機のソフトウェア更新を検索するように、受信機に関する複数のモードを有する受信機を提供し、当該モードの少なくとも１つによりソフトウェア更新を検索し、受信機内のモードの１つについてソフトウェア更新可能性を示し、利用可能なソフトウェア更新を受信機に転送し、転送されたソフトウェア更新を受信機にインストールすることによって、従来技術の問題点を解決する。

本発明の課題は、ネットワークに接続され、ネットワーク接続を介しアップグレード可能なシステム内の不揮発性メモリにより構成されるシステムを提供することである。

本発明のさらなる課題は、システムがソフトウェア更新を検索し、ソフトウェア更新が利用可能であるという指標をシステムに提供するスタンバイモードをシステムに提供することである。

本発明のさらなる課題は、システムがソフトウェア更新が利用可能であるという指標を認識し、システムソフトウェアがソフトウェア更新をロードする動作モードをシステムに提供することである。

本発明のさらなる課題は、動作モード中に利用可能なソフトウェア更新を検索し、利用可能なソフトウェア更新をシステムに転送可能な動作モードをシステムに提供することである。

本発明のさらなる課題は、スタンバイモードに再び入ると、ローディングプログラムがシステムに転送されたソフトウェア更新をロードするスタンバイモードをシステムに提供することである。

上記及び他の課題が、ネットワークに接続され、ネットワーク接続を介しアップグレード可能な不揮発性メモリ内に含まれるソフトウェアを有するシステムによって提供される。システムは、それがソフトウェア更新を検索し、利用可能な更新が検出される場合、ソフトウェア更新が利用可能であるという指標を記録するスタンバイモードを提供する。システムがある動作モードに入ると、ソフトウェア更新が利用可能であるという指標がシステムによって特定され、その後、システムソフトウェアがこの新しいソフトウェア更新をロードする。システムは、この動作モード中にソフトウェア更新を検索することが可能であり、利用可能な更新が検出されると、システムはそれをメモリにロードし、スタンバイモードに再び入ると、メモリに格納されている更新が所定の不揮発性メモリに配置され、これにより、次に動作モードに入ると、当該更新が利用可能となる。

図１は、本発明を実現するのに使用されるローダ１０のフローチャートである。図２は、上記フローチャート及び図１によって示されるローダ１０のアルゴリズムを実行可能な典型的なセットトップボックス内のハードウェア５０のブロック図である。

図２を参照するに、セットトップボックスのハードウェア５０は、入出力コントローラ６０の直接的な制御の下で動作するフロントエンド６２を有する。フロントパネルコントロール６４は、リモコンとすることが可能であり、入出力コントローラ６０にコマンドを与える。入出力コントローラ６０はまた、ＩＥＥＥ１３９４インタフェース６６又はＲＳ２３２インタフェース６８を介しデータを送受信することが可能である。セットトップボックスハードウェア５０によって受信されるデータは、フロントエンド６２に入力され、その後、メモリ５８に置かれる。メモリ５８は、揮発性又は不揮発性メモリとすることが可能であり、好ましくは、あるタイプのＤＲＡＭである。セットトップボックスを実行するシステムソフトウェアは、典型的には、フラッシュメモリなどの不揮発性タイプのメモリ内に配置される。例えば、ＥＥＰＲＯＭ、ＦＬＡＳＨメモリ又は電池駆動ＤＲＡＭなどの他のタイプの不揮発性メモリがあり、そのすべてが書き込み可能であるが、システムの電力が除去されると、それらのコンテンツを失うことはない。ＦＬＡＳＨ５２は、現在のバージョンのシステムソフトウェアを保持するため、本発明の好適な実施例によって利用されるフラッシュメモリである。セットトップボックスハードウェア５０は、ＣＰＵバス７５を介しＣＰＵ７０の制御の下で動作する。ＣＰＵ７０とＦＬＡＳＨ５２に加えて、ＤＲＡＭ５４とメモリ５６もまた、ＣＰＵ７０によって利用可能なリソースとしてＣＰＵバス７５上に配備される。さらに、ＣＰＵ７０は、独立した専用のバスを介しビデオグラフィックス７２とインタフェースをとる。この好適な実施例によって示されるように、ビデオグラフィックス７２は、少なくとも１つのメモリリソースを有する。

好ましくは、セットトップボックスハードウェア５０において、そして典型的にはデジタルテレビドメイン内では、受信機（セットトップボックス又はデジタルテレビのための）のシステムソフトウェアは、フラッシュメモリが不揮発性であり、書き込み可能であるため、大部分はフラッシュメモリに格納される。ＦＬＡＳＨ５２は、システムソフトウェアを格納するのに利用される好適な実施例のうちのフラッシュメモリである。セットトップボックスハードウェア５２は、書き込み可能な不揮発性メモリ内のシステムソフトウェアを更新可能であるため、フラッシュメモリを用いてシステムソフトウェアを保持する。ＥＥＰＲＯＭや電池駆動不揮発性メモリなど、書き込み可能な他のタイプの不揮発性メモリが存在するが、設計及び製造の簡単さ、集積密度及び費用のため、フラッシュメモリが好適な実施例によって好ましい。

セットボックスハードウェア５０において、典型的にはデジタルテレビドメイン内において、典型的には、セットトップボックスのシステムソフトウェアに対する更新が、フロントエンド６２によって受信され、一時的にメモリ５８に配置される。新しいシステムソフトウェアは、典型的には、配信ストリーム内の別のサービスを介し配信される。システムソフトウェア更新を実行するため、セットトップボックスはまず、新しいシステムソフトウェアを含むサービスを検出し、その後、この新しいシステムソフトウェアをメモリ５８にロードし、最後に（新しいシステムソフトウェアが正しいことを検証した後）、新しいシステムソフトウェアを、この好適な実施例ではＦＬＡＳＨ５８メモリである特定タイプの不揮発性メモリに格納する。

ソフトウェアの観点から、好適な実施例は、セットトップボックスの受信機部分が２つの基本的コンポーネントを有することを想定する。第１コンポーネントは、セットトップボックス上で実行されるシステムソフトウェアであり、第２コンポーネントは、システムソフトウェアへのアップグレードを抽出するローダ１０である。

システムソフトウェアは、受信機の通常の動作を提供するソフトウェアである。ローダ１０は、システムソフトウェア更新サービスを検索し、実際のソフトウェアアップグレードを実行するソフトウェアである。システムソフトウェアとローダ１０は、従来、同時に実行することはできなかった。

受信機の現在の実現形態は、システムソフトウェアとローダの両方の内部においてシステムソフトウェア更新サービスを検索する機能を有する。これら従来の実現形態は、完全には互換的でない検索機能をもたらすことが可能である。この状況は、システムソフトウェア更新の抽出において不整合性を導く可能性がある。

本発明は、ローダ１０が２つの異なるモードにより開始可能となるように拡張される機能を有するローダ１０を提供することによって、上記問題点を解決する。第１モードは、ローダ１０がシステムソフトウェア更新サービスを検索することを可能にする。第２モードは、ローダ１０がシステムソフトウェア更新サービスを検索することを可能にし、ローダ１０が当該サービスを検出する場合、それはシステムソフトウェア更新の実行を開始する。第１モードは、現在のローダ実現形態では提供されていない。本発明は、システムソフトウェア更新サービスを自ら検索せず、代わりに、別のローダ１０を用いて上述の第１モードと同様に、システムソフトウェア更新サービスを検索する機能を実行するシステムソフトウェアを提供する。

上述のように、ローダ１０とシステムソフトウェアは、典型的には同時には実行しない。典型的には、フラッシュ又はＥＥＰＲＯＭなどの不揮発性メモリ内の位置は、ローダ１０又はシステムソフトウェアが、電源オンへの切り替え後、又はリセットの実行後、開始されねばならないか示すのに利用される。さらに、フラッシュやＥＥＰＲＯＭなどの不揮発性メモリ内などの当該不揮発性メモリは、ローダとシステムソフトウェアとの間で情報（例えば、システムソフトウェア更新サービスを参照するロケータなど）をわたすのに利用される。システムソフトウェア更新サービスを検出するため、システムソフトウェアにローだ１０を使用させる１つの方法は、以下の通りである。すなわち、受信機がスタンバイに移行しようとするとき、システムソフトウェアはローダに情報をわたし、その後受信機をリセットする。受信機は、ローダ１０がシステムソフトウェア更新サービスを検索する第１モードによりローダ１０を開始する。ローダ１０が検索を終了すると、それはスタンバイモードに受信機を置く。受信機が再びオンされると（すなわち、スタンバイモードから離れると）、システムソフトウェアは、ローダ１０がシステムソフトウェア更新サービスを検出したかチェックする。フラグの設定、ソフトウェアのセマフォの変更、システムソフトウェアによる対応する動作を可能にすることなど、システムソフトウェアがローダ１０によって返される状態を検証可能な多数の方法が存在する。ローダ１０が更新が利用可能であることを示す場合、システムソフトウェアは、当該サービスに調整され、当該更新をセットトップボックスにダウンロードするのに必要な任意の情報を抽出する。

図１は、本発明の好適な実施例のローダ１０の動作を示すフローチャートである。本発明の好適な実施例によって示されるようなローダ１０は、典型的には、ここではコールドブートと呼ばれるシステムが最初にオンされると、開始される（１５）。しかしながら、多数のルーチンがローダ１０を起動可能であるということに留意すべきである。本発明の好適な実施例は、動作モード又はスタンバイモードの何れかにより行われる図１のアルゴリズムへの呼び出しを説明する。図１に示されるアルゴリズムの実行は、一般にはスタート１５として呼ばれる。呼び出されると（最初のオン又はモード変更中など）、ローダ１０は２つのタスクを実行する。第１タスクは、ソフトウェア画像が現在システムにある画像をチェックする現在画像を検証１３することである。現在画像の検証１３は、それが損傷しているか、好ましくは、当該画像のチェックサム又はＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋｓｕｍ）を計算することによって実現されるか判断するため、現在画像をチェックする。ＣＲＣは、２つの画像又はファイルが同一であるか決定することが可能である。ＣＲＣ機能は、典型的には、画像又はファイルの各バイトを処理する。画像又はファイルにおける相違は、異なるＣＲＣ数を生成するであろう。しかしながら、現在画像を検証する他の実現形態が可能であり、当業者には容易に明らかとなるであろう。

第２タスクは、強制されたダウンロードシーケンス１２をチェックするためである。本発明によって想定されるような強制されたダウンロードシーケンスは、リモコン又は受信機の所定のボタンシーケンスを入力することによって、セットトップ装置のホームユーザにより起動可能である。さらに、強制されたダウンロードシーケンスは、修理店のサービススタッフによって起動可能である。起動されると、強制されたダウンロードシーケンスは、ここで標準画像と呼ばれるものを抽出する。この標準画像は、当初セットトップ装置に配置されていた画像である。

現在画像の検証１３を実行する前に、必要なシーケンスが現在画像の検証１３を行う前に、強制されたダウンロードシーケンスを開始するよう入力されていなかった場合、強制されたダウンロードシーケンスについてチェックを行う実施例が考えられる。しかしながら、好適な実施例は、現在画像を検証する前に、ダウンロードシーケンス１２のチェックを実行しない。なぜなら、強制されたダウンロードシーケンスのチェックは、破滅的なイベントに関するものであり、システムに入力がなされることを要求し、ほとんど実行される必要がない機能について時間を要する。好適な実施例では、強制されたダウンロードシーケンス１２のチェックは、現在画像の検証１３とパラレルに実質的に実行される。強制されたダウンロードシーケンス１２と現在画像の検証１３の各機能は、互いに独立に実行されてもよく、この好適な実施例では独立に行われる。本好適な実施例はまた、強制されたダウンロードシーケンス１２と現在画像の検証１３の各機能が、パラレルに実行される２つの機能として実現されることを可能にするシステム内のハードウェアを提供する。

ローカルダウンロードサーバのテスト１４は、ローダが強制されたダウンロードシーケンス１２を実行した後、ダウンロード可能な利用可能なアップグレードを有するダウンロードサーバを検索するであろう。ローカルダウンロードサーバは、ユーザが修理のためシステムを持ち込み可能なローカルショップにおいて、又はセットトップボックスと同じ場所にあるＰＣ上で実行されるソフトウェアとすることが可能である。ローカルダウンロードサーバのテスト１４は、システムのソフトウェア画像がダメになり、何れのソフトウェア画像も現在配信されていない例において有用である。ローカルダウンロードサーバの使用は（家庭又は店において）、ユーザが再びシステムに正しいソフトウェア画像を取得することを可能にする。ローカルダウンロードサーバが緊急の状況において利用されることは、本好適な実施例の意図である。ダウンロードサーバが検出される場合、当該サーバにおいて利用可能な画像は、選択された画像となるであろう。

ローカルダウンロードサーバのテスト１４が実行されると、判定ブロック４１はローカルダウンロードサーバのテスト１４の結果を特定し、これに応じてプログラム処理を順序を決定する。判定ブロック４１が何れのダウンロードサーバも検出されないと判断する場合、判定ブロック４２は、前述のように強制されたダウンロードシーケンスが検出されたか判断するであろう。判定ブロック４２が、強制されたダウンロードを検出しないと判断した場合、ローダ１０は、画像の選択１６を実行する。画像の選択１６は、ローダ１０がソフトウェア更新を配信された信号から検索するステップである。典型的な処理では、ローダ１０は、ダウンロードサーバ又は強制されたダウンロードを検出せず、従って、画像の選択１６が通常は実行されるであろう。ソフトウェア更新が利用可能である場合、ローダ１０は、当該更新をセットトップボックスに抽出するため、選択された画像のダウンロード２８の機能を実行するであろう。判定ブロック４３は、可能な損傷について画像をテストするであろう。判定ブロック４３が、現在画像が損傷していると判断する場合、ローダ１０は更新をセットトップボックスに抽出するため、選択された画像のダウンロード２８を実行する。典型的には、１つの特定のシステムについて任意の時点において配信される１つのみのソフトウェア画像が存在するであろう。上述のように、判定ブロック４１がダウンロードサーバが検出されたと判断すると、当該サーバから利用可能な画像が選択された画像となるであろう。

判定ブロック４４は、選択された画像が現在画像であるか特定するであろう。判定ブロック４４が選択された画像がセットトップボックス内で現在使用されている画像と同一であると判断することが、全く可能性がある。現在画像が選択された画像である場合、フラッシュメモリに現在書き込まれている画像は正しいものであり、当該ルーチンが終了することを仮定する。損傷についての画像のテストにおける判定ブロック４３と、現在画像が選択された画像であるか特定する判定ブロック４４によって実行される各機能は、１つの機能に合成可能であるということは、当業者に容易に明らかであろう。選択された画像が現在画像と同一であるという可能性があるということに留意すべきである。これは典型的には、ソフトウェアアップグレードの成功後に発生し、１つのソフトウェア画像が何ヶ月又は何年も配信されるかもしれないため、珍しいことではない。

判定ブロック４１がダウンロードサーバが検出されると判断する場合、ローダは、前述のように当該サーバから更新を抽出するため、選択された画像のダウンロード２８を実行する。

選択された画像のダウンロード２８が実行された後、選択された画像は、判定ブロック４６においてそれが正しくダウンロードされたことを検証するためテストされる。選択された画像のダウンロードが成功したと判定ブロック４６によって判断された場合、ダウンロードされた画像の検証２０は、当該画像が損傷しているか判断し、判定ブロック４７は、これに応じてプログラム処理を分岐させる。判定ブロック４７がダウンロードされた画像が損傷していると判断する場合、既存の画像をロードするため、現在画像のロード２６に分岐される。判定ブロック４７がダウンロードされた画像が損傷していないと判断する場合、画像はフラッシュメモリに書き込まれ、ローダ１０はシステムソフトウェア処理を返す。判定ブロック４９が当該書き込みが不成功であると判断した場合、処理は標準画像のダウンロード１８に分岐する。

選択された画像のダウンロード２８に戻って、選択された画像のダウンロードが判定ブロック４６によって失敗しなかったと判断される場合、現在画像のロード２６によって既存の画像を復元するためのステップが行われる。その後、既存の画像は、判定ブロック４８によって損傷についてテストされる。既存の画像に損傷がないと判明すると、プログラム処理は、標準画像のダウンロード１８に分岐し、再び判定ブロック４６は、それが標準画像であるときのみ当該画像をテストする。

再び判定ブロック４１に戻って、ダウンロードサーバが検出されないと判断されると、強制されたダウンロードシーケンスの指標が存在するか特定するため、プログラムは判定ブロック４２に分岐する。強制されたダウンロードシーケンスが検出される場合、処理は、当初の画像をセットトップボックスに抽出するセットトップボックスへのシーケンスのダウンロードを開始するであろう。その後、処理が再び判定ブロック４６に分岐し、ダウンロードの適切さがチェックされる。判定ブロック４６が当該画像が適切にダウンロードされたと判断する場合、当該画像は検証され、前述のように、フラッシュメモリに書き込まれる。判定ブロック４７が当該画像が損傷していると判断すると、システムは現在画像のロード２６を実行する。現在画像の検証が成功すると、当該ルーチンは終了２４する。現在画像が適切に検証されていない場合、画像を訂正及び復元するためのステップが実行される。

本発明は、システムソフトウェアとローダ１０が互いに完全に認識しているため、ローダが何れかの方法により互換的であることを保証しながら、システムソフトウェア更新サービスを検索する機能を実現する効果を提供する。好ましくは、ローダ１０とシステムソフトウェアは、同一のコードを使用する。さらに、ローダ１０とシステムソフトウェアの構成に対する集中化されたアプローチを有するシステムソフトウェアのサイズは、低減される。好適な実施例は、ＥＴＳＩ ＴＳ １０２００６ ＶＩ．２．１（２００２−１０），Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｆｏｒ Ｓｙｓｔｅｍ Ｓｏｆｔｗａｒｅ Ｕｐｄａｔｅ ｉｎ ＤＶＢ Ｓｙｓｔｅｍｓに詳述されるようなＤＶＢシステムのシステムソフトウェア更新の仕様を利用する。

上記説明は、発明者によって最も好適な実施例を説明している。これらの実施例の変形が、当業者に容易に明らかとなり、これに応じて、本発明の範囲は上述の実施例によって限定されるものではなく、添付された請求項によって決定されるべきである。

図１は、本発明の好適な実施例を示すフローチャートである。 図２は、図１のアルゴリズムを実行するセットトップボックスのブロック図である。

Claims (18)

1. ソフトウェアを更新する方法であって、
   少なくとも第１モードがセットトップ装置の通常の動作モードであり、第２モードがソフトウェア更新を検索するように、受信機について複数のモードを実現するステップと、
   前記モードの少なくとも１つによりソフトウェア更新を検索するステップと、
   利用可能なソフトウェア更新が発生すると、前記受信機内で前記モードの１つに示すステップと、
   利用可能なソフトウェア更新を前記受信機に転送するステップと、
   転送されたソフトウェア更新をプログラマブル装置にインストールするステップと、
   を有することを特徴とする方法。
2. 請求項１記載の方法であって、
   前記実現するステップはさらに、前記複数のモードとして動作モードとスタンバイモードを有することを特徴とする方法。
3. 請求項２記載の方法であって、
   前記検索するステップと前記転送するステップは、前記スタンバイモードにより実行されることを特徴とする方法。
4. 請求項２記載の方法であって、
   前記検索するステップと前記転送するステップは、前記動作モードにより実行されることを特徴とする方法。
5. 請求項３記載の方法であって、
   前記検索するステップはさらに、前記スタンバイモードにおいてソフトウェア更新を検索し、ソフトウェア更新が検出されると、ソフトウェア更新が利用可能であるという表示がなされることを特徴とする方法。
6. 通信インタフェースを有する受信システムであって、当該システムは、ネットワーク接続を介しアップグレード可能な不揮発性メモリにソフトウェアを有し、
   当該受信システムが動作モードにより通常は機能し、スタンバイモードは前記動作モードと同時に機能しない、前記動作モードに関してソフトウェア更新をインストールするよう機能する当該受信システム内のスタンバイモードと、
   前記動作モード又は前記スタンバイモードの何れかにより動作し、前記動作モード又は前記スタンバイモードの他方によって使用されるソフトウェア更新の利用性の表示を、該表示を特定し、ソフトウェア更新を受信機にインストールするのに供するよう提供するルーチンと、
   を有することを特徴とする受信システム。
7. 請求項６記載のシステムであって、
   前記スタンバイモードは、ソフトウェア更新の存在を特定し、
   前記動作モードは、前記受信機に利用可能な更新をインストールする、
   ことを特徴とするシステム。
8. 請求項６記載のシステムであって、
   前記動作モードは、利用可能なソフトウェア更新の存在を特定し、
   前記スタンバイモードは、利用可能なソフトウェア更新を前記受信機にロードする、
   ことを特徴とするシステム。
9. 請求項６記載のシステムであって、
   前記ルーチンは、以降において前記不揮発性メモリに配置されるソフトウェア更新を揮発性メモリに配置することを特徴とするシステム。
10. 請求項９記載のシステムであって、
    前記ルーチンは、前記スタンバイモードにおいてソフトウェア更新を前記揮発性メモリに配置し、
    前記受信機は、前記動作モードへの再移行の後、ソフトウェア更新を前記不揮発性メモリに配置する、
    ことを特徴とするシステム。
11. 変更可能な不揮発性メモリを有する受信システムであって、
    当該受信システム内の処理手段の制御の下、前記不揮発性メモリに動作可能に接続される当該受信システムの通信インタフェースと、
    当該受信システムの通常動作を実行する受信機内のシステムソフトウェア手段と、
    ソフトウェア更新を検索し、検出された更新を抽出する前記システムソフトウェア手段とは独立に機能するローダと、
    を有し、
    前記ローダは、複数の所定のイベントの１つの発生に応答して実行することを特徴とするシステム。
12. 請求項１１記載の受信システムであって、
    前記システムソフトウェア手段は、当該システムが配信された信号を受信するよう動作する動作モードにより実行され、
    前記ローダは、通常の配信受信機能が非イネーブルとされるスタンバイモードにより実行される、
    ことを特徴とするシステム。
13. 請求項１２記載の受信システムであって、
    前記動作モードは、ソフトウェア更新が前記ローダに利用可能であると特定し、
    前記ローダは、利用可能なソフトウェア更新を抽出する、
    ことを特徴とするシステム。
14. 請求項１２記載の受信システムであって、
    前記スタンバイモードは、利用可能なソフトウェア更新を特定し、
    前記動作モードは、利用可能なソフトウェア更新をインストールする、
    ことを特徴とするシステム。
15. 請求項１２記載の受信システムであって、
    前記受信機は、前記スタンバイモードにおいて更新を特定することが可能であり、前記動作モードに移行すると、ソフトウェア更新が利用可能であり、前記受信機がその後前記新たなソフトウェア更新をロードするという表示を前記受信機のために生成可能であることを特徴とするシステム。
16. 請求項１１記載の受信システムであって、
    前記複数の所定のイベントはさらに、当該受信システムに電力を印加することを有することを特徴とするシステム。
17. 請求項１１記載の受信システムであって、
    前記複数の所定のイベントはさらに、受信システム上のチャネルを変更することを有することを特徴とするシステム。
18. 請求項１１記載の受信システムであって、
    前記複数の所定のイベントはさらに、当該受信システムへの入力を有することを特徴とするシステム。

Images