JP2008259120A - 配信装置、配信システムおよび配信方法 - Google Patents

Abstract

【課題】動画像中の特定シーンを視聴制限できる機能をもつ動画配信システムを実現する。
【解決手段】配信判断基準入力機能と配信判断機能をもち、動画タイトルごとに異なる視聴制限を設定できる映像配信装置。視聴制限により１つの動画タイトル中に視聴可能なシーン、視聴できないシーンを設定する。視聴制限の範囲はアクセス履歴から動的に生成することもできるので、人気シーンを自動的に抽出して限定公開するなどプロモーションに用いることができる。また、アクセス履歴などの情報を外部から取得するためのインターフェースを持ち、より多くの情報に基づいて視聴制限範囲を合理的に決定する。さらに、限定公開した動画断片に他サイトへのリンク情報を埋め込み、動画断片の視聴者を、動画全体の視聴ができる別サイトに誘導できる。
【選択図】図１

Description

本発明は配信装置、配信システムおよび配信方法に係り、静止画像または動画像の配信装置、配信システムおよび配信方法に関する。

近年、ＮＧＮ（Next Generation Network）と呼ばれる次世代ネットワーク上で映像配信事業が開始されつつある。ＮＧＮは従来のインターネットとは異なり、映像の伝送に必要なネットワーク帯域を保証することができるＱoＳ保証機能、認証機能など、課金に有利な機能を具備しており、大規模な映像配信網を構築することも可能である。しかしながら、既にインターネット上には多数の利用料無料の映像配信サービスが存在しており、最大手では１千万人以上の利用者を集めている。このような状況では、上述のＮＧＮ独自機能だけではビジネス成功の決定打にはならないと考えられている。

インターネット上で最も利用者が多い映像配信サービスの形態は、動画共有型と呼ばれるサービスである。動画共有型サービスでは、利用者自らが撮影、作成した動画像をアップロードして他の利用者に公開する。一般に動画共有型サービスで扱われる映像コンテンツは、低画質なもので再生時間（動画像の長さ）にも限界がある。しかし、サービスの利用料は無料であり、アップロードされた動画像に対して自由にコメントをつけることができる機能、他のユーザがつけたコメントを読む機能、動画像の人気ランキング機能、さらに、他サイトのブログ上に任意の動画像を貼り付ける機能などを持つ。これら機能は、動画の品質を改善するものではなく、動画像に関するユーザコミュニティの形成に役立つものである。すなわち、動画品質の向上だけが利用者ニーズを満たす唯一の手段ではないことを示している。

このような背景から、ＮＧＮ上で映像配信サービスを成功させるために、既存のインターネット上の動画ユーザコミュニティとＮＧＮ上の高品質動画配信サービスをいかに結びつけるかが課題となっている。動画共有型サービスの成功例に倣えば、ＢＬＯＧなどのＷＥＢページ上に貼り付けられるように動画像の一部を無料公開する方法が有効と考えられている。なぜならば、動画像の魅力をよく理解した動画ユーザの制作する動画評価ページ（ＢＬＯＧ）は、読者に当該動画への興味をもたせる影響力があり、うまく利用できれば通常のプロモーションよりも安価に効果的に宣伝ができるためである。このようなプロモーションを目的とした映像配信では、映像の一部だけを限定して公開する機能が有用である。

特許文献１記載には、１８歳未満禁止映像など映像タイトル単位での視聴制限が記載されている。しかし、特許文献１に記載の技術では、同じ映像タイトル中の一部を視聴制限することができない。また、特許文献２または特許文献３記載の方法では、同じ映像タイトル中の一部を視聴することができる。しかし、特許文献２または特許文献３記載の技術では、視聴制限をすることができない。すなわち、既存技術ではあらかじめ映像を編集して視聴用に抜粋された映像データを用意しておかなければ映像の一部だけを公開するといった視聴制限を実施することができない。

特開２００４−０３２５３０号公報 特開２００３−２４４６７８号公報 特開２００３−２０４５３６号公報

上記従来技術の組み合わせでは、１つの同じ動画像中の特定のシーンを視聴制限することができない。このため、プロモーションなどを目的に動画像の一部だけを公開したい場合、オリジナル動画像をあらかじめ編集して公開用の動画像を別途作成しなければならない。特に、人気の高いシーンのみを公開するなど、公開後に動的に視聴制限範囲が定まるような制限基準を設けることは従来技術では困難である。本発明の目的は、この問題を解決して同一動画像中の特定シーンを視聴制限できる機能をもつなど、プロモーション目的にも応用可能な映像配信装置を実現することである。

上述した課題は、記憶部に保存した映像データをネットワークを介してエンドユーザに配信し、管理端末から受信した配信判断基準に基づいて配信の可否を判断する配信判断部と、第１のユーザから受信した配信要求と配信判断部の判断とに基づいて、映像データに制約を加えた動画データを第１のユーザに送信する動画配信部とからなる配信装置により、達成できる。

また、第１のネットワークに接続された第１の配信装置と、第２のネットワークに接続された第２の配信装置とからなり、第１の配信装置は、管理端末から受信した配信判断基準に基づいて配信の可否を判断する配信判断部と、第１のユーザから受信した配信要求と、配信判断部の判断とに基づいて、映像データに制約を加えた第１の動画データを第１のユーザに送信する動画配信部とからなり、第２の配信装置は、第１の動画データに添付されたリンクに対応する第２の動画データを第１のユーザに送信する配信システムにより、達成できる。

さらに、ユーザからの配信要求を受信するステップと、配信要求に対する配信の可否を判定するステップと、映像データに制約を加えた第１の動画データと、制約を加えない第２の動画データへのリンクとをユーザに送信するステップとからなる配信方法により、達成できる。

本発明によれば、あらかじめタイトル毎に異なる視聴制限基準を設定して、動画像の特定シーンを視聴制限することができる。これにより、オリジナル動画像を編集することなく動画像の一部だけを公開することが可能となる。

以下、本発明の実施の形態について、実施例を用い図面を参照しながら説明する。なお、実質同一箇所には同じ参照番号を振り、説明は繰り返さない。

図１を参照して限定配信システムを説明する。ここで、図１は映像配信システムのブロック図である。図１において、映像配信システム２００は、ネットワーク１０５を介して複数のユーザ端末１００が、ＷＥＢサーバ１０２、映像配信サーバ１０３、限定配信サーバ１０４に接続され、構成されている。ネットワーク１０５には、管理用端末１０６も接続されている。

ユーザ端末１００の中にはＢＬＯＧオーナなど動画ユーザコミュニティで中心となって活動しているユーザの端末１０１も含まれる。通常ＢＬＯＧオーナは、一般ユーザに比べて人数は少ない。一方、サービス提供者サイドには既存のＢＬＯＧサーバ１０２や課金を目的した映像配信サーバ１０３、限定配信サーバ１０４および管理端末１０６が存在する。

限定配信サーバ１０４はメモリ１１０、ＣＰＵ１１１、Ｉ／Ｏインターフェース１１２、ＤＩＳＫドライブ１１３のハードウェアと、ＤＩＳＫドライブ上に記録されたコンテンツ（動画、静止画像データ）１１４と、メモリ上に保持され、且つＣＰＵ、Ｉ／Ｏインターフェースと連携して各種機能を実現する配信判断基準入力部１２０、配信判断部１２１、配信要求受信部１２２、サムネイル配信部１２３、動画配信部１２４、コンテンツ視聴状況管理部１２５、リンク埋め込み部１２６、のソフトウェアから構成される。

図２を参照して、大規模映像配信システムへのプロモーションを説明する。ここで、図２は映像配信システムの詳細なブロック図である。図１のネットワーク１０５は、実際にはネットワーク帯域を保証して動画の品質を一定に保つことができるＮＧＮ網１のような高機能ネットワークと、インターネット網２のようなベストエフォート型のネットワークの２種類に大別できる。ＮＧＮ網１では映像伝送に必要な帯域を保証（ＱoＳ保証）することができるので、課金を前提とした大規模な映像配信システム４を構築できる。しかし、インターネット２では品質保証が困難であるため課金が難しい。

図２において、インターネット網２には、映像配信サーバ１３０と、ユーザ端末１００、１０１とが接続されている。映像は、映像配信サーバ１３０からインターネット網２を介して、ユーザ端末１００、１０１に送信される。ここで、映像配信サーバ１３０は、従来技術のサーバである。一方、ＮＧＮ網１には、映像配信システム４が接続されている。映像は、映像配信システム４から、ＮＧＮ網１を介して、ユーザ端末３に送信される。このとき、映像配信システム４は、複数の映像配信サーバ１０３と、映像配信サーバに映像を配信する映像配信サーバ１０３Ａとから構成されている。また、インターネット網２には、映像配信サーバ１０３Ａと接続された限定配信サーバ１０４が接続されている。限定配信サーバ１０４は、インターネット網２を介して、ユーザ端末１００、１０１に、映像配信サーバ１０３Ａから提供された映像を限定して配信する。限定配信サーバ１０４と映像配信サーバ１０３Ａとは、相互に人気コンテンツ情報、公開範囲の変更等の情報を交換する。

インターネット網２では既存の映像配信サービスが既にワールドワイドで５千万人以上のエンドユーザを集めている。しかし、後発のＮＧＮ網１では、これからエンドユーザを集めなければならない。限定配信サーバ１０４は、ＮＧＮ網１で提供されるコンテンツの一部を既存ユーザコミュニティのユーザ端末１００〜１０１へ限定公開することによりＮＧＮサービスのプロモーションを行う。インターネット上で既存の低画質な動画像を視聴しているユーザにはＮＧＮサービスの潜在顧客がいる可能性が高いと考えられるので、上述のプロモーションにより効率のよい新規ユーザ獲得が期待できる。限定配信サーバ１０４とＮＧＮ網１上の配信サーバ１０３Ａの間ではアクセス履歴や人気コンテンツ情報などを交換することができるため、たとえば人気のないコンテンツの公開範囲を拡大するなど、柔軟に視聴制限範囲を制御することができる。

図３を参照して、ＮＧＮ網へのプロモーションを説明する。ここで、図３はユーザ端末、ＷＥＢサーバ、映像配信サーバ、限定配信サーバ、管理端末の間の全体動作シーケンス図である。図３において、限定配信サーバ１０４は、あらかじめ管理端末１０６から視聴範囲の制限方式（制限基準）が入力される（Ｓ２０１）。制限基準の入力は、動画配信中など任意のタイミングでも実行することができる。また、映像配信サーバ１０３は、限定配信サーバ１０４に対して、映像配信サーバ１０３で配信中のコンテンツへのリンク（アクセス先）情報などのリンク情報を通知する（Ｓ２０２）。このリンク情報は後述のステップで動画像に埋め込んでユーザ端末１００に配信される。定常状態では、限定配信サーバ１０４は、ユーザ端末１００またはユーザ端末１０１からの画像配信要求を待つ。

ユーザ端末１０１は、動画コミュニティ上でＢＬＯＧなどのコンテンツを製作しているユーザの端末である。ユーザ端末１０１のユーザを、一般のユーザとは区別して以下ＢＬＯＧオーナと呼ぶ。ＢＬＯＧオーナはユーザ端末１０１より、限定配信サーバ１０４が限定公開する動画断片や静止画像を利用して自身のＢＬＯＧページを作成する。このＢＬＯＧページ作成活動は宣伝効果があるため、映像配信サーバ１０３による配信サービス提供者にとってもメリットがある。すなわち、ＢＬＯＧページ上に動画の一部を掲載することによりＢＬＯＧページの価値を高めることは、当該動画像の宣伝効果の増大という側面を持つ。限定配信サーバ１０４により動画像の各シーンの静止画像（サムネイル）と当該シーンの時刻情報を提供することにより、ＢＬＯＧオーナは動画自体を見ることなく動画の特定シーンを埋め込んだＢＬＯＧページ（ＨＴＭＬドキュメント）を作成することができる。静止画像を先行して提供することにより、ＢＬＯＧでの利用ニーズの高いシーンを確認してから人気シーン動画のみを公開するといった動画視聴制限が可能となる。

具体的には、ＢＬＯＧオーナは、ユーザ端末１０１を操作して、限定配信サーバ１０４に接続する。ユーザ端末１０１は、限定配信サーバ１０４にサムネイル要求を送信する（Ｓ２０３）。サムネイル要求を受信した限定配信サーバ１０４は、要求されたサムネイルとシーン時刻と断片動画へのリンク先とをユーザ端末１０１に送信する（Ｓ２０４）。ＢＬＯＧオーナの操作によって、ユーザ端末１０１はＷＥＢサーバ１０２上でＢＬＯＧを作成する（Ｓ２０６）。このＢＬＯＧには、サムネイルを表示し、断片動画へのリンクを埋め込む。作成されたＢＬＯＧページはＢＬＯＧサーバ１０２にアップロードされインターネット全体に公開される。インターネット全体に公開されたＢＬＯＧページはユーザ端末１００を用いて一般ユーザが閲覧できる。

一般視聴者の操作によって、ユーザ端末１００はＷＥＢサーバ１０２にアクセスし、ＢＬＯＧオーナが作成したＢＬＯＧページを要求する（Ｓ２０７）。ＢＬＯＧページを要求されたＷＥＢサーバ１０２は、ユーザ端末１００にＢＬＯＧページを配信する（Ｓ２０８）。このＢＬＯＧページには、限定配信サーバ１０４から、ステップ２０４で取得したリンク情報が埋め込まれたサムネイルが表示されている。ＢＬＯＧページ上に掲載されたサムネイルに関心を持ったユーザがリンクをクリックすると、ユーザ端末１００は、限定配信サーバ１０４に対して、断片動画要求を送信する（Ｓ２０９）。断片動画要求を受信した限定配信サーバ１０４は、ユーザ端末１００に断片動画と全体動画へのリンクを配信する（Ｓ２１１）。断片動画に関心を持ったユーザがリンクをクリックすると、ユーザ端末１００は、映像配信サーバ１０３に対して、全体動画要求を送信する（Ｓ２１２）。全体動画要求を受信した映像配信サーバ１０３は、ユーザ端末１００に全体動画を配信する（Ｓ２１３）。このとき、限定配信サーバ１０４から映像配信サーバ１０３に対してアクセス履歴情報を提供する（Ｓ２１４）。

アクセス履歴情報には上記リンクの配信数やリンクのクリック数、リンクをクリックしたユーザ端末のアドレスなどの情報が含まれており、映像配信サーバへのアクセス予測や、リンク経由で訪れたユーザに対して割引サービスを実施するなど映像配信サービスの改善や機能拡張に役立てることができる。アクセス履歴情報はユーザおよびＢＬＯＧユーザからのアクセスがある毎に逐次送出してもよいし、あらかじめ定めた件数まとめてから送出してもよい。

図４はユーザ端末、ＢＬＯＧオーナ端末、管理端末、映像配信サーバ、限定配信サーバの内部動作を含めた動作シーケンス図である。図４において、管理端末１０６は、配信制限基準を限定配信サーバ１０４に送信する（Ｓ２２１）。限定配信サーバ１０４は、配信制限基準を配信判断基準入力部１２０で受信して、配信判断部１２１に転送する（Ｓ２２２）。映像配信サーバ１０３は、リンク情報を、限定配信サーバ１０４に送信する（Ｓ２２３）。限定配信サーバ１０４は、リンク情報をリンク埋め込み部１２６で受信する。

ユーザ（ＢＬＯＧオーナ）端末１０１は、サムネイル要求（静止画要求）を限定配信サーバ１０４に送信し、配信要求受信部１２２が受信する（Ｓ２２４）。配信要求受信部１２２は、履歴通知をコンテンツ視聴状況管理部１２５に送信する（Ｓ２２５）。配信要求受信部１２２は、配信指示をサムネイル配信部１２３に送信する（Ｓ２２６）。配信指示を受信したサムネイル配信部１２３は、ＢＬＯＧオーナ端末１０１に画像を配信する（Ｓ２２７）。

一方、断片動画について、ユーザ端末１００は断片動画要求を限定配信サーバ１０４に送信し、配信要求受信部１２２が受信する（Ｓ２２８）。断片動画要求を受信した配信要求受信部１２２は、配信判断部１２１に要求されたシーンが視聴可能区間であるか問い合わせる（Ｓ２２９）。配信判断部１２１は、ステップ２２２で指定された配信制限基準に応じて、コンテンツ視聴状況管理部１２５の管理するアクセス履歴から必要な情報を取得して（Ｓ２３１、Ｓ２３２）、当該シーン配信の可否を判断する。配信判断部１２１は、配信等級受信部１２２に、この場合配信可の判断結果を送信する（Ｓ２３３）。配信要求受信部１２２は、履歴通知をコンテンツ視聴状況管理部１２５に送信する（Ｓ２３４）。配信要求受信部１２２は、配信指示を動画配信部１２４に送信する（Ｓ２３６）。配信指示を受信した動画配信部１２４は、リンク埋め込み部１２６にリンク要求を送信する（Ｓ２３７）。リンク埋め込み部１２６は、リンク情報を動画配信部１２４に送信する。動画配信部１２４は、リンク埋め込み部１２６から受信したリンク情報を埋め込み、ユーザ端末１００に対して、動画を配信する。

図５を参照して、管理端末１０６から送出される配信制限基準の具体的な内容を説明する。ここで、図５は配信制限基準を説明する図である。図５において、配信制限基準５００は、当該基準を適用するコンテンツ（動画）を特定するためのタイトル（識別子）５０１、制限方式５０２、制限方式に応じた制限パラメータ５０３の３つの情報の複数のセットである。コンテンツのタイトル５０１は、ジャンル指定や正規表現による複数タイトルの指定も含まれる。制限方式５０２は、コンテンツ全体のうち公開してもよいシーンの比率を指定する公開率方式、連続したシーンが公開されないことを保障する連続再生可能時間指定方式、あらかじめ指定した区間を公開禁止にする公開禁止区間指定方式、人気シーン上位のみを公開する人気シーン順方式などの制限方式がある。それぞれ、公開率方式および人気シーン順方式では比率（％）、連続再生可能時間指定方式および公開禁止区間指定方では時間（分・秒・ミリ秒）、などのパラメータ５０３を指定する。なお、パラメータとして指定する単位には上述以外のものを利用してもかまわない。また、上述した４つの方式以外の配信制限基準を追加してもかまわない。

図６を参照して、映像配信サーバ１０３から送出されるリンク情報の具体的な内容を説明する。ここで、図６はリンク情報を説明する図である。図６において、リンク情報６００は、コンテンツを特定するためのタイトル（識別子）６０１と、リンク先６０２、当該リンクの有効期限６０３の３つの情報の複数のセットである。

図７を参照して、ユーザ（ＢＬＯＧオーナ）端末１０１から送出されるサムネイル要求の具体的な内容を説明する。ここで、図７はサムネイル要求を説明する図である。図７において、サムネイル要求７００は、コンテンツを特定するためのタイトル（識別子）７０１と当該コンテンツ内のシーンを特定するための先頭からの経過時間７０２から成る。複数のシーンを要求する場合には、一括して複数の要求を送出してもよい。

図８を参照して、ユーザ端末から送出される動画要求の具体的な内容を説明する。ここで、図８は一人のユーザが送出する動画要求を説明する図である。図８において、動画要求８００は、コンテンツを特定するためのタイトル（識別子）８０１と当該コンテンツ内のシーンを特定するための先頭からの経過時間８０２と、再生時間（または終了時間）８０２から成る。複数のシーンを要求する場合には一括して複数の要求を送出してもよく、連続していない複数のシーンを繋ぎ合わせた動画を作成することもできる。

図９を参照して、限定配信サーバ１０４から映像配信サーバ１０３に送出されるアクセス履歴情報の具体的な内容を説明する。ここで、図９はアクセス履歴情報を説明する図である。図９において、アクセス履歴情報には、図９（ａ）の生データ９００と図９（ｂ）の統計情報９１０の２種類がある。生データ９００とはコンテンツを特定するためのタイトル（識別子）９０１と当該コンテンツへの要求（アクセス）があった時刻９０２とアクセス元９０３のリストである。統計情報９１０とはコンテンツを特定するためのタイトル（識別子）９１１と、当該コンテンツに対する累計アクセス数９１２や、年間、月間、時系列、曜日別など異なる方式でカウントした生データを集計して得られる統計情報９１３のセットである。統計情報９１０には上述した以外の情報を加えてもよい。

図１０を参照して、ユーザ端末の処理シーケンスの詳細を説明する。ここで、図１０はユーザ端末の処理シーケンス図である。図１０において、ユーザ端末１００は、ステップ２０７でＷＥＢサーバ１０２からＨＴＭＬドキュメント１００１を取得する。ＨＴＭＬドキュメント１００１の中には動画要求送出のトリガとなるスクリプト（またはプラグインタグ）１００２が記述されている。ユーザ端末１００は、スクリプト１００２を解釈して動画要求を限定配信サーバ１０４へ送出する（Ｓ２０９）。動画要求を受信した限定配信サーバ１０４は、要求された動画データとリンク情報をユーザ端末１００へ送出する（Ｓ２１１）。動画データは、ユーザ端末１００の動画表示領域１００３に表示される。動画表示領域１００３は、ＨＴＭＬドキュメントの構成要素のひとつとして埋め込まれる場合、上記ページとは独立した領域になる場合もある。リンク情報１００４は、アンカーリンク、フォームボタンなどのクリッカブルなコンポーネントの形で、動画表示領域１００３上またはＨＴＭＬドキュメントの構成要素のひとつとして表示される。表示されたボタン（アンカーリンク）１０４をクリックすると、リンク情報で指定された動画像を映像配信サーバ１０３からダウンロードして動画表示領域１００３に表示する（Ｓ２１３）。リンク情報には映像配信サーバ１０３上の動画像へのリンク以外のリンクを記述してもよく、ＷＥＢサイトへのリンクを記述して、当該ＷＥＢサイトにページ移動することや、限定配信サーバ１０４上の別な動画像へリンクすることもできる。認証が必要なリンク先へリンクしている場合には、リンクをクリックするとともに入力フォームを表示してユーザＩＤやパスワードを取得する。ＩＤやパスワードをリンク先に送出するためにステップ２１２〜ステップ２１３の通信は複数ステップになる場合もある。

図１１を参照して、配信要求受信部の動作アルゴリズムを説明する。ここで、図１１は配信要求受信部の動作フロー図である。図１１において、配信要求受信部１２２は、配信要求を受信すると、まず配信制限基準の設定された配信判断が必要なコンテンツか確認する（Ｓ３０１）。配信判断が必要なコンテンツである場合（Ｓ３０１：ＹＥＳ）は、配信判断部１２１を呼び出し（Ｓ３０２）、配信判断結果に応じて動画配信部１２４に動画配信を指示して（Ｓ３０３）、終了する。ステップ３０１でＮＯならばサムネイル配信部１２３にサムネイル配信を指示して（Ｓ３０４）、終了する。

図１２を参照して、配信判断部の動作アルゴリズムを説明する。ここで、図１２は配信判断部の動作フロー図である。図１２において、配信判断部１２１は、まず、配信判断を要求されると、当該コンテンツに対応する判断基準が存在するか判定する（Ｓ３１１）。存在するとき、判定基準を取得する（Ｓ３１２）。ステップ３１１で配信判断基準が設定されていない場合（Ｎ）、配信拒否を通知し（Ｓ３２１）、終了する。

ステップ３１２の次に、配信判断部１２１は、制限基準の種類を確認して（Ｓ３１３〜Ｓ３１６）、制限基準に応じて配信の可否判断を行う（Ｓ３１７〜Ｓ３２０）。まず制限基準が公開率方式か確認して（Ｓ３１３）、異なる場合は制限基準が連続再生時間方式か確認する（Ｓ３１４）。連続再生方式でもなければ、制限基準が禁止区間方式か確認して（Ｓ３１５）、さらに異なるならば人気順か確認する（Ｓ３１６）。すべての基準に該当しない場合には配信拒否を通知し（Ｓ３２１）、終了する。

上述の何れかの制限基準に該当した場合には、判断結果に応じて配信拒否を通知（Ｓ３２１）または、配信許可を通知し（Ｓ３２２）、終了する。

なお、配信判断基準が設定されていない場合、配信許可に変更してもよい。また、基準に該当しない場合の挙動を配信許可に変更して実施してもよい。制限基準は上述の４方式以外の方式を追加してもよく、その場合はステップ３１６の制限基準の種類確認に続いて追加した制限基準の種類確認を行う。

図１３を参照して、公開率に基づく配信判断の判定を説明する。ここで、図１３は公開率に基づく配信判断の判定を説明する図である。図１３において、図１３（ａ）は映像の時間経過、（ｂ）は映像公開率管理テーブルである。映像データ４００に対して、映像データを複数のセグメント（１分単位）に分割した個々のセグメントが公開済みか未公開かを示す映像公開率管理テーブル４０１を用意する。ユーザ１００からの要求に対して、映像データを公開する毎にテーブル４０１の対応するセグメントに公開中フラグ「１」をセットしていく。公開中セグメントがあらかじめ定められた公開率に達すると、すでに公開中フラグがセットされているセグメント以外は配信拒否する。これによりインターネット上に流出した映像断片が配信制限基準で設定した公開率以下となることを保証できる。また、限定配信装置が保持するのは、映像公開率管理テーブルのビットマップだけでなので、公開用の映像データを保存する必要がない。なお、セグメントの単位は１分に限らない。

図１４を参照して、連続再生時間に基づく配信判断の判定を説明する。ここで、図１４は連続再生時間に基づく配信判断の判定を説明する図である。図１４において、図１４（ａ）は映像の時間経過、（ｂ）は連続再生時間管理テーブルである。公開率による配信制限と同様、映像データ４００に対して、映像データを複数のセグメント（１分単位）に分割した個々のセグメントが公開済みか未公開かを示す連続再生時間管理テーブル４０２を用意する。再生先頭時刻と再生末尾時刻とから判断される連続再生時間を超えた領域に公開フラグをセットしようとする場合、配信判断部１２１は、配信拒否をする。配信判断部１２１は、また、要求された再生範囲自体が連続再生時間を越える場合（式１を満たさない場合）にも、配信拒否する。
再生終了時刻 − 再生開始時刻 ＜ 連続再生時間 … 式１
図１５を参照して、公開禁止区間に基づく配信判断の判定を説明する。ここで、図１５は公開禁止区間に基づく配信判断の判定を説明する図である。図１５において、図１５（ａ）は映像の時間経過、（ｂ）は禁止区間管理テーブルである。映像データ４００に対して、映像データを複数のセグメント（１分単位）に分割した個々のセグメントが公開可能か公開禁止かを示す禁止区間テーブル４０３を用意する。あらかじめ、公開禁止区間に禁止フラグ「１」をセットしておき、ユーザ１００から要求された再生範囲中に禁止フラグがなければ、配信判断部１２１は、配信許可し、禁止フラグがあれば、配信判断部１２１は、配信拒否する。

図１６を参照して、人気シーン順に基づく配信判断の判定を説明する。ここで、図１６は人気シーン順に基づく配信判断の判定を説明する図である。図１６において、図１６（ａ）は映像の時間経過、（ｂ）は人気シーン管理テーブル、（ｃ）は公開範囲管理テーブルである。映像データ４００に対して、映像データを複数のセグメント（１分単位）に分割した個々のセグメントのリクエスト数（アクセス数）をカウントした人気シーン管理テーブル４０４と、公開範囲を管理する公開範囲管理テーブル４０５とを用意する。シーン（セグメント）に対してリクエストが発生する毎に人気シーン管理テーブル４０４のセグメントの値をカウントアップする。次に、人気シーン管理テーブル４０４上でカウントされた値が大きいセグメントから順に公開範囲管理テーブル４０５に公開フラグをセットする。配信判断部１２１は、公開フラグがセットされていないセグメントへの配信要求を拒否する。
なお、アクセス数の少ないセグメントから順に公開フラグをセットした不人気順公開など、上述の基準以外にも様々な配信制限基準を追加してもかまわない。また、公開率に基づく配信判断の判定では、早いもの勝ちの公開であったが、人気シーン順に基づく配信判断の判定では、希望者の多いシーンの公開が可能である。また、人気シーン管理テーブルは、サムネイルの要求の数に基づいて作成しても良い。

図１７を参照して、ユーザ端末より要求された範囲の動画を配信する手順を説明する。ここで、図１７はＭＰＥＧストリームのブロック図である。図１７において、ＭＰＥＧストリーム４１０は、パックヘッダ（Pack Header：ＰＨ）４１１とペイロード４２０の繰り返し構造を持つ。ペイロード４２０には画像データが格納されており、パックヘッダ４１１中には、画像データの動画先頭からの経過時間が格納されている。動画配信部１２４は、ユーザ端末１００から要求された開始時刻にもっとも近い時間が記録されているパックヘッダと終了時刻にもっとも近い時間が記録されているパックヘッダをサーチして、その間の画像を配信することにより、ユーザ端末１００より要求された範囲の動画を動的に抽出して配信することができる。

図１８を参照して、ユーザ端末より要求された静止画像を抜き出し配信する手順を説明する。ここで、図１８はＭＰＥＧストリームのブロック図である。ＭＰＥＧストリーム４１０はパックヘッダ４１１と、パックヘッダ４１１に続くペイロードの繰り返しから成る。ペイロードは、ＧＯＰ（Group of Pictures）ヘッダ４２２と、Ｉピクチャ４２３、Ｂピクチャ４２４、Ｐピクチャ４２５の繰り返しから成る。このうちＧＯＰヘッダ４２２以外のＩピクチャ４２３、Ｂピクチャ４２４、Ｐピクチャ４２５は画像データである。ただしＩピクチャ４２３を除いたＢピクチャ４２４、Ｐピクチャ４２５は差分画像であり、前後の画像との差分情報しか持たない。一方、Ｉピクチャ４２３は静止画像として完結した画像データをもつ。通常Ｉピクチャ４２３はＧＯＰヘッダ４２２の直後にある。そこで、ユーザ端末１００より静止画像の要求を受信すると、サムネイル配信部１２３は、要求時刻にもっとも近いパックヘッダ４２１をサーチして、当該パックヘッダ以降にある最初のＧＯＰヘッダ４２２直後のＩピクチャ４２３を抽出して配信する。これにより、限定配信サーバ１０４は、ユーザ端末１０１より要求された静止画像を動的に抽出して配信することができる。

本実施例に拠れば、特に、視聴者によって異なるシーンを部分的に視聴させたい場合には複数の動画断片を用意する必要がなく、動画ファイルを格納するＤＩＳＫドライブ容量の削減効果も期待できる。動画像から静止画像を抽出して配信する機能も併せ持つため、動画像と当該動画像の任意シーン静止画像の配信を同時に行う場合にもＤＩＳＫドライブ容量の削減効果が期待できる。その他にも、動画全体を公開後に動画中に問題のあるシーンが存在することがわかった場合など、問題のあるシーンのみをオリジナル動画像を編集することなく視聴制限することもできる。また、人気の高いシーンなど動画像公開後に動的に定まる基準を視聴制限基準として設定することも可能である。このような動的な視聴制限は、従来方式の組み合わせでは実現困難である。さらに、配信する動画像に別サイトへ視聴者を誘導するリンクを埋め込む機能をもつため、動画の一部を公開してプロモーション用途に用いるような場合には、当該プロモーション効果がより高まることが期待できる。

なお、上述した実施例では一般ユーザとＢＬＯＧオーナとを区別して説明した。しかし、一般ユーザがサムネイルを要求しても構わない。同様にＢＬＯＧオーナが制限のない画像配信を受けても構わない。

図１９を参照して、実施例２の映像配信システムを説明する。ここで、図１９は映像配信システムのブロック図である。図１９において、大規模映像配信システム４Ａは、中央局６と地域毎に設けられる複数のエッジ局５から構成される。各エッジ局５は、映像配信サーバ１０３と限定配信サーバ１０４とが設置されており、ＮＧＮ網１のエンドユーザ３は最寄りのエッジ局５から映像配信サービスを享受する。新しい動画像を配信する場合には中央局６から各エッジ局５に動画データが配布される。動画データは一般にサイズが大きいためなるべく共有するのが望ましい。このため、限定配信サーバ１０４と、映像配信サーバ１０３とは、共通のＮＡＳ（Network Attached Storage）装置１１３Ａを用いて、動画像ファイルを共有している。

限定配信サーバ１０４は、インターネット網２を介して、インターネットのエンドユーザ１００、１０１に限定された画像を配信する。
本実施例では、ＮＡＳ装置を用いるので映像配信サーバと限定配信サーバとで、動画像ファイルを共有できる。

図２０を参照して、実施例３の映像配信システムを説明する。ここで、図２０は映像配信システムのブロック図である。図２０において、大規模映像配信システム４Ｂは、中央局６と地域毎に設けられる複数のエッジ局５から構成される。各エッジ局５は、限定配信サーバの機能を限定配信部１０４Ａとして内蔵する配信サーバ１０３Ａが設置されており、ＮＧＮ網１のエンドユーザ３は最寄りのエッジ局５から映像配信サービスを享受する。また、インターネット網２のエンドユーザ１００、１０１は、インターネット網２を介して、最寄のエッジ局５の配信サーバ１０３の限定配信部１０４Ａから、限定された画像の配信を受けることができる。

本実施例では、映像配信サーバに限定配信機能を組み込んだので、動画像ファイルは一つで構わず、ＮＡＳ装置である必要もない。

映像配信システムのブロック図である。 映像配信システムの詳細なブロック図である。 ユーザ端末、ＷＥＢサーバ、映像配信サーバ、限定配信サーバ、管理端末の間の全体動作シーケンス図である。 ユーザ端末、ＢＬＯＧオーナ端末、管理端末、映像配信サーバ、限定配信サーバの内部動作を含めた動作シーケンス図である。 配信制限基準を説明する図である。 リンク情報を説明する図である。 サムネイル要求を説明する図である。 動画要求を説明する図である。 アクセス履歴情報を説明する図である。 ユーザ端末の処理シーケンス図である。 配信要求受信部の動作フロー図である。 配信判断部の動作フロー図である。 公開率に基づく配信判断の判定を説明する図である。 連続再生時間に基づく配信判断の判定を説明する図である。 公開禁止区間に基づく配信判断の判定を説明する図である。 人気シーン順に基づく配信判断の判定を説明する図である。 ＭＰＥＧストリームのブロック図である。 ＭＰＥＧストリームのブロック図である。 映像配信システムのブロック図である。 映像配信システムのブロック図である。

符号の説明

１００…ユーザ端末、１０１…ＢＬＯＧオーナ端末、１０２…ＷＥＢサーバ、１０３…映像配信サーバ、１０４…限定配信サーバ、１０５…ネットワーク、１０６…管理用端末、１１０…メモリ、１１１…ＣＰＵ、１１２…Ｉ／Ｏインターフェース、１１３…ＤＩＳＫドライブ、１２０…配信判断基準入力部、１２１…配信判断部、１２２…配信要求受信部、１２３…サムネイル配信部、１２４…動画配信部、１２５…コンテンツ視聴状況管理部、１２６…リンク埋め込み部、２００…配信システム。

Claims (11)

1. 記憶部に保存した映像データをネットワークを介してエンドユーザに配信する配信装置において、
   管理端末から受信した配信判断基準に基づいて配信の可否を判断する配信判断部と、第１のユーザから受信した配信要求と前記配信判断部の判断とに基づいて、前記映像データに制約を加えた動画データを前記第１のユーザに送信する動画配信部とからなることを特徴とする配信装置。
2. 請求項１に記載の配信装置であって、
   第２のユーザから受信したサムネイル要求に基づいて、前記映像データから抽出した静止画データを前記第２のユーザに送信することを特徴とする配信装置。
3. 請求項１または請求項２に記載の配信装置であって、
   前記動画データには、制約のない動画データへのリンクが添付されていることを特徴とする配信装置。
4. 請求項１ないし請求項３のいずれか一つに記載の配信装置であって、
   前記制約は、公開率、連続再生時間、公開禁止区間、人気シーン、不人気シーンから選択することを特徴とする配信装置。
5. 請求項１ないし請求項４のいずれか一つに記載の配信装置であって、
   さらに、前記配信要求を管理する視聴状況管理部を備え、
   予め定めたタイミングでアクセス履歴を送信することを特徴とする配信装置。
6. 第１のネットワークに接続された第１の配信装置と、第２のネットワークに接続された第２の配信装置とからなる配信システムであって、
   前記第１の配信装置は、管理端末から受信した配信判断基準に基づいて配信の可否を判断する配信判断部と、第１のユーザから受信した配信要求と、前記配信判断部の判断とに基づいて、前記映像データに制約を加えた第１の動画データを前記第１のユーザに送信する動画配信部とからなり、
   前記第２の配信装置は、前記第１の動画データに添付されたリンクに対応する第２の動画データを前記第１のユーザに送信することを特徴とする配信システム。
7. 請求項６に記載の配信システムであって、
   第２のユーザから受信したサムネイル要求に基づいて、静止画データを前記第２のユーザに送信することを特徴とする配信システム。
8. 請求項６または請求項７に記載の配信システムであって、
   前記第１の配信装置は、予め定めたタイミングでアクセス履歴を前記第２の配信装置に送信することを特徴とする配信システム。
9. ユーザからの配信要求を受信するステップと、
   前記配信要求に対する配信の可否を判定するステップと、
   映像データに制約を加えた第１の動画データと、制約を加えない第２の動画データへのリンクとを前記ユーザに送信するステップと、からなる配信方法。
10. 請求項９に記載の配信方法であって、
    さらに、前記ユーザからサムネイル要求を受信するステップと、
    静止画データと、前記第１の動画データへのリンクとを前記ユーザに送信するステップと、を含む配信方法。
11. 請求項９または請求項１０に記載の配信方法であって、
    さらに、予め定めたタイミングでアクセス履歴を送信するステップを含む配信方法。

Images