(57)【要約】【課題】ケーブルシステム中の種々のホストに対してソフトウェアモジュールを組織的に配布するためのシステムと方法を開示する。【解決手段】ダウンロードマネージャーは、ケーブルシステム中の種々のホストに対して、要求されかつ両立し得るソフトウェアオブジェクトの配布を確実にする。本システムは種々のソフトウェア依存性及びホストの特質をネットワーク運用者から抽出し、そうでなければエラーを起こしがちな過程において、種々のホストのためにホストソフトウェアの容易で効率的なアップデートを可能にする。本システムは、ホストをあるホストプロファイルに関係付ける目的で、ホストがネットワークに対して自己を識別できるようにし、これにより必要で互換性のあるソフトウェアモジュールだけがダウンロードされることを確実にする。本システムはまたサイトプロファイルデータを用いてホストへの配布のための適切なソフトウェアモジュールを決定する。【選択図】図１
2007280392.tif 000002
【特許請求の範囲】
【請求項１】
ケーブルシステムに接続されたホストからホスト識別データを受け取るステップと；
該ホスト識別データを用いて該ホストに対するホストプロファイルを決定するステップと；
加入者は該ホストに関係付けられるが、該ホスト識別データに基づいて加入者に対する加入者サービスプロファイルを決定するステップと；
該ケーブルシステムに関連付けられたサイトプロファイルを決定するステップと；
該加入者サービスプロファイルと、該サイトプロファイルと、該ホストプロファイルとに基づいて、該ホストへのダウンロードのためにソフトウェアオブジェクトライブラリーから少なくとも一つのソフトウェアオブジェクトを選択するステップと；
該ケーブルシステムで発信するために該ソフトウェアオブジェクトをダウンロードマネージャーにロードするステップと；
該ソフトウェアオブジェクトを取得するように該ホストに指示するステップ；及び
該ソフトウェアオブジェクトを該ホストに発信するステップと：
から成るソフトウェアモジュールを配布する方法。
【請求項２】
該ホスト識別データがメーカーと関係付けられるメーカー識別子及び該メーカーにより生産されたホストモデルと関係付けられるモデル識別子を含む、請求項１記載の方法。
【請求項３】
該ホスト識別データが業界で承認されたホストプロファイルと関係付けられる英数字値を含む、請求項１記載の方法。
【請求項４】
該ホストプロファイルが該ホストと関係付けられた総称的ホストプロファイルと、該ホストと関係付けられたホスト目録プロファイルとを処理することにより決定される、請求項１記載の方法。
【請求項５】
該ホストが該ケーブルシステムへの最初の接続の際に、該ホスト識別データの発信を開始する、請求項１記載の方法。
【請求項６】
該ホストプロファイルはメーカーの定義されたホストプロファイルである、請求項１記載の方法。
【請求項７】
該メーカーの定義されたホストプロファイルはメーカーを識別するための該ホスト識別データの第一部分と、ホストモデルを識別するための該ホスト識別データの第二部分とを用いて識別される、請求項６記載の方法。
【請求項８】
該複数のホストプロファイルから一つを選択することは、業界取引グループによって定義される複数のホストプロファイルから一つを識別することを含む、請求項１記載の方法。
【請求項９】
該複数のホストプロファイルから一つを選択することは、該ホストと関連付けられたホスト目録プロファイルを識別するために該ホストによって発信された英数字シリアル番号を使用することを含む、請求項１記載の方法。
【請求項１０】
該ホスト目録プロファイルが、該ホストに以前にダウンロードされたソフトウェアモジュールを識別する、請求項９記載の方法。
【請求項１１】
該加入者サービスプロファイルは該ケーブルシステムに関係付けられた該加入者に提供されるサービスを示し、該ホスト識別データは該加入者と関係付けられている、請求項１記載の方法。
【請求項１２】
該サイトプロファイルは該ケーブルシステムにおいてホストへのサービスを提供することと関係付けられた機能的能力に関するデータを含む、請求項１記載の方法。
【請求項１３】
該サイトプロファイルはケーブルネットワーク上でサービスを提供することと関係付けられたソフトウェアバージョン識別子を更に含む、請求項１記載の方法。
【請求項１４】
該ソフトウェアオブジェクトライブラリーは複数のホストに対する複数のソフトウェアオブジェクトを含み、該複数のホストは複数のメーカーと関係付けられており、該ソフトウェアオブジェクトライブラリーは単一のメーカーからの複数のホストモデルに対応する複数のソフトウェアオブジェクトを更に含む、請求項１記載の方法。
【請求項１５】
第二のソフトウェアオブジェクトを該第一のソフトウェアオブジェクトに関係付けられた規則に基づいて選択するステップを更に含み、該規則は、該第一のソフトウェアオブジェクトの実行が該ホストに存在する該第二のソフトウェアオブジェクトに基づいていることを示す、請求項１記載の方法。
【請求項１６】
該ソフトウェアオブジェクトは該ソフトウェアオブジェクトライブラリーにダウンロードされ、選択可能とされるに先立って認証される、請求項１記載の方法。
【請求項１７】
該ダウンロードマネージャーへの該ソフトウェアオブジェクトのロードは、該ソフトウェアオブジェクトの状態をアイドル状態から活性化された状態へ変化させることを含む、請求項１記載の方法。
【請求項１８】
該ホストに対する該ソフトウェアオブジェクトを取得するように指示することは、該取得すべきソフトウェアオブジェクトを識別するホストへＸＭＬに基づくダウンロードコマンドを送付することを含む、請求項１記載の方法。
【請求項１９】
該ホストへのソフトウェアの送信はカルーセルを使用することを含む、請求項１記載の方法。
【請求項２０】
ホスト識別データにより識別されるホストであって、ケーブルネットワークに接続されたホストをアップデートするためにダウンロードマネージャーにてコマンドを受け取るステップと；
該ホストに関連付けられたホストプロファイルを識別するステップと；
該ホストに関連付けられたホスト目録ファイルを識別するステップと；
該ケーブルネットワークに関連付けられたサイトプロファイルを識別するステップと；
少なくとも一つの第一のソフトウェアオブジェクトを識別するために該コマンド、該サイトプロファイル、該ホスト目録ファイル、及び、該ホストプロファイルを使用するステップと；
該少なくとも一つの第一のソフトウェアオブジェクトがダウンロードマネージャーにおいて活性化されている事を決定するステップと；
該少なくとも一つの第一のソフトウェアオブジェクトをカルーセルから取得するように該ホストに指示するダウンロードコマンドを該ホストに生成するステップと；
該カルーセル上の該第一のソフトウェアオブジェクトをケーブルネットワーク上に送信するステップと：
を含む、ソフトウェアをダウンロードする方法。
【請求項２１】
該ホスト識別データは、該ホストのメーカーと関連付けられたホストメーカー識別子と、該メーカーのホストモデルと関連付けられたモデル識別子とを含む、請求項２０記載の方法。
【請求項２２】
該ホスト識別データは、ユニークなホスト識別子を更に含み、かつホスト目録ファイルを識別するために使用される、請求項２１記載の方法。
【請求項２３】
該サイトプロファイルは、ケ―ブルネットワーク上でサービスを提供することと関係付けられた機能的能力を示す、請求項２０記載の方法。
【請求項２４】
該少なくとも一つのソフトウェアオブジェクトがソフトウェアオブジェクトライブラリーから取得される、請求項２０記載の方法。
【請求項２５】
該ソフトウェアオブジェクトライブラリーからの該第一のソフトウェアオブジェクトの取得することは、第二のソフトウェアオブジェクトが該第一のソフトウェアオブジェクトの適切な稼動に必要であることを示す、該第一のソフトウェアオブジェクトに関係付けられた規則に基づく第二のソフトウェアオブジェクトを取得することを含む、請求項２０記載の方法。
【請求項２６】
該ダウンロードマネージャーにより受領された該コマンドに基づいて該ホストにダウンロードするための第二のソフトウェアオブジェクトの取得を更に含む、請求項２０記載の方法。
【請求項２７】
該ケーブルネットワークと関係付けられた能力に関するデータから成り、該能力は該ケーブルネットワークに接続された該ホストに対して提供されるサービスを定義するために使用される、サイトプロファイルデータベースと；
ホストにダウンロードされる該ソフトウェアオブジェクトを含む、複数のソフトウェアオブジェクトを保存するソフトウェアオブジェクトライブラリーと；
該サイトプロファイルデータベース及び該ソフトウェアオブジェクトライブラリーに動作可能に接続され、該サイトプロファイルデータベースからサイトプロファイルデータを受け取ることができ、更に該ソフトウェアオブジェクトライブラリーから該ソフトウェアオブジェクトを受け取ることができ、該ソフトウェアオブジェクトを該ホストにダウンロードするように構成されるダウンロードマネージャーと；
該ホストと関係付けられたホストプロファイルデータを含み、ここで該ホストプロファイルデータは該ホストと関係付けられた能力を示すとともにホスト識別データを使用して指数付けされるが、該ホストと関係付けられた該ホストプロファイルデータを提供するよう構成される、デバイスマネージャーと；
該ホストプロファイルデータを受領するように該デバイスマネージャーと動作可能に接続され、更に該ダウンロードマネージャーが該ソフトウェアオブジェクトの配布を開始するように指示するためのダウンロードロードマネージャーに動作可能に接続され、該ホストと関係付けられた該ホスト目録プロファイルを受け取るために該デバイス提供マネージャーに動作可能に接続された登録サーバーと：
を含む、ケーブルネットワーク上のホストへソフトウェアオブジェクトをダウンロードするためのシステム。
【請求項２８】
該サイトプロファイルデータベースは機器識別子及びソフトウェアバージョン識別子を含む、請求項２７記載のシステム。
【請求項２９】
該ソフトウェアライブラリーは該ダウンロードマネージャーから離れて位置し、該ソフトウェアオブジェクトを要求に応じて該ダウンロードマネージャーに発信する、請求項２７記載のシステム。
【請求項３０】
該ダウンロードマネージャーは該サイトプロファイルデータベースからのデータを用いて該ソフトウェアオブジェクトライブラリーから該ソフトウェアオブジェクトを要求する、請求項２７記載のシステム。
【請求項３１】
該ダウンロードマネージャーは第二のソフトウェアオブジェクトを取得しダウンロードするために該ソフトウェアオブジェクトに関係付けられた規則を使用する、請求項２７記載のシステム。
【請求項３２】
加入者に提供されるサービスを示す加入者サービスプロファイルを更に含み、該加入者サービスプロファイルは該ホストに関係付けられ、該登録サーバーは更に加入者サービスプロファイルからサービスプロファイルデータを得るよう構成された、請求項２７記載のシステム。
【請求項３３】
該ソフトウェアオブジェクトの該ホストへダウンロードする前に、
ホスト特有のコマンドを該ケーブルネットワーク上のホストに生成させることができるデバイス提供マネージャーを更に含む、該請求項２７記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、「ケーブルシステム中のホスト装置にソフトウェアを配布するためのシステムと方法」と題する米国特許出願第１０／７１２，８９０号（２００３年１１月１２日提出）の全内容を包含している。
【０００２】
本発明は一般にケーブルネットワーク中のケーブルセットトップボックス及び集積デジタルケーブルレディテレビ（Ｉｎｔｅｇｒａｔｅｄ  Ｄｉｇｉｔａｌ  Ｃａｂｌｅ  Ｒｅａｄｙ  ＴＶｓ  （ＩＤＣＲ  ＴＶｓ））のようなホスト装置へのソフトウェアの配布に関するものである。
【背景技術】
【０００３】
ケーブルテレビネットワークは、テレビ番組の送付のための確立された通信網である。テレビ受像機に適合するように信号を処理するばかりでなく、ケーブルネットワークからの信号の処理を制御するために、ケーブルネットワークオペレーターによってしばしばセットトップボックス（ｓｅｔ−ｔｏｐ−ｂｏｘ  （ＳＴＢ））が顧客に提供される。たとえば、プログラム信号は圧縮したデジタル方式で送信されてもよく、ＳＴＢによってデジタル入力を持たないテレビに適合する方式に変換されなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＳＴＢはケーブルネットワークにより提供される双方向ビデオゲームやデータサービスのみならず、ビデオオンデマンド（Ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ  （ＶＯＤ））、プレミアムチャンネル、双方向テレビを含む他のサービスを容易にするために使用される。加入者がワールドワイドウェブを閲覧するために、ケーブルネットワーク事業者がＤＯＣＳＩＳ規格に基づくモデムを用いた高速データ（ｈｉｇｈ−ｓｐｅｅｄ  ｄａｔａ  （ＨＳＤ））サービスを提供することが非常に一般的になっている。ケーブルネットワーク事業者はしばしば同じＨＳＤインフラストラクチャを音声サービスの提供のために使用する。ＤＯＣＳＩＳ機能はＳＴＢに組み込まれてもよいし、別の物理的なユニットとして具体化されてもよい。
【０００５】
上記の種々のサービスの運用は、広く「ホストデバイス」又は単に「ホスト」と名付けられるいろいろな形式の装置を用いると容易に行われる。これらホストデバイスは典型的には加入者の敷地に設置されたケーブルネットワークに付加される。したがって、広く解釈すれば、ＤＯＣＳＩＳモデム、デジタルテレビ、ＩＰ電話及びセットトップボックスはホストの具体化例である。ホストはケーブルサービス事業者によって所有されて（そして顧客に貸し出されて）いてもよいし、顧客によって所有されていてもよい。ホストは独立した装置であってもよいし、また他の家電製品に組み込まれ得る。たとえば、テレビメーカーは独立のセットトップボックスを必要としないＣａｂｌｅＣＡＲＤ（登録商標）対応のテレビを提供しているが、そのような場合、ホストはテレビということになる。このように、種々の物理的装置や構成が可能である。ホストについては様々な実施の形態が可能である一方、本発明の原理は、他の実施の形態も本発明の範囲で可能ではあるが、セットトップボックスの形で開示される。
【０００６】
セットトップボックス（ＳＴＢ）の共通の機能の一つは、正当なユーザーだけがサービスを受けることを保証することであり、これはホストに常駐する種々のソフトウェアルーチンを利用することにより達成される。典型的には、ホストが最初に製造されるときにソフトウェアがホストに組み込まれるが、ホストの展開過程でソフトがアップグレードされてもよい。もしアップグレードの結果としてソフトウェアがホストに適合しなくなると、そのホストは完全又は部分的に働かなくなり、顧客は欲するサービスを受けられなくなったり、又はサービスが不適切に働いたりするであろう。セットトップボックスの構成が不適切である場合には、ユーザーは放送チャンネルを受信することはできるものの、オンデマンド映画を選択できなくなる可能性がある。
【０００７】
ケーブル事業者はソフトウェアをホストに配布するためのメカニズムを開発した。ソフトウェアを配布する共通の理由のひとつは、ホストに常駐するソフトウェアの欠陥を補正したり、ホスト又はネットワークの能力を増大させたりすることにある。ホストには多数の異なる形式があり、ソフトウェアにも異なるバージョンがある。そのためにソフトウェアの配布は複雑になる。典型的な場合、ホストの各形式は異なるソフトウェアモジュールを必要とする一方、これらモジュールはしばしば同一又は類似の機能を果たす。更にソフトウェアの配布を複雑にするのは、どの形式のホストに対しても、ネットワークに付属するあるメーカーから、いくつかのモデルのホストが、典型的に存在することである。例えば、あるケーブルネットワークは、複数のブランドのケーブルモデム又はＳＴＢを認識し、それぞれのデータやビデオサービスを提供するユニークなソフトウェアバージョンを持っている。更に問題を複雑にするのは、各メーカーが各モデルに対して、異なるソフトウェアをリリースするであろうということである。
【０００８】
更に、各ホスト装置は、適切に動作するためには特定の組み合わせのソフトウェアモジュールが必要とされるであろう。こうして、あるバージョンの特定の組み合わせのソフトウェアが、ホストにロードされ動いているという必要性とともに、ホストは複数のソフトウェアモジュールを要求するであろう。必要とされる特定の組み合わせは、ユーザーによって視聴されるサービスの特定のセットによるであろうし、他の理由でケーブルオペレーターによって規定されるであろう。
【課題を解決するための手段】
【０００９】
以上から明らかなように、ホストへのソフトウェアの配布は複雑であり、また潜在的にエラーを引き起こしやすい。ケーブルネットワーク事業者が使用され得るホストの形式を一種に限定し、全てのホストが同時にアップグレードされるよう要求すれば、こうした課題を単純化できるが、この手法はケーブルサービス事業者にとって妥当でなく、非現実的で、好ましくない。こうすると、提供されるサービスの多様性と柔軟性を制限しがちとなる。新しい形式のホスト装置が常に製造され、ケーブルネットワーク施設に付加されているという事実によって、ケーブルオペレーターによる新しいサービスの採用が容易になり、収入が増加する。予期されるように、ソフトウェア配布中にエラーが起こり、あるサービスについて顧客のホストが動作不能に陥って顧客に悪影響を与え、結果として顧客サービスに関する苦情を引き起こすという事態が起こり得る。こうした困難は、ホストにソフトウェアアップデートを送信する能力において存するわけではなく、ソフトウェア配布の管理において存するのである。ソフトウェア、ホスト、及び他の制限の種々の組合せ（後述するように）は、ケーブルネットワークにおけるソフトウェアの配布を複雑化する。したがって、ケーブルネットワークにおいて、ホストへのソフトウェアの配布の管理を容易にするシステムや方法が必要とされる。
【発明を実施するための最良の形態】
【００１０】
以下、添付図面を参照しつつ、本発明を更に詳細に説明するが、当該図面は、本発明の全てではないがいくつかの実施態様を示している。実際、これらの発明は多くの異なる形で具体化されていてもよいものであり、ここに説明される実施態様に限定されると解釈されるべきではない。むしろ、これらの実施態様は、適用され得る法的要求を発明の開示が満たすように提供されたものである。全文を通して、同一番号は同一要素を示す。特定の用語がここに使用されるが、それらは総称的、記述的な意味でのみ使用され、制限を意図するものではない。
【００１１】
本発明は「ケーブルシステム中のホスト装置にソフトウェアを配布するためのシステムと方法」と題する米国特許出願第１０／７１２，８９０号（２００３年１１月１２日提出）の主題に基づき、かつ補足するもので、該出願の内容は参照され全て本出願に含まれている。上述の特許出願は、ソフトウェア製造者からケーブルネットワーク中の強化サービスサーバーへのソフトウェアの配布を開示するものである。例えば、図１において、種々のホストソフトウェア製造者（典型的にはホストメーカーであるが、独立の第三者ソフトウェアプロバイダでもあり得る）が、ホストソフトウェアを彼らホストソフトウェア製造者のコンピュータ１００ａからインターネット１０５ａを通じて、又は他の通信ネットワークのいずれかを通じて、中心的なホストファイルデータベース１１０（Ｈｏｓｔ  Ｆｉｌｅ  Ｄａｔａｂａｓｅ  （ＨＦＤ））へダウンロードする。典型例では、ＨＦＤ１１０は、上述の出願に開示されているように、要求されるソフトウェアがインターネット１０５ｂを利用して一以上のケーブルネットワークと関係付けられる種々の強化サービスサーバー１１５ｃ（ＥＳＳ）へ再度ダウンロードされるまで、ファイルを保存する。さらなる詳細な説明と他の実施態様は上述の出願に見出すことができる。種々の実体間でソフトウェアを転送する種々の方式は、ソフトウェアを適切なＥＳＳ１１５に提供するための「プッシュ」又は「プル」モデル（又はそれらの組み合わせ）に基づいて定義され得る。他の実施態様は、ソフトウェアモジュールを搭載した記憶媒体（例えばコンパクトディスク）をホストソフトウェアプロバイダからケーブルシステムオペレーターへ郵送することを含む。この場合、ケーブルネットワークオペレーターはソフトウェアをＥＳＳにマニュアルで組み込む。
【００１２】
上述のスペシフィケーションに基づく本発明の１面は、適切なＥＳＳへのソフトウェアの送信や保存において、追加の柔軟性を含む。例えば、図１において、ローカルデータベース１１６がＥＳＳに付属してもよい。しかし、他の実施態様では、多重ＥＳＳシステム１１５ｃ、１１５ｂにサービスを提供する共通のローカルデータベース１１７が存在してもよい。共通ローカルデータベース１１７は、ＥＳＳシステム１１５ｂ  、１１５ｃを運用するオペレーターと同一のネットワークオペレーターによって運用されてもよいし、サービス事務局としての第三者によって運用されてもよい。更に、後に論議するように、適切なソフトウェアオブジェクトの選択的ダウンロードを更に助けるために、ソフトウェアのローカルデータベースに付加的能力が与えられてもよい。
【００１３】
図１に示された実施態様においては、ケーブルサービス事業者（ケーブルネットワーク事業者とも呼ばれる）（強化サービスサーバーによって具現化されるように）は必要に応じてホストソフトウェアにアクセスでき、それをロードし、かつ使用する権限を与えられると仮定される。図１はホストソフトウェアがケーブルネットワーク（例えば強化サービスサーバー）によって必要に応じて使用され得るようにＨＦＤに記憶されている様子を示す。ホストソフトウェアモジュールは必要に応じて（リアルタイムを含む）ＨＦＤからＥＳＳに送信され得る一方、ホストソフトウェアモジュール又はオブジェクトは、ソフトウェアモジュールのホストへの配布に先立って、ローカルデータベース経由でケーブル事業者に送信されることもできる。ここで用語「ソフトウェアオブジェクト」及び「ソフトウェアモジュール」との間において識別を意味するものではない。具体的には、ソフトウェアモジュールはケーブルネットワーク事業者によってＥＳＳによる使用に先立って他のローカルデータベースに保存されることができる（これについては図４ａ、４ｂに関連して論ずる）。ローカルデータベースは、図１に示すようにＥＳＳと統合されるか、ＬＡＮ又は他の通信手段経由でＥＳＳによりアクセスされ得る。後者では、該データベースはＥＳＳに局在するものとすることもでき、又は遠隔のもので複数のＥＳＳによってアクセスされることもできる。付加的なローカルデータベースの利用はホストモジュールにとって便利なローカル記憶を提供し、ＨＦＤからのダウンロードの反復を避け、要求に応じてソフトウェアモジュールを即座に配布できるようにする。更にソフトウェアをその使用に先立ってＥＳＳにダウンロードすることは、ケーブル事業者がそのソフトウェアの使用を要求しているＥＳＳに先立ってそのソフトウェアを有効化し、問題を正すことを許す。他の実施態様においては、ソフトウェアモジュールは、モジュールの使用が要求されるごとにＨＦＤから取得され、有効化されることができる。しかしこのことは、モジュールが複数回ダウンロードされることを引き起こす。ソフトウェアモジュールは、物理媒体（例えばディスク）のケーブル事業者への配送を含む他の方法によっても、ケーブル事業者によって取得され得る。
【００１４】
ソフトウェアモジュールを中央記憶装置（例えばＨＦＤ）からケーブル事業者へ転送する状況は、ソフトウェアモジュールをローカルデータベースからケーブルネットワーク上のホストへ転送する場合とは区別される。類似の用語が用いられるかもしれないが（例えばダウンロード、発信、配布）、含まれる手順は明確に異なる。
【００１５】
ケーブルオペレーターによりひとたびソフトウェアモジュールがローカルに記憶され、使用のために有効化されると、ケーブルネットワーク上でのソフトウェアモジュールの送信のために利用できる方法は、そのソフトウェアを配布するために使用されることができる。１つの利用できる方法は、どのホストがバスから情報を「ピックアップ」できるかをコントロールすることによって、ケーブルネットワーク上でソフトウェアを送信するために、ダウンロードマネージャーにおいて実行される「カルーセル」と呼ばれるプロセスを使用することを含む。「カルーセル」と言う用語は、回転する台の上から品物を含む箱を選択的に「ピックアップ」する回転カルーセル（ｓｐｉｎｎｉｎｇ  ｃａｒｏｕｓｅｌ）との類似性から由来するものと思われる。この箱は論理的にソフトウェアモジュールの保持に対応し、ホスト（ホストは情報を読むように指示するビットマスクコードを受け取るのであるが）はモジュールが前を通過するときにそれを「ピックアップ」する。ケーブルネットワーク事業者はソフトウェアモジュールをケーブルネットワーク上で定期的に送信してもよい（このプロセスは「回転（ｓｐｉｎｎｉｎｇ）」と呼ばれ、定期的に現れるカルーセルに相似する）。こうして、ホストは情報を受け取る機会を一度以上持ってもよい。「カルーセル」という用語はソフトウェアメーカーからＥＳＳへのソフトウェア配布には適用されない。この用語はＥＳＳからケーブルネットワーク上のホストへのソフトウェア配布に適用される。
【００１６】
ホストは、あるモジュールをダウンロードコマンドに基づいて「ピックアップ」あるいはコピーするよう別々に指示される。ダウンロードコマンドは、一実施態様においては、ホストがいつ「聞き」、モジュールをコピーするかを指示する、論理的ビットマスクと考えられ得る。ダウンロードコマンドはまた、ホストが前提条件として必要なモジュールを未だに持っていないとき、更にどのモジュールが前提条件として必要かといった更なる情報を伝えることができる。そのような手順はケーブルネットワークの技術ではよく知られている。典型的に、ダウンロードコマンドは人間が解読し、直接プログラムするのは容易ではない低水準コマンドである。
【００１７】
カルーセルは概念的にはソフトウェアをホストに「ダウンロード」する手法として高水準と見なせるが、カルーセルは図１に示したようなインターネット上のダウンロード機構と同一のダウンロード機構ではない。図１では、情報のダウンロードは単一の源である実体から単一の行き先へ（ポイントからポイントへ）情報を転送するためにコンピュータネットワークや関連する手続きを使用する事を含んでもよい。しかしホストへのソフトウェアの配布は、典型的な場合積極的な受領の確認もエラーの際再送を要求する能力ももたらさない。一般的に、本発明の発明性のある原理の多くは、ソフトウェアをケーブルオペレーターからホストへと同様に、ソフトウェア製作者からケーブルオペレーターへ発信するために使用される通信手段に関係なく適用できる。説明の目的のため、ホストへのソフトウェアの配布はカルーセルを用いて説明される。
【００１８】
図２ａと２ｂは上記のソフトウェアオブジェクトのローカル記憶装置（ローカルデータベースとも呼ばれる）の代替となる実施態様を開示している。ホストファイルデータベースがソフトウェアを配布するとき、典型的には複数の形式のソフトウェアオブジェクトを用意する。これらの形式は異なる販売者、異なるバージョン、そして異なる製品のソフトウェアオブジェクトを含む。ある特定のケーブルオペレーターが全ての形式を要求することはなくてもよいと予想される。したがって、必要とされないソフトウェアオブジェクトの保存を避けるために、どれが必要かを選択的に識別する何らかのメカニズムが要求される。
【００１９】
図２ａにおいて、そのような実施態様の一つが開示されている。破線４３０は、これが「サイト」又は「論理的」ケーブルネットワークを指すことを示している。ケーブルオペレーターは多数のケーブルシステムを持ってもよく、それらは異なる都市に存在することが多い。これらはケーブルオペレーターによって論理的にまったく異なるシステムではあるが、ケーブル事業者の事業の総合的部分の範囲内にあると見なされ得る。ケーブルオペレーターが、異なる販売者の装置が使用されていたり又は異なる能力を備える装置又は異なるバージョンのソフトウェアが使用されたりしているケーブルサブシステムを所有することも典型的である。図２ａにおいては、単一のケーブルネットワークが示唆されており、ソフトウェアオブジェクトはデータベース４１６にローカルに保存されている。これらは種々の方法でＨＦＤから得てもよい。それらのいくつかについては既に述べた。
【００２０】
「サイトプロファイルデータ」４１２のセットは、どのソフトウェアオブジェクトがそのサイトにとって適用可能かに強い影響を与える、サイトの特質に関する情報を記述する。サイトの特質はケーブルネットワークに配置された機器のメーカー、配置されたソフトウェアのバージョン、ソフトウェアの互換性についての情報、ソフトウェアと機器の性能等を含んでもよい。例えばソフトウェアオブジェクトライブラリー４１６はあるバージョンのブランドＸ、Ｙ、Ｚのセットトップボックスのためのモジュールを保存してもよいが、サイトプロファイルデータ４１２はブランドＸとＹの装置のみがこのケーブルネットワークサイトで使用されていることを示してもよい。別の例では、サイトプロファイルデータはそのサイトのビデオオンデマンドサービスに関連する１セットの機能又は能力を示していてもよい。これは、今度は特定の目的を達成するためのソフトウェアオブジェクトの選択に影響を与える。こうして、そのケーブルネットワークの詳細に基づいて、ホストに対するカルーセリングのための適切なソフトウェアモジュールを得ることを確かにするために、ダウンロードマネージャー４１４はサイトプロファイルデータから情報を得てもよい。
【００２１】
図２ａに関しては、他の実施態様も考えられる。適用できるモジュールのみを保存し、必要でないものを廃棄するために、ローカルソフトウェアライブラリー（データベースともいう）がサイトプロファイルデータを用いることは可能であろう。例えば、ローカルソフトウェアデータベースは特定のソフトウェアオブジェクトの全てのバージョンを受理してもよいが、そのあとサイトプロファイルデータがこのサイトに適用不可能なものを排除する。これは、この特定の実施態様については、サイトプロファイルデータはダウンロードマネージャーとは逆にソフトウェアオブジェクトライブラリーへの入力として使用されることを本質的に意味する。他の実施態様においては、ソフトウェアオブジェクトは直接ダウンロードマネージャーにロードされ得て、その際ダウンロードマネージャーはサイトプロファイルデータを篩い分けのために使用する。
【００２２】
図２ｂは他の実施態様を示す。この実施態様は、多くのケーブル事業者が複数のケーブルを運用しており、ケーブルネットワークが共通のインフラストラクチャによってサービスされる種々の都市において所有しているであろう、という事実を反映している。図２ｂには、二つの特定のケーブルの運用が図示されている。一つは「サイトＸ」４３２ａとして示され、他は「サイトＹ」４３２ｂである。分かりやすくするために、サイトＸとサイトＹは異なっていて互換性のない装置又は機能を使用しており、それゆえ異なるソフトウェアオブジェクトを必要としているものとする。この実施態様では、ケーブル事業者は各サイトから離れて存在してもよい（又はサイトの一つと同じ場所に配置されてもよい）中央ソフトウェアオブジェクトライブラリー４４６を保持している。このライブラリーはサイトＸ  ４４２のための一つのプロファイルとサイトＹのための一つのプロファイル（図示せず）を含む複数のサイトプロファイルデータを保持しているオブジェクトサーバー４４０中に含まれている。オブジェクトサーバーは適切なソフトウェアオブジェクトを通信リンク４４５経由で各サイトへ「押し込む」。この場合オブジェクトサーバーは、適切なソフトウェアオブジェクトをダウンロードマネージャー４３６ａによりアクセスされ得るローカルオブジェクト記憶装置４３４ａに保存するために、通信ネットワークを通じてサイトＸ４３２ａに送信するために、サイトＸのためのサイトプロファイルデータを用いる。こうして、ローカルデータベース記憶装置はソフトウェアオブジェクトライブラリー記憶装置４４６とローカルオブジェクト記憶装置４３４の両者からなると考えられることができる。実施態様によっては、ローカルオブジェクト記憶装置４３４はダウンロードマネージャーの中のメモリーの一部であり、二つの機能ユニットが一つの装置中に実体化され、単に論理的に区別されるに過ぎない。このようにして、種々のケーブルネットワークを有するケーブルオペレーターは中央記憶装置を保持し、オブジェクトを適切なシステムにダウンロードすることができる。ダウンロードマネージャー４１４が必要とされるオブジェクトをソフトウェアオブジェクトライブラリー４１６から「引き込む」図２ａの場合と異なり、図２ｂにおいては、必要とされるオブジェクトは中央記憶装置からダウンロードマネージャーへと「押し込まれる」。ある実施態様では、組み合わせを使用することが可能である。例えばあるサイトはオブジェクトをダウンロードマネージャーへ「押し込み」、一方ダウンロードマネージャーはオブジェクトを他のサイトから「引き込む」。
【００２３】
種々の階層構造や手順が、オブジェクトをダウンロードマネージャーに記憶、篩い分け、送信するために定義され得ることはきわめて明白である。それぞれは、ホストへのカルーセリングのために適切なソフトウェアオブジェクトを選択的に特定することを目的とするそのサイトのプロファイルに関する情報にある点で依存する。サイトプロファイルデータを使用すると、適切なソフトウェアのケーブルオペレーターへの配布が容易になる。なぜなら、ケーブルオペレーターはそれらのネットワーク上に存在する種々の形式のホストへの追加や変更を、多数の適用できないソフトウェアモジュールを保存する必要なしに容易に取り入れることができるからである。新しい形式のホストを収容するために必要に応じてサイトプロファイルをアップデートすることにより、適切なホストモジュールが直ちにダウンロードできるようになる。また、こうして不適切なモジュールをホストにダウンロードする際に生じ得るエラーを回避する。
【００２４】
図２のソフトウェアオブジェクトライブラリーへのソフトウェアオブジェクトの移動は（実施態様に関係なく）ソフトウェアモジュールを種々の状態を通じて移動させるものと見ることができる。これらの状態はソフトウェアオブジェクトモジュールの使用を反映している。図３においてはソフトウェアモジュールの様々な状態を表現する状態図が示されている。第一の状態５００では、ソフトウェアは隔離されている。これはソフトウェアのローカルソフトウェアオブジェクトライブラリーへの最初の移動を表す。典型的には、このソフトウェアはソフトウェアオブジェクトが正しいソフトウェアモジュールとして正当と確認されるまではダウンロードマネージャーによってダウンロードされない。正当性の確認は、典型的にはモジュールの起源を真正と認めることと並んで、モジュールが改ざんされていないことを保証する周知の手続きを使用することを含む。そのような周知の手続きは、モジュールの完全性と真正性を保証するために、デジタル証明書又はデジタル署名を用いることを含む。例えばソフトウェアモジュールが故意にではなく「モジュールＸ」としてラベルされるかホストファイルデータベースに（例えば事務的過誤によって）ロードされ、その後ケーブルネットワークオペレーターのローカルソフトウェアオブジェクト記憶装置に転送される、ということが起こり得る。しかし、実際には、該モジュールは「モジュールＹ」である。もしケーブルネットワークオペレーターが該ソフトウェアモジュールを該ソフトウェアオブジェクトの真正性を確認せずにホストにロードすると、結果としてエラーが生じ得る。したがって、ケーブルオペレーターはソフトウェアの起源を確認し、ケーブルオペレーターがそのソフトウェアを使用する正当な権利を有することを確認し、その内容が改悪されていないこと等を保証してもよい。有効化は送信エラーが起こらなかったこと、及び適切なデジタル証明書が適用できることを確実にすることを含んでもよい。
【００２５】
移行線５１０により表されているように、ひとたび有効化されると、ソフトウェアはアイドル状態５０２に入る。アイドル状態とは、ホストに配布するソフトウェアが存在し、そのソフトウェアが目的とする物であり、それを使用する権利が既に得られている、等を意味する。ひとたびこの状態になると、ダウンロードマネージャーはソフトウェアを探し出し、それをカルーセル中に置く。移行線５１４が示すように、ひとたびソフトウェアがロードされると、ソフトウェアは活性状態５０４に入る。この状態は「回転（ｓｐｉｎｎｉｎｇ）」状態とも呼ばれることができる。なぜならソフトウェアはダウンロードマネージャーによって活発にホストに配布されているからである。最後に、ソフトウェアが回転し終わると、ダウンロードマネージャーはソフトウェアモジュールを移行線５１６で表されるようにライブラリーに戻す。ここでソフトウェアは再度アイドル状態５０２に入る。もしこのソフトウェアがもはや要求されなくなると、システムは移行線５１２で示されるようにソフトウェアを廃棄し、ソフトウェアは廃棄状態５０６に入る。典型的には、ソフトウェアがひとたび廃棄されると、正当性の確認なしに再び元の状態に戻されることはない。図３はカルーセル手法に注目して描写されているが、様々なプロトコル（例えばＴＦＴＰ、ＦＴＰ等）同様に、クライアント−サーバーモデルなどデータをホストに転送する様々な手法を用いて類似の状態図が定義され得る。他の実施態様においては、一度使用されたモジュールがその後活発に必要とされず、保存状態に置かれるような第五状態（休止状態）が定義され得る。この場合、モジュールは有効化の必要なしにアイドル状態へと再活性化される。
【００２６】
実際には、ダウンロードマネージャーにより必要とされるソフトウェアモジュールのほとんどは既に「アイドル」又は「活性化」状態のいずれかの状態にある。典型的には、ソフトウェアモジュールはダウンロードマネージャーによって隔離状態から検索されるわけではなく、ダウンロードマネージャーによって使用されることを予期して前もって取得されている。大規模ケーブルネットワークのホストにとって、ホストソフトウェアのアップデートは数ヶ月かかる可能性があり、全てのホストの大量アップデートを一度に行うのは現実的ではなく、また望ましくもない。典型的には、スケジュールし、コーディネートする必要のあるアップデートやホスト装置が多様にある。更に、ホストは定常的にケーブルネットワークに付加されたり取り外されたりしている。その結果、あるソフトウェアモジュールがアップデートされつつあるが存在していないときは、ローカルデータベース記憶装置はそのソフトウェアをホストファイルデータベースから探し出し、有効化し、それをアイドル状態に置き、いつでも使用できるようにする。ローカルデータベースはダウンロードマネージャーの支配下にある適切なソフトウェアを探し出してもよい。ダウンロードマネージャーは、適切なダウンロードコマンドを送ることによってソフトウェアを探し出し、それをカルーセルに置き（ソフトウェアを活性状態に置き）、それをホストが利用できるようにして配布するであろう。ソフトウェアは長期間カルーセル中に保持され、周期的にホストに対して利用可能状態とされてもよい。しかし、ソフトウェアがもはやカルーセル中に保持（例えば活性化された状態）されることが要求されないなら、ソフトウェアはアイドル状態に戻される。もちろん、ソフトウェアをアイドル状態から回収して活性化された状態に戻すこともでき、典型的にはこのプロセスは必要なだけ繰り返される。最後に、システムがもはやそのモジュールを必要としない（配布が完了した、及び／又はソフトウェアが古くなった）なら、それは廃棄され得る。しかし、一度廃棄されると、ソフトウェアは再度回収（真正性の確認を含む）しないと配布できない。したがって、図２ａ、２ｂのソフトウェアライブラリー４１６、４４６及び４３４は様々な状態を取り得るソフトウェアモジュールの高レベル保存のみを図示している。
【００２７】
ソフトウェアモジュールの状態から必ずしも特定の記憶技術が分かるわけではない。「活性化」されているソフトウェアモジュールは「アイドル」状態のソフトウェアモジュールと同様にシステムのメモリーに保存されてもよい。これは一次メモリーでもあり得るし、二次メモリー（例えばディスク記録装置）でもあり得る。又は、「アイドル」なソフトウェアはディスク上に記憶されてもよい。ソフトウェアモジュールの状態に基づき、特に実施化実施例は必要とされない。
【００２８】
ダウンロードできる適切なソフトウェアモジュールが存在するとき、ダウンロードを調整するときの複雑さが検討される。ホストソフトウェア配布管理の複雑性を説明する一つの例を図４ａに図示する。図４ａにおいて、セットトップボックス（ＳＴＢ）２００が論理的に図示されている。該ＳＴＢは視聴者が視聴メニューから映画を選択できるムービーオンデマンドサービスを提供すると仮定する。このサービスはＳＴＢ中で実行されるビデオオンデマンド（ＶＯＤ）アプリケーションを用いて提供される。該ＶＯＤアプリケーション２０２はどのような映画を顧客が選択できるかを知っている必要があるが、この情報は電子番組ガイド（ＥＰＧ）モジュール２０４を用いて得られる。ＥＰＧはムービーオンデマンドサービスがユーザーに提供されていなくとも存在してもよい、独立のソフトウェアモジュールである。ＥＰＧは情報を処理し、利用できる番組サービスに関する情報をユーザーに提供する。ＥＰＧの機能の一つは番組情報を人間が読める形式で提供することである。しかし、ＥＰＧは番組情報を例えばＶＯＤアプリケーションのような他のアプリケーションにも、そのアプリケーションが理解できる形で提供する。ＶＯＤアプリケーションはユーザーに利用できる映画のリストを提供するので、利用できるビデオオンデマンドプログラムと他のオンデマンドでないプログラムは（ＶＯＤ又はＥＰＧアプリケーションのいずれかによって）区別されなければならない。その結果、ＶＯＤアプリケーション（ＶＯＤサーバーのメーカーに特有であってもよい）は利用できる映画をユーザーに提供し、ユーザーはＥＰＧが用意する情報を用いて映画を選択する。これに対して、ＥＰＧは他のソフトウェアモジュール、具体的にはケーブルネットワーク上で配布される番組案内情報を処理するファームウェアモジュール２０６を用いて情報を得る。他の実施態様では、ＥＰＧは第三者からプログラム情報を得るために他のコミュニケーションモジュールに依存してもよい（例えばサーバーに電話をかける電話インターフェースを制御するモジュールを通じて、又はＩＰ方式高速データ通信性とのインターフェースを行うモジュールを通じて）。要約すれば、ＶＯＤモジュール２０２はＥＰＧモジュール２０４から情報を求め、ＥＰＧモジュールはこれに対してファームウェアモジュール２０６により処理された情報を求める。他のモジュールが係わる場合もあってもよいが、この構成は本発明のいろいろな面を説明するには十分である。図４ａにおいて、これらのモジュールのそれぞれはあるバージョン番号を持つものとして図示されている。よく知られているように、ＳＴＢ中のソフトウェアは頻繁に修正され、新しいソフトウェアバーバージョンがＳＴＢに配布される。したがってバージョン番号は現在のソフトウェアモジュールを識別するには便利な方法である。
【００２９】
与えられたモジュールの異なるソフトウェアバージョンは異なる能力を有するので、種々のモジュールの特定のバージョンを他のモジュールと共に使用するために調整することは重要である。例えば、同一のバージョン番号（例えばバージョン１．０）を有する全てのモジュールが全てお互いに両立できると考えるのは不適当である。むしろ、あるモジュールのあるバージョンのみが他のモジュールと両立してもよいのであり、どのモジュールが他のモジュールと両立し得るかを知るには規則が必要とされる。
【００３０】
図４ｂはこれら種々のモジュール間の互換性情報を示す。典型的には、異なるソフトウェアバージョンはケーブルオペレーターから得ることができ、セットトップボックスに組み込まれてもよい。互換性表２１０は、表示されたモジュール２１２についてそれが他のモジュール２１４のどれと適合し得るかを示す。したがって、例えばＶＯＤモジュール１．０  ２１６はＥＰＧモジュール１．０及び１．５と互換性がある。ＥＰＧモジュール１．５  ２１８はファームウェアモジュール１．０、１．１、１．２及び１．３  ２１９と互換性がある。最後に、ファームウェアモジュール２２０はセットトップボックスＸ、Ｙ及びＺ  ２２１中に見出される。このような規則を含むこの種の互換性表がなければ、どのモジュールがお互いに適合できるかは直ちに明らかになってもよいわけではない。論理的には、これらの規則は「規則テーブル」と想像されてもよい。しかしこれらの規則は、関連するソフトウェアモジュールから得られるメタデータから動的に導かれる。したがって、通常、関連するソフトウェアモジュールから独立した単一の、演繹的に確立された「規則テーブル」は存在しない。
【００３１】
ここで、ネットワークオペレーターがＳＴＢにおいて最新の、又は少なくともより新しいＥＰＧモジュールのバージョンへのアップグレードを欲していると考えてみる。そうしたいと思う理由は様々であり、新しいＥＰＧモジュールがソフトウェアのバグを補正したり、利用し得るプログラムについて付加的な情報を提供する新しい能力を付け加えたりすることが可能な場合はその一つである。図２ｃにおいて、目標はＥＰＧバージョン２．０  ２０６ｂをＳＴＢ  ２００ｂにインストールし、実行することである。表２１０からＥＰＧ  １．０及び１．５  ２１７はＶＯＤ  １．０  ２１６と適合することが知られる。しかし、図２ｂ中の互換性表から判断されるように、ＥＰＧ  ２．０  ２２５はＶＯＤ  １．０  ２１６とは両立せず、ＶＯＤ  ２．０  ２２６を必要とする。同様に、ＥＰＧ  ２．０  ２２８はファームウェアバージョン１．５、１．６又は１．７  ２２９を必要とする。最後に、全てのファームウェアバージョン２２０はＳＴＢモデルＸ  ２２１と適合できる。要約すれば、ＳＴＢボックスモデルＸ上のＥＰＧプログラムをＥＰＧ  ２．０にアップデートするには、ファームウェア及びＶＯＤソフトウェアモジュールもまたアップデートされる必要がある。この必要性は他のＳＴＢボックスモデル又はメーカーに対しては異なっていてもよい。したがって、上記の規則は各売り手に特有であってもよい。
【００３２】
事態を複雑にするのは、バージョンのある組み合わせが必要なばかりでなく、各モジュールをアップデートするにあたって特別の順序が必要であってもよいということである。図４ｃにおいて、順序はステップ１  ２３５に示されたとおりであり、ファームウェアモジュール２０６ｂのより新しいバージョン、即ちファームウェアモジュール１．５が最初に組み込まれる。次にステップ２  ２３７でＥＰＧモジュールバージョン２．０が組み込まれ、最後に、これが完了したあと、最後のステップは、ＶＯＤアプリケーション２０２ｂをバージョン２．０へとアップグレードさせるステップ３  ２３９である。アップデートの「順序」は、必ずしもソフトウェアがある時間系列で配布されなければならないということを意味するわけではない―それはホスト中でどれが最初に活性化されるかを述べていてもよい。ＳＴＢを「アップデート」すると言うことは、ホストが一つのモジュールを他に先立って活性化するよう指示されること、あるいはホスト中の他のモジュールを活性化するに先立ってあるモジュールがホスト中に存在することを要求することを意味している可能性がある。
【００３３】
モジュールはある他のモジュールとのインターフェースとなり、他のモジュールと共に機能するよう設計され得ること、また一つのモジュールをアップデートするには他のモジュールのアップデートが前提条件として要求されてもよいことは明白である。したがって、ソフトウェアの配布を正しく管理しないと、あるアプリケーションを動作不能としたり、また他の不都合な結果を招いたりする可能性がある。例えば、ＥＰＧアプリケーションをアップデートした後にＶＯＤアプリケーションをアップデートしないと、ＶＯＤアプリケーションの動作不能を生じさせるかもしれない。適切な順序でソフトウェア配布を行わないと、あるサービスがある状況下で「暗礁に乗り上げる」（使用できなくなる）事態を含む、他の結果が生じるかもしれない。最初にＥＰＧをアップデートせずに新しいＶＯＤアプリケーションを配布すると、ＶＯＤが視聴者の選択のために利用できる映画に関する情報を受け取れないという結果を生じるかもしれない。
【００３４】
ソフトウェアモジュールの配布は、ダウンロードをコーディネートする異なる手順に対応する二つの方法に分類できる。これらはしばしば「ブロードキャスト」ダウンロードと「オンコマンド／デマンド」ダウンロードに分類される。ブロードキャストダウンロードは典型的には多数のホストを、典型的には大量販売的にアップデートすることと関連している。典型的には、これはオペレーターが新しいソフトウェアオブジェクトを全てのホスト又は特定の型の全てのホストにインストールするような、システム全体にわたるアップグレードを行う時に生ずる。これはアップデートに関係するケーブルネットワーク全体に関連することが多い。「オンコマンド」又は「オンデマンド」ダウンロードは、単一のホストから多数のホストまでを含む、より少ない数のホストを対象とするように設計されている。オンコマンドとオンデマンドの区別は比較的マイナーなことであり、オンコマンドは典型的にはネットワークにより開始されるのに対し、オンデマンドは典型的にはホストにより開始されるという点にある。これらはわずかに異なるプロセスの流れを含むが、オンコマンドダウンロードはオンデマンドダウンロードと同じ結果を達成できる。例えば、あるホストが要求しケーブル事業者から受け取ることができるソフトウェアオブジェクトはどれでも、ケーブルネットワークオペレーターがダウンロードマネージャーにコマンドを発行することによって送付されることができる。逆は真でない。ケーブルネットワークオペレーターは一組のホストに対するダウンロードを開始できるが、ある特定のホストが同じ一組（例えば他のホストを含む）に対してダウンロードを開始することはできない。
【００３５】
配布がどちらのスキームに分類されるかに関わらず、アップデートされたソフトウェアバージョンをホストに配布する能力は、ソフトウェアのダウンロードとともに様々な複雑性をもたらす。一つの手法は、目標ホストにおいてどのモジュールが他のモジュールと両立し得るかを手動で決定すること、及びソフトウェアを配布する際にどの順序（もしあれば）が要求されるかを手動で決定することである。この手法では、どのモジュールとそのバージョンが現在ホストに存在しているかを正確に知る事が必要である。成功するか失敗するかはダウンロードを管理する個人の技量に大きく依存し得る。これは間違いを引き起こしやすく、複雑な過程である。ケーブルネットワークオペレーターにとってこの過程を更に複雑にするのは、ソフトウェアオブジェクトの識別と指示は人間が読める語句でなく英数字の識別名を用いてなされるということである。したがって、ソフトウェアモジュールを手動でダウンロードするには、自動化された補助手段を必要とする。
【００３６】
本発明の一面は、ケーブルネットワークオペレーターに対して上記のプロセスを単純化する（例えば要約する）ための固有の規則への依存を含む。図２とともに論じたように、ソフトウェア配布を単純化する一つの手法は、どの形式のモジュールが必要とされているかに関する、情報をサイトプロファイルを通じて保持することに依存する。他の手法はネットワークに接続されたホストに関する情報を保持することを含む。これはどのような形式のホストが存在するかということと、それらの能力に関する情報を保持することを含む。この過程はホストを適切なホストプロファイルに関係付ける事を含む。
【００３７】
ホストにダウンロードするべき適切なソフトウェアオブジェクトを選択するための効率的かつ柔軟性に富むアーキテクチャーの造出に関連する「プロファイル」には種々のものがある。そのようなプロファイルの一つはサイトプロファイルの形で論議した。他のプロファイルは加入者プロファイル又は加入者サービスプロファイルである。加入者プロファイルは彼らの氏名、サービスアドレス、請求アドレス、及び彼らがどのようなサービスを受けているかなどのような、加入者に関する情報を含む。典型的には、加入者プロファイルが加入者の請求と関係付けられるように、関係付けられた１つのセットの種々のサービス水準、価格などがある。典型的には、異なるサービス水準とオプションが加入者に提供される。これらのサービスの水準は、サービスの遂行に関連するある能力を更に識別するために使用される。加入者は更にあるホスト又は一組のホストと結び付けられているので、ネットワークは加入者をあるホストと結び付ける情報を保持している。例えばプレミアムチャンネル又はサービスパッケージを付け加えるために、サービスの水準を変更しようとしている加入者は、ネットワーク運用者が新サービスを達成するにはどのホストに対する権利を取得するべきかを知ることを要求する。
【００３８】
ネットワークによって保持されるべき他のプロファイルは、ネットワークに接続された、与えられたホストの能力に関する知識を含む。これはネットワークに、ホストの形式とどのような能力がそれと結び付けられているかについての情報を保持することを要求する。高い水準では、これは「ホストプロファイル」と呼ぶことができる。これは特定のホスト又はあるクラスのホストの現在の能力についての情報を提供する、ケーブルオペレーターによって保持されている情報の集まりとして考えることができる。例えば、ホストはいろいろな水準の機能性をもった種々の形の消費者向け電子装置として具体化されることができる。ある能力を持ったデジタルテレビ（例えば単独のＨＤＴＶチューナー又は画像の中に画像を作り出す能力を持った二つのチューナーを組み込んであるもの）はあるホストプロファイルと結び付けられてもよい。組み込みのデジタルビデオレコーダーを持ったテレビは異なるホストプロファイルと結び付けられてもよい。加入者にＤＶＲサービスを提供するなら、加入者は明らかにＤＶＲの機能性又は能力を有するある形のホストを所有していることを要求される。ネットワークはホストの機能性を動作可能にしなければならず、したがって特定のホストのＤＶＲの能力の詳細を知っている必要がある。
【００３９】
ホストとホスプロファイルの関連付けは種々のやり方で達成され得る。ある手法では、ある特定のホストの現在の能力を記述する一組の情報が保持され得る。他の手法では、最初の一組の情報はホストの基本能力についての情報を保持し、次の一組の情報はそのホストへの能力の変更（例えば「強化」）についての情報を保持していて、この二組の組み合わせが現時点でのそのホストの能力を表示する。ホストの能力は、ホスト固有の能力に加えて、どのソフトウェアモジュールがホスト中に組み込まれ、動作可能とされ、機能するかによって決定される。したがって、ＤＶＲハードウェアを持っていてもそれが動作可能になっていないホストは、実際にはＤＶＲサービスを提供する能力は持っていない。更にＤＶＲは、動作可能とされなければならないばかりでなく、ケーブルオペレーターのネットワーク上で両立可能であるソフトウェアオブジェクトの現バージョンを必要としてもよい。
【００４０】
あるホストにどのような能力を結びつけるべきかをネットワークが知るためには、ホストはそれ自身をある方法で識別する必要がある。ある実施態様では、ホストはある方法でそれ自身をネットワークに知らしめる。ホストにとっての一つの手法は、最初の接続の際に、ネットワークに対して自動的にそれ自身の識別を行うことである。別の手法では、管理者は様々な運用と提供のシステムを用いてケーブルネットワークに対して手動でホスト識別情報を提供できる。どの手法を採るにしても、結果としてネットワーク中でホスト識別情報が得られ、ネットワークはそのホストを能力のプロファイル（例えばホストプロファイル）と結びつけることができる。ひとたびこれが達成されれば、ネットワークは必要に応じてホストへのソフトウェアオブジェクトのダウンロードを達成することができる。
【００４１】
ホストがそれ自身を識別する状況の下では、様々な条件がホストにこのプロセスを開始させるきっかけを種々の方法で作ってもよい。これら全ての結果として、ホストはその能力についての何らかの情報をネットワークに提供することになり、ネットワークはホストを適切なホストプロファイルと関連付けることができる。
【００４２】
ホストとホストプロファイルの関連付けは種々の異なる方法で行うことができる。図５は、ホストがホストプロファイルとの関連付けを目的として自分自身を識別する種々の実施態様を図示する。図５において、最初のステップ３００から始まって、第一実施態様３０２では、ホストは二つのデータ事項を発信する。この実施態様では、ホストはターミナルメーカー識別子とモデル識別子３０２を発信する。この実施態様は、既知の独自のフォーマットがメーカーを識別するために用いられると想定している。このフォーマットは工業標準（例えばメーカー識別のためのＭＡＣアドレスの最初の桁の使用）に準拠していることもあり得る。その番号付けスペース内で、各メーカーは特定のモデルに関連する独自の識別子（メーカーのアドレスの番号付けスペース中で独自）を用いる。この実施態様では、ネットワークはこの情報を、ホストを特定のホストプロファイル３０４に位置付けるために用いる。ホストプロファイルはその特定のホストの作りとモデルと関連付けられた能力を反映するものと定義される。ホストプロファイルは狭く（例えばその作りとモデルに固有であるように）定義され得るし、また種々の類似のホストの作りとモデルが同一のホストプロファイルと関係付けられるように、より広く定義され得る。当業者であれば、種々の符号又は文法構造を用いて単一の複合メーカー／モデル識別子を定義するなど、本実施態様に対する代案を案出することが可能であろう。符号化の詳細とは無関係に、ホストは自分自身に関する情報を発信し、ネットワークがそれをホスト固有のある能力を識別するメーカー特有の情報と関係付ける事を可能にする。ひとたびこれが知られれば、ステップ３１６でホストはホストプロファイルに位置付けされ、関連付けはステップ３１８で完了する。この実施態様では、ホストが、例えばシリアル番号のような更に他の情報を発信して、そのホストが同じ作りとモデルの他のホストと区別可能とすることがあり得る。
【００４３】
本実施態様の一変形では、ホストは単にホストプロファイルを直接に識別するホストプロファイル番号３０６を報告することができる。これはそのような数値が各形式のホストプロファイルについてよく知られている事を前提としている。ある能力をホストプロファイル番号と関連付けるような産業界の協定を作れば、これは実現できる。このような手法によれば、ステップ３１６でネットワークはホストをあるプロファイルにマップすることができ、この過程は完成ステップ３１８で完成する。このような総称的なプロファイルは付加的な能力に対して定義された数値を用いて単一の、又は複数のメーカーに共通なものとされることができる。そのようなホストプロファイルによって、ある形式又はクラスのホストにおいて認識される能力の最小のサブセットを許すことが可能である。ネットワークがそれを他のホストから区別できるようにするために、これら及び他の変形によって、ネットワーク事業者はホストにおける最小限のホスト能力を認識できるようになる。また、ホストはさらなる情報を発信してもよい。
【００４４】
図５に示された他の変形では、ホストはソフトウェアモジュール監視ルーチンを組み込む。そのルーチンは、ステップ３０８に示すように、ホスト中の他のルーチンに対して照会を行う（そうでなければ、ホストに組み込まれた能力を確認したり目録としたりする）能力を有する。その後、ホストはステップ３１０においてその能力を自律的に（又は引き金となるイベントに反応して）個々に報告し、それによってネットワークはステップ３１２において適切なサブプロファイルを決定できるようになる。もし全ての能力が単一の報告で報告できないなら、この過程は繰り返されるであろう。一組の能力を位置付けするために単一の識別子を用いる前述の手法とは異なり、各能力は一つの識別子によって定義され、ホストによって個々に報告される。この目的に適合し得る一つのプロトコルは、データの管理情報ブロック（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ  （ＭＩＢ））中のパラメーターの読み取りと書き込みを可能にする簡易ネットワーク管理プロトコル（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  （ＳＮＭＰ））である。
【００４５】
最後に、図５のステップ３１４に示すように、ネットワークがホストに照会する事を容認する可能性を含む他のメカニズムが定義され得る。例えば、ネットワークはホストにコマンドを送り、そのコマンドはホストにホスト識別データの報告を開始させる（例えば、メーカー及びモデル情報、シリアル番号、能力識別子等）。ホストはそのデータをＸＭＬタグに基づくフォーマット、又はＳＮＭＰを経て報告できる。ネットワークはそれに応じて上記識別子の一つを受け取ることができる。又は、ネットワーク管理者又は他の人物によりネットワーク活性化時に定義されるホストプロファイルを、ホストとネットワークの相互作用の必要なしに受け取ることができる。
【００４６】
上記実施態様のそれぞれにおいて、ホストは、例えばシリアル番号のような、数値又は英数字情報のような他の独自情報を発信してもよい。これは、ホストをサービスプロファイルと関連付けるために、又は一つのホストを他のホストから区別するための他の識別の目的で、他の実施態様で使用されてもよい。
【００４７】
典型的な場合、あるホストは単一のホストプロファイルと関連付けられるが、他の実施態様ではホストは多重のプロファイルと関連付けられることがあり得る。既に識別された他の選択肢は、一つのホストプロファイルにより識別される一つのホストであり、それが今度は二つの他のホストプロファイルによってマッピングされるか定義される。例えば、ある特定のホストは、組み込まれたＨＤＴＶチューナーを持つ高品位テレビとして具体化されてもよい。これは特定のビデオ系ホストプロファイルにマッピングされる。ホストメーカーはホストの他のモデル、すなわち組み込まれたＤＯＣＳＩＳ高速データモデムを有する「強化ＩＰケーブルテレビ」版を製造してもよい。この強化ＩＰケーブルテレビ装置は消費者によってインターネットを閲覧して回るために使用され得る。この場合、ホストプロファイルの「強化ＩＰケーブルテレビ」版は二つの別々のホストプロファイル  −すなわちビデオ指向属性を持つホストプロファイルと、これとは独立のデータ指向ホストプロファイルを持つホストと−  の組み合わせとして定義されてもよい。これは「リンクされた」データ構造を用いて実施されることができる。又は、単一の独立なホストプロファイルが能力の組み合わせに対して定義されることができ、それは単一のデータ構造として実施されることができる。
【００４８】
あるホストを一つ以上のホストプロファイルに位置付けるに際して、種々のトレードオフや選択肢があり得ることは直ちに分かる。更に、他の実施態様では、一つのホストプロファイルを他のホストプロファイルの階層構造として定義できる。一つのホストを多重のホストプロファイルと関係付ける事を許すなら、一つのホストが唯一のホストプロファイルと関係付けられる場合に比べて、可能なホストプロファイルの並べ替えの数は減少する。ある程度まで、そのようなホストプロファイルの定義はケーブル運用者、工業標準、又はその両者によって定義されることができる。上記のいずれの実施態様及びその変形も、本発明の範囲中にある。
【００４９】
ソフトウェアオブジェクトはホストに、それをアップグレードする（従って、その能力を変える）目的でダウンロードされ得るので、あるホストの現在のホストプロファイルは知られていなければならない。これを達成するには二つの道がある。最初に、あるホストの現在の単一のホストプロファイルが定義され得る。該ホストは、初期化に際してこのホストプロファイルに関係付けられてもよい。又は、該ホストはデータ構造の組み合わせと関連付けられてもよい。このとき、一つのデータ構造はその特定のホストと関係付けられた一組の基礎的（又は総称的）な能力を記述し、他のデータ構造はそれ以来そのホストに起こった変化を示す。本質的には、開始点とあるホストに起こった変化とを知れば、その現在の能力が識別され得る。命名法の目的で言うなら、「現在の」ホストプロファイルは単一のデータ構造であり、一方「総称的な」ホストプロファイルはその特定のホストと関係付けられた能力である。そして「ホスト目録」プロファイルは該ホストにどんな変化が起こったかを、典型的にはどのソフトウェアオブジェクトが該ホストにダウンロードされたかを示す形で識別する。このように、ホストプロファイルの一実施態様は、総称的ホストプロファイルをホスト目録プロファイルと組み合わせて使用することにある。
【００５０】
図５に記述されたホスト識別情報が現在のホストファイル、又は総称的ホストプロファイルとホスト目録プロファイルとの組み合わせと関係付けられるには種々の方法がある。第一に単一の現在のホストプロファイルを考えてみる。図５に開示された各実施例において、ホスト識別情報がメーカー及びモデル識別子３０２の形でも、単一の英数字数値３０６でも、又は能力の明示的報告３１０でも、又は他の形でも、ネットワークはホストをある特定の現在のホストプロファイルに位置付けることができる。ここで、総称的ホストプロファイルとホスト目録プロファイルが使用されている実施態様を考えてみる。この場合、ホスト識別子は、総称的なサービスプロファイルの決定を可能にするメーカー及びモデル識別子（複数可）３０２の形を取る。付加的な独自情報はホストの識別とともにシリアル番号（又は英数字情報）の形で運ばれ、ネットワークがそのホストのためのホスト目録プロファイルが識別されてもよいようにする。したがって該組み合わせは、ネットワークがそのホストのための現在のホストプロファイルを知ることを可能にする。同様に、ホストは単に独自識別子を提供してもよく、その最初の部分は産業的に定義された複数の総称的ホストプロファイルの一つを選択するために使用される。そして該識別子の他の部分は特定のホスト目録プロファイルを識別するために使用される。最後に、ホストはその能力を個々に報告してもよく、ネットワークはそれを総称的ホストプロファイル及びホスト目録プロファイルに位置付けすることができる。典型的には、要求はされていないが、もしホストがその能力を個々に報告するなら、ネットワークはそのホストを総称的ホストプロファイル及びホスト目録プロファイルよりはむしろ単一の現在のホストプロファイルに位置付ける。
【００５１】
ホストをホストプロファイルに関係付けるために使用される機能的構成要素も図６に示されている。図６はソフトウェアオブジェクトをホストにダウンロードするための一つの可能なアーキテクチャーを示しており、ネットワークが総称的ホストプロファイル及びホストと関連付けられたホスト目録プロファイルを保持している実施態様に基づいている。以下は図６の各構成要素の機能性の概観である。
【００５２】
ダウンロードマネージャー
ダウンロードマネージャー４１４の主な機能はソフトウェアモジュールをケーブルネットワークに配布することである。これはカルーセルを経由して行われ、ダウンロードマネージャーはダウンロードされるべきモジュールが例えば活性化状態で「回転」していることを確実にする。ダウンロードマネージャーはソフトウェアモジュールの一組を、図３に関連して論議したように種々の状態に保つ。前に示したように、ダウンロードマネージャーは組み込まれたソフトウェアオブジェクトライブラリー又は離れた場所に置かれたライブラリーと共に具体化されてもよい。アイドル状態のオブジェクトはライブラリー又はダウンロードマネージャーに保存されて良いが、活性化されたオブジェクトはダウンロードマネージャー中に存在する（コピーはライブラリー中にも保持されてよい）。ダウンロードマネージャーは各ソフトウェアモジュールによって定義される種々の規則、例えばモジュールに関係付けられた前提条件や他の要求をも施行してもよい。このようにソフトウェアモジュールは、他のモジュールに関してダウンロードの順序に関するある規則を定義してもよいし、ダウンロードマネージャーが施行するモジュールダウンロードの前提条件を定義してもよい。
【００５３】
本発明はカルーセルを用いて開示されているが、モジュールの転送には、ホストへの高速データ接続（例えば内部ＤＯＣＳＩＳモデム、又はホストにデータを受け取らせるケーブルネットワーク上の他の独立したデータ通信チャンネルを用いる）経由でデータを送信するファイルサーバーを用いるような、他のモジュール転送の手法を用いることもできる。他の代替アーキテクチャーでは、他のよく知られたファイル転送プロトコル（例えばマルチキャストＩＰ、ＨＴＴＰ、ＦＴＰ、ＴＦＴＰ、ＯＳＩプロトコル、又は他のデータ転送プロトコル）又はダウンロードのための他の方式（例えばポーリング、オンデマンド、又はオンコマンド方式）を用いる、クライアント−サーバー方式を使用することができる。したがって、図６はカルーセルを図示しているが、ケーブルシステムで用いられる他の転送手段も、本発明の範囲内において可能である。
【００５４】
ダウンロードマネージャーは、オンコマンドダウンロードを開始するために、ネットワーク管理者４１５からも端末インターフェース又は他のシステムへのインターフェース経由でコマンドを受け取ることができる。ダウンロードマネージャーはオンコマンドダウンロードコマンドを、どのモジュールがダウンロードされるべきかを指示する、定義されたスクリプトへ配置してもよい。
【００５５】
サイトプロファイルデータ
ダウンロードマネージャー４１４はサイトプロファイルデータ４１２と密接に結び付けられている。前に示したように、サイトプロファイルデータは、その中でホストが稼動しているケーブルネットワーク４１６特有の情報を含む。サイト特有の情報は、特定のメーカー、機器のバージョン、アップリケ−ションモジュール、アップリケ−ションのバージョン、能力のセット、又はアーキテクチャーの詳細に関する情報など、ケーブルネットワークの運用に必要な特定のソフトウェアモジュールを適切に選択するのに必要な情報を提供してもよい。例えば、ケーブルシステムにダウンロードされるべき特定のバージョンのＥＰＧソフトウェアモジュールは、そのケーブル運用内に展開されたある中継機器のメーカーとバージョンに依存してもよい。他の例では、ビデオオンデマンドサービスを作動させるには、あるホストに対し特定のソフトウェアオブジェクトの選択を要求してもよい。このとき、そのオブジェクトはネットワークビデオオンデマンドサーバー中に存在するある能力に依存する。
【００５６】
ソフトウェアオブジェクトライブラリー
ソフトウェアオブジェクトライブラリー４１６は、ソフトウェアオブジェクトをカルーセルに乗せることを見越してそのソフトウェアオブジェクトを保存している。ある実施態様では、ソフトウェアオブジェクトライブラリー４１６はダウンロードマネージャー４１４の一部であり得る。そして、この二つの構成要素の間で、必要なソフトウェアオブジェクトは種々の定義された状態の一つに見出される。カルーセルに乗せられるべき適切なオブジェクトは、ライブラリー及び／又はダウンロードマネージャーのいずれかに保存されている。前に論議したように、ダウンロードマネージャー４１４、ソフトウェアオブジェクトライブラリー４１２、及びサイトプロファイルデータ４１６を含む、達成のために定義可能な種々のアーキテクチャーが存在する。
【００５７】
デバイスマネージャー
デバイスマネージャー４０４はあるホストの現在の能力に関する情報を提供する。それは複数のホストプロファイル４０６を保持し、ホストは特定のホストプロファイルに関係付けられる。こうして、ある特定のホストに関する情報は、デバイスマネージャーによって、典型的には登録サーバーに対して提供され得る。新しいホストがメーカーによって作り出されるにつれ、新しいホストプロファイルが定義される。ホストプロファイルはメーカーによって提供されてもよく、そのメーカー固有のものでもよい。又は、ホストプロファイルは産業界の同意によって定義され、特定のカテゴリーのホストに対して設定された最小限の能力を反映してもよい。初めにネットワークに接続されたホストはホストプロファイルの一つと関連付けられることが予想される。
【００５８】
しかし、時とともに（ある場合には最初のインストールのあと直ぐに）ソフトウェアオブジェクトはホストにロードされてもよく、そうすることにより、それが最初にインストールされた時にそれと関連付けられた能力の基礎レベルからそれをアップグレードする。ある与えられたホストに対する現在の情報への一つの接近法は、どんなモジュールがそのホストにダウンロードされたかについての情報を保持することである。これはホスト目録プロファイル４０８の機能である。他の実施態様はホスト目録プロファイル４０８をデバイスマネージャー４０４に保存してもよいが、この実施態様ではホスト目録はデバイス提供マネージャー４１０に保存される。ホスト目録は各ホストのＭＡＣアドレス又はシリアル番号、又はホストの他の独自識別子により索引化されてもよい。
【００５９】
デバイス提供マネージャー
デバイス提供マネージャー４１０はホスト特有のコマンドを発することができる。これらのコマンドはふつうダウンロード過程に付随するものである。例えば、あるホストに新しい能力を備えるに関連して、ホスト中のハードドライブの再分割が必要であってもよい。再分割はモジュールのダウンロードとは独立しているが、ホストがモジュールを受け取るよう準備するために必要であってもよい。デバイス提供マネージャーはホストに特有の属性を知っており、登録サーバーに指示されたようにホストに対する適切なコマンドを作り出せる。
【００６０】
請求システム
請求システム４０２は加入者サービス関連情報を保持し、典型的には複数の加入者サービスプロファイル４０２を保持している。請求システムの構造と機能は多様であり、実行に依存する。加入者サービスプロファイルの記憶のためには他の実施態様も存在する。加入者サービスプロファイルはある与えられた加入者に対するサービス水準に関する情報を保持する。これは次にホストに提供されたサービスに位置付けられなければならず、これは次にあるソフトウェアオブジェクトがあるホストにダウンロードされなければならないかどうかを決定する。たいていの場合、あるホストにダウンロードされたソフトウェアオブジェクトは、加入者による予約サービスの変更に基づいて始動されるわけではない。しかし、加入者が彼らのサービスを変更するとき、付加的なソフトウェアオブジェクトがホストにダウンロードされなければならないということは大いにあり得る（しかし常に要求されるわけではない）。加入者のサービスプロファイルはふつう、どのソフトウェアオブジェクトがダウンロードされる必要があるか、といった低水準情報を保持していない。しかしそれは、モジュールの適切なダウンロードをもたらすためには加入者サービス水準が知られていなければならない場合、又はもし加入者サービス水準に対する変更が起こったとき、登録サーバーと交信をするものである。
【００６１】
登録サーバー
登録サーバー４１９は総括的なプロセスマネージャーであり、上述の機能的構成要素の一つが点検される必要があるかを判断すると同様、上述の機能的構成要素の全てが必要な情報を適切な時に提供することを保証するために、ワークフローマネージャーを含んでいる。この理由で、登録サーバーは上記の実体のそれぞれと交信し、それぞれに、ある行動がいつ為されなければ成らないかを指示する。
【００６２】
オンコマンド／オンデマンドアップデート
登録サーバーの役割はオンコマンド／オンデマンドアップデートとの関連において最もよく説明できる。具体的には、オンコマンドアップデートについては、ホストがケーブルネットワークに対してそれ自身を認識する局面において説明される。その過程は、まず登録サーバーがメッセージ４２０を自分自身を確認するホスト４００から受け取ることから始まり、結果としてホストはホストプロファイルに関係付けられることになる。
【００６３】
ホストプロファイル４０６をそのホストにとって適切なデバイスマネージャー４０４から取得するために、登録サーバーはホスト識別データを使用する。また登録サーバー４１９はデバイスマネージャー４１０中のホスト目録４０８にアクセスすることにより、どのようなアップグレードが以前ホストに提供されたかを確認するために、ホスト識別データ（シリアル番号のような、ホスト独自の付加的情報を含み得る）を使用する。ホストは初めて初期化することになるので、そのホストに対するホスト目録に以前のアップデートの記録は存在しそうにない。加入者がどのサービスに関連しているかを確認するために、登録サーバーは更に適切な加入者サービスプロファイルを得る。登録サーバーは、加入者が料金を払っているサービスが行われるように、適切なソフトウェアオブジェクトがカルーセル経由でホストに提供されることを保証しなければならない。登録サーバーはダウンロードマネージャーに対して、要求されるオブジェクトがカルーセル中で回転にかけられるよう指示する。ある場合には要求されるオブジェクトは既に回転状態にあってもよいが、他の場合には一つ以上がダウンロードマネージャーによってロードされるよう要求されてもよい。更に、ダウンロードマネージャーはホストに、ダウンロードコマンドを通じてどのモジュールがピックアップされるべきか通知する。最後に、登録サーバーがダウンロードマネージャーにタスクが完了したこと、及びモジュールがもはやカルーセル中に必要とされないことを通知する。
【００６４】
登録サーバーはタスクのタイミングを調整する。登録サーバーは上記タスクを与えられた順序で遂行するか、もし実行可能ならそれらを並行して遂行してもよい。ふつう、情報がある特定の順序で得られることを指示する要求が多い。もしエラーに遭遇したら（たとえばデータが一時的にアクセスできないような）、登録サーバーは全ての必要とされる情報が処理の前に得られることを保証するとともに、エラーから回復するためにしかるべき行動を取らなければならない。
【００６５】
登録サーバーはダウンロードマネージャーに、ダウンロードマネージャーが適切なソフトウェアオブジェクトを選択し得るような情報を示す。種々の実施態様において、ダウンロードマネージャーに提供される情報は様々であり得る。ある実施態様においては、ダウンロードマネージャーは限定された知力を持ち、登録サーバーにより提供されるオブジェクトに関してかなり特定の情報を提供する。望ましい実施態様では、ダウンロードマネージャーはより高い知力を持ち、登録サーバーは高水準コマンドとその結果としてのプロファイル情報をダウンロードマネージャーに提供し、ダウンロードマネージャーはその情報をどのオブジェクトが要求されているかを決定するために使用する。例えば、登録サーバーは関連するプロファイル情報とサービスの水準をダウンロードマネージャーに示してもよい。すると、ダウンロードマネージャーはプロファイルデータを含む、自身に提供された情報と、ホストの目録プロファイルデータと、サイトプロファイルデータを、ダウンロードのために選択すべき適切なオブジェクトを確認するために使用する。ひとたび決定されれば、ダウンロードマネージャーは適切なオブジェクトがカルーセル上で回転していることを確実にすることができる。
【００６６】
ダウンロードマネージャーはこのステップを登録サーバーに対して認め、登録サーバーがデバイス提供マネージャーにホストへのダウンロードコマンドの提案を通知することを可能にしてもよい。適切なダウンロードコマンドがなければ、ホスト端末はオブジェクトをピックアップしないだろう。ダウンロードコマンドはビットマスクコマンドを含む種々の形を取ることができる。他の実施態様では、ダウンロードマネージャーはホストが適切なオブジェクトを組み込めるようにする目的で、ＸＭＬコマンドスクリプト（又は他の言語）をホストへ送信することもできる。ひとたび適切なモジュールが組み込まれると、そのホストのホスト目録プロファイルはホストがアップデートされたことを反映するためにアップデートされる。いくつかの実施態様においては、ホストはモジュールを受け取ったことを積極的に認めてもよいが、他の実施態様ではダウンロードマネージャーはホストがそれらを受け取ったことを推量することができる。
【００６７】
ブロードキャストアップデート
ダウンロードマネージャーはネットワーク管理者（又は他のシステム）に、多数のホストに対するブロードキャストアップデートを行わせる。この場合、ユーザーインターフェース（例えばグラフィカル又はコマンド言語の様な）を経由するネットワーク管理者は、一つ（又はそれ以上）のソフトウェアオブジェクトを配布のために選択することができる。これは特定のオブジェクト（複数可）を選択することによって、又はもっとあり得るのはコマンドを選択するか指示することによって、一つ以上のオブジェクトがダウンロードされることによってなされ得る。ダウンロードマネージャーは又、指示されたモジュールの動作の前提となる一組のモジュールを決定し、また選択されたモジュールが両立可能であることを保証するためのチェックを行う。例えば、もしユーザーがＶＯＤ関連のモジュールをアップデートすることを選択するなら、ダウンロードマネージャーは両立し得るファームウェアモジュールだけがそのホストのために選択されたことを保証する。モジュールの選択はプルダウンメニュー、選択アイコン等の周知のユーザーインターフェース技術のいずれかを用いてなされてもよい。
【００６８】
ダウンロードマネージャーは、適切な選択を確実にするために例えば図４ｂに図示されたような規則を使用してもよい。例えば、図４ｂによれば、ＥＰＧ１．０モジュールをアップデートすることを選択することは、ホストが既にファームウェアモジュール１．０、１．１、１．２、又は１．３の一つを所有する（又はダウンロードされている）時にだけ可能となる。システムはＥＰＧ１．０モジュールとファームウェアモジュール１．７の組み合わせは許可しない。なぜならこれらは両立し得ないからである。同様に、このシステムはＥＰＧ１．０モジュールがＶＯＤ１．０モジュールとだけ（ＶＯＤ２．０モジュールではなく）両立できることを了知している。これらの規則は典型的にはメタデータの形で各ソフトウェアモジュールに含まれるが、他の実施態様では、規則は単一のメタデータファイルに集められ得る。これらに係わらず、ダウンロードマネージャーは、両立し得る情報のみがホストにダウンロードされることを確実にするために該規則を使用する。
【００６９】
ダウンロードマネージャーはダウンロードの筋書きを作り出す過程を、ユーザーによりあるモジュールとの関連において入力された種々のコマンドを認識することにより更に抽出することができる。したがってネットワーク管理者は、コマンド言語を用いて「ブランドＸのテレビホストの全てのＶＯＤ１．０モジュールをＶＯＤ２．０モジュールにアップグレードせよ」、又は「全てのブランドＸのＳＴＢユニットを最新のＶＯＤバージョンにアップグレードせよ」を入力できる。前者の例では、システムはＶＯＤ２．０がＥＰＧ１．０と両立しないことを知るであろうし、したがってＥＰＧ１．０を有する適切なホストをも両立し得るバージョン（例えばＥＰＧ１．５）にアップグレードするだろう。また後者のバージョンでは、システムは現在のＶＯＤバージョンを知り、またどのブランドＸのＳＴＢユニットが現在のＶＯＤバージョンを持っているか、そしてどれがアップデートされるべきかを知るだろう。同様にダウンロードシステムは、どのファームウェアモジュールが必要か、適切なアップデートが必要か、ダウンロードコマンドの生成に係わる各モジュールの状態とリンクをも知る。
【００７０】
モジュール間の非両立性を回避するためにダウンロードマネージャーによって使用される規則は、典型的にはメタデータに含まれており、これは他のデータを記述するデータとして広く解釈され得る。メタデータはソフトウェアモジュールと関係付けられており、種々の実体において処理され得る。そのようなメタデータの一例は図４ｂに、各モジュールに関する特定の両立性情報を表現する表の形で開示されている。図４ｂは比較的簡単な一組の規則を含むが、モジュール間に渡ってチェックされなければならない両立性情報の一タイプを示す。モジュールの序列とともにどのモジュールが配布されるべきかに関するサイト固有情報を含むような、他の両立性規則が存在する。メタデータの一部と同様、どのホスト形式がそのモジュールと両立し得るか、といった他の規準が定義され得る。メタデータはモジュール自身とは別に表形式で提供され得る。典型的にはソフトウェアモジュールのプロバイダーは、ある与えられたモジュールを他の特定のソフトウェアモジュールと相互運用可能なものとして試験し認証すると同様、モジュールそれ自身との両立性情報を示す。もしそうであれば、ダウンロードマネージャーが他のモジュールとの両立性を保証するためにモジュールを処理するにあたって、別のファイルが必要とされることはなくてもよい。こうして、ソフトウェアモジュールコードに関連して、ソフトウェアオブジェクトコード開発者は、それがどの他のモジュールと両立し得るか及び相互に作用する必要に関する情報、及び該モジュールがどのように組み込まれるべきかを示す順序情報と同様に、その製作日付、バージョン番号、創作者情報のような、ソフトウェアモジュールを表現するメタデータを提供する。構成情報に関する情報を含む他の情報も提供され得る。あるソフトウェアモジュールに関連するメタデータは、ただそのモジュール自身、及び他のソフトウェア又はハードウェア上の特徴に対して存在し得る依存性に関連する。したがって、図４ｂに示された規則に戻ると、ある与えられたモジュールのためのメタデータは図４ｂに見出される全ての情報を含むわけではなく、ただ手近のモジュールに関連する情報のサブセットのみを含む。
【００７１】
ここで説明された発明の多くの修正及び他の実施態様は、上記の記述及び関連する図面中に示された教示の助けを借りれば、これらの発明の関連分野の当業者が想到し得るものであろう。したがって本発明は開示された特定の実施態様に限定されるべきものではなく、修正と他の実施態様が付属の請求の範囲に含まれていると理解されるべきである。特定の用語がここに使用されているが、それらは単に総称的、記述的な意味でのみ使用されたもので、制限を意図するものではない。
【００７２】
本発明は一般的な用語で説明されてきたが、ここに添付図面への参照が行われるが、これらの図面は必ずしも一定の縮尺で描かれているわけではない。
【図面の簡単な説明】
【００７３】
【図１】図１は、ホストソフトウェアをホストメーカーから強化サービスサーバーへと配布する実施態様を解説する図。
【図２ａ】図２ａは、特定のケーブルネットワークに対してソフトウェアモジュールを選択する種々の実施態様を解説する図。
【図２ｂ】図２ｂは、特定のケーブルネットワークに対してソフトウェアモジュールを選択する種々の実施態様を解説する図。
【図３】図３は、あるソフトウェアモジュールに潜在的に関係付けられた種々の状態の実施態様を解説する図。
【図４ａ】図４ａは、ホストに常駐する種々のソフトウェアモジュールの実施態様を解説する図。
【図４ｂ】図４ｂは、ソフトウェアモジュールのオペレーションに関連付けられた種々の制限の実施態様を解説する図。
【図４ｃ】図４ｃは、ホスト中におけるソフトウェアモジュールのアップデートに関連付けられたステップの実施態様を解説する。
【図５】図５は、ホストプロファイルとの関連付けのために情報を提供するホストの種々の実施態様を解説する。
【図６】図６は、ソフトウェアをホストにダウンロードする際に含まれる要素の実施態様を解説する。
【図７】図７は、ソフトウェアをホストにダウンロードする際に含まれるステップの実施態様を解説する。
【図１】
2007280392.tif 000003
【図２ａ】
2007280392.tif 000004
【図２ｂ】
2007280392.tif 000005
【図３】
2007280392.tif 000006
【図４ａ】
2007280392.tif 000007
【図４ｂ】
2007280392.tif 000008
【図４ｃ】
2007280392.tif 000009
【図５】
2007280392.tif 000010
【図６】
2007280392.tif 000011
【図７】
2007280392.tif 000012
【外国語明細書】
2007280392000001.pdf