(57)【要約】【課題】  ユーザコミュニティにおいて、関連性のあるユーザを他のユーザに推奨するためのシステムおよび方法を提供する。【解決手段】ある実施形態では、ａ）ユーザが聴いている（そうでなければ、興味のある）音楽（または他のアイテム）、ｂ）ユーザが与えられた音楽（または他のアイテム）の推奨、という２つの異なるデータセットを検討する。いくつかの実施形態では、事前計算方法によって、システムがコミュニティ中のユーザ間でアイテムセットと推奨アイテムセットとを効果的に比較することが可能になる。また、このような比較は、与えられたターゲットユーザに対してどのユーザを推奨するべきかを算定するためにシステムが使用することが可能なメトリクスを含んでいてもよい。【選択図】図１
2009520304.tif 000002
【特許請求の範囲】
【請求項１】
ユーザコミュニティにおいてユーザを推奨するための方法であって、
前記ユーザコミュニティ内で第１のユーザを選択するステップと、
前記ユーザコミュニティ内でユーザセットを選択するステップと、
前記第１のユーザのユーザプロフィールを前記ユーザセットの中のそれぞれのユーザのユーザプロフィールと比較するステップと、
前記第１のユーザに対して推奨ユーザセットを生成するステップと、を含み、
前記推奨ユーザセットは前記ユーザコミュニティ内の少なくともひとりのユーザから構成されることを特徴とする方法。
【請求項２】
前記推奨ユーザセットは、前記ユーザコミュニティ内の複数のユーザを含む請求項１に記載の方法。
【請求項３】
前記第１のユーザを選択するステップは、前記第１のユーザから要求を受信して前記推奨ユーザセットを生成するステップを含む請求項１に記載の方法。
【請求項４】
前記ユーザセットは、前記ユーザコミュニティ中の前記ユーザのそれぞれを含む請求項１に記載の方法。
【請求項５】
前記ユーザプロフィールは、複数のメディアデータアイテムを含んでいるメディアアイテムセットを含む請求項１に記載の方法。
【請求項６】
前記メディアデータアイテムは、複数のメディアアイテムを特定するメタデータを含む請求項５に記載の方法。
【請求項７】
前記推奨ユーザセットを生成するステップは、前記メディアアイテムセット中のメディアアイテムのプレイカウントを分析するステップを含む請求項５に記載の方法。
【請求項８】
前記ユーザプロフィールは、複数の推奨メディアデータアイテムを含んでいる推奨メディアアイテムセットをさらに含む請求項５に記載の方法。
【請求項９】
前記推奨ユーザセットは、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリック、
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリック、のうちの少なくとも１つのメトリックを使用することによって生成される請求項８に記載の方法。
【請求項１０】
前記推奨ユーザセットは、前記ユーザセット中のそれぞれのユーザに対する前記メディアアイテムセットにおけるメディアアイテムのプレイカウントをさらに使用することによって生成される請求項９に記載の方法。
【請求項１１】
前記推奨ユーザセットは、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリック、
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、および
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリックを使用することによって生成される請求項８に記載の方法。
【請求項１２】
ユーザコミュニティにおいてユーザを推奨する方法を実行するためのコンピュータが実行可能な命令を記憶しているコンピュータ可読媒体であって、前記方法は、
前記ユーザコミュニティ内で第１のユーザを選択するステップと、
前記ユーザコミュニティ内でユーザセットを選択するステップと、
前記第１のユーザのユーザプロフィールを前記ユーザセットの中のそれぞれのユーザのユーザプロフィールと比較するステップと、
前記第１のユーザに対して推奨ユーザセットを生成するステップと、を含み、
前記推奨ユーザセットは前記ユーザコミュニティ内の少なくともひとりのユーザから構成されることを特徴とする媒体。
【請求項１３】
前記第１のユーザを選択するステップは、前記第１のユーザから要求を受信して前記推奨ユーザセットを生成するステップを含む請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記ユーザプロフィールは、複数のメディアデータアイテムを含んでいるメディアアイテムセットを含む請求項１２に記載のコンピュータ可読媒体。
【請求項１５】
前記メディアデータアイテムは、複数のメディアアイテムを特定するメタデータを含む請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記推奨ユーザセットを生成するステップは、前記メディアアイテムセットにおけるメディアアイテムのプレイカウントを分析するステップを含む請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記ユーザプロフィールは、推奨メディアデータアイテムの推奨メディアアイテムセットをさらに含む請求項１４に記載のコンピュータ可読媒体。
【請求項１８】
前記推奨ユーザセットは、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリック、
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリック、のうちの少なくとも１つのメトリックを使用することによって生成される請求項１７に記載のコンピュータ可読媒体。
【請求項１９】
前記推奨ユーザセットは、前記ユーザセット中のそれぞれのユーザに対する前記メディアアイテムセットにおけるメディアアイテムのプレイカウントをさらに使用することによって生成される請求項１８に記載のコンピュータ可読媒体。
【請求項２０】
前記推奨ユーザセットは、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、
前記メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリック、
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対するメディアデータアイテムのメディアアイテムセットとの共通部分を分析するメトリック、および
前記推奨メディアアイテムセットと前記ユーザセット中のそれぞれのユーザに対する推奨メディアデータアイテムの推奨メディアアイテムセットとの共通部分を分析するメトリックを使用することによって生成される請求項１７に記載のンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザコミュニティ(user community)においてユーザを他のユーザに推奨するためのシステムおよび方法に関する。
【発明の背景】
【０００２】
以下において、本発明の具体的な好適実施形態の十分な理解のために、プログラミング、ソフトウエアモジュール、ユーザ選択、ネットワークトランザクション、データベースクエリ、データベース構造などについて具体的かつ詳細に説明する。しかしながら、実施形態は１つ以上の要素なしに実施することや、他の方法、構成要素、材料などとともに実施することが可能であることを当業者であれば理解するであろう。
【０００３】
いくつかのケースでは、好適実施形態の特徴が曖昧になることを避けるために、周知の構造、周知の材料、または周知のオペレーションについては詳細に図示や説明がなされていない。さらに、説明されている特徴や構造や特性は、他のさまざまな実施形態において任意の適切な方法で組み合わせることができる。いくつかの実施形態では、ここで説明されている方法やシステムを、パーソナルコンピュータ（ＰＣ）、ラップトップコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、およびあらゆる種類の他の卓上電子機器や携帯用電子機器において一般的に使用されているマイクロプロセッサのような１つ以上のデジタルプロセッサを使用して実行することができる。
【０００４】
ここで、ユーザコミュニティ(user community)においてユーザを他のユーザに推奨するためのシステムおよび方法に関する実施形態を説明する。ここで使用されているように、「ユーザレコメンダ(user recommender)」とはユーザのコミュニティに組み込まれたモジュールであり、主な機能はそのコミュニティにおいてユーザを他のユーザに推奨することである。コミュニティの中には、そのコミュニティのユーザ達が情報をやりとりするためのアイテムのセットが存在していてもよい。また、ユーザに他のアイテムを推奨するためのアイテムレコメンダ(item recommender)が存在していてもよい。ここで説明されている実施形態に関連して使用することが可能なレコメンダシステムの例は、米国特許公開公報第2006-0184558号「メディアアイテムの入力セットおよび知識ベースメトリクスに対応する新たなメディアアイテムのセットを特定するためのレコメンダシステム(Recommender System for Identifying a New Set of Media Items Responsive to an Input Set of Media Items and Knowledge Base Metrics)」、および米国特許公開公報第2006-0173910号「入力メディアセットに対応する新たなメディアアイテムのセットの動的同定(Dynamic Identification of a New Set of Media Items Responsive to an Input Mediaset)」に開示されている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ここで使用されているように、「メディアデータアイテム(media data item)」という語は、あらゆるメディアアイテムもしくはメディアアイテムを表示するものを含むものとする。「メディアアイテム(media item)」は、デジタルメディアフォーマットで表示することが可能なあらゆる種類のメディアファイル、例えば、歌、映画、写真、電子ブック（イーブック）、新聞、テレビ／ラジオ番組、ゲームなどを含むものとする。したがって、「メディアデータアイテム」という語は、例えば再生可能なメディアアイテムファイル（例えば、ＭＰ３ファイル）のほかに、再生可能なメディアファイルを特定するメタデータ（例えば、ＭＰ３ファイルを特定するメタデータ）も含むことを意図している。したがって、「メディアアイテム」を使用したプロセス、ステップまたはシステムを提供する全ての実施形態において、そのプロセス、ステップまたはシステムは、メディアアイテムの代わりにメタデータなどのメディアアイテムを表示するものを使用することができ、その逆もまた同様であることは明らかである。
【課題を解決するための手段】
【０００６】
ユーザレコメンダは、特定のターゲットユーザに対して関連性のあるユーザを選択することが可能である。そのためには、ユーザは比較可能な集団でなくてはならない。コミュニティにおいてユーザを定義する要素を、ユーザプロフィール(user profile)と呼ぶことができる。ユーザプロフィールは以下に説明するような２つのセットを定義することによって定義することができ、２人のユーザを比較することは彼らのユーザプロフィールセットの共通部分を求めるという問題になる。
【発明を実施するための最良の形態】
【０００７】
例えば、図１を参照すると、第１のセットは図１における110で示される「アイテムセット(item set)」であり、このアイテムセットは特定のユーザ118にとって最も関連性の高いアイテム115を含んでいてもよい。第２のセットは図１における120で示される「推奨セット(recommendations set)」であり、この推奨セットはユーザ118にとって最も関連性の高い推奨アイテム(recommended items)を含んでいてもよい。アイテムセット110は、アイテムの使用もしくは特定のユーザと特定のアイテムとの接触から推定することができる。一方で、推奨セットはアイテムレコメンダ130を使用することによって推定することができる。いくつかのケースでは、アイテムセット110はレコメンダ130の入力として使用することが可能であり、それによって推奨セットを出力として得ることができる。
【０００８】
以下の例において説明するアイテムは、音楽アイテム(musical item)や他のメディアアイテム(media item)である。しかしながら、ここに述べる実施形態はアイテムを特定するものではなく、ユーザのコミュニティによって使用／共有される他のあらゆるタイプのアイテムで機能することが可能であることを理解されたし。
【０００９】
音楽アイテムやマルチメディアアイテム(multimedia items)（曲、アーティスト、アルバムなど）に対して、ユーザはそれらのアイテムを使用することによって（聴いたり購入したりすることによって）アイテムと関係を持つことができる。このような実施形態におけるセットは音楽アイテムを含むものであるため「音楽セット(musical sets)」とする。したがって、これらのセットを「ミュージックセット(Music Set)」および「推奨セット(Recommendations Set)」とする。
【００１０】
ミュージックセットは、ユーザが聴いているアイテムによって形成される音楽セットである。ここではユーザＡのミュージックセットをＭａとする。推奨セットは、ユーザが推奨されているアイテムによって形成される音楽セットである。ここではユーザＡの推奨セットをＲａとする。
【００１１】
２つのユーザプロフィールを比較するために、彼らのそれぞれのセット（ミュージックセットと推奨セット）のうちの１つ以上の間の共通部分（共通集合）を分析することができる。また、有益なデータを提供するために、さまざまな異なるメトリクス(metrics)をセットの共通部分に適用することができる。いくつかのこのようなメトリクスはユーザ間の関係を表すものである。例えば、４つの基本の共通ケース(intersecting cases)は、Ｍａ∩Ｍｂ、Ｍａ∩Ｒｂ、Ｒａ∩Ｍｂ、およびＲａ∩Ｒｂである。これらのケースを分析することによって、異なる関係としてラベル付け(labeled)もしくは分類することができる複雑なケースを導くことができる。例えば、一例において、４つの関連性のある関係を抽出することができる。
【００１２】
ピア(Peer)：ＭａとＭｂが十分な共通部分を有する場合、ＢをＡの「ピア」とみなす。
グル(Guru)：ＭａとＲｂ（ＲａとＭｂ）が十分な共通部分を有する場合、ＢをＡの「グル」とみなす。
ピア−グル(Peer-Guru)：ピアの条件にグルの条件が加わった場合、ＢをＡの「ピア−グル」とみなす。
フォロワー(Follower)：ＲａとＭｂ（ＭａとＲｂ）が十分な共通部分を有する場合、ＢをＡの「フォロワー」とみなす。
【００１３】
ピア関係は、ターゲットユーザの音楽ライブラリ(musical library)（もしくは他のアイテムのライブラリ）に何らかの形で類似している音楽ライブラリを有する他のユーザをターゲットユーザに与えるものであるため、関連性のある関係である。グル関係は、ターゲットユーザが発見するのを楽しむ可能性がある音楽を含んでいる音楽ライブラリを有する他のユーザをターゲットユーザに与えるものであるため、関連性のある関係である。ピア−グル関係は、ひとり以上の推奨ユーザ(recommended users)に対するピア関係の類似経験(affinity experiences)とグル関係の発見経験(discovery experiences)の両方をターゲットユーザに与えるものであるため、関連性のある関係である。フォロワー関係は、どのユーザがターゲットユーザによって影響を受ける可能性があるかを知る機会をターゲットユーザに与えるものであるため、関連性のある関係である。
【００１４】
例えば上記の関係を導くことが可能なメトリクスの具体例を以下に示す。メトリック(metric)は、２つ（もしくはそれ以上）のユーザプロフィールを入力として取り込み、測定可能な結果を出力として生成する関数であってもよい。以下に説明するメトリクスは一方向性であり、つまりパラメータの順序によって結果を変えることが可能である。
【００１５】
「アフィニティ(Affinity)」メトリックは、「ＭａはどれだけＭｂと共通しているか」という質問、言い換えれば、「ユーザＡはどれだけの類似経験(affinity experiences)をユーザＢに対して有しているか」、という質問に返答するものである。
【００１６】
「ディスカバリ(Discovery)」メトリックは、「ＲａはどれだけＭｂと共通しているか」という質問、言い換えれば、「ユーザＡはどれだけの発見経験(discovery experience)をユーザＢに対して有しているか」という質問に返答するものである。
【００１７】
「ガイダンス(Guidance)」メトリックは、「ＭａはどれだけＲｂと共通しているか」という質問、言い換えれば、「ユーザＡはどれだけユーザＢを導くことができるか」という質問に返答するものである。
【００１８】
これらのメトリクスを使用して、アフィニティメトリックを最大化させることによってピア関係を求めることができ、ディスカバリメトリックを最大化させることによってグル関係を求めることができ、アフィニティメトリックとディスカバリメトリックの両方を最大化させることによってピア−グル関係を求めることができ、ガイダンスメトリックを最大化させることによってフォロワー関係を求めることができる。ひとりのユーザの他のユーザに対する総合的な関連性は、例えば各メトリクス（もしくは１つ以上のメトリクス）を使用して機能する関数を定義することによって計算することが可能である。Ｘ＝アフィニティ、Ｙ＝ディスカバリ、Ｚ＝ガイダンスとするとき、ターゲットユーザに対してコミュニティ中の他の全てのユーザを三次元空間（「ADG空間」）の中に点として位置づけることができる。メトリクスを０から１の間の数字を返すものとして定義すると、コミュニティ中の全てのユーザをそのADG空間の中の１×１×１の立方体の中に入れることができる。図２において、ADG空間におけるサンプルターゲットユーザＸの位置を示す。
【００１９】
説明されている概念モデル(conceptual model)に従ったユーザレコメンダを実装するために、基礎システム(under-lying system)を構築してもよい。このようなシステムの１つは以下のように構成することができる。
１．ユーザコミュニティおよびアイテムレコメンダが存在し、そのアイテムレコメンダからコミュニティ中の各ユーザのユーザプロフィールを抽出することができる。この情報は１つ以上のデータソースによって提供することができる。
２．モデルのデータおよびオペレーションを構築し、データソースからデータを収集するユーザレコメンダが存在する。
【００２０】
ユーザレコメンダの基本的なアーキテクチャスキーマ(architecture schema)の一例を図３に示す。図示されているように、データソース310はユーザコミュニティ320にデータを供給するとともにユーザコミュニティ320からデータを受信する。また、データソース310はユーザレコメンダ330にデータを供給する。ユーザレコメンダ330はユーザコミュニティ320と情報をやりとりする。具体的には、ユーザ推奨(user recommendations)の要求をユーザコミュニティ320から受信し、推奨ユーザ(recommended users)を順々にコミュニティ320に供給することができる。もちろん、いくつかの実施形態ではユーザからの要求を受信することによって推奨ユーザのセットを生成してもよく、他の実施形態では最初にユーザの要求を受信することなく推奨ユーザのセットを生成してコミュニティ中のユーザに提供してもよいということが考えられる。
【００２１】
また、拡張可能なアーキテクチャソリューション(architecture solution)を提供することが望ましい。要求を考慮すると、ターゲットユーザをコミュニティ中の全てのユーザと比較することは、ユーザの数によって応答時間が直線的に増加することが予想されるため実行できない可能性がある。この問題については多くの解決策を実行することができる。例えば、以下のような方法が考えられる。
１．ユーザデータをクラスタ化(clusterized)してターゲットユーザと適切なクラスタ（集団）とを比較することができる。
２．一定数のユーザのサブセットをユーザコミュニティから選択することができる。このユーザのサブセットは「推奨可能ユーザ(Recommendable Users)」と呼ぶことができ、ターゲットユーザとこの一定サイズのサブセットとを比較することができる。推奨可能ユーザはいくつかの手順によって選択することができ、この手順によってシステムがコミュニティ中の最も興味深いユーザを推奨することが可能になる。
【００２２】
Ｎを全世界における音楽アイテムの総数とするとき、音楽セットエンティティ(musical set entity)をＮ次元空間のスパースベクトルとしてモデル化することができる。それぞれの次元は異なるアイテムを表しており、一方でそれぞれの具体的数値はそのアイテムの関連度を表している。各アイテムに関連値(relevance value)を加えることで、基礎システムの実施が特定のユーザに対して最も関連性の高いアイテムを認識することが可能になる。
【００２３】
いくつかの実施形態では、アイテムを音楽の曲とすることができる。しかしながら、このような実施形態では、スパース問題(sparsity problem)のために２つのユーザセットにおけるアイテムどうしが共通する可能性は低い。さらに、このような共通部分は計算コストが高くなる可能性がある。
【００２４】
いくつかの実施形態では、曲の代わりにアーティストレベルで検討することによりこれらの問題に対処することができる。曲に比べてアーティストが共通する可能性の方が高い。一方で、関連値はアイテムが抽出されるデータソースによって決定されてもよい。したがって、全ての関連値が定性値スケール(qualitative value scale)のような既知の価値スケールに最終的に属するように正規化（標準化）プロセス(normalization process)を使用することができる。
【００２５】
例えば、図４はアーティストなどの特定のアイテムの特定のユーザに対する関連性を示す定性値スケールを表している。特定のユーザに対してＣ１未満の関連値を有するアーティスト（もしくは他のアイテム）を「Ｌｏｗ（低）」、Ｃ１からＣ２の間の関連値を有するアーティストを「Ｍｅｄｉｕｍ（中）」、Ｃ２からＣ３の間の関連値を有するアーティストを「Ｍｅｄｉｕｍ／Ｈｉｇｈ（中／高）」、Ｃ３を超える関連値を有するアーティストを「Ｈｉｇｈ（高）」とみなす。
【００２６】
標準化（正規化）プロセスの詳細および具体例は、特定のアイテムの特定のユーザに対する関連性を求めるための他の方法とともに後述する。
【００２７】
ユーザエンティティ(user entity)は、固有の識別情報（ＩＤ）に２つの音楽セットエンティティを加えたものを有するエンティティとしてモデル化することができ、それによってここで説明している概念モデルに従って共通部分を計算するために必要とされる全てのデータを有することができる。
【００２８】
ここで、本発明のいくつかの実施形態において実行することができるいくつかの演算について説明する。基本の演算は、２つのユーザエンティティを比較する必要があり、音楽セット間の共通集合を含むものである。例えば、
１．音楽セットのサイズは、ＭｕｋをセットＭｕにおけるアイテムｋの関連値とする場合、以下のように表すことができる。
【００２９】
【数１】
2009520304.tif 000003
２．ＭｕとＭｕ’において共通の全ての音楽アイテムに対して、共通部分のサイズは以下のように表すことができる。
【００３０】
【数２】
2009520304.tif 000004
３．アフィニティメトリック、ディスカバリメトリック、およびガイダンスメトリックは以下のように表すことができる。
【００３１】
アフィニティメトリックに対する１つのアプローチは、以下のようにＭｕとＭｕ’の共通部分のサイズを計算し、それをＭｕのサイズによって正規化（標準化）するものである。
【００３２】
【数３】
2009520304.tif 000005
他の方法として、ＲｕとＲｕ’の共通部分が何らかの形で類似性（アフィニティ）の尺度になると考えた場合、この要素を全体の公式に加えることができ、それを因数Ｋによって加重することによりその尺度を正規化（標準化）する。
【００３３】
【数４】
2009520304.tif 000006
ここで、ＵがＵ’に対して高い類似性を有していることは、必ずしもＵ’がＵに対して高い類似性を有していることを意味するものではない。
【００３４】
ディスカバリメトリックおよびガイダンスメトリックに対応する公式は以下のとおりである。
【００３５】
【数５】
2009520304.tif 000007
ここで、Discovery(U,U’)=Guidance(U’,U)が常に成り立つ。
【００３６】
以下のモデル演算は、ユーザレコメンダにおいて実行することができる大域演算(global operation)の具体例であり、基本演算を利用することによって所望の結果を計算することが可能となる。
【００３７】
− get Best Users (User, Requirement):
特定のメトリクスのセットを計算することによって、推奨ユーザのセットをターゲットユーザに対して返すことができる。必要条件(Requirement)は、どのタイプのユーザを推奨するか、またどんなメトリクスを検討するかを特定することができる。この関数の一般的アルゴリズム(general algorithm)は以下のとおりである。
１．TUをターゲットユーザ(Target User)、RUSを推奨可能ユーザセット(Recommendable Users Set)、REQを要求の必要条件(Requirement of request)とする。
２．RUS中の各ユーザＵに対してREQに従って必要なメトリクス（TU，U）を計算し、その結果をRUS中の比較対象のユーザＵの結果とともに保存する。
３．リストの最初にREQに応じたベストユーザがくるように、比較結果に従ってＲＵＳをソートする。
４．RUSのサブリストに戻り、最初から開始する。
【００３８】
get Relevance (User1, User2):
ユーザ１のユーザ２に対する全てのメトリクスを計算することによって、全てのメトリック値(metric values)でいくつかの計算を実行する関数を計算することにより浮動数(floating number)を返すことができ、「ユーザ２はユーザ１にとってどれだけ関連性があるか」という質問に返答する。この関数は、例えばADG空間におけるベクトルの長さを計算することができる。
【００３９】
ユーザレコメンダはジャバウェブモジュール(Java Web Module)であってもよい。このモジュールは、例えばwebappとしてトムキャット環境(Tomcat environment)に配置することができる。一例において、このような実施形態のデータソースは以下のとおりである。
１．Reach API（Reachアプリケーションプログラミングインタフェース）：各ユーザのプレイカウント(playcount)データを返す。いくつかの実施形態では、このデータから音楽セットを推定することが可能である。
２．UMAレコメンダ（ユニファイドメモリアーキテクチャレコメンダ）：アイテムセットの推奨アイテムを返す。いくつかの実施形態では、例えばユーザプロフィールのミュージックセットを入力として使用してこのデータから音楽セットを推定することが可能であり、その結果上述したユーザプロフィールの推奨セットを得ることができる。
３．Kill Bill API（Kill Billアプリケーションプログラミングインタフェース）：ユーザに関するいくつかの追加情報（例えば、通称名）を返す。
【００４０】
１つの拡張可能な解決策は、Reach APIを通してコミュニティのＮ人のベストユーザを取得し、彼らを推奨ユーザとすることである。いくつかの実施形態では、CLUTOクラスタリングプログラム(CLUTO clustering program)を使用することができる。CLUTOプログラムはオープンソースソフトウェアであり、「http://glaros.dtc.umn.edu/gkhome/cluto/cluto/download」でダウンロードすることが可能である。他の実施形態では、WEKAクラスタリングプログラム(WEKA clustering program)を使用することができる。WEKAもまたオープンソースプログラムであり、「http://www.cs.waikato.ac.nz/ml/weka/」でダウンロードすることが可能である。また、いくつかの実施形態では、ファイルキャッシュシステム(file-cache system)を構築して使用してもよい。
【００４１】
したがって、推奨は全てのユーザに対して実行されるが、推奨されるのはベストユーザのみとすることができる。あるユーザがＮ人のベストユーザのセットの中に存在していない場合、ユーザレコメンダはその後リアルタイムでそのユーザのユーザプロフィールを要求し、データソースに加えることができる。
【００４２】
ジャバ実装(Java implementation)はクラスのセットから構成されていてもよく、そのロジックは以下のように分割することができる。
サーブレット・ビュー(Servlet View)：サーブレットの要求／応答ロジックの全てが入っている場所。
レコメンダ・ビュー(Recommender View)：シングルトンレコメンダ(singleton Recommender)によってメイン演算を実行する場所。多くの場合それらの演算をマネジャー(Manager)に委託する。
マネジャー・ビュー(Manager View)：コアクラス(Core classes)を使用することによって全ての演算を実質的に実行する場所。
コア・ビュー(Core View)：ジャバクラス(Java Classes)のセットによってモデルの基盤を確立する場所。
【００４３】
ここで、前述の「ビュー(View)」についてさらに詳細に説明する。ユーザレコメンダは、ハイパーテキストトランスファープロトコルサーブレット(HTTP Servlets)のセットであってもよい。また、ユーザレコメンダはシングルトンインスタンス(Singleton Instance)であってもよく、図５に示すように、３つの異なるサーブレットによって使用されてもよい。
１．デバッグサーブレット(Debug Servlet)500がデバッグコマンドを処理する。例えば、action=statsのとき、レコメンダ530の内部メモリの統計データのプロットを実行する。
２．レコメンダサーブレット(Recommender Servlet)510が前述のモデル演算に従って推奨要求を処理する。
３．アップデートサーブレット(Update Servlet)520がユーザデータにおいてアップデートプロセスを実行する。
【００４４】
ユーザレコメンダは、主にマネジャー(manager)とリクエストキャッシュ(request cache)によって形成されるシングルトンクラス(singleton class)であってもよい。また、キャッシュへの同時アクセスをセマフォによって制御し、矛盾する情報を避けることができる。例えば、デバッグサーブレットがフラッシュキャッシュコマンド(flush cache command)を送信すると、キャッシュから結果を得るために待機している推奨要求がある場合は、そのフラッシュキャッシュコマンドが実行された後に要求が処理されると空白応答(null response)を受信することができる。
【００４５】
いくつかの実施形態では、リクエストキャッシュにアクセスするための一般的アルゴリズムは以下のとおりである。
１．セマフォが開いている場合はセマフォを閉じ、そうでなければ待機。
２．結果がキャッシュの中にあるか。
３．キャッシュの中にある場合は、キャッシュから結果を取り出す。
４．キャッシュセマフォ(cache semaphore)を開く。
【００４６】
キャッシュはハッシュマップ(Hash Map)により実行してもよい。ハッシュマップのキーは文字列要求ハッシュ(string request hashes)であり、ハッシュマップの値は要求結果である。文字列要求ハッシュを計算して、異なる結果を生成する可能性のある各パラメータセットの固有文字列を得ることができる。
【００４７】
図６はユーザ・ツー・ユーザレコメンダ600の一例およびレコメンダ600とシステム中の他の要素との基本の相互作用(interactions)を示す図である。レコメンダ600はマネジャー610およびリクエストキャッシュ620を有している。マネジャー610は、612で示す１つ以上の外部接続と614で示すデータフィード(data feed)を有している。
【００４８】
図７の700で示すように、マネジャー610はサービス層(service layer)とデータ領域層(dataspace layer)という２つの層を有するシングルトンクラスであってもよい。
【００４９】
サービス層710はサービス712のシングルトンインスタンスを含んでいてもよい。各サービス712を使用して特定タイプのタスクのセットを実行することができる。例えば、データのアップデートを実行するための全てのロジックを含む「アップデートサービス(Update Service)」を提供することができる。また、データ間でコンパレータを実行するための全てのロジックを含む「コンパレータサービス(Comparator Service)」を提供することができる。これらのサービスはデータ領域層720と直接通信していてもよい。
【００５０】
データ領域層720は、外部サービス（UMA 722、 Kill Bill 724、Reach 726など）への全ての接続、および推奨可能ユーザが恒久的に記憶されているメインメモリ構造(main memory structures)728を含んでいてもよい。
【００５１】
いくつかの実施形態の基本クラスは、図８に示すように、ユーザ810、測定ユーザ(MeasuredUser)820、ユーザ類似性(UserSimilarity)830、および必要条件(Requirement)840である。このような実施形態では、ユーザ810の音楽セット850はアイテム854と関連性856のペアのセットであってもよい。アイテムと関連性の一例は、アーティストのＩＤを含むアーティストアイテム(ArtistItem)と１から３の間の大きさを有するシンプル関連性(SimpleRelevance)である。また、アイテムファクトリ(ItemFactory)と関連性ファクトリ(RelevanceFactory)が存在していてもよく、それらのタスクは、アイテムオブジェクトと関連性オブジェクトを生成し、実施の名前を入力として取得することである。このような実施形態では、アイテムと関連性は、他のコアクラスに影響を及ぼすことなくプロジェクトのどのステージにおいても容易に変更することが可能である。
【００５２】
ユーザを他のユーザと比較するとき、比較されるユーザである測定ユーザ820とユーザ類似性830インスタンスが存在する。ユーザ類似性830は、各メトリック860がどれだけターゲットユーザと相関性があるかを特定する。また、クライアントは異なるメトリクスを最大化／最小化させるための必要条件を特定することができる。アフィニティメトリック、ディスカバリメトリック、およびガイダンスメトリックを図８の862、864、および866にそれぞれ示す。
【００５３】
上述したとおり、アフィニティメトリック、ディスカバリメトリック、およびガイダンスメトリックを実装してもよいが、他のメトリクスも同様にインタフェースメトリック(interface metric)を拡張することによって実装することができる。
【００５４】
インタフェースメトリックは、各メトリックが２人のユーザ間の共通部分を求める必要があることを特定し、その結果はパラメータ化することが可能(parametrizable)である。また、インタフェースメトリックは、各メトリックが２人のユーザ間の関連性をそのメトリックに従って測定する計算値を返す必要があることを特定することができる。この値もまたパラメータ化することが可能であり、各メトリックは二重にパラメータ化される(double-parameterized)ことになる。また、計算値は０から１の間で正規化することができる。一例として、新たなメトリックである「年齢アフィニティ(Age Affinity)」を実装することが可能である。このメトリックは、２人のユーザの年齢差を共通部分として含んでいる符号付き整数(signed Integer)および／または一方のユーザの他方のユーザに対する定性的年齢差（「若い」、「かなり若い」など）を表している文字列(String)を返すことが可能である。また、１が２人のユーザの年齢が等しいことを意味し、０がシステムの目的上関連性があるとみなすには２人のユーザの年齢が離れすぎていることを意味するように、正規化された計算結果を算出することが可能である。
【００５５】
一例において、webappをロードバランサ (load balancer)によって制御される２つの生産機械に配置した。推奨可能ユーザの数は約１０００人であり、システムは１日当たり５００を越えるリクエストに応答することが可能であった。また、「http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi」でダウンロードすることが可能なジャバデスクトップアプリケーション(Java desktop application)であるアパッチジェイメータ(Apache Jmeter)を使用して負荷テストを行った。このテストでは、いくつかのリクエストがサーバに送信され、応答時間は同時リクエストの数に伴い直線的に増加した。テスト結果の数値は以下のとおりである。
【００５６】
【表１】
2009520304.tif 000008
【００５７】
いくつかの実施形態では、グラフプロッタツール(Graph Plotter tool)を使用することによって可視グラフを描くことが可能である。図９は、グラフプロッタツールから抽出することが可能な情報の一例を示している。図９に示すように、ユーザコミュニティにおけるさまざまなユーザ間のディスカバリ値(Discovery values)および／またはアフィニティ値(Affinity values)がグラフに表示されている。
【００５８】
ここで、特定の実施形態をさらに詳細に説明する。ここで、音楽セットＭａおよび推奨セットＲａを有するＡと音楽セットＭｂおよび推奨セットＲｂを有するＢという２人のユーザが存在すると仮定する。Ｒ（推奨セット）が入力であるＭ（音楽セット）から生成されたアイテムレコメンダの出力であるとすると、いくつかのアイテムレコメンダに対して以下の数式が常に成り立つ。
【００５９】
【数６】
2009520304.tif 000009
上述したように、４つの可能な基本共通ケースは、Ｍａ∩Ｍｂ、Ｍａ∩Ｒｂ、Ｒａ∩Ｍｂ、およびＲａ∩Ｒｂである。また、ケースの総数は１２である。
【００６０】
ピア関係(Peer relation)：Ｍａ∩Ｍｂ  ＡとＢは音楽の趣味が共通している。
【００６１】
ピア―ブラザー関係(Peer-Brother relation)：Ｍａ∩Ｍｂ＋Ｒａ∩Ｒｂ  ＡとＢは音楽の趣味が共通しており、かつ将来においても音楽の趣味が共通する可能性がある。
【００６２】
グル―フォロワー関係(Guru-follower relation)：Ｍａ∩Ｒｂ  ＢはＡから学ぶことができる（ＡはＢにとってのグルであり、ＢはＡのフォロワーである）。
【００６３】
ヒドゥン―ピア関係(Hidden-peer relation)：Ｒａ∩Ｒｂ  ＡとＢは音楽の趣味が共通するように発展する可能性がある。
【００６４】
ピア―グル／ピア―フォロワー関係(Peer-guru/Peer-follower relation)：Ｍａ∩Ｍｂ＋Ｍａ∩Ｒｂ  ＢはＡから学ぶことができるが、Ｂはすでに何かをＡから学んでいる。このケースは、ピア関係の特別なケースもしくはグル―フォロワー関係の特別なケースとして扱うことができる。ピア関係の特別なケースとして扱われた場合は、より強いピア関係(“stronger” Peer relation)であるとみなすことができる（第２の条件（Ｍａ∩Ｒｂ）は、ユーザＢの次の状態(state)もまたＡとＢの間のピア状態(Peer state)であることを保障するものである）。一方で、グル―フォロワー関係の特別なケースとして扱われた場合は、より弱いグル―フォロワー関係（“weaker” Guru-Follower relation)であるとみなすことができる（つまり、フォロワーの音楽のいくつかがグルの音楽の中に存在している）。
【００６５】
ピア―ブラザー―グル／ピア―ブラザー―フォロワー関係(Peer-Brother-Guru/Peer-Brother-Follower relation)：Ｍａ∩Ｍｂ＋Ｍａ∩Ｒｂ＋Ｒａ∩Ｒｂ  ピア―グル／ピア―フォロワー関係と同じであるが、推奨の中に共通部分を有している。
【００６６】
固定的なグル―フォロワー関係(Static Guru-Follower relation)：Ｍａ∩Ｒｂ＋Ｒａ∩ＲｂＢはＡから学ぶことができ、かつＡが次の状態へと進んだ場合には、ＢはさらにＡから学ぶことができる。これは、グル―フォロワー関係のより強いケースである。
【００６７】
クロス・トレイン関係(Crossing-trains relation)：Ｍａ∩Ｒｂ＋Ｒａ∩Ｍｂ  ＢはＡから学び、ＡはＢから学ぶ。しかしながら、ＡとＢの次の状態は共通しない。このケースは双方向性であるためグル―フォロワー関係の特殊なケースである。
【００６８】
タクシー関係(Taxi relation)：Ｍａ∩Ｒｂ＋Ｒａ∩Ｍｂ＋Ｍａ∩Ｍｂ クロス・トレイン関係と同様であるが、音楽の中に共通部分を有している。
【００６９】
ミーティングトレイン関係(Meeting-trains relation)：Ｍａ∩Ｒｂ＋Ｒａ∩Ｍｂ＋Ｒａ∩Ｒｂ  ＢはＡから学び、ＡはＢから学ぶ。さらに、ＡとＢの次の状態は共通部分を有している。ＡもしくはＢが次の状態に進むと、もう一方はさらに彼から学ぶことができる。２人とも次の状態に進んだ場合は、彼らはピア関係になる。これは、双方向性のグル―フォロワー関係の最も強いケースである。
【００７０】
パーフェクトコネクション関係(Perfect Connection relation)：Ｍａ∩Ｒｂ＋Ｒａ∩Ｍｂ＋Ｍａ∩Ｍｂ＋Ｒａ∩Ｒｂ  全てにおいて共通部分を有している。
【００７１】
また、あるアーティストが特定のユーザに対してどれだけ関連性があるかを決定／計算するための方法が存在していてもよい。例えば、システムが特定のユーザに対するそのアーティストのプレイカウント(playcounts)を有している場合、一定数のプレイカウントは「Ｌｏｗ（低）」とみなすことができ、他の一定数のプレイカウントは「Ｍｅｄｉｕｍ（中）」とみなすことができるなどのように、絶対的なカットオフポイント(absolute cut-off points)を設定することによってデータを正規化することができる。
【００７２】
または、システムがその特定ユーザのプレイリスト(playlists)のセットを有している場合、上記のアーティストがこのプレイリストに登場する回数をカウントすることができる。その後、この方法は上述したような方法（すなわち、カットオフポイントを設定する方法）に進むことができる。
【００７３】
さらに他の方法として、システムが推奨セット(recommended set)を有している場合、推奨リスト(recommended list)において特定のアーティストが占める位置に基づくそのアーティストの関連性を計算し、分析に使用することができる。もちろん、レコメンダは推奨されたアーティストの順位付けされたリストを提供するものであることが想定される。
【００７４】
いくつかの実施形態では、ユーザがどれだけ頻繁に特定のアーティストの曲を聴いているか、彼／彼女のプロフィールの中にそのアーティストの曲をいくつ有しているか、および／またはそのユーザが特定のアーティストにどれだけ精通しているかによって、ユーザをさらに分類することができる。例えば、ユーザが聴く各アーティストに対して、以下の１および２を考えることができる。
１．Ｆ：聴いている頻度
２．Ｋ：知識（ユーザがこのアーティストの曲をいくつ知っているか）
ＦおよびＫの値は、「Ｈｉｇｈ（高）」もしくは「Ｌｏｗ（低）」として分類することができる。したがって、特定のアーティストのリスナーは以下のように分類することができる。
【００７５】
【表２】
2009520304.tif 000010
【００７６】
通常、同じタイプのリスナーのみがマッチする。しかしながら、これらの分類を０を「Ｌｏｗ（低）」および１を「Ｈｉｇｈ（高）」とした場合の完全平方上の点として考えると、ＡはＢおよびＣに対して距離１、またＤに対して距離√２である。同様に、ＢはＡおよびＤに対して距離１、またＣに対して距離√２である。また、ＣとＤに関しても同様である。
【００７７】
しかしながら、聴いている頻度は知識ほど重要ではない可能性がある。したがって、１つの次元を他の次元よりも大きくすることができ、それによって四角形はＫ次元の周囲でより大きくなる。
【００７８】
この方法を使用すると、Ａの他のユーザに対する近接度は、Ｃに対しては「Ｈｉｇｈ（高）」、Ｂに対しては「Ｍｅｄｉｕｍ（中）」、Ｄに対しては「Ｌｏｗ（低）」となる。これらの関係を、図１０においてグラフとして示す。したがって、アーティストＡの特定のユーザＵに対する関連性は、Ｋ（Ａ）⊆［０，１］がユーザＵがアーティストＡに関して有している知識を計算する関数であり、ｆ（Ａ）⊆［０，１］がユーザＵがアーティストＡを聴いている相対頻度を求める関数である場合、以下のように表すことができる。
【００７９】
【数７】
2009520304.tif 000011
いくつかの実施形態では、ｎをユーザが知っている特定のアーティストの曲の数とし、Ｎをこのアーティストの曲の総数とするとき、Ｋをｎ／Ｎから求めることができる。同様に、ｎをユーザが聴いた特定のアーティストのプレイカウントの数とし、Ｐをこのユーザのプレイカウントの総数とするとき、Ｆをｎ／Ｐから求めることができる。いくつかの実施形態では、Ｆは上述のＲｅａｃｈ  ＡＰＩを通して計算することができる。
【００８０】
上記の説明は、好適な実施形態を含む本発明を完全に開示するものである。さらに詳述することなく、当業者であれば前述の説明を利用して本発明を最大限に活用することが可能であると考えられる。したがって、ここに開示されている実施例や実施形態は単なる一例として解釈されるべきであり、多少なりとも本発明の範囲を限定するものではない。
【００８１】
本発明の基本原理を逸脱しない範囲で上記の実施形態の詳細に対して多くの変更が可能であることは当業者にとっては言うまでもない。したがって、本発明は開示されている特定の実施形態に限定されるべきではなく、改良や他の実施形態が特許請求の範囲に含まれることが意図されている。
【００８２】
したがって、本発明の範囲は特許請求の範囲によってのみ決定される。
【図面の簡単な説明】
【００８３】
図面は、本発明の一部の好適実施形態のみを描写するものであり、本発明の範囲を限定するものではないことを理解されたし。好適実施形態を、添付の図面を使用することによりさらに具体的かつ詳細に記述しかつ説明する。
【図１】一実施形態に係るユーザプロフィールの基本の構成要素およびソースを示す図である。
【図２】一実施形態に係るADG空間におけるターゲットユーザＸの位置を示すグラフである。
【図３】一実施形態に係るユーザレコメンダの基本のアーキテクチャスキーマ(architecture schema)を示す図である。
【図４】ユーザコミュニティにおける特定のアイテムの特定のユーザに対する関連性を表す定性的スケールを示す図である。
【図５】ユーザレコメンダシステムの一実施形態のサーブレット・ビュー(Servlet View)を示す図である。
【図６】ユーザレコメンダシステムの一実施形態のレコメンダ・ビュー(Recommender View)を示す図である。
【図７】ユーザレコメンダシステムの一実施形態のマネジャー・ビュー(Manager View)を示す図である。
【図８】ユーザレコメンダシステムの一実施形態のコア統一モデリング言語(core UML)を示す図である。
【図９】ユーザレコメンダシステムの一実施形態とともに使用されるグラフプロッタツール(Graph Plotter tool)から抽出することができる情報の一例を示す図である。
【図１０】「頻度／知識」モデル(Frequency/Knowledge model)に従って複数のタイプのリスナー間の関係を表すグラフである。
【図１】
2009520304.tif 000012
【図２】
2009520304.tif 000013
【図３】
2009520304.tif 000014
【図４】
2009520304.tif 000015
【図５】
2009520304.tif 000016
【図６】
2009520304.tif 000017
【図７】
2009520304.tif 000018
【図８】
2009520304.tif 000019
【図９】
2009520304.tif 000020
【図１０】
2009520304.tif 000021
【手続補正書】
【提出日】平成20年8月18日(2008.8.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のユーザを含む定義されたコミュニティにおいて当該コミュニティ内の第１のユーザと関係がありそうと思われる個々のユーザを特定する方法であって、当該方法は、
前記コミュニティ内で第１のユーザを選択するステップと、
第１のメディアアイテムのセットと第１の推奨メディアアイテムのセットを含む前記第１のユーザのユーザプロフィールにアクセスするステップと、
前記ユーザコミュニティにおける複数の他のユーザを選択するステップと、
対応するメディアアイテムのセットと対応する推奨メディアアイテムのセットを含む前記複数の他のユーザのそれぞれに対するユーザプロフィールにアクセスするステップと、
前記第１のユーザのユーザプロフィールを前記コミュニティにおける前記複数の他のユーザのユーザプロフィールと比較するステップと、
前記複数の他のユーザのユーザプロフィールに基づいて、前記第１のユーザに関係がありそうと思われる前記複数の他のユーザの中から１または複数のユーザのセットを特定するステップと、を含むことを特徴とする前記方法。
【請求項２】
前記メディアアイテムのセットは、それぞれ、複数のメディアデータアイテムを含む請求項１に記載の方法。
【請求項３】
前記メディアデータアイテムは、それぞれ、少なくとも１つのデジタルミュージックトラック、デジタルビデオクリップまたはメタデータファイル、あるいは対応するミュージックトラックまたはビデオクリップを識別するリンクを含む請求項２に記載の方法。
【請求項４】
前記第１のユーザプロフィールを比較するステップは、前記第１のユーザのメディアアイテムのセットを前記複数の他のユーザのメディアアイテムのセットと比較するステップと、前記第１のユーザ推奨メディアアイテムのセットを前記複数の他のユーザの推奨メディアアイテムのセットと比較するステップと、を含む請求項３に記載の方法。
【請求項５】
前記第１のユーザのユーザプロフィールを前記複数の他のユーザのプロフィールと比較するステップは、当該他のユーザのユーザプロフィールのそれぞれに対して、
（a）前記第１のユーザのメディアアイテムのセットと前記複数の他のユーザのメディアアイテムのセットの共通部分を求めるステップと、
（b）前記第１のユーザのメディアアイテムのセットと前記複数の他のユーザの推奨メディアアイテムのセットの共通部分を求めるステップと、を含む請求項３に記載の方法。
【請求項６】
前記第１のユーザのユーザプロフィールを前記複数の他のユーザのユーザプロフィールと比較するステップは、当該他のユーザのユーザプロフィールのそれぞれに対して、
（a）前記第１のユーザの推奨メディアアイテムのセットと前記複数の他のユーザのメディアアイテムのセットの共通部分を求めるステップと、
（b）前記第１のユーザの推奨メディアアイテムのセットと前記複数の他のユーザの推奨メディアアイテムのセットの共通部分を求めるステップと、を含む請求項５に記載の方法。
【請求項７】
複数のユーザを含む定義されたコミュニティにおいて、第１のユーザに対する複数の個々のユーザの関係度を定量化する方法であって、当該方法は、
前記ユーザコミュニティにおいて第１のユーザを選択するステップと、
第１のメディアアイテムのセットと第１の推奨メディアアイテムのセットを含む前記第１のユーザのユーザプロフィールにアクセスするステップと、
対応するメディアアイテムのセットと対応する推奨メディアアイテのセットを含む前記複数の他のユーザのそれぞれに対するユーザプロフィールにアクセスするステップと、
前記第１のユーザのユーザプロフィールを前記コミュニティにおける複数の他のユーザのそれぞれのユーザプロフィールと比較するステップと、を有しており、
前記比較は、
（a）前記第１のユーザのメディアアイテムのセットと前記複数の他のユーザのそれぞれのメディアアイテムのセットの共通部分に基づいてアフィニティメトリックを求めるステップと、
（b）前記第１のユーザの推奨メディアアイテムのセットと前記複数の他のユーザのそれぞれのメディアアイテムのセットの共通部分に基づいてディスカバリメトリックを求めるステップと、
（c）前記第１のユーザのメディアアイテムのセットと前記複数の他のユーザのそれぞれの推奨メディアアイテムのセットとの共通部分に基づいてガイダンスメトリックを求めるステップと、を含むことを特徴とする前記方法。
【請求項８】
前記複数の他のユーザのそれぞれの推奨メディアアイテムのセットは、対応するユーザによって使用される少なくとも１つの入力メディアアイテムに応じて、アイテムリコメンダプログラムによって生成される請求項７に記載の方法。
【請求項９】
さらに、前記複数のユーザのそれぞれのメディアアイテムのセットにおける各アイテムに対する関連値を求めるステップと、
前記関連値を標準化するステップと、
前記標準化された関連値に基づいて、前記複数のユーザのそれぞれのメディアアイテムのセットの中で、それらのメディアアイテムをランク付けするステップと、
前記アフィニティメトリック、ディスカバリメトリック及びガイダンスメトリックのうちの少なくとも１つを決めるために最も高くランク付けされたメディアアイテムを含むサブセットを用いるステップと、を含む請求項７に記載の方法。
【請求項１０】
前記メディアアイテム関連値を標準化するステップは、所定の関連度スケールに対してそれらの関連値を定量化することにより行われる請求項９に記載の方法。
【国際調査報告】
2009520304.tif 000022