JP2009296484A - コンテンツ配信システム、および配信サーバ、送信側端末、ならびに配信サーバプログラム、送信側端末プログラム - Google Patents

Abstract

【課題】ストリーミング型やダウンロード型等のサービス形態と、ライブコンテンツもしくは記録コンテンツといったコンテンツ形態とを組み合わせ、配信形態を適宜変更してコンテンツ配信を行うコンテンツ配信システムを提供する。
【解決手段】コンテンツを配信する配信サーバ１００と、配信の対象となるコンテンツを配信サーバ１００に送信する送信側端末１２０と、配信サーバ１００から配信されるコンテンツを受信して表示を行う受信側端末１３０とから構成されるコンテンツ配信システムであって、送信側端末１２０は、送信側ユーザの指示に基づいて配信の対象となるコンテンツを特定する情報およびコンテンツの配信条件を配信サーバ１００に対して指定し、配信サーバ１００は、送信側端末１２０から指定された配信条件と、受信側端末１３０からのアクセス態様とに基づいて、配信対象のコンテンツの配信形態を変更して受信側端末１３０へ配信する。
【選択図】図１

Description

本発明は、ネットワークを介したコンテンツ配信サービスにおける技術に関し、特に、個人放送局に適用可能なＩＰテレビを用いた放送局システムなどのコンテンツ配信システム、および配信サーバ、送信側端末、ならびに配信サーバプログラム、送信側端末プログラムに適用して有効な技術に関するものである。

近年、ＰＣ（パーソナルコンピュータ）や携帯端末等の端末性能の向上や、ネットワーク回線の大容量化、ハードディスクの大容量化等に伴い、映像や音楽、文字列や説明情報（メタデータ）などのデータからなるコンテンツを、サーバからクライアント端末にＩＰ（Internet Protocol）ネットワークを通じて配信し、端末で視聴を行うコンテンツ配信システムが構成されている。このようなコンテンツ配信システムを用いて、テレビ番組や映画などの映像コンテンツをネットワークを通じて配信するＩＰテレビ（ＩＰＴＶ）サービスが開発されている。

これらのＩＰＴＶサービスを用いることで、サービス事業者としての企業や団体が提供するコンテンツの配信が行われている。一方、この仕組みを個人利用にまで広げ、個人の紹介や、趣味、家庭でのイベントなどに基づいて制作したコンテンツを他人に公開し、自己表現や感動共有を行わせたいという要求が高まってきた。このように、個人コンテンツを共有するためのＩＰＴＶサービスは「個人放送局」とも言えるが、コンテンツの制作や、配信するためのデータ変換、ユーザの管理、課金、実際の配信など、様々な局面で専門的知識を要したり、作業や面倒な手続きも多いため、これをセンターシステムでサポートすることで個人向けＩＰＴＶサービスを提供するシステムが登場してきた。

例えば、インターネットを用いた個人向けＩＰＴＶシステムとして、ビデオ映像の共有を目的とした「ＹｏｕＴｕｂｅ（登録商標）」（URL：http://www.youtube.com）が広く知られている。ここでは、ウェブサイトに連動したサーバに、指定されたサイズまでの録画済の動画像ファイルを転送（アップロード）し、コンテンツ情報と共に投稿する。この動画像ファイルは、投稿した登録済会員が指定することで、不特定まで、もしくは、特定数の任意指定会員までのどちらかより公開範囲条件を選択することが可能である。

これにより、それぞれの公開範囲条件にしたがって、同じウェブサイトや別のウェブサイトからのＵＲＬによるリンクを用いて、ＶＯＤ（Video On Demand）としてコンテンツを視聴することができる。また、テキストによるコンテンツ情報からの動画像検索や、評価やコメント付けが可能である。このように、「ＹｏｕＴｕｂｅ」などでは、ウェブサイトに連動したサーバに個人コンテンツをアップロードし、視聴を行うユーザに対してそのコンテンツをストリーミング型で配信する、すなわち、記録コンテンツのストリーミング配信を行っている。

また、特開２００７−４３６９５号公報（特許文献１）には、「ワン―ストップでインターネットを通じて個人動画放送を提供すること」（段落［０００４］参照）を課題とし、その解決手段として「個人動画放送、チャンネル及びビデオオンデマンド情報を実時間で提供するウェブサーバーと、実時間放送及びビデオオンデマンド情報を端末の環境フォーマットに変換して提供するメディアサーバーと、実時間エンコーディングもしくは実時間で放送を選択して各種情報を伝送する個人用放送端末と、動画を撮影するための映像機器とを含む個人動画放送システム」（段落［０００５］参照）が記載されており、実時間放送およびビデオオンデマンド、すなわち、記録コンテンツに加えてライブコンテンツについてもストリーミング配信を行うことが開示されている。

また、個人動画放送サイト上で「自分のチャンネルに移動した後、ライブ放送を選択し、放送用プログラムの組込み有無を確認し、ビデオ／オーディオ・キャプチャー装置を自動に検索して選択し、放送基本情報を入力して放送装置を準備し、放送用固有ＵＲＬを生成してメディアサーバーに接続することで、実時間映像圧縮データ伝送によって放送を開始する」（段落［０００５］参照）というステップを経て、ライブによる個人動画放送を実現することが記載されている。
特開２００７−４３６９５号公報

しかしながら、「ＹｏｕＴｕｂｅ」や特許文献１の技術をはじめとして、従来のＩＰＴＶシステムを含むコンテンツ配信システムでは、ライブコンテンツに関して、そのコンテンツの配信時間帯以外での配信サービスは実施されていない。その理由は、ライブコンテンツは、正にその配信が行われる時間に受信側ユーザが見ることができない場合には、予めライブ配信を行うことを知る受信側ユーザが、一般的なビデオレコーダで行われている予約による録画を行い、受信側ユーザがビデオレコーダを操作可能なタイミングで時間をずらして視聴するという、受信側ユーザによるコンテンツ配信の認知と受信側端末でのサポートとを前提としていたためである。

すなわち、従来のコンテンツ配信システムにおいては、ライブとしての配信を希望する送信側ユーザがいても、受信側ユーザがその場にいない場合はコンテンツ共有は成立せず、また、受信側ユーザが予めライブ配信が行われることを知らない、もしくは、録画予約設定に失敗した場合には、これらユーザ間でのコンテンツ共有の実現は困難であった。さらに、送信側ユーザがライブコンテンツをいったん記録しておき、記録コンテンツとして再び別形態で配信をやり直すといった煩雑な作業があれば同様の配信が可能であるが、設備面や技術面で制約のある個人レベルでの放送局ではこのような再配信を行うには限界があった。なお、この場合でも、再配信の時間帯を受信側ユーザが失念したり、予約録画に失敗したりすると見逃してしまうことには変わりない。

そこで本発明の目的は、ＩＰＴＶを用いた放送局システムなどのコンテンツ配信システムにおいて、ストリーミング型やダウンロード型等のサービス形態と、ライブコンテンツもしくは記録コンテンツといったコンテンツ形態とを組み合わせ、配信形態を適宜変更してコンテンツ配信を行うコンテンツ配信システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるコンテンツ配信システムは、送信側ユーザの指定した配信条件と受信側端末からのアクセス態様とに基づいて配信形態を変更して、送信側端末から取得したコンテンツを受信側端末に配信する配信サーバと、送信側ユーザからの指定を受けてコンテンツの配信条件を配信サーバに対して指定し、また、コンテンツを配信サーバに対して送信する送信側端末と、配信サーバから配信されるコンテンツを受信して表示を行う受信側端末とから構成されることを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、コンテンツ配信システムにおいて、ストリーミング型やダウンロード型等のサービス形態と、ライブコンテンツもしくは記録コンテンツといったコンテンツ形態とを組み合わせ、送信側ユーザの意向に基づいて、受信側端末による配信サーバへのアクセス態様を考慮して、配信形態を適宜変更してコンテンツ配信を行うコンテンツ配信システムを提供することが可能となる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜概要＞
以下で説明する本発明の一実施の形態であるコンテンツ配信システムは、映像や音声や文字情報などのいくつかのメディアで構成される番組情報のようなコンテンツをInternet Protocolで配信する放送サービス（以下では「ＩＰＴＶサービス」と記載する）を想定しているが、特にこれに限定されるものではない。このＩＰＴＶサービスは、コンテンツのサービス形態から大別すると、「ストリーミング」、「ダウンロード」、および「プログレッシブダウンロード」の３つのサービス形態に分類される。

「ストリーミング」は、サーバからコンテンツデータをネットワーク経由でクライアントに逐次配信し、クライアントでは到着したデータから映像や音声等を逐次再生することでユーザに提示する。このため、十分に帯域の広いネットワークがある場合にはほぼリアルタイムにユーザがコンテンツを視聴可能であることが特徴である。

「ダウンロード」は、クライアントがサーバから予めコンテンツデータのすべてを取得して蓄積しておき、蓄積が完了した後に視聴再生を行う。このため、リアルタイムに視聴する必要がない場合、予めすべてのコンテンツデータの配信を完了して蓄積しておくことで、ユーザが所望するタイミングで何度でも視聴することが可能となり、十分に帯域の広いネットワークがない場合でもコンテンツ配信を受けられることが特徴である。

また、「プログレッシブダウンロード」は、これら２つの中間に位置し、コンテンツデータのすべての配信が完了する前に、クライアントに蓄積された分のコンテンツから逐次視聴を行う。これにより、コンテンツデータの蓄積完了を待つ必要がなくなるため、十分に帯域の広いネットワークがない場合でもコンテンツの視聴開始までの時間を短縮することができる。また、コンテンツデータの蓄積完了後であれば、ユーザが所望するタイミングで何度でも視聴できるというメリットが得られる。

一方で、コンテンツは、別の分類として、既に全体として完成された「記録コンテンツ」と、実時間で逐次行われている事象そのものである「ライブコンテンツ」の２つの形態に大別できる。従って、コンテンツの配信形態としては、上記３つのサービス形態と２つのコンテンツ形態による６通りの組み合わせが考えられる。

なお、「記録コンテンツのダウンロード」は歴史的に古くから行われており、「記録コンテンツ」のデータ、すなわちファイルとしてクライアントがすべてサーバから受信し、受信したファイルをユーザが任意のタイミングで再生することで実現されている。また、「記録コンテンツのプログレッシブダウンロード」についても、ファイルの受信の途中で既に受信済みのデータを用いて再生を行うことで実現できる。また、「記録コンテンツのストリーミング」については、前述した通り「ＹｏｕＴｕｂｅ」などのサービスにおいて現在では一般的に行われている。

ＩＰＴＶサービスを含むコンテンツ配信サービスにおいては、ユーザがコンテンツ配信サービスを受けたときの対価の支払いとしてサービス事業者による利用料課金が行われることが多い。このとき、ユーザは正規利用者として予め登録されており、ユーザの識別子（ＩＤ）をキーとして、パスワード（パスコードもしくは指紋等の生体情報等でもよい）や、本名および住所をはじめとする各種情報が管理される。その上で、有料となるコンテンツの配信を受けて蓄積もしくは視聴した際の課金情報を記録可能であり、別途指定される支払い方法により利用料の納付が可能であることが確認される。

そして、ユーザがコンテンツ配信サービスを利用する際には、これら登録情報内のＩＤとパスワードによる管理情報との照合によってサービスを利用可能化する処理、すなわち、ユーザ認証を受ける必要がある。このユーザ認証された正規利用者には、配信を受けるコンテンツの選択や検索、その他の情報配信等のサービスを選択するための、いわゆる「ポータル」と呼ばれる、サービス選択のための画面が提供されることが多い。

さらに、ユーザが用いる端末装置がサービス事業者が指定する装置であるか、もしくは、端末装置内で動作するコンテンツ配信サービスを受けるプログラムが指定のプログラムであるかを、コンテンツ配信サービスに先んじて通信により確認する、すなわち、機器認証を行うことも多い。これにより、無断でのコピーや移動、改変などの著作権法等の法令に違反する行為や、コンテンツの不正利用を防止することができる。

このとき、コンテンツデータを予め共通鍵暗号方式で暗号化しておき、認証された正規利用者および／または認証された正規機器上で復号化できるよう、暗号化されたコンテンツを復号化するための鍵を別途授受して、端末上にコンテンツに結び付けて保持することがある。また、公開鍵暗号化方式を用いて公開鍵と秘密鍵を端末側もしくはサービス事業者側で用意し、秘密鍵を利用者登録時等に端末に送信して、サービス事業者と端末とでそれぞれ暗号化、復号化に用いてもよい。一般にこれら復号化のための鍵は、コンテンツ再生の期限や回数、および再生可能なユーザや機器等の再生条件とともに記録される。以下、暗号化のための鍵を暗号鍵、復号化のための鍵を復号鍵と呼ぶ。

このように、ユーザ認証と機器認証、および復号鍵の関連付けにより、サービス事業者は、コンテンツやサービスの提供者の代行として、コンテンツ配信サービス等をユーザに安全に提供し、確実な課金を行うことができる。以降、ユーザは所望するコンテンツの配信を受け、正しくコンテンツ再生等のサービスを受けることとなる。さらに、これらに基づいて、ユーザは、再生できる権利に対応させて結び付けたコンテンツを端末に保持することが可能となる場合もある。

＜実施の形態＞
以下、本発明の一実施の形態であるコンテンツの配信を行うためのコンテンツ配信システムについて図面を用いて説明する。図１は、本実施の形態であるコンテンツ配信システムの基本的なシステム構成例を表した図である。

本実施の形態のコンテンツ配信システムは、コンテンツを配信するサーバが、送信側端末よりコンテンツ情報およびコンテンツの配信条件情報を取得し、これらを用いることで送信側端末からのコンテンツデータの取得、および、受信側端末から当該コンテンツの配信の要求を受けた際の状況を判定する処理を行う。これにより、ライブ配信時のコンテンツデータの転送、もしくは、サーバ上での蓄積、再生開始時刻等の判断を行うものである。

コンテンツ配信システムは、ネットワーク１１０を中心として、配信サーバ１００、クライアント端末（送信側端末１２０、受信側端末１３０）が接続されている。なお、本実施の形態では、配信サーバ１００およびクライアント端末は、それぞれ個別の装置として構成されているが、これらのうちの一部または全部が同一の装置で構成されていてもよい。また、ネットワーク１１０については、インターネットをはじめ、例えば、家庭内のＬＡＮ（ローカルエリアネットワーク）や、同一の装置内部にあるデータバス等であってもよい。

配信サーバ１００は、演算部１０３を中心として、ユーザ（送信側ユーザ、受信側ユーザ）もしくはクライアント端末を管理するユーザ管理部１０１、コンテンツを管理するコンテンツ管理部１０２、ネットワーク１１０を経由して他の機器、特にクライアント端末と通信を行うための通信部１０４、およびコンテンツの配信状況を管理する配信管理部１０５から構成される。

ユーザ管理部１０１では、ユーザ認証を行うための認証情報１０６と、ユーザによるコンテンツの視聴に対する課金状況を記録する課金情報１０７とを管理している。図２は、認証情報１０６のデータ構造およびデータの例を示す図である。認証情報１０６には、ユーザＩＤ（管理番号）と、予め定めたユーザに一意の識別子（ユーザ名）およびパスワード、ユーザの氏名、住所および連絡先などが格納されている。図２の例ではユーザの情報を管理しているが、ユーザが使用するクライアント端末の情報を管理していてもよい。

図３は、課金情報１０７のデータ構造およびデータの例を示す図である。課金情報１０７には、前述のユーザＩＤに関連付けて、支払い方法および支払い名義人、利用したコンテンツのＩＤ、契約形態および発生日、コンテンツ配信サービスもしくは配信されたコンテンツを再生視聴したことにより発生するユーザへの課金額などが格納されている。なお、ユーザ管理部１０１が管理する認証情報１０６、課金情報１０７の各種情報は、ハードディスク等の記録メディアを用いて記録され、ユーザ管理部１０１が管理するメモリ領域上に読み込まれてもよい。

コンテンツ管理部１０２では、コンテンツデータおよび付随する情報から構成するコンテンツ情報１０８を管理する。図４は、コンテンツ情報１０８のデータ構造およびデータの例を示す図である。コンテンツ情報１０８には、コンテンツのＩＤ（管理番号）と、コンテンツの所有者であるユーザのＩＤ（オーナＵＩＤ）、コンテンツのフォーマットや内容等の説明情報、コンテンツデータ自体、およびコンテンツのサイズや、コンテンツ配信サービスもしくは配信されたコンテンツを再生視聴した場合に課金する料金などが格納されている。

また、コンテンツの完全性を保証するために用いるチェックサム情報や、インターネット等の通信経路にて悪意の第三者からコンテンツを保護するために、ＲＳＡ暗号化技術などを用いて暗号化されたコンテンツを復号化して再生するための鍵情報が格納されていてもよい。なお、コンテンツ管理部１０２が管理するコンテンツ情報１０８の各種情報は、ハードディスク等の記録メディアを用いて記録され、コンテンツ管理部１０２が管理するメモリ領域上に読み込まれてもよい。また、コンテンツ情報１０８の各種情報を、コンテンツデータ自体と、コンテンツデータを説明するデータ（メタデータ）としていくつかに分けて管理してもよい。

次にクライアント端末について説明する。図１に示すように、本実施の形態におけるクライアント端末は、送信側端末１２０と、受信側端末１３０の２種類あるものとして説明する。すなわち、送信側端末１２０は、配信サーバ１００を経由して自らのコンテンツの配信を希望するユーザが操作する端末である。また、受信側端末１３０は、配信サーバ１００を経由して送信側端末１２０のユーザの意向に従って配信されてくるコンテンツを受信し、視聴することを希望するユーザが操作する端末である。

本実施の形態では、送信側端末１２０と受信側端末１３０のブロック構成は同じであるものとしているが、後述するそれぞれのクライアント端末における処理ステップを行うことができれば必ずしも同じ構成でなくてもよい。また、それぞれのクライアント端末がＰＣ等の汎用機器やＴＶ等の特定機器として構成される場合も、後述する処理ステップを行うことができれば、ブロック構成は図１に示す構成に限定されない。

送信側端末１２０は、演算部１２３を中心として、コンテンツを管理するコンテンツ管理部１２１、ネットワーク１１０を用いて他の機器、特に配信サーバ１００と通信を行うための通信部１２２、ユーザに対して表示を行う表示部１２４、ユーザからの指示を受け付ける入力部１２５、および送信側端末１２０を識別するために予め設定された識別子１２８から構成される。また、受信側端末１３０も同様に、演算部１３３、コンテンツ管理部１３１、通信部１３２、表示部１３４、入力部１３５、識別子１３８から構成される。なお、それぞれの表示部１２４、１３４は、必ずしもディスプレイ等自体である必要はなく、当該クライアント端末と別体のディスプレイやＴＶ等に表示するデータを出力する出力部であってもよい。

それぞれのクライアント端末におけるコンテンツ管理部１２１、１３１では、コンテンツ情報１２６、１３６をそれぞれ管理する。このコンテンツ情報１２６、１３６は、図４に示す配信サーバ１００でのコンテンツ情報１０８と同様の形式であるものとし、送信側端末１２０が有するコンテンツに関する各種情報、受信側端末１３０が既に配信を受けたコンテンツに関する各種情報がそれぞれ管理される。また、それぞれのクライアント端末における設定情報１２７、１３７では、コンテンツ配信システムに関するそれぞれのクライアント端末でのオプション等の各種設定情報を管理する。

次に、本実施の形態のコンテンツ配信システムにおける処理フローについて説明する。図５は、本実施の形態のコンテンツ配信システムにおける処理フローのうち、送信側端末１２０で行われる送信前処理の流れの例を示すフロー図である。まず、ユーザは送信側端末１２０を用いて配信サーバ１００にアクセスし、ログイン、すなわちユーザ認証を行う（ステップＳ５０１、Ｓ５１１）。

図６は、ユーザ認証の際のログイン画面の例を示す図である。ユーザは送信側端末１２０の表示部１２４に表示される図６の画面、および入力部１２５でのユーザによる入力からなるユーザインタフェースを用いて、ユーザＩＤ（ユーザ名）と、パスワード等の情報を入力する。送信側端末１２０の演算部１２３は、入力された情報を予め定められた形式で配信サーバ１００に送信する。配信サーバ１００では、ユーザ管理部１０１にて管理される認証情報１０６を用いて、受信したユーザ名とパスワードが正しいか否かを検証する。正しい場合にはこのユーザが正規にログインしたものとして認証する。

ここでのユーザインタフェースにおいて、入力部１２５は、例えば、リモコンやマウス、キーボードなどの装置、あるいは表示部１２４上に配置されるタッチパネルなどであってもよい。これらを用いたユーザの操作に従い、表示部１２４に表示される画面に配置されるボタン図形の形状や色等を変化させたり、入力に従ってテキストを追加表示したり削除したりすることで、ボタン図形の選択や決定、あるいは文字入力させるように連携して動作することが望ましい。また、文字入力の際には、例えば、表示画面上に文字一覧表および操作のボタンを列挙し、ユーザにボタンを選択・決定させることで文字入力を可能にしてもよい。これらは、以降の画面操作の説明でも同様であり、特にボタン図形を選択し決定する際の動作を「押下」と表記することとする。

なお、ログイン後、送信側端末１２０においてユーザが操作をしない状態で一定時間を超えた場合には、再度ステップＳ５０１、Ｓ５１１のログイン処理を行ってもよい。また、本実施の形態では、ユーザ名とパスワードにて認証するものとしているが、ユーザの指静脈や指紋、虹彩、顔等の画像や声紋等の音響を用いた生体認証や、その他の認証手段であってもよく、その際には、配信サーバ１００は、これらのユーザ情報を検証するための情報を認証情報１０６にて管理し、ユーザ認証を行う。

配信サーバ１００において正しくユーザ認証が行われた場合は、送信側端末１２０ではサービスを選択するメインメニューに画面が遷移する。図７は、メインメニューの例を示す図である。図７の例では、ユーザが選択可能な、「ＶＯＤ視聴」「個人放送視聴」「個人放送配信」の各種サービスを示すボタンが表示されている。

図７に示すメインメニューから、送信側端末１２０のユーザが「個人放送配信」のボタンを選択して押下することで、送信側端末１２０は、コンテンツの配信要求を配信サーバ１００に通知する（ステップＳ５０２）。配信サーバ１００は、配信要求に対する応答として、配信要求許可の応答を送信側端末１２０に送信する（ステップＳ５１２）。

配信要求許可の応答を受信すると、送信側端末１２０では、個人放送の配信条件を設定する画面に遷移する。図８は、個人放送配信における配信条件設定の主画面の例を示す図である。図８に示す画面によって、送信側端末１２０のユーザは、配信するコンテンツの内容、および個人放送として配信する際の配信条件を設定し（ステップＳ５０３）、送信側端末１２０は、設定された配信条件を配信サーバ１００へ通知する。

図９は、配信条件のうちのコンテンツの形態等の情報を設定する画面の例を示す図である。図９に示す画面は、図８に示す画面において、送信側端末１２０のユーザがコンテンツ欄の右側にある「設定変更」ボタンを押下した場合に表示される画面である。図９の例では、コンテンツ形態として「アップロード」が選択され、配信サーバもしくは送信側端末１２０で行うコンテンツを配信可能なフォーマットに変換する処理が「自動」で行われるように選択されている。

また、ライブコンテンツを配信サーバ１２０にアップロードするために送信側端末１２０と連携するビデオカメラ等の外部デバイスの検出を「自動」で行うように選択されており、さらにそのデバイスとして「○○家のＢＤカム」が選択されている例を表している。なお、この外部デバイスの検出に関しては、例えば、一般的なＵＰｎＰ（Universal Plug and Play）等のネットワーク機器間連携のための規格により、ネットワークに接続しているデバイスの自動検索を用いることなどが考えられる。ここでは、外部デバイスとして選択された「○○家のＢＤカム」からの映像を送信側端末１２０が取得可能であるものとして、以下説明する。

図９に示す画面では、さらにユーザがこれから配信を行うコンテンツの説明を入力することができる。例えば、コンテンツ説明欄の「変更」ボタンを押下することで、コンテンツのタイトルや概要を設定してもよい。以上のような設定項目を設定したうえで、画面右下の「設定」ボタンを押下することで、図８に示す配信条件設定の主画面に戻る。

図１０は、配信するコンテンツの配信条件を設定する画面の例を示す図である。図１０に示す画面は、図８に示す画面において、送信側端末１２０のユーザが配信条件欄の右側にある「設定変更」ボタンを押下した場合に表示される画面である。この画面では、受信側端末１３０への配信をどのようにして行いたいかという、送信側ユーザの意向を設定する。

図１０の例では、配信形態として「ライブ」、すなわち、配信サーバ１００からの配信時刻と受信側ユーザが視聴する時刻とがほぼ同一である配信が選択されている。さらに、当該コンテンツについて再配信を「しない」、すなわち、一度のライブ配信のみとし、また、受信側端末１３０がライブ配信の途中で参加してきて配信を受けはじめた場合の対応として「ライブのみ」、すなわち途中（本実施の形態の場合は参加時点）からの視聴とするように選択されていることを表している。

さらに、配信を行う時間帯として特定の時間帯を指定「する」ように選択されており、その時間帯として、「２／２９ １４：００〜 ９０分」の時間帯が指定されている。この時間帯指定は、例えば、ライブ欄の「変更」ボタンを押下することにより変更可能であり、直接時間帯を入力する他に、例えば、カレンダや時計などの表示によるユーザインタフェースを用いて容易に設定できるようにしてもよい。

また、コンテンツの配信を行う相手（ユーザ）を指定「する」ように選択されており、そのユーザとして、「祖父母」および「弟」が指定されている。この場合、受信側端末１３０において「祖父母」もしくは「弟」が配信サーバ１００にログインしてアクセスした場合にのみコンテンツの配信が行われる。

なお、この「祖父母」および「弟」の情報については、予め送信側ユーザが何らかの方法で「祖父母」および「弟」の本来のユーザＩＤもしくは使用している受信側端末１３０の識別子１３８の内容を知った上で、これらの情報に対するニックネームとして登録しておいた情報を用いたり、配信サーバ１００の認証情報１０６の中からニックネームが登録されているユーザとそのＩＤを検索することで、「祖父母」もしくは「弟」を特定したりしてもよい。これらの情報についても、ユーザ欄の「変更」ボタンを押下することで変更することができる。

次に、図５において、ステップＳ５０３で送信側ユーザが設定したコンテンツの配信条件を配信サーバ１００に送信し（ステップＳ５０４）、配信サーバ１００では、受信した配信条件の設定を評価する（ステップＳ５１３）。

図１１は、送信側端末１２０から配信サーバ１００に送信する、配信条件設定情報のデータ構造およびデータの例を示す図であり、図１２は、配信サーバ１００における配信条件評価処理の流れの例を示すフロー図である。ここで、図１１に示す配信条件設定情報には、前述したステップＳ５０３において送信側端末１２０にて個人放送配信を行うユーザが設定した図８に示す内容が含まれており、ユーザＩＤや、配信形態である「ライブ」、再配信なしを示す「Ｎ」などの値が設定されていることを表している。

図１１に示す配信条件設定情報を受信した配信サーバ１００は、図１２に示す処理フローに従って配信条件設定情報を取り込んで評価し、配信情報１０９として格納する。まず、アップロード配信であるか否か、すなわち、配信サーバ１００に既に存在するコンテンツの配信であるのか、コンテンツを新規に配信サーバ１００にアップロードしての配信であるのかを確認する（ステップＳ１２０１）。アップロード配信である場合には、配信情報１０９の該当のレコードの「アップロードフラグ」をＴＲＵＥにし（ステップＳ１２０２）、そうでない場合は、「アップロードフラグ」をＦＡＬＳＥにする（ステップＳ１２１１）。

次に、ライブ配信であるか否かを確認し（ステップＳ１２０３）、ライブ配信である場合には、配信情報１０９の該当のレコードの「ライブフラグ」をＴＲＵＥにし（ステップＳ１２０４）、そうでない場合は、「ライブフラグ」をＦＡＬＳＥにする（ステップＳ１２２１）。

ライブ配信である場合には、さらに、再配信もしくは途中参加時に最初から再生することを許可するか否かを確認する（ステップＳ１２０５）。再配信もしくは途中参加時に最初から再生することを許可する場合、もしくはライブ配信ではない場合は、コンテンツを蓄積する手段を準備し（ステップＳ１２２２）、配信情報１０９の該当のレコードの「蓄積フラグ」をＴＲＵＥにする（ステップＳ１２２３）。再配信および途中参加時に最初から再生することを許可しない場合は、「蓄積フラグ」をＦＡＬＳＥにする（ステップＳ１２０６）。

次に、配信時間帯が指定されているか否かを確認し（ステップＳ１２０７）、指定されている場合は、これらの時間帯を配信情報１０９の該当のレコードに記録して予約する（ステップＳ１２０８）。次に、受信側端末１３０のユーザ指定がされているか否かを確認する（ステップＳ１２３１）。ユーザ指定がされている場合は、これらのユーザＩＤを配信情報１０９の該当のレコードに記録し（ステップＳ１２４１）、「ユーザ指定フラグ」をＴＲＵＥにする（ステップＳ１２４２）。ユーザ指定がされていない場合は、「ユーザ指定フラグ」をＦＡＬＳＥにする（ステップＳ１２３２）。

以上の処理を行うことによって、配信サーバ１００の配信管理部１０５を通じて配信情報１０９に配信条件を設定する。図１３は、図１２に示す配信条件評価処理フローによって設定された配信情報１０９のデータ構造とデータの例を示す図である。例えば、図１１に示す配信条件設定情報の例の場合は、図１３に示す配信情報１０９のＮｏ．＝１のレコードのように保持される。

＜配信処理の第１の例＞
図１４は、本実施の形態のコンテンツ配信システムにおける配信処理の第１の例を示すフロー図である。図１４のフローでは、図１３に示す配信情報１０９の例のうちのＮｏ．＝１のレコードが示す、「アップロードフラグ」がＴＲＵＥ、「蓄積フラグ」がＦＡＬＳＥ（すなわち、再配信「なし」、配信形態「ライブ」）、途中参加時の処理が「ライブのみ」である配信条件に基づく配信処理、すなわち、「ライブコンテンツのストリーミング」配信に関して説明する。

なお、すでに送信側端末１２０および配信サーバ１００では、図５に示すフローに従ってログインから配信条件評価処理までは完了しているものとし、かつ、配信条件に設定された配信時間帯の前であるものとする。また、配信サーバ１００内の処理は、送信側端末１２０、および受信側端末１３０のそれぞれに対して非同期で処理を行うことが可能であるものとする。

まず、配信サーバ１００の送信側端末１２０に対する処理では、アップロード配信であるか否かを確認する（ステップＳ１４１１）。ここでは、送信側端末１２０からコンテンツをアップロードしてライブ配信する場合の例であるため、次に、送信側端末１２０との間でコンテンツアップロードの準備を行う（ステップＳ１４０１、Ｓ１４１２）。

具体的には、送信側端末１２０では、カメラ等の外部デバイスとＵＰｎＰの機能などを用いて接続し、データのやり取りが可能な状態とする。また、配信サーバ１００との間でデータのやり取りを行う接続、例えば、一般的なＲＴＰ（Realtime Transfer Protocol）やＨＴＴＰ（Hyper Text Transfer Protocol）等のデータ転送プロトコルを用いるアップロード用通信環境を確立する。また、配信サーバ１００側では、送信側端末１２０から受信したデータのバッファリング等の準備を行う。

次に、ライブ配信であるか否かを確認する（ステップＳ１４１３）。ここではライブ配信の場合の例であるため、その後、配信時間帯が指定されている場合には、配信開始時刻まで待つ（ステップＳ１４１４）。

一方、受信側端末１３０では、送信側端末１２０の場合と同様に、図６に示したようなログイン画面によって、配信サーバ１００へのログイン（ステップＳ１４５１）およびユーザ認証（ステップＳ１４３１）を行う。ログイン後は、送信側端末１２０の場合と同様に、図７に示したようなメインメニューが表示され、ここでユーザは「個人放送視聴」を選択したものとする。

「個人放送視聴」が選択されたことが配信サーバ１００に通知されると、配信サーバ１００は、受信側端末１３０にログインしているユーザのＩＤから、当該ユーザ向けに指定されているコンテンツを配信情報１０９の各レコードから検索し、該当するコンテンツについての情報を受信側端末１３０に送信して表示部１３４に提示する（ステップＳ１４３２）。図１５は、ステップＳ１４３２にて提示されるユーザ別配信選択画面の例を示す図である。図１５の例では、当該ユーザに公開されている個人配信コンテンツとして、「娘」の「小学校の運動会」や、「ゴルフ場」の「３月のお得情報」のコンテンツが、今すぐ視聴可能であることが示されている。また、今後の配信予定として、「娘」の「小学校の運動会」の再配信が予定されていることが示されている。

すぐに視聴可能なコンテンツ欄の右側の「視聴」ボタンを押下して、当該コンテンツについての配信を選択すると（ステップＳ１４５２）、配信サーバ１００は、配信要求を受けた時刻が配信情報１０９における選択されたコンテンツの配信時間帯より前であるか否かを確認する（ステップＳ１４３３）。ここでは配信時間帯より前であるため、コンテンツ配信および受信の準備を行う（ステップＳ１４３４、Ｓ１４５３）。具体的には、受信側端末１３０では、配信サーバ１００との間でのＲＴＰやＨＴＴＰ等のデータ転送プロトコルによる送受信のための通信環境の確立や、配信されるコンテンツデータの受信の準備や、当該コンテンツデータについての復号器、もしくは復号されて表示可能となる映像等を表示するための装置等の準備を行う。この状態で配信開始時刻まで待つ（ステップＳ１４３５）。

配信サーバ１００のステップＳ１４１４において、配信開始時刻になった場合、配信サーバ１００からアップロード開始要求を送信側端末１２０に送信する（ステップＳ１４１５）。送信側端末１２０は、配信サーバ１００からのアップロード開始要求を受けて、コンテンツのデータをパケットと呼ばれる小さい単位に分割して、逐次的に配信サーバ１００へ送信する（ステップＳ１４０２）。

配信サーバ１００は、パケットを受信すると（Ｓ１４１６）、受信したパケットを蓄積するか否か、すなわち、配信情報１０９の当該コンテンツに対応するレコードにおける蓄積フラグがＴＲＵＥであるか否かを確認する（ステップＳ１４１７）。蓄積フラグがＴＲＵＥである場合は、受信したパケットをコンテンツ管理部１０２を経由して逐次蓄積する（ステップＳ１４１８）。ただし、ここでは蓄積フラグがＦＡＬＳＥである場合の例であるため、パケットの蓄積は行わない。

一方、配信サーバ１００における受信側端末１３０に対する処理では、配信情報１０９の当該コンテンツに対応するレコードの情報から、当該コンテンツの視聴に際してユーザが途中参加した場合の処理が「ライブのみ」であるか否かを確認する（ステップＳ１４３６）。ここでは、「ライブのみ」である場合の例であるため、次に、受信側端末１３０に配信するパケットとして、送信側端末１２０に対する処理からパケットの伝達を受ける（ステップＳ１４１９、Ｓ１４３７）。配信サーバの受信側端末１３０に対する処理では、受け取ったパケットを受信側端末１３０に転送する（ステップＳ１４３８）。これら一連の処理は、指定された配信時間帯が終了するまで繰り返される（ステップＳ１４２０）。

図１６は、これら一連の処理におけるパケット転送の例を説明する図である。送信側端末１２０から逐次送出されるパケット１６０１は、送信元が送信側端末１２０のネットワークアドレス、宛先が配信サーバ１００のネットワークアドレスとされており、データがインターネット等のネットワーク１１０を経由して配信サーバ１００に対して逐次送られる。配信サーバ１００では、受け取ったパケット１６０１を直接、もしくはデータをコンテンツ情報１０８として蓄積した後、送信元を配信サーバ１００のネットワークアドレス、宛先を受信側端末１３０のネットワークアドレスに書き換えて、パケット１６０２としてネットワーク１１０上に送出することにより、受信側端末１３０に転送する。

このように、パケット１６０１、１６０２の中の実データの内容を考慮することなく、また、受信側端末１３０が送信側端末１２０のネットワークアドレスを、逆に、送信側端末１２０が受信側端末１３０のネットワークアドレスを知ることなくデータの配信を行うことにより、秘匿性を高めたコンテンツ配信が可能となる。

なお、以上の説明では、ＩＰｖ４（Internet Protocol version 4）の様式に沿って記載しているが、ＩＰｖ６（Internet Protocol version 6）や電話回線など、他の方式による転送であってもよい。また、配信サーバ１００において、配信情報１０９の当該コンテンツに対応するレコードにおけるフォーマット変換を行うか否かの情報を確認し、フォーマット変換を行う場合には、パケットの転送の際にパケット内の実データを逐次解析することで、送信側端末１２０から送られてくるコンテンツのフォーマットを、これと異なる受信側端末１３０で表示可能なフォーマットに変換する処理を行ってもよい。

図１４の処理フローにおいて、受信側端末１３０では、配信サーバ１００から転送されてきたパケットを逐次受信し（ステップＳ１４５４）、受信したパケットのデータを用いて、コンテンツを復号して表示可能な形式に変換して表示する（ステップＳ１４５５）。

配信サーバ１００の送信側端末１２０に対する処理において、指定された配信終了時刻になった場合は（ステップＳ１４２０）、送信側端末１２０に対してコンテンツ終了要求を送信し、同様に受信側端末１３０に対する処理に対してもコンテンツ終了要求を送信する（ステップＳ１４２１）。送信側端末１２０は、コンテンツ終了要求を受けると（ステップＳ１４０３）、アップロードの終了処理を行い（ステップＳ１４０４）、処理を終了する。また、受信側端末１３０に対する処理では、コンテンツ終了要求を受けると（ステップＳ１４３９）、受信側端末１３０に対して配信終了通知を送信する（ステップＳ１４４０）。受信側端末１３０は、配信終了通知を受け取ると（ステップＳ１４５６）、コンテンツ受信終了処理を行い（ステップＳ１４５７）、処理を終了する。

このように、送信側端末１２０のユーザが設定した配信条件に従い、「ライブコンテンツのストリーミング」配信を行うことが可能となる。

＜配信処理の第２の例＞
次に、上述した本実施の形態のコンテンツ配信システムにおける配信処理の第１の例と異なり、受信側端末１３０にユーザがログインし、所望のライブコンテンツの配信を選択した時刻が、すでに送信側端末１２０にて設定された配信条件における配信時間帯に入ってしまっている場合の処理フローの例を説明する。ここで、配信前処理については、図５に示すものと同様であるため再度の説明は省略する。

図１７は、配信するコンテンツの配信条件を設定する画面の例を示す図である。図１７の例では、配信形態として「ライブ」、すなわち、配信サーバ１００からの配信時刻と受信側ユーザが視聴する時刻とがほぼ同一である配信が選択されている。さらに、当該コンテンツについて再配信を「しない」、すなわち、一度のライブ配信のみとし、また、受信側端末１３０がライブ配信の途中で参加してきて配信を受けはじめた場合の対応として「最初から」、すなわちコンテンツの最初からの視聴とするように選択されていることを表している。さらに、配信を行う時間帯として特定の時間帯を指定「する」ように選択されており、その時間帯として、「２／２９ １４：１５〜 ４５分」の時間帯が指定されている。この配信条件の例の場合は、配信情報１０９は図１３の例のＮｏ．＝２のレコードのように保持される。

図１８は、本実施の形態のコンテンツ配信システムにおける配信処理の第２の例を示すフロー図である。ここでは、送信側端末１２０に対する処理は図１４に示す処理と同様であるため記載および説明を省略する。一方、受信側端末１３０に対する処理は少々異なり、受信側端末１３０のユーザがログイン（ステップＳ１４５１、Ｓ１４３１）する際には、配信開始時刻をすでに過ぎているものとする。

受信側端末１３０において、配信サーバ１００からステップＳ１４３２によって提示されたユーザ別配信選択画面（例えば図１５）からの配信選択（ステップＳ１４５２）を行った後、配信サーバ１００では、配信情報１０９における選択されたコンテンツの配信時間帯と配信要求を受けた時刻との比較を行う（ステップＳ１４３３）。ここでは、配信要求を受けた時刻が配信開始時刻より前ではないため、次に、配信時間帯内であるか否かを確認する（ステップＳ１８０１）。ここで、配信時間帯内ではない、すなわち、配信要求を受けた時刻が配信終了時刻よりも後の場合には、受信側端末１３０の表示部１３４にその旨を表示するなどして終了したり、再度ユーザ別配信選択画面に戻るなどしてもよい。

一方、送信側端末１２０からは、ライブ配信としてコンテンツが配信サーバ１００にアップロードされているが、配信情報１０９における当該コンテンツに対応するレコードの蓄積フラグがＴＲＵＥとなっているため、図１４の処理フローにおいて、配信サーバ１００は、送信側端末１２０からアップロードされたコンテンツを逐次蓄積している（ステップＳ１４１７、Ｓ１４１８）。

次に、図１８において、コンテンツの配信・受信準備を行い（ステップＳ１４３４、Ｓ１４５３）、次に、配信サーバ１００は、配信情報１０９の当該コンテンツに対応するレコードにおける途中参加時の処理の情報が「ライブのみ」であるか否かを確認する（ステップＳ１４３６）。ここでは、「ライブのみ」ではなく「最初から」である場合の例であるため、ライブ配信中のパケットではなく、コンテンツ管理部１０２を経由して蓄積中のコンテンツのパケットの最初から逐次パケットを取得して（ステップＳ１８０２）、取得したパケットを受信側端末１３０に転送する（ステップＳ１４３８）。このとき、図１６において前述したのと同様に、パケットの宛先アドレスの変換を行ったり、コンテンツのフォーマット変換を行ったりしてもよい。

受信側端末１３０では、配信サーバ１００からのパケットを受信し（ステップＳ１４５４）、受信したパケットを復号して表示可能な形式に変換し、コンテンツの表示を行う（ステップＳ１４５５）。これら一連の処理（蓄積コンテンツのパケット転送と表示）を、配信終了時刻もしくはコンテンツの終了まで行う（ステップＳ１８０３）。配信終了時刻もしくはコンテンツが終了した場合は、配信サーバ１００の受信側端末１３０に対応する処理は、受信側端末１３０に対して配信終了通知を送信し（ステップＳ１４４０）、受信側端末１３０は、配信終了通知を受信すると（ステップＳ１４５６）、コンテンツ受信終了処理を行い（ステップＳ１４５７）、処理を終了する。

このように、送信側端末１２０によるライブ配信の途中に受信側端末１３０が配信を要求してきた場合にも、送信側端末１２０のユーザが設定した配信条件に従い、ライブ配信ではあるが配信サーバ１００ではコンテンツの蓄積を行っておき、受信側端末１３０ではいわゆる「タイムシフト視聴」を行うことが可能となる。

＜配信処理の第３の例＞
次に、送信側端末１２０からは、配信サーバ１００に対してライブコンテンツを配信し、配信サーバ１００がこれを蓄積しておき、その後、特定の時間帯において受信側端末１３０に配信する「記録コンテンツ」の配信、すなわちＶＯＤ配信を、配信サーバ１００側で自動的に実現する場合の処理フローの例を説明する。ここで、配信前処理については、図５に示すものと同様であるため再度の説明は省略する。

図１９は、配信するコンテンツの配信条件を設定する画面の例を示す図である。図１９の例では、配信形態として「ＶＯＤ」、すなわち、配信サーバ１００からの配信時刻と受信側ユーザが視聴する時刻とが異なる配信が選択されている。さらに、配信を行う時間帯として、「２／２９ １６：００〜２２：００」および「３／３ ２０：００〜２２：００」の時間帯が指定されている。この配信条件の例の場合は配信情報１０９は図１３のＮｏ．＝３のレコードのように保持される。

図２０は、本実施の形態のコンテンツ配信システムにおける配信処理の第３の例を示すフロー図のうち、送信側端末１２０に対する処理のみ記載した図である。配信サーバ１００では、送信側端末１２０からのコンテンツアップロードであるため（ステップＳ１４１１）、送信側端末１２０とコンテンツアップロードの準備を行う（ステップＳ１４０１、Ｓ１４１２）。

配信サーバ１００の送信側端末１２０に対応する処理において、図１４のフローの場合と異なり、ここではライブ配信ではない場合の例であるため（ステップＳ１４１３）、配信開始時刻を待つことなく、配信サーバ１００からアップロード開始要求を送信側端末１２０に送信する（ステップＳ１４１５）。アップロード開始要求を受信した送信側端末１２０は、コンテンツのデータをパケットと呼ばれる小さい単位に分割して、逐次的に配信サーバ１００へ送信する（ステップＳ１４０２、Ｓ１４１６）。ここでは、配信情報１０９の当該コンテンツに対応するレコードにおける蓄積フラグがＴＲＵＥであるため（ステップＳ１４１７）、配信サーバ１００は、受信したパケットをコンテンツ管理部１０２を経由して逐次蓄積する（ステップＳ１４１８）。

次に、当該コンテンツに対して指定された配信時間帯に相当する配信時間のコンテンツアップロードを終了したか否かを確認し（ステップＳ２００１）、終了した場合には、送信側端末１２０に対してコンテンツ終了要求を送信する（ステップＳ１４２１）。送信側端末は、コンテンツ終了要求を受信すると（ステップＳ１４０３）、アップロードの終了処理を行い（ステップＳ１４０４）、処理を終了する。

なお、送信端末側１２０でのこれら一連のアップロード処理は、コンテンツの配信開始時刻までには終了しているものとするが、終了していない場合でも、前述した図１８に示す処理フローの場合と同様に、ライブ配信に対する受信側端末１３０での「タイムシフト視聴」配信と同様に取り扱うことで、受信側端末１３０で配信を受けることができる。

図２１は、本実施の形態のコンテンツ配信システムにおける配信処理の第３の例を示すフロー図のうち、受信側端末１３０に対する処理のみ記載した図である。ここでは、受信側端末１３０にユーザがログインし（ステップＳ１４５１、Ｓ１４３１）、所望の個人コンテンツ配信を選択した時刻が、すでに送信側端末１２０にて設定された配信条件における配信開始時刻を過ぎているものとする。このときの配信開示時刻は、ＶＯＤ配信を行うことができる開始時刻であり、同様に配信終了時刻は、ＶＯＤ配信を行うことができる終了時刻であるものとする。すなわち、この配信開始時刻と配信終了時刻の間の時刻に配信を開始すれば、配信コンテンツの長さを考慮して、配信終了時刻を越えて配信を最後まで行ってもよい。

受信側端末１３０において、配信サーバ１００からステップＳ１４３２によって提示されたユーザ別配信選択画面（例えば図１５）からの配信選択（ステップＳ１４５２）を行った後、配信サーバ１００では、配信情報１０９における選択されたコンテンツの配信時間帯と受信側端末１３０から配信要求を受けた時刻との比較を行う（ステップＳ１４３３）。ここでは、配信要求を受けた時刻が配信開始時刻より前ではないため、次に、配信時間帯内であるか否かを確認する（ステップＳ１８０１）。ここで、配信時間帯内ではない、すなわち、配信要求を受けた時刻が配信終了時刻よりも後の場合には、受信側端末１３０の表示部１３４にその旨を表示するなどして終了したり、再度ユーザ別配信選択画面に戻るなどしてもよい。

次に、コンテンツの配信・受信準備を行い（ステップＳ１４３４、Ｓ１４５３）、次に、配信サーバ１００は、配信情報１０９の当該コンテンツに対応するレコードにおける途中参加時の処理の情報が「ライブのみ」であるか否かを確認する（ステップＳ１４３６）。ここでは、「ライブのみ」ではない場合の例であるため、コンテンツ管理部１０２を経由して蓄積済みのコンテンツのパケットの最初から逐次パケットを取得して（ステップＳ１８０２）、取得したパケットを受信側端末１３０に転送する（ステップＳ１４３８）。このとき、図１６において前述したのと同様に、パケットの宛先アドレスの変換を行ったり、コンテンツのフォーマット変換を行ったりしてもよい。

受信側端末１３０では、配信サーバ１００からのパケットを受信し（ステップＳ１４５４）、受信したパケットを復号して表示可能な形式に変換し、コンテンツの表示を行う（ステップＳ１４５５）。これら一連の処理（蓄積コンテンツのパケット転送と表示）を、配信終了時刻もしくはコンテンツの終了まで行う（ステップＳ１８０３）。配信終了時刻もしくはコンテンツが終了した場合は、配信サーバ１００の受信側端末１３０に対応する処理は、受信側端末１３０に対して配信終了通知を送信し（ステップＳ１４４０）、受信側端末１３０は、配信終了通知を受信すると（ステップＳ１４５６）、コンテンツ受信終了処理を行い（ステップＳ１４５７）、処理を終了する。

このように、図１８に示した処理フローと類似した処理を行うことで、ＶＯＤ配信を行うことが可能であり、送信側端末１２０のユーザが設定した配信条件に従い、受信側端末１３０のユーザの配信要求に柔軟に対応して適切なコンテンツ配信を行うことが可能となる。

以上に説明したように、本実施の形態のコンテンツ配信システムによれば、ストリーミング型やダウンロード型等のサービス形態と、ライブコンテンツもしくは記録コンテンツといったコンテンツ形態とを組み合わせ、送信側ユーザの意向に基づいて、受信側端末による配信サーバへのアクセス態様を考慮して、配信形態を適宜変更してコンテンツ配信を行うコンテンツ配信システムを提供することが可能となる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、上述した配信サーバ１００、送信側端末１２０および受信側端末１３０が保持するデータについては、外部からの盗用、なりすまし等の悪用を防ぐため、暗号化や異常時の自己破壊などの適切な手段で保護されることが望ましい。また、配信サーバ１００、および送信側端末１２０、受信側端末１３０が有する通信部（１０４、１２２、１３２）による相互の通信は、他技術、例えばＳＳＬ（Secure Socket Layer）等の技術を用いるなどにより、相互信頼と外部の悪用を防止した通信を行うためのデータ暗号化を行うことが望ましい。

また、本実施の形態における送信側端末１２０、受信側端末１３０の画面等には、配信サーバ１００側で生成したＨＴＭＬ等の記述を表現する手段としてＷｅｂブラウザ等を用いてもよい。さらに、本実施の形態では、コンテンツとして映像や音声や文字情報などのいくつかのメディアで構成する番組情報を想定して説明を行ったが、コンテンツはこれらに限らず、ＰＣ等で用いられるファイル、実行可能なオブジェクトデータ、メール文書、ＷＷＷ（World Wide Web）により送受信されるマークアップ記述や動作記述を行うスクリプト、その他ネットワークを用いて伝送が行われる一般的電子データであってもよい。従って、本実施の形態のコンテンツ配信システムは、ネットワークを用いた多くの産業で汎用的に用いられる可能性がある。

本発明は、ネットワークを介したコンテンツ配信サービス、特に、個人放送局に適用可能なＩＰテレビを用いた放送局システムなどのコンテンツ配信システム、および配信サーバ、送信側端末、ならびに配信サーバプログラム、送信側端末プログラムに利用可能である。

本発明の一実施の形態であるコンテンツ配信システムの基本的なシステム構成例を表した図である。 本発明の一実施の形態における認証情報のデータ構造およびデータの例を示す図である。 本発明の一実施の形態における課金情報のデータ構造およびデータの例を示す図である。 本発明の一実施の形態におけるコンテンツ情報のデータ構造およびデータの例を示す図である。 本発明の一実施の形態における処理フローのうち、送信側端末で行われる送信前処理の流れの例を示すフロー図である。 本発明の一実施の形態におけるユーザ認証の際のログイン画面の例を示す図である。 本発明の一実施の形態におけるメインメニューの例を示す図である。 本発明の一実施の形態における、個人放送配信における配信条件設定の主画面の例を示す図である。 本発明の一実施の形態における、配信条件のうちのコンテンツの形態等の情報を設定する画面の例を示す図である。 本発明の一実施の形態における、配信するコンテンツの配信条件を設定する画面の例を示す図である。 本発明の一実施の形態における、送信側端末から配信サーバに送信する配信条件設定情報のデータ構造およびデータの例を示す図である。 本発明の一実施の形態における、配信サーバにおける配信条件評価処理の流れの例を示すフロー図である。 本発明の一実施の形態における配信情報のデータ構造とデータの例を示す図である。 本発明の一実施の形態における、配信処理の第１の例を示すフロー図である。 本発明の一実施の形態におけるユーザ別配信選択画面の例を示す図である。 本発明の一実施の形態におけるパケット転送の例を説明する図である。 本発明の一実施の形態における、配信するコンテンツの配信条件を設定する画面の例を示す図である。 本発明の一実施の形態における、配信処理の第２の例を示すフロー図である。 本発明の一実施の形態における、配信するコンテンツの配信条件を設定する画面の例を示す図である。 本発明の一実施の形態における、配信処理の第３の例を示すフロー図のうち、送信側端末に対する処理のみ記載した図である。 本発明の一実施の形態における、配信処理の第３の例を示すフロー図のうち、受信側端末に対する処理のみ記載した図である。

符号の説明

１００…配信サーバ、１０１…ユーザ管理部、１０２…コンテンツ管理部、１０３…演算部、１０４…通信部、１０５…配信管理部、１０６…認証情報、１０７…課金情報、１０８…コンテンツ情報、１０９…配信情報、１１０…ネットワーク、１２０…送信側端末、１２１…コンテンツ管理部、１２２…通信部、１２３…演算部、１２４…表示部、１２５…入力部、１２６…コンテンツ情報、１２７…設定情報、１２８…識別子、１３０…受信側端末、１３１…コンテンツ管理部、１３２…通信部、１３３…演算部、１３４…表示部、１３５…入力部、１３６…コンテンツ情報、１３７…設定情報、１３８…識別子、
１６０１…パケット、１６０２…パケット。

Claims (11)

1. ネットワークに接続され、コンテンツを配信する配信サーバと、
   前記ネットワークに接続され、前記配信サーバによる配信の対象となる前記コンテンツを前記配信サーバに送信する送信側端末と、
   前記ネットワークに接続され、前記配信サーバから配信される前記コンテンツを受信して表示を行う受信側端末とから構成されるコンテンツ配信システムであって、
   前記送信側端末は、送信側ユーザの指示に基づいて配信の対象となる前記コンテンツを特定する情報および前記コンテンツの配信条件を前記配信サーバに対して指定し、
   前記配信サーバは、前記送信側端末から指定された前記配信条件と、前記受信側端末からのアクセス態様とに基づいて、配信対象の前記コンテンツの配信形態を変更して前記受信側端末へ配信することを特徴とするコンテンツ配信システム。
2. 請求項１に記載のコンテンツ配信システムにおいて、
   前記配信条件は、前記コンテンツの配信形態の情報と、前記コンテンツの配信を受けることができる前記受信側端末もしくは受信側ユーザの情報、および／または、前記コンテンツの配信を行う時間帯の情報とを含むことを特徴とするコンテンツ配信システム。
3. 請求項２に記載のコンテンツ配信システムにおいて、
   前記配信サーバは、前記配信条件に、前記コンテンツの配信を受けることができる前記受信側端末もしくは受信側ユーザの情報が指定されている場合に、当該情報と前記配信サーバにアクセスしている前記受信側端末の接続情報とを比較し、合致する場合にのみ前記受信側端末に前記コンテンツを配信することを特徴とするコンテンツ配信システム。
4. 請求項２に記載のコンテンツ配信システムにおいて、
   前記配信サーバは、前記配信条件に、前記コンテンツの配信を行う時間帯の情報が指定されている場合に、当該時間帯と前記受信側端末からの配信要求を受けた時刻とを比較し、当該時間帯の範囲内である場合にのみ前記受信側端末に前記コンテンツを配信することを特徴とするコンテンツ配信システム。
5. 請求項１に記載のコンテンツ配信システムにおいて、
   前記配信サーバは、前記送信側端末から指定された前記配信条件に基づいて、前記送信側端末から受信した配信対象の前記コンテンツを前記配信サーバ上に蓄積するか否かを制御することを特徴とするコンテンツ配信システム。
6. 請求項１に記載のコンテンツ配信システムにおいて、
   前記配信サーバは、配信対象の前記コンテンツを前記送信側端末から受信中に、配信対象の前記コンテンツに対する配信要求を前記受信側端末から受けた場合に、前記送信側端末から指定された前記配信条件および前記受信側端末からのアクセス態様とに基づいて、配信対象の前記コンテンツの最初から配信するのか途中から配信するのかを制御することを特徴とするコンテンツ配信システム。
7. 請求項１に記載のコンテンツ配信システムにおいて、
   前記配信サーバは、配信対象の前記コンテンツについての前記配信条件に、前記コンテンツの配信を受けることができる前記受信側端末を特定する情報が指定されており、かつ、該当する前記受信側端末が前記配信サーバに接続している場合に、前記送信側端末から前記配信サーバに逐次分割送信される配信対象の前記コンテンツにおけるネットワーク伝送に用いる宛先を、前記配信サーバから前記受信側端末に変更することで、前記送信側端末から受信した前記コンテンツを前記受信側端末に転送して配信することを特徴とするコンテンツ配信システム。
8. ネットワークに接続され、コンテンツを配信する配信サーバと、
   前記ネットワークに接続され、前記配信サーバによる配信の対象となる前記コンテンツを前記配信サーバに送信する送信側端末と、
   前記ネットワークに接続され、前記配信サーバから配信される前記コンテンツを受信して表示を行う受信側端末とから構成されるコンテンツ配信システムにおける配信サーバであって、
   前記送信側端末から指定された配信対象の前記コンテンツの配信条件と、前記受信側端末からのアクセス態様とに基づいて、配信対象の前記コンテンツの配信形態を変更して前記受信側端末へ配信することを特徴とする配信サーバ。
9. ネットワークに接続され、コンテンツを配信する配信サーバと、
   前記ネットワークに接続され、前記配信サーバによる配信の対象となる前記コンテンツを前記配信サーバに送信する送信側端末と、
   前記ネットワークに接続され、前記配信サーバから配信される前記コンテンツを受信して表示を行う受信側端末とから構成されるコンテンツ配信システムにおける送信側端末であって、
   送信側ユーザの指示に基づいて配信の対象となる前記コンテンツを特定する情報および前記コンテンツの配信条件を前記配信サーバに対して指定することを特徴とする送信側端末。
10. ネットワークに接続され、コンテンツを配信する配信サーバと、
    前記ネットワークに接続され、前記配信サーバによる配信の対象となる前記コンテンツを前記配信サーバに送信する送信側端末と、
    前記ネットワークに接続され、前記配信サーバから配信される前記コンテンツを受信して表示を行う受信側端末とから構成されるコンテンツ配信システムにおける、コンピュータシステムを前記配信サーバとして動作させるための配信サーバプログラムであって、
    前記送信側端末から指定された配信対象の前記コンテンツの配信条件と、前記受信側端末からのアクセス態様とに基づいて、配信対象の前記コンテンツの配信形態を変更して前記受信側端末へ配信することを特徴とする配信サーバプログラム。
11. ネットワークに接続され、コンテンツを配信する配信サーバと、
    前記ネットワークに接続され、前記配信サーバによる配信の対象となる前記コンテンツを前記配信サーバに送信する送信側端末と、
    前記ネットワークに接続され、前記配信サーバから配信される前記コンテンツを受信して表示を行う受信側端末とから構成されるコンテンツ配信システムにおける、コンピュータシステムを前記送信側端末として動作させるための送信側端末プログラムであって、
    送信側ユーザの指示に基づいて配信の対象となる前記コンテンツを特定する情報および前記コンテンツの配信条件を前記配信サーバに対して指定することを特徴とする送信側端末プログラム。

Images