(57)【要約】      （修正有）【課題】サーバーで録画されるコンテンツを配信する際の利用者の利便性を向上するコンテンツ配信サーバー、コンテンツ再生装置を提供する。【解決手段】サーバー１０は、コンテンツの録画を行う録画制御部と、コンテンツの録画が完了する前に、コンテンツの内容を示す属性情報を作成する属性情報管理部と、コンテンツの録画中に、外部機器（クライアント）から録画中のコンテンツの属性情報の要求があった場合、属性情報を送信する属性情報提供部を有する。属性情報記憶部は、コンテンツが所定の再生時間分録画される毎に、録画された前記コンテンツの累積録画時間を、コンテンツの総再生時間に係る属性情報として記憶する。【選択図】図２
2017143329.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツの録画を行う録画制御部と、
前記コンテンツの録画中に、前記コンテンツの内容を示す属性情報を記憶する属性情報記憶部と、
前記コンテンツの録画中に、外部機器から録画中の前記コンテンツの前記属性情報の要求があった場合、前記属性情報を送信する属性情報提供部と、を有することを特徴とするコンテンツ配信サーバー。
【請求項２】
前記属性情報記憶部は、前記コンテンツが所定の再生時間分録画される毎に、前記録画された前記コンテンツの累積録画時間を、前記コンテンツの総再生時間に係る属性情報として記憶する、ことを特徴とする請求項１に記載のコンテンツ配信サーバー。
【請求項３】
前記属性情報記憶部は、前記コンテンツの録画中に、前記コンテンツの総再生時間を前記属性情報として記憶しておき、
前記コンテンツの録画完了後、前記コンテンツの内容に変更があれば、前記属性情報を更新する、ことを特徴とする請求項１に記載のコンテンツ配信サーバー。
【請求項４】
前記属性情報記憶部は、前記属性情報として、通常の再生以外の再生に関する情報を拡張情報として記憶する、ことを特徴とする請求項１に記載のコンテンツ配信サーバー。
【請求項５】
前記属性情報の送信後、前記外部機器から録画中のコンテンツの配信要求があった場合、前記配信要求があったコンテンツの録画済みのデータの配信を開始するサービス提供部を、有することを特徴とする請求項１から請求項４のいずれか一項に記載のコンテンツ配信サーバー。
【請求項６】
前記サービス提供部は、前記外部機器からのサーチ要求により、録画済みのコンテンツのシーンより後のシーンをサーチ要求された場合、前記外部機器にエラーを通知する、ことを特徴とする請求項５に記載のコンテンツ配信サーバー。
【請求項７】
前記サービス提供部は、前記外部機器からのサーチ要求により、録画済みのコンテンツのシーンより後のシーンを要求された場合、前記外部機器に、録画済みの前記コンテンツのシーンと、前記シーンの時間情報とを配信する、ことを特徴とする請求項５に記載のコンテンツ配信サーバー。
【請求項８】
前記サービス提供部は、録画済みの前記コンテンツの情報にダミー情報を付与して、前記コンテンツとして配信する、ことを特徴とする請求項５から請求項７のいずれか一項に記載のコンテンツ配信サーバー。
【請求項９】
サーバーにコンテンツの配信を要求するコンテンツ再生装置であって、
前記コンテンツの内容を示す属性情報を要求する属性情報取得部と、
前記要求に応じて取得された前記属性情報に所定の拡張情報が付与されている場合、前記拡張情報をもとに、前記サーバーに対して前記コンテンツの配信に伴う処理を要求するサービス要求部と、を有することを特徴とするコンテンツ再生装置。
【請求項１０】
前記サービス要求部は、前記拡張情報に基づいて、通常の再生以外の再生の可否を判定して前記コンテンツの配信に伴う処理を要求する、ことを特徴とする請求項９に記載のコンテンツ再生装置。
【請求項１１】
前記サービス要求部は、コンテンツの配信の開始位置が録画済みかを判断する、ことを特徴とする請求項９または請求項１０に記載のコンテンツ再生装置。
【請求項１２】
前記サービス要求部は、終了予定時刻と、現在時刻とに基づいてコンテンツの配信の開始位置が録画済みかを判断する、ことを特徴とする請求項１１に記載のコンテンツ再生装置。
【請求項１３】
前記サービス要求部は、コンテンツの再生を行うときに、録画済み範囲を確認する、ことを特徴とする請求項１１に記載のコンテンツ再生装置。
【請求項１４】
前記サービス要求部は、前記録画済み範囲を確認して再生画像上に表示する、ことを特徴とする請求項１３に記載のコンテンツ再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＰｎＰ ＡＶに対応するプロトコルに基づくコンテンツの配信に関する。
【背景技術】
【０００２】
ＤＬＮＡ（Digital Living Network Alliance）等のＵＰｎＰ  ＡＶの規格に対応するサーバー（コンテンツ配信サーバー）は、自機が配信可能なコンテンツのメタ情報（属性情報とも呼ぶ）を管理している。このメタ情報には、ＸＭＬ（eXtensible Markup Language）といったマークアップ言語で作成されており、コンテンツのタイトル、放送時間、このコンテンツの再生に必要な情報が記憶されている。サーバーはクライアント（コンテンツ再生装置）からブラウズの要求があった場合、クライアントに対してこのメタ情報の一部又は全部を配信することで、クライアントにサーバーが提供可能なコンテンツの内容を通知する（例えば、特許文献１参照）。
【０００３】
メタ情報にはコンテンツの総再生時間等が含まれるため、従来では、サーバーはメタ情報をコンテンツの録画が完了した時点で作成している。このメタ情報を受信したクライアントは、正確なコンテンツの総再生時間を判断することができ、この再生情報を特定のシーンからの配信を要求するためのサーチ要求や、ＵＩ画面の表示に利用している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１２３１４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来では、メタ情報はコンテンツの録画が完了した後に作成されていたため、コンテンツの録画中は、サーバーからクライアントにコンテンツを配信することができなかった。そのため、利用者はサーバーでのコンテンツの録画が完了するまで、このコンテンツの配信を受けることができなかった。
本発明は、上記課題に鑑みてなされたものであり、サーバーで録画されるコンテンツを配信する際の利用者の利便性を向上することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために本発明の一態様では、コンテンツの録画を行う録画制御部と、前記コンテンツの録画が完了する前に、前記コンテンツの内容を示す属性情報（メタ情報）を作成する属性情報記憶部と、前記コンテンツの録画中に外部機器から録画中の前記コンテンツの前記属性情報の要求があった場合、前記属性情報を送信する属性情報提供部と、を有する。
【０００７】
「コンテンツ」は、テレビジョン放送波や、インターネット等の広域ネットワークを介して配信される映像、音声等の情報を意味する。
「メタ情報」としての「属性情報」は、コンテンツのタイトル、記録場所、サイズ、再生に要する情報等の情報を意味しており、XML(eXtensible markup Language)といった周知のマークアップ言語で作成されている。
「コンテンツの録画が完了する前に、前記コンテンツの内容を示す属性情報を作成する」とは、コンテンツの録画完了に伴うコンテンツの総再生時間等が確定する前に、このコンテンツの属性情報を作成することを意味する。
【０００８】
上記のように構成された発明では、コンテンツの録画完了を待つことなく録画中のコンテンツの属性情報ＭＤ（メタ情報）が作成されるため、この属性情報ＭＤをもとに、サーバーとクライアント（外部機器）との間でブラウズの要求や、配信要求を行うことができる。そのため、利用者のコンテンツの配信に係る利便性を高めることができる。
【図面の簡単な説明】
【０００９】
【図１】一例としてのコンテンツ配信システム１を構成する各装置を示す図。
【図２】ＤＭＳとして機能するサーバー１０のブロック構成図。
【図３】ＤＭＰとして機能するクライアント２０のブロック構成図。
【図４】サーバー１０とクライアント２０との間で行われる処理を説明するシーケンス図。
【図５】メタ情報ＭＤを説明する図。
【図６】メタ情報管理部１５２が実行するメタ情報更新処理を説明するフローチャート。
【図７】コンテンツＣＯＤの累積録画時間とメタ情報管理部１５２が更新するメタ情報ＭＤとの関係を説明する図。
【図８】図４のステップＳ６において、クライアント２０が実行する再生処理を説明する図。
【図９】メタ情報管理部１５２が実行するメタ情報更新処理を説明するフローチャート。
【図１０】コンテンツＣＯＤの累積録画時間とメタ情報管理部１５２が更新するメタ情報ＭＤとの関係を説明する図。
【図１１】図４のステップＳ６においてクライアント２０がサーチ要求を行った場合の処理と、サーバー１０におけるクライアント２０からのサーチ要求に対する処理を説明するフローチャート。
【図１２】クライアント２０とサーバー１０との処理を説明する図。
【図１３】図４のステップＳ６においてクライアント２０がアクションのサーチ要求を行った場合の処理と、サーバー１０におけるクライアント２０からのサーチ要求に対する処理を説明するフローチャート。
【図１４】図４のステップＳ６においてクライアント２０がサーチ要求を行った場合の処理と、サーバー１０におけるクライアント２０からのサーチ要求に対する処理を説明するフローチャート。
【図１５】クライアント２０とサーバー１０との処理を説明する図。
【図１６】メタ情報（拡張メタ情報ＭＤ２）を示す図。
【図１７】この拡張メタ情報ＭＤ２を用いたクライアント２０の動作を説明する図。
【図１８】コンテンツデータを説明する図。
【図１９】サーバー１０の配信処理を示すフローチャートである。
【図２０】録画中のitem情報の一例を示している。
【図２１】ＤＭＰであるクライアント２０のトリックプレイ処理のフローチャートである。
【図２２】ＤＭＰであるクライアント２０の再生処理のフローチャートである。
【図２３】クライアント２０とサーバー１０間の通信を示している。
【図２４】ＤＭＰであるクライアント２０の再生処理のフローチャートである。
【図２５】ＤＭＰであるクライアント２０の再生処理のフローチャートである。
【図２６】コンテンツの配信を受けているときにタイムバーをＧＵＩとして表示する画面例を示している。
【図２７】コンテンツの配信を受けているときにタイムバーをＧＵＩとして表示する画面例を示している。
【発明を実施するための形態】
【００１０】
以下、下記の順序に従って本発明の実施形態を説明する。
１．第１の実施形態：
（１）コンテンツ配信システムの構成
（２）コンテンツ配信方法
（３）作用・効果
２．第２の実施形態：
２．２．変形例：
３．第３の実施形態：
４．第４の実施形態：
５．第５の実施形態：
６．第６の実施形態：
７．その他の実施形態：
【００１１】
１．第１の実施形態：
（１）コンテンツ配信システムの構成
図１は、一例としてのコンテンツ配信システム１を構成する各装置を示す図である。コンテンツ配信システム１は、ＤＬＮＡのＤＭＳとして機能するサーバー（コンテンツ配信サーバー）１０と、ＤＭＰとして機能するクライアント（コンテンツ再生装置であり、外部機器に相当する）２０と、を備えている。図１では、サーバー１０、クライアント２０は、ネットワークＮに有線又は無線を介して接続されている。サーバー１０とクライアント２０とはＤＬＮＡに対応する装置であり、ネットワークＮを介してサーバー１０からクライアント２０にコンテンツの配信が行われる。ネットワークＮは、ＬＡＮや、インターネット、電話回線網である。無論、ネットワークＮがインターネットである場合、サーバー１０やクライアント２０は、ルーターＬＵ、アクセスポイントＡＰ、不図示の電話回線網を介してネットワークＮに接続されることとなる。
【００１２】
図２は、ＤＭＳとして機能するサーバー１０のブロック構成図である。図２に示すサーバー１０は、動画や音声等のコンテンツを外部記憶装置に記憶するレコーダーとして機能する。サーバー１０は、テレビジョン放送や、不図示の再生装置からの外部入力を受信するデータ入力部１１と、コンテンツやこのコンテンツのメタ情報（属性情報）ＭＤを記憶する外部記憶装置１２と、ユーザーの操作入力等を受け付ける操作入力部１３と、ネットワークＮに接続するためのネットワークＩＦ１４と、これらを統合的に制御する制御部１５とを備えている。
【００１３】
データ入力部１１は、チューナー１１１や、入力端子１１２を備えている。チューナー１１１は、地上波、衛星放送波などのテレビ放送、ラジオ放送、データ放送を受信する。入力端子１１２は、不図示の外部装置からのデジタル入力やアナログ入力を受け付ける。
【００１４】
外部記憶装置１２は、ＨＤＤ（Hard Disk Drive）等の磁気メモリや、ＳＳＤ等の半導体メモリにより構成されている。外部記憶装置１２に記憶されているコンテンツは、例えば、データ入力部１１を介してサーバー１０で録画されたテレビジョン放送信号である。メタ情報ＭＤは、外部記憶装置１２に記憶されているコンテンツのタイトル、録画日時、再生時間、記録場所（ＵＲＬ）等を示すＸＭＬデータである。なお、メタ情報ＭＤの具体的な構成については後述する。
【００１５】
操作入力部１３は、不図示の操作キーや、リモコン装置からの入力を受け付ける受信部を備えている。
ネットワークＩＦ１４は、ネットワークＮに接続するためのＬＡＮカード、ＮＩＣ（Network Interface Card）等により構成されている。
【００１６】
制御部１５は、ＳｏＣ等の集積回路であり、デコーダ、エンコーダ、演算中枢として機能するＣＰＵ、このＣＰＵが実行するプログラムやデータが記憶されたＲＯＭ、ＣＰＵのワークエリアとして機能するＲＡＭを備えている。また、ＣＰＵがＲＯＭに記憶されたプログラムを実行することで、制御部１５は、録画制御部１５１、メタ情報管理部（属性情報管理部に相当、以下同様）１５２、サービス提供部１５３を機能的に備えている。
【００１７】
エンコーダは、データ入力部１１を介して取得されたコンテンツデータをＭＰＥＧ規格に対応する圧縮形式で圧縮変換する。変換されたコンテンツデータは、外部記憶装置１２に記録（録画）される。デコーダは、外部記憶装置１２に記憶されたコンテンツデータの圧縮変換を解除して出力する際に使用される。
【００１８】
録画制御部１５１は、コンテンツデータの外部記憶装置１２への録画や、録画されたコンテンツデータの出力に伴う制御を行う。以下、外部記憶装置１２に録画されたコンテンツデータを単にコンテンツとも記載する。
【００１９】
メタ情報管理部１５２は、外部記憶装置１２に記憶されたメタ情報ＭＤの管理や、ＣＤＳ（Content Directory Service）に対応するアクションを実行する。ＣＤＳのブラウズでは、メタ情報管理部１５２は、メタ情報ＭＤの全部又は一部をクライアント２０に送信する。クライアント２０はブラウズにより提供されたメタ情報ＭＤからコンテンツに該当するＵＲＬを取得し、このＵＲＬをもとにコンテンツの配信要求（ＨＴＴＰのＧＥＴ要求）を行うことが可能となる。本発明のメタ情報作成部（属性情報記憶部に相当、以下同様）１５２ａとメタ情報提供部（属性情報提供部に相当、以下同様）１５２ｂの機能は、メタ情報管理部１５２により実現される。
【００２０】
サービス提供部１５３は、ＤＬＮＡのＡＶＴｒａｎｓｐｏｒｔに従って、クライアント２０からのコンテンツの配信要求や、コンテンツの配信に伴って行われるアクション（コンテンツの再生、停止、トリックプレー等）の要求を処理する。トリックプレーは、サーバー１０が配信するコンテンツの再生ポイントを変更するシークや、このシークを流用した早送り、巻き戻しを含むアクションの名称である。広い意味では、通常の再生以外の再生全般を含んでいる。なお、録画制御部１５１、メタ情報管理部１５２およびサービス提供部１５３の他の機能については後述する。
【００２１】
図３は、ＤＭＰとして機能するクライアント２０のブロック構成図である。図３に示すクライアント２０は、サーバー１０から配信されたコンテンツを再生する表示装置として機能する。クライアント２０は、ネットワークＮと接続するネットワークＩＦ２１と、利用者の操作入力等を受け付ける操作入力部２２と、コンテンツを一時的に記憶するビデオメモリー２３と、コンテンツを表示する表示部２４と、これらを制御する制御部２５と、を備えている。
【００２２】
ネットワークＩＦ２１は、クライアント２０をネットワークＮに接続する。ネットワークＩＦ２１は、ＬＡＮカード、ＮＩＣ（Network Interface Card）等により構成されている。このネットワークＩＦ２１によりクライアント２０とサーバー１０とはネットワークを介して接続することができる。
【００２３】
操作入力部２２は、利用者の操作入力を受け付けるタッチパネルや、操作キーにより構成されている。操作入力部２２は、制御部２５に接続されており、利用者による操作入力部２２の操作に応じた信号を制御部２５に出力する。
【００２４】
ネットワークＩＦ２１と操作入力部２２とは、制御部２５に接続されている。制御部２５は、ＣＰＵ、ＲＯＭ、ＲＡＭを備えており、ネッワークＩＦ２１を通じたネットワークＮへの接続や、利用者の操作による操作入力部２２からの信号を処理する。また、制御部２５のＲＯＭには、ＣＰＵにＯＳ（Operating System）や、ブラウザー２５１としての機能を実現させるプログラムが記憶されている。
【００２５】
ブラウザー２５１は、サーバー１０から送信されるＸＭＬデータ（メタ情報ＭＤ）の解読や、コンテンツを表示部２４に表示させるための処理を行う。本実施形態では、ブラウザー２５１の機能により、コンテンツの内容を示すメタ情報ＭＤを要求するメタ情報取得部（属性情報取得部に相当、以下同様）２５１ａ、取得したメタ情報ＭＤによりサーバー１０に対してコンテンツの配信に伴う処理を要求するサービス要求部２５１ｂと、を実現する。
配信要求がされたコンテンツはビデオメモリー２３に一時的に記憶された後、ブラウザー２５１によって処理される。ブラウザー２５１によって処理されたコンテンツは表示部２４に出力され、映像又は音声として出力される。
【００２６】
表示部２４は、例えば、ＬＣＤ（Liquid Crystal Display）や、ＬＣＤを駆動するためのドライバーを備えている。また、表示部２４がタッチパネルモジュールの機能を備える場合、表示部２４は操作入力部２２としても機能する。
【００２７】
（２）コンテンツ配信方法
次に、コンテンツ配信システム１により行われるコンテンツ配信方法を説明する。
図４は、サーバー１０とクライアント２０との間で行われる処理を説明するシーケンス図である。図４では、サーバー１０はテレビジョン放送の録画を行っており（ステップＳ１）、この録画中に、クライアント２０がサーバー１０に対してブラウズの要求（ステップＳ３）を行う場合の処理を示している。まずは、図４をもとに、サーバー１０とクライアント２０とが行う処理の概要を説明する。
【００２８】
録画制御部１５１は、コンテンツの録画を開始する（ステップＳ１）。録画制御部１５１の制御により、データ入力部１１を介して取得されたテレビジョン放送信号は、外部記憶装置１２にコンテンツとして録画される。
【００２９】
録画制御部１５１によるコンテンツの録画に伴って、メタ情報管理部１５２は、メタ情報更新処理を行う（ステップＳ２−１、Ｓ２−２…）。このメタ情報更新処理により、メタ情報管理部１５２は、コンテンツの録画中であっても、ＣＤＳに対応するメタ情報ＭＤの作成・更新を行う。
【００３０】
図５は、メタ情報ＭＤを説明する図である。メタ情報ＭＤは、ＸＭＬにより作成されており、コンテンツの内容や、配信に必要な情報をタグ形式で階層的に記録している。タグ＜item id＞は、コンテンツごとに固有に付与される番号を要素とする。また、図５では、タグ＜item id＞には、属性情報として、ツリー構造の親のタグが付与されている。タグ＜dc:title＞には、コンテンツのタイトル名を要素としている。タグ＜dc:data＞には、コンテンツの放送開始時刻を要素としている。タグ＜res protocolInfo＞には、このコンテンツを配信する際にクライアント２０が参照する情報が要素として記憶されている。例えば、タグ＜res protocolInfo＞には、コンテンツが記憶されるサーバー上のアドレス、トリックプレーを許可するフラグ（Dlna.ORG OP）、コンテンツが放送される際の平均ビットレート（bitrate）、総再生時間（duration）、コンテンツのデータサイズが記憶されている。
【００３１】
この第１の実施形態では、メタ情報管理部１５２（メタ情報作成部１５２ａ）は、コンテンツの録画時間を所定時間（後述する録画周期Ｆｒｅｃ）毎に区切り、この録画周期Ｆｒｅｃ毎にメタ情報ＭＤを更新する。例えば、図５に示すメタ情報ＭＤのうち、タグ＜res protocolInfo＞の要素「duration」は、この更新時の累積録画時間をもとに書き換えられる。すなわち、メタ情報管理部１５２は、コンテンツの録画完了前に、このコンテンツに対するメタ情報ＭＤを作成することとなる。
【００３２】
クライアント２０（メタ情報取得部２５１ａ）は、サーバー１０に対して、提供可能コンテンツの一覧の情報を取得するためのブラウズの要求を行う（ステップＳ３）。クライアント２０からのブラウズの要求により、メタ情報管理部１５２（メタ情報提供部１５２ｂ）は、該当コンテンツの検索（ステップＳ４）と、該当するコンテンツのメタ情報ＭＤの一部又は全部をクライアント２０へ送信する（ステップＳ５）。サーバー１０が配信するメタ情報ＭＤは、録画が完了したコンテンツのみならず、現在録画中のコンテンツのメタ情報ＭＤも配信される。
【００３３】
クライアント２０のブラウザー２５１（サービス要求部２５１ｂ）は、サーバー１０から配信されたメタ情報ＭＤをもとに、コンテンツの配信要求や、再ブラウズの要求を行う（ステップＳ６）。クライアント２０は、コンテンツの配信要求や再ブラウズの要求に伴うコンテンツを利用者に選択させるためにコンテンツリストを表示する。以下では、利用者がクライアント２０を操作して、現在録画中のコンテンツに対して配信要求を行ったものとする。
【００３４】
サービス提供部１５３は、クライアント２０からの要求（配信要求、再ブラウズ）に対して、応答する（ステップＳ７）。この実施形態では、クライアント２０からの配信要求が録画が完了していないコンテンツである場合でも、クライアント２０は、このコンテンツに対して配信を開始する。この場合、サービス提供部１５３は、録画が完了している再生時間分のコンテンツをコンテンツデータとし、このコンテンツデータを随時、クライアント２０に配信する。
【００３５】
また、コンテンツデータの配信中においても、メタ情報管理部１５２によるメタ情報更新処理は、録画制御部１５１が一定の再生時間分のコンテンツデータを録画するたびに行われる（ステップＳ２−１、Ｓ２−２、Ｓ２−３…）。
【００３６】
次に、メタ情報管理部１５２が実行するメタ情報更新処理の具体例を説明する。図６は、メタ情報管理部１５２が実行するメタ情報更新処理を説明するフローチャートである。図７は、コンテンツの累積録画時間とメタ情報管理部１５２が更新するメタ情報ＭＤとの関係を説明する図である。図６に示す処理は、図４のステップＳ２において実行される処理である。以下では、外部記憶装置１２に記憶されたコンテンツデータ（録画中のものも含む）を単にコンテンツＣＯＤとも記載する。
【００３７】
ステップＳ２１では、メタ情報管理部１５２は、コンテンツが録画中か否かを判断する。例えば、メタ情報管理部１５２は、放送波に含まれるＳＩ情報や、電子番組表ＥＰＧに記憶された録画コンテンツの放送時刻をもとに、コンテンツＣＯＤが録画中か否かを判断する。
【００３８】
ステップＳ２２では、メタ情報管理部１５２は、録画周期Ｆｒｅｃが閾値Ｔ１以上か否かを判断する。録画周期Ｆｒｅｃは、コンテンツＣＯＤの録画開始とともにカウントアップされる。例えば、録画周期Ｆｒｅｃは、コンテンツＣＯＤの総再生時間や、ビットレートに応じてその値が決定される。
【００３９】
録画周期Ｆｒｅｃが閾値Ｔ１以上であれば（ステップＳ２２：ＹＥＳ）、ステップＳ２３では、メタ情報管理部１５２は、録画コンテンツのメタ情報ＭＤの作成・更新を行う。コンテンツＣＯＤの録画の開始後、最初のタイミングでは、メタ情報管理部１５２は、放送波に含まれるＳＩ情報や、電子番組表ＥＰＧに記憶されたコンテンツの情報をもとに、メタ情報ＭＤを作成する。
【００４０】
図７では、横軸を時間軸とした場合の、コンテンツの累積録画時間と、コンテンツの総再生時間（図７では、２時間３０分）と、更新されるメタ情報ＭＤのうち、再生時間「duration」の値を示している。図７（ａ）では、最初のメタ情報ＭＤの作成（更新）において「duration」は、累積録画時間（図７（ａ）では、３０分）に対応した値として記憶される。そのため、クライアント２０は、図７（ａ）において示されるメタ情報ＭＤのブラウズにより、コンテンツＣＯＤの総再生時間を３０分として判断することとなる。
【００４１】
ステップＳ２４では、メタ情報管理部１５２は、SystemUpdateIDを更新する。SystemUpdateIDは、メタ情報管理部１５２が管理するメタ情報ＭＤが更新されたことを示す情報である。クライアント２０は、一定周期でこのSystemUpdateIDの監視（Ｇｅｔ要求）を行っており、SystemUpdateIDの変化により、サーバー１０が保持するメタ情報ＭＤが更新されたことを判断することが可能となる。なお、クライアントがSystemUpdateIDを要求（Ｓ８）して、サーバーが返信（Ｓ９）することも可能である。従って、クライアントのSystemUpdateID要求（Ｓ８）に対して、サーバーがSystemUpdateIDを返信（Ｓ９）するようにしても良い。
【００４２】
コンテンツの録画が終了していなければ（ステップＳ２５：ＮＯ）、ステップＳ２２に戻り、メタ情報管理部１５２は一連の処理を繰り返す。なお、一連の処理を繰り返すためには、SystemUpdateIDを更新したら、録画周期Ｆｒｅｃをリセットするか、閾値Ｔ１を倍増していくようにすればよい。図７（ｂ）に示したように、録画中のコンテンツのメタ情報ＭＤの更新（ステップＳ２３）は、録画周期Ｆｒｅｃのカウントアップに応じて繰り返し行われる。図７（ｂ）では、メタ情報ＭＤの更新において「duration」は、累積録画時間（図７（ｂ）では、１時間５分）に対応した値となっている。すなわち、クライアント２０は、図７（ｂ）において示される更新後のメタ情報ＭＤのブラウズにより、コンテンツＣＯＤの総再生時間を１時間５分として判断することとなる。
【００４３】
コンテンツの録画が終了していれば（ステップＳ２５：ＹＥＳ）、ステップＳ２６では、メタ情報管理部１５２は、メタ情報ＭＤを確定させる。図７（ｃ）では、累積録画時間は、コンテンツＣＯＤの総再生時間と同じ値となっており、録画が完了している。図７（ｃ）に示すメタ情報ＭＤの更新において「duration」は、コンテンツの総再生時間（図７（ｃ）では、２時間３０分）に対応した値となっている。その結果、クライアント２０は、図７（ｃ）において示される更新確定後のメタ情報ＭＤのブラウズにより、コンテンツＣＯＤの総再生時間を２時間３０分として判断することとなる。
【００４４】
ステップＳ２７では、メタ情報管理部１５２は、SystemUpdateIDを更新する。すなわち、メタ情報ＭＤの更新があったことをクライアント２０に通知する。
【００４５】
図８は、図４のステップＳ６において、クライアント２０が実行する処理を説明する図である。図８に示す処理に先だって、ブラウザー２５１は、ブラウズの要求によりサーバー１０からメタ情報ＭＤを取得している（ステップＳ３）。クライアント２０が取得するメタ情報ＭＤは、図７（ａ）〜（ｃ）に示したように、サーバー１０の累積録画時間に応じて、コンテンツＣＯＤの再生時間を示す「duration」が更新されている。
【００４６】
ステップＳ３１では、ブラウザー２５１は、コンテンツＣＯＤの再生処理を開始する。この再生処理により、ブラウザー２５１からサーバー１０へは、該当コンテンツの配信要求が行われる。サーバー１０は、クライアント２０からの配信要求に対してコンテンツの配信を開始する。
【００４７】
ステップＳ３２では、ブラウザー２５１は、SystemUpdateIDの更新を確認する。SystemUpdateIDが更新されていなければ（ステップＳ３２：ＮＯ）、ステップＳ３３では、ブラウザー２５１は、コンテンツＣＯＤの再生が終了したか否かを判断する。SystemUpdateIDが更新されていないということは、サーバー１０側でメタ情報ＭＤが更新されていないことを意味している。
【００４８】
コンテンツＣＯＤの再生が終了していなければ（ステップＳ３３：ＮＯ）、ブラウザー２５１は、ステップＳ３２に戻る。なお、この間も、サーバー１０からクライアント２０へのコンテンツＣＯＤの配信は継続している。
【００４９】
SystemUpdateIDが更新されていれば（ステップＳ３２：ＹＥＳ）、ステップＳ３４では、ブラウザー２５１は、サーバー１０から更新後のメタ情報ＭＤを取得する。SystemUpdateIDが更新されていれば、サーバー１０側でメタ情報ＭＤが更新されているため、メタ情報ＭＤを更新する必要があるからである。
このようにサーバー側で逐次SystemUpdateIDを更新しており、クライアント側では必要に応じてサーバー側で管理するSystemUpdateIDを問い合わせ、変化していれば、クライアントが管理しているSystemUpdateIDを更新するようにしている。
【００５０】
ステップＳ３２に戻り、ブラウザー２５１は、コンテンツの再生が完了するまで一連の処理を繰り返す。コンテンツＣＯＤの再生が終了した場合（ステップＳ３３：ＹＥＳ）、ステップＳ３５において、ブラウザー２５１はコンテンツの再生終了処理を行う。
【００５１】
（３）作用・効果
以上説明したようにこの第１の実施形態では、サーバー１０では、コンテンツの録画完了を待つことなく録画中のコンテンツのメタ情報ＭＤが作成され、このメタ情報ＭＤをもとに、サーバーとクライアントとの間でブラウズの要求や、配信要求が行われる。そのため、サーバー１０がコンテンツを録画する場合に、利用者のコンテンツの配信に係る利便性を高めることができる。
メタ情報管理部１５２は、コンテンツが所定の再生時間分録画される毎に、録画したコンテンツの累積録画時間を、コンテンツの総再生時間に係るメタ情報として記憶する。そのため、クライアント２０は、コンテンツの総再生時間を録画されたコンテンツに対応する時間として判断するため、少なくとも録画済みの範囲でしか再生することはなく、再生やトリックプレーにおける操作の破綻を回避することができる。
このように、本実施例では、属性情報記憶部は、コンテンツが所定の再生時間分録画される毎に、録画されたコンテンツの累積録画時間を、コンテンツの総再生時間に係る属性情報として記憶している。
【００５２】
２．第２の実施形態：
メタ情報管理部１５２は、録画中にメタ情報ＭＤを繰り返し更新するではなく、予め、メタ情報ＭＤを設定しておき、コンテンツの内容が更新された場合にのみ、このメタ情報ＭＤを更新するものであってもよい。
【００５３】
以下、第１の実施形態と同様、図４に示すサーバー１０とクライアント２０との間で行われる処理を流用して説明を行う。また、この第２の実施形態においても、サーバー１０はテレビジョン放送の録画を行っており（ステップＳ１）、この録画中に、サーバー１０はコンテンツのメタ情報ＭＤを作成する（ステップＳ２−１）。
【００５４】
クライアント２０は、サーバー１０に対して、提供可能コンテンツの一覧の情報を取得するためのブラウズの要求を行う（ステップＳ３）。クライアント２０からのブラウズの要求により、サーバー１０（メタ情報管理部１５２）は、該当コンテンツの検索（ステップＳ４）と、該当するコンテンツのメタ情報ＭＤの一部又は全部をクライアント２０へ送信する（ステップＳ５）。サーバー１０が配信するメタ情報ＭＤは、録画が完了したコンテンツのみならず、現在録画中のコンテンツのメタ情報ＭＤも配信される。
【００５５】
クライアント２０のブラウザー２５１は、サーバー１０から配信されたメタ情報ＭＤをもとに、コンテンツリストを表示する。利用者がこのコンテンツリストにおいて、任意のコンテンツを選択すると、クライアント２０からサーバー１０に対して選択されたコンテンツの配信要求と、この配信要求に応じたコンテンツの配信が開始される（ステップＳ６）。
【００５６】
サービス提供部１５３は、クライアント２０からのブラウズの要求に対して、該当するコンテンツの配信を行う（ステップＳ７）。本実施形態においては、サービス提供部１５３は、録画が完了していないコンテンツであっても、クライアント２０からの配信要求があれば、配信を開始する。
【００５７】
次に、ステップＳ２−１において、メタ情報管理部１５２が実行するメタ情報更新処理の具体例を説明する。図９は、第２の実施形態において、メタ情報管理部１５２が実行するメタ情報更新処理を説明するフローチャートである。また、図１０は、コンテンツＣＯＤの累積録画時間とメタ情報管理部１５２が更新するメタ情報ＭＤとの関係を説明する図である。
【００５８】
ステップＳ１２１では、メタ情報管理部１５２は、コンテンツが録画中か否かを判断する。コンテンツが録画中であれば（ステップＳ１２１：ＹＥＳ）、メタ情報管理部１５２は、ステップＳ１２２に進み、コンテンツの録画が終了していれば、ステップＳ１２７に進む。
【００５９】
ステップＳ１２２では、メタ情報管理部１５２は、録画中のコンテンツの総再生時間を含むコンテンツ情報を取得する。総再生時間の取得は、例えば、テレビジョン放送信号に含まれるＳＩ情報や、ＥＰＧをもとに取得される。
【００６０】
ステップＳ１２３では、メタ情報管理部１５２は、ステップＳ１２２で取得したコンテンツ情報をもとに、録画中のコンテンツのメタ情報ＭＤを作成する。
図１０（ａ）では、累積録画時間が３０分であるのに対して、メタ情報ＭＤの「duration」は、コンテンツの総再生時間を示す「２時間３０分」となっている。すなわち、メタ情報管理部１５２は、メタ情報ＭＤの作成とともに、このコンテンツの総再生時間が「２時間３０分」であることを設定している。そのため、クライアント２０は、図１０（ａ）において示されるメタ情報ＭＤのブラウズにより、コンテンツＣＯＤの総再生時間を２時間３０分として判断することとなる。
【００６１】
ステップＳ１２４では、メタ情報管理部１５２は、SystemUpdateIDを更新する。SystemUpdateIDの更新により、クライアント２０は、サーバー１０が保持するメタ情報ＭＤが更新されたことを判断することが可能となる。
【００６２】
コンテンツの録画が終了していなければ（ステップＳ１２５：ＮＯ）、メタ情報管理部１５２はコンテンツの録画が終了するまでウェイトする。
【００６３】
コンテンツの録画が終了していれば（ステップＳ１２５：ＹＥＳ）、メタ情報管理部１５２は、ステップＳ１２６に進む。ステップＳ１２６では、メタ情報管理部１５２は、録画終了により確定したメタ情報ＭＤが、ステップＳ１２３において作成されたメタ情報ＭＤから変更されているか否かを判断する。メタ情報ＭＤの変更がなければ（ステップＳ１２６：ＮＯ）、メタ情報管理部１５２は、処理を終了する。
【００６４】
図１０（ｂ）に示したように、録画後のコンテンツＣＯＤのメタ情報ＭＤの変更がなければ、ステップＳ１２２で作成したメタ情報の「duration」は、コンテンツの総再生時間（図１０（ｂ）では、２時間３０分）と同じ値となっている。すなわち、ステップＳ１２２で作成したメタ情報ＭＤと、録画完了により取得されるメタ情報ＭＤとは同じ値である。
【００６５】
一方、メタ情報ＭＤの変更があれば（ステップＳ１２６：ＹＥＳ）、ステップＳ１２７において、メタ情報管理部１５２は、メタ情報ＭＤを更新する。図１０（ｃ）に示したように、録画後のコンテンツＣＯＤの再生時間が変更された場合、ステップＳ１２２で作成した「duration」（図１０（ｃ）では２時間３０分）と、コンテンツの総再生時間（２時間４０分）とが異なる値となっている。そのため、メタ情報管理部１５２は、メタ情報ＭＤの「duration」を、変更後の総再生時間に応じて更新する（ステップＳ１２７）。
【００６６】
ステップＳ１２８では、メタ情報管理部１５２はSystemUpdateIDを更新する。SystemUpdateIDの変更により、メタ情報管理部１５２は、サーバー１０においてメタ情報ＭＤが更新されていることを判断することが可能となる。
【００６７】
次に、サーバー１０が作成したメタ情報ＭＤをもとに、コンテンツの配信を行っているクライアント２０において、トリックプレーを要求した場合の処理を説明する。以下では、トリックプレーの一例として所定のシーンからの配信を要求する「サーチ」を例に説明を行う。ここで、トリックプレーのうち「早送り」は、サーバー１０に対してサーチを連続して要求するものであるため、本実施形態では、「サーチ」には「早送り」を含む概念としている。
【００６８】
図１１は、図４のステップＳ６においてクライアント２０がサーチ要求を行った場合の処理と、サーバー１０におけるクライアント２０からのサーチ要求に対する処理を説明するフローチャートである。図１２は、クライアント２０とサーバー１０との処理を説明する図である。
【００６９】
図１１のステップＳ１６１では、利用者によるサーチ操作を受け付けると、ブラウザー２５１は、サーバー１０に対して、該当シーンを再生開始ポイントとするサーチを要求する。
【００７０】
サーバー１０のサービス提供部１５３は、サーチ要求を受信すると（ステップＳ１７１：ＹＥＳ）、ステップＳ１７２では、現在のコンテンツの録画が完了されたポイントを判定する。判定の手法としては、コンテンツのメタ情報ＭＤから、録画開始時刻と、ビットレートとを取得し、録画が完了されたポイントを判定する。
【００７１】
サーチ要求されたポイントが録画済みであれば（ステップＳ１７３：ＹＥＳ）、ステップＳ１７４では、サービス提供部１５３は、サーチ要求されたポイントからのコンテンツＣＯＤを配信する。図１２（ａ）に示すように、クライアント２０からサーチ要求されたポイントＰｓａがサーバー１０で録画が完了しているポイントＰｒｅｃよりも時間軸で前であれば、サーバー１０はサーチ要求されたポイントＰｓａからのコンテンツを配信することができる。
【００７２】
ステップＳ１６２では、ブラウザー２５１は、サーバー１０からコンテンツＣＯＤの配信が行われれば（ステップＳ１６２：ＹＥＳ）、ステップＳ１６３では、サーバー１０から配信されたコンテンツ（サーチ要求点からのコンテンツ）を再生する。すなわち、このステップでは、ブラウザー２５１はコンテンツＣＯＤの配信の有無のみを判断している。
【００７３】
一方、サーチ要求されたポイントが録画済みでなければ（ステップＳ１７３：ＮＯ）、サービス提供部１５３は、ステップＳ１７５では、サーチポイントＰｓａに対応していないことを示すエラーコードを通知する。図１２（ｂ）に示すように、クライアント２０からサーチ要求されたポイントＰｓａがサーバー１０の録画が完了しているポイントＰｒｅｃよりも時間軸で後であれば、サーバー１０はサーチ要求されたポイントＰｓａからのコンテンツを配信することができない。
【００７４】
サーバー１０からエラーコードが通知された場合（ステップＳ１６２：ＮＯ）、ステップＳ１６４では、ブラウザー２５１は返信されたエラーコードを解析し、該当するサーチエラーを通知する。ステップＳ１６５では、クライアント２０は、サーチ要求される以前にサーバー１０から配信されているコンテンツを再生を継続する。
【００７５】
２．２．変形例
上記した第２の実施形態において、サーチポイントに該当するコンテンツのシーンが録画されているか否かをクライアント２０で判断するものであってもよい。
図１３は、第２の実施形態の変形例において、図４のステップＳ６においてクライアント２０がサーチ要求を行った場合の処理と、サーバー１０におけるクライアント２０からのサーチ要求に対する処理を説明するフローチャートである。
【００７６】
ステップＳ１１６１では、利用者によるサーチ操作を受け付けると、ブラウザー２５１は、サーバー１０に対して、サーチポイントＰｓａに該当する時刻を判断する。この実施形態では、サーバー１０がコンテンツとしてテレビジョン放送を録画している場合、録画が完了しているか否かは、現在の時刻をもとに判断することができる。
【００７７】
サーチポイントＰｓａに該当する時刻が、現在の時刻と比べて時間軸で後であれば（ステップＳ１１６２：ＮＯ）、ステップＳ１１６３では、ブラウザー２５１は、サーチエラー表示を行う。サーチポイントＰｓａに該当する時刻が、現在の時刻と比べて時間軸で後であれば、コンテンツは録画されていない。ステップＳ１１６４では、サーチ要求前からの配信コンテンツの再生を継続する。
【００７８】
サーチ要求されたポイントＰｓａに該当する時刻が、現在の時刻と比べて時間軸で前であれば（ステップＳ１１６２：ＹＥＳ）、ステップＳ１１６５では、ブラウザー２５１は、サーバー１０に対して該当サーチポイントＰｓａでのサーチ要求を行う。
【００７９】
サーバー１０のサービス提供部１５３は、サーチ要求を受けると（ステップＳ１１７１：ＹＥＳ）、ステップＳ１１７２、サーチ要求されたポイントＰｓａからのコンテンツＣＯＤを配信する。ステップＳ１１６６では、ブラウザー２５１は、サーバー１０からコンテンツＣＯＤの配信を受けると、配信されたコンテンツ（サーチ要求ポイントＰｓａからのコンテンツ）を再生する。
【００８０】
以上説明したようにこの第２の実施形態では、コンテンツの録画完了前にメタ情報を作成しておき、コンテンツの内容の変更がある場合のみメタ情報を変更する。そのため、このメタ情報ＭＤをもとに、サーバーとクライアントとの間でブラウズの要求や、配信要求を行うことができる。また、クライアントからのサーチ要求のポイントが録画が完了されたシーンより後である場合でも、エラー通知を行うことで、操作の破綻を回避することができる。
すなわち、本実施例では、属性情報記憶部は、コンテンツの録画が完了する前（すなわち録画中）に、コンテンツの総再生時間を属性情報として記憶しておき、コンテンツの録画完了後、コンテンツの内容に変更があれば、属性情報を更新している。
また、本実施例では、属性情報の送信後、クライアントから録画中のコンテンツの配信要求があった場合、配信要求があったコンテンツの録画済みのデータの配信を開始するサービス提供部を有している。
さらに、本実施例では、サービス提供部は、クライアントからのサーチ要求により、録画済みのコンテンツのシーンより後のシーンをサーチ要求された場合、クライアントにエラーを通知している。
【００８１】
３．第３の実施形態：
第２の実施形態で示したクライアント２０からサーバー１０へのサーチ要求に対して、サーチ要求のポイントが録画されていないコンテンツのポイントである場合、録画済みのコンテンツであって、サーチ要求のポイントに近いシーンを応答として配信するものであってもよい。
【００８２】
図１４は、第３の実施形態において、図４のステップＳ６においてクライアント２０がアクションのサーチ要求を行った場合の処理と、サーバー１０におけるクライアント２０からのサーチ要求に対する処理を説明するフローチャートである。図１５は、クライアント２０とサーバー１０との処理を説明する図である。
【００８３】
ステップＳ２６１では、利用者によるサーチ操作を受け付けると、ブラウザー２５１は、サーバー１０に対して、該当シーンをサーチポイントＰｓａとするサーチを要求する。
【００８４】
サーバー１０のサービス提供部１５３は、サーチ要求を受信すると（ステップＳ２７１：ＹＥＳ）、ステップＳ２７２では、サーチポイントＰｓａを判定する。サーチ要求されたポイントＰｓａが録画済みであれば（ステップＳ２７３：ＹＥＳ）、ステップＳ２７４では、サービス提供部１５３は、サーチ要求されたポイントＰｓａからのコンテンツＣＯＤを配信する。
【００８５】
図１５（ａ）に示すように、クライアント２０からサーチ要求されたポイントＰｓａがサーバー１０の録画が完了しているポイントＰｒｅｃよりも時間軸で前であれば、サーバー１０はサーチ要求されたポイントＰｓａからのコンテンツを配信することができる。
【００８６】
一方、サーチ要求されたポイントが録画済みでなければ（ステップＳ２７３：ＮＯ）、サービス提供部１５３は、ステップＳ２７５では、サーチポイントＰｓａに近いサーチポイントＰｓａからコンテンツの配信を行う。図１５（ｂ）に示すように、クライアント２０からサーチ要求されたサーチポイントＰｓａがサーバー１０の録画が完了しているポイントＰｒｅｃよりも時間軸で後であれば、サーバー１０はサーチ要求されたポイントＰｓａからのコンテンツを配信することができない。この場合、サーチポイントＰｓａを時間軸で前に変更し、配信可能なシーンのうち、要求されたサーチポイントＰｓａに近い位置をサーチポイントＰｓａ’とする。言い換えると、少なくとも録画完了ポイントＰｒｅｃよりも時間軸で前のポイントを返す。一例として、録画完了ポイントＰｒｅｃの３分前というようにすればよい。また、全体の番組長さに応じて何分前にするかを変化させても良い。
【００８７】
ステップＳ２７６では、サービス提供部１５３は、サーチポイントＰｓａの再生開始時刻を示すタイムスタンプＴＳＰをクライアント２０に返信する。図１５（ａ）に示したように、サーチポイントＰｓａが録画完了ポイントＰｒｅｃよりも時間軸で前であれば、タイムスタンプＴＳＰは、サーチポイントＰｓａが示す時刻となる。一方、図１５（ｂ）に示したように、サーチポイントＰｓａが録画完了ポイントＰｒｅｃよりも時間軸で後であれば、タイムスタンプＴＳＰは、ステップＳ２７５でサービス提供部１５３が設定したサーチポイントＰｓａ’が示す時刻となる。
【００８８】
サーバー１０からコンテンツＣＯＤの配信が行われれば（ステップＳ２６２：ＹＥＳ）、ステップＳ２６３では、ブラウザー２５１は、返信されたタイムスタンプＴＳＰをもとにスライドバーを構成する。スライドバーは、コンテンツの再生位置を示すアイコンであり、利用者がこのアイコンを巻き戻し方向に操作することで、ブラウザー２５１はスライドバーで示された位置からのコンテンツを再生することができる。
【００８９】
ステップＳ２６４では、ブラウザー２５１は、配信されたコンテンツ（要求したサーチポイントＰｓａからのコンテンツ、又はサーバー１０が設定したサーチポイントＰｓａ’からのコンテンツ）を再生する。
【００９０】
以上説明したようにこの第３の実施形態では、第１の実施形態で奏する効果に加えて、以下の効果を奏する。クライアント２０からのサーチ要求のポイントがコンテンツの録画前のシーンである場合でも、録画されているコンテンツの範囲で応答を行うため、トリックプレーに準じた操作の破綻を抑制することができる。
すなわち、本実施例では、サービス提供部は、クライアントからのサーチ要求により、録画済みのコンテンツのシーンより後のシーンを要求された場合、クライアントに、録画済みの前記コンテンツのシーンのうち要求されたシーンに近いシーンと、シーンの時間情報とを配信する。
【００９１】
４．第４の実施形態：
メタ情報ＭＤの構成として、特定のタグ（拡張情報ＥＸＤ）を付与しておき、この拡張情報ＥＸＤを認識できるクライアントにのみ、上記した第２及び第３の実施形態に示したサーチ要求を許可する構成としてもよい。以下では、クライアント２０は、この拡張情報ＥＸＤを認識できる機器であることを前提に説明を行う。また、この拡張情報には、トリックプレーに関する情報を含めている。
【００９２】
図１６は、第４の実施形態に係るメタ情報（拡張メタ情報ＭＤ２）を示す図である。図１６に示す拡張メタ情報ＭＤ２には、タグ「res protocolInfo」には、拡張情報ＥＸＤの一例として、録画中を示す「rec:status」、コンテンツサイズ「dlna:cleartextSize」、対応可能なトリックプレーを示す「rec:op」、録画時間を示す「rec:duration」、録画済みサイズを示す「rec:cleartextSize」が追加されている。これら、拡張情報ＥＸＤは、上述した他の実施形態と同様、メタ情報管理部１５２により作成される。
【００９３】
「rec:status」は、録画中であれは「"recording"」が付与される。「dlna:cleartextSize」は予想ビットレートと時間から算出して仮設定される値である。「rec:op」は、サーチアクション等の許可・不許可を示し、この要素が付与される場合、通常のトリックプレーの対応を示す「DLNA.ORG_OP」は設定されない。すなわち、「rec:op」を認識できないクライアントでは、再生コンテンツに対するトリックプレーが禁止される。
【００９４】
次に、図１７を用いて、この拡張メタ情報ＭＤ２を用いたクライアント２０の動作を説明する。ステップＳ３０１では、クライアント２０のブラウザー２５１はサーバー１０に対してブラウズの要求を行う。
【００９５】
ステップＳ３０２では、サーバー１０からメタ情報が送信されると（ステップＳ３０２：ＹＥＳ）、ステップＳ３０３では、ブラウザー２５１は、このメタ情報（拡張メタ情報ＭＤ２）に拡張情報ＥＸＤが含まれているか否かを解析する。無論、拡張情報ＥＸＤを認識できないクライアント２０では、拡張情報ＥＸＤの有無を解析することなく処理が継続される。
【００９６】
拡張情報ＥＸＤが含まれている場合（ステップＳ３０３：ＹＥＳ）、ステップＳ３０４では、クライアント２０はこの拡張情報ＥＸＤをもとに、サーバー１０からのコンテンツに対してトリックプレーが対応していると判断する。例えば、拡張情報ＥＸＤの「rec:op」で、サーチアクション等の許可を示すフラグが付与されていれば、「DLNA.ORG_OP」が設定されていなくとも、クライアント２０はサーバー１０に対してサーチアクションが可能であると判断する。
【００９７】
拡張情報ＥＸＤが含まれていなければ（ステップＳ３０３：ＮＯ）、ステップＳ３０５では、サーバー１０からのコンテンツに対してトリックプレーが対応していないと判断する。この場合、クライアント２０は、通常のメタ情報ＭＤ１に含まれる要素をもとに、サーバー１０に対して処理を要求することになる。
【００９８】
以上説明したようのこの第４の実施形態では、メタ情報ＭＤに含まれる拡張情報ＥＸＤの有無を検索し、トリックプレーの許可・不許可を切り替えるため、本発明の各実施形態で示す機能に対応していない既存のクライアントでは、各実施形態で示した機能を使用できないこととなる。そのため、本発明の機能に対応していない既存のクライアントと本発明の各機能に対応するクライアントとを併用する場合でも、操作破綻を抑制することができる。
すなわち、本実施例では、属性情報記憶部は、前記属性情報として、通常の再生以外の再生に関する情報を拡張情報として作成し記憶している。
【００９９】
５．第５の実施形態：
サービス提供部１５３は、録画済みのコンテンツ（分割コンテンツ）の情報にダミーデータ（ダミー情報に相当）を付与して、クライアント２０に配信するものであってもよい。
【０１００】
図１８は、第５の実施形態にかかるコンテンツデータを説明する図である。図１８で示すコンテンツＣＯＤには、元のコンテンツから作成されたソースデータＳＯＤにコンテンツの総再生時間に応じたダミーデータＤＭＤが付与されている。ソースデータＳＯＤは、サーバー１０が元のコンテンツを録画して得られたデータである。ダミーデータＤＭＤは、サービス提供部１５３により生成され、元のコンテンツの総再生時間から累積録画時間（すなわち、ソースデータＳＯＤの再生時間）を引いた分の時間長に応じたデータである。
【０１０１】
ダミーデータＤＭＤを構成するパケットには、ダミー画像部Ｄｍと、タイムスタンプ（時間情報）ＴＳＰとが付与されている。ダミー画像部Ｄｍは、コンテンツに換えてダミー画像（例えば、単色ベタ画像、通知画像）を構成するデータである。このダミー画像は、サーバー１０に予め記憶されている。また、タイムスタンプＴＳＰは、ソースデータＳＯＤを構成するパケットが備えるタイムスタンプＴＳＰと連続性をもってダミーデータＤＭＤに付与されている。
【０１０２】
サービス提供部１５３は、図４のステップＳ７において、録画済みのコンテンツデータ（ソースデータＳＯＤ）にダミーデータＤＭＤを付与しコンテンツデータＣＯＤを生成する。クライアント２０がこのコンテンツＣＯＤの配信を要求すると、サービス提供部１５３は、このコンテンツデータＣＯＤをクライアント２０に順次、配信する。無論、サーバー１０のサービス提供部１５３は、コンテンツの累積録画時間が経過するに従い、コンテンツＣＯＤに含まれるソースデータＳＯＤの量を変化させる。
【０１０３】
クライアント２０がサーバー１０にサーチ要求をした場合、サービス提供部１５３は要求されたサーチポイントＰｓａ付近のタイムスタンプＴＳＰをもとに、コンテンツＣＯＤのシーンが判断され、このシーンからの配信が行われる。無論、要求されたサーチポイントＰｓａがダミーデータＤＭＤに該当する場合でも、タイムスタンプＴＳＰをもとに、ダミーデータＤＭＤ内での位置が判断され、このシーン（ダミー画像）からの配信が行われる。
【０１０４】
上記のように構成された第５の実施形態では、クライアント２０から録画完了前のシーンに対してサーチ要求があった場合でも、タイムスタンプＴＳＰに沿った形でダミー画像を表示させることでトリックプレーに伴う操作の破綻を防止することができる。
すなわち、本実施例では、サービス提供部は、録画済みのコンテンツの情報にダミー情報を付与して、コンテンツとして配信している。
【０１０５】
６．第６の実施形態
本実施例では、クライアント２０の側（ＤＭＰの側）で、Ｓｅｅｋ可能な範囲を効率よく判断して配信を受ける構成について説明する。
この前提として、図１９は、サーバー１０の配信処理を示すフローチャートである。
ステップＳ４００にて録画制御部１５１が録画を開始すると、ステップＳ４０５にてメタ情報管理部１５２はメタ情報であるＣＤＳを登録する。このメタ情報は、上述したように録画中のコンテンツを配信するために加工したものであり、ここでは追っかけ用データと称する。
【０１０６】
この場合、特に加工するものは、以下のようなものである。
・配信する時にはTrickPlayを初期登録時に許可（DLNA.ORG_OP=10）しておく。
・録画中はORG_FLGASのsN-increasingをTrueに設定し、終端位置は随時更新する事を明示する。
また、録画中のitem情報としては、以下のようにする。
・Durationを付与せず、GuideLineに従い、sizeは現在録画出来ているところまで提示する。
・ORG_FLGASのsN-increasing（ORG_FLAGS BIT26）をTrueに設定
【０１０７】
図２０は、録画中のitem情報の一例を示している。
同図に示すように、録画開始時点から取得出来ている開始時刻（録画開始時点においては、開始予定時刻でもある）と終了時刻（録画開始時点においては、終了予定時刻でもある）として、
2015-09-29T16:00:00
20154-09-29T18:00:00
のように、設定してある。これは実際に録画されている時間と一致することが保証されているものではないが、この情報に基づいてＤＭＰ側は開始時刻と終了時刻を概ね把握出来ることになる。
ORG_FLGASのsN-increasing（ORG_FLAGS BIT26）をTrueに設定しており、このことは、
DLNA.ORG_FLAGS=05119000000000000000000000000000
として反映されている。
【０１０８】
図１９に戻ると、ＣＤＳの登録後は、ステップＳ４１０にて、サービス提供部１５３が配信要求の有無を判断し、配信要求があれば、ステップＳ４１５にて、サービス提供部１５３はクライアント２０に対して追っかけ配信を行う。この配信については後述する。
配信の有無にかかわらず、逐次、ステップＳ４２０にて、録画制御部１５１が録画の完了の有無を判断しており、完了している場合は、ステップＳ４２５にて、ＣＤＳを更新する。この場合、録画は完全に終了しているので、ステップＳ４０５にて設定したような仮の情報のものではなく、確定した情報に基づいてＣＤＳを更新する。
以下に、ステップＳ４１５にて配信が行われているＤＭＰの側でのトリックプレイについて説明する
【０１０９】
６−１  ＤＭＰ実施例１
scheduledEndTime/dc:dateで範囲判定する方法：Seek要求前に、scheduledEndTime/dc:dateと現在時刻から飛び先が有効かどうかを判定する。
本実施例では、終了時刻を表すscheduledEndTimeと、現在時刻とにより、ｓｅｅｋ先が有効か否かを判定する。
【０１１０】
図２１は、ＤＭＰであるクライアント２０のトリックプレイ処理のフローチャートである。なお、時刻計算にはＤＭＰの側に時計を内蔵している必要がある。
クライアント２０において、ステップＳ４５０にて、ユーザーによる早送りやジャンプなどのトリックプレイを受け付けると、まず、ステップＳ４５５にて、配信を受けているコンテンツが追っかけ配信のコンテンツであるか判断する。追っかけ配信のコンテンツでない場合は、予め受領しているＣＤＳの情報は確定したものであるから、ステップＳ４７５にて対応するｓｅｅｋ要求を実行すればよい。同ｓｅｅｋ要求を実行してトリックプレイは終了する。
【０１１１】
一方、追っかけ配信のコンテンツである場合は、ステップＳ４６０にて、現在時刻と、scheduledEndTimeとを対比し、ｓｅｅｋ要求しようとしている移動先が範囲内（録画済み範囲）にあるか否かを判断する。
【０１１２】
例えば、
upnp:scheduledStartTimeの値が、2015-09-29T16:00:00であり、現在時刻が、2015-09-29T17:10:00の場合、録画時間は1:10:00となる。TrickPlayの有効範囲（録画済み範囲、以下同様）も、その範囲となる。
【０１１３】
また、終端は、upnp:scheduledEndTimeが、+20154-09-29T18:00:00であるとすると、その時刻以降は範囲外となる。
すなわち、Seek有効範囲は、
開始2015-09-29T16:58:00（upnp:scheduledStartTime ＜ dc:dateより)
終端2015-09-29T17:10:00（現在時刻 ＜ upnp:scheduledEndTimeより）
である。
【０１１４】
ステップＳ４６５では、ユーザの操作によるｓｅｅｋ要求の移動先がこの範囲内であるか判断し、範囲内であれば問題なく再生可能であるのでステップＳ４７５にてｓｅｅｋ要求を実行する。一方、範囲内ではなかった場合は、ステップＳ４７０にて、ｓｅｅｋ移動先をこの範囲内に変更し、ステップＳ４７５にてｓｅｅｋ要求を実行する。また、範囲内ではなかった場合の他の処理として、移動要求自体を不可とすることも可能である。
このように、本実施例では、サービス要求部は、コンテンツの配信の開始位置が、録画中のコンテンツの録画済みの範囲内であるか（すなわち、録画済みか）を判断するようにしており、具体的には、終了予定時刻と、現在時刻とを利用して判断している。
【０１１５】
６−２  ＤＭＰ実施例２
再生時は常にTimeSeekRangeヘッダを付ける方法：再生を行うとき（GET要求）は常にTimeSeekRangeヘッダを付与することで、有効範囲を確認する。
【０１１６】
図２２は、ＤＭＰであるクライアント２０の再生処理のフローチャートである。
クライアント２０において、ステップＳ５００にて、ユーザーによる再生操作を受け付けると、ステップＳ５０５では、ｇｅｔ要求に加え、常にTimeSeekRangeヘッダを付与する。
【０１１７】
再生開始時は、先頭からの配信を要求するので、「timeseekrange.dlna.org: npt=0- 」を設定する。この要求範囲は「0-」としており、終端を設定しない。このように、終端を設定しないでTimeSeekRangeヘッダを付与すると、サーバー１０側からの応答には有効な時間として終了時刻を含めて返答が来る。従って、この応答内の終了時刻を記憶する。
【０１１８】
図２３は、クライアント２０とサーバー１０間の通信を示している。
図に示すように、クライアント２０からの再生要求には、
「timeseekrange.dlna.org: npt=0-」が含まれている。
これに対するサーバー１０からの返答には、
「TimeSeekRange.dlna.org: npt=0.000-1354.000/* bytes=0-413019647/*」が含まれている。
これにより、クライアント２０は、有効範囲は0.000-1354.000(s)ということが分かる。
【０１１９】
図２０に示すitemのMetadataの場合、開始時刻はdc:dateとなり、その時刻から1354秒経過した時間が録画済みの範囲となるので、
1354秒=22分34秒、つまり2015-09-29T17:20:34までの時間が録画出来ているということである。
従って、Seek有効範囲は、
開始2015-09-29T16:58:00（upnp:scheduledStartTime ＜ dc:dateより)
終端2015-09-29T17:20:34（TimeSeekRange終端 ＜ upnp:scheduledEndTimeより）
である。
【０１２０】
次に、ステップＳ５１０にて、クライアント２０がユーザーによる早送りやジャンプなどのトリックプレイを受け付けると、まず、ステップＳ５１５にて、配信を受けているコンテンツが追っかけ配信のコンテンツであるか判断する。追っかけ配信のコンテンツでない場合は、予め受領しているＣＤＳの情報は確定したものであるから、ステップＳ５３５にて対応するｓｅｅｋ要求を実行すればよい。同ｓｅｅｋ要求を実行してトリックプレイは終了する。
【０１２１】
一方、追っかけ配信のコンテンツである場合は、ステップＳ５２０にて、現在時刻と、ステップＳ５０５で得た終了時刻とを対比し、ｓｅｅｋ要求しようとしている移動先が範囲内にあるか否かを判断する。
すなわち、ステップＳ５２５では、ユーザの操作によるｓｅｅｋ要求の移動先が、
開始2015-09-29T16:58:00（upnp:scheduledStartTime ＜ dc:dateより)
終端2015-09-29T17:20:34（TimeSeekRange終端 ＜ upnp:scheduledEndTimeより）
の範囲内であるか判断し、範囲内であれば問題なく再生可能であるのでステップＳ５３５にてｓｅｅｋ要求を実行する。一方、範囲内ではなかった場合は、ステップＳ５３０にて、ｓｅｅｋ移動先をこの範囲内に変更し、ステップＳ５３５にてｓｅｅｋ要求を実行する。また、範囲内ではなかった場合の他の処理として、移動要求自体を不可とすることも可能である。
【０１２２】
なお、内蔵時計が無い機器の場合は、TimeSeekRange.dlna.orgとdc:dateの値を基準に時間管理する。
例えば、上記の条件と同じとして、現在設定時刻は初期値として00:00と設定する。dc:dateが2015-09-29T16:58:00なので、この値に、これまでの経過時間である00:22:34を加算した結果の2015-09-29T17:20:34を、現在時刻として設定すればよい。
このように、本実施例では、サービス要求部は、コンテンツの配信の開始位置が、録画中のコンテンツの録画済みの範囲内であるか（録画済みか）を判断するようにしており、具体的には、コンテンツの再生を行うときにその時点での有効範囲を確認する。このとき、配信要求のコマンド内のヘッダを利用している。
【０１２３】
６−３  ＤＭＰ実施例３
GET要求を行う前に、先にHEADコマンドでTimeSeekRangeヘッダを付与して実行する：現在の終端時刻の最新情報を更新することで移動先が有効かどうかを判断し、無効領域に飛ぶ事が無いようにする。
【０１２４】
図２４は、ＤＭＰであるクライアント２０の再生処理のフローチャートである。
ステップＳ５５０にて、クライアント２０がユーザーによる早送りやジャンプなどのトリックプレイを受け付けると、まず、ステップＳ５５５にて、配信を受けているコンテンツが追っかけ配信のコンテンツであるか判断する。追っかけ配信のコンテンツでない場合は、予め受領しているＣＤＳの情報は確定したものであるから、ステップＳ５７５にて対応するｓｅｅｋ要求を実行すればよい。同ｓｅｅｋ要求を実行してトリックプレイは終了する。
【０１２５】
一方、追っかけ配信のコンテンツである場合は、ステップＳ５６０にて、ＧＥＴ要求を行う前に、先に、TimeSeekRangeヘッダを付与してＨＥＡＤコマンドを実行する。
TimeSeekRangeヘッダを付与してＨＥＡＤコマンドを実行すると、現在の終端時刻の最新情報がサーバー１０からの応答に含まれる。このため、終端時刻を最新情報に更新することででき、移動先が有効かどうかを判断することができる。例えば、録画中断や録画延長などが生じると、upnp:scheduledEndTimeが更新される。このように更新された場合でも、本実施例のように先にＨＥＡＤコマンドを実行しておくことで追従することが可能となる。そして、無効領域に飛ぶことがないようにする。
【０１２６】
ステップＳ５６５では、現在時刻と、ステップＳ５６０で得た最新情報の終了時刻とを対比し、ｓｅｅｋ要求しようとしている移動先が範囲内にあるか否かを判断する。
すなわち、ユーザの操作によるｓｅｅｋ要求の移動先が、
開始2015-09-29T16:58:00（upnp:scheduledStartTime ＜ dc:dateより)
終端2015-09-29T17:20:34（TimeSeekRange終端 ＜ upnp:scheduledEndTimeより）
の範囲内であるか判断し、範囲内であれば問題なく再生可能であるのでステップＳ５７５にてｓｅｅｋ要求を実行する。一方、範囲内ではなかった場合は、ステップＳ５７０にて、ｓｅｅｋ移動先をこの範囲内に変更し、ステップＳ５７５にてｓｅｅｋ要求を実行する。また、範囲内ではなかった場合の他の処理として、移動要求自体を不可とすることも可能である。
このように、本実施例では、サービス要求部は、コンテンツの配信の開始位置が、録画中のコンテンツの録画済みの範囲内であるか（録画済みか）を判断するようにしており、具体的には、コンテンツの再生を行うときにその時点での有効範囲を確認する。このとき、配信要求のコマンドであるｓｅｅｋ要求をする前のＨＥＡＤコマンドを実行することで、実現している。
【０１２７】
６−４  ＤＭＰ実施例４
ＨＥＡＤコマンドを実行して範囲を更新する：この方法を応用することで、GUIのTimebar 時間範囲を任意のタイミングで更新することが可能となり、安定した動作を行うことができる。
【０１２８】
図２５は、ＤＭＰであるクライアント２０の再生処理のフローチャートである。
クライアント２０は、ステップＳ６００にて、再生中である場合に、以下の処理を実行する。ステップＳ６０５にて、配信を受けているコンテンツが追っかけ配信のコンテンツであるか判断する。追っかけ配信のコンテンツでない場合は、予め受領しているＣＤＳの情報は確定したものであるから、開始時刻、終了時刻、シーク可能範囲の変更はない。唯一、これまでの再生時刻が変化しており、この再生時刻の変化を反映させるために、ステップＳ６２０にて再生情報を更新する。
【０１２９】
一方、追っかけ配信のコンテンツである場合は、ステップＳ６１０にて、TimeSeekRangeヘッダを付与してＨＥＡＤコマンドを実行する。TimeSeekRangeヘッダを付与してＨＥＡＤコマンドを実行すると、現在の終端時刻の最新情報がサーバー１０からの応答に含まれ、この終了時刻を取得した上で、ｓｅｅｋ有効範囲を確認する。
開始2015-09-29T16:58:00（upnp:scheduledStartTime ＜ dc:dateより)
終端2015-09-29T17:20:34（TimeSeekRange終端 ＜ upnp:scheduledEndTimeより）
の範囲内がｓｅｅｋ有効範囲であり、ＧＵＩとして再生画面に表示するタイムバーの情報を更新可能となる。ステップＳ６１５では、クライアント２０は、終端時刻に基づいて終端位置を更新し、上記ｓｅｅｋ有効範囲を更新する。その上で、ステップＳ６２０にて再生情報を更新する。
【０１３０】
図２６と図２７は、コンテンツの配信を受けているときにタイムバーをＧＵＩとして表示する画面例を示している。
図２６に示す画面では、画面の下寄りの部分にタイムバーＴＢが表示されている。タイムバーの左端は開始時刻に相当し、右端は終了時刻に相当する。再生を開始した時点ではそれまでの録画済みの範囲が01:23:00であった場合は、図に示すように、左端に0:00:00と表示し、右端には01:23:00と表示される。また、再生経過部分を示すようにタイムバーが左から右に向かって伸びてきている。
【０１３１】
一方、ＨＥＡＤコマンドで終了時刻とｓｅｅｋ有効範囲を更新出来る結果、図２７に示すように、タイムバーＴＭの左端は開始時刻である15:00:00が表示され、右端は延長なども含めた最新の情報として16:30:00が表示される。
再生開始からの経過時間に基づいて、再生位置を15:21:30として示しており、録画済み位置もｓｅｅｋ有効範囲が反映されて15:43:00と表示されている。
このように、scheduledStartTimeとscheduledEndTime、TimeSeekRangeから、TimeBarを実時間で表示することが可能となる。
むろん、ＨＥＡＤコマンドで値を取得するだけなので、再生には影響しない。
このように、本実施例では、配信要求のコマンドに先立つコマンドを利用し、録画中のコンテンツの録画済み範囲を確認して再生画像上に重ねて表示している。
【０１３２】
７．その他の実施形態：
サーバー１０としてレコーダーを例に説明を行ったのは一例に過ぎず、ＵＰｎＰ  ＡＶのプロトコルに準じてコンテンツを配信できるものであれば、パーソナルコンピューター等、どのような装置であってもよい。
【０１３３】
なお、本発明は上記実施例に限られるものでないことは言うまでもない。当業者であれば言うまでもないことであるが、
・上記実施例の中で開示した相互に置換可能な部材および構成等を適宜その組み合わせを変更して適用すること
・上記実施例の中で開示されていないが、公知技術であって上記実施例の中で開示した部材および構成等と相互に置換可能な部材および構成等を適宜置換し、またその組み合わせを変更して適用すること
・上記実施例の中で開示されていないが、公知技術等に基づいて当業者が上記実施例の中で開示した部材および構成等の代用として想定し得る部材および構成等と適宜置換し、またその組み合わせを変更して適用すること
は本発明の一実施例として開示されるものである。
【符号の説明】
【０１３４】
１…コンテンツ配信システム、１０…サーバー、１１…データ入力部、１２…外部記憶装置、１３…操作入力部、１５…制御部、２０…クライアント、２２…操作入力部、２３…ビデオメモリー、２４…表示部、２５…制御部、１１１…チューナー、１１２…入力端子、１５１…録画制御部、１５２…メタ情報管理部、１５３…サービス提供部、２５１…ブラウザー
【図１】
2017143329.tif 000003
【図２】
2017143329.tif 000004
【図３】
2017143329.tif 000005
【図４】
2017143329.tif 000006
【図５】
2017143329.tif 000007
【図６】
2017143329.tif 000008
【図７】
2017143329.tif 000009
【図８】
2017143329.tif 000010
【図９】
2017143329.tif 000011
【図１０】
2017143329.tif 000012
【図１１】
2017143329.tif 000013
【図１２】
2017143329.tif 000014
【図１３】
2017143329.tif 000015
【図１４】
2017143329.tif 000016
【図１５】
2017143329.tif 000017
【図１６】
2017143329.tif 000018
【図１７】
2017143329.tif 000019
【図１８】
2017143329.tif 000020
【図１９】
2017143329.tif 000021
【図２０】
2017143329.tif 000022
【図２１】
2017143329.tif 000023
【図２２】
2017143329.tif 000024
【図２３】
2017143329.tif 000025
【図２４】
2017143329.tif 000026
【図２５】
2017143329.tif 000027
【図２６】
2017143329.tif 000028
【図２７】
2017143329.tif 000029