説明

通信システム、通信装置並びに通信方法

【課題】ライブ・コンテンツに関する十分なメタ情報を各機器に好適に提供する。
【解決手段】コンテンツ・ブラウジング時にアクセスされる標準CDSとは別に、配信中のコンテンツのコンテンツ詳細情報を載せるための配信中コンテンツ情報用拡張CDSを定義する。配信中コンテンツ情報用拡張CDSでは、配信先のクライアント毎のコンテナーを設け、各配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを配置する。配信中コンテンツ情報用拡張CDSに関するルールをクライアントとの間で共有することで、クライアントは、自身が再生しているコンテンツの配信中コンテンツ情報用拡張CDS情報を特定できる。

【発明の詳細な説明】
【技術分野】
【0001】
本明細書で開示される技術は、DLNA規格に則ってコンテンツ配信サービスを行なう通信システム、通信装置並びに通信方法に係り、特に、CDS機能によりコンテンツのメタ情報を提供する通信システム、通信装置並びに通信方法に関する。
【背景技術】
【0002】
最近、AVコンテンツのほとんどがディジタル化されており、CDやDVDなどのディジタル・コンテンツを記録再生するメディアが広く利用されている。さらには、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んとなり、CDやDVDなどのメディアの移動なしに、ネットワークを経由して遠隔端末間でコンテンツ配信が行なわれている。また、機器を接続しただけでネットワークへの参加を可能にするUPnP(Universal Plug and Play)をペーストしてディジタル化されたAVコンテンツを家庭内でIP(Internet Protocol)ネットワーク経由で流通させるDLNA(DigitalLiving Network Alliance)が規格化されている。これに伴い、AV機器を中心としたCE(Consumer Electronics)機器、PC(Personal Computer)及びその周辺機器(例えばNAS(Network Attached Storage)など)で、DLNA規格、あるいはUPnP規格に準拠した機能を持つ製品が増えてきている。
【0003】
数年前に策定されたDLNA Guideline 1.0(及び1.5)では、コンテンツを提供するサーバーに相当するDMS(Digital Media Server)と、再生するクライアントに相当するDMP(Digital Media Player)からなる2−Box Pull形式(System Usage)の接続条件について定義された。同ガイドラインのリリースに伴い、DMS及びDMS機能を装備した製品が主に普及した。また近年策定されたDLNA Guideline 1.5では、クライアントがDMR(Digital Media Renderer)及びDMC(Digital Media Controller)からなる3−Box System Usageが定義され、DMCを操作して、DMSからコンテンツをDMRに送信して再生させることができる。同ガイドラインのリリースに伴い、DMR及びDMC機能を装備した製品が登場した。
【0004】
2−Box Pull及び3−Box System Usageのいずれにおいても、DMSは自身のストレージに保存されているコンテンツを配信する場合がほとんどである。DLNAのベースとなるUPnPでは、DMSが提供するコンテンツのリストとコンテンツの詳細情報を階層化して配信するCDS(Content Directory Service)機能が策定されている。DLNAでCDSを実装する場合、上記のように配信コンテンツがDMS内に保存されていれば、保存されているコンテンツからあらかじめCDSを構築することが可能である。そもそもCDSの規格は、DMSが配信コンテンツを自身のストレージに保存していること、つまり静的な情報を扱うことを前提として策定されている。
【0005】
一方、ブロードバンドの普及に伴い、インターネット・サービスの分野において、音楽や動画コンテンツをストリーミング配信するサービスが増えてきている。今後は、インターネット・コンテンツや、欧米を中心に広がっているDigital Audio Broadcast(DAB)、従来からあるアナログあるいはディジタルのラジオ放送コンテンツを受信して、家庭内の機器(DMP、DMC、DMR)に配信する、DMS機能の需要が高まると考えられる。言い換えれば、各々の機器(DMP、DMC、DMR)がそういったサービスや放送コンテンツを直接受信するのではなく、DMS機能を持つ1つの機器がプロキシー・サーバーのような役割で受信して、他のクライアント機器に配信するのである。このような利用形態によれば、DMP、DMC、DMRなどのクライアント機器側では、上記のようなサービスを直接受けるための認証シーケンスを実装したソフトウェア・モジュールや、放送を受信するチューナーなどのハードウェアを必要としないというメリットがある。
【0006】
ところが、DMS機能を持つ機器がリアルタイムで受信するコンテンツ(以下では「ライブ・コンテンツ」とする)をクライアント機器に配信する場合、そのコンテンツに付随する情報は、実際にサービス・放送コンテンツを受信しないと得られないことが多い。これに対し、標準的なCDSは、前述のように、あらかじめ取得可能で静的な情報を扱うことを想定しているため、ライブ・コンテンツについてのより詳細な情報を公開できないという問題がある。この場合、サービスや放送コンテンツを直接受信する場合と比べて、クライアント機器側で表示できるメタ情報が少なくなってしまうなどのユーザビリティーの低下を招いてしまう。
【0007】
例えば、コンテンツ・サーバーから受信したコンテンツを第2デバイスに提供する第1デバイスが、UPnP AV構造のCDSのコンテンツ・リストを更新するコンテンツ提供方法について提案されているが(例えば、特許文献1を参照のこと)、コンテンツの詳細情報については更新されないので、ユーザビリティーの低下から免れることはできない。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2008−21293号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
本明細書で開示する技術の目的は、DLNA規格に則ってコンテンツ配信サービスを好適に行なうことができる、優れた通信システム、通信装置並びに通信方法を提供することにある。
【0010】
本明細書で開示する技術のさらなる目的は、DMSから各機器へ、CDS機能によりコンテンツのメタ情報を好適に提供することができる、優れた通信システム、通信装置並びに通信方法を提供することにある。
【0011】
本明細書で開示する技術のさらなる目的は、DMSがリアルタイムで受信して各機器へ配信するライブ・コンテンツに関する十分なメタ情報を好適に提供することができる、優れた通信システム、通信装置並びに通信方法を提供することにある。
【課題を解決するための手段】
【0012】
本明細書は、上記課題を参酌してなされた技術を開示するものであり、請求項1に記載の技術は、
DLNA規格に則って動作してコンテンツを配信するサーバーと、DLNA規格に則って動作してコンテンツの配信を要求するクライアントからなり、
前記サーバーは、前記クライアントを特定する情報に基づくObjectIDを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを配置した配信中コンテンツ情報用拡張CDSを作成し、前記クライアントに配信するために取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納する、
通信システムである。
【0013】
但し、ここで言う「システム」とは、複数の装置(又は特定の機能を実現する機能モジュール)が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【0014】
また、本願の請求項2に記載の技術は、
外部の機器と通信する通信部と、
クライアントから要求されたコンテンツを取得するコンテンツ取得部と、
クライアントにコンテンツを配信するコンテンツ提供部と、
コンテンツに関するCDS情報を生成するCDS情報生成部と、
クライアントからの要求によりCDS情報を送信するCDS情報提供部と、
を具備し、
前記CDS情報生成部は、クライアントからコンテンツの提供を要求されたことに応答して、配信中コンテンツ情報用拡張CDSのルートの直下に、当該クライアントを特定する情報に基づくObjectIDを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを作成し、前記コンテンツ取得部が取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納し、
前記CDS情報提供部は、前記コンテンツ提供部がコンテンツを配信中のクライアントからのCDS情報の要求に応答して、該当する配信中コンテンツ・ノードに格納されているコンテンツ詳細情報を含むCDS情報を送信する、
DLNA規格に則ってサーバーとして動作する通信装置である。
【0015】
本願の請求項3に記載の技術によれば、請求項2に記載の通信装置において、配信中コンテンツ・ノードは、コンテンツのURLと一致するres情報を持つ。
【0016】
本願の請求項4に記載の技術によれば、請求項2に記載の通信装置は、コンテンツ提供部がクライアントへのコンテンツの配信を終了したときに、前記配信コンテンツ情報用拡張CDSから該当する各ノードを削除するように構成されている。
【0017】
本願の請求項5に記載の技術によれば、請求項2に記載の通信装置のコンテンツ取得部は、前記通信部を介して外部ネットワーク上のプロバイダーからライブ・コンテンツを取得し、CDS情報生成部は、クライアントからライブ・コンテンツが要求されたときに、前記配信中コンテンツ情報用拡張CDSに、前記配信先コンテナー・ノード及び前記配信中コンテンツ・ノードを作成するように構成されている。
【0018】
本願の請求項6に記載の技術によれば、請求項2に記載の通信装置は、クライアントに提供するコンテンツを蓄積するコンテンツ蓄積部をさらに備えている。そして、CDS情報生成部は、クライアントから前記コンテンツ蓄積部に蓄積されているコンテンツが要求されたときに、前記配信中コンテンツ情報用拡張CDSに、前記配信先コンテナー・ノード及び前記配信中コンテンツ・ノードを作成するように構成されている。
【0019】
また、本願の請求項7に記載の技術は、
DLNA規格に則った機器と通信する通信部と、
DLNA規格に則ったサーバーに対してCDS情報の閲覧を要求するCDS情報閲覧部と、
を少なくとも備え、
前記CDS情報閲覧部は、自身を特定する情報に基づくObjectIDを生成し、前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求する、
DLNA規格に則ってクライアントとして動作する通信装置。
である。
【0020】
本願の請求項8に記載の技術によれば、請求項7に記載の通信装置は、DLNA規格で定義されるDMPであり、前記サーバーにコンテンツを要求して取得するコンテンツ取得部と、コンテンツを復号するコンテンツ復号部と、復号したコンテンツを再生出力するコンテンツ再生出力部をさらに備えている。そして、CDS情報閲覧部は、前記コンテンツ取得部が前記サーバーに対してプロバイダーが提供するライブ・コンテンツを要求するときに、自身を特定する情報に基づくObjectIDを生成し、前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求するように構成されている。
【0021】
本願の請求項9に記載の技術によれば、請求項7に記載の通信装置は、DLNA規格で定義されるDMCであり、レンダラーに対してコンテンツの再生出力を要求するコンテンツ再生要求部をさらに備えている。そして、CDS情報閲覧部は、前記コンテンツ再生要求部が前記レンダラーに対してプロバイダーが提供するライブ・コンテンツの再生を要求するときに、自身を特定する情報に基づくObjectIDを生成し、前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求するように構成されている。
【0022】
また、本願の請求項10に記載の技術は、
クライアントからコンテンツの提供を要求されたことに応答して、配信中コンテンツ情報用拡張CDSのルートの直下に、当該クライアントを特定する情報に基づくObjectIDを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを作成するステップと、
クライアントから要求されたコンテンツを取得するステップと、
取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納するステップと、
取得したコンテンツをクライアントに配信するステップと、
コンテンツを配信中のクライアントからのCDS情報の要求に応答して、該当する配信中コンテンツ・ノードに格納されているコンテンツ詳細情報を含むCDS情報を送信するステップと、
を有し、DLNA規格に則ってサーバーとして動作する通信方法である。
【0023】
また、本願の請求項11に記載の技術は、
通信装置自身を特定する情報に基づくObjectIDを生成するステップと、
前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求するステップと、
を有し、DLNA規格に則ってクライアントとして動作する通信方法である。
【発明の効果】
【0024】
本明細書で開示される技術によれば、DMSがリアルタイムで受信して各機器へ配信するライブ・コンテンツに関する十分なメタ情報を好適に提供することができる、優れた通信システム、通信装置並びに通信方法を提供することができる。
【0025】
本明細書で開示される技術によれば、DMSなどの1つの機器がプロキシー・サーバーのような役割で各々の機器(DMP、DMC、DMR)に配信するライブ・コンテンツについてのより詳細な情報を公開することができ、ユーザビリティーを向上することができる。
【0026】
本明細書で開示される技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【0027】
【図1】図1は、DLNA Guideline 1.0で定義された2−Box Pull形式(System Usage)に基づく通信システムの構成例を示した図である。
【図2】図2は、DLNA Guideline 1.5で定義された3−Box System Usageに基づく通信システムの構成例を示した図である。
【図3】図3は、DMSとして動作する機器の機能ブロック図である。
【図4】図4は、DMPとして動作する機器の機能ブロック図である。
【図5】図5は、DMCとして動作する機器の機能ブロック図である。
【図6】図6は、DMRとして動作する機器の機能ブロック図である。
【図7】図7は、2−Box Pull System Usageにおいて、DMSが自身のストレージに保存されたコンテンツをDMPに配信する場合の、DMPがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示した図である。
【図8】図8は、2−Box Pull System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツをDMPに配信する場合の、DMPがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示した図である。
【図9A】図9Aは、3−Box System Usageにおいて、DMSが自身のストレージに保存されたコンテンツを配信する場合の、DMCにおいてコンテンツ・ブラウジングを行なうための通信シーケンス例を示した図である。
【図9B】図9Bは、3−Box System Usageにおいて、DMSが自身のストレージに保存されたコンテンツを配信する場合の、DMRにおいてコンテンツ再生を行なうための通信シーケンス例を示した図である。
【図10A】図10Aは、3−Box System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツを配信する場合の、DMCにおいてコンテンツ・ブラウジングを行なうための通信シーケンス例を示した図である。
【図10B】図10Bは、3−Box System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツを配信する場合の、DMRにおいてコンテンツ再生を行なうための通信シーケンス例を示した図である。
【図11】図11は、コンテンツ・ブラウジング時にアクセスされるCDSツリーとは別に、配信中のコンテンツのコンテンツ詳細情報を載せるためのCDSツリーを備えたCDS構成例を示した図である。
【図12A】図12Aは、2−Box Pull System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツをDMPに配信する場合の、DMPがコンテンツ再生を行なう通信シーケンス例を示した図である。
【図12B】図12Bは、2−Box Pull System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツをDMPに配信する場合の、DMPがコンテンツ再生を行なう通信シーケンス例を示した図である。
【図13A】図13Aは、3−Box System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツを配信する場合の、DMRにおいてコンテンツ再生を行なう通信シーケンス例を示した図である。
【図13B】図13Bは、3−Box System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツを配信する場合の、DMRにおいてコンテンツ再生を行なう通信シーケンス例を示した図である。
【発明を実施するための形態】
【0028】
以下、図面を参照しながら本明細書で開示される技術に係る実施形態について詳細に説明する。
【0029】
図1には、DLNA Guideline 1.0で定義された2−Box Pull形式(System Usage)に基づく通信システムの構成例を示している。家庭内に敷設されたIPネットワーク上には、家庭内IPネットワークを介してコンテンツを提供するDMSと、家庭内IPネットワーク経由で受信したコンテンツを再生するDMPが、所定の接続条件に従って接続されている。DMSは、自身のストレージに保存している静的なコンテンツを提供する。また、DMSは、インターネットなどの外部ネットワークにも接続しており、外部ネットワーク上のプロバイダーから取得したライブ・コンテンツを提供することもできる。但し、ここで言う「プロバイダー」とは、サービスやコンテンツの提供者のことを指す。
【0030】
図示の通信システムでは、UPnPで策定されているCDS機能が実装されているが、その詳細については後述に譲る。なお、図面の簡素化のため、図1中ではDMS並びにDMPをそれぞれ1台ずつしか描いていないが、2台以上のDMS、DMPが家庭内IPネットワークに接続されることもある。
【0031】
また、図2には、DLNA Guideline 1.5で定義された3−Box System Usageに基づく通信システムの構成例を示している。家庭内に敷設されたIPネットワーク上には、家庭内IPネットワークを介してコンテンツを提供するDMSと、IPネットワーク経由で受信したコンテンツを再生するDMRと、DMRを操作するDMCが、所定の接続条件に従って接続されている。DMSは、自身のストレージに保存している静的なコンテンツを提供する。また、DMSは、インターネットなどの外部ネットワークにも接続しており、外部ネットワーク上のプロバイダー(コンテンツ・サーバー)から取得したライブ・コンテンツを提供することもできる。図示の通信システムでは、UPnPで策定されているCDS機能が実装されているが、その詳細については後述に譲る。なお、図面の簡素化のため、図2中ではDMS、DMC、DMRをそれぞれ1台ずつしか描いていないが、2台以上のDMS、DMC、DMRが家庭内IPネットワークに接続されることもある。
【0032】
図3には、図1並びに図2中のDMSとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。
【0033】
通信制御部301は、家庭内IPネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。
【0034】
コンテンツ蓄積部302は、DMS自身がDMP若しくはDMRに提供するコンテンツを蓄積する。また、コンテンツ蓄積部302は、蓄積している各コンテンツに関する詳細な情報を記述したコンテンツ情報をあらかじめ保存する内部データベースを備えている。
【0035】
コンテンツ取得部303は、DMP若しくはDMRから要求されたライブ・コンテンツを、外部ネットワーク経由でプロバイダーから取得する。
【0036】
コンテンツ提供部304は、コンテンツ蓄積部302に蓄積されている静的なコンテンツ、並びに、プロバイダーから取得した取得したライブ・コンテンツを、要求元のDMP若しくはDMRに提供する。
【0037】
CDS情報生成部305は、コンテンツ蓄積部302に蓄積されている静的なコンテンツ、並びに、プロバイダーから取得した取得したライブ・コンテンツについてのCDS情報を生成する。生成されたCDS情報は、CDS情報格納部306に格納される。
【0038】
コンテンツ蓄積部302に蓄積されている静的なコンテンツについては、その内部データベース(前述)にアクセスして、コンテンツに関する取得可能なすべての情報を取得することができるので、CDS情報生成部305は十分なCDS情報を生成することができる。これに対し、ライブ・コンテンツについては、プロバイダーによって異なるが、大抵の場合はコンテンツのタイトルなどの限られた情報しか取得できず、実際にコンテンツ・データ自体を取得してからでないとアーティスト情報などのより詳細な情報を得ることができない。このため、CDS情報生成部305は、取得前のライブ・コンテンツに関しては、限られた情報からなるCDS情報を生成することになる。なお、CDS情報格納部306に格納するCDS情報のデータ構造の詳細については、後述に譲る。
【0039】
CDS情報提供部307は、DMP若しくはDMCからのCDS情報の取得要求に応答して、CDS情報格納部306に格納されているCDS情報を提供する。
【0040】
図4には、図1中のDMPとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。
【0041】
通信制御部401は、家庭内IPネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。
【0042】
CDS情報閲覧部402は、DMSに対してCDS情報の取得要求を行ない、取得したCDS情報の閲覧画面を表示する。例えば、CDS情報として、DMSが提供可能な(若しくはDMSを通じて取得可能な)コンテンツのリストを取得したときには、コンテンツ一覧画面が表示され、ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。
【0043】
コンテンツ取得部403は、ユーザーが選択したコンテンツの取得要求をDMSに送信して、コンテンツの取得を行なう。そして、コンテンツ復号部404は取得したコンテンツを復号し、コンテンツ再生出力部405は復号したコンテンツを再生出力する。
【0044】
図5には、図2中のDMCとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。
【0045】
通信制御部501は、家庭内IPネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。
【0046】
CDS情報閲覧部502は、DMSに対してCDS情報の取得要求を行ない、取得したCDS情報の閲覧画面を表示する。例えば、CDS情報として、DMSが提供可能な(若しくはDMSを通じて取得可能な)コンテンツのリストを取得したときには、コンテンツ一覧画面が表示され、ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。
【0047】
コンテンツ再生要求部503は、ユーザーが選択したコンテンツの再生出力を、DMRに対して要求する。
【0048】
図6には、図2中のDMRとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。
【0049】
通信制御部601は、家庭内IPネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。
【0050】
コンテンツ取得部602は、DMCから再生要求されたコンテンツの取得要求をDMSに送信して、コンテンツの取得を行なう。そして、コンテンツ復号部603は取得したコンテンツを復号し、コンテンツ再生出力部604は復号したコンテンツを再生出力する。
【0051】
図7には、図1に示した2−Box Pull System Usageにおいて、DMSが自身のストレージ(コンテンツ蓄積部302)に保存されたコンテンツをDMPに配信する場合の、DMPがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示している。
【0052】
コンテンツ・ブラウジングにおいては、DMPのCDS情報閲覧部402からDMSに対して、CDS:Browseアクションが発行される。
【0053】
DMS側では、自身のストレージであるコンテンツ蓄積部302に保存されているコンテンツに対してCDS:Browseアクションが発行されたので、CDS情報生成部305は、該当するコンテンツに関する取得可能なすべてのコンテンツ情報をコンテンツ蓄積部302の内部データベースから取得して、十分な情報量のCDS情報を生成して、CDS情報格納部306に格納する。また、CDS情報提供部307は、生成されたCDS情報を、DMPに対してCDS Resultとして返す。
【0054】
DMP側では、CDS情報閲覧部402が、受信したCDS Resultを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する。DMPのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。
【0055】
再生時には、DMPのコンテンツ取得部403から例えばHTTP Getメソッドを用いてコンテンツが要求される。DMS側では、コンテンツ提供部304がHTTP Get要求を受けとると、自身のストレージであるコンテンツ蓄積部302に保存されているコンテンツ・データを、一定容量毎にDMPに返す(配信する)。そして、DMP側では、コンテンツ復号部404が受け取ったデータをデコードし、コンテンツ再生出力部405が再生する。コンテンツ・データのエンドに到達するまで、DMSからのコンテンツ・データの配信とDMP側でのコンテンツのデコード及び再生が繰り返される。
【0056】
一方、図8には、図1に示した2−Box Pull System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツをDMPに配信する場合の、DMPがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示している。
【0057】
コンテンツ・ブラウジングにおいては、DMPのCDS情報閲覧部402からDMSに対して、ライブ・コンテンツに関するCDS:Browseアクションが発行される。
【0058】
DMS側では、ライブ・コンテンツ、すなわち自身のストレージであるコンテンツ蓄積部302に保存されていないコンテンツに対してCDS:Browseアクションが発行されたので、CDS情報生成部305は、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得して、CDS情報を生成し、CDS情報格納部306に格納する。プロバイダーによって異なるが、大抵の場合はコンテンツのタイトルなどの限られた情報しか取得できない。このため、CDS情報生成部305は、限られた情報からなるCDS情報しか生成することができない。そして、CDS情報提供部307は、生成されたCDS情報を、DMPに対してCDS Resultとして返す。
【0059】
DMP側では、CDS情報閲覧部402が、受信したCDS Resultを解析して、コンテンツのタイトルなどの限られた情報からなるコンテンツ情報を表示する。DMPのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。
【0060】
再生時には、DMPのコンテンツ取得部403から例えばHTTP Getメソッドを用いてコンテンツが要求される。DMS側では、ライブ・コンテンツに対するHTTP Get要求を受けとると、コンテンツ取得部303がプロバイダーにアクセスして、コンテンツ・データを取得する。そして、コンテンツ提供部304は、プロバイダーから取得したライブ・コンテンツのデータを、一定容量毎にDMPに返す(配信する)。DMP側では、コンテンツ復号部404が受け取ったデータをデコードし、コンテンツ再生出力部405が再生する。コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びDMSからDMSへのコンテンツ・データの配信とDMP側でのコンテンツのデコード及び再生が繰り返される。
【0061】
DMSは、実際にコンテンツ・データ自体を取得すれば、ライブ・コンテンツに関してアーティスト情報などのより詳細な情報(以下、「コンテンツ詳細情報」とする)を得ることができるようになる。しかしながら、現在のDLNAの標準規格では、DMSが配信しているコンテンツの情報をDMPが取得する仕組みがないので、DMP側ではライブ・コンテンツに関するコンテンツ詳細情報を得ることができず、結局のところ、DMPのユーザーは、コンテンツ・ブラウジング時において限られた情報からなるCDS情報しか取得することができない。
【0062】
また、図9A及び図9Bには、3−Box System Usageにおいて、DMSが自身のストレージに保存されたコンテンツを配信する場合の、DMCにおいてコンテンツ・ブラウジングしDMRにおいてコンテンツ再生を行なうための通信シーケンス例を示している。
【0063】
コンテンツ・ブラウジングにおいては、図9Aに示すように、DMCのCDS情報閲覧部502からDMSに対して、CDS:Browseアクションが発行される。
【0064】
DMS側では、自身のストレージであるコンテンツ蓄積部302に保存されているコンテンツに対してCDS:Browseアクションが発行されたので、CDS情報生成部305は、該当するコンテンツに関する取得可能なすべてのコンテンツ情報をコンテンツ蓄積部302の内部データベースから取得して、十分な情報量のCDS情報を生成して、CDS情報格納部306に格納する。また、CDS情報提供部307は、生成されたCDS情報を、DMPに対してCDS Resultとして返す。
【0065】
DMC側では、CDS情報閲覧部502が、受信したCDS Resultを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する。DMPのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。
【0066】
再生時には、図9Bに示すように、DMCのコンテンツ再生要求部503が、DMRに対してAVT:SetAVTransportURI()アクションを発行して、選択したコンテンツの属性情報を通知する。コンテンツの属性情報には、コンテンツのタイトル、コンテンツのサイズ、コンテンツの長さ、コンテンツにアクセスするためのURL(Uniform Resource Locator)などが含まれる。コンテンツ再生要求部503は、DMRに対してさらにAVT:Play()アクションを発行して、コンテンツの再生開始を要求する。
【0067】
DMRは、コンテンツの再生開始要求に応答して、コンテンツ取得部602が、HTTP Getメソッドを用いてコンテンツを要求する。DMS側では、コンテンツ提供部304がHTTP Get要求を受けとると、自身のストレージであるコンテンツ蓄積部302に保存されているコンテンツ・データを、一定容量毎にDMPに返す(配信する)。そして、DMR側では、コンテンツ復号部603が受け取ったデータをデコードし、コンテンツ再生出力部604が再生する。コンテンツ・データのエンドに到達するまで、DMSからのコンテンツ・データの配信とDMR側でのコンテンツのデコード及び再生が繰り返される。
【0068】
一方、図10A及び図10Bには、3−Box System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツを配信する場合の、DMCにおいてコンテンツ・ブラウジングしDMRにおいてコンテンツ再生を行なうための通信シーケンス例を示している。
【0069】
コンテンツ・ブラウジングにおいては、図10Aに示すように、DMCのCDS情報閲覧部502からDMSに対して、CDS:Browseアクションが発行される。
【0070】
DMS側では、ライブ・コンテンツ、すなわち自身のストレージであるコンテンツ蓄積部302に保存されていないコンテンツに対してCDS:Browseアクションが発行されたので、CDS情報生成部305は、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得して、CDS情報を生成し、CDS情報格納部306に格納する。プロバイダーによって異なるが、大抵の場合はコンテンツのタイトルなどの限られた情報しか取得できない。このため、CDS情報生成部305は、限られた情報からなるCDS情報しか生成することができない。そして、CDS情報提供部307は、生成されたCDS情報を、DMCに対してCDS Resultとして返す。
【0071】
DMC側では、CDS情報閲覧部502が、受信したCDS Resultを解析して、コンテンツのタイトルなどの限られた情報からなるコンテンツ情報を表示する。DMCのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。
【0072】
再生時には、図10Bに示すように、DMCのコンテンツ再生要求部503が、DMRに対してAVT:SetAVTransportURI()アクションを発行して、選択したコンテンツの属性情報を通知する。コンテンツの属性情報には、コンテンツのタイトル、コンテンツのサイズ、コンテンツの長さ、コンテンツにアクセスするためのURL(Uniform Resource Locator)などが含まれる。コンテンツ再生要求部503は、DMRに対してさらにAVT:Play()アクションを発行して、コンテンツの再生開始を要求する。
【0073】
DMRは、コンテンツの再生開始要求に応答して、コンテンツ取得部602が、HTTP Getメソッドを用いてコンテンツを要求する。DMS側では、HTTP Get要求を受けとると、コンテンツ取得部303がプロバイダーからライブ・コンテンツのコンテンツ・データを一定量毎に取得し、コンテンツ提供部がこれをDMRに返す(配信する)。そして、DMR側では、コンテンツ復号部603が受け取ったデータをデコードし、コンテンツ再生出力部604が再生する。コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びDMSからDMSへのコンテンツ・データの配信とDMP側でのコンテンツのデコード及び再生が繰り返される。
【0074】
DMSは、実際にコンテンツ・データ自体を取得すれば、ライブ・コンテンツに関するコンテンツ詳細情報を得ることができるようになる。しかしながら、現在のDLNAの標準規格では、DMSが配信しているコンテンツの情報をDMCが取得する仕組みがないので、DMC側ではライブ・コンテンツに関するコンテンツ詳細情報を得ることができず、結局のところ、DMCのユーザーは、コンテンツ・ブラウジング時において限られた情報からなるCDS情報しか取得することができない。
【0075】
図8並びに図10についてまとめると、CDSの規格はDMSが配信コンテンツを自身のストレージに保存していることを前提として策定され、ライブ・コンテンツに関するコンテンツ詳細情報をカバーするものではなく、また、現在のDLNAの標準規格ではDMSが配信しているコンテンツの情報をDMP、DMCが取得する仕組みがない。このため、DMP、DMCのユーザーはライブ・コンテンツに関しては限られた情報からなるCDS情報しか取得することができない。
【0076】
そこで、本明細書では、DMP、DMCのユーザーがライブ・コンテンツに関してもコンテンツ詳細情報を取得できるようにするための、DMSのCDS構成について提案する。本提案に係るCDS情報は、図11に示すように、コンテンツ・ブラウジング時にアクセスされるCDSツリーとは別に、配信中のコンテンツのコンテンツ詳細情報を載せるためのCDSツリーを備えている。前者のCDSツリーは、現在のDLNAでも実装されている通常のCDSツリーであり、以下では「標準CDS」と呼ぶことにする。また、後者の配信中のコンテンツのコンテンツ詳細情報を記載するためのCDSツリーを、以下では「配信中コンテンツ情報用拡張CDS」と呼ぶことにする。
【0077】
標準CDSは、ObjectIDが0(固定)のルートの直下に各コンテナーが配置される形で構成される。これに対し、配信中コンテンツ情報用拡張CDSについては、独自のObjectIDを規定し(図示の例では、“STREAMING_0”)、それを持った配信中コンテンツ用のルート(以降、「StreamingRootと」呼ぶことにする)を設け、それを大元にしたツリーを構成する。
【0078】
このように、標準CDSとは独立した形で配信中コンテンツ情報用拡張CDSを構成することにより、基本的に静的な情報しか載せることのない標準CDSと、配信する度に動的に変化する配信中コンテンツ情報用拡張CDSを分離し、コンテンツ・ブラウジング時に配信中コンテンツ情報用拡張CDSにアクセスされないようにする。
【0079】
ここで、コンテンツの最小単位、例えば、1つの音楽データ(曲)、1つの動画データ、1つの静止画データなどは、アイテム(item)と呼ばれる。ライブ・コンテンツの場合には、1つのチャンネルが1アイテムとして扱われる。また、上記のアイテムの集合として規定されるアイテムの上位オブジェクトは、コンテナー(container)と呼ばれる。集合の単位は、例えば、各オブジェクトの物理的な記憶位置に基づく集合、各オブジェクトの論理的関係に基づく集合、カテゴリーに基づく集合など、さまざまに設定され得る。
【0080】
図11に示す例では、標準CDSの集合の単位はメディアのカテゴリーである。標準CDSのルートの直下には、メディア種別毎のコンテナー・ノードVideo、Music、Pictureが設けられる。各コンテナー・ノードは、メディアの種別を特定できるObjectID、“VIDEO_CONTAINER”、“MUSIC_CONTAINER”、“PICTURE_CONTAINER”を持つ。また、各コンテナー・ノードVideo、Music、Pictureの配下にはそれぞれ、動画、音楽、静止画のコンテンツ・ノード(アイテム)が配置されている。各コンテンツ・ノードは、HTTP Getメソッドで指定されるURLに該当するres情報を持つ。
【0081】
一方、配信中コンテンツ情報用拡張CDSの集合の単位は配信先のクライアントであり、配信先のクライアント毎のコンテナー(以下では、「配信先コンテナー・ノード」と呼ぶ)が設けられている。そして、各配信先コンテナー・ノードの配下には、アイテムとして、コンテンツ詳細情報を格納用の配信中コンテンツ・ノードを配置している。こうすることにより、同時に複数のコンテンツを(複数のクライアントに)配信可能なDMSにも対応することができる。なお、配信中コンテンツ情報用拡張CDSの各ノードは、配信が開始されると生成され、配信が終了すると破棄される動的なものとする。
【0082】
配信先コンテナー・ノードは、IPアドレスあるいはMACアドレス(図11に示す例では、IPアドレス)により特定できるようにし、その配下の配信中コンテンツ・ノードは、標準CDS側のコンテンツ・ノードと紐付けられるようにする。本提案では、配信先コンテナー・ノードのObjectIDとして、接頭辞“STREAMING”の後ろに、配信先クライアントのIPアドレスを付加する。また、配信中コンテンツ・ノードについては、クライアントから再生時にHTTP Getメソッドで指定されるURLに該当するres情報により、標準CDSの同コンテンツと紐付けることができる。
【0083】
上述したような配信中コンテンツ情報用拡張CDSのルール(規定)をサーバー(DMS)とクライアント(DMP、DMC)の間で共有することで、クライアントは、自身が再生しているコンテンツの配信中コンテンツ情報用拡張CDS情報を特定することができる。具体的には、クライアントは、まず、自身のIPアドレスから対象の配信先コンテナー・ノードのObjectIDを生成し、そのObjectIDを引数として配信先コンテナー・ノードに対するCDS:Browseアクションを行ない、サーバーから返却されたCDS Resultから、自身が再生しているコンテンツのURLと一致するres情報を持つ配信中コンテンツ・ノードを特定する。
【0084】
DMSは、プロバイダーからライブ・コンテンツのコンテンツ・データを取得すると、コンテンツ詳細情報を抽出することができ、配信中コンテンツ情報用拡張CDSに書き込むようにすることができる。一方、DMP、DMCなどのクライアントは、上記のように、自身が再生しているコンテンツの配信中コンテンツ情報用拡張CDS情報にアクセスすれば、コンテンツ・ブラウジング時には取得できなかったコンテンツ詳細情報を取得することができる。
【0085】
図12A及び図12Bには、図1に示した2−Box Pull System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツをDMPに配信する場合の、DMPがコンテンツ再生を行なう通信シーケンス例を示している。コンテンツ再生時において、DMSがライブ・コンテンツについてのコンテンツ詳細情報を配信中コンテンツ情報用拡張CDSに格納して、DMPに公開するという点で、図8に示した通信シーケンス例とは相違する。
【0086】
DMPがコンテンツ・ブラウジングを行なうための通信シーケンスは、図8と同様なので、図12では図示を省略する。すなわち、コンテンツ・ブラウジングにおいては、DMPのCDS情報閲覧部402からDMSに対して、ライブ・コンテンツに関するCDS:Browseアクションが発行される。これに対し、DMS側では、CDS情報生成部305が、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得してCDS情報を生成し、CDS情報提供部307がこれをCDS Resultとして返す。
【0087】
再生時には、DMPのコンテンツ取得部403から例えばHTTP Getメソッドを用いてコンテンツが要求される。DMS側では、ライブ・コンテンツに対するHTTP Get要求を受けとると、まず、CDS情報生成部305は、配信中コンテンツ情報用拡張CDSをCDS情報格納部306内に生成する。そして、HTTP Get要求元のIPアドレスから、配信先コンテナー・ノードを作成し、配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを生成する。但し、既に同一のクライアントに配信中で、作成済みであれば、配信先コンテンツを作成する必要はない。
【0088】
続いて、コンテンツ取得部303がプロバイダーにアクセスして、コンテンツ・データを取得する。CDS情報生成部305は、取得したコンテンツ・データからコンテンツ詳細情報を抽出すると、配信中コンテンツ・ノードにこのコンテンツ詳細情報を保存し公開する。なお、コンテンツ詳細情報は、プロバイダーによって、別の専用のコマンドを発行することによって取得できる場合もあれば、コンテンツ・データに含まれている場合などがあり、後者の場合は、コンテンツ・データをデコードする際に抽出する必要がある。
【0089】
そして、コンテンツ取得部303はプロバイダーからライブ・コンテンツのコンテンツ・データを一定量毎に取得し、コンテンツ提供部304はこれをDMPに返す(配信する)。DMP側では、コンテンツ復号部404が受け取ったデータをデコードし、コンテンツ再生出力部405が再生する。
【0090】
ここで、DMPは、HTTP Get要求を出し、DMSからライブ・コンテンツの配信が開始された段階で、配信中コンテンツ情報用拡張CDSに対するCDS:Browseアクションを発行することにより、DMSが配信中で自身が再生しているライブ・コンテンツのコンテンツ詳細情報を取得し、表示に用いたりすることが可能である。DMPは、CDS:Browseアクションを発行する際、対象とする配信先コンテナー・ノードのObjectIDを自身のIPアドレスから生成する(前述)。DMS側では、CDS情報提供部307は、CDS:Browseアクションを受け取ると、そのObjectIDを基に、配信中コンテンツ情報用拡張CDSから該当する配信中コンテナー・ノードを特定して、そこに格納されているコンテンツ詳細情報を、DMPに対してCDS Resultとして返す。
【0091】
コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びDMSからDMSへのコンテンツ・データの配信とDMP側でのコンテンツのデコード及び再生が繰り返される。そして、ライブ・コンテンツの配信が終了すると、DMS側では、配信中コンテンツ情報用拡張CDSのうち、該当する配信先コンテナー・ノード並びに配信中コンテンツ・ノードを、CDS情報格納部306から破棄する。
【0092】
このように、CDS情報を拡張することにより、サービスや放送コンテンツを実際に受信しないとコンテンツ詳細情報を取得できない場合であっても、DMPがコンテンツ詳細情報を取得することが可能になる。
【0093】
また、拡張内容は、単に配信中コンテンツ情報用拡張CDSを設けたのみで、使用するコマンド(アクション)のプロトコルを変更する必要はない。したがって、DMS及びDMPへの実装負担は大きくない。
【0094】
また、図13A及び図13Bには、3−Box System Usageにおいて、DMSがプロバイダーから取得したライブ・コンテンツを配信する場合の、DMRにおいてコンテンツ再生を行なう通信シーケンス例を示している。コンテンツ再生時において、DMSがライブ・コンテンツについてのコンテンツ詳細情報を配信中コンテンツ情報用拡張CDSに格納して、DMCに公開するという点で、図10Bに示した通信シーケンス例とは相違する。
【0095】
DMPがコンテンツ・ブラウジングを行なうための通信シーケンスは、図10Aと同様なので、ここでは図示を省略する。すなわち、コンテンツ・ブラウジングにおいては、DMCのCDS情報閲覧部502からDMSに対して、CDS:Browseアクションが発行される。DMS側では、CDS情報生成部305が、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得して、CDS情報を生成する。そして、CDS情報提供部307は、生成されたCDS情報を、DMCに対してCDS Resultとして返す。
【0096】
再生時には、DMCのコンテンツ再生要求部503が、DMRに対してAVT:SetAVTransportURI()アクションを発行して、選択したコンテンツの属性情報を通知する。コンテンツ再生要求部503は、DMRに対してさらにAVT:Play()アクションを発行して、コンテンツの再生開始を要求する。
【0097】
DMRは、コンテンツの再生開始要求に応答して、コンテンツ取得部602が、HTTP Getメソッドを用いてコンテンツを要求する。DMS側では、ライブ・コンテンツに対するHTTP Get要求を受けとると、まず、CDS情報生成部305は、配信中コンテンツ情報用拡張CDSをCDS情報格納部306内に生成する。そして、HTTP Get要求元のIPアドレスから、配信先コンテナー・ノードを作成し、配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを生成する。但し、既に同一のクライアントに配信中で、作成済みであれば、配信先コンテンツを作成する必要はない。
【0098】
続いて、コンテンツ取得部303がプロバイダーにアクセスして、コンテンツ・データを取得する。CDS情報生成部305は、取得したコンテンツ・データからコンテンツ詳細情報を抽出すると、配信中コンテンツ・ノードにこのコンテンツ詳細情報を保存し公開する。なお、コンテンツ詳細情報は、プロバイダーによって、別の専用のコマンドを発行することによって取得できる場合もあれば、コンテンツ・データに含まれている場合などがあり、後者の場合は、コンテンツ・データをデコードする際に抽出する必要がある。
【0099】
そして、コンテンツ取得部303はプロバイダーからライブ・コンテンツのコンテンツ・データを一定量毎に取得し、コンテンツ提供部304はこれをDMRに返す(配信する)。そして、DMR側では、コンテンツ復号部603が受け取ったデータをデコードし、コンテンツ再生出力部604が再生する。
【0100】
ここで、DMCは、DMRがHTTP Get要求を出し、DMSからライブ・コンテンツの配信が開始された段階で、配信中コンテンツ情報用拡張CDSに対するCDS:Browseアクションを発行することにより、DMSが配信中で自身が再生しているライブ・コンテンツのコンテンツ詳細情報を取得し、表示に用いたりすることが可能である。DMCは、CDS:Browseアクションを発行する際、対象とする配信先コンテナー・ノードのObjectIDを自身のIPアドレスから生成する(前述)。DMS側では、CDS情報提供部307は、CDS:Browseアクションを受け取ると、そのObjectIDを基に、配信中コンテンツ情報用拡張CDSから該当する配信中コンテナー・ノードを特定して、そこに格納されているコンテンツ詳細情報を、DMCに対してCDS Resultとして返す。
【0101】
コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びDMSからDMSへのコンテンツ・データの配信とDMP側でのコンテンツのデコード及び再生が繰り返される。そして、ライブ・コンテンツの配信が終了すると、DMS側では、配信中コンテンツ情報用拡張CDSのうち、該当する配信先コンテナー・ノード並びに配信中コンテンツ・ノードを、CDS情報格納部306から破棄する。
【0102】
このように、CDS情報を拡張することにより、サービスや放送コンテンツを実際に受信しないとコンテンツ詳細情報を取得できない場合であっても、DMCがコンテンツ詳細情報を取得することが可能になる。
【0103】
また、拡張内容は、単に配信中コンテンツ情報用拡張CDSを設けたのみで、使用するコマンド(アクション)のプロトコルを変更する必要はない。したがって、DMS及びDMC、DMRへの実装負担は大きくない。
【0104】
図12並びに図13から分かるように、本提案によれば、DMSが現在配信中のライブ・コンテンツに関するコンテンツ詳細情報をリアルタイムで受信し、クライアントに配信することにより、DMPやDMRなどのクライアント側では、コンテンツを直接受信した場合と同様のコンテンツ詳細情報を表示することができる。すなわち、2−Box Pull及び3−Box System Usageにおいて、ライブ・コンテンツを配信する際のユーザビリティーを向上することができる。
【産業上の利用可能性】
【0105】
以上、本明細書で開示する技術に係る特定の実施形態について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0106】
本明細書では、DLNAの2−Box Pull及び3−Box System Usageにおいて、DMSがライブ・コンテンツを配信する場合の実施形態を中心に説明してきたが、DMSが自身のストレージに保存するコンテンツを配信する場合であっても、同様に配信中コンテンツ情報用拡張CDSを生成して、コンテンツ詳細情報をクライアントに公開することができる。
【0107】
また、本明細書では、本提案をDLNAの2−Box Pull及び3−Box System Usageに適用した実施形態を中心に説明してきたが、勿論、DLNA以外であっても、CDS機能を実装するさまざまなタイプの通信システムに、同様に本提案を適用することができる。
【0108】
要するに、例示という形態で本明細書で開示する技術を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【0109】
301…通信制御部
302…コンテンツ蓄積部
303…コンテンツ取得部
304…コンテンツ提供部
305…CDS情報生成部
306…CDS情報格納部
307…CDS情報提供部
401…通信制御部
402…CDS情報閲覧部
403…コンテンツ取得部
404…コンテンツ復号部
405…コンテンツ再生出力部
501…通信制御部
502…CDS情報閲覧部
503…コンテンツ再生要求部
601…通信制御部
602…コンテンツ取得部
603…コンテンツ復号部
604…コンテンツ再生出力部


【特許請求の範囲】
【請求項1】
DLNA規格に則って動作してコンテンツを配信するサーバーと、DLNA規格に則って動作してコンテンツの配信を要求するクライアントからなり、
前記サーバーは、前記クライアントを特定する情報に基づくObjectIDを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを配置した配信中コンテンツ情報用拡張CDSを作成し、前記クライアントに配信するために取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納する、
通信システム。
【請求項2】
外部の機器と通信する通信部と、
クライアントから要求されたコンテンツを取得するコンテンツ取得部と、
クライアントにコンテンツを配信するコンテンツ提供部と、
コンテンツに関するCDS情報を生成するCDS情報生成部と、
クライアントからの要求によりCDS情報を送信するCDS情報提供部と、
を具備し、
前記CDS情報生成部は、クライアントからコンテンツの提供を要求されたことに応答して、配信中コンテンツ情報用拡張CDSのルートの直下に、当該クライアントを特定する情報に基づくObjectIDを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを作成し、前記コンテンツ取得部が取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納し、
前記CDS情報提供部は、前記コンテンツ提供部がコンテンツを配信中のクライアントからのCDS情報の要求に応答して、該当する配信中コンテンツ・ノードに格納されているコンテンツ詳細情報を含むCDS情報を送信する、
DLNA規格に則ってサーバーとして動作する通信装置。
【請求項3】
前記配信中コンテンツ・ノードは、コンテンツのURLと一致するres情報を持つ、
請求項2に記載の通信装置。
【請求項4】
前記コンテンツ提供部がクライアントへのコンテンツの配信を終了したときに、前記配信コンテンツ情報用拡張CDSから該当する各ノードを削除する、
請求項2に記載の通信装置。
【請求項5】
前記コンテンツ取得部は、前記通信部を介して外部ネットワーク上のプロバイダーからライブ・コンテンツを取得し、
前記CDS情報生成部は、クライアントからライブ・コンテンツが要求されたときに、前記配信中コンテンツ情報用拡張CDSに、前記配信先コンテナー・ノード及び前記配信中コンテンツ・ノードを作成する、
請求項2に記載の通信装置。
【請求項6】
クライアントに提供するコンテンツを蓄積するコンテンツ蓄積部をさらに備え、
前記CDS情報生成部は、クライアントから前記コンテンツ蓄積部に蓄積されているコンテンツが要求されたときに、前記配信中コンテンツ情報用拡張CDSに、前記配信先コンテナー・ノード及び前記配信中コンテンツ・ノードを作成する、
請求項2に記載の通信装置。
【請求項7】
DLNA規格に則った機器と通信する通信部と、
DLNA規格に則ったサーバーに対してCDS情報の閲覧を要求するCDS情報閲覧部と、
を少なくとも備え、
前記CDS情報閲覧部は、自身を特定する情報に基づくObjectIDを生成し、前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求する、
DLNA規格に則ってクライアントとして動作する通信装置。
【請求項8】
前記通信装置は、DLNA規格で定義されるDMPであり、前記サーバーにコンテンツを要求して取得するコンテンツ取得部と、コンテンツを復号するコンテンツ復号部と、復号したコンテンツを再生出力するコンテンツ再生出力部をさらに備え、
前記CDS情報閲覧部は、前記コンテンツ取得部が前記サーバーに対してプロバイダーが提供するライブ・コンテンツを要求するときに、自身を特定する情報に基づくObjectIDを生成し、前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求する、
請求項7に記載の通信装置。
【請求項9】
前記通信装置は、DLNA規格で定義されるDMCであり、レンダラーに対してコンテンツの再生出力を要求するコンテンツ再生要求部をさらに備え、
前記CDS情報閲覧部は、前記コンテンツ再生要求部が前記レンダラーに対してプロバイダーが提供するライブ・コンテンツの再生を要求するときに、自身を特定する情報に基づくObjectIDを生成し、前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求する、
請求項7に記載の通信装置。
【請求項10】
クライアントからコンテンツの提供を要求されたことに応答して、配信中コンテンツ情報用拡張CDSのルートの直下に、当該クライアントを特定する情報に基づくObjectIDを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを作成するステップと、
クライアントから要求されたコンテンツを取得するステップと、
取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納するステップと、
取得したコンテンツをクライアントに配信するステップと、
コンテンツを配信中のクライアントからのCDS情報の要求に応答して、該当する配信中コンテンツ・ノードに格納されているコンテンツ詳細情報を含むCDS情報を送信するステップと、
を有し、DLNA規格に則ってサーバーとして動作する通信方法。
【請求項11】
通信装置自身を特定する情報に基づくObjectIDを生成するステップと、
前記ObjectIDを使って前記サーバーにCDS情報の閲覧を要求するステップと、
を有し、DLNA規格に則ってクライアントとして動作する通信方法。


【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9A】
image rotate

【図9B】
image rotate

【図10A】
image rotate

【図10B】
image rotate

【図11】
image rotate

【図12A】
image rotate

【図12B】
image rotate

【図13A】
image rotate

【図13B】
image rotate