JP2011081780A - 類似性データに基づくメディアアイテムのクラスタリング - Google Patents

Abstract

【課題】複数のプログラム参加者により提供されたメディアライブラリ一覧表情報に少なくとも部分的に基づいてプログラム参加者に対するメディアミックスの生成を容易にする。
【解決手段】プログラム参加者になると決定した個人は、他の参加者の母集団から導出されたデータに少なくとも部分的に基づいて音楽を編成、維持及び再生することに興味を有する。プログラム参加者は、そのプログラム参加者のメディア一覧表を表すデータを送出する必要があり、システムはそのデータを受信する必要がある。システム又はプログラムは、他の各アイテムと比較してプログラム参加者の集合から各アイテムの相対的な類似性を判定し、その類似性情報から類似するアイテムのクラスタが識別される。クラスタは、個々のプログラム参加者のメディアライブラリの類似するアイテムのクラスタを識別するために使用され、それから類似するメディアアイテムのミックスが作成される。
【選択図】図１６

Description

本出願は、２００９年１２月２３日出願の米国特許出願第１２／６４６９１６号の優先権を請求し、２００９年９月８日出願の米国仮特許出願第６１／２４０６３０号（名称：類似性データに基づくメディアアイテムクラスタリング）の利益を請求するものであり、両出願を引用することによってそれらの内容をここに合体する。

本発明は、メディアアイテムのクラスタに関し、特に、メディアアイテムのクラスタに基づいてメディアミックスを生成することに関する。

ＭＰＥＧ、ＡＣＣ、ＷＭＡメディア等の圧縮メディアファイルの出現以前は、メディアは磁気テープに格納され、その後コンパクトディスク（ＣＤ）に格納されていた。特に音楽メディアファイルに関しては、一般に消費者はいくつかの音楽トラックを含むアルバムである音楽メディアを購入した。多くの場合、これらのアルバムは、個々のトラックを聴き手の好みに合わせるため又は聴き手の現在の聴きたい音楽に合わせるために、聴き手が種々の楽しさの度合いと関連付けるトラックを含んでいた。

これは、聴き手が聴きたいトラックがいくつかのアルバム又は多くのアルバムに分散しているという状況を招くことが多い。この状況が動機となり、一般にユーザは、お気に入りのオーディオトラックの「ミックス」、あるいは類似しており且つ同一のテープ又はコンパクトディスクで共に再生されると素晴らしいであろうと思われるオーディオトラックの「ミックス」を作成していた。

これらのミックスを作成するために、ユーザは自身のコレクションの全てのトラックの大量の知識を有する必要があった。更にユーザは、各トラックを元のメディアから別のメディアに記録する必要があった。多くの場合、ユーザは、テープ又はＣＤの限定された空間に収まるトラックを決定し且つ順序を決定するためにトラックを聴くのに多くの時間を費やした。

今日、多くのメディア消費者は完全なアルバムを購入するのではなく個々のトラックを購入する。今日、ユーザのコレクション全体が多くのテープ又はＣＤの代わりに１つのデバイス上に収められるため、多くの場合、ユーザは自身のライブラリの更に多くのトラックを聴ける。

自身のメディアライブラリの全てのトラックに随時アクセスでき且つスクロール及びクリックにより各トラックにアクセスでき、相対的に便利であるにも関わらず、多くの場合、聴き手は依然としてプレイリストの形式でトラックのミックスを作成する。しかし、これらのミックスを作成することは、依然として大量のユーザ対話及び多くのユーザ決定を必要とし且つ時間のかかる処理である。従って、聴き手に対する負担を除去し、その一方で依然として高品質のミックスを作成する必要がある。

本明細書で開示される概念の更なる特徴及び利点は、以下の説明において説明され、その説明から部分的に明らかとなるか、あるいは説明する技術の実行により学習されてもよい。これら概念の特徴及び利点は、特に添付の特許請求の範囲において示される手段及び組合せにより実現及び達成されてもよい。説明する技術のこれらの特徴及び他の特徴は、以下の説明及び添付の特許請求の範囲からより完全に明らかとなるか、あるいは本明細書で示すような開示された概念の実行により学習されてもよい。

本発明は、メディアアイテムのミックスを作成する際に使用するプログラム参加者のメディアライブラリのメディアアイテムのクラスタを識別するための方法及び装置を説明する。最高品質のミックスを作成するために、クラスタは、ユーザの母集団全体の入力に基づく。

プログラム参加者の母集団は、特に個々の音楽ライブラリと関連付けられたクラスタリングデータを受信する代わりにプログラムをホストするサーバと自身の音楽ライブラリの個々のメディアアイテムのコンテンツに関する情報を共有する。

いくつかの実施形態において、アイテムは、プログラム参加者のライブラリの解析に基づいて類似するものとして識別される。少なくとも２人のプログラム参加者のメディアライブラリに表される全てのメディアアイテムに対して、各プログラム参加者のライブラリのメディアアイテムの存在を表すベクトルが示される。各ベクトルは、メディアアイテムを表し且つ他の全てのベクトルと比較される。どの２つのアイテムに対しても、２つのベクトル間の関係が近い程、それらの２つのアイテムは互いに対して類似していると考えられる。

クラスタリング解析は、上記で識別された類似性データを使用して、プログラム参加者のライブラリから収集された個々のメディアアイテムをサーバクラスタ又は互いに相対的に類似するサーバデータベース中のメディアアイテムのグループにマッピングできる。いくつかの実施形態において、クラスタリング解析は、各サーバクラスタにおいて再帰的に適用され、その結果、「親」クラスタを構成するメディアアイテムと比較して互いに対してより強い類似性関係を有するメディアアイテムを含むより小さいサーバクラスタが得られる。クラスタ解析を再帰的に適用することにより、各「親」サーバクラスタが２つ以上の「子」サーバクラスタの間で「親」サーバクラスタのコンテンツを分割する「子」サーバクラスタを有するサーバクラスタの木のような関係が生成される。この再帰的解析は、所望の回数だけ適用されるが、いくつかの実施形態においては、「子」サーバクラスタが１，０００個以下のメディアアイテム又は１００個以下のメディアアイテム、あるいは５０個以下のメディアアイテムを有するようになるまで解析が再適用される。この基準を満たすサーバクラスタは、木の最下位レベルのサーバクラスタである。

いくつかの実施形態において、クラスタリング解析は編集区分と組み合わされる。クラスタリング解析の前に編集区分を実行するのが最も単純であるが、編集区分は随時実行可能である。いくつかの実施形態において、潜在的に類似するメディアアイテムの重なり合わないグループのキャノピー（canopies）は、クラスタリング解析が実行される前にジャンル情報に基づいて作成される。例えば音楽の場合、「ラップ」ジャンルに属する音楽メディアアイテムは、「オペラ」ジャンルに属する音楽メディアアイテムと類似すると考えられることはない。従って、メディアアイテムの集合全体は、「ロック」、「ラップ」、「クラシック」、「オペラ」等の重なり合わないグループの大きなキャノピーに分けられる。しかし、メディアアイテムが同一のキャノピーにグループ化されるため、これらのアイテムの各々が互いに類似することを意味しないが、類似する可能性はある。

サーバは、サーバクラスタにより表される類似性関係をプログラム参加者のメディアライブラリに投影することによりプログラム参加者のメディアライブラリに存在するメディアアイテムのみを含む参加者クラスタを生成できる。サーバは、プログラム参加者のメディアライブラリのコンテンツを既に認識しているため、どの最下位レベルのサーバクラスタがプログラム参加者のメディアライブラリにある各アイテムを含み、参加者クラスタを形成するかを判定できる。

参加者クラスタのいずれか１つが含むメディアアイテムが少なすぎる場合、例えば２０個又は５０個未満のメディアアイテムである場合、サーバは共通の親サーバクラスタを共有するクラスタを再帰的に凝集できる。凝集動作を繰り返すことにより、共通の親の子孫であるプログラム参加者のメディアアイテムは、参加者クラスタが許容可能なサイズになるまで更に大きい参加者クラスタに累積される。いくつかの実施形態において、凝集動作は、判定された数のクラスタのみが残るまで継続する。

プログラム参加者のメディアライブラリのメディアアイテムから作成された参加者クラスタに関する情報は、サーバにより送出可能であり且つクライアントデバイスにより受信可能である。クライアントデバイスは、任意のクラスタに含まれる全てのメディアアイテムのリストをサーバから受信できる。上述のように、クラスタはサーバ上の階層的に関連付けられたメディアアイテムの参加者クラスタにおいて見つけられるプログラム参加者のトラックの凝集に基づいてコンパイルされる。メディアアイテムのクラスタは、サーバの一覧表（inventory）の各曲の相互の相対的な類似性に基づく一覧表のメディアアイテムのクラスタ解析に基づいて判定され、曲の間の相対的な類似性は、異なるプログラム参加者のメディアライブラリ内のメディアアイテムの同時発生の発生率の解析により判定される。

結果として得られる参加者クラスタは、メディアアイテムのミックスを生成及び再生するために使用される。ミックスは、サーバから受信したメディアアイテムのプログラム参加者のコレクション内に含まれるメディアアイテムのクラスタのうちの１つに表されるメディアアイテムを含む。いくつかの実施形態において、ミックスは、クラスタに表されるいくつかのアイテムの選択肢及びそれらのメディアアイテムに類似すると考えられる他の曲を含む。換言すると、クラスタのメディアアイテムはミックスの残りのアイテムに対するシードアイテム（seed items）としての役割を果たせる。ミックスを作成するためにシードアイテムとして使用されるメディアアイテムをクラスタ内から選択する方法が多く存在することは理解されるだろう。例えばいくつかの実施形態において、メディアアイテムはクラスタ全体に対する相対的な類似性に基づいて選択される。いくつかの実施形態において、クラスタの全てのアイテムはミックスを作成する時に使用可能である。

このプログラム又はシステム全体の固有の態様は、メディア供給側（オンライン音楽ストア）のサーバ、参加者のメディア再生デバイス及び多くの場合は再生デバイスとオンラインストアのコンピュータシステムとの間の通信に対応するユーザのパーソナルコンピュータ等の中間機能で行われることが理解されるべきである。

上述の実施形態が実現される方法を最適に説明し且つ本発明の他の利点及び特徴を規定するために、更に特定の説明を以下に提供し、添付の図面に示す。これらの図面は、本発明の例示的な実施形態のみを示すため、範囲を限定するものと考えられないことが理解され、添付の図面を使用して追加の特異性及び詳細によりそれらの例を説明する。

システムの一実施形態を示す図である。 プログラム参加者のライブラリのアイテムを受信及び識別し且つ類似性データを生成する方法の一実施形態を示すフローチャートである。 、 相関データを判定する方法を示す図である。 サンプル購入マトリクスを示す図である。 マスタ類似性テーブルの１つの列を示す図である。 個別の類似性テーブルを示す図である。 ベクトル空間においてクラスタを識別する例示的な方法を示す図である。 ベクトル空間においてサブクラスタを識別する例示的な方法を示す図である。 サーバクラスタの一実施形態を示す図である。 サーバクラスタを生成する例示的な方法を示すフローチャートである。 サーバクラスタを生成する例示的な方法を示すフローチャートである。 クラスタベクトルを算出する例示的な方法を示す図である。 サーバクラスタ及びキャノピーの一実施形態を示す図である。 参加者クラスタを生成する例示的な方法を示すフローチャートである。 参加者クラスタを生成する例示的な方法を示す図である。 システムの一実施形態を示す図である。 類似性データを受信する例示的な方法を示すフローチャートである。 プレイリスト作成方法の一実施形態を示すフローチャートである。 メディアミックス作成方法の一実施形態を示すフローチャートである。 購入するアイテムを推薦する例示的な方法の一実施形態を示すフローチャートである。 システムの一実施形態を示す図である。 メディア及び類似性テーブルをデジタルメディアプレーヤに同期させるシステムの一例を示す図である。

開示された方法及び装置の種々の実施形態を以下に詳細に説明する。特定の実現例を説明するが、これは例示する目的でのみ説明されることが理解されるべきである。他の構成要素、構成及びステップが本発明の趣旨の範囲から逸脱せずに使用されてもよいことが、当業者には理解されるだろう。

図１を参照すると、例示的なシステムは、処理装置（ＣＰＵ）１２０と読み出し専用メモリ（ＲＯＭ）１４０及びランダムアクセスメモリ（ＲＡＭ）１５０等のシステムメモリを含む種々のシステム構成要素を処理装置１２０に結合するシステムバス１１０とを含む汎用演算装置１００を含む。他のシステムメモリ１３０が使用されてもよい。システムは、２つ以上のＣＰＵ１２０を有する演算装置上、あるいはネットワーク化された演算装置のグループ又はクラスタ上で動作し、より大きな処理能力を提供してもよいことが理解される。システムバス１１０は、メモリバス又はメモリコントローラ、周辺バス、並びに種々のバスアーキテクチャのいずれかを使用するローカルバスを含むいくつかの種類のバス構造のいずれであってもよい。ＲＯＭ１４０等に格納された基本入出力（ＢＩＯＳ）は、スタートアップ中等に演算装置１００内の要素間で情報を転送することを助長する基本ルーチンを提供してもよい。演算装置１００は、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ又はテープドライブ等の記憶装置１６０を更に含む。記憶装置１６０は、ドライブインタフェースによりシステムバス１１０に接続される。ドライブ及び関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール及び他のデータの不揮発性記憶装置を演算装置１００に提供する。１つの態様において、特定の機能を実行するハードウェアモジュールは、機能を実行するためにＣＰＵ、バス及びディスプレイ等の必要なハードウェアコンポーネントと関連して有形のコンピュータ可読媒体に格納されたソフトウェアコンポーネントを含む。基本コンポーネントは当業者には既知であり、適切な変形例は、デバイスが小型のハンドヘルド演算装置であるか、デスクトップコンピュータであるか又は大型のコンピュータサーバであるか等のデバイスの種類に基づいて考慮される。

本明細書で説明した例示的な環境がハードウェアディスクを採用するが、コンピュータによりアクセス可能なデータを格納できる磁気カセット、フラッシュメモリカード、デジタル汎用ディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）又は読み出し専用メモリ（ＲＯＭ）等の他の種類のコンピュータ可読媒体が例示的な動作環境において使用されてもよいことが当業者には理解されるべきである。

演算装置１００とのユーザ対話を可能にするために、入力装置１９０は、音声のためのマイク、ジェスチャ又は図形入力のためのタッチセンシティブ画面、キーボード、マウス、動作入力及び音声等の、任意の数の入力機構を表す。出力装置１７０は、当業者には既知の１つ以上の複数の出力機構であってもよい。いくつかの例において、マルチモーダルシステムは、ユーザが演算装置１００と通信するために複数の種類の入力を提供できるようにする。一般に通信インタフェース１８０は、ユーザ入力及びシステム出力を制御及び管理する。いかなる特定のハードウェア構成においても動作する開示された方法及びデバイスには制限がないため、基本的な特徴は、それらの発展に伴って改善されたハードウェア又はファームウェア構成と容易に置換され得る。

説明を分かり易くするために、例示するシステムの実施形態は、個々の機能ブロック（「プロセッサ」とラベル付けされた機能ブロックを含む）を含むものとして提示される。これらのブロックが表す機能は、共用ハードウェア又は専用ハードウェアを使用して提供されてもよい。共用ハードウェア又は専用ハードウェアは、ソフトウェアを実行できるハードウェアを含むが、それに限定されない。例えば図１に提示される１つ以上のプロセッサの機能は、単一の共用プロセッサ又は複数のプロセッサにより提供されてもよい。（「プロセッサ」という用語の使用は、ソフトウェアを実行できるハードウェアを排他的に示すものとして解釈されるべきではない。）図示する実施形態は、マイクロプロセッサ及び／又はデジタル信号プロセッサ（ＤＳＰ）ハードウェア、以下に説明する動作を実行するソフトウェアを格納する読み出し専用メモリ（ＲＯＭ）、並びに結果を格納するランダムアクセスメモリ（ＲＡＭ）を含んでもよい。超大規模集積回路（ＶＬＳＩ）ハードウェアの実施形態、並びに汎用ＤＳＰ回路と組み合わされたカスタムＶＬＳＩ回路網が更に提供されてもよい。

種々の実施形態の論理動作は、（１）汎用コンピュータ内のプログラマブル回路上で実行し且つコンピュータにより実現されるステップ、動作又は手順のシーケンス、（２）専用プログラマブル回路上で実行し且つコンピュータにより実現されるステップ、動作又は手順のシーケンス、並びに／あるいは（３）プログラマブル回路内の相互接続されたマシンモジュール又はプログラムエンジンとして実現される。

上述した演算装置は、ユーザの大量のサンプルから導出された類似性データのクラスタリング解析に基づいてメディアアイテムのミックスを生成及び使用するのに特に有用である。統計的類似性は、複数のユーザのライブラリにわたる２つ以上の曲の相関の発生率を判定するための解析学に基づいて判定される。クラスタリング解析は、統計的類似性データから大きなデータセットを関連したメディアアイテムのより小さなセットに分割できる。大きなデータセットの解析結果をより小さいデータセット（個々のプログラム参加者のメディアライブラリ）に投影することにより、高品質のメディアアイテムのミックスが作成される。

この類似性データは種々の有用な機能に対して使用可能である。種々の有用な機能としては、たとえば、高品質のプレイリストを生成すること、購入をユーザに推薦するために提案される製品を判定すること、曲の新しい選択によりユーザのメディアデバイスを最新の状態に維持すること、数あるうちの一人のユーザのメディアライブラリからミックスを生成すること、が含まれる。一例において、ユーザは、自身のメディアデータベース全体のコンテンツに関連する情報を多くの視聴者ユーザにアクセス可能なサーバにアップロードすることができる。メディアアイテムは、視聴者ユーザ全体のライブラリにおける２つ以上のメディアアイテムの同時発生の回数に基づいて、互いに相関され且つ類似するものとして示される。この類似性に基づいて、サーバはシードトラック（seed track）の選択に基づく１つ以上の類似する曲を含むようにプレイリストを作成できるか、あるいはサーバはユーザのライブラリにない類似する曲の購入を推薦することができる。システムのこれらの特徴及び他の特徴について、以下に更に詳細に説明する。

クラスタは、類似するアイテムの集合が使用できるどんな方法ででも使用可能である。一例において、クラスタはクラスタのコンテンツに基づいてプレイリストを生成する時に有用である。別の例において、クラスタはメディアアイテムのミックスを生成する時に有用である。この状況におけるミックスは、聴き手が選択した相性の良い音楽アイテムのＣＤ又はテープを作成する音楽ミックスの概念と同様である。この場合、クラスタはメディアアイテムのミックスを自動的に生成する方法をデバイスに提供する。

説明した技術及び製品の多くの特徴がAppleInc.の（公序良俗違反につき、不掲載）Store等のオンライン音楽ストアを参照して説明されるが、好適な実施形態を実行するためにシステムはいかなるメディア販売も要求しないことが理解されるべきである。更に説明の一部が１つの特定の形式の媒体のみを参照してもよいが、その一方で、本明細書で説明した原理はオーディオ、ビデオ、静止画像、文書及び他の種類のデータファイル等のどんな媒体にも適用可能である。

サーバ
アップロード
図２は、類似性データを生成する方法の一実施形態を示す。方法は、サーバによりプログラム参加者の個人メディアの一覧表（inventory）に関連付けられたユーザデータを受信すること（２０２）を含む。ユーザデータは、通常はメタデータの形式であるユーザのライブラリ中の個々のメディアアイテムに関する識別情報を含む。ユーザのライブラリ内のメディアアイテムの発生元は、システムと関連していない。説明する方法が音楽コンテンツストアにより採用される場合であっても、本実施形態は、サーバが発信元に基づいてファイル情報を区別しないため、すなわち全てのメディアアイテムが同一のものとして処理されるため、ユーザのファイルが音楽ストアから発生することを要求しない。方法は、ＣＤ、ＤＶＤ又はＨＤ−ＤＶＤ等の物理媒体、並びに物理媒体がデジタル形式にコード変換され且つユーザのメディアライブラリに入力されるような事例に同等に適用される。好適な一実施形態において、サーバは、ユーザがライブラリ中の全てのメディアアイテムに関する情報をアップロードすることを要求せず、制限された数のメディアアイテムのみに関する情報又はメディアアイテムに関する部分情報のみがサーバにより受け入れられる。

ユーザデータの識別
方法は、ユーザデータを特定のメディアアイテムとして識別すること（２０３）を含む。このステップは、ファイル名、メタデータを検査すること含む複数の方法のうちのいずれか１つの方法で達成されてもよく、あるいはファイルの一部分の詳細な解析を介して達成されてもよい。音楽トラックの例において、サーバは種々の機構を介して音楽トラックを識別できる。例えば約８分の長さを有するLedZeppelinのStairwaytoHeaven等の所定のトラックは、ファイルと関連付けられた種々のデータを有する。そのような種々のデータは、たとえばアーティスト、曲名、ジャンル、トラックの長さ、アルバム名、トラック番号等を識別するファイル名又はメタデータを含む。このデータの一部分は、サーバがアルバムLedZeppelinIVからLedZeppelinのStairwaytoHeavenとしてファイルを識別するのに十分である。あるいは、ファイルを識別するために、市販の曲識別サービスが使用可能である。音楽トラックの一部分をサンプリングすることにより又は購入ストアから一意の識別子を認識することにより、あるいは曲のデジタル指紋を認識することにより、トラックを識別できる。例えばサーバ又はサービスは、曲が（公序良俗違反につき、不掲載）Storeから購入されたこと及びファイルのメタデータが（公序良俗違反につき、不掲載）Store専用の一意の識別子を含むことを認識できる。サーバはその識別子によりメディアアイテムを識別できる。メディアアイテムを認識する多くの他の可能な方法が既知であり、それらの全ての方法が開示される方法及び装置により含まれることが理解されるべきである。

相関
各メディアアイテムは、一意の識別子と関連付けられ（２０４）、テーブルに格納される（２０５）。サーバが以前にその曲に遭遇していない場合、サーバはそのトラックに新しい識別子を割り当てる。しかし、殆どのメディアアイテムの場合、識別子は既に割り当てられており、メディアはその識別子と相関されることのみが必要である。Stairway to Heavenの例を継続すると、メディアアイテムがトラックとして識別されると、サーバはそのトラックに対する一意の識別データをルックアップできる。この処理は、サーバにより受信されたメディアアイテム毎に繰り返される。

サーバは殆どの曲と関連付ける識別子を既に有しているが、場合によっては、メディアアイテムはサーバにとって全く新しいものであるか又は少なくとも全く新しいものとして認識される。そのような場合、サーバは新しい識別子を発行し且つそれをメディアアイテムに割り当てる。例えば、新しいアーティスト又はガレージバンドがサーバにより認識されていない場合がある。しかし、サーバはそのアーティストのトラックに対して新しい識別子を発行し、異なるユーザのライブラリで同一のトラックに遭遇した時には以前に発行されたのと同一の識別子をそのトラックに割り当てる。

サーバは、サーバにとって新しいメディアアイテムに対して新しい識別子を供給しない場合がある。例えば、メディアアイテムはユーザのライブラリに固有のものである可能性があり、そのようなアイテムに対する同時発生の発生率が存在しないため、当該アイテムに識別子を提供することは何の価値もない。従って、システムは全ての新しいアイテムに対して一意の識別子を供給する必要がない。システムは、他のユーザがライブラリにそのメディアアイテムを有する場合、後でそのトラックに対して一意の識別子を供給でき且つそのアイテムに対して類似性データを供給できる。

マスタ購入マトリクス
ステップ２０５において、各メディアアイテムはマスタ購入マトリクスに格納される。マスタ購入マトリクスの一例を図４に示す。購入マトリクス４０２は、テーブル中の一意の各メディアアイテムに対応する列４０４を含むテーブルである。テーブルが（公序良俗違反につき、不掲載）Store等の音楽コンテンツ販売側がホストとなる実施形態において、購入マトリクスは、（公序良俗違反につき、不掲載）Storeから購入することが可能な全てのメディアアイテムを更に含む。マスタ購入マトリクス４０４の行は、ユーザの一意のユーザ識別番号４０６と関連付けられる。識別コードは、匿名の識別コードによりユーザを表すもので、システムではなくユーザにより既知となっている。従って、マスタ購入マトリクスは、参加する全てのユーザからプログラムサーバにより受信された全てのファイルのレコードを含む。

購入マトリクスが全てのプログラム参加者及び各プログラム参加者のライブラリ中の全てのメディアに対応するため、購入マトリクス４０２は非常に大きい可能性が高い。例えば、音楽ストアが約２２５万のユーザを有し且つ５００万を上回る曲を有する場合、そのようなオンラインストアに対する購入マトリクスは約２２５万行×５００万列のテーブル、すなわち１兆１，２５０億個の個別のセルから成るテーブルになる。（公序良俗違反につき、不掲載）Storeは、５，０００万を超える登録ユーザを有し且つ１，０００万を超える曲を含む。そのようなストアに対する購入マトリクスは、約５，０００万行×１，０００万列のテーブル、すなわち５００兆個の個別のセルから成るテーブルになる。

ユーザのライブラリに存在する曲の場合、そのユーザ及びその曲に対応するマトリクス中のセルがマーク付けされる。マーク付けは、ブール変数のように単純なデータタイプで行われてもよい。１は購入４０８を示し、０は未購入４１０を示す。ブールデータタイプが許可するより多くのデータが格納される必要がある場合、他のデータタイプが使用されてもよい。マトリクスが非常に大きくなる可能性があるが、殆どのユーザが自身のライブラリに相対的に少ない曲数（５００万と比較して）を有するため、マトリクスの密度は非常に低くなる。各ユーザ行はほんの一握りのエントリのみしか含まない可能性がある一方で、各曲列は数十、数百、数千又はより人気のある曲に対しては数百万個のエントリを含み得るが、購入マトリクスの大部分は空である。

マスタ購入マトリクス又はテーブルは、ライブラリへの新しい曲の追加、ファイルメタデータの変更又はファイルの削除等ユーザライブラリの変更に伴って、更新を必要とすることが理解されるべきである。購入マトリクスはリアルタイムに更新されてもよく、あるいは後日挿入するためにトランザクションがキューに入れられてもよい。キューに入れるための１つの構成は、毎日午後１１：３０等、定期的に購入マトリクスにトランザクションを挿入する。キューに入れる別の構成は、ある最小数のトランザクションの挿入準備が整った場合にトランザクションを購入マトリクスに挿入する。

購入テーブルに対する更新は、全てのメディアアイテムに対してステップ２０３及び２０４を繰り返すことを必要としない。既に識別され且つプログラムに基づく識別番号と相互に関連付けされたメディアアイテムは、識別及び相関ステップを必要としない。これは、ユーザのデータが最初にテーブルにポピュレートされた時に識別及び相関ステップが既に実行されたためである。一実施形態において、サーバは、メディアアイテムをその識別データと相関すると、識別データをメタデータに格納するためにユーザに再度送出できる。将来のサーバとの通信において、サーバは関連した識別データを有するメディアアイテムに対する更新データを受信でき、それによりステップ２０４を再度行なう必要がなくなる。

いくつかの実施形態において、購入マトリクスは、販売の時間及び日付、メディアの形式、メディアが高精細であるか又は標準画質であるか、トランザクションが無料であるか又は有料であるか、再生することを許可されたデバイス等の各トランザクションに関する追加の情報を含むより大きいテーブル又はマトリクスの一部であってもよい。購入マトリクスは、離散的な別個のテーブルであってもよく、あるいはより大きなテーブル又はマトリクスに完全に統合されてもよい。

更に別の実施形態において、マスタ購入マトリクスは、ユーザのメディア一覧表に関するアップロード済み情報を含む必要がない。マスタ購入マトリクスは、本質的に購入情報から構成される。購入情報は、ユーザによりオンラインストアから購入されたアイテムのみであってもよく、あるいは追加の情報を含むことができる。本実施形態において、テーブルは、各ユーザにより購入された全てのアイテムのリストを含むことができる。依然として、マスタ購入マトリクスは、ユーザのメディア一覧表のコンテンツに関するデータの少なくとも制限された集合を含む可能性が高い。

協調フィルタリングエンジン
図２に示す方法は、マスタ購入マトリクス上で協調フィルタリングエンジン（図１６において３０８で示す）を実行して類似性データを生成し（２０６）、類似性データをマスタ類似性テーブルに格納する（２０７）ことを含む。類似性データは、マスタテーブルのいくつかの他のメディアアイテムと同時発生（co-occurrence）するメディアアイテムの発生率から導出される。複数のユーザが、同一の「２つのメディアアイテム」を有する場合、それらのメディアアイテムは同時に発生する（共起する）と考えられる。複数のユーザのライブラリにおいてそのように同時に発生することは、２つのメディアアイテムが「類似する」ことを示す。２つのメディアアイテムがより頻繁にプログラム参加者のライブラリに同時に発生する程、メディアアイテムはより類似すると考えられる。

協調フィルタリングエンジン３０８は、マスタ購入テーブルの個々のメディアアイテム間の類似性を計算する。一実施形態において、協調フィルタリングエンジンは、データベース中の曲の対がプログラム参加者のライブラリで同時に発生する回数を集計するプログラムのように単純なものであってもよい。

いくつかの実施形態において、協調フィルタリングエンジンは、多次元ベクトル空間において各アイテムをベクトルとして表すことにより２つの異なるメディアアイテム間の類似性を計算できる。次元数は、購入マトリクス３０６（図１６）におけるユーザ数と同一である。アイテム間の相関は、ベクトル間の距離を算出することにより行われる。純粋な三角関数又は変形三角関数（例えば、余弦関数又は正弦関数）は、ベクトル間の距離を計算するために使用される。２つのベクトルが小さな角度を有する場合、それらのベクトルは類似すると考えられ、２つのベクトルが大きな角度を有する場合、それらのベクトルはより低い類似性を有すると考えられる。この処理は、マスタ購入マトリクスの各曲をマスタ購入マトリクスの他の全ての曲と比較することにより実行される。

いくつかの実施形態において、協調フィルタリングエンジンは、同時発生するデータの発生率以外のものを考慮に入れることができる。例えば、類似性評価において全体の発生率を考慮に入れることができる。例えば曲Ａ及び曲Ｂは、曲Ａ及び曲Ｃと同一の頻度で同時発生してもよいが、曲Ｂが全体的により人気がある場合、曲Ａ及び曲Ｂは曲Ａ及び曲Ｃより高い類似性スコアを有することができる（すなわち、より類似していると考えられる）。種々の曲の人気を判定する１つの方法は、各曲が全体のデータセットにおいて存在する頻度を測定することである。

同様に、使用頻度入力等の類似性スコアに影響を及ぼす協調フィルタリングエンジンへの他の入力が存在する。例えば、メディアアイテムに与えられた評価、再生数及びスキップ数は、メディアアイテム間の類似性を判定する協調フィルタリングエンジンへの入力であってもよい。

図３Ａ及び図３Ｂは、各曲をベクトルとして表す概念を示す。図３Ａにおいて、マスタテーブルにおけるメディアＩＤ６２９に対するベクトルはユーザ２、８９９、１,３４３及び２,０００のライブラリにおける曲の存在に基づいてマッピングされている。同様に、マスタテーブルにおけるメディアＩＤ１,２６３,９９９に対するベクトルは、ユーザ２、１２、４４４、１,３４３のライブラリにおける曲の存在に基づいてマッピングされている。これらの２つのベクトル間の角度は、２０°であると測定され、約０.９３９の余弦値を計算する。余弦値は、メディアＩＤ６２９とメディアＩＤ１,２６３,９９９との間の相関値を表す。図３Ｂは、メディアＩＤ６２９とメディアＩＤ１５との間の相関を判定するための別の相関計算を表す。この例において、１人のユーザのみがライブラリにメディアＩＤ６２９及びメディアＩＤ１５の双方を有するため、これらの２つのベクトル間の余弦値は約０.７０７である。スコアが低い程、メディアＩＤ６２９及び１５が互いに密接に相関されないことを示す。

別の実施形態において、アイテム間の類似性スコアを計算するために、他の関数が使用可能である。例として、類似性スコアは、特定のアイテムにより構成されるアイテムの合計の同時発生回数のパーセント比を考慮に入れる方法で計算される。例えばアイテムＡがアイテム１〜５と同時に発生すれば、アイテムＡの合計の同時発生回数はアイテム１〜５との同時発生回数の合計となる。例えばアイテムＡがアイテム１と２回同時発生し、アイテム２と２回同時発生し、アイテム３と２回同時発生し、アイテム４と１０回動時発生し且つアイテム５と２回動時発生した場合、アイテムＡは合計で１８回の同時発生回数を有する。特定の対による合計の同時発生回数のパーセント比を学習することは有用である。例えばアイテム４は、アイテムＡの全ての同時発生回数の約５５％であるため、Ａの同時発生回数の合計の約１１％のみである他のどのアイテムより強くアイテムＡと相関される。このデータは、類似性データを判定するために使用される。類似性データを計算する２つの特定の方法が上記で示されるが、２つのアイテム間の類似性を計算する任意の数の他の方法が使用可能であることは理解されるだろう。

上記処理は、全てのアイテムと他の全てのアイテムとの間で定期的に算出される。この処理は、時間が過度にかかる可能性があるため、一般にオフラインで実行される。これは、月に１回、週に１回、１日に１回又は計算能力の可能な頻度で実行される。

類似性テーブル
協調フィルタリングエンジンによりコンパイルされた相関データは、マスタ類似性テーブルを生成するために使用される（図２の２０７）。図５は、マスタ類似性テーブル５０２に格納されたデータを示す。所定のメディアアイテムに対して、プログラムに基づく識別データ５０４によりメディアアイテムを識別するマスタ類似性テーブルのエントリが存在する。更に、そのメディアアイテムに類似するか又は相関すると考えられる他の各メディアアイテムがテーブル５０８に一覧表示される。このように、テーブル５０２はマスタ購入マトリクス４０２の各メディアアイテムに類似する全てのメディアのリストを維持する。

アイテムは、メディアアイテムに類似するか又は相関すると考えられるのに十分なスコアを有する場合、マスタ類似性テーブルに含まれる。どの所定のアイテムに対しても、他のアイテムの殆どが全く類似しない。類似性スコアが十分に低い場合、類似性テーブルに含まれない。類似性スコアが十分に低いか又は高いかを判定するための閾値は、動的であっても静的であってもよい。例えば類似性スコアが−１〜１の範囲である場合、閾値は静的に０.５に設定されてもよい。尚、−１は全く類似しないことを示し、１は非常に類似することを示す。閾値は、マスタ購入テーブルの曲の同時発生回数に基づいて動的に設定されてもよい。例えば、曲の発生が１００回未満の場合は閾値０.９であり、曲の発生が５,０００回未満の場合は閾値０.７であり、曲の発生が２５,０００回未満の場合は閾値０.６であり、曲の発生が２５,０００回以上の場合は閾値０.５とする。閾値は、利用可能な記憶装置又は他のどのパラメータに基づいてもよい。

換言すると、マスタ類似性テーブル５０２は、類似性スコアの全て又は一部を取り入れてもよい。マスタ類似性テーブルがある特定の記憶サイズに適合するように制約される必要がある場合、最適な類似性又は最強の類似性のみが含まれ、残りは除かれる。同様に、十分なプログラム参加者がメディア一覧表にアイテムを有さない場合、そのアイテムは除外される。これに対する１つの変形例は、アイテムがマスタ類似性テーブルに含まれるのに適当であるためにはユーザのライブラリにおいて最小回数発生することを要求することである。例えば２つのアイテムが５回以下の同時発生回数しか有していない場合、すなわち５人以下のユーザが双方のアイテムを有する場合、システムは残りのスコアを算出しない。

いくつかの実施形態において、マスタ類似性テーブルは等価関係を更に格納できる。例えばテーブル５０２のメディアＩＤ１７は、１９９０年に演奏されたようなLuciano Pavarottiによる「O Sole Mio」に対応してもよい。Enrico Caruso及びMario Lanza等のアーティストによる「O Sole Mio」の複数の演奏がオンラインストアで入手可能であり、等価なメディア５０６と考えられる。他の注目すべき種類の等価なメディアは、公式のアルバムトラック、生楽器によるアコースティックトラック、ライブコンサートトラック、他のバンドによるカバートラック及び同一曲の外国語トラックを含む。シングル曲が列挙された全ての形式及びそれ以上の形式で存在してもよい。等価であるかの判定は、手動で実行可能であり、あるいは実際のメディアコンテンツ、メタデータ及び／又は他の入手可能なデータに基づいて自動的に実行可能である。各々に対する等価なメディアＩＤは、メディアＩＤ５０４と並べて提示され、それらのメディアＩＤの各々が同一であると考えられること及びそれらが共にカウントされることを識別する。

マスタ類似性テーブルのＩＤは、メディアに索引を付けるために購入マトリクス３０６で使用されるＩＤと同一であってもよく、あるいは完全に異なる方式に基づいてもよい。２つのＩＤが一致しない場合、一方のＩＤを他方のＩＤに変換するために変換関数又は参照変換テーブルが提供される。２つのＩＤの間で共有される共通のＩＤ空間は、性能を犠牲にせずに維持することが最も容易で単純である可能性が高い。

ユーザ類似性テーブル
マスタ類似性テーブルが類似するメディアの領域（universe）を含むが、個人のメディアライブラリは類似するメディアの領域のより小さい部分集合をほぼ確実に含む。従って、制約された集合又は個別の類似性テーブルが生成される。制約は、所定のライブラリにおけるメディアの入手可能性に適応される。制約された集合は、メディアライブラリで見つけられない類似するメディアに対する参照を更に含んでもよい。これは、提案されたメディア購入品の対象をあるユーザにするために行われる。共通のメディアの好みを有する他のユーザが自身のライブラリに提案された購入品を既に有するため、そのような対象になった提案された購入品はそのユーザにとって更に魅力的になるだろう。

マスタ類似性テーブル５０２が計算され且つポピュレートされると、個別の類似性テーブル６０２が生成される。図６は、個別の類似性テーブルを示す。個別の類似性テーブル６０２は、個人のメディアライブラリに含まれる各曲に対するメディアＩＤ６０４及びそのメディアＩＤと相関されたメディアを含む。相関されたメディア６０６は、中括弧記号で示す。個別の類似性テーブル中の相関されたメディアは、アイテムのマスタ類似性テーブルに配置された格納された類似するアイテム５０８のリスト全体の部分集合である。部分集合が選択され、それに基づいてメディアは個人のメディアライブラリに存在する。換言すると、個人のライブラリ中の曲毎に、個人のライブラリに含まれた類似するメディアのリストが生成される。アイテム６０８は、値がプログラム参加者のライブラリに存在しないが購入することを推薦される曲のメディアＩＤである別の実施形態を示す。

個別の類似性テーブルは、サーバにおいてサーバにより生成されてクライアントデバイスによりダウンロードされるか、あるいはユーザのメディア一覧表のアイテムに対する類似性データのみをダウンロードすることによりクライアントにより作成される。類似性テーブルが作成される場所に関係なく、処理は同一である。メディアアイテムは、アイテムのプログラムに基づく類似性識別データによりマスタ類似性テーブルにおいてルックアップされる。次に、システムはそのメディアアイテムに対する類似性データの場所を索引でルックアップできる。システムは、ルックアップ動作の結果に基づいて類似するアイテムを検索できる。これらのアイテムは、ユーザのメディアライブラリのメディアアイテムと更に比較され、ユーザのメディアライブラリに存在するアイテムのみが個別の類似性テーブルに格納される。更なる一実施形態において、ある非常に類似するトラックは、個別の類似性テーブルに記録され、ユーザに対して購入を提案するために使用される。

いくつかの実施形態において、ライブラリ毎の少なくとも１つの個別の類似性テーブルはサーバにより生成可能である。クライアントは、サーバにライブラリデータを送出でき、サーバは、ライブラリのアイテムを識別でき、そのライブラリのアイテムに関するマスタ類似性テーブルから類似性データを抽出することによりそのライブラリに対する個別の類似性テーブルを生成できる。結果として得られた個別の類似性テーブルは、プレイリストを生成する際に使用するためにクライアントにダウンロードされる。同一の個別の類似性テーブルは、周辺装置に対する個別の類似性テーブルを作成するためにクライアントにより使用される。

ユーザは、これらの個別の類似性テーブルを使用して、ユーザの母集団全体から導出されたデータにより利益を得る。ユーザは、プレイリストを作成し且つ新しいメディア購入に対する提案及び種々の他の可能性を受信するために類似性データを使用できる。

協調フィルタリングに影響を及ぼすユーザデータ
プレイリストが類似性データに基づいて生成される実施形態において、ユーザがプレイリスト中の聴きたくない曲をスキップしたことによるフィードバックを提供できるか、又はシステムはそのようなフィードバックを要求できる。あるいは、ユーザはプレイリスト中の聴くことを楽しんだメディアアイテムに正の評価を与えることができる。そのようなデータは、クライアントデバイスからアップロードされ且つサーバにより受信される。フィードバックデータは、マスタ購入インデックス又は別個のテーブル等の任意の数の種々のモードで格納される。フィードバックは、（公序良俗違反につき、不掲載）Store等のオンライン音楽ストアからも導出可能である。本実施形態において、オンラインストア３０４（図１６）におけるユーザ活動により、フィードバックデータが生成される。オンラインストアにおけるユーザ活動は、メディアアイテムの購入、メディアアイテムのプレビュー、特定のメディアアイテムタイトルの探索、特定のメディアアイテムアーティストの探索又は特定のメディアアイテムジャンルの探索を含むことができる。フィードバックデータは、アイテム間の相関スコアを変更するために協調フィルタリングエンジンにより使用可能である。

母集団からのフィードバックデータは、そうでなければ存在したあろう相関を潜在的に削除できる。例えば、Simon and Garfunkelによる曲Mrs. Robinsonは、Lemonheads又はFrank Sinatraによる同一曲に対する強い相関性を受け入れてもよいが、Simon and Garfunkelのバージョンに基づいてプレイリストを生成しようとするユーザは、カバー曲が異なるジャンルであることに起因した、異なるバージョンを好まない可能性がある。ある期間にわたり、曲のスキップ又はプレイリストからのアイテムの除去等のフィードバックデータは、相関されたアイテムのリストから一方又は双方のカバーバージョンを削除するために使用される。

いくつかの実施形態において、更にユーザフィードバックは、最初に協調フィルタリングエンジンにより使用されるためにサーバにフィードバックを送出せずにクライアントデバイス上で直接類似性データを変更するために使用され得る。これらの実施形態において、ユーザフィードバックデータは、最初にサーバと同期せずにクライアントデバイス上の個別の類似性テーブルに格納された関係に直接影響を及ぼすことができる。あるいは、類似性テーブルは変更されないが、制約がユーザフィードバックデータに基づいて生成される。例えばユーザが類似するアイテムを頻繁にスキップする場合、クライアント自体は、個別の類似性テーブルからそのアイテムを除去することによりそのアイテムを類似するものと考えなくなってもよく、あるいはプレイリストアルゴリズムにおける制約等の他の手段により頻繁にスキップされたアイテムの追加がプレイリストに含まれることを防止できる。

類似性テーブルの更新
時間の経過にともなって、アーティストが新しい音楽を作成し且つ新しいアーティストが登場すると、新しいメディアアイテムはオンラインストア及び更にはマスタ購入テーブルに追加される。従って、オンラインストア３０４の既存のアイテムとオンラインストアの新しく追加されたアイテムとの間の相関性が形成されてもよい。例えばユーザが自身のメディアライブラリに曲Ａを有し、その後オンラインストア３０４で最近紹介された新しく追加された曲Ｂを購入する場合、曲Ａと新しく追加された曲Ｂとの間の新しい相関性が形成されてもよい。ユーザが新しく追加された曲Ｂを購入する場合、トランザクションが購入マトリクス３０６に記録され、更新済み購入マトリクス３０６が生成される。あるいは、曲ＢはＣＤからトラックをコピーすることによりユーザのライブラリに追加されていてもよい。そのような状況において、結果は同一である。曲Ａ及び曲Ｂの双方がユーザのメディアライブラリにある限り、この同時発生は、更新済みマスタ購入マトリクスに記録される。

協調フィルタリングエンジン３０８は、上述したようにアイテムの更新済みマスタ類似性テーブル３１６を生成するために、更新済み購入マトリクス３０６からの情報を使用する。その後、更新済みの個別の類似性テーブル３２２は、変更された更新済みマスタ類似性テーブル３１６のそれらのアイテムのみを抽出することによりユーザ毎に生成される。あるいは、完全に新しい個別の類似性テーブルは、新しいデータに基づいて作成可能である。

クラスタ
更に上述の類似性データは、メディアアイテムのグループを識別するためにクラスタリング解析において利用可能である。概念的なレベルにおいて、クラスタリング解析は、類似性ベクトルに基づいてアイテムをグラフ化し、グラフにおいて相対的に近接して示されるアイテムを選択する。例えば、図７はメディアアイテム及びそのアイテムに類似する全てのメディアアイテムを表す類似性ベクトルであるいくつかのメディアアイテム４２０〜４２８を示すグラフである。図中、ベクトルは類似性ベクトルの３つのクラスタを形成するようにグループ化される。クラスタ解析は、それぞれメディアアイテム４２０のクラスタ４３０にグループ化し、メディアアイテム４２１〜４２６をクラスタ４３２にグループ化し、メディアアイテム４２７〜４２８をクラスタ４３４にグループ化する。

音楽の場合、クラスタ４３０、４３２及び４３４は、別個のジャンル、サブジャンル又は他のメディアアイテムより強く互いに関連付けられるメディアアイテムの単なるグループ、に属するメディアアイテムを表すことができる。

図８は、クラスタ４３２の子クラスタを示す。図８は、図７と同一の類似性ベクトル空間を示すが、図７でクラスタ４３２にグループ化されたメディアアイテム４２１〜４２６は、子クラスタ４３５、４３６及び４３７にさらに細分される。子クラスタ４３５〜４３７は、クラスタ４３２に含まれるアイテムのより小さいグループにクラスタ解析を再適用することにより生成される。

図９は、図７及び図８で算出されたクラスタを樹形図で示す。最上位レベルにおいて、CLUSTER0は図７及び図８で表される全てのメディアアイテムを含む。クラスタ４３２、４３０、４３４を有する第２のレベルは、図７の同一番号のクラスタに対応する。樹形図の最下位の子クラスタ４３５、４３６、４３７は、図８の同一番号のクラスタに対応する。より具体的には、CLUSTER 0にクラスタリング解析を実行することにより、図７に示され、図９の中間ノードにより示されるクラスタが得られる。同様に、親クラスタ４３２にクラスタ解析を実行すると、図８及び図９に示す子クラスタ４３５、４３６、４３７が結果として得られる。

クラスタリング解析には既知の数学的な形式が多く存在する。本発明の技術において、階層クラスタリングの機構が採用される。階層クラスタリングは、上述したように木構造で表され得るクラスタの階層を作成する。これらのアルゴリズムは、凝集型（agglomerative）（「ボトムアップ」）であってもよく又は分枝型（divisive）（「トップダウン」）であってもよい。凝集型アルゴリズムは、別個のクラスタである各要素から開始し、それらを連続するより大きなクラスタにマージする。分枝型アルゴリズムは集合全体から開始し、それを連続するより小さなクラスタに分割していく。分枝型クラスタリング解析を図７〜図９に示した。クラスタリング解析に対する技術が多く存在し、それらのいずれもが本発明の技術において適用されることが理解されるだろう。

いくつかの実施形態において、適用されるクラスタリング解析の種類はｋ平均解析である。ｋ平均アルゴリズムは、中心が最近接するクラスタに各点を割り当てる。中心は、クラスタ中の全ての点の平均である。すなわち、その座標は別個にクラスタの全ての点にわたる次元毎の算術平均（arithmetic mean）である。例えば、データセットが３次元であり且つクラスタが２つの点、X = (x1, x2, x3)及びY= (y1, y2, y3)を有する場合、中心Ｚは、Z = (z1, z2, z3)となり、ここで、z1= (x1 + y1)/2、z2= (x2 + y2)/2、z3= (x3 + y3)/2である。

ｋ平均解析は、（１）クラスタ数ｋを選択するステップと、（２）ｋ個のクラスタを無作為に生成し且つクラスタの中心を判定するか、あるいはｋ個の無作為な点をクラスタの中心として直接生成するステップと、（３）際近接するクラスタの中心に各点を割り当てるステップと、（４）新しいクラスタの中心を再度算出するステップと、（５）最下位レベルのクラスタが最下位レベルの各クラスタ内の判定されたメディアアイテム数より少ないメディアアイテムを有するようになるまで先の２つのステップを繰り返すステップとを実行する。ｋ平均解析の一実現例を図１０〜図１２に示す。

いくつかの実施形態において、メディアアイテムのデータベースは、任意の適度な基準に基づいてキャノピー（canopies）に分割される（１０１２）。非常に類似するメディアアイテムのクラスタを達成する必要はなく、その一方でこのステップは種々の方法で有用である。まず第１に、大きなデータセットの場合、データベースの単純な分割により、データベースの最上位レベルに対するクラスタを算出するのに必要とされる計算資源が低減される。数百万又は数十億個のメディアアイテムのデータベース全体に対して統計的クラスタリング解析を実行する代わりに、統計的クラスタリング解析は全体のより小さい部分集合に対して実行される。

更に、データベースをキャノピーに分割することにより、結果として得られるクラスタの品質が向上される。例えばキャノピーは、編集分割に基づいて生成される。図１３において、キャノピー４５０、４５１及び４５３は、音楽アイテムのデータベース全体を音楽メディアアイテムの類似しないジャンルの重なり合わないグループに分割する例である。そのような例において、ロック４５０、ラップ４５１及びオペラ４５３の種々の音楽メディアアイテムが互いに類似することはないという編集決定が行われており、メディアアイテムのデータベースは最初にこれらのキャノピーに分枝されている。

いくつかの実施形態において、キャノピーは編集決定に基づいてサブキャノピーに分割される。しかし、好適な実施形態において、２つの異なるキャノピーのアイテムが後で同一クラスタにグループ化できないため、キャノピーは、キャノピー又はサブキャノピーがグループ化されるべきでないアイテムを分離するように分割されるべきである。

次に、選択されたクラスタリングアルゴリズムは、各キャノピー／サブキャノピーに対して実行され、データベースを更にクラスタに細分する。図１３に示すように、ロックキャノピー４５０は、類似するメディアアイテムの２つのサブグループ、すなわちポップ／オルタナティブ（alt）／クラシックロック４５４及びハード／メタルロック４５５に分割されている。同様に、ラップキャノピー４５１は、東海岸ラップクラスタ４５９及び西海岸ラップクラスタ４６０に更に分割されている。尚、図１３はジャンル及びサブジャンルで細分されているクラスタを示すが、これは例示する目的でのみ示される。統計的クラスタリングアルゴリズムは、プログラム参加者のライブラリにおけるメディアアイテムの発生回数に基づく類似性データの統計的解析に従ってクラスタを細分し、種々の互換性のあるジャンルのメディアアイテムを有するクラスタを生成することになる。

クラスタリング解析は、以下のように実行される。所定のキャノピー又はサブキャノピーのアイテムは、Ｘ（Ｘは１より大きい任意の数字）個のクラスタに無作為に分割される（１０１３）。クラスタ毎に重心が計算される。

図１２は、重心を計算する１つの方法を示す。１０５０は、所定のクラスタのメディアアイテムに対する類似性ベクトルの集合である。類似性ベクトルは、類似性の降順でメディアアイテムに最も類似するメディアアイテムを一覧表示する。例えば、１０５０はクラスタにグループ化されたアイテム１、２及び２５に対するベクトルを示す。アイテム１は、最も類似するメディアアイテム１及び２番目に類似するアイテム２５を有する。クラスタの各アイテムは、アイテムがクラスタの他のアイテムにどの程度類似するかに基づいて値を与えられる。これは、重み付き値を各アイテムに割り当て（より類似しないアイテムより大きい重みをより類似するアイテムに重み付けする）且つそれらの値を加算することにより達成される。例えば、１０５２はクラスタに提示されるメディアアイテムの類似性ベクトルで見つけられた各アイテム及び関連する重み付き値を有するテーブルを示す。尚、テーブルの全てのメディアアイテムが実際にクラスタにあるわけではない。

アイテム１は、アイテム１に最も類似していたため、値１００を与えられ、アイテム２５は２番目に類似していたため、値９９を与えられる。各アイテムに対するスコアは合計され、結果としてアイテムのスコアを与える。このクラスタの場合、アイテム１はスコア１９９を受ける。アイテム２５は、各リストで高くランク付けされ、より高いスコア２９８を受ける。スコアはアイテム毎に計算される。最終的なスコアはソートされ、クラスタ１０５４全体に対する類似性ベクトルを作成するために使用される。この処理は、Ｘ個のクラスタの各々に対して繰り返され、結果としてＸ個の重心を与える。

多くの種々のスコアリング機構が考えられ、本発明の技術内で考慮される。上述の例示的な方法は、所定のクラスタに対する重心を計算する１つの方法である。本発明の例において、重心はクラスタ内のメディアアイテムの全てのメディアアイテムの類似性ベクトルの平均であるのが効果的である。

重心が計算されると、無作為に作成されたクラスタは廃棄される。その目的は、重心を確立することのみであった。次に、キャノピー内の各メディアアイテムに対する類似性ベクトルは各重心（更にベクトル）と比較され（１０１５）、各メディアアイテムはＸ個のクラスタを作成するために最近接する重心を含むクラスタに割り当てられる（１０１６）。

処理は、既存のクラスタに対する重心を算出し（１０１４）、各アイテムの類似性ベクトルを新しい各重心と比較し（１０１５）且つアイテムを最近接する重心にクラスタリングする（１０１６）ことにより最高品質のクラスタを生成するために繰り返し実行される。最大回数の繰り返しが完了すると（１０２２）又はメディアアイテムが一方のクラスタから他方のクラスタに移行されなくなると（１０２４）、処理は終了する（１０２６）。このように、繰り返し処理は、重心を改善し且つ曲を適切なクラスタに移行することによりクラスタ解析をゆっくり向上する。

処理全体は、どの所定のクラスタに対しても再実行可能である。例えば処理は、図１１に示すようにサブクラスタを作成するために上記で作成されたＸ個のクラスタのどのクラスタに対しても再実行可能である。Ｘ個のクラスタのうちいずれか１つがＸ個のサブクラスタに無作為に分割される（１０２８）（ここでも、Ｘは１より大きい任意の数字である）。各サブクラスタに対する重心は計算され（１０３０）、各メディアアイテムの類似性ベクトルは、各重心に対するベクトルと比較され（１０３４）且つクラスタにグループ化される（１０３６）。新しい重心が計算され（１０３０）、各メディアアイテムは、その重心と比較され（１０３４）且つクラスタにグループ化される（１０３６）。処理は、最大回数の繰り返しが完了するまで（１０４６）又はメディアアイテムがクラスタを変更しなくなるまで（１０４８）繰り返され、処理は終了する（１０５０）。

メディアアイテムの母集団が所望の数のクラスタ又は所望のサイズのクラスタに減少されるまで、処理は繰り返し続ける。

上述したクラスタリング方法に対する別の変形例において、メディアアイテムを個別にクラスタリングするのではなく、アイテムはアーティストによりクラスタリングされる。上述したように、メディアアイテムは編集決定に基づいて分割され、同一のアーティストによる類似しない曲がグループ化される可能性をなくす。

ベクトルは、キャノピーで表されるアーティスト毎に、図１２に示される重心が作成された方法と同一の方法で作成される。キャノピーにおけるアーティストによる各曲はグループ化され、アーティストベクトルが生成される。ベクトルは、キャノピーであるアーティストによる各曲を含む。アーティスト毎にベクトルを算出したため、クラスタリングアルゴリズムは、メディアアイテムの代わりにアーティストベクトルを使用でき、アーティストをクラスタに編成できる。処理が選択した回数だけ繰り返されるか又は選択した数のアーティスト、例えば３人のアーティストが各クラスタに残ると、繰り返しクラスタリング処理は完了する。クラスタリング処理が完了すると、アーティストベクトルはアーティストのベクトルの各曲を識別することによりメディアアイテムに戻され得る。

上述の処理は、サーバ上のデータベースの全てのメディアアイテムのクラスタを生成するために使用される。データベース全体がサーバクラスタの完全な木に分割されると、サーバクラスタの木は参加者クラスタを生成するために使用される。参加者クラスタは、個別のユーザのライブラリに固有であり、参加者のメディアライブラリに含まれるメディアアイテムのみを含む。

プログラム参加者のメディアライブラリは、木の最下位レベルのサーバクラスタのプログラム参加者のメディアライブラリの各メディアアイテムを見つけ且つ少なくとも判定された数のアイテムを有する参加者クラスタが蓄積されるまでクラスタの木を構築することによりサーバクラスタにマッピングされる。この方法を図１４に示す。図１５は、階層に従ってラベル付けされたサーバクラスタの木にマッピングされたプログラム参加者のライブラリを示す。木はサーバクラスタの木構造全体と同一の関係を表すが、サーバクラスタのいずれか１つにあるプログラム参加者のメディアアイテム数を示すクラスタが示される（いかなる数も有さないクラスタは、プログラム参加者のメディアアイテムのいずれも含まない）。

プログラム参加者のメディアアイテムは、最下位レベルのサーバクラスタにマッピングされる（４７０）。例えば図１５を参照すると、サーバクラスタ１．１．１．１はプログラム参加者のアイテムのうち３つを含む。以下の表１は、最下位レベルの子クラスタのプログラム参加者のメディアアイテムの数を識別する。

図１４に戻ると、処理は、クラスタが判定されたアイテム数より多くのアイテムを含むかを判定する。いくつかの実施形態において、判定されたアイテム数は１０個以上、２０個以上又は５０個以上であってもよい。いくつかの実施形態において、クラスタのサイズは判定された最大値に制限される。本発明の例の目的のために、判定されたアイテム数は２０個以上である。４７１において、処理は、サーバクラスタ１．１．１．１が２０個未満のアイテムを含むことを判定し、４７２に進み、他の参加者クラスタからのメディアアイテムを共通の親に追加する。クラスタ１．１．１．１がプログラム参加者のメディアアイテムのうち２つ及び１つをそれぞれ含むクラスタ１．１．１．２及び１．１．１．３と共通の親を共有するため、これらのメディアアイテムは１つのより大きな参加者クラスタにマージされる。ここでも、処理は参加者クラスタのメディアアイテム数をチェックし、クラスタにはアイテムが６個しか存在しないため、処理は繰り返される（４７２）。この時、サーバクラスタ１．１．１と、１．１．２及び１．１．３は共通の親を共有し、これらのクラスタをマージすることにより２８個のメディアアイテムを含む参加者クラスタが結果として得られる。ここで、処理が判定されたアイテム数に関してチェックする場合（４７３）、参加者クラスタは１９個を超えるため、処理は終了する（４７４）。図１５において、クラスタは４７５で示される。

上述したように、木のより上位でクラスタをマージすることにより類似するアイテムをグループ化するこの処理は凝集と呼ばれる。

図１５は、図１４に示す処理の他のいくつかの潜在的な結果を示す。例えば参加者クラスタ４７６は、十分な数のアイテムを凝集するために１回の繰り返しのみを要求した。クラスタ４７７は、全ての分岐に対する樹形図の最下位レベルが同一である必要がないことを示す。クラスタ４７７は、５次のサーバクラスタから開始し、結果として参加者クラスタ４７７を得るために全ての５次及び４次のサーバクラスタを同一の親にマージした。

４７８は、失敗したクラスタを示す。十分なアイテムを凝集して所望のサイズを達成するために、４７８は最上位次数のサーバクラスタを含む必要がある。そのような例において、十分な類似性を示すアイテムがクラスタに組み合わされると判断される。クラスタは、木の特定のレベルを超える凝集を許可しないようにプログラミング決定が行われるため、失敗する可能性がある。あるいは、クラスタはこの時点で多すぎるアイテムを有するために失敗する可能性がある。

システムの概要
図１６は、上述した実施形態を実行できる１つのシステム３００の一例を示す。購入マトリクス３０６は、各ユーザのライブラリの全てのメディアアイテムに関するデータを格納する。協調フィルタリングエンジン３０８は、購入マトリクス３０６のデータを使用して他のメディアの各々に対する各メディアアイテムの同時発生の発生率を判定する。協調フィルタリングエンジン３０８は、プログラム参加者の母集団にわたるユーザの好みに従って類似性スコアを調整するために、オブジェクト３２４及び３２６に格納されたフィードバックデータをオプションとして使用できる。協調フィルタリングエンジンの出力は、所定のメディアアイテム３１８に類似すると考えられる全てのメディアアイテム３２０を格納することによりマスタ類似性テーブルに格納される。類似するメディアアイテム３２０は、相関性の最も高いアイテムから相関性の最も低いアイテムの順序で提示されるようにソートされる。

同様に、協調フィルタリングエンジンは、データベースをサーバクラスタ３３２の木に分割するために入力を処理できる。あるいは、サーバクラスタ３３２の木は、協調フィルタリングエンジンにより出力されたデータから生成される。いずれのデータセットもクラスタリング解析に適切である。

オンライン管理ツール３０４は、クライアント側３０２及びサーバ側３０１に対するインタフェースとしての役割を果たす。好適な一実施形態において、オンライン管理ツール３０４は、オンラインストアと関連付けられる。一実施形態において、オンラインストアは、類似性データを生成する際に協調フィルタリングエンジン３０８により使用されるデータ３１０を生成してもよい。しかし、クライアント３０２は、クライアント３０２に格納されたメディアアイテムに関する情報をアップロードし且つサーバ３０１から類似性データ及びクラスタリングデータをダウンロードする。クライアントに固有の類似性データは、クライアントデバイス３０２で個別の類似性テーブル３２２を生成するためにオンライン管理ツール３０４を使用してマスタ類似性テーブル３１６から直接ダウンロードされてもよい。あるいは、個別の類似性テーブルは、サーバ３０１により生成され且つクライアントデバイス３０２にダウンロードされてもよい。更にクライアントデバイスは、より適切な類似性データを生成するのを助長するためにオンライン管理ツール３０４を介して協調フィルタ３０８にフィードバックデータを通信できる。

同様に、クライアントデバイス３０２は、サーバ３０１からクラスタリング情報をダウンロードできる。いくつかの実施形態において、サーバ３０１は、プログラム参加者に対する参加者クラスタを計算し、参加者クラスタを識別する情報及び参加者クラスタ３３０に属するメディアアイテムを送出する。いくつかの実施形態において、サーバは、各サーバクラスタのプログラム参加者のメディアアイテムの各々の存在を詳細に示す情報を送出し、参加者クラスタの凝集をクライアントに行わせることができる。

クライアント
図１６に示すように、クライアントデバイス３０２は、種々の形態のうちいずれか１つの形態をとれる。クライアントデバイス３０２は、携帯デジタルオーディオプレーヤ、携帯デジタルビデオプレーヤ、スマートフォン、デスクトップコンピュータ、ラップトップコンピュータ、テレビセットトップボックス及びメディアを再生できる他の何らかのデバイス等のデバイスを含む。クライアントデバイスは、デスクトップコンピュータ又は他の中間デバイスを介してオンラインストア３０４と同期するオフライン携帯デバイス、例えばケーブル接続を介してデスクトップコンピュータと同期する（公序良俗違反につき、不掲載）デジタルオーディオプレーヤ、無線ルータを介して無線で同期する（公序良俗違反につき、不掲載）TOUCHデジタルオーディプレーヤ又はセルラ接続を介して無線で同期するスマートフォン等を含むことができる。上記説明から明らかであるように、クライアントデバイスは種々のメディアアイテムの一覧表を含む。クライアントデバイスのユーザが類似性データの使用により利益を得たい場合、ユーザはオンラインインタフェースを介してサービスにアクセスする。あるいは、クライアントデバイスは、インターネットを介してリモートサーバと通信する（公序良俗違反につき、不掲載）デスクトップアプリケーション等のクライアントアプリケーションを介して類似性データサービスにアクセスできる。

オンラインストア３０４は、クライアントデバイスがデジタルメディアを購入できるようにする単一のサーバ又はサーバのクラスタであってもよい。オンラインストアは、他の補助メディア管理機能にアクセス権を付与してもよい。

図１７は、類似性データをクライアントにダウンロードする方法の一実施形態を示す。これがクライアントの初めての協調プログラムへのアクセスである（８４２）場合、クライアントはプログラムに加わること（８４４）により参加することを選択する必要がある。ステップ８４６において、クライアントは専用ユーザ識別コードを与えられる。サーバはクライアントのライブラリと関連付けるためにこのコードを使用するが、クライアントのみが追加の識別情報を含む。サーバは、クライアントデバイス又はユーザ（プログラム参加者）に関する専用又は識別情報を認識しない。専用識別コードが割り当てられると、クライアントデバイスは、メディアライブラリに関する情報をアップロードできる（８４８）。いくつかの実施形態において、ユーザはサーバと共有するメディアアイテムを選択してもよい。

ステップ８４２の結果が、ユーザが既に協調プログラムの参加者であることを示す場合、ステップ８５０において、クライアントは専用識別コードを使用してサーバにログインできる。ステップ８５２において、サーバはメディアライブラリに対する変更に関するクライアントからの情報を要求してもよく、あるいはクライアントは最初に要求されることなくこの情報を共有してもよい。ライブラリに対する変更が行なわれた場合、クライアントは変更に関する情報をアップロードする（８５４）。変更は、編集済みメタデータ、新しいアイテム、削除済みアイテム等の形式をとってもよい。クライアントのメディアライブラリに関する最新情報がサーバに送出されると、ステップ８５６において、クライアントはサーバから新しい類似性及び／又はクラスタデータ（総称して「参加者データ」）を要求できる。あるいは、サーバは新しい参加者データ又は更新済み参加者データの送信を開始してもよい。

いくつかの実施形態において、クライアントは、上記ステップをスキップし、ライブラリを識別する必要なくマスタ類似性テーブルから更新済み結果を単純に要求できる。例えばクライアントは、識別番号により自身を識別せず且つクライアントメディアライブラリ一覧表に対する変更をサーバに通知せずに、特定のアイテム又はアイテムのリストに対する更新を要求できる。

ステップ８５８において、類似性データ及び／又はクラスタデータがダウンロードされる。類似性データはサーバにより先に作成されたテーブルの形式でダウンロードされるか、あるいは、情報はリアルタイムに個別の類似性データテーブルにダウンロード及びフォーマットされる。クラスタデータは、クラスタ及びクラスタに属するメディアアイテムのリストとしてダウンロードされる。データは、同一の又は別個のデータ構造又は送信で提供される。

プレイリストは、個別の類似性テーブルに基づいて生成される。プレイリストは、クライアント側３０２、オンラインストア３０４又は協調フィルタリングエンジン３０８で生成される。プレイリストは、１曲又は複数曲に対する統計的類似性に基づいて生成される。クライアントデバイスが個別の類似性テーブルに基づくプレイリストを採用する場合、特定の曲は、ユーザが期待した曲ではない可能性があり、又はユーザが満足するものではない可能性がある。ユーザが統計的類似性に基づいてプレイリストに入れられた曲を頻繁にスキップする場合、システムはその曲に「ペナルティを科し」、類似性値を減少し、より少ない頻度でプレイリストに含め、最終的にプレイリストから完全に廃棄できる。これは、ユーザが曲をスキップした時に報告することにより実現される。その動作は、クライアントデバイスに記録され、オンラインストアにフィードバックとして送信される。オンラインストアは、このフィードバックを協調フィルタリングエンジンに送出し、協調フィルタリングエンジンは、それを負の相関テーブル３２６に格納する。負の相関テーブルは、類似性の負の指示を格納する。このように、各ユーザは、類似性テーブルから拒否されるまで何度も曲を個別にスキップする必要がない。累積した負のフィードバックは、グループの挙動に基づいてユーザグループに人気のない曲を除去する。従って、これらのプレイリストはユーザの母集団の変化するメディアの好みに適合するように進化する生物のように動作する。

例えば、多くのユーザがプレイリストの特定の曲を常にスキップする場合、あるいは多くのユーザがプレイリストからその曲を削除する場合、その情報は記録され且つ重みを割り当てられ、マスタ類似性テーブルの生成に影響を及ぼす。重みは、報告された負の相関の数又はユーザ対話の他の側面に基づいてもよい。逆に、特定の曲に対する肯定的なユーザ対話は正の相関を提供する。例えば、多くのユーザが既存のプレイリストに同一の曲を追加する場合、あるいは多くのユーザが特定の曲の間に音量を上げた場合、これらの正の相関はオンラインインタフェースを介してサーバに報告され、正の相関テーブルに格納される。

クライアントは、サーバとの対話に加えて他のクライアント又は周辺装置と対話してもよい。好適な一実施形態において、クライアントは、（公序良俗違反につき、不掲載）携帯音楽プレーヤ等の携帯音楽プレーヤと対話するパーソナルコンピュータであってもよい。そのような例において、クライアントデバイスは周辺装置において使用する個別の類似性テーブルを準備できる。サーバがクライアントライブラリのメディアアイテムのみに対する情報を含むクライアントに対する個別の類似性テーブルを準備できるのと同様に、クライアントは周辺装置のライブラリのメディアアイテムのみに対する情報を含む周辺装置に対する個別の類似性テーブルを準備できる。クライアントは、他の何らかのデータアイテムのように、個別の類似性テーブルを周辺装置にロードできる。

周辺装置
クライアントがサーバを使用して動作するのと同様に、周辺装置はクライアントを使用して動作しようとする。例えば周辺装置は、コンテンツに対する変更をクライアントに通知し、それらのコンテンツに対する類似性データを要求できる。更に好適な一実施形態において、（公序良俗違反につき、不掲載）デスクトップアプリケーションを実行するパーソナルコンピュータが（公序良俗違反につき、不掲載）携帯メディアデバイスを管理するのと同様に、周辺装置はクライアントにより管理される。本実施形態において、一般にクライアントは、周辺装置のコンテンツに対する変更に影響を及ぼすツールであることによりそれらの変更を既に認識しているため、それらの変更により更新される必要はない。本実施形態において、クライアントは、クライアントの個別の類似性テーブルの利用可能なデータに基づいて周辺装置の類似性テーブルを最新の状態に維持できる。更に周辺装置は、後でサーバに送信するためにフィードバックデータをクライアントに通信できる。

ここでも、クラスタデータは、類似性データが更新される方法に関して同様の方法で周辺装置に送出される。クライアントは、周辺装置に存在するメディアアイテムのみと共にクラスタＩＤを送出できる。

いくつかの実施形態において、周辺装置は、クライアントデバイス自体としてサーバと直接対話できる。益々多くの携帯メディアプレーヤがインターネットにアクセスする機能を有するため、携帯デバイスは、最新の類似性データをダウンロードするため又はマスタ購入マトリクスを更新するためにサーバと直接対話できる。そのような一実施形態において、周辺装置は、クライアントの全ての機能を有することができる。

プレイリストの生成
上述したように、本明細書で説明された方法により生成された類似性データの１つの用途は、プレイリストを生成するために類似性データを使用することである。プレイリストを生成することが個別の類似性テーブルの全ての類似するアイテムを再生することと同じくらい単純である可能性がある一方で、最適な結果はプレイリスト生成モジュールを使用して取得される可能性が高い。図１８は、プレイリストを生成する方法の一実施形態を示す。１つ以上のシードトラックが、ステップ８０２において選択され、ステップ８０４においてプレイリストに追加される。ステップ８０６において、シードトラックに対する類似性データが個別の類似性テーブルにおいてルックアップされ、ステップ８０８において、類似するトラックが候補リストに追加される。候補は、プレイリストに追加される潜在的なトラックのリストである。候補がプレイリストに追加されるかは、一連の制約に対して候補を評価することにより判定される。

制約は、曲がプレイリストに追加されるかに関して制限する。殆どの場合、制約はプレイリストの品質を向上させる。１つの制約は、プレイリストにおいて特定の間隔を要求してもよい。例えば、アーティスト間隔制約が有効である場合、Radioheadによる２曲は連続して再生されない。同様の一例において、制約は、同一のアルバム又は曲のタイトルからの曲がプレイリストにおいて互いの所定の曲数内で発生しないようにしてもよい。別の制約は、互換性のないジャンルの曲が同一のプレイリストにおいて再生されないようにする。更に別の制約は「ジッタ（jitter）」機能であってもよい。ジッタは、受け入れ可能である曲がプレイリストに追加されることを無作為に防止できる。ジッタは、同一のシードトラックの選択に基づいて同一のプレイリストが毎回生成されるのを防止するためにプレイリストにランダム性を提供する。更に別の制約は、所定の回数を超えてスキップされたどの曲も制約を満たさずプレイリストに含まれないスキップ回数制約であってもよい。

制約は、容易に変動する特定のパラメータ又は変数に依存することが理解されるべきである。例えば同一アルバム又はアーティストの２つの曲の間に入ることが要求される曲数は変動する可能性がある。同様に、トラックを除外するのに必要なスキップ回数又は互換性のあるジャンルのメンバは変動する可能性がある。一実施形態において、そのような変数の設定はユーザにより設定される。別の実施形態において、そのような設定は、サーバにより選択され且つサーバから発行され、クライアントが更新済み類似性データをダウンロードするために接続する度にサーバにより調整されてもよい。

正の制約も考慮されることが理解されるべきである。高い再生率又は高い評価を有する曲は、プレイリストに移動されるか、あるいはジッタ機能又は他の負の制約の影響を受けない。更に多くの制約を加え、制約を除去し、制約をより厳しくするか又は緩和することにより多くの変形例が可能である。各変形例は、本明細書で説明される方法により考慮される。

ステップ８１０において、考慮すべき次の候補が選択され、ステップ８１２において、そのメタデータが検索される。メタデータは、制約を評価する際に必要とされる候補に関する情報を提供する。ステップ８１４、８１５及び８１６において、トラックは制約により評価される。図１８において３つの制約のみが示されるが、任意の数の可能な制約が存在してもよいことが考慮される。曲が１つの制約を満たした場合、全ての制約を満たすまで次の制約に渡され、すべての制約を満たすとステップ８１８においてトラックはプレイリストに追加される。その後、ステップ８２０に進み、プレイリストの新しい曲に対する類似性データを取り出す。この類似性データは、プレイリストに含めるかを考慮するために候補リストに付加される。

トラックが制約を満たさない場合、ステップ８３０に飛び、評価する追加の候補がリストにある場合はステップ８１０に戻る。しかし、追加の候補がリストにない場合、全ての候補が制約を満たさないか又はプレイリストにあることを意味し、ステップ８３２は、全ての候補がデフォルト値に設定されているかを判定するために制約をチェックする。デフォルト値に設定されている場合、１つ以上の制約を緩和することにより、先に拒否された候補がステップ８２６において再度考慮された際にプレイリストに追加されることが許可されることを期待して、ステップ８２８において制約が緩和される。全ての候補が再び制約を満たさない場合、ステップ８３２は、制約が既に緩和されていたことを判定し、処理を終了する。

制約を緩和することは、種々の形態のうちいずれか１つの形態をとれる。いくつかの例において、１つの制約のみが緩和される。他の例において、複数の制約が緩和される。例えば第１の制約が、同一アーティストの２曲が互いの４曲以内に再生されないことを要求する場合、制約は、間に１曲入ることのみを要求するように緩和されるか又は制約は完全に除去される。いくつかの実施形態において、全ての制約が緩和されるわけではない。一例はジャンルの制約である。特定のジャンルは互換性を全く有さない場合があるため、ジャンルの制約は追加のジャンルを含むように緩和されない。

ステップ８２６に戻ると、候補トラックが制約を満たさず且つ追加の候補が入手可能でない例において、制約は緩和される。緩和された制約のために、候補が全ての制約を満たしてプレイリストに追加される場合、ステップ８２２及び８２４において制約は標準に戻される。ステップ８２２は、制約が緩和されているか又はデフォルト設定になっているかを判定するために制約をチェックする。制約がデフォルト設定になっている場合、ステップ８１０に戻り、リスト中の次のトラックを考慮する。しかし、制約が緩和されていることをステップ８２２が判定する場合、ステップ８２４に進み、制約を標準に戻し、ステップ８１０に戻り、リスト中の次の候補を考慮する。この処理は、候補が緩和された制約を満たさなくなるまで継続し、ルーチンはステップ８３４で終了する。

曲は、最も類似するものから最も類似しないものの順番でプレイリストに追加される必要はない。曲はランダム化アルゴリズム又は他の論理を使用してどんな順序で追加されてもよい。

生成されたプレイリストは、静的であっても動的であってもよい。動的なプレイリストは、類似性データが進化し且つ新しいアイテムがユーザのライブラリに追加されるのに伴いある期間にわたり更新される。あるいは、ユーザが楽しみ且つ変更せずに保持したいプレイリストが生成される場合、ユーザは類似性データに影響を受けない別個の静的なプレイリストとしてそのプレイリストを保存できる。このように、生成された特定のプレイリストが「完璧」であるとユーザが感じている場合、そのプレイリストは、サーバを介して類似性テーブルにおいて反映された一般大衆の変化する好みにより損なわれずに維持される。

参加者クラスタからのミックス
参加者クラスタは、メディアアイテムのミックスを生成する時に有用である。例示的な一実施形態として、ミックスは音楽メディアアイテムミックスであってもよい。

上述したように、クライアントデバイスは、プログラム参加者のメディアライブラリ内に含まれるクラスタに関する情報をダウンロードする。任意の数のクラスタが存在してもよいが、いくつかの実施形態において、例えば１２個である制限された数のクラスタのみを常時監視することが望ましい。各クラスタは、他のどのクラスタとも重なり合わないメディアアイテムを含むため、類似するメディアアイテムの種々の集合を表す。その結果、１２個のクラスタの各々が異なる種類の音楽を表せる。プログラム参加者は、クラシックメディアアイテム又は人気のあるメディアアイテムを聴く気分である場合があり、クラスタは、それらの集合からミックスを作成できる。

図１９は、ミックスを生成する基本的な方法を示す。ミックスがプログラム参加者のメディアライブラリ内の類似するメディアアイテムの表現であることを意図するため、クラスタの平均類似性が計算される（８６５）。これは、クラスタで表されるメディアアイテムに対する全ての類似性ベクトルの平均をとることを含む複数の種々の方法で行なわれる。平均ベクトルは、クラスタに対するメディアアイテムの平均類似性を表す。別の方法は、選択したメディアアイテムに対する他のメディアアイテムの類似性スコアが非常に類似しているメディアアイテムを選択し、そのメディアアイテムをクラスタの代表的なメディアアイテムとして使用することである。

処理は、クラスタからいくつかの曲を選択できる（ユーザの介入なしで）。これらのアイテムは、シード曲がクラスタを代表するようにクラスタ平均に対してほぼ平均の類似性スコアを有するのが理想的である。いくつかの実施形態において、クラスタに対して最も高い相関性を有するか又は最も低い相関性を有するアイテムを選択することを回避するのが望ましい。しかし、いくつかの実施形態において、最も強く相関されたアイテムが選択される。いくつかの実施形態において、いくつかのメディアアイテムの選択は、クラスタ内からのメディアアイテムの無作為な選択であってもよい。

選択されたメディアアイテム８６７は、上述したようなプレイリストアルゴリズムに入力される（８６９）。選択した各アイテムは、プレイリストアルゴリズムに対するシードトラックを構成する。プレイリストモジュールがプレイリストに含める候補として使用するためにプレイリスト中の全てのアイテムに対する類似するアイテム８０８、８２０をルックアップするため、プレイリストは最終的にクラスタ外のメディアアイテムを含んでもよい。プレイリストが作成されると、そのプレイリストは、プログラム参加者が再生を中止するまで再生される（８７１）。図１９に示すように、プレイリストが最後まで到達すると、処理はミックスが際限なく続くように継続する。その結果、一般に選択されたクラスタの他のアイテムに類似するメディアアイテムは継続的に再生される。

デバイスを同期させるための類似性データの使用
プレイリストが生成可能であるのと同様に、類似性データは、携帯音楽プレーヤ等の周辺装置をユーザのメディアライブラリの新しい音楽又は異なる音楽により更新するために使用可能である。多くの携帯メディアプレーヤは、制限された容量の影響を受けるため、ユーザのメディアライブラリの全てが（公序良俗違反につき、不掲載）携帯メディアプレーヤ等の携帯デバイスに格納できるわけではない。そのような例において、多くの場合、ユーザは携帯デバイスに格納するメディアアイテムの一部分を選択する必要がある。一部のユーザは、この処理を煩わしいと考え、携帯デバイスに現在格納されているメディアアイテムに退屈していることに気付くだろう。

上記で識別された問題に対する１つの解決策は、携帯デバイスを新しいメディアアイテムで更新するために類似性データを使用することである。本実施形態において、ユーザは携帯デバイスに保持したい音楽の種類を表す特定の数のシードトラックを選択する。プレイリストがシードトラックから生成可能であるのと同様に、ユーザのライブラリのデータアイテムも携帯メディアプレーヤに含むために選択可能である。類似性データが変更され、新しい曲がユーザのライブラリに追加されると、類似性データは携帯デバイスを新しいトラックにより最新の状態に維持するために使用される。

購入の推薦
類似性データは、ユーザが購入する新しいアイテムを推薦するために使用される。マスタ類似性テーブルに発生するがユーザのライブラリに存在しないアイテムは、システムにより購入することを推薦される。一実施形態において、オンラインストアはユーザのライブラリ又はシードトラックの選択に基づいて購入の推薦を行える。オンラインストアは、最近の購入品をシードトラックとして使用して購入するアイテムを推薦できる。別の実施形態において、プレイリストモジュールは、曲がユーザのライブラリの一部である場合にプレイリストのどこに含まれているかをユーザに通知することにより購入する曲を推薦できる。購入の推薦は、携帯メディアプレーヤに対してサーバからクライアントのシステムのどのレベルでも行える。

同様に、プログラム参加者により所有されないサーバクラスタのアイテムは、プログラム参加者に対して購入することを提案される。

いくつかの実施形態において、推薦されるアイテムは、関連付けられた類似性データをまだ有していない新しいアイテムであってもよい。そのような例において、類似性スコアは、新しいアイテムがユーザにより購入されることを推薦されるようにオンラインストアの管理者により提供される。提供された類似性スコアは、同時発生又は他の実施形態に基づく類似性データが入手可能になるまで存続可能である。

同様に、映画のレンタル又は購入が推薦される。殆どの実施形態が曲に関して説明されたが、メディアアイテムはビデオ又は映画を含むいかなるファイルであってもよい。本実施形態において、ユーザはシードアイテムの選択に基づいて類似する映画を要求できる。あるいは、システムは以前のレンタルに基づいて映画を推薦できる。類似性データは、ユーザが後で見る新しい映画をクライアント又は携帯メディアプレーヤに自動的にダウンロードするために使用できることが考慮される。本実施形態は加入サービスの一部であってもよく、あるいは、ユーザは映画を見ないことを選択してレンタル料が発生しないようにできる。

図２０は、類似性データが購入するメディアアイテムを推薦するために使用される方法の一実施形態を示す。ステップ１００２において、シードトラックが選択される。プレイリストがシードトラックに基づいて生成されるのと同様に、購入の推薦はシードトラックに基づく。しかし、少なくとも１つの実施形態において、購入の推薦は、ユーザのライブラリ全体に最も類似するコンテンツに基づいてもよい。

シードトラックが選択されると、ステップ１００４において、図示された方法は次に個別の類似性テーブルからそのシードトラックに対する類似性データをルックアップする。本実施形態において、個別の類似性テーブルは、ユーザのライブラリにないメディアアイテムを更に含むが、類似性データによりユーザのメディアライブラリに存在するアイテムと関連付けられることが理解されるだろう。別の実施形態において、購入の推薦は、ローカルに格納された類似性テーブルではなくサーバから直接行われる。マスタ類似性テーブルからの類似性リストは類似性データを提供でき、サーバ又はクライアントはユーザのライブラリから識別されたトラックを除くことができる。購入の推薦が含まれる必要はなく且つ全てのユーザが推薦する目的でマスタテーブルを共有するため、本実施形態は、最小である可能性がある個別の類似性テーブルを生成するという利点を有する。

既にユーザのライブラリにあるアイテムが購入されることを推薦されないようにするために、ステップ１００６は、ステップ１００４で検索された類似性データからユーザのメディアライブラリに既に存在するアイテムを除去する。いくつかの例において、メディアアイテムはユーザにより既に購入されているが、それらのアイテムはユーザのメディアライブラリに存在しない。これは、多くの理由のためである。例えば、ユーザがその曲を好きではなく削除したためであり、ユーザがメディアアイテムを別のライブラリに格納したためであり、あるいはユーザがメディアアイテムを購入したがまだダウンロードしていないためである。少なくともこれらの例において、これらのメディアアイテムを購入することを推薦することは望ましくなく、これらのメディアアイテムもステップ１００８において除去される。ステップ１０１０は、購入するように推薦されたアイテムを表示する。

当然、方法はユーザにより現在選択されている全ての曲に対して繰り返される。いくつかの実施形態において、ユーザは、購入の推薦を肯定的に要求する必要はない。そのような実施形態において、購入の推薦は、メディアアイテムが再生するために選択される度にメディアオーガナイザ又はメディアストア内に表示される。メディアアイテムが再生されると、グラフィカルユーザインタフェースは、購入するように推薦された他のメディアアイテム又はアルバム等のメディアアイテムのグループを表示できる。好適な一実施形態において、メディアアイテムは入力装置を使用して推薦自体を選択することにより直接購入可能であり、あるいは、メディアアイテムがオンラインストアから購入可能であるように、少なくとも推薦はオンラインストアにハイパーリンクすることが可能である。

別の実施形態において、購入の推薦は、選択が可能でない方法を使用して示される。例えば聴き手が購入した指定したアーティストによる上位の曲を表示するView An Artistページにおいて、システムは既にユーザのライブラリに存在するアイテムの推薦を除去するようにフィルタリングされる推薦を表示できる。

サーバ＞クライアント＞（公序良俗違反につき、不掲載）
特に好適な一実施形態において、１つの場所で有用な方法はシステムの各場所で同等に適用可能である。図２１はこの概念を示す。類似性テーブル９０８及びプレイリストモジュール９１４を含むオンライン音楽ストア９０２を示す。類似性テーブル９０８は、サーバのメディア一覧表のアイテム毎の全ての関係を含む。プレイリストモジュール９１４は、システムの他のどのクライアント又は携帯メディアプレーヤとも同様に、類似性テーブルのデータに基づいて動作する。同様に、サーバより小さいメディア一覧表を含むクライアント９０４が示され、クライアントのメディア一覧表の各アイテムの類似性データは類似性テーブル９１０に格納される。プレイリストモジュール９１６は、携帯メディアプレーヤ９０６又は音楽ストア９０２と同様にローカルの類似性テーブル９１０のデータに基づいて動作する。最後に、クライアント９０４より小さいメディア一覧表を含む携帯メディアプレーヤ９０６を示す。類似性テーブル９１２は携帯メディアプレーヤ９０６のメディア一覧表のアイテムに関連した情報を格納し、プレイリストモジュール９１８はそのデータに基づいて動作する。

図２１は、クライアントが携帯メディアプレーヤのグループに対してサーバのように挙動でき又はより大きいクライアントがより小さいクライアントに対してサーバとして挙動できるという概念を示す。これらの全ては本明細書で考慮される。

殆どの実施形態において、サーバはマスタ購入マトリクス及びマスタ類似性テーブルを維持する唯一の場所であるが、ローカルの類似性テーブルの生成はサーバから導出されたデータに基づいてどのデバイスにおいても行える。サーバにより行われる可能性が高い別の機能は更新である。殆どの実施形態において、サーバは類似性データ更新を行うだけでなく、サーバはシステムのプレイリストモジュール又はソフトウェアコンポーネントを更新できる。

本明細書で説明した全ての処理がリアルタイムで行われる必要はないことが理解されるだろう。多くの場合、処理資源を節約し且つ特定のタスクをオフラインで実行するのが望ましい。例えば協調フィルタリングエンジンは、マスタ類似性データテーブルを生成するためにスケジュールされた時間に実行してもよい。オフライン処理の必要性は、技術の進歩によりなくなる可能性があることが更に考えられる。そのような例において、現在オフラインで実行されるのが好ましい処理はリアルタイムで実行できるだろう。

別の実施形態において、各デバイスが特定の機能をローカルで実行できるが、特定のタスクをサーバに実行させるのが望ましいだろう。例えばサーバは、クライアントに対する個別の類似性テーブルを生成でき、あるいはクライアントに対するプレイリストを生成できる。これは、大きな処理に対して要求される処理資源が一般に不足する携帯メディアプレーヤに対するそれらのタスクをクライアントが実行するために多用されてもよい。別の例において、サーバがプレイリストの生成の際に使用されたいくつかの制約を実行し且つ結果を類似性テーブルデータに取り入れることは利点である。例えば緩和されることがないジャンルの制約の場合、サーバはアイテムの類似性データから互換性のないジャンルのメディアアイテムを除外してもよい。このように、サーバが制約を満たさないアイテムを個別の類似性テーブルから既に除外しているため、プレイリストモジュールはプレイリストを生成する時に制約を実行する必要はない。

図２２は、メディア及び類似性テーブルをデジタルメディアプレーヤに同期させるシステムの一例を示す。通信媒体９２０は、インターネットである可能性がもっとも高いが、デバイスが互いに通信できるようにするいかなるチャネルも含むことができる。オンラインストア９２２は、オンラインストアと通信及び対話するためにインストールされた特別なソフトウェアを使用して一般にパーソナルコンピュータであるクライアント９２４と通信する。Appleの（公序良俗違反につき、不掲載）メディアプレーヤ等の携帯メディアプレーヤ９２６は、一般に３０ピンＵＳＢコネクタを介して、オンラインストア９２２に接続されたパーソナルコンピュータ９２４と同期する。携帯メディアプレーヤ９２６をパーソナルコンピュータ９２４と接続する他の方法は、ＵＳＢ、Ｆｉｒｅｗｉｒｅ、８０２．１１シリーズ又はＢｌｕｅｔｏｏｔｈ無線接続を含む。オンラインストアは、メディア９３０のマスタライブラリ、マスタ類似性テーブル９３２及びサーバクラスタ９３１の木を有する。携帯メディアプレーヤ９２６が同期されると、ローカルメディア９３４のメタデータ、ローカルの部分集合類似性テーブル９３６及び参加者サーバクラスタ９３５はパーソナルコンピュータ９２４及び通信媒体９２０を介してオンラインストア９２２に送信される。尚、メタデータのみが送信され、実際のメディアが送信されないことが重要である。オンラインストアは、メディアのコピーを必要とせず、携帯メディアプレーヤ９２６に配置されるメディアを明確に識別するのに十分な情報のみを必要とする。オンラインストアは、適切な情報を生成及び／又は検索し、その情報をデバイスに送出し返すことができ、それにより、ローカルに格納されたメディア９３４に対応する新しいデータによりローカルの部分集合類似性テーブル９３６及び参加者クラスタ９３５を更新する。ローカルの部分集合類似性テーブルは、オンラインストアレベル、コンピュータレベル及び／又はデバイス自体において個々のプレイリストを生成するために使用される。

別の実施形態において、携帯メディアプレーヤ９２６はサーバ９２２からデータを直接取得できる。そのような一実施形態において、携帯メディアプレーヤは、８０２．１１シリーズの通信（Ｗｉ−Ｆｉ）又は移動電話網等を介してオンラインストアに接続するための種々の機能を備えることができる。携帯メディアプレーヤは、サーバに直接接続でき、クライアントデバイスが上記例で実行するように実行できる。携帯メディアは、一意の識別番号を割り当てられ、あるいはライブラリがクライアントデバイスと関連付けられる場合は携帯メディアプレーヤはクライアントデバイスと同一の識別番号を使用できる。しかし、携帯メディアプレーヤは、ライブラリに格納されたメディアアイテムに関する情報をアップロードし且つ同一のアイテムに関する類似性データをダウンロードできる。携帯メディアプレーヤは、サーバに接続する方法を２つ以上有することができることが理解されるべきである。携帯メディアプレーヤは、オンラインストアに接続する機構を複数有することができるだけでなく、クライアントデバイスと同期し且つオンラインストアと直接通信する機能も有することができる。

本発明の範囲内の実施形態は、コンピュータ実行可能命令又はデータ構造を保持するか又は格納するコンピュータ可読媒体を更に含んでもよい。そのようなコンピュータ可読媒体は、汎用コンピュータ又は専用コンピュータによりアクセスされる利用可能などんな媒体であってもよい。例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光ディスク記憶装置、磁気ディスク記憶装置又は他の磁気記憶装置、あるいはコンピュータ実行可能命令又はデータ構造の形式で所望のプログラムコード手段を保持又は格納するために使用可能な他のいかなる媒体も含むことができるが、これらに限定されない。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。

例えばコンピュータ実行可能命令は、汎用コンピュータ、専用コンピュータ又は専用処理装置に特定の機能又は機能群を実行させる命令及びデータを含む。コンピュータ実行可能命令は、スタンドアロン又はネットワーク環境でコンピュータにより実行されるプログラムモジュールを更に含む。一般にプログラムモジュールは、特定のタスクを実行するか又は特定の抽象データタイプを実現するルーチン、プログラム、オブジェクト、構成要素及びデータ構造を含む。コンピュータ実行可能命令、関連するデータ構造及びプログラムモジュールは、本明細書で開示された方法のステップを実行するためのプログラムコード手段の例である。そのような実行可能命令又は関連するデータ構造の特定のシーケンスは、そのようなステップで説明された機能を実現するための対応する動作の例である。

本発明の他の実施形態は、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサを使用する消費者電子機器、プログラマブル消費者電子機器、ネットワークＰＣ、ミニコンピュータ及びメインフレームコンピュータ等を含む多くの種類のコンピュータシステム構成を有するネットワークコンピューティング環境で実現されてもよいことが当業者には理解されるだろう。実施形態は、通信ネットワークを介してリンクされる（ハードワイヤードリンク、無線リンク又はそれらの組合せにより）ローカル処理装置及びリモート処理装置によりタスクが実行される分散コンピューティング環境で実現されてもよい。分散コンピューティング環境において、プログラムモジュールは、ローカルメモリ記憶装置及びリモートメモリ記憶装置の双方に配置されてもよい。

説明したシステムの種々の段階における通信は、ローカルエリアネットワーク、トークンリングネットワーク、インターネット、企業イントラネット、８０２．１１シリーズ無線信号、光ファイバネットワーク、無線又はマイクロ波伝送等のネットワーククラウド３２８（図１６に示す）を介して実行される。基礎となる通信技術が変更されてもよいが、本明細書で説明した基本的な原理は依然として適用可能である。

上述した種々の実施形態は、例として提供され、本発明を限定するものとして解釈されるべきではない。例えば本明細書の原理は、携帯メディア再生デバイス又はネットワークに物理的に接続されたパーソナルコンピュータにより無線でアクセスできるオンラインストアに適用されてもよい。本明細書で図示して説明した実施形態及び応用例に従わず且つ本発明の趣旨の範囲から逸脱せずに本発明に対して行われてもよい種々の変形及び変更は、当業者には容易に理解されるだろう。

Claims (17)

1. １つ以上のプロセッサと、
   メモリと、
   前記メモリに格納され且つ前記１つ以上のプロセッサにより実行されるように構成される１つ以上のプログラムとを備え、前記１つ以上のプログラムは、
   プログラム参加者のメディアアイテムの集合の個々のメディアアイテムを記述する情報を受信することと、
   前記プログラム参加者のメディアアイテムの集合内に含まれるメディアアイテムのクラスタを記述するデータをコンパイルすることと、ここで前記クラスタは、サーバが認識しているメディアアイテムの階層的に関連したクラスタにおいて見つけられるトラックの凝集に基づいてコンパイルされ、一覧表内のメディアアイテムの前記クラスタはプログラム参加者の母集団から導出された類似性データのクラスタ解析に基づいて決定され、
   前記サーバから受信した前記プログラム参加者のメディアアイテムの集合内に含まれる前記メディアアイテムのクラスタのうちの１つから選択されたメディアアイテムを含むメディアアイテムのミックスを判定することと、
   プログラム参加者のクライアントデバイスに前記メディアアイテムのミックスを提供することとを含む演算装置。
2. 更に、前記サーバが認識している前記メディアアイテムのクラスタは、前記サーバが認識しているメディアアイテムの集合を潜在的に類似するメディアアイテムのグループを含むキャノピーに分割することにより決定される請求項１に記載の装置。
3. 更に、前記サーバが認識している前記メディアアイテムのクラスタは、各キャノピーの前記メディアアイテムを再帰的に細分することにより決定される請求項２に記載の装置。
4. 各再帰が、前記プログラム参加者の母集団から導出された類似性データのクラスタ解析に基づいて各サーバクラスタの他のアイテムに類似すると判定されたメディアアイテムの、重なり合わない、より精錬されたサーバクラスタを生成する請求項３に記載の装置。
5. 最新の再帰により生成された前記サーバクラスタの各々が定められた数を超えないメディアアイテムを含み、その結果複数の最下位レベルのサーバクラスタが得られたとの判定に応答して、前記再帰的な細分を終了する請求項３に記載の装置。
6. 前記メディアアイテムのミックスは、前記クラスタのうちの１つから選択された曲及び前記クラスタのうちの１つから選択された前記曲に類似する曲から生成されたプレイリストを含む請求項１に記載の装置。
7. 前記メディアアイテムのミックスを含む前記曲は、前記曲の各々と前記１つのクラスタとの間の類似性に基づいて選択される請求項１に記載の装置。
8. 前記プログラム参加者の母集団から導出された前記類似性データはベクトル空間を含み、前記ベクトル空間内の各ベクトルはメディアアイテム及び前記メディアアイテムに類似する全てのメディアアイテムを表す請求項１に記載の装置。
9. 類似するメディアアイテムをプログラム参加者のメディアライブラリにクラスタリングするシステムであって、
   サーバメディアアイテムの集合を関連するメディアアイテムのサーバクラスタに再帰的に細分する第１のサーバと、
   前記プログラム参加者のメディアライブラリ及び１つ以上の最下位レベルのサーバクラスタの双方に同時発生するメディアアイテムの集合を判定することと、より大きい各参加者クラスタが少なくとも定められた最少数のメディアアイテムを含むようになるまで前記プログラム参加者のメディアライブラリ及び親サーバクラスタの双方に共存するメディアアイテムを前記参加者クラスタに追加することによってより大きい参加者クラスタに再帰的に凝集することとを有する方法を実行することにより、前記サーバクラスタに基づいて特定のプログラム参加者のメディアライブラリに存在するアイテムから当該プログラム参加者に対する１つ以上のメディアアイテムクラスタを作成する第２のサーバと、
   前記参加者クラスタのうちの１つにおいて表されるメディアアイテムの選択に基づいて、類似するメディアアイテムの、再生のためのミックスを生成するように構成されたメディア再生デバイスとを備えたシステム。
10. 前記サーバは１つのサーバアレイの一部を構成する請求項９に記載のシステム。
11. 前記プログラム参加者の母集団から導出された前記類似性データはベクトル空間を含み、前記ベクトル空間内の各ベクトルは各プログラム参加者のメディアライブラリにおける個別のメディアアイテムの発生を表す請求項９に記載のシステム。
12. 前記プログラム参加者の母集団から導出された前記類似性データは、プログラム参加者のメディアライブラリのうち個別のメディアアイテムの同時発生の発生率を表す類似性マトリクスを含む請求項９に記載のシステム。
13. 前記第１のサーバは、まず、前記サーバメディアアイテムの集合を潜在的に類似するメディアアイテムのグループを含むキャノピーに分割し、その後、各キャノピーの前記サーバメディアアイテムを分割することにより前記サーバメディアアイテムの集合を再帰的に細分するように更に構成される請求項９に記載のシステム。
14. 前記第１のサーバにおける再帰的な細分の各々により、前記サーバメディアアイテムの集合内の各アイテムを前記サーバメディアアイテムの集合内の他の全てのアイテムと関連付ける類似性データのクラスタ解析に基づいて、各サーバクラスタの他のアイテムに類似すると判定されたメディアアイテムに重なり合わない、より精錬されたサーバクラスタが生成される請求項９に記載のシステム。
15. 最新の再帰的な細分により生成された前記サーバクラスタの各々が、定められた数を超えないメディアアイテムを含むと判定されることに応答して、前記第１のサーバにおける前記再帰的な細分を終了する請求項９に記載のシステム。
16. 前記メディアアイテムのミックスは、前記クラスタのうちの１つから選択された曲及び前記クラスタのうちの１つから選択された前記曲に類似する曲から生成されたプレイリストを含む請求項９に記載のシステム。
17. 前記メディアアイテムのミックスを含む前記曲は、前記曲の各々と前記１つのクラスタとの間の類似性に基づいて選択される請求項１６に記載のシステム。
    
    

Images