JP4303085B2

JP4303085B2 - コンテンツ提供サービスシステム

Info

Publication number: JP4303085B2
Application number: JP2003363558A
Authority: JP
Inventors: 芳美守屋; 博文西川; 悦久山田; 俊一関口; 研二乙井; 嘉明加藤; 光太郎浅井
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2003-10-23
Filing date: 2003-10-23
Publication date: 2009-07-29
Anticipated expiration: 2023-10-23
Also published as: JP2005130196A

Description

この発明は、メタデータに関連付けられて管理される映像コンテンツの効率的な伝送、蓄積、管理、運用を行うコンテンツ提供サービスシステムであって、コンテンツ視聴権をネットワーク上で管理することにより、異なる属性をもつ端末間においてもコンテンツのシームレスな視聴を可能とするコンテンツ提供サービスシステムに関するものである。

近年、ＭＰＥＧ−２，ＭＰＥＧ−４などデジタル映像コンテンツの圧縮技術の普及を背景として、ＤＶＤやハードディスクレコーダ、映像再生機能付携帯電話など、デジタル映像コンテンツを再生・記録する機器・装置が爆発的な普及を見せている。また、インターネットの広帯域化や広帯域モバイル網の整備に伴い、オンラインでデジタル映像コンテンツを伝送、蓄積、管理、運用するシステムの重要性が増している。一方で、いまもってデジタル映像コンテンツはオンラインで直接やりとりするには文書情報などに比してかさばるデータ量であること、かつ、意味内容が時系列変化する情報であることから、その内容を遠隔から的確かつ迅速に確認するためにメタデータを付与することの意義が大きい。このような映像コンテンツへのアクセスを効率化させる目的で、ＭＰＥＧ−７（ＩＳＯ／ＩＥＣ１５９３８）、ＴＶＡｎｙｔｉｍｅ(http://www.tv-anytime.org/)などの国際標準・業界標準の映像メタデータフォーマットが定められている。このような標準化されたメタデータによれば、オンラインでの映像コンテンツ管理・運用を行うシステムは、ネット上で映像コンテンツそのものにアクセスすることなく外部からのアクセス(検索、ブラウジング、フィルタリング)に効率的に対処することができる。

なお、コンテンツに関する詳細情報について記述したメタデータを利用してコンテンツに対する様々な制御を行う従来技術として、例えば、メタデータ配信方法がある。このメタデータ配信方法は、送出側装置で定義された著作権者及び関連する権利の保護に関する視聴者へのコンテンツ提示方法や利用条件の情報等のコンテンツの関連情報を格納したメタデータを受信端末に配信することにより、受信端末によるコンテンツ視聴及び権利保護を制御することができる（例えば、特許文献１参照）。

特開２００２−２０３０７０号公報（第１頁、図１）

しかしながら、上記従来例のようにメタデータを受信端末で管理した場合、メタデータを受信した端末と異なる端末や環境でコンテンツを再生することができないという問題点があった。

この発明は、上述のような課題を解決するためになされたもので、その目的は、コンテンツ視聴権をネットワーク上で管理することにより、コンテンツの利用条件や視聴ステイタスに関する情報を含むメタデータを各種の端末・環境で利用できるコンテンツ提供サービスシステムを得るものである。

この発明に係るコンテンツ提供サービスシステムは、第１及び第２の端末、並びに第１のサーバがネットワークを介して相互に接続されているコンテンツ提供サービスシステムにおいて、前記第１の端末は、ディスプレイ上に表示されたコンテンツメニューが参照され購入者により選択されたコンテンツを購入する場合には、入力された購入者識別情報を含む購入要求を送信し、前記第１のサーバは、前記購入要求を受信すると、前記購入者が購入したコンテンツを視聴する権利であり少なくとも前記購入者識別情報及び前記購入したコンテンツを特定する情報を含むコンテンツ視聴権を生成・管理し、前記第２の端末は、前記コンテンツ視聴権を使用して、前記購入者が購入したコンテンツを視聴し、前記第１のサーバは、コンテンツメニューを作成する処理手順を記述した第１の処理手順スクリプトを前記第１の端末へ送信し、前記第１の端末は、前記第１の処理手順スクリプトの解析を行い、記述されている処理手順に基づきコンテンツメニューを作成する処理手順スクリプトブラウザを有するものである。

この発明に係るコンテンツ提供サービスシステムは、コンテンツ視聴権をネットワーク上で管理することにより、コンテンツの利用条件や視聴ステイタスに関する情報を含むメタデータを各種の端末・環境で利用できるという効果を奏する。

実施の形態１．
この発明の実施の形態１に係るコンテンツ提供サービスシステムについて図面を参照しながら説明する。図１は、この発明の実施の形態１に係るコンテンツ提供サービスシステムの全体構成を示す図である。なお、各図中、同一符号は同一又は相当部分を示す。

図１において、購入端末（第１の端末）１とコンテンツ購入処理サーバ（第１のサーバ）２は、ネットワークを介して接続されている。このネットワークとは、携帯電話回線上に構成されるＩＰ網、インターネット、専用回線、放送網などである。購入端末１は店舗に配置された購入端末でもよいし、各種のパソコンや、各家庭のＴＶ受像機などの受信機、携帯電話などネットワークに接続可能な端末であればよい。購入端末１には購入者を識別するための購入者識別情報３を入力する。例えば、購入端末１にＩＣカードを投入してもよいし、購入端末１に携帯電話を接続し、携帯電話のＩＰアドレスや電話番号などをＩＤとして用いることもできる。

また、コンテンツ配信サーバ（第２のサーバ）４と映像端末（第２の端末）５とはネットワークを介して接続されている。このネットワークとは、携帯電話回線上に構成されるＩＰ網、インターネット、専用回線、放送網などである。映像端末５には購入端末１へ入力した購入者識別情報３と同じＩＤを入力する。なお、購入端末１と映像端末５とは例えば家庭の受信機など同一装置で構成されていてもよい。また、購入端末１、コンテンツ購入処理サーバ２、コンテンツ配信サーバ４、及び映像端末５は、上記ネットワークを通じてそれぞれ相互に接続されている。さらに、コンテンツ購入処理サーバ２や、コンテンツ配信サーバ４は、複数のサーバ等から構成される上位概念のサーバの場合がある。

メタデータ６は、映像データ７に関連付けられており、少なくとも、映像データ７の例えばシーンのタイトル、シーンの開始点・長さなどのシーン構成と、個々のシーンの映像、音声等のメディアデータに関する特徴量を記述したデータである。この特徴量として、ＭＰＥＧ−７のメタデータが使用されることもある。

アダプテーションヒント８は、メタデータ６に関連付けられており、個々のメタデータ６に実際にどのようなデータが含まれているかを記述したメタデータの要約情報である。図１において、メタデータ６、アダプテーションヒント８は、コンテンツ購入処理サーバ２の一部として蓄積されているものとして図示されているが、これらはインターネット上の任意のサーバに配置されていてもよい。アダプテーションヒント８は、ＭＰＥＧ−２１の適応化の項目で定義されたものが使用されることがある。

つぎに、この実施の形態１に係るコンテンツ提供サービスシステムの動作について図面を参照しながら説明する。

最初に、コンテンツ購入処理について説明する。

コンテンツ購入処理サーバ２は、例えばネット配信型コンテンツサービスプロバイダが運用するものであり、サービス加入ユーザごとにカスタマイズされた、お勧めのコンテンツメニュー９(Recommended Contents Menu、以下、ＲＣＭと略す。)を購入端末１に送出する。

ＲＣＭ９は、システムがユーザに勧めるコンテンツの一覧情報であり、例えば各コンテンツの代表画像のサムネイルや映像クリップ、コンテンツのロケータ(ＵＲＬなど)、コンテンツのタイトル、概要説明情報（概要情報、総再生時間など）、購入価格といったデータが含まれる。

ユーザは、サービスプロバイダ等のコンテンツ購入処理サーバ２から送られてくるＲＣＭ９を購入端末１のディスプレイ上に表示して、自分が視聴したいコンテンツを選択し、購入者識別情報３を含む購入要求１０をコンテンツ購入処理サーバ２へ送出する。

コンテンツ購入処理サーバ２は、その内部の機能ブロックである購入処理部１１において、適切なユーザ認証のもとで購入者識別情報３を含む購入要求１０を処理する。すなわち、選択されたコンテンツに関連付けられているメタデータ６や、ＲＣＭ９を参照して後で説明する種々の情報から、ユーザが購入したコンテンツを視聴する権利情報であるコンテンツ視聴権１２を生成してコンテンツ視聴権管理部１３に登録する。また、購入要求１０は、ユーザが何を選択したかの情報となるため、選択されたコンテンツに関連付けられているメタデータ６からタイトル、ジャンル、キーワードなどの情報を吸い上げ、サービスプロバイダ側の個々の加入ユーザの情報である、ユーザプロファイル１４として蓄積・更新しておき、以降のＲＣＭ９の供給時に反映させる。

ＲＣＭ作成部（コンテンツメニュー作成部）１５は、更新されたユーザプロファイル１４を用いて、常にユーザの最新の嗜好を反映したＲＣＭ９を送信することができる。コンテンツ視聴権管理部１３は購入処理部１１からコンテンツ視聴権１２の登録を受け付けるとともに、映像端末５からの要求に従って、コンテンツ視聴権１２の情報を映像端末５へ送信する。これらの処理については後述する。なお、図１において、コンテンツ視聴権管理部１３は、コンテンツ購入処理サーバ２の一部の機能として記載されているが、インターネット上の任意のサーバの機能であってもよい。

図２にコンテンツ視聴権１２の一例を示す。コンテンツ視聴権１２は、例えば、図２に示すように、購入したユーザを識別するための購入者識別情報、ユーザが購入したコンテンツのタイトルや、概要情報、購入日時、コンテンツの内容である映像データ７のＵＲＬ等のロケータ情報、コンテンツの総再生時間、有効期限、有効再生回数、映像データ７のどの時刻から再生すればよいかの再生開始時間、再生回数のいずれか、あるいは全部を含むデジタルデータである。

ＲＣＭ作成部１５は、例えばネット上もしくはローカルの大容量ディスクに蓄積されたサービス提供対象となる映像コンテンツに関連付けて蓄積される膨大なメタデータ６を入力して、該入力メタデータそれぞれについて付与されているアダプテーションヒント８と、ユーザプロファイル１４を用いてターゲットとなるメタデータの部位をフィルタリングし、それらを統合することによってお勧めのコンテンツメニューであるＲＣＭ９を作成し送出する。具体的には、ターゲットとなるメタデータの部位とは、ユーザ嗜好としてユーザプロファイル１４に登録されてキーワードに合致する映像シーンを示すメタデータなどである。

ここで、アダプテーションヒント８は、対応するメタデータ６の特定のデータ種別に着目して、メタデータ６の実データ（以下、インスタンスと呼ぶ。）に、着目する種別のデータがどの程度含まれているかを示す概要・要約情報である。例えば、着目するデータ種別の例として、ＭＰＥＧ−７で規定される、映像シーンを特定の観点から見た場合の重要度を記述するデータである「PointOfView記述子」を考える。このPointOfView記述子は、以下のようなデータシンタックスで表現される。

viewpointとは、上記の「観点」を記述するデータであり、いわば映像シーンをある側面から見た場合の特徴的なキーワードの情報と言い換えることができる。

Importanceとは、０〜１の範囲で定義され、あるviewpointから映像シーンを見た場合に、該viewpointの意味で当該映像シーンがどの程度重要度が高いシーンかを示す情報である。上記のデータ例では、ある映像シーンを「スポーツ」という観点から見た場合に、その重要度は０．５、すなわち１００％を最重要とすれば５０％のそこそこの程度である、ということを記述していることになる。ＲＣＭ作成部１５は、アダプテーションヒント８としてＭＰＥＧ−７で規定されるPointOfView記述子のviewpointの内容と、ユーザプロファイル１４とのマッチングによって、ユーザが望むコンテンツのメタデータを抽出・特定することができる。

なお、ＭＰＥＧ−７規格の標準準拠性の観点からは、ＭＰＥＧ−７で規定される記述子は、スキーマ（シンタックス定義）によってメタデータ６のインスタンス内に含まれることが規定されても、実際のインスタンスに記述として現れるかどうかは、インスタンスを確認する以外に知る手段がない。したがって、映像コンテンツのように時系列で長時間の映像データでは、<PointOfView記述子>のような映像シーン単位に出現の状況が異なるような記述子がメタデータ６のインスタンス内にどの程度含まれているか、サブシーン階層構造を有する映像コンテンツの場合にどの階層に含まれているかなどの情報は、メタデータ６のみでは事前に知ることができないので、上記の例のように「スポーツ」を含む映像シーンの存在を<PointOfView>でチェックするにはメタデータ６のすべての解析作業が必要となる。

この解析処理の処理量を低減する目的で、メタデータ要約情報としてのアダプテーションヒント８を用いることになる。このアダプテーションヒント８は、例えば解析対象のメタデータ６に何個の<PointOfView>が含まれるか、どの階層に<PointOfView>が含まれるか、などのメタデータ６のインスタンスに関する要約情報を記述する。したがって、端的な例を示せば、複数のメタデータ６をチェックする前にアダプテーションヒント８を確認して、個々のメタデータ６に<PointOfView>が少なくとも１つ含まれるかどうかを知ることができれば、<PointOfView>が含まれるメタデータ６についてのみ、そのインスタンスの記述内容を解析すればよいため、ＲＣＭ９を生成するためのユーザプロファイル１４とメタデータ６とのマッチング処理量を大幅に削減することができる。このアダプテーションヒント８は、ＭＰＥＧ−２１のＰａｒｔ−７の適応化で議論されている。

次に、以上の手順により購入したコンテンツを映像端末５で再生する手順について説明する。

映像端末５とは家庭の受信機、映像コンテンツの再生が可能な携帯電話、パソコンなどであり、映像コンテンツの再生機能とネットワークへの接続環境を持っていれば何でもよい。映像端末５には購入端末１へ入力した購入者識別情報３と同じＩＤを入力する。映像端末５は購入者識別情報３を含む視聴要求をコンテンツ視聴権管理部１３へ送出し、コンテンツ視聴権管理部１３よりコンテンツ視聴権１２とそれに基づく視聴可能なコンテンツ情報の一覧を取得する。映像端末５はユーザからの要求に従って、ユーザが選択したコンテンツのコンテンツ視聴権１２と端末情報１６をコンテンツ配信サーバ４へ送出する。

端末情報１６は、映像端末５に固有で、標準的なデータ定義に従って記述される情報として映像端末５から標準的な手順に従ってコンテンツ配信サーバ４に送信される。端末情報１６は、少なくとも、映像端末５の表示可能な時間・空間解像度や、受信可能な映像データフォーマット、例えば符号化方式やビットレートなどを含んでいる。また、映像端末５とコンテンツ配信サーバ４とをつなぐネットワークの状況（QoS）の情報を含むこともある。

コンテンツ配信サーバ４では、映像フォーマット判定部１７がコンテンツ視聴権１２を解析し、送信すべき映像データ７の情報（ロケータや再生開始時刻など）を取得する。また、端末情報１６に従って、映像端末５に送信すべき映像データ７の最適なデータフォーマット、すなわち適応化映像データ１８のデータフォーマットを決定する。データフォーマットの種別には、例えばＭＰＥＧ−４、ＭＰＥＧ−２、Ｍｏｔｉｏｎ−ＪＰＥＧ、ＪＰＥＧ、Ｗｉｎｄｏｗｓ（登録商標）ＭｅｄｉａＶｉｄｅｏ、ＤｉｖＸなどがある。また、画面サイズにあわせた解像度等もフォーマット情報の一部である。次に、決定した送出映像データフォーマットに対して、コンテンツ配信サーバ４自身からそのまま送出可能な映像データか、自分自身でリアルタイムに映像データフォーマットの変換を行いながら送出すべきデータか、あるいは他と連携して動作する別のサーバから送出することが適当な映像データか、などの判断を行い、映像フォーマット変換部１９にフォーマット情報２０を送信し、送信すべき映像データ７の情報（ロケータや再生開始時間）を映像データサーバ２１に送信する。映像データの送出時に、前記のネットワークの状況(QoS)に従い送出することもある。

映像データサーバ２１は、映像データのロケータ情報で指示される場所に格納される映像データ７を要求された再生開始時間から、映像フォーマット変換部１９に送信する。

映像フォーマット変換部１９は、映像データサーバ２１からの映像データ７を、映像フォーマット判定部１７からのフォーマット情報２０で示される映像データフォーマットに変換したものを、適応化映像データ１８として映像端末５に送信する。なお、フォーマット変換の必要がない場合には映像データ７がそのまま適応化映像データ１８として映像端末５に送信される。

なお、映像端末５では、映像再生を中断した場合、中断した時刻でのコンテンツ視聴権１２をコンテンツ視聴権管理部１３に送信する。コンテンツ視聴権管理部１３は、中断した時刻に基づきコンテンツ視聴権１２の再生開始時間を更新する。映像端末５で再生を中断したときの時刻に基づきコンテンツ視聴権管理部１３で管理されているコンテンツ視聴権１２の再生開始時間を更新することにより、別の種類の映像端末５からアクセスした場合でも上記と同様の手順で映像データ７の配信を要求することにより、映像再生を中断した時刻から再び映像を再生することができる。また、最後まで映像再生を行った場合には、コンテンツ視聴権１２の再生回数を更新する。

つづいて、コンテンツ視聴権管理部におけるコンテンツ視聴権の管理方法について説明する。

コンテンツ視聴権管理部１３は、購入処理部１１からのコンテンツ視聴権１２の登録を受け付け、図２に例示したフォーマットで管理する。

映像端末５から視聴可能なコンテンツ情報の一覧の送信要求（視聴要求）を受け付けると、映像端末５から送信される購入者識別情報３に基づき、管理しているコンテンツ視聴権１２の中から相当するコンテンツ視聴権１２を選択する。コンテンツ視聴権１２の有効期限や有効再生回数等の視聴制限に基づき視聴可能なコンテンツを選択し、それらのコンテンツ視聴権１２から視聴可能なコンテンツ情報の一覧を作成し、映像端末５へ送信する。また、映像端末５からは、再生を中断した時刻や再生を終了した旨の情報を取得し、再生開始時間や再生回数の更新を行う。

コンテンツ視聴権管理部１３はユーザからの要求に従い上述したような処理を行うほかに、例えば映像データ７の蓄積場所が変更になった場合にはそれに対応してコンテンツ視聴権１２で管理されている映像データ７のロケータ情報を更新したり、有効期限が近づいているコンテンツを購入しているユーザに対しその旨通知するサービスを行ったり、ユーザが再生を中断した場合にすでに視聴した映像についてダイジェストを作成しておき、次回ユーザが中断した時刻から再生を開始する前にダイジェスト映像を提供するなどのサービスを提供することも出来る。

本実施の形態１によれば、コンテンツの視聴権利や視聴ステイタスを記述したコンテンツ視聴権１２をネットワーク上で管理するようにしたので、コンテンツ視聴権１２を適切なユーザ認証に基づき取得することにより、いつでもどこでも、異なる映像端末においてコンテンツを取得し再生することができる。また、コンテンツ視聴権１２をネットワーク上で管理することにより、映像コンテンツの蓄積場所の変更などコンテンツ視聴権１２に記述されている内容が変更した場合でも記述の変更が容易である。

実施の形態２．
この発明の実施の形態２に係るコンテンツ提供サービスシステムについて図面を参照しながら説明する。図３は、この発明の実施の形態２に係るコンテンツ提供サービスシステムの一部構成を示す図である。

この図３は、実施の形態２における購入端末１とコンテンツ購入処理サーバ２の構成を示す。なお、コンテンツ配信サーバ４と映像端末５は実施の形態１と同じであるため、図３には図示せずに説明を省略する。

実施の形態１におけるコンテンツ購入処理サーバ２は、ＲＣＭ作成部１５にてユーザへのお勧めメニューであるＲＣＭを作成し送出していたが、本実施の形態２におけるコンテンツ購入処理サーバ２では、ＲＣＭを作成する処理手順を記述した処理手順スクリプト（第１の処理手順スクリプト）２２を購入端末１へ送出し、購入端末１の処理手順スクリプトブラウザ２４で処理手順スクリプト２２の解析を行い、記述されている処理手順に基づきＲＣＭ９の作成を行う。

以下に図３の購入端末１およびコンテツ購入処理サーバ２における購入処理フローについて説明する。

コンテンツ購入処理サーバ２は、ユーザごとにカスタマイズされたお勧めのコンテンツメニュー９の作成処理手順を記述した処理手順スクリプト２２を購入端末１へ送出する。

図４は、ＲＣＭ作成手順を記述した処理手順スクリプトの一例を示す。この図４では、処理手順スクリプト２２をＸＭＬで記述している。処理手順スクリプト２２には、入力メタデータ、アダプテーションヒント、ユーザプロファイルの所在が記述されている。次にＲＣＭ作成手順の記述として、"GenerateRCM()"という関数が定義され、メタデータ、アダプテーションヒント、ユーザプロファイルを取得し、それらを入力として"AdaptationMetadata()"を実行することが指示されている。この"AdaptationMetadata()"は、入力メタデータ、アダプテーションヒント、ユーザプロファイルを用いて入力メタデータのフィルタリングおよび統合を行う標準ＡＰＩ関数である。

購入端末１の処理手順スクリプトブラウザ２４は、ＲＣＭ作成手順を記述した処理手順スクリプト２２を受け取り、標準的に定められた手順で解析を行い、解析された記述に従って、ＲＣＭの作成を行う。図４に示したように、処理手順スクリプト２２には入力データの所在が記載されているので、処理手順スクリプト２２の記述に基づき、入力データとして、メタデータ６、アダプテーションヒント８、ユーザプロファイル１４および端末情報１６を所定の場所から取得する。次に、処理手順スクリプト２２の記述に基づき、取得したメタデータ６、アダプテーションヒント８、ユーザプロファイル１４を用いて入力メタデータのフィルタリングおよび統合を行い、ＲＣＭ９の作成を行う。なお、メタデータのフィルタリングおよび統合処理は標準ＡＰＩ関数として定義されており、ＡＰＩ関数の処理はＡＰＩ処理部２７にて行われる。また、一度ダウンロードした処理手順スクリプト２２、メタデータ６およびアダプテーションヒント８は、購入端末１のキャッシュ２３に蓄積され、同じ処理を行う場合にはキャッシュ２３から取得することもできる。

ＡＰＩ処理部２７は、処理手順スクリプトブラウザ２４からの要求に基づき、処理手順スクリプト２２に記述されているＡＰＩ関数のモジュール（ＡＰＩモジュール２５）をコンテツ購入処理サーバ２からダウンロードし、ＡＰＩ関数の処理を行う。なお、一度ダウンロードしたＡＰＩモジュール２５は購入端末１のキャッシュ２６に蓄積され、同じ処理を行う場合にはキャッシュ２６から取得することもできる。

処理手順スクリプトブラウザ２４から出力されるＲＣＭ９はディスプレイ上に表示され、ユーザは自分が視聴したいコンテンツを選択し、購入要求１０を送出する。購入要求１０は、コンテンツ購入処理サーバ２の購入処理部１１にて処理する。以降の処理については実施の形態１と同様であるため、説明を省略する。

本実施の形態２によれば、ユーザ毎のお勧めコンテンツメニューの作成を行うＲＣＭ作成部１５をハードウェアモジュールあるいはソフトウェアモジュールとしてコンテンツ購入処理サーバ２に設けておくのではなく、コンテンツ購入処理サーバ２は、お勧めコンテンツメニューの作成を行う手順を記述した処理手順スクリプト２２を購入端末１に送信し、購入端末１側で処理手順スクリプト２２を標準的に定められた手順で解析し、必要に応じて処理を行うＡＰＩモジュール２５を取得してＲＣＭ９の作成を行うようにしたので、コンテンツ購入処理サーバ２における処理負荷を軽減することができる。また、購入端末１側もＲＣＭ作成部として専用のハードウェアモジュールあるいはソフトウェアモジュールを備えておく必要はなく、標準で定められた処理手順スクリプト２２の記述を解析する処理手順スクリプトブラウザ２４と、必要に応じてＡＰＩモジュール２５を取得し、実行する仕組みがあればよく、購入端末１の構成を小さくすることができる。

実施の形態３．
この発明の実施の形態３に係るコンテンツ提供サービスシステムについて図面を参照しながら説明する。図５は、この発明の実施の形態３に係るコンテンツ提供サービスシステムの一部構成を示す図である。

この図５は、本実施の形態３におけるコンテンツ配信サーバ４と映像端末５の構成を示す。なお、購入端末１とコンテンツ購入処理サーバ２の構成は実施の形態１または実施の形態２のいずれかと同じであるため、図５には図示せずに、説明を省略する。

実施の形態１では映像フォーマット判定部１７がコンテンツ視聴権１２を解析し、送信すべき映像データ７の情報（ロケータや再生開始時間）を取得するようにしたが、本実施の形態３では映像端末５の再生制御部２８がコンテンツ視聴権１２を解析し、送信すべき映像データ７の情報（再生情報３１）を取得する。また、実施の形態１におけるコンテンツ配信サーバ４では、映像フォーマット判定部１７が端末情報１６に従って、適応化映像データ１８のデータフォーマットを決定し、映像フォーマット変換部１９が映像フォーマット判定部１７で決定されたフォーマット情報２０に基づき、映像データ７のフォーマット変換を行い、映像端末５に送出していたが、本実施の形態３では、映像端末５の端末性能がフォーマット変換の処理を行うのに十分な場合には、映像データ７をそのまま受け取り、映像端末５の再生制御部２８にてフォーマット変換を行う。映像端末５の端末性能がフォーマット変換の処理を行うのに不十分な場合には、実施の形態１と同様にコンテンツ配信サーバ４で行う。

以下に図５のコンテンツ配信サーバ４および映像端末５における映像データ配信・再生処理フローについて説明する。

映像端末５には購入端末１へ入力した購入者識別情報３と同じＩＤを入力する。映像端末５は購入者識別情報３を含む視聴要求をコンテンツ視聴権管理部１３へ送出し、コンテンツ視聴権管理部１３よりコンテンツ視聴権１２とそれに基づく視聴可能なコンテンツ情報の一覧を取得する。

映像端末５の再生制御部２８は、ユーザからの要求に従って視聴可能なコンテンツ情報の一覧中から視聴したいコンテンツを選択すると、ユーザが選択したコンテンツのコンテンツ視聴権１２を解析し、そのコンテンツ視聴権１２から送信すべき映像データ７の情報（再生情報３１）を取得する。

次に、ユーザが選択したコンテンツを取得して、再生する手順について説明する。

ユーザが選択したコンテンツに関する再生情報３１は、コンテンツ配信サーバ４へ送出される。コンテンツ配信サーバ４の処理手順スクリプト作成部３２は、再生情報３１に従って、ユーザが選択したコンテンツを再生する処理手順を記述した処理手順スクリプト（第２の処理手順スクリプト）２９を作成し、映像端末５の再生制御部２８へ送出する。

図６は、映像コンテンツを再生する手順を記述した処理手順スクリプト２９の一例を示す。図６の処理手順スクリプト２９では、コンテンツの所在と再生開始時間を記述したファイルの所在が記述されている。次に、コンテンツの再生および停止手順の記述として、それぞれ"PlayContents()"と"StopContents()"という関数を定義している。"PlayContents()"ではまずコンテンツの所在と再生開始時間を記述したファイルを解析し、コンテンツの所在と再生開始時間を取得する。次に、指定したコンテンツの変換を行う標準ＡＰＩ関数"AdaptationMedia(...)"を呼び出す。さらに、指定したコンテンツを指定した時間から再生する標準ＡＰＩ関数"Play(...)"を呼び出し、"AdaptationMedia(...)"により得られた適応化映像データを指定した時間から再生する。"StopContents()"ではまず"Play(...)"で呼び出したプレイヤを停止する標準ＡＰＩ関数"Stop(...)"を呼び出し、コンテンツの所在と再生開始時間を記述したファイルに記述されている再生開始時間をユーザが再生を停止した時間に基づき更新する。

映像端末５の再生制御部２８は、コンテンツを再生する手順を記述した処理手順スクリプト２９を、処理手順スクリプト作成部３２から受け取り、標準的に定められた手順で解析を行う。次に、解析した処理手順スクリプト２９の記述に従って、まず入力データである映像データ７を映像データサーバ２１から取得する。次に、映像端末５の端末情報１６に従って、映像端末５で再生可能なデータフォーマットを決定し、フォーマット変換を行う。なお、フォーマット変換を行う処理は標準ＡＰＩ関数（図６の"AdaptationMedia()"）として定義されているので、対応するＡＰＩモジュール３０をコンテンツ配信サーバ４より取得し、取得したＡＰＩモジュールを実行することによりフォーマット変換を行う。次に、処理手順スクリプト２９の記述に従って、フォーマット変換後の適応化映像データの再生を行う。なお、フォーマット変換の必要がない場合には映像データ７がそのまま適応化映像データとして再生される。

フォーマット変換時において端末性能によってはフォーマット変換の処理を行うことができない場合がある。このときには、コンテンツ配信サーバ４でフォーマット変換の処理を行うようにしてもよい。再生制御部２８は映像フォーマット変換部１９に、選択した映像データ７のフォーマット変換を要求する。映像フォーマット変換部１９は映像データサーバ２１より映像データ７を取得し、フォーマット変換を行い、適応化映像データ１８を映像端末５へ送出する。

なお、映像フォーマット変換部１９はコンテンツ配信サーバ４内に設けるようにしたが、コンテンツ配信サーバ４とネットワークで接続された別のサーバに設けてもよい。また、コンテンツ配信サーバ４とネットワークで接続された別のサーバに予め映像フォーマット変換部１９を設けるのではなく、コンテンツ配信サーバ４からフォーマット変換用のＡＰＩモジュールを取得して実行するようにしてもよい。

また、フォーマット変換用のＡＰＩモジュールはコンテンツ配信サーバ４から提供されるようにしたが、コンテンツ配信サーバ４以外のサーバから提供されるようにしても良い。

本実施の形態３によれば、コンテンツ視聴権１２の解析を受信端末である映像端末５側で行うようにしたので、コンテンツ配信サーバ４における処理負荷を軽減することができる。また、映像データのフォーマット変換処理をコンテンツ配信サーバ４で行うのではなく、コンテンツ配信サーバ４はフォーマット変換処理を含むコンテンツの再生手順を記述した処理手順スクリプト２９を受信端末である映像端末５に送信し、映像端末５側で処理手順スクリプト２９を標準的に定められた手順で解析し、必要に応じてＡＰＩモジュール３０を取得してフォーマット変換および再生処理を行うようにしたので、コンテンツ配信サーバ４における処理負荷を軽減することができる。さらに、映像端末５側も予めフォーマット変換を行う専用のハードウェアモジュールあるいはソフトウェアモジュールを備えておく必要はないので、映像端末５の構成を小さくすることができる。

この発明の実施の形態１に係るコンテンツ提供サービスシステムの全体構成を示す図である。この発明の実施の形態１に係るコンテンツ提供サービスシステムのコンテンツ視聴権の一例を示す図である。この発明の実施の形態２に係るコンテンツ提供サービスシステムの一部構成を示す図である。この発明の実施の形態２に係るコンテンツ提供サービスシステムのＲＣＭ作成手順を記述した処理手順スクリプトの一例を示す図である。この発明の実施の形態３に係るコンテンツ提供サービスシステムの一部構成を示す図である。この発明の実施の形態３に係るコンテンツ提供サービスシステムの映像コンテンツ再生手順を記述した処理手順スクリプトの一例を示す図である。

符号の説明

１購入端末、２コンテンツ購入処理サーバ、３購入者識別情報、４コンテンツ配信サーバ、５映像端末、６メタデータ、７映像データ、８アダプテーションヒント、９ＲＣＭ、１０購入要求、１１購入処理部、１２コンテンツ視聴権、１３コンテンツ視聴権管理部、１４ユーザプロファイル、１５ＲＣＭ作成部、１６端末情報、１７映像フォーマット判定部、１８適応化映像データ、１９映像フォーマット変換部、２０フォーマット情報、２１映像データサーバ、２２処理手順スクリプト、２３キャッシュ、２４処理手順スクリプトブラウザ、２５ＡＰＩモジュール、２６キャッシュ、２７ＡＰＩ処理部、２８再生制御部、２９処理手順スクリプト、３０ＡＰＩモジュール、３１再生情報、３２処理手順スクリプト作成部。

Claims

第１及び第２の端末、並びに第１のサーバがネットワークを介して接続されているコンテンツ提供サービスシステムにおいて、
前記第１の端末は、ディスプレイ上に表示されたコンテンツメニューが参照され購入者により選択されたコンテンツを購入する場合には、入力された購入者識別情報を含む購入要求を送信し、
前記第１のサーバは、前記購入要求を受信すると、前記購入者が購入したコンテンツを視聴する権利であり少なくとも前記購入者識別情報及び前記購入したコンテンツを特定する情報を含むコンテンツ視聴権を生成・管理し、
前記第２の端末は、前記コンテンツ視聴権を使用して、前記購入者が購入したコンテンツを視聴し、
前記第１のサーバは、コンテンツメニューを作成する処理手順を記述した第１の処理手順スクリプトを前記第１の端末へ送信し、
前記第１の端末は、前記第１の処理手順スクリプトの解析を行い、記述されている処理手順に基づきコンテンツメニューを作成する処理手順スクリプトブラウザを有する
ことを特徴とするコンテンツ提供サービスシステム。
前記第１の処理手順スクリプトは、コンテンツに関する詳細情報について記述したメタデータの所在の記述、前記メタデータの要約情報であるアダプテーションヒントの所在の記述、ユーザの情報について記述したユーザプロファイルの所在の記述、及びコンテンツメニュー作成手順の記述を少なくとも含む
ことを特徴とする請求項１記載のコンテンツ提供サービスシステム。
第１及び第２の端末、並びに第１のサーバがネットワークを介して接続されているコンテンツ提供サービスシステムにおいて、
前記第１の端末は、ディスプレイ上に表示されたコンテンツメニューが参照され購入者により選択されたコンテンツを購入する場合には、入力された購入者識別情報を含む購入要求を送信し、
前記第１のサーバは、前記購入要求を受信すると、前記購入者が購入したコンテンツを視聴する権利であり少なくとも前記購入者識別情報及び前記購入したコンテンツを特定する情報を含むコンテンツ視聴権を生成・管理し、
前記第２の端末は、前記コンテンツ視聴権を使用して、前記購入者が購入したコンテンツを視聴し、
少なくとも前記コンテンツメニューに掲載されたコンテンツの映像データを格納する第２のサーバが前記ネットワークにさらに接続され、
前記第２のサーバは、購入者が購入したコンテンツを特定する再生情報に従って、購入者が購入したコンテンツを再生する処理手順を記述した第２の処理手順スクリプトを作成し、前記第２の端末へ送信する処理手順スクリプト作成部を有し、
前記第２の端末は、映像データを取得して再生する再生制御部を有するとともに、前記購入者が購入したコンテンツを視聴する場合には、前記第１の端末で使用したものと同じ購入者識別情報を含む視聴要求を前記第１のサーバへ送信して前記コンテンツ視聴権を前記第１のサーバから取得し、
前記再生制御部が、前記取得したコンテンツ視聴権を解析し前記再生情報を取得して前記第２のサーバへ送信し、取得した前記第２の処理手順スクリプトの解析を行い、記述されている処理手順に基づき前記購入したコンテンツの映像データを前記第２のサーバから取得して再生する
ことを特徴とするコンテンツ提供サービスシステム。
前記第２の処理手順スクリプトは、購入者が購入したコンテンツの所在と再生開始時間を記述したファイルの所在の記述、並びに購入者が購入したコンテンツの再生及び停止手順の記述を少なくとも含む
ことを特徴とする請求項３記載のコンテンツ提供サービスシステム。