ストリーミング配信システム及びストリーミング配信方法
【課題】ストリーミング配信における不正な受信を防ぐ手段を提供する。
【解決手段】配信サーバ５は、ストリーミングデータを、クライアント端末１における事前認証済みのプレーヤ１２に配信する。ストリーミングデータは、プレーヤ１２から管理サーバ６に認証データを送信させるための送信指令を含む。ここで、認証データの送信は、ストリーミング再生中において、一回又は複数回行われる。管理サーバ６は、送信指令に基づいて送信された認証データを用いて、クライアント端末１の認証を行う。さらに、管理サーバ６は、認証データを用いた認証が失敗した場合には、配信サーバ５によるストリーミングデータの配信を停止させる。
【解決手段】配信サーバ５は、ストリーミングデータを、クライアント端末１における事前認証済みのプレーヤ１２に配信する。ストリーミングデータは、プレーヤ１２から管理サーバ６に認証データを送信させるための送信指令を含む。ここで、認証データの送信は、ストリーミング再生中において、一回又は複数回行われる。管理サーバ６は、送信指令に基づいて送信された認証データを用いて、クライアント端末１の認証を行う。さらに、管理サーバ６は、認証データを用いた認証が失敗した場合には、配信サーバ５によるストリーミングデータの配信を停止させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングデータを配信する技術に関するものである。
【背景技術】
【０００２】
従来から、データ配信の技術として、ストリーミング配信とダウンロード配信という二つの手法が知られている。
【０００３】
ダウンロード配信においては、データをサーバからクライアント端末に送信し、クライアント端末に保存する。ユーザは、クライアント端末に保存されたデータを用いて、例えば動画などのコンテンツを視聴することができる。
【０００４】
一方、ストリーミング配信においては、サーバからクライアント端末に送られたデータは、クライアント端末には保存されない。ユーザは、クライアント端末がサーバに接続している間のみ、配信されたデータを利用して、コンテンツを視聴することができる。
【０００５】
ストリーミング配信においては、データがクライアント端末に残らないため、データの複製物が不正に流出することを防ぐことができ、著作権管理が容易になるという利点がある。
【０００６】
ストリーミング配信における、ユーザ側で使用されるコンテンツ再生ソフトウエアは、プレーヤまたは再生プレーヤと呼ばれることが多い。一般的なストリーミング配信においては、プレーヤは、メタファイルを取得するためのＵＲＬに接続する。ついで、プレーヤは、メタファイルを介して、コンテンツ配信用のＵＲＬ（いわゆる実ＵＲＬ）を自動的に取得し、ストリーミング配信を受ける。ユーザは、実ＵＲＬを見ることができないので、ユーザによるコンテンツの保存を防止することができる。
【０００７】
ところで、近年、ストリーミング配信用の実ＵＲＬを取得してコンテンツをダウンロードする手法が出現している。このため、ストリーミングデータがダウンロードされる危険性が高くなっている。
【０００８】
そこで、ワンタイムＵＲＬという手法が提案されている（下記特許文献１）。この手法においては、プレーヤに渡す実ＵＲＬを、ユーザ毎に一時的に生成する。そして、その有効期間をごく短時間とする。これによれば、ＵＲＬが非正規ユーザに流出しても、非正規ユーザはストリーミング配信を受け取ることができない。このため、この技術では、コンテンツが非正規ユーザによってダウンロードされる可能性を減らすことができる。しかしながら、この手法においても、正規のユーザに悪意があり、実ＵＲＬを解析してダウンロードする場合には、コンテンツの流出を防ぐことが難しかった。
【０００９】
一方、ダウンロード配信の技術においては、分割されたコンテンツファイル毎にランダムなアクセス・キーを付与した上で、これらのコンテンツファイルを配信する技術が提案されている（下記特許文献２）。この技術では、分割されたファイルのダウンロード要求と一緒に、対応するアクセス・キーの送信を要求する。これによりユーザの正当性を検証することができる。
【００１０】
しかしながら、特許文献２の技術は、ダウンロード配信に特有の手法であって、ストリーミング配信に直接用いることは難しい。
【特許文献１】特開２００２−２８８１３４号公報
【特許文献２】特開２００３−３４５７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
また、一般に、ストリーミング配信用のシステムでは、既存のプレーヤやコンテンツ配信サーバ自体の仕組みを変更することは、現実的には難しい。すなわち、ストリーミング配信においては、既存の標準的なアプリケーション・ソフトウエアを用いざるを得ないことが多い。そこで、ストリーミング配信システムとしては、既存のプレーヤや配信サーバにも適合するシステムであることが望まれる。
【００１２】
本発明は、前記の状況に鑑みてなされたものである。本発明の目的の一つは、ストリーミング配信における不正な受信を防ぐことができるシステムないし手法を提供することである。
【課題を解決するための手段】
【００１３】
本発明は、以下のいずれかの項目に記載の構成とされている。
【００１４】
（項目１）
配信部と、認証部とを備えており、
前記配信部は、ストリーミングデータを、クライアント端末における事前認証済みのプレーヤに配信する構成となっており、
前記ストリーミングデータは、前記クライアント端末の前記プレーヤにおけるストリーミング再生中に、前記プレーヤから前記認証部に認証データを一回又は複数回送信させるための送信指令を含んでおり、
前記認証部は、前記送信指令に基づいて前記クライアント端末から送信された前記認証データを用いて、前記クライアント端末の認証を行う構成となっており、
さらに、前記認証部は、前記認証データを用いた認証が失敗した場合には、前記配信部による前記ストリーミングデータの配信を停止させる構成となっている
ことを特徴とするストリーミング配信システム。
【００１５】
この発明では、ストリーミング配信中において、ストリーミングデータを受信しているクライアント端末から、認証データを送信させることができる。したがって、仮にストリーミング配信用の実ＵＲＬが流出しても、認証データを持たない端末による不正受信を防ぐことが可能になる。
【００１６】
また、この発明では、事前認証されたプレーヤに対して、認証データの送信を要求するので、不正受信の可能性を一層低減させることができる。
【００１７】
（項目２）
前記ストリーミングデータに含まれる前記送信指令は、既定の時間間隔で定期的に、前記配信部から前記クライアント端末の前記プレーヤに送信されるようになっている
項目１に記載のストリーミング配信システム。
【００１８】
ストリーミング配信中において、定期的に認証データを送信させることにより、不正受信の可能性を一層低減させることができる。
【００１９】
（項目３）
さらに、認証情報送信部を備えており、
前記認証情報送信部は、認証情報を前記クライアント端末に送信する構成となっており、
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報に基づいて生成されている
項目１又は２に記載のストリーミング配信システム。
【００２０】
認証情報とは、例えば、暗号化された認証データを生成するためのキーとなる情報である。
【００２１】
（項目４）
さらに、認証情報記録部を備えており、
前記認証情報記録部は、前記認証情報送信部から前記クライアント端末に送信された前記認証情報を記録する構成となっており、
前記認証部は、前記認証情報記録部に記録された前記認証情報を用いて、前記クライアント端末から送信された前記認証データの認証を行う構成となっている
ことを特徴とする項目３に記載のストリーミング配信システム。
【００２２】
（項目５）
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報を用いて暗号化されている
ことを特徴とする項目３又は４に記載のストリーミング配信システム。
【００２３】
（項目６）
前記認証情報は、ユーザ端末毎に違うものとされている
項目３〜５のいずれか１項に記載のストリーミング配信システム。
【００２４】
ユーザ端末毎に異なる認証情報を用いることにより、異なるユーザ端末からのアクセスに対して、ストリーミング配信を拒否することができる。
【００２５】
（項目７）
前記プレーヤに対する事前認証は、
前記プレーヤに事前に第２チケットを渡しておく処理と；
前記プレーヤから前記認証部に前記第２チケットを送信する処理と；
前記プレーヤから送信された前記第２チケットと、前記認証部に記録された第２チケットとを照合する処理と；
を含む
ことを特徴とする項目１〜６のいずれか１項に記載のストリーミング配信システム。
【００２６】
（項目８）
前記クライアント端末はブラウザを備えており、
前記プレーヤに対する事前認証に先だって、前記ブラウザに対する事前認証が行われており、
前記ブラウザに対する事前認証は、
前記ブラウザに事前に第１チケットを渡しておく処理と；
前記ブラウザから前記認証部に前記第１チケットを送信する処理と；
前記ブラウザから送信された前記第１チケットと、前記認証部に記録された第１チケットとを照合する処理と；
を含む
ことを特徴とする項目７に記載のストリーミング配信システム。
【００２７】
（項目９）
クライアント端末におけるプレーヤに対する事前認証を行うステップと；
前記プレーヤからサーバ側に認証データを一回又はそれ以上送信させるための送信指令を含むストリーミングデータを前記プレーヤに配信するステップと；
前記プレーヤでのストリーミング再生中に前記送信指令に基づいて前記プレーヤから前記サーバ側に送信された前記認証データを用いて、前記クライアント端末の正当性の認証を行うステップと；
前記認証データを用いた認証が失敗した場合には、前記ストリーミングデータの配信を停止させるステップと
を備えることを特徴とするストリーミング配信方法。
【００２８】
（項目１０）
項目９に記載のステップをコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の効果】
【００２９】
本発明によれば、ストリーミング配信における不正な受信を防ぐことができるシステムないし手法を提供することができる。
【発明を実施するための最良の形態】
【００３０】
（本実施形態の装置構成）
本発明の一実施形態に係るストリーミング配信システムを、添付の図面に基づいて説明する。
【００３１】
この配信システムは、図１に示されるように、クライアント端末１と、表示サーバ２と、イメージサーバ３と、認証サーバ４と、配信サーバ５と、管理サーバ６とを主要な要素として備えている。これらの各要素は、インターネットなどの適宜なネットワークを介して、相互に通信可能となっている。
【００３２】
クライアント端末１は、ユーザがストリーミング配信を受けるための端末であり、ユーザ端末とも呼ばれる。クライアント端末１としては、通常のパーソナルコンピュータを用いることができる。ただし、クライアント端末１としては、ストリーミング配信を受信可能な携帯端末を用いることもできる。要するに、クライアント端末１としては、ストリーミング配信を受信できるものであれば、特に制約されない。
【００３３】
本実施形態のクライアント端末１は、ブラウザ１１とプレーヤ１２とを備えている。
【００３４】
ブラウザ１１は、Ｗｅｂページを閲覧するためのアプリケーション・ソフトウエアである。ブラウザ１１は、一般に、以下のような動作が可能である。ただし、本実施形態のブラウザ１１は、これらの動作を全て行うものである必要はない。ブラウザとしては、例えば、Microsoft社のInternet ExploreやMozilla FoundationのFirefoxを用いることができる。
・インターネット上からＨＴＭＬファイル、画像ファイル、音楽ファイルなどをダウンロードし、レイアウトを解析して、表示あるいは再生すること。
・クライアント端末１からのデータをＷｅｂサーバに送信すること。
・Javascript（Javaは登録商標）やFlashを動作させること。
【００３５】
プレーヤ１２は、ストリーミング配信を受けるためのアプリケーション・ソフトウエアである。プレーヤの一例は、Microsoft社のWindows（登録商標） Media Playerであるが、他のプレーヤを用いることは可能である。他のプレーヤの例としては、Adobe社のFlash Playerや、Microsoft社のSilverlightがあるが、これらには制限されない。
【００３６】
表示サーバ２は、ストリーミング配信をユーザが要求するためのページを提供するためのものである。
【００３７】
イメージサーバ３は、ストリーミング配信に対する実際の要求をユーザが入力するための画面をクライアント端末１に表示するためのものである。
【００３８】
認証サーバ４は、後述する第１チケット及び第２チケットを用いてクライアント端末１を認証するためのものである。認証サーバ４は、この実施形態では複数とされており、ロード・バランサ４１によって負荷を分散できるようになっている。
【００３９】
配信サーバ５は、実際のストリーミングデータをクライアント端末１のプレーヤ１２に配信するためのものである。配信サーバ５は、本発明における配信部の一例に対応する。配信サーバ５も、この実施形態では複数とされており、ＤＮＳラウンドロビンによって負荷が分散されるようになっている。
【００４０】
管理サーバ６は、第１・第２チケットや、後述するチケットコードを管理・認証するためのものである。管理サーバ６は、本発明における認証部の一例に対応する。管理サーバ６も、この実施形態では複数とされており、ロード・バランサ６１によって負荷分散が図られている。また、管理サーバ６は、後述する第１チケット等のデータを記録するためのデータベース６２を備えている。
【００４１】
本実施形態に係る配信システムの詳細は、以下における配信方法の説明において詳しく述べる。なお、前記のシステムでは、サーバに冗長性を持たせているが、どの程度の冗長性を持たせるかは適宜決定できる。
【００４２】
（本実施形態におけるストリーミング配信方法）
以下、本実施形態におけるストリーミング配信方法を、図２を主に参照しながら説明する。
【００４３】
（ステップＳＡ−１及びＳＡ−２）
まず、クライアント端末１のブラウザ１１は、表示サーバ２から提供されたページを表示する。このページには、ストリーミングによる視聴を希望するためのアイコン（図示せず）が表示される。
【００４４】
ついで、ユーザは、当該アイコンをクリックする。これにより視聴要求が表示サーバ２に送られる。
【００４５】
（ステップＳＡ−３）
ついで、表示サーバ２は、第１チケットを生成する。第１チケットは、セッション毎に特有なＩＤとなるものである。第１チケットとしては、適宜な記号列を用いることができる。
【００４６】
第１チケットは、システム側で取得したデータ（例えば、セッション毎のＩＤやユーザ毎のＩＤ）を暗号化して得た記号列である。暗号化方式としては例えばハッシュ関数を用いることができる。なお、第１チケットの生成に必要なデータは表示サーバ２で適宜に生成、取得することができる。
【００４７】
（ステップＳＡ−４〜ＳＡ−６）
ついで、表示サーバ２は、生成された第１チケットと、その生成のために用いた各データを、イメージサーバ３へのリダイレクトを介して、管理サーバ６に登録する。
【００４８】
さらに、管理サーバ６は、各データを登録すると共に、暗号化関数のコードを生成して、表示サーバ２に送る。暗号化関数のコードとは、後述するチケットコードを生成するための暗号化関数（例えばハッシュ関数）を実行するためのキーである。このキーは、この実施形態では、ユーザ毎又はセッション毎にユニークなものとされている。
【００４９】
（ステップＳＡ−７）
ついで、イメージサーバ３は、第１チケットと暗号化コードとをクライアント端末１のブラウザ１１に送る。さらに、イメージサーバ３は、クライアント端末１のブラウザ１１を介して、プレーヤ１２により、再生ボタン（図示せず）を表示させる。この再生ボタンは、実際にストリーミング配信を開始するためのものである。
【００５０】
（ステップＳＡ−８及びＳＡ−９）
ついで、ユーザが再生ボタンを押す。すると、第１チケットがブラウザ１１から認証サーバ４に送られる。認証サーバ４は、受け取った第１チケットを管理サーバ６に送る。管理サーバ６は、送信された第１チケットと、先ほど登録したものとを比較し、認証を行う。ここで、第１チケットには、端末やユーザについてのＩＤ情報を含むことができ、これらのＩＤを用いて、第１チケットの照合を行うことができる。また、管理サーバ６は、第１チケットの生成に用いたハッシュ関数の情報も持っている。さらに、管理サーバ６は、認証の結果を認証サーバ４に返す。
【００５１】
本実施形態においては、この動作により、クライアント端末１のブラウザ１１に対する認証を、第１チケットを用いて行うことができる。
【００５２】
（ステップＳＡ−１０）
認証成功の場合、認証サーバ４は、第２チケットを生成する。第２チケットも、第１チケットと同様に、システムにおいて適宜に生成できる。第２チケットとしては、システム側で得たＩＤ等の各種の情報を暗号化（例えばハッシュ）することにより生成した値を用いることができる。この実施形態では、第１チケットによる認証を経たクライアント端末１のプレーヤ１２に対してのみ第２チケットを発行する。
【００５３】
認証不成功の場合、認証サーバ４は、エラーメッセージをクライアント端末１のブラウザ１１又はプレーヤ１２に送って表示させる。
【００５４】
（ステップＳＡ−１１及びＳＡ−１２）
さらに、認証サーバ４は、第２チケットと、その生成に使ったデータとを、ユーザＩＤ毎に管理サーバ６に登録する。
【００５５】
また、認証サーバ４は、再生用のファイルと共に、第２チケットをクライアント端末１のプレーヤ１２に送る。例えば、プレーヤ１２がWindows（登録商標） Media Playerの場合、ASXという形式のファイルが渡される。
【００５６】
（ステップＳＡ−１３及びＳＡ−１４）
ついで、クライアント端末１のプレーヤ１２は、再生用ファイルを再生する。すると、プレーヤ１２は、再生用ファイル（この例ではASXファイル）に記載されたデータ（実ＵＲＬに相当）に従って、配信サーバ５に接続する。さらに、プレーヤ１２は、先に受け取った第２チケットを配信サーバ５に送る。
【００５７】
（ステップＳＡ−１５〜ＳＡ−１７）
ついで、配信サーバ５は、受け取った第２チケットを管理サーバ６に送り、管理サーバ６に記録されている第２チケットと照合する。この認証が成功すると、管理サーバ６は、配信サーバ５に対し、認証成功の応答を返す。さらに管理サーバ６は、当該チケットに対応するＩＤについて、「視聴中」の状態を設定する。具体的には、例えば、この状態に対応するフラグを記録する。
【００５８】
認証が不成功であった場合は、管理サーバ６は、認証不成功の応答を配信サーバ５に返す。この場合、配信サーバ５は、エラーメッセージをクライアント端末１のプレーヤ１２に送って、その旨を表示させる。
【００５９】
この実施形態では、第１チケットによる認証を経たクライアント端末１のプレーヤ１２に対してのみ第２チケットを発行するので、不正受信の可能性を一層低減させることができる。
【００６０】
さらに、第１チケットを、セッション毎に特有としているので、仮に第２チケットが流出しても、異なるセッションには異なる第１チケットが付与される。本実施形態では、第２実施形態の照合の前に、第１チケットによる照合を先行して行うので、この点においても、不正受信の可能性を低減させることができる。
【００６１】
（ステップＳＡ−１８）
認証成功の応答を受け取った配信サーバ５は、スクリプトコマンドを埋め込んだストリーミングデータをクライアント端末１のプレーヤ１２に送る。
【００６２】
ここで、ストリーミングデータとは、例えば動画データや音声データである。
【００６３】
また、スクリプトコマンドとは、ストリーミングデータに埋め込まれたコマンドであって、この実施形態では記号列によって構成される。このスクリプトコマンドをストリーミングデータに埋め込むと、このコマンドを受け取ったプレーヤ１２において、スクリプトコマンドイベントが発生する。スクリプトコマンドを含むストリーミングデータの例を図３に示す。図示例においてtextとあるのがスクリプトコマンドである。つまり、この実施形態では、送信指令としてのスクリプトコマンドが、規定の時間間隔で、定期的に送られていることになる。
【００６４】
スクリプトコマンドは、発生タイミングの記述を含むことができる。これにより、指定された発生タイミングにおいて、スクリプトコマンドイベントを発生させることができる。発生タイミングは例えば５秒間隔に設定される。この場合、スクリプトコマンドをプレーヤ１２が受け取ってスクリプトコマンドイベントが発生する。したがって、この実施形態では、５秒ごとにこのイベントが発生する。より具体的には、スクリプトコマンドは、セキュリティキー（秘密鍵）と、発生タイミングの秒数とをＭＤ５ハッシュした値（以下「Value値」という）を含んでいる。なお、スクリプトコマンドは、本発明における送信指令に相当している。
【００６５】
（ステップＳＡ−１９）
プレーヤ１２においてスクリプトコマンドイベントが発生すると、プレーヤ１２は、チケットコードを生成して、管理サーバ６に送る。ストリーミングデータの再生中に複数のスクリプトコマンドが発生すれば、プレーヤ１２は、そのたびに、チケットコードを生成して、管理サーバ６に送る。一般に、一つのストリーミングデータの再生中に、定期的にスクリプトコマンドイベントを順次発生させることが、不正受信を防ぐためには好ましい。つまり、この実施形態では、ストリーミング再生中に、複数の認証データが端末からサーバ側に送られることになる。ここで、一つの送信指令に対応して、複数の認証データを送る構成とすることもできるし、一つの認証データのみを送る構成とすることも可能である。
【００６６】
チケットコードは、この実施形態では記号列によって構成されている。具体的には、チケットコードは、スクリプトコマンドにおけるValue値と、現在再生中のコンテンツ（例えば動画）の視聴秒数とを暗号化した値が用いられる。ここで、暗号化のためのキーとしては、ステップＳＡ−６及びＳＡ−７において管理サーバ６からクライアント端末１のブラウザ１１に送られた暗号化キーが用いられる。
【００６７】
暗号化キーは、本発明における認証情報の一例に相当する。この例では、認証情報を用いてチケットコードが暗号化されている。また、チケットコードは、本発明における認証データの一例に相当する。また、本実施形態のサーバ６は、本発明における認証情報送信部と認証情報記録部の具体例にも相当している。
【００６８】
さらに、プレーヤ１２は、チケットコードと一緒に、第２チケットを管理サーバ６に送る。この第２チケットに含まれるID情報を利用して、IDに基づく照合を行うことが可能である。
【００６９】
（ステップＳＡ−２１及びＳＡ−２２）
管理サーバ６は、クライアント端末１から送付される、暗号化済みのチケットコードをチェックする。管理サーバ６は、チケットコード生成のための情報を持っているので、自身が生成した検証用チケットコードと、受信したチケットコードとが同一であるかどうかを検証する。また、管理サーバ６は、ブラウザ１１に送った暗号化キーと同じ暗号化キーでチケットコードが暗号化されたかどうかを、認証の一手段とすることができる。暗号化キーは、ユーザ毎又はセッション毎にユニークとされているからである。この場合、認証情報である暗号化キーが、認証データであるチケットコードを認証する手段に用いられていることになる。
【００７０】
認証不成功の場合、不正なチケットコードと考えられるので、管理サーバ６は、配信サーバ５からクライアント端末１へのストリーミング配信を中止させる。
【００７１】
また、管理サーバ６は、既定時間内にチケットコードを受信しなかった場合も、同様に、クライアント端末１へのストリーミング配信を中止する。例えば、この実施形態では、スクリプトコマンドを送信してから１０秒以内にチケットコードを受信しないときは、配信中止の処理が行われる。
【００７２】
本実施形態では、ストリーミング配信されるストリーミングデータ中に、スクリプトコマンドを挿入し、このコマンドに基づいて、クライアント端末１からチケットコードを送信させることができる。そして、ストリーミング配信中に送付されたチケットコードを確認することにより、不正な端末への配信を中止することができる。
【００７３】
このため、この実施形態においては、不正な受信を試みる端末へのストリーミング配信を高い確率で遮断することができるという利点がある。
【００７４】
さらに、この実施形態では、ストリーミング再生中に、クライアント端末１から、チケットコードを複数回送信させているので、不正受信を一層確実に遮断することができるという利点もある。チケットコードを定期的に送信させることとし、再生時間に対して送信間隔を十分に短いものとすれば、不正受信をさらに確実に遮断できる。一般にストリーミング再生の時間は、短くても１分以上と予想されるので、チケットコードの送信間隔を５〜１０秒程度に設定することが、不正受信の防止に効果的であると考えられる。ただし、送信間隔は、これに限られるものではなく、コンテンツの再生時間、種類、ネットワークへの負荷などの条件を考慮して設定することができる。
【００７５】
（ステップＳＡ−２３及びＳＡ−２４）
また、プレーヤ１２における一時停止ボタンがクリックされると、管理サーバ６は、当該ＩＤに対して一時停止のフラグを立てる。この場合、管理サーバは、チケットコードが届かなくても、配信を中止しない。
【００７６】
（ステップＳＡ−２５及びＳＡ−２６）
その後、プレーヤ１２における再生ボタンが再度クリックされると、管理サーバ６は、当該ＩＤにおける状態を「視聴中」に変更する。この場合、管理サーバは、チケットコードの監視を再開する。従って、一時停止時間を除く既定時間内にチケットコードを受信しない場合は、ストリーミング配信を中止する。
【００７７】
本実施形態のシステムにおいては、プレーヤやコンテンツ配信サーバの基本的な仕組みをそのまま使いながら、チケットコードを送信させることで、不正なストリーミング受信の危険を低減させることができる。
【００７８】
前記した各実施形態の動作は、コンピュータに適宜のコンピュータソフトウエアを組み込むことにより実施することができる。
【００７９】
なお、本発明の内容は、前記実施形態に限定されるものではない。本発明は、特許請求の範囲に記載された範囲内において、具体的な構成に対して種々の変更を加えうるものである。
【００８０】
例えば、前記した各構成要素は、機能ブロックとして存在していればよく、独立したハードウエアとして存在しなくても良い。また、実装方法としては、ハードウエアを用いてもコンピュータソフトウエアを用いても良い。さらに、本発明における一つの機能要素が複数の機能要素の集合によって実現されても良く、本発明における複数の機能要素が一つの機能要素により実現されても良い。例えば、前記した各サーバの機能を一つのハードウエアで実現することもできるし、一つのサーバの機能を複数のハードウエアで実現することもできる。
【００８１】
また、機能要素は、物理的に離間した位置に配置されていてもよい。この場合、機能要素どうしがネットワークにより接続されていても良い。グリッドコンピューティングにより機能を実現し、あるいは機能要素を構成することも可能である。
【図面の簡単な説明】
【００８２】
【図１】本発明の一実施形態にストリーミング配信システムの基本的な構成を示すブロック図である。
【図２】本発明の一実施形態に係るストリーミング配信方法の流れを概略的に説明するためのシーケンス図である。
【図３】スクリプトコマンドを含むストリーミングデータの例を示すデータ構造図である。
【符号の説明】
【００８３】
１ ユーザ端末
１１ ブラウザ
１２ プレーヤ
２ 表示サーバ
３ イメージサーバ
４ 認証サーバ
５ 配信サーバ（配信部）
６ 管理サーバ（認証部、認証情報送信部、認証情報記録部）
【技術分野】
【０００１】
本発明は、ストリーミングデータを配信する技術に関するものである。
【背景技術】
【０００２】
従来から、データ配信の技術として、ストリーミング配信とダウンロード配信という二つの手法が知られている。
【０００３】
ダウンロード配信においては、データをサーバからクライアント端末に送信し、クライアント端末に保存する。ユーザは、クライアント端末に保存されたデータを用いて、例えば動画などのコンテンツを視聴することができる。
【０００４】
一方、ストリーミング配信においては、サーバからクライアント端末に送られたデータは、クライアント端末には保存されない。ユーザは、クライアント端末がサーバに接続している間のみ、配信されたデータを利用して、コンテンツを視聴することができる。
【０００５】
ストリーミング配信においては、データがクライアント端末に残らないため、データの複製物が不正に流出することを防ぐことができ、著作権管理が容易になるという利点がある。
【０００６】
ストリーミング配信における、ユーザ側で使用されるコンテンツ再生ソフトウエアは、プレーヤまたは再生プレーヤと呼ばれることが多い。一般的なストリーミング配信においては、プレーヤは、メタファイルを取得するためのＵＲＬに接続する。ついで、プレーヤは、メタファイルを介して、コンテンツ配信用のＵＲＬ（いわゆる実ＵＲＬ）を自動的に取得し、ストリーミング配信を受ける。ユーザは、実ＵＲＬを見ることができないので、ユーザによるコンテンツの保存を防止することができる。
【０００７】
ところで、近年、ストリーミング配信用の実ＵＲＬを取得してコンテンツをダウンロードする手法が出現している。このため、ストリーミングデータがダウンロードされる危険性が高くなっている。
【０００８】
そこで、ワンタイムＵＲＬという手法が提案されている（下記特許文献１）。この手法においては、プレーヤに渡す実ＵＲＬを、ユーザ毎に一時的に生成する。そして、その有効期間をごく短時間とする。これによれば、ＵＲＬが非正規ユーザに流出しても、非正規ユーザはストリーミング配信を受け取ることができない。このため、この技術では、コンテンツが非正規ユーザによってダウンロードされる可能性を減らすことができる。しかしながら、この手法においても、正規のユーザに悪意があり、実ＵＲＬを解析してダウンロードする場合には、コンテンツの流出を防ぐことが難しかった。
【０００９】
一方、ダウンロード配信の技術においては、分割されたコンテンツファイル毎にランダムなアクセス・キーを付与した上で、これらのコンテンツファイルを配信する技術が提案されている（下記特許文献２）。この技術では、分割されたファイルのダウンロード要求と一緒に、対応するアクセス・キーの送信を要求する。これによりユーザの正当性を検証することができる。
【００１０】
しかしながら、特許文献２の技術は、ダウンロード配信に特有の手法であって、ストリーミング配信に直接用いることは難しい。
【特許文献１】特開２００２−２８８１３４号公報
【特許文献２】特開２００３−３４５７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
また、一般に、ストリーミング配信用のシステムでは、既存のプレーヤやコンテンツ配信サーバ自体の仕組みを変更することは、現実的には難しい。すなわち、ストリーミング配信においては、既存の標準的なアプリケーション・ソフトウエアを用いざるを得ないことが多い。そこで、ストリーミング配信システムとしては、既存のプレーヤや配信サーバにも適合するシステムであることが望まれる。
【００１２】
本発明は、前記の状況に鑑みてなされたものである。本発明の目的の一つは、ストリーミング配信における不正な受信を防ぐことができるシステムないし手法を提供することである。
【課題を解決するための手段】
【００１３】
本発明は、以下のいずれかの項目に記載の構成とされている。
【００１４】
（項目１）
配信部と、認証部とを備えており、
前記配信部は、ストリーミングデータを、クライアント端末における事前認証済みのプレーヤに配信する構成となっており、
前記ストリーミングデータは、前記クライアント端末の前記プレーヤにおけるストリーミング再生中に、前記プレーヤから前記認証部に認証データを一回又は複数回送信させるための送信指令を含んでおり、
前記認証部は、前記送信指令に基づいて前記クライアント端末から送信された前記認証データを用いて、前記クライアント端末の認証を行う構成となっており、
さらに、前記認証部は、前記認証データを用いた認証が失敗した場合には、前記配信部による前記ストリーミングデータの配信を停止させる構成となっている
ことを特徴とするストリーミング配信システム。
【００１５】
この発明では、ストリーミング配信中において、ストリーミングデータを受信しているクライアント端末から、認証データを送信させることができる。したがって、仮にストリーミング配信用の実ＵＲＬが流出しても、認証データを持たない端末による不正受信を防ぐことが可能になる。
【００１６】
また、この発明では、事前認証されたプレーヤに対して、認証データの送信を要求するので、不正受信の可能性を一層低減させることができる。
【００１７】
（項目２）
前記ストリーミングデータに含まれる前記送信指令は、既定の時間間隔で定期的に、前記配信部から前記クライアント端末の前記プレーヤに送信されるようになっている
項目１に記載のストリーミング配信システム。
【００１８】
ストリーミング配信中において、定期的に認証データを送信させることにより、不正受信の可能性を一層低減させることができる。
【００１９】
（項目３）
さらに、認証情報送信部を備えており、
前記認証情報送信部は、認証情報を前記クライアント端末に送信する構成となっており、
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報に基づいて生成されている
項目１又は２に記載のストリーミング配信システム。
【００２０】
認証情報とは、例えば、暗号化された認証データを生成するためのキーとなる情報である。
【００２１】
（項目４）
さらに、認証情報記録部を備えており、
前記認証情報記録部は、前記認証情報送信部から前記クライアント端末に送信された前記認証情報を記録する構成となっており、
前記認証部は、前記認証情報記録部に記録された前記認証情報を用いて、前記クライアント端末から送信された前記認証データの認証を行う構成となっている
ことを特徴とする項目３に記載のストリーミング配信システム。
【００２２】
（項目５）
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報を用いて暗号化されている
ことを特徴とする項目３又は４に記載のストリーミング配信システム。
【００２３】
（項目６）
前記認証情報は、ユーザ端末毎に違うものとされている
項目３〜５のいずれか１項に記載のストリーミング配信システム。
【００２４】
ユーザ端末毎に異なる認証情報を用いることにより、異なるユーザ端末からのアクセスに対して、ストリーミング配信を拒否することができる。
【００２５】
（項目７）
前記プレーヤに対する事前認証は、
前記プレーヤに事前に第２チケットを渡しておく処理と；
前記プレーヤから前記認証部に前記第２チケットを送信する処理と；
前記プレーヤから送信された前記第２チケットと、前記認証部に記録された第２チケットとを照合する処理と；
を含む
ことを特徴とする項目１〜６のいずれか１項に記載のストリーミング配信システム。
【００２６】
（項目８）
前記クライアント端末はブラウザを備えており、
前記プレーヤに対する事前認証に先だって、前記ブラウザに対する事前認証が行われており、
前記ブラウザに対する事前認証は、
前記ブラウザに事前に第１チケットを渡しておく処理と；
前記ブラウザから前記認証部に前記第１チケットを送信する処理と；
前記ブラウザから送信された前記第１チケットと、前記認証部に記録された第１チケットとを照合する処理と；
を含む
ことを特徴とする項目７に記載のストリーミング配信システム。
【００２７】
（項目９）
クライアント端末におけるプレーヤに対する事前認証を行うステップと；
前記プレーヤからサーバ側に認証データを一回又はそれ以上送信させるための送信指令を含むストリーミングデータを前記プレーヤに配信するステップと；
前記プレーヤでのストリーミング再生中に前記送信指令に基づいて前記プレーヤから前記サーバ側に送信された前記認証データを用いて、前記クライアント端末の正当性の認証を行うステップと；
前記認証データを用いた認証が失敗した場合には、前記ストリーミングデータの配信を停止させるステップと
を備えることを特徴とするストリーミング配信方法。
【００２８】
（項目１０）
項目９に記載のステップをコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の効果】
【００２９】
本発明によれば、ストリーミング配信における不正な受信を防ぐことができるシステムないし手法を提供することができる。
【発明を実施するための最良の形態】
【００３０】
（本実施形態の装置構成）
本発明の一実施形態に係るストリーミング配信システムを、添付の図面に基づいて説明する。
【００３１】
この配信システムは、図１に示されるように、クライアント端末１と、表示サーバ２と、イメージサーバ３と、認証サーバ４と、配信サーバ５と、管理サーバ６とを主要な要素として備えている。これらの各要素は、インターネットなどの適宜なネットワークを介して、相互に通信可能となっている。
【００３２】
クライアント端末１は、ユーザがストリーミング配信を受けるための端末であり、ユーザ端末とも呼ばれる。クライアント端末１としては、通常のパーソナルコンピュータを用いることができる。ただし、クライアント端末１としては、ストリーミング配信を受信可能な携帯端末を用いることもできる。要するに、クライアント端末１としては、ストリーミング配信を受信できるものであれば、特に制約されない。
【００３３】
本実施形態のクライアント端末１は、ブラウザ１１とプレーヤ１２とを備えている。
【００３４】
ブラウザ１１は、Ｗｅｂページを閲覧するためのアプリケーション・ソフトウエアである。ブラウザ１１は、一般に、以下のような動作が可能である。ただし、本実施形態のブラウザ１１は、これらの動作を全て行うものである必要はない。ブラウザとしては、例えば、Microsoft社のInternet ExploreやMozilla FoundationのFirefoxを用いることができる。
・インターネット上からＨＴＭＬファイル、画像ファイル、音楽ファイルなどをダウンロードし、レイアウトを解析して、表示あるいは再生すること。
・クライアント端末１からのデータをＷｅｂサーバに送信すること。
・Javascript（Javaは登録商標）やFlashを動作させること。
【００３５】
プレーヤ１２は、ストリーミング配信を受けるためのアプリケーション・ソフトウエアである。プレーヤの一例は、Microsoft社のWindows（登録商標） Media Playerであるが、他のプレーヤを用いることは可能である。他のプレーヤの例としては、Adobe社のFlash Playerや、Microsoft社のSilverlightがあるが、これらには制限されない。
【００３６】
表示サーバ２は、ストリーミング配信をユーザが要求するためのページを提供するためのものである。
【００３７】
イメージサーバ３は、ストリーミング配信に対する実際の要求をユーザが入力するための画面をクライアント端末１に表示するためのものである。
【００３８】
認証サーバ４は、後述する第１チケット及び第２チケットを用いてクライアント端末１を認証するためのものである。認証サーバ４は、この実施形態では複数とされており、ロード・バランサ４１によって負荷を分散できるようになっている。
【００３９】
配信サーバ５は、実際のストリーミングデータをクライアント端末１のプレーヤ１２に配信するためのものである。配信サーバ５は、本発明における配信部の一例に対応する。配信サーバ５も、この実施形態では複数とされており、ＤＮＳラウンドロビンによって負荷が分散されるようになっている。
【００４０】
管理サーバ６は、第１・第２チケットや、後述するチケットコードを管理・認証するためのものである。管理サーバ６は、本発明における認証部の一例に対応する。管理サーバ６も、この実施形態では複数とされており、ロード・バランサ６１によって負荷分散が図られている。また、管理サーバ６は、後述する第１チケット等のデータを記録するためのデータベース６２を備えている。
【００４１】
本実施形態に係る配信システムの詳細は、以下における配信方法の説明において詳しく述べる。なお、前記のシステムでは、サーバに冗長性を持たせているが、どの程度の冗長性を持たせるかは適宜決定できる。
【００４２】
（本実施形態におけるストリーミング配信方法）
以下、本実施形態におけるストリーミング配信方法を、図２を主に参照しながら説明する。
【００４３】
（ステップＳＡ−１及びＳＡ−２）
まず、クライアント端末１のブラウザ１１は、表示サーバ２から提供されたページを表示する。このページには、ストリーミングによる視聴を希望するためのアイコン（図示せず）が表示される。
【００４４】
ついで、ユーザは、当該アイコンをクリックする。これにより視聴要求が表示サーバ２に送られる。
【００４５】
（ステップＳＡ−３）
ついで、表示サーバ２は、第１チケットを生成する。第１チケットは、セッション毎に特有なＩＤとなるものである。第１チケットとしては、適宜な記号列を用いることができる。
【００４６】
第１チケットは、システム側で取得したデータ（例えば、セッション毎のＩＤやユーザ毎のＩＤ）を暗号化して得た記号列である。暗号化方式としては例えばハッシュ関数を用いることができる。なお、第１チケットの生成に必要なデータは表示サーバ２で適宜に生成、取得することができる。
【００４７】
（ステップＳＡ−４〜ＳＡ−６）
ついで、表示サーバ２は、生成された第１チケットと、その生成のために用いた各データを、イメージサーバ３へのリダイレクトを介して、管理サーバ６に登録する。
【００４８】
さらに、管理サーバ６は、各データを登録すると共に、暗号化関数のコードを生成して、表示サーバ２に送る。暗号化関数のコードとは、後述するチケットコードを生成するための暗号化関数（例えばハッシュ関数）を実行するためのキーである。このキーは、この実施形態では、ユーザ毎又はセッション毎にユニークなものとされている。
【００４９】
（ステップＳＡ−７）
ついで、イメージサーバ３は、第１チケットと暗号化コードとをクライアント端末１のブラウザ１１に送る。さらに、イメージサーバ３は、クライアント端末１のブラウザ１１を介して、プレーヤ１２により、再生ボタン（図示せず）を表示させる。この再生ボタンは、実際にストリーミング配信を開始するためのものである。
【００５０】
（ステップＳＡ−８及びＳＡ−９）
ついで、ユーザが再生ボタンを押す。すると、第１チケットがブラウザ１１から認証サーバ４に送られる。認証サーバ４は、受け取った第１チケットを管理サーバ６に送る。管理サーバ６は、送信された第１チケットと、先ほど登録したものとを比較し、認証を行う。ここで、第１チケットには、端末やユーザについてのＩＤ情報を含むことができ、これらのＩＤを用いて、第１チケットの照合を行うことができる。また、管理サーバ６は、第１チケットの生成に用いたハッシュ関数の情報も持っている。さらに、管理サーバ６は、認証の結果を認証サーバ４に返す。
【００５１】
本実施形態においては、この動作により、クライアント端末１のブラウザ１１に対する認証を、第１チケットを用いて行うことができる。
【００５２】
（ステップＳＡ−１０）
認証成功の場合、認証サーバ４は、第２チケットを生成する。第２チケットも、第１チケットと同様に、システムにおいて適宜に生成できる。第２チケットとしては、システム側で得たＩＤ等の各種の情報を暗号化（例えばハッシュ）することにより生成した値を用いることができる。この実施形態では、第１チケットによる認証を経たクライアント端末１のプレーヤ１２に対してのみ第２チケットを発行する。
【００５３】
認証不成功の場合、認証サーバ４は、エラーメッセージをクライアント端末１のブラウザ１１又はプレーヤ１２に送って表示させる。
【００５４】
（ステップＳＡ−１１及びＳＡ−１２）
さらに、認証サーバ４は、第２チケットと、その生成に使ったデータとを、ユーザＩＤ毎に管理サーバ６に登録する。
【００５５】
また、認証サーバ４は、再生用のファイルと共に、第２チケットをクライアント端末１のプレーヤ１２に送る。例えば、プレーヤ１２がWindows（登録商標） Media Playerの場合、ASXという形式のファイルが渡される。
【００５６】
（ステップＳＡ−１３及びＳＡ−１４）
ついで、クライアント端末１のプレーヤ１２は、再生用ファイルを再生する。すると、プレーヤ１２は、再生用ファイル（この例ではASXファイル）に記載されたデータ（実ＵＲＬに相当）に従って、配信サーバ５に接続する。さらに、プレーヤ１２は、先に受け取った第２チケットを配信サーバ５に送る。
【００５７】
（ステップＳＡ−１５〜ＳＡ−１７）
ついで、配信サーバ５は、受け取った第２チケットを管理サーバ６に送り、管理サーバ６に記録されている第２チケットと照合する。この認証が成功すると、管理サーバ６は、配信サーバ５に対し、認証成功の応答を返す。さらに管理サーバ６は、当該チケットに対応するＩＤについて、「視聴中」の状態を設定する。具体的には、例えば、この状態に対応するフラグを記録する。
【００５８】
認証が不成功であった場合は、管理サーバ６は、認証不成功の応答を配信サーバ５に返す。この場合、配信サーバ５は、エラーメッセージをクライアント端末１のプレーヤ１２に送って、その旨を表示させる。
【００５９】
この実施形態では、第１チケットによる認証を経たクライアント端末１のプレーヤ１２に対してのみ第２チケットを発行するので、不正受信の可能性を一層低減させることができる。
【００６０】
さらに、第１チケットを、セッション毎に特有としているので、仮に第２チケットが流出しても、異なるセッションには異なる第１チケットが付与される。本実施形態では、第２実施形態の照合の前に、第１チケットによる照合を先行して行うので、この点においても、不正受信の可能性を低減させることができる。
【００６１】
（ステップＳＡ−１８）
認証成功の応答を受け取った配信サーバ５は、スクリプトコマンドを埋め込んだストリーミングデータをクライアント端末１のプレーヤ１２に送る。
【００６２】
ここで、ストリーミングデータとは、例えば動画データや音声データである。
【００６３】
また、スクリプトコマンドとは、ストリーミングデータに埋め込まれたコマンドであって、この実施形態では記号列によって構成される。このスクリプトコマンドをストリーミングデータに埋め込むと、このコマンドを受け取ったプレーヤ１２において、スクリプトコマンドイベントが発生する。スクリプトコマンドを含むストリーミングデータの例を図３に示す。図示例においてtextとあるのがスクリプトコマンドである。つまり、この実施形態では、送信指令としてのスクリプトコマンドが、規定の時間間隔で、定期的に送られていることになる。
【００６４】
スクリプトコマンドは、発生タイミングの記述を含むことができる。これにより、指定された発生タイミングにおいて、スクリプトコマンドイベントを発生させることができる。発生タイミングは例えば５秒間隔に設定される。この場合、スクリプトコマンドをプレーヤ１２が受け取ってスクリプトコマンドイベントが発生する。したがって、この実施形態では、５秒ごとにこのイベントが発生する。より具体的には、スクリプトコマンドは、セキュリティキー（秘密鍵）と、発生タイミングの秒数とをＭＤ５ハッシュした値（以下「Value値」という）を含んでいる。なお、スクリプトコマンドは、本発明における送信指令に相当している。
【００６５】
（ステップＳＡ−１９）
プレーヤ１２においてスクリプトコマンドイベントが発生すると、プレーヤ１２は、チケットコードを生成して、管理サーバ６に送る。ストリーミングデータの再生中に複数のスクリプトコマンドが発生すれば、プレーヤ１２は、そのたびに、チケットコードを生成して、管理サーバ６に送る。一般に、一つのストリーミングデータの再生中に、定期的にスクリプトコマンドイベントを順次発生させることが、不正受信を防ぐためには好ましい。つまり、この実施形態では、ストリーミング再生中に、複数の認証データが端末からサーバ側に送られることになる。ここで、一つの送信指令に対応して、複数の認証データを送る構成とすることもできるし、一つの認証データのみを送る構成とすることも可能である。
【００６６】
チケットコードは、この実施形態では記号列によって構成されている。具体的には、チケットコードは、スクリプトコマンドにおけるValue値と、現在再生中のコンテンツ（例えば動画）の視聴秒数とを暗号化した値が用いられる。ここで、暗号化のためのキーとしては、ステップＳＡ−６及びＳＡ−７において管理サーバ６からクライアント端末１のブラウザ１１に送られた暗号化キーが用いられる。
【００６７】
暗号化キーは、本発明における認証情報の一例に相当する。この例では、認証情報を用いてチケットコードが暗号化されている。また、チケットコードは、本発明における認証データの一例に相当する。また、本実施形態のサーバ６は、本発明における認証情報送信部と認証情報記録部の具体例にも相当している。
【００６８】
さらに、プレーヤ１２は、チケットコードと一緒に、第２チケットを管理サーバ６に送る。この第２チケットに含まれるID情報を利用して、IDに基づく照合を行うことが可能である。
【００６９】
（ステップＳＡ−２１及びＳＡ−２２）
管理サーバ６は、クライアント端末１から送付される、暗号化済みのチケットコードをチェックする。管理サーバ６は、チケットコード生成のための情報を持っているので、自身が生成した検証用チケットコードと、受信したチケットコードとが同一であるかどうかを検証する。また、管理サーバ６は、ブラウザ１１に送った暗号化キーと同じ暗号化キーでチケットコードが暗号化されたかどうかを、認証の一手段とすることができる。暗号化キーは、ユーザ毎又はセッション毎にユニークとされているからである。この場合、認証情報である暗号化キーが、認証データであるチケットコードを認証する手段に用いられていることになる。
【００７０】
認証不成功の場合、不正なチケットコードと考えられるので、管理サーバ６は、配信サーバ５からクライアント端末１へのストリーミング配信を中止させる。
【００７１】
また、管理サーバ６は、既定時間内にチケットコードを受信しなかった場合も、同様に、クライアント端末１へのストリーミング配信を中止する。例えば、この実施形態では、スクリプトコマンドを送信してから１０秒以内にチケットコードを受信しないときは、配信中止の処理が行われる。
【００７２】
本実施形態では、ストリーミング配信されるストリーミングデータ中に、スクリプトコマンドを挿入し、このコマンドに基づいて、クライアント端末１からチケットコードを送信させることができる。そして、ストリーミング配信中に送付されたチケットコードを確認することにより、不正な端末への配信を中止することができる。
【００７３】
このため、この実施形態においては、不正な受信を試みる端末へのストリーミング配信を高い確率で遮断することができるという利点がある。
【００７４】
さらに、この実施形態では、ストリーミング再生中に、クライアント端末１から、チケットコードを複数回送信させているので、不正受信を一層確実に遮断することができるという利点もある。チケットコードを定期的に送信させることとし、再生時間に対して送信間隔を十分に短いものとすれば、不正受信をさらに確実に遮断できる。一般にストリーミング再生の時間は、短くても１分以上と予想されるので、チケットコードの送信間隔を５〜１０秒程度に設定することが、不正受信の防止に効果的であると考えられる。ただし、送信間隔は、これに限られるものではなく、コンテンツの再生時間、種類、ネットワークへの負荷などの条件を考慮して設定することができる。
【００７５】
（ステップＳＡ−２３及びＳＡ−２４）
また、プレーヤ１２における一時停止ボタンがクリックされると、管理サーバ６は、当該ＩＤに対して一時停止のフラグを立てる。この場合、管理サーバは、チケットコードが届かなくても、配信を中止しない。
【００７６】
（ステップＳＡ−２５及びＳＡ−２６）
その後、プレーヤ１２における再生ボタンが再度クリックされると、管理サーバ６は、当該ＩＤにおける状態を「視聴中」に変更する。この場合、管理サーバは、チケットコードの監視を再開する。従って、一時停止時間を除く既定時間内にチケットコードを受信しない場合は、ストリーミング配信を中止する。
【００７７】
本実施形態のシステムにおいては、プレーヤやコンテンツ配信サーバの基本的な仕組みをそのまま使いながら、チケットコードを送信させることで、不正なストリーミング受信の危険を低減させることができる。
【００７８】
前記した各実施形態の動作は、コンピュータに適宜のコンピュータソフトウエアを組み込むことにより実施することができる。
【００７９】
なお、本発明の内容は、前記実施形態に限定されるものではない。本発明は、特許請求の範囲に記載された範囲内において、具体的な構成に対して種々の変更を加えうるものである。
【００８０】
例えば、前記した各構成要素は、機能ブロックとして存在していればよく、独立したハードウエアとして存在しなくても良い。また、実装方法としては、ハードウエアを用いてもコンピュータソフトウエアを用いても良い。さらに、本発明における一つの機能要素が複数の機能要素の集合によって実現されても良く、本発明における複数の機能要素が一つの機能要素により実現されても良い。例えば、前記した各サーバの機能を一つのハードウエアで実現することもできるし、一つのサーバの機能を複数のハードウエアで実現することもできる。
【００８１】
また、機能要素は、物理的に離間した位置に配置されていてもよい。この場合、機能要素どうしがネットワークにより接続されていても良い。グリッドコンピューティングにより機能を実現し、あるいは機能要素を構成することも可能である。
【図面の簡単な説明】
【００８２】
【図１】本発明の一実施形態にストリーミング配信システムの基本的な構成を示すブロック図である。
【図２】本発明の一実施形態に係るストリーミング配信方法の流れを概略的に説明するためのシーケンス図である。
【図３】スクリプトコマンドを含むストリーミングデータの例を示すデータ構造図である。
【符号の説明】
【００８３】
１ ユーザ端末
１１ ブラウザ
１２ プレーヤ
２ 表示サーバ
３ イメージサーバ
４ 認証サーバ
５ 配信サーバ（配信部）
６ 管理サーバ（認証部、認証情報送信部、認証情報記録部）
【特許請求の範囲】
【請求項１】
配信部と、認証部とを備えており、
前記配信部は、ストリーミングデータを、クライアント端末における事前認証済みのプレーヤに配信する構成となっており、
前記ストリーミングデータは、前記クライアント端末の前記プレーヤにおけるストリーミング再生中に、前記プレーヤから前記認証部に認証データを一回又は複数回送信させるための送信指令を含んでおり、
前記認証部は、前記送信指令に基づいて前記クライアント端末から送信された前記認証データを用いて、前記クライアント端末の認証を行う構成となっており、
さらに、前記認証部は、前記認証データを用いた認証が失敗した場合には、前記配信部による前記ストリーミングデータの配信を停止させる構成となっている
ことを特徴とするストリーミング配信システム。
【請求項２】
前記ストリーミングデータに含まれる前記送信指令は、既定の時間間隔で定期的に、前記配信部から前記クライアント端末の前記プレーヤに送信されるようになっている
請求項１に記載のストリーミング配信システム。
【請求項３】
さらに、認証情報送信部を備えており、
前記認証情報送信部は、認証情報を前記クライアント端末に送信する構成となっており、
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報に基づいて生成されている
請求項１又は２に記載のストリーミング配信システム。
【請求項４】
さらに、認証情報記録部を備えており、
前記認証情報記録部は、前記認証情報送信部から前記クライアント端末に送信された前記認証情報を記録する構成となっており、
前記認証部は、前記認証情報記録部に記録された前記認証情報を用いて、前記クライアント端末から送信された前記認証データの認証を行う構成となっている
ことを特徴とする請求項３に記載のストリーミング配信システム。
【請求項５】
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報を用いて暗号化されている
ことを特徴とする請求項３又は４に記載のストリーミング配信システム。
【請求項６】
前記認証情報は、ユーザ端末毎に違うものとされている
請求項３〜５のいずれか１項に記載のストリーミング配信システム。
【請求項７】
前記プレーヤに対する事前認証は、
前記プレーヤに事前に第２チケットを渡しておく処理と；
前記プレーヤから前記認証部に前記第２チケットを送信する処理と；
前記プレーヤから送信された前記第２チケットと、前記認証部に記録された第２チケットとを照合する処理と；
を含む
ことを特徴とする請求項１〜６のいずれか１項に記載のストリーミング配信システム。
【請求項８】
前記クライアント端末はブラウザを備えており、
前記プレーヤに対する事前認証に先だって、前記ブラウザに対する事前認証が行われており、
前記ブラウザに対する事前認証は、
前記ブラウザに事前に第１チケットを渡しておく処理と；
前記ブラウザから前記認証部に前記第１チケットを送信する処理と；
前記ブラウザから送信された前記第１チケットと、前記認証部に記録された第１チケットとを照合する処理と；
を含む
ことを特徴とする請求項７に記載のストリーミング配信システム。
【請求項９】
クライアント端末におけるプレーヤに対する事前認証を行うステップと；
前記プレーヤからサーバ側に認証データを一回又はそれ以上送信させるための送信指令を含むストリーミングデータを前記プレーヤに配信するステップと；
前記プレーヤでのストリーミング再生中に前記送信指令に基づいて前記プレーヤから前記サーバ側に送信された前記認証データを用いて、前記クライアント端末の正当性の認証を行うステップと；
前記認証データを用いた認証が失敗した場合には、前記ストリーミングデータの配信を停止させるステップと
を備えることを特徴とするストリーミング配信方法。
【請求項１０】
請求項９に記載のステップをコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１】
配信部と、認証部とを備えており、
前記配信部は、ストリーミングデータを、クライアント端末における事前認証済みのプレーヤに配信する構成となっており、
前記ストリーミングデータは、前記クライアント端末の前記プレーヤにおけるストリーミング再生中に、前記プレーヤから前記認証部に認証データを一回又は複数回送信させるための送信指令を含んでおり、
前記認証部は、前記送信指令に基づいて前記クライアント端末から送信された前記認証データを用いて、前記クライアント端末の認証を行う構成となっており、
さらに、前記認証部は、前記認証データを用いた認証が失敗した場合には、前記配信部による前記ストリーミングデータの配信を停止させる構成となっている
ことを特徴とするストリーミング配信システム。
【請求項２】
前記ストリーミングデータに含まれる前記送信指令は、既定の時間間隔で定期的に、前記配信部から前記クライアント端末の前記プレーヤに送信されるようになっている
請求項１に記載のストリーミング配信システム。
【請求項３】
さらに、認証情報送信部を備えており、
前記認証情報送信部は、認証情報を前記クライアント端末に送信する構成となっており、
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報に基づいて生成されている
請求項１又は２に記載のストリーミング配信システム。
【請求項４】
さらに、認証情報記録部を備えており、
前記認証情報記録部は、前記認証情報送信部から前記クライアント端末に送信された前記認証情報を記録する構成となっており、
前記認証部は、前記認証情報記録部に記録された前記認証情報を用いて、前記クライアント端末から送信された前記認証データの認証を行う構成となっている
ことを特徴とする請求項３に記載のストリーミング配信システム。
【請求項５】
前記クライアント端末から送信される前記認証データは、前記認証情報送信部から送信された前記認証情報を用いて暗号化されている
ことを特徴とする請求項３又は４に記載のストリーミング配信システム。
【請求項６】
前記認証情報は、ユーザ端末毎に違うものとされている
請求項３〜５のいずれか１項に記載のストリーミング配信システム。
【請求項７】
前記プレーヤに対する事前認証は、
前記プレーヤに事前に第２チケットを渡しておく処理と；
前記プレーヤから前記認証部に前記第２チケットを送信する処理と；
前記プレーヤから送信された前記第２チケットと、前記認証部に記録された第２チケットとを照合する処理と；
を含む
ことを特徴とする請求項１〜６のいずれか１項に記載のストリーミング配信システム。
【請求項８】
前記クライアント端末はブラウザを備えており、
前記プレーヤに対する事前認証に先だって、前記ブラウザに対する事前認証が行われており、
前記ブラウザに対する事前認証は、
前記ブラウザに事前に第１チケットを渡しておく処理と；
前記ブラウザから前記認証部に前記第１チケットを送信する処理と；
前記ブラウザから送信された前記第１チケットと、前記認証部に記録された第１チケットとを照合する処理と；
を含む
ことを特徴とする請求項７に記載のストリーミング配信システム。
【請求項９】
クライアント端末におけるプレーヤに対する事前認証を行うステップと；
前記プレーヤからサーバ側に認証データを一回又はそれ以上送信させるための送信指令を含むストリーミングデータを前記プレーヤに配信するステップと；
前記プレーヤでのストリーミング再生中に前記送信指令に基づいて前記プレーヤから前記サーバ側に送信された前記認証データを用いて、前記クライアント端末の正当性の認証を行うステップと；
前記認証データを用いた認証が失敗した場合には、前記ストリーミングデータの配信を停止させるステップと
を備えることを特徴とするストリーミング配信方法。
【請求項１０】
請求項９に記載のステップをコンピュータに実行させることを特徴とするコンピュータプログラム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１０−７２７８０（Ｐ２０１０−７２７８０Ａ）
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【出願番号】特願２００８−２３７３７８（Ｐ２００８−２３７３７８）
【出願日】平成２０年９月１７日（２００８．９．１７）
【出願人】（５００２５７３００）ヤフー株式会社 (1,128)
【Ｆターム（参考）】
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【出願日】平成２０年９月１７日（２００８．９．１７）
【出願人】（５００２５７３００）ヤフー株式会社 (1,128)
【Ｆターム（参考）】
[ Back to top ]