JP2023545945A - コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法 - Google Patents

コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法 Download PDF

Info

Publication number
JP2023545945A
JP2023545945A JP2023519188A JP2023519188A JP2023545945A JP 2023545945 A JP2023545945 A JP 2023545945A JP 2023519188 A JP2023519188 A JP 2023519188A JP 2023519188 A JP2023519188 A JP 2023519188A JP 2023545945 A JP2023545945 A JP 2023545945A
Authority
JP
Japan
Prior art keywords
content
user
taxonomy
tag
categorization
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023519188A
Other languages
English (en)
Other versions
JPWO2022067236A5 (ja
Inventor
ゴシャール，サンディップ
カミレッディ，シュリーハルシャ
マリャラ，ジャスワンス
ピーター，ビベク
カドラバル，ハレーシュ・エス
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/486,524 external-priority patent/US20220012268A1/en
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2023545945A publication Critical patent/JP2023545945A/ja
Publication of JPWO2022067236A5 publication Critical patent/JPWO2022067236A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/906—Clustering; Classification

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

ある実施形態に従うと、本明細書に記載のシステムおよび方法を、例えばコンテンツ管理システムとともに用いて、コンテンツをユーザ定義カテゴリにカテゴリ化／分類するための推奨を提供することができ、これにより、コンテンツマネージャのために、事前に評価／カテゴリ化されたコンテンツに基づいて新しいコンテンツを正確なカテゴリに難なく配置する機会が提供される。推奨システムまたはツールは、新たに作成／編集されたコンテンツの自動カテゴリ化／分類により、コンテンツを関連カテゴリに配置することを支援し得る。推奨ツールは、コンテンツから特徴ベクトルを生成し、事前にカテゴリ化されたコンテンツに基づいて特徴空間にクラスタを作成し、クラスタからの特徴空間距離計算により新しいコンテンツについてのカテゴリを推奨することにより、多様なドメインにわたって実装および適用することができる。

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許情報開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。
優先権主張および関連出願の相互参照：
本願は、２０２０年９月２８日に出願されて「コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法（SYSTEM AND METHOD FOR SMART CATEGORIZATION OF CONTENT IN A CONTENT MANAGEMENT SYSTEM）」と題された米国仮特許出願第６３／０８４，１７４号と、２０２１年９月２７日に出願されて「コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法（SYSTEM AND METHOD FOR SMART CATEGORIZATION OF CONTENT IN A CONTENT MANAGEMENT SYSTEM）」と題された米国特許出願第１７／４８６，５２４号とについての優先権の利益を主張するとともに、２０１８年１０月１８日に出願されて「オーサーのためのスマートなコンテンツ推奨（SMART CONTENT RECOMMENDATIONS FOR AUTHORS）」と題されたインド仮特許出願第２０１８４１０３９４９５号の優先権を主張する、２０１９年９月２４日に出願されて「コンテンツオーサーのためのスマートなコンテンツ推奨（SMART CONTENT RECOMMENDATIONS FOR CONTENT AUTHORS）」と題された米国特許出願第１６／５８１，１３８号の一部継続出願であってその優先権の利益を主張する、２０１９年１０月１８日に出願されて「コンテンツアイテム推奨をランク付けするための技術（TECHNIQUES FOR RANKING CONTENT ITEM RECOMMENDATIONS）」と題された米国特許出願第１６／６５７，３９５号に関するものであり、上述の出願の各々およびそれぞれの内容が引用により本明細書中に援用されている。
本願は、概して、オンラインコマース環境、ならびにコンテンツデータの管理および配信に関し、特に、コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化／分類に向けられている。
背景：
オンライン出版および／または送信向けのオリジナルコンテンツの作成者およびオーサーは、新しく作成されたコンテンツを生成し、編集し、格納するための多種多様なソフトウェアベースのツールおよび技術を用いる可能性がある。
コンテンツ管理システムにおいては、様々な種類のコンテンツ（例えば、文書、ブログのような構造化されたコンテンツ、記事、プレスリリース、ならびに画像および映像のようなメディアファイル）は、多くの場合、それらのコンテンツに基づいて評価／カテゴリ化される必要がある。このようなカテゴリ化／分類は、カテゴリまたはノードの階層セットにわたって行なわれる。例えば、不動産リースの契約文書は、法的文書→不動産→契約の下で評価／カテゴリ化され得る。同じ文書（またはコンテンツ）を同時に２回以上カテゴリ化／分類する可能性もある。例えば、同じ契約文書が、有効な契約→署名済みの下に存在することもある。
カテゴリは、タクソノミーと呼ばれる組織化概念の下でグループ化される。組織は、コンテンツについてのビジネス組織を反映する多くのタクソノミーを有する傾向がある。新しい文書またはコンテンツアイテムが追加される場合、または新しいタクソノミーが生じる場合、またはコンテンツ組織に有意な変化がある場合、コンテンツを正しく分類または再分類するタスクはエンドユーザ（またはコンテンツオーサー）に割当てられる。これは、コンテンツの量ならびにタクソノミーの数が増加した場合に費用が掛かりエラーが起こり易い作業となる可能性がある。
概要：
ある実施形態に従うと、本明細書に記載のシステムおよび方法を例えばコンテンツ管理システムとともに用いて、コンテンツをユーザ定義カテゴリにカテゴリ化／分類するための推奨を提供することができ、これにより、コンテンツマネージャのために、事前に評価／カテゴリ化されたコンテンツに基づいて新しいコンテンツを難なく正確なカテゴリに配置するための機会が提供される。
膨大な量のコンテンツをオンライン方式で分類することは、データに対するシングルパス制約および高速応答の要件などの課題を伴う複雑なタスクである。ある実施形態に従うと、コンテンツユーザは、階層的タクソノミーツリーなどの論理クラスタを通じて同様のコンテンツをカテゴリ化し、同様のコンテンツをタクソノミーツリーの同じノード／カテゴリに配置する。時間の経過に応じて、タクソノミーツリー内のノードおよびコンテンツ実体の数がともに増加すると、同様のコンテンツ実体がノード内に互いに並んで存在することとなるだろう。コンテンツ組織化のこの状態を前提として、既に評価／カテゴリ化されたタクソノミー内に存在するコンテンツは、新しく作成／編集されたものがどこに属し得るかを判定するためにコンピュータアルゴリズムによって使用することができる。
ある実施形態に従うと、推奨システムまたはツールは、人工知能（artificial intelligence：ＡＩ）技術を用いて、過去のデータから継続的に学習し、新しく作成／編集されたコンテンツの自動カテゴリ化／分類によりコンテンツを関連カテゴリに配置するのを支援することができる。推奨ツールは、コンテンツから特徴ベクトルを生成し、事前にカテゴリ化されたコンテンツに基づいて特徴空間内にクラスタを作成し、クラスタからの特徴空間距離計算により新しいコンテンツについてのカテゴリを推奨することによって、種々のドメインにわたって実装および適用することができる。
本開示の局面は、コンテンツリポジトリからの画像、テキストコンテンツおよび他の関連メディアコンテンツを推奨するためのスマートデジタルアシスタントとして機能するように構成された人工知能（ＡＩ）駆動ツールに関する。特定の実施形態は、オリジナルのメディアコンテンツ（たとえば、ブログ投稿、オンライン記事など）をオーサリングするのに用いられるコンテンツオーサリングインターフェイスを補足するためのグラフィカルユーザインターフェイス（graphical user interface：ＧＵＩ）を有するフロントエンドソフトウェアツールを含み得る。場合によっては、既存のコンテンツオーサリングソフトウェアツールに、付加的なＧＵＩ画面および特徴が、たとえばソフトウェアプラグインとして組込まれてもよい。スマートデジタルコンテンツ推奨ツールは、いくつかのバックエンドサービスおよびコンテンツリポジトリと通信して、たとえば、テキストおよび／または視覚入力を分析し、当該入力からキーワードまたはトピックを抽出し、入力コンテンツを分類およびタグ付けし、分類／タグ付けされたコンテンツを１つ以上のコンテンツリポジトリに格納し得る。
（たとえば、ソフトウェアツールによって直接、および／または、バックエンドサービスを呼び出すことによって間接的に）スマートデジタルコンテンツ推奨ツールのさまざまな実施形態において実行される付加的な技術は、入力されたテキストおよび／または画像を多次元ベクトル空間内でベクトルに変換することと、コンテンツリポジトリ内でいくつかの関連するコンテンツオプションを発見するために入力コンテンツを複数のリポジトリコンテンツと比較することとを含み得る。このような比較は、完全かつ網羅的な深層サーチおよび／またはより効率的なタグベースのフィルタリング済みサーチを含み得る。最後に、関連するコンテンツアイテム（たとえば、画像、音声および／または映像クリップ、関係記事へのリンク等）が取出され、レビュー用にコンテンツオーサーに提示されて、オリジナルのオーサリング済みコンテンツ内に埋込まれ得る。
本明細書の説明は主にテキストコンテンツへの適用を示しているが、様々な実施形態に従うと、このアプローチは、メタデータ抽出により、例えば、マルチメディアまたは画像／映像などの他のタイプのコンテンツに拡張させることができる。
図面の簡単な説明：
本開示に従った実施形態の性質および利点は、添付の図面と併せて本明細書の残りの部分を参照することによってさらに理解され得る。
添付の図面では、同様の構成要素および／または特徴は同じ参照レベルを有し得る。さらに、同様の構成要素同士を識別するダッシュおよび第２のラベルが当該参照ラベルの後に続くことによって同じタイプのさまざまな構成要素が区別され得る。第１の参照ラベルが本明細書において用いられる場合、第２の参照ラベルに関わらず、当該記載は、同じ第１の参照ラベルを有する同様の構成要素のいずれか１つに適用可能である。
本開示の特定の実施形態が実装され得るデータ統合クラウドプラットフォームを含む例示的なコンピュータシステムアーキテクチャを示す図である。 本開示の特定の実施形態に従った、サービスインスタンスを構成、監視および制御するのに用いられるユーザインターフェイスにおけるカスタマイズされたダッシュボードの例示的な画面を示す図である。 本開示の特定の実施形態に従ったデータ統合クラウドプラットフォームを示すアーキテクチャ図である。 本開示の特定の実施形態に従った、コンテンツ分類および推奨を実行するように構成された例示的なコンピューティング環境を示す図である。 本開示の特定の実施形態に従った、コンテンツ分類および推奨を実行するように構成された例示的なコンピューティング環境を示す別の図である。 本開示の特定の実施形態に従った、コンテンツリポジトリ内のコンテンツリソースに基づいて特徴ベクトルを生成するためのプロセスを示すフローチャートである。 本開示の特定の実施形態に従った、複数の画像特徴を識別する例示的な画像を示す図である。 本開示の特定の実施形態に従った、キーワード抽出プロセスを示すテキスト文書の例を示す図である。 本開示の特定の実施形態に従った、画像タグを生成および格納するプロセスを示す図である。 本開示の特定の実施形態に従った、画像タグを生成および格納するプロセスを示す図である。 本開示の特定の実施形態に従った、画像タグを生成および格納するプロセスを示す図である。 本開示の特定の実施形態に従った、特徴ベクトル同士を比較し、コンテンツリポジトリ内の関係するコンテンツを識別するための別のプロセスを示すフローチャートである。 本開示の特定の実施形態に従った、画像ファイルを特徴ベクトルに変換する技術を示す図である。 本開示の特定の実施形態に従った、特徴ベクトルがポピュレートされた例示的なベクトル空間を示す図である。 本開示の特定の実施形態に従った、深層特徴空間ベクトル比較を示す図である。 本開示の特定の実施形態に従った、フィルタリング済み特徴空間ベクトル比較を示す図である。 本開示の特定の実施形態に従った、フィルタリング済み特徴空間ベクトル比較を示す図である。 本開示の特定の実施形態に従った、関係する画像または記事を識別するためにテキスト入力を受取って処理するプロセスを示す図である。 本開示の特定の実施形態に従った、抽出されたキーワードと画像タグとの比較を示す例示的な図である。 本開示の特定の実施形態に従った、３Ｄ単語ベクトル空間内のキーワード分析の例を示す図である。 本開示の特定の実施形態に従った、キーワードとタグとのベクトル空間分析を示す図である。 本開示の特定の実施形態に従った、同音異義語画像タグの例を示す図である。 本開示の特定の実施形態に従った例示的な曖昧性除去プロセスを示す図である。 本開示の特定の実施形態に従った例示的な曖昧性除去プロセスを示す図である。 本開示の特定の実施形態に従った、特徴ベクトル同士を比較し、コンテンツリポジトリ内の関係するコンテンツを識別するプロセスを示す図である。 本開示の特定の実施形態に従った、特徴ベクトル同士を比較し、コンテンツリポジトリ内の関係するコンテンツを識別するプロセスを示す図である。 本開示の特定の実施形態に従った、特徴ベクトル同士を比較し、コンテンツリポジトリ内の関係するコンテンツを識別するプロセスを示す図である。 本開示の特定の実施形態に従った、特徴ベクトル同士を比較し、コンテンツリポジトリ内の関係するコンテンツを識別するプロセスを示す図である。 本開示の特定の実施形態に従った、トピック抽出プロセスを示すテキスト文書の例示的な図である。 本開示の特定の実施形態に従った、トピック抽出プロセスを示すテキスト文書の例示的な図である。 本開示の特定の実施形態に従った、入力テキストデータに基づいて関係する記事を識別するプロセスを示す図である。 本開示の特定の実施形態に従った、入力テキストデータに基づいて関係する記事を識別するプロセスを示す図である。 本開示の特定の実施形態に従った、入力テキストデータに基づいて関係する記事を識別するプロセスを示す図である。 本開示の特定の実施形態に従った、入力テキストデータに基づいて関係する記事を識別するプロセスを示す図である。 本開示の特定の実施形態に従った、入力テキストデータに基づいて関係する記事を識別するプロセスを示す図である。 本開示の特定の実施形態に従った、例示的なセマンティックテキストアナライザシステムを示す図である。 本開示の特定の実施形態に従った、コンテンツの作成中にユーザに提供される画像推奨を示す例示的なユーザインターフェイス画面を示す図である。 本開示の特定の実施形態に従った、コンテンツの作成中にユーザに提供される画像推奨を示す例示的なユーザインターフェイス画面を示す図である。 本開示に従った特定の実施形態を実装するための分散システムを示す簡略図である。 本開示の特定の実施形態に従った、システムの１つ以上のコンポーネントによって提供されるサービスがクラウドサービスとして提供され得る、システム環境における１つ以上のコンポーネントを示す簡略ブロック図である。 さまざまな実施形態が実装され得る例示的なコンピュータシステムを示す図である。 本開示の特定の実施形態に従った、ユーザまたはクライアントシステムから受取った入力コンテンツに応答してコンテンツリポジトリからのコンテンツアイテムを評価してランク付けするように構成された例示的なコンピューティング環境を示す図である。 本開示の特定の実施形態に従った、ユーザコンテンツに関連するコンテンツアイテムを識別してランク付けするためのプロセスを示すフローチャートである。 本開示の特定の実施形態に従ったコンテンツオーサリングユーザインターフェイスの例示的な画面を示す図である。 本開示の特定の実施形態に従った、コンテンツ推奨システムによって識別される一致するコンテンツアイテムのセットの例示的な表を示す図である。 本開示の特定の実施形態に従った、ランク付けスコアを含む一致するコンテンツアイテムのセットの別の例示的な表を示す図である。 本開示の特定の実施形態に従ったコンテンツオーサリングユーザインターフェイスの別の例示的な画面を示す図である。 ある実施形態に従った、コンテンツ管理システム環境の例を示す図である。 ある実施形態に従った、コンテンツデータの管理および配信のためのコンテンツ管理システムの例示的な使用を示す図である。 ある実施形態に従ったスマートコンテンツ分類フロー図である。 ある実施形態に従ったタクソノミー作成フロー図である。 ある実施形態に従ったタクソノミー修正フロー図である。 ある実施形態に従った、サンプルタクソノミーツリーをカテゴリ図とともに示す図である。 ある実施形態に従った、サンプルタクソノミーツリーをカテゴリ図とともにさらに示す図である。 ある実施形態に従った、サンプルタクソノミーツリーをカテゴリ図とともにさらに示す図である。 ある実施形態に従った、自動分類閾値図の構成を示す図である。 ある実施形態に従った、リポジトリ図におけるコンテンツの（一括での）再分類をトリガする構成を示す図である。 ある実施形態に従った、クラスタを任意の形状にすることができる従来のクラスタリングに付随する問題を示す図である。 ある実施形態に従ったマイクロクラスタリングを示す図である。 ある実施形態に従った、衣料品顧客のサンプルトピック分布を示す図である。 ある実施形態に従った、クラスタ半径の視覚化を示す図である。 ある実施形態に従った、クラスタ表現を示す図である。 ある実施形態に従った、カテゴリ化のマクロ段階を示す図である。 マクロステップを通じてより高レベルのカテゴリが選択された時のカテゴリ化を示す図である。 ある実施形態に従った、クラスタ重みが時間とともにどのように減衰し得るかを示すとともに減衰窓モデルの例を示す図である。 ある実施形態に従った、シャドウクラスタがどのように現れ得るかを示すグラフ図である。 ある実施形態に従った、シャドウクラスタがどのように現れ得るかを示すグラフ図である。 ある実施形態に従った、カテゴリ化されていないコンテンツから新しいカテゴリを作成するようにユーザに提案することを示す図である。 ある実施形態に従った、コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のための方法を示すフローチャートである。
詳細な説明：
ある実施形態に従うと、本発明は、同様の参照符号が同様の要素を示す添付の図面中の図において、限定としてではなく例として示される。本開示における「ある（an）」または「１つの（one）」または「いくつかの（some）」実施形態について言及する場合、必ずしも同じ実施形態を言及するものではなく、そのように言及する場合、少なくとも１つを意味することに留意されたい。特定の実装例について論じているが、これらの特定の実装例は例示のみを目的として提供されていることを理解されたい。当業者であれば、本発明の範囲および精神から逸脱することなく、他の構成要素および構成が使用され得ることを認識するだろう。
以下の記載では、さまざまな実装例および例を十分に理解できるようにするために、説明する目的で具体的な詳細が記載される。しかしながら、これらの具体的な詳細なしでもさまざまな実装例が実施され得ることが明らかになるだろう。たとえば、回路、システム、アルゴリズム、構造、技術、ネットワーク、プロセス、および他の構成要素は、不必要な詳細で実装例を不明瞭にしないためにブロック図の形態の構成要素として示され得る。図および記載は限定することを意図したものではない。
本開示の図に関して開示されるようないくつかの例は、フローチャート、フロー図、データフロー図、構造図、シーケンス図、またはブロック図として示されるプロセスとして説明され得る。シーケンス図またはフローチャートは、動作を連続的なプロセスとして説明し得るが、動作の多くは並行してまたは同時に実行されてもよい。加えて、動作の順序は並べ替えられてもよい。プロセスは、その動作が完了すると終了するが、図に含まれない付加的なステップを有していてもよい。プロセスは、方法、機能、手順、サブルーチン、サブプログラムなどに対応し得る。或るプロセスが或る機能に対応する場合、そのプロセスの終了は、対応する機能を呼出し機能または主機能に戻すことに対応し得る。
本開示の図を参照して説明されるプロセスなどの、本明細書に記載されるプロセスは、１つ以上の処理ユニット（たとえば、プロセッサコア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）、ハードウェア、またはそれらの組合せで実装され得る。ソフトウェアは、メモリ（たとえば、メモリデバイス上、非一時的なコンピュータ可読記憶媒体上）に格納されてもよい。いくつかの例では、本明細書のシーケンス図およびフローチャートに示されるプロセスは、本明細書で開示されるシステムのいずれかによって実装され得る。本開示における特定の一連の処理ステップは、限定することを意図していない。ステップの他のシーケンスが代替例に従って実行されてもよい。たとえば、本開示の代替例は、上記で概説したステップを異なる順序で実行することもある。さらに、図に示される個々のステップは、個々のステップに適したさまざまな順序で実行され得る複数のサブステップを含み得る。さらに、特定の用途に応じて、付加的なステップが追加または削除されてもよい。当業者であれば、多くの変形例、変更例および代替例を認識するだろう。
いくつかの例では、本開示の図における各プロセスは、１つ以上の処理ユニットによって実行され得る。処理ユニットは、シングルコアもしくはマルチコアプロセッサ、プロセッサの１つ以上のコア、またはそれらの組合わせを含む１つ以上のプロセッサを含み得る。いくつかの例では、処理ユニットは、グラフィックプロセッサ、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）などの１つ以上の専用コプロセッサを含み得る。いくつかの例では、処理ユニットのいくつかまたは全ては、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（Field programmable gate array：ＦＰＧＡ）などのカスタマイズされた回路を用いて実装され得る。
本明細書で説明する特定の実施形態は、データ統合プラットフォームクラウド（Data Integration Platform Cloud：ＤＩＰＣ）の一部として実装され得る。概して、データ統合は、異なるデータソースに存在するデータを組合わせることと、データの統一されたアクセスおよび統一されたビューをユーザに提供することとを含む。このプロセスは頻繁に行われるものであって、既存のレガシーデータベースと商業用エンティティとをマージするなど多くの状況において重要となる。有用な結果（「ビッグデータ（big data）」）を提供するためにデータを分析する能力に合わせてデータの量が増加し続けるのに応じて、エンタープライズソフトウェアシステムにおいてデータ統合の発生する頻度が高くなり始めている。たとえば、ユーザがさまざまな種類の旅行情報（たとえば、天候、ホテル、航空会社、人口統計、犯罪統計など）について問合わせることができるウェブアプリケーションについて考察する。エンタープライズアプリケーションは、これらのさまざまなデータタイプの全てを単一のスキーマで単一のデータベースに格納する必要なしに、ＤＩＰＣ内の統合されたビューおよび仮想スキーマを用いて、多くの異種データソースを組合わせることで、それらを統合されたビューでユーザに提示することができる。
ＤＩＰＣは、データ変換、統合、複製、および管理のためのクラウドベースのプラットフォームである。これは、デフォルト公差およびレジリエンシーとのデータ一貫性を維持しながら、クラウドとオンプリミスのデータソースとの間でバッチデータおよびリアルタイムデータを移動させるものである。ＤＩＰＣは、さまざまなデータソースに接続して、これらさまざまなデータソースが１つ以上のデータウェアハウスに結合されたときにこれらのさまざまなソースからデータを準備、変換、複製、管理および／または監視するのに用いられ得る。ＤＩＰＣは、任意のタイプのデータソースと協働し、任意のフォーマットで任意のタイプのデータをサポートし得る。ＤＩＰＣは、サービスとしてのプラットフォーム（Platform as a Service：ＰａａＳ）、またはサービスとしてのインフラストラクチャ（Infrastructure as a Service：ＩａａＳ）のアーキテクチャを用いて、エンタープライズのためにクラウドベースのデータ統合を提供し得る。
ＤＩＰＣは、データソース全体を新しいクラウドベースのデプロイメントに転送すること、および、クラウドプラットフォームからクラウドデータベースへの容易なアクセスを可能にすることを含め、いくつかの異なるユーティリティを提供し得る。データをリアルタイムでストリーミングして最新の新しいデータソースにするとともに、任意の数の分散データソースを同期させたまま維持することができる。負荷は、エンドユーザにとって利用可能性が極めて高いままで維持されるように、同期されたデータソース間で分割されてもよい。基礎となるデータ管理システムは、データベースクラウド、ビッグデータクラウド、サードパーティクラウドなどへのデプロイメントのためにネットワーク上を移動させるデータの量を減らすために用いることができる。ドラッグ・アンド・ドロップユーザインターフェイスを用いて、再利用可能な抽出、ロードおよび変換（Extract, Load, and Transform：ＥＬＴ）機能およびテンプレートを実行し得る。リアルタイムテスト環境は、エンドユーザにとってデータの利用可能性が極めて高いままで維持されるように複製データソース上のクラウド内で報告およびデータ分析を実行するために作成され得る。データ移行は、複製された同期済みデータソースを用いてゼロダウンタイムで実行され得る。同期済みデータソースはまた、利用可能性を維持するシームレスな障害回復のために用いることもできる。
図１は、いくつかの実施形態に従った、さまざまな既存のプラットフォームからのデータを統合するためにＤＩＰＣを利用するコンピュータシステムアーキテクチャを示す。第１のデータソース１０２は、クラウドベースのストレージリポジトリを含み得る。第２のデータソース１０４は、オンプレミスデータセンタを含み得る。第１のデータソース１０２および第２のデータソース１０４への均一なアクセスおよびビューを提供するために、ＤＩＰＣ１０８は、高性能ＥＬＴ機能１０６の既存のライブラリを用いて、第１のデータソース１０２および第２のデータソース１０４からのデータをコピーすることができる。ＤＩＰＣ１０８は、データが新しいクラウドプラットフォームに格納されると当該データを抽出、エンリッチ化および変換することもできる。ＤＩＰＣ１０８は、さらに、クラウドプラットフォーム内に常駐するかまたはクラウドプラットフォームによってアクセス可能である任意のビッグデータユーティリティへのアクセスを可能にする。いくつかの実施形態では、オリジナルのデータソース１０２および１０４が顧客へのアクセスを提供し続け得る一方で、クラウドプラットフォーム内の複製されたデータソースは、試験、監視、管理およびビッグデータ分析のために用いることができる。いくつかの実施形態では、データ管理が、ユーザインターフェイス内の既存の１セットのカスタマイズされたダッシュボード内でデータソースをプロファイリング、クレンジングおよび管理するために提供さされ得る。
図２は、ユーザインターフェイスにおけるカスタマイズされたダッシュボードのうち、ＤＩＰＣ１０８においてサービスインスタンスを構成、監視、および制御するために用いることができるダッシュボードを示す。サマリダッシュボード２０２は、ユーザがサービスインスタンスを作成することを可能にする制御２０４を提供し得る。次いで、一連のプログレッシブウェブフォームを提示することで、サービスインスタンスを作成するために用いられる情報のタイプを順々にユーザに提示することができる。第１のステップにおいて、ユーザは、電子メールアドレスおよびサービスエディションタイプ付きのサービス名および記述を提供することを要求されるだろう。ユーザはまた、サービスにおいて用いられる仮想マシンの数を指定するクラスタサイズについて質問される可能性もある。サービスエディションタイプに応じて、仮想マシンにどのアプリケーションがインストールされているかが判定される。第２のステップおよび対応するウェブフォームにおいて、ユーザは、ＤＩＰＣサーバのスキーマを格納するために実行中のクラウドデータベースデプロイメントを提供し得る。後に、同じデータベースを用いて、データエンティティを格納し、統合タスクを実行することもできる。加えて、ストレージクラウドは、バックアップユーティリティとして指定および／またはプロビジョニングされてもよい。ユーザはまた、データ統合に用いられる既存のデータソースにアクセスするために用いることができるクレデンシャルを提供し得る。第３のステップでは、プロビジョニング情報が確認され得るとともに、サービスインスタンスが作成され得る。次いで、新しいサービスインスタンスが、サマリダッシュボード２０２のサマリエリア２０６に表示され得る。そこから、ユーザは、実行中の任意のデータ統合サービスインスタンスについてのいずれかの情報にアクセスし得る。
図３は、いくつかの実施形態に従ったＤＩＰＣのアーキテクチャ図を示す。要求は、コンポーネントのJava（登録商標）Script（登録商標）Extension Toolkit（JET）セットを用いて実装され得るブラウザクライアント３０２を介して受取られてもよい。代替的には、または付加的には、当該システムは、顧客のオンプレミスデータセンタ３０６において動作するＤＩＰＣエージェント３０４を介して要求を受取ることもできる。ＤＩＰＣエージェント３０４は、オラクル社（Oracle）のGoldenGate（登録商標）サービスなどの複製サービスのためのデータ統合エージェント３０８およびエージェント３１０を含み得る。これらのエージェント３０８、３１０の各々は、通常の動作中にオンプレミスデータセンタ３０６から情報を取出して、接続サービス３１２を用いてＤＩＰＣにデータを返信し得る。
着信要求は、ＤＩＰＣを通じて要求をルーティングするためのロードバランシングまたは他のユーティリティを含み得るサインインサービス３１４に渡すことができる。サインインサービス３１４は、統合されたエンタープライズセキュリティファブリックの一部としてクラウドプラットフォームのためにセキュリティおよびアイデンティティ管理を提供するために、アイデンティティクラウドサービス３１６などのアイデンティティ管理サービスを用いてもよい。アイデンティティクラウドサービス３１６は、本実施形態で説明するクラウドデプロイメントおよびオンプレミスアプリケーションの両方についてのユーザアイデンティティを管理し得る。アイデンティティクラウドサービス３１６に加えて、ＤＩＰＣはまた、クラウドデプロイメントにおけるプラットフォームサービスのライフサイクルを管理するためのインターフェイスを提供するために、ＰａａＳサービスマネージャ（PaaS Service Manage：ＰＳＭ）ツール３１８を用いてもよい。たとえば、ＰＳＭツール３１８を用いて、クラウドプラットフォームにおけるデータ統合サービスのインスタンスを作成および管理することができる。
ＤＩＰＣは、クラウド環境においてエンタープライズアプリケーションを構築およびデプロイするために、ウェブ論理サーバ３２０上において実装され得る。ＤＩＰＣは、ＤＩＰＣを通過する情報に関するデータポリシー、設計情報、メタデータ、および監査データを格納するローカルリポジトリ３２２を含み得る。ＤＩＰＣはまた、ローカルリポジトリ３２２をポピュレートするための監視サービス３２４を含んでもよい。カタログサービス３２６は、クラウドデプロイメントにおけるＳａａＳアプリケーションおよびＰａａＳアプリケーションの多くにアクセスできるようにするために機械可読オープンＡＰＩの集合を含み得る。カタログサービス３２６は、Apache Solr（登録商標）などの分散型インデックス付けサービスを用いるサーチアプリケーション３３８にも利用可能であり得る。接続サービス３２８および仲介サービス３３０は、接続を管理し得るとともに、ＤＩＰＣを通過する情報に関する論理を変換、検証およびルーティングし得る。ＤＩＰＣ内の情報は、イベント駆動型アーキテクチャ（Event Driven Architecture：ＥＤＡ）および対応するメッセージバス３３２を用いて渡されてもよい。
ＤＩＰＣはまた、オーケストレーションサービス３３４を含み得る。オーケストレーションサービス３３４は、ＲＥＳＴエンドポイント、スクリプト、サードパーティ自動化フレームワーク等を呼び出すことによって自動化タスクを可能にし得る。次いで、これらのタスクがオーケストレーションサービス３３４によって実行されて、ＤＩＰＣ機能が提供され得る。オーケストレーションサービス３３４は、ランタイムサービスを用いて、データをインポート、変換および格納し得る。たとえば、ＥＬＴランタイムサービス３３４は、上述のＥＬＴ機能のライブラリを実行することができ、複製ランタイムサービス３４２は、さまざまなデータソースからのデータをクラウドデプロイ型ＤＩＰＣリポジトリ３１６にコピーすることができる。加えて、ＤＩＰＣは、ＥＬＴ機能および複製機能の両方のために自動的にコードを生成するコード生成サービス３３６を含み得る。
スマートコンテンツ－スマートコンテンツ推奨
上述したように、ユーザがオリジナルのメディアコンテンツ（たとえば、記事、広報、電子メール、ブログ投稿など）を作成／認可しているとき、関係する画像、音声／映像クリップ、関係する記事へのリンク、または他のコンテンツなどの関連する付加的コンテンツでオーサリング済みコンテンツを強化することがしばしば有用である。しかしながら、このような付加的コンテンツをサーチすること、さらには、ユーザのオリジナルのオーサリング済みコンテンツ内に付加的コンテンツを埋込むことは、いくつかの点で困難であるかもしれない。最初の難題は、信頼できるソースから安全／確実な付加的コンテンツを発見すること、および、ユーザ／オーサーがそのコンテンツを自身の作業に組込むのを認可されることを確実にすること、を含み得る。加えて、このような安全かつ認可された任意のコンテンツリポジトリから、ユーザ／オーサーが自身のオリジナルのオーサリング済みコンテンツ内に任意の関連コンテンツを位置特定して組込む／埋込むことは、多くの手作業を必要とする非効率的なプロセスとなる可能性がある。
したがって、本明細書で説明する特定の局面は、スマートデジタルコンテンツ推奨ツールに関する。特定の実施形態では、スマートデジタルコンテンツ推奨ツールは、コンテンツオーサーからの入力コンテンツ（たとえば、テキスト、画像）をリアルタイムで処理して分析するとともに、１つ以上の信頼できるコンテンツリポジトリから関連画像、付加的なテキストコンテンツおよび／または他の関連メディアコンテンツ（たとえば、音声クリップまたは映像クリップ、グラフィックス、ソーシャルメディア投稿など）を推奨するように構成された人工知能（ＡＩ）駆動ツールであってもよい。スマートデジタルコンテンツ推奨ツールは、いくつかのバックエンドサービスおよびコンテンツリポジトリと通信して、たとえば、テキストおよび／または視覚入力を分析し、当該入力からキーワードまたはトピックを抽出し、入力コンテンツを分類およびタグ付けし、分類／タグ付けされたコンテンツを１つ以上のコンテンツリポジトリに格納してもよい。
本明細書で説明する付加的な局面は、各々がコンテンツオーサーによって操作されるクライアント上で実行されるスマートデジタルコンテンツ推奨ツールを介して直接、および／または、さまざまなバックエンドサービスを呼び出すことによって間接的に、実行され得るものであって、（ａ）テキストおよび／または画像の形態で入力としてオリジナルコンテンツを受取ること、（ｂ）オリジナルコンテンツからキーワードおよび／またはトピックを抽出すること、（ｃ）オリジナルコンテンツについての関連付けられたキーワードおよび／またはトピックタグを判定して格納すること、（ｄ）オリジナルコンテンツ（たとえば、入力されたテキストおよび／または画像）を多次元ベクトル空間内でベクトルに変換すること、（ｅ）ユーザ／オーサーによってオーサリングされたオリジナルコンテンツ入力に関係するさまざまな潜在的に関連する付加的コンテンツを発見して識別するために、このようなベクトルを、コンテンツリポジトリ内の付加的なコンテンツのそれぞれを表わしている複数の他のコンテンツベクトルと比較すること、ならびに、最後に、（ｆ）スマートデジタルコンテンツ推奨ツールを介して識別済み付加的コンテンツを取出してオーサーに提示することを含み得る。いくつかの実施形態では、各々の付加的なコンテンツアイテム（たとえば、画像、関係記事またはウェブページへのリンク、音声ファイルまたは映像ファイル、グラフィックス、ソーシャルメディア投稿など）は、コンテンツのポジショニング、フォーマッティング、再サイジングなどを含め、ユーザがユーザのオリジナルのオーサリング済みコンテンツ内に付加的コンテンツをドラッグアンドドロップするかまたは配置することを可能にするＧＵＩベースのツールにおいて、スマートデジタルコンテンツ推奨ツールによって表示および／またはサムネイル化され得る。
ここで図４を参照すると、クライアントデバイス４１０、コンテンツ入力処理および分析サービス４２０、コンテンツ推奨エンジン４２５、コンテンツ管理システム４３５、ならびにコンテンツ取出しおよび埋込みサービス４４５を含む、スマートコンテンツ分類および推奨のためのシステム４００のさまざまなコンポーネントを示すブロック図が示されている。加えて、システム４００は、コンテンツファイル／リソースを格納する１つ以上のコンテンツリポジトリ４４０と、１つ以上のベクトル空間４３０とを含む。以下でより詳細に説明するように、ベクトル空間は、１つ以上の特徴ベクトルを格納するように構成された多次元データ構造を指すこともある。いくつかの実施形態では、推奨エンジン４２５、関連付けられたソフトウェアコンポーネントおよびサービス４２０および４４５、コンテンツ管理システム４３５、ならびに、コンテンツリポジトリ４４０（１つ以上のデータストアまたは他のデータ構造を格納し得る）は、フロントエンドクライアントデバイス４１０から離れたところにあるバックエンドサーバシステムとして実装および格納され得る。したがって、クライアントデバイス４１０とコンテンツ推奨エンジン４２５との間の対話は、インターネットベースのウェブブラウジングセッション、またはクライアント・サーバアプリケーションのセッションであってもよく、そのセッション中に、ユーザはクライアントデバイス４１０を介してオリジナルのオーサリング済みコンテンツを入力し得るとともに、コンテンツ推奨エンジン４２５からコンテンツ推奨を受取り得る。当該コンテンツ推奨の受取りは、コンテンツリポジトリ４４０から取出されるとともにクライアントデバイス４１０におけるコンテンツオーサリングユーザインターフェイスにリンクされるかまたは埋込まれる付加的コンテンツの形態で行なわれ得る。付加的には、または代替的には、コンテンツ推奨エンジン４２５および／またはコンテンツリポジトリ４４０ならびに関係するサービスは、クライアントデバイス４１０上で実行される専用のソフトウェアコンポーネントとして実装されてもよい。
この例に示されるさまざまなコンピューティングインフラストラクチャ要素（たとえば、コンテンツ推奨エンジン４２５、ソフトウェアコンポーネント／サービス４２０、４３５および４４５、ならびにコンテンツリポジトリ４４０）は、さまざまなクライアントデバイス４１０にインターネットベースのサービスおよび／またはコンテンツを提供するエンタープライズまたは組織によって作成および維持される高レベルのコンピュータアーキテクチャに対応し得る。本明細書で説明するコンテンツ（コンテンツリソースおよび／またはコンテンツファイル、コンテンツリンクなどとも称され得る）は、１つ以上のコンテンツリポジトリに格納され、コンテンツ推奨エンジン４２５によって取出されるとともに分類され、クライアントデバイス４１０においてコンテンツオーサーに提供され得る。さまざまな実施形態では、多種多様なメディアタイプまたはファイルタイプのコンテンツが、クライアントデバイス４１０においてコンテンツオーサーによってオリジナルコンテンツとして入力されてもよく、同様に、多種多様なメディアタイプまたはファイルタイプのコンテンツが、コンテンツリポジトリ４４０に格納されて、クライアントデバイス４１０においてフロントエンドユーザインターフェイスについての推奨／フロントエンドユーザインターフェイスへの埋込みが行なわれてもよい。コンテンツオーサーによってオーサリングされるかまたはコンテンツオーサーへと推奨されるこれらの多種多様なメディアタイプは、（たとえば、文字、記事またはブログをオーサリングする）テキスト、（オーサーによってまたはオーサーのために選択された）画像、音声または映像コンテンツリソース、グラフィックス、ソーシャルメディアコンテンツ（たとえば、投稿、メッセージまたはツイート）を含み得る。
いくつかの実施形態では、図４に示すシステム４００はクラウドベースの多層システムとして実装されてもよく、上層のユーザデバイス４１０は、コンテンツ処理／分析コンポーネント４２０を介してネットワークベースのリソースおよびサービスへのアクセスを要求して受取り得る。この場合、アプリケーションサーバは、ハードウェアリソースおよび／またはソフトウェアリソースを含むリソースの基礎となるセット（たとえば、クラウドベース、ＳａａＳ、ＩａａＳ、ＰａａＳなど）上にデプロイされて実行され得る。加えて、クラウドベースのシステムがいくつかの実施形態で用いられ得るが、他の例では、システム４００は、オンプレミスデータセンタ、サーバファーム、分散コンピューティングシステム、および他のさまざまな非クラウドコンピューティングアーキテクチャを用い得る。コンテンツ処理／分析コンポーネント４２０、コンテンツ推奨エンジン４２５、コンテンツ管理システム４３５、コンテンツ取出しおよび埋込みコンポーネント４４５、ならびにベクトル空間４３０の生成および格納について本明細書で説明する機能のいくつかまたは全ては、シンプルオブジェクトアクセスプロトコル（Simple Object Access protocol：ＳＯＡＰ）ウェブサービスもしくはＡＰＩを含むレプレゼンテーショナル・ステート・トランスファ（Representational State Transfer：ＲＥＳＴ）サービスおよび／もしくはウェブサービスによって、ならびに／または、ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol：ＨＴＴＰ）もしくはＨＴＴＰセキュアプロトコルを介して公開されるウェブコンテンツによって、実行され得る。こうして、付加的な詳細とともに示されるコンポーネントを不明瞭にしないために図４には示されていないが、コンピューティング環境４００は、付加的なクライアントデバイス４１０、１つ以上のコンピュータネットワーク、１つ以上のファイアウォール４３５、プロキシサーバ、および／または他の中間ネットワークデバイスを含み得ることで、クライアントデバイス４１０と、コンテンツ推奨エンジン４２５と、バックエンドコンテンツリポジトリ４４０との間の対話を容易にし得る。同様のシステム５００の別の実施形態をより詳細に図５に示す。
図５を簡潔に参照すると、コンピューティング環境５００の別の例示的な図であって、コンテンツ分類および推奨を実行するためのデータフロー／データ変換図が示されている。したがって、この例に示されるコンピューティング環境５００は、図４において上述されたコンピューティング環境４００の１つの実現可能な実装例に対応し得る。図５では、示される図のブロックのいくつかは、図４で上述した構造ハードウェアおよび／またはソフトウェアコンポーネントではなく、特定のデータ状態またはデータ変換を表わしている。このように、ブロック５０５は、ユーザインターフェイスを介して受取った入力コンテンツデータを表わし得る。ブロック５１０は、入力コンテンツ５０５に基づいてシステム４００によって判定されるキーワードのセットを表わす。上述したように、キーワード５１０は、入力処理／分析コンポーネント４２０によって、１つ以上のキーワード抽出および／またはトピックモデリングプロセスを用いて判定され得るとともに、テキスト特徴ベクトル５１５は、判定されたキーワード５１０に基づいて生成され得る。
図５に示される例を続けて参照すると、いくつかの付加的な特徴ベクトル５２０が、コンテンツリポジトリ４４０から取出され得る。この例では、付加的な特徴ベクトル５２０は、１つ以上のニューラルネットワークトレーニング済み画像モデルを実行して、判定されたキーワード５１０をトレーニング済みモデルに提供することによって、コンテンツリポジトリ４４０から選択され得る。結果として得られる特徴ベクトル５２０は、トレーニング済みモデルの出力に基づいて、ｚ％未満の特徴ベクトル確率を有するものを除外するようにさらに狭められてもよく、結果として、取出された特徴ベクトル５２５のサブセットが得られることとなる。次いで、テスト特徴ベクトル５１５と取出された特徴ベクトルのサブセット５２５との間で特徴空間比較５３０が実行され得る。いくつかの実施形態では、この例に示されるように、最も近いユークリッド距離算出を用いて、テスト特徴５１５に最も近い、取出された特徴ベクトル５２５を識別し得る。特徴空間比較５３０に基づいて、１つ以上の推奨５３０が判定され得る。各々の推奨５３０は、テスト特徴ベクトル５１５と閾値が近い、関連付けられた特徴ベクトル５２５に基づいており、各々の推奨５３０は、コンテンツリポジトリ４４０内の画像に対応している。
ＡＩベースおよび特徴ベクトル分析ベースのコンテンツ推奨およびサービスをクライアントデバイス４１０に提供するための、システム４００に示されるコンポーネントは、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合わせで実装され得る。たとえば、ウェブサービスは、データストレージデバイス、ネットワークリソース、コンピューティングリソース（たとえば、サーバ）、およびさまざまなソフトウェアコンポーネントなどの基礎となるシステムハードウェアまたはソフトウェアのコンポーネントを用いて、データセンタ４４０内で生成、展開および実行され得る。いくつかの実施形態では、ウェブサービスは、基礎となる同じコンピュータサーバ、ネットワーク、データストア上で、および／または、同じ仮想マシン内で実行されるさまざまなソフトウェアコンポーネントに対応し得る。コンテンツ推奨エンジン４２５内に設けられるウェブベースのコンテンツ、コンピューティングインフラストラクチャインスタンス、および／またはウェブサービスの中には、専用のハードウェアおよび／またはソフトウェアリソースを用い得るものもあり、他には、基礎となるリソース（たとえば、共有クラウド）を共有し得るものもある。いずれの場合においても、より高レベルの特定のサービス（たとえば、ユーザアプリケーション）、さらにはクライアントデバイスにおけるユーザは、サービスをサポートするために用いられている基礎リソースを常に認識している必要はない。
このような実装例では、さまざまなアプリケーションサーバ、データベースサーバおよび／またはクラウドストレージシステム、ならびに、ウェブキャッシュ、ネットワークコンポーネントなど（この例では図示せず）の他のインフラストラクチャコンポーネントは、コンテンツリソースの分類およびベクトル化を提供および監視するために、さらには、基礎となるストレージ／サーバ／ネットワークリソースを管理するために、さまざまなハードウェアおよび／またはソフトウェアコンポーネント（たとえば、アプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）、クラウドリソースマネージャなど）を含み得る。コンテンツリポジトリ４４０の基礎となるリソースは、たとえば、データベース、ファイルベースのストレージなどとして実装される１セットの不揮発性コンピュータメモリデバイス、１セットのネットワークハードウェアおよびソフトウェアコンポーネント（たとえば、ルータ、ファイアウォール、ゲートウェイ、ロードバランサなど）、１セットのホストサーバ、ならびに、異なるバージョンのさまざまなプラットフォーム、サーバ、ミドルウェアおよびアプリケーションソフトウェアに対応するソフトウェア画像の格納、インストール、構築、テンプレート、構成ファイルなどのさまざまなソフトウェアリソースを含み得る、コンテンツリポジトリおよび／またはクラウドストレージシステム内に格納され得る。推奨エンジン４２５のアプリケーションサーバ、ベクトル空間４３０、および関係するサービス／コンポーネントを収容するデータセンタはまた、付加的なリソース、たとえば、ハイパーバイザ、ホストオペレーティングシステム、リソースマネージャ、および他のクラウドベースのアプリケーションなどとともに、さまざまなインターネットベースのサービスをサポートするためのハードウェアおよびソフトウェアインフラストラクチャ、たとえば、サービスとしてのインフラストラクチャ（ＩａａＳ）、サービスとしてのプラットフォーム（ＰａａＳ）、および、サービスとしてのソフトウェア（ＳａａＳ）を含み得る。加えて、データセンタの基礎となるハードウェアは、たとえば、セキュリティおよびアイデンティティサービス、統合サービス、リポジトリサービス、エンタープライズ管理サービス、ウィルススキャンサービス、バックアップおよびリカバリサービス、通知サービス、ファイル転送サービスなどを含み得るいくつかの内部共有サービスをサポートするように構成され得る。
上述したように、多くの異なる種類のコンピュータアーキテクチャ（クラウドベース、ウェブベース、ホスティング、多層コンピューティング環境、分散コンピューティング環境など）を用いて、本明細書に記載されるさまざまな実施形態にしたがって、（１つ以上のコンテンツ推奨アプリケーションサーバを介して実装され得る）コンテンツ推奨エンジン５４２からクライアントデバイス４１０に対してウェブベースのコンテンツ推奨を提供し得る。しかしながら、特定の実装例では、ウェブベースのコンテンツの生成および管理のための特定の有利な特徴を提供するために、クラウドコンピューティングプラットフォームが用いられてもよい。たとえば、クラウドコンピューティングプラットフォームは、アーキテクチャが固定されておりハードウェアリソースが限定されている非クラウドベースの実装とは対照的に、多くの異なるタイプのコンピューティングインフラストラクチャインスタンスを迅速に提供、構成およびデプロイするための順応性および拡張性を提供し得る。さらに、公共のクラウドプラットフォーム、専用のクラウドプラットフォーム、および公共と専用とのハイブリッドクラウドプラットフォームが、個々のアーキテクチャの特徴および利点を活用するためにさまざまな実施形態において用いられてもよい。
加えて、この例に示されるように、システム４００は、コンテンツ管理システム４３５も含む。いくつかの実施形態では、コンテンツ管理システム４３５は、分散ストレージ処理システム、１つ以上の機械学習ベースの分類アルゴリズム（および／または非機械学習ベースのアルゴリズム）、および／またはストレージアーキテクチャを含み得る。以下でより詳細に説明するように、いくつかの実施形態では、コンテンツ管理システム４３５は、１つ以上のコンテンツリポジトリ４４０（たとえば、ネットワークベースの文書ストア、ウェブベースのコンテンツプロバイダなど）を介してコンテンツリソース（たとえば、ウェブベースの記事、画像、音声ファイル、映像ファイル、グラフィックス、ソーシャルメディアコンテンツなど）にアクセスし得る。たとえば、システム４００内では、専用のJavaScriptまたは他のソフトウェアコンポーネントをインストールして、コンテンツオブジェクトまたはネットワークベースのコンテンツを格納する１つ以上のアプリケーションサーバ、データベースサーバおよび／またはクラウドシステム上で動作させてもよい。これらのソフトウェアコンポーネントは、コンテンツリソース（たとえば、記事、画像、ウェブページ、文書など）を取出して、分析および分類のためにコンテンツ管理システム４３５に送信するように構成され得る。たとえば、システム４００の運営組織内のユーザが画像または記事などの新しいコンテンツをインポートまたは作成するたびに、ソフトウェアコンポーネントは、以下で説明するさまざまな処理および分析（たとえば、画像処理、キーワード抽出、トピック分析など）のために、コンテンツをコンテンツ管理システム４３５に戻してもよい。加えて、この例では、コンテンツ管理システム４３５は、コンテンツ推奨エンジン４２５およびコンテンツリポジトリ４４０とは別個に実装されるものとして示されているが、他の例では、コンテンツ管理システム４３５は、コンテンツ推奨エンジン４２５および／またはコンテンツリポジトリ４４０を格納するストレージデバイスのいずれかでローカルに実装されてもよく、このため、それらのデバイスから別個に送信されたコンテンツを受取る必要はないが、それぞれのシステムによって格納または提供されるコンテンツリソースを分析および分類することもある。
１つ以上のベクトル空間４３０はまた、コンテンツリポジトリ４４０内の異なるコンテンツアイテムに対応する特徴ベクトルを格納するために、かつ、（たとえば、クライアントデバイス４１０から受取った）オリジナルのオーサリング済みコンテンツについての特徴ベクトルをコンテンツリポジトリ４４０内の付加的なコンテンツアイテムの特徴ベクトルと比較するために、生成されて用いられ得る。いくつかの実施形態では、テキスト入力／記事のトピックのための第１の特徴空間４３０ａおよび画像のための第２の特徴空間４３０ｂなどの複数の多次元特徴空間４３０がシステム４００内に実装され得る。他の実施形態では、異なる種類のコンテンツメディア（たとえば、音声データ／ファイルのための特徴空間、映像データ／ファイルのための特徴空間、グラフィックスのための特徴空間、ソーシャルメディアコンテンツのための特徴空間など）のために、付加的な別個の多次元特徴空間４３０が生成されてもよい。以下で説明するように、比較アルゴリズムを用いて、特徴空間内のベクトル間の距離を判定し得る。したがって、画像特徴ベクトルの特徴空間においては、アルゴリズムを用いて、受取った入力画像に最も近い画像を識別し得るとともに、テキスト特徴ベクトルの特徴空間においては、アルゴリズムを用いて、受取った入力テキストブロックに最も近いテキスト（たとえば、記事）を識別し得る、などである。付加的または代替的には、比較アルゴリズムは、ベクトル空間のキーワード／タグを用いて、さまざまなメディアタイプ間の類似性を判定してもよい。
さまざまな実装例では、システム４００は、１つ以上のコンピューティングシステムおよび／またはネットワークを用いて実装され得る。これらのコンピューティングシステムは１つ以上のコンピュータおよび／またはサーバを含み得る。これらの１つ以上のコンピュータおよび／またはサーバは、汎用コンピュータ、専用サーバコンピュータ（たとえば、デスクトップサーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなど）、サーバファーム、サーバクラスタ、分散サーバ、または、コンピューティングハードウェアの他の任意で適切な構成および／もしくは組合わせであり得る。コンテンツ推奨エンジン４２５は、オペレーティング・システムおよび／または多様な付加的サーバアプリケーションおよび／または中間層アプリケーションを、たとえば、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）サーバ、ファイルトランスポートサービス（ＦＴＰ）サーバ、共通ゲートウェイインターフェイス（ＣＧＩ）サーバ、Ｊａｖａ（登録商標）サーバ、データベースサーバ、および他のコンピューティングシステムなどを含め、実行し得る。コンテンツリポジトリ４４０は、たとえば、Oracle、Microsoftなどから市販されているデータベースサーバを含んでもよい。システム４００内の各コンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはハードウェアとファームウェアとソフトウェアとの組合わせを用いて実装され得る。
さまざまな実装例では、システム４００内の各コンポーネントは、少なくとも１つのメモリ、１つ以上の処理ユニット（たとえば、プロセッサ）および／またはストレージを含み得る。処理ユニットは、ハードウェア（たとえば、集積回路）、コンピュータ実行可能命令、ファームウェア、または、ハードウェアと命令との組合わせにおいて適宜実装され得る。いくつかの例では、システム４００のさまざまなコンポーネントは、いくつかのサブシステムおよび／またはモジュールを含み得る。コンテンツ推奨エンジン４２５内のサブシステムおよび／またはモジュールは、ハードウェア、ハードウェア上で実行されるソフトウェア（たとえば、プロセッサによって実行可能なプログラムコードもしくは命令）、またはそれらの組合わせで実装され得る。いくつかの例では、ソフトウェアは、メモリ（たとえば、非一時的なコンピュータ可読媒体）、メモリデバイス、または他の何らかの物理メモリに格納され得るとともに、１つ以上の処理ユニット（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のグラフィックス処理ユニット（Graphics Process Unit：ＧＰＵ）など）によって実行され得る。処理ユニットのコンピュータ実行可能命令またはファームウェア実装例は、本明細書で説明するさまざまな動作、機能、方法、および／または処理を実行し得る任意の適切なプログラミング言語で書かれたコンピュータ実行可能命令または機械実行可能命令を含み得る。メモリは、処理ユニット上でロード可能かつ実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納し得る。メモリは、揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）および／または不揮発性（読取り専用メモリ（read only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。メモリは、コンピュータ可読記憶媒体などの任意のタイプの永続性記憶装置を用いて実装され得る。いくつかの例では、コンピュータ可読記憶媒体は、悪意あるコードを含む電子通信からコンピュータを保護するように構成され得る。
ここで図６を参照すると、コンテンツリポジトリ４４０内のコンテンツリソースに基づいて特徴ベクトルを生成するとともに、特徴空間４３０内に特徴ベクトルを格納するためのプロセスを示すフロー図が示される。以下で説明するように、このプロセスにおけるステップは、コンピューティング環境４００内の１つ以上のコンポーネント、たとえば、コンテンツ管理システム４３５、ならびにそこに実装されるさまざまなサブシステムおよびサブコンポーネントなどによって実行され得る。
ステップ６０２において、コンテンツリソースは、コンテンツリポジトリ４４０または他のデータストアから取出され得る。上述のように、（コンテンツまたはコンテンツアイテムとも称され得る）個々のコンテンツリソースは、テキストアイテム（たとえば、テキストファイル、記事、電子メール、ブログ投稿など）、画像、音声ファイル、映像ファイル、２Ｄまたは３Ｄグラフィックオブジェクト、ソーシャルメディアデータアイテムなどの、任意のさまざまなコンテンツタイプのデータオブジェクトに対応し得る。いくつかの実施形態では、コンテンツアイテムは、特定の信頼できる組織によって所有および運用されるプロプラエタリデータストアなど、特定のコンテンツリポジトリ４４０から取出され得る。コンテンツリポジトリ４４０は、インターネットウェブサーバまたは他の遠隔データストアなどの外部データソースであってもよいが、ローカルな、および／または個別に制御されるコンテンツリポジトリ４４０からコンテンツを検索してベクトル化するシステム４００は、システム４００の動作におけるいくつかの技術的利点を実装し得る。いくつかの技術的利点とは、リポジトリ４４０からのコンテンツが保存されており必要に応じてアクセス可能であることと、ユーザ／オーサーがリポジトリ４４０からのコンテンツを使用および再生することが認可されることとを確実にすることを含む。場合によっては、ステップ６０２（および後続のステップ６０４～６０８）における取出しは、コンテンツリポジトリ４４０に格納されている新しいコンテンツアイテムに応答して、および／または、コンテンツリポジトリ４４０内のアイテムの修正に応答してトリガされてもよい。
ステップ６０４では、ステップ６０２において取出されたコンテンツアイテムは、アイテム特徴または特性のセットを抽出するためにパーズ／分析／などされてもよい。ステップ６０４において実行されるパーズ、処理、特徴抽出および／または分析のタイプは、コンテンツアイテムのタイプに依存し得る。画像コンテンツアイテムの場合、人工知能ベースの画像分類ツールを用いて、特定の画像特徴の識別および／または画像タグの生成を実行し得る。図７の画像例に示されるように、画像分析は、複数の画像特徴（たとえば、笑顔、ウェイトレス、カウンタ、販売機、コーヒーカップ、ケーキ、手、食品、人、カフェなど）を識別し得るものであって、画像は、これらの識別された特徴の各々でタグ付けされ得る。ブログ投稿、文字、電子メール、記事などのテキストベースのコンテンツアイテムの場合、ステップ６０４において実行される分析は、図８に示されるように、キーワード抽出および処理ツール（たとえば、ステミング、同義語検索など）を含み得る。１つまたは両方のタイプの分析（すなわち、図９に示すような画像からの特徴抽出および図８に示すようなテキストコンテンツからのキーワード／トピック抽出）は、分析、機械学習アルゴリズムおよび／または人工知能（ＡＩ）、たとえば、ＡＩベースの認知画像分析サービス、または、図８のテキストコンテンツに用いられる同様のＡＩ／ＲＥＳＴ認知テキストサービスなどを用いて、ＲＥＳＴベースのサービスまたは他のウェブサービスを介して実行され得る。同様の技術が、映像ファイル、音声ファイル、グラフィックス、またはソーシャルメディア投稿などの他のタイプのコンテンツアイテムのためにステップ６０４において用いられてもよい。この場合、システム４００の専用ウェブサービスが、コンテンツアイテムのメディアタイプに応じて特定の特徴（たとえば、単語、画像／映像内のオブジェクト、顔の表現など）を抽出および分析するために用いられる。
ステップ６０６において、コンテンツアイテムから特定のコンテンツ特徴（たとえば、視覚的オブジェクト、キーワード、トピックなど）を抽出／判定した後、抽出／判定された特徴に基づいて特徴ベクトルが生成され得る。さまざまな変換技術を用いて、コンテンツアイテムに関連付けられた特徴の各セットが、共通のベクトル空間４３０に入力可能なベクトルに変換され得る。変換アルゴリズムは、予め定められたベクトル形式（たとえば、１×４０９６次元ベクトル）を出力し得る。次いで、ステップ６０８において、特徴ベクトルは、ベクトル空間４３０のうちの１つ以上（たとえば、テキストコンテンツのためのトピックベクトル空間４３０ａ、画像コンテンツのための画像ベクトル空間４３０ｂ、および／または、複数のコンテンツタイプのための結合ベクトル空間）に格納され得る。それぞれのベクトル空間および対応する空間に格納されたそれぞれの特徴ベクトルは、コンテンツ管理システム４３５、コンテンツ推奨エンジン４２５、および／または、システム４００の他のコンポーネントによって生成および維持され得る。
いくつかの実施形態では、抽出／判定されたコンテンツ特徴のサブセットはまた、コンテンツアイテムに関連付けられたタグとして保存されてもよい。画像に基づいて画像タグを生成して格納するための例示的なプロセス、および、逆に画像タグに基づいて画像を検索するための例示的なプロセスが図９～図１１に示されている。これらの例は画像コンテンツアイテムに関係しているが、同様のタグ付けプロセスおよび／またはキーワードもしくはトピック抽出がテキストコンテンツアイテム、音声／映像コンテンツアイテムなどに対して実行されてもよい。図９に示されるように、ステップ９０１において、画像が作成てもよく、および／または、たとえばコンテンツリポジトリ４４０にアップロードされてもよい。ステップ９０２では、当該画像はコンテンツリポジトリ４４０から人工知能（ＡＩ）ベースのＲＥＳＴサービスに送信され得る。この人工知能（ＡＩ）ベースのＲＥＳＴサービスは、画像を分析するとともにトピック、テーマ、特定の視覚的特徴などを抽出するように構成されている。ＡＩ ＲＥＳＴサービスは、識別された画像特徴に基づいて１つ以上の特定の画像タグを判定し得るとともに、ステップ９０３において、画像タグをコンテンツリポジトリに送り返して、ステップ９０４において、画像内に格納され得るかまたは当該画像と関連付けられ得る。図１０では、画像に基づいて画像タグを生成して格納するための、図９で説明したものと同じプロセスが示されている。加えて、図１０は、特定の実施形態におけるＡＩ ＲＥＳＴサービス内で実装され得るとともに画像タグ判定／取出しコンポーネント、Apache MxNetコンポーネント、および認知画像サービスを含むいくつかの例示的な特徴１００１を示す。コンテンツアイテムについて１つ以上のタグを判定した後、これらのタグは、コンテンツリポジトリ４４０または別個の格納場所に再び格納され得る。たとえば、図７の例示的な画像を参照すると、十数個以上の潜在的な画像特徴がこの単一の画像から抽出されてもよく、それらの全てが特徴ベクトルに組込まれてもよい。しかしながら、ＡＩ ＲＥＳＴサービスおよび／またはコンテンツリポジトリ４４０は、画像（たとえば、コーヒー、小売り）の最も普及しているテーマのうちほんの少数のテーマだけを用いて当該画像にタグ付けすることがコンテンツ一致のために最適であると判定し得る。
ここで図１１を簡潔に参照すると、複数の画像に基づいて画像タグを生成して格納するための別の例示的なプロセスが図９および図１０の記載に関連付けて示されている。図１１では、コンテンツリポジトリ４４０から一致する画像を取出すために複数の画像タグが用いられる、逆のプロセスが示されている。ステップ１１０１において、コンテンツオーサリングユーザインターフェイス４１５または他のフロントエンドインターフェイスは、インターフェイスを介して受取った入力に基づいて１つ以上のコンテンツタグを判定し得る。この例では、単一のコンテンツタグ（「ウェイトレス（waitress）」）が、受取ったユーザ入力から判定され、ステップ１１０２において、コンテンツタグが、コンテンツリポジトリ４４０に関連付けられたサーチＡＰＩに送信される。サーチＡＰＩは、コンテンツ入力処理／分析コンポーネント４２０、コンテンツ推奨エンジン４２５、ならびに／または、コンテンツ管理システム４３５を含む、コンピューティングシステムの１つ以上の別個の層内で実装され得る。ステップ１１０３において、サーチＡＰＩによって判定される一致画像を識別するデータが、インターフェイス内で統合されるように、またはユーザに提示されるように、コンテンツオーサリングユーザインターフェイス４１５に送り返されてもよい。
したがって、コンテンツリポジトリ４４０内の複数のコンテンツリソースのためのステップ６０２～６０８が完了すると、１つ以上のベクトル空間４３０に、リポジトリ４４０内のコンテンツアイテムに対応する各ベクトルがポピュレートされ得る。加えて、いくつかの実施形態では、メタデータタグの別個のセットが、コンテンツアイテムのいくつかまたは全てに対して生成され、ベクトル空間４３０においてベクトルとは別個のオブジェクトとして格納されてもよい。このようなタグは、図４に示される任意のデータストレージもしくはコンポーネント、または別個のデータストアに格納されてもよく、各タグは、リポジトリ４４０内のコンテンツアイテム、ベクトル空間４３０内のベクトル、またはこれら両方に関連付けられてもよい。
ここで図１２を参照すると、クライアントデバイス４１０を介してユーザからオリジナルのオーサリング済みコンテンツを受取り、ユーザのオーサリングセッション中にリアルタイム（またはほぼリアルタイム）でコンテンツから特徴および／またはタグを抽出し、（同様にリアルタイムまたはほぼリアルタイムで）オーサリング済みコンテンツをベクトル化し、１つ以上の利用可能なコンテンツリポジトリ４４０から関係する／関連付けられたコンテンツを識別して取出すために、オリジナルのオーサリング済みコンテンツのベクトルを１つ以上の既存のベクトル空間４３０と比較するための第２のプロセスを示す別のフローチャートが示されている。このプロセスにおけるステップはまた、コンピューティング環境４００内の１つ以上のコンポーネントによって、たとえば、クライアントデバイス４１０と協働するコンテンツ推奨エンジン４２５、入力処理／分析コンポーネント４２０および取出し／埋込みコンポーネント４４５、ならびに、そこに実装されるさまざまなサブシステムおよびサブコンポーネントによって、実行されてもよい。
ステップ１２０２において、オリジナルのオーサリング済みコンテンツを、クライアントデバイス４１０を介してユーザから受取り得る。上述のように、オリジナルのオーサリング済みコンテンツは、ユーザによってタイプされたテキスト、ユーザによって作成またはインポートされた新しい画像、ユーザによって記録またはインポートされた新しい音声または映像入力、ユーザによって作成された新しいグラフィックなどに対応し得る。このため、ステップ１２０２は、上述のステップ６０２と類似している可能性がある。しかしながら、ステップ６０２におけるコンテンツがリポジトリ４４０から取出されて事前にオーサリング／格納されたコンテンツであり得るのに対して、ステップ１２０２において、コンテンツは、ウェブベースのテキスト入力制御、画像インポータ制御、画像作成制御、音声／映像作成制御など、ユーザインターフェイスを介して受取った新たにオーサリングされたコンテンツであり得る。
ステップ１２０４では、ステップ１２０２において受取ったコンテンツ（たとえば、オリジナルのオーサリング済みコンテンツ）は、たとえば、入力処理／分析コンポーネント４２０によって処理され得る。ステップ１２０４は、パーズステップ、処理ステップ、キーワード／データ特徴抽出ステップなどに関して上述したステップ６０４と同様または同一であってもよい。たとえば、ステップ１２０２で受取ったテキスト入力（たとえば、ブログ投稿、文字、電子メール、記事など）の場合、ステップ１２０４の処理は、テキストのパーズ、キーワードの識別、ステミング、同義語分析／取出しなどを含み得る。他の例では、画像がステップ１２０２において受取られる（ユーザによってアップロードされ得る、別のシステムからインポートされ得る、および／または、コンテンツオーサユーザインターフェイス４１５を介してユーザによって手動で作成もしくは修正され得る）場合、ステップ１２０４は、上述のとおりＡＩベースの画像分類ツールを用いて、特定の画像特徴を識別するステップおよび／または画像タグを生成するステップを含み得る。ステップ１２０４におけるこれらの分析は、分析、機械学習アルゴリズム、および／または、ＡＩ、このようなＡＩベースの認知画像分析サービス、および／または、ＡＩ／ＲＥＳＴ認知テキストサービスを用いて、ＲＥＳＴベースのサービスまたは他のウェブサービスを介して実行され得る。同様の技術／サービスが、映像ファイル、音声ファイル、グラフィックス、またはソーシャルメディア投稿などの他のタイプのコンテンツアイテムのためにステップ１２０４において用いられてもよい。この場合、システム４００の専用ウェブサービスを用いて、コンテンツアイテムのメディアタイプに応じて特定の特徴（たとえば、単語、画像／映像内のオブジェクト、顔の表現など）を抽出および分析する。ステップ１２０４はまた、テキストブロック、画像、音声／映像データおよび／または他のコンテンツを、任意の識別されたコンテンツトピック、カテゴリ、または特徴に対応するタグでタグ付けするための、本明細書で説明するタグ付け処理のいずれかを含み得る。
ステップ１２０６では、ステップ１２０２で受取ったコンテンツに基づいて、利用可能なベクトル空間４３０のうちの１つ以上と互換性のある１つ以上のベクトルが生成され得る。ステップ１２０６は、上述のステップ６０６と同様または同一であってもよい。上述したように、ベクトルは、ステップ１２０４において識別されたコンテンツ（および／またはタグ）内の特定の特徴に基づいて生成され得る。ステップ１２０６におけるベクトル生成プロセスは、１つ以上のデータ変換技術を用いてもよく、これにより、元々オーサリングされていたコンテンツアイテムに関連付けられた特徴のセットを、共通のベクトル空間４３０のうちの１つと互換性のあるベクトルに変換し得る。たとえば、図１３に示す技術により、ステップ１２０２において受取った画像入力が、ステップ１２０６において予め定められたベクトルフォーマットの特徴ベクトル（たとえば、１×４０９６次元ベクトル）に変換され得る。図１３に示されるように、画像はモデルへの入力として提供されてもよく、当該モデルは、（たとえば、畳み込み、プール、および他の関数を用いて）当該画像内の特徴を抽出して学習するとともに、入力画像を表わす特徴ベクトルを出力するように構成される。たとえば、引用により本明細書中に援用されている、ニューヨーク大学（New York University）のMatthew D. ZeilerおよびRob Fergusによる論文「畳み込みネットワークの視覚化および理解（Visualizing and Understanding Convolutional Networks）」（２０１４年）に記載されるように、畳み込みニューラルネットワーク内では、ニューラルネットワークの初期層は、線形エッジのような画像から単純な特徴を検出し得るとともに、後の層では、より複雑な形状およびパターンを検出する。たとえば、畳み込みニューラルネットワークにおける第１の層および／または第２の層は単純なエッジまたはパターンを検出し得る一方で、後の層は、画像中に存在する実際の複雑なオブジェクト（カップ、花、犬など）を検出することができる。一例として、畳み込みニューラルネットワークを用いて顔の画像を受取って処理する場合、第１の層はさまざまな方向のエッジを検出してもよく、第２の層は所与の顔のさまざまな部分（たとえば、目、鼻など）を検出してもよく、第３の層は顔全体の特徴マップを所得してもよい。
ステップ１２０８において、ステップ１２０６で生成された特徴ベクトルは、上述の処理６０２～６０８中にポピュレートされた互換性のある特徴ベクトル空間４３０（または空間４３０ａ～４３０ｎ）と比較され得る。たとえば、複数の画像に対応する複数の特徴ベクトルがポピュレートされた例示的なベクトル空間を図１４に示す。この例では、各ドットはベクトル化された画像を表わし得るとともに、図１４の円（および対応するドット色）は、画像に関連付けられた３つの例示的なタグのうちの１つを示し得る。この場合の画像タグは、「コーヒー（Coffee）」、「山（Mountain）」、「鳥（Bird）」であり、これらのタグが互いに排他的でない（すなわち、画像が１つのタグ、２つのタグまたは３つのタグ全てでタグ付けされ得る）ことを理解されたい。加えて、図１４のこれらのタグおよび多次元ベクトル空間のレイアウトが例示にすぎないことを理解されたい。さまざまな実施形態においては、用いられ得るタグの数もしくはタイプ、またはベクトル空間４３０の次元の数は限定されない。
ステップ１２０８でベクトル空間比較を実行するために、コンテンツ推奨エンジン４２５は、ステップ１２０６で生成された特徴ベクトルと、ベクトル空間／空間４３０に格納された他の特徴ベクトルの各々との間のユークリッド距離を算出し得る。算出された距離に基づいて、エンジン４２５は、特徴空間距離の小さい順に特徴ベクトルをランク付けし得るので、２つの特徴ベクトル間の距離が小さければ小さいほど、ランクが高くなる。このような技術は、コンテンツ推奨エンジン４２５が、ベクトル空間４３０内の最高ランクの特徴ベクトルのセットを判定することを可能にし得る。最高ランクの特徴ベクトルは、ステップ１２０２において受取った入力に基づいてステップ１２０６において生成された特徴ベクトルと特徴／特性などが最も類似している。場合によっては、ステップ１２０８において、予め定められた数（Ｎ）の最高ランクの特徴ベクトル（たとえば、５個の最も類似した記事、１０個の最も類似した画像など）が選択されてもよく、他の場合には、特定の近さの閾値を満たす全ての特徴ベクトル（たとえば、ベクトル間の距離＜閾値（Ｔ））が選択されてもよい。
いくつかの実施形態では、ステップ１２０８におけるベクトル比較は、図１５に示される「深層特徴空間」比較であってもよい。これらの実施形態では、ステップ１２０６で生成された特徴ベクトルは、任意のタグまたは他のメタデータを考慮せずに比較されてもよい。言い換えれば、深層特徴比較では、ステップ１２０６で生成された特徴ベクトルを、ベクトル空間４３０に格納された他の全ての特徴と比較してもよい。ベクトル空間４３０において最も近いベクトルを発見するために深層特徴比較が確実にされ得る一方で、この種の比較は、ベクトル結果を返すために付加的な処理リソースおよび／または付加的な時間を必要とする可能性がある。これは、特に、数千または数百万もの特徴ベクトルを含み得る大きなベクトル空間の場合に当てはまり、当該特徴ベクトルの各々は、リポジトリ４４０に格納された別個のコンテンツオブジェクト／リソースを表わしている。たとえば、サイズ１×４０９６の２つの画像特徴ベクトル間のユークリッド距離を計算するために、約１０，０００の加算命令および乗算命令をシステム４００によって実行することが必要となる。したがって、リポジトリ内に１０，０００個の画像が存在する場合、１０，０００，０００の動作が実行されなければならない。
したがって、他の実施形態では、ステップ１２０８におけるベクトル比較は、図１６および図１７に示される「フィルタリング済み特徴空間」比較であり得る。フィルタリング済み特徴空間比較では、ベクトル空間は、まず、タグ（および／または、リソースメディアタイプ、作成日などの他のプロパティ）に基づいてフィルタリングされて、ステップ１２０６で生成された特徴ベクトルのタグと一致するタグ（および／または他のプロパティ）を有するベクトル空間４３０内の特徴ベクトルのサブセットを識別し得る。次いで、ステップ１２０６で生成された特徴ベクトルは、一致するタグ／プロパティを有するサブセット内の特徴ベクトルのみと比較され得る。したがって、フィルタリング済み特徴空間比較は、フィルタリングして除去されるが比較されない近接特徴ベクトルが存在しない可能性があるものの、深層空間比較よりも迅速かつ効率的に実行され得る。
上述したように、ステップ１２０８は、ステップ１２０６で生成された特徴ベクトルを単一のベクトル空間または複数のベクトル空間と比較することを含み得る。いくつかの実施形態では、ステップ１２０６で生成された特徴ベクトルは、対応するタイプのベクトル空間と比較され得る。たとえば、テキスト入力がステップ１２０２で受取られると、結果として得られる特徴ベクトルはトピックベクトル空間４３０ａ内のベクトルと比較され得る。さらに、画像がステップ１２０２で入力として受取られると、結果として得られる特徴ベクトルは画像ベクトル空間４３０ｂ内のベクトルと比較され得る、等である。いくつかの実施形態では、１つのタイプの入力に対応する特徴ベクトルを異なるタイプのベクトルを含むベクトル空間と比較すること（たとえば、テキストベースの入力に最も密接に関係する画像リソースを識別すること、またはその逆）が可能であり得る。たとえば、図１８は、ステップ１４０２においてテキスト入力を受取って、ステップ１４０８において、同様の画像（たとえば、画像ベクトル空間４３０ｂから最も近い）および同様の記事（たとえば、トピックベクトル空間４３０ｂから最も近い）の両方を取出すプロセスを表わす。
コンテンツリソースに関連付けられたタグを取出すことおよび／または比較することを含む実施形態の場合、１つのリソースのタグ同士が関係しているが、別のリソースの対応するタグ／キーワード／特性と厳密に一致しない場合に問題が生じる可能性がある。この潜在的な問題の例を図１９に示している。この場合、オリジナルのオーサリング済みテキストコンテンツリソースから抽出されたキーワードが、画像コンテンツリソースのセットのために格納された画像タグのセットと比較される。この例では、抽出されたキーワード（「エベレスト（Everest）」、「ベースキャンプ（Base Camp）」、「頂上（Summit）」、「山（Mountain）」または「ヒマラヤ（Himalaya）」）のいずれも、画像タグ（「登山家（Mountaineer）」、「カプチーノ（Cappuccino）」または「コンゴウインコ（Macaw）」）に対する厳密な一致ではない。いくつかの実施形態では、単語のステミング、単語定義および／または同義語検索および分析などの単語／句のパーズおよび処理技術を用いて、関係しているが一致していない用語間の一致を検出してもよい。しかしながら、これらの技術は、関係するキーワード／タグに対しても失敗する可能性がある。したがって、いくつかの実施形態では、コンテンツ処理／分析コンポーネント４２０および／またはコンテンツ推奨エンジン４２５は、この問題に対処するために単語ベクトル比較を実行し得る。図２０の例に示すように、図１９のテキスト文書から抽出したキーワードを３次元単語ベクトル空間内で分析し、それらのキーワードと画像タグの各々との間の距離を計算してもよい。図２１に示されるように、図２０において実行されるキーワード対タグのベクトル空間分析は、画像タグ「登山家（Mountaineer）」が単語ベクトル空間内で抽出キーワードに十分に近接しているため、フィルタリング済み特徴空間比較に関する画像タグ一致と見なされるべきであると判定し得る。
コンテンツリソースに関連付けられたタグを取出すおよび／または比較する実施形態において発生し得る別の潜在的な問題は、同綴異義のキーワードおよび／またはリソースタグによって引起こされる。同綴異義の単語または句（または同音異義語）は、スペルは同じであるが意味が異なっていて関係性のないものである。同音異義の画像タグの例を図２２に示す。この場合、第１の画像は、脚が長くて首が長い鳥を意味する「Crane（ツル）」という単語でタグ付けされており、第２の画像は、重い物体を移動させるために用いられる突出たアームを備えた機械を意味する「Crane（起重機）」という同じ単語でタグ付けされている。この場合、コンテンツ処理／分析コンポーネント４２０および／またはコンテンツ推奨エンジン４２５は、２つの画像タグに対して単語意味曖昧性除去プロセスを実行して、単語「crane」のどちらの意味を指しているのかを判定し得る。この例では、単語意味曖昧性除去プロセスは、２つの異なる「Crane」タグについて、図２２に示されるように、各タグに関連付けられたWordnetデータベースエントリ（または他の定義データ）を最初に検索し得る。
例示的な単語意味曖昧性除去プロセスを図２３および図２４に示す。このプロセスでは、オーサリング済み文書内の他のキーワードおよび／または当該文書内の単語「Crane」の特定のコンテキスト（たとえば、説明、スピーチの一部、時制など）を、コンテンツ処理／分析コンポーネント４２０および／またはコンテンツ推奨エンジン４２５が用いることで、オーサリング済みテキスト文書内の単語「crane」の意味で最も可能性の高いものを判定し得るとともに、これにより、「Crane」画像タグのうちどれがオーサリング済みテキスト文書に関係しているかを判定し得る。たとえば、図２３を参照すると、図示されている入力テキスト２３０１からは、いくつかの関連キーワード２３０２が抽出されている。第１の抽出キーワード（「Crane」）がコンテンツリポジトリ４４０内の画像タグと比較され得るとともに、この例では、２つの一致するタグ２３０３が、コンテンツリポジトリ４４０内の２つの「Crane」タグ付き画像２３０４ａおよび２３０４ｂに対応して識別されている。
図２４に示されるように、単語の意味の不明瞭さというこの潜在的な問題に対処するために、曖昧性除去プロセスは、引き続き、入力コンテンツ２３０１から抽出された１つ以上の追加のキーワード２３０２を、２つの一致する画像２３０４ａおよび２３０４ｂの他のコンテンツタグと比較し得る。この例では、「機械式（mechanical）」、「機械（machine）」、「昇降（lifting）」、および「建設（construction）」といった追加の抽出されたキーワードが、画像２３０４ａおよび２３０４ｂの各々に関連付けられたコンテンツタグおよび／または抽出された特徴と比較され得る。図２４に示されるように、これらの追加の比較によって「Crane」の初期のキーワード一致が明確になり得るので、コンテンツ推奨システム４２５によって、鳥類の「ツル（crane）」の画像２３０４ａが返されるのではなく、建設用の「起重機（crane）」の画像２３０４ｂが返される。
他の例では、同様の曖昧性除去プロセスが、画像類似性を用いて実行され得る。たとえば、コンテンツ処理／分析コンポーネント４２０および／またはコンテンツ推奨エンジン４２５は、どの「crane」が適切な関係画像であるかを判定するために、オーサリング済みコンテンツに関連付けられた画像（たとえば、描画またはオーサリング済み画像）と２つの異なる「Crane」画像との間の共通の画像特徴を識別し得る。これらの曖昧性除去プロセスはまた、たとえば、オーサリング済みテキスト文書から抽出されたキーワードを、画像から抽出された視覚的特徴と比較するなど、さまざまな方法で組合わされてもよい。したがって、「crane」を引用するオーサリング済みテキスト文書において、「ブーム」および「プーリ」という関係する単語は、ブームおよびプーリがその画像内で視覚的に識別できるのであれば、下段の「起重機（crane）」の画像に視覚的に一致し得る。同様に、オーサリング済みテキスト文書が「crane」を引用しており、「くちばし」および「羽根」という関係する単語を含む場合、「crane」というキーワードは、くちばしおよび羽根がその画像内で視覚的に識別できるのであれば、上段の「ツル（crane）」の画像に視覚的に一致され得る。
ここで図２５～図２８を参照すると、図１２のプロセスを実行するエンドツーエンドの例が示されており、具体的には、ユーザインターフェイス４１５を介してユーザによってオーサリングされた記事についての関連画像のセットを取出す実施形態についての例が示されている。最初に、２５０１（図２５）において、ユーザは、Demo Editor（Alditor）のユーザインターフェイスに記事についてのテキストをタイプする。２５０２において、記事のテキストからいくつかのキーワードが抽出され、２５０３において、抽出されたキーワードがＡＩ Ｒｅｓｔサービスによって、画像コンテンツリポジトリ４４０内の画像のライブラリ用に格納された画像タグと比較される。図２６および図２７は、ＡＩ Ｒｅｓｔサービスの動作に関する追加の詳細と共に、図２５の同じ例示的なプロセスを示す。図２６に示されるように、ＡＩ Ｒｅｓｔサービスは、上述の技術を用いて、１つ以上のタグ（たとえば、「登山家（mountaineer）」）をオーサリング済み記事に関係するものとして識別する。次いで、図２７に示すように、いくつかの実施形態においては、異なるソフトウェアサービスの組合わせを用いて、本ステップ、たとえば、テキスト入力からキーワードのセットを判定するのに用いられる第１の認知テキストＲＥＳＴサービスと、キーワードを画像タグにマッピングするのに用いられる第２の内部ＲＥＳＴサービスと、を実行し得る。これらのサービスの各々は、コンテンツ推奨エンジン４２５内で、および／または、外部サービスプロバイダを介して実装され得る。次いで、（図２８に示される）ステップ２５０５において、コンテンツ推奨エンジン４２５は、判定された画像タグを、画像コンテンツリポジトリ４４０に関連付けられたサーチＡＰＩに送信し得る。場合によっては、サーチＡＰＩは、クラウドベースのコンテンツハブ、たとえば、オラクル・コンテンツ・マネージメント（Oracle Content Management：ＯＣＭ）内で実装されてもよい。ステップ２５０６において、サーチＡＰＩは、タグの一致に基づいて関連画像のセットを取出し得るとともに、ステップ２５０７において、取出された画像（または縮小版の画像）が送り返されて（画面領域２８１０において）４１５におけるユーザインターフェイス内に埋込まれてもよい。
図２５～図２８に示される例は、ユーザによってオーサリングされた記事に関する関連画像のセットを取出す特定の実施形態を示すが、図１２のステップが、同様に他のタイプのコンテンツを取出すために実行され得ることを理解されたい。たとえば、同様のステップを実行して、ユーザインターフェイス４１５を介してユーザによって入力されたテキストに関係する記事（または他のテキスト文書）を取出してもよい。他の実施形態では、他のメディアタイプ（たとえば、音声ファイル、映像クリップ、グラフィックス、ソーシャルメディア投稿など）の関係するコンテンツリソースが取出されてもよい。加えて、ユーザがテキスト以外の他のタイプの入力をユーザインターフェイス（たとえば、描画またはアップロードされた画像、発話音声入力、映像入力など）にインポート／作成する場合、同様のステップを実行して、コンテンツ推奨エンジン４２５の構成および／またはユーザの好みに応じて、多種多様なタイプの関係するコンテンツリソース（たとえば、関係記事、画像、映像、音声、ソーシャルメディアなど）を取出してもよい。
たとえば、ここで図２９～図３５を参照して別の例示的実施形態を示す。ここでは、図１２のプロセスステップを実行して、ユーザインターフェイス４１５（たとえば、ユーザのブログ投稿、電子メール、記事など）を介して受取ったオリジナルのオーサリング済みテキスト入力に基づいて関係記事（または他のテキストコンテンツリソース）のセットを取出す。図２９に示されるように、ユーザは、ユーザインターフェイス４１５を介して新しい記事を認可しており、記事トピックのセットは、コンテンツ推奨エンジン４２５によって呼び出されたＡＩベースのＲＥＳＴサービスによって識別されている。図３０に示されるように、識別された記事トピックは、記事コンテンツリポジトリ４４０内の記事のセットに関して以前に識別されたトピックと比較され得る。これらの例では、図２９は一実施形態に従って示されており、図３０は別の実施形態を示す。図２９は、図３０の部分集合にすぎず、図２９を省いても問題はない。このように、記事トピックは、画像特徴／タグを判定して画像に関連付けて格納する（図６で上述した）プロセスと同様の技術を用いて、メタデータまたは他の関連付けられたデータオブジェクトとして判定されて格納され得る。同様に、記事コンテンツリポジトリ４４０は、リポジトリ４４０に格納された各記事ごとに、記事トピック、日付、キーワード、著者、出版物等を含むメタデータまたは他の関連付けられたストレージを備えてもよい。図３０に示す例では、エベレスト山の死亡者に関係する記事が、記事トピックの一致に基づいて、新しく作成されたユーザの記事に関係している可能性があるものとして識別されている。図３１～図３５は、関係する画像を発見するための図２５～図２８に示すステップと同様に、ユーザ入力記事に関係する記事を発見するためにシステム４００を用いるエンドツーエンドプロセスを示す。ステップ３１０１（図３１）において、ユーザは、ユーザインターフェイス４１５を介して新しい記事を作成する。ステップ３１０２において、記事テキストは、コンテンツ推奨エンジン４２５（たとえば、ＡＩベースのＲＥＳＴサービス）によって１つ以上のソフトウェアサービスに送信され、ステップ３１０３（図３２）において、ソフトウェアサービスは、認知テキストサービス機能を用いて、記事のテキストを分析して記事の１つ以上のトピックを判定する。ステップ３１０４において、判定された記事トピックは、コンテンツ推奨エンジン４２５に送り返され、ステップ３１０５において、推奨エンジン４２５は、記事テキストおよび識別されたトピックの両方を別個の（たとえば、クラウドベースのコンテンツハブ内の）ＡＰＩに送信し、ステップ３１０６において、記事は、将来参照するためにリポジトリ４４０に保存され、識別済みトピックに基づいてインデックス付けされてもよい。また、ステップ３１０６（図３３）において、記事の既存のリポジトリ４４０は、サーチＡＰＩを介してサーチされ、トピック一致プロセス（図３４）に基づいて、潜在的に関係しているトピックを識別し得る。最後に、ステップ３１０７（図３５）において、新しく作成された記事に関係する可能性があると識別された記事は、（たとえば、ユーザインターフェイス領域３５１０において）ユーザインターフェイス４１５内に埋込まれるように（全体的に、または単にリンクにて）送り返され得る。
図２９～図３３の上述の例に示されるように、本明細書で説明する特定の実施形態は、新たに作成されたテキスト文書のトピック、および／または、コンテンツリポジトリ４４０内に格納されたテキスト文書のトピックの識別、ならびに、トピックの近似性と一致との比較および識別を含み得る。本明細書で説明するさまざまな実施形態では、明示的な意味論分析を含むさまざまな技術が、テキストトピック評価およびトピック「近似性」技術のために用いられ得る。図２９および図３０に示されるように、場合によっては、このような技術は、大規模データソース（たとえば、ウィキペディア「Wikipedia」）を用いて、無制限の自然言語テキストの細粒度の意味論的表現を提供して、データソースから導出される自然概念の高次元空間での意味を表わし得る。たとえば、テキスト分類技術を用いて、ウィキペディアベースの概念の点から、任意のテキストの意味を明示的に表わしてもよい。意味論的表現は、トピックモデリングによって変換されるテキストスニペットの特徴ベクトルであってもよい。ウィキペディア（または別の大規模データソース）を用いることで、より大きな語彙（たとえば、「bag of words」）をシステムに含めて、複数単語の大きな領域を網羅してもよい。ウィキペディアベースの概念は、所与のテキストスニペットを分類すると同時にクラス／カテゴリとして用いられるウィキペディアページのタイトルであってもよい。テキストスニペットの場合、テキストのクラス／カテゴリとして用いられ得る最も近似するウィキペディアページタイトル（たとえば、「エベレスト山（Mount Everest）」、「スティーヴン・ホーキング（Stephen Hawking」、「自動車事故（Car Accident）」等）が戻され得る。このような技術の有効性は、自然言語テキストのフラグメント間の意味論的関係性の度合いを計算することによって自動的に評価され得る。
これらのテキスト分類／関係性評価技術では、公に利用可能な大規模な知識ソース（たとえば、ウィキペディアまたは他の百科事典）を用いる１つの利点は、定期的に変更および開発されるとともに公に利用可能なソースへと予め符号化された、高度に組織化された大量の人の知識にアクセスできることである。ウィキペディアおよび／または他のソースに基づいて機械学習技術を用いることで意味論的インタプリタを構築することもできる。この意味論的インタプリタは、自然言語テキストのフラグメントを、入力との関連性によって順序付けられた重み付けされた一連のウィキペディア概念にマッピングするものである。したがって、入力テキストは、解釈ベクトルと呼ばれる概念の重み付きベクトルとして表わされることもある。このため、テキストフラグメントの意味は、ウィキペディア概念のホストとの類似性の点から解釈される。次いで、テキストの意味論的関係性は、たとえば、コサインメトリックを用いて、上記概念によって定義される空間におけるそれらのベクトルを比較することによって計算され得る。このような意味論分析は、明確な概念が人の認知に基づくものであり得るという意味で明確であり得る。ユーザ入力がユーザインターフェイス４１５を介してプレーンテキストとして受取られ得るので、従来のテキスト分類アルゴリズムを用いて、所与のテキストフラグメントに対するそれらの関連性に従ってこれらの記事によって表わされる概念をランク付けしてもよい。したがって、オンラインの百科事典（たとえば、ウィキペディア）は、深層言語の理解または予め分類生成された共通意味の知識を必要とすることなく、直接、用いられてもよい。いくつかの実施形態では、ウィキペディア概念は各々、対応する記事において生じる単語の属性ベクトルとして表現されることもある。これらのベクトルのエントリには、たとえば、単語出現頻度に対する逆文書頻度（term frequency-inverse document frequency：ＴＦＩＤＦ）スキームを用いて重みが割当てられてもよい。これらの重みは、単語と概念との間の関連付けの強さを定量化し得る。意味論的解釈を促進するために、各単語をそれが現れる概念のリストにマッピングする転置インデックスが用いられてもよい。転置インデックスはまた、所与の単語についての重みが或る閾値未満である概念を除去することによって、単語と概念との間の重要でない関連付けを破棄するために用いられてもよい。意味論的インタプリタは、受取ったテキストフラグメントに基づいて、関連性によってウィキペディア概念をランク付けし得る重心ベースの分類器として実装されてもよい。たとえば、コンテンツ推奨エンジン内の意味論的インタプリタは、入力テキストフラグメントＴを受取って、そのフラグメントを（たとえば、ＴＦＩＤＦスキームを用いて）ベクトルとして表わし得る。意味論的インタプリタは、テキストワードを反復させ、転置インデックスから対応するエントリを取出し、それらを重み付きベクトルにマージし得る。重み付きベクトルのエントリは、テキストＴに対する対応する概念の関連性を反映してもよい。テキストフラグメントのペアの意味論的関係性を計算するために、それらのベクトルは、たとえばコサインメトリックを用いて比較されてもよい。
他の例では、テキストのカテゴリ分類のための特徴を生成するための同様の方法は、教師あり学習タスクを含み得る。この場合、トレーニング文書に現われる単語は使用されている特徴であり得る。したがって、いくつかの例では、ウィキペディア概念は「bag of words」を増強するために用いられ得る。他方では、テキストのペアの意味論的関係性を計算することは、本質的に「１回限りの（one-off）」タスクであり、したがって、「bag of words」の表現は、概念に基づく表現と置換えられてもよい。これらの技術および他の関係する技術は、あらゆる目的のために引用により本明細書に全体が援用されている、Evgeniy GabrilovichおよびShaul Markovitch（イスラエル工科大学（Israel Institute of Technology）、コンピュータサイエンス学部（Department of Computer Science Technion））による論文「ウィキペディアベースの明示的な意味論分析を用いたコンピューティング意味論的関係性（Computing Semantic Relatedness using Wikipedia-based Explicit Semantic Analysis）」、ならびに本明細書に記載される他の関連文献においてより詳細に記載されている。本論文および他の論文に記載される技術を用いることで、ウィキペディアのフィルタリング済みサブセットには、各記事ごとに、記事のタイトルである１つの概念が存在し得る。コンテンツ推奨エンジン４２５がユーザインターフェイス４１５を介してテキスト文書を受取ると、当該テキストが最初に要約され得る。これらの場合、テキスト内の一意の単語は各々、停止単語が除去され、単語がステミングされた後、記事内の単語の頻度および逆頻度に基づいて重みが与えられてもよい。各単語は、それがどのウィキペディア記事（概念）に現れるかを調べるために比較されてもよく、このため、その単語について、コンテンツ推奨エンジン４２５が概念ベクトルを生成し得る。テキスト文書内の全ての単語についての概念ベクトルを組合わせることで、テキスト文書についての重み付き概念ベクトルを形成することができる。次いで、コンテンツ推奨エンジン４２５は、各単語概念ベクトルとテキスト概念ベクトルとの間の類似性を測定し得る。さらに、ある閾値を上回る全ての単語が、文書についての「キーワード」として選択され得る。
ここで図３６を参照すると、例示的なセマンティックテキストアナライザシステム３６００が示されており、上述の特定の実施形態において意味論的なテキストのサマリー化を実行するためにアナライザシステム３６００によって用いられる技術を示している。このようなシステム３６００は、さまざまな実装例では、コンテンツ推奨エンジン４２５によってアクセスされることによって、組込まれてもよく、および／または別個であってもよい。
いくつかの実装例では、意味論的関係性を計算するための明示的な意味論分析は、所与のテキスト文書のテキストサマリーを計算するために別の用途に用いられる。より具体的には、テキストサマリーは、単語埋込みに基づいて導出される。言い換えれば、ｎグラム（n-gram）（たとえば、単語）のコンテキストは、「bag of words」に対するコサインまたは文字列上の編集距離などの典型的な類似性尺度とは対照的に、意味論的類似性を判定する目的で取込まれる。
所与のテキスト文書は、テキスト要約が望まれる記事、ウェブページまたは他のテキスト片であり得る。本明細書で説明する分類アプローチと同様に、テキストは、それが書かれている言語に限定されず、他の人が読取り可能である記号、数字、チャート、表、方程式、式などを含み得る。
明示的な意味論分析を用いたテキストサマリーアプローチは概して以下のとおりである。（１）文法単位（たとえば、文または単語）が、このような単位を識別および抽出するための任意の公知の技術を用いて所与のテキスト文書から抽出され、（２）抽出された文法単位およびテキスト文書の各々が、知識ベース概念の重み付きベクトルとして表わされ、（３）テキスト文書全体と各文法単位との間の意味論的関係性が重み付きベクトルを用いて計算され、（４）テキスト文書全体に最も意味論的に関係した文法単位の１つ以上がテキスト文書のテキストサマリーに含めるために選択される。場合によっては、知識ベース概念の重み付きベクトルの表現はトピックモデリングに対応し得る。この場合、各文または単語は最初に特徴ベクトルに変換されてもよく、その後、特徴の差／類似性が高次元ベクトル空間において算出されてもよい。単語をベクトルに変換するために、たとえば、WORD2VECまたは潜在ディリクレ配分法（Latent Dirichlet Allocation）などのさまざまな方法があり得る。
図３６は、明示的な意味論分析を用いたテキストサマリー化を示す図である。まず、知識ベース３６０２に基づいてテキストサマライザを構築する。知識ベース３６０２は、一般的であり得るかまたはドメイン固有であり得る。一般的な知識ベースの例として、百科事典記事の集まり、たとえば、ウィキペディア記事の集まりまたはテキスト記事についての他の百科事典の集まりなどが挙げられる。しかしながら、知識ベース３６０２はドメイン固有のものであってもよく、たとえば、医療、科学、工学または金融関係の記事の集まりなどの特定の技術分野に特有のテキスト記事の集まりなどであり得る。
知識ベース３６０２の各記事は、記事中に現われるｎグラム（たとえば単語）の属性ベクトルとして表わされる。属性ベクトルのエントリには重みが割付けられる。たとえば、重みは、単語出現頻度に対する逆文書頻度のスコアリングスキームを用いて使用されてもよい。或る記事についての属性ベクトルにおける重みは、当該記事のｎグラム（たとえば単語）と記事との間の関連付けの強さを概念として定量化する。
いくつかの実装例では、単語出現頻度に対する逆文書頻度のスコアリングスキームで、以下の式によって表わされるように、所与の記事文書ｄの所与のｎグラムｔについての重みを計算する。
Figure 2023545945000002
ここで、ｔｆｔ，ｄは、文書ｄにおけるｎグラムｔの頻度を表わす。ｄｆｔは、知識ベース３６０２におけるｎグラムｔの文書頻度を表わす。Ｍはトレーニングセットにおける文書の総数を表わし、Ｌｄは文書ｄの長さを数で表わし、Ｌａｖｇは、トレーニングコーパスにおける平均長さを表わし、Ｋおよびｂは自由パラメータである。いくつかの実装例では、ｋは約１．５であり、ｂは約０．７５である。
上記は、属性ベクトルの属性に重み付けするために用いられ得る、単語出現頻度に対する逆文書頻度スコアリングスキームの一例である。知識ベース３６０２内の記事に対して属性（たとえば、ｎグラム）がどれほど重要であるかを反映する他の統計的尺度が用いられてもよい。たとえば、アンカーテキストを考慮に入れるＢＭ２５Ｆなどの他のＴＦ／ＩＤＦ変形例が、たとえば、ウェブページの知識ベースまたはハイパーリンクされた文書の他のセットなどの特定のタイプの知識ベースと共に用いられてもよい。
重み付き転置インデックスビルダコンピュータ３６０４は、知識ベース３６０２の記事を表わす属性ベクトルから重み付き転置インデックス３６０６を構築する。重み付き転置インデックス３６０６は、属性ベクトルのセットにおいて表わされるそれぞれ別個のｎグラムを、ｎグラムが現れる概念（記事）の概念ベクトルにマッピングする。概念ベクトル内の各概念は、概念と、概念ベクトルが重み付き転置インデックス３６０６によってマッピングされるｎグラムとの間の関連付けの強さに従って重み付けされ得る。いくつかの実装例では、インデクサコンピュータ３６０４は、転置インデックス３６０６を用いて、所与のｎグラムについての重みが閾値未満である概念を概念ベクトルから除去することによって、ｎグラムと概念との間の重要度の低い関連付けを廃棄する。
所与のテキスト文書３６１０のテキストサマリーを生成するために、文法単位３６０８が所与のテキスト文書３６１０から抽出され、各文法単位と所与のテキスト文書３６１０との間の意味論的関係性が計算される。所与のテキスト文書３６１０に対して高度の意味論的関係性を有するいくつかの文法単位が、テキストサマリーに含めるために選択される。
テキストサマリーに含めるために選択される文法単位の数は、多種多様な要因に基づいて異なり得る。１つのアプローチは、所定の数の文法単位を選択することである。たとえば、所定の数は、システムのユーザによって構成されてもよいし、機械学習プロセスによって学習されてもよい。別のアプローチは、所定の閾値を上回る所与のテキスト文書３６１０に対する意味論的関係性の度合いを有する全ての文法単位を選択することである。所定の閾値は、システムのユーザによって構成され得るかまたは機械学習プロセスによって学習され得る。さらに別の実現可能なアプローチは、所与のテキスト文書３６１０に対する意味論的関係性の度合いが最も高い文法単位を判定し、次いで、文法単位の所与のテキスト文書３６１０に対する意味論的関係性の度合いと最も高い度合いとの差が所定の閾値を下回っている他の全ての文法単位を選択することである。度合いが最も高い文法単位と、所定の閾値未満の他のいずれかの文法単位とが、テキストサマリーに含めるために選択される。ここでも、所定の閾値は、システムのユーザによって構成され得るかまたは機械学習プロセスによって学習され得る。
いくつかの実装例では、所与のテキスト文書３６１０に対する意味論的関係性の度合いが最も高いかまたは比較的高い文法単位は、テキストサマリーに含めるために必ずしも選択されるわけではない。たとえば、所与のテキスト文書３６１０に対する意味論的関係性の度合いが第２の文法単位よりも低い第１の文法単位がテキストサマリーに含められるよう選択されてもよく、第１の文法単位がテキストサマリーに含めるために既に選択された文法単位と比べて十分に異なっていなければ、第２の文法単位がテキストサマリーに含めるために選択されなくてもよい。既存のテキストサマリーに対する文法単位の相違の程度は、たとえば、語彙によるアプローチ、確率論的アプローチ、または語彙によるアプローチと確率論的アプローチとのハイブリッドを用いることなどによって、多種多様な方法で測定することができる。テキストサマリーに含めるための文法単位を選択するために相違の尺度を用いることで、複数の同様の文法単位が同じテキストサマリーに含まれるのを防ぐことができる。
いくつかの実装例では、テキストサマリーに含めるためにいくつかの文法単位を所与のテキスト文書３６１０に対するその単位の意味論的関係性の関数および他の単位のうちの１つ以上に対するその相違性として選択するための他の技術が用いられてもよく、如何なる特定の技術にも限定されない。たとえば、所与のテキスト文書３６１０に対する意味論的関係性を有する文法単位の数が閾値を上回る場合、文法単位の数の組合わせに対する複合型文法単位の相違性が測定され得るとともに、テキストサマリーに含めるために、互いに最も異なる文法単位の数が選択され得る。結果として、テキストサマリーに含めるために選択された文法単位は、全体としてテキスト文書に対して高度に意味論的に関係しているが、互いに異なっている。これは、意味論的に高度に関係しているが同様である文法単位を含むものよりも有用なテキストサマリーである。なぜなら、同様の文法単位は、異なる文法単位よりも、文法単位が伝える情報の点で互いに冗長である可能性がより高いからである。
別の可能性は、文法単位に対する複合的な類似性／相違性の尺度を計算し、次いで、それらの複合スコアに基づいてテキストサマリーに含めるための文法単位を選択することである。たとえば、複合尺度は、意味論的関係性尺度と相違性尺度との重み付き平均であり得る。たとえば、重み付き平均として計算される考えられ得る複合尺度は以下のとおりである。
（ａ＊類似性）＋（ｂ＊相違性）
ここで、パラメータ「類似性」は、入力テキスト３６１０全体に対する文法単位の意味論的関係性を表わす。たとえば、パラメータ「類似性」は、文法単位について計算される類似性推定値３６２０であり得る。パラメータ「相違性」は、１つ以上の文法単位のセットに対する文法単位の相違性の相違性尺度を表わす。たとえば、１つ以上の文法単位のセットは、テキストサマリーに含めるために既に選択された１つ以上の文法単位のセットであり得る。パラメータａは、類似性尺度に適用される重みを重み付き平均で表わす。パラメータｂは、相違度尺度への重みの適用を重み付き平均で表わす。複合尺度は、類似性尺度と相違性尺度との互いに対するバランスを有効にとるものである。これらは、互いに等しくバランスをとることができる（たとえば、ａ＝０．５およびｂ＝０．５）。代替的には、類似性尺度にはより多くの重みが与えられる可能性もある（たとえば、ａ＝０．８およびｂ＝０．２）。
所与のテキスト文書から抽出される文法単位は、文、句、段落、単語、ｎグラム、または他の文法単位であり得る。この場合、所与のテキスト文書３６１０から抽出される文法単位３６０８が単語またはｎグラムである場合、プロセスは、テキストサマリー化とは対照的に、キーワード生成と見なされる可能性がある。
テキストサマライザ３６１２はテキスト片を受付ける。このテキスト片は、所与のテキスト文書３６１０またはその文法単位である。このテキスト片は、当該テキスト片の重み付き属性（たとえば、単語またはｎグラム）の「入力」ベクトルとして表わされる。入力ベクトルにおける各重みは、テキスト片において識別される対応する属性（たとえば、単語またはｎグラム）のためのものであり、テキスト片と対応する属性との間の関連付けの強さを表わす。たとえば、これらの重みはＴＦ－ＩＤＦスキーム等に従って算出されてもよい。
いくつかの実装例では、入力ベクトルにおける属性の重みは以下のように計算される。
Figure 2023545945000003
ここで、ｔｆｔ，ｄは、テキスト片ｄにおけるｎグラムｔの頻度である。パラメータｋ、ｂ、Ｌｄ、およびＬａｖｇは、分類トレーニングセットではなく知識ベース３６０２に関する点を除いては以前と同様である。いくつかの実装例では、ｋは約１．５であり、ｂは約０．７５である。
他の重み付けスキームも実現可能であり、実施形態が、入力ベクトルを形成するときにいかなる特定の重み付けスキームにも限定されないことに留意されたい。入力ベクトルを形成することはまた、トレーニングデータアイテムベクトルに関して上述したような単位長正規化を含み得る。
テキストサマライザ３６１２は、テキスト片に基づいて形成された入力ベクトルの非ゼロ重み付き属性を反復し、重み付き転置インデックス３６０６から属性に対応する属性ベクトルを取出し、取出された属性ベクトルをテキスト片を表わす概念の重み付きベクトルにマージする。概念のこの重み付きベクトルを以下「概念」ベクトルと称する。
入力ベクトルの属性に対応する重み付き転置インデックス３６０６から取出される属性ベクトルも各々が重みのベクトルである。しかしながら、属性ベクトルにおける重みは、知識ベース３６０２のそれぞれの概念と転置インデックス３６０６によって属性ベクトルにマッピングされた属性との関連付けの強さを定量化する。
テキストサマライザ３６１２は、テキスト片の概念ベクトルを作成する。概念ベクトルは重みのベクトルである。概念ベクトルにおける各重みは、知識ベース３６０２のそれぞれの概念とテキスト片との間の関連付けの強さを表わす。概念ベクトルにおける概念重みは、入力ベクトルにおいて非ゼロの重み付けがなされた各属性ごとの値の合計としてテキストサマライザ３６１２によって計算される。当該合計の属性についての各値は、（ａ）入力ベクトルにおける属性の重みと、（ｂ）属性についての属性ベクトルにおける概念の重みとの積として計算される。概念ベクトルにおける各々の概念重みは、テキスト片に対する概念の関連性を反映している。いくつかの実装例では、概念ベクトルが正規化される。たとえば、概念ベクトルは、（たとえば、上記のクラス長のように）単位長または概念長に関して正規化され得る。
テキストサマライザ３６１２は、入力テキスト３６１０についての概念ベクトル３６１６と、文法単位３６０８の各々についての概念ベクトル３６１４とを生成し得る。ベクトル比較器３６１８は、類似性尺度を用いて、文法単位について生成された概念ベクトル３６１４と入力テキスト３６１０について生成された概念ベクトル３６１６とを比較して、類似性推定値３６２０を生成する。いくつかの実装例では、コサイン類似性尺度が用いられる。実装例は任意の特定の類似性尺度に限定されず、２つの非ゼロベクトル間の類似性を測定することを可能にする任意の類似性尺度が用いられ得る。
類似性推定値３６２０は、或る文法単位と、当該文法単位が抽出された入力テキスト３６１０との間の意味論的関係性の度合いを定量化する。たとえば、類似性推定値３６２０は、意味論的関係性の度合いがより高くて１により近い値と、意味論的関係性の度合いがより低くて０により近い値とを含め、１と０との間の値であってもよい。
類似性推定値３６２０は、文法単位３６０８の各々について計算され得る。文法単位３６０８について生成された類似性推定値３６２０は、入力テキスト３６１０のテキストサマリーに含めるために文法単位３６０８のうちの１つ以上を選択する（かまたは、入力テキスト３６１０についてのキーワード生成のために１つ以上のキーワードを選択する）ために用いられ得る。
たとえばニュース記事、ブログ投稿、ジャーナル記事、ウェブページなどの、より長いテキストの正確なテキストサマリーを提供するためのテキストサマリー化に関して上述の技術のさまざまな応用例がある。
任意またはすべての上記実施形態においては、１つ以上のコンテンツリソース（たとえば、画像、記事等）が、ユーザインターフェイス４１５を介してユーザによって現在作成されているコンテンツに潜在的に関係していると識別された後、関係するコンテンツリソースは、コンテンツ推奨エンジン４２５に送り返され、そこで、たとえば、コンテンツ取出し／埋込みコンポーネント４４５によって、取出され、修正され、ユーザインターフェイス４１５に埋込まれてもよい。取出し／埋込みコンポーネント４４５を用いて、潜在的に関係したコンテンツリソースが、現在作成されているコンテンツに含まれるように任意に選択され得るように、ユーザインターフェイス４１５を介してユーザに提供され得る。２つの例示的なユーザインターフェイスが図３７および図３８に示されており、ここで、コンテンツの作成中に画像推奨がユーザに提供される。図３７では、ユーザインターフェイスを介してユーザによって現在オーサリングされているコンテンツのテキストに基づいて選択された画像を含むメディア推奨ペインが示されている。図３８では、視覚特徴分析は、ユーザによって選択された第１の画像（「ファイル名．ＪＰＧ」）に潜在的に関係している画像のセットを選択するために用いられてきた。同様の技術およびユーザインターフェイス画面を用いて、ユーザが、画像、記事および他のテキスト文書へのリンク、音声／映像ファイルなどを選択し、ドラッグアンドドロップするとともに、当該ユーザによって現在作成中のコンテンツに埋込むことを可能にし得る。
図３９は、上述のさまざまな例が実装され得る分散システム３９００の簡略図を示す。図示の例では、分散システム３９００は、１つ以上の通信ネットワーク３９１０を介してサーバ３９１２に結合された１つ以上のクライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８を含む。クライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８は、１つ以上のアプリケーションを実行するように構成され得る。
さまざまな実施形態では、サーバ３９１２は、コンテンツ推奨システム４００に関連付けられた１つ以上の動作を可能にする１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。たとえば、ユーザは、（たとえば、コンテンツオーサデバイス４１０に対応する）クライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８を用いて、コンテンツ推奨エンジン４２５を介して提供される１つ以上のクラウドベースのサービスにアクセスし得る。
さまざまな例では、サーバ３９１２はまた、他のサービスまたはソフトウェアアプリケーションを提供してもよく、非仮想環境および仮想環境を含み得る。いくつかの例では、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはサービスとしてのソフトウェア（ＳａａＳ）モデル下で、クライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８のユーザに提供され得る。クライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８を操作するユーザは、次に、１つ以上のクライアントアプリケーションを用いてサーバ３９１２と対話して、これらのコンポーネントによって提供されるサービスを用い得る。
図３９に示す構成では、サーバ３９１２は、サーバ３９１２によって実行される機能を実装する１つ以上のコンポーネント３９１８、３９２０、３９２２を含み得る。これらのコンポーネントは、１つ以上のプロセッサ、ハードウェアコンポーネント、またはそれらの組合わせによって実行され得るソフトウェアコンポーネントを含み得る。例示的な分散システム３９００とは異なり得る多種多様なシステム構成が実現可能であることが認識されるはずである。
クライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８は、さまざまなタイプのコンピューティングシステム、たとえば、スマートフォンおよびタブレットなどの携帯用の手持ち式デバイス、パーソナルコンピュータおよびラップトップなどの汎用コンピュータ、ワークステーションコンピュータ、頭部装着型ディスプレイなどのウェアラブルデバイス、携帯型ゲーム装置、ゲームコンソール、およびインターネット対応ゲーム装置などのゲームシステム、シンクライアント、さまざまなメッセージングデバイス、センサおよび他の感知デバイスなどを含み得る。これらのコンピューティングデバイスは、各種モバイルオペレーティングシステム（たとえばＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｍｏｂｉｌｅ（登録商標）、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、ＢｌａｃｋＢｅｒｒｙ（登録商標）、Ｐａｌｍ ＯＳ（登録商標））を含む、さまざまな種類およびバージョンのソフトウェアアプリケーションおよびオペレーティングシステム（たとえばＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、ＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステム、Ｌｉｎｕｘ（登録商標）またはＬｉｎｕｘ系オペレーティングシステム）を実行し得る。クライアントデバイスは、さまざまなインターネット関連アプリ、通信アプリケーション（たとえば、電子メールアプリケーション、ショートメッセージサービス（short message service：ＳＭＳ）アプリケーション）などの多種多様なアプリケーションを実行することができるとともに、さまざまな通信プロトコルを用い得る。クライアントデバイスは、当該クライアントデバイスのユーザがクライアントデバイスと対話することを可能にするインターフェイスを提供し得る。クライアントデバイスはまた、このインターフェイスを介してユーザに情報を出力してもよい。図３９は４つのクライアントコンピューティングデバイスだけを示しているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。
分散システム３９００内のネットワーク３９１０は、利用可能な多様なプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当該技術の当業者には周知のいずれかの種類のネットワークであればよく、上記プロトコルは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋ（登録商標）などを含むがこれらに限定されない。単に例として、ネットワーク３９１０は、ローカルエリアネットワーク（ＬＡＮ）、Ｅｔｈｅｒｎｅｔ（登録商標）に基づくネットワーク、トークンリング、ワイドエリアネットワーク、インターネット、仮想ネットワーク、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば電気電子学会（ＩＥＥＥ）８０２．１１プロトコルスイートのいずれかの下で動作するネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）および／もしくは他の任意の無線プロトコル）、ならびに／または、これらおよび／もしくは他のネットワークの任意の組合わせであってもよい。
サーバ３９１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の任意の適切な構成および／または組合わせで構成されてもよい。サーバ３９１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャ、たとえば、サーバに対して仮想記憶装置を維持するように仮想化できる論理記憶装置の１つ以上のフレキシブルプールなど、を含み得る。各種例において、サーバ３９１２は、上述の動作を実行する１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。
サーバ３９１２は、上述のいずれかを含むオペレーティングシステム、および、市場で入手可能なサーバオペレーティングシステムを実行し得る。また、サーバ３９１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（共通ゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含むさまざまな付加的なサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行し得る。データベースサーバの例は、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、ＩＢＭ（登録商標）（International Business Machines）などから市場で入手可能なものを含むが、それらに限定されるものではない。
いくつかの実装例において、サーバ３９１２は、クライアントコンピューティングデバイス３９０２，３９０４，３９０６および３９０８のユーザから受取ったデータフィードおよび／またはイベントアップデートを解析および整理統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリングなどに関係するリアルタイムのイベントを含み得る、１つ以上の第三者情報源および連続データストリームから受取られる、フィード、またはリアルタイムのアップデートを含み得るが、これらに限定されない。サーバ３９１２は、データフィードおよび／またはリアルタイムのイベントをクライアントコンピューティングデバイス３９０２，３９０４，３９０６および３９０８の１つ以上の表示デバイスを介して表示するための１つ以上のアプリケーションも含み得る。
分散システム３９００はまた、１つ以上のデータリポジトリ３９１４、３９１６を含み得る。これらのデータリポジトリは、上述のさまざまな例によって説明される情報などのさまざまなタイプの情報を格納するためのメカニズムを提供し得る。データリポジトリ３９１４、３９１６はさまざまな場所に常駐し得る。たとえば、サーバ３９１２が使用するデータリポジトリは、サーバ３９１２のローカルにあってもよく、またはサーバ３９１２から遠隔の位置にあってもよく、ネットワークベースの接続または専用接続を介してサーバ３９１２と通信する。データリポジトリ３９１４、３９１６は異なる種類であってもよい。いくつかの例において、サーバ３９１２が使用するデータリポジトリは、データベース、たとえば、Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）および他の製造業者が提供するデータベースなどのリレーショナルデータベースであってもよい。これらのデータベースのうちの１つ以上を、ＳＱＬフォーマットのコマンドに応じて、データの格納、アップデート、およびデータベースとの間での取出しを可能にするように適合されてもよい。
いくつかの例では、データリポジトリ３９１４、３９１６のうちの１つ以上はまた、アプリケーションデータを格納するためにアプリケーションによって用いられてもよい。アプリケーションが使用するデータリポジトリは、たとえば、キー値ストアリポジトリ、オブジェクトストアリポジトリ、またはファイルシステムがサポートする汎用ストレージリポジトリなどのさまざまな種類のものであってもよい。
いくつかの例では、クラウド環境は、上述したような１つ以上のサービスを提供し得る。図４０は、これらのサービスおよび他のサービスをクラウドサービスとして提供することができるシステム環境４０００の１つ以上のコンポーネントの簡略ブロック図である。図４０に示される例では、クラウドインフラストラクチャシステム４００２は、１つ以上のクライアントコンピューティングデバイス４００４、４００６および４００８を用いてユーザが要求し得る１つ以上のクラウドサービスを提供し得る。クラウドインフラストラクチャシステム４００２は、図３９のサーバ３９１２について上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを含み得る。図４０のクラウドインフラストラクチャシステム４００２内のコンピュータは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または他の任意の適切な構成および／または組合わせとして編成され得る。
ネットワーク４０１０は、クライアント４００４、４００６、４００８とクラウドインフラストラクチャシステム４００２との間のデータの通信およびやり取りを容易にし得る。ネットワーク４０１０は１つ以上のネットワークを含み得る。ネットワークは、同じタイプであっても異なるタイプであってもよい。ネットワーク４０１０は、通信を容易にするために、有線プロトコルおよび／または無線プロトコルを含む１つ以上の通信プロトコルをサポートし得る。
図４０に示す例は、クラウドインフラストラクチャシステムの一例にすぎず、限定することを意図していない。他の例では、クラウドインフラストラクチャシステム４００２は、図４０に示されたものよりも多いかまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組合わせてもよく、または異なる構成または配置のコンポーネントを有してもよいことが認識されるはずである。たとえば、図４０は３つのクライアントコンピューティングデバイスを示すが、他の例では、サポートされ得るクライアントコンピューティングデバイスの数は任意である。
クラウドサービスという用語は一般に、サービスプロバイダのシステム（たとえばクラウドインフラストラクチャシステム４００２）により、インターネット等の通信ネットワークを介してオンデマンドでユーザが利用できるようにされるサービスを意味するために用いられている。典型的には、公共のクラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。クラウドサービスプロバイダのシステムは、クラウドサービスプロバイダによって管理される。よって、顧客は、別途ライセンス、サポート、またはハードウェアおよびソフトウェアリソースをサービスのために購入しなくても、クラウドサービスプロバイダが提供するクラウドサービスを利用することができる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストし得るとともに、ユーザは、アプリケーションを実行するためにインフラストラクチャリソースを購入しなくても、インターネットを介しオンデマンドかつセルフサービスでアプリケーションをオーダーして使用することができる。クラウドサービスは、アプリケーション、リソースおよびサービスに対する容易でスケーラブルなアクセスを提供するように設計されている。いくつかのプロバイダがクラウドサービスを提供する。たとえば、ミドルウェアサービス、データベースサービス、Ｊａｖａクラウドサービスその他などのいくつかのクラウドサービスが、Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）から提供されている。
さまざまな例において、クラウドインフラストラクチャシステム４００２は、ハイブリッドサービスモデルを含む、サービスとしてのソフトウェア（ＳａａＳ）モデル、サービスとしてのプラットフォーム（ＰａａＳ）モデル、サービスとしてのインフラストラクチャ（ＩａａＳ）モデルなどのさまざまなモデルを用いて、１つ以上のクラウドサービスを提供し得る。クラウドインフラストラクチャシステム４００２は、各種クラウドサービスのプロビジョンを可能にする、アプリケーション、ミドルウェア、データベース、およびその他のリソースの一式を含み得る。
ＳａａＳモデルは、アプリケーションまたはソフトウェアを、インターネットのような通信ネットワークを通して、顧客が基本となるアプリケーションのためのハードウェアまたはソフトウェアを購入しなくても、サービスとして顧客に配信することを可能にする。たとえば、ＳａａＳモデルを用いることにより、クラウドインフラストラクチャシステム４００２がホストするオンデマンドアプリケーションに顧客がアクセスできるようにしてもよい。Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）が提供するＳａａＳサービスの例は、人的資源／資本管理のための各種サービス、顧客関係管理（ＣＲＭ）、エンタープライズ・リソース・プランニング（ＥＲＰ）、サプライチェーン・マネジメント（ＳＣＭ）、エンタープライズ・パフォーマンス・マネジメント（ＥＰＭ）、解析サービス、ソーシャルアプリケーションその他を含むがこれらに限定されるものではない。
ＩａａＳモデルは一般に、インフラストラクチャリソース（たとえばサーバ、ストレージ、ハードウェアおよびネットワーキングリソース）を、クラウドサービスとして顧客に提供することにより柔軟な計算およびストレージ機能を提供するために使用される。各種ＩａａＳサービスがＯｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）から提供されている。
ＰａａＳモデルは一般に、顧客が、このようなリソースを調達、構築、または管理しなくても、アプリケーションおよびサービスを、開発、実行および管理することを可能にするプラットフォームおよび環境リソースをサービスとして提供するために使用される。Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）が提供するＰａａＳサービスの例は、Oracle Java Cloud Service（ＪＣＳ）、Oracle Database Cloud Service（ＤＢＣＳ）、データ管理クラウドサービス、各種アプリケーション開発ソリューションサービスその他を含むがこれらに限定されるものではない。
いくつかの例では、クラウドインフラストラクチャシステム４００２内のリソースは、複数のユーザによって共有され、要求に応じて動的に再割当てされ得る。加えて、リソースは、異なる時間帯のユーザに割当てられてもよい。たとえば、クラウドインフラストラクチャシステム４００２は、第１の時間帯にあるユーザの第１のセットが、指定された時間数にわたってクラウドインフラストラクチャシステムのリソースを利用することを可能にし、次いで、異なる時間帯にあるユーザの別のセットに同じリソースを再割当てすることを可能にし、これにより、リソースを最大限利用し得る。
クラウドインフラストラクチャシステム４００２は、異なるデプロイメントモデルを介してクラウドサービスを提供し得る。公共のクラウドモデルにおいて、クラウドインフラストラクチャシステム４００２は、第三者クラウドサービスプロバイダによって所有されていてもよく、クラウドサービスは一般の任意の顧客に提供される。この場合、顧客は個人であっても企業であってもよい。その他いくつかの実施形態において、プライベートクラウドモデルでは、クラウドインフラストラクチャシステム４００２を或る組織内で（たとえば企業組織内で）機能させてもよく、サービスはこの組織内の顧客に提供される。たとえば、これらの顧客は、企業のさまざまな部署、たとえば人事部、給与部などであってもよく、企業内の個人であってもよい。その他の特定の実施形態において、コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム４００２および提供されるサービスは、関係するコミュニティ内のいくつかの組織で共有されてもよい。上記モデルの混成モデルなどの他の各種モデルが用いられてもよい。
クライアントコンピューティングデバイス４００４、４００６、４００８は、図３９のクライアントコンピューティングデバイス３９０２、３９０４、３９０６、３９０８について上述したものと同様のデバイスであってもよい。図４０のクライアントコンピューティングデバイス４００４、４００６、４００８は、クラウドインフラストラクチャシステム４００２によって提供されるサービスを用いるためにクライアントコンピューティングデバイスのユーザがクラウドインフラストラクチャシステム４００２と対話するのに用いられ得るウェブブラウザ、プロプラエタリクライアントアプリケーション（たとえば、Oracle Forms）、または他の何らかのアプリケーションなどのクライアントアプリケーションを操作するように構成され得る。
さまざまな例では、クラウドインフラストラクチャシステム４００２は、「ビッグデータ（big data）」ならびに関係する計算サービスおよび分析サービスを提供することもできる。「ビッグデータ」という語は、一般に、大量のデータを可視化し、傾向を検出し、および／またはそうでなければデータと対話するために分析者および研究者によって格納および操作され得る、極めて大きなデータセットを指すのに用いられる。クラウドインフラストラクチャシステム４００２が実行できる分析は、大きなデータセットを使用し、分析し、操作することにより、このデータ内のさまざまな傾向、挙動、関係などを検出し可視化することを含み得る。この分析は、１つ以上のプロセッサが、場合によっては、データを並列に処理し、データを用いてシミュレーションを実行するなどして、実行されてもよい。この分析に使用されるデータは、構造化データ（たとえばデータベースに格納されたデータもしくは構造化モデルに従って構造化されたデータ）および／または非構造化データ（たとえばデータブロブ（blob）（binary large object：バイナリ・ラージ・オブジェクト））を含み得る。
図４０の実施形態に示されるように、クラウドインフラストラクチャシステム４００２は、クラウドインフラストラクチャシステム４００２が提供する各種クラウドサービスのプロビジョンを容易にするために利用されるインフラストラクチャリソース４０３０を含み得る。インフラストラクチャリソース４０３０は、たとえば、処理リソース、ストレージまたはメモリリソース、ネットワーキングリソースなどを含み得る。
いくつかの例では、異なる顧客に対しクラウドインフラストラクチャシステム４００２が提供する各種クラウドサービスをサポートするためのこれらのリソースを効率的にプロビジョニングし易くするために、これらリソースをまとめて、リソースのセットまたはリソースモジュール（「ポッド」とも称される）にしてもよい。各リソースモジュールまたはポッドは、１種類以上のリソースの予め一体化して最適化された組合わせを含み得る。いくつかの例では、異なるポッドを異なる種類のクラウドサービスに対して予めプロビジョニングしてもよい。たとえば、第１のポッドセットをデータベースサービスのためにプロビジョニングしてもよく、第１のポッドセット内のポッドとは異なるリソースの組み合わせを含み得る第２のポッドセットをＪａｖａサービスなどのためにプロビジョニングしてもよい。いくつかのサービスの場合、これらのサービスをプロビジョニングするために割当てられたリソースを当該サービス間で共有してもよい。
クラウドインフラストラクチャシステム４００２自体が、クラウドインフラストラクチャシステム４００２のさまざまなコンポーネントによって共有されるとともにクラウドインフラストラクチャシステム４００２によるサービスのプロビジョニングを容易にするサービス４０３２を、内部で使用してもよい。これらの内部共有サービスは、セキュリティ・アイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャン・ホワイトリストサービス、高可用性バックアップリカバリサービス、クラウドサポートを可能にするサービス、Ｅメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。
さまざまな例では、クラウドインフラストラクチャシステム４００２は複数のサブシステムを含み得る。これらのサブシステムは、ソフトウェア、またはハードウェア、またはこれらの組合わせで実現され得る。図４０に示されるように、サブシステムは、クラウドインフラストラクチャシステム４００２のユーザまたは顧客がクラウドインフラストラクチャシステム４００２とやり取りすることを可能にするユーザインターフェイスサブシステムｗを含み得る。ユーザインターフェイスサブシステム４０１２は、ウェブインターフェイス４０１４、クラウドインフラストラクチャシステム４００２が提供するクラウドサービスが宣伝広告されるとともに消費者が購入可能であるオンラインストアインターフェイス４０１６、およびその他のインターフェイス４０１８などの、各種異なるインターフェイスを含み得る。たとえば、顧客は、クライアントデバイスを用い、クラウドインフラストラクチャシステム４００２が提供する１つ以上のサービスを、インターフェイス４０１４、４０１６、および４０１８のうちの１つ以上を用いて要求（サービス要求４０３４）し得る。たとえば、顧客は、オンラインストアにアクセスし、クラウドインフラストラクチャシステム４００２が提供するクラウドサービスをブラウズし、クラウドインフラストラクチャシステム４００２が提供するサービスのうち顧客が申し込むことを希望する１つ以上のサービスについてサブスクリプションオーダーを行なう。サービス要求は、顧客と、当該顧客が加入を望む１つ以上のサービスとを識別する情報を含み得る。たとえば、顧客は、上述したようなサービスについてのサブスクリプションオーダーを行なってもよい。オーダーの一部として、顧客は、とりわけ、顧客が必要とするリソースの量、および／または、どの時間フレームに該当するか、を識別する情報を提供し得る。
図４０に示される例のようないくつかの例では、クラウドインフラストラクチャシステム４００２は、新規のオーダーを処理するように構成されたオーダー管理サブシステム（ＯＭＳ）４００２を含み得る。この処理の一部として、ＯＭＳ４０２０は、いくつかある動作の中でも特に、既に作成されていなければ顧客のアカウントを生成し、要求されたサービスを顧客に提供するために顧客に対して課金するのに使用する課金および／またはアカウント情報を顧客から受取り、顧客情報を検証し、検証後、顧客のためにこのオーダーを予約し、各種ワークフローを調整することにより、プロビジョニングのためにオーダーを準備するように、構成され得る。
適切に検証されると、ＯＭＳ４０２０は、処理リソース、メモリリソースおよびネットワーキングリソースを含む、このオーダーのためのリソースをプロビジョニングするように構成されたオーダープロビジョニングサブシステム（ＯＰＳ）４０２４を呼び出し得る。プロビジョニングは、オーダーのためのリソースを割当てることと、顧客オーダーが要求するサービスを容易にするようにリソースを構成することとを含み得る。オーダーのためにリソースをプロビジョニングする方法およびプロビジョニングされるリソースのタイプは、顧客がオーダーしたクラウドサービスのタイプに依存し得る。たとえば、あるワークフローに従うと、ＯＰＳ４０２４は、要求されている特定のクラウドサービスを判定し、この特定のクラウドサービスのために予め構成されたであろうポッドの数を特定するように構成されてもよい。あるオーダーのために割当てられるべきポッドの数は、要求されたサービスのサイズ／量／レベル／範囲に依存し得る。たとえば、割当てるポッドの数は、サービスがサポートすべきユーザの数、サービスが要求されている期間などに基づいて判断され得る。次に、要求されたサービスを提供するために、割当てられたポッドを、要求している特定の顧客に合わせてカスタマイズしてもよい。
クラウドインフラストラクチャシステム４００２は、要求されたサービスがいつ使用できるようになるかを示すために、応答または通知４０４４を、要求している顧客に送ってもよい。いくつかの例において、顧客が、要求したサービスの利益の使用および利用を開始できるようにする情報（たとえばリンク）を顧客に送信してもよい。
クラウドインフラストラクチャシステム４００２はサービスを複数の顧客に提供し得る。各顧客ごとに、クラウドインフラストラクチャシステム４００２は、顧客から受けた１つ以上のサブスクリプションオーダーに関係する情報を管理し、オーダーに関係する顧客データを維持し、要求されたサービスを顧客に提供する役割を果たす。また、クラウドインフラストラクチャシステム４００２は、申し込まれたサービスの顧客による使用に関する使用統計を収集してもよい。たとえば、統計は、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムアップタイムおよびシステムダウンタイムの量などについて、収集されてもよい。この使用情報を用いて顧客に課金してもよい。課金は、たとえば月ごとに行なってもよい。
クラウドインフラストラクチャシステム４００２は、サービスを複数の顧客に並列に提供してもよい。クラウドインフラストラクチャシステム４００２は、場合によっては著作権情報を含む、これらの顧客についての情報を格納していてもよい。いくつかの例では、クラウドインフラストラクチャシステム４００２は、顧客の情報を管理して当該管理される情報を分離させることで、ある顧客に関する情報が別の顧客からアクセスされないようにするように構成された、アイデンティティ管理サブシステム（ＩＭＳ）４０２８を含む。ＩＭＳ４０２８は、アイデンティティサービス、たとえば情報アクセス管理、認証および許可サービス、顧客のアイデンティティおよび役割ならびに関連する能力などを管理するためのサービスなどの各種セキュリティ関連サービスを提供するように構成されてもよい。
図４１は、上述のさまざまな例を実現するために用いられ得るコンピュータシステム４１００の例を示す。いくつかの例において、コンピュータシステム４１００を使用することにより、上述のさまざまなサーバおよびコンピュータシステムのいずれかが実現され得る。図４１に示されるように、コンピュータシステム４１００は、バスサブシステム４１０２を介して複数の他のサブシステムと通信する処理サブシステム４１０４を含むさまざまなサブシステムを含む。これらの他のサブシステムは、処理加速ユニット４１０６、Ｉ／Ｏサブシステム４１０８、ストレージサブシステム４１１８および通信サブシステム４１２４を含み得る。ストレージサブシステム４１１８は、非一時的なコンピュータ可読記憶媒体４１２２およびシステムメモリ４１１０を含み得る。
バスサブシステム４１０２は、コンピュータシステム４１００のさまざまなコンポーネントおよびサブシステム同士を意図するとおりに通信させるための機構を提供する。バスサブシステム４１０２は単一のバスとして概略的に示されているが、バスサブシステムの代替例は複数のバスを利用してもよい。バスサブシステム４１０２は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture）（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture）（ＭＣＡ）バス、エンハンストＩＳＡ（Enhanced ISA）（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association）（ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に従って製造されるメザニンバスとして実現可能な周辺コンポーネントインターコネクト（Peripheral Component Interconnect）（ＰＣＩ）バスなどを含み得る。
処理サブシステム４１０４は、コンピュータシステム４１００の動作を制御し、１つ以上のプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含み得る。プロセッサは、シングルコアまたはマルチコアプロセッサを含み得る。コンピュータシステム４１００の処理リソースを、１つ以上の処理ユニット４１３２、４１３４などに組織することができる。処理ユニットは、シングルコアまたはマルチコアのプロセッサを含む１つ以上のプロセッサ、同一のもしくは異なるプロセッサからの１つ以上のコア、コアとプロセッサとの組み合わせ、またはコアとプロセッサとのその他の組み合わせを含み得る。いくつかの例において、処理サブシステム４１０４は、グラフィックスプロセッサ、デジタル信号プロセッサ（ＤＳＰ）などの１つ以上の専用コプロセッサを含み得る。いくつかの例では、処理サブシステム４１０４の処理ユニットの一部または全ては、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのカスタマイズされた回路を用いて実現することができる。
いくつかの例において、処理サブシステム４１０４内の処理ユニットは、システムメモリ４１１０またはコンピュータ可読記憶媒体４１２２に格納された命令を実行することができる。さまざまな例において、処理ユニットはさまざまなプログラムまたはコード命令を実行するとともに、同時に実行する複数のプログラムまたはプロセスを維持することができる。任意の所定の時点で、実行されるべきプログラムコードの一部または全ては、システムメモリ４１１０および／または潜在的に１つ以上の記憶装置を含むコンピュータ可読記憶媒体４１１０に常駐していてもよい。適切なプログラミングにより、処理サブシステム４１０４は、先に述べたさまざまな機能を提供することができる。コンピュータシステム４１００が１つ以上の仮想マシンを実行している例において、１つ以上の処理ユニットに各仮想マシンを割当ててもよい。
いくつかの例において、コンピュータシステム４１００によって実行される全体的な処理を加速するよう、カスタマイズされた処理を実行するために、または処理サブシステム４１０４によって実行される処理の一部をオフロードするために、処理加速ユニット４１０６を任意に設けてもよい。
Ｉ／Ｏサブシステム４１０８は、コンピュータシステム４１００に情報を入力するための、および／またはコンピュータシステム４１００から、もしくはコンピュータシステム１２００を介して、情報を出力するための、デバイスおよび機構を含み得る。一般に、「入力デバイス」という語の使用は、コンピュータシステム４１００に情報を入力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。ユーザインターフェイス入力デバイスは、たとえば、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザが入力デバイスを制御しそれと対話することを可能にするＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサ、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャおよび音声コマンドを用いて入力を受信するためのインターフェイスを提供するデバイスなど、モーションセンシングおよび／またはジェスチャ認識デバイスも含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き（たとえば、写真を撮っている間および／またはメニュー選択を行っている間の「まばたき」）を検出し、アイジェスチャを入力デバイスへの入力として変換するアイジェスチャ認識デバイスも含んでもよい。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システムと対話することを可能にする音声認識感知デバイスを含んでもよい。
ユーザインターフェイス入力デバイスの他の例は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスも含むが、それらに限定されない。加えて、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、および医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスを含んでもよい。
一般に、出力デバイスという語の使用は、コンピュータシステム４１００からユーザまたは他のコンピュータに情報を出力するための考えられる全てのタイプのデバイスおよび機構を含むことを意図している。ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非視覚式ディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを用いたものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含み得るが、それらに限定されない。
ストレージサブシステム４１１８は、コンピュータシステム４１００によって使用される情報を格納するためのリポジトリまたはデータストアを備える。ストレージサブシステム４１１８は、いくつかの例の機能を提供する基本的なプログラミングおよびデータ構成を格納するための有形の非一時的なコンピュータ可読記憶媒体を提供する。処理サブシステム４１０４によって実行されると上述の機能を提供するソフトウェア（たとえばプログラム、コードモジュール、命令）が、ストレージサブシステム４１１８に格納されてもよい。ソフトウェアは、処理サブシステム４１０４の１つ以上の処理ユニットによって実行されてもよい。ストレージサブシステム４１１８はまた、本開示に従って使用されるデータを格納するためのリポジトリを備えてもよい。
ストレージサブシステム４１１８は、揮発性メモリデバイスおよび不揮発性メモリデバイスを含む１つ以上の非一時的メモリデバイスを含み得る。図４１に示すように、ストレージサブシステム４１１８は、システムメモリ４１１０およびコンピュータ可読記憶媒体４１２２を含む。システムメモリ４１１０は、プログラム実行中に命令およびデータを格納するための揮発性主ランダムアクセスメモリ（ＲＡＭ）と、固定命令が格納される不揮発性読出専用メモリ（ＲＯＭ）またはフラッシュメモリとを含む、いくつかのメモリを含み得る。いくつかの実装例において、起動中などにコンピュータシステム４１００内の要素間における情報の転送を助ける基本的なルーチンを含むベーシックインプット／アウトプットシステム（basic input/output system）（ＢＩＯＳ）は、典型的には、ＲＯＭに格納されてもよい。典型的に、ＲＡＭは、処理サブシステム４１０４によって現在動作および実行させられているデータおよび／またはプログラムモジュールを含む。いくつかの実装例において、システムメモリ４１１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの複数の異なるタイプのメモリを含み得る。
一例として、限定を伴うことなく、図４１に示されるように、システムメモリ４１１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含み得る実行中のアプリケーションプログラム４１１２、プログラムデータ４１１４、およびオペレーティングシステム４１１６を、ロードしてもよい。一例として、オペレーティングシステム４１１６は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／またはＬｉｎｕｘオペレーティングシステム、市場で入手可能なさまざまなＵＮＩＸ（登録商標）もしくはＵＮＩＸ系オペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むがそれらに限定されない）、および／または、モバイルオペレーティングシステム、たとえば、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標） Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標） ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標） ＯＳ、および、Ｐａｌｍ（登録商標） ＯＳオペレーティングシステムなどを含み得る。
コンピュータ可読記憶媒体４１２２は、いくつかの例の機能を提供するプログラミングおよびデータ構成を格納することができる。コンピュータ可読媒体４１２２は、コンピュータシステム４１００のための、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータを格納し得る。処理サブシステム４１０４によって実行されると上記機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム４１１８に格納されてもよい。一例として、コンピュータ可読記憶媒体４１２２は、ハードディスクドライブ、磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤ、Ｂｌｕ－Ｒａｙ（登録商標）ディスクなどの光ディスクドライブ、またはその他の光学媒体のような不揮発性メモリを含み得る。コンピュータ可読記憶媒体４１２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、それらに限定されるものではない。コンピュータ可読記憶媒体４１２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭのような揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組合わせを使用するハイブリッドＳＳＤも含み得る。コンピュータ可読記憶媒体４１２２は、コンピュータシステム４１００のためのコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータを格納し得る。
いくつかの例では、ストレージサブシステム４１１８はまた、コンピュータ可読記憶媒体４１２２にさらに接続可能なコンピュータ可読記憶媒体リーダ４１２０も含み得る。リーダ４１２０は、ディスク、フラッシュドライブなどのメモリデバイスからデータを受取り得るとともに、読取るように構成され得る。
いくつかの例では、コンピュータシステム４１００は、処理リソースおよびメモリリソースの仮想化を含むがこれに限定されない仮想化技術をサポートし得る。たとえば、コンピュータシステム４１００は、１つ以上の仮想マシンを実行するためのサポートを提供してもよい。コンピュータシステム４１００は、仮想マシンの構成および管理を容易にするハイパーバイザなどのプログラムを実行し得る。各仮想マシンは、概して、他の仮想マシンからは独立して実行される。仮想マシンは、メモリ、計算（たとえばプロセッサ、コア）、Ｉ／Ｏ、およびネットワーキングリソースを割当てられてもよい。各仮想マシンは、典型的に、コンピュータシステム４１００によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同じでも異なっていてもよい、それ自体のオペレーティングシステムを実行する。したがって、複数のオペレーティングシステムが潜在的にはコンピュータシステム４１００によって同時に実行され得る。
通信サブシステム４１２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム４１２４は、他のシステムとコンピュータシステム４１００との間のデータの送受のためのインターフェイスとして機能する。たとえば、通信サブシステム４１２４は、コンピュータシステム４１００が、１つ以上のクライアントコンピューティングデバイスとの間で情報を送受信するために、インターネットを介して１つ以上のクライアントコンピューティングデバイスへの通信チャネルを確立することを可能にし得る。
通信サブシステム４１２４は、有線および／または無線の通信プロトコルの両方をサポートし得る。たとえば、いくつかの例において、通信サブシステム４１２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格）、もしくは他のモバイル通信技術、またはそれらのいずれかの組合わせを用いて）無線音声および／もしくはデータネットワークにアクセスするための無線周波数（ＲＦ）送受信機コンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、ならびに／または、他のコンポーネントを含み得る。いくつかの例において、通信サブシステム４１２４は、無線インターフェイスに加えてまたはその代わりに、有線ネットワーク接続（たとえば、Ｅｔｈｅｒｎｅｔ（登録商標））を提供することができる。
通信サブシステム４１２４は、さまざまな形式でデータを受取り、送信することができる。たとえば、いくつかの例において、通信サブシステム４１２４は、構造化データフィードおよび／または非構造化データフィード４１２６、イベントストリーム４１２８、イベントアップデート４１３０などの形式で入力通信を受信し得る。たとえば、通信サブシステム４１２４は、ソーシャルメディアネットワークのユーザから、ならびに／または、フィード、アップデート、Ｒｉｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィードおよび／もしくは１つ以上の第三者情報源からのリアルタイムアップデートなどの他の通信サービスのユーザから、リアルタイムでデータフィード４１２６を受信（または送信）するように構成されてもよい。
いくつかの例では、通信サブシステム４１２４は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム４１２８および／またはイベントアップデート４１３０を含み得る。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえばネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリングなどを挙げることができる。
通信サブシステム４１２４は、構造化および／または非構造化データフィード４１２６、イベントストリーム４１２８、イベントアップデート４１３０などを、コンピュータシステム４１００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。
コンピュータシステム４１００は、手持ち式の携帯型デバイス（たとえばｉＰｈｏｎｅ（登録商標）セルラーフォン、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば頭部装着型ディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのもののうちの１つであり得る。
コンピュータおよびネットワークの性質が常に変化するものであるので、図４１に示されるコンピュータシステム４１００の記載は、具体例としてのみ意図されている。図４１に示されるシステムよりも多くのコンポーネントまたは少ないコンポーネントを有するその他多くの構成が実現可能である。当業者であれば、本明細書の開示および教示に基づいて、さまざまな例を実現するための他の態様および／または方法を理解するだろう。
スマートコンテンツ－結果のランク付け
クライアントまたはユーザからの入力に応答して特定のコンテンツ（コンテンツアイテム）を推奨するように構成されたコンテンツ推奨システムの場合、コンテンツアイテムを互いに対して評価およびランク付けするプロセスは推奨全体において重要な役割を果たす。たとえば、ユーザは、１つ以上の検索用語を検索エンジンクエリインターフェイスに入力し得るとともに、推奨システムは、入力された検索用語に最も厳密に一致する１つ以上の関連コンテンツアイテム（たとえば、ウェブページ、文書、画像など）を推奨し得る。他の例では、ユーザは、コンテンツオーサリングシステムを用いて、電子メール、文書、オンライン記事、ブログ投稿などのオリジナルのコンテンツをオーサリングし得る。コンテンツオーサリングシステムは、ユーザによってオーサリングされたコンテンツに関連する可能性がある関係コンテンツアイテムの推奨を行なうように構成され得る。たとえば、上述のように、コンテンツ推奨システムは、オーサーが、所望するのであれば、推奨されるコンテンツアイテムのうちの１つ以上を、ユーザによってオーサリングされているコンテンツに組込むことができるように、関連する画像またはウェブページへのリンク等をユーザに推奨し得る。このような技術のいくつかの例が上記段落に記載されている。これらの例が示すように、特定のコンテンツアイテムのランク付けおよび推奨は、他のプロセスから手動で入力されたユーザ入力および／または自動入力を受取ることに応答して、多くの異なる使用事例に適用され得る。ランク付けおよび／または推奨されるべきコンテンツアイテムは、サーチの際に推奨システムが利用できる画像、ウェブページ、他のメディアファイル、文書、デジタルオブジェクトなどに対応し得る。これらのコンテンツアイテムは、推奨システムにアクセス可能な、専用のリポジトリまたは公共のリポジトリ（たとえば、インターネット）であり得る１つ以上のリポジトリに格納され得る。
しかしながら、コンテンツアイテムのランク付けは重要な作業である。たとえば、推奨を実行するためにタグ一致技術を用いる推奨システムについて考察する。このようなシステムでは、推奨システムによって検索するのに利用可能なコンテンツアイテムがタグ付けされ、コンテンツアイテムがタグと共に１つ以上のリポジトリに格納され得る。タグ付けは、コンテンツアイテムタグ付けサービス／アプリケーションによって実行されてもよい。コンテンツアイテムの場合、コンテンツアイテムに関連付けられた１つ以上のタグは、コンテンツアイテムに含まれるコンテンツを示している。値（場合によってはタグ確率とも称される）はまた、各タグに関連付けられてもよく、その値は、コンテンツアイテムにおいて現われるタグによって示されるコンテンツの尺度（たとえば、確率）を提供する。コンテンツアイテムの推奨がなされることとなるユーザ入力（たとえば、検索用語／句、ユーザによってオーサリングされるコンテンツ）を受取ると、ユーザ入力が分析されて、ユーザ入力に関連付けられるべき１つ以上のタグが識別され得る。次いで、推奨システムは、タグ一致技術を用いて、ユーザ入力に関連付けられたタグと一致する関連付けられたタグを有するコンテンツアイテムのセットを、検索に利用可能なコンテンツアイテムから識別し得る。次いで、推奨システムは、何らかのランク付けアルゴリズムを用いて、識別されたセット内のコンテンツアイテムをランク付けし、その結果をユーザに表示し得る。
しかしながら、推奨システムによって用いられるランク付けアルゴリズムの有効性は、特定の使用事例では制限される可能性があり、最適な結果を生成しない可能性がある。たとえば、ユーザ入力に関連付けられた複数のタグが存在する場合について考察する。たとえば、ユーザが単語「コーヒー（coffee）」および「人（human）」を画像検索エンジンにタイプする場合、タグ「コーヒー」および「人」がユーザ入力に関連付けられ得る。特定の実施形態では、検索用語自体は、ユーザ入力に関連付けられたタグとして扱われてもよい。簡潔にするために、検索に利用可能なコンテンツアイテムの集まりはタグ付き画像を含むと想定する。推奨システムは、これらの２つのタグを用いて、コンテンツアイテム（たとえば、画像）の集まりから、一致するコンテンツアイテムのセットを取出し得る。この場合、コンテンツアイテムに関連付けられた少なくとも１つのタグがユーザ入力に関連付けられたタグと一致する場合、当該コンテンツアイテムは一致していると見なされる。複数の一致するコンテンツアイテムが推奨システムによって取出されており、各コンテンツアイテムに「コーヒー」および「人」タグの両方が関連付けられているシナリオ（事例１）について考察する。これらの取出されたコンテンツアイテムをランク付けする１つの考えられる方法は、（ａ）一致するコンテンツアイテムごとに、そのコンテンツアイテムについてのタグ「コーヒー」および「人」に関連付けられた値を追加し、次いで、（ｂ）それらの関連付けられた追加合計に基づいてコンテンツアイテムをランク付けすることである。しかしながら、この場合、或る問題が生じる。なぜなら、複数の一致するコンテンツアイテムについて、一致するタグに関連付けられた複数の値が合計されて同じ値になる可能性があるからである。この状況が起こる可能性は非常に高い。なぜなら、大部分のタグ付けサービスが複数の確率を１段階だけで正規化するからである。たとえば、３つの一致する画像は、以下のように関連付けられたタグ値を有し得る。具体的には、画像Ａ（（「コーヒー」，０．５），（「人」，０．５））；画像Ｂ（（「コーヒー」，０．２），（「人」，０．８））；および画像Ｃ（（「コーヒー」，０．７），（「人」，０．３））である。以上のように、これらの一致画像の各々についての一致タグの値の合計は「１」であり、このため、従来の加算技術を用いて、これらの画像の一方を他方に対してランク付けする方法はない。したがって、単にそれらの一致するタグ値の加算合計に基づいてこれらの画像をランク付けすることは、画像のランク付けのために用いることができない。
上記の例を拡張すると、一致画像のセットは、１つのタグだけ（たとえば、一致した「コーヒー」だけ、または一致した「人」だけ）に一致するとともに関連付けられた同じタグ値を有する複数の画像を含む可能性もある。この場合も、画像をランク付けする際に問題が生じる。たとえば、３つの一致する画像が以下のように関連付けられたタグ値を有する可能性がある場合について考察する。具体的には、画像Ａ（（「コーヒー」，０．５））、画像Ｂ（（「人」，０．５））である。この場合も、従来の技術を用いて、これらの画像の一方を他方に対してランク付けする方法はない。
上記状況は、ユーザ入力に関連付けられたタグが３つ以上存在する場合、さらに悪化する。たとえば、ユーザが「コーヒー」、「人」、「カフェ（cafe）」という単語を画像検索エンジンにタイプする場合、ユーザ入力に関連付けられた３つの検索タグ「コーヒー」、「人」、「カフェ」が生じる。推奨システムは、コンテンツアイテム（たとえば、画像）の集まりから一致するコンテンツアイテムのセットを取出し得る。この場合、コンテンツアイテムは、当該コンテンツアイテムに関連付けられた少なくとも１つのタグがユーザ入力に関連付けられたタグと一致する場合、一致していると見なされる。一致するコンテンツアイテムについての一致するタグの数は、わずかに１つ一致タグから複数の一致タグまでとさまざまなであり得る（「コーヒー」、「人」および「カフェ」の例の場合、最大で３つの一致タグがある）。このシナリオでも、一致するコンテンツアイテムが複数ある場合、一致するタグに関連付けられた値は合計して同じ値になり得る。たとえば、３つの一致する画像は、以下のように関連付けられたタグ値を有し得る。具体的には、画像Ａ（（「人」，０．８），（「コーヒー」，０．２））；画像Ｂ（（「人」，０．２），（「コーヒー」，０．２），（「カフェ」，０．６））；および画像Ｃ（（「人」，０．５），（「カフェ」，０．５））である。上記のように、これらの一致画像の各々についての一致タグの値の合計は「１」であり、このため、従来の加算技術を用いて、これらの画像の一方を他方に対してランク付けする方法はない。
したがって、多くの場合、単純なタグ一致技術は、さまざまな理由で、最適なコンテンツ推奨を返さない可能性がある。たとえば、リポジトリ内の特定の画像（または他のコンテンツアイテム）は、１つまたは２つのコンテンツタグだけでタグ付けされてもよく、他の画像／コンテンツアイテムは、単一のコンテンツアイテムに対して潜在的に数十または数百のタグを含む多数のタグでタグ付けされてもよい。このような場合、従来のタグ一致技術は、高度にタグ付けされたコンテンツアイテムを過度に推奨する可能性があり（たとえば、入力された語に一致する少なくとも１つのタグを含む頻度がより高いからである）、および／または、このようなアイテムを過小に推奨する可能性がある（たとえば、１つ以上のコンテンツタグを一致させるときでも、それらのタグの大部分は依然として入力された語と一致しないからである）。同様に、ユーザまたはクライアントシステムによって提供される入力コンテンツは、受取った入力データに応じて、ほんの数個の入力語（たとえば、より大きな入力テキストから抽出される、明確に入力された検索用語またはトピック）だけを含み得るか、または比較的多数の入力語を含み得る。このような場合、従来のタグ一致技術では、リポジトリ内の特定の関連コンテンツアイテムを（たとえば、関係するコンテンツアイテムのタグと一致する入力語が少なすぎるために）識別できないか、または、より関連性の低いコンテンツアイテムを（たとえば、この関連性の低いコンテンツアイテムが１つ以上の一致タグを含んでいるために）誤って推奨する可能性がある。
特定の実施形態において、タグ付けされたコンテンツアイテムを評価し、ランク付けし、推奨するための改善された技術を本明細書で説明する。いくつかの実施形態では、コンテンツ推奨システムは、検索クエリ、新しくオーサリングされたテキスト入力などの入力コンテンツをクライアントデバイスから受取り得る。１つ以上のタグが、クライアントデバイスから受取った入力コンテンツに含まれてもよく、もしくは当該入力コンテンツに関連付けられてもよく、および／または、当該入力コンテンツに対して実行される前処理技術および分析技術に基づいて当該入力コンテンツから判定および抽出されてもよい。加えて、コンテンツ推奨システムは、画像、メディアコンテンツファイル、ウェブページへのリンクおよび／または他の文書などの複数のタグ付きコンテンツアイテムを格納するコンテンツリポジトリにアクセスし得る。場合によっては、コンテンツリポジトリは、タグ付きコンテンツアイテムを識別するデータを格納してもよく、タグ付きコンテンツアイテムごとに、各アイテムについての関連付けられたタグ情報をさらに格納してもよい。この場合、コンテンツアイテムについてのタグ情報は、コンテンツアイテムに関連付けられた１つ以上のタグを識別する情報と関連付けられた各々のタグについてのタグ値とを含む。
推奨が行われるべき入力データを受取ったことに応答して、コンテンツ推奨システムは、コンテンツリポジトリからの一致するタグ付きコンテンツアイテムのセットを検索可能なコンテンツアイテムの集まりから取出し得る。この場合、或るコンテンツアイテムは、当該コンテンツアイテムに関連付けられた少なくとも１つのコンテンツタグが入力コンテンツに関連付けられたタグと一致する場合、一致するコンテンツアイテムと見なされる。次いで、コンテンツリポジトリから取出された一致するタグ付きコンテンツアイテムごとに、コンテンツ推奨システムは以下の２つのスコアを算出し得る。（１）入力コンテンツに関連付けられたタグと一致するコンテンツアイテムに関連付けられたタグの数に基づいた第１のスコア（タグカウントスコアとも称される）、および（２）コンテンツアイテムについての一致するタグの各々に対するタグ値に基づいた第２のスコア（タグ値ベースのスコアまたはＴＶＢＳとも称される）。次いで、コンテンツ推奨システムは、一致するコンテンツアイテムに関する第１のスコアおよび第２のスコアに基づいて、一致するコンテンツアイテムの各々についての最終ランク付けスコアを算出する。次いで、一致するコンテンツアイテムのセットについて計算された最終ランク付けスコアを用いて、一致するコンテンツアイテムのランク付けリストを生成する。このランク付けリストは、ユーザまたはクライアントシステムに出力されるべき一致コンテンツアイテムの推奨されるサブセットを識別するために用いられる。
ここで図４２を参照すると、特定の実施形態に従ったユーザまたはクライアントシステム４２１０から受取った入力コンテンツに応答して、コンテンツリポジトリ４２３０からのコンテンツアイテムに対する評価およびランク付けを行なうために実装されるコンテンツ推奨システム４２２０を備えたコンピューティング環境４２００のブロック図が示されている。この例では、グラフィカルユーザインターフェイス（graphical user interface：ＧＵＩ）４２１５を含め、コンテンツ推奨システム４２２０内のさまざまなコンポーネントおよびサブシステムも示されている。クライアントシステム４２１０は、このＧＵＩ ４２１５を介してコンテンツ推奨システム４２２０と対話して、入力コンテンツを提供するとともに、推奨されるコンテンツアイテムのサブセットを識別するデータを受取り得る。特定の実施形態では、ＧＵＩ ４２１５は、コンテンツをオーサリングするためにユーザによって用いられる別個のクライアントアプリケーション４２１５（たとえば、ウェブブラウザアプリケーション）のＧＵＩであってもよい。この実施形態では、コンテンツ推奨システム４２２０は、ユーザによって提供されるかまたはオーサリングされたコンテンツをクライアントアプリケーションから受取り得る。コンテンツは、クライアントアプリケーションおよびコンテンツ推奨システム４２２０が互いに対話して情報を交換することを可能にするアプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）を用いて、コンテンツ推奨システム４２２０によって受取られてもよい。
図４２に示す実施形態は、単なる例にすぎず、主張される実施形態の範囲を過度に限定することを意図するものではない。当業者であれば、実現可能な多くの変更例、代替例および変形例を認識するだろう。たとえば、いくつかの実装例では、コンテンツ推奨システム４２２０は、図４２に示されるものよりも多いかもしくは少ないシステムもしくはサブシステムを有し得るか、２つ以上のシステムを組合わせ得るか、または、異なる構成もしくは配置のシステムを有し得る。コンテンツ推奨システム４２２０は、いくつかの実施形態では、専用の特化されたハードウェアおよびソフトウェアを備えた独立したコンピューティングインフラストラクチャおよびネットワークインフラストラクチャを用いる別個のシステムを含む１つ以上のコンピューティングシステムとして実装されてもよい。代替的または付加的には、これらのコンポーネントおよびサブシステムのうちの１つ以上は、別個の機能を実行する単一のシステムに統合されてもよい。図４２に示すさまざまなシステム、サブシステムおよびコンポーネントは、それぞれのシステムの１つ以上の処理ユニット（たとえば、プロセッサ、コア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）、ハードウェア、またはそれらの組合わせで実装され得る。ソフトウェアは、非一時的記憶媒体上（たとえば、メモリデバイス上）に格納され得る。
高レベルでは、コンテンツ推奨システム４２２０は、ユーザ入力コンテンツを受取るとともに、ユーザ入力コンテンツに応じて、当該ユーザ入力コンテンツに基づいてコンテンツアイテム推奨を行なうように構成される。これらの推奨は、推奨を行なうためにコンテンツ推奨システム４２２０にとって利用可能かつアクセス可能であるコンテンツアイテムの集まりから行なわれる。コンテンツアイテムの集まりは、画像、さまざまな種類の文書、メディアコンテンツ、デジタルオブジェクト等を含み得る。ユーザ入力コンテンツに関連付けられたタグ情報およびコンテンツアイテムの集まりに関連付けられたタグ情報に基づいて、コンテンツ推奨システム４２２０は、タグ一致技術を用いて、ユーザ入力コンテンツについて、一致するコンテンツアイテムのセットを識別するように構成されている。次いで、コンテンツ推奨システム４２２０は、本開示で説明する革新的なランク付け技術を用いて、一致するコンテンツアイテムのセット中のコンテンツアイテムをランク付けするように構成される。ランク付けに基づいて、コンテンツ推奨システム４２２０は、ユーザまたはクライアントシステムに出力されるべき一致するコンテンツアイテムのサブセットを識別および推奨するように構成される。
コンテンツ推奨システム４２２０は、コンテンツ推奨システム４２２０による推奨に利用可能なコンテンツアイテムを受取るかまたは取出すように構成されたコンテンツタグ付けサブシステム４２２２を含む。コンテンツアイテムは、画像、ウェブページ、文書、メディアファイル等を含み得るが、これらに限定されない。コンテンツアイテムは、１つ以上のコンテンツリポジトリ４２３０から受取られ得るかまたは検索され得る。コンテンツリポジトリ４２３０は、画像ライブラリ、文書ストア、ウェブベースのリソースのローカルエリアネットワークまたはワイドエリアネットワーク（たとえば、インターネット）等を含む、ライブラリまたはデータベースなどのさまざまな公共または専用のコンテンツリポジトリを含み得る。１つ以上のコンテンツリポジトリ４２３０は、コンテンツ推奨システム４２２０にローカルに格納されてもよく、他のコンテンツリポジトリは、コンテンツ推奨システム４２２０から別個であり遠隔に設けられているとともに１つ以上のコンピュータネットワークを介してコンテンツ推奨システム４２２０にアクセス可能であってもよい。
特定の実施形態では、コンテンツアイテムごとに、コンテンツタグ付けサブシステム４２２２は、コンテンツアイテムのコンテンツを取出して分析するとともに、コンテンツアイテムに関連付けられるべき１つ以上のコンテンツタグ（タグ）を識別するように構成される。コンテンツアイテムに関連付けられる各タグごとに、コンテンツタグ付け部４２２２はまた、タグに関連付けられたタグ値を判定し得る。この場合、この値は、コンテンツアイテムにおいて現われるタグによって示されるコンテンツの尺度（たとえば、確率）を提供する。タグについてのタグ値は、特定のコンテンツタグがそのコンテンツアイテムにどのように適用可能であるかを表わす数値尺度に対応し得る。１つ以上のタグおよび対応するタグ値をコンテンツアイテムに関連付けてもよい。複数の関連付けられたタグおよび対応するタグ値を有するコンテンツアイテムの場合、これらのタグ値は、その画像内のタグによって示される画像トピックまたはテーマの相対的な著名性を表わし得る。たとえば、比較的高いタグ値を有するコンテンツアイテムに関連付けられた第１のタグは、当該第１のタグによって示されるコンテンツまたは特徴がコンテンツアイテムにおいて特に関連性があり著名であることを示し得る。対照的に、より低いタグ値を有する同じコンテンツアイテムに関連付けられた第２のタグは、当該第２のタグによって示されるコンテンツまたは特徴が、第１のコンテンツタグによって示されるコンテンツと比較してコンテンツアイテムにおいてそれほど著名ではないことまたは普及していないことを示し得る。たとえば、画像コンテンツアイテムは、（「人」，０．８），（「コーヒー」，０．２）といった２つの関連付けられたタグおよび値を有し得る。これは、画像がコーヒー（たとえば、コーヒーカップ）および人（たとえば、コーヒーを飲む人）に関係するコンテンツを含むこと、さらに、画像において人の方がコーヒーの描写と比べてより目立つように描写されている（たとえば、画像の大部分が人を描写していてもよく、コーヒーカップは画像のうちわずかな面積を占めていてもよい）ことを示す。タグ値は異なるフォーマットを用いて表現されてもよい。たとえば、いくつかの実装例では、これらのタグ値は、０．１と１．０との間の浮動小数点で表わされてもよい。いくつかの実装例では、特定のコンテンツアイテムに関連付けられたタグについての全てのタグ値の合計は、（たとえば、合計すると１になる）固定された一定値になり得る。
いくつかの実施形態では、コンテンツタグ付け部４２２２は、コンテンツアイテムと関連付けられるべき１つ以上のタグと各タグについてのタグ値とを識別することを含む、コンテンツアイテムに対するタグ付けタスクを実行するために、コンテンツタグ付けサービスのサービスを用い得る。特定の実施形態では、コンテンツタグ付け部４２２２は、コンテンツアイテムを入力として採用するとともにコンテンツアイテムおよび関連付けられたタグ値についてのタグを予測するようにトレーニングされた１つ以上の予測機械学習モデルを用いて実装される。いくつかの実施形態では、これらのタグは、モデルをトレーニングするために用いられる事前構成されたタグのセットから選択されてもよい。事前トレーニングされた機械学習モデルを用いるさまざまな機械学習技術、および／または、ＡＩベースのテキストもしくは画像分類システム、トピックもしくは特徴抽出を含む他の人工知能ベースのツール、および／または、上述の技術の他の任意の組合わせが、コンテンツアイテムおよび対応するタグ値に関連付けられるべきタグを判定するために用いられてもよい。
いくつかの実施形態では、コンテンツリポジトリ４２３０から取出されたコンテンツアイテムは、関連付けられたコンテンツタグおよびタグ値を既に含み得る。取出されたコンテンツアイテムがタグ情報を含まない場合、および／または、コンテンツ推奨システム４２２０がコンテンツアイテムについての追加タグを判定するように構成されている場合、コンテンツタグ付け部４２２２は、取出されたコンテンツアイテムについての新しいタグを更新または生成するために用いられ得る。コンテンツタグ付け部４２２２は、多種多様な技術を用いて、コンテンツアイテムについてのタグ情報（たとえば、１つ以上のタグおよび関連付けられたタグ値）を生成し得る。たとえば、コンテンツタグ付け部４２２２は、取出されたコンテンツアイテムを分析してコンテンツタグを判定するために、パーズ、処理、特徴抽出および／または他の分析技術などの前述の技術のいずれかまたは全てを用いてもよい。パーズ、処理、特徴抽出および／または分析のタイプはコンテンツアイテムのタイプに依存し得る。たとえば、ブログ投稿、手紙、電子メール、記事、文書などのテキストベースのコンテンツアイテムの場合、分析は、キーワード抽出および処理ツール（たとえば、ステミング、同義語検索など）、トピック分析ツールなどを含み得る。コンテンツアイテムが画像である場合、人工知能ベースの画像分類ツールを用いて、特定の画像特徴の識別および／または画像タグの生成を実行し得る。たとえば、画像の分析により複数の画像特徴を識別してもよく、画像がこれらの識別された特徴のそれぞれでタグ付けされてもよい。１つまたは両方のタイプの分析（すなわち、画像からのタグ抽出およびテキストコンテンツからのキーワード／トピック抽出）は、分析、機械学習アルゴリズムおよび／または人工知能（ＡＩ）ベースの技術、たとえば、ＡＩベースの認知画像分析サービス、またはテキストコンテンツに用いられる同様のＡＩ／ＲＥＳＴ認知テキストサービスなどを用いて、ＲＥＳＴベースのサービスまたは他のウェブサービスを介して実行され得る。同様の技術が、映像ファイル、音声ファイル、グラフィックス、またはソーシャルメディア投稿などの他のタイプのコンテンツアイテムのために用いられてもよい。この場合、コンテンツアイテムのメディアタイプに応じて特定の特徴（たとえば、単語、画像／映像内のオブジェクト、顔の表現など）を抽出および分析するために専用のウェブサービスが用いられてもよい。
いくつかの実施形態では、コンテンツタグ付け部４２２２は、トレーニングデータでトレーニングされた１つ以上の機械学習および／または人工知能ベースの事前トレーニング済みモデルを用いて、コンテンツアイテムについてのタグおよびタグ値を判定するのに用いられるコンテンツ特徴を識別および抽出し得る。たとえば、モデルトレーニングシステムは、以前の入力データ（たとえば、テキスト入力、画像など）の或るトレーニングデータセットを含むトレーニングデータセットと、以前の入力データについての対応するタグとに基づいて機械学習アルゴリズムを用いて予めトレーニングされ得る１つ以上のモデルを生成し得る。さまざまな実施形態において、１つ以上の異なる種類のトレーニング済みモデルが用いられてもよく、これには、ナイーブベイズモデル、判定ツリーモデル、ロジスティック回帰モデルもしくは深層学習モデルなどの、教師ありもしくは半教師ありの学習技術を実行する分類システム、または、教師ありもしくは教師なしの学習技術を実行し得る他の任意の機械学習もしくは人工知能ベースの予測システムが含まれる。各機械学習モデルまたはモデルタイプの場合、トレーニング済みモデルは１つ以上のコンピューティングシステムによって実行され得る。この期間中、或るコンテンツアイテムが１つ以上のモデルへの入力として提供されるとともに、モデルからの出力が当該コンテンツアイテムに関連付けられるべき１つ以上のタグを識別し得るか、または、モデルの出力が、当該コンテンツアイテムに関連付けられるべき１つ以上のタグを識別するために用いられ得る。したがって、コンテンツタグ付け部４２２２は、多種多様なツールまたは技術、たとえば、キーワード抽出および処理（たとえば、ステミング、同義語検索など）、トピック分析、画像からの特徴抽出、機械学習およびＡＩベースのモデリングツールおよびテキストもしくは画像分類システム、ならびに／または、推奨に利用可能な各コンテンツアイテムごとのタグ情報（たとえば、１つ以上のタグおよび関連付けられたタグ値）を判定もしくは生成するための上述の技術の他の任意の組合わせなど、を用い得るが、これらに限定されない。
特定の実施形態では、推奨に利用可能なコンテンツアイテムおよびそれらの関連付けられたタグ情報（たとえば、各コンテンツアイテムごとに、コンテンツアイテムに関連付けられた１つ以上のタグおよび対応するタグ値）がデータストア４２２３に格納され得る。いくつかの実施形態では、コンテンツ／タグ情報データストア４２２３は、コンテンツリポジトリ４２３０から取出されたコンテンツアイテムを識別するデータを格納し得る。これは、アイテム自体（たとえば、画像、ウェブページ、文書、メディアファイルなど）を含み得るか、または、付加的／代替的には、アイテムへの参照（たとえば、アイテム識別子、コンテンツアイテムを取出すことができるネットワークアドレス、アイテムの記述、アイテムのサムネイル等）を含み得る。コンテンツ／タグ情報データストア４２２３に格納され得るデータのタイプを示す例を図４５に示し、以下でより詳細に説明する。
コンテンツ推奨システム４２２０はタグ識別子サブシステム４２２１を含む。タグ識別子サブシステム４２２１は、デバイス４２１０からユーザ入力コンテンツを受取るとともに、ユーザコンテンツに関連付けられるべき１つ以上のタグを判定するように構成されている。いくつかの実施形態では、デバイス４２１０から受取ったユーザコンテンツは、関連付けられたタグを含み得る。いくつかの他の実施形態では、タグ識別子４２２１は、入力データと関連付けられるべき１つ以上のタグを判定するために入力データを処理するように構成され得る。一例として、タグ識別子４２２１は、データタグ付けサービスを用いて、入力データに関連付けられるべき１つ以上のタグのセットを識別し得る。次いで、タグ識別子４２２１は、さらなる処理のために、入力データに（およびいくつかの実装例ではユーザコンテンツにも）関連付けられたタグを、推奨されるコンテンツアイテム識別子およびランク付けサブシステム４２２４（簡潔にするためにコンテンツアイテムランク付け部４２２４とも称され得る）に提供し得る。
いくつかの実施形態では、タグ識別子４２２１は、コンテンツタグ付け部４２２２によって用いられる上述のさまざまな技術を用いて、上述のように、受取ったユーザコンテンツに関連付けられるべき１つ以上のタグを判定し得る。いくつかの実施形態では、タグ識別子４２２１およびコンテンツタグ付け部４２２２はともにタグの同じスーパーセットを用い得るが、このタグの同じスーパーセットから、ユーザ入力およびコンテンツアイテムに関連付けられるべきタグが判定される。特定の実施形態では、タグ識別子４２２１およびコンテンツタグ付け部４２２２は、ユーザコンテンツおよびコンテンツアイテムにそれぞれ関連付けられるべきタグを識別するために同じデータタグ付けサービスを用いてもよい。さらに他の実施形態では、タグ識別子４２２１およびコンテンツタグ付け部４２２２のサブシステムは、リポジトリ４２３０から受取ったコンテンツアイテムとクライアントシステム４２１０から受取った入力コンテンツとに対して同様の（または同一の）処理を実行するように構成された単一のサブシステムとして実装され得る。
上述のように、コンテンツアイテムがコンテンツタグ付け部４２２２によってタグ付けされると、各コンテンツアイテムごとに、コンテンツアイテムに関連付けられるべき１つ以上のタグが、各タグごとにタグ値と共に識別される。ユーザコンテンツのためのタグ付けに関して、いくつかの実施形態では、タグ識別子４２２１は、関連付けられたタグ値なしで、ユーザ入力に関連付けられるべきタグのみを判定するように構成される。このような実施形態では、各タグには、ユーザ入力に関連付けられたタグに基づいてコンテンツアイテムランク付け部４２２４によって実行されるランク付けに対して等しい重みが与えられる。いくつかの他の実施形態では、タグおよび関連付けられたタグ値がともに、ユーザコンテンツについて判定され得るともに、コンテンツアイテム推奨をランク付けするためにコンテンツアイテムランク付け部４２２４によって用いられ得る。
上述したように、タグ識別子４２２１によって受取られて処理されるユーザコンテンツは異なる形態を取り得る。たとえば、ユーザコンテンツは、ユーザによってオーサリングされている文書（たとえば、電子メール、記事、ブログ投稿、文書、ソーシャルメディア投稿、画像など）のコンテンツ、ユーザによって作成または選択されたコンテンツ（たとえば、マルチメディアファイル）などを含み得る。別の例として、ユーザ入力は、ユーザによってアクセスされる文書（たとえば、ウェブページ）であってもよい。さらに別の例として、ユーザコンテンツは、検索を実行するためにユーザによって入力された検索用語（たとえば、ブラウザベースの検索エンジン）であってもよい。特定の実施形態では、たとえば、検索用語については、これらの用語自体がタグとして用いられてもよい。
図４２に図示して上述したように、コンテンツアイテムランク付け部４２２４は、タグ識別子４２２１から、ユーザコンテンツに関連付けられた１つ以上のタグのセットを識別する情報を入力として受取る。ユーザコンテンツについてのこのタグ情報に基づいて、かつ、推奨に利用可能なコンテンツアイテムに基づいて、コンテンツアイテムランク付け部４２２４は、タグ一致技術を用いて、入力コンテンツに最も関係および／または関連する１つ以上のコンテンツアイテムを識別するように構成される。複数のコンテンツアイテムがユーザ入力に関係するかまたは関連するものとして識別される場合、コンテンツアイテムランク付け部４２２４はさらに、本明細書で説明する革新的なランク付け技術を用いてコンテンツアイテムをランク付けするように構成される。コンテンツアイテムをスコアリングしてランク付けするためにコンテンツアイテムランク付け部４２２４によって用いられるさまざまな技術に関係するさらなる詳細について、以下でより詳細に説明する。コンテンツアイテムランク付け部４２２４は、ユーザのために受取ったユーザ入力に応答して、当該ユーザに推奨されるべきコンテンツアイテムのランク付けリストを生成するように構成される。次いで、コンテンツアイテムのランク付けリストは、さらなる処理のために推奨セレクタサブシステム４２２５に提供される。
推奨セレクタ４２２５は、コンテンツアイテムランク付け部４２２４から受取ったコンテンツアイテムのランク付けリストを用いて、クライアントシステム４２１０から受取った入力コンテンツに応答して、ユーザに推奨されるべき１つ以上の特定のコンテンツアイテムを選択するように構成される。特定のシナリオでは、ランク付けリスト内の全てのコンテンツアイテムが推奨のために選択されてもよい。他のいくつかのシナリオでは、ランク付けされたコンテンツアイテムのサブセットが推奨のために選択されてもよく、この場合、サブセットは、ランク付けリスト内の全てのコンテンツアイテムよりも少ないコンテンツアイテムを含み、当該サブセットに含まれる１つ以上のコンテンツアイテムは、ランク付けリスト内のコンテンツアイテムのランク付けに基づいて選択される。たとえば、推奨セレクタ４２２５は、推奨のためにランク付けリストから上位「Ｘ」までのランク付けされた（たとえば、上位５個まで、上位１０個までなどの）コンテンツアイテムを選択し得る。この場合、Ｘは、ランク付けされたアイテムの数以下の何らかの整数である。特定の実施形態では、推奨セレクタ４２２５は、ランク付けリスト内のコンテンツアイテムに関連付けられたスコアに基づいて、ユーザに推奨されるべきサブセットに含まれるようにコンテンツアイテムを選択し得る。たとえば、ユーザ設定可能な閾値スコアを上回るスコアが関連付けられているコンテンツアイテムのみが、ユーザに推奨されるように選択されてもよい。
次いで、推奨セレクタ４２２５によって推奨すべく選択されたコンテンツアイテムを識別する情報が、コンテンツ推奨システム４２２０からユーザのユーザクライアントデバイス４２１０に通信され得る。次いで、推奨コンテンツアイテムに関する情報が、ユーザクライアントデバイスを介してユーザに出力され得る。たとえば、推奨に関する情報は、ユーザクライアントデバイス上に表示されるＧＵＩ ４２１５を介して、またはユーザクライアントデバイスによって実行されるアプリケーション４２１５を介して出力され得る。たとえば、ユーザ入力が、ユーザデバイスによって実行されるブラウザによって表示されるウェブページを介してユーザによって入力された検索クエリに対応していた場合、推奨に関する情報は、そのウェブページを介して、またはブラウザによって表示される追加のウェブページを介して、ユーザに出力されてもよい。特定の実施形態では、推奨された各コンテンツアイテムごとに、ユーザに出力された情報は、コンテンツアイテムを識別する情報（たとえば、テキスト情報、画像のサムネイル等）、およびコンテンツアイテムにアクセスするための情報を含み得る。たとえば、コンテンツアイテムにアクセスする情報は、リンク（たとえば、ＵＲＬ）の形態であってもよく、ユーザによって（たとえば、マウスクリック動作によって）選択されると、対応するコンテンツアイテムにアクセスされて、ユーザクライアントデバイスを介してユーザに対して表示される。いくつかの実施形態では、コンテンツアイテムを識別する情報とコンテンツアイテムにアクセスするための情報とが組合わされてもよい（たとえば、画像コンテンツアイテムを識別するとともに画像自体にアクセスするためにユーザによって選択され得る推奨された画像のサムネイル表現）。
さまざまな実施形態において、コンテンツ推奨システム４２２０は、その関連付けられたハードウェア／ソフトウェアコンポーネント４２２１～４２２５およびサービスを含んでおり、フロントエンドクライアントデバイス４２１０から離れた所にあるバックエンドサービスとして実装されてもよい。クライアントデバイス４２１０とコンテンツ推奨システム４２２０との間の対話は、インターネットベースのウェブブラウジングセッションまたはクライアント・サーバアプリケーションセッションであってもよく、これらセッション中に、ユーザは、クライアントデバイス４２１０を介してユーザコンテンツ（たとえば、検索用語、オリジナルのオーサリング済みコンテンツなど）を入力し得るとともに、コンテンツ推奨システム４２２０からコンテンツアイテム推奨を受取り得る。付加的または代替的には、コンテンツ推奨システム４２２０および／またはコンテンツリポジトリ４２３０ならびに関係するサービスは、クライアントデバイス上で直接実行される専用ソフトウェアコンポーネントとして実装されてもよい。
いくつかの実施形態では、図４２に示すシステム４２００は、クラウドベースの多層システムとして実装されてもよく、上位層ユーザデバイス４２１０は、リソースの基礎となるセット（たとえば、クラウドベース、ＳａａＳ、ＩａａＳ、ＰａａＳなど）上に展開されて実行されるバックエンドアプリケーションサーバ上に常駐するコンテンツ推奨システム４２２０を介して、ネットワークベースのリソースおよびサービスへのアクセスを要求してこれを受取り得る。コンテンツ推奨システム４２２０に関して本明細書で説明する機能の一部または全ては、レプレゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）サービスおよび／またはシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）ウェブサービスもしくはＡＰＩを含むウェブサービス、および／または、ハイパーテキスト転送プロトコル（ＨＴＴＰ）もしくはＨＴＴＰセキュアプロトコルを介して公開されるウェブコンテンツによって実行され得るか、またはそれらを用いてアクセスされ得る。したがって、追加の詳細とともに示されるコンポーネントを不明瞭にしないために図４２には示されていないが、コンピューティング環境４２００は、追加のクライアントデバイス、１つ以上のコンピュータネットワーク、１つ以上のファイアウォール、プロキシサーバ、ルータ、ゲートウェイ、ロードバランサ、および／または他の中間ネットワークデバイスを含み得ることで、クライアントデバイス４２１０とコンテンツ推奨システム４２２０とコンテンツリポジトリ４２３０との間の対話を容易にし得る。
さまざまな実装例では、コンピューティング環境４２００に示されるシステムは、専用サーバコンピュータ（デスクトップサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなど）、サーバファーム、サーバクラスタ、分散サーバ、または、他の任意の適切な構成および／もしくは組合せのコンピューティングハードウェアを含む、１つ以上のコンピューティングシステムおよび／またはネットワークを用いて実装され得る。たとえば、コンテンツ推奨システム４２２０は、オペレーティングシステムおよび／またはハイパーテキストトランスポートプロトコル（ＨＴＴＰ）サーバ、ファイル・トランスポート・サービス（File Transport Service：ＦＴＰ）サーバ、共通ゲートウェイ・インターフェイス（Common Gateway Interface：ＣＧＩ）サーバ、Ｊａｖａ（登録商標）サーバ、データベースサーバ、および他のコンピューティングシステムを含むさまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションを実行し得る。コンテンツ推奨システム４２２０内のコンポーネントまたはサブシステムのいずれかまたは全ては、少なくとも１つのメモリ、１つ以上の処理ユニット（たとえば、プロセッサ）および／またはストレージを含み得る。コンテンツ推奨システム４２２０内のサブシステムおよび／またはモジュールは、ハードウェア、ハードウェア上で実行されるソフトウェア（たとえば、プロセッサによって実行可能なプログラムコードもしくは命令）、またはそれらの組合わせで実装され得る。いくつかの例では、ソフトウェアは、メモリ（たとえば、非一時的なコンピュータ可読媒体）、メモリデバイス、または他の何らかの物理メモリに格納され得るとともに、１つ以上の処理ユニット（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のグラフィックスプロセスユニット（Graphics Process Unit：ＧＰＵ）など）によって実行され得る。処理ユニットのコンピュータ実行可能命令またはファームウェア実装例は、本明細書で説明するさまざまな動作、機能、方法および／またはプロセスを実行し得る任意の適切なプログラミング言語で書かれたコンピュータ実行可能命令または機械実行可能命令を含み得る。メモリは、処理ユニット上でロード可能かつ実行可能なプログラム命令、およびこれらのプログラムの実行中に生成されるデータを格納し得る。メモリは揮発性（ランダムアクセスメモリ（ＲＡＭ）など）および／または不揮発性（読取り専用メモリ（ＲＯＭ）など）、フラッシュメモリ等）であり得る。メモリは、コンピュータ可読記憶媒体などの任意のタイプの永続性記憶装置を用いて実装され得る。いくつかの例では、コンピュータ可読記憶媒体は、悪意あるコードを含む電子通信からコンピュータを保護するように構成され得る。
図４３は、特定の実施形態に従った、ユーザコンテンツに関連するコンテンツアイテムを識別してランク付けするためのコンテンツ推奨システムによって実行される処理を示す簡略化されたフローチャート４３００を示す。図４３に示される処理は、それぞれのシステムの１つ以上の処理ユニット（たとえば、プロセッサ、コア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）、ハードウェア、またはそれらの組合わせで実装され得る。ソフトウェアは、非一時的記憶媒体上に（たとえば、メモリデバイス上に）格納され得る。図４３に提示される以下に記載の方法は、例示的であるとともに非限定的であることを意図している。図４３は、特定のシーケンスまたは順序で行なわれるさまざまな処理ステップを示すが、これは限定を意図するものではない。いくつかの代替的な実施形態では、処理は、何らかの異なる順序で実行されてもよく、または、いくつかのステップが並行して実行されてもよい。図４３に示される処理は、コンテンツ推奨システム４２２０などの、図４２に示される１つ以上のシステムによって実行され得る。一例として、図４２に示す実施形態の場合、タグ識別子４２２１によって４３０２および４３０４における処理を実行し、コンテンツアイテムランク付け部４２２４によって４３０６から４３１６における処理を実行し、推奨選択器４２２５によって４３１８および４３２０における処理を実行してもよい。しかしながら、図４３に関連付けて説明する技術および機能は、必ずしも図４２に示される特定のコンピューティングインフラストラクチャ内の実装例だけに限定されるわけではなく、本明細書で説明する他の互換性のあるコンピューティングインフラストラクチャを用いて実装され得ることを理解されたい。
４３０２において、コンテンツ推奨システム４２２０は、１つ以上のユーザまたはクライアントシステム４２１０から入力コンテンツを受取り得る。図４２を参照して上述したように、入力コンテンツは、コンテンツ推奨システム４２２０によって提供されるグラフィカルユーザインターフェイス４２１５（たとえば、ウェブベースのＧＵＩ）を介して、クライアントデバイス４２１０から受取られてもよい。他の例では、入力コンテンツは、クライアントデバイス４２１０にインストールされたフロントエンドアプリケーション（たとえば、モバイルアプリケーション）によって送信されるデータに基づいて、コンテンツ推奨システム４２２０内で実行するウェブサーバまたはバックエンドサービスによって受取られてもよい。
いくつかの実施形態では、ステップ４３０２で受取った入力コンテンツは、ユーザによって検索エンジンユーザインターフェイスに入力される検索用語または句のセットに対応し得る。他の実施形態では、入力コンテンツは、ユーザによってオーサリングされて専用ユーザインターフェイスに入力されるオリジナルのコンテンツに対応し得る。たとえば、新しいオリジナルコンテンツは、オンライン記事、広報、電子メール、ブログ投稿などを含み得るとともに、このようなコンテンツは、ソフトウェアベースのワードプロセッサツール、電子メールクライアントアプリケーション、ウェブ開発ツールなどを介してユーザによって入力され得る。さらに他の例では、ステップ４３０２で受取られた入力コンテンツは、画像、グラフィック、音声入力、または、クライアントデバイス４３１０を介してユーザによって生成もしくは選択される他の任意のテキストおよび／もしくはマルチメディアコンテンツであってもよい。
図４４を簡単に参照すると、ユーザがオリジナルのオーサリング済みコンテンツを入力することを可能にするユーザインターフェイス画面４４１０を含む例示的なユーザインターフェイス４４００が示されている。この例では、ユーザインターフェイス画面４４１０は「コンテンツオーサリングユーザインターフェイス」と総称されるが、さまざまな実施形態では、ユーザインターフェイス４４１０は、ワードプロセッサ、記事設計者またはブログ投稿作成者、電子メールクライアントアプリケーションなどのためのインターフェイスに対応し得る。この例では、ユーザインターフェイス４４１０は、ユーザがオーサリング済みコンテンツのタイトルまたは主題を入力し得る第１のテキストボックス４４１１と、ユーザが入力コンテンツについての全テキスト（たとえば、記事、電子メール本文、文書など）を入力し得る第２のテキストボックス４４１２とを含む。加えて、ユーザインターフェイス４４１０は、新たにオーサリングされたコンテンツに組込まれ得る関連コンテンツアイテム（たとえば、画像、関係する記事など）をユーザが検索し始めることを可能にする選択可能ボタン４４１３を含む。場合によっては、ボタン４４１３または同様のユーザインターフェイスコンポーネントを選択することで、ユーザインターフェイス４４１０を介して受取ったユーザコンテンツ（たとえば、４４１１および／または４４１２において入力されたユーザコンテンツ）を最初に分析してコンテンツ推奨システム４２２０に送信することによって、図４３に示されるプロセスを開始させてもよい。他の実施形態では、バックグランドプロセスをフロントエンドユーザインターフェイス内で連続的（または周期的）に実行して、ユーザから受取った新しいテキスト入力（たとえば、４４１１および／または４４１２においてユーザによって入力されたコンテンツ）を連続的に（または周期的に）分析し得るとともに、テキスト更新に応答して図４３のプロセスを再び開始し得ることにより、コンテンツアイテム推奨がリアルタイムで連続的または周期的に更新され得ることとなる。
再び図４３を参照すると、４３０４において、コンテンツ推奨システム４２２０は、ステップ４３０２において受取った入力コンテンツについての１つ以上のタグを判定する。いくつかの実施形態では、４３０２において受取った入力コンテンツには既にタグが関連付けられているかまたは当該入力コンテンツにタグが埋込まれている可能性があり、タグ識別子４２２１は、入力コンテンツに関連付けられた予め定められたタグのセットを識別および抽出し得る。ステップ４３０２において受取った入力コンテンツが検索用語に対応している場合、タグ識別子４２２１は、単に、ユーザによって入力された検索用語を（たとえば、冠詞、結合語、前置詞、修飾語などの特定の語を除いて）タグとして用いてもよい。元からオーサリングされていたテキストコンテンツの場合、またはコンテンツ推奨システム４２２０が受取った他の任意のタグ無しの入力コンテンツの場合、タグ識別子４２２１は、４３０２において受取った入力コンテンツのさまざまな特徴を分析し、この分析に基づいて、受取った入力コンテンツに関連付けられるべき１つ以上のタグを判定するように構成され得る。前述したように、タグ識別子４２２１は、多種多様な技術を用いて、４３０２において受取った入力コンテンツに関連付けられるべき１つ以上のタグを判定し得る。
図４４に示す例示的なユーザインターフェイス４４００を再び参照すると、この例では、４３０２において受取った入力コンテンツは、主題／トピックボックス４４１１においてユーザによって入力されたテキスト、すなわち、「Is Coffee Healthier For You Than Tea？（貴方にとってコーヒーは茶よりも健康に良いものですか？）」と、ボックス４４１２において入力されたテキストとに対応し得る。４４１１における主題コンテンツの分析および４４１１においてオーサリングされた記事の本文と、提供され得る任意の追加の入力コンテンツとに基づいて、コンテンツ推奨システム４２２０は、４３０４において、タグ「コーヒー（coffee）」、「茶（tea）」および「人（human）」がユーザコンテンツに関連付けられるべきであると判定し得る。
４３０６において、４３０２で入力コンテンツについて判定されたタグに基づいて、コンテンツ推奨システム４２２０は、タグ一致技術を用いて、推奨に利用可能なコンテンツアイテムの集まりから一致するコンテンツアイテムのセットを識別する。この場合、コンテンツアイテムは、当該コンテンツアイテムに関連付けられた少なくとも１つのタグが４３０４において入力コンテンツについて判定されたタグと一致する場合、４３０６において一致していると見なされて識別される。４３０６において識別されたコンテンツアイテムのセットは、コンテンツアイテムの一致セットと称されてもよく、４３０２で受取った入力コンテンツに応答してユーザに推奨される候補であるコンテンツアイテムを含む。さまざまな実施形態において、ステミングおよび同義語検索／比較などのデータ処理技術は、一致するタグを識別するために、４３０６における一致プロセスの一部として用いられてもよい。
たとえば、図４２に示す実施形態では、推奨に利用可能なコンテンツアイテムの集まりを、それらの関連付けられたタグ情報（たとえば、コンテンツアイテムに関連付けられたタグおよび関連付けられたタグ値）と共に、コンテンツ／タグ情報データストア４２２３に格納し得る。４３０６における処理の一部として、コンテンツ推奨システム４２２０は、４３０４において判定された１つ以上のタグを、推奨に利用可能なコンテンツアイテムに関連付けられたタグと比較し、それらのコンテンツアイテムを、４３０４において識別されたタグと一致する少なくとも１つの関連付けられたタグを有する集まりから識別し得る。
図４４の例を続けて参照して、４３０２において受取られたユーザ入力コンテンツについて、４３０４においてタグ「コーヒー」、「人」、および「茶」が判定されたと想定すると、図４５の例示的な表４５００は、推奨を行なうのに利用可能なコンテンツアイテムの集まりからコンテンツ推奨システム４２２０によって（たとえば、コンテンツアイテムランク付け部４２２４によって）識別されたコンテンツアイテムの一致セットを示す。表４５００から分かるように、８つの異なる画像コンテンツアイテムは、タグ「コーヒー」、「人」または「茶」のうち少なくとも１つに一致する少なくとも１つの関連付けられたタグを有するものとして識別されていた。この例に示されるように、一致した各画像コンテンツアイテムは、画像識別子４５０１を用いて識別される。図４５に提供される画像の説明４５０２は、一致した画像の内容の説明であり、実際の画像を示す必要がないように図４５において提供されている。一致した画像の各々は１つ以上の関連付けられたタグ４５０３を有し、タグ値４５０４は各タグに関連付けられている。表４５００の例において、タグ値は、予め定められた範囲（たとえば０．０～１．０）の浮動小数点値であり、各コンテンツアイテムごとのタグ値の合計は同じ総数（たとえば１．０）となる。このような実施形態は付加的な技術的利点を提供するものであって、たとえば、タグカウントスコアとＴＶＢＳとの合計が均一であることで、より多くの関連付けられたタグを有するコンテンツアイテムが、より多くの関連付けられたタグに基づいて、意図的に高くランク付けされないこと、または過剰に推奨されないことを確実にし得る。さらに、以下で説明するように、０．０から１．０の範囲のタグ値を有することにより、（たとえば、以下で説明する使用事例において）それらが乗算されたとき、結果として得られる値は、コンテンツアイテムが特定のグループまたはバケット内でランク付けされることを可能にする一方で、１つのグループ内で最も高くランク付けされたコンテンツアイテムが、次により高いグループ内で最も低くランク付けされたコンテンツアイテムよりも高くランク付けされないようにすることを確実にする。
図４５から、或るコンテンツアイテム（この例では、画像）に関連付けられた少なくとも１つのタグが入力コンテンツに関連付けられたタグと一致する場合、当該コンテンツアイテムが一致していると見なされることが分かる。一致したコンテンツアイテムには、入力コンテンツに関連付けられたタグのうちの１つ以上に一致するタグが関連付けられてもよい。一致したコンテンツアイテムにはまた、入力コンテンツ（たとえば、Image_1、Image_3など）についてのタグとは異なる他のタグが関連付けられていてもよい。
４３０８において、入力コンテンツについて判定されたタグと一致するコンテンツアイテムに関連付けられたタグの数に基づいて、４３０６で識別された一致するコンテンツアイテムごとにタグカウントスコア（第１のスコア）が計算される。いくつかのシナリオでは、コンテンツアイテムの一致するタグの各々に１の値を与え、このため、或るコンテンツアイテムについて４３０８で計算されるタグカウントスコアは、入力コンテンツに関連付けられたタグと一致するコンテンツアイテムのタグの数に等しくなる。図４５で識別される一致画像の例の場合、図４６の表４６００では、図４５で（および図４６でも）識別される一致画像の各々についてそのタグカウントスコア４６０２を識別する。たとえば、Image_1についてのタグカウントスコアは、当該画像に関連付けられた１つのタグ（「人」）が入力コンテンツに関連付けられたタグと一致したので、「１」となる。別の例として、Image_2についてのタグカウントスコアは、画像に関連付けられた２つのタグ（「コーヒー」および「人」）が入力コンテンツに関連付けられたタグと一致したので、「２」となる。さらに別の例として、Image_8についてのタグカウントスコアは、画像に関連付けられた１つのタグ（「コーヒー」）が入力コンテンツに関連付けられたタグと一致したので、「１」となる。
４３１０において、一致するコンテンツアイテムは、４３０８においてコンテンツアイテムについて計算されたタグカウントスコアに基づいてグループまたはバケットにグループ化（バケット化）される。特定の実施形態では、グループ（またはバケット）は、同じタグカウントスコアを有する全てのコンテンツアイテムを含む。コンテンツアイテムの一致タグの各々に１の値が与えられるシナリオでは、各グループまたは各バケットに含まれるコンテンツアイテムは同数の一致したタグを有する。４３１０における処理は、任意であってもよく、特定の実施形態では実行されない可能性もある。
図４６に示される例を続けて参照すると、８つの一致画像は、タグカウントスコアが１であるコンテンツアイテムを含む第１のグループまたはバケットと、タグカウントスコアが２である第２のグループまたはバケットとを含む２つのグループまたはバケットにグループ化され得る。第１のグループは、画像｛Image_1, Image_3, Image_6, Image_8｝を含むだろう。第２のグループは、画像｛Image_2, Image_4, Image_5, Image_7｝を含むだろう。なお、本例では、一致した画像はいずれも、入力コンテンツに関連付けられた３つのタグ（「コーヒー」、「人」、「茶」）の全てに一致しなかった。
４３１２において、４３１０で識別された各グループごとに、タグ値ベースのスコア（第２のスコア）が、そのグループ内の候補コンテンツアイテムの各々について算出される。いくつかの実施形態では、特定のコンテンツアイテムについてのタグ値ベースのスコア（ＴＶＢＳ）は、そのコンテンツアイテムについての一致タグに関連付けられたタグ値に基づいているとともに当該タグ値を用いて算出される。
特定の実施形態では、コンテンツアイテムについてのＴＶＢＳは、入力コンテンツに関連付けられたタグと一致したコンテンツアイテムのタグに関連付けられたタグ値を乗算することによって算出される。たとえば、以下のとおりである。
図４６におけるImage_1についてのＴＶＢＳ＝０．９３、
図４６におけるImage_2についてのＴＶＢＳ＝０．５＊０．５＝０．２５、
図４６におけるImage_3についてのＴＶＢＳ＝０．６５、
図４６におけるImage_4についてのＴＶＢＳ＝０．３５＊０．６０＝０．２１、など。
表４６００は、上述の技術を用いてさまざまな一致画像について算出されたＴＶＢＳ４６０３を示す。特定の実施形態では、コンテンツアイテムについてのタグ値ベースのスコアを計算するためにナイーブベイズ手法を用いる。たとえば、入力コンテンツについて２つのタグtag1およびtag2が判定されると想定すると、或る画像コンテンツアイテムについてのタグ値ベースのスコア（ＴＶＢＳ）は、以下のように表わすことができる。
ImageiについてのＴＶＢＳ＝Ｐ（Imagei｜tag1, tag2）＝タグtag1およびtag2とした場合のImageiの確率
これを「ｎ」のタグに関して拡張すると、以下のとおりとなる。
P(Imagei|tag1, tag2 …, tagn)=(タグtag1およびtag2および…tagn)とした場合のImageiの確率
タグtag1，tag2…，tagnが互いに依存していないと想定する。
ImageiについてのTVBS = TVBSi = P(Imagei|tag1,tag2 …, tagn)
=P(Imagei|tag1)*P(Imagei|tag2)*…*P(Imagen|tagn)
ここで、単純ナイーブベイズによれば以下の通りとなる。
Figure 2023545945000004
この場合、
Ｐ（Imagei｜tagt）＝Imageiについてのtagtの確率
Ｐ（Imagei）＝全ての画像を固有のものとみなし、この項を破棄または無視することができる
Ｐ（tagt）＝コンテンツアイテムの集まりにおけるタグの頻度（すなわち、tagtでタグ付けされるとともに推奨に利用可能であるコンテンツアイテムの集まりにおけるコンテンツアイテム（たとえば、画像）の数）。この項が分母にあるので、コンテンツアイテムの集まりにタグが存在する頻度が低いほど（すなわち、この関連付けられたタグを有するコンテンツアイテムの数が少ないほど）、当該タグを有する画像についてのＴＶＢＳスコアが高くなるだろう。
上記の式は、拡張すると以下のとおりとなる。
Figure 2023545945000005
上記式３における分子は、確率が同程度である場合により高いスコアをもたらすであろう確率を乗算したものである（複数の画像について同じタグが一致したとすると、分母は同じままであるだろう）。
以下の例は、コンテンツアイテムについてのＴＶＢＳを算出するための式３の適用例を示す。入力コンテンツについて判定されたタグが「人」および「コーヒー」であると想定する。さらに、推奨に利用可能なコンテンツアイテム（画像）の集まりが、以下のタグおよびタグ値を有する３つの画像を含むと想定する。
画像Ａ：（「人」，０．５），（「コーヒー」，０．５）
画像Ｂ：（「人」，０．１），（「コーヒー」，０．９）
画像Ｃ：（「人」，０．８），（「コーヒー」，０．２）
画像Ａの場合：
Ｐ（human｜image）＝０．５およびＰ（coffee｜image）＝０．５
式３を適用すると、以下のとおりである。
Figure 2023545945000006
この場合、「Frequency（human）」は、コンテンツアイテムの集まりにおける、推奨に利用可能であるとともに「人（human）」タグが関連付けられているコンテンツアイテムの数であり、「Frequency（coffee）」は、コンテンツアイテムの集まりにおける、推奨に利用可能であるとともに「コーヒー（coffee）」タグが関連付けられているコンテンツアイテムの数である。
Figure 2023545945000007
画像ＡについてのＴＶＢＳ＝０．０２８
同様の技術を用いると、以下のとおりである。
画像ＢについてのＴＶＢＳ＝（０．１／３）＊（０．９／３）＝０．０１
画像ＣについてのＴＶＢＳ＝（０．８／３）＊（０．２／３）＝０．０１８
この例から分かるように、頻度が同じであれば、確率が同程度である場合にはＴＶＢＳはより高くなる（複数の画像について同じタグが一致したとすると、分母は同じままであるだろう）。
式３の拡張例によれば、コンテンツアイテムの集まりのうち特定の関連付けられたタグを有するコンテンツアイテムの頻度は、ＴＶＢＳを算出するために考慮される（このため、以下に記載するように、総ランク付けスコアにも影響を与える）。特定の関連付けられたタグを有するコンテンツアイテムの数が少ない（すなわち、頻度が低い）ほど、その特定のタグを有する画像についてのＴＶＢＳスコアは高くなるだろう。いくつかの実施形態では、これは、タグの頻度が「まれ」であるかまたはより低いこのようなコンテンツアイテムが、より高くランク付けされたタグの頻繁がより高いコンテンツアイテムよりも高くランク付けされる可能性を高め、これにより、これらのコンテンツアイテムをユーザに推奨されるコンテンツアイテムのリストに含める可能性を高めるために、望ましい。したがって、或るコンテンツアイテムについてのＴＶＢＳの値は、コンテンツアイテムの集まりに現れる特定のタグの発生頻度（すなわち、当該集まりにおける、関連付けられた特定のタグを有するコンテンツアイテムの数）に反比例する。
４３１４では、総ランク付けスコアは、４３０８においてコンテンツアイテムについて算出されたタグカウントスコアと４３１２においてコンテンツアイテムについて算出されたＴＶＢＳとに基づいて、４３０６において識別された一致するコンテンツアイテムごとに算出される。いくつかの実施形態では、候補コンテンツアイテムについての総ランク付けスコアは、（４３０８において算出される）タグカウントスコアと、コンテンツアイテムについて算出される（４３１２において算出される）ＴＶＢＳとの和として算出され得る。すなわち、画像コンテンツアイテムImageiの場合、以下のとおりである。
ランク付けスコア（Imagei）= TagsCountScorei + TVBSi
図４６に示される例の場合、列４６０４は、一致画像ごとに（列４６０２に示される）その画像についてのタグカウントスコアと（列４６０３に示される）その画像についてのＴＶＢＳとを加算することによって、一致画像ごとに計算される総ランク付けスコアを示す。たとえば、算出した総ランク付けスコアは以下のとおりである。
Image_1: 1 + 0.93 = 1.93
Image_2: 2 + 0.25 = 2.25
Image_3: 1 + 0.65 = 1.65
などである。
ステップ４３１６では、コンテンツ推奨システム４２２０（たとえば、コンテンツ推奨システム４２２０におけるコンテンツアイテムランク付け部４２２４）は、４３１４においてコンテンツアイテムについて計算された総ランク付けスコアに基づいて、一致するコンテンツアイテムのランク付けリストを生成する。このため、図４４～図４６の例を続けて参照すると、一致する画像について計算された（列４６０４における）総ランク付けスコアに基づいて、画像（Images）が、（１）Image_2、（２）Image_5、（３）Image_4、（４）Image_7、（５）Image_6、（６）Image_1、（７）Image_8、（８）Image_3、のように最高ランクから最低ランクにまでランク付けされ得る。
タグについてのタグ値が０．０から１．０の範囲内にある特定の実施形態では、（TagCountScore＋ＴＶＢＳ）アプローチを用いた総ランク付けスコアの計算は、入力コンテンツに関連付けられたタグと一致したより多くの関連付けられたタグを有するコンテンツアイテムが、一致するタグの数がより少ないコンテンツアイテムよりも高くランク付けされることを確実にする。たとえば、図４６の例では、（入力コンテンツに関連付けられたタグが一致した画像に関連付けられた２つのタグに対応する）２というタグカウントスコア付きの画像は、常に総ランク付けスコアを有することとなり、このため、（入力コンテンツに関連付けられたタグが一致した画像に関連付けられた２つのタグに対応する）１というタグカウントスコア付きの画像よりも高くランク付けされることとなる。これは、タグ値が０から１の範囲であると想定すると、一致するタグに関連付けられたタグ値を乗算することによって計算される画像についてのＴＶＢＳが１を超える可能性がないためである。このことはまた、第１のタグカウントスコアに対応するコンテンツアイテムの第１のグループまたはバケットおよび第２のタグカウントスコアに対応するコンテンツアイテムの第２のグループまたはバケットに関して、第１のタグカウントスコアが第２のタグカウントスコアよりも高い場合、第１のグループ内の各コンテンツアイテムが第２のグループ内のコンテンツアイテムよりも（総ランク付けスコアがより高いために）高くランク付けされるであろうことを示唆している。したがって、入力コンテンツについて３つのタグ（「コーヒー」、「人」および「茶」）が判定された例では、入力コンテンツについてのタグに対して３つのコンテンツタグ一致を有するコンテンツアイテムは、常に、２つの一致するコンテンツタグを有するコンテンツアイテムよりも高いランクとなり、当該２つの一致するコンテンツタグを有するコンテンツアイテムの各々は、常に、１つの一致するコンテンツタグを有するコンテンツアイテよりも高いランクとなる、等である。各グループまたはバケット内では、コンテンツアイテムは、それらのＴＶＢＳに基づいてランク付けされてもよく、これは、一致するコンテンツタグについてのより高いパラメータおよびより等しいパラメータの両方にとって有利となる。しかしながら、他の実施形態では、さまざまなコンテンツアイテムランク付けの優先度およびポリシーを実現するために、タグカウントスコア、ＴＶＢＳおよび総ランク付けスコアを算出するためにさまざまな式または論理が用いられ得ることを理解されたい。
４３１８において、コンテンツ推奨システム４２２０（たとえば、推奨セレクタ４２２５）は、４３１６で生成されたランク付けリストを用いて、ユーザに推奨されるべき１つ以上のコンテンツアイテムを選択してもよい。特定のシナリオでは、ランク付けリスト内の全てのコンテンツアイテムを推奨のために選択し得る。いくつかの他のシナリオでは、ランク付けされたコンテンツアイテムのサブセットが推奨のために選択されてもよく、この場合、サブセットはランク付けリスト内のコンテンツアイテムを全て含むわけではなく、サブセットに含まれる１つ以上のコンテンツアイテムがランク付けリスト内のコンテンツアイテムのランク付けに基づいて選択される。たとえば、推奨セレクタ４２２５は、推奨のために、ランク付けリストから上位「Ｘ」位にランク付けされた（たとえば、上位５まで、上位１０までなどの）コンテンツアイテムを選択し得る。この場合、Ｘは、リスト中のランク付けされたアイテムの数以下である何らかの整数である。特定の実施形態では、推奨セレクタ４２２５は、ランク付けリスト内のコンテンツアイテムに関連付けられた総ランク付けスコアに基づいて、ユーザに推奨されるべきサブセットに含まれるようにコンテンツアイテムを選択し得る。たとえば、ユーザ設定可能な閾値スコアを上回るスコアが関連付けられているコンテンツアイテムのみがユーザに推奨されるように選択されてもよい。
４３２０において、コンテンツ推奨システム４２２０は、４３１８において選択されたコンテンツアイテムに関する情報をユーザデバイスに通信し得る。この情報は、ユーザに推奨するべきコンテンツアイテムに関する情報を含んでいるので推奨情報と称されてもよい。４３２０において通信される推奨情報はまた、ランク付け情報（たとえば、選択されたコンテンツアイテムに関連付けられた総ランク付けスコア）を含み得る。この情報は、推奨されたコンテンツアイテムに関する情報（たとえば、注文）がユーザデバイスを介してユーザにどのように表示されるかを判定するために、ユーザデバイス上で用いられ得る。いくつかの実施形態では、推奨セレクタ４２２５は、推奨情報の一部として、コンテンツアイテム自体、またはコンテンツアイテムを識別する特定の情報（たとえば、コンテンツアイテム識別子および記述、サムネイル画像、ダウンロードのためのネットワーク経路またはリンクなど）のいずれかをクライアントデバイス４３１０に送信し得る。ステップ４３０２において、このクライアントデバイス４３１０から入力コンテンツが受取られた。
次いで、選択された推奨に関する情報がユーザデバイスを介してユーザに出力され得る。たとえば、推奨に関する情報は、ユーザクライアントデバイス上に表示されるＧＵＩ ４２１５を介して、またはユーザクライアントデバイスによって実行されるアプリケーション４２１５を介して、出力され得る。たとえば、ユーザ入力が、ユーザデバイスによって実行されるブラウザによって表示されるウェブページを介してユーザによって入力された検索クエリに対応している場合、推奨に関する情報は、検索の結果を示すウェブページまたはブラウザによって表示される追加のウェブページを介してユーザに出力されてもよい。特定の実施形態では、推奨されたコンテンツアイテムごとに、ユーザに出力された情報は、コンテンツアイテムを識別する情報（たとえば、テキスト情報、画像のサムネイルなど）およびコンテンツアイテムにアクセスするための情報を含み得る。たとえば、コンテンツアイテムにアクセスする情報は、リンク（たとえば、ＵＲＬ）の形態であってもよく、リンクがユーザによって（たとえば、マウスクリック動作によって）選択されると、対応するコンテンツアイテムにアクセスされて、ユーザクライアントデバイスを介してユーザに対して表示される。いくつかの実施形態では、コンテンツアイテムを識別する情報およびコンテンツアイテムにアクセスするための情報は組合わされてもよい（たとえば、画像コンテンツアイテムを識別するとともに画像自体にアクセスするためにユーザによって選択され得る推奨画像のサムネイル表現）。
たとえば、図４７を参照すると、推奨された画像に関係する情報を表示する図４４のユーザインターフェイス画面４４００の更新に対応する例示的なユーザインターフェイス４７００が示される。この例では、タイトル／主題４７１１、本文４７１２および／または他の任意の入力コンテンツに基づいて、コンテンツ推奨システム４２２０は、画像のランク付けリストから、ユーザに推奨するべく上位にランク付けされた４つのコンテンツアイテム画像を選択した。これらの上位４つのランク付けされた画像に関係する情報は、コンテンツアイテム推奨を示すためにユーザインターフェイス４７００の専用部分４７１４内にランク順に表示される。特定の実施形態では、推奨された画像のサムネイル表現が４７１４において表示され得る。ユーザインターフェイス４７００は、ドラッグアンドドロップ機能または他の技術をサポートして、ユーザが、４７１４に表示された提案された画像の１つ以上を、オーサリング済みコンテンツの本文４７１２に組込むことを可能にする。
図４３に示される上述の処理は限定することを意図したものではない。さまざまな変形例が異なる実施形態において提供されてもよい。たとえば、図４３に示される上述の実施形態の場合、４３１２、４３１４および４３１６における処理が、４３０６で識別される全ての一致するコンテンツアイテムに対して実行される。特定の変形例では、４３０８において算出されるタグカウントスコアは、その後の処理から特定のコンテンツアイテムをフィルタリング除去するために用いられてもよい。たとえば、コンテンツアイテムが異なるタグカウントスコアを有する場合、最低のタグカウントスコア（または他の何らかの閾値）を有するコンテンツアイテムは、フローチャート中のその後の処理からフィルタリング除去され得る。他のいくつかの実施形態では、最高のタグカウントスコアを有するコンテンツアイテムのみがその後の処理のために選択され、その後の処理から他のコンテンツアイテムがフィルタリング除去され得る。たとえば、コンテンツアイテムランク付け部４２２４は、（ステップ４３０４で判定されるとおり）最高のタグスコアグループについてのＴＶＢＳを算出し得るのみであるか、または、最高のタグカウントスコアグループから最低のタグカウントスコアグループまで順々にＴＶＢＳを算出してもよく、その間、算出プロセスは、候補コンテンツアイテムの閾値数または閾値タグカウントスコアに達すると停止する可能性もある。このようなフィルタリングにより、処理すべきコンテンツアイテムの数を減らすとともに、より少ない処理リソース（たとえば、プロセッサ、メモリ、ネットワークリソース）を用いて全体的な推奨動作をより高速でより効率的に実行させ得る。
図４３に示された上述の方法では、４３０４において入力コンテンツに関連付けられるかまたは入力コンテンツについて判定される各タグは、コンテンツ推奨システム４２２０によって実行されるランク付けに対して等しい重みが与えられる。この仮定に基づいて、一致するコンテンツアイテムごとのタグスコアが、入力コンテンツのタグに一致するそのコンテンツタグの数として判定された。したがって、或る一致するコンテンツアイテムに関連付けられた一致するコンテンツタグの各々は、タグカウントスコアの判定に対して等しく値付け／重み付けされた。しかしながら、他の実施形態では、入力コンテンツに関連付けられたタグに異なる重みを与えてもよい。たとえば、入力コンテンツについて判定された２つのタグの場合、一方のタグは、他方のタグよりも高い重みが与えられることで、入力コンテンツについて「より重要」と示されてもよい。たとえば、図４４～図４７に示される上述の例の場合、タグ（「人」、「コーヒー」、「茶」）が入力コンテンツについて判定されており、これら３つのタグに等しい重要度を与えるのではなく、これらのタグは、人＝１、コーヒー＝２、および、茶＝４、のように重み付けされる。この重み付けは、入力コンテンツに対するタグの相対的な重要度を示し得る。たとえば、「茶」は「コーヒー」よりも重く重み付けされており、「コーヒー」は「人」よりも重く重み付けされている。特定の実施形態では、各コンテンツアイテムごとにタグカウントスコアを計算するために用いられる論理は、入力コンテンツに関してタグに割当てられた異なる重みを考慮するように修正されてもよい。このような１つの修正論理に従うと、コンテンツアイテムの一致するタグの各々の寄与分には、入力コンテンツに関して同じタグに関連付けられた重みが掛けられる。たとえば、入力コンテンツについての（人＝１、コーヒー＝２、および茶＝４）の重み付けを用いると、図４５の一致画像に関するタグカウントスコアは以下のとおりとなるだろう。
Image_1：
TagCountScore（重み付けなし）＝「人」タグ一致＝１
TagCountScore（重み付けあり）＝「人」タグ一致＝１*１＝１
Image_2：
TagCountScore（重み付けなし）＝「コーヒー」および「人」タグ一致＝１＋１＝２
TagCountScore（重み付けあり）＝「コーヒー」および「人」タグ一致＝２（１）＋１（１）＝３
Image_3：
TagCountScore（重み付けなし）＝「tea」タグ一致＝１
TagCountScore（重み付けあり）＝「tea」タグ一致＝４（１）＝４
Image_4：
TagCountScore（重み付けなし）＝「コーヒー」および「人」タグ一致＝１＋１＝２
TagCountScore（重み付けあり）＝「コーヒー」および「人」タグ一致＝２（１）＋１（１）＝３
Image_5：
TagCountScore（重み付けなし）＝「茶」および「人」タグ一致＝１＋１＝２
TagCountScore（重み付けあり）＝「茶」および「人」タグ一致＝４（１）＋１（１）＝５
Image_6：
TagCountScore（重み付けなし）＝「コーヒー」タグ一致＝１
TagCountScore（重み付けあり）＝「コーヒー」タグ一致＝２（１）＝２
Image_7：
TagCountScore（重み付けなし）＝「茶」および「人」タグ一致＝１＋１＝２
TagCountScore（重み付けあり）＝「茶」および「人」タグ一致＝４（１）＋１（１）＝５
Image_8：
TagCountScore（重み付けなし）＝「コーヒー」タグ一致＝１
TagCountScore（重み付けあり）＝「コーヒー」タグ一致＝２（１）＝２
異なるタグカウントスコアの結果として、４３１０において実行されるコンテンツアイテムのグループ化またはバケット化はさまざまに異なるだろう。したがって、「茶」タグおよび「人」タグの両方に一致するコンテンツタグを有するコンテンツアイテムはともにグループ化されるとともに５のタグスコアを割当てられ、「茶」について一致するコンテンツタグを１つしかもたないコンテンツアイテムはともにグループ化されるとともに４のタグスコアを割当てられ、さらに、「コーヒー」タグおよび「人」タグの両方に一致するコンテンツタグを有するコンテンツアイテムはともにグループ化されるとともに３のタグスコアを割当てられる、等である。したがって、このような実施形態では、候補コンテンツアイテムの総ランク付けは、コンテンツアイテムのタグがいくつ入力コンテンツのタグに一致したかによって影響されるだけでなく、コンテンツアイテムのどの特定のタグが入力コンテンツタグおよびそれらのタグに与えられる相対的重要度の重みに一致しているかによっても影響される。この例では、画像Image_5およびImage_7は、５という最高のタグカウントスコア（茶＝４＋人＝１）に基づけば、最高ランクの総コンテンツアイテムとなるだろう。
スマートコンテンツ－スマートなカテゴリ化/分類
大量のコンテンツをオンライン方式で分類することは、データに対するシングルパスの制約および高速応答についての要件などの課題を伴う複雑なタスクである。ある実施形態に従うと、コンテンツユーザは、階層的タクソノミーツリーなどの論理クラスタを通じて同様のコンテンツをカテゴリ化し、同様のコンテンツをタクソノミーツリーの同じノード／カテゴリに配置する。時間とともに、コンテンツ実体の数およびタクソノミーツリー内のノードが増加するにつれて、同様のコンテンツ実体は、ノード内に互いに並んで存在していることが分かるだろう。コンテンツ組織化のこの状態を前提として、すでに評価／カテゴリ化されたタクソノミー内に存在するコンテンツは、新しく作成／編集されたものがどこに属し得るかを判定するためにカテゴリ化エンジンなどのコンピュータアルゴリズムによって使用され得る。
ある実施形態に従うと、本明細書に記載のシステムおよび方法を、例えばコンテンツ管理システムとともに用いて、コンテンツをユーザ定義カテゴリにカテゴリ化／分類するための推奨を提供することができ、これにより、コンテンツマネージャのために、事前に評価／カテゴリ化されたコンテンツに基づいて、より少ない労力で、新しいコンテンツを正確なカテゴリに難なく配置する機会が提供される。
推奨システムまたはツールは、人工知能（ＡＩ）技術を用いて、過去のデータから継続的に学習し、および／または生成された推奨から新たに入力された結果を継続的に学習し、新しく作成／編集されたコンテンツの自動カテゴリ化／分類によりコンテンツを関連カテゴリに配置するのを支援することができる。
推奨ツールは、コンテンツから特徴ベクトルを生成し、事前にカテゴリ化されたコンテンツに基づいて特徴空間にクラスタを作成し、クラスタからの特徴空間距離計算により新しいコンテンツについてのカテゴリを推奨することによって、種々のドメインにわたって実装および適用することができる。
図４８は、ある実施形態に従った、コンテンツ管理システム環境の例示的な使用を示す。
より具体的には、図４８は、コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのカテゴリ化エンジンを含み得る例示的なコンテンツ管理システムを示す。
図４８に示されるように、ある実施形態に従うと、ユーザインターフェイス４８０１、４８０３、４８０５および物理デバイスハードウェア４８０６、４８０７、４８０８（例えばＣＰＵ、メモリ）を有する複数のクライアントデバイス４８００、４８０２、および４８０４ごとに、クライアントデバイスに、そこで実行すべきコンテンツアクセスアプリケーション４８１０、４８１１、４８１２を提供することができる。
ある実施形態に従うと、クライアントデバイスは、物理コンピュータハードウェア４８３１（例えばＣＰＵ、メモリ）およびコンテンツ管理システム４８３２を含むアプリケーションサーバ４８３０と通信する（４８６２）ことができる。
ある実施形態に従うと、クライアントデバイスにおけるコンテンツアクセスアプリケーションは、ネットワーク４８６０（例えば、インターネットまたはクラウド環境）を介してコンテンツ管理システムと通信することができる。コンテンツアクセスアプリケーションは、ユーザ４８５０、４８５２、４８５４が、例えば、各クライアントデバイスにおけるコンテンツアイテム４８２０、４８２２、４８２４等のコンテンツを閲覧、アップロード、修正もしくは削除すること、または当該コンテンツにアクセスすることを可能にするように構成することができる。例えば、ユーザが関連するクライアントデバイス上のコンテンツアクセスアプリケーションと対話することによって、新しいコンテンツをコンテンツ管理システムに追加またはアップロードすることができる。コンテンツは、例えば、タグ付けおよび格納のためにコンテンツ管理システムに送信することができる。
ある実施形態に従うと、コンテンツ管理システムは、いくつかのユーザまたはクライアントによって管理することができるコンテンツを整理統合するためのプラットフォームであり得るかまたは当該プラットフォームを含み得る。ある実施形態に従うと、コンテンツ管理システムは、コンテンツ（またはコンテンツアイテム）４８４０を格納するためのコンテンツリポジトリ４８３６と通信するように構成することができ、それらのクライアントデバイスを介してユーザにコンテンツを配信することができる。ある実施形態に従うと、コンテンツリポジトリは、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）、ファイルシステム、またはコンテンツ管理システムがアクセスすることができる他のデータストアであってもよい。コンテンツは、例えば、文書、ファイル、電子メール、メモ、画像、映像、スライドプレゼンテーション、会話、およびユーザプロファイルを含み得る。
ある実施形態に従うと、コンテンツ管理システムは、メタデータをコンテンツに関連付けるように構成することができる。メタデータは、コンテンツのアイテムに関する情報、例えばそのタイトル、著者、公開日、履歴データ、例えば誰がいつアイテムにアクセスしたか、コンテンツが格納されている場所などを含み得る。
ある実施形態に従うと、メタデータをメタデータデータベース４８３８に格納することができる。ある実施形態に従うと、コンテンツ管理システムは、メタデータデータベースと通信して、そこに格納されているメタデータにアクセスし、システムによって生成されるメタデータをメタデータデータベースに格納するように構成することができる。
ある実施形態に従うと、コンテンツ管理システムはまた、サーチインデックス４８３９と通信するように構成することもできる。サーチインデックスは、コンテンツリポジトリおよびメタデータデータベースに格納されたコンテンツおよびデータのインデックス付けおよびサーチを提供するように構成され得る。ある実施形態に従うと、サーチインデックスは、リレーショナルデータベース管理システム（ＲＤＢＭＳ）またはサーチツール、例えばOracle Secure Enterprise search（Oracle SES）などであり得る。
ある実施形態に従うと、コンテンツ管理システムはさらに、コンテンツ管理アプリケーション４８３３およびカテゴリ化エンジン４８３４を含み得る。カテゴリ化エンジンは、人工知能／機械学習エンジンおよびライブラリ４８３５と、例えば、コンテンツカテゴリ化についての推奨を示す出力を表示するためにおよび／またはコンテンツカテゴリ化の選択を示す入力を受信するために使用可能なユーザインターフェイス４８３６とを含み得る。
ある実施形態に従うと、例えばコンテンツ管理システムとともに、カテゴリ化エンジンを用いて、コンテンツを定義（例えばユーザ定義）カテゴリにカテゴリ化／分類するための推奨を提供することができ、これにより、コンテンツマネージャのために、事前に評価／カテゴリ化されたコンテンツに基づいて新しいコンテンツを正確なカテゴリに難なく配置する機会が提供される。カテゴリ化エンジンは、人工知能（ＡＩ）技術および例えば機械学習ライブラリを用いて、過去のデータから継続的に学習するとともに、新しく作成／編集されたコンテンツの自動カテゴリ化／分類によりコンテンツを関連カテゴリに配置するのを支援することができる。推奨ツールは、コンテンツから特徴ベクトルを生成し、事前にカテゴリ化されたコンテンツに基づいて特徴空間にクラスタを作成し、クラスタからの特徴空間距離計算により新しいコンテンツについてのカテゴリを推奨することによって、種々のドメインにわたって実装および適用することができる。エンジンは、付加的または代替的には、その計算によってコンテンツを自動的にカテゴリ化することができる。
概略的に説明するように、ある実施形態に従うと、カテゴリ化エンジンを用いて、新しいタクソノミーを作成し、既存のタクソノミー構造を修正し、および／または、（高信頼度、中信頼度または低信頼度などの）様々な信頼度スコアまたは信頼度レベルに関連付けられた様々な推奨または提案に従って、既存のコンテンツおよび／または新しいコンテンツを一括でカテゴリ化／分類することができる。
例えば、ある実施形態に従うと、コンテンツの特定のセットに関連付けられたカテゴリ／分類の低信頼度の推奨はシステムまたはユーザからは無視することができ、カテゴリの高／中信頼度の推奨は受入れ可能である。
ある実施形態に従うと、カテゴリ化エンジンは、コンテンツアドミニストレータがレビューおよび／または動作を行なうために、コンテンツの特定のセットに関連付けられたカテゴリ／分類についてのこのような推奨または提案をユーザインターフェイスに表示することができる。
例えば、新しいコンテンツのセットでの作業中、システムは、様々なコンテンツの前の分類に基づいて、新しいコンテンツについての１つ以上のカテゴリ／分類を提案または推奨することができ、次いで、コンテンツアドミニストレータは、当該コンテンツに対するそれらのカテゴリ／分類の割当てを受入れまたは拒否することを選択することができる。
ある実施形態に従うと、ユーザまたはコンテンツアドミニストレータによるカテゴリ化提案のこのような受入れまたは拒否は、コンテンツカテゴリ化エンジンのデータベースなどのデータベースに格納することができる。このような履歴記録を利用することで、コンテンツカテゴリ化についての将来の推奨を改良することができる。
ある実施形態に従うと、分類は、文書のトピック分布および名前付き実体分布をより高レベルのクラスタノードと一致させることができるマクロレベル分類段階と、マイクロクラスタの評価に基づいて特徴空間内でカテゴリを拡張して比較することができるマイクロレベル分類段階とを含む２段階のプロセスとして実行することができる。
図４９は、ある実施形態に従った、コンテンツデータの管理および配信のためのコンテンツ管理システムの例示的な使用を示す。
ある実施形態に従うと、コンテンツ管理システム（content management system：ＣＭＳ）により、ユーザが、ウェブコンテンツを含むデジタルコンテンツを協調的に管理することが可能となる。例示的なコンテンツ管理システムは、クラウドサービスから提供されて当該クラウドサービスを介してアクセスされ得るOracle（登録商標）Content Management（ＯＣＭ）である。コンテンツ管理システムは、例えば、関連するデジタルコンテンツの格納、管理および公開などの様々な特徴を提供する。例えばＯＣＭなどのシステムは、複数の配信チャネルにわたるコンテンツの迅速な展開および公開を可能にする。
ある実施形態に従うと、配信チャネルは、コンテンツが当該コンテンツの消費者に配信されるのであれば如何なる形式であってもよい。例示的な配信チャネルは、ウェブサイト、ブログ、ＨＴＭＬ電子メール、ストーリーボード、モバイルアプリケーションなどを含む。関連する配信チャネルによって用いられる文書を迅速に展開するために、システムは、例えば、追加設定なしの（out-of-the-box）テンプレート、ドラッグ・アンド・ドロップ（drag-and-drop）コンポーネント、サンプルページレイアウト、およびサイトテーマなどの特徴を含み得ることにより、ユーザがコンテンツを予め定義された構築ブロックから公開可能な文書へと組立てることを可能にする。コンテンツ管理システムは、これらのコンポーネントを用いて、文書のマークアップ言語およびコード（本明細書では「コード」と総称する）を生成することができる。
ある実施形態に従うと、コンテンツ管理システムと商用プロバイダシステム（商用プロバイダ）との間の対話を確立するサーバアプリケーションプログラムインターフェイス（application program interface：ＡＰＩ）契約（管理ＡＰＩ契約）を提供することができる。サーバＡＰＩ契約は、コンテンツ管理システムと商用プロバイダ（例えばオンライン小売業者）との間の契約として機能し、コンテンツ管理システムと商用プロバイダとの間の通信およびデータ交換を可能にする。ある実施形態に従うと、対話特徴との対話に基づいて、製品に関連付けられたデータおよび他のメトリックを商用プロバイダから取出すことができるか、または、要求に関連付けられたデータを商用プロバイダに送信して、当該製品に関連付けられたアクションを実行することができる。
ある実施形態に従うと、商用プロバイダシステム４９１０をシステム内に設けて、コンテンツデータを管理および配信することができる。商用プロバイダシステムは、製品カタログ４９１１、ＡＰＩ、例えばサーバＡＰＩ４９１２など、および、物理コンピュータリソース、例えばＣＰＵ、メモリ４９１３などを含み得る。
ある実施形態に従うと、コンテンツ管理システム４９２０は、コンテンツメタデータデータベース４９２１（例えば、ＯＣＭコンテンツおよびメタデータデータベース）、ＡＰＩ、例えばサーバＡＰＩ４９２２など、ならびに、物理コンピュータリソース、例えばＣＰＵ、メモリ４９２３などを含み得る。
ある実施形態に従うと、コンテンツアドミニストレータ４９３５は、このようなシステムにおける管理システム４９３０と対話して、コンテンツデータ４９０３を作成／管理および配信することができる。管理システムは、コンテンツマッピング構成４９３２を備え得るかまたは提供し得るユーザインターフェイス４９３１を備え得るかまたは提供し得る。管理システムはまた、例えばＣＰＵ、メモリ４９３３などの物理コンピュータリソースを含み得る。
ある実施形態に従うと、サーバＡＰＩ契約（管理ＡＰＩ契約）４９０４９は、コンテンツ管理システムと商用プロバイダとの間の契約として機能し得る。例えば、サーバＡＰＩ契約は、商用プロバイダにおけるユーザアカウントに関連付けられたアカウント情報およびクレデンシャルを受信するように構成することができる。
ある実施形態に従うと、コンテンツ管理システムは、受信したアカウントクレデンシャルを用いて、サーバＡＰＩ（管理ＡＰＩ）を介して商用プロバイダシステムにおけるコンテンツ管理システムの管理ユーザ（例えばコンテンツアドミニストレータ）を認証することができ、これにより、商用プロバイダシステムに格納されたデータへのコンテンツ管理システムによるアクセスを可能にする。例えば、コンテンツ管理システムは、サーバＡＰＩを介して、商用プロバイダによって販売用に提供される製品のセットを記述／定義するデータを当該商用プロバイダが送信することを要求することができる。商用プロバイダシステムは、次いで、サーバＡＰＩを介してコンテンツ管理システムにこのようなデータを送信することができる。このデータは、例えば、製品のリストを記述するデータと共に、製品のリストを含み得る。
ある実施形態に従うと、コンテンツ管理システムは、例えば生成されたモバイルアプリケーションページ４９０５を介して、または生成されたウェブページ４９０６を介して、いくつかの異なるチャネルにおいてコンテンツ４９０４を公開することができる。
ある実施形態に従うと、エンドユーザ４９４５は、クライアントデバイス４９４０を介して、例えば、生成されたモバイルアプリケーションページ４９０５を表示するモバイルアプリケーション４９４１を介して、または、例えば、生成されたウェブページ４９０６にアクセスして当該ページを表示するブラウザ４９４２などのウェブアプリケーションを介して、このような生成されたページにアクセスすることができる。
ある実施形態に従うと、例えば、公開可能なコンテンツ（例えば、ウェブページまたはモバイルアプリケーション（アプリ）ページ）は、例えば「購入」ボタンなどの機能および視覚的なコンテンツコンポーネントを定義するソフトウェア開発キット（software development kit：ＳＤＫ）４９０７などのコードライブラリを用いて構築することができる。
マクロ／マイクロ分類プロセス
ある実施形態に従うと、分類は、文書のトピック分布および名前付き実体分布をより高レベルのクラスタノードと一致させることができるマクロレベル分類段階と、マイクロクラスタの評価に基づいて特徴空間内でカテゴリを拡張して比較することができるマイクロレベル分類段階とを含む２段階のプロセスとして実行することができる。
図５０は、ある実施形態に従ったスマートコンテンツ分類フロー図を示す。
図５０に示すように、既知のタクソノミー（ドメイン特有のオントロジなど）へのコンテンツの自動的な分類（本明細書では「自動分類」とも称する）は、ＡＩ／ＭＬシステムによって達成することができる。
新しいコンテンツ（すなわち、コンテンツ管理システムにおいて生成されたコンテンツなどの、コンテンツ管理システムにおける新しいコンテンツ、またはコンテンツ管理システムにアップロードされた新しいコンテンツ）が作成される（５０００）場合、予測段階（５０１５）中に、上述のカテゴリ化エンジンなどのエンジンは、新たに作成されたコンテンツがカテゴリ化されるべきであるカテゴリまたは複数のカテゴリを自動的に提案する（５０１０）ことができる。
ある実施形態に従うと、コンテンツのカテゴリ化について（１回または複数回の）選択を受信した後、このような選択されたカテゴリ（または複数のカテゴリ）にコンテンツを配置する（５０２０）ことができる。
このような選択から、学習段階５０３５中に、クラスタ（例えば、カテゴリ化エンジンのメモリまたはライブラリを格納したクラスタ）をこれに応じて更新する（５０３０）ことができる。したがって、予測段階５０１５は、新たに作成された別のコンテンツ５０００に応じて更新することができる。
他のシステムでは、このようなカテゴリ化は、通常、大量の同様のデータをパブリックドメインにおいて分析することによって達成される。しかしながら、ある実施形態に従うと、ユーザ定義カテゴリ階層におけるコンテンツの上述した自動分類は、カテゴリ化／分類の提案に応答して、事前に評価／カテゴリ化されたコンテンツ、カテゴリメタデータ、およびユーザ挙動を継続的に観察するアプローチといった新しいアプローチを必要とする。
ある実施形態に従うと、未評価／未カテゴリ化のコンテンツ、またはわずかに評価／カテゴリ化されただけであるコンテンツは、コールドスタート時にシステムが提案を行なうために依拠する情報をほとんど持たないという点で、特別な課題を提示する。コンテンツ管理システムを使用するビジネスは時間とともに進化するので、古いカテゴリ階層は関連性が低下していき、さらには古くて旧式なものになってしまう。
ある実施形態に従うと、マイクロクラスタリング式アプローチを用いて、関連する概念のクラスタに基づいて様々な種類のコンテンツをカテゴリに自動的に分類するためのシステムおよびツールを本明細書に記載する。このアプローチは、従来のクラスタリングアプローチよりも性能が優れている。さらに、ツールは、ユーザの挙動から学習することができ、コンテンツのオーサーに対していくつかの生産性向上をもたらすことにより時間の経過に応じてそれ自体を調整することができる。ある実施形態に従うと、本システムは以下の使用事例のセットを組込んでいる。
新しいタクソノミーの作成
ある実施形態に従うと、例えば以下の記載により当該開示するシステムおよび方法を利用して新しいタクソノミーを作成することができる。
ａ．ユーザがタクソノミーを作成することを示す命令を受信する。特定の実施形態では、タクソノミーは階層分類構造を含み得る。構造の各ノードはカテゴリである。
ｂ．ユーザが、既存のコンテンツアイテム（例えば、既にコンテンツ管理システム内にあるコンテンツアイテム）の少なくとも一部を適切なカテゴリに（例えば、一度に１つまたは一括で）配置することによってこれらのタクソノミーに分類／カテゴリ化することを示す命令を受信する。
ｃ．（例えば、コンテンツ管理システム内でアップロードまたは作成された）新しいコンテンツを受信する。
ｄ．システムは自動的に通知を受けて、上述のアクションから学習を開始する。
ｅ．システムは、新しく作成されたコンテンツおよびカテゴリ化されていない既存のコンテンツが属し得るカテゴリを（単一のコンテンツごとに、または一括で）推奨することを開始する。
ｆ．ユーザは提案を（一度に１つまたは一括で）受入れるかまたは拒否し、ユーザアクションは、システムに、このことから学習してより良い推奨を行なうよう通知する。
図５１は、ある実施形態に従ったタクソノミー作成フロー図を示す。
ある実施形態に従うと、ステップ５１００において、上述のように、システムは、ユーザが１つ以上のタクソノミーを作成することを示す命令を受信し得る。タクソノミーの作成時、命令はさらに、タクソノミーの下のカテゴリを含み得る。特定の実施形態では、タクソノミーは階層分類構造を含み得る。当該構造の各ノードはカテゴリである。
ある実施形態に従うと、ステップ５１０５において、システムは、ユーザが、既存のコンテンツアイテム（例えば、既にコンテンツ管理システム内にあるコンテンツアイテム）の少なくとも一部を、適切なカテゴリに（例えば、一度に１つまたは一括で）配置することによってこれらのタクソノミーに分類／カテゴリ化することを示す命令を受信し得る。これはまた、新しいコンテンツ（例えば、コンテンツ管理システムにアップロードされた新しいコンテンツ）の分類／カテゴリ化も含み得る。新しいコンテンツは、必ずしも分類またはカテゴリ化を受信するとは限らない。
ある実施形態に従うと、ステップ５１１０において、システムは自動的に通知を受けて、上述のアクションから学習を開始する。システムは、新たに作成されたコンテンツおよびカテゴリ化されていない既存のコンテンツが属し得るカテゴリを推奨することを開始する。これは、個々のコンテンツに対して／コンテンツごとに実行することができるか、または、このような提案は、コンテンツを一括でカテゴリ化するために実行することができる。
ある実施形態に従うと、ステップ５１１５において、システムは、ユーザが当該生成された提案を（例えば、一度に１つまたは一括で）受入れるかまたは拒否することを示す命令を受信し得る。
このように、ある実施形態に従うと、ステップ５１２０において、ユーザアクションを示す命令は、システムに対して、当該ユーザアクションから学習してより良い推奨を行なうよう通知する。システムは、ＭＬおよびＡＩに基づいて、カテゴリ化提案に関して記録された受入れまたは拒否に基づいて推奨を改良することができる。
既存のタクソノミー構造内での修正
ある実施形態に従うと、既存のタクソノミー構造内での修正は以下のプロセスを用いて行なうことができる。
ａ．ユーザは、新しいカテゴリを作成するか、タクソノミーの構造を変更するか、またはコンテンツを分類する。
ｂ．システムは、新しく追加された任意のカテゴリを含む、既存の未評価／未カテゴリ化のコンテンツまたは新しく追加されたコンテンツについての提案を（一度に１つまたは一括で）生成する。
ｃ．ユーザは、提案を（一度に１つまたは一括で）受入れるかまたは拒否し、ユーザアクションは、より良い推奨を行なうようにシステムに通知する。
図５２は、ある実施形態に従ったタクソノミー修正フロー図を示す。
ある実施形態に従うと、ステップ５２００において、上述したように、システムは、ユーザが新しいカテゴリを追加するかまたは１つ以上の既存のタクソノミーを修正することを示す命令を受信することができる。次いで、システムは、ユーザが既存のコンテンツまたは新しいコンテンツを（例えば、個々にまたは一括で）当該新しく作成されたカテゴリに分類することを示す命令を受信することができる。
ある実施形態に従うと、ステップ５２０５において、システムは、新しいコンテンツおよび新しく作成されたカテゴリを含む既存のコンテンツのカテゴリ化のための提案および推奨の生成を自動的に開始することができる。
ある実施形態に従うと、ステップ５２１０において、システムは、ユーザが当該生成された提案を（例えば、一度に１つまたは一括で）受入れるかまたは拒否することを示す命令を受信することができる。
このように、ある実施形態に従うと、ステップ５２１５において、ユーザアクションを示す命令は、システムに対して、当該ユーザアクションから学習してより良い推奨を行なうように通知する。システムは、ＭＬおよびＡＩに基づいて、カテゴリ化提案に関して記録された受入れまたは拒否に基づいて推奨を改良することができる。
一括でのコンテンツの分類
ある実施形態に従うと、以下のプロセスを用いてコンテンツを一括で分類することができる。
ａ．システムは、ユーザが、信頼度スコアに基づいて、コンテンツのセットを提案されたカテゴリにカテゴリ化／分類することを可能にする。
ｂ．あるカテゴリの場合、システムは、コンテンツアイテムごとに、予測の信頼度スコアに基づいて、推奨されたコンテンツを３つの互いに素なバケット（高、中、低）に配置することができる。
ｃ．信頼度スコアバケットは、一括でのカテゴリ化がより容易に達成されるようにコンテンツアイテムのセットをグループ化するための機構を提供する。例えば、ユーザは、高信頼度スコアバケット内のコンテンツに関するすべてのコンテンツカテゴリ化提案を受入れ得るとともに、低信頼度スコアバケット内の他のコンテンツに関するすべてのコンテンツカテゴリ化提案を拒否し得る。
ｄ．加えて、ユーザは、全体的な分類閾値構成を通じて提案の受入れ／拒否をスキップすることができる。選択される場合、システムは、ユーザが設定した閾値よりも高い推奨信頼度スコアを有するカテゴリにコンテンツを自動的に割当てることができる。
ｅ．通常、提案は、自動的に定期的に実行されるバックエンドジョブにより生成される。また、システムは、リポジトリアドミニストレータがジョブを手動でトリガすることを可能にし、結果として、推奨システムが、提案を生成するか、またはコンテンツをリポジトリに割当てられたタクソノミーに直ちに分類することとなる。
図５３は、ある実施形態に従った、サンプルタクソノミーツリーをカテゴリ図とともに示す。
図５３に示すように、ある実施形態に従うと、ユーザインターフェイス５３００のスクリーンショットに示すように、（ｉ）「カテゴリ提案を閲覧（View Category Suggestions）」５３０５というカテゴリを有するサンプルタクソノミーツリーは、スマート提案画面にユーザを導くことができる。このユーザインターフェイス５３００は、コンテンツを単独でまたは一括で分類するのを支援するように設計されている。
ある実施形態に従うと、画面内の各カテゴリは、カテゴリに加えて、提案の数を示す。例えば、コンテンツ５３１５は、いくつかの提案されたカテゴリ化５３２０とともに示すことができる。コンテンツ提案は、カテゴリ内に配置されるべきそのコンテンツの信頼度スコアに基づいて３つのバケット（高、中、低）に分割される。
図５４はさらに、ある実施形態に従った、サンプルタクソノミーツリーをカテゴリ図とともに示す。
図５４に示すように、ある実施形態に従うと、ユーザインターフェイス５４００のスクリーンショットに示すように、（ｉ）「カテゴリ提案を閲覧」というカテゴリを有するサンプルタクソノミーツリーは、ユーザをスマート提案画面に導くことができる。このユーザインターフェイス５４００は、コンテンツを単独でまたは一括で分類するのを支援するように設計されている。
図５４に示すように、ある実施形態に従うと、この例では、信頼度の高いコンテンツ５４０５および中程度のコンテンツ５４１０が選択される。「カテゴリに割当て（Assign to Category）」リンク５４１５により、ユーザは、選択した全てのコンテンツをそれぞれのカテゴリに配置することが可能となる。
ある実施形態に従うと、上述したように、高信頼度の提案および中信頼度の提案の範囲内に収まる提案を受入れることに基づいて、カテゴリ化エンジンは後続のカテゴリ化提案をさらに改良することができる。
図５５はさらに、ある実施形態に従った、サンプルタクソノミーツリーをカテゴリ図とともに示す。
図５５に示すように、ある実施形態に従うと、ユーザインターフェイス５５００のスクリーンショットに示すように、（ｉ）「カテゴリ提案を閲覧」というカテゴリを有するサンプルタクソノミーツリーは、ユーザをスマート提案画面に導くことができる。このユーザインターフェイス５５００は、コンテンツを単独でまたは一括で分類するのを支援するように設計されている。
図５５に示すように、ある実施形態に従うと、同様に、ユーザはコンテンツを選択することができる（この例では、低信頼度５５０５のスコアアイテムが選択される）。次いで、ユーザは、全ての低信頼度スコアカテゴリ化提案を拒否するオプション５５１０を選択することができる。
ある実施形態に従うと、上述したように、低信頼度提案の範囲内に収まる提案の拒否に基づいて、カテゴリ化エンジンはさらに、後続のカテゴリ化提案を改良することができる。
図５６は、ある実施形態に従った自動分類閾値図の構成を示す。
図５６に示すように、ある実施形態に従うと、ユーザインターフェイス５６００のスクリーンショットに示すように、このユーザインターフェイス５６００は、ユーザが信頼度スコアに関する自動分類閾値５６０５を設定することを支援／許可するように設計されている。
言い換えれば、ある実施形態に従うと、当該システムおよび方法がコンテンツアイテムの自動的な分類またはカテゴリ化を可能にするように構成されている場合、閾値は、当該閾値の設定値を上回る信頼度スコアを有するコンテンツアイテムがいずれもさらなるユーザ対話なしにシステムによって自動的に分類／カテゴリ化することが可能となるように、設定され得る。図示のとおり、自動分類設定を制御するためのタクソノミーレベルでの構成は、「中」信頼度スコアと「高」信頼度スコアとの間に設定される。これは、この閾値を上回る信頼度スコアを有するコンテンツが、対応するカテゴリでカテゴリ化／分類されるであろうことを示唆している。加えて、設定された閾値を下回る信頼度スコアを有するコンテンツアイテムは、自動的に破棄されるカテゴリ化／分類のオプション、または、付加的もしくは代替的には、決定に関する入力用にユーザに提示されるカテゴリ化／分類のオプション、を含み得る。
図５７は、ある実施形態に従った、リポジトリ図におけるコンテンツの（一括での）再分類をトリガするための構成を示す。
図５７に示すように、ある実施形態に従うと、ユーザインターフェイス５７００のスクリーンショットに示すように、このユーザインターフェイス５７００は、例えば標的リポジトリ５７０５内の文書の一括分類をユーザがトリガするのを支援／許可するように設計されている。
ある実施形態に従うと、例えば、スクリーンショットは、既存のリポジトリ内の（例えばコンテンツ管理システムにおける）コンテンツアイテムをバックグラウンドプロセスによって再分類することができることを示している。バックグラウンドプロセスを実行して、決定のためにユーザに提出すべき新しいカテゴリ化／分類の提案を行なうことができる。代替的には、例えば、バックグラウンドプロセスは、例えば、計算された信頼度スコアに基づいて、コンテンツアイテムの自動分類のために実行することができる。
概念およびアプローチ
様々な状況では、従来のクラスタリングアプローチはコンテンツ管理システムの観点から見るとうまく機能しない。なぜなら、以下を含むがそれらに限定されないいくつかの理由で、コンテンツを正しいカテゴリにカテゴリ化／分類することが困難であるからである。
ａ．コンテンツ管理システム内のコンテンツの数が時間とともに膨大に増加する可能性がある。
ｂ．コンテンツは様々な分野から得ることができるものであり、ドメイン固有のソリューションが機能しない可能性がある。
ｃ．タクソノミーツリーにおけるカテゴリ／ノードは制限されず、新しいカテゴリが頻繁に導入される。
ｄ．カテゴリ内に存在するコンテンツの数は１桁から数千桁の数まで様々であり得るとともに、同じコンテンツが複数のカテゴリに割当てられ得る。
ｅ．あるカテゴリに存在するコンテンツは意味的に互いに近くない可能性があり、同じカテゴリを共有する同様のコンテンツからなる複数の互いに素なサブセットが存在する可能性がある。
ｆ．最近傍アプローチは正確であり得るが、大量のデータを考慮するとスケーラブルではあり得ない。
ｇ．従来の分類アルゴリズムは、カテゴリへのコンテンツの分配が不均等であるとともにラベル付けされたデータが不十分であるので、このようなシナリオでは機能しない可能性がある。
ｈ．従来のクラスタリングアプローチは適切ではない可能性がある。なぜなら、ますます多くのコンテンツが追加されるにつれてクラスタが任意のサイズおよび形状にまで大きくなる可能性があり、クラスタを再構築するにはクラスタに存在するデータ点（コンテンツ）全体にわたるパスが必要となるからであり、これはスケーラビリティの点で許容し得ないものである。
図５８は、ある実施形態に従った、クラスタを任意の形状にすることができる従来のクラスタリングに付随する問題を示す。
ある実施形態に従うと、データ点Ｎ５８０５が、クラスタ１ ５８００およびクラスタ２ ５８１０を含むクラスタマップに示されている。記載の実施形態から、データ点Ｎ５８０５がクラスタ１の一部であるはずであることが明確に視認可能である。しかしながら、実質的には、Ｎからクラスタ２の中心までの距離は実際にはＮからクラスタ１の中心までの距離よりも短い。これは、クラスタ２がより正確であるように見えることを示唆している。
ある実施形態に従うと、精度およびスケーラビリティにともに留意すると、記載したアプローチは汎用の密度ベースのシングルパスマイクロクラスタリングを提供するものであり、（精度に関して）任意の形状のクラスタを発見し、（スケーラビリティの観点から）過去のデータを調べることなくクラスタを再整形し、直近のデータから継続的に学習して進化させるとともに新しいコンテンツのカテゴリを一括で正確に予測することができ、これにより、コンテンツを正しいカテゴリにカテゴリ化する時間および労力を減らすことができる。
適応マイクロクラスタリング
ある実施形態に従うと、記載したアプローチは、（１）文書から特徴を抽出し、クラスタを作成する学習段階、および、（２）新しいコンテンツを自動的に分類する予測段階という２つの部分または局面を含む。
１．文書から特徴を抽出
ある実施形態に従うと、文書から特徴を抽出することは、クラスタ（マイクロクラスタ）を作成および更新することを含む。このステップでは、クラスタをより適切に表現できれば、システムの精度がより優れたものになる。図５９で説明するように、単一のクラスタ中心は単独ではクラスタウェル全体を表現しない可能性もあり、マイクロクラスタがメインクラスタの内側に付加的に形成され得る。
図５９は、ある実施形態に従ったマイクロクラスタリングを示す。上述の図５８と同じ例では、より大きいクラスタである図５８のクラスタ１は、ここでは、３つの点（例えば、マイクロクラスタ）、すなわちクラスタ１ ５９００、クラスタ１′５９０１、およびクラスタ１′′５９０２で表わされている。このとき、新しいデータ点Ｎ５９０５は、Ｎに最も近い点がクラスタ２ ５９１０ではなくクラスタ１′５９０１であるので、クラスタ１に属するものとしてカテゴリ化されるだろう。
ある実施形態に従うと、以下に記載するように、クラスタを更新し、クラスタ内のマイクロクラスタを分割するために実行されるステップがいくつかある。
Ａ．テキストからの特徴ベクトルの生成
ある実施形態に従うと、第１のステップは、未処理のテキスト文書をさらなる処理のために特徴ベクトルに変換するためのステップである。テキストスニペットの特徴空間は、疎なテキスト特徴（例えば、２００ｋ次元）を出力するトピックモデリングシステムを通じて生成される。その後、テキスト特徴が、高速処理のために、ランダム投影技術を用いて、より低次元（２０４８）の高密度特徴空間に投影される。コンテンツが疎である場合、アプローチは、タクソノミー自体を定義するのに用いられる名前および記述ならびに他のメタデータのようなコンテンツモデル自体で機能する。
Ｂ．テキストからの名前付き実体の抽出
ある実施形態に従うと、名前付き実体認識（named entity recognizer：ＮＥＲ）システムは、人々、組織、顧客製品および国々の名前、書籍または音楽アルバムのタイトルなどの実体を自動的に抽出するタスクを実行する。
ある実施形態に従うと、名前付き実体認識により、システムは、構造化されていないテキストから主要情報を取得し、それらをユーザ定義カテゴリに分類することができる。例えば、医薬品産業からの文書にしばしば医薬品、化学物質の名称が言及されている一方で、出版社の文書に本、著者、架空登場人物などの名前が含まれている場合について考察する。このような文書は、実体を見るだけでそれぞれのドメインに分類することができる。ユーザ定義カテゴリにおける名前付き実体の分布に関して文書の名前付き実体スコアを考慮することにより、分類タスクをより効果的、よりスケーラブル、かつ、より正確にすることができる。
Ｃ．テキストからのトピックの抽出
ある実施形態に従うと、トピック抽出は、用語頻度を識別し、同様の単語パターンをグループ化することによって文書からキーワードおよびキーフレーズを自動的に発見するものである。ユーザ定義タクソノミーツリーは、水平方向および垂直方向の両方に大きく成長し得るとともに、統計的なトピック抽出モデルをマクロレベル分類に用いて、文書についてのカテゴリを提案しながらツリー内の高次ノードと、それに続いて、特徴ベースのマイクロ分類子とを選択することができる。
例えば、衣料品の顧客は、「女性＞衣類＞民族＞サリー＞コットン＞チャンデリ（chanderi）」および「家庭用リネン＞ベッド用リネン＞ベッドカバー＞コットン＞ハイバ（Haiba）」のようなタクソノミーツリー階層を有してもよい。この例では、マクロレベルカテゴリを決定するために、各文書をリーフレベルで比較する必要がないことは明らかであり（すべての文書は女性用衣類またはベッド用リネン下に入り）、むしろ、上位３位～４位のノードにおける項目のトピック分布を調べることによって、高レベルカテゴリを選択することができ、さらには、マイクロレベル（特徴比較）分類子は、（チャンデリまたはバナラシのような）サリーまたはベッドカバー（ハイバ）のタイプを提案するのを支援することができる。
図６０は、ある実施形態に従った、衣料品顧客についてのサンプルトピック分布を示す。
ある実施形態に従うと、図示のとおり、トピック分布は、例えば、衣類クラスタ６００１と、家庭用リネンクラスタ６０２０と、家庭用装飾クラスタ６０３０とを含む。各クラスタの周囲には例示的なデータ点が示されている。
Ｄ．クラスタの作成
ある実施形態に従うと、すべてのカテゴリ（タクソノミーツリーにおけるノード）にクラスタが当てられる。クラスタは、そのクラスタ内に存在するコンテンツに関連付けられた特徴ベクトルの要約された特徴空間表現と、そのクラスタ内の文書中に存在する名前付き実体の分布と、そのクラスタの文書から抽出されたトピックの分布とを含み得る。
ある実施形態に従うと、（抽出された特徴ベクトル、カテゴリメタデータからの名前付き実体およびトピックで初期化される）カテゴリとともにクラスタが作成される。
Ｅ．クラスタの定義
ある実施形態に従うと、クラスタは以下のプロセスを用いて定義することができる。クラスタ特徴：ある実施形態に従うと、クラスタは重心および半径の観点で定義される。重心＝クラスタ内に存在するコンテンツの特徴ベクトルの平均。半径＝クラスタ重心までのメンバ特徴ベクトルの平均距離。半径が小さいほど、クラスタ内に存在するコンテンツ同士が密接に関連していることを示している。
ある実施形態に従うと、名前付き実体のリストが頻度とともにクラスタにアタッチされている。分布は、クラスタに属する各文書から上位ｎ位の名前付き実体を選択することによって作成される。
ある実施形態に従うと、名前付き実体と同様に、最も頻繁なトピックがクラスタにアタッチされていることを特定するトピック分布を定義することができる。トピック分布は、各文書から最も関連のあるトピックを抽出することによっても作成される。
図６１は、ある実施形態に従った、クラスタ半径の視覚化を示す。
ある実施形態に従うと、図６１は、２つの例示的なクラスタであるクラスタ１ ６１００およびクラスタ２ ６１１０を示す。図示のとおり、クラスタ１はクラスタ２よりも小さい半径を有する。上述したように、半径が小さいほど、クラスタ内に存在するコンテンツが密接に関連していることを意味する。
Ｆ．クラスタ特徴を更新
ある実施形態に従うと、図６１に示すように、高密度で小半径のクラスタ（左側）は、可能な限り最良の精度を達成することができる。この目標を達成するために、ますます多くのコンテンツ（例えば、新しいコンテンツ）が追加されるのに応じてクラスタがマイクロクラスタに分割される。新しいコンテンツにより、結果としてマイクロクラスタ半径が拡大する場合、これらの新しいコンテンツはマイクロクラスタに直ちに追加される必要はなく、代わりに単に潜在的なマイクロクラスタとして識別され得るに過ぎない。
ある実施形態に従うと、その後、コンテンツが成長するにつれて、潜在的なマイクロクラスタは、ますます多くの同様のコンテンツが追加されるのに応じてコアマイクロクラスタに成長し得るか、または、時間の経過に応じて減衰係数により外れ値として無視されることとなる。このマイクロクラスタリングのアプローチは、カテゴリ内の関連コンテンツの互いに素なサブセットを発見するのに役立つ。
クラスタの重心および半径は、（過去のデータを調べることなく）オンライン形式で更新することができる。
図６２は、ある実施形態に従ったクラスタ表現を示す。
ある実施形態に従うと、図６２は、３つの典型的なクラスタであるクラスタ１ ６２００、クラスタ２ ６２１０、およびクラスタ３ ６２３０を示す。図示のように、各クラスタの半径は異なっており、各半径は、各クラスタ内のコンテンツアイテムがどれだけ密接に関連しているかを反映している。上述したように、半径が小さいほど、クラスタ内に存在するコンテンツが密接に関連していることを意味する。
ある実施形態に従うと、コンテンツが成長するにつれて、潜在的なマイクロクラスタは、ますます多くの同様のコンテンツが追加されるのに応じてコアマイクロクラスタに成長し得るか、または、時間の経過に応じて減衰係数によりＯ１ ６２４０およびＯ２ ６２４１等の外れ値として無視されることとなる。このマイクロクラスタリングのアプローチは、カテゴリ内の関連コンテンツの互いに素なサブセットを発見するのに役立つ。
ある実施形態に従うと、新しい文書Ｄがクラスタ内に配置されると、Ｄからトピックおよび名前付き実体を抽出することにより、当該クラスタについて、関連付けられた名前付き実体分布およびトピック分布が更新される。
２．新しいコンテンツを関連カテゴリに分類
ある実施形態に従うと、分類は、マクロレベル分類段階およびマイクロレベル分類段階を含む、以下で説明するような２段階プロセスである。
Ａ．マクロレベル分類
ある実施形態に従うと、上述したように、各カテゴリノードは、それぞれに関連付けられたトピック分布および名前付き実体分布を有する。文書がアップロードされると、まず、トピックおよび名前付き実体が文書から抽出され、条件付き確率スコアがタクソノミーツリー内の高レベルカテゴリごとに計算される。
図６３は、ある実施形態に従ったカテゴリ化のマクロ段階を示す。より具体的には、図６３は、文書のトピック分布および名前付き実体分布が高レベルクラスタノード（すなわちノード６３００～６３０９）と一致している実施形態を示す。
ある実施形態に従うと、例えば「シャツ」、「コットン」などのトピックのリスト（および文書に対する各トピックの重み）を想定すると、スコア関数は、文書が「女性用衣類」というカテゴリに属し得る機会であるものとみなすことができる。ここで、ｎ個のトピック（例えば、topic-1、topic-2、…、topic-n）およびトピックごとの重み（weighttopic-1、weighttopic-2、…、weighttopic-n）を有する文書Ｄを想定すると、カテゴリCatg-Cに関するその文書の結合確率は以下のように計算することができる。
Figure 2023545945000008
Ｂ．マイクロレベル分類
ある実施形態に従うと、この段階中、特徴比較は、マクロで選択されたカテゴリの子ノードに存在するすべての文書に関してこれら文書をより細かいレベルに分類するために実行される。
図６４は、マクロステップを通じてより高レベルのカテゴリが選択されたときのカテゴリ化を示す。マイクロステップでは、ある実施形態に従うと、選択されたツリー下のカテゴリ、衣類６４０１－－＞女性６４０５である選択されたツリー、および、カテゴリ６４１０～６４１５である選択されたツリー下のカテゴリが、特徴空間内で拡張されて比較される。
ある実施形態に従うと、新しいコンテンツをカテゴリにカテゴリ化／分類するために、コンテンツおよび利用可能なマイクロクラスタのコサイン類似度を特徴空間において計算することができ、最も類似するマイクロクラスタが属するカテゴリを新しい項目として推奨することができる。
ある実施形態に従うと、例えばコンテンツユーザによって新しいカテゴリが導入され、ますます多くのコンテンツがカテゴリに配置されるのに応じて、マイクロクラスタの数は非常に高い値に到達し得る。新しいコンテンツを高次元特徴空間内のすべての既存のマイクロクラスタと比較することは、リソース集約的であり得るとともに、システムの性能を損なう可能性がある。この問題は、データストリームクラスタリングにおいて用いられる減衰窓モデルアプローチで解決することができる。
減衰窓モデル（経時的な重み減衰）：
ある実施形態に従うと、減衰窓モデル（経時的な重み減衰）の使用時、各コンテンツは、その到着時間に応じた重みに関連付けられている。新しいコンテンツが到着すると、可能な限り高い重みが割当てられ、この重みは経時関数に従って時間の経過に応じて（例えば、指数関数的に）減少する。減衰された窓モデルのために典型的に用いられる経時関数は指数関数的なフェージング関数である。マイクロクラスタの重みは、そこに存在するコンテンツの重みの合計として計算することができる。新しいコンテンツを既存のマイクロクラスタと比較しながら、まず重みに基づいてマイクロクラスタを（降順で）ソートし、次いで、特徴類似度計算のために上位ｎ個のマイクロクラスタだけを選択することができる。このように、直近に使用された高密度のマイクロクラスタは、より使用頻度の低いマイクロクラスタよりも高い優先度を得ることができる。
図６５は、ある実施形態に従った、クラスタ重みが時間の経過とともにどのように減衰し得るかを示すとともに減衰窓モデルの一例を示す。
ある実施形態に従うと、図６５に示すように、カテゴリ１ ６５１０、カテゴリ２ ６５２０およびカテゴリ３ ６５３０といった３つのカテゴリが示される。ある実施形態に従うと、これらのカテゴリに適用される減衰関数は以下の通りである。
Figure 2023545945000009
ある実施形態に従って、上記方程式について考察すると、カテゴリ１ ６５００が、図中に太線のスコアボックス６５０１として示すようにｔ１で追加された１００の項目を有する場合、カテゴリ１はｔ１において１００のスコアを有することとなるが、これは図示のとおり減衰されることとなる。ｔ５までにカテゴリ１についてそれ以上項目が追加されない場合、減衰関数によって計算される１００の項目についてのスコアは６．２５となるだろう。
ある実施形態に従って、上記方程式について考察すると、カテゴリ２ ６５１０が、太線のスコアボックス６５１１、６５１２、および６５１３として示すようにｔ１で追加された３０の項目とｔ２で追加された２０の項目とｔ４で追加された１０の項目とを有する場合、カテゴリ２は、ｔ１で３０のスコア、ｔ２で３５のスコア、ｔ３で１７．５のスコア、およびｔ４で１７．７５のスコアを有することとなる。さらに、ｔ５までにカテゴリ２についてそれ以上項目が追加されない場合、６０の項目についてのスコアは９．３７５となるだろう。
ある実施形態に従って、上記方程式について考察すると、カテゴリ３ ６５１０が、太線のスコアボックス６５２１、６５２２、６５２３および６５２４として示すようにｔ２で追加された１０の項目、ｔ３で追加された１０の項目、ｔ４で追加された１０の項目、およびｔ５で追加された１０の項目を有する場合、カテゴリ３は、４０の項目に関して、ｔ１で０のスコア、ｔ２で１０のスコア、ｔ３で１５のスコア、ｔ４で１７．５のスコア、およびｔ５で１８．７５のスコアを有することとなる。
ユーザ挙動からの学習
ある実施形態に従うと、ユーザは、コンテンツカテゴリ化／分類に関してシステムによって提供される提案を受入れる／拒否するオプションを有する。システムは、ユーザアクションに応じて、例えば、以下の方法で機械学習データベースに追加することができる。
ユーザが提案を受入れる場合
ある実施形態に従うと、直近の受入れにより既存の信号が強化される。コンテンツはこのときカテゴリクラスタの一部となっており、コンテンツ特徴はクラスタ特徴に含まれている。これはクラスタ特徴の直接的な平均の更新ではなく、減衰係数はこの更新において主要な役割を果たす。前のクラスタ特徴は部分的に減衰され、次いで、直近に配置されたコンテンツ特徴に追加されることで、更新されたクラスタ特徴が計算される。これにより、システムが、次のバッチを分類しながら、直近に追加されたコンテンツに対してより多くの重みを与えることが可能となる。名前付き実体およびトピックの頻度もまたカテゴリに関して更新される。
ユーザが提案を拒否する場合
ある実施形態に従うと、ユーザが特定のコンテンツのカテゴリ化／分類を拒否する場合、このような拒否は最終的に２つのシナリオをもたらす可能性がある。
ｉ．ユーザが項目を拒否し、何らかの別のカテゴリに配置する。このアクションは受入れと同じ効果をもたらすこととなり、この時点でユーザによってコンテンツが配置されているカテゴリは、重み付けされたコンテンツ特徴を消費することとなり、更新されたクラスタ特徴は、信頼度がより高い同様のコンテンツを推進するよう推奨し始めるだろう。
ｉｉ．ユーザがコンテンツを拒否し、コンテンツが「カテゴリ化されない」ままとなる。この状況では、システムは、コンテンツ（または同様のコンテンツ）がクラスタのいずれにも寄与しないので当該コンテンツ（または同様のコンテンツ）で何をすべきかを知ることができない。このようなコンテンツを追跡して記録するために、「シャドウクラスタ」と呼ばれるカテゴリが導入される。シャドウクラスタは、以前に拒否されたすべての提案のうち拒否されたコンテンツおよびカテゴリ化されていないコンテンツを含む。新しいコンテンツが到着したとき、この新しいコンテンツがシャドウクラスタで最も高い類似性スコアを得ている場合、システムは当該コンテンツについて如何なるカテゴリも提案しない。
図６６は、ある実施形態に従った、シャドウクラスタがどのように現れ得るかを示すグラフ図である。
ある実施形態に従うと、上述したように、クラスタ１ ６６００、クラスタ２ ６６１０、およびクラスタ３ ６６２０に、割当て／カテゴリ化／分類がなされたコンテンツアイテムをポピュレートすることができる。
しかしながら、ある実施形態に従うと、上述のように、時間の経過に応じてシャドウクラスタ６６４０が成長する可能性もある。これらのシャドウクラスタは、形状およびサイズが無期限に成長する可能性があり、結果として、システムは、新しく作成されたコンテンツの大部分についてのカテゴリを提案しなくなる可能性がある。このようなシナリオを回避するために、同じマイクロクラスタリングアプローチをシャドウクラスタに適用することができる。マイクロクラスタリングは、シャドウクラスタ内の同様のカテゴリ化されていないコンテンツをグループ化するのに役立つ。
図６７は、ある実施形態に従った、シャドウクラスタがどのように現れ得るかを示すグラフ図である。
より具体的には、図６７は、ある実施形態に従って、シャドウクラスタ１ ６７００、シャドウクラスタ２ ６７１０、およびシャドウクラスタ３ ６７２０がシャドウクラスタ内のマイクロクラスタとして生成可能であることを示す。
ある実施形態に従うと、シャドウクラスタ内のマイクロクラスタが成長すると、推奨システム（例えばカテゴリ化エンジン）は、このような新しいマイクロクラスタについての提案の生成を開始し、これらの提案をユーザに提供することができる。このようなカテゴリ化されていないコンテンツは、システムで用いられる最も頻繁なトピックに基づいてカテゴリを形成し当該カテゴリの名前を提案し得る。ユーザは、新しいカテゴリの作成オプションによりこれらのコンテンツから新しいカテゴリを形成することができる。
図６８は、ある実施形態に従った、カテゴリ化されていないコンテンツから新しいカテゴリを作成するようユーザに提案することを示す。
ある実施形態に従うと、図６８には、ユーザインターフェイス６８００の例示的なスクリーンショットが示されている。図示の実施形態では、カテゴリ化されていないコンテンツ６８０５が表示されている。ユーザには、このようなカテゴリ化されていないコンテンツについての新しいカテゴリ６８１０を（例えば、タクソノミー内に）作成する提案を提示することができる。
図６９は、ある実施形態に従った、コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のための方法のフローチャートである。
ある実施形態に従うと、ステップ６９００において、当該方法は、プロセッサを含みコンテンツ管理システムへのアクセスを提供する１つ以上のコンピュータを設けることができる。
ある実施形態に従うと、ステップ６９１０において、当該方法は、１つ以上のコンピュータにおいてコンテンツカテゴリ化エンジンを設けることができ、当該コンテンツカテゴリ化エンジンはタクソノミーにアクセスすることができる。
ある実施形態に従うと、ステップ６９２０において、当該方法は、コンテンツカテゴリ化エンジンの推奨システムにより、コンテンツ管理システムにおけるコンテンツから特徴ベクトルを生成することができ、当該推奨システムは、コンテンツカテゴリ化エンジンのデータベースおよびＡＩ／ＭＬエンジンにアクセスすることができ、特徴ベクトルの生成は、少なくともタクソノミー内で事前にカテゴリ化されたコンテンツの評価に基づく。
ある実施形態に従うと、ステップ６９３０において、当該方法は、新しいコンテンツをタクソノミーにカテゴリ化する際に当該生成された特徴ベクトルを利用することができる。
特定の実施形態について説明してきたが、さまざまな変形例、変更例、代替構成例、および同等例が実現可能である。本開示に記載される実装例は、いくつかの特定のデータ処理環境内の動作に限定されず、複数のデータ処理環境内で自由に実施することができる。加えて、実装例を特定の一連のトランザクションおよびステップを用いて説明してきたが、これが限定を意図しているのではないことは当業者には明らかとなるはずである。いくつかのフローチャートは動作を逐次的プロセスとして説明しているが、これらの動作のうちの多くは並列または同時に実行できる。加えて、動作の順序は並べ替えられてもよい。プロセスは図に含まれない追加のステップを有することもある。上述の実装例の各種特徴および局面は、個別に用いられてもよく、または共に用いられてもよい。
さらに、本開示に記載の実装例をハードウェアとソフトウェアとの特定の組合わせを用いて説明してきたが、ハードウェアとソフトウェアとの他の組合わせも可能であることが理解されるはずである。本明細書で説明するいくつかの実装例は、ハードウェアでのみ、またはソフトウェアでのみ、またはそれらの組み合わせを用いて実装されてもよい。本明細書に記載のさまざまなプロセスは、同じプロセッサまたは任意の組み合わせの異なるプロセッサ上で実現できる。
デバイス、システム、コンポーネントまたはモジュールが特定の動作または機能を実行するように構成されるものとして記載されている場合、そのような構成は、たとえば、動作を実行するように電子回路を設計することにより、動作を実行するようにプログラミング可能な電子回路（マイクロプロセッサなど）をプログラミングすることにより、たとえば、コンピュータ命令もしくはコードを実行することなどにより、または、非一時的なメモリ媒体に格納されたコードもしくは命令またはその任意の組合わせを実行するようにプログラミングされたプロセッサもしくはコアを設計することにより、達成され得る。プロセスは、プロセス間通信のための従来の技術を含むがこれに限定されないさまざまな技術を用いて通信することができ、異なる対のプロセスは異なる技術を用いてもよく、または、同じ対のプロセスは異なる時間に異なる技術を用いてもよい。
実施形態が十分に理解されるように本開示では特定の詳細事項を示している。しかしながら、実施形態はこれらの特定の詳細事項なしでも実施され得る。たとえば、周知の回路、プロセス、アルゴリズム、構造および技術は、実施形態が曖昧にならないようにするために不必要な詳細事項なしで示されている。本記載は例示的な実施形態のみを提供しており、他の実施形態の範囲、適用可能性、または構成を限定することを意図するものではない。むしろ、実施形態の上記説明は、各種実施形態を実現することを可能にする説明を当業者に提供するだろう。各種変更は要素の機能および構成の範囲内で行なってもよい。
したがって、明細書および添付の図面は、限定的な意味ではなく例示的なものとみなされるべきである。しかしながら、開示されているより広範な精神および範囲から逸脱することなく、追加、削減、削除、ならびに他の修正および変更がこれらになされ得ることは明らかであるだろう。このように、特定の実装例を説明してきたが、これらは限定を意図するものではなく、さまざまな変更例および同等例は開示の範囲に含まれる。
本明細書に記載の実施形態は、１つ以上の汎用または専用のデジタルコンピュータ、コンピューティングデバイス、マシンもしくはマイクロプロセッサ、または、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／もしくはコンピュータ可読記憶媒体を含む他のタイプのコンピュータを用いて実装され得る。ソフトウェア技術の当業者には明らかであるように、適切なソフトウェアコーディングは、本開示の教示に基づいて熟練したプログラマによって容易に準備され得る。
いくつかの実施形態に従うと、本明細書に記載の特徴は、クラウドコンピューティングシステムの一部として、またはそのサービスとして、クラウド環境において全体的または部分的に実装され得る。当該クラウドコンピューティングシステムは、構成可能なコンピューティングリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、およびサービス）の共有プールへのオンデマンドのネットワークアクセスを可能にするとともに、例えば、国立標準技術研究所によって定義されるような特性、例えば、オンデマンドのセルフサービス、ブロードネットワークアクセス、リソースプーリング、迅速な拡張性、計測サービスなどを含み得る。例示的なクラウド展開モデルは、パブリッククラウド、プライベートクラウド、およびハイブリッドクラウドを含み得るのに対して、例示的なクラウドサービスモデルは、サービスとしてのソフトウェア（Software as a Service：ＳａａＳ）、サービスとしてのプラットフォーム（ＰａａＳ）、サービスとしてのデータベース（Database as a Service：ＤＢａａＳ）、およびサービスとしてのインフラストラクチャ（ＩａａＳ）を含み得る。ある実施形態に従うと、特に規定のない限り、クラウドは、本明細書で用いられる場合、パブリッククラウド、プライベートクラウド、およびハイブリッドクラウドの実施形態、ならびに、クラウドＳａａＳ、クラウドＤＢａａＳ、クラウドＰａａＳおよびクラウドＩａａＳを含むがこれらに限定されないすべてのクラウド展開モデルを包含し得る。
いくつかの実施形態に従うと、本明細書に記載のプロセスのいずれかを実行するようにコンピュータをプログラムするために使用可能な命令が格納されている非一時的なコンピュータ可読記憶媒体であるコンピュータプログラム製品が提供され得る。このような記憶媒体の例は、ハードディスクドライブ、ハードディスク、ハードドライブ、固定ディスク、または、他の電気機械データストレージデバイス、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気カードもしくは光カード、ナノシステム、または、命令および／もしくはデータの非一時的な格納に適した他のタイプの記憶媒体またはデバイスを含み得るが、これらに限定されない。
上述の説明は、例示および説明を目的として提供されたものであって、網羅的であること、または、本発明を開示された厳密な形態に限定することを意図するものではない。多くの修正および変形が当業者にとって明らかになるだろう。上述の実施形態は、本教示の原理およびそれらの実際の適用を最もよく説明するために選択および記載されており、これにより、当業者は、企図される特定の用途に適したさまざまな実施形態およびさまざまな変形例を理解することができる。範囲は、添付の特許請求の範囲およびそれらの同等例によって定義されることが意図されている。

Claims (20)

  1. コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムであって、
    プロセッサを含み、コンテンツ管理システムへのアクセスを提供する１つ以上のコンピュータと、
    前記１つ以上のコンピュータに設けられるとともにタクソノミーにアクセスできるコンテンツカテゴリ化エンジンと、
    前記コンテンツカテゴリ化エンジンを含む推奨システムとを備え、前記推奨システムは、前記コンテンツ管理システムにおいてコンテンツから特徴ベクトルを生成し、前記推奨システムは、前記コンテンツカテゴリ化エンジンのデータベースにアクセスでき、
    前記特徴ベクトルの生成は、少なくとも、前記タクソノミー内における事前にカテゴリ化されたコンテンツの評価に基づいており、
    前記生成された特徴ベクトルは、新しいコンテンツを前記タクソノミーにカテゴリ化するのに利用される、システム。
  2. 前記推奨システムは、事前にカテゴリ化されたコンテンツに基づいて特徴空間にクラスタを作成する、請求項１に記載のシステム。
  3. 前記推奨システムは、前記クラスタからの特徴空間距離計算により前記タクソノミーへの前記新しいコンテンツについての１つ以上の推奨を生成する、請求項２に記載のシステム。
  4. 前記推奨システムは、新しいタクソノミーを作成するかまたは前記タクソノミーを修正するために用いられる、請求項１に記載のシステム。
  5. 前記コンテンツカテゴリ化エンジンの前記データベースは、以前のカテゴリ化推奨のユーザ受入れについての履歴記録を含み、
    前記コンテンツカテゴリ化エンジンの前記データベースは、以前のカテゴリ化推奨のユーザ拒否についての履歴記録を含む、請求項１に記載のシステム。
  6. 前記推奨システムは、以前のカテゴリ化記録のユーザ受入れについての前記履歴記録および以前のカテゴリ化推奨のユーザ拒否についての前記履歴記録に基づいて、前記タクソノミーへの前記新しいコンテンツについての１つ以上の推奨を生成する、請求項５に記載のシステム。
  7. 前記推奨システムは、複数のカテゴリ化されていないコンテンツアイテムについて前記タクソノミー内に新しいカテゴリの作成のための推奨を生成する、請求項１に記載のシステム。
  8. コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のための方法であって、
    プロセッサを含み、コンテンツ管理システムへのアクセスを提供する１つ以上のコンピュータを設けるステップと、
    タクソノミーにアクセスできるコンテンツカテゴリ化エンジンを前記１つ以上のコンピュータに設けるステップと、
    前記コンテンツカテゴリ化エンジンを含む推奨システムによって、前記コンテンツ管理システムにおいてコンテンツから特徴ベクトルを生成するステップとを含み、前記推奨システムは、前記コンテンツカテゴリ化エンジンのデータベースにアクセスでき、前記特徴ベクトルを生成するステップは、少なくとも、前記タクソノミー内における事前にカテゴリ化されたコンテンツの評価に基づいており、前記方法はさらに、
    新しいコンテンツを前記タクソノミーにカテゴリ化するのに、前記生成された特徴ベクトルを利用するステップを含む、方法。
  9. 前記推奨システムによって、前記タクソノミー内における前記事前にカテゴリ化されたコンテンツに基づいて特徴空間にクラスタを作成するステップをさらに含む、請求項８に記載の方法。
  10. 前記推奨システムによって、前記クラスタからの特徴空間距離計算により前記タクソノミーへの前記新しいコンテンツについての１つ以上の推奨を生成するステップをさらに含む、請求項９に記載の方法。
  11. 前記推奨システムは、新しいタクソノミーを作成するかまたは前記タクソノミーを修正するために用いられる、請求項８に記載の方法。
  12. 前記コンテンツカテゴリ化エンジンの前記データベースは、以前のカテゴリ化推奨のユーザ受入れについての履歴記録を含み、
    前記コンテンツカテゴリ化エンジンの前記データベースは、以前のカテゴリ化推奨のユーザ拒否についての履歴記録を含む、請求項８に記載の方法。
  13. 前記推奨システムによって、以前のカテゴリ化記録のユーザ受入れについての前記履歴記録および以前のカテゴリ化推奨のユーザ拒否についての前記履歴記録に基づいて、前記タクソノミーへの前記新しいコンテンツについての１つ以上の推奨を生成するステップをさらに含む、請求項１２に記載の方法。
  14. 前記推奨システムによって、複数のカテゴリ化されていないコンテンツアイテムについて前記タクソノミー内に新しいカテゴリの作成のための推奨を生成するステップをさらに含む、請求項８に記載の方法。
  15. 命令が格納された非一時的なコンピュータ可読記憶媒体であって、前記命令は、コンピュータによって読出されて実行されると、前記コンピュータに以下のステップを実行させ、前記以下のステップは、
    プロセッサを含み、コンテンツ管理システムへのアクセスを提供する１つ以上のコンピュータを設けるステップと、
    タクソノミーにアクセスできるコンテンツカテゴリ化エンジンを前記１つ以上のコンピュータに設けるステップと、
    前記コンテンツカテゴリ化エンジンを含む推奨システムによって、前記コンテンツ管理システムにおいてコンテンツから特徴ベクトルを生成するステップとを含み、前記推奨システムは前記コンテンツカテゴリ化エンジンのデータベースにアクセスでき、前記特徴ベクトルを生成するステップは、少なくとも、前記タクソノミー内における事前にカテゴリ化されたコンテンツの評価に基づいており、前記以下のステップはさらに、
    新しいコンテンツを前記タクソノミーにカテゴリ化するのに、前記生成された特徴ベクトルを利用するステップを含む、非一時的なコンピュータ可読記憶媒体。
  16. 前記以下のステップはさらに、
    前記推奨システムによって、前記タクソノミー内における前記事前にカテゴリ化されたコンテンツに基づいて特徴空間にクラスタを作成するステップをさらに含む、請求項１５に記載の非一時的なコンピュータ可読記憶媒体。
  17. 前記推奨システムによって、前記クラスタからの特徴空間距離計算により前記タクソノミーへの前記新しいコンテンツについての１つ以上の推奨を生成するステップをさらに含む、請求項１６に記載の非一時的なコンピュータ可読記憶媒体。
  18. 前記推奨システムは、新しいタクソノミーを作成するかまたは前記タクソノミーを修正するために用いられる、請求項１５に記載の非一時的なコンピュータ可読記憶媒体。
  19. 前記コンテンツカテゴリ化エンジンの前記データベースは、以前のカテゴリ化推奨のユーザ受入れについての履歴記録を含み、
    前記コンテンツカテゴリ化エンジンの前記データベースは、以前のカテゴリ化推奨のユーザ拒否についての履歴記録を含む、請求項１５に記載の非一時的なコンピュータ可読記憶媒体。
  20. 前記以下のステップはさらに、
    前記推奨システムによって、以前のカテゴリ化記録のユーザ受入れについての前記履歴記録および以前のカテゴリ化推奨のユーザ拒否についての前記履歴記録に基づいて、前記タクソノミーへの前記新しいコンテンツについての１つ以上の推奨を生成するステップを含む、請求項１９に記載の非一時的なコンピュータ可読記憶媒体。
JP2023519188A 2020-09-28 2021-09-28 コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法 Pending JP2023545945A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202063084174P 2020-09-28 2020-09-28
US63/084,174 2020-09-28
US17/486,524 US20220012268A1 (en) 2018-10-18 2021-09-27 System and method for smart categorization of content in a content management system
US17/486,524 2021-09-27
PCT/US2021/052351 WO2022067236A1 (en) 2020-09-28 2021-09-28 System and method for smart categorization of content in a content management system

Publications (2)

Publication Number Publication Date
JP2023545945A true JP2023545945A (ja) 2023-11-01
JPWO2022067236A5 JPWO2022067236A5 (ja) 2024-04-19

Family

ID=78483487

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023519188A Pending JP2023545945A (ja) 2020-09-28 2021-09-28 コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法

Country Status (3)

Country Link
EP (1) EP4217887A1 (ja)
JP (1) JP2023545945A (ja)
WO (1) WO2022067236A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220309428A1 (en) * 2021-03-25 2022-09-29 Reveal Why, LLC Generating and presenting an interactive audit report
US20240104632A1 (en) * 2022-09-27 2024-03-28 Maplebear Inc. (Dba Instacart) Item attribute determination using a co-engagement graph
CN115333858B (zh) * 2022-10-11 2022-12-23 北京华云安信息技术有限公司 登录页面破解方法、装置、设备以及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10963503B2 (en) * 2017-06-06 2021-03-30 SparkCognition, Inc. Generation of document classifiers
US10936970B2 (en) * 2017-08-31 2021-03-02 Accenture Global Solutions Limited Machine learning document processing

Also Published As

Publication number Publication date
WO2022067236A1 (en) 2022-03-31
EP4217887A1 (en) 2023-08-02

Similar Documents

Publication Publication Date Title
JP7411651B2 (ja) コンテンツアイテム推奨をランク付けするための技術
US11023441B2 (en) Distributed storage and processing of hierarchical data structures
US20220012268A1 (en) System and method for smart categorization of content in a content management system
US11200248B2 (en) Techniques for facilitating the joining of datasets
US11704321B2 (en) Techniques for relationship discovery between datasets
US11163527B2 (en) Techniques for dataset similarity discovery
US11379506B2 (en) Techniques for similarity analysis and data enrichment using knowledge sources
US10915233B2 (en) Automated entity correlation and classification across heterogeneous datasets
US10891272B2 (en) Declarative language and visualization system for recommended data transformations and repairs
Martella et al. Practical graph analytics with apache giraph
JP2023545945A (ja) コンテンツ管理システムにおけるコンテンツのスマートなカテゴリ化のためのシステムおよび方法
CN116569164A (zh) 在内容管理系统中对内容进行智能归类的系统和方法
WO2022098886A1 (en) Techniques to generate and store graph models from structured and unstructured data in a cloud-based graph database system
Malavolta “Enzo Ferrari” Engineering Department
Pellegrini et al. LOD2 Deliverable 1.2: State of the Art Analysis

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240409

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240409