JP2023514653A - ユーザー供給の基準に基づいて推奨を提供する方法およびシステム - Google Patents

Abstract

本明細書では、利用可能な推奨スキームの非効率性に対処する方法およびシステムが提案される。より具体的には、本明細書で開示される実施形態は、新しい推奨スキームを提供し、これにより、ユーザーは何を推薦されたいかについてさまざまな基準を入力することができる。例えば、システムは、ユーザーからコンテンツ推奨のためのユーザープロファイルを受信することができる。システムは、ユーザーのユーザープロファイルを取得することができる。システムは、ユーザーの好みをユーザープロファイルと比較して、ユーザーのためのコンテンツ推奨の基準を決定することができる。システムは、コンテンツプロバイダーによって提供されるコンテンツのコンテンツ属性を受信することができる。システムは、条件をコンテンツ属性に一致させることができる。システムは、基準をコンテンツ属性に一致させることに応答して、コンテンツに対するユーザーへの表示のための推奨を生成することができる。

Description

本出願は、2020年2月10日に出願された米国仮特許出願第62/972,430号に対する優先権を主張する。前述の出願の内容は、参照によりその全体が本明細書に組み込まれる。

本発明は、ユーザー供給の基準に基づいて改善された推奨を提供することに関する。

コンテンツ制作において、従来の大規模なメディアプロバイダー（例：放送スタジオ、テレビネットワーク、およびその他の信頼できる関係者）から独立したコンテンツ制作者とコンテンツ消費者が直接対話できる新しいものへと制作を分散化する動きがある。現在、信頼できる関係者が、エクスペリエンス、データ（視聴者の好み、属性、欲求、価格設定、過去の行動を含むがこれらに限定されない）、提供物、潜在的な推奨を管理している。これらの入力の一部の制御を信頼できる関係者からユーザーに移すことができる革新的なシステムは、コンテンツの配信と消費を分散化の波の方向に動かし、全体的な視聴体験を向上させる可能性がある。

現在、ユーザーが表示できるコンテンツは数多くある。したがって、ユーザーがこのコンテンツをナビゲートして、必要なコンテンツを見つける方法が必要になる。コンテンツのソースの１つは、大企業、ストリーミングメディアプロバイダー、放送スタジオ、テレビネットワークなどの信頼できる関係者である（例:Amazon（登録商標）、Netflix（登録商標）、ABC（登録商標）、Disney（登録商標）)。もう１つのソースは、ユーザーが作成したコンテンツを仲介者（YouTube（登録商標）など）に公開する独立したプロバイダーである。
どちらのシステムもユーザーに推奨を提供するが、どちらのシステムにも欠陥がある。信頼できる関係者は、独自のデータにタグを付け、何を推奨するかを決定する。したがって、信頼できる関係者は、必ずしもユーザーが最も見たいとは限らないが、信頼できる関係者がユーザーに見てもらいたいコンテンツ、および／またはユーザーがアクセスできるコンテンツをユーザーにプッシュする場合がある。例えば、信頼できる当事者は、別のエンティティのプログラミングではなく、その信頼できる当事者のオリジナルのプログラミングに向けてユーザーをプッシュする場合がある。

独立したプロバイダーには別の問題がある。独立したプロバイダーは、標準化された方法でコンテンツにタグを付けることができなかったり、より多くのビューを獲得したり、より頻繁に推奨されるようにコンテンツに不正なタグを付けたりする可能性がある。さらに、独立したプロバイダーがより多くのビューを獲得する方法でコンテンツにタグを付けない場合、彼らはコンテンツに不正にタグを付ける独立したプロバイダーや、自社のコンテンツを優先する信頼できる団体に負けることになる。したがって、独立したプロバイダーには、信頼できる関係者がコンテンツの優先順位を下げることを回避する技術的手段と、コンテンツを正確に表す標準化された方法でコンテンツにタグを付けるメカニズムの両方が欠けている。同様に、ユーザーには、独立したプロバイダーからのコンテンツにアクセスしたり、推奨するコンテンツ、推奨する基準、および／またはその基準をどのように解釈するかを決定したりするメカニズムがない。

本明細書では、利用可能な推奨スキームの非効率性に対処する方法およびシステムが提案される。より具体的には、本明細書で開示される実施形態は、ユーザーが何を推薦されたいかについての様々な基準を入力することによって、新しい推薦システムを提供する。（例：逆推奨システム）。次に、システムはユーザーのプロファイルに基づいてその基準を解釈する。つまり、ユーザーの好みやプロファイル情報を解釈する独自の推奨アルゴリズムに基づいて推奨を提供する従来のシステムとは対照的に、逆の推奨により、ユーザーは基準を入力できる。さらに、ユーザーがデータをフィルタリングできる従来のフィルタリングメカニズムとは対照的に、逆推奨システムは、ユーザーの好みやプロファイル情報に基づいて、ユーザーが入力した基準を解釈する。この逆推奨システムは、以下で説明するように、コンテンツベース、協調、および／またはハイブリッドフィルタリングを利用し、一部の実施形態では、特定の人工知能および機械学習(まとめて機械学習と呼ぶ)モデル、アーキテクチャ、およびデータ準備ステップを利用して、逆推奨システムを強化することができる。最後に、プロバイダーとユーザーの両方が利用可能なコンテンツとそのコンテンツの推奨の両方の基準を入力できる（そしてそれらの基準を独立して解釈させる）ため、システムは推奨を分散した方法で提供できるようにする。

例えば、ユーザーが「面白い」「長すぎない」ものをリクエストした場合、システムはまずユーザーが面白いと感じたコンテンツを判断する。これには、例えば、ユーザーが最後まで視聴したコメディータグ付きの番組が含まれる場合がある。システムは、同様のタイプのコメディーを見つけることができる。次に、システムは、ユーザーの通常の視聴期間よりも短い（つまり、「長すぎない」）コンテンツを判断することができる。最初に、システムは、ユーザーの典型的な視聴セッションの時間の長さを取得し、次に、システムは、取得した時間の長さよりも短いものについて、類似したタイプのコメディーをフィルター処理する。例えば、システムは「コンテンツベースのフィルタリング」コンポーネントを採用している（例：アイテム機能を使用して、ユーザーの以前のアクションまたは明示的なフィードバックに基づいて、ユーザーが好むものに類似した他のアイテムを推奨する）。追加または代替として、システムは、コンテンツの特性を識別するために、ビデオおよび／または他のコンテンツに埋め込まれたメタデータ、および他のサードパーティが生成したコメント（例：ユーザーのコメント、レビューなど）を使用することができる。

同様に、独立したコンテンツプロバイダーの場合、システムは、番組のコンテンツおよび／またはコンテンツを説明するために使用する基準を解釈し、番組および／またはプロバイダーのプロファイルを作成する。例えば、プロバイダーがコンテンツに「非常に」面白いタグを付けている場合でも、サードパーティのコンテンツ（例：評価、ユーザーのコメントなど）に基づいて作成されたコンテンツのプロファイルは、コンテンツが「少し」面白いだけであることを示している場合がある。次に、システムは、「協調フィルタリング」方式で、このプロファイルをユーザーが提供した基準のプロファイルに一致させることができる（例：多くのユーザーから好みや嗜好情報を収集（共同）することで、ユーザーの興味関心を自動予測（フィルタリング）できる）。コンテンツベースのフィルタリングと協調フィルタリングの両方を組み込んだ複合アプローチは、「ハイブリッドフィルタリング」と呼ばれる。例えば、これらのアプローチは、従来の推奨システムよりも優れているものであり、それは、従来の推奨システムは、すでに人気があり、視聴されおよび／または共有されているコンテンツを推奨することを目的としているためである。これは、すでに人気のある信頼できる関係者のコンテンツに特に当てはまる。対照的に、このシステムは、ユーザーが推奨したいものに対して入力するさまざまな基準に合わせた、コンテンツベース、協調、および／またはハイブリッドのアプローチを使用して多様性を促進する。この推奨の多様性により、信頼できる関係者によって生成されたコンテンツに対する固有のバイアスが軽減されるため、推奨が独立したプロバイダーによって生成されたコンテンツを返す能力が向上する。

いくつかの実施形態では、逆推奨システムは、機械学習モデル、アーキテクチャ、および逆推奨システムを強化するためのデータ準備ステップを含み、従来のシステムに固有の技術的問題を軽減するための技術的特徴を含む。例えば、逆推奨システムが直面する最初の技術的問題は、データのまばらさである。機械学習を活用する従来の推奨システムは、ユーザーに合わせて調整された大規模なデータセットを利用したり、ユーザーの好みやアイテム間の関係を判断するのに十分なデータを含んだりする場合がある。このようなデータセットは、逆推奨システムでは（少なくとも最初は）利用できない可能性があるため、システムは、システムのさまざまなコンポーネントおよび／または段階で既存のデータを活用する場合がある。システムは、本明細書で説明する新規のアーキテクチャを使用して、これらの異なるコンポーネントを編成およびトレーニングすることができる。

例えば、コンテンツに関する情報、ユーザーに関する情報、ユーザーが選択した基準を解釈するために使用される情報、プロバイダーに関する情報、および／またはコンテンツに関してプロバイダーが選択した基準を解釈するために使用される情報がまばらである場合、システムは、データがまばらな環境でより正確な機械学習モデルを使用することを選択する場合がある。対照的に、データがまばらでない場合、システムは、データのまばらさに関係なく最も正確な結果を提供する機械学習モデルの使用を選択する場合がある。例えば、コンテンツベースのフィルタリングアルゴリズム（または、コンテンツベースのフィルタリングアルゴリズムの影響を強く受けているモデル）は、データがまばらな環境（またはトレーニング情報が利用できない）ではより正確な推奨を提供するが、コンテンツベースのフィルタリングアルゴリズムは、データがまばらでない環境（またはトレーニング情報が利用可能なもの）では協調フィルタリングアルゴリズム（または協調フィルタリングアルゴリズムの影響を強く受けたモデル）ほど正確ではない。したがって、最も正確な結果を提供するのに最適な各決定（例えば、コンテンツにタグを付ける方法、ユーザーにタグを付ける方法、ユーザーが選択した基準を解釈する方法、プロバイダーにタグを付ける方法、および／またはプロバイダーが選択した基準を解釈する方法）について、逆推奨システムは、（例えば、複数の機械学習モデルから）機械学習モデルを選択することができる。特に、システムは、ハイブリッドスキーム（例えば、コンテンツベースおよび／または協調フィルタリングアルゴリズムに基づくフィルタリングアルゴリズム（または、コンテンツベースおよび／または協調フィルタリングアルゴリズムの影響を強く受けるモデル）を選択することもできる。システムは、最も正確な結果を提供するのに最適なさまざまなアンサンブルアーキテクチャを選択することもできる。

システムが直面する別の技術的問題は、ユーザーの数および／または推奨のリクエストに対応するのに必要なサイズ、推奨のベースとなるアイテムの数、興味の多様性、使用中のリクエストにスケーリングし、アイテムなどの動的な変化を補正する能力である。従来のシステムは、単一ドメイン専用のシステムであっても、このような問題を抱えている。システムは、ユーザー、アイテム、および処理制限の特定の特性に基づいて、ネットワークとドメインをクラスタ化することにより、この問題を克服することができる。追加および／または代替として、システムは、１以上の決定のためにトレーニングデータの潜在表現を生成することができる。これらの潜在表現を使用して、処理負荷を減らし、スケーラビリティを向上させることができる。

いくつかの態様では、機械学習モデルを使用して、ユーザー供給の基準に基づいて推奨を提供するための方法およびシステムが説明されている。例えば、システムは、ユーザーからのコンテンツ推奨に対するユーザーの好みを受信することができる。システムは、ユーザーのユーザープロファイルを取得できる。システムは、ユーザーの好みをユーザープロファイルと比較して、ユーザーに対するコンテンツ推奨の基準を決定することができる。システムは、コンテンツプロバイダーによって提供されるコンテンツのコンテンツ属性を受信することができる。システムは、条件をコンテンツ属性に一致させる場合がある。システムは、基準をコンテンツ属性に一致させることに応答して、コンテンツに対するユーザーへの表示用の推奨を生成することができる。

本発明の他の様々な態様、特徴、および利点は、本発明の詳細な説明および添付の図面から明らかになるであろう。また、前述の一般的な説明と以下の詳細な説明の両方が例であり、本発明の範囲を限定するものではないことも理解されたい。本明細書および特許請求の範囲で使用されるように、「a」、「an」、および「the」の単数形は、文脈が明確に指示しない限り、複数の指示対象を含む。さらに、本明細書および特許請求の範囲で使用される用語「または」は、文脈上明らかに別段の指示がない限り、「および／または」を意味する。

図１は、１以上の実施形態による、複数の推奨を生成するためのユーザーインターフェースの例示的な例を示している。

図２は、１以上の実施形態による、複数の推奨を生成するためのユーザーインターフェースの別の例示的な例を示す。

図３は、１以上の実施形態による、ユーザー供給の基準をコンテンツに一致させるための機械学習モデルアーキテクチャを示している。

図４は、１以上の実施形態による、ユーザー供給の基準をコンテンツに一致させるためのシステムを示す。

図５は、１以上の実施形態による、ユーザー供給の基準を一致させるためのフローチャートを示す。

図６は、１以上の実施形態による、ユーザー供給の基準に一致させるための機械学習モデルを選択するためのフローチャートを示す。

以下の説明では、説明の目的で、本発明の実施形態の完全な理解を提供するために、多くの特定の詳細が示される。しかし、当業者であれば、本発明の実施形態は、これらの特定の詳細なしに、または同等の構成で実施できることを理解するであろう。他の場合には、本発明の実施形態を不必要に不明瞭にすることを避けるために、周知の構造およびデバイスがブロック図形式で示されている。

本発明は、最も実用的で好ましい実施形態であると現在考えられているものに基づいて説明する目的で詳細に説明されてきたが、そのような詳細は単にその目的のためであり、本発明は開示された実施形態に限定されず、反対に、添付の特許請求の範囲内にある変更および同等の構成をカバーすることを意図していることを理解されたい。例えば、本発明は、可能な限り、任意の実施形態の１以上の特徴を他の任意の実施形態の１以上の特徴と組み合わせることができることを意図していることを理解されたい。

本明細書で言及される場合、「ユーザーインターフェース」は、デバイスにおける人間とコンピューターの対話および通信を含み得、ディスプレイスクリーン、キーボード、マウス、およびデスクトップの外観を含み得る。例えば、ユーザーインターフェースは、ユーザーがアプリケーションまたはウェブサイトと対話する方法を含むことができる。本明細書で言及される「コンテンツ」は、テレビ番組、ペイパービュープログラム、オンデマンドプログラム（ビデオオンデマンド（ＶＯＤ）システムのように）、インターネットコンテンツ（例：ストリーミングコンテンツ、ダウンロード可能なコンテンツ、Ｗｅｂキャストなど）、ビデオクリップ、音声、コンテンツ情報、写真、回転画像、ドキュメント、プレイリスト、ウェブサイト、記事、書籍、電子書籍、ブログなど、広告、チャットセッション、ソーシャルメディア、アプリケーション、ゲーム、および／またはその他のメディアまたはマルチメディア、および／またはそれらの組み合わせ等の電子的に消費可能なユーザー資産を意味すると理解されるべきである。本明細書で言及する「マルチメディア」という用語は、上記の少なくとも２つの異なるコンテンツ形式、例えば、テキスト、オーディオ、画像、ビデオ、または対話型コンテンツ形式を利用するコンテンツを意味すると理解されるべきである。コンテンツは、ユーザー機器デバイスによって記録、再生、表示、またはアクセスされる場合があるが、ライブパフォーマンスの一部である場合もある。コンテンツには、製品、サービス、価値、および／またはその他の情報も含まれる場合がある。例えば、コンテンツは、そのアイテムが製品、サービス、および／または組み合わせであるかどうかにかかわらず、コンテンツプロバイダーから入手可能なアイテムを指す場合がある。

図１は、１以上の実施形態による、複数の推奨を生成するアプリケーション（例えば、ウェブブラウザ）の例示的な例を示す。例えば、ユーザーインターフェース１００は、推奨１０２および推奨１０４、ならびに推奨１０２および推奨１０４のコンテンツに対する基準を入力するためにユーザーによって使用され得るフィールド１０６を含む。いくつかの実施形態では、アプリケーションは、別のアプリケーションの一部として提供されてもよく、および／またはプラグイン、アプレット、ブラウザ拡張、および／または他のソフトウェアコンポーネントとして提供されてもよい。一部の実施形態では、ユーザーインターフェース（および／またはそのコンポーネント）は、ＡＰＩ層（例えば、ＡＰＩ層４５０（図４））を介して実装され得る。例えば、アプリケーションは、アプリケーション（例えば、ウェブブラウザ）および／またはオンまたはオフに切り替えることができる他のプログラムの一部であってもよい。別の例では、アプリケーションは、別のアプリケーションに追加および／または削除できるソフトウェアコンポーネントである場合がある。

いくつかの実施形態では、アプリケーションは、アプリケーションの概念データモデルおよび／またはアプリケーションの１以上のフィールド（例えば、アプリケーションによって現在表示されているフィールド）を含むことができる。例えば、概念データモデルは、データオブジェクト、異なるデータオブジェクト間の関連付け、および／またはアプリケーションのルールの表現である場合がある。一部の実施形態では、システムは、データの視覚的表現を決定し、一貫した命名規則、デフォルト値、およびセマンティクスをモデル内の１以上のフィールドに適用することができる。これらの命名規則、デフォルト値、およびモデル内の１以上のフィールドのセマンティクスは、アプリケーションの推奨を生成するためにシステムによって使用される。例えば、各フィールドは、基準、特性、および／またはオプションのカテゴリに対応する場合がある。システムは、フィールド識別子を使用して、入力されている基準のタイプを識別できる。例えば、システムは、フィールド識別子をフィールドデータベース（例えば、フィールドに対応するコンテンツおよび／またはコンテンツの特性をリストするルックアップテーブルデータベース）と比較して、推奨のためのコンテンツを識別し得る。

各フィールドは、特定の情報および／またはコンテンツの特定の特徴の情報についての基準に対応することができる。代替的または追加的に、各フィールドは所与の機能を提供することができる。この機能は、ローカルで実行される機能（例えば、ローカルデバイスで実行される機能）の場合もあれば、リモートで実行される機能の場合もある。いくつかの実施形態では、機能は、ローカルまたはリモートでアクセスおよび／または利用できる追加情報および／または他のアプリケーションへのリンクを含むことができる。いくつかの実施形態では、フィールドは、テキストおよび／またはグラフィック情報によって表すことができる。例えば、フィールドは、送信されると購入を生じさせ得る情報（例えば、ユーザー資格証明および／または支払いアカウント情報）をユーザーが入力することができる購入機能を含み得る。システムは、概念データモデルの生成に使用するこれらの特性とアプリケーション機能を識別できる。

いくつかの実施形態では、システムは、アプリケーションのフィールドに関する情報（例えば、フィールドを説明するメタデータまたは他の情報）を検出することができる。例えば、情報は、目的、機能、起源、作成者、開発者、システム要件（必要な形式および／または機能を含む）、作成者、推奨される使用、および／または承認されたユーザーを説明する場合がある。情報は、人間が可読な言語および／またはコンピューター可読な言語で表現されてもよく、またはユーザーインターフェース１００を閲覧しているユーザーに認識されなくてもよい。これらのフィールドは、ユーザーおよび／またはコンテンツプロバイダーによって送信された基準および／またはその他の情報を一致させるために、システムによって使用される場合がある。例えば、いくつかの実施形態では、システムは、複数のユーザーおよび／またはプロバイダーからコンテンツおよび／または基準を受信することができる。いくつかの実施形態では、この基準は、コンテンツを記述し、および／または所与のコンテンツに関連する製品またはサービスを記述し得る。例えば、第１のプロバイダーは、コンテンツの価格に関する基準を入力することができる。第２のプロバイダーは、コンテンツの配達条件の第１のセットに関する基準を入力することができる。第２のプロバイダーは、コンテンツの第２の配達条件に関する基準を入力することができる。次に、ユーザーは、コンテンツの受諾可能な配達条件に関する基準を入力することができる。システムは、コンテンツのフィールド識別子（例えば、コンテンツおよび／またはコンテンツに関する特性を一意に識別する値）によって、受信した基準のそれぞれと一致させることができる。次いで、システムは、コンテンツに関連する推奨を行うことができる。例えば、システムは、配達条件の第１のセットを使用してコンテンツをユーザーに推奨する場合がある（これらは配達条件の第２のセットよりも優れているため）。

例えば、システムは複数当事者のトランザクション（transaction）を含む場合があり、それにより、何らかの理由で、トランザクションを履行するのに多くの関係のない当事者が必要になる。例としては、ユーザー、複数のプロバイダー、１以上の貸し手、１以上の荷送人、チェーンの上流にあるサプライヤーなどがあるが、これらに限定されない。入札のフィールドには、必要に応じてこれらすべての要件が含まれ、システムを拡張してより現実的なシナリオを満たすことができる。これにより、そのようなトランザクションを完了するには複数の当事者が必要になる場合があり、多くの場合実際に行われ、特定の従順（amenable）なアイテム（カスタムまたは手作りなど）の生産をその場で計画できるため、リスクとオーバーヘッドが削減される。代替的または追加的に、システムは、特定の用語、特性、および／または特性の値を必要とする場合がある。例えば、指定されたプロバイダー、条件、および／または指定されたユーザーの範囲は、システムの管理下にある場合がある。したがって、誰がどの条件の下で参加を許可されるかという点で、管理は非常に管理されたものから実質的に分散化されたものまでさまざまである。

フィールドは、フィールド識別子および／または特定のタイプのデータに関連付けられたフィールド特性を含むことができる。例えば、フィールド特性は、情報（例：順序、見出し情報、タイトル、説明、評価情報（例：保護者による制限の評価、評論家の評価など）、ソースコードデータ（例：ＨＴＭＬ、ソースコードヘッダーなど）、ジャンルまたはカテゴリ情報、主題事項情報、著者／俳優情報、ロゴデータ、またはコンテンツプロバイダーのその他の識別子）、メディア形式、ファイルタイプ、オブジェクトタイプ、コンテンツに表示されるオブジェクト(例えば、製品の配置、広告、キーワード、コンテキスト)、またはあるセクションを別のセクションと区別するために使用されるその他の適切な情報である可能性がある。一部の実施形態では、フィールド特性は、人間が可読なテキストであってもよい。フィールド特性は、フィールド特性とユーザーのユーザープロファイルデータとの比較に基づいて、ユーザーが関心を持っているフィールド（またはフィールドに入力された値に関連するコンテンツ）を示すと決定され得る。

この情報はまた、フィールドの選択および／または使用に関連し得るユーザープロファイル情報への参照またはポインタを含み得る。システムは、情報を検証、選択、および／または使用するために、この情報を取得し、および／または別のフィールド（例えば、許容されるフィールド値の説明）と比較することができる。例えば、説明は、フィールド値が特定のフォーマットを使用すること、特定の範囲内に収まること、特定のユーザー、コンテンツ、ユーザーデバイス、および／またはユーザーアカウントに関連することを示すことができる。

システムは、ユーザープロファイルにアクセスする場合がある。ユーザープロファイルは、ユーザーデバイス（例えば、システム４００（図４）のコンポーネント）にローカルに格納され得る。ユーザープロファイルは、ユーザーおよび／またはユーザーのデバイスに関する情報を含むことができる。情報は、ユーザーの行動を能動的および／または受動的に監視することによって生成され得る。ユーザープロファイルには、１以上の情報源（サードパーティの情報源を含む）から収集された情報も含まれる場合がある。ユーザープロファイル内の情報は、ユーザーに関する個人を特定できる情報を含む場合があり、安全な方法および／または暗号化された方法で保存される場合がある。ユーザープロファイル内の情報には、ユーザー設定および／またはユーザーの好み、ユーザーのアクティビティ、ユーザーの人口統計、および／またはユーザー向けの機能をターゲットにする、および／またはユーザー向けに機能をカスタマイズするために使用されるその他の情報を含むことができる

さらに、ユーザープロファイルは、ユーザーが自分の好みをどのように説明するかについての情報、ユーザーが自分の好みをどのように説明するかについての決定（例：機械学習モデルを介して）、ユーザーの好みの説明が、１以上のコンテンツプロバイダーによって提供された基準の説明とどのように一致させるか、および／または基準を解釈し、基準を推奨に使用できるコンテンツに関する基準と一致させるために使用されるその他の情報を含むことができる。

いくつかの実施形態では、システムは、ユーザーがナビゲートし、および／または１以上のアプリケーションを使用するときに、コンテンツ（または推奨）をプリフェッチすることができる。システムは、ユーザープロファイル（例：ユーザーの好みや設定）内の情報、所定のまたは標準の推奨選択（例：アプリケーションによる）、アプリケーションが最後に使用されたときに以前に選択されたコンテンツ、および／またはその他の基準に基づいて、この情報をプリフェッチすることができる。例えば、システムは、アプリケーションおよび／またはユーザーインターフェース１００を自動的に投入するために、継続的かつリアルタイムでコンテンツをプリフェッチ（またはリクエスト）することができる。システムは、この情報を継続的にプリフェッチしたり、アプリケーションがアクティブ化された場合にすぐに使用できるように、この情報をローカルユーザーデバイスやエッジサーバーにプッシュしたりできる。したがって、システムは、推奨の入力に起因する遅延と、リモートソースが必要とする処理時間に起因する遅延を最小限に抑えることができる。

推奨１０２は、第１のリンクを含み得る。例えば、リンクはハイパーリンクを含むことができる。例えば、リンクは、ハイパーテキストファイルまたはドキュメントから別の場所またはファイルへのリンクを含むことができ、通常、画面上で強調表示された単語または画像をクリックすることによってアクティブ化される。リンクは、コンテンツを埋め込む必要なしにリモートコンテンツを表示するインラインリンクである場合がある。例えば、インラインリンクは、アクセス可能なコンテンツ（例えば、アクセス可能なコンテンツの画像、サムネイル、低解像度のプレビュー、トリミングされたセクション、または拡大されたセクション）の変更されたバージョンを表示する場合がある。あるいは、リンクは、アンカーリンクおよび／またはファットリンクであってもよい。いくつかの実施形態では、第１のリンクはプッシュ通知を含むことができる。例えば、プッシュ通知は、推奨が必要であり得るというシステム（例えば、システム３００（図３））による決定に基づいて、リアルタイムで生成された可能性がある。ユーザーインターフェース１００のフィールド１０６への基準のユーザー入力に応答して、システムはリクエストをリモートソース（例えば、クラウドコンポーネント４１０（図４））に送信することができる。

図２は、１以上の実施形態による、複数の推奨を生成するためのユーザーインターフェースの別の例示的な例を示す図である。例えば、ユーザーインターフェース２００は、フィールド２０２を含み得る。フィールド２０２は、フィールドに入力するためのユーザープロンプトを含み得る（例えば、フィールド２０２に入力されるべき値および／または値のタイプを説明する）。

ユーザープロンプト２０４の選択に応答して、システムは、（例えば、フィールド２０２および２０６に入力された値に基づいて）推奨のリクエストを生成することができる。代替的または追加的に、プロンプト２０４のユーザー選択に応答して、システムは、ユーザーインターフェース２００に示されるアプリケーションを識別し、ユーザーインターフェースに現在表示されているフィールド（例えば、フィールド２０２および２０６）が、アプリケーションによって自動的に入力される所定のフィールドに対応するかどうかを判断することができる。例えば、システムは、フィールドのタイプを決定するために使用されるメタデータを取得し、そのタイプをオーバーレイアプリケーションによって自動的に入力される所定のタイプのフィールドと比較することができる。フィールドが所定のフィールドに対応するという決定に応答して、システムは、リモートソース（例えば、クラウドコンポーネント４１０（図４））に、フィールドを埋めるための補足コンテンツのリクエストを送信することができる。

リクエストは、１つのアプリケーション（例えば、ローカルデバイス上に実装されるオーバーレイアプリケーション）からサーバー上のアプリケーション（例えば、システム３００（図３）を実装するサーバー）へのＡＰＩリクエスト（または呼び出し）を含み得る。リクエストには、ウェブサーバーがリクエストに応答するために使用できる１以上のタイプの情報が含まれる場合がある。例えば、リクエストは、アプリケーション固有のデータを選択し、アプリケーションを識別し、および／または投入するフィールドを決定するために使用される情報を含むことができる。

例えば、いくつかの実施形態では、アプリケーションはライブラリを作成して、ＡＰＩリクエストを使用して通信し、ユーザー、アプリケーション、およびセッションデータを管理することを簡素化することができる。したがって、システムは、アプリケーション／サブアプリケーションルーティングのより良い管理、データの一貫したキャプチャ、および／またはフィールドの識別を含む、複数のデータプロバイダーおよびフェデレーテッドルーティング開発をサポートする場合がある。例えば、サードパーティのアプリケーションには「paymenttype」というフィールドがあり、システムには「payTP」というラベルの付いたレコードに支払いタイプ情報を入力するためのデータがある場合がある。ライブラリを使用すると、ＡＰＩリクエストはリクエスト内の形式を正規化できる。

図３は、１以上の実施形態による、ユーザー供給の基準をコンテンツに一致させるための機械学習モデルアーキテクチャを示している。例えば、システムは、１以上の機械学習モデル、アーキテクチャ、およびデータ準備ステップを含むことができる。システムは、推奨を生成するために使用される１以上の決定にどの機械学習モデル（例えば、コンテンツにタグを付ける方法、ユーザーにタグを付ける方法、ユーザーが選択した基準を解釈する方法、プロバイダーにタグを付ける方法、および／またはプロバイダーが選択した基準を解釈する方法）を使用するかを決定することができる。システムは、最も正確な結果を提供するのに最適な機械学習モデルを（例えば、複数の機械学習モデルから）選択する場合がある。例えば、システムは、最も正確な結果を提供するために（例えば、並行して）トレーニングされる１以上のモデルを特徴とするさまざまなアンサンブルアーキテクチャから選択することができる。

システム３００は、モデル３０４を含むことができる。モデル３０４は、コンテンツベースのフィルタリングを使用する機械学習モデルを含むことができる（例：アイテム機能を使用して、ユーザーの以前のアクションまたは明示的なフィードバックに基づいて、ユーザーが好むものに類似した他のアイテムを推奨する）。システム３００は、モデル３０６を含むことができる。モデル３０６は、協調フィルタリングを使用する機械学習モデルを含むことができる（例：多くのユーザーから好みや嗜好情報を収集（共同）することで、ユーザーの興味関心を自動予測（フィルタリング））。

システム３００は、モデル３１０を含むことができる。モデル３１０は、コンテンツベースおよび協調フィルタリングの両方を使用する機械学習モデルを含むことができる。例えば、モデル３１０において、モデル３２０からの出力（例えば、コンテンツベースのコンポーネント（例えば、コンテンツベースのフィルタリングを使用するモデル））は、協調フィルタリングを使用するモデル（例えば、協調フィルタリングを使用するモデル）に入力され得る。システム３００は、モデル３６０を含むことができる。モデル３６０は、コンテンツベースおよび協調フィルタリングの両方を使用する機械学習モデルを含むことができる。例えば、モデル３６０では、モデル３７０（例えば、協調コンポーネント（例えば、協調フィルタリングを使用するモデル））からの出力を、コンテンツベースのフィルタリングを使用するモデル（例えば、コンテンツベースのフィルタリングを使用するモデル）に入力することができる。

システム３００は、モデル３３０を含み得る。モデル３３０は、コンテンツベースおよび協調フィルタリングの両方を使用する機械学習モデルを含むことができる。例えば、モデル３３０では、モデル３４０（例：コンテンツベースのコンポーネント（例：コンテンツベースのフィルタリングを使用するモデル））とモデル３５０（例：協調コンポーネント（例：協調フィルタリングを使用するモデル））の両方からの出力をモデル３３０に入力することができる。例えば、モデル３３０は、並行してトレーニングされるモデル３４０およびモデル３５０を含むことができる。

モデル３３０は、ハイブリッドアプローチのために１以上の技法を使用することができる。例えば、モデル３３０は、モデル３４０およびモデル３５０からの出力（例えば、推奨スコアの線形結合）を重み付けすることができる。代替的または追加的に、システムは、いくつかの基準を使用して推奨技術を切り替えるスイッチングハイブリッドを使用することができる。スイッチングハイブリッドでは、スイッチング基準を決定する必要があるため、推奨プロセスがさらに複雑になる可能性があり、これにより別のレベルのパラメータ化が導入される。代替的または追加的に、システムは、同時に提示されるモデル３４０およびモデル３５０からの推奨を使用することができる。これは、多数の推奨を同時に作成することが実際的である場合に可能である。代替的または追加的に、システムは、モデル３４０およびモデル３５０からの特徴の組み合わせを使用することができ、出力は単一のモデル（例えば、モデル３３０）にまとめられる。例えば、モデル３４０とモデル３５０の手法を組み合わせて、協調情報を各例に関連付けられた単なる追加の特徴データとして扱い、この拡張されたデータセットに対してコンテンツベースの手法を使用することができる。

代替的または追加的に、システムは段階的プロセスを含むカスケードハイブリッドを使用することができる。これは、１つのモデルが別のモデルによって与えられた推奨を改良するためである。システムは、ある技術からの出力が別の技術への入力機能として使用される機能拡張を使用することもできる。例えば、アイテムの格付けまたは分類を作成するためにある技法が使用され、その情報が次の推奨技法の処理に組み込まれる。代替または追加として、システムは、あるレコメンダによって学習されたモデルを別の推奨者への入力として使用することができる（例えば、モデル３４０はモデル３５０の入力になる）。

モデル３８０で、システム３００は、モデル３０４、３０６、３１０、３３０、および３６０のうちの１以上から出力を受信することができる。モデル３８０は、推奨を生成するために使用される決定のためにどの出力を使用するかを決定することができる。例えば、コンテンツに関する情報、ユーザーに関する情報、ユーザーが選択した基準を解釈するために使用される情報、プロバイダーに関する情報、および／またはコンテンツに関してプロバイダーが選択した基準を解釈するために使用される情報がまばらである場合、システムは、データがまばらな環境でより正確な機械学習モデルを使用することを選択する場合がある。対照的に、データがまばらでない場合、システムは、データのまばらさに関係なく最も正確な結果を提供する機械学習モデルの使用を選択する場合がある。例えば、コンテンツベースのフィルタリングアルゴリズムは、データがまばらな（またはトレーニング情報が利用できない）環境ではより正確な推奨を提供するが、コンテンツベースのフィルタリングアルゴリズム（または、コンテンツベースのフィルタリングアルゴリズムの影響を強く受けているモデル）は、データがまばらでない（またはトレーニング情報が利用可能なもの）環境では協調フィルタリングアルゴリズム（または協調フィルタリングアルゴリズムの影響を強く受けたモデル）ほど正確ではない。

いくつかの実施形態では、データ処理を減らすために、システム３００は、クラスタを識別するモデル３８０にクラスタ層をさらに備えることができる。例えば、システムは、同じグループ（例えば、クラスタ）内のアイテムが、他のグループ（例えば、他のクラスタ内）のアイテムよりも互いに（ある意味で）より類似するような方法でアイテムのセットをグループ化することができる）。例えば、システムは推奨（および／または推奨を生成するために使用される決定）をクラスタ化することができる。システムは、推奨を決定するために、さまざまな方法で複数のクラスタからのデータを比較する場合がある。いくつかの実施形態では、モデル３８０は、モデル３０４、３０６、３１０、３３０、および３６０からの出力の潜在表現も含み得る。システムは、機械学習モデル（例えば、モデル３８０）のエンコーダ部分に第１の特徴入力を入力して、第１の潜在表現を生成することができ、ここで、機械学習モデルのエンコーダ部分は、入力された特徴入力の潜在表現を生成するようにトレーニングされる。システムは、第１の潜在表現を機械学習モデルのデコーダ部分に入力して、推奨を生成するために使用されるデータの第１の再構成を生成することができ、ここで、機械学習モデルのデコーダ部分は、入力された特徴入力の再構成を生成するようにトレーニングされる。次いで、システムは、潜在表現を使用して推奨を生成することができる。潜在表現は次元削減された出力であるため、システムは処理されるデータ量を削減する。

モデル３８０は、モデル３０４、３０６、３１０、３３０、および３６０のどれが最も正確であるかを、所与の決定に使用されるデータの量に基づいて決定するように訓練され得る。次いで、モデル３８０は、出力３９０を生成することができる。システム３００は、出力３９０に基づいて推奨を生成することができる。

図４は、ユーザー供給の基準に基づくコンテンツ配達のための例示的なシステム図である。本明細書で説明する方法およびシステムは、任意の商品および／またはサービスに適用できることに留意されたい。本明細書ではメディアコンテンツに関して実施形態を説明しているが、本明細書の実施形態は任意の商品および／またはサービスに適用できることに留意されたい。さらに、推奨という用語は広く解釈されるべきである。例えば、推奨には、人的または電子的に消費可能なデータ部分が含まれる場合がある。例えば、推奨は、ユーザーおよび／またはコンピュータシステムによって消費されるメディアとして（例えば、ディスプレイデバイスのスクリーン上に）表示され得る。

図４は、ユーザー供給の基準に基づくコンテンツ配達のための例示的なシステム図である。図４に示されるように、システム４００はサーバー４２２およびユーザーターミナル４２４（実施例によってはパーソナルコンピューターに相当してよい）を含んでよい。図４では、それぞれサーバーおよびパーソナルコンピュータとして示されているが、サーバー４２２およびユーザ端末４２４は、ラップトップコンピューター、タブレットコンピューター、ハンドヘルドコンピューター、「スマート」、ワイヤレス、ウェアラブル、および／またはモバイルデバイスを含むその他のコンピューター機器(サーバーなど)を含むが、これらに限定されない、任意のコンピューティングデバイスであり得ることに留意されたい。図４は、クラウドコンポーネント４１０も含む。あるいは、クラウドコンポーネント４１０は、上述の任意のコンピューティングデバイスであってもよく、任意のタイプのモバイル端末、固定端末、または他のデバイスを含んでもよい。例えば、クラウドコンポーネント４１０は、クラウドコンピューティングシステムとして実装することができ、１以上のコンポーネントデバイスを特徴とすることができる。システム４００が３つのデバイスに限定されないことにも留意されたい。ユーザーは、例えば、１以上のデバイスを利用して、互いに、１以上のサーバー、またはシステム４００の他のコンポーネントと対話することができる。本明細書では、システム４００の特定のコンポーネントによって実行されるものとして１以上のオペレーションが説明されているが、これらのオペレーションは、いくつかの実施形態では、システム４００の他のコンポーネントによって実行され得ることに留意されたい。例として、１以上のオペレーションがサーバー４２２のコンポーネントによって実行されるものとして本明細書に記載されているが、これらのオペレーションは、一部の実施形態では、クラウドコンポーネント４１０のコンポーネントによって実行されてもよい。いくつかの実施形態では、本明細書に記載の様々なコンピューターおよびシステムは、記載の機能を実行するようにプログラムされた１以上のコンピューティングデバイスを含むことができる。さらに、または代わりに、複数のユーザーがシステム４００および／またはシステム４００の１以上のコンポーネントと対話することができる。例えば、一実施形態では、第１のユーザーおよび第２のユーザーは、２つの異なるコンポーネントを使用してシステム４００と対話することができる。

サーバー４２２、ユーザー端末４２４、およびクラウドコンポーネント４１０のコンポーネントに関して、これらのデバイスのそれぞれは、入出力（以下「Ｉ／Ｏ」）経路を介してコンテンツおよびデータを受信することができる。これらのデバイスのそれぞれは、Ｉ／Ｏ経路を使用してコマンド、リクエスト、および他の適切なデータを送受信するためのプロセッサおよび／または制御回路も含み得る。制御回路は、任意の適切な処理、記憶、および／または入力／出力回路を備えることができる。これらのデバイスのそれぞれは、データの受信および表示に使用するためのユーザー入力インターフェースおよび／またはユーザー出力インターフェース（例えば、ディスプレイ）も含むことができる。例えば、図４に示されるように、サーバー４２２とユーザー端末４２４の両方が、データを表示するためのディスプレイを含む（例えば、図１に示されるように）。

さらに、サーバー４２２およびユーザー端末４２４はタッチスクリーンスマートフォンとして示されているので、これらのディスプレイはユーザー入力インターフェースとしても機能する。一部の実施形態では、デバイスはユーザー入力インターフェースもディスプレイも持たず、代わりに別のデバイス（例えば、コンピューター画面などの専用表示デバイスおよび／またはリモコン、マウス、音声入力などの専用入力デバイス）を使用してコンテンツを受信および表示することができることに留意されたい。さらに、システム４００内のデバイスは、アプリケーション（または別の適切なプログラム）を実行することができる。アプリケーションは、プロセッサおよび／または制御回路に、コンテンツの推奨に関連するオペレーションを実行させることができる。いくつかの実施形態は、機械学習モデルに関して本明細書で具体的に説明されているが、他の実施形態では、機械学習モデルの代わりに、または機械学習モデルに加えて、他の予測統計に基づく分析モデルを使用することができることに留意されたい。

これらのデバイスのそれぞれは、電子記憶装置の形でメモリを含むこともできる。電子記憶装置は、情報を電子的に記憶する非一時的な記憶媒体を含むことができる。電子記憶装置の電子記憶媒体は、（ｉ）サーバーまたはクライアント装置と一体的に（例えば、実質的に取り外し不能に）提供されるシステム記憶装置、または（ｉｉ）例えばポート（ＵＳＢポート、ｆｉｒｅｗｉｒｅポートなど）またはドライブ（ディスクドライブなど）を介した、サーバー、または、クライアントデバイスに取り外し可能に接続可能な取り外し可能な記憶装置の一方または両方を含むことができる。電子記憶装置は、光学的に可読な記憶媒体（例えば、光ディスクなど）、磁気的に可読な記憶媒体（例えば、磁気テープなど）、磁気ハードドライブ、フロッピードライブなど)、電荷ベースのストレージメディア（ＥＥＰＲＯＭ、ＲＡＭなど）、ソリッドステートストレージメディア（フラッシュドライブなど）、および／またはその他の電子的に可読なストレージメディアのうちの１以上を含むことができる。電子ストレージは、１以上の仮想ストレージリソース（例えば、クラウドストレージ、仮想プライベートネットワーク、および／または他の仮想ストレージリソース）を含み得る。電子ストレージは、ソフトウェアアルゴリズム、プロセッサによって決定された情報、サーバーから取得された情報、クライアントデバイスから取得された情報、または本明細書で説明した機能を可能にする他の情報を格納することができる。

図４は、通信経路４２８、４３０、および４３２も含む。通信経路４２８、４３０、および４３２は、インターネット、携帯電話ネットワーク、モバイル音声またはデータネットワーク（例えば、５ＧまたはＬＴＥネットワーク）、ケーブルネットワーク、公衆交換電話ネットワーク、または他のタイプの通信ネットワークまたは通信ネットワークの組み合わせを含み得る。通信経路４２８、４３０、および４３２は、衛星経路、光ファイバー経路、ケーブル経路、インターネット通信をサポートする経路（ＩＰＴＶなど）、自由空間接続（ブロードキャストまたはその他の無線信号用）、またはその他の適切な有線または無線など通信経路またはそのような経路の組み合わせなどの１以上の通信経路を別々にまたは一緒に含むことができる。コンピューティングデバイスは、一緒に動作する複数のハードウェア、ソフトウェア、および／またはファームウェアコンポーネントをリンクする追加の通信経路を含むことができる。例えば、コンピューティングデバイスは、コンピューティングデバイスとして一緒に動作するコンピューティングプラットフォームのクラウドによって実装され得る。

クラウドコンポーネント４１０は、ユーザーのユーザーデータを格納するように構成されたデータベース（表またはグラフ）であってもよい。例えば、データベースは、システムが以前の対話を通じて能動的および受動的に収集したユーザーデータを含むことができる。代替的または追加的に、システムは、ユーザー、プロバイダー、および／またはコンテンツに関する複数の情報源のためのクリアリングハウスとして機能することができる。この情報は、クロスプラットフォームプロファイルにコンパイルされる場合がある。例えば、クラウドコンポーネント４１０のうちの１以上は、マイクロサービスおよび／またはそのコンポーネントを含み得る。いくつかの実施形態では、マイクロサービスは、それぞれが複数の変数のうちの１以上を収集するアプリケーションの集合であってもよい。

クラウドコンポーネント４１０は、機械学習モデルであり得るモデル４０２を含み得る。モデル４０２は、入力４０４を取り、出力４０６を提供することができる。入力には、トレーニングデータセットやテスト データセットなどの複数のデータセットが含まれる場合がある。複数のデータセット（例えば、入力４０４）のそれぞれは、ユーザーデータ、オリジナルコンテンツ、および／または代替コンテンツに関連するデータサブセットを含み得る。いくつかの実施形態では、出力４０６は、モデル４０２を訓練するための入力としてモデル４０２にフィードバックされてもよい。例えば、システムは最初にラベル付けされた特徴入力を受信し、ここで、第１のラベル付き特徴入力は、第１のラベル付き特徴入力（例えば、ユーザーが基準をネイティブに記述する方法に基づく特徴入力）の既知の説明（例えば、基準を解釈するためにシステムによって使用される）でラベル付けされる。次いで、システムは、第１の機械学習モデルをトレーニングして、第１のラベル付けされた特徴入力を既知の説明で分類することができる。

別の実施形態では、モデル４０２は、その予測（例えば、出力４０６）および参照フィードバック情報（例えば、精度、参照ラベル、または他の情報のユーザー指示）の評価に基づいてその構造（例：重み、バイアス、またはその他のパラメータ）を更新することができる。モデル４０２がニューラルネットワークである別の実施形態では、ニューラルネットワークの予測と参照フィードバックとの間の差異を調整するために接続重みを調整することができる。さらなるユースケースでは、ニューラルネットワークの１以上のニューロン（またはノード）は、更新プロセス（例えば、エラーの逆伝播）を容易にするために、それぞれのエラーがニューラルネットワークを介して逆方向に送信されることを必要とする場合がある。接続重みの更新は、例えば、順方向経路が完了した後に逆方向に伝搬されたエラーの大きさを反映する場合がある。このようにして、例えば、モデル４０２を訓練して、より良い予測を生成することができる。

いくつかの実施形態では、モデル４０２は、人工ニューラルネットワークを含み得る。そのような実施形態では、モデル４０２は、入力層および１以上の隠れ層を含むことができる。モデル４０２の各ニューラルユニットは、モデル４０２の他の多くのニューラルユニットと接続することができる。このような接続は、接続された神経単位の活性化状態に対する影響において、強制的または抑制的である可能性がある。いくつかの実施形態では、各個々のニューラルユニットは、その入力のすべての値を組み合わせる合計関数を有することができる。いくつかの実施形態では、各接続（またはニューラルユニット自体）は、信号が他のニューラルユニットに伝播する前にそれを超えなければならないように、閾値関数を有してもよい。モデル４０２は、明示的にプログラムされているのではなく、自己学習および訓練されている可能性があり、従来のコンピュータープログラムと比較して、問題解決の特定の領域で大幅に優れたパフォーマンスを発揮できる。訓練中、モデル４０２の出力層はモデル４０２の分類に対応することができ、その分類に対応することが知られている入力は、訓練中にモデル４０２の入力層に入力することができる。テスト中に、既知の分類のない入力が入力層に入力される場合があり、決定された分類が出力される場合がある。

いくつかの実施形態では、モデル４０２は、複数の層を含むことができる（例えば、信号経路が前層から後層まで横断する場合）。いくつかの実施形態では、モデル４０２によって逆伝播技法を利用することができ、前方刺激を使用して「前方」ニューラルユニットの重みをリセットする。いくつかの実施形態では、モデル４０２の刺激および抑制は、より無秩序で複雑な様式で相互作用する接続により、より自由に流れることができる。テスト中、モデル４０２の出力層は、所与の入力がモデル４０２の分類（例えば、インシデント）に対応するかどうかを示すことができる。

例えば、いくつかの実施形態では、システムは、機械学習モデル（例えば、人工ニューラルネットワーク）をトレーニングして、特徴入力に基づいて既知の説明を検出することができる。例えば、システムは、ユーザーデータ（例えば、図１～２で説明した変数および変数のカテゴリを含む）を受信することができる。次に、システムは、トレーニングデータに基づいて一連の特徴入力を生成することができる。例えば、システムは、第１の既知のエラー（またはエラー尤度）に対応するユーザーデータを含むトレーニングデータに基づいて、第１の特徴入力を生成することができる。システムは、第１の特徴入力を第１の既知の説明でラベル付けすることができる（例えば、データを説明の分類に対応するものとしてラベル付けする）。

例えば、いくつかの実施形態では、システムは、機械学習モデル（例えば、人工ニューラルネットワーク）をトレーニングして、推奨（例えば、所与の基準）を決定することができる。例えば、システムは基準（例えば、ユーザーの説明を含む）を受信することができる。次いで、システムは、基準に基づいて一連の特徴入力を生成することができる。例えば、システムは、ユーザーの説明のモデルの解釈に対応するコンテンツを含むトレーニングデータに基づいて特徴入力を生成することができ、システムは応答（例えば、コンテンツの推奨）を決定することができる。

次いで、システムは、機械学習モデルを訓練して、ラベル付けされた第１の特徴入力に基づいて第１の既知のコンテンツを検出することができる。システムはまた、機械学習モデル（例えば、同じまたは異なる機械学習モデル）を訓練して、ラベル付けされた第２の特徴入力に基づいて第２の既知のコンテンツを検出することができる。例えば、トレーニングプロセスには、トレーニングマトリックス（機械学習モデルなど）ごとにいくつかのランダム値を初期化し、初期ランダム値を使用して入力フィーチャの出力を予測しようとすることが含まれる場合がある。最初は、モデルの誤差は大きくなるが、モデルの予測を正しい出力（既知の分類など）と比較すると、モデルが必要な予測を提供するまで、モデルは重みとバイアスの値を調整できる。

システムは、マイクロサービスおよび／または他の手段を介してユーザーデータを受信することができる。例えば、マイクロサービスは、それぞれが複数の変数のうちの１以上を収集するアプリケーションの集合を含むことができる。例えば、システムは、ユーザーデバイス上で、またはサービスプロバイダーで（例えば、ユーザーがアクセスするクラウドサービスを介して）動作するＡＰＩ層からユーザーデータを抽出することができる。追加または代替として、システムは、ユーザーデータファイルを（例えば、リアルタイムまたはほぼリアルタイムでのダウンロードおよび／またはストリーミングとして）受信することができる。

システム４００は、ＡＰＩ層４５０も含む。例えば、いくつかの実施形態では、システムは、１以上のＡＰＩおよび／またはＡＰＩ層として実装され得る。いくつかの実施形態では、ＡＰＩ層４５０は、サーバー４２２またはユーザー端末４２４上に実装され得る。代替的または追加的に、ＡＰＩ層４５０は、クラウドコンポーネント４１０のうちの１以上の上に存在し得る。ＡＰＩ層４５０（ＲＥＳＴまたはウェブサービスＡＰＩ層であり得る）は、１以上のアプリケーションのデータおよび／または機能への分離されたインターフェースを提供し得る。ＡＰＩ層４５０は、アプリケーションと対話する共通の言語にとらわれない方法を提供することができる。ＷｅｂサービスＡＰＩは、オペレーションと情報交換に使用されるデータ型の観点からサービスを説明している、ＷＳＤＬと呼ばれる明確に定義されたコントラクトを提供する。通常、ＲＥＳＴ ＡＰＩにはこの規約がなく、代わりに、Ｒｕｂｙ、Ｊａｖａ、ＰＨＰ、ＪａｖａＳｃｒｉｐｔなどのほとんどの一般的な言語のクライアントライブラリで文書化されている。ＳＯＡＰ Ｗｅｂサービスは、企業内サービスの公開や、Ｂ２Ｂトランザクションでのパートナーとの情報交換のために従来から採用されてきた。

ＡＰＩ層４５０は、さまざまなアーキテクチャ構成を使用することができる。例えば、システム４００は部分的にＡＰＩ層４５０に基づいている場合があり、ＳＯＡＰおよびＲＥＳＴｆｕｌ Ｗｅｂサービスの強力な採用があり、サービスリポジトリや開発者ポータルなどのリソースを使用するが、ガバナンス、標準化、関心の分離は低くなる。あるいは、システム４００は、ＡＰＩ層４５０、サービス、およびアプリケーションなどの層の間の関心の分離が適所にあるように、ＡＰＩ層４５０に完全に基づいていてもよい。

いくつかの実施形態では、システムアーキテクチャはマイクロサービスアプローチを使用することができる。このようなシステムは、マイクロサービスが存在するフロントエンド層とバックエンド層の２タイプの層を使用する場合があり、この種のアーキテクチャでは、ＡＰＩ層４５０の役割により、フロントエンドとバックエンドの間の統合が提供される場合がある。そのような場合、ＡＰＩ層４５０は、ＲＥＳＴｆｕｌ ＡＰＩ（フロントエンドへの公開、またはマイクロサービス間の通信さえも）を使用することができる。ＡＰＩ層４５０は、ＡＭＱＰ（例えば、Ｋａｆｋａ、ＲａｂｂｉｔＭＱなど）を使用することができる。ＡＰＩ層４５０は、ｇＲＰＣ、スリフトなどの新しい通信プロトコルの初期使用を使用することができる。

いくつかの実施形態では、システムアーキテクチャは、オープンＡＰＩアプローチを使用することができる。そのような場合、ＡＰＩ層４５０は、商用またはオープンソースのＡＰＩプラットフォームおよびそれらのモジュールを使用することができる。ＡＰＩ層４５０は、開発者ポータルを使用することができる。ＡＰＩ層４５０は、ＷＡＦおよびＤＤｏＳ保護を適用する強力なセキュリティ制約を使用することができ、ＡＰＩ層４５０は、外部統合のための標準としてＲＥＳＴｆｕｌ ＡＰＩを使用することができる。

図５は、１以上の実施形態による、ユーザー供給の基準を一致させるためのフローチャートを示す。本明細書で開示される方法およびシステムは、任意の媒体（ストア、ウェブサイト、データベース、データおよび／またはブロックチェーン、および／またはブロックチェーンの分散機能で組織化された他の同様の構造、および／または分散データ構造管理技術および／または分散台帳技術を介して）（まとめておよび／または個別に、「媒体」）に適用され得ることに留意されたい。例えば、本明細書で説明する実施形態はオーバーザトップ（「ＯＴＴ」）コンテンツおよびストリーミングメディアに関するが、本明細書で開示する実施形態は多数の技術分野に適用できる。

いくつかの実施形態では、本明細書で議論される推奨の主題は、任意の潜在的な商品および／またはサービスを指す場合があり、シリアル番号または製品ＳＫＵによって識別される場合がある。例えば、システムは、シリアル番号または製品ＳＫＵを特徴とするメディア資産の推奨を生成する場合がある。各商品および／またはサービスには、１つ以上の関連付けられたユーザー供給の基準がある。これらの基準には、好みのジャンル、長さ、タイプ、特徴的なキャラクター、注目の俳優など、ユーザーの好みが含まれる場合がある。追加または代替として、潜在的なユーザー基準は以下のことを示す場合がある：（ａ）喜んで支払う最高額；（ｂ）必要な商品および／またはサービスの状態；（ｃ）どのタイプのプロバイダー（「指定プロバイダー」）からコンテンツを受信するか（これはさらに、カテゴリ、評判、場所、電子小売業者、実店舗の小売業者、特定の小売業者、小売業者の規模、距離などに基づく場合がある）；（ｄ）商品および／またはサービスの単位数；（ｅ）オファーの期間または失効条件（つまり、購入後５分で失効するなど）；（ｆ）複数のプロバイダーから奇数ロットを受信する意思があるかどうか；（ｇ）ユーザーまたはプロバイダーが自分の名前を公開または匿名にしたい場合；（ｈ）ユーザーとプロバイダーが、ＩＤがパブリックかプライベートかについて合意できるかどうか；（ｉ）ユーザーが希望する返品条件；（ｊ）ユーザーが商品またはサービスに対して支払う意思がある方法；（ｋ）配送または集荷などで複数のアイテムをグループ化するかどうか（「条件」）；（ｌ）価格やその他の販売属性がシステムに改善されるまで、ユーザーがどのくらいの期間待つか、その後、現在のデータと予測に基づいて自動的に販売を行うか；および／または、（ｍ）ユーザーが待つことによって、どれだけのリスクと正味の効用を受け入れるか。

ステップ５０２で、プロセス５００（例えば、図４で説明した１以上のコンポーネントを使用する）は、ユーザーからのコンテンツ推奨に対するユーザーの好みを受信することができる。例えば、システムは、ユーザーインターフェース１００（図１）またはユーザーインターフェース２００（図２）を介してユーザー入力を受信することができる。次いで、システムは、手動で入力された、または自動的に決定された（例えば、ユーザープロファイルに基づいて）これらの基準を使用して、ユーザーのコンテンツを見つけることができる。したがって、ユーザーは、任意のコンテンツ推奨に使用したい基準を定義することができる。

ステップ５０４で、プロセス５００（例えば、図４で説明した１以上のコンポーネントを使用して）は、ユーザーのユーザープロファイルを取得することができる。例えば、いくつかの実施形態では、システムは、基準をユーザーのプロファイルとさらに比較して、基準を明確にし、定量化し、および／または認定することができる。例えば、ユーザーが「怖い映画」を好むと入力した場合、システムはユーザーの視聴履歴を確認して、ユーザーが視聴した映画を判断する。例えば、ユーザープロファイルは、ユーザーの以前のアクションに基づいている場合がある。上述のように、システムは、データの様々なフィールドを比較して、どのデータおよび／またはどの値を比較するかを決定することができる。

ステップ５０６で、プロセス５００（例えば、図４で説明した１以上のコンポーネントを使用）は、ユーザーの好みをユーザープロファイルと比較して、ユーザーに対するコンテンツ推奨の基準を決定することができる。例えば、システムは、これらの映画に関するメタデータまたは他の情報を比較して、映画が特定のジャンル（ホラーなど）に対応するかどうかを判断することができる。これらの映画がジャンルに対応するとシステムが判断した場合、システムはそのジャンルに対応する推奨基準を設定することができる。別の例では、システムは、ユーザープロファイルからの情報を使用して、受信したユーザーの好み（例えば、入力）を解釈し、および／または業界および／または一般的な標準に基づいて入力を正規化することができる。

いくつかの実施形態では、ユーザーの好みをユーザープロファイルと比較して、ユーザーにコンテンツを推奨する基準を決定することは、ユーザーの好みおよびユーザープロファイルに基づいて、第１の機械学習モデル（例えば、図３～４で説明したように）のための第１の特徴入力（例えば、図６で説明したように）を生成すること、および基準を受信するために、第１の機械学習モデルに第１の特徴入力を入力することをさらに含み、ここで、第１の機械学習モデルは、第１のコンテンツベースフィルタリングコンポーネントおよび第１の協調フィルタリングコンポーネントを含む（例えば、図３～４で説明したように）。

例えば、ユーザーは、潜在的な選択に関して行う意思があるすべての条件を指定し、ランク付けすることができる。このようなランキングは、推奨システムに特に関連する、嗜好学習として知られる機械学習のサブフィールドのアプリケーションと見なすことができる。例えば、上記の図３で説明したように、システムは、データ処理を削減するために、１以上のステップ（例えば、クラスタリングおよび／または潜在表現の生成）を実行することができる。追加または代替として、一部の実施形態では、システムは、ユーザープロファイルに格納された情報に従って、関連性のないコンテンツの漸進的な除去を実行することができる。システムは、明示的／能動的（例：ユーザーにアイテムに関する意見を表明させる）または暗黙的／受動的（例：いくつかの行動特性の研究）な方法で取得されたユーザーの関心に関する情報を処理するモデルを使用し、これらのデータを利用して推奨アイテムのリストを生成する場合がある。

さらに、いくつかの実施形態では、システムは、ユーザーに関する情報（例えば、ユーザープロファイルから取得される）、業界情報、またはプロバイダーからの情報に基づいて、選択および／またはランキングを正規化することができる。例えば、システムは １以上の人工知能アルゴリズムを使用して、ユーザー基準をユーザーの実際の行動や感情に一致させることができる。それに加えて、または代わりに、さまざまなタイプの最適化人工知能アルゴリズムを使用して、ユーザー/プロバイダーの一致を見つけることができる(上記で説明したように)。

ステップ５０８で、プロセス５００（例えば、図４で説明した１以上のコンポーネントを使用）は、コンテンツプロバイダーによって提供されるコンテンツのコンテンツ属性を受信することができる。例えば、ユーザーが提供する基準と同様に、システムはプロバイダーに、ユーザー供給の基準と比較されるコンテンツとアウトライン条件、タグ、およびメタデータ（まとめて「コンテンツ属性」）を説明する機会を提供する場合がある。例えば、プロバイダーは、レビューするユーザー属性のフィールドを提供することにより、推奨するユーザー（「指定ユーザー」）を制限する場合がある。さらに、指定ユーザーの範囲は、支払い条件、信用力、レビュー、配送条件、場所、および／またはプロバイダーが選択したその他のユーザー属性を中心に展開する場合がある。この情報は、「プロバイダープロファイル」に含まれる場合がある。さらに、システムは、第三者からのレビューに基づいてプロバイダープロファイルを入力する場合がある。顧客のさまざまな高レベルの複合属性に加えて、データの重み付けとソースは、機械学習を利用して、顧客とプロバイダー間の相互作用、および指定された好みに基づいて作成、変更、または改善できる。

ステップ５１０で、プロセス５００は（例えば、図４で説明した１以上のコンポーネントを使用して）、基準をコンテンツ属性に一致させる。例えば、システムは、ユーザー供給の基準をプロバイダー提供のコンテンツ属性に一致させることができる。 一致を決定すると、システムは推奨を発行する場合がある。「推奨」は、コンテンツを閲覧するためのオファーおよび／またはコンテンツを購入するためのオファーを含み得ることに留意されたい。いくつかの実施形態では、「推奨」は、プロバイダーがユーザーの条件に同意することを含むことができる。例えば、ユーザーは、推奨を提供するプロバイダーによって受け入れられる基準（費用を含む）の形でオファーを発行することができる。別の例では、基準は承認されたプロバイダーのリストを含むことができ、コンテンツ属性はプロバイダーを識別することができる。次いで、システムは、プロバイダーが承認されたプロバイダーのリストにあると判断することによって、基準をコンテンツ属性に一致させることができる。

いくつかの実施形態では、同じ基準を有するユーザーは、異なる基準（例えば、金銭的条件のみ）に基づいて列に並ぶことができ、または前のユーザーとまったく同じ条件で購入オファーに参加することができる。とにかく、そのような仕様はすべて公共政策（非人種差別、非性差別など）に準拠する必要がある。

本制度において、特定提供者、条件、特定利用者の範囲は本制度の管理下にある。したがって、誰がどの条件の下で参加を許可されるかという点で、制御は非常に制御されたものから実質的に分散化されたものまでさまざまである。トランザクションは、任意の媒体で発生する可能性がある。プライバシーも当事者が設定できる。このシステムでは、ユーザーが１以上の基準（価格や購入条件の柔軟性など）で互いに競合する可能性があることを認識しておく必要がある。

ステップ５１２で、プロセス５００は（例えば、図４で説明した１以上のコンポーネントを使用して）、基準をコンテンツ属性に一致させることに応答して、コンテンツについてユーザーに表示するための推奨を生成する。推奨が発行された後、システムは選択を確定する場合がある。選択を確定するために、指定プロバイダーはユーザーオファーを選択し（または、ユーザー基準とプロバイダー要件の合流点に基づいてシステムが自動的に一致させる）、ユーザーが設定した条件を受け入れ、コンテンツを提供する。提供されたコンテンツの登録は、ユーザーと提供者の間で直接行われる場合がある。選択が確定すると、任意の媒体の会計システムまたは非公開で記録できる。記録には、トランザクションに入った条件、および販売条件の一部である特定のプロバイダー／ユーザーが含まれる。さらに、合意に基づいて、記録をシステムの独自のデータベースまたは独自の分散型データ構造に秘密裏に投稿することができる。

当事者がトランザクションの実行を公表することを許可した場合、システムの独自のデータ構造または時間インデックス付きグラフデータベースは、最終的なトランザクションをオフチェーントランザクションとして記録することもでき、また、他の場所で報告されているように、システムで利用可能な全体的なデータに追加するために、そのようなトランザクションが発生したことを確認するオラクルになることができる。例えば、システムは複数のトランザクションのためのクリアリングハウスを運営することができ、そこでは異なる当事者が分散された方法でトランザクションの金額と条件に影響を与える可能性がある。このような状況では、関係する「プロバイダー」が適切な資格情報（つまり、肯定的なレビューや、特定の基準を満たしているというサードパーティの判断など）を持っていない可能性があり、そのため、評判の良いプロバイダーを必要とするユーザーは、より厳密な指定プロバイダー入力とユーザーの属性をリクエストするため、偽のトランザクションを記録する機能は制限される。さらに、または代わりに、システムは評判の悪い当事者を禁止することができる。

この説明と特許請求の範囲では、「ユーザー」と「プロバイダー」の定義が拡張されており、商品またはサービスの提供または販売の推奨に限定されないことに注意することが重要である。これには、リーストランザクション、共有トランザクション、部分所有権トランザクション、単なる「購入」と「販売」を超えた一時的なトランザクションなどが含まれる。例えば、このシステムでは、これらのいずれについても推奨を行うことができる。リースまたは部分所有権に関連するトランザクションの場合、追加のフィールドには、例えば、アイテムの費用／保険を購入する意思を含めることができる。

さらなる実施形態として、システムはモノのインターネット（ＩｏＴ）上に展開することができ、それによってデバイスのネットワークを介してシステムとの自動または統合通信が行われる。例えば、昼食を探している人は、特定の時間または特定の状況から、発行後５分で自動的に有効期限が切れる、半径３００ヤード以内のタイプ／カテゴリのランチに１０ドルを支払うことを申し出る、自動的なメッセージを送信するようにスマートフォンをプログラミングすることで、システムを利用できる。したがって、その人は、自分の特定の基準に適合する「推奨」をリクエストする場合がある。

オファーは、彼女のオファーの仕様に適合する可能性のあるレストランのＩｏＴネットワークに「ヒット」し、そのネットワーク内で接続されたすべてのデバイスにヒットする可能性がある。技術的には、これは分散型データベースではなくＩｏＴネットワーク上でのみ保持される可能性があるため、以前に定義された媒体への投稿と異なる場合と異ならない場合がある。これらのレストランは、受け入れるかどうかを自動的に決定でき、最初に受け入れたレストランが入札に勝つ（例：推奨される）。あるいは、ユーザーは、所与の時間枠内で受け入れるすべてのレストランが手動選択のためにユーザーに提示されるように指定することができる。これらはすべてネットワークで自動化でき、これにより、資格のあるレストランのみがアクセスできる電子媒体にオファーが掲載され、そして、それらのレストランは、オファーを受け入れてトランザクションを処理するために内部のＩｏＴ接続デバイスを横断する、そのようなオファーに対する応答を事前にプログラムすることができる。５Ｇネットワーク以降が登場し、使用されるようになると、技術的に可能な範囲で、このようなトランザクションを自動化するために、システムがＩｏＴネットワークに展開されることが予想される。いくつかの実施形態では、人は、推奨を「確認」する機会をさらに有することができる。別の方法として、システムは、レストランが個人の推薦リクエストを受け入れた（そして最初に受け入れた）ことに応じて、推薦を自動的に確認することができる。

システムの別の実施形態は、複数当事者のトランザクションであり、これにより、トランザクションを履行するのに多くの関係のない当事者が必要になる。例としては、ユーザー、複数のプロバイダー、１以上の貸し手、１以上の荷送人、チェーンの上流にあるサプライヤーなどがあるが、これらに限定されない。入札のフィールドには、必要に応じてこれらすべての要件が含まれ、システムを拡張してより現実的なシナリオを満たすことができ、これにより、そのようなトランザクションを完了するには複数の当事者が必要になることがあり、多くの場合実際にそうであり、特定の従順なアイテム（カスタムまたは手作りなど）の生産をその場で計画できるため、リスクとオーバーヘッドが削減される。

システムのアルゴリズムの詳細（例えば、図３～４で説明し、図６で説明したように）は、システムの参加者にとって価格設定、マッチメイキング、および所望の機能の自動／体系的な最適化を可能にするように設計されている。参加者は、所望の基準（例：価格、商品の特徴、指定業者等）を手動で入力するか、代わりに、提供されているオペレーションズリサーチと人工アルゴリズムを使用して、一部またはすべてのフィールドを自動的に入力できるようにすることができ、好みの入力から、価格やその他の属性の一致と割り当てのガイドまで、さまざまな目標がある。

このシステムには、従来の推奨 システムに比べて多くの技術的改良が加えられていることに注意されたい。これらの技術的な利点には、追加の潜在的な推奨を含むより正確な推奨システム、推奨アクティビティの効率の向上、推奨の提供と受信の柔軟性が含まれる。

例えば、従来のＯＴＴコンテンツ配達では、プロバイダーはコンテンツをＷｅｂサイト、データベース、ストアに配置し、ユーザーはそれらのリストに反応している。コンテンツがリストされていないか見つからない場合、ユーザーはコンテンツが利用可能かどうかわからない。システムでは、ユーザーが特定の基準を設定し、プロバイダーのコンテンツ記述が正規化されているため、追加のコンテンツが見つかる場合がある。さらに、ユーザーが基準を提供すると、プロバイダーは潜在的なユーザーが何を望んでいるかについてより多くを知ることができる。

例えば、システム内で、ユーザーＸは、製品Ａ（例：映画のレンタル）を選択する意思があること、彼女が選択する許可プロバイダー（例：ストリーミングメディアプロバイダー）の範囲、およびそのような選択の条件（レンタル期間、レンタル料金、ジャンルタイプなど）を示している。条件が、許可されたプロバイダーによって既に公開されているものよりもユーザーＸにとって有利である場合、ユーザーＸは、システムが整っていないと利用できない潜在的な推奨を導入するための新しいメカニズムを導入した。

追加の技術的利点は、推奨基準を最適化できることである。例えば、システムがユーザー供給の基準とタグ、コンテンツ記述、および／またはプロバイダーによって提供される推奨要件の両方を正規化すると、データ、用語などの一貫性がないために通常は提供されない推奨が発行される。

さらに、ユーザーは、推奨を受信するための特定の基準（契約条件など）を決定することができる。現在、ユーザーはプロバイダーを見つけて、提供されている条件が何であれ、推奨を受け入れることを余儀なくされている。

さらに、集約されたユーザー基準（明示的および推論された暗黙的）をプロバイダーが利用できるようにすることで、システムは、提供されるコンテンツと作成されるコンテンツの両方を調整するために、ユーザーとプロバイダーが同様に使用できるより多くのデータを提供する。

このシステムは、プロバイダーやユーザー向けの記述的および予測的分析など、他の形式の自動化されたビジネスインテリジェンス、メタデータ、属性、および時間次元を含むグラフとしてデータを格納するためのデータ構造も提供し、システム内のすべてのトランザクションデータを利用し、時間をかけて、ユーザーとトランザクションのグラフ構造を考慮し、必要に応じて、グラフニューラルネットワークやその他の機械学習手法を使用する。これらには、ユーザーのセグメンテーション、販売および作成された製品のタイプ間の傾向、これらと先行指標（ＮＬＰ、経済など）との相関関係、季節性、将来の価格設定、およびサプライチェーンにおける製品とリソースの可用性が含まれる。

推奨を作成するために、システムは最適化アルゴリズムを使用してプロバイダーと用途を一致させる場合がある。最適化アルゴリズムは、（例えば、図３で説明したように）１以上のモデルによって使用することができる。いくつかの実施形態では、これは、一般的な以下の形式の関連する最適化プログラムを解くことを含む：
Ｆ（ｘ）を最小化する （１）
Ｇ_ｉ（ｘ）≦ｂ_ｉ，ｉ＝１，…，Ｍに従う （２）
ここで、（１）のＦは最適化される目的関数であり、（２）の不等式（適切な関数Ｇ_ｉ、ｉ＝１、…、Ｍと共に）は、満たされる制約であり、Ｍは正の整数であり、ｘは０－１バイナリ変数ｘ_ｉｊｋ，１≦ｉ，ｊ，ｋ≦Ｎ（任意の適切な順序）のベクトルである。値ｘ_ｉｊｋを使用した問題（１）～（２）の解決策は、どのコンテンツとプロバイダーをどのユーザーに割り当てる必要があるかを示す。実際、プロバイダーｋからユーザーｉへのコンテンツｊの割り当ては、ｘ_ｉｊｋ＝１の場合に限り、（１）－（２）の最適解に対応する（ここでは、表記を簡単にするために、コンテンツ、選択肢、コンテンツプロバイダー、およびユーザーのそれぞれの数はすべて同じであり、Ｎに等しいと仮定している）。

例えば、システムは、ユーザーがシステムを介して基準を宣言すると、すべてのユーザーの特定の基準（例えば、購入したすべてのコンテンツおよび／または製品またはサービスに対して支払われる価格）の値の合計を最小化する場合がある。さらに、システムは、所与の数のユーザーに配布しなければならない制限された量のコンテンツを含むものなど、特定の制約のコンテキスト内でこれを行うことができる。したがって、この問題を解決する最適化プログラム（１）－（２）のインスタンス化の場合、システムは（上記の（１）のように）目的関数を次のように取ることができる：

可能な制約のセットの例として（（２）のように）、次のことを考慮することができる：

ここで、値ｐ_ｉｊｋは、プロバイダーｋからコンテンツｊを受信するユーザーｉのコストを示す。値ｍ_ｉは、購入したすべてのコンテンツに対してｉが支払うことができる最大ユーザーを示し、ｎ_ｊｋは、プロバイダーｋが所有するタイプｊのコンテンツ項目の数を示す。３つの制約の最後は、プロバイダーｋによって販売されたコンテンツｊが正確に１人のユーザーに販売されなければならないことを保証する。

目的関数が（３）のように定義され、制約が（４）－（６）のように定義された（１）－（２）の形式の問題は、整数プログラムである。整数線形計画法として、問題の効率的な解決策は、場合によっては必ずしもルーチンではない場合がある。ただし、分枝限定法、シミュレーテッドアニーリングなどのメタヒューリスティックアルゴリズム、対応する連続線形計画法（解の値に対する０－１制約を無視して得られるもの）の単純な丸めなど、多くの正確または近似アルゴリズムがその解に存在する。また、必要に応じて、売り手による利益の最大化も上記の最適化問題の目的に組み込むことができることに注意されたい。もちろん、（４）－（６）に加えて、買い手が喜んで購入する販売者のタイプ（「指定販売業者」）や、待ち時間の応答時間に関する制約など、さらに制約を含めることもできる（実際には、最小化するパラメータとして目標に組み込むこともできる）。

最適化問題（１）－（２）には、単一の実数値の目的関数が含まれるが、複数の独立したエージェントユーザーが関与する状況では、複数の（スカラー）目的関数を受け入れることで、システムの有効性を高めることができる。この拡張は、（１）でベクトル値関数Ｆを許可することに対応する。すべてのｘについて、

である場合に限り、点ｘ_０はＦ＝（Ｆ_１，…，Ｆ_Ｍ）の最適（またはパレート最適）点である。したがって、例えば、（３）のようにユーザー基準項ｐ_ｉｊｋの線形結合を最小化する代わりに、パレート最適解を見つけようとすることができる。一部のアプリケーションには適している可能性がある、ベクトル値の目的関数Ｆを最適化する別の方法は、ベクトル値の目的関数をスカラー値の目的関数に変換するだけであり、Ｆ自体を、たとえばＦ_１＋．．．＋Ｆ_Ｍ（つまり、Ｆの個々のコンポーネントの合計）などの目的や別の適切な選択肢に置き換える。予測モデリングおよび機械学習方法も、問題（３）～（６）（または、より一般的には（１）～（２）のフレームワーク）のフレームワークに組み込むことができる。例えば、これらのタイプの技法を使用して、価格値ｐ_ｉｊｋを事前に見積もることができる。ニューラルネットワークやサポートベクターマシンを含む、線形または非線形回帰などの教師あり機械学習アプローチを利用して、十分な量のトレーニングデータが利用可能であれば、これらの価格を予測できる。特に、価格データは時系列の時間依存データである可能性があり、これは、特にリカレントニューラルネットワーク、ＣＮＮ、および／または変換器が、正確な価格予測のためにこの設定に非常に適している可能性があることを意味する。実際、少なくとも場合によっては、この問題を時系列予測を含むものと見なし、ランダムフォレストアルゴリズム、ベイジアンＲＮＮ、ＬＳＴＭ、変換器ベースのモデル、ＣＮＮ、または他の方法、または、これらと、以下：ニューラル常微分方程式（ＮＯＤＥ）、スティッフおよびノンスティッフユニバーサル常微分方程式（ユニバーサルＯＤＥ）、ユニバーサル確率微分方程式（ユニバーサルＳＤＥ）、ユニバーサル遅延微分方程式（ユニバーサルＤＤＥ）、ユニバーサル偏微分方程式（ユニバーサルＰＤＥ）、ユニバーサルジャンプ確率微分方程式（ユニバーサルジャンプ拡散）、ハイブリッドユニバーサル微分方程式（イベント処理を伴うユニバーサルＤＥ）の２つ以上の組み合わせを使用してアプローチすることもできる。また、ｇＣＮＮやメッセージパッシングレイヤーなどのグラフ埋め込みレイヤーを使用して、時間グラフデータから直接学習することもできる。

これは、時系列予測に特に適している。実際、観測間隔の離散化を必要とする一部のタイプのニューラルネットワークモデルとは異なり、ＮＯＤＥの連続的に定義されたダイナミクスは、任意の時間に到着するデータを自然に組み込むことができる。

図５のステップまたは説明は、本開示の任意の他の実施形態で使用できることが企図される。さらに、図５に関連して説明されたステップおよび説明は、本開示の目的をさらに進めるために、別の順序で、または並行して行うことができる。例えば、これらのステップのそれぞれは、システムまたは方法の遅延を減少させるか、または速度を増加させるために、任意の順序で、または並行して、または実質的に同時に実行され得る。さらに、図１～４に関連して説明したデバイスまたは機器のいずれかを使用して、図５のステップのうちの１以上を実行できることに留意されたい。

図６は、１以上の実施形態による、ユーザー供給の基準に一致させるための機械学習モデルを選択するためのフローチャートを示す。例えば、システムは、価格設定、マッチメイキング、およびシステムの参加者に所望の機能の自動／体系的な最適化を可能にするように設計された特定のアルゴリズムと機械学習モデル（例えば、図３～４で上述し、図６で後述するような）を使用する場合がある。参加者は、所望の基準（例：価格、商品の特徴、指定業者等）を手動で入力するか、代わりにオペレーションズリサーチと提供された人工アルゴリズムを使用して、一部またはすべてのフィールドを自動的に入力できるようにすることができる。目標は、好みの入力から、価格やその他の属性の一致と割り当てのガイドにまで及ぶ。例えば、各決定（例えば、コンテンツにタグを付ける方法、ユーザーにタグを付ける方法、ユーザーが選択した基準を解釈する方法、プロバイダーにタグを付ける方法、および／またはプロバイダーが選択した基準を解釈する方法）において、逆推奨システムは、システムが推奨を生成するために使用する機械学習モデルを（例えば、複数の機械学習モデルから）選択することができる。

ステップ６０２で、プロセス６００（例えば、図４で説明した１以上のコンポーネントを使用する）は、データの量を決定する。例えば、システムは、１以上の決定に必要な利用可能なデータの初期ステータスレポートを受信することができる。初期ステータスレポートは、データの量（トレーニングデータなど）、特定のモデルが行ったトレーニングの量、またはモデルの信頼レベル（例えば、モデルが決定を正確に決定するという信頼）を示す場合がある。追加または代替として、システムは情報フィルタリングを使用し、情報取得システムは関連するフィードバックに依存して、システムがユーザーの入力を解釈できるようにするために、ユーザーの好みの適切なスナップショットをキャプチャする。

ステップ６０４で、プロセス６００は（例えば、図４で説明した１以上のコンポーネントを使用して）、データ量に基づいて機械学習アーキテクチャを選択する。例えば、システムは、複数の機械学習モデル（例えば、図３で説明した複数の機械学習モデル）から機械学習モデルを選択することができる。機械学習モデルは、ベイズ分類器、決定木学習器、決定規則分類器、ニューラルネットワーク、および／または最近傍アルゴリズムを使用することができる。

ステップ６０６で、プロセス６００は（例えば、図４で説明した１以上のコンポーネントを使用して）、選択された機械学習モデルの特徴入力を生成する。例えば、システムは、特徴入力が入力されるモデルに基づいて正規化されたフォーマットおよび／または値を有する特徴入力を生成することができる。例えば、いくつかの実施形態では、システムは、データのより低い次元の表現が使用され得る特許表現（例えば、図３に記載されるような）を使用し得る。

ステップ６０８で、プロセス６００（例えば、図４で説明した１以上のコンポーネントを使用する）は、特徴入力を入力する。例えば、システムは特徴入力を機械学習モデルに入力することができる。例えば、システムは、ユーザーの好みとユーザープロファイルに基づいて、第１の機械学習モデルの第１の特徴入力を生成し、第１の機械学習モデルに第１の特徴入力を入力して基準を受信することによって、ユーザーの好みをユーザープロファイルと比較して、ユーザーのコンテンツ推奨の基準を決定することができ、ここで、第１の機械学習モデルは、第１のコンテンツベースのフィルタリングコンポーネントおよび第１の協調フィルタリングコンポーネントを含む。別の例では、システムは、コンテンツ属性およびコンテンツプロバイダープロファイルに基づいて、第２の機械学習モデルの第２の特徴入力を生成し、第２の機械学習モデルに第２の特徴入力を入力して、正規化されたコンテンツ属性を受信することによって、
コンテンツ属性をコンテンツプロバイダープロファイルと比較して、コンテンツプロバイダーのコンテンツ推奨のための正規化されたコンテンツ属性を決定することができ、ここで、第２の機械学習モデルは、第２のコンテンツベースのフィルタリングコンポーネントおよび第２の協調フィルタリングコンポーネントを含む。

ステップ６１０で、プロセス６００（例えば、図４で説明した１以上のコンポーネントを使用する）は、出力を受信する。例えば、システムは機械学習モデルから出力を受信することができる。たとえば、各決定（コンテンツにタグを付ける方法、ユーザーにタグを付ける方法、ユーザーが選択した基準を解釈する方法、プロバイダーにタグを付ける方法、および／またはプロバイダーが選択した基準を解釈する方法）のために、逆推奨システムは、（例えば、複数の機械学習モデルから）機械学習モデルを選択することができ、１以上の機械学習モデルからの１以上の出力に基づくことができる。

ステップ６１２で、プロセス６００は（例えば、図４で説明した１以上のコンポーネントを使用して）、出力に基づいて推奨を決定する。例えば、システムは、機械学習モデルからの出力に基づいて推奨を決定することができる。例えば、基準がコンテンツ属性に一致することを示す出力に応答して、システムは、コンテンツに対するユーザーへの表示用の推奨を生成することができる。別の例では、ユーザー入力（例えば、ユーザーは怖い映画が好きである）が標準化されたユーザー入力（例えば、ユーザーは特定レベルの怖さの怖い映画が好きである）と一致することを示す出力に応答して、システムは、標準化されたユーザー入力に基づいてユーザーに推奨を表示する。

図６のステップまたは説明は、本開示の任意の他の実施形態で使用できることが企図される。さらに、図６に関連して説明されたステップおよび説明は、本開示の目的をさらに進めるために、別の順序で、または並行して行うことができる。例えば、これらのステップのそれぞれは、システムまたは方法の遅延を減少させるか、または速度を増加させるために、任意の順序で、または並行して、または実質的に同時に実行され得る。さらに、図１～４に関連して説明したデバイスまたは機器のいずれかを使用して、図６のステップのうちの１以上を実行できることに留意されたい。

本開示の上述の実施形態は、限定ではなく例示の目的で提示されており、本開示は、以下の特許請求の範囲によってのみ限定される。さらに、任意の一実施形態で説明された特徴および制限は、本明細書の任意の他の実施形態に適用され得ること、また、一実施形態に関するフローチャートまたは例は、適切な方法で他の実施形態と組み合わせたり、異なる順序で行ったり、並行して行ったりすることができることに留意されたい。さらに、本明細書で説明するシステムおよび方法は、リアルタイムで実行することができる。上述のシステムおよび／または方法は、他のシステムおよび／または方法に適用され、またはそれらに従って使用されてもよいことにも留意されたい。

本技法は、以下の列挙された実施形態を参照してよりよく理解されるであろう：
１．ユーザー供給の基準に基づいて推奨を提供する方法であって、方法は、以下：コンテンツ推奨に対するユーザーの好みをユーザーから受信すること；ユーザーのユーザープロファイルを取得すること；ユーザーの好みをユーザープロファイルと比較して、ユーザーにコンテンツを推奨するための基準を決定すること；コンテンツプロバイダーによって提供されたコンテンツのコンテンツ属性を受信すること；基準をコンテンツ属性に一致させること；基準をコンテンツ属性に一致させることに応答して、コンテンツのユーザーへの表示用の推奨を生成することを含む。
２．いずれか１つまたは前述の実施形態の方法であって、以下：制御回路を使用して、プロバイダーからコンテンツのコンテンツ記述を受信すること；制御回路を使用して、プロバイダーのプロバイダープロファイルを取得すること；および、制御回路を使用して、コンテンツ記述をプロバイダープロファイルと比較して、コンテンツのコンテンツ属性を決定することをさらに含む、
３．いずれか１つまたは前述の実施形態の方法は、プロバイダーおよび顧客プロファイルが、サードパーティからのレビュー、または他の情報と併せてサードパーティのレビューの分析によって導出されたデータに基づく。
４．いずれか１つまたは前述の実施形態の方法であって、承認されたプロバイダーのリストを含み、ｃｏｎｔｅｎｔ属性はプロバイダーを識別し、基準をコンテンツ属性に一致させることは、プロバイダーが承認されたプロバイダーのリストにあることを決定することを含む。
５．いずれか１つまたは前述の実施形態の方法であって、基準は第１のカテゴリに含まれ、第１のカテゴリの基準は複数のユーザーについて決定される。
６．いずれか１つまたは前述の実施形態の方法であって、基準を一致させることは、複数のユーザーの第１のカテゴリにおける基準の値の合計を最小化することを含む。
７．いずれか１つまたは前述の実施形態の方法であって、複数のユーザーの第１のカテゴリにおける基準の値の合計を最小化するようにリカレントニューラルネットワーク、ＣＮＮ、および／または変換器をトレーニングするステップをさらに含む。
８．いずれか１つまたは前述の実施形態の方法であって、機械学習モデルをトレーニングして、ユーザーの好みおよびユーザープロファイルに基づいて基準を決定することをさらに含む。
９．いずれか１つまたは前述の実施形態の方法であって、ユーザープロファイルは、ユーザーの以前のアクションに基づく。
１０．データ処理装置によって実行されると、データ処理装置に実施形態１～９のいずれかのそれを含むオペレーションを実行させる命令を格納する、有形で非一時的な機械可読媒体。
１１．１以上のプロセッサと、プロセッサによって実行されると、実施形態１～９のいずれかのそれを含むオペレーションをプロセッサに実行させる命令を格納するメモリを含む、実施形態１～９のステップを実行するための手段を備えるシステム。
１２．実施形態１～９のステップを実行するための手段を含むシステム。

Claims (20)

1. 機械学習モデルを使用して、ユーザー供給の基準に基づいて推奨を提供するシステムであって、以下：
   メモリ；および
   命令を含む非一時的なコンピューター可読メモリを含み、該命令は、プロセッサに、以下：
   ユーザーからコンテンツ推奨のためのユーザーの好みを受信すること；
   ユーザーのためのユーザープロファイルを取得すること；
   ユーザーの好みおよびユーザープロファイルに基づいて、第１の機械学習モデルの第１の特徴入力を生成し、第１の機械学習モデルに第１の特徴入力を入力して基準を受信することによって、ユーザーにコンテンツを推奨する基準を決定するために、ユーザーの好みをユーザープロファイルと比較すること、ここで、第１の機械学習モデルは、第１のコンテンツベースのフィルタリングコンポーネントおよび第１の協調フィルタリングコンポーネントを含むこと；
   コンテンツプロバイダーによって提供されたコンテンツのコンテンツ属性を受信すること；
   コンテンツプロバイダーのコンテンツプロバイダープロファイルを取得すること；
   コンテンツ属性およびコンテンツプロバイダープロファイルに基づいて、第２の機械学習モデルの第２の特徴入力を生成し、第２の機械学習モデルに第２の特徴入力を入力して、正規化されたコンテンツ属性を受信することによって、コンテンツプロバイダーのコンテンツ推奨の正規化されたコンテンツ属性を決定するために、コンテンツ属性をコンテンツプロバイダープロファイルと比較すること；ここで、第２の機械学習モデルは、第２のコンテンツベースのフィルタリングコンポーネントおよび第２の協調フィルタリングコンポーネントを含むこと；
   基準を正規化されたコンテンツ属性に一致させまること；および
   基準を正規化されたコンテンツ属性に一致させることに応答して、コンテンツのためのユーザーへの推奨を表示するために生成すること
   を含むオペレーションを実行させる、前記システム。
2. ユーザー供給の基準に基づいて推奨を提供する方法であって、以下：
   制御回路を使用して、ユーザーからコンテンツ推奨のためのユーザーの好みを受信すること；
   制御回路を使用して、ユーザーのためのユーザープロファイルを取得すること；
   制御回路を使用して、ユーザーのためのコンテンツ推奨のための基準を決定するために、ユーザーの好みをユーザープロファイルと比較すること；
   制御回路を使用して、コンテンツプロバイダーによって提供されたコンテンツのためのコンテンツ属性を受信すること；
   基準をコンテンツ属性に一致させること；および
   基準をコンテンツ属性に一致させることに応答して、コンテンツのためのユーザーへの推奨の表示を生成すること
   を含む、前記方法。
3. ユーザーのためのコンテンツ推奨のための基準を決定するために、ユーザーの好みをユーザープロファイルと比較することが、以下：
   ユーザーの好みおよびユーザープロファイルに基づいて、第１の機械学習モデルのための第１の特徴入力を生成すること；および
   基準を受信するために、第１の機械学習モデルに第１の特徴入力を入力すること、ここで、第１の機械学習モデルは、第１のコンテンツベースのフィルタリングコンポーネントおよび第１の協調フィルタリングコンポーネントを含むこと；
   をさらに含む、請求項２に記載の方法。
4. 制御回路を使用して、コンテンツプロバイダーからコンテンツのコンテンツ記述を受信すること；
   制御回路を使用して、コンテンツプロバイダーのためのプロバイダープロファイルを取得すること；および
   制御回路を使用して、コンテンツのためのコンテンツ属性を決定するために、コンテンツ記述をプロバイダープロファイルと比較すること
   をさらに含む、請求項２に記載の方法。
5. プロバイダーのプロファイルが、サードパーティからのレビュー、または他の情報と組み合わせた第三者のレビューの分析によって得られたデータに基づいている、請求項４に記載の方法。
6. 基準が、承認されたプロバイダーのリストを含み、および
   コンテンツ属性が、コンテンツプロバイダーを識別し、
   基準をコンテンツ属性に一致させることが、コンテンツプロバイダーが承認されたプロバイダーのリストにあることを決定することを含む、請求項２に記載の方法。
7. 基準が、第１のカテゴリに含まれ、第１のカテゴリの基準が、複数のユーザーのために決定される、請求項２に記載の方法。
8. 基準に一致させることが、複数のユーザーのための第１のカテゴリにおける基準の値の合計を最小化することを含む、請求項７に記載の方法。
9. 複数のユーザーのための第１のカテゴリにおける基準の値の合計を最小化するために、再帰型ニューラルネットワーク、ＣＮＮ、および／または変換器、または他の適切な学習および／または最適化アルゴリズムをトレーニングすることをさらに含む、請求項７に記載の方法。
10. ユーザーの好みおよびユーザープロファイルに基づいて基準を決定するために、機械学習モデルをトレーニングすることをさらに含む、請求項２に記載の方法。
11. ユーザープロファイルが、ユーザーの以前のアクションに基づいている、請求項２に記載の方法。
12. それに埋め込まれた命令を含む、ユーザー供給の基準に基づいて推奨を提供するための非一時的なコンピューター可読媒体であって、該命令は、１以上のプロセッサに、以下：
    ユーザーからコンテンツ推奨のためのユーザーの好みを受信すること；
    ユーザーのためのユーザープロファイルを取得すること；
    ユーザーのためのコンテンツ推奨のための基準を決定するために、ユーザーの好みをユーザープロファイルと比較すること；
    コンテンツプロバイダーによって提供されたコンテンツのためのコンテンツ属性を受信すること；
    基準をコンテンツ属性に一致させること；および
    基準をコンテンツ属性に一致させることに応答して、コンテンツのためのユーザー推奨の表示を生成すること
    を含むオペレーションを実行させる、前記非一時的なコンピューター可読媒体。
13. ユーザーのためのコンテンツ推奨のための基準を決定するために、ユーザーの好みをユーザープロファイルと比較することが、以下：
    ユーザーの好みおよびユーザープロファイルに基づいて、第１の機械学習モデルのための第１の特徴入力を生成すること；および
    基準を受信するために、第１の機械学習モデルに第１の特徴入力を入力すること、ここで、第１の機械学習モデルは、第１のコンテンツベースのフィルタリングコンポーネントおよび第１の協調フィルタリングコンポーネントを含むこと；
    をさらに含む、請求項１２に記載の非一時的なコンピューター可読媒体。
14. オペレーションが、以下：
    コンテンツプロバイダーからコンテンツのコンテンツ記述を受信すること；
    プロバイダーのためのプロバイダープロファイルを取得すること；および
    コンテンツのためのコンテンツ属性を決定するために、コンテンツ記述をプロバイダープロファイルと比較すること
    をさらに含む、請求項１２に記載の非一時的なコンピューター可読媒体。
15. プロバイダーのプロファイルが、第三者からのレビュー、または他の情報と組み合わせたサードパーティのレビューの分析によって得られたデータに基づいている、請求項１４に記載の非一時的なコンピューター可読媒体。
16. 基準が、承認されたプロバイダーのリストを含み、コンテンツ属性が、コンテンツプロバイダーを識別し、ここで、基準をコンテンツ属性に一致させることは、コンテンツプロバイダーが承認されたプロバイダーのリストにあることを決定することを含む、請求項１２に記載の非一時的なコンピューター可読媒体。
17. 基準が、第１のカテゴリに含まれ、ここで、第１のカテゴリの基準は、複数のユーザーに対して決定される、請求項１２に記載の非一時的なコンピューター可読媒体。
18. 基準に一致させることが、複数のユーザーの第１のカテゴリにおける基準の値の合計を最小化することを含む、請求項１７に記載の非一時的なコンピューター可読媒体。
19. オペレーションが、複数のユーザーの第１のカテゴリにおける基準の値の合計を最小化するために、リカレントニューラルネットワークまたは他の適切な学習および／または最適化アルゴリズムをトレーニングすることをさらに含む、請求項１７に記載の非一時的なコンピューター可読媒体。
20. オペレーションが、機械学習モデルをトレーニングして、ユーザーの好みとユーザープロファイルに基づいて基準を決定することをさらに含む、請求項１２に記載の非一時的なコンピューター可読媒体。

Images