JP2004078424A

Movatterモバイル変換

Info

Publication number: JP2004078424A
Application number: JP2002235893A
Authority: JP
Inventors: Takeshi Mishima; 三島　健
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2002-08-13
Filing date: 2002-08-13
Publication date: 2004-03-11

Abstract

【課題】ユーザ端末にハードウェアやソフトウェアをインストールしたり、コンテンツの獲得毎にＩＤやパスワードを入力するような繁雑な作業を必要としないコンテンツの配信を実現すること。
【解決手段】ユーザＩＤ及びパスワードをＩＰアドレスとペアで保持する機能を備え、ユーザからコンテンツ要求を受信するとユーザＩＤ及びパスワードとともに事業者側へ転送するホームゲートウェイ７０をユーザ宅内に設置するとともに、コンテンツ要求とともに送られてきたユーザＩＤ及びパスワードを認証サーバ３０へ送って認証させ、認証に成功した場合は前記コンテンツ要求をコンテンツ配信サーバ２０へ転送する課金・認証ゲートウェイ６０を事業者側に設置することにより、コンテンツの復号、ＩＤやパスワードの入力などが不要なコンテンツの配信を可能とする。
【選択図】　　　　　　図１An object of the present invention is to realize content distribution that does not require complicated work such as installing hardware or software on a user terminal or inputting an ID or a password every time content is acquired.
A home gateway is provided in a user's home, having a function of holding a user ID and a password in a pair with an IP address, and transferring a content request from a user to a business operator along with the user ID and a password. A billing / authentication gateway 60 for transferring the content request to the content distribution server 20 if the user ID and password sent together with the request are sent to the authentication server 30 for authentication and succeeding in the authentication is installed on the business side. Accordingly, it is possible to decrypt contents and distribute contents that do not require input of an ID or a password.
[Selection diagram] Fig. 1

Description

Translated fromJapanese

【０００１】
【発明の属する技術分野】
本発明は、映像などのコンテンツをネットワークを介してユーザに提供し、課金を行うコンテンツ配信システム、コンテンツ配信方法、ホームゲートウェイ及び認証・課金ゲートウェイに関する。
【０００２】
【従来の技術】
従来、コンテンツ配信システムとして、図１７に示すシステムが提案されている。本例では、契約者のみにコンテンツを提供し、コンテンツ毎に課金する、いわゆるペイパービュー（Ｐａｙ　Ｐｅｒ　Ｖｉｅｗ：ＰＰＶ）課金方式のシステムについて例示している。
【０００３】
このコンテンツ配信システムは、図１７に示すように、ユーザ端末１と、暗号化されたコンテンツをユーザ端末１に配信するコンテンツ配信サーバ２と、契約ユーザかどうかを認証する認証サーバ３と、暗号化されたコンテンツを復号するキーを発行する復号キー管理サーバ４と、認証サーバ３のログを元にして課金を行う課金サーバ５とを備えている。
【０００４】
ユーザがコンテンツを視聴開始するまでの動作について説明する。
（１）ユーザ端末１には、コンテンツ配信サーバ２から暗号化されたコンテンツが配信される。この段階では暗号化されているため、ユーザはコンテンツを視聴することはできない。
（２）ユーザは、認証サーバ３へＩＤとパスワード（Ｐａｓｓｗｏｒｄ）を送信する。
（３）認証サーバ３は、ＩＤとパスワードから正しいユーザであるかどうかを判定する。正しいユーザである場合、復号キー管理サーバ４に対して復号キーを発行するように依頼する。
（４）復号キー管理サーバ４は、復号キーをユーザ端末１へ送信する。
（５）ユーザ端末１は、復号キーを使ってコンテンツを復号する。ユーザはコンテンツを視聴することができるようになる。
（６）認証サーバ３は、どのユーザがどんなコンテンツを購入したかなどの情報を課金サーバ５へ転送する。課金サーバ５はこの情報を元にして、ＰＰＶ課金を行う。
【０００５】
【発明が解決しようとする課題】
上述のように、従来のコンテンツ配信システムでは、認証サーバでユーザを特定し、そのユーザにだけ復号キーを渡してコンテンツを視聴できるようにするという方式を採用している。これにより、前記認証サーバのログを使ってコンテンツを獲得（視聴）したユーザにだけＰＰＶ課金を行うことができる。
【０００６】
しかし、上記システムを利用するには、ユーザ自身がユーザ端末に認証要求やコンテンツ復号のためのハードウェアやソフトウェアをインストールしたり、設定したりする必要があるという問題があった。また、ユーザはコンテンツを獲得する毎にユーザＩＤやパスワードを入力する手間がかかるという問題があった。
【０００７】
本発明は、上記事情を鑑みてなされたものであり、その目的とするところは、ユーザ端末にハードウェアやソフトウェアをインストールしたり、設定したり、コンテンツを獲得する毎にＩＤやパスワードを入力したりする繁雑な作業を必要としないコンテンツ配信システム、ホームゲートウェイ及び認証・課金ゲートウェイを提供することにある。
【０００８】
また、一般に使われている製品や標準のプロトコルを改造せずそのまま利用することができ、開発し易く、事業導入し易いコンテンツ配信システム、コンテンツ配信方法、ホームゲートウェイ及び認証・課金ゲートウェイを提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明は、ユーザからのコンテンツ獲得開始要求を受信するとコンテンツをそのままユーザへ配信するコンテンツ配信サーバと、ユーザＩＤ及びパスワードを基に認証する認証サーバとを含む事業者が、コンテンツ獲得毎に認証を行ってユーザへコンテンツを配信するシステムであって、ユーザ側に、ユーザＩＤ及びパスワードを記録する手段と、ユーザからのコンテンツ獲得開始要求を保持する手段と、前記コンテンツ獲得開始要求を基に前記記録手段が記録しているユーザＩＤ及びパスワードを取り出す手段と、前記コンテンツ獲得開始要求、ユーザＩＤ及びパスワードを含む情報を事業者側へ転送する手段とを備えたホームゲートウェイを設けるとともに、事業者側に、前記情報を保持する手段と、前記情報のうちユーザＩＤ及びパスワードを認証サーバへ転送する手段と、認証サーバから認証に成功した旨を受信した場合にはコンテンツ獲得開始要求をコンテンツ配信サーバへ転送する手段とを備えた認証・課金ゲートウェイを設けたことを特徴とする。
【００１０】
本発明によれば、ユーザ端末にはコンテンツがそのまま、つまり暗号化されないまま配信され、また、コンテンツ獲得開始要求を基にユーザＩＤ及びパスワードを取り出して認証するため、ユーザ端末に認証要求やコンテンツ復号のためのハードウェアやソフトウェアをインストールしたり、設定したり、コンテンツを獲得する毎にＩＤやパスワードを入力したりすることなく、コンテンツを獲得できる。また、一般に使われている製品や標準のプロトコルを改造せずそのまま利用することができるため、開発し易く、事業導入し易いものを提供できる。さらに、ユーザ側に設置されたホームゲートウェイがユーザの代わりにＩＤとパスワードの入力を代行してくれるため、シングルサインオンが実現できる。さらに、ホームゲートウェイ及び認証・課金ゲートウェイ間で暗号化して通信することで、よりいっそうセキュリティを高めることができる。さらに、コンテンツ獲得開始要求やコンテンツ獲得終了要求を契機にした課金情報を基にして、ＰＰＶ課金や時間課金、従量課金など、コンテンツ毎に様々な課金を行うことができる。
【００１１】
【発明の実施の形態】
（第１の実施の形態）
以下、本発明のコンテンツ配信システムについて図面を参照して説明する。
【００１２】
図１は本発明のコンテンツ配信システムの第１の実施の形態を示す全体構成図である。なお、本実施の形態ではマルチキャストでストリーミングコンテンツをユーザへ配信するシステムを例示する。また、ルータはＩＧＭＰバージョン２（詳細はＲＦＣ２２３６を参照）を実装している場合を例示する。
【００１３】
このコンテンツ配信システムは、図１に示すように、ユーザ端末１と、課金サーバ５と、ストリーミングコンテンツをユーザ端末１へ配信するコンテンツ配信サーバ２０と、ユーザを認証するための認証サーバ３０と、認証用のユーザ情報を保持するユーザデータベース（ＤＢ）４０と、マルチキャストプロトコルＩＧＭＰバージョン２を実装しているルータ５０と、認証サーバ３０及び課金サーバ５と協調動作する機能（後述する）を持った認証・課金ゲートウェイ（ＡＡＡＧＷ）６０と、通常のルータの機能並びにＡＡＡＧＷ６０と協調動作する機能（後述する）を併せ持ったホームゲートウェイ（ＨＧＷ）７０とを備えている。
【００１４】
なお、ＡＡＡＧＷ６０はコンテンツ配信サーバ２０、認証サーバ３０、課金サーバ５とともに事業者（サービス提供者）側に設置され、ＨＧＷ７０はユーザ側（ユーザ宅内）に設置される。
【００１５】
ユーザ端末１は、グローバルＩＰアドレスであるｘ．ｘ．ｘ．ｘを予め設定されているものとする。
【００１６】
課金サーバ５は、あるユーザＩＤの課金情報（例えば、いつ、どのコンテンツを購入したかなどの情報）を受け取ると、ＡＡＡＧＷへＡｃｃｏｕｎｔｉｎｇ−Ｒｅｓｐｏｎｓｅを返す。
【００１７】
認証サーバ３０は、あるユーザＩＤに対して認証に成功した場合、ＡＡＡＧＷ６０へＡｃｃｅｓｓ−Ａｃｃｅｐｔを返し、認証に失敗した場合、Ａｃｃｅｓｓ−Ｒｅｊｅｃｔを返す。
【００１８】
図２にユーザＤＢ４０の記憶内容の一例を示す。図２の例では、ユーザＤＢ４０は、ユーザＩＤ、パスワード、現在ログインしているかどうかを示すログイン情報、認証に何回失敗したかを示す認証カウンタ、ユーザが参加できるグループアドレスから構成されている。ここで、１つのグループアドレスは、１つのコンテンツに対応している。
【００１９】
ユーザがログインしていない場合はログイン情報を「０」にしておき、ログイン中である間はログイン情報を「１」にセットする。ログアウトすると、再び「０」にリセットする。
【００２０】
認証サーバ３０は、二重ログインを防止するため、あるユーザＩＤのユーザがログイン中には同じユーザＩＤでログインできないようにする機能を有する。これを実現するためには、認証時にログイン情報をチェックし、「１」であればログインを拒否する。
【００２１】
また、認証サーバ３０は、不正アクセスを防止するため、ある認証回数を越えたらログインを拒否する。例えば、認証失敗回数の許容値を「３」とすると、認証が失敗する毎に認証カウンタ値を一つずつ増やし、３回になった場合は以後の認証は全て拒否する。
【００２２】
さらに、不正アクセス防止を強化するため、タイマを設定し、ある時間以内に認証が成功しない場合はログインを拒否するような機能を認証サーバ３０に持たせても良い。
【００２３】
図２の例では、ｕｓｅｒ２１がログイン中であるため、ログイン中であることを示すログイン情報は「１」である。また、認証は失敗せずに一回で成功したので、認証カウンタは「０」である。また、ｕｓｅｒ２１はグループアドレス２２４．１．１．１に対応するコンテンツだけを獲得（視聴）することができる。ｕｓｅｒ２０とｕｓｅｒ２２はネットワークにログインしていない。ｕｓｅｒ２０はグループアドレス２２４．１．１．１と２２４．１．１．２に対応するコンテンツを視聴可能である。ｕｓｅｒ２２はグループアドレス２２４．１．１．１と２２４．１．１．３に対応するコンテンツを視聴可能である。
【００２４】
［ＡＡＡＧＷ］
次に、ＡＡＡＧＷ６０の機能を説明する。図３にＡＡＡＧＷ６０の詳細なブロック構成図を示す。
【００２５】
ＡＡＡＧＷ６０は、ＨＧＷ７０からパケットを受信する受信部６１と、ＨＧＷ７０へパケットを送信する送信部６２と、ＩＧＭＰルータ５０からパケットを受信する受信部６３と、ＩＧＭＰルータ５０へパケットを送信する送信部６４と、認証サーバ３０または課金サーバ５からパケットを受信する受信部６５と、認証サーバ３０または課金サーバ５へパケットを送信する送信部６６と、受信部６１が受信したパケットのタイプにより、後述する適切な処理を行った後、どこにどんなパケットを送信するかを決定するパケット制御部６７とから構成される。これらの機能は、Ｌｉｎｕｘ（登録商標）上で動作するアプリケーションとして実装する。
【００２６】
ＨＧＷ７０から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部６１はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐ（ｆｔｐ：／／ｆｔｐ．ｅｅ．ｌｂｌ．ｇｏｖ／ｌｉｂｐｃａｐ．ｔａｒ．Ｚ）を利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ＨＧＷ７０からのパケットの送信先ＩＰアドレスはＡＡＡＧＷ６０ではないので、ＡＡＡＧＷ６０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットはパケット制御部６７へ渡す。
【００２７】
同じように、ＩＧＭＰルータ５０から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部６３はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐ（ｆｔｐ：／／ｆｔｐ．ｅｅ．ｌｂｌ．ｇｏｖ／ｌｉｂｐｃａｐ．ｔａｒ．Ｚ）を利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ＩＧＭＰルータ５０からのパケットの送信先ＩＰアドレスはＡＡＡＧＷ６０ではないので、ＡＡＡＧＷ６０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットは送信部６２へ渡す。
【００２８】
認証サーバ３０あるいは課金サーバ５にとってＡＡＡＧＷ６０は通常のクライアントとして扱えるので、受信部６５及び送信部６６は通常のｓｏｃｋｅｔを使って受信及び送信する。受信部６５が受信したパケットはパケット制御部６７へ渡す。送信部６６は、パケット制御部６７からパケットを受けとり、認証サーバ３０あるいは課金サーバ５へパケットを送信する。
【００２９】
送信部６４が送信すべきパケットの送信元ＩＰアドレスはＡＡＡＧＷ６０ではなく、受信部６１が受信したパケットの送信元ＩＰアドレス（例えばユーザ端末１のＩＰアドレス）である。そのため、送信部６４はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００３０】
同じように、送信部６２が送信すべきパケットの送信元ＩＰアドレスはＡＡＡＧＷ６０ではなく、受信部６３が受信したパケットの送信元ＩＰアドレス（例えばコンテンツ配信サーバ２０のＩＰアドレス）である。そのため、送信部６２はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００３１】
次に、パケット制御部６７の動作について図４乃至図７を参照して説明する。図４乃至図７はパケット制御部６７の動作を説明するフローチャートである。
【００３２】
パケット制御部６７は、受信部６１から受け取ったパケットが何であるかをチェックする。この際、ユーザがネットワークにログインするための認証要求である場合（ステップＳＡ１）、Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ（ＩＤ、パスワードを含んだ認証要求パケット）を認証サーバ３０へ送信する（ステップＳＢ１）。認証サーバ３０は、ＩＤ、パスワードから正当なユーザかどうかを判断し、認証結果をＡＡＡＧＷ６０へ返信する（ステップＳＢ２）。ここで、認証結果とは、認証サーバ３０が正当なユーザと判断した場合、Ａｃｃｅｓｓ−ＡｃｃｅｐｔをＡＡＡＧＷ６０へ返し、正当ではないと判断した場合、Ａｃｃｅｓｓ−ＲｅｊｅｃｔをＡＡＡＧＷ６０へ返す。ＡＡＡＧＷ６０は、認証結果をＨＧＷ７０へ転送する（ステップＳＢ３）。
【００３３】
ステップＳＡ１でネットワークログインのための認証要求であるとは判断せず（ステップＳＡ１のＮｏ）、コンテンツ視聴開始要求であると判断した場合（ステップＳＡ２）、ＡＡＡＧＷ６０は、コンテンツ視聴開始要求のためのＡｃｃｅｓｓ−Ｒｅｑｕｅｓｔ（ＩＤ、パスワード、視聴したいコンテンツのグループアドレスを含むパケット）を認証サーバ３０へ送信する（ステップＳＣ１）。認証サーバ３０は、図２に示すような情報と、送信されてきたＩＤ、パスワード、グループアドレスを比較して、正当かどうかを判断する。
【００３４】
正当である場合（ステップＳＣ２のＹｅｓ）、認証サーバ３０はＡｃｃｅｓｓ−ＡｃｃｅｐｔをＡＡＡＧＷ６０へ返す。ＡＡＡＧＷ６０は、ＩＧＭＰ　ｊｏｉｎパケット（参加したいグループアドレスを含んだＭｅｍｂｅｒｓｈｉｐ　Ｒｅｐｏｒｔパケット、ヘッダタイプは０ｘ１６）をＩＧＭＰルータ５０へ送信する（ステップＳＣ３）。ＩＧＭＰ　ｊｏｉｎパケットを受け取ったＩＧＭＰルータ５０は、指定されたグループアドレスに対応するコンテンツをユーザ端末１へ送信開始する。ＡＡＡＧＷ６０は、課金情報（ＩＤ、グループアドレス、視聴開始時刻など）を課金サーバ５へ送信する（ステップＳＣ４）。課金サーバ５は、受け取った課金情報をハードディスクなどに蓄積し終えたら、ＡＡＡＧＷ６０へ蓄積完了したことを通知する（ステップＳＣ５）。
【００３５】
ステップＳＣ２で正当ではないと判断した場合（ステップＳＣ２のＮｏ）、コンテンツ視聴開始要求を破棄する（ステップＳＣ６）とともに、ユーザ端末１にその旨を通知する（ステップＳＣ７）。
【００３６】
また、コンテンツ視聴開始要求であるとは判断せず（ステップＳＡ２のＮｏ）、コンテンツ視聴終了要求であると判断した場合（ステップＳＡ３）、ＡＡＡＧＷ６０は、コンテンツ視聴終了要求のためのＡｃｃｅｓｓ−Ｒｅｑｕｅｓｔ（ＩＤ、パスワード、視聴終了したいコンテンツのグループアドレスを含むパケット）を認証サーバ３０へ送信する（ステップＳＤ１）。認証サーバ３０は、図２に示すような情報と、送信されてきたＩＤ、パスワード、グループアドレスを比較して、正当かどうかを判断する。
【００３７】
正当である場合（ステップＳＤ２のＹｅｓ）、認証サーバ３０はＡｃｃｅｓｓ−ＡｃｃｅｐｔをＡＡＡＧＷ６０へ返す。ＡＡＡＧＷ６０は、ＩＧＭＰ　ｌｅａｖｅパケット（Ｌｅａｖｅ　Ｇｒｏｕｐパケット、ヘッダタイプが０ｘ１７）をＩＧＭＰルータ５０へ送信する（ステップＳＤ３）。ＩＧＭＰ　ｌｅａｖｅパケットを受け取ったＩＧＭＰルータ５０は、指定されたグループアドレスに対応するコンテンツのユーザ端末１への送信を停止する。ＡＡＡＧＷ６０は、課金情報（ＩＤ、グループアドレス、視聴終了時刻など）を課金サーバ５へ送信する（ステップＳＤ４）。課金サーバ５は、受け取った課金情報をハードディスクなどに蓄積し終えたら、ＡＡＡＧＷ６０へ蓄積完了したことを通知する（ステップＳＤ５）。
【００３８】
ステップＳＤ２で正当ではないと判断した場合（ステップＳＤ２のＮｏ）、コンテンツ視聴終了要求を破棄する（ステップＳＤ６）とともに、ユーザ端末１にその旨を通知する（ステップＳＤ７）。
【００３９】
コンテンツ視聴終了要求であるとは判断しなかった場合（ステップＳＡ３のＮｏ）、受け取ったパケットをそのままＩＧＭＰルータ５０へ転送する（ステップＳＡ４）。
【００４０】
ステップＳＤ４、ＳＤ５は、従量課金、時間課金など、スタート時間とストップ時間が必要な場合には必要なステップである。一方、一旦、購入を決めたら、そのコンテンツを実際に利用しようとしまいと課金する場合には、ステップＳＣ４、ＳＣ５のみ必要であり、ステップＳＤ４、ＳＤ５は必要ない。例えば、レンタルビデオのような映画コンテンツの場合、一旦、購入を決めたら、ユーザが全ての映画を見ようとみまいと一律料金を課金する場合などである。
【００４１】
［ＨＧＷ］
【００４２】
次に、ＨＧＷ７０の機能を説明する。図８にＨＧＷ７０の詳細なブロック構成図を示す。
【００４３】
ＨＧＷ７０は、ユーザ端末１からパケットを受信する受信部７１と、ユーザ端末１へパケットを送信する送信部７２と、ＡＡＡＧＷ６０からパケットを受信する受信部７３と、ＡＡＡＧＷ６０へパケットを送信する送信部７４と、ユーザに対応するＩＤとパスワードを管理するパケット制御部７５と、パケット制御部７５がユーザ情報を記録するために使うユーザ情報管理表７６とから構成される。これらの機能は、Ｌｉｎｕｘ上で動作するアプリケーションとして実装する。
【００４４】
ユーザ情報管理表７６は、ユーザが使用しているユーザ端末のＩＰアドレスと、ユーザのＩＤ、パスワードとをペアにして記録しておく。
【００４５】
図９にユーザ情報管理表７６の一例を示す。図９の例では、ユーザ端末１のＩＰアドレスｘ．ｘ．ｘ．ｘと、ユーザのＩＤであるｕｓｅｒ２０、ユーザのパスワードであるｕｓｅｒ２０ｐｗｄが記録されている。これらの情報は、ユーザがネットワークにログインする時に認証サーバ３０へ送信されるパケットから拾い出して記録される。
【００４６】
ユーザ端末１から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部７１はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐを利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ユーザ端末１からのパケットの送信先ＩＰアドレスはＨＧＷ７０ではないので、ＨＧＷ７０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットはパケット制御部７５へ渡す。
【００４７】
同じように、ＡＡＡＧＷ６０から送信されてくるパケットをアプリケーションレイヤで受信するために、受信部７３はｒａｗ　ｓｏｃｋｅｔにフィルタ機能を追加したｌｉｂｐｃａｐを利用することによって、データリンク層からパケットを受信する。ｒａｗ　ｓｏｃｋｅｔを使う理由は、ＡＡＡＧＷ６０からのパケットの送信先ＩＰアドレスはＨＧＷ７０ではないので、ＨＧＷ７０は通常のｓｏｃｋｅｔでは受信できないからである。受信したパケットは送信部７２へ渡す。
【００４８】
送信部７４が送信すべきパケットの送信元ＩＰアドレスはＨＧＷ７０ではなく、受信部７１が受信したパケットの送信元ＩＰアドレス（例えばユーザ端末１のＩＰアドレス）である。そのため、送信部７４はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００４９】
同じように、送信部７２が送信すべきパケットの送信元ＩＰアドレスはＨＧＷ７０ではなく、受信部７３が受信したパケットの送信元ＩＰアドレス（例えばコンテンツ配信サーバ２０のＩＰアドレス）である。そのため、送信部７２はｒａｗ　ｓｏｃｋｅｔを使って送信する。
【００５０】
次に、パケット制御部７５の動作について図１０乃至図１３を参照して説明する。図１０乃至図１３はパケット制御部７５の動作を説明するフローチャートである。
【００５１】
パケット制御部７５は、受信部７１から受け取ったパケットが何であるかをチェックする。この際、ユーザがネットワークにログインするための認証要求である場合（ステップＳＦ１）、そのパケットから、送信元ＩＰアドレス、ユーザＩＤ、パスワードを取り出し、ユーザ情報管理表７６へ登録する（ステップＳＧ１）。その後、そのパケットをＡＡＡＧＷ６０へ転送する（ステップＳＧ２）。例えば、ユーザがユーザ端末１を使ってネットワークにログインする場合、ユーザ情報管理表７６は、図９に示したようになる。
【００５２】
ステップＳＦ１でネットワークログインのための認証要求であるとは判断せず（ステップＳＦ１のＮｏ）、ＩＧＭＰ　ｊｏｉｎパケット（コンテンツ視聴開始要求）であると判断した場合（ステップＳＦ２）、ユーザ情報管理表７６を参照し、前記ＩＧＭＰ　ｊｏｉｎパケットのソースＩＰに対応するユーザＩＤ、パスワードを取り出す（ステップＳＨ１）。取り出したユーザＩＤ、パスワードと前記ＩＧＭＰ　ｊｏｉｎパケットを適当なプロトコルのデータ部に詰め込み、ＡＡＡＧＷ６０へ転送する（ステップＳＨ２）。
【００５３】
また、ＩＧＭＰ　ｊｏｉｎパケットであるとは判断せず（ステップＳＦ２のＮｏ）、ＩＧＭＰ　ｌｅａｖｅパケット（コンテンツ視聴終了要求）であると判断した場合（ステップＳＦ３）、ユーザ情報管理表７６を参照し、前記ＩＧＭＰ　ｌｅａｖｅパケットのソースＩＰに対応するユーザＩＤ、パスワードを取り出す（ステップＳＩ１）。取り出したユーザＩＤ、パスワードと前記ＩＧＭＰ　ｌｅａｖｅパケットを適当なプロトコルのデータ部に埋め込み、ＡＡＡＧＷ６０へ転送する（ステップＳＩ２）。
【００５４】
上記ステップＳＨ２とステップＳＩ２で用いている「適当なプロトコル」は、ユーザＩＤ、パスワード、ＩＧＭＰ　ｊｏｉｎパケット（またはＩＧＭＰ　ｌｅａｖｅパケット）をＡＡＡＧＷ６０へ転送するという目的が達成することができるならば、ＴＣＰでもＵＤＰでも何でも良い。また、ＡＡＡＧＷ６０とＨＧＷ７０との間で共通鍵を保持し、上記情報を暗号化して送受信することでセキュリティを高めても良い。
【００５５】
ＩＧＭＰ　ｌｅａｖｅパケットであるとは判断しなかった場合（ステップＳＦ３のＮｏ）、ユーザ端末から受け取ったパケットをそのままＡＡＡＧＷ６０へ転送する（ステップＳＦ４）。
【００５６】
［シーケンス］
次に、ユーザがネットワークにログイン完了するまでの全体の動作について図１４を使って説明する。図１４はユーザがネットワークにログイン完了するまでのシーケンス図である。
（１）ユーザはネットワークにログインするために、ユーザ端末１にＩＤ、パスワード（Ｐａｓｓｗｏｒｄ）を入力する。ＩＤ、パスワードはＨＧＷ７０へ送信される。
（２）ＨＧＷ７０は、受け取ったパケットから、ユーザ端末１のＩＰアドレス、ユーザＩＤ、パスワードを取り出し、ユーザ情報管理表７６へ登録する。その後、前記パケットをＡＡＡＧＷ６０へ転送する。この時のユーザ情報管理表７６は、図９に示したようになる。
（３）ＡＡＡＧＷ６０は、ユーザＩＤ、パスワードを含んだＲＡＤＩＵＳパケット（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を認証サーバ３０へ送信する。
（４）認証サーバ３０は、ユーザＤＢ４０を参照し、正規のユーザであるかどうかを確認する。正規のユーザである場合、認証に成功した旨（Ａｃｃｅｓｓ−Ａｃｃｅｐｔパケット）をＡＡＡＧＷ６０へ送信する。
（５）ＡＡＡＧＷ６０は、認証成功（Ａｕｔｈｅｎｔｉｃａｔｅ−Ａｃｋ）をＨＧＷ７０へ返す。
（６）ＨＧＷ７０は、認証成功をユーザ端末１へ転送する。認証失敗を受け取った場合には、上記（２）でユーザ情報管理表７６へ登録したユーザデータを消去する。
【００５７】
次に、コンテンツを視聴開始するまでの全体の動作について図１５を使って説明する。図１５はコンテンツを視聴開始するまでのシーケンス図を示す。
（７）ユーザはユーザ端末１から欲しいコンテンツ（＝Ｇｒｏｕｐ　Ａｄｄｒｅｓｓ）を含んだＩＧＭＰ　ｊｏｉｎパケットを送信する。
（８）ＨＧＷ７０は、ユーザ情報管理表７６を参照し、ＩＧＭＰ　ｊｏｉｎパケットの送信元ＩＰアドレスに対応するユーザＩＤ、パスワードを取り出す。そのユーザＩＤ、パスワードとＩＧＭＰ　ｊｏｉｎパケットをデータ部に詰め込み、ＡＡＡＧＷ６０へ送信する。
（９）ＡＡＡＧＷ６０は、受け取ったパケットの中からユーザＩＤとパスワード、グループアドレスを取り出し、認証サーバ３０へ認証要求パケットとして送信する。
（１０）認証サーバ３０は、ユーザＤＢ４０を参照して、ＩＤ、パスワード、グループアドレスをチェックする。認証に成功した場合は、ＡＡＡＧＷ６０へ認証成功パケット（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を返す。
（１１）認証成功を受け取ったＡＡＡＧＷ６０は、ＩＧＭＰ　ｊｏｉｎパケットをＩＧＭＰルータ５０へ転送する。
（１２）コンテンツがユーザ端末１へ転送される。
（１３）ＡＡＡＧＷ６０は、課金情報（ユーザＩＤ、ユーザが参加したグループアドレス、視聴開始時刻など）を課金サーバ５へ送信する。
（１４）課金サーバ５は、課金情報を受け取った後、正常に受け取ったことを知らせる応答パケット（ｒｅｓｐｏｎｓｅ）をＡＡＡＧＷ６０へ返す。
【００５８】
次に、コンテンツを視聴終了するまでの全体の動作について図１６を使って説明する。図１６はコンテンツを視聴終了するまでのシーケンス図を示す。
（１５）ユーザはユーザ端末１からＧｒｏｕｐ　Ａｄｄｒｅｓｓを含んだＩＧＭＰ　ｌｅａｖｅパケットを送信する。
（１６）ＨＧＷ７０は、ユーザ情報管理表７６を参照し、ＩＧＭＰ　ｌｅａｖｅパケットの送信元ＩＰアドレスに対応するユーザＩＤ、パスワードを取り出す。そのユーザＩＤ、パスワードとＩＧＭＰ　ｌｅａｖｅパケットをデータ部に詰め込み、ＡＡＡＧＷ６０へ送信する。
（１７）ＡＡＡＧＷ６０は、受け取ったパケットの中からユーザＩＤとパスワード、グループアドレスを取り出し、認証サーバ３０へ認証要求パケットとして送信する。
（１８）認証サーバ３０は、ユーザＤＢ４０を参照して、ＩＤ、パスワード、グループアドレスをチェックする。認証に成功した場合は、ＡＡＡＧＷ６０へ認証成功パケット（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を返す。
（１９）認証成功を受け取ったＡＡＡＧＷ６０は、ＩＧＭＰ　ｌｅａｖｅパケットをＩＧＭＰルータ５０へ転送する。
（２０）ユーザ端末１へのコンテンツ転送が中止される。
（２１）ＡＡＡＧＷ６０は、課金情報（ユーザＩＤ、ユーザが退去したグループアドレス、視聴終了時刻など）を課金サーバ５へ送信する。
（２２）課金サーバ５は、課金情報を受け取った後、正常に受け取ったことを知らせる応答パケットをＡＡＡＧＷ６０へ返す。
【００５９】
ユーザが視聴しているコンテンツを切り替えるためには、上記図１６の処理を行い、現在のコンテンツの視聴終了を行って、その後、図１５の視聴開始処理を行う。
【００６０】
（実施の形態のバリエーション）
なお、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲によって示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。
【００６１】
例えば、上記実施の形態では、コンテンツ認証の契機としてＩＧＭＰを取り上げているが、ＩＧＭＰ以外でも良い。
【００６２】
また、上記実施の形態では、ユーザがネットワークにログインする時にはＰＰＰを用い、ＡＡＡＧＷ６０−認証サーバ間とＡＡＡＧＷ６０−課金サーバ間はＲＡＤＩＵＳプロトコル、マルチキャスト制御プロトコルにはＩＧＭＰｖ２を用いることを想定しているが、他のプロトコルを使っても良い。
【００６３】
また、上記実施の形態では、ユーザ端末１に固定ＩＰアドレス（ユーザに一意のＩＰアドレスが予め割り当てられており、ログインする度にＩＰアドレスは変わらない）が割り当てられていることを前提としているが、ログイン時にＩＰアドレスを割り当てるようにしても良い。また、ＩＰアドレスの代わりにＭＡＣアドレスなど、ユーザを一意に特定する情報であれば、何でも良い。
【００６４】
さらに、上記実施の形態では、ＡＡＡＧＷ６０やＨＧＷ７０の機能はＬｉｎｕｘ上で動作するアプリケーションとして実装する例を示しているが、他のＯＳを使っても良いし、一部または全ての機能をカーネル内に実装しても良い。また、ハードウェアで実装しても良い。
【００６５】
また、ＡＡＡＧＷ６０やＨＧＷ７０はＩＧＭＰ　ｊｏｉｎパケットとＩＧＭＰｌｅａｖｅパケットを受け取らないルータソフトウェアを動作させ（例えば、ｒｏｕｔｅｄやｍｒｏｕｔｅｄなどでＩＧＭＰ　ｊｏｉｎとＩＧＭＰ　ｌｅａｖｅパケットが来たら捨てるように改造したもの）、ＩＧＭＰ　ｊｏｉｎとＩＧＭＰ　ｌｅａｖｅは別途拾い上げて上記実施の形態のパケット制御部６７やパケット制御部７５で処理させても良い。
【００６６】
さらに、上記実施の形態では、ユーザ端末１にグローバルＩＰアドレスが割り当てられる例を示しているが、ＨＧＷ７０にＩＰマスカレード機能を持たせることによって、ＨＧＷ７０にグローバルＩＰアドレスを与え、ユーザ端末１はローカルＩＰアドレスを与えても良い。
【００６７】
さらに、上記実施の形態では、ＨＧＷ７０配下にユーザ端末が１つの場合を示しているが、２つ以上存在しても良い。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、ユーザ端末に認証要求やコンテンツ復号のためのハードウェアやソフトウェアをインストールしたり、設定したり、コンテンツを獲得する毎にＩＤやパスワードを入力したりすることなく、ユーザを認証してコンテンツを配信し、課金を適切に行うことができる。また、一般に使われている製品や標準のプロトコルを改造せずそのまま利用することができるため、開発し易く、事業導入し易いものを提供できる。また、ユーザ宅内に設置されたホームゲートウェイがユーザの代わりにＩＤ、パスワードの入力を代行してくれるため、シングルサインオンが実現できる。さらにまた、ホームゲートウェイ−認証・課金ゲートウェイ間で暗号化して通信することで、よりいっそうセキュリティを高めることができる。さらに、コンテンツ獲得開始要求やコンテンツ獲得終了要求を契機にした課金情報を基にして、ＰＰＶ課金や時間課金、従量課金など、コンテンツ毎に様々な課金を行うことができる。
【図面の簡単な説明】
【図１】本発明のコンテンツ配信システムの実施の形態の一例を示す構成図
【図２】ユーザデータベースの記憶内容の一例を示す説明図
【図３】ＡＡＡＧＷの詳細を示すブロック構成図
【図４】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図５】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図６】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図７】ＡＡＡＧＷのパケット制御部の動作を説明するフローチャート
【図８】ＨＧＷの詳細を示すブロック構成図
【図９】ユーザ情報管理表の一例を示す説明図
【図１０】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１１】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１２】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１３】ＨＧＷのパケット制御部の動作を説明するフローチャート
【図１４】ネットワークログイン時の動作を説明するシーケンス図
【図１５】視聴開始の動作を説明するシーケンス図
【図１６】視聴終了の動作を説明するシーケンス図
【図１７】従来のコンテンツ配信システムの一例を示す構成図
【符号の説明】
１：ユーザ端末、５：課金サーバ、２０：コンテンツ配信サーバ、３０：認証サーバ、４０：ユーザデータベース、５０：ＩＧＭＰルータ、６０：課金・認証ゲートウェイ（ＡＡＡＧＷ）、７０：ホームゲートウェイ（ＨＧＷ）。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a content delivery system, a content delivery method, a home gateway, and an authentication / billing gateway that provide content such as video to a user via a network and perform billing.
[0002]
[Prior art]
Conventionally, a system shown in FIG. 17 has been proposed as a content distribution system. This example illustrates a so-called pay-per-view (PPV) billing system in which content is provided only to a contractor and billed for each content.
[0003]
As shown in FIG. 17, the content distribution system includes auser terminal 1, acontent distribution server 2 that distributes the encrypted content to theuser terminal 1, anauthentication server 3 that authenticates whether or not the user is a contract user, and an encryption server. A decryptionkey management server 4 for issuing a key for decrypting the obtained content, and anaccounting server 5 for performing accounting based on the log of theauthentication server 3 are provided.
[0004]
The operation until the user starts viewing the content will be described.
(1) Thecontent distribution server 2 distributes the encrypted content to theuser terminal 1. At this stage, since the content is encrypted, the user cannot view the content.
(2) The user transmits the ID and the password (Password) to theauthentication server 3.
(3) Theauthentication server 3 determines whether or not the user is correct based on the ID and the password. If the user is a correct user, it requests the decryptionkey management server 4 to issue a decryption key.
(4) The decryptionkey management server 4 transmits the decryption key to theuser terminal 1.
(5) Theuser terminal 1 decrypts the content using the decryption key. The user can view the content.
(6) Theauthentication server 3 transfers information such as which user has purchased what content to thebilling server 5. Theaccounting server 5 performs PPV accounting based on this information.
[0005]
[Problems to be solved by the invention]
As described above, the conventional content distribution system employs a method in which a user is specified by an authentication server, and a decryption key is passed only to that user so that the content can be viewed. Thus, PPV charging can be performed only for the user who has acquired (viewed) the content using the log of the authentication server.
[0006]
However, in order to use the above system, there is a problem that the user himself needs to install or set hardware or software for authentication request or content decryption in the user terminal. In addition, there is a problem that the user has to input a user ID and a password every time the user acquires the content.
[0007]
The present invention has been made in view of the above circumstances, and its purpose is to install or set hardware or software on a user terminal or to input an ID or password every time content is acquired. Another object of the present invention is to provide a content delivery system, a home gateway, and an authentication / charging gateway that do not require complicated work.
[0008]
In addition, to provide a content distribution system, a content distribution method, a home gateway, and an authentication / billing gateway that can be used without modification to commonly used products and standard protocols and that are easy to develop and introduce into a business. It is in.
[0009]
[Means for Solving the Problems]
In order to achieve the above object, the present invention provides a content distribution server that distributes content to a user upon receiving a content acquisition start request from the user, and an authentication server that performs authentication based on a user ID and a password. Is a system that authenticates each time a content is acquired and distributes the content to a user, wherein a means for recording a user ID and a password on the user side, a means for holding a content acquisition start request from the user, A home gateway comprising: means for extracting a user ID and a password recorded by the recording means based on an acquisition start request; and means for transferring information including the content acquisition start request, a user ID and a password to a business side. A means for holding the information, and the information And a means for transferring a user ID and a password to the authentication server, and a means for transferring a content acquisition start request to the content distribution server when the authentication server receives a successful authentication from the authentication server. It is characterized by having been provided.
[0010]
According to the present invention, the content is delivered to the user terminal as it is, that is, without being encrypted, and the user ID and password are extracted and authenticated based on the content acquisition start request. Content can be obtained without installing or setting hardware or software for the user, and without inputting an ID or password every time the content is obtained. In addition, since commonly used products and standard protocols can be used without modification, it is possible to provide products that are easy to develop and easy to introduce into business. Furthermore, since the home gateway installed on the user's side performs input of the ID and password on behalf of the user, single sign-on can be realized. Furthermore, by encrypting and communicating between the home gateway and the authentication / charging gateway, security can be further improved. Further, based on charging information triggered by a content acquisition start request or a content acquisition end request, various types of charging such as PPV charging, time charging, and usage-based charging can be performed.
[0011]
BEST MODE FOR CARRYING OUT THE INVENTION
(First Embodiment)
Hereinafter, a content distribution system according to the present invention will be described with reference to the drawings.
[0012]
FIG. 1 is an overall configuration diagram showing a first embodiment of a content distribution system of the present invention. In the present embodiment, a system that distributes streaming contents to users by multicast is exemplified. Also, a case where the router implements IGMP version 2 (refer to RFC2236 for details) is illustrated.
[0013]
As shown in FIG. 1, the content distribution system includes auser terminal 1, abilling server 5, acontent distribution server 20 that distributes streaming content to theuser terminal 1, anauthentication server 30 for authenticating a user, Database (DB) 40 that stores user information for authentication, arouter 50 that implements the multicast protocol IGMPversion 2, anauthentication server 30 that has a function of cooperating with theauthentication server 30 and the billing server 5 (described later). It has a charging gateway (AAAGW) 60 and a home gateway (HGW) 70 having both the function of a normal router and the function of cooperating with the AAAGW 60 (described later).
[0014]
Note that the AAAGW 60 is installed on the side of the business operator (service provider) together with thecontent distribution server 20, theauthentication server 30, and thebilling server 5, and the HGW 70 is installed on the user side (user premises).
[0015]
Theuser terminal 1 has a global IP address x. x. x. It is assumed that x is set in advance.
[0016]
When theaccounting server 5 receives the accounting information of a certain user ID (for example, information such as when and what content was purchased), theaccounting server 5 returns an Accounting-Response to the AAAGW.
[0017]
Theauthentication server 30 returns Access-Accept to theAAAGW 60 when authentication is successful for a certain user ID, and returns Access-Reject when authentication fails.
[0018]
FIG. 2 shows an example of the contents stored in theuser DB 40. In the example of FIG. 2, theuser DB 40 includes a user ID, a password, login information indicating whether the user is currently logged in, an authentication counter indicating how many times authentication has failed, and a group address in which the user can participate. Here, one group address corresponds to one content.
[0019]
If the user has not logged in, the login information is set to “0”, and while the user is logged in, the login information is set to “1”. When the user logs out, it is reset to "0" again.
[0020]
Theauthentication server 30 has a function of preventing a user with a certain user ID from logging in with the same user ID during login in order to prevent double login. To realize this, login information is checked at the time of authentication, and if "1", login is rejected.
[0021]
Further, theauthentication server 30 rejects login if the number of authentications exceeds a certain number of times in order to prevent unauthorized access. For example, assuming that the allowable value of the number of authentication failures is “3”, the authentication counter value is incremented by one each time the authentication fails, and if the number of authentications becomes three, all subsequent authentications are rejected.
[0022]
Furthermore, in order to strengthen prevention of unauthorized access, a timer may be set, and theauthentication server 30 may have a function of rejecting login if authentication is not successful within a certain time.
[0023]
In the example of FIG. 2, since the user 21 is logging in, the login information indicating that the user is logging in is “1”. In addition, since the authentication succeeded once without failing, the authentication counter is “0”. Further, the user 21 can obtain (view) only the content corresponding to the group address 224.1.1.1.User 20 anduser 22 are not logged into the network. Theuser 20 can view contents corresponding to the group addresses 224.1.1.1 and 224.1.1.2. Theuser 22 can view the content corresponding to the group addresses 224.1.1.1 and 224.1.1.3.
[0024]
[AAAGW]
Next, the function of theAAAGW 60 will be described. FIG. 3 shows a detailed block diagram of theAAAGW 60.
[0025]
TheAAAGW 60 includes a receivingunit 61 that receives a packet from theHGW 70, a transmittingunit 62 that transmits a packet to theHGW 70, a receivingunit 63 that receives a packet from theIGMP router 50, and a transmittingunit 64 that transmits a packet to theIGMP router 50. The receivingunit 65 for receiving a packet from theauthentication server 30 or the chargingserver 5, the transmittingunit 66 for transmitting a packet to theauthentication server 30 or the chargingserver 5, and the type of the packet After performing the processing, thepacket control unit 67 determines where and what packet is to be transmitted. These functions are implemented as an application that operates on Linux (registered trademark).
[0026]
In order to receive a packet transmitted from theHGW 70 at the application layer, the receivingunit 61 uses libpcap (ftp: //ftp.ee.lbl.gov/libpcap.tar.Z) obtained by adding a filter function to the raw socket. By doing so, a packet is received from the data link layer. The reason for using the raw socket is that the destination IP address of the packet from theHGW 70 is not theAAAGW 60, and therefore, theAAAGW 60 cannot receive the packet using the normal socket. The received packet is passed to thepacket control section 67.
[0027]
Similarly, in order to receive a packet transmitted from theIGMP router 50 at the application layer, the receivingunit 63 transmits the raw socket to a libpcap (ftp://ftp.ee.lbl.gov/libpcap. tar.Z), the packet is received from the data link layer. The reason that the raw socket is used is that the destination IP address of the packet from theIGMP router 50 is not theAAAGW 60, and therefore theAAAAGW 60 cannot receive the packet using the normal socket. The received packet is passed to the transmittingunit 62.
[0028]
TheAAAGW 60 can be treated as a normal client for theauthentication server 30 or thebilling server 5, so that the receivingunit 65 and the transmittingunit 66 receive and transmit using a normal socket. The packet received by the receivingunit 65 is passed to thepacket control unit 67. Thetransmission unit 66 receives the packet from thepacket control unit 67, and transmits the packet to theauthentication server 30 or theaccounting server 5.
[0029]
The source IP address of the packet to be transmitted by the transmittingunit 64 is not theAAAGW 60 but the source IP address of the packet received by the receiving unit 61 (for example, the IP address of the user terminal 1). Therefore, the transmittingunit 64 transmits using the raw socket.
[0030]
Similarly, the source IP address of the packet to be transmitted by thetransmission unit 62 is not theAAAGW 60 but the source IP address of the packet received by the reception unit 63 (for example, the IP address of the content distribution server 20). Therefore, the transmittingunit 62 transmits using the raw socket.
[0031]
Next, the operation of thepacket control unit 67 will be described with reference to FIGS. 4 to 7 are flowcharts for explaining the operation of thepacket control unit 67.
[0032]
Thepacket control unit 67 checks what the packet received from the receivingunit 61 is. At this time, if the authentication request is for the user to log in to the network (step SA1), an access request (authentication request packet including an ID and a password) is transmitted to the authentication server 30 (step SB1). Theauthentication server 30 determines whether the user is a valid user based on the ID and the password, and returns an authentication result to the AAAGW 60 (step SB2). Here, the authentication result is such that when theauthentication server 30 determines that the user is a valid user, the Access-Accept is returned to theAAAGW 60, and when it is determined that the user is not valid, the Access-Reject is returned to theAAAGW 60. TheAAAGW 60 transfers the authentication result to the HGW 70 (Step SB3).
[0033]
If it is not determined in step SA1 that the request is an authentication request for network login (No in step SA1), and if it is determined that the request is a content viewing start request (step SA2), theAAAGW 60 sets the Access for the content viewing start request. -Request (a packet including an ID, a password, and a group address of content to be viewed) is transmitted to the authentication server 30 (step SC1). Theauthentication server 30 compares the information shown in FIG. 2 with the transmitted ID, password, and group address to determine whether the information is valid.
[0034]
If it is valid (Yes in step SC2), theauthentication server 30 returns Access-Accept to theAAAGW 60. TheAAAGW 60 transmits an IGMP join packet (Membership Report packet including a group address to join, a header type is 0x16) to the IGMP router 50 (step SC3). TheIGMP router 50 receiving the IGMP join packet starts transmitting the content corresponding to the specified group address to theuser terminal 1. TheAAAGW 60 transmits billing information (ID, group address, viewing start time, etc.) to the billing server 5 (step SC4). When theaccounting server 5 finishes storing the received accounting information on the hard disk or the like, it notifies theAAAGW 60 of the completion of the accumulation (step SC5).
[0035]
If it is determined in step SC2 that the request is not valid (No in step SC2), the content viewing start request is discarded (step SC6), and theuser terminal 1 is notified of that (step SC7).
[0036]
If the request is not determined to be a content viewing start request (No in step SA2), but is determined to be a content viewing end request (step SA3), theAAAGW 60 determines that the Access-Request (ID) , A password, and a packet including the group address of the content whose viewing is to be terminated (step SD1). Theauthentication server 30 compares the information shown in FIG. 2 with the transmitted ID, password, and group address to determine whether the information is valid.
[0037]
If it is valid (Yes in step SD2), theauthentication server 30 returns Access-Accept to theAAAGW 60. TheAAAGW 60 transmits an IGMP leave packet (Leave Group packet, header type is 0x17) to the IGMP router 50 (step SD3). TheIGMP router 50 that has received the IGMP leave packet stops transmitting the content corresponding to the specified group address to theuser terminal 1. TheAAAGW 60 transmits the billing information (ID, group address, viewing end time, etc.) to the billing server 5 (step SD4). When the chargingserver 5 has finished storing the received charging information on the hard disk or the like, it notifies theAAAGW 60 that the storing has been completed (step SD5).
[0038]
When it is determined in step SD2 that the request is not valid (No in step SD2), the content viewing / listening end request is discarded (step SD6), and theuser terminal 1 is notified of that (step SD7).
[0039]
When it is not determined that the request is the content viewing end request (No in step SA3), the received packet is transferred to theIGMP router 50 as it is (step SA4).
[0040]
Steps SD4 and SD5 are necessary steps when a start time and a stop time are required, such as metering and time charging. On the other hand, once the purchase is decided, when charging for actually using the content, only steps SC4 and SC5 are necessary, and steps SD4 and SD5 are not necessary. For example, in the case of movie content such as rental video, once the user decides to purchase, there is a case where the user charges a flat rate to view all movies.
[0041]
[HGW]
[0042]
Next, the function of theHGW 70 will be described. FIG. 8 shows a detailed block diagram of theHGW 70.
[0043]
TheHGW 70 includes a receivingunit 71 that receives a packet from theuser terminal 1, a transmittingunit 72 that transmits a packet to theuser terminal 1, a receivingunit 73 that receives a packet from theAAAGW 60, and a transmittingunit 74 that transmits a packet to theAAAGW 60. , Apacket control unit 75 for managing an ID and a password corresponding to the user, and a user information management table 76 used by thepacket control unit 75 to record user information. These functions are implemented as an application that operates on Linux.
[0044]
The user information management table 76 records the IP address of the user terminal used by the user, the user ID, and the password as a pair.
[0045]
FIG. 9 shows an example of the user information management table 76. In the example of FIG. 9, the IP address x. x. x. x, user20 as a user ID, and user20pwd as a user password are recorded. These pieces of information are picked up and recorded from a packet transmitted to theauthentication server 30 when the user logs in to the network.
[0046]
In order to receive the packet transmitted from theuser terminal 1 at the application layer, the receivingunit 71 receives the packet from the data link layer by using a ribcap added to the raw socket with a filter function. The reason for using the raw socket is that the destination IP address of the packet from theuser terminal 1 is not theHGW 70, so that theHGW 70 cannot receive the packet using the normal socket. The received packet is passed to thepacket control unit 75.
[0047]
Similarly, in order to receive a packet transmitted from theAAAGW 60 at the application layer, the receivingunit 73 receives a packet from the data link layer by using a ribcap with a filter function added to the raw socket. The reason for using the raw socket is that the destination IP address of the packet from theAAAGW 60 is not theHGW 70, so that theHGW 70 cannot receive the packet using the normal socket. The received packet is passed to the transmittingunit 72.
[0048]
The source IP address of the packet to be transmitted by the transmittingunit 74 is not theHGW 70 but the source IP address of the packet received by the receiving unit 71 (for example, the IP address of the user terminal 1). Therefore, the transmittingunit 74 transmits using the raw socket.
[0049]
Similarly, the source IP address of the packet to be transmitted by the transmittingunit 72 is not theHGW 70 but the source IP address of the packet received by the receiving unit 73 (for example, the IP address of the content distribution server 20). Therefore, thetransmission unit 72 transmits using the raw socket.
[0050]
Next, the operation of thepacket control unit 75 will be described with reference to FIGS. FIGS. 10 to 13 are flowcharts illustrating the operation of thepacket control unit 75.
[0051]
Thepacket control unit 75 checks what the packet received from the receivingunit 71 is. At this time, if the authentication request is for the user to log in to the network (step SF1), the source IP address, the user ID, and the password are extracted from the packet and registered in the user information management table 76 (step SG1). Thereafter, the packet is transferred to the AAAGW 60 (step SG2). For example, when the user logs in to the network using theuser terminal 1, the user information management table 76 is as shown in FIG.
[0052]
If it is not determined in step SF1 that the request is an authentication request for network login (No in step SF1), and if it is determined that the packet is an IGMP join packet (content viewing start request) (step SF2), the user information management table 76 is displayed. Then, the user ID and password corresponding to the source IP of the IGMP join packet are taken out (step SH1). The extracted user ID, password and the IGMP join packet are packed in a data portion of an appropriate protocol, and transferred to the AAAGW 60 (step SH2).
[0053]
If it is determined that the packet is not an IGMP join packet (No in step SF2) and is determined to be an IGMP leave packet (content viewing end request) (step SF3), the user information management table 76 is referred to and the IGMP The user ID and password corresponding to the source IP of the leave packet are extracted (step SI1). The extracted user ID, password and the IGMP leave packet are embedded in a data portion of an appropriate protocol and transferred to the AAAGW 60 (step SI2).
[0054]
The “appropriate protocol” used in the above-mentioned steps SH2 and SI2 is such that if the purpose of transferring the user ID, password, and IGMP join packet (or IGMP leave packet) to theAAAGW 60 can be achieved, TCP and UDP But anything is fine. Further, a common key may be held between the AAAGW 60 and theHGW 70, and the information may be encrypted and transmitted / received to enhance security.
[0055]
When it is not determined that the packet is an IGMP leave packet (No in step SF3), the packet received from the user terminal is directly transferred to the AAAGW 60 (step SF4).
[0056]
[sequence]
Next, the entire operation until the user completes the login to the network will be described with reference to FIG. FIG. 14 is a sequence diagram until a user logs in to the network.
(1) The user inputs an ID and a password (Password) to theuser terminal 1 to log in to the network. The ID and the password are transmitted to theHGW 70.
(2) TheHGW 70 extracts the IP address, the user ID, and the password of theuser terminal 1 from the received packet and registers them in the user information management table 76. Thereafter, the packet is transferred to theAAAGW 60. The user information management table 76 at this time is as shown in FIG.
(3) TheAAAGW 60 transmits a RADIUS packet (Access-Request) including the user ID and the password to theauthentication server 30.
(4) Theauthentication server 30 refers to theuser DB 40 and checks whether the user is a legitimate user. If the user is an authorized user, a message indicating that authentication has been successful (Access-Accept packet) is transmitted to theAAAGW 60.
(5) TheAAAGW 60 returns an authentication success (Authenticate-Ack) to theHGW 70.
(6) TheHGW 70 transfers the authentication success to theuser terminal 1. When the authentication failure is received, the user data registered in the user information management table 76 in (2) is deleted.
[0057]
Next, the entire operation up to the start of viewing the content will be described with reference to FIG. FIG. 15 shows a sequence diagram up to the start of viewing the content.
(7) The user transmits an IGMP join packet including desired content (= Group Address) from theuser terminal 1.
(8) TheHGW 70 refers to the user information management table 76 and extracts the user ID and the password corresponding to the source IP address of the IGMP join packet. The user ID, the password, and the IGMP join packet are packed in the data section and transmitted to theAAAGW 60.
(9) TheAAAGW 60 extracts the user ID, the password, and the group address from the received packet and transmits the user ID, the password, and the group address to theauthentication server 30 as an authentication request packet.
(10) Theauthentication server 30 refers to theuser DB 40 and checks an ID, a password, and a group address. If the authentication is successful, an authentication success packet (Access-Accept) is returned to theAAAGW 60.
(11) Upon receiving the authentication success, theAAAGW 60 transfers the IGMP join packet to theIGMP router 50.
(12) The content is transferred to theuser terminal 1.
(13) TheAAAGW 60 transmits charging information (user ID, group address in which the user has joined, viewing start time, etc.) to the chargingserver 5.
(14) After receiving the billing information, thebilling server 5 returns a response packet (response) notifying the normal reception to theAAAGW 60.
[0058]
Next, the overall operation until the end of viewing the content will be described with reference to FIG. FIG. 16 shows a sequence diagram up to the end of viewing the content.
(15) The user transmits an IGMP leave packet including the Group Address from theuser terminal 1.
(16) TheHGW 70 refers to the user information management table 76 and extracts the user ID and the password corresponding to the source IP address of the IGMP leave packet. The user ID, the password, and the IGMP leave packet are packed in the data section and transmitted to theAAAGW 60.
(17) TheAAAGW 60 extracts the user ID, the password, and the group address from the received packet and transmits the user ID, the password, and the group address to theauthentication server 30 as an authentication request packet.
(18) Theauthentication server 30 refers to theuser DB 40 and checks the ID, the password, and the group address. If the authentication is successful, an authentication success packet (Access-Accept) is returned to theAAAGW 60.
(19) TheAAAGW 60 having received the authentication success transfers the IGMP leave packet to theIGMP router 50.
(20) Content transfer to theuser terminal 1 is stopped.
(21) TheAAAGW 60 transmits billing information (user ID, group address from which the user has left, viewing end time, etc.) to thebilling server 5.
(22) After receiving the charging information, the chargingserver 5 returns to the AAAGW 60 a response packet indicating that the charging information has been normally received.
[0059]
In order to switch the content being viewed by the user, the process of FIG. 16 is performed, the viewing of the current content is ended, and then the viewing start process of FIG. 15 is performed.
[0060]
(Variations of Embodiment)
It should be noted that the above embodiment is illustrative, and the present invention is not limited to this. The scope of the present invention is defined by the appended claims, and all modifications that fall within the meaning of the claims are included in the present invention.
[0061]
For example, in the above embodiment, IGMP is taken as an opportunity for content authentication, but other than IGMP may be used.
[0062]
In the above embodiment, it is assumed that the user uses PPP when logging in to the network, uses the RADIUS protocol between the AAAGW 60 and the authentication server and between the AAAGW 60 and the billing server, and uses IGMPv2 for the multicast control protocol. Other protocols may be used.
[0063]
Further, in the above embodiment, it is assumed that a fixed IP address (a unique IP address is assigned to the user in advance and the IP address does not change every time the user logs in) is assigned to theuser terminal 1. Alternatively, an IP address may be assigned at the time of login. Also, any information that uniquely identifies a user, such as a MAC address instead of an IP address, may be used.
[0064]
Further, in the above-described embodiment, an example is shown in which the functions of theAAAGW 60 and theHGW 70 are implemented as an application that operates on Linux. However, another OS may be used, or some or all of the functions may be stored in the kernel. May be implemented. Moreover, you may implement with hardware.
[0065]
Also, theAAAGW 60 or theHGW 70 operates router software that does not receive the IGMP join packet and the IGMP leave packet (for example, the IGMP join and the IGMP leave are modified so as to be discarded when the IGMP join and the IGMP leave packet come, and the IGMP join and the IGMP leave are used). May be separately picked up and processed by thepacket control unit 67 or thepacket control unit 75 of the above embodiment.
[0066]
Furthermore, in the above-described embodiment, an example is shown in which a global IP address is assigned to theuser terminal 1. However, by giving theHGW 70 an IP masquerade function, a global IP address is given to theHGW 70, and theuser terminal 1 You may give an address.
[0067]
Furthermore, in the above embodiment, the case where one user terminal is under the control of theHGW 70 is shown, but two or more user terminals may exist.
[0068]
【The invention's effect】
As described above, according to the present invention, hardware or software for an authentication request or content decryption is installed or set in a user terminal, and an ID or a password is input every time content is acquired. Without distributing the content, the user can be authenticated, the content can be distributed, and the billing can be appropriately performed. In addition, since commonly used products and standard protocols can be used without modification, it is possible to provide products that are easy to develop and easy to introduce into business. In addition, since a home gateway installed in the user's house substitutes for an ID and a password on behalf of the user, single sign-on can be realized. Furthermore, by encrypting and communicating between the home gateway and the authentication / charging gateway, security can be further improved. Further, based on charging information triggered by a content acquisition start request or a content acquisition end request, various types of charging such as PPV charging, time charging, and usage-based charging can be performed.
[Brief description of the drawings]
FIG. 1 is a configuration diagram showing an example of an embodiment of a content distribution system of the present invention.
FIG. 2 is an explanatory diagram showing an example of contents stored in a user database.
FIG. 3 is a block diagram showing details of an AAAGW.
FIG. 4 is a flowchart illustrating an operation of a packet control unit of the AAAGW.
FIG. 5 is a flowchart illustrating an operation of a packet control unit of the AAAGW.
FIG. 6 is a flowchart illustrating the operation of a packet control unit of the AAAGW.
FIG. 7 is a flowchart for explaining the operation of the packet control unit of the AAAGW;
FIG. 8 is a block diagram showing details of the HGW.
FIG. 9 is an explanatory diagram showing an example of a user information management table.
FIG. 10 is a flowchart illustrating the operation of a packet control unit of the HGW.
FIG. 11 is a flowchart illustrating an operation of a packet control unit of the HGW.
FIG. 12 is a flowchart illustrating the operation of the packet control unit of the HGW.
FIG. 13 is a flowchart illustrating the operation of the packet control unit of the HGW.
FIG. 14 is a sequence diagram illustrating an operation at the time of network login.
FIG. 15 is a sequence diagram illustrating an operation for starting viewing.
FIG. 16 is a sequence diagram illustrating an operation of terminating viewing.
FIG. 17 is a configuration diagram showing an example of a conventional content distribution system.
[Explanation of symbols]
1: User terminal, 5: Billing server, 20: Content distribution server, 30: Authentication server, 40: User database, 50: IGMP router, 60: Billing / authentication gateway (AAAGW), 70: Home gateway (HGW).