WO2006077935A1

WO2006077935A1 - Ａｖサーバ機器

Info

Publication number: WO2006077935A1
Application number: PCT/JP2006/300757
Authority: WO
Inventors: Takayuki Fukui; Monta Nakatsuka
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2005-01-21
Filing date: 2006-01-19
Publication date: 2006-07-27
Also published as: EP1840750A4; DE602006020403D1; CN101080704A; US8001251B2; JPWO2006077935A1; EP1840750A1; CN101080704B; US20070260678A1; EP1840750B1

Description

AVサーバ機器

技術分野

[0001] 本発明は、宅内ネットワーク等を介してクライアント機器に音楽や動画などの AVコンテンッ等を提供する AVサーバ機器に関し、特に、宅内にある複数のクライアント機器に AVコンテンツを送信する AVサーバ機器に関する。

背景技術

[0002] 近年、 xDSLや光ファイバ一などのブロードバンド環境が整ったことにより、企業、一般家庭を問わずインターネット接続が急速に普及してきている。また、家庭内の PC や家電機器を Ethernet (登録商標）や無線 LANなどで接続するホームネットワーク環境も一般化してきている。この様な中で、パーソナルコンピュータ（PC)だけでなぐテレビや DVDレコーダ、エアコン、冷蔵庫のような家電も IETF (Internet Enginee ring Task Force)により定義される IP (Internet Protocol)により相互に接続できるようになってきている。

[0003] インターネットやホームネットワークにおけるアプリケーションの 1つとして、家電機器や PC間で音楽や動画などの AVコンテンツを視聴するアプリケーションがある。例えば、 DVDレコーダに録画した放送番組を、ネットワークに接続された TVや PCなどで視聴する AVストリーミング機能を提供する例などである。

[0004] この様な AVストリーミングを行うプロトコルでは、代表的なものとしては、 RFC2616 で定義される HTTP (Hyper Text Transfer Protocol)や、 RFC1889で定義される RTP (Real— time Transport Protocol)等が存在した。特に、 HTTPは TC P (Transmission Control Protocol)の再送機能によって転送の信頼性を確保している。すなわち、 TCPはパケットのエラーを検出して再送する手順と、欠落したパケットを検出して再送する手順を含んでおり、そのために伝送路上でエラーやバケツト欠落が起こっても正しいファイルの転送が保障できる。

[0005] そして、伝送エラーが発生しやす!/、ネットワーク環境では、データの再送信のためにスループットが低下するといつた特徴があり、このため、 TCPは、ホームネットワークのような伝送路上のエラーやパケット欠落が発生し易い環境下における AVストリーミングに向いており、 UPnP AV (Universal Plug and Play Audio/Video A rchitecture)や、 DLNA (Digital Living Network Alliance)などの基本的な AVストリーミング方式となって!/、る。

[0006] し力しながら、 HTTPでの AVストリーミングは信頼性が高い反面、リアルタイム性を保持するためには AVサーバ機器側のリソースに依存する。例えば高ビットレートの転送速度が要求される蓄積データや、複数同時アクセスされた場合などには、スル一プットを見据えて AVサーバ機器側でリソース配分の管理を行う必要がある。リソース配分の管理方法としては、（1) HTTPメッセージの送受信を行うための TCPコネクシヨンの本数を制限するなどが考えられる。この場合、制限を超えて後からネットヮーク再生をリクエストしようとしたクライアント機器に対しては、一般にエラーメッセージが送信されるか、またはリクエストそのものが無視され、先にコネクションを確立したクライアント機器は、 AVコンテンツの視聴を継続して楽しめる。これは先にコネクション確立を行った機器を優先する"先取り優先"の考え方である。この"先取り優先"の考え方は、物理コネクションに代表されるものである。

[0007] 一方、（2) UPnP AVにはコネクション管理のための CMS (Connection Manag er Service)というものがあり、論理的なコネクションの確立 ·切断を行うためのコマンド（SOAP Action)が存在する。具体的には、コネクションを確立するためのコマンドが CMS : : PrepareForConnectionであり、このコマンドを受信した AVサーバ機器は、サーバ内部においてリソースの空きがあれば IDを発行する。また、コネクションを切断した、場合にぉ、ては CMS：： ConnectionCompleteを AVサーバ機器に送信することで、 AVサーノ機器はリソースの解放を行う。 CMSは論理的なコネクション確立をするものであるため、 HTTPにおける AVストリーミングと連動するために、 H TTPヘッダ等に IDを付与するなどの関連付けすることが一般的である。

[0008] そして、 CMS：： ConnectionCompleteは、必ずしも CMS：： PrepareForConne ctionにて IDを取得した機器のみが出来るわけではないため、 AVサーバ機器にお V、てリソース配分されて!、る IDを閲覧するためのコマンドである CMS：： GetCurrent ConnectionlDsを発行した上で、 IDを知る事が出来、更に IDを解放するために C MS : : ConnectionCompleteを AVサーバ機器に送信することで、先にコネクションを確立したクライアント機器を、後から別のクライアント機器が切断することも可能である。これは後からコネクション確立を要求した方が優先される"後取り優先"の考え方である。この"後取り優先"の考え方は、論理コネクションに代表されるものである。

[0009] このように、 (2)においては、 TCPコネクションの本数とは別に、 CMSによる論理的なコネクションの本数によってリソース管理をする方法となる。

[0010] 上記のことは、例えば特許文献 1、並びに特許文献 2に開示されている。

特許文献 1：特開 2002— 84484号公報

特許文献 2：特開 2004— 348454号公報

発明の開示

発明が解決しょうとする課題

[0011] 前述した通り、物理コネクションである TCPコネクションの本数などでリソース管理する方法は、 "先取り優先"の考え方であるのに対し、論理コネクションを用いる UPnP AVの CMSなどでリソース管理する方法は、 "後取り優先"の考え方である。

[0012] 例えば、（l)TCPコネクションの本数によりリソース管理する方法と、 CMSなどの論理的なコネクションの本数によりリソース管理する方法を併用して用いる AVサーバ機器においては、 HTTPリクエストのみで AVコンテンツ要求された場合には先取り優先の機能が働くため、後力 CMS : : PrepareForConnectionなどで要求された場合において、リソースが割り振れず、かつ CMS : : ConnectionCompleteなどでリソースを解放することも出来な、と、う課題を有して、る。

また、（2) CMSなどの論理的なコネクションの本数だけでリソース管理する方法を用いた AVサーバ機器においては、常に後取り優先の機能が働くため、ビデオオンデマンドなどの個人で楽しむサービスを提供した時に、いつ何時、誰からでも視聴を中断されると、う課題を有して、る。

[0013] さらに、（3)今後、宅内の 1つの AVサーバ機器に家族の各々のクライアント機器が宅内ネットワークを介して接続してコンテンツ視聴するような環境が考えられ、そのような場合には、 AVサーバ機器にぉヽて有効なコネクション本数のリソース管理を適切に行うために、主に UPnPに基づく AVコンテンツ配信においては、コンテンツの実体を配信するための物理コネクションの確立前に、論理コネクションの確立が要求されるようになる。し力しながら、現状のクライアント機器においては、最初に物理コネクシヨンを用いてコンテンツ取得要求を行う機器が一般的であり、このような場合には、図

13の S134に示すように、 AVサーバ機器 140においては論理コネクションの ID確認ができず、コネクションなしとしてエラー返信（S 136)を行うために、クライアント機器 1 30は要求するコンテンツが取得できな、と、う課題もある。

[0014] 本発明は、上記従来の課題を解決するもので、 AVコンテンツを要求するクライアント機器とのコネクションにお、て、物理コネクション及び論理コネクションを併用して、コネクションの"先取り優先"及び"後取り優先"を実現した AVサーバ機器を提供することを目的とする。

課題を解決するための手段

[0015] 上記目的を達成するために、本発明に係る AVサーバ機器は、ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信する AVサーバ機器であって、通信パケットを送受信する通信手段と、前記通信手段を用いて物理コネクションに基づいてコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信手段と、前記コンテンツデータを蓄積するコンテンツデータ蓄積手段と、前記通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、前記コンテンツデータ配信手段の前記物理コネクション、及び前記プロトコル処理手段の前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクション IDに基づいて行うコネクション管理手段とを備え、前記通信手段が前記クライアント機器力前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクション IDの確認処理を行、、前記コンテンツデータ配信手段は、前記コネクション IDの確認ができない場合には、前記コネクション管理手段に対して前記コネクション IDの生成要求を行うことを特徴とする。

[0016] また、本発明に係る AVサーバ機器の前記コネクション管理手段は、前記コネクション IDの生成要求を受けた場合には、前記コネクション IDを生成し、前記コンテンツデータ配信手段に応答し、前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、前記通信手段は、前記物理コネクションに基づ、て前記コンテンツデータを前記クライアント機器に送信することを特徴とする。

[0017] これらの構成により、クライアント機器力論理コネクションの確立前に物理コネクシヨンに基づくコンテンツデータ配信要求を受信した場合においても、コンテンツデータ配信手段にぉ、てコネクションの種類を判定して、コネクション IDが付与されて、な V、場合、即ち論理コネクションが確立して、な、コンテンツデータの配信要求に対しても、コネクション管理手段においてコネクション IDを生成して、コンテンツデータ配信手段は通信手段を介してコンテンツデータをクライアント機器に配信することが可能となる。

[0018] また、本発明に係る AVサーバ機器の前記コネクション管理手段は、少なくとも前記 AVサーバ機器に接続された各クライアント機器のアドレス情報と、前記論理コネクシヨン確立の優先度との関係が記述された優先度テーブルを管理し、前記プロトコル処理手段は、前記クライアント機器力前記コネクション管理手段が保持する前記コネクシヨン情報を消去するためのコマンドを受信した際に、前記コネクション管理手段は、前記優先度テーブルを参照して、優先度の高いクライアント機器力の削除要求である場合に前記コネクション管理手段が保持する前記コネクション IDを消去することを特徴とする。

[0019] この構成により、 AVサーバ機器でクライアント機器の論理コネクション接続における優先とを優先度テーブルを用いて参照して、優先度の高、クライアント機器からの接続要求を優先することができ、複数のクライアント機器が接続される AVサーノ機器のコネクション本数に限りがある場合において有効なコネクション利用を図ることが可能となる。

[0020] また、本発明に係る AVサーバ機器の前記コネクション管理手段は、少なくとも前記コネクション IDと、前記論理コネクションの生成先となるクライアント機器のアドレス情報、前記物理コネクションの接続先となるクライアント機器のアドレス情報、前記コンテンッのサービス情報、及び前記クライアント機器毎に付与されて、る前記論理コネクシヨン確立の優先度の少なくとも 1つが記載されたコネクション管理情報を管理し、前記プロトコル処理手段は、前記クライアント機器力も前記コネクション管理手段が保持するコネクション ID情報を消去するためのコマンドを受信した際に、前記コネクション管理情報を参照し、予め定められたコネクション IDが付与されている場合には、前記コネクション管理手段が保持する前記コネクション IDを消去しないことを特徴とする。

[0021] この構成により、 AVサーバ機器においてはコネクション管理情報に記載されている情報に基づいてコネクションの接続及び切断を行うことができ、より適切なクライアント機器とのコネクション管理を行うことが可能となる。

[0022] 尚、前記目的を達成するために、本発明は、 AVサーバ機器の特徴的な構成手段をステップとするコネクション管理方法としたり、この方法が備える特徴的な命令を含むプログラムとして実現することもできる。そして、そのようなプログラムは、 CD-RO

M等の記録媒体やインターネット等の通信ネットワークを介して流通させることができるのは言うまでもない。

発明の効果

[0023] 本発明に係る AVサーバ機器によれば、物理コネクションである TCPコネクションの本数などでリソース管理する方法においても、論理コネクションの管理と併用することで"後取り優先"にすることが可能であると同時に、論理コネクションの管理においても"先取り優先"させることができ、 AVサーバ機器とクライアント機器との間のコネクシヨンを適切に管理することが可能となる。

図面の簡単な説明

[0024] [図 1]図 1は、本発明の実施の形態におけるサーバ機器の主要部の構成を示すプロック図である。

[図 2]図 2は、同、クライアント機器の主要部の構成を示すブロック図である。

[図 3]図 3は、同、サーバ機器、クライアント機器のネットワーク構成図である。

[図 4]図 4は、同、メタデータ取得のシーケンス図である。

[図 5]図 5は、同、コンテンツデータのメタデータである。

[図 6]図 6は、同、サーバ機器、クライアント機器間での論理コネクション確立手順のシ一ケンス図である。

[図 7]図 7は、同、論理コネクション確立有りの際のコンテンツデータ取得のシーケンス図である。

[図 8]図 8は、同、論理コネクション確立無しの際のコンテンツデータ取得のシーケンス図である。

[図 9]図 9は、同、コネクション ID—覧取得のシーケンス図である。

[図 10]図 10は、同、コネクション削除のシーケンス図である。

[図 11]図 11は、同、コネクション削除不可の場合のシーケンス図である。

[図 12]図 12は、同、コネクション管理情報である。

[図 13]図 13は、従来の論理コネクション確立無しの際のコンテンツデータ取得のシーケンス図である。

符号の説明

[0025] 3 通信路

10 サーバ機器

11 通信部

12 UPnP AVプロトコル処理部（サーバ機能）

13 コンテンツデータ蓄積咅

14 コンテンツデータ配信部

15 コネクション管理部

20 クライアント機器

21 通信部

22 UPnP AVプロトコル処理部（クライアント機能）

23 コンテンツデータ受信部

24 コンテンツデータ再生部

50 メタデータ

120 コネクション管理情報

121 優先度テーブル

発明を実施するための最良の形態

[0026] 以下、本発明を実施するための最良の形態について図面を用いて説明する。

(実施の形態 1) [0027] 図 1は、本実施の形態におけるサーバ機器 10の主要部の構成を示すブロック図である。

[0028] サーバ機器 10は、通信路 3を介してクライアント機器と通信する通信部 11を備える。ここで通信路 3は、イーサネット（登録商標）などの有線通信路ゃ IEEE802. 110/ bZg、 Bluetoothなどの無線通信路とする。

[0029] またサーバ機器 10はユニバーサル 'プラグ 'アンド'プレイ AV規格のプロトコル処理部 12を備え、 UPnP AV規格に準拠した機器検索や能力交換などの処理を実行することができる。また、 UPnP AV規格に準拠したクライアント機器が送信した UPn P AVコマンドを受信し、受信したコマンドに従って動作する。

[0030] コンテンツデータ蓄積部 13には録画されたテレビ番組や、 DVC (Digital Video Camera)などで撮影された動画データ、 DSC (Digital Still Camera)などで撮影された静止画データ、録音されたラジオ番組や録音された CD (Compact Disc) 楽曲などの音声データ（以下、動画、静止画、音声の各データをコンテンツデータと呼ぶ。）が蓄積されている。

クライアント機器では、これらのコンテンツデータのタイトル情報や、録音録画日情報、 URL (Uniformed Resource Locator)等で表されるコンテンツデータの位置情報（以下、これらをまとめてメタデータと呼ぶ。）は UPnP AVコマンド要求により、 UPnP AVプロトコル処理部を介して取得する事ができる。また、コンテンツデータ蓄積部 14に蓄積されたコンテンツデータは、 HTTP (Hyper Text Transport P rotocol)などのコンテンツデータ配信部 14を用いてクライアントに配信される。またコンテンッデータを配信する際の HTTP接続のセッション情報はコネクション管理部 15 によって管理される。クライアント機器では、コネクション管理部 15によって管理されるセッション情報の一覧を UPnP AVコマンド要求により、 UPnP AVプロトコル処理部を介して取得する事ができる。

[0031] 図 2は、クライアント機器 20の主要部の構成を示すブロック図である。

[0032] クライアント機器 20は、通信路 3を介してサーバ機器と通信する通信部 21を備える。また UPnP AV規格のプロトコル処理部 22を備え、 UPnP AV規格に準拠したサーバ機器に対して UPnP AVコマンドを送信し、サーバ機器を遠隔制御する事ができる。

[0033] また、サーバ機器力もコンテンツデータを受信するコンテンツデータ受信部 23を備え、 HTTP等でコンテンツデータを取得する事ができる。取得したコンテンツデータはコンテンツデータ再生部 24により再生できる。ここで、コンテンツデータ再生部 24 はコンテンツデータが動画データであり MPEG (Moving Picture Experts Gro up)エンコードされたものである場合には、 MPEGエンコーダである。

[0034] 図 3は、本実施の形態におけるサーバ機器 10、クライアント機器 20、 200、及び 21 0のネットワーク構成図である。

[0035] 通信路 3を介してサーバ機器 10、クライアント機器 20、クライアント機器 200、およびクライアント機器 210が接続されている。ここでクライアント機器 20、クライアント機器 200、およびクライアント機器 210は UPnPの機器検索機能によりサーノ機器 10を認識している。

そして、サーバ機器 10、クライアント機器 20、クライアント機器 200は UPnP AVォプシヨンコマンドである CMS : : PrepareForConnection、および CMS : : Connecti on Completeをサポートしており、論理コネクション及び物理コネクションに対応している。

一方、クライアント機器 210は上記 2つの UPnP AVコマンドをサポートしていない。すなわち、クライアント機器 210は、物理コネクションに対応しているが論理コネクションは対応して、な、。オプションコマンドをサポートするか否かは機器に依存しており、 UPnP AV規格上サポートは義務付けられていない。

[0036] 図 4は、クライアント機器 200がサーバ機器 10内のコンテンツデータ蓄積部 13に蓄積されたコンテンツデータのメタデータを取得するシーケンスを示す。尚、このメタデータ取得のシーケンスは従来技術と同様である。

[0037] クライアント機器 200は所望のコンテンツデータを指定し、コンテンツデータのメタデータを取得するための UPnP AVコマンドである CDS :： Browse要求コマンドを送信する（S40)。 CDS：： Browse要求を受信したサーバ機器 10では UPnP AVプロトコル処理部 12により、 CDS :： Browse要求コマンドが処理され（S41)、コマンドの内容に従い、クライアント機器 200によって指定されたコンテンッデータのメタデータを取得する（S42、 S43)。コンテンツデータ蓄積処理部 13ではコンテンツデータの一部としてメタデータを蓄積し、 UPnP AVプロトコル処理部 12に応答してもよいし、メタデータの要求を受信して力動的にコンテンツデータからメタデータを生成してもよい。

[0038] UPnP AVプロトコル処理部 12は受信したメタデータから CDS :： Browse応答コマンドを生成し (S44)、クライアント機器 200に応答する（S45)。

[0039] 尚、クライアント機器 210においても同様のシーケンスで、サーノ機器 10力も所望のコンテンツデータのメタデータを取得する。

[0040] 図 5は、図 4で説明したサーバ機器 10からクライアント機器 200に送信される CDS :

： Browse応答コマンドに含まれるコンテンツデータのメタデータ 50を示す。このメタデータ 50は XML (extensible Markup Language)で記述されており、タイトル情報や、録画日情報、コンテンツデータの位置情報が記されている。

[0041] そして、クライアント機器 200ではコンテンツデータ取得に先立って、サーバ機器 10 との間に UPnP AVコマンドである CMS : : PrepareForConnection要求コマンドを送信し、論理的な接続を確立する。

[0042] 図 6は、サーバ機器 10とクライアント機器 200間で論理コネクションを確立するシーケンス図を示す。尚、図 6のシーケンス図も従来と同様である。

[0043] クライアント機器 200は CMS：： PrepareForConnection要求コマンドをサーバ機器 10へ送信する（S60)。 CMS : : PrepareForConnection要求を受信したサーバ機器 10では UPnP AVプロトコル処理部 12により、 CMS：： PrepareForConnecti on要求コマンドが処理され（S61)、コネクション管理部 15に対して論理コネクションの生成を要求する（S62)。

そして、論理コネクション生成要求を受信したコネクション管理部 15では、論理コネクシヨンの管理可能数内であれば新たに論理コネクションを生成し、一意に識別可能な ID (以下、コネクション IDと呼ぶ。）を割り当てる。また、コネクション IDを UPnP AV プロトコル処理部に対して通知する（S64)。ここではコネクション IDとして" 2"が付与されている。コネクション IDは UPnP AVプロトコル処理部 12により CMS :： Prepare ForConnection応答コマンド中に記述され（S65)クライアント機器 200に送信される（S66)。

[0044] 次に取得したコンテンッデータの位置情報をもとに物理コネクションを確立してコンテンッデータを取得するシーケンスを図 7に示す。尚、本図に示すシーケンスも従来と同様となる。

[0045] クライアント機器 200では、コンテンツデータのメタデータ中に含まれる URL力 H TTP— GETを発行する（S70)。この際、先ほど確立した論理コネクションのコネクシヨン IDを HTTPヘッダに付与しておく。

そして、 HTTP— GET要求を受信したサーバ機器 10内のコンテンツデータ配信部 1 4では HTTP— GET要求のヘッダ中にコネクション IDが付与されているので（S71) 、当該コネクション IDが存在する力否かをコネクション管理部 15に問い合わせる（S7 2)。コネクション管理部 15は照会のあったコネクション IDが存在するコネクション ID であることを確認し、クラアイントの IPアドレスや MACアドレスなどのアドレス情報をコネクシヨン IDと関連付け記憶し (S73)、コンテンツデータ配信部 14に応答する（S74 )。コンテンツデータ配信部 14はコンテンッデータ蓄積部 13にコンテンッデータ取得要求を送信し (S75)取得する（S76)。コンテンツデータ配信部 14は取得したコンテンッデータを HTTPを用いて、クライアント機器 200に送信する（S77)。

[0046] 図 8は、 CMS：： PrepareForConnectionコマンドをサポートしな!/、クライアント機器 210がコンテンツデータを取得するシーケンスを示す。尚、本図は、最初に物理コネクシヨンを用いてコンテンツデータの取得要求を行うクライアント機器 210に対してコンテンツデータの配信を行うサーバ機器 10の特徴を説明するものである。

[0047] クライアント機器 210は図 4でのシーケンス同様、サーバ機器 10に対して CDS：： Br owse要求コマンドを送信し、その応答コマンドによって所望のコンテンツデータの U RLを取得している。

クライアント機器 210は URLに対してコテンッデータの取得を要求する（S80)。ここで HTTP— GET要求を受信したコンテンツデータ配信部 14では、 HTTPヘッダにコンテンッ IDが付与されていないため（S81)、コネクション管理部 15に対して新たな論理コネクションの生成を要求する（S82)。コネクション管理部 15では管理可能なコネクシヨン容量に空きがあるので論理コネクションを生成し、コネクション IDを付与し（ S83)クライアント機器 210のアドレス情報などと関連付け記憶すると共に、コネクション IDをコンテンツデータ配信部 14に対して通知する（S84)。その後、コンテンツデータ配信部 14はコンテンッデータ蓄積部 13にコンテンツデータ取得要求を送信し（ S85)取得する（S86)。コンテンツデータ配信部 14は取得したコンテンツデータを H TTPに準拠したフォーマットに変換し、クライアント機器 200に送信する（S87)。

[0048] このように、本発明に係るサーバ機器 10は、 HTTPヘッダにコンテンツ IDが付与されて、な、、すなわち論理コネクションが確立されて、な、クライアント機器 210からの HTTP - GET要求を受信した場合にも、コネクション管理部 15におヽて新たな論理コネクションの生成を要求して、コネクション IDを付与することが可能となる。

[0049] さらに、クライアント機器 200およびクライアント機器 210がサーバ機器 10からコンテンッデータを受信中にクライアント機器 20がサーバ機器 10からコンテンツデータを取得する場合について説明を行う。

[0050] クライアント機器 20は CMS：： PrepareForConnectionコマンドをサポートして!/、るので、図 6のシーケンス同様コンテンツデータ受信に先立ち、論理コネクションの生成を試みる。ここでサーバ機器 10は、例えば、同時に管理可能な論理コネクション数が 2である場合には、既にクライアント機器 200およびクライアント機器 210によって論理コネクションが生成されているので、クライアント機器 20の CMS : : PrepareForCo nnection要求コマンドに対し、サーバ機器 10は処理失敗応答が返信されることとなる。そこで、クライアント機器 20はサーバ機器 10が生成したコネクション IDを取得するために CMS : : GetCurrentConnectionIDs要求コマンドを発行する。図 9にシーケンスを示す。

[0051] 最初に、クライアント機器 20は CMS：： GetCurrentConnectionlDs要求コマンドをサーバ機器 10へ送信する（S90)。 CMS :： GetCurrentConnectionlDs要求を受信したサーバ機器 10では UPnP AVプロトコル処理部 12により、 CMS : : GetCu rrentConnectionlDs要求コマンドが処理され（S91)、コネクション管理部 15に対して現在管理されているコネクション IDのリストの生成を要求する（S92)。コネクション I Dのリスト生成要求を受信したコネクション管理部 15では、管理しているコネクション I Dのリスト生成し（S93)、 UPnP AVプロトコル処理部に対して通知する（S94)。コネクシヨン IDのリストは UPnP AVプロトコル処理部 12により CMS : : GetCurrentC onnectionlDs応答コマンドに変換され（S95)クライアント機器 20に送信される（S9 6)。

[0052] 次に、クライアント機器 20はコネクション ID"3"で管理される論理コネクションを削除する。図 10に論理コネクション削除のシーケンスを示す。

[0053] クライアント機器 20は CMS：： ConnectionComplete要求コマンドをサーバ機器 1 0へ送信する（S100)。サーバ機器 10では UPnP AVプロトコル処理部 12により、 C MS : : ConnectionComplete要求コマンドが処理され（S101)、コネクション管理部 15に対してコネクション IDで示される論理コネクションの削除を要求する（S102)。論理コネクション削除要求を受信したコネクション管理部 15では、例えば、後述するクライアント機器毎に付与されている優先度を、後述する図 12 (b)に示す優先度テーブルを用いて参照して、優先度が高、クライアント機器 (本図にお、てはクライアント機器 20)力もの削除要求である場合には、コネクション IDで示される論理コネクションを削除し（S103)、処理結果を UPnP AVプロトコル処理部に対して通知する（S 10 4)。処理結果は UPnP AVプロトコル処理部 12により CMS : : ConnectionCompl e_te応答コマンドに変換され (S 105)クライアント機器 20に送信される（S 106)。

[0054] ここでクライアント機器 20は CMS：： PrepareForConnection要求コマンドを前述した手順で発行し、サーバ機器 10と論理コネクションを確立後、 HTTP— GET要求によりサーバ機器 10内のコンテンツデータ蓄積部 13に記録された所望のコンテンツデータの取得を行い、コンテンツデータ再生部 24により再生を行う。

[0055] 尚、図 11には、クライアント機器 20はコネクション ID"3"で管理される論理コネクシヨンを削除できな、場合のシーケンス図を示す。

[0056] 本図においては、 S110〜S112までの処理は図 10の S100〜S102までの処理と同様となるが、優先度が低、クライアント機器 (本図にお、てはクライアント機器 20) 力もの削除要求であるために、論理コネクションの ID削除不可と判断して（S113)、処理結果を UPnP AVプロトコル処理部に対して通知し（SI 14)、 UPnP AVプロトコル処理部 12により、コマンドの応答の中のパラメータに処理結果を示すフィールドがあり、そこにエラー情報が入った CMS : : ConnectionCompleteがエラー応答で返信され (SI 15)クライアント機器 20に送信される（SI 16)。尚、上記のエラ一応答は、例えばエラーコードを拡張して、「これ以上はコネクションを張れない」旨のエラ一メッセージを送信するものである。

[0057] 以上の説明のように、本実施の形態 1に係るサーノ機器においては、図 8の S81〜 S84に示すように、 HTTPヘッダにコンテンツ IDが付与されているか否かを判定して、コネクション IDが付与されていない場合、即ちクライアント機器力も論理コネクションの確立前に物理コネクションに基づく HTTP— GET取得要求を受信した場合においても、コネクション管理部 15に対して新たな論理コネクションの生成を要求して、管理可能なコネクション容量に空きがある場合には、論理コネクションに用いるコネクシヨン IDを付与することが可能となり、クライアント機器とサーバ機器間のコネクションを適切に管理することが可能となる。

[0058] 以下、本実施の形態で示した構成の変形例について説明する。

[0059] 上記実施の形態 1では、クライアント機器から明示的に CMS : : ConnectionComp elete要求コマンドを発行する事で論理コネクションを削除する構成について説明したが、論理コネクションで接続されるサーバ機器、クラアイント機器におけるサーバ機器では HTTP接続や TCP接続の切断をコンテンツデータ配信部が検知した場合には、コネクション管理部に対して当該論理コネクションの切断を要求する構成としてもよい。

[0060] また、サーバ機器にぉ、て 30分間などの基準値を設け、基準時間を超えて HTTP

— GET要求を受信しな力つた場合は、コネクション管理部に対して当該論理コネクシヨンの切断を要求する構成としてもよ、。

[0061] さらに、 HTTP— GET要求をする際に HTTPヘッダ情報に Range指定を行い、コンテンッデータの取得に複数回の HTTP— GET要求を行ってもよい。

(実施の形態 2)

[0062] 次に、本発明に係るサーバ機器の第二の実施の形態について図面を参照しながら説明を行う。尚、上記実施の形態 1では、図 10及び図 11を用いて後からネットワークに参入したクライアント機器が優先度等に基づいて既に確立されたコネクションを削除して新たなコネクションを生成する方法について説明したが、本実施の形態では、後からネットワークに参入したクライアント機器による既存のコネクション削除を禁止する方法についての説明を行う。

[0063] また、本実施の形態におけるサーバ機器及びクライアント機器の構成図は、実施の形態 1における構成図と同様であるので、説明を省略する。

[0064] この場合、図 6において、クライアント機器 200からの CMS：： PrepareForConnec tion要求コマンドに対して、サーノ機器 10が当該論理コネクションを前述した CMS：

： ConnectionComplete要求コマンドによって削除されな!、論理コネクションを生成したい場合は、コネクション IDを" 0，，として CMS : : PrepareForConnection応答コマンドをクライアント機器 200に送信する。

[0065] ここで、コネクション ID"0"はコネクション管理部 15において、論理コネクションの数のみを管理し、クライアント機器のアドレス情報などのクライアント機器情報を管理しない事を表す。

[0066] 図 3で示されるネットワーク構成において、サーバ機器 10はクライアント機器 200からの CMS : : PrepareForConnection要求コマンドに対して、コネクション IDが" 0" である CMS : : PrepareForConnection応答コマンドを返答する。その後、クライアント機器 200はコネクション ID"0"を HTTPヘッダ情報に含む HTTP— GET要求をサーバ機器 10に対して行い、コンテンツデータの取得を行う。

[0067] また、サーバ機器 10は、クライアント機器 210からの HTTP— GET要求に対して、コネクション IDが" 0"である論理コネクションとしてコネクション管理部 15によって当該論理コネクションを管理する。

[0068] 次に、クライアント機器 20はサーバ機器 10に対して CMS：： PrepareForConnect ion要求コマンドを発行する力サーバ機器 20では現在管理して、る論理コネクション数が管理可能な最大論理コネクション数 (本実施の形態の説明にお、ては 2本）に達しているため、 CMS : : PrepareForConnection応答コマンドにエラー応答を行う。次に、クライアント機器 20は CMS : : GetCurrentConnectionIDs要求コマンドを発行する。サーバ機器 10は CMS : : GetCurrentConnectionIDs応答コマンドとして" ID=0"を応答する。

[0069] クライアント機器 20はコネクション IDが" 0"である CMS：： ConnectionComplete 要求コマンドを送信するが、サーバ機器 10内のコネクション管理部 15において、当該コネクション IDで示される論理コネクションの情報は存在しな、ため、当該コネクシヨン IDで示される論理コネクションは削除されず、クライアント機器 20に対しては CM S : : ConnectionComplete応答コマンドが返送される力クライアント機器 200およびクライアント機器 210においてはコネクションは確立されたままとなる。

[0070] クライアント機器 200、およびクライアント機器 210ではコンテンツデータの取得が完了した時点で HTTPコネクションが切断される。 HTTPコネクションが切断されるとコンテンッデータ配信部 14はコネクション管理部 15に対して、論理コネクションの削除を要求する。要求を受けたコネクション管理部 15では管理する論理コネクションを削除する。

[0071] なお、ここでは HTTPコネクションの切断でコネクション ID"0"で表される論理コネクシヨンが削除される条件となる例を示した力 TCPコネクションの切断が論理コネクシヨンが切断される条件としてもょ、。

[0072] また、図 12 (a)に示すように、 CMS： : PrepareForConnection要求コマンドを送信したクラアイント機器のアドレス情報 (PFC生成先)や、 HTTP接続が確立されてヽるクラアイント機器のアドレス情報 (HTTP配信先）、またテレビや VOD (Video On Demand)など配信中のコンテンツデータの種別（サービス）、優先度などをコネクシヨン管理情報 120として記憶し、例えば、サービスが VODである論理コネクションは CMS：： ConnectionComplete要求コマンドによって削除されることのな、ような構成としてもよい。ここでは、サービスという 1つの情報に基づいて論理コネクション削除が拒否される条件について説明したが、 HTTP配信先とサービスなど 2つ以上の情報を組み合わせで条件を設定してもよヽ。

[0073] また、図 12 (a)のコネクション管理情報 120に示すように、提供されるコンテンツのサービスの種類が VODである場合には、コネクション IDが" 0"となり、論理コネクションの切断を行うことができない設定となっている。また、 2つ目のコネクションで、 PFC 生成先が記述されて、な、コネクションは、クライアント機器が最初に物理コネクションを用いてコンテンツ取得要求を行った場合におけるコネクションであり、コネクション管理情報 120の 3つ目のコネクションは、 PFC生成先と HTTP配信先とが異なるアドレスとなって!/、るが、これは論理コネクションの接続を他のクライアント機器力も行った場合の例である。

[0074] そして、コネクション管理情報 120に記載されている優先度は、他のクライアント機器からの論理コネクション切断の判断を行う場合に用いられ、例えば、優先度が 1である父親のクライアント機器からは優先度が 3である兄のコネクションを切断することができる一方、兄のクライアント機器力父親の論理コネクションを勝手に切断できなヽ設定となっている。

[0075] また、図 12 (b)は、本発明のサーバ機器に管理される優先度テーブル 121の一例を示し、サーバ機器に接続されているクライアント機器の IPアドレスと、論理コネクション確立における優先度との関係が記述されている。サーバ機器は、この優先度テーブル 121を参照することにより、例えば、図 10及び図 11に示すように、優先度の高いクライアント機器から、既に確立されてヽる優先度の低ヽクライアント機器のコネクション IDの削除を行うことが可能となる。尚、図 12ではアドレス情報として IPアドレスを用 V、る例を示した力 MACアドレス等の物理アドレスを用いてもよ!、。

[0076] 以上説明したように、本実施の形態 2に係るサーバ機器は、コネクション管理情報 1 20や優先度テーブル 121を用いて、コネクション本数に限りのあるクライアント機器との間のコネクションを適切に管理することが可能となる。

[0077] また、本実施の形態 2に係るサーノ機器では、ホームネットワークの規格において、下位互換を保ちながらも新たにコネクション管理を行うことが可能となり、これに合わせて、コネクション管理情報 120等を用いることにより、例えばテレビ放送のような映像配信にっ、ては"後取り優先"のコネクション管理を行、、ビデオオンデマンドのように個人が任意で楽しむような映像配信については"先取り優先"のコネクション管理を行うなど、サービスによって効率的なリソース管理が行える効果を発揮する。

[0078] 尚、本実施の形態 2ではコネクション ID"0"を論理コネクションに関する詳細情報を持たない予約値として、コネクション管理部において扱う構成について説明したが、予約値は" 0"以外の、かなる数値であってもよ、事は説明するまでもな!/、。

[0079] また、コネクション ID"0"が指定された場合は論理コネクションを生成せず、実際の HTTPコネクションのみを用いてコンテンツデータのやりとりを行う構成としてもよい。 [0080] さらに、配信するコンテンツの種別を判定して、例えば、録画中コンテンツの配信時にはコネクション削除を禁止し、録画済コンテンツの配信時にはコネクション削除を可會とすることち考免られる。

[0081] そして、上述の説明においてはコネクション ID消去のタイミングについては言及していないが、例えば、コンテンツの配信要求が一定期間なカゝつた場合や、配信要求先の IPアドレス力もコンテンツ配信要求先を特定して一定期間後に消去することが考え得る。

[0082] また、セキュリティの関係で登録した MACアドレス以外のクライアント機器からのコネクシヨン接続要求を受け付けない構成とすることも考え得る。

産業上の利用可能性

[0083] 本発明に係る AVサーバ機器は、例えば、 UPnP— AVの CDSに準じるファイル転送方法に基づいて宅内ネットワークを介して家電機器間でのマルチメディアコンテンッの転送を行う AVサーバ機器として適用できる。

Claims

請求の範囲

[1] ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信する AVサーバ機器であって、

通信パケットを送受信する通信手段と、

前記通信手段を用いて物理コネクションに基づ、てコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信手段と、

前記コンテンツデータを蓄積するコンテンツデータ蓄積手段と、

前記通信手段を用いて論理コネクションの管理を行うコマンドを処理するプロトコル処理手段と、

前記コンテンツデータ配信手段の前記物理コネクション、及び前記プロトコル処理手段の前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクション IDに基づいて行うコネクション管理手段とを備え、

前記通信手段が前記クライアント機器力前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合において、前記コンテンツデータ配信手段は、前記コネクション管理手段に前記コネクション IDの確認処理を行い、

前記コンテンツデータ配信手段は、前記コネクション IDの確認ができなヽ場合には、前記コネクション管理手段に対して前記コネクション IDの生成要求を行う

ことを特徴とする AVサーバ機器。

[2] 前記コネクション管理手段は、前記コネクション IDの生成要求を受けた場合には、コネクション IDを生成し、前記コンテンツデータ配信手段に応答し、

前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、

前記通信手段は、前記物理コネクションに基づ!、て前記コンテンツデータを前記クライアント機器に送信する

ことを特徴とする請求項 1記載の AVサーバ機器。

[3] 前記コンテンツデータ配信手段は、前記コネクション IDの確認ができる場合には、前記コンテンツデータ配信手段は、前記コンテンツデータ蓄積手段にコンテンツデータの取得を要求して前記コンテンツデータを取得し、前記通信手段は、前記物理コネクションに基づ!、て前記コンテンツデータを前記クライアント機器に送信する

ことを特徴とする請求項 1記載の AVサーバ機器。

[4] 前記コンテンツデータ配信手段は、前記通信手段を介して取得した前記クライアント機器のアドレス情報を前記コネクション管理手段に提供し、

前記コネクション管理手段は、前記アドレス情報を用いて前記クライアント機器とのコネクションを識別する前記コネクション IDの有無を確認する

ことを特徴とする請求項 1記載の AVサーバ機器。

[5] 前記アドレス情報は、前記クライアント機器の IPアドレス又は MACアドレスであることを特徴とする請求項 4記載の AVサーバ機器。

[6] 前記コネクション管理手段は、少なくとも前記 AVサーバ機器に接続された各クライアント機器のアドレス情報と、前記論理コネクション確立の優先度との関係が記述された優先度テーブルを管理し、

前記プロトコル処理手段は、前記クライアント機器力も前記コネクション管理手段が保持する前記コネクション HD情報を消去するためのコマンドを受信した際に、前記コネクシヨン管理手段は、前記優先度テーブルを参照して、優先度の高いクライアント機器力の削除要求である場合に前記コネクション管理手段が保持する前記コネクシヨン IDを消去する

ことを特徴とする請求項 1記載の AVサーバ機器。

[7] 前記コネクション管理手段は、少なくとも前記コネクション IDと、前記論理コネクションの生成先となるクライアント機器のアドレス情報、前記物理コネクションの接続先となるクライアント機器のアドレス情報、前記コンテンツのサービス情報、及び前記クライアント機器毎に付与されている前記論理コネクション確立の優先度の少なくとも 1つが記載されたコネクション管理情報を管理し、

前記プロトコル処理手段は、前記クライアント機器力も前記コネクション管理手段が保持するコネクション HD情報を消去するためのコマンドを受信した際に、前記コネクシヨン管理情報を参照し、予め定められたコネクション IDが付与されている場合には、前記コネクション管理手段が保持する前記コネクション IDを消去しなヽことを特徴とする請求項 1記載の AVサーバ機器。

[8] 前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクション HD情報を消去するためのコマンドを受信した際に、前記コネクシヨン管理情報を参照し、前記コネクション IDを生成したクライアント機器力をアドレス情報を用いて判別し、前記コネクション IDを生成したクライアント機器以外からの要求である場合には、前記コネクション管理手段が保持する前記コネクション IDを消去しない

ことを特徴とする請求項 7記載の AVサーバ機器。

[9] 前記プロトコル処理手段は、前記クライアント機器から前記コネクション管理手段が保持するコネクション HD情報を消去するためのコマンドを受信した際に、前記コネクシヨン管理情報を参照し、前記コネクション IDと関連付けられた前記サービスの種類に応じて前記コネクション管理手段が保持する前記コネクション IDを消去しないことを特徴とする請求項 7記載の AVサーバ機器。

[10] 前記プロトコル処理手段は、前記通信手段を介して前記クライアント機器から前記コネクション管理手段において保持するコネクション HD情報を閲覧するためのコマンドを受信した際に、前記コマンドの応答として、前記コネクション管理情報を付与して返信する

ことを特徴とする請求項 7記載の AVサーバ機器。

[11] 前記コネクション管理手段は、コンテンツデータに対する配信要求が継続して行われていない場合、又はコンテンツデータに対する配信要求が一定期間なくなった場合にぉ、て前記コネクション IDを消去する

ことを特徴とする請求項 1記載の AVサーバ機器。

[12] 前記コネクション管理手段は、配信要求がなくなった配信先の前記クライアント機器のアドレス情報に基づいて前記コネクション IDを消去する

ことを特徴とする請求項 1記載の AVサーバ機器。

[13] 前記コンテンツデータ配信手段は、コンテンツに対する配信要求が継続中に、コンテンッに対する配信要求受信時にぉ、て、前記コネクション管理手段に前記コネクシヨン IDの存在有無を確認し、前記コネクション IDが消去されて!、た場合にお!、ては、前記通信手段を介してコンテンツに対する配信要求でエラーを返した上で、前記クライアント機器とのコネクションの切断を行う

ことを特徴とする請求項 1記載の AVサーバ機器。

[14] 前記コンテンツデータ配信手段は、コンテンツに対する配信要求が継続中に、コンテンッ配信時にぉ、て、前記コネクション管理手段に前記コネクション IDの存在有無を確認し、前記コネクション IDが消去されていた場合においては、前記通信手段を介してコンテンツを配信せずに、前記クライアント機器とのコネクションの切断を行うことを特徴とする請求項 1記載の AVサーバ機器。

[15] 前記コンテンツデータ配信手段は、前記コネクション IDが消去されているかどうかを、配信要求先となるクライアント機器のアドレス情報力判別する

ことを特徴とする請求項 13又は 14記載の AVサーノ機器。

[16] ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信する AVサーバ機器に用いるコネクション管理方法であって、

通信パケットを送受信する通信ステップと、

前記通信ステップにお、て物理コネクションに基づ、てコンテンツデータを前記クライアント機器に配信するためのコンテンツデータ配信ステップと、

前記コンテンツデータを蓄積するコンテンツデータ蓄積ステップと、

前記通信ステップにおいて論理コネクションの管理を行うコマンドを処理するプロトコル処理ステップと、

前記コンテンツデータ配信ステップにおける前記物理コネクション、及び前記プロトコル処理ステップにおける前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクション IDに基づいて行うコネクション管理ステップとを含み

前記通信ステップにおいて前記クライアント機器力前記物理コネクションに基づくコンテンツデータ配信要求を受信した場合にぉヽて、前記コンテンツデータ配信ステップにお、ては、前記コネクション管理ステップにおける前記コネクション IDの確認処理を行い、

前記コンテンツデータ配信ステップにお、ては、前記コネクション IDの確認ができな、場合には、前記コネクション管理ステップにおける前記コネクション IDの生成要求を行う

ことを特徴とするコネクション管理方法。

[17] 前記コネクション管理ステップにおいては、前記コネクション IDの生成要求を受けた場合には、コネクション IDを生成し、

前記コンテンツデータ配信ステップにお、ては、前記コンテンツデータ蓄積ステツプにおけるコンテンツデータの取得を要求して前記コンテンツデータを取得し、前記通信ステップにお、ては、前記物理コネクションに基づ、て前記コンテンツデータを前記クライアント機器に送信する

ことを特徴とする請求項 16記載のコネクション管理方法。

[18] ネットワークに接続され、コンテンツを要求するクライアント機器に対してコンテンツを配信する AVサーバ機器に用いるプログラムであって、

通信パケットを送受信する通信ステップと、

前記コンテンツデータ配信ステップにおける前記物理コネクション、及び前記プロトコル処理ステップにおける前記論理コネクションに基づく前記クライアント機器との間のコネクション管理をコネクション IDに基づいて行うコネクション管理ステップとをコンピュータに実行させ、

ことを特徴とするプログラム。

前記コネクション管理ステップにお、ては、前記コネクション IDの生成要求を受けた場合には、コネクション IDを生成し、

ことを特徴とする請求項 18記載のプログラム。