(57)【特許請求の範囲】
【請求項１】
ゲートウェイ装置により実行される方法であって、
クライアント装置に係る第１認証要素と、前記ゲートウェイ装置に係る第２認証要素とを含むデータファイルを受信するステップであって、前記第１認証要素は前記クライアント装置が前記データファイルを利用することを認証するためのシグネチャであり、前記第２認証要素は前記ゲートウェイ装置が前記データファイルを利用することを認証するためのシグネチャである、前記受信するステップと、
前記第２認証要素が前記ゲートウェイ装置に対して有効であるか判断するステップと、
前記第２認証要素が前記ゲートウェイ装置に対して有効である場合、前記クライアント装置に対するクライアントファイルと前記第１認証要素とを格納するステップと、
を有する方法。
【請求項２】
前記第１認証要素と前記クライアントファイルとを前記ゲートウェイ装置から前記クライアント装置に送信するステップをさらに有する、請求項１記載の方法。
【請求項３】
前記データファイルの一部は、メタデータを有し、
前記クライアントファイルは、実行可能ファイルである、請求項１記載の方法。
【請求項４】
前記クライアントファイルは、前記データファイルの一部に含まれる、請求項１記載の方法。
【請求項５】
前記第１認証要素と前記第２認証要素とは、前記クライアントファイルに添付される、請求項１記載の方法。
【請求項６】
前記第２認証要素は、前記第１認証要素を変更することなく、前記第１認証要素上に署名される、請求項５記載の方法。
【請求項７】
前記第２認証要素は、前記ゲートウェイ装置のメーカーとサービスプロバイダの少なくとも１つによって、前記クライアントファイルと前記第１認証要素とに添付される、請求項５記載の方法。
【請求項８】
前記データファイルに含まれる前記ゲートウェイ装置又は前記クライアント装置の識別要素が、前記ゲートウェイ装置に格納されている前記ゲートウェイ装置又は前記クライアント装置に係る少なくとも１つの対応する識別要素に一致するか判断するステップと、
前記判断に基づき、前記データファイル内の情報を用いて前記クライアントファイルを特定するステップと、
をさらに有する、請求項１記載の方法。
【請求項９】
前記特定に基づき、前記クライアントファイルを受信するステップをさらに有する、請求項８記載の方法。
【請求項１０】
ゲートウェイ装置であって、
クライアント装置に係る第１認証要素と、当該ゲートウェイ装置に係る第２認証要素とを含むデータファイルを受信する手段であって、前記第１認証要素は前記クライアント装置が前記データファイルを利用することを認証するためのシグネチャであり、前記第２認証要素は当該ゲートウェイ装置が前記データファイルを利用することを認証するためのシグネチャである、前記受信する手段と、
前記第２認証要素が当該ゲートウェイ装置に対して有効であるか判断する手段と、
前記第２認証要素が当該ゲートウェイ装置に対して有効である場合、前記クライアント装置に対するクライアントファイルと前記第１認証要素とを提供する手段と、
を有するゲートウェイ装置。
【請求項１１】
前記第２認証要素が当該ゲートウェイ装置に対して有効である場合、前記クライアント装置に対するクライアントファイルと前記第１認証要素とを含む前記受信したデータファイルの一部を格納する手段をさらに有する、請求項１０記載のゲートウェイ装置。
【請求項１２】
前記第１認証要素と前記第２認証要素とが、前記クライアントファイルに添付される、請求項１０記載のゲートウェイ装置。
【請求項１３】
前記第２認証要素は、当該ゲートウェイ装置のメーカーとサービスプロバイダの少なくとも１つによって、前記クライアントファイルと前記第１認証要素とに添付される、請求項１０記載のゲートウェイ装置。
【請求項１４】
前記データファイルに含まれる当該ゲートウェイ装置又は前記クライアント装置の識別要素が、当該ゲートウェイ装置に格納されている当該ゲートウェイ装置又は前記クライアント装置に係る少なくとも１つの対応する識別要素に一致するか判断する手段と、
前記判断に基づき、前記データファイル内の情報を用いて前記クライアントファイルを特定する手段と、
をさらに有する、請求項１０記載のゲートウェイ装置。
【請求項１５】
ゲートウェイ装置であって、
クライアント装置に係る第１認証要素と、当該ゲートウェイ装置に係る第２認証要素とを含むデータファイルを受信する受信機であって、前記第１認証要素は前記クライアント装置が前記データファイルを利用することを認証するためのシグネチャであり、前記第２認証要素は当該ゲートウェイ装置が前記データファイルを利用することを認証するためのシグネチャである、前記受信機と、
前記受信機に接続され、前記第２認証要素が当該ゲートウェイ装置に対して有効であるか判断するプロセッサと、
前記プロセッサに接続され、前記第２認証要素が当該ゲートウェイ装置に対して有効である場合、前記クライアント装置に対する前記受信したデータファイルの一部と前記第１認証要素とを格納するメモリと、
を有するゲートウェイ装置。
【請求項１６】
前記プロセッサに接続され、前記第１認証要素と前記受信したデータファイルの一部とを当該ゲートウェイ装置から前記クライアント装置に送信する送信機をさらに有する、請求項１５記載のゲートウェイ装置。
【請求項１７】
前記データファイルはさらに、メタデータファイルと、前記クライアント装置に対する実行可能ファイルとを含む、請求項１５記載のゲートウェイ装置。
【請求項１８】
前記第１認証要素と前記第２認証要素とは、前記実行可能ファイルに添付される、請求項１７記載のゲートウェイ装置。
【請求項１９】
前記第２認証要素は、当該ゲートウェイ装置のメーカーとサービスプロバイダの少なくとも１つによって、前記実行可能ファイルと前記第１認証要素とに添付される、請求項１８記載のゲートウェイ装置。
【請求項２０】
前記プロセッサはさらに、前記データファイルに含まれる当該ゲートウェイ装置又は前記クライアント装置の識別要素が、当該ゲートウェイ装置に格納されている当該ゲートウェイ装置又は前記クライアント装置に係る少なくとも１つの対応する識別要素に一致するか判断し、前記判断に基づき前記データファイル内の情報を利用して前記実行可能ファイルを特定する、請求項１５記載のゲートウェイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００７年４月２３日に出願された仮出願第６０／９２５，８１０号の３５  Ｕ．Ｓ．Ｃ．§１１９による利益を主張する。
【０００２】
ここに提示される実施例は、一般にＭＤＵ（Ｍｕｌｔｉ−Ｄｗｅｌｌｉｎｇ  Ｕｎｉｔ）ネットワークにおけるクライアント装置のためにサービスを提供するのに使用されるゲートウェイ装置に関し、より詳細には、当該ネットワークにおけるゲートウェイ装置とクライアント装置との処理に係るファイルをダウンロードする機構に関する。
【背景技術】
【０００３】
複数の住宅やアパートメントなど、１つの場所における複数ユーザの処理のニーズに補完的な構成を利用した衛星テレビサービスなどのサービスを提供するシステムが、使用されてきた。ＭＤＵ設備などの設備のために用いられるシステムの構成は、しばしばサービスプロバイダのネットワークに接続される中央装置やゲートウェイ装置にローカルネットワークを介し接続されるクライアント装置を含む。
【０００４】
問題はしばしば、これらのシステムがフィールドアップグレード可能な装置を有するときのシステム、すなわち、フィールドアップグレード可能なシステムに関するものであるかもしれない。特に、フィールドアップグレード可能なシステムは、ソフトウェアのアップグレードを開始するため、ユニット単位でのオペレータの介入を必要とするかもしれない。この結果、アップグレードに必要とされる労力は、フィールド化されたユニットの個数についてスケーリングされる。さらに、典型的なフィールドアップグレード可能なシステムは、１以上の選択された設備において又は所与の設備における１以上のゲートウェイ装置において先進的な機能／能力を導入する自動化された方法を提供するものでない。
【０００５】
さらに、ネットワーク装置をアップグレードするのに用いられる各種タイプのファイル（実行可能なファイル、コンフィグレーションファイル、キーファイルなど）のセキュリティと真正性による問題が存在しうる。ゲートウェイ装置は、クライアント装置のリブートに続いて、クライアント装置へのダウンロードにおいて使用されるクライアント装置のファイルのアップグレードされた一覧表を維持するようにしてもよい。各クライアント装置のモデルのメーカーは、セキュリティの目的のため、サービスオペレータやメーカーにより生成されたキーを使用して署名される実行可能なコードファイルを提供する。この問題を解決する１つの方法は、ゲートウェイ装置にクライアント装置のファイルを署名するのに用いられるキーとアルゴリズムのリストを維持させるか、又は等価的にはクライアント装置のモデル毎の署名検証ルーチンのセットを維持させることである。しかしながら、この要求は、フィールド化されるシステムにおけるクライアントモデルとメーカーの数が増えるに従って、管理するのに困難となる。さらに、サービスオペレータとメーカーは、クライアント装置のファイルを署名するのに用いられるキー又はアルゴリズム情報をリリースしたがらない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
すなわち、この情報がオペレータやメーカーにより利用可能とされていると仮定して、モデル毎のキー／アルゴリズムのリストの負担を生じさせることなく、クライアント装置のファイルのソース（非拒絶）及びデータ完全性を検証するための方法が必要とされる。
【０００７】
ファイルの署名が公開秘密鍵暗号システムを用いて実行される場合、標準的なアプローチは、ゲートウェイ装置がクライアント装置のファイルを署名するのに使用される公開鍵又は公開鍵を有するＸ．５０９装置証明書のリストを維持すること、又は等価的にはゲートウェイ装置が埋め込み公開鍵を含む１以上の署名検証機能（公開／秘密鍵ペア毎に必要とされる１つの署名検証機能）を維持することである。同様に、秘密鍵がクライアント装置のファイルを署名するのに使用される場合、秘密鍵と検証アルゴリズムを埋め込む署名検証機能が提供される必要がある。これらの検証機能は、対応するクライアントモデル番号に適用及び管理される必要がある。
【０００８】
追加的なクライアント装置モデルがシステムに追加されるとき、さらなる複雑さが存在する。フィールド化されたゲートウェイ装置は、クライアントキー／検証機能の増大していくリストを管理し、それらを対応するクライアント装置モデル数に適用することを必要とする。従って、ネットワークにおける装置により使用されるファイルをダウンロードする改良された方法が必要とされ、さらにネットワークにおける複数の装置により使用される改良されたセキュリティ又は認証システムが必要とされる。開示された実施例は、これらの問題の１以上を解決する。
【課題を解決するための手段】
【０００９】
本実施例の一態様によると、ネットワークにおいて信号ソースからゲートウェイ装置にデータを提供する方法が開示される。一実施例によると、本方法は、第１ファイルと、ゲートウェイ装置に係るクライアント装置に一意的な第１認証要素と、第２認証要素とを受信するステップと、第２認証要素がゲートウェイ装置に対して有効であるか判断するステップと、第２認証要素がゲートウェイ装置に対して有効である場合、クライアント装置に対する第２ファイルと第１認証要素とを格納するステップとを有する。
【００１０】
本実施例の他の態様によると、ゲートウェイ装置が開示される。一実施例によると、ゲートウェイ装置は、第１認証要素と、第２認証要素とを含むデータであって、第１認証要素がゲートウェイ装置に係るクライアント装置に一意的であるデータを受信するターミナルと、第２認証要素がゲートウェイ装置に対して有効であるか判断するプロセッサと、第２認証要素がゲートウェイ装置に対して有効である場合、クライアント装置に対する受信したデータの一部と第１認証要素とを格納するメモリとを含む。
【図面の簡単な説明】
【００１１】
添付した図面と共に本開示の各実施例の以降の説明を参照することによって、本開示の上述された及び他の特徴及び効果とそれを達成する方法とがより明らかとなり、本開示がより良好に理解されるであろう。
【図１】図１は、本開示の実施例を利用する一例となるシステムを示すブロック図である。
【図２】図２は、図１のゲートウェイ装置の１つの関連部分を示すブロック図である。
【図３】図３は、図１のゲートウェイ装置の１つの一例となる実施例を示すブロック図である。
【図４】図４は、本開示の実施例を利用する一例となる方法を示すフローチャートである。
【図５】図５は、本開示の実施例を利用する一例となる方法を示す図４のフローチャートの続きである。
【図６】図６は、本開示の実施例を利用する一例となる方法を示す図５のフローチャートの続きである。
【図７】図７は、本開示の実施例を利用する一例となるデータ構造の図である。  ここに与えられる例示は本開示の好適な実施例を示し、このような例示は本開示の範囲を何れかの方法により限定するものとして解釈されるべきでない。
【発明を実施するための形態】
【００１２】
説明される実施例は、主としてＭＤＵにおいて見つけられる設備システムに関する。これらの実施例はまた、データネットワークを介しクライアント装置、セットトップボックス又は受信回路にコンテンツを提供するヘッドエンド又はゲートウェイインタフェースを利用する任意のネットワーク情報配信システムにおいて利用及び適用されてもよい。例えば、説明される実施例は、当業者に知られている技術を用いて飛行機やバスの乗客のエンターテイメント配信システムにおいて機能するよう変更されてもよい。
【００１３】
図面を参照するに、より詳細には図１を参照して、本開示の実施例を利用する一例となるシステム１００が示される。図１に示されるように、一例となるシステム１００は、ゲートウェイ装置１０と、メイン配信フレーム（ＭＤＦ）２０と、中間配信フレーム（ＩＤＦ）３０とを有する。一例となるシステム１００はまた、図示しない１以上の信号ソースとクライアント装置とを有する。一実施例によると、図１は、イーサネット（登録商標）や同軸ケーブル、デジタル加入者線（ＤＳＬ）、電力線ネットワーク接続、無線技術などの他のタイプのネットワークを利用したＭＤＵにおいて使用される典型的なシステムを表す。
【００１４】
図１において、各ゲートウェイ装置１０は、衛星、地上、ケーブル、インターネット及び／又は他のタイプの放送システムのヘッドエンドなどの信号ソース（すなわち、サービスプロバイダ）と動作接続し、通信する。一実施例によると、各ゲートウェイ装置１０は、信号ソースからオーディオ、ビデオ及び／又はデータコンテンツを含む複数の信号を受信し、受信した信号の信号フォーマットを変換し、その後、各居住ユニットのユーザによるリクエストに基づき、インターネットプロトコル（ＩＰ）フォーマットなどのフォーマットにより適切なデータストリームをＭＤＦ２０及びＩＤＦ３０を介したネットワークを通じてクライアント装置（セットトップボックス、テレビなど）に送信する。当該技術において知られているように、ＭＤＦ２０とＩＤＦ３０は、スイッチング装置及びルーティング装置として機能する。所与のＭＤＵ設備に含まれるゲートウェイ装置１０、ＭＤＦ２０及びＩＤＦ３０の個数は、設計選択に基づき変更されてもよい。各ＩＤＦ３０は、例えば、所与のフロア及び／又はＭＤＵの他の規定された部分に対して提供されるクライアント装置に対してサービスを提供するようにしてもよい。システム１００は、特定のネットワークフォーマットを利用したイーサネット（登録商標）ネットワークであるとして図示及び説明されるが、当業者は、本実施例の原理がまた同軸ケーブル、デジタル加入者線（ＤＳＬ）、電力線ネットワーク接続及び／又は無線技術を利用したネットワークなどの他のタイプのネットワークといくつかの可能なネットワークフォーマットに適用可能であることを理解するであろう。以降に説明される本開示の実施例によると、各ゲートウェイ装置１０は、ゲートウェイ装置１０及びクライアント装置の処理に係るファイルが最小限のオペレータの介入によりダウンロード可能となるよう動作する。
【００１５】
複数のゲートウェイ装置１０が同一のシステムサービスプロバイダヘッドエンドに接続されてもよいことに留意することが重要である。複数のゲートウェイ装置１０は、単一のゲートウェイ装置１０のサイズ又は能力の設計上の制約によりサービスプロバイダから、利用可能なコンテンツのすべてを受信及び配信するため必要とされるかもしれない。さらに、ゲートウェイ装置１０は、ＭＤＦ２０とによるローカルネットワーク接続とは独立して、又はこれに関連して互いに接続及び通信する機能を有してもよい。
【００１６】
信号ソースとクライアント装置との間でデータを管理するのに関連する他の機能に加えて、ゲートウェイ装置の１以上は、第１ファイル、ゲートウェイ装置に係るクライアント装置に一意な第１認証要素及び第２認証要素を受信するため、ハードウェア、ソフトウェア、ファームウェア又はこれらの何れかの組み合わせとして実現される要素を含むものであってもよい。１以上のゲートウェイ装置１０はまた、第２認証要素がゲートウェイ装置に対して有効であるか決定するため、ハードウェア、ソフトウェア、ファームウェア又はこれらの何れかの組み合わせとして実現される要素を含むものであってもよい。これらの要素はまた、第２認証要素がゲートウェイ装置に対して有効である場合、第１認証要素と、クライアント装置の実行可能なプログラムファイルなどのデータファイルとを格納するのに利用されてもよい。また、１以上のゲートウェイ装置１０は、ゲートウェイ装置１０から１以上のクライアント装置に第１認証要素とデータファイルとを送信するため、ハードウェア、ソフトウェア、ファームウェア又はこれらの何れかの組み合わせとして実現される要素を含むものであってもよい。
【００１７】
図２を参照するに、図１のゲートウェイ装置１０の１つの関連部分を示すブロック図が示される。図２のゲートウェイ装置１０は、入出力（Ｉ／Ｏ）ブロック１２と、プロセッサ１４と、メモリ１６とを有する。説明の簡単化のため、図２では、特定の制御信号、電力信号及び／又は他の要素などのゲートウェイ装置１０に係る特定の従来の要素は示されていないかもしれない。
【００１８】
Ｉ／Ｏブロック１２は、信号ソースからの信号の受信と、クライアント装置との信号の送受信を含む、ゲートウェイ装置１０のＩ／Ｏ機能を実行するよう動作可能である。一実施例によると、Ｉ／Ｏブロック１２は、衛星、地上、ケーブル又はインターネットなどの１以上の信号ソースから、アナログ形式及び／又はデジタル形式によりオーディオ、ビデオ及び／又はデータ信号などの信号を受信するよう動作可能である。Ｉ／Ｏブロック１２はまた、１以上の信号ソースに信号を出力するよう動作可能である。Ｉ／Ｏブロック１２はまた、ＭＤＦ２０を介しクライアント装置との間で信号を送受信するよう動作可能である。
【００１９】
プロセッサ１４は、ゲートウェイ装置１０の各種信号処理及び制御機能を実行するよう動作可能である。一実施例によると、プロセッサ１４は、クライアント装置による処理及び送信に適したフォーマットの信号を変換するため、Ｉ／Ｏブロック１２により受信したオーディオ、ビデオ及び／又はデータ信号を処理するよう動作可能である。
【００２０】
プロセッサ１４はまた、ゲートウェイ装置１０とクライアント装置の処理に係るファイルが最小限のオペレータの加入によりダウンロードされることを可能にするソフトウェアコードを実行するよう動作可能である。さらに、プロセッサ１４の上記態様とそれに係る機能に関するさらなる詳細が、以降に提供される。プロセッサ１４はまた、限定されることなく、図示されないユーザ入力装置を介して行われるユーザ入力の処理、メモリ１６に対するデータの読み書き、及び当業者に知られる他の処理を含むゲートウェイ装置１０の他の機能を実行及び／又は可能にするため動作可能である。好適な実施例では、プロセッサ１４は、第１ファイル、第１認証要素及び第２認証要素を含む情報を１／Ｏブロック１２から受信可能なマイクロプロセッサ装置を含む。プロセッサ１４は、第２認証要素がゲートウェイ装置に対して有効であるか判断し、第２認証要素がゲートウェイ装置に対して有効である場合、１以上のクライアント装置による格納、送信及び以降の利用のため、第１ファイルに係る第２ファイルと第１認証要素とを提供する。第１ファイルと第２ファイルとの間の関連付けは、以下に限定されるものでないが、第２ファイルと特定するメタデータを含む第１ファイルと、第１ファイル内に含まれる第２ファイルとを含むものであってもよい。
【００２１】
メモリ１６は、プロセッサ１４に動作接続され、ゲートウェイ装置１０のデータ格納機能を実行する。一実施例によると、メモリ１６は、以下に限定されるものでないが、実行可能ファイル及びコンフィグレーションファイルを含む各種タイプのファイル、ゲートウェイ装置１０と関連するすべてのクライアント装置のための各種タイプの識別情報並びにここに説明されるような他のデータを含むデータを格納してもよい。メモリ１６の少なくとも一部は、不揮発性であってもよい。
【００２２】
ゲートウェイ装置１０は、複数の衛星信号を含むいくつかの異なるタイプの放送信号を受信するよう構成されてもよい。ゲートウェイ装置１０はまた、放送信号において提供されるオーディオ及びビデオコンテンツを含む複数のネットワークデータ信号を生成し、ゲートウェイ装置１０とクライアント装置とを接続するネットワークを介しネットワークデータ信号を提供するよう構成されてもよい。
【００２３】
図３を参照するに、一例となる衛星ゲートウェイ装置のブロック図が示される。衛星ゲートウェイ装置３００は、図１に示されるゲートウェイ装置と同様である。図示されるように、衛星ゲートウェイ装置３００は、電源３４０と、２つのフロントエンド３４１ａ及び３４１ｂと、バックエンド３５２とを含む。電源３４０は、フロントエンド３４１ａ，３４１ｂ及びバックエンド３５２が後述される機能を実行するのを可能にするよう設定可能ないくつかの工業規格ＡＣ又はＤＣ電源の何れかであってもよい。
【００２４】
衛星ゲートウェイ装置３００はまた、２つのフロントエンド３４１ａ，ｂを有してもよい。一実施例では、フロントエンド３４１ａ，ｂのそれぞれは、図示しない１：２スプリッタから提供される２つの信号を受信するよう設定されてもよい。例えば、フロントエンド３４１ａは、１：２スプリッタの１つから２つの信号を受信するようにしてもよく、フロントエンド３４１ｂは、第２の１：２スプリッタから２つの信号を受信するようにしてもよい。
【００２５】
その後、フロントエンド３４１ａ，ｂはさらに、１：４スプリッタ３４２ａ，３４２ｂ，３４２ｃ，３４２ｄを用いて上記信号を細分化するようにしてもよい。細分化されると、これらの信号はデュアルチューナリンクの４つのバンク３４４ａ，３４４ｂ，３４４ｃ，３４４ｄにわたされるようにしてもよい。バンク３４４ａ〜３４４ｄ内のデュアルチューナリンクのそれぞれは、１以上のトランスポートストリームを生成するため、各デュアルチューナリンクにより受信される信号内に２つのサービスに調整するよう構成されてもよい。デュアルチューナリンク３４４ａ，３４４ｂ，３４４ｃ，３４４ｄのそれぞれは、トランスポートストリームを低電圧差動信号処理（ＬＶＤＳ）ドライバ３４８ａ，３４８ｂ，３４８ｃ，３４８ｄの１つに送信する。ＬＶＤＳドライバ３４８ａ〜３４８ｄは、バックエンド３５２に送信するためトランスポート信号を増幅するよう構成されてもよい。他の実施例では、異なる形式による差動ドライバ及び／又はアンプが、ＬＶＤＳドライバ３４８ａ〜３４８ｄの代わりに使用されてもよい。他の実施例は、バックエンド３５２へのルーティングと共に、トランスポート信号のすべての直列化を利用するようにしてもよい。
【００２６】
図示されるように、フロントエンド３４１ａ，ｂはまたマイクロプロセッサ３４６ａ，３４６ｂを有してもよい。一実施例では、マイクロプロセッサ３４６ａ，ｂは、デュアルチューナリンクと１：４スプリッタ３４２ａ〜３４２ｄのバンク３４４ａ〜３４４ｄへのコマンドを制御及び／又は中継する。マイクロプロセッサ３４６ａ，ｂは、例えば、ＳＴ  Ｍｉｃｒｏｅｌｅｃｔｒｏｎｉｃｓにより製造されるＳＴ１０マイクロプロセッサを有してもよい。他の実施例では、異なるプロセッサが使用されてもよく、又は制御がバックエンド３５２においてプロセッサから導かれてもよい。マイクロプロセッサ３４６ａ，ｂは、ＬＶＤＳ受信及び送信モジュール３５０ａ，３５０ｂに接続されてもよい。ＬＶＤＳ受信／送信モジュール３５０ａ，ｂは、後述されるように、バックエンド３５２上のコンポーネントとデュアルチューナリンクのバンク３４４ａ〜３４４ｄとの間のトランスポート信号の通信を実行する。
【００２７】
バックエンド３５２に続いて、バンクエンド３５２は、ＬＶＤＳドライバ３４８ａ〜３４８ｄにより送信されたトランスポートストリーム信号を受信するよう構成されるＬＶＤＳ受信機３５４ａ，３５４ｂ，３５４ｃ，３５４ｄを含む。バックエンド３５２はまた、ＬＶＤＳ受信／送信モジュール３５０ａ，ｂと通信するよう構成されるＬＶＤＳ受信／送信モジュール３５６ａ，３５６ｂを含む。
【００２８】
図示されるように、ＬＶＤＳ受信機３５４ａ〜３５４ｄとＬＶＤＳ受信機／送信機３５６ａ，ｂとは、コントローラ又はトランスポートプロセッサ３５８ａ，３５８ｂと通信するよう構成される。一実施例では、トランスポートプロセッサ３５８ａ，ｂは、フロントエンド３４１ａ，ｂにおけるデュアルチューナリンクにより生成されるトランスポートストリームを受信するよう構成される。トランスポートプロセッサ３５８ａ，ｂはまた、トランスポートストリームを上述されたローカルネットワークを介しマルチキャスト可能なインターネットプロトコル（ＩＰ）パケットに再パケット化するよう構成されてもよい。例えば、トランスポートプロセッサ３５８ａ，ｂは、ブロードキャストプロトコルパケットをＩＰプロトコルパケットに再パッケージ化し、その後、これらのＩＰパケットをＩＰアドレスによりクライアント装置の１以上にマルチキャストしてもよい。
【００２９】
トランスポートプロセッサ３５８ａ，ｂはまた、３２ビット６６ＭＨｚＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスに接続されてもよい。バス３６２を介し、トランスポートプロセッサ３５８ａ，ｂは、他のコントローラ又はネットワークプロセッサ３７０、イーサネット（登録商標）インタフェース３８４及び／又は拡張スロット３６６と通信してもよい。ネットワークプロセッサ３７０は、ローカルネットワークからサービス要求を受信し、トランスポートプロセッサ３５８ａ，ｂに要求されたサービスをマルチキャストするよう指示するよう構成されてもよい。ネットワークプロセッサ３７０はまた、クライアント装置により使用されるソフトウェアのダウンロードを管理するようにしてもよい。一実施例では、ネットワークプロセッサは、インテルにより製造されるＩＸＰ４２５であり、フロントエンド３４１ａ，ｂからデータなどの情報を受信するため、ソフトウェアコードを実行する。データダウンロードはまた、イーサネット（登録商標）インタフェース３６８又はモデム３７２を用いて実行されてもよい。データは、メタデータ、１以上の実行可能ファイル、第１認証要素及び第２認証要素を有してもよい。ネットワークプロセッサ３７０は、第２認証要素がゲートウェイ装置に対して有効であるか判断し、第２認証要素がゲートウェイ装置に対して有効である場合、１以上のクライアント装置による格納、送信及び以降の使用のため、第１認証要素と第１ファイルに係る第２ファイルとを提供する。第１ファイルと第２ファイルとの間の関連付けは、以下に限定されるものでないが、第２ファイルを特定するメタデータを含む第１ファイルと、第１ファイル内に含まれる第２ファイルとを含むものであってもよい。図示されないが、ネットワークプロセッサ３７０はまた、状態データを衛星ゲートウェイ装置３００のフロントパネルに送信し、又はデバッグポートを介し衛星ゲートウェイ装置３００のデバッグ処理又はモニタリングをサポートするよう構成されてもよい。
【００３０】
図示されるように、トランスポートプロセッサ３５８ａ，ｂは、バス３６２を介しイーサネット（登録商標）インタフェース３６８に接続される。一実施例では、イーサネット（登録商標）インタフェース３６８は、ローカルネットワークとの銅線又は光ファイバを提供するギガビットイーサネット（登録商標）インタフェースである。他の実施例では、デジタルホームネットワークアプリケーションに使用されるものなど、他のインタフェースが使用されてもよい。さらに、バス３６２はまた、衛星ゲートウェイ装置３００のアップグレード又は拡張を可能にするため、ＰＣＩ拡張スロットなどの拡張スロットに接続されてもよい。
【００３１】
トランスポートプロセッサ３５８ａ，ｂはまた、ホストバス３６４に接続されてもよい。一実施例では、ホストバス３６４は、トランスポートプロセッサ３５８ａ，ｂと、ＰＳＴＮ（Ｐｕｂｌｉｃ  Ｓｗｉｔｃｈｅｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ）２８を介し通信するよう構成されるモデム３７２とを接続する１６ビットデータバスである。他の実施例では、モデム３７２はまた、バス３６２に接続されてもよい。
【００３２】
ネットワークプロセッサ３７０はまた、ゲートウェイ装置３００の動作の各種態様に関する情報を格納するためのメモリを有してもよい。メモリは、ネットワークプロセッサ３７０内に設けられてもよく、又は図示されないが、外部に設置されてもよい。メモリは、受信リソースのチューニング情報と共に、タイマーやアナウンスメントに関する情報などの状態情報を格納するのに使用されてもよい。
【００３３】
トランスポートプロセッサ３５８ａ，ｂ、ネットワークプロセッサ３７０及びマイクロプロセッサ３４６ａ，ｂが、衛星ゲートウェイ装置３００の処理に必要な制御機能の何れか又はすべてを実行可能なより大きなコントローラ又は処理ユニットに含まれてもよい。制御機能の一部又はすべてはまた、他のブロックに分散されてもよく、衛星ゲートウェイ装置３００内の主要な処理に影響を及ぼさないようにしてもよい。
【００３４】
図４〜６を参照するに、本開示の一例となる方法を示すフローチャートが示される。具体例及び説明のため、図４〜６の方法は図１のシステム１００と図２のゲートウェイ装置１０の各要素を参照して説明される。図４〜６の方法は図３のゲートウェイ装置３００を参照して同様に説明可能であることに留意すべきである。また、具体例及び説明のため、図４〜６の各ステップは１つのゲートウェイ装置１０を参照して主に説明される。しかしながら、実際には、所与のＭＤＵ設備の各ゲートウェイ装置１０は、図４〜６のステップの一部又はすべてを別々にかつ独立に実行するようにしてもよいことが理解されるであろう。図４〜６の各ステップは、単なる一例であり、本開示を何れかの方法により限定することを意図するものでない。
【００３５】
ステップ４１０において、自動的なアップデートタイマーがスタートされる。一実施例によると、各ゲートウェイ装置１０は、ファイルアップグレード処理を開始する時点を決定するため、自動アップデートタイマーを維持する。図４に示されるように、自動アップデートタイマーが経過すると、タイマーはステップ４２０において再開される。ステップ４２０から、処理フローは、ファイルアップデート処理がスタートするステップ４３０に進捗する。
【００３６】
ステップ４３０において、データファイルが、所定のファイルサーバ（ｓｆｔｐ．ｍｆｈ３．ｃｏｍなど）などの信号ソースからゲートウェイ装置１０にダウンロードされる。ダウンロードされたデータファイルは、Ｉ／Ｏ１２などのゲートウェイ装置１０の入力により受信されてもよい。受信されたデータファイルは、同一の又は異なるリモートファイルサーバからダウンロードするため、利用可能なファイルの記述を含むメタデータを含む。一実施例によると、使用されるデータファイルフォーマットは、他のタイプのファイルフォーマットもまた利用可能であるが、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）である。ＸＭＬは、ドキュメントを生成するための基礎とドキュメントシステムとを提供する。ＸＭＬは、２つのメインレベルに対して機能する。すなわち、第１には、ドキュメントマークアップのためのシンタックスを提供し、第２には、ドキュメントの構造を宣言するためのシンタックスを提供する。より重要なことは、ＸＭＬは、多数の変換レイヤを通過する必要なく、各種コンピュータ、アプリケーション及び構成の間で情報を共有するのに利用可能な基本的なシンタックスを提供する。本実施例によると、ステップ４３０においてダウンロードされるデータファイルの各エントリは、１以上のＸＭＬ情報タイプを含むものであってもよい。ＸＭＬ情報タイプの具体例は、ファイル名、ファイルバージョン、ファイルサイズ、ファイルタイプ、ファイル情報及びシグネチャフラグなどの認証情報を含む。上述された以外のファイル属性もまた可能である。
【００３７】
一実施例によると、ＸＭＬファイルはまた、“オーバライド（ｏｖｅｒｒｉｄｅ）”セクションを有する。後述されるように、このオーバライドセクションは、一部のゲートウェイ装置１０がゲートウェイ装置１０により格納される特定の識別情報に応じて特定のファイルをダウンロードすべきであることをヘッドエンドオペレータが規定することを可能にする。
【００３８】
ステップ４３０及び“Ａ”から、処理フローは、ゲートウェイ装置１０がダウンロードされたデータファイルを解析するステップ４４０に進捗する。一実施例によると、プロセッサ１４は、ステップ４４０においてデータファイルのコンテンツを解析及び調べる。上述されるように、データファイルは、ダウンロードするのに利用可能なファイルの記述を含む。このようなファイルは、例えば、ゲートウェイ装置１０の実行可能ファイル、ゲートウェイ装置１０のコンフィギュレーションファイル、ゲートウェイ装置１０のキーファイル、１以上のクライアント装置の実行可能ファイル及び／又は他のタイプのファイルを含むものであってもよい。実行可能ファイルはまた、ここでは“イメージ”として参照されてもよい。本実施例で利用可能なＸＭＬ固有情報は以下のとおりである。
【００３９】
ファイル情報タイプは、以下のようにＸＭＬタグにより示される。
【００４０】
【表１】
0005406177.tif 000002
１つのファイルに対する完全なＸＭＬ構造は以下のとおりである。
【００４１】
【表２】
0005406177.tif 000003
例えば、クライアント装置の所与のモデル番号に対するファイルは、以下のように指定されてもよい。
【００４２】
【表３】
0005406177.tif 000004
ＸＭＬ構造は、ディレクトリ名の一部としての属性を有するディレクトリ構造として概念的にみなすことが可能である。すなわち、上記ファイルの情報は、“Ｇａｔｅｗａｙ：Ｃｌｉｅｎｔ／Ｍａｎｕｆａｃｔｕｒｅｒ：７ｄ／Ｍｏｄｅｌ：０００ｅ”というディレクトリに概念的にある。
【００４３】
第２のクライアント装置の所与のモデルに対するファイルは、＜／Ｍａｎｕｆａｃｔｕｒｅｒ＞タグの前に以下の情報を追加することによって示される。
【００４４】
【表４】
0005406177.tif 000005
ＸＭＬファイルは、“ディレクトリ”を１回生成してもよい。すなわち、すべてのクライアント装置のエントリは、タグ＜Ｇａｔｅｗａｙ  Ｉｍａｇｅ＝“Ｃｌｉｅｎｔ”＞とタグ＜／Ｇａｔｅｗａｙ＞との間にあってもよい。トムソンからのすべてのクライアントイメージは、タグ＜Ｍａｎｕｆａｃｔｕｒｅｒ  ＩＤ＝“７ｄ”＞とタグ＜／Ｇａｔｅｗａｙ＞との間にあってもよい。
【００４５】
上述した“オーバライド”のシンタックスは、以下のとおりである。
【００４６】
【表５】
0005406177.tif 000006
ダウンロードのため利用可能なファイルの記述と情報を含めるのに加えて、データファイルはまた利用可能なファイル自体の一部又は全部を含むようにしてもよいことに留意することが重要である。当初のデータファイルのダウンロードの一部としてファイルを含めることは、さらなるダウンロード及び通信ステップを排除する可能性がある。
【００４７】
ステップ４４０から、処理フローは、“Ｂ”により示されるように、図５のステップ５１０に進捗する。ステップ５１０において、ゲートウェイ装置１０は、ゲートウェイ装置１０（ゲートウェイファイルである場合）又は適用可能なクライアント装置（クライアントファイルである場合）のマーケット識別情報がデータファイルのオーバライドセクションの対応するエントリに一致するか判断する。一実施例によると、プロセッサ１４は、データファイルのオーバライドセクションの対応するエントリと、メモリ１６に格納されているゲートウェイ装置１０又は適用可能なクライアント装置のマーケット識別データとを比較することによって、ステップ５１０を実行する。
【００４８】
ステップ５１０における決定が否定的なものである場合、処理フローは、ゲートウェイ装置１０が、ゲートウェイ装置１０（ゲートウェイファイルである場合）又は適用可能なクライアント装置（クライアントファイルである場合）のサイト情報がデータファイルのオーバライドセクションの対応するエントリに一致するか判断するステップ５２０に進捗する。一実施例によると、プロセッサ１４は、データファイルのオーバライドセクションの対応するエントリとメモリ１６に格納されているゲートウェイ装置１０又は適用可能なクライアント装置のサイト識別データとを比較することによって、ステップ４１０を実行する。
【００４９】
ステップ５２０における決定が否定的なものである場合、処理フローは、ゲートウェイ装置１０が、ゲートウェイ装置１０（ゲートウェイファイルである場合）又は適用可能なクライアント装置（クライアントファイルである場合）のＣＡＭ（Ｃｏｎｄｉｔｉｏｎａｌ  Ａｃｃｅｓｓ  Ｍｏｄｕｌｅ）識別情報が、データファイルのオーバライドセクションの対応するエントリに一致するか決定するステップ５３０に進捗する。一実施例によると、プロセッサ１４は、データファイルのオーバライドセクションの対応するエントリとメモリ１６に格納されているゲートウェイ装置１０又は適用可能なクライアント装置のＣＡＭ識別データとを比較することによって、ステップ４１０を実行する。
【００５０】
ステップ５１０，５２０又は５３０における決定は肯定的なものである場合、処理フローは、プロセッサ１４により、ゲートウェイ装置１０がオーバライドファイル情報を利用して、オリジナルデータファイルからダウンロード又は解析するファイルバージョンの名前を特定すると判断するステップ５４０に進捗する。すなわち、ダウンロード又は解析するファイルバージョンの名前は、データファイルのオーバライドセクションから取得される。上記の例では、ステップ５１０における決定が肯定的なものである場合（すなわち、マーケット識別情報が一致する）、ダウンロードするファイルバージョンの名前は、“Ｕｓｅｌｎｄｙ”となる。同様に、ステップ５２０における決定が肯定的なものである場合（すなわち、サイト識別情報が一致する）、ダウンロードするファイルバージョンの名前は、“ＵｓｅＡｌｐｈａ”である。また、ステップ５３０における決定が肯定的なものであって（すなわち、ＣＡＭ識別情報が一致する）、ゲートウェイ装置１０又は適用可能なクライアント装置のＣＡＭ識別情報が“００１５７９０４６１６８”である場合、ダウンロードするファイルバージョンの名前は、“ＵｓｅＢｅｔａ”である。他方、ステップ５１０，５２０，５３０のそれぞれにおける判定が否定的なものである場合、処理フローは、プロセッサ１４により、ゲートウェイ装置１０がデフォルトファイル情報を使用して、ダウンロードするファイルバージョンの名前を特定することが判断されるステップ５５０に進捗する。デフォルトファイル情報はまた、データファイルに指定されるが、明示的には示されない。特定された実行可能ファイルがオリジナルのデータファイルから解析される場合、同様のステップがとられる。
【００５１】
ステップ５４０又はステップ５５０から、処理フローは、“Ｃ”により示されるような図６のステップ６１０に進捗する。ステップ６１０において、ファイル情報（すなわち、ステップ５４０によるオーバライド情報又はステップ５５０によるデフォルト情報）がゲートウェイ装置１０又は特定のクライアント装置のためのメーカー識別情報とモデル識別情報とに一致するか判定される。一実施例によると、プロセッサ１４は、データファイルのメーカー識別情報とモデル識別情報のエントリと、メモリ１６に格納されているゲートウェイ装置１０又は特定のクライアント装置のためのメーカー識別情報とモデル識別データとを比較することによって、ステップ６１０を実行する。
【００５２】
ステップ６１０における決定が肯定的なものである場合、処理フローは、ゲートウェイ装置１０がオーバライド又はデフォルト情報により規定されるファイルのバージョンをすでに格納したか決定されるステップ６２０に進捗する。一実施例によると、プロセッサ１４は、オーバライド又はデフォルト情報により規定されるファイルのバージョンとメモリ１６に現在格納されているファイルバージョンとを比較することによって、ステップ６２０を実行する。
【００５３】
ステップ６１０における決定が否定的なものである場合、又はステップ６２０における決定が肯定的なものである場合、処理フローは、ゲートウェイ装置１０がデータファイルの解析を実行したか決定されるステップ６３０に進捗する。一実施例によると、プロセッサ１４は、データファイル全体が解析されたか判断することによってステップ６３０を実行する。ステップ６３０における決定が肯定的なものである場合、処理フローは、本方法が終了されるステップ６４０に進捗する。あるいは、ステップ６３０における決定が否定的なものである場合、処理フローは、“Ａ”により示されるような図４のステップ４４０にループバックし、データファイル全体が対象となるすべてのファイルタイプに対して、すなわち、関連するクライアント装置と共にゲートウェイ装置１０に対するファイルについて解析されるまで、上述したステップが繰り返される。
【００５４】
ステップ６２０を再び参照するに、そこでの判定が否定的なものである場合、処理フローは、新たなファイルバージョンがゲートウェイ装置１０にダウンロードされ、新たなファイルバージョンに付属するゲートウェイ装置１０に係る認証要素（すなわち、シグネチャ）がプロセッサ１４の制御の下でチェックされるステップ６５０に進捗する。新たにダウンロードされたファイルは、ステップ４３０について上述されたものと同様の方法により受信されてもよい。あるいは、ステップ６５０において、新たなファイルバージョンがオリジナルのデータファイルの一部として含まれる場合、オリジナルのデータファイルから解析可能であり、認証要素がチェックされる。ステップ６６０において、プロセッサ１４は、ゲートウェイ装置１０に係る認証要素（すなわち、シグネチャ）が有効であるか判断する。一実施例によると、プロセッサ１４は、メモリ１６に格納されているゲートウェイ装置１０の公開鍵を用いてファイルのハッシュ値を復元するため、認証要素（すなわち、シグネチャ）を解読することによって、ステップ６６０を実行する。その後、プロセッサ１４は、ファイル（シグネチャ部分を含まない）に対してそれ自体のハッシュ値を計算する。プロセッサ１４は、シグネチャ部分に対しては自らのハッシュ値を計算しない。これは、当該部分が最初のハッシュ値を決定するためすでに解読されているためである。その後、プロセッサ１４は、これら２つのハッシュ値を比較する。２つのハッシュ値が一致する場合、シグネチャは有効であるとみなされる。他方、２つのハッシュ値が一致しない場合、シグネチャは無効であるとみなされる。ここでの認証処理はクライアント装置が使用するファイルに含まれる何れかの認証要素（すなわち、シグネチャ）を変更することなく、それから独立して実現されてもよい。このようにして、クライアントの認証要素のセキュリティと完全性とが、ゲートウェイ装置１０の処理により変更、影響又は特定されない。
【００５５】
一実施例によると、ゲートウェイ装置１０のためにダウンロードされたファイルは１つの認証要素しか有しないが、クライアント装置のためにダウンロードされたファイルは２つの異なる認証要素を有する。図７において、ゲートウェイ装置１０のためのダウンロードされたファイルの一例となるデータ構造７０は、ゲートウェイファイル７４に添付されたゲートウェイシグネチャ７２を含む。さらに、クライアント装置のためのダウンロードされたファイルの一例となるデータ構造８０は、クライアントファイル８４に添付されたクライアントシグネチャ８２を含み、さらにゲートウェイ装置１０のメーカー又はサービスプロバイダにより添付されたゲートウェイシグネチャ７２を有する。上述されるように、図７に示されるデータ構造は、ゲートウェイファイル及び添付されたゲートウェイシグネチャをダウンロードするのに使用されるデータ構造を表す。受信したゲートウェイファイルは、同じステップ又は別のステップにおいて、添付されたクライアントシグネチャとゲートウェイシグネチャと共にダウンロードされる１以上のクライアントファイルの識別情報を含むものであってもよい。クライアントファイルを特定するための別のゲートウェイファイルの使用は、例えば、複数のクライアント装置のベンダーがクライアントファイルとクライアントシグネチャとを提供しているときに重要となるかもしれない。
【００５６】
データ構造８０において、クライアントシグネチャ８２とクライアントファイル８４とは変更されず、それのフォーマット又はコンテンツについて何れの仮定もなされない場合、不明りょうなデータファイルとして扱われる。ゲートウェイシグネチャ７２のクライアントシグネチャ８２及びクライアントファイル８４への追加は、ゲートウェイ装置１０のメーカー又はサービスプロバイダによるオーバシグネチャ（ｏｖｅｒ−ｓｉｇｎａｔｕｒｅ）を表す。このオーバシグネチャは、特定のゲートウェイ装置ベンダー及び／又はゲートウェイ装置モデル番号により排他的利用のため選択された署名キーを用いて生成される。一実施例によると、メーカー又はモデル番号に関係なく、すべてのクライアント装置のファイルは、同一のゲートウェイ署名キーを用いて上書き署名又はオーバ署名（ｏｖｅｒ−ｓｉｇｎ）される。ゲートウェイ装置１０が新たな又はアップデートされたクライアント装置ファイルを受信すると、それは、ゲートウェイ署名キー（公開／秘密暗号システムが使用される場合、公開鍵）及び／又はゲートウェイシグネチャ検証ルーチンを用いて、それのオーバシグネチャを検証する。一実施例によると、プロセッサ１４は、最も外側のシグネチャが図６のステップ６６０において有効であるか決定するだけである。すなわち、プロセッサ１４は、ステップ６６０において、ゲートウェイシグネチャ７２の有効性しかチェックしない。
【００５７】
図７に示されるデータ構造が単一のデータ構造にマージされてもよいことに留意することが重要である。マージされた構造の一実施例では、１以上の各クライアント装置のファイルが、添付された各クライアントのシグネチャと共に連結された構造に添付され、マージされた構造のオーバシグネチャとして使用される。ここに記載されるマージされた構造は、クライアントファイルが後述されるようにダウンロードされたファイルから解析されるデータ構造を表す。マージされた構造は、特に１つの装置メーカーからの複数のクライアント装置モデルに関する装置ファイルのダウンロードについて、より効率的なダウンロードについて望ましいかもしれない。
【００５８】
図６に戻って、ステップ６６０における決定が肯定的なものである場合、処理フローは、新たにダウンロードされたファイルバージョンがプロセッサ１４の制御の下でメモリ１６の不揮発性部分に格納されるステップ６７０に進捗する。メモリ１６の不揮発性部分への新たにダウンロードされたファイルバージョンの格納は、電力不足などの予期しない動作中断などによる、潜在的なネットワーク及び装置のセキュリティ問題を回避する。一実施例にると、ステップ６７０においてクライアント装置のためにファイルバージョンを格納すると、ゲートウェイ装置１０は、オーバシグネチャバイト（すなわち、ゲートウェイシグネチャ７２）を破棄し、オリジナルのクライアントシグネチャ８２とクライアントファイル８４を変更せずに維持する。ゲートウェイ装置１０は、このオリジナルの署名付きのクライアントファイルをメモリ１６の不揮発性部分に格納し、その後、クライアント装置からのリブート／ファイルダウンロードリクエストの受信などに続いて、これを１以上のクライアント装置に送信又はダウンロードしてもよい。ステップ６７０から、処理フローは、上述されるようなステップ６３０に進捗する。
【００５９】
上述された各実施例の１つの効果は、メーカーにかかわらず、クライアント装置のすべてのモデルが１つのゲートウェイ署名キーにより上書き署名又はオーバ署名可能であり、これにより、クライアントファイルの署名が提供するセキュリティ効果のすべてを維持しながら、複数のモデル／メーカーの管理を簡単化することである。他の特徴に加えて、上述されたオーバ署名は、ゲートウェイ装置１０において使用される署名キーと、クライアント装置のためのファイルがクライアント装置に送信されると使用される別の署名キーとの共存を可能にする。
【００６０】
ここに記載される実施例は、最小限のオペレータの介入によりクライアント装置ファイルと共にゲートウェイ装置ファイルを自動的にアップグレードするための機構に関する。この機構は、リモートファイルサーバから最初にダウンロードされるメタデータファイルを用いる。このメタデータファイルは、同一の又は異なるリモートファイルサーバからダウンロードされる利用可能なファイルの記述を含む。メタデータファイルは、特定の地域、サイト及び／又はユニットなどの特定のパラメータに基づきターゲットとされたダウンロード又はすべてのゲートウェイ装置に対するグローバルなダウンロードを可能にする情報を含む。
【００６１】
さらに、各実施例は、第三者のファイルがそれを署名するのに使用されたオリジナルのキー又はアルゴリズムへのアクセス又は知識を必要とすることなく検証可能となるように、適用されるオーバ署名技術を説明する。オーバ署名技術は、イメージ署名が提供するセキュリティ効果のすべてを維持しながら、これらのイメージの管理を大きく簡単化する。オーバ署名技術は、ここに記載されるダウンロード機構と共に又は他のダウンロード制御機構と共に使用されてもよい。
【００６２】
各実施例は好適な設計を有するものとして説明されたが、本実施例はさらに、本開示の趣旨及び範囲内において変更可能である。従って、本願は、それらの一般的原理を用いた実施例の何れかの変形、使用又は適応化をカバーするものとされる。さらに、本願は、本開示が属し、添付した請求項の範囲内に属する分野における既知の又は慣例的な実施の範囲内にあるものとして、本開示からの逸脱をカバーするものとされる。
【図１】
0005406177.tif 000007
【図２】
0005406177.tif 000008
【図３】
0005406177.tif 000009
【図４】
0005406177.tif 000010
【図５】
0005406177.tif 000011
【図６】
0005406177.tif 000012
【図７】
0005406177.tif 000013