"ネットワークにアクセスを提供するために受信機/デコーダとリモートサーバの間の通信を認証する方法であって、当該方法が通信を認証するために、前記受信機/デコーダの識別子を使用することを含み、該識別子は放送サービスへのアクセス用の識別子に基づく、前記方法。好ましい実施形態では、ログイン詳細は、以下の形式を取り、ログイン={スマートカード番号}{サービスの種別}その場合、サービスの種別TOSは、データ通信がその上で発生することになるチャネル、例えば応答のカテゴリが衛星によって端末に送信されなければならないケースを指定してよい。好ましい実施形態では、リモートサーバは、受信機/デコーダに、ネットワークプロトコルを有するネットワークへのアクセスを提供し、受信機/デコーダから出力されるデータは、受信機/デコーダから遠い場所でネットワークプロトコルに準拠するデータに変換される。このようにして、ネットワークプロトコルを備えていない受信機/デコーダも、依然としてネットワークと通信してよい。ネットワークは、例えば、インターネットでよく、ネットワークプロトコルは、例えば、トランスポート制御プロトコル/インターネットプロトコルTCP/IPであってよい。該遠い場所とは、例えば、インターネットアカウント管理システムを備えてよいオペレータであってよい。好ましくは、データは、受信機/デコーダとリモートサーバ間のゲートウェイによって、ネットワークプロトコルに準拠する前記データに変換される。好ましい実施形態では、ネットワークは、複数のリモートデバイスを備え、前記変換されたデータは、前記データに指定されるように、ゲートウェイによって前記リモートデバイスの内の1つに通信され、それにより受信機/デコーダと指定されたリモートデバイス間に通信チャネルを確立する。第2態様では、本発明は、非インターネットプロトコルイネーブル済みユーザ端末から複数のインターネットプロトコルイネーブル済みリモートデバイスの1つにデータを通信する方法を提供し、該方法は、前記ユーザ端末から前記ゲートウェイへ前記非インターネットプロトコルを使用してデータを通信し、前記データがメッセージを含み、前記複数のリモートデバイスからの前記メッセージの宛先を指定するステップと、前記ゲートウェイで前記データを前記インターネットプロトコルを使用するデータに変換するステップと、前記インターネットプロトコルを使用する前記データを前記ゲートウェイから指定された宛先リモートデバイスに通信し、それによりユーザ端末と指定されたリモートデバイス間に通信チャネルを確立するステップとを備える。ユーザ端末は、受信機/デコーダであってよい。また、提供されているのは、受信機/デコーダとリモートネットワーク間で通信する方法であって、そこではリモートネットワークと通信するために必要なプロトコルは、受信機/デコーダから遠い場所で実現される。通信チャネルの終端を命令するメッセージが、非インターネットプロトコルを使用して、受信機/デコーダからゲートウェイに通信されてよく、ゲートウェイは、代わりに、インターネットプロトコルを使用して指定されたリモートデバイスに終端コマンドを通信する。好ましくは、受信機/デコーダの識別は、通信チャネルが確立する前にゲートウェイによって認証される。第3態様では、本発明は、ネットワークへのアクセスを提供するために受信機/デコーダとリモートサーバ間の通信を認証するための装置を提供し、該装置は、通信を認証するために受信機/デコーダの識別子を使用するための手段例えば、システム、サーバまたはゲートウェイを備え、該識別子は、放送サービスへのアクセスのために識別子に基づいている。識別子は、受信機/デコーダとリモートサーバ間の通信に使用されるデータ経路を特定するデータを伴ってよい。リモートサーバは、ネットワークプロトコルを有するネットワークへのアクセスを、受信機/デコーダに与えてよく、前記装置は、受信機/デコーダから出力されるデータを、ネットワークプロトコルに準拠するデータに変換するための手段例えば、システム、サーバまたはゲートウェイを備える。好ましくは、装置は、受信機/デコーダとリモートサーバの中間のゲートウェイである。好ましくは、ネットワークは複数のリモートデバイスを備え、前記ゲートウェイは、前記データに指定されるように、前記リモートデバイスの1つに変換されたデータを通信するように適応され、それにより、受信機/デコーダと指定されたリモートデバイス間の通信チャネルを確立する。第4態様では、本発明は、非インターネットプロトコルイネーブル済みユーザ端末から受信されるデータを、複数のインターネットプロトコルイネーブル済みリモートデバイスの1つに通信するためのゲートウェイを提供し、該ゲートウェイは、前記ユーザ端末からの前記非インターネットプロトコルを使用して通信されるデータを受信するための手段例えば、入力であって、前記データがメッセージを含み、前記複数のリモートデバイスからの前記メッセージの宛先を指定する手段と、受信されたデータを、前記インターネットプロトコルを使用するデータに変換するための手段例えば、変換器と、前記インターネットプロトコルを使用する前記データを、指定された宛先リモートデバイスに通信し、それによりユーザ端末と指定されたリモートデバイス間に通信チャネルを確立するための手段例えば、出力と、を備える。ゲートウェイは、それぞれのリモートデバイスへの接続のためにそれぞれ複数の入力/出力を備えてよい。ゲートウェイは、通信チャネルの終端を命令するユーザ端末からのメッセージを特定するための手段例えば、識別子、および指定されたリモートデバイスに終端コマンドを送るための手段例えば、出力を備えてよい。本発明は、実質的には添付図面に関して説明されるような、および添付図面の中に示されるような方法および装置も提供する。ある態様の特徴は、他の態様に適用されてよい。同様に、方法特徴は、装置態様に適用されてよく、またその逆にも適用されてよい。本発明の好ましい特徴は、ここでは、純粋に例によって、添付図面に関して記述される。デジタルテレビシステム1の概要は、図1に図示される。本発明は、圧縮済みデジタル信号を伝送するために、既知のMPEG-2圧縮システムを使用する主として従来のデジタルテレビシステム2を含む。さらに詳細には、放送センタ内のMPEG-2圧縮機3がデジタル信号ストリーム典型的には、ビデオ信号のストリームを受信する。圧縮機3は、リンク機構5によってマルチプレクサとスクランブラ4に連結される。マルチプレクサ4は、複数の追加入力信号を受信し、トランスポートストリームをアセンブルし、圧縮済みデジタル信号を、言うまでもなく電気通信リンクを含む幅広い形式を取ることができるリンク機構7を介して、放送センタの送信機6に伝送する。送信機6は、アップリンク8を介して衛星トランスポンダ9に向かって電磁信号を伝送し、そこではそれらは電子的に処理され、概念上のダウンリンク10を介して、従来は、エンドユーザによって所有あるいは賃貸される放物面反射器という形を取る、地上受信機12に一斉送信される。地上放送、ケーブル伝送、結合された衛星/ケーブルリンク、電話網等のデータの伝送用のその他のトランスポートチャネルが、言うまでもなく可能である。受信機12により受信される信号は、エンドユーザによって所有または賃貸される統合型受信機/デコーダ13に伝送され、エンドユーザのテレビセット14に接続される。該受信機/デコーダ13は、圧縮済みMPEG-2信号をテレビセット14用のテレビ信号に復号する。別個の受信機/デコーダが図1に図示されているが、受信機/デコーダもまた、統合型デジタルテレビの一部であってもよい。ここに使用されるように、用語受信機/デコーダは、セットトップボックスなどの別個の受信機/デコーダ、およびそれと統合された受信機/デコーダを有するテレビを含む。マルチチャネルシステムでは、マルチプレクサ4は、数多くの並列ソースから受信される音声およびビデオ情報を処理し、対応する数のチャネルに沿って情報を一斉送信するために送信機6と対話する。視聴覚情報に加えて、メッセージまたはアプリケーション、あるいはそれ以外の種類のデジタルデータが、伝送済みのデジタル音声ビデオ情報とインタフェースされるこれらのチャネルのいくつかまたはすべてに導入されてよい。従来のアクセスシステム15は、マルチプレクサ4および受信機/デコーダ13に接続され、部分的には放送センタに位置し、部分的には受信機/デコーダ内に位置する。それは、エンドユーザが、1つまたは複数の放送供給業者からのデジタルテレビ放送にアクセスできるようにする。商業的なオファーすなわち、放送供給業者により販売される1つまたは複数のテレビ番組に関係するメッセージを解読することができるスマートカードを、受信機/デコーダ13に差し込むことができる。受信機/デコーダ13およびスマートカードを使用して、エンドユーザは、加入モードまたは有料視聴モードのどちらかで商業的なオファーを購入してよい。前述したように、システムにより伝送される番組は、マルチプレクサ4でスクランブルされ、条件および暗号化キーが、アクセス制御システム15によって決定される所与の伝送に適用される。このようにしてスクランブルされたデータの伝送は、有料テレビシステムの分野では周知である。典型的には、スクランブルされたデータは、データを逆スクランブルするための制御ワードとともに伝送され、制御ワード自体がいわゆる探索キーによって暗号化され、暗号化された形式で伝送される。それから、スクランブルされたデータおよび暗号化された制御ワードは、暗号化された制御ワードを解読し、その後で伝送されたデータを逆スクランブルするために、受信機/デコーダに挿入されたスマートカードに記憶される探索キーに同等なものにアクセスできる受信機/デコーダ13によって受信される。支払済みの加入者は、例えば、放送月次EMM資格管理メッセージの中で、伝送の表示を可能にするために暗号化された制御ワードを復号するために必要な探索キーを受信するだろう。やはりマルチプレクサ4および受信機/デコーダ13に接続され、再び、部分的に放送センタ内に位置し、部分的に受信機/デコーダ内に位置する対話型システム16により、エンドユーザは、モデム送受信modemedバックチャネル17を介して多様なアプリケーションと対話できるようになる。モデム送受信バックチャネルは、条件付きアクセスシステム15内で使用される通信にも使用されてよい。受信機/デコーダ13の物理インタフェースは、データをダウンロードするために使用される。図2を参照すると、受信機/デコーダ13は、例えば、6台のダウンロードデバイス、つまり直列インタフェース30、並列インタフェース32、モデム34、2台のカード読取り装置36、およびMPEGフローチューナ38を含む。放送受信システムも、ウェブブラウジングおよびeメールなどのインターネットサービスを提供するために使用される。受信機/デコーダ13によって実行されるアプリケーションは、受信機/デコーダが、インターネットサービスにアクセスし、ウェブページおよびeメールを、テレビセット14上でまたは受信機/デコーダ13に接続されるコンピュータを介して表示できるようにする。図3を参照して、インターネットアクセスシステムの概要を説明する。受信機/デコーダを含むユーザ装置20は、公衆加入電話網PSTN24を介してオペレータ22と通信する。ユーザ装置は、オペレータ22に対し、例えば、ある特定のウェブページまたはeメールなどの一定のデータを送信されるようにという要求を送信する。オペレータはこの要求を受信し、要求をインターネットサービスプロバイダISP26に出力する。この要求に応えて、ISPは、インターネット27から得られた要求されたウェブページ、またはISPで加入者を待機していたeメールを備える可能性がある応答をオペレータに供給する。オペレータは、応答を、それが、例えば私用セクションとしてMPEGビットストリームに統合され、前述されたように送信機6によって伝送され、受信機12によって受信される放送センタ28に送達する。受信機/デコーダがIPイネーブルされている場合、つまりデータをインターネットから受信するためのプロトコルを備えている場合、情報はMPEGビットストリーム内で、つまりIPフォーマットでIPフレームとして伝送されてよい。受信機/デコーダがIPイネーブルされていない場合には、データは、例えば私用MPEGセクションとして、なんらかの他の方法で送信される。ユーザ装置20は、MPEGビットストリームから応答を抽出し、それをテレビセットまたはコンピュータ画面上で表示する。代わりに、応答は、PSTN24を介してユーザ装置20に伝送されてよい。ユーザ装置20で利用されるソフトウェアレベルは、図4に図示される。アプリケーションレベルは、NetscapeまたはMicrosoftInternetExplorerおよびOutlookExpressなどの商業的なアプリケーション、または受信機/デコーダで実行するように特に設計されるアプリケーションであってよい、ウェブブラウザおよびeメールアプリケーションを備える。アプリケーションレベルの下には、HTTP、ソケット、TCP/IP、PPP/SLIP、およびドライバレベルがある。ドライバレベルは、PC上で従来動作しているブラウザアプリケーションと比較して、それがユーザ装置のモデムを介してPSTN24と通信するためのモデムドライバ、およびMPEGフローチューナ4028を介して通信するためのチューナドライバに分割されるという点で修正される。ユーザ装置20の多様な構成が考えられる。ある構成では、PCは使用されず、ユーザソフトウェアのすべては受信機/デコーダ13上で実行する。この構成では、受信機/デコーダ13は、内蔵モデムを介して、または外部モデムおよびシリアルポートを介してのどちらかでPSTN24と通信する。受信機/デコーダ13は、地上受信機12からビットストリーム内のインターネット応答を受信できる。ユーザインタフェースは、遠隔制御装置またはキーボードおよび受信機/デコーダ13に接続されているテレビセットによって提供される。この構成では、図4に示されるTCP/IPレベルは省略されてよく、その場合、オペレータに位置するゲートウェイが、後述されるように必要なプロトコルを提供する。別の構成では、その並列ポートによって受信機/デコーダ13の並列ポート32にあるいは任意にその直列ポートによって受信機/デコーダ13の直列ポート30に接続されるパーソナルコンピュータPCが提供される。この場合、図4に図示されるソフトウェアレベルの上部は、PC上で実行し、ソフトウェアレベルの残りの下部は受信機/デコーダ13上で実行する。ユーザインタフェースは、キーボードおよびPCに接続されるモニタによって提供される。追加の構成では、PCはPCの内蔵モデムまたは外付けモデムを介してPSTN24に接続される。この構成では、受信機/デコーダ13は、別個に、またはそのISAまたはPCIバスに接続される、PCの付属またはプラグイン式のカードの形を取り、提供されてよい。インターネットアクセスシステムのアーキテクチャは、図5に示されている。図5を参照すると、インターネットアカウント管理システムIAMS50は、ウェブブラウジングおよびeメールなどのサービスを提供するインターネットサービスプロバイダISP26にリンクされる。IAMS50は、加入者を管理し、インターネットサービスへのアクセスを許可または拒絶するためにIAMSに要求を送信する加入者管理システムSMS60にもリンクされる。受信機/デコーダ113は、内蔵モデム、公衆加入電話網PSTN24、ネットワークアクセスサーバNAS56、およびゲートウェイ58を介してIAMSに接続される。SMSは、放送テレビサービスなどの許可および放送サービスに対する加入者の注文を管理する加入許可システムSAS61にも接続される。SMSは、並列でSASシステムおよびIAMSシステムを実行し、2つのシステム間の整合性を確実にする。SMSとSASとIAMSとの間の通信は、バッチファイルを使用するリアルタイムTCP/IPリンクを使用して発生する。ゲートウェイ58により、加入者は、リアルタイムでインターネットサービスにアクセスできる。このようなサービスは、メールを送受するためのメールサービス、およびISP26によって提供されてよいそれ以外のサービス、ならびにIAMSによって提供される対応provisioningサービスおよびリマインダサービスを含む。機能上、ゲートウェイ58は、単一モデム接続で多様な異なるシステムとの通信をイネーブルするメッセージルータである。受信機/デコーダにISPと通信するためのTCP/IPプロトコルが備えられていない場合、ゲートウェイは、受信機/デコーダがISPと通信するために必要なプロトコルも提供する。それから、受信機/デコーダ13は、図5の線59で示されるように、ゲートウェイ58を介してISPと通信する。受信機/デコーダに必要なプロトコルが備えられている場合、通信は、図5の破線57で示されるように、ISPと直接的に発生することができる。ゲートウェイは通信サーバおよびeメールディスパッチャを備える。ISPインタフェース66は、IAMS内で発生するユーザのアカウントに関係する各修正を、メールサービスなどのホストインターネットサービスを担当するISP26内のユーザアカウントに複製できるようにする。加入者アカウントに関係するすべての情報はIAMS内に集中化され、TVおよびインターネットパラメータの管理を確実にすることに注記する必要がある。IAMSは、加入者管理システムSMS60とのそのインタフェースを通して、インターネットパラメータとTVパラメータ間の関係性も管理する。SMS60は加入者を管理し、加入者によるインターネットサービスへのアクセスを許可または拒絶するためにIAMSに要求を送信する。IAMSアカウントをセットアップするために、加入者は、最初に、受信機/デコーダ13からIAMS50に、要求されたeメールアドレスおよび選択されたオプションなどの情報とともに、新規アカウントに対する要求を送信する。IAMSは、それがインターネットアカウントをセットアップしてよい加入者に対応して、加入者管理者システムSMS60から得られるスマートカード番号のリストに付き合わせて加入者のスマートカードをチェックする。それから、IAMSは、インターネットアカウントをセットアップするためにISPに要求を送信する。いったんアカウントがセットアップされると、ISPは、パスワードとともにIAMSに肯定応答を戻す。パスワードは、当初、SMSによって定められるが、後に加入者によって修正されてよい。IAMSアカウント情報パスワード,eメールアドレス、およびインターネットパラメータが、加入者のスマートカード番号とともに、IAMSに記憶される。IAMSは加入者に、自分のアカウントがセットアップしたことを知らせる。それから、加入者は、メールサーバ28に、およびメールサーバ28からメールを送信、受信することができる。IAMSの主要な構成要素は、図6に示されている。IAMSの主要な機能は、以下の通りである。スマートカード番号などの加入者パラメータにリンクされるeメールアカウントパラメータの集中化したリストの維持。SMSの要求時における、加入者用のインターネットサービスへのアクセスの許可または拒絶。加入者の要求時のインターネットアカウントのカスタマイズ対応。eメールユーザが、イベントを登録し、イベント時にeメールによって警告を受けることができるリマインダサービス。IAMSコンテンツの更新を、ISPなどの関連サーバにコピーできるようにする複製サービス。IAMSに対して中心にあるのは、記憶手段72に記憶されるインターネットサービスおよびeメールアカウント用の加入情報を含む、関連データベース管理システムRDBMS70である。SMS通信インタフェース74により、IAMSは、SMSと通信することができ、その結果IAMSは、メールサービスへのアクセスを許可または拒絶された加入者の詳細で更新されてよい。対応サーバ76は、加入者が、自分のeメールアカウントを管理し、カスタマイズできるようにする。リマインダサービス78によって、加入者は、イベントのリストを管理できる。イベントは、加入者のeメールアカウントに関係する。加入者はイベントを登録し、自動的に作成されるeメールを介してイベントの所定日数前に、自動リマインダを受信してよい。Eメール通知通信インタフェース84によって、EMNS62は、架空通知メッセージを送信するために、IAMSRDBMS70での加入者の通知優先を検索できるようにする。サポートサーバ80は、管理者が、IAMS内の加入者またはeメールユーザの存在およびステータスをチェックできるようにする。複写サービス82は、IAMSRDBMS70のコンテンツの更新をISPアカウント管理システムにコピーする。IAMSに受信機/デコーダ13から送信される要求は、ゲートウェイ58によって、eメールアカウント管理用の対応サーバおよびリマインダイベントを管理するためのリマインダサーバなどのIAMSの適切な部分に向けられる。前述されたインターネットアクセスシステムは、放送サービスプロバイダが、インターネットサービスを提供できるようにもする。システムのオペレータは、インターネットアカウントを、インターネットサービスプロバイダとは無関係に維持し、その結果、オペレータは、ある特定のインターネットプロバイダに関連付けられない。放送サービスへの加入と、インターネットへの加入をともにリンクすることによって、アカウントが別個に管理され、加入者が2つのサービスにともに請求書を作成発行されるケースと比較して、関与する処理の量を削減してよい2つのサービスに対するアカウントが共に管理される。IAMSの追加詳細は、本出願の名称でインターネット加入者管理InternetSubscriberManagementと題され、その主題がここに参照して組み込まれる同時係続出願に記述される。eメール通知システムの更なる詳細は、本発明の名称でEメールと共に使用するための方法および装置MethodandApparatusforusewithE-mailと題され、その主題が参照してここに組み込まれる同時係続出願に記述される。受信機デコーダ13がインターネットイネーブルされていないケースでのインターネットアクセスシステムの構成を、ここで図7から図10に関して説明する。その全体が図5に図示され、一定の態様がさらに詳細に描かれているシステムの一部を示す図7を参照すると、受信機/デコーダ13は、装置にISP26との直接通信に必要なトランスポート制御プロトコル/インターネットプロトコルTCP/IPが備えられていない前述された型のものである。したがって、通信は、DSTBゲートウェイ58を介して起こる。対応サーバ76およびリマインドサーバ78は、IAMS50の別個の部分として図中に示され、実施形態では、データは別個の線路76aと78aを介して適宜にそれぞれに送られる。したがって、実際には、受信機/デコーダ13とアクセスされることが所望される任意のリモートサーバ間の任意の通信で重要な4つのサブシステムがあることが理解されるだろう。これらは、受信機/デコーダ13自体、NAS56、ゲートウェイ58、および実施形態の中では対応サーバ76、リマインドサーバ78、またはメールサーバ64の内のいずれか1つであってよいリモートサーバである。PSTN24は、実際にはデータトランスペアレントである。実施形態では、メールサーバ64は、インタフェース66およびISP26を介してアクセスされるが、これが当てはまる必要はなく、メールサーバ64はゲートウェイ58から直接的にアクセスできるだろう。さらに、図中では単一装置として図示されているが、メールサーバ64は、第1が例えば、SMTPサーバであってよいeメール送信用、および第2が例えば、IMAPサーバであってよいeメール受信用の2つの別個の装置から成り立ってよい。このような構成では、ゲートウェイ58は、2つの別個のポートを介してメールサーバを備える2つの装置と通信してよい。前述された4つのサブシステムの内のそれぞれによって処理される異なるプロトコルレベルが、ここで図8に関連して説明されるだろう。図から分かるように、受信機/デコーダ13は、以下のような4つのプロトコルレベル最高レベルが先を有する:アプリケーション依存であるだろうアプリケーションレベルプロトコル、および例えば、SMTP、IMAP等であってよい;ゲートウェイプロトコルこれは、受信機/デコーダ用に使用されるレベルである―さらに詳しく後述されるようなゲートウェイ通信;v22またはv42bisなどのPP4プロトコルおよびモデム層。これら後者の2つの層の動作は、当業者に周知だろう。NAS56は、単一プロトコル層で機能し、PSTN24全体で通信するために使用されるモデム層をインターネットプロトコルTCP/IPに変換するために効果的である。ゲートウェイ58は、3つの作動できるプロトコル層再び、最高レベルが先、すなわち、ゲートウェイプロトコル層、PP4プロトコル層、およびTCP/IPを有する。最終的に、リモートサーバは、通常、アプリケーションレベルプロトコルでの上位層およびTCP/IPプロトコルでの下位層という2つのプロトコルを有するだろう。したがって、ゲートウェイプロトコルは、ゲートウェイ58が、メッセージに応え、適切な場合には、データの意図された受け取り人を特定し、データをその受け取り人に転送することができるようにする。プロトコルは、受信機/デコーダ13が、多様なゲートウェイ58/リモートサーバ動作も開始できるようにする。実施形態では、ゲートウェイ58は、メールサーバ64にSMTPデータまたはIMAPデータを向けること;データを、新しいアカウントの作成に備える要求を含んでよい対応サーバ76に向けること;データを、イベント登録に対する要求を含んでよいリマインダサーバ78に向けること;メールサーバ64のいずれか1つから受信されるデータに基づいて受信機/デコーダ13に送信されるべきメッセージを構築することを担当し、対応サーバ76またはリマインダサーバ78、およびこのような構築されたメッセージを処理する。さらに、ゲートウェイは、受信機/デコーダ認証機能を実行するための能力を有する。ここでは、受信機/デコーダ13とゲートウェイ58の間の低レベル通信を説明する。第1ステップでは、モデム通信が受信機/エンコーダ13とPSTN24上のNAS56の間に確立される。例えば、v22またはv42bisなどの任意の適切なモデムフォーマットが使用される。この時点で、チャットシーケンスは、通信チャネルを完全に確立するために、受信機/デコーダ13とNAS56の間のモデムレベルで発生する。それ以降、NAS56は、TCPプロトコルレベルで、ゲートウェイ58との接続チャネルを確立する。このイベントに続いて、ゲートウェイ58によってトークンが受信機/デコーダ13に送信され、このトークンは事前に指定された文字シーケンスである。このようなトークンの受信機チャネルによる受信は、それに、ゲートウェイ58の存在およびゲートウェイプロトコルレベルでの受信機/デコーダ13とゲートウェイ58間の通信チャネルが、それによって確立されることを知らせる。確立されたゲートウェイプロトコル通信チャネルは、実際には、受信機/デコーダ13の支配下にある。メッセージ交換が発生する前にチャネルを要求しなければならないのは、受信機/デコーダである。さらに、後述される切断手順は、チャネルを閉じるために受信機/デコーダ13によって始められる。本実施形態では、ゲートウェイプロトコルが、対応するリモートサーバとの単一TCPチャネルの確立を可能にすることが注記されなければならない。言い替えると、本実施形態では、受信機/デコーダ13は、任意の一時点に複数のリモートサーバに接続することはできない。しかしながら、受信機/デコーダ13は、それとゲートウェイ58間でフレッシュな通信チャネルを確立することを必要とせずにさまざまなリモートサーバに対して接続を確立し、解放してよい。さらに、実施形態では、ゲートウェイプロトコル層は、下部レベルプロトコルモデム/TCPがデータの移送を保証し、上部レベルプロトコルアプリケーションプロトコルがエラー処理を実行するために、エラー回復機能を実行していないことが注記されなければならない。ゲートウェイプロトコルでの通信の一般的なメッセージ構造を、ここで記述する。各メッセージ構造は、以下のフィールドを含む。{プロトコルバージョン}{コマンド識別子}{データ長}[パラメータ]この場合、{...}は必須フィールドを示し、[...]は任意フィールドを示す。メッセージ構造は、メッセージが受信機/デコーダ13から発出するのか、ゲートウェイ58から発出するのかに関係なく同じである。フィールドは、最初に最上位ビットで2進符号化される。プロトコルバージョンPRTフィールドは、プロトコルバージョンを特定する単一バイトを備える。コマンド識別子CIフィールドは、2バイトを備え、表されるメッセージの種類を特定する。多様な種類のメッセージが、下記に概略されるデータ交換イベント説明から明らかになるだろう。データ長DLフィールドは、長さが2バイトで、存在する場合には付加されるパラメータフィールドの全体的な長さを特定する。これが、パラメータフィールドが可変長であることを可能にする。付加されるパラメータフィールドがない場合には、このフィールドはゼロ値を含むだろう。パラメータフィールドは、TLV形式型長さ値で符号化され、メッセージに関連付けられるあらゆる必要なパラメータを含む。個々に、あるいはメッセージの種類に依存して組み合わせて使用されてよい3つのカテゴリのパラメータがある。言い替えると、メッセージの種類が、どのパラメータフィールドが存在するのかを定める。また、一定のメッセージ例えば、接続がリセットされるMG_RCNXことを命令するメッセージが、関連付けられたパラメータを有さないことも理解されるだろう。第1種のパラメータREMOTE_SERVERはリモートサーバを特定し、特定されるサーバがメールサーバ64のSTMP部分であるのか、メールサーバ64のIMAP部分であるのか、対応サーバ76、またはリマインダサーバ78であるのかを示す整数を含む。実施形態では、このパラメータの長さは2バイトである。修正では、パラメータが、その他のまたは追加のサーバを特定するために使用できるだろう。第2種のパラメータBODYは、重要なリモートサーバから受信されるまたは重要なリモートサーバに送信されるデータを含むために使用される。このパラメータは、データ長フィールドによって定められるように可変長であり、このためデータパッケージが所定の長さである必要がないことを示す。このパラメータの最大長は事前に定義される。第3種のパラメータERROR_CODEは、エラー状態を特定するために使用される。これは、例えば、ゲートウェイがいつ指定されたリモートサーバとの接続を開くことができないのか、いつリモートサーバとの接続が失われたのか、いつ受信機/デコーダ13から受信されたメッセージでエラーが検出されるのか、いつ受信機/デコーダ13からの命令に続いてリモートサーバからデータが受信されなかったのか、またはいつ認証が失敗したのかを示すために使用されてよい。実施形態では、このパラメータの長さは2バイト長である。修正では、認証詳細を含むために使用される第4種パラメータがあってよい。ゲートウェイプロトコルレベル通信チャネル上の通常のダイアログを表す典型的なデータ交換シーケンスを、ここで図9に関して説明する。これは、ある時間期間で時間は、ページを下るにつれて増すゲートウェイ58と選択されたリモートサーバの間で発生する対応するイベントとともに、受信機/デコーダ13とゲートウェイ58の間のメッセージを図で示す。図示されている第1イベントシリーズe1は、受信機/デコーダと指定されたリモートサーバ間のゲートウェイプロトコルレベル接続手順である。受信機/デコーダ13は、2つのパラメータ、つまり、それがダイアログを実施することを所望するサーバを指定するREMOTE_SERVERパラメータと、存在する場合はリモートサーバにアドレス指定されるデータをカプセル化するBODYパラメータを含む接続MG_CNXを要求するメッセージ1000を送信する。これが、ゲートウェイに、図において接続1001として集合的に示される2つのタスク、つまり適切なリンクを介して指定されたリンクとの接続を確立させ、そのリンクを介して指定されたサーバにメッセージBODYパラメータ内に含まれる存在する場合データを送信させるというタスクを実行させる。前記シーケンスに続いて、リモートサーバは、受信機/デコーダ13への前方への伝送のために、データ1002をゲートウェイ58に送信する。ゲートウェイは、このデータを含む単一パラメータフィールド、つまりBODYを有するリモートサーバとのデータ交換MG_REMOTEメッセージ1003の中でこれを符号化し、メッセージを受信機/デコーダ13に送信する。接続はそれにより確立される。図示される第2イベントシリーズe2は、典型的なデータ交換シーケンスである。シーケンスは、フィールドパラメータBODY内のサーバを宛先とするデータを含むリモートサーバとのデータ交換MG_OTHERメッセージの受信機/デコーダ13による送信で開始する。理解されるように、受信機/デコーダ13は、任意の一時点で1つのリモートサーバと通信するだけであるため、サーバが接続メッセージe2によってすでに指定されるので、それは通常のデータ交換中に指定される必要はない。ゲートウェイ58がこのデータ交換メッセージ1004を受信すると、それはその中のデータを、1005と示される通信の中のリモートサーバに渡す。それ以後、リモートサーバは、前述されたように、1006、1007と示される受信機/デコーダにデータを送信する。実施形態の追加の特徴を、ここで1008a、1008bおよび1009と示される通信に関して説明する。ゲートウェイ58から受信機/デコーダ13に送信される型のリモートサーバとのデータ交換MG_REMOTEメッセージは、最小データパケットサイズを含む。したがって、所定の最小量のデータがリモートサーバから受信される実際には最小データ量スレッショルドまで、あるいはリモートサーバからの最終データの受信から所定の時間が経過する実際には、タイムアウトまで、ゲートウェイ58は、受信機/デコーダ13にメッセージを送信しないだろう。このようにして、通信1008aはリモートサーバからゲートウェイ58へのデータ転送を表すが、このデータの量は所定スレッショルドより低いため、この時点では受信機/デコーダ13にメッセージは送信されない。次に、追加データ転送1008bは、リモートサーバからゲートウェイ58へ発生する。この転送の結果、ゲートウェイに十分なデータが通信され、そのためそれはデータシーケンス1008a、1008bの両方を含むデータ交換メッセージ1009を送信する。同様にして、いったんリモートサーバからゲートウェイ58によって受信されるデータの量が最大量を超えると、データ交換メッセージは受信機/デコーダ13に送信される。このような場合、リモートサーバとゲートウェイ58間での単一データ交換シーケンスから、ゲートウェイ58と受信機/デコーダ13間の複数のメッセージが生じる可能性がある。実施形態では、タイムアウト期間は200ミリ秒msであり、最小データ受信スレッショルドは128バイトであり、最大データ受信スレッショルドは512バイトである。図中に示されていないが、ゲートウェイ58が、実施形態では5秒である所定のタイムアウト期間内にリモートサーバからデータを受信していないということが生じる場合がある。このような場合、ゲートウェイは受信機/デコーダ13に、ERROR_CODE型のパラメータフィールドを含むゲートウェイによるエラー検出MG_ERRORメッセージを送信し、このフィールドのコンテンツがこのようなイベントの発生を指定する。受信機/デコーダ13は、ゲートウェイ58にリモートサーバとのTCP接続を閉じさせる通信リセットMG_RCNXメッセージの送信を含むことがある、それが講じることを望むあらゆる追加動作の責任を負う。前記に予示されるように、類似したエラーメッセージが、リモートサーバとの接続を開くことができない、リモートサーバとの接続の損失、あるいはリモートサーバからの誤ったメッセージなどのそれ以外のイベントの後に続く可能性がある。後者のケースでは、これは、未知の型の、不正確な長さの、適用不可の値の、あるいは未知のプロトコルバージョンを有する、ゲートウェイ58によるリモートサーバからのデータの受信を含むことがある。図9を参照して、リモートサーバからの切断のイベントe3をここで説明する。このイベントは、切断MG_DCNXメッセージ1020を送信する受信機/デコーダ13によって開始される。このメッセージは、BODYパラメータ内でリモートサーバに渡されるべきデータを含んでよい。このコマンドおよびデータ1021は、リモートサーバに渡され、その後、ゲートウェイ58は、肯定応答および存在する場合には応答データ1022を待機する。その後で、ゲートウェイ58はリモートサーバ1023から切断し、存在する場合、受信されたデータを含むメッセージ1024を受信機/デコーダ13に送信する。低プロトコルレベルの図には示されていないが、受信機/デコーダ13は、それからモデムレベルでの切断を閉じてよい。ゲートウェイ58は、その後、TCP接続が閉じられる旨をNAS56によって通知されるだろう。ゲートウェイプロトコルによって備えられる認証プロセスを、ここで図10に関して説明する。これは、通信チャネルの確立前に、多様なサービス、たとえば対応サービスのために必要とされることがある。ゲートウェイ58は、サーバがアクセスの前に認証を必要とする情報を含み、それがこのようなサーバのために接続要求MG_CNXメッセージ1100を受信するとき、それは認証要求MG_AUTHEB_REQメッセージ1101で応答する。このような認証要求メッセージは、付随するパラメータを有していない。受信機/デコーダ13は、それ以降、適切な認証メッセージ1102で応答しなければならない。以下により完全に述べられるように、このメッセージは、例えば、スマートカード番号である場合がある認証データを含む関連付けられたパラメータを有する。認証データは、BODY型パラメータの中で渡されてよいか、あるいは修正の中で独自のパラメータ型を有してよい。ゲートウェイ58が、認証詳細が正しいと宣言すると、認証は無事終了し図ではイベント1103で示される、ゲートウェイ58が指定されたリモートサーバとの接続1104を確立する。ゲートウェイ58は、接続の開放に応えてリモートサーバから受信されるあらゆるデータ1105を含むであろうデータ交換メッセージ1106を送信することによって認証が無事終了することを報告する。認証が失敗する場合、前記に概略されたように、このような失敗を示すパラメータを含むエラーメッセージMG_ERRORが送信される。図5に示されるシステムに戻ると、受信機/デコーダ13からのインターネットサービス等のアクセス用の2つの異なった種類のアカウント、つまりいわゆる接続アカウントおよびいわゆるディレクトリアカウントを特定することが可能である。あらゆる接続アカウントの内で、複数のディレクトリアカウントが存在する可能性がある。接続アカウントは、加入者がオペレータネットワークにアクセスしてよい基礎を提供する。これはさらに詳しく後述されるように複数の接続プロトコルと関連付けられてよいが、加入者はオペレータごとに単一の接続アカウントを割り当てられるだろう。このようなアカウントの認証を発生させる方法はネットワークレベルであり、さらに詳細に後述されるだろう。自分の接続アカウントによるユーザログイン時の手順を、ここで説明する。理解されるように、ログイン時に供給される識別データは、ユーザが、受信者によって特定できるようにするために一意でなければならない。実施形態では、これは、少なくとも部分的に、ユーザの装置のスマートカード番号から引き出されるいわゆるMSD番号の使用によって達成される。さらに、ログイン時、ユーザは、例えば、ユーザがコンピュータ例えば、Canalの製品であるMediaWebPCと関連付けられるダイヤルアップモデムを介してアクセスを試みるのか、それとも一般的にセットトップボックスと呼ばれている装置のような受信機/デコーダ装置の種類を介してアクセスを試みるのかに応じて変化する可能性がある通信プロトコルを指定しなければならない。使用されるプロトコルは、例えば、ダイヤルアップモデムに対してはPAP、CHAPまたはPPPである可能性がある。したがって、ログイン情報は、ユーザのMSD番号の内、ユーザ端末の種別を特定するフィールド、活用されるデータ戻りの種類を指定するフィールド、クライアントバージョン番号を示すフィールド、および該当する場合、いわゆるクライアントのRADIUSドメイン名を含む。ログインは、パスワードも含むだろう。実施形態では、この情報は以下のようにフォーマットされる。ログイン={msn_number}{端末種別}{return_type}{バージョン}{RADIUS_domain_name}前記フィールドのそれぞれを、ここで更に詳細に説明する。msn_numberフィールド自体は、フィールドの以下の文字列から成り立つ。{msn_number}={RSMC}{RSMN}{chck}第1のMSNデータフィールドは、スマートカードの型を特定する取外し可能機密保護モジュール製品コードRSMCを含む。型のこの識別は、カードの技術的な構成、製造メーカー、およびカードをユーザに提供した商業的なオペレータの1つまたは複数の態様を示すデータを含んでよい。実施形態では、このフィールドは長さが2バイトであり、4個のディジットを含んでいてよい。第2のMSNデータフィールドは、取外し可能機密保護モジュール番号RSMNを含む。このフィールドは、使用中のスマートカードを特定するコードを含む。このようなコードは、好ましくはスマートカード供給業者によって事前にプログラミングされ、スマートカード、したがってユーザに一意であり、それによりユーザの識別を可能にする。実施形態では、このフィールドは、長さが4バイトであり、15個の数字を含んでよい。最終フィールドは、任意の既知の方法によって計算されてよいチェックデータchckを含み、例えば、それはチェックサムであってよい。terminal_typeフィールドが、ここで説明されるだろう。前述されたように、端末はいわゆるセットトップボックスの種類であってよいか、あるいはモデム機構を有するコンピュータであってよい。フィールドは、PC型端末の場合値Pを取り、セットトップボックス端末型の場合、値Tを取るだろう。フィールドが、より正確に端末型を指定し、このようなフィールドの提供が、追加のおよび代替の端末型の定義による将来の拡張も可能にすることが理解されるだろう。return_typeフィールドは、戻りデータをユーザに送信する方法の指定を可能にする。実施形態では、フィールドは、すべての戻りデータがモデムを解して送られなければならないときには値Mを取り、データ戻りが衛星チャネルとモデムチャネルの両方で発生しなければならないときには値Sを取る。再び、戻りデータを提供する方法の将来の拡張の可能性が提供される。バージョンデータフィールドは、バージョンデータを受信機/デコーダ13からネットワークに渡すことができるようにする。実施形態では、これはデフォルトとして01で設定される。オプションフィールドのRADIUS_domain_nameは、クライアントの認証要求を、ゲートウェイのこのような第3者による、例えば、別のサービスプロバイダへの提供を可能にする第3部認証サーバに送ることができるようにする。接続プロファイルは、実施形態では、14英数字という最大長を有するパスワードフィールドも含むだろう。ここでディレクトリアカウントの説明に戻ると、これは、例えば識別付き代理、メール、ニュース等の個々のインターネットサービスのアクセスの基礎を提供する。加入者のディレクトリアカウントは、自分の接続アカウントにリンクされる。しかしながら、接続アカウントと区別して、ディレクトリアカウントの認証はアプリケーションレベルで発生する。前述されたように、ディレクトリアカウントは、受信機/デコーダ13からの種々のインターネットサービスへのアクセスを可能にする。ディレクトリアカウントは、通常、以下から成り立つ。-識別子およびパスワード-1つまたは複数のいわゆるeメールエイリアス-適切なケースでは、加入者に提供されるサービスに関するその他のデータ識別子は適切なケースではパスワードと組み合わされて、例えば加入者のメールボックスへのアクセスなどの多様なISPサービスの加入者によるアクセスを制御するために使用される。その他の例は、私用ウェブサイト、ディレクトリへのアクセス、サービス、証明書、メールグループ登録等へのアクセスの制御を含む。識別子は、フォーマットidentifierdomainでeメールアドレスを受信するためにも使用されてよく、その場合加入者が、識別子によって特定されるメールボックスにアクセスするときに自分のパスワードを使用する必要がある場合がある。eメールエイリアスは、aliasdomainへのメッセージアドレスのeメールサーバによるeメール受信の機構に備える。実施形態では、複数のディレクトリアカウントが、単一接続アカウントいわゆる家族加入に関連付けられてよい。このような場合、各識別子およびエイリアスが一意でなければならないことが注記される必要があるが、ユーザは、最初に、各接続アカウントごとに可能であるディレクトリアカウントの数を指定できる可能性がある。用語以下の用語がここに使用される。EメールアドレスEメールアドレスは、EメールIDとドメイン名の2つのフィールドから構成される。eメールアドレスの形式は、mail_IdDomain_Nameである。EメールアカウントEメールアカウントは、メールサーバがそのユーザのメッセージを処理する必要のあるユーザについての情報を提供する。EメールIdeメールアドレスの接頭語である。eメールIdは、ドメイン名で一意でなければならない。Eメール通知者Eメール通知者システムにより、加入者EMNに、彼らがメールボックスに新しいeメールを受信するとすぐに通知することができる。短いメッセージは、電波放送媒体上で彼らのSTBに送信される。インターネットアカウント管理システム加入者TVアカウント管理パラメータおよび関連するEメールアカウントシステムIAMSパラメータを管理するシステム。メールボックスIMAP送達用に記憶されるメッセージは、メールボックス内に保持される。メールサーバ上のメールボックスは、メールボックスIdによって一意に特定されなければならない。異なるドメイン名をホストするメールサーバは、eメールIdがメールサーバで一意であると考えることはできないため、メールボックスIdはEメールアドレスでなければならない。メールサーバ他のメールサーバとeメールを交換し、メッセージを受け入れ、メールクライアントに送達するプログラム。メッセージ待ち行列サーバMQSメッセージ管理システム。対応サーバ加入者が、eメールアカウントを自分達自身で作成、カスタマイズできるようにする。リマインダサービスユーザが、イベントを登録し、自動メールを介して自動リマインダを受信できるようにする。セットトップボックスデジタルビデオ放送規格、CANALTECHNOLOGIES仕様に従って、完全に組み立てられ、使用準備が完了しているSTBデジタル復号ハードウェア。エンドユーザがテレビ番組およびサービスにアクセスできるように、伝送済みのビデオ、オーディオ、アプリケーション、およびデータストリーム用のデジタルデコーダとして使用される。スマートカード1つまたは複数の商業的なオペレータの秘密鍵、およびその他のアクセス情報を電子的に記憶するカード。加入者加入者はTVアカウントつまり、スマートカード番号に関係する。加入者管理システムSMS加入者に関係するデータを管理するシステム。ユーザユーザはEメールアカウントに関係する。単一加入者に複数のユーザがいる可能性がある。ここに使用される用語受信機/デコーダまたはデコーダは、例えば、なんらかの他の手段によって放送または伝送されてよい、テレビおよび/または無線信号などの符号化されるか、符号化されていない信号のどちらかを受信するための受信機を言外に意味する。この用語は、また、受信された信号を復号するためのデコーダも言外に意味する。このような受信機/デコーダの実施形態は、例えばセットトップボックス内で受信された信号を復号するための受信機に一体化されたデコーダを含んでよく、このようなデコーダは、物理的に別個の受信機と組み合わされて機能するか、あるいはこのようなデコーダは、ウェブブラウザなどの追加機能を含むか、あるいはビデオレコーダまたはテレビなどのその他のデバイスと統合されている。本発明が、純粋に例によって前述され、詳細の修正が発明の範囲内でなされうることが理解されるだろう。説明、および適切な場合クレームおよび図面中に開示される各特徴は、独立して、または適切な組み合わせで提供されてよい。クレーム中に示される参照番号は例示としてのみであり、クレームの範囲に制限的な影響を及ぼさないものとする。"