JP5681651B2 - リコメンデーションを作成する方法及びシステム - Google Patents

Description

本発明は、インターネットアプリケーションの分野に係る。より詳細には、本発明は、多数のドメインからのユーザ入力データを使用して製品又はサービスのリコメンデーションを作成するための方法及びシステムに係る。

リコメンデーションとは、人々が自分の希望するものをサーチしそして見つける最も強力な方法の１つである。カメラの買い物をするかレストランを見つけるよう試みるかに関わらず、人々は、友人、専門家及び出版物のような種々のソースからリコメンデーションを得ることを頼みとする。

コンピュータ作成リコメンデーションの研究が数十年にわたって活発に行われ、そして大量の出版物や種々の解決策並びに多数のワーキングシステムを、ある範囲の成功度で生み出している。コンピュータ作成リコメンデーションは、種々のソースからの専門知識のコンディフィケーション(condification)に基づくことができる。これは、１９７０年代及び８０年代に専門システムベースのアプリケーションの供給過剰により明らかになった。この解決策に伴う問題は、コンピュータアプリケーションにおいて専門知識を捕獲して維持する上での努力と困難さである。

専門システムの幾つかの欠点に対処する別の解決策は、コンピュータアプリケーションが過去の実績に基づいてそれ自身を適応させることによりそれ自身の実績を改善できるマシン学習システムである。リコメンデーションに関しては、この解決策は、協力的フィルタリングアルゴリズムの形態で表わされる。

協力的フィルタリングは、他のユーザの経験についてのリコメンデーションをベースとしている。特定ドメインにおける判断に直面したときには、人々は、そのドメインにおいて経験をもつ友人にしばしば相談する。協力的フィルタリングは、単なる友人や知人を越えて、ユーザの大きなグループにわたりこれらのリコメンデーションを構築する方法である。この解決策は、評論、スコア、ランク、投票、等の形態でこれらユーザのフィードバックを入力として取り上げる。この入力データを分析して、リコメンデーションの成功の確率へと換算されるユーザ及びアイテム間の相関及びパターンを見出す。

協力的フィルタリングを使用する良く知られた個人化映画リコメンデーションウェブサイトは、ＭｏｖｉｅＬｅｎｓ（ｈｔｔｐ：／／ｗｗｗ．ｍｏｖｉｅｌｅｎｓ．ｃｏｍ）である。この個人化映画リコメンデーションサービスでは、数千人のユーザが、その映画をどの程度好きか嫌いかに基づいて映画のスコアを提示する。ユーザがリンクした映画と同様の映画を見ることにより特定ユーザのリコメンデーションを作成することができる。これは、「people who like this movie also like the following movies（この映画が好きな人は、次の映画も好きである）」という形式のリコメンデーションを与える。例えば、「Jerry Maguire」という映画を見るユーザは、「A Few Good Men」という映画リコメンデーションを得ることがある。この場合、「類似性」は、リコメンデーションを要求している特定ユーザがスコアをつけた映画と相交わる映画にスコアをつけた全ユーザ人口にわたってスコアを分析することに基づく。

上述した例に示されたように、協力的フィルタリングのエリアにおける既存のシステムは、単一のドメイン内のユーザの入力データに基づいてリコメンデーションを作成することに集中している。入力データは、例えば、映画のような単一ドメインからしか収集されないので、リコメンデーションは、このドメイン内のアイテムに対して作成できるだけである。更に、協力的フィルタリングリコメンデーションのクオリティは、入手できるユーザ入力データの量に依存する。しかし、１つのドメインに入手できるデータが僅かである場合は、作成されるリコメンデーションは、関連性が低く且つ信頼性の低いものとなる。

それ故、単一ドメインから収集されたデータに基づいてリコメンデーションを作成する問題に対処できるシステム及び方法が要望される。特に多数のドメインからのユーザ入力データを使用して製品又はサービスのリコメンデーションを作成するためのシステム及び方法が要望される。

本発明は、多数のドメインにわたってユーザ入力データを使用して製品又はサービスのリコメンデーションを作成するシステム及び方法を開示する。本発明は、既存のシステムに対する多数の改善を提供する。

第１に、本発明は、ビジネスの関心が複数のドメインにわたっている組織に対して効果的である。リコメンデーションは、単一ドメインに限定されない。むしろ、異なるドメインからのユーザの事象をレバレッジして、これらドメインのいずれにおいてもリコメンデーションを作成することができる。例えば、ショッピング、ニュース及び映画にわたってユーザのフィードバックを分析することにより、このシステムは、スケートボードの買い物をしたユーザにスケートボードの映画を勧め、或いはスケートボードに関するニュース記事を読むことを勧めることができる。

更に、本発明は、非常に多量のユーザ入力データにアクセスすることを許し、ひいては、リコメンデーションのクオリティを改善することができる。前記スケートボードの例では、スケートボードに関するショッピングドメイン内のデータの量だけでは、クオリティの高いリコメンデーションを許すには少な過ぎることがある。これは、ニュース及び映画ドメイン内についても、それらを個々に見たときに、言えることである。しかし、これらのドメインにわたるデータの合成を許すことにより、そうでなければなし得ないことであるが、スケートボード相関のこのパターンを見つけてリコメンデーションに使用することができる。

多数の製品又はサービスドメインにわたりリコメンデーションを作成する方法は、データベース内の複数の製品又はサービスドメインにわたりユーザ事象を収集するステップと、リコメンデーションに対するトリガー事象を受け取るステップと、ユーザ事象を分析して、データベースにおけるユーザ事象間の相関を公式化するステップと、トリガー事象に応答し、データベースにおけるユーザ事象間の相関に基づいてリコメンデーションを作成するステップとを備えている。

多数の製品又はサービスドメインにわたりリコメンデーションを作成するシステムは、ユーザ事象を取り扱うと共に、インターネットを経てユーザにインターフェイスするための複数のドメインサーバーと、ユーザ事象を記憶するためのデータベースと、リコメンデーションエンジンとを備えている。リコメンデーションエンジンは、更に、データベース内の複数の製品又はサービスドメインにわたりユーザ事象を収集し、リコメンデーションに対するトリガー事象を受け取り、ユーザ事象を分析して、データベースにおけるユーザ事象間の相関を公式化し、そしてトリガー事象に応答し、データベースにおけるユーザ事象間の相関に基づいてリコメンデーションを作成するためのインストラクションを含む１つ以上のコンピュータプログラムを備えている。

本発明の前記特徴及び効果、並びにその付加的な特徴及び効果は、図面全体にわたり同じ番号が使用された添付図面を参照した本発明の実施形態の以下の詳細な説明から明確に理解されよう。

本発明の実施形態によるクロスドメインリコメンデーションシステムを示す。 本発明の実施形態により図１のユーザデータベース１１４においてユーザ事象を収集するための方法を示す。 本発明の実施形態により図１のユーザデータベース１１４においてユーザ事象を分析するための方法を示す。 本発明の実施形態により同様のアイテムのリコメンデーションを作成する方法を示す。 本発明の実施形態により個人化リコメンデーションを作成する方法を示す。

図１は、本発明の実施形態によるクロスドメインリコメンデーションシステムを示す。このリコメンデーションシステムは、１つ以上のリコメンデーションサーバー１０２と、１つ以上のクライアント１０４とを備えている。リコメンデーションサーバー１０２は、インターネット１０３を経てクライアント１０４とインターフェイスする。リコメンデーションサーバーは、更に、複数の個々のドメイン、例えば、ショッピングドメイン１０６、ニュースドメイン１０８、映画ドメイン１１０及び他のドメイン１１２を備えている。

ドメインとは、ショッピングアプリケーション１０６、ニュースアプリケーション１０８、及び映画アプリケーション１１０のような特定のアプリケーションのための異なるハードウェア及びソフトウェアで実施される。各特定ドメインとのユーザの相互作用、ユーザ事象とも称される、は、ユーザデータベース１１４にセーブされて更新される。ユーザデータベース１１４は、各個々のドメインから収集されたデータ、例えば、映画データ１１６、ニュースデータ１１８、ショッピングデータ１２０、及び他のドメインデータ１２２に対する記憶装置を構成する。ユーザ１０４は、全てのドメインとの多数のユーザ相互作用をもつことができる。更に、ドメインは、より一般的には、情報のカテゴリーとして定義することもできる。例えば、異なるドメインは、人口統計学的情報（年齢、人種、職業、学歴レベル、等）、行動情報（インターネットの使用時間、使用する種々のウェブサイト、インターネットにアクセスするのに使用するコンピュータの数、等）、及びコンピュータシステム情報（インターネット接続容量、マルチメディアシステム能力、ブラウザバージョン、等）を含むことができる。

リコメンデーションサーバー１０２は、リコメンデーションエンジン１２６を更に備えている。以下に述べるように、このリコメンデーションエンジン１２６は、特定のユーザ事象に応答してドメインにわたってユーザデータベース１１４の一部分を分析して、ドメインにわたる相関を見出し、リコメンデーションを作成する。リコメンデーションエンジン１２６は、例えば、映画データ１１６、ニュースデータ１１８、ショッピングデータ１２０、及び他のドメインデータ１２２のような種々のドメインからのデータスライス１２４を処理する。異なるドメインに記憶されたユーザ事象は、異なる形式、値及び構造を有してもよいことに注意されたい。次いで、リコメンデーションエンジン１２６は、ユーザ事象間の相関を見出し、そしてユーザ事象間の相関に基づいてそのリコメンデーションを公式化する。

ユーザ事象の収集
協力的(collaborative)フィルタリングからのリコメンデーションは、ユーザの行動を分析することにより導出される。このユーザ行動は、ユーザデータベース１１４においてユーザ事象として表わされる。多数のドメインからのこれらユーザ事象を記憶することは、各ドメインからのデータフォーマットが異なることがあるので、単一ドメインの場合より複雑である。ユーザデータベース１１４に記憶されたユーザ事象は、それらが多様なドメインから収集されたものであれば、多様なものである。例えば、ショッピングドメイン１０６からの事象の形式は、製品をブラウズし、購入し、又は返品することを含んでもよい。ニュースドメイン１０８において、事象形式は、タイトルを見、概要を見、又はニュース記事全体を見ることを含んでもよい。映画ドメイン１１０では、事象形式は、映画にスコアを付けそして評論したり、又はオンラインで映画チケットを購入したりすることを含む。

種々の形式の事象に加えて、所与の事象に対して種々の事象値がある。
− 数値：映画、歌、等に対するスコア及びランク
− 順序的値：順序付けされたスケール、例えば、高、中、低を有するテキスト値
− フリーテキスト：評論、見解
− 公称値：上記に含まれない全てのもので、通常は、１組の１つ以上のラベル、例えば、（オン、オフ）、（ｅメール、メッセージ、電話）

クロスドメインリコメンデーションをサポートするユーザデータベース１１４は、この種々の事象値を記憶することができる。更に、多数のドメインからのユーザ事象を記憶するためのユーザデータベース１１４は、図２Ｂに示すように、多数のドメインにわたって編成される。多数の組織において、ドメインは、個人の異なるチームにより管理される。ここに開示するリコメンデーションシステムによる多数のドメインからのデータの集計は、異なる地理的位置における人々の種々のチームにわたって整合されそして同期される。更に、リコメンデーションシステムにおける進行中の変化は、動的に更新される。換言すれば、全てのドメインにおける変化が、この集中型ユーザデータベース１１４により受け容れられる。１組のドメイン、製品、サービス、ユーザ、及びユーザ事象の属性は、常時、変化してもよい。以下に述べるように、本発明は、ユーザデータベースのこの動的な態様をサポートする。

図２Ａは、本発明の実施形態により図１のユーザデータベース１１４においてユーザ事象を収集するための方法を示す。ユーザ事象は、次の入力パラメータにより記述される。
− ｕｓｅｒｉｄ（ユーザｉｄ）：特定のユーザに対する独特の識別子
− ｄｏｍａｉｎ（ドメイン）：事象、例えば、ショッピング、ニュース、映画を発生するビジネス、プロパティ又はシステム
− ｉｔｅｍｉｄ（アイテムｉｄ）：ドメイン内の特定アイテム又は製品に対する独特の識別子
− ｅｖｅｎｔ ｔｙｐｅ（事象形式）：記憶される事象、例えば、購入、スコア、評論の形式
− ｅｖｅｎｔ ｖａｌｕｅ（事象値）：所与のドメイン、アイテム及び事象形式に対するユーザの入力

この方法は、ステップ２０２でスタートし、その後、ステップ２０４へ進み、記憶されるべきユーザ事象を受け取って、それが有効なユーザ事象であるかどうか決定する。それが有効な事象でない場合には、それを拒絶すべきか、又はデータベースを拡張すべきか決定する。事象が拒絶されない場合には、新たなユーザ事象を反映するようにデータベースが更新される。

ステップ２０６において、事象の「ｄｏｍａｉｎ」が有効であるかどうかについて評価を行う。「ｄｏｍａｉｎ」が有効である（２０６−イエス）場合には、ステップ２１２へと続く。さもなければ（２０６−ノー）、ステップ２０８において、リコメンデーションシステムのコンフィギュレーションをチェックし、新たな「ｄｏｍａｉｎ」を受け取ったときにデータベースを動的に更新できるかどうか決定する。動的な「ｄｏｍａｉｎ」更新がイネーブルされない場合には、ステップ２３８へ進み、事象を拒絶する。一方、動的な「ｄｏｍａｉｎ」更新がイネーブルされる場合には、ステップ２１０において、「ｄｏｍａｉｎ」を１組の有効ドメインに追加し、そしてステップ２１２へと続く。

ステップ２１２において、「ｅｖｅｎｔ ｔｙｐｅ」が有効であるかどうかチェックする。有効である（２１２−イエス）場合には、ステップ２１８へ続く。「ｅｖｅｎｔ ｔｙｐｅ」が有効でない（２１２−ノー）場合には、ステップ２１４において、動的な「ｅｖｅｎｔ ｔｙｐｅ」更新がイネーブルされるかどうかチェックする。動的な「ｅｖｅｎｔ ｔｙｐｅ」更新がイネーブルされない（２１４−ノー）場合には、ステップ２３８へ進み、その事象を拒絶する。一方、動的な「ｅｖｅｎｔ ｔｙｐｅ」更新がイネーブルされる（２１４−イエス）場合には、ステップ２１６において、その「ｅｖｅｎｔ ｔｙｐｅ」を１組の有効事象形式に追加し、そしてステップ２１８へ続く。

次いで、ステップ２１８において、「ｅｖｅｎｔ ｖａｌｕｅ」が有効であるかどうかチェックする。それが有効である（２１８−イエス）場合には、ステップ２２４へ続く。「ｅｖｅｎｔ ｖａｌｕｅ」が有効でない（２１８−ノー）場合には、ステップ２２０において、動的な「ｅｖｅｎｔ ｖａｌｕｅ」更新がイネーブルされるかどうかチェックする。動的な「ｅｖｅｎｔ ｖａｌｕｅ」更新がイネーブルされない（２２０−ノー）場合には、ステップ２３８へ進み、事象を拒絶する。一方、動的な「ｅｖｅｎｔ ｖａｌｕｅ」更新がイネーブルされる（２２０−イエス）場合には、ステップ２２２において、「ｅｖｅｎｔ ｖａｌｕｅ」を１組の有効事象値に追加し、そしてステップ２２４へ続く。種々の事象値を動的に受け入れる融通性をもつことが効果的である。例えば、ドメイン「パーソナル」及び事象形式「連絡方法（Method of Contact）」については、既知の値は、「（ｅメール、ボイスメール、ページャー）」でよい。「パーソナル」製品が変化するときには、他の人々に連絡する新たな方法、例えば、「ｗｅｂｃａｍ」を追加してもよい。ユーザがこの新たな特徴の利点を取り入れるときには、「連絡方法」に対して「ｗｅｂｃａｍ」を伴う新たなユーザ事象が作成される。動的な「ｅｖｅｎｔ ｖａｌｕｅ」更新がイネーブルされる場合には、システムは、それらのユーザ事象を受け入れて、継続することができる。この方法は、システムが、個々のドメインアプリケーション及びチームと共に自動的に成長しそして変化するのを許す。

ステップ２２４において、「ｉｔｅｍｉｄ」が有効かどうかチェックする。有効であれば（２２４−イエス）、ステップ２２４へ続く。「ｉｔｅｍｉｄ」が有効でない（２２４−ノー）場合には、ステップ２２６において、動的な「ｉｔｅｍｉｄ」更新がイネーブルされるかどうかチェックする。動的な「ｉｔｅｍｉｄ」更新がイネーブルされない（２２６−ノー）場合には、ステップ２３８へ続き、事象を拒絶する。一方、動的な「ｉｔｅｍｉｄ」更新がイネーブルされる（２２６−イエス）場合には、ステップ２２８において、「ｉｔｅｍｉｄ」を１組の有効な「ｉｔｅｍｉｄ」に追加し、そしてステップ２３０へと続く。事象値について上述した融通性と同様に、「ｉｔｅｍｉｄ」を動的に更新するためのこの融通性は、システムが、ほとんどのビジネスアプリケーションにおいて不可避である製品在庫の変化を自動的に取り扱うのを許す。あるアプリケーションは、動的な「ｉｔｅｍｉｄ」更新をディスエイブルするための能力が重要となる。例えば、サブ組のアイテムについてリコメンデーションを作成することしか要望されない場合には、それらのアイテムだけを有効な「ｉｔｅｍｉｄ」のリストに許すことができる。動的な「ｉｔｅｍｉｄ」更新をディスエイブルすると、望ましからぬアイテムが候補リコメンデーションのプールに徐々に進行することが防止される。全てのドメインにわたり「ｉｔｅｍｉｄ」の独特さを維持するために、「ｉｔｅｍｉｄ」は、それが発生された「ｄｏｍａｉｎ」内でのみ有効性についてチェックされる。これは、各「ｄｏｍａｉｎ」（チーム、プロパティ、アプリケーション）が、他のドメインとのネームスペースの競合に関与することなく、アイテム識別のためのそれら自身のプロセスを維持することを許す。

ステップ２３０において、「ｕｓｅｒｉｄ」が有効であるかどうかチェックする。これが有効である（２３０−イエス）場合には、ステップ２３６に続く。「ｕｓｅｒｉｄ」が有効でない（２３０−ノー）場合には、ステップ２３２において、動的な「ｕｓｅｒｉｄ」更新がイネーブルされるかどうかチェックする。動的な「ｕｓｅｒｉｄ」更新がイネーブルされない（２３２−ノー）場合には、ステップ２３８へ進み、事象を拒絶する。一方、動的な「ｕｓｅｒｉｄ」更新がイネーブルされる（２３２−イエス）場合には、ステップ２３４において、その「ｕｓｅｒｉｄ」を１組の有効な「ｕｓｅｒｉｄ」に追加し、そしてステップ２３６へ続く。「ｉｔｅｍｉｄ」について上述した融通性と同様に、ユーザ人口が毎日変化するようなほとんどのインターネットアプリケーションでは、新たなユーザに対して事象を記憶するようにデータベースを自動的に拡張する能力が重要となる。しかしながら、例えば、サービスの期間について合意しない限りユーザの事象を記憶してはならない場合には、これらの更新を制限する融通性も有益である。

ステップ２３６において、ユーザ事象をユーザデータベース１１４に記憶し、そしてステップ２４０でこの方法が終了となる。

ユーザ事象の分析
図２Ｂは、本発明の実施形態により図１のユーザデータベース１１４においてユーザ事象を分析するための方法を示す。図２Ｂに示すように、ユーザデータベース１１４は、各ユーザが１つ以上の行に表わされ、各行が特定のユーザ事象を含むような多次元アレーとして表わされる。

上述したスケートボードの例を使用すると、収集した第１ユーザ事象は、ユーザ１がスケートボードに関する全ニュース記事を見るというものである。この場合の「ｅｖｅｎｔ ｖａｌｕｅ」は、公称値（イエス）である。第２事象は、ユーザ１がスケートボード映画を８０のレーティングでレーティング決めしたというものである。「ｅｖｅｎｔ ｖａｌｕｅ」は、順序的値であり、この場合は、０と１００との間の整数である。第３事象は、ユーザ１がその後にこの映画の評論を書いたことである。この場合の「ｅｖｅｎｔ ｖａｌｕｅ」は、フリーテキストである。第４事象は、ユーザ１がスケートボードを購入したというものである。この場合、「ｅｖｅｎｔ ｖａｌｕｅ」は、アイテムに対して支払われた金額を反映する順序である。その後、第５事象は、これらスケートボードアイテムに対するレーティングを示す。この場合の「ｅｖｅｎｔ ｖａｌｕｅ」は、「低」、「中」及び「高」のスケールにおいて順序的な「高」である。

ユーザ事象間の相関を見出すために使用できる協力的フィルタリングアルゴリズムは、多数ある。本発明の一実施形態では、２００３年４月１６日に出願された「Affinity Analysis Method and Article of Manufacture」と題する米国特許出願第１０／４１７，７０９号に開示された親和性エンジン(Affinity Engine)を使用して、ユーザ事象間の相関を見出す。この米国特許出願第１０／４１７，７０９号は、参考としてここに援用する。この親和性エンジンは、全ユーザ人口に対して収集された多数のドメインにわたりユーザデータベース１１４の部分を処理して、ユーザ事象間、例えば、ユーザデータベースにおけるユーザ１及び他のユーザのユーザ事象間の相関を決定する。規範的ユーザ事象間の関係の重みを指示するように相関値が指定され、そしてこの相関値は、類似性データベースに記憶される。次いで、これらの相関値を使用して、同様のユーザ行動を示すその後のユーザに対してリコメンデーションを作成する。例えば、ユーザ２も、スケートボードに関して同じ全体的ニュース記事を見て、同じスケートボード映画のレーティングを決め、そしてその評論を書いた場合には、ユーザ１の規範的ユーザ事象のような、ユーザ人口における他のユーザにより示された集合的な規範的ユーザ事象に基づいて、あるスケートボードを購入するためのリコメンデーションをユーザ２に対して作成することができる。ここに開示する発明は、ユーザ事象間の相関値を計算するのに使用された協力的フィルタリングアルゴリズムとは独立している。ある形式のフィルタリングアルゴリズムは、ある形式のユーザ事象をフィルタリングするのにより適していることを確認すると、ここに開示する発明は、協力的フィルタリングアルゴリズムをプラグインコンポーネントとしてリコメンデーションシステムに一体化するのをサポートする。

同様のアイテムのリコメンデーション
アイテムとアイテムとの間の類似性は、リコメンデーションを作成するための考えられる基準を与える。しばしば、人々は、自分が楽しんだ他の本と同様であると考えられる読むべき本を見つける。これは、他のドメイン、即ち映画、歌、衣服、ゲーム、並びに他の製品及びサービスへと拡張される。アイテムは、それらが似ている場合、又はより明確には、それらがそれらの属性にわたって同様の値を有する場合に同様とみなされる。例えば、本の場合には、属性は、著者、フィクション又はノンフィクション、ジャンル、及びキャラクタの開発でよい。アイテムの類似性に基づいてリコメンデーションを計算するための異なる解決策が存在する。

図３に示す本発明の一実施形態では、この方法は、クロスドメインリコメンデーションの状況においてこれらアイテムの類似性を使用する仕方を与える。同様のアイテムリコメンデーションに対するユーザ要求のようなトリガー事象は、次の入力パラメータを備えている。
・ｄｏｍａｉｎ：例えば、ショッピング、ニュース、映画のような同様のアイテムのリコメンデーションが要求されるところのアイテムを含むビジネス、プロパティ、又はシステム
・ｉｔｅｍｉｄ：ドメイン内の特定アイテム又は製品に対する独特の識別子
・ｔｈｒｅｓｈｏｌｄ：勧められるアイテムが有していなければならない類似性の最小レベル
・ｍｉｎｉｔｅｍ：勧められる希望のアイテムの最小数
・ｍａｘｉｔｅｍ：勧められる希望のアイテムの最大数
・ｓｒｃ＿ｄｏｍａｉｎｓ：勧められるアイテムが属するべきドメイン（１つ又は複数）

この方法は、全ての希望のドメインにわたって同様のアイテムを見出し、そして１組の規定の制約に基づいて勧められるアイテムのリストを返送する。

図３は、本発明の実施形態に基づきリコメンデーションエンジン１２６により同様のアイテムのリコメンデーションを作成する方法を示す。この方法は、ステップ３０２でスタートし、その後、ステップ３０４へ進み、ここで、指定のアイテムと同様の他のアイテムのリコメンデーションのために、ユーザ要求のようなトリガー事象を受け取る。ステップ３０６において、指定のアイテムがユーザデータベース１１４に存在するかどうかの判断がなされる。指定のアイテムが存在しない（３０６−ノー）場合には、この方法は、ステップ３３４において終了となり、リコメンデーションは作成されない。一方、指定のアイテムが存在する（３０６−イエス）場合には、ステップ３０８に続く。指定のアイテムが存在するかどうかの決定は、この指定のアイテムと同様とみなされるアイテムがあるかどうかに基づく。同様のアイテムがないことは、２つの原因が考えられる。１）以前に存在しなかった新たなアイテムがある。２）この指定のアイテムは、要求の前に存在したが、リコメンデーションの基礎となるに充分なユーザ事象がこの指定のアイテムに関連していない。

次いで、ステップ３０８乃至３１２において、１組の非制約の同様のアイテムが検索され、この組は、リコメンデーションの第１リストとも称される。この１組の非制約の同様のアイテムは、「ｓｒｃ＿ｄｏｍａｉｎｓ」入力パラメータが指定されたかどうかに依存する。「ｓｒｃ＿ｄｏｍａｉｎｓ」が指定された（３０８−イエス）場合には、１組の同様のアイテムが、ステップ３１０において、「ｓｒｃ＿ｄｏｍａｉｎｓ」により指示されたドメインのみから引き出される。「ｓｒｃ＿ｄｏｍａｉｎｓ」が指定されない（３０８−ノー）場合には、１組の同様のアイテムがステップ３１２において全てのドメインから引き出される。

同様のアイテムについてのリコメンデーションの第１リストが与えられると、クロスドメインリコメンデーションを改善するために、ｄｏｍａｉｎ、ｔｈｒｅｓｈｏｌｄ、ｍｉｎｉｔｅｍ及びｍａｘｉｔｅｍを含む規定の１組の制約が適用される。ステップ３１４において、リコメンデーションの第１リストにおけるアイテムの数が規定のｍｉｎｉｔｅｍより大きいかどうかの決定がなされる。この決定の結果が否定である（３１４−ノー）場合には、リコメンデーションの第１リストがステップ３３２において返送される。一方、決定の結果が肯定である（３１４−イエス）場合には、ステップ３１６に続く。

ステップ３１６において、リコメンデーションの第１リストからリコメンデーションの第２リストが形成される。リコメンデーションの第２リストは、規定のｔｈｒｅｓｈｏｌｄより高い相関値を有する同様のアイテムで構成されるリコメンデーションの第１リストのサブ組である。リコメンデーションの第２リストにおけるアイテムの数がｍｉｎｉｔｅｍより大きいかどうかについて別の決定がなされる。リコメンデーションの第２リストにおけるアイテムの数がｍｉｎｉｔｅｍより大きくない（３１６−ノー）場合には、ステップ３３０において、リコメンデーションの第１リストから相関値が減少する順にｍｉｎｉｔｅｍ数のリコメンデーションを選択して、リコメンデーションの第３リストを形成し、そしてステップ３３２において、リコメンデーションの第３リストを返送する。この状況において、勧められる１つ以上のアイテムは、相関値がｔｈｒｅｓｈｏｌｄより低いものでよいが、それでも、ｍｉｎｉｔｅｍ制約を満足するように返送される。多数の普通のコンピュータ及びインターネットアプリケーションにおいて要求される数のアイテムをユーザに与えるのが効果的である。別の態様において、リコメンデーションの第２リストにおけるアイテムの数がｍｉｎｉｔｅｍより大きい（３１６−イエス）場合には、ステップ３２０乃至３２８における更なる処理のために、ステップ３１８において、リコメンデーションの第２リストが保持される。

ステップ３２０において、ｍａｘｉｔｅｍ制約が考慮される。リコメンデーションの第２リストにおけるアイテムの数がｍａｘｉｔｅｍ制約より大きいかどうかの決定がなされる。その結果がノーである（３２０−ノー）場合には、ステップ３３２において、リコメンデーションの第２リストが返送される。この経路は、スレッシュホールドを満足し又はそれを越えるような勧められる同様のアイテムのリストを返送し、そして勧められるアイテムの数は、要求されたアイテムの最小数より大きいが、要求されたアイテムの最大数以下である。別の場合（３２０−イエス）には、類似性「ｔｈｒｅｓｈｏｌｄ」制約を適用した後に、リコメンデーションの第２リストにおけるアイテムの数が依然として最大希望アイテム数より大きい場合には、ステップ３２２へと続き、勧められるアイテムを、それらが引き出されたところの１組のドメインにわたって拡散することにより、リコメンデーションの第２リストを改善する。

ステップ３２２において、候補アイテムは、規定の「ｓｒｃ＿ｄｏｍａｉｎｓ」パラメータに基づいてドメイングループに分離される。ステップ３２４乃至３２８において、この方法は、ラウンドロビン機構を使用し、各グループを一度に１つ横断する（ステップ３２４）。ステップ３２６では、最も高い相関値を有するリコメンデーションを選択して、リコメンデーションの第４リストを形成する（ステップ３２６）。当業者であれば、他のプライオリティ機構を選択プロセスに使用してもよいことが明らかであろう。ステップ３２４及び３２６は、リコメンデーションの第４リストにおけるアイテムの数が規定の「ｍａｘｉｔｅｍ」に等しくなるまで繰り返される。最終的な結果は、要求されたアイテムと同様の第４組のリコメンデーションである。この第４組のリコメンデーションは、「ｍｉｎｉｔｅｍ」及び「ｍａｘｉｔｅｍ」制約を満足すると共に、充分に同様のアイテムが存在する場合には類似性「ｔｈｒｅｓｈｏｌｄ」も満足する。又、１組の勧められるアイテムは、指定のドメインにわたる均一な選択も反映する。ステップ３３２において、リコメンデーションの第４リストが返送される。この方法は、ステップ３３４で終了となる。

個人化アイテムのリコメンデーション
同様のアイテムのリコメンデーションは、ユーザの個人的好みの経歴を考慮することにより更に改善することができる。ユーザの個人的好みの経歴に基づいて所与の個人が好むアイテムと同様のアイテムを見出すことにより個人化リコメンデーションが行われる。図４は、本発明の実施形態により個人化リコメンデーションを作成する方法を示す。この方法は、全ての希望のドメインにわたって個人化リコメンデーションを見出し、そして１組の規定のパラメータに基づいて個人化リコメンデーションのリストを返送する。個人化リコメンデーションのためのユーザ要求のようなトリガー事象は、次の入力パラメータを含む。
・ｕｓｅｒｉｄ：特定のユーザに対する独特の識別子
・ｔｈｒｅｓｈｏｌｄ：勧められるアイテムが有していなければならない類似性の最小レベル
・ｍｉｎｉｔｅｍ：勧められる希望のアイテムの最小数
・ｍａｘｉｔｅｍ：勧められる希望のアイテムの最大数
・ｓｒｃ＿ｄｏｍａｉｎｓ：勧められるアイテムが属するドメイン（１つ又は複数）

この方法は、ステップ４０２でスタートし、その後、ステップ４０４へ進み、ここで、個人化リコメンデーションのためのトリガー事象を受け取る。ステップ４０６において、ユーザが存在するかどうかについて第１の決定がなされる。ユーザが存在しない（４０６−ノー）場合には、この方法は、ステップ４３４で終了となり、個人化リコメンデーションは作成されない。或いは又、ユーザが存在する（４０６−イエス）場合には、ステップ４０８へ続く。ユーザが存在するかどうかの決定は、ユーザデータベース１１４にユーザ事象があるかどうかに基づく。ステップ４０８では、ユーザが気質を示すか又は好みを示すところのアイテムの第１リストが検索される。この第１リストのアイテムは、規定のｔｈｒｅｓｈｏｌｄ以上でもある。

これら好ましいアイテムは、個人化リコメンデーションを見出すための基礎として使用される。ステップ４１０及び４１２では、各好ましいアイテムについて（ステップ４１０）、１組の同様のアイテムが検索される（ステップ４１２）。同様のアイテムを見出すための方法は、図３を参照して上述した。同様のアイテムを得るためのプロセスには、次の入力パラメータ、即ちｔｈｒｅｓｈｏｌｄ、ｍｉｎｉｔｅｍ、ｍａｘｉｔｅｍ、及びｓｒｃ＿ｄｏｍａｉｎｓが使用される。同様のアイテムを得るためのｉｔｅｍｉｄ及びｄｏｍａｉｎ入力パラメータは、好ましいアイテムのリストにおける各アイテムから導出される。ステップ４１２では、各好ましいアイテムに対して検索された同様のアイテムの結合が、その後のステップのために個人化リコメンデーションの第１リストに記憶される。

個人化リコメンデーションの第１リストが与えられると、クロスドメインリコメンデーションを改善するために、ｄｏｍａｉｎ、ｔｈｒｅｓｈｏｌｄ、ｍｉｎｉｔｅｍ及びｍａｘｉｔｅｍを含む規定の１組の制約が適用される。ステップ４１４では、リコメンデーションの第１リストにおけるアイテムの数が規定のｍｉｎｉｔｅｍより大きいかどうかの決定がなされる。この決定の結果が否定（４１４−ノー）である場合には、リコメンデーションの第１リストがステップ４３２において返送される。一方、この決定の結果が肯定である（４１４−イエス）場合には、この方法は、ステップ４１６に続く。

ステップ４１６において、リコメンデーションの第１リストからリコメンデーションの第２リストが形成される。リコメンデーションの第２リストは、規定のｔｈｒｅｓｈｏｌｄより高い相関値を有するアイテムで構成されるリコメンデーションの第１リストのサブ組である。リコメンデーションの第２リストにおけるアイテムの数がｍｉｎｉｔｅｍより大きいかどうかについて別の決定がなされる。リコメンデーションの第２リストにおけるアイテムの数がｍｉｎｉｔｅｍより大きくない（４１６−ノー）場合には、ステップ４３０において、リコメンデーションの第１リストから相関値が減少する順にｍｉｎｉｔｅｍ数のリコメンデーションを選択して、リコメンデーションの第３リストを形成し、そしてステップ４３２において、リコメンデーションの第３リストを返送する。この状況において、勧められる１つ以上のアイテムは、相関値がｔｈｒｅｓｈｏｌｄより低いものでよいが、それでも、ｍｉｎｉｔｅｍ制約を満足するように返送される。多数の普通のコンピュータ及びインターネットアプリケーションにおいて要求される数のアイテムをユーザに与えるのが効果的である。別の態様において、リコメンデーションの第２リストにおけるアイテムの数がｍｉｎｉｔｅｍより大きい（４１６−イエス）場合には、ステップ４２０乃至４２８における更なる処理のために、ステップ４１８において、リコメンデーションの第２リストが保持される。

ステップ４２０において、ｍａｘｉｔｅｍ制約が考慮される。リコメンデーションの第２リストにおけるアイテムの数がｍａｘｉｔｅｍ制約より大きいかどうかの決定がなされる。その結果がノーである（４２０−ノー）場合には、ステップ４３２において、リコメンデーションの第２リストが返送される。この経路は、スレッシュホールドを満足し又はそれを越えるような勧められるアイテムのリストを返送し、そして勧められるアイテムの数は、要求されたアイテムの最小数より大きいが、要求されたアイテムの最大数以下である。別の場合（４２０−イエス）には、類似性「ｔｈｒｅｓｈｏｌｄ」制約を適用した後に、リコメンデーションの第２リストにおけるアイテムの数が依然として最大希望アイテム数より大きい場合には、ステップ４２２へと続き、勧められるアイテムを、それらが引き出されたところの１組のドメインにわたって拡散することにより、リコメンデーションの第２リストを改善する。

ステップ４２２において、候補アイテムは、規定の「ｓｒｃ＿ｄｏｍａｉｎｓ」パラメータに基づいてドメイングループに分離される。ステップ４２４乃至４２８において、この方法は、ラウンドロビン機構を使用し、各グループを一度に１つ横断する（ステップ４２４）。ステップ４２６では、最も高い相関値を有するリコメンデーションを選択して、リコメンデーションの第４リストを形成する。当業者であれば、他のプライオリティ機構を選択プロセスに使用してもよいことが明らかであろう。ステップ４２４及び４２６は、リコメンデーションの第４リストにおけるアイテムの数が規定の「ｍａｘｉｔｅｍ」に等しくなるまで繰り返される。最終的な結果は、ユーザの好ましいアイテムに対して個人化された第４組のリコメンデーションである。この第４組のリコメンデーションは、「ｍｉｎｉｔｅｍ」及び「ｍａｘｉｔｅｍ」制約を満足すると共に、充分な個人化アイテムが存在する場合には相関値の「ｔｈｒｅｓｈｏｌｄ」も満足する。又、１組の勧められるアイテムは、指定のドメインにわたる均一な選択も反映する。ステップ４３２において、リコメンデーションの第４リストが返送される。この方法は、ステップ４３４で終了となる。

リコメンデーションを作成するためのここに開示するシステムは、既存のシステムに勝る多数の改善を提供する。より詳細には、ここに開示するシステムは、多数のドメインにわたりユーザ入力データを考慮することで、より良好なそしてより関連性のあるリコメンデーションを作成する。より良好なリコメンデーションを作成するこの能力は、ひいては、より良好なユーザの経験を可能にし、そしてより広い範囲の製品又はサービスをユーザに提供することができる。

当業者であれば、同じ基本的なメカニズム及び方法を使用しながら、ここに開示した実施形態の多数の変更を利用できることが明らかであろう。例えば、ユーザの人口統計学的情報のような異なる組の制約を使用して、リコメンデーションを改善することもできる。本発明の一実施形態で開示したラウンドロビン機構に代わって異なるプライオリティ機構を使用してもよい。そして異なるアルゴリズムを使用して、多数のドメインにわたりユーザ入力データ間の相関値を計算することができる。

以上、特定の実施形態を参照して本発明を例示した。しかしながら、この説明は、余すところのないものでもないし、本発明を上述した詳細な形態に限定するものでもない。前記教示に鑑み、多数の変更や修正が考えられる。前記実施形態は、本発明の原理及びその実際の応用を最良に説明するために選択されたものであり、従って、当業者であれば、本発明及び種々の実施形態を、意図された特定の用途に適するように種々変更して最良に使用することができよう。

Claims (29)

1. (1)少なくとも１つのコンピュータが、インターネットを介してユーザとインタフェース接続する少なくとも１つのサーバコンピュータの製品及びサービスに関するマルチドメインから、複数のイベントタイプを含むユーザ事象を受信する段階であって、前記マルチドメインに対するユーザの関与は、データベース内のユーザ事象としてあらわされ、さらに、前記各ユーザ事象は前記ユーザ事象のタイプに関連するユーザ事象パラメータを含み、当該ユーザ事象パラメータには、ドメインと、当該ドメインからのアイテムを識別するアイテム識別子と、事象タイプと、事象値とを含むユーザ事象パラメータとを含んでいる当該段階と、
   (2)前記データベース内にユーザ事象のそれぞれを記憶するかどうかを決定する段階を更に含み、当該決定する段階は、
   (i)前記ユーザ事象のユーザ事象パラメータの有効を確認することを含み、各ユーザ事象パラメータは、各々のユーザ事象パラメータに関して一つの値をもち、
   関連する値が前記データベースに存在するが、前記ユーザ事象パラメータの値が前記データベース内に存在しないことが決定された場合、前記ユーザ事象パラメータは有効であり、
   前記データベースが前記ユーザ事象パラメータの値を含むように更新され得ることが決定されるとき、前記ユーザ事象パラメータは有効であり、
   (ii)前記ユーザ事象パラメータのどれもが無効であると決定された場合、前記ユーザ事象を拒絶すること、
   (iii)前記ユーザ事象のユーザ事象パラメータが有効であると決定された場合、前記ユーザ事象を前記データベースに記憶することを含み、
   (3)前記少なくとも１つのコンピュータが、ユーザに対するアイテムの推奨に関するトリガー事象を受け取る段階と、
   (4)前記少なくとも１つのコンピュータが、少なくとも２つの前記マルチドメインにより前記ユーザの関与によって生じた少なくとも２つのユーザ事象からのユーザ事象パラメータを分析する段階と、
   (5)前記少なくとも１つのコンピュータが、前記データベース内の前記少なくとも２つのユーザ事象間の少なくとも１つの相関であって、それぞれに相関値が割り当てられた当該相関を系統立てる段階と、
   (6)前記少なくとも１つのコンピュータが、前記ユーザに関するデータベース内で識別されたアイテムの推奨を生成する段階であって、推奨されたアイテムは前記少なくとも２つのユーザ事象に関連する少なくとも２つのドメインとは異種の他のドメインから選択され、前記トリガー事象に関連する少なくとも１つのアイテム識別子、及び前記データベースからのユーザ事象を用いながら、且つ、前記少なくとも２つのユーザ事象間の前記少なくとも１つの相関に基づいて前記推奨を生成する段階と、
   を含む方法。
2. 前記ユーザ事象パラメータを有効確認することは、前記ユーザ事象の各ユーザ事象パラメータに関し、
   前記ユーザ事象パラメータの値が前記データベースに存在するかを決定すること、
   前記ユーザ事象パラメータの値が前記データベースに存在しない場合には、前記データベースが前記ユーザ事象パラメータの値を含むように更新できるかどうか判断すること、
   前記値が前記データベースに存在せず、前記ユーザ事象パラメータの値によって前記データベースを更新できることが決定された場合には、前記ユーザ事象パラメータの値を前記データベースに追加すること、
   前記ユーザ事象パラメータの値によって前記データベースを更新できないことが決定された場合には、前記ユーザ事象を拒絶する段階と、
   を含む請求項１に記載の方法。
3. 前記データベースにあるユーザ事象からのユーザ事象パラメータを分析する段階は、
   各相関に割り当てられた前記相関値を前記データベースに記憶すること、
   を含む請求項１又は２に記載の方法。
4. 前記トリガー事象は、アイテムの推奨に関する要求である請求項１〜３の何れか１項に記載の方法。
5. アイテムの推奨を生成する前記段階は、
   少なくとも１つのユーザ事象ドメインパラメータが前記要求中で指定された場合、前記指定された少なくとも１つのユーザ事象ドメインパラメータに基づいて推奨の第１リストを生成する段階であって、前記推奨の第１リストは前記データベースからの１つ以上のアイテムを含み、前記１つ以上のアイテムのそれぞれは前記指定された少なくとも１つのユーザ事象ドメインパラメータによって示されるドメインからのものである当該段階と、
   前記少なくとも１つのユーザ事象ドメインパラメータが前記要求中で指定されていない場合、前記データベース内の前記ユーザ事象ドメインパラメータに基づいて前記推奨の第１リストを生成する段階と、
   を含む請求項４に記載の方法。
6. 前記要求は所定の最小アイテム数を含み、
   アイテムの推奨を生成する前記段階は、
   前記推奨の第１リストが前記所定の最小アイテム数以下のアイテム数を有する場合、前記推奨の第１リストをアイテムの推奨として返送され、
   前記推奨の第１リストの前記アイテム数が前記所定の最小アイテム数より大きい場合、前記要求に含まれる所定の閾値相関を更に用いて実行されることを特徴とする、
   請求項５に記載の方法。
7. 前記要求に含まれる所定の閾値相関を更に用いながらアイテムの推奨を生成する前記段階は、
   前記所定の閾値相関以上の相関値を有する前記推奨の第１リストのアイテムから推奨の第２リストを生成すること、
   前記推奨の第２リストが前記所定の最小アイテム数以下のアイテム数を有する場合、前記推奨の第１リストのアイテムからの相関値に基づいてプライオリティ決めされた前記所定の最小数のアイテムより成る推奨の第３リストを選択し、そしてその推奨の第３リストをアイテムの推奨として返送すること、
   前記推奨の第２リストのアイテム数が前記所定の最小アイテム数より大きい場合、アイテムの推奨を生成する前記段階は、前記要求で示された所定の最大アイテム数を更に用いて実行されること、
   を含む請求項６に記載の方法。
8. 前記要求で示される所定の最大アイテム数を更に用いながらアイテムの推奨を生成する前記段階は、
   前記推奨の第２リストが前記所定の最大アイテム数以下のアイテム数を有する場合、前記推奨の第２リストをアイテムの推奨として返送し、
   前記推奨の第２リストの前記アイテム数が前記所定の最大アイテム数より大きい場合、前記アイテムの推奨である前記推奨の第２リストから前記所定の最大アイテム数を選択することを含む、
   請求項７に記載の方法。
9. 前記アイテムの推奨である前記推奨の第２リストから前記所定の最大アイテム数を選択する段階は、
   前記推奨の第２リストの前記アイテムを前記推奨の第２リスト内の前記アイテムの前記ユーザ事象ドメインパラメータに基づいて複数のグループに分離すること、
   （ａ）各グループに対して、前記グループ内の他のアイテムに関して最大の相関値を有するアイテムを推奨の第４リストのために前記グループから選択し、前記グループから前記選択されたアイテムを除去すること、
   （ｂ）前記推奨の第４リストが前記所定の最大アイテム数に等しい数を含むまで前記段階（ａ）を繰り返すこと、
   前記推奨の第４リストをアイテムの推奨として返送すること、
   を含む請求項８に記載の方法。
10. 前記トリガー事象は、パーソナライズされたアイテムを推奨することに関する、所定の閾値相関を含む要求であり、アイテムの推奨を生成する前記段階は、
    前記ユーザが好みを示したアイテムの第１リストを前記データベースから検索する段階であって、各アイテムが、前記所定の閾値相関以上の相関値を有し、
    （ａ）前記ユーザが好みを示した各アイテムに対して１組の推奨を生成し、
    （ｂ）前記１組の推奨内の前記アイテムを推奨の第１リストに記憶し、
    （ｃ）前記アイテムの第１リストの全メンバーに対して、前記段階（ａ）及び（ｂ）を繰り返し、
    前記要求で示された所定の最小アイテム数に従い、前記推奨の第１リストを用いてアイテムの推奨を生成すること、
    を含む請求項１に記載の方法。
11. 前記要求で示された所定の最小アイテム数に従い、前記推奨の第１リストを用いてアイテムの推奨を生成する前記段階は、
    前記推奨の第１リストが前記所定の最小アイテム数以下のアイテム数を有する場合、前記推奨の第１リストをアイテムの推奨として返送し、
    前記推奨の第１リストの前記アイテム数が前記所定の最小アイテム数より大きい場合、前記推奨の第１リスト、前記所定の最小アイテム数、及び前記所定の閾値相関を更に用いて実行される、
    請求項１０に記載の方法。
12. 前記推奨の第１リスト、前記所定の最小アイテム数、及び前記所定の閾値相関を更に用いてアイテムの推奨を生成する前記段階は、
    前記所定の閾値相関以上の相関値を有する前記推奨の第１リストのアイテムから推奨の第２リストを生成し、
    前記推奨の第２リストが前記所定の最小アイテム数以下の数を有する場合に、前記推奨の第１リストのアイテムからの相関値に基づいてプライオリティ決めされた前記所定の最小数のアイテムより成る推奨の第３リストを選択し、そしてその推奨の第３リストをアイテムの推奨として返送し、
    前記推奨の第２リストのアイテム数が前記所定の最小アイテム数より大きい場合に、前記要求で示された所定の最大アイテム数を更に用いて実行されること、
    を含む請求項１１に記載の方法。
13. 所定の最大アイテム数を更に用いて前記アイテムの推奨を生成する前記段階は、
    前記推奨の第２リストが前記所定の最大アイテム数以下のアイテム数を有する場合には、前記推奨の第２リストをアイテムの推奨として返送すること、
    生成された前記推奨の第２リストの前記アイテム数が前記所定の最大アイテム数より大きい場合には、前記アイテムの推奨である第２リストから前記所定の最大アイテム数を選択すること、
    を含む請求項１２に記載の方法。
14. 前記推奨の第２リストにおける各アイテムは関連するユーザ事象ドメインを有し、前記アイテムの推奨である前記推奨の第２リストから前記所定の最大アイテム数を選択することは、
    前記推奨の第２リストをそれぞれの推奨に関連するユーザ事象ドメインパラメータに基づいて複数のグループに分離すること、
    （ｘ）各グループに対して、推奨の第４リストのために前記グループ内の他のアイテムに関して最大の相関値を有するアイテムを前記グループから選択して、前記選択されたアイテムを前記グループから削除すること、
    （ｙ）前記推奨の第４リストが前記所定の最大アイテム数に等しいアイテム数を有するまで前記段階（ｘ）を繰り返すこと、
    前記推奨の第４リストをアイテムの推奨として返送すること、
    を含む請求項１３に記載の方法。
15. 少なくとも１つのプロセッサ及びメモリを含む少なくとも１つのサーバであって、前記メモリはインストラクションを記憶し、
    前記少なくとも１つのプロセッサは、
    (1)インターネットを介してユーザとインタフェース接続する前記少なくとも１つのサーバコンピュータの製品及びサービスに関するマルチドメインから、複数のイベントタイプを含むユーザ事象を受信し、前記マルチドメインに対するユーザの関与は、データベース内のユーザ事象としてあらわされ、さらに、前記各ユーザ事象は、ドメイン、当該ドメインからのアイテムを識別するアイテム識別子、事象タイプ、及び事象値を含むユーザ事象パラメータを有し、
    (2)前記データベース内にユーザ事象を記憶するかどうかを決定することであって、前記決定は、
    (i)前記ユーザ事象のユーザ事象パラメータの有効を確認することを含み、各ユーザ事象パラメータは、各々のユーザ事象パラメータに関して一つの値をもち、
    関連する値が前記データベースに存在するが、前記ユーザ事象パラメータの値が前記データベース内に存在しないことが決定された場合、前記ユーザ事象パラメータは有効であり、
    前記データベースが前記ユーザ事象パラメータの値を含むように更新され得ることが決定されるとき、前記ユーザ事象パラメータは有効であり、
    (ii)前記ユーザ事象パラメータのどれもが無効であると決定された場合、前記ユーザ事象を拒絶し、そして
    (iii)前記ユーザ事象のユーザ事象パラメータが有効であると決定された場合、前記ユーザ事象を前記データベースに記憶することを含み、
    (3)ユーザに対するアイテムの推奨に関するトリガー事象を受け取ること、
    (4)少なくとも２つの前記マルチドメインにより前記ユーザの関与によって生じた少なくとも２つのユーザ事象からのユーザ事象パラメータを分析すること、
    (5)前記データベース内の前記少なくとも２つのユーザ事象間の少なくとも１つの相関であって、それぞれに相関値が割り当てられた当該相関を系統立て、そして
    (6)前記ユーザに関するデータベース内で識別されたアイテムの推奨を生成することであって、推奨されたアイテムは前記少なくとも２つのユーザ事象に関連する少なくとも２つのドメインとは異種の他のドメインから選択され、前記トリガー事象に関連した少なくとも１つのアイテム識別子及び前記データベースからのユーザ事象を用いながら、且つ、前記少なくとも２つのユーザ事象間の前記少なくとも１つの相関に基づいて前記推奨を生成する、
    ためのインストラクションを実行するサーバを含むシステム。
16. 前記ユーザ事象のユーザ事象パラメータ値を有効確認する前記インストラクションは、前記ユーザ事象の各ユーザ事象パラメータに関し、
    前記ユーザ事象パラメータの値が前記データベースに存在するかを決定すること、
    前記ユーザ事象パラメータの値が前記データベースに存在しない場合には、前記データベースが前記ユーザ事象パラメータの値を含むように更新できるかどうか判断すること、
    前記値が前記データベースに存在せず、前記ユーザ事象パラメータの値によって前記データベースを更新できることが決定された場合には、前記ユーザ事象パラメータの値を前記データベースに追加し、
    前記ユーザ事象パラメータの値によって前記データベースを更新できないことが決定された場合には、前記ユーザ事象を拒絶する、
    ためのインストラクションを含む請求項１５に記載のシステム。
17. 前記データベースにあるユーザ事象からのユーザ事象パラメータを分析する前記インストラクションは、
    各相関に割り当てられた前記相関値を前記データベースに記憶する、
    ためのインストラクションを含む請求項１５に記載のシステム。
18. 前記トリガー事象は、アイテムの推奨に関する要求である請求項１５に記載のシステム。
19. アイテムの推奨を生成する前記インストラクションは、
    少なくとも１つのユーザ事象ドメインパラメータが前記要求中で指定された場合、前記指定された少なくとも１つのユーザ事象ドメインパラメータに基づいて推奨の第１リストを生成し、前記推奨の第１リストは前記データベースからの１つ以上のアイテムを含むものであり、前記１つ以上のアイテムのそれぞれは前記指定された少なくとも１つのユーザ事象ドメインパラメータによって示されるドメインからのものであり、そして
    前記少なくとも１つのユーザ事象ドメインパラメータが前記要求中で指定されていない場合、前記データベース内の前記ユーザ事象ドメインパラメータに基づいて前記推奨の第１リストを生成する、
    ためのインストラクションを含む請求項１８に記載のシステム。
20. 前記要求は所定の最小アイテム数を含み、
    アイテムの推奨を生成する前記インストラクションは、
    前記推奨の第１リストが前記所定の最小アイテム数以下のアイテム数を有する場合、前記推奨の第１リストをアイテムの推奨として返送され、
    前記推奨の第１リストの前記アイテム数が前記所定の最小アイテム数より大きい場合、前記要求に含まれる所定の閾値相関を更に用いて実行される、
    ためのインストラクションを含む請求項１９に記載のシステム。
21. 前記要求に含まれる所定の閾値相関を更に用いながらアイテムの推奨を生成する前記インストラクションは、
    前記所定の閾値相関以上の相関値を有する前記推奨の第１リストのアイテムから推奨の第２リストを生成すること、
    前記推奨の第２リストが前記所定の最小アイテム数以下のアイテム数を有する場合、前記推奨の第１リストのアイテムからの相関値に基づいてプライオリティ決めされた前記所定の最小数のアイテムより成る推奨の第３リストを選択し、そしてその推奨の第３リストをアイテムの推奨として返送すること、
    前記推奨の第２リストのアイテム数が前記所定の最小アイテム数より大きい場合、アイテムの推奨を生成する前記インストラクションは、前記要求で示された所定の最大アイテム数を更に用いて実行される、
    ことを含む請求項２０に記載のシステム。
22. 前記要求で示される所定の最大アイテム数を更に用いながらアイテムの推奨を生成する前記インストラクションは、
    前記推奨の第２リストが前記所定の最大アイテム数以下のアイテム数を有する場合、前記推奨の第２リストをアイテムの推奨として返送し、
    前記推奨の第２リストの前記アイテム数が前記所定の最大アイテム数より大きい場合、前記アイテムの推奨である前記推奨の第２リストから前記所定の最大アイテム数を選択する、
    ためのインストラクションを更に含む請求項２１に記載のシステム。
23. 前記アイテムの推奨である前記推奨の第２リストから前記所定の最大アイテム数を選択するインストラクションは、
    前記推奨の第２リストの前記アイテムを前記推奨の第２リスト内の前記アイテムの前記ユーザ事象ドメインパラメータに基づいて複数のグループに分離し、
    （ａ）各グループに対して、前記グループ内の他のアイテムに関して最大の相関値を有するアイテムを推奨の第４リストのために前記グループから選択し、前記グループから前記選択されたアイテムを除去し、
    （ｂ）前記推奨の第４リストが前記所定の最大アイテム数に等しい数を含むまで前記（ａ）を繰り返し、
    前記推奨の第４リストをアイテムの推奨として返送する、
    ためのインストラクションを更に含む請求項２２に記載のシステム。
24. 前記トリガー事象は、パーソナライズされたアイテムを推奨することに関する、所定の閾値相関を含む要求であり、アイテムの推奨を生成する前記インストラクションは、
    前記ユーザが好みを示したアイテムの第１リストを前記データベースから検索することであって、各アイテムが、前記所定の閾値相関以上の相関値を有し、
    （ａ）前記ユーザが好みを示した各アイテムに対して１組の推奨を生成し、
    （ｂ）前記１組の推奨内の前記アイテムを推奨の第１リストに記憶し、
    （ｃ）前記アイテムの第１リストの全メンバーに対して、前記（ａ）及び（ｂ）を繰り返し、
    前記要求で示された所定の最小アイテム数に従い、前記推奨の第１リストを用いてアイテムの推奨を生成する、
    ためのインストラクションを含む請求項１５に記載のシステム。
25. 前記要求で示された所定の最小アイテム数に従い、前記推奨の第１リストを用いてアイテムの推奨を生成する前記インストラクションは、
    前記推奨の第１リストが前記所定の最小アイテム数以下のアイテム数を有する場合、前記推奨の第１リストをアイテムの推奨として返送し、
    前記推奨の第１リストの前記アイテム数が前記所定の最小アイテム数より大きい場合、前記推奨の第１リスト、前記所定の最小アイテム数、及び前記所定の閾値相関を更に用いて実行される、
    ためのインストラクションを含む請求項２４に記載のシステム。
26. 前記推奨の第１リスト、前記所定の最小アイテム数、及び前記所定の閾値相関を更に用いてアイテムの推奨を生成する前記インストラクションは、
    前記所定の閾値相関以上の相関値を有する前記推奨の第１リストのアイテムから推奨の第２リストを生成し、
    前記推奨の第２リストが前記所定の最小アイテム数以下の数を有する場合に、前記推奨の第１リストのアイテムからの相関値に基づいてプライオリティ決めされた前記所定の最小数のアイテムより成る推奨の第３リストを選択し、そしてその推奨の第３リストをアイテムの推奨として返送し、
    前記推奨の第２リストのアイテム数が前記所定の最小アイテム数より大きい場合に、前記要求で示された所定の最大アイテム数を更に用いて実行される、
    ためのインストラクションを含む請求項２５に記載のシステム。
27. 所定の最大アイテム数を更に用いて前記アイテムの推奨を生成する前記インストラクションは、
    前記推奨の第２リストが前記所定の最大アイテム数以下のアイテム数を有する場合には、前記推奨の第２リストをアイテムの推奨として返送し、
    生成された前記推奨の第２リストの前記アイテム数が前記所定の最大アイテム数より大きい場合には、前記アイテムの推奨である第２リストから前記所定の最大アイテム数を選択する、
    ためのインストラクションを含む請求項２６に記載のシステム。
28. 前記推奨の第２リストにおける各アイテムは関連するユーザ事象ドメインを有し、前記アイテムの推奨である第２リストから前記所定の最大アイテム数を選択するインストラクションは、
    前記推奨の第２リストをそれぞれの推奨に関連するユーザ事象ドメインパラメータに基づいて複数のグループに分離し、
    （ｘ）各グループに対して、推奨の第４リストのために前記グループ内の他のアイテムに関して最大の相関値を有するアイテムを前記グループから選択して、前記選択されたアイテムを前記グループから削除し、
    （ｙ）前記推奨の第４リストが前記所定の最大アイテム数に等しいアイテム数を有するまで前記（ｘ）を繰り返し、
    前記推奨の第４リストをアイテムの推奨として返送する、
    ためのインストラクションを更に含む請求項２７に記載のシステム。
29. １つ以上のコンピュータシステムにより実行するためのコンピュータプログラムを記憶するコンピュータ読み取り可能記録媒体において、前記コンピュータプログラムは、
    (1)インターネットを介してユーザとインタフェース接続する少なくとも１つのサーバコンピュータの製品及びサービスに関するマルチドメインから、複数のイベントタイプを含むユーザ事象を受信し、前記マルチドメインに対するユーザの関与は、データベース内のユーザ事象としてあらわされ、さらに、前記各ユーザ事象は、前記ユーザ事象のタイプに関連するユーザ事象パラメータを含み、当該ユーザ事象パラメータには、ドメインと、当該ドメインからのアイテムを識別するアイテム識別子と、事象タイプと、事象値を含むものであり、
    (2)前記データベース内にユーザ事象のそれぞれを記憶するかどうかを決定することを更に含み、当該決定することは、
    (i)前記ユーザ事象のユーザ事象パラメータの有効を確認することを含み、各ユーザ事象パラメータは、各ユーザ事象パラメータに関する値をもち、
    関連する値が前記データベースに存在するが、前記ユーザ事象パラメータの値が前記データベース内に存在しないことが決定された場合、前記ユーザ事象パラメータは有効であり、
    前記データベースが前記ユーザ事象パラメータの値を含むように更新され得ることが決定されるとき、前記ユーザ事象パラメータは有効であり、
    (ii)前記ユーザ事象パラメータのどれもが無効であると決定された場合、前記ユーザ事象を拒絶すること、
    (iii)前記ユーザ事象のユーザ事象パラメータが有効であると決定された場合、前記ユーザ事象を前記データベースに記憶すること、を含み、
    (3)ユーザに対するアイテムの推奨に関するトリガー事象を受け取り、
    (4)少なくとも２つの前記マルチドメインにより前記ユーザの関与によって生じた少なくとも２つのユーザ事象からのユーザ事象パラメータを分析し、
    (5)前記データベース内の前記少なくとも２つのユーザ事象間の少なくとも１つの相関を系統立て、前記各相関には１つの相関値が割り当てられており、そして
    (6)前記ユーザに関するデータベース内で識別されたアイテムの推奨を生成することであって、推奨されたアイテムは前記少なくとも２つのユーザ事象に関連する少なくとも２つのドメインとは異種の他のドメインから選択され、前記トリガー事象に関連する少なくとも１つのアイテム識別子、及び前記データベースからのユーザ事象を用いながら、且つ、前記少なくとも２つのユーザ事象間の前記少なくとも１つの相関に基づいて前記推奨を生成する、
    ためのインストラクションを含むコンピュータ読み取り可能記録媒体。

Images