(57)【要約】グループのメンバに対する推奨アイテムを生成する方法は、複数のユーザをグループのメンバとして登録すること、ユーザのグループのメンバのサブグループを識別することであって、サブグループは推奨エンジンに推奨アイテムを要求すること、多腕バンディットアルゴリズムを使用してメンバのサブグループに対する推奨アイテムを計算することを含む。推奨アイテムは、それらの評価のためにサブグループメンバに提供される。個々のユーザは、推奨アイテムを評価した後、推奨アイテムをレーティングし、これにより、推奨エンジンは、サブグループのメンバを表す選好で更新される。
2015513154.tif 000002
【特許請求の範囲】
【請求項１】
ユーザグループのメンバに対する推奨アイテムを生成する装置によって実施される方法であって、
前記ユーザグループのメンバを登録することと、
前記ユーザグループのサブグループを識別することであって、前記サブグループは前記装置に推奨アイテムを要求することと、
前記サブグループに対する推奨アイテムを決定することであって、前記推奨アイテムは、対数リグレット特性を有する多腕バンディットアルゴリズムを使用して決定されることと、
前記推奨アイテムを前記ユーザグループのメンバの前記サブグループに提供するステップと、
を含む、前記方法。
【請求項２】
前記推奨アイテムを決定することは、時間ｔにおける重みベクトルを使用することをさらに含み、前記重みベクトルは時間ｔにおける個々のサブグループメンバの重みを表す、請求項１に記載の方法。
【請求項３】
前記推奨アイテムを決定することは、前記個々のサブグループメンバによって受け取られた、過去の重みベクトル、過去のジャンル、および過去のレーティングを使用することをさらに含む、請求項２に記載の方法。
【請求項４】
前記推奨アイテムを決定することは、カテゴリのセットからカテゴリを選択し選択された前記カテゴリ内で推奨アイテムを選択するステップを含む、請求項１に記載の方法。
【請求項５】
さらに、前記カテゴリは映画ジャンルまたは食事料理である、請求項４に記載の方法。
【請求項６】
前記サブグループによって前記推奨アイテムを受諾または拒否するステップと、
選択された前記推奨アイテムを評価およびレーティングするステップと、
をさらに含む、請求項１に記載の方法。
【請求項７】
前記選択されたアイテムをレーティングするステップは、選択された前記推奨アイテムのレーティングを前記サブグループのメンバによって個別に提供することを含む、請求項６に記載の方法。
【請求項８】
ユーザグループに推奨アイテムを提供するための装置であって、
１または複数のユーザデバイスと通信するためのインタフェースと、
前記ユーザグループのサブグループに提案すべき推奨アイテムを決定するためのプログラムを実行するプロセッサと、
前記プログラムを記憶するための前記プロセッサによって利用可能なメモリであって、前記プログラムは、前記プロセッサによって実行されたとき、対数リグレット特性を有する多腕バンディットアルゴリズムを利用して前記推奨アイテムを決定する、メモリと、を備える、前記装置。
【請求項９】
前記プロセッサは、最初にカテゴリのセットからカテゴリを選択し、次いで前記選択されたカテゴリ内で推奨アイテムを選択することによって、前記推奨アイテムを決定する、請求項８に記載の装置。
【請求項１０】
前記プロセッサーは、時間ｔにおける重みベクトルを使用して前記推奨アイテムを決定し、前記重みベクトルは時間ｔにおける個々のサブグループメンバの重みを表す、請求項８に記載の装置。
【請求項１１】
１または複数のユーザデバイスと通信するための前記インタフェースは、前記１または複数のユーザデバイスに取り付けられたネットワークインタフェースを含み、前記インタフェースは前記推奨アイテムを前記装置のユーザに送達するのに有用である、請求項８に記載の装置。
【請求項１２】
１または複数のユーザデバイスと通信するための前記インタフェースは、前記推奨アイテムに関するレーティング情報を前記１または複数のユーザデバイスから前記装置に転送するように機能する、請求項１１に記載の装置。
【請求項１３】
前記プロセッサーは、前記サブグループの各メンバに割り当てられた異なる重みを適用して、前記多腕バンディットアルゴリズムを使用して前記サブグループの各メンバから前記レーティング情報を別々に収集して処理する、請求項１２に記載の装置。
【請求項１４】
前記装置は、テレビジョン、モデム、ルータ、セットトップボックス、のうちの１つを含む、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータによって生成される、ユーザのグループに対する推奨に関する。特に、本発明は、ユーザインタフェースを有するモバイルおよび他のコンピューティングデバイスなどのインタフェースデバイスの使用を通して、コンピュータによって生成される推奨を既知のユーザグループに対して生成することに関する。
【背景技術】
【０００２】
関連出願の相互参照
本出願は、２０１２年３月８日に出願された「Ｍｅｔｈｏｄ  ｆｏｒ  Ｒｅｃｏｍｍｅｎｄｉｎｇ  Ｉｔｅｍｓ  ｔｏ  ａ  Ｇｒｏｕｐ  ｏｆ  Ｕｓｅｒｓ」という名称の米国特許仮出願第６１／６０８，１７１号明細書に対する優先権を主張するものであり、この仮出願の全体はあらゆる目的のために参照により本明細書に組み込まれる。
【０００３】
定期的に集まって映画鑑賞やレストランでの食事などのソーシャルアクティビティを実施する人々のグループを考えてみる。これらの人々は、例えば、テレビの前に座って映画を見る家族、映画館に行く友人のグループ、または、どのレストランで昼食をとるか決めたい同僚のグループとすることができる。ソーシャルアクティビティは複数回行われ、アクティビティに参加する人は、あるセッションから次のセッションに変わる場合がある。各セッションで、参加者は、多くの可能なオプションのうちの１つを選択することによって、アクティビティに携わることができる。例えば、映画を見るとき、参加者は、ホラー、アクション、ロマンティックなど、多くの異なるジャンルの中から映画を選ぶことができる。レストラン選択の場合、参加者は、イタリアンや中華など、複数の料理のうちの１つを選ぶことができる。
【０００４】
グループに対する推奨を生成する際の問題の１つは、以下の場合を仮定して、システム中に存在する参加者のグループの関心に最もよく合致するオプションをどのように選択するかである。すなわち、（ａ）オプション（ジャンルまたは料理）への彼らの関心が、アプリオリに知られておらず、彼らがソーシャルアクティビティへの参加後に提供するフィードバック（例えば、ホラー映画を視聴してレーティングする、またはイタリアンレストランで食事する）からのみ明らかにされ、また、（ｂ）グループが、あるセッションから次のセッションに変わる可能性がある場合である。
【０００５】
グループに対する推奨に関する従来の研究は、多くの異なる応用例によって鼓舞されてきた。例えば、Ｊ．Ｍａｓｔｈｏｆｆは、一連のディジタルＴＶ番組をグループに対して推奨する（例えば、非特許文献１参照）。観光旅行提案もまた、人気のあるトピックである。Ｇ．Ｐ．Ｌｉｌｉａｎａ  Ａｒｄｉｓｓｏｎｏ、Ａｎｎａ  Ｇｏｙ、Ｍ．Ｓｅｇｎａｎ、およびＰ．Ｔｏｒａｓｓｏ、ならびにＬ．Ｃ．Ｋｅｖｉｎ  ＭｃＣａｒｔｈｙ、Ｍａｒｉａ  Ｓａｌａｍ、Ｌ．ＭｃＧｉｎｔｙ、Ｂ．Ｓｍｙｔｈ、およびＰ．Ｎｉｘｏｎは、友人または観光旅行客グループが休暇または観光ツアーを計画するのを補助する（例えば、非特許文献２および非特許文献３参照）。グループモデラ（Group Modeler）は、博物館をグループで訪れる人々に向けて設計されている（例えば、非特許文献４参照）。Ｊ．Ｆ．ＭｃＣａｒｔｈｙは、同僚が一緒に食事に出かけることを対象とする（例えば、非特許文献５参照）。別の応用例は、音楽を推奨することである。Ａ．Ｔ．Ｊｏｓｅｐｈ  Ｆ．ＭｃＣａｒｔｈｙは、ジムで運動する人々に対して音楽局を推奨する（例えば、非特許文献６参照）。
【０００６】
グループ推奨に関する過去の研究は主に、個人よりもグループを満足させながら最適化するための「目的」関数を識別することに焦点を合わせていた。いくつかの場合では、目的関数は、正式に定義され守られる。社会的選択理論に鼓舞されて、Ｊ．Ｍａｓｔｈｏｆｆは、「平均戦略」、「ミザリーなし平均戦略」、および「最小ミザリー戦略」のような戦略を考察および検討した。他の場合では、著者らは、グループ推奨を行うための特定のアルゴリズムを提案しているが、これらのアルゴリズムは、グループにわたる何らかの複雑な目的関数を暗黙的に最適化する。Ｇ．Ｊ．−Ｄ．Ｊｕａｎ  Ａ  Ｒｅｃｉｏ−Ｇａｒｃｉａ、Ａ．Ａ．Ｓａｎｃｈｅｚ−Ｒｕｉｚ、およびＢ．Ｄｉａｚ−Ａｇｕｄｏは、協調フィルタリング技法を使用して、推奨を行い、パーソナリティ組成を考慮する（例えば、非特許文献７参照）。Ａ．Ｃ．Ｓｉｈｅｍ  ＡｍｅｒＹａｈｉａ、Ｓｅｎｊｕｔｉ  Ｂａｓｕ  Ｒｏｙ、Ｇ．Ｄａｓ、およびＣ．Ｙｕは、グループに対するアイテム関連性とグループメンバ間の不一致とを考慮した、グループ推奨のセマンティックを提案する（例えば、非特許文献８参照）。高い関連性スコアおよび低い不一致スコアを有するアイテムが、推奨すべき候補である。彼らは、トップｋアルゴリズムを使用して、ｋ個の候補を効率的に選ぶ。Ｆ．Ｒ．Ｌｉｎａｓ  Ｂａｌｔｒｕｎａｓ、Ｔａｄａｓ  Ｍａｋｃｉｎｓｋａｓは、協調フィルタリングとランク集約とを組み合わせる（例えば、非特許文献９参照）。彼らは、最初に、グループ中の各ユーザに対するランク付けされた推奨リストを作成し、次いで、リストを集約して、グループに対する共通アイテムを含むランク付けされたリストを作成する。Ｊ．Ｆ．Ｓｈｌｏｍｏ  Ｂｅｒｋｏｖｓｋｙは、やはり協調フィルタリング技法を利用するが、ユーザ・プロファイルをグループ・プロファイルに集約してから、集約されたプロファイルに対して協調フィルタリングを適用する（例えば、非特許文献１０参照）。あるグループに対する推奨は、他の類似のグループの選好に基づいて行われる。本発明者らの知る限り、時間の経過に伴うグループメンバのダイナミクス、または時間の経過に伴う学習など、本発明によって対処されるグループ推奨の課題に対処する従来の研究はない。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「Ｇｒｏｕｐ  ｍｏｄｅｌｉｎｇ：Ｓｅｌｅｃｔｉｎｇ  ａ  ｓｅｑｕｅｎｃｅ  ｏｆ  ｔｅｌｅｖｉｓｉｏｎ  ｉｔｅｍｓ  ｔｏ  ｓｕｉｔ  ａ  ｇｒｏｕｐ  ｏｆ  ｖｉｅｗｅｒｓ，２００４」
【非特許文献２】Ｉｎｔｒｉｇｕｅ：「Ｐｅｒｓｏｎａｌｉｚｅｄ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  ｏｆ  ｔｏｕｒｉｓｔ  ａｔｔｒａｃｔｉｏｎｓ  ｆｏｒ  ｄｅｓｋｔｏｐ  ａｎｄ  ｈａｎｄｓｅｔ  ｄｅｖｉｃｅｓ」、Ａｐｐｌｉｅｄ  Ａｒｔｉｆｉｃｉａｌ  Ｉｎｔｅｌｌｉｇｅｎｃｅ、６８７〜７１４頁、２００３年
【非特許文献３】Ｃａｔｓ：「Ａ  ｓｙｎｃｈｒｏｎｏｕｓ  ａｐｐｒｏａｃｈ  ｔｏ  ｃｏｌｌａｂｏｒａｔｉｖｅ  ｇｒｏｕｐ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎ」、Ｔｈｅ  Ｎｉｎｅｔｅｅｎｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｆｌｏｒｉｄａ  Ａｒｔｉｆｉｃｉａｌ  Ｉｎｔｅｌｌｉｇｅｎｃｅ  Ｒｅｓｅａｒｃｈ  Ｓｏｃｉｅｔｙ  Ｃｏｎｆｅｒｅｎｃｅ、２００６年
【非特許文献４】Ｗ．Ｎ．Ｊ．Ｋａｙ、「Ａｄａｐｔｉｎｇ  ｉｎｆｏｒｍａｔｉｏｎ  ｄｅｌｉｖｅｒｙ  ｔｏ  ｇｒｏｕｐｓ  ｏｆ  ｐｅｏｐｌｅ」、Ｆｉｒｓｔ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｎｅｗ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  ｆｏｒ  Ｐｅｒｓｏｎａｌｉｚｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ａｃｃｅｓｓ、１０ｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｕｓｅｒ  Ｍｏｄｅｌｉｎｇ、２００５年
【非特許文献５】ｐｏｃｋｅｔ  ｒｅｓｔａｕｒａｎｔ  ｆｉｎｄｅｒ：「Ａ  ｓｉｔｕａｔｅｄ  ｒｅｃｏｍｍｅｎｄｅｒ  ｓｙｓｔｅｍ  ｆｏｒ  ｇｒｏｕｐｓ」、Ｔｈｅ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｍｏｂｉｌｅ  Ａｄ−Ｈｏｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＣＨＩ、２００２年
【非特許文献６】Ｍｕｓｉｃｆｘ：「Ａｎ  ａｒｂｉｔｅｒ  ｏｆ  ｇｒｏｕｐ  ｐｒｅｆｅｒｅｎｃｅｓ  ｆｏｒ  ｃｏｍｐｕｔｅｒ  ｓｕｐｐｏｒｔｅｄ  ｃｏｌｌａｂｏｒａｔｉｖｅ  ｗｏｒｋｏｕｔｓ」、Ｃｏｍｐｕｔｅｒ−Ｓｕｐｐｏｒｔｅｄ  Ｃｏｏｒｐｅｒａｔｉｖｅ  Ｗｏｒｋ、１９９８年
【非特許文献７】「Ｐｅｒｓｏｎａｌｉｔｙ  ａｗａｒｅ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ  ｔｏ  ｇｒｏｕｐｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ｔｈｉｒｄ  ＡＣＭ  ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｒｅｃｏｍｍｅｎｄｅｒ  Ｓｙｓｔｅｍｓ  ＲｅｃＳｙｓ、２００９年
【非特許文献８】「Ｇｒｏｕｐ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ：Ｓｅｍａｎｔｉｃｓ  ａｎｄ  ｅｆｆｉｃｉｅｎｃｙ」、ＶＬＤＢ、２００９年
【非特許文献９】「Ｇｒｏｕｐ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ  ｗｉｔｈ  ｒａｎｋ  ａｇｇｒｅｇａｔｉｏｎ  ａｎｄ  ｃｏｌｌａｂｏｒａｔｉｖｅ  ｆｉｌｔｅｒｉｎｇ」、Ｒｅｃｓｙｓ、２０１０年
【非特許文献１０】「Ｇｒｏｕｐ−ｂａｓｅｄ  ｒｅｃｉｐｅ  ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ：ａｎａｌｙｓｉｓ  ｏｆ  ｄａｔａ  ａｇｇｒｅｇａｔｉｏｎ  ｓｔｒａｔｅｇｉｅｓ」、Ｒｅｃｓｙｓ、２０１０年
【発明の概要】
【０００８】
この概要は、詳細な記述においてさらに後述する概念の精選を単純化した形で紹介するために提供するものである。この概要は、特許請求される主題の重要な特徴または必須の特徴を識別するものとはせず、また、特許請求される主題の範囲を制限するために使用されるものともしない。
【０００９】
本発明は、映画やレストランなどの推奨アイテムをユーザのグループに対して推奨する方法を決定する。この方法は、映画を見る家族、または昼食に出かける同僚のグループなど、グループのメンバが不定期に現れてソーシャルアクティビティに参加する可能性のある、合同ソーシャルアクティビティを実施する人々の動的なグループに対処することができる。この方法は、ユーザがどのように推奨に反応するかを、ユーザが提供したフィードバックから学習し、ソーシャルアクティビティに現れる参加者を満足させながら彼らの関心も探索するという二重の目標を満たす推奨を提供し、それにより、推奨の品質を毎回向上させる。
【００１０】
本発明では、多腕バンディット数学的手法を使用して、グループ推奨の提供に関して上に参照した課題に対処する。多腕バンディットの数学理論は広範であり、多くのアーム、遅延、アーム間の依存性などから検討された、無数のバージョンがある。それでもなお、時間の経過に伴って複数の異なるグループ中にユーザが現れる本発明による変形は、発明的なアルゴリズムのとおり新しい。関連の研究には、いわゆる線形またはコンテキスト依存バンディット（contextual bandit）があり、これらは、グループレベル推奨レベルではなく個別ユーザ推奨レベルで個人化された推奨に適用されてきた。コンテキスト依存バンディットでは、アームの報酬を、観察可能なコンテキストベクトルと１組の潜在性変数との内積として表現することができる。本発明の手法は、従来技術におけるように最終的なグループレーティングへのアクセスを有するだけではなく、ユーザの個別レーティングへのアクセスも有することによって、従来技術のコンテキスト依存バンディットから逸脱する。ユーザの個別レーティングは、潜在性であり、標準的な従来技術のコンテキスト依存バンディットモデル中では観察されない。従来技術は、レーティングの合計のみが知られており個別レーティングは知られていない設定におけるアルゴリズムを考案した。本発明の一態様では、有利にも、従来技術の方法でこれまで抑制されていた個別レーティングが使用される。これにより、本発明は、リグレット（これは通常、コンテキスト依存バンディットに対する対数でない）と呼ばれる尺度から見て、よりよい境界を得ることができる。
【００１１】
本発明の一特徴では、グループのメンバに対する推奨アイテムを生成する方法は、複数のユーザをグループのメンバとして登録すること、ユーザのグループのメンバのサブグループを識別することであって、サブグループは推奨エンジンに推奨アイテムを要求すること、多腕バンディットアルゴリズムを使用してメンバのサブグループに対する推奨アイテムを計算することを含む。推奨アイテムは、それらの評価のためにサブグループメンバに提供される。個々のユーザは、推奨アイテムを評価した後、推奨アイテムをレーティングし、これにより、推奨エンジンは、サブグループのメンバを表す選好で更新される。
【００１２】
添付の図を参照しながら進める、説明に役立つ実施形態に関する後続の詳細な記述から、本発明の追加の特徴および利点が明らかにされるであろう。
【図面の簡単な説明】
【００１３】
前述の本発明の概要、ならびに例示の実施形態に関する後続の詳細な記述は、添付の図面と共に読めばよりよく理解される。添付の図面は、特許請求される本発明に関する制限としてではなく例として含めるものである。
【図１】本発明の態様に従う、複数のユーザデバイスが推奨エンジンに相互接続された一実施形態を示す図である。
【図２】本発明の態様に従う、推奨エンジンを有するスマートＴＶの一実施形態を示す図である。
【図３】本発明の態様に従う、クラウドリソースを使用して推奨エンジンを収容する一実施形態を示す図である。
【図４】本発明の態様に従う、使用の例示的な流れ図を示す図である。
【図５】本発明の態様に従う例示的なユーザデバイスを示す図である。
【図６】本発明の態様に従う例示的な推奨エンジンを示す図である。
【発明を実施するための形態】
【００１４】
例示の様々な実施形態に関する後続の記述では、添付の図面を参照する。添付の図面は後続の記述の一部をなし、添付の図面には、本発明をその中で実践できる様々な実施形態が例示として示されている。本発明の範囲を逸脱することなく、他の実施形態を利用してもよいこと、ならびに構造上および機能上の修正を加えてもよいことを理解されたい。
【００１５】
本発明の一特徴では、グループ推奨が多腕バンディット問題として定式化される。古典的かつ周知の多腕バンディットアルゴリズムでは、ギャンブラおよびアームの関数を識別することができる。本発明では、ギャンブラは、リコメンダまたは推奨エンジンに取って代わられ、アームは、オブジェクトのカテゴリに取って代わられる。特に、本発明では、定期的に集まって映画鑑賞やレストランでの食事などのソーシャルアクティビティを実施するｄ＝｜Ｇ｜ユーザのグループＧを考える。アクティビティに参加するユーザは、あるセッションから次のセッションに変更する場合があり、これは、Ｓ（ｔ）⊂Ｇ、ｔ＝０，１，２，．．．、すなわち、ｔ番目のセッション中に存在するユーザのセットによって示される。推奨エンジンとして実現されるリコメンダは、ソーシャルアクティビティがそれを中心に展開することになる新しいオブジェクト（例えば映画またはレストラン）の提案が各セッションで行われるように、設計される。提案されるオブジェクトは、Ｋ個の異なるカテゴリのうちの１つに属してよい。例えば、映画カテゴリは、ジャンル（喜劇、アクション、ホラーなど）に対応してよく、レストランカテゴリは、料理（中華、イタリアンなど）に対応してよい。この実施形態の場合、モデルを多くのグループ状況に一般化できることを念頭に置いた上で、推奨エンジンによって、オブジェクトを映画として提案することができ、カテゴリをジャンルとして提案することができる。
【００１６】
特に、各セッションで、推奨エンジンは、修正された多腕バンディット（ＭＭＡＢ）アルゴリズムを使用してジャンルを選択する。次いで、このジャンルからの映画を、セッション中に存在するユーザに提案することで進行する。Ａが、｜Ａ｜＝Ｋ、すなわち全ての可能なジャンルのセットで示される。理想的には、推奨エンジンは、現在のセッション中に存在するユーザの選好に最もよく合致するジャンルを選択すべきである。ｕ∈Ｇに映画が提案されたときはいつでも、その満足度が、実数値のレーティングによって測定される。これは例えば、星１つと５つの間のレーティング、または、０（最低レーティング）と１（最高レーティング）の間の端数レーティングとすることができる。
【００１７】
各セッションｔで、映画が提案された後、Ｓ（ｔ）中のユーザは、自分のレーティングを推奨エンジンに開示することによって、自分の満足度を報告する。ユーザは、提案された映画を視聴する必要はない。例えば、ユーザは、過去にすでに見た映画についてすぐにレーティングを提供して、別の推奨を請う（すなわち別のセッションを保持する）ことに進む。総計グループレーティングを介してグループ満足度が測定されるが、総計グループレーティングは、存在する個人のレーティングの一次関数である。特に、ユーザｕ∈Ｓ（ｔ）によって提供されたレーティングがｒｕ（ｔ）であるとすると、グループレーティングは、Σｕ∈Ｓ（ｔ）ｘｕ（ｔ）＊ｒｕ（ｔ）によって与えられ、ここで、ｘｕ（ｔ）は、ユーザｕ∈Ｓ（ｔ）の重みである。ユーザの重みは、リコメンダによって選択される設計パラメータであり、ユーザｕの意見に割り当てる重要性を取り込むためにリコメンダによって使用される。異なる重みを選ぶことにより、異なるタイプの総計「グループレーティング」を取り込むことができる。例えば、ｘｕ（ｔ）＝１に設定すると、総計グループレーティングは、システム中に存在するユーザのレーティングの合計に等しくなり、ｘｕ（ｔ）＝ｗｕに設定すると、いくつかのｗｕについて、異なる重みが異なるユーザに与えられる。
【００１８】
ｔ番目のセッションで推奨エンジンによって選択されるジャンルを、ａ（ｔ）∈Ａとする。推奨エンジンは、以下の情報に基づいてジャンルａ（ｔ）を選択する。
【００１９】
１．時間ｔにおける重みベクトルｘ（ｔ）
２．τ＜ｔについて、ユーザｕ∈Ｓ（τ）によって受け取られた、過去の重みベクトルｘ（τ）、ジャンルａ（τ）、およびレーティングｒｕ（τ）
推奨エンジンは時間ｔにおける重みベクトルを知っていることに留意されたい。例えば、重みがｗｕによって与えられる場合、このことは、推奨エンジンが、相対的な重みｗｕへのアクセス、ならびに、時間ｔにおける存在するユーザＳ（ｔ）のユーザのグループまたはサブグループの組成へのアクセスを有することを意味する。一方、時間ｔにおけるユーザのレーティングは、映画提案の後でしか明らかにされず、したがって将来のジャンル選択でしか使用することができない。提案するポリシに関するより詳細な記述を以下に提供する。
【００２０】
ＭＭＡＢ推奨エンジンは、全てのユーザｕ∈Ｇおよび全てのジャンルａ∈Ａについて、以下の量θｕ，ａの推定値を維持する。すなわち、ｕが、ジャンルａからの映画をこれまでにｓ回レーティングした場合、量θｕ，ａは、経験的平均
【００２１】
【数１】
2015513154.tif 000003
【００２２】
であり、上式で、ｒｕは、ユーザｕがジャンルａからのτ番目の映画に与えたレーティングである。さらに、推奨エンジンは、何回ユーザがアクティビティに参加して特定のジャンルが表示されたかを、常にを記憶している。より正式には、イベントＥの特性関数を
【００２３】
【数２】
2015513154.tif 000004
【００２４】
とする（Ｅが真ならば１、そうでないならば０）。推奨エンジンは、
【００２５】
【数３】
2015513154.tif 000005
【００２６】
すなわちセッションＴまでにｕが存在してジャンルａからの映画が提案された回数を記憶しならびに、
【００２７】
【数４】
2015513154.tif 000006
【００２８】
セッションＴまでにｕが存在した回数を、常に記憶している。上記の量を使用して、推奨エンジンは、以下のようにジャンルを選択する。ｔ番目のセッションで、推奨エンジンは最初に、グループＳ（ｔ）の現在の組成および現在の重みベクトルｘ（ｔ）を観察する。選択されるジャンルは、以下のように定義される多腕バンディットアームによって与えられる。
【００２９】
【数５】
2015513154.tif 000007
【００３０】
その後、推奨エンジンは、このジャンルからの映画をＳ（ｔ）中のユーザに提案し、ユーザは、レーティングを推奨エンジンに提供することによって反応する。次いで、このレーティングを使用して、多腕バンディットアルゴリズムアームａ＝ａ（ｔ）およびユーザｕ∈Ｓ（ｔ）について推定値θｕ，ａが更新される。直観的に、ジャンル選択のための上記の戦略は、これまでに開示されたようにユーザの関心に合うジャンルからの映画を表示することと、ユーザの関心がまだよくわかっていない（すなわちｎｕ，ａが低い）ジャンルをも好むこととを両立させる（ｓｔｒｉｋｅ  ａ  ｂａｌａｎｃｅ）。これにより、推奨エンジンが過去の重みベクトルに関する情報をユーザおよびグループレビューから集める前に、新しいジャンルを最初に提案することができる。別の言い方をすれば、推奨エンジンは、存在するグループメンバ内での予想レーティングが高いカテゴリを選択し（推定値θｕ，ａを介して）、かつ、これらのメンバがあまりレーティングしなかったカテゴリも選択する（ｎｕ，ａを介して）ことによって、存在するメンバに合わせてグループ推奨をカスタマイズする。
【００３１】
ベクトルｘ∈Ｘを仮定した場合、最適なジャンルａ＊（ｘ）は、予想グループレーティングを最大化するジャンルであり、すなわち以下のとおりである。
【００３２】
【数６】
2015513154.tif 000008
【００３３】
ポリシ｛ａ（ｔ）｝ｔ＝１Ｔを仮定した場合、リコメンダのリグレット特性は、Ｔ回のセッションの後、以下のように定義される。
【００３４】
【数７】
2015513154.tif 000009
【００３５】
上式で、ａ＊（ｘ（ｔ））は、時間ｔで最適なジャンルである。言い換えれば、古典的な従来技術の多腕バンディット問題と同様、リグレットは、最適なポリシとポリシ｛ａ（ｔ）｝ｔ＝１Ｔの、予想報酬間の差である。しかし、古典的な設定とは対照的に、本発明における最適なアームは、重みベクトルｘ（ｔ）に依存するので、セッションごとに変わる場合がある。前と同様、ポリシがランダムな場合、リグレットは、｛ａ（ｔ）｝ｔ＝１Ｔの全てのサンプル経路にわたる予想として定義される。
【００３６】
しかし、本発明者は、グループのサブセットの個別ユーザレーティングが考慮された場合に、本発明のリグレット特性が線形ではなく対数であると決定した。特に、本発明のリグレット特性は、下式に従って境界をつけることができる。
【００３７】
ｘ∈Ｘを仮定した場合、ｘのもとでの準最適ジャンルのセットをＢｘ⊂Ａによって示す。すなわち、Ｂｘ＝｛ａ∈Ａ：〈ｘ，θａ＊（ｘ）〉＞〈ｘ，θａ〉｝である。さらに、
【００３８】
【数８】
2015513154.tif 000010
【００３９】
とする。その場合、
【００４０】
【数９】
2015513154.tif 000011
【００４１】
である。上記の境界は、本発明の方法が、ユーザ選好の全景を有する最適なポリシと比較して対数リグレットを達成することを設定する。これはまた、任意のシーケンスｘ（ｔ）∈Ｘにも当てはまる。すなわち、ユーザのどのサブセットが現れるか、およびこれらのユーザのレーティングがどのように重み付けされるかにかかわらず、リグレットは対数となり、境界が当てはまる。非常に重要なことに、これは、グループサイズにおいて指数関数的である可能性のあるグループの数に依存しない。したがって、この方法は、非常によい性能を有し、実際、ユーザの選好を満たす提案を提供するとともに、彼らの関心が何であるかをも発見する。図１に本発明の一実施形態１００を示すが、実施形態１００では、推奨エンジンが、本明細書に記載の修正多腕バンディット（ＭＭＡＢ）アルゴリズムを使用して、複数のユーザデバイスを使用する１または複数のグループに推奨を提供することができる。図１では、ユーザインタフェースデバイスＡからＤ（それぞれ１０２、１０４、１０６、および１０８）が、推奨エンジン１１０と通信することができる。４つのユーザインタフェースデバイスしか示されていないが、システム１００はより多くのユーザインタフェースデバイス（図示せず）に対応することもできる。推奨エンジン１１０は、ＭＭＡＢアルゴリズムと、初期ユーザ入力およびユーザフィードバックとを使用して、１人の個人にだけでなく個人のグループにも推奨を提供する。ユーザおよびグループに関するデータが、推奨エンジン内の別個のキャッシュ（図示せず）に、または推奨エンジンに対してリモートに記憶されてよく、したがって、エンジン１１０は、変化するグループおよび／またはモバイルグループをサポートすることができる。ユーザインタフェースデバイスＡ〜Ｄは、任意の形のユーザデバイスとすることができる。例えば、ユーザインタフェースデバイスは、スマートフォン、パーソナルディジタルアシスタント、表示デバイス、ラップトップコンピュータ、タブレットコンピュータ、コンピュータ端末、または、ユーザインタフェースを提供できるいずれか他の有線もしくはワイヤレスデバイスとすることができる。推奨アイテムデータベース１２０は、推奨アイテムのデータソースとして使用できる１または複数のデータベースを含む。例えば、グループが映画の推奨を受け取りたい場合は、アイテムデータベース１２０は、多くの映画タイトルおよび特性を少なくとも含むことになる。グループがアクティビティの推奨を受け取りたい場合は、アイテムデータベースは、多くのアクティビティアイテムを少なくとも含むことになる。グループが書籍の推奨を受け取りたい場合は、アイテムデータベースは、多くの書籍タイトルを少なくとも含むことになる。
【００４２】
一実施形態では、図１のシステム１００は、１つのグループ、またはより大きいグループのサブグループに有用である。この場合、ユーザインタフェースデバイスＡ、Ｂ、およびＣは、グループＡのユーザがアイテム（映画、アクティビティ、書籍、または他の情報もしくはディジタルコンテンツなど）の推奨を要求および受領することを可能にする、ワイヤレスデバイス（セルフォン、ラップトップ、ＰＤＡ、リモートコントロールなど）またはワイヤレスもしくは有線デバイスの任意の組合せとすることができる。ユーザインタフェースデバイスＤは、グループのユーザが推奨アイテムのリストを閲覧することまたは選択されたアイテムを表示させることを可能にする、表示デバイスとすることができる。本発明の一特徴として、エンジン１１０によって提供された推奨に対するユーザフィードバックが望ましい。したがって、ユーザインタフェースデバイスＡ〜Ｄをこの目的に使用することができる。
【００４３】
別の実施形態では、図１のシステム１００は、複数のグループまたはサブグループに対応するための基本的なアーキテクチャとして使用することができる。ユーザインタフェースデバイスＡは、グループＡの１または複数のユーザを識別するユーザ入力を受諾するリモートコントロールデバイスとすることができる。ユーザインタフェースデバイスＢは、グループＢ中の１または複数の個人によって使用できるリモートインタフェースデバイスとすることができる。ユーザインタフェースデバイスＣは、グループＡの参加者のための表示メカニズムとすることができ、ユーザインタフェースデバイスＤは、グループＢの参加者のための表示装置とすることができる。したがって、推奨エンジン１１０は、グループの構成に基づいて、アイテムデータベース１２０からのアイテムの推奨を２つの別々のグループＡとＢに提供することができる。原則的に、図１の基本的なアーキテクチャは、異なる要求ニーズを有する個人の１または複数のグループをサポートするように拡張可能である。
【００４４】
図２は、スマートＴＶ２１２に具現化された本発明の推奨システム概念を例示するシステム２００である。あるいは、推奨エンジンは、モデムまたはセットトップボックスまたはルータの一部を形成することもできる。図２では、スマートＴＶの実装が示されている。ここでは、推奨エンジン２１０を有するスマートＴＶ２１２が、リンク２０９を介してコンテンツプロバイダに接続されるのが示されている。通信接続２０９は、有線接続とワイヤレス接続のいずれかとすることができる。コンテンツプロバイダは、映画、ビデオ、音楽、製品、サービス、アクティビティなどのアイテムのデータベースを推奨エンジンに提供し、それにより、ＭＭＡＢアルゴリズムに基づいてアイテムが個人のグループに推奨されることが可能である。推奨アイテムデータベースは、コンテンツプロバイダから直接に提供されてもよく、または別個にアクセスされてもよい。図２では、ユーザ、またはユーザのグループが、リンク２０５を介してスマートＴＶ２１２に接続されたリモートコントロールなどの第１の制御デバイス２０２を使用して、グループをユニットとしてまたはその個人を介して識別することができる。第２の制御デバイス２０３は、例えば、リンク２０７を介してスマートＴＶ２１２に接続されたタブレットＰＣ、ラップトップコンピュータ、またはＰＤＡとすることができる。リンク２０５および２０７は、有線通信接続とワイヤレス通信接続のいずれかとすることができる。第２の制御デバイス２０３を第１の制御デバイス２０２と共に使用して、グループをスマートＴＶとインタフェースするのを補助することができる。例えば、グループがスマートＴＶ２１２を見て推奨を受け取っている間、第２の制御デバイス２０３は、予告編、記述、パラメータ選択肢などの提案されるコンテンツをスマートＴＶ２１２上で視聴するオプションを提供して、推奨に関するグループ入力を可能にすることができる。ユーザは、選択された推奨を視聴した後、第１の制御デバイス２０２と第２の制御デバイス２０３のいずれかを使用して、スマートＴＶ２１２上で視聴した選択した推奨に関するフィードバックを提供することができ、それにより、ＭＭＡＢアルゴリズムは、グループに対する将来の推奨を改善するために更新されることが可能である。
【００４５】
図３に、クラウドリソースを利用して図１および２の推奨エンジンの等価物を実装する、本発明の一実施形態を示す。図３のシステム３００では、リモートコントロール、セルフォン、ＰＤＡ、ラップトップコンピュータ、タブレットコンピュータなどのユーザデバイス３０２または３０３を使用して、ネットワークインタフェースデバイス３０６を介してネットワーク３０８にアクセスすることができる。図２の様々な機能要素を接続する通信リンク３０４、３０５、３１２、および３１４は、有線接続とワイヤレス接続のいずれかとすることができる。ネットワークインタフェースデバイス３０６は、ユーザデバイス３０２および３０３がネットワーク３０８にアクセスするのを可能にする、ワイヤレスルータ、モデム、ネットワークインタフェースアダプタ、または他のインタフェースとすることができる。ネットワーク３０８は、任意の私設または公衆ネットワークとすることができる。ネットワーク３０８の例は、ネットワークインタフェースデバイス３０６およびクラウドリソース３１０との通信のための適切なインタフェースを備えた、セルラーネットワーク、イントラネット、インターネット、ＷｉＦｉネットワーク、コンテンツプロバイダのケーブルネットワーク、またはいずれか他の有線もしくはワイヤレスネットワークとすることができる。クラウドリソース３１０は、ユーザデバイス３０２、３０５が、推奨エンジンに求められる機能をクラウドコンピューティングの概念を介して提供できるサーバーなどのリソースに、ネットワーク３０８を介してアクセスするのを可能にする。クラウドリソース３１０はまた、推奨アイテムデータベース（図示せず）を提供することができ、推奨アイテムデータベースは、クラウドリソースに含まれる推奨エンジンが動作のために必要とすることになる推奨をサポートするために、コンテンツプロバイダが供給するものである。別の変形では、推奨アイテムデータベースはネットワーク３０８の一部であってもよく、ネットワーク３０８は、コンテンツプロバイダがサポートするネットワークとすることができる。
【００４６】
クラウドコンピューティングは、コンピューティングを製品としてではなくサービスとして送達するものであり、それにより、共有リソース、ソフトウェア、および情報が、ネットワーク（通常はインターネットだがこれに制限されない）を介してユーティリティとしてコンピュータおよび他のデバイスに提供される。クラウドコンピューティングは、クラウドユーザがコンピューティングインフラストラクチャの位置および他の詳細を知っていることを必要とすることなく、計算、ソフトウェアアプリケーション、データアクセス、データ管理、および記憶リソースを提供する。エンドユーザは、自分のユーザデバイス上のウェブブラウザまたは軽量デスクトップもしくはモバイルアプリケーションを介して、クラウドベースのアプリケーションにアクセスすることができ、ビジネスソフトウェアおよびデータは、クラウドのリソースを介して利用可能なリモート位置にあるサーバー上に記憶される。クラウドアプリケーションプロバイダは、ソフトウェアプログラムがエンドユーザのコンピュータ上にローカルにインストールされているかのように、同じかまたはよりよいサービスおよび性能を提供して実行しようと努める。
【００４７】
図３の別の変形では、ネットワーク３０８とクラウドリソースとを併合することができ、したがって、結合されたネットワーク３０８とクラウドリソース３１０は本質的に、推奨エンジン機能と推奨アイテムデータベース記憶およびアクセスとを提供するサーバーを含めた、全てのリソースを提供する。
【００４８】
図４に、本発明の一特徴によるイベントフローの基本的なブロック図を示す。プロセスは、図１、２、または３のいずれかによるシステムについて、ステップ４０１で開始する。ステップ４０５で、個人が、推奨サービスの使用に登録する。これは、個人識別情報をユーザインタフェースデバイスまたはサーバー装置に入力することを伴う場合がある。ステップ４１０で、ユーザのうちの１または複数は、識別されたグループ中のユーザの全セットに基づいてアイテム推奨を受け取ることになるグループのメンバを識別する。したがって、ステップ４０５では個人が識別され、ステップ４１０では、識別された個人を含むグループが識別される。このとき、グループ内の各個人に重みを適用して、時間ｔで存在するグループまたはサブグループについての重みベクトルを設定することができる。この重み付けは、グループ中のメンバのグループ全体のサブグループを構成する存在するメンバの特性を定義する助けとなる。別々のステップ４０５と４１０の代替として、個人は単純に、自分をユーザグループのメンバとして識別することによって推奨サービスに登録することもできる。ユーザに対する重みは、推奨エンジンによって、または、個々のメンバに重みを割り当てる仕事を課された特定のメンバによって、割り当てることができる。
【００４９】
ステップ４１２で、グループ推奨時間ｔで考慮されるべきグループのメンバが識別される。本発明の一特徴では、推奨エンジンは、グループ全体に対してだけでなく、グループのサブセットに対しても推奨アイテムを生成することができる。例えば、時間ｔでグループの全てのメンバが存在しない場合は、グループ全体のサブセット（サブグループ）のメンバシップのみが推奨実施時に考慮される。このようにすると、グループのサブセット（例えば、推奨の時点で存在するグループメンバのみ）が、彼らに合わせてカスタマイズされたサブセットグループ推奨を受け取ることができる。このようにすると、グループ推奨の時点で考慮されないことになるグループメンバは、推奨決定から除外される。このように修正多腕バンディットアルゴリズムがグループ全体のサブセットに基づいて推奨をカスタマイズできることにより、グループ推奨をグループのうちの出席メンバのみに対してカスタマイズすることができる。ステップ４１２で、識別されたサブグループは、１または複数の推奨アイテムを推奨エンジンに要求する。
【００５０】
ステップ４１５で、推奨エンジンは、これらの個別メンバを含む識別されたグループのメンバの具体的な出席に従って、アイテム推奨を提供する。最初、推奨エンジンは、グループに対する推奨アイテムに関係する可能なカテゴリのセットから、カテゴリを選択する。例えば、推奨システムが映画タイトルを推奨するものである場合、推奨エンジンによって選択されるカテゴリは映画ジャンルである。推奨システムがレストランを推奨するものである場合、選択されるカテゴリは食事料理である。カテゴリ（例えば、映画ジャンル、または食事料理、または音楽ジャンルなど）の選択後、次いで１または複数の特定の推奨アイテムがカテゴリから選択される。次いで、１または複数の推奨アイテムは、選択されたカテゴリに対応するグループ消費に向けて提案される。グループ推奨アイテムとして提供される推奨アイテムの数は、０からｎまで変動する場合がある。推奨アイテムは、推奨エンジンの出力である。推奨エンジンによって使用される推奨アルゴリズムは、修正多腕バンディット（ＭＭＡＢ）アルゴリズムである。
【００５１】
ステップ４２０で、グループまたはサブグループが、どの推奨アイテムを選択するか決定して推奨を受諾したと仮定する。または、新しい推奨セットが要求される場合もある。ステップ４２５で、グループまたはサブグループは、選択された推奨アイテムを評価する。これは、グループまたはサブグループのアクティビティに携わって、選択された推奨アイテムを査定することを伴ってもよい。例えば、推奨アイテムが映画タイトルである場合、サブグループは、映画タイトルを視聴する。推奨アイテムが食事料理カテゴリからのレストランである場合は、サブグループは、提案されたレストランで食事することになる。ステップ４３０で、サブグループの個人は、選択した推奨アイテムをレーティングする。このステップは、推奨エンジンへのフィードバックを提供し、それにより、ＭＭＡＢアルゴリズムは、メンバのグループまたはサブグループに対する将来の推奨を改善することができる。グループは２人以上の個人を含むと仮定する。この時点で、グループに対して別の推奨を行うことができる。次のグループ推奨は、ステップ４１２に入ることによって、同じサブグループまたは異なるサブグループに対して行うことができる。
【００５２】
図５に、図１のユーザインタフェースデバイスＡ１０２など、あるタイプのユーザインタフェースデバイス５００を示す。このタイプのユーザインタフェースデバイスは、リモートコントロール、ラップトップもしくはテーブルＰＣ、ＰＤＡ、セルフォン、または標準的なパーソナルコンピュータなどとすることができる。このデバイスは通常、個別およびグループユーザデータを入力するステップ、ならびにユーザによって識別されたグループに対する推奨を受諾するステップをユーザが行うための、表示装置、タッチパッド、タッチスクリーン、メニューボタンなどのユーザインタフェース部分５１０を備えてよい。デバイス５００は、当技術分野で知られるように、ユーザインタフェース５１０を、内部バス５１５などのデバイスの内部回路と結合するためのインタフェース回路５２０を備えてよい。プロセッサ５２５は、デバイス５００のための様々なインタフェースおよびリソースを制御するのを補佐する。これらのリソースは、プログラムおよび／またはデータ記憶に使用されるローカルメモリ５３５、ならびにネットワークインタフェース５３０を含む。ネットワークインタフェース５３０は、デバイス５００が当該ネットワークと通信できるようにするのに使用される。例えば、ネットワークインタフェース５３０は、図１のユーザインタフェースデバイスＡ１０２について述べた機能が推奨エンジン１１０と通信するための、有線またはワイヤレスインタフェースとすることができる。あるいは、ネットワークインタフェース５３０は、図２に示したようなインタフェースとすることもでき、スマートＴＶと通信するように第１または第２の制御デバイス２０２または２０３を接続する。このようなインタフェースは、音響、ＲＦ、赤外線、または有線とすることができる。あるいは、ネットワークインタフェース５３０は、図３のユーザデバイス３０２または３０３について述べたようなルータまたはモデムなど、外部ネットワークインタフェースデバイスとすることもできる。
【００５３】
他の代替ユーザデバイスタイプまたは構成もまた、当業者ならよく理解することができる。例えば、図１のユーザデバイスがディジタルテレビジョンである場合は、ユーザデバイスのアーキテクチャは、推奨リストを表示できるかまたは推奨アイテム自体をユーザに対してレンダリングもしくは表示できるディジタルテレビジョンまたはモニタのアーキテクチャとなる。
【００５４】
図６は、図１および２に示したものなどの推奨エンジンの基礎を形成できる、サーバーまたは他の電子デバイスなどの装置６００の描写である。上に表現したように、推奨エンジンは通常、スマートＴＶ、モデム、ルータ、またはセットトップボックスなどのデバイス中に位置してもよい。推奨エンジンを備える装置の形にかかわらず、推奨エンジン機能は、ローカルユーザまたは管理者インタフェース６１０を有してよく、インタフェース６１０は、オプションのバス６１５への相互接続を提供できるインタフェース回路６２０に結合される。このような相互接続はいずれも、プロセッサ６２５、ローカルメモリ６３５、ネットワークインタフェース６３０、およびオプションのローカルまたはリモートリソース相互接続インタフェース６４０を含んでよい。
【００５５】
プロセッサ６２５は、推奨エンジンまたはサーバー装置のための制御機能を実施し、ならびに推奨エンジンのユーザに提供される推奨リストの決定のための計算リソースを提供する。プロセッサ６２５は、ＭＭＡＢを使用してソフトウェア、ファームウェア、またはハードウェア中でプログラムを実行して、ユーザのグループまたはサブグループに対する１または複数の推奨アイテムを決定する役割を果たす。例えば、ＭＭＡＢアルゴリズムを、ローカルプログラムおよびデータリソースメモリ６３５を使用してプロセッサ６２５によって処理することができる。プロセッサ６２５は、サーバー６００に対してローカルであるかまたはインタフェース６３０および／もしくは６４０を介して分散された、単一プロセッサまたは複数プロセッサであってよいことに留意されたい。ＭＭＡＢアルゴリズムの処理、および図４のような流れ図は、図５中のものなどのユーザインタフェースデバイスを介して取得されるユーザデータ入力へのアクセスと、図１に示したものまたは図２および３を記述するテキスト中で述べたものなどの推奨アイテムデータベースの使用とを必要とする。ネットワークまたはユーザデバイスインタフェース６３０を、インターネット、セルフォン、または他の私設もしくは公衆外部ネットワークへの接続など、ネットワーク中での主要な通信に使用して、サポートする外部ネットワークによって装置６００へのアクセスを可能にすることができる。例えば、ネットワークインタフェース６３０を、図５に示したようなユーザデバイスと推奨エンジンとの間の主要な通信に使用して、ユーザから要求およびフィードバックを受け取り、ユーザのグループに推奨を提供することができる。ネットワークまたはユーザデバイスインタフェース６３０を使用してまた、推奨のための潜在的アイテムに関する情報が記憶されたデータベースが接続６５０におけるサポートする外部ネットワーク上に位置する場合に、データベースに記憶された潜在的アイテムに関する情報を収集することもできる。一実施形態では、接続６５０は、図３のネットワーク３０８と３０９のいずれかとすることができる。あるいは、接続６５０は、図１の構成におけるようなユーザデバイスへの多くの直接接続のうちの１つとすることもできる。別の構成では、並列コンピューティングエンジン、メモリ、または推奨アイテムのデータベースなどのリソースが、インタフェース接続６３０のネットワークとは異なるネットワーク上またはローカルネットワーク上に位置する場合は、インタフェース６４０を使用してそのローカルまたはリモートネットワークと通信することができる。一実施形態では、インタフェース６４０は、インタフェース接続６３０に対する代替または補足を提供する。一例では、インタフェース６４０は、インタフェース６３０を介した接続６５０を通してアクセス可能な任意のデータベースアクセスを補足するローカルデータベースアクセスを有することができる。装置６００は、識別可能なネットワーク上に明確なエンティティとして位置してもよく、または、図２および３について述べたようなクラウドコンピューティングに対応するように分散されてもよいことに留意されたい。
【００５６】
図５中のユーザデバイスおよび図６中のサーバータイプ装置の実装について具体的なアーキテクチャを示しているが、構成要素の機能の分散、構成要素の統合、および内部バスの使用または不使用など、実装オプションが存在することは、当業者なら認識するであろう。このようなオプションも、図示および記述した構成の機能および構造と等価である。
【図１】
2015513154.tif 000012
【図２】
2015513154.tif 000013
【図３】
2015513154.tif 000014
【図４】
2015513154.tif 000015
【図５】
2015513154.tif 000016
【図６】
2015513154.tif 000017
【国際調査報告】
2015513154.tif 000018
2015513154.tif 000019
2015513154.tif 000020