以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施形態は、番組配信タイプのコンテンツ配信システムであって、端末装置から受信したリクエストに基づいてコンテンツを配信するシステムに対して本発明を適用した場合の実施形態である。
[1.コンテンツ配信システムの構成等]
まず、図1を参照して、コンテンツ配信システムの概要構成等について説明する。
図1は、本実施形態に係るコンテンツ配信システムの概要構成例を示す図である。図1に示すように、本実施形態に係るコンテンツ配信システムSは、本発明のコンテンツ配信装置としてのコンテンツ配信サーバ1と、複数のコンテンツデータを記憶しているコンテンツデータベース2と、複数の端末装置3a〜3eと、を備えている。
コンテンツ配信サーバ1、コンテンツデータベース2及び各端末装置3a〜3eには、各々IPアドレスが割り当てられており、これら装置は、ネットワークの一例としてのインターネット4に接続可能となっている。なお、コンテンツデータベース2をコンテンツ配信サーバ1の内部に有することとしてもよく、この場合にはコンテンツデータベース2にはIPアドレスは割り当てなくてもよい。
なお、端末装置3a〜3eのいずれかの端末装置を示す場合には、便宜上、端末装置3という場合がある。
このコンテンツ配信システムSは、端末装置3からリクエストされたコンテンツのうち、配信するコンテンツを選択するための条件(以下、「配信条件」とする。)を満たすコンテンツデータを配信するものである。
そして、このコンテンツデータの配信は、配信要求を行った端末装置3に対して行われるものであり、コンテンツリクエストを送信した端末装置3に限られない。すなわち、配信要求を行った端末装置3は、他の端末装置3がリクエストしたコンテンツのデータ配信も行われる。
このようなコンテンツ配信システムSにおける概略動作を、図2を参照して説明する。図2は、本実施形態に係るコンテンツ配信装置の概要動作を示すフローチャートである。
まず、コンテンツ配信サーバ1において、配信条件などが設定される(ステップS1)。
次に、端末装置3からのコンテンツ配信のリクエスト、すなわち、端末装置3のユーザがコンテンツ配信サーバ1から配信してもらいたいコンテンツを特定したリクエスト(以下、「コンテンツリクエスト」とする。)を呼びかける呼びかけ情報を端末装置3に対して送信して、コンテンツリクエストの受付を開始する(ステップS2)。
その後、端末装置3のユーザは、端末装置3を操作し、コンテンツリクエストをコンテンツ配信サーバ1へ送信する。コンテンツ配信サーバ1は、端末装置3から送信されるコンテンツリクエストを受信する(ステップS3)。
そして、コンテンツ配信サーバ1は、このようにリクエストされたコンテンツのうち、配信条件を満たすコンテンツを選択し、選択したコンテンツに対応するコンテンツデータベース2のコンテンツデータを、配信要求している端末装置3へ配信する。(ステップS4)。
このように送信されたコンテンツデータは、各端末装置3上で再生される。なお、最初に選択するコンテンツは、端末装置3からのコンテンツリクエストではなく、配信条件を満たすコンテンツをコンテンツデータベース2へ問い合わせるようにすることもできる。このようにすれば、配信条件が設定された後に、端末装置3からのコンテンツリクエストを待たずにコンテンツデータの配信をすることができる。
また、配信条件を満たすコンテンツリクエストが端末装置3から送信されてくるまで、配信条件に合致するコンテンツをコンテンツデータベース2から取出すようにすることもできる。
以降、端末装置3からのリクエストを受け付けながら(ステップS5)、配信条件を満たすコンテンツのデータを選択し、順次連続して端末装置3へ配信する。
このようにコンテンツ配信サーバ1は、配信条件を満たすコンテンツを選択しつつ、選択されたコンテンツのデータを順次配信しているため、コンテンツデータの配信開始を早くすることができると共に、選択処理を集中させることがなく、システムのパフォーマンスを低下させない。
しかも、コンテンツデータの配信を開始した後に新しくコンテンツデータベース2に格納されたコンテンツデータも配信対象とすることができる。さらに、端末装置3からのリクエストから配信されるコンテンツが選択されるため、コンテンツ配信システムSの運営者はコンテンツ選択の手間を省くことができる。
一方、端末装置3のユーザである視聴者は、配信条件を満たすコンテンツを各端末装置3上で視聴することができるので、その配信条件を満たすコンテンツを連続して視聴したいユーザはコンテンツを選択するための操作を省略でき、利便性に優れている。
なお、コンテンツ配信サーバ1は、端末装置3からのコンテンツリクエストに対してコンテンツデータを配信するための配信番組のチャンネル(以下、「配信チャンネル」とする。)を複数設けており、端末装置3はこの配信チャンネルごとにコンテンツデータの配信を要求し、配信の要求を行った配信チャンネルからコンテンツデータの配信を受けることができる。なお、この配信チャンネルごとに配信条件を含む配信チャンネル条件が設けられており、その配信チャンネル条件に従ってコンテンツデータの配信が行われる。
ここで、上記各コンテンツデータは、例えば音声データと映像データ等の少なくとも一方のコンテンツデータにより構成されており、より具体的には、ポップスやクラシックなどの楽曲データや、映画などの映像データなどが該当する。
また、各コンテンツデータは、コンテンツデータベース2に記憶保存され、更に、各コンテンツデータに関連する付帯データとして、各々固有のコンテンツIDのほか、楽曲であれば、歌手、作詞家、作曲家、ジャンル、発表日などが、又映像であれば、タイトル、作者、出演者、ジャンル、発表日などが、各コンテンツデータのヘッダ部分に記述されている。なお、これらのコンテンツ識別情報は必ずしもコンテンツデータのヘッダ部分に記述されていなくてもよく、例えば、タグデータとして各コンテンツデータに関連付けられてコンテンツデータベース2に記憶保存されるようにしてもよい。
[2.コンテンツ配信サーバの構成等]
次に、図3を参照して、コンテンツ配信サーバ1の構成及び機能について説明する。
図3は、本実施形態に係るコンテンツ配信サーバ1の概要構成例を示す図である。コンテンツ配信サーバ1は、一般のサーバコンピュータを適用可能であり、図3に示すように、CPU(Central Processing Unit)、作業用RAM(Random-Access Memory)、各種データ及びプログラム等を記録(格納)するROM等から構成された制御部11と、各種データやプログラム等を記憶(格納)するHDD(Hard Disc Drive)等から構成された記憶部12と、インターネット4を介して端末装置3との間で通信を行ったり、LAN(Local Area Network)を介してコンテンツデータベース2と通信を行うための通信部13と、所定の情報を入力可能なキーボードやマウス等の入力部14を備えて構成され、これらの各種構成要素はバス15を介して相互に接続されている。
なお、コンテンツ配信サーバ1には、図示しないが、表示装置(液晶ディスプレイ等)等が接続されるようになっており、例えば、コンテンツ配信サーバ1を運用する運営側のオペレータは、この表示装置を見ながら入力部14から所定の情報を入力することができる。
(記憶部12について)
記憶部12には、接続(アクセス)してきた端末装置3に対して提示(提供)するための各種データ等が記憶されている。例えば、コンテンツの配信やリクエストの受付などに使用されるWebページ(例えば、HTML(Hyper Text Markup Language)やXML(eXtensible Markup Language)等により構成)のベースとなるデータやこれに貼り付ける画像データ等も記憶されている。
また、記憶部12には、図4に示すように、配信条件を含む配信チャンネル条件メモリ領域、コンテンツリクエストメモリ領域、配信待ちコンテンツメモリ領域及び配信済コンテンツ数メモリ領域を有する配信チャンネルメモリ領域が、配信チャンネルごとに確保されている。
なお、配信チャンネル条件は、後述する配信条件設定手段によりこの配信チャンネル条件メモリ領域に設定されて、又端末装置3からのコンテンツリクエストは、後述するコンテンツリクエスト受信手段によって受信されてこのコンテンツリクエストメモリ領域に設定される。
(配信チャンネル条件メモリ領域)
ここで、配信チャンネル条件メモリ領域は、図4に示すように、コンテンツのジャンルやそのデータの物理的特徴などを定義する配信条件領域、配信するコンテンツ数を定義する配信コンテンツ数領域、配信の開始及び終了を定義する配信時間帯領域、コンテンツの配信を特定の端末装置に限定する(非公開)のか、しない(公開)のかを定義する公開/非公開領域などがある。
配信チャンネル条件領域は、端末装置3から送信されるコンテンツリクエストの中から配信するコンテンツデータを選別するために、「静かな楽曲」や「適度に動きのある楽曲」などといった選択基準情報を含む配信条件を格納する領域である。
配信コンテンツ数領域は、配信チャンネル条件に基づいて配信するコンテンツデータの数を格納する領域である。
配信時間帯領域は、後述する配信手段がコンテンツデータの配信を開始する時間と、その配信を終了する時間を格納する領域である。これらの時間は、分単位又は時単位で設定することができる。なお、この領域で設定された配信終了時間になると、その配信チャンネル条件での配信を終了することになるが、この配信終了時間に到達する前に、配信コンテンツ数領域に格納された数のコンテンツデータの配信が終了すると、その配信チャンネル条件での配信を終了する。
公開/非公開領域は、コンテンツの配信先を、特定の端末装置3とするのか、不特定の端末装置3かを設定するための領域であり、特定の端末装置3のIDやIPアドレスなどが設定される。
この領域が“非公開”と設定されている場合には、後述する配信手段が、配信チャンネル条件を設定した端末装置3のみのアクセスに対してその配信チャンネル条件でのコンテンツデータの配信を行い、他の端末装置3からのアクセスに対してはコンテンツデータの配信を行わない。
一方、この領域が“公開”と設定されている場合には、配信手段は、どの端末装置3からのアクセスに対してもその配信チャンネル条件でのコンテンツデータの配信を行う。なお、非公開の設定として、複数の端末装置3のIDやIPアドレスを設定する領域を設けることもでき、設定された複数の端末装置3へのコンテンツデータの配信を可能とするようにしてもよい。
(コンテンツリクエストメモリ領域)
また、コンテンツリクエストメモリ領域は、リクエストされたコンテンツ情報(コンテンツ名など)と共に、その情報に関し配信条件を満たすかどうかの判定が行われたか否かを示す情報(以下、「選択情報」とする。)とが関連付けられて格納される領域である。
(配信待ちコンテンツメモリ領域)
また、配信待ちコンテンツメモリ領域は、選択手段で選択されたコンテンツ情報が一時的に格納される領域であり、後述の配信手段により配信中のコンテンツ情報、その直前に配信が終わったコンテンツ情報、及び、配信待ちのコンテンツ情報が格納される。なお、本実施形態においては、配信待ちのコンテンツを2つ格納することができるがこれに制限されない。また、配信が終了したもので古いものはこの領域から削除される。
(配信済コンテンツ数メモリ領域)
また、配信済コンテンツ数メモリ領域は、配信が終了したコンテンツの数が格納される領域であり、後述する配信手段により配信が終了するたびに、制御部11によってこの数がインクリメントされる。
なお、この配信待ちコンテンツメモリ領域には、コンテンツ情報ではなく、選択手段が選択したコンテンツ情報に対応するコンテンツデータをコンテンツデータベース2から受信して、格納するようにしてもよい。
また、本実施形態では、リクエストメモリ領域と配信待ちコンテンツメモリ領域とを分けているが、配信待ちコンテンツメモリ領域を設けずに、コンテンツリクエストメモリ領域の選択情報に、配信中、配信終了番号、配信待ち番号を加えるようにしてもよい。
(制御部11について)
制御部11は、CPUが記憶部12等に記憶されたプログラム(本発明のコンテンツ配信プログラムを含む)を読み出して実行することにより、コンテンツ配信サーバ1全体を統括制御し、かつ、本発明の配信条件受信手段、配信条件設定手段、配信リクエスト受信手段(コンテンツリクエスト受信手段を含む。)、選択手段、配信手段、通知手段、Webページ提供手段等として機能させるようになっている。
なお、コンテンツ配信プログラムは、例えば、インターネット4に接続されたサーバ等から記憶部12にダウンロードされるようにしてもよく、又CD−ROM等の記憶媒体に記録されてから当該記憶媒体のドライブを介して、記憶部12に読み込まれるようにしてもよい。
(配信条件受信手段)
そして、制御部11は、配信条件受信手段として、端末装置3から送信される配信チャンネル条件(特定された一つの配信チャンネルにおける配信条件、放送コンテンツ数、放送時間帯、放送公開種別などを含む)を受信する。
(配信条件設定手段)
また、制御部11は、配信条件設定手段として、配信条件受信手段で受信又は入力部14から入力された配信チャンネル条件を記憶部12に記憶することにより設定する。
(配信リクエスト受信手段)
また、制御部11は、配信リクエスト受信手段として、端末装置3から送信される、コンテンツの配信要求を受信すると共に、配信条件受信手段と同様の動作をする。
(コンテンツリクエスト受信手段)
また、制御部11は、コンテンツリクエスト受信手段として、インターネット4を介して端末装置3から送信されるコンテンツリクエストを受信する。このコンテンツリクエストには、例えば、「G線上のアリア」や「バッヘルベルのカレン」といった楽曲名や、「ローマの休日」といった映画タイトルが含まれており、コンテンツリクエスト受信手段は、端末装置3から送信されるコンテンツリクエストからこれらの楽曲や映画タイトル等を受信する。
(選択手段)
さらに、制御部11は、選択手段として、コンテンツリクエスト受信手段で受信したコンテンツリクエストに対応するコンテンツが、配信条件設定手段によって設定された配信条件を満たすかどうかを判定し、配信条件を満たすコンテンツを選択する。
すなわち、選択手段は、リクエスト受信手段が受信したコンテンツリクエストに対応するコンテンツデータをコンテンツデータベース2に要求し、その要求に対してコンテンツデータベース2から送信されるコンテンツデータ及びそのコンテンツ識別情報を取得すると共に、その取得したコンテンツデータやそのコンテンツ識別情報を以下に説明する分類方法によって分類し、その分類された結果が記憶部12に記憶されている配信条件を満たすかどうかを判定する。
このように選択されたコンテンツは、配信待ちコンテンツとして記憶部12の配信待ちコンテンツメモリ領域(本発明の配信データ記憶手段)に記憶される。
また、この選択手段は、後述する配信手段がコンテンツデータの配信を開始した後も、配信条件を満たすコンテンツの選択を行う。例えば、選択手段は、配信待ちコンテンツメモリ領域に記憶されているコンテンツ情報が所定数以下であるときに動作するようにする。このようにすることによって、連続的なコンテンツデータの配信を確保すると共に、選択処理を可及的に少なくすることができる。
また、選択手段が最初に選択するコンテンツは、配信条件を満たすコンテンツリクエストが端末装置3から送られてきていないとき(コンテンツリクエストを全く受信していない場合も含む)には、選択手段によって配信条件を満たすコンテンツをコンテンツデータベース2から取出すようにし、この選択は、配信条件を満たすコンテンツリクエストが端末装置3から送信されてくるまで継続する。
ここで、配信条件とは、コンテンツを選択するための選択基準情報であり、選択手段はこの選択基準情報を満たすコンテンツのデータを選択する。なお、この選択基準情報を満たすか否かの判定時間を設定することもできる。この判定時間を長くすれば、コンテンツデータをより細かく、複雑な分析をすることができる。
コンテンツデータの選択方法として、コンテンツデータに含まれる音声データや映像データの物理的な特徴による選択方法や上述のコンテンツデータに関連するデータ(本発明のコンテンツ識別情報)から類推される特徴による選択方法などがある。なお、コンテンツ配信サーバ1の入力部14からの入力又は端末装置3から送信により、いずれの選択方法で選択するかの情報、後述の記憶部12の配信チャンネルメモリ領域に設定することができる。
まず、コンテンツデータの物理的特徴による選択方法について説明する。
音声データの物理的特徴としては、拍子、節、音色などがあり、音楽データを再生することによって得られる音楽信号から音量の平均・最大・最小・偏差や全体に占める特定の周波数帯域の割合などを分析することによって算出される。
そして、この物理的特徴に基づいて、「静かな楽曲」、「適度に動きのある楽曲」、「ビートの効いた楽曲」といった分類を行うことができる。
例えば、音量の変化率が低く、低域周波数が多く含まれている曲は、「静かな楽曲」と分類される。選択手段は、音声データが属する分類を分析し、その分析結果が配信条件を満たすかどうかを判定して、配信条件を満たす音声データを選択する。
図5に、音楽データの物理的特徴を分析して、音楽データを分類分けする処理のフローチャートを示す。なお、この分析はコンテンツ配信サーバ1の選択手段によって行われる。
まず、分析対象となる音声データを取り出し、音声データを高速再生(スキャンニング)(ステップS11)をしながら、音量解析(音の強弱と偏差の解析)を行う(ステップS12)と同時に、周波数成分解析(周波数成分の偏差の解析)を行う(ステップS13)。
その後、これらの解析が終了した時点で、曲調判断処理が開始される(ステップS14)。そして、この音量解析の結果から、高音量偏差が認められる(すなわち、感覚的に大きな音が比較的安定して続く)か否かを判定する(ステップS15)。
その結果、高音量偏差が認められると判定された場合には、低域周波数偏向パターンの分析を行う(ステップS16)。低域周波数偏向パターンは、音楽における低音打楽器が規則的にリズムを刻んでいるかどうかによって音調を判断するもので、低域周波数のヒストグラムを作成することによって分析する。
例えば、作成したヒストグラムから100kHz以下の成分のピークが0.5秒ごとに現れると判定すると、基準音価が一分間に120(メトロノーム表示M.M.基準音符=120)の比較的早いテンポで演奏される、リズムを強調した楽曲であると判定する。
ステップS16において低域周波数偏向パターンを分析した結果、低域周波数偏向パターンがあると判定すると、分析した音声データは、比較的大音量で激しくリズムを刻むダンスミュージックのような曲調の楽曲、または規則性を持った機械騒音であると判定する(ステップS17)。
また、ステップS16において低域周波数偏向パターンがないと判定すると、分析した音声データは、比較的大音量であるが規則的なリズムの強調がされていない大編成のオーケストラ音楽等であると判定する(ステップS18)。
一方、ステップS15で高音量偏向が認められず、感覚的に小さな音が比較的安定して続いていると判定すると、ステップS16と同様に低域周波数偏向パターンを分析する(ステップS19)。
その結果、低域周波数偏向パターンがあると判定すると、分析した音声データは、比較的小音量であるが、リズムを強調したボーカル曲のような楽曲であると判定する(ステップS20)。
一方、低域周波数偏向パターンがないと判定すると、分析した音声データは、比較的小音量であり、規則的なリズムが強調されて静かな楽曲であると判定する(ステップS21)。
また、映像データの物理的特徴としては、動きや色相などがあり、映像データを再生することによって得られる映像信号から明度、彩度、フレーム間差分などの情報を分析することによって算出される。
例えば、映像フレーム間の差分の偏向が大きく、色相周波数の偏向パターンが検出されるものは、動きが大きいが特定の色相の偏りは認められないと分析し、感覚刺激の強い映像と分類する。選択手段は、映像データが属する分類を分析し、その分析結果が配信条件を満たすかどうかを判定して、配信条件を満たす映像データを選択する。
図6に、映像データの物理的特徴を分析して、音楽データを分類分けする処理のフローチャートを示す。なお、この分析はコンテンツ配信サーバ1の選択手段によって行われる。
まず、分析対象となる映像データを取り出し、映像データを高速再生(スキャンニング)する(ステップS31)。
そして、高速再生をしながら、フレーム間差分解析を行う(ステップS32)と同時に、色相周波数成分解析を行う(ステップS33)。
そして、これらの解析が終了した時点で、映像判断処理が開始され(ステップS34)、まずフレーム間差分解析の結果から、偏向が認められる(すなわち、視覚的に動きの多い)か否かを判定する(ステップS35)。
その結果、偏向が認められると判定された場合には、特定の色相への偏向があるか否かの分析を行う。また、心理的に刺激の強い色相が強調されているか否かも明度及び彩度から分析する(ステップS36)。
ステップS36で色相周波数偏差パターンがあると判定すると、分析した映像データは、動きが多く、特定の色調に偏りが認められる視覚的刺激が非常に強い映像であると判定する(ステップS37)。
一方、色相周波数偏差パターンがないと判定すると、分析した映像データは、動きが多いが、特定の色調に偏りが認められない比較的視覚的刺激が強い映像であると判定する(ステップS38)。
一方、ステップS35でフレーム間差分偏向が認められないと判定すると、特定の色相への偏向があるか否かの分析を行う。また、心理的に刺激の強い色相が強調されているか否かも明度及び彩度から分析する(ステップS39)。
ステップS39で色相周波数偏差パターンがあると判定すると、分析した映像データは、動きは少ないが、特定の色調に偏りが認められる少し視覚的刺激が強い映像であると判定する(ステップS40)。
一方、色相周波数偏差パターンがないと判定すると、分析した映像データは、動きが少なく多く、特定の色調に偏りが認められない比較的視覚的刺激が少ない映像であると判定する(ステップS41)。
次に、コンテンツデータに関連するデータ、すなわちコンテンツ識別情報から類推して選択する方法について説明する。コンテンツ情報に関連するデータから類推される特徴としては、言語データなどがあり、例えば、音楽データであれば、歌手、作詞家、作曲家、ジャンル、発表日などから、又映像データであれば、タイトル、作者、出演者、ジャンル、発表日などからコンテンツデータの分類分けをする。例えば、「サムライ」、「カタナ」、「エド」の語を含むものを、日本の時代劇の映像データと類推するがごときである。
選択手段は、この類推の結果が配信条件を満たすかどうかを判定して、配信条件を満たすコンテンツを選択し、記憶部12の配信待ちコンテンツメモリ領域に記憶する。
(配信手段)
さらに、制御部11は、配信手段として、選択手段で選択され、記憶部12の配信待ちコンテンツメモリ領域に記憶されたコンテンツのコンテンツデータを取り出して、インターネット4を介して、端末装置3へ配信する。
また、この配信手段は、コンテンツデータを配信するための複数の配信チャンネルを有し、この配信チャンネル毎にコンテンツデータの連続的な配信を行う。
さらに、配信手段は、公開/非公開領域の情報に基づいて、所定の端末装置以外の端末装置3からのアクセスに対しては、コンテンツデータの配信を行わないようにする。
なお、配信待ちコンテンツメモリ領域に記憶されるものがコンテンツ情報のときには、このコンテンツ情報に基づいて、コンテンツデータベース2から対応するコンテンツデータを取出して、端末装置3へ配信する。一方、配信待ちコンテンツメモリ領域に記憶されるものがコンテンツデータのときには、そのコンテンツデータを取り出して、端末装置3へ配信する。
(通知手段)
さらに、制御部11は、通知手段として、端末装置3から送信されたコンテンツリクエストが選択手段によって選択することができない場合に、その端末装置3へその旨を示す情報を通知する。
また、選択手段が、リクエストされた配信チャンネルでは選択することができない場合であっても、そのリクエストが他の配信チャンネルの配信条件を満たすときには、その配信チャンネルの情報と共に、そのコンテンツリクエストに対応するコンテンツデータを、コンテンツリクエストを行った端末装置3へ送信する。
(Webページ提供手段)
本実施形態のコンテンツ配信サーバ1には、端末装置3の表示装置上で表示するための、配信チャンネルの状態を一覧にしたトップページ及び配信チャンネル毎のチャンネルページを提供するWebページ提供手段が設けられている。以下その詳細について説明する。
トップページは、各配信チャンネルのアクセス先及びその配信チャンネルがどのような配信チャンネル条件等にあるかを記述した配信チャンネル一覧を端末装置3で表示するための情報である。そして、このトップページがWebページ提供手段により端末装置3へ送信される。
より具体的に説明すると、制御部11のWebページ提供手段は、端末装置3からHttpプロトコルにより行われるコンテンツ配信サーバ1のIPアドレスに対するアクセスを、通信部13を介して受信すると、このHttpのヘッダからgetメソッドのリクエストURI(Uniform Resource Identifier)を取り出す。
そして、取り出したリクエストURIが<http://www.content-server.com/>の場合には、端末装置3からのアクセスがトップページを要求するものであると判定し、各配信チャンネルに対応する配信チャンネル領域から配信チャンネル条件等を取り出す。
次に、取り出した配信チャンネル条件等を利用してトップページのWebページを生成し、アクセスした端末装置3へ送信する。
そして、端末装置3は、このトップページを受信して、内蔵したブラウザプログラム(以下、単に「ブラウザ」とする。)によって、そのトップページを表示部に表示する。
また、トップページには、各配信チャンネルへアクセスするための情報がハイパーリンク形式で記述されており、端末装置3のユーザは、このハイパーリンクを利用して、各配信チャンネルにアクセスすることができる。
すなわち、端末装置3のユーザが上述のトップページから一つの配信チャンネルへのアクセスを要求(端末装置3の表示手段に表示された配信チャンネルのボタンを押下)することによって、要求した配信チャンネルのアドレスに対するチャンネルページの取得要求が、Httpプロトコルにより端末装置3からコンテンツ配信サーバ1へ送られる。そして、Webページ提供手段は、その要求に対応するチャンネルページを提供する。
たとえば、リクエストURIが<http://www.content-server.com/channel-1/>とすると、制御部11は、<channel-1>を識別し、端末装置3からのアクセスが配信チャンネル1に対するものであると判定する。
そして、記憶部12から配信チャンネル1に対応する配信チャンネル領域から配信条件やリクエスト情報を取り出して、配信チャンネル1のチャンネルページを生成し、アクセスした端末装置3へ送信する。
同様に、リクエストURIが<http://www.content-server.com/channel-3/>とすると、制御部11は、端末装置3からのアクセスを配信チャンネル3に対するものであると判定し、記憶部12から配信チャンネル3に対応する配信チャンネル領域から配信条件やリクエスト情報を取り出して、配信チャンネル3のチャンネルページを生成し、アクセスした端末装置3へ送信する。
また、このチャンネルページには、配信されているコンテンツデータの取得をコンテンツ配信サーバ1へ要求(すなわち、コンテンツ配信要求)するように記述されており、端末装置3は、チャンネルページを取得すると、そのページの情報に従って、表示部にその配信チャンネルの配信条件やリクエスト情報を表示すると共に、コンテンツデータの配信を要求する。
そして、端末装置3は配信されるコンテンツデータを受信すると、そのコンテンツデータを再生して、表示部に映像を表示したり、音声出力部から音声を出力したりする。
このように、制御部11は、端末装置3から送信されるリクエストURIに応じて、種々の異なるWebページを生成して、アクセスした端末装置3へ送信することができる。
なお、このようにURI中のディレクトリでチャンネルページを複数設けるといった方法ではなく、TCP/IPのポート番号を利用して配信チャンネルを複数も受けるようにすることもできる。
例えば、<http://www.content-server.com:8081>は、配信チャンネル1のWebページの要求とし、<http://www.content-server.com:8083>は、配信チャンネル3のWebページの要求とする等である。
また、IPアドレスごとに、チャンネルページを複数設けてもよい。
また、ディレクトリとポート番号やIPアドレスとを組み合わせることもできる。たとえば、トップページやチャンネルページなどのWebページの提供は、各ディレクトリへのアクセスに応じて行い、コンテンツ配信要求に関しては、配信チャンネルごとにアクセス先のポート番号を設けて、そのポート番号にアクセスさせるようチャネルページに記述する。なお、通信プロトコルをTCP/IPのみにするのではなく、Webページの提供をTCPプロトコルで行い、コンテンツの配信はUDPプロトコルで行うようにすることもできる。
[3.コンテンツデータベースサーバの構成等]
次に、図7を参照して、コンテンツデータベースの構成及び機能について説明する。図7は、本実施形態におけるコンテンツデータベース2の構成概要例を示す図である。
コンテンツデータベース2は、一般のサーバコンピュータを適用可能であり、図7に示すように、CPU、作業用RAM、各種データ及びプログラムを記憶するROM等から構成された制御部21と、各種データ及びプログラム等を記憶(格納)するHDD等から構成された記憶部22と、コンテンツデータ及びそれに関連するコンテンツ識別情報を関連付けて記憶するデータベース23と、インターネット4を介して端末装置3やコンテンツ配信サーバ1との間で通信を行うための通信部24と、を備えて構成され、これらの各構成要素は、バス25を介して相互に接続される。
制御部21は、CPUが記憶部等に記憶したプログラムを読み出して実行することにより、コンテンツ要求受信手段と、コンテンツデータ検索手段と、コンテンツ送信手段等として機能するようになっている。なお、このプログラムは、例えば、インターネット4上の所定サーバからダウンロードされるようにしてもよいし、例えば、CD−ROM等の記憶媒体に記憶されてこの記憶媒体のドライブを介して読み出されるようにしてもよい。
このようなコンテンツデータベース2において、制御部21は、コンテンツ要求受信手段としてコンテンツ配信サーバ1からコンテンツリクエストの情報を受信し、コンテンツ検索手段としてコンテンツリクエストの情報に対応するコンテンツデータがデータベースに存在するかどうかを検索する。
コンテンツ検索手段によりコンテンツリクエストに対応するコンテンツデータが存在すると確認されると、コンテンツ検索手段によって、そのコンテンツデータに関連するコンテンツ識別情報がコンテンツデータベース2から取り出される。
そして、制御部21は、コンテンツ送信手段として、コンテンツデータベース2から取り出したコンテンツデータ及びそのコンテンツ識別情報を、コンテンツ配信サーバ1へ送信する。なお、コンテンツリクエストに対応するコンテンツデータがデータベースにないとコンテンツ検索手段により判定されると、コンテンツ送信手段は、その旨をコンテンツ配信サーバ1へ送信する。
[4.端末装置の構成等]
次に、図8を参照して、端末装置3の構成及び機能について説明する。図8は、端末装置3の概要構成例を示す図である。
各端末装置3は、例えば一般の汎用コンピュータのほか、携帯電話機、PDA(Personal digital assistant)などの携帯端末や、STB(Set Top Box)付きの受像機等を適用可能である。
そして、各端末装置3は、図8に示すように、CPU,作業用RAM,各種データ及びプログラムを記憶するROM等から構成された制御部31と、各種データ及びWebブラウザなどのプログラム等を記憶保存(格納)するためのHDD等から構成された記憶部32と、受信されたコンテンツデータやWebページデータなどを一時蓄積するバッファメモリ33と、コンテンツデータ(ビデオデータ)をデコード(データ伸張や復号化等)するデコーダ部34と、当該デコードされたコンテンツデータ(ビデオデータ)等に対して所定の描画処理を施しビデオ信号として出力する映像処理部35と、当該映像処理部35から出力されたビデオ信号に基づき映像表示するCRT,液晶ディスプレイ等の表示部36と、上記デコードされたコンテンツデータ(オーディオデータ)をアナログオーディオ信号にD(Digital)/A(Analog)変換した後これをアンプにより増幅して出力する音声処理部37と、当該音声処理部37から出力されたオーディオ信号を音波として出力するスピーカ38と、インターネット4を通じて他の端末装置3やコンテンツ配信サーバ3との間で通信を行うための通信部39と、ユーザから情報を入力するための入力部(例えば、キーボード、マウス、或いは、操作パネル等)40と、バス41を備えて構成され、制御部31、記憶部32、バッファメモリ33、デコーダ部34、及び通信部39はバス41を介して相互に接続されている。
そして、制御部31は、CPUが記憶部32等に記憶された各種プログラムを実行することにより、端末装置3全体を統括制御するようになっている。
上述したように、制御部31は、コンテンツ配信サーバ1から送信されたWebページデータ及び画像データ等の情報をブラウザにより表示部36の表示画面上に表示(以下、「ブラウザ画面」とする。)する。
また、制御部31は、ユーザから入力部40を介して入力されたコンテンツリクエストや配信チャンネル条件等を、コンテンツ配信サーバ1に通信部39等を介して送信する。
また、制御部31は、接続したコンテンツ配信サーバ1から送信されたWebページデータに基づいて、コンテンツ配信要求をコンテンツ配信サーバ1に送信する。
[5.コンテンツ配信システムの動作]
次に、図9〜図11を参照して、コンテンツ配信システムSの動作について説明する。
図9は、本実施形態に係るコンテンツ配信装置の動作を示すフローチャート、図10は、本実施形態に係るポータルページを示す図、図11は、本実施形態に係るトップページを示す図である。
まず、端末装置3のユーザが入力部40を操作して、端末装置3のブラウザ表示画面にコンテンツ配信サーバ1のURIを指定すると、端末装置3のブラウザは、このURIに対するIPアドレス(すなわち、コンテンツ配信サーバ1のIPアドレス)をDNSサーバ(図示せず)から取得して、TCP/IPパケットのヘッダ部にあて先IPアドレスとして設定すると共に、TCP/IPパケットのデータ部として、HttpヘッダのGetメソッドにURIを設定(get=”http://www.content-server.com)する。
そして、端末装置3のブラウザは、このTCP/IPパケットを、通信部39を介してインターネット4へHttpプロトコルにより送信する。
一方、このようにして端末装置3から送信されたTCP/IPパケットは、インターネット4を介して、コンテンツ配信サーバ1にルーティングされる。そして、このTCP/IPパケットをコンテンツ配信サーバ1が受信する。すると、図9のフローチャートがスタートする。
コンテンツ配信サーバ1の制御部11は、このパケットのHttpヘッダからURIを取り出して、そのURIに応じたWebページを生成し、端末装置3に対して生成したWebページを送信する。
ここでは、URIとして、“www.content-server.com”が指定されているので、コンテンツ配信サーバのポータルWebページ(以下、「ポータルページ」とする。)に必要なデータ(例えば、日付や新着情報など)を記憶部12から取り出して、ポータルページを生成して、アクセス元の端末装置3へ送信する(ステップS102)。
端末装置3のブラウザは、このポータルページを受信して表示部36にブラウザの表示画面(以下、「ブラウザ画面」とする。)として表示する。このように表示した画面の例を図10に示す。
ブラウザ画面に表示されたポータルページには、IDとパスワードの入力ボックスと、入力されたID及びパスワードをコンテンツ配信サーバ1へ送信するための送信ボタンが配置されており、端末装置3のユーザがIDとパスワードを入力後に送信ボタンを押すと、ポータルページのHTMLデータの記述に従って、入力されたIDとパスワードがコンテンツ配信サーバ1に送信されると共に、コンテンツ配信サーバ1に対しての配信チャンネル番組一覧を表示するためのトップページの送信要求も同時に行われる。
コンテンツ配信サーバ1の制御部11は、端末装置3からID及びパスワードを受信するとその認証を行い(ステップS103)。受信したID及びパスワードが記憶部12に記憶されているものと一致したら(ステップS103:Y)認証したものとし、一致しなければ再びポータルページを端末装置3へ送信する(ステップS103:N)。
ステップS103で、コンテンツ配信サーバ1の制御部11により端末装置3の認証が行われると(ステップS103)、制御部11は、記憶部12の各配信チャンネルメモリ領域から配信条件や配信状態などのデータを取り出して、端末装置3のIDに応じて、トップページを生成する。そして、生成したトップページを、その端末装置3へ送信する(ステップS104)。
一方、端末装置3のブラウザは、送信されたトップページをブラウザ画面に表示する。このようにブラウザ画面に表示されるトップページの例を図11に示す。図11に示すトップページには、コンテンツ配信サーバ1が端末装置3に対して提供する5つの配信チャンネルの状態が、配信チャンネルごとに表示される。
例えば、配信チャンネル1は、配信条件として「落ち着いたクラシック」が設定されており、かつ配信するコンテンツデータが全10曲であり、現在3曲目を配信中であることを示している。加えて、この配信チャンネル1では、まだ端末装置3からのリクエストを受付け中であることを示している。
また、配信チャンネル2では、配信チャンネル状態が設定されていない状態である。すなわち、端末装置3から配信チャンネルの設定が可能であることを示している。
さらに、配信チャンネル4では、トップページを表示している端末装置3からはコンテンツデータの配信を受けられない配信チャンネル条件(すなわち、アクセスを許可する端末装置3が特定されている)が設定されていることを示している。
このように、トップページには、コンテンツ配信サーバ1の各配信チャンネルの状態を表示されており、端末装置3のユーザは、容易に好みの配信チャンネルを選ぶことができる。
ここで、トップページには、チャンネルボタン1〜5が設けられている。そして、端末装置3のユーザは、これらのボタンをブラウザ画面上で入力部40によって選択することにより、好みの配信チャンネルを選択することができる。
具体的には、端末装置3で選択された配信チャンネルの情報は、通信部13からインターネット4を介して、コンテンツ配信サーバ1に送信される。
例えば、配信チャンネル1を選択した場合には、上述したように<http://www.content-server.com/channel-1/>がHttpヘッダに設定されて、TCP/IPパケットが送信される。
一方、コンテンツ配信サーバ1の制御部11は、端末装置3からチャンネルページの要求を受信すると、要求対象の配信チャンネルの配信中チャンネルか否か(すなわち、設定された配信チャンネル条件に従ってコンテンツが配信中の配信チャンネルか否か)を、要求対象の配信チャンネルの配信チャンネルメモリ領域に格納されたデータから判定する(ステップS105)。
例えば、配信チャンネルメモリ領域に、すでに配信したコンテンツ又は配信中のコンテンツがある場合や、配信済コンテンツ数が1以上の場合に、配信中チャンネルであると判定する。
そして、この判定の結果、要求対象の配信チャンネルが配信中チャンネルである場合には、配信中チャンネル処理(ステップS200)に移行する。
また、コンテンツ配信サーバ1の制御部11が、要求対象の配信チャンネルが配信中チャンネルではないと判定すると、次に、この要求対象の配信チャンネルが、コンテンツを配信することが決定されている状態の配信チャンネル(以下、「配信決定段階チャンネル」とする。)か否かを判定する(ステップS106)。
例えば、配信チャンネルメモリ領域に、すでに配信条件が設定されているものの、配信したコンテンツ又は配信中のコンテンツがない場合や、配信済みコンテンツ数が0である場合に、配信決定段階チャンネルであると判定する。
そして、この判定の結果、要求対象の配信チャンネルが配信決定段階チャンネルである場合には、配信決定段階チャンネル処理(ステップS300)に移行する。
また、コンテンツ配信サーバ1の制御部11が、要求対象の配信チャンネルが配信決定段階チャンネルでもないと判定すると、要求対象の配信チャンネルは、コンテンツを配信することが決定されていない状態の配信チャンネル(以下、「空き配信チャンネル」とする。)であるかを判定する(ステップS107)。
そして、判定の結果、空き配信チャンネルであるときに、空き配信チャンネル処理(ステップS400)に移行する。
(配信中チャンネル処理)
次に、図12〜図21を参照して、配信中チャンネル処理について具体的に説明する。
図12は本実施形態におけるコンテンツ配信サーバ1の配信中チャンネル処理フローチャートを示す図、図13は本実施形態における配信中チャンネルページを示す図、図14は本実施形態におけるコンテンツ配信サーバ1のリクエスト処理フローチャートを示す図、図15は本実施形態におけるコンテンツ配信サーバ1のリクエスト受信フローチャートを示す図、図16は本実施形態におけるリクエストページを示す図、図17は本実施形態におけるコンテンツ配信サーバ1のコンテンツ選択配信処理フローチャートを示す図、図18、図19は本実施形態におけるコンテンツ配信サーバ1のコンテンツ選択処理フローチャートを示す図、図20は本実施形態におけるリクエスト拒否ページを示す図、図21は本実施形態における第2の配信決定待機チャンネルページを示す図である。
配信中チャンネル処理が開始されると、コンテンツ配信サーバ1の制御部11は、要求対象の配信チャンネルに対応する配信チャンネルメモリ領域から、配信条件を含む配信チャンネル条件及びコンテンツリクエストを取り出して(ステップS201)、配信中チャンネルのチャンネルページ(以下、「配信中チャンネルページ」とする。)を生成する(ステップS202)。
そして、生成した配信中チャンネルページを、インターネット4を介してこの配信中チャンネルページを要求した端末装置3へ送信する(ステップS203)。
一方、コンテンツ配信サーバ1から配信中チャンネルページを受信した端末装置3のブラウザは、ブラウザ画面に配信中チャンネルページを表示する。
このようにブラウザ画面に表示した配信中チャンネルページ(配信チャンネル1)の例を図13に示す。
図13には、配信チャンネル1がコンテンツ配信中であることが表示され、又配信チャンネル条件として“落ち着いたクラシック”(配信条件)、“10曲”(配信コンテンツ数)、“3曲面配信中”、”公開“(公開/非公開)が表示される。
さらに、一つ前に配信されたコンテンツ名、現在配信中のコンテンツ名及び次に配信するコンテンツ名が表示される。なお、これらの情報は、上述のように配信チャンネルの配信チャンネルメモリ領域に記憶された情報に基づくものである。
また、この配信中チャンネルページには、リクエストボタンと戻るボタンが設けられている。そして、端末装置3のユーザがブラウザ画面上でこれらのボタンを選択すると、その情報がコンテンツ配信サーバ1に送られ、それに応じた処理が行われる。
例えば、戻るボタンが選択され、その旨の情報がコンテンツ配信サーバ1で受信される(ステップS204:Y)と、制御部11は、ステップS104へその処理を移行させ、トップページを生成して、その端末装置3へ送信する。また、リクエストボタンが選択され、その旨の情報がコンテンツ配信サーバ1で受信される(ステップS205:Y)と、制御部11は、リクエストページ処理(ステップS500)へその処理を移行する。
一方、配信中チャンネルページには、コンテンツ配信サーバ1の配信チャンネルにコンテンツデータの配信を要求する命令が記述されており、端末装置3のブラウザは、このページの記述に従って、コンテンツ配信サーバ1の配信チャンネル(配信チャンネルページが対象とする配信チャンネル)に対して、コンテンツデータの配信を要求する。
コンテンツ配信サーバ1の制御部11がこの要求を受信する(ステップS206)と、コンテンツ選択・配信処理(ステップS600)へ移行する。
(リクエスト処理)
リクエストページ処理(ステップS500)に移行すると、コンテンツ配信サーバ1の制御部11は、要求対象の配信チャンネルに対応する記憶部の配信チャンネルメモリ領域から、配信条件を取り出して、リクエストページを生成し(ステップS501)、要求元の端末装置3へ生成したリクエストページを送信する(ステップS502)。
一方、コンテンツ配信サーバ1からリクエストページを受信した端末装置3のブラウザは、ブラウザ画面にこの受信したリクエストページを表示する。
このようにブラウザ画面に表示したリクエストチャンネルページ例を図16に示す。
図16には、配信チャンネル1の配信条件と共に、コンテンツリクエストを入力する入力ボックスと、コンテンツ検索のためのキーワード検索ボックス及びアーティスト名検索ボックスが示されている。
また、このリクエストチャンネルページには、リクエスト送信ボタン、リクエスト検索ボタン及び戻るボタンが設けられている。
そして、端末装置3のユーザがブラウザ画面上でこれらのボタンを選択すると、その情報がコンテンツ配信サーバに送られ、それに応じた処理が行われる。
例えば、リクエスト送信ボタンが選択されると、端末装置3からその選択情報と共に、リクエスト入力ボックスに入力されたコンテンツリクエストが、コンテンツ配信サーバ1へ送信される。
そして、制御部11は端末装置3からのこのリクエスト要求を受信する(ステップS503:Y)と、制御部11によるリクエスト受信処理が行われる(ステップS800)。
また、戻るボタンが選択され、その旨の情報がコンテンツ配信サーバで受信される(ステップS504:Y)と、制御部11は、リクエスト処理を終了する。
また、ブラウザ画面上で検索ボタンが選択され、その旨の情報がコンテンツサーバで受信される(ステップS505:Y)と、制御部11は、要求された検索内容のコンテンツがあるか否かを、コンテンツデータベース2に問い合わせる(ステップS506)。
そして、その問い合わせに対するコンテンツデータベース2からの応答情報を受信して、端末装置3へその情報を送信する(ステップS507)。
ステップS800でのリクエスト受信処理が開始されると、制御部11は、このリクエスト要求と共に送信されるコンテンツリクエストの情報を、リクエスト対象の配信チャンネルに対応する記憶部12のコンテンツリクエストメモリ領域に記憶する(ステップS801)。
その後、制御部11は、リクエスト受付を完了した旨の情報が表示されたリクエスト受付完了Webページを、コンテンツリクエストを送信した端末装置3へ送信する(ステップS802)。このリクエスト受付完了Webページを受信した端末装置3のブラウザは、ブラウザ画面のこのページを表示する。
(コンテンツ選択配信処理)
ステップS206にて端末装置3からのコンテンツの要求を受信して、コンテンツ選択・配信処理に移行すると、制御部11は、まず対象の配信チャンネルに対する記憶部12の配信チャンネルメモリ領域を参照して、配信条件を満たすと判定し、かつまだ配信していない配信待ちのコンテンツデータが2以上あるか否かを判定する(ステップS601)。
この判定の結果、配信待ちコンテンツデータが所定数(2個)以上ないと判定する(ステップS601:N)と、後述するコンテンツ選択処理(ステップS700)に移行する。なお、この所定数は、配信条件を満たすコンテンツを選択するために必要な最大時間に応じてこの所定数を設定する。
ステップS601で配信待ちコンテンツデータが2以上あると判定した場合(ステップS601:Y)、又はS700のコンテンツ選択処理により配信待ちコンテンツデータを追加した場合には、制御部11により記憶部12の配信待ちコンテンツデータ領域に記憶されたコンテンツ情報から配信すべきコンテンツデータを選択する。
そして、制御部11で選択された送信待ちコンテンツデータは、通信部15を介して配信要求を行った端末装置3へ配信する(ステップS602)。
その後、制御部11は、対象の配信チャンネルに対する記憶部12の配信チャンネルメモリ領域から配信チャンネル条件(配信終了時間、配信済みコンテンツ数、配信コンテンツ数等)を取り出して、その配信チャンネル条件でのコンテンツデータの配信を終了するか否かを判定する(ステップS603)。
例えば、制御部11は、配信中のコンテンツデータの配信が終了するまでに配信終了時間が来ると判定すると、その配信終了時間が到達する所定時間前からコンテンツデータの送信をフェードアウト(コンテンツデータが音楽情報であれば、音声レベルを段階的に0になるまで下げていき、映像情報であれば、輝度レベルを段階的に0になるまで下げていく)して配信を終了する(ステップS604)。
配信終了時間が設定されていない場合や、配信コンテンツ数と配信済みコンテンツ数とが同じになった場合には、配信中のコンテンツデータの配信が終了したときに配信時間到達と判定する。なお、配信時間に到達しない場合には、コンテンツ選択配信処理を終了する。
(コンテンツ選択処理)
ステップS700のコンテンツ選択処理が開始されると、制御部11は、対象の配信チャンネルに対応する記憶部の配信チャンネルメモリ領域から、分類方法と配信条件とを取り出す(ステップS701)。
また、制御部11は、受信されているコンテンツリクエストのうち、まだ判定が終わっていないコンテンツリクエストがコンテンツリクエストメモリ領域に存在するか否かを判定する(ステップS702)。
そして、そのようなコンテンツリクエストがコンテンツリクエストメモリ領域に存在すると判定する(ステップS702:Y)と、そのコンテンツリクエストの中から、ランダム(任意)に一つを取り出すと共に、コンテンツデータベース2からこのコンテンツリクエストに対応するコンテンツデータを取り出す(ステップS703)。
一方、ステップS702でそのようなコンテンツリクエストがコンテンツリクエストメモリ領域に存在しないと判定する(ステップS702:N)と、コンテンツデータベース2から任意のコンテンツデータを取り出す(ステップS704)。
次に、制御部11は、ステップS703又はS704で取り出したコンテンツデータを、取り出した分類方法によって分類すると共に、その分類した結果と取り出した配信条件とを比較する(ステップS705)。
そして、この比較の結果、コンテンツデータの分類結果が配信条件を満たすと判定する(ステップS706:Y)と、そのコンテンツデータを送信待ちコンテンツとして、記憶部の配信待ちコンテンツメモリ領域に加える(ステップS708)。
例えば、コンテンツデータが「G線上のアリア」であり、コンテンツの分類方法として「コンテンツの物理的特徴」が選択されているとすると、このコンテンツデータは、落ち着いた楽曲と分類される。
そして、配信条件が「落ち着いた楽曲」と設定されている場合には、コンテンツデータの分類結果が配信条件を満たすと判定される。
一方、制御部11が、コンテンツデータの分類結果が配信条件を満たさないと判定する(ステップS706:N)と、他の配信チャンネルの配信条件を満たすか否かを判定する処理を行う(ステップS707)。
具体的には、まず制御部11は、配信条件が設定されている他の配信チャンネルがあるか否かを判定する(ステップS709)。
そして、配信条件が設定されている他の配信チャンネルがないと判定する(ステップS709:N)と、制御部11は、リクエスト受付不可ページを生成して、コンテンツリクエストを行った端末装置3へ生成したページを送信する(ステッS710)。
このようにして生成され送信されたチャンネルページの例を図20に示す。図20は、ステップS710で送信されるリクエスト受付不可ページの例を示すものであり、配信チャンネル1へリクエストは受付られなかった旨を端末装置3に通知している。
一方、ステップS709にて、配信条件が設定されている他の配信チャンネルがあると判定する(ステップS709:N)と、その配信チャンネルに対応する配信チャンネルメモリ領域から配信条件を取り出し(ステップS711)、コンテンツリクエストに対応するコンテンツデータをステップS711で取り出した配信条件と比較、すなわちそのコンテンツデータが配信条件を満たすか否かを判定する(ステップS712)。
ステップS712の比較の結果、制御部11が配信条件を満たすと判定する(ステップS713:Y)と、その配信チャンネルがコンテンツ配信中の配信チャンネルか否かを判定し(ステップS714)、制御部11はその判定の結果に応じたチャンネルページを生成し、端末装置3へ送信する(ステップS715、S716)。
このようにして生成され送信されたチャンネルページの例を図21に示す。図21は、ステップS715で送信される配信待機決定チャンネルページの例を示すものであり、配信チャンネル1へリクエストしたコンテンツが配信チャンネル5の配信条件を満たし、そのコンテンツの配信を配信チャンネル5で行う旨を端末装置3へ通知するものである。そして、配信開始時間になると配信中チャンネルページへ移行して、コンテンツの配信が開始される。
ステップS706でコンテンツデータの分類結果が配信条件を満たさないと判定する(ステップS706:N)と、その配信条件を満たすコンテンツデータを発見するまで、ステップS702〜S707の動作を繰り返し行う。
なお、ステップS703で、制御部11は、受信されたコンテンツリクエストのうち判定が終わっていないコンテンツリクエストをランダム(任意)に一つを取り出すとしたが、コンテンツリクエストメモリ領域に記憶された順に取り出すコンテンツリクエストを選択するようにしてもよい。
また、ステップS704で、制御部11は、コンテンツデータベース2から任意のコンテンツデータを取り出すこととしたが、すでにその配信チャンネルで配信したコンテンツデータを再度配信するようにすることもできる。また、制御部11は、その配信チャンネルを空き配信チャンネルへ移行させるようにしてもよく、単にコンテンツリクエストがあるまで待つようにしてもよい。
また、制御部11は、ステップS706でコンテンツデータの分類結果が配信条件を満たさないと判定すると、空き配信チャンネルでそのコンテンツデータのみ配信するようにしてもよい。
また、ステップS706でコンテンツデータの分類結果が配信条件を満たさないと判定する(ステップS706:N)と、空き配信チャンネルがあるか否かを判定し、空き配信チャンネルがあるとそのコンテンツデータが満たす配信条件を判定して、空き配信チャンネルにその配信条件を設定するようにしてもよく、特にリクエストが多いが配信できないものに対してのみこの処理を行うようにしてもよい。また、配信条件がない配信チャンネルを設け、ステップS706でコンテンツデータの分類結果が配信条件を満たさないと判定する(ステップS706:N)と、その配信チャンネルで配信するようにしてもよい。
なお、コンテンツデータベース2に、コンテンツリクエストに対応するコンテンツデータがない場合、制御部11は、コンテンツデータがデータベースに格納されるまで定期的にデータベースに問い合わせをし、コンテンツデータベース2にそのコンテンツデータが格納されたときにその旨をリクエスト元の端末装置3へ通知すると共に、そのコンテンツデータが配信条件を満たす配信チャンネルで配信するようにすることもできる。
(配信決定待機チャンネル処理)
次に、図22、図23を参照して、配信決定待機チャンネル処理について具体的に説明する。
図22は、本実施形態におけるコンテンツ配信サーバの配信決定待機チャンネル処理フローチャートを示す図、図23は本実施形態における配信決定チャンネルページを示す図である。
配信決定待機チャンネル処理(図9のステップS300)が開始されると、コンテンツ配信サーバ1の制御部11は、要求対象の配信チャンネルに対応する配信チャンネルメモリ領域から、配信条件を含む配信チャンネル条件を取り出して、配信決定待機チャンネルのチャンネルページ(以下、「配信決定チャンネルページ」とする。)を生成する。そして、生成した配信決定チャンネルページを、インターネット4を介してこの配信決定チャンネルページを要求した端末装置3へ送信する(ステップS301)。
一方、コンテンツ配信サーバ1から配信決定チャンネルページを受信した端末装置3のブラウザは、ブラウザ画面に配信決定チャンネルページを表示する。
このようにブラウザ画面に表示した配信決定チャンネルページ(配信チャンネル5)の例を図23に示す。
図23には、配信チャンネル5が配信待機中であることが表示され、又配信チャンネル条件として“落ち着いたクラシック”(配信条件)、“10曲”(配信コンテンツ数)、“PM3:00〜4:00”(配信時間)、”公開“(公開/非公開)が表示される。さらに、コンテンツリクエスト受付け中である旨が表示される。なお、これらの情報は、上述のように配信決定待機チャンネルの配信チャンネルメモリ領域に記憶された情報に基づくものである。
また、この配信決定チャンネルページには、リクエストボタンと戻るボタンが設けられている。そして、端末装置3のユーザがブラウザ画面上でこれらのボタンを選択すると、その情報がコンテンツ配信サーバに送られ、それに応じた処理が行われる。
例えば、戻るボタンが選択され、その旨の情報がコンテンツ配信サーバ1で受信される(ステップS302:Y)と、制御部11は、S104へその処理を移行させ、トップページを生成して、その端末装置3へ送信する。
また、制御部11は、この配信決定チャンネルのクエストメモリ領域から、配信時間領域の情報を取り出して、この配信決定チャンネルの配信開始時間が到達したかどうかを判定する(ステップS303)。そして、制御部11は、配信時間が到達したと判定する(ステップS303:Y)と、配信中チャンネル処理へ移行する。
また、リクエストボタンが選択され、その旨の情報がコンテンツ配信サーバ1で受信される(ステップS304:Y)と、制御部11は、リクエストページ処理(ステップS500)へその処理を移行する。
(空き配信チャンネル処理)
次に、図24、図25を参照して、空き配信チャンネル処理について具体的に説明する。
図24は本実施形態におけるコンテンツ配信サーバ1の空き配信チャンネル処理フローチャートを示す図、図25は本実施形態における空き配信チャンネルページを示す図である。
空き配信チャンネル処理が開始されると、コンテンツ配信サーバ1の制御部11は、記憶部12に記憶された空き配信チャンネルのチャンネルページ(以下、「空き配信チャンネルページ」とする。)を取り出し、インターネット4を介してこの空き配信チャンネルページを要求した端末装置3へ送信する(ステップS401)。
一方、コンテンツ配信サーバ1から空き配信チャンネルページを受信した端末装置3のブラウザは、ブラウザ画面に空き配信チャンネルページを表示する。
このようにブラウザ画面に表示した空き配信チャンネルページ(配信チャンネル4)の例を図25に示す。
図25には、配信チャンネル4の配信チャンネル条件設定が表示されており、端末装置3のユーザは、この配信チャンネル条件(配信条件、配信局数、配信開始時間、配信終了時間、外部公開情報等)を設定することができる。配信条件として、配信条件1〜3を選択することが可能であり、配信条件1〜3はand条件となっている。
例えば、配信条件1はコンテンツの物理的特徴から分類するための条件を選択するために使用され、「落ち着いた」、「適度に動きのある」、「ビートの効いた」などの選択枝から選択することができるように、空き配信チャンネルページが構成されている。
また、配信条件2はコンテンツデータに関連するコンテンツ識別情報から分類するための条件を選択するために使用され、「クラシック」、「ポップス」、「ジャズ」などの選択を行うことができるように、空き配信チャンネルページが構成されている。
なお、配信条件1〜3に選択枝として存在しないものを選択する方法として、配信種別に自由欄が設けられており、端末装置3のユーザはこの欄に入力することによって、コンテンツデータに関連するデータから分類するための条件を選択することができる。また、リクエスト曲の選択も同時に行うことができる。
また、この空き配信チャンネルページには、設定ボタンと戻るボタンが設けられている。そして、端末装置3のユーザがブラウザ画面上でこれらのボタンを選択すると、その情報がコンテンツ配信サーバ1に送られ、それに応じた処理が行われる。
例えば、戻るボタンが選択され、その旨の情報がコンテンツ配信サーバ1で受信される(ステップS402:Y)と、制御部11は、ステップS104へその処理を移行させ、トップページを生成して、その端末装置3へ送信する。また設定ボタンが選択され、その旨の情報がコンテンツ配信サーバ1で受信される(ステップS403:Y)と、制御部11は、端末装置3から送信される配信チャンネル条件を記憶部12の配信チャンネルメモリ領域に設定する(ステップS404)。
そして、配信開始時間が設定されていない場合には、配信開始時間が到達したと判定して(ステップS405:Y)、配信中チャンネル処理に移行する。
一方、配信開始時間が設定されており、配信開始時間が到達していない場合には、配信決定チャンネル処理に移行する。
以上、説明したように、本実施形態1によれば、配信チャンネル毎にコンテンツ配信の種々の条件(例えば、配信条件や配信時間帯等)を予め設定し、その後、端末装置3のユーザからのコンテンツ配信のリクエストを随時募集しながら、端末装置3から送られてきたリクエストのコンテンツデータが配信条件のコンテンツ配信基準を満たすかどうかを判定して、条件を満たすコンテンツデータのみを配信するようにしているので、一つの配信チャンネルによるコンテンツ配信の中で、特徴が異なるコンテンツ(音楽や映像など)を配信することがなく、不快感を与えることがない。
また、配信条件は、端末装置3のユーザが設定することができるので、コンテンツ配信サーバ1の運営者が、配信チャンネルの各種条件を設定する手間が削減でき、配信サービスの運用の効率化を図ることができる。
そして、配信チャンネルの各種条件を満たすことができないリクエストが端末装置3から送信されてきた場合であっても、そのリクエストを満たす配信チャンネル条件が設定された配信チャンネルへリクエストの転送をすることができるため、端末装置3のユーザは誤った配信チャンネルにリクエストしたり、どの配信チャンネルに設定すればよいか不明なときであっても、そのリクエストにあった配信チャンネルでのコンテンツ配信の提供を受けることが可能となる。
また、一つのチャンネルに対して、複数の配信条件を設定しても良いし、複数の配信条件の選択順を設定しても良い。例えば、一つのコンテンツ毎に配信条件を変更するように設定し、所定時間内に、ゆっくりなコンテンツから徐々に盛り上がるコンテンツへと移っていっても良い。
また、配信されるべき複数のコンテンツが既に決定しており、コンテンツの配信順を設定するために上記配信条件を用いても良い。
また、配信条件に合うコンテンツを選択したら、コンテンツリスト記憶手段に記憶し、そのコンテンツ記憶手段に記憶されたコンテンツを繰り返し配信するようにしても良い。