JP4469398B2 - ディジタルメディアを取り出す方法および同装置 - Google Patents

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 (11)

1. ディジタルメディアを取り出す方法であって、
   コンピュータが、サーバに前記サーバの属性をクエリーし、
   コンピュータが、前記サーバの前記属性を受け取り、前記属性は、少なくとも１つのディジタルメディアデータベースについての情報を含み、前記少なくとも１つのディジタルメディアデータベースについての情報は、前記ディジタルメディアデータベースに含まれるレコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションのデータまたはそれら両方に関し、
   コンピュータが、前記レコードに関連付けられている前記メタデータを受け取った後に、前記サーバに対して、前記メタデータに関連付けられているレコードの内の１または複数を埋めるために必要とされる情報をクエリーし、前記メタデータは、前記１または複数のレコードに関する第１のレベルの詳細を提供する第１の代理を提供し、
   コンピュータが、前記サーバへのクエリーに応答して、前記１または複数のレコードを埋めるために必要とされる情報を受け取り、受け取った情報を用いて前記１または複数のレコードを埋め、前記埋められた１または複数のレコードは、前記第１のレベルの詳細よりも詳細に、前記１または複数のレコードを表す、前記１または複数のレコードに関する第２のレベルの詳細を提供する第２の代理を提供し、
   コンピュータが、前記情報を用いてネットワークを隔ててディジタルメディアを要求し、
   コンピュータが、前記ネットワークを隔てて、前記要求したディジタルメディアを受け取ること
   を含み、
   前記埋められた１または複数のレコードはローカルデータベースの一部であり、前記１または複数のレコードを埋めることは、前記デジタルメディアデータベースの少なくとも一部を前記ローカルデータベースに複製することである、方法。
2. 請求項１に記載の方法であって、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションデータの両方に関し、前記コンピュータが前記メタデータに関連付けられる前記レコードを埋めるために複数のクエリーが必要とされる方法。
3. 請求項１に記載の方法はさらに、ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータのレコードおよび前記ディジタルメディアメタデータのレコード内に含まれる前記情報を管理する方法。
4. 請求項１に記載の方法であって、サーバは、ネットワークを隔てたリモートデバイスである方法。
5. 請求項１に記載の方法であって、前記受け取られたディジタルメディアをクライアントデバイスにおいて提示することをさらに含み、前記受け取られたディジタルメディアを提示することは、前記ディジタルメディアをユーザのために再生することを含む方法。
6. 請求項１に記載の方法であって、前記方法は、コンピュータで読み取り可能な媒体上に命令として記憶される方法。
7. 請求項１に記載の方法はさらに、
   コンピュータが、前記１または複数のレコードの第３の代理を提供するのに必要とされる情報について前記サーバにクエリーすること
   を含む方法。
8. 請求項１に記載の方法はさらに、
   前記少なくとも１つのレコードの第３の代理を提供するために前記少なくとも１つのレコードをさらに埋めるために必要とされる情報について前記サーバにクエリーすること
   を含む方法。
9. 請求項１に記載の方法であって、
   前記１または複数のレコードを埋めることは、前記１または複数のレコードに対応する１または複数の埋められたレコードを提供する方法。
10. 請求項４に記載の方法はさらに、
    コンピュータが、前記１または複数のレコードを埋めるために必要とされる前記情報を受け取った後に、前記１または複数のレコードを埋めることにより、前記１または複数のレコードに関連付けられている前記メタデータに基づいて、１または複数の埋められたレコードを提供し、
    コンピュータが、前記埋められたレコードの内の少なくとも１つに関連付けられているディジタルメディアを取り出すことを備える方法。
11. ディジタルメディアを取り出すための装置であって、
    サーバに対して前記サーバの属性をクエリーする属性クエリー部と、
    前記サーバの前記属性を受け取る属性受取部と、前記属性は、少なくとも１つのディジタルメディアデータベースについての情報を含み、前記少なくとも１つのディジタルメディアデータベースについての情報は、前記ディジタルメディアデータベースに含まれるレコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションのデータまたはそれら両方に関し、
    前記レコードに関連付けられている前記メタデータを受け取った後に、前記サーバに対して、前記メタデータに関連付けられているレコードの内の１または複数を埋めるために必要とされる情報をクエリーする情報クエリー部と、前記メタデータは、前記１または複数のレコードに関する第１のレベルの詳細を提供する第１の代理を提供し、
    前記サーバへのクエリーに応答して、前記１または複数のレコードを埋めるために必要とされる情報を受け取り、受け取った情報を用いて前記１または複数のレコードを埋める情報受取部と、前記埋められた１または複数のレコードは、前記第１のレベルの詳細よりも詳細に、前記１または複数のレコードを表す、前記１または複数のレコードに関する第２のレベルの詳細を提供する第２の代理を提供し、
    前記情報を用いてネットワークを隔ててディジタルメディアを要求するディジタルメディア要求部と、
    前記ネットワークを隔てて、前記要求したディジタルメディアを受け取るディジタルメディア受取部とを備え、
    前記埋められた１または複数のレコードはローカルデータベースの一部であり、前記１または複数のレコードを埋めることは、前記デジタルメディアデータベースの少なくとも一部を前記ローカルデータベースに複製することである、装置。

Images