JP5161794B2 - 動的インタラクティブエンターテイメントベニュー - Google Patents

Description

本願は、2006年2月10日出願の「System and Method for Building and Sharing a Composite Playlist from Collective Group Tastes on Multiple Media Playback Devices」と題する米国暫定特許出願No. 60/772,502に基づく優先権を主張する。本願は、2006年2月15日出願の「Mediaset Recommendations for a Group of Users」と題する米国暫定特許出願No. 60/774,072に基づく優先権も主張する。本願は、2006年5月1日出願の「Dynamically Building Composite Playlist for Merging Collective User Tastes」と題する米国暫定特許出願No. 60/796,724に基づく優先権も主張する。優先権は、1883年3月20日の工業所有権の保護に関するパリ条約（改正および修正を含む）に従って主張される。

以下の説明では、本発明による特定の好適な実施例を十分に理解するために、プログラミング、ソフトウェアモジュール、ユーザによる選択、ネットワークトランザクション、データベースの照会、データベース構造などに関して具体的に詳細な説明を行う。しかし、当該技術に熟練した人々は、これらの1つ以上の詳細情報なしに、またはその他の方法、コンポーネント、材料などを用いて、実施例を実践できることを認識するであろう。

場合によっては、好適な実施例の諸局面が不明確にならないように、周知の構造、材料、または動作の詳細な表示または説明は行わない。さらに、説明される特徴、構造、または特性は、様々な他の実施例においていずれの適切な方法によっても組み合わせることができる。一部の実施例においては、ここに説明される方法論およびシステムは、1つ以上のデジタルプロセッサを使用して実行される。デジタルプロセッサとしては、PC、ラップトップ、PDAおよびあらゆる種類のその他のデスクトップまたはポータブル電子機器などに一般に見られるタイプのマイクロプロセッサなどがある。

複数のメディアデータアイテムを含むメディアセットを生成するためのシステム、方法、および装置の実施例を開示する。ここで使用されているように、「メディアデータアイテム（media data item）」という用語は、任意のメディアアイテム、またはメディアアイテムの表現を含むように意図されている。「メディアアイテム」は、曲、映画、ピクチャ、電子ブック、ゲームなど、デジタルメディアフォーマットで表すことができる任意のタイプのメディアファイルを含むように意図されている。このように、「メディアデータアイテム」という用語は、再生可能なメディアファイルを特定するメタデータ（例えば、MP3ファイルを特定するメタデータ）を含むだけでなく、例えば、再生可能なメディアアイテムファイル（例えば、MP3ファイル）を含むように意図されている。したがって、明白であるべきことは、「メディアアイテム」を使用するプロセス、ステップ、またはシステムを提供する任意の実施例において、そのプロセス、ステップ、またはシステムは、代わりにメディアアイテムの表現（例えば、メタデータ）を使用することである。その逆もまた同様である。

1つの実施例においては、所定のユーザグループに対してメディアセットの推奨を行うシステムが提供される。そのようなシステムの実施例は、ユーザのコミュニティにおける各メンバのプレイリストおよび/またはプレイカウントを格納する機構を有する。プレイリストおよびプレイカウントを使用して、各ユーザの嗜好が定義される。したがって、プレイリストおよびプレイカウントは、ユーザ毎の嗜好分析の実行に使用される。

上述した一般的原理によると、本発明の実施例は、メディアセットまたはグループプレイリストをコミュニティまたはネットワーク内のユーザのグループに推奨する問題に対処するために使用される。一部の実施例においては、入力がメディアアイテムのセットであるとともに、出力が加重メディアアイテムのメディアセットである場合に、メディアセットリコメンダが提供される。メディアセットのグループ推奨を提供する2つの具体的方法は、1）全体としてユーザのグループの嗜好を表す共通のプロファイルを作成して、リコメンダにそのプロファイルを適用することと、2)メンバ嗜好ごとに個別の推奨を考慮して、結果を集約することを含む。

メディアプレーヤーは、一般にすべてのタイプのメディアアイテムを再生して、プレイカウントおよびプレイリストを収集することができる。プレイカウントは、メディアプレーヤーでメディアアイテムが再生された回数である。プレイリストは、ユーザがメディアアイテムのライブラリの編成用に作成したメディアアイテムのグループである。システム（例えば、サーバ）を使用して、ユーザのコミュニティにおけるメディアアイテムのプレイカウントおよびプレイリストを収集する。

ユーザのプレイカウントおよびプレイリストを使用して、そのユーザの嗜好を合成するか、または嗜好分析を実行する。その意味で、ユーザの嗜好は、そのユーザのプレイカウントおよびプレイリストを考慮した、最も関連性の高い嗜好データを集めたものであると考えられる。

本システムの特定の実施例では、メディアセットをユーザのグループに推奨する仕事が課されている。ユーザのグループに対するメディアセットの推奨は、グループの各ユーザに推奨される、異なるメディアセットの集約プロセスの結果である。このように、本システムの一部の実施例は、（例えば、各ユーザの嗜好の分析を実行することによって）別のメディアセットからのメディアセットを推奨するコンポーネントを含む。集約プロセスは、例えば、投票スキーマおよび/または最適化スキーマを適用する。

ユーザのグループに対するメディアセット推奨は、様々なシナリオで役立つ。一例としては、人々のグループが音楽を一緒に楽しみたい場合のパーティである。グループ内の特定の個人に推奨される音楽を再生する代わりに、そのグループ全体として推奨される音楽を再生することが望ましい場合がある。

このような事情により、ある特定の実施例では、システムに課された仕事は、ユーザのグループに推奨されるメディアセットまたはプレイリストを見つけることである。システムがユーザからプレイカウントおよび/またはプレイリストを収集する実施例では、そのようなリコメンダシステムは、次の3つの主要ステップから成る。
1) ユーザの嗜好を合成するステップ
2) ユーザの嗜好ごとに推奨されるメディアセットを作成するステップ
3) 推奨メディアセットのセットを、すべてのユーザのグループに推奨される単一のメディアセットに集約するステップ

これらのステップの内容、適用範囲、および順序については、様々な変形が考えられることを理解する必要がある。例えば、ユーザの嗜好ごとに推奨されるメディアセットを作成するステップは、任意であってもよい。

以下の図面は、本発明の特定の好適な実施例のみを示すものであり、したがって本発明の適用範囲を限定することを意図するものではないことを理解した上で、好適な実施例は、添付図面を用いることによって、以下のようにさらに具体的にかつ詳細に解説、説明される。

図1は、ユーザ100の嗜好108が、そのユーザ100のプレイカウント104およびプレイリスト102から、「嗜好合成（Synthesize Taste）」と呼ばれるプロセス106によってどのように作成されるかを示す図である。当該プロセス106は、嗜好分析の一例であることを理解する必要がある。プロセス106は、嗜好108を作成する。嗜好108は、メディアセットとして符号化される。プロセス106の一部として、より大きなプレイカウントを有するメディアアイテム、および/またはプレイリスト内でより多いと思われるメディアアイテムが選択される。選択されたメディアアイテムは、ユーザによってより頻繁に再生されたメディアアイテム、および/またはさらに異なる背景および状況において使用されるメディアアイテムを含む（その理由は、これらのメディアアイテムは多くの異なるプレイリストに現れるからである）。一部の実施例においては、プレイカウントは再生日付と対応している。そのような場合、当該プロセスは、再生日付によってプレイカウントを比較検討する。したがって、最近のプレイカウントには、以前のプレイカウントに対するよりも多くの関連性が付与される。

プロセス106は、ユーザのメディアアイテムのランク付けプロセスを含む。ここで、より大きなプレイカウントを有し、再生がより最近で、および/またはより多くプレイリストに出現するアイテムが、より上位にランク付けされる。当該プロセスは、ユーザの嗜好108の符号化として、トップmにランク付けされたメディアアイテムを選択する。このプロセスは、時間とともに同じユーザに対して異なる結果を生むことに留意する必要がある。これは、時間の経過とともに進展するユーザの嗜好を符号化することを目標とする、これらの実施例における望ましい特性である。

一部の実施例においては、本システムは、個別のメディアセット推奨を提供する。例えば、図2を参照すると、n人のユーザ200、208、および216のグループが示されているが、本システムは、例えば上記のプロセスによって、ユーザごとに個別の嗜好を計算する（それぞれ嗜好202、210、および218）。本システムは、リコメンダエンジン（それぞれ204、212、および220）を使用して、各ユーザに対応した推奨されたメディアセットを提供する。これらのリコメンダエンジンは、ユーザ嗜好（メディアセット202、210、および218）を処理して、推奨されたメディアセット206、214、および222をそれぞれ作成する。ここで理解すべきことは、図2に示されるように、個別の推奨されたエンジンはユーザごとに使用される（リコメンダエンジン204、212、および220）ことであり、または別の方法として、単一のリコメンダエンジンがグループ全体に対して使用される場合もあることである。このようにして、図示されたシステムが全体でm個のメディアアイテムから成るn個のメディアセットを計算する。

一部の実施例においては、本システムでは、個別の推奨されたメディアセットを、グループに推奨されたメディアセットまたはグループプレイリストに集約することも行う。例えば、図3を参照すると、本システムがm個のメディアアイテムから成るn個のメディアセットを計算したら（グループの各ユーザ300、304、308ごとに1つ）、集約ステップを使用して、 ユーザのグループに推奨されるp（p ≦ n*m）個のメディアアイテム314から成る最終的なメディアセットを作成する。図3に示されるように、本システムはアグリゲータ312を提供する。アグリゲータ312は、グループ内の各ユーザから推奨されたメディアセット（それぞれ302、306、および310）を入力として取り入れ、そこからグループ推奨メディアセット314を提供する。

集約ステップは、例えば、異なる目標を満足させる異なるアプローチに従うことによって実行される。すでに説明したように、2つの好適な実施例においては、本システムは、a)投票スキーマまたはb）最適化スキーマに従う。投票スキーマは、大多数のユーザが、グループの残りのメンバーによる嫌いの度合いを考慮せずに満足するであろうメディアセットを見つける目標を満足させる。それに対して、最適化スキーマは、グループのすべてのメンバーの嫌いの度合いを最小限に抑える（または、好きの度合いを最大限に高める）メディアセットを作成する。最適化スキーマを適用するには、n個の推奨されるメディアセット302、306、310に含まれるメディアアイテムを、それぞれ関連付けられた重みとリンクさせる。ユーザに対するメディアセットのメディアアイテムの重みを用いて、そのユーザに対するメディアアイテムの関連性を示す。

投票スキーマを使用して、集約プロセスは、n個のメディアセットの中で最も頻繁に出現するp個のメディアアイテムを取り出す。n個のメディアセットの中で出現回数が同じアイテムがある場合（タイブレーク）、それらのアイテムをランダムに選択する。

一部のリコメンダエンジンは、加重メディアアイテムを含むメディアセットを作成する。そのような実施例では、タイブレークの状況が発生したとき、当該プロセスは、アイテムをランダムに選択する代わりに、最も高い重みを有するメディアアイテムを選択する。例えば、以下のメディアセットについて考察すると、
ms1 = {s3,s7,s8,s10}
ms2 = {s2,s3,s4,s10}
ms3 = {s3,s4,s7}
上記の投票スキーマに従って、メディアセット（ms#）に含まれるメディアアイテム（s#）は、以下の通りにランク付けされる。
s1=0, s2=1, s3=3, s4=2, s5=0, s6=0, s7=2, s8= 1, s9=0, s10= 2

このように、推奨されたグループメディアセットに対するメディアアイテムが選択される順序は、s3、s4, s7, s10, s2, s8である。メディアアイテムs7およびs10はタイブレーク状況にあるため、これらのメディアアイテムは、もしあればそれらのメディアセット内のそれぞれの重みにしたがって順序付けされる。関連付けられた重みがこれらのメディアアイテムに付与されていない場合、メディアアイテムs7およびs10の順序はランダム化される。メディアアイテムs2およびs8についても同様である。

集約スキーマを使用して、集約プロセスは、グループのすべてのユーザを考慮した（すなわち、n個のすべてのメディアセット302、306、310を考慮した）何らかの効用関数を最適化するp個のメディアアイテムを取り出す。最適化スキーマを適用するには、n個のメディアセット302、306、310に含まれるメディアアイテムは、関連付けられた重みを、例えば、0から1までの範囲で有する。ここで、0はそのアイテムはまったく関連性がないことを意味し、1はそのアイテムが最も関連性が高いことを意味する。したがって、所定のメディアセットjに対して、メディアアイテムiは重みw（j, i）を有する。メディアアイテムiがメディアセットjに含まれていない場合、メディアアイテムiは重み0を有すると考えられる。以下の例は、メディアセットの集まりに対してメディアアイテムと関連付けられた重みを示す。
ms1 = {s3,s7,s8,s10}
ms2 = {s2,s3,s4,s7,s10}
ms3 = {s3,s4,s7}
w(1) = [0, 0, 0.1, 0, 0, 0, 0.3, 0.2, 0, 0.9]
w(2) = [0, 0.2, 0.5, 0.4, 0, 0, 0.3, 0, 0, 0.9]
w(3) = [0, 0, 0.1, 0.8, 0, 0, 0.3, 0, 0, 0.5]

メディアアイテムを集約するには、いくつかの異なる効用関数を選択する。例えば、効用関数を選択して、n個のメディアセットのいずれかに含まれる最高の重みを有するp個の選択アイテムのすべてに対する合計を最大にする。この効用関数に従ってp=3のアイテムを選択することが望ましい場合、s10、s4、およびs3が選択される。これらのアイテムに対する最高の重みの合計は、0.9 + 0.8 + 0.5 = 2.2である。この値は、上記の例で得ることができる最大値である。

別の方法として、効用関数を選択して、n個のメディアセットのいずれかに含まれる最低の重みを有するp個の選択アイテムのすべてに対する合計を最大にする。この効用関数に従ってp=3のアイテムを選択することが望ましい場合、s10、s7、およびs3が選択される。これらのアイテムに対する最低の重みの合計は、0.5 + 0.3 + 0.1 = 0.9である。この値は、上記の例で得ることができる最大値である。

さらに別の方法として、効用関数を選択して、n個のメディアセットのすべての平均重みを有するp個の選択アイテムのすべてに対する合計を最大にする。この効用関数に従ってp=3のアイテムを選択することが望ましい場合、s10、s4、およびs7が選択される。これらのアイテムに対する平均重みの合計は、2.3/3 + 1.2/3 + 0.9/3 = 1.16である。この値は、上記の例で得ることができる最大値である。当然、当業者にとって明らかであるように、その他の効用関数を使用してもよい。

リコメンダエンジンは、一部の実施例で提供される。リコメンダエンジンを含まない実施例では、ユーザ嗜好を符号化するメディアセットは直接集約されて、ユーザのグループ全体に推奨されるメディアセットを形成する。

リコメンダエンジンを使用するシステムは、新しい音楽を発見するためのメディアセットを提案する。それに対して、リコメンダエンジンを設けないシステムは、グループ内のユーザの少なくとも１人にすでに知られたメディアアイテムを含むメディアセットを提案する。

明白なことであるが、前記のシステムおよび方法では、n人のユーザのグループに対するメディアセット推奨を作成して、ユーザのグループによって同時に楽しむことができるメディアセットの提案を可能にしている。本システムでは、プレイリストおよび/またはプレイカウントからユーザ嗜好を分析することによって、ユーザ嗜好をメディアセットとして表すことができる。これらのn個のユーザ嗜好は、別のn個のメディアセットを提案するリコメンダエンジンの入力にすることができる。これらのメディアセットを取り出して単一のグループメディアセットを作成する集約プロセスを提供してもよい。そのようなプロセスは、例えば、投票スキーマまたは最適化スキーマを使用して実行することができる。同様のシステムが、リコメンダエンジンなしで動作する場合もある。そのような実施例では、集約プロセスは、n人のユーザの嗜好を代表するメディアセットで動作する。その結果は、ユーザのグループ全体に推奨することができるメディアセットを含む。

図4から図14を参照して、追加の実施例の開示および説明を行う。これらの実施例の一部においては、共通のロケーションにおいておよび/または通信ネットワークを通じて、複数のメディアデバイス上の個別のライブラリに含まれるメディアアイテムから、コンポジットプレイリストがつくられる。グループ内のメディアデバイスは、携帯型および/または非携帯型デバイスを含む。コンポジットプレイリストを再生する手段は、プレイリストを順番に実行する。これによって、示されたメディアアイテムを含むメディアプレーヤーは、可能であれば1つ以上の他のプレーヤーにそのメディアアイテムを流す。そのような実施例では、例えば、クライアントサーバアーキテクチャまたはP2P分散アーキテクチャに基づいて動作が行われる。したがって、これらの実施例では、一組のメディアプレーヤーを連携させることによって、所定のグループプレイリスト上のメディアアイテムを、個別のメディアプレーヤーの各々に、またはメディアプレーヤーの所定のサブセットに、グループプレイリストにリストされている順番でストリーミングの方法で送信する。これは、メディアアイテムの単独型コピーを種々のメディアプレーヤー間で転送することなく達成することができる。

当該技術に熟練した人々は、上記の1つ以上の実施例の特徴を取り入れたシステムは、7レベルISO開放型システム間相互接続参照モデルにおける階層プロトコルの集まりとして、または標準的なネットワークプロトコルを使用して通信するメディアデバイス内のアプリケーションタスクとして、開示された機能的挙動をその設計が具体化するメディアデバイスの集まりとして理解されることを認識する。

一部の好適な実装例は、3つの主要なコンポーネントを含む。第1のコンポーネントは、複数のセッションマネージャ（Session Manager）である。セッションマネージャは、「セッション」と呼ばれる共同作業の期間に稼動している複数の他のメディアプレーヤーデバイスに関して、各メディアプレーヤーのステータスを指定して管理するのに必要な情報を集合的に調整する。好適な実装例においては、1つのセッションマネージャは各メディアプレーヤーデバイスと対応している。ただし、すべての実装例でそれが必要であるとは限らない。セッションマネージャは、各デバイスの有資格を検証してセッションに参加する手段を含む。これは、サービスに加入している有資格のユーザによって達成される。このサービスは、集合的に楽しむメディアアイテムに対する正当なアクセスを提供するものである。

前記の実装例の第2のコンポーネントは、プレイリストビルダ（Playlist Builder）である。プレイリストビルダは、例えば、複数のメディアプレーヤーの1つ、サーバ、本システムに含まれるネットワークアクセスコントローラ、または、通信ネットワークを通じてメディアプレーヤーデバイスにアクセス可能なサードパーティのサーバに常駐する。プレイリストビルダは、グループ内のユーザについて利用可能な嗜好データ、およびメディアプレーヤーにとって利用可能なメディアアイテムの集合体などの情報を使用して、グループの集合的な嗜好と互換性を持つグループプレイリストを作成する。

前記の実装例の第3のコンポーネントは、複数のプレイリストマネージャ（Playlist Manager）であり、それぞれ各メディアプレーヤーデバイスと対応している。プレイリストマネージャは、プレイリストビルダと集合的に通信を行い、グループプレイリストの作成に必要な情報、およびグループプレイリストに基づいてメディアアイテムを再生するのに必要な情報を提供する。各メディアプレーヤーデバイスと対応するプレイリストマネージャは、ローカルライブラリ内の、または、例えば、メディアプレーヤーによってアクセス可能なメディアストリーミングサービスからの、メディアプレーヤーデバイス上におけるメディアアイテムの利用可能性を伝達する機能を含む。プレイリストマネージャは、プレイリストプレイ（Playlist Play）サブコンポーネントを含む場合もある。プレイリストプレイサブコンポーネントは、セッション内の他のメディアプレーヤー上の対応するサブコンポーネントと連携して動作することによって、グループプレイリスト上の各アイテムを順次実行する。また、プレイリストプレイサブコンポーネントは、各メディアアイテムに遭遇したときに、メディアアイテムと対応するメディアプレーヤーがそのメディアアイテムを1つ以上の他のプレーヤーに流すように構成されている。

ここで、再び図面を参照して、特定の実施例のさらなる局面をより詳細に説明する。図4および図5に、そのような他の実施例を2つ示す。図4は、クライアントサーバ型実施例400のシステム図である。図5は、ピアツーピア型実施例500のシステム図である。本発明の両方の実施例は、同じ必須コンポーネントを含む。しかし、ここでは、図4のクライアントサーバ型実施例400を、ピアツーピア型実施例よりもより詳細に説明する。それにもかかわらず、ここで行われる開示は、図示するように、システムの特有の機構的相違を有するピアツーピアシステムに等しく適用することを理解する必要がある。

クライアントサーバ型実施例400の主要なコンポーネントは、サーバ機能ユニット402、および1つ以上のメディアプレーヤーデバイス（Media Player Device）クライアント404である。このサーバ402は、次の3つの基本機能コンポーネントを含む。
1）セッションアクセスコントローラ（Session Access Controller）408（用途：個々のメディアプレーヤーを使用する許可を与えて、デバイス間の連携的な相互のやりとりに参加させる）、
2）プレイリストビルダ（Playlist Builder）410（用途：セッション中にグループプレイリスト内の再生すべきメディアアイテムのリストとシーケンスを作成する）、および
3）セッション内の各メディアプレーヤーデバイス404に対して使用されるデバイスマネージャ（Device Manager）406（用途：デバイスのセッション関連機能を制御する）。

図5に示されるように、ピアツーピア型実施例500も複数のメディアプレーヤーデバイス504を含む。これらのメディアプレーヤーデバイス504は、それぞれデバイスマネージャ506を含む。また、ネットワークアクセスコントローラ502も提供される。ネットワークアクセスコントローラ502は、セッションアクセスコントローラ508と、複数のメディアデバイスからメディアアイテムデータを受信して、そのメディアアイテムデータからメディアデータアイテムのコンポジットプレイリストを作成するプレイリストビルダ510とを含む。

各メディアプレーヤーデバイスに使用されるデバイスマネージャは、セッションマネージャと、プレイリストマネージャとを含む。例えば、図6は、セッションマネージャ604と、プレイリストマネージャ606とを含むデバイスマネージャ602を示す。セッションマネージャ602は、対応するメディアデバイスのステータスを管理するように構成される。

図7は、セッションマネージャの一実施例と関連付けられたメンバーステータス（Member Status）スクリーン702を示す。図7に示されるように、セッションマネージャは、ID、プロキシ、ステータス、および期間情報など、セッション内のメディアプレーヤーごとに情報の一連のカテゴリを追跡する。

プレイリストマネージャ606は、プレイリストビルダと通信して対応するメディアデバイスのメディアアイテムデータをプレイリストビルダに送信することによって、対応するメディアデバイス上でコンポジットプレイリスト内のメディアデータアイテムを再生するように構成されている。

サーバクライアント構成の図4およびピアツーピア構成の図5に示すように、各メディアプレーヤーデバイス404は、図6に示すデバイスマネージャ602の対応するインスタンスを有する。さらに、サーバ402およびネットワークアクセスコントローラ502は、セッションアクセスコントローラ408、508およびプレイリストビルダ410、510の単一インスタンスを含む。

後により詳細に説明するが、セッションアクセスコントローラ408、508は、システム内の各メディアデバイス404のデバイスマネージャ602に含まれるセッションマネージャ604と相互にやりとりすることによって、セッションを含む一組のメディアデバイスを定義して、それらのメディアデバイス間の通信を可能にする。同様に、プレイリストビルダ410、510は、デバイスマネージャ602に含まれるプレイリストマネージャ606で動作することによって、セッション内の一連のメディアアイテムを定義して実行する。

図8は、デバイスマネージャ602に含まれるセッションマネージャ604の一実施例によるトップレベルのフロー図である。個別のメディアプレーヤーデバイスのセションマネージャは、メディア再生セッション（以下「セッション（session）」と呼ぶ）内のデバイスの導入、動作、離脱をネゴシエートするのに使用される。これは、セッション内の他のすべてのメディアプレーヤーデバイスに関する知識を維持することを含む。

セッションマネージャ604は、クライアントサーバ構成を有するサーバシステム402上で、またはピアツーピア構成を有する、特権を付与されたピアツーピアネットワークアクセスシステム502上で、単一のセッションアクセスコントローラ408が存在していると仮定する。ピアツーピア型実施例では、ネットワークアクセスシステムは、ネットワークレベル機能のホストとして動作する、一部のピアツーピアネットワークに見られるシステム上に実装することができる。一方、その他の実施例では、ネットワークアクセスシステムは、ネットワーク内の1つのピアシステム上に実装することができる。

一部の実施例におけるセッションアクセスコントローラの主要機能は、デバイスにインディケーション許可が与えられたとき、セッションに入る許可を求めているデバイスからの「request-to-enter」セッションメッセージに応じて、セッションsIDコードを提供することである。一部の実施例においては、「request-to-enter」メッセージを受け取ったデバイスからのメディアプレーヤーmIDコードが、セッションに入る許可に対して適格であるmIDと認識された場合、その許可が与えられる。その他の実施例では、セッションアクセスコントローラは、代わりに動的なmIDを要求側のメディアプレーヤーデバイスに返して、返されたセッションsIDコードと一緒にセッションとの関連においてデバイスの一意識別子としての役割を果たすようにする。一部の実施例においては、セッションアクセスコントローラは、主として、メディアプレーヤーデバイスをリンクする基礎をなす通信ネットワーク用のネットワークプロトコルにおいて機能的である。また、mIDおよびsIDは、デバイスおよびコミュニケーションセッションまたはトランザクションを特定するネットワークプロトコル内のパラメータに由来するコードである。

図8に示すように、セッションマネージャは、2つの主要なサブファンクション802、806を含む。サブファンクション802は、メディアプレーヤーがセッションに入る許可をメディエートする。一方、サブファンクション806は、メディアプレーヤーが、通信ネットワークリンクを通じてセッション内の他のメディアプレーヤーの認識を維持するプロセスを実装する。

図8に示すセッションマネージャのフロー図の開始ステップは、メディアプレーヤーがセッションに参加していないと仮定する。サブファンクション802に示されるように、セッションマネージャは、任意の「mID」コードを有する「request-to-enter」メッセージを一斉送信する。メディアデバイスが、セッションに対するアクセスをメディアプレーヤーに許可するセッションアクセスコントローラと正常に通信する場合、メディアプレーヤーは、sIDコードによって特定されるセッションに入る許可がメディアプレーヤーに与えられたことを示す「enter session-sID」メッセージを受信する。1つのセッションのみを有する実施例においては、sIDコードは余分であり、sIDコードは省略されるか、またはデフォルト値が返される。

「enter-session-sID」応答メッセージが受信されない場合、セッションマネージャは、ランダムな長さの時間待ってから、別の「request-to-enter」メッセージを送信する。一部の実施例においては、「enter-session-sID」応答が受信されない場合、セッションマネージャは、「request-to-enter」メッセージを送信した後にランダムな長さの時間待ってから、別の「request-to-enter」メッセージを送信する。その他の実施例では、セッションマネージャは、「request-to-enter」メッセージを送信した後に固定長の時間待つ。そして、「enter-session-sID」応答が受信されない場合、ランダムな長さの時間待ってから、次の「request-to-enter」を送信する。さらにその他の実施例では、セッションマネージャは、「enter-session-sID」を受信するというよりも、「request-to-enter」メッセージを送信した後に何らかの外部イベントが発生するまで待つ。その後、ランダムな長さの時間待ってから、次の「request-to-enter」を送信する。

セッションアクセスコントローラから「enter-session-sID」応答を受け取りしだい、セッションマネージャは、804に示されるように、「in-session-mId-mId-status-sID」メッセージを一斉送信する。このメッセージを一斉送信することによって、セッションマネージャは、セッション内におけるその存在を、セッション内の他のすべてのデバイスに含まれるセッションマネージャに示す。このメッセージ（mID、mID、ステータス、sID）のパラメータは、このメディアプレーヤーデバイスのmID、プロキシによってこのデバイスについて知っているセッション内の別のメディアプレーヤーデバイスのmID（プロキシが含まれていないため、このメディアプレーヤーデバイスのmIDに設定する）、デバイスマネージャ602のプレイリストマネージャコンポーネント606のステータス、およびセッションsIDである。

「in-session-mId-mId-status-sID」メッセージを一斉送信した後、セッションマネージャは、サブファンクション806を開始する。サブファンクション806は、特定のsIDによって特定されるセッション内の他のメディアプレーヤーに関する知識を維持管理する。サブファンクション506は、セッションマネージャ状態データ構造内の情報を維持管理するポーリングループである（例えば、図7に示される）。各メディアプレーヤーに含まれるデバイスマネージャ602は、一意のsIDによって特定されるセッションごとにセッションマネージャ状態のコピーを自主的に維持管理する。各セッションでは、メディアプレーヤーが参加者である。この状態情報は、対象メディアプレーヤーに知られているセッション内の他のメディアプレーヤーごとにいくつかの要素を含む。そのような要素の1つとしては、メディアプレーヤーのmIDがある。もう一つの要素は、対象メディアプレーヤーに知られている、セッション内のプロキシメディアプレーヤーのmID（pmIDと呼ぶ）である。対象メディアプレーヤーは、たとえそのメディアプレーヤーが、対象メディアプレーヤーに直接知られていないとしても、mIDによって特定されるメディアプレーヤーはセッション内にあることを知っている。第3の例は、メディアプレーヤーのステータスである。さらに別の例は、このメディアプレーヤーが、対象メディアプレーヤーによって現行セッションにあると最後に肯定的に知られてからの時間の長さである。

サブファンクション806のポーリングループは、実装例で決定されるように「n」回実行される。この回数は、比較的任意の値であるとともに、一般に、セッションマネージャおよびセッションメンテナンスプロトコルの所望の「軽快さ（liveliness）」基準を達成するために選択される。ここで、「軽快さ」は、対象メディアプレーヤーが、セッション内におけるその存在をセッション内の他のメディアプレーヤーに示す頻度を表す。フロー図の参照番号804で指示されるように、セッションマネージャは、他のメディアプレーヤーに「in-session-mid-mid-status-sid」メッセージを一斉送信することによって、対象メディアプレーヤーがセッション内でまだアクティブであることを示すとともに、セッションマネージャ状態データテーブル702に他のメディアプレーヤーのエントリが含まれる場合、それらのメディアプレーヤーにそのステータスを知らせる。セッションマネージャ状態データテーブル702が空である場合、セッションマネージャは、代わりに、セッション参加サブファンクション802を開始することによって、参加するセッションのサーチに戻る。

サブファンクション806は、図8に示される3つのプロセス810、812、814を繰り返し実行することによって、セッション内の他のメディアプレーヤーに関する知識を維持管理する。上記3つのプロセス810、812、814は、図9〜図11にそれぞれさらに詳細に示されている。「プルーンセッションメンバー（Prune Session Members）」プロセス810は、セッションマネージャ状態データ構造702を詳細に調べ、まだセッション内に存在していたためセッションから出たと推測されるという肯定的指示を、対象メディアプレーヤーがメディアプレーヤーから受信しなかった場合、そのメディアプレーヤーに対応するエントリを削除する。「アップデートセッションメンバー（Update Session Members）」プロセス812は、セッションに参加したかまたはセッションに留まったままであると推測される他のメディアプレーヤーからのメッセージを処理する。最後に、「サービスプロシキリクエスト（Service Proxy Requests）」プロセスは814、以下のエントリをセッションマネージャ状態データ構造702が含む場合、他のメディアプレーヤーからの要求に応答する。つまり、対象メディアプレーヤーを介してプロキシによってのみ別のメディアプレーヤーに知られた、対象メディアプレーヤーに直接知られているメディアプレーヤーに対するエントリである。

プロセス810、812、814をそれぞれ順に説明すると、「プルーンセッションメンバー」プロセス810（図9）は、セッションマネージャデータ構造702内の各メディアプレーヤーiに対するエントリについて次の3つの動作の1つを実行する。

1)
メディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られた時間[i]が実装指定タイムアウト値を超えた場合、エントリは削除される。その後、削除されたエントリに対応するメディアプレーヤーがセッション内の別のメディアプレーヤーにまだ知られている場合、「proxy-session-mID-sID」クエリーが一斉送信され要求が行われる。

2)
メディアプレーヤーがセッション内の別のメディアプレーヤーにまだ知られている場合、かつメディアプレーヤーのエントリステータスが「cued（キュード状態）」にマークされた場合（メディアプレーヤーが、以下に説明するプレイリストマネージャプロセスによってトラックを実行するようにスケジュール設定されていることを意味する）、および以下の2つの状況のうち1つに該当する場合、「proxy-session-mID-sID」クエリーが一斉送信され要求が行われる。
a) メディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られた時間[i]が、実装指定キュードタイムアウト値を超えた状況である。この状況は、エントリに対応するメディアプレーヤーがキュード状態からの状態変化を送信したという指示を対象メディアプレーヤーが受信しなかったことを意味する。
b) メディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られた時間[i]が、実装指定されたキュードタイムアウト値を超えていないが、エントリに対応するメディアプレーヤーが、セッション内の別のメディアプレーヤーを介してプロキシによって対象メディアにのみ知られている状況である。この場合、その状態変化が「proxy-session-mID-sID」クエリーに応じてプロキシメディアプレーヤーによって一斉送信されれば、対象メディアプレーヤーは、エントリに対応するメディアプレーヤーによる状態変化についてのみ知る。

3)
万が一上記のいずれの条件もあてはまらない場合、メディアプレーヤーのエントリについて何も行われない。

「アップデートセッションメンバー（Update Session Members）」プロセス812（図10）は、セッションマネージャおよび「サービスプロシキリクエスト」プロセス814によって一斉送信された「in-session-mID-pmID-status-sID」メッセージを受信して、セッションマネージャ状態データ構造702を更新する。このプロセスは、メディアプレーヤーの通信経路であるネットワークのプロトコルが、すべての「in-session-mID-pmID-status-sID」メッセージを、それらが処理できるまでバッファに格納するという前提に基づいている。メッセージsIDがセッションのIDと一致する各受信メッセージは、次の5つの方法の1つによって処理される。

1）IDとしてmIDを有するエントリがすでに存在しない場合、当該メッセージのmIDを有するメディアプレーヤーに対応するエントリを、セッションマネージャ状態データ構造に追加する。

2）当該メッセージのmIDとpmIDが一致する場合（つまり、このメッセージが、対象メディアプレーヤーに現在直接知られているメディアプレーヤーによって送信されたことを意味する）、mIDを有するメディアプレーヤーのデータテーブル内のエントリは、メッセージからのステータスによって更新される。mIDを有するメディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られてからの時間は、0秒にリセットされる。

3）mIDを有するメディアプレーヤーのデータテーブル内のエントリが、プロキシメディアプレーヤーIDであるpmIDおよび受信された「in-session-mID-pmID-status-sID」メッセージからのステータスによって更新される。受信メッセージがプロキシメッセージである場合（miID、pmIDが異なる）、当該メッセージによって参照されるメディアプレーヤーは、プロキシによって対象メディアに現在知られているか（セッションマネージャ状態データ構造内のエントリに対するmID、pmIDが異なる）、またはmIDを有するメディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られてからの時間が実装タイムアウト値を超えた。さらに、参照されたメディアプレーヤーのステータスが知られていないか、またはメッセージ内のステータスがidle（アイドル状態）であるかのいずれかである。mIDを有するメディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られてからの時間は、0秒にリセットされる。

4）mIDを有するメディアプレーヤーのデータテーブル内のエントリが、受信された「in-session-mID-pmID-status-sID」メッセージからのプロキシメディアプレーヤーIDであるpmIDによって更新される。受信メッセージがプロキシメッセージである場合（miID、pmIDが異なる）、当該メッセージによって参照されるメディアプレーヤーは、プロキシによって対象メディアにのみ現在知られているか（セッションマネージャ状態データ構造内のエントリに対するmID、pmIDが異なる）、またはmIDを有するメディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られてからの時間が実装タイムアウト値を超えた。さらに、参照されたメディアプレーヤーのステータスが知られているとともに、メッセージ内のステータスがアイドル状態である。mIDを有するメディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られてからの時間は、0秒にリセットされる。

5）受信された「in-session-mID-pmID-status-sID」がプロキシメッセージである場合（miID、pmIDが異なる）、何も行わない。当該メッセージによって参照されるメディアプレーヤーは、対象メディアプレーヤーに現在知られており（セッションマネージャ状態データ構造内のエントリに対するmID、pmIDが一致する）、参照されるメディアプレーヤーが対象メディアプレーヤーに最後に肯定的に知られてからの時間は、実装時定義のタイムアウト値を超えない。

「サービスプロキシリクエスト（Service Proxy Request）」プロセス814（図11）は、すべてのメディアプレーヤーに関する情報を、「proxy-session-mID-sID」要求メッセージに応じてセッション内の他のメディアプレーヤーに肯定的に知られている対象メディアプレーヤーに提供する。「proxy-session-mID-sID」要求メッセージは、sIDによって特定されたセッション内の任意のメディアプレーヤーの「プルーンセッションメンバー」プロセス810によって一斉送信されたものである。「アップデートセッションメンバー」プロセスと同様に、このプロセスは、メディアプレーヤーの通信経路であるネットワークのプロトコルが、すべての「proxy-session-mID-sID」メッセージを、それらが処理できるまでバッファに格納するという前提に基づいている。メッセージsIDがセッションのIDと一致する各受信「proxy-session-mID-sID」メッセージは、以下の4つの方法の1つによって処理される。

1）「in session-mID-pmID-status-sID」メッセージが一斉送信される。ここで、pmID=mIDである。また、対象メディアプレーヤーが要求のmIDと一致する場合、ステータスは対象メディアプレーヤーのステータスである。

2）「in session-mID-pmID-status-sID」メッセージが一斉送信される。ここで、pmID = mIDである。また、クエリーのメディアプレーヤーmIDが対象メディアプレーヤーに肯定的に知られている場合（クエリーのmIDが、状態マネージャ状態データ構造のpmIDと一致する場合）、mIDおよびステータスパラメータは、クエリーによって参照されるメディアプレーヤーのセッションマネージャ状態データ構造702内のmIDおよびステータスパラメータである。

3) 「in session-mID-pmID-status-sID」メッセージが一斉送信される。ここで、クエリーのメディアプレーヤーmIDが、対象メディアプレーヤーにプロキシによってのみ知られている場合（クエリーのmIDが、状態マネージャ状態データ構造内のpmIDと異なる場合）、pmIDおよびステータスパラメータは、クエリーによって参照されるメディアプレーヤーのセッションマネージャ状態データ構造702内のpmIDおよびステータスパラメータである。

4）「proxy-session-mID-sID」メッセージが、対象メディアプレーヤーに知られているセッションマネージャ状態データ構造402内の対象メディアプレーヤーまたはメディアプレーヤーを参照しない場合、何も一斉送信されない。

個別のメディアプレーヤーデバイスのプレイリストマネージャは、2つの主要なサブファンクションから成る。第1は、「プレイリストキューアップデータ（Playlist Queue Updater）」プロセス1300である。図13に示すように、このプロセスは、セッション内のメディア再生デバイス間でプレイリスト情報の共有をネゴシエートする。第2は、「プレイリストプレイシーケンサ（Playlist Play Sequencer）」プロセス1400である。図14に示すように、このプロセスは、対象メディアプレーヤーによるメディアアイテムの演奏を制御する。

プレイリストマネージャ1200（図12）は、クライアントサーバ構成を有するサーバシステム上で、またはピアツーピア構成を有する、特権を付与されたピアツーピアネットワークアクセスシステム上で、単一のプレイリストビルダが存在していると仮定する。ピアツーピア型実施例では、プレイリストビルダは、ネットワークレベル機能のホストとして機能する一部のピアツーピアネットワークに見られるシステム上に実装することができる。一方、その他の実施例では、プレイリストビルダは、ネットワーク内の1つのピアシステム上に実装することができる。「プレイリストキューアップデータ」は、メディアプレーヤーからのデータを、プレイリスト作成プロセスで使用されるプレイリストビルダに提供する。プレイリストビルダについては、後で詳細に説明する。

プレイリストマネージャ1200も、メディアプレーヤーが、図15に概念的に示されるプレイリスト作成プロセスに関連するいくつかのデータアイテムを利用可能にすると仮定する。一部の実施例においては、メディアプレーヤーデバイス1502は、メディアアイテムをローカルライブラリ1506に格納する。さらに、メディアプレーヤーデバイス1502は、ローカルディレクトリ1508に問い合わせて、メディアプレーヤーによる演奏に対して特定のメディアアイテムが利用可能かどうかを判断する機構を提供する。その他の実施例においては、メディアプレーヤー1502は、要求に応じて通信ネットワークを通じた遠隔サービスからメディアアイテムをダウンロードする（または流す）。また、メディアプレーヤー1502は、メディアプレーヤーによる演奏に対して、遠隔サービスから利用可能なメディアアイテムのディレクトリ1504について問い合わせる仕組みを提供する。図15も、プレイリスト作成プロセスに関連するメディアプレーヤーによって維持管理されるその他のデータアイテムをいくつか示している。これらのデータアイテムは、プレイリストにプリエンプティブな方法で追加されるべきメディアアイテムの指示1510、およびユーザがプレイリストに、追加したくない、優先的に追加する、および可能ならば追加するアイテムのアイテムリスト（それぞれ、1512、1514、1516）を含む。

図13は、「プレイリストキューアップデータ」プロセス1300のトップレベルのフロー図である。図示されるように、このプロセスは、際限なく実行される反復性のプロセスである。「プレイリストキューアップデータ」は、最初に、作成中のプレイリストに特定のメディアアイテムを追加することを、対象メディアプレーヤーのユーザが要求したかどうかを判断する。要求したと判断される場合、「プレイリストキューアップデータ」は、「force-iid-pid-length-sid」メッセージをプレイリストビルダに送信する。このメッセージは、iIDによるメディアアイテム、メディアプレーヤーのpID（これは、すでに説明したセッションキューアップデータ（Session Queue Updater）によって用いられるmIDと同じ値である）、メディアアイテムのタイムユニットの長さ、およびセッションのsIDを指定する。

特定のメディアアイテムをプレイリストに追加するという任意のユーザ要求が処理された後、「プレイリストキューアップデータ」は、対象メディアプレーヤーがプレイリストに対して特定のメディアアイテムを提供できるかどうかを問い合わせるプレイリストビルダから、「have-iID-sID」要求メッセージが受信されたかどうかをチェックする。このプロセスは、メディアプレーヤーの通信経路であるネットワークのプロトコルが、すべての「have-iID-sID」要求メッセージを、それらが処理できるまでバッファに格納するという前提に基づいている。メッセージsIDがセッションのIDと一致する各受信メッセージは、次の3つの方法の1つによって処理される。

1）対象メディアプレーヤーpIDが、メディアアイテムのローカルライブラリから長さ「length」を有する要求済みメディアアイテムiIDにアクセスする場合、「have-iID-pID-length-sid」メッセージが一斉送信される。

2）対象メディアプレーヤーpIDが、メディアアイテムのローカルライブラリから長さ「length」を有する要求済みメディアアイテムiIDにアクセスしないが、遠隔サービスからの要求済みメディアアイテムにアクセスする場合、「have-iID-pID-length-sid」メッセージが一斉送信される。

3）メディアプレーヤーが要求済みメディアアイテムにアクセスしない場合、何の応答も一斉送信されない。

一部の実施例においては、「プレイリストキューアップデータ」は、リスト1512、1514、1516によって示されるように、メディアアイテムに関するユーザの好みを考慮して、「have-iID-sID」要求メッセージに応じて「have-iID-pID-length-sid」メッセージを供給するかどうかを決定する。例えば、「プレイリストキューアップデータ」は、たとえ要求されたアイテムがデバイスのカタログ1504または1506にあるとしても、そのアイテムが「再生なし（no play）」リスト1512にもある場合は、「have-iID-sID」メッセージに応答しない。同様に、要求されたアイテムが「優先再生（preferred）」リスト1514にある場合、「プレイリストキューアップデータ」は、何らかの統計的基準またはその他の基準にしたがって任意に応答する。さらに、要求されたアイテムが「再生必須（must play）」リスト1514にある場合、「プレイリストキューアップデータ」は常に応答する。

「プレイリストキューアップデータ」のフロー図に示される繰り返しの最後のステップでは、プレイリストビルダから「queue-iID-pID-length-sID」メッセージを受信した場合、それらのメッセージの少なくとも1つを処理する。このプロセスは、メディアプレーヤーの通信経路であるネットワークのプロトコルが、すべての「queue-iID-pID-length-sID」メッセージを、それらが処理できるまでバッファに格納するという前提に基づいている。一部の実施例においては、「プレイリストキューアップデータ」は、メッセージからのiID、長さ、およびpIDアイテムから成る、プレイリストマネージャのプレイリストキュー（Playlist Queue）データ構造にエントリを追加することによって、繰り返しごとに単一の「queue-iID-pID-length-sID」メッセージのみを処理する。その他の実施例においては、「プレイリストキューアップデータ」は、複数のまたはすべての保留中の「queue-iID-pID-length-sID」メッセージを処理する。

1つの実施例においては、プレイリストの演奏は、事実上プレイリストビルダによって方向付けられる。後述するように、プレイリストビルダは、プレイリストマネージャ1200のプレイリストキューデータ構造1202にメディアアイテムを追加することを要求するセッション内のすべてのメディアプレーヤーに、「queue-iID-pID-length-sid」メッセージを一斉送信する。プレイリストビルダは、メディアアイテムを実行すべき実際の時間にこのメッセージを送信する。メディアプレーヤーは、そのメッセージを、所定のメディアアイテムを実行するコマンドとして受け付ける。この実施例の変形としては、プレイリストビルダは、メディアアイテムを実行すべき時間よりも十分に前もってこのメッセージを送信することによって、演奏が開始するまでに、演奏を開始するのに必要ないずれの処理もメディアアイテムが実行できるようにする。

別の実施例では、図14に示されるプレイリストマネージャ1200の「プレイリストプレイシーケンサ（Playlist Play Sequencer）」プロセス1400は、対象メディアプレーヤーによって実際に演奏されるプレイリスト上のアイテムの演奏を、該当するメディアプレーヤーによるプレイリスト上の他のメディアアイテムの演奏とローカルで連携させる。セッション内のすべてのメディアプレーヤーは、プレイリストキュー1202のコピーを含む。このコピーは不完全である。これは、対象メディアプレーヤーがセッションに参加する前にプレイリストに置かれた待ち行列の先頭における欠落アイテムである。または、通信障害に起因する待ち行列の中央部における欠落アイテムである。プレイリストプレイシーケンサによって、対象メディアプレーヤーは、個々のメディアアイテムのその演奏を、プレイリスト内にこれらの起こり得るギャップがある状態における、セッション内の他のメディアプレーヤーによるメディアアイテムの演奏と同期させることができるようになる。

「プレイリストプレイシーケンサ」1400は、例えば、以下の3つの方法の1つを使用してプレイリストキュー1202の先頭にあるアイテムを処理することによって、ギャップが存在する場合における同期演奏を達成する繰り返しプロセスである。

1）待ち行列の先頭にあるメディアアイテムのpIDが対象メディアプレーヤーのpIDではない場合、フロー図の左の支流に対応して、「プレイリストプレイシーケンサ」は、実質的にアイドル状態となり、セッションメンバー状態データ構造702においてmID=pIDであるメディアプレーヤーのステータスを、メディアアイテムが演奏されたと推測されるまで監視する。「再生中」から「アイドル状態」への移行が確認されるか、またはローカルプレイ時間タイマーの値がメディアアイテムの演奏の長さを超えた場合、対象メディアプレーヤーは、メディアアイテムが演奏されたと推測する。

2）待ち行列の先頭にあるメディアアイテムのpIDが対象メディアプレーヤーのpIDである場合、かつセッションメンバー状態データ構造702が、ステータス値「playing（再生中）」を有する別のメディアプレーヤーのエントリを含まない場合、フロー図の中央の支流に対応して、「プレイリストプレイシーケンサ」はメディアアイテムを再生する。アイテムが再生されている間、対象メディアプレーヤーのステータスは「playing（再生中）」に設定される。演奏が終了して、セッション内の他のメディアプレーヤーにその演奏の信号を送った後、ステータスは「idle（アイドル状態）」に戻される。

3）待ち行列の先頭にあるメディアアイテムのpIDが対象メディアプレーヤーのpIDであるが、セッションメンバー状態データ構造702が、ステータス値「playing（再生中）」を有する別のメディアプレーヤーのエントリを含む場合、フロー図の右の支流に対応して、メディアアイテムの演奏は延期される。「プレイリストプレイシーケンサ」は、ステータス値「cued（キュード状態）」を有するメディアプレーヤーがなくなるまで、フロー図のこの支流を繰り返し通過する。その後、「プレイリストプレイシーケンサ」は、対象メディアプレーヤーのステータス値を「cued（キュード状態）」に設定する。次の繰り返しで、「プレイリストプレイシーケンサ」は、フロー図の中央の支流に進み、上述したようにメディアアイテムを再生する。

すでに述べたとおり、各メディアプレーヤーデバイスに含まれるデバイスマネージャのプレイリストマネージャは、クライアントサーバ構成を有するサーバシステム上で、またはピアツーピア構成を有する、特権を付与されたピアツーピアネットワークアクセスシステム上で自主的プレイリストビルダの存在を仮定する。ピアツーピア型実施例では、プレイリストビルダは、ネットワークレベル機能のホストとして動作する一部のピアツーピアネットワークに見られるシステム上に実装することができる。一方、その他の実施例では、プレイリストビルダは、ネットワーク内の1つのピアシステム上に実装することができる。

図16は、プレイリストビルダ1606が、メディアアイテムに関する情報の知識ベース1604を利用して、セッション内のメディア再生デバイスに利用可能なメディアアイテム1602のプールから、プレイリスト待ち行列1608に含まれるメディアアイテムのプレイリストを構成する方法を示す。

図17は、プレイリストビルダ1606のプロセスのフロー図である。このプロセスは、プレイリストに含める候補となるメディアアイテムのIDを生成する方法の利用可能性を前提とする。候補は、知識ベース1604の情報、およびメディアプレーヤーがセッションに参加しているユーザの好みに関する知識などを含む、多くの基準に基づいて提案される。

「プレイリストビルダ」は、繰り返しごとに単一のメディアアイテムをプレイリストに追加する繰り返しプロセスである。各繰り返しは、次の3つのステップを含む。

1）ciIDを有する候補メディアアイテムを、知識ベース1604内の情報および/または他の基準に基づいて生成する。「who-has-cilD-sID」クエリーを、セッション内のすべてのメディアプレーヤーに一斉送信して、いずれかのメディアプレーヤーが提案されたメディアアイテムにアクセスするかどうかを判断する。

2）セッション内のいずれかのメディアプレーヤーのプレイリストキューマネージャ（Playlist Queue Manager）が、未処理の「force-iID-pID-length-sID」メッセージを以前に一斉送信した場合、要求されたメディアアイテムiIDがプレイリスト2108に追加される。プレイリストビルダは、セッション内のすべてのメディアプレーヤーに「queue-iID-pID-length-sID」メッセージを一斉送信して、プレイリストキューマネージャが維持管理しているローカルプレイリストに、要求されたメディアアイテムが追加されるように指示する。

3）実装により決定された遅延の経過後、セッション内のいずれかのメディアプレーヤーのプレイリストキューマネージャが、未処理の「have-iID-pID-length-sID」応答メッセージを一斉送信したかどうかの判断が行われる。この応答メッセージは、セッション内のメディアプレーヤーが、要求されたメディアアイテムiIDにアクセスすることを示す。1つ以上のメディアプレーヤーが要求済みアイテムにアクセスするとき、それらのメディアプレーヤーの1つが、そのメディアアイテムを実行するメディアプレーヤーとして、ランダムにまたは何か他の基準にしたがって選択されるとともに、そのアイテムがプレイリストに追加される。プレイリストビルダは、セッション内のすべてのメディアプレーヤーに「queue-iID-pID-length-sID」メッセージを一斉送信して、プレイリストキューマネージャ1100が維持管理しているローカルプレイリストに要求済みメディアアイテムが追加されるように指示する。

このプロセスは、メディアプレーヤーの通信経路であるネットワークのプロトコルが、すべての「force-iID-pID-length-sID」要求メッセージおよび「have-iID-pID-length-sID」を、それらが処理できるまでバッファに格納することを前提としている。いずれの特定の実施例においても、1つ以上の各タイプのメッセージが繰り返しごとに処理される。さらに、フロー図に指示されるように、ステップ2）および3）は、タイムアウト値によって限定された回数繰り返され、プレイリストビルダとメディアプレーヤーデバイスとの間の通信の応答性を向上させる。

プレイリストビルダの繰り返しは、際限なく繰り返される。プレイリストは、セッション内に少なくとも1つのメディアプレーヤーが存在する限り再生されるメディアアイテムの無限シーケンスである。さらに、一部の実施例では、メディアデバイスのユーザによって提案されるメディアアイテムのみから成るプレイリストの作成がサポートされている。「force-iID-pID-length-sID」要求メッセージによってプレイリストビルダへの伝達が行われる。そのため、フロー図内の「auto build?」嗜好が失敗するようにオプションフラグを「false」に設定するオプションが設けられる。

図18〜図26を参照して、さらに別の実装例を開示して説明する。これらの実施例では、選択されたメディアアイテムのプレイリストは、メディアプレーヤーデバイスを所有する時間的に定義されたユーザのグループの好みに基づいて、メディアアイテムの集まりから動的に作成される。合成的な目標、およびそれらの目標を達成するために利用可能なメディアアイテムの集まりを、個々のユーザがグループに入ったり出たりしたとき、例えば、グループに対する合成嗜好データを使用して、全体として動的に計算する。

したがって、一部の実施例は、個人の時間的に定義されたグループの集合的な嗜好に対応したメディアアイテムのプレイリストを動的に作成する方法に関する。さらに、一部の実施例では、グループプレイリストが動的に多様化される。これは、グループプレイリストが、全体的にまたは部分的に、グループ（または、全体のグループに含まれるユーザの特定のサブグループ）の単一のメンバーの嗜好を過度に反映しないようにするためである。

追加の実施例では、 グループのメンバーの集合的な嗜好プリファレンスを使用してプレイリストの合成的目標を決定することによってメディアアイテムのプレイリストを動的に作成し、その後、それらの合成的目標を達成するグループプレイリストを作成するシステムおよび方法が提供される。このシステムは、グループの現在のメンバーの嗜好プリファレンスを分析することによって、合成的な目標を導き出す。それらの目標を達成するために利用可能なメディアアイテムは、一般に、嗜好データの分析に応じて特定されるメディアアイテムの部分集合であり、このシステムが利用可能なメディアアイテムの集まりから選択される。利用可能なメディアアイテムの集まりは、ユーザによって提供されたメディアアイテムの部分的集まりを集約したものであるか、またはその代わりに、例えば、中央データベースまたはジュークボックスに格納されているメディアアイテムの既存の集合である。

本システムの好適な実装例では、3つの主要プロセスが提供されている。第1のプロセスは、例えば、個別のネットワーク化された通信装置を使用して本システムとの通信を開始または終了することによって、ユーザがグループに入ったときおよび/またはグループから出たとき、ユーザを追跡する。例示する実施例は、 Bluetooth（登録商標）デバイス、およびインターネットの特別なネットワーク内で通信するその他のデバイス、または、例えば、Apple Bonjourプロトコルを使用するその他のネットワーク接続されたデバイスなどを含む。個々の通信装置を有するユーザは、通信ネットワークとの接続および接続解除を暗黙的にまたは明示的に行ったとき、システムによってグループに追加される、および/またはグループから削除される。ここで、通信ネットワークは、グループプレイリストを作成する計算手段に個々のデバイスをリンクする。

ユーザがグループに入ったとき、本システムはユーザの嗜好データを検索する。嗜好データは、例えば、本システムに知られているユーザから嗜好データのデータベースにアクセスして、またはユーザの通信装置から嗜好データを直接要求して、グループに対する嗜好データのプールにその嗜好データを追加することによって検索される。さらに、本システムは、ユーザがグループを出たとき、グループに対する嗜好データのプールからそのユーザの嗜好データを削除するように構成される。プレイリストに含めることが可能なメディアアイテムがユーザによって提供されるとともに、それらのメディアアイテムが本システムによって中央で維持管理されない一部の実施例においては、本システムは、現在のグループに利用可能なメディアアイテムのプールを維持管理する。

グループに対する嗜好データのプール、およびプレイリストに含めることが可能なメディアアイテムのプールを使用して、第1のプロセスは、プレイリストの合成的な目標を導き出す。例えば、特定の属性の選択済みメディアアイテムに対する値が所定の分布を有することを要求することなどである。一部の実施例においては、第1のプロセスは、プレイリストの作成に使用すべきメディアアイテムの全体のプールからメディアアイテムの部分集合を選択することも含む。図41から図42を参照して以下にさらに説明するように、これはメディアアイテム「リコメンダ（recommender）」を使用して達成される。

第2のプロセスは、選択されたアイテムがプレイリストに追加されたとき、進展中のプレイリストが所定の合成的な目標にさらに近づく方法で、メディアアイテムのプール全体からメディアアイテムを選択することによってコンポジットプレイリストを作成する。したがって、本システムの一部の実装例は、絶えず変化しているグループのメンバー構成に対応している。特に、グループのユーザは連続的にグループに入ったり出たりするため、合成的な目標および/またはそれらの目標を達成するために利用可能なメディアアイテムのプールは絶えず変化する。一部の実施例では、特に、グループメンバーが実際にメディアアイテムをプールに提供する状況においては、ユーザがグループから出たとき、メディアアイテムが動的なプレイリストから削除される。そのような状況においては、プール内のメディアアイテムは、例えば、近接から物理的に去ることによって、またはシステムからログアウトすることによって、ユーザが出たときに、プールから削除される。しかし、そのような機能はすべての実装例に必要であるわけではないことを理解する必要がある。なぜならば、メディアアイテムは、再生すべきときに利用可能でなければスキップすることができるからである。

第3のプロセスは、グループプレイリストを多様化させることを含む。多様化プロセスは、必要に応じてリスト上のメディアアイテムを再編成することによって、プレイリストのセグメントが、１人以上のグループメンバーの嗜好を代表するメディアアイテムによって確実に左右されないようにする。一部の実施例においては、メディアアイテムの美的特性に関する付加情報を使用してグループプレイリスト内のメディアアイテムの順序を再編成することによって、具体的な美的目標を達成する。最後に、ユーザがほとんどいないために、各ユーザについて、プレイリストがまさにそのユーザの嗜好に応じた多数のアイテムを含む場合は、一部の実施例では、一部のメディアアイテムを追加のメディアアイテムと入れ替える。これらの追加のまたは補足的なメディアアイテムは、グループ内の任意のメンバーによって提供されるものではなく、グループプレイリストをさらに多様化させるための多様化した基準によって選択されるものである。

本システムの一実施例では、図18から図20に詳述されるプロセスが実装される。この実施例は、ジュークボックスのオートメーション化された進化に類推される。ジュークボックスは、ローカル音楽を提供するとともに、ユーザからの明示的なユーザ対話を要求して所望の音楽を選択するのに対して、これらの実施例は、本システムに（物理的にまたは仮想的に）最も近いユーザに関する以前に収集されたデータに基づいて自動的にプレイリストを作成する。

図18から図20に示す実施例の以下の説明において、本システムにユーザを追加するプロセスについて最初に説明し、次にユーザを削除するプロセスについて説明し、最後に、全体的なプレイリスト構築プロセスについて説明する。プレイリストを作成するための最も近いユーザの知識を活用した目標とするプレイリストを作成するための情報を、プロセスが使用する方法が含まれる。

本システムが、最も近いユーザのプレイリストを「ナローキャスト（narrowcast）」するために（すなわち、特定のユーザのセットへのコンテンツを対象とする）、最も近いユーザを発見/検出する仕組みが提供される。1つの実施例においては、例えば、 Bluetooth（登録商標）技術を使用する（図24に示されるような）サーバプロセス2400が提供されることによって、ユーザによる本システムへの 「ログイン（log in）」が可能になる。他のユーザまたはサーバに物理的に近接しているかどうかには関わらず、本システムに「ログインした」ユーザは、最も近いユーザであると考えられる。一部の実施例においては、すべての最も近いユーザは、作成中のプレイリストにすぐに影響し始める。このことは、後でさらに詳細に論じる。 Bluetooth（登録商標）は、本システムへのユーザの追加に使用することが可能な多くのデータ発見/エントリメカニズムのまさに1つであることは、当業者にとっては明らかである。他の実施例は、ユーザからの明示的なテキスト入力を含む。または、まさにAppleのBonJourプロトコルなどのゼロ構成プロトコルである。

Bluetooth（登録商標）ユーザ追加プロセスの一実装例のステップ1では、あらかじめ決められたサービスUUID（Universally Unique Identifier（汎用一意識別子））を有する Bluetooth（登録商標）サーバが提供される。 Bluetooth（登録商標）仕様は、UUIDを使用して、多数のデバイスにわたるサービスを一意に特定する。UUIDを使用することにより、Bluetooth(r)クライアントは、遠隔サーバ上の特定のサービスを検出することができる。

ステップ2では、クライアント Bluetooth（登録商標）プロセスが本システムの Bluetooth（登録商標）サーバ2400と接続すれば、図25の参照番号2500に示されるように、当該クライアントはユーザ情報をサーバプロセス2400に送信する。その後、参照番号2501に示されるように、サーバプロセス2400はユーザ情報の妥当性確認を行う。ユーザ確認プロセス2501が失敗した場合、ユーザは拒絶される。そのため、このユーザは、ユーザリスト変更プロセス2502によって近接ユーザリスト2503または近接デバイスリスト2504に追加されない。ユーザ確認プロセス2501が成功した場合、当該ユーザは近接ユーザリスト2503に追加され、ユーザデバイスは近接デバイスリスト2504に追加される。当業者によって理解されるように、ユーザおよびユーザデバイスを該当するリストに登録する手段は異なる場合がある。

リアルタイムでナローキャストされたプレイリストコンテンツを提供するために、本システムは、望ましくは、近接ユーザリスト2503と近接デバイスリスト2504の内容の更新および維持管理を定期的に行う。同時に、本システムは、いずれか一方のリストからユーザが誤って移動されてしまう可能性が減少するように構成されている。これらの問題は、図26に示されるように、ユーザ/デバイス近接検出プロセス（User/Device Proximity Detection Process）2600を使用して、本システムに近接するユーザを特定することによって対処される。他の様々なプロセスのように、プロセス2600は Bluetooth（登録商標）技術を使用して実装される。本システムは、例えば、近接したデバイスを検出して、近接デバイスリスト2504を近接ユーザリスト2503にマップすることによって、ユーザがもはや近接していないことを判断することができる。

もはや近接していないユーザであると判断された場合、ユーザ/デバイス非活動検出プロセス（User/Device Inactivity Detection Process）2601を使用して、ユーザを近接ユーザリスト2503から削除すべきかどうか、およびユーザのデバイスを近接デバイスリスト2504から削除すべきかどうかの判断を開始する。ユーザ/デバイス非活動検出プロセス2601は、時間ベースのプロセスとして実装される。本システムは、ユーザが最初に非近接であると分類された時間を記憶するように構成される。その後、例えば、特定の制限時間が経過したとき、非近接ユーザが引き続き非近接であると特定された場合、ユーザ/デバイス削除プロセス（User/Device Removal Process）2602によって、ユーザが近接ユーザリスト2503から削除されるとともに、ユーザのデバイスが近接デバイスリスト2504から削除する。ユーザ/デバイス非活動検出プロセス2601の制限時間が経過する前に、ユーザ/デバイス近接検出プロセス2600によってユーザが近接していることが判明した場合、ユーザとそのデバイスは、該当するリスト2503/2504に残される。前記のシステムの具体的な実装例は、 Bluetooth（登録商標）または時間ベースのユーザ削除方法の使用に依存する（ただし、必須ではない）ことは当業者にとって明らかである。

コンポジットプレイリストビルダ（Composite Playlist Builder）プロセスは、プレイリストをナローキャストすべきユーザを決定するために、上記のユーザ追加/削除（User Addition/Removal）プロセスに依存する。一実装例では、コンポジットプレイリストビルダプロセスは、最初に、ユーザ嗜好を定義するメディアアイテムのリストを生成して、その後、システム内のすべての近接したユーザに対してこのステップを繰り返す。

図18に示されるように、ユーザ嗜好を定義するメディアアイテムのリストを生成するプロセスは、本システムにログインしているユーザ1800を検査してから、参照番号1802に示されるように、情報（すなわち、メディアアイテム嗜好データ）を使用してユーザ嗜好を合成することによって遂行される。メディアアイテム嗜好データは、本システムによって同時に収集されるか、または代わりに、以前に収集されたメディアアイテム嗜好データからリストまたはデータベースに編集される。これらのいずれか一方が、図18に示されるステップ1801によって表される。次に、参照番号1803に示されるように、ユーザ1800にナローキャストすべき音楽に関する情報を含む、メディアアイテムのリストおよび/またはメディアアイテムメタデータ（集合的に「メディアデータアイテム」と呼ぶ）を作成する。グループプレイリストを生成するために、いずれのユーザも本システムにログインする必要はないことに留意すべきである。システムが利用できるユーザがないか少ない場合、またはシステムが利用できるデータが不十分な場合、あらかじめ構成された目標を使用することができる。このプロセスは、本システムにログインしているユーザ1800ごとに繰り返される。

一実施例においては、データをキャッシュに入れることによって、高速な検索を可能にしている。他のステップで実証するが、ユーザ嗜好を代表するデータは、他のステップが情報を引き出す元となる基礎も提供する。一部の実施例においては、ユーザ嗜好は、最初に、ユーザが最近視聴したトラックのセット、および/またはユーザが当然最高にランク付けしたトラックのセットを取得することによって合成される。収集したユーザ嗜好データに基づいてユーザ嗜好を合成する方法には、多くの異なる方法があることは当業者にとって明らかなことである。

一実装例の第2のプロセスとして、集約されたプレイリスト目標を、第1のプロセスの結果および/または所望のカテゴリのリストに基づいて計算する。一般に、入力メディアデータアイテムは、ユーザごとに1セットであることに留意する必要がある。

集約されたプレイリスト目標を計算するには、図19に示されるように、ユーザ嗜好1900を示す、メディアアイテムのセットおよび/またはメタデータ、および/またはあらかじめ決められたまたは計算された興味のあるカテゴリのセット1901を、ユーザ嗜好集約プロセス（User Taste Aggregation Process）1902の入力として使用する。ユーザ嗜好集約プロセス1902は、近接したユーザにナローキャストされることを目的としたグループプレイリストに対して、最適プレイリスト特性のセット1903を生成するために使用される。ある特定の実施例では、2つ以上のユーザの嗜好を代表するメディアアイテムおよび/またはメタデータは、重複しては見られない。この機能によって、ユーザ嗜好集約プロセス1902を使用して、複数のユーザ間で共通するメディアアイテムおよび/またはメタデータの重要性を、所定のレベルに高めることができる。ユーザ嗜好集約プロセス1902は、ユーザ嗜好1900と所望の興味のあるカテゴリ1901の両方を入力として受け付ける。興味のあるカテゴリ1901は、多くの場合、特定のユーザのグループを対象としたナローキャストプレイリストに対する最適プレイリスト特性1903の計算に使用すべきメタデータのセットを示すメタデータインジケータである（ただし、必須ではない）。

1つの実施例では、ジャンルを含むカテゴリセット1901を使用する。そのようなシステムは、接続されたユーザごとに検索された再生履歴に含まれるジャンルの頻度分布を計算する。各ジャンルの百分率は、生成されたグループプレイリストの最適ジャンル分布として使用される。当然、プレイリストの生成に使用できるカテゴリは、ジャンルだけではない。未処理の頻度分布は、所定のカテゴリに関する統計を計算する唯一の方法でないことも理解しておく必要がある。他の類似した実装例では、重み付けによる方法または投票による方法を採用して（ただし、これらに限定されない）、機能ごとに所望のレベルを決定する。

集約されたプレイリスト目標が計算された後、ユーザに対応した関連メディアアイテムが、利用可能なメディアアイテムのプールから選択される。このプロセスは、システム内で近接したユーザごとに繰り返される。

例えば、図20において、所定のユーザと関係付けられた関連メディアアイテムのセット2002が計算/選択される。これを行うために、プロセス2001がユーザごとに実行される。プロセス2001は、メディアアイテムのセット、および/またはユーザの嗜好1803を示すメタデータ、および/またはすべての利用可能なメディアアイテムのセット2000を入力として受け付ける。プロセス2001は、単一のユーザの関連メディアアイテムである、利用可能なメディアアイテムの部分集合を生成する。

1つの実施例においては、プロセス2001は、例えば、以前に参照として示された、「Recommender System for Identifying a New Set of Media Items Responsive to an Input Set of Media Items and Knowledge Base Metrics」という名称を有する米国特許出願シリアル番号11/346818に説明されるような、メディアアイテムリコメンダを使用することによって実装される。プロセス2001は、メディアアイテムリコメンダに、メディアアイテムの部分集合を推奨する元となる、推奨メディアアイテムを完全に網羅した範囲を提供することによって増加される。実際問題として、これは、推奨されたメディアアイテムが、コンポジットプレイリストビルダアプリケーションによって利用可能であることを確かめるために使用される。例えば、選択される利用可能なメディアアイテム2000が1000個である場合、プロセス2001は、関連メディアアイテム2002が、1000個の利用可能なメディアアイテム2000の範囲内であることを確実にする。これは、プレイリストを作成する元となるメディアのセットが有限であるジュークボックスに類似している。プロセス2001が利用できるメディアアイテムは、プロセス2001を実行しているマシンと同じマシンに存在している必要はないことは明らかである。任意のプロトコルを介してプログラム的に入手可能ないずれのメディアアイテムも、利用可能なメディアアイテムと考えられる。

各ユーザの関連メディアアイテムが利用可能なメディアアイテムのプールから選択された後、それらのメディアアイテムは、所望の属性のセットにしたがって分類される。例えば、図21に示されるように、関連メディアアイテム2100は、ユーザ嗜好集約プロセス1902において以前に使用された興味のあるカテゴリ1901にしたがって、カテゴリ化プロセス2101によって分類される。カテゴリ化プロセス2101を使用して、関連メディアアイテム2102のカテゴリ化済みリストが作成される。このリストによって、全体のシステムは、1つ以上の興味のあるカテゴリ1901に基づいて1つ以上のメディアアイテムを選択することが可能になる。

所望の属性のセットによってメディアアイテムが分類された後、目標に対する現在のグループプレイリストの達成のステータスが評価/計算される。例えば、図22を参照すると、カテゴリ化プロセス2101とともに目標評価プロセス2201を使用して、実行が必要な目標の優先順位付きリスト2202が作成される。カテゴリ化プロセス2101は、現在のプレイリスト2200および興味のあるカテゴリ1901を入力として受け付ける。カテゴリ化プロセス2101は、興味のあるカテゴリ1901を使用して、現在のプレイリスト2200上でメディアアイテムを分類する。カテゴリ化プロセス2101の出力は、目標評価プロセス2201に送信される。目標評価プロセス2201を使用して、現在のプレイリスト2200の特性が最適プレイリスト特性1903にどれだけ近いかを判断する。目標評価プロセス2201の出力は、実行する必要がある目標の優先順位付きリスト2202である。

1つの実施例においては、ジャンルの頻度分布は、カテゴリ化プロセスのために計算される。目標評価プロセスは、最適プレイリストの目標百分率から現在のプレイリストの達成済みジャンル百分率を減算することを含む。目標評価プロセスは、最大の値の差を、プレイリストに対する必要な来るべきジャンルとして使用することができる。当然、他の様々なアプローチを使用して、プレイリストの要望を計算することができる。

目標に対する現在のグループプレイリストの達成のステータスを評価/計算した後、以前に実行した目標達成評価プロセスにしたがって、プレイリストに対する現在の要望の評価に基づいてグループプレイリストに追加するトラックのセットが選択される。例えば、図23を参照すると、プレイリスト追加プロセス2302によって、1つ以上のメディアアイテム2301のセットが選択され、現在のプレイリスト2200に追加される。メディアアイテム選択プロセス2300は、実行が必要な目標の優先順位付きリスト2202、関連アイテムの分類済みリスト2102、および現在のプレイリスト2200を入力として受け付ける。一部の実施例においては、メディアアイテム選択プロセス2300は、目標を最善に実行する関連アイテムのリスト2102からメディアアイテムを選択することによって最も重要な目標を実行するような優先順位を付けた方法で、目標を実行しようと試みる。複数のメディアアイテムが目標の実行に役立つ場合、メディアアイテムは、リストからランダムに選択される。または、何らかの形式のタイブレーカプロセスなど、別の方法で選択される。

選択されたメディアアイテムに対して多様化ステップを実行してもよい。多様化ステップを使用することによって、プレイリストに追加されているメディアアイテムが、現在のプレイリストの内容と類似しすぎないようにすることができる。一部の実施例においては、多様化ステップは、グループプレイリスト内のメディアアイテムを再編成して、1つ以上のユーザの嗜好を過度に代表するメディアデータアイテムを含むグループプレイリストの少なくとも1つのセグメントを多様化させることを含む。本システムは、グループプレイリストが、１人以上のユーザの嗜好を代表するメディアアイテムによって左右されることの決定に応じて、1人以上のユーザの嗜好と一致するグループプレイリストから少なくとも1つのメディアデータアイテムを削除するように構成されている。

一部の実施例においては、現在のプレイリスト2200に対してメディアアイテムの選択および追加を行うには、多様化プロセスを使用しなければならない（多様化プロセスがプール内のすべてのメディアアイテムを除外する場合を除く）。メディアアイテムの十分なセットが選択されれば、メディアアイテムのセット2301は、プレイリスト追加プロセス2302に送信される。プレイリスト追加プロセス2302は、メディアアイテムのセット2301をアクティブなプレイリストに追加する。プレイリスト追加プロセス2302は、現在のプレイリスト2200を作成/更新する機能を有する。さらに、一部の実装例では、プレイリスト追加プロセス2302は、現在のプレイリスト2200に含まれるメディアアイテムの再生を開始する機能を有する。

1つの実施例においては、メディアアイテムは、現在のプレイリストにとって最も必要なジャンルから選択される。これは、該当するジャンル内で分類された関連トラックからランダムに選択することによって行われる。多様化ステップを使用して、決められた時間、メディアアイテムがグループプレイリスト内で繰り返されないことを確実にする。その他の実施例では、多様化ステップを使用して、アーティスト、アルバム、ジャンルなどのメディアアイテムの部分集合が、グループプレイリストの所定の部分集合の範囲内で繰り返されないことを確実にする場合もある。例えば、多様化ステップを使用して、グループプレイリスト内の7トラックウィンドウの中で、特定のアーティストからのメディアアイテムが繰り返されないようにする。多様化プロセスの要件を実行することが不可能である場合、該当するジャンル内のすべてのメディアアイテムからメディアアイテムをランダムに選択する。複数のジャンルに特定される優先順位が等しい場合、選択されたメディアアイテムは、特定されたジャンルのいずれか1つから選択される。または、何か他のタイブレーク選択手順によって選択される。
ベニューの推奨

次に図27に進む。先に説明した技術の別の適用例として、ベニューが、その提供をユーザまたは顧客の嗜好に合わせることができるようにする。この文脈においては、「ベニュー」として可能なのは、ホテル、レストラン、バーなどの実際の物理的空間である。または、ベニューは、インターネット上のベニューなど、仮想空間に存在することができる。さらに、現在の文脈においては、「ユーザ」として可能なのは、個々のユーザ、ユーザグループ、またはユーザのグループである。

ホテルを例にして、本発明のこの局面を説明する。ここで図27に進むと、顧客がホテルユーザとしてサインアップする。これは、例えば、インターネットを使用したサービスである。現在、多くのホテルは、「ロイヤルティ」または好ましい顧客の手配だけでなく、オンライン登録システムを備えており、それによって、禁煙ルームやクイーンサイズのベッドなどの、顧客の好みをこれらのホテルが蓄積していることが知られている。これらのホテルが過去に行わなかったことは、1つ以上のお気に入りの映画、お気に入りの食べ物と飲み物、音楽（曲、アルバム、またはアーティストなど）を含むリストなどのユーザの好みを収集することである。このように、図においては、現在のプロセスは、顧客サインアップステップ2702から開始して、ユーザの好みの収集2704がこれに続く。ホテルは、その後、先に説明したタイプのリコメンダソフトウェアを使用して、この特定の顧客に相応しい推奨を、収集される個別の好みに基づいて特定する（ステップ2706）。最後に、これらの推奨は、種々のチャネルを通じて顧客に提供することができる。例えば、これらの推奨は、記録された電話メッセージ、ホテルの部屋のテレビシステム、電子メールまたは無線による電気通信メッセージを通じて、ユーザに単純に配信される。別の方法として、ユーザは、都合によって携帯電話などのデバイスを使用して、要望どおりホテルの推奨にアクセスする。例えば、ユーザが昼食に行く準備ができているとき、ユーザは単純に昼食のレストランに関するホテルの推奨にアクセスすることができる。おそらく、推奨は、ユーザの個人的な好みと一致するであろう。

本発明の別の局面では、リコメンダ技術を使用して、そのユーザのプロファイルに基づいて個々のユーザに1つ以上のベニューを推奨する。図28の簡略化されたフロー図を用いて、ベニューをユーザに推奨する方法の概要を示す。図28は、ユーザログインステップ2802から開始する。このステップは、既存のプロファイルにアクセスすることができるように、ユーザがすでに「メンバー」となっている既存のシステムにログインすることを含む。一方、新規のユーザは、ログインするときにプロファイル情報を提供することができる。音楽または他のメディアアイテムの場合、すでに説明したように、ユーザの好みは、1つ以上のお気に入りの曲またはアーティストを特定することによって表現することができる。図28のステップ2804は、既存のユーザプロファイルにアクセスする場合を示す。

次に、この方法は、ベニュープロファイル情報へのアクセスを要求する（ステップ2808）。重ねて、メディアアイテムの場合、ベニュープロファイルは、システムにログインした現在のユーザとともに提供される現在のメディアアイテムから成る。さらに以下で説明されるように、これはベニューに現在出席しているユーザまたは「ゲスト」を参照する。ベニューによって提供されるメディアアイテムは、適切な時期に順序付けられ、結果として一連のメディアアイテムとなる。例えば、音楽の場合、ベニューによって提供される現在のメディアアイテムはプレイリストである。加えて、ベニュープロファイルは、ロケーション、スタイル、価格帯、始業時間のような一般属性、および静的プロファイル局面を示すその他の特性を含む。

最後に、本システムは、ユーザプロファイルおよびベニュープロファイルに基づいてベニューを推奨する（ステップ2810）。さらに以下で説明されるように、ベニュープロファイルは、ベニューに入出するゲストおよび提供されるメディアアイテムに応じて変化するため、推奨はリアルタイムで行うことができる。本システムは、関連付けられた時間について提供されるメディアアイテムの重要性に重み付けする。この方法では、古いアイテムは最近のアイテムよりも低く重み付けされる。

例えば、ユーザのグループがディスコミュージックにダンスに行きたい場合、彼らは該当するデバイスを使用して、彼らの好きな音楽を現在演奏している最も近いクラブにアクセスすることができる。ユーザは、リアルタイムで現在の再生リストをチェックすることができる。以下に説明されるように、彼らが到着した後、同じユーザは、ベニューで演奏される音楽に影響を及ぼし始めることができる。

図29は、3つの異なる概念レベルでソフトウェアプログラムを示す略図である。実際は、リコメンダコアエンジン2900は、上記のタイプのリコメンダシステム（すなわち、メディアアイテムの入力セット（または、「クエリーセット（query set）」）に応じて新しいメディアアイテムのセットを特定するためのリコメンダシステム）を含む。好適な実施例におけるそのようなシステムは、メディアセットの集まりを含む知識ベースを使用する。

中間の概念レベルでは、図29は、リコメンダコア2900を使用するアルゴリズムのいくつかの例を示す。例えば、ユーザツーユーザ類似性アルゴリズム2902、グループリコメンダ2904、コンポジットプレイリストジェネレータ2906、および動的グループ管理アルゴリズム2908が例として示される。これらのアルゴリズムは、すでに詳細に説明した。最後に、図29のトップレベルに沿って示されるのは、図示されるタイプの1つ以上のアルゴリズムを好んで使用するアプリケーションのいくつかの例である。そのようなアプリケーションは、インタラクティブベニューアプリケーション2910、ベニューリコメンダ2912、提供物を顧客に合わせるためのベニュー用のアプリケーション2914、および１人以上のユーザの個人的な好みまたは利益に対応した他のアプリケーションなどを含む。ベニューリコメンダについては、図28を参照してすでに説明した。ベニューの提供物を特定の顧客に合わせる方法は、図27を参照してすでに説明した。所定のベニューにおいて動的でインタラクティブなエンターテイメントを提供するアプリケーション（2910）について、以下の例を用いてさらに詳細に説明する。
リアルタイムパーティセッション

以下の例は、ベニュー3000の要約の説明から開始する。ベニュー3000は、ディスコ、バー、またはナイトクラブであり、その選択された要素が図30に示される。図30では、ベニュー3000は、数個のスピーカーを有するサウンドシステム3004と、少なくとも1つの表示画面3002と、少なくとも1つのキオスクまたは端末3006とを含む（それぞれ以下にさらに詳細に説明する）。ベニューは、パーティまたはセッションの過程においてゲスト3008の写真を撮るための1つ以上のカメラ3012と、類似した目的で使用される1つ以上のビデオカメラ3014とを任意に含む。ベニュー3000は、多くの場合、飲み物を提供するためのバー3010を含む。ベニュー3000は、無線通信に使用するwifiアクセスポイント3016を含む場合もある。

上述したように、ベニューは、1つ以上の表示画面3002を含む。表示画面3002は、そこに集まったゲストにコンテンツを表示するように配置されている。 表示画面またはスクリーンの数と寸法は重要ではないが、それらは一般にゲストによって容易に視聴されるように配置されるべきである。以下に論じられるように、表示画面3002は、ゲスト間だけでなく、ベニュー所有者または「ホスト」とゲストとの間で双方向通信を行うための主要なメディアを提供する。

図31は、ベニュー表示画面のコンテンツの一例を示す略図である。図31において、表示画面3002は、広告3102（「Bella Terra Bar and Grill」）、およびホスト3104からの歓迎メッセージ（「ようこそ、パーティ参加者様。私たちは今夜あなた方と午前3:00までここにいます。」）を現在表示している。 図31の表示画面例では、「パーティに参加する」方法（すなわち、ここで説明されるインタラクティブシステムにログインする方法）についてユーザに指示する追加のメッセージ3106が表示されている。以下、ベニューシステムに現在ログインしているユーザを「ゲスト」と呼ぶ。図31は、ユーザがログインしてゲストになる2つの方法を示す。第1の方法は、携帯電話などの無線装置から、またはPDAなどの他の多目的デバイスからSMSメッセージを送信することによる方法である。実際、メッセージングは、いずれの無線による電気通信メッセージングが可能なデバイスからも行うことができる。画面表示メッセージは、「PartyStrands J - nickname」のフォーマットを有するメッセージを、所定の電話番号に送信するようにユーザに指示する。この例におけるフォーマットは、[サーバ名、パーティ識別子、ニックネーム]として総称的に記述される。サーバ名（この例では、「PartyStrands」）は、リモートサーバのことを意味する（好適な本実施例においては、図39を参照して後述するような、インターネットを介してアクセスされるリモートサーバである）。「PartyStrands」は、Mediastrands, Inc社の商標である。パーティ識別子（この例では、「J」）は、ユーザが参加したい特定のパーティまたはベニューを特定する。最後に、ユーザのニックネームまたはユーザ名を指定する。提供される電話番号は、必要に応じて短いメッセージを受信およびルーティングすることができる無線による電気通信ゲートウェイなどに対応する。この場合、メッセージは、PartyStrandsサーバにルーティングされる。その後、さらに以下に論じられるように、このメッセージによって、「ニックネーム」のユーザの「パーティJ」へのログインが行われる。別の実施例では、メッセージングプロトコルを単純化するために、特定のベニューに対して専用の電話番号を提供することができる。選択されるメッセージングフォーマットの詳細は重要ではないが、いくつかの例を以下に示す。
A. 説明のためのメッセージフォーマット

本システムへのSMSメッセージは、動作ごとに特定のフォーマットを有する。また、本システムによるユーザのSMSメッセージの受信を確認するために、本システムによって応答メッセージがユーザに送信される。実際問題として、これはユーザに返される応答メッセージである。これによって、キャリアがユーザに請求し、その結果オペレータが収益を受け取る。

(1) Join party（パーティに参加）
特定のパーティとローカルシステムにログインして、本システムに最初のアーティストの好みを提供する。現在演奏されているプレイリストを、本システムが作成に含めるようにする。
メッセージ: <party_name> <user_nickname> <artist_name>
ここで、<party_name>は、画面に表示される、ユーザが参加するベニューまたはイベントの識別子であり、<user_nickname>は次のように使用される。
<nickname> - 匿名のユーザとして参加する。
<mystrands_alias> : mystrands - MyStrandsプロファイル情報を使用して参加する。
<mystrands_alias> : ms - MyStrandsプロファイル情報を使用して参加する（代替フォーム）。
<last fm alias> : lastfm - LastFMプロファイル情報を使用して参加する。
<myspace_alias> : myspace - MySpaceプロファイル情報を使用して参加する。
応答: <text_response>
ここで、<text_response>は、ユーザがパーティに正常に参加したかどうかを記述したテキストメッセージである。このメッセージは、追加の説明情報を任意に提供する。ユーザがパーティに参加したことを本システムがユーザに示したら、ユーザは、追加のSMSメッセージを送信することによって、本システムとやり取りして、他のユーザと通信する。例えば、

(2) Text party（テキストメッセージ）
本システムによって画面上に表示すべきテキストメッセージを送信する。
メッセージ: <party_name> t <text_message>
ここで、<text_message>は、ユーザが送信したい任意のテキストメッセージである。一部の実施例においては、システムは、テキストをスキャンすることによって、いずれの不快な言い回しもそのメッセージが画面上に表示される前に削除する。
応答: <text_response>
ここで、<text_response>は、ユーザのメッセージがシステムによって受け付けられたかどうかを記述したテキストメッセージである。このメッセージは、追加の説明情報を任意に提供する。

(3) Add artist（アーティストを追加）
新しいアーティストを本システムに提案する。本システムが、演奏中のプレイリストを作成プロセスに含めるようにする。
メッセージ: <party_name> a <artist name>
ここで、<text_message>は、ユーザが送信したい任意のテキストメッセージである。一部の実施例においては、システムは、テキストをスキャンすることによって、いずれの不快な言い回しもそのメッセージが画面上に表示される前に削除する。
応答: <text_response>
ここで、<text_response>は、ユーザの提案が本システムによって受け付けられて、プレイリスト作成プロセスに含められたかどうかを記述したテキストメッセージである。このメッセージは、追加の説明情報を提供する。

(4) SMS another user（SMSメッセージを別のユーザに送信）
画面上に表示されるユーザのアバターまたはエイリアスの存在によって示されるような、パーティにログインされた別のユーザに、個人のSMSメッセージを送信する。
1つの実施例においては、ユーザは、対象とする受信者に直接配信するメッセージを、フォームを使用して送信する。
メッセージ:
ここで、<user_nickname>は、ログイン中に本システムに提供される対象とする受信者の名前であり、本システムによって画面上に表示される。<text_message>は、対象とする受信者にユーザが送信したい任意のテキストメッセージである。一部の実施例においては、システムは、テキストをスキャンすることによって、いずれの不快な言い回しもそのメッセージが画面上に表示される前に削除する。
応答: <text_response>
ここで、<text_response>は、ユーザのメッセージがシステムによって受け付けられて、受信者への配信が試みられたかどうかを記述したテキストメッセージである。このメッセージは、追加の説明情報を任意に提供する。

別の実施例においては、ユーザは、説明したようなメッセージを送信するが、ソフトウェア/IPオーナー（Software/IP Owner）4000によって動作するシステムは、対象とする受信者が、配信を要求するメッセージを送信するまで配信メッセージを「保持」する。対象とする受信者は、メッセージが待機状態であることを示すシステムからメッセージを受信した後、そのメッセージの配信を要求するメッセージを返信する。
メッセージ: <party_name> g
ここで、システム/IPオーナー（System/IP Owner）システムが、対象とする受信者からこのタイプのレスポンスを予想するように構成されている場合、<party_name>は任意である。
応答: <text_response>
ここで、<text_response>は、対象とする受信者に配信するためにユーザによって最初に送信された<text_message>である。

前の方式では、ソフトウェア/IPオーナー（Software/IP Owner）は、開始ユーザによって送信されるSMSメッセージのみにリンクしたモバイルキャリアから収益を受け取る。後者において、ソフトウェア/IPオーナーは、開始ユーザによって送信されるSMSメッセージと、開始メッセージの配信を要求する対象とする受信者によって送信されたメッセージの両方にリンクされたモバイルキャリアから収益を受け取る。さらに、パーティに参加しているユーザのアバター3210（図32）は、それらのユーザにどれだけ多くのメッセージが送信されたかを示す数字、および/または配信を要求したユーザに対してどれだけ多くのメッセージが待機状態にあるかを示す数字を表示する。

(5) Vote（投票）
画面に表示される質問に答えて投票を送信する。
メッセージ: <party_name> v <vote>
ここで、<vote>は、「y」、「yes」、「n」、「no」などのユーザの投票である。<vote>は、複数の答えが可能な質問に対する「a」、「b」、「c」または「1」、「「2」、「3」などの識別子であってもよい。
応答: <text_response>
ここで、<text_response>は、ユーザの投票がシステムによって受け付けられ、集計されたかどうかを記述したテキストメッセージである。このメッセージは、追加の説明情報を任意に提供する。

(6) Send Photo/Video to party（写真/ビデオをパーティに送信）
MMSを使用してパーティスクリーン上に表示する写真を送信する。利用可能であればメッセージングプロバイダを通じて送信する。
メッセージ: <party_name> p <photo_file> または <party_name> f <photo file>
ここで、<photo_file>は、MMSサービスによって受け付けられたフォーマットを有するデジタル写真またはビデオファイルである。
応答: <text_response>
ここで、<text_response>は、ユーザの写真またはビデオがシステムによって受け付けられ、集計されたかどうかを記述したテキストメッセージである。このメッセージは、追加の説明情報を任意に提供する。
B. 任意のメッセージングフォーマットおよび方法

1つの好適な実施例では、ソフトウェア/IPオーナー4001（図40）は、専用の電話番号に対応する「非共有ショートコード」のために携帯電話ネットワークオペレータと契約をする。この実施例においては、メッセージ3106（図31）、3212（図32）、3401（図34）、および3506（図35）は以下のフォームを有する。
Send <message> to <short_code>
ここで、<message>は、前述したようにフォーマットされたメッセージであり、<short_code>は、携帯電話プロバイダによってソフトウェア/IPオーナーに提供されたショートコードのテキスト文字列である。このメッセージを受信したとき、携帯電話プロバイダは、テキスト<message>を含むメッセージを、ソフトウェア/IPオーナーにインターネットなどの通信ネットワークを通じて転送する。

別の実施例では、ソフトウェア/IPオーナー4000（図40）は、専用の電話番号に対応する「非共有ショートコード」のために携帯電話ネットワークオペレータと契約をしないが、その代わりに、411Syncなどの共有SMS配信サービス、またはEricssonなどのキャリアによって提供されるサービスを使用する。これらのサービスは、誰もがSMSメッセージを送信してもよい共有電話番号を提供する。SMSメッセージは、一般に、共有SMS配信サービスによる特定のメッセージの配信先である顧客を意味する識別子キーワードから開始する。この実施例においては、メッセージ3106（図31）、3212（図32）、3401（図34）、および3506（図35）は以下のフォームを有する。
Send <ip_owner keyword> <message> to <phone_number>
ここで、<ip_owner_keyword>は、ソフトウェア/IPオーナー4001のサービス用の「fiesta」または「partyStrands」などの識別子であり、<message>は、前述したようにフォーマットされたメッセージであり、<phone_number>は、共有SMS配信サービスの専用電話番号である。このメッセージを受信したとき、共有SMS配信サービスは、テキスト<message>を含むメッセージを、ソフトウェア/IPオーナーにインターネットなどの通信ネットワークを通じて転送する。

図36も、ユーザがベニューにおけるパーティにログインするための代わりの方法を示す。すなわち、ユーザがログインすることが可能な、ベニューに物理的に位置するキオスクまたは端末にアクセスすることである。端末はベニューに位置するため、端末は、「PartyStrands」サーバと通信して、ベニューの識別を自動的に行うようにあらかじめ構成されている。ユーザが必要なのは、ニックネームを提供するだけである。ユーザは、任意に、例えば、好みの曲のトラック、アルバム、またはアーティストの形式でユーザの音楽の嗜好の識別を行う。リモートサーバに格納された既存の音楽プロファイルをユーザが有する場合、お気に入りのアーティストなどの代わりにそのプロファイルにアクセスすることができる。コンタクトをとった手段がSMSであるか端末であるかにはかかわらず、リモートサーバは、ゲストの音楽の嗜好を決定し、所定のパーティへのユーザのログインを行い、そのパーティ用のプレイストリームを作成するアルゴリズムにそのユーザの音楽の嗜好情報を配信する。最後に、図31も、カメラ3012（図30）を使用して時々ベニューで撮影されたピクチャ3108の表示を示す。これは、ゲストまたはホストバーテンダーによって自動的に作動させられる。同様に、ビデオカメラ（図30の参照番号3014）を使用して、表示画面3110用のライブビデオフィードを表示画面3002上で提供することができる。

図32は、パーティセッション中にベニューで使用される表示画面3002の別の説明図である。この図は、上部領域3202、中央領域3204、および下部領域3206の3つの主要領域に分割された表示画面3002を示す。表示画面のこの配置は、単に説明するためのものである。稼動領域の数は重要ではなく、それらの領域のサイズまたは配置も重要ではない。この例では、実例として、上部領域3202は、SMSシステムを使用してパーティにログインすることをユーザに再び勧めるホストメッセージ3212を含む。下部領域3206では、現在再生中の曲が特定される。再生された最後の曲を示したり、潜在的にプレイリストの再生すべき次の曲を示したりすることもできる。曲の識別には、アルバムカバーまたはその他のグラフィクスなどの関連付けられたアートワークを含めることができる。

図32では、中央領域3204には、本システムに現在ログインしているゲストがグラフィック表示されている。望ましくは、ゲストは、実名によって特定されないが、ニックネームまたはエイリアスによって（任意に、グラフィックまたはアバターとともに）特定することができる。アバターは、ゲストのログイン時に、システムによって自動的に提供することができる。ユーザのプロファイルまたはログイン情報から性別を判断できる場合、本システムは、アバターを割り当てるときに、ユーザの性別を考慮に入れる場合がある。

図33を参照すると、表示画面3002の中央領域には、グラフィカルなプレイリストが表示されている。すなわち、現在再生中の曲の指示を含む、いくつかの曲のしるしが表示される。この場合、破線3304によって示される。当然、プレイリスト3300は、プレイリストが実行されるときに動的に更新される。図33に示すこの表示画面は、さらに広告3308を示す。この広告は、ベニューホストの広告収益源である。図33に示す表示画面の下部領域には、バーテンダーのお奨めを指示するホストからのメッセージが表示される（3306）。これらの種々の表示エレメントは、当然これらの図面では静的に示されているが、望ましくは、実際の実装例では、これらの表示エレメントはアニメ化して、内容を頻繁に変化させてゲストの興味を維持するようにする。

図34は、ベニュー表示画面の内容の別の例を示す図である。この図は、１人のゲストが別のゲストにメッセージを送信する概念を取り入れている。図34において、表示画面の上部領域に表示されているメッセージ3400は、ゲストに、別のゲストへメッセージを送信するように勧めている。表示画面の下部領域に表示されているさらなるメッセージは、（SMSなどを使用して）メッセージを送信するようにユーザに指示している。ここで、メッセージは、[サーバ名、パーティ、「MG」、ニックネーム]というフォーマットを有する。この場合、MGは、「ニックネーム」によって特定されるユーザにメッセージを送信する要求を示す任意のコードである。この点では、ユーザが（ゲストになるために）本システムにログインするとき、ユーザは、他のゲストからメッセージを受信したいかどうかの選択肢を与えられる。インタラクティブベニューアプリケーションソフトウェアは、その選択肢を実行するように、またはメッセージを仲介するための他の該当する規則を実施するように構成することができる。

図34も、ユーザがゲストとしてログインするときに表示可能な歓迎メッセージ3404を示す。逆に言えば、ゲストがベニューからログアウトするときに、あいさつ3402を表示することができる。ログアウトは、その趣旨でメッセージを明示的に送信するユーザによって有効にすることができる。別の方法として、ユーザが単にベニューから出る場合、そのユーザから何のメッセージも受信することなくあらかじめ決められた期間が経過した後、ログアウトを自動的に有効にすることができる。言い換えれば、ユーザがベニューから出たことを推論することができる。図32を参照して以前に留意したように、現在ログインしているゲストのリストを時々表示することができる。

図35は、ベニューにいるゲストによって行われる投票の概念を取り入れている。ここで、表示画面3002の中央領域には、プレイリスト3502が表示されている。この場合、現在再生中の曲は参照番号3502である。一方、参照番号3504は、プレイストリームを生成するアルゴリズムによって再生を提案された次の曲として特定される。表示画面の上部領域では、メッセージ3500が、次の曲に投票するようにゲストに勧めている。表示画面の下部では、上述したように、SMSメッセージをあらかじめ決められたゲートウェイに送信することによって、メッセージ3506が、興味を持ったゲストに次の曲に投票するように指示している。

図36は、提案された曲3504に投票するまでの時間が限られていることをゲストに思い出させるメッセージ3600を示す図である。投票が行われたとき、任意に、リアルタイム投票結果3604を表示することができる。図36も、歓迎メッセージ3602を示しており、新しいゲストが最近ログインしたことを反映している。表示画面の下部領域において、現在再生中のトラックもメッセージ3606によって特定される（曲のタイトル3608）。

図37では、ゲストに投票の残り時間を思い出させる追加のメッセージ3700が再び表示される。前述した種々の画面表示例は、単に説明するためのものであることに留意すべきである。上述のコンテンツまたは類似したコンテンツを示すために、他の配置を使用することができる。望ましくは、実際の画面表示は、色彩豊かにして、アニメ化して、頻繁に変更される。読者は、画面表示、およびベニューで演奏される音楽の選択は、そのベニューにログインしているユーザによってなされることを理解するであろう。図38は、ベニューで表示することができるコンテンツのタイプをいくつか要約した図である。これらはすでに説明したため、ここでは繰り返さない。これらは図面の中で明らかである。ここで図39を参照する。図39は、本発明の局面による、主要な接続の一例およびベニューにおける動的なインタラクティブエンターテイメントの実装に関わるデータフローパスを示す略図である。図39では、横の破線は、ベニューから遠く離れた機器および人々から（横の破線の上方に示されている）、図の下半分に示されるベニュー3000に位置するコンポーネント（および人々）を分離する。

図の中央近くには、オンサイトホストシステム3900が示される。このオンサイトホストシステム3900としては、従来のコンピュータ、またはここで説明される目的に特化した特殊用途コンピュータが可能である。ホストシステム3900は、コンピュータプログラム（すなわち、インタラクティブベニューアプリケーション）を実行して、ここに説明される機能を実行する（すなわち、説明したようなパーティセッションを管理する）。アプリケーションは、ローカルでインストールされるか、またはパーティサーバ3902に関わるクライアントサーバの実装においてインストールされる。好適な実施例においては、以下にさらに説明するように、ホストシステム3900は、いずれにしてもリモートパーティサーバ3902に接続される。説明したように、これはインターネットを通じて接続することができる。ホストシステム3900は、望ましくはベニューサウンドシステム3910を制御することによって、説明したようなソフトウェアアルゴリズムによって生成されるプレイストリームにしたがって選択を再生する。ホストシステム3900は、上述したように1つ以上の表示画面3002を含む表示システム3912を駆動する目的でも接続される。ホストシステム3900は、望ましくは、ベニューに位置する1つ以上の端末3914にも結合される。そのような端末またはキオスクは、種々の機能を提供することができる。例えば、以下の機能を提供することができる。
1. 利用可能な携帯電話を持たないユーザが、端末を使用してベニューにログインすることができる。
2. ユーザは、端末を使用して、遠隔のウェブサイトにアクセスすることができる。遠隔のウェブサイトでは、1つ以上のプレイリストを更新することによって、ユーザの好みプロファイルを間接的に調節することができる。
3. 端末またはキオスクを使用して、選択された音楽トラックを、個人のデバイスまたはプレーヤーにダウンロードすることができる。例えば、ゲストは、ベニューにおいて最近再生された1つの特定のトラックを特に好んで、その時それを買うことに決める場合がある。キオスクは、ベニューにおいてその時間まで再生されたプレイリストを示すことによって、その努力を支援するようにプログラムされる。一部のオンラインサービスは、フリーメディアダウンロードを提供する。
4. キオスクを使用して、パブリックディスプレイにメッセージを送信することができる。または、写真、ビデオ、または潜在的にパブリックディスプレイで使用される他のコンテンツをアップロードすることができる。
5. キオスクを使用して、来るべき選択について投票を行う。
6. キオスクを使用して、インターネット上で音楽サイトにアクセスすることによって、音楽をサーチして、ローカルベニューシステムに入力することができる。この入力は、従来の「要求」のように受信した後に再生されないが、その代わりに、その特定のユーザのプロファイルに対するアップデートとして入力される。言い換えれば、ベニューで再生されるトラックの進行中の選択にそのゲストがどのように影響を及ぼすかを変更する。

ホストシステム3900は、前に述べたような1つ以上のカメラ3916、および/または同様の目的の1つ以上のビデオカメラ3918に結合させることもできる。一部のアプリケーションでは、照明制御システム3920も、ホストシステム3900とのインタフェースがとられており、ベニュー照明システムと演奏される音楽とを連携させる。

図39において、枠3930は、望ましくはSMSまたは同様のメッセージングシステムを使用して、ホストシステム3900への入力としてゲストが送信できるメッセージのタイプの例をまとめたものである。好適な実施例においては、これらのメッセージは、無線電気通信ゲートウェイ3932で受信された後、参照番号3934を介してパーティサーバ3902にルーティングされる。パーティサーバ3902は、破線3940によって示されるように、必要に応じてこれらのメッセージを処理してホストシステム3900に情報を渡す。別の実施例においては、メッセージは、「スタンドアローン」構成のホストシステム3900に直接ルーティングされる。このルーティングは、破線3942によって示される。

図39も、自宅または他のベニューにいるリモートユーザ3944を示す。ここでは、リモートユーザは、インターネットを通じた通信が可能なコンピュータまたは無線装置にアクセスする。リモートユーザ3944は、パーティサーバ3902と通信することによって、到着前にベニュー/ホストシステム3900にログインすることができる。すなわち、パーティサーバ3902によって提供されるベニューウェブページにアクセスすることによって、リモートユーザは、ベニュープレイストリームのレコードおよび他のインターアクションを参照したい場合がある。言い換えれば、本発明の別の態様では、オンサイトベニューシステムと、ウェブサイトによってメディエートされた自宅または他のリモートユーザとの間で相互のやり取りを行うことができる。好適な本実施例においては、パーティに参加した（ログインした）後、ゲストは、パーティサーバウェブサイトに行くためのSMS招待状を受信し、都合のよいときにパーティをレビューする。ベニューのパーティ表示システムに表示される内容は、パーティサーバウェブページに送信され、パーティの日と対応している。この情報は、再生されたすべての音楽トラックの一意識別子、ゲストのニックネームとアバター、およびメッセージやピクチャなどのユーザにより作成されたパーティコンテンツを含む。

ゲストは、「PartyStrands」メンバー（ウェブサイトコミュニティ）としてサインアップして、ベニューウェブページにコメントを追加したり、パーティの出席者としてリストとされた他のPartyStrandsメンバーにメッセージを送信したりすることができる。さらに、PartyStrandsメンバー/ゲストは、彼ら自身のPartyStrands/パーソナルウェブページを有する。PartyStrandsメンバー/ゲストは、このウェブページから、他のメンバー/ゲストに対するメッセージの送受信を行うことができる。

図34について上述したように、本システムによって、ゲストは、パーティにいる別のゲストに個人的なメッセージを送信することができる。メッセージが送信されるとき、パーティ表示システムに「送信メッセージ」画面を表示することができる。この画面表示は、メッセージの内容を含まない。個人的なメッセージを受信するゲストは、パーティサーバ（3902）システムを通じて任意に返答することができる。好適な本実施例においては、この機能はSMSを通じて実装される。

図40は、本発明によるビジネス方法の1つの例を簡単に示す概略図である。一般に、このビジネス方法では、ホストがソフトウェアアプリケーションを使用して上述したようなパーティセッションを実行したときに生じるSMSとMMS収益の分け前を提供することによって、ベニュー（ホスト）に報酬を与えようとする。詳細に述べると、ベニューホストがパーティセッションを開始して、そのセッションと関連してゲストがSMSやMMSを介して互いに交流し合うたびに、ベニューホストは支払いを受け取る。

図40を参照すると、一番上に示されるエンティティ4000は、本発明の局面を実装するためのコンピュータソフトウェアの開発者または所有者である。いずれにしても、ここで説明したインタラクティブエンターテイメントシステムの作成および使用に向けられた技術と関連する知的財産の所有者、エージェントまたはライセンシーである。すでに詳細に説明したこれらの技術を、図29を参照して簡単にまとめる。本発明のビジネスモデルの一例に従って、ソフトウェア/IPオーナー4000は、ホストシステム（図39の参照番号3900）上で実行可能なインタラクティブベニューアプリケーションを配布して、前述の説明と一貫性のあるベニュー（「パーティ」とも呼ばれる）においてインタラクティブエンターテイメントセッションを実行する。IPオーナー4000は、1つ以上のアフィリエイトまたはディストリビュータ4002を通じて、そのようなソフトウェアを配布する。次に、アフィリエイトは、例えば、複数のベニューホスト4004にソフトウェアアプリケーションを再配布する。

図40には、特定のホスト（ベニュー）4006が、ディストリビュータ4002を通じてアプリケーションを受信するように示されている。別の方法として、ベニューホストは、アプリケーションをダウンロードすることができる。または、アプリケーションをIPオーナー4000から直接取得することができる。前述のように、ホストは、パーティセッション参照番号4012に出席する多数のパーティゲスト4010を含むベニューにおいて、セッション（パーティ）を実行する。すでに論じたように、出席しているゲストは、そのセッション中にSMSおよび/またはMMSを介して、ホストとおよび/またはお互いと相互にやり取りする様々な機会を有する。これは、「SMSトラフィック」4016として示される。

すでに論じたように、SMSトラフィックは、無線キャリアゲートウェイ4018を通じてルーティングされる。そのトラフィックを処理する無線キャリアは、後日、メッセージを送信するゲストに請求4020を行う。それらのパーティゲストは、次に、無線キャリア請求/集金機能4022に対して支払いを行う（直接、またはホームキャリアを通じるなど）。1つの具体例では、その収益の一部、またはより単純にそのようなメッセージの数に基づくお金の総額は、破線4024によって示されるように、無線キャリアによってIPオーナー4000に払われる。IPオーナー4000は、その収益の一部を、ソフトウェアを配布したり、対応するベニューホスト4006をサポートしたりするアフィリエイト4002に分配する。ホスト4006がIPオーナー4000からソフトウェアを直接取得する場合、ホスト4006は、重ねて望ましくは、そのホストによって実行されるパーティセッションから発信されたメッセージの数に基づいて、IPオーナー4000から収益を直接受け取る。

種々の実装例におけるこのビジネスモデルによって、インタラクティブベニューアプリケーションソフトウェアの広範な潜在的に無料の配布が可能になる。その一方で、アプリケーションを受け取る企業（ベニュー）はその使用を促進するように促される。なぜならば、ソフトウェアの該当する使用から生み出される収益を分かち合えるからである。上述したように、一部の実施例においては、アプリケーションソフトウェアは、アフィリエイトを通じて配布される。アフィリエイトは、インストールされるソフトウェアのコピーごとに、またはパーティセッションごとに支払を受ける。パーティセッションは、ホストによって実行されるか、またはソフトウェアの配布先であるベニューにおいて実行される。このビジネスモデルは、無料のソフトウェアの配布を促すだけでなく、アフィリエイトが、彼らのクライアント（ベニュー）と絶えずコンタクトを取り続けて支援を行うように促し、製品の使用を促進する。好適なモデルでは、アフィリエイトは、SMSメッセージの数とMMSメッセージの数に基づいて、またはそのメッセージによって生み出される収益に基づいて、収益の分配も受け取る。
リコメンダの例

以下のセクションでは、個別のメディアセットを推奨するのに用いることができるリコメンダ技術の一例または実装例について詳細に説明する。さらに、すでに論じたように、このリコメンダ技術はユーザのグループに適用することができる。例えば、図2を参照してすでに論じたように、システムは、リコメンダエンジン（それぞれ204、212、および220）を使用して、各ユーザに対応した推奨されたメディアセットを提供する。これらのリコメンダエンジンは、ユーザ嗜好（メディアセット202、210、および218）を処理して、推奨されたメディアセット206、214、および222をそれぞれ作成する。次に、そのようなリコメンダエンジンの一実施例について説明する。他に、例えば、Yahoo!ミュージックリコメンダを使用することができる。

背景として、コンピュータネットワーク（例えば、インターネット）を介した新しいメディア配布チャネルとともに、デジタルメディアアイテムプレーヤーを専用のソフトウェアと組み合わせる新技術は、人々がメディアアイテムを編成および再生する方法を急速に変化させている。メディア産業におけるそのような進化の直接的結果として、ユーザは、特定の瞬間に再生するアイテムを選択するとき、明らかに彼らを圧倒する膨大な数の利用可能な選択肢に直面する。この圧倒的影響は、音楽アリーナで明らかである。ここでは、人々は、曲の非常に大きな集まりから音楽を選択する問題に直面する。しかし、将来、我々は、音楽ビデオ、映画、新しいアイテムなどの他の領域で同様の影響を見つけるかもしれない。

一般に、以下の開示は、ユーザによってグループ化して 「メディアセット」を定義することができるいずれのメディアアイテムにでも適用することができる。例えば、音楽領域では、これらのメディアセットはプレイリストと呼ばれている。ユーザは、プレイリストの中に曲をまとめることによって、膨大な集まりから曲を選択するときに圧倒される問題を解決する。すなわち、特定の状況において曲のセットを単に楽しむ。例えば、ランニング向けのプレイリストを持つことに興味のある人もいれば、料理向けなどのプレイリストを持つことに興味のある人もいる。

異なるアプローチを採用して、個人化された推奨に基づいてユーザが正しい選択肢を選ぶのを手助けすることができる。アプローチの一種としては、人間の専門知識を使用して、メディアアイテムを分類した後、これらの分類を使用して、入力メディアセットに基づいてユーザに対する推奨を推論する方法がある。例えば、入力メディアセット内にアイテムxが出現しており、xがyと同じ分類に属している場合、システムは、両方のアイテムが同様のクラスタに分類されるという事実に基づいて、アイテムyを推奨することができる。しかし、このアプローチは、信じられないほど膨大な量の人間の仕事と専門知識を必要とする。別のアプローチは、アイテムのデータ（曲の音声信号、ビデオのビデオ信号など）を分析してから、ユーザの好みと抽出された分析とを一致させるように試みることである。このクラスのアプローチは、技術的な観点から効果的であるとまだ示されていない。

代わりに、我々の技術は、多数のユーザの主観的な判断を利用することによって推奨を行う。ユーザの主観的な判断は、ユーザのプレイリストに反映されている。このようにして、我々は、初期（または入力）メディアセットと相性のよいメディアアイテムを推奨することによって、ユーザによるメディアセットの作成を支援するという課題、または新しい音楽選択を単純に見つけ出すという課題に取り組む。推奨は、本システムの知識ベースのメディアアイテム間のメトリックスを使用して計算される。この知識ベースは、ユーザのコミュニティからのメディアセットの集まりを含む。（以下に説明されるように、メディアセットは、メディアアイテムまたはコンテンツの集まりではない。むしろ、そのようなアイテムのリストであり、種々のメタデータを含む） 望ましくは、本発明の方法は、コンピュータソフトウェアで実現される。

商用アプリケーションでは、現在の技術の特徴は、種々の方法で導入することができる。リコメンダサービスは、例えば、ほとんどすべての種類（有線または無線）のネットワークを介して、クライアント計算機のリモートユーザに提供することができる。ここで、我々が「計算機」を使用する場合、それらは、携帯電話、PDA、携帯用音楽プレーヤーなどだけでなく、伝統的なコンピュータを含む。システムの知識ベース、データベースは、ユーザからローカルまたはリモートにすることができる。それは、1つのロケーションまたはサーバであってもよく、または種々の方法で配布される。上述したように、リコメンダエンジンを、「集合的なプレイリスト」（すなわち、ユーザのグループがおそらく好むであろうメディアアイテムのリスト）の形成と関連したユーザのグループに適用することができる。

1つの局面におけるリコメンダ技術は、メディアアイテムの入力セットに応じてメディアアイテムのセットを特定するシステムを具体化する。前記システムは、メディアセットの集まりから成る知識ベースを必要とする。メディアセットは、ユーザによって自然にグループ化されるメディアアイテムのセットである。これらのメディアセットは、ユーザの主観的判断と好みを反映する。知識ベースのメディアセットは、アイテム間のメトリックスを定義する。そのようなメトリックスは、知識ベースのメディアセットに含まれるメディアアイテム間の相関の程度を示す。メディアアイテム間における種々の異なるメトリックスは、メディアセットの知識ベースから生成することができる。そのようなメトリックスには、以下の例を含めることができる（ただし、それらに限定されるものではない）。
a）（順序付けされたメディアセットについて）2つのアイテム間のプレコンカレンシー（pre-concurrency）を、所定のアイテムが知識ベースのメディアセット内の他のアイテムに先行する回数として計算する。
b）（順序付けされたメディアセットについて）2つのアイテム間のポストコンカレンシー（post-concurrency）を、アイテムが知識ベースのメディアセット内の別のアイテムに続く回数として計算する。
c）2つのアイテム間のココンカレンシー（co-concurrency）を、アイテムがメディアセット内に一緒に現れる回数として計算する。
d）アーティスト、アクター、日付などの、メディアアイテムと関連付けられたキーワードを考慮することによって、メタデータ類似点を同様に計算する。
e）以前のメトリックスの組合せを役立てることができる。
f）推移性を適用する以前のメトリックスの組合せ。

そのようなメトリックスは、メディアアイテムを他のメディアアイテムと直接関連付ける明示的な形式で表すことができる。入力セットのメディアアイテムごとに、本システムは、最高のメトリックスを有するn個のメディアアイテムを取り出す。これらのメディアアイテムは、候補と呼ばれる。そのため、メディアアイテムの推奨されるセットは、最適化基準を最大化する候補の部分集合である。そのような基準は、本システムの知識ベースのメトリックスを使用して単純に定義することができる。さらに、そのような基準には、以下のフィルタを含めることもできる（ただし、それらに限定されるものではない）。
a）決められたタイプのアイテムのみに推奨を集中させるようにユーザが表現するフィルタ。
b）具体的なアーティスト、年、ジャンルなどの、特定のキーワードベースの基準を満たすアイテムに推奨を集中させるようにユーザが表現するフィルタ。
c）ユーザに対する推奨を個人化するフィルタ。この種のフィルタリングは、ユーザが知っているアイテムのみを推奨すること、またはユーザが知らないアイテムのみを推奨することなどを含む。
リコメンダの定義

リコメンダシステムは、望ましくは、メディアセットの集まりである知識ベースを含む。または、前記知識ベースへのアクセスを含む。メディアセットは、ユーザが集めたメディアアイテムのリストである。メディアアイテムとしては、オーディオ、ビデオ、マルチメディアなど、ほとんどすべてのコンテンツが可能である。例えば、曲、本、新聞または雑誌の記事、映画、ラジオ番組などである。メディアアイテムは、アーティストまたはアルバムでもよい。メディアセットが、一種類のメディアアイテムから構成される場合、このメディアセットは同種メディアセットと呼ばれる。そうでなければ、このメディアセットは異種メディアセットと呼ばれる。メディアセットは、順序付けることができる。または、順序付けないこともできる。順序付けられたメディアセットは、アイテムがユーザによって使用されるシーケンスに関して特定の順番を意味する。（アイテムの性質によって、そのアイテムの再生、表示、読み取りなどが行われる。）好適な実施例においては、メディアセットは、メディアアイテムのリストである（すなわち、メディアアイテムの実際のコンテンツというよりもメタデータである）ことに再び留意する必要がある。その他の実施例では、コンテンツ自体も含まれることがある。望ましくは、知識ベースは、マシンで読み取り可能なデジタル記憶システムに格納される。知識ベースは、データベースを構築、維持、検索するための周知のデータベース技術を使用することができる。

一般に、メディアセットは、ユーザが、純粋に主観的である（または、主観的ではない）何らかのロジックまたは推理にしたがって、メディアアイテムをまとめることを前提としている。例えば、音楽領域では、ユーザがドライブ向けの曲のセットを選択する場合がある。そのため、このメディアセットは、曲の同種メディアセットである。本発明においては、我々も、本、映画、新聞などの他の種類のメディアアイテムについて考慮する。例えば、我々が本について考慮する場合、ユーザは、夏に関する本のリスト、バス乗車に関する本のリスト、および週末に関する本の別のリストを有する。ユーザは、本と音楽を混合させた異種メディアセットを表現することや、リストされた音楽が特定の本と似合っていることを（暗に）表現することに興味を持つ。

メディアアイテムのセットは、メディアセットと同じではない。これらの相違は、主に、アイテムをまとめるユーザの意図にある。メディアセットの場合、ユーザは、メディアセット内のアイテムが、ある意味でユーザの個人的な好みにしたがってよく釣り合っていることを表す。音楽メディアセットの一般例は、プレイリストである。一方、メディアアイテムのセットは、必ずしもユーザの好みを表しているわけではない。我々は、メディアアイテムのセットという用語を使用して、本発明の本システムの出力とともに本システムの入力について言及する。

所定の知識ベースkについてのメディアアイテムi、jのペア間のメトリックMは、kに関してiとjとの間の関係の何らかの程度を表す。メトリックは、「距離」として表される（ここで、より小さな距離値（近接性）がより強い関連性値を表す）。または、メトリックは、類似性として表される（ここで、より大きな類似性値は、より強い関連性値を表す）。これらは、機能的に等しいが、計算は相補的である。最も即時のメトリックは、kのメディアセットのいずれかにアイテムiとアイテムjが一緒に出現した回数を示すココンカレンシー(i, j, k)である。プレコンカレンシー(i, j, k)のメトリックは、kのメディアセットのいずれかに、アイテムiとアイテムjが一緒に出現した（ただし、アイテムiがアイテムjの前に出現した）回数を示す。ポストコンカレンシー(i, j, k)のメトリックは、kのメディアセットのいずれかに、アイテムiとアイテムjが一緒に出現した（ただし、アイテムiがアイテムjの後に出現した場合のみ）回数を示す。以前の定義したメトリックは、アイテムiとアイテムjの即時シーケンスを考慮することにも適用することができる。そのため、本システムは、コ/プレ/ポスト-コンカレンシーメトリックについて考慮しているが、メディアセット内でアイテムiとアイテムjが連続的である（すなわち、メディアセットは順序付けられている）場合のみである。他のメトリックを考慮することができるとともに、以前のメトリックを組み合わせることによって新しいメトリックを定義することもできる。

メトリックは、上記のメトリックのいずれかおよび推移性の適用に基づいて計算される。例えば、アイテムiとアイテムj間のココンカレンシー（co(i, j)）およびアイテムjとアイテムk間のココンカレンシー（co(j, k)）を考慮すれば、co(i, k) = 0であると考えられる。我々は、 別のメトリックを作成して推移性を含めることができる。例えば、d(i, k) = 1/co(i, j) + 1/co(j, k)である。これらのタイプの推移性メトリックは、標準的な分岐限定法サーチアルゴリズムを使用して効率よく計算される。アイテムiとアイテムkがいずれのメディアセットkにも出現しないにもかかわらず、このメトリックはアイテムiとアイテムkと間の関連性を明らかにする。

所定の知識ベースKに対するメトリックMのマトリックス表現は、二次元のマトリックスとして定義することができる。ここで、エレメントM(i, j)は、メディアアイテムiとメディアアイテムj間のメトリックの値である。

所定の知識ベースkのグラフ表現は、ノードがメディアアイテムを表し、エッジがメディアアイテムのペア間にあるグラフである。メディアアイテムi、jのペアは、ラベル付けされ方向付けられたエッジによってリンクされる。ここで、ラベルは、先頭メディアアイテムiと末尾メディアアイテムjを有するエッジに対する類似性または距離のメトリックM（i, j）の値を示す。

本技術の一実施例を、図42に示されるフロー図によって説明する。この方法は、メディアアイテムの入力セット4201を受け付ける。通常の場合、これは、部分的なメディアセットである。すなわち、ユーザがメディアセットの作成を目的として出発点として集めたメディアアイテムのセット（少なくとも1アイテム）である。入力メディアアイテムに最も類似した候補メディアアイテムの第1の集まりは、プロセス4202によって以下のとおり生成される。

前付として、好適な本実施例においては、前処理ステップを実行して、既存の知識ベースの内容を分析する。これは、入力アイテムを受信する前に行うことができる。上述のように、知識ベースは、メディアセットの既存の集まりを含む。知識ベースは、複数のメディアセットを含む。各メディアセットは、少なくとも2つのメディアアイテムを含む。所定のメディアセット内に複数のメディアアイテムが存在することによって、それらのメディアアイテム間の関連性が生じる。

任意の選択されたメトリックに対して、知識ベースの前処理分析を実行することができる。一般に、メトリックは、所定の知識ベース内におけるメディアアイテムのペア間の関連性を反映し、実際にそれを定量化する。プロセスは、すでに述べたココンカレンシーメトリックを使用する例によって説明される。メディアセット内のアイテムごとに、プロセスは、同じメディアセット内のその他すべてのアイテムを特定し、それによって、そのメディアセット内のアイテムのペアをすべて定義する。このプロセスは、知識ベース内のすべてのメディアセットに対して繰り返される。このようにして、知識ベースに含まれるいずれかのメディアセットに出現するアイテムのペアは、すべて定義される。

次に、メディアアイテムの各ペアについて、同じ知識ベース内で同じアイテムのペアが追加で発生するたびにココンカレンシーメトリックをインクリメントする。例えば、メディアアイテムのペア（例えば、Billy Joelによる「Uptown Girl」という曲とJeff Buckleyによる「Hallelujah」という曲）が知識ベース内の42の異なるメディアセットに同時に出現した場合（必ずしも互いに隣接している必要はない）、ココンカレンシーメトリックは42である（または、選択されるスケーリング、正規化などによっては何か他の数字である）。一部の実施例においては、この数字（すなわち、ココンカレンシーの「重み」）は、0と1の間の数に正規化される。

ここで図41Aを参照すると、マトリックス4100は、任意の特定のメトリックに対するメトリック値または重みを保存するための有益な方法を示す。ここで、知識ベース内の個々のメディアアイテム（例えば、m₁、m₂、m₃、 m_k）は、マトリックス内の対応する行と列に割り当てられている。このマトリックス内では、すべてのアイテムペアについて選択されたメトリック重みは、ペアを定義する2つのメディアアイテムに対応する行と列のロケーション(x, y)に入力される。図41Aでは、値は正規化されている。

ここで、我々は、メディアアイテムの入力セットが受信されると仮定する（ステップ4201）。再びプロセスステップ4202を参照すると、図41Aのマトリックス4100のようなメトリックマトリックスに基づいて、入力メディアアイテムに最も類似した「候補メディアアイテム」の集まりが生成される。例えば、各メディアアイテムについて（例えば、入力セット4201内の（アイテムm₂））、プロセス4202は、メディアアイテムm₂に対するメトリックマトリックス4100の対応する行4102内の、ゼロ以外の類似性値を有するかまたはあらかじめ決められたしきい値を超えたすべてのメディアアイテム（図41Aのm₁、m₃、 m_k）を、メディアアイテムの候補の集まりに追加することができる。この場合、追加される各メディアアイテムには、対応するメトリック値をラベル付けする（それぞれ、0.7、0.4、0.1）。図41Bのグラフにおけるエッジを参照のこと。サイズmの入力セット内の各メディアアイテムについて、プロセス4202は、n個のメディアアイテムを候補として選択する。このようにして、すべての候補の集約によって、最高でもm*n個のメディアアイテムから成るセットが生成される。

1つの実施例においては、プロセス4203は、最高でもm*n個のメディアアイテムを含む候補セットをプロセス4202から受け取る。このコンポーネントは、候補セットのm *n個のアイテムからp個のエレメントを選択する。この選択は、種々の基準にしたがって行うことができる。例えば、本システムでは、候補は、候補セットを生成したメディアアイテム配布にしたがって選択されるべきであると考える。この配布方針を使用することによって、非常に少ないメディアアイテムから多数の候補が生じるのを避けることができる。さらに、本システムでは、候補セット内のメディアアイテムの人気を考慮している。知識ベースに関するメディアアイテムの人気は、知識ベースのメディアセットにおけるそのようなメディアアイテムの頻度を示す。

最後に、メディアアイテムの第2の集まり[p]から、何らかの所定の数のメディアアイテムの第3および最終の出力セット4205が選択される。この出力セット4205は、フィルタプロセス4204によってすべての追加の所望の外的制約に適合する。例えば、このステップによって、メディアアイテムの最終セットが、最終セットのメディアセット間のメトリックと確実に釣り合うようにすることができる。例えば、本システムは、結果として生じるメディアアイテムの各ペア間でメトリックの合計を最大化する。計算の費用が高すぎるとき、場合によっては、本システムは最適化技術を使用することがある。このステップには、個人化、またはユーザによって表されるその他の好みなどのフィルタリング基準も考慮に入れることもある。一部のアプリケーションでは、何らかの想定される計算処理上の制約のために、これらのフィルタリングステップは、プロセス4204ではなくプロセス4203において実行される。その他の実施例におけるフィルタリングは、ジャンル、10年または年の生成、ベンダーなどを含む。さらに、フィルタリングを使用して、候補出力アイテムを削除するというよりも降格させることができる。

本発明の別の実施例または局面においては、図41Bのグラフ形式に示されるように、本システムに知られているメディアアイテムのフルセットの部分集合間における類似性値を含む、明示的な関連性が使用される場合がある。図41Bは、方向付けられたグラフ4300の一部を示しており、様々なメディアアイテムを反映する（参照番号4302またはm₁、参照番号4304またはm₂、参照番号4308またはm_kなど）。エッジ4306は、m₁からm₂までの類似性値（0.1）を示す。例えば、一般にインデックスiによって以下に示される第1のメディアアイテム4302と、一般にインデックスjによって以下に示される第2のメディアアイテム（例えば、参照番号4314）との間の類似性値が明示的に指定されていない場合、代わりに暗黙の類似性値を、方向付けされたパスに従うことによって導き出すことができる。この場合、方向付けされたパスは、第1のメディアアイテムから中間アイテム、そして最終的に関心のある第2のメディアアイテム（この例では、アイテムMp）に至るエッジ4310およびエッジ4312によって表されるパスなどである。中間アイテムは、このようにいくつでも通過することができる。我々は、これを推移的技術と呼ぶ。グラフ上のこの経路に沿ったメディアアイテムのペア間における類似性値のリスト（M(i, i + 1), M(i + 1, i + 2), , M(i + k, j)）は、結果として得られる値が、アプリケーションにとって相応しいメディアアイテムiとメディアアイテムjとの間の類似性の定義を満足させるように組み合わされる。例えば、類似性M（i, j）は、次のように計算される。
M(i, j) = min{M(i, i + 1), M(i, i + 2), … , M(i + k, j)}
または
M(i, j) = M(i, i + 1) * M(i, i + 2) * … * M(i + k, j)

第1のメディアアイテムiと第2の（隣接していない）メディアアイテムjとの間の経路に対する類似性値M(i, j)を計算する他の方法を使用することができる。ここで、エッジは、類似性値のシーケンスでラベル付けされる（M(i, i + 1), M(i + 1, i + 2), ... , M(i + k, j)）。ユーザの観点から、これは、同じメディアセット内で出現しないアイテムのペアに対して関連性メトリックを決定することに相当する。

上記の説明は、その好適な実施例を含む本発明について十分に開示する。さらに詳述することなく、当業者は、前述の説明を使用して本発明を最大限に利用することができると考えられる。したがって、ここに開示される例および実施例は、単に説明するためのものであり、本発明の適用範囲を決して制限するものではないと解釈される。

本発明の基本的な原則から逸脱することなく、上記の実施例の詳細に数多くの変更を加えてもよいことは当業者にとって明白なことである。したがって、当然のことながら、本発明は開示された具体的な実施例に限定されるべきではなく、また、修正およびその他の実施例は、添付された特許請求の範囲内に含められるように意図されている。例えば、当業者は、ここに開示される実施例の様々な局面は、複数のメディアプレイバックデバイス上の集合的なグループ嗜好からコンポジットプレイリストを作成および共有するすべてのシステムで使用することができることを理解するであろう。

したがって、本発明の適用範囲は、以下の特許請求の範囲のみによって決定されるべきである。

ユーザのプレイリストおよびプレイカウントを分析することによって、ユーザの嗜好を合成するシステムの一実施例を示す図である。 複数のユーザからの嗜好分析を使用して、複数の推奨メディアセットを生成するシステムの一実施例を示す図である。 複数のユーザからの推奨メディアセットを使用して、ユーザのグループ向けの推奨メディアセットを生成するシステムの一実施例を示す図である。 本発明によるクライアントサーバ型実施例のシステム図である。 本発明によるピアツーピア型実施例のシステム図である。 一実施例によるデバイスマネージャの主要な機能コンポーネントを示す。 一実施例によるデバイスマネージャのセッションマネージャサブコンポーネント内におけるデータ構造に関連する詳細情報を表示する、セッションマネージャのメンバーステータス画面を示す。 一実施例によるデバイスマネージャのセッションマネージャサブコンポーネントの動作を示すトップレベルのフロー図である。 図8のセッションマネージャフロー図における「プルーンセッションメンバー」ステップを示すさらに詳細なフロー図である。 図8のセッションマネージャフロー図における「アップデートセッションメンバー」ステップを示すさらに詳細なフロー図である。 図8のセッションマネージャフロー図における「サービスプロキシリクエスト」ステップを示すさらに詳細なフロー図である。 一実施例によるデバイスマネージャのプレイリストマネージャサブコンポーネント内におけるデータ構造に関連する詳細情報を表示する、プレイリストマネージャのプレイリストキュー画面を示す。 一実施例によるデバイスマネージャのプレイリストマネージャサブコンポーネントの動作を示すフロー図である。 メディアプレーヤークライアントの実施例における、プレイリストマネージャのプレイリストプレイサブコンポーネントの動作を示すフロー図である。 本システムのプレイリストビルダコンポーネントをサポートするメディアプレーヤークライアントの一実施例における、関連するデータ構造を示す。 一実施例によるプレイリスト作成機能の概念図を示す。 本システムのプレイリストビルダコンポーネントの一実施例における動作を示すフロー図である。 ユーザ嗜好を定義するメディアアイテムのリストを生成するプロセスの図である。 集約されたプレイリスト目標と、所望のカテゴリのリストとを計算するプロセスの図である。 すべての利用可能なメディアアイテムからユーザごとの関連メディアアイテムを計算するプロセスの図である。 所望の属性にしたがって関連メディアアイテムを分類するプロセスの図である。 合成的な目標に対する現在のグループプレイリストの達成のステータスを計算するプロセスの図である。 合成的な目標の達成評価にしたがって要望を評価することに基づき、グループプレイリストに追加するメディアアイテムのセットを選択するプロセスの図である。 新しいユーザを検出するためのユーザ追加プロセスのステップを示す。 新しいユーザが本システムに追加されるとともに、ソースデバイス情報が格納されるユーザ追加プロセスの別のステップを示す。 本システムからユーザを削除するプロセスの図である。 商業施設またはベニューが、その提供物を個々の顧客の嗜好に合わせるプロセスの一例を簡単に示すフロー図である。 商業施設またはベニューを、潜在的顧客またはグループに推奨するプロセスの一例を簡単に示すフロー図である。 リコメンダコアエンジン、前記コアエンジンを使用する種々のアルゴリズム、前記1つ以上の種々のアルゴリズムを使用する説明的アプリケーションを示すソフトウェア概念図である。 ベニューで見られる機能および機器のいくつかを示す略図である。これらの機能および機器は、本発明の局面にしたがって使用されることにより、リアルタイムでユーザ嗜好に対応する、ベニューにおける動的なインタラクティブエンターテイメントを提供する。 広告、ホストの歓迎メッセージ、ピクチャ、および無線電気通信メッセージサービスを使用したユーザに対するパーティへの参加指示などを含む、ベニュー表示画面のコンテンツの一例を簡単に示した図である。 対応するニックネーム、およびシンボルまたはアバターによって、現在ログインしている各ゲストを特定する現在のゲストのリストなどを含む、ベニュー表示画面のコンテンツの一例を簡単に示した図である。 以下でさらに十分に説明する種々の局面および機能を含む、ベニュー表示画面のコンテンツの追加の例を簡単に示した図である。 以下でさらに十分に説明する種々の局面および機能を含む、ベニュー表示画面のコンテンツの追加の例を簡単に示した図である。 以下でさらに十分に説明する種々の局面および機能を含む、ベニュー表示画面のコンテンツの追加の例を簡単に示した図である。 以下でさらに十分に説明する種々の局面および機能を含む、ベニュー表示画面のコンテンツの追加の例を簡単に示した図である。 以下でさらに十分に説明する種々の局面および機能を含む、ベニュー表示画面のコンテンツの追加の例を簡単に示した図である。 ベニュー表示画面のコンテンツを、いくつかの例にまとめた略図である。 接続の一例と、ベニューにおける動的なインタラクティブエンターテイメントの実装に関わるデータフローパスとを示す略図である。 本発明の一実施例によるソフトウェア配布、ライセンス供与、および収益分配のビジネス方法の一例を示す略図である。 メディアアイテムの集まりの間における類似性値を説明する、メトリックのマトリックス形式を表す。 メディアアイテムの集まりにおける関連性を示す、重み付けしたグラフである。2つのメディアアイテム間の各エッジは、これらのメディアアイテム間の類似性に対するメトリックの値を表す重みの注釈がついている。 本発明の実施例による、メディアアイテムの初期セットに対応したメディアアイテムのセットを選択するための1つの方法を示すブロック図である。

Claims (14)

1. コンピュータにより実施される方法であって、
   ユーザのコミュニティからユーザの部分集合を有するユーザグループを形成するステップと、
   各ユーザメディアセットがそれぞれ複数のメディアデータアイテムを含む、前記ユーザグループ内のユーザの複数の個々のメディアセットから動的なグループプレイリストを生成するステップとを有し、
   前記生成するステップは、
   前記ユーザメディアセットの内の第１のユーザメディアセットについて嗜好分析を実行することによって、前記第１のユーザメディアセットから第１のサブメディアセットを生成するステップと、
   前記ユーザメディアセットの内の第２のユーザメディアセットについて嗜好分析を実行することによって、前記第２のユーザメディアセットから第２のサブメディアセットを生成するステップと、
   前記第１および第２のサブメディアセットからメディアデータアイテムを集約することによって、前記ユーザグループについて最適プレイリスト特性のセットを生成するステップと、
   前記第１のサブメディアセット及び前記第２のサブメディアセットにおけるメディアデータアイテムのココンカレンシーに基づくとともに、前記ユーザグループについての前記最適プレイリスト特性に基づいて、グループプレイリストにメディアデータアイテムを追加するステップとを含み、
   第１のユーザ及び第２のユーザについてのユーザ嗜好データは、接続されたデバイスのネットワークに所与のユーザがログインして前記ユーザグループに参加することに応じて検索される
   ことを特徴とする方法。
2. 前記メディアデータアイテムは、再生可能なメディアファイルを含むことを特徴とする請求項１に記載の方法。
3. 前記メディアデータアイテムの各々は、再生可能なメディアファイルを特定するメタデータを含むことを特徴とする請求項１又は２に記載の方法。
4. 前記第１のユーザ嗜好分析に基づいて、前記第１のユーザ向けの推奨メディアセットを生成するステップと、
   前記第２のユーザ嗜好分析に基づいて、前記第２のユーザ向けの推奨メディアセットを生成するステップとを更に含むことを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. 前記推奨メディアセットの各々は、再生可能なメディアファイルを特定するメタデータを含むことを特徴とする請求項４に記載の方法。
6. 前記メディアデータアイテムを集約するステップは、個々のメディアデータアイテムを、それが出現するサブメディアセットの数によってランク付けするステップを含むことを特徴とする請求項１乃至５の何れか１項に記載の方法。
7. 前記グループプレイリストは、曲を含むメディアデータアイテムを含むことを特徴とする請求項１乃至６の何れか１項に記載の方法。
8. 前記メディアデータアイテムを集約するステップは、前記ユーザグループの効用関数を最適化するメディアデータアイテムのセットを選択するステップを含むことを特徴とする請求項１乃至７の何れか１項に記載の方法。
9. 前記効用関数は、個々のメディアデータアイテムと関連付けられた重みに基づくことを特徴とする請求項８に記載の方法。
10. 前記ユーザグループの効用関数を最適化するメディアデータアイテムのセットを選択するステップは、選択されたメディアデータアイテムの重みの合計を最大化するようメディアデータアイテムのセットを選択するステップを含むことを特徴とする請求項９に記載の方法。
11. 選択されたメディアデータアイテムの重みの合計を最大化するよう前記メディアデータアイテムのセットを選択するステップは、複数のユーザメディアセット内の複数の異なるメディアデータアイテムの各々に対して、最高の重みの合計を最大化するメディアデータアイテムを選択するステップを含むことを特徴とする請求項１０に記載の方法。
12. 前記ユーザグループの効用関数を最適化するメディアデータアイテムのセットを選択するステップは、平均メディアデータアイテム重みの合計を最大化するメディアデータアイテムを選択するステップを含むことを特徴とする請求項９に記載の方法。
13. 前記グループプレイリスト内の前記メディアデータアイテムは、それぞれ前記ユーザグループ内のユーザメディアセットにおいて見つけることができることを特徴とする請求項１乃至１２の何れか１項に記載の方法。
14. 前記ネットワークにログインするステップは、所与のユーザのネットワーク接続されたデバイスが所定の近接状態に入った際に暗黙的に達成されることを特徴とする請求項１乃至１３の何れか１項に記載の方法。

Images