JP2010146584A

JP2010146584A - ネットワークを隔てたメディアへのアクセス

Info

Publication number: JP2010146584A
Application number: JP2010008390A
Authority: JP
Inventors: Amandeep Jawa; ジャワ・アマンディープ; Jeffrey L Robbin; ロビン・ジェフリィ・エル．; David Heller; ヘラー・デイビッド
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2003-04-25
Filing date: 2010-01-18
Publication date: 2010-07-01
Anticipated expiration: 2024-04-15
Also published as: USRE47934E1; US6728729B1; JP2008171442A; CN100533435C; JP5358463B2; EP1843260A2; US20040215611A1; CN1768338A; JP2007525726A; WO2004097683A3; EP1843260A3; JP4469398B2; WO2004097683A2; EP1618501A2; USRE45793E1; JP4176801B2; US7698297B2

Abstract

【課題】ネットワークを隔ててメディアにアクセスする方法およびシステムを提供する。
【解決手段】本発明は、一般にメディアがネットワークを隔てて提供されることを可能にする。クライアントはメディア情報をサーバから要求し、それによりクライアントはサーバのデータベースローカル代理を作りえる。クライアントはそれからメディア情報をローカルに管理する。クライアントが所望のメディアを選択するとき、それはネットワークを隔てての選択を要求する。サーバはそれから選択されたメディアを送達する。
【選択図】図５

Description

本発明は、ディジタルメディアに関し、より具体的にはディジタルメディアにネットワークを介してアクセスすることに関する。

情報を共有できるコンピュータの能力は、情報化時代には最も重要である。ネットワークは、コンピュータ群が互いに通信できるメカニズムである。一般に、リソースを提供するデバイスはサーバと呼ばれ、それらリソースを利用するデバイスはクライアントと呼ばれる。ネットワークのタイプに依存して、デバイスは、あるタイプのタスクに専用であったり、またはリソースを与えたり要求したりするのに依存してクライアントおよびサーバの両方として働いたりする。

ますます、人々が共有したいリソースのタイプは、エンターテイメントに関するものである。特に、音楽、映画、写真、およびプリントは、ネットワークを通してアクセスしたいと思うエンターテイメント関連のメディアである。例えば、音楽ライブラリは、書斎の家庭コンピュータ上に常駐し、メディアの所有者はリビングで音楽を聴きたいかもしれない。

しかし、メディアデータを共有することは、ネットワークの負荷が大きいプロセスでありえる。人々は、ネットワーク上の負荷を低減し、大きなデータ転送を扱うためにネットワークの能力を増すことに大きな資源を投入してきた。圧縮技術およびネットワークの帯域幅の進歩により、ネットワークを通した情報のスループットは、ここ何年かで飛躍的に増加してきている。

前述の技術は、多くのアプリケーションでうまく働くが、ディジタルメディアを転送する能力をさらに改善するための努力が続けられている。

本発明は、ネットワークを隔ててメディアを取り出す方法を提供する。まず、クライアントは、サーバを含むネットワークに接続する。このサーバは、メディアおよび関連付けられたメディア情報を有する少なくとも１つのメディアデータベースを含む。クライアントはそれから、メディア情報の少なくとも一部についてサーバにクエリーし、それからクエリーに応答してメディア情報を受け取る。クライアントはそれから、クライアント側メディアマネージメントシステムを用いて、受け取られたメディア情報を管理する。受け取られたメディア情報の管理は、メディアを選択することを含む。クライアントは、選択されたメディアをネットワークを隔てて要求し、要求に応答して、要求されたメディアを受け取る。

他の局面において、クライアントは、ネットワークに接続した後、サーバ情報および能力についてサーバにクエリーする。クライアントはそれから、サーバを特定するレスポンスを受け取り、クライアントにその能力について知らせる。サーバ情報を受け取った後、クライアントは、データベース列挙についてサーバにクエリーし、全てのデータベース、どのくらい多くのメディアが利用可能であり、かつどのくらい多くのメディアコレクションが利用可能であるかを列挙するレスポンスを受け取る。データベース特定の後、クライアントは、データベース中のメディアコレクションの列挙についてサーバにクエリーし、メディアコレクションを特定するレスポンスを受け取る。クライアントはそれから、特定されたメディアコレクションに関連付けられたデータについてサーバにクエリーし、このクエリーは、デフォールトによって与えられるのとは異なる詳細さのレベルを要求することができる。メディアコレクションクエリーに対するレスポンスは、要求された詳細さのレベルで、特定されたメディアコレクションに関連付けられたデータを特定する。クライアントはそれから、特定されたメディアコレクションを実行し、メディアコレクションがメディアを必要とするときにサーバからメディアを要求し、要求されたメディアを受け取る。

さらに他の局面において、本発明は、クライアント上のメディアデータベース表現が最新であることを確実にする方法を提供する。サーバはまず、メディアデータベースが変更されるたびに現在のリビジョン指示子にアップデートするメディアデータベースを提供する。それから、サーバはクライアントから要求を受け取り、この要求は、クライアントによって提供されたリビジョン指示子を含むデータベースに関する。要求を受け取った後で、サーバは、現在のリビジョン指示子をクライアントによって提供されたリビジョン指示子と比較する。サーバは、もしクライアントによって提供されたリビジョン指示子が現在のリビジョン指示子と一致しなかったら、現在のリビジョン指示子の少なくとも識別を含むレスポンスでそれから要求に応答する。

本発明が実現されえる例示的環境を示すブロック図である。図１に示されるサーバ上のサーバ側メディアマネージメントシステムの組織構成を示すブロック図である。図１に示されるクライアントのうちの１つの上のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。図２に示されるサーバ側メディアマネージメントシステムの特徴を決定するのに用いられえるある技術を示す代表的な制御フロー図である。図２に示されるサーバ側メディアマネージメントシステムのデータベースを列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。図５に示されるクライアント側メディアマネージメントシステムの曲レコードの部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。図２に示されるサーバ側メディアマネージメントシステムのプレイリストレコードの部分を列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。図６に示されるクライアント側メディアマネージメントシステムのプレイリストレコードの部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。図７に示されるクライアント側メディアマネージメントシステムからいったん曲が選択されて、曲データベースから曲を取り出すのに用いられえる技術を示す代表的な制御フロー図である。図４Ｂに示されるサーバ・データベース要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。図４Ｃに示されるデータベース・曲要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。図４Ｅに示されるプレイリスト・曲要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。図１に示されるクライアントおよびサーバがシンクロされることを確かにするのに用いられえる一つの技術を示す代表的な制御フロー図である。本発明のさまざまな実施形態が実現されえる例示的コンピューティングデバイスを示す図である。

本発明は、添付の図面と併せて以下の記載を参照して最もよく理解されるだろう。

図面において、同様の参照番号は同様の構成要素を示すことが理解されよう。また、図面中の図示は必ずしも正しい縮尺ではない。

以下の記載では、本発明の完全な理解のために多くの具体的な詳細が述べられる。しかし、本発明は、これら特定の詳細の一部または全てがなくても実施されえることは当業者には明らかだろう。他の場合には、よく知られたプロセスステップは、本発明の趣旨を不必要にぼかさないために詳細には記載されない。

本発明は、一般に、クライアントマシンがサーバ上のメディアデータベースにアクセスすることを可能にする。サーバ上のデータおよびメタデータの両方は、さまざまなやり方でメディアを記述および整理し、サーバがメディアを操作できるようにする。メディアマネージメントシステムをサーバが実行するのに頼る代わりに、クライアントは、データおよびメタデータを要求し、それからクライアント上でサーバの代理を実質的に作るローカルメディアマネージメントシステム上でその情報を利用する。いったんメディアがクライアント側のメディアマネージメントシステムを通してクライアント上で選択されると、クライアントは、サーバからのメディアを要求でき、サーバはメディアをクライアントに伝達できる。

本発明は、「シック」および「シン」クライアントの両方をサポートできる。シッククライアントは、典型的には、カリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiTunes（商標）のような、十分なユーザインタフェース機能をサポートし、かなりのプロセッサおよびメモリリソースを有するハードウェアデバイス上で動作するソフトウェアプログラムである。シンクライアントは、限られたユーザインタフェース機能を有し、少ない処理およびメモリリソースを有するハードウェアデバイス上で動作するソフトウェアプログラムである。本発明は、シッククライアントに適切なロバストなコントロール属性を可能にし、シンクライアントのために最低限のコントロール属性にも適応できる。

一般に、クライアントは、メディアがサーバ上で利用可能であるかを決定するためにまず要求をする。それから、クライアントは、サーバ上で利用可能であるメディアの代理をクライアント上に作るために一連の要求をしえる。この代理は、サーバ上で利用可能であるメディアに関する情報（「メディア情報」）を含む。シッククライアントは、サーバの利用可能なメディアの完全な代理を取り出すことを選んでもよく、一方、シンクライアントは、サーバの利用可能なメディアの部分的な代理を取り出すことを選んでもよい。メディア情報をサーバから受け取った後、クライアント（そのユーザによって指示されるように）は、それからサーチ、ブラウズ、ソート、または他の対話を今やクライアント上に常駐するメディア情報と行うことができる。さらに、クライアント（そのユーザによって指示されるように）は、典型的には提示される（例えば再生される）べきメディアアイテムを選択する。このような場合には、選択されたメディアアイテムについてのメディアコンテンツは、サーバからクライアントへストリーミングされる。

加えて、クライアントは、メディアデータベースが変わったときに通知をサーバから受け取ることができる。複数の接続は、クライアントがある接続を用いてメディアにアクセスする一方で、他の接続を用いてデータベースが変わった通知を待つ、またはメディアリスティングをブラウズすることを可能にする。

図１は、本発明が実現されえる例示的環境を示すブロック図である。ネットワーク１０５は、サーバ１１０をさまざまなクライアント１１５、１２０、１２５、および１３０に結合する。ネットワーク１０５は一般に、ＬＡＮ、ＷＡＮまたはインターネットのようなデータネットワークでありえる。サーバ１１０は、専用のデバイスであっても、そうでなくてもよい。図１に示される例では、サーバ１１０は汎用のコンピュータである。さまざまなクライアント１１５、１２０、１２５、および１３０は、シックまたはシンクライアントでありえ、さまざまなレベルの処理パワーを持つ。クライアントは、携帯コンピュータ１１５、デスクトップコンピュータ１２０、カリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiPod^TMのような専用デバイス１２５、またはネットワーク１０５を通して働くよう設計されるさらにネットワークアウェアなオーディオ／ビデオコンポーネント１３０を含みえる。簡単のために、以下の説明では、携帯コンピュータクライアント１１５だけがサーバ１１０からの情報を要求すると想定する。

図２は、サーバ１１０上のサーバ側メディアマネージメントシステム２００の組織構成を示すブロック図である。サーバ側メディアマネージメントシステム２００は、メディアマネージャ２１０および音楽データベース２０５を含む。メディアマネージャ２１０は、音楽データベース２０５へのアクセスをコントロールする。より具体的には、メディアマネージャ２１０は、クライアント１１５から要求を受け取り、音楽データベースにアクセスし、かつレスポンスをクライアント１１５に返す。

音楽データベース２０５は、音楽データベース２０５内でメディア（すなわちメディアアイテム）を分類、識別、および／または記述するのに用いられる多くのレコード２１５および２２０を有する。簡単のために、以下の説明は、サーバ１１０上に含まれるディジタルメディアは、ネットワーク１０５上でストリーミングされえる音楽ファイルだけを含むと想定する。本明細書でなされる「曲」または「音楽」への参照は、任意の形態のディジタルメディアに一般化され、このディジタルメディアは、サウンドファイル、画像データ、ムービー、テキストファイルまたはディジタル的にコンピュータ上に記憶されえる任意の他のタイプのメディアを含みえることが理解されよう。同様に、「プレイリスト」への任意の参照は、メディアのコレクションに一般化されえ、これは複合ディジタルメディアのコレクションを含みえる。

メディアマネージャ２１０は、例えば、サーバの名前、用いられるデータベースのバージョン、必要とされるセキュリティのタイプ、サーバに利用可能なデータベースの数、非標準のコンテンツコードがサポートされるか、持続識別（persistent identification）がサポートされるか、などを含みえるデータベース２０５についての情報を有し、または獲得しえる。データベース２０５についての情報は、単一のレコードファイル中に存在しえ、または必要に応じてさまざまな情報の部分を特定しつつ部分的にまたは完全にオンデマンドで生成されえることが当業者には理解されよう。

曲レコード２１５は、データベース２０５内で利用可能なそれぞれのメディアアイテムについてのメタデータを含む。メタデータは、例えば、曲の名前、識別番号、持続識別番号、アーチスト、アルバム、曲のサイズ、曲のフォーマット、必要とされるビットレート、および任意の他の適切な情報を含みえる。もちろん、情報のタイプは、メディアのタイプに依存しえる。ビデオファイルは、追加でディレクタおよびプロデューサーのフィールドを有しえるが、アルバムのフィールドを使わなくてもよい。静止画は、ビットレート情報は必要ないだろう。いくつかのフィールドは標準であるが、他のものはある種のアプリケーションに特定でありえる。例えば、ビデオ信号は、第２オーディオプログラム（ＳＡＰ）情報を有しえる。クライアントが適切に非標準のコンテンツコードを処理できることを確かにするメカニズムは、図４Ａに関連して記載される。

識別番号および持続識別番号の両方が用いられえる。もしサポートされるなら、持続識別は、サーバのリスタートにわたっても同じ情報にアクセスするために用いられえる。典型的には、サーバは、メディアマネージメントシステム２００がリスタートするたびにそれぞれのレコードに新しい識別番号をアサインする。しかし、持続識別番号は、そのレコードが利用可能である限り同じであり続ける。

プレイリストレコード２２０は、音楽データベース２０５内で利用可能なそれぞれのプレイリストについての情報を含む。さらに、与えられたプレイリストについての情報は、プレイリスト内の曲のそれぞれについての識別番号を含みえる。プレイリストは、任意の特定の順番であってもよく、そうでなくてもよいメディアのコレクションである。ユーザは、ジャンル、ムード、アーチスト、オーディエンス、または任意の他の意味のある構成によってメディアを統合することを選びえる。サーバ１１０上のプレイリスト２２０は、ふつうその音楽データベース２０５内に含まれるメディアしか含まないが、プレイリストレコード２２０が他のサーバ上に記憶されたメディアまたはプレイリストを含んではならない理由はない。しかし、サーバ側メディアマネージメントシステム２００の実現に依存して、ある種の非標準のコンテンツコードが用いられなければならないかもしれない。

図３は、クライアント１１５のうちの１つの上のクライアント側メディアマネージメントシステム３００の組織構成を示すブロック図である。クライアント側メディアマネージメントシステム３００は、メディアマネージャ３０５を含む。メディアマネージャ３０５は、サーバ１１０における音楽データベース２０５の少なくとも一部をクライアント１１５上に複製するように、サーバ側メディアマネージメントシステム２００のメディアマネージャ２１０とネットワーク１０５を通して対話する。クライアント側メディアマネージメントシステム３００が最初にスタートするとき、それはサーバ１１０上のメディアにアクセスできないが、それはまだどんなメディアが利用可能であるかについてのなんらの情報もそれが有していないからである。

図４Ａは、サーバ側メディアマネージメントシステム２００の特徴を決定するのに用いられえるある技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線４０３および４０６によって表される。４０９において、クライアント１１５は、ネットワーク１０５に接続し、まずサーバ１１０を知ることになる。クライアント１１５は、それがネットワーク１０５と対話できるようにする任意の接続メカニズムを用いえる。例えば、もしクライアント１１５がカリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiBook^TMであったなら、それは、自動でそれ自身をネットワーク１０５にコンフィギュレーションするために、同じくカリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なRendezvous^TMネットワーク技術を用いえる。もしクライアントがサーバ１１０を知らないなら、他のメカニズムが用いられえる。例えば、ユーザは、手動でサーバ１１０を探してもよく、またはユーザは、直接にサーバ１１０のアドレスを入力してもよい。

いったんクライアント１１５が、サーバ１１０を知ると、それはサーバ情報要求をサーバ１１０に４１２において送りえる。サーバ情報要求は、任意の他のトランザクションを試みる前に、サーバから情報を得るためにふつう用いられる。もしネットワーク１０５が、ＴＣＰ／ＩＰプロトコルを用いるなら、要求は、ＨＴＴＰＧＥＴ要求としてフォーマットされえる。ＧＥＴ要求は、追加の拡張子がその要求に追加されることも可能にし、それにより例えば、クライアント１１５は、クライアント側メディアマネージメントシステム３００についての情報を含ませることができる。

４１５において、サーバは、サーバによってサポートされる、または必要とされる一連の属性を記述する情報でサーバ情報要求に応答する。この情報は、例えば、サーバ側メディアマネージメントシステム２００についての情報、利用可能なデータベースの数、ログインプロシージャが必要か、およびどのようなログインプロシージャが必要か、アップデートがサポートされるか、持続識別番号がサポートされるか、非標準のコンテンツコードがサポートされるか、およびプロトコルバージョンを含みえる。

クライアント１１５および４１５に提供される情報は、クライアント側メディアマネージメントシステム３００がサーバ１１０の能力を理解することを可能にする。クライアント１１５は、サーバ１１０を識別できるが、クライアント１１５は、まだ利用可能なメディアについてのなんらの情報も有していない。

もし、クライアント１１５が、サーバ１１０が、４１８において、非標準のコンテンツコードがサポートされるという指示と共にサーバ情報要求に応答したと決定するなら、クライアント１１５は、オプションでコンテンツコード要求を４２１において発行しえる。コンテンツコード要求は、クライアント１１５が、サーバ１１０によってサポートされるコンテンツコードのリストおよびそれにマッピングされた関連付けられたストリング名を得ることができる一つのメカニズムである。

ストリング名を含ませることによって、複数の開発者が彼らの個別の製品のために同じコードを用いることができる。例えば、ある開発者がコード「１６０００」を、ユーザがネットワーク上で対応するアルバムを購入することができるようにする属性に割り当てることが可能となり、一方で、他の開発者は同じコードを、ユーザが聴いている曲の歌詞をユーザに提供する属性に割り当てることができる。ストリング名が含まれることを許すことによって、クライアント１１５は、それがコンテンツコードをサポートできるかを決定できる。ストリング名のユニークさは、例えば、開発者のＵＲＬをストリング名の一部として含ませることによって確保されえる。

４２４において、サーバ１１０は、コードおよびそれらに関連付けられたストリング名でコンテンツコード要求に応答する。４２７において、クライアント１１５は、それが認識できないコード／ストリングのペアを単に無視できる。そうでなければ、クライアント１１５が認識できないこれらコード／ストリングペアについては、クライアント１１５は、そのコードを関連付けられたストリング名と関連付ける。

４３０において、クライアント１１５はサーバ１１０にログインする。ログインプロシージャは、ユーザ名（またはアカウント名）およびパスワードを必要としえ、それによりクライアントのユーザが認証されえる。ログインプロシージャは、サーバ１１０がそれを要求する場合だけ必要とされる。ある種のセキュリティプロトコルは、クライアント１１５による全ての将来の要求が、セッション識別番号のような所定のパラメータを含むことを要求しえる。

いったんログインすると、クライアント１１５は、音楽データベース２０５のそのローカル代理にデータを埋め始める。図４Ｂは、サーバ側メディアマネージメントシステム２００のデータベースを列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線４０３および４０６によって表される。４３３において、クライアント１１５は、サーバ・データベース要求を発行しえ、これはサーバ１１０から全ての音楽データベースのリストを取り出すのに用いられえる。このサーバ・データベース要求は、インデックスレンジおよび／またはクエリーを追加で含みえる。シックおよびシンクライアントの両方に利用可能であるが、シンクライアントは、インデックスレンジおよび／またはクエリーを用いて、それぞれのサーバレスポンス中に含まれるデータの量を制限しえる。

インデックスレンジは、第１アイテムの位置（またはインデックス）および要求されたアイテムの数に基づいて、レスポンス中で戻されるアイテムを、アイテムの総セットのうちのサブセットに制限するために任意の要求において用いられえる。例えば、インデックスレンジは、サーバから第２音楽データベース、音楽データベースから曲１０から２０、音楽データベースから最後５プレイリスト、与えられたプレイリストから最初の５曲、または音楽データベース中の４２番目の曲を要求するのに用いられえる。

クエリーは、特定された基準に基づいて、レスポンス中で戻されるアイテムを、アイテムの総セットのうちのサブセットに制限するために任意の要求において用いられえる。例えば、クエリーは、所定の年以降のデータベース中の曲、その名前にある語を含むプレイリスト、その名前にある語を含まないデータベース中の曲、またはこれらの組み合わせを要求しえる。

サーバ・データベース要求を４３６において処理した後、サーバ１１０は、レスポンスを４３９において発行する。もしインデックスレンジおよび／またはクエリーが与えられなかったなら、レスポンスは、サーバ１１０において利用可能な全ての音楽データベースの完全なリストと共に、１つ以上の音楽データベースについての情報を含むことになる。それぞれのデータベースについての情報は、例えば、データベース識別番号、持続データベース識別番号、それぞれのデータベースの名前、曲の数、およびプレイリストの数を含みえる。この情報で、クライアント側メディアマネージメントシステム３００は、サーバ１１０における１つ以上の音楽データベースの大まかな構造を知ることになる。

図５は、サーバ・データベース要求への応答を受け取った後の図３に示されるクライアント側メディアマネージメントシステム３００の組織構成を示すブロック図である。４４２において、クライアント１１５は、音楽データベース５１０、利用可能な曲レコード５１５の数、および利用可能なプレイリスト５２０の数を特定できる。いったん音楽データベース５１０の大まかな構成が知られると、クライアント１１５は、任意の技術を用いてその代理にデータを埋めることができる。

図４Ｃは、特定のデータベース５１０についてのクライアント側メディアマネージメントシステム３００の曲レコード５１５の部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線４０３および４０６によって表される。４４５において、クライアントは、利用可能な曲についてのメタデータを得るためにデータベース・曲要求を発行する。

シッククライアントは、それがネットワークトラフィックを前倒しできるように、データベース・曲要求を発行することを選びえる。いったん曲についてのメタデータが受け取られて記憶されると、クライアント１１５は、メタデータを再び要求する必要がない。プレイリストは、正しく曲を特定しさえすればよく（例えば曲識別番号を用いて）、クライアント側メディアマネージメントシステム３００は、それを既に受け取られたメタデータに関連付けられえる。

シンクライアントは、インデックスレンジ、クエリー、メタデータフィールド指定子を発行するか、または４４５を全部スキップすることを選びえる。メタデータフィールド指定子は、ある種のメタデータフィールドだけが望まれることを指示する。４４５を用いるシッククライアントは、これら同じインデックスレンジ、クエリーまたはメタデータフィールド指定子の技術を用いることを選びえる。例えば、曲メタデータ要求をある種のジャンルの曲だけに限定することは、ユーザに異なるユーザ体験を提供するために用いられる技術でありえる。

サーバ１１０は、任意の必要なフィルタリング操作を４４８において実行し、それから４５１において応答を発行する。図６は、データベース・曲要求への応答を受け取った後の４５３におけるクライアント側メディアマネージメントシステム３００の組織構成を示すブロック図である。曲レコード６０５は、サーバ側曲レコード２１５の部分的または完全な代理のいずれかでありえ、例えば、曲の名前、識別番号、持続識別番号、アーチスト、アルバム、曲のサイズ、曲のフォーマット、必要とされるビットレート、および任意の他の適切な情報を含みえるメタデータを有する。もしサーバ側マネージメントシステム２００が複数のデータベースを有したなら、データベース・曲要求（もし用いられるなら）は、それぞれのデータベースについて発行されなければならないだろう。

図４Ｄは、サーバ側メディアマネージメントシステム２００のプレイリストレコード２２０部分を列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線４０３および４０６によって表される。

４５４において、クライアントは、利用可能なプレイリストのリストを得るためにデータベース・プレイリスト要求を発行する。サーバ１１０上のプレイリストは、ユーザが特定するか、またはサーバ側メディアマネージメントシステム２００によって自動的に生成されるかのいずれかでありえる。例えば、「ベースプレイリスト」は、曲データベース２０５の全体にある全ての曲を含む特別なプレイリストとして自動的に作られえ、一方、「ジョンレノンのプレイリスト」は、ユーザが作ったジョンレノンによる曲のコレクションでありえる。

データベース・プレイリスト要求を受け取り、任意の必要なフィルタリング操作を行った後、サーバ１１０は応答を４５７において発行する。この応答は、音楽データベース２０５中の全てのプレイリストのリストおよびこれらプレイリストについての情報を含む。このプレイリストについての情報は、例えば、プレイリストについての識別番号および／または持続識別番号、および提供されたかもしれない任意の他の情報（例えばプレイリスト中の曲が順番通りになっているか、またはシャッフルされえるか）を含みえる。複数のデータベース・プレイリスト要求は、複数のデータベースを埋めるために必要とされえる。

図４Ｅは、クライアント側メディアマネージメントシステム３００のプレイリストレコード５２０の部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線４０３および４０６によって表される。いったんプレイリストが４６０において特定されると、クライアント１１５は、そのプレイリストについてのプレイリスト・曲要求を４６３において送る。操作４４５から４５１が既に実行されたかに依存して、プレイリスト・曲要求は、曲レコード６０５を埋めるためにそれぞれの曲に付随するメタデータも伝達されるよう、追加で要求しえる。サーバ１１０に既に受け取られた曲レコード６０５を知らせるメカニズムを有しないシッククライアントは、重複した曲レコード６０５を受け取るリスクを冒すことになるが、曲レコード６０５を保持しなかったシンクライアントは、それぞれのプレイリストと共に曲メタデータを要求することから利益を享受するかもしれない。

プレイリスト・曲要求を受け取り、任意の必要なフィルタリング操作を実行した後で、サーバ１１０は、要求された情報を含む応答を４６６において発行する。図７は、プレイリスト・曲要求への応答を受け取った後の４６９におけるクライアント側メディアマネージメントシステム３００の組織構成を示すブロック図である。クライアント１１５およびサーバ１１０間のプレイリスト・曲トランザクションが完了するたびに、他のプレイリストレコード７０５が埋められる。プレイリストレコード７０５は、対応するサーバ側プレイリストレコード２２０の完全なまたは部分的な代理でありえる。複数のプレイリスト・曲要求は、複数のプレイリストを埋めるために必要されえる。

図４Ｆは、いったん曲が選択されると、曲データベース２０５から曲を取り出すのに用いられえる技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線４０３および４０６によって表される。

４７２において、クライアント１１５は、曲データをサーバ１１０から取り出すために、曲・データ要求を発行する。もし単一の曲がサーバ１００上に複数のフォーマットで記憶されるなら、曲・データ要求はフォーマット識別子を含みえる。フォーマット識別子は、その曲が例えばＭＰＥＧ３でエンコードされたデータ（「ｍｐ３」）、ＭＰＥＧ４アドバンスオーディオコーディング（「ｍ４ａ」）、オーディオインターチェンジファイルフォーマット（「ａｉｆｆ」）、またはウィンドウズサウンドファイル（「ｗａｖ」）で要求されているかを特定しえる。４７５において、サーバ１１０は、オーディオファイルをクライアント１１５に届ける。ある実施形態において、サーバ１１０は、ｈｔｔｐヘッダに曲データをアペンドすることによって曲をストリーミングし、したがってクライアント１１５において曲を再生するために、クライアント１１５がデータを適切にパージングする責任を負うことになる。

先の記載は、もしサーバ側メディアマネージメントシステム２００上のデータがセッション中に変更されても、クライアント１１５をアップデートするためのメカニズムが用いられないと想定している。例えば、プレイリスト７０５のクライアント側代理は、対応するサーバ側プレイリスト２２０の最も新しいバージョンを正確には反映しないかもしれない。

図８は、クライアント１１５およびサーバ１１０がシンクロされることを確かにするのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント１１５およびサーバ１１０によって実行される操作は、対応する垂直な線８０５および８１０によって表される。

８１５において、クライアント１１５は、メディアデータをサーバ１１０から取り出すためにアップデート要求を発行する。アップデート要求は、サーバ１１０（例えば音楽データベース２０５）上のデータが変更するときにクライアント１１５は知らせて欲しいとサーバ１１０に知らせるフラグでありえる。ある実施形態において、このフラグは、リビジョン番号またはタイムスタンプのようなリビジョン指示子である。

８２０において、サーバ１１０はアップデート要求を処理する。ある実施形態においてサーバ１１０は、サーバの音楽データベースが、クライアントのその音楽データベースについての代理に比較して変化するまで、アップデート要求には応答しない。もしリビジョン番号が８１５において用いられたなら、サーバ１１０は、クライアント１１５によって提供されたリビジョン番号を、現在のリビジョン番号と比較し、変更がなされたかを決定する。サーバ１１０のリビジョン番号は、サーバ１１０における音楽データベース２０５のバージョンを表す。レコード２１５または２２０への任意の後に続く変更は、サーバ１１０がそのリビジョン番号を一つだけ増やすようにさせえる。システムの要求に依存して、レコード２１５または２２０への変更群のグループはバッチされえ、それによりリビジョン番号は一度だけ増加しえる。バッチさせることは、操作によって（例えばファイル群をグループとしてサーバに追加する）、時間によって（例えば最も新しい変更がなされてから所定の期間だけ待つことによって、他の変更がなされないことを確かにする）、または操作の数によって（例えば所定の数の変更の後、リビジョン番号を変える）などを含む標準的な技術によって実行されえる。

いったんサーバ１１０が、クライアントによって提供されるリビジョン番号がもはや現在のリビジョン番号と一致しないと決定すると、応答が８２５において発行される。ある実施形態において、この応答は、サーバの現在のリビジョン番号を含む。サーバ１１０は、それからサーバの現在のリビジョン番号の変化をモニタし続けることができるが、クライアント１１５は、サーバの現在のリビジョン番号で新しいアップデート要求を再発行するかもしれず、実質的に操作８１５をアップデートされたリビジョン番号で反復するかもしれない。システムによっては、サーバがアップデート要求を初めて受け取ったときに、サーバ１１０にアップデート応答を強制的に発行させるために、発行クライアント１１５はいつもクライアント生成リビジョン番号「１」から始まり、サーバ１１０はいつもリビジョン番号「２」から始まるようにさせるかもしれない。このようなアプローチは、クライアント１１５に、音楽データベース２０５のそのローカル代理をサーバ・データベース要求（図４Ｂの４３３を参照）で埋めるきっかけを提供しえる。加えて、アップデート応答はまた、サーバが接続を切断しようとしている（おそらくはタイムアウトまたはサーバシャットダウンのために）ことを、例えば現在のリビジョン番号０を発行することによって、クライアント１１５に通知するために用いられえる。

アップデート要求に加えて、クライアント１１５はまたリビジョン番号フィールドを要求４３３、４４５、４５４、および４６３の任意のものの中に含みえる。サーバ１１０は、それから要求・バイ・要求で、要求で提供されるリビジョン番号を特定の要求についてのリビジョン番号とチェックする。もしリビジョン番号が一致しなかったなら、サーバ１１０は、アップデート応答を発行し、現在のリビジョン番号およびおそらくは対応する応答を特定する。そうでなければ、サーバ１１０は、前述のように要求に従う。

ある実施形態において、データベース要求４３３、４４５、４５４、および４６３は、ネットワークトラフィックを減らすために（かつより高い応答性を通してユーザの体験を改善するために）漸次アップデートをさらにサポートしえる。漸次アップデートは、クライアントが過去のリビジョン番号から現在のリビジョン番号への変化だけを要求することを可能にする。もし、例えば、クライアント１１５がそのプレイリストレコード７０５をリビジョン「５」からの情報で埋め、それからクライアントは、サーバ１１０によって最新のリビジョンは「８」であると通知されるなら、クライアントは、新しいプレイリスト・曲要求４６３を発行しえ、それによりリビジョン「５」からリビジョン「８」へ変化した本発明だけを要求できる。サーバ１１０が、それぞれのリビジョン番号からの変更の過去のレコードへのアクセスを維持または保有する限り、サーバは漸次要求に従うことができる。

しかし最適化によれば、サーバ１１０が、漸次要求に従うことが全体の応答を再送することよりも実際に効率的かを決定することが可能になるかもしれない。ある状況下では（例えばプレイリスト中の半分より多い曲が削除されたとき）、漸次応答の代わりにフルのプレイリスト・曲応答４６６で応答するほうがネットワークリソースをより少なくしか使わないだろう。しかし、プレイリスト・曲応答４６６がフルの応答を提供するとき、クライアント１１５がその情報を適切に扱えるようにするために、その応答は、そのデータが漸次アップデートを表さない旨の指示を含むのが有利になろう。

一般に、本発明の技術は、ソフトウェアおよび／またはハードウェアで実現されえる。例えば、これらはオペレーティングシステムにおいて、別個のユーザプロセスにおいて、ネットワークアプリケーションにバウンドされるライブラリパッケージにおいて、または特別に構築されたマシン上で実現されえる。本発明の具体的な実施形態において、本発明の技術は、オペレーティングシステムおよび／またはそのオペレーティングシステム上で走るアプリケーションプログラムのようなソフトウェアで実現される。

本発明の技術のソフトウェアまたはソフトウェア／ハードウェアのハイブリッド実現例は、メモリ中に記憶されたコンピュータプログラムによって選択的にアクティベートされた、または再コンフィギュレーションされた汎用プログラム可能なマシン上で実現されえる。代替として、本発明の技術は、パーソナルコンピュータ、ワークステーションまたはサーバのような汎用ネットワークホストマシン上で実現されえる。さらに、本発明は、少なくとも部分的に汎用コンピューティングデバイス上で実現されえる。

ここで図９を参照して、本発明の技術を実現するのに適するコンピューティングデバイス９００は、マスタ中央処理ユニット（ＣＰＵ）９０５、インタフェース９１０、メモリ９１５およびバス９２０を含む。適切なソフトウェアまたはファームウェアの制御下で動作するとき、ＣＰＵ９０５は、所望のコンピューティングデバイスの機能に関連付けられた特定の機能を実現することを担う。ＣＰＵ９０５は、オペレーティングシステム（例えばMac OS X）、および任意の適切なアプリケーションソフトウェア（例えばiTunes）を含むソフトウェアの制御下で全てのこれら機能を好ましくは達成する。

ＣＰＵ９０５は、マイクロプロセッサのモトローラファミリーまたはマイクロプロセッサのＭＩＰＳファミリーからのような１つ以上のプロセッサを含みえる。代替としては、プロセッサは、コンピューティングデバイス９００の動作を制御するために特別に設計されたハードウェアである。

インタフェース９１０は典型的にはインタフェースカードとして提供される。一般に、これらは、データパケットをネットワーク上で送ったり、受け取ったりするのを制御し、時にはコンピューティングデバイス９００と共に用いられる他の周辺機器をサポートする。提供されえるインタフェースとしては、イーサネットインタフェース、フレームリレーインタフェース、ケーブルインタフェース、ＤＳＬインタフェース、トークンリングインタフェースなどがある。加えて、高速イーサネットインタフェース、ギガビットイーサネットインタフェース、ＡＴＭインタフェース、ＨＳＳＩインタフェース、ＰＯＳインタフェース、ＦＤＤＩインタフェース、ＡＳＩインタフェース、ＤＨＥＩインタフェースなどのようなさまざまな非常に高速のインタフェースが提供されえる。一般に、これらインタフェースは、適切なメディアと通信するのに適切なポートを含みえる。場合によっては、それらは独立したプロセッサおよび時には揮発性ＲＡＭも含みえる。

コンピューティングデバイスのコンフィギュレーションにかかわらず、それは、ここで記載した技術の機能に関するデータ、プログラム命令および／または情報を記憶するよう構成される１つ以上のメモリまたはメモリモジュール（例えばメモリ９１５のような）を採用しえる。プログラム命令は、オペレーティングシステムおよび／または１つ以上のアプリケーションの動作を例えば制御しえる。

このような情報およびプログラム命令は、ここで記載されたシステム／方法を実現するために採用されえるので、本発明は、ここで記載されたさまざまな操作を実行するプログラム命令、状態情報などを含む機械で読み取り可能な媒体に関する。機械で読み取り可能な媒体の例は、以下に限定されないが、ハードディスク、フレキシブルディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭディスクのような光媒体、フロプティカルディスクのような光磁気媒体、および読み出し専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）のようなプログラム命令を記憶するよう特別に構成されるハードウェアデバイスを含む。本発明は、空間波、光ライン、電気ラインなどのような適切な媒体上を伝搬する搬送波内でも実現されえる。プログラム命令の例は、コンパイラによって作られるような機械語コード、およびコンピュータプログラムによって実行されえる（例えばインタープリタを用いて）高級言語コードの両方を含む。

本発明の例示的実施形態および応用例は、ここに図示され記載されるが、多くの変更および改変が可能であり、それらも本発明の概念、範囲および精神の中に留まり、これら改変は本願を熟読すれば当業者には明らかになろう。したがって、本発明の実施形態は、例示的であって、限定的ではなく、本発明は、ここで与えられた詳細に限定されるべきではなく、添付の特許請求の範囲の範囲および等価物の中で改変されえる。

Claims

ディジタルメディアを取り出す方法であって、
サーバに前記サーバの属性をクエリーし、
前記サーバの前記属性を受け取り、前記属性は、少なくとも１つのディジタルメディアデータベースについての情報を含み、前記少なくとも１つのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションデータまたはそれら両方に関し、
前記サーバに前記メタデータに関連付けられている前記レコードを埋めるのに必要とされる情報をクエリーし
前記メタデータに関連付けられている前記レコードを埋めるのに必要とされる情報を受け取ること
を含む方法。
請求項１に記載の方法であって、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションの両方に関し、前記メタデータに関連付けられる前記レコードを埋めるために複数のクエリーが必要とされる方法。
請求項１に記載の方法はさらに、ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータレコードおよび前記ディジタルメディアメタデータレコード内に含まれる前記情報を管理する方法。
請求項１に記載の方法であって、サーバは、ネットワークを隔ててリモートデバイスである方法。
請求項１から４のいずれかに記載の方法はさらに、
ネットワークを隔ててメディアを要求し、
前記要求されたメディアを受け取ること
を含む方法。
請求項５に記載の方法であって、前記受け取られたメディアをクライアントデバイスにおいて提示することをさらに含み、前記受け取られたメディアを提示することは、前記メディアをユーザのために再生することを含む方法。
請求項６に記載の方法であって、前記クライアントデバイスはメディアプレーヤーであるか、またはメディアプレーヤーを有する方法。
請求項６に記載の方法であって、前記受け取られたメディアは曲に関する方法。
請求項１から８のいずれかに記載の方法であって、前記方法は、コンピュータで読み取り可能な媒体上に命令として記憶される方法。
メディアを取り出す方法であって、
サーバに接続し、前記サーバはメディア情報を含み、
前記サーバに前記メディア情報の少なくとも一部についてクエリーし、
前記クエリーに応答してメタデータを受け取り、少なくとも１つのメタデータアイテムは、前記メディアまたはメディアコレクションに関連付けられており、
少なくとも１つのメタデータアイテムが関連付けられる情報を要求すること
を含む方法。
請求項１０に記載の方法であって、
前記方法は、クライアント側メディアマネージメントシステムによって実行され、
前記クエリーは、前記一部を示し、かつ
前記一部は、少なくとも部分的に前記クライアント側メディアマネージメントシステムが制限されたユーザインタフェース機能を有するか否かに基づく
方法。
請求項１０に記載の方法であって、
前記方法は、クライアント側メディアマネージメントシステムによって実行され、
前記クエリーは、前記一部を示し、かつ
前記一部は、少なくとも部分的に前記クライアント側メディアマネージメントシステムが前記サーバから利用可能な前記メディア情報の全てを記憶するのには充分ではない制限されたメモリを有するか否かに基づく
方法。
請求項１０に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、ユーザにカスタマイズされた体験を提供することに少なくとも部分的に基づく
方法。
請求項１０に記載の方法であって、前記サーバはネットワークを隔てたリモートデバイスである方法。
ネットワークを隔ててメディアを取り出す方法であって、
サーバを含むネットワークに接続し、
前記サーバにサーバ能力についてクエリーし、
前記サーバを記述する前記サーバ能力クエリーに対するレスポンスを受け取り、
前記サーバにデータベース列挙についてクエリーし、
少なくとも１つのデータベースを記述する前記データベース列挙クエリーに対するレスポンスを受け取り、前記記述は、どのくらいのメディアが利用可能であるか、および何個のコレクションが前記少なくとも１つのデータベースから利用可能であるかを含み、
データベースを前記少なくとも１つのデータベースから選択し、
前記選択されたデータベース中のメディアコレクションの列挙について前記サーバにクエリーし、
前記メディアコレクションを記述する前記メディアコレクション列挙クエリーに対するレスポンスを受け取り、
前記記述されたメディアコレクションの中からメディアコレクションを選択し、
前記選択されたメディアコレクションに関連付けられたデータについて前記サーバにクエリーし、前記メディアコレクションデータクエリーは、デフォールトで与えられるのとは詳細さの異なるレベルを要求することが可能であり、
詳細さの前記要求されたレベルにおける前記選択されたメディアコレクションに関連付けられたデータを記述する前記メディアコレクションデータクエリーに対するレスポンスを受け取り、
どのようなメディアが必要とされるかを前記メディアコレクションに基づいて決定し、
前記メディアが必要とされるとき、メディアを前記サーバから要求し、
前記要求されたメディアを受け取ること
を含む方法。
請求項１５に記載の方法であって、前記データベース識別クエリーの前に前記サーバにログインすることをさらに含む方法。
請求項１５に記載の方法であって、
前記サーバにコンテンツコードについてクエリーし、
サポートされるストリング名および前記サーバがサポートされるストリング名と関連付ける対応するコードのリストを含む、前記コンテンツコードクエリーに対するレスポンスを受け取ること
をさらに含む方法。
請求項１５に記載の方法であって、詳細さの前記デフォールトレベルは、メディアの詳細を含まない方法。
請求項１８に記載の方法であって、
前記データベース中のメディアの詳細について前記サーバにクエリーし、
前記メディアの詳細を記述する前記メディア詳細クエリーに対するレスポンスを受け取ること
をさらに含む方法。
請求項１９に記載の方法であって、
データベース列挙フィルタが前記データベース列挙クエリーに含まれる場合には、前記レスポンスは、前記データベース列挙フィルタによって除外されなかったデータベース記述だけを含み、
メディア詳細フィルタが前記メディア詳細クエリーに含まれる場合には、前記レスポンスは、前記メディア詳細フィルタによって除外されなかったメディア詳細だけを含み、
メディアコレクション列挙フィルタが前記メディアコレクション列挙クエリーに含まれる場合には、前記レスポンスは、前記メディアコレクション列挙フィルタによって除外されなかったメディアコレクション記述だけを含み、かつ
メディアコレクションデータフィルタが前記メディアコレクションデータクエリーに含まれる場合には、前記レスポンスは、前記メディアコレクションデータフィルタによって除外されなかったメディアコレクションデータだけを含む
方法。
請求項１９に記載の方法であって、
データベース列挙インデックスレンジが前記データベース列挙クエリーに含まれる場合には、前記レスポンスは、前記データベース列挙インデックスレンジ内に入るデータベース記述だけを含み、
メディア詳細インデックスレンジが前記メディア詳細クエリーに含まれる場合には、前記レスポンスは、前記メディア詳細インデックスレンジによって除外されなかったメディア詳細だけを含み、
メディアコレクション列挙インデックスレンジが前記メディアコレクション列挙クエリーに含まれる場合には、前記レスポンスは、前記メディアコレクション識別インデックスレンジ内に入るメディアコレクション記述だけを含み、かつ
メディアコレクションデータインデックスレンジが前記メディアコレクションデータクエリーに含まれる場合には、前記レスポンスは、前記メディアコレクションデータインデックスレンジ内に入るメディアコレクションデータだけを含む
方法。
請求項１５に記載の方法であって、記述は持続識別子を含む方法。
請求項１５に記載の方法であって、
前記サーバに、クライアント生成リビジョン指示子を含むアップデート要求でクエリーし、
サーバ生成現在リビジョン指示子が前記アップデート要求中に含まれる前記クライアント生成リビジョン指示子と対応しない場合には、サーバ生成現在リビジョン指示子を含む前記アップデート要求に対するレスポンスを受け取ること
をさらに含む方法。
請求項１９に記載の方法であって、
前記データベース列挙クエリーは、クライアント生成データベース列挙リビジョン指示子を含み、
サーバ生成現在データベース列挙リビジョン指示子が前記クライアント生成データベース列挙リビジョン指示子と対応しない場合には、前記データベース列挙クエリーに対するレスポンスは、サーバ生成現在データベース列挙リビジョン指示子を含み、
前記メディア詳細クエリーは、クライアント生成メディア詳細リビジョン指示子を含み、
サーバ生成現在メディア詳細リビジョン指示子が前記クライアント生成メディア詳細リビジョン指示子と対応しない場合には、前記メディア詳細クエリーに対する前記レスポンスは、サーバ生成現在メディア詳細を含み、
前記メディアコレクション列挙クエリーは、クライアント生成メディアコレクション列挙リビジョン指示子を含み、
サーバ生成現在メディアコレクション列挙リビジョン指示子が前記クライアント生成メディアコレクション列挙リビジョン指示子と対応しない場合には、前記メディアコレクション列挙クエリーに対する前記レスポンスは、サーバ生成現在メディアコレクション列挙リビジョン指示子を含み、
前記メディアコレクションデータクエリーは、クライアント生成メディアコレクションデータリビジョン指示子を含み、かつ
サーバ生成現在メディアコレクションデータリビジョン指示子が前記クライアント生成メディアコレクションデータリビジョン指示子と対応しない場合には、前記メディアコレクションデータクエリーに対する前記レスポンスは、サーバ生成現在メディアコレクションデータリビジョン指示子を含む
方法。
請求項２４に記載の方法であって、
前記データベース列挙クエリーに対する前記レスポンスが前記サーバ生成現在データベース列挙リビジョン指示子を含む場合には、前記データベース列挙クエリーを再送し、
前記メディア詳細クエリーに対する前記レスポンスが前記サーバ生成現在メディア詳細リビジョン指示子を含む場合には、前記メディア詳細クエリーを再送し、
前記メディアコレクション列挙クエリーに対する前記レスポンスが前記サーバ生成現在メディアコレクション列挙リビジョン指示子を含む場合には、前記メディアコレクション列挙クエリーを再送し、
前記メディアコレクションデータクエリーに対する前記レスポンスが前記サーバ生成現在メディアコレクションデータリビジョン指示子を含む場合には、前記メディアコレクションデータクエリーを再送すること
をさらに含む方法。
請求項２５に記載の方法であって、
前記データベース列挙クエリーの前記再送は、前記サーバ生成現在データベース列挙リビジョン指示子および前記クライアント現在データベース列挙リビジョン指示子の両方を含み、
前記メディア詳細クエリーの前記再送は、前記サーバ生成現在メディア詳細リビジョン指示子および前記クライアント生成現在メディア詳細リビジョン指示子の両方を含み、
前記メディアコレクション列挙クエリーの前記再送は、前記サーバ生成現在メディアコレクション列挙リビジョン指示子および前記クライアント生成現在メディアコレクション列挙リビジョン指示子の両方を含み、かつ
前記メディアコレクションデータクエリーの前記再送は、前記サーバ生成現在メディアコレクションデータリビジョン指示子および前記クライアント生成現在メディアコレクションデータリビジョン指示子の両方を含む
方法。
請求項２６に記載の方法であって、
前記データベース列挙クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、
前記メディア詳細クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、
前記メディアコレクション列挙クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、かつ
前記メディアコレクションデータクエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含む
方法。
請求項２６に記載の方法であって、
前記データベース列挙クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、
前記メディア詳細クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、
前記メディアコレクション列挙クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、かつ
前記メディアコレクションデータクエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含む
方法。
メディアを送達する方法であって、
サーバ情報についてのクエリーを受け取り、
前記サーバ情報クエリーに対するレスポンスを送り、
データベース列挙クエリーを受け取り、
少なくとも１つの利用可能なデータベースを記述する前記データベース列挙クエリーに対するレスポンスを送り、前記記述は、どのくらい多くのメディアが利用可能であるか、およびどのくらい多くのメディアコレクションが利用可能であるかを含み、
メディアコレクションの列挙を要求するクエリーを受け取ろ、
前記メディアコレクションを記述する前記メディアコレクション列挙クエリーに対するレスポンスを送り、
特定されたメディアコレクションに関連付けられたデータを要求するメディアコレクションデータクエリーを受け取り、
前記特定されたメディアコレクションに関連付けられたメディアを適切なレベルの詳細さで記述する前記メディアコレクションメディアクエリーに対するレスポンスを送り、
メディア要求を受け取り、
前記要求されたメディアを送達すること
を含む方法。
ネットワークを隔ててメディアを取り出す方法であって、
クライアント側メディアマネージメントシステムを提供し、
サーバを含むネットワークに接続し、前記サーバは、少なくとも１つのメディアデータベースを含み、前記少なくとも１つのメディアデータベースは、メディアおよび関連付けられたメディア情報を含み、
前記メディア情報の少なくとも一部について前記サーバにクエリーし、
前記クエリーに応答してメディア情報を受け取り、
前記クライアント側メディアマネージメントシステムを通した前記メディア情報との対話に基づいて少なくとも１つのメディアを選択し、
前記ネットワークを隔てて前記選択されたメディアを要求し、
前記要求されたメディアを受け取ること
を含む方法。
請求項３０に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、少なくとも一部は、前記クライアント側メディアマネージメントシステムが制限されたユーザインタフェース能力を有するか否かに基づく
方法。
請求項３０に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、前記クライアント側メディアマネージメントシステムが前記サーバから利用可能な前記メディア情報の全てを記憶するのに充分ではない制限されたメモリを有するか否かに少なくとも部分的に基づく
方法。
請求項３０に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、ユーザにカスタマイズされた体験を提供することに少なくとも部分的に基づく
方法。
メディアを提供する方法であって、
クライアントに属性について通知し、前記属性は、少なくとも１つのディジタルメディアデータベースについての情報を含み、前記少なくとも１つのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションデータまたはそれら両方に関し、
前記クライアントからの情報についての要求に応答し、前記レスポンスは、前記クライアントが前記メタデータに関連付けられた前記レコードを埋めるために用いられえる情報を含む
を含む方法。
請求項３４に記載の方法であって、
前記少なくとも１つのディジタルメディアデータベースが変更されるときはいつでも、現在のリビジョン指示子に更新し、
前記クライアントからの要求を受け取り、前記要求は前記少なくとも１つのディジタルメディアデータベースに関し、前記要求はクライアント提供リビジョン指示子を含み、
前記現在のリビジョン指示子を前記クライアント提供リビジョン指示子と比較し、
前記クライアント提供リビジョン指示子が前記現在のリビジョン指示子と一致しない場合には、前記現在のリビジョン指示子の識別を少なくとも含むレスポンスで前記要求に応答すること
を含む方法。
請求項３５に記載の方法であって、
前記データベースが変更されるときはいつでも、前記クライアントに前記現在のリビジョン指示子を提供すること
をさらに含む方法。
請求項３５に記載の方法であって、それぞれのリビジョン指示子からの変更の履歴を維持することをさらに含む方法。
請求項３７に記載の方法であって、
前記クライアントからの前記要求は、履歴リビジョン指示子をさらに含み、かつ
前記情報が前記レスポンス内で漸次情報を表すかの指示を提供する
方法。
請求項３８に記載の方法であって、
（ｉ）前記データベースのコンテンツ全体の送信、または（ｉｉ）前記履歴リビジョン指示子から前記現在のリビジョン指示子までになされた変更に対応する前記漸次変更だけの送信のいずれがより効率的であるか決定すること
をさらに含む方法。
クライアント上のメディアデータベース表現が最新であることを確実にする方法であって、
メディアデータベースを提供し、
前記メディアデータベースが変更されるときはいつでも、現在のリビジョン指示子に更新し、
前記クライアントから要求を受け取り、前記要求は、クライアント提供リビジョン指示子を含む前記データベースに関し、
前記現在のリビジョン指示子を前記クライアント提供リビジョン指示子と比較し、
前記クライアント提供リビジョン指示子が前記現在のリビジョン指示子に一致しない場合には、前記現在のリビジョン指示子の指示を少なくとも含むレスポンスで要求に応答すること
を含む方法。
請求項４０に記載の方法であって、
前記データベースが変更されるときはいつでも、前記クライアントに前記現在のリビジョン指示子を提供すること
をさらに含む方法。
請求項４０に記載の方法であって、それぞれのリビジョン指示子からの変更の履歴を維持することをさらに含む方法。
請求項４２に記載の方法であって、
前記クライアントからの前記要求は、履歴リビジョン指示子をさらに含み、かつ
前記情報が前記レスポンス内で漸次情報を表すかの指示を提供する
方法。
請求項４３に記載の方法であって、
（ｉ）前記データベースのコンテンツ全体の送信、または（ｉｉ）前記履歴リビジョン指示子から前記現在のリビジョン指示子までになされた変更に対応する前記漸次変更だけの送信のいずれがより効率的であるか決定すること
をさらに含む方法。
コンピューティングデバイスであって、
プロセッサ、
前記プロセッサに動作可能に接続されたメモリ
を備え、
前記プロセッサは、
メディア情報を含むサーバに接続すること、
前記メディア情報の少なくとも一部について前記サーバにクエリーすること、
前記クエリーに応答してメディア情報を受け取ること、
前記クエリーに応答して前記メディア情報に関連付けられた少なくとも１つのメディアアイテムを要求すること、および
前記メディアアイテムを受け取ること
を含む命令を実行できる
コンピューティングデバイス。
請求項４５に記載のコンピューティングデバイスであって、前記プロセッサは、
サーバ能力について前記サーバにクエリーすること、および
前記サーバを記述する前記サーバ能力クエリーに対するレスポンスを受け取ること
を含む命令を実行するようさらに動作可能であるコンピューティングデバイス。
請求項４５に記載のコンピューティングデバイスであって、前記プロセッサは、
前記サーバにデータベース列挙についてクエリーすること、
少なくとも１つのデータベースを記述する前記データベース列挙クエリーに対するレスポンスを受け取り、前記記述は、どのくらいのメディアが前記少なくとも１つのデータベースから利用可能であるか、および何個のメディアコレクションが前記少なくとも１つのデータベースからまたは両方から利用可能であるかを含むこと、
を含む命令を実行するようさらに動作可能であるコンピューティングデバイス。
請求項４５に記載のコンピューティングデバイスであって、前記メディア情報の少なくとも一部について前記サーバにクエリーすることは、メディアコレクションの少なくとも一部の列挙の要求であるコンピューティングデバイス。
コンピューティングデバイスであって、
プロセッサ、
前記プロセッサに動作可能に接続されたメモリ、および
前記プロセッサに動作可能に接続されたネットワークインタフェース
を備え、
前記プロセッサは、
メディアデータベースを有するサーバを含むネットワークに接続すること、
前記サーバの属性について前記サーバにクエリーすること、
前記サーバの前記属性を受け取ること、前記属性は、少なくとも１つのディジタルメディアデータベースについての情報を含み、それぞれのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションデータに関し、
前記ディジタルメディアメタデータレコードを埋めるのに必要とされる情報について前記サーバにクエリーすること、
前記ディジタルメディアメタデータレコードを埋めるのに必要とされる情報を受け取ること、
前記メディアコレクションデータレコードを埋めるのに必要とされる情報について前記サーバにクエリーすること、
前記メディアコレクションデータレコードを埋めるのに必要とされる前記情報を受け取ること、
ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータレコードおよび前記ディジタルメディアメタデータレコードに含まれる前記情報を管理すること、
前記ネットワークを隔ててメディアを要求すること、および
前記要求されたメディアを受け取ること
を含む命令を実行するよう動作可能である、
コンピューティングデバイス。