JP2008165594A - 再生装置およびデータ処理方法 - Google Patents

Abstract

【課題】ネットワークを通じてストリームデータを受信する再生装置において、自機で利用可能なストリームデータを容易かつ確実にユーザが選択できるようにする。
【解決手段】サーバ装置が送信可能なストリームデータの属性情報が受信されると、フラグ生成部３０９は、ストリームデータを利用してオーディオ再生装置３で実行可能な動作のそれぞれに対して、ストリームデータが対応しているか否かを示す対応情報をリスト化したフラグ一覧情報３１０を、属性情報を基に生成してメモリに記録する。この後、主制御部３０１は、例えばオーディオ再生装置３での再生に対応しているストリームデータをフラグ一覧情報３１０に基づいて抽出し、抽出したものを表示した選択画面を生成する。そして、選択画面に表示されたストリームデータのうちの１つを選択する操作入力情報を受け付けると、選択されたストリームデータの送信をサーバ装置に対して要求する。
【選択図】図６

Description

本発明は、ストリームデータを再生する再生装置、およびその再生装置におけるデータ処理方法に関し、特に、ストリームデータをネットワーク上のサーバ装置から受信して再生する再生装置およびそのデータ処理方法に関する。

近年、デジタルデータ化されたオーディオコンテンツやビデオコンテンツが広く流通し、これらを手軽に記録・再生する機器も一般的に普及している。また、ネットワーク技術の発達に伴い、家庭内においてもＬＡＮ（Local Area Network）や無線ＬＡＮなどのネットワークシステムを構築することが容易になっている。

そして、このような家庭内のネットワークシステムにおいて、機器間でデジタルコンテンツを容易にやり取りできるようにすることが望まれており、そのために機器間の接続やコンテンツ制御などの手順の規格化が進められている。その規格の代表例として、米マイクロソフト社が発表したＵＰｎＰ（Universal Plug & Play）が広く知られている。また、このＵＰｎＰをベースとしたＤＬＮＡ（Digital Living Network Alliance）ガイドラインが策定され、ＤＬＮＡガイドラインに準拠した機器の開発が現在進められている。

ＵＰｎＰでは、ネットワークに接続されるＵＰｎＰ機器を、コンテンツを提供するメディアサーバ（Media Server）と、制御端末装置として機能するコントロールポイント（Control Point）と、再生装置として機能するメディアレンダラ（Media Renderer）の３つに分類している。なお、コントロールポイントの機能は、メディアサーバとして動作する機器と、メディアレンダラとして動作する機器のどちらに実装されてもよい。

そして、これらの機能との間での通信手順を規定することで、ネットワーク上におけるＵＰｎＰ機器の探索や、再生動作などの制御を容易に行うことが可能となっている。例えば、この制御手順を利用することで、１つのメディアレンダラから、メディアサーバからのコンテンツデータの送受信を制御するだけでなく、他のメディアレンダラに対するコンテンツデータの送信制御を行うことも可能となる（例えば、特許文献１参照）。

ところで、オーディオデータやビデオデータなどのデジタルコンテンツにおいては、様々な符号化方式が存在している。このため、ネットワークを介してコンテンツが提供されるシステムにおいては、サーバ装置で提供可能なコンテンツの符号化方式と、クライアント装置で再生可能なコンテンツの符号化方式とは、必ずしも一致する訳ではない。

そこで、コンテンツ配信サーバから配信されるコンテンツを解析してその符号化条件を解析し、解析した符号化条件を一元的に保持する符号化条件サーバを配置し、クライアント端末からの要求に応じて所望のコンテンツの符号化条件を送信するようにしたネットワークシステムが考えられていた（例えば、特許文献２参照）。
特開２００５−２５０８６７号公報（段落番号〔００９０〕〜〔００９７〕、図７） 特開２００４−１２６３７０号公報（段落番号〔００４２〕〜〔００４８〕、図７）

上述したように、デジタルコンテンツには様々な符号化方式が存在するため、クライアント装置がネットワークを介してサーバ装置からコンテンツの提供を受ける場合には、クライアント装置で再生可能なコンテンツの提供を受ける必要があり、再生可能なコンテンツ、あるいはそのようなコンテンツを提供するサーバ装置を、クライアント装置において例えばユーザ操作によって選択する必要が生じる。また、サーバ装置では、同じ楽曲のコンテンツであっても、ファイル形式やサンプリング周波数、ビットレートなどの符号化仕様が異なる複数のデータを提供可能である場合もあり、この場合には、クライアント装置側での選択処理も煩雑になる。

特に、ネットワークを介してコンテンツが提供される場合、クライアント装置からサーバ装置に対してコンテンツの送信が要求され、その要求に応じてコンテンツが送信されるという手順が実行されるため、サーバ装置側の処理の混み具合やネットワーク上の伝送負荷の状態によっては、再生開始までに時間を要する場合も考えられる。このため、クライアント装置で、自機で対応していないコンテンツの提供を受けて再生エラーが生じ、別のコンテンツが選択されてあらためて提供を受けるような場合には、クライアント装置のユーザに対して大きな操作ストレスを与えてしまうことになり、また、ネットワークやサーバ装置に対しても余計な伝送負荷・処理負荷を与えてしまうことにもなる。

さらに、クライアント装置では、単にコンテンツを再生するだけでなく、その再生時のキュー／レビュー／一時停止などの動作や、提供されたコンテンツの記録動作、提供されたコンテンツのトランスコード動作などが行われる場合もあり、これらの動作に対応しているコンテンツが確実に選択される必要がある。しかし、提供されるコンテンツがこれらの動作に対応しているか否かをユーザがすべて把握していることは困難であり、そのような多機能のクライアント装置では、所望の動作の実行の際にユーザが操作ストレスを感じることがさらに多くなる可能性がある。

また、クライアント装置の内部においても、上記のような符号化仕様や機能に対する対応の可否は、内部の回路ブロックごとに一致していない場合も多い。このため、例えば、選択されたコンテンツを受信したときに、前段の回路ブロックがそのコンテンツの処理を開始しても、そこで処理されたデータを受けた後段の回路ブロックが処理できないといった事態が生じ、コンテンツの受信開始から時間を経た後にエラーが生じて、ユーザがさらに大きなストレスを与えることもあり得る。

本発明はこのような課題に鑑みてなされたものであり、自機で利用可能なストリームデータを容易かつ確実にユーザが選択することが可能な再生装置、およびこの再生装置でのデータ処理方法を提供することを目的とする。

本発明では上記課題を解決するために、ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信して再生する再生装置において、前記サーバ装置が送信可能な前記ストリームデータの属性情報を、前記サーバ装置から前記ネットワークを通じて受信する属性情報受信手段と、前記ストリームデータを利用して前記再生装置で実行可能な動作のそれぞれに対して、前記サーバ装置が送信可能な前記ストリームデータが対応しているか否かを示す対応情報をリスト化した対応情報リストを、前記属性情報受信手段により受信された前記属性情報を基に生成してメモリに記録するリスト生成手段と、前記再生装置で実行可能な動作のうちの１つに対応している前記ストリームデータを、前記対応情報リストに基づいて抽出し、抽出された前記ストリームデータのうち１つをユーザに選択させるための選択画面を生成する選択画面生成手段と、前記選択画面に表示した前記ストリームデータのうちの１つを選択する操作入力情報を受け付け、選択された前記ストリームデータの送信を前記サーバ装置に対して要求するデータ要求手段とを有することを特徴とする再生装置が提供される。

このような再生装置では、属性情報受信手段により、サーバ装置が送信可能なストリームデータの属性情報が、このサーバ装置からネットワークを通じて受信される。すると、リスト生成手段により、この属性情報を基に対応情報リストが生成されてメモリに記録される。対応情報リストは、ストリームデータを利用してこの再生装置で実行可能な動作のそれぞれに対して、サーバ装置が送信可能なストリームデータが対応しているか否かを示す対応情報をリスト化した情報である。この後、選択画面生成手段により、この再生装置で実行可能な動作のうちの１つに対応しているストリームデータが、対応情報リストに基づいて抽出され、抽出されたストリームデータのうち１つをユーザに選択させるための選択画面が生成される。そして、データ要求手段により、選択画面に表示されたストリームデータのうちの１つを選択する操作入力情報が受け付けられ、選択されたストリームデータの送信がサーバ装置に対して要求される。

本発明によれば、再生装置で実行可能な動作の１つを実行しようとする際に、対応情報リストを参照することで、その動作に対応しているストリームデータのみが選択画面に表示されてユーザに選択される。このため、所望の動作に対応しているストリームデータをユーザ自身が判断して選択することなく、サーバ装置から受信したストリームデータを利用した正常な動作を確実に実行することができる。

以下、本発明の実施の形態を図面を参照して詳細に説明する。以下の説明では、家庭内に形成されるＬＡＮシステム（ホームネットワークシステム）に本発明を適用した場合を想定する。また、このＬＡＮシステムを通じて送受信されるコンテンツデータの例として、オーディオデータを適用する。

［ホームネットワークの構成］
図１は、実施の形態に係るホームネットワークシステムの構成例を示す図である。
図１に示すホームネットワークシステムは、サーバ装置１および２と、オーディオ再生装置３〜５とが、ＬＡＮ６を通じて接続された構成となっている。

サーバ装置１および２は、例えばパーソナルコンピュータなどの情報処理装置や、オーディオコンテンツのレコーダなどであり、ＬＡＮ６への接続機能を備えるとともに、ＨＤＤ（Hard Disk Drive）などの大容量記憶媒体を備えている。そして、ＨＤＤに蓄積されているオーディオデータを、ＬＡＮ６を通じてオーディオ再生装置３〜５に対して提供することが可能となっている。オーディオ再生装置３〜５は、それぞれＬＡＮ６への接続機能を備えており、サーバ装置１および２からＬＡＮ６を通じて送信されるオーディオデータを受信して再生する。

なお、このホームネットワークシステムにおいては、実際には例えば、サーバ装置１および２とオーディオ再生装置３〜５とが図示しないブロードバンドルータにそれぞれ接続することにより、ＬＡＮシステムが形成される。この場合、ブロードバンドルータは、ＬＡＮ６上の機器に対するＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ機能およびＮＡＴ（Network Address Translation）機能を備え、これにより、ＬＡＮ６上の各機器が外部ネットワーク（ＷＡＮ：Wide Area Network）側の回線を共有できるようにもなっている。

以上のようなホームネットワークシステムでは、サーバ装置１および２は、オーディオデータを提供する情報提供装置としての機能を備え、オーディオ再生装置３〜５は、サーバ装置１および２からのオーディオデータの提供を受けて再生するクライアント装置（情報再生装置）としての機能を備えたものとなっている。そして、ユーザは、オーディオ再生装置３〜５のそれぞれを通じて、サーバ装置１または２が提供する異なったオーディオコンテンツを楽しむことが可能である。すなわち、オーディオ再生装置３〜５は、再生しようとするオーディオデータ（オーディオコンテンツ）に応じて、サーバ装置１および２のいずれか一方を、オーディオデータの配信元として選択することが可能となっている。

さらに、本実施の形態のオーディオ再生装置３〜５は、電子機器間の接続やコンテンツデータのやり取りを簡単に行うようにするため、例として、ＤＬＮＡ（Digital Living Network Alliance）が推奨するガイドラインに準拠した機器であるものとする。ＤＬＮＡガイドラインでは、電子機器の検出や制御、コンテンツデータの管理の手順として、米マイクロソフト社が発表したＵＰｎＰ（Universal Plug & Play）に標準で対応するよう求めている。

ＵＰｎＰは、１０／１００ＢＡＳＥ−Ｔのイーサネット（Ethernet，登録商標）を用いたネットワーク通信において代表的なＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２ネットワーク上で用いることが可能な、ＩＰ（Internet Protocol）およびＩＰ上のＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）などで構成されるプロトコル群とデータフォーマットの仕様であり、インターネット標準通信（ＴＣＰ／ＩＰ通信）における機能を拡充するものである。

そして、ＵＰｎＰをオーディオ再生装置などのいわゆるＣＥ（Consumer Electronics）機器に採用することにより、オーディオ再生装置などのＣＥ機器が、他のＣＥ機器やパーソナルコンピュータとの間で簡単に相互認証し、ネットワークを通じたサービスの提供や提供されたサービスの実行を、ユーザに面倒な作業をさせることなく、簡単かつ適正に行うことを可能にするものである。

［ＵＰｎＰの概要］
図２は、ＵＰｎＰのプロトコルスタック（プロトコル群の構造）について説明するための図である。

図２に示すように、ＵＰｎＰでは、実際のデータの送受信はインターネット標準通信プロトコルによって行われる。また、以下に説明するようなＵＰｎＰの独自の機能を実現するために、ＳＳＤＰ（Simple Service Discovery Protocol）、ＧＥＮＡ（General Event Notification Architecture）、ＳＯＡＰ（Simple Object Access Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）などのプロトコル群が用いられる。

さらに、ＵＰｎＰでは、図２に示すように、ベンダ定義（UPnP Vendor Defined）、ＵＰｎＰフォーラム作業委員会定義（UPnP Forum Working Committee Defined）、デバイス仕様（構造）定義（UPnP Device Architecture Defined）がなされることになっている。

そして、ＵＰｎＰは、アドレッシング（Addressing）、ディスカバリ（Discovery）、ディスクリプション（Description）、コントロール（Control）、イベンティング（Eventing）、プレゼンテーション（Presentation）の６つの機能を提供している。以下、ＵＰｎＰが提供する６つの機能について説明する。

オーディオ再生装置などのＵＰｎＰ機器（ＵＰｎＰが搭載された電子機器）では、ＵＰｎＰの機能を用いてオーディオデータを利用するために、ＵＰｎＰ・ＡＶ・アーキテクチャという規定に従うことなる。ＵＰｎＰ・ＡＶ・アーキテクチャにおけるＵＰｎＰ機器は、以下のように３種類に分類されている。

すなわち、ＵＰｎＰ・ＡＶ・アーキテクチャでは、ＵＰｎＰ機器を、コンテンツを提供するメディアサーバ（Media Server）と、制御端末装置として機能する（Control Point）と、再生装置として機能するメディアレンダラ（Media Renderer）との３つに分類している。ここで、メディアサーバは、ネットワークシステムにおいて一般にサーバ装置と呼ばれているものに相当し、メディアレンダラは、ネットワークシステムにおいて一般にクライアント装置と呼ばれているものに相当する。

また、コントロールポイント（制御装置）は、ネットワークに接続された各ＵＰｎＰ機器を制御することができるものである。コントロールポイントとしての機能は、メディアサーバにもメディアレンダラにも搭載することが可能であり、ネットワークを構成するすべての電子機器にコントロールポイントを搭載することも、また、ネットワークを構成する任意の電子機器にコントロールポイントを搭載することも可能となっている。本実施の形態では、オーディオ再生装置３〜５のそれぞれにコントロールポイントとしての機能が搭載されているものとする。

また、ＵＰｎＰにおけるアドレッシングは、各ＵＰｎＰ機器が、ＩＥＥＥ８０２ネットワーク上で自機を特定するためのアドレスを取得する機能であり、ＤＨＣＰまたはＡｕｔｏ−ＩＰが用いられる。

ディスカバリは、アドレッシングの後に行われ、これによりコントロールポイントは、コントロールしたいターゲット機器（メディアサーバまたはメディアレンダラ）を発見することができる。ここで用いられるプロトコルは、上述のＳＳＤＰである。ネットワークシステムを構成する各電子機器は、ＩＥＥＥ８０２ネットワークに接続されたときに、自分自身が備えるデバイスやサービスを通知するメッセージを、ＩＥＥＥ８０２ネットワーク上にブロードキャストする。コントロールポイントは、このブロードキャストされたメッセージを受信することで、ＩＥＥＥ８０２ネットワークにどのような機器が接続されたかを知ることができる。

ディスカバリによって、コントロールポイントが発見したコントロール対象の電子機器が出力したＳＳＤＰパケットには、デバイスディスクリプション（Device Description）のＵＲＬ（Uniform Resource Locator）が記述されている。コントロールポイントは、そのＵＲＬにアクセスすることにより、その電子機器のさらに詳しいデバイス情報をデバイスディスクリプションから取得することができる。

このデバイス情報には、アイコン情報、モデル名、生産者名、商品名や、そのデバイスが有するサービスの詳しい情報が記載されているサービスディスクリプション（Service Description）などが記述されている。コントロールポイントは、これらのデバイスディスクリプションやサービスディスクリプションから、ターゲット機器に対するアクセスの方法を知ることができる。デバイスディスクリプションやサービスディスクリプションは、ＸＭＬ（eXtensible Markup Language）で表現されている。

コントロールの機能は、アクション（Action：実行）とクエリ（Query：問い合わせ）の２つの機能に大きく分類される。アクションは、サービスディスクリプションのアクション情報に規定された方法で行われ、アクションを実施（Invoke）することによって、コントロールポイントはターゲット機器を操作することができる。クエリは、サービスディスクリプションの機器情報の値を取り出すために用いられる。コントロールでは、上述のＳＯＡＰというトランスポートプロトコルが利用され、その表現としてはＸＭＬが用いられる。

イベンティングは、機器情報の値が変更されたとき、そのことをターゲット機器からコントロールポイントに通知させるために用いられる。このイベンティングでは、上述のＧＥＮＡというトランスポートプロトコルが利用され、その表現としてはＸＭＬが用いられる。プレゼンテーションは、ユーザにユーザインタフェースを用いたコントロール手段を提供するために用いられる。

各ＵＰｎＰ機器は、以上のようなＵＰｎＰ機能を用いることにより、ユーザに複雑な操作を求めることなく、ネットワークに参加し、通信が行える状態になるだけでなく、他のＵＰｎＰ機器の検出や接続までも自動的に行うことができるようにされる。

図３は、メディアサーバに格納されたコンテンツを管理するツリー構造の例を示す図である。
ＵＰｎＰ機器であるメディアサーバには、ＣＤＳ（Contents Directory Service）という機能（Service）が組み込まれており、メディアサーバはこの機能により、コントロールポイントに対して、メディアサーバにどのようにコンテンツが格納されているかを通知する。ＣＤＳには、コンテナ（Container）とアイテム（Item）という二つの抽象化されたオブジェクト（Object）があり、これらはいわば、米マイクロソフト社が提供するＯＳ（Operating System）であるＷＩＮＤＯＷＳ（登録商標）におけるフォルダ（Folder）とファイル（File）に相当する。コンテナとアイテムは、図３に示すように常にツリー構造を作ることになっている。

なお、本実施の形態では、メディアサーバから送信可能なオーディオデータが、図３におけるアイテムに対応している。ただし、後述するように、アイテムは必ずしも１つのストリームデータに対応している訳ではなく、送信可能な複数のストリームデータに対応している場合もある。

コントロールポイントは、図３に示したツリー構造をメディアサーバから取得することにより、各コンテンツのＵＲＬ（情報が書いてあるリンク（Link））を得ることができる。そして、所望のオーディオコンテンツ（アイテム）の情報が取得できた場合、メディアサーバのＡＶトランスポート（ＡＶ Transport）という機能を用いてオーディオコンテンツの再生や停止など、オーディオトラック（オーディオデータ）についての操作を行うことができるようにされる。

本実施の形態のサーバ装置１および２とオーディオ再生装置３〜５のそれぞれは、上述のように、ＵＰｎＰのアドレッシング機能を用いて、ＴＣＰ／ＩＰの通信が可能な状態になり、ＵＰｎＰのディスカバリ機能を用いてお互いの機器認証を行う。これによって、各機器は、ネットワークの構成を把握し、目的とする電子機器との間で通信を行うことができるようにされる。

［サーバ装置の構成例］
次に、本実施の形態のホームネットワークシステムを構成する各電子機器の構成例について説明する。

図４は、サーバ装置のハードウェア構成を示すブロック図である。なお、ここでは例としてサーバ装置１の構成について説明するが、サーバ装置２も同様のハードウェア構成により実現できる。

図４に示すように、サーバ装置１は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、ＨＤＤ１４、入力インタフェース（Ｉ／Ｆ）１５、グラフィック処理部１６、および通信インタフェース（Ｉ／Ｆ）１７を備え、これらは内部バス１８を介して相互に接続されている。

ＣＰＵ１１は、このサーバ装置１全体に対する制御をつかさどる。ＲＯＭ１２には、ＣＰＵ１１において実行するプログラムや処理に必要なデータなどが記録されている。ＲＡＭ１３は、主に各種の処理において作業領域として用いられるものである。

ＨＤＤ１４は、多数のデジタルコンテンツ（提供情報）などを蓄積することが可能な容量を持っている。また、ＨＤＤ１４は、ＣＰＵ１１により実行される各種のプログラムや処理用のデータなどを保持するとともに、コンテンツのトランスコードやコンテンツをＬＡＮ６を通じて他の機器に送信する際などに作業領域としても用いられる。

本実施の形態では、ＨＤＤ１４には、オーディオ再生装置３〜５に対してオーディオデータを送信する、ＤＬＮＡガイドラインに準拠したサーバとして機能するためのサーバプログラムが格納されて、ＣＰＵ１１により実行される。また、このサーバプログラムの機能としては、ＨＤＤ１４に格納されたオーディオデータの符号化方式やサンプリングレート、量子化レートなどを変換するトランスコード機能を含んでもよい。

入力Ｉ／Ｆ１５には、例えばキーボードやマウスなどの入力装置１５ａが接続されている。この入力Ｉ／Ｆ１５は、入力装置１５ａからの信号を、内部バス１８を介してＣＰＵ１１に送信する。

グラフィック処理部１６には、例えばＬＣＤ（Liquid Crystal Display）などの表示装置１６ａが接続されている。このグラフィック処理部１６は、ＣＰＵ１１からの命令に従って、表示装置１６ａの画面上に画像を表示させる。

通信Ｉ／Ｆ１７は、図示しないＬＡＮケーブルを介してＬＡＮ６に接続し、他の機器との間でデータの送受信を行う。
［オーディオ再生装置の構成例］
図５は、オーディオ再生装置のハードウェア構成を示すブロック図である。なお、ここでは例としてオーディオ再生装置３の構成について説明するが、オーディオ再生装置４および５も同様のハードウェア構成により実現できる。

図５に示すように、オーディオ再生装置３は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、フラッシュメモリ３４、入力インタフェース（Ｉ／Ｆ）３５、入力部３５ａ、グラフィック処理部３６、表示部３６ａ、通信インタフェース（Ｉ／Ｆ）３７、オーディオＣＯＤＥＣ（Coder／Decoder）３８、Ｄ／Ａ変換部３９、オーディオアンプ４０、およびスピーカ４１を備えている。これらのうち、スピーカ４１を除く各ブロックは、内部バス４２を介して接続されている。

ＣＰＵ３１は、このオーディオ再生装置３全体に対する制御をつかさどる。ＲＯＭ３２には、ＣＰＵ３１において実行するプログラムや処理に必要なデータなどが記録されている。ＲＡＭ３３は、主に各種の処理において作業領域として用いられるものである。なお、これらのＣＰＵ３１、ＲＯＭ３２、およびＲＡＭ３３は、マイクロコンピュータとして実現されてもよい。フラッシュメモリ３４は、書き換え可能な不揮発性メモリであり、例えば、オーディオ再生装置３の電源が落とされても保持しておくべき種々のデータが記録されるものである。

入力Ｉ／Ｆ３５は、入力部３５ａからの信号を、内部バス４２を介してＣＰＵ３１に送信する。入力部３５ａには、操作キーなどの各種入力スイッチが設けられている。グラフィック処理部３６は、ＣＰＵ３１からの命令に従って、表示部３６ａの画面上に画像を表示させる。表示部３６ａは、例えばＬＣＤなどから構成される。

通信Ｉ／Ｆ３７は、図示しないＬＡＮケーブルを介してＬＡＮ６に接続し、他の機器との間でデータの送受信を行う。また、通信Ｉ／Ｆ３７は、ＬＡＮ６を通じて受信したパケットからオーディオ符号化データを抽出し、オーディオＣＯＤＥＣ３８に直接受け渡すことが可能になっている。

オーディオＣＯＤＥＣ３８は、通信Ｉ／Ｆ３７から受信したオーディオ符号化データをデコードする機能を備える。このオーディオＣＯＤＥＣ３８は、例えば、ＭＰ３（Moving Picture Experts Group−Audio Layer 3）などの圧縮符号化方式のオーディオデータをデコード可能となっている。また、ＬＰＣＭ（Linear Pulse Code Modulation）方式のオーディオデータが入力された場合には、そのまま後段のＤ／Ａ変換部３９に出力することが可能となっている。さらに、通信Ｉ／Ｆ３７から入力された、あるいはフラッシュメモリ３４などから内部バス４２を介して入力されたオーディオデータを、符号化方式やサンプリング周波数、ビットレートなどの符号化仕様が異なるデータに変換するトランスコード機能も備えている。なお、このようなオーディオＣＯＤＥＣ３８の機能は、ＣＰＵ３１においてソフトウェアが実行されることで実現されてもよい。

Ｄ／Ａ変換部３９は、オーディオＣＯＤＥＣ３８から供給されたデジタルオーディオデータを、アナログオーディオ信号に変換する。オーディオアンプ４０は、Ｄ／Ａ変換部３９から供給されたアナログオーディオ信号を所定のレベルに増幅し、これをスピーカ４１に供給する。これにより、スピーカ４１からは、これに供給されたアナログオーディオ信号に応じた音声が再生出力される。

［オーディオ再生装置におけるコンテンツ利用動作］
上記のホームネットワークシステムでは、サーバ装置１および２が、ＵＰｎＰにおけるメディアサーバとして機能し、これらのサーバ装置１および２のＨＤＤ１４には、オーディオ再生装置３〜５に対して提供されるコンテンツのデータが蓄積されている。そして、サーバ装置１および２は、メディアサーバとして機能するためのプログラムを実行することで、オーディオ再生装置３〜５からの要求に応じて、自身が保持するコンテンツのデータや、それらのコンテンツに関する属性情報などを、オーディオ再生装置３〜５に対して返送する。

本実施の形態では、コンテンツの例としてオーディオのデータが、サーバ装置１および２からオーディオ再生装置３〜５に対して提供されるものとする。また、これらのサーバ装置１および２からは、例えば、ＬＰＣＭ、ＭＰ３、ＡＴＲＡＣ（Adaptive Transform Acoustic Coding、ソニー株式会社の登録商標）など、複数の異なる符号化方式のオーディオデータが提供されてもよい。さらに、同じ符号化方式であっても、サンプリング周波数やビットレートなどの仕様が異なるオーディオデータが存在する場合もある。

また、同じ楽曲（すなわち、同じアーティストによる同じタイトルのオーディオコンテンツ）でも、符号化仕様が異なるオーディオデータが提供可能である場合もある。特に、ＤＬＮＡガイドラインでは、オーディオデータのファイル形式としてＬＰＣＭを標準で採用することが推奨されている。このため、サーバ装置１および２では、ある楽曲の当初のデータ（トランスコードされていないオリジナルの符号化データ。以下、オリジナル符号化データと呼ぶ。）がＭＰ３などの圧縮データである場合に、その当初のＭＰ３形式のデータに加えて、これをトランスコードしたＬＰＣＭ形式のオーディオデータも提供されることが考えられる。

また、提供される各オーディオデータには、例えば、再生時にキュー／レビュー／一時停止などの操作（以下、特殊再生操作と呼ぶ）が可能か否か、そのデータをクライアント装置に保存可能であるか否か、そのデータを可搬型記録媒体にコピー可能であるか否か、そのデータをクライアント装置でトランスコード可能であるか否かといった他の属性が付加されている場合もある。

一方、オーディオ再生装置３〜５では、サーバ装置１および２から提供されるすべての符号化方式のオーディオデータを、必ずしも再生できるとは限らない。すなわち、各オーディオ再生装置３〜５において、どのような符号化方式のオーディオデータを再生可能であるか、また、どのような属性に対応しているかについては、各オーディオ再生装置３〜５の能力に依存することになる。

そこで、本実施の形態のオーディオ再生装置３〜５では、オーディオデータの提供を要求するのに先立って、サーバ装置１および２から提供可能なオーディオデータの属性情報を取得し、自機が対応している符号化仕様や属性の情報と比較して、それらの対応状態をフラグ化したフラグ情報として保持しておく。そして、オーディオデータをユーザに選択させる際や、提供されたオーディオデータを処理する際にそのフラグ情報を参照することで、ユーザが特に意識することなく、自機が対応しているオーディオデータのみが確実に選択され、そのデータを処理できるようにする。

図６は、オーディオ再生装置が備える主な機能を示すブロック図である。
なお、この図６では例として、オーディオ再生装置３の機能について説明し、以降の説明では、このオーディオ再生装置３とサーバ装置１との間の処理について述べることとする。言うまでもなく、他のオーディオ再生装置４および５についてもオーディオ再生装置３と同様の機能を備えていてよく、また、各オーディオ再生装置３〜５がサーバ装置２との間で、以下で説明する処理を実行することも可能である。

オーディオ再生装置３は、主制御部３０１、通信制御部３０２、ユーザインタフェース（Ｕ／Ｉ）制御部３０３、再生制御部３０４、ダウンロード制御部３０５、トランスコード制御部３０６、およびコンテンツ情報抽出部３０７を備えている。

主制御部３０１は、オーディオ再生装置３の全体の動作を統括的に制御するブロックであり、Ｕ／Ｉ制御部３０３を通じて受け取った操作入力情報に応じて、他の各ブロックに対して動作を制御する信号を出力する。このとき、後述するフラグ情報を参照することができる。

通信制御部３０２は、ＬＡＮ６を通じた通信処理を制御するブロックであり、本実施の形態では、主制御部３０１からの要求に応じて、ＵＰｎＰで規定された通信手順を実行することが可能となっている。

Ｕ／Ｉ制御部３０３は、入力部３５ａに対するユーザの入力操作を入力Ｉ／Ｆ３５を通じて検知して、その入力操作に応じた操作入力情報を主制御部３０１に出力する。また、主制御部３０１からの制御情報に従って、例えば、サーバやコンテンツの選択時、コンテンツの再生やダウンロードなどの操作時など、場面に応じた表示情報を生成してグラフィック処理部３６に出力し、表示情報に応じた画像を表示部３６ａに表示させる。

再生制御部３０４は、主制御部３０１による制御の下で、ＬＡＮ６を通じて受信されたオーディオデータの再生動作を制御する。例えば、通信制御部３０２の制御により受信されたオーディオデータをオーディオＣＯＤＥＣ３８に供給して、そのデコード動作や後段のＤ／Ａ変換部３９の動作を制御する。

ダウンロード制御部３０５は、オーディオ再生装置３で保存可能なオーディオデータが受信された場合に、そのオーディオデータをフラッシュメモリ３４に格納する処理を制御する。

トランスコード制御部３０６は、フラッシュメモリ３４内に格納されたオーディオデータをオーディオＣＯＤＥＣ３８に供給し、主制御部３０１から指定された別の符号化方式に変換するようにオーディオＣＯＤＥＣ３８を制御する。

コンテンツ情報抽出部３０７は、サーバ装置１から送信されたコンテンツの属性情報から必要な情報を抽出して、属性情報３０８としてＲＡＭ３３などに格納する。また、このコンテンツ情報抽出部３０７は、上述したフラグ情報を生成するフラグ生成部３０９を備えている。

フラグ生成部３０９は、サーバ装置１からの属性情報を基に、受信したオーディオデータを利用してこのオーディオ再生装置３で実行可能な様々な動作のそれぞれに対して、オーディオデータが対応しているか否かを示す複数のフラグ情報を生成し、それらのフラグ情報をリスト化したフラグ一覧情報３１０としてＲＡＭ３３などに格納する。

また、フラグ生成部３０９は、このオーディオ再生装置３において再生可能なオーディオデータの符号化方式などの仕様を示す再生仕様情報３１１を、ＲＯＭ３２またはフラッシュメモリ３４などにあらかじめ保持している。そして、この再生仕様情報３１１を参照してフラグ一覧情報３１０を生成することで、サーバ装置１から送信されるオーディオデータがオーディオ再生装置３において再生可能か否かを判断し、再生可能であるオーディオデータをフラグ一覧情報３１０において識別可能であるようにしている。例えば、再生可能なオーディオデータについてのフラグ情報のみを、フラグ一覧情報３１０として記録する。

なお、属性情報３０８およびフラグ一覧情報３１０は、ともにオーディオ再生装置３内に一時的に保持される情報とされればよいが、例えば、オーディオ再生装置３が再生レジューム機能に対応している場合には、最後に再生されていたオーディオデータに対応する属性情報３０８およびフラグ一覧情報３１０を、フラッシュメモリ３４などの不揮発性記憶媒体に保存して、その後の再生時に利用できるようにしてもよい。

次に、属性情報３０８およびフラグ一覧情報３１０の内容について具体的に説明する。上述したように、ＵＰｎＰにおけるメディアサーバにはＣＤＳ機能が組み込まれており、オーディオ再生装置３はこの機能を利用して、オーディオデータを取得するためのロケーション情報や、コンテンツなどの属性情報（メタデータ）をＸＭＬデータとして取得することができる。

図７は、ＣＤＳ機能により取得可能な属性情報の一例を示す図である。
オーディオ再生装置３では、通信制御部３０２の制御により“ブラウズ（Browse）”と呼ばれるアクションを実行することで、サーバ装置１が管理しているコンテンツのツリー構造の中のオブジェクトに関する属性情報を、ＸＭＬデータとしてそのサーバ装置１から取得することができる。図７では、サーバ装置１においてアルバム名ごとに楽曲のデータが管理されている場合の例を示しており、あるコンテナの属性情報１０１の一例として、このコンテナに付与されたタイトル名（dc:title）、アーティスト名（upnp:artist）、アルバム名（upnp:album）が記載されている。

また、このコンテナのロケーション情報（ＵＲＬ）が得られた状態で、このコンテナの子階層の情報を要求するためのアクション（“Browse Direct Children”と呼ばれる）を実行したとき、その子階層にアイテムが含まれている場合には、そのアイテムの属性情報を得ることができる。図７では、このときに得られる子階層のアイテムの属性情報１０２および１０３の一例として、アイテムごとのユニークなアイテムＩＤ、各アイテムに付与されたタイトル名（dc:title）、アーティスト名（upnp:artist）、アルバム名（upnp:album）を示している。なお、この例ではアイテムのタイトル名は楽曲名に相当し、１つのアイテムＩＤに１つの楽曲が対応付けられる。

さらに、図７の例では、属性情報１０２および１０３の中に、“レス（res：Resource Encoding Characteristics properties）”と呼ばれる符号化特性を示す情報が記載されている。レス情報は、階層構造の中のアイテムに対してのみ付加することが可能な属性情報であり、このレス情報には、例えば図７に示すように、同じ楽曲に対して符号化方式が異なるオーディオデータをサーバ装置１が送信可能である場合に、これらのオーディオデータのロケーション情報を記述することができる。また、図示しないが、それらの各オーディオデータについての符号化仕様や再生動作などに関するより詳細な情報を記述することもできる。

なお、レス情報に記載される各オーディオデータは、あくまでサーバ装置１がクライアント機器に対して送信可能なデータであって、これらのすべてのデータの実体が必ずしもサーバ装置１内に記憶されていなくてもよい。例えば、レス情報に記述されたもののうち１つのオーディオデータ（例えばオリジナル符号化データ）のみがサーバ装置１に記憶されており、同じアイテムに記述されたそれ以外のオーディオデータのロケーション情報に対してクライアント機器からのアクセスを受けたときに、対応するオーディオデータを、記憶されているオーディオデータをトランスコードすることによって生成し、クライアント機器に送信してもよい。

図８は、フラグ一覧情報の例を示す図である。
フラグ一覧情報３１０では、複数の項目に対応するフラグ情報の組が、アイテムごとに付与される。ただし、１つのアイテムに対してサーバ装置１が複数の異なる符号化仕様のオーディオデータを送信可能な場合（すなわち、アイテムの属性情報内に複数のレス情報が含まれる場合）には、後述する処理により、基本的に最も品質が高いと考えられる、最適な１つのオーディオデータが選択されて、そのオーディオデータについてのフラグ情報のみが格納される。

図８では、フラグ一覧情報３１０に格納されるフラグ情報の例として、音楽ファイルか否かを示すフラグＦＬ１、オーディオ再生装置３での再生が可能か否かを示すフラグＦＬ２、再生時にキュー／レビューの操作が可能なデータであるか否かを示すフラグＦＬ３、再生時に一時停止が可能なデータであるか否かを示すフラグＦＬ４、再生装置側でのダウンロード（データ保存）が可能なデータであるか否かを示すフラグＦＬ５、トランスコードが可能なデータであるか否かを示すフラグＦＬ６、オリジナル符号化データであるか否かを示すフラグＦＬ７が示されている。すなわち、この例では、オーディオ再生装置１は、オーディオデータの再生時のキュー／レビュー／一時停止の機能、オーディオデータを保存（ダウンロード）する機能、保存したオーディオデータをトランスコードする機能を備えており、フラグ一覧情報３１０を参照することで、サーバ装置１から送信されるコンテンツのデータがこれらの機能に対応しているか否かを判別できるようになっている。

ここで示したフラグＦＬ１〜ＦＬ７に対する設定値は、レス情報に記述される情報を基に判定できる。フラグＦＬ１については、ＭＩＭＥ（Multipurpose Internet Mail Extension）タイプ情報などを基に判定できる。フラグＦＬ２については、符号化方式、サンプリング周波数、ビットレート、チャネル数、暗号化方式などを基に判定できる。

フラグＦＬ３については、再生経過時間あるいは先頭からのデータサイズにより指定された場所からの再生（すなわちサーバ装置１からの送信）が可能であるか否かを示すシーク（seek）フラグ、トータル再生時間、ファイルサイズなどを基に判定できる。フラグＦＬ４については、フラグＦＬ３で挙げた情報の他、著作権保護情報などを基に判定できる。フラグＦＬ５〜ＦＬ７については、これらの可否を示すレス情報内のフラグ情報を基に判定できる。

一方、属性情報３０８として記憶される情報は、基本的に、オーディオデータをオーディオ再生装置３内で利用する際の手順において必要とされる情報であり、そのような情報を主制御部３０１が読み込みやすいように、元のＸＭＬデータから抽出してオーディオデータごとに対応付けたものである。このような情報としては、例えば、再生やダウンロードのためにオーディオデータにアクセスするための情報や、データの選択時や再生動作中などに表示部３６ａに表示させるための情報などがある。

より具体的には、例えば、オーディオデータに対応するアイテムＩＤ、ロケーション情報（ＵＲＬ）、タイトル名（楽曲名）、アーティスト名、アルバム名、トータル再生時間、ファイルサイズ、符号化方式、サンプリング周波数、ビットレート、チャネル数、著作権保護情報などが記録される。

図９は、コンテンツ情報抽出部における情報抽出処理の手順を示すフローチャートである。
〔ステップＳ１１〕まず、コンテンツ情報抽出部３０７は、通信制御部３０２によって受信された、コンテンツの属性を示すＸＭＬデータのうち、１つのアイテムについてのデータを読み込む。なお、受信された属性情報がアイテムのものであることは、例えば、属性情報の記述が、アイテムに関する情報であることを示す“<item>”から始まっていること、または、属性情報においてクラス属性を示す“<upnp:class>”がアイテムを示していることによって判断できる。

〔ステップＳ１２〕フラグ生成部３０９は、読み込んだデータ中に複数のレス情報が記述されているか否かを判別し、複数記述されている場合には、符号化仕様の異なる複数のオーディオデータが存在すると判断して、ステップＳ１３の処理を実行する。また、１つのレス情報のみ記述されている場合には、ステップＳ１４の処理を実行する。

〔ステップＳ１３〕フラグ生成部３０９は、レス情報に記述された複数のオーディオデータのうち、最適なデータを選択する。
このステップでは、まず、レス情報に含まれる符号化仕様に関する情報と、再生仕様情報３１１に記憶された、オーディオ再生装置３において再生可能な符号化仕様とを比較して、オーディオ再生装置３において対応しているオーディオデータのみを抽出する。なお、比較される符号化仕様の情報は、例えば、符号化方式、サンプリング周波数、ビットレート、チャネル数、著作権保護情報などである。また、再生仕様情報３１１に記憶される情報は、このオーディオ再生装置３に設けられた各デバイス（オーディオＣＯＤＥＣ３８、Ｄ／Ａ変換部３９、各種メモリなど）や処理機能（例えば、特殊再生のための制御機能、著作権保護のための制御機能など）の能力に応じて決定される。

次に、抽出された再生可能なオーディオデータのうち、最も高品質と考えられるものを１つだけ選択する。この選択処理では、例えば、オーディオデータがトランスコードされたデータであるか否かを示すフラグ情報をレス情報から抽出し、トランスコードされていないオリジナル符号化データを、最も高品質のものとして優先的に選択する。また、オリジナル符号化データが存在しない場合には、サンプリング周波数およびビットレートの高いオーディオデータを選択する。符号化方式についても、優先的に選択するものを決めておいてもよい。

〔ステップＳ１４〕フラグ生成部３０９は、ステップＳ１２およびＳ１３の処理により特定された１つのオーディオデータについてのレス情報などを基に、図８に示したような項目に対するフラグの値を設定して、フラグ一覧情報３１０を生成し、ＲＡＭ３３に格納する。各フラグＦＬ１〜ＦＬ７に対する設定値の判定基準については、上述した通りである。また、フラグＦＬ２の設定値の判定時には、再生仕様情報３１１が参照されて、オーディオデータの符号化仕様との比較が行われる。

なお、上記のステップＳ１３において、複数のオーディオデータの中に、オーディオ再生装置３において再生可能なものが１つも存在しなかった場合には、ステップＳ１４において、例えば、フラグ一覧情報３１０内のそのアイテムに対応する項目において、フラグＦＬ２を再生不可を示すようにし、その他のフラグをすべて“ＮＵＬＬ”として、有効な属性情報が存在しないことを示すようにすればよい。

〔ステップＳ１５〕コンテンツ情報抽出部３０７は、上記のステップＳ１２およびＳ１３の処理により特定された１つのオーディオデータについての必要な属性情報を、ステップＳ１１で読み込んだ情報から抽出し、属性情報３０８としてＲＡＭ３３に格納する。

〔ステップＳ１６〕コンテンツ情報抽出部３０７は、サーバ装置１から受信したすべてのアイテムの属性情報について、上記のステップＳ１１〜Ｓ１５の処理を実行したか否かを判定する。処理が完了していない場合には、次のアイテムについての属性情報を読み込み、ステップＳ１１からの処理を再実行する。そして、すべてのアイテムについて処理が完了するまで、上記処理を繰り返す。

次に、上記処理により生成されたフラグ一覧情報３１０を利用した処理について、具体的に説明する。まず、所望のコンテンツを選択して、そのコンテンツのデータをサーバ装置１から受信して再生する場合の処理について説明する。

図１０は、オーディオ再生装置でのコンテンツ再生時の処理手順の例を示すフローチャートである。
〔ステップＳ２１〕オーディオ再生装置３では、ＬＡＮ６に接続されると、サーバ装置を探索する処理が実行される。

まず、オーディオ再生装置３がＬＡＮ６に接続されると、通信制御部３０２により自身のネットワークアドレスが取得された後、主制御部３０１は、サーバ装置を探索するように通信制御部３０２に要求する。通信制御部３０２は、ＵＰｎＰで規定されたサーチメッセージをＬＡＮ６上にマルチキャストする。ＬＡＮ６上のサーバ装置１および２は、サーチメッセージに応答して、自身を特定するＩＤや、デバイスディスクリプションを取得するためのＵＲＬなどを返信する。

通信制御部３０２は、以上の手順で探索されたサーバ装置１および２に関する情報を主制御部３０１に送信し、主制御部３０１は、サーバ装置１および２を選択するための画面を表示させるようにＵ／Ｉ制御部３０３に指示する。これにより、表示部３６ａには、探索されたサーバ装置１および２の名前などが一覧表示され、ユーザからの選択入力を待機する状態となる。

〔ステップＳ２２〕オーディオ再生装置３では、サーバ装置を選択するためのユーザによる入力操作に応じて、選択されたサーバ装置（ここではサーバ装置１とする）からコンテンツの属性情報を得るための処理が実行される。

ここでは、主制御部３０１は、サーバ装置１が選択されたことをＵ／Ｉ制御部３０３を介して検出すると、そのサーバ装置１からデバイスディスクリプションを取得するように、通信制御部３０２に要求する。通信制御部３０２は、対応するＵＲＬにアクセスしてＧＥＴコマンドによりデバイスディスクリプションを受信した後、サーバ装置１でコンテンツを管理している階層構造のルートのロケーションを得て、そのルートの子階層についての属性情報（メタデータ）を要求する。

この要求に対する応答から、子階層にコンテナのみ含まれる場合には、そのコンテナの情報を主制御部３０１に送信する。主制御部３０１は、それらのコンテナをユーザに選択させるための画面表示をＵ／Ｉ制御部３０３に要求する。これにより、コンテナに付与された名前が表示部３６ａに一覧表示され、ユーザはこれらから１つを選択する操作を行う。主制御部３０１は、選択されたコンテナの子階層の属性情報を取得するように、通信制御部３０２に対して要求する。

このような手順が繰り返されることにより、子階層の属性情報が順次得られる。一般的には、ルートの子階層のコンテナはアーティストごとに設けられ、さらにその子階層のコンテナはアルバムごとに設けられ、そのコンテナの子階層に、楽曲に対応するアイテムが存在する。なお、オーディオ再生装置３から、アーティストなどの検索条件を指定して、その条件に応じた階層構造に従ってアイテムを探索することもできる。

以上の処理により、子階層にアイテムが存在した場合には、そのアイテムの属性情報がＸＭＬデータとして取得される。上述したように、本実施の形態では、アイテムはコンテンツ（ここでは楽曲）に対応しており、１つのアルバムに対応するコンテナの子階層に含まれるアイテムの属性情報が一度に取得される。

〔ステップＳ２３〕サーバ装置１から取得された、アイテムの属性情報のＸＭＬデータは、通信制御部３０２からコンテンツ情報抽出部３０７に引き渡される。そして、コンテンツ情報抽出部３０７は、この情報を基に、フラグ一覧情報３１０を生成してＲＡＭ３３に記憶し、さらに、属性情報３０８も記憶する。なお、これらの情報の生成・記憶処理手順は、図９で説明した通りである。

〔ステップＳ２４〕オーディオ再生装置３では、フラグ一覧情報３１０を基に、再生対象のオーディオデータのタイトル名などが表示部３６ａに一覧表示され、再生するコンテンツの選択操作が待機される。

主制御部３０１は、フラグ一覧情報３１０のフラグＦＬ２に基づき、オーディオ再生装置３において再生可能なアイテム（ここでは１つのオーディオデータに対応）を抽出する。そして、そのアイテム（すなわち楽曲）のタイトルやアーティスト名などを属性情報３０８から抽出し、それらを一覧表示した選択画面を表示させるように、Ｕ／Ｉ制御部３０３に要求する。なお、このときに表示部３６ａに表示される楽曲選択画面については、後の図１１で説明する。

〔ステップＳ２５〕主制御部３０１は、楽曲の選択情報をＵ／Ｉ制御部３０３を介して受け取ると、その楽曲に対応するオーディオデータの再生を要求するために必要な情報（ロケーション情報）を、属性情報３０８から取得し、その情報を通信制御部３０２に対して転送して、そのオーディオデータの送信要求処理を実行させる。ここで、属性情報３０８には、１つのアイテム（すなわち楽曲）について最適な１つのオーディオデータに関する情報だけが記憶されているので、楽曲の選択情報により属性情報３０８から取得するロケーション情報は一意に決まることになる。

通信制御部３０２は、受け取ったロケーション情報にアクセスしてオーディオデータの送信を要求するアクションを実行する。なお、実際には、属性情報３０８に基づいて、選択されたオーディオデータに関するより詳細な属性情報がサーバ装置１から取得された後、この詳細な属性情報を基にオーディオデータの送信要求のアクションが実行される。サーバ装置１からは、このアクションに応答して、要求されたオーディオデータの送信が開始される。

〔ステップＳ２６〕主制御部３０１は、オーディオデータの再生時に表示する画面を生成するように、Ｕ／Ｉ制御部３０３に対して要求する。このとき、フラグ一覧情報３１０を参照して、所定の再生機能の対応の有無を検出し、その検出結果をＵ／Ｉ制御部３０３に通知して、結果に応じた表示画面を生成させる。なお、このときの具体的な処理の例については、後の図１２で説明する。

〔ステップＳ２７〕通信Ｉ／Ｆ３７において、サーバ装置１から送信されたオーディオデータが受信されると、主制御部３０１は、再生制御部３０４に対して、受信されたオーディオデータの再生動作を実行するように要求する。これにより、オーディオデータはオーディオＣＯＤＥＣ３８に供給され、必要に応じてデコードされた後、Ｄ／Ａ変換部３９に供給され、さらにオーディオアンプ４０に供給されて、スピーカ４１から音声が再生出力される。

なお、以上の図９および図１０の処理では、１つのアイテムに対して複数のオーディオデータが存在する場合に、フラグ一覧情報３１０の生成過程で選択されたオーディオデータに対応する情報のみが、属性情報３０８に記憶されるようにしている。しかし、このような処理の他に、例えば、属性情報３０８には、１つのアイテムに記述されたすべてのオーディオデータに関する情報を記憶しておき、それらの情報のうち、フラグ一覧情報３１０の生成過程で最適なものとして選択されたオーディオデータに対応する情報については、そのことを識別するための識別情報を付加しておいて、最適なオーディオデータに関する情報を属性情報３０８から即座に抽出できるようにしておいてもよい。

また、フラグ一覧情報３１０においても、１つのアイテムに対応するすべてのオーディオデータについてフラグ情報を設定してリスト化し、その中で、上記のステップＳ１３で最適なものとして選択されたオーディオデータを識別できるようにしておいてもよい。

図１１は、楽曲を選択するための画面表示例を示す図である。
上記のステップＳ２４では、再生させる楽曲をユーザが選択するための画面が表示部３６ａに表示される。図１１に示す楽曲選択画面３６１では、タイトル一覧表示部３６２において、再生対象の楽曲のタイトルが一覧表示されている。また、ユーザの操作によりカーソル３６３が移動されることで、所望の楽曲の再生が要求される。

上述したように、フラグ一覧情報３１０には、オーディオデータがオーディオ再生装置３において再生可能か否かを示すフラグＦＬ２が記録されており、ステップＳ２４では、フラグＦＬ２に基づき再生可能なオーディオデータに関する情報のみが抽出されて、表示に利用される。このため、楽曲選択画面３６１に表示されたどの楽曲が選択された場合でも、その楽曲に対応するオーディオデータを必ず正常に再生できる。従って、再生不能なオーディオデータをユーザが選択してしまうことがなくなり、ユーザの操作性が向上する。また、再生可能なオーディオデータのみを表示するために、ステップＳ２４の段階で再生可能か否かをオーディオデータごとに属性情報などから判定する必要がなくなり、一覧表示の際の処理負荷を軽減できる。

また、１つの楽曲について、符号化仕様の異なる複数のオーディオデータがサーバ装置１から送信可能である場合でも、楽曲選択画面３６１には１つの楽曲のタイトルしか表示されず、ユーザが符号化仕様の異なるオーディオデータから１つを選択する必要がなくなる。しかも、楽曲が選択されると、品質の高いオーディオデータが自動的に選択されて再生されるようになる。また、このような最適なオーディオデータを選択するための判断処理を、オーディオデータの一覧表示の処理段階で行う必要がなくなり、この段階での処理負荷を軽減できる。

なお、他の処理例として、ステップＳ２４ではすべてのアイテムについてのタイトルなどを楽曲選択画面に一覧表示し、その画面において、フラグＦＬ２に基づく再生不可能なオーディオデータについては、カーソルにより選択できないようにしたり、あるいは、そのタイトルを表示した領域のみ背景色を文字色に近い色とするなどして再生可能なものと視覚的に区別できるようにしてもよい。

図１２は、オーディオデータの再生時の画面表示例を示す図である。
上記のステップＳ２６では、オーディオデータを再生する際に、フラグ一覧情報３１０の内容に応じた表示画面が生成して表示させることが可能となっている。ここでは例として、フラグＦＬ４の設定値に応じて再生画面の表示を変える場合を挙げる。

図１２（Ａ）に示す再生画面３６４は、フラグＦＬ４の設定値が、キュー／レビュー操作が可能であることを示している場合の画面表示例である。このとき、再生画面３６４には、再生されている楽曲のタイトル、その楽曲の再生開始からの経過時間をそれぞれ表示する表示部３６４ａおよび３６４ｂが配置されている。さらにその下に、現在、楽曲の再生開始から終了までのどの位置が再生されているのかを示す再生位置表示部３６４ｃが配置されている。この再生位置表示部３６４ｃにはスクロールバーが表示されており、再生の継続に伴って再生位置を示すポインタ３６４ｄが徐々に移動していく。また、キュー操作やレビュー操作が行われると、それに応じてポインタ３６４ｄの位置が変化して、再生位置がどの位置まで変化したのかを目視できるようになっている。

これに対して、図１２（Ｂ）に示す再生画面３６５は、フラグＦＬ４の設定値が、キュー／レビュー操作が不可能であることを示している場合の画面表示例である。このとき、再生画面３６５には、再生画面３６４と同様に、楽曲のタイトル、経過時間がそれぞれ表示される表示部３６５ａおよび３６５ｂが配置されているが、再生位置を示すためのスクロールバーは表示されない。すなわち、スクロールバーの表示の有無により、再生中のオーディオデータがキュー／レビュー操作に対応しているか否かをユーザが認識できるようになる。

また、上記の例の他に、例えば、フラグＦＬ５およびＦＬ６の設定値を基に、再生中のオーディオデータを保存可能か、また、保存したデータのトランスコードが可能かといった情報を表示して、ユーザに知らせることもできる。このように、フラグ一覧情報３１０の内容に応じて表示画面を生成することにより、再生位置や対応している動作の情報など、ユーザが操作する上で有用な情報を必要に応じて表示させることが可能となる。そして、再生時にどのような表示画面を生成するかを、フラグ一覧情報３１０を用いた簡単な処理によって判断できるようになる。

さらに、フラグ一覧情報３１０の設定値を表示のために利用する以外に、例えば、再生中のオーディオデータがキュー／レビューなどの特殊再生機能に対応している場合にのみ、その操作に必要な操作キーを有効にし、それ以外ではその操作キーを無効化することなども可能である。

以上の説明では、オーディオデータの再生動作におけるフラグ一覧情報３１０の利用法を述べたが、オーディオデータの保存（ダウンロード）や、保存したオーディオデータのトランスコードなどの動作の際にも、フラグ一覧情報３１０を利用できる。例えば、ダウンロード対象とする楽曲をユーザに選択させる際に、フラグ一覧情報３１０のフラグＦＬ５を参照して、ダウンロード可能な楽曲のみ表示部３６ａに一覧表示し、ユーザによる選択を受け付けるようにすることができる。

また、フラグ一覧情報３１０では、このオーディオ再生装置３での再生などの仕様と各オーディオデータの仕様との対応状態が一元的に管理されているので、上記のように、楽曲の選択や再生動作などの制御の際にフラグ一覧情報３１０を参照することで、その制御処理を単純化できるとともに、仕様変更にも簡単に対応できるようになる。

例えば、オーディオ再生装置１において、特殊再生などの新たな機能が可能になった場合には、フラグ一覧情報３１０においてその新たな機能に対応するフラグの項目を設け、サーバ装置１からアイテムの属性情報を取得したときにそのフラグを設定すればよい。

また、例えば、再生仕様を一元的に管理していないシステムでは、各デバイスを制御する制御部が、入力されるコンテンツのデータの属性情報などを個別にチェックすることで、動作の可否を判断することになる。従って、例えば、再生対象のオーディオデータをユーザに選択させるための制御部は、再生可能なオーディオデータのみをユーザに提示しようとすると、再生のためのデバイスの制御部から再生仕様の情報をその都度受け取るなど、制御ブロック間のやり取りが煩雑になってしまう。このため、オーディオデータが選択され、そのオーディオデータが受信された後でも、特定のデバイス（例えば、オーディオＣＯＤＥＣ３８、Ｄ／Ａ変換部３９など）のみがそのオーディオデータを処理できず、エラーが生じるなどといった事態も発生しやすくなる。しかし、フラグ一覧情報３１０を用いることで、このような事態を回避できる。

また、本実施の形態のように、ネットワークを介して所望のコンテンツのデータのロケーションを探索し、その探索結果を基にデータの送信を要求するという手順が必要な場合には、上記のように再生時にエラーが発生すると、その後に別のデータをユーザが選択して、そのデータの再生が正常に開始されるまでには相当の時間が必要となる。従って、本実施の形態のようにフラグ一覧情報３１０を利用することで、ユーザの操作感を大きく向上させることができる。

さらに、新たなオーディオ再生装置を開発・製品化する際に、そのオーディオ再生装置内の基本的な処理機能の構造を本実施の形態のように共通化しておけば、例えば、装置内のＣＯＤＥＣやメモリ、Ｄ／Ａ変換部などのデバイスが変更されて、それによって装置内で再生可能な符号化仕様が変化した場合でも、デバイスの変更に応じて再生仕様情報３１１を変更するだけで、各デバイスをエラーが生じることなく確実に動作させて、再生を行うことが可能になる。従って、上記構成により製品開発を効率化して、新たなオーディオ再生装置の開発・製造コストを削減できるようにもなる。

なお、上記の例では、再生仕様情報３１１に、オーディオ再生装置３で再生可能な符号化仕様を記憶した構成としたが、再生に限らず、保存可能な符号化仕様や著作権保護仕様、トランスコード可能な符号化仕様（変換前および変換後の各仕様）などを記憶しておき、これらをフラグ一覧情報３１０のフラグの項目に付加してもよい。例えば、保存可能な符号化仕様の情報、トランスコード可能な符号化仕様の情報を、それぞれフラグＦＬ５，ＦＬ６の設定値を判定する際に利用することができる。

これにより、コンテンツの再生時だけでなく、ダウンロードやトランスコードを行うコンテンツをユーザに選択させる際にも、主制御部３０１が上記のフラグ一覧情報３１０を参照することで、それらの動作が可能なオーディオデータのみをユーザに対して提示し、選択させることができる。そして、選択されたオーディオデータのダウンロードやトランスコードの動作を、エラーを起こさずに確実に実行できるようになる。

なお、以上の実施の形態では、レス情報に基づき、同じアイテムに対応する符号化仕様の異なるオーディオデータから１つを抽出していたが、例えば、サーバ装置において、異なるコンテナに同一の楽曲であって符号化仕様の異なるオーディオデータが保存されている場合も考えられる。この場合、例えば、サーバ装置から取得される属性情報に、“ｒｅｆＩＤ”という情報が付加されていれば、同じｒｅｆＩＤが付加されたアイテムを抽出することで、同一の楽曲のデータが対応付けられていることを判断でき、その中から再生装置側で最適なアイテムのみ抽出して、ユーザに選択させることが可能となる。

実施の形態に係るホームネットワークシステムの構成例を示す図である。 ＵＰｎＰのプロトコルスタックについて説明するための図である。 メディアサーバに格納されたコンテンツを管理するツリー構造の例を示す図である。 サーバ装置のハードウェア構成を示すブロック図である。 オーディオ再生装置のハードウェア構成を示すブロック図である。 オーディオ再生装置が備える主な機能を示すブロック図である。 ＣＤＳ機能により取得可能な属性情報の一例を示す図である。 フラグ一覧情報の例を示す図である。 コンテンツ情報抽出部における情報抽出処理の手順を示すフローチャートである。 オーディオ再生装置でのコンテンツ再生時の処理手順の例を示すフローチャートである。 楽曲を選択するための画面表示例を示す図である。 オーディオデータの再生時の画面表示例を示す図である。

符号の説明

１，２……サーバ装置、３〜５……オーディオ再生装置、６……ＬＡＮ、１１，３１……ＣＰＵ、１２，３２……ＲＯＭ、１３，３３……ＲＡＭ、１４……ＨＤＤ、１５，３５……入力インタフェース、１５ａ……入力装置、１６，３６……グラフィック処理部、１６ａ……表示装置、１７，３７……通信インタフェース、１８，４２……内部バス、３４……フラッシュメモリ、３５ａ……入力部、３６ａ……表示部、３８……オーディオＣＯＤＥＣ、３９……Ｄ／Ａ変換部、４０……オーディオアンプ、４１……スピーカ、３０１……主制御部、３０２……通信制御部、３０３……Ｕ／Ｉ制御部、３０４……再生制御部、３０５……ダウンロード制御部、３０６……トランスコード制御部、３０７……コンテンツ情報抽出部、３０８……属性情報、３０９……フラグ生成部、３１０……フラグ一覧情報、３１１……再生仕様情報

Claims (10)

1. ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信して再生する再生装置において、
   前記サーバ装置が送信可能な前記ストリームデータの属性情報を、前記サーバ装置から前記ネットワークを通じて受信する属性情報受信手段と、
   前記ストリームデータを利用して前記再生装置で実行可能な動作のそれぞれに対して、前記サーバ装置が送信可能な前記ストリームデータが対応しているか否かを示す対応情報をリスト化した対応情報リストを、前記属性情報受信手段により受信された前記属性情報を基に生成してメモリに記録するリスト生成手段と、
   前記再生装置で実行可能な動作のうちの１つに対応している前記ストリームデータを、前記対応情報リストに基づいて抽出し、抽出された前記ストリームデータのうち１つをユーザに選択させるための選択画面を生成する選択画面生成手段と、
   前記選択画面に表示した前記ストリームデータのうちの１つを選択する操作入力情報を受け付け、選択された前記ストリームデータの送信を前記サーバ装置に対して要求するデータ要求手段と、
   を有することを特徴とする再生装置。
2. 前記再生装置で実行可能な動作として、前記ストリームデータの再生動作を含むことを特徴とする請求項１記載の再生装置。
3. 前記リスト生成手段は、前記再生動作に対する前記対応情報を生成する際に、前記再生装置において再生可能な符号化データの仕様を示す符号化仕様情報と、前記属性情報受信手段により受信された前記属性情報に含まれる、前記ストリームデータの仕様情報とを比較して、前記再生装置において再生可能な前記ストリームデータについての前記対応情報のみを生成して、前記対応情報リストに記録することを特徴とする請求項２記載の再生装置。
4. 前記サーバ装置が、同一のコンテンツについて符号化データの仕様が異なる複数の前記ストリームデータを送信可能である場合に、
   前記リスト生成手段は、前記属性情報受信手段により受信された前記属性情報に基づき、同一のコンテンツに対応する複数の前記ストリームデータの中から１つを選択して、選択した前記ストリームデータを識別可能な状態として前記対応情報リストに記録し、
   前記選択画面生成手段は、同一のコンテンツに対応する複数の前記ストリームデータの中から、前記リスト生成手段により選択された１つの前記ストリームデータのみを抽出して、前記選択画面を生成する、
   ことを特徴とする請求項１記載の再生装置。
5. 前記リスト生成手段は、前記属性情報受信手段により受信された前記属性情報に基づき、同一のコンテンツに対応する複数の前記ストリームデータの中から、トランスコードされていない前記ストリームデータを優先的に選択することを特徴とする請求項４記載の再生装置。
6. 前記リスト生成手段は、同一のコンテンツに対応する複数の前記ストリームデータの中から選択した１つの前記ストリームデータについての前記対応情報のみを生成して、前記対応情報リストに記録することを特徴とする請求項４記載の再生装置。
7. 前記データ要求手段による送信要求に応じて前記サーバ装置から送信された前記ストリームデータが受信され、当該ストリームデータを利用した所定の動作が実行される際に、前記所定の動作の実行を示す動作実行画面を、当該ストリームデータに対応する前記対応情報リストの情報に応じて生成する画面生成手段をさらに有することを特徴とする請求項１記載の再生装置。
8. 前記所定の動作として前記ストリームデータの再生が行われ、前記対応情報の１つとして再生動作中のユーザ操作に応じた所定の特殊再生動作の可否が記録される場合に、前記画面生成手段は、前記対応情報リストに基づき、再生中の前記ストリームデータが前記特殊再生動作に対応している場合のみ、前記特殊再生動作の実行を示すための画像を前記動作実行画面上に表示することを特徴とする請求項７記載の再生装置。
9. 前記ストリームデータの受信の前に、前記サーバ装置から送信可能な前記ストリームデータのリストの送信を前記サーバ装置に対して要求するデータリスト要求手段をさらに有し、
   前記属性情報受信手段は、前記データリスト要求手段による送信要求に応答して前記サーバ装置から送信される前記ストリームデータのリストに記述された情報として、前記属性情報を受信することを特徴とする請求項１記載の再生装置。
10. ネットワークを通じて接続されたサーバ装置から送信されるストリームデータを受信し、その再生を含む所定の動作を実行するための再生装置におけるデータ処理方法であって、
    属性情報受信手段が、前記サーバ装置が送信可能な前記ストリームデータの属性情報を、前記サーバ装置から前記ネットワークを通じて受信し、
    リスト生成手段が、前記ストリームデータを利用して前記再生装置で実行可能な動作のそれぞれに対して、前記サーバ装置が送信可能な前記ストリームデータが対応しているか否かを示す対応情報をリスト化した対応情報リストを、前記属性情報受信手段により受信された前記属性情報を基に生成してメモリに記録し、
    選択画面生成手段が、前記再生装置で実行可能な動作のうちの１つに対応している前記ストリームデータを、前記対応情報リストに基づいて抽出して、抽出された前記ストリームデータのうち１つをユーザに選択させるための選択画面を生成し、
    データ要求手段が、前記選択画面に表示した前記ストリームデータのうちの１つを選択する操作入力情報を受け付け、選択された前記ストリームデータの送信を前記サーバ装置に対して要求する、
    ことを特徴とするデータ処理方法。

Images