JP2022515115A - 個別ユーザのために個人化された食事及び健康のアドバイス又は提案を生成するための自動化された方法及びシステム - Google Patents

Abstract

様々なソースからの栄養及び健康データを分析に適した構造化ファイル形式に標準化するための自律機能を備えたサーバレスアーキテクチャを利用することができる方法、システム、及びプラットフォームが提供されている。プラットフォームは、認証構成要素、データ取り出し構成要素、パイプライン構成要素、標準化構成要素、及びストレージ構成要素を含み得る。構成要素は、自律機能のセット、ストリーミングアプリケーション、通知メッセージ、及び互いに論理的に接続された他のオブジェクトを含み得る。構成要素は、直列に接続されることができ、データは、ストリームで順次に構成要素を通って流れることができる。開示されたアーキテクチャを使用することで、プラットフォームは、大量のデータを効率的で費用効果の高い様式で集約して処理し、標準化された構造化データを分析し、個別のエンドユーザへの個人化された食事及び健康のアドバイス又は提案を生成することができる。

Description

関連出願の相互参照
本出願は、２０１８年１２月１９日に出願された米国仮特許出願第６２／７８２，２７５号の利益と優先権を主張し、及び２０１９年１２月１０日に出願された米国特許出願第１６／７０９，７２１号の利益と優先権を主張し、これらの内容は、参照によりその全体が本明細書に組み込まれている。

本明細書に記載の主題の実施形態は、一般に、個人化された食事及び健康のアドバイス又は提案、並びにそれを自動的に作成するための技法及び技術を提供することに関する。より具体的には、本主題の実施形態は、データを自動的に収集して処理し、個別ユーザのための個人化された食事及び健康のアドバイス又は提案を生成するサーバレスアーキテクチャに関する。

近年、健康に関するデータを顧客に提供するために、いくつかのデバイス及びソフトウェアアプリケーションが開発されている。これらのデバイス及びソフトウェアアプリケーションは、活動を監視することができ、人々が食料消費及び運動習慣を監視し、睡眠パターンを監視し、ユーザから健康情報を受動的に収集することを可能にしている。しかしながら、現在、このすべてのデータを標準化してまとめて処理するための業界標準は存在しない。特に、収集されたデータは、データが様々なソースから様々な異なる形式で取得されているため、統合することが困難である。このことが、ユーザが彼らの栄養ニーズについての完全な情報を有することを困難にしており、したがって、ユーザが、食品消費及び異なる食品の自身の健康に対する影響についてタイムリーで情報に基づいた判断をする能力を阻害している。

様々な食品関連、栄養、健康のデータを統合して処理することは、多くの課題を提示している。例えば、データは、異なるデータタイプ（例えば、構造化又は非構造化、時系列など）として提供されることができ、有用な情報を抽出及び伝達するために、異なる方法又はツールを使用して処理されることができる。加えて、これらのデバイス及びソフトウェアアプリケーションで収集されるデータの量は膨大になる可能性があり、定期的な、又はランダムな頻度で収集されている数千又は数百万のデータポイントのオーダになっている。収集されたデータの量は、デバイス及びソフトウェアアプリケーションがユーザの日常生活とますます相互接続されるようになるにつれて、時間経過とともに指数関数的に増加する傾向がある。場合によっては、アプリケーションプログラミングインターフェース（ＡＰＩ）が更新されると、その変更によって特定のＡＰＩが誤動作してデータが損失することがある。

したがって、様々な異なるソースからの食品関連、栄養、並びに健康のデータの統合、及び処理に関する課題を含む、そのような問題に対処するための技術、システム、方法、及び技法を提供することが望ましい。さらに、他の望ましい特徴及び特性は、添付の図面及び前述の技術分野及び背景と併せて、以下の詳細な説明及び添付の特許請求の範囲から明らかになるであろう。

大量の食品関連、栄養、及び健康のデータをスケーラブルな様式で処理し、データが生成されて処理される速度の予測不可能性を管理することができるプラットフォームが本明細書に開示されている。開示されたプラットフォームはまた、多くの異なるデータタイプを処理することができ、複数の異なるソースからデータを受信するように適合されることができる。プラットフォームはまた、データ処理やデータ損失に関する問題を生じることなく、基盤となるＡＰＩに加えられた変更をサポートすることもできる。

本明細書に開示されるプラットフォームは、大量の食品関連、栄養及び健康のデータの処理、統合、及び構造化を可能にする１つ以上のモジュールを含み得る。モジュールは互いに切り離すことができ、それによって、各構成要素又はモジュールの保守及び再利用が容易になることを確実にしている。本明細書に開示されているプラットフォームは、サーバレスアーキテクチャを採用することにより、大量のデータを処理することができる。サーバレスアーキテクチャでは、ＡＭＡＺＯＮ（登録商標）Ｌａｍｂｄａなどのツールを利用して、データをプラットフォーム経由でストリーミングすることができ、コード処理は、ストリーミングデータによって処理機能がトリガーされた場合にのみ実施することができる。このような関数は「ラムダ関数」として広く知られている。このようにラムダ関数を使用することで、コンピューティングリソースを継続的に実行する必要がないことから、データを処理するためのコンピューティングリソースがより効率的に利用されることが可能になる。サーバレスアーキテクチャは、本明細書に開示されているプラットフォームが大量のデータを効率的に処理することを可能にすることができる。

プラットフォーム構成要素は、多くのデータタイプとインターフェースするように構成され得る。取り出しモジュールでは、ラムダ関数のセットが、接続されたアプリケーションからデータをプルして、定期的にデータを取り出す時間ベースのタスクスケジューラを実装するように構成され得る。ラムダ関数の別のセットは、接続されたアプリケーションから通知を受信し、プッシュされたデータを受信する準備をすることができる。ラムダ関数の別のセットは、プルされたデータとプッシュされたデータとを統合してプラットフォームを介してカスケードされるストリームにデータを送信することができる。追加のラムダ関数は、処理のためにストリームからデータを迂回することができ、これにより、データを標準化された構造化された形式に変換することができる。変換された構造化データは、栄養及び健康に関する見識又は提案をユーザに提供するために、さらに分析されることができる。

本開示の一実施形態では、データ収集及び処理方法が提供されている。本方法は、サーバレスアーキテクチャを使用して実装され得る。サーバレスアーキテクチャは、本方法がスケーリングされ、データの新しいタイプ若しくは形式、又はそれらが導入された新しいソースをサポートすることを可能にする。本明細書に開示される方法は、複数の異なるソースからデータを収集して集約することを含み得、このデータは、データの異なるタイプ又は形式で構成されている。異なるタイプ又は形式のデータには、構造化データ並びに非構造化データ、及び時系列センサデータが含まれ得る。データは、複数の個別ユーザに固有の食品、健康、又は栄養に関するデータを含み得る。本方法は、異なるタイプ又は形式のデータを健康及び栄養プラットフォームと互換性のある標準化された構造化形式に変換することにより、データのソースにとらわれない様式で異なるタイプ又は形式のデータの各々を継続的に処理することをさらに含み得る。本方法はまた、健康及び栄養プラットフォームからの情報を部分的に使用して、標準化された構造化形式に変換されたデータを分析することを含み得る。標準化された構造化データは、１つ以上の機械学習モデルを使用して分析され得る。この分析に基づいて、個人化された食事及び健康のアドバイス又は提案が、複数の個別ユーザの各々のために生成されることができる。

いくつかの実施形態では、複数の異なるソースは、モバイルデバイス、ウェアラブルデバイス、医療デバイス、家電製品、又はヘルスケアデータベースのうちの２つ以上を含み得る。モバイルデバイスは、スマートデバイス（スマートフォン、タブレットなど）を含み得、ウェアラブルデバイスは、以下の１つ以上を含み、それらは、アクティビティトラッカー、スマートウォッチ、スマートグラス、スマートリング、スマートパッチ、抗酸化モニタ、睡眠センサ、バイオマーカー血液モニタ、心拍変動（ＨＲＶ）モニタ、ストレスモニタ、温度モニタ、自動スケール、体脂肪モニタ、又はスマートファブリックである。医療デバイスは、血糖モニタ、心拍数モニタ、血圧モニタ、汗センサ、インスリンポンプ、ケトンモニタ、乳酸モニタ、鉄分モニタ、又はガルバニック皮膚反応（ＧＳＲ）センサのうちの１つ以上を含み得る。本明細書に記載の主題の例示的な実施形態は、携帯型電子医療デバイスなどの医療デバイスと併せて実装されることができる。多くの異なる用途が可能であるが、一実施形態は、注入システム展開の一部としてインスリン注入装置（又はインスリンポンプ）を組み込むことができる。簡潔にするために、注入システムの作動、インスリンポンプ及び／又は注入セットの作動、及びシステム（及びシステムの個々の作動構成要素）の他の機能的態様に関連する従来の技術は、ここでは詳細に説明されない場合がある。注入ポンプ（例えば、インスリンポンプ）の例は、限定するものではないが、米国特許番号第４，５６２，７５１号、同第４，６８５，９０３号、同第５，０８０，６５３号、同第５，５０５，７０９号、同第５，０９７，１２２号、同第６，４８５，４６５号、同第６，５５４，７９８号、同第６，５５８，３２０号、同第６，５５８，３５１号、同第６，６４１，５３３号、同第６，６５９，９８０号、同第６，７５２，７８７号、同第６，８１７，９９０号、同第６，９３２，５８４号、及び同第７，６２１，８９３号に説明されているタイプであり、これらの各々が参照により本明細書組み込まれている。ヘルスケアデータベースは、遺伝子データベース、血液検査データベース、バイオームデータベース、又は電子医療記録（ＥＭＲ）を含み得る。

いくつかの実施形態では、複数の異なるソースからのデータは、少なくとも１日を通して不均一に分布される１０６のオーダの毎日のデータポイントを含み得る。データは、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、複数の異なるソースから収集されて集約され得る。いくつかの場合では、データの処理は、基盤となるＡＰＩへの変更又は更新の影響を受けないため、データは、基盤となるＡＰＩに変更又は更新が行われるときに、データを損失することなく処理され得るようになっている。

いくつかの実施形態では、データの収集及び集約は、データを複数のストリームに格納することを含み得る。データの処理は、様々な状態の発生時に、複数のストリームに格納されたデータに対してラムダ関数を実行することをさらに含み得る。ラムダ関数は、データが収集され、複数のストリームに格納されている場合にのみ実行され得る。格納されたデータに対するラムダ関数の実行は、データの各横列を複数のストリームから関連するストリームに流して送信するように構成されている。データは、複数のストリームのうち１つのストリームから別のストリームにカスケードすることにより、データパイプラインに沿って進めることができる。

いくつかの実施形態では、複数の異なるソースからデータを収集して集約することは、（１）データがプルされることを可能にするソースの第１のセットからデータをプルすること、及び（２）ソースの第２のセットからプッシュされるデータを受信することを含み得、複数のプルリクエスト及びプッシュリクエストからのデータが、一元化された場所にストリーミングされるようになっている。データは、タスクスケジューラを使用して、所定の時間間隔でソースの第１のセットからプルされ得る。データはまた、データがソースの第２のセットからプッシュされると、又はそのときに、ソースの第２のセットから受信され得る。場合によっては、ソースの第２のセットからのデータのプッシュは、データに関連付けられた１つ以上の通知によって進行され得る。他の場合、データが対応する通知とともに到着しない場合は、対応する通知に関連付けられているデータはプルされる。いくつかの事例では、ソースの第１のセット及びソースの第２のセットは、第１及び第２のセットの両方に共通の１つ以上のソースを含み得る。他の事例では、ソースの第１のセット及びソースの第２のセットは、互いに異なるソースを含み得る。

いくつかの実施形態では、複数のストリームの各々は、データが各ストリームに格納される時間枠を規定する保持ポリシーを有し得る。時間枠は、例えば、約２４時間～約１６８時間の範囲になり得る。データは、各データのソース（複数可）についての事前知識を必要とせずに、分離された様式で複数のストリームに格納することができる。複数のストリームは、複数のシャードを含み得る。各シャードは、（１）キューに入り、（２）保持ポリシーの満了時にキューから出る、データレコードの文字列を含み得る。データレコードの文字列は、複数の個別ユーザに固有である食品消費、健康、又は栄養の記録を含み得る。複数のストリーム内のいくつかのシャードを制御することにより、データが処理される速度を制御することができる。

いくつかの実施形態では、本方法は、１つ以上の異なるエンティティに関連付けられたトークンモジュールを介して複数のＡＰＩと通信することを含み得る。複数のＡＰＩからのデータは、取り出しモジュールを使用して収集して集約されることができ、それにより、取り出しモジュールは、トークンモジュールから分離され、それから独立することができる。トークンモジュールは、既存のトークンをリフレッシュし、トークン変更に関する通知更新情報を提供するように構成され得る。新しいトークンが生成される度に、新しいトークンは、トークンモジュールに格納されることに加えて、取り出しモジュールで個別に複製され得る。場合によっては、取り出しモジュールは、データを収集して集約するだけのために構成され得、データを保持し、格納し、又は処理するように構成され得ない。

いくつかの実施形態では、収集されたデータの一部又はすべてが、健康及び栄養プラットフォームに提供され、利用され得る。追加的に、又は任意選択的に、収集されたデータの一部は、１つ以上のサードパーティに送信され得る。データは、健康及び栄養プラットフォームに提供されて利用される前に、標準化された構造化形式に変換され得る。

いくつかの実施形態では、複数のデータソースからのデータが収集され、ストレージモジュールに集約されることができる。ストレージモジュールは、重複データを検証、チェック、及び削除するように構成され得る。ストレージモジュールは、データをバッチで保持するように構成され得る。ストレージモジュールは、選択したタイプのデータを統合することによってデータを減少するように構成され得る。

場合によっては、格納されたデータの一部は、１つ以上の撮像デバイスを使用してキャプチャされた複数の画像を含み得る。選択されたラムダ関数は、保存されたデータの一部に対して実行され、複数の画像のいずれかが、それらの栄養成分について分析される１つ以上の食品画像を含むかどうかを検出することができる。１つ以上の食品画像は、タイムスタンプ及び地理的位置に関連付けられることができ、それにより、ユーザの食物摂取の時間的追跡及び空間的追跡を可能にしている。ユーザの食物摂取の時間的追跡及び空間的追跡は、食事の消費時間又は食事内容を予測することを含み得る。

本開示の別の実施形態では、サーバレスデータ収集及び処理システムが提供される。本システムは、複数の異なるソースからデータを収集して集約するように構成された取り出しモジュールを含み得、データは、異なるタイプ又は形式のデータを含んでいる。本システムはまた、異なるタイプ又は形式のデータを健康及び栄養プラットフォームに互換性がある標準化された構造化形式に変換することによって、異なるタイプ又は形式のデータの各々をデータのソースにとらわれない様式で継続的に処理するように構成された標準化モジュールを含み得る。

この概要は、詳細な説明で以下にさらに説明される、選択された概念を簡略化した形式で紹介するために提供されている。この概要は、特許請求される主題の主要な特徴又は本質的な特徴を識別することを意図しておらず、特許請求される主題の範囲を判定する際の補助として使用されることも意図していない。本開示の異なる実施形態は、個別に、集合的に、又は互いに組み合わせて理解され得ることが理解されるであろう。本明細書に記載の本開示の様々な実施形態は、以下に記載される特定の用途のいずれかに、又は他のタイプの健康、栄養、又は食品関連の監視／追跡／提案システム及び方法に適用され得る。

主題のより完全な理解は、以下の図と併せて考慮した場合に詳細な説明及び請求項を参照することによって導き出すことができ、同様の参照番号は図全体を通して同様の要素を指す。

いくつかの実施形態によるエコシステムを示している。 いくつかの実施形態によるプラットフォームのブロック図を示している。 いくつかの実施形態によるトークンモジュールの構成要素を示している。 いくつかの実施形態による取り出しモジュールの構成要素を示している。 いくつかの実施形態によるパイプラインモジュールの構成要素を示している。 いくつかの実施形態による標準化モジュールの構成要素を示している。 いくつかの実施形態によるストレージモジュールの構成要素を示している。 いくつかの実施形態による、図３のトークンモジュールの一例を示している。 いくつかの実施形態による、図４の取り出しモジュールの一例を示している。 いくつかの実施形態による、図５のパイプラインモジュールの一例を示している。 いくつかの実施形態による、図６の標準化モジュールの一例を示している。 いくつかの実施形態による、図７のストレージモジュールの一例を示している。 コンピュータ実装データ収集及び処理方法を示すフローチャートであり、開示された実施形態に従って、ハードウェアベースの処理システムを介して個人化された食事及び健康のアドバイス又は提案を生成するための健康及び栄養プラットフォームを含むサーバレスアーキテクチャを使用して実装されている。 開示された実施形態による、複数の異なるソースからデータを収集して集約するための方法を示すフローチャートである。 開示された実施形態による、ストレージモジュール内の複数の異なるソースからデータを収集して集約するための方法を示すフローチャートである。 複数の異なるソースから収集されて集約されたデータを格納し、開示された実施形態によるストレージモジュールで収集されて集約されたデータを処理するための方法を示すフローチャートである。 開示された実施形態による、複数の異なるソースから収集されて集約されたデータを複数のストリームに格納するための方法を示すフローチャートである。 開示された実施形態に従って、画像を分析してそれらの栄養成分を判定するための方法を示すフローチャートである。

以下の詳細な説明は、本質的に単なる例示であり、主題の実施形態又はそのような実施形態の用途及び使用を限定することを意図するものではない。本明細書で使用される場合、「例示的（ｅｘｅｍｐｌａｒｙ）」という単語は、「例、事例、又は例証としての役割を果たす」ことを意味する。本明細書で例示として説明されている任意の実装は、必ずしも他の実装よりも好ましいか、又は有利であると解釈されるべきではない。さらに、前述の技術分野、背景、簡単な要約、又は以下の詳細な説明で提示されたいずれの明示的又は黙示的な理論に拘束される意図はない。加えて、本明細書に記載されているすべての刊行物、特許、及び特許出願は、個々の刊行物、特許、又は特許出願の各々が参照により組み込まれることが具体的かつ個別に示された場合と同程度に、参照により本明細書に組み込まれていることに留意すべきである。

ここで本開示の例示的な実施形態を詳細に参照すると、その例が添付の図面に示されている。可能な限り、同一の参照番号が、図面及び開示全体を通して同一又は類似の部品を参照するために使用されている。

今日、個人から健康、栄養、フィットネスのデータを収集する多くのアプリケーションが存在する。一部のアプリケーションは、携帯電話やウェアラブルデバイスに実装され、活動レベル、及び心拍数、血圧、並びにインスリンレベルなどの動態統計を受動的に追跡することができる。一部のアプリケーションは、ユーザが食事、運動ルーチン、及び睡眠習慣を記録することができるようにし、記録されたデータから健康指標を計算することができる。個人が複数のアプリケーションから取得した無数のデータを追跡し続けるのは困難になり得る。個別のデータセットは、特にユーザが異なるタイプ又はセットの健康及び栄養データ間の影響及び関係を完全に理解していない場合、ユーザに必要な見識を提供できないことが多い。その結果、ユーザは自身の健康や快適性を改善するための実行可能な措置を講じるために必要なツールを欠いていることがある。プラットフォーム（本明細書に開示）は、複数のアプリケーションから大量の健康、食品関連、及び栄養データを収集して統合して、より正確で有用な栄養及び／又は健康の情報をユーザに提供するためにデータを処理するように構成され得る。場合によっては、データを分析するために、ニューラルネットワークや他の機械学習アルゴリズムが使用されることができ、個別ユーザに個人化された健康に関する提案を提供することができる。

本明細書で開示されているプラットフォームは、（１）ユーザによって送信されたデータ、及び／又は様々なタイプのサードパーティアプリケーションから取り出されたデータを収集して集約し、（２）異なるタイプ又は形式のデータを健康と栄養のプラットフォームと互換性のある標準化された構造化形式に変換することにより、そのソースにとらわれない様式でデータを処理することができる。いくつかの実施形態では、本明細書に開示されるプラットフォームは、健康及び栄養プラットフォームと統合されるか、又はその一部として提供され得る。他の実施形態では、本明細書に開示されるプラットフォームは、健康及び栄養プラットフォームとは別に提供され得る。本明細書に開示されるプラットフォーム、又は本開示と整合性のある健康及び栄養プラットフォームへの任意の修正が企図され得る。健康及び栄養プラットフォームの例は、米国特許出願第１３／７８４，８４５号及び同第１５／９８１，８３２号に記載され、これらは両方とも、参照によりその全体が本明細書に組み込まれている。

本明細書に開示されるプラットフォームは、自律機能を備えたサーバレスアーキテクチャを使用して実装されることができ、データがプラットフォームを介してストリーミングされているときに大量の健康及び栄養データを処理する。サーバレスアーキテクチャを採用することで、プラットフォームが大量のデータを処理することを可能にし、例えば、１日あたり１０６データポイントのオーダで、１日を通して均等又は不均等に分散され得る。サーバレスアーキテクチャを使用することは、サーバリソースが、着信データフローに応じて必要に応じて利用されることから、データトラフィック中の大きな変動に関連する予測不可能性を軽減するのに有効である。自律機能は、データ項目が受信又は格納されたときなど、特定のイベントに応答してトリガーされ得る。サーバレスアーキテクチャを使用してプラットフォームを実装することで、特定の関数が呼び出された場合にのみ料金が発生する可能性があるため、コスト面での恩恵をもたらすこともできる。さらに、この機能は短期間で実行することができ、プロセッサの継続的な使用に関連するコストを削減している。データを受信していないときは、自律機能を起動する必要がないため、処理コストは発生しない。サーバレスアーキテクチャでプラットフォームを実装することの追加の利点は、そのようなアーキテクチャが、従来のサーバベースのシステムを使用することに関連するコスト負担をすることなく拡張性が可能になることである。サーバレスプラットフォームで処理されるデータが増えると、データを処理するための自律機能をトリガーする呼び出しの数が増加する。追加のコストは、関数呼び出しの数の増加に基づいている。サーバレスアーキテクチャを使用することで追加のサーバリソース、メンテナンス、又は人員への投資を回避できるため、開示されたプラットフォームを使用することで節約が実現され得る。

本明細書に記載のサーバレスアーキテクチャは、アプリケーションがサードパーティサービスによってホストされているソフトウェア設計開発であり得る。サードパーティサービスの例としては、ＡＭＡＺＯＮ（登録商標）Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｌａｍｂｄａ、ＴＷＩＬＩＯ（登録商標）Ｆｕｎｃｔｉｏｎｓ、ＭＩＣＲＯＳＯＦＴ（登録商標）Ａｚｕｒｅ Ｆｕｎｃｔｉｏｎｓが含まれ得る。典型的に、インターネット上でサーバアプリケーションをホストするには、仮想サーバ又は物理サーバ、並びにアプリケーションを実行するために必要なオペレーティングシステム及び他のウェブサーバホスティングプロセスを管理する必要がある。サーバレスアーキテクチャにおいてサードパーティサービス上にアプリケーションをホストすると、サーバソフトウェア及びハードウェア管理の負担はサードパーティサービスに移行する。

サーバレスアーキテクチャ内で動作するように開発されたアプリケーションは、個別の自律機能によって分割されることができ、これらは個別に呼び出されスケーリングされることができる。本明細書に記載のいくつかのサードパーティサービスの例では、関数は、例えばＬａｍｂｄａ関数、Ｔｗｉｌｉｏ関数、及びＡｚｕｒｅ関数として知られているものになり得る。これらの関数は、イベントに応答してトリガーされたときにコンピューティングオペレーションを実施するステートレスコンテナである。それらは一時的なものであり、これらが継続的に計算力を使用する代わりに、１回の呼び出し中に、又は限られた数の呼び出しを含む期間に計算力を使用することができるということを意味する。自律機能は、サードパーティサービスによって完全に管理されてもよい。自律機能を備えたサーバレスアーキテクチャは、「Ｆｕｎｃｔｉｏｎｓ ａｓ ａ Ｓｅｒｖｉｃｅ（ＦａａＳ）」と呼ばれることもあり、自律機能は、どの言語が基盤となるサーバレスアーキテクチャでサポートされているかに応じて、様々なプログラミング言語を使用して実装され得る。言語の例には、ＪａｖａＳｃｒｉｐｔ、Ｐｙｔｈｏｎ、Ｇｏ、Ｊａｖａ、Ｃ、及びＳｃａｌａが含まれる。

自律機能によって実施される計算タスクは、データの格納、通知のトリガー、ファイルの処理、タスクのスケジューリング、及びアプリケーションの拡張を含み得る。例えば、自律関数は、モバイルアプリケーションからのアプリケーションプログラミングインターフェース（ＡＰＩ）呼び出しとして要求を受信し、要求内のパラメータに属する値を検査し、検査された値に基づいて出力を生成するオペレーションを実施し、データベース内のテーブルエントリを変更することによって出力データをデータベース内に格納することができる。自律機能によって実施される処理オペレーションの一例は、ＰＤＦファイル又は画像ファイル上の光学式文字認識（ＯＣＲ）であり得、記号を編集可能なテキストに変換するものであり得る。スケジュールされたタスクの例は、データベースからの重複エントリの定期的な削除、接続されたアプリケーションからのデータ要求、アクセストークンの更新であり得る。自律機能は、アプリケーションの拡張機能として機能することができ、アプリケーションからデータを取り出し、処理のためにデータをサードパーティのサービスに送信する。例えば、サービスデスクチケットは、自律機能を使用して、スタッフに表示される別のヘルプデスクチャットプログラムに転送されることができる。

本明細書に記載されたようなサーバレスアーキテクチャを使用する利点は、それらが容易にスケーラブルになることである。水平スケーリング、又は追加のリソースの追加は、リソースが必要なときに実施することができる。例えば、処理されるリクエストの量が増えると、アーキテクチャは追加のコンピューティングリソースを自動的に調達することができる。一時的自律機能は、実行時のニーズに応じて作成及び破棄することができるため、スケーリングを容易にすることができる。サーバレスアーキテクチャは標準化されているため、問題が発生した場合の保守は、より容易になっている。

サーバレスアーキテクチャを使用する別の利点は、サーバレスアーキテクチャの費用効果が高いことである。自律機能は一時的なものであるため、計算能力は機能が呼び出されたときにのみ使用され得る。したがって、機能が呼び出されていないときは、計算能力に課金はされない。この支払い構造には、リクエストがたまにしか発生しない場合、又はトラフィックに一貫性がない場合に利点がある。サーバが継続的に稼働しているが、１分あたり１つの要求しか処理しない場合、サーバが稼働している時間と比較して要求を処理する時間が短いため、サーバは非効率的になり得る。対照的に、サーバレスアーキテクチャでは、一時的自律機能は計算能力を使用して要求を処理し、残りの時間は休止状態を維持する。トラフィックに一貫性がないとき、要求の頻度が低いと、計算能力はほとんど使用され得ない。トラフィックが急増すると、大量の計算能力が使用され得る。従来環境では、トラフィックの急増に対処するためにハードウェアの数を増やす必要があり得るが、トラフィックが停止するとハードウェアは無駄になることになる。しかしながら、サーバレス環境では、柔軟なスケーリングにより、トラフィックの急増時にのみ支払いを増やし、トラフィックの少ない期間にはコスト低減することが可能になっている。

本明細書に開示されるサーバレスアーキテクチャは、ストリーミングデータを統合及び処理することができる。ストリーミングデータは、複数のソースによって継続的に生成され、同時に処理されるデータである。サーバレスアーキテクチャは、データが生成されるときに、ストリーミングデータを迅速かつタイムリーに（例えば、実質的にリアルタイムで）収集して処理することができる。このことは、データを収集してデータベースに格納し、後で分析することとは対照的である。サーバレスアーキテクチャは、データをキャプチャして、変換して、分析するために特別に設計されたサービスを有し得る。これらのサービスは、ストリーミングデータを圧縮して、暗号化して、様々な種類のサードパーティアプリケーションと相互運用可能な形式に変換する自律機能を補完することができる。

自律機能は、プラットフォームが、例えば、認証、承認、データ統合、データ転送、データ処理、及び標準化などの多くのタスクを実施することができるようにすることが可能である。特定の自律機能は、外部アプリケーションプログラミングインターフェース（ＡＰＩ）と通信し、アクセストークンを交換、保存、更新、及び削除して、アプリケーションの権限を管理する。自律機能の一部は、データをプラットフォームにプッシュ及びプルする接続アプリケーションからデータを取り出し、収集したすべてのデータをストリームに統合することができる。他の自律機能は、ストリーミングされたデータをプラットフォームの他の構成要素に転送することができる。他の自律機能の一部は、データを分類して、データを異なるファイル形式に変換し、冗長データを削除し、及び／又はデータを標準化することによってデータ処理することができる。他の自律機能の一部は、格納と分析のためにデータを前処理することができる。

プラットフォーム内のモジュールは、メンテナンスや更新を容易にするために切り離すことができる。本明細書に記載のモジュールは、互換的に構成要素と称され得る。逆に、本明細書に記載のモジュールは、１つ以上の構成要素を含み得、モジュールは、構成要素の群を備えるようになっている。モジュールを切り離すことにより、データはプラットフォーム構成要素を通過し、データ損失なく処理されることができる。例えば、トークンは１つの構成要素から別の構成要素にコピーされることができ、２つの構成要素は互いに依存しないように切り離され得る。場合によっては、１つの構成要素がストリームをリダイレクトするように構成され得、一方で別の構成要素が処理用に構成され得る。第３の構成要素はストレージ用に構成され得る。本明細書で開示されるプラットフォームは、モジュール式に設計されることができ、各モジュールは、１つ以上の他のモジュールへの相互運用上の依存を必要とせずに固有の機能を実施するように構成されている。

サーバレスアーキテクチャを有する本開示のプラットフォームは、ビッグデータ処理に最適であり、多くの異なるタイプ又は形式のデータを、健康及び栄養プラットフォーム又は他のサードパーティアプリケーションと互換性のある標準化された構造化形式に集約する柔軟性をプラットフォームにもたらしている。このプラットフォームは、ユーザからデータを収集することができ、また、様々なサードパーティアプリケーションからの複数のＡＰＩと統合して、他のタイプのデータを収集することもできる。いくつかの実施形態では、プラットフォームは、食品オントロジーを作成することができ、これは様々なソース（例えば、インターネット、既存のデータベース、ユーザ入力など）から継続的に更新され、すべての食品タイプ（例えば、基本食品、パッケージ食品、レシピ、レストラン料理など）の情報のいずれかの取得可能情報を整理して分析する。いくつかの実施形態では、プラットフォームはまた、ユーザが、消費した食事、実施した運動又は活動、睡眠量、及び他の健康データに関する情報を手動で記録することを可能にすることができる。いくつかの実施形態では、プラットフォームのサードパーティアプリケーションとの統合は、プラットフォームが、多数のデータ収集デバイス及びサービス（例えば、モバイルデバイス、グルコースセンサ、ヘルスケアプロバイダデータベースなど）の間で個人化されたデータネットワークを生成することを可能にすることができ、代謝によって影響を受け得るか、又は代謝に影響を与え得る、あらゆるバイオマーカーの取得可能な情報（例えば、睡眠、運動、血液検査、ストレス、血糖値、ＤＮＡなど）を統合する。プラットフォームをＭｅｄｔｒｏｎｉｃ、Ａｂｂｏｔｔ、Ｄｅｘｃｏｍなどの企業によって製造された医療デバイスと統合することで、デバイスの使用状況データや健康関連データなどのデータをプラットフォームに提供することができる。プラットフォームは、様々な食品が各個人にどのように影響するかについての洞察を引き出すために様々な情報を接続又は相互に関連付けることによって、食品オントロジー、手動ログ、及び個人化されたデータネットワークを合成することができ、各個人のために個人化された食品、及びウェルネス提案をさらに生成する。

プラットフォームの実施形態は、例えば、ＡＭＡＺＯＮ（登録商標）Ｌａｍｂｄａ、ＡＭＡＺＯＮ（登録商標）Ｓ３、及びＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓを含むＡＭＡＺＯＮ（登録商標）Ｗｅｂ Ｓｅｒｖｉｃｅ ｓｏｌｕｔｉｏｎｓを利用することができる。他の実施形態は、ＧＯＯＧＬＥ（登録商標）Ｃｌｏｕｄ Ｓｅｒｖｉｃｅｓ又はＭＩＣＲＯＳＯＦＴ（登録商標）Ａｚｕｒｅなどのサービスからの類似のツールを利用することができる。

図面を参照した以下の説明は、プラットフォームが実装され得る環境の背景を提供し、プラットフォームの構造とともにプラットフォームを通るデータストリームについて詳しく説明する。図１は、いくつかの実施形態によるエコシステム１００を示している。一態様では、エコシステム１００は、システムアーキテクチャ又はプラットフォーム１５０を含むことができる。プラットフォームは、複数の異なるソース（例えば、デバイス１１０、インターネット１２０、及びデータベース（複数可）１３０）からデータを収集して集約することができる。図１に示されるように、エコシステム１００は、デバイス１１０を含むことができる。デバイス１１０は、ウェアラブルデバイス１１２（例えば、スマートウォッチ、アクティビティトラッカー、スマートグラス、スマートリング、スマートパッチ、スマートファブリックなど）、モバイルデバイス１１４（例えば、携帯電話、スマートフォン、音声レコーダなど）、及び／又は医療デバイス１１６（例えば、グルコースモニタ、インスリンポンプ、血圧モニタ、心拍数モニタ、汗センサ、ガルバニック皮膚反応（ＧＳＲ）モニタ、皮膚温度センサなど）を含むことができる。場合によっては、デバイス１１０は、家電製品（例えば、食物及び食習慣を追跡できるスマート冷蔵庫、消費されている食物の量及びタイプを追跡することができるスマート電子レンジなど）又はユーザの身体活動レベルを追跡できるゲーム機を含み得る。デバイス１１０は、互いに通信することができる。プラットフォーム１５０は、同時に、又は異なる時間インスタンスのいずれかで、１つ以上のデバイス１１０と通信することができる。

デバイス１１０は、１つ以上のセンサを備えることができる。センサは、信号を検出したり情報を取得したりするように構成されたデバイス、モジュール、ユニット、又はサブシステムのいずれかであり得る。センサの非限定的な例には、慣性センサ（例えば、加速度計、ジャイロスコープ、慣性測定ユニット（ＩＭＵ）を形成し得る重力検出センサ）、位置センサ（例えば、グローバルポジショニングシステム（ＧＰＳ）センサ、位置三角測量を可能にするモバイルデバイス送信機）、心拍数モニタ、温度センサ（例えば、外部温度センサ、皮膚温度センサ）、ユーザを取り巻く環境に関連するパラメータ（例えば、温度、湿度、輝度）を検出するように構成された環境センサ、容量性タッチセンサ、ＧＳＲセンサ、ビジョンセンサ（例えば、可視光、赤外線、又は紫外線を検出できるイメージングデバイス、カメラ）、熱イメージングセンサ、位置センサ、近接距離センサ（例えば、超音波センサ、光検出及び測距（ＬＩＤＡＲ）、時刻飛行又は深度カメラ）、高度センサ、姿勢センサ（例えば、コンパス）、圧力センサ（例えば、バロメーター）、湿度センサ、振動センサ、オーディオセンサ（例えば、マイク）、フィールドセンサ（例えば、磁力計、電磁センサ、無線センサ）、ＨＲＶモニタで使用されるセンサ（例えば、心電図（ＥＣＧ）センサ、心弾動図センサ、フォトプレチスモグラム（ＰＰＧ）センサ）、血圧センサ、液体検出器、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、セルラーネットワーク信号強度検出器、周囲光センサ、紫外線（ＵＶ）センサ、酸素飽和センサ、又はそれらの組み合わせ、又は本明細書の他の場所で説明されている他のセンサ又はセンシングデバイスが含まれ得る。センサは、ウェアラブルデバイス、モバイルデバイス、又は医療デバイスのうちの１つ以上に位置し得る。場合によっては、センサがユーザの体内に配置されることもある。

デバイス１１０はまた、プラットフォーム１５０と通信することができる任意のコンピューティングデバイスを含み得る。コンピューティングデバイスの非限定的な例は、モバイルデバイス、スマートフォン／携帯電話、タブレット、携帯情報端末（ＰＤＡ）、ラップトップ若しくはノートブックコンピュータ、デスクトップコンピュータ、メディアコンテンツプレーヤー、テレビ、ビデオゲームステーション／システム、仮想現実システム、拡張現実システム、マイク、又は様々なタイプの健康、栄養、若しくは食品データを分析、受信、提供、又は表示することが可能な任意の電子デバイスを含み得る。デバイスはハンドヘルドオブジェクトであり得る。デバイスはポータブルであり得る。デバイスは、人間のユーザにより携帯され得る。場合によっては、デバイスは人間のユーザから遠隔で位置し得、ユーザは無線及び／又は有線通信を使用してデバイスを制御することができる。

プラットフォーム１５０は、インターネット１２０及びデータベース（複数可）１３０（例えば、他の食品、栄養、又はヘルスケアプロバイダ）と通信することができる。例えば、プラットフォームは、電子医療記録（ＥＭＲ）を収容しているヘルスケアデータベースと通信し得る。いくつかの実施形態では、データベース（複数可）１３０は、Ｈａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）のような非構造化データベース又は非構造化形式で格納されたデータを含み得る。ＨＤＦＳデータストアは、非構造化データのストレージを提供することができる。ＨＤＦＳは、スケーラブルで信頼性の高いデータストレージを提供するＪａｖａベースのファイルシステムであり、コモディティサーバの大規模なクラスタにまたがるように設計されることができる。ＨＤＦＳデータストアは、ＭａｐＲｅｄｕｃｅなどの並列処理アルゴリズムに有用になり得る。

プラットフォーム１５０はまた、追加のデータベース（複数可）２４０と通信して、プラットフォーム１５０によって収集又は生成される任意のデータ又は情報を格納することができる。追加のデータベース（複数可）２４０は、安全なクラウドデータベースのコレクションであり得る。複数の異なるソースからのデータは、異なるタイプ又は形式のデータ（構造化データ及び／又は非構造化データ）を含み得る。場合によっては、データは、デバイス１１０、センサ、又は監視システムのうち１つ以上によって収集された時系列データを含み得る。時系列データは、定期的なセンサ読み取り値又は他のデータを含み得る。プラットフォームは、数十、数百、数千、数十万、又は数百万の範囲のデバイスに及ぶ、任意の数又はタイプのデバイスからデータを受信することができる。プラットフォーム１５０は、異なるタイプ又は形態のデータを標準化された構造化形式に変換することにより、データのソースにとらわれない様式で、異なるタイプ又は形態のデータの各々を継続的に処理することができる。標準化された構造化形式の変換されたデータは、健康及び栄養のプラットフォームと互換性があり得る。本明細書の他の場所で説明されるように、プラットフォーム１５０は、健康及び栄養プラットフォームの一部と統合されることができるか、又は健康及び栄養プラットフォームの一部として提供されることができる。いくつかの実施形態では、プラットフォーム１５０は、健康及び栄養プラットフォームとは別に提供され得る。

プラットフォーム１５０は、ストリーミングデータを相互に転送することができる一組の構成要素（又はモジュール）を含み得る。いくつかの実施形態では、データは、ＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓデータストリームを使用して保持キューに格納され得る。いくつかの実施形態では、データは、１人以上の個別ユーザに固有の食品、健康、又は栄養のデータを含み得る。プラットフォーム１５０は、健康及び栄養プラットフォームからの情報の一部を使用して、標準化された構造化形式に変換されたデータを分析することができる。いくつかの実施形態では、プラットフォーム１５０は、１つ以上の機械学習モデル又は自然言語処理（ＮＬＰ）技術を使用して、標準化された構造化データを分析することができる。本開示で使用され得る機械学習モデル又はアルゴリズムは、教師あり（又は予測）学習、半教師あり学習、能動学習、教師なし機械学習、又は強化学習を含み得る。

人工知能はコンピュータサイエンスの分野であり、人間のように機能して反応するインテリジェントマシンの形成を強調している。人工知能を備えたコンピュータが設計されている活動のいくつかには、学習が含まれる。人工知能アルゴリズムの例には、キーラーニング、アクター批評方法、深層強化決定論的方策勾配法（ＤＤＰＧ）、マルチエージェント深層強化決定論的方策勾配法（ＭＡＤＤＰＧ）などが含まれるが、これらに限定されない。機械学習とは、人間の知識の技術開発に向けた人工知能規律を指す。

機械学習は、新しいシナリオへの露出、テスト、適応を通じてコンピューティングの継続的な進歩を促進し、同時に、改善された意思決定とその後の同じではない状況のためのパターンと傾向の検出を採用している。機械学習（ＭＬ）アルゴリズム及び統計モデルは、明示的な指示を使用せずに、パターンと推論に依存して、特定のタスクを効果的に実施するためにコンピュータシステムによって使用されることができる。機械学習アルゴリズムは、タスクを実施するように明示的にプログラムされていなくても予測や決定を行うために、「トレーニングデータ」として知られるサンプルデータに基づいて数学モデルを構築する。機械学習アルゴリズムは、タスクを実施するための特定の命令のアルゴリズムを開発することが不可能なときに使用されることができる。

例えば、教師あり学習アルゴリズムは、入力と目的の出力の両方を含むデータセットの数学モデルを構築する。このデータはトレーニングデータとして知られ、一連のトレーニング例で構成されている。各トレーニング例は、１つ以上の入力、及び監視信号としても知られる所望の出力を有する。半教師あり学習アルゴリズムの場合、一部のトレーニング例は、所望の出力が欠如している。数学モデルでは、各トレーニング例は、配列又はベクトルで表され、トレーニングデータは行列で表されている。目的関数の反復最適化を通じて、教師あり学習アルゴリズムは、新しい入力に関連付けられた出力を予測するために使用できる関数を学習する。最適な関数は、アルゴリズムが、トレーニングデータの一部ではなかった入力の出力を正しく決定することを可能にする。経時的にその出力又は予測の精度を向上させるアルゴリズムは、そのタスクを実施することを学習したものである。教師あり学習アルゴリズムには、分類と回帰が含まれる。分類アルゴリズムは、出力が限られた値のセットに制限される場合に使用され、回帰アルゴリズムは、出力が範囲内の任意の数値を有し得る場合に使用される。類似性学習は、回帰及び分類に密接に関連する教師あり機械学習の領域であるが、目標は、２つのオブジェクトの類似性又は関連性を測定する類似性関数を使用して例から学習することである。

強化学習は、累積リワードの一部の概念を最大にするように、ソフトウェアエージェントが環境内でどのようにアクションを行うべきかに関する機械学習の分野である。その一般性により、本分野は、ゲーム理論、制御理論、オペレーションズリサーチ、情報理論、シミュレーションベースの最適化、マルチエージェントシステム、群知能、統計、及び遺伝的アルゴリズムなど、他の多くの分野で研究されている。機械学習では、環境は、典型的に、マルコフ決定過程（ＭＤＰ）として表される。多くの強化学習アルゴリズムは、動的計画法を使用している。強化学習アルゴリズムは、ＭＤＰの正確な数学的モデルの知識を前提とせず、正確なモデルが実現不可能な場合に使用される。

予測モデリング及び他のタイプのデータ分析では、１つのデータサンプルに基づく単一モデルには偏り、高い変動性、又は完全な不正確さがあることがあり、分析結果の信頼性に影響を与えることがある。異なるモデルを組み合わせるか、又は複数のサンプルを分析することで、これらの制限の影響は低減されることができ、より良い情報を提供する。したがって、アンサンブル手法が、複数の機械学習アルゴリズムを使用して、構成要素の学習アルゴリズムのいずれかから得られるよりも優れた予測パフォーマンスを得ることができる。

アンサンブルは、トレーニングして予測に使用できることから、教師あり学習アルゴリズムである。したがって、トレーニングされたアンサンブルは、それが構築されたモデルの仮説空間内に必ずしも含まれているとは限らない単一の仮説を表す。したがって、アンサンブルは、それらが表すことができる関数においてより柔軟性を有するとして示され得る。アンサンブルモデルは、予測が組み合わされた、個別にトレーニングされた分類器（ニューラルネットワークや決定木など）のセットを含むことができる。

例えば、アンサンブルモデリングの一般的な例の１つは、ランダムフォレストモデルであり、これは複数の決定木を活用し、様々な変数とルールに基づいて結果を予測するように設計された分析モデルのタイプである。ランダムフォレストモデルは、異なるサンプルデータを分析するか、異なる要因を評価するか、又は共通変数に異なる重みを付け得る決定木をブレンドする。次に、様々な決定木の結果が単純な平均に変換されるか、又はさらに重み付けされて集計される。Ｈａｄｏｏｐ及び他のビッグデータテクノロジーの出現により、より大容量データが保存及び分析されるようになり、このことが分析モデルが異なるデータサンプルで実行されることを可能にした。

実装に応じて、任意の数の機械学習モデルが、アンサンブルモデルを最適化するために組み合わせられることができる。機械学習モデルで実装できる機械学習アルゴリズム又はモデルの例は、限定されるものでないが、以下のものが含まれ、それらは、線形回帰、ロジスティック回帰、Ｋ－ｍｅａｎｓクラスタリングなどの回帰モデル、１つ以上の決定木モデル（例えば、ランダムフォレストモデル）、１つ以上のサポートベクターマシン、１つ以上の人工ニューラルネットワーク、１つ以上の深層学習ネットワーク（例えば、少なくとも１つのリカレントニューラルネットワーク、深層学習を使用したシーケンスからシーケンスへのマッピング、深層学習を使用したシーケンスエンコーディングなど）ファジー論理ベースのモデル、遺伝的プログラミングモデル、ベイジアンネットワーク又は他のベイジアン手法、確率的機械学習モデル、ガウス処理モデル、隠れマルコフモデル、自己回帰移動平均（ＡＲＭＡ）モデル、自己回帰和分移動平均（ＡＲＩＭＡ）モデル、自己回帰条件付きヘテロスケダスティシティ（ＡＲＣＨ）モデルなどの時系列手法、一般化された自己回帰条件付き不均一分散（ＧＡＲＣＨ）モデル、移動平均（ＭＡ）モデル又は他のモデル、及び上記のいずれかからヒューリスティックに導出された組み合わせなどである。機械学習アルゴリズムのタイプは、それらの手法、入出力するデータのタイプ、及び解決しようとしているタスク又は問題のタイプが異なっている。

隠れマルコフモデル（ＨＭＭ）は、統計的マルコフモデルであり、ここではモデル化されているシステムが観測されていない（隠れ）状態のマルコフ過程であると想定されている。ＨＭＭは、最も単純な動的ベイジアンネットワークと見なされることができる。ベイジアンネットワーク、信念ネットワーク、又は有向非巡回グラフィカルモデルは、確率的グラフィカルモデルであり、これは確率変数のセットと条件付き独立性を有向非巡回グラフ（ＤＡＧ）とともに表す。変数のシーケンスをモデル化するベイジアンネットワークは、動的ベイジアンネットワークと称される。不確実性の下での決定問題を表現及び解決することができるベイジアンネットワークの一般化は、影響図と称される。

サポートベクターネットワークとしても知られているサポートベクターマシン（ＳＶＭ）は、分類及び回帰に使用される関連する教師あり学習方法のセットである。各々が２つのカテゴリのうちの１つに属するとマークされた一連のトレーニング例が与えられると、ＳＶＭトレーニングアルゴリズムは、新しい例が一方のカテゴリに分類されるか、又は他方のカテゴリに分類されるかを予測するモデルを構築する。ＳＶＭトレーニングアルゴリズムは、非確率的、バイナリ、線形分類器である。線形分類の実施に加えて、ＳＶＭは、カーネルトリックと呼ばれるものを使用して非線形分類を効率的に実施し、入力を高次元の特徴空間に暗黙的にマッピングすることができる。

決定木学習は、決定木を予測モデルとして使用して、アイテムに関する観察（ブランチで表される）からアイテムのターゲット値に関する結論（リーフで表される）に移行する。ターゲット変数が離散的な値のセットを取ることができるツリーモデルは、分類ツリーと称され、これらのツリー構造では、リーフはクラスラベルを表し、ブランチはそれらのクラスラベルにつながる特徴の連結を表す。ターゲット変数が連続値（典型的には実数）を取ることができる決定木は、回帰木と称される。意思決定分析では、決定木が意思決定と意思決定プロセスを視覚的かつ明示的に表すために使用されることができる。

深層学習アルゴリズムは、機械学習で使用されるアルゴリズムのコレクションを参照することができ、これらのアルゴリズムは、複数の非線形変換で構成されるモデルアーキテクチャを使用して、高レベルの抽象化とデータをモデル化するために使用される。深層学習は、ニューラルネットワークの構築及びトレーニングに使用される特有のアプローチである。深層学習は、人工ニューラルネットワーク内の複数の隠れ層で構成されている。深層学習アルゴリズムの例には、例えば、シャムネットワーク、転移学習、リカレントニューラルネットワーク（ＲＮＮ）、長短期記憶（ＬＳＴＭ）ネットワーク、畳み込みニューラルネットワーク（ＣＮＮ）、トランスフォーマなどが含まれる。例えば、深層学習アプローチは、長短期記憶（ＬＳＴＭ）や￥及びゲート付き回帰ユニット（ＧＲＵ）などの自動回帰リカレントニューラルネットワーク（ＲＮＮ）を利用することができる。ＲＮＮ（及びバリアント）を使用した時系列予測のためのニューラルネットワークアーキテクチャの１つは、自動エンコーダとして機能する自己回帰ｓｅｑ２ｓｅｑニューラルネットワークアーキテクチャである。

いくつかの実施形態では、アンサンブルモデルは、１つ以上の深層学習アルゴリズムを含むことができる。任意の数の異なる機械学習技術も利用できることに留意されたい。実装に応じて、アンサンブルモデルは、ブートストラップ集約アンサンブルアルゴリズム（バギング分類器メソッドとも称される）として、ブースティングアンサンブルアルゴリズム又は分類器アルゴリズムとして、スタッキングアンサンブルアルゴリズム又は分類器アルゴリズムとして、モデルのバケットアンサンブルアルゴリズムとして、ベイズ最適分類アルゴリズムとして、ベイジアンパラメータ平均化アルゴリズムとして、ベイジアンモデル組み合わせアルゴリズムとしてなどで実装されることができる。

バギングと略されることが多いブートストラップ集約は、アンサンブル内の各モデルに同じ重みで投票させる必要がある。モデル分散を促進するために、バギングは、トレーニングセットのランダムに描かれたサブセットを使用して、アンサンブル内の各モデルをトレーニングする。一例として、ランダムフォレストアルゴリズムは、ランダム決定木とバギングとを組み合わせて、非常に高い分類精度を実現している。バギング分類器又はアンサンブル法は、トレーニングセットのランダムな再配布で各分類器をトレーニングすることにより、そのアンサンブルの個体を作成する。各分類器のトレーニングセットは、Ｎ個の例を置き換えてランダムに描画することで生成することができ、ここで、Ｎは元のトレーニングセットのサイズであり、元の例の多くは、結果のトレーニングセットで繰り返されることができ、一方で他の例は残され得る。アンサンブル内の各個別の分類器は、トレーニングセットの異なるランダムサンプリングで生成されている。バギングは、トレーニングセットの小さな変化が予測に大きな変化をもたらす「不安定な」学習アルゴリズム（例えば、ニューラルネットワークや決定木）において効果的である。

対照的に、ブーストでは、各新規モデルインスタンスをトレーニングして、以前のモデルが誤って分類したトレーニングインスタンスを強調することにより、アンサンブルを段階的に構築する。場合によっては、ブーストはバギングよりも精度が高いことが示されているが、トレーニングデータに適合しすぎる傾向もある。ブースティング分類器は、シリーズの分類器を生成するために使用することができる一連の方法を参照できる。シリーズの各メンバーに使用されるトレーニングセットは、シリーズの以前の分類器（複数可）のパフォーマンスに基づいて選択されている。ブースティングでは、シリーズ内の前の分類器によって誤って予測された例が、正しく予測された例よりも頻繁に選択されている。したがって、ブーストは、現在のアンサンブルのパフォーマンスが低い例を、より良好に予測することができる新しい分類器を生成する試みを後押しする。ブースティングの一般的な実装は、Ａｄａｂｏｏｓｔであるが、より良好な結果を達成するために、いくつかのより新しいアルゴリズムが報告されている。

スタッキング（スタック一般化と呼ばれることもある）は、他のいくつかの学習アルゴリズムの予測を組み合わせるための学習アルゴリズムのトレーニングを伴う。スタッキングは２つのフェーズで機能し、複数の基本分類器が、クラスを予測するために使用され、次に、新規学習者が汎化誤差を低減する目的で、予測を組み合わせるために使用されている。最初に、他のアルゴリズムのすべてが、利用可能なデータを使用してトレーニングされ、次に、組み合わせアルゴリズムがトレーニングされて、他のアルゴリズムのすべての予測を追加の入力として使用して最終的な予測を行う。任意の組み合わせアルゴリズムが使用される場合、次にスタッキングは、理論的には本書に記載のアンサンブル手法のいずれかを表すことができるが、実際には、ロジスティック回帰モデルが多くの場合コンバイナーとして使用される。

「モデルのバケット」は、モデル選択アルゴリズムを使用して各問題に最良のモデルを選択するアンサンブル手法である。１つの問題のみでテストした場合、モデルのバケットはセット内の最良のモデルよりも優れた結果を生成することができないが、多くの問題にわたって評価した場合、典型的に、セット内のどのモデルよりも平均してはるかに良好な結果を生成する。モデル選択に使用される一般的なアプローチの１つは、相互検証選択（「ベイクオフコンテスト」と呼ばれることもある）である。相互検証の選択は、トレーニングセットですべてを試し、最も効果的な１つを選択することで要約することができる。ゲーティングは、相互検証選択の一般化である。これには、別の学習モデルをトレーニングして、バケット内のどのモデルが問題解決に最適かを判断することが含まれる。多くの場合、パーセプトロンはゲーティングモデルに使用される。「最良の」モデルを選択するために使用することもでき、バケット内の各モデルからの予測に線形の重みを与えるために使用することもできる。モデルのバケットが多数の問題で使用される場合、トレーニングに時間がかかる一部のモデルのトレーニングを回避することが望ましくなり得る。ランドマーク学習は、この問題を解決しようとするメタ学習アプローチである。これには、バケット内の高速（ただし不正確）アルゴリズムのみをトレーニングし、次いで、これらのアルゴリズムのパフォーマンスを使用して、どの低速（ただし正確）アルゴリズムが最も効果的であるかを判断することを補助することが含まれる。

ベイズの最適分類器は分類手法である。これは仮説空間内のすべての仮説のアンサンブルである。平均して、他のアンサンブルがそれを上回ることはできない。単純ベイズ最適分類器は、データが条件付きでクラスに依存しないことを前提とし、計算をより実現可能にするバージョンである。各仮説には、その仮説が真である場合にトレーニングデータセットがシステムからサンプリングされる可能性に比例した投票が与えられている。有限サイズのデータのトレーニングを容易にするために、各仮説の投票はまた、その仮説の事前確率が掛けられている。しかしながら、ベイズの最適分類器によって表される仮説は、アンサンブル空間（すべての可能なアンサンブルの空間）における最適な仮説である。

ベイズパラメータ平均化（ＢＰＡ）は、仮説空間から仮説をサンプリングし、ベイズの法則を使用してそれらを組み合わせることにより、ベイズの最適分類器を近似させようとするアンサンブル手法である。ベイズの最適分類器とは異なり、ベイズモデル平均化（ＢＭＡ）は実際的に実装することができる。仮説は、典型的に、ＭＣＭＣなどのモンテカルロサンプリング手法を使用してサンプリングされる。例えば、分布を表す仮説を立てるためにはギブスサンプリングが使用され得る。特定の状況下では、仮説がこのように立てられベイズの法則に従って平均化されると、この手法には、ベイズ最適分類器の予想誤差の最大２倍に制限される予想誤差があることが示されている。

ベイジアンモデルの組み合わせ（ＢＭＣ）は、ベイジアンモデルの平均化（ＢＭＡ）に対するアルゴリズム修正である。アンサンブル内の各モデルを個別にサンプリングする代わりに、可能なアンサンブルの空間から（均一なパラメータを有するディリクレ分布からランダムに抽出されたモデルの重みを使用して）サンプリングする。この変更は、ＢＭＡが単一のモデルにすべての重みを与える方向に収束する傾向を克服する。ＢＭＣは、ＢＭＡよりも計算コストがいくらか高くなるが、はるかに優れた結果が得られる傾向がある。ＢＭＣの結果は、ＢＭＡやバギングよりも平均して（統計的に有意に）優れていることが示されている。モデルの重みを計算するためにベイズの法則を使用するには、各モデルに与えられたデータの確率を計算する必要がある。典型的に、アンサンブル内のどのモデルも、トレーニングデータが生成された正確な分布ではなく、そのため、すべてのモデルは、この項のゼロに近い値を正しく受け取ることになる。アンサンブルがモデル空間全体をサンプリングするのに十分な大きさである場合、これはうまく機能するが、そのようなことはまれである。その結果、トレーニングデータの各パターンにより、アンサンブルの重みが、トレーニングデータの分布に最も近いアンサンブルのモデルに向かってシフトするようになる。それは本質的に、モデル選択を行うための不必要に複雑な方法に減少する。アンサンブルのための可能な重み付けは、シンプレックス上にあるものとして視覚化され得る。シンプレックスの各頂点では、すべての重みがアンサンブル内の単一モデルに与えられている。ＢＭＡは、トレーニングデータの分布に最も近い頂点に向かって収束する。対照的に、ＢＭＣは、この分布がシンプレックスに投影されるポイントに向かって収束する。換言すると、生成分布に最も近いモデルを１つ選択する代わりに、生成分布に最も近いモデルの組み合わせを探す。ＢＭＡの結果は、多くの場合、相互検証を使用してモデルのバケットから最良のモデルを選択することで概算できる。同様に、ＢＭＣからの結果は、相互検証を使用して、可能な重み付けのランダムサンプリングから最適なアンサンブルの組み合わせを選択することで概算され得る。

再び図１を参照すると、標準化された構造化データの分析に基づいて、プラットフォーム１５０は、複数の個別ユーザの各々について、個人化された食事及び健康のアドバイス又は提案をさらに生成することができる。

ＡＰＩゲートウェイを使用してプラットフォームに接続することにより、データをプラットフォーム１５０に入力することができる。したがって、データは、ＡＰＩゲートウェイを介してプラットフォームに接続する複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、複数の異なるソースから収集されて集約されることができる。データは、自律機能を使用してプラットフォームに集約、処理、及び格納され得、自律機能は、受信データがプラットフォーム内の様々なモジュール又は構成要素を介してストリーミングされるときにトリガーされている。プラットフォーム内の構成要素／モジュールは互いに切り離されることができ、それによりメンテナンス、更新、及び再利用が容易になることを確実にしている。プラットフォームによるデータの処理は、基盤となるＡＰＩへの変更や更新の影響を受けない。プラットフォームでサーバレスアーキテクチャを使用すると、基盤となるＡＰＩに変更や更新が行われたときに、データを失うことなくデータを処理することができるようにする。

プラットフォーム１５０は、リアルタイム又はニアリアルタイムで大量のストリーミングデータを処理するように構成されることができる。いくつかの実施形態では、プラットフォームは、複数の異なるソースからデータを収集、集約、及び処理することができる。データは、１日を通して均等又は不均等に分布する少なくとも１０６のオーダの毎日のデータポイントを含み得る。データの一部は、ミリ秒のオーダでＡＰＩゲートウェイから取り出されることができる。場合によっては、プラットフォーム１５０は、リアルタイムで処理できないバルクデータを受信することができる。プラットフォームは、大量のデータの分析を可能にするように構成されたＰａｒｑｕｅｔのようなファイル形式でデータを出力することができる。

図２は、いくつかの実施形態によるプラットフォーム１５０のブロック図を示している。プラットフォームは、トークンモジュール２１０、取り出しモジュール２３０、パイプラインモジュール２５０、標準化モジュール２７０、及びストレージモジュール２９０を含み得る。モジュールは、機能、ストレージユニット、又はデータを認証し、向け、格納し、又は処理することができるアプリケーションのグループを表し得る。データは、モジュールを直列に流れることができるが、各構成要素内に設けられた自律機能は、直列又は並列様式で配置することができる。プラットフォームに接続されたＡＰＩは、トークンモジュール２１０を使用して認証され、かつ承認されることができる。取り出しモジュール２３０は、接続されたアプリケーションからデータを取り出するように構成されることができる。パイプラインモジュール２５０は、さらなる処理又は格納のために、データをホストされたサードパーティアプリケーションに向けるように構成されることができる。標準化モジュール２７０は、データを処理してデータを標準化された構造化形式に変換することができる。標準化された構造化データは、例えば、本明細書に記載の１つ以上の機械学習モデルを使用して、プラットフォーム内でさらに分析されることができる。代替的に、標準化された構造化データは、分析のために１つ以上のサードパーティアプリケーションにエクスポートされることもできる。最後に、ストレージモジュール２９０は、処理されたデータを格納し、受動的データ収集を監視し、そして異なるタイプの分析に使用されるデータを準備することができる。

トークンモジュール２１０は、外部ＡＰＩ及びデータサービスを統合することができ、これらの外部ＡＰＩを承認及び認証する役割を担っている。トークンモジュール２１０は、サードパーティアプリケーションを認証するときに、それ自体をトークンモジュールとして表すか、又は表さない可能性がある。例えば、トークンモジュール２１０は、外部ＡＰＩ及びデータサービスと通信するとき、それ自体をプラットフォーム１５０として、又はサードパーティアプリケーションからデータを収集する他のサービスとして表すことができる。このことは、トークンモジュール２１０が、それらのアイデンティティを変化させずにサードパーティアプリケーションによってサービスを匿名化することを可能にすることができる。したがって、異なるエンティティ（例えば、企業）によって提供される１つ以上のサードパーティアプリケーションへのアクセスを管理するためにトークンモジュールが使用され得る。

トークンモジュール２１０は、トークンを作成、更新、及び削除することができる。トークンモジュールは、既存のトークンをリフレッシュし、トークン変更に関する通知の更新情報を提供することができる。トークンモジュール２１０によって作成されたトークンは、複製され、トークンモジュールから切り離され、独立している取り出しモジュールに転送され得る。新しいトークンが生成される度に、新しいトークンは、トークンモジュールに格納されることに加えて、取り出しモジュールで個別に複製され得る。作成されたトークンには有効期限があることがある。許可を維持するために、トークンモジュール２１０は、スケジュールに基づいて取り出しモジュール２３０にトークンを発行することができる。いくつかの実施形態では、取り出しモジュール２３０は、必要なトークンを持たないとき、又はトークンが適切に機能していないとき、単純な通知サービスを使用して、トークンモジュール２１０にメッセージを送信することができる。

トークンモジュール２１０は、ＯＡｕｔｈを使用して外部ＡＰＩを統合することができる。ユーザは、プラットフォーム１５０を使用してアプリケーションにログインすることができる。プラットフォームのＡＰＩを使用して、アプリケーションは、ユーザと１つ以上の追加のサードパーティアプリケーションとの間の認証プロセスの開始を要求することができる。ユーザが１つ以上のサードパーティアプリケーションによって認証されると、プラットフォームを使用するアプリケーションは、プラットフォーム１５０に格納されているアクセストークンを受信する。認証プロセスでは、ＯＡｕｔｈ１．０又はＯＡｕｔｈ２．０を使用することができる。

取り出しモジュール２３０は、プラットフォーム１５０に接続されたＡＰＩからデータを取り出すことができる。取り出しモジュール２３０は、とりわけ、多くのタイプのアプリケーション、ウェアラブルデバイス、モバイルデバイス、医療デバイス、データセット、データソースと統合するためのプラットフォームのハブとして機能することができる。取り出しモジュールは、様々なデバイスとインターフェースしてデータを受信することができる。データは、対応するアプリケーションによって通常エクスポートされる形式で受信されることができる。取り出しモジュール２３０は、多くの異なるアプリケーションからのデータをストリームに統合することができる一連の処理機能を備えることができる。データは非同期的に統合されることができ、所定の期間ストリームに保持される。データが受信されストリームに統合された後、データは、データパッケージとして処理のために他のモジュールに向けられることができる。取り出しモジュールは、他のモジュールから切り離され、独立していることができる。例えば、取り出しモジュールは、データを収集して集約するだけのために構成され得、データを保持するか、格納するか、又は処理するように構成され得ない。

取り出しモジュール２３０は、データをプルし、プッシュされたデータを受信するように構成されることができる。データは、接続されたＡＰＩから直接収集され得るか、又はモバイルデバイスから受信され得る。これらの実施形態では、モバイルデバイスアプリケーションからのデータは、ＡＭＡＺＯＮ（登録商標）Ｓ３バケットなどのバケットオブジェクトに格納され得る。プッシュ及びプルされたデータは、同時に、又は異なる時間に受信され得る。受信したプッシュ及びプルされたデータは、データストリームに移動され得る。データは、様々な段階で処理機能を使用して、プラットフォーム内の様々なモジュールに送信され得る。データストリームは、データレコードのキューであるデータシャードを含み得る。シャードの数を変更すると、データが処理される速度を変更することができる。したがって、プラットフォームは、ストリーム内のシャードの数を制御することによってデータが処理される速度を制御することができる。各データストリームは、データをストリームで保持する期間を指定する保持ポリシーを有し得る。いくつかの実施形態では、データは、２４時間～１６８時間の範囲の期間で保持され得る。各シャードは、（１）キューに入り、（２）保持ポリシーの満了時にキューから出るデータレコードの文字列を備え得る。保持期間内の任意の時点で、キュー内の以前のデータレコードが見られることができ、ストリームは、以前の履歴状態へと繰り返されることができる。この期間が満了すると、データレコードがキューから出ることができる。個々のサービスは、１つのタイプからデータをプッシュすることができ、取り出しモジュール２３０によってプルされた別のタイプのデータを有することができる。いくつかの実施形態では、データレコードの文字列は、複数の個別ユーザに固有の食品消費、健康、又は栄養の記録を含み得る。アプリケーションからのデータのプルは、時間ベースのタスクスケジューラによって定期的に実施され得る。データがプラットフォーム１５０にプルされ得るアプリケーションの例は、Ｗｉｔｈｉｎｇｓなどのサードパーティアプリケーションを含み得る。

取り出しモジュール２３０はまた、データをプラットフォームにプッシュするアプリケーションからデータを取り出すことができる。データをプラットフォームにプッシュすることができるサービス及びデバイスの例は、Ａｂｂｏｔｔ ＦｒｅｅＳｔｙｌｅ Ｌｉｂｒｅ、Ｇａｒｍｉｎ、ＦｉｔＢｉｔなどを含み得る。これらのデバイスは、プラットフォーム１５０に通知を送信することができ、この通知は、取り出しモジュール２３０によって受信されることができる。それに応答して、取り出しモジュール２３０は、これらのアプリケーションからデータをプルすることができ、データを１つのストリーム又は複数のストリームに統合／格納することができる。場合によっては、データは通知と同時にプラットフォームに送信されることができ、したがって、取り出しモジュール２３０がそれに応答してデータをプルする必要がなくなる。いくつかの実施形態では、取り出しモジュール２３０は、トークンモジュール２１０によって作成されたトークンを格納することもできる。トークンは、取り出しモジュールに設けられたサーバレスデータベースに格納され得る。

パイプラインモジュール２５０は、プラットフォーム１５０を通るデータの流れを制御することができる。パイプラインモジュール２５０は、サードパーティアプリケーションへのデータ転送を容易にすることができ、その例には、Ｗｅｌｌｔｏｋ、Ｍｅｄｔｒｏｎｉｃなどが含まれ得る。パイプラインモジュール２５０はまた、プラットフォーム内のストリーミングアプリケーションにデータを転送することもできる。データは、イベントに応答してトリガーされる自律機能を使用して転送されることができる。イベントには、オブジェクトの作成、及びＳＮＳメッセージなどの通知メッセージの受信が含まれ得る。いくつかの実施形態では、パイプラインモジュール２５０は、ＡＭＡＺＯＮ（登録商標）ラムダ関数及びＡＭＡＺＯＮ（登録商標）Ｓ３バケットを使用するＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓストリームによって実装されることができる。Ｋｉｎｅｓｉｓは、イベントに応答して、プラットフォーム内の様々なリソースにデータを向けるラムダ関数をトリガーすることができる。イベントは、ストリーム内のデータシャードの受信であり得る。

標準化モジュール２７０は、サードパーティアプリケーションによって読み取られるか、又は標準化されたデータファイルに対して実施された分析を有することができる、標準化されて、統合された構造化データファイルを作成することによって、プラットフォーム１５０を介したデータストリーミングを管理及び処理することができる。標準化モジュール２７０は、データストリーム上で異なる処理機能を実装することができる要素のセットを含み得る。処理機能は、データの分類、異なる形式への変換、及び冗長データの削除を含み得る。処理されたデータストリームは、保存されるか、キャッシュされるか、又は追加のデータストリームに向けられ得る。

ストレージモジュール２９０は、プラットフォームの受動的データ収集アクティビティを管理することができる。データ収集アクティビティの管理は、受動的データ収集ＳＤＫによってプルされたストリーミングデータのログを保持すること、及びストリーミングデータを分析し、分類し、格納することを含み得る。ストレージモジュール２９０は、モバイルデバイス上の接続されたアプリケーション又はネイティブアプリケーションからプルされたデータに対して自動的に分析を実施することができる。モバイルデバイスカメラは、画像データを受動的に収集することができ、画像データは、受動的データ収集ソフトウェア開発キット（ＳＤＫ）によってストレージモジュール２９０にプッシュされ得る。ストレージモジュール２９０は、ニューラルネットワークで構築された二項分類器を使用して、画像が食品を含むものか、又は含まないものかのいずれかに分類することができる。このデータは、分析前に前処理又は暗号化されることがある。

以下の図の説明では、プラットフォーム１５０内の各モジュールは、１つ以上の構成要素を含むものとして説明することができる。これらの構成要素は各々、１つ以上の自律機能、データストリーム、ストリーミングアプリケーション、ストレージバケット、又は他の構成要素のグループを含み得、論理的に接続され、タスクを実施するためのグループとして構成されている。プラットフォーム１５０を介してストリーミングされたデータは、これらのグループ内の１つ以上の自律機能をトリガーすることができる。例えば、ＡＭＡＺＯＮ（登録商標）Ｌａｍｂｄａ関数は、ＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓデータストリーム又はＡＭＡＺＯＮ（登録商標）Ａ３イベントを使用してトリガーすることができる。例えば、Ｋｉｎｅｓｉｓは、ストリームに新規レコードを検出したときにＬａｍｂｄａ関数をトリガーすることができる。ＤｙｎａｍｏＤＢテーブルに書き込まれたレコードに応答して、関数がトリガーされることもできる。ＡＭＡＺＯＮ（登録商標）Ｌａｍｂｄａは、新しい記録がいつ利用可能になるかを判断するために、これらのソースをポーリングすることができる。

図３は、いくつかの実施形態によるトークンモジュール２１０の構成要素を示している。トークンモジュール２１０は、認証並びにトークン作成構成要素３３０、トークンリフレッシュ構成要素３６０、及びトークンストレージ構成要素３９０を含み得る。

認証及びトークン作成構成要素３３０は、外部ＡＰＩと通信することができる。認証及びトークン作成構成要素は、ＵＲＬで接続要求を受信し、要求を保存することができる。トークンは、ユーザアクセストークンであり得る。トークンは、有効期限、権限、及び識別子を含むことができる。いくつかの実施形態では、要求はテーブル内に格納され得る。認証及びトークン作成構成要素はまた、認証ＵＲＬを維持することができる。ユーザが認証された後、コールバック関数はユーザを認証ＵＲＬに戻ることができる。外部ＡＰＩが認証及び承認されると、承認及びトークン作成構成要素は、トークンモジュール２１０に格納されているトークンを発行することができる。トークンはまた、テーブルに保存されることもできる。認証及びトークン作成構成要素はまた、トークンを複製し、複製されたトークンを取り出しモジュール２３０に転送することができる。トークンの有効期限などのトークン情報は、トークンとともに取り出しモジュール２３０にコピーすることができる。トークンはまた、有効期限が切れたときに構成要素３３０を使用して削除されることもできる。

トークンリフレッシュ構成要素３６０は、スケジューリング構成要素であり得、これは、定期的に実行し、既存のトークンの有効期限をチェックし、まもなく有効期限が切れるトークンをリフレッシュする。トークンリフレッシュ構成要素３６０は、トークンの加入者を更新することができる。通知は、トークンステータスの変更に関する更新情報を提供できる。トークンリフレッシュ構成要素は、例えば、単純な通知サービスを使用して構成要素を更新し得る。トークンストレージ構成要素３９０は、プラットフォーム内のトークンの記録を保持することができる。トークンが作成又はリフレッシュされると、これらはトークンストレージ構成要素３９０に格納されることができる。

図４は、いくつかの実施形態による、取り出しモジュール２３０の構成要素を示している。取り出しモジュール２３０は、トークンストレージ構成要素４２０、データプッシュ構成要素４５０、データプル構成要素４８０、及びデータ統合構成要素４９０を含み得る。

トークンストレージ構成要素４２０は、トークンモジュール２１０によって作成されたトークンを格納することができる。トークンストレージ構成要素はまた、トークンモジュール２１０からリフレッシュされたトークンを取り出すこともできる。トークンモジュール２１０がＡＰＩを認証するとき、トークンモジュール２１０は、新しいトークンを作成するために取り出しモジュールにメッセージを送信することができる。メッセージはトークン情報を含み得る。作成されたトークンはテーブルに格納され得る。再発行されたトークンはまた、テーブルに格納され得る。トークンストレージ構成要素４２０は、トークンモジュール２１０からの通知を受信して、すでに格納されているトークンを更新することができる。例えば、トークンストレージ構成要素４２０は、トークンモジュール４２０からのトークンのタイムゾーンフィールドを更新するためのコマンドを受信することができる。トークンストレージ構成要素４２０は、既存のまもなく期限切れになるトークンを新しいトークンと交換するための通知を受信することができる。

データプッシュ構成要素４５０は、外部ＡＰＩが取り出しモジュール２３０にデータをプッシュすることを可能にし得る。外部ＡＰＩは、ＡＰＩゲートウェイを用いて取り出しモジュール２３０と通信することができる。データプッシュ構成要素４５０は、外部ＡＰＩからの通知をサブスクライブすることができる。データが利用可能である場合、データプッシュ構成要素４５０は、外部ＡＰＩによってプッシュされているデータを取り出すように促され得る。このデータはローカルに格納され得る。取り出しモジュール２３０は、１つ以上のストレージバケットなどの１つ以上のオブジェクトに生の応答データを格納することができる。

データプル構成要素４８０は、外部ＡＰＩからデータをプルすることができる。データは、取り出しモジュール４８０に格納された有効なトークンを有するＡＰＩから、スケジュールに基づいてプルされ得る。データプル構成要素４８０は、ストリーミングに利用可能なすべてのデータを提供することができない。代わりに、データプル構成要素４８０は、このデータの部分サブセットをデータ統合構成要素４９０に提出することができる。

データ統合構成要素４９０は、（ａ）データプッシュ構成要素４５０からプッシュされたデータ、及び（ｂ）データプル構成要素４８０からプルされたデータを、データストリームに配置することができる。本明細書で使用される「統合」という用語は、サードパーティアプリケーションから受信したデータを１つ以上のデータストリームに移動することを含み得る。データ統合構成要素は、データプッシュ構成要素４５０かデータプル構成要素４８０のいずれか、又はその両方からのプッシュ通知を介してデータをストリームに移動するように促され得る。データ統合構成要素４９０は、ＡＰＩから履歴データ（例えば、前月から収集されたデータ）を取り出すための自律機能を含み得る。履歴データ関数は、例えば、新規ユーザがプラットフォームに登録されたときに１回だけ呼び出すことができる。１つ以上のデータストリームからのデータの一部は、ローカルに保存され得る。データ統合構成要素４９０は、１つ以上のデータストリームを、プラットフォーム内の他の接続されたモジュールに提供することができる。

図５は、いくつかの実施形態によるパイプラインモジュール２５０の構成要素を示している。パイプラインモジュール２５０は、データストリームからアプリケーションにデータを送信するための構成要素５４０、及びプラットフォーム内でデータを送信するための構成要素５７０を含み得る。パイプラインは、パイプライン設計パターンを活用することができ、直列に接続された要素のグループを含み得る。例示的な要素には、ストリーミングされたデータを転送するために使用されるラムダ関数が含まれ得る。ストリーミングされたデータで作動するラムダ関数は、どの外部ＡＰＩ（複数可）がデータを提供しているか、その処理速度、及び／又はプラットフォーム内の他の条件によって異なり得る。プラットフォームの２つ以上の構成要素が同じデータを処理する必要がある場合、ストリームから転送されるデータは、複製され得る。

図６は、いくつかの実施形態による標準化モジュール２７０の構成要素を示している。標準化モジュール２７０は、生データストレージモジュール６２０、データ分類モジュール６４０、ダイアリー６５０、データ減少モジュール６６０、監視モジュール６８０、及び変換モジュール６９０を含み得る。他の実施形態では、標準化モジュール２７０は、異なる又は追加のデータ処理構成要素を含み得る。構成要素は、直列に配置され得、ストレージモジュール２９０によるデータ分析又は格納の準備中に、ストリームが複数の構成要素によって連続して段階的に処理され得るようになっている。データが更新され、受信モジュール２１０に提示されると、その更新が、標準化モジュール２７０のストリームに反映され得る。

生データストレージモジュール６２０は、サードパーティアプリケーションから収集されたデータを格納することができる。格納されているデータは、プラットフォーム構成要素による処理がまだ行われていない「生」データであり得る。このようなデータは、Ａｐｐｌｅ Ｈｅａｌｔｈ Ｋｉｔなどのモバイルデバイス上のアプリケーションから受動的に収集され得る。生データは、生ストレージモジュール６２０に直接格納されることができ、トークンモジュール２１０及び取り出しモジュール２３０をバイパスすることができる。

データ分類モジュール６４０は、パイプラインモジュール２５０から受信したデータを分類することができる。データは、ユーザＩＤ、データタイプ、又はアクティビティタイムスタンプで分類され得る。この分類は、関数によって呼び出され、プラットフォーム上でストリーミングするアプリケーションを使用して実施され得る。分類されたデータは、クイックアクセスのためにキャッシュされ得る。分類されたデータは、分析ツールへの容易なストレージ又はローディングのためにＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓ Ｆｉｒｅｈｏｓｅストリームなどのストリームに配置されることができる。分類されたデータは、標準化モジュール２７０の他のツールを使用して処理され得る。データ分類モジュール６４０はまた、キャッシュをチェックすることによって、受信するデータが重複データではないことを検証することもできる。

ダイアリー６５０は、サードパーティアプリケーション又はエンドユーザによる消費のための標準化され、処理されたデータを格納することができる。ダイアリーは、手動で記録されたデータ、及び派生データを格納することができる。手動で記録されたデータには、食事、トレーニング、自己申告の感情、睡眠時間、自己申告の品質、身長、体重、投薬、及びインスリンレベルが含まれ得る。派生データは、記録されたデータから計算されることができ、体脂肪率や基礎代謝率（ＢＭＲ）などの指標を含み得る。接続されたアプリケーションから受動的に収集されたデータは、このデータと統合されることができ、アプリケーション、及びＦｉｔｂｉｔ、Ａｐｐｌｅ Ｗａｔｃｈ、Ｏｕｒａ ｒｉｎｇ、及びＲｕｎｋｅｅｐｅｒのようなウェアラブルデバイスからの同期化された健康情報を含み得る。個別のダイアリーエントリは、標準化された構造化形式に変換された、この統合され、処理されたデータを含み得る。エントリは、一度に１つずつ、又は一括で追加され得る。ダイアリーエントリは、クイックアクセスのためにキャッシュされ得る。ダイアリーエントリは、要約情報と提案をユーザに提供するレポートを作成するためにプラットフォームによって使用されることができる。例えば、ダイアリーエントリは、要約的なグルコース情報、食事統計、及び食習慣を改善するためのヒント、及び血糖と身体活動との相関性、睡眠と気分との相関性を含むレポートを生成することができる。

データ減少モジュール６６０は、データストリームから冗長又は無関係なエントリを削除することができる。データ減少モジュール６６０は、冗長又は無関係なエントリを削除するために、Ｍａｐ－Ｒｅｄｕｅアルゴリズムを使用することができる。例えば、サードパーティアプリケーションＭｙＦｉｔｎｅｓｓＰａｌは、栄養素と食品を組み合わせることができる。ＭｙＦｉｔｎｅｓｓＰａｌは、栄養素ごとに食品内の各栄養素を一覧表示することができる。しかしながら、同じ食品に多くの栄養素が含まれ得ることから、このことは多くの重複エントリにつながることがある。データ減少モジュール６６０は、「食品」キーを作成し、食品の各栄養素を値として一覧表示することによってこれらのエントリを統合することができ、それにより、各食品がその栄養情報とともに一回で一覧表示される。

監視モジュール６８０は、標準化モジュール２７０の処理段階が正しく機能していることを確実にすることができる。これを行うために、監視モジュール６８０はダミーデータを生成することができる。ダミーデータは、ストリームに配置され得、データ標準化モジュール内の１つ以上の処理モジュールに向けられ得る。監視モジュール６８０によって生成されたダミーデータは、処理で使用される１つ以上のデータタイプからのものであり得る。監視モジュールは、ダミーデータのテストからレポートを作成することができ、そのレポートを外部分析サービス（ＤＡＴＡＤＯＧ（登録商標）など）に提供することができる。

変換モジュール６９０は、ストリーミングデータを他のデータ形式に変換することができる。データが変換されるファイル形式は、標準化モジュール２７０内の後続の処理段階に依存し得る。例えば、変換モジュール６９０は、データをＦｏｏｄＰｒｉｎｔＴＭデータ形式に変換することができる。変換されたストリーミングデータは、クイックアクセスのためにキャッシュに格納され得るか、又は標準化モジュール２７０内の他の処理段階に送信され得る。

図７は、いくつかの実施形態によるストレージモジュール２９０の構成要素を示している。ストレージモジュール２９０は、データ監視モジュール７２０、データ分類モジュール７５０、及びデータストレージモジュール７８０を含み得る。ストレージモジュールの構成要素は、受動的に収集されたデータを操作することができる。受動的データは、ユーザモバイルデバイス上のアプリケーションから収集され得る。

データ監視モジュール７２０は、構成要素を監視するために、プラットフォーム内の異なる構成要素から報告されたデータを受信する１つ以上のラムダ関数を含み得る。データは、外部デバイスの構成要素によって収集され得る。ラムダ関数の１つは、収集されているデータに関する情報を出力できるアプリケーションを呼び出すことができる。監視プロセスは、データの取得、データの保存、データのパッケージ化、データの暗号化、データのアップロード、１つ以上のサーバへのデータの保存など、受動的に収集されたデータに対して実行される様々なアクションを分析できる。追加のラムダ関数は、監視プロセスを通じて収集された情報をログファイルに保存することができ、ログファイルはＵＲＬに保存され得る。

データ分類モジュール７５０は、受動的に収集されたデータを含む暗号化されたファイルを受信することができる。データ分類モジュール７５０は、収集されたデータが分類される前に、これらのファイルに対して前処理を実施する１つ以上のラムダ関数を含み得る。前処理アクティビティには、ファイルの解凍と復号化が含まれ得る。データ分類モジュールは、収集されたデータを分類するためにラムダ関数を使用することができる。分類は、機械学習、又は畳み込みニューラルネットワークやリカレントニューラルネットワークなどの深層学習手法の使用を含み得る。例えば、携帯電話のカメラで撮影された画像に対して画像認識分析が実施されることができ、それらの画像のどこかに食物が存在するかどうかを判断することができる。食物を含む画像はダイアリー６５０に保存され得、そこで栄養情報がこれらの画像から抽出され得る。分類が完了した後、分類器のトラブルシューティングを行うために、分類されたデータはデバッグバケットに保存され得る。データ分類モジュール７５０は、１つ以上のセキュリティポリシーを実装することができ、データが危険にさらされたり盗まれたりした場合にデータが匿名化されることを確実にする。例えば、画像内の人物の顔をぼやけさせることができる。データはまた、クラウドにアップロードする場合、暗号化されることもできる。

データストレージモジュール７８０は、分類された受動データを格納することができる。格納されたデータは、サードパーティアプリケーションによって分析されることができ、データ分析モデルを改善するために、分析（ジオロケーション、ファイル解像度、カメラモジュールデータなど）をユーザに提供することができる。格納される受動データは、ログ情報だけでなく画像データも含み得る。ログ情報は、手動入力されたか、又は自動で記録されたサードパーティアプリケーションからの睡眠及び活動情報を含み得る。分類されたデータは、データストレージモジュール２９０に一時的に格納され得、一定期間後に削除され得る。

図８～図１２は、プラットフォーム１５０内のモジュールの例示的な実施形態を示す。例示的な実施形態は、ＡＭＡＺＯＮ（登録商標）Ｗｅｂ ｓｅｒｖｉｃｅｓ及びＡＭＡＺＯＮ（登録商標）Ｌａｍｂｄａ ｓｅｒｖｅｒｌｅｓｓ ｃｏｍｐｕｔｉｎｇを採用することができる。ＧＯＯＧＬＥ（登録商標）Ｃｌｏｕｄ Ｆｕｎｃｔｉｏｎｓ及びＭＩＣＲＯＳＯＦＴ（登録商標）Ａｚｕｒｅなどの他のサーバレスアーキテクチャも、本明細書に開示されているインフラストラクチャを作成するために使用され得る。プラットフォームが同様のタイプのサーバレスアーキテクチャを使用して開発されている場合、プラットフォームの構成要素は、本明細書で説明されている実施形態に類似し得る。これらの図の要素は、Ｌａｍｂｄａ関数、ＡＰＩゲートウェイ、ウェブサーバ、Ｓｉｍｐｌｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ（ＳＮＳ）メッセージ、ストレージバケット、Ｋｉｎｅｓｉｓ Ｆｉｒｅｈｏｓｅストリーム、及びストリーミングアプリケーションを含み得る。

ラムダ関数は、ＡＭＡＺＯＮ（登録商標）Ｌａｍｂｄａを使用して実装されているような自律機能であり得る。これらは、イベントに応答してトリガーされ、呼び出されたときにのみアクティブになる機能である。これらの機能は、サーバリソースをアクティブにする必要がある時間を短縮することができる。Ｌａｍｂｄａ関数は、認証、承認、データ転送、処理、及びストレージ機能を実装するために使用され得る。前述の機能の１つ以上は、１つ以上のＬａｍｂｄａ関数を使用して実装され得る。例えば、Ｌａｍｂｄａ関数は、ＡＰＩゲートウェイを認証し、認証サーバからのトークンを要求するために使用され得る。認証されたＡＰＩをＵＲＬにリダイレクトするためには、別のＬａｍｂｄａ関数が使用され得る。追加のＬａｍｂｄａ関数が、トークンを発行し、リフレッシュし、及び削除することができる。同様に、データをプル又はプッシュし、プル及びプッシュされたデータを統合し、様々なデータ項目をストリームから異なる場所に向けるために、様々なＬａｍｂｄａ関数が使用され得る。Ｌａｍｂｄａ関数は、データストリーム、データストレージ、ストリーミングアプリケーションを含む、多くのタイプのＡＭＡＺＯＮ（登録商標）オブジェクトと統合できる。

ＡＰＩゲートウェイは、外部アプリケーションからプラットフォームにデータを転送するために、プラットフォームを外部ＡＰＩに接続できる。ＡＰＩゲートウェイはまた、外部ＡＰＩとデータサービスを統合するためのＯＡｕｔｈプロセス全体の外部エントリポイントとなり得る。プラットフォームはまた、ＡＰＩゲートウェイを介してデータをプッシュするＡＰＩにサブスクライブすることもできるため、データをプッシュする準備ができたときにゲートウェイを介して通知を受信する。ＡＰＩゲートウェイはまた、外部ＡＰＩがプラットフォーム自体からデータを受信することを可能にすることができる。

アプリケーションＡＰＩは、ＨＴＴＰコールを使用して、データの転送とデータとの対話を可能にすることができる。ＡＰＩは、これらのＡＰＩと対話するための一連のルールを定義するＲＥＳＴに従うことができる。ＡＰＩは、要求メッセージを送信することによって、リソースへのデータのＰＯＳＴ、リソースからのデータのＧＥＴ、リソース内のデータの更新、又はリソースからのデータの削除を行うことができる。これらのメッセージは、メッセージ、ユーザ、資格情報、タイムスタンプ、及び他のメッセージ情報を有するテキストフィールドを含み得る。ＡＰＩゲートウェイは、ＨＴＴＰリクエストを使用してアプリケーションと通信することができる。

ウェブサーバは、ＨＴＴＰリソースなどのリソースを格納することができ、ネットワークを介してプラットフォームに接続することができる。ウェブサーバは認証情報を格納することができ、プラットフォームが外部ＡＰＩからユーザデータにアクセス可能にするためにプラットフォームにトークンを発行することができる。ウェブサーバは、処理された情報を格納することもできる。プラットフォーム１５０上で実行されるアプリケーションは、ウェブサーバに格納されたデータにアクセスすることができる。ストリーミングアプリケーションは、ウェブサーバでホストされ得る。

ＡＭＡＺＯＮ（登録商標）Ｓ３バケットは、ユーザとアプリケーションとがデータを格納することを可能にすることができる。データオブジェクトは、バケットからアップロード及びダウンロードされることができる。バケットはまた、メタデータを含むことができ、これが格納されているフィールドに関する情報を提供する。バケットは、権限を変更することにより、ユーザ又はアプリケーションへのアクセスを制限又は許可することができる。プラットフォーム１５０は、取り出しモジュール２３０からのストリームとの処理及び統合のためにバケットからデータを取り出すことができる。

ＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓストリームは、ストリーミングデータを他のツールにロードすることができる。これらはまた、データを暗号化して変換することもできる。Ｆｉｒｅｈｏｓｅストリームは、Ｌａｍｂｄａ関数と組み合わせて使用されることができ、処理するためにデータをストレージ又はアプリケーションに送信する。Ｋｉｎｅｓｉｓは、格納されるデータをバッチ処理して圧縮することができ、使用されるストレージの量を最小限に抑える。ストリーミングデータを暗号化することでセキュリティを強化することができる。

ストリーミングアプリケーションは、ＡＭＡＺＯＮ（登録商標）Ｗｅｂ Ｓｅｒｖｉｃｅでホストされることができ、安全かつ高性能で実行することができる。アプリケーションは、データが転送されるときに、必要に応じてオンデマンドで使用することができる。ストリーミングアプリケーションは、データが処理された後にデータを向けるＬａｍｂｄａ関数と組み合わせることができる。

図８は、いくつかの実施形態によるトークンモジュール２１０の実施形態８００を示す。トークンモジュールは、プラットフォーム１５０を外部ＡＰＩに接続するＡＰＩゲートウェイ８１０を含み得る。ラムダ関数接続８２２は、外部ＡＰＩからの接続要求をテーブルに保存できる。外部ＡＰＩは、ラムダ関数によって確認及び認証され得る。認証に続いて、ラムダ関数はトークンを作成するために呼び出され得る。図示した実施形態では、リフレッシュ８２４と呼ばれるラムダは、トークンをリフレッシュするためにメッセージを送信することができる。別のラムダ８２６は、データベースで既存のトークンを検索することができる。トークンは、取り出しモジュール２３０に対して発行されることができる。取り出しモジュールに格納されている１つ以上のトークンを無効化するために、ラムダディスエーブル８２８も呼び出されることができる。別のラムダは、生成、読み取り、更新、及び削除（ＣＲＵＤ）操作のために使用され得る。

図９は、取り出しモジュール２３０の一実施形態９００を示す。図９の例では、取り出しモジュールは、トークンモジュールの実施形態８００からのメッセージを受信して、トークンを更新、生成、及び無効化することができる。メッセージは、シンプル通知サービス（ＳＮＳ）メッセージ９１０であり得る。トークンは、トークンデータテーブル９３０で更新され得る。図９のデータプッシュ構成要素４５０を参照すると、取り出しモジュールは、接続された外部ＡＰＩからプッシュされたデータを受信するために、ＡＰＩゲートウェイに接続することができる。サブスクライブ９２２ラムダは、ＳＮＳメッセージを通知９２４関数に送信することができ、これは、取り出しモジュールの実施形態９００にプッシュされるデータを示す。図９のデータプル構成要素４８０を参照すると、関数ｓｃｈｅｄｕｌｅｄ＿ｐｏｌｌ９２６は、トークンデータテーブル９３０にリストされているように、接続された外部ＡＰＩをポーリングすることができる。ＳＮＳメッセージｇｅｔｄａｔａ９２８は、新しいデータが利用可能であることをアナウンスすることができ、プッシュ及びプルされたデータは、ラムダ関数ｇｅｔ＿ｄａｔａ＿ｓｎｓ９２９を使用して取り出されることができる。関数ｇｅｔ＿ｈｉｓｔｏｒｉｃ＿ｄａｔａ＿ｓｎｓ９２７は、保持期間のより早い時点からデータを受信し、データストリームに追加することができる。バケット取り出しデータ９４０は、デバッグ又はバックアップのために、取り出しモジュールに送信されたデータを格納することができる。

図１０は、パイプラインモジュール２５０の一実施形態１０００を示している。この実施形態では、２つのストリーミングアプリケーション及び２つのラムダ関数が直列に接続され得る。取り出しモジュールの実施形態９００からのデータは、データ分散１０５２と呼ばれるストリーミングアプリケーションに送信され得る。ラムダ関数ｄａｔａ＿ｄｉｓｔｒｉｂｕｔｉｏｎ １０２２は、このデータを標準化モジュールの実施形態１１００に向けることができる。別のストリーミングアプリケーションｔｈｉｒｄ＿ｐａｒｔｙ＿ｄａｔａ１０５４及び対応するラムダ関数１０２４は、ストリームをサードパーティアプリケーションバケット１０４２に送信することができる。

図１１は、標準化モジュール２７０の一実施形態１１００を示す。この実施形態は、直列処理チェーン、並びに直列処理チェーンの様々な段階での複数のキャッシュ及びＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓストリームを含み得る。データは、例えば、ＡＭＡＺＯＮ（登録商標）Ｋｉｎｅｓｉｓ Ｆｉｒｅｈｏｓｅを使用してＡＭＡＺＯＮ（登録商標）Ｓ３バケット内に格納され得る。ストリーミングデータは、ドロップオフ１１４２と呼ばれるストレージ領域から、及びパイプラインの実施形態９００から受信することができる。データは、分類器ｌａｍｂｄａ１１５２によって分類され得、対応するラムダ１１２２によって、ｓｏｒｔｅｒ＿ｃａｃｈｅ１１６２と分類器未処理ストリーム１１７２との両方に保存されるように向けられ得る。データは、次いでコンバータ関数１１５４を使用して変換され得、コンバータラムダ関数１１２４を使用してダイアリーリソースに向けられ得る。変換されたデータは、ｄｉａｒｙ＿ｂｕｌｋ１１２６関数によってダイアリーに保存され、キャッシュされ得る。単一のダイアリーエントリは、ｄｉａｒｙ＿ｓｉｎｇｌｅ１１２８関数によって抽出され、ダイアリーに格納され得る。変換されたデータはまた、２つのｆｏｏｄ＿ｐｒｏｃｅｓｓｏｒ＿ｃａｃｈｅｓ１１６４に格納され得る。データは、ｌａｍｂｄａ＿ｆｕｎｃｔｉｏｎ ｆｏｏｄ＿ｐｒｏｃｅｓｓｏｒ１１５６によって低減され、関数ｆｏｏｄ＿ｐｒｏｃｅｓｓｏｒ＿ｄｉａｒｙ１１２７によってダイアリーに向けられ得る。Ｃｏｏｒｄｉｎａｔｉｏｎ＿ｃａｃｈｅ関数は、関数が並行して実行されないようにするミューテックスとして機能する。

図１２は、ストレージモジュール２９０の一実施形態１２００を示している。データ監視モジュールは、関数ｄａｔａ＿ｃｏｌｌｅｃｔｉｏｎ１２２２を使用してシステム構成要素からのデータを監視することができる。ストリームは、アプリケーションｍｏｎｉｔｏｒ＿ｓｔｒｅａｍ１２２４によって監視されることができる。追加のラムダ関数１２２６は、監視プロセスからｅｓドメインにログを保存することができる。データ分類モジュールは、「ドロップオフ」１２４２からデータを収集し、ラムダ関数ｆｉｒｅｓｔｏｒｍ１２２８を使用してデータを前処理し、食品画像を分類することができる。ラムダ関数ｓａｖｅ＿ｉｍａｇｅ１２２１は、食品として分類されていない項目をデバッグバケットとイメージデバッグバケットに配置することができる。食品として分類される画像は、ストレージモジュールによってｆｏｏｄ＿ｉｍａｇｅｓ１２４４、ダイアリー１２８２、及び分析バケット１２４６に保存されることができる。

図１３～図１８は、開示された実施形態による方法の実施例を示すフローチャートである。図１３～図１８に関して、示される各方法のステップは必ずしも限定的ではない。添付の特許請求の範囲から逸脱することなく、ステップは追加され、省略され、及び／又は同時に実施されることができる。各方法は、任意の数の追加的又は代替的タスクを含むことができ、示されているタスクは、示されている順序で実施される必要はない。各方法は、本明細書に詳細に記載されていない追加機能を有するより包括的な手順又はプロセスに組み込むことができる。さらに、意図した全体的な機能性がそのまま維持される限り、示した１つ以上のタスクは、各方法の一実施形態から省略されることができる。さらに、各方法に関連して実施される様々なタスク又はステップが、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせによって実施され得るという点において、各方法はコンピュータで実装される方法である。例示の目的で、各方法の以下の説明は、図１に関連して上述した要素を指し得る。特定の実施形態では、このプロセスのいくつか又はすべてのステップ、及び／又は実質的に同じステップは、非一時的であるか、又は非一時的になり得るプロセッサ可読メディアに格納又は含まれたプロセッサ可読命令の実行によって実施されている。例えば、以下の図１３～図１８の説明では、プラットフォーム１５０の様々な構成要素（例えば、トークンモジュール２１０、取り出しモジュール２３０、パイプラインモジュール２５０、標準化モジュール２７０、ストレージモジュール２９０、及びそれらの構成要素のいずれか）は、様々な行為、タスク又はステップを実施するものとして説明され得るが、これは、これらの様々な行為、タスク又はステップを実施するための命令を実行するこれらのエンティティの処理システム（複数可）を指すことを理解されたい。実装に応じて、一部の処理システム（複数可）が中央に配置するか、又は連携して動作するいくつかのサーバシステムに分散させるができる。

図１３は、コンピュータ実装データ収集及び処理方法１３００を示すフローチャートであり、これは、開示された実施形態によるハードウェアベースの処理システムを介して、個人化された食事及び健康のアドバイス又は提案を生成するための健康及び栄養プラットフォーム１５０を含むサーバレスアーキテクチャを使用して実装されている。方法１３００は、１３１０において開始し、そこでは取り出しモジュール２３０が、データストレージモジュール２９０内の複数の異なるソースからのデータを収集して集約している。データは異なるタイプ又は形式のデータ（例えば、複数の個別ユーザに固有の食品、健康、又は栄養データを含む構造化データ及び非構造化データ）を含むことができる。

１３２０において、標準化モジュール２７０は、例えば、異なるタイプ又は形式のデータを健康及び栄養プラットフォーム１５０と互換性のある標準化された構造化形式に変換することによって、異なるタイプ又は形式のデータのソースにとらわれない様式で、異なるタイプ又は形式のデータの各々を継続的に処理することができる。

１３３０において、標準化された構造化形式に変換されたデータは、健康及び栄養プラットフォーム１５０からの情報（の少なくとも一部）を使用して分析することができる。例えば、標準化された構造化データは、１つ以上の人工ニューラルネットワーク、１つ以上の回帰モデル、１つ以上の決定木モデル、１つ以上のサポートベクターマシン、１つ以上のベイジアンネットワーク、１つ以上の確率的機械学習モデル、１つ以上のガウス処理モデル、１つ以上の隠れマルコフモデル、及び１つ以上の深層学習ネットワークを含むが、これらに限定されない１つ以上の機械学習モデルを使用して分析することができる。１３４０において、複数の個別ユーザの各々のために個人化された食事及び健康のアドバイス又は提案が生成され得る。

図１４は、開示された実施形態による、複数の異なるソースからデータを収集して集約するための方法１３１０を示すフローチャートである。方法１３００は、１４１０で開始し、ここではタスクスケジューラを使用して所定の時間間隔でデータがプルされることを可能にするソースの第１のセットからデータがプルされる。１４２０において、ソースの第２のセットからプッシュされているデータに関連する１つ以上の通知を受信することができる。１４３０において、各対応する通知のデータが、対応する通知とともに到着したかどうかが判断され得る。各対応する通知のデータが対応する通知とともに到着していないと（１４３０で）判断されると、方法１３１０は、次に１４１０に進み、そこでデータが対応する通知とともに到着しない場合、対応する通知に関連するデータがプルされる。（１４３０において）各対応する通知のデータが対応する通知とともに到着していないと判断されると、方法１３１０は１４４０に進み、そこでソースの第２のセットからプッシュされたデータが受信され得る。複数のプッシュ要求からのデータは、一元化された場所にストリーミングされることができる。

図１５は、開示された実施形態による、ストレージモジュール２９０内の複数の異なるソースからデータを収集して集約するための方法１３１０を示すフローチャートである。方法１３１０は、１５０５において開始し、そこでは、１つ以上の異なるエンティティに関連付けられたトークンモジュール２１０が、１つ以上の異なるエンティティに関連付けられた複数のアプリケーションプログラミングインターフェース（ＡＰＩ）と通信することができる。トークンモジュール２１０は、既存のトークンをリフレッシュし、トークン変更に関する通知の更新情報を提供することができる。新規トークンが生成される度に、新規のトークンは、トークンモジュール２１０に格納されることに加えて、取り出しモジュール２３０で別個に複製される。取り出しモジュール２３０は、トークンモジュール２１０から分離され、トークンモジュール２１０から独立している。

１５１０において、取り出しモジュール２３０は、複数の異なるソースからの複数の個別ユーザに固有の異なるタイプ又は形式のデータ（例えば、食品、健康、又は栄養データを含む構造化データ及び非構造化データ）を１つ以上の異なるエンティティに関連付けられた複数のＡＰＩを介して収集して集約することができる。

１５１５において、ストレージモジュール２９０は、収集されて集約されたデータを検証してチェックし、収集されて集約されたデータから重複データを削除し、収集されて集約されたデータの選択されたタイプを統合し、収集されて集約されたデータを減少させ、統合されたデータをバッチで保持することができる。

図１６は、開示された実施形態による、複数の異なるソースから収集されて集約されたデータを格納し、収集されて集約されたデータを処理するための方法１６００を示すフローチャートである。方法１６００は、１６１０において開始し、そこでは、取り出しモジュール２３０が、複数の異なるソースから収集されて集約されたデータをストレージモジュール２９０で複数のストリームに格納する。一実施形態では、複数のストリームは各々、データが各ストリームに格納される時間枠を規定する保持ポリシーを有する。１６２０において、異なる状況が発生すると、収集されて集約されたデータは、複数のストリームに格納されている収集されて集約されたデータに対してラムダ関数を実行することによって処理され得る。１６２０の一実施形態では、ラムダ関数は、データが収集されて複数のストリームに格納されたときにのみ実行される。例えば、１６３０において、ラムダ関数が１６３０で格納されたデータに対して実行され、データの各行を複数のストリームから関連するストリームに流して転送し、１６４０において、収集されて集約されたデータが、複数のストリームのうち１つのストリームから別のストリームにカスケードすることにより、データパイプラインに沿って進められる。

図１７は、開示された実施形態による、複数の異なるソースから収集されて集約されたデータを複数のストリームに格納するための方法１６１０を示すフローチャートである。方法１６１０は、１７１０において開始し、取り出しモジュール２３０は、複数の異なるソースから収集されて集約されたデータをストレージモジュール２９０の複数のストリームに格納し、複数のストリームは、複数のシャードを含み得、各シャードは、（１）キューに入り、（２）保持ポリシーの満了時にキューから出るデータレコードの文字列を備えている。データレコードの文字列は、複数の個別ユーザに固有である食品消費、健康、又は栄養の記録を含み得る。１７２０において、データが処理される速度を制御するために複数のストリーム内のシャードの数が制御され得る。

図１８は、開示された実施形態による、画像を分析してそれらの栄養成分を判断するための方法１８００を示すフローチャートである。格納された収集されて集約されたデータの一部は、１つ以上のイメージングデバイスを使用してキャプチャされた画像を含むことができる。１８１０において、１つ以上の選択されたラムダ関数（複数可）が、格納されたデータのその部分に対して実行され、複数の画像のいずれかが、それらの栄養成分について分析される１つ以上の食品画像を含むかどうかを検出することができる。食品画像はタイムスタンプと地理的位置に関連付けられており、それによって、１８２０において、例えば食事の消費時間や食事の内容を予測することにより、ユーザの食品摂取を時間的及び空間的に追跡することができる。

コンピュータ可読格納メディアは、単一メディアであり得るが、「コンピュータ可読格納メディア」などの用語は、１つ以上の命令セットを格納する単一の媒体又は複数の媒体（例えば、集中型又は分散型データベース、及び／又は関連するキャッシュ及びサーバ）を含むと解釈されるべきである。「コンピュータ可読格納メディア」などの用語はまた、機械によって実行するための一連の命令を格納し、符号化し、又は搭載することができ、機械に本発明の方法論のいずれか１つ以上を実施させる任意のメディアを含むと解釈されるものとする。したがって、「コンピュータ可読格納メディア」などの用語は、これらに限定されないが、固体メモリ、光メディア、及び磁気メディアを含むと解釈されるものとする。

前述の説明は、本発明のいくつかの実施形態の十分な理解をもたらすために、特定のシステム、構成要素、方法などの例のような多数の特定的な詳細を示している。しかしながら、本発明の少なくともいくつかの実施形態は、これらの特定的な詳細を伴わずに実践され得ることが当業者には明らかであろう。他の例では、本発明を不必要に曖昧にすることを回避するために、周知の構成要素又は方法は、詳細に説明されていないか、又は単純なブロック図形式で提示されている。したがって、記載されている特定的な詳細は単なる例示にすぎない。特有な実装は、これらの例示的な詳細とは異なり得るが、依然として本発明の範囲内であると考えられる。

上述の説明では、多くの詳細が説明されている。しかしながら、本開示の恩恵を有する当業者には、本発明の実施形態がこれらの特定的な詳細を伴わずに実践され得ることが明らかであろう。場合によっては、説明を曖昧にすることを回避するために、周知の構造とデバイスが詳細ではなくブロック図の形式で示されている。

詳細な説明の一部は、コンピュータメモリ内のデータビットに対する操作のアルゴリズムと記号表現の観点から提示されている。これらのアルゴリズムの記述及び表現は、データ処理技術の当業者が彼らの仕事の実体を当業者に最も効果的に伝えるために使用する手段である。アルゴリズムはここにあり、一般に、望ましい結果につながる自己矛盾のない一連のステップであると考えられている。これらのステップは、物理量の物理的な操作を必要とするものである。通常、必須ではないが、これらの量は、格納され、転送され、組み合わせられ、比較され、及び他の方法で操作されることが可能な電気信号又は磁気信号の形式をとる。主に共通な使用法の理由から、これらの信号をビット、値、要素、記号、文字、用語、数値などと呼ぶと便利な場合がある。

しかしながら、これらの、及び類似の用語はすべて、適切な物理量に関連付けられており、これらの量に適用される便利なラベルにすぎないことに注意すべきである。上記の議論から明らかであるように、特に明記しない限り、説明全体を通して、「判断する」、「識別する」、「追加する」、「選択する」などの用語を利用する議論は、コンピュータシステムのレジスタ及びメモリ内の物理的（例えば、電子的）量として表されたデータを操作し、コンピュータシステムメモリ又はレジスタ又は他のそのような情報格納、送信、又はディスプレイデバイス内の物理的量として同様に表された他のデータに変換するコンピュータシステム又は類似の電子コンピューティングデバイスのアクション及びプロセスを指すことを理解されたい。

本発明の実施形態はまた、本明細書の操作を実施するための装置に関する。この装置は、必要な目的のために特別に構築され得るか、又はコンピュータに格納されたコンピュータプログラムによって選択的に起動又は再構成される汎用コンピュータを含み得る。そのようなコンピュータプログラムは、限定されるものでないが、フロッピーディスク、光ディスク、ＣＤ－ＲＯＭ、及び磁気光学ディスクを含む任意タイプのディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード又は光カード、又は電子命令の格納に好適な任意タイプのメディアなどのコンピュータ可読記憶メディアに格納され得る。

本明細書に提示されるアルゴリズム及び表示は、特定のコンピュータ又は他の装置に本質的に関連付けられていない。様々なシステムが、本明細書の教示に従ってプログラムとともに使用され得るか、又は必要な方法ステップを実施するためのより専用化した装置を構築することが便利であることを証明し得る。これらの様々なシステムに必要な構造は、本明細書に記載の説明から明らかになる。加えて、本発明は、特定のプログラミング言語に関しては説明されていない。本明細書に記載されているように本発明の教示を実装するために、様々なプログラミング言語が使用され得ることが理解されよう。

前述の詳細な説明では少なくとも１つの例示的な実施形態を提示したが、非常に多くの変形が存在することを理解されたい。また、本明細書に記載される例示的な実施形態（複数可）は、特許請求される主題の範囲、適用性、又は構成を決して限定することを意図するものではないことも理解されたい。むしろ、前述の詳細な説明は、説明された実施形態（複数可）を実装するための便利なロードマップを当業者に提供するであろう。本特許出願の時点で既知の均等物及び予測可能な均等物を含む請求項によって定義される範囲から逸脱することなく、要素の機能及び配設に様々な変更を加えることができることを理解されたい。

Claims (20)

1. ハードウェアベースの処理システムを介し個人化された食事及び健康のアドバイス又は提案を生成するためのサーバレスアーキテクチャを使用して実装されたコンピュータ実装データ収集及び処理の方法であって、
   ストレージモジュール内の複数の異なるソースからデータを収集して集約することであって、前記データが異なるタイプ又は形式のデータを含む、収集して集約するステップと、
   前記異なるタイプ又は形式のデータを健康及び栄養プラットフォームと互換性のある標準化された構造化形式に変換することによって、前記異なるタイプ又は形式のデータのソースにとらわれない様式で前記異なるタイプ又は形式のデータの各々を継続的に処理するステップと、
   前記標準化された構造化形式に変換されたデータを前記健康及び栄養プラットフォームからの情報の一部を使用して分析するステップと、
   複数の個別ユーザの各々のために個人化された食事及び健康のアドバイス又は提案を生成するステップと、
   を含むことを特徴とする方法。
2. 前記異なるタイプ又は形式のデータが、構造化データ及び非構造化データを含む、
   ことを特徴とする請求項１に記載の方法。
3. 前記データが、複数の個別ユーザに固有の食品、健康、又は栄養データを含む、
   ことを特徴とする請求項１に記載の方法。
4. 前記標準化された構造化データが、
   １つ以上の人工ニューラルネットワークと、
   １つ以上の回帰モデルと、
   １つ以上の決定木モデルと、
   １つ以上のサポートベクターマシンと、
   １つ以上のベイジアンネットワークと、
   １つ以上の確率的機械学習モデルと、
   １つ以上のガウス処理モデルと、
   １つ以上の隠れマルコフモデルと、
   １つ以上の深層学習ネットワークと、を含む１つ以上の機械学習モデルを使用して分析されている、
   ことを特徴とする請求項１に記載の方法。
5. 前記データが、前記複数の異なるソースから複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を介して収集されて集約されている、
   ことを特徴とする請求項１に記載の方法。
6. １つ以上の異なるエンティティに関連付けられたトークンモジュールを介して前記複数のＡＰＩと通信するステップと、
   をさらに含み、
   前記複数のＡＰＩからの前記データが、取り出しモジュールを使用して収集されて集約され、
   前記取り出しモジュールが、前記トークンモジュールから切り離れて独立している、
   ことを特徴とする請求項５に記載の方法。
7. 前記トークンモジュールが、既存のトークンをリフレッシュし、トークン変更に関する通知更新情報を提供するように構成され、
   新しいトークンが生成される度に、前記新しいがトークンが、前記トークンモジュール内に格納されることに加え、前記取り出しモジュール内で別個に複製される、
   ことを特徴とする請求項６に記載の方法。
8. 前記ストレージモジュールが、複製データを検証し、チェックし、除去し、選択されたタイプのデータを統合することによって前記データをまとめ、前記データをバッチで保持するように構成されている、
   ことを特徴とする請求項１に記載の方法。
9. 前記データを前記収集して集約するステップが、前記データを複数のストリームに格納することを含む、
   ことを特徴とする請求項１に記載の方法。
10. 前記データの前記処理が、異なる条件の発生時に、前記複数のストリームに格納された前記データにラムダ関数を実行することをさらに含む、
    ことを特徴とする請求項９に記載の方法。
11. 前記ラムダ関数が、前記データが収集され前記複数のストリームに格納されたときにだけ実行され、
    前記ラムダ関数の前記格納されたデータへの前記実行が、データの各行を前記複数のストリームからの関連するストリームに流して転送するように構成されている、
    ことを特徴とする請求項１０に記載の方法。
12. 前記データが、前記複数のストリームの一方のストリームから別のストリームにカスケードすることによって、データパイプラインに沿って進められる、
    ことを特徴とする請求項１１に記載の方法。
13. 前記複数のストリームの各々が、前記データが各ストリームに格納されているタイムフレームを規定する保持ポリシーを有する、
    ことを特徴とする請求項９に記載の方法。
14. 前記複数のストリームが複数のシャードを含み、
    各シャードが（１）キューに入り、かつ（２）前記保持ポリシーの満了時に前記キューから出るデータレコードのストリングを含み、
    前記データレコードのストリングが、複数の個別ユーザに固有の食品消費、健康、又は栄養の記録を含む、
    ことを特徴とする請求項１３に記載の方法。
15. 前記複数のストリームのいくつかのシャードを制御することによって、前記データが処理される速度を制御するステップをさらに含む、
    ことを特徴とする処理されている請求項１４に記載の方法。
16. 前記複数の異なるソースからの前記データの前記収集及び集約が、
    （１）ソースの第１のセットからデータをプルすることであって、これがタスクスケジューラを使用して所定の時間間隔でデータがプルされることを可能にする、プルすることと、
    （２）複数のプル要求及びプッシュ要求からの前記データが一元化された場所にストリーミングされるように、ソースの第２のセットからプッシュされたデータを受信することであって、前記ソースの第２のセットからの前記データの前記プッシュが前記データに関連付けられた１つ以上の通知によって優先されている、受信することと、
    （３）データが対応する通知とともに到着しない場合、前記対応する通知に関連付けられた前記データをプルすることと、を含む、
    ことを特徴とする請求項１に記載の方法。
17. 格納された前記データの一部分が、１つ以上の画像化デバイスを使用してキャプチャされた複数の画像を含み、
    選択されたラムダ関数が前記格納されたデータの前記一部分で実行されて、前記複数の画像のいずれかが、その栄養成分ついて分析される１つ以上の食品画像を含むかどうかを検出する、
    ことを特徴とする請求項１に記載の方法。
18. 前記１つ以上の食品画像が、タイムスタンプ及びジオロケーションに関連付けられ、それによってユーザの食品摂取の時間的及び空間的な追跡を可能にし、
    前記ユーザの食品摂取の前記時間的及び空間的な追跡が、食事の摂取時間又は食事の内容を予測することを含む、
    ことを特徴とする請求項１７に記載の方法。
19. ハードウェアベースの処理システムを介し個人化された食事及び健康のアドバイス又は提案を生成するためのサーバレスアーキテクチャを使用して実装されたデータ収集及び処理システムであって、
    前記システムが、少なくとも１つのハードウェアベースのプロセッサ及びメモリを備え、前記メモリが、非一時的プロセッサ可読メディアにエンコードされたプロセッサで実行可能な命令を含み、
    前記プロセッサで実行可能な命令は、前記プロセッサによって実行されるとき、
    ストレージモジュール内の複数の異なるソースからデータを収集して集約することであって、前記データが異なるタイプ又は形式のデータを含む、収集して集約することと、
    前記異なるタイプ又は形式のデータを健康及び栄養プラットフォームと互換性のある標準化された構造化形式に変換することによって、前記異なるタイプ又は形式のデータのソースにとらわれない様式で前記異なるタイプ又は形式のデータの各々を継続的に処理することと、
    前記標準化された構造化形式に変換されたデータを前記健康及び栄養プラットフォームからの情報の一部を使用して分析することと、
    複数の個別ユーザの各々のために個人化された食事及び健康のアドバイス又は提案を生成することと、
    を生じさせるように構成される、
    ことを特徴とするシステム。
20. 個人化された食事及び健康のアドバイス又は提案を生成するためのサーバレスのデータ収集及び処理システムであって、前記システムが、
    ハードウェアベースの処理システムによって実行されるとき、ストレージモジュール内の複数の異なるソースからデータを収集して集約することを生じさせるように構成可能である取り出しモジュールであって、前記データが異なるタイプ又は形式のデータを含んでいる、取り出しモジュールと、
    前記ハードウェアベースの処理システムによって実行されるとき、前記異なるタイプ又は形式のデータを健康及び栄養プラットフォームと互換性のある標準化された構造化形式に変換することによって、前記異なるタイプ又は形式のデータのソースにとらわれない様式で前記異なるタイプ又は形式のデータの各々を継続的に処理することを生じさせるように構成可能である標準化モジュールと、
    前記ハードウェアベースの処理システムによって実行されるとき、前記標準化された構造化形式に変換されたデータを前記健康及び栄養プラットフォームからの情報を部分的に使用して分析することと、前記複数の個別ユーザの各々のために個人化された食事及び健康のアドバイス又は提案を生成することと、を生じさせるように構成可能である１つ以上の機械学習モデルを有するプラットフォームと、
    を備えることを特徴とするシステム。

Images