(57)【要約】【課題】記録装置の記憶容量が枯渇する時期の推測を容易に行なえるネットワーク機器を提供すること。【解決手段】ネットワーク上の他の機器との間で情報の交換を行うネットワーク機器であって、コンテンツ蓄積部1-9の残量の単位時間当たりの減少量を記録ビットレートとして計測する記録ビットレート計測部1-8と、記録ビットレート計測部1-8で計測されたビットレートを状態変数として監視し、予め定められた基準に基づいて状態変数に変化があったか否かを判断するとともに、該状態変数に変化があったと判断した場合に、イベント発行要求を出力する記録ビットレート監視部1-7と、記録ビットレート監視部1-7からのイベント発行要求に基づいて、状態変化を示すイベント通知を他の機器に対して送信するイベント処理部1-6とを具備する。【選択図】        図１
2007184844.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上の他の機器との間で情報の交換を行うネットワーク機器であって、
前記他の機器と前記ネットワークを介して通信する通信部と、
データを蓄積するデータ蓄積部と、
前記データ蓄積部の残量の単位時間当たりの減少量を記録ビットレートとして計測する記録ビットレート計測部と、
前記記録ビットレート計測部で計測されたビットレートを状態変数として監視し、予め定められた基準に基づいて状態変数に変化があったか否かを判断するとともに、該状態変数に変化があったと判断した場合に、イベント発行要求を出力する記録ビットレート監視部と、
前記記録ビットレート監視部からのイベント発行要求に基づいて、状態変化を示すイベント通知を前記通信部から前記他の機器に対して送信するイベント処理部と、
を具備することを特徴とするネットワーク機器。
【請求項２】
前記ビットレート監視部は、前記記録ビットレート計測部で計測されたビットレートの変化が一定の範囲を超過している際に、状態変数に変化があったと判断すること
を特徴とする請求項１記載のネットワーク機器。
【請求項３】
前記状態変数が変化したか否かを判断する基準を新たに設定する旨の前記他の機器からのアクション要求を前記通信手段で受信したときに、前記記録ビットレート監視部が判断する基準を新たな基準に設定する第１のアクション処理部をさらに具備し、
前記記録ビットレート監視部は、前記新たな基準に基づいて状態変数に変化があったか否かを判断すること
を特徴とする請求項１記載のネットワーク機器。
【請求項４】
現在のビットレートを表わす状態変数の値を要求する旨の前記他の機器からのアクション要求を前記通信手段で受信したときに、前記記録ビットレート監視部から当該状態変数の値を取得して通知する第２のアクション処理部をさらに具備すること
を特徴とする請求項１または２記載のネットワーク機器。
【請求項５】
他の機器からコンテンツの詳細情報を要求する旨のアクション要求があった場合に、現在のビットレートと判断基準の値を前記記録ビットレート監視部から取得し、取得した値をもとにプロパティを生成して通知する第３のアクション処理部をさらに具備することを特徴とする請求項１から３のいずれか１つに記載のネットワーク機器。
【請求項６】
前記イベント処理部は、ＵＰｎＰ規格に基づくＸＭＬ形式で記載されたイベント通知を前記通信部から前記他の機器に対して送信すること
を特徴とする請求項１乃至請求項５のいずれか１項記載のネットワーク機器。
【請求項７】
ネットワーク上の他の機器との間で情報の交換を行うネットワーク機器であって、
前記他の機器に対してイベント発行を依頼すると共に、前記他の機器からのイベント通知を受信するイベント処理部と、
データを蓄積するデータ蓄積部と、
前記データ蓄積部に蓄積されたデータを、他の機器に対して伝送する送信部と、
前記送信部から前記他の機器へのデータ伝送の開始およびデータ伝送の終了を指示するデータ伝送部と、
前記他の機器からのイベント通知に基づいて、前記他の機器の記録ビットレートの変化を検出し、前記データ伝送部による前記他の機器へのデータ伝送が完了するか否かを予測する記録ビットレート解釈部と、
を具備することを特徴とするネットワーク機器。
【請求項８】
前記記録ビットレート解釈部は、前記データ伝送部による前記他の機器へのデータ伝送が完了しないと予測した場合に、ユーザに対する注意画面を表示する指示を情報表示部に対して行なうとともに、前記コンテンツ伝送部に対してコンテンツ伝送の停止を指示すること
を特徴とする請求項７記載のネットワーク機器。
【請求項９】
状態変数が変化したか否かを前記他の機器が判断する基準を新たに設定する旨のアクション要求を、前記他の機器に対して送信する第１のアクション処理部
をさらに具備することを特徴とする請求項７または８に記載のネットワーク機器。
【請求項１０】
前記他の機器の現在の記録ビットレートを表わす状態変数の値を要求する旨のアクション要求を他の機器に対して行なう第２のアクション処理部をさらに具備すること
を特徴とする請求項７から９のいずれか１つに記載のネットワーク機器。
【請求項１１】
前記他の機器に対してコンテンツの詳細情報を要求する旨のアクション要求を行なう第３のアクション処理部をさらに具備すること
を特徴とする請求項７から１０のいずれか１つに記載のネットワーク機器。
【請求項１２】
前記イベント処理部は、ＵＰｎＰ規格に基づくＸＭＬ形式で記載されたイベントを処理すること
を特徴とする請求項７乃至請求項１１のいずれか１項記載のネットワーク機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に配置された他の機器との間で情報の交換を行うネットワーク機器に関する。
【背景技術】
【０００２】
データを記録するにあたって、記録装置に記録可能な残りの容量を検出するための種々の提案が従来からなされている。例えば、特許文献１は、利用者が自らの要求に応じた形態で可変ビットレートでの符号化処理における記録媒体の記録残量を把握できるデータ記録装置を開示している。また、特許文献２は、可変ビットレートによって記録している最中の記録媒体の残容量に関する情報を表示可能な信号記録装置を開示している。また、特許文献３は、ハードディスクに記憶する番組の録画予約設定をするときに、予約録画実行時点でのハードディスク残容量を算出し、該当予約録画ができない可能性があるときには、予約録画ができない可能性があることを表示する画像記録装置を開示している。
【特許文献１】特開２００５−６１９９号公報
【特許文献２】特開平１１−３２８９３７号公報
【特許文献３】特開２００２−３３９８２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記した先行技術はいずれも単に記録装置の記録残量を検出するのみであり、記録装置の記憶容量が枯渇する時期についての推測を容易にするための具体的な方法を開示していない。
【０００４】
本発明はこのような課題に着目してなされたものであり、その目的とするところは、適切な基準での状態変化の通知を可能にして、記録装置の記憶容量が枯渇する時期の推測を容易に行なえるネットワーク機器を提供することにある。
【課題を解決するための手段】
【０００５】
上記の目的を達成するために、本発明の第１の態様は、ネットワーク上の他の機器との間で情報の交換を行うネットワーク機器であって、前記他の機器と前記ネットワークを介して通信する通信部と、データを蓄積するデータ蓄積部と、前記データ蓄積部の残量の単位時間当たりの減少量を記録ビットレートとして計測する記録ビットレート計測部と、前記記録ビットレート計測部で計測されたビットレートを状態変数として監視し、予め定められた基準に基づいて状態変数に変化があったか否かを判断するとともに、該状態変数に変化があったと判断した場合に、イベント発行要求を出力する記録ビットレート監視部と、
前記記録ビットレート監視部からのイベント発行要求に基づいて、状態変化を示すイベント通知を前記通信部から前記他の機器に対して送信するイベント処理部と、を具備する。
【０００６】
また、本発明の第２の態様は、第１の態様において、前記ビットレート監視部は、前記記録ビットレート計測部で計測されたビットレートの変化が一定の範囲を超過している際に、状態変数に変化があったと判断する。
【０００７】
また、本発明の第３の態様は、第１の態様において、前記状態変数が変化したか否かを判断する基準を新たに設定する旨の前記他の機器からのアクション要求を前記通信手段で受信したときに、前記記録ビットレート監視部が判断する基準を新たな基準に設定する第１のアクション処理部をさらに具備し、前記記録ビットレート監視部は、前記新たな基準に基づいて状態変数に変化があったか否かを判断する。
【０００８】
また、本発明の第４の態様は、第１または第２の態様において、現在のビットレートを表わす状態変数の値を要求する旨の前記他の機器からのアクション要求を前記通信手段で受信したときに、前記記録ビットレート監視部から当該状態変数の値を取得して通知する第２のアクション処理部をさらに具備する。
【０００９】
また、本発明の第５の態様は、第１から第３のいずれか１つの態様において、他の機器からコンテンツの詳細情報を要求する旨のアクション要求があった場合に、現在のビットレートと判断基準の値を前記記録ビットレート監視部から取得し、取得した値をもとにプロパティを生成して通知する第３のアクション処理部をさらに具備する。
【００１０】
また、本発明の第６の態様は、第１から第５のいずれか１つの態様において、前記イベント処理部は、ＵＰｎＰ規格に基づくＸＭＬ形式で記載されたイベント通知を前記通信部から前記他の機器に対して送信する。
【００１１】
また、本発明の第７の態様は、ネットワーク上の他の機器との間で情報の交換を行うネットワーク機器であって、前記他の機器に対してイベント発行を依頼すると共に、前記他の機器からのイベント通知を受信するイベント処理部と、データを蓄積するデータ蓄積部と、前記データ蓄積部に蓄積されたデータを、他の機器に対して伝送する送信部と、前記送信部から前記他の機器へのデータ伝送の開始およびデータ伝送の終了を指示するデータ伝送部と、前記他の機器からのイベント通知に基づいて、前記他の機器の記録ビットレートの変化を検出し、前記データ伝送部による前記他の機器へのデータ伝送が完了するか否かを予測する記録ビットレート解釈部と、を具備する。
【００１２】
また、本発明の第８の態様は、第７の態様において、前記記録ビットレート解釈部は、前記データ伝送部による前記他の機器へのデータ伝送が完了しないと予測した場合に、ユーザに対する注意画面を表示する指示を情報表示部に対して行なうとともに、前記コンテンツ伝送部に対してコンテンツ伝送の停止を指示する。
【００１３】
また、本発明の第９の態様は、第７または第８の態様において、状態変数が変化したか否かを前記他の機器が判断する基準を新たに設定する旨のアクション要求を、前記他の機器に対して送信する第１のアクション処理部をさらに具備する。
【００１４】
また、本発明の第１０の態様は、第７から第９のいずれか１つの態様において、前記他の機器の現在の記録ビットレートを表わす状態変数の値を要求する旨のアクション要求を他の機器に対して行なう第２のアクション処理部をさらに具備する。
【００１５】
また、本発明の第１１の態様は、第７から第１０のいずれか１つの態様において、前記他の機器に対してコンテンツの詳細情報を要求する旨のアクション要求を行なう第３のアクション処理部をさらに具備する。
【００１６】
また、本発明の第１２の態様は、第７から第１１のいずれか１つの態様において、前記イベント処理部は、ＵＰｎＰ規格に基づくＸＭＬ形式で記載されたイベントを処理する。
【発明の効果】
【００１７】
本発明によれば、適切な基準での状態変化の通知を行うことにより、ネットワーク機器としての記録装置の記憶容量が枯渇する時期の推測を容易に行なえる。これによって、残容量がなくなる推定時刻の計算の煩雑さを解消することができる。また、状態変数を用いることにより、変化が生じた場合のみイベント発行によって通知することができる。また、状態変数に記載するビットレートの基準を変更することができるので変化通知の監視間隔を調整することができる。また、状態変数の値を取得するアクションを定義することにより、必要なときに値を取得することができる。これにより、複数台からの同時録画を許可するサーバにおいても、残量が枯渇する推定時刻をクライアントが容易に推測することができるようになる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態について詳細に説明する。ここでは、本発明をUniversal Plug and Play(以下、UPnPと呼ぶ)に適用した場合について説明する。この実施の形態において、イベント、アクション等はＵＰｎＰ規格に基づくＸＭＬ形式でやり取りされる。
【００１９】
（第１実施形態）
まず、第１実施形態の概略を説明する。第１実施形態では、HDD等のコンテンツ蓄積部の残量の単位時間当たりの減少量を記録ビットレートとして、記録ビットレート計測部が計算し、記録ビットレート監視部につたえる。記録ビットレート監視部は、記録ビットレートをUPnPの状態変数として蓄積しておき、変化があった場合、イベント処理部に変化通知を発行するように指示を出す。
【００２０】
以下、図面を参照して第１実施形態を詳細に説明する。図１は、本発明の第１実施形態にかかる記録装置の概略構成を示すブロック図である。
【００２１】
本実施形態の記録装置1-1は、他の機器（図１においては、クライアント1-20）との情報交換を行うためのTCP/IPネットワークI/F処理部1-2を持つ。また、UPnP イベントを発行するためのイベント処理部1-6を具備している。一方、クライアント1-20からのコンテンツ転送を受信するためにHTTPサーバPOSTメソッド処理部1-3および、受信したコンテンツを蓄積するコンテンツ蓄積部1-9を具備する。また、本実施形態の記録装置1-1は、記録中のビットレートを監視し、変化を検知した場合にイベント処理部1-6に対してUPnP イベントの発行を指示する記録ビットレート監視部1-7、コンテンツ蓄積部1-9の残量の単位時間当たりの減少量を計測する記録ビットレート計測部1-8を具備する。
【００２２】
本実施形態の記録装置1-1は、UPnP AVのMediaServerデバイスを実装しており、ContentDirectoryServiceのServiceDescriptionに記録ビットレートを格納する状態変数の定義を行う。
【００２３】
図3は、記録ビットレートを表す状態変数のservice description内の定義の例を示している。図３のservice descriptionでは、X_RecordingBitrateという名前（name）の状態変数が、stringタイプ、即ち文字列として（dataType）記載されており、当該状態変数がイベント可能（sendEvents=”yes”）であることを示す。
【００２４】
尚、イベント可能とは、イベント発行要求をクライアント1-20から受信すると、当該状態変数が変化した場合に、そのことを通知するイベント通知を当該クライアント1-20へ送信することが可能であることを言う。
【００２５】
即ち、本実施形態では、記録装置1-1の記録ビットレートがX_RecordingBitrateという状態変数の中に、文字列データとして格納される。さらに、クライアント1-20からイベント発行要求を受信すると、その後記録ビットレートが変化すると、記録装置1-1はイベント通知として変化した記録ビットレートを当該クライアントに送信する。
【００２６】
記録ビットレート計測部1-8は単位時間当たりのコンテンツ蓄積部1-9の残量の単位時間当たりの減少量を常に計算し、記録ビットレート監視部1-7に計算結果を通知する。コンテンツ蓄積部1-9に対して記録が行われていない場合には残量の減少割合が0であるため、記録ビットレート計測部1-8は0を記録ビットレート監視部1-7に通知し続ける。
【００２７】
次に、HTTPサーバPOSTメソッド処理部1-3からコンテンツ蓄積部1-9に対してコンテンツの記録が開始された場合、記録ビットレート計測部1-8はあらかじめ定められた間隔でコンテンツ蓄積部1-9の残容量を取得し、単位時間当たりの減少量を計測する。
【００２８】
たとえば、記録ビットレート計測部1-8は0.5秒ごとにコンテンツ蓄積部1-9の残容量を読み出し、単位時間を1秒、容量の単位をbitとして残容量の減少量をbit per second (bps)として計算し、記録ビットレート監視部1-7に対して、0.5秒ごとに、bpsを単位として残容量の減少割合を通知する。
【００２９】
以下に、図2のフローチャートを参照して記録ビットレート監視部1-7の動作を説明する。図２は、記録ビットレート監視部1-7の動作を説明するためのフローチャートである。
【００３０】
まず記録ビットレート監視部1-7は起動時に、状態変数としての記録ビットレートを格納する変数Brと、現在の記録ビットレートを格納する変数Br_nowと、BrとBr_nowとの差分の絶対値と比較する際に用いる値Gapとを初期化する(図示しない)。記録ビットレート監視部1-7は、記録ビットレート計測部1-8からの現在の記録ビットレートを受信すると、Br_nowに代入する(ステップS1-1)。
【００３１】
次に、記録ビットレート監視部1-7は、BrとBr_nowの差の絶対値が基準としてのGapよりも大きいかどうか比較する(ステップS1-2)。たとえば、Gapの値があらかじめ100k bps (100,000 bps)と設定されている場合、BrとBr_nowとの差分の絶対値が100k bpsを超えた場合にステップS1-3に進み、それ以外の場合は処理を終了する。たとえば、Br=1,000,000 bpsであり、Br_now=1,500,000 bpsである場合、差分の絶対値は500,000 bpsとなり、この値はGapの値である100,000 bpsよりも大きいため、ステップS1-3に進むことになる。即ち、記録ビットレートの変化がGap値以下である場合には、イベント通知をクライアント1-20に行わず、Gap値を超過した場合には、イベント通知が行われる。
【００３２】
次に、記録ビットレート監視部1-7は、BrにBr_nowの値を代入し記録する（ステップS1-3）。次に状態変数を更新する（ステップS1-4）。たとえば、状態変数は、文字列型として、Brの値をGapで割った値とGapの値との組み合わせで記録する。ここでは、Br=1,500,000 bpsであり、Gapは100,000 bpsであるため、状態変数の値として”15,100000bps”として記録する。
【００３３】
次に記録ビットレート監視部1-7は、イベント処理部1-6に対して更新した状態変数の値と共にイベント発行要求を行う(ステップS1-5)。
【００３４】
イベント処理部1-6は、記録ビットレート監視部1-7からのイベント発行要求に基づき、Subscribe（購読）を行っているデバイスに対して状態変化通知を行う。図4に状態変化通知のフォーマットの例を示す。図4の例では、イベント処理部1-6がGENA(General Event Notification Architecture)によって伝送するHTTPメッセージのHTTPボディのみを示している。
【００３５】
なお、この例では、コンテンツ蓄積部1-9全体の記録ビットレートのみを記載しているが、これに限られるものではない。例えば、本状態変数を、CDS(Content Directory Service)で管理するコンテナごとに計算してもよい。この場合、たとえば、ステップＳ1-2においてBrを各コンテナ毎に計算し、状態変数を各コンテナのIDとの組み合わせで表現する。  たとえば、コンテナID=HDD0, コンテナID=HDD1のそれぞれの状態変数の値を計算した場合、それぞれ、0, 15となった場合、状態変数として、”0,100000bps,HDD0,15,100000bps,HDD1”というように、コンテナIDと状態変数の組み合わせで表せばよい。
【００３６】
また、本実施形態では、記録容量がHTTP POSTリクエストによりクライアント1-20からのコンテンツ伝送によって変化することを前提にして説明したが、記録装置1-1内部の予約録画等で記録容量の残量が変化する場合についても適用することができる。
【００３７】
図１２は、第１実施形態の記録装置1-1に対応するクライアント1-20の概略構成を示すブロック図である。クライアント1-20は、他の機器（図１においては、記録装置1-1）との情報交換を行うためのTCP/IPネットワークI/F処理部1-20-1を持つ。クライアント1-20は、記録装置1-1に対してイベント発行を依頼するための処理(Subscribe処理)および、記録装置1-1からのイベント通知を受信するクライアントイベント処理部1-20-2を備えている。
【００３８】
クライアント1-20は、記録ビットレート解釈部1-20-3を備える。該記録ビットレート解釈部1-20-3は、クライアントイベント処理部1-20-2に対してイベント発行依頼を行い、コンテンツ伝送部1-20-4に対してコンテンツの伝送の指示を行う。また、記録装置1-1からのイベント通知から記録ビットレートの変化を解釈し、ユーザに対する注意画面を表示する指示を情報表示部1-20-7に対して行い、また、コンテンツ伝送部1-20-4に対してコンテンツ伝送の停止を指示する。
【００３９】
コンテンツ伝送部1-20-4は、コンテンツ蓄積部1-20-5に蓄積されたコンテンツの記録装置1-1への伝送の開始および伝送の終了を指示する。また、HTTPクライアントPOSTメソッド処理部1-20-6は、コンテンツ蓄積部1-20-5からの指示により、記録装置1-1に対してHTTP POSTメソッドを発行し、コンテンツ蓄積部1-20-5に蓄積されたコンテンツの伝送を行う。
【００４０】
以下に図１３のフローチャートを参照して上記した構成を有するクライアント1-20の動作について説明する。図１３は、クライアント1-20の動作を説明するためのフローチャートである。
【００４１】
クライアント1-20は、UPnP CDS(Content Directory Service) アクション等により、記録装置1-1の残容量R0を取得し、記録ビットレート解釈部1-20-3に設定しておく(図示しない)。
【００４２】
次に、記録ビットレート解釈部1-20-3の指示により、クライアントイベント処理部1-20-2から記録装置1-1に対してイベント発行要求を送信する（ステップＳ20-1）。尚、このとき送信するイベント発行要求は、記録装置1-1の状態変数の変化、即ち記録ビットレートの変化をイベントとしてクライアント1-20へ通知（イベント通知）することを要求するものである。
【００４３】
続いて、記録ビットレート解釈部1-20-3は、コンテンツ蓄積部1-20-5から伝送を行うコンテンツの容量S0(bit単位のサイズ)を取得し(ステップＳ20-2)、コンテンツ伝送部1-20-4に対してそのコンテンツを伝送するように指示する(ステップＳ20-3)。更に記録ビットレート解釈部1-20-3は、コンテンツが全て転送されコンテンツ伝送が終了したか否かの判断を行い(ステップＳ20-4)、終了した場合は、処理を終了する。
【００４４】
一方、コンテンツの伝送が終了していない場合は、記録ビットレート解釈部1-20-3は、記録装置1-1の記録ビットレートが変化したかどうかの判断を行う(ステップＳ20-5)。このステップでは、記録装置1-1からイベントによって通知される記録ビットレートをもとに判断を行う。即ち、前回のS20-4の判断時と今回のS20-4の判断時との間に、記録装置1-1から記録ビットレートが変化した旨のイベント通知を受信したか否かにより判断を行う。ステップＳ20-5の判断結果が偽(NO)の場合は、現在までに伝送が完了したデータ量S1(bit単位のサイズ)とコンテンツ伝送経過時間Tm(秒単位)、及び記録ビットレートから、コンテンツの伝送が完了する予測終了時刻T1を計算し(ステップＳ20-6)、ステップＳ20-4に戻る。
【００４５】
一方、ステップＳ20-5の判断結果が真(YES)の場合は、伝送開始時に取得しておいた空き容量R0(bit単位のサイズ)および伝送が完了したデータ量S1(bit単位のサイズ)から、現在の予想空き容量Rm(bit単位のサイズ)を計算し、新たに取得した記録ビットレートB1（bps単位。bpsはbit per secの略であり単位秒あたりのbit数を表す）と予想空き容量Rmから空き容量がなくなる時刻T2(秒単位)を計算する(ステップＳ20-7)。
【００４６】
たとえば、伝送完了予想時刻T1(秒単位)はT1 = (Tm / S1) * (S0 -S1)で計算される。また、予想空き容量RmはRm = R0 - S1で計算されるので、空き容量がなくなると予想される時刻T2は、T2 = Rm / B1となる。
【００４７】
次に記録ビットレート解釈部1-20-3はT2がT1よりも小さいかどうか判断し(ステップＳ20-8)、T2のほうが小さい場合は、伝送が完了する前に記録機器の空き容量がなくなることが予想されるためステップＳ20-9に進む。
【００４８】
まず記録ビットレート解釈部1-20-3は、伝送が完了する前に空き容量がなくなることを情報表示部1-20-7を用いてユーザに注意喚起を行う(ステップＳ20-9)。より具体的には例えば、記録ビットレート解釈部1-20-3は情報表示部1-20-7に、表示画面（図示せず）に注意喚起を即すウィンドウを表示させる。このような注意喚起を行った後、記録ビットレート解釈部1-20-3は、コンテンツ伝送部1-20-4にコンテンツの伝送を中止させる(ステップＳ20-10)。なお、ステップＳ20-10における伝送の中止は、本実施の形態では自動的に行っているが、注意喚起を受けたユーザの指示により行ってもよい。
【００４９】
上記した第１実施形態によれば、記録ビットレート監視部がコンテンツ蓄積部の残量の単位時間当たりの減少量を監視し、減少量をGap値と比較してイベント発行の指示を行うことにより、適度な基準で状態変化通知がクライアントに通知される。これにより、クライアントは記録装置の記憶容量の枯渇する時刻の推測を容易に行なえる。
【００５０】
（第２実施形態）
第2実施形態の概略を説明する。第２実施形態では、記録ビットレート監視部が記憶する、状態変数の変化を通知する基準であるGap値(たとえば、1K bpsや10K bpsなど)を設定するためのSOAP アクションを実装し、クライアントからのアクション要求によって、この基準であるGap値を変更する。基準が変更された場合は、記憶している状態変数の値を新たに指定された基準に変更し、イベント処理部に対して変化通知の発行を要求する。以下、図面を参照して第２実施形態を詳細に説明する。
【００５１】
図５は、本発明の第２実施形態にかかる記録装置の概略構成を示すブロック図である。本実施形態の記録装置1-1は、他の機器（図5においては、クライアント1-20）との情報交換を行うためのTCP/IPネットワークI/F処理部1-2を持つ。また、UPnP イベントを発行するためのイベント処理部1-6および、UPnP アクションを処理するためのアクション処理部1-4を具備している。
【００５２】
一方、他の機器からのコンテンツ転送を受信するためにHTTPサーバPOSTメソッド処理部1-3および、コンテンツを蓄積するコンテンツ蓄積部1-9を具備する。また、本実施形態の記録装置1-1は、記録中のビットレートを監視し、変化を検知した場合にイベント処理部1-6に対してUPnP イベントの発行を指示する記録ビットレート監視部1-7、コンテンツ蓄積部1-9の残量の単位時間当たりの減少量を計測する記録ビットレート計測部1-8を具備する。
【００５３】
本実施形態の記録装置は、UPnP AVのMediaServerデバイスを実装しており、ContentDirectoryServiceのServiceDescriptionに、図6に示すような記録ビットレートの変化を比較する際の基準となるGapを設定するアクションの定義および、設定するアクションで用いる引数に対する状態変数の定義、記録ビットレートを格納する状態変数の定義を行う。
【００５４】
図６の例では、X_SetRecordingBitrateGapという名前のアクションが定義されており、このアクションには、Gapという名前（name）の入力（direction、in）変数（argument）がアクション受信に与えられる。このアクションにより、状態変数（relatedStateVariable）X_ARG_TYPE_RecordingBitrateGapが変更される。即ち、Gap値が変更される。
【００５５】
尚、この状態変数（StateVariable）X_ARG_TYPE_RecorgingBitrateGapはイベント不能（sendEvents=”no”）であり、データ型（dataType）は文字列型（string）として記憶される。イベント不能とは、当該状態変数が変更されても、クライアントにイベント通知が発行されないことを言う。
【００５６】
また、記録ビットレート値を示す、イベント可能なX_RecordingBitrateという状態変数も有する。この点については実施形態１と同様であるので説明を省略する。
【００５７】
このように本実施形態は、図５に示す、ビットレートの変化を比較する際のGapの値を設定するアクションを処理するためのアクション処理部1-4を追加している点が第１の実施形態と異なる。
【００５８】
以下に、図6に示したX_SetRecordingBitrateGapのアクションがクライアント1-20から呼び出された際の記録装置1-1の動作を、図7を参照して説明する。
【００５９】
アクション処理部1-4は、X_SetRecordingBitrateGapアクション要求をクライアント1-20から受信すると(ステップＳ7-1)、X_SetRecordingBitrateGapアクションの入力変数である、Gapの値を解析する(ステップＳ7-2)。次にアクション処理部1-4はフォーマット誤り等のエラーがあるかどうか判断し(ステップＳ7-3)、エラーがある場合は、TCP/IPネットワークI/F処理部からエラーレスポンスを返答し(ステップＳ7-9)、処理を終了する。
【００６０】
一方、誤りがない場合は、アクション処理部1-4は、X_SetRecordingBitrateGapアクションの入力変数のGapの値と、記録ビットレート監視部1-7において状態変数計算に用いるGapの値と比較し(ステップＳ7-4)、同じ値の場合は、成功レスポンスを返答し(ステップＳ7-8)、処理を終了する。一方、入力変数Gapの値と、状態変数計算に用いるGapの値が異なる場合は、アクション処理部1-4は入力変数Gapの値をGapに代入する(ステップＳ7-5)。
【００６１】
たとえば、Gapの値が100,000 bps（bpsはbit per secの略であり単位秒あたりのbit数を表す）である場合に、X_SetRecordingBitrateGapの入力変数Gapの値が500,000 bpsである場合、Gapの値を500,000 bpsに設定する。次に、記録ビットレート監視部1-7は、新たに設定したGapの値を基に、状態変数の値を再計算する(ステップＳ7-6)。たとえば、Br=1,500,000 bpsである場合、新たに設定されたGap値500,000 bpsを基に、新たな状態変数の値として、”3,500000bps”（“３”は、1,500,000をGap値500,000で割った値）を取得し、記録する。
【００６２】
次に、アクション処理部1-4はイベント処理部1-6に対して、新たに計算した状態変数の値を基にイベント発行要求を行う(ステップＳ7-7)。その後、アクション処理部1-4は成功レスポンス(ステップＳ7-8)を発行して処理を終了する。
【００６３】
記録ビットレート監視部1-7は、図7のフローチャートによって設定されたGap値を用いて図２のフローチャートに示す手順に従い記録ビットレートの監視、イベント発行を行う。
【００６４】
図14は第２実施形態の記録装置1-1に対応するクライアント1-20の概略構成を示すブロック図である。図14のクライアント1-1は、クライアントアクション処理部1-20-8を持ち、クライアントアクション処理部1-20-8を通して、記録装置1-1が公開するX_SetRecordingBitrateGapアクションを呼び出すことにより、Gap値を変更することができる。
【００６５】
尚、イベント通知による記録ビットレート取得に係る処理の流れについては、第１の実施形態（図１３）と同様であるので説明を省略する。
【００６６】
上記した第２実施形態によれば、記録装置1-1のアクション処理部1-4によって、クライアント1-20からGap値を設定するようにしたので、クライアント1-20が監視するときのビットレートの基準を設定できるようになる。これにより、クライアント1-20は記録装置1-1の記憶容量の枯渇する時刻の推測の正確さを調整できるようになる。
【００６７】
（第３実施形態）
第３実施形態では、現在の状態変数の値を取得するためのアクションを実装し、クライアントからのアクション要求によって現在の状態変数の値を返答する。以下、図面を参照して第３実施形態を詳細に説明する。
【００６８】
第３実施形態の概略構成は図5と同様である。ただし、アクション処理部1-4の機能が異なる。図8は、本実施形態のContentDirectoryServiceのServiceDescriptionの記載の一例を示している。図８の例では、X_GetCurrentRecordingBitrateという名前のアクションが定義されている。このX_GetCurrentRecordingBitrateというアクションは、CurrentRecordingBitrateという名前（name）の出力（direction、out）変数（argument）を有する。このCurrentRecordingBitrateには、記録ビットレートの状態変数（relatedStateVariable）であるX_RecordingBitrateの値が入力される。即ちCurrentRecordingBitrateというアクションをクライアントが送信することにより、クライアントは戻り値（出力変数）として記録ビットレートの値を取得することができる。
【００６９】
つまり、図８のServiceDescriotion例では、現在の記録ビットレートを表す状態変数の値を取得するアクションを定義している。図５のアクション処理部1-4はX_GetCurrentRecordingBitrateアクションを受信すると、記録ビットレート監視部1-7から現在の記録ビットレートの状態変数の値を取得し、その値をレスポンスとして返答する。
【００７０】
図９はX_GetCurrentRecordingBitrateアクションに対してアクション処理部1-4が返すレスポンスのHTTP ボディの例を示している。戻り値であるX_RecordingBitrateの値が”15,100000bps”となっているので、Gap値が100000bpsであり、記録ビットレートBrは、100000×15= 1,500,000bpsである。bpsはbit per secの略であり単位秒あたりのbit数を表す。
【００７１】
第３実施形態の記録装置1-1に対応するクライアント1-20のブロック図は前記した図１４と同様となるので説明を省略する。図１５は、本実施形態に係るクライアント1-20の動作を示すフローチャートである。
【００７２】
以下に図１５のフローチャートを参照してクライアント1-20の動作の説明を行う。クライアント1-20は、UPnP CDS:Browse Action(ブラウズアクション)等により、記録装置1-1の残容量R0を取得し、記録ビットレート解釈部1-20-3に設定しておく(図示しない)。次に、記録ビットレート解釈部1-20-3の指示により、クライアントアクション処理部1-20-8は記録装置1-1に対してX_GetCurrentRecordingBitrate アクション発行依頼を行い、現在の記録ビットレートを取得する（ステップＳ21-1）。
【００７３】
次に、記録ビットレート解釈部1-20-3はコンテンツ蓄積部1-20-5から、伝送を行うコンテンツの容量S0(bit単位のサイズ)を取得し(ステップＳ21-2)、そのコンテンツを伝送するようにコンテンツ伝送部1-20-4に指示する(ステップＳ21-3)。次に、記録ビットレート解釈部1-20-3はコンテンツが全て転送されコンテンツ伝送が終了したか否かの判断を行い(ステップＳ21-4)、終了した場合は、処理を終了する。
【００７４】
また、コンテンツの伝送が終了していない場合は、クライアントアクション処理部1-20-8は記録ビットレート解釈部1-20-3の指示によりX_GetCurrentRecordingBitrate アクションを規則装置1-1に送信して現在の記録ビットレートを取得し(ステップＳ21-5)、記録ビットレート解釈部1-20-3は記録ビットレートが変化したかどうか否かの判断を行う(ステップＳ21-6)。ステップＳ21-6の判断結果が偽(NO)の場合は、現在伝送したデータ量S1とコンテンツ伝送経過時間Tm(秒単位)から予測終了時刻T1(秒単位)を計算し(ステップＳ21-7)、ステップＳ20-4に戻る。
【００７５】
一方、真(YES)の場合は、伝送開始時に取得しておいた空き容量R0(bit単位のサイズ)および伝送が完了したデータ量S1(bit単位のサイズ)から、現在の予想空き容量Rm(bit単位のサイズ)を計算し、新たに取得した記録ビットレートB1(bps単位)と予想空き容量Rmから空き容量がなくなる時刻T2（秒単位）を計算する(ステップＳ21-8)。
【００７６】
例えば伝送完了予想時刻T1はT1 = (Tm / S1) * (S0 -S1)で計算される。また、予想空き容量RmはRm = R0 - S1で計算され、空き容量がなくなると予想される時刻T2は、T2 = Rm / B1である。
【００７７】
次に記録ビットレート解釈部1-20-3はT2がT1よりも小さいかどうか判断し(ステップＳ21-9)、T2のほうが小さい場合は、伝送が完了する前に記録機器の空き容量がなくなることが予想されるためステップＳ21-10に進む。
【００７８】
まず記録ビットレート解釈部1-20-3は、伝送が完了する前に空き容量がなくなることを情報表示部1-20-7を用いてユーザに注意喚起を行い(ステップＳ21-10)、続いてコンテンツの伝送を中止する(ステップＳ21-11)。なお、ステップＳ21-11における伝送の中止は、本実施形態では自動的に行っているが、注意喚起を受けたユーザの指示によって行ってもよい。また、ステップＳ21-5における記録ビットレートの取得は、一定時間待ってから取得するといった方法でもよい。
【００７９】
上記した第３実施形態によれば、アクション処理部1-4によって、クライアント1-20から現在の記録ビットレートを表す状態変数の値を取得することができることにより、クライアント1-20は必要なときに記録ビットレートの値を取得することができるようになる。
【００８０】
（第４実施形態）
図１０は、本発明の第４実施形態にかかる記録装置の概略構成を示すブロック図である。以下に、この概略ブロック図を参照して本装置の動作を説明する。
【００８１】
本実施形態の記録装置1-1は、他の機器（図１０においては、クライアント1-20）との情報交換を行うためのTCP/IPネットワークI/F処理部1-2を持つ。また、UPnP イベントを発行するためのイベント処理部1-6および、UPnP アクションを処理するためのアクション処理部1-4を具備している。一方、他の機器からのコンテンツ転送を受信するためにHTTPサーバPOSTメソッド処理部1-3および、コンテンツを蓄積するコンテンツ蓄積部1-9を具備する。
【００８２】
また、本実施形態の記録装置1-1は、記録中のビットレートを監視し、変化を検知した場合にイベント処理部1-6に対してUPnP イベントの発行を指示する記録ビットレート監視部1-7、コンテンツ蓄積部1-9の残量の単位時間当たりの減少量を計測する記録ビットレート計測部1-8を具備する。
【００８３】
本実施形態のアクション処理部1-4は、第２実施形態および第３実施形態の記録ビットレートのGap値を設定するアクションと、現在の記録ビットレートを取得するアクションの処理に加えて、CDS:ブラウズリクエストに対して、現在の記録ビットレートの値をプロパティとして返答する機能を持つ点が異なる。
【００８４】
図１１は、記録ビットレートを表すプロパティの一例を示している。図１１は、CDSで管理するルートコンテナに対するCDS:ブラウズの結果の例である。本例では、現在のビットレートを表すプロパティとして、av:RecordingBitrateエレメントで表し、現在のGapの値をav:unitアトリビュートで表している。また、xmlのname spaceとして、xmlns:av=”urn:schemas-toshiba-co-jp:metadata-1-0/av/”を用いている。
【００８５】
図１１の例では、総容量が1,000,000,000Bytes、空き容量が800,000,000Bytesである例である。なお、av:RecordingBitrateエレメントはルートコンテナのみに付加するものとしてもよいし、各コンテナに持ってもよい。CDS:ブラウズリクエストを本実施形態の装置がCDS:ブラウズリクエストを受信すると、アクション処理部1-4は、記録ビットレート監視部1-7に対して現在の記録ビットレートおよびGapの値を要求し、得た値から図１１に示すプロパティを生成しCDS:ブラウズレスポンスのresult出力変数を生成してレスポンスを返答する。
【００８６】
第４実施形態の記録装置1-1に対応するクライアント1-20のブロック図は前記した図１４と同様となるので説明を省略する。図１６は、本実施形態に係る、クライアント1-20の動作を示すフローチャートである。
【００８７】
以下に図１６のフローチャートを参照してクライアント1-20の説明を行う。クライアント1-20は、記録ビットレート解釈部1-20-3の指示により、アクション処理部1-4から記録装置1-1に対してCDS:ブラウズ アクション発行依頼を行い、現在の記録ビットレートと空き容量とを取得する（ステップＳ22-1）。この際、CDS:ブラウズアクションによって取得した空き容量の単位はByteであるため、bit単位に変換を行う。
【００８８】
次に、記録ビットレート解釈部1-20-3は、コンテンツ蓄積部1-20-5から伝送を行うコンテンツの容量S0(サイズ)を取得し(ステップＳ22-2)、コンテンツ伝送部1-20-4に対し、そのコンテンツを伝送するように指示する(ステップＳ22-3)。
【００８９】
次に、記録ビットレート解釈部1-20-3は、コンテンツが全て転送しコンテンツ伝送が終了したか否かの判断を行い(ステップＳ22-4)、終了した場合は、処理を終了する。コンテンツの伝送が終了していない場合は、CDS:ブラウズアクションにより現在の記録ビットレートを取得し(ステップＳ22-5)、記録ビットレートが変化したかどうかの判断を行う(ステップＳ22-6)。ステップＳ21-6の判断結果が偽(NO)の場合は、現在伝送したデータ量S1(bit単位のサイズ)とコンテンツ伝送経過時間Tm（秒単位）から予測終了時刻T1（秒単位）を計算し(ステップＳ22-7)、ステップＳ22-4に戻る。
【００９０】
一方、真(YES)の場合は、伝送開始時に取得しておいた空き容量R0(bit単位のサイズ)および伝送が完了したデータ量S1から、現在の予想空き容量Rm(bit単位のサイズ)を計算し、新たに取得した記録ビットレートB1(bps単位)と予想空き容量Rmから空き容量がなくなる時刻T2(秒単位)を計算する(ステップＳ22-8)。
【００９１】
例えば伝送完了予想時刻T1は、T1 = Tm * ((S0 - S1) / S1)で計算される。  また、予想空き容量RmはRm = R0 - S1で計算され、空き容量がなくなると予想される時刻T2は、T2 = Rm / B1として計算される。
【００９２】
次にT2がT1よりも小さいかどうか判断し(ステップＳ22-9)、T2のほうが小さい場合は、伝送が完了する前に記録機器1-1の空き容量がなくなることが予想されるため、ステップＳ22-10に進む。
【００９３】
ステップＳ22-10では、伝送が完了する前に空き容量がなくなることを情報表示部1-20-7を用いてユーザに注意喚起を行い、コンテンツの伝送を中止する(ステップＳ22-11)。なお、ステップＳ22-11における伝送の中止は、本実施形態では、自動的に行っているが、注意喚起を受けたユーザの指示によって行ってもよい。また、ステップＳ22-5における記録ビットレートの取得は、一定時間待ってから取得するといった方法でもよい。
【００９４】
上記した第４実施形態によれば、記録ビットレートをUPnPのプロパティとして定義することにより、コンテナ毎に異なる記録容量を持つ記録装置1-1においてもそれぞれの記録装置1-1に対する記録レートを取得することができる。これにより、クライアント1-20はCDS:ブラウズを発行することにより、残容量と記録ビットレートを一度のアクションで取得でき、コマンドの発行数を減らすことができる。
【図面の簡単な説明】
【００９５】
【図１】図１は、本発明の第１実施形態にかかる記録装置の概略構成を示すブロック図である。
【図２】記録ビットレート監視部1-7の動作を説明するためのフローチャートである。
【図３】記録ビットレートを表す状態変数のservice description内の定義を示す図である。
【図４】状態変化通知のフォーマットを示す図である。
【図５】本発明の第２実施形態にかかる記録装置の概略構成を示すブロック図である。
【図６】第２実施形態のServiceDescriptionの記載の一例を示す図である。
【図７】Gap値設定のアクションの詳細を示すフローチャートである。
【図８】ContentDirectoryServiceのServiceDescriptionの記載の一例を示す図である。
【図９】X_GetCurrentRecordingBitrateアクションのレスポンスのHTTP Bodyを示す図である。
【図１０】本発明の第４実施形態にかかる記録装置の概略構成を示すブロック図である。
【図１１】記録ビットレートを表すプロパティの一例を示す図である。
【図１２】第１実施形態の記録装置に対応するクライアントの概略構成を示すブロック図である。
【図１３】図１２に示すクライアント1-20の動作を説明するためのフローチャートである。
【図１４】第２、第３、第４実施形態の記録装置に対応するクライアントの概略構成を示すブロック図である。
【図１５】第３実施形態の記録装置に対応するクライアント1-20の動作を説明するためのフローチャートである。
【図１６】第４実施形態の記録装置に対応するクライアント1-20の動作を説明するためのフローチャートである。
【符号の説明】
【００９６】
1-1  記録装置
1-2  TCP/IPネットワークI/F処理部
1-3  HTTPサーバPOSTメソッド処理部
1-6  イベント処理部
1-7  記録ビットレート監視部
1-8  記録ビットレート計測部
1-9  コンテンツ蓄積部
1-20  クライアント
【図１】
2007184844.tif 000003
【図２】
2007184844.tif 000004
【図３】
2007184844.tif 000005
【図４】
2007184844.tif 000006
【図５】
2007184844.tif 000007
【図６】
2007184844.tif 000008
【図７】
2007184844.tif 000009
【図８】
2007184844.tif 000010
【図９】
2007184844.tif 000011
【図１０】
2007184844.tif 000012
【図１１】
2007184844.tif 000013
【図１２】
2007184844.tif 000014
【図１３】
2007184844.tif 000015
【図１４】
2007184844.tif 000016
【図１５】
2007184844.tif 000017
【図１６】
2007184844.tif 000018