ネットワークを隔てたメディアへのアクセス
【課題】ネットワークを隔ててメディアにアクセスする方法およびシステムを提供する。
【解決手段】本発明は、一般にメディアがネットワークを隔てて提供されることを可能にする。クライアントはメディア情報をサーバから要求し、それによりクライアントはサーバのデータベースローカル代理を作りえる。クライアントはそれからメディア情報をローカルに管理する。クライアントが所望のメディアを選択するとき、それはネットワークを隔てての選択を要求する。サーバはそれから選択されたメディアを送達する。
【解決手段】本発明は、一般にメディアがネットワークを隔てて提供されることを可能にする。クライアントはメディア情報をサーバから要求し、それによりクライアントはサーバのデータベースローカル代理を作りえる。クライアントはそれからメディア情報をローカルに管理する。クライアントが所望のメディアを選択するとき、それはネットワークを隔てての選択を要求する。サーバはそれから選択されたメディアを送達する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ディジタルメディアに関し、より具体的にはディジタルメディアにネットワークを介してアクセスすることに関する。
【背景技術】
【0002】
情報を共有できるコンピュータの能力は、情報化時代には最も重要である。ネットワークは、コンピュータ群が互いに通信できるメカニズムである。一般に、リソースを提供するデバイスはサーバと呼ばれ、それらリソースを利用するデバイスはクライアントと呼ばれる。ネットワークのタイプに依存して、デバイスは、あるタイプのタスクに専用であったり、またはリソースを与えたり要求したりするのに依存してクライアントおよびサーバの両方として働いたりする。
【0003】
ますます、人々が共有したいリソースのタイプは、エンターテイメントに関するものである。特に、音楽、映画、写真、およびプリントは、ネットワークを通してアクセスしたいと思うエンターテイメント関連のメディアである。例えば、音楽ライブラリは、書斎の家庭コンピュータ上に常駐し、メディアの所有者はリビングで音楽を聴きたいかもしれない。
【0004】
しかし、メディアデータを共有することは、ネットワークの負荷が大きいプロセスでありえる。人々は、ネットワーク上の負荷を低減し、大きなデータ転送を扱うためにネットワークの能力を増すことに大きな資源を投入してきた。圧縮技術およびネットワークの帯域幅の進歩により、ネットワークを通した情報のスループットは、ここ何年かで飛躍的に増加してきている。
【発明の開示】
【発明が解決しようとする課題】
【0005】
前述の技術は、多くのアプリケーションでうまく働くが、ディジタルメディアを転送する能力をさらに改善するための努力が続けられている。
【課題を解決するための手段】
【0006】
本発明は、ネットワークを隔ててメディアを取り出す方法を提供する。まず、クライアントは、サーバを含むネットワークに接続する。このサーバは、メディアおよび関連付けられたメディア情報を有する少なくとも1つのメディアデータベースを含む。クライアントはそれから、メディア情報の少なくとも一部についてサーバにクエリーし、それからクエリーに応答してメディア情報を受け取る。クライアントはそれから、クライアント側メディアマネージメントシステムを用いて、受け取られたメディア情報を管理する。受け取られたメディア情報の管理は、メディアを選択することを含む。クライアントは、選択されたメディアをネットワークを隔てて要求し、要求に応答して、要求されたメディアを受け取る。
【0007】
他の局面において、クライアントは、ネットワークに接続した後、サーバ情報および能力についてサーバにクエリーする。クライアントはそれから、サーバを特定するレスポンスを受け取り、クライアントにその能力について知らせる。サーバ情報を受け取った後、クライアントは、データベース列挙についてサーバにクエリーし、全てのデータベース、どのくらい多くのメディアが利用可能であり、かつどのくらい多くのメディアコレクションが利用可能であるかを列挙するレスポンスを受け取る。データベース特定の後、クライアントは、データベース中のメディアコレクションの列挙についてサーバにクエリーし、メディアコレクションを特定するレスポンスを受け取る。クライアントはそれから、特定されたメディアコレクションに関連付けられたデータについてサーバにクエリーし、このクエリーは、デフォールトによって与えられるのとは異なる詳細さのレベルを要求することができる。メディアコレクションクエリーに対するレスポンスは、要求された詳細さのレベルで、特定されたメディアコレクションに関連付けられたデータを特定する。クライアントはそれから、特定されたメディアコレクションを実行し、メディアコレクションがメディアを必要とするときにサーバからメディアを要求し、要求されたメディアを受け取る。
【0008】
さらに他の局面において、本発明は、クライアント上のメディアデータベース表現が最新であることを確実にする方法を提供する。サーバはまず、メディアデータベースが変更されるたびに現在のリビジョン指示子にアップデートするメディアデータベースを提供する。それから、サーバはクライアントから要求を受け取り、この要求は、クライアントによって提供されたリビジョン指示子を含むデータベースに関する。要求を受け取った後で、サーバは、現在のリビジョン指示子をクライアントによって提供されたリビジョン指示子と比較する。サーバは、もしクライアントによって提供されたリビジョン指示子が現在のリビジョン指示子と一致しなかったら、現在のリビジョン指示子の少なくとも識別を含むレスポンスでそれから要求に応答する。
【発明を実施するための最良の形態】
【0009】
本発明は、添付の図面と併せて以下の記載を参照して最もよく理解されるだろう。
【0010】
図面において、同様の参照番号は同様の構成要素を示すことが理解されよう。また、図面中の図示は必ずしも正しい縮尺ではない。
【0011】
以下の記載では、本発明の完全な理解のために多くの具体的な詳細が述べられる。しかし、本発明は、これら特定の詳細の一部または全てがなくても実施されえることは当業者には明らかだろう。他の場合には、よく知られたプロセスステップは、本発明の趣旨を不必要にぼかさないために詳細には記載されない。
【0012】
本発明は、一般に、クライアントマシンがサーバ上のメディアデータベースにアクセスすることを可能にする。サーバ上のデータおよびメタデータの両方は、さまざまなやり方でメディアを記述および整理し、サーバがメディアを操作できるようにする。メディアマネージメントシステムをサーバが実行するのに頼る代わりに、クライアントは、データおよびメタデータを要求し、それからクライアント上でサーバの代理を実質的に作るローカルメディアマネージメントシステム上でその情報を利用する。いったんメディアがクライアント側のメディアマネージメントシステムを通してクライアント上で選択されると、クライアントは、サーバからのメディアを要求でき、サーバはメディアをクライアントに伝達できる。
【0013】
本発明は、「シック」および「シン」クライアントの両方をサポートできる。シッククライアントは、典型的には、カリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiTunes(商標)のような、十分なユーザインタフェース機能をサポートし、かなりのプロセッサおよびメモリリソースを有するハードウェアデバイス上で動作するソフトウェアプログラムである。シンクライアントは、限られたユーザインタフェース機能を有し、少ない処理およびメモリリソースを有するハードウェアデバイス上で動作するソフトウェアプログラムである。本発明は、シッククライアントに適切なロバストなコントロール属性を可能にし、シンクライアントのために最低限のコントロール属性にも適応できる。
【0014】
一般に、クライアントは、メディアがサーバ上で利用可能であるかを決定するためにまず要求をする。それから、クライアントは、サーバ上で利用可能であるメディアの代理をクライアント上に作るために一連の要求をしえる。この代理は、サーバ上で利用可能であるメディアに関する情報(「メディア情報」)を含む。シッククライアントは、サーバの利用可能なメディアの完全な代理を取り出すことを選んでもよく、一方、シンクライアントは、サーバの利用可能なメディアの部分的な代理を取り出すことを選んでもよい。メディア情報をサーバから受け取った後、クライアント(そのユーザによって指示されるように)は、それからサーチ、ブラウズ、ソート、または他の対話を今やクライアント上に常駐するメディア情報と行うことができる。さらに、クライアント(そのユーザによって指示されるように)は、典型的には提示される(例えば再生される)べきメディアアイテムを選択する。このような場合には、選択されたメディアアイテムについてのメディアコンテンツは、サーバからクライアントへストリーミングされる。
【0015】
加えて、クライアントは、メディアデータベースが変わったときに通知をサーバから受け取ることができる。複数の接続は、クライアントがある接続を用いてメディアにアクセスする一方で、他の接続を用いてデータベースが変わった通知を待つ、またはメディアリスティングをブラウズすることを可能にする。
【0016】
図1は、本発明が実現されえる例示的環境を示すブロック図である。ネットワーク105は、サーバ110をさまざまなクライアント115、120、125、および130に結合する。ネットワーク105は一般に、LAN、WANまたはインターネットのようなデータネットワークでありえる。サーバ110は、専用のデバイスであっても、そうでなくてもよい。図1に示される例では、サーバ110は汎用のコンピュータである。さまざまなクライアント115、120、125、および130は、シックまたはシンクライアントでありえ、さまざまなレベルの処理パワーを持つ。クライアントは、携帯コンピュータ115、デスクトップコンピュータ120、カリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiPodTMのような専用デバイス125、またはネットワーク105を通して働くよう設計されるさらにネットワークアウェアなオーディオ/ビデオコンポーネント130を含みえる。簡単のために、以下の説明では、携帯コンピュータクライアント115だけがサーバ110からの情報を要求すると想定する。
【0017】
図2は、サーバ110上のサーバ側メディアマネージメントシステム200の組織構成を示すブロック図である。サーバ側メディアマネージメントシステム200は、メディアマネージャ210および音楽データベース205を含む。メディアマネージャ210は、音楽データベース205へのアクセスをコントロールする。より具体的には、メディアマネージャ210は、クライアント115から要求を受け取り、音楽データベースにアクセスし、かつレスポンスをクライアント115に返す。
【0018】
音楽データベース205は、音楽データベース205内でメディア(すなわちメディアアイテム)を分類、識別、および/または記述するのに用いられる多くのレコード215および220を有する。簡単のために、以下の説明は、サーバ110上に含まれるディジタルメディアは、ネットワーク105上でストリーミングされえる音楽ファイルだけを含むと想定する。本明細書でなされる「曲」または「音楽」への参照は、任意の形態のディジタルメディアに一般化され、このディジタルメディアは、サウンドファイル、画像データ、ムービー、テキストファイルまたはディジタル的にコンピュータ上に記憶されえる任意の他のタイプのメディアを含みえることが理解されよう。同様に、「プレイリスト」への任意の参照は、メディアのコレクションに一般化されえ、これは複合ディジタルメディアのコレクションを含みえる。
【0019】
メディアマネージャ210は、例えば、サーバの名前、用いられるデータベースのバージョン、必要とされるセキュリティのタイプ、サーバに利用可能なデータベースの数、非標準のコンテンツコードがサポートされるか、持続識別(persistent identification)がサポートされるか、などを含みえるデータベース205についての情報を有し、または獲得しえる。データベース205についての情報は、単一のレコードファイル中に存在しえ、または必要に応じてさまざまな情報の部分を特定しつつ部分的にまたは完全にオンデマンドで生成されえることが当業者には理解されよう。
【0020】
曲レコード215は、データベース205内で利用可能なそれぞれのメディアアイテムについてのメタデータを含む。メタデータは、例えば、曲の名前、識別番号、持続識別番号、アーチスト、アルバム、曲のサイズ、曲のフォーマット、必要とされるビットレート、および任意の他の適切な情報を含みえる。もちろん、情報のタイプは、メディアのタイプに依存しえる。ビデオファイルは、追加でディレクタおよびプロデューサーのフィールドを有しえるが、アルバムのフィールドを使わなくてもよい。静止画は、ビットレート情報は必要ないだろう。いくつかのフィールドは標準であるが、他のものはある種のアプリケーションに特定でありえる。例えば、ビデオ信号は、第2オーディオプログラム(SAP)情報を有しえる。クライアントが適切に非標準のコンテンツコードを処理できることを確かにするメカニズムは、図4Aに関連して記載される。
【0021】
識別番号および持続識別番号の両方が用いられえる。もしサポートされるなら、持続識別は、サーバのリスタートにわたっても同じ情報にアクセスするために用いられえる。典型的には、サーバは、メディアマネージメントシステム200がリスタートするたびにそれぞれのレコードに新しい識別番号をアサインする。しかし、持続識別番号は、そのレコードが利用可能である限り同じであり続ける。
【0022】
プレイリストレコード220は、音楽データベース205内で利用可能なそれぞれのプレイリストについての情報を含む。さらに、与えられたプレイリストについての情報は、プレイリスト内の曲のそれぞれについての識別番号を含みえる。プレイリストは、任意の特定の順番であってもよく、そうでなくてもよいメディアのコレクションである。ユーザは、ジャンル、ムード、アーチスト、オーディエンス、または任意の他の意味のある構成によってメディアを統合することを選びえる。サーバ110上のプレイリスト220は、ふつうその音楽データベース205内に含まれるメディアしか含まないが、プレイリストレコード220が他のサーバ上に記憶されたメディアまたはプレイリストを含んではならない理由はない。しかし、サーバ側メディアマネージメントシステム200の実現に依存して、ある種の非標準のコンテンツコードが用いられなければならないかもしれない。
【0023】
図3は、クライアント115のうちの1つの上のクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。クライアント側メディアマネージメントシステム300は、メディアマネージャ305を含む。メディアマネージャ305は、サーバ110における音楽データベース205の少なくとも一部をクライアント115上に複製するように、サーバ側メディアマネージメントシステム200のメディアマネージャ210とネットワーク105を通して対話する。クライアント側メディアマネージメントシステム300が最初にスタートするとき、それはサーバ110上のメディアにアクセスできないが、それはまだどんなメディアが利用可能であるかについてのなんらの情報もそれが有していないからである。
【0024】
図4Aは、サーバ側メディアマネージメントシステム200の特徴を決定するのに用いられえるある技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。409において、クライアント115は、ネットワーク105に接続し、まずサーバ110を知ることになる。クライアント115は、それがネットワーク105と対話できるようにする任意の接続メカニズムを用いえる。例えば、もしクライアント115がカリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiBookTMであったなら、それは、自動でそれ自身をネットワーク105にコンフィギュレーションするために、同じくカリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なRendezvousTMネットワーク技術を用いえる。もしクライアントがサーバ110を知らないなら、他のメカニズムが用いられえる。例えば、ユーザは、手動でサーバ110を探してもよく、またはユーザは、直接にサーバ110のアドレスを入力してもよい。
【0025】
いったんクライアント115が、サーバ110を知ると、それはサーバ情報要求をサーバ110に412において送りえる。サーバ情報要求は、任意の他のトランザクションを試みる前に、サーバから情報を得るためにふつう用いられる。もしネットワーク105が、TCP/IPプロトコルを用いるなら、要求は、HTTP GET要求としてフォーマットされえる。GET要求は、追加の拡張子がその要求に追加されることも可能にし、それにより例えば、クライアント115は、クライアント側メディアマネージメントシステム300についての情報を含ませることができる。
【0026】
415において、サーバは、サーバによってサポートされる、または必要とされる一連の属性を記述する情報でサーバ情報要求に応答する。この情報は、例えば、サーバ側メディアマネージメントシステム200についての情報、利用可能なデータベースの数、ログインプロシージャが必要か、およびどのようなログインプロシージャが必要か、アップデートがサポートされるか、持続識別番号がサポートされるか、非標準のコンテンツコードがサポートされるか、およびプロトコルバージョンを含みえる。
【0027】
クライアント115および415に提供される情報は、クライアント側メディアマネージメントシステム300がサーバ110の能力を理解することを可能にする。クライアント115は、サーバ110を識別できるが、クライアント115は、まだ利用可能なメディアについてのなんらの情報も有していない。
【0028】
もし、クライアント115が、サーバ110が、418において、非標準のコンテンツコードがサポートされるという指示と共にサーバ情報要求に応答したと決定するなら、クライアント115は、オプションでコンテンツコード要求を421において発行しえる。コンテンツコード要求は、クライアント115が、サーバ110によってサポートされるコンテンツコードのリストおよびそれにマッピングされた関連付けられたストリング名を得ることができる一つのメカニズムである。
【0029】
ストリング名を含ませることによって、複数の開発者が彼らの個別の製品のために同じコードを用いることができる。例えば、ある開発者がコード「16000」を、ユーザがネットワーク上で対応するアルバムを購入することができるようにする属性に割り当てることが可能となり、一方で、他の開発者は同じコードを、ユーザが聴いている曲の歌詞をユーザに提供する属性に割り当てることができる。ストリング名が含まれることを許すことによって、クライアント115は、それがコンテンツコードをサポートできるかを決定できる。ストリング名のユニークさは、例えば、開発者のURLをストリング名の一部として含ませることによって確保されえる。
【0030】
424において、サーバ110は、コードおよびそれらに関連付けられたストリング名でコンテンツコード要求に応答する。427において、クライアント115は、それが認識できないコード/ストリングのペアを単に無視できる。そうでなければ、クライアント115が認識できないこれらコード/ストリングペアについては、クライアント115は、そのコードを関連付けられたストリング名と関連付ける。
【0031】
430において、クライアント115はサーバ110にログインする。ログインプロシージャは、ユーザ名(またはアカウント名)およびパスワードを必要としえ、それによりクライアントのユーザが認証されえる。ログインプロシージャは、サーバ110がそれを要求する場合だけ必要とされる。ある種のセキュリティプロトコルは、クライアント115による全ての将来の要求が、セッション識別番号のような所定のパラメータを含むことを要求しえる。
【0032】
いったんログインすると、クライアント115は、音楽データベース205のそのローカル代理にデータを埋め始める。図4Bは、サーバ側メディアマネージメントシステム200のデータベースを列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。433において、クライアント115は、サーバ・データベース要求を発行しえ、これはサーバ110から全ての音楽データベースのリストを取り出すのに用いられえる。このサーバ・データベース要求は、インデックスレンジおよび/またはクエリーを追加で含みえる。シックおよびシンクライアントの両方に利用可能であるが、シンクライアントは、インデックスレンジおよび/またはクエリーを用いて、それぞれのサーバレスポンス中に含まれるデータの量を制限しえる。
【0033】
インデックスレンジは、第1アイテムの位置(またはインデックス)および要求されたアイテムの数に基づいて、レスポンス中で戻されるアイテムを、アイテムの総セットのうちのサブセットに制限するために任意の要求において用いられえる。例えば、インデックスレンジは、サーバから第2音楽データベース、音楽データベースから曲10から20、音楽データベースから最後5プレイリスト、与えられたプレイリストから最初の5曲、または音楽データベース中の42番目の曲を要求するのに用いられえる。
【0034】
クエリーは、特定された基準に基づいて、レスポンス中で戻されるアイテムを、アイテムの総セットのうちのサブセットに制限するために任意の要求において用いられえる。例えば、クエリーは、所定の年以降のデータベース中の曲、その名前にある語を含むプレイリスト、その名前にある語を含まないデータベース中の曲、またはこれらの組み合わせを要求しえる。
【0035】
サーバ・データベース要求を436において処理した後、サーバ110は、レスポンスを439において発行する。もしインデックスレンジおよび/またはクエリーが与えられなかったなら、レスポンスは、サーバ110において利用可能な全ての音楽データベースの完全なリストと共に、1つ以上の音楽データベースについての情報を含むことになる。それぞれのデータベースについての情報は、例えば、データベース識別番号、持続データベース識別番号、それぞれのデータベースの名前、曲の数、およびプレイリストの数を含みえる。この情報で、クライアント側メディアマネージメントシステム300は、サーバ110における1つ以上の音楽データベースの大まかな構造を知ることになる。
【0036】
図5は、サーバ・データベース要求への応答を受け取った後の図3に示されるクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。442において、クライアント115は、音楽データベース510、利用可能な曲レコード515の数、および利用可能なプレイリスト520の数を特定できる。いったん音楽データベース510の大まかな構成が知られると、クライアント115は、任意の技術を用いてその代理にデータを埋めることができる。
【0037】
図4Cは、特定のデータベース510についてのクライアント側メディアマネージメントシステム300の曲レコード515の部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。445において、クライアントは、利用可能な曲についてのメタデータを得るためにデータベース・曲要求を発行する。
【0038】
シッククライアントは、それがネットワークトラフィックを前倒しできるように、データベース・曲要求を発行することを選びえる。いったん曲についてのメタデータが受け取られて記憶されると、クライアント115は、メタデータを再び要求する必要がない。プレイリストは、正しく曲を特定しさえすればよく(例えば曲識別番号を用いて)、クライアント側メディアマネージメントシステム300は、それを既に受け取られたメタデータに関連付けられえる。
【0039】
シンクライアントは、インデックスレンジ、クエリー、メタデータフィールド指定子を発行するか、または445を全部スキップすることを選びえる。メタデータフィールド指定子は、ある種のメタデータフィールドだけが望まれることを指示する。445を用いるシッククライアントは、これら同じインデックスレンジ、クエリーまたはメタデータフィールド指定子の技術を用いることを選びえる。例えば、曲メタデータ要求をある種のジャンルの曲だけに限定することは、ユーザに異なるユーザ体験を提供するために用いられる技術でありえる。
【0040】
サーバ110は、任意の必要なフィルタリング操作を448において実行し、それから451において応答を発行する。図6は、データベース・曲要求への応答を受け取った後の453におけるクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。曲レコード605は、サーバ側曲レコード215の部分的または完全な代理のいずれかでありえ、例えば、曲の名前、識別番号、持続識別番号、アーチスト、アルバム、曲のサイズ、曲のフォーマット、必要とされるビットレート、および任意の他の適切な情報を含みえるメタデータを有する。もしサーバ側マネージメントシステム200が複数のデータベースを有したなら、データベース・曲要求(もし用いられるなら)は、それぞれのデータベースについて発行されなければならないだろう。
【0041】
図4Dは、サーバ側メディアマネージメントシステム200のプレイリストレコード220部分を列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。
【0042】
454において、クライアントは、利用可能なプレイリストのリストを得るためにデータベース・プレイリスト要求を発行する。サーバ110上のプレイリストは、ユーザが特定するか、またはサーバ側メディアマネージメントシステム200によって自動的に生成されるかのいずれかでありえる。例えば、「ベースプレイリスト」は、曲データベース205の全体にある全ての曲を含む特別なプレイリストとして自動的に作られえ、一方、「ジョンレノンのプレイリスト」は、ユーザが作ったジョンレノンによる曲のコレクションでありえる。
【0043】
データベース・プレイリスト要求を受け取り、任意の必要なフィルタリング操作を行った後、サーバ110は応答を457において発行する。この応答は、音楽データベース205中の全てのプレイリストのリストおよびこれらプレイリストについての情報を含む。このプレイリストについての情報は、例えば、プレイリストについての識別番号および/または持続識別番号、および提供されたかもしれない任意の他の情報(例えばプレイリスト中の曲が順番通りになっているか、またはシャッフルされえるか)を含みえる。複数のデータベース・プレイリスト要求は、複数のデータベースを埋めるために必要とされえる。
【0044】
図4Eは、クライアント側メディアマネージメントシステム300のプレイリストレコード520の部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。いったんプレイリストが460において特定されると、クライアント115は、そのプレイリストについてのプレイリスト・曲要求を463において送る。操作445から451が既に実行されたかに依存して、プレイリスト・曲要求は、曲レコード605を埋めるためにそれぞれの曲に付随するメタデータも伝達されるよう、追加で要求しえる。サーバ110に既に受け取られた曲レコード605を知らせるメカニズムを有しないシッククライアントは、重複した曲レコード605を受け取るリスクを冒すことになるが、曲レコード605を保持しなかったシンクライアントは、それぞれのプレイリストと共に曲メタデータを要求することから利益を享受するかもしれない。
【0045】
プレイリスト・曲要求を受け取り、任意の必要なフィルタリング操作を実行した後で、サーバ110は、要求された情報を含む応答を466において発行する。図7は、プレイリスト・曲要求への応答を受け取った後の469におけるクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。クライアント115およびサーバ110間のプレイリスト・曲トランザクションが完了するたびに、他のプレイリストレコード705が埋められる。プレイリストレコード705は、対応するサーバ側プレイリストレコード220の完全なまたは部分的な代理でありえる。複数のプレイリスト・曲要求は、複数のプレイリストを埋めるために必要されえる。
【0046】
図4Fは、いったん曲が選択されると、曲データベース205から曲を取り出すのに用いられえる技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。
【0047】
472において、クライアント115は、曲データをサーバ110から取り出すために、曲・データ要求を発行する。もし単一の曲がサーバ100上に複数のフォーマットで記憶されるなら、曲・データ要求はフォーマット識別子を含みえる。フォーマット識別子は、その曲が例えばMPEG3でエンコードされたデータ(「mp3」)、MPEG4アドバンスオーディオコーディング(「m4a」)、オーディオインターチェンジファイルフォーマット(「aiff」)、またはウィンドウズサウンドファイル(「wav」)で要求されているかを特定しえる。475において、サーバ110は、オーディオファイルをクライアント115に届ける。ある実施形態において、サーバ110は、httpヘッダに曲データをアペンドすることによって曲をストリーミングし、したがってクライアント115において曲を再生するために、クライアント115がデータを適切にパージングする責任を負うことになる。
【0048】
先の記載は、もしサーバ側メディアマネージメントシステム200上のデータがセッション中に変更されても、クライアント115をアップデートするためのメカニズムが用いられないと想定している。例えば、プレイリスト705のクライアント側代理は、対応するサーバ側プレイリスト220の最も新しいバージョンを正確には反映しないかもしれない。
【0049】
図8は、クライアント115およびサーバ110がシンクロされることを確かにするのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線805および810によって表される。
【0050】
815において、クライアント115は、メディアデータをサーバ110から取り出すためにアップデート要求を発行する。アップデート要求は、サーバ110(例えば音楽データベース205)上のデータが変更するときにクライアント115は知らせて欲しいとサーバ110に知らせるフラグでありえる。ある実施形態において、このフラグは、リビジョン番号またはタイムスタンプのようなリビジョン指示子である。
【0051】
820において、サーバ110はアップデート要求を処理する。ある実施形態においてサーバ110は、サーバの音楽データベースが、クライアントのその音楽データベースについての代理に比較して変化するまで、アップデート要求には応答しない。もしリビジョン番号が815において用いられたなら、サーバ110は、クライアント115によって提供されたリビジョン番号を、現在のリビジョン番号と比較し、変更がなされたかを決定する。サーバ110のリビジョン番号は、サーバ110における音楽データベース205のバージョンを表す。レコード215または220への任意の後に続く変更は、サーバ110がそのリビジョン番号を一つだけ増やすようにさせえる。システムの要求に依存して、レコード215または220への変更群のグループはバッチされえ、それによりリビジョン番号は一度だけ増加しえる。バッチさせることは、操作によって(例えばファイル群をグループとしてサーバに追加する)、時間によって(例えば最も新しい変更がなされてから所定の期間だけ待つことによって、他の変更がなされないことを確かにする)、または操作の数によって(例えば所定の数の変更の後、リビジョン番号を変える)などを含む標準的な技術によって実行されえる。
【0052】
いったんサーバ110が、クライアントによって提供されるリビジョン番号がもはや現在のリビジョン番号と一致しないと決定すると、応答が825において発行される。ある実施形態において、この応答は、サーバの現在のリビジョン番号を含む。サーバ110は、それからサーバの現在のリビジョン番号の変化をモニタし続けることができるが、クライアント115は、サーバの現在のリビジョン番号で新しいアップデート要求を再発行するかもしれず、実質的に操作815をアップデートされたリビジョン番号で反復するかもしれない。システムによっては、サーバがアップデート要求を初めて受け取ったときに、サーバ110にアップデート応答を強制的に発行させるために、発行クライアント115はいつもクライアント生成リビジョン番号「1」から始まり、サーバ110はいつもリビジョン番号「2」から始まるようにさせるかもしれない。このようなアプローチは、クライアント115に、音楽データベース205のそのローカル代理をサーバ・データベース要求(図4Bの433を参照)で埋めるきっかけを提供しえる。加えて、アップデート応答はまた、サーバが接続を切断しようとしている(おそらくはタイムアウトまたはサーバシャットダウンのために)ことを、例えば現在のリビジョン番号0を発行することによって、クライアント115に通知するために用いられえる。
【0053】
アップデート要求に加えて、クライアント115はまたリビジョン番号フィールドを要求433、445、454、および463の任意のものの中に含みえる。サーバ110は、それから要求・バイ・要求で、要求で提供されるリビジョン番号を特定の要求についてのリビジョン番号とチェックする。もしリビジョン番号が一致しなかったなら、サーバ110は、アップデート応答を発行し、現在のリビジョン番号およびおそらくは対応する応答を特定する。そうでなければ、サーバ110は、前述のように要求に従う。
【0054】
ある実施形態において、データベース要求433、445、454、および463は、ネットワークトラフィックを減らすために(かつより高い応答性を通してユーザの体験を改善するために)漸次アップデートをさらにサポートしえる。漸次アップデートは、クライアントが過去のリビジョン番号から現在のリビジョン番号への変化だけを要求することを可能にする。もし、例えば、クライアント115がそのプレイリストレコード705をリビジョン「5」からの情報で埋め、それからクライアントは、サーバ110によって最新のリビジョンは「8」であると通知されるなら、クライアントは、新しいプレイリスト・曲要求463を発行しえ、それによりリビジョン「5」からリビジョン「8」へ変化した本発明だけを要求できる。サーバ110が、それぞれのリビジョン番号からの変更の過去のレコードへのアクセスを維持または保有する限り、サーバは漸次要求に従うことができる。
【0055】
しかし最適化によれば、サーバ110が、漸次要求に従うことが全体の応答を再送することよりも実際に効率的かを決定することが可能になるかもしれない。ある状況下では(例えばプレイリスト中の半分より多い曲が削除されたとき)、漸次応答の代わりにフルのプレイリスト・曲応答466で応答するほうがネットワークリソースをより少なくしか使わないだろう。しかし、プレイリスト・曲応答466がフルの応答を提供するとき、クライアント115がその情報を適切に扱えるようにするために、その応答は、そのデータが漸次アップデートを表さない旨の指示を含むのが有利になろう。
【0056】
一般に、本発明の技術は、ソフトウェアおよび/またはハードウェアで実現されえる。例えば、これらはオペレーティングシステムにおいて、別個のユーザプロセスにおいて、ネットワークアプリケーションにバウンドされるライブラリパッケージにおいて、または特別に構築されたマシン上で実現されえる。本発明の具体的な実施形態において、本発明の技術は、オペレーティングシステムおよび/またはそのオペレーティングシステム上で走るアプリケーションプログラムのようなソフトウェアで実現される。
【0057】
本発明の技術のソフトウェアまたはソフトウェア/ハードウェアのハイブリッド実現例は、メモリ中に記憶されたコンピュータプログラムによって選択的にアクティベートされた、または再コンフィギュレーションされた汎用プログラム可能なマシン上で実現されえる。代替として、本発明の技術は、パーソナルコンピュータ、ワークステーションまたはサーバのような汎用ネットワークホストマシン上で実現されえる。さらに、本発明は、少なくとも部分的に汎用コンピューティングデバイス上で実現されえる。
【0058】
ここで図9を参照して、本発明の技術を実現するのに適するコンピューティングデバイス900は、マスタ中央処理ユニット(CPU)905、インタフェース910、メモリ915およびバス920を含む。適切なソフトウェアまたはファームウェアの制御下で動作するとき、CPU905は、所望のコンピューティングデバイスの機能に関連付けられた特定の機能を実現することを担う。CPU905は、オペレーティングシステム(例えばMac OS X)、および任意の適切なアプリケーションソフトウェア(例えばiTunes)を含むソフトウェアの制御下で全てのこれら機能を好ましくは達成する。
【0059】
CPU905は、マイクロプロセッサのモトローラファミリーまたはマイクロプロセッサのMIPSファミリーからのような1つ以上のプロセッサを含みえる。代替としては、プロセッサは、コンピューティングデバイス900の動作を制御するために特別に設計されたハードウェアである。
【0060】
インタフェース910は典型的にはインタフェースカードとして提供される。一般に、これらは、データパケットをネットワーク上で送ったり、受け取ったりするのを制御し、時にはコンピューティングデバイス900と共に用いられる他の周辺機器をサポートする。提供されえるインタフェースとしては、イーサネットインタフェース、フレームリレーインタフェース、ケーブルインタフェース、DSLインタフェース、トークンリングインタフェースなどがある。加えて、高速イーサネットインタフェース、ギガビットイーサネットインタフェース、ATMインタフェース、HSSIインタフェース、POSインタフェース、FDDIインタフェース、ASIインタフェース、DHEIインタフェースなどのようなさまざまな非常に高速のインタフェースが提供されえる。一般に、これらインタフェースは、適切なメディアと通信するのに適切なポートを含みえる。場合によっては、それらは独立したプロセッサおよび時には揮発性RAMも含みえる。
【0061】
コンピューティングデバイスのコンフィギュレーションにかかわらず、それは、ここで記載した技術の機能に関するデータ、プログラム命令および/または情報を記憶するよう構成される1つ以上のメモリまたはメモリモジュール(例えばメモリ915のような)を採用しえる。プログラム命令は、オペレーティングシステムおよび/または1つ以上のアプリケーションの動作を例えば制御しえる。
【0062】
このような情報およびプログラム命令は、ここで記載されたシステム/方法を実現するために採用されえるので、本発明は、ここで記載されたさまざまな操作を実行するプログラム命令、状態情報などを含む機械で読み取り可能な媒体に関する。機械で読み取り可能な媒体の例は、以下に限定されないが、ハードディスク、フレキシブルディスク、および磁気テープのような磁気媒体、CD−ROMディスクのような光媒体、フロプティカルディスクのような光磁気媒体、および読み出し専用メモリ(ROM)およびランダムアクセスメモリ(RAM)のようなプログラム命令を記憶するよう特別に構成されるハードウェアデバイスを含む。本発明は、空間波、光ライン、電気ラインなどのような適切な媒体上を伝搬する搬送波内でも実現されえる。プログラム命令の例は、コンパイラによって作られるような機械語コード、およびコンピュータプログラムによって実行されえる(例えばインタープリタを用いて)高級言語コードの両方を含む。
【0063】
本発明の例示的実施形態および応用例は、ここに図示され記載されるが、多くの変更および改変が可能であり、それらも本発明の概念、範囲および精神の中に留まり、これら改変は本願を熟読すれば当業者には明らかになろう。したがって、本発明の実施形態は、例示的であって、限定的ではなく、本発明は、ここで与えられた詳細に限定されるべきではなく、添付の特許請求の範囲の範囲および等価物の中で改変されえる。
【図面の簡単な説明】
【0064】
【図1】本発明が実現されえる例示的環境を示すブロック図である。
【図2】図1に示されるサーバ上のサーバ側メディアマネージメントシステムの組織構成を示すブロック図である。
【図3】図1に示されるクライアントのうちの1つの上のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図4A】図2に示されるサーバ側メディアマネージメントシステムの特徴を決定するのに用いられえるある技術を示す代表的な制御フロー図である。
【図4B】図2に示されるサーバ側メディアマネージメントシステムのデータベースを列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。
【図4C】図5に示されるクライアント側メディアマネージメントシステムの曲レコードの部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。
【図4D】図2に示されるサーバ側メディアマネージメントシステムのプレイリストレコードの部分を列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。
【図4E】図6に示されるクライアント側メディアマネージメントシステムのプレイリストレコードの部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。
【図4F】図7に示されるクライアント側メディアマネージメントシステムからいったん曲が選択されて、曲データベースから曲を取り出すのに用いられえる技術を示す代表的な制御フロー図である。
【図5】図4Bに示されるサーバ・データベース要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図6】図4Cに示されるデータベース・曲要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図7】図4Eに示されるプレイリスト・曲要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図8】図1に示されるクライアントおよびサーバがシンクロされることを確かにするのに用いられえる一つの技術を示す代表的な制御フロー図である。
【図9】本発明のさまざまな実施形態が実現されえる例示的コンピューティングデバイスを示す図である。
【技術分野】
【0001】
本発明は、ディジタルメディアに関し、より具体的にはディジタルメディアにネットワークを介してアクセスすることに関する。
【背景技術】
【0002】
情報を共有できるコンピュータの能力は、情報化時代には最も重要である。ネットワークは、コンピュータ群が互いに通信できるメカニズムである。一般に、リソースを提供するデバイスはサーバと呼ばれ、それらリソースを利用するデバイスはクライアントと呼ばれる。ネットワークのタイプに依存して、デバイスは、あるタイプのタスクに専用であったり、またはリソースを与えたり要求したりするのに依存してクライアントおよびサーバの両方として働いたりする。
【0003】
ますます、人々が共有したいリソースのタイプは、エンターテイメントに関するものである。特に、音楽、映画、写真、およびプリントは、ネットワークを通してアクセスしたいと思うエンターテイメント関連のメディアである。例えば、音楽ライブラリは、書斎の家庭コンピュータ上に常駐し、メディアの所有者はリビングで音楽を聴きたいかもしれない。
【0004】
しかし、メディアデータを共有することは、ネットワークの負荷が大きいプロセスでありえる。人々は、ネットワーク上の負荷を低減し、大きなデータ転送を扱うためにネットワークの能力を増すことに大きな資源を投入してきた。圧縮技術およびネットワークの帯域幅の進歩により、ネットワークを通した情報のスループットは、ここ何年かで飛躍的に増加してきている。
【発明の開示】
【発明が解決しようとする課題】
【0005】
前述の技術は、多くのアプリケーションでうまく働くが、ディジタルメディアを転送する能力をさらに改善するための努力が続けられている。
【課題を解決するための手段】
【0006】
本発明は、ネットワークを隔ててメディアを取り出す方法を提供する。まず、クライアントは、サーバを含むネットワークに接続する。このサーバは、メディアおよび関連付けられたメディア情報を有する少なくとも1つのメディアデータベースを含む。クライアントはそれから、メディア情報の少なくとも一部についてサーバにクエリーし、それからクエリーに応答してメディア情報を受け取る。クライアントはそれから、クライアント側メディアマネージメントシステムを用いて、受け取られたメディア情報を管理する。受け取られたメディア情報の管理は、メディアを選択することを含む。クライアントは、選択されたメディアをネットワークを隔てて要求し、要求に応答して、要求されたメディアを受け取る。
【0007】
他の局面において、クライアントは、ネットワークに接続した後、サーバ情報および能力についてサーバにクエリーする。クライアントはそれから、サーバを特定するレスポンスを受け取り、クライアントにその能力について知らせる。サーバ情報を受け取った後、クライアントは、データベース列挙についてサーバにクエリーし、全てのデータベース、どのくらい多くのメディアが利用可能であり、かつどのくらい多くのメディアコレクションが利用可能であるかを列挙するレスポンスを受け取る。データベース特定の後、クライアントは、データベース中のメディアコレクションの列挙についてサーバにクエリーし、メディアコレクションを特定するレスポンスを受け取る。クライアントはそれから、特定されたメディアコレクションに関連付けられたデータについてサーバにクエリーし、このクエリーは、デフォールトによって与えられるのとは異なる詳細さのレベルを要求することができる。メディアコレクションクエリーに対するレスポンスは、要求された詳細さのレベルで、特定されたメディアコレクションに関連付けられたデータを特定する。クライアントはそれから、特定されたメディアコレクションを実行し、メディアコレクションがメディアを必要とするときにサーバからメディアを要求し、要求されたメディアを受け取る。
【0008】
さらに他の局面において、本発明は、クライアント上のメディアデータベース表現が最新であることを確実にする方法を提供する。サーバはまず、メディアデータベースが変更されるたびに現在のリビジョン指示子にアップデートするメディアデータベースを提供する。それから、サーバはクライアントから要求を受け取り、この要求は、クライアントによって提供されたリビジョン指示子を含むデータベースに関する。要求を受け取った後で、サーバは、現在のリビジョン指示子をクライアントによって提供されたリビジョン指示子と比較する。サーバは、もしクライアントによって提供されたリビジョン指示子が現在のリビジョン指示子と一致しなかったら、現在のリビジョン指示子の少なくとも識別を含むレスポンスでそれから要求に応答する。
【発明を実施するための最良の形態】
【0009】
本発明は、添付の図面と併せて以下の記載を参照して最もよく理解されるだろう。
【0010】
図面において、同様の参照番号は同様の構成要素を示すことが理解されよう。また、図面中の図示は必ずしも正しい縮尺ではない。
【0011】
以下の記載では、本発明の完全な理解のために多くの具体的な詳細が述べられる。しかし、本発明は、これら特定の詳細の一部または全てがなくても実施されえることは当業者には明らかだろう。他の場合には、よく知られたプロセスステップは、本発明の趣旨を不必要にぼかさないために詳細には記載されない。
【0012】
本発明は、一般に、クライアントマシンがサーバ上のメディアデータベースにアクセスすることを可能にする。サーバ上のデータおよびメタデータの両方は、さまざまなやり方でメディアを記述および整理し、サーバがメディアを操作できるようにする。メディアマネージメントシステムをサーバが実行するのに頼る代わりに、クライアントは、データおよびメタデータを要求し、それからクライアント上でサーバの代理を実質的に作るローカルメディアマネージメントシステム上でその情報を利用する。いったんメディアがクライアント側のメディアマネージメントシステムを通してクライアント上で選択されると、クライアントは、サーバからのメディアを要求でき、サーバはメディアをクライアントに伝達できる。
【0013】
本発明は、「シック」および「シン」クライアントの両方をサポートできる。シッククライアントは、典型的には、カリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiTunes(商標)のような、十分なユーザインタフェース機能をサポートし、かなりのプロセッサおよびメモリリソースを有するハードウェアデバイス上で動作するソフトウェアプログラムである。シンクライアントは、限られたユーザインタフェース機能を有し、少ない処理およびメモリリソースを有するハードウェアデバイス上で動作するソフトウェアプログラムである。本発明は、シッククライアントに適切なロバストなコントロール属性を可能にし、シンクライアントのために最低限のコントロール属性にも適応できる。
【0014】
一般に、クライアントは、メディアがサーバ上で利用可能であるかを決定するためにまず要求をする。それから、クライアントは、サーバ上で利用可能であるメディアの代理をクライアント上に作るために一連の要求をしえる。この代理は、サーバ上で利用可能であるメディアに関する情報(「メディア情報」)を含む。シッククライアントは、サーバの利用可能なメディアの完全な代理を取り出すことを選んでもよく、一方、シンクライアントは、サーバの利用可能なメディアの部分的な代理を取り出すことを選んでもよい。メディア情報をサーバから受け取った後、クライアント(そのユーザによって指示されるように)は、それからサーチ、ブラウズ、ソート、または他の対話を今やクライアント上に常駐するメディア情報と行うことができる。さらに、クライアント(そのユーザによって指示されるように)は、典型的には提示される(例えば再生される)べきメディアアイテムを選択する。このような場合には、選択されたメディアアイテムについてのメディアコンテンツは、サーバからクライアントへストリーミングされる。
【0015】
加えて、クライアントは、メディアデータベースが変わったときに通知をサーバから受け取ることができる。複数の接続は、クライアントがある接続を用いてメディアにアクセスする一方で、他の接続を用いてデータベースが変わった通知を待つ、またはメディアリスティングをブラウズすることを可能にする。
【0016】
図1は、本発明が実現されえる例示的環境を示すブロック図である。ネットワーク105は、サーバ110をさまざまなクライアント115、120、125、および130に結合する。ネットワーク105は一般に、LAN、WANまたはインターネットのようなデータネットワークでありえる。サーバ110は、専用のデバイスであっても、そうでなくてもよい。図1に示される例では、サーバ110は汎用のコンピュータである。さまざまなクライアント115、120、125、および130は、シックまたはシンクライアントでありえ、さまざまなレベルの処理パワーを持つ。クライアントは、携帯コンピュータ115、デスクトップコンピュータ120、カリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiPodTMのような専用デバイス125、またはネットワーク105を通して働くよう設計されるさらにネットワークアウェアなオーディオ/ビデオコンポーネント130を含みえる。簡単のために、以下の説明では、携帯コンピュータクライアント115だけがサーバ110からの情報を要求すると想定する。
【0017】
図2は、サーバ110上のサーバ側メディアマネージメントシステム200の組織構成を示すブロック図である。サーバ側メディアマネージメントシステム200は、メディアマネージャ210および音楽データベース205を含む。メディアマネージャ210は、音楽データベース205へのアクセスをコントロールする。より具体的には、メディアマネージャ210は、クライアント115から要求を受け取り、音楽データベースにアクセスし、かつレスポンスをクライアント115に返す。
【0018】
音楽データベース205は、音楽データベース205内でメディア(すなわちメディアアイテム)を分類、識別、および/または記述するのに用いられる多くのレコード215および220を有する。簡単のために、以下の説明は、サーバ110上に含まれるディジタルメディアは、ネットワーク105上でストリーミングされえる音楽ファイルだけを含むと想定する。本明細書でなされる「曲」または「音楽」への参照は、任意の形態のディジタルメディアに一般化され、このディジタルメディアは、サウンドファイル、画像データ、ムービー、テキストファイルまたはディジタル的にコンピュータ上に記憶されえる任意の他のタイプのメディアを含みえることが理解されよう。同様に、「プレイリスト」への任意の参照は、メディアのコレクションに一般化されえ、これは複合ディジタルメディアのコレクションを含みえる。
【0019】
メディアマネージャ210は、例えば、サーバの名前、用いられるデータベースのバージョン、必要とされるセキュリティのタイプ、サーバに利用可能なデータベースの数、非標準のコンテンツコードがサポートされるか、持続識別(persistent identification)がサポートされるか、などを含みえるデータベース205についての情報を有し、または獲得しえる。データベース205についての情報は、単一のレコードファイル中に存在しえ、または必要に応じてさまざまな情報の部分を特定しつつ部分的にまたは完全にオンデマンドで生成されえることが当業者には理解されよう。
【0020】
曲レコード215は、データベース205内で利用可能なそれぞれのメディアアイテムについてのメタデータを含む。メタデータは、例えば、曲の名前、識別番号、持続識別番号、アーチスト、アルバム、曲のサイズ、曲のフォーマット、必要とされるビットレート、および任意の他の適切な情報を含みえる。もちろん、情報のタイプは、メディアのタイプに依存しえる。ビデオファイルは、追加でディレクタおよびプロデューサーのフィールドを有しえるが、アルバムのフィールドを使わなくてもよい。静止画は、ビットレート情報は必要ないだろう。いくつかのフィールドは標準であるが、他のものはある種のアプリケーションに特定でありえる。例えば、ビデオ信号は、第2オーディオプログラム(SAP)情報を有しえる。クライアントが適切に非標準のコンテンツコードを処理できることを確かにするメカニズムは、図4Aに関連して記載される。
【0021】
識別番号および持続識別番号の両方が用いられえる。もしサポートされるなら、持続識別は、サーバのリスタートにわたっても同じ情報にアクセスするために用いられえる。典型的には、サーバは、メディアマネージメントシステム200がリスタートするたびにそれぞれのレコードに新しい識別番号をアサインする。しかし、持続識別番号は、そのレコードが利用可能である限り同じであり続ける。
【0022】
プレイリストレコード220は、音楽データベース205内で利用可能なそれぞれのプレイリストについての情報を含む。さらに、与えられたプレイリストについての情報は、プレイリスト内の曲のそれぞれについての識別番号を含みえる。プレイリストは、任意の特定の順番であってもよく、そうでなくてもよいメディアのコレクションである。ユーザは、ジャンル、ムード、アーチスト、オーディエンス、または任意の他の意味のある構成によってメディアを統合することを選びえる。サーバ110上のプレイリスト220は、ふつうその音楽データベース205内に含まれるメディアしか含まないが、プレイリストレコード220が他のサーバ上に記憶されたメディアまたはプレイリストを含んではならない理由はない。しかし、サーバ側メディアマネージメントシステム200の実現に依存して、ある種の非標準のコンテンツコードが用いられなければならないかもしれない。
【0023】
図3は、クライアント115のうちの1つの上のクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。クライアント側メディアマネージメントシステム300は、メディアマネージャ305を含む。メディアマネージャ305は、サーバ110における音楽データベース205の少なくとも一部をクライアント115上に複製するように、サーバ側メディアマネージメントシステム200のメディアマネージャ210とネットワーク105を通して対話する。クライアント側メディアマネージメントシステム300が最初にスタートするとき、それはサーバ110上のメディアにアクセスできないが、それはまだどんなメディアが利用可能であるかについてのなんらの情報もそれが有していないからである。
【0024】
図4Aは、サーバ側メディアマネージメントシステム200の特徴を決定するのに用いられえるある技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。409において、クライアント115は、ネットワーク105に接続し、まずサーバ110を知ることになる。クライアント115は、それがネットワーク105と対話できるようにする任意の接続メカニズムを用いえる。例えば、もしクライアント115がカリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なiBookTMであったなら、それは、自動でそれ自身をネットワーク105にコンフィギュレーションするために、同じくカリフォルニア州、クパチーノのApple Computer, Inc.から入手可能なRendezvousTMネットワーク技術を用いえる。もしクライアントがサーバ110を知らないなら、他のメカニズムが用いられえる。例えば、ユーザは、手動でサーバ110を探してもよく、またはユーザは、直接にサーバ110のアドレスを入力してもよい。
【0025】
いったんクライアント115が、サーバ110を知ると、それはサーバ情報要求をサーバ110に412において送りえる。サーバ情報要求は、任意の他のトランザクションを試みる前に、サーバから情報を得るためにふつう用いられる。もしネットワーク105が、TCP/IPプロトコルを用いるなら、要求は、HTTP GET要求としてフォーマットされえる。GET要求は、追加の拡張子がその要求に追加されることも可能にし、それにより例えば、クライアント115は、クライアント側メディアマネージメントシステム300についての情報を含ませることができる。
【0026】
415において、サーバは、サーバによってサポートされる、または必要とされる一連の属性を記述する情報でサーバ情報要求に応答する。この情報は、例えば、サーバ側メディアマネージメントシステム200についての情報、利用可能なデータベースの数、ログインプロシージャが必要か、およびどのようなログインプロシージャが必要か、アップデートがサポートされるか、持続識別番号がサポートされるか、非標準のコンテンツコードがサポートされるか、およびプロトコルバージョンを含みえる。
【0027】
クライアント115および415に提供される情報は、クライアント側メディアマネージメントシステム300がサーバ110の能力を理解することを可能にする。クライアント115は、サーバ110を識別できるが、クライアント115は、まだ利用可能なメディアについてのなんらの情報も有していない。
【0028】
もし、クライアント115が、サーバ110が、418において、非標準のコンテンツコードがサポートされるという指示と共にサーバ情報要求に応答したと決定するなら、クライアント115は、オプションでコンテンツコード要求を421において発行しえる。コンテンツコード要求は、クライアント115が、サーバ110によってサポートされるコンテンツコードのリストおよびそれにマッピングされた関連付けられたストリング名を得ることができる一つのメカニズムである。
【0029】
ストリング名を含ませることによって、複数の開発者が彼らの個別の製品のために同じコードを用いることができる。例えば、ある開発者がコード「16000」を、ユーザがネットワーク上で対応するアルバムを購入することができるようにする属性に割り当てることが可能となり、一方で、他の開発者は同じコードを、ユーザが聴いている曲の歌詞をユーザに提供する属性に割り当てることができる。ストリング名が含まれることを許すことによって、クライアント115は、それがコンテンツコードをサポートできるかを決定できる。ストリング名のユニークさは、例えば、開発者のURLをストリング名の一部として含ませることによって確保されえる。
【0030】
424において、サーバ110は、コードおよびそれらに関連付けられたストリング名でコンテンツコード要求に応答する。427において、クライアント115は、それが認識できないコード/ストリングのペアを単に無視できる。そうでなければ、クライアント115が認識できないこれらコード/ストリングペアについては、クライアント115は、そのコードを関連付けられたストリング名と関連付ける。
【0031】
430において、クライアント115はサーバ110にログインする。ログインプロシージャは、ユーザ名(またはアカウント名)およびパスワードを必要としえ、それによりクライアントのユーザが認証されえる。ログインプロシージャは、サーバ110がそれを要求する場合だけ必要とされる。ある種のセキュリティプロトコルは、クライアント115による全ての将来の要求が、セッション識別番号のような所定のパラメータを含むことを要求しえる。
【0032】
いったんログインすると、クライアント115は、音楽データベース205のそのローカル代理にデータを埋め始める。図4Bは、サーバ側メディアマネージメントシステム200のデータベースを列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。433において、クライアント115は、サーバ・データベース要求を発行しえ、これはサーバ110から全ての音楽データベースのリストを取り出すのに用いられえる。このサーバ・データベース要求は、インデックスレンジおよび/またはクエリーを追加で含みえる。シックおよびシンクライアントの両方に利用可能であるが、シンクライアントは、インデックスレンジおよび/またはクエリーを用いて、それぞれのサーバレスポンス中に含まれるデータの量を制限しえる。
【0033】
インデックスレンジは、第1アイテムの位置(またはインデックス)および要求されたアイテムの数に基づいて、レスポンス中で戻されるアイテムを、アイテムの総セットのうちのサブセットに制限するために任意の要求において用いられえる。例えば、インデックスレンジは、サーバから第2音楽データベース、音楽データベースから曲10から20、音楽データベースから最後5プレイリスト、与えられたプレイリストから最初の5曲、または音楽データベース中の42番目の曲を要求するのに用いられえる。
【0034】
クエリーは、特定された基準に基づいて、レスポンス中で戻されるアイテムを、アイテムの総セットのうちのサブセットに制限するために任意の要求において用いられえる。例えば、クエリーは、所定の年以降のデータベース中の曲、その名前にある語を含むプレイリスト、その名前にある語を含まないデータベース中の曲、またはこれらの組み合わせを要求しえる。
【0035】
サーバ・データベース要求を436において処理した後、サーバ110は、レスポンスを439において発行する。もしインデックスレンジおよび/またはクエリーが与えられなかったなら、レスポンスは、サーバ110において利用可能な全ての音楽データベースの完全なリストと共に、1つ以上の音楽データベースについての情報を含むことになる。それぞれのデータベースについての情報は、例えば、データベース識別番号、持続データベース識別番号、それぞれのデータベースの名前、曲の数、およびプレイリストの数を含みえる。この情報で、クライアント側メディアマネージメントシステム300は、サーバ110における1つ以上の音楽データベースの大まかな構造を知ることになる。
【0036】
図5は、サーバ・データベース要求への応答を受け取った後の図3に示されるクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。442において、クライアント115は、音楽データベース510、利用可能な曲レコード515の数、および利用可能なプレイリスト520の数を特定できる。いったん音楽データベース510の大まかな構成が知られると、クライアント115は、任意の技術を用いてその代理にデータを埋めることができる。
【0037】
図4Cは、特定のデータベース510についてのクライアント側メディアマネージメントシステム300の曲レコード515の部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。445において、クライアントは、利用可能な曲についてのメタデータを得るためにデータベース・曲要求を発行する。
【0038】
シッククライアントは、それがネットワークトラフィックを前倒しできるように、データベース・曲要求を発行することを選びえる。いったん曲についてのメタデータが受け取られて記憶されると、クライアント115は、メタデータを再び要求する必要がない。プレイリストは、正しく曲を特定しさえすればよく(例えば曲識別番号を用いて)、クライアント側メディアマネージメントシステム300は、それを既に受け取られたメタデータに関連付けられえる。
【0039】
シンクライアントは、インデックスレンジ、クエリー、メタデータフィールド指定子を発行するか、または445を全部スキップすることを選びえる。メタデータフィールド指定子は、ある種のメタデータフィールドだけが望まれることを指示する。445を用いるシッククライアントは、これら同じインデックスレンジ、クエリーまたはメタデータフィールド指定子の技術を用いることを選びえる。例えば、曲メタデータ要求をある種のジャンルの曲だけに限定することは、ユーザに異なるユーザ体験を提供するために用いられる技術でありえる。
【0040】
サーバ110は、任意の必要なフィルタリング操作を448において実行し、それから451において応答を発行する。図6は、データベース・曲要求への応答を受け取った後の453におけるクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。曲レコード605は、サーバ側曲レコード215の部分的または完全な代理のいずれかでありえ、例えば、曲の名前、識別番号、持続識別番号、アーチスト、アルバム、曲のサイズ、曲のフォーマット、必要とされるビットレート、および任意の他の適切な情報を含みえるメタデータを有する。もしサーバ側マネージメントシステム200が複数のデータベースを有したなら、データベース・曲要求(もし用いられるなら)は、それぞれのデータベースについて発行されなければならないだろう。
【0041】
図4Dは、サーバ側メディアマネージメントシステム200のプレイリストレコード220部分を列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。
【0042】
454において、クライアントは、利用可能なプレイリストのリストを得るためにデータベース・プレイリスト要求を発行する。サーバ110上のプレイリストは、ユーザが特定するか、またはサーバ側メディアマネージメントシステム200によって自動的に生成されるかのいずれかでありえる。例えば、「ベースプレイリスト」は、曲データベース205の全体にある全ての曲を含む特別なプレイリストとして自動的に作られえ、一方、「ジョンレノンのプレイリスト」は、ユーザが作ったジョンレノンによる曲のコレクションでありえる。
【0043】
データベース・プレイリスト要求を受け取り、任意の必要なフィルタリング操作を行った後、サーバ110は応答を457において発行する。この応答は、音楽データベース205中の全てのプレイリストのリストおよびこれらプレイリストについての情報を含む。このプレイリストについての情報は、例えば、プレイリストについての識別番号および/または持続識別番号、および提供されたかもしれない任意の他の情報(例えばプレイリスト中の曲が順番通りになっているか、またはシャッフルされえるか)を含みえる。複数のデータベース・プレイリスト要求は、複数のデータベースを埋めるために必要とされえる。
【0044】
図4Eは、クライアント側メディアマネージメントシステム300のプレイリストレコード520の部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。いったんプレイリストが460において特定されると、クライアント115は、そのプレイリストについてのプレイリスト・曲要求を463において送る。操作445から451が既に実行されたかに依存して、プレイリスト・曲要求は、曲レコード605を埋めるためにそれぞれの曲に付随するメタデータも伝達されるよう、追加で要求しえる。サーバ110に既に受け取られた曲レコード605を知らせるメカニズムを有しないシッククライアントは、重複した曲レコード605を受け取るリスクを冒すことになるが、曲レコード605を保持しなかったシンクライアントは、それぞれのプレイリストと共に曲メタデータを要求することから利益を享受するかもしれない。
【0045】
プレイリスト・曲要求を受け取り、任意の必要なフィルタリング操作を実行した後で、サーバ110は、要求された情報を含む応答を466において発行する。図7は、プレイリスト・曲要求への応答を受け取った後の469におけるクライアント側メディアマネージメントシステム300の組織構成を示すブロック図である。クライアント115およびサーバ110間のプレイリスト・曲トランザクションが完了するたびに、他のプレイリストレコード705が埋められる。プレイリストレコード705は、対応するサーバ側プレイリストレコード220の完全なまたは部分的な代理でありえる。複数のプレイリスト・曲要求は、複数のプレイリストを埋めるために必要されえる。
【0046】
図4Fは、いったん曲が選択されると、曲データベース205から曲を取り出すのに用いられえる技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線403および406によって表される。
【0047】
472において、クライアント115は、曲データをサーバ110から取り出すために、曲・データ要求を発行する。もし単一の曲がサーバ100上に複数のフォーマットで記憶されるなら、曲・データ要求はフォーマット識別子を含みえる。フォーマット識別子は、その曲が例えばMPEG3でエンコードされたデータ(「mp3」)、MPEG4アドバンスオーディオコーディング(「m4a」)、オーディオインターチェンジファイルフォーマット(「aiff」)、またはウィンドウズサウンドファイル(「wav」)で要求されているかを特定しえる。475において、サーバ110は、オーディオファイルをクライアント115に届ける。ある実施形態において、サーバ110は、httpヘッダに曲データをアペンドすることによって曲をストリーミングし、したがってクライアント115において曲を再生するために、クライアント115がデータを適切にパージングする責任を負うことになる。
【0048】
先の記載は、もしサーバ側メディアマネージメントシステム200上のデータがセッション中に変更されても、クライアント115をアップデートするためのメカニズムが用いられないと想定している。例えば、プレイリスト705のクライアント側代理は、対応するサーバ側プレイリスト220の最も新しいバージョンを正確には反映しないかもしれない。
【0049】
図8は、クライアント115およびサーバ110がシンクロされることを確かにするのに用いられえる一つの技術を示す代表的な制御フロー図である。クライアント115およびサーバ110によって実行される操作は、対応する垂直な線805および810によって表される。
【0050】
815において、クライアント115は、メディアデータをサーバ110から取り出すためにアップデート要求を発行する。アップデート要求は、サーバ110(例えば音楽データベース205)上のデータが変更するときにクライアント115は知らせて欲しいとサーバ110に知らせるフラグでありえる。ある実施形態において、このフラグは、リビジョン番号またはタイムスタンプのようなリビジョン指示子である。
【0051】
820において、サーバ110はアップデート要求を処理する。ある実施形態においてサーバ110は、サーバの音楽データベースが、クライアントのその音楽データベースについての代理に比較して変化するまで、アップデート要求には応答しない。もしリビジョン番号が815において用いられたなら、サーバ110は、クライアント115によって提供されたリビジョン番号を、現在のリビジョン番号と比較し、変更がなされたかを決定する。サーバ110のリビジョン番号は、サーバ110における音楽データベース205のバージョンを表す。レコード215または220への任意の後に続く変更は、サーバ110がそのリビジョン番号を一つだけ増やすようにさせえる。システムの要求に依存して、レコード215または220への変更群のグループはバッチされえ、それによりリビジョン番号は一度だけ増加しえる。バッチさせることは、操作によって(例えばファイル群をグループとしてサーバに追加する)、時間によって(例えば最も新しい変更がなされてから所定の期間だけ待つことによって、他の変更がなされないことを確かにする)、または操作の数によって(例えば所定の数の変更の後、リビジョン番号を変える)などを含む標準的な技術によって実行されえる。
【0052】
いったんサーバ110が、クライアントによって提供されるリビジョン番号がもはや現在のリビジョン番号と一致しないと決定すると、応答が825において発行される。ある実施形態において、この応答は、サーバの現在のリビジョン番号を含む。サーバ110は、それからサーバの現在のリビジョン番号の変化をモニタし続けることができるが、クライアント115は、サーバの現在のリビジョン番号で新しいアップデート要求を再発行するかもしれず、実質的に操作815をアップデートされたリビジョン番号で反復するかもしれない。システムによっては、サーバがアップデート要求を初めて受け取ったときに、サーバ110にアップデート応答を強制的に発行させるために、発行クライアント115はいつもクライアント生成リビジョン番号「1」から始まり、サーバ110はいつもリビジョン番号「2」から始まるようにさせるかもしれない。このようなアプローチは、クライアント115に、音楽データベース205のそのローカル代理をサーバ・データベース要求(図4Bの433を参照)で埋めるきっかけを提供しえる。加えて、アップデート応答はまた、サーバが接続を切断しようとしている(おそらくはタイムアウトまたはサーバシャットダウンのために)ことを、例えば現在のリビジョン番号0を発行することによって、クライアント115に通知するために用いられえる。
【0053】
アップデート要求に加えて、クライアント115はまたリビジョン番号フィールドを要求433、445、454、および463の任意のものの中に含みえる。サーバ110は、それから要求・バイ・要求で、要求で提供されるリビジョン番号を特定の要求についてのリビジョン番号とチェックする。もしリビジョン番号が一致しなかったなら、サーバ110は、アップデート応答を発行し、現在のリビジョン番号およびおそらくは対応する応答を特定する。そうでなければ、サーバ110は、前述のように要求に従う。
【0054】
ある実施形態において、データベース要求433、445、454、および463は、ネットワークトラフィックを減らすために(かつより高い応答性を通してユーザの体験を改善するために)漸次アップデートをさらにサポートしえる。漸次アップデートは、クライアントが過去のリビジョン番号から現在のリビジョン番号への変化だけを要求することを可能にする。もし、例えば、クライアント115がそのプレイリストレコード705をリビジョン「5」からの情報で埋め、それからクライアントは、サーバ110によって最新のリビジョンは「8」であると通知されるなら、クライアントは、新しいプレイリスト・曲要求463を発行しえ、それによりリビジョン「5」からリビジョン「8」へ変化した本発明だけを要求できる。サーバ110が、それぞれのリビジョン番号からの変更の過去のレコードへのアクセスを維持または保有する限り、サーバは漸次要求に従うことができる。
【0055】
しかし最適化によれば、サーバ110が、漸次要求に従うことが全体の応答を再送することよりも実際に効率的かを決定することが可能になるかもしれない。ある状況下では(例えばプレイリスト中の半分より多い曲が削除されたとき)、漸次応答の代わりにフルのプレイリスト・曲応答466で応答するほうがネットワークリソースをより少なくしか使わないだろう。しかし、プレイリスト・曲応答466がフルの応答を提供するとき、クライアント115がその情報を適切に扱えるようにするために、その応答は、そのデータが漸次アップデートを表さない旨の指示を含むのが有利になろう。
【0056】
一般に、本発明の技術は、ソフトウェアおよび/またはハードウェアで実現されえる。例えば、これらはオペレーティングシステムにおいて、別個のユーザプロセスにおいて、ネットワークアプリケーションにバウンドされるライブラリパッケージにおいて、または特別に構築されたマシン上で実現されえる。本発明の具体的な実施形態において、本発明の技術は、オペレーティングシステムおよび/またはそのオペレーティングシステム上で走るアプリケーションプログラムのようなソフトウェアで実現される。
【0057】
本発明の技術のソフトウェアまたはソフトウェア/ハードウェアのハイブリッド実現例は、メモリ中に記憶されたコンピュータプログラムによって選択的にアクティベートされた、または再コンフィギュレーションされた汎用プログラム可能なマシン上で実現されえる。代替として、本発明の技術は、パーソナルコンピュータ、ワークステーションまたはサーバのような汎用ネットワークホストマシン上で実現されえる。さらに、本発明は、少なくとも部分的に汎用コンピューティングデバイス上で実現されえる。
【0058】
ここで図9を参照して、本発明の技術を実現するのに適するコンピューティングデバイス900は、マスタ中央処理ユニット(CPU)905、インタフェース910、メモリ915およびバス920を含む。適切なソフトウェアまたはファームウェアの制御下で動作するとき、CPU905は、所望のコンピューティングデバイスの機能に関連付けられた特定の機能を実現することを担う。CPU905は、オペレーティングシステム(例えばMac OS X)、および任意の適切なアプリケーションソフトウェア(例えばiTunes)を含むソフトウェアの制御下で全てのこれら機能を好ましくは達成する。
【0059】
CPU905は、マイクロプロセッサのモトローラファミリーまたはマイクロプロセッサのMIPSファミリーからのような1つ以上のプロセッサを含みえる。代替としては、プロセッサは、コンピューティングデバイス900の動作を制御するために特別に設計されたハードウェアである。
【0060】
インタフェース910は典型的にはインタフェースカードとして提供される。一般に、これらは、データパケットをネットワーク上で送ったり、受け取ったりするのを制御し、時にはコンピューティングデバイス900と共に用いられる他の周辺機器をサポートする。提供されえるインタフェースとしては、イーサネットインタフェース、フレームリレーインタフェース、ケーブルインタフェース、DSLインタフェース、トークンリングインタフェースなどがある。加えて、高速イーサネットインタフェース、ギガビットイーサネットインタフェース、ATMインタフェース、HSSIインタフェース、POSインタフェース、FDDIインタフェース、ASIインタフェース、DHEIインタフェースなどのようなさまざまな非常に高速のインタフェースが提供されえる。一般に、これらインタフェースは、適切なメディアと通信するのに適切なポートを含みえる。場合によっては、それらは独立したプロセッサおよび時には揮発性RAMも含みえる。
【0061】
コンピューティングデバイスのコンフィギュレーションにかかわらず、それは、ここで記載した技術の機能に関するデータ、プログラム命令および/または情報を記憶するよう構成される1つ以上のメモリまたはメモリモジュール(例えばメモリ915のような)を採用しえる。プログラム命令は、オペレーティングシステムおよび/または1つ以上のアプリケーションの動作を例えば制御しえる。
【0062】
このような情報およびプログラム命令は、ここで記載されたシステム/方法を実現するために採用されえるので、本発明は、ここで記載されたさまざまな操作を実行するプログラム命令、状態情報などを含む機械で読み取り可能な媒体に関する。機械で読み取り可能な媒体の例は、以下に限定されないが、ハードディスク、フレキシブルディスク、および磁気テープのような磁気媒体、CD−ROMディスクのような光媒体、フロプティカルディスクのような光磁気媒体、および読み出し専用メモリ(ROM)およびランダムアクセスメモリ(RAM)のようなプログラム命令を記憶するよう特別に構成されるハードウェアデバイスを含む。本発明は、空間波、光ライン、電気ラインなどのような適切な媒体上を伝搬する搬送波内でも実現されえる。プログラム命令の例は、コンパイラによって作られるような機械語コード、およびコンピュータプログラムによって実行されえる(例えばインタープリタを用いて)高級言語コードの両方を含む。
【0063】
本発明の例示的実施形態および応用例は、ここに図示され記載されるが、多くの変更および改変が可能であり、それらも本発明の概念、範囲および精神の中に留まり、これら改変は本願を熟読すれば当業者には明らかになろう。したがって、本発明の実施形態は、例示的であって、限定的ではなく、本発明は、ここで与えられた詳細に限定されるべきではなく、添付の特許請求の範囲の範囲および等価物の中で改変されえる。
【図面の簡単な説明】
【0064】
【図1】本発明が実現されえる例示的環境を示すブロック図である。
【図2】図1に示されるサーバ上のサーバ側メディアマネージメントシステムの組織構成を示すブロック図である。
【図3】図1に示されるクライアントのうちの1つの上のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図4A】図2に示されるサーバ側メディアマネージメントシステムの特徴を決定するのに用いられえるある技術を示す代表的な制御フロー図である。
【図4B】図2に示されるサーバ側メディアマネージメントシステムのデータベースを列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。
【図4C】図5に示されるクライアント側メディアマネージメントシステムの曲レコードの部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。
【図4D】図2に示されるサーバ側メディアマネージメントシステムのプレイリストレコードの部分を列挙するのに用いられえる一つの技術を示す代表的な制御フロー図である。
【図4E】図6に示されるクライアント側メディアマネージメントシステムのプレイリストレコードの部分を埋めるのに用いられえるある技術を示す代表的な制御フロー図である。
【図4F】図7に示されるクライアント側メディアマネージメントシステムからいったん曲が選択されて、曲データベースから曲を取り出すのに用いられえる技術を示す代表的な制御フロー図である。
【図5】図4Bに示されるサーバ・データベース要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図6】図4Cに示されるデータベース・曲要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図7】図4Eに示されるプレイリスト・曲要求への応答を受け取った後のクライアント側メディアマネージメントシステムの組織構成を示すブロック図である。
【図8】図1に示されるクライアントおよびサーバがシンクロされることを確かにするのに用いられえる一つの技術を示す代表的な制御フロー図である。
【図9】本発明のさまざまな実施形態が実現されえる例示的コンピューティングデバイスを示す図である。
【特許請求の範囲】
【請求項1】
ディジタルメディアを取り出す方法であって、
サーバに前記サーバの属性をクエリーし、
前記サーバの前記属性を受け取り、前記属性は、少なくとも1つのディジタルメディアデータベースについての情報を含み、前記少なくとも1つのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションデータまたはそれら両方に関し、
前記サーバに前記メタデータに関連付けられている前記レコードを埋めるのに必要とされる情報をクエリーし
前記メタデータに関連付けられている前記レコードを埋めるのに必要とされる情報を受け取ること
を含む方法。
【請求項2】
請求項1に記載の方法であって、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションの両方に関し、前記メタデータに関連付けられる前記レコードを埋めるために複数のクエリーが必要とされる方法。
【請求項3】
請求項1に記載の方法はさらに、ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータレコードおよび前記ディジタルメディアメタデータレコード内に含まれる前記情報を管理する方法。
【請求項4】
請求項1に記載の方法であって、サーバは、ネットワークを隔ててリモートデバイスである方法。
【請求項5】
請求項1から4のいずれかに記載の方法はさらに、
ネットワークを隔ててメディアを要求し、
前記要求されたメディアを受け取ること
を含む方法。
【請求項6】
請求項5に記載の方法であって、前記受け取られたメディアをクライアントデバイスにおいて提示することをさらに含み、前記受け取られたメディアを提示することは、前記メディアをユーザのために再生することを含む方法。
【請求項7】
請求項6に記載の方法であって、前記クライアントデバイスはメディアプレーヤーであるか、またはメディアプレーヤーを有する方法。
【請求項8】
請求項6に記載の方法であって、前記受け取られたメディアは曲に関する方法。
【請求項9】
請求項1から8のいずれかに記載の方法であって、前記方法は、コンピュータで読み取り可能な媒体上に命令として記憶される方法。
【請求項10】
メディアを取り出す方法であって、
サーバに接続し、前記サーバはメディア情報を含み、
前記サーバに前記メディア情報の少なくとも一部についてクエリーし、
前記クエリーに応答してメタデータを受け取り、少なくとも1つのメタデータアイテムは、前記メディアまたはメディアコレクションに関連付けられており、
少なくとも1つのメタデータアイテムが関連付けられる情報を要求すること
を含む方法。
【請求項11】
請求項10に記載の方法であって、
前記方法は、クライアント側メディアマネージメントシステムによって実行され、
前記クエリーは、前記一部を示し、かつ
前記一部は、少なくとも部分的に前記クライアント側メディアマネージメントシステムが制限されたユーザインタフェース機能を有するか否かに基づく
方法。
【請求項12】
請求項10に記載の方法であって、
前記方法は、クライアント側メディアマネージメントシステムによって実行され、
前記クエリーは、前記一部を示し、かつ
前記一部は、少なくとも部分的に前記クライアント側メディアマネージメントシステムが前記サーバから利用可能な前記メディア情報の全てを記憶するのには充分ではない制限されたメモリを有するか否かに基づく
方法。
【請求項13】
請求項10に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、ユーザにカスタマイズされた体験を提供することに少なくとも部分的に基づく
方法。
【請求項14】
請求項10に記載の方法であって、前記サーバはネットワークを隔てたリモートデバイスである方法。
【請求項15】
ネットワークを隔ててメディアを取り出す方法であって、
サーバを含むネットワークに接続し、
前記サーバにサーバ能力についてクエリーし、
前記サーバを記述する前記サーバ能力クエリーに対するレスポンスを受け取り、
前記サーバにデータベース列挙についてクエリーし、
少なくとも1つのデータベースを記述する前記データベース列挙クエリーに対するレスポンスを受け取り、前記記述は、どのくらいのメディアが利用可能であるか、および何個のコレクションが前記少なくとも1つのデータベースから利用可能であるかを含み、
データベースを前記少なくとも1つのデータベースから選択し、
前記選択されたデータベース中のメディアコレクションの列挙について前記サーバにクエリーし、
前記メディアコレクションを記述する前記メディアコレクション列挙クエリーに対するレスポンスを受け取り、
前記記述されたメディアコレクションの中からメディアコレクションを選択し、
前記選択されたメディアコレクションに関連付けられたデータについて前記サーバにクエリーし、前記メディアコレクションデータクエリーは、デフォールトで与えられるのとは詳細さの異なるレベルを要求することが可能であり、
詳細さの前記要求されたレベルにおける前記選択されたメディアコレクションに関連付けられたデータを記述する前記メディアコレクションデータクエリーに対するレスポンスを受け取り、
どのようなメディアが必要とされるかを前記メディアコレクションに基づいて決定し、
前記メディアが必要とされるとき、メディアを前記サーバから要求し、
前記要求されたメディアを受け取ること
を含む方法。
【請求項16】
請求項15に記載の方法であって、前記データベース識別クエリーの前に前記サーバにログインすることをさらに含む方法。
【請求項17】
請求項15に記載の方法であって、
前記サーバにコンテンツコードについてクエリーし、
サポートされるストリング名および前記サーバがサポートされるストリング名と関連付ける対応するコードのリストを含む、前記コンテンツコードクエリーに対するレスポンスを受け取ること
をさらに含む方法。
【請求項18】
請求項15に記載の方法であって、詳細さの前記デフォールトレベルは、メディアの詳細を含まない方法。
【請求項19】
請求項18に記載の方法であって、
前記データベース中のメディアの詳細について前記サーバにクエリーし、
前記メディアの詳細を記述する前記メディア詳細クエリーに対するレスポンスを受け取ること
をさらに含む方法。
【請求項20】
請求項19に記載の方法であって、
データベース列挙フィルタが前記データベース列挙クエリーに含まれる場合には、前記レスポンスは、前記データベース列挙フィルタによって除外されなかったデータベース記述だけを含み、
メディア詳細フィルタが前記メディア詳細クエリーに含まれる場合には、前記レスポンスは、前記メディア詳細フィルタによって除外されなかったメディア詳細だけを含み、
メディアコレクション列挙フィルタが前記メディアコレクション列挙クエリーに含まれる場合には、前記レスポンスは、前記メディアコレクション列挙フィルタによって除外されなかったメディアコレクション記述だけを含み、かつ
メディアコレクションデータフィルタが前記メディアコレクションデータクエリーに含まれる場合には、前記レスポンスは、前記メディアコレクションデータフィルタによって除外されなかったメディアコレクションデータだけを含む
方法。
【請求項21】
請求項19に記載の方法であって、
データベース列挙インデックスレンジが前記データベース列挙クエリーに含まれる場合には、前記レスポンスは、前記データベース列挙インデックスレンジ内に入るデータベース記述だけを含み、
メディア詳細インデックスレンジが前記メディア詳細クエリーに含まれる場合には、前記レスポンスは、前記メディア詳細インデックスレンジによって除外されなかったメディア詳細だけを含み、
メディアコレクション列挙インデックスレンジが前記メディアコレクション列挙クエリーに含まれる場合には、前記レスポンスは、前記メディアコレクション識別インデックスレンジ内に入るメディアコレクション記述だけを含み、かつ
メディアコレクションデータインデックスレンジが前記メディアコレクションデータクエリーに含まれる場合には、前記レスポンスは、前記メディアコレクションデータインデックスレンジ内に入るメディアコレクションデータだけを含む
方法。
【請求項22】
請求項15に記載の方法であって、記述は持続識別子を含む方法。
【請求項23】
請求項15に記載の方法であって、
前記サーバに、クライアント生成リビジョン指示子を含むアップデート要求でクエリーし、
サーバ生成現在リビジョン指示子が前記アップデート要求中に含まれる前記クライアント生成リビジョン指示子と対応しない場合には、サーバ生成現在リビジョン指示子を含む前記アップデート要求に対するレスポンスを受け取ること
をさらに含む方法。
【請求項24】
請求項19に記載の方法であって、
前記データベース列挙クエリーは、クライアント生成データベース列挙リビジョン指示子を含み、
サーバ生成現在データベース列挙リビジョン指示子が前記クライアント生成データベース列挙リビジョン指示子と対応しない場合には、前記データベース列挙クエリーに対するレスポンスは、サーバ生成現在データベース列挙リビジョン指示子を含み、
前記メディア詳細クエリーは、クライアント生成メディア詳細リビジョン指示子を含み、
サーバ生成現在メディア詳細リビジョン指示子が前記クライアント生成メディア詳細リビジョン指示子と対応しない場合には、前記メディア詳細クエリーに対する前記レスポンスは、サーバ生成現在メディア詳細を含み、
前記メディアコレクション列挙クエリーは、クライアント生成メディアコレクション列挙リビジョン指示子を含み、
サーバ生成現在メディアコレクション列挙リビジョン指示子が前記クライアント生成メディアコレクション列挙リビジョン指示子と対応しない場合には、前記メディアコレクション列挙クエリーに対する前記レスポンスは、サーバ生成現在メディアコレクション列挙リビジョン指示子を含み、
前記メディアコレクションデータクエリーは、クライアント生成メディアコレクションデータリビジョン指示子を含み、かつ
サーバ生成現在メディアコレクションデータリビジョン指示子が前記クライアント生成メディアコレクションデータリビジョン指示子と対応しない場合には、前記メディアコレクションデータクエリーに対する前記レスポンスは、サーバ生成現在メディアコレクションデータリビジョン指示子を含む
方法。
【請求項25】
請求項24に記載の方法であって、
前記データベース列挙クエリーに対する前記レスポンスが前記サーバ生成現在データベース列挙リビジョン指示子を含む場合には、前記データベース列挙クエリーを再送し、
前記メディア詳細クエリーに対する前記レスポンスが前記サーバ生成現在メディア詳細リビジョン指示子を含む場合には、前記メディア詳細クエリーを再送し、
前記メディアコレクション列挙クエリーに対する前記レスポンスが前記サーバ生成現在メディアコレクション列挙リビジョン指示子を含む場合には、前記メディアコレクション列挙クエリーを再送し、
前記メディアコレクションデータクエリーに対する前記レスポンスが前記サーバ生成現在メディアコレクションデータリビジョン指示子を含む場合には、前記メディアコレクションデータクエリーを再送すること
をさらに含む方法。
【請求項26】
請求項25に記載の方法であって、
前記データベース列挙クエリーの前記再送は、前記サーバ生成現在データベース列挙リビジョン指示子および前記クライアント現在データベース列挙リビジョン指示子の両方を含み、
前記メディア詳細クエリーの前記再送は、前記サーバ生成現在メディア詳細リビジョン指示子および前記クライアント生成現在メディア詳細リビジョン指示子の両方を含み、
前記メディアコレクション列挙クエリーの前記再送は、前記サーバ生成現在メディアコレクション列挙リビジョン指示子および前記クライアント生成現在メディアコレクション列挙リビジョン指示子の両方を含み、かつ
前記メディアコレクションデータクエリーの前記再送は、前記サーバ生成現在メディアコレクションデータリビジョン指示子および前記クライアント生成現在メディアコレクションデータリビジョン指示子の両方を含む
方法。
【請求項27】
請求項26に記載の方法であって、
前記データベース列挙クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、
前記メディア詳細クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、
前記メディアコレクション列挙クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、かつ
前記メディアコレクションデータクエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含む
方法。
【請求項28】
請求項26に記載の方法であって、
前記データベース列挙クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、
前記メディア詳細クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、
前記メディアコレクション列挙クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、かつ
前記メディアコレクションデータクエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含む
方法。
【請求項29】
メディアを送達する方法であって、
サーバ情報についてのクエリーを受け取り、
前記サーバ情報クエリーに対するレスポンスを送り、
データベース列挙クエリーを受け取り、
少なくとも1つの利用可能なデータベースを記述する前記データベース列挙クエリーに対するレスポンスを送り、前記記述は、どのくらい多くのメディアが利用可能であるか、およびどのくらい多くのメディアコレクションが利用可能であるかを含み、
メディアコレクションの列挙を要求するクエリーを受け取ろ、
前記メディアコレクションを記述する前記メディアコレクション列挙クエリーに対するレスポンスを送り、
特定されたメディアコレクションに関連付けられたデータを要求するメディアコレクションデータクエリーを受け取り、
前記特定されたメディアコレクションに関連付けられたメディアを適切なレベルの詳細さで記述する前記メディアコレクションメディアクエリーに対するレスポンスを送り、
メディア要求を受け取り、
前記要求されたメディアを送達すること
を含む方法。
【請求項30】
ネットワークを隔ててメディアを取り出す方法であって、
クライアント側メディアマネージメントシステムを提供し、
サーバを含むネットワークに接続し、前記サーバは、少なくとも1つのメディアデータベースを含み、前記少なくとも1つのメディアデータベースは、メディアおよび関連付けられたメディア情報を含み、
前記メディア情報の少なくとも一部について前記サーバにクエリーし、
前記クエリーに応答してメディア情報を受け取り、
前記クライアント側メディアマネージメントシステムを通した前記メディア情報との対話に基づいて少なくとも1つのメディアを選択し、
前記ネットワークを隔てて前記選択されたメディアを要求し、
前記要求されたメディアを受け取ること
を含む方法。
【請求項31】
請求項30に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、少なくとも一部は、前記クライアント側メディアマネージメントシステムが制限されたユーザインタフェース能力を有するか否かに基づく
方法。
【請求項32】
請求項30に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、前記クライアント側メディアマネージメントシステムが前記サーバから利用可能な前記メディア情報の全てを記憶するのに充分ではない制限されたメモリを有するか否かに少なくとも部分的に基づく
方法。
【請求項33】
請求項30に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、ユーザにカスタマイズされた体験を提供することに少なくとも部分的に基づく
方法。
【請求項34】
メディアを提供する方法であって、
クライアントに属性について通知し、前記属性は、少なくとも1つのディジタルメディアデータベースについての情報を含み、前記少なくとも1つのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションデータまたはそれら両方に関し、
前記クライアントからの情報についての要求に応答し、前記レスポンスは、前記クライアントが前記メタデータに関連付けられた前記レコードを埋めるために用いられえる情報を含む
を含む方法。
【請求項35】
請求項34に記載の方法であって、
前記少なくとも1つのディジタルメディアデータベースが変更されるときはいつでも、現在のリビジョン指示子に更新し、
前記クライアントからの要求を受け取り、前記要求は前記少なくとも1つのディジタルメディアデータベースに関し、前記要求はクライアント提供リビジョン指示子を含み、
前記現在のリビジョン指示子を前記クライアント提供リビジョン指示子と比較し、
前記クライアント提供リビジョン指示子が前記現在のリビジョン指示子と一致しない場合には、前記現在のリビジョン指示子の識別を少なくとも含むレスポンスで前記要求に応答すること
を含む方法。
【請求項36】
請求項35に記載の方法であって、
前記データベースが変更されるときはいつでも、前記クライアントに前記現在のリビジョン指示子を提供すること
をさらに含む方法。
【請求項37】
請求項35に記載の方法であって、それぞれのリビジョン指示子からの変更の履歴を維持することをさらに含む方法。
【請求項38】
請求項37に記載の方法であって、
前記クライアントからの前記要求は、履歴リビジョン指示子をさらに含み、かつ
前記情報が前記レスポンス内で漸次情報を表すかの指示を提供する
方法。
【請求項39】
請求項38に記載の方法であって、
(i)前記データベースのコンテンツ全体の送信、または(ii)前記履歴リビジョン指示子から前記現在のリビジョン指示子までになされた変更に対応する前記漸次変更だけの送信のいずれがより効率的であるか決定すること
をさらに含む方法。
【請求項40】
クライアント上のメディアデータベース表現が最新であることを確実にする方法であって、
メディアデータベースを提供し、
前記メディアデータベースが変更されるときはいつでも、現在のリビジョン指示子に更新し、
前記クライアントから要求を受け取り、前記要求は、クライアント提供リビジョン指示子を含む前記データベースに関し、
前記現在のリビジョン指示子を前記クライアント提供リビジョン指示子と比較し、
前記クライアント提供リビジョン指示子が前記現在のリビジョン指示子に一致しない場合には、前記現在のリビジョン指示子の指示を少なくとも含むレスポンスで要求に応答すること
を含む方法。
【請求項41】
請求項40に記載の方法であって、
前記データベースが変更されるときはいつでも、前記クライアントに前記現在のリビジョン指示子を提供すること
をさらに含む方法。
【請求項42】
請求項40に記載の方法であって、それぞれのリビジョン指示子からの変更の履歴を維持することをさらに含む方法。
【請求項43】
請求項42に記載の方法であって、
前記クライアントからの前記要求は、履歴リビジョン指示子をさらに含み、かつ
前記情報が前記レスポンス内で漸次情報を表すかの指示を提供する
方法。
【請求項44】
請求項43に記載の方法であって、
(i)前記データベースのコンテンツ全体の送信、または(ii)前記履歴リビジョン指示子から前記現在のリビジョン指示子までになされた変更に対応する前記漸次変更だけの送信のいずれがより効率的であるか決定すること
をさらに含む方法。
【請求項45】
コンピューティングデバイスであって、
プロセッサ、
前記プロセッサに動作可能に接続されたメモリ
を備え、
前記プロセッサは、
メディア情報を含むサーバに接続すること、
前記メディア情報の少なくとも一部について前記サーバにクエリーすること、
前記クエリーに応答してメディア情報を受け取ること、
前記クエリーに応答して前記メディア情報に関連付けられた少なくとも1つのメディアアイテムを要求すること、および
前記メディアアイテムを受け取ること
を含む命令を実行できる
コンピューティングデバイス。
【請求項46】
請求項45に記載のコンピューティングデバイスであって、前記プロセッサは、
サーバ能力について前記サーバにクエリーすること、および
前記サーバを記述する前記サーバ能力クエリーに対するレスポンスを受け取ること
を含む命令を実行するようさらに動作可能であるコンピューティングデバイス。
【請求項47】
請求項45に記載のコンピューティングデバイスであって、前記プロセッサは、
前記サーバにデータベース列挙についてクエリーすること、
少なくとも1つのデータベースを記述する前記データベース列挙クエリーに対するレスポンスを受け取り、前記記述は、どのくらいのメディアが前記少なくとも1つのデータベースから利用可能であるか、および何個のメディアコレクションが前記少なくとも1つのデータベースからまたは両方から利用可能であるかを含むこと、
を含む命令を実行するようさらに動作可能であるコンピューティングデバイス。
【請求項48】
請求項45に記載のコンピューティングデバイスであって、前記メディア情報の少なくとも一部について前記サーバにクエリーすることは、メディアコレクションの少なくとも一部の列挙の要求であるコンピューティングデバイス。
【請求項49】
コンピューティングデバイスであって、
プロセッサ、
前記プロセッサに動作可能に接続されたメモリ、および
前記プロセッサに動作可能に接続されたネットワークインタフェース
を備え、
前記プロセッサは、
メディアデータベースを有するサーバを含むネットワークに接続すること、
前記サーバの属性について前記サーバにクエリーすること、
前記サーバの前記属性を受け取ること、前記属性は、少なくとも1つのディジタルメディアデータベースについての情報を含み、それぞれのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションデータに関し、
前記ディジタルメディアメタデータレコードを埋めるのに必要とされる情報について前記サーバにクエリーすること、
前記ディジタルメディアメタデータレコードを埋めるのに必要とされる情報を受け取ること、
前記メディアコレクションデータレコードを埋めるのに必要とされる情報について前記サーバにクエリーすること、
前記メディアコレクションデータレコードを埋めるのに必要とされる前記情報を受け取ること、
ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータレコードおよび前記ディジタルメディアメタデータレコードに含まれる前記情報を管理すること、
前記ネットワークを隔ててメディアを要求すること、および
前記要求されたメディアを受け取ること
を含む命令を実行するよう動作可能である、
コンピューティングデバイス。
【請求項1】
ディジタルメディアを取り出す方法であって、
サーバに前記サーバの属性をクエリーし、
前記サーバの前記属性を受け取り、前記属性は、少なくとも1つのディジタルメディアデータベースについての情報を含み、前記少なくとも1つのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションデータまたはそれら両方に関し、
前記サーバに前記メタデータに関連付けられている前記レコードを埋めるのに必要とされる情報をクエリーし
前記メタデータに関連付けられている前記レコードを埋めるのに必要とされる情報を受け取ること
を含む方法。
【請求項2】
請求項1に記載の方法であって、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションの両方に関し、前記メタデータに関連付けられる前記レコードを埋めるために複数のクエリーが必要とされる方法。
【請求項3】
請求項1に記載の方法はさらに、ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータレコードおよび前記ディジタルメディアメタデータレコード内に含まれる前記情報を管理する方法。
【請求項4】
請求項1に記載の方法であって、サーバは、ネットワークを隔ててリモートデバイスである方法。
【請求項5】
請求項1から4のいずれかに記載の方法はさらに、
ネットワークを隔ててメディアを要求し、
前記要求されたメディアを受け取ること
を含む方法。
【請求項6】
請求項5に記載の方法であって、前記受け取られたメディアをクライアントデバイスにおいて提示することをさらに含み、前記受け取られたメディアを提示することは、前記メディアをユーザのために再生することを含む方法。
【請求項7】
請求項6に記載の方法であって、前記クライアントデバイスはメディアプレーヤーであるか、またはメディアプレーヤーを有する方法。
【請求項8】
請求項6に記載の方法であって、前記受け取られたメディアは曲に関する方法。
【請求項9】
請求項1から8のいずれかに記載の方法であって、前記方法は、コンピュータで読み取り可能な媒体上に命令として記憶される方法。
【請求項10】
メディアを取り出す方法であって、
サーバに接続し、前記サーバはメディア情報を含み、
前記サーバに前記メディア情報の少なくとも一部についてクエリーし、
前記クエリーに応答してメタデータを受け取り、少なくとも1つのメタデータアイテムは、前記メディアまたはメディアコレクションに関連付けられており、
少なくとも1つのメタデータアイテムが関連付けられる情報を要求すること
を含む方法。
【請求項11】
請求項10に記載の方法であって、
前記方法は、クライアント側メディアマネージメントシステムによって実行され、
前記クエリーは、前記一部を示し、かつ
前記一部は、少なくとも部分的に前記クライアント側メディアマネージメントシステムが制限されたユーザインタフェース機能を有するか否かに基づく
方法。
【請求項12】
請求項10に記載の方法であって、
前記方法は、クライアント側メディアマネージメントシステムによって実行され、
前記クエリーは、前記一部を示し、かつ
前記一部は、少なくとも部分的に前記クライアント側メディアマネージメントシステムが前記サーバから利用可能な前記メディア情報の全てを記憶するのには充分ではない制限されたメモリを有するか否かに基づく
方法。
【請求項13】
請求項10に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、ユーザにカスタマイズされた体験を提供することに少なくとも部分的に基づく
方法。
【請求項14】
請求項10に記載の方法であって、前記サーバはネットワークを隔てたリモートデバイスである方法。
【請求項15】
ネットワークを隔ててメディアを取り出す方法であって、
サーバを含むネットワークに接続し、
前記サーバにサーバ能力についてクエリーし、
前記サーバを記述する前記サーバ能力クエリーに対するレスポンスを受け取り、
前記サーバにデータベース列挙についてクエリーし、
少なくとも1つのデータベースを記述する前記データベース列挙クエリーに対するレスポンスを受け取り、前記記述は、どのくらいのメディアが利用可能であるか、および何個のコレクションが前記少なくとも1つのデータベースから利用可能であるかを含み、
データベースを前記少なくとも1つのデータベースから選択し、
前記選択されたデータベース中のメディアコレクションの列挙について前記サーバにクエリーし、
前記メディアコレクションを記述する前記メディアコレクション列挙クエリーに対するレスポンスを受け取り、
前記記述されたメディアコレクションの中からメディアコレクションを選択し、
前記選択されたメディアコレクションに関連付けられたデータについて前記サーバにクエリーし、前記メディアコレクションデータクエリーは、デフォールトで与えられるのとは詳細さの異なるレベルを要求することが可能であり、
詳細さの前記要求されたレベルにおける前記選択されたメディアコレクションに関連付けられたデータを記述する前記メディアコレクションデータクエリーに対するレスポンスを受け取り、
どのようなメディアが必要とされるかを前記メディアコレクションに基づいて決定し、
前記メディアが必要とされるとき、メディアを前記サーバから要求し、
前記要求されたメディアを受け取ること
を含む方法。
【請求項16】
請求項15に記載の方法であって、前記データベース識別クエリーの前に前記サーバにログインすることをさらに含む方法。
【請求項17】
請求項15に記載の方法であって、
前記サーバにコンテンツコードについてクエリーし、
サポートされるストリング名および前記サーバがサポートされるストリング名と関連付ける対応するコードのリストを含む、前記コンテンツコードクエリーに対するレスポンスを受け取ること
をさらに含む方法。
【請求項18】
請求項15に記載の方法であって、詳細さの前記デフォールトレベルは、メディアの詳細を含まない方法。
【請求項19】
請求項18に記載の方法であって、
前記データベース中のメディアの詳細について前記サーバにクエリーし、
前記メディアの詳細を記述する前記メディア詳細クエリーに対するレスポンスを受け取ること
をさらに含む方法。
【請求項20】
請求項19に記載の方法であって、
データベース列挙フィルタが前記データベース列挙クエリーに含まれる場合には、前記レスポンスは、前記データベース列挙フィルタによって除外されなかったデータベース記述だけを含み、
メディア詳細フィルタが前記メディア詳細クエリーに含まれる場合には、前記レスポンスは、前記メディア詳細フィルタによって除外されなかったメディア詳細だけを含み、
メディアコレクション列挙フィルタが前記メディアコレクション列挙クエリーに含まれる場合には、前記レスポンスは、前記メディアコレクション列挙フィルタによって除外されなかったメディアコレクション記述だけを含み、かつ
メディアコレクションデータフィルタが前記メディアコレクションデータクエリーに含まれる場合には、前記レスポンスは、前記メディアコレクションデータフィルタによって除外されなかったメディアコレクションデータだけを含む
方法。
【請求項21】
請求項19に記載の方法であって、
データベース列挙インデックスレンジが前記データベース列挙クエリーに含まれる場合には、前記レスポンスは、前記データベース列挙インデックスレンジ内に入るデータベース記述だけを含み、
メディア詳細インデックスレンジが前記メディア詳細クエリーに含まれる場合には、前記レスポンスは、前記メディア詳細インデックスレンジによって除外されなかったメディア詳細だけを含み、
メディアコレクション列挙インデックスレンジが前記メディアコレクション列挙クエリーに含まれる場合には、前記レスポンスは、前記メディアコレクション識別インデックスレンジ内に入るメディアコレクション記述だけを含み、かつ
メディアコレクションデータインデックスレンジが前記メディアコレクションデータクエリーに含まれる場合には、前記レスポンスは、前記メディアコレクションデータインデックスレンジ内に入るメディアコレクションデータだけを含む
方法。
【請求項22】
請求項15に記載の方法であって、記述は持続識別子を含む方法。
【請求項23】
請求項15に記載の方法であって、
前記サーバに、クライアント生成リビジョン指示子を含むアップデート要求でクエリーし、
サーバ生成現在リビジョン指示子が前記アップデート要求中に含まれる前記クライアント生成リビジョン指示子と対応しない場合には、サーバ生成現在リビジョン指示子を含む前記アップデート要求に対するレスポンスを受け取ること
をさらに含む方法。
【請求項24】
請求項19に記載の方法であって、
前記データベース列挙クエリーは、クライアント生成データベース列挙リビジョン指示子を含み、
サーバ生成現在データベース列挙リビジョン指示子が前記クライアント生成データベース列挙リビジョン指示子と対応しない場合には、前記データベース列挙クエリーに対するレスポンスは、サーバ生成現在データベース列挙リビジョン指示子を含み、
前記メディア詳細クエリーは、クライアント生成メディア詳細リビジョン指示子を含み、
サーバ生成現在メディア詳細リビジョン指示子が前記クライアント生成メディア詳細リビジョン指示子と対応しない場合には、前記メディア詳細クエリーに対する前記レスポンスは、サーバ生成現在メディア詳細を含み、
前記メディアコレクション列挙クエリーは、クライアント生成メディアコレクション列挙リビジョン指示子を含み、
サーバ生成現在メディアコレクション列挙リビジョン指示子が前記クライアント生成メディアコレクション列挙リビジョン指示子と対応しない場合には、前記メディアコレクション列挙クエリーに対する前記レスポンスは、サーバ生成現在メディアコレクション列挙リビジョン指示子を含み、
前記メディアコレクションデータクエリーは、クライアント生成メディアコレクションデータリビジョン指示子を含み、かつ
サーバ生成現在メディアコレクションデータリビジョン指示子が前記クライアント生成メディアコレクションデータリビジョン指示子と対応しない場合には、前記メディアコレクションデータクエリーに対する前記レスポンスは、サーバ生成現在メディアコレクションデータリビジョン指示子を含む
方法。
【請求項25】
請求項24に記載の方法であって、
前記データベース列挙クエリーに対する前記レスポンスが前記サーバ生成現在データベース列挙リビジョン指示子を含む場合には、前記データベース列挙クエリーを再送し、
前記メディア詳細クエリーに対する前記レスポンスが前記サーバ生成現在メディア詳細リビジョン指示子を含む場合には、前記メディア詳細クエリーを再送し、
前記メディアコレクション列挙クエリーに対する前記レスポンスが前記サーバ生成現在メディアコレクション列挙リビジョン指示子を含む場合には、前記メディアコレクション列挙クエリーを再送し、
前記メディアコレクションデータクエリーに対する前記レスポンスが前記サーバ生成現在メディアコレクションデータリビジョン指示子を含む場合には、前記メディアコレクションデータクエリーを再送すること
をさらに含む方法。
【請求項26】
請求項25に記載の方法であって、
前記データベース列挙クエリーの前記再送は、前記サーバ生成現在データベース列挙リビジョン指示子および前記クライアント現在データベース列挙リビジョン指示子の両方を含み、
前記メディア詳細クエリーの前記再送は、前記サーバ生成現在メディア詳細リビジョン指示子および前記クライアント生成現在メディア詳細リビジョン指示子の両方を含み、
前記メディアコレクション列挙クエリーの前記再送は、前記サーバ生成現在メディアコレクション列挙リビジョン指示子および前記クライアント生成現在メディアコレクション列挙リビジョン指示子の両方を含み、かつ
前記メディアコレクションデータクエリーの前記再送は、前記サーバ生成現在メディアコレクションデータリビジョン指示子および前記クライアント生成現在メディアコレクションデータリビジョン指示子の両方を含む
方法。
【請求項27】
請求項26に記載の方法であって、
前記データベース列挙クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、
前記メディア詳細クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、
前記メディアコレクション列挙クエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含み、かつ
前記メディアコレクションデータクエリーの前記再送に対するレスポンスは、漸次変更だけが行われたことの指示を含む
方法。
【請求項28】
請求項26に記載の方法であって、
前記データベース列挙クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、
前記メディア詳細クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、
前記メディアコレクション列挙クエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含み、かつ
前記メディアコレクションデータクエリーの前記再送に対するレスポンスは、漸次変更が行われなかったことの指示を含む
方法。
【請求項29】
メディアを送達する方法であって、
サーバ情報についてのクエリーを受け取り、
前記サーバ情報クエリーに対するレスポンスを送り、
データベース列挙クエリーを受け取り、
少なくとも1つの利用可能なデータベースを記述する前記データベース列挙クエリーに対するレスポンスを送り、前記記述は、どのくらい多くのメディアが利用可能であるか、およびどのくらい多くのメディアコレクションが利用可能であるかを含み、
メディアコレクションの列挙を要求するクエリーを受け取ろ、
前記メディアコレクションを記述する前記メディアコレクション列挙クエリーに対するレスポンスを送り、
特定されたメディアコレクションに関連付けられたデータを要求するメディアコレクションデータクエリーを受け取り、
前記特定されたメディアコレクションに関連付けられたメディアを適切なレベルの詳細さで記述する前記メディアコレクションメディアクエリーに対するレスポンスを送り、
メディア要求を受け取り、
前記要求されたメディアを送達すること
を含む方法。
【請求項30】
ネットワークを隔ててメディアを取り出す方法であって、
クライアント側メディアマネージメントシステムを提供し、
サーバを含むネットワークに接続し、前記サーバは、少なくとも1つのメディアデータベースを含み、前記少なくとも1つのメディアデータベースは、メディアおよび関連付けられたメディア情報を含み、
前記メディア情報の少なくとも一部について前記サーバにクエリーし、
前記クエリーに応答してメディア情報を受け取り、
前記クライアント側メディアマネージメントシステムを通した前記メディア情報との対話に基づいて少なくとも1つのメディアを選択し、
前記ネットワークを隔てて前記選択されたメディアを要求し、
前記要求されたメディアを受け取ること
を含む方法。
【請求項31】
請求項30に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、少なくとも一部は、前記クライアント側メディアマネージメントシステムが制限されたユーザインタフェース能力を有するか否かに基づく
方法。
【請求項32】
請求項30に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、前記クライアント側メディアマネージメントシステムが前記サーバから利用可能な前記メディア情報の全てを記憶するのに充分ではない制限されたメモリを有するか否かに少なくとも部分的に基づく
方法。
【請求項33】
請求項30に記載の方法であって、
前記クエリーは前記一部を示し、
前記一部は、ユーザにカスタマイズされた体験を提供することに少なくとも部分的に基づく
方法。
【請求項34】
メディアを提供する方法であって、
クライアントに属性について通知し、前記属性は、少なくとも1つのディジタルメディアデータベースについての情報を含み、前記少なくとも1つのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータまたはメディアコレクションデータまたはそれら両方に関し、
前記クライアントからの情報についての要求に応答し、前記レスポンスは、前記クライアントが前記メタデータに関連付けられた前記レコードを埋めるために用いられえる情報を含む
を含む方法。
【請求項35】
請求項34に記載の方法であって、
前記少なくとも1つのディジタルメディアデータベースが変更されるときはいつでも、現在のリビジョン指示子に更新し、
前記クライアントからの要求を受け取り、前記要求は前記少なくとも1つのディジタルメディアデータベースに関し、前記要求はクライアント提供リビジョン指示子を含み、
前記現在のリビジョン指示子を前記クライアント提供リビジョン指示子と比較し、
前記クライアント提供リビジョン指示子が前記現在のリビジョン指示子と一致しない場合には、前記現在のリビジョン指示子の識別を少なくとも含むレスポンスで前記要求に応答すること
を含む方法。
【請求項36】
請求項35に記載の方法であって、
前記データベースが変更されるときはいつでも、前記クライアントに前記現在のリビジョン指示子を提供すること
をさらに含む方法。
【請求項37】
請求項35に記載の方法であって、それぞれのリビジョン指示子からの変更の履歴を維持することをさらに含む方法。
【請求項38】
請求項37に記載の方法であって、
前記クライアントからの前記要求は、履歴リビジョン指示子をさらに含み、かつ
前記情報が前記レスポンス内で漸次情報を表すかの指示を提供する
方法。
【請求項39】
請求項38に記載の方法であって、
(i)前記データベースのコンテンツ全体の送信、または(ii)前記履歴リビジョン指示子から前記現在のリビジョン指示子までになされた変更に対応する前記漸次変更だけの送信のいずれがより効率的であるか決定すること
をさらに含む方法。
【請求項40】
クライアント上のメディアデータベース表現が最新であることを確実にする方法であって、
メディアデータベースを提供し、
前記メディアデータベースが変更されるときはいつでも、現在のリビジョン指示子に更新し、
前記クライアントから要求を受け取り、前記要求は、クライアント提供リビジョン指示子を含む前記データベースに関し、
前記現在のリビジョン指示子を前記クライアント提供リビジョン指示子と比較し、
前記クライアント提供リビジョン指示子が前記現在のリビジョン指示子に一致しない場合には、前記現在のリビジョン指示子の指示を少なくとも含むレスポンスで要求に応答すること
を含む方法。
【請求項41】
請求項40に記載の方法であって、
前記データベースが変更されるときはいつでも、前記クライアントに前記現在のリビジョン指示子を提供すること
をさらに含む方法。
【請求項42】
請求項40に記載の方法であって、それぞれのリビジョン指示子からの変更の履歴を維持することをさらに含む方法。
【請求項43】
請求項42に記載の方法であって、
前記クライアントからの前記要求は、履歴リビジョン指示子をさらに含み、かつ
前記情報が前記レスポンス内で漸次情報を表すかの指示を提供する
方法。
【請求項44】
請求項43に記載の方法であって、
(i)前記データベースのコンテンツ全体の送信、または(ii)前記履歴リビジョン指示子から前記現在のリビジョン指示子までになされた変更に対応する前記漸次変更だけの送信のいずれがより効率的であるか決定すること
をさらに含む方法。
【請求項45】
コンピューティングデバイスであって、
プロセッサ、
前記プロセッサに動作可能に接続されたメモリ
を備え、
前記プロセッサは、
メディア情報を含むサーバに接続すること、
前記メディア情報の少なくとも一部について前記サーバにクエリーすること、
前記クエリーに応答してメディア情報を受け取ること、
前記クエリーに応答して前記メディア情報に関連付けられた少なくとも1つのメディアアイテムを要求すること、および
前記メディアアイテムを受け取ること
を含む命令を実行できる
コンピューティングデバイス。
【請求項46】
請求項45に記載のコンピューティングデバイスであって、前記プロセッサは、
サーバ能力について前記サーバにクエリーすること、および
前記サーバを記述する前記サーバ能力クエリーに対するレスポンスを受け取ること
を含む命令を実行するようさらに動作可能であるコンピューティングデバイス。
【請求項47】
請求項45に記載のコンピューティングデバイスであって、前記プロセッサは、
前記サーバにデータベース列挙についてクエリーすること、
少なくとも1つのデータベースを記述する前記データベース列挙クエリーに対するレスポンスを受け取り、前記記述は、どのくらいのメディアが前記少なくとも1つのデータベースから利用可能であるか、および何個のメディアコレクションが前記少なくとも1つのデータベースからまたは両方から利用可能であるかを含むこと、
を含む命令を実行するようさらに動作可能であるコンピューティングデバイス。
【請求項48】
請求項45に記載のコンピューティングデバイスであって、前記メディア情報の少なくとも一部について前記サーバにクエリーすることは、メディアコレクションの少なくとも一部の列挙の要求であるコンピューティングデバイス。
【請求項49】
コンピューティングデバイスであって、
プロセッサ、
前記プロセッサに動作可能に接続されたメモリ、および
前記プロセッサに動作可能に接続されたネットワークインタフェース
を備え、
前記プロセッサは、
メディアデータベースを有するサーバを含むネットワークに接続すること、
前記サーバの属性について前記サーバにクエリーすること、
前記サーバの前記属性を受け取ること、前記属性は、少なくとも1つのディジタルメディアデータベースについての情報を含み、それぞれのディジタルメディアデータベースについての情報は、レコードについてのメタデータを含み、前記レコードは、ディジタルメディアメタデータおよびメディアコレクションデータに関し、
前記ディジタルメディアメタデータレコードを埋めるのに必要とされる情報について前記サーバにクエリーすること、
前記ディジタルメディアメタデータレコードを埋めるのに必要とされる情報を受け取ること、
前記メディアコレクションデータレコードを埋めるのに必要とされる情報について前記サーバにクエリーすること、
前記メディアコレクションデータレコードを埋めるのに必要とされる前記情報を受け取ること、
ローカルデータベースマネージメントシステムを用いて、前記メディアコレクションデータレコードおよび前記ディジタルメディアメタデータレコードに含まれる前記情報を管理すること、
前記ネットワークを隔ててメディアを要求すること、および
前記要求されたメディアを受け取ること
を含む命令を実行するよう動作可能である、
コンピューティングデバイス。
【図1】
【図2】
【図3】
【図5】
【図6】
【図7】
【図8】
【図9】
【図2】
【図3】
【図5】
【図6】
【図7】
【図8】
【図9】
【公表番号】特表2007−525726(P2007−525726A)
【公表日】平成19年9月6日(2007.9.6)
【国際特許分類】
【出願番号】特願2006−510066(P2006−510066)
【出願日】平成16年4月15日(2004.4.15)
【国際出願番号】PCT/US2004/011621
【国際公開番号】WO2004/097683
【国際公開日】平成16年11月11日(2004.11.11)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ウィンドウズ
2.イーサネット
【出願人】(503260918)アップル インコーポレイテッド (568)
【Fターム(参考)】
【公表日】平成19年9月6日(2007.9.6)
【国際特許分類】
【出願日】平成16年4月15日(2004.4.15)
【国際出願番号】PCT/US2004/011621
【国際公開番号】WO2004/097683
【国際公開日】平成16年11月11日(2004.11.11)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ウィンドウズ
2.イーサネット
【出願人】(503260918)アップル インコーポレイテッド (568)
【Fターム(参考)】
[ Back to top ]