(57)【要約】【課題】送信ホストのネットワークへアクセスするユーザの認識動作を容易、かつ正確に行うこと。【解決手段】ネットワーク網接続時に、受信者ホスト（ユーザＰＣ）１０，１１から送信される何らかのパケットの送信元ＭＡＣアドレスから、ＰＥルータ１２が受信者ホストのリンクローカルアドレスを生成して登録し、さらにこのパケット内のユーザＩＤから、ＰＥルータ１２が送信者ホスト１４側のバックボーンネットワーク１３へのアクセスの認証要求を行うパケットを作成して、ユーザ認証サーバ１５に送信して、ユーザ認証サーバ１５での認証処理を可能にする。【選択図】      図１
2005011245.tif 000002
【特許請求の範囲】
【請求項１】
複数の受信者ホストと、送信者ホスト側のネットワーク網とがネットワーク間接続装置を介して接続されるとともに、前記ネットワーク網内の認証サーバによって、前記受信者ホストの認証を行い、該認証結果を前記受信者ホストに返送する受信者認証方法において、
前記受信者ホストから送信されるパケット内の受信者ホスト情報を抽出し、該受信者ホスト情報に基づき、前記ネットワーク間接続装置で該受信者ホストに設定された所定情報を作成する作成工程と、
前記パケット内の受信者ホストの識別情報と、予め設定された認証用情報に基づいて、前記認証サーバで前記受信者の認証を行う認証工程と、
を含むことを特徴とする受信者認証方法。
【請求項２】
前記作成工程では、前記受信者ホスト情報として、少なくとも前記パケット内の送信元アドレス情報に基づき、当該受信者ホストの所定情報を作成することを特徴とする請求項１に記載の受信者認証方法。
【請求項３】
複数の受信者ホストと接続されるとともに、送信者ホストのネットワーク網を介して認証サーバと接続され、前記受信者ホストから前記認証サーバへの認証要求、および前記認証サーバから前記受信者ホストへの認証結果をそれぞれ中継するネットワーク間接続装置において、
前記受信者ホストから送信されたパケット内の当該受信者ホストの受信者ホスト情報を抽出し、該受信者ホスト情報に基づき、前記受信者ホストに設定された所定情報を作成する作成手段と、
前記パケット内の受信者ホストの識別情報に基づき、前記認証要求用のパケットを作成して前記認証サーバに送信する送信手段と、
を備えたことを特徴とするネットワーク間接続装置。
【請求項４】
前記作成手段は、前記受信者ホスト情報として、少なくとも前記パケット内の送信元アドレス情報に基づき、当該受信者ホストの所定情報を作成することを特徴とする請求項３に記載のネットワーク間接続装置。
【請求項５】
前記作成手段では、ネットワーク網接続時に前記受信者ホストから送信されたパケットから、前記所定情報を作成することを特徴とする請求項３または４に記載のネットワーク間接続装置。
【請求項６】
少なくともネットワーク間接続装置と認証サーバとから構築される送信者ホスト側のネットワークが、複数の受信者ホストと前記ネットワーク間接続装置を介して接続され、前記受信者ホストから送信されたパケットに基づいて、前記受信者ホストの認証を行う受信者認証システムにおいて、
請求項３〜５のいずれか一つに記載のネットワーク間接続装置を備え、
該ネットワーク間接続装置は、受信したパケットの受信者ホスト情報から、予め設定された受信者ホストの所定情報を作成することを特徴とする受信者認証システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、送信者ホストのネットワークへアクセスする受信者ホストの認証を行う受信者認証方法、そのネットワーク間接続装置および受信者認証システムに関し、特に送信者ホストが、インターネットのサービス事業者である場合の受信者ホストを認証する受信者認証方法、そのネットワーク間接続装置および受信者認証システムに関するものである。
【０００２】
【従来の技術】
従来の中継方法のうち、たとえばマルチキャスト中継方法は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）により標準化されており、例えば図１７のマルチキャスト受信者の認証システムの構成図に示すように、パーソナルコンピュータ（ＰＣ）などの受信者となるホスト（以下、「受信者ホスト」という）１０，１１と、マルチキャストグループのストリームを配信するバックボーンネットワーク１３上の送信者となるホスト（以下、「送信者ホスト」という）１４とを、ネットワーク間接続装置であるルータ１２を介して接続させるものがあった。
【０００３】
このシステムでは、受信者ホスト１０，１１とルータ１２間は、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）によるメッセージの送受信を行っている。このＩＧＭＰは、ＲＦＣ２２３６で標準の方式となっており、受信者ホスト１０，１１は、受信したいマルチキャストグループのアドレスをＩＧＭＰのパケットによってルータ１２に通知し、ルータ１２は、このようなＩＧＭＰを受信したポートＰ０，Ｐ１にだけ、送信者ホスト１４から送信されるマルチキャストパケットのストリームをフォワードすることにより、必要な受信者ホスト１０，１１にだけマルチキャストパケットを中継していた。
【０００４】
【特許文献１】
特開２００１−１１１５９１号公報（６頁−１０頁、図１）
【０００５】
【発明が解決しようとする課題】
しかしながら、上記従来例に用いられるＩＧＭＰには、ユーザの認証の仕組みがないため、受信者ホスト１０，１１からＩＧＭＰメッセージを受信したルータは、送信者ホスト１４からのマルチキャストのストリームを無条件でフォワードすることとなる。
【０００６】
このため、たとえば企業内のＬＡＮ環境においては、特に利用を制限することのない場合には問題とならないが、インターネットのサービス事業者のネットワークにおいて、有料のコンテンツなどを配信するような場合には、サービス事業者からフォワードされるマルチキャストのストリームを、受信者からの要求によって誰でも受信できる状況では、受信者を正確に認識できないという問題点があり、不正アクセスや課金などの面からも受信者の確認ができないことは問題であった。
【０００７】
また、ＩＰｖ６でのネットワークを実現する特許文献１では、マルチキャストサービスにおいて、必要以上のトラフィックの増加を防ぐものはあるが、この文献１には、マルチキャスト受信者の認証方式が記述されておらず、受信者を正確に認識できないという問題点があった。なお、このＩＰｖ６（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ６）でのマルチキャスト受信では、受信者を認証するためのシステムを構築することは可能であるが、この受信者が送信するＭＬＤ（Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒｙ）のパケットの送信元アドレスは、一般にリンクローカルと呼ばれるアドレスであり、このリンクローカルのアドレスは、複数設定が可能であり、またグローバルアドレスと違いＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）に登録されない。このため、受信者を特定するには、ＭＡＣアドレスまたは特定のリンクローカルアドレスをユーザに登録してもらう手順が必要となり、一般のユーザにとっては、この登録手順が煩雑となって、手間どり、コンテンツの配信までに時間がかかるという問題点があった。また、コンテンツの配信サービスに不慣れなユーザによっては、アドレス登録に間違いが起こったり、登録できない事態が生じ、希望するコンテンツの配信が受けられないことがあるという問題点があった。
【０００８】
この発明は、上記問題点に鑑みなされたもので、送信ホストのネットワークへアクセスするユーザの認識動作を容易、かつ正確に行うことができる受信者認証方法、そのネットワーク間接続装置および受信者認証システムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、請求項１にかかる受信者認証方法では、複数の受信者ホストと、送信者ホスト側のネットワーク網とがネットワーク間接続装置を介して接続されるとともに、前記ネットワーク網内の認証サーバによって、前記受信者ホストの認証を行い、該認証結果を前記受信者ホストに返送する受信者認証方法において、前記受信者ホストから送信されるパケット内の受信者ホスト情報を抽出し、該受信者ホスト情報に基づき、前記ネットワーク間接続装置で該受信者ホストに設定された所定情報を作成する作成工程と、前記パケット内の受信者ホストの識別情報と、予め設定された認証用情報に基づいて、前記認証サーバで前記受信者の認証を行う認証工程とを含むことを特徴とする受信者認証方法が提供される。
【００１０】
この発明によれば、ＰＥルータで、ユーザの端末装置から送られてくる受信者ホスト情報から、予め受信者ホストに設定された所定情報、たとえばリンクローカルアドレスを作成するとともに、このパケット内の受信者ホストの識別情報（ユーザＩＤ）と、予め設定された認証用情報（ユーザＩＤ）に基づいて、送信者ホスト側のネットワーク網にアクセスするユーザの認証を行うことで、ユーザの認証時の動作を容易に、かつ正確に行う。
【００１１】
また、請求項２にかかる受信者認証方法では、前記作成工程では、前記受信者ホストから前記受信者ホスト情報として、少なくとも前記パケット内の送信元アドレス情報に基づき、当該受信者ホストの所定情報を作成することを特徴とする。
【００１２】
この発明によれば、作成工程でパケット内の送信元アドレス、たとえば送信元ＭＡＣアドレスに基づいて、受信者ホストの所定情報であるリンクローカルアドレスを生成することで、この後にリンクローカルアドレスを用いた処理、たとえばマルチキャストのコンテンツ配信における認証処理の動作を容易、かつ正確に行う。
【００１３】
また、請求項３にかかるネットワーク間接続装置では、複数の受信者ホストと接続されるとともに、送信者ホストのネットワーク網を介して認証サーバと接続され、前記受信者ホストから前記認証サーバへの認証要求、および前記認証サーバから前記受信者ホストへの認証結果をそれぞれ中継するネットワーク間接続装置において、前記受信者ホストから送信されたパケット内の当該受信者ホストの受信者ホスト情報を抽出し、該受信者ホスト情報に基づき、前記受信者ホストに設定された所定情報を作成する作成手段と、前記パケット内の受信者ホストの識別情報に基づき、前記認証要求用のパケットを作成して前記認証サーバに送信する送信手段とを備えたことを特徴とするネットワーク間接続装置が提供される。
【００１４】
この発明によれば、ＰＥルータにおける作成手段で、ユーザの端末装置から送られてくる受信者ホスト情報から、予め受信者ホストに設定された所定情報、たとえばリンクローカルアドレスを作成するとともに、このパケット内の受信者ホストの認識情報（ユーザＩＤ）に基づき、認証要求用のパケットを作成して送信することで、予め設定された認証用情報（ユーザＩＤ）に基づいて、送信者ホスト側のネットワーク網にアクセスするユーザの認証を行うことで、ユーザの認証時の動作を容易に、かつ正確に行う。
【００１５】
また、請求項４にかかるネットワーク間接続装置では、前記作成手段は、前記受信者ホスト情報として、少なくとも前記パケット内の送信元アドレス情報に基づき、当該受信者ホストの認証用情報を作成することを特徴とする。
【００１６】
この発明によれば、ＰＥルータにおける作成手段でパケット内の送信元アドレス、たとえば送信元ＭＡＣアドレスに基づいて、受信者ホストの所定情報であるリンクローカルアドレスを生成することで、この後にリンクローカルアドレスを用いた処理、たとえばマルチキャストのコンテンツ配信におけるユーザ認証サーバでの認証処理の動作を容易、かつ正確に行う。
【００１７】
また、請求項５にかかるネットワーク間接続装置では、前記作成手段では、ネットワーク網接続時に前記受信者ホストから送信されたパケットから、前記所定情報を作成することを特徴とする。
【００１８】
この発明によれば、ネットワーク網にアクセスする時に認証要求を行うパケット以外のネットワーク網接続時の何らかのパケット、たとえば最初に送信されるパケットからも、送信元ＭＡＣアドレスを抽出し、この送信元ＭＡＣアドレスに基づいて、リンクローカルアドレスを生成およびアクセスするネットワーク網への認証要求を行うことで、ユーザの認証時の動作を容易に、かつ正確に行う。
【００１９】
また、請求項６にかかる受信者認証システムでは、少なくともネットワーク間接続装置と認証サーバとから構築される送信者ホスト側のネットワークが、複数の受信者ホストと前記ネットワーク間接続装置を介して接続され、前記受信者ホストから送信されたパケットに基づいて、前記受信者ホストの認証を行う受信者認証システムにおいて、請求項３または４に記載のネットワーク間接続装置を備え、該ネットワーク間接続装置は、受信したパケットの受信者ホスト情報から、予め設定された受信者ホストの所定情報を作成することを特徴とする受信者認証システムが提供される。
【００２０】
この発明によれば、たとえば起動時などに受信者ホストから送信されるパケットの送信元ＭＡＣアドレスに基づいて、リンクローカルアドレスをネットワーク間接続装置が生成し、以後にこのリンクローカルアドレスを用いた処理の動作を容易、かつ正確に行う。
【００２１】
【発明の実施の形態】
以下に図１〜図１６の添付図面を参照して、この発明にかかる受信者認証方法、そのネットワーク間接続装置および受信者認証システムの好適な実施の形態を説明する。なお、以下の実施の形態では、マルチキャストの受信者認証を行う場合を、一例として説明する。また、以下の図において、図１７と同様の構成部分に関しては、説明の都合上、同一符号を付記するものとする。
【００２２】
（概略構成）
図１は、この発明にかかるマルチキャスト受信者認証システムの概略構成を示す構成図である。図１において、図１７の構成と異なる点は、バックボーンネットワーク１３上にユーザ認証サーバ１５を配設する点であり、ユーザ認証サーバ１５には、例えば予めＷｅｂページで公開されたコンテンツの配信予定などの申し込みに対して、ユーザが入力したユーザ情報（アドレス）や参加を希望するコンテンツ（マルチキャストグループ）のグループアドレスや受信者ホスト１０，１１が接続されるＰＥ（プロバイダエッジ）ルータ１２のポートの情報がデータベースとして登録され、ＩＰｖ６のプロトコルを用いてマルチキャストの受信者認証を行うものである。
【００２３】
ここで、例えばサービス事業者によって、送信者ホスト１４から配信されるコンテンツに対する放送番組表がＷｅｂページで公開されている。このコンテンツの利用を希望する利用者は、受信者ホスト１０，１１からユーザ登録を行い、さらにこのサービス事業者が用意する入力ページにおいて、ユーザ情報（ユーザＩＤやパスワード）を入力して、このコンテンツに参加を希望する旨の申し込みの通知を行えば、受信者ホストのユーザ情報がユーザ認証サーバ１５に登録される。
【００２４】
そして、次にこの発明では、バックボーンネットワーク１３へのアクセスにおいて、ＩＥＥＥ８０２．１ｘとユーザ認証サーバ１５を用いて受信者ホストの認証を行う。そして、バックボーンネットワーク１３へのアクセスでは、ＩＰｖ６プロトコルによる中継を行う。
【００２５】
ここでは、ネットワーク網接続後にユーザがユーザ情報（ユーザＩＤとパスワード）を入力して、受信者ホスト１０，１１からＥＡＰＯＬ−Ｓｔａｒｔパケットなどの何らかのパケットを送信する。ＰＥルータ１２は、受信したこのパケットの、例えば送信元アドレス（ＭＡＣアドレス）とユーザＩＤを抽出し、このＭＡＣアドレスからリンクローカルアドレスを生成し、同じく抽出したユーザＩＤと対応付けて自ルータ内のユーザＩＤテーブル（後述する）に登録する。次に、ＰＥルータ１２は、このパケットの受信を契機にユーザ認証サーバ１５による認証処理のための中継動作を行う。
【００２６】
この認証がなされると、受信者ホスト１０，１１は、マルチキャスト受信を行うため、参加要求を示すＭＬＤのメンバーシップレポートをＰＥルータ宛てに送り、ＰＥルータでは、参加要求メッセージ内のユーザ情報や送信元のリンクローカルアドレスを抽出して、認証要求メッセージを作成してユーザ認証サーバ１５に送る。このユーザ認証サーバ１５は、登録されているユーザ情報を検索し、一致すればそこで認証がなされ、送信者ホスト１４から常時コンテンツの配信が受けられることとなる。
【００２７】
しかし、送信者ホスト１４から配信されるコンテンツは、１種類に限らず、実際には複数の種類が存在する。そこで、コンテンツ毎の受信者ホストの認証が必要になる場合がある。この場合には、受信者ホストは、配信が予定されている各マルチキャストグループのうちから、参加を希望する特定のマルチキャストグループのグループアドレスを指定することによって、ユーザ認証サーバ１５のマルチキャスト受信者認証テーブルに登録される。
【００２８】
この場合も、受信者ホストが参加要求を行うことによって、ユーザ認証サーバ１５は、ＰＥルータ１２を介して送られてくる上記認証要求のメッセージ内のユーザ情報とグループアドレスから、登録されているアドレスを検索し、一致すればそこで認証がなされ、送信者ホスト１４から常時コンテンツの配信が受けられることとなる。
【００２９】
また、受信者ホストからは、この特定のマルチキャストグループのグループアドレスを指定しないで、参加要求を行うことも可能である。ただし、この場合には、全てのマルチキャストグループの指定となって、ユーザ認証サーバ１５のマルチキャスト受信者認証テーブルに登録される。
【００３０】
この場合には、受信者ホストが参加要求を行うことによって、ユーザ認証サーバ１５は、ＰＥルータ１２を介して送られてくる上記認証要求のメッセージ内のユーザ情報から、登録されているユーザ情報を検索し、一致すればそこで認証がなされ、送信者ホスト１４から常時複数のコンテンツの配信が受けられることとなる。
【００３１】
また、自己のリンクローカルアドレスではない任意のリンクローカルアドレスによってマルチキャストグループへの参加を試みる受信者ホストに対しては、上記の認証では不正参加を防ぐことができないので、例えば受信者ホスト１０，１１が接続されているＰＥルータ１２のポートの情報を、認証の対象にすることも可能である。
【００３２】
この場合には、受信者ホストが参加要求を行うことによって、ユーザ認証サーバ１５は、ＰＥルータ１２を介して送られてくる上記参加要求のメッセージ内のユーザ情報とポートの情報から、登録されているアドレスを検索し、一致すればそこで認証がなされ、送信者ホスト１４から常時複数のコンテンツの配信が受けられることとなる。
【００３３】
この構成に示したように、この発明では、ＩＥＥＥ８０２．１ｘを用いて受信者ホストの認証を行うとともに、ＰＥルータが受信者ホストのリンクローカルアドレスを生成するので、受信者ホストでは、たとえばリンクローカルアドレスを用いてマルチキャストの認証を得たい場合など、リンクローカルアドレスを用いて何らかの処理が必要になる場合に、ユーザがリンクローカルアドレスの煩わしい入力を行わなくても、たとえばユーザＩＤとパスワードの入力だけで、バックボーンネットワークへのアクセスの認証と、その後に行われるマルチキャストの認証などの処理を容易に実行することができる。
【００３４】
（実施の形態）
図２は、この発明にかかるマルチキャスト受信者認証システムの実施の形態の構成を示す構成図である。図において、このシステムは、複数のユーザＰＣ（受信者ホスト）２０，２１と、ユーザＰＣ２０，２１が接続される中継装置であるカスタマエッジルータ（以下、「ＣＥルータ」という）２２，２３と、サービス事業者のＩＰ網２９に配設されるネットワーク間接続装置であるプロバイダエッジルータ（以下、「ＰＥルータ」という）３０と、同じくＩＰ網２９に配設されてストリームを配信するストリームコンテンツ配信サーバ３１と、同じくＩＰ網２９に配設されてユーザＰＣの認証を行うユーザ認証サーバ３２と、同じくＩＰ網２９に配設されてユーザＰＣからの配信受付を行う配信受付サーバ３３と、同じくＩＰ網２９に配設されて課金の計算を行う課金サーバ３４とから構成されている。
【００３５】
ＣＥルータ２２，２３は、ユーザＰＣ２０，２１とＰＥルータ３０との間に介在し、ユーザＰＣ２０，２１からＰＥルータ３０へのＭＬＤメンバーシップレポートのメッセージパケットやユーザＰＣ２０，２１と配信受付サーバ３３間のＷｅｂページ上でのデータの送受信を中継している。
【００３６】
ＰＥルータ３０は、図３の構成図に示すように、各ＣＥルータ２２，２３や各種サーバ３１〜３４とポートを介して接続されるＬＡＮインターフェース３０ａと、ＬＡＮインターフェース３０ａで取り込まれたパケットを受信し、パケットの種類を判別して振り分けるパケット受信部３０ｂと、パケット受信部３０ｂで振り分けられたＭＬＤメンバーシップレポートのメッセージパケットの制御処理を行うＭＬＤ制御部３０ｃと、パケット受信部３０ｂで振り分けられたＲＡＤＩＵＳメッセージのパケットの制御処理を行う認証制御部３０ｄと、パケット受信部３０ｂで振り分けられたマルチキャストパケットのフォワーディング制御処理を行うマルチキャストフォワーディング制御部３０ｅと、ＩＥＥＥ８０２．１ｘを用いてユーザの認証制御を行う８０２．１ｘ認証制御部３０ｆと、各制御部３０ｃ〜３０ｆと接続されて、これらパケットから得られるマルチキャスト受信者の情報を格納するマルチキャスト受信者管理テーブル３０ｇと、マルチキャストパケットをフォワーディングするためのルート情報を格納するマルチキャストフォワーディングテーブル３０ｈと、予め設定されたユーザＩＤの情報を格納するユーザＩＤテーブル３０ｉと、各制御部３０ｃ〜３０ｆで処理されたパケットを送信するパケット送信部３０ｊとから構成されている。
【００３７】
マルチキャスト受信者管理テーブル３０ｇは、図４に示すように、ユーザＰＣが参加を希望するマルチキャストグループのグループアドレスと、ユーザを識別するための受信者ユーザＩＤと、このユーザＰＣが接続されるインターフェースの受信者ポート番号と、コンテンツの配信を行うストリームコンテンツ配信サーバ３１が接続されるインターフェースの送信者ポート番号とから構成されている。なお、このマルチキャスト受信者管理テーブル３０ｇは、ＣＥルータ２２，２３との間で送受されるＭＬＤメッセージの情報に基づいて作成される。
【００３８】
マルチキャストフォワーディングテーブル３０ｈには、図５に示すように、ストリームコンテンツ配信サーバ３１で配信されるコンテンツを示すマルチキャストグループのグループアドレスと、当該マルチキャストグループに参加を希望する各ユーザＰＣ（ＣＥルータ）が接続されるインターフェースの受信者ポート番号のリストが格納されている。
【００３９】
また、ユーザＩＤテーブル３０ｉは、図６に示しように、送信元のＭＡＣアドレスと、ユーザＩＤと、このＭＡＣアドレスから生成されたＩＰｖ６アドレスが格納されている。このユーザＩＤテーブル３０ｉは、ユーザＰＣから受信した８０２．１ｘ認証メッセージの内容に基づいて作成される。
【００４０】
ユーザ認証サーバ３２は、図７に示すように、ＰＥルータ３０や配信受付サーバ３３とポートを介して接続されるＬＡＮインターフェース３２ａと、ＬＡＮインターフェース３２ａで取り込まれた８０２．１ｘ認証メッセージのパケットを受信するパケット受信部３２ｂと、受信された８０２．１ｘ認証メッセージ内の送信元アドレスとグループアドレスに基づいてユーザの認証を行う認証制御部３２ｃと、配信受付サーバ３３に接続されて受け付けられたユーザ情報などが入力する配信受付サーバインターフェース３２ｄと、配信受付サーバインターフェース３２ｄから入力するユーザ情報を登録するマルチキャスト受信者認証テーブル３２ｅと、ユーザ情報やＥＡＰタイプを登録する加入者接続認証テーブル３２ｆと、認証制御部３２ｃからの認証結果をＬＡＮインターフェース３２ａを介して送信するパケット送信部３２ｇとから構成されている。
【００４１】
このユーザ認証サーバ３２のマルチキャスト受信者認証テーブル３２ｅは、図８に示すような構成になっている。図において、このマルチキャスト受信者認証テーブル３２ｅには、受信者ホストのユーザＩＤである受信者ＩＤと、その受信者ホストが参加するマルチキャストグループのグループアドレスと、受信者ホストが接続されるＰＥルータ１２のポートのＩＰｖ６アドレスと、そのＰＥルータポート番号が格納されている。
【００４２】
また、加入者接続認証テーブル３２ｆは、ユーザＩＤである加入者ＩＤの情報と、パスワードであるシークレットの値と、ＥＡＰタイプ、この例ではＭＤ５−Ｃｈａｌｌｅｎｇｅの情報とが格納されている。
【００４３】
この構成例では、例えば受信者ホスト１０，１１の受信者ＩＤおよび加入者ＩＤを”ｆｕｒｕｋａｗａ”、”ｄｅｎｋｏ”、シークレット値を”ｄｆｄａｕｓｆｈｄｓａｕｆ４８９”、”ａｄｆｅｒｇｄ９７３ｋ”とし、受信者ホスト１０が配信を受けるマルチキャストグループのグループアドレスを”ｆｆ１５：：２：ｅｄｂ１”とし、受信者ホスト１１が配信を受けるマルチキャストグループを全てのグループとした場合を示している。また、この構成例では、受信者ホスト１０が接続されるＰＥルータ１２のポートのＰＥルータＩＰｖ６アドレスを”３ｆ０ｅ：８１ｃ０：ｆ１０１：：１”、そのポート番号を”１”とし、受信者ホスト１１が接続されるＰＥルータ１２のポートのＰＥルータＩＰＶ６アドレスを”３ｆ０ｅ：８１ｃ０：ｆ１０２：：１”、そのポート番号を”６”としている。
【００４４】
なお、このパスワードは、ユーザＰＣ２０，２１に個別に設定されるものではなく、ＲＡＤＩＵＳのパケットの中で使われるパスワードで、ＲＡＤＩＵＳのプロトコル上、ＲＡＤＩＵＳのクライアントを認証するために予め決められたものを登録しておくもので、ユーザがユーザＰＣに個別に設定するパスワードとは異なる。このパスワードは、ユーザＰＣ側でも持っていて、ユーザ認証サーバ３２からキーとなる情報を渡し、ユーザＰＣでは、このキーとシークレットの情報を組み合わせて計算した、たとえばハッシュの値を、ユーザＰＣから返送するもので、ユーザ認証サーバでも同じ計算を行い、同一の場合には、ＥＡＰ−Ｓｕｃｃｅｓｓを送信して認識が可能となる。
【００４５】
なお、このバックボーンネットワークへのアクセスの問い合わせは、ＩＥＥＥ８０２．１ｘの認証（Ａｕｔｈｅｎｔｉｃａｔｏｒ）機能を用いて行う。この問い合わせは、ユーザ側から８０２．１ｘ認証メッセージパケットのうちのＥＡＰＯＬ−Ｓｔａｒｔパケットの受信を契機にユーザ認証サーバ３２による認証処理を開始する。この問い合わせにおいては、受信者ホスト２０とＰＥルータ３０間では、８０２．１ｘ認証メッセージパケットを用い、ＰＥルータ３０とユーザ認証サーバ３２では、ＲＡＤＩＵＳメッセージを用いて行われる。
【００４６】
ここで、８０２．１ｘ認証メッセージのパケットフォーマットは、図１０に示すように、レイヤ２レベルの宛先ＭＡＣアドレスと、送信元ＭＡＣアドレスと、ＰＡＥイーサネット（Ｒ）タイプと、プロトコルのバージョンと、このメッセージのパケットタイプと、パケットボディフィールドのオクテット長を示すパケットボディレングスと、ＥＡＰパケットを示すパケットボディのフィールドとから構成されている。なお、この実施の形態において、パケットタイプは、ＥＡＰ−Ｐａｃｋｅｔを示す”０”と、ＥＡＰＯＬ−Ｓｔａｒｔを示す”１”と、ＥＡＰＯＬ−Ｌｏｇｏｆｆを示す”２”と、ＥＡＰＯＬ−Ｋｅｙを示す”３”などからなる。
【００４７】
また、ＥＡＰパケットのパケットフォーマットは、図１１に示すように、パケットのコードを示すコードと、コードに示されるリクエストとレスポンスのマッチングのために使用され、どのリクエストに対する応答であるかを識別するアイデンティファイヤと、ＥＡＰパケット全体のオクテット長を示すレングスと、データのタイプを示すタイプと、ユーザＩＤが格納されるタイプ−データとからなる。なお、この実施の形態において、コードは、リクエストを示す”１”と、レスポンスを示す”２”と、サクセスを示す”３”などからなり、またタイプは、フェ−ルを示す”４”などからなる。
【００４８】
ユーザ認証サーバ３２は、この問い合わせのＥＡＰパケットのメッセージを受信すると、登録内容から受信者ホストの受信者ＩＤを確認し、その後ＥＡＰによる認証手順を実行した後に受信者の認証ＯＫとなると、その後に受信者からＭＬＤのパケットを受信した場合には、そのマルチキャストグループへの参加を認証するかどうか判断し、この認証結果（および許可時間が設定されている場合には、そのマルチキャストグループへの参加許可時間）をＰＥルータ３０に応答する。
【００４９】
また、配信受付サーバ３３は、ＰＥルータ３０とポートを介して接続され、Ｗｅｂ上で伝送される配信申し込みのためのｗｗｗブラウザが送受信するＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のパケットを取り込み、このパケットに基づいて、ユーザ認証を行うとともに、この受信されたパケットのユーザ情報をＣＧＩなどを用いてデータベースへ展開し、この展開したデータをユーザ認証サーバ３２に送信している。
【００５０】
課金サーバ３４は、たとえば定額制または従量制によって課金することができる、ここで定額制の課金の場合には、たとえば月単位に定額とし、この定額で参加できるコンテンツは、いつ申し込んでも配信を受けることができるように設定する。
【００５１】
図１２は、図３に示したＰＥルータ３０による受信パケットの識別動作を示すフローチャートである。図において、図３に示したＬＡＮインターフェース３０ａにあるパケットが取り込まれ、そのパケットがパケット受信部３０ｂで受信されると（ステップ１０１）、パケット受信部３０ｂでは、受信したパケットが８０２．１ｘの認証パケットかどうか判断する（ステップ１０２）。
【００５２】
ここで、上記受信パケットが８０２．１ｘの認証パケットの場合には、上記パケットを８０２．１ｘ認証制御部３０ｆに出力して、８０２．１ｘ認証制御部３０ｆによる処理に移行し（ステップ１０３）、また上記受信パケットが８０２．１ｘの認証パケットでない場合には、上記受信パケットがＭＬＤメンバーシップ・レポートのメッセージパケットかどうか判断する（ステップ１０４）。
【００５３】
ここで、上記受信パケットがＭＬＤメンバーシップ・レポートのメッセージパケットの場合には、上記受信パケットをＭＬＤ制御部３０ｃに出力し、ＭＬＤ制御部３０ｃによる処理に移行し（ステップ１０５）、また上記受信パケットがＭＬＤメンバーシップ・レポートのメッセージパケットでない場合には、ＲＡＤＩＵＳメッセージパケットかどうか判断する（ステップ１０６）。
【００５４】
ここで、上記受信パケットがＲＡＤＩＵＳメッセージパケットの場合には、上記受信パケットを認証制御部３０ｄに出力し、認証制御部３０ｄによる処理に移行し（ステップ１０７）、また上記受信パケットがＲＡＤＩＵＳメッセージパケットでない場合には、マルチキャストパケットかどうか判断する（ステップ１０８）。
【００５５】
ここで、上記受信パケットがマルチキャストパケットの場合には、上記受信パケットをマルチキャストフォワーディング制御部３０ｅに出力し、マルチキャストフォワーディング制御部３０ｅによる処理に移行し（ステップ１０９）、また。上記受信パケットがマルチキャストパケットでない場合には、上記受信パケットをパケット受信部３０ｂ内で受信処理を行い（ステップ１１０）、例えばこの受信パケットをパケット送信部３０ｊから送信する。
【００５６】
次に、８０２．１ｘ認証制御部３０ｆの制御処理動作について、図１３のフローチャートを用いて説明する。図において、８０２．１ｘ認証制御部３０ｆは、８０２．１ｘ認証パケットが受信されると（ステップ２０１）、このパケット内のパケットタイプの情報を抽出して、パケットタイプがＥＡＰＯＬ−Ｓｔａｒｔかどうか判断する（ステップ２０２）。
【００５７】
ここで、パケットタイプがＥＡＰＯＬ−Ｓｔａｒｔの場合には、パケットタイプがＥＡＰＯＬ  ＥＡＰ−Ｒｅｑｕｅｓｔ／ＩｄｅｎｔｉｔｙのパケットをユーザＰＣに送信して、ユーザＩＤを要求する（ステップ２０３）。また、パケットタイプがＥＡＰＯＬ−Ｓｔａｒｔでない場合には、パケットタイプがＥＡＰＯＬＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙかどうか判断する（ステップ２０４）。
【００５８】
ここで、パケットタイプがＥＡＰＯＬ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙの場合には、ＲＡＤＩＵＳのＡｔｔｒｉｂｕｔｅｓにＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙを入れて、ＲＡＤＩＵＳメッセージのパケットを生成して、ユーザ認証サーバ３２に送信して問い合わせを行う（ステップ２０５）。また、パケットタイプがＥＡＰＯＬ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙでない場合には、パケットタイプがＥＡＰＯＬ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅかどうか判断する（ステップ２０６）。
【００５９】
ここで、パケットタイプがＥＡＰＯＬ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅの場合には、ＲＡＤＩＵＳのＡｔｔｒｉｂｕｔｅｓにＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅを入れて、ＲＡＤＩＵＳメッセージのパケットを生成して、ユーザ認証サーバ３２に送信して問い合わせを行う（ステップ２０７）。また、パケットタイプがＥＡＰＯＬ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅでない場合には、パケットタイプがＥＡＰＯＬ  ＥＡＰ−ＬＯＧＯＦＦかどうか判断する（ステップ２０８）。
【００６０】
ここで、パケットタイプがＥＡＰＯＬ  ＥＡＰ−ＬＯＧＯＦＦの場合には、ユーザが利用停止と判断し、図６に示したユーザＩＤテーブルから該当するエントリを消去する（ステップ２０９）。また、パケットタイプがＥＡＰＯＬ  ＥＡＰ−ＬＯＧＯＦＦでない場合には、８０２．１ｘ認証パケットではないと判断して、上記動作を終了する。
【００６１】
次に、認証制御部３０ｄの制御処理動作を、図１４のフローチャートを用いて説明する。図１４において、パケット受信部３０ｂがＲＡＤＩＵＳメッセージを識別すると、認証制御部３０ｄによる処理に移行し、認証制御部３０ｄは、ユーザ認証サーバ３２から受信したＲＡＤＩＵＳメッセージの内容を確認する（ステップ３０１）。そして、受信したＲＡＤＩＵＳメッセージのパケットタイプがＥＡＰ−Ｒｅｑｕｅｓｔ／ＥＡＰ−ＴｙｐｅまたはＥＡＰ−Ｓｕｃｃｅｓｓかどうか判断する（ステップ３０２）。
【００６２】
ここで、受信したＲＡＤＩＵＳメッセージのパケットタイプがＥＡＰ−Ｒｅｑｕｅｓｔ／ＥＡＰ−ＴｙｐｅまたはＥＡＰ−Ｓｕｃｃｅｓｓの場合には、ＥＡＰＯＬ  ＥＡＰ−Ｒｅｑｕｅｓｔ／ＥＡＰ−ＴｙｐｅまたはＥＡＰＯＬ  ＥＡＰ−ＳｕｃｃｅｓｓをユーザＰＣに送信する（ステップ３０３）。そして、パケットタイプがＥＡＰ−Ｓｕｃｃｅｓｓの場合には、パケット内のユーザＰＣのＭＡＣアドレスとユーザＩＤおよび生成したＩＰｖ６アドレスをユーザＩＤテーブル３０ｉに登録する（ステップ３０４）。
【００６３】
また、受信したＲＡＤＩＵＳメッセージのパケットタイプがＥＡＰ−Ｒｅｑｕｅｓｔ／ＥＡＰ−ＴｙｐｅまたはＥＡＰ−Ｓｕｃｃｅｓｓでない場合には、ユーザ認証サーバ３２からの応答が認証の許可かどうか判断する（ステップ３０５）。
【００６４】
ここで、この認証が不許可の場合には認証失敗と判断し、マルチキャスト受信者管理テーブル３０ｇから該当するエントリを削除する（ステップ３０６）。また、この認証が許可された場合には、拡張属性値の時刻を読み出し（ステップ３０７）、時刻属性があるかどうか判断する（ステップ３０８）。
【００６５】
ここで、時刻属性が設定されていない場合には、ユーザ情報をマルチキャスト受信者管理テーブル３０ｇに登録し（ステップ３０９）、また時刻属性が設定されている場合には、次に現時刻がその拡張属性値の設定時刻内かどうか判断する（ステップ３１０）。
【００６６】
ここで、現時刻が設定時刻外、特に設定時刻のスタート時刻前の場合は、例えば内部に有するタイマを起動させて、スタート時刻まで待ち、タイマが満了すると、ユーザ情報をマルチキャスト受信者管理テーブル３０ｇに登録する（ステップ３１１）。また、現時刻が設定時刻内の場合には、ユーザ情報をマルチキャスト受信者管理テーブル３０ｇに登録する（ステップ３０９）。
【００６７】
次に、図７に示したユーザ認証サーバ３２の認証制御処理動作を、図１５のフローチャートを用いて説明する。図において、ＬＡＮインターフェース３２ａで取り込まれ、パケット受信部３２ｂでパケットが受信されると（ステップ４０１）、パケット受信部３２ｂは、上記受信パケットが、ＲＡＤＩＵＳ  Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔメッセージかどうか判断する（ステップ４０２）。
【００６８】
ここで、この受信パケットがＲＡＤＩＵＳ  Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔメッセージの場合には、認証制御部３２ｃの処理に移行する。そして、認証制御部３２ｃによって受信者認証が行われ（ステップ４０３）、認証が許可された場合には（ステップ４０４）、拡張属性であるコンテンツの配信サービスの開始と終了の時間をマルチキャスト受信者認証テーブル３２ｅから読み出し、「Ａｃｃｅｓｓ−Ａｃｃｅｐｔ」のＲＡＤＩＵＳメッセージを作成し（ステップ４０５）、また認証が不許可の場合には、「Ａｃｃｅｓｓ−Ｒｅｊｅｃｔ」のＲＡＤＩＵＳメッセージを作成する（ステップ４０６）。そして、作成したＲＡＤＩＵＳメッセージをパケット送信部３２ｇからＬＡＮインターフェース３２ａを介して送信する（ステップ４０７）。
【００６９】
また、ステップ４０２において、受信パケットがＲＡＤＩＵＳ  Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔメッセージでない場合には、この受信パケットがＲＡＤＩＵＳＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙメッセージかどうか判断する（ステップ４０８）。
【００７０】
ここで、この受信パケットがＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙメッセージの場合には、メッセージ内のユーザＩＤに基づき、加入者接続認証テーブル３２ｆを検索してＥＡＰ−Ｔｙｐｅの情報を求めて、ＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｑｕｅｓｔメッセージを作成する（ステップ４０９）。そして、作成したＲＡＤＩＵＳメッセージをパケット送信部３２ｇからＬＡＮインターフェース３２ａを介して送信する（ステップ４０７）。
【００７１】
また、この受信パケットがＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙメッセージでない場合には、この受信パケットがＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅかどうか判断し（ステップ４１０）、ＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅでない場合には、このパケットを廃棄する（ステップ４１１）。また、この受信パケットがＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅの場合には、認証制御部３２ｃによる認証が許可されたかどうか判断する（ステップ４１２）。
【００７２】
ここで、認証が許可された場合には、ＲＡＤＩＵＳ  ＥＡＰ−Ｓｕｃｃｅｓｓパケットを作成し（ステップ４１３）、また認証が不許可の場合には、ＲＡＤＩＵＳ  ＥＡＰ−Ｆａｉｌｕｒｅパケットを作成し（ステップ４１４）、作成したパケットをパケット送信部３２ｇからＬＡＮインターフェース３２ａを介して送信する（ステップ４０７）。
【００７３】
図１６は、図２に示したこの発明にかかる受信者認証システムの各部の８０２．１ｘ認証制御処理動作を説明するためのタイムチャートである。たとえば、マルチキャストのコンテンツ配信サービスでは、Ｗｅｂサーバは、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）などを用いて、入力情報をデータベースに展開し、マルチキャスト認証用のユーザ認証サーバ３２へデータを格納している。ユーザは、このコンテンツ配信を受信するユーザＰＣをネットワークに接続することで、８０２．１ｘ認証による認証動作を実行する。
【００７４】
図１６において、ユーザＰＣ２０が起動すると、ユーザＰＣ２０は、バックボーンネットワークへの接続時に、ユーザＩＤとパスワードを入力して、ＥＡＰＯＬ−ＳｔａｒｔパケットをＰＥルータ３０に送信する。ＰＥルータ３０は、このパケットを受信すると、ＥＡＰＯＬ  ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙを、該当するユーザＰＣ２０に送信して、ユーザＩＤを要求する。このユーザＩＤの要求に対して、ユーザＰＣ２０は、自ＰＣのユーザＩＤを含んだＥＡＰＯＬ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙを作成して応答する。
【００７５】
ＰＥルータ３０は、この受信パケットからユーザＩＤのドメイン名部からユーザのアクセス先を識別するとともに、受信したＥＡＰＯＬパケットをＲＡＤＩＵＳのメッセージ（ＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ）に変換して、このアクセス先に対応するユーザ認証サーバ３２へ送信する。また、ＰＥルータ３０は、受信したＥＡＰＯＬパケットの送信元ＭＡＣアドレスと受信者ポート番号の情報からユーザを認識するとともに、送信元ＭＡＣアドレスから、ユーザＰＣのリンクローカルアドレスを生成し、ユーザＩＤテーブル３０ｉに登録する。さらに、ＰＥルータ３０は、ユーザに対して、どのユーザ認証サーバ３２にＲＡＤＩＵＳメッセージを送信したかを、例えば送信者ポート番号をマルチキャスト受信者管理テーブル３０ｇに記録しておく。
【００７６】
次に、ユーザ認証サーバ３２は、ＲＡＤＩＵＳメッセージを受信すると、このメッセージ内のユーザＩＤに基づいて、加入者接続認証テーブル３２ｆを検索してＥＡＰ−Ｔｙｐｅ（この実施の形態では、ＭＤ５−Ｃｈａｌｌｅｎｇｅ）を抽出して、このＥＡＰ−Ｔｙｐｅを含んだＲＡＤＩＵＳ  ＥＡＰ−Ｒｅｑｕｅｓｔ／ＥＡＰ−Ｔｙｐｅを作成して送信する。このＰＥルータ３０は、ユーザ認証サーバ３２からＥＡＰ−Ｔｙｐｅによって認証方法を指定したＲＡＤＩＵＳメッセージを受信すると、このメッセージをＥＡＰＯＬパケットに変換してユーザＰＣに送信する。
【００７７】
すなわち、ユーザ認証サーバ３２は、このＲＡＤＩＵＳメッセージにＥＡＰ−Ｔｙｐｅとともに、ＭＤ５でキーとなる情報を含めてユーザＰＣに送信し、ユーザＰＣは、受信したこのキー情報とシークレット情報を組み合わせてハッシュ値を求め、このハッシュ値を含んだＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＥＡＰ−Ｔｙｐｅのパケットを、ＰＥルータ３０を介してユーザ認証サーバ３２に返送する。
【００７８】
ユーザ認証サーバ３２では、このハッシュ値を受け取ると、同じ計算を行ってハッシュ値を求め、両ハッシュ値の比較を行い、同じ場合には、認証の許可を示すＥＡＰ−Ｓｕｃｃｅｓｓを、ＰＥルータ３０を介してユーザＰＣに送信する。また、認証が不許可の場合には、ＥＡＰ−Ｆａｉｌｕｒｅのパケットを送信する。そして、ユーザＰＣからＥＡＰＯＬ  ＥＡＰ−ＬｏｇｏｆｆをＰＥルータ３０が受信すると、ＰＥルータ３０は、接続終了と判断してユーザからのアクセス許可を終了する。
【００７９】
この認証の後に、ユーザＰＣとＰＥルータ間では、マルチキャストコンテンツ配信を行うためのＭＬＤのメンバーシップ・レポートが通信される。その際、ＰＥルータでは、ＭＬＤのメッセージに含まれるリンクローカルアドレス（ＩＰｖ６アドレス）に基づき、ユーザＩＤテーブルを検索して、該当するユーザＩＤを抽出して、このユーザＩＤに基づいてユーザ認証サーバでマルチキャストグループへの当該ユーザＰＣの参加を許可されると、実際のマルチキャストストリームが流されることとなる。
【００８０】
なお、この発明では、一度認証された後、定期的に認証を行うことも可能であり、この場合には、「定期的な再認証を行う／行わない」の設定や、「再認証の間隔」などの設定を行うことで、処理を最適化することができる。
【００８１】
このように、この実施の形態では、バックボーンネットワークへのアクセスの認証工程を追加するとともに、ユーザＰＣから入力するパケットの送信元アドレスから、ユーザＰＣのリンクローカルアドレスを生成してユーザＩＤと対応付けてＰＥルータに登録するので、ユーザは、ユーザＩＤとパスワードを入力するだけで、リンクローカルアドレスをＰＥルータで生成して登録することができ、これによりバックボーンネットワークへアクセスするユーザの認識動作を容易、かつ正確に行うことができる。
【００８２】
また、この実施の形態では、このようにＰＥルータが自動的にユーザＰＣのリンクローカルアドレスを生成するので、このリンクローカルアドレスを用いた処理、たとえばマルチキャストコンテンツ配信における認証処理を容易、かつ正確に行うことができ、これにより契約を行った正しいユーザにのみ、コンテンツなどの情報提供を行うとともに、課金サーバによってユーザ毎に正しく提供するサービスに対する課金を行うことが可能となる。
【００８３】
この発明は、これら実施形態に限定されるものではなく、この発明の要旨を逸脱しない範囲で種々の変形実施が可能である。たとえば、この実施の形態では、ＥＡＰＯＬ−Ｓｔａｒｔパケットの送信元ＭＡＣアドレスから、ユーザのリンクローカルアドレスを生成したが、この発明はこれに限らず、ネットワーク網接続時にユーザＰＣから送信される何らかのパケットの送信元ＭＡＣアドレスから、リンクローカルアドレスを生成し、かつこのパケットのユーザＩＤから認証要求用のパケットを作成してユーザ認証サーバに送信しても良い。
【００８４】
また、この発明では、ＩＥＥＥ８０２．１ｘの認証機能を行うか、行わないかの設定を、ＶＬＡＮ（ブリッジグループ）毎に行うことも可能である。この場合の設定は、ＰＥルータに直接設定することも可能であり、また図２に示した配信受付サーバ３３にこの設定を行っておき、配信受付サーバ３３からＰＥルータがこの設定条件を取得できるように設定することも可能である。
【００８５】
【発明の効果】
以上説明したように、この発明では、受信者ホストから送信される何らかのパケットの受信者ホスト情報から、ネットワーク間接続装置がこの受信者ホストに予め設定されている所定情報を生成するとともに、このパケット内の受信者ホストの識別情報から、送信ホストのネットワークへのアクセスを認証するための認証要求するパケットを作成するので、ユーザの認識動作を容易、かつ正確に行うことができる。
【００８６】
また、この発明では、ネットワーク間接続装置が受信したパケット内のＭＡＣアドレスから、受信者ホストのリンクローカルアドレスを生成するので、この後にリンクローカルアドレスを用いた処理、たとえばマルチキャストのコンテンツ配信における認証処理などの動作を容易、かつ正確に行うことができる。
【図面の簡単な説明】
【図１】この発明にかかる受信者認証システムの概略構成を示す構成図である。
【図２】この発明にかかる受信者認証システムの実施の形態の構成を示す構成図である。
【図３】図２に示したＰＥルータの構成の一例を示す構成図である。
【図４】図３に示したマルチキャスト受信者管理テーブルの構成の一例を示す構成図である。
【図５】図３に示したマルチキャストフォワーディングテーブルの構成の一例を示す構成図である。
【図６】図３に示したユーザＩＤテーブルの構成の一例を示す構成図である。
【図７】図２に示したユーザ認証サーバの構成の一例を示す構成図である。
【図８】図７に示したマルチキャスト受信者認証テーブルの構成の一例を示す構成図である。
【図９】図７に示した加入者接続認証テーブルの構成の一例を示す構成図である。
【図１０】８０２．１ｘ認証メッセージのパケットフォーマットを示す図である。
【図１１】図１０に示したＥＡＰパケット（パケットボディ）のパケットフォーマットを示す図である。
【図１２】図３に示したＰＥルータによる受信パケットの識別動作を説明するためのフローチャートである。
【図１３】図３に示した８０２．１ｘ認証制御部の制御処理動作を説明するためのフローチャートである。
【図１４】図３に示した認証制御部の制御処理動作を説明するためのフローチャートである。
【図１５】図７に示したユーザ認証サーバの認証制御処理動作を説明するためのフローチャートである。
【図１６】この発明にかかる受信者認証システムの各部の８０２．１ｘ認証制御処理動作を説明するためのタイムチャートである。
【図１７】従来のマルチキャスト受信者認証システムの概略構成を示す構成図である。
【符号の説明】
１０，１１，２０，２１  受信者ホスト（ユーザＰＣ）
１２，３０  ＰＥルータ
１３，２９  バックボーンネットワーク
１４  送信者ホスト
１５，３２  ユーザ認証サーバ
２２，２３  ＣＥルータ
２９  サービス事業者ＩＰ網
３０ａ，３２ａ  ＬＡＮインターフェース
３０ｂ，３２ｂ  パケット受信部
３０ｃ  ＭＬＤ制御部
３０ｄ，３２ｃ  認証制御部
３０ｅ  マルチキャストフォワーディング制御部
３０ｆ  ８０２．１ｘ認証制御部
３０ｇ  マルチキャスト受信者管理テーブル
３０ｈ  マルチキャストフォワーディングテーブル
３０ｉ  ユーザＩＤテーブル
３０ｊ，３２ｇ  パケット送信部
３１  ストリームコンテンツ配信サーバ
３２ｅ  マルチキャスト受信者認証テーブル
３２ｆ  加入者接続認証テーブル
３２ｄ  配信受付サーバインターフェース
３３  配信受付サーバ
３４  課金サーバ
Ｐ０，Ｐ１  ポート
【図１】
2005011245.tif 000003
【図２】
2005011245.tif 000004
【図３】
2005011245.tif 000005
【図４】
2005011245.tif 000006
【図５】
2005011245.tif 000007
【図６】
2005011245.tif 000008
【図７】
2005011245.tif 000009
【図８】
2005011245.tif 000010
【図９】
2005011245.tif 000011
【図１０】
2005011245.tif 000012
【図１１】
2005011245.tif 000013
【図１２】
2005011245.tif 000014
【図１３】
2005011245.tif 000015
【図１４】
2005011245.tif 000016
【図１５】
2005011245.tif 000017
【図１６】
2005011245.tif 000018
【図１７】
2005011245.tif 000019