JP4901044B2 - 送信方法及び端末 - Google Patents

Description

【０００１】
本発明は、機器を更新する、或いは、機器に新しい機能を付与するための、通信センターによって配信されるデータをダウンロードする方法に関する。
【０００２】
本発明は、特に、典型的には、テレビ映像デコーダ受信機である機器のメモリへダウンロードされるべきプログラムの送信に関する。
【０００３】
以下では、簡単のためデコーダと呼ぶこれらの機器は、衛星、無線網、若しくは、光ケーブル（同軸若しくは光）によって放送された信号を受信する。放送網による伝送のモードは単方向である。放送信号は、テレビ向けの映像（ピクチャー）及び音声（サウンド）と、デコーダ向けのデジタル情報とを表わす。放送網は、数個の放送チャネルにより構成される。チャネルは、通信手段を用いて、継続的に情報を取得する手段である。アナログ方式テレビの場合、チャネルは、放送局に割り当てられた周波数帯域である。この場合、デジタル情報は、フレームのフライバック、又は、ＶＢＩ（垂直帰線消去期間）に放送される。デジタル方式テレビの場合、チャネルは、同じプログラム識別子が与えられたデータストリームであり、第２レベルの識別情報によって、視聴覚（映像・音声）データを、デジタル情報と区別することが可能である。このデジタル情報は、双方向サービス、テレテキスト、又は、デコーダのソフトウェアを更新するためのデータなどを含む。
【０００４】
デコーダは、読み出し専用メモリ、及び／又は、不揮発性プログラマブルメモリに格納されたソフトウェアを実行する中央ユニットを含む。中央ユニットは、一般的に、屡々、リターンパスと称される双方向対話用のインタフェースを備え、通信センターとの間に特定リンクを確立することが可能である。このインタフェースは、典型的に、交換網に連結されたモデムである。
【０００５】
放送網によって受信された情報は、特に、更新用データであり、この更新用データによって、デコーダの機能を向上させることができる。更新用データはプログラマブルメモリに保持される。更新キャンペーン中に行われる更新用データの自動ダウンロードによって、デコーダ側でユーザが手動で介入する必要がなくなる。更新用データは、セッション中に繰り返し送信される。
【０００６】
デコーダの主要な機能は、ユーザに映像及び双方向サービスを提供することである。更新用データのダウンロードは、２次的な機能であり、非優先タスク（作業）である。デコーダのリソースは、双方向サービスと、更新用データのダウンロードの両方を必ずしも管理できなくても構わない。したがって、できる限りユーザに不便をかけることなく、ダウンロードを実行し得る解決策を見つけることが必要である。リターンパスを用いたデータの系統的なダウンロードは考えられない。なぜならば、リターンパスは、放送網の帯域よりも更に帯域が制限され、専用回線の使用は費用が高くつくからである。本発明は、できる限りユーザに不便をかけることがないようにデコーダのリソースを調整することによって、更新用データをダウンロードするフレキシブルな方式の提供を目的とする。
【０００７】
したがって、本発明が対象とする通信センターによって複数の端末へ更新用データを送信する方法は、
更新用データを配信することにより更新キャンペーンを放送する手順と、
センターと、状態の標識をセンターへ送信する少なくとも一部の端末との間に双方向通信を設定する手順と、
実際に更新された端末の台数を、センターのレベルで判定する手順と、
更新された端末の台数の関数として、新しい更新キャンペーンを中断、若しくは、始動する手順と、
更新が無いという標識が端末によって発信された後、ポイント・ツー・ポイント接続を用いて、センターからこの端末へ更新用データを送信する手順と、
を有することを特徴とする。
【０００８】
このようにして、センターは、実際に更新された端末の台数を確認することが可能である。この台数が不足している場合、センターは、現在の更新キャンペーンを中止することが可能であり、或いは、逆に、現在のキャンペーンの終了時に、この台数が不十分である場合、センターは新しいキャンペーンを開始することができる。連続した更新キャンペーンの後に、更新されていない端末の台数が僅かであるならば、更新されていない端末は、ポイント・ツー・ポイント接続を用いることにより、特定の通信の途中で更新される。これによって、小数の端末に向けられたデータを配信するために帯域を使用し続けることが防止される。
【０００９】
また、本発明は、センターが更新キャンペーンを放送し、更新キャンペーンの途中で一部の端末が更新用データを受信し保持する、通信センターによって端末へ配信された更新用データを受信する方法であり、この方法は、端末の実際の更新に続いて、動作の適切な実行を表わす信号を受信機からセンターへ送信する手順と、端末が更新されていない旨の標識を配信した後に、ポイント・ツー・ポイント接続によって、センターからこの端末への更新用データを受信する手順と、を更に有することを特徴とする。
【００１０】
このようにして、端末は、端末のストックの更新の状態をセンターへ勧告し、端末は、ポイント・ツー・ポイント接続によって更新用データを受信可能である。
【００１１】
さらに、本発明は、上記の方法を実現するように設計された通信センター及び受信機端末を対象とする。
【００１２】
本発明のその他の特徴及び効果は、本発明の具体的な非限定的な例示のための実施例の説明によって明らかになるであろう。
【００１３】
図１には、本発明を実施する通信システムの構成要素が示されている。デコーダ（１−ａ，１−ｂ，１−ｃ）は、たとえば、パラボラアンテナであるアンテナ（３）を用いて映像信号を捕捉する。映像信号は、衛星（４）若しくは無線中継によって伝送される。映像信号は、ケーブル、若しくは、十分なビットレートを備えたその他の通信手段を用いて伝送してもよい。音声−映像信号に含まれる情報は、中央ユニット（６）を具備した通信センター（５）から配信される。音声−映像信号の情報は、テレビ向けの映像と、双方向サービス、テレテキスト、若しくは、デコーダのソフトウェアを更新するためのデータのようなデコーダ向けの情報とを表現する。このような情報の挿入は、特に、当業者に周知の技術である。たとえば、アナログ方式テレビの場合、情報は、映像信号の間で、フレームのフライバック、又は、ＶＢＩの区間にデータパケットの形式で送信される。デコーダは、一般的に、リターンパス、若しくは、ＶＲと称される双方向パスによって、交換電話網（７）に接続される。このパスは、上述のケーブル、若しくは、当業者が利用可能な任意の他の手段、たとえば、ＲＦリンクを用いて具現化してもよい。センター（６）の中央ユニットは、各デコーダに関連した情報を格納するメモリ（８）を含む。
【００１４】
図２には、本発明によるデコーダ（１）の構造の一例が示されている。デコーダ（１）は、中央ユニット（２０）を含む。中央ユニット（２０）は、たとえば、マイクロプロセッサ若しくは専用回路であり、内部通信バス（２１）によって他の構成要素に接続される。バスに接続された主要な構成要素は、特に、電源投入時に実行されるプログラムを格納するプログラム読み出し専用メモリ（２２）と、ＲＡＭタイプの作業用メモリ（２３）と、データ（たとえば、ダウンロードされた画面ページ）及び／又は実行可能なコード（たとえば、更新用データ）を収容するプログラマブル不揮発性メモリ（２４）と、テレビと通信するためのＳＣＡＲＴソケット（２５）のようなコネクタと、アンテナ（３）によって受信された信号を取得し、処理する単方向通信インタフェース（２６）と、（典型的に、電話網に接続されたモデムである）双方向通信インタフェース（２７）と、公知の方法でリモートコントローラから信号を受信する赤外線受信機（２８）と、である。デコーダは、網からダウンロードされたデータによって更新可能なクロック（２９）を含む。本発明の他の実施例によれば、デコーダは、テレビと一体化され、チューナー、及び／又は、リモートコントローラを伴う赤外線受信機（２９）のようなある種の既設モジュールを使用することが可能である。
【００１５】
多数の製造者から入手されるデコーダは、ハードウェア構成及びソフトウェア構成は様々であり、能力に差がある。そのため、デコーダは、二つのフィールドからなる識別子によって識別される。識別子は、たとえば、ＲＯＭタイプの書き込み禁止メモリに収容される。第１フィールドは、デコーダの製造元の識別情報を含み、第２フィールドは、デコーダのタイプを収容する。これらの二つのフィールドは、デコーダのプログラム読み出し専用メモリに設けられる。
【００１６】
放送網を介して配信された更新用データは、特定モデルのデコーダへ向けて送られる。なぜならば、更新用データは、デコーダ識別子、又は、デコーダのモデルの識別子と関連しているからである。放送網を介して配信された更新用データの取得を実行する前に、デコーダは、その更新用データの宛先であるかどうかを予め検証する必要がある。このため、デコーダは、デコーダ自体のバージョン識別子及び製造元識別子が、更新用データに設けられたバージョン識別子及び製造元識別子と一致するかどうか（或いは、少なくとも互換性があるかどうか）を検査する必要がある。識別子は、チップカードのような可搬型媒体に格納することも可能である。この識別子は、加入者番号を含む場合もある。
【００１７】
デコーダに新しい更新用データの送信を勧告するため、通信システムは、最初に、告知信号を配信し、次に、更新用データを配信する。告知信号を正しく受信したデコーダだけがデコーダ自体を更新することができる。
【００１８】
告知信号の一例は、図３に示されている。告知信号は、少なくとも以下のデータブロックにより構成される。
データブロックＴＡ：デコーダ、若しくは、目標デコーダのモデルの識別子。
データブロックＶ３：本例では、バージョン番号を含むデータの識別子。
データブロックＴＤ１_Ａ，ＴＦ１_Ａ：本例の場合、少なくとも一つのデータ配信時間区間、若しくは、一つ以上の配信時点。
データブロックＲＺ３：本例では、更新用データを正確に指定する情報。
データブロックＯＮ：本例では、放送網上のキャンペーンの状態の標識であり、値”ＯＮ”をとる。
【００１９】
データの位置を正確に指定する情報は、デコーダに更新用データの位置を見つけさせることができる手段を特定する。この手段が放送網である場合、告知信号は、チャネル番号が後に続けられたシンボル”ＲＺ”を含む。この手段は電話網でもよく、その場合、告知信号は、シンボル”ＴＥＬ”と、その後に続く１０桁の電話番号とを含む。この手段は、インターネットのようなネットワークでもよく、その場合、告知信号は、シンボル”ＩＰ”と、その後に続く、サーバーのアドレスに対応した文字列とを指定する。たとえば、更新用データが遠隔サーバーから抽出され得る双方向サービスを含む場合、正確に位置を指定する情報は、ＵＲＬ（ユニフォーム・リソース・ロケータ）として知られているデータ項目でも構わない。このデータ項目は、サーバー内でデータが置かれる場所のアドレスである。告知信号は、テキスト、ネットワークへアクセスするための照会先（ＨＴＭＬ）、或いは、双方向サービスでもよい。
【００２０】
配信時間区間は、最初のデータの配信時刻（時分秒）と、最後のデータの配信時刻とによって決められる。最初の告知信号の配信と、最後の更新用データの配信とが、２４時間以上離れている場合、日付（月日）を付加しなければならない。正確に位置を指定する情報が、リターンパスを特定する場合、告知信号に、配信時間区間は含まれない。実際、センターはリターンパスによって何時でも呼び出される。有利的には、センターは、デコーダが一般的にあまり頻繁には使用されない時点に、更新用データの配信時間区間を決定する。そのため、更新用データの配信は夜間に実行することが好ましい。
【００２１】
一変形例では、セッションの配信の時間区間ではなく、各セッションの配信の開始時点を特定する。この変形例は、精密な時点に固定することができるので、デコーダの精細なプログラミングが可能である。これは、特に、配信時点が多数ではない場合に想定される。それ以外の場合、告知信号のサイズが大きくなり過ぎる。
【００２２】
第５フィールドは、放送網上のキャンペーンの状態の標識と呼ばれ、さらに、簡潔にキャンペーン標識と称され、告知されたデータが放送されたかどうか、並びに、告知されたデータは最後の放送であるかどうかがを示すフラグである。センターは、双方向サービスのような予定されていないイベントによって妨げられ、突然、予定されたデータを配信できなくなる場合がある。この標識は、デコーダに、データの放送の停止を通知し、キャンペーンの次の終わりを予め警告することが可能である。この標識は以下の３つの値をとり得る。
値ＳＴＢ（０に符号化）：告知データは放送されなくなる。
値ＯＮ（１に符号化）：告知データは放送される。
値ＥＮＤ（２に符号化）：告知データは最後に放送された告知データである。
【００２３】
標識ＳＴＢを含む告知信号は、配信区間を持つことが可能であり、デコーダは、その間に標識ＯＮを含む告知信号が放送された場合に、指定された区間中にダウンロードするように準備することができる。
【００２４】
告知信号のデータの配信及び更新用データの配信は、時間順と使用される伝送手段とに応じて、４通りのシナリオに従って実行され得る。
【００２５】
第１シナリオ：告知信号及び更新用データは、放送網の同じチャネルで配信される。更新は、直ちに実行してもよく、或いは、後で実行してもよい。
【００２６】
第２シナリオ：告知信号は、幾つかの放送チャネルで配信され、更新用データは単一チャネルで配信される。更新は、直ちに実行してもよく、或いは、後で実行してもよい。
【００２７】
第３シナリオ：告知信号は、一つ以上の放送チャネルで配信され、更新用データはリターンパスで配信される。これは、たとえば、デコーダがユーザによって常に呼び出されるとき、又は、プラグを抜かれているときに行われる。デコーダは、放送網を介して、更新用データをダウンロードし得ない。デコーダは、センターと接続されている機会に、告知信号を受信した後に、リターンパス用いるデータのダウンロードを要求する。
【００２８】
第４シナリオ：告知信号及び更新用データは、リターンパスで配信される。これは、たとえば、通信センターが、放送網上で帯域を告知信号に割り付けないという決定をした場合に行われる。そこで、リターンパスを介して通信センターと接続される機会に、通信センターは告知信号を接続されているデコーダへ送信する。
【００２９】
第１シナリオと第２シナリオの場合、大半のデコーダを更新することが可能であり、第３シナリオと第４シナリオは、むしろ少数のデコーダの場合に関係する。次に、４通りのシナリオについて説明する。
【００３０】
図４は、第１シナリオに従って、放送網の指定されたチャネルにセンターによって配信された信号の時間経過の説明図である。全ての告知信号中のキャンペーン標識はＯＮである。
【００３１】
最初に、時間Ｔ１で、キャンペーンは、アクティブ（動作中）である。更新用データは、第１の告知信号に指定された時間区間に含まれる時点Ｍ１、Ｍ２及びＭ３で、放送網に配信される。図４において、告知信号は、細い線で表わされ、データは太い線で表わされている。第１の信号は、時点Ｍ１、Ｍ２及びＭ３における次のデータセッションの配信を指定する。時点Ｍ１で、第１のデータセッションは放送される。セッションは、数本の太い線によって表現され、数個のデータパケットの連続的な配信を表わし、更新用データの全体の１倍以上を表わす（データの循環的な放送）。次に、第２の告知信号が配信され、時点Ｍ２及びＭ３における次のセッションの配信を告知し、以下、同様に続く。告知信号は、全く同一の２個のパケットの間を除く任意の時点で配信することが可能である。
【００３２】
それ以降、告知信号だけが放送され、次の更新用データに対応した時間区間（Ｍ１’、Ｍ２’、Ｍ３’）を指定する。キャンペーンは、カレント（現行）キャンペーンと呼ばれる。第２の時間は、帯域を他のデータストリームへ割り付けることが可能である。続いて、キャンペーンは再度アクティブになる。
【００３３】
図５は、キャンペーンの過程における標識の値の変化の影響を示す図である。配信された第１の告知信号（ＳＧ１）と、その後に続く信号は、キャンペーン標識がＯＮである。キャンペーンは、最初に、カレントであり、次に、アクティブになる（更新用データが放送される）。ある時点で、センターは、他のデータセッションを配信し得なくなるので、センターは、標識がＳＴＢである告知信号（ＳＧ２）を送信する。この時点以降、送信されるべきであった更新用データは、図５において、中抜きの線で示されている。これらの時点では、他の情報が放送される。ＳＧ２の期間中に聴取していなかったある種のデコーダに予め警告するため、同じ標識の値をもつ数個の告知信号が送信される。最後に、告知信号（ＳＧ３）以降で、全ての信号のキャンペーン標識はＯＮである。デコーダは、更新キャンペーンの再開が警告され、指定された時間区間の先頭で、データを受信し始めることが可能である。
【００３４】
次に、デコーダの動作について説明する。デコーダのスイッチがオンにされると、デコーダは、放送チャネルによって受信した信号を絶えず解析する。この解析は、トランスポート・ソフトウェア層によって実行される。この層は、告知信号、更新用データ及びその他のメッセージを検出する。
【００３５】
センターによって配信された告知信号は、データパケットに組み入れられる。デコーダはパケットを受信し、トランスポート層は、上述の５個のデータ項目により構成された告知信号を検出する。トランスポート層は、送信されたデコーダの識別子（製造元の識別情報及びデコーダのタイプ）と、メモリに記憶されているデコーダの識別子とを比較する。識別子が一致しない場合、告知信号は無視される。識別子が一致した場合、デコーダは、実際に、告知信号のデータと、関連した更新用データの宛先である。
【００３６】
この場合、デコーダは、データの識別子を解析し、データの識別子からバージョン番号を抽出し、抽出したバージョン番号を不揮発性メモリに記憶されているバージョン番号と比較する。バージョン番号が同一である場合、デコーダは、既に、このバージョンの更新用データを具備しているので、新たなダウンロードを実施する必要がない。このバージョン番号が一致しない場合、デコーダは、告知信号に含まれている情報を、告知信号領域と称される不揮発性メモリ領域へ書き込む。最新の告知信号のデータは、前に受信された告知信号のデータに上書きされるので、唯一の告知信号だけがメモリに存在する。
【００３７】
デコーダの不揮発性メモリは、少なくとも、図６に示されるような領域を含む。
【００３８】
デコーダの実際の更新は、好ましくは、デコーダの本来の動作に支障を来たすべきではない。そこで、デコーダの更新は、本発明の典型的な実施例では、好ましくは、ユーザがデコーダの双方向機能を使用していないときに行われ、一般的には、デコーダがユーザによって呼び出されていないときに行われる。最も好ましい時点は、通常、夜間である。デコーダの使用が終了するとき、デコーダは、告知信号領域の内容を読む。この領域が空いている場合、最後の更新以降、告知信号は受信されていないので、以下のステップは実行されず、プログラムは、他のタスクを実行することが可能である。
【００３９】
告知信号領域が使用されているとき、デコーダは告知信号のデータを読み出し、指定された時間区間であるかどうかを判定する。このため、デコーダは、現在時刻と、配信開始時刻及び配信終了時刻を比較する。配信終了時刻が過ぎている場合、更新の実行は間に合わない。配信開始時刻が到来していない場合、デコーダは他のタスクを実行可能である。デコーダは、スタンバイモードに移行し、配信開始時刻の少し前の時点に呼び出すようにプログラムすることも可能である。現在時刻が時間区間中である場合、デコーダは、告知信号に指定された手段に従ってデータを受信することが可能である。最初に、告知信号がデータは放送網で入手可能であることを示す場合について説明する。双方向リンクに関連した状況については後述する。
【００４０】
告知信号に指定された時間区間の途中で、デコーダは、単方向通信インタフェース（２６）を介して、指定された放送チャネルの聴取を開始する。略全リソースがダウンロードに用いられ、ユーザ側の選択の幅は著しく削減される。このため、全ての双方向性は禁止され、ある種のモデルでは、映像及び／又は音声も禁止される。デコーダは、読み出した各パケットを解析し、更新用データに対応したパケットを抽出する。次に、デコーダは、受信したデータ識別子を、告知信号領域に保持されているデータ識別子と比較する。両者が一致した場合、データは、実際に告知されたデータである。デコーダは、データの内容を不揮発性プログラマブルメモリへ書き込む。
【００４１】
更新が実行されたとき、デコーダは、不揮発性メモリに収容されたバージョン番号を更新する。この新しい更新番号は、デコーダが同じバージョン番号、すなわち、同じ更新用データによって更新を実行することを防止する。次に、デコーダは、告知領域を零にセットする。これにより、告知領域は、次の電源投入時に空（未使用）であることが宣言される。最後に、デコーダは、更新動作が適切に実行された旨を表わす（更新実行）信号を通信センターへ送信する。この信号は、リターンパスを用いて送信される。更新用データが放送網を介して配信される場合、デコーダは、更新動作の適切な実行を示す信号を送信するためポイント・ツー・ポイント網への接続を直ちに実行するか、又は、その信号を保持し、リターンパスとの次の接続時にその信号を送信することが可能である。
【００４２】
有利的には、この信号は、デコーダの実際の更新時間を含む。これにより、センターは、デコーダが放送網を介して更新処理を行った時点に関する統計量を作成することが可能である。
【００４３】
更新用データは、１回以上、配信され得る。更新用データが数回配信された場合、デコーダが利用可能である時点に更新用データがデコーダに到達する機会は拡大され、更新されるデコーダの台数を最大限にすることが可能になる。
【００４４】
次に、更新キャンペーンの動作の一例を説明する。デコーダＡとデコーダＢの二つのデコーダモデルを想定する。各デコーダモデルは、固有の識別子値をもつ。モデルＡのデコーダのグループは、バージョン番号２（Ｖ２）の更新用データを保有し、モデルＢのデコーダのグループは、バージョン番号５（Ｖ５）の更新用データを保有する。キャンペーンの目的は、二つのグループの更新を実行することであり、デコーダのグループＡはバージョン番号３（Ｖ３）を受信し、グループＢはバージョン番号６（Ｖ６）を受信する。
【００４５】
デコーダの集合は、図７−ａに概略的に示されている。更新キャンペーンは、告知信号の送信によって始まる。図８−ａに示された告知信号は、タイプＡのデコーダに関する第１のデータ部分とタイプＢのデコーダに関する第２のデータ部分とを含む、２組のデータのグループにより構成されたブロックである。したがって、デコーダＡに対応した第１の告知信号と、デコーダＢに対応した第２の告知信号の２個の別々の告知信号を配信することが可能である。図８−ａに示された値は、デコーダＡ向けのバージョン番号３に対応した更新用データが、放送チャネル番号３上で、時間区間［ＴＤ１_Ａ，ＴＦ１_Ａ］中に利用可能であることを表わす。デコーダＢ向けのバージョン番号６に対応した更新用データは、放送チャネル番号５上で、時間区間［ＴＤ１_Ｂ，ＴＦ１_Ｂ］中に利用可能である
この告知信号は、ある特定の回数だけ繰り返される。デコーダＡは、バージョン番号（Ｖ３）と、配信の時間区間［ＴＤ１_Ａ，ＴＦ１_Ａ］と、更新用データにアクセスする手段、すなわち、放送網のチャネル３とをメモリに記録する。デコーダＢは、バージョン番号（Ｖ６）と、配信の時間区間［ＴＤ１_Ｂ，ＴＦ１_Ｂ］と、更新用データにアクセスする手段、すなわち、放送網のチャネル５とをメモリに記録する。デコーダＡは第１の配信時刻ＴＤ１_Ａを待ち、デコーダＢは第１の配信時刻ＴＤ１_Ｂを待つ。
【００４６】
デコーダが、中央ユニットを呼び出すことができるクロックを具備しない場合、デコーダは、放送網を監視し、更新用メッセージの到着を注意して捜すことができる。この期間中、デコーダの中の使用されない部分（たとえば、ディスプレイ）は、低電力消費モードになる。そうではない場合、デコーダは、告知信号によって指定された時間区間の少し前に呼び出しをトリガーするようにクロックをプログラムすることができるので、デコーダ全体がスタンバイモードに移行する。告知信号が、時間区間ではなく、配信の時点を含む場合、デコーダは、好ましくは、時間順の中で最初の時点を選択する。
【００４７】
更新用データは、繰り返しの多いセッション中に送信される。一例として、デコーダＡ向けのデータは、時点Ｍ_Ａ１、Ｍ_Ａ２及びＭ_Ａ３の３回に亘って配信され、デコーダＢ向けのデータは、時点Ｍ_Ｂ１、Ｍ_Ｂ２、Ｍ_Ｂ３及びＭ_Ｂ４の４回に亘って配信される。端末Ａと端末Ｂに対する信号は、交互に配信しない方が好ましい。なぜならば、後述のように、ＶＲを用いたセンターとの接続は、デコーダの適切な更新処理を示すために要求されるからである。端末Ａに対する配信と端末Ｂに対する配信が交互になされる場合、デコーダＡ及びデコーダＢは、かなり素早く更新処理を行い、ＶＲによる接続を要求する。これは、センターのレベルで通信の負荷が過剰になる危険性がある。したがって、端末Ｂに対するキャンペーンを開始する前に、端末Ａの最大台数を更新する方が望ましい。
【００４８】
デコーダＡ向けの１回目のデータの配信後（本例では、時点Ｍ_Ａ１の後）、デコーダの状態が図７−ｂに示されるような状態であるとする。半数よりも僅かに少ない台数のデコーダが更新されている。時点Ｍ_Ａ２におけるデータの配信後、新しいバージョン（Ｖ３）のデコーダＡの台数が旧いバージョン（Ｖ２）のデコーダＡの台数を上回る。このデコーダの状態は図７−ｃに示されている。最後の更新用データを配信するよりも前の時刻に、センターは、標識の値がＥＮＤである告知信号を配信する。これにより、デコーダは、最後の更新用データが配信されることを通知される。各デコーダは、テレビ画面上、デコーダのディスプレイ上、或いは、その他の表示手段上へのメッセージを用いて、この事実をユーザへ通知する。ユーザは、デコーダが放送網を用いて更新処理を実行できるように、デコーダの使用を中止ことを選択可能である。デコーダＡ向けの最後のデータの配信後、非常に僅かな台数のデコーダが更新されていないままの状態で残される。このときのデコーダの状態は図７−ｄに示されている。
【００４９】
データＢの１回目の配信後（本例では、時点Ｍ_Ｂ１の後）、デコーダの状態が図７−ｅに示されている。デコーダＢ向けのデータの最後の配信後（本例の場合、時点Ｍ_Ｂ４の後）、図７−ｆに示されるように、ある台数のデコーダは更新されていない状態のまま残される。
【００５０】
既に説明したように、更新処理が正確に実行された後、各デコーダは、動作の適切な実行を示す信号を通信センターへ送信する。この信号は、リターンパスによって送信される。通信センターは、これらの信号を保持し処理する。通信センターは、応答がない場合に、旧いバージョン及び新しいバージョンを装備したデコーダの台数を近似的に判定する。
【００５１】
通信センターは、実施されたキャンペーンの有効性を分析し、依然として更新する必要があるデコーダの台数を判定する。デコーダＡの場合に、更新すべきデコーダの台数は少ないので、これらの更新は、センターによって発生させられた通信中、若しくは、ユーザによって後で発生させられた通信中にリターンパスを用いて行われる。デコーダＢの場合に、更新すべきデコーダの台数は非常に多数であるため、リターンパスを用いて個別に更新することは不可能であり、センターは、放送網による新たな更新キャンペーンを実施することを決定する。この新たな更新キャンペーンは、図８−ｂに示されるようなデータにより構成されたえ告知信号の送信によって始まる。新しい時間区間［ＴＤ２_Ｂ，ＴＦ２_Ｂ］中に、デコーダＢ向けの更新用データは放送網で入手可能である。
【００５２】
新たな更新キャンペーンの最後で、更新する必要があるデコーダの台数は少数であり、これらの少数のデコーダは、リターンパスによって更新することが可能である。センターは、図８−ｃに示された更新信号を送信し、放送網上のデータの配信の終了を報せる。まだ更新されていない（未更新）端末は、リターンパスを用いて接続する。
【００５３】
リターンパスによるデータのダウンロードは第３シナリオの中で説明する。
【００５４】
一変形例として、キャンペーン中に、通信センターが、非常に多数のデコーダが更新され、残りのデコーダはリターンパスによって更新されるという認識をした場合、更新用データの配信の終了を早める旨の信号が、最初に予定していた配信終了時刻の前に送信される。この信号は、固有のフォーマットであるか、又は、告知信号のフォーマットをとる。この場合、この告知信号の時間区間は、前の告知信号の時間区間よりも短くなり、最初に予定していた残りの更新は除外される。この変形例によれば、少ない台数のデコーダに対して、放送網を用いてデータを送信する必要が回避される。
【００５５】
有利的には、告知信号の配信と更新用データの配信は併存する。たとえば、放送網上で、告知信号の配信と、更新用データセッションの配信を交互に行うことが可能である。受信の問題（たとえば、データの欠陥）は別として、告知信号だけを送信し、その直後に、データセッションだけを放送することが可能である。実際上、告知信号を継続的に放送することによって、最大限の台数のデコーダが次のデータの配信を事前に知らされることが保証される。図４からわかるように、告知信号は、セッションの配信の時点Ｍ１、Ｍ２、Ｍ３の間で配信される。告知信号を、更新用データの配信の間に挿入し、告知信号の直後に更新用データを配信することにより、告知信号に示された最初の時点の直後から利用可能なデコーダを更新できる効果が得られる。
【００５６】
他の実施例は、数個の告知信号をメモリに格納する。時間区間の期限が経過した告知信号、又は、全ての配信時点が経過した告知信号は、自動的に消去される。現時点以降の配信時点をもつ告知信号だけが考慮される。
【００５７】
第１シナリオは、告知信号を数個の放送チャネルで配信することによって改良される。これが第２シナリオである。第２シナリオは、最大限の台数のデコーダに対し、更新用データが特定チャネルで配信されることを勧告できる。なぜならば、帯域幅を少ししか必要としない告知信号は、告知信号が配信されるチャネルの性能を殆ど劣化させないからである。たとえば、図９に示された告知信号は、チャネル１、２及び５で全く同じように配信される。この告知信号は、バージョン３の更新用データが時間区間［ＴＤ１_ｉ，ＴＦ１_ｉ］にチャネル４で入手可能であることを指定する。
【００５８】
チャネル１、２及び５を受信するデコーダＴｉは、この告知信号を処理する。デコーダＴｉがバージョン３を必要とするとき、デコーダＴｉは、時点ＴＤ１_ｉと時点ＴＦ１_ｉの間にチャネル番号４を監視し、データを獲得する。チャネルの変更は、デコーダがユーザによって使用されていない場合、自動的に行われる。そうではない場合、時点Ｍ１で、デコーダは、ユーザに対し、チャネルの変更を行うことにより、ダウロードを勧める。ユーザは、ダウンロードを承認しても拒否しても構わない。ダウンロードが拒否された場合、デコーダは、時点Ｍ２で再度、ダウンロードを提案する。
【００５９】
一変形例によれば、キャンペーンの終わりではない場合（キャンペーン標識の値がＥＮＤではない場合）、デコーダは、ユーザに不便をかけることなく、ユーザがデコーダの使用を中断するまで待ち受けた後に、ダウンロードを始める。ダウンロードをするかどうかは、デコーダだけによって決定され、ユーザはそのことに気付かない。これに対し、告知信号がキャンペーンの終了を示す場合、たとえば、もしダウンロードを実行しなければ、更新処理はリターンパスを用いて実行しなければならない、という旨をユーザに報せることによって、ダウンロードがユーザに対し提示される。
【００６０】
第１シナリオの場合と同様に、ダウンロードの最後に、デコーダは、動作が適切に実行された旨を示す信号を送出する。
【００６１】
デコーダは、ユーザによって常時呼び出されるか、又は、電源が投入されていない場合がある。このような場合には、デコーダは、放送網を介して配信されたデータをダウンロードし得ない。第３シナリオは、リターンパスによるダウンロードを実施させる。したがって、デコーダは、リターンパスによるセンターとの接続を利用する。たとえば、ユーザによって要求された双方向サービスの実行のために確立されたこのリターンパスによる接続中に、デコーダは、更新用データの送信を要求する信号を送出する。
【００６２】
図１０は、第３シナリオに従ってセンターとデコーダとの間で交換される信号の時間経過を示す図である。最初に、時間Ｔ１で、更新用データは放送網で利用可能である。一部のデコーダは、この時間の終了時までに更新処理を行うことができない。次に、時間Ｔ２の間に、更新用データの配信は放送網で中断され、告知信号はデータが双方向リターンパスを介して入手可能であることを示す。時間Ｔ３の先頭で、デコーダはセンターへ接続する。デコーダは、更新用データのダウンロードだけのためにセンターへ接続しても構わないが、ユーザ主導で、双方向サービスを要求するためにセンターへ接続し、最後にダウンロードを要求しても構わない。どちらの場合でも、接続中に、デコーダは、更新を依頼する要求を送出する。これに対し、センターは更新用データを送信する。ダウンロードの最後に、適切な実行を示す信号がデコーダによって送信され、センターに更新を報告する。
【００６３】
更新用データ及び告知信号よりも優先度の高い他の信号によって帯域が非常に輻輳し、このタイプの情報に割り付ける帯域が残されていない場合がある。また、デコーダが告知信号を放送するチャネルに接続されず、接続されたときに、更新が必要であることを認識する場合もある。この場合、デコーダは、センターに対し、双方向パスを用いて告知信号を送信するように依頼する。本発明の拡張型である第４シナリオによれば、デコーダは、告知信号と更新用信号の両方を配信するためリターンパスを使用する。
【００６４】
図１１は、第４シナリオに従ってセンターとデコーダの間で交換される信号の時間経過を示す図である。ユーザ主導で、デコーダは、たとえば、双方向サービスを要求すべく通信センターへ接続する。センターは、告知信号と、要求されたサービスを送信することによって返答する。デコーダは、告知信号の送信を認識し、更新する必要があるかどうかを検査する。更新する必要がある場合、デコーダは、ユーザに対し更新処理が進行する旨を予め報せる。ユーザは、更新を承認してもよく、或いは、双方向サービスが終了するまで更新を延期してもよい。デコーダが更新用データの受信準備を完了したとき、デコーダは、センターへ要求を送信する。センターは、更新用データを配信する。更新用データが受信され、正確にメモリへ書き込まれたとき、デコーダは、動作の適切な実行を通知し、切断する。センターは、当該デコーダが新バージョンのデータを用いて更新された直後であることを指摘することによってセンターのメモリを更新する。
【００６５】
第４シナリオの利点は、更新されるべきデコーダが完全に目標とされることである。特に、既に説明した通り、センターは、動作の適切な実行を示す信号が送信されない場合、各デコーダのメモリに収容されているデータのバージョンを推測する。リターンパスによる接続の機会に、センターは、当該デコーダが新バージョンのデータを必要とするかどうかを照合する。デコーダが新バージョンを必要とするとき、センターは、デコーダに対し更新処理を勧告する告知信号を配信する。デコーダは、配信されたバージョン番号と、メモリ内のバージョン番号とを比較する。とくに、センターが適切な実行を示す信号を受信せずに、誤って更新処理を勧告する場合がある。デコーダが更新処理を必要としないとき、デコーダは、その旨をセンターへ報せ、センターはメモリを更新する。デコーダが更新処理を必要とするとき、デコーダは、センターに対し、上述のシナリオを実行するように依頼する。
【００６６】
本発明の改良型は第５シナリオに示されている。第５シナリオは、ユーザによって頻繁に呼び出され、告知信号の取得を実行する可能性がないデコーダに関する。この場合、デコーダの主導によるセンターとの接続の機会に、センターは、更新用データが放送網に現在放送されている旨を報せる告知信号を送信する。デコーダは、配信が通知され、ユーザにデコーダを更新可能である旨を報せる。ユーザは、更新動作の時間中、デコーダの使用を中断する。
【００６７】
第５シナリオの一変形例では、ネットワーク上に放送されたデータは、復号鍵を持たない人が音声−映像情報を利用できないようにさせる暗号化成分を含む。復号鍵を保有するデコーダは、更新用データを復号化（解読）し、更新用データが利用できるようにする。復号鍵は、特定のコネクションを介して各デコーダへ個別に送信される告知信号に組み込んでもよい。ユーザは、たとえば、料金を支払うことによって、予めこの復号鍵を受け取る権利を取得しておく必要がある。
【００６８】
一変形例によれば、メモリへダウンロードされたデータの欠陥が考慮される。データに欠陥がある場合、データは使用できなくなり、新しいデータをダウンロードしなければならない。これは、バックアップ再更新である。問題が生じたデコーダは、放送網を介して配信された情報を解析し、このデコーダのモデルに対応した告知信号を受信する。このようにして、デコーダは、必要なソフトウェアバージョンと、そのソフトウェアバージョンを取得する手段と、ダウンロードを実行可能な時点とを判定することができる。キャンペーンがアクティブ状態であるとき、デコーダは、直ちにデータをダウンロードすることが可能である。キャンペーンがカレント状態であるとき、デコーダは、第３シナリオの場合と同様に、センターとの接続を確立し、リターンパスを介して更新用データをダウンロードする。バックアップ更新を始動する要因は、ユーザ側の設備に、空白のメモリを保有する新しいデコーダが収容されたときである。
【００６９】
この変形例によれば、告知信号は、図１２に示されるような補助フィールドを含む。補助フィールドは、双方向リンクを介してデータをダウンロードすることが可能である手段（電話網、インターネットのようなネットワークのアドレスなど）を指定する。図１２に示された例示的な告知信号に従うデータは、放送網（チャネルＲＺ３）によって配信され、バックアップの場合には、デコーダは、このデータを受信するため、ＴＥＬによって表わされた番号へ接続することができる。
【００７０】
本発明の一改良例では、有効日付及び／又は有効期限日付が告知信号に組み入れられる。有効日付は、ユーザが指定された日付以降にダウンロードされたデータへアクセスすることを許可することができる。有効期限日付は、ダウンロードされたデータへのユーザのアクセス権を削除することが可能である。ダウンロードされたデータは、このようしてメモリから消去され、これにより、メモリの一部の空間を開放する。有利的には、デコーダが既に有効期限日付を経過した有効信号を受信したとき、デコーダは、この告知信号を無視する。一変形例によれば、数個の告知信号の中の１個以上の要素が同一である場合、これらの告知信号を、ヘッダ付きのテーブルに一つのグループとしてまとめることが可能である。このヘッダは、テーブル中の全ての告知信号に共通の値を収容する。図１３は、１、２及び３の番号が付けられた３組のデータグループの配信に対応した３個の告知信号により構成されたテーブルを示す図である。正確に位置を特定するピンポイント情報（ＲＺ３）及び有効日付（ＤＡＴＥ−Ｖ）は、３組のデータグループに対して同一であり、ヘッダに一括してまとめられる。有効期限日付（ＤＡＴＡ−Ｆ１、ＤＡＴＡ−Ｆ２、ＤＡＴＡ−Ｆ３）のような異なる値は、各告知信号に残される。
【００７１】
本発明は、アナログ方式テレビの分野、並びに、デジタル方式テレビの分野に同様に適用されることに注意する必要がある。
【図面の簡単な説明】
【図１】 本発明による通信システムの略構成図である。
【図２】 本発明を実施するテレビ・デコーダの構成図である。
【図３】 本発明の好ましい一態様による告知信号のデータの説明図である。
【図４】 本発明の第１実施例によるセンターによって配信された信号の時間経過の説明図である。
【図５】 配信を停止する標識を使用してセンターによって配信された信号の時間経過の説明図である。
【図６】 本発明によるデコーダのプログラマブル不揮発性メモリの内容の一部の説明図である。
【図７】 更新キャンペーン中に２組のデコーダのグループのバージョンが変化する様子を説明する図である。
【図８】 ２組のデコーダのグループに対し、更新キャンペーン中に告知信号の内容が変化する様子を説明する図である。
【図９】 本発明の一変形による告知信号のデータの説明図である。
【図１０】 本発明の第２実施例によるセンターとデコーダとの間で交換される信号を時間順に表わす図である。
【図１１】 本発明の第４実施例によるセンターとデコーダとの間で交換される信号を時間順に表わす図である。
【図１２】 本発明の一変形による告知信号のデータの説明図である。
【図１３】 本発明の一変形による数個の告知信号を含むテーブルの説明図である。

Claims (8)

1. 通信ユニットからメモリ手段を有する複数の端末へ更新用データを送信する送信方法であって、
   更新用データを前記通信ユニットが指定した時間に配信することを示す少なくとも１つの告知信号を生成し、
   更新キャンペーンの間に前記通信ユニットが、前記更新キャンペーンの終了を示す告知信号に至るまで告知信号を送信し、
   少なくとも１つの前記告知信号を受信し、ユーザの端末を更新するダウンロードを承認するか又は拒否するかをユーザに問い合わせるメッセージを、該告知信号に含まれている指定された前記時間において端末により表示し、
   前記通信ユニットが前記更新用データを通信チャネルで送信し、
   前記ユーザが前記ダウンロードを承認した場合、前記通信チャネルで受信した前記更新用データを前記メモリ手段に保存することで、該ユーザの端末を更新する手順
   を有する送信方法。
2. 前記通信ユニット及び少なくとも複数の端末の間で双方向通信が行われ、各端末は更新の状態を示す標識を前記通信ユニットに送信し、
   前記通信ユニットが、実際に更新された端末の台数を判定し、
   更新された端末の台数に応じて、新しい更新キャンペーンを中断又は始動し、
   未更新の端末が、ポイント・ツー・ポイントリンクを用いて前記通信ユニットから前記更新用データをダウンロードし、前記更新用データを受信する、請求項１記載の送信方法。
3. 双方向通信が、更新キャンペーン以外のときに端末の主導で行われ、該端末は前記通信ユニットからの要求の際に未更新の標識を送信する、請求項１記載の送信方法。
4. 前記更新用データは端末のタイプに依存し、
   前記通信ユニットが判定する端末の台数は、各端末のタイプに応じて判定される、請求項１記載の送信方法。
5. 前記更新用データは端末の製造元に依存し、
   前記通信ユニットが判定する端末の台数は、各端末の製造元に応じて判定される、請求項１記載の送信方法。
6. 通信ユニットから送信された更新用データを受け取るメモリを備えた端末であって、
   前記更新用データを更新キャンペーンの間に前記通信ユニットが指定した時間に配信することを示す少なくとも１つの告知信号を受信する受信手段を有し、該受信手段が受信した前記告知信号に含まれている指定された時間において、当該端末は、ユーザの端末を更新するダウンロードをユーザが承認するか又は拒否するかを当該端末のユーザに問い合わせるメッセージを表示手段が表示することを促し、当該端末は、前記ユーザからの応答を受信する入力手段を有し、前記ユーザが承認した場合、更新用データを受信するために受信モードを始動し、当該端末は、受信した更新用データを書き込むためのメモリを有する、端末。
7. 前記更新用データを保存した後に前記通信ユニットと双方向通信する手段をさらに有し、更新の状態に関する信号を前記通信ユニットに送信し、前記双方向通信する手段は、当該端末が更新されていなかった場合、前記通信ユニットが発した更新用データを受信する、請求項６記載の端末。
8. 前記メモリは端末のタイプの値を含み、
   前記双方向通信する手段は、更新用データを記憶した後に、該値を送信する、請求項６又は７記載の端末。

Images