JP2022161031A - 予測モデルを適用して監視リストを生成する方法及びシステム - Google Patents

Abstract

【課題】信頼性を有したデータ、並びに、データを分析してデータの現在の動向及び将来の動向を決定するための信頼性を有した方法を提供する。【解決手段】コンピュータに実装された方法は、少なくとも１つのハードウェアプロセッサを使用することを有し、ハードウェアプロセッサが、１以上のエンティティに関連する複数のデータを複数のデータソースから受信し、複数のデータに予測モデルを適用して、１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、監視リストは、１以上のエンティティのそれぞれについて、エンティティの識別子、エンティティについて予測された重要指標の識別子、エンティティについて予測された重要指標に関連する値、及び、エンティティについて予測された重要指標に関連する値に基づく推奨を含み、グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する。【選択図】図３

Description

関連出願の相互参照
本出願は、２０２１年５月７日に出願された米国特許出願第１７／３１５，１２２号の継続出願であり、米国特許法第１１９条（ｅ）項に基づき、２０２０年５月７日に出願された米国仮出願第６３／０２１，５５０号及び２０２１年４月７日に出願された米国仮出願第６３／１７１，９６７号の優先権を主張し、それらの内容は参照によりその全体が本明細書に組み込まれる。

本開示は、ユーザがシングルユーザアクションに基づいて意思決定を行うことに対して支援を提供するためのシステム及び方法に関し、より具体的には、データ条件及びユーザプロファイルに応答して提供されるプッシュ通知に基づいて、ユーザが意思決定を行うことに関連した、システム、方法、及びユーザ経験、を提供することに関する。

関連技術におけるシステムでは、データアナリストが、典型的には、経済データの動向を手動で研究して分析している。例えば、それらのアナリストは、株式をいつ売買するかを手動で決定するために、あるいは、任意の所与の期間における失業率がどのようなものであるかを決定するために、データを研究し得る。

しかしながら、これらの指標を決定するために使用されるデータは、そのような独自の情報が利用し得ないことのために、信頼性が低い場合がある。例えば、特定の経済指標と必ずしも相関していないはずのデータが、データを分析する際に除去されていない可能性があり、それによって分析に不正確さが生じる。

さらに、関連技術では、ユーザは、シングルユーザアクションによって意思決定を行うためのプッシュ通知を受信し得ない場合がある。関連技術におけるアプローチは、電子メール又は他の手段によって、株価又は全体的市場パフォーマンスなどの周囲状況に関連した情報を提供し得る。しかしながら、関連技術におけるアプローチでは、複数のデータストリームが考慮されておらず、また、上述したように、データから不正確さを取り除くこともない。よって、ユーザが受信するあらゆる情報は、不正確さを内包し得るデータに基づいている。さらに、このような情報が提供された場合、ユーザは、シングルユーザアクションを提供するだけでは、意思決定を行うことができない。例えば、限定するものではないが、企業名を含む購入したい株式、株式数、購入のタイミング、１回の注文にするか複数回の注文にするか、等を含むけれどもこれらに限定されるものではない詳細な命令を、サービスプロバイダに対して提供しなければならない。このような要件は、時間が限られているユーザが所望数の取引を実行し得ないなど、ユーザにとって不便なものであり、さらに、時間的な制限により、株価の急変などのデータ条件の変化の前に取引を完了させる機会を逃す可能性がある。

よって、信頼性を有したデータ、並びに、データを分析してこのデータの現在の動向及び将来の動向を決定するための信頼性を有した方法が、要望されている。さらに、シングルアクションでユーザが購入の命令又は注文を行い得るという、満たされていないニーズがある。

態様は、少なくとも１つのハードウェアプロセッサを使用する方法であって、ハードウェアプロセッサが、１以上のエンティティに関連する複数のデータを複数のデータソースから受信し、複数のデータに予測モデルを適用して、１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、監視リストは、１以上のエンティティのそれぞれについて、エンティティの識別子、エンティティについて予測された重要指標の識別子、エンティティについて予測された重要指標に関連する値、及び、エンティティについて予測された重要指標に関連する値に基づく推奨を含み、グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する、ことを有する方法を含んでもよい。

他の態様によれば、機械学習モデルは、複数のアルゴリズムを含み、複数のアルゴリズムのそれぞれは、複数の異なる収益構造のうちの１つに関連し、機械学習モデルを適用することは、１以上のエンティティのそれぞれについて、エンティティの収益構造に関連する複数のアルゴリズムのうちの１つを適用することを有する。

更に他の態様によれば、１以上のエンティティは、第１のエンティティ及び第２のエンティティを含む複数のエンティティであり、予測モデルは、複数の重要指標の中から第１のエンティティについて第１の重要指標の値を予測し、複数の重要指標の中から第２のエンティティについて第２の重要指標の値を予測し、第１の重要指標は、第２の重要指標と異なる。

更に他の態様によれば、複数の重要指標は、収益を含む。

更に他の態様によれば、複数の重要指標は、サブスクライブしたユーザ数を含む。

更に他の態様によれば、複数の重要指標は、店舗の来客数を含む。

更に他の態様によれば、複数の重要指標は、オンラインアプリ又はプラットフォーム上で費やされた時間を含む。

更に他の態様によれば、少なくとも１つのハードウェアプロセッサが、１以上のエンティティのそれぞれについて、エンティティのタイプに基づいて予測モデルによってエンティティについて予測される重要指標を選択することを更に有する。

更に他の態様によれば、少なくとも１つのハードウェアプロセッサが、１以上のエンティティの少なくとも１つについて、少なくとも１つのエンティティに関連する複数のデータの変化に基づいて予測モデルによってエンティティについて予測される重要指標を変更することを更に有する。

更に他の態様によれば、重要指標に関連する値は、重要指標の値の予測された変化を含む。

更に他の態様によれば、複数のデータは、リアルタイムで受信される。

更に他の態様によれば、複数のデータを受信することは、スケジューリングサービスによって、データを外部システムからフェッチして、データをクラウドストレージコンテナ内に格納することを有する。

更に他の態様によれば、複数のデータを受信することは、予め定義された入力パラメータに基づいて、格納されたデータから複数のデータをバッチ処理で抽出、変換及び導入することを更に有する。

更に他の態様によれば、１以上のエンティティのそれぞれについて、推奨は、エンティティがオーバーパフォーマンス、ニュートラル又はアンダーパフォーマンスしているかを示す、エンティティについて予測された重要指標に関連する値に基づく単一の単語を含む。

更に他の態様によれば、１以上のエンティティのそれぞれについて、推奨は、エンティティについて予測された重要指標に関連する値に基づく数値スコアを含む。

更に他の態様によれば、１以上のエンティティのそれぞれについて、数値スコアは、エンティティのサイズに更に基づく。

更に他の態様によれば、複数のデータは、１以上のエンティティの財務データ、１以上のエンティティによるパブリック向けアナウンス、１以上のエンティティによるソーシャルメディアへの投稿、１以上のエンティティによる公開プレゼンテーション、又は１以上のエンティティのリーダーが投稿した公開情報のうちの１以上を含む。

更に他の態様によれば、複数のデータへの予測モデルの適用は、少なくとも１つのグラフィックス処理ユニット（ＧＰＵ）によって実行される。

更に他の態様は、少なくとも１つのハードウェアプロセッサと、１以上のソフトウェアモジュールであって、少なくとも１つのハードウェアプロセッサによって実行されたときに、１以上のエンティティに関連する複数のデータを複数のデータソースから受信し、複数のデータに予測モデルを適用して、１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、監視リストは、１以上のエンティティのそれぞれについて、エンティティの識別子、エンティティについて予測された重要指標の識別子、エンティティについて予測された重要指標に関連する値、及び、エンティティについて予測された重要指標に関連する値に基づく推奨を含み、グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する、ように構成されたコンピュータ実行可能命令を含む１以上のソフトウェアモジュールと、を有するシステムを含んでもよい。

更に他の態様は、命令を記憶した非一時的なコンピュータ可読媒体であって、命令は、ハードウェアプロセッサによって実行されたときに、ハードウェアプロセッサに、１以上のエンティティに関連する複数のデータを複数のデータソースから受信し、複数のデータに予測モデルを適用して、１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、監視リストは、１以上のエンティティのそれぞれについて、エンティティの識別子、エンティティについて予測された重要指標の識別子、エンティティについて予測された重要指標に関連する値、及び、エンティティについて予測された重要指標に関連する値に基づく推奨を含み、グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する、ようにさせる非一時的なコンピュータ可読媒体を含んでもよい。

本発明の例示的な１つ又は複数の実施態様について、以下においては、図面に基づいて詳細に説明する。

図１は、本出願の例示的な実装によるアーキテクチャの機能を示している。 図２は、本出願の例示的な実装によるアーキテクチャの構造を示している。 図３は、本出願の例示的な実装によるアーキテクチャに関連したプロセスを示している。 図４は、本出願の例示的な実装による例示的な代替可能なデータタイプを示している。 図５は、本出願の例示的な実装による例示的な代替可能なデータセット処理を示している。 図６は、本出願の例示的な実装による例示的な自動タグ付けを示している。 図７は、監視リストに関しての、本出願の例示的な実装によるユーザ経験を示している。 図８は、監視リストに関しての、本出願の例示的な実装によるユーザ経験の生成に関連したプロセスを示している。 図９は、予測分析に関しての、本出願の例示的な実装によるユーザ経験を示している。 図１０は、予測分析に関しての、本出願の例示的な実装によるユーザ経験の生成に関連したプロセスを示している。 図１１は、予測分析に関しての、本出願の例示的な実装によるユーザ経験を示している。 図１２は、アラートチェーンに関しての、本出願の例示的な実装によるユーザ経験を示している。 図１３は、アラートチェーンに関しての、本出願の例示的な実装によるユーザ経験の生成に関連したプロセスを示している。 図１４は、自動取引に関しての、本出願の例示的な実装によるユーザ経験の生成に関連したプロセスを示している。 図１５は、自動取引に関しての、本出願の例示的な実装によるモバイルユーザ経験の生成に関連したプロセスを示している。 図１６は、自動取引に関しての、本出願の例示的な実装によるモバイルユーザ経験の生成に関連したプロセスを示している。 図１７は、例示的な実装を示している。 図１８は、例示的な実装を示している。 図１９は、例示的な実装を示している。 図２０は、例示的な実装を示している。 図２１は、例示的な実装を示している。 図２２Ａは、例示的な実装を示している。 図２２Ｂは、例示的な実装を示している。 図２３は、例示的な実装を示している。 図２４は、例示的な実装を示している。 図２５は、本出願の例示的な実装による例示的な環境を示している。 図２６は、いくつかの例示的な実装において使用するのに適した例示的なコンピュータデバイスを有した例示的なコンピューティング環境を示している。 図２７は、本出願の例示的な実装により提供されたデータ通知に応答した、シングルユーザアクション命令及びユーザ設定に基づく注文の実行に関連したプロセスを示している。 図２８は、本明細書において開示する例示的な実装に関連した例示的なユーザ経験を示している。 図２９は、本明細書において開示する例示的な実装に関連した例示的なユーザ経験を示している。

以下の詳細な説明では、本出願の図面及び例示的な実装に関する更なる詳細を提供する。複数の図面どうしの間においては、参照符号及び冗長な部材に関する説明は、明瞭さのために省略されている。説明を通して使用される用語は、例示として提供されており、限定することを意図したものではない。例えば、「自動」という用語の使用は、本出願の実装を実施する当業者が行う所望の実装に依存して、実装の特定の態様に関しての、ユーザ又はオペレータの制御を含む完全自動又は半自動の実装を含んでもよい。

より複雑でよりダイナミックな経済では、任意の所与の時点で経済に何が起こっているかを正確に反映する正確なデータが必要である。より具体的には、経済の現在の状態を正確に決定し、その後、経済の現在の動向及び将来の動向を決定し得るようにするために、推奨自体が正確であるように、正確なデータが必要とされる。

例えば、特定の株式の購入を検討する際には、トレーダなどの購入者は、その株式に関連した企業に関する企業情報を考慮し得る。この企業情報には、非常に高いレベルで、特定の期間（例えば、四半期、月、年）に企業がどれだけの収益を上げているかあるいはどれだけの損失を出しているか、が含まれてもよい。

しかしながら、この一般的で広範なデータは、企業が現実にはどのように立ち振る舞っているかを正確に描写していないことが多い。例えば、ある衣料品企業の収益は、全体的に高いように見えるけれども、データを分解すると、その収益が主にオンライン販売によるものかもしれない。典型的には、オンライン販売で高い収益を上げている店舗は、利益が出なくなったためにいくつかの実店舗を閉鎖することとなる。よって、その衣料品企業の株式を購入しようと検討しているトレーダは、それらの店舗が将来の時点で閉鎖される可能性が高いことを知っていれば、その株式を購入したくないかもしれない。

残念なことに、正確なデータがなければ、トレーダは、特定の動向が将来どのようになるかを知る方法をほとんど有していない。したがって、データを収集しそのデータをクリーニングして正規化することによって、このクリーニングされて正規化されたデータを、過去のデータと比較することにより、特定の動向が将来どのようになるかを決定することができる。同様に、トレーダは、現在の情報を評価して意思決定又は推奨を行うことができないこともある。本例示による実装によれば、クリーニングされて正規化されたデータは、現在の動向の分析を提供するために、過去のデータと比較される現在のデータであってもよい。

上記の例示的な実装では、株式市場に関連した動向を決定することについて説明したけれども、地域や国や又は世界全体の失業率、公開企業及び非公開企業の収益及び市場占有率、複数の企業にわたっての消費者行動、株式のバスケット（例えば、全体的な株式ポートフォリオなどの、２つ以上の特定の株式）、電子指数、レストラン指数、労働力における特定の部門がどのように実行されているか、インフレ、及び、投資信託の動向、を含む他の指標を決定してもよい（例えば、決定論的に得られる）。特に、経済的影響を与え得る任意のデータ又は情報を、測定してもよい。

例示的な実装の態様は、異なるタイプのデータを有する異なるデータプロバイダから複数のデータ入力を受信するための、装置、方法、及びシステム、を対象とする。異なるタイプのデータは、ビッグデータシステム内で受信され、ビッグデータシステムは、正規化、重複除去、及び分類、並びに任意選択的に他のプロセス、を実行することによって、データを標準化する。

標準化されたデータは、パネル構築するマルチパネルジェネレータに対して提供され、予測を構築し、予測を生成する。予測は、アクセスポイントに対して出力され、ユーザは、予測に対してアクセスしてもよい。ユーザ経験は、複数のエンティティを示す監視リスト上の推奨として予測結果を受信すること、及び／又は、複数のエンティティの１つに関する詳細なパフォーマンス及び推奨レポートを受信すること、及び／又は、１つ又は複数の状況によってトリガーされ得るアラート（alert）をユーザに対して提供するアラートチェーン（alert chain）を受信すること、を含んでもよい。

上記の例示的な実装では、データは、連続的にかつリアルタイムで処理され、これにより、ユーザに対して、推奨、監視リスト、及び／又はアラートチェーンに関するリアルタイムでの更新が、自動的に提供されるようになっている。ユーザは、手動又は自動のいずれかで取引を実行する機会を有してもよく、また、システムに対してリアルタイムでフィードバックを提供する機会を有してもよい。

上記の例示的な実装を実施するために、以下においてより詳細に説明するように、アーキテクチャが提供される。さらに、アーキテクチャに関連したユーザ経験についても、より詳細に説明する。

アーキテクチャ

図１～図３に示すように、例えば、本明細書において説明する例示的な実装は、システム構成要素、及び関連した機能、並びに動作を含む、アーキテクチャに関する。

図１は、例示的な実装によるアーキテクチャに関する概略的な説明を示している。１０１では、複数の代替可能なデータプロバイダから、データが受信される。複数の代替可能なデータプロバイダの詳細については、以下においてより詳細に説明する。例えば、限定するものではないが、データプロバイダの一部は、金融取引情報プロバイダ、ＧＰＳデータなどの位置情報、ソーシャルメディア又はオンライン出版物情報などの消費者行動情報、あるいは、他のデータ、を含んでもよい。

１０３では、複数のデータプロバイダからデータを受信するとともにデータのタグ付け又はラベル付けを実行する自動タグ付けシステムが提供される。より具体的には、データは、異なるデータプロバイダから受信した異なるタイプのデータどうしの間にわたって標準化されてもよい。標準化処理は、フィルタリング、重複除去、正規化、及び、分類又はラベル付け、を含み得るが、これらに限定されるものではない。自動タグ付けシステムに関する更なる詳細を提供する。

１０５では、更新及びフィードバックプロセスが提供される。より具体的には、自動タグ付けシステムを更新するために、及び、プロセスのチェック及び監査のために、手動の又は自動のプロセスが提供されてもよい。任意選択的に、更新及び監督プロセスへの入力は、データマイナ又はアナリストなどの手動ソースに対して提供されてもよい。これに代えて、いくつかの例示的な実装では、ニューラルネットワークなどの機械学習を採用した人工知能システムが、訓練段階に対する定期的な更新のためにバックプロパゲーション技法を使用してもよい。

１０７では、企業に関連した財務データが提供される。より具体的には、年次報告書、プレスリリース、広報担当者又は幹部のソーシャルメディアからの情報、公表された価格情報、及び、当業者であれば理解されるような他の情報などの、公表された情報が提供される。

１０９では、自動タグ付けシステム１０３の標準化されたデータ及び企業の財務データ１０７が、モデル化システム１０９に対して提供される。モデル化システム１０９は、１つ又は複数のハンドル生成器と予測構築器とを含み、これらはモデルに対して適用される。モデルは、限定するものではないが、ニューラルネットワークの形態で機械学習を適用する人工知能ベースのシステムを含んでもよく、このようなシステムは、自動化タグ付けシステム１０３の標準化されたデータ及び企業財務データ１０７を受信するとともに、それらをニューラルネットワークに対して適用し、出力として、予測を生成する。

また、１１１において指摘するように、モデル化システムへの入力は、企業の合併買収情報に関連した専有データ、及び企業の会計四半期カレンダーを含み得るが、これらに限定されるものではない。

１１３では、予測の出力が、１つ又は複数の収益予想として提供される。上述したように、標準化されたデータに基づく企業の財務データと、独自のデータとが、収益予想を生成するために機械学習モデル内へと供給される。

１１５では、最終的な出力が推奨の形態で提供される。例えば、限定するものではないが、最終的な出力は、取引として、購入、保有、又は売却するための推奨であってもよい。これに代えて、最終的な出力は、スコアであってもよい。なおもこれに代えて、最終的な出力は、ユーザを関与させずに、取引自体の実行であってもよい。任意選択的に、ルールベースの又は他の決定論的アプローチが、上述したような機械学習の確率論的アプローチと組み合わせて採用されてもよい。

図２は、例示的な実装によるアーキテクチャ２００を示している。入力２０１は、ビッグデータシステム２１１に対して設けられたデータプロバイダ２０１～２０７を含み、このシステムは、次に、アクセスポイント２１３に対して関連付けられている。

より具体的には、２００に示すように、データは、複数のＮ個のデータプロバイダ２０３～２０７からの入力２０１として受信される。本明細書で「データソース」という用語が使用される場合、データは、Ｎ個のデータプロバイダ２０３～２０９などの１つ又は複数のデータプロバイダから、並びに当業者であれば理解されるような任意の他のデータプロバイダから、取得される。

ビッグデータシステム２０９では、データプロバイダ２０３～２０９のそれぞれについて、Ｎ個の対応したアダプタ２１５～２２１が設けられている。アダプタ２１５～２２１は、本明細書において説明するように、データを、正規化２２３したり、重複除去２２５したり、分類２２７したり、してもよい。

上述したように、データは、データプロバイダ２０３～２０９によって提供され、データアダプタ２１５～２２１によって処理される。データアダプタ２１５～２２１の出力は、上述したように、結果として得られる出力データが、正規化、重複除去、及び分類されるように、自動タグ付けシステムに対して提供される。例示的な実装に関するこれらの態様は、自動化されているけれども、データマイナ又はアナリストは、任意選択的にプロセスを監督し、プロセスを更新し続けてもよい。結果として得られた出力データは、財務報告書などの企業の財務データに対して、あるいは、過去又は現在の企業の特性に関連した他の公的に利用可能な情報に対して、組み合わせてもよい。

自動タグ付けシステムの出力及び企業の財務データは、モデル化システムに対して提供される。モデル化システムは、複数のマルチパネル生成器２２９、２３１、２３３、マルチ予測構築器２３５、２３７、２３９、及び、予測モジュール２４１、２４３、２４５、を含んでもよい。モデル化システムは、その出力予測として、財務データ、専有データ、及び機械学習に基づいて、収益予想を生成する。より具体的には、財務データ及び専有データは、自動タグ付けシステムに関する上記の入力と、企業の財務データと、を含む。例えば、限定するものではないが、データは、財務報告書、合併買収情報、及び、四半期の財務実績、を含んでもよい。

出力は、予測であり、ファイル、ＡＰＩ、コンソール、又は、カスタム書式、という形式で、出力に対して提供されてもよい。したがって、出力は、ユーザアクセスポイントにおいて、ユーザに対して提供される。アクセスポイントに関連した例示的なユーザ経験は、本明細書においてより詳細に説明する。

図３は、例示的な実装による上記の構造及び機能に関連したプロセス３００を示している。より具体的には、プロセスは、データ処理に関連した第１フェーズ３０１と、パネルの進展及び校正に関連した第２フェーズ３０３と、予測モデルの作成及び適用、並びに予測の生成に関連した第３フェーズ３０５と、に分けられる。

第１フェーズ３０１に関して、３０７では、入力データが受信される。上述したように、そして本明細書において説明するように、入力データは、異なるタイプの複数のソースからのものである。例えば、限定するものではないが、入力データは、クレジットカード取引、デビットカード取引、又は他の電子購入取引、などの複数のベンダーからの時系列データを含んでもよい。

３０９では、データを正規化する。より具体的には、演算３０７の入力データは、受信時点での有機ベンダーデータ書式から、ベンダー間の一貫性を提供する内部データ書式へと、マッピングされる。例えば、限定するものではないが、正規化は、異なる代替可能なデータセットどうしの相違点を考慮することと、そのデータを共通の基準へと標準化することと、を含む。追加的な態様は、データを標準化するための複製又は他のプロセスを含んでもよい。

３１１では、購入に関連したブランドが、タグ付けされる。タグ付けは、正規化されたデータに対して、タグ付けルールを適用することを含んでもよい。ルールは、クレジットカード又はデビットカードに固有のルール、ＧＰＳデータのためのジオフェンシングルール、ブラウザの履歴又はオンラインアプリケーションの使用に関連したルール、あるいは、当業者であれば理解されるような他のルールを含み得るが、これらに限定されるものではない。例えば、限定するものではないが、一連の金融取引について、それぞれの金融取引に対して、ラベル付けしたり、タグ付けしたり、してもよい。タグ付けを実行するために、１つ又は複数のタグ付けルール３１３を適用してもよい。タグ付けルールは、包括的なフィルタ、又は排他的なフィルタであると考えてもよい。さらに、フィルタなどのルールベースのアプローチに加えて、ニューラルネットワークを含む機械学習モデルなどの、人工知能を組み込んだ自然言語処理アプローチが採用されてもよい。

入力データが正規化されてタグ付けされた後には、第２フェーズ３０３において、パネル化演算３１５が実行される。例示的な実装によれば、ユーザのサンプルが、パネルとして確立される。ユーザは、パネルに関連した基準に一致するように選択される。例えば、限定するものではないが、パネルは、入力データの解約率に関連する態様で作成されてもよい。チャネル化ルールの他の例は、３１７に示されており、それらのルールは、ユーザ取引パターン、国勢調査データバランシング、あるいは、ユーザの取引行動の特徴を取引に対して関連付ける他のルール、に基づくものであってもよい。

３１５においてパネルが生成された後には、３１９においてグループ化処理が実行される。より具体的には、パネルは、シンボルによってグループ化される。タグ付けプロセスにおいてデータに関連したブランドは、企業に関連したシンボルに対して割り当てられる。このデータが、合併、買収、分社化、倒産、ブランド変更、上場、上場廃止、あるいは、他の金融イベントのために、時間の経過とともに変化する可能性があることに、留意されたい。よって、イベントは、３１９においてシンボルに対してブランドを割り当てる時点で含まれているように、リアルタイムで割り当てられる。シンボルは、３２１に示すようなデータベースから選択することができる。

３２３では、グループ化されたものに対して、１つ又は複数の補正が適用される。例えば、限定するものではないが、３２５に示すように、金融機関に特に関連したパターンが、グループ化を校正するために適用される。このようなパターンの例は、情報に関する週末の投稿、金融機関に典型的に関連した投稿の遅延、及び、保留中であってまだ投稿されていない取引、を含んでもよい。加えて、３２７に示すように、異常が除去される。除去される異常の例は、異常な取引又は異常なユーザが含まれ得るが、これらに限定されるものではない。

第２フェーズ３０３においてパネルが完全に生成された後には、プロセスは、以下のように第３フェーズ３０５へと進む。３２９では、予測モデルが生成される。例えば、限定するものではないが、訓練段階では、企業のファンダメンタルズ及び株価などの企業に関連した履歴データ、並びに、例示的な実装によって以前から提供されていた可能性のある履歴測定値が、訓練データとして使用される。したがって、予測モデルは、３３１に示すように、この訓練データに基づいて訓練される。

３３３では、予測が生成される。３２９で生成された予測モデルを使用して、オープンクォータ３３５に関連した特徴点を適用することにより、将来の企業のファンダメンタル指標に対する将来の株価予想を導出する。特徴点は、オープンクォータを対象としたものとして開示されているけれども、例示的な実装の場合は、これに限定されず、他のオープン期間をその代わりとしてもよい。

アーキテクチャに関する上記の例示的な実装は、図２６及び図２７に関して以下に説明するように、ハードウェア上で実行されてもよい。さらに、ハードウェアは、モデルが連続的にデータを受信して、自動的にかつリアルタイムで更新されるように、連続的な大規模データの入力を提供する。よって、ハードウェアの処理能力は、そのような処理を可能とするのに充分なものでなければならない。例えば、限定するものではないが、ＧＰＵを、人工知能処理に関して使用してもよい。これに代えて、あるいはＧＰＵ（グラフィック処理ユニット）と組み合わせて、ＮＰＵ（ニューラル処理ユニット）を使用してもよい。これらのユニットの一方又は双方は、クラウドコンピューティングシステムのための、分散サーバシステムなどの、遠隔的に配置されたプロセッサにおいて使用されてもよい。

例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。

さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。

さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

代替可能なデータセット

上述したように、アーキテクチャは、複数の代替可能なデータセットを受信するように構成される。図４に示すように、代替可能なデータ入力４００の例は、限定するものではないが、１つのクレジットカード取引及びデビットカード取引、モバイルデバイス使用情報４０３、ジオロケーションデータ４０５、ソーシャルデータ及びセンチメントデータ４０７、並びに、ウェブトラフィック及びインターネットデータ４０９、を含んでもよい。

上記のハードウェア実装は、当業者であれば理解されるように、図４の代替可能なデータセットを処理するために使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

図５は、例示的な実装による代替可能なデータセットの処理を示している。より具体的には、５００では、代替可能なデータセットの受信及び処理が開示されている。代替可能なデータセット５０１は、限定するものではないが、代替可能なタイプを有したデータを含んでもよい。例えば、限定するものではないが、ＧＰＳデータ５０３、金融取引に関連したデータ５０５、ワクチン接種データ５０７、衛星画像データ５０９、アプリ使用データ５１１、及び、閲覧履歴情報５１３は、代替可能なデータセット５０１の一部とされ得るデータのすべてのタイプである。しかしながら、代替可能なデータセット５０１は、上記の例示的な場合に限定されるものではなく、当業者であれば理解されるように、他のデータセットを含んでもよい。

５１５では、複数のデータソースが、データを抽出、変換、及び導入するために、ＥＴＬ（抽出、変換、導入）演算を実行する。したがって、５１５では、１～ｍというデータタイプに関連した特徴点が、５１７に示すように、対応する特徴点１～特徴点ｍへと抽出される。

５１９では、プロセスは、モデル化演算を受ける。モデル化演算は、５２１に示すように、モデルの選択、特徴点の選択、モデルに対する訓練段階の実行、及び、モデルテストの実行、を含む。モデル化演算５１９は、ニューラルネットワーク及び機械学習を使用する人工知能システム上で実行されてもよい。

５２３では、バックテストとも称される検証ステップが実行される。例えば、５２５において開示するように、株価、企業のファンダメンタルズ、及び、過去の決定又はイベント、に関連した履歴データが、生成されたモデルに対して適用される。５２３の検証に基づいて、過去の情報の適用がモデルの検証に成功したかどうかの決定が行われる。モデルが成功裏に検証されなかった場合には、すなわち言い換えれば、バックテストの結果が許容不可能であることが判明した場合には、プロセスは、５１９へと戻り、モデル化が、再び実行される。

他方、演算５２３での検証が成功した場合には、演算が進められる。より具体的には、演算は、上述したように、モデル化演算５２７及び予測演算５２９へと進む。

上述したハードウェア実装は、当業者であれば理解されるように、図５の代替可能なデータセットを処理するために使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

自動タグ付け

代替可能なデータセットが上述したようにして処理された際には、演算１０１に関して、自動タグ付け１０３が、データ上で実行される。図６は、例示的な実装による自動タグ付け６００を示している。

６０１では、取引が受信され、代替可能なデータセットが、上述したようにして処理される。６０３では、正規化が実行される。より具体的には、ブランド分類器に関連した取引から、特徴点が抽出される。

６０５では、ブランド分類が実行される。より具体的には、抽出された特徴点が、正規化６０３された後に、分類階層化モデルに対して適用される。より具体的には、決定論的な態様で抽出を実行するルールベースのアプローチが適用され、ルールベースのアプローチは、ニューラルネットワークに基づく機械学習などの、本質的には確率論的な人工知能のアプローチと混合される。したがって、ブランド分類６０５は、決定論的モデルと確率論的モデルとの混合で実行される。

６０７では、分類器が正確であることを検証するための検証ステップが実行される。より具体的には、分類されたデータからなるサンプルが検証され、ブランドに関してラベル付けが正しく適用されたことが確認される。必要に応じて、分類器の再訓練を実行する。任意選択的に、６０７でのこの検証演算及び再訓練演算は、ブランドの分類が、しきい値の信頼レベルで検証されるまで、反復的に実行されてもよい。

６０９では、ブランドを、企業に関して分類する。例えば、企業は、民間企業、公的企業、あるいは、公的企業又は民間企業と同様の特徴を有した他の取引企業組織、であってもよい。上記の演算６０５及び６０７と同様の態様で、ブランドが企業に分類されるように、ルールベースの決定論的な演算と、機械学習及びニューラルネットワークなどの確率論的な人工知能の演算と、の混合が採用される。また、演算６０７と同様に、６１１では、企業分類器を検証することにより、企業の分類に関して、サンプルデータの正確なラベル付けが確保されていることを確認する。必要であれば、企業分類器が、しきい値の信頼性レベルで検証されるまで、再訓練を実行してもよく、任意選択的に、反復的な無料訓練を実行してもよい。

６１３では、ブランド分類６０５及び企業分類６０９が検証された後に、タグ付けされた取引が生成されたと考えられる。例えば、限定するものではないが、ラベル付けは、データが自動的にラベル付けされるような態様で実行される。このプロセスの出力は、パネル生成、予測構築、及び予測、において使用されてもよい。

例示的な実装は、関連技術におけるアプローチと比較して、様々な利点及び有益性を有することができる。例えば、限定するものではないが、関連技術におけるアプローチでは、一般的な名称（例えば、ＤＥＮＮＹＳ又はＳＰＲＩＮＴ）、短い名称（例えば、ＡＭＣ又はＢＯＯＴ）、特定の名称（例えば、ＴＡＣＯ又はＴＡＲＧＥＴ）、及び、類似した名称（例えば、ＦＩＶＥ ＢＥＬＯＷ又はＢＩＧ ＦＩＶＥ）に関する誤ったタグ付けなどの、問題点又は欠点を回避し得ない。さらに、明確な基準に従っていない場合は、エンティティが省略されてしまい得る。明確な基準に従っていないために企業が省略される例は、フルネームではなく略語を使用している場合、時間の経過とともに名称が変更されている場合、店舗の取得時期の違いによるわずかな名称の違い、あるいは、店舗名の誤植、を含む。関連技術における他の誤りの例は、取引が、異なる企業に対して明確に関連付けられていたとしても、取引を誤ったティッカー（企業の指標）に対して割り当てられてしまうことを含む。

当業者であれば理解されるように、図６の自動タグ付けを処理するために、上記のハードウェア実装を使用してもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

ユーザ経験

本明細書において説明する例示的な実装の出力は、アーキテクチャによって生成された情報をユーザが視覚化することを提供するという態様で、ユーザ経験において提供されてもよい。上記の例示的な実装は、上述したように、クラウド内で実行され得るけれども、上記の例示的な実装の出力に関連したユーザインターフェースに対してアクセスすることをユーザに許可するオンラインアプリケーションが、ユーザに対して提供されてもよい。そのユーザインターフェースは、限定するものではないが、モバイルデバイス上のオンラインアプリケーション、ラップトップ上のアプリケーション、及び、Ａｍａｚｏｎ Ａｌｅｘａなどの家庭用デバイス上の対話型アプリケーション、並びに、自動車のプロセッサによって実行される自動車などのモバイル環境でのアプリケーション、あるいは、本明細書において説明するユーザ経験を提供するためのコンピュータ可読命令を実行する更に他の態様又は構造、であってもよい。

例えば、限定するものではないが、予想、予測、推奨、又は同種のもの、などのアーキテクチャの出力に関連した意思決定支援情報をユーザに対して提供するように生成される監視リストを、ユーザに対して提供してもよい。加えて、監視リスト上のエントリの詳細な分析が、特定の推奨事項と一緒に及び推奨事項の根拠に関する詳細な指標と一緒に提供されてもよく、任意選択的に、外部ベンチマークによって提供される推奨事項と比較されてもよい。さらに、本明細書において説明する例示的な実装を使用することにより、アラートチェーンを提供してもよく、あるいは任意選択的に、決定論的なルールベースのアプローチと、人工知能アプローチの技術を含むがこれに限定されるものではない上記の態様と、を組み合わせた、意思決定支援を又は自動化された意思決定ツールを提供してもよい。

ユーザ経験に関連したデータ処理は、本明細書において開示するハードウェアを使用して処理されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

監視リスト

図７は、例示的な実装に関連したユーザ経験を示している。７００に示すように、ユーザ経験は、企業の監視リストを提供し、これは、例えば、ユーザが選択してもよいし、ユーザに関連した嗜好に基づいてユーザに対して提案されてもよい。例えば、限定するものではないが、監視リストは、第１列７０１内に、企業名と取引シンボルとを含めた、企業の名称を含む。別の列７０３では、株価が提供され、これと一緒に、総量やパーセンテージとしての株価変動などのパフォーマンスに関する情報が提供される。

さらに別の列７０５では、例示的な実装で入力として使用されているパフォーマンスに関連した重要データタイプが、特定されている。図７に示すように、第１行目は、第１の企業に対して関連付けられており、この企業は、小売販売のための物理的に及びオンラインで存在感を有した大規模な小売企業であることができ、この企業にとって、収益がパフォーマンスの重要なインジケータである。第２行目は、オンラインでのサブスクリプション（online subscription）企業であり、製品に関連した他のユーザの数が、パフォーマンスの重要なインジケータとなる。ユーザが訪れ得る小売店である第３行目では、同一店舗の来客数（same-store visits）が、パフォーマンスの重要なインジケータとして提供される。第４行目は、国際的に存在感のある大手自動車メーカで、米国での売上高が、パフォーマンスの重要なインジケータとして提供される。ソーシャルメディア企業である第５行目では、ユーザのエンゲージメント（social media company engagement of users）（例えば、プラットフォーム上で費やされた時間）が、パフォーマンスの重要なインジケータとして提供される。

さらに別の列７０７では、パフォーマンスの重要なインジケータに関連したパフォーマンスが示されている。図７に示すように、第１行目では、収益という重要なインジケータが０．４％のパフォーマンス増加を示し、第２行目では、ユーザ数が３％の増加を示し、第３行目では、既存店売上高が１０％の減少を示し、第４行目では、米国の収益が６．２％の増加を示し、最終行では、ユーザエンゲージメントが３％の増加を示している。したがって、例示的なユーザ経験は、パフォーマンスにおける重要なインジケータに関する情報と、上述したような入力データに基づく実際のパフォーマンスと、をユーザに対して提供する。

本例示的な実装によれば、重要なインジケータとパフォーマンスに基づいて、システムは、さらに別の列７０９に、スコアを生成する。スコアとは、企業のパフォーマンスを、ユーザに対して提示するものであり、ユーザは、推奨の形態としてこれを適用することができる。例えば、限定するものではないが、図７における第１行目のケースでは、売上高が０．４％増加したことが、ニュートラルというスコアと関連付けられ、第２行目では、ユーザ数が３％増加したことが、オーバーパフォーマンスというスコアと関連付けられている。第３行目では、既存店での売上高が１０％減少したことが、アンダーパフォーマンスというスコアと関連付けられている。第４行目では、米国での売上高が６．２％増加したことが、オーバーパフォーマンスというスコアと関連付けられている。最後の行では、エンゲージメントが３％増加したことが、オーバーパフォーマンスというスコアと関連付けられている。

したがって、例示的な実装によるユーザ経験は、企業のタイプに基づいて、及び、複数のデータストリームのうちの利用可能なデータに基づいて、システムによって決定される、パフォーマンスの重要なインジケータに関する情報を、ユーザに対して提供する。さらに、企業ごとの重要なインジケータに関する実際のパフォーマンスが、スコアの決定と一緒に提供される。例えば、限定するものではないが、収益情報などの第１行目の情報は、本開示の他の箇所で説明するように、データソースとして受信した入力クレジットカード情報に基づいて生成されてもよい。その情報は、企業に関連した収益を決定するために使用されてもよく、パフォーマンスを計算するために使用されてもよい。

図面に図示されたスコアは、ニュートラル、オーバーパフォーマンス、又はアンダーパフォーマンス、などの単一の単語であるけれども、本発明の範囲から逸脱することなく、他のスコアで代用してもよい。例えば、限定するものではないが、１から１０までのパフォーマンス格付けなどの数値スコアを提供してもよい。この情報及びスコアは、提供される入力データに基づいて、また、その企業に対する適切なスコアとして特徴付けられるものを観察することに基づいて、生成される。よって、各企業は、業界又は企業規模などの企業属性に基づいて、スコアを提供するために必要なパフォーマンス変動量を決定するために、異なるスコアを決定してもよい。

本明細書において説明する例示的な実装は、監視リストに示すような重要なインジケータを決定する方法を提供する。例えば、限定するものではないが、株価の変化に関して最も高い相関性を有する基準を決定するために、履歴データを、人工知能機械学習モデルに対して適用してもよい。例えば、限定するものではないが、いくつかの関連技術におけるアプローチは、収益を決定するために、総ユーザ数を直接的に測定しようとする場合がある。しかしながら、ユーザ数が２倍になったとしても必ずしも収益額が２倍になるとは限らないため、そのような関連技術におけるアプローチは正確であり得ない。これが当てはまる可能性がある理由は、新たなユーザが、初期のユーザ又は以前のユーザと比較して、同じ表現、同じ使用パターン、又は同じ消費傾向を有していない可能性があるからである。

同様に、使用の地理的位置、ユーザ、又は他の情報は、データがユーザを代表しているかどうかを決定するのに重要であり、重要なインジケータを正しく決定することができる。例示的な実装に関して上述したように、ＧＰＳデータは、入力として受信され、また、自動タグ付けシステムにおいて安定化されるので、データは代表的なものとなり得る。別の例として、データを安定化させる必要があるのは、ユーザの全体的な数を示すためだけではなく、ユーザがオンラインアプリに費やす時間を示すためでもあり、なぜなら、新たなユーザが現在のユーザよりもアプリに費やす時間が長かったり短かったりする場合には、これは、収益、購入、広告、又は同種のものに関する異なるユーザアクションを反映している可能性があり、データをより正確なものとし得るからである。

同様に、企業がターゲットを買収する時には、ユーザ数が増加するかもしれないけれども、それらの新たなユーザは、以前のユーザを代表していない可能性がある。合併の発表から合併プロセスの完了までの間に、数ヶ月又は数年が経過することがあり、その間に、公に入手可能な情報がこれらの例示的な実装に組み込まれ、その結果、重要なインジケータ、パフォーマンス提示、及び／又は、推奨事項、を調整して、そのような情報を校正することができる。独占禁止法又は輸出規制などの法的な又は規制上の障害により、合併が停滞又は阻止される可能性があり、その場合、合併に関連して公開されている情報における特定の用語の存在を使用することにより、予測及び推奨を調整することができる。さらに、ツールの予測的態様は、そのようなモデルの特徴付け方法、処理方法、及び出力予想の生成方法に関してモデルを訓練するために使用された同様のパターンに基づいて、合併後のパフォーマンスに関する予測を提供してもよい。

別の例として、レストランに関連した株式について、コロナウイルスのパンデミック状況がより深刻な状況から深刻度が低減した状況へと変化したことが、個人での食事に戻ることを望む消費者の嗜好に影響を与える可能性がある。このような情報の掲載は、特定の業界又は企業にとっては、より敏感なものとなるかもしれない。コロナウイルスの場合、旅行、レジャー、ダイニング、又はその他の業界は、他の業界と比較してより敏感である可能性があり、本例示的な実装は、そのような変化を考慮してデータの安定化を実行することが可能である。正規化、重複除去、分類、及び、データ安定化、を実行する例示的な実装における上記アプローチがなければ、データは、充分に高い信頼性で重要なインジケータを決定するに際して、必要な精度を欠くこととなる（例えば、ユーザ集団をよりよく表現するためのクラスタ化）。

図８は、例示的な実装による、監視リストへの情報の生成及び更新に関するプロセスを示している。上述したユーザ経験に関連するように、重要なインジケータのタイプ、並びにスコアが、データ入力に基づいて、リアルタイムで連続的に更新される。例えば、第１行目では、収益が重要なインジケータのタイプとしてリストアップされている。しかしながら、企業に関連した入力データに変化があった場合、例示的な実装では、重要なインジケータのタイプを、収益から、既存店売上高や顧客基盤や又は他の重要なインジケータへと、変更させてもよい。

より具体的には、８００に示すように、本明細書において説明するアーキテクチャに対して、入力が提供される。例えば、限定するものではないが、各企業に関して、重要なインジケータに関連したシグナル（signal）のタイプごとに、別個のパイプライン処理が存在する。よって、上記の例では、第１の企業について、候補となる重要なインジケータのそれぞれについて、複数のパイプライン処理が存在してもよい。あるパイプライン処理は、収益に関するシグナルに関連してもよく、別のパイプライン処理は、消費者支出、又は企業業績のインジケータに関連してもよい。

より具体的には、８０１では、上述したような代替可能なデータソースからのリアルタイムデータイベントが、提供される。パイプライン処理のそれぞれは、モデルに関連した新たなデータを受信することによってトリガーされる。代替可能なデータソースからの新たなデータの入力については、上述したとおりである。これらのリアルタイムデータイベントは、アーキテクチャに関する例示的な実装に従って処理され、現在のデータに基づいてシグナルが生成される。よって、８０３では、更新されたシグナルが提供される。より具体的には、８０１で受信された新たなデータが、例示的な実装のモデルに対して提供される。したがって、上述したように予想が生成され、出力シグナルとして提供される。

８０５では、更新されたシグナルの強度が評価される。例えば、限定されるものではないが、潜在的に重要なインジケータの予想であり得る出力シグナルは、ベンチマークコンセンサスシグナルと比較される。一例示的な実装によれば、更新されたシグナルは、企業の予想収益であってもよく、これは、利用可能な情報からの、１人又は複数人のアナリストが生成した予想すなわちアナリストコンセンサスと比較される。更新されたシグナルとベンチマークシグナルとの間の比較に基づいて、シグナル強度ベクトルが生成され、これは、更新されたシグナルとベンチマークシグナルとの間の相対的な近さの度合いを示すものである。

８０７では、更新されたシグナルの強度が分類される。より具体的には、８０５で生成されたシグナル強度ベクトルは、推奨へと分類される。例えば、限定するものではないが、推奨は、ホールド、買い、又は売り、などの一次元的にアクション可能な推奨であってもよい。

８０９では、シグナルの強度に関連した分類は、任意の更新を生成するために使用され、これらの更新は、その後、ユーザ経験においてユーザに対して提供されて表示される。より具体的には、ウェブインターフェース、モバイルインターフェース、又はプッシュされたアラート、などのユーザインターフェースは、シグナル強度の分類の結果によって、及び、監視リストの更新の結果によって、更新されてもよい。よって、例示的な実装によれば、パイプライン処理のうち、どのパイプライン処理が最も強いベクトルを有しているかに応じて、重要なインジケータタイプの変更が、また、推奨の変更が、ユーザに対して提供されてもよい。任意選択的に、複数のパイプライン処理は、シグナル強度に基づいて混合又は重み付けされてもよく、これにより、混合された結果が提供され、重要なインジケータは、最も重く重み付けされたインジケータとしてリストアップされる。別の例示的な実装によれば、複数のインジケータのすべてが、結果の複数の出力と一緒にリストアップされてもよく、続いて、各企業に関してシグナルのそれぞれについて、各パイプライン処理に関しての、重み付けありの又は重み付けなしの、強度ベクトルの行列演算又は多重化に基づく推奨が、リストアップされてもよい。

この例示的な実装によれば、重要なインジケータ、パフォーマンス、及び推奨、に関するリアルタイムでの変化が、アクション可能な形態で、ユーザに対して提供されてもよい。後述するように、推奨は、また、企業の詳細な分析内で又はアラートチェーン内で提供されてもよく、自動的に行われる推奨又は実際のアクションに関して使用されてもよい。

上記のハードウェア実装は、当業者であれば理解されるように、図７～図８の監視リストを処理するために使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

パフォーマンス及び推奨

図９に示すように、別の例示的なユーザ経験９００によれば、図７の上記のユーザ経験に図示された企業のいずれかが、更なる要約を提供するために選択されてもよい。ここでは、第４行目が選択され、予測に関連した更なる情報が提供される。推奨事項９０５が提供され、この場合、収益の減少に基づいて「ストロングバイ」が提供されている。

株価に対しての収益の相対的な影響（例えば、収益と株価との相関関係）、及び、例示的な実装に関連した株式に関する予測精度、などの更なる詳細９０３が、ユーザに対して提供される。アナリスト予想に基づく予測に関する情報が、実際のデータの測定値に基づく予測と比較して提供され、また、実際のデータの測定値に基づくパフォーマンスに関連したスコアも提供される。チャート９０７は、実際のデータの測定値に基づく収益と、企業が提供した公開情報に基づく予想収益と、の比較を図示して提供している。加えて、株価の情報も提供されている。

図１０は、例示的な実装による、期待値と実際値との間の差を視覚化する出力を生成するためのプロセス１０００を示している。

１００１では、測定された売上高が提供される。限定するものではないが最初に適用可能であるように、上述したように、測定された売上高は、図３に図示して上述したような第２フェーズ３０３などのようにして計算される企業売上高を含んでもよい。

１００３では、予想売上高が提供される。予想売上高は、実際の売上高情報とは対照的に、アナリストの予想、アナリストのコンセンサス、業界の公表、あるいは、予想売上高情報を提供することに関連した他の利用可能な情報、に基づくものであってもよい。

１００５では、１００１で得られた測定された売上高について、集約演算が実行される。より具体的には、測定された売上高が、時系列に基づいて、予想される売上高シグナルに関連した間隔と同等の間隔で、集約される。例えば、限定されるものではないが、予想売上高シグナルが、毎日、毎週、毎時、四半期、等の既知の時間間隔を有する場合には、測定された売上高は、同等の時間期間で集約される。

１００７では、拡縮演算が実行される。より具体的には、測定された売上高は、母集団のサンプルからの情報を提供するので、測定された売上高は、拡縮される必要がある。例えば、削除を限定するものではないが、拡縮は、サンプルに対して関連したサンプルの代表母集団を外挿すること、及び同様に、サンプルのその母集団の集計された売上高を、代表母集団に対して外挿すること、を含んでもよい。

１００９では、１００１、１００５、及び１００７からの、測定された売上高に関する、拡縮され集約された情報に関連した期間を、１００３における予想売上高の期間と合わせる。したがって、集計されて拡縮された測定売上高は、時間間隔によって、予想売上高と突き合わされる。

１０１１では、視覚化演算が実行される。したがって、出力は、棒グラフ１０１３、折れ線グラフ１０１５、あるいは、当業者であれば理解されるような任意の他の視覚化技法１０１７、の形態で、ユーザに対して提供されてもよい。視覚化技法は、単一のアプローチに限定されるものではなく、異なる視覚化技法を、互いに組み合わせたり、付加したり、混合又はブレンドしたり、してもよい。さらに、グラフ的な視覚化アプローチに代えて、テキスト出力を、結果を単純に表示する書き下しチャートの形態で提供してもよい。

図１１は、上述した例示的な実装に関連した例示的なグラフ的視覚化を示している。より具体的には、１１００では、１２週間という期間にわたって週単位で売上高収益を表示するチャートが提供される。１１０１では、１週間単位で測定された売上高の集計情報が表示されている。加えて、１１０３では、１週間単位で提供される予想売上高が表示されている。したがって、本明細書における例示的な実装に関連した測定売上高と、アナリストやアナリストコンセンサス等によって提供されるような予想売上高と、の間の差を図示した表示を、ユーザに対して提供し得る。

図９に戻ると、チャート９０７は、収益の比較を含む。よって、ユーザは、測定された収益が、アナリスト予想に基づく予測よりも約６．２％高いことを、詳細情報及び９０３を見ることによって、視覚化により理解することができる。このように、例示的な実装では、アナリストの予想と比較して、エンティティがオーバーパフォーマンスを発揮しているという決定を提供する。その結果、例示的な実装では、上述した態様で、９０５において「ストロングバイ」という推奨を生成する。

上記のハードウェア実装は、当業者であれば理解されるように、図９～図１０に関連した評価演算及び推奨演算を処理するために使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

アラートチェーン

図１２に示すように、例示的な実装に関連したさらに別のユーザ経験１２００によれば、アラートが、ユーザに対して提供される。選択されたアラートは、ユーザ１２０１に関して固有のアラートと、すべてのユーザにわたっての最も人気のあるアラートに関して集約されたリスト１２１３と、に分けられて、複数の行としてリストアップされている。上述したように、企業の名称及び株式記号と、アラートの根拠となる情報のタイプ１２０３と、アラートをトリガーする状況１２０５と、アラートを提供すべき頻度１２０７と、からなる列が提供される。ユーザに対しては、アラートを活性化又は非活性化に設定するためのツール１２０９と、アラートを編集するためのツール１２１１と、アラートを削除するためのツールと、が提供される。

例えば、限定するものではないが、第１行目に示すように、アラートは、パフォーマンスが５％よりも大きいことに基づいてもよい。第２行目に示すように、複数のアラートは、単一の企業に関連付けて提供され、この場合、価格が５％を超えて移動することであり、また、スコアが「オーバーパフォーマンス」の値を有することである。同様に、時間ベースのアラートが提供されてもよく、例えば、第３行目に示すように、ユーザに対して、収支報告の１０日前に、アラートが提供される。したがって、ユーザに対しては、企業に関連した１つ又は複数の状況によってトリガーされ得る一連のアラートが提供される。

また、図１２に示すように、ユーザは、ユーザベースにわたって生成されている最も人気のあるアラート１２１３と、それらのアラートを生成して使用しているユーザ１２１５の数と、を見ることができるようになっていてもよい。それらの人気のあるアラートのそれぞれに関しての、タイプや状況や頻度などの、詳細な情報が提供される。ユーザに対しては、「＋」記号１２１７によって示すように、それらのアラートを自分自身のユーザアラートチェーンに対して追加するという選択肢が提供される。

図１３は、アラートチェーンの処理に関連した演算１３００を示している。例えば、上述したように、タイプ、状況、パフォーマンス、価格、及びスコアを、データとして処理することにより、ユーザに対してアラートを提供するかどうかを決定することができる。さらに、ユーザは、ユーザのコミュニティ全体で使用されているアラートを閲覧して検討してもよく、これにより、他の人が生成したアラートの恩恵を受けることができる。例示的な実装によれば、ユーザは、そのようなルールにサブスクライブ（subscribe）してもよく、これにより、上記のシグナルの変化に応答してアラートを受信することができる。

１３０１では、シグナルの更新が実行される。より具体的には、図８の８０３に関して上述したようにして、シグナルの更新が実行される。例えば、限定するものではないが、シグナル強度ベクトルとシグナル強度分類とを含むがこれらに限定されるものではない、監視リストの出力が提供されてもよい。

１３０３では、シグナルの絶対値などの、あるいは、前回のシグナル更新と比較した場合のシグナルの相対値などの、１３０１の出力が、決定論的ルールに対して適用される。例えば、限定するものではないが、収益が、前回のシグナル更新と比較して２％増加しており、かつ、ユーザが、所与の企業について収益が２％以上増加したときにアラートを提供するようにルールを設定している場合には、ルールがトリガーされてもよい。図１２に関して上述したのと同様の又は他の決定論的ルールは、１３０１の更新情報が提供された際に、リアルタイムで処理される。したがって、監視リストの確率的出力が、ユーザの決定論的ルールベースに対して適用され、アラートは、各リアルタイム更新によって、トリガーされるか又はトリガーされないかのいずれかである。

１３０５では、通知生成演算が実行される。より具体的には、ユーザのルールベースに基づいて、ユーザのために、カスタム通知ペイロードが生成される。例えば、限定するものではないが、前のシグナル更新と比較して収益が２％以上増加した場合には、ユーザが株式を売却すべきとのアラートを受信するべきであると、ユーザが決定した際には、そのような通知ペイロードが生成される。

１３０７では、通知がユーザに対して配信される。配信チャネルは、モバイルアプリケーションの通知、電子メールの簡略化されたメッセージングサービス、あるいは、他の通信手段を含むがこれらに限定されるものではない、１つ又は複数のモードに設定されてもよい。したがって、ルールベースに対して提供されたリアルタイムシグナル更新に基づいてトリガーされた、ルールに関連した推奨事項を含む通知が、ユーザの所望の態様で、ユーザにプッシュされる。

いくつかの例示的な実装では、データ収集、価格チェック、及び計算に関するリアルタイム測定に基づいて、リアルタイムで推奨を提供してもよいけれども、例示的な実装は、推奨に限定されるものではない。上記の例示的な実装は、ユーザが意思決定のための入力及び実行を提供する必要がないような、自動取引を提供するアプローチと統合されてもよい。

図１４は、例示的な実装による意思決定の実行に関連したプロセス１４００を示している。より具体的には、アラートを受信するためにシグナル分類及びシグナル強度ベクトルをユーザが受信して閲覧することに代えて、ニューラルネットワーク内において機械学習などの人工知能技法を適用することにより、シグナル分類及びシグナル強度ベクトルを、意思決定の実行のために提出され得る意思決定シグナルへと変換する自動システムが提供される。例えば、限定するものではないが、シグナルは、仲介サービス（brokerage service）のための取引注文へと変換されてもよい。

１４０１では、上記の例示的な実装に従って、測定データが、複数の代替可能なデータソースから受信され、リアルタイムでもって自動ベースで処理され、これにより、重要なインジケータのためのリアルタイム更新が提供される。

１４０３では、更新が、等価ではあるが限定されるものではない取引モデルに対して入力され、取引モデルは、取引の意思決定を提供するために、ニューラルネットワーク内に機械学習などの人工知能アプローチを含んでもよい。例示的な実装によれば、取引モデルは、過去の株価と、例示的なＴａｔｉａｎによる測定シグナルに関連したシグナル更新の履歴と、によって訓練されたニューラルネットワークであってもよい。取引モデルへの入力は、シグナルデータと、ユーザのアカウントの現在の状態と、である。例えば、ユーザが、購入又は売却に関連した未決済注文又は保留注文を有している場合には、モデルは、この情報を考慮する。出力として、取引モデル１４０３は、他の例示的な実装で行われているようなアラート又は推奨に代えて、意思決定又はアクションを提供する。

１４０５では、注文が作成される。例えば、注文は、仲介サービスを含むがこれに限定されるものではない自動化された要求を販売者に対して提出することによって、任意選択的にユーザに対して注文を確認することによって、作成されてもよい。ユーザ確認については、図１３に関して上述したように、任意選択的に、通知配信チャネルによって提供されてもよい。

１４０７で、システムは、ユーザ閲覧が必要であるかどうかを決定する演算を実行する。ユーザ閲覧が必要でない場合には、注文は、１４０９で実行される。例えば、１４０５で作成された注文は、仲介サービスなどの販売者によって実行されてもよい。

これに代えて、１４０７では、ユーザ閲覧が必要な購入者であると決定された場合、１４１１において、上述したように、確認要求が、上述したようにして、通知配信チャネルを介して送信される。ユーザが１４１１において注文を確認した場合、注文は、１４０９で実行される。ユーザが、１４１１の注文を確認しない場合には、その注文は、拒絶されたものとみなされ、１４１３においてキャンセルされる。

より具体的には、プッシュ通知などの定期的な通知を、ユーザに対して提供してもよい。定期的な通知は、毎日又は毎朝の同じ時間に実行されるなどのように、定期的に行われてもよい。プッシュ通知は、データ条件に関連した情報を含み得るが、これに限定されるものではない。例えば、限定するものではないが、上記の例示的な実装に基づき、シグナルに関連した予測に基づいて、当該企業が収支報告を逸するなどのように、予想される状況を満たさないと予測されることが決定された場合には、ユーザに対して、そのデータ条件が通知されてもよい。さらに、ユーザに対して、信頼性を提示してもよい。一例示的な実装では、ユーザに対して、パーセンテージという単位で信頼性スコアが提供されてもよい。

加えて、例示的な実装によれば、プッシュ通知は、プッシュ通知で提供された情報に基づいて意思決定を行うためにシングルユーザアクションのみを必要とする選択可能な選択肢（「ユーザプロンプト」ともいう）を含んでもよい。例えば、限定するものではないが、ユーザに対して、「投資を希望するか」という質問に続いて、「はい」又は「いいえ」という選択可能な選択肢を提供してもよい。

ユーザが、「はい」という選択肢を選択した場合には、ユーザ嗜好などの事前に規定されたユーザ設定に基づいて、購入注文が実行される。一例示的な実装によれば、ユーザが、オンラインアプリケーションに関連したユーザ設定内に、注文を即座に実行するという初期設定を含めていた場合には、ユーザが遅延なく選択を行うとすぐに注文が提出されることとなる。別の例示的な実装によれば、注文は、営業日などの期間にわたって実行されてもよい。一例示的な実装によれば、ユーザは、一日の間に均等な間隔で１００万ドルなどの所定金額分の購入を実行するという初期設定を、ユーザ嗜好内に含めることができる。

任意選択的に、初期設定は、一日のうちの特定の部分では２０分間隔で密集しかつ一日のうちの別の部分では１時間又は２時間というより長い間隔で広がるなどのように、ユーザが、一日のうちの注文の割合を不均等な間隔で調整することを可能としてもよい。また任意選択的に、初期設定は、予測を提供する上記の例示的な実装における推奨という出力に基づいて、あるいは、その他のユーザが決定した初期設定に基づいて、ユーザが規定したプロファイル曲線に適合させるよう、また、次の期での株価の上昇又は下降の予測に適合させるよう、投資額が一日の初めに向けて前倒しされて一日の間に徐々に減少するように、あるいは、一日の間に徐々に増加しつつ一日の終わりに向けて集約されるように、一日の間にわたって均等となるように、ユーザが各注文の量を調整することを可能としてもよい。

同様に、ユーザ設定は、価格が制限価格を超えた場合には、その日の残りの時間では注文がもはや実行されないように、初期設定に制限注文を設けておいてもよい。よって、一例示的な実装によれば、１０００ドルの株式を５時間にわたって均等に分割して購入し、１時間ごとに２００ドルの注文を出すことに対して、ユーザが「はい」と選択した際に、株価が、３時間目に制限価格を超えた場合には、４時間目の２００ドルの注文は、株価が制限価格を超え続けていたならば、実行されないこととなる。同様に、５時間目において、株価が制限価格を超えていれば、その５時間目の注文は、成立しないこととなる。

注文の実行に関して、ユーザは、初期設定で、証券会社などの１つ又は複数の初期設定サービスプロバイダを提供してもよい。さらに、ユーザは、注文を実行するための１つ又は複数の証券取引所を提供してもよい。ユーザは、各証券会社に対して発注する注文全体の割合を、過去の推奨に対する過去の実績に基づいて、均等に又は不均等に又は比例的に自動的に分割して、指定してもよい。

注文サイズについては、ユーザ初期設定は、１００株などの所定の注文サイズ、あるいは、１０００ドル相当分などの、所定の金額を提供してもよい。よって、ユーザは、株数、金額、どの証券会社や証券取引所に問い合わせるか、注文を出すタイミング及び実行するタイミング、時間的に見た場合のタイミング又は金額に関する割合又は均等性、を決める必要はなく、なぜなら、それらパラメータが、予め用意されたユーザ設定に基づいて既に決定されているからである。したがって、ユーザは、「はい」又は「いいえ」を選択するだけで、ユーザが決定したユーザ初期設定に従って注文を実行することができる。

上記の例示的な実装は、単一の銘柄と、その単一銘柄を購入することに関連したシングルユーザアクションと、を参照しているけれども、例示的な実装は、これらに限定されるものではない。例えば、限定するものではないが、ユーザは、時間的に同時に、あるいは、所望のユーザの嗜好に基づいて時間的に分散して、異なる企業のそれぞれに関連した複数のプッシュ通知を受信してもよい。ユーザに対してのプッシュ通知内で提供される企業は、例えば特定割合を超えた信頼性スコアを有した企業などといったように、また、上記のユーザ経験に関する実装に示すようなユーザが関心を寄せている企業又はユーザが追跡している企業からなるリスト上にある企業などといったように、あるいは、例示的な実装によって決定された予測値と、公表された予想収支報告の間に所定しきい値の分だけ差を有した企業などといったように、ユーザの嗜好に基づいて決定されてもよい。

ユーザアクションと取引実行との間の１対１関係に加えて、「すべてに対して、はい」などの選択肢を選択することにより、一緒に提供される複数のプッシュ通知のすべてを１回の意思決定で実行するという選択肢を、ユーザに対して提供してもよい。そのような選択肢が選択された場合には、上述したように、事前に規定されたユーザの嗜好に従って、すべての注文が実行されることとなる。

上記の例示的な実装は、当業者に公知のモードによって、プッシュ通知を提供してもよい。例えば、限定するものではないが、プッシュ通知は、電子メール、テキストメッセージ又はＳＭＳ（ショートメッセージサービス）、オンラインソーシャルネットワーキングサービスを介したチャット、あるいは同種のもの、によって提供されてもよい。さらに、プッシュ通知は、視覚的な提示によって提供されてもよいだけではなく、Ａｍａｚｏｎ Ａｌｅｘａあるいは同種のものなどの家庭用デバイスのスピーカなどによる音声メッセージとして、代替的に又は併用的に提供されてもよい。

さらに、上記の例示的な実装では、５Ｇネットワークを含むがこれに限定されるものではない通信ネットワークを介することなどによって、シグナルを受信する運転者などのように、輸送中に選択肢を提供してもよい。よって、運転者は、スピーカ及びマイクを有した音声通信によって、あるいは、当業者であれば理解されるような他の入出力デバイスによって、上述したような注文を実行するための命令を、単一の音声コマンドによって実行してもよい。同様に、乗客が、また、システムを使用してもよい。よって、例示的な実装は、ハンズフリーでの注文を提供してもよい。

加えて、例示的な実装は、スマートフォンなどのモバイル通信デバイス上で実装され得るけれども、例示的な実装はそれに限定されるものではない。例えば、限定するものではないが、ユーザ設定は、推奨又はプッシュ通知に対してアクセスする前に、例えば２段階認証を要求することなどによって、認証されたデバイスから参加することをユーザに要求するように、単一行動購入モードの制御を、ユーザに対して提供してもよく、あるいは、プッシュ通知を受信するために、例えばログインや生体認証や２段階認証などの他の形態での認証が要求されるように、プライバシー保護態様を提供してもよい。同様に、ユーザが、音声応答を提供したり、画面上で特定の選択肢を選択したり、することに代えて、ユーザは、ジェスチャやシグナルや他の生体認証を使用することにより、意思決定を提示してもよい。

例えば、限定するものではないが、ユーザは、ユーザ設定において、第１の指が指紋検出器上に置かれた場合には、注文を実行すべきであることをユーザが示していると決定してもよく、他方、第１の指以外の指が指紋検出器上に置かれた場合には、注文を実行すべきではないことをユーザが示していると決定してもよい。このような例示的な実装は、ユーザが、ユーザインターフェースを聞いたり見たりすることはできても、ユーザのシングルアクションが注文を実行するか注文を実行しないかの意思決定であるかどうかを理解できない他人の存在下において、自身の意思決定を行うことを可能とする。上記の例では指紋を参照しているけれども、ユーザ設定において規定された他のジェスチャ又はユーザシグナルを採用してもよい。同様に、「はい」又は「いいえ」以外の音声コマンドを使用することによっても、また、ユーザの音声応答を聞いただけではユーザが何を意思決定したかを第三者に知られないようにすることができる。よって、ユーザインターフェースが他人に見られたり聞かれたりする状況であっても、ユーザのプライバシーは、保護される。

ハードウェアの観点では、上記の例示的な実装は、スマートフォン、ラップトップ、あるいは同種のもの、などのクライアントデバイス内において実装されてもよい。さらに、本明細書において上述したように、上記の例示的な実装は、例えば、自動車又は他の車両に関する、デバイス、プロセッサ、メモリなどの、あるいは、当業者であれば理解されるような他のデバイスなどの、他のデバイスと統合されてもよい。上記のユーザ経験は、テキスト入力、ラジオボタン、チェックボックス、スライダー、あるいは、当業者であれば理解されるようなユーザ入力及びユーザ出力に関する他の視覚的態様、によって入力されたパラメータとして、オンラインアプリケーションの「ユーザ設定」の態様で、ユーザによって提供されてもよい。

本明細書において説明する例示的な実装は、メモリ内に格納された機械可読実行可能命令の形態で実行されてもよく、これらの命令は、予め規定されたユーザ設定に対してアクセスするように構成され、これらの命令は、命令を実行することをユーザによって許可された１つ又は複数のデバイスがユーザ設定に対してアクセスし得るようにして、例えば局所的に又はクラウド内において遠隔的に、データベース内などへと格納されてもよい。命令は、また、オンラインユーザアプリケーションの形態で提供されてもよい。

プッシュ通知を提供するために上記の例示的な実装を実行する前に、ユーザは、ユーザ初期設定を入力しなければならない。オンラインアプリケーションがインストールされると、ユーザに関連した情報のプロファイルに基づいて、一連の初期設定が提供されてもよい。例えば、限定するものではないが、ユーザが、自分のリスクレベルを、高、中、又は低として自己認識した場合には、リスクプロファイルに関連した他のユーザ情報を集約することに基づいて、対応する一組の事前規定されたプロファイルから、初期設定を選択してもよく、これにより、ユーザの初期設定を、同様のリスクプロファイルを有した他のユーザに関する平均的な初期設定と一致させてもよい。リスク以外の要因を使用することにより、初期設定を決定してもよい。

加えて、ユーザは、複数の初期設定を有してもよく、オンラインアプリケーションによって自動的にアクセスされ得る異なるユーザ状況に応じて、異なる初期設定が適用されてもよい。例えば、限定するものではないが、オンラインアプリケーションが、銀行口座におけるユーザの利用可能な現金資金が所定レベルを超えていることを認識している場合には、初期設定は、ユーザ設定の金額、頻度、価格制限、又は更に他の態様が、投資資金の利用可能性の増加を考慮して又はリスクプロファイルの増加を考慮して調整されるような、ある１つの初期設定へと、設定されてもよい。

任意選択的に、ユーザは、収支報告の前後、会計年度の開始時／終了時、あるいは当業者であれば理解されるような他の重要なタイミングなどの、時間に関する日付に応じて設定を調整してもよい。同様に、タイミングは、雇用者の給料日後などの、あるいは、住宅ローンやクレジットカードや又は同種のものなどの月々の債務支払い後などの、ユーザの状態に基づくものであってもよい。同様に、オンラインアプリケーションは、新たな仕事、解雇、家又は車などの大きな購入、休暇、あるいは、他の金融イベントなどの、ユーザの経済状況の変化に基づいて、初期設定の中から変更を選択するようにユーザに促してもよい。よって、ユーザによる初期設定の選択は、部分的に又は完全に、支援又は自動化されていてもよい。これに代えて、１つ又は複数のユーザ設定を入力することに代えて、ユーザは、ユーザ設定に適用されるルールベースを生成してもよく、あるいは、プッシュ通知上の「はい」決定に対して直接的に適用されるルールベースを生成してもよい。

図２７は、上記の例示的な実装に関連した例示的なプロセス２７００を示している。より具体的には、例示的プロセス２７００は、シングルユーザアクションに基づいて注文を実行することを対象としており、その場合、注文は、ユーザ状況に基づいて、かつ、ユーザに対しての、シングルユーザアクションを促すデータ条件を含むプッシュ通知に応答して、実行される。

２７０１では、オンラインアプリケーションがインストールされた後に、ユーザに関連した情報を、ユーザ設定情報として受信する。例えば、限定するものではないが、上述したように、リスク情報、財務情報、人口統計学的情報、あるいは、ユーザに関連した他の情報などの、ユーザのプロファイルに関連した情報が、オンラインアプリケーションによって受信される。

２７０３では、ユーザ設定を決定する。より具体的には、２７０１でユーザから受信したユーザ設定情報は、一連の嗜好、しきい値、パラメータ、あるいは同種のものとして、データベース内などへと、集約されて保存される。さらに、上述したように、四半期末、年度末、給料日、主要な購入イベントの前後、あるいは同種のものなどといったような、期間中の現在時点などの、ユーザ設定を決定するための追加的な支援ツール又は自動化されたプロセスを考慮してもよい。演算２７０３の結果として、ユーザ設定は、ユーザ入力を必要とすることなく必要な命令又は注文の実行を提供するように、アクセスされて注文に対して適用され得るように、機械可読形式で保存される。

２７０５では、例示的な実装は、データ条件を決定するためにデータ処理を実行する。より具体的には、上述したように、異なるタイプの複数の代替可能なデータ入力が、処理されて正規化されるとともに、一連の演算に対して適用され、これにより、予測又は期待値又は推奨を生成する。さらに、推奨、予測、又は期待値は、また、関連した信頼性を有してもよい。よって、予想四半期収益などの予想情報と比較した予測又は期待値又は推奨と、推奨予測値又は期待値に関連した信頼性と、を含むデータ条件が生成される。

２７０７では、データ条件を、上述したように、ＳＭＳ、電子メール、あるいは同種のものなどの、プッシュ通知の形態でユーザに対して提供する。さらに、ユーザは、「はい」又は「いいえ」などのシングルユーザアクションを求める。ユーザは、提供されたデータ条件に基づいて、注文を実行するかどうかだけを決定しなければならない。２７０７での情報は、ユーザインターフェースを介してユーザに対して提供されるものであって、上述したように、視覚的な入力及び音声的な入力を含み得るが、これらに限定されるものではない。

２７０９では、シングルユーザ命令を受信する。シングルユーザ命令は、シングルユーザアクションに基づくものである。例えば、限定するものではないが、シングルユーザアクションとは、ユーザが「はい」又は「いいえ」を選択することである。これは、上述したように、クライアントデバイスに対しての視覚的な入力又は音声的な入力によって行われてもよく、クライアントデバイスは、これについても上述したように、携帯電話又はラップトップを含んでもよい。

２７１１では、シングルユーザアクションに関連した命令についての決定を行う。例えば、限定するものではないが、シングルユーザアクションが注文を実行することであるかあるいは注文を実行しないことであるかが決定される。２７１１での演算が、シングルユーザアクションが注文を実行しない命令であることが決定された場合には、プロセスは終了する。

他方、シングルユーザアクションが注文を実行する命令であることが決定された場合には、２７１３において、２７０３で決定されたユーザ設定に基づいて、注文を実行する。より具体的には、ユーザ設定は、注文を即座に実行するのかそれとも後の時間に実行するのか、また、注文を単一の取引として実行するのかそれとも複数の取引として実行するのか、また、複数の取引が要求された場合には、タイミングと金額を、一日にわたってあるいは他の期間にわたって均等に配分するのかそれとも不均等に分配するのか、また、一日にわたってあるいは他の期間にわたって不均等に分配する場合には、何らかの価格制限又は他の制限あるいはパターンが存在するのか、また、サービスプロバイダを構成する１つ又は複数の証券会社又は市場の識別が存在するのか、また、上述したような他のユーザ設定が存在するのか、などを含むがこれらに限定されるものではない情報を、提供する。よって、注文は、ユーザ設定と関連して、シングルユーザアクションに基づいて実行される。

１４１５では、注文が実行されたことを表示するように、ユーザのポートフォリオを更新する演算を実行する。任意選択的に、注文が実行されたことを確認するために、及び／又は、ポートフォリオの更新を提供するために、及び／又は、保留中のすなわち未解決の注文をユーザに思い出させるために、上述した通信チャネル又は配信チャネルを介して、ユーザに対してレポートを提供してもよい。

上記のハードウェア実装は、当業者であれば理解されるように、図１２～図１４に開示したアラートチェーンを処理するために使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

自動取引の態様に関する上記の例示的な実装は、連続的にかつリアルタイムで実行される。よって、複数の注文が同時に実行されてもよく、あるいは、実行の異なる段階にあってもよい。ユーザによる確認が要求される範囲では、ユーザは、いくつかの注文を実行することを、そして、他の注文を拒絶することを、さらに、他の注文をなおも保留とさせないことを、意思決定してもよい。ユーザによる確認が要求されない範囲では、実行前にユーザに対して何らの閲覧を提供することなく自動的な実行を継続してもよく、実行直後には、保留中の注文又は現在のポートフォリオの通知を提示してもよい。ユーザによる閲覧を必要としない場合の実行は、戦略的ではない別の主題である。正義のためのアイデンティティである利用可能性については、あるいは、個別又は定期購入に関する所定金額を超えるような、注文のエンティティ側の利用可能性については、変化が要求される。

上記の例示的な実装では、リストアップされた企業のそれぞれについて、重要なインジケータのタイプの決定、パフォーマンスの計算、及びスコアの生成、を自動的に実行する。ユーザ経験に関する上記の例示的な実装では、先行インジケータの決定及びパフォーマンスの比較が、リアルタイムベースで提供される。上述したように、ルールベースの決定論的なアプローチの混合物は、本明細書において説明する人工知能ニューラルネットワークアプローチなどの確率論的なアプローチと、混合される。アーキテクチャは、サーバーファーム内やクラウド内などのビッグデータサーバー上で実行されてもよい。したがって、バッチ処理を実行する関連技術におけるアプローチとは異なり、シグナルは、受信時にリアルタイムで処理される。さらに、クラウドコンピューティングが、また、使用されてもよい。必要な処理能力が利用可能な範囲では、例示的な実装に関連したシグナル処理は、自立型のマシン上で実行されてもよい。本例示的な実装が、リアルタイムの情報を提供し得ることのために、ユーザは、投資収益率に大きな影響をもたらすタイムリーな態様で、推奨を受信し得るとともに、意思決定を実行することができる。対照的に、関連技術におけるアプローチでは、リアルタイムの測定データの処理が考慮されることがなく、代わりに、予想データ情報が使用されるのみである。

上記の例示的な実装は、ラップトップコンピュータ又はデスクトップコンピュータなどのディスプレイの画面上に示されているけれども、例示的な実装は、ユーザ経験の観点から、それら２つに限定されるものではない。例えば、限定するものではないが、モバイルデバイスに関連したユーザ経験は、上記の例示的なユーザ経験と置き換えてもよく、あるいは、そのようなユーザ経験と組み合わせて使用してもよい。図１５～図１６は、モバイルデバイスに関連したそのような例示的な実装を示している。

さらに、図２８及び図２９は、例示的な実装に関連した追加的なユーザ経験を示している。例えば、図２８は、インターフェース２８００を示している。より具体的には、２８０１では、企業のパフォーマンスと業界のパフォーマンスとの比較が示されている。より具体的には、上記の例示的な実装によって提供された出力に基づいて、また、本明細書において説明するアーキテクチャ及び演算によって処理された代替可能なデータソースに基づいて、損益比較が生成され、これにより、シグナルに基づいて予想損益値が生成される。理解されるように、企業は、業界レベルを大きく上回るパフォーマンスを示している。２８０３では、業界セクションに対する損益比較が、例示的な実装に従ってシグナルによって生成された予想損益値と比較した場合の、アナリストの比較（例えば、オーバーパフォーマンス、アンダーパフォーマンス、ニュートラル）を提供している。

図２９は、本明細書に開示するような監視リスト上の企業の比較２９００に関連したユーザインターフェースを提供する。より具体的には、所定期間にわたっての、例えば直近の四半期にわたっての、銘柄ごとの結果が示されている。理解されるように、各企業は、評価の基礎となる指標、戦略の選択、期間中の損益結果、と一緒に表示されている。比較結果が、グラフで示されている。よって、複数の企業は、上述したようにして処理されて正規化されたデータを使用して比較され得るけれども、また、上述したように、企業の財務実績に関して最も重要な及び／又は最も敏感なパラメータに基づいて各企業を評価する能力も保持されている。

上記の例示的な実装は、また、企業に関連した商品やサービスに関する割引を、ユーザに対して提供するために使用されてもよい。割引は、リベート、報酬、値下げ、あるいは、ユーザに対する他の形態での利益又は補償、という形態とされてもよい。例えば、限定するものではないが、割引は、例示的な実装が上記の構造上で上記の演算を実行する例示的なユーザ経験に示されている企業のアカウント上におけるユーザの取引数量に基づいて、ユーザに対して提供されてもよい。

任意選択的に、例示的な実装によれば、フィードバックループが提供されてもよい。より具体的には、ユーザは、モデルの結果及び推奨に関する入力を提供してもよく、これらを使用することにより、モデルを校正してもよい。例えば、限定するものではないが、重要なパラメータ又はインジケータに基づいて、パフォーマンスと組み合わせて、ユーザが同意しない推奨が設定された場合には、ユーザは、システム内へのフィードバックに対して、提案を提供してもよい。ユーザは、重要なインジケータが適切ではないことを提案してもよく、代わりに、別の重要なインジケータを提案してもよく、また、推奨が望ましい推奨ではないことを提案することもできる。一例示的な実装によれば、ユーザは、ソーシャルメディア又はオンラインサービスの適切な重要なインジケータが、ユーザエンゲージメント又はユーザ数だけではなく、オンライン広告、クリック数、又は、いくつかの他のパラメータ、に関連していてもよいことを提示することができる。このフィードバックは、消費者の嗜好及び需要に応じて調整するように、予測ツールを再訓練又は再校正するためにシステムによって使用されてもよい。

任意選択的に、特定の状況下で特定の推奨を実装する自動取引ツールを提供してもよい。例えば、限定するものではないが、アラートチェーン上にもある監視リスト上のアイテムに関して、ユーザ嗜好におけるユーザからの命令は、アラートチェーン内の１つ又は複数の状況が満たされた時には、特定の株式を購入又は売却すべきであることを提示してもよい。任意選択的に、ユーザは、自動的に取引を実行するために、また、アラートを提供するために、全く異なる別個のアラートチェーンを作成してもよい。よって、売買は、ユーザによって自動的に実行されてもよく、これにより、あらゆる遅延が回避され、そのような命令が即座に提供される。このようなシステムは、特定のユースケースにおいて価値があり得る。例えば、限定するものではないが、自動化された取引ツールは、ユーザが旅行中又は休暇中である時に、活動のピーク期間又は激しい金融ニュースの際、ユーザがアラート又は推奨に対して迅速に又はタイムリーに対処できないような場合に、あるいは、単にユーザの利便性のために、価値があるものとすることができる。

例示的な実装によれば、自動化された取引ツールは、ユーザデバイスに関連したオンラインアプリケーションによって、ユーザ嗜好情報を受信することと、受信したユーザ嗜好情報に基づいて、１つ又は複数のユーザ設定を決定することであり、ここで、１つ又は複数のユーザ設定を、一連の嗜好又はしきい値又はパラメータとして、アクセス可能でありかつ自動化されたユーザ要求に対して適用され得る機械可読形式で、データベース内に集約して格納し、これにより、自動化されたユーザ要求の時点で、ユーザがユーザ嗜好を入力することなく自動化されたユーザ要求が実行されるものとすることと、データ条件を決定するためにデータを処理することであり、ここで、データ条件の決定に際しては、異なるタイプの複数の代替可能なデータ入力を処理して正規化するとともに一連の演算に対して適用し、これにより、信頼性を有した予測又は期待値又は推奨を生成し、さらに、データ条件を第三者エンティティ情報と比較することと、データ条件を示す電子通知を生成することであり、ここで、電子通知は、第三者エンティティ情報と比較されたデータ条件と、データ条件に関連した信頼性インジケータと、シングルアクションを実行するための問い合わせと、を含むものとすることと、シングルアクションを実行するための自動化された決定に応答して、ユーザデバイスが、自動化されたユーザ要求を実行するための自動命令を生成することと、自動命令に基づいて、決定された１つ又は複数のユーザ設定に基づき、自動化されたユーザ要求を実行することであり、ここで、ユーザ設定は、注文が即座に実行されるのか又は後の時間に実行されるのかに関する情報と、注文が単一の取引として実行されるのか又は複数の取引として実行されるのかに関する情報と、複数の取引が要求された場合には、タイミング及び金額が期間中にわたって均等に分散されるのか又は不均等に分散されるのかに関する情報と、期間中にわたって不均等に分散される場合には、何らかの価格制限又はパターンがあるのかに関する情報と、１つ又は複数の証券会社又は１つ又は複数の市場の識別に関する情報と、を含むものとすることと、を含んでもよい。

また、任意選択的に、上述したように企業の財務データを使用することに加えて、企業に関連した他の公開されている利用可能なデータを使用してもよい。例えば、限定されるものではないが、１つ又は複数のソーシャルメディアアカウント、業界イベント、ニュースリリース又は出版物、あるいは、他の情報に関連した企業のリーダーについて、パブリック向けアナウンス（public facing announcements）、ソーシャルメディアへの投稿（social media posts）、公開プレゼンテーション（public presentations）、あるいは、他の情報を感知又は検出してもよい。この情報は、センチメント分析内に組み合わされてもよい。

上記の例示的な実装は、様々な利点及び／又は利益を有し得る。例えば、限定するものではないが、例示的な実装は、パフォーマンスを自動的にかつリアルタイムで決定する方法を提供してもよい。関連技術におけるアプローチでは、手動で調査を実行し、多くの日数及び多くの時間をかけて手動でパフォーマンス提示を生成し、投資アドバイザーが手動でスコアを決定することがある。しかしながら、関連技術におけるアプローチでは、異なるデータソースから異種のデータを取得することと、正規化や重複除去や分類や任意選択的に他の演算などの、データに関する演算を実行することと、洗練されたデータを予測ツールに対して適用することと、特定のインジケータが重要であるという決定に基づいてすべて自動的にかつすべてリアルタイムで予測又は推奨を生成することと、を行う手法を、全く有していない。

この相違点は、重要であり、なぜなら、時間の経過や情報の分散や新たな情報や又は他のイベントによって予測が再び変更されるよりも前に、ユーザが効果的に意思決定を行ってタイムリーに意思決定を実行し得るよう、情報及び推奨が、リアルタイムで提供されなければならないからである。実際の連続した決定、並びに、再計算及び再予測は、正確で精度が高く、ユーザの意思決定の支援に利用可能な、情報及び推奨を提供する。

データクリーニング及びパイプライン処理

上記の例示的な実装によれば、ユーザは、パネルを作成するように情報提供される。本明細書で提供するように、パネルは、以下の選択プロセスに従って選択されてもよい。

予測に使用されるべき最適なパネルを、生成してもよい。より具体的には、選択プロセスは、パネルのための候補ユーザに関してフィルタ演算を実行することを含む。例えば、限定するものではないが、フィルタ演算は、１つ又は複数の基準を満たすパネルを生成するように、フィルタの適用によって実行されてもよい。本例示的な実装によれば、基準は、地理的位置について人口（例えば、米国の人口）を代表するユーザであって開始日から終了日までの（例えば、２０１１年から現在の日付までの）実質的に安定した購入数を有しかつ一定数の取引を有したユーザを含むパネルを含み得るが、これに限定されるものではない。任意選択的に、外れ値及び重複を除去してもよい。

図１７に示すようにして、選択プロセス１７００が実行されてもよい。最初に、候補ユーザのプールは、１７０１では、６０００万人のユーザからなる断片化されたパネルである。第１のフィルタプロセスが、候補ユーザのプールが地理的位置について人口を代表するようにフィルタリング演算を実行した後には、フィルタリングされたプールは、１７０３では、１５００万人のユーザへと絞られる。その後、時間間隔にわたって安定した購入数を確認するための別のフィルタ演算が実行され、１７０５では、候補ユーザのプールが、４００万人のユーザへと、さらに絞られる。１７０７では、外れ値及び重複が除去されてもよく、一定の取引数に関してのフィルタ演算が実行され、１５０万人のユーザからなる最適なパネルが生成される。

図１８は、例示的な実装によるデータパイプライン処理を示している。１８０１では、データの正規化を実行する。異なる機関から受信したデータは、異なる構造を有する可能性がある。異なる機関からのデータを適切に使用するためには、データを固定書式によって正規化しなければならない。より具体的には、データは、テキスト形式から、取引上で動作するように設計された分散型データベースへと変換される。

１８０３では、データクリーニング演算が実行される。より具体的には、データパイプライン処理１８００には必要とされないデータ又は所望されないデータが、除去される。例えば、限定するものではないが、重複した取引、重複したアカウント、及び重複したユーザが、識別されて除去される。さらに、データが欠落した不完全な取引などの不完全なデータも、また、データから除去される。したがって、また、パネル選択に関して上述したように、選択プロセス及びフィルタ演算を満たすユーザのベースは、ユーザデータベース内に維持され、外れ値及び重複が除去される。

データクリーニング１８０３の完了後には、分類演算１８０５を実行する。この演算では，データベース内の取引のそれぞれを分類する。分類は、取引の記述子を分析し、その記述子に対して正しい業者名を関連付けることによって、実行される。この演算では、関連付けの品質が、さらに後述することとなる相関及び拒絶の品質に対して、直接的にかつ決定的に影響を与える。より具体的には、１００％に近いような所望の精度に到達するために、自動化された機械学習アルゴリズムの組合せが、人間の手動制御に対して組み合わされる。

上記の分類演算１８０５の例として、例示的な抽出が提供される。一例示的な実装によれば、１ヶ月あたりの平均的な処理量は、２億回以上の取引であってもよく、それらの取引のそれぞれは、正しい企業に対して関連付けられていなければならない。

図１９は、例示的な抽出を示している。例示的な抽出１９００において理解されるように、業者の名称は、各取引において見受けられる。

上述したようにして、クリーニングされたデータが分類された後には、モデル化演算１８０７を実行する。より具体的には、モデル化演算１８０７は、予測を生成する。入力として、モデル化演算１８０７に対して、分類１８０５から出力されたデータと、例えばブルームバーグデータ１８０９などの第三者入力と、を適用する。モデル化演算１８０７では、多くの予測を組み合わせることにより、最適な結果を得る。モデル化演算１８０７は、企業に関連したカテゴリに特化される。さらに、モデル化演算１８０７は、季節性及び同種のものなどの、様々なバイアス要因を補償する。

図２０は、モデル化演算１８０７に関連した例示的な実装２０００を示している。より具体的には、データパイプライン処理１８００における上記の演算を受けた複数のパネルからなるセット２００１が、複数の対応する予測からなるセット２００３に対して提供され、予測からなるセット２００３の出力が複数のアセンブラ２００５に対して提供され、これにより、最終的な予測２００７が生成される。

モデル化演算１８０７では、異なるカテゴリの企業は、予測を生成するために異なるアルゴリズムを必要としてもよい。例えば、限定するものではないが、アルゴリズムは、企業内の収益の異なる構造に対しての、消費者の異なるアクションを組み込んでいなければならない。カテゴリのいくつかは、完全所有のレストラン、フランチャイズレストラン、スーパーマーケットチェーン、保険会社、及び他の企業、を含み得るが、これらに限定されるものではない。

モデル化演算１８０７はまた、バイアス補正を提供する。例えば、限定するものではないが、パネルデータは、トークン又は報酬と引き換えにデータを共有した数千人のユーザから、数年間の履歴データを含んでもよい。データを得るためのこのようなアプローチは、ランダム化されていないパネルが影響を与えるバイアスをより完全に理解することを可能とし、バイアスを補正するためのアルゴリズムを可能とする。

図２１は、情報の取得に関連したユーザ経験２１００を示している。２１０１では、ユーザに対して、データを入力し、紹介コードを入力するための入力画面と、調査の完了に関連し得るポイント数と、が提供される。２１０３では、ユーザによる調査完了により、ポイント数が増加し、ポイントを預け得る銀行を選択するための選択肢と、プライバシーポリシーと、が表示される。

バイアス補正を実行するために、過去のデータポイントを分析することにより、バイアスが経時的にどのように振る舞うかを決定する。一例示的な実装によれば、データのバイアスを調整するために９個のアルゴリズムが作成された。その後、それら９個のアルゴリズムを、ティッカーのために使用されかつバイアスの影響が少ない他の３つのアルゴリズムと組み合わせた。

１８１１では、モデル化の出力が提供されることで、予測を実行する。より具体的には、データが集約され、データベース内に挿入される。データベース内のデータは、トレーダなどの他のルールによってアクセスされて使用されることができ、検証、バックテスト、等のために、さらに取得される。

加えて、データパイプライン処理１８００は、異常検出１８１３～１８１９を含む。より具体的には、データパイプライン処理の各構成要素の出力は、最終的な予測を損いかねない異常を識別するために、異常検出の対象となる。異常検出１８１３～１８１９の一例として、パイプライン処理チェーン内におけるデータフローの異常は、技術的な異常と、データの異常と、を検査してもよい。

例えば、限定するものではないが、予測が実行される企業の振る舞いに関して異常が分析され、以下のものが提供され得るが、これらに限定されるものではない。

１．第三者のニュースソースから情報提供された買収又は売却。

２．例えば、限定するものではないが、ＳＥＣ（証券取引委員会）ファイルから情報提供された、会計基準などの、企業の振る舞いを変更させることとなる要件変更。

３．フランチャイズ店と個人所有店舗との比率の変化。

４．９０日から９７日へと変更することなどの、四半期の異なる期間。

５．四半期ごとに異なり得るような、数週間にわたっての特別販売促進活動又は他の促進活動。

６．企業による新製品のリリース。

例示的な実装によれば、代表性が考慮される。より具体的には、特定の例によれば、２０１９年の米国の人口は、約３億３０００万人であり、平均的な家族の人数は、３．１４人であり、よって、およそ１億５００万世帯が存在し、その数は１億２８００万世帯にも上るとする研究もある。例示的な実装では、米国の世帯数と最良パネルとの比率は、およそ７０対８５である。また、企業の申告収入とパネルの購入総額との比率は、約７０～９０である。この比率は、期待値と一致しているとともに、異なる企業間で一貫しており、そのため、消費者の割合は、例示的な実装によるパネルを適切に維持している。

図２２Ａ及び図２２Ｂは、データとの比較に関する様々な例を示している。図２２Ａは、フランチャイズの例を含み、図２２Ｂは、買収の履歴又は異常な履歴を有した企業の例を含む。

図２３は、例示的な実装による結果と関連技術におけるアプローチとの間の比較を示している。例示的な実装に関する「ＤＦ」で示された列と、関連技術におけるアプローチに関する「１０１０データ」で示された列と、から理解されるように、予測結果における実質的な違いは、例示的な実装においてパフォーマンスが大幅に向上したことを示している。

図２４は、パネルサイズの決定及び実際の統計誤差の測定のための統計的手法に従った技術的根拠を示している。

中心極限定理から、予測に関する理論的％誤差は、次式によって与えられる。

予測における誤差％は、購入のサンプル標準偏差に比例し、購入数及び平均金額の平方根に反比例する。

このことは、パネルサイズが、正確な予測を生成するのに充分であることを、意味する。

以前に発表された収益を使用することによりデータを修正して調整していることにより、実際の統計誤差は、さらに小さくなる。

上述したハードウェア実装は、当業者であれば理解されるように、図１８～図２４の演算を処理するために使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

例示的な環境
図２５は、いくつかの例示的な実装に適した例示的な環境を示している。環境２５００は、デバイス２５１０～２５５５を含み、これらのデバイスのそれぞれは、例えばネットワーク２５６０（例えば、有線接続及び／又は無線接続による）を介して、少なくとも１つの他のデバイスに通信可能に接続されている。いくつかのデバイスは、１つ又は複数のストレージデバイス２５４０及び２５４５に対して通信可能に接続されてもよい。

１つ又は複数のデバイス２５１０～２５５５の例は、それぞれ図２６に記載されたコンピューティングデバイス２６００であってもよい。デバイス２５０５～２５５５は、モニタを有したコンピュータ２５１０（例えば、ラップトップコンピューティングデバイス）、モバイルデバイス２５１５（例えば、スマートフォン又はタブレット）、テレビ２５２０、車両２５２５に関連したデバイス、サーバコンピュータ２５３０（単に「サーバ」ともいう）、コンピューティングデバイス２５３５及び２５５０、ストレージデバイス２５４０及び２５４５、並びに、スマートウォッチ又は他のスマートデバイス２５５５、を含み得るが、これらに限定されるものではない。

いくつかの実装では、デバイス２５１０～２５２５及び２５５５は、企業のユーザに関連したユーザデバイスと見なされてもよい。デバイス２５３０～２５５０は、サービスプロバイダに関連したデバイスであってもよい（例えば、上述したようなサービスを提供するために外部ホストによって使用され、データの収集及び保存に関して使用される）。

上述したハードウェア実装は、当業者であれば理解されるように、図２５の環境で使用されてもよい。より具体的には、例えば、限定するものではないが、本明細書において説明する例示的な実装による外部データフェッチは、外部の第三者（例えば、ベンダー）からデータをコピーし、そのデータをクラウドストレージコンテナ内に格納することによって、実行されてもよい。データフェッチプロセスは、スケジューリングサーバによって、及び／又は、外部データストレージ及び関連した計算リソースを管理するために演算を実行するサーバレス計算サービスによって、管理されてもよい。さらに、本明細書において説明するデータの抽出、変換、及び導入は、バッチ管理プロセッサ又はバッチ管理サービスによって実行されてもよい。バッチコンピューティングとは、ユーザによる手動介入を必要とすることなく、例えば自動的に、１つ又は複数のプロセッサ上において、一連の実行可能な命令（「ジョブ」）を実行することである。入力パラメータは、スクリプト、コマンドライン引数、制御ファイル、あるいは、ジョブ制御言語によって、予め定義されてもよい。バッチジョブは、先行するジョブの完了に対して、あるいは、特定の入力の利用可能性に対して、関連付けられていてもよい。よって、複数のジョブの順序付け及びスケジューリングが重要となる。任意選択的に、バッチ処理は、双方向的な処理と一緒に実行されなくてもよい。例えば、バッチ管理プロセッサ又はバッチ管理サービスは、ユーザがジョブキューとジョブ定義とを作成するとともに、ジョブ定義を実行して結果を確認することを許可してもよい。例示的な実装によれば、バッチクラスタは、２５６個のＣＰＵｓと、６４個のコア及び３１２ＧＢのＲＡＭを有したＥＴＬ専用サーバと、を含む。ランニングインスタンスの数は、１であってもよい。上記のＥＴＬインフラストラクチャは、また、見通し抽出のプロセスに適用されてもよい。さらに、データアクセスのために、ＡＰＩが提供されている。例えば、限定するものではないが、ＲＥＳＴスタイルのアーキテクチャに準拠していて、ＲＥＳＴｆｕｌリソースとの対話を可能とするＲＥＳＴ ＡＰＩが、サービス上で実行されてもよい。サービスは、限定するものではないが、１ｖＣＰＵ、２ＧＢ ＲＡＭ、１０ＧＢ ＳＳＤディスク、及び、最小で２つのランニングインスタンス、などのハードウェアを含んでもよい。ＡＰＩは、オンラインアプリケーションロードバランサを介してインターネットに対して公開されてもよく、このロードバランサは、弾力性があり、着信したエンドユーザを、クラウド内をベースとしたオンラインアプリケーションに対して構成してルーティングすることができ、任意選択的に、複数のアベイラビリティゾーン内の複数のターゲットにわたってトラフィックをプッシュすることができる。キャッシング層は、高速コンテンツ配信ネットワーク（ＣＤＮ）サービスによって提供されてもよく、本明細書において説明するデータを、低遅延でかつ高速な転送速度で、安全に配信し得る。例示的な実装によれば、コンテナに関連した演算を実行するために、仮想マシン上のクラスタを、設定したり、構成したり、又は拡縮したり、する必要がないように、サーバ又はインスタンスのクラスタを管理する必要なく、コンテナを実行し得る。

例示的なコンピューティング環境
図２６は、少なくとも１つの例示的な実施形態を実装するのに適した例示的なコンピューティングデバイスを有した例示的なコンピューティング環境を示している。コンピューティング環境２６００内のコンピューティングデバイス２６０５は、１つ又は複数の処理ユニット、コア、又はプロセッサ２６１０、メモリ２６１５（例えば、ＲＡＭ、ＲＯＭ、及び／又は同様のもの）、内部ストレージ２６２０（例えば、磁気ストレージ、光学ストレージ、ソリッドステートストレージ、及び／又は有機ストレージ）、並びに、Ｉ／Ｏインターフェース２６２５、を含むことができ、これらのすべては、情報を通信するための通信メカニズム又はバス２６３０上において結合することができる。プロセッサ２６１０は、汎用プロセッサ（ＣＰＵｓ）及び／又は特殊目的プロセッサ（例えば、デジタル信号プロセッサ（ＤＳＰｓ）、グラフィックス処理ユニット（ＧＰＵｓ）、及び他のもの）とすることができる。

いくつかの例示的な実施形態では、コンピューティング環境２６００は、アナログ－デジタル変換器、デジタル－アナログ変換器、及び／又は、無線周波数ハンドラ、として使用される１つ又は複数のデバイスを含んでもよい。

コンピューティングデバイス２６０５は、入力／ユーザインターフェース２６３５と、出力デバイス／インターフェース２６４０と、に対して通信可能に結合することができる。入力／ユーザインターフェース２６３５と、出力デバイス／インターフェース２６４０と、のうちの、一方又は双方は、有線インターフェース又は無線インターフェースとすることができ、着脱可能なものとすることができる。入力／ユーザインターフェース２６３５は、入力を提供するために使用され得る、物理的な又は仮想的な、任意のデバイス、構成要素、センサ、又はインターフェース（例えば、キーボード、ポインティング／カーソル制御、マイク、カメラ、点字、モーションセンサ、光学リーダ、及び／又は、同様のもの）を含んでもよい。出力デバイス／インターフェース２６４０は、ディスプレイ、モニタ、プリンタ、スピーカ、あるいは同種のもの、を含んでもよい。いくつかの例示的な実施形態では、入力／ユーザインターフェース２６３５と、出力デバイス／インターフェース２６４０とは、コンピューティングデバイス２６０５（例えば、ボタン又はタッチスクリーン入力／ユーザインターフェースと、出力又は印刷ディスプレイと、を有したモバイルコンピューティングデバイス、あるいは、テレビ）に対して組み込まれることができる、あるいは、コンピューティングデバイス２６０５に対して物理的に結合されることができる。

コンピューティングデバイス２６０５は、同じ又は異なる構成の１つ又は複数のコンピューティングデバイスを含む、任意の数のネットワーク化された構成要素、デバイス、及びシステム、と通信するために、外部ストレージ２６４５及びネットワーク２６５０に対して通信可能に結合することができる。コンピューティングデバイス２６０５又は任意の接続されたコンピューティングデバイスは、サーバ、クライアント、シンサーバ、一般的なマシン、特別目的のマシン、又は別のラベル、として機能することができ、又は、そのようなものとしてサービスを提供することができ、又は、そのようなものとして参照することができる。

Ｉ／Ｏインターフェース２６２５は、コンピューティング環境２６００内の少なくともすべての接続された構成要素、デバイス、及びネットワークの間にわたって情報を通信するための、任意の通信又はＩ／Ｏプロトコル又は規格（例えば、イーサネット（登録商標）、８０２．１ １ｘ、ユニバーサルシステムバス、ＷｉＭａｘ、モデム、セルラーネットワークプロトコル、及び同種のもの）を使用した有線インターフェース及び／又は無線インターフェースを含み得るが、これらに限定されるものではない。ネットワーク２６５０は、任意のネットワーク又はネットワークどうしの組合せ（例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、電話ネットワーク、セルラーネットワーク、衛星ネットワーク、及び同種のもの）とすることができる。

コンピューティングデバイス２６０５は、一過性媒体及び非一過性媒体を含む、コンピュータ使用可能媒体又はコンピュータ可読媒体を使用することができる、及び／又は、そのような媒体を使用して通信することができる。一過性媒体は、伝送媒体（例えば、金属ケーブル、光ファイバ）、信号、搬送波、及び同種のもの、を含む。非一過性媒体は、磁気媒体（例えば、ディスク、テープ）、光学媒体（例えば、ＣＤ ＲＯＭ、デジタルビデオディスク、ブルーレイディスク）、ソリッドステート媒体（例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ソリッドステートストレージ）、及び、他の不揮発性のストレージ又はメモリ、を含む。

コンピューティングデバイス２６０５は、少なくとも１つの実施形態（例えば、説明した実施形態）を実装するための技法、方法、アプリケーション、プロセス、又は、コンピュータ実行可能命令、を実装するために使用することができる。コンピュータ実行可能命令は、一過性媒体から取得され得るとともに、非一過性媒体に保存することができ、それら非一過性媒体から取得することができる。実行可能命令は、任意のプログラミング言語、スクリプト言語、及び機械言語（例えば、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、ＪａｖａＳｃｒｉｐｔ（登録商標）、及び他のもの）のうちの、１つ又は複数に由来することができる。

１つ又は複数のプロセッサ２６１０は、任意のオペレーティングシステム（ＯＳ）（図示せず）の下で、ネイティブ環境又は仮想環境内で、実行することができる。説明した実施形態を実装するために、論理ユニット２６５５、アプリケーションプログラミングインターフェース（ＡＰＩ）ユニット２６６０、入力ユニット２６６５、出力ユニット２６７０、サービス処理ユニット２６９０、及び、異なるユニットが、互いに通信するための、またＯＳと通信するための、さらに他のアプリケーション（図示せず）と通信するための、ユニット間通信メカニズム２６９５、を含む１つ又は複数のオンラインアプリケーションを、展開することができる。例えば、代替可能なデータ処理ユニット２６７５、タグ付けユニット２６８０、及びモデル化／予測ユニット２６８５は、上述した１つ又は複数の処理を実装してもよい。説明したユニット及び構成要素は、設計、機能、構成、又は実装、において変更されることができ、提供された説明に限定されるものではない。

いくつかの例示的な実施形態では、情報又は実行命令が、ＡＰＩユニット２６６０によって受信された時には、その情報又は実行命令は、１つ又は複数の他のユニット（例えば、論理ユニット２６５５、入力ユニット２６６５、出力ユニット２６７０、サービス処理ユニット２６９０）に対して通信されてもよい。例えば、入力ユニット２６６５は、ＡＰＩユニット２６６０を使用することにより、他のデータソースと接続してもよく、これにより、サービス処理ユニット２６９０は、情報を処理することができる。サービス処理ユニット２６９０は、上述したように、パネリストのフィルタリング、データのフィルタリング及びクリーニング／正規化、並びに、結果の生成、を実行する。

いくつかの例では、論理ユニット２６６０は、ユニットどうしの間の情報フローを制御するように構成されてもよく、また、上述した実施形態を実装するために、ＡＰＩユニット２６６０、入力ユニット２６６５、出力ユニット２６７０、代替可能なデータ処理ユニット２６７５、タグ付けユニット２６８０、及び、モデル化／予測ユニット２６８５、によって提供されるサービスを案内するように構成されてもよい。例えば、１つ又は複数のプロセス又は実装のフローは、論理ユニット２６５５単独で、あるいは、ＡＰＩユニット２６６５と連携して、制御されてもよい。

いくつかの例示的な実装について図示して説明したけれども、これらの例示的な実装は、本明細書において説明する主題を、この分野に精通している人々に対して伝えるために、提供されている。本明細書において説明する主題が、説明した例示的な実装に限定されることなく、様々な態様で実装されてもよいことは、理解されよう。本明細書において説明する主題は、具体的に規定又は説明された事項がなくても実施することができる、あるいは、説明されていない他の異なる構成要素又は事項を使用して実施することができる。当業者であれば、添付の特許請求の範囲及びその等価物によって規定される本明細書の主題から逸脱することなく、これらの例示的な実装に関して、変更を行い得ることは、理解されるであろう。

Claims (20)

1. 少なくとも１つのハードウェアプロセッサを使用する方法であって、前記ハードウェアプロセッサが、
   １以上のエンティティに関連する複数のデータを複数のデータソースから受信し、
   前記複数のデータに予測モデルを適用して、前記１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、
   監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、前記監視リストは、前記１以上のエンティティのそれぞれについて、前記エンティティの識別子、前記エンティティについて予測された前記重要指標の識別子、前記エンティティについて予測された前記重要指標に関連する値、及び、前記エンティティについて予測された前記重要指標に関連する前記値に基づく推奨を含み、
   前記グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する、
   ことを有する方法。
2. 前記機械学習モデルは、複数のアルゴリズムを含み、前記複数のアルゴリズムのそれぞれは、複数の異なる収益構造のうちの１つに関連し、前記機械学習モデルを適用することは、前記１以上のエンティティのそれぞれについて、前記エンティティの収益構造に関連する前記複数のアルゴリズムのうちの１つを適用することを有する、請求項１に記載の方法。
3. 前記１以上のエンティティは、第１のエンティティ及び第２のエンティティを含む複数のエンティティであり、前記予測モデルは、複数の重要指標の中から前記第１のエンティティについて第１の重要指標の値を予測し、複数の重要指標の中から前記第２のエンティティについて第２の重要指標の値を予測し、前記第１の重要指標は、前記第２の重要指標と異なる、請求項１に記載の方法。
4. 前記複数の重要指標は、収益を含む、請求項３に記載の方法。
5. 前記複数の重要指標は、サブスクライブしたユーザ数を含む、請求項３に記載の方法。
6. 前記複数の重要指標は、店舗の来客数を含む、請求項３に記載の方法。
7. 前記複数の重要指標は、オンラインアプリ又はプラットフォーム上で費やされた時間を含む、請求項３に記載の方法。
8. 前記少なくとも１つのハードウェアプロセッサが、前記１以上のエンティティのそれぞれについて、前記エンティティのタイプに基づいて前記予測モデルによって前記エンティティについて予測される前記重要指標を選択することを更に有する、請求項３に記載の方法。
9. 前記少なくとも１つのハードウェアプロセッサが、前記１以上のエンティティの少なくとも１つについて、前記少なくとも１つのエンティティに関連する前記複数のデータの変化に基づいて前記予測モデルによって前記エンティティについて予測される前記重要指標を変更することを更に有する、請求項８に記載の方法。
10. 前記重要指標に関連する前記値は、前記重要指標の値の予測された変化を含む、請求項１に記載の方法。
11. 前記複数のデータは、リアルタイムで受信される、請求項１に記載の方法。
12. 前記複数のデータを受信することは、スケジューリングサービスによって、データを外部システムからフェッチして、前記データをクラウドストレージコンテナ内に格納することを有する、請求項１に記載の方法。
13. 前記複数のデータを受信することは、予め定義された入力パラメータに基づいて、格納されたデータから前記複数のデータをバッチ処理で抽出、変換及び導入することを更に有する、請求項１２に記載の方法。
14. 前記１以上のエンティティのそれぞれについて、前記推奨は、前記エンティティがオーバーパフォーマンス、ニュートラル又はアンダーパフォーマンスしているかを示す、前記エンティティについて予測された前記重要指標に関連する前記値に基づく単一の単語を含む、請求項１に記載の方法。
15. 前記１以上のエンティティのそれぞれについて、前記推奨は、前記エンティティについて予測された前記重要指標に関連する前記値に基づく数値スコアを含む、請求項１に記載の方法。
16. 前記１以上のエンティティのそれぞれについて、前記数値スコアは、前記エンティティのサイズに更に基づく、請求項１５に記載の方法。
17. 前記複数のデータは、前記１以上のエンティティの財務データ、前記１以上のエンティティによるパブリック向けアナウンス、前記１以上のエンティティによるソーシャルメディアへの投稿、前記１以上のエンティティによる公開プレゼンテーション、又は前記１以上のエンティティのリーダーが投稿した公開情報のうちの１以上を含む、請求項１に記載の方法。
18. 前記複数のデータへの前記予測モデルの前記適用は、少なくとも１つのグラフィックス処理ユニット（ＧＰＵ）によって実行される、請求項１に記載の方法。
19. 少なくとも１つのハードウェアプロセッサと、
    １以上のソフトウェアモジュールであって、前記少なくとも１つのハードウェアプロセッサによって実行されたときに、
    １以上のエンティティに関連する複数のデータを複数のデータソースから受信し、
    前記複数のデータに予測モデルを適用して、前記１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、
    監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、前記監視リストは、前記１以上のエンティティのそれぞれについて、前記エンティティの識別子、前記エンティティについて予測された前記重要指標の識別子、前記エンティティについて予測された前記重要指標に関連する値、及び、前記エンティティについて予測された前記重要指標に関連する前記値に基づく推奨を含み、
    前記グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する、
    ように構成されたコンピュータ実行可能命令を含む１以上のソフトウェアモジュールと、
    を有するシステム。
20. 命令を記憶した非一時的なコンピュータ可読媒体であって、前記命令は、ハードウェアプロセッサによって実行されたときに、前記ハードウェアプロセッサに、
    １以上のエンティティに関連する複数のデータを複数のデータソースから受信し、
    前記複数のデータに予測モデルを適用して、前記１以上のエンティティのそれぞれについてパフォーマンスの重要指標の値を予測し、
    監視リストを含むグラフィカルユーザインターフェースを生成し、ここで、前記監視リストは、前記１以上のエンティティのそれぞれについて、前記エンティティの識別子、前記エンティティについて予測された前記重要指標の識別子、前記エンティティについて予測された前記重要指標に関連する値、及び、前記エンティティについて予測された前記重要指標に関連する前記値に基づく推奨を含み、
    前記グラフィカルユーザインターフェースを少なくとも１人のユーザに提供する、
    ようにさせる、非一時的なコンピュータ可読媒体。

Images