(57)【要約】クライアント機器から最初に物理的なコネクションが要求される場合においても、内部的に論理的なコネクションを確立し、適切に複数のクライアント機器とのコネクションを管理することができるサーバ機器を提供する。  通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、  コンテンツデータ配信手段の物理コネクション、及び前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理手段とを備え、  前記通信手段が前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合に、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクションＩＤの確認処理を行い、前記コネクションＩＤの確認ができない場合には、前記コネクション管理手段に対して前記コネクションＩＤの生成要求を行うことを特徴とするＡＶサーバ機器。【特許請求の範囲】
【請求項１】
ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器であって、
通信パケットを送受信する通信手段と、
前記通信手段を用いて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信手段と、
前記コンテンツデータを蓄積するコンテンツデータ蓄積手段と、
前記通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、
前記コンテンツデータ配信手段の前記物理コネクション、及び前記プロトコル処理手段の前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理手段とを備え、
前記通信手段が前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクションＩＤの確認処理を行い、
前記コンテンツデータ配信手段は、前記コネクションＩＤの確認ができない場合には、前記コネクション管理手段に対して前記コネクションＩＤの生成要求を行う
ことを特徴とするＡＶサーバ機器。
【請求項２】
前記コネクション管理手段は、前記コネクションＩＤの生成要求を受けた場合には、コネクションＩＤを生成し、前記コンテンツデータ配信手段に応答し、
前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信手段は、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項３】
前記コンテンツデータ配信手段は、前記コネクションＩＤの確認ができる場合には、前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信手段は、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項４】
前記コンテンツデータ配信手段は、前記通信手段を介して取得した前記クライアント機器のアドレス情報を前記コネクション管理手段に提供し、
前記コネクション管理手段は、前記アドレス情報を用いて前記クライアント機器とのコネクションを識別する前記コネクションＩＤの有無を確認する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項５】
前記アドレス情報は、前記クライアント機器のＩＰアドレス又はＭＡＣアドレスである
ことを特徴とする請求項４記載のＡＶサーバ機器。
【請求項６】
前記コネクション管理手段は、少なくとも前記ＡＶサーバ機器に接続された各クライアント機器のアドレス情報と、前記論理コネクション確立の優先度との関係が記述された優先度テーブルを管理し、
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持する前記コネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理手段は、前記優先度テーブルを参照して、優先度の高いクライアント機器からの削除要求である場合に前記コネクション管理手段が保持する前記コネクションＩＤを消去する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項７】
前記コネクション管理手段は、少なくとも前記コネクションＩＤと、前記論理コネクションの生成先となるクライアント機器のアドレス情報、前記物理コネクションの接続先となるクライアント機器のアドレス情報、前記コンテンツのサービス情報、及び前記クライアント機器毎に付与されている前記論理コネクション確立の優先度の少なくとも１つが記載されたコネクション管理情報を管理し、
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、予め定められたコネクションＩＤが付与されている場合には、前記コネクション管理手段が保持する前記コネクションＩＤを消去しない
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項８】
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、前記コネクションＩＤを生成したクライアント機器かをアドレス情報を用いて判別し、前記コネクションＩＤを生成したクライアント機器以外からの要求である場合には、前記コネクション管理手段が保持する前記コネクションＩＤを消去しない
ことを特徴とする請求項７記載のＡＶサーバ機器。
【請求項９】
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、前記コネクションＩＤと関連付けられた前記サービスの種類に応じて前記コネクション管理手段が保持する前記コネクションＩＤを消去しない
ことを特徴とする請求項７記載のＡＶサーバ機器。
【請求項１０】
前記プロトコル処理手段は、前記通信手段を介して前記クライアント機器から前記コネクション管理手段において保持するコネクションＩＤ情報を閲覧するためのコマンドを受信した際に、前記コマンドの応答として、前記コネクション管理情報を付与して返信する
ことを特徴とする請求項７記載のＡＶサーバ機器。
【請求項１１】
前記コネクション管理手段は、コンテンツデータに対する配信要求が継続して行われていない場合、又はコンテンツデータに対する配信要求が一定期間なくなった場合において前記コネクションＩＤを消去する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１２】
前記コネクション管理手段は、配信要求がなくなった配信先の前記クライアント機器のアドレス情報に基づいて前記コネクションＩＤを消去する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１３】
前記コンテンツデータ配信手段は、コンテンツに対する配信要求が継続中に、コンテンツに対する配信要求受信時において、前記コネクション管理手段に前記コネクションＩＤの存在有無を確認し、前記コネクションＩＤが消去されていた場合においては、前記通信手段を介してコンテンツに対する配信要求でエラーを返した上で、前記クライアント機器とのコネクションの切断を行う
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１４】
前記コンテンツデータ配信手段は、コンテンツに対する配信要求が継続中に、コンテンツ配信時において、前記コネクション管理手段に前記コネクションＩＤの存在有無を確認し、前記コネクションＩＤが消去されていた場合においては、前記通信手段を介してコンテンツを配信せずに、前記クライアント機器とのコネクションの切断を行う
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１５】
前記コンテンツデータ配信手段は、前記コネクションＩＤが消去されているかどうかを、配信要求先となるクライアント機器のアドレス情報から判別する
ことを特徴とする請求項１３又は１４記載のＡＶサーバ機器。
【請求項１６】
ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器に用いるコネクション管理方法であって、
通信パケットを送受信する通信ステップと、
前記通信ステップにおいて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信ステップと、
前記コンテンツデータを蓄積するコンテンツデータ蓄積ステップと、
前記通信ステップにおいて論理コネクションの管理を行うコマンドを処理するプロトコル処理ステップと、
前記コンテンツデータ配信ステップにおける前記物理コネクション、及び前記プロトコル処理ステップにおける前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理ステップとを含み、
前記通信ステップにおいて前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信ステップにおいては、前記コネクション管理ステップにおける前記コネクションＩＤの確認処理を行い、
前記コンテンツデータ配信ステップにおいては、前記コネクションＩＤの確認ができない場合には、前記コネクション管理ステップにおける前記コネクションＩＤの生成要求を行う
ことを特徴とするコネクション管理方法。
【請求項１７】
前記コネクション管理ステップにおいては、前記コネクションＩＤの生成要求を受けた場合には、コネクションＩＤを生成し、
前記コンテンツデータ配信ステップにおいては、前記コンテンツデータ蓄積ステップにおけるコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信ステップにおいては、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１６記載のコネクション管理方法。
【請求項１８】
ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器に用いるプログラムであって、
通信パケットを送受信する通信ステップと、
前記通信ステップにおいて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信ステップと、
前記コンテンツデータを蓄積するコンテンツデータ蓄積ステップと、
前記通信ステップにおいて論理コネクションの管理を行うコマンドを処理するプロトコル処理ステップと、
前記コンテンツデータ配信ステップにおける前記物理コネクション、及び前記プロトコル処理ステップにおける前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理ステップとをコンピュータに実行させ、
前記通信ステップにおいて前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信ステップにおいては、前記コネクション管理ステップにおける前記コネクションＩＤの確認処理を行い、
前記コンテンツデータ配信ステップにおいては、前記コネクションＩＤの確認ができない場合には、前記コネクション管理ステップにおける前記コネクションＩＤの生成要求を行う
ことを特徴とするプログラム。
【請求項１９】
前記コネクション管理ステップにおいては、前記コネクションＩＤの生成要求を受けた場合には、コネクションＩＤを生成し、
前記コンテンツデータ配信ステップにおいては、前記コンテンツデータ蓄積ステップにおけるコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信ステップにおいては、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１８記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、宅内ネットワーク等を介してクライアント機器に音楽や動画などのＡＶコンテンツ等を提供するＡＶサーバ機器に関し、特に、宅内にある複数のクライアント機器にＡＶコンテンツを送信するＡＶサーバ機器に関する。
【背景技術】
【０００２】  近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のＰＣや家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。この様な中で、パーソナルコンピュータ（ＰＣ）だけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）により定義されるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）により相互に接続できるようになってきている。【０００３】  インターネットやホームネットワークにおけるアプリケーションの１つとして、家電機器やＰＣ間で音楽や動画などのＡＶコンテンツを視聴するアプリケーションがある。例えば、ＤＶＤレコーダに録画した放送番組を、ネットワークに接続されたＴＶやＰＣなどで視聴するＡＶストリーミング機能を提供する例などである。【０００４】  この様なＡＶストリーミングを行うプロトコルでは、代表的なものとしては、ＲＦＣ２６１６で定義されるＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、ＲＦＣ１８８９で定義されるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）等が存在した。特に、ＨＴＴＰはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）の再送機能によって転送の信頼性を確保している。すなわち、ＴＣＰはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正しいファイルの転送が保障できる。【０００５】  そして、伝送エラーが発生しやすいネットワーク環境では、データの再送信のためにスループットが低下するといった特徴があり、このため、ＴＣＰは、ホームネットワークのような伝送路上のエラーやパケット欠落が発生し易い環境下におけるＡＶストリーミングに向いており、ＵＰｎＰ  ＡＶ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ  Ａｕｄｉｏ／Ｖｉｄｅｏ  Ａｒｃｈｉｔｅｃｔｕｒｅ）や、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ）などの基本的なＡＶストリーミング方式となっている。【０００６】  しかしながら、ＨＴＴＰでのＡＶストリーミングは信頼性が高い反面、リアルタイム性を保持するためにはＡＶサーバ機器側のリソースに依存する。例えば高ビットレートの転送速度が要求される蓄積データや、複数同時アクセスされた場合などには、スループットを見据えてＡＶサーバ機器側でリソース配分の管理を行う必要がある。リソース配分の管理方法としては、（１）ＨＴＴＰメッセージの送受信を行うためのＴＣＰコネクションの本数を制限するなどが考えられる。この場合、制限を超えて後からネットワーク再生をリクエストしようとしたクライアント機器に対しては、一般にエラーメッセージが送信されるか、またはリクエストそのものが無視され、先にコネクションを確立したクライアント機器は、ＡＶコンテンツの視聴を継続して楽しめる。これは先にコネクション確立を行った機器を優先する“���取り優先”の考え方である。この“先取り優先”の考え方は、物理コネクションに代表されるものである。【０００７】  一方、（２）ＵＰｎＰ  ＡＶにはコネクション管理のためのＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｒ  Ｓｅｒｖｉｃｅ）というものがあり、論理的なコネクションの確立・切断を行うためのコマンド（ＳＯＡＰ  Ａｃｔｉｏｎ）が存在する。具体的には、コネクションを確立するためのコマンドがＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎであり、このコマンドを受信したＡＶサーバ機器は、サーバ内部においてリソースの空きがあればＩＤを発行する。また、コネクションを切断したい場合においてはＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅをＡＶサーバ機器に送信することで、ＡＶサーバ機器はリソースの解放を行う。ＣＭＳは論理的なコネクション確立をするものであるため、ＨＴＴＰにおけるＡＶストリーミングと連動するために、ＨＴＴＰヘッダ等にＩＤを付与するなどの関連付けすることが一般的である。【０００８】  そして、ＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅは、必ずしもＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎにてＩＤを取得した機器のみが出来るわけではないため、ＡＶサーバ機器においてリソース配分されているＩＤを閲覧するためのコマンドであるＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓを発行した上で、ＩＤを知る事が出来、更にＩＤを解放するためにＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅをＡＶサーバ機器に送信することで、先にコネクションを確立したクライアント機器を、後から別のクライアント機器が切断することも可能である。これは後からコネクション確立を要求した方が優先される“後取り優先”の考え方である。この“後取り優先”の考え方は、論理コネクションに代表されるものである。【０００９】  このように、（２）においては、ＴＣＰコネクションの本数とは別に、ＣＭＳによる論理的なコネクションの本数によってリソース管理をする方法となる。【００１０】  上記のことは、例えば特許文献１、並びに特許文献２に開示されている。
【特許文献１】特開２００２−８４４８４号公報
【特許文献２】特開２００４−３４８４５４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】  前述した通り、物理コネクションであるＴＣＰコネクションの本数などでリソース管理する方法は、“先取り優先”の考え方であるのに対し、論理コネクションを用いるＵＰｎＰＡＶのＣＭＳなどでリソース管理する方法は、“後取り優先”の考え方である。【００１２】  例えば、（１）ＴＣＰコネクションの本数によりリソース管理する方法と、ＣＭＳなどの論理的なコネクションの本数によりリソース管理する方法を併用して用いるＡＶサーバ機器においては、ＨＴＴＰリクエストのみでＡＶコンテンツ要求された場合には先取り優先の機能が働くため、後からＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎなどで要求された場合において、リソースが割り振れず、かつＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅなどでリソースを解放することも出来ないという課題を有している。
また、（２）ＣＭＳなどの論理的なコネクションの本数だけでリソース管理する方法を用いたＡＶサーバ機器においては、常に後取り優先の機能が働くため、ビデオオンデマンドなどの個人で楽しむサービスを提供した時に、いつ何時、誰からでも視聴を中断されるという課題を有している。【００１３】  さらに、（３）今後、宅内の１つのＡＶサーバ機器に家族の各々のクライアント機器が宅内ネットワークを介して接続してコンテンツ視聴するような環境が考えられ、そのような場合には、ＡＶサーバ機器において有効なコネクション本数のリソース管理を適切に行うために、主にＵＰｎＰに基づくＡＶコンテンツ配信においては、コンテンツの実体を配信するための物理コネクションの確立前に、論理コネクションの確立が要求されるようになる。しかしながら、現状のクライアント機器においては、最初に物理コネクションを用いてコンテンツ取得要求を行う機器が一般的であり、このような場合には、図１３のＳ１３４に示すように、ＡＶサーバ機器１４０においては論理コネクションのＩＤ確認ができず、コネクションなしとしてエラー返信（Ｓ１３６）を行うために、クライアント機器１３０は要求するコンテンツが取得できないという課題もある。【００１４】  本発明は、上記従来の課題を解決するもので、ＡＶコンテンツを要求するクライアント機器とのコネクションにおいて、物理コネクション及び論理コネクションを併用して、コネクションの“先取り優先”及び“後取り優先”を実現したＡＶサーバ機器を提供することを目的とする。
【課題を解決するための手段】
【００１５】  上記目的を達成するために、本発明に係るＡＶサーバ機器は、ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器であって、通信パケットを送受信する通信手段と、前記通信手段を用いて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信手段と、前記コンテンツデータを蓄積するコンテンツデータ蓄積手段と、前記通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、前記コンテンツデータ配信手段の前記物理コネクション、及び前記プロトコル処理手段の前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理手段とを備え、前記通信手段が前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクションＩＤの確認処理を行い、前記コンテンツデータ配信手段は、前記コネクションＩＤの確認ができない場合には、前記コネクション管理手段に対して前記コネクションＩＤの生成要求を行うことを特徴とする。【００１６】  また、本発明に係るＡＶサーバ機器の前記コネクション管理手段は、前記コネクションＩＤの生成要求を受けた場合には、前記コネクションＩＤを生成し、前記コンテンツデータ配信手段に応答し、前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、前記通信手段は、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信することを特徴とする。【００１７】  これらの構成により、クライアント機器から論理コネクションの確立前に物理コネクションに基づくコンテンツデータ配信要求を受信した場合においても、コンテンツデータ配信手段においてコネクションの種類を判定して、コネクションＩＤが付与されていない場合、即ち論理コネクションが確立していないコンテンツデータの配信要求に対しても、コネクション管理手段においてコネクションＩＤを生成して、コンテンツデータ配信手段は通信手段を介してコンテンツデータをクライアント機器に配信することが可能となる。【００１８】  また、本発明に係るＡＶサーバ機器の前記コネクション管理手段は、少なくとも前記ＡＶサーバ機器に接続された各クライアント機器のアドレス情報と、前記論理コネクション確立の優先度との関係が記述された優先度テーブルを管理し、前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持する前記コネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理手段は、前記優先度テーブルを参照して、優先度の高いクライアント機器からの削除要求である場合に前記コネクション管理手段が保持する前記コネクションＩＤを消去することを特徴とする。【００１９】  この構成により、ＡＶサーバ機器でクライアント機器の論理コネクション接続における優先とを優先度テーブルを用いて参照して、優先度の高いクライアント機器��らの接続要求を優先することができ、複数のクライアント機器が接続されるＡＶサーバ機器のコネクション本数に限りがある場合において有効なコネクション利用を図ることが可能となる。【００２０】  また、本発明に係るＡＶサーバ機器の前記コネクション管理手段は、少なくとも前記コネクションＩＤと、前記論理コネクションの生成先となるクライアント機器のアドレス情報、前記物理コネクションの接続先となるクライアント機器のアドレス情報、前記コンテンツのサービス情報、及び前記クライアント機器毎に付与されている前記論理コネクション確立の優先度の少なくとも１つが記載されたコネクション管理情報を管理し、前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、予め定められたコネクションＩＤが付与されている場合には、前記コネクション管理手段が保持する前記コネクションＩＤを消去しないことを特徴とする。【００２１】  この構成により、ＡＶサーバ機器においてはコネクション管理情報に記載されている情報に基づいてコネクションの接続及び切断を行うことができ、より適切なクライアント機器とのコネクション管理を行うことが可能となる。【００２２】  尚、前記目的を達成するために、本発明は、ＡＶサーバ機器の特徴的な構成手段をステップとするコネクション管理方法としたり、この方法が備える特徴的な命令を含むプログラムとして実現することもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の通信ネットワークを介して流通させることができるのは言うまでもない。
【発明の効果】
【００２３】  本発明に係るＡＶサーバ機器によれば、物理コネクションであるＴＣＰコネクションの本数などでリソース管理する方法においても、論理コネクションの管理と併用することで“後取り優先”にすることが可能であると同時に、論理コネクションの管理においても“先取り優先”させることができ、ＡＶサーバ機器とクライアント機器との間のコネクションを適切に管理することが可能となる。
【図面の簡単な説明】
【００２４】
【図１】図１は、本発明の実施の形態におけるサーバ機器の主要部の構成を示すブロック図である。
【図２】図２は、同、クライアント機器の主要部の構成を示すブロック図である。
【図３】図３は、同、サーバ機器、クライアント機器のネットワーク構成図である。
【図４】図４は、同、メタデータ取得のシーケンス図である。
【図５】図５は、同、コンテンツデータのメタデータである。
【図６】図６は、同、サーバ機器、クライアント機器間での論理コネクション確立手順のシーケンス図である。
【図７】図７は、同、論理コネクション確立有りの際のコンテンツデータ取得のシーケンス図である。
【図８】図８は、同、論理コネクション確立無しの際のコンテンツデータ取得のシーケンス図である。
【図９】図９は、同、コネクションＩＤ一覧取得のシーケンス図である。
【図１０】図１０は、同、コネクション削除のシーケンス図である。
【図１１】図１１は、同、コネクション削除不可の場合のシーケンス図である。
【図１２】図１２は、同、コネクション管理情報である。
【図１３】図１３は、従来の論理コネクション確立無しの際のコンテンツデータ取得のシーケンス図である。
【符号の説明】
【００２５】  ３  通信路
１０  サーバ機器
１１  通信部
１２  ＵＰｎＰ  ＡＶプロトコル処理部（サーバ機能）
１３  コンテンツデータ蓄積部
１４  コンテンツデータ配信部
１５  コネクション管理部
２０  クライアント機器
２１  通信部
２２  ＵＰｎＰ  ＡＶプロトコル処理部（クライアント機能）
２３  コンテンツデータ受信部
２４  コンテンツデータ再生部
５０  メタデータ
１２０  コネクション管理情報
１２１  優先度テーブル
【発明を実施するための最良の形態】
【００２６】  以下、本発明を実施するための最良の形態について図面を用いて説明する。
（実施の形態１）【００２７】  図１は、本実施の形態におけるサーバ機器１０の主要部の構成を示すブロック図である。【００２８】  サーバ機器１０は、通信路３を介してクライアント機器と通信する通信部１１を備える。ここで通信路３は、イーサネット（登録商標）などの有線通信路やＩＥＥＥ８０２．１１０／ｂ／ｇ、Ｂｌｕｅｔｏｏｔｈなどの無線通信路とする。【００２９】  またサーバ機器１０はユニバーサル・プラグ・アンド・プレイ  ＡＶ規格のプロトコル処理部１２を備え、ＵＰｎＰ  ＡＶ規格に準拠した機器検索や能力交換などの処理を実行することができる。また、ＵＰｎＰ  ＡＶ規格に準拠したクライアント機器が送信したＵＰｎＰ  ＡＶコマンドを受信し、受信したコマンドに従って動作する。【００３０】  コンテンツデータ蓄積部１３には録画されたテレビ番組や、ＤＶＣ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｃａｍｅｒａ）などで撮影された動画データ、ＤＳＣ（Ｄｉｇｉｔａｌ  Ｓｔｉｌｌ  Ｃａｍｅｒａ）などで撮影された静止画データ、録音されたラジオ番組や録音されたＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）楽曲などの音声データ（以下、動画、静止画、音声の各データをコンテンツデータと呼ぶ。）が蓄積されている。
クライアント機器では、これらのコンテンツデータのタイトル情報や、録音録画日情報、ＵＲＬ（Ｕｎｉｆｏｒｍｅｄ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等で表されるコンテンツデータの位置情報（以下、これらをまとめてメタデータと呼ぶ。）はＵＰｎＰ  ＡＶコマンド要求により、ＵＰｎＰ  ＡＶプロトコル処理部を介して取得する事ができる。また、コンテンツデータ蓄積部１４に蓄積されたコンテンツデータは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などのコンテンツデータ配信部１４を用いてクライアントに配信される。またコンテンツデータを配信する際のＨＴＴＰ接続のセッション情報はコネクション管理部１５によって管理される。クライアント機器では、コネクション管理部１５によって管理されるセッション情報の一覧をＵＰｎＰ  ＡＶコマンド要求により、ＵＰｎＰ  ＡＶプロトコル処理部を介して取得する事ができる。【００３１】  図２は、クライアント機器２０の主要部の構成を示すブロック図である。【００３２】  クライアント機器２０は、通信路３を介してサーバ機器と通信する通信部２１を備える。またＵＰｎＰ  ＡＶ規格のプロトコル処理部２２を備え、ＵＰｎＰ  ＡＶ規格に準拠したサーバ機器に対してＵＰｎＰ  ＡＶコマンドを送信し、サーバ機器を遠隔制御する事ができる。【００３３】  また、サーバ機器からコンテンツデータを受信するコンテンツデータ受信部２３を備え、ＨＴＴＰ等でコンテンツデータを取得する事ができる。取得したコンテンツデータはコンテンツデータ再生部２４により再生できる。ここで、コンテンツデータ再生部２４はコンテンツデータが動画データでありＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）エンコードされたものである場合には、ＭＰＥＧエンコーダである。【００３４】  図３は、本実施の形態におけるサーバ機器１０、クライアント機器２０、２００、及び２１０のネットワーク構成図である。【００３５】  通信路３を介してサーバ機器１０、クライアント機器２０、クライアント機器２００、およびクライアント機器２１０が接続されている。ここでクライアント機器２０、クライアント機器２００、およびクライアント機器２１０はＵＰｎＰの機器検索機能によりサーバ機器１０を認識している。
そして、サーバ機器１０、クライアント機器２０、クライアント機器２００はＵＰｎＰ  ＡＶオプションコマンドであるＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ、およびＣＭＳ：：Ｃｏｎｎｅｃｔｉｏｎ  Ｃｏｍｐｌｅｔｅをサポートしており、論理コネクション及び物理コネクションに対応している。
一方、クライアント機器２１０は上記２つのＵＰｎＰ  ＡＶコマンドをサポートしていない。すなわち、クライアント機器２１０は、物理コネクションに対応しているが論理コネクションは対応していない。オプションコマンドをサポートするか否かは機器に依存しており、ＵＰｎＰ  ＡＶ規格上サポートは義務付けられていない。【００３６】  図４は、クライアント機器２００がサーバ機器１０内のコンテンツデータ蓄積部１３に蓄積されたコンテンツデータのメタデータを取得するシーケンスを示す。尚、このメタデータ取得のシーケンスは従来技術と同様である。【００３７】  クライアント機器２００は所望のコンテンツデータを指定し、コンテンツデータのメタデータを取得するためのＵＰｎＰ  ＡＶコマンドであるＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを送信する（Ｓ４０）。ＣＤＳ：：Ｂｒｏｗｓｅ要求を受信したサーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドが処理され（Ｓ４１）、コマンドの内容に従い、クライアント機器２００によって指定されたコンテンツデータのメタデータを取得する（Ｓ４２、Ｓ４３）。コンテンツデータ蓄積処理部１３ではコンテンツデータの一部としてメタデータを蓄積し、ＵＰｎＰ  ＡＶプロトコル処理部１２に応答してもよいし、メタデータの要求を受信してから動的にコンテンツデータからメタデータを生成してもよい。【００３８】  ＵＰｎＰ  ＡＶプロトコル処理部１２は受信したメタデータからＣＤＳ：：Ｂｒｏｗｓｅ応答コマンドを生成し（Ｓ４４）、クライアント機器２００に応答する（Ｓ４５）。【００３９】  尚、クライアント機器２１０においても同様のシーケンスで、サーバ機器１０から所望のコンテンツデータのメタデータを取得する。【００４０】  図５は、図４で説明したサーバ機器１０からクライアント機器２００に送信されるＣＤＳ：：Ｂｒｏｗｓｅ応答コマンドに含まれるコンテンツデータのメタデータ５０を示す。このメタデータ５０はＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で記述されており、タイトル情報や、録画日情報、コンテンツデータの位置情報が記されている。【００４１】  そして、クライアント機器２００ではコンテンツデータ取得に先立って、サーバ機器１０との間にＵＰｎＰ  ＡＶコマンドであるＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを送信し、論理的な接続を確立する。【００４２】  図６は、サーバ機器１０とクライアント機器２００間で論理コネクションを確立するシーケンス図を示す。尚、図６のシーケンス図も従来と同様である。【００４３】  クライアント機器２００はＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドをサーバ機器１０へ送信する（Ｓ６０）。ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求を受信したサーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドが処理され（Ｓ６１）、コネクション管理部１５に対して論理コネクションの生成を要求する（Ｓ６２）。
そして、論理コネクション生成要求を受信したコネクション管理部１５では、論理コネクションの管理可能数内であれば新たに論理コネクションを生成し、一意に識別可能なＩＤ（以下、コネクションＩＤと呼ぶ。）を割り当てる。また、コネクションＩＤをＵＰｎＰ  ＡＶプロトコル処理部に対して通知する（Ｓ６４）。ここではコネクションＩＤとして“２”が付与されている。コネクションＩＤはＵＰｎＰ  ＡＶプロトコル処理部１２によりＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンド中に記述され（Ｓ６５）クライアント機器２００に送信される（Ｓ６６）。【００４４】  次に取得したコンテンツデータの位置情報をもとに物理コネクションを確立してコンテンツデータを取得するシーケンスを図７に示す。尚、本図に示すシーケンスも従来と同様となる。【００４５】  クライアント機器２００では、コンテンツデータのメタデータ中に含まれるＵＲＬからＨＴＴＰ−ＧＥＴを発行する（Ｓ７０）。この際、先ほど確立した論理コネクションのコネクションＩＤをＨＴＴＰヘッダに付与しておく。
そして、ＨＴＴＰ−ＧＥＴ要求を受信したサーバ機器１０内のコンテンツデータ配信部１４ではＨＴＴＰ−ＧＥＴ要求のヘッダ中にコネクションＩＤが付与されているので（Ｓ７１）、当該コネクションＩＤが存在するか否かをコネクション管理部１５に問い合わせる（Ｓ７２）。コネクション管理部１５は照会のあったコネクションＩＤが存在するコネクションＩＤであることを確認し、クラアイントのＩＰアドレスやＭＡＣアドレスなどのアドレス情報をコネクションＩＤと関連付け記憶し（Ｓ７３）、コンテンツデータ配信部１４に応答する（Ｓ７４）。コンテンツデータ配信部１４はコンテンツデータ蓄積部１３にコンテンツデータ取得要求を送信し（Ｓ７５）取得する（Ｓ７６）。コンテンツデータ配信部１４は取得したコンテンツデータをＨＴＴＰを用いて、クライアント機器２００に送信する（Ｓ７７）。【００４６】  図８は、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎコマンドをサポートしないクライアント機器２１０がコンテンツデータを取得するシーケンスを示す。尚、本図は、最初に物理コネクションを用いてコンテンツデータの取得要求を行うクライアント機器２１０に対してコンテンツデータの配信を行うサーバ機器１０の特徴を説明するものである。【００４７】  クライアント機器２１０は図４でのシーケンス同様、サーバ機器１０に対してＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを送信し、その応答コマンドによって所望のコンテンツデータのＵＲＬを取得している。
クライアント機器２１０はＵＲＬに対してコテンツデータの取得を要求する（Ｓ８０）。ここでＨＴＴＰ−ＧＥＴ要求を受信したコンテンツデータ配信部１４では、ＨＴＴＰヘッダにコンテンツＩＤが付与されていないため（Ｓ８１）、コネクション管理部１５に対して新たな論理コネクションの生成を要求する（Ｓ８２）。コネクション管理部１５では管理可能なコネクション容量に空きがあるので論理コネクションを生成し、コネクションＩＤを付与し（Ｓ８３）クライアント機器２１０のアドレス情報などと関連付け記憶すると共に、コネクションＩＤをコンテンツデータ配信部１４に対して通知する（Ｓ８４）。その後、コンテンツデータ配信部１４はコンテンツデータ蓄積部１３にコンテンツデータ取得要求を送信し（Ｓ８５）取得する（Ｓ８６）。コンテンツデータ配信部１４は取得したコンテンツデータをＨＴＴＰに準拠したフォーマットに変換し、クライアント機器２００に送信する（Ｓ８７）。【００４８】  このように、本発明に係るサーバ機器１０は、ＨＴＴＰヘッダにコンテンツＩＤが付与されていない、すなわち論理コネクションが確立されていないクライアント機器２１０からのＨＴＴＰ−ＧＥＴ要求を受信した場合にも、コネクション管理部１５において新たな論理コネクションの生成を要求して、コネクションＩＤを付与することが可能となる。【００４９】  さらに、クライアント機器２００およびクライアント機器２１０がサーバ機器１０からコンテンツデータを受信中にクライアント機器２０がサーバ機器１０からコンテンツデータを取得する場合について説明を行う。【００５０】  クライアント機器２０はＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎコマンドをサポートしているので、図６のシーケンス同様コンテンツデータ受信に先立ち、論理コネクションの生成を試みる。ここでサーバ機器１０は、例えば、同時に管理可能な論理コネクション数が２である場合には、既にクライアント機器２００およびクライアント機器２１０によって論理コネクションが生成されているので、クライアント機器２０のＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドに対し、サーバ機器１０は処理失敗応答が返信されることとなる。そこで、クライアント機器２０はサーバ機器１０が生成したコネクションＩＤを取得するためにＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドを発行する。図９にシーケンスを示す。【００５１】  最初に、クライアント機器２０はＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドをサーバ機器１０へ送信する（Ｓ９０）。ＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求を受信したサーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドが処理され（Ｓ９１）、コネクション管理部１５に対して現在管理されているコネクションＩＤのリストの生成を要求する（Ｓ９２）。コネクションＩＤのリスト生成要求を受信したコネクション管理部１５では、管理しているコネクションＩＤのリスト生成し（Ｓ９３）、ＵＰｎＰ  ＡＶプロトコル処理部に対して通知する（Ｓ９４）。コネクションＩＤのリストはＵＰｎＰ  ＡＶプロトコル処理部１２によりＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ応答コマンドに変換され（Ｓ９５）クライアント機器２０に送信される（Ｓ９６）。【００５２】  次に、クライアント機器２０はコネクションＩＤ”３”で管理される論理コネクションを削除する。図１０に論理コネクション削除のシーケンスを示す。【００５３】  クライアント機器２０はＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドをサーバ機器１０へ送信する（Ｓ１００）。サーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドが処理され（Ｓ１０１）、コネクション管理部１５に対してコネクションＩＤで示される論理コネクションの削除を要求する（Ｓ１０２）。論理コネクション削除要求を受信したコネクション管理部１５では、例えば、後述するクライアント機器毎に付与されている優先度を、後述する図１２（ｂ）に示す優先度テーブルを用いて参照して、優先度が高いクライアント機器（本図においてはクライアント機器２０）からの削除要求である場合には、コネクションＩＤで示される論理コネクションを削除し（Ｓ１０３）、処理結果をＵＰｎＰ  ＡＶプロトコル処理部に対して通知する（Ｓ１０４）。処理結果はＵＰｎＰ  ＡＶプロトコル処理部１２によりＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ応答コマンドに変換され（Ｓ１０５）クライアント機器２０に送信される（Ｓ１０６）。【００５４】  ここでクライアント機器２０はＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを前述した手順で発行し、サーバ機器１０と論理コネクションを確立後、ＨＴＴＰ−ＧＥＴ要求によりサーバ機器１０内のコンテンツデータ蓄積部１３に記録された所望のコンテンツデータの取得を行い、コンテンツデータ再生部２４により再生を行う。【００５５】  尚、図１１には、クライアント機器２０はコネクションＩＤ”３”で管理される論理コネクションを削除できない場合のシーケンス図を示す。【００５６】  本図においては、Ｓ１１０〜Ｓ１１２までの処理は図１０のＳ１００〜Ｓ１０２までの処理と同様となるが、優先度が低いクライアント機器（本図においてはクライアント機器２０）からの削除要求であるために、論理コネクションのＩＤ削除不可と判断して（Ｓ１１３）、処理結果をＵＰｎＰ  ＡＶプロトコル処理部に対して通知し（Ｓ１１４）、ＵＰｎＰ  ＡＶプロトコル処理部１２により、コマンドの応答の中のパラメータに処理結果を示すフィールドがあり、そこにエラー情報が入ったＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅがエラー応答で返信され（Ｓ１１５）クライアント機器２０に送信される（Ｓ１１６）。尚、上記のエラー応答は、例えばエラーコードを拡張して、「これ以上はコネクションを張れない」旨のエラーメッセージを送信するものである。【００５７】  以上の説明のように、本実施の形態１に係るサーバ機器においては、図８のＳ８１〜Ｓ８４に示すように、ＨＴＴＰヘッダにコンテンツＩＤが付与されているか否かを判定して、コネクションＩＤが付与されていない場合、即ちクライアント機器から論理コネクションの確立前に物理コネクションに基づくＨＴＴＰ−ＧＥＴ取得要求を受信した場合においても、コネクション管理部１５に対して新たな論理コネクションの生成を要求して、管理可能なコネクション容量に空きがある場合には、論理コネクションに用いるコネクションＩＤを付与することが可能となり、クライアント機器とサーバ機器間のコネクションを適切に管理することが可能となる。【００５８】  以下、本実施の形態で示した構成の変形例について説明する。【００５９】  上記実施の形態１では、クライアント機器から明示的にＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｅｌｅｔｅ要求コマンドを発行する事で論理コネクションを削除する構成について説明したが、論理コネクションで接続されるサーバ機器、クラアイント機器におけるサーバ機器ではＨＴＴＰ接続やＴＣＰ接続の切断をコンテンツデータ配信部が検知した場合には、コネクション管理部に対して当該論理コネクションの切断を要求する構成としてもよい。【００６０】  また、サーバ機器において３０分間などの基準値を設け、基準時間を超えてＨＴＴＰ−ＧＥＴ要求を受信しなかった場合は、コネクション管理部に対して当該論理コネクションの切断を要求する構成としてもよい。【００６１】  さらに、ＨＴＴＰ−ＧＥＴ要求をする際にＨＴＴＰヘッダ情報にＲａｎｇｅ指定を行い、コンテンツデータの取得に複数回のＨＴＴＰ−ＧＥＴ要求を行ってもよい。
（実施の形態２）【００６２】  次に、本発明に係るサーバ機器の第二の実施の形態について図面を参照しながら説明を行う。尚、上記実施の形態１では、図１０及び図１１を用いて後からネットワークに参入したクライアント機器が優先度等に基づいて既に確立されたコネクションを削除して新たなコネクションを生成する方法について説明したが、本実施の形態では、後からネットワークに参入したクライアント機器による既存のコネクション削除を禁止する方法についての説明を行う。【００６３】  また、本実施の形態におけるサーバ機器及びクライアント機器の構成図は、実施の形態１における構成図と同様であるので、説明を省略する。【００６４】  この場合、図６において、クライアント機器２００からのＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドに対して、サーバ機器１０が当該論理コネクションを前述したＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドによって削除されない論理コネクションを生成したい場合は、コネクションＩＤを“０”としてＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンドをクライアント機器２００に送信する。【００６５】  ここで、コネクションＩＤ“０”はコネクション管理部１５において、論理コネクションの数のみを管理し、クライアント機器のアドレス情報などのクライアント機器情報を管理しない事を表す。【００６６】  図３で示されるネットワーク構成において、サーバ機器１０はクライアント機器２００からのＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドに対して、コネクションＩＤが“０”であるＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンドを返答する。その後、クライアント機器２００はコネクションＩＤ“０”をＨＴＴＰヘッダ情報に含むＨＴＴＰ−ＧＥＴ要求をサーバ機器１０に対して行い、コンテンツデータの取得を行う。【００６７】  また、サーバ機器１０は、クライアント機器２１０からのＨＴＴＰ−ＧＥＴ要求に対して、コネクションＩＤが“０”である論理コネクションとしてコネクション管理部１５によって当該論理コネクションを管理する。【００６８】  次に、クライアント機器２０はサーバ機器１０に対してＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを発行するが、サーバ機器２０では現在管理している論理コネクション数が管理可能な最大論理コネクション数（本実施の形態の説明においては２本）に達しているため、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンドにエラー応答を行う。次に、クライアント機器２０はＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドを発行する。サーバ機器１０はＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ応答コマンドとして“ＩＤ＝０”を応答する。【００６９】  クライアント機器２０はコネクションＩＤが“０”であるＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドを送信するが、サーバ機器１０内のコネクション管理部１５において、当該コネクションＩＤで示される論理コネクションの情報は存在しないため、当該コネクションＩＤで示される論理コネクションは��除されず、クライアント機器２０に対してはＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ応答コマンドが返送されるが、クライアント機器２００およびクライアント機器２１０においてはコネクションは確立されたままとなる。【００７０】  クライアント機器２００、およびクライアント機器２１０ではコンテンツデータの取得が完了した時点でＨＴＴＰコネクションが切断される。ＨＴＴＰコネクションが切断されるとコンテンツデータ配信部１４はコネクション管理部１５に対して、論理コネクションの削除を要求する。要求を受けたコネクション管理部１５では管理する論理コネクションを削除する。【００７１】  なお、ここではＨＴＴＰコネクションの切断でコネクションＩＤ“０”で表される論理コネクションが削除される条件となる例を示したが、ＴＣＰコネクションの切断が論理コネクションが切断される条件としてもよい。【００７２】  また、図１２（ａ）に示すように、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを送信したクラアイント機器のアドレス情報（ＰＦＣ生成先）や、ＨＴＴＰ接続が確立されているクラアイント機器のアドレス情報（ＨＴＴＰ配信先）、またテレビやＶＯＤ（Ｖｉｄｅｏ  Ｏｎ  Ｄｅｍａｎｄ）など配信中のコンテンツデータの種別（サービス）、優先度などをコネクション管理情報１２０として記憶し、例えば、サービスがＶＯＤである論理コネクションはＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドによって削除されることのないような構成としてもよい。ここでは、サービスという１つの情報に基づいて論理コネクション削除が拒否される条件について説明したが、ＨＴＴＰ配信先とサービスなど２つ以上の情報を組み合わせで条件を設定してもよい。【００７３】  また、図１２（ａ）のコネクション管理情報１２０に示すように、提供されるコンテンツのサービスの種類がＶＯＤである場合には、コネクションＩＤが“０”となり、論理コネクションの切断を行うことができない設定となっている。また、２つ目のコネクションで、ＰＦＣ生成先が記述されていないコネクションは、クライアント機器が最初に物理コネクションを用いてコンテンツ取得要求を行った場合におけるコネクションであり、コネクション管理情報１２０の３つ目のコネクションは、ＰＦＣ生成先とＨＴＴＰ配信先とが異なるアドレスとなっているが、これは論理コネクションの接続を他のクライアント機器から行った場合の例である。【００７４】  そして、コネクション管理情報１２０に記載されている優先度は、他のクライアント機器からの論理コネクション切断の判断を行う場合に用いられ、例えば、優先度が１である父親のクライアント機器からは優先度が３である兄のコネクションを切断することができる一方、兄のクライアント機器から父親の論理コネクションを勝手に切断できない設定となっている。【００７５】  また、図１２（ｂ）は、本発明のサーバ機器に管理される優先度テーブル１２１の一例を示し、サーバ機器に接続されているクライアント機器のＩＰアドレスと、論理コネクション確立における優先度との関係が記述されている。サーバ機器は、この優先度テーブル１２１を参照することにより、例えば、図１���及び図１１に示すように、優先度の高いクライアント機器から、既に確立されている優先度の低いクライアント機器のコネクションＩＤの削除を行うことが可能となる。尚、図１２ではアドレス情報としてＩＰアドレスを用いる例を示したが、ＭＡＣアドレス等の物理アドレスを用いてもよい。【００７６】  以上説明したように、本実施の形態２に係るサーバ機器は、コネクション管理情報１２０や優先度テーブル１２１を用いて、コネクション本数に限りのあるクライアント機器との間のコネクションを適切に管理することが可能となる。【００７７】  また、本実施の形態２に係るサーバ機器では、ホームネットワークの規格において、下位互換を保ちながらも新たにコネクション管理を行うことが可能となり、これに合わせて、コネクション管理情報１２０等を用いることにより、例えばテレビ放送のような映像配信については“後取り優先”のコネクション管理を行い、ビデオオンデマンドのように個人が任意で楽しむような映像配信については“先取り優先”のコネクション管理を行うなど、サービスによって効率的なリソース管理が行える効果を発揮する。【００７８】  尚、本実施の形態２ではコネクションＩＤ“０”を論理コネクションに関する詳細情報を持たない予約値として、コネクション管理部において扱う構成について説明したが、予約値は“０”以外のいかなる数値であってもよい事は説明するまでもない。【００７９】  また、コネクションＩＤ“０”が指定された場合は論理コネクションを生成せず、実際のＨＴＴＰコネクションのみを用いてコンテンツデータのやりとりを行う構成としてもよい。【００８０】  さらに、配信するコンテンツの種別を判定して、例えば、録画中コンテンツの配信時にはコネクション削除を禁止し、録画済コンテンツの配信時にはコネクション削除を可能とすることも考えられる。【００８１】  そして、上述の説明においてはコネクションＩＤ消去のタイミングについては言及していないが、例えば、コンテンツの配信要求が一定期間なかった場合や、配信要求先のＩＰアドレスからコンテンツ配信要求先を特定して一定期間後に消去することが考え得る。【００８２】  また、セキュリティの関係で登録したＭＡＣアドレス以外のクライアント機器からのコネクション接続要求を受け付けない構成とすることも考え得る。
【産業上の利用可能性】
【００８３】  本発明に係るＡＶサーバ機器は、例えば、ＵＰｎＰ−ＡＶのＣＤＳに準じるファイル転送方法に基づいて宅内ネットワークを介して家電機器間でのマルチメディアコンテンツの転送を行うＡＶサーバ機器として適用できる。
【図１】
2006077935.tif 000002
【図２】
2006077935.tif 000003
【図３】
2006077935.tif 000004
【図４】
2006077935.tif 000005
【図５】
2006077935.tif 000006
【図６】
2006077935.tif 000007
【図７】
2006077935.tif 000008
【図８】
2006077935.tif 000009
【図９】
2006077935.tif 000010
【図１０】
2006077935.tif 000011
【図１１】
2006077935.tif 000012
【図１２】
2006077935.tif 000013
【図１３】
2006077935.tif 000014
【手続補正書】
【提出日】平成19年1月17日(2007.1.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器であって、
通信パケットを送受信する通信手段と、
前記通信手段を用いて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信手段と、
前記コンテンツデータを蓄積するコンテンツデータ蓄積手段と、
前記通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、
前記コンテンツデータ配信手段の前記物理コネクション、及び前記プロトコル処理手段の前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理手段とを備え、
前記通信手段が前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクションＩＤの確認処理を行い、
前記コンテンツデータ配信手段は、前記コネクションＩＤの確認ができない場合には、前記コネクション管理手段に対して前記コネクションＩＤの生成要求を行う
ことを特徴とするＡＶサーバ機器。
【請求項２】
前記コネクション管理手段は、前記コネクションＩＤの生成要求を受けた場合には、コネクションＩＤを生成し、前記コンテンツデータ配信手段に応答し、
前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信手段は、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項３】
前記コンテンツデータ配信手段は、前記コネクションＩＤの確認ができる場合には、前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信手段は、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項４】
前記コンテンツデータ配信手段は、前記通信手段を介して取得した前記クライアント機器のアドレス情報を前記コネクション管理手段に提供し、
前記コネクション管理手段は、前記アドレス情報を用いて前記クライアント機器とのコネクションを識別する前記コネクションＩＤの有無を確認する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項５】
前記アドレス情報は、前記クライアント機器のＩＰアドレス又はＭＡＣアドレスである
ことを特徴とする請求項４記載のＡＶサーバ機器。
【請求項６】
前記コネクション管理手段は、少なくとも前記ＡＶサーバ機器に接続された各クライアント機器のアドレス情報と、前記論理コネクション確立の優先度との関係が記述された優先度テーブルを管理し、
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持する前記コネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理手段は、前記優先度テーブルを参照して、優先度の高いクライアント機器からの削除要求である場合に前記コネクション管理手段が保持する前記コネクションＩＤを消去する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項７】
前記コネクション管理手段は、少なくとも前記コネクションＩＤと、前記論理コネクションの生成先となるクライアント機器のアドレス情報、前記物理コネクションの接続先となるクライアント機器のアドレス情報、前記コンテンツのサービス情報、及び前記クライアント機器毎に付与されている前記論理コネクション確立の優先度の少なくとも１つが記載されたコネクション管理情報を管理し、
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、予め定められたコネクションＩＤが付与されている場合には、前記コネクション管理手段が保持する前記コネクションＩＤを消去しない
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項８】
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、前記コネクションＩＤを生成したクライアント機器かをアドレス情報を用いて判別し、前記コネクションＩＤを生成したクライアント機器以外からの要求である場合には、前記コネクション管理手段が保持する前記コネクションＩＤを消去しない
ことを特徴とする請求項７記載のＡＶサーバ機器。
【請求項９】
前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、前記コネクションＩＤと関連付けられた前記サービスの種類に応じて前記コネクション管理手段が保持する前記コネクションＩＤを消去しない
ことを特徴とする請求項７記載のＡＶサーバ機器。
【請求項１０】
前記プロトコル処理手段は、前記通信手段を介して前記クライアント機器から前記コネクション管理手段において保持するコネクションＩＤ情報を閲覧するためのコマンドを受信した際に、前記コマンドの応答として、前記コネクション管理情報を付与して返信する
ことを特徴とする請求項７記載のＡＶサーバ機器。
【請求項１１】
前記コネクション管理手段は、コンテンツデータに対する配信要求が継続して行われていない場合、又はコンテンツデータに対する配信要求が一定期間なくなった場合において前記コネクションＩＤを消去する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１２】
前記コネクション管理手段は、配信要求がなくなった配信先の前記クライアント機器のアドレス情報に基づいて前記コネクションＩＤを消去する
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１３】
前記コンテンツデータ配信手段は、コンテンツに対する配信要求が継続中に、コンテンツに対する配信要求受信時において、前記コネクション管理手段に前記コネクションＩＤの存在有無を確認し、前記コネクションＩＤが消去されていた場合においては、前記通信手段を介してコンテンツに対する配信要求でエラーを返した上で、前記クライアント機器とのコネクションの切断を行う
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１４】
前記コンテンツデータ配信手段は、コンテンツに対する配信要求が継続中に、コンテンツ配信時において、前記コネクション管理手段に前記コネクションＩＤの存在有無を確認し、前記コネクションＩＤが消去されていた場合においては、前記通信手段を介してコンテンツを配信せずに、前記クライアント機器とのコネクションの切断を行う
ことを特徴とする請求項１記載のＡＶサーバ機器。
【請求項１５】
前記コンテンツデータ配信手段は、前記コネクションＩＤが消去されているかどうかを、配信要求先となるクライアント機器のアドレス情報から判別する
ことを特徴とする請求項１３又は１４記載のＡＶサーバ機器。
【請求項１６】
ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器に用いるコネクション管理方法であって、
通信パケットを送受信する通信ステップと、
前記通信ステップにおいて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信ステップと、
前記コンテンツデータを蓄積するコンテンツデータ蓄積ステップと、
前記通信ステップにおいて論理コネクションの管理を行うコマンドを処理するプロトコル処理ステップと、
前記コンテンツデータ配信ステップにおける前記物理コネクション、及び前記プロトコル処理ステップにおける前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理ステップとを含み、
前記通信ステップにおいて前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信ステップにおいては、前記コネクション管理ステップにおける前記コネクションＩＤの確認処理を行い、
前記コンテンツデータ配信ステップにおいては、前記コネクションＩＤの確認ができない場合には、前記コネクション管理ステップにおける前記コネクションＩＤの生成要求を行う
ことを特徴とするコネクション管理方法。
【請求項１７】
前記コネクション管理ステップにおいては、前記コネクションＩＤの生成要求を受けた場合には、コネクションＩＤを生成し、
前記コンテンツデータ配信ステップにおいては、前記コンテンツデータ蓄積ステップにおけるコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信ステップにおいては、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１６記載のコネクション管理方法。
【請求項１８】
ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器に用いるプログラムであって、
通信パケットを送受信する通信ステップと、
前記通信ステップにおいて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信ステップと、
前記コンテンツデータを蓄積するコンテンツデータ蓄積ステップと、
前記通信ステップにおいて論理コネクションの管理を行うコマンドを処理するプロトコル処理ステップと、
前記コンテンツデータ配信ステップにおける前記物理コネクション、及び前記プロトコル処理ステップにおける前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理ステップとをコンピュータに実行させ、
前記通信ステップにおいて前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信ステップにおいては、前記コネクション管理ステップにおける前記コネクションＩＤの確認処理を行い、
前記コンテンツデータ配信ステップにおいては、前記コネクションＩＤの確認ができない場合には、前記コネクション管理ステップにおける前記コネクションＩＤの生成要求を行う
ことを特徴とするプログラム。
【請求項１９】
前記コネクション管理ステップにおいては、前記コネクションＩＤの生成要求を受けた場合には、コネクションＩＤを生成し、
前記コンテンツデータ配信ステップにおいては、前記コンテンツデータ蓄積ステップにおけるコンテンツデータの取得を要求して前記コンテンツデータを取得し、
前記通信ステップにおいては、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信する
ことを特徴とする請求項１８記載のプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、宅内ネットワーク等を介してクライアント機器に音楽や動画などのＡＶコンテンツ等を提供するＡＶサーバ機器に関し、特に、宅内にある複数のクライアント機器にＡＶコンテンツを送信するＡＶサーバ機器に関する。
【背景技術】
【０００２】
近年、ｘＤＳＬや光ファイバーなどのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内のＰＣや家電機器をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮなどで接続するホームネットワーク環境も一般化してきている。この様な中で、パーソナルコンピュータ（ＰＣ）だけでなく、テレビやＤＶＤレコーダ、エアコン、冷蔵庫のような家電もＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）により定義されるＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）により相互に接続できるようになってきている。
【０００３】
インターネットやホームネットワークにおけるアプリケーションの１つとして、家電機器やＰＣ間で音楽や動画などのＡＶコンテンツを視聴するアプリケーションがある。例えば、ＤＶＤレコーダに録画した放送番組を、ネットワークに接続されたＴＶやＰＣなどで視聴するＡＶストリーミング機能を提供する例などである。
【０００４】
この様なＡＶストリーミングを行うプロトコルでは、代表的なものとしては、ＲＦＣ２６１６で定義されるＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）や、ＲＦＣ１８８９で定義されるＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）等が存在した。特に、ＨＴＴＰはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）の再送機能によって転送の信頼性を確保している。すなわち、ＴＣＰはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやパケット欠落が起こっても正しいファイルの転送が保障できる。
【０００５】
そして、伝送エラーが発生しやすいネットワーク環境では、データの再送信のためにスループットが低下するといった特徴があり、このため、ＴＣＰは、ホームネットワークのような伝送路上のエラーやパケット欠落が発生し易い環境下におけるＡＶストリーミングに向いており、ＵＰｎＰ  ＡＶ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ  Ａｕｄｉｏ／Ｖｉｄｅｏ  Ａｒｃｈｉｔｅｃｔｕｒｅ）や、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ）などの基本的なＡＶストリーミング方式となっている。
【０００６】
しかしながら、ＨＴＴＰでのＡＶストリーミングは信頼性が高い反面、リアルタイム性を保持するためにはＡＶサーバ機器側のリソースに依存する。例えば高ビットレートの転送速度が要求される蓄積データや、複数同時アクセスされた場合などには、スループットを見据えてＡＶサーバ機器側でリソース配分の管理を行う必要がある。リソース配分の管理方法としては、（１）ＨＴＴＰメッセージの送受信を行うためのＴＣＰコネクションの本数を制限するなどが考えられる。この場合、制限を超えて後からネットワーク再生をリクエストしようとしたクライアント機器に対しては、一般にエラーメッセージが送信されるか、またはリクエストそのものが無視され、先にコネクションを確立したクライアント機器は、ＡＶコンテンツの視聴を継続して楽しめる。これは先にコネクション確立を行った機器を優先する“先取り優先”の考え方である。この“先取り優先”の考え方は、物理コネクションに代表されるものである。
【０００７】
一方、（２）ＵＰｎＰ  ＡＶにはコネクション管理のためのＣＭＳ（Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｒ  Ｓｅｒｖｉｃｅ）というものがあり、論理的なコネクションの確立・切断を行うためのコマンド（ＳＯＡＰ  Ａｃｔｉｏｎ）が存在する。具体的には、コネクションを確立するためのコマンドがＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎであり、このコマンドを受信したＡＶサーバ機器は、サーバ内部においてリソースの空きがあればＩＤを発行する。また、コネクションを切断したい場合においてはＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅをＡＶサーバ機器に送信することで、ＡＶサーバ機器はリソースの解放を行う。ＣＭＳは論理的なコネクション確立をするものであるため、ＨＴＴＰにおけるＡＶストリーミングと連動するために、ＨＴＴＰヘッダ等にＩＤを付与するなどの関連付けすることが一般的である。
【０００８】
そして、ＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅは、必ずしもＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎにてＩＤを取得した機器のみが出来るわけではないため、ＡＶサーバ機器においてリソース配分されているＩＤを閲覧するためのコマンドであるＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓを発行した上で、ＩＤを知る事が出来、更にＩＤを解放するためにＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅをＡＶサーバ機器に送信することで、先にコネクションを確立したクライアント機器を、後から別のクライアント機器が切断することも可能である。これは後からコネクション確立を要求した方が優先される“後取り優先”の考え方である。この“後取り優先”の考え方は、論理コネクションに代表されるものである。
【０００９】
このように、（２）においては、ＴＣＰコネクションの本数とは別に、ＣＭＳによる論理的なコネクションの本数によってリソース管理をする方法となる。
【００１０】
上記のことは、例えば特許文献１、並びに特許文献２に開示されている。
【特許文献１】特開２００２−８４４８４号公報
【特許文献２】特開２００４−３４８４５４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
前述した通り、物理コネクションであるＴＣＰコネクションの本数などでリソース管理する方法は、“先取り優先”の考え方であるのに対し、論理コネクションを用いるＵＰｎＰ  ＡＶのＣＭＳなどでリソース管理する方法は、“後取り優先”の考え方である。
【００１２】
例えば、（１）ＴＣＰコネクションの本数によりリソース管理する方法と、ＣＭＳなどの論理的なコネクションの本数によりリソース管理する方法を併用して用いるＡＶサーバ機器においては、ＨＴＴＰリクエストのみでＡＶコンテンツ要求された場合には先取り優先の機能が働くため、後からＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎなどで要求された場合において、リソースが割り振れず、かつＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅなどでリソースを解放することも出来ないという課題を有している。
また、（２）ＣＭＳなどの論理的なコネクションの本数だけでリソース管理する方法を用いたＡＶサーバ機器においては、常に後取り優先の機能が働くため、ビデオオンデマンドなどの個人で楽しむサービスを提供した時に、いつ何時、誰からでも視聴を中断されるという課題を有している。
【００１３】
さらに、（３）今後、宅内の１つのＡＶサーバ機器に家族の各々のクライアント機器が宅内ネットワークを介して接続してコンテンツ視聴するような環境が考えられ、そのような場合には、ＡＶサーバ機器において有効なコネクション本数のリソース管理を適切に行うために、主にＵＰｎＰに基づくＡＶコンテンツ配信においては、コンテンツの実体を配信するための物理コネクションの確立前に、論理コネクションの確立が要求されるようになる。しかしながら、現状のクライアント機器においては、最初に物理コネクションを用いてコンテンツ取得要求を行う機器が一般的であり、このような場合には、図１３のＳ１３４に示すように、ＡＶサーバ機器１４０においては論理コネクションのＩＤ確認ができず、コネクションなしとしてエラー返信（Ｓ１３６）を行うために、クライアント機器１３０は要求するコンテンツが取得できないという課題もある。
【００１４】
本発明は、上記従来の課題を解決するもので、ＡＶコンテンツを要求するクライアント機器とのコネクションにおいて、物理コネクション及び論理コネクションを併用して、コネクションの“先取り優先”及び“後取り優先”を実現したＡＶサーバ機器を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明に係るＡＶサーバ機器は、ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信するＡＶサーバ機器であって、通信パケットを送受信する通信手段と、前記通信手段を用いて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信手段と、前記コンテンツデータを蓄積するコンテンツデータ蓄積手段と、前記通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、前記コンテンツデータ配信手段の前記物理コネクション、及び前記プロトコル処理手段の前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクションＩＤに基づいて行うコネクション管理手段とを備え、前記通信手段が前記クライアント機器から前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクションＩＤの確認処理を行い、前記コンテンツデータ配信手段は、前記コネクションＩＤの確認ができない場合には、前記コネクション管理手段に対して前記コネクションＩＤの生成要求を行うことを特徴とする。
【００１６】
また、本発明に係るＡＶサーバ機器の前記コネクション管理手段は、前記コネクションＩＤの生成要求を受けた場合には、前記コネクションＩＤを生成し、前記コンテンツデータ配信手段に応答し、前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、前記通信手段は、前記物理コネクションに基づいて前記コンテンツデータを前記クライアント機器に送信することを特徴とする。
【００１７】
これらの構成により、クライアント機器から論理コネクションの確立前に物理コネクションに基づくコンテンツデータ配信要求を受信した場合においても、コンテンツデータ配信手段においてコネクションの種類を判定して、コネクションＩＤが付与されていない場合、即ち論理コネクションが確立していないコンテンツデータの配信要求に対しても、コネクション管理手段においてコネクションＩＤを生成して、コンテンツデータ配信手段は通信手段を介してコンテンツデータをクライアント機器に配信することが可能となる。
【００１８】
また、本発明に係るＡＶサーバ機器の前記コネクション管理手段は、少なくとも前記ＡＶサーバ機器に接続された各クライアント機器のアドレス情報と、前記論理コネクション確立の優先度との関係が記述された優先度テーブルを管理し、前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持する前記コネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理手段は、前記優先度テーブルを参照して、優先度の高いクライアント機器からの削除要求である場合に前記コネクション管理手段が保持する前記コネクションＩＤを消去することを特徴とする。
【００１９】
この構成により、ＡＶサーバ機器でクライアント機器の論理コネクション接続における優先とを優先度テーブルを用いて参照して、優先度の高いクライアント機器からの接続要求を優先することができ、複数のクライアント機器が接続されるＡＶサーバ機器のコネクション本数に限りがある場合において有効なコネクション利用を図ることが可能となる。
【００２０】
また、本発明に係るＡＶサーバ機器の前記コネクション管理手段は、少なくとも前記コネクションＩＤと、前記論理コネクションの生成先となるクライアント機器のアドレス情報、前記物理コネクションの接続先となるクライアント機器のアドレス情報、前記コンテンツのサービス情報、及び前記クライアント機器毎に付与されている前記論理コネクション確立の優先度の少なくとも１つが記載されたコネクション管理情報を管理し、前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクションＩＤ情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、予め定められたコネクションＩＤが付与されている場合には、前記コネクション管理手段が保持する前記コネクションＩＤを消去しないことを特徴とする。
【００２１】
この構成により、ＡＶサーバ機器においてはコネクション管理情報に記載されている情報に基づいてコネクションの接続及び切断を行うことができ、より適切なクライアント機器とのコネクション管理を行うことが可能となる。
【００２２】
尚、前記目的を達成するために、本発明は、ＡＶサーバ機器の特徴的な構成手段をステップとするコネクション管理方法としたり、この方法が備える特徴的な命令を含むプログラムとして実現することもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の通信ネットワークを介して流通させることができるのは言うまでもない。
【発明の効果】
【００２３】
本発明に係るＡＶサーバ機器によれば、物理コネクションであるＴＣＰコネクションの本数などでリソース管理する方法においても、論理コネクションの管理と併用することで“後取り優先”にすることが可能であると同時に、論理コネクションの管理においても“先取り優先”させることができ、ＡＶサーバ機器とクライアント機器との間のコネクションを適切に管理することが可能となる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
（実施の形態１）
【００２５】
図１は、本実施の形態におけるサーバ機器１０の主要部の構成を示すブロック図である。
【００２６】
サーバ機器１０は、通信路３を介してクライアント機器と通信する通信部１１を備える。ここで通信路３は、イーサネット（登録商標）などの有線通信路やＩＥＥＥ８０２．１１０／ｂ／ｇ、Ｂｌｕｅｔｏｏｔｈなどの無線通信路とする。
【００２７】
またサーバ機器１０はユニバーサル・プラグ・アンド・プレイ  ＡＶ規格のプロトコル処理部１２を備え、ＵＰｎＰ  ＡＶ規格に準拠した機器検索や能力交換などの処理を実行することができる。また、ＵＰｎＰ  ＡＶ規格に準拠したクライアント機器が送信したＵＰｎＰ  ＡＶコマンドを受信し、受信したコマンドに従って動作する。
【００２８】
コンテンツデータ蓄積部１３には録画されたテレビ番組や、ＤＶＣ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｃａｍｅｒａ）などで撮影された動画データ、ＤＳＣ（Ｄｉｇｉｔａｌ  Ｓｔｉｌｌ  Ｃａｍｅｒａ）などで撮影された静止画データ、録音されたラジオ番組や録音されたＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）楽曲などの音声データ（以下、動画、静止画、音声の各データをコンテンツデータと呼ぶ。）が蓄積されている。
クライアント機器では、これらのコンテンツデータのタイトル情報や、録音録画日情報、ＵＲＬ（Ｕｎｉｆｏｒｍｅｄ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等で表されるコンテンツデータの位置情報（以下、これらをまとめてメタデータと呼ぶ。）はＵＰｎＰ  ＡＶコマンド要求により、ＵＰｎＰ  ＡＶプロトコル処理部を介して取得する事ができる。また、コンテンツデータ蓄積部１４に蓄積されたコンテンツデータは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などのコンテンツデータ配信部１４を用いてクライアントに配信される。またコンテンツデータを配信する際のＨＴＴＰ接続のセッション情報はコネクション管理部１５によって管理される。クライアント機器では、コネクション管理部１５によって管理されるセッション情報の一覧をＵＰｎＰ  ＡＶコマンド要求により、ＵＰｎＰ  ＡＶプロトコル処理部を介して取得する事ができる。
【００２９】
図２は、クライアント機器２０の主要部の構成を示すブロック図である。
【００３０】
クライアント機器２０は、通信路３を介してサーバ機器と通信する通信部２１を備える。またＵＰｎＰ  ＡＶ規格のプロトコル処理部２２を備え、ＵＰｎＰ  ＡＶ規格に準拠したサーバ機器に対してＵＰｎＰ  ＡＶコマンドを送信し、サーバ機器を遠隔制御する事ができる。
【００３１】
また、サーバ機器からコンテンツデータを受信するコンテンツデータ受信部２３を備え、ＨＴＴＰ等でコンテンツデータを取得する事ができる。取得したコンテンツデータはコンテンツデータ再生部２４により再生できる。ここで、コンテンツデータ再生部２４はコンテンツデータが動画データでありＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）エンコードされたものである場合には、ＭＰＥＧエンコーダである。
【００３２】
図３は、本実施の形態におけるサーバ機器１０、クライアント機器２０、２００、及び２１０のネットワーク構成図である。
【００３３】
通信路３を介してサーバ機器１０、クライアント機器２０、クライアント機器２００、およびクライアント機器２１０が接続されている。ここでクライアント機器２０、クライアント機器２００、およびクライアント機器２１０はＵＰｎＰの機器検索機能によりサーバ機器１０を認識している。
そして、サーバ機器１０、クライアント機器２０、クライアント機器２００はＵＰｎＰ  ＡＶオプションコマンドであるＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ、およびＣＭＳ：：Ｃｏｎｎｅｃｔｉｏｎ  Ｃｏｍｐｌｅｔｅをサポートしており、論理コネクション及び物理コネクションに対応している。
一方、クライアント機器２１０は上記２つのＵＰｎＰ  ＡＶコマンドをサポートしていない。すなわち、クライアント機器２１０は、物理コネクションに対応しているが論理コネクションは対応していない。オプションコマンドをサポートするか否かは機器に依存しており、ＵＰｎＰ  ＡＶ規格上サポートは義務付けられていない。
【００３４】
図４は、クライアント機器２００がサーバ機器１０内のコンテンツデータ蓄積部１３に蓄積されたコンテンツデータのメタデータを取得するシーケンスを示す。尚、このメタデータ取得のシーケンスは従来技術と同様である。
【００３５】
クライアント機器２００は所望のコンテンツデータを指定し、コンテンツデータのメタデータを取得するためのＵＰｎＰ  ＡＶコマンドであるＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを送信する（Ｓ４０）。ＣＤＳ：：Ｂｒｏｗｓｅ要求を受信したサーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドが処理され（Ｓ４１）、コマンドの内容に従い、クライアント機器２００によって指定されたコンテンツデータのメタデータを取得する（Ｓ４２、Ｓ４３）。コンテンツデータ蓄積処理部１３ではコンテンツデータの一部としてメタデータを蓄積し、ＵＰｎＰ  ＡＶプロトコル処理部１２に応答してもよいし、メタデータの要求を受信してから動的にコンテンツデータからメタデータを生成してもよい。
【００３６】
ＵＰｎＰ  ＡＶプロトコル処理部１２は受信したメタデータからＣＤＳ：：Ｂｒｏｗｓｅ応答コマンドを生成し（Ｓ４４）、クライアント機器２００に応答する（Ｓ４５）。
【００３７】
尚、クライアント機器２１０においても同様のシーケンスで、サーバ機器１０から所望のコンテンツデータのメタデータを取得する。
【００３８】
図５は、図４で説明したサーバ機器１０からクライアント機器２００に送信されるＣＤＳ：：Ｂｒｏｗｓｅ応答コマンドに含まれるコンテンツデータのメタデータ５０を示す。このメタデータ５０はＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で記述されており、タイトル情報や、録画日情報、コンテンツデータの位置情報が記されている。
【００３９】
そして、クライアント機器２００ではコンテンツデータ取得に先立って、サーバ機器１０との間にＵＰｎＰ  ＡＶコマンドであるＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを送信し、論理的な接続を確立する。
【００４０】
図６は、サーバ機器１０とクライアント機器２００間で論理コネクションを確立するシーケンス図を示す。尚、図６のシーケンス図も従来と同様である。
【００４１】
クライアント機器２００はＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドをサーバ機器１０へ送信する（Ｓ６０）。ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求を受信したサーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドが処理され（Ｓ６１）、コネクション管理部１５に対して論理コネクションの生成を要求する（Ｓ６２）。
そして、論理コネクション生成要求を受信したコネクション管理部１５では、論理コネクションの管理可能数内であれば新たに論理コネクションを生成し、一意に識別可能なＩＤ（以下、コネクションＩＤと呼ぶ。）を割り当てる。また、コネクションＩＤをＵＰｎＰ  ＡＶプロトコル処理部に対して通知する（Ｓ６４）。ここではコネクションＩＤとして“２”が付与されている。コネクションＩＤはＵＰｎＰ  ＡＶプロトコル処理部１２によりＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンド中に記述され（Ｓ６５）クライアント機器２００に送信される（Ｓ６６）。
【００４２】
次に取得したコンテンツデータの位置情報をもとに物理コネクションを確立してコンテンツデータを取得するシーケンスを図７に示す。尚、本図に示すシーケンスも従来と同様となる。
【００４３】
クライアント機器２００では、コンテンツデータのメタデータ中に含まれるＵＲＬからＨＴＴＰ−ＧＥＴを発行する（Ｓ７０）。この際、先ほど確立した論理コネクションのコネクションＩＤをＨＴＴＰヘッダに付与しておく。
そして、ＨＴＴＰ−ＧＥＴ要求を受信したサーバ機器１０内のコンテンツデータ配信部１４ではＨＴＴＰ−ＧＥＴ要求のヘッダ中にコネクションＩＤが付与されているので（Ｓ７１）、当該コネクションＩＤが存在するか否かをコネクション管理部１５に問い合わせる（Ｓ７２）。コネクション管理部１５は照会のあったコネクションＩＤが存在するコネクションＩＤであることを確認し、クラアイントのＩＰアドレスやＭＡＣアドレスなどのアドレス情報をコネクションＩＤと関連付け記憶し（Ｓ７３）、コンテンツデータ配信部１４に応答する（Ｓ７４）。コンテンツデータ配信部１４はコンテンツデータ蓄積部１３にコンテンツデータ取得要求を送信し（Ｓ７５）取得する（Ｓ７６）。コンテンツデータ配信部１４は取得したコンテンツデータをＨＴＴＰを用いて、クライアント機器２００に送信する（Ｓ７７）。
【００４４】
図８は、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎコマンドをサポートしないクライアント機器２１０がコンテンツデータを取得するシーケンスを示す。尚、本図は、最初に物理コネクションを用いてコンテンツデータの取得要求を行うクライアント機器２１０に対してコンテンツデータの配信を行うサーバ機器１０の特徴を説明するものである。
【００４５】
クライアント機器２１０は図４でのシーケンス同様、サーバ機器１０に対してＣＤＳ：：Ｂｒｏｗｓｅ要求コマンドを送信し、その応答コマンドによって所望のコンテンツデータのＵＲＬを取得している。
クライアント機器２１０はＵＲＬに対してコテンツデータの取得を要求する（Ｓ８０）。ここでＨＴＴＰ−ＧＥＴ要求を受信したコンテンツデータ配信部１４では、ＨＴＴＰヘッダにコンテンツＩＤが付与されていないため（Ｓ８１）、コネクション管理部１５に対して新たな論理コネクションの生成を要求する（Ｓ８２）。コネクション管理部１５では管理可能なコネクション容量に空きがあるので論理コネクションを生成し、コネクションＩＤを付与し（Ｓ８３）クライアント機器２１０のアドレス情報などと関連付け記憶すると共に、コネクションＩＤをコンテンツデータ配信部１４に対して通知する（Ｓ８４）。その後、コンテンツデータ配信部１４はコンテンツデータ蓄積部１３にコンテンツデータ取得要求を送信し（Ｓ８５）取得する（Ｓ８６）。コンテンツデータ配信部１４は取得したコンテンツデータをＨＴＴＰに準拠したフォーマットに変換し、クライアント機器２００に送信する（Ｓ８７）。
【００４６】
このように、本発明に係るサーバ機器１０は、ＨＴＴＰヘッダにコンテンツＩＤが付与されていない、すなわち論理コネクションが確立されていないクライアント機器２１０からのＨＴＴＰ−ＧＥＴ要求を受信した場合にも、コネクション管理部１５において新たな論理コネクションの生成を要求して、コネクションＩＤを付与することが可能となる。
【００４７】
さらに、クライアント機器２００およびクライアント機器２１０がサーバ機器１０からコンテンツデータを受信中にクライアント機器２０がサーバ機器１０からコンテンツデータを取得する場合について説明を行う。
【００４８】
クライアント機器２０はＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎコマンドをサポートしているので、図６のシーケンス同様コンテンツデータ受信に先立ち、論理コネクションの生成を試みる。ここでサーバ機器１０は、例えば、同時に管理可能な論理コネクション数が２である場合には、既にクライアント機器２００およびクライアント機器２１０によって論理コネクションが生成されているので、クライアント機器２０のＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドに対し、サーバ機器１０は処理失敗応答が返信されることとなる。そこで、クライアント機器２０はサーバ機器１０が生成したコネクションＩＤを取得するためにＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドを発行する。図９にシーケンスを示す。
【００４９】
最初に、クライアント機器２０はＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドをサーバ機器１０へ送信する（Ｓ９０）。ＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求を受信したサーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドが処理され（Ｓ９１）、コネクション管理部１５に対して現在管理されているコネクションＩＤのリストの生成を要求する（Ｓ９２）。コネクションＩＤのリスト生成要求を受信したコネクション管理部１５では、管理しているコネクションＩＤのリスト生成し（Ｓ９３）、ＵＰｎＰ  ＡＶプロトコル処理部に対して通知する（Ｓ９４）。コネクションＩＤのリストはＵＰｎＰ  ＡＶプロトコル処理部１２によりＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ応答コマンドに変換され（Ｓ９５）クライアント機器２０に送信される（Ｓ９６）。
【００５０】
次に、クライアント機器２０はコネクションＩＤ“３”で管理される論理コネクションを削除する。図１０に論理コネクション削除のシーケンスを示す。
【００５１】
クライアント機器２０はＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドをサーバ機器１０へ送信する（Ｓ１００）。サーバ機器１０ではＵＰｎＰ  ＡＶプロトコル処理部１２により、ＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドが処理され（Ｓ１０１）、コネクション管理部１５に対してコネクションＩＤで示される論理コネクションの削除を要求する（Ｓ１０２）。論理コネクション削除要求を受信したコネクション管理部１５では、例えば、後述するクライアント機器毎に付与されている優先度を、後述する図１２（ｂ）に示す優先度テーブルを用いて参照して、優先度が高いクライアント機器（本図においてはクライアント機器２０）からの削除要求である場合には、コネクションＩＤで示される論理コネクションを削除し（Ｓ１０３）、処理結果をＵＰｎＰ  ＡＶプロトコル処理部に対して通知する（Ｓ１０４）。処理結果はＵＰｎＰ  ＡＶプロトコル処理部１２によりＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ応答コマンドに変換され（Ｓ１０５）クライアント機器２０に送信される（Ｓ１０６）。
【００５２】
ここでクライアント機器２０はＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを前述した手順で発行し、サーバ機器１０と論理コネクションを確立後、ＨＴＴＰ−ＧＥＴ要求によりサーバ機器１０内のコンテンツデータ蓄積部１３に記録された所望のコンテンツデータの取得を行い、コンテンツデータ再生部２４により再生を行う。
【００５３】
尚、図１１には、クライアント機器２０はコネクションＩＤ“３”で管理される論理コネクションを削除できない場合のシーケンス図を示す。
【００５４】
本図においては、Ｓ１１０〜Ｓ１１２までの処理は図１０のＳ１００〜Ｓ１０２までの処理と同様となるが、優先度が低いクライアント機器（本図においてはクライアント機器２０）からの削除要求であるために、論理コネクションのＩＤ削除不可と判断して（Ｓ１１３）、処理結果をＵＰｎＰ  ＡＶプロトコル処理部に対して通知し（Ｓ１１４）、ＵＰｎＰ  ＡＶプロトコル処理部１２により、コマンドの応答の中のパラメータに処理結果を示すフィールドがあり、そこにエラー情報が入ったＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅがエラー応答で返信され（Ｓ１１５）クライアント機器２０に送信される（Ｓ１１６）。尚、上記のエラー応答は、例えばエラーコードを拡張して、「これ以上はコネクションを張れない」旨のエラーメッセージを送信するものである。
【００５５】
以上の説明のように、本実施の形態１に係るサーバ機器においては、図８のＳ８１〜Ｓ８４に示すように、ＨＴＴＰヘッダにコンテンツＩＤが付与されているか否かを判定して、コネクションＩＤが付与されていない場合、即ちクライアント機器から論理コネクションの確立前に物理コネクションに基づくＨＴＴＰ−ＧＥＴ取得要求を受信した場合においても、コネクション管理部１５に対して新たな論理コネクションの生成を要求して、管理可能なコネクション容量に空きがある場合には、論理コネクションに用いるコネクションＩＤを付与することが可能となり、クライアント機器とサーバ機器間のコネクションを適切に管理することが可能となる。
【００５６】
以下、本実施の形態で示した構成の変形例について説明する。
【００５７】
上記実施の形態１では、クライアント機器から明示的にＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｅｌｅｔｅ要求コマンドを発行する事で論理コネクションを削除する構成について説明したが、論理コネクションで接続されるサーバ機器、クラアイント機器におけるサーバ機器ではＨＴＴＰ接続やＴＣＰ接続の切断をコンテンツデータ配信部が検知した場合には、コネクション管理部に対して当該論理コネクションの切断を要求する構成としてもよい。
【００５８】
また、サーバ機器において３０分間などの基準値を設け、基準時間を超えてＨＴＴＰ−ＧＥＴ要求を受信しなかった場合は、コネクション管理部に対して当該論理コネクションの切断を要求する構成としてもよい。
【００５９】
さらに、ＨＴＴＰ−ＧＥＴ要求をする際にＨＴＴＰヘッダ情報にＲａｎｇｅ指定を行い、コンテンツデータの取得に複数回のＨＴＴＰ−ＧＥＴ要求を行ってもよい。
（実施の形態２）
【００６０】
次に、本発明に係るサーバ機器の第二の実施の形態について図面を参照しながら説明を行う。尚、上記実施の形態１では、図１０及び図１１を用いて後からネットワークに参入したクライアント機器が優先度等に基づいて既に確立されたコネクションを削除して新たなコネクションを生成する方法について説明したが、本実施の形態では、後からネットワークに参入したクライアント機器による既存のコネクション削除を禁止する方法についての説明を行う。
【００６１】
また、本実施の形態におけるサーバ機器及びクライアント機器の構成図は、実施の形態１における構成図と同様であるので、説明を省略する。
【００６２】
この場合、図６において、クライアント機器２００からのＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドに対して、サーバ機器１０が当該論理コネクションを前述したＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドによって削除されない論理コネクションを生成したい場合は、コネクションＩＤを“０”としてＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンドをクライアント機器２００に送信する。
【００６３】
ここで、コネクションＩＤ“０”はコネクション管理部１５において、論理コネクションの数のみを管理し、クライアント機器のアドレス情報などのクライアント機器情報を管理しない事を表す。
【００６４】
図３で示されるネットワーク構成において、サーバ機器１０はクライアント機器２００からのＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドに対して、コネクションＩＤが“０”であるＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンドを返答する。その後、クライアント機器２００はコネクションＩＤ“０”をＨＴＴＰヘッダ情報に含むＨＴＴＰ−ＧＥＴ要求をサーバ機器１０に対して行い、コンテンツデータの取得を行う。
【００６５】
また、サーバ機器１０は、クライアント機器２１０からのＨＴＴＰ−ＧＥＴ要求に対して、コネクションＩＤが“０”である論理コネクションとしてコネクション管理部１５によって当該論理コネクションを管理する。
【００６６】
次に、クライアント機器２０はサーバ機器１０に対してＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを発行するが、サーバ機器２０では現在管理している論理コネクション数が管理可能な最大論理コネクション数（本実施の形態の説明においては２本）に達しているため、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ応答コマンドにエラー応答を行う。次に、クライアント機器２０はＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ要求コマンドを発行する。サーバ機器１０はＣＭＳ：：ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ応答コマンドとして“ＩＤ＝０”を応答する。
【００６７】
クライアント機器２０はコネクションＩＤが“０”であるＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドを送信するが、サーバ機器１０内のコネクション管理部１５において、当該コネクションＩＤで示される論理コネクションの情報は存在しないため、当該コネクションＩＤで示される論理コネクションは削除されず、クライアント機器２０に対してはＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ応答コマンドが返送されるが、クライアント機器２００およびクライアント機器２１０においてはコネクションは確立されたままとなる。
【００６８】
クライアント機器２００、およびクライアント機器２１０ではコンテンツデータの取得が完了した時点でＨＴＴＰコネクションが切断される。ＨＴＴＰコネクションが切断されるとコンテンツデータ配信部１４はコネクション管理部１５に対して、論理コネクションの削除を要求する。要求を受けたコネクション管理部１５では管理する論理コネクションを削除する。
【００６９】
なお、ここではＨＴＴＰコネクションの切断でコネクションＩＤ“０”で表される論理コネクションが削除される条件となる例を示したが、ＴＣＰコネクションの切断が論理コネクションが切断される条件としてもよい。
【００７０】
また、図１２（ａ）に示すように、ＣＭＳ：：ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ要求コマンドを送信したクラアイント機器のアドレス情報（ＰＦＣ生成先）や、ＨＴＴＰ接続が確立されているクラアイント機器のアドレス情報（ＨＴＴＰ配信先）、またテレビやＶＯＤ（Ｖｉｄｅｏ  Ｏｎ  Ｄｅｍａｎｄ）など配信中のコンテンツデータの種別（サービス）、優先度などをコネクション管理情報１２０として記憶し、例えば、サービスがＶＯＤである論理コネクションはＣＭＳ：：ＣｏｎｎｅｃｔｉｏｎＣｏｍｐｌｅｔｅ要求コマンドによって削除されることのないような構成としてもよい。ここでは、サービスという１つの情報に基づいて論理コネクション削除が拒否される条件について説明したが、ＨＴＴＰ配信先とサービスなど２つ以上の情報を組み合わせで条件を設定してもよい。
【００７１】
また、図１２（ａ）のコネクション管理情報１２０に示すように、提供されるコンテンツのサービスの種類がＶＯＤである場合には、コネクションＩＤが“０”となり、論理コネクションの切断を行うことができない設定となっている。また、２つ目のコネクションで、ＰＦＣ生成先が記述されていないコネクションは、クライアント機器が最初に物理コネクションを用いてコンテンツ取得要求を行った場合におけるコネクションであり、コネクション管理情報１２０の３つ目のコネクションは、ＰＦＣ生成先とＨＴＴＰ配信先とが異なるアドレスとなっているが、これは論理コネクションの接続を他のクライアント機器から行った場合の例である。
【００７２】
そして、コネクション管理情報１２０に記載されている優先度は、他のクライアント機器からの論理コネクション切断の判断を行う場合に用いられ、例えば、優先度が１である父親のクライアント機器からは優先度が３である兄のコネクションを切断することができる一方、兄のクライアント機器から父親の論理コネクションを勝手に切断できない設定となっている。
【００７３】
また、図１２（ｂ）は、本発明のサーバ機器に管理される優先度テーブル１２１の一例を示し、サーバ機器に接続されているクライアント機器のＩＰアドレスと、論理コネクション確立における優先度との関係が記述されている。サーバ機器は、この優先度テーブル１２１を参照することにより、例えば、図１０及び図１１に示すように、優先度の高いクライアント機器から、既に確立されている優先度の低いクライアント機器のコネクションＩＤの削除を行うことが可能となる。尚、図１２ではアドレス情報としてＩＰアドレスを用いる例を示したが、ＭＡＣアドレス等の物理アドレスを用いてもよい。
【００７４】
以上説明したように、本実施の形態２に係るサーバ機器は、コネクション管理情報１２０や優先度テーブル１２１を用いて、コネクション本数に限りのあるクライアント機器との間のコネクションを適切に管理することが可能となる。
【００７５】
また、本実施の形態２に係るサーバ機器では、ホームネットワークの規格において、下位互換を保ちながらも新たにコネクション管理を行うことが可能となり、これに合わせて、コネクション管理情報１２０等を用いることにより、例えばテレビ放送のような映像配信については“後取り優先”のコネクション管理を行い、ビデオオンデマンドのように個人が任意で楽しむような映像配信については“先取り優先”のコネクション管理を行うなど、サービスによって効率的なリソース管理が行える効果を発揮する。
【００７６】
尚、本実施の形態２ではコネクションＩＤ“０”を論理コネクションに関する詳細情報を持たない予約値として、コネクション管理部において扱う構成について説明したが、予約値は“０”以外のいかなる数値であってもよい事は説明するまでもない。
【００７７】
また、コネクションＩＤ“０”が指定された場合は論理コネクションを生成せず、実際のＨＴＴＰコネクションのみを用いてコンテンツデータのやりとりを行う構成としてもよい。
【００７８】
さらに、配信するコンテンツの種別を判定して、例えば、録画中コンテンツの配信時にはコネクション削除を禁止し、録画済コンテンツの配信時にはコネクション削除を可能とすることも考えられる。
【００７９】
そして、上述の説明においてはコネクションＩＤ消去のタイミングについては言及していないが、例えば、コンテンツの配信要求が一定期間なかった場合や、配信要求先のＩＰアドレスからコンテンツ配信要求先を特定して一定期間後に消去することが考え得る。
【００８０】
また、セキュリティの関係で登録したＭＡＣアドレス以外のクライアント機器からのコネクション接続要求を受け付けない構成とすることも考え得る。
【産業上の利用可能性】
【００８１】
本発明に係るＡＶサーバ機器は、例えば、ＵＰｎＰ−ＡＶのＣＤＳに準じるファイル転送方法に基づいて宅内ネットワークを介して家電機器間でのマルチメディアコンテンツの転送を行うＡＶサーバ機器として適用できる。
【図面の簡単な説明】
【００８２】
【図１】図１は、本発明の実施の形態におけるサーバ機器の主要部の構成を示すブロック図である。
【図２】図２は、同、クライアント機器の主要部の構成を示すブロック図である。
【図３】図３は、同、サーバ機器、クライアント機器のネットワーク構成図である。
【図４】図４は、同、メタデータ取得のシーケンス図である。
【図５】図５は、同、コンテンツデータのメタデータである。
【図６】図６は、同、サーバ機器、クライアント機器間での論理コネクション確立手順のシーケンス図である。
【図７】図７は、同、論理コネクション確立有りの際のコンテンツデータ取得のシーケンス図である。
【図８】図８は、同、論理コネクション確立無しの際のコンテンツデータ取得のシーケンス図である。
【図９】図９は、同、コネクションＩＤ一覧取得のシーケンス図である。
【図１０】図１０は、同、コネクション削除のシーケンス図である。
【図１１】図１１は、同、コネクション削除不可の場合のシーケンス図である。
【図１２】図１２は、同、コネクション管理情報である。
【図１３】図１３は、従来の論理コネクション確立無しの際のコンテンツデータ取得のシーケンス図である。
【符号の説明】
【００８３】
３  通信路
１０  サーバ機器
１１  通信部
１２  ＵＰｎＰ  ＡＶプロトコル処理部（サーバ機能）
１３  コンテンツデータ蓄積部
１４  コンテンツデータ配信部
１５  コネクション管理部
２０  クライアント機器
２１  通信部
２２  ＵＰｎＰ  ＡＶプロトコル処理部（クライアント機能）
２３  コンテンツデータ受信部
２４  コンテンツデータ再生部
５０  メタデータ
１２０  コネクション管理情報
１２１  優先度テーブル
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006077935.tif 000015
【図２】
2006077935.tif 000016
【図３】
2006077935.tif 000017
【図４】
2006077935.tif 000018
【図５】
2006077935.tif 000019
【図６】
2006077935.tif 000020
【図７】
2006077935.tif 000021
【図８】
2006077935.tif 000022
【図９】
2006077935.tif 000023
【図１０】
2006077935.tif 000024
【図１１】
2006077935.tif 000025
【図１２】
2006077935.tif 000026
【図１３】
2006077935.tif 000027
【国際調査報告】
2006077935.tif 000028
2006077935.tif 000029
2006077935.tif 000030
2006077935.tif 000031
2006077935.tif 000032
2006077935.tif 000033