(57)【要約】      （修正有）【課題】コンテンツデータが入力されてから、通信相手がコンテンツデータを取得するまでの時間を低減する通信装置、方法及びプログラムを提供する。【解決手段】データ通信装置１０１のコンテンツ生成部３０５は、コンテンツデータを入力し、データ通信装置のプレイリスト管理部３０４は、コンテンツ生成部により入力された第１期間のコンテンツデータを再生装置に要求させるための第１情報と第２期間のコンテンツデータを再生装置に要求させるための第２情報とを示すリスト情報を生成する。そしてＷｅｂサーバ部３０１は、リスト情報を再生装置へ送信し、リスト情報を取得した再生装置による第１及び第２情報に対するアクセスに応じてコンテンツデータを送信する。【選択図】図３
2016091436.tif 000002
【特許請求の範囲】
【請求項１】
第１期間に対応する第１のコンテンツデータと、前記第１期間より後の第２期間に対応する第２のコンテンツデータを順次、入力する入力手段と、
前記入力手段により入力された第１のコンテンツデータを通信相手に要求させるための第１情報と、前記入力手段による入力が未完了の第２のコンテンツデータを前記通信相手に要求させるための第２情報とを示すリスト情報を生成する生成手段と、
前記生成手段により生成された前記リスト情報を通信相手に対して送信すると共に、前記リスト情報を受信した前記通信相手により前記第２情報に対するアクセスが実行された場合、前記リスト情報の生成後に前記入力手段が入力完了した前記第２のコンテンツデータを前記通信相手に対して送信する送信手段とを備えることを特徴とする通信装置。
【請求項２】
前記生成手段は、前記第１のコンテンツデータの前記第１情報と、前記第２のコンテンツデータの前記第２情報とをそれぞれ記述した前記リスト情報を生成することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記生成手段は、テンプレートを含む前記リスト情報を生成し、
前記クライアントは、前記第１のコンテンツデータの識別情報を前記テンプレートに挿入することで前記第１のコンテンツデータの前記第１情報を特定可能で、且つ、前記第２のコンテンツデータの識別情報を前記テンプレートに挿入することで前記第２のコンテンツデータの第２情報を特定可能であることを特徴とする請求項１に記載の通信装置。
【請求項４】
前記リスト情報には、当該リスト情報が有効になる時刻を示す有効開始時刻が記述され、
前記生成手段は、前記入力手段がコンテンツデータを入力開始する時刻よりも前の時刻を前記有効開始時刻の情報として含む前記リスト情報を生成することを特徴とする請求項３に記載の通信装置。
【請求項５】
前記第２のコンテンツデータを前記入力手段が入力完了する前に前記第２のコンテンツデータの要求を前記クライアントから受信した場合、前記送信手段は、前記クライアントに対してエラーを通知することを特徴とする請求項１乃至４のうち、何れか１項に記載の通信装置。
【請求項６】
前記第２のコンテンツデータを前記入力手段が入力完了する前に前記第２のコンテンツデータの要求を前記クライアントから受信した場合、当該受信から前記第２のコンテンツデータの入力完了までに要する時間情報を判定する判定手段をさらに備え、
前記送信手段は、前記判定された時間情報が所定時間よりも長い時間に対応する場合、前記クライアントに対してエラーを通知し、前記判定された前記時間情報が前記所定時間より短い時間に対応する場合、前記エラーを通知せず、前記第２のコンテンツデータの前記入力手段による入力が完了してから前記クライアントに対して前記第２のコンテンツデータを送信することを特徴とする請求項１乃至４のうち、何れか１項に記載の通信装置。
【請求項７】
撮影手段をさらに備え、
前記入力手段は、前記撮影手段による撮影データを前記コンテンツデータとして入力することを特徴とする請求項１乃至６のうち、何れか１項に記載の通信装置。
【請求項８】
前記入力手段は、ネットワークを介して接続される他の通信装置から、前記コンテンツデータを入力することを特徴とする請求項１乃至６のうち、何れか１項に記載の通信装置。
【請求項９】
記憶手段に記憶された第１のコンテンツデータをクライアントに要求させるための第１情報と、前記記憶手段に記憶されていない第２のコンテンツデータをクライアントに要求させるための第２情報とを示すリスト情報を生成する生成工程と、
前記生成工程により生成された前記リスト情報をクライアントに対して送信すると共に、前記リスト情報を受信した前記クライアントにより前記第２情報に対するアクセスが実行された場合、前記リスト情報の生成後に前記記憶手段に記憶された前記第２のコンテンツデータを前記クライアントに対して送信する送信工程とを備え、前記第１のコンテンツデータは、第１期間に対応するコンテンツデータであり、前記第２のコンテンツデータは、前記第１期間より後の第２期間に対応するコンテンツデータであることを特徴とする通信方法。
【請求項１０】
前記生成工程は、前記第１のコンテンツデータの前記第１情報と、前記第２のコンテンツデータの前記第２情報とをそれぞれ記述した前記リスト情報を生成することを特徴とする請求項９に記載の通信方法。
【請求項１１】
前記生成工程は、テンプレートを含む前記リスト情報を生成し、
前記クライアントは、前記第１のコンテンツデータの識別情報を前記テンプレートに挿入することで前記第１のコンテンツデータの前記第１情報を特定可能で、且つ、前記第２のコンテンツデータの識別情報を前記テンプレートに挿入することで前記第２のコンテンツデータの前記第２情報を特定可能であることを特徴とする請求項９に記載の通信方法。
【請求項１２】
コンピュータを請求項１乃至８のうちいずれか１項に記載の通信装置として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツデータの送信のための通信技術に関する。
【背景技術】
【０００２】
近年、音声データや映像データ等により構成されるストリーミング形式のコンテンツをユーザに配信するストリーム配信システムが提供されている。このようなシステムにより、ユーザは、撮影中のライブコンテンツや映画などの記録済みコンテンツなどの所望のコンテンツをネットワーク経由で自身の端末装置で受信することで視聴することができる。
【０００３】
インターネットのようなオープンなネットワークを介してストリーミング配信を可能とする技術としてＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）を用いたストリーミング技術（例えばＭＰＥＧ−ＤＡＳＨ）が知られている。これらＨＴＴＰストリーミング技術では、サーバ側でコンテンツデータを数秒毎のセグメントという単位に区切り、それぞれのセグメントに対するアクセス情報であるＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）をプレイリストに記述する。このプレイリストを再生装置が受信し、プレイリスト内のアクセス情報を用いて所望のセグメントを取得することによって擬似的なストリーミングを実現する。
【０００４】
ＶｏＤ（Ｖｉｄｅｏ  ｏｎ  Ｄｅｍａｎｄ）システムなどで利用されるＨＴＴＰストリーミングでは、多数の再生装置に対して多数のコンテンツデータを配信することが求められる。これに対応するため、元のコンテンツデータを例えばクラウド上に存在する複数のサーバに転送し、ロードバランサーを用いて処理負荷を分散させることが一般的に行われている。
【０００５】
一方でリアルタイムコンテンツストリーミングにおいてはコンテンツのリアルタイム性が重視されるため、撮影等により取得されたコンテンツをなるべく低遅延で再生装置に届けることが求められる。低遅延でコンテンツを配信するためには、コンテンツデータがサーバ側で取得されてから再生装置側に配信されるまでの時間を短くすることが求められる。
【０００６】
特許文献１に記載の配信システムでは、再生装置がプレイリストをサーバより取得し、プレイリスト内に記載される複数のコンテンツファイルのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）に順番にアクセスしコンテンツを取得している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２０１２−５１４２７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、通信装置にコンテンツデータが入力されてから通信装置の通信相手が当該コンテンツデータを取得するまでにかかる時間が長くなってしまう場合が考えられる。
【０００９】
例えば、サーバ側（通信装置側）でコンテンツデータ（セグメント）を取得してから、当該コンテンツデータを要求するためのＵＲＬをプレイリスト内に記述する場合を例に挙げる。この場合において、サーバがプレイリストをクライアントに送信し、プレイリストをパースしたクライアントがコンテンツデータの要求をサーバへ送信し、当該要求を受信したサーバがコンテンツデータをクライアントへ送信する。このようにして、クライアントはコンテンツデータを再生できる。しかしながら、上記の手順に従ってサーバからコンテンツデータを再生装置に送信すると、サーバによるセグメントの取得から、再生装置が当該コンテンツデータを取得するまでに時間がかかってしまうことが考えられる。
【００１０】
本発明は、上記課題を解決するためになされたものであり、その目的は、通信装置にコンテンツデータが入力されてから通信装置の通信相手が当該コンテンツデータを取得するまでにかかる時間を低減することである。
【課題を解決するための手段】
【００１１】
上記の課題を解決するために、本発明の通信装置は、例えば以下の構成を備える。すなわち、第１期間に対応する第１のコンテンツデータと、前記第１期間より後の第２期間に対応する第２のコンテンツデータを順次、入力する入力手段と、前記入力手段により入力された第１のコンテンツデータをクライアントに要求させるための第１情報と、前記入力手段による入力が未完了の第２のコンテンツデータを前記クライアントに要求させるための第２情報とを示すリスト情報を生成する生成手段と、前記生成手段により生成された前記リスト情報をクライアントに対して送信すると共に、前記リスト情報を受信した前記クライアントにより前記第２情報に対するアクセスが実行された場合、前記リスト情報の生成後に前記入力手段が入力完了した前記第２期間のコンテンツデータを前記クライアントに対して送信する送信手段とを備える。
【発明の効果】
【００１２】
本発明によれば、通信装置にコンテンツデータが入力されてから通信装置の通信相手が当該コンテンツデータを取得するまでにかかる時間を低減できる。
【図面の簡単な説明】
【００１３】
【図１】実施形態のシステム構成図である。
【図２】実施形態におけるデータ通信装置１０１のハードウェア構成例を示すブロック図である。
【図３】実施形態におけるデータ通信装置１０１の機能モジュール構成例を示すブロック図である。
【図４】実施形態におけるプレイリスト生成処理の動作を示すフローチャートである。
【図５】実施形態におけるコンテンツデータのセグメント化処理の動作を示すフローチャートである。
【図６】実施形態におけるプレイリストの一例を示す図である。
【図７】実施形態におけるプレイリストの一例を示す図である。
【図８】実施形態におけるプレイリストの一例を示す図である。
【図９】実施形態におけるデータ通信装置１０１と再生装置１０２との間のメッセージの一例を示すシーケンス図である。
【図１０】実施形態におけるデータ通信装置１０１の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１４】
以下に、本発明の一実施形態について図面を用いて説明する。ただし、本発明はこの具体的な処理例に限定されるものではない。
【００１５】
＜システム全体の構成図＞
以下、添付の図面を参照して、本発明に関わる実施形態を説明する。図１は、本実施形態におけるコンテンツデータ配信システムの構成例を示す図である。
【００１６】
ネットワーク１０３は、本実施形態におけるネットワークとしての一般的なインターネット回線である。なお、本実施形態ではネットワークとしてインターネット回線を利用しているが、これに限らずＷＡＮなどの公衆網、ＬＡＮ、ＰＡＮなどのローカルネットワーク、ＶＰＮなどの専用回線、イントラネットワークやオンプレミスな回線などでも良い。なお、ＷＡＮはＷｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ、ＬＡＮはＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋである。また、ＰＡＮはＰｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ、ＶＰＮはＶｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋである。
【００１７】
データ通信装置１０１（以下、通信装置１０１）は、本実施形態における通信装置である。通信装置１０１は、コンテンツデータ（例えば、映像データやオーディオデータ、テキストデータ等）の入力と、当該入力したコンテンツデータの送信が可能である。通信装置１０１の具体的な例としては、カメラ装置、ビデオカメラ装置、スマートフォン装置、パーソナルコンピュータ、携帯電話などが挙げられるが、後述のハードウェア構成及び機能モジュール構成を満たすものであれば、これらに限定されない。また、本実施形態の通信装置１０１はカメラを備えており、撮影によってコンテンツデータ（撮影データ）を取得（生成）するが、他の装置によって取得（生成）されたコンテンツデータを入力するようにしても良い。例えば、通信装置１０１は、ネットワークを介して接続される他の通信装置から、コンテンツデータを入力し、当該入力完了したコンテンツデータをクライアント（再生装置１０２）に対して送信することも可能である。本実施形態において、クライアント（再生装置１０２）は、通信装置１０１に対する通信相手である。また、ネットワーク１０３に接続された通信装置１０１は１台のみであっても良いし、複数台存在しても良い。
【００１８】
再生装置１０２は、コンテンツデータの再生・表示機能、及び後述するプレイリストの解釈機能、及び通信機能を備える。再生装置１０２の具体例は、スマートフォン装置、ＰＣ装置、デジタルテレビ、携帯電話、などが挙げられるが、これらに限定されない。また、コンテンツデータの再生・表示機能とプレイリストの解釈機能、通信機能を別の装置で行い、それらを通信させる構成でも良い。ネットワーク１０３に接続された再生装置１０２は１台のみであっても良いし、複数台存在しても良い。
【００１９】
＜データ通信装置ハードウェア構成図＞
図２は本実施形態における通信装置１０１のハードウェア構成例を示すブロック図である。通信装置１０１は上述の通り、カメラ装置、ビデオカメラ装置、スマートフォン装置、パーソナルコンピュータ、携帯電話等で実現可能である。通信装置１０１は図２に示すように、バス２０１、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０２、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０４を備える。また、通信装置１０１は、撮影部２０５、記憶部２０６、通信部２０７を備える。ただし、撮影部２０５や記憶部２０６が別の装置として存在し、通信装置１０１が撮影部２０５や記憶部２０６に接続されるような構成であってもよい。
【００２０】
ＣＰＵ２０２は、ＲＯＭ２０３、ＲＡＭ２０４、及び記憶部２０６内に記憶されたコンピュータプログラムや処理用データに従って各種処理を実行することにより、通信装置１０１の各種機能を実現する。また、ＲＡＭ２０４は、半導体メモリ等の揮発性の記録媒体により構成され、ＣＰＵ２０２が実行するコンピュータプログラムや処理用データを一時的に格納する。
【００２１】
ＲＯＭ２０３、及び記憶部２０６は、磁気的、光学的記録媒体、半導体メモリ等のＣＰＵ２０２が読み取り可能な不揮発性の記録媒体により構成される。ＲＯＭ２０３及び記憶部２０６は通信装置１０１の起動プログラム等の基本プログラムを記憶する。また、後述する通信装置１０１の動作を実現する配信プログラム等のアプリケーションプログラム、及びこれらプログラムの実行に必要な処理用データも記憶する。
【００２２】
ここで、ＲＯＭ２０３、及び記憶部２０６内に記憶される情報の一部若しくは全部は、ネットワーク１０３を介してインストールする構成にしてもよい。また、上記アプリケーションプログラムは、後述する処理を実行する際に、ＣＰＵ２０２が記録媒体から読み出すようにしてもよい。この場合、ＣＰＵ２０２は、処理を実行する際に、記録媒体から読み出したアプリケーションプログラムをＲＡＭ２０４内に記録した後に、アプリケーションプログラムを実行する。なお、記録媒体には、例えば、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープ等のＣＰＵ２０２が読み取り可能な全ての記録媒体が含まれる。
【００２３】
撮影部２０５はＣＰＵ２０２の指示のもと、撮影を実行してコンテンツデータを取得（生成）し、取得済みのコンテンツデータを記憶部２０６もしくはＲＡＭ２０４に保存する。すなわち撮影部２０５は、撮影によりコンテンツデータを取得し、当該取得されたコンテンツデータをＲＡＭ２０４に入力する。また、通信部２０７は、通信装置１０１と再生装置１０２の間の通信仕様に対応したプロトコルスタックを実装し、有線通信部２０８、及び無線通信部２０９の両方、もしくはいずれかを利用して通信を実現する。この実施形態では、通信部２０７はＨＴＴＰ、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）等の通信用プロトコルを実装する。通信部２０７は、上記通信用プロトコルに従ってプレイリスト及びコンテンツデータを再生装置１０２に送信する。また、通信部２０７は、この通信用プロトコルに従って、プレイリストの要求やコンテンツデータの要求やコンテンツデータの転送に対する応答等の各種情報を再生装置１０２から受信し、受信した情報をＣＰＵ２０２が処理可能な形式に変換する。
【００２４】
＜送信装置モジュール構成図＞
図３は、本実施形態における通信装置１０１のモジュール構成例を示すブロック図である。Ｗｅｂサーバ部３０１は、ネットワーク１０３を介して再生装置１０２と通信を行う。Ｗｅｂサーバ部３０１は、再生装置１０２からのリクエストに対して、リクエストされたリソースをセグメント管理部３０３、もしくはプレイリスト管理部３０４から取得して送信する。より詳細には、再生装置１０２がデータ通信装置１０１に対して発行するリクエストは、特定のリソースと紐づけられているＵＲＬに対して行われる。Ｗｅｂサーバ部３０１は、再生装置１０２からのリクエストが示すＵＲＬを解釈し、ＵＲＬに対応するリソースがプレイリストの場合、プレイリスト管理部３０４からプレイリストを取得し、再生装置１０２に対して送信する。一方、Ｗｅｂサーバ部３０１は、再生装置１０２からのリクエストが示すＵＲＬに対応するリソースがセグメントの場合、セグメント管理部３０３からセグメントを取得し、再生装置１０２に対して送信する。
【００２５】
本実施形態では、再生装置１０２が送信するリクエストのうち、プレイリストを要求するためのリクエストをプレイリスト取得要求、セグメント（コンテンツデータ）を要求するためのリクエストをコンテンツ取得要求として説明する。
【００２６】
なお、本実施形態のセグメントは、コンテンツデータとしての動画データを所定時間ごとに分割した場合の分割単位である。ただし、コンテンツデータは動画データに限らず、オーディオデータやテキストデータ等であってもよいし、それらの組み合わせでもよい。また、動画データを所定時間ごとに分割するのではなく、所定データ量ごとに分割し、当該所定データ量ごとの動画データのことを、セグメントとして扱うことも可能である。上記のように、セグメントの設定は特定の方法に限定されない。
【００２７】
本実施形態のＷｅｂサーバ部３０１は、不正な再生装置やリクエストを除外するための認証機能や脆弱性に対応する機能を備えている。また、Ｗｅｂサーバ部３０１は、すでに存在しないセグメントに対するリクエストに対してエラーメッセージを送信してもよい。すでに存在しないセグメントとは、例えば、通信装置１０１が取得してから所定時間が経過したことにより、別のサーバ装置に転送され、通信装置１０１の内部に存在しなくなったセグメントである。
【００２８】
制御部３０２は、通信装置１０１の全体の制御を行う。制御部３０２は、Ｗｅｂサーバ部３０１、セグメント管理部３０３、プレイリスト管理部３０４の各モジュールを管理、制御する。
【００２９】
セグメント管理部３０３は、コンテンツ生成部３０５により取得されたコンテンツデータ（例えば動画データ）を一定の時間で分割する。そしてセグメント管理部３０３は、分割によって得られたセグメントをＲＡＭ２０４内もしくは記憶部２０６内に保存する。すなわち、セグメント管理部３０３は、第１期間のコンテンツデータ（セグメント１）と第２期間のコンテンツデータ（セグメント２）を順次、入力する。本実施形態において、セグメント１は、第１期間に撮像等によって取得されたコンテンツデータ（コンテンツデータ１）である。セグメントをＲＡＭ２０４に保存するか記憶部２０６に保存するかに関する制御については図５を用いて後述する。
【００３０】
セグメント管理部３０３は、ＲＡＭ２０４内、及び記憶部２０６内に保存されているセグメントの情報を管理し、再生装置１０２に対して配信可能なセグメントを把握する機能を備える。また、セグメント管理部３０３は、セグメントを、Ｗｅｂサーバ部３０１を利用し、ネットワーク１０３を介して再生装置１０２に送信する。さらに、セグメント管理部３０３は次のセグメントが生成されるまでに要する時間を管理する。
【００３１】
プレイリスト管理部３０４はプレイリストの生成及び管理を行う。本実施形態のプレイリスト管理部３０４は、再生装置１０２からのプレイリスト取得要求の受信に応じて、プレイリストを生成し、生成されたプレイリストを再生装置１０２に対して送信することが可能である。
【００３２】
より具体的には、Ｗｅｂサーバ部３０１が再生装置１０２からプレイリスト取得要求を受信すると、当該取得要求はプレイリスト管理部３０４に通知される。そして、プレイリスト管理部３０４は、再生装置１０２に対して配信可能なセグメントの情報をセグメント管理部３０３に問い合わせ、問い合わせ結果に基づいてプレイリストを生成する。
【００３３】
なお、詳細は後述するが、本実施形態のプレイリスト管理部３０４は、通信装置１０１が取得済みのセグメントを再生装置１０２に要求させるためのアクセス情報のみならず、通信装置１０１が未入力のセグメントのアクセス情報を示すプレイリストを生成する。つまり、プレイリスト管理部３０４は、通信装置１０１が動画データの第１セグメントを入力済みで、第２セグメントの入力は未完了（これから入力される）の場合にプレイリスト取得要求を受信した場合、以下のようなプレイリストを生成する。すなわち、プレイリスト管理部３０４は、第１セグメントを再生装置１０２に要求させるためのアクセス情報（第１情報）と、第２セグメントを再生装置１０２に要求させるためのアクセス情報（第２情報）とを示すリスト情報（プレイリスト）を生成する。そして生成したプレイリストは、Ｗｅｂサーバ部３０１によって、ネットワーク１０３を介して再生装置１０２へ送信される。なお、再生装置１０２は、プレイリストを受信したからといって、必ず第1情報や第２情報にアクセスしなければならないわけではない。
【００３４】
なお、プレイリスト管理部３０４は、新たなセグメントが生成されるたびにプレイリストを新たに生成することも可能であるし、一定期間ごとにプレイリストを生成することも可能である。プレイリスト管理部３０４は、例えば、第１セグメントが入力されたタイミングで新たにプレイリストを生成する場合、第１セグメントのアクセス情報と、第２セグメントのアクセス情報とを示すリスト情報（プレイリスト）を生成することが可能である。そして、再生装置１０２からのプレイリスト取得要求の受信に応じて、生成済みのプレイリストがプレイリスト管理部３０４から再生装置１０２に送信される。具体的なプレイリストの生成方法については図４〜図７を用いて後述する。
【００３５】
コンテンツ生成部３０５は、撮影部２０５からコンテンツデータ（動画データ）を取得し、制御部３０２を介してセグメント管理部３０３に渡す機能を有する。上述の通り、コンテンツデータは動画データに限らず、オーディオデータやテキストデータ等であってもよいし、それらの組み合わせでもよい。例えばコンテンツデータをオーディオデータにする場合は、撮影部２０５をマイクに置き換えれば良い。
【００３６】
＜プレイリスト生成処理＞
図４は、本実施形態のプレイリスト管理部３０４がプレイリストを生成する際の動作を示すフローチャートである。図４の処理は、通信装置１０１のＣＰＵ２０２が、図４の処理の実行に必要なプログラムをＲＯＭ２０３から読み出して実行することにより実現される。ただし、図４の処理が専用のハードウェアによって行われるようにしてもよい。また、図４の処理は、通信装置１０１が再生装置１０２からのプレイリスト取得要求の受信に応じて開始される。ただし、図４の処理が、新たなセグメントの生成に応じて開始されるようにしてもよいし、一定時間ごとに開始されるようにしてもよい。
【００３７】
プレイリスト管理部３０４は、通信装置１０１のＷｅｂサーバ部３０１が再生装置１０２から受信したプレイリスト取得要求を取得する（Ｓ４００）。ただし、新たなセグメントの生成に応じて図４の処理が開始される場合は、プレイリスト管理部３０４は、Ｓ４００において、新たなセグメントの生成完了を示す通知をセグメント管理部３０３から取得する。また、一定時間ごとに図４の処理が開始される場合は、プレイリスト管理部３０４は、Ｓ４００において、一定時間が経過したことを示す通知を計時部から取得する。計時部の機能はＣＰＵ２０２が実行する計時アプリケーションによって実現可能である。
【００３８】
Ｓ４００においてプレイリスト取得要求を取得したプレイリスト管理部３０４は、Ｓ４０１において、配信可能な（入力済みの）セグメントの識別情報をセグメント管理部３０３から取得する。例えば、Ｓ４０１の時点で、第１セグメントが入力済みであり、第２セグメントの入力が未完了であった場合、プレイリスト管理部３０４は、第１セグメントの識別情報をセグメント管理部３０３から取得する。なお、第２セグメントは、第１セグメントの次の期間の動画データであり、第１セグメントの取得後に撮影部２０５の撮影が継続されることで取得される。Ｓ４０１において配信可能なセグメントの識別情報をプレイリスト管理部３０４が取得すると、Ｓ４０２に進む。
【００３９】
Ｓ４０２において、プレイリスト管理部３０４は、セグメント管理部３０３が入力済みのセグメントを再生装置１０２に要求させるためのアクセス情報と、セグメント管理部３０３による入力が未完了のセグメントのアクセス情報とを示すプレイリストを生成する。より具体的には、プレイリスト管理部３０４は、Ｓ４０１で取得したセグメントの識別情報に対応するセグメントよりも後に取得されるべきセグメントのアクセス情報（ＵＲＬ）を示すプレイリストを生成する。
【００４０】
即ち、プレイリスト管理部３０４は、セグメント管理部３０３が入力済みの第１セグメントの第１情報と、セグメント管理部３０３による入力が未完了の第２セグメントの第２情報とを示すリスト情報（プレイリスト）を生成する。なお、第１セグメントは、第１期間に取得された動画データ（コンテンツデータ）に対応し、第２セグメントは、第１期間に続く第２期間に取得された動画データ（コンテンツデータ）に対応する。また、アクセス情報は、再生装置１０２（クライアント）がコンテンツデータを要求するためのＵＲＬである。プレイリスト管理部３０４によってＳ４０２で生成されたプレイリストは、プレイリスト取得要求を送信した再生装置１０２に対して送信される。本実施形態において、再生装置１０２（クライアント）は、通信装置１０１の通信相手である。
【００４１】
＜コンテンツデータのセグメント化処理＞
図５は本実施形態において、セグメント管理部３０３がコンテンツデータを取得した後、当該コンテンツデータを一定時間で区切ったセグメントに分割し、それを保存する方法についての動作例を示すフローチャートである。
【００４２】
図５の処理は、通信装置１０１が再生装置１０２からプレイリスト取得要求を受信することで開始される。ただし、図５の処理が開始されるタイミングは上記のタイミングに限らない。また、図５の処理は、通信装置１０１のＣＰＵ２０２が、図５の処理の実行に必要なプログラムをＲＯＭ２０３から読み出して実行することにより実現される。ただし、図５の処理が専用のハードウェアによって行われるようにしてもよい。
【００４３】
セグメント管理部３０３は、コンテンツ生成部３０５を介して撮影部２０５からコンテンツデータを取得する（Ｓ５００）。そして、セグメント管理部３０３は、Ｓ５００で取得したコンテンツデータを所定時間ごと（例えば２秒ごと）に分割してセグメントを得る（Ｓ５０１）。なお、本実施形態では、動画データが所定時間ごとに分割された場合の１つ１つの分割コンテンツデータをセグメントとする例を中心に説明しているが、この形態に限らない。例えば、コンテンツデータはオーディオデータやテキストデータであってもよいし、それらの組み合わせであってもよい。また、セグメントは所定時間ごとのコンテンツデータでなくてもよく、例えば、所定データ量ごとのコンテンツデータであってもよい。
【００４４】
セグメント管理部３０３は、セグメントをＭＰ４やＭ２ＴＳなどのコンテンツデータ格納フォーマットにフォーマットする（Ｓ５０２）。なお、コンテンツデータ格納フォーマットはこれに限定されない。また、コンテンツデータがすでにフォーマットされている場合は、この処理は必要ない。
【００４５】
セグメント管理部３０３は、Ｓ５０３において未処理のセグメント（ＲＡＭ２０４または記憶部２０６への保存処理が完了していないセグメント）が存在するか否かを判定する。未処理のセグメントが存在すると判定された場合Ｓ５０４に進む。一方、未処理のセグメントが存在しないと判定された場合で、且つ、撮影部２０５の撮影が終了していれば、図５の処理は終了する。未処理のセグメントが存在しないと判定されたが、撮影部２０５の撮影が終了していなければ、Ｓ５００の処理に戻ることになる。
【００４６】
セグメント管理部３０３は、ＲＡＭ２０４内のセグメント用バッファが一杯かどうかを判定する（Ｓ５０４）。セグメント管理部３０３は、ＲＡＭ２０４内のセグメント用バッファが一杯であるか否かを以下の項目を用いて判定することが可能である。すなわち、セグメント管理部３０３は、ＲＡＭ２０４のサイズ、１つ１つのセグメントの平均サイズの情報を用いてＲＡＭ２０４内のセグメント用バッファが一杯であるか否かを判定することが可能である。また、セグメント管理部３０３は、ＲＡＭ２０４のサイズとセグメントの平均サイズに加えて、セグメント保存時点から通信装置１０１が再生装置１０２に低遅延の送信を保証する時間の情報を用いてセグメント用バッファが一杯であるか否かを判定してもよい。ここで留意しておくべき点として、ＲＡＭ２０４に保持しているセグメントは記憶部２０６に保持しているセグメントに比べ、高速にアクセス可能であるため低遅延に送信することが可能になる。
【００４７】
Ｓ５０４にて、ＲＡＭ２０４内のセグメント用バッファが一杯でないと判定された場合、Ｓ５０９にて処理対象のセグメントをＲＡＭ２０４内のセグメント用バッファに保存し、Ｓ５０３に戻り、次のセグメントを処理対象としてＳ５０４以降の処理を実行する。一方、Ｓ５０４にて、ＲＡＭ２０４内のセグメント用バッファが一杯であると判定された場合、Ｓ５０５にてＲＡＭ２０４内の最も古いセグメントを記憶部２０６に退避する。つまり、セグメント管理部３０３は、Ｓ５０５において、ＲＡＭ２０４のセグメント用バッファに記憶された複数のセグメントのうち、最も古いセグメントを記憶部２０６に移す処理を実行する。
【００４８】
また、セグメント管理部３０３は、記憶部２０６内のセグメント用バッファが一杯かどうかを判定する（Ｓ５０６）。セグメント管理部３０３は、記憶部２０６内のセグメント用バッファが一杯であるか否かを以下の項目を用いて判定することが可能である。すなわち、セグメント管理部３０３は、記憶部２０６のサイズ、１つ１つのセグメントの平均サイズの情報を用いて記憶部２０６内のセグメント用バッファが一杯であるか否かを判定することが可能である。
【００４９】
また、セグメント管理部３０３は、記憶部２０６のサイズとセグメントの平均サイズに加えて、セグメント保存時点から通信装置１０１が再生装置１０２に送信を保証する時間の情報を用いてセグメント用バッファが一杯であるか否かを判定してもよい。ここで留意しておくべき点として、記憶部２０６に保持してあるセグメントの送信には上述の通り、ＲＡＭ２０４内に保持してあるセグメントの送信に比べて時間を要する。このため遅延は増大してしまうが、ＲＡＭ２０４のサイズが小さく、多くのセグメントをＲＡＭ２０４内に保存できないような場合には記憶部２０６を利用することが有用である。
【００５０】
なお、ＲＡＭ２０４からのセグメント配信で実現される、低遅延の配信のみを実施する場合は、Ｓ５０４にてＲＡＭ２０４内のセグメント用バッファが一杯であると判定された場合に、ＲＡＭ２０４内の最も古いセグメントを削除する処理を行えば良い。
【００５１】
Ｓ５０６にて記憶部２０６内のセグメント用バッファが一杯であると判定された場合、セグメント管理部３０３は、記憶部２０６内のセグメント用バッファに保存されたセグメントのうち、最も古いセグメントを削除（上書き可能に）する（Ｓ５０８）。Ｓ５０６にて記憶部２０６内のセグメント用バッファが一杯でないと判定された場合、セグメント管理部３０３は、Ｓ５０５で退避されたセグメントを記憶部２０６内のセグメント用バッファに保存する（Ｓ５０７）。
【００５２】
Ｓ５０４でＲＡＭ２０４のセグメント用バッファが一杯でないと判定された場合、及び、Ｓ５０７又はＳ５０８の処理が完了した場合、Ｓ５０９に進む。セグメント管理部３０３は、Ｓ５０９において、処理対象のセグメントをＲＡＭ２０４内のセグメント用バッファの空領域に保存する。Ｓ５０９の処理が完了すると、次のセグメントを処理対象セグメントとして、Ｓ５０３以降の処理を実行する。
【００５３】
＜生成するプレイリストの記述内容＞
次に本実施形態のプレイリスト管理部３０４が生成するプレイリストの例を図６〜図８を用いて説明する。本実施形態ではプレイリストの記述フォーマットとしてＭＰＥＧ−ＤＡＳＨで規定されているＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）が用いられる場合の例を説明する。なお、プレイリストの記述フォーマットはＭＰＥＧ−ＤＡＳＨのＭＰＤに限定されるものではなく、これに準ずるものでも良い。また、図６〜図８では説明を簡潔にするために、プレイリストに必要な情報を一部省略してあることに留意されたい。
【００５４】
１つ目の記述例について、図６及び図７を用いて説明する。図６と図７で示すプレイリストはＳｅｇｍｅｎｔＬｉｓｔ方式（セグメントリスト方式）を用いた記述例である。ＳｅｇｍｅｎｔＬｉｓｔ方式では、配信可能なセグメントのリストを記述したプレイリストが生成される。６０２はセグメント１を取得するためのＵＲＬである。プレイリスト６０１を取得した再生装置１０２は、ＵＲＬ６０２にアクセスすることで、通信装置１０１に対してセグメント１を要求することが可能である。すなわち、図６のプレイリスト６０１は、セグメント１（第１セグメント）を再生装置１０２（クライアント）に要求させるためのアクセス情報（ＵＲＬ６０２）を示すリスト情報である。なお、再生装置１０２は、取得したリスト情報に含まれるアクセス情報に必ずアクセスしなければならないわけではない。
【００５５】
また、図６において、ＥｘａｍｐｌｅＳｏｕｒｃｅで示されるホスト名は通信装置１０１の識別情報を示す。ただし、ホスト名に限らず、通信装置１０１を特定するものであれば、ＩＰアドレスなどを記載しても良い。６０３で示すｍｉｎｉｍｕｍＵｐｄａｔｅＰｅｒｉｏｄはプレイリストの更新タイミングを通知するための値であり、再生装置１０２はこの間隔でプレイリスト取得要求を送信することが期待される。
【００５６】
６０４で示すａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅはこのプレイリストが有効となる時刻（有効開始時刻）を示している。再生装置１０２は、有効開始時刻６０４と現在の時刻を比較することで、現在、通信装置１０１が送信可能なセグメントを知ることができる。言い換えると、有効開始時刻は、通信装置１０１がコンテンツデータを入力開始（生成開始）する時刻であると言うこともできる。６０５で示すｔｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈはサーバ側（通信装置１０１）からセグメントの配信を保証する期間（配信保証期間）についての情報を示す。この情報は図５で説明したセグメントを保存しておくセグメント用バッファの数によって規定することが可能である。
【００５７】
なお、上記のプレイリスト６０１は、図９におけるＭ９０１で生成されるプレイリストである。図９のシーケンスの詳細は後述するが、Ｍ９０１は、セグメント１が入力（生成）される前のタイミングである。すなわち、本実施形態のプレイリスト管理部３０４は、セグメント１が入力完了する前に、セグメント１を再生装置１０２に要求させるための第１情報を示すリスト情報（プレイリスト６０１）を生成する。
【００５８】
図７に示すプレイリスト７０１は、図９におけるＭ９０７において更新されるプレイリストである。図７において、７０２は通信装置１０１内で生成されるセグメント２を再生装置１０２に要求させるためのＵＲＬである。図９のＭ９０７は、セグメント１の入力（生成）が完了したタイミングであり、セグメント１に続くセグメント２の入力（生成）は完了していない。すなわち、プレイリスト管理部３０４は、セグメント２の入力が未完了のタイミングで、第１セグメントのアクセス情報と第２セグメントのアクセス情報とをそれぞれ記述したリスト情報（プレイリスト７０１）を生成する。なお、本実施形態では、セグメントの生成順序を示す番号のみが異なるＵＲＬをアクセス先としている。例えば、セグメント１のアクセス情報を示すＵＲＬと、セグメント２のアクセス情報を示すＵＲＬの違いは、ＵＲＬの末尾がＳｅｇｍｅｎｔ１であるかＳｅｇｍｅｎｔ２であるかの違いのみである。このような構成により、プレイリスト管理部３０４は、入力（生成）が未完了のセグメントを再生装置１０２に要求させるためのリスト情報を容易に生成することが可能である。ただし、アクセス情報の生成方法は、任意である。このようにＳｅｇｍｅｎｔＬｉｓｔ方式では、次に配信可能になるセグメントのアクセス情報をリスト情報に追加することで図４のＳ４０２の処理を実行する。
【００５９】
２つ目の記述例について、図８を用いて説明する。図８ではＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ方式（セグメントテンプレート方式）のプレイリストについて記述例を説明する。ＭＰＥＧ−ＤＡＳＨのＭＰＤフォーマットではＳｅｇｍｅｎｔＴｅｍｐｌａｔｅを用いてＭＰＤのサイズを低減することができる。例えば図７のプレイリスト７０１で示したＳｅｇｍｅｎｔＬｉｓｔ方式の記述方法では、セグメントの数が増えるに従ってＳｅｇｍｅｎｔＬｉｓｔの行を追加していく必要があるため、ＭＰＤのサイズが増大してしまう。これをＳｅｇｍｅｎｔＴｅｍｐｌａｔｅでＵＲＬをテンプレート化することで、セグメントの数が多い場合でもＭＰＤのサイズを抑えることができる。
【００６０】
図８に示す８０１はセグメントテンプレート方式で記述されたプレイリストの具体例である。８０２に示す箇所でＵＲＬのテンプレートを記述している。再生装置１０２は、＄Ｎｕｍｂｅｒ＄の部分にセグメントの番号を置換することで所望のセグメントに対するＵＲＬを特定できる。ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ方式においては、ＳｅｇｍｅｎｔＬｉｓｔ方式と異なり、セグメント取得のためのアクセスＵＲＬをクライアント（再生装置１０２）がテンプレートに基づいて特定できる。上記の例においては、クライアント（再生装置１０２）は、＄Ｎｕｍｂｅｒ＄の位置に１が挿入されたＵＲＬに対してアクセスすることでセグメント１を要求できる。また、クライアントは、＄Ｎｕｍｂｅｒ＄の位置に２が挿入されたＵＲＬに対してアクセスすることでセグメント２を要求できる。
【００６１】
すなわち、プレイリスト管理部３０４は、テンプレートを含むリスト情報（プレイリスト）を生成する。そして、再生装置１０２は、セグメント１の識別情報（１）をテンプレートに挿入することでセグメント１を要求するための第１情報（第１ＵＲＬ）を特定可能である。また、再生装置１０２は、セグメント２の識別情報（２）をテンプレートに挿入することで、セグメント２を要求するための第２情報（第２ＵＲＬ）を特定可能である。なお、セグメント１は、第１期間に取得されたコンテンツデータであり、セグメント２は、第１期間に続く第２期間に取得されたコンテンツデータである。本実施形態においては、第１期間と第２期間は連続する期間である。
【００６２】
セグメントテンプレート方式では、現在配信可能なセグメントの番号については、再生装置１０２が８０５、８０６と現在時刻の情報、及び、８０３で示されるピリオドの対応する時間、８０４で示される開始番号から判定できる。よって、通信装置１０１内でこれらの値を変更することで、未入力（未生成）のセグメントをあたかも配信可能なようにプレイリストを生成することが可能となる。
【００６３】
なお、８０５は、図６の有効開始時刻６０４に対応する情報であり、プレイリスト８０１が有効になる時刻が示されている。また、８０６は、図６の配信保証期間６０５に対応する情報であり、サーバ側（通信装置１０１）からセグメントの配信を保証する期間が示されている。例えば、配信保証期間８０６が４秒である場合、通信装置１０１がセグメント１を生成してから４秒間が経過するまでに、再生装置１０２からセグメント１の要求を受信した場合、セグメント１が再生装置１０２へ送信される。一方で、通信装置１０１がセグメント１を生成してから５秒が経過してから、セグメント１の要求を受信した場合、セグメント１の送信は保証されない。また、図８の８０３は、プレイリスト８０１が有効である期間を示している。図８の例では、１０．００Ｍと記述されているため、有効開始時刻８０５で示された時刻から１０分間は、当該プレイリスト８０１が有効であることが示されている。また、８０４は、テンプレート中の変数の最初の値を示している。図８の例では「１」と記述されているため、最初のセグメントを取得するためには＄Ｎｕｍｂｅｒ＄に「１」を代入すればよいことがわかる。また、持続時間８０７は、１つのセグメントに対応するコンテンツデータの長さ（時間）を示している。図８の例では、持続時間８０７に「２．００Ｓ」と記述されているので、各セグメントの長さが２秒であることがわかる。
【００６４】
再生装置１０２が図８に示すようなプレイリスト８０１を取得し、さらに現在時刻が２０ＸＸ−ＸＸ−ＸＸＴ０１：００：１０であった場合を考える。この場合において、有効開始時刻８０５で示される時刻２０ＸＸ−ＸＸ−ＸＸＴ０１：００：００から現在時刻までに１０秒が経過していることがわかる。また、持続時間８０７によれば各セグメントが２秒間のデータであるため、再生装置１０２は、開始番号１から始めて５つのセグメント１、２、３、４、５が配信可能であると判定できる。ただし、配信保証期間８０６で示される配信保証期間は、十分に長いものとする。
【００６５】
この場合において、例えば、有効開始時刻８０５を２０ＸＸ−ＸＸ−ＸＸＴ００：５９：５８に変更すれば、セグメント１〜６の６つのセグメントが配信可能であると再生装置１０２に判定させることが可能である。すなわち、本実施形態のセグメントテンプレート方式のプレイリストには、当該プレイリストが有効になる時刻を示す有効開始時刻を記述可能である。そして、プレイリスト管理部３０４は、セグメント管理部３０３がコンテンツデータを入力開始（生成開始）する時刻よりも前の時刻をプレイリストの有効開始時刻として含むプレイリストを生成する。このようにすることで、セグメントテンプレート方式のプレイリストを受信した再生装置１０２が、通信装置１０１において未入力（未生成）のセグメントに対して取得要求を送信できるようになる。
【００６６】
このように未入力のセグメントを配信可能であるかのようにプレイリストに記述することで、再生装置１０２からの取得要求をより早いタイミングで送信できるようになる。この構成により、通信装置１０１がセグメントを取得してから、当該セグメントを再生装置１０２（クライアント）が取得するまでの時間を低減できる。また、再生装置１０２側の処理という観点では、特別な処理は必要なく、ＭＰＥＧ−ＤＡＳＨに準拠した汎用的なクライアントでよいことに留意されたい。
【００６７】
なお、上記の実施形態では、未入力の１つのセグメントのアクセス情報を示すプレイリストを生成する場合の例を中心に説明したが、プレイリスト管理部３０４は、未入力の複数のセグメントのアクセス情報を含むプレイリストを生成することも可能である。例えば、セグメント１を入力済みで、セグメント２以降のセグメントの入力が未完了の場合において、プレイリスト管理部３０４は、セグメント２と３を再生装置１０２に要求させるための第２及び第３情報を示すプレイリストを生成することが可能である。
【００６８】
また、未入力のセグメントのアクセス情報を、いくつプレイリストに記述するかを、通信環境やクライアント（再生装置１０２）の状態に応じて選択するようにしてもよい。例えば、ネットワークの通信速度が低い場合は、通信速度が高い場合よりも、多くの未入力のセグメントのアクセス情報を含むプレイリストを生成し、再生装置１０２に対して送信することが可能である。このようにすれば、再生装置１０２が通信装置１０１からのプレイリストの取得に時間がかかるような通信環境においても、低遅延でコンテンツデータの再生ができる。また、プレイリストをやり取りする回数を少なくすることも可能である。
【００６９】
また、クライアント（再生装置１０２）の処理能力が低い場合は、より多くの未入力のセグメントのアクセス情報を含むプレイリストを生成し、再生装置１０２に対して送信することが可能である。このようにすれば、プレイリストの取得に関する処理負荷を低減できる。
【００７０】
また、本実施形態では、通信装置１０１からコンテンツデータを取得するクライアントが再生装置１０２である場合の例を中心に説明しているが、これに限らず、例えば、コンテンツデータを記録するレコーダ等であってもよい。
【００７１】
＜コンテンツ配信シーケンス＞
図９を用いてコンテンツ配信を行う際のデータ通信装置１０１と再生装置１０２間のやりとりのシーケンスを説明する。プレイリストの記述方式としては上述したＳｅｇｍｅｎｔＬｉｓｔ方式を用いる場合について記述する。
【００７２】
Ｍ９０１において、通信装置１０１は、再生装置１０２からプレイリスト取得要求を受信すると、コンテンツデータの送信が可能な送信モードに移行する。ただし、送信モードへの移行は、プレイリスト取得要求の受信とは別のトリガーで行われてもよい。
【００７３】
通信装置１０１は送信モードに移行したあと、プレイリストを生成する（Ｍ９０２）。Ｍ９０２で生成されるプレイリストは、例えば、図６で示すプレイリスト６０１である。図６に示すように、プレイリスト６０１は、セグメント１を再生装置１０２に要求させるためのアクセス情報（第１情報）が含まれている。しかしながら図９に示すように、セグメント１が生成されるのは、Ｍ９０５のタイミングである。このように、本実施形態の通信装置１０１のプレイリスト管理部３０４は、セグメント１の入力が完了する前に、セグメント１を再生装置１０２に要求させるためのアクセス情報（第１情報）を示すプレイリスト（リスト情報）を生成する。
【００７４】
そして、通信装置１０１のプレイリスト管理部３０４は、Ｍ９０２で生成したプレイリストを再生装置１０２に対して送信する（Ｍ９０３）。すなわち、通信装置１０１のプレイリスト管理部３０４は、セグメント１を再生装置１０２に要求させるためのリスト情報を、セグメント１がセグメント管理部３０３によって入力完了される前に再生装置１０２に対して送信する。
【００７５】
プレイリスト６０１を受信した再生装置１０２は、プレイリスト６０１をパースし、セグメント１を要求するためのコンテンツ取得要求を送信する（Ｍ９０４）。そして、セグメント１を要求するためのコンテンツ取得要求を受信した通信装置１０１のセグメント管理部３０３は、セグメント１を再生装置１０２に対して送信する（Ｍ９０６）。図９に示すように、通信装置１０１は、セグメント１を要求するためのコンテンツ取得要求を受信したタイミングでセグメント１を入力完了していない場合、セグメント１の入力完了まで待機する。ただし、待機時間が所定時間を超えると判定される場合は、セグメント管理部３０３は、再生装置１０２に対してエラーメッセージを送信することが可能である。
【００７６】
また、プレイリスト管理部３０４は、セグメント１の入力完了後、プレイリスト６０１を更新して、プレイリスト７０１を生成する（Ｍ９０７）。図７に示すように、プレイリスト７０１には、セグメント１のアクセス情報と共に、セグメント２のセグメントのアクセス情報が示されている。また、図９に示すように、Ｍ９０７のタイミングでは、セグメント２はセグメント管理部３０３によって入力されていない。このように、本実施形態のプレイリスト管理部３０４は、入力済みのセグメント１のアクセス情報（第１情報）と共に、入力が未完了のセグメント２のアクセス情報（第２情報）とを示すリスト情報（プレイリスト７０１）を生成する。そして、プレイリスト管理部３０４は、生成したプレイリスト７０１を再生装置１０２に対して送信する。
【００７７】
なお、通信装置１０１は、プレイリスト７０１を受信した再生装置１０２からセグメント２を要求するためのコンテンツ取得要求を受信した場合、セグメント２を入力してから当該セグメント２を再生装置１０２に対して送信する。即ち、セグメント管理部３０３は、プレイリスト７０１を受信したクライアント（再生装置１０２）からセグメント２のコンテンツデータの要求を受信した場合、プレイリスト７０１の生成後に入力されたセグメント２を再生装置１０２に対して送信する。
【００７８】
ただし、セグメント２の取得要求の受信から、セグメント管理部３０３がセグメント２を入力するまでに要する待機時間が所定時間を超えると判定される場合、セグメント管理部３０３は、再生装置１０２にエラーメッセージを送信するようにしてもよい。
【００７９】
＜未取得セグメントに対する取得要求時の処理＞
通信装置１０１が再生装置１０２からコンテンツデータ取得要求を受信した場合の動作について、図１０を用いて説明する。図１０の処理は、通信装置１０１のＣＰＵ２０２が、図１０の処理の実行に必要なプログラムをＲＯＭ２０３から読み出して実行することにより実現される。ただし、図１０の処理が専用のハードウェアによって行われるようにしてもよい。また、図１０の処理は、再生装置１０２からプレイリスト取得要求を受信すると開始される。ただし、図１０の開始のタイミングは上記のタイミングに限らない。
【００８０】
制御部３０２は、再生装置１０２からコンテンツデータ取得要求を受信すると、当該要求が、すでに通信装置１０１によって入力済みのセグメントに対する取得要求であるか、未入力のセグメントに対する取得要求であるかを判定する（Ｓ１０００）。入力済みのセグメントに対する取得要求であると判定された場合、Ｓ１００３に進み、ＲＡＭ２０４または記憶部２０６のセグメント用バッファに保存されたセグメントを読み出して再生装置１０２に送信する。一方、入力が未完了のセグメントに対する取得要求であると判定された場合、Ｓ１００１に進む。
【００８１】
Ｓ１００１において、制御部３０２は、再生装置１０２から要求された未入力のセグメントが所定時間内に入力完了できるか否かを判定する。具体的には、制御部３０２は、セグメント管理部３０３に問い合わせを行うことで、未入力のセグメントが入力されるまでにかかる時間を取得し、当該時間が所定時間よりも長いか否かを判定する。なお、セグメント管理部３０３は、セグメントが生成される間隔の情報に基づいて、次のセグメントの入力完了までにかかる時間を特定可能である。また、セグメント管理部３０３は、セグメントの入力が完了した（撮影部２０５が撮影を終了した）場合は、その旨を制御部３０２に対して通知する。
【００８２】
未入力のセグメントが所定時間内に入力完了できると判定された場合、制御部３０２は、セグメント管理部３０３が当該セグメントを入力完了するまで待機し（Ｓ１００２）、当該セグメントを再生装置１０２へ送信する（Ｓ１００３）。一方、再生装置１０２から要求された未入力のセグメントが所定時間内に入力完了できないと判定された場合、制御部３０２は、再生装置１０２に対してエラーメッセージを送信する。
すなわち、通信装置１０１は、コンテンツデータの要求の受信から、当該コンテンツデータの入力完了までの時間（待機時間）に応じた時間情報を判定する。そして、通信装置１０１は、時間情報が所定時間より長い時間に対応する場合、再生装置１０２に対してエラーメッセージを送信する。一方、通信装置１０１は、時間情報が所定時間より短い時間に対応する場合、再生装置１０２に対してエラーメッセージを送信せず、当該コンテンツデータの入力が完了してから再生装置１０２に対してコンテンツデータを送信する。このようにすれば、例えば、撮影部２０５の撮影が終了したことによって、新たなセグメントが取得されなくなった状況において、再生装置１０２が当該新たなセグメントを待ち続けるような状況を防止できる。
【００８３】
なお、図１０の説明では、未入力のセグメントが入力完了されるまでの待機時間が所定時間以上であれば、エラーメッセージを送信する構成を説明したが、これに限らない。例えば、通信装置１０１の制御部３０２は、クライアント（再生装置１０２）からの取得要求に対応するセグメントの入力が完了していない場合は、待機時間に関わらず、エラーメッセージを送信するようにしてもよい。また、セグメント管理部３０３は、エラーメッセージの送信に限らず、音やランプなどによってエラーを通知してもよい。
【００８４】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００８５】
２０２  ＣＰＵ
２０３  ＲＯＭ
２０４  ＲＡＭ
１０１  データ通信装置
２０５  撮影部
２０６  記憶部
２０７  記憶部
３０１  Ｗｅｂサーバ部
３０２  制御部
３０３  セグメント管理部
３０４  プレイリスト管理部
３０５  コンテンツ生成部
【図１】
2016091436.tif 000003
【図２】
2016091436.tif 000004
【図３】
2016091436.tif 000005
【図４】
2016091436.tif 000006
【図５】
2016091436.tif 000007
【図６】
2016091436.tif 000008
【図７】
2016091436.tif 000009
【図８】
2016091436.tif 000010
【図９】
2016091436.tif 000011
【図１０】
2016091436.tif 000012