JP2007510195A - コンテンツ・ディレクトリ・サービスを用いたシステムにおける問い合わせのキャッシング - Google Patents

Abstract

キャッシングデバイス（７０）がサーバー役の機器（ＭＳ−ａ）のＣＤＳにメディアコンテンツ情報についての問い合わせ（２０３ａ）を行い、のちの検索のために結果（２０４ａ）を保存する。問い合わせ（２０３ａ）は問い合わせ装置（ＵＩ、２１）からその問い合わせを実行するようにという要求（２０２）を受け取るのに反応して、あるいはキャッシングデバイス自身によって定式化される問い合わせに反応して行われることができる。問い合わせ装置は、要求された問い合わせの再実行よりも優先してキャッシュされた結果にアクセスすることができる。キャッシュされている結果は、問い合わせ装置（２１）の要求によって、あるいは問い合わせ装置の関与なしに自動的に最新のものに維持されることができる。

Description

本発明は、コンテンツ・ディレクトリ・サービス（CDS: Content Directory Service）を使ってメディアコンテンツ情報を保存する、ユニバーサルプラグアンドプレイ（UPnP: Universal Plug and Play）アーキテクチャに従うシステムのようなシステムに関するものである。

メディアコンテンツを保存するためのデジタル記憶装置の使用は増加の一途をたどっている。メディアコンテンツの範囲は、単純なテキストファイルから、オーディオ、録画済みもしくはユーザーが録画したビデオ、放送デジタルオーディオ（たとえばインターネットラジオ）、放送デジタルビデオまたはデジタル画像（たとえばデジタル写真）といったマルチメディアコンテンツまで及びうる。

ユニバーサルプラグアンドプレイ（UPnP）は、異なるメーカーによって製造された電子機器が互いと一緒に動作できるようにする通信プロトコルである。UPnPは新規デバイスの自動検出を用いたゼロ設定（zero-configuration）すなわち「見えない」ネットワーク構成をサポートするよう設計されている。これは、デバイスが動的にネットワークに加わり、IPアドレスを取得し、自分の機能を伝え、他のデバイスの存在および機能を学ぶということを意味している。UPnPのさらなる発展形は、UPnPアーキテクチャのオーディオ・ビジュアル機器に関連した拡張を記載するUPnPオーディオ・ビジュアル（AV: Audio-Visual）アーキテクチャである。UPnP AVアーキテクチャはメディアサーバー、メディアレンダラー、コントロールポイントを定義している。

UPnP ホームネットワークのようなUPnP準拠ネットワーク内にある多くのデバイスは、当該ネットワーク内の他のデバイスがアクセスしたいさまざまな種類のコンテンツ（たとえば音楽、ビデオ、静止画像）を含む。例を挙げると、メディアサーバー機器がオーディオ、ビデオおよび静止画像のライブラリーを含んでいることがありうる。ユーザーがこのコンテンツを楽しむためには、ユーザーはメディアサーバー上に保存されているオブジェクトをブラウズして、特定のものを選択し、それが適切なレンダリング機器（たとえば音楽オブジェクトについてはオーディオプレーヤー、ビデオコンテンツについてはテレビ、静止画像については電子額縁）上で再生されるようにすることができなければならない。利便性を最大にするためには、ユーザーがこれらの操作を多様なユーザーインターフェース（UI: user interface）機器から開始できるようにすることが望ましい。多くの場合、これらのUI機器はレンダリング機器に組み込まれたUIか、あるいはリモコンユニットのようなスタンドアローンのUI機器である。ユーザーが、コンテンツを含んでいる機器と直接対話する必要なしにコンテンツにアクセスできることが望ましい。

UPnP AVアーキテクチャの主要部分の一つがコンテンツ・ディレクトリ・サービス（CDS）である。CDSは、UPnPコントロールポイント（CP: Control Point）機器がメディアサーバー（MS: Media Server）機器に保存されているコンテンツにアクセスできるようにする一組の機能を提供する。一般に利用可能な現在のCDSの記載は、ユニバーサルプラグアンドプレイ・バージョン1.0、2002年6月25日についての「コンテンツ・ディレクトリ・サービス・テンプレート・バージョン1.01（Content Directory Service Template Version 1.01）」である。コンテンツ・ディレクトリ・サービスによりクライアント（たとえばUI機器）は、サーバー機器が提供できる個々のオブジェクト（たとえば楽曲、映画、写真）の位置を特定できるようになる。たとえば、このサービスを使って提供できるものには、MP3プレーヤーに保存されている楽曲のリスト、さまざまなスライドショーをなす静止画像のリスト、DVDジュークボックスに保存されている映画のリスト、現在放送中のテレビ番組のリスト、CDジュークボックスに保存されている楽曲のリスト、PVR（Personal Video Recorder［パーソナルビデオレコーダー］）に保存されている番組のリストがある。ほとんどどんな種類のコンテンツでもCDSを通じてリストできるし、CDSは複数の種類のコンテンツ（たとえばMP3、MPEG2、JPEG）を一緒にリストすることもできる。

コンテンツはUPnPコンテナオブジェクトの階層構造中に保存される。各コンテナはその中に保存されているオブジェクトのコレクションをもつ。各オブジェクトはメディアコンテンツ情報と一様リソース識別子（URI: Uniform Resource Identifier）のようなメディアコンテンツ位置指定子とを含んでいる。UPnP AV運営委員会はクラス定義の集合を発行しているものの（ユニバーサルプラグアンドプレイ・バージョン1.0、2002年6月25日についての「コンテンツ・ディレクトリ・サービス・テンプレート・バージョン1.01」の付録C参照）、UPnPは、メディアサーバーのCDSについて特定の配列方法は要求しておらず、コンテナとオブジェクトを配列する仕方は各ベンダーまたはユーザーによって決定される。その結果、各CDSが独自の構造をもつことができ、その構造内の個々のオブジェクトは説明用メタデータの異なる組み合わせをもってラベル付けされる。追加的に、UPnPは、問い合わせ機器がCDSを調べられる二つの機構を定義している：問い合わせ機器がCDS構造の中を通してブラウズできる「ブラウズ」機構と、問い合わせ機器がCDSに対して特定の検索語に合致する項目を返すよう要求できるというより有用な「検索」機構である。しかし、「検索」機構は任意的であり、あるメディアサーバーによってホストされているCDSがUPnPの任意的な「検索」機能を実装しておらず、CPがその階層構造をコンテナごとに「ブラウズ」することを要求するということもありうる。

コントロールポイントがCDSに問い合わせをするとき、応答を受け取るまでに必然的に遅延がある。この遅延は、要求された情報についてCDSデータベースを検索するのにかかる時間のほか、抽出された情報を照合するのにかかる時間を含む。この遅延は、検索の種類および規模、個々の機器のパフォーマンスおよび機器間の通信効率を含む諸要因に依存して変動しうる。遅延はさらに、ユーザーインターフェースが記憶装置のCDSに対して異なる仕方で構成されている場合、あるいはCDSが「ブラウズ」処理しかサポートしていない場合にはさらに長引くことになる。いずれの場合にも、問い合わせ機器は要求される情報を引き出すために複数の問い合わせをしなければならない。応答を受け取るまでの長い遅延は遅延の変動と並んで当該システムのユーザーの使用感を悪化させる。

したがって、本発明は、コンテンツ・ディレクトリ・サービスが使われるシステムを運用する改良された方法を提供しようとするものである。

本発明の第一の側面は、メディアコンテンツ情報を保存するためのコンテンツ・ディレクトリ・サービス（CDS）を使用するシステムにおいてキャッシングデバイスに問い合わせ情報を保存する方法であって：
メディアコンテンツ情報についてのサーバー役の機器のCDSに問い合わせをし、
問い合わせの結果を受け取り、
前記結果をのちの検索のために保存する、
ことを含む方法を提供する。

キャッシングデバイスが問い合わせを実行し、結果を保存できるようにすることによって、問い合わせ機器の処理および記憶リソースにキャッシングサービスの提供に関して負担がかからなくなる。保存すなわちキャッシュされた結果は、要求された問い合わせを再実行するよりも優先して問い合わせ機器によってアクセスされうる。この結果として、結果がより速く届けられるようになり、それにより問い合わせ機器と対話するユーザーの使用感が改善される。

好ましくは、キャッシュされた結果は最新のものに維持される。これは問い合わせ機器の要求によってでもよいし、あるいは問い合わせ機器の関与なく自動的にであってもよい。これによりキャッシングサービスの有用性が改善され、問い合わせ機器のリソースに対する負担がさらに軽減される。

好ましくは、当該システム内の複数の問い合わせ機器に当該サービスが提供される。

好ましくは、最も重要な諸問い合わせのみがキャッシングされる。これにより、保存および維持される必要があるのは比較的少数の結果だけとなり、結果を取得するためにかかる時間もCDSに直接アクセスする場合に比べて短縮される。

デバイスによる当該方法の実行は、そのデバイスによる内部的な使用のためであってもよいし、あるいはシステム内の他のデバイスによって使用されうるサービスとしてであってもよい。当該方法は記憶装置（メディアサーバー型のUPnP機器のような）によっても、あるいは処理および記憶リソースをもつ他のいかなるデバイスによってもホストされうる。当該方法は、ネットワーク上の諸デバイスに別のサービスを提供するデバイスによってホストされてもよいし、当該ネットワーク上の諸記憶装置についての情報を保持しているいかなるデバイスによってホストするためにも特に好適である。

本発明のあるさらなる側面は、メディアコンテンツ情報を保存するためのコンテンツ・ディレクトリ・サービス（CDS）を使うシステムにおいて問い合わせ装置を動作させる方法であって：
キャッシュされるべき候補となる問い合わせを決定し、
前記候補となる問い合わせを実行し、その問い合わせの結果を保存するようキャッシングデバイスに指示する、
ことを含む方法を提供する。

本発明のさらなる諸側面は、前記諸方法を実装するための装置を提供する。

ここに記載される機能はソフトウェア、ハードウェアまたはそれらの組み合わせにおいて実装されることができる。したがって、本発明のもう一つの側面は、当該方法を実行するためのソフトウェアを提供する。該ソフトウェアは、電子的メモリ素子、ハードディスク、光ディスクまたはその他の機械可読記憶媒体に保存されることができ、ホストデバイス上の好適な処理デバイスによって実行されることになる。前記ソフトウェアは、機械可読担体上のコンピュータプログラムプロダクトとして与えられてもよいし、あるいはネットワーク接続を通じてホストデバイスに直接ダウンロードされてもよい。前記ソフトウェアがホストデバイスの寿命の間のいかなる時点でインストールされてもよいことは理解されるであろう。

「コンテンツ・ディレクトリ・サービス」（CDS）の用語はUPnPシステムにおいて使われるCDSを含むことが意図されているが、UPnPシステムだけに限定されるよう解釈するべきではない。それは、定義が厳密でなく、よって予測が不可能で、かつ問い合わせ機器にとって要求される情報を引き出すのが難しい階層構造をもつ、CDSに似たいかなるメディアコンテンツ情報の記憶システムをも含むことができる。

本発明の実施形態についてこれからあくまでも例として付属の図面を参照しつつ説明する。

本発明を詳細に説明する前に、従来のUPnPシステムについて手短に説明する。より十全な説明はUPnPフォーラムによって刊行されている『UPnP AVアーキテクチャ（UPnP AV Architecture）』から得ることができる。UPnP AVシステムの主要な構成要素は、コントロールポイント（CP）２０、メディアサーバー（MS）５０およびメディアレンダラー（MR）６０である。これらはみな論理的な実体である：物理的な装置が含むのはこれらの実体のうちの一つのみ（たとえばリモコンの形でのコントロールポイント）、あるいはより一般的にはこれらの実体のいくつかの組み合わせであってもよい。例を挙げると、CDプレーヤーは、プレーヤーを操作するためのユーザーインターフェース兼制御回路（コントロールポイント）、光ディスクからデジタルコンテンツを読み出す装置（メディアサーバー）およびそのデジタルコンテンツをユーザーに呈示するためにオーディオ信号に変換する装置（メディアレンダラー）を有している。

メディアサーバー（MS）５０はメディアコンテンツの記憶５２を含んでいる。コンテンツはたとえば、オーディオ、ビデオ、静止画像またはそれらの組み合わせを含みうる。メディアサーバーはまた、記憶５２中のコンテンツをカタログ化するコンテンツ・ディレクトリ・サービス（CDS）５５もサポートしている。CDSは、コンピュータのファイルシステムと同様な仕方で階層的に編成されている。コンテナ（フォルダまたはディレクトリに相当）は、複数のオブジェクト（ファイルに相当）および階層的に一つ下のレベルのコンテナを含むことができる。オブジェクトは識別子および任意的にメタデータを用いたオブジェクトの説明を含んでいる。メタデータはオブジェクト名、アーチスト、作曲家、作成日、大きさなどといった属性を含みうる。オブジェクトはまた、オブジェクトコンテンツ（項目）を含んでいたり、あるいは前記コンテンツの位置を特定するためのURIのような位置指定子を含んでいたりしていてもよい。CDS構造の例が図８に示されている。メディアサーバー５０のさらなる機能は、メディアサーバー５０とメディアレンダラー６０のようなその他の機器との間で接続を管理するのに使われる接続マネージャサービスがある。任意的なAV転送サービスは、停止、一時停止、シークなどのような機能を用いたコンテンツ再生の制御を可能にする。

メディアレンダラー（MR）６０はメディアサーバー５０から受け取られたメディアコンテンツをレンダリング（再生）する役割を担っている。再生装置６２はディスプレイ６３およびスピーカー６４を用いて示されているが、出力は多くの形を取りうる。典型的には、再生装置６２は一つまたは複数のデコーダ、デジタル‐アナログコンバータおよび増幅器を含む。メディアレンダラー６０はまた、メディアサーバーと、コンテンツがレンダリングされる仕方を制御するためのレンダーコントロール６１との新規の接続を確立するための接続マネージャサービス６５もサポートしている。オーディオ再生については、これは音量調節のような機能を含むことができる。

コントロールポイント（CP）２０はメディアサーバー５０およびメディアレンダラー６０の動作を調整するもので、ユーザーがコンテンツを選択できるユーザーインターフェース（UI）を含んでいる。コントロールポイント２０は、新規デバイスを検出するための従来のUPnP機構をサポートしており、またメディアレンダリング機器の機能を見出し、メディアサーバーとメディアレンダラーとの間の接続を確立するための機構をもサポートしている。UPnP AVアーキテクチャは、テレビ、ビデオデッキ、CD/DVDプレーヤー／ジュークボックス、セットトップボックス、ステレオシステム、MP3プレーヤー、静止画像カメラ、ビデオカメラ、電子額縁（EPF: electronic picture frames）およびパソコンといった広範な種類のAV機器をサポートする。AVアーキテクチャは機器が娯楽コンテンツについての異なる種類のフォーマット（MPEG2、MPEG4、JPEG、MP3、ウィンドウズ（登録商標）・メディア・アーキテクチャ(WMA: Windows（登録商標） Media Architecture)、ビットマップ（BMP:bitmap）、NTSC、PAL、ATSCなどのような）および複数の種類の転送プロトコル（IEC-61883/IEEE-1394、HTTP GET、RTP、HTTP PUT/POST、TCP/IPなどのような）をサポートすることを許容する。

それぞれがCP、MS、MR実体のうちの一つまたは複数をもつ複数の物理機器はネットワークとして一緒に運用することができる。図２は、家庭内の機器のネットワークを表すことができるUPnPネットワークの例を示している。コントロールポイント１２０、二つのメディアサーバー機器１２１、１２２およびメディアレンダラーデバイス１４０は一緒にネットワーク１１０に接続されている。ネットワーク１１０は有線（たとえばイーサネット（登録商標））でも無線（たとえばIEEE802.11、ブルートゥース）でもよい。メディアコンテンツは完全に家庭ネットワーク１００内のサーバー上に位置していることもできるし、家庭ネットワーク１００の外に位置していることもできる。図２は、コンテンツを保存するためのサーバー１２３をインターネットのような外部ネットワーク１３０の一部として示している。この外部サーバー１２３は家庭ネットワークにゲートウェイ１１５を通じて接続されている。

再び図１を参照すると、これはUPnPネットワークを通じてコンテンツにアクセスするための従来式の構成を示している。メディアサーバーMS５０はローカル記憶装置５２との対話３１によってコンテンツ・ディレクトリ・サービス（CDS）５５を維持している。メディアサーバー５０はこのCDSをある特定の方法で構造化する。これはMSのメーカーによって指定されることもある。CDSは記憶５２に新規コンテンツが追加されるにつれて更新される。典型的には、ユーザーインターフェース２１はユーザーに可能なオプションのメニューを呈示する。例を挙げると、初期メニュー画面は、オーディオコンテンツ、ビデオコンテンツまたは画像のどれを取得したいかをユーザーに尋ねうる。UI２１におけるユーザーの選択に反応して、CPはMS５０のCDS５５に適切な問い合わせ３２を行う。MS５０は要求されたコンテンツのリストをもって応答する。ユーザーが一つのコンテンツを選択すると、CPはMSおよびMRに、適切な接続３５を構成して、当該コンテンツのMSからMRへのストリーミングを開始するよう指示３３、３４する。

再び図２を参照すると、ネットワークはまた、本発明に基づく問い合わせキャッシングサービス（QCS: query caching service）７０をも含む。QCSはネットワーク内のデバイスによってホストされており、ネットワーク内でサービスを要求するいかなるコントロールポイント（CP）にもそのサービスを提供する。図３は、QCSが設けられたシステムの第一の実施形態を示している。明確のため、図は一つのコントロールポイントCP、メディアサーバー機器MS-aおよびQCS７０をホストするデバイス７５しか示していない。図３は、キャッシュされる問い合わせ結果の生成をCPが開始するのに必要とされるメッセージフローを示している。MSはそのCDS５５を、従来の仕方でコンテンツ記憶５２との対話によって維持する。CPはQCSに、メッセージ２０２を送ることによってある特定の問い合わせのキャッシュを生成するよう指示する。メッセージ２０２はキャッシュする必要のある問い合わせを指定する。QCS７０はメッセージ２０３ａによってCDS５５に問い合わせをし、メッセージ２０４ａにおいてその問い合わせの結果を受け取る。要求された情報のすべてを取得するためにいくつかの問い合わせ２０３ａが必要となることもある。問い合わせの結果はQCS７０によって保存される―キャッシュされる。QCSは次いでCPにメッセージ２０５を送るが、このメッセージ２０５には、のちにCPが前記結果を取得できるようにするキャッシュされた結果についての識別用参照情報を含んでいる。

CPは任意の時点で、キャッシュされている問い合わせの参照情報を指定したメッセージをQCSに送ることによって、QCSにその特定のキャッシュされている結果のリフレッシュを要求できる。リフレッシュメッセージ受領に反応して、QCSはCDSに改めて問い合わせを実行し、更新された結果を保存する。CPがこのようにしてリフレッシュメッセージを送るのは、その特定の結果がもうすぐ必要になりそうだと考えるからでもよいし、あるいはQCSがいつキャッシュをリフレッシュすべきかを決める独自の方法をもたないからでもよいし、あるいはQCSがCPによって明示的に再要求されない限りいかなるキャッシュも破棄することを含むポリシーを有しているからでもよい。この場合、CPに返す必要があるのはリフレッシュが行われたという確認のメッセージだけであって実際の結果は必要ではない。

CPはまた、CPがすでに保持している結果の更新をQCSに求めることもできる。この場合、QCSは、CDS問い合わせを自分自身のために再実行するのではなく、現在キャッシュされている結果の何らかの表現をCPに送る。QCSは新しい結果の組を生成するために問い合わせを再実行する。QCSが応答するのはいくつかの方法がありうる。CPに送信する必要のあるデータの量を最小化するためには、QCSが新しい結果を以前の結果と比較し、CPに、該CPによって現在保持されている結果に対してどのような修正がなされているかを示すメッセージを返すことが好ましい。これは、キャッシュの変わっていない部分は伝達されないので、さらにCPに対する通信および処理要求を軽減する。あるいはまた、QCSはキャッシュされた結果の完全なリストをCPに提供することもできるし、単に新しい結果を要求されるまで保存することもできる。

図４は、キャッシュされる問い合わせ結果の生成をQCSが開始するのに必要とされるメッセージフローを示している。QCSは問い合わせを定式化し、該問い合わせをメッセージ２１１としてCDSに送る。結果はメッセージ２１２として送られ、QCSによってキャッシュされる。QCSは次いでCPにメッセージ２１３によって前記キャッシュされた問い合わせの参照情報およびそれが関係する問い合わせ基準を通知する。例を挙げると、メッセージ２１３は「キャッシュ参照情報：１０５；問い合わせ基準：CDS５５に最も最近追加された５項目」と指定することができる。CPは、関連する問い合わせを必要とする場合（または必要とするとき）、前記参照情報を指定するメッセージ２１４をQCSに送ることによってそれを要求することができる。キャッシュされている結果はQCSによって記憶装置から取得され、メッセージ２１５としてCPに送られる。

キャッシュされた結果はCPまたはQCSの要求により削除できる。CPによって開始された問い合わせの場合、CPは、キャッシュされている問い合わせのうち削除したいものの参照情報を指定するメッセージをQCSに送ることができる。

図３は、CDSとQCSを別個のデバイスとして示している。実際、両者は互いに物理的に別個の機器によってホストされることもできる。あるいはまた、CDSとQCSが同一の機器によってホストされることもできる。そのことが図４の枠７６によって示されている。その場合、CDSとQCSとの間の通信はネットワークを介したUPnPメッセージではなく内部チャネルによって運ばれる。

図５はCDSの変化に反応してQCSを自動的に更新するプロセスを示している。サービスの有用性を保証するためには、キャッシュされた結果が最新のものに維持されることが重要である。記憶装置５２のコンテンツに更新があったときには常に、MSは従来の仕方で最新のCDSを維持する。更新は新しい項目が追加されるとき、既存の項目が削除されるとき、あるいはユーザーがコンテンツ情報もしくはCDSの構造内でのある項目の位置を訂正しようと決めるときに起こりうる。CDSは、コンテンツ記憶５２に変化が生じたときには標準的なUPnPメッセージ２３２によってQCSに通知する。メッセージ２３２の受領に反応して、QCSはキャッシュされている問い合わせのどれがこのCDSの更新によって影響を受けそうかを判定する。QCSは、もとの問い合わせ基準に基づいて、現在キャッシュされている問い合わせに潜在的に関係するCDSのなんらかの変更された部分に対する問い合わせ２３３を提出する。QCSは前記問い合わせの結果２３４を解析し、必要ならそれぞれのキャッシュされている結果を更新する。QCSはCPに、キャッシュされている問い合わせが更新されたことを示すメッセージ２３５を送ることができる。ただし、このメッセージは必須ではない。CPが更新されたキャッシュの結果を必要とする場合に（または必要とするときに）QCSに要求２３６し、受け取る２３７ことができる。QCSは同様の機構（２３３、２３４）を使って、任意の時点においてそのキャッシュの有効性を能動的に確認することができる。自動更新機構を設けることにより、QCSはキャッシュされた結果について、CPによるさらなる介入なしに、CDSと整合性を保たせることができ、よってネットワークを通じたトラフィックのフローを最小限にすることができる。

図６は、QCS内の主要な機能ブロックを示している。記憶装置８５は問い合わせおよび問い合わせの結果を、それらの検索のための参照情報とともに保存する。問い合わせインターフェース機能８１はCPにメッセージを送ったりCPからメッセージを受け取ったりする。問い合わせ処理機能８２はMSデバイスに問い合わせを送り、一つまたは複数のMSデバイスからの結果を照合し、キャッシュされたデータへの参照情報を割り当てる。どの問い合わせをキャッシュするかを決める役割をQCSが担う実施例では、問い合わせ処理機能８２がCPから受け取られる情報に基づいて問い合わせを定式化する。QCSがCDSへの更新を通知されたときには、CDS解析機能８３が使われる。解析機能８３は、その更新によってキャッシュされている問い合わせのどれが影響を受けるかを判定し、更新されたCDSのさらなる問い合わせをするよう問い合わせ処理機能８２に指示する。その後、CDS解析機能８３は更新された結果をキャッシュ８５に保存されている古い結果と比較し、必要であればCPに送るための更新メッセージを用意する。

QCSは一つの物理機器７５によってホストされることができる。UPnPアーキテクチャはMSデバイスが別のMSデバイスに問い合わせをすることは認めていないので、QCSを示す正しい方法は、CPデバイス内に埋め込まれたMSデバイスとして、あるいはたとえば同一の物理機器によってホストされているなどのため緊密に協力することのできる別個のMSデバイスおよびCPデバイスとしてである。そのため、記憶機能８５は、制御機能８１、８２、８３をホストするコントロールポイントデバイスCP-QCS内に埋め込まれたメディアサーバーデバイスMS-QCSの一部として示されている。

図７はCP内の主要な機能ブロックを示している。ユーザーインターフェース処理ユニット９３は、キーボード上で、マウスによって、あるいはタッチ感応スクリーン上でなされた選択といったユーザー入力９６を受け取り、画面表示のためのグラフィックデータおよび音声プロンプトといった出力（図示せず）を発する。処理ユニット９３は、既知の仕方でメニューの生成を制御し、ユーザー選択に反応する。ユーザー選択はデータベースによって記録が取られ、UIを用いたユーザーの対話についての履歴情報を表すユーザー選択統計９２のコレクションが形成される。解析ユニット９１はそのユーザー統計９２を解析して、キャッシュすべき問い合わせの有望な候補とするため最もよく要求される選択およびメニューナビゲーションを決定する。これらは問い合わせ処理ユニット９４に転送される。UIの現在の状態についての情報、すなわちユーザーに現在呈示されていたりあるいはまもなく呈示されることになっていたりするオプションなども同様にキャッシュのための有望な候補として問い合わせ処理ユニットに転送される。キャッシュすべき問い合わせの選択はさまざまな基準に基づいたものでありうる：
・コントロールポイントによって提供される機能に基づく基本的な問い合わせ。UIの基本構造がほとんど保証しているこれらの問い合わせは、絶対的な頻度やどのくらい最近実際に選択されたかに関わりなく、ユーザーがその対話のどこかの点（たとえばユーザーが最初に呈示されるメニュー）で遭遇するものである。
・よく要求される問い合わせ。ユーザー統計９２によって保持されている、そのユーザーの過去の選択履歴の解析によって、どの問い合わせがよくなされているかが示される。これらはキャッシングのための有望な候補になる。
・最近要求された問い合わせ。これらをキャッシュしておくと、ユーザーは、UIのメニュー構造をたどって後戻りするときにそれぞれの高レベル問い合わせを繰り返さずに迅速にできる。
・UIによってユーザーに呈示された可能なオプションに基づいた問い合わせ。UIの操作の各段階において、ユーザーはある範囲の可能なオプションを呈示される。ユーザーは提供された選択肢の一つを選ばなければならなくなっている。利用可能な各オプションが問い合わせされ、キャッシュされることもできるし、最初のX個のオプションが問い合わせされ、キャッシュされることもできるし、あるいはメニューのその段階でのユーザーの選択履歴などに基づいてメニューのその段階から最もよく選ばれたオプションが問い合わせされ、キャッシュされることもできる。それぞれの場合において、問い合わせはユーザーによる実際の選択に先立って行われ、キャッシュされる。ユーザーが選択を行うときまでにはユーザーにとって最小限の遅延で結果が得られるようになるとの希望からである。より洗練された形では、現在のメニューレベルよりも一つまたは複数のメニューレベル下のUIオプションについての問い合わせもなされる。
・選択統計その他の基準に基づく確からしい問い合わせシーケンス。UIのメニュー構造でユーザーがたどるルートについて予測をすることができる。
・現在の問い合わせと意味的に類似の問い合わせまたは変形。

問い合わせ処理ユニット９４は、キャッシングのための有望な候補であると示されている問い合わせについてキャッシュがすでに存在しているかどうかを調べることができる。キャッシュが存在していなければ、問い合わせ処理ユニットはQCSにキャッシュを要求することを決定できる。問い合わせ処理ユニット９４がQCSによってすでにキャッシュされていると知っており、まもなく必要になるかもしれない結果についての要求がされた場合には、問い合わせ処理ユニット９４は、CP上の短期キャッシュに保存するために、ユーザーによる実際の選択に先立ってQCSにその結果を要求することができる。CPがこのようにしてキャッシュを行う程度は記憶リソース９５に依存する。代替的に、問い合わせ処理ユニット９４は前記メニュー選択がなされたときにのみ結果を要求する。

再び図４を参照すると、どれをキャッシュするかの決定をQCSが行う場合の実施形態が示されている。何をキャッシュする必要があるかを決定するためには、QCSはCPのUIについての情報を必要とする。これはUIの構造、すなわちメニュー構造、ユーザーに呈示されているオプション、QCSがキャッシュすべき問い合わせを導出できる母集団についての情報を含むことができる。代替的または追加的に、QCSが独自のユーザー選択統計を集計することができるように、前記情報はユーザー選択についての情報の形を取ることもできる。その情報はCPによってその都度あるいはバッチにまとめて送られることができる。あるいはまた、CPはCPのUIによって現在ユーザーに呈示されている特定の諸オプションの詳細を送るよう構成される。これらに基づいて、QCSはどの問い合わせをキャッシュすべきかを決定できる。

問い合わせ結果をコントロールポイントではなくQCSに保存することにより、コントロールポイントのための記憶および通信要求が軽減される。しかし、キャッシングの量はQCSの処理および記憶リソースによって、および問い合わせを受けるべきCDSをホストしているMSのリソースによって制約を受ける。

各キャッシング動作のためのオーバーヘッド軽減により、CPは、推測に基づいてより多くの問い合わせをキャッシュするよう要求することができるようになり、それにより有意なキャッシュが利用可能である可能性が改善され、よってシステムの平均応答時間が改善される。これはまた、UIの操作パフォーマンスをも改善する。これは、無線リモコンユニットのように、CPデバイスのリソースが限られており、ネットワークに低帯域幅のリンクで接続されている場合にはとりわけ重要である。

完全性のため、図８にMSのコンテンツ・ディレクトリ・サービス（CDS）の例示的な構造を示す。CDSはコンテナとオブジェクトの階層構造を有する。コンテナは複数のオブジェクトを保持する。たとえば音楽アルバムは複数のオーディオオブジェクトを保持しているコンテナである。図示しているように、コンテナはさらなるコンテナ（コンテナ３．２、３．３、３．４を保持しているコンテナ２．３の場合など）または複数のオブジェクトの諸集合を保持していることができる。各オブジェクトはいくつかの属性によって定義される。そのようなオブジェクトの一つ、オブジェクト３．１．３がより詳細に示されている。UPnPでは属性は「id」および「title」（名称）のような識別子を含まなければならない。オブジェクトは、メディアオブジェクトの位置をポイントする一様リソース識別子（URI）を含むことができる。オブジェクトはメディアサーバー内の記憶装置（たとえば図１の記憶５２）に保存されてもよいし、あるいはメディアサーバーの外部にあるサーバーに保存されてもよい。コンテナの属性の一つは、そのコンテナが検索できるかどうかを示すフィールドである。メタデータ７００を含むさらなる属性もその情報に含められることができる。

UPnPシステムの主要な構成要素を示す図である。 UPnP機器のネットワークを示す図である。 本発明に基づく問い合わせキャッシングサービスを含むシステムの実施形態を示す図である。 本発明に基づく問い合わせキャッシングサービスを含むシステムの実施形態を示す図である。 本発明に基づく問い合わせキャッシングサービスを含むシステムの実施形態を示す図である。 問い合わせキャッシングサービスの主要な機能ブロックを示す図である。 コントロールポイントの主要な機能ブロックを示す図である。 コンテンツ・ディレクトリ・サービス（CDS）の例示的な構造を示す図である。

Claims (22)

1. メディアコンテンツ情報を保存するためのコンテンツ・ディレクトリ・サービス（CDS）を使用するシステムにおいてキャッシングデバイスに問い合わせ情報を保存する方法であって：
   メディアコンテンツ情報についてのサーバー役の機器のCDSに問い合わせをし、
   前記問い合わせの結果を受け取り、
   前記結果をのちの検索のために保存する、
   ことを含むことを特徴とする方法。
2. のちの検索での使用のために前記保存される結果の識別情報を問い合わせ装置に送るステップをさらに有することを特徴とする、請求項１記載の方法。
3. サーバー役の機器のCDSに問い合わせをする前記ステップが、問い合わせ装置から受け取られる問い合わせを使用することを特徴とする、請求項１または２記載の方法。
4. サーバー役の機器のCDSに問い合わせをする前記ステップが、前記キャッシングデバイスによって定式化される問い合わせを使用することを特徴とする、請求項１または２記載の方法。
5. 前記定式化された問い合わせが前記問い合わせ装置のユーザーインターフェースの情報を使用することを特徴とする、請求項４記載の方法。
6. 前記定式化された問い合わせが前記問い合わせ装置のユーザーインターフェースにおけるユーザー選択の情報を使用することを特徴とする、請求項５記載の方法。
7. 前記定式化された問い合わせが前記ユーザーインターフェースにおいて頻繁に選択されるオプションに関係していることを特徴とする、請求項６記載の方法。
8. 前記サーバー役の機器から前記CDSへの更新の通知を受け取り、前記キャッシングデバイスに保存されている結果を更新するステップをさらに有することを特徴とする、請求項１ないし７のうちいずれか一項記載の方法。
9. 前記CDSへの更新の通知を受け取ったときに、前記キャッシングデバイスが保存されている結果が更新を必要としているかどうかを判定するよう構成されていることを特徴とする、請求項８記載の方法。
10. 保存されている情報が更新された場合に、前記キャッシングデバイスが問い合わせ装置に更新が発生したことを通知することを特徴とする、請求項８または９記載の方法。
11. 保存されている情報が更新された場合に、前記キャッシングデバイスが問い合わせ装置に変化のあった情報を送ることを特徴とする、請求項１０記載の方法。
12. メディアコンテンツ情報を保存するためのコンテンツ・ディレクトリ・サービス（CDS）を使うシステムにおいて問い合わせ装置を動作させる方法であって：
    キャッシュされるべき候補となる問い合わせを決定し、
    前記候補となる問い合わせを実行し、その問い合わせの結果を保存するようキャッシングデバイスに指示する、
    ことを含むことを特徴とする方法。
13. 保存された結果ののちの検索での使用のために前記保存される結果の識別情報をキャッシングデバイスから受け取ることをさらに含むことを特徴とする、請求項１２記載の方法。
14. 前記問い合わせ装置がユーザーインターフェースを有し、候補となる問い合わせを決定する前記ステップがユーザーインターフェースにおけるユーザー選択の履歴データを使用することを特徴とする、請求項１２または１３記載の方法。
15. 前記候補となる問い合わせがユーザーインターフェースにおいて頻繁に選択されるオプションであることを特徴とする、請求項１４記載の方法。
16. 前記候補となる問い合わせが、ユーザーインターフェースのユーザーに現在利用可能な少なくとも一つのオプションであることを特徴とする、請求項１３ないし１５のうちいずれか一項記載の方法。
17. プロセッサをして、請求項１ないし１６のうちいずれか一項記載の方法を実行せしめることを特徴とするソフトウェア。
18. キャッシングデバイスのための制御装置であって、前記キャッシングデバイスをして請求項１ないし１１のうちいずれか一項記載の方法を実行せしめることを特徴とする装置。
19. 請求項１８記載の制御装置を組み込んでいることを特徴とするキャッシングデバイス。
20. 問い合わせ装置のための制御装置であって、前記問い合わせ装置をして請求項１２ないし１６のうちいずれか一項記載の方法を実行せしめることを特徴とする装置。
21. 請求項２０記載の制御装置を組み込んでいることを特徴とする問い合わせ装置。
22. ユニバーサルプラグアンドプレイ（UPnP）に従うシステムで使用するための、請求項１ないし２１のうちいずれか一項記載の方法、ソフトウェア、制御装置、キャッシングデバイスまたは問い合わせ装置。

Images