JP2012213111A - 通信システム、通信装置並びに通信方法 - Google Patents

Abstract

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

Description

本明細書で開示される技術は、ＤＬＮＡ規格に則ってコンテンツ配信サービスを行なう通信システム、通信装置並びに通信方法に係り、特に、ＣＤＳ機能によりコンテンツのメタ情報を提供する通信システム、通信装置並びに通信方法に関する。

最近、ＡＶコンテンツのほとんどがディジタル化されており、ＣＤやＤＶＤなどのディジタル・コンテンツを記録再生するメディアが広く利用されている。さらには、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んとなり、ＣＤやＤＶＤなどのメディアの移動なしに、ネットワークを経由して遠隔端末間でコンテンツ配信が行なわれている。また、機器を接続しただけでネットワークへの参加を可能にするＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）をペーストしてディジタル化されたＡＶコンテンツを家庭内でＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワーク経由で流通させるＤＬＮＡ（ＤｉｇｉｔａｌＬｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）が規格化されている。これに伴い、ＡＶ機器を中心としたＣＥ（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ）機器、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）及びその周辺機器（例えばＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）など）で、ＤＬＮＡ規格、あるいはＵＰｎＰ規格に準拠した機能を持つ製品が増えてきている。

数年前に策定されたＤＬＮＡ Ｇｕｉｄｅｌｉｎｅ １．０（及び１．５）では、コンテンツを提供するサーバーに相当するＤＭＳ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ）と、再生するクライアントに相当するＤＭＰ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｐｌａｙｅｒ）からなる２−Ｂｏｘ Ｐｕｌｌ形式（Ｓｙｓｔｅｍ Ｕｓａｇｅ）の接続条件について定義された。同ガイドラインのリリースに伴い、ＤＭＳ及びＤＭＳ機能を装備した製品が主に普及した。また近年策定されたＤＬＮＡ Ｇｕｉｄｅｌｉｎｅ １．５では、クライアントがＤＭＲ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｒｅｎｄｅｒｅｒ）及びＤＭＣ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｃｏｎｔｒｏｌｌｅｒ）からなる３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅが定義され、ＤＭＣを操作して、ＤＭＳからコンテンツをＤＭＲに送信して再生させることができる。同ガイドラインのリリースに伴い、ＤＭＲ及びＤＭＣ機能を装備した製品が登場した。

２−Ｂｏｘ Ｐｕｌｌ及び３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅのいずれにおいても、ＤＭＳは自身のストレージに保存されているコンテンツを配信する場合がほとんどである。ＤＬＮＡのベースとなるＵＰｎＰでは、ＤＭＳが提供するコンテンツのリストとコンテンツの詳細情報を階層化して配信するＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）機能が策定されている。ＤＬＮＡでＣＤＳを実装する場合、上記のように配信コンテンツがＤＭＳ内に保存されていれば、保存されているコンテンツからあらかじめＣＤＳを構築することが可能である。そもそもＣＤＳの規格は、ＤＭＳが配信コンテンツを自身のストレージに保存していること、つまり静的な情報を扱うことを前提として策定されている。

一方、ブロードバンドの普及に伴い、インターネット・サービスの分野において、音楽や動画コンテンツをストリーミング配信するサービスが増えてきている。今後は、インターネット・コンテンツや、欧米を中心に広がっているＤｉｇｉｔａｌ Ａｕｄｉｏ Ｂｒｏａｄｃａｓｔ（ＤＡＢ）、従来からあるアナログあるいはディジタルのラジオ放送コンテンツを受信して、家庭内の機器（ＤＭＰ、ＤＭＣ、ＤＭＲ）に配信する、ＤＭＳ機能の需要が高まると考えられる。言い換えれば、各々の機器（ＤＭＰ、ＤＭＣ、ＤＭＲ）がそういったサービスや放送コンテンツを直接受信するのではなく、ＤＭＳ機能を持つ１つの機器がプロキシー・サーバーのような役割で受信して、他のクライアント機器に配信するのである。このような利用形態によれば、ＤＭＰ、ＤＭＣ、ＤＭＲなどのクライアント機器側では、上記のようなサービスを直接受けるための認証シーケンスを実装したソフトウェア・モジュールや、放送を受信するチューナーなどのハードウェアを必要としないというメリットがある。

ところが、ＤＭＳ機能を持つ機器がリアルタイムで受信するコンテンツ（以下では「ライブ・コンテンツ」とする）をクライアント機器に配信する場合、そのコンテンツに付随する情報は、実際にサービス・放送コンテンツを受信しないと得られないことが多い。これに対し、標準的なＣＤＳは、前述のように、あらかじめ取得可能で静的な情報を扱うことを想定しているため、ライブ・コンテンツについてのより詳細な情報を公開できないという問題がある。この場合、サービスや放送コンテンツを直接受信する場合と比べて、クライアント機器側で表示できるメタ情報が少なくなってしまうなどのユーザビリティーの低下を招いてしまう。

例えば、コンテンツ・サーバーから受信したコンテンツを第２デバイスに提供する第１デバイスが、ＵＰｎＰ ＡＶ構造のＣＤＳのコンテンツ・リストを更新するコンテンツ提供方法について提案されているが（例えば、特許文献１を参照のこと）、コンテンツの詳細情報については更新されないので、ユーザビリティーの低下から免れることはできない。

特開２００８−２１２９３号公報

本明細書で開示する技術の目的は、ＤＬＮＡ規格に則ってコンテンツ配信サービスを好適に行なうことができる、優れた通信システム、通信装置並びに通信方法を提供することにある。

本明細書で開示する技術のさらなる目的は、ＤＭＳから各機器へ、ＣＤＳ機能によりコンテンツのメタ情報を好適に提供することができる、優れた通信システム、通信装置並びに通信方法を提供することにある。

本明細書で開示する技術のさらなる目的は、ＤＭＳがリアルタイムで受信して各機器へ配信するライブ・コンテンツに関する十分なメタ情報を好適に提供することができる、優れた通信システム、通信装置並びに通信方法を提供することにある。

本明細書は、上記課題を参酌してなされた技術を開示するものであり、請求項１に記載の技術は、
ＤＬＮＡ規格に則って動作してコンテンツを配信するサーバーと、ＤＬＮＡ規格に則って動作してコンテンツの配信を要求するクライアントからなり、
前記サーバーは、前記クライアントを特定する情報に基づくＯｂｊｅｃｔＩＤを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを配置した配信中コンテンツ情報用拡張ＣＤＳを作成し、前記クライアントに配信するために取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納する、
通信システムである。

但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。

また、本願の請求項２に記載の技術は、
外部の機器と通信する通信部と、
クライアントから要求されたコンテンツを取得するコンテンツ取得部と、
クライアントにコンテンツを配信するコンテンツ提供部と、
コンテンツに関するＣＤＳ情報を生成するＣＤＳ情報生成部と、
クライアントからの要求によりＣＤＳ情報を送信するＣＤＳ情報提供部と、
を具備し、
前記ＣＤＳ情報生成部は、クライアントからコンテンツの提供を要求されたことに応答して、配信中コンテンツ情報用拡張ＣＤＳのルートの直下に、当該クライアントを特定する情報に基づくＯｂｊｅｃｔＩＤを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを作成し、前記コンテンツ取得部が取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納し、
前記ＣＤＳ情報提供部は、前記コンテンツ提供部がコンテンツを配信中のクライアントからのＣＤＳ情報の要求に応答して、該当する配信中コンテンツ・ノードに格納されているコンテンツ詳細情報を含むＣＤＳ情報を送信する、
ＤＬＮＡ規格に則ってサーバーとして動作する通信装置である。

本願の請求項３に記載の技術によれば、請求項２に記載の通信装置において、配信中コンテンツ・ノードは、コンテンツのＵＲＬと一致するｒｅｓ情報を持つ。

本願の請求項４に記載の技術によれば、請求項２に記載の通信装置は、コンテンツ提供部がクライアントへのコンテンツの配信を終了したときに、前記配信コンテンツ情報用拡張ＣＤＳから該当する各ノードを削除するように構成されている。

本願の請求項５に記載の技術によれば、請求項２に記載の通信装置のコンテンツ取得部は、前記通信部を介して外部ネットワーク上のプロバイダーからライブ・コンテンツを取得し、ＣＤＳ情報生成部は、クライアントからライブ・コンテンツが要求されたときに、前記配信中コンテンツ情報用拡張ＣＤＳに、前記配信先コンテナー・ノード及び前記配信中コンテンツ・ノードを作成するように構成されている。

本願の請求項６に記載の技術によれば、請求項２に記載の通信装置は、クライアントに提供するコンテンツを蓄積するコンテンツ蓄積部をさらに備えている。そして、ＣＤＳ情報生成部は、クライアントから前記コンテンツ蓄積部に蓄積されているコンテンツが要求されたときに、前記配信中コンテンツ情報用拡張ＣＤＳに、前記配信先コンテナー・ノード及び前記配信中コンテンツ・ノードを作成するように構成されている。

また、本願の請求項７に記載の技術は、
ＤＬＮＡ規格に則った機器と通信する通信部と、
ＤＬＮＡ規格に則ったサーバーに対してＣＤＳ情報の閲覧を要求するＣＤＳ情報閲覧部と、
を少なくとも備え、
前記ＣＤＳ情報閲覧部は、自身を特定する情報に基づくＯｂｊｅｃｔＩＤを生成し、前記ＯｂｊｅｃｔＩＤを使って前記サーバーにＣＤＳ情報の閲覧を要求する、
ＤＬＮＡ規格に則ってクライアントとして動作する通信装置。
である。

本願の請求項８に記載の技術によれば、請求項７に記載の通信装置は、ＤＬＮＡ規格で定義されるＤＭＰであり、前記サーバーにコンテンツを要求して取得するコンテンツ取得部と、コンテンツを復号するコンテンツ復号部と、復号したコンテンツを再生出力するコンテンツ再生出力部をさらに備えている。そして、ＣＤＳ情報閲覧部は、前記コンテンツ取得部が前記サーバーに対してプロバイダーが提供するライブ・コンテンツを要求するときに、自身を特定する情報に基づくＯｂｊｅｃｔＩＤを生成し、前記ＯｂｊｅｃｔＩＤを使って前記サーバーにＣＤＳ情報の閲覧を要求するように構成されている。

本願の請求項９に記載の技術によれば、請求項７に記載の通信装置は、ＤＬＮＡ規格で定義されるＤＭＣであり、レンダラーに対してコンテンツの再生出力を要求するコンテンツ再生要求部をさらに備えている。そして、ＣＤＳ情報閲覧部は、前記コンテンツ再生要求部が前記レンダラーに対してプロバイダーが提供するライブ・コンテンツの再生を要求するときに、自身を特定する情報に基づくＯｂｊｅｃｔＩＤを生成し、前記ＯｂｊｅｃｔＩＤを使って前記サーバーにＣＤＳ情報の閲覧を要求するように構成されている。

また、本願の請求項１０に記載の技術は、
クライアントからコンテンツの提供を要求されたことに応答して、配信中コンテンツ情報用拡張ＣＤＳのルートの直下に、当該クライアントを特定する情報に基づくＯｂｊｅｃｔＩＤを持つ配信先コンテナー・ノードをルートの直下に配置するとともに、前記配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを作成するステップと、
クライアントから要求されたコンテンツを取得するステップと、
取得したコンテンツからコンテンツ詳細情報を抽出して前記配信中コンテンツ・ノードに格納するステップと、
取得したコンテンツをクライアントに配信するステップと、
コンテンツを配信中のクライアントからのＣＤＳ情報の要求に応答して、該当する配信中コンテンツ・ノードに格納されているコンテンツ詳細情報を含むＣＤＳ情報を送信するステップと、
を有し、ＤＬＮＡ規格に則ってサーバーとして動作する通信方法である。

また、本願の請求項１１に記載の技術は、
通信装置自身を特定する情報に基づくＯｂｊｅｃｔＩＤを生成するステップと、
前記ＯｂｊｅｃｔＩＤを使って前記サーバーにＣＤＳ情報の閲覧を要求するステップと、
を有し、ＤＬＮＡ規格に則ってクライアントとして動作する通信方法である。

本明細書で開示される技術によれば、ＤＭＳがリアルタイムで受信して各機器へ配信するライブ・コンテンツに関する十分なメタ情報を好適に提供することができる、優れた通信システム、通信装置並びに通信方法を提供することができる。

本明細書で開示される技術によれば、ＤＭＳなどの１つの機器がプロキシー・サーバーのような役割で各々の機器（ＤＭＰ、ＤＭＣ、ＤＭＲ）に配信するライブ・コンテンツについてのより詳細な情報を公開することができ、ユーザビリティーを向上することができる。

本明細書で開示される技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、ＤＬＮＡ Ｇｕｉｄｅｌｉｎｅ １．０で定義された２−Ｂｏｘ Ｐｕｌｌ形式（Ｓｙｓｔｅｍ Ｕｓａｇｅ）に基づく通信システムの構成例を示した図である。 図２は、ＤＬＮＡ Ｇｕｉｄｅｌｉｎｅ １．５で定義された３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅに基づく通信システムの構成例を示した図である。 図３は、ＤＭＳとして動作する機器の機能ブロック図である。 図４は、ＤＭＰとして動作する機器の機能ブロック図である。 図５は、ＤＭＣとして動作する機器の機能ブロック図である。 図６は、ＤＭＲとして動作する機器の機能ブロック図である。 図７は、２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳが自身のストレージに保存されたコンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示した図である。 図８は、２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示した図である。 図９Ａは、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳが自身のストレージに保存されたコンテンツを配信する場合の、ＤＭＣにおいてコンテンツ・ブラウジングを行なうための通信シーケンス例を示した図である。 図９Ｂは、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳが自身のストレージに保存されたコンテンツを配信する場合の、ＤＭＲにおいてコンテンツ再生を行なうための通信シーケンス例を示した図である。 図１０Ａは、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツを配信する場合の、ＤＭＣにおいてコンテンツ・ブラウジングを行なうための通信シーケンス例を示した図である。 図１０Ｂは、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツを配信する場合の、ＤＭＲにおいてコンテンツ再生を行なうための通信シーケンス例を示した図である。 図１１は、コンテンツ・ブラウジング時にアクセスされるＣＤＳツリーとは別に、配信中のコンテンツのコンテンツ詳細情報を載せるためのＣＤＳツリーを備えたＣＤＳ構成例を示した図である。 図１２Ａは、２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ再生を行なう通信シーケンス例を示した図である。 図１２Ｂは、２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ再生を行なう通信シーケンス例を示した図である。 図１３Ａは、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツを配信する場合の、ＤＭＲにおいてコンテンツ再生を行なう通信シーケンス例を示した図である。 図１３Ｂは、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツを配信する場合の、ＤＭＲにおいてコンテンツ再生を行なう通信シーケンス例を示した図である。

以下、図面を参照しながら本明細書で開示される技術に係る実施形態について詳細に説明する。

図１には、ＤＬＮＡ Ｇｕｉｄｅｌｉｎｅ １．０で定義された２−Ｂｏｘ Ｐｕｌｌ形式（Ｓｙｓｔｅｍ Ｕｓａｇｅ）に基づく通信システムの構成例を示している。家庭内に敷設されたＩＰネットワーク上には、家庭内ＩＰネットワークを介してコンテンツを提供するＤＭＳと、家庭内ＩＰネットワーク経由で受信したコンテンツを再生するＤＭＰが、所定の接続条件に従って接続されている。ＤＭＳは、自身のストレージに保存している静的なコンテンツを提供する。また、ＤＭＳは、インターネットなどの外部ネットワークにも接続しており、外部ネットワーク上のプロバイダーから取得したライブ・コンテンツを提供することもできる。但し、ここで言う「プロバイダー」とは、サービスやコンテンツの提供者のことを指す。

図示の通信システムでは、ＵＰｎＰで策定されているＣＤＳ機能が実装されているが、その詳細については後述に譲る。なお、図面の簡素化のため、図１中ではＤＭＳ並びにＤＭＰをそれぞれ１台ずつしか描いていないが、２台以上のＤＭＳ、ＤＭＰが家庭内ＩＰネットワークに接続されることもある。

また、図２には、ＤＬＮＡ Ｇｕｉｄｅｌｉｎｅ １．５で定義された３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅに基づく通信システムの構成例を示している。家庭内に敷設されたＩＰネットワーク上には、家庭内ＩＰネットワークを介してコンテンツを提供するＤＭＳと、ＩＰネットワーク経由で受信したコンテンツを再生するＤＭＲと、ＤＭＲを操作するＤＭＣが、所定の接続条件に従って接続されている。ＤＭＳは、自身のストレージに保存している静的なコンテンツを提供する。また、ＤＭＳは、インターネットなどの外部ネットワークにも接続しており、外部ネットワーク上のプロバイダー（コンテンツ・サーバー）から取得したライブ・コンテンツを提供することもできる。図示の通信システムでは、ＵＰｎＰで策定されているＣＤＳ機能が実装されているが、その詳細については後述に譲る。なお、図面の簡素化のため、図２中ではＤＭＳ、ＤＭＣ、ＤＭＲをそれぞれ１台ずつしか描いていないが、２台以上のＤＭＳ、ＤＭＣ、ＤＭＲが家庭内ＩＰネットワークに接続されることもある。

図３には、図１並びに図２中のＤＭＳとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。

通信制御部３０１は、家庭内ＩＰネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。

コンテンツ蓄積部３０２は、ＤＭＳ自身がＤＭＰ若しくはＤＭＲに提供するコンテンツを蓄積する。また、コンテンツ蓄積部３０２は、蓄積している各コンテンツに関する詳細な情報を記述したコンテンツ情報をあらかじめ保存する内部データベースを備えている。

コンテンツ取得部３０３は、ＤＭＰ若しくはＤＭＲから要求されたライブ・コンテンツを、外部ネットワーク経由でプロバイダーから取得する。

コンテンツ提供部３０４は、コンテンツ蓄積部３０２に蓄積されている静的なコンテンツ、並びに、プロバイダーから取得した取得したライブ・コンテンツを、要求元のＤＭＰ若しくはＤＭＲに提供する。

ＣＤＳ情報生成部３０５は、コンテンツ蓄積部３０２に蓄積されている静的なコンテンツ、並びに、プロバイダーから取得した取得したライブ・コンテンツについてのＣＤＳ情報を生成する。生成されたＣＤＳ情報は、ＣＤＳ情報格納部３０６に格納される。

コンテンツ蓄積部３０２に蓄積されている静的なコンテンツについては、その内部データベース（前述）にアクセスして、コンテンツに関する取得可能なすべての情報を取得することができるので、ＣＤＳ情報生成部３０５は十分なＣＤＳ情報を生成することができる。これに対し、ライブ・コンテンツについては、プロバイダーによって異なるが、大抵の場合はコンテンツのタイトルなどの限られた情報しか取得できず、実際にコンテンツ・データ自体を取得してからでないとアーティスト情報などのより詳細な情報を得ることができない。このため、ＣＤＳ情報生成部３０５は、取得前のライブ・コンテンツに関しては、限られた情報からなるＣＤＳ情報を生成することになる。なお、ＣＤＳ情報格納部３０６に格納するＣＤＳ情報のデータ構造の詳細については、後述に譲る。

ＣＤＳ情報提供部３０７は、ＤＭＰ若しくはＤＭＣからのＣＤＳ情報の取得要求に応答して、ＣＤＳ情報格納部３０６に格納されているＣＤＳ情報を提供する。

図４には、図１中のＤＭＰとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。

通信制御部４０１は、家庭内ＩＰネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。

ＣＤＳ情報閲覧部４０２は、ＤＭＳに対してＣＤＳ情報の取得要求を行ない、取得したＣＤＳ情報の閲覧画面を表示する。例えば、ＣＤＳ情報として、ＤＭＳが提供可能な（若しくはＤＭＳを通じて取得可能な）コンテンツのリストを取得したときには、コンテンツ一覧画面が表示され、ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。

コンテンツ取得部４０３は、ユーザーが選択したコンテンツの取得要求をＤＭＳに送信して、コンテンツの取得を行なう。そして、コンテンツ復号部４０４は取得したコンテンツを復号し、コンテンツ再生出力部４０５は復号したコンテンツを再生出力する。

図５には、図２中のＤＭＣとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。

通信制御部５０１は、家庭内ＩＰネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。

ＣＤＳ情報閲覧部５０２は、ＤＭＳに対してＣＤＳ情報の取得要求を行ない、取得したＣＤＳ情報の閲覧画面を表示する。例えば、ＣＤＳ情報として、ＤＭＳが提供可能な（若しくはＤＭＳを通じて取得可能な）コンテンツのリストを取得したときには、コンテンツ一覧画面が表示され、ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。

コンテンツ再生要求部５０３は、ユーザーが選択したコンテンツの再生出力を、ＤＭＲに対して要求する。

図６には、図２中のＤＭＲとして動作する機器の機能的構成を模式的に示している。以下、各部について説明する。

通信制御部６０１は、家庭内ＩＰネットワークを介した通信動作を制御するとともに、当該機器全体の動作を統括的に制御する。

コンテンツ取得部６０２は、ＤＭＣから再生要求されたコンテンツの取得要求をＤＭＳに送信して、コンテンツの取得を行なう。そして、コンテンツ復号部６０３は取得したコンテンツを復号し、コンテンツ再生出力部６０４は復号したコンテンツを再生出力する。

図７には、図１に示した２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳが自身のストレージ（コンテンツ蓄積部３０２）に保存されたコンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示している。

コンテンツ・ブラウジングにおいては、ＤＭＰのＣＤＳ情報閲覧部４０２からＤＭＳに対して、ＣＤＳ：Ｂｒｏｗｓｅアクションが発行される。

ＤＭＳ側では、自身のストレージであるコンテンツ蓄積部３０２に保存されているコンテンツに対してＣＤＳ：Ｂｒｏｗｓｅアクションが発行されたので、ＣＤＳ情報生成部３０５は、該当するコンテンツに関する取得可能なすべてのコンテンツ情報をコンテンツ蓄積部３０２の内部データベースから取得して、十分な情報量のＣＤＳ情報を生成して、ＣＤＳ情報格納部３０６に格納する。また、ＣＤＳ情報提供部３０７は、生成されたＣＤＳ情報を、ＤＭＰに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

ＤＭＰ側では、ＣＤＳ情報閲覧部４０２が、受信したＣＤＳ Ｒｅｓｕｌｔを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する。ＤＭＰのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。

再生時には、ＤＭＰのコンテンツ取得部４０３から例えばＨＴＴＰ Ｇｅｔメソッドを用いてコンテンツが要求される。ＤＭＳ側では、コンテンツ提供部３０４がＨＴＴＰ Ｇｅｔ要求を受けとると、自身のストレージであるコンテンツ蓄積部３０２に保存されているコンテンツ・データを、一定容量毎にＤＭＰに返す（配信する）。そして、ＤＭＰ側では、コンテンツ復号部４０４が受け取ったデータをデコードし、コンテンツ再生出力部４０５が再生する。コンテンツ・データのエンドに到達するまで、ＤＭＳからのコンテンツ・データの配信とＤＭＰ側でのコンテンツのデコード及び再生が繰り返される。

一方、図８には、図１に示した２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ・ブラウジング及びコンテンツ再生を行なうための通信シーケンス例を示している。

コンテンツ・ブラウジングにおいては、ＤＭＰのＣＤＳ情報閲覧部４０２からＤＭＳに対して、ライブ・コンテンツに関するＣＤＳ:Ｂｒｏｗｓｅアクションが発行される。

ＤＭＳ側では、ライブ・コンテンツ、すなわち自身のストレージであるコンテンツ蓄積部３０２に保存されていないコンテンツに対してＣＤＳ：Ｂｒｏｗｓｅアクションが発行されたので、ＣＤＳ情報生成部３０５は、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得して、ＣＤＳ情報を生成し、ＣＤＳ情報格納部３０６に格納する。プロバイダーによって異なるが、大抵の場合はコンテンツのタイトルなどの限られた情報しか取得できない。このため、ＣＤＳ情報生成部３０５は、限られた情報からなるＣＤＳ情報しか生成することができない。そして、ＣＤＳ情報提供部３０７は、生成されたＣＤＳ情報を、ＤＭＰに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

ＤＭＰ側では、ＣＤＳ情報閲覧部４０２が、受信したＣＤＳ Ｒｅｓｕｌｔを解析して、コンテンツのタイトルなどの限られた情報からなるコンテンツ情報を表示する。ＤＭＰのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。

再生時には、ＤＭＰのコンテンツ取得部４０３から例えばＨＴＴＰ Ｇｅｔメソッドを用いてコンテンツが要求される。ＤＭＳ側では、ライブ・コンテンツに対するＨＴＴＰ Ｇｅｔ要求を受けとると、コンテンツ取得部３０３がプロバイダーにアクセスして、コンテンツ・データを取得する。そして、コンテンツ提供部３０４は、プロバイダーから取得したライブ・コンテンツのデータを、一定容量毎にＤＭＰに返す（配信する）。ＤＭＰ側では、コンテンツ復号部４０４が受け取ったデータをデコードし、コンテンツ再生出力部４０５が再生する。コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びＤＭＳからＤＭＳへのコンテンツ・データの配信とＤＭＰ側でのコンテンツのデコード及び再生が繰り返される。

ＤＭＳは、実際にコンテンツ・データ自体を取得すれば、ライブ・コンテンツに関してアーティスト情報などのより詳細な情報（以下、「コンテンツ詳細情報」とする）を得ることができるようになる。しかしながら、現在のＤＬＮＡの標準規格では、ＤＭＳが配信しているコンテンツの情報をＤＭＰが取得する仕組みがないので、ＤＭＰ側ではライブ・コンテンツに関するコンテンツ詳細情報を得ることができず、結局のところ、ＤＭＰのユーザーは、コンテンツ・ブラウジング時において限られた情報からなるＣＤＳ情報しか取得することができない。

また、図９Ａ及び図９Ｂには、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳが自身のストレージに保存されたコンテンツを配信する場合の、ＤＭＣにおいてコンテンツ・ブラウジングしＤＭＲにおいてコンテンツ再生を行なうための通信シーケンス例を示している。

コンテンツ・ブラウジングにおいては、図９Ａに示すように、ＤＭＣのＣＤＳ情報閲覧部５０２からＤＭＳに対して、ＣＤＳ：Ｂｒｏｗｓｅアクションが発行される。

ＤＭＳ側では、自身のストレージであるコンテンツ蓄積部３０２に保存されているコンテンツに対してＣＤＳ：Ｂｒｏｗｓｅアクションが発行されたので、ＣＤＳ情報生成部３０５は、該当するコンテンツに関する取得可能なすべてのコンテンツ情報をコンテンツ蓄積部３０２の内部データベースから取得して、十分な情報量のＣＤＳ情報を生成して、ＣＤＳ情報格納部３０６に格納する。また、ＣＤＳ情報提供部３０７は、生成されたＣＤＳ情報を、ＤＭＰに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

ＤＭＣ側では、ＣＤＳ情報閲覧部５０２が、受信したＣＤＳ Ｒｅｓｕｌｔを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する。ＤＭＰのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。

再生時には、図９Ｂに示すように、ＤＭＣのコンテンツ再生要求部５０３が、ＤＭＲに対してＡＶＴ：ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＩ（）アクションを発行して、選択したコンテンツの属性情報を通知する。コンテンツの属性情報には、コンテンツのタイトル、コンテンツのサイズ、コンテンツの長さ、コンテンツにアクセスするためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などが含まれる。コンテンツ再生要求部５０３は、ＤＭＲに対してさらにＡＶＴ：Ｐｌａｙ（）アクションを発行して、コンテンツの再生開始を要求する。

ＤＭＲは、コンテンツの再生開始要求に応答して、コンテンツ取得部６０２が、ＨＴＴＰ Ｇｅｔメソッドを用いてコンテンツを要求する。ＤＭＳ側では、コンテンツ提供部３０４がＨＴＴＰ Ｇｅｔ要求を受けとると、自身のストレージであるコンテンツ蓄積部３０２に保存されているコンテンツ・データを、一定容量毎にＤＭＰに返す（配信する）。そして、ＤＭＲ側では、コンテンツ復号部６０３が受け取ったデータをデコードし、コンテンツ再生出力部６０４が再生する。コンテンツ・データのエンドに到達するまで、ＤＭＳからのコンテンツ・データの配信とＤＭＲ側でのコンテンツのデコード及び再生が繰り返される。

一方、図１０Ａ及び図１０Ｂには、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツを配信する場合の、ＤＭＣにおいてコンテンツ・ブラウジングしＤＭＲにおいてコンテンツ再生を行なうための通信シーケンス例を示している。

コンテンツ・ブラウジングにおいては、図１０Ａに示すように、ＤＭＣのＣＤＳ情報閲覧部５０２からＤＭＳに対して、ＣＤＳ:Ｂｒｏｗｓｅアクションが発行される。

ＤＭＳ側では、ライブ・コンテンツ、すなわち自身のストレージであるコンテンツ蓄積部３０２に保存されていないコンテンツに対してＣＤＳ：Ｂｒｏｗｓｅアクションが発行されたので、ＣＤＳ情報生成部３０５は、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得して、ＣＤＳ情報を生成し、ＣＤＳ情報格納部３０６に格納する。プロバイダーによって異なるが、大抵の場合はコンテンツのタイトルなどの限られた情報しか取得できない。このため、ＣＤＳ情報生成部３０５は、限られた情報からなるＣＤＳ情報しか生成することができない。そして、ＣＤＳ情報提供部３０７は、生成されたＣＤＳ情報を、ＤＭＣに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

ＤＭＣ側では、ＣＤＳ情報閲覧部５０２が、受信したＣＤＳ Ｒｅｓｕｌｔを解析して、コンテンツのタイトルなどの限られた情報からなるコンテンツ情報を表示する。ＤＭＣのユーザーは、コンテンツのリストの中から、再生したいコンテンツを選択することができる。

再生時には、図１０Ｂに示すように、ＤＭＣのコンテンツ再生要求部５０３が、ＤＭＲに対してＡＶＴ：ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＩ（）アクションを発行して、選択したコンテンツの属性情報を通知する。コンテンツの属性情報には、コンテンツのタイトル、コンテンツのサイズ、コンテンツの長さ、コンテンツにアクセスするためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などが含まれる。コンテンツ再生要求部５０３は、ＤＭＲに対してさらにＡＶＴ：Ｐｌａｙ（）アクションを発行して、コンテンツの再生開始を要求する。

ＤＭＲは、コンテンツの再生開始要求に応答して、コンテンツ取得部６０２が、ＨＴＴＰ Ｇｅｔメソッドを用いてコンテンツを要求する。ＤＭＳ側では、ＨＴＴＰ Ｇｅｔ要求を受けとると、コンテンツ取得部３０３がプロバイダーからライブ・コンテンツのコンテンツ・データを一定量毎に取得し、コンテンツ提供部がこれをＤＭＲに返す（配信する）。そして、ＤＭＲ側では、コンテンツ復号部６０３が受け取ったデータをデコードし、コンテンツ再生出力部６０４が再生する。コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びＤＭＳからＤＭＳへのコンテンツ・データの配信とＤＭＰ側でのコンテンツのデコード及び再生が繰り返される。

ＤＭＳは、実際にコンテンツ・データ自体を取得すれば、ライブ・コンテンツに関するコンテンツ詳細情報を得ることができるようになる。しかしながら、現在のＤＬＮＡの標準規格では、ＤＭＳが配信しているコンテンツの情報をＤＭＣが取得する仕組みがないので、ＤＭＣ側ではライブ・コンテンツに関するコンテンツ詳細情報を得ることができず、結局のところ、ＤＭＣのユーザーは、コンテンツ・ブラウジング時において限られた情報からなるＣＤＳ情報しか取得することができない。

図８並びに図１０についてまとめると、ＣＤＳの規格はＤＭＳが配信コンテンツを自身のストレージに保存していることを前提として策定され、ライブ・コンテンツに関するコンテンツ詳細情報をカバーするものではなく、また、現在のＤＬＮＡの標準規格ではＤＭＳが配信しているコンテンツの情報をＤＭＰ、ＤＭＣが取得する仕組みがない。このため、ＤＭＰ、ＤＭＣのユーザーはライブ・コンテンツに関しては限られた情報からなるＣＤＳ情報しか取得することができない。

そこで、本明細書では、ＤＭＰ、ＤＭＣのユーザーがライブ・コンテンツに関してもコンテンツ詳細情報を取得できるようにするための、ＤＭＳのＣＤＳ構成について提案する。本提案に係るＣＤＳ情報は、図１１に示すように、コンテンツ・ブラウジング時にアクセスされるＣＤＳツリーとは別に、配信中のコンテンツのコンテンツ詳細情報を載せるためのＣＤＳツリーを備えている。前者のＣＤＳツリーは、現在のＤＬＮＡでも実装されている通常のＣＤＳツリーであり、以下では「標準ＣＤＳ」と呼ぶことにする。また、後者の配信中のコンテンツのコンテンツ詳細情報を記載するためのＣＤＳツリーを、以下では「配信中コンテンツ情報用拡張ＣＤＳ」と呼ぶことにする。

標準ＣＤＳは、ＯｂｊｅｃｔＩＤが０（固定）のルートの直下に各コンテナーが配置される形で構成される。これに対し、配信中コンテンツ情報用拡張ＣＤＳについては、独自のＯｂｊｅｃｔＩＤを規定し（図示の例では、“ＳＴＲＥＡＭＩＮＧ＿０”）、それを持った配信中コンテンツ用のルート（以降、「ＳｔｒｅａｍｉｎｇＲｏｏｔと」呼ぶことにする)を設け、それを大元にしたツリーを構成する。

このように、標準ＣＤＳとは独立した形で配信中コンテンツ情報用拡張ＣＤＳを構成することにより、基本的に静的な情報しか載せることのない標準ＣＤＳと、配信する度に動的に変化する配信中コンテンツ情報用拡張ＣＤＳを分離し、コンテンツ・ブラウジング時に配信中コンテンツ情報用拡張ＣＤＳにアクセスされないようにする。

ここで、コンテンツの最小単位、例えば、１つの音楽データ（曲）、１つの動画データ、１つの静止画データなどは、アイテム（ｉｔｅｍ）と呼ばれる。ライブ・コンテンツの場合には、１つのチャンネルが１アイテムとして扱われる。また、上記のアイテムの集合として規定されるアイテムの上位オブジェクトは、コンテナー（ｃｏｎｔａｉｎｅｒ）と呼ばれる。集合の単位は、例えば、各オブジェクトの物理的な記憶位置に基づく集合、各オブジェクトの論理的関係に基づく集合、カテゴリーに基づく集合など、さまざまに設定され得る。

図１１に示す例では、標準ＣＤＳの集合の単位はメディアのカテゴリーである。標準ＣＤＳのルートの直下には、メディア種別毎のコンテナー・ノードＶｉｄｅｏ、Ｍｕｓｉｃ、Ｐｉｃｔｕｒｅが設けられる。各コンテナー・ノードは、メディアの種別を特定できるＯｂｊｅｃｔＩＤ、“ＶＩＤＥＯ＿ＣＯＮＴＡＩＮＥＲ”、“ＭＵＳＩＣ＿ＣＯＮＴＡＩＮＥＲ”、“ＰＩＣＴＵＲＥ＿ＣＯＮＴＡＩＮＥＲ”を持つ。また、各コンテナー・ノードＶｉｄｅｏ、Ｍｕｓｉｃ、Ｐｉｃｔｕｒｅの配下にはそれぞれ、動画、音楽、静止画のコンテンツ・ノード（アイテム）が配置されている。各コンテンツ・ノードは、ＨＴＴＰ Ｇｅｔメソッドで指定されるＵＲＬに該当するｒｅｓ情報を持つ。

一方、配信中コンテンツ情報用拡張ＣＤＳの集合の単位は配信先のクライアントであり、配信先のクライアント毎のコンテナー（以下では、「配信先コンテナー・ノード」と呼ぶ）が設けられている。そして、各配信先コンテナー・ノードの配下には、アイテムとして、コンテンツ詳細情報を格納用の配信中コンテンツ・ノードを配置している。こうすることにより、同時に複数のコンテンツを（複数のクライアントに）配信可能なＤＭＳにも対応することができる。なお、配信中コンテンツ情報用拡張ＣＤＳの各ノードは、配信が開始されると生成され、配信が終了すると破棄される動的なものとする。

配信先コンテナー・ノードは、ＩＰアドレスあるいはＭＡＣアドレス（図１１に示す例では、ＩＰアドレス）により特定できるようにし、その配下の配信中コンテンツ・ノードは、標準ＣＤＳ側のコンテンツ・ノードと紐付けられるようにする。本提案では、配信先コンテナー・ノードのＯｂｊｅｃｔＩＤとして、接頭辞“ＳＴＲＥＡＭＩＮＧ”の後ろに、配信先クライアントのＩＰアドレスを付加する。また、配信中コンテンツ・ノードについては、クライアントから再生時にＨＴＴＰ Ｇｅｔメソッドで指定されるＵＲＬに該当するｒｅｓ情報により、標準ＣＤＳの同コンテンツと紐付けることができる。

上述したような配信中コンテンツ情報用拡張ＣＤＳのルール（規定）をサーバー（ＤＭＳ）とクライアント（ＤＭＰ、ＤＭＣ）の間で共有することで、クライアントは、自身が再生しているコンテンツの配信中コンテンツ情報用拡張ＣＤＳ情報を特定することができる。具体的には、クライアントは、まず、自身のＩＰアドレスから対象の配信先コンテナー・ノードのＯｂｊｅｃｔＩＤを生成し、そのＯｂｊｅｃｔＩＤを引数として配信先コンテナー・ノードに対するＣＤＳ：Ｂｒｏｗｓｅアクションを行ない、サーバーから返却されたＣＤＳ Ｒｅｓｕｌｔから、自身が再生しているコンテンツのＵＲＬと一致するｒｅｓ情報を持つ配信中コンテンツ・ノードを特定する。

ＤＭＳは、プロバイダーからライブ・コンテンツのコンテンツ・データを取得すると、コンテンツ詳細情報を抽出することができ、配信中コンテンツ情報用拡張ＣＤＳに書き込むようにすることができる。一方、ＤＭＰ、ＤＭＣなどのクライアントは、上記のように、自身が再生しているコンテンツの配信中コンテンツ情報用拡張ＣＤＳ情報にアクセスすれば、コンテンツ・ブラウジング時には取得できなかったコンテンツ詳細情報を取得することができる。

図１２Ａ及び図１２Ｂには、図１に示した２−Ｂｏｘ Ｐｕｌｌ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツをＤＭＰに配信する場合の、ＤＭＰがコンテンツ再生を行なう通信シーケンス例を示している。コンテンツ再生時において、ＤＭＳがライブ・コンテンツについてのコンテンツ詳細情報を配信中コンテンツ情報用拡張ＣＤＳに格納して、ＤＭＰに公開するという点で、図８に示した通信シーケンス例とは相違する。

ＤＭＰがコンテンツ・ブラウジングを行なうための通信シーケンスは、図８と同様なので、図１２では図示を省略する。すなわち、コンテンツ・ブラウジングにおいては、ＤＭＰのＣＤＳ情報閲覧部４０２からＤＭＳに対して、ライブ・コンテンツに関するＣＤＳ:Ｂｒｏｗｓｅアクションが発行される。これに対し、ＤＭＳ側では、ＣＤＳ情報生成部３０５が、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得してＣＤＳ情報を生成し、ＣＤＳ情報提供部３０７がこれをＣＤＳ Ｒｅｓｕｌｔとして返す。

再生時には、ＤＭＰのコンテンツ取得部４０３から例えばＨＴＴＰ Ｇｅｔメソッドを用いてコンテンツが要求される。ＤＭＳ側では、ライブ・コンテンツに対するＨＴＴＰ Ｇｅｔ要求を受けとると、まず、ＣＤＳ情報生成部３０５は、配信中コンテンツ情報用拡張ＣＤＳをＣＤＳ情報格納部３０６内に生成する。そして、ＨＴＴＰ Ｇｅｔ要求元のＩＰアドレスから、配信先コンテナー・ノードを作成し、配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを生成する。但し、既に同一のクライアントに配信中で、作成済みであれば、配信先コンテンツを作成する必要はない。

続いて、コンテンツ取得部３０３がプロバイダーにアクセスして、コンテンツ・データを取得する。ＣＤＳ情報生成部３０５は、取得したコンテンツ・データからコンテンツ詳細情報を抽出すると、配信中コンテンツ・ノードにこのコンテンツ詳細情報を保存し公開する。なお、コンテンツ詳細情報は、プロバイダーによって、別の専用のコマンドを発行することによって取得できる場合もあれば、コンテンツ・データに含まれている場合などがあり、後者の場合は、コンテンツ・データをデコードする際に抽出する必要がある。

そして、コンテンツ取得部３０３はプロバイダーからライブ・コンテンツのコンテンツ・データを一定量毎に取得し、コンテンツ提供部３０４はこれをＤＭＰに返す（配信する）。ＤＭＰ側では、コンテンツ復号部４０４が受け取ったデータをデコードし、コンテンツ再生出力部４０５が再生する。

ここで、ＤＭＰは、ＨＴＴＰ Ｇｅｔ要求を出し、ＤＭＳからライブ・コンテンツの配信が開始された段階で、配信中コンテンツ情報用拡張ＣＤＳに対するＣＤＳ：Ｂｒｏｗｓｅアクションを発行することにより、ＤＭＳが配信中で自身が再生しているライブ・コンテンツのコンテンツ詳細情報を取得し、表示に用いたりすることが可能である。ＤＭＰは、ＣＤＳ:Ｂｒｏｗｓｅアクションを発行する際、対象とする配信先コンテナー・ノードのＯｂｊｅｃｔＩＤを自身のＩＰアドレスから生成する（前述）。ＤＭＳ側では、ＣＤＳ情報提供部３０７は、ＣＤＳ：Ｂｒｏｗｓｅアクションを受け取ると、そのＯｂｊｅｃｔＩＤを基に、配信中コンテンツ情報用拡張ＣＤＳから該当する配信中コンテナー・ノードを特定して、そこに格納されているコンテンツ詳細情報を、ＤＭＰに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びＤＭＳからＤＭＳへのコンテンツ・データの配信とＤＭＰ側でのコンテンツのデコード及び再生が繰り返される。そして、ライブ・コンテンツの配信が終了すると、ＤＭＳ側では、配信中コンテンツ情報用拡張ＣＤＳのうち、該当する配信先コンテナー・ノード並びに配信中コンテンツ・ノードを、ＣＤＳ情報格納部３０６から破棄する。

このように、ＣＤＳ情報を拡張することにより、サービスや放送コンテンツを実際に受信しないとコンテンツ詳細情報を取得できない場合であっても、ＤＭＰがコンテンツ詳細情報を取得することが可能になる。

また、拡張内容は、単に配信中コンテンツ情報用拡張ＣＤＳを設けたのみで、使用するコマンド（アクション）のプロトコルを変更する必要はない。したがって、ＤＭＳ及びＤＭＰへの実装負担は大きくない。

また、図１３Ａ及び図１３Ｂには、３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがプロバイダーから取得したライブ・コンテンツを配信する場合の、ＤＭＲにおいてコンテンツ再生を行なう通信シーケンス例を示している。コンテンツ再生時において、ＤＭＳがライブ・コンテンツについてのコンテンツ詳細情報を配信中コンテンツ情報用拡張ＣＤＳに格納して、ＤＭＣに公開するという点で、図１０Ｂに示した通信シーケンス例とは相違する。

ＤＭＰがコンテンツ・ブラウジングを行なうための通信シーケンスは、図１０Ａと同様なので、ここでは図示を省略する。すなわち、コンテンツ・ブラウジングにおいては、ＤＭＣのＣＤＳ情報閲覧部５０２からＤＭＳに対して、ＣＤＳ：Ｂｒｏｗｓｅアクションが発行される。ＤＭＳ側では、ＣＤＳ情報生成部３０５が、該当するコンテンツを提供するプロバイダーからコンテンツ情報を取得して、ＣＤＳ情報を生成する。そして、ＣＤＳ情報提供部３０７は、生成されたＣＤＳ情報を、ＤＭＣに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

再生時には、ＤＭＣのコンテンツ再生要求部５０３が、ＤＭＲに対してＡＶＴ：ＳｅｔＡＶＴｒａｎｓｐｏｒｔＵＲＩ（）アクションを発行して、選択したコンテンツの属性情報を通知する。コンテンツ再生要求部５０３は、ＤＭＲに対してさらにＡＶＴ：Ｐｌａｙ（）アクションを発行して、コンテンツの再生開始を要求する。

ＤＭＲは、コンテンツの再生開始要求に応答して、コンテンツ取得部６０２が、ＨＴＴＰ Ｇｅｔメソッドを用いてコンテンツを要求する。ＤＭＳ側では、ライブ・コンテンツに対するＨＴＴＰ Ｇｅｔ要求を受けとると、まず、ＣＤＳ情報生成部３０５は、配信中コンテンツ情報用拡張ＣＤＳをＣＤＳ情報格納部３０６内に生成する。そして、ＨＴＴＰ Ｇｅｔ要求元のＩＰアドレスから、配信先コンテナー・ノードを作成し、配信先コンテナー・ノードの配下に配信中コンテンツ・ノードを生成する。但し、既に同一のクライアントに配信中で、作成済みであれば、配信先コンテンツを作成する必要はない。

続いて、コンテンツ取得部３０３がプロバイダーにアクセスして、コンテンツ・データを取得する。ＣＤＳ情報生成部３０５は、取得したコンテンツ・データからコンテンツ詳細情報を抽出すると、配信中コンテンツ・ノードにこのコンテンツ詳細情報を保存し公開する。なお、コンテンツ詳細情報は、プロバイダーによって、別の専用のコマンドを発行することによって取得できる場合もあれば、コンテンツ・データに含まれている場合などがあり、後者の場合は、コンテンツ・データをデコードする際に抽出する必要がある。

そして、コンテンツ取得部３０３はプロバイダーからライブ・コンテンツのコンテンツ・データを一定量毎に取得し、コンテンツ提供部３０４はこれをＤＭＲに返す（配信する）。そして、ＤＭＲ側では、コンテンツ復号部６０３が受け取ったデータをデコードし、コンテンツ再生出力部６０４が再生する。

ここで、ＤＭＣは、ＤＭＲがＨＴＴＰ Ｇｅｔ要求を出し、ＤＭＳからライブ・コンテンツの配信が開始された段階で、配信中コンテンツ情報用拡張ＣＤＳに対するＣＤＳ:Ｂｒｏｗｓｅアクションを発行することにより、ＤＭＳが配信中で自身が再生しているライブ・コンテンツのコンテンツ詳細情報を取得し、表示に用いたりすることが可能である。ＤＭＣは、ＣＤＳ：Ｂｒｏｗｓｅアクションを発行する際、対象とする配信先コンテナー・ノードのＯｂｊｅｃｔＩＤを自身のＩＰアドレスから生成する（前述）。ＤＭＳ側では、ＣＤＳ情報提供部３０７は、ＣＤＳ：Ｂｒｏｗｓｅアクションを受け取ると、そのＯｂｊｅｃｔＩＤを基に、配信中コンテンツ情報用拡張ＣＤＳから該当する配信中コンテナー・ノードを特定して、そこに格納されているコンテンツ詳細情報を、ＤＭＣに対してＣＤＳ Ｒｅｓｕｌｔとして返す。

コンテンツ・データのエンドに到達するまで、プロバイダーからのコンテンツ・データの取得及びＤＭＳからＤＭＳへのコンテンツ・データの配信とＤＭＰ側でのコンテンツのデコード及び再生が繰り返される。そして、ライブ・コンテンツの配信が終了すると、ＤＭＳ側では、配信中コンテンツ情報用拡張ＣＤＳのうち、該当する配信先コンテナー・ノード並びに配信中コンテンツ・ノードを、ＣＤＳ情報格納部３０６から破棄する。

このように、ＣＤＳ情報を拡張することにより、サービスや放送コンテンツを実際に受信しないとコンテンツ詳細情報を取得できない場合であっても、ＤＭＣがコンテンツ詳細情報を取得することが可能になる。

また、拡張内容は、単に配信中コンテンツ情報用拡張ＣＤＳを設けたのみで、使用するコマンド（アクション）のプロトコルを変更する必要はない。したがって、ＤＭＳ及びＤＭＣ、ＤＭＲへの実装負担は大きくない。

図１２並びに図１３から分かるように、本提案によれば、ＤＭＳが現在配信中のライブ・コンテンツに関するコンテンツ詳細情報をリアルタイムで受信し、クライアントに配信することにより、ＤＭＰやＤＭＲなどのクライアント側では、コンテンツを直接受信した場合と同様のコンテンツ詳細情報を表示することができる。すなわち、２−Ｂｏｘ Ｐｕｌｌ及び３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ライブ・コンテンツを配信する際のユーザビリティーを向上することができる。

以上、本明細書で開示する技術に係る特定の実施形態について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、ＤＬＮＡの２−Ｂｏｘ Ｐｕｌｌ及び３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅにおいて、ＤＭＳがライブ・コンテンツを配信する場合の実施形態を中心に説明してきたが、ＤＭＳが自身のストレージに保存するコンテンツを配信する場合であっても、同様に配信中コンテンツ情報用拡張ＣＤＳを生成して、コンテンツ詳細情報をクライアントに公開することができる。

また、本明細書では、本提案をＤＬＮＡの２−Ｂｏｘ Ｐｕｌｌ及び３−Ｂｏｘ Ｓｙｓｔｅｍ Ｕｓａｇｅに適用した実施形態を中心に説明してきたが、勿論、ＤＬＮＡ以外であっても、ＣＤＳ機能を実装するさまざまなタイプの通信システムに、同様に本提案を適用することができる。

要するに、例示という形態で本明細書で開示する技術を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

３０１…通信制御部
３０２…コンテンツ蓄積部
３０３…コンテンツ取得部
３０４…コンテンツ提供部
３０５…ＣＤＳ情報生成部
３０６…ＣＤＳ情報格納部
３０７…ＣＤＳ情報提供部
４０１…通信制御部
４０２…ＣＤＳ情報閲覧部
４０３…コンテンツ取得部
４０４…コンテンツ復号部
４０５…コンテンツ再生出力部
５０１…通信制御部
５０２…ＣＤＳ情報閲覧部
５０３…コンテンツ再生要求部
６０１…通信制御部
６０２…コンテンツ取得部
６０３…コンテンツ復号部
６０４…コンテンツ再生出力部

Claims (11)

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

Images