(57)【要約】【課題】ユーザ端末にハードウェアやソフトウェアをインストールしたり、コンテンツの獲得毎にＩＤやパスワードを入力するような繁雑な作業を必要としないコンテンツの配信を実現すること。【解決手段】ユーザＩＤ及びパスワードをＩＰアドレスとペアで保持する機能を備え、ユーザからコンテンツ要求を受信するとユーザＩＤ及びパスワードとともに事業者側へ転送するホームゲートウェイ７０をユーザ宅内に設置するとともに、コンテンツ要求とともに送られてきたユーザＩＤ及びパスワードを認証サーバ３０へ送って認証させ、認証に成功した場合は前記コンテンツ要求をコンテンツ配信サーバ２０へ転送する課金・認証ゲートウェイ６０を事業者側に設置することにより、コンテンツの復号、ＩＤやパスワードの入力などが不要なコンテンツの配信を可能とする。【選択図】　　　　　　図１
2004078424.tif 000002
【特許請求の範囲】
【請求項１】
ユーザからのコンテンツ獲得開始要求を受信するとコンテンツをそのままユーザへ配信するコンテンツ配信サーバと、ユーザＩＤ及びパスワードを基に認証する認証サーバとを含む事業者が、コンテンツ獲得毎に認証を行ってコンテンツを配信するシステムであって、
ユーザ側に、
ユーザＩＤ及びパスワードを記録する手段と、
ユーザからのコンテンツ獲得開始要求を保持する手段と、
前記コンテンツ獲得開始要求を基に前記記録手段が記録しているユーザＩＤ及びパスワードを取り出す手段と、
前記コンテンツ獲得開始要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送する手段とを設けるとともに、
事業者側に、
前記情報を保持する手段と、
前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送する手段と、
認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得開始要求をコンテンツ配信サーバへ転送する手段とを設けた
ことを特徴とするコンテンツ配信システム。
【請求項２】
ユーザ側に、
ユーザからのコンテンツ獲得終了要求を保持する手段と、
前記コンテンツ獲得終了要求を基に前記記録手段が記録しているユーザＩＤ及びパスワードを取り出す手段と、
前記コンテンツ獲得終了要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送する手段とを設けるとともに、
事業者側に、
前記情報を保持する手段と、
前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送する手段と、
認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得終了要求をコンテンツ配信サーバへ転送する手段とを設けた
ことを特徴とする請求項１記載のコンテンツ配信システム。
【請求項３】
事業者側に、認証サーバから認証に成功した旨を受信した場合には課金のための情報を課金サーバへ転送する手段を設けた
ことを特徴とする請求項１または２記載のコンテンツ配信システム。
【請求項４】
前記認証サーバは、同じユーザが二重にログインすることを防ぐことを特徴とする請求項１乃至３いずれか記載のコンテンツ配信システム。
【請求項５】
前記認証サーバは、認証を試行した回数をカウントする手段を備えていることを特徴とする請求項１乃至４いずれか記載のコンテンツ配信システム。
【請求項６】
前記認証サーバは、認証の試行回数が予め決められた値を越えた場合は認証に失敗したと判定することを特徴とする請求項５記載のコンテンツ配信システム。
【請求項７】
前記コンテンツ獲得開始要求またはコンテンツ獲得終了要求、ユーザＩＤ及びパスワードを含む情報をユーザ及び事業者間で転送する際、これらの情報を暗号化して転送することを特徴とする請求項１乃至６いずれか記載のコンテンツ配信システム。
【請求項８】
前記記録手段からユーザＩＤ及びパスワードを取り出すために、コンテンツ獲得開始要求またはコンテンツ獲得終了要求の送信元ＩＰアドレスを用いることを特徴とする請求項１乃至７いずれか記載のコンテンツ配信システム。
【請求項９】
前記記録手段からユーザＩＤ及びパスワードを取り出すために、コンテンツ獲得開始要求またはコンテンツ獲得終了要求の送信元ＭＡＣアドレスを用いることを特徴とする請求項１乃至７いずれか記載のコンテンツ配信システム。
【請求項１０】
前記コンテンツ獲得開始要求として、ＩＧＭＰ　ｊｏｉｎパケットを用いることを特徴とする請求項１乃至９いずれか記載のコンテンツ配信システム。
【請求項１１】
前記コンテンツ獲得終了要求として、ＩＧＭＰ　ｌｅａｖｅパケットを用いることを特徴とする請求項２乃至１０いずれか記載のコンテンツ配信システム。
【請求項１２】
ユーザからのコンテンツ獲得開始要求を受信するとコンテンツをそのままユーザへ配信するコンテンツ配信サーバと、ユーザＩＤ及びパスワードを基に認証する認証サーバとを含む事業者が、コンテンツ獲得毎に認証を行ってコンテンツを配信する方法であって、
ユーザ側で、
ユーザＩＤ及びパスワードを記録し、
ユーザからのコンテンツ獲得開始要求を基に前記記録したユーザＩＤ及びパスワードを取り出し、
前記コンテンツ獲得開始要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送し、
事業者側で、
前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送し、
認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得開始要求をコンテンツ配信サーバへ転送する
ことを特徴とするコンテンツ配信方法。
【請求項１３】
ユーザ側で、
ユーザからのコンテンツ獲得終了要求を基に前記記録したユーザＩＤ及びパスワードを取り出し、
前記コンテンツ獲得終了要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送し、
事業者側で、
前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送し、
認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得終了要求をコンテンツ配信サーバへ転送する
ことを特徴とする請求項１２記載のコンテンツ配信方法。
【請求項１４】
事業者側で、認証サーバから認証に成功した旨を受信した場合には課金のための情報を課金サーバへ転送する
ことを特徴とする請求項１２または１３記載のコンテンツ配信方法。
【請求項１５】
ユーザからのコンテンツ獲得開始要求を受信するとコンテンツをそのままユーザへ配信するコンテンツ配信サーバと、ユーザＩＤ及びパスワードを基に認証する認証サーバとを含む事業者が、コンテンツ獲得毎に認証を行ってコンテンツを配信するシステムにおいてユーザ側に設置されるホームゲートウェイであって、
ユーザＩＤ及びパスワードを記録する手段と、
ユーザからのコンテンツ獲得開始要求を保持する手段と、
前記コンテンツ獲得開始要求を基に前記記録手段が記録しているユーザＩＤ及びパスワードを取り出す手段と、
前記コンテンツ獲得開始要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送する手段とを備えた
ことを特徴とするホームゲートウェイ。
【請求項１６】
ユーザからのコンテンツ獲得終了要求を保持する手段と、
前記コンテンツ獲得終了要求を基に前記記録手段が記録しているユーザＩＤ及びパスワードを取り出す手段と、
前記コンテンツ獲得終了要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送する手段とを備えた
ことを特徴とする請求項１５記載のホームゲートウェイ。
【請求項１７】
前記記録手段からユーザＩＤ及びパスワードを取り出すために、コンテンツ獲得開始要求またはコンテンツ獲得終了要求の送信元ＩＰアドレスを用いることを特徴とする請求項１５または１６記載のホームゲートウェイ。
【請求項１８】
前記記録手段からユーザＩＤ及びパスワードを取り出すために、コンテンツ獲得開始要求またはコンテンツ獲得終了要求の送信元ＭＡＣアドレスを用いることを特徴とする請求項１５または１６記載のホームゲートウェイ。
【請求項１９】
前記コンテンツ獲得開始要求として、ＩＧＭＰ　ｊｏｉｎパケットを用いることを特徴とする請求項１５乃至１８いずれか記載のホームゲートウェイ。
【請求項２０】
前記コンテンツ獲得終了要求として、ＩＧＭＰ　ｌｅａｖｅパケットを用いることを特徴とする請求項１６乃至１９いずれか記載のホームゲートウェイ。
【請求項２１】
ユーザからのコンテンツ獲得開始要求を受信するとコンテンツをそのままユーザへ配信するコンテンツ配信サーバと、ユーザＩＤ及びパスワードを基に認証する認証サーバとを含む事業者が、コンテンツ獲得毎に認証を行ってコンテンツを配信するシステムにおいて事業者側に設置される認証・課金ゲートウェイであって、
コンテンツ獲得開始要求、ユーザＩＤ及びパスワードを含む情報を保持する手段と、
前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送する手段と、
認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得開始要求をコンテンツ配信サーバへ転送する手段とを備えた
ことを特徴とする認証・課金ゲートウェイ。
【請求項２２】
コンテンツ獲得終了要求、ユーザＩＤ及びパスワードを含む情報を保持する手段と、
前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送する手段と、
認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得終了要求をコンテンツ配信サーバへ転送する手段とを備えた
ことを特徴とする請求項２１記載の認証・課金ゲートウェイ。
【請求項２３】
認証サーバから認証に成功した旨を受信した場合には課金のための情報を課金サーバへ転送する手段を設けた
ことを特徴とする請求項２１または２２記載の認証・課金ゲートウェイ。
【請求項２４】
前記コンテンツ獲得開始要求として、ＩＧＭＰ　ｊｏｉｎパケットを用いることを特徴とする請求項２１乃至２３いずれか記載の認証・課金ゲートウェイ。
【請求項２５】
前記コンテンツ獲得終了要求として、ＩＧＭＰ　ｌｅａｖｅパケットを用いることを特徴とする請求項２２乃至２４いずれか記載の認証・課金ゲートウェイ。
【請求項２６】
前記認証結果が失敗の場合には、ユーザに失敗した旨を通知する手段を備えたことを特徴とする請求項２１乃至２５いずれか記載の認証・課金ゲートウェイ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、映像などのコンテンツをネットワークを介してユーザに提供し、課金を行うコンテンツ配信システム、コンテンツ配信方法、ホームゲートウェイ及び認証・課金ゲートウェイに関する。
【０００２】
【従来の技術】
従来、コンテンツ配信システムとして、図１７に示すシステムが提案されている。本例では、契約者のみにコンテンツを提供し、コンテンツ毎に課金する、いわゆるペイパービュー（Ｐａｙ　Ｐｅｒ　Ｖｉｅｗ：ＰＰＶ）課金方式のシステムについて例示している。
【０００３】
このコンテンツ配信システムは、図１７に示すように、ユーザ端末１と、暗号化されたコンテンツをユーザ端末１に配信するコンテンツ配信サーバ２と、契約ユーザかどうかを認証する認証サーバ３と、暗号化されたコンテンツを復号するキーを発行する復号キー管理サーバ４と、認証サーバ３のログを元にして課金を行う課金サーバ５とを備えている。
【０００４】
ユーザがコンテンツを視聴開始するまでの動作について説明する。
（１）ユーザ端末１には、コンテンツ配信サーバ２から暗号化されたコンテンツが配信される。この段階では暗号化されているため、ユーザはコンテンツを視聴することはできない。
（２）ユーザは、認証サーバ３へＩＤとパスワード（Ｐａｓｓｗｏｒｄ）を送信する。
（３）認証サーバ３は、ＩＤとパスワードから正しいユーザであるかどうかを判定する。正しいユーザである場合、復号キー管理サーバ４に対して復号キーを発行するように依頼する。
（４）復号キー管理サーバ４は、復号キーをユーザ端末１へ送信する。
（５）ユーザ端末１は、復号キーを使ってコンテンツを復号する。ユーザはコンテンツを視聴することができるようになる。
（６）認証サーバ３は、どのユーザがどんなコンテンツを購入したかなどの情報を課金サーバ５へ転送する。課金サーバ５はこの情報を元にして、ＰＰＶ課金を行う。
【０００５】
【発明が解決しようとする課題】
上述のように、従来のコンテンツ配信システムでは、認証サーバでユーザを特定し、そのユーザにだけ復号キーを渡してコンテンツを視聴できるようにするという方式を採用している。これにより、前記認証サーバのログを使ってコンテンツを獲得（視聴）したユーザにだけＰＰＶ課金を行うことができる。
【０００６】
しかし、上記システムを利用するには、ユーザ自身がユーザ端末に認証要求やコンテンツ復号のためのハードウェアやソフトウェアをインストールしたり、設定したりする必要があるという問題があった。また、ユーザはコンテンツを獲得する毎にユーザＩＤやパスワードを入力する手間がかかるという問題があった。
【０００７】
本発明は、上記事情を鑑みてなされたものであり、その目的とするところは、ユーザ端末にハードウェアやソフトウェアをインストールしたり、設定したり、コンテンツを獲得する毎にＩＤやパスワードを入力したりする繁雑な作業を必要としないコンテンツ配信システム、ホームゲートウェイ及び認証・課金ゲートウェイを提供することにある。
【０００８】
また、一般に使われている製品や標準のプロトコルを改造せずそのまま利用することができ、開発し易く、事業導入し易いコンテンツ配信システム、コンテンツ配信方法、ホームゲートウェイ及び認証・課金ゲートウェイを提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明は、ユーザからのコンテンツ獲得開始要求を受信するとコンテンツをそのままユーザへ配信するコンテンツ配信サーバと、ユーザＩＤ及びパスワードを基に認証する認証サーバとを含む事業者が、コンテンツ獲得毎に認証を行ってユーザへコンテンツを配信するシステムであって、ユーザ側に、ユーザＩＤ及びパスワードを記録する手段と、ユーザからのコンテンツ獲得開始要求を保持する手段と、前記コンテンツ獲得開始要求を基に前記記録手段が記録しているユーザＩＤ及びパスワードを取り出す手段と、前記コンテンツ獲得開始要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送する手段とを備えたホームゲートウェイを設けるとともに、事業者側に、前記情報を保持する手段と、前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送する手段と、認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得開始要求をコンテンツ配信サーバへ転送する手段とを備えた認証・課金ゲートウェイを設けたことを特徴とする。
【００１０】
本発明によれば、ユーザ端末にはコンテンツがそのまま、つまり暗号化されないまま配信され、また、コンテンツ獲得開始要求を基にユーザＩＤ及びパスワードを取り出して認証するため、ユーザ端末に認証要求やコンテンツ復号のためのハードウェアやソフトウェアをインストールしたり、設定したり、コンテンツを獲得する毎にＩＤやパスワードを入力したりすることなく、コンテンツを獲得できる。また、一般に使われている製品や標準のプロトコルを改造せずそのまま利用することができるため、開発し易く、事業導入し易いものを提供できる。さらに、ユーザ側に設置されたホームゲートウェイがユーザの代わりにＩＤとパスワードの入力を代行してくれるため、シングルサインオンが実現できる。さらに、ホームゲートウェイ及び認証・課金ゲートウェイ間で暗号化して通信することで、よりいっそうセキュリティを高めることができる。さらに、コンテンツ獲得開始要求やコンテンツ獲得終了要求を契機にした課金情報を基にして、ＰＰＶ課金や時間課金、従量課金など、コンテンツ毎に様々な課金を行うことができる。
【００１１】
【発明の実施の形態】
（第１の実施の形態）
以下、本発明のコンテンツ配信システムについて図面を参照して説明する。
【００１２】
図１は本発明のコンテンツ配信システムの第１の実施の形態を示す全体構成図である。なお、本実施の形態ではマルチキャストでストリーミングコンテンツをユーザへ配信するシステムを例示する。また、ルータはＩＧＭＰバージョン２（詳細はＲＦＣ２２３６を参照）を実装している場合を例示する。
【００１３】
このコンテンツ配信システムは、図１に示すように、ユーザ端末１と、課金サーバ５と、ストリーミングコンテンツをユーザ端末１へ配信するコンテンツ配信サーバ２０と、ユーザを認証するための認証サーバ３０と、認証用のユーザ情報を保持するユーザデータベース（ＤＢ）４０と、マルチキャストプロトコルＩＧＭＰバージョン２を実装しているルータ５０と、認証サーバ３０及び課金サーバ５と協調動作する機能（後述する）を持った認証・課金ゲートウェイ（ＡＡＡＧＷ）６０と、通常のルータの機能並びにＡＡＡＧＷ６０と協調動作する機能（後述する）を併せ持ったホームゲートウェイ（ＨＧＷ）７０とを備えている。
【００１４】
なお、ＡＡＡＧＷ６０はコンテンツ配信サーバ２０、認証サーバ３０、課金サーバ５とともに事業者（サービス提供者）側に設置され、ＨＧＷ７０はユーザ側（ユーザ宅内）に設置される。
【００１５】
ユーザ端末１は、グローバルＩＰアドレスであるｘ．ｘ．ｘ．ｘを予め設定されているものとする。
【００１６】
課金サーバ５は、あるユーザＩＤの課金情報（例えば、いつ、どのコンテンツを購入したかなどの情報）を受け取ると、ＡＡＡＧＷへＡｃｃｏｕｎｔｉｎｇ−Ｒｅｓｐｏｎｓｅを返す。
【００１７】
認証サーバ３０は、あるユーザＩＤに対して認証に成功した場合、ＡＡＡＧＷ６０へＡｃｃｅｓｓ−Ａｃｃｅｐｔを返し、認証に失敗した場合、Ａｃｃｅｓｓ−Ｒｅｊｅｃｔを返す。
【００１８】
図２にユーザＤＢ４０の記憶内容の一例を示す。図２の例では、ユーザＤＢ４０は、ユーザＩＤ、パスワード、現在ログインしているかどうかを示すログイン情報、認証に何回失敗したかを示す認証カウンタ、ユーザが参加できるグループアドレスから構成されている。ここで、１つのグループアドレスは、１つのコンテンツに対応している。
【００１９】
ユーザがログインしていない場合はログイン情報を「０」にしておき、ログイン中である間はログイン情報を「１」にセットする。ログアウトすると、再び「０」にリセットする。
【００２０】
認証サーバ３０は、二重ログインを防止するため、あるユーザＩＤのユーザがログイン中には同じユーザＩＤでログインできないようにする機能を有する。これを実現するためには、認証時にログイン情報をチェックし、「１」であればログインを拒否する。
【００２１】
また、認証サーバ３０は、不正アクセスを防止するため、ある認証回数を越えたらログインを拒否する。例えば、認証失敗回数の許容値を「３」とすると、認証が失敗する毎に認証カウンタ値を一つずつ増やし、３回になった場合は以後の認証は全て拒否する。
【００２２】
さらに、不正アクセス防止を強化するため、タイマを設定し、ある時間以内に認証が成功しない場合はログインを拒否するような機能を認証サーバ３０に持たせても良い。
【００２３】
図２の例では、ｕｓｅｒ２１がログイン中であるため、ログイン中であることを示すログイン情報は「１」である。また、認証は失敗せずに一回で成功したので、認証カウンタは「０」である。また、ｕｓｅｒ２１はグループアドレス２２４．１．１．１に対応するコンテンツだけを獲得（視聴）することができる。ｕｓｅｒ２０とｕｓｅｒ２２はネットワークにログインしていない。ｕｓｅｒ２０はグループアドレス２２４．１．１．１と２２４．１．１．２に対応するコンテンツを視聴可能である。ｕｓｅｒ２２はグループアドレス２２４．１．１．１と２２４．１．１．３に対応するコンテンツを視聴可能である。
【００２４】
［ＡＡＡＧＷ］
次に、ＡＡＡＧＷ６０の機能を説明する。図３にＡＡＡＧＷ６０の詳細なブロック構成図を示す。
【００２５】
ＡＡＡＧＷ６０は、ＨＧＷ７０からパケットを受信する受信部６１と、ＨＧＷ７０へパケットを送信する送信部６２と、ＩＧＭＰルータ５０からパケットを受信する受信部６３と、ＩＧＭＰルータ５０へパケットを送信する送信部６４と、認証サーバ３０または課金サーバ５からパケットを受信する受信部６５と、認証サーバ３０または課金サーバ５へパケットを送信する送信部６６と、受信部６１が受信したパケットのタイプにより、後述する適切な処理を行った後、どこにどんなパケットを送信するかを決定するパケット制御部６７とから構成される。これらの機能は、Ｌｉｎｕｘ（登録商標）上で動作するアプリケーションとして実装する。
【００２６】
ＨＧＷ７０から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部６１はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐ（ｆｔｐ：／／ｆｔｐ．ｅｅ．ｌｂｌ．ｇｏｖ／ｌｉｂｐｃａｐ．ｔａｒ．Ｚ）を利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ＨＧＷ７０からのパケットの送信先ＩＰアドレスはＡＡＡＧＷ６０ではないので、ＡＡＡＧＷ６０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットはパケット制御部６７へ渡す。
【００２７】
同じように、ＩＧＭＰルータ５０から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部６３はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐ（ｆｔｐ：／／ｆｔｐ．ｅｅ．ｌｂｌ．ｇｏｖ／ｌｉｂｐｃａｐ．ｔａｒ．Ｚ）を利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ＩＧＭＰルータ５０からのパケットの送信先ＩＰアドレスはＡＡＡＧＷ６０ではないので、ＡＡＡＧＷ６０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットは送信部６２へ渡す。
【００２８】
認証サーバ３０あるいは課金サーバ５にとってＡＡＡＧＷ６０は通常のクライアントとして扱えるので、受信部６５及び送信部６６は通常のｓｏｃｋｅｔを使って受信及び送信する。受信部６５が受信したパケットはパケット制御部６７へ渡す。送信部６６は、パケット制御部６７からパケットを受けとり、認証サーバ３０あるいは課金サーバ５へパケットを送信する。
【００２９】
送信部６４が送信すべきパケットの送信元ＩＰアドレスはＡＡＡＧＷ６０ではなく、受信部６１が受信したパケットの送信元ＩＰアドレス（例えばユーザ端末１のＩＰアドレス）である。そのため、送信部６４はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００３０】
同じように、送信部６２が送信すべきパケットの送信元ＩＰアドレスはＡＡＡＧＷ６０ではなく、受信部６３が受信したパケットの送信元ＩＰアドレス（例えばコンテンツ配信サーバ２０のＩＰアドレス）である。そのため、送信部６２はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００３１】
次に、パケット制御部６７の動作について図４乃至図７を参照して説明する。図４乃至図７はパケット制御部６７の動作を説明するフローチャートである。
【００３２】
パケット制御部６７は、受信部６１から受け取ったパケットが何であるかをチェックする。この際、ユーザがネットワークにログインするための認証要求である場合（ステップＳＡ１）、Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ（ＩＤ、パスワードを含んだ認証要求パケット）を認証サーバ３０へ送信する（ステップＳＢ１）。認証サーバ３０は、ＩＤ、パスワードから正当なユーザかどうかを判断し、認証結果をＡＡＡＧＷ６０へ返信する（ステップＳＢ２）。ここで、認証結果とは、認証サーバ３０が正当なユーザと判断した場合、Ａｃｃｅｓｓ−ＡｃｃｅｐｔをＡＡＡＧＷ６０へ返し、正当ではないと判断した場合、Ａｃｃｅｓｓ−ＲｅｊｅｃｔをＡＡＡＧＷ６０へ返す。ＡＡＡＧＷ６０は、認証結果をＨＧＷ７０へ転送する（ステップＳＢ３）。
【００３３】
ステップＳＡ１でネットワークログインのための認証要求であるとは判断せず（ステップＳＡ１のＮｏ）、コンテンツ視聴開始要求であると判断した場合（ステップＳＡ２）、ＡＡＡＧＷ６０は、コンテンツ視聴開始要求のためのＡｃｃｅｓｓ−Ｒｅｑｕｅｓｔ（ＩＤ、パスワード、視聴したいコンテンツのグループアドレスを含むパケット）を認証サーバ３０へ送信する（ステップＳＣ１）。認証サーバ３０は、図２に示すような情報と、送信されてきたＩＤ、パスワード、グループアドレスを比較して、正当かどうかを判断する。
【００３４】
正当である場合（ステップＳＣ２のＹｅｓ）、認証サーバ３０はＡｃｃｅｓｓ−ＡｃｃｅｐｔをＡＡＡＧＷ６０へ返す。ＡＡＡＧＷ６０は、ＩＧＭＰ　ｊｏｉｎパケット（参加したいグループアドレスを含んだＭｅｍｂｅｒｓｈｉｐ　Ｒｅｐｏｒｔパケット、ヘッダタイプは０ｘ１６）をＩＧＭＰルータ５０へ送信する（ステップＳＣ３）。ＩＧＭＰ　ｊｏｉｎパケットを受け取ったＩＧＭＰルータ５０は、指定されたグループアドレスに対応するコンテンツをユーザ端末１へ送信開始する。ＡＡＡＧＷ６０は、課金情報（ＩＤ、グループアドレス、視聴開始時刻など）を課金サーバ５へ送信する（ステップＳＣ４）。課金サーバ５は、受け取った課金情報をハードディスクなどに蓄積し終えたら、ＡＡＡＧＷ６０へ蓄積完了したことを通知する（ステップＳＣ５）。
【００３５】
ステップＳＣ２で正当ではないと判断した場合（ステップＳＣ２のＮｏ）、コンテンツ視聴開始要求を破棄する（ステップＳＣ６）とともに、ユーザ端末１にその旨を通知する（ステップＳＣ７）。
【００３６】
また、コンテンツ視聴開始要求であるとは判断せず（ステップＳＡ２のＮｏ）、コンテンツ視聴終了要求であると判断した場合（ステップＳＡ３）、ＡＡＡＧＷ６０は、コンテンツ視聴終了要求のためのＡｃｃｅｓｓ−Ｒｅｑｕｅｓｔ（ＩＤ、パスワード、視聴終了したいコンテンツのグループアドレスを含むパケット）を認証サーバ３０へ送信する（ステップＳＤ１）。認証サーバ３０は、図２に示すような情報と、送信されてきたＩＤ、パスワード、グループアドレスを比較して、正当かどうかを判断する。
【００３７】
正当である場合（ステップＳＤ２のＹｅｓ）、認証サーバ３０はＡｃｃｅｓｓ−ＡｃｃｅｐｔをＡＡＡＧＷ６０へ返す。ＡＡＡＧＷ６０は、ＩＧＭＰ　ｌｅａｖｅパケット（Ｌｅａｖｅ　Ｇｒｏｕｐパケット、ヘッダタイプが０ｘ１７）をＩＧＭＰルータ５０へ送信する（ステップＳＤ３）。ＩＧＭＰ　ｌｅａｖｅパケットを受け取ったＩＧＭＰルータ５０は、指定されたグループアドレスに対応するコンテンツのユーザ端末１への送信を停止する。ＡＡＡＧＷ６０は、課金情報（ＩＤ、グループアドレス、視聴終了時刻など）を課金サーバ５へ送信する（ステップＳＤ４）。課金サーバ５は、受け取った課金情報をハードディスクなどに蓄積し終えたら、ＡＡＡＧＷ６０へ蓄積完了したことを通知する（ステップＳＤ５）。
【００３８】
ステップＳＤ２で正当ではないと判断した場合（ステップＳＤ２のＮｏ）、コンテンツ視聴終了要求を破棄する（ステップＳＤ６）とともに、ユーザ端末１にその旨を通知する（ステップＳＤ７）。
【００３９】
コンテンツ視聴終了要求であるとは判断しなかった場合（ステップＳＡ３のＮｏ）、受け取ったパケットをそのままＩＧＭＰルータ５０へ転送する（ステップＳＡ４）。
【００４０】
ステップＳＤ４、ＳＤ５は、従量課金、時間課金など、スタート時間とストップ時間が必要な場合には必要なステップである。一方、一旦、購入を決めたら、そのコンテンツを実際に利用しようとしまいと課金する場合には、ステップＳＣ４、ＳＣ５のみ必要であり、ステップＳＤ４、ＳＤ５は必要ない。例えば、レンタルビデオのような映画コンテンツの場合、一旦、購入を決めたら、ユーザが全ての映画を見ようとみまいと一律料金を課金する場合などである。
【００４１】
［ＨＧＷ］
【００４２】
次に、ＨＧＷ７０の機能を説明する。図８にＨＧＷ７０の詳細なブロック構成図を示す。
【００４３】
ＨＧＷ７０は、ユーザ端末１からパケットを受信する受信部７１と、ユーザ端末１へパケットを送信する送信部７２と、ＡＡＡＧＷ６０からパケットを受信する受信部７３と、ＡＡＡＧＷ６０へパケットを送信する送信部７４と、ユーザに対応するＩＤとパスワードを管理するパケット制御部７５と、パケット制御部７５がユーザ情報を記録するために使うユーザ情報管理表７６とから構成される。これらの機能は、Ｌｉｎｕｘ上で動作するアプリケーションとして実装する。
【００４４】
ユーザ情報管理表７６は、ユーザが使用しているユーザ端末のＩＰアドレスと、ユーザのＩＤ、パスワードとをペアにして記録しておく。
【００４５】
図９にユーザ情報管理表７６の一例を示す。図９の例では、ユーザ端末１のＩＰアドレスｘ．ｘ．ｘ．ｘと、ユーザのＩＤであるｕｓｅｒ２０、ユーザのパスワードであるｕｓｅｒ２０ｐｗｄが記録されている。これらの情報は、ユーザがネットワークにログインする時に認証サーバ３０へ送信されるパケットから拾い出して記録される。
【００４６】
ユーザ端末１から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部７１はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐを利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ユーザ端末１からのパケットの送信先ＩＰアドレスはＨＧＷ７０ではないので、ＨＧＷ７０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットはパケット制御部７５へ渡す。
【００４７】
同じように、ＡＡＡＧＷ６０から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部７３はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐを利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ＡＡＡＧＷ６０からのパケットの送信先ＩＰアドレスはＨＧＷ７０ではないので、ＨＧＷ７０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットは送信部７２へ渡す。
【００４８】
送信部７４が送信すべきパケットの送信元ＩＰアドレスはＨＧＷ７０ではなく、受信部７１が受信したパケットの送信元ＩＰアドレス（例えばユーザ端末１のＩＰアドレス）である。そのため、送信部７４はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００４９】
同じように、送信部７２が送信すべきパケットの送信元ＩＰアドレスはＨＧＷ７０ではなく、受信部７３が受信したパケットの送信元ＩＰアドレス（例えばコンテンツ配信サーバ２０のＩＰアドレス）である。そのため、送信部７２はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００５０】
次に、パケット制御部７５の動作について図１０乃至図１３を参照して説明する。図１０乃至図１３はパケット制御部７５の動作を説明するフローチャートである。
【００５１】
パケット制御部７５は、受信部７１から受け取ったパケットが何であるかをチェックする。この際、ユーザがネットワークにログインするための認証要求である場合（ステップＳＦ１）、そのパケットから、送信元ＩＰアドレス、ユーザＩＤ、パスワードを取り出し、ユーザ情報管理表７６へ登録する（ステップＳＧ１）。その後、そのパケットをＡＡＡＧＷ６０へ転送する（ステップＳＧ２）。例えば、ユーザがユーザ端末１を使ってネットワークにログインする場合、ユーザ情報管理表７６は、図９に示したようになる。
【００５２】
ステップＳＦ１でネットワークログインのための認証要求であるとは判断せず（ステップＳＦ１のＮｏ）、ＩＧＭＰ　ｊｏｉｎパケット（コンテンツ視聴開始要求）であると判断した場合（ステップＳＦ２）、ユーザ情報管理表７６を参照し、前記ＩＧＭＰ　ｊｏｉｎパケットのソースＩＰに対応するユーザＩＤ、パスワードを取り出す（ステップＳＨ１）。取り出したユーザＩＤ、パスワードと前記ＩＧＭＰ　ｊｏｉｎパケットを適当なプロトコルのデータ部に詰め込み、ＡＡＡＧＷ６０へ転送する（ステップＳＨ２）。
【００５３】
また、ＩＧＭＰ　ｊｏｉｎパケットであるとは判断せず（ステップＳＦ２のＮｏ）、ＩＧＭＰ　ｌｅａｖｅパケット（コンテンツ視聴終了要求）であると判断した場合（ステップＳＦ３）、ユーザ情報管理表７６を参照し、前記ＩＧＭＰ　ｌｅａｖｅパケットのソースＩＰに対応するユーザＩＤ、パスワードを取り出す（ステップＳＩ１）。取り出したユーザＩＤ、パスワードと前記ＩＧＭＰ　ｌｅａｖｅパケットを適当なプロトコルのデータ部に埋め込み、ＡＡＡＧＷ６０へ転送する（ステップＳＩ２）。
【００５４】
上記ステップＳＨ２とステップＳＩ２で用いている「適当なプロトコル」は、ユーザＩＤ、パスワード、ＩＧＭＰ　ｊｏｉｎパケット（またはＩＧＭＰ　ｌｅａｖｅパケット）をＡＡＡＧＷ６０へ転送するという目的が達成することができるならば、ＴＣＰでもＵＤＰでも何でも良い。また、ＡＡＡＧＷ６０とＨＧＷ７０との間で共通鍵を保持し、上記情報を暗号化して送受信することでセキュリティを高めても良い。
【００５５】
ＩＧＭＰ　ｌｅａｖｅパケットであるとは判断しなかった場合（ステップＳＦ３のＮｏ）、ユーザ端末から受け取ったパケットをそのままＡＡＡＧＷ６０へ転送する（ステップＳＦ４）。
【００５６】
［シーケンス］
次に、ユーザがネットワークにログイン完了するまでの全体の動作について図１４を使って説明する。図１４はユーザがネットワークにログイン完了するまでのシーケンス図である。
（１）ユーザはネットワークにログインするために、ユーザ端末１にＩＤ、パスワード（Ｐａｓｓｗｏｒｄ）を入力する。ＩＤ、パスワードはＨＧＷ７０へ送信される。
（２）ＨＧＷ７０は、受け取ったパケットから、ユーザ端末１のＩＰアドレス、ユーザＩＤ、パスワードを取り出し、ユーザ情報管理表７６へ登録する。その後、前記パケットをＡＡＡＧＷ６０へ転送する。この時のユーザ情報管理表７６は、図９に示したようになる。
（３）ＡＡＡＧＷ６０は、ユーザＩＤ、パスワードを含んだＲＡＤＩＵＳパケット（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を認証サーバ３０へ送信する。
（４）認証サーバ３０は、ユーザＤＢ４０を参照し、正規のユーザであるかどうかを確認する。正規のユーザである場合、認証に成功した旨（Ａｃｃｅｓｓ−Ａｃｃｅｐｔパケット）をＡＡＡＧＷ６０へ送信する。
（５）ＡＡＡＧＷ６０は、認証成功（Ａｕｔｈｅｎｔｉｃａｔｅ−Ａｃｋ）をＨＧＷ７０へ返す。
（６）ＨＧＷ７０は、認証成功をユーザ端末１へ転送する。認証失敗を受け取った場合には、上記（２）でユーザ情報管理表７６へ登録したユーザデータを消去する。
【００５７】
次に、コンテンツを視聴開始するまでの全体の動作について図１５を使って説明する。図１５はコンテンツを視聴開始するまでのシーケンス図を示す。
（７）ユーザはユーザ端末１から欲しいコンテンツ（＝Ｇｒｏｕｐ　Ａｄｄｒｅｓｓ）を含んだＩＧＭＰ　ｊｏｉｎパケットを送信する。
（８）ＨＧＷ７０は、ユーザ情報管理表７６を参照し、ＩＧＭＰ　ｊｏｉｎパケットの送信元ＩＰアドレスに対応するユーザＩＤ、パスワードを取り出す。そのユーザＩＤ、パスワードとＩＧＭＰ　ｊｏｉｎパケットをデータ部に詰め込み、ＡＡＡＧＷ６０へ送信する。
（９）ＡＡＡＧＷ６０は、受け取ったパケットの中からユーザＩＤとパスワード、グループアドレスを取り出し、認証サーバ３０へ認証要求パケットとして送信する。
（１０）認証サーバ３０は、ユーザＤＢ４０を参照して、ＩＤ、パスワード、グループアドレスをチェックする。認証に成功した場合は、ＡＡＡＧＷ６０へ認証成功パケット（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を返す。
（１１）認証成功を受け取ったＡＡＡＧＷ６０は、ＩＧＭＰ　ｊｏｉｎパケットをＩＧＭＰルータ５０へ転送する。
（１２）コンテンツがユーザ端末１へ転送される。
（１３）ＡＡＡＧＷ６０は、課金情報（ユーザＩＤ、ユーザが参加したグループアドレス、視聴開始時刻など）を課金サーバ５へ送信する。
（１４）課金サーバ５は、課金情報を受け取った後、正常に受け取ったことを知らせる応答パケット（ｒｅｓｐｏｎｓｅ）をＡＡＡＧＷ６０へ返す。
【００５８】
次に、コンテンツを視聴終了するまでの全体の動作について図１６を使って説明する。図１６はコンテンツを視聴終了するまでのシーケンス図を示す。
（１５）ユーザはユーザ端末１からＧｒｏｕｐ　Ａｄｄｒｅｓｓを含んだＩＧＭＰ　ｌｅａｖｅパケットを送信する。
（１６）ＨＧＷ７０は、ユーザ情報管理表７６を参照し、ＩＧＭＰ　ｌｅａｖｅパケットの送信元ＩＰアドレスに対応するユーザＩＤ、パスワードを取り出す。そのユーザＩＤ、パスワードとＩＧＭＰ　ｌｅａｖｅパケットをデータ部に詰め込み、ＡＡＡＧＷ６０へ送信する。
（１７）ＡＡＡＧＷ６０は、受け取ったパケットの中からユーザＩＤとパスワード、グループアドレスを取り出し、認証サーバ３０へ認証要求パケットとして送信する。
（１８）認証サーバ３０は、ユーザＤＢ４０を参照して、ＩＤ、パスワード、グループアドレスをチェックする。認証に成功した場合は、ＡＡＡＧＷ６０へ認証成功パケット（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を返す。
（１９）認証成功を受け取ったＡＡＡＧＷ６０は、ＩＧＭＰ　ｌｅａｖｅパケットをＩＧＭＰルータ５０へ転送する。
（２０）ユーザ端末１へのコンテンツ転送が中止される。
（２１）ＡＡＡＧＷ６０は、課金情報（ユーザＩＤ、ユーザが退去したグループアドレス、視聴終了時刻など）を課金サーバ５へ送信する。
（２２）課金サーバ５は、課金情報を受け取った後、正常に受け取ったことを知らせる応答パケットをＡＡＡＧＷ６０へ返す。
【００５９】
ユーザが視聴しているコンテンツを切り替えるためには、上記図１６の処理を行い、現在のコンテンツの視聴終了を行って、その後、図１５の視聴開始処理を行う。
【００６０】
（実施の形態のバリエーション）
なお、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲によって示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。
【００６１】
例えば、上記実施の形態では、コンテンツ認証の契機としてＩＧＭＰを取り上げているが、ＩＧＭＰ以外でも良い。
【００６２】
また、上記実施の形態では、ユーザがネットワークにログインする時にはＰＰＰを用い、ＡＡＡＧＷ６０−認証サーバ間とＡＡＡＧＷ６０−課金サーバ間はＲＡＤＩＵＳプロトコル、マルチキャスト制御プロトコルにはＩＧＭＰｖ２を用いることを想定しているが、他のプロトコルを使っても良い。
【００６３】
また、上記実施の形態では、ユーザ端末１に固定ＩＰアドレス（ユーザに一意のＩＰアドレスが予め割り当てられており、ログインする度にＩＰアドレスは変わらない）が割り当てられていることを前提としているが、ログイン時にＩＰアドレスを割り当てるようにしても良い。また、ＩＰアドレスの代わりにＭＡＣアドレスなど、ユーザを一意に特定する情報であれば、何でも良い。
【００６４】
さらに、上記実施の形態では、ＡＡＡＧＷ６０やＨＧＷ７０の機能はＬｉｎｕｘ上で動作するアプリケーションとして実装する例を示しているが、他のＯＳを使っても良いし、一部または全ての機能をカーネル内に実装しても良い。また、ハードウェアで実装しても良い。
【００６５】
また、ＡＡＡＧＷ６０やＨＧＷ７０はＩＧＭＰ　ｊｏｉｎパケットとＩＧＭＰｌｅａｖｅパケットを受け取らないルータソフトウェアを動作させ（例えば、ｒｏｕｔｅｄやｍｒｏｕｔｅｄなどでＩＧＭＰ　ｊｏｉｎとＩＧＭＰ　ｌｅａｖｅパケットが来たら捨てるように改造したもの）、ＩＧＭＰ　ｊｏｉｎとＩＧＭＰ　ｌｅａｖｅは別途拾い上げて上記実施の形態のパケット制御部６７やパケット制御部７５で処理させても良い。
【００６６】
さらに、上記実施の形態では、ユーザ端末１にグローバルＩＰアドレスが割り当てられる例を示しているが、ＨＧＷ７０にＩＰマスカレード機能を持たせることによって、ＨＧＷ７０にグローバルＩＰアドレスを与え、ユーザ端末１はローカルＩＰアドレスを与えても良い。
【００６７】
さらに、上記実施の形態では、ＨＧＷ７０配下にユーザ端末が１つの場合を示しているが、２つ以上存在しても良い。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、ユーザ端末に認証要求やコンテンツ復号のためのハードウェアやソフトウェアをインストールしたり、設定したり、コンテンツを獲得する毎にＩＤやパスワードを入力したりすることなく、ユーザを認証してコンテンツを配信し、課金を適切に行うことができる。また、一般に使われている製品や標準のプロトコルを改造せずそのまま利用することができるため、開発し易く、事業導入し易いものを提供できる。また、ユーザ宅内に設置されたホームゲートウェイがユーザの代わりにＩＤ、パスワードの入力を代行してくれるため、シングルサインオンが実現できる。さらにまた、ホームゲートウェイ−認証・課金ゲートウェイ間で暗号化して通信することで、よりいっそうセキュリティを高めることができる。さらに、コンテンツ獲得開始要求やコンテンツ獲得終了要求を契機にした課金情報を基にして、ＰＰＶ課金や時間課金、従量課金など、コンテンツ毎に様々な課金を行うことができる。
【図面の簡単な説明】
【図１】本発明のコンテンツ配信システムの実施の形態の一例を示す構成図
【図２】ユーザデータベースの記憶内容の一例を示す説明図
【図３】ＡＡＡＧＷの詳細を示すブロック構成図
【図４】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図５】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図６】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図７】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図８】ＨＧＷの詳細を示すブロック構成図
【図９】ユーザ情報管理表の一例を示す説明図
【図１０】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１１】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１２】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１３】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１４】ネットワークログイン時の動作を説明するシーケンス図
【図１５】視聴開始の動作を説明するシーケンス図
【図１６】視聴終了の動作を説明するシーケンス図
【図１７】従来のコンテンツ配信システムの一例を示す構成図
【符号の説明】
１：ユーザ端末、５：課金サーバ、２０：コンテンツ配信サーバ、３０：認証サーバ、４０：ユーザデータベース、５０：ＩＧＭＰルータ、６０：課金・認証ゲートウェイ（ＡＡＡＧＷ）、７０：ホームゲートウェイ（ＨＧＷ）。
【図１】
2004078424.tif 000003
【図２】
2004078424.tif 000004
【図３】
2004078424.tif 000005
【図４】
2004078424.tif 000006
【図５】
2004078424.tif 000007
【図６】
2004078424.tif 000008
【図７】
2004078424.tif 000009
【図８】
2004078424.tif 000010
【図９】
2004078424.tif 000011
【図１０】
2004078424.tif 000012
【図１１】
2004078424.tif 000013
【図１２】
2004078424.tif 000014
【図１３】
2004078424.tif 000015
【図１４】
2004078424.tif 000016
【図１５】
2004078424.tif 000017
【図１６】
2004078424.tif 000018
【図１７】
2004078424.tif 000019