通信方法および装置
【課題】受信機／デコーダとリモートサーバ間で通信を認証する方法を提供する。
【解決手段】通信を認証するために該受信機／デコーダ１３の識別子を使用することからなり、該識別子はスマートカード番号に基づいている。データを受信機／デコーダから受け取り、そのデータはインターネットプロトコルにはなく、インターネットサービスプロバイダへの伝送のために前記データをインターネットプロトコルに変換するように適応されているゲートウェイ５８もまた開示されている。
【解決手段】通信を認証するために該受信機／デコーダ１３の識別子を使用することからなり、該識別子はスマートカード番号に基づいている。データを受信機／デコーダから受け取り、そのデータはインターネットプロトコルにはなく、インターネットサービスプロバイダへの伝送のために前記データをインターネットプロトコルに変換するように適応されているゲートウェイ５８もまた開示されている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信機／デコーダなどのユーザ装置と、例えばインターネットアカウント管理システムまたはインターネットサービスプロバイダであってよいリモート装置の間での通信のための方法および装置に関する。
受信機／デコーダは、アナログ形式またはデジタル形式で伝送されてよい、テレビ信号などの信号を受信および／または復号するために使用される。デジタル伝送のケースでは、デジタルチャネルは、送信機終端でデジタルデータストリームに符号化され、デジタルセットトップボックス（ＤＳＴＢ）内または統合型デジタルテレビ型のどちらかであってよい受信機／デコーダを使用して受信機終端で復号される。アナログ伝送のケースでは、受信機／デコーダは、伝送済み信号を、テレビ画面で表示されてよいフォーマットに変換するために加入者で提供されてよい。
【０００２】
受信機／デコーダは、典型的には、アプリケーションとして知られているプログラムが実行されてよいプロセッサを含む。受信機／デコーダで実行されてよいアプリケーションの例は、加入者が受信機／デコーダによってインターネットにアクセスできるようにする、インターネットアクセスアプリケーションである。
受信機／デコーダは、低い単位費用を確実にするために相対的に簡略な構造となる傾向がある。このために、インターネットなどのリモートネットワークと通信するために受信機／デコーダをセットアップするのが困難になる場合がある。特に、インターネットとの通信は、受信機／デコーダ上で実現するのが困難である場合があるインターネットプロトコルの使用および認証を必要とする。例えば、一定の受信機／デコーダは、インターネットへの直接的な接続に適したフォーマットでデータを出力できない可能性がある。このような受信機／デコーダが、「非ＩＰイネーブル済み」と呼ばれる。
【発明の概要】
【０００３】
本発明の第１態様は、ネットワークにアクセスを提供するために、受信機／デコーダとリモートサーバ間の通信を認証する方法を提供し、該方法は、該通信を認証するために該受信機／デコーダの識別子を使用することからなり、該識別子は放送サービスへのアクセスのために識別子に基づいている。
発明を使用することにより、受信機／デコーダとリモートサーバとの間の通信の認証は、受信機／デコーダが準備可能なアクセスを有する受信機／デコーダの一致の識別子に基づくことがあり、受信機／デコーダに対してなされた要求を削減することができる。受信機／デコーダには、多くの場合、放送サービスへのアクセス用の一意の識別子が提供され、その識別子が受信機／デコーダを識別する便利な手段を提供する。
【０００４】
好ましくは、識別子は、スマートカードなどの取外し可能な構成要素に記憶される。
好ましくは、識別子は、ネットワークログイン識別子とは無関係である。識別子は、ユーザが憶えるのを容易にするために、複雑な複数文字識別子である傾向があるネットワークログイン識別子より簡略である可能性があるため、これが受信機／デコーダの複雑度を削減できる。ログイン識別子の別の欠点とは、それらがときどき変化する可能性がある点、あるいはさまざまなサービスへのアクセスのために複数のものが必要とされる可能性がある点である。本発明は、受信機／デコーダによって供給される単一識別子を（リモートサーバ内で）変更可能ネットワーク識別子と、あるいは複数のネットワーク識別子と関連付けることができるようにする。この機能は個別に提供されてよい。
【０００５】
好ましくは、識別子は、スマートカードに一意の番号に基づく。ここに使用されているように、用語「スマートカード」は、任意のチップベースのカードデバイス、または例えばマイクロプロセッサおよび／またはメモリ記憶装置などの類似した機能と性能、処理の対象を含むが、独占的にそのようではない。この用語に含まれるのは、多くの場合ＴＶデコーダシステムで使用されるような鍵の形をしたデバイスなど、カードに代わる物理形式を有する装置である。
【０００６】
リモートサーバは、インターネットにアクセスするためであるか、あるいはそれはインターネットアカウント管理システム、あるいは例えば任意の形式のリモートネットワークにアクセスするためのそれ以外の任意の形のサーバであってよい。
ユーザ用のインターネットアカウントは、受信機／デコーダの識別子を使用するインターネットアカウント管理システムによって確立されてよい。アカウントを確立するために、受信機／デコーダの識別子は、インターネットアカウント管理システムによって、インターネットアカウントを確立してよい受信機／デコーダの識別子の記憶されているリストと比較されてよい。
【０００７】
リモートサーバは、データをインターネットサービスプロバイダに送信するための手段を備えてよく、該方法は、インターネットアカウントの詳細をインターネットサービスプロバイダに提供し、受信機／デコーダとインターネットサービスプロバイダ間で双方向データ経路を確立するステップを備える。
識別子は、受信機／デコーダとリモートサーバ間の通信のために使用されるデータ経路を特定するデータに伴われてよい。このようにして、受信機／デコーダは、通信のために使用される経路を指定することができる。例えば、衛星リンクが戻りチャネルのために使用されてよい。
【図面の簡単な説明】
【０００８】
【図１】典型的なデジタルテレビシステムのアーキテクチャを示す。
【図２】受信機／デコーダの概略図である。
【図３】インターネットアクセスシステムの概要を示す。
【図４】図３のユーザ装置内のソフトウェア層を示す。
【図５】インターネットアクセスシステムのアーキテクチャを示す。
【図６】インターネットアカウント管理システムの主要な構成要素を示す。
【図７】受信機／デコーダがＩＰイネーブル済みではない場合の、インターネットアクセスシステムの構成の一部を示す。
【図８】図７に図示されるシステムプロトコル層を示す。
【図９】図７のシステム内のユーザ装置とゲートウェイ間の通信のために適応されるプロトコルを図式で示す。
【図１０】図７のシステム内のユーザ装置とゲートウェイ間の認証関係通信のために適応されるプロトコルを図式で示す
【発明を実施するための形態】
【０００９】
好ましい実施形態では、ログイン詳細は、以下の形式を取り、
ログイン＝｛スマートカード番号｝｛サービスの種別｝
その場合、サービスの種別（ＴＯＳ）は、データ通信がその上で発生することになるチャネル、例えば応答のカテゴリが衛星によって端末に送信されなければならないケースを指定してよい。
【００１０】
好ましい実施形態では、リモートサーバは、受信機／デコーダに、ネットワークプロトコルを有するネットワークへのアクセスを提供し、受信機／デコーダから出力されるデータは、受信機／デコーダから遠い場所でネットワークプロトコルに準拠するデータに変換される。このようにして、ネットワークプロトコルを備えていない受信機／デコーダも、依然としてネットワークと通信してよい。ネットワークは、例えば、インターネットでよく、ネットワークプロトコルは、例えば、トランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）であってよい。該遠い場所とは、例えば、インターネットアカウント管理システムを備えてよいオペレータであってよい。
【００１１】
好ましくは、データは、受信機／デコーダとリモートサーバ間のゲートウェイによって、ネットワークプロトコルに準拠する前記データに変換される。
好ましい実施形態では、ネットワークは、複数のリモートデバイスを備え、前記変換されたデータは、前記データに指定されるように、ゲートウェイによって前記リモートデバイスの内の１つに通信され、それにより受信機／デコーダと指定されたリモートデバイス間に通信チャネルを確立する。
【００１２】
第２態様では、本発明は、非インターネットプロトコルイネーブル済みユーザ端末から複数のインターネットプロトコルイネーブル済みリモートデバイスの１つにデータを通信する方法を提供し、該方法は、前記ユーザ端末から前記ゲートウェイへ前記非インターネットプロトコルを使用してデータを通信し、前記データがメッセージを含み、前記複数のリモートデバイスからの前記メッセージの宛先を指定するステップと、前記ゲートウェイで前記データを前記インターネットプロトコルを使用するデータに変換するステップと、前記インターネットプロトコルを使用する前記データを前記ゲートウェイから指定された宛先リモートデバイスに通信し、それによりユーザ端末と指定されたリモートデバイス間に通信チャネルを確立するステップとを備える。ユーザ端末は、受信機／デコーダであってよい。
【００１３】
また、提供されているのは、受信機／デコーダとリモートネットワーク間で通信する方法であって、そこではリモートネットワークと通信するために必要なプロトコルは、受信機／デコーダから遠い場所で実現される。
通信チャネルの終端を命令するメッセージが、非インターネットプロトコルを使用して、受信機／デコーダからゲートウェイに通信されてよく、ゲートウェイは、代わりに、インターネットプロトコルを使用して指定されたリモートデバイスに終端コマンドを通信する。好ましくは、受信機／デコーダの識別は、通信チャネルが確立する前にゲートウェイによって認証される。
【００１４】
第３態様では、本発明は、ネットワークへのアクセスを提供するために受信機／デコーダとリモートサーバ間の通信を認証するための装置を提供し、該装置は、通信を認証するために受信機／デコーダの識別子を使用するための手段（例えば、システム、サーバまたはゲートウェイ）を備え、該識別子は、放送サービスへのアクセスのために識別子に基づいている。識別子は、受信機／デコーダとリモートサーバ間の通信に使用されるデータ経路を特定するデータを伴ってよい。
リモートサーバは、ネットワークプロトコルを有するネットワークへのアクセスを、受信機／デコーダに与えてよく、前記装置は、受信機／デコーダから出力されるデータを、ネットワークプロトコルに準拠するデータに変換するための手段（例えば、システム、サーバまたはゲートウェイ）を備える。
好ましくは、装置は、受信機／デコーダとリモートサーバの中間のゲートウェイである。
好ましくは、ネットワークは複数のリモートデバイスを備え、前記ゲートウェイは、前記データに指定されるように、前記リモートデバイスの１つに変換されたデータを通信するように適応され、それにより、受信機／デコーダと指定されたリモートデバイス間の通信チャネルを確立する。
【００１５】
第４態様では、本発明は、非インターネットプロトコルイネーブル済みユーザ端末から受信されるデータを、複数のインターネットプロトコルイネーブル済みリモートデバイスの１つに通信するためのゲートウェイを提供し、該ゲートウェイは、
前記ユーザ端末からの前記非インターネットプロトコルを使用して通信されるデータを受信するための手段（例えば、入力）であって、前記データがメッセージを含み、前記複数のリモートデバイスからの前記メッセージの宛先を指定する手段と、
受信されたデータを、前記インターネットプロトコルを使用するデータに変換するための手段（例えば、変換器）と、
前記インターネットプロトコルを使用する前記データを、指定された宛先リモートデバイスに通信し、それによりユーザ端末と指定されたリモートデバイス間に通信チャネルを確立するための手段（例えば、出力）と、
を備える。
【００１６】
ゲートウェイは、それぞれのリモートデバイスへの接続のためにそれぞれ複数の入力／出力を備えてよい。
ゲートウェイは、通信チャネルの終端を命令するユーザ端末からのメッセージを特定するための手段（例えば、識別子）、および指定されたリモートデバイスに終端コマンドを送るための手段（例えば、出力）を備えてよい。
本発明は、実質的には添付図面に関して説明されるような、および添付図面の中に示されるような方法および装置も提供する。
ある態様の特徴は、他の態様に適用されてよい。同様に、方法特徴は、装置態様に適用されてよく、またその逆にも適用されてよい。
【００１７】
本発明の好ましい特徴は、ここでは、純粋に例によって、添付図面に関して記述される。
デジタルテレビシステム１の概要は、図１に図示される。本発明は、圧縮済みデジタル信号を伝送するために、既知のＭＰＥＧ−２圧縮システムを使用する主として従来のデジタルテレビシステム２を含む。さらに詳細には、放送センタ内のＭＰＥＧ−２圧縮機３がデジタル信号ストリーム（典型的には、ビデオ信号のストリーム）を受信する。圧縮機３は、リンク機構５によってマルチプレクサとスクランブラ４に連結される。
【００１８】
マルチプレクサ４は、複数の追加入力信号を受信し、トランスポートストリームをアセンブルし、圧縮済みデジタル信号を、言うまでもなく電気通信リンクを含む幅広い形式を取ることができるリンク機構７を介して、放送センタの送信機６に伝送する。送信機６は、アップリンク８を介して衛星トランスポンダ９に向かって電磁信号を伝送し、そこではそれらは電子的に処理され、概念上のダウンリンク１０を介して、従来は、エンドユーザによって所有あるいは賃貸される放物面反射器という形を取る、地上受信機１２に一斉送信される。地上放送、ケーブル伝送、結合された衛星／ケーブルリンク、電話網等のデータの伝送用のその他のトランスポートチャネルが、言うまでもなく可能である。
【００１９】
受信機１２により受信される信号は、エンドユーザによって所有または賃貸される統合型受信機／デコーダ１３に伝送され、エンドユーザのテレビセット１４に接続される。該受信機／デコーダ１３は、圧縮済みＭＰＥＧ−２信号をテレビセット１４用のテレビ信号に復号する。別個の受信機／デコーダが図１に図示されているが、受信機／デコーダもまた、統合型デジタルテレビの一部であってもよい。ここに使用されるように、用語「受信機／デコーダ」は、セットトップボックスなどの別個の受信機／デコーダ、およびそれと統合された受信機／デコーダを有するテレビを含む。
【００２０】
マルチチャネルシステムでは、マルチプレクサ４は、数多くの並列ソースから受信される音声およびビデオ情報を処理し、対応する数のチャネルに沿って情報を一斉送信するために送信機６と対話する。視聴覚情報に加えて、メッセージまたはアプリケーション、あるいはそれ以外の種類のデジタルデータが、伝送済みのデジタル音声ビデオ情報とインタフェースされるこれらのチャネルのいくつかまたはすべてに導入されてよい。
【００２１】
従来のアクセスシステム１５は、マルチプレクサ４および受信機／デコーダ１３に接続され、部分的には放送センタに位置し、部分的には受信機／デコーダ内に位置する。それは、エンドユーザが、１つまたは複数の放送供給業者からのデジタルテレビ放送にアクセスできるようにする。商業的なオファー（すなわち、放送供給業者により販売される１つまたは複数のテレビ番組）に関係するメッセージを解読することができるスマートカードを、受信機／デコーダ１３に差し込むことができる。受信機／デコーダ１３およびスマートカードを使用して、エンドユーザは、加入モードまたは有料視聴モードのどちらかで商業的なオファーを購入してよい。
【００２２】
前述したように、システムにより伝送される番組は、マルチプレクサ４でスクランブルされ、条件および暗号化キーが、アクセス制御システム１５によって決定される所与の伝送に適用される。このようにしてスクランブルされたデータの伝送は、有料テレビシステムの分野では周知である。典型的には、スクランブルされたデータは、データを逆スクランブルするための制御ワードとともに伝送され、制御ワード自体がいわゆる探索キーによって暗号化され、暗号化された形式で伝送される。
【００２３】
それから、スクランブルされたデータおよび暗号化された制御ワードは、暗号化された制御ワードを解読し、その後で伝送されたデータを逆スクランブルするために、受信機／デコーダに挿入されたスマートカードに記憶される探索キーに同等なものにアクセスできる受信機／デコーダ１３によって受信される。支払済みの加入者は、例えば、放送月次ＥＭＭ（資格管理メッセージ）の中で、伝送の表示を可能にするために暗号化された制御ワードを復号するために必要な探索キーを受信するだろう。
【００２４】
やはりマルチプレクサ４および受信機／デコーダ１３に接続され、再び、部分的に放送センタ内に位置し、部分的に受信機／デコーダ内に位置する対話型システム１６により、エンドユーザは、モデム送受信（ｍｏｄｅｍｅｄ）バックチャネル１７を介して多様なアプリケーションと対話できるようになる。モデム送受信バックチャネルは、条件付きアクセスシステム１５内で使用される通信にも使用されてよい。
【００２５】
受信機／デコーダ１３の物理インタフェースは、データをダウンロードするために使用される。図２を参照すると、受信機／デコーダ１３は、例えば、６台のダウンロードデバイス、つまり直列インタフェース３０、並列インタフェース３２、モデム３４、２台のカード読取り装置３６、およびＭＰＥＧフローチューナ３８を含む。
【００２６】
放送受信システムも、ウェブブラウジングおよびｅメールなどのインターネットサービスを提供するために使用される。受信機／デコーダ１３によって実行されるアプリケーションは、受信機／デコーダが、インターネットサービスにアクセスし、ウェブページおよびｅメールを、テレビセット１４上でまたは受信機／デコーダ１３に接続されるコンピュータを介して表示できるようにする。
【００２７】
図３を参照して、インターネットアクセスシステムの概要を説明する。（受信機／デコーダを含む）ユーザ装置２０は、公衆加入電話網（ＰＳＴＮ）２４を介してオペレータ２２と通信する。ユーザ装置は、オペレータ２２に対し、例えば、ある特定のウェブページまたはｅメールなどの一定のデータを送信されるようにという要求を送信する。オペレータはこの要求を受信し、要求をインターネットサービスプロバイダ（ＩＳＰ）２６に出力する。この要求に応えて、ＩＳＰは、インターネット２７から得られた要求されたウェブページ、またはＩＳＰで加入者を待機していたｅメールを備える可能性がある応答をオペレータに供給する。オペレータは、応答を、それが、例えば私用セクションとしてＭＰＥＧビットストリームに統合され、前述されたように送信機６によって伝送され、受信機１２によって受信される放送センタ２８に送達する。受信機／デコーダがＩＰイネーブルされている場合、つまりデータをインターネットから受信するためのプロトコルを備えている場合、情報はＭＰＥＧビットストリーム内で、つまりＩＰフォーマットでＩＰフレームとして伝送されてよい。受信機／デコーダがＩＰイネーブルされていない場合には、データは、例えば私用ＭＰＥＧセクションとして、なんらかの他の方法で送信される。ユーザ装置２０は、ＭＰＥＧビットストリームから応答を抽出し、それをテレビセットまたはコンピュータ画面上で表示する。代わりに、応答は、ＰＳＴＮ２４を介してユーザ装置２０に伝送されてよい。
【００２８】
ユーザ装置２０で利用されるソフトウェアレベルは、図４に図示される。アプリケーションレベルは、ＮｅｔｓｃａｐｅまたはＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒおよびＯｕｔｌｏｏｋ Ｅｘｐｒｅｓｓなどの商業的なアプリケーション、または受信機／デコーダで実行するように特に設計されるアプリケーションであってよい、ウェブブラウザおよびｅメールアプリケーションを備える。アプリケーションレベルの下には、ＨＴＴＰ、ソケット、ＴＣＰ／ＩＰ、ＰＰＰ／ＳＬＩＰ、およびドライバレベルがある。ドライバレベルは、ＰＣ上で従来動作しているブラウザアプリケーションと比較して、それがユーザ装置のモデムを介してＰＳＴＮ２４と通信するためのモデムドライバ、およびＭＰＥＧフローチューナ４０２８を介して通信するためのチューナドライバに分割されるという点で修正される。
【００２９】
ユーザ装置２０の多様な構成が考えられる。ある構成では、ＰＣは使用されず、ユーザソフトウェアのすべては受信機／デコーダ１３上で実行する。この構成では、受信機／デコーダ１３は、内蔵モデムを介して、または外部モデムおよびシリアルポートを介してのどちらかでＰＳＴＮ２４と通信する。受信機／デコーダ１３は、地上受信機１２からビットストリーム内のインターネット応答を受信できる。ユーザインタフェースは、遠隔制御装置またはキーボードおよび受信機／デコーダ１３に接続されているテレビセットによって提供される。この構成では、図４に示されるＴＣＰ／ＩＰレベルは省略されてよく、その場合、オペレータに位置するゲートウェイが、後述されるように必要なプロトコルを提供する。
【００３０】
別の構成では、その並列ポートによって受信機／デコーダ１３の並列ポート３２に（あるいは任意にその直列ポートによって受信機／デコーダ１３の直列ポート３０に）接続されるパーソナルコンピュータ（ＰＣ）が提供される。この場合、図４に図示されるソフトウェアレベルの上部は、ＰＣ上で実行し、ソフトウェアレベルの残りの下部は受信機／デコーダ１３上で実行する。ユーザインタフェースは、キーボードおよびＰＣに接続されるモニタによって提供される。
追加の構成では、ＰＣはＰＣの内蔵モデムまたは外付けモデムを介してＰＳＴＮ２４に接続される。この構成では、受信機／デコーダ１３は、別個に、またはそのＩＳＡまたはＰＣＩバスに接続される、ＰＣの付属またはプラグイン式のカードの形を取り、提供されてよい。
【００３１】
インターネットアクセスシステムのアーキテクチャは、図５に示されている。図５を参照すると、インターネットアカウント管理システム（ＩＡＭＳ）５０は、ウェブブラウジングおよびｅメールなどのサービスを提供するインターネットサービスプロバイダ（ＩＳＰ）２６にリンクされる。ＩＡＭＳ５０は、加入者を管理し、インターネットサービスへのアクセスを許可または拒絶するためにＩＡＭＳに要求を送信する加入者管理システム（ＳＭＳ）６０にもリンクされる。受信機／デコーダ１１３は、内蔵モデム、公衆加入電話網（ＰＳＴＮ）２４、ネットワークアクセスサーバ（ＮＡＳ）５６、およびゲートウェイ５８を介してＩＡＭＳに接続される。
【００３２】
ＳＭＳは、放送テレビサービスなどの許可および放送サービスに対する加入者の注文を管理する加入許可システム（ＳＡＳ）６１にも接続される。ＳＭＳは、並列でＳＡＳシステムおよびＩＡＭＳシステムを実行し、２つのシステム間の整合性を確実にする。ＳＭＳとＳＡＳとＩＡＭＳとの間の通信は、バッチファイルを使用するリアルタイムＴＣＰ／ＩＰリンクを使用して発生する。
【００３３】
ゲートウェイ５８により、加入者は、リアルタイムでインターネットサービスにアクセスできる。このようなサービスは、メールを送受するためのメールサービス、およびＩＳＰ２６によって提供されてよいそれ以外のサービス、ならびにＩＡＭＳによって提供される対応（ｐｒｏｖｉｓｉｏｎｉｎｇ）サービスおよびリマインダサービスを含む。機能上、ゲートウェイ５８は、単一モデム接続で多様な異なるシステムとの通信をイネーブルするメッセージルータである。受信機／デコーダにＩＳＰと通信するためのＴＣＰ／ＩＰプロトコルが備えられていない場合、ゲートウェイは、受信機／デコーダがＩＳＰと通信するために必要なプロトコルも提供する。それから、受信機／デコーダ１３は、図５の線５９で示されるように、ゲートウェイ５８を介してＩＳＰと通信する。受信機／デコーダに必要なプロトコルが備えられている場合、通信は、図５の破線５７で示されるように、ＩＳＰと直接的に発生することができる。ゲートウェイは通信サーバおよびｅメールディスパッチャを備える。
【００３４】
ＩＳＰインタフェース６６は、ＩＡＭＳ内で発生するユーザのアカウントに関係する各修正を、メールサービスなどのホストインターネットサービスを担当するＩＳＰ２６内のユーザアカウントに複製できるようにする。加入者アカウントに関係するすべての情報はＩＡＭＳ内に集中化され、ＴＶおよびインターネットパラメータの管理を確実にすることに注記する必要がある。ＩＡＭＳは、加入者管理システム（ＳＭＳ）６０とのそのインタフェースを通して、インターネットパラメータとＴＶパラメータ間の関係性も管理する。ＳＭＳ６０は加入者を管理し、加入者によるインターネットサービスへのアクセスを許可または拒絶するためにＩＡＭＳに要求を送信する。
【００３５】
ＩＡＭＳアカウントをセットアップするために、加入者は、最初に、受信機／デコーダ１３からＩＡＭＳ５０に、要求されたｅメールアドレスおよび選択されたオプションなどの情報とともに、新規アカウントに対する要求を送信する。ＩＡＭＳは、それがインターネットアカウントをセットアップしてよい加入者に対応して、加入者管理者システム（ＳＭＳ）６０から得られるスマートカード番号のリストに付き合わせて加入者のスマートカードをチェックする。それから、ＩＡＭＳは、インターネットアカウントをセットアップするためにＩＳＰに要求を送信する。いったんアカウントがセットアップされると、ＩＳＰは、パスワードとともにＩＡＭＳに肯定応答を戻す。パスワードは、当初、ＳＭＳによって定められるが、後に加入者によって修正されてよい。ＩＡＭＳアカウント情報（パスワード，ｅメールアドレス、およびインターネットパラメータ）が、加入者のスマートカード番号とともに、ＩＡＭＳに記憶される。ＩＡＭＳは加入者に、自分のアカウントがセットアップしたことを知らせる。それから、加入者は、メールサーバ２８に、およびメールサーバ２８からメールを送信、受信することができる。
【００３６】
ＩＡＭＳの主要な構成要素は、図６に示されている。ＩＡＭＳの主要な機能は、以下の通りである。
・スマートカード番号などの加入者パラメータにリンクされるｅメールアカウントパラメータの集中化したリストの維持。
・ＳＭＳの要求時における、加入者用のインターネットサービスへのアクセスの許可または拒絶。
・加入者の要求時のインターネットアカウントのカスタマイズ（対応）。
・ｅメールユーザが、イベントを登録し、イベント時にｅメールによって警告を受けることができるリマインダサービス。
・ＩＡＭＳコンテンツの更新を、ＩＳＰなどの関連サーバにコピーできるようにする複製サービス。
【００３７】
ＩＡＭＳに対して中心にあるのは、記憶手段７２に記憶されるインターネットサービスおよびｅメールアカウント用の加入情報を含む、関連データベース管理システム（ＲＤＢＭＳ）７０である。ＳＭＳ通信インタフェース７４により、ＩＡＭＳは、ＳＭＳと通信することができ、その結果ＩＡＭＳは、メールサービスへのアクセスを許可または拒絶された加入者の詳細で更新されてよい。対応サーバ７６は、加入者が、自分のｅメールアカウントを管理し、カスタマイズできるようにする。リマインダサービス７８によって、加入者は、イベントのリストを管理できる。イベントは、加入者のｅメールアカウントに関係する。加入者はイベントを登録し、自動的に作成されるｅメールを介してイベントの所定日数前に、自動リマインダを受信してよい。Ｅメール通知通信インタフェース８４によって、ＥＭＮＳ６２は、架空通知メッセージを送信するために、ＩＡＭＳ ＲＤＢＭＳ７０での加入者の通知優先を検索できるようにする。サポートサーバ８０は、管理者が、ＩＡＭＳ内の加入者またはｅメールユーザの存在およびステータスをチェックできるようにする。複写サービス８２は、ＩＡＭＳ ＲＤＢＭＳ７０のコンテンツの更新をＩＳＰアカウント管理システムにコピーする。
ＩＡＭＳに受信機／デコーダ１３から送信される要求は、ゲートウェイ５８によって、（ｅメールアカウント管理用の）対応サーバおよび（リマインダイベントを管理するための）リマインダサーバなどのＩＡＭＳの適切な部分に向けられる。
【００３８】
前述されたインターネットアクセスシステムは、放送サービスプロバイダが、インターネットサービスを提供できるようにもする。システムのオペレータは、インターネットアカウントを、インターネットサービスプロバイダとは無関係に維持し、その結果、オペレータは、ある特定のインターネットプロバイダに関連付けられない。放送サービスへの加入と、インターネットへの加入をともにリンクすることによって、アカウントが別個に管理され、加入者が２つのサービスにともに請求書を作成発行されるケースと比較して、関与する処理の量を削減してよい２つのサービスに対するアカウントが共に管理される。
【００３９】
ＩＡＭＳの追加詳細は、本出願の名称で「インターネット加入者管理（Ｉｎｔｅｒｎｅｔ Ｓｕｂｓｃｒｉｂｅｒ Ｍａｎａｇｅｍｅｎｔ）」と題され、その主題がここに参照して組み込まれる同時係続出願に記述される。ｅメール通知システムの更なる詳細は、本発明の名称で「Ｅメールと共に使用するための方法および装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ ｕｓｅ ｗｉｔｈ Ｅ−ｍａｉｌ）」と題され、その主題が参照してここに組み込まれる同時係続出願に記述される。
【００４０】
受信機デコーダ１３がインターネットイネーブルされていないケースでのインターネットアクセスシステムの構成を、ここで図７から図１０に関して説明する。その全体が図５に図示され、一定の態様がさらに詳細に描かれているシステムの一部を示す図７を参照すると、受信機／デコーダ１３は、装置にＩＳＰ２６との直接通信に必要なトランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）が備えられていない前述された型のものである。したがって、通信は、ＤＳＴＢゲートウェイ５８を介して起こる。対応サーバ７６およびリマインドサーバ７８は、ＩＡＭＳ５０の別個の部分として図中に示され、実施形態では、データは別個の線路７６ａと７８ａを介して適宜にそれぞれに送られる。
【００４１】
したがって、実際には、受信機／デコーダ１３とアクセスされることが所望される任意のリモートサーバ間の任意の通信で重要な４つのサブシステムがあることが理解されるだろう。これらは、受信機／デコーダ１３自体、ＮＡＳ５６、ゲートウェイ５８、および実施形態の中では対応サーバ７６、リマインドサーバ７８、またはメールサーバ６４の内のいずれか１つであってよいリモートサーバである。ＰＳＴＮ２４は、実際にはデータトランスペアレントである。実施形態では、メールサーバ６４は、インタフェース６６およびＩＳＰ２６を介してアクセスされるが、これが当てはまる必要はなく、メールサーバ６４はゲートウェイ５８から直接的にアクセスできるだろう。さらに、図中では単一装置として図示されているが、メールサーバ６４は、第１が（例えば、ＳＭＴＰサーバであってよい）ｅメール送信用、および第２が（例えば、ＩＭＡＰサーバであってよい）ｅメール受信用の２つの別個の装置から成り立ってよい。このような構成では、ゲートウェイ５８は、２つの別個のポートを介してメールサーバを備える２つの装置と通信してよい。
【００４２】
前述された４つのサブシステムの内のそれぞれによって処理される異なるプロトコルレベルが、ここで図８に関連して説明されるだろう。図から分かるように、受信機／デコーダ１３は、以下のような４つのプロトコルレベル（最高レベルが先）を有する：（アプリケーション依存であるだろう）アプリケーションレベルプロトコル、および例えば、ＳＭＴＰ、ＩＭＡＰ等であってよい；ゲートウェイプロトコル（これは、受信機／デコーダ用に使用されるレベルである―さらに詳しく後述されるようなゲートウェイ通信）；ｖ２２またはｖ４２ｂｉｓなどのＰＰ４プロトコルおよびモデム層。これら後者の２つの層の動作は、当業者に周知だろう。
【００４３】
ＮＡＳ５６は、単一プロトコル層で機能し、（ＰＳＴＮ２４全体で通信するために使用される）モデム層をインターネットプロトコルＴＣＰ／ＩＰに変換するために効果的である。
ゲートウェイ５８は、３つの作動できるプロトコル層（再び、最高レベルが先）、すなわち、ゲートウェイプロトコル層、ＰＰ４プロトコル層、およびＴＣＰ／ＩＰを有する。
最終的に、リモートサーバは、通常、アプリケーションレベルプロトコルでの上位層およびＴＣＰ／ＩＰプロトコルでの下位層という２つのプロトコルを有するだろう。
【００４４】
したがって、ゲートウェイプロトコルは、ゲートウェイ５８が、メッセージに応え、適切な場合には、データの意図された受け取り人を特定し、データをその受け取り人に転送することができるようにする。プロトコルは、受信機／デコーダ１３が、多様なゲートウェイ５８／リモートサーバ動作も開始できるようにする。実施形態では、ゲートウェイ５８は、メールサーバ６４にＳＭＴＰデータまたはＩＭＡＰデータを向けること；データを、新しいアカウントの作成に備える要求を含んでよい対応サーバ７６に向けること；データを、イベント登録に対する要求を含んでよいリマインダサーバ７８に向けること；メールサーバ６４のいずれか１つから受信されるデータに基づいて受信機／デコーダ１３に送信されるべきメッセージを構築することを担当し、対応サーバ７６またはリマインダサーバ７８、およびこのような構築されたメッセージを処理する。さらに、ゲートウェイは、受信機／デコーダ認証機能を実行するための能力を有する。
【００４５】
ここでは、受信機／デコーダ１３とゲートウェイ５８の間の低レベル通信を説明する。第１ステップでは、モデム通信が受信機／エンコーダ１３とＰＳＴＮ２４上のＮＡＳ５６の間に確立される。例えば、ｖ２２またはｖ４２ｂｉｓなどの任意の適切なモデムフォーマットが使用される。この時点で、「チャット」シーケンスは、通信チャネルを完全に確立するために、受信機／デコーダ１３とＮＡＳ５６の間のモデムレベルで発生する。それ以降、ＮＡＳ５６は、ＴＣＰプロトコルレベルで、ゲートウェイ５８との接続チャネルを確立する。このイベントに続いて、ゲートウェイ５８によってトークンが受信機／デコーダ１３に送信され、このトークンは事前に指定された文字シーケンスである。このようなトークンの受信機チャネルによる受信は、それに、ゲートウェイ５８の存在およびゲートウェイプロトコルレベルでの受信機／デコーダ１３とゲートウェイ５８間の通信チャネルが、それによって確立されることを知らせる。
確立されたゲートウェイプロトコル通信チャネルは、実際には、受信機／デコーダ１３の支配下にある。メッセージ交換が発生する前にチャネルを要求しなければならないのは、受信機／デコーダである。さらに、（後述される）切断手順は、チャネルを閉じるために受信機／デコーダ１３によって始められる。
【００４６】
本実施形態では、ゲートウェイプロトコルが、対応するリモートサーバとの単一ＴＣＰチャネルの確立を可能にすることが注記されなければならない。言い替えると、本実施形態では、受信機／デコーダ１３は、任意の一時点に複数のリモートサーバに接続することはできない。しかしながら、受信機／デコーダ１３は、それとゲートウェイ５８間でフレッシュな通信チャネルを確立することを必要とせずにさまざまなリモートサーバに対して接続を確立し、解放してよい。
さらに、実施形態では、ゲートウェイプロトコル層は、下部レベルプロトコル（モデム／ＴＣＰ）がデータの移送を保証し、上部レベルプロトコル（アプリケーションプロトコル）がエラー処理を実行するために、エラー回復機能を実行していないことが注記されなければならない。
【００４７】
ゲートウェイプロトコルでの通信の一般的なメッセージ構造を、ここで記述する。各メッセージ構造は、以下のフィールドを含む。
｛プロトコルバージョン｝｛コマンド識別子｝｛データ長｝［パラメータ］
この場合、｛．．．｝は必須フィールドを示し、［．．．］は任意フィールドを示す。
メッセージ構造は、メッセージが受信機／デコーダ１３から発出するのか、ゲートウェイ５８から発出するのかに関係なく同じである。フィールドは、最初に最上位ビットで２進符号化される。
プロトコルバージョン（ＰＲＴ）フィールドは、プロトコルバージョンを特定する単一バイトを備える。
コマンド識別子（ＣＩ）フィールドは、２バイトを備え、表されるメッセージの種類を特定する。多様な種類のメッセージが、下記に概略されるデータ交換イベント説明から明らかになるだろう。
データ長（ＤＬ）フィールドは、長さが２バイトで、（存在する場合には）付加されるパラメータフィールドの全体的な長さを特定する。これが、パラメータフィールドが可変長であることを可能にする。付加されるパラメータフィールドがない場合には、このフィールドはゼロ値を含むだろう。
パラメータフィールドは、ＴＬＶ形式（型長さ値）で符号化され、メッセージに関連付けられるあらゆる必要なパラメータを含む。個々に、あるいはメッセージの種類に依存して組み合わせて使用されてよい３つのカテゴリのパラメータがある。言い替えると、メッセージの種類が、どのパラメータフィールドが存在するのかを定める。また、一定のメッセージ（例えば、接続がリセットされる（ＭＧ＿ＲＣＮＸ）ことを命令するメッセージ）が、関連付けられたパラメータを有さないことも理解されるだろう。
【００４８】
第１種のパラメータ（ＲＥＭＯＴＥ＿ＳＥＲＶＥＲ）はリモートサーバを特定し、特定されるサーバがメールサーバ６４のＳＴＭＰ部分であるのか、メールサーバ６４のＩＭＡＰ部分であるのか、対応サーバ７６、またはリマインダサーバ７８であるのかを示す整数を含む。実施形態では、このパラメータの長さは２バイトである。修正では、パラメータが、その他のまたは追加のサーバを特定するために使用できるだろう。
【００４９】
第２種のパラメータ（ＢＯＤＹ）は、重要なリモートサーバから受信されるまたは重要なリモートサーバに送信されるデータを含むために使用される。このパラメータは、データ長フィールドによって定められるように可変長であり、このためデータパッケージが所定の長さである必要がないことを示す。このパラメータの最大長は事前に定義される。
【００５０】
第３種のパラメータ（ＥＲＲＯＲ＿ＣＯＤＥ）は、エラー状態を特定するために使用される。これは、例えば、ゲートウェイがいつ指定されたリモートサーバとの接続を開くことができないのか、いつリモートサーバとの接続が失われたのか、いつ受信機／デコーダ１３から受信されたメッセージでエラーが検出されるのか、いつ受信機／デコーダ１３からの命令に続いてリモートサーバからデータが受信されなかったのか、またはいつ認証が失敗したのかを示すために使用されてよい。実施形態では、このパラメータの長さは２バイト長である。
修正では、認証詳細を含むために使用される第４種パラメータがあってよい。
【００５１】
ゲートウェイプロトコルレベル通信チャネル上の通常のダイアログを表す典型的なデータ交換シーケンスを、ここで図９に関して説明する。これは、ある時間期間で（時間は、ページを下るにつれて増す）ゲートウェイ５８と選択されたリモートサーバの間で発生する対応するイベントとともに、受信機／デコーダ１３とゲートウェイ５８の間のメッセージを図で示す。
【００５２】
図示されている第１イベントシリーズ（ｅ１）は、受信機／デコーダと指定されたリモートサーバ間のゲートウェイプロトコルレベル接続手順である。受信機／デコーダ１３は、２つのパラメータ、つまり、それがダイアログを実施することを所望するサーバを指定するＲＥＭＯＴＥ＿ＳＥＲＶＥＲパラメータと、（存在する場合は）リモートサーバにアドレス指定されるデータをカプセル化するＢＯＤＹパラメータを含む接続（ＭＧ＿ＣＮＸ）を要求するメッセージ１０００を送信する。これが、ゲートウェイに、図において接続１００１として集合的に示される２つのタスク、つまり適切なリンクを介して指定されたリンクとの接続を確立させ、そのリンクを介して指定されたサーバにメッセージＢＯＤＹパラメータ内に含まれる（存在する場合）データを送信させるというタスクを実行させる。
【００５３】
前記シーケンスに続いて、リモートサーバは、受信機／デコーダ１３への前方への伝送のために、データ１００２をゲートウェイ５８に送信する。ゲートウェイは、このデータを含む単一パラメータフィールド、つまりＢＯＤＹを有する「リモートサーバとのデータ交換」（ＭＧ＿ＲＥＭＯＴＥ）メッセージ１００３の中でこれを符号化し、メッセージを受信機／デコーダ１３に送信する。接続はそれにより確立される。
【００５４】
図示される第２イベントシリーズ（ｅ２）は、典型的なデータ交換シーケンスである。シーケンスは、フィールドパラメータＢＯＤＹ内のサーバを宛先とするデータを含む「リモートサーバとのデータ交換」（ＭＧ＿ＯＴＨＥＲ）メッセージの受信機／デコーダ１３による送信で開始する。理解されるように、受信機／デコーダ１３は、任意の一時点で１つのリモートサーバと通信するだけであるため、サーバが接続メッセージ（ｅ２）によってすでに指定されるので、それは通常のデータ交換中に指定される必要はない。ゲートウェイ５８がこのデータ交換メッセージ１００４を受信すると、それはその中のデータを、１００５と示される通信の中のリモートサーバに渡す。
それ以後、リモートサーバは、前述されたように、（１００６、１００７と示される）受信機／デコーダにデータを送信する。
【００５５】
実施形態の追加の特徴を、ここで１００８ａ、１００８ｂおよび１００９と示される通信に関して説明する。ゲートウェイ５８から受信機／デコーダ１３に送信される型の「リモートサーバとのデータ交換」（ＭＧ＿ＲＥＭＯＴＥ）メッセージは、最小データパケットサイズを含む。したがって、所定の最小量のデータがリモートサーバから受信される（実際には最小データ量スレッショルド）まで、あるいはリモートサーバからの最終データの受信から所定の時間が経過する（実際には、タイムアウト）まで、ゲートウェイ５８は、受信機／デコーダ１３にメッセージを送信しないだろう。このようにして、通信１００８ａはリモートサーバからゲートウェイ５８へのデータ転送を表すが、このデータの量は所定スレッショルドより低いため、この時点では受信機／デコーダ１３にメッセージは送信されない。次に、追加データ転送１００８ｂは、リモートサーバからゲートウェイ５８へ発生する。この転送の結果、ゲートウェイに十分なデータが通信され、そのためそれはデータシーケンス１００８ａ、１００８ｂの両方を含むデータ交換メッセージ１００９を送信する。同様にして、いったんリモートサーバからゲートウェイ５８によって受信されるデータの量が最大量を超えると、データ交換メッセージは受信機／デコーダ１３に送信される。このような場合、リモートサーバとゲートウェイ５８間での単一データ交換シーケンスから、ゲートウェイ５８と受信機／デコーダ１３間の複数のメッセージが生じる可能性がある。
実施形態では、タイムアウト期間は２００ミリ秒（ｍｓ）であり、最小データ受信スレッショルドは１２８バイトであり、最大データ受信スレッショルドは５１２バイトである。
【００５６】
図中に示されていないが、ゲートウェイ５８が、実施形態では５秒である所定のタイムアウト期間内にリモートサーバからデータを受信していないということが生じる場合がある。このような場合、ゲートウェイは受信機／デコーダ１３に、ＥＲＲＯＲ＿ＣＯＤＥ型のパラメータフィールドを含む「ゲートウェイによるエラー検出」（ＭＧ＿ＥＲＲＯＲ）メッセージを送信し、このフィールドのコンテンツがこのようなイベントの発生を指定する。受信機／デコーダ１３は、ゲートウェイ５８にリモートサーバとのＴＣＰ接続を閉じさせる「通信リセット」（ＭＧ＿ＲＣＮＸ）メッセージの送信を含むことがある、それが講じることを望むあらゆる追加動作の責任を負う。
【００５７】
前記に予示されるように、類似したエラーメッセージが、リモートサーバとの接続を開くことができない、リモートサーバとの接続の損失、あるいはリモートサーバからの誤ったメッセージなどのそれ以外のイベントの後に続く可能性がある。後者のケースでは、これは、未知の型の、不正確な長さの、適用不可の値の、あるいは未知のプロトコルバージョンを有する、ゲートウェイ５８によるリモートサーバからのデータの受信を含むことがある。
【００５８】
図９を参照して、リモートサーバからの切断のイベント（ｅ３）をここで説明する。このイベントは、「切断」（ＭＧ＿ＤＣＮＸ）メッセージ１０２０を送信する受信機／デコーダ１３によって開始される。このメッセージは、ＢＯＤＹパラメータ内でリモートサーバに渡されるべきデータを含んでよい。このコマンドおよびデータ１０２１は、リモートサーバに渡され、その後、ゲートウェイ５８は、肯定応答および存在する場合には応答データ１０２２を待機する。その後で、ゲートウェイ５８はリモートサーバ（１０２３）から切断し、存在する場合、受信されたデータを含むメッセージ１０２４を受信機／デコーダ１３に送信する。低プロトコルレベルの図には示されていないが、受信機／デコーダ１３は、それからモデムレベルでの切断を閉じてよい。ゲートウェイ５８は、その後、ＴＣＰ接続が閉じられる旨をＮＡＳ５６によって通知されるだろう。
【００５９】
ゲートウェイプロトコルによって備えられる認証プロセスを、ここで図１０に関して説明する。これは、通信チャネルの確立前に、多様なサービス、たとえば対応サービスのために必要とされることがある。ゲートウェイ５８は、サーバがアクセスの前に認証を必要とする情報を含み、それがこのようなサーバのために「接続要求」（ＭＧ＿ＣＮＸ）メッセージ１１００を受信するとき、それは「認証要求」（ＭＧ＿ＡＵＴＨＥＢ＿ＲＥＱ）メッセージ１１０１で応答する。このような認証要求メッセージは、付随するパラメータを有していない。受信機／デコーダ１３は、それ以降、適切な「認証」メッセージ１１０２で応答しなければならない。以下により完全に述べられるように、このメッセージは、例えば、スマートカード番号である場合がある認証データを含む関連付けられたパラメータを有する。認証データは、ＢＯＤＹ型パラメータの中で渡されてよいか、あるいは修正の中で独自のパラメータ型を有してよい。
【００６０】
ゲートウェイ５８が、認証詳細が正しいと宣言すると、認証は無事終了し（図ではイベント１１０３で示される）、ゲートウェイ５８が指定されたリモートサーバとの接続１１０４を確立する。ゲートウェイ５８は、接続の開放に応えてリモートサーバから受信されるあらゆるデータ１１０５を含むであろうデータ交換メッセージ１１０６を送信することによって認証が無事終了することを報告する。認証が失敗する場合、前記に概略されたように、このような失敗を示すパラメータを含むエラーメッセージ（ＭＧ＿ＥＲＲＯＲ）が送信される。
【００６１】
図５に示されるシステムに戻ると、受信機／デコーダ１３からのインターネットサービス等のアクセス用の２つの異なった種類の「アカウント」、つまりいわゆる「接続アカウント」およびいわゆる「ディレクトリアカウント」を特定することが可能である。あらゆる接続アカウントの内で、複数のディレクトリアカウントが存在する可能性がある。
【００６２】
接続アカウントは、加入者がオペレータネットワークにアクセスしてよい基礎を提供する。これはさらに詳しく後述されるように複数の接続プロトコルと関連付けられてよいが、加入者はオペレータごとに単一の接続アカウントを割り当てられるだろう。このようなアカウントの認証を発生させる方法はネットワークレベルであり、さらに詳細に後述されるだろう。
【００６３】
自分の接続アカウントによるユーザログイン時の手順を、ここで説明する。理解されるように、ログイン時に供給される識別データは、ユーザが、受信者によって特定できるようにするために一意でなければならない。実施形態では、これは、少なくとも部分的に、ユーザの装置のスマートカード番号から引き出されるいわゆるＭＳＤ番号の使用によって達成される。さらに、ログイン時、ユーザは、例えば、ユーザがコンピュータ（例えば、Ｃａｎａｌ＋の製品であるＭｅｄｉａ Ｗｅｂ ＰＣ）と関連付けられるダイヤルアップモデムを介してアクセスを試みるのか、それとも一般的に「セットトップボックス」と呼ばれている装置のような受信機／デコーダ装置の種類を介してアクセスを試みるのかに応じて変化する可能性がある通信プロトコルを指定しなければならない。使用されるプロトコルは、例えば、ダイヤルアップモデムに対してはＰＡＰ、ＣＨＡＰまたはＰＰＰである可能性がある。
【００６４】
したがって、ログイン情報は、ユーザのＭＳＤ番号の内、ユーザ端末の種別を特定するフィールド、活用されるデータ戻りの種類を指定するフィールド、クライアントバージョン番号を示すフィールド、および該当する場合、いわゆるクライアントのＲＡＤＩＵＳドメイン名を含む。ログインは、パスワードも含むだろう。実施形態では、この情報は以下のようにフォーマットされる。
【００６５】
ログイン＝
｛ｍｓｎ＿ｎｕｍｂｅｒ｝｛端末種別｝｛ｒｅｔｕｒｎ＿ｔｙｐｅ｝｛バージョン｝｛＠ＲＡＤＩＵＳ＿ｄｏｍａｉｎ＿ｎａｍｅ｝
前記フィールドのそれぞれを、ここで更に詳細に説明する。
ｍｓｎ＿ｎｕｍｂｅｒフィールド自体は、フィールドの以下の文字列から成り立つ。
｛ｍｓｎ＿ｎｕｍｂｅｒ｝＝｛ＲＳＭＣ｝｛ＲＳＭＮ｝｛ｃｈｃｋ｝
第１のＭＳＮデータフィールドは、スマートカードの型を特定する取外し可能機密保護モジュール製品コード（ＲＳＭＣ）を含む。型のこの識別は、カードの技術的な構成、製造メーカー、およびカードをユーザに提供した商業的なオペレータの１つまたは複数の態様を示すデータを含んでよい。実施形態では、このフィールドは長さが２バイトであり、４個のディジットを含んでいてよい。
第２のＭＳＮデータフィールドは、取外し可能機密保護モジュール番号（ＲＳＭＮ）を含む。このフィールドは、使用中のスマートカードを特定するコードを含む。このようなコードは、好ましくはスマートカード供給業者によって事前にプログラミングされ、スマートカード、したがってユーザに一意であり、それによりユーザの識別を可能にする。実施形態では、このフィールドは、長さが４バイトであり、１５個の数字を含んでよい。
【００６６】
最終フィールドは、任意の既知の方法によって計算されてよいチェックデータ（ｃｈｃｋ）を含み、例えば、それはチェックサムであってよい。
ｔｅｒｍｉｎａｌ＿ｔｙｐｅフィールドが、ここで説明されるだろう。前述されたように、端末はいわゆる「セットトップ」ボックスの種類であってよいか、あるいはモデム機構を有するコンピュータであってよい。フィールドは、ＰＣ型端末の場合値「Ｐ」を取り、セットトップボックス端末型の場合、値「Ｔ」を取るだろう。フィールドが、より正確に端末型を指定し、このようなフィールドの提供が、追加のおよび代替の端末型の定義による将来の拡張も可能にすることが理解されるだろう。
【００６７】
ｒｅｔｕｒｎ＿ｔｙｐｅフィールドは、戻りデータをユーザに送信する方法の指定を可能にする。実施形態では、フィールドは、すべての戻りデータがモデムを解して送られなければならないときには値「Ｍ」を取り、データ戻りが衛星チャネルとモデムチャネルの両方で発生しなければならないときには値「Ｓ」を取る。再び、戻りデータを提供する方法の将来の拡張の可能性が提供される。
バージョンデータフィールドは、バージョンデータを受信機／デコーダ１３からネットワークに渡すことができるようにする。実施形態では、これはデフォルトとして０１で設定される。
オプションフィールドのＲＡＤＩＵＳ＿ｄｏｍａｉｎ＿ｎａｍｅは、クライアントの認証要求を、ゲートウェイのこのような第３者による、例えば、別のサービスプロバイダへの提供を可能にする第３部認証サーバに送ることができるようにする。
【００６８】
接続プロファイルは、実施形態では、１４英数字という最大長を有するパスワードフィールドも含むだろう。
ここでディレクトリアカウントの説明に戻ると、これは、例えば識別付き代理、メール、ニュース等の個々のインターネットサービスのアクセスの基礎を提供する。加入者のディレクトリアカウントは、自分の接続アカウントにリンクされる。しかしながら、接続アカウントと区別して、ディレクトリアカウントの認証はアプリケーションレベルで発生する。
【００６９】
前述されたように、ディレクトリアカウントは、受信機／デコーダ１３からの種々のインターネットサービスへのアクセスを可能にする。ディレクトリアカウントは、通常、以下から成り立つ。
−識別子およびパスワード
−１つまたは複数のいわゆる「ｅメールエイリアス」
−適切なケースでは、加入者に提供されるサービスに関するその他のデータ
識別子は（適切なケースではパスワードと組み合わされて）、例えば加入者のメールボックスへのアクセスなどの多様なＩＳＰサービスの加入者によるアクセスを制御するために使用される。その他の例は、私用ウェブサイト、ディレクトリへのアクセス、サービス、証明書、「メールグループ」登録等へのアクセスの制御を含む。
識別子は、フォーマット「ｉｄｅｎｔｉｆｉｅｒ＠ｄｏｍａｉｎ」でｅメールアドレスを受信するためにも使用されてよく、その場合加入者が、識別子によって特定されるメールボックスにアクセスするときに自分のパスワードを使用する必要がある場合がある。
ｅメールエイリアスは、「ａｌｉａｓ＠ｄｏｍａｉｎ」へのメッセージアドレスのｅメールサーバによるｅメール受信の機構に備える。
【００７０】
実施形態では、複数のディレクトリアカウントが、単一接続アカウント（いわゆる「家族加入」）に関連付けられてよい。このような場合、各識別子およびエイリアスが一意でなければならないことが注記される必要があるが、ユーザは、最初に、各接続アカウントごとに可能であるディレクトリアカウントの数を指定できる可能性がある。
【００７１】
用語
以下の用語がここに使用される。
Ｅメールアドレス
Ｅメールアドレスは、ＥメールＩＤとドメイン名の２つのフィールドから構成される。ｅメールアドレスの形式は、ｍａｉｌ＿Ｉｄ＠Ｄｏｍａｉｎ＿Ｎａｍｅである。
Ｅメールアカウント
Ｅメールアカウントは、メールサーバがそのユーザのメッセージを処理する必要のあるユーザについての情報を提供する。
ＥメールＩｄ
ｅメールアドレスの接頭語である。ｅメールＩｄは、ドメイン名で一意でなければならない。
Ｅメール通知者
Ｅメール通知者システムにより、加入者（ＥＭＮ）に、彼らがメールボックスに新しいｅメールを受信するとすぐに通知することができる。短いメッセージは、電波放送媒体上で彼らのＳＴＢに送信される。
インターネットアカウント管理システム
加入者ＴＶアカウント管理パラメータおよび関連するＥメールアカウントシステム（ＩＡＭＳ）パラメータを管理するシステム。
メールボックス
ＩＭＡＰ送達用に記憶されるメッセージは、メールボックス内に保持される。メールサーバ上のメールボックスは、メールボックスＩｄによって一意に特定されなければならない。異なるドメイン名をホストするメールサーバは、ｅメールＩｄがメールサーバで一意であると考えることはできないため、メールボックスＩｄはＥメールアドレスでなければならない。
メールサーバ
他のメールサーバとｅメールを交換し、メッセージを受け入れ、メールクライアントに送達するプログラム。
メッセージ待ち行列サーバ（ＭＱＳ）
メッセージ管理システム。
対応サーバ
加入者が、ｅメールアカウントを自分達自身で作成、カスタマイズできるようにする。
リマインダサービス
ユーザが、イベントを登録し、自動メールを介して自動リマインダを受信できるようにする。
セットトップボックス
デジタルビデオ放送規格、ＣＡＮＡＬ＋ＴＥＣＨＮＯＬＯＧＩＥＳ仕様に従って、完全に組み立てられ、使用準備が完了している（ＳＴＢ）デジタル復号ハードウェア。エンドユーザがテレビ番組およびサービスにアクセスできるように、伝送済みのビデオ、オーディオ、アプリケーション、およびデータストリーム用のデジタルデコーダとして使用される。
スマートカード
１つまたは複数の商業的なオペレータの秘密鍵、およびその他のアクセス情報を電子的に記憶するカード。
加入者
加入者はＴＶアカウント（つまり、スマートカード番号）に関係する。
加入者管理システム（ＳＭＳ）
加入者に関係するデータを管理するシステム。
ユーザ
ユーザはＥメールアカウントに関係する。単一加入者に複数のユーザがいる可能性がある。
【００７２】
ここに使用される用語「受信機／デコーダ」または「デコーダ」は、例えば、なんらかの他の手段によって放送または伝送されてよい、テレビおよび／または無線信号などの符号化されるか、符号化されていない信号のどちらかを受信するための受信機を言外に意味する。この用語は、また、受信された信号を復号するためのデコーダも言外に意味する。このような受信機／デコーダの実施形態は、例えば「セットトップボックス」内で受信された信号を復号するための受信機に一体化されたデコーダを含んでよく、このようなデコーダは、物理的に別個の受信機と組み合わされて機能するか、あるいはこのようなデコーダは、ウェブブラウザなどの追加機能を含むか、あるいはビデオレコーダまたはテレビなどのその他のデバイスと統合されている。
本発明が、純粋に例によって前述され、詳細の修正が発明の範囲内でなされうることが理解されるだろう。
説明、および（適切な場合）クレームおよび図面中に開示される各特徴は、独立して、または適切な組み合わせで提供されてよい。
クレーム中に示される参照番号は例示としてのみであり、クレームの範囲に制限的な影響を及ぼさないものとする。
【技術分野】
【０００１】
本発明は、受信機／デコーダなどのユーザ装置と、例えばインターネットアカウント管理システムまたはインターネットサービスプロバイダであってよいリモート装置の間での通信のための方法および装置に関する。
受信機／デコーダは、アナログ形式またはデジタル形式で伝送されてよい、テレビ信号などの信号を受信および／または復号するために使用される。デジタル伝送のケースでは、デジタルチャネルは、送信機終端でデジタルデータストリームに符号化され、デジタルセットトップボックス（ＤＳＴＢ）内または統合型デジタルテレビ型のどちらかであってよい受信機／デコーダを使用して受信機終端で復号される。アナログ伝送のケースでは、受信機／デコーダは、伝送済み信号を、テレビ画面で表示されてよいフォーマットに変換するために加入者で提供されてよい。
【０００２】
受信機／デコーダは、典型的には、アプリケーションとして知られているプログラムが実行されてよいプロセッサを含む。受信機／デコーダで実行されてよいアプリケーションの例は、加入者が受信機／デコーダによってインターネットにアクセスできるようにする、インターネットアクセスアプリケーションである。
受信機／デコーダは、低い単位費用を確実にするために相対的に簡略な構造となる傾向がある。このために、インターネットなどのリモートネットワークと通信するために受信機／デコーダをセットアップするのが困難になる場合がある。特に、インターネットとの通信は、受信機／デコーダ上で実現するのが困難である場合があるインターネットプロトコルの使用および認証を必要とする。例えば、一定の受信機／デコーダは、インターネットへの直接的な接続に適したフォーマットでデータを出力できない可能性がある。このような受信機／デコーダが、「非ＩＰイネーブル済み」と呼ばれる。
【発明の概要】
【０００３】
本発明の第１態様は、ネットワークにアクセスを提供するために、受信機／デコーダとリモートサーバ間の通信を認証する方法を提供し、該方法は、該通信を認証するために該受信機／デコーダの識別子を使用することからなり、該識別子は放送サービスへのアクセスのために識別子に基づいている。
発明を使用することにより、受信機／デコーダとリモートサーバとの間の通信の認証は、受信機／デコーダが準備可能なアクセスを有する受信機／デコーダの一致の識別子に基づくことがあり、受信機／デコーダに対してなされた要求を削減することができる。受信機／デコーダには、多くの場合、放送サービスへのアクセス用の一意の識別子が提供され、その識別子が受信機／デコーダを識別する便利な手段を提供する。
【０００４】
好ましくは、識別子は、スマートカードなどの取外し可能な構成要素に記憶される。
好ましくは、識別子は、ネットワークログイン識別子とは無関係である。識別子は、ユーザが憶えるのを容易にするために、複雑な複数文字識別子である傾向があるネットワークログイン識別子より簡略である可能性があるため、これが受信機／デコーダの複雑度を削減できる。ログイン識別子の別の欠点とは、それらがときどき変化する可能性がある点、あるいはさまざまなサービスへのアクセスのために複数のものが必要とされる可能性がある点である。本発明は、受信機／デコーダによって供給される単一識別子を（リモートサーバ内で）変更可能ネットワーク識別子と、あるいは複数のネットワーク識別子と関連付けることができるようにする。この機能は個別に提供されてよい。
【０００５】
好ましくは、識別子は、スマートカードに一意の番号に基づく。ここに使用されているように、用語「スマートカード」は、任意のチップベースのカードデバイス、または例えばマイクロプロセッサおよび／またはメモリ記憶装置などの類似した機能と性能、処理の対象を含むが、独占的にそのようではない。この用語に含まれるのは、多くの場合ＴＶデコーダシステムで使用されるような鍵の形をしたデバイスなど、カードに代わる物理形式を有する装置である。
【０００６】
リモートサーバは、インターネットにアクセスするためであるか、あるいはそれはインターネットアカウント管理システム、あるいは例えば任意の形式のリモートネットワークにアクセスするためのそれ以外の任意の形のサーバであってよい。
ユーザ用のインターネットアカウントは、受信機／デコーダの識別子を使用するインターネットアカウント管理システムによって確立されてよい。アカウントを確立するために、受信機／デコーダの識別子は、インターネットアカウント管理システムによって、インターネットアカウントを確立してよい受信機／デコーダの識別子の記憶されているリストと比較されてよい。
【０００７】
リモートサーバは、データをインターネットサービスプロバイダに送信するための手段を備えてよく、該方法は、インターネットアカウントの詳細をインターネットサービスプロバイダに提供し、受信機／デコーダとインターネットサービスプロバイダ間で双方向データ経路を確立するステップを備える。
識別子は、受信機／デコーダとリモートサーバ間の通信のために使用されるデータ経路を特定するデータに伴われてよい。このようにして、受信機／デコーダは、通信のために使用される経路を指定することができる。例えば、衛星リンクが戻りチャネルのために使用されてよい。
【図面の簡単な説明】
【０００８】
【図１】典型的なデジタルテレビシステムのアーキテクチャを示す。
【図２】受信機／デコーダの概略図である。
【図３】インターネットアクセスシステムの概要を示す。
【図４】図３のユーザ装置内のソフトウェア層を示す。
【図５】インターネットアクセスシステムのアーキテクチャを示す。
【図６】インターネットアカウント管理システムの主要な構成要素を示す。
【図７】受信機／デコーダがＩＰイネーブル済みではない場合の、インターネットアクセスシステムの構成の一部を示す。
【図８】図７に図示されるシステムプロトコル層を示す。
【図９】図７のシステム内のユーザ装置とゲートウェイ間の通信のために適応されるプロトコルを図式で示す。
【図１０】図７のシステム内のユーザ装置とゲートウェイ間の認証関係通信のために適応されるプロトコルを図式で示す
【発明を実施するための形態】
【０００９】
好ましい実施形態では、ログイン詳細は、以下の形式を取り、
ログイン＝｛スマートカード番号｝｛サービスの種別｝
その場合、サービスの種別（ＴＯＳ）は、データ通信がその上で発生することになるチャネル、例えば応答のカテゴリが衛星によって端末に送信されなければならないケースを指定してよい。
【００１０】
好ましい実施形態では、リモートサーバは、受信機／デコーダに、ネットワークプロトコルを有するネットワークへのアクセスを提供し、受信機／デコーダから出力されるデータは、受信機／デコーダから遠い場所でネットワークプロトコルに準拠するデータに変換される。このようにして、ネットワークプロトコルを備えていない受信機／デコーダも、依然としてネットワークと通信してよい。ネットワークは、例えば、インターネットでよく、ネットワークプロトコルは、例えば、トランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）であってよい。該遠い場所とは、例えば、インターネットアカウント管理システムを備えてよいオペレータであってよい。
【００１１】
好ましくは、データは、受信機／デコーダとリモートサーバ間のゲートウェイによって、ネットワークプロトコルに準拠する前記データに変換される。
好ましい実施形態では、ネットワークは、複数のリモートデバイスを備え、前記変換されたデータは、前記データに指定されるように、ゲートウェイによって前記リモートデバイスの内の１つに通信され、それにより受信機／デコーダと指定されたリモートデバイス間に通信チャネルを確立する。
【００１２】
第２態様では、本発明は、非インターネットプロトコルイネーブル済みユーザ端末から複数のインターネットプロトコルイネーブル済みリモートデバイスの１つにデータを通信する方法を提供し、該方法は、前記ユーザ端末から前記ゲートウェイへ前記非インターネットプロトコルを使用してデータを通信し、前記データがメッセージを含み、前記複数のリモートデバイスからの前記メッセージの宛先を指定するステップと、前記ゲートウェイで前記データを前記インターネットプロトコルを使用するデータに変換するステップと、前記インターネットプロトコルを使用する前記データを前記ゲートウェイから指定された宛先リモートデバイスに通信し、それによりユーザ端末と指定されたリモートデバイス間に通信チャネルを確立するステップとを備える。ユーザ端末は、受信機／デコーダであってよい。
【００１３】
また、提供されているのは、受信機／デコーダとリモートネットワーク間で通信する方法であって、そこではリモートネットワークと通信するために必要なプロトコルは、受信機／デコーダから遠い場所で実現される。
通信チャネルの終端を命令するメッセージが、非インターネットプロトコルを使用して、受信機／デコーダからゲートウェイに通信されてよく、ゲートウェイは、代わりに、インターネットプロトコルを使用して指定されたリモートデバイスに終端コマンドを通信する。好ましくは、受信機／デコーダの識別は、通信チャネルが確立する前にゲートウェイによって認証される。
【００１４】
第３態様では、本発明は、ネットワークへのアクセスを提供するために受信機／デコーダとリモートサーバ間の通信を認証するための装置を提供し、該装置は、通信を認証するために受信機／デコーダの識別子を使用するための手段（例えば、システム、サーバまたはゲートウェイ）を備え、該識別子は、放送サービスへのアクセスのために識別子に基づいている。識別子は、受信機／デコーダとリモートサーバ間の通信に使用されるデータ経路を特定するデータを伴ってよい。
リモートサーバは、ネットワークプロトコルを有するネットワークへのアクセスを、受信機／デコーダに与えてよく、前記装置は、受信機／デコーダから出力されるデータを、ネットワークプロトコルに準拠するデータに変換するための手段（例えば、システム、サーバまたはゲートウェイ）を備える。
好ましくは、装置は、受信機／デコーダとリモートサーバの中間のゲートウェイである。
好ましくは、ネットワークは複数のリモートデバイスを備え、前記ゲートウェイは、前記データに指定されるように、前記リモートデバイスの１つに変換されたデータを通信するように適応され、それにより、受信機／デコーダと指定されたリモートデバイス間の通信チャネルを確立する。
【００１５】
第４態様では、本発明は、非インターネットプロトコルイネーブル済みユーザ端末から受信されるデータを、複数のインターネットプロトコルイネーブル済みリモートデバイスの１つに通信するためのゲートウェイを提供し、該ゲートウェイは、
前記ユーザ端末からの前記非インターネットプロトコルを使用して通信されるデータを受信するための手段（例えば、入力）であって、前記データがメッセージを含み、前記複数のリモートデバイスからの前記メッセージの宛先を指定する手段と、
受信されたデータを、前記インターネットプロトコルを使用するデータに変換するための手段（例えば、変換器）と、
前記インターネットプロトコルを使用する前記データを、指定された宛先リモートデバイスに通信し、それによりユーザ端末と指定されたリモートデバイス間に通信チャネルを確立するための手段（例えば、出力）と、
を備える。
【００１６】
ゲートウェイは、それぞれのリモートデバイスへの接続のためにそれぞれ複数の入力／出力を備えてよい。
ゲートウェイは、通信チャネルの終端を命令するユーザ端末からのメッセージを特定するための手段（例えば、識別子）、および指定されたリモートデバイスに終端コマンドを送るための手段（例えば、出力）を備えてよい。
本発明は、実質的には添付図面に関して説明されるような、および添付図面の中に示されるような方法および装置も提供する。
ある態様の特徴は、他の態様に適用されてよい。同様に、方法特徴は、装置態様に適用されてよく、またその逆にも適用されてよい。
【００１７】
本発明の好ましい特徴は、ここでは、純粋に例によって、添付図面に関して記述される。
デジタルテレビシステム１の概要は、図１に図示される。本発明は、圧縮済みデジタル信号を伝送するために、既知のＭＰＥＧ−２圧縮システムを使用する主として従来のデジタルテレビシステム２を含む。さらに詳細には、放送センタ内のＭＰＥＧ−２圧縮機３がデジタル信号ストリーム（典型的には、ビデオ信号のストリーム）を受信する。圧縮機３は、リンク機構５によってマルチプレクサとスクランブラ４に連結される。
【００１８】
マルチプレクサ４は、複数の追加入力信号を受信し、トランスポートストリームをアセンブルし、圧縮済みデジタル信号を、言うまでもなく電気通信リンクを含む幅広い形式を取ることができるリンク機構７を介して、放送センタの送信機６に伝送する。送信機６は、アップリンク８を介して衛星トランスポンダ９に向かって電磁信号を伝送し、そこではそれらは電子的に処理され、概念上のダウンリンク１０を介して、従来は、エンドユーザによって所有あるいは賃貸される放物面反射器という形を取る、地上受信機１２に一斉送信される。地上放送、ケーブル伝送、結合された衛星／ケーブルリンク、電話網等のデータの伝送用のその他のトランスポートチャネルが、言うまでもなく可能である。
【００１９】
受信機１２により受信される信号は、エンドユーザによって所有または賃貸される統合型受信機／デコーダ１３に伝送され、エンドユーザのテレビセット１４に接続される。該受信機／デコーダ１３は、圧縮済みＭＰＥＧ−２信号をテレビセット１４用のテレビ信号に復号する。別個の受信機／デコーダが図１に図示されているが、受信機／デコーダもまた、統合型デジタルテレビの一部であってもよい。ここに使用されるように、用語「受信機／デコーダ」は、セットトップボックスなどの別個の受信機／デコーダ、およびそれと統合された受信機／デコーダを有するテレビを含む。
【００２０】
マルチチャネルシステムでは、マルチプレクサ４は、数多くの並列ソースから受信される音声およびビデオ情報を処理し、対応する数のチャネルに沿って情報を一斉送信するために送信機６と対話する。視聴覚情報に加えて、メッセージまたはアプリケーション、あるいはそれ以外の種類のデジタルデータが、伝送済みのデジタル音声ビデオ情報とインタフェースされるこれらのチャネルのいくつかまたはすべてに導入されてよい。
【００２１】
従来のアクセスシステム１５は、マルチプレクサ４および受信機／デコーダ１３に接続され、部分的には放送センタに位置し、部分的には受信機／デコーダ内に位置する。それは、エンドユーザが、１つまたは複数の放送供給業者からのデジタルテレビ放送にアクセスできるようにする。商業的なオファー（すなわち、放送供給業者により販売される１つまたは複数のテレビ番組）に関係するメッセージを解読することができるスマートカードを、受信機／デコーダ１３に差し込むことができる。受信機／デコーダ１３およびスマートカードを使用して、エンドユーザは、加入モードまたは有料視聴モードのどちらかで商業的なオファーを購入してよい。
【００２２】
前述したように、システムにより伝送される番組は、マルチプレクサ４でスクランブルされ、条件および暗号化キーが、アクセス制御システム１５によって決定される所与の伝送に適用される。このようにしてスクランブルされたデータの伝送は、有料テレビシステムの分野では周知である。典型的には、スクランブルされたデータは、データを逆スクランブルするための制御ワードとともに伝送され、制御ワード自体がいわゆる探索キーによって暗号化され、暗号化された形式で伝送される。
【００２３】
それから、スクランブルされたデータおよび暗号化された制御ワードは、暗号化された制御ワードを解読し、その後で伝送されたデータを逆スクランブルするために、受信機／デコーダに挿入されたスマートカードに記憶される探索キーに同等なものにアクセスできる受信機／デコーダ１３によって受信される。支払済みの加入者は、例えば、放送月次ＥＭＭ（資格管理メッセージ）の中で、伝送の表示を可能にするために暗号化された制御ワードを復号するために必要な探索キーを受信するだろう。
【００２４】
やはりマルチプレクサ４および受信機／デコーダ１３に接続され、再び、部分的に放送センタ内に位置し、部分的に受信機／デコーダ内に位置する対話型システム１６により、エンドユーザは、モデム送受信（ｍｏｄｅｍｅｄ）バックチャネル１７を介して多様なアプリケーションと対話できるようになる。モデム送受信バックチャネルは、条件付きアクセスシステム１５内で使用される通信にも使用されてよい。
【００２５】
受信機／デコーダ１３の物理インタフェースは、データをダウンロードするために使用される。図２を参照すると、受信機／デコーダ１３は、例えば、６台のダウンロードデバイス、つまり直列インタフェース３０、並列インタフェース３２、モデム３４、２台のカード読取り装置３６、およびＭＰＥＧフローチューナ３８を含む。
【００２６】
放送受信システムも、ウェブブラウジングおよびｅメールなどのインターネットサービスを提供するために使用される。受信機／デコーダ１３によって実行されるアプリケーションは、受信機／デコーダが、インターネットサービスにアクセスし、ウェブページおよびｅメールを、テレビセット１４上でまたは受信機／デコーダ１３に接続されるコンピュータを介して表示できるようにする。
【００２７】
図３を参照して、インターネットアクセスシステムの概要を説明する。（受信機／デコーダを含む）ユーザ装置２０は、公衆加入電話網（ＰＳＴＮ）２４を介してオペレータ２２と通信する。ユーザ装置は、オペレータ２２に対し、例えば、ある特定のウェブページまたはｅメールなどの一定のデータを送信されるようにという要求を送信する。オペレータはこの要求を受信し、要求をインターネットサービスプロバイダ（ＩＳＰ）２６に出力する。この要求に応えて、ＩＳＰは、インターネット２７から得られた要求されたウェブページ、またはＩＳＰで加入者を待機していたｅメールを備える可能性がある応答をオペレータに供給する。オペレータは、応答を、それが、例えば私用セクションとしてＭＰＥＧビットストリームに統合され、前述されたように送信機６によって伝送され、受信機１２によって受信される放送センタ２８に送達する。受信機／デコーダがＩＰイネーブルされている場合、つまりデータをインターネットから受信するためのプロトコルを備えている場合、情報はＭＰＥＧビットストリーム内で、つまりＩＰフォーマットでＩＰフレームとして伝送されてよい。受信機／デコーダがＩＰイネーブルされていない場合には、データは、例えば私用ＭＰＥＧセクションとして、なんらかの他の方法で送信される。ユーザ装置２０は、ＭＰＥＧビットストリームから応答を抽出し、それをテレビセットまたはコンピュータ画面上で表示する。代わりに、応答は、ＰＳＴＮ２４を介してユーザ装置２０に伝送されてよい。
【００２８】
ユーザ装置２０で利用されるソフトウェアレベルは、図４に図示される。アプリケーションレベルは、ＮｅｔｓｃａｐｅまたはＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒおよびＯｕｔｌｏｏｋ Ｅｘｐｒｅｓｓなどの商業的なアプリケーション、または受信機／デコーダで実行するように特に設計されるアプリケーションであってよい、ウェブブラウザおよびｅメールアプリケーションを備える。アプリケーションレベルの下には、ＨＴＴＰ、ソケット、ＴＣＰ／ＩＰ、ＰＰＰ／ＳＬＩＰ、およびドライバレベルがある。ドライバレベルは、ＰＣ上で従来動作しているブラウザアプリケーションと比較して、それがユーザ装置のモデムを介してＰＳＴＮ２４と通信するためのモデムドライバ、およびＭＰＥＧフローチューナ４０２８を介して通信するためのチューナドライバに分割されるという点で修正される。
【００２９】
ユーザ装置２０の多様な構成が考えられる。ある構成では、ＰＣは使用されず、ユーザソフトウェアのすべては受信機／デコーダ１３上で実行する。この構成では、受信機／デコーダ１３は、内蔵モデムを介して、または外部モデムおよびシリアルポートを介してのどちらかでＰＳＴＮ２４と通信する。受信機／デコーダ１３は、地上受信機１２からビットストリーム内のインターネット応答を受信できる。ユーザインタフェースは、遠隔制御装置またはキーボードおよび受信機／デコーダ１３に接続されているテレビセットによって提供される。この構成では、図４に示されるＴＣＰ／ＩＰレベルは省略されてよく、その場合、オペレータに位置するゲートウェイが、後述されるように必要なプロトコルを提供する。
【００３０】
別の構成では、その並列ポートによって受信機／デコーダ１３の並列ポート３２に（あるいは任意にその直列ポートによって受信機／デコーダ１３の直列ポート３０に）接続されるパーソナルコンピュータ（ＰＣ）が提供される。この場合、図４に図示されるソフトウェアレベルの上部は、ＰＣ上で実行し、ソフトウェアレベルの残りの下部は受信機／デコーダ１３上で実行する。ユーザインタフェースは、キーボードおよびＰＣに接続されるモニタによって提供される。
追加の構成では、ＰＣはＰＣの内蔵モデムまたは外付けモデムを介してＰＳＴＮ２４に接続される。この構成では、受信機／デコーダ１３は、別個に、またはそのＩＳＡまたはＰＣＩバスに接続される、ＰＣの付属またはプラグイン式のカードの形を取り、提供されてよい。
【００３１】
インターネットアクセスシステムのアーキテクチャは、図５に示されている。図５を参照すると、インターネットアカウント管理システム（ＩＡＭＳ）５０は、ウェブブラウジングおよびｅメールなどのサービスを提供するインターネットサービスプロバイダ（ＩＳＰ）２６にリンクされる。ＩＡＭＳ５０は、加入者を管理し、インターネットサービスへのアクセスを許可または拒絶するためにＩＡＭＳに要求を送信する加入者管理システム（ＳＭＳ）６０にもリンクされる。受信機／デコーダ１１３は、内蔵モデム、公衆加入電話網（ＰＳＴＮ）２４、ネットワークアクセスサーバ（ＮＡＳ）５６、およびゲートウェイ５８を介してＩＡＭＳに接続される。
【００３２】
ＳＭＳは、放送テレビサービスなどの許可および放送サービスに対する加入者の注文を管理する加入許可システム（ＳＡＳ）６１にも接続される。ＳＭＳは、並列でＳＡＳシステムおよびＩＡＭＳシステムを実行し、２つのシステム間の整合性を確実にする。ＳＭＳとＳＡＳとＩＡＭＳとの間の通信は、バッチファイルを使用するリアルタイムＴＣＰ／ＩＰリンクを使用して発生する。
【００３３】
ゲートウェイ５８により、加入者は、リアルタイムでインターネットサービスにアクセスできる。このようなサービスは、メールを送受するためのメールサービス、およびＩＳＰ２６によって提供されてよいそれ以外のサービス、ならびにＩＡＭＳによって提供される対応（ｐｒｏｖｉｓｉｏｎｉｎｇ）サービスおよびリマインダサービスを含む。機能上、ゲートウェイ５８は、単一モデム接続で多様な異なるシステムとの通信をイネーブルするメッセージルータである。受信機／デコーダにＩＳＰと通信するためのＴＣＰ／ＩＰプロトコルが備えられていない場合、ゲートウェイは、受信機／デコーダがＩＳＰと通信するために必要なプロトコルも提供する。それから、受信機／デコーダ１３は、図５の線５９で示されるように、ゲートウェイ５８を介してＩＳＰと通信する。受信機／デコーダに必要なプロトコルが備えられている場合、通信は、図５の破線５７で示されるように、ＩＳＰと直接的に発生することができる。ゲートウェイは通信サーバおよびｅメールディスパッチャを備える。
【００３４】
ＩＳＰインタフェース６６は、ＩＡＭＳ内で発生するユーザのアカウントに関係する各修正を、メールサービスなどのホストインターネットサービスを担当するＩＳＰ２６内のユーザアカウントに複製できるようにする。加入者アカウントに関係するすべての情報はＩＡＭＳ内に集中化され、ＴＶおよびインターネットパラメータの管理を確実にすることに注記する必要がある。ＩＡＭＳは、加入者管理システム（ＳＭＳ）６０とのそのインタフェースを通して、インターネットパラメータとＴＶパラメータ間の関係性も管理する。ＳＭＳ６０は加入者を管理し、加入者によるインターネットサービスへのアクセスを許可または拒絶するためにＩＡＭＳに要求を送信する。
【００３５】
ＩＡＭＳアカウントをセットアップするために、加入者は、最初に、受信機／デコーダ１３からＩＡＭＳ５０に、要求されたｅメールアドレスおよび選択されたオプションなどの情報とともに、新規アカウントに対する要求を送信する。ＩＡＭＳは、それがインターネットアカウントをセットアップしてよい加入者に対応して、加入者管理者システム（ＳＭＳ）６０から得られるスマートカード番号のリストに付き合わせて加入者のスマートカードをチェックする。それから、ＩＡＭＳは、インターネットアカウントをセットアップするためにＩＳＰに要求を送信する。いったんアカウントがセットアップされると、ＩＳＰは、パスワードとともにＩＡＭＳに肯定応答を戻す。パスワードは、当初、ＳＭＳによって定められるが、後に加入者によって修正されてよい。ＩＡＭＳアカウント情報（パスワード，ｅメールアドレス、およびインターネットパラメータ）が、加入者のスマートカード番号とともに、ＩＡＭＳに記憶される。ＩＡＭＳは加入者に、自分のアカウントがセットアップしたことを知らせる。それから、加入者は、メールサーバ２８に、およびメールサーバ２８からメールを送信、受信することができる。
【００３６】
ＩＡＭＳの主要な構成要素は、図６に示されている。ＩＡＭＳの主要な機能は、以下の通りである。
・スマートカード番号などの加入者パラメータにリンクされるｅメールアカウントパラメータの集中化したリストの維持。
・ＳＭＳの要求時における、加入者用のインターネットサービスへのアクセスの許可または拒絶。
・加入者の要求時のインターネットアカウントのカスタマイズ（対応）。
・ｅメールユーザが、イベントを登録し、イベント時にｅメールによって警告を受けることができるリマインダサービス。
・ＩＡＭＳコンテンツの更新を、ＩＳＰなどの関連サーバにコピーできるようにする複製サービス。
【００３７】
ＩＡＭＳに対して中心にあるのは、記憶手段７２に記憶されるインターネットサービスおよびｅメールアカウント用の加入情報を含む、関連データベース管理システム（ＲＤＢＭＳ）７０である。ＳＭＳ通信インタフェース７４により、ＩＡＭＳは、ＳＭＳと通信することができ、その結果ＩＡＭＳは、メールサービスへのアクセスを許可または拒絶された加入者の詳細で更新されてよい。対応サーバ７６は、加入者が、自分のｅメールアカウントを管理し、カスタマイズできるようにする。リマインダサービス７８によって、加入者は、イベントのリストを管理できる。イベントは、加入者のｅメールアカウントに関係する。加入者はイベントを登録し、自動的に作成されるｅメールを介してイベントの所定日数前に、自動リマインダを受信してよい。Ｅメール通知通信インタフェース８４によって、ＥＭＮＳ６２は、架空通知メッセージを送信するために、ＩＡＭＳ ＲＤＢＭＳ７０での加入者の通知優先を検索できるようにする。サポートサーバ８０は、管理者が、ＩＡＭＳ内の加入者またはｅメールユーザの存在およびステータスをチェックできるようにする。複写サービス８２は、ＩＡＭＳ ＲＤＢＭＳ７０のコンテンツの更新をＩＳＰアカウント管理システムにコピーする。
ＩＡＭＳに受信機／デコーダ１３から送信される要求は、ゲートウェイ５８によって、（ｅメールアカウント管理用の）対応サーバおよび（リマインダイベントを管理するための）リマインダサーバなどのＩＡＭＳの適切な部分に向けられる。
【００３８】
前述されたインターネットアクセスシステムは、放送サービスプロバイダが、インターネットサービスを提供できるようにもする。システムのオペレータは、インターネットアカウントを、インターネットサービスプロバイダとは無関係に維持し、その結果、オペレータは、ある特定のインターネットプロバイダに関連付けられない。放送サービスへの加入と、インターネットへの加入をともにリンクすることによって、アカウントが別個に管理され、加入者が２つのサービスにともに請求書を作成発行されるケースと比較して、関与する処理の量を削減してよい２つのサービスに対するアカウントが共に管理される。
【００３９】
ＩＡＭＳの追加詳細は、本出願の名称で「インターネット加入者管理（Ｉｎｔｅｒｎｅｔ Ｓｕｂｓｃｒｉｂｅｒ Ｍａｎａｇｅｍｅｎｔ）」と題され、その主題がここに参照して組み込まれる同時係続出願に記述される。ｅメール通知システムの更なる詳細は、本発明の名称で「Ｅメールと共に使用するための方法および装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ ｕｓｅ ｗｉｔｈ Ｅ−ｍａｉｌ）」と題され、その主題が参照してここに組み込まれる同時係続出願に記述される。
【００４０】
受信機デコーダ１３がインターネットイネーブルされていないケースでのインターネットアクセスシステムの構成を、ここで図７から図１０に関して説明する。その全体が図５に図示され、一定の態様がさらに詳細に描かれているシステムの一部を示す図７を参照すると、受信機／デコーダ１３は、装置にＩＳＰ２６との直接通信に必要なトランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）が備えられていない前述された型のものである。したがって、通信は、ＤＳＴＢゲートウェイ５８を介して起こる。対応サーバ７６およびリマインドサーバ７８は、ＩＡＭＳ５０の別個の部分として図中に示され、実施形態では、データは別個の線路７６ａと７８ａを介して適宜にそれぞれに送られる。
【００４１】
したがって、実際には、受信機／デコーダ１３とアクセスされることが所望される任意のリモートサーバ間の任意の通信で重要な４つのサブシステムがあることが理解されるだろう。これらは、受信機／デコーダ１３自体、ＮＡＳ５６、ゲートウェイ５８、および実施形態の中では対応サーバ７６、リマインドサーバ７８、またはメールサーバ６４の内のいずれか１つであってよいリモートサーバである。ＰＳＴＮ２４は、実際にはデータトランスペアレントである。実施形態では、メールサーバ６４は、インタフェース６６およびＩＳＰ２６を介してアクセスされるが、これが当てはまる必要はなく、メールサーバ６４はゲートウェイ５８から直接的にアクセスできるだろう。さらに、図中では単一装置として図示されているが、メールサーバ６４は、第１が（例えば、ＳＭＴＰサーバであってよい）ｅメール送信用、および第２が（例えば、ＩＭＡＰサーバであってよい）ｅメール受信用の２つの別個の装置から成り立ってよい。このような構成では、ゲートウェイ５８は、２つの別個のポートを介してメールサーバを備える２つの装置と通信してよい。
【００４２】
前述された４つのサブシステムの内のそれぞれによって処理される異なるプロトコルレベルが、ここで図８に関連して説明されるだろう。図から分かるように、受信機／デコーダ１３は、以下のような４つのプロトコルレベル（最高レベルが先）を有する：（アプリケーション依存であるだろう）アプリケーションレベルプロトコル、および例えば、ＳＭＴＰ、ＩＭＡＰ等であってよい；ゲートウェイプロトコル（これは、受信機／デコーダ用に使用されるレベルである―さらに詳しく後述されるようなゲートウェイ通信）；ｖ２２またはｖ４２ｂｉｓなどのＰＰ４プロトコルおよびモデム層。これら後者の２つの層の動作は、当業者に周知だろう。
【００４３】
ＮＡＳ５６は、単一プロトコル層で機能し、（ＰＳＴＮ２４全体で通信するために使用される）モデム層をインターネットプロトコルＴＣＰ／ＩＰに変換するために効果的である。
ゲートウェイ５８は、３つの作動できるプロトコル層（再び、最高レベルが先）、すなわち、ゲートウェイプロトコル層、ＰＰ４プロトコル層、およびＴＣＰ／ＩＰを有する。
最終的に、リモートサーバは、通常、アプリケーションレベルプロトコルでの上位層およびＴＣＰ／ＩＰプロトコルでの下位層という２つのプロトコルを有するだろう。
【００４４】
したがって、ゲートウェイプロトコルは、ゲートウェイ５８が、メッセージに応え、適切な場合には、データの意図された受け取り人を特定し、データをその受け取り人に転送することができるようにする。プロトコルは、受信機／デコーダ１３が、多様なゲートウェイ５８／リモートサーバ動作も開始できるようにする。実施形態では、ゲートウェイ５８は、メールサーバ６４にＳＭＴＰデータまたはＩＭＡＰデータを向けること；データを、新しいアカウントの作成に備える要求を含んでよい対応サーバ７６に向けること；データを、イベント登録に対する要求を含んでよいリマインダサーバ７８に向けること；メールサーバ６４のいずれか１つから受信されるデータに基づいて受信機／デコーダ１３に送信されるべきメッセージを構築することを担当し、対応サーバ７６またはリマインダサーバ７８、およびこのような構築されたメッセージを処理する。さらに、ゲートウェイは、受信機／デコーダ認証機能を実行するための能力を有する。
【００４５】
ここでは、受信機／デコーダ１３とゲートウェイ５８の間の低レベル通信を説明する。第１ステップでは、モデム通信が受信機／エンコーダ１３とＰＳＴＮ２４上のＮＡＳ５６の間に確立される。例えば、ｖ２２またはｖ４２ｂｉｓなどの任意の適切なモデムフォーマットが使用される。この時点で、「チャット」シーケンスは、通信チャネルを完全に確立するために、受信機／デコーダ１３とＮＡＳ５６の間のモデムレベルで発生する。それ以降、ＮＡＳ５６は、ＴＣＰプロトコルレベルで、ゲートウェイ５８との接続チャネルを確立する。このイベントに続いて、ゲートウェイ５８によってトークンが受信機／デコーダ１３に送信され、このトークンは事前に指定された文字シーケンスである。このようなトークンの受信機チャネルによる受信は、それに、ゲートウェイ５８の存在およびゲートウェイプロトコルレベルでの受信機／デコーダ１３とゲートウェイ５８間の通信チャネルが、それによって確立されることを知らせる。
確立されたゲートウェイプロトコル通信チャネルは、実際には、受信機／デコーダ１３の支配下にある。メッセージ交換が発生する前にチャネルを要求しなければならないのは、受信機／デコーダである。さらに、（後述される）切断手順は、チャネルを閉じるために受信機／デコーダ１３によって始められる。
【００４６】
本実施形態では、ゲートウェイプロトコルが、対応するリモートサーバとの単一ＴＣＰチャネルの確立を可能にすることが注記されなければならない。言い替えると、本実施形態では、受信機／デコーダ１３は、任意の一時点に複数のリモートサーバに接続することはできない。しかしながら、受信機／デコーダ１３は、それとゲートウェイ５８間でフレッシュな通信チャネルを確立することを必要とせずにさまざまなリモートサーバに対して接続を確立し、解放してよい。
さらに、実施形態では、ゲートウェイプロトコル層は、下部レベルプロトコル（モデム／ＴＣＰ）がデータの移送を保証し、上部レベルプロトコル（アプリケーションプロトコル）がエラー処理を実行するために、エラー回復機能を実行していないことが注記されなければならない。
【００４７】
ゲートウェイプロトコルでの通信の一般的なメッセージ構造を、ここで記述する。各メッセージ構造は、以下のフィールドを含む。
｛プロトコルバージョン｝｛コマンド識別子｝｛データ長｝［パラメータ］
この場合、｛．．．｝は必須フィールドを示し、［．．．］は任意フィールドを示す。
メッセージ構造は、メッセージが受信機／デコーダ１３から発出するのか、ゲートウェイ５８から発出するのかに関係なく同じである。フィールドは、最初に最上位ビットで２進符号化される。
プロトコルバージョン（ＰＲＴ）フィールドは、プロトコルバージョンを特定する単一バイトを備える。
コマンド識別子（ＣＩ）フィールドは、２バイトを備え、表されるメッセージの種類を特定する。多様な種類のメッセージが、下記に概略されるデータ交換イベント説明から明らかになるだろう。
データ長（ＤＬ）フィールドは、長さが２バイトで、（存在する場合には）付加されるパラメータフィールドの全体的な長さを特定する。これが、パラメータフィールドが可変長であることを可能にする。付加されるパラメータフィールドがない場合には、このフィールドはゼロ値を含むだろう。
パラメータフィールドは、ＴＬＶ形式（型長さ値）で符号化され、メッセージに関連付けられるあらゆる必要なパラメータを含む。個々に、あるいはメッセージの種類に依存して組み合わせて使用されてよい３つのカテゴリのパラメータがある。言い替えると、メッセージの種類が、どのパラメータフィールドが存在するのかを定める。また、一定のメッセージ（例えば、接続がリセットされる（ＭＧ＿ＲＣＮＸ）ことを命令するメッセージ）が、関連付けられたパラメータを有さないことも理解されるだろう。
【００４８】
第１種のパラメータ（ＲＥＭＯＴＥ＿ＳＥＲＶＥＲ）はリモートサーバを特定し、特定されるサーバがメールサーバ６４のＳＴＭＰ部分であるのか、メールサーバ６４のＩＭＡＰ部分であるのか、対応サーバ７６、またはリマインダサーバ７８であるのかを示す整数を含む。実施形態では、このパラメータの長さは２バイトである。修正では、パラメータが、その他のまたは追加のサーバを特定するために使用できるだろう。
【００４９】
第２種のパラメータ（ＢＯＤＹ）は、重要なリモートサーバから受信されるまたは重要なリモートサーバに送信されるデータを含むために使用される。このパラメータは、データ長フィールドによって定められるように可変長であり、このためデータパッケージが所定の長さである必要がないことを示す。このパラメータの最大長は事前に定義される。
【００５０】
第３種のパラメータ（ＥＲＲＯＲ＿ＣＯＤＥ）は、エラー状態を特定するために使用される。これは、例えば、ゲートウェイがいつ指定されたリモートサーバとの接続を開くことができないのか、いつリモートサーバとの接続が失われたのか、いつ受信機／デコーダ１３から受信されたメッセージでエラーが検出されるのか、いつ受信機／デコーダ１３からの命令に続いてリモートサーバからデータが受信されなかったのか、またはいつ認証が失敗したのかを示すために使用されてよい。実施形態では、このパラメータの長さは２バイト長である。
修正では、認証詳細を含むために使用される第４種パラメータがあってよい。
【００５１】
ゲートウェイプロトコルレベル通信チャネル上の通常のダイアログを表す典型的なデータ交換シーケンスを、ここで図９に関して説明する。これは、ある時間期間で（時間は、ページを下るにつれて増す）ゲートウェイ５８と選択されたリモートサーバの間で発生する対応するイベントとともに、受信機／デコーダ１３とゲートウェイ５８の間のメッセージを図で示す。
【００５２】
図示されている第１イベントシリーズ（ｅ１）は、受信機／デコーダと指定されたリモートサーバ間のゲートウェイプロトコルレベル接続手順である。受信機／デコーダ１３は、２つのパラメータ、つまり、それがダイアログを実施することを所望するサーバを指定するＲＥＭＯＴＥ＿ＳＥＲＶＥＲパラメータと、（存在する場合は）リモートサーバにアドレス指定されるデータをカプセル化するＢＯＤＹパラメータを含む接続（ＭＧ＿ＣＮＸ）を要求するメッセージ１０００を送信する。これが、ゲートウェイに、図において接続１００１として集合的に示される２つのタスク、つまり適切なリンクを介して指定されたリンクとの接続を確立させ、そのリンクを介して指定されたサーバにメッセージＢＯＤＹパラメータ内に含まれる（存在する場合）データを送信させるというタスクを実行させる。
【００５３】
前記シーケンスに続いて、リモートサーバは、受信機／デコーダ１３への前方への伝送のために、データ１００２をゲートウェイ５８に送信する。ゲートウェイは、このデータを含む単一パラメータフィールド、つまりＢＯＤＹを有する「リモートサーバとのデータ交換」（ＭＧ＿ＲＥＭＯＴＥ）メッセージ１００３の中でこれを符号化し、メッセージを受信機／デコーダ１３に送信する。接続はそれにより確立される。
【００５４】
図示される第２イベントシリーズ（ｅ２）は、典型的なデータ交換シーケンスである。シーケンスは、フィールドパラメータＢＯＤＹ内のサーバを宛先とするデータを含む「リモートサーバとのデータ交換」（ＭＧ＿ＯＴＨＥＲ）メッセージの受信機／デコーダ１３による送信で開始する。理解されるように、受信機／デコーダ１３は、任意の一時点で１つのリモートサーバと通信するだけであるため、サーバが接続メッセージ（ｅ２）によってすでに指定されるので、それは通常のデータ交換中に指定される必要はない。ゲートウェイ５８がこのデータ交換メッセージ１００４を受信すると、それはその中のデータを、１００５と示される通信の中のリモートサーバに渡す。
それ以後、リモートサーバは、前述されたように、（１００６、１００７と示される）受信機／デコーダにデータを送信する。
【００５５】
実施形態の追加の特徴を、ここで１００８ａ、１００８ｂおよび１００９と示される通信に関して説明する。ゲートウェイ５８から受信機／デコーダ１３に送信される型の「リモートサーバとのデータ交換」（ＭＧ＿ＲＥＭＯＴＥ）メッセージは、最小データパケットサイズを含む。したがって、所定の最小量のデータがリモートサーバから受信される（実際には最小データ量スレッショルド）まで、あるいはリモートサーバからの最終データの受信から所定の時間が経過する（実際には、タイムアウト）まで、ゲートウェイ５８は、受信機／デコーダ１３にメッセージを送信しないだろう。このようにして、通信１００８ａはリモートサーバからゲートウェイ５８へのデータ転送を表すが、このデータの量は所定スレッショルドより低いため、この時点では受信機／デコーダ１３にメッセージは送信されない。次に、追加データ転送１００８ｂは、リモートサーバからゲートウェイ５８へ発生する。この転送の結果、ゲートウェイに十分なデータが通信され、そのためそれはデータシーケンス１００８ａ、１００８ｂの両方を含むデータ交換メッセージ１００９を送信する。同様にして、いったんリモートサーバからゲートウェイ５８によって受信されるデータの量が最大量を超えると、データ交換メッセージは受信機／デコーダ１３に送信される。このような場合、リモートサーバとゲートウェイ５８間での単一データ交換シーケンスから、ゲートウェイ５８と受信機／デコーダ１３間の複数のメッセージが生じる可能性がある。
実施形態では、タイムアウト期間は２００ミリ秒（ｍｓ）であり、最小データ受信スレッショルドは１２８バイトであり、最大データ受信スレッショルドは５１２バイトである。
【００５６】
図中に示されていないが、ゲートウェイ５８が、実施形態では５秒である所定のタイムアウト期間内にリモートサーバからデータを受信していないということが生じる場合がある。このような場合、ゲートウェイは受信機／デコーダ１３に、ＥＲＲＯＲ＿ＣＯＤＥ型のパラメータフィールドを含む「ゲートウェイによるエラー検出」（ＭＧ＿ＥＲＲＯＲ）メッセージを送信し、このフィールドのコンテンツがこのようなイベントの発生を指定する。受信機／デコーダ１３は、ゲートウェイ５８にリモートサーバとのＴＣＰ接続を閉じさせる「通信リセット」（ＭＧ＿ＲＣＮＸ）メッセージの送信を含むことがある、それが講じることを望むあらゆる追加動作の責任を負う。
【００５７】
前記に予示されるように、類似したエラーメッセージが、リモートサーバとの接続を開くことができない、リモートサーバとの接続の損失、あるいはリモートサーバからの誤ったメッセージなどのそれ以外のイベントの後に続く可能性がある。後者のケースでは、これは、未知の型の、不正確な長さの、適用不可の値の、あるいは未知のプロトコルバージョンを有する、ゲートウェイ５８によるリモートサーバからのデータの受信を含むことがある。
【００５８】
図９を参照して、リモートサーバからの切断のイベント（ｅ３）をここで説明する。このイベントは、「切断」（ＭＧ＿ＤＣＮＸ）メッセージ１０２０を送信する受信機／デコーダ１３によって開始される。このメッセージは、ＢＯＤＹパラメータ内でリモートサーバに渡されるべきデータを含んでよい。このコマンドおよびデータ１０２１は、リモートサーバに渡され、その後、ゲートウェイ５８は、肯定応答および存在する場合には応答データ１０２２を待機する。その後で、ゲートウェイ５８はリモートサーバ（１０２３）から切断し、存在する場合、受信されたデータを含むメッセージ１０２４を受信機／デコーダ１３に送信する。低プロトコルレベルの図には示されていないが、受信機／デコーダ１３は、それからモデムレベルでの切断を閉じてよい。ゲートウェイ５８は、その後、ＴＣＰ接続が閉じられる旨をＮＡＳ５６によって通知されるだろう。
【００５９】
ゲートウェイプロトコルによって備えられる認証プロセスを、ここで図１０に関して説明する。これは、通信チャネルの確立前に、多様なサービス、たとえば対応サービスのために必要とされることがある。ゲートウェイ５８は、サーバがアクセスの前に認証を必要とする情報を含み、それがこのようなサーバのために「接続要求」（ＭＧ＿ＣＮＸ）メッセージ１１００を受信するとき、それは「認証要求」（ＭＧ＿ＡＵＴＨＥＢ＿ＲＥＱ）メッセージ１１０１で応答する。このような認証要求メッセージは、付随するパラメータを有していない。受信機／デコーダ１３は、それ以降、適切な「認証」メッセージ１１０２で応答しなければならない。以下により完全に述べられるように、このメッセージは、例えば、スマートカード番号である場合がある認証データを含む関連付けられたパラメータを有する。認証データは、ＢＯＤＹ型パラメータの中で渡されてよいか、あるいは修正の中で独自のパラメータ型を有してよい。
【００６０】
ゲートウェイ５８が、認証詳細が正しいと宣言すると、認証は無事終了し（図ではイベント１１０３で示される）、ゲートウェイ５８が指定されたリモートサーバとの接続１１０４を確立する。ゲートウェイ５８は、接続の開放に応えてリモートサーバから受信されるあらゆるデータ１１０５を含むであろうデータ交換メッセージ１１０６を送信することによって認証が無事終了することを報告する。認証が失敗する場合、前記に概略されたように、このような失敗を示すパラメータを含むエラーメッセージ（ＭＧ＿ＥＲＲＯＲ）が送信される。
【００６１】
図５に示されるシステムに戻ると、受信機／デコーダ１３からのインターネットサービス等のアクセス用の２つの異なった種類の「アカウント」、つまりいわゆる「接続アカウント」およびいわゆる「ディレクトリアカウント」を特定することが可能である。あらゆる接続アカウントの内で、複数のディレクトリアカウントが存在する可能性がある。
【００６２】
接続アカウントは、加入者がオペレータネットワークにアクセスしてよい基礎を提供する。これはさらに詳しく後述されるように複数の接続プロトコルと関連付けられてよいが、加入者はオペレータごとに単一の接続アカウントを割り当てられるだろう。このようなアカウントの認証を発生させる方法はネットワークレベルであり、さらに詳細に後述されるだろう。
【００６３】
自分の接続アカウントによるユーザログイン時の手順を、ここで説明する。理解されるように、ログイン時に供給される識別データは、ユーザが、受信者によって特定できるようにするために一意でなければならない。実施形態では、これは、少なくとも部分的に、ユーザの装置のスマートカード番号から引き出されるいわゆるＭＳＤ番号の使用によって達成される。さらに、ログイン時、ユーザは、例えば、ユーザがコンピュータ（例えば、Ｃａｎａｌ＋の製品であるＭｅｄｉａ Ｗｅｂ ＰＣ）と関連付けられるダイヤルアップモデムを介してアクセスを試みるのか、それとも一般的に「セットトップボックス」と呼ばれている装置のような受信機／デコーダ装置の種類を介してアクセスを試みるのかに応じて変化する可能性がある通信プロトコルを指定しなければならない。使用されるプロトコルは、例えば、ダイヤルアップモデムに対してはＰＡＰ、ＣＨＡＰまたはＰＰＰである可能性がある。
【００６４】
したがって、ログイン情報は、ユーザのＭＳＤ番号の内、ユーザ端末の種別を特定するフィールド、活用されるデータ戻りの種類を指定するフィールド、クライアントバージョン番号を示すフィールド、および該当する場合、いわゆるクライアントのＲＡＤＩＵＳドメイン名を含む。ログインは、パスワードも含むだろう。実施形態では、この情報は以下のようにフォーマットされる。
【００６５】
ログイン＝
｛ｍｓｎ＿ｎｕｍｂｅｒ｝｛端末種別｝｛ｒｅｔｕｒｎ＿ｔｙｐｅ｝｛バージョン｝｛＠ＲＡＤＩＵＳ＿ｄｏｍａｉｎ＿ｎａｍｅ｝
前記フィールドのそれぞれを、ここで更に詳細に説明する。
ｍｓｎ＿ｎｕｍｂｅｒフィールド自体は、フィールドの以下の文字列から成り立つ。
｛ｍｓｎ＿ｎｕｍｂｅｒ｝＝｛ＲＳＭＣ｝｛ＲＳＭＮ｝｛ｃｈｃｋ｝
第１のＭＳＮデータフィールドは、スマートカードの型を特定する取外し可能機密保護モジュール製品コード（ＲＳＭＣ）を含む。型のこの識別は、カードの技術的な構成、製造メーカー、およびカードをユーザに提供した商業的なオペレータの１つまたは複数の態様を示すデータを含んでよい。実施形態では、このフィールドは長さが２バイトであり、４個のディジットを含んでいてよい。
第２のＭＳＮデータフィールドは、取外し可能機密保護モジュール番号（ＲＳＭＮ）を含む。このフィールドは、使用中のスマートカードを特定するコードを含む。このようなコードは、好ましくはスマートカード供給業者によって事前にプログラミングされ、スマートカード、したがってユーザに一意であり、それによりユーザの識別を可能にする。実施形態では、このフィールドは、長さが４バイトであり、１５個の数字を含んでよい。
【００６６】
最終フィールドは、任意の既知の方法によって計算されてよいチェックデータ（ｃｈｃｋ）を含み、例えば、それはチェックサムであってよい。
ｔｅｒｍｉｎａｌ＿ｔｙｐｅフィールドが、ここで説明されるだろう。前述されたように、端末はいわゆる「セットトップ」ボックスの種類であってよいか、あるいはモデム機構を有するコンピュータであってよい。フィールドは、ＰＣ型端末の場合値「Ｐ」を取り、セットトップボックス端末型の場合、値「Ｔ」を取るだろう。フィールドが、より正確に端末型を指定し、このようなフィールドの提供が、追加のおよび代替の端末型の定義による将来の拡張も可能にすることが理解されるだろう。
【００６７】
ｒｅｔｕｒｎ＿ｔｙｐｅフィールドは、戻りデータをユーザに送信する方法の指定を可能にする。実施形態では、フィールドは、すべての戻りデータがモデムを解して送られなければならないときには値「Ｍ」を取り、データ戻りが衛星チャネルとモデムチャネルの両方で発生しなければならないときには値「Ｓ」を取る。再び、戻りデータを提供する方法の将来の拡張の可能性が提供される。
バージョンデータフィールドは、バージョンデータを受信機／デコーダ１３からネットワークに渡すことができるようにする。実施形態では、これはデフォルトとして０１で設定される。
オプションフィールドのＲＡＤＩＵＳ＿ｄｏｍａｉｎ＿ｎａｍｅは、クライアントの認証要求を、ゲートウェイのこのような第３者による、例えば、別のサービスプロバイダへの提供を可能にする第３部認証サーバに送ることができるようにする。
【００６８】
接続プロファイルは、実施形態では、１４英数字という最大長を有するパスワードフィールドも含むだろう。
ここでディレクトリアカウントの説明に戻ると、これは、例えば識別付き代理、メール、ニュース等の個々のインターネットサービスのアクセスの基礎を提供する。加入者のディレクトリアカウントは、自分の接続アカウントにリンクされる。しかしながら、接続アカウントと区別して、ディレクトリアカウントの認証はアプリケーションレベルで発生する。
【００６９】
前述されたように、ディレクトリアカウントは、受信機／デコーダ１３からの種々のインターネットサービスへのアクセスを可能にする。ディレクトリアカウントは、通常、以下から成り立つ。
−識別子およびパスワード
−１つまたは複数のいわゆる「ｅメールエイリアス」
−適切なケースでは、加入者に提供されるサービスに関するその他のデータ
識別子は（適切なケースではパスワードと組み合わされて）、例えば加入者のメールボックスへのアクセスなどの多様なＩＳＰサービスの加入者によるアクセスを制御するために使用される。その他の例は、私用ウェブサイト、ディレクトリへのアクセス、サービス、証明書、「メールグループ」登録等へのアクセスの制御を含む。
識別子は、フォーマット「ｉｄｅｎｔｉｆｉｅｒ＠ｄｏｍａｉｎ」でｅメールアドレスを受信するためにも使用されてよく、その場合加入者が、識別子によって特定されるメールボックスにアクセスするときに自分のパスワードを使用する必要がある場合がある。
ｅメールエイリアスは、「ａｌｉａｓ＠ｄｏｍａｉｎ」へのメッセージアドレスのｅメールサーバによるｅメール受信の機構に備える。
【００７０】
実施形態では、複数のディレクトリアカウントが、単一接続アカウント（いわゆる「家族加入」）に関連付けられてよい。このような場合、各識別子およびエイリアスが一意でなければならないことが注記される必要があるが、ユーザは、最初に、各接続アカウントごとに可能であるディレクトリアカウントの数を指定できる可能性がある。
【００７１】
用語
以下の用語がここに使用される。
Ｅメールアドレス
Ｅメールアドレスは、ＥメールＩＤとドメイン名の２つのフィールドから構成される。ｅメールアドレスの形式は、ｍａｉｌ＿Ｉｄ＠Ｄｏｍａｉｎ＿Ｎａｍｅである。
Ｅメールアカウント
Ｅメールアカウントは、メールサーバがそのユーザのメッセージを処理する必要のあるユーザについての情報を提供する。
ＥメールＩｄ
ｅメールアドレスの接頭語である。ｅメールＩｄは、ドメイン名で一意でなければならない。
Ｅメール通知者
Ｅメール通知者システムにより、加入者（ＥＭＮ）に、彼らがメールボックスに新しいｅメールを受信するとすぐに通知することができる。短いメッセージは、電波放送媒体上で彼らのＳＴＢに送信される。
インターネットアカウント管理システム
加入者ＴＶアカウント管理パラメータおよび関連するＥメールアカウントシステム（ＩＡＭＳ）パラメータを管理するシステム。
メールボックス
ＩＭＡＰ送達用に記憶されるメッセージは、メールボックス内に保持される。メールサーバ上のメールボックスは、メールボックスＩｄによって一意に特定されなければならない。異なるドメイン名をホストするメールサーバは、ｅメールＩｄがメールサーバで一意であると考えることはできないため、メールボックスＩｄはＥメールアドレスでなければならない。
メールサーバ
他のメールサーバとｅメールを交換し、メッセージを受け入れ、メールクライアントに送達するプログラム。
メッセージ待ち行列サーバ（ＭＱＳ）
メッセージ管理システム。
対応サーバ
加入者が、ｅメールアカウントを自分達自身で作成、カスタマイズできるようにする。
リマインダサービス
ユーザが、イベントを登録し、自動メールを介して自動リマインダを受信できるようにする。
セットトップボックス
デジタルビデオ放送規格、ＣＡＮＡＬ＋ＴＥＣＨＮＯＬＯＧＩＥＳ仕様に従って、完全に組み立てられ、使用準備が完了している（ＳＴＢ）デジタル復号ハードウェア。エンドユーザがテレビ番組およびサービスにアクセスできるように、伝送済みのビデオ、オーディオ、アプリケーション、およびデータストリーム用のデジタルデコーダとして使用される。
スマートカード
１つまたは複数の商業的なオペレータの秘密鍵、およびその他のアクセス情報を電子的に記憶するカード。
加入者
加入者はＴＶアカウント（つまり、スマートカード番号）に関係する。
加入者管理システム（ＳＭＳ）
加入者に関係するデータを管理するシステム。
ユーザ
ユーザはＥメールアカウントに関係する。単一加入者に複数のユーザがいる可能性がある。
【００７２】
ここに使用される用語「受信機／デコーダ」または「デコーダ」は、例えば、なんらかの他の手段によって放送または伝送されてよい、テレビおよび／または無線信号などの符号化されるか、符号化されていない信号のどちらかを受信するための受信機を言外に意味する。この用語は、また、受信された信号を復号するためのデコーダも言外に意味する。このような受信機／デコーダの実施形態は、例えば「セットトップボックス」内で受信された信号を復号するための受信機に一体化されたデコーダを含んでよく、このようなデコーダは、物理的に別個の受信機と組み合わされて機能するか、あるいはこのようなデコーダは、ウェブブラウザなどの追加機能を含むか、あるいはビデオレコーダまたはテレビなどのその他のデバイスと統合されている。
本発明が、純粋に例によって前述され、詳細の修正が発明の範囲内でなされうることが理解されるだろう。
説明、および（適切な場合）クレームおよび図面中に開示される各特徴は、独立して、または適切な組み合わせで提供されてよい。
クレーム中に示される参照番号は例示としてのみであり、クレームの範囲に制限的な影響を及ぼさないものとする。
【特許請求の範囲】
【請求項１】
ネットワークにアクセスを提供するために受信機／デコーダとリモートサーバの間の通信を認証する方法であって、
当該方法が通信を認証するために、前記受信機／デコーダの識別子を使用することを含み、該識別子は放送サービスへのアクセス用の識別子に基づく、前記方法。
【請求項１】
ネットワークにアクセスを提供するために受信機／デコーダとリモートサーバの間の通信を認証する方法であって、
当該方法が通信を認証するために、前記受信機／デコーダの識別子を使用することを含み、該識別子は放送サービスへのアクセス用の識別子に基づく、前記方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−１２４９０４（Ｐ２０１２−１２４９０４Ａ）
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願番号】特願２０１１−２８５０８０（Ｐ２０１１−２８５０８０）
【出願日】平成２３年１２月２７日（２０１１．１２．２７）
【分割の表示】特願２００１−５０８１５４（Ｐ２００１−５０８１５４）の分割
【原出願日】平成１２年７月３日（２０００．７．３）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願日】平成２３年１２月２７日（２０１１．１２．２７）
【分割の表示】特願２００１−５０８１５４（Ｐ２００１−５０８１５４）の分割
【原出願日】平成１２年７月３日（２０００．７．３）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]