知財求人 - 知財ポータルサイト「IP Force」
特表2024-531667前糖尿病のためのデジタルかつパーソナライズされたリスク監視及び栄養計画システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-08-29
(54)【発明の名称】前糖尿病のためのデジタルかつパーソナライズされたリスク監視及び栄養計画システム
(51)【国際特許分類】
G16H 20/60 20180101AFI20240822BHJP
【ＦＩ】
G16H20/60
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024515620
(86)(22)【出願日】2022-09-21
(85)【翻訳文提出日】2024-03-11
(86)【国際出願番号】 EP2022076163
(87)【国際公開番号】W WO2023046718
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】63/246,394
(32)【優先日】2021-09-21
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】590002013
【氏名又は名称】ソシエテ・デ・プロデュイ・ネスレ・エス・アー
(74)【代理人】
【識別番号】100088155
【弁理士】
【氏名又は名称】長谷川 芳樹
(74)【代理人】
【識別番号】100140453
【弁理士】
【氏名又は名称】戸津 洋介
(74)【代理人】
【識別番号】100123995
【弁理士】
【氏名又は名称】野田 雅一
(72)【発明者】
【氏名】ダリモント‐ニコラウ， クリスチャン
(72)【発明者】
【氏名】カンポス， ヴァネッサ キャロライン
(72)【発明者】
【氏名】スクッチマラ， エリック アントワーヌ
(72)【発明者】
【氏名】ドゥダン， フローラン
(72)【発明者】
【氏名】プロゾロフスカイア， ダニエラ
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA15
(57)【要約】
本方法は、ユーザ特有の前糖尿病リスクを評価するためのアプリケーションであって、ユーザ特有の前糖尿病リスクを評価するためにユーザ属性の入力を促すアプリケーションを生成することと、ユーザデバイスからユーザのユーザ属性を、該ユーザに関するユーザ特有の前糖尿病リスクを評価するために受信することと、該ユーザに関連付けられた特徴ベクトルをユーザ属性のベクトル化に基づいて生成することと、該ユーザに関連付けられた特徴ベクトルと複数の基準特徴ベクトルとを含む複数の特徴ベクトルのクラスタリングを行うことと、クラスタリングに基づいて該ユーザの前糖尿病リスクレベルを判定することと、該ユーザの前糖尿病リスクレベル及びユーザ属性に基づいて該ユーザのための食物摂取量の推奨を生成することと、を含む。
【選択図】図３
【選択図】図３
【特許請求の範囲】
【請求項1】
パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨する方法であって、ユーザ特有の前糖尿病リスクを評価するためのアプリケーションであって、前記ユーザ特有の前糖尿病リスクを評価するためにユーザ属性の入力を促すアプリケーションを、アプリケーションプログラミングインターフェースを介して、１つ以上のプロセッサを有するコンピューティングデバイスによって生成することと、
ユーザに関連付けられたユーザデバイスから、前記コンピューティングデバイスによって受信することであって、前記ユーザの前記ユーザ特有の前糖尿病リスクを評価するために前記ユーザの１つ以上のユーザ属性を受信することと、
前記ユーザに関連付けられた特徴ベクトルを、前記１つ以上のユーザ属性のベクトル化に基づいて生成することと、
前記ユーザに関連付けられた前記特徴ベクトルと複数の基準特徴ベクトルとを含む複数の特徴ベクトルのクラスタリングを行うことと、
前記ユーザの前糖尿病リスクレベルを、前記クラスタリングに基づいて判定することと、
前記ユーザのための食物摂取量の推奨を、前記ユーザの前記前糖尿病リスクレベル及び前記１つ以上のユーザ属性に基づいて、前記コンピューティングデバイスによって生成することと、
を含む、方法。
【請求項2】
前記クラスタリングを前記行うことが、形成すべきクラスタの個数を、前糖尿病リスクレベルの個数に基づいて決定することと、
１回以上の繰り返しを行うことであって、
前記ユーザに関連付けられた前記特徴ベクトルと前記複数の基準特徴ベクトルとを含む前記複数の特徴ベクトルの中から重心特徴ベクトルを、形成すべきクラスタの前記個数の各々のクラスタについて選択することと、
前記複数の特徴ベクトルの各々の平均距離を判定することと、
の繰り返しを行うことと、
前記個数のクラスタのうち各々のクラスタに属する特徴ベクトルを、前記平均距離を最小化する重心のセットに基づいて特定することと、
各々のクラスタに関連付けられた前糖尿病リスクレベルを判定することと、を含む、
請求項１に記載の方法。
【請求項3】
前記１つ以上のユーザ属性を前記受信することが、生理学的データを入力するように前記ユーザに要求するメッセージを、前記アプリケーションを介して前記ユーザデバイスに送信することと、
前記生理学的データを前記ユーザデバイスから受信することと、を含む、
請求項１に記載の方法。
【請求項4】
ユーザ特有の製品セットを、前記ユーザの前記前糖尿病リスクレベル及び前記１つ以上のユーザ属性に基づいて決定することを更に含み、前記食物摂取量の前記推奨が、前記ユーザ特有の製品セットからの１つ以上のユーザ特有の製品に関する推奨を含む、請求項１に記載の方法。
【請求項5】
活動レベル、食物過敏症、食嗜好、又は併存症のうち１つ以上を入力するように前記ユーザに要求するメッセージを、前記アプリケーションを介して前記ユーザデバイスに送信することと、前記活動レベル、前記食物過敏症、前記食嗜好、又は前記併存症のうち前記１つ以上に基づいて、ユーザ特有の製品を、前記ユーザ特有の製品セットからフィルタリングすることと、
を更に含む、請求項４に記載の方法。
【請求項6】
前記ユーザのための食物摂取量選択肢を、前記ユーザの前記１つ以上のユーザ属性に基づいて、前記コンピューティングデバイスによって生成することと、前記ユーザのための前記食物摂取量選択肢を、前記ユーザの前記前糖尿病リスクレベルに基づいてフィルタリングして、前記ユーザのための前記食物摂取量の前記推奨を生成することと、
を更に含む、請求項１に記載の方法。
【請求項7】
前記食物摂取量選択肢を前記フィルタリングすることが、グリセミック負荷を、各々の食物摂取量選択肢について判定することと、
各々の食物摂取量選択肢の前記グリセミック負荷を、前記ユーザの前記前糖尿病リスクレベルに関連付けられた閾値グリセミック負荷と比較することと、を含む、
請求項６に記載の方法。
【請求項8】
前糖尿病リスクを監視し、食物摂取量を推奨するためのシステムであって、１つ以上のプロセッサと、
命令を記憶するメモリと、を備え、前記命令が前記プロセッサによって実行されると、前記システムに、
前糖尿病リスクを評価するためのアプリケーションであって、前記前糖尿病リスクを評価するためにユーザ属性の入力を促すアプリケーションを、アプリケーションプログラミングインターフェースを介して生成させ、
ユーザに関連付けられたユーザデバイスから、前記ユーザの前記前糖尿病リスクを評価するために１つ以上のユーザ属性を受信させ、
前記ユーザに関連付けられた特徴ベクトルを、前記１つ以上のユーザ属性のベクトル化に基づいて生成させ、
前記ユーザに関連付けられた前記特徴ベクトルと複数の基準特徴ベクトルとを含む複数の特徴ベクトルのクラスタリングを行わせ、
前記ユーザの前糖尿病リスクレベルを、前記クラスタリングに基づいて判定させ、
前記ユーザのための食物摂取量の推奨を、前記ユーザの前記前糖尿病リスクレベル及び前記１つ以上のユーザ属性に基づいて生成させる、
システム。
【請求項9】
前記命令が、前記プロセッサに、形成すべきクラスタの個数を、前糖尿病リスクレベルの個数に基づいて決定することと、
１回以上の繰り返しを行うことであって、
前記ユーザに関連付けられた前記特徴ベクトルと前記複数の基準特徴ベクトルとを含む前記複数の特徴ベクトルの中から重心特徴ベクトルを、形成すべきクラスタの前記個数の各々のクラスタについて選択することと、
前記複数の特徴ベクトルの各々の平均距離を判定することと、
の繰り返しを行うことと、
前記個数のクラスタのうち各々のクラスタに属する特徴ベクトルを、前記平均距離を最小化する重心のセットに基づいて特定することと、
各々のクラスタに関連付けられた前糖尿病リスクレベルを判定することと、
によってクラスタリングを行わせる、
請求項８に記載のシステム。
【請求項10】
前記命令が実行されると、前記システムに、生理学的データを入力するように前記ユーザに要求するメッセージを、前記アプリケーションを介して前記ユーザデバイスに送信することと、
前記生理学的データを前記ユーザデバイスから受信することと、によって前記１つ以上のユーザ属性を受信させる、
請求項８に記載のシステム。
【請求項11】
前記命令が実行されると、前記システムに、ユーザ特有の製品セットを、前記ユーザの前記前糖尿病リスクレベル及び前記１つ以上のユーザ属性に基づいて決定させ、前記食物摂取量の前記推奨が、前記ユーザ特有の製品セットからの１つ以上のユーザ特有の製品に関する推奨を含む、
請求項８に記載のシステム。
【請求項12】
前記命令が実行されると、前記システムに更に、活動レベル、食物過敏症、食嗜好、又は併存症のうち１つ以上を入力するように前記ユーザに要求するメッセージを、前記アプリケーションを介して前記ユーザデバイスに対して送信させ、
前記活動レベル、前記食物過敏症、前記食嗜好、又は前記併存症のうち前記１つ以上に基づいて、ユーザ特有の製品を、前記ユーザ特有の製品セットからフィルタリングさせる、
請求項１０に記載のシステム。
【請求項13】
前記命令が実行されると、前記システムに更に、前記ユーザのための食物摂取量選択肢を、前記ユーザの前記１つ以上のユーザ属性に基づいて生成させ、
前記ユーザのための前記食物摂取量選択肢を、前記ユーザの前記前糖尿病リスクレベルに基づいてフィルタリングして、前記ユーザのための前記食物摂取量の前記推奨を生成させる、
請求項８に記載のシステム。
【請求項14】
前記命令が実行されると、前記システムに、グリセミック負荷を、各々の食物摂取量選択肢について判定することと、
各々の食物摂取量選択肢の前記グリセミック負荷を、前記ユーザの前記前糖尿病リスクレベルに関連付けられた閾値グリセミック負荷と比較することと、によって、前記食物摂取量選択肢をフィルタリングさせる、
請求項１３に記載のシステム。
【請求項15】
前糖尿病リスクを監視し、食物摂取量を推奨するためのコンピュータ実行可能プログラミング命令を含むコンピュータシステム上で使用するための非一時的コンピュータ可読媒体であって、前記命令が、ユーザ特有の前糖尿病リスクを評価するためのアプリケーションであって、前記ユーザ特有の前糖尿病リスクを評価するためにユーザ属性の入力を促すアプリケーションを、アプリケーションプログラミングインターフェースを介して、前記コンピュータシステムによって生成することと、
それぞれの複数のユーザに関連付けられた複数のユーザデバイスの各々について、
前記ユーザの前記ユーザ特有の前糖尿病リスクを評価するために前記ユーザの１つ以上のユーザ属性を、前記ユーザに関連付けられた前記ユーザデバイスから受信すること及び、
前記ユーザに関連付けられた特徴ベクトルを、前記１つ以上のユーザ属性のベクトル化に基づいて生成することと、
前記それぞれの複数のユーザに関連付けられた複数の特徴ベクトルのクラスタリングを行うことと、
前記複数のユーザの各々の前糖尿病リスクレベルを、前記クラスタリングに基づいて判定することと、
前記ユーザのための食物摂取量の推奨を、前記前糖尿病リスクレベル及び前記ユーザの前記１つ以上のユーザ属性に基づいて、前記複数のユーザの各々について生成することと、
を含む、非一時的コンピュータ可読媒体。
【請求項16】
前記クラスタリングを前記行うことが、形成すべきクラスタの個数を、前糖尿病リスクレベルの個数に基づいて決定することと、
１回以上の繰り返しを行うことであって、
前記複数の特徴ベクトルの中から重心特徴ベクトルを、形成すべきクラスタの前記個数の各々のクラスタについて選択することと、
前記複数の特徴ベクトルの各々の平均距離を判定することと、
の繰り返しを行うことと、
前記個数のクラスタのうち各々のクラスタに属する特徴ベクトルを、前記平均距離を最小化する重心のセットに基づいて特定することと、
各々のクラスタに関連付けられた前糖尿病リスクレベルを判定することと、を含む、
請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項17】
前記命令が更に、前記複数のユーザのうち所与のユーザについて、ユーザ特有の製品セットを、前記所与のユーザの前記前糖尿病リスクレベル及び前記１つ以上のユーザ属性に基づいて決定することを含み、前記所与のユーザのための前記食物摂取量の前記推奨が、前記ユーザ特有の製品セットからの１つ以上のユーザ特有の製品に関する推奨を含む、
請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項18】
前記命令が更に、前記複数のユーザデバイスのうち所与のユーザデバイスに、前記アプリケーションを介して、メッセージであって、活動レベル、食物過敏症、食嗜好、又は併存症のうち１つ以上を入力するように、前記所与のユーザデバイスに関連付けられた所与のユーザに要求する、メッセージを送信することと、
前記活動レベル、前記食物過敏症、前記食嗜好、又は前記併存症のうち前記１つ以上に基づいて、ユーザ特有の製品を、前記ユーザ特有の製品セットからフィルタリングすることと、
を含む、請求項１７に記載の非一時的コンピュータ可読媒体。
【請求項19】
前記命令が更に、前記複数のユーザのうち所与のユーザの前記１つ以上のユーザ属性に基づいて、前記コンピュータシステムによって、前記ユーザのための食物摂取量選択肢を生成することと、
前記所与のユーザのための前記食物摂取量選択肢を、前記所与のユーザの前記前糖尿病リスクレベルに基づいてフィルタリングして、前記所与のユーザのための前記食物摂取量の前記推奨を生成することと、
を含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項20】
前記食物摂取量選択肢を前記フィルタリングすることが、グリセミック負荷を、前記所与のユーザの各々の食物摂取選択肢について判定することと、
各々の食物摂取量選択肢の前記グリセミック負荷を、前記所与のユーザの前記前糖尿病リスクレベルに関連付けられた閾値グリセミック負荷と比較することと、
を含む、請求項１９に記載の非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
[0001]本開示のある特定の態様は、概して、前糖尿病のための推奨食事計画を提供するデジタルかつパーソナライズされた健康監視システムに関する。システムへの入力は、指名されたユーザの栄養摂取量、食嗜好、性別、体重、及び年齢を含むが、これらに限定されない。
【背景技術】
【0002】
[0002]前糖尿病は、世界中で何億人もの人々に影響を及ぼしている、グローバルな健康関連の緊急課題である。前糖尿病は、血糖値が正常よりも高いが、まだ糖尿病と診断されるほどは高くない状態である。医師は、前糖尿病を耐糖能異常（ｉｍｐａｉｒｅｄｇｌｕｃｏｓｅ ｔｏｌｅｒａｎｃｅ：ＩＧＴ）又は空腹時血糖異常（ｉｍｐａｉｒｅｄ ｆａｓｔｉｎｇ ｇｌｕｃｏｓｅ：ＩＦＧ）と呼ぶこともある。世界保健機関（ＷＨＯ）は、ＩＧＴ又はＩＦＧを有する人々は糖尿病を発症するリスクが高い可能性があると述べている。ある人が前糖尿病を有するか試験する方法はいくつかあり得るが、相対的に前糖尿病の明白な症状が存在しないことは、その個人が前糖尿病にかかっていることを知らない可能性があることを意味する。
【0003】
[0003]糖尿病は、膵臓が十分なインスリンを産生しないこと、又は身体の細胞がインスリンに適切に応答しないことの結果であり得る。糖尿病を治癒させる方法は知られてないため、糖尿病を予防する１つの方法は、生活習慣介入によって前糖尿病を後退させることによるものである。例えば、前糖尿病の発現を緩和する推奨食生活は糖尿病の予防に役立ち得る。前糖尿病と診断された人又は前糖尿病のリスクがある人に、より効果的に関与し、実用的かつ効果的な推奨食物摂取量（ｄｉｅｔａｒｙｉｎｔａｋｅ）を提供する、デジタルかつパーソナライズされた栄養計画システムに対する要望及び必要性が存在する。ユーザの健康に対する食物摂取量の影響を評価する１つの方法は、食物摂取量のグリセミック負荷による評価である。グリセミック負荷（ｇｌｙｃｅｍｉｃｌｏａｄ：ＧＬ）とは、食物摂取量が摂取後に人の血糖値をどれだけ上昇させるかを推定する数を指す。従来のグリセミック負荷の判定方法では、グリセミック指数を低下させる様々な原材料を含み得る、食料製品の微妙な差異が見落とされる。より正確で信頼性の高いグリセミック負荷測定に基づいた、デジタルかつパーソナライズされた栄養の監視及び計画のシステムに対する要望及び必要性が存在する。
【0004】
[0004]本開示の様々な実施形態は、上に提示された欠点のうちの１つ以上に対処する。
【発明の概要】
【0005】
[0005]本開示は、パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨するための新規かつ革新的な方法及びシステムを提示する。一実施形態では、ユーザ特有の前糖尿病リスクを評価するためのアプリケーションを（例えばアプリケーションプログラミングインターフェースを介して）生成する、コンピューティングデバイス（例えばアプリケーションサーバ）を含む方法が提供される。このアプリケーションは、ユーザ特有の前糖尿病リスクを評価するためにユーザ属性の入力を促してもよい。コンピューティングデバイスは、あるユーザに関連付けられたユーザデバイスから、（例えば、そのユーザについてのユーザ特有の前糖尿病リスクを評価するために）１つ以上のユーザ属性を受信してもよい。例えば、ユーザ属性として、血糖値、年齢、体重、性別、生理学的データ、食嗜好、病的状態などが挙げられる。コンピューティングデバイスは、その１つ以上のユーザ属性のベクトル化に基づいて、そのユーザに関連付けられた特徴ベクトルを生成してもよい。ユーザに関連付けられた特徴ベクトルは、複数の他のユーザ又は基準に関連付けられた基準特徴ベクトルと、（例えばプロットすることによって）比較されてもよい。コンピューティングデバイスは、ユーザに関連付けられた特徴ベクトルと複数の基準特徴ベクトルとを含む複数の特徴ベクトルのクラスタリング（例えば、ｋ－ｍｅａｎｓクラスタ）を行ってもよい。クラスタリングの結果、異なる前糖尿病リスクレベルを表す、離散的な個数のクラスタが得られ得る。コンピューティングデバイスはクラスタリングに基づいて、ユーザの前糖尿病リスクレベルを特定又は判定してもよい。ユーザの前糖尿病リスクレベル及び１つ以上のユーザ属性に基づいて、コンピューティングデバイスは、そのユーザのための食物摂取量の推奨を生成してもよい。
【0006】
[0006]いくつかの態様では、コンピューティングデバイスは、ユーザに生理学的データ（例えば心拍数、血圧、血糖値など）を入力するように要求するメッセージを、アプリケーションを介してユーザデバイスに送信してもよい。ユーザデバイスは生理学的データを（例えば、ユーザデバイスと通信可能に関連付けられたウェアラブル及び／又はアクセサリデバイスを介して）提供してもよく、この生理学的データはコンピューティングデバイスによって（例えば、１つ以上のユーザ属性として）受信されてもよい。
【0007】
[0007]いくつかの態様では、クラスタリングは、形成すべきクラスタの個数を、前糖尿病リスクレベルの個数に基づいて決定することを含んでもよい。コンピューティングデバイスは、ユーザに関連付けられた特徴ベクトルと複数の基準特徴ベクトルとを含む複数の特徴ベクトルの中から重心特徴ベクトルを、その形成すべきクラスタの個数の各々のクラスタについて選択することと、複数の特徴ベクトルの各々の平均距離を決定することとの、１回以上の繰り返しを行ってもよい。コンピューティングデバイスが、重心と特徴ベクトルとの間の平均距離を最小化する重心のセットを決定した後、コンピューティングデバイスは繰り返しを終了してもよい。多数のクラスタのうち各々のクラスタに属する特徴ベクトルが特定されてもよい。各々のクラスタは、各々のクラスタに関連付けられた前糖尿病リスクレベルを表してもよい。よって、例えば各々の前糖尿病リスクレベルにあるユーザを判定するために、各々のクラスタの特徴ベクトルが特定されてもよい。
【0008】
[0008]コンピューティングデバイスは、ユーザのためのユーザ特有の製品セットを（例えば、そのユーザの１つ以上のユーザ属性及びユーザの前糖尿病リスクレベルに基づいて）決定してもよい。生成される食物摂取量の推奨は、ユーザ特有の製品セットからの１つ以上のユーザ特有の製品（例えばサブセット）を含んでもよい。いくつかの態様では、ユーザは、ユーザ特有の製品のための１つ以上のフィルタを入力するように（例えば、ユーザデバイス上のアプリケーションを介して受信されるメッセージを介して）促されてもよく、フィルタには活動レベル、食物過敏症、食嗜好、又は併存症が含まれるが、これらに限定されない。コンピューティングデバイスは、ユーザによって入力された１つ以上のフィルタに基づいて、あるユーザ特有の製品を、ユーザ特有の製品セットからフィルタリングしてもよい。いくつかの態様では、コンピューティングデバイスは、各々の前糖尿病リスクレベルに属するユーザに推奨されるグリセミック負荷の閾値を決定してもよい。コンピューティングデバイスは、そのユーザの前糖尿病リスクレベルに対応するグリセミック負荷の閾値を満たすユーザ特有の製品があれば、ユーザ特有の製品セットから、それをフィルタリングしてもよい。よって、推奨食物摂取量の一部として、ユーザ特有の製品のフィルタセットを推奨することができる。
【0009】
[0009]いくつかの態様では、コンピューティングデバイスは、そのユーザの定期的な（例えば毎日、毎週などの）栄養素及び／又はカロリー要件及び、そのユーザの食事の栄養素及び／又は食事カロリー要件を特定してもよい。推奨食物摂取量は、これらの要件と比較され、更に精緻化及び／又はフィルタリングされてからユーザに提示されてもよい。
【0010】
[0010]別の実施形態では、パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨するためのシステムが開示される。システムは、１つ以上のプロセッサと、メモリとを備えてもよい。メモリは命令を記憶し、命令は、１つ以上のプロセッサによって実行されると、システムに、本明細書に記載の１つ以上の方法を行わせる。別の実施形態では、パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨するためのコンピュータ実行可能プログラミング命令を含む、コンピュータシステム上で使用するための非一時的コンピュータ可読媒体が開示される。命令は、本明細書に記載の１つ以上のステップ、方法、又はプロセスを含み得る。
【0011】
[0011]本明細書に記載の特徴及び利点は、包括的なものではなく、具体的には、図面及び説明を考慮することで多くの追加の特徴及び利点が当業者には明らかになるであろう。更に、本明細書で使用される言葉は、専ら読みやすさ及び指示を目的として選択されており、本発明の主題の範囲を限定するものではないことを留意されたい。
【図面の簡単な説明】
【0012】
【図1】本開示の一実施形態による、パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨するためのシステムを示す図である。
【図2】本開示の例示的な実施形態による、食料製品データベース例を示す図である。
【図3】本開示の例示的な実施形態による、パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨するための方法例のフロー図である。
【図4】本開示の例示的な実施形態による、前糖尿病リスクレベルに基づいてユーザをクラスタリングする方法例のフロー図である。
【図5】本開示の例示的な実施形態による、前糖尿病についてのリスクを監視し、前糖尿病のための推奨食物摂取量を提供するための食物摂取量選択肢の、グリセミック指数を判定する方法例のフロー図である。
【図6】本開示の例示的な実施形態による、食物摂取量選択肢のグリセミック指数を判定する方法例に適用可能な栄養素の補正係数の例を示す表である。
【図7】本開示の例示的な実施形態による、前糖尿病のための推奨食物摂取量を適用する方法例のフロー図である。
【図8】本開示の例示的な実施形態による、栄養素、カロリー、及びグリセミック負荷の毎日の要件の例を示す表である。
【図9】本開示の例示的な実施形態による、前糖尿病リスククラスタに基づく食事計画の生成を示す図である。
【発明を実施するための形態】
【0013】
[0021]前述したように、前糖尿病は、上昇しているが真性糖尿病を診断するための閾値は下回っている血糖値によって特徴付けられる代謝障害である。前糖尿病の予防又は治療は、真性糖尿病及び他の心血管疾患を予防するための有効な方法であり得る。人の食生活は、前糖尿病の進行と密接に結び付いていることがある。例えば、食事の摂取は、典型的には血糖値の増加をもたらし得、それにより、正常な状況下では身体がインスリンを産生するようになり得る。インスリンは、血流から身体の特定の細胞への血糖の取り込みを引き起こし得る。血糖の低下はグルカゴンの産生を誘発し得、その結果、（例えば、空腹及び食事の摂取を誘発することによって）血糖値を回復させる活動が起こり得る。
【0014】
[0022]本開示は概して、栄養意識を高め、前糖尿病リスクを監視し、前糖尿病を後退させる食物摂取量を推奨するための、パーソナライズされたデジタルプラットフォームに関する。パーソナライズされたデジタルプラットフォームは、プラットフォームがユーザのリスクカテゴリを評価できるように、関連情報を入力するようにユーザを促してもよい。例えば、ユーザは、年齢、体重、性別、及び毎日の食物摂取情報を入力してもよい。いくつかの態様では、ユーザは、バイオセンサ又はウェアラブルデバイスを介して生理学的データ（例えば、血糖情報）を入力するように促されてもよい。ユーザから受信した情報（例えばユーザ属性）は、例えばベクトル化を介して、定量化可能なデータとして編成されてもよい。そのユーザに属するユーザ属性が他のユーザに関連付けられたユーザ属性と比較されて、ユーザの前糖尿病リスクレベルが（例えば、クラスタリング又は他の機械学習モデルを通して）判定されてもよい。パーソナライズされたデジタルプラットフォームは、各々の前糖尿病リスクレベルに適した食物摂取量選択肢を、例えば各々の食物摂取量選択肢に関連付けられたグリセミック指数（ＧＩ）又はグリセミック負荷（ＧＬ）に基づいて、判定することができる。食物摂取量選択肢はまた、食事の栄養要件に加えて定期的な（例えば毎日、毎週などの）栄養要件に基づいてもよい。更に、食物摂取量選択肢は、食事のカロリー要件に加えて定期的な（例えば毎日、毎週などの）カロリー要件に基づいてもよい。いくつかの態様では、推奨食物摂取量は、前糖尿病に好都合なレシピ及び／又はカスタマイズされた食事計画としてユーザに提示されてもよい。ユーザは推奨食物摂取量をそのユーザのライフスタイルに組み込むように促されるので、ユーザは改善について定期的に（例えば、生理学的データの入力を促すことを介して）監視されてもよい。
【0015】
[0023]加えて、本開示は、ユーザの前糖尿病のリスクをより確実かつ正確に監視する（例えば、ユーザの食生活のグリセミック負荷を判定する改良された方法を介して）ための方法を提供する。グリセミック負荷とは、所与の量の食料摂取（例えば、１回の食事、１日、規定の時間長さにわたる）が摂取後に人の血糖値をどれだけ上昇させるかを推定する数を指す。グリセミック指数及びグリセミック負荷を判定するための従来の方法は、包括的な一覧表に見られる何百もの一般的な食品及び飲料の平均ＧＩ及びＧＬ値を集計することを伴う。ところが、そのような従来の方法は、実際の製品の特異性を反映していない（例えば、原材料の供給元の地域及び処理工程に応じて異なる）。第２に、そのような従来の方法は、食事内の非グリセミック成分（例えば、パン上のバター）のＧＩ低下効果を適切に考慮していない。ＧＬ及びＧＩを判定し、よってユーザのためのより確実かつ効果的な推奨食物摂取量を生成するための改良された方法について、例えば図５及び６に関連して、本明細書でより詳細に考察する。よって、開示されるデジタルかつパーソナライズされた栄養監視システムは、ユーザ特有の入力及び、改良されたグリセミック負荷の評価に基づいて、推奨食生活を生成する。
【0016】
[0024]図１は、本開示の一実施形態によるシステム１００を示す。システム１００は、あるユーザに関連付けられたユーザデバイス１０２と、本明細書に記載の１つ以上のステップ又は方法を行うための分析サーバ１２０と、を含む。ユーザデバイス１０２は、１つ以上のバイオセンサ及び／又はウェアラブルデバイス１１９に通信可能に結合されていてもよい。更に又は代替的に、バイオセンサ及び／又はウェアラブル１１９は、スタンドアロン型コンピューティングデバイス（例えば、病院及び／又は医療施設における）の一部であってもよい。これらのデバイス及び他の外部デバイス（図示せず）の各々は、通信ネットワーク１５０を介して互いに通信することができてもよく、通信ネットワーク１５０は、情報を伝播させるための任意の有線又は無線ネットワークであり得る。無線ネットワークの例としては、Ｗｉ－Ｆｉ（登録商標）、モバイル通信グローバルシステム（ＧＳＭ（登録商標））ネットワーク、汎用パケット無線サービス（ＧＰＲＳ）ネットワーク、エンハンストデータＧＳＭ環境（ＥＤＧＥ）ネットワーク、８０２．５通信ネットワーク、符号分割多元接続（ＣＤＭＡ）ネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク若しくはロングタームエボリューション（ＬＴＥ）ネットワーク、ＬＴＥアドバンスト（ＬＴＥ－Ａ）ネットワーク、又は第５世代（５Ｇ）ネットワークを挙げることができる。更に、各デバイスは、通信ネットワーク１５０を介した通信を容易にするために、それぞれのネットワークインターフェース（例えばネットワークインターフェース１１８及び１４６）を含んでもよい。例えば、それぞれのネットワークインターフェースは、有線インターフェース（例えば、電気的、ＲＦ（同軸ケーブル経由）、光学的（ファイバ経由））、無線インターフェース、モデムなどを含んでもよい。更に、これらデバイスの各々は、１つ以上のそれぞれのプロセッサ（例えばプロセッサ１０４及び１２２）及びメモリ（例えばメモリ１１０及び１３２）を含んでもよい。プロセッサは、あるデータストリームに、本開示で説明される機能を含めた動作を行うように構成された、１つ以上の種類のどのようなデジタル回路を備えてもよい。メモリは、任意のタイプの長期メモリ、短期メモリ、揮発性メモリ、不揮発性メモリ、又は他のメモリを含んでもよく、任意の特定のタイプのメモリ若しくはメモリの数、又はメモリが記憶される媒体のタイプに限定されるべきではない。メモリは命令を記憶してもよく、命令は、プロセッサにより実行されると、それぞれのデバイスに、本明細書で論じられる１つ以上の方法を行わせてもよい。
【0017】
[0025]ユーザデバイス１０２は、例えば、関連付けられたユーザがアプリケーション１１４の使用により分析サーバ１２０と通信することができる、コンピュータ、スマートフォン、タブレット、スマートウォッチ、又は他のウェアラブルなどの、コンピューティングデバイスとして実装することができる。ユーザデバイス１０２は、タッチ感知ディスプレイ、タッチスクリーン、ディスプレイデバイスを有するキーパッド、又はそれらの組み合わせを含み得るユーザインターフェース（ＵＩ）１１２を更に含んでもよく、ディスプレイ１０６に関連して機能してもよい。ＵＩ１１２は、第１のユーザが、分析サーバ１２０によって提示される音声、視覚、及び／又はテキスト情報をアプリケーション１１４を介して閲覧すること、１つ以上のアプリケーション１１４にアクセスして使用すること、例えばディスプレイ１０６上のアイコンをタッチして移動することによって、入力信号を入力すること、を可能にし得る。ディスプレイ１０６は、視覚情報（例えば、画像、ビデオなど）を出力する任意の媒体を備え得る。アプリケーション１１４は、本明細書に記載される方法を行うためのどのようなプログラム又はソフトウェアを含んでもよい。例えばアプリケーション１１４は、栄養素レベル及び／又は栄養必要量を監視し、食物摂取量を推奨するための、分析サーバ１２０によってホスティングされるアプリケーションを含んでもよい。ユーザは、アプリケーションに関連付けられたユーザプロファイル１１６を有してもよく、ユーザプロファイル１１６は、分析サーバ１２０により利用され得る複数のユーザ属性を含んでもよい。
【0018】
[0026]ユーザ属性には、そのユーザに関する人物情報詳細（例えば、ユーザ識別子、性別、体重、身長など）、ユーザの健康に関する情報（例えば活動レベル、併存症、健康目標など）、食嗜好及び過敏症、並びにアレルギーが含まれてもよい。更に、ユーザ属性は、前糖尿病リスクを評価するために生成されるデータ構造へのユーザ入力（例えば、標準化された、又は標準化されていない質問表への回答）を含んでもよい。いくつかの実施形態では、ユーザ属性は、第１のユーザの生理学的データを更に含み得る。生理学的データは、１つ以上のバイオセンサ、及び／又は１つ以上のバイオセンサを含むウェアラブルデバイス（例えば、「バイオセンサ／ウェアラブル」１１９）を介して取得することができる。いくつかの態様では、バイオセンサ／ウェアラブル１１９は、ユーザデバイス１０２の一部であってもよい、又はユーザデバイス１０２に通信可能にリンクされていてもよい。バイオセンサ／ウェアラブルは、グルコースモニタ、血圧計、心拍数測定デバイス、及び／又は活動レベルを測定するデバイス（例えば、ＦＩＴＢＩＴ（登録商標））を含んでもよいが、これらに限定されない。
【0019】
[0027]アプリケーション１１４は、ユーザの属性に基づいて食生活計画（例えば、摂食機会又は期間のための推奨食事、栄養素とカロリーとグリセミック負荷とに基づくガイドラインなど）を推奨し、ユーザの食料摂取量及び健康を監視する、パーソナライズされたデジタルプラットフォームを備えてもよい。
【0020】
[0028]分析サーバ１２０は、ローカル又は遠隔のコンピューティングシステムを備えてもよい。分析サーバ１２０は、他の機能の中でもとりわけ、ユーザデバイス１０２から受信した情報を要求して受信し、あるユーザ又はフォロワに関連付けられた情報を処理し、栄養素レベル及び栄養ニーズを予測するために、栄養素レベル及びユーザ属性に関する様々なユーザ特有のデータから学習して機械学習モデルを訓練し、様々な食物摂取量選択肢のグリセミック負荷を判定し、推奨製品及び製品の使用法のリストを生成し、推奨を送信する、ように構成されていてもよい。
【0021】
[0029]分析サーバ１２０の１つ以上のプロセッサ１２２は、画像プロセッサ１２４及び自然言語プロセッサ１２６を含み得る。画像プロセッサ１２４は、ユーザデバイス１０２によって生成された画像データをデジタル処理して、ノイズ及び他のアーチファクトを回避し、テキスト及び物理的オブジェクトを認識するためのそのような画像データを準備してもよい。自然言語プロセッサ１２６を使用して、テキストを認識し、画像データからキャプチャされたテキストから意味を判断してもよい。テキストは、ユーザ属性、及び認識可能な製品の識別子（例えば、製品名、会社名など）を含み得る。画像プロセッサ及び／又は自然言語プロセッサは、画像及びテキストデータから様々なユーザ属性についての情報（例えば、自然言語のテキストから得られる年齢及び体重情報、食品の画像から得られる１日あたりの摂取カロリー、健康状態を説明する自然言語のテキストから得られる健康状態など）を認識するために、機械学習モジュール１２８から得られた記憶されている機械学習モデルに依存してもよい。
【0022】
[0030]一態様では、機械学習モジュール１２８はクラスタリングユニット１３０を含んでもよい。クラスタリングユニット１３０は、特徴ベクトルのクラスタを特定するソフトウェア、プログラム、又は命令を備えてもよい。特徴ベクトルが含む値は、複数の個々のユーザについてのユーザ属性のセットに基づき、かつ対応してもよい。例えば、その値は、前糖尿病のリスク又は重症度を評価するための情報への要求に対するユーザ回答に対応してもよい。このように形成されたクラスタは、ユーザのリスクレベルを示し得る。いくつかの態様では、クラスタリングユニット１３０は、教師なし機械学習モデル（例えば、ジェンクス自然分類最適化、ｋ－ｍｅａｎｓクラスタリング、ｋ－ｍｅｄｉａｎｓクラスタリング、ｋ－ｍｅｄｏｉｄｓクラスタリング、ファジィＣ－ｍｅａｎｓクラスタリング、ＥＭアルゴリズム（Ｅｘｐｅｃｔａｔｉｏｎ－Ｍａｘｉｍｉｚａｔｉｏｎ Ａｌｇｏｒｉｔｈｍ）で訓練された混合ガウスモデル、ｋ－ｍｅａｎｓ＋＋など）を利用して、ｎ個の観測値（例えば、特徴ベクトル）をｋ個のクラスタに分割してもよく、ここで各々の観測値は、最も近い平均を有するクラスタに属する。いくつかの態様では、クラスタリングユニット１３０は、教師あり機械学習モジュール（例えば、マルチクラス分類、多項ロジスティック回帰、ｋ近傍法アルゴリズムなど）を利用してもよい。そのような態様では、機械学習モジュール１２４はまた、ある特定のユーザが属し得る特定のクラス（例えば、前糖尿病リスクレベル）を、そのユーザに関連付けられたユーザ属性に基づいて予測するようにモデルを訓練するために使用されてもよい。訓練は、基準訓練データを使用することを伴ってもよい。基準訓練データは特徴ベクトルを含んでもよく、各々の特徴ベクトルが含む値は、複数の個々のユーザについてのユーザ属性のセットに基づき、かつ対応する。特徴ベクトルは、それらの複数の個々のユーザの知られている前糖尿病リスクレベルに関連付けられていてもよく、教師あり機械学習モデルの一部として訓練されてもよい。
【0023】
[0031]分析サーバ１２０のメモリ１３２は、ユーザデータベース１３４、食料製品データベース１３６、及びアプリケーションプログラムインターフェース（ＡＰＩ）１３８を更に含んでもよい。ユーザデータベース１３４は、本明細書に提示されるシステム及び方法のユーザ（例えば、ユーザデバイス１０２に関連付けられたユーザを含む）に関連付けられた、それぞれのユーザプロファイルを記憶してもよい。食料製品データベース１３６は、パーソナライズされたデジタルプラットフォームの様々なユーザによって情報が入力された食料製品に並び、複数の認識可能な（例えば、市販の）食料製品に関する情報を記憶してもよい。食料製品は、食事又は食事の品目を構成することができ、知られている栄養情報、カロリー情報、グリセミック負荷、及び／又はグリセミック指数を有することができる。食料製品データベース１３６は、各々の製品の栄養及びカロリーの情報、レシピにおける製品の使用法、並びに、それらの使用を考慮した特別な指示及び警告を列挙してもよい。食料製品には、栄養及び食生活の補助食品に関連付けられた食料製品及び飲料製品が含まれ得る。食料製品の例には、ＮＵＴＲＥＮ ＤＩＡＢＥＴＩＫ、ＯＰＴＩＦＡＳＴ、ＮＵＴＲＥＮ ＭＥＡＬＴＩＭＥ ＣＯＭＰＡＮＩＯＮ、又はＲＥＤＵＣＯＳＥが含まれ得る。
【0024】
[0032]メモリ１３２はまた、ユーザデバイス１０２内の１つ以上のアプリケーション（例えばアプリケーション１１４）を、ホスティング、管理、又は円滑化するアプリケーションプログラムインターフェース（ＡＰＩ）１３８を含んでもよい。例えば、ＡＰＩ１３８は、栄養素レベルの監視、及び食物摂取量の推奨を可能にするアプリケーションを管理してもよい。食生活推奨エンジン１４０は食事計画エンジンとも称され、所与のユーザの食事のための適切な推奨を、その所与のユーザのための１つ以上の製品からなるセットに関連付けられた食事を含めて生成する、１つ以上のプログラム、アプリケーション、又は実装を備えてもよい。食生活推奨エンジン１４０は、ユーザデータベース１３４、食料製品データベース１３６、及びクラスタリングユニット１３０を利用してもよい。いくつかの態様では、食生活推奨エンジン１４０は、ＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢ（固有名詞）１６０などの外部データベースを利用して、食事のために提案されるレシピの形態で推奨食物摂取量を提供してもよい。
【0025】
[0033]ＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢ１６０は、食料製品についてのレシピのリポジトリを備えてもよい。各レシピは、食事又は摂食機会（例えば朝食、昼食、夕食、間食など）及び料理タイプ（例えば主食、副菜など）によってタグ付けされてもよい。更に、各レシピは、レシピに関連付けられた食料製品又は食料製品成分に関する栄養情報を提供してもよい。いくつかの態様では、ＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢ１６０は分析サーバ１２０の一部であってもよい。
【0026】
[0034]分析サーバ１２０は、更新インターフェース１４８を更に含んでもよい。更新インターフェース１４８は、１つ以上のデータベース（例えばユーザデータベース１３４、製品データベース１３６など）を作成、読み取り、更新、又は削除（ｃｒｅａｔｅ，ｒｅａｄ，ｕｐｄａｔｅ，ｏｒ ｄｅｌｅｔｅ：ＣＲＵＤ）機能を介して管理するための、データベース管理プログラム又はアプリケーションを含んでもよい。いくつかの態様では、更新インターフェース１４８は、例えば、栄養素レベルを監視し、食物摂取量を推奨するためのアプリケーションに新しいユーザが登録を希望するときなどに、外部デバイス（例えばユーザデバイス１０２）が１つ以上のデータベースを更新できるようにしてもよい。
【0027】
[0035]図２は、本開示の例示的な実施形態による、食料製品データベース例２００を示す。前述したように、食料製品データベース２００は分析サーバ１２０の構成要素であってもよい。食料製品データベース２００は、ユーザの前糖尿病リスクレベルを判定するためにユーザを監視すること又はユーザの食習慣を評価することの一部として、分析サーバ１２０がユーザの摂取した食事又は食料製品を特定できるようにしてもよい。更に又は代替的に、食料製品データベース２００は、分析サーバ１２０がユーザの前糖尿病リスクレベル及びユーザに関連付けられたユーザ属性に基づいて食物摂取量を推奨できるようにしてもよい。そのユーザのための、様々な食料製品を考慮した推奨食物摂取量は、ユーザが前糖尿病のリスク又は症状を改善又は克服するために役立ち得る。食料製品データベース２００は、複数の食料製品２０２のプロファイルを含んでもよい。
【0028】
[0036]いくつかの食料製品は、食料製品成分及び原材料が知られている、又は容易に入手可能であり得る、市販又は家庭用の食料製品を含み得ることが企図される。ただし、他の食料製品のプロファイルがユーザによって作成され、例えば更新インターフェース２１２を介して、食料製品データベース２００に記憶されてもよい。
【0029】
[0037]食料製品プロファイル２０２は、食料製品を構成する１つ以上の食料製品成分２０４（例えば原材料）についての情報を含んでもよい。更に、各々の食料製品成分２０４内の栄養素２０６についての情報が記憶されてもよい。栄養素２０６の情報は、様々な糖質（例えば単糖類、二糖類、多糖類、糖アルコールなど）、ＧＩを低下させる主要栄養素（例えば、繊維、β－グルカン、脂肪タンパク質、灰、水）、ビタミン、ミネラルなどの量又は割合を含んでもよい．更に、食料製品データベース２００は、各々の食料製品成分２０４について、そのグリセミック負荷２０８、グリセミック指数２１０、及びカロリー２１１を記憶してもよく、３つのうちいずれも、食料製品成分中の栄養素２０６に基づいてもよい。いくつかの態様では、グリセミック負荷２０８及びグリセミック指数２１０は、本明細書に提示される方法を使用して（例えば図５及び６に関連して説明されるように）、食料製品成分の栄養素２０６に基づいて自動的に計算されてもよい。ある食料製品、あるレシピ、ある食事、ある一日の食料摂取量、ある週の食料摂取量などの、グリセミック負荷、グリセミック指数、カロリー及び／又は栄養素を判定するために、個々の食料製品成分のグリセミック負荷２０８、グリセミック指数２１０、カロリー２１１、及び／又は栄養素２０６が集計されてもよい。
【0030】
[0038]更新インターフェース２１２は更新インターフェース１４８を含むか、その一部であるか、又はそれと同様の機能を行ってもよく、食料製品データベース２００のいずれかの局面を更新するために使用されてもよい。更に、クエリ最適化部２１４が、外部構成要素及びデバイスが食料製品データベース２００から情報をより効率的かつ正確に取り出せるようにしてもよい。
【0031】
[0039]図３は、本開示の例示的な実施形態による、パーソナライズされたデジタルプラットフォームを介して、前糖尿病についてのリスクを監視し、食物摂取量を推奨するための方法例３００のフロー図を示す。方法３００は、分析サーバ１２０の１つ以上のプロセッサによって行われてもよい。方法３００は、分析サーバ１２０がユーザの前糖尿病リスクレベルを判定し、栄養、カロリー、及びグリセミック負荷のニーズを判定し、食物摂取量を推奨し、ユーザの前糖尿病リスクを監視できるようにする、アプリケーション１１４のユーザの能力に関係してもよい。
【0032】
[0040]複数のユーザが前糖尿病リスク又は症状を改善するために、パーソナライズされたデジタルプラットフォームを利用するか、又は他の形でそれから利益を得てもよいことが企図される。各々のユーザは、パーソナライズされたデジタルプラットフォームにそのユーザが加入する（例えば分析サーバ１２０によって管理されるアプリケーション１１４を介して）ために使用してもよいユーザデバイス（例えばユーザデバイス１０２）に関連付けられていてもよい。よって、方法３００を参照すると、分析サーバは、各々のユーザについて、対応するユーザプロファイルを受信してもよい（ブロック３０２）。例えば、パーソナライズされたデジタルプラットフォームに加入する（例えば、ユーザの前糖尿病リスク又は症状を評価及び監視するという利益を享受する）ための条件として、ユーザは、ユーザ及び／又はユーザデバイスの識別情報（例えばユーザ名、ユーザデバイス番号、年齢、体重、性別など）などのユーザに属する予備情報を、ユーザデバイス１０２上のアプリケーション１１４を介して提出するように促されてもよい。アプリケーション１１４は、分析サーバ１２０のＡＰＩ１３４によって生成されてホスティングされてもよく、このアプリケーションはユーザにとって、それぞれのユーザデバイスを介してアクセス可能であってもよい。アプリケーションは、ウェブブラウザ対応であってもよく、かつ／又はモバイルプラットフォーム上でアクセス可能なモバイルアプリケーションを含んでもよい。更に、分析サーバはアプリケーションと相互作用するユーザデバイスを追跡（例えば、デバイス識別子を記憶することによって）してもよく、同じデバイスがアプリケーションに戻ってきたときを認識してもよい。よって、分析サーバ１２０はブロック３０２で、ユーザに属するそのような予備情報を受信してもよい。予備情報を使用して、そのユーザのユーザプロファイルを作成することができる。ユーザプロファイルは分析サーバ１３２のユーザデータベース１３４内に記憶装置を備えてもよく、そこではユーザに関する追加情報（例えば、ユーザ属性、前糖尿病リスクレベルなど）がデータ構造内に記憶されてもよい。
【0033】
[0041]例えば、分析サーバは所与のユーザについて、ユーザプロファイルに基づくデータ構造を生成してもよい（ブロック３０４）。次いで、分析サーバは、データ構造へのユーザ属性の入力を促してもよい（ブロック３０６）。本明細書で使用するとき、ユーザ属性は、ユーザに関する人物情報詳細（例えば、ユーザ識別子、性別、体重、身長など）、ユーザの健康に関する情報（例えば活動レベル、併存症、健康目標など）、食のニーズ及び嗜好、並びに生理学的データ（例えば血糖値）を含んでもよい。いくつかの態様では、ユーザ属性を入力するようにユーザに促すことは、バイオセンサ及び／又はウェアラブルデバイス（例えばバイオセンサ／ウェアラブル１１９）に接続して生理学的データ（例えば血糖値）を入力するようにユーザに促すことを含んでもよい。更に又は代替的に、ユーザ属性の入力は、画像、音声、及び／又はビデオアップロードを介してもよい。例えば、患者データシートをスキャンしてアプリケーション１１４にアップロードしてもよく、自然言語プロセッサ１２６は、併存症、基礎疾患、及び人物情報詳細に属するユーザ属性を解析して認識してもよい。ユーザプロファイルを完成させるために使用する予備情報には、１つ以上のユーザ属性（例えば年齢、体重、身長、性別など）が含まれてもよい。
【0034】
[0042]更に、ユーザ属性は、前糖尿病又は糖尿病のリスク及び症状を評価するための標準的な質問票への回答に基づいてもよい。例えば、そのような質問票としては、フィンランド糖尿病リスクスコア（ＦＩＮＤＲＩＳＣ）、修正アジアＦＩＮＤＲＩＳＣ（ＭｏｄＡｓｉａｎ ＦＩＮＤＲＩＳＣ）、Ａｍｅｒｉｃａｎ Ｄｉａｂｅｔｅｓ Ａｓｓｏｃｉａｔｉｏｎが提供する質問票（例えば「Ｃｏｕｌｄ Ｙｏｕ Ｈａｖｅ Ｄｉａｂｅｔｅｓ？ Ｔａｋｅ Ｔｈｅ Ｒｉｓｋ Ｔｅｓｔ」）、Ｄｉａｂｅｔｅｓ ＵＫが提供する質問表（例えば「Ｃｈｅｑｕｅ Ｆｏｒ Ｔｅｃｈ」）などがある。
【0035】
[0043]ユーザによる入力のいくつかはプロンプト（例えば質問）に十分に応答していないこと、又は、追跡プロンプトを発生させることがあることが企図される。そのような状況が原因となって、分析サーバは、ユーザデバイスを介したユーザの入力を評価して（ブロック３０８）、あるデータ構造を更新する必要があるか（例えば、回答の補遺又は訂正のために）、又は新しいデータ構造を作成する必要があるか（例えば、追跡プロンプトへの回答のために）を判定する（ブロック３１０）。入力がプロンプトに十分に応答しない場合、又は追跡プロンプト（例えば質問）の動機となる場合、分析サーバは、ユーザが訂正するため、又は新しいプロンプトに応答するために、データ構造を更新してもよく、かつ／又は新しいデータ構造を作成してもよい（ブロック３１２）。よって、ユーザは、更新又は作成されたデータ構造にユーザ属性を入力するように再び促されてもよい（ブロック３０６）。
【0036】
[0044]ユーザ属性を入力するためのいずれかのプロンプトに対する回答が完了したとみなされると、分析サーバは、ユーザ特有の食物摂取量選択肢を生成してもよい（ブロック３１４）。例えば、分析サーバはユーザ属性として、食嗜好若しくは食物アレルギー、共存症、予備情報（例えば年齢、体重、身長、性別など）、又は生理学的データ（例えば血糖値）があれば、それらを入力するようにユーザを促してもよい。そのようなユーザ属性を使用して、ユーザの毎日の栄養素及びカロリー要件を判定し（例えば、体格指数の計算に基づいて）、食物アレルギーに関連付けられた食事があれば除外し、ユーザの食嗜好に基づいて食物摂取選択肢のリストを生成してもよい。食品の選択肢には、栄養及びグリセミック指数の情報が知られている、周知の食料製品、レシピ、及び／又は食事のリストが含まれてもよい。いくつかの態様では、ユーザ属性を使用して、個々の栄養素及び／又はカロリーについての要件を、食品群レベルの規則に基づいて判定してもよい。例えば、ある食品群（例えば野菜）は、他の食品群（例えば菓子）よりも多くのカロリー要件を有し得る。後述するように、生成されたユーザ特有の食物摂取量選択肢は、後続のステップにおいて、ユーザの前糖尿病リスクレベルに基づいて更にフィルタリングされてもよい。
【0037】
[0045]例えば分析サーバは、所与のユーザのユーザ特有の食物摂取量選択肢の各々の、栄養素、カロリー、及びグリセミック負荷を判定してもよい（ブロック３１６）。前述したように、所与の食物摂取量選択肢のグリセミック負荷を判定する改善された方法が開示され、これにより、前糖尿病のリスク及び症状をより正確に信頼性をもって監視できるようになる。図５及び図６は、グリセミック負荷を判定する改善された方法の少なくとも１つの実施形態をより詳細に説明する。栄養素及びカロリー情報は、食料製品データベース１３６から取り込まれ、かつ／又は他の方法で計算されてもよい。図８に関連して更に説明するように、栄養素は、炭水化物、タンパク質、脂肪（例えば飽和脂肪、不飽和脂肪など）、繊維、及びナトリウムを含んでもよいが、それらに限定されない。
【0038】
[0046]所与のユーザを前糖尿病リスクレベルに基づいて分類するために、分析サーバが他のユーザのユーザ属性を得ることは有用であり得る。よって、ブロック３１８で、分析サーバは、ユーザ属性を受信できる追加のユーザを分析サーバが特定したか判定してもよい。追加のユーザが存在する場合、例えば後続のステップで前糖尿病リスククラスタを決定するために、ユーザ属性の１つのセットが受信されるまで、追加のユーザの各々についてブロック３０４～３１６を繰り返してもよい。ユーザ属性の受信が済んでいない追加のユーザが存在しない場合、又は複数のユーザから受信された十分なデータが存在する場合、分析サーバは、様々なユーザの入力されたユーザ属性を定量化可能なデータに変換する（例えば各々のユーザのユーザ属性をベクトル化する）ことに進む（ブロック３２０）。例えば、ｎ人のユーザが回答を入力したｍ個のユーザ属性の共通セット（例えば年齢、体重、身長、血糖値）が、ｎ個のｍ次元特徴ベクトルとして配列されてもよい。個々の回答は、各々の特徴ベクトル内で数値に変換されてもよい。
【0039】
[0047]分析サーバは、特徴ベクトルからクラスタを特定してもよく、クラスタは前糖尿病リスクレベルを意味する（ブロック３２２）。次いで、教師なしクラスタリング手順（例えば ｋ－ｍｅａｎｓクラスタリング）又は教師あり機械学習モデル（例えば多次元分類）を使用して、複数の特徴ベクトルの中でクラスタを特定することができる。図４は、ブロック３２０及び３２２の少なくともいくつかの実施形態をより詳細に説明する。ブロック３２２でこのように形成及び／又は特定されたクラスタを、ある前糖尿病リスクレベルに従って各々のユーザを分類するために使用してもよい。少なくとも１つの実施形態において、各々のクラスタは唯一の前糖尿病リスクレベルに対応してもよい。形成すべきクラスタの数は予め定められていてもよく、また、クラスタの数は、所望の推奨食物摂取量の特異度に応じて変化してもよい。例えば一実施形態では、１つのクラスタは、糖尿病を発症するリスクが高度から中程度であるユーザを含んでもよく（例えば計画Ａ）、別のクラスタは、糖尿病を発症するリスクが高度から非常に高度であるユーザを含んでもよい（例えば計画Ｂ）。本明細書で更に説明されるように、図９は、３クラスタ（例えば、低リスク、軽度から中程度のリスク、及び高度から非常に高度のリスク）の実施形態例を、各々のクラスタのカロリー制限例、グリセミック負荷要件、及び推奨食物摂取量と共に示す。
【0040】
[0048]ブロック３２３で、分析サーバは、各々の前糖尿病リスクレベルに関連付けられたグリセミック負荷、個々の栄養素、及びカロリーについての閾値要件を特定してもよい。所与の前糖尿病リスクレベルに関連付けられたグリセミック負荷、栄養素、及びカロリーの閾値要件は、その所与の前糖尿病リスクレベルに属するユーザの所与の食事の、それぞれグリセミック負荷、栄養素、及びカロリーの推奨範囲であってもよい。いくつかの態様では、各々の食事（例えば朝食、昼食、夕食、間食）は、異なるグリセミック負荷、栄養素、及び／又はカロリーの閾値要件を有してもよい。本明細書で更に説明されるように、図９は、３つの異なる前糖尿病リスクレベルに関連付けられたグリセミック負荷、栄養素、及びカロリーに対する閾値要件の例を示す。
【0041】
[0049]ブロック３２４で、分析サーバは、ユーザの前糖尿病リスクレベルに基づいてユーザ特有の食物摂取量選択肢をフィルタリングしてもよい。例えば分析サーバは、各々の前糖尿病リスクレベルに関連付けられたグリセミック負荷、栄養素、及びカロリーの閾値要件を使用してもよい。次いで、分析サーバは各々のユーザについて、ユーザの前糖尿病リスクレベルに関連付けられたグリセミック負荷、栄養素、及び／又はカロリーの閾値要件を満たさないユーザ特有の食物摂取量選択肢を除外するために、ユーザ特有の食物摂取量選択肢（ブロック３１４から）、並びに各々のユーザ特有の食物摂取量選択肢のグリセミック負荷、栄養素、及びカロリー（３１６から）を特定してもよい。フィルタリング後に得られるユーザ特有の食物摂取量選択肢は、ユーザの推奨食物摂取量を含み得る。
【0042】
[0050]ブロック３２６で、分析サーバは、そのユーザのための推奨食物摂取量を、そのユーザに関連付けられたユーザデバイスに出力してもよい。例えば、ユーザはユーザデバイス１０２のアプリケーション１１４上で、例えば次の食事（例えば朝食、昼食、夕食など）のための食事の選択肢の提案について推奨を閲覧することが可能であってもよい。少なくとも１つの実施形態では、分析サーバは、ユーザの食嗜好及び過敏症に基づいて、カスタマイズされたレシピを用いて毎週（例えば７日間）の食事計画を作成してもよい。例えば、レシピがＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢなどのデータベースから供給されてもよく、レシピの個々の食品成分に関する情報が食料製品データベース１３６から取得されてもよく、次いで、前糖尿病リスククラスタ及びユーザに関連するユーザ属性に基づいてレシピがフィルタリングされてもよい。いくつかの態様では、分析サーバはまた、推奨食物摂取量以外にも推奨を含んでもよい。例えば健康計画は、運動の提案を含んでもよい。
【0043】
[0051]更に、分析サーバは、後にユーザの健康を監視してもよい（ブロック３２８）。例えば、分析サーバは、ユーザが摂取する食事の説明（例えば、分析サーバによって推奨される食物摂取量でない場合）を入力するように（例えば、アプリ１１４を介して送信される通知によって）ユーザに促してもよい。分析サーバは、摂取された食事のグリセミック負荷を判定してもよく、次いで、それが、ユーザの前糖尿病リスクレベルに関連付けられた標的グリセミック負荷又は閾値グリセミック負荷内であるか判定してもよい。更に、又は代替的に、分析サーバは、推奨された食物摂取量が経時的にユーザの前糖尿病症状を改善するのに役立つか追跡するために、バイオセンサ又はウェアラブルデバイスを介して血糖値を提供するようにユーザに定期的に促してもよい。
【0044】
[0052]図４は、本開示の例示的な実施形態による、前糖尿病リスクレベルに基づいてユーザをクラスタリングする方法例４００のフロー図である。方法４００は、分析サーバ１２０の１つ以上のプロセッサによって行われてもよい。前述したように、方法４００は、図３のブロック３２０及び３２２の少なくとも１つの実施形態を示す。更に、図３のブロック３０６に関連して説明したように、分析サーバは、パーソナライズされたデジタルプラットフォームのユーザに、前糖尿病リスクを評価して食物摂取量選択肢を推奨するために有用であり得る様々な質問に対する回答を入力するように促してもよい。これらの回答は、各々のユーザについてユーザ属性として記憶されてもよい。
【0045】
[0053]よって、図４を参照すると、分析サーバは各々のユーザについて、ユーザ属性の入力を受け取ってもよい（ブロック４０２）。入力は、各々のユーザのユーザプロファイルに関連付けられたデータ構造内に記憶されてもよい。前糖尿病リスクレベルのクラスタ又はクラスを決定する目的のために、図４で論じたように、ユーザが各々で入力を有し得る、共通ユーザ属性（例えば年齢、体重、身長、血糖値など）のセットが存在してもよい。
【0046】
[0054]次いで、分析サーバは、各々のユーザについて入力をベクトル化して特徴ベクトルとしてもよい（ブロック４０４）。いくつかの態様では、入力のベクトル化とは、様々なユーザのユーザ属性について入力された入力を定量化可能なデータに変換することを指してもよい。各々のユーザについてこのように形成された特徴ベクトルは、各々のユーザ属性の定量化可能なデータを含んでもよい。例えば、ｎ人のユーザが回答を入力したｍ個のユーザ属性の共通セット（例えば年齢、体重、身長、血糖値）が、ｎ個のｍ次元特徴ベクトルとして配列されてもよい。個々の回答は、各々の特徴ベクトル内で数値に変換されてもよい。
【0047】
[0055]分析サーバは、特定すべきクラスタの個数ｋを決定してもよい（ブロック４０６）。クラスタは、例えば多次元グラフにプロットされたときの互いの距離に起因して、グループとして自然に形成されるデータ点（例えば特徴ベクトル）のグループを指してもよい。各々のクラスタは、ある前糖尿病リスクレベルを意味してもよい。特定すべきクラスタの個数は、パーソナライズされたデジタルプラットフォームのユーザ又はオペレータが、ユーザの前糖尿病を評価するために、どれだけの層別化を望むかに基づいてもよい。
【0048】
[0056]特定すべきクラスタの個数ｋを決定した後、分析サーバは、それぞれがそれぞれのクラスタを表すｋ個の特徴ベクトルを選択してもよい（ブロック４０８）。そのような選択された特徴ベクトルは、重心と呼ばれてもよい。そのような選択は、恣意的、かつ／又は無作為であってもよい。クラスタの範囲及び構成は本明細書に提示される方法に基づいて決定すべきではあるが、例えば、特定すべきクラスタの個数ｋが３である場合、特徴ベクトルｆ１がクラスタｋ１を表してもよく、特徴ベクトルｆ２がクラスタｋ２を表してもよく、特徴ベクトルｆ３がクラスタｋ３を表してもよい。特定される各々のクラスタが重心を含めて少なくとも２つ以上の特徴ベクトルを有し得るように、特徴ベクトル（例えばデータ点）の総数は少なくともｋよりも大きいことが企図される。分析サーバは、各々の特徴ベクトル（例えば、各々のクラスタを表すために選択された特徴ベクトル）の、重心からの平均距離を計算してもよい（ブロック４１０）。特徴ベクトルまでの距離が計算される重心は、特徴ベクトルに最も近い重心であってもよい。平均は、それぞれの重心からの各々の特徴ベクトルの距離の平均値又は中央値を含んでもよい。
【0049】
[0057]平均距離の計算値を評価して、それが最小平均距離であるか判定してもよい（ブロック４１２）。例えば、ブロック４１０と４１２との１回の繰り返しの平均距離の計算値を、ブロック４１０と４１２との以前の繰り返しの平均距離の計算値と比較して、新しい最小平均距離が見つかったか判定してもよい。最小平均距離が見つかるまでは、特定すべきｋ個のクラスタを表す重心として、特徴ベクトルの別のセットが選択されていてもよい（ブロック４１４）。このように、各々の特徴ベクトルとそれぞれの重心との間の平均距離を最小化する重心のセットが見つかるまで、ブロック４１０、４１２、及び４１４を繰り返してもよい。それが見つかった後、ｋ個のクラスタが、最小平均距離をもたらす重心のセットに基づいて特定される（ブロック４１６）。よって、各々の重心及びそれに最も近いそれぞれの特徴ベクトルが、ひとつのクラスタを形成してもよい。更に、各々のクラスタは、ある前糖尿病リスクレベルを表してもよい。各々のクラスタについて、各々のユーザを表す（例えば、各々のユーザのユーザ属性のベクトル化を介して）特徴ベクトルは、そのクラスタに関連付けられた前糖尿病リスクレベルにユーザをリンクしてもよい。よって、分析サーバは、各々のユーザの前糖尿病リスクレベルを、そのユーザに関連付けられた特徴ベクトルのクラスタに基づいて出力してもよい（ブロック４１８）。本明細書で論じるように、そのユーザの前糖尿病リスクレベルは、そのユーザのための食物摂取量を、例えばその前糖尿病リスクレベルに関連付けられたグリセミック負荷又は他の要件閾値があればそれを判定することによって、推奨するための関連情報を提供し得る。
【0050】
[0058]図５は、本開示の例示的な実施形態による、前糖尿病のリスクを監視し、前糖尿病のための推奨食物摂取量を提供するための食物摂取量選択肢の、グリセミック指数を判定する方法例のフロー図を示す。方法５００は、分析サーバ１２０の１つ以上のプロセッサによって行われてもよい。更に、方法５００は、図３のブロック３１６の少なくともいくつかの実施形態を説明してもよい。
【0051】
[0059]方法５００は、ある食料製品を特定することから開始してもよい（ブロック５０２）。例えば、その食料製品は、グリセミック負荷を計算する（例えば図３のブロック３１６から）対象の食物摂取量選択肢に含まれてもよい。更に又は代替的に、その食料製品は、パーソナライズされたデジタルプラットフォームのユーザによって、そのユーザが摂取しているか、摂取しようと意図しているとして特定されてもよい。例えば、ユーザは、ユーザデバイス１０２上のアプリ１１４を介して、その食料製品の識別子又はその食料製品に関する詳細を入力してもよい。
【0052】
[0060]分析サーバは、その食料製品の栄養素情報が入手可能であるか判定してもよい。例えば、分析サーバ１２０は、その食料製品（例えば食料製品２０２）について食料製品データベース１３６及び２００に問い合わせて、記憶された栄養素情報２０６があるか確認（例えば、記憶された食品成分２０４に基づいて）してもよい。栄養素情報が記憶されていない場合、分析サーバは、特定可能な食品成分があるか判定してもよい。例えば、分析サーバは食料製品データベース１３６及び２００に問い合わせて、その食料製品のもとに列挙された食料製品成分（例えば、その食料製品の原材料）があるか確認してもよい。特定可能な食品成分がない（例えば、食料製品データベース１３６及び２００に何も記憶されていない）場合、分析サーバ１２０は、特定された食料製品（例えば、ピーナッツバターとジャムのサンドウィッチ）が何から作られているかを特定するようにユーザに促してもよい（ブロック５０８）。ユーザは、食品成分（例えば、２個の全粒小麦パン、小匙１杯のピーナッツバター、及び小匙１杯のイチゴゼリー）を、ユーザデバイス１０２上のアプリ１１４を介して入力してもよい。食料製品成分に関する情報が食料製品データベース１３６内で見つかった場合、又はユーザが食料製品成分に関する情報を提供した後、分析サーバは、その食料製品成分に関する栄養素情報が食料製品データベース内で見つかるか判定してもよい（ブロック５１０）。例えば、分析サーバ１２０は、各々の個別の食料製品成分（例えば、全粒小麦パン、ピーナッツバター、イチゴゼリー）について食料製品データベース１３６及び２００に問い合わせて、各々の食料製品成分に関連付けられた栄養素情報を取り込んでもよい。いくつかの態様では、各々の食料製品成分は、他の食料製品に関連付けられたデータ構造のもとに記憶されていることもある。そのような態様では、分析サーバ１２０は、ブロック５０２で特定した食料製品に関連付けられたデータ構造を更新して、食料製品成分の追加のデータフィールドを記入してもよい。栄養素には、脂肪、タンパク質、水、ビタミン、ミネラル、複合炭水化物（例えば血糖多糖類）、単純炭水化物（単糖類、二糖類など）が含まれ得るが、これらに限定されない。栄養素情報が見つからない場合、分析サーバは、様々な食料製品成分についての栄養素情報を入力するようにユーザに促してもよい（ブロック５１２）。ユーザは各々の食料製品成分についての栄養情報を、ユーザデバイス１０２のアプリ１１４を介して入力してもよい。いくつかの態様では、栄養素は、例えば、炭水化物、タンパク質、脂肪、飽和脂肪、繊維、及びナトリウムを含んでもよい。そのような態様では、そのような栄養素の定期的な（例えば毎日、毎週などの）推奨摂取量がユーザに提供されてもよい（例えば、ユーザに関連付けられた前糖尿病リスクレベルに基づいて）。
【0053】
[0061]その食料製品又は、その食料製品を構成する様々な食料製品成分についての栄養素情報を（例えば食料製品データベースから）取り込む、又は（例えばユーザデバイス１０２から）受信すると、分析サーバは、食料製品のグリセミック負荷を判定するために特定の栄養素の分析を開始してもよい。例えば分析サーバは、その食料製品が単糖類又は二糖類を有するか判定してもよい（ブロック５１４）。存在する場合、分析サーバは、単糖類又は二糖類の相対量に基づいてグリセミック指数を判定してもよい（ブロック５１６）。本明細書で論じるように、図６（例えばブロック６０２を介して）は、グリセミック指数をどのように判定するかの例をより詳細に示す。
【0054】
[0062]その後、又は単糖類若しくは二糖類が存在しない場合、分析サーバは、食料製品が血糖多糖類を有するか判定してもよい（ブロック５１８）。存在する場合、分析サーバは、血糖多糖類の相対量に基づいてグリセミック指数を判定してもよい（ブロック５２０）。例えば、特定タイプの血糖多糖類を特定して、図６のブロック６０４に示す参照表からグリセミック指数を取り込んでもよく、それを食料製品データベース１３６及び２００に記憶してもよい。更に、各々の血糖多糖類に基づく補正係数ａｉを適用してもよい（ブロック５２２）。本明細書で論じるように、図６（例えばブロック６０４）は、様々な知られている血糖炭水化物の補正係数ａｉを列挙する。
【0055】
[0063]その後、又は血糖多糖類が存在しない場合、分析サーバは、食料製品が非血糖栄養素を有するか判定してもよい（ブロック５２４）。このような非血糖栄養素として、β－グルカン、繊維、脂肪、タンパク質、灰分、及び水が挙げられるが、これらに限定されない。存在する場合、分析サーバは、グリセミック指数の判定において、各々の非グリセミック栄養素に関連付けられたＧＩ低下力ｂｉを適用してもよい（ブロック５２６）。例えば、特定のタイプの非グリセミック栄養素を図６のブロック６０６から特定して、図６のブロック６０２に示す方法に基づいてグリセミック指数を計算してもよい。本明細書で論じるように、図６（例えばブロック６０６）は、様々な知られている非血糖栄養素のＧＩ低下力ｂｉを列挙する。
【0056】
[0064]栄養素及びそれぞれの補正係数ａｉ、並びにＧＩ低下力ｂｉを特定すると、分析サーバは、予測したグリセミック指数から食料製品のグリセミック負荷を生成してもよい（ブロック５２８）。例えば、分析サーバは、図６のブロック６０２に示される式を利用してグリセミック負荷を計算してもよい。
【0057】
[0065]図６は、本開示の例示的な実施形態による、食物摂取量選択肢のグリセミック指数を判定する方法例に適用すべき栄養素の補正係数の例を示す表である。例えば、ブロック６０２は、様々な栄養素ｘｉのグリセミック指数ＧＩｉの総和に基づいてグリセミック負荷を判定する例示的な方法を示す。前述したように、血糖炭水化物などの栄養素には補正係数ａｉを適用してもよい。この総和を、それらの栄養素の総計にＧＩ低下栄養素ｘｊ及びそれらのそれぞれのＧＩ低下力ｂｊの総計を加えたもので除算してもよい。
【0058】
[0066]ブロック６０４は、様々な血糖炭水化物及び単純炭水化物の例を列挙した表である。例えば、血糖多糖類には血糖多糖類が含まれ、単純炭水化物には単糖類、二糖類、及び糖アルコールが含まれる。これらの炭水化物についても、グリセミック指数ＧＩｉが補正係数ａｉと共に列挙されている。
【0059】
[0067]ブロック６０６は、様々なＧＩ低下栄養素の例を列挙した表である。例えば、そのようなＧＩ低下栄養素には、βグルカンなどの炭水化物、繊維、脂肪、タンパク質、灰分、及び水が含まれる。それぞれの栄養素について、ＧＩ低下力ｂｉも列挙されている。
【0060】
[0068]更に、少なくとも１つの実施形態において、グリセミック負荷及びグリセミック指数を判定するための方法は、更に簡略化されてもよい。簡略化された方法では、スクロース６０８、デンプン６１０、繊維６１２、脂肪６１４、及びタンパク質６１６、の５つのパラメータを利用してもよい。この５つのパラメータの栄養情報は比較的容易にアクセスでき得るので、この簡略化された方法では、より多くの種類の食料製品を、グリセミック指数及び／又はグリセミック負荷について、より効率的に評価できるようになる。いくつかの態様では、他の栄養素は、補正係数ａｉ又はＧＩ低下力ｂｉの類似点又は類似性に基づいて、５つのパラメータのうち１つ以上にリンクされるか、他の方法でそれらの中に含められてもよい。
【0061】
[0069]図７は、本開示の例示的な実施形態による、前糖尿病のための推奨食物摂取量を適用する方法例７００のフロー図である。方法７００は、分析サーバ１２０の１つ以上のプロセッサによって行われてもよい。更に、方法７００は、例えば推奨食物摂取量がレシピに基づく食事計画の形態で提供される、図３のブロック３２４及び３２６の少なくともいくつかの実施形態を説明する。更に、方法７００は、図１に関連して前述したように、ＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢ１６０などの内部又は外部のレシピデータベースを利用してもよい。
【0062】
[0070]図７を参照すると、方法７００は、ユーザに関連付けられたユーザ属性に基づいて、レシピデータベース（例えばＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢ１６０）内のレシピをフィルタリングすることから開始してもよい（ブロック７０２）。ユーザ属性は、ユーザに関連付けられたユーザデバイス１０２から分析サーバ１２０によって受信された（例えばブロック３０４～３１４で）ものであってもよく、レシピデータベースからのレシピの予備的フィルタリングを行うために使用されてもよい。ユーザ属性は、例えば、食嗜好及び過敏症（例えば、豚肉を含まない、牛肉を含まない、魚菜食、ラクトースを含まない、卵を含まないなど）、並びにアレルギー（例えば、ナッツ、魚、貝、大豆、グルテンなど）を含んでもよい。
【0063】
[0071]レシピは、それらのカロリー及びグリセミック負荷の含有量によって更に特定され、かつ／又はフィルタリングされてもよい（ブロック７０４）。例えば、各々のレシピは、ある食料製品及び１つ以上の食料製品成分に関連付けられており得る。そのレシピに関連付けられた何らかの栄養情報（例えば、グリセミック負荷及びグリセミック指数）がレシピデータベースにまだ提供されていない場合、前述し、図５に示した方法５００を使用して、その情報を特定して記憶してもよい。いくつかの態様では、カロリー及びグリセミック負荷の含有量に基づいてレシピの予備的フィルタリングが行われてもよい（例えば、ユーザの前糖尿病リスクレベルに基づくフィルタリングの前に）。例えば、１食あたりのカロリー含有量が８００ｋｃａｌを超え、１食あたりのＧＬが２０を超えるレシピをフィルタリングしてもよい。
【0064】
[0072]ブロック７０６で、分析サーバは、いずれかの推奨食物摂取量をレシピに変換してもよい。例えば、分析サーバは、あるユーザの前糖尿病リスクレベルに基づいて推奨食物摂取量を生成しており、またその推奨食物摂取量はカロリー摂取及びグリセミック負荷の範囲を規定しており、レシピを更にフィルタリングするために、その範囲が使用されてもよい。
【0065】
[0073]更に、ユーザに提供されるいずれかの特定の推奨食物摂取量について、例えば後続のブロック７１０～７１６のために、食事又は摂食機会（例えば朝食、昼食、夕食、間食など）が特定されてもよい（ブロック７０８）。あるユーザが、ある期間（例えば１日、１週間など）の食事のための推奨食物摂取量を受信することを選択した場合、分析サーバは、その期間を構成する食事又は摂食機会の各々について後続のステップを行ってもよい。
【0066】
[0074]特定された各々の食事又は摂食機会について、最小及び最大カロリー量、最大グリセミック負荷、及び１食あたりの最小繊維量が定められてもよい（ブロック７１０）。食事は個々の食料製品の複数のレシピに基づくことがあるので、ある食事又は摂食機会の全体について規定されるカロリー範囲は、個々のレシピで許容されるカロリー範囲よりも厳密であってもよい。更に、分析サーバは、例えば、適切なら随時、又は必要に応じて、あるレシピが食事に占める割合（例えば半分）を推奨することによって、使用するレシピの数を最大化することを選択してもよい。よって、特定された各々の食事又は摂食機会について、食事を構成する個々の食料製品のレシピを集約してもよい（例えば、適切な割合で）（ブロック７１２）。
【0067】
[0075]いくつかの態様では、集約された組み合わせが確実に、個々の栄養素及び／又はカロリーの毎日の要件を満たし、個々の栄養素及び／又はカロリーの食事レベル要件を満たすように、チェックが行われてもよい。いくつかの態様では、そのような要件が前糖尿病リスクレベルに結び付けられてもよい。図８及び９に、毎日の、及び食事の栄養要件の例を示し、本明細書で更に説明する。
【0068】
[0076]最終的な食事計画が、ユーザに関連付けられたユーザデバイスに出力されてもよい（ブロック７１４）。例えば、ユーザは、そのユーザの食嗜好及び過敏症に基づいて各々の食事のためにカスタマイズされたレシピを有する、１週間（例えば７日間）の食事計画を受信してもよい。いくつかの態様では、分析サーバは、食事及び／又は食事計画に関するフィードバックを提供するようにユーザに促してもよく（例えばユーザデバイス１０２のアプリ１１４を介して）、フィードバックを受信してもよい（ブロック７１６）。分析サーバは、フィードバックを使用して、食事計画内の今後の食事を修正及び／又は置換してもよく、又はいずれかの食料製品成分若しくはそれらの量を変更してもよい。
【0069】
[0077]図８は、非限定的な実施形態例による、栄養素、カロリー、及びグリセミック負荷についての毎日の要件の例を示す表である。いくつかの態様では、毎日のカロリー要件８０２は、ハリスベネディクトの式を介して（例えば、基礎代謝率（ＢＭＲ）に基づいて）決定されてもよい。図示した例では、毎日のカロリー要件８０２には、カロリー削減の推奨（例えば、過体重の人は５００ｋｃａｌ削減／日、肥満の人は１０００ｋｃａｌ削減／日）が更に示され得る。表に示されるように、個々の栄養素及びそれらの毎日の摂取要件は、例えば、炭水化物８０４（例えば４５～６０％ＴＥＩ(Total Energy Intake)）、タンパク質８０６（例えば１５～２０％ＴＥＩ）、脂肪８０８（例えば２５～３５％ＴＥＩ）、飽和脂肪８１０（例えば＜７％ＴＥＩ）、繊維８１２（例えば２０～３０ｇ（例えば１４ｇ／１０００ｋｃａｌ））、ナトリウム８１４（例えば＜２４００ｍｇ）を含んでもよい。グリセミック負荷８１６の毎日の要件も示されている（例えば８５／１０００ｋｃａｌ）。いくつかの態様では、推奨食物摂取量が生成されると、分析サーバは、毎日の要件が確実に満たされるように、１日の個々の食事の推奨食物摂取量を比較してもよい。毎日の要件は、分析サーバ１２０のメモリ１３２に記憶されたデータ構造を含んでもよく、更新可能であってもよい。
【0070】
[0078]いくつかの態様では、図８に示されるものなどの、カロリー、個々の栄養素、及びグリセミック負荷についての毎日の、及び食事時の要件（「栄養規則」）は、複数の団体の栄養ガイドライン（例えば、Ｔｈｅ Ａｍｅｒｉｃａｎ Ｄｉａｂｅｔｅｓ Ａｓｓｏｃｉａｔｉｏｎ、Ｃａｎａｄｉａｎ Ｄｉａｂｅｔｅｓ Ａｓｓｏｃｉａｔｉｏｎ（例えば、特に南アジアに背景を有する人々のためのガイドラインを含む）、Ｄｉａｂｅｔｅｓ ＵＫ、日本糖尿病学会、Ｎａｔｉｏｎａｌ Ｄｉａｂｅｔｅｓ Ｉｎｓｔｉｔｕｔｅ（マレーシア））からの抜粋情報を統合することによって生成されてもよい。いくつかの態様では、栄養規則は、目標母集団に基づいて修正されてもよい。ガイドラインの抜粋、フィルタリング、及び合成からこのように形成された栄養規則の例を、より詳細に付録で説明する。付録に示すように、栄養規則は、主要栄養素、カロリー含有量、グリセミック指数及び／又は負荷、糖尿病に好都合な食事パターン、繊維摂取量、炭水化物摂取量、タンパク質摂取量、脂肪摂取量、食事推奨（例えば、特定の食品群（例えば、果物、葉菜類、ヨーグルト及びチーズなど）に基づく推奨を含む）、栄養補助食品摂取量、塩分摂取量（例えばナトリウム）、アルコール摂取量、甘味料摂取量、及び飲料摂取量についての毎日のガイドラインを含む。
【0071】
[0079]一実施形態では、これらのガイドラインの統合からこのように形成された栄養規則は、１日あたり少なくとも４００ｇの果物及び野菜（例えば、ジャガイモ及び他のデンプン質根菜作物を除くが、豆果（例えば豆、レンズ豆）、全粒穀物及びナッツを含む）を食べることの推奨；不飽和脂肪の摂取を飽和脂肪に優先し、トランス脂肪を禁止して、脂肪の摂取を制限する（例えば総カロリーの３０％未満として）ことの推奨；単糖の摂取を総カロリーの１０％未満（例えば１日あたり２５グラム未満又はカロリーの５％未満）に制限する推奨；すべての供給源からのナトリウム及び塩を制限（例えば１日あたり５ｇ未満の塩）し、塩を確実にヨード化することの推奨；及び、身体が使用しているカロリーとほぼ同じカロリー数を摂取することによって健康な体重を維持することの推奨、を含んでもよい。
【0072】
[0080]図９は、本開示の例示的な実施形態による、前糖尿病リスククラスタに基づく食事計画の生成を示す図である。前糖尿病リスククラスタは、ユーザから取得したユーザ属性に基づいて形成されてもよい。そのようなユーザ属性は例えば、前糖尿病リスクを評価するための質問票への回答を通して取得されてもよい（例えばブロック９０２に示すように）。ユーザ属性を使用して、ユーザを複数のクラスタ（例えば、低リスク９０６、軽度から中程度のリスク９０８、高度から非常に高度なリスク９１０など）のうち１つに属するとして分類してもよい。いくつかの態様では、分類はスコアの生成に基づいてもよい。スコアは、前述の方法によるユーザ属性のベクトル化に基づいてもよい。各々の前糖尿病リスククラスタに基づいて、暫定的な推奨食物摂取量を生成してもよい。更に、そのような推奨を、食嗜好、併存症、食物アレルギー、及び／又は食品制限に基づいてフィルタリングしてもよい。更に、暫定的な推奨食物摂取量を、定期的な（例えば、摂食機会、毎日、毎週などの）食物摂取を管理する栄養規則と更に比較してもよい。栄養規則は、前述したように、図８に示されるものなどの、個々の栄養素、カロリー、又はグリセミック負荷の摂取のための閾値要件に関するガイドラインを含み得る。暫定的な推奨食物摂取量を、栄養規則との比較に基づいて更にフィルタリングしてもよい。
【0073】
[0081]各々のユーザについて、食事計画（例えば推奨食物摂取量）を、ユーザに関連付けられた前糖尿病リスククラスタに基づいて生成してもよい。ただし、食事計画はまた、栄養規則９０４、ユーザの食嗜好、ユーザの併存症、ユーザの食品アレルギー、及び／又はユーザの食品制限に従ってもよく、かつ／又はそれらに基づいて更にカスタマイズされてもよい。例えば、低リスククラスタ９０６に属するユーザは、低リスクの前糖尿病に適したヒント及び食料製品の推奨を受信してもよい（例えばブロック９１２）。例えば、ユーザは、より前糖尿病リスクの高いクラスタのものほど制限的でなくてもよい健康的な摂食のヒント及び食料製品の推奨を受信してもよい（例えば、ユーザデバイス１０２上のアプリ１１４を介して、及び分析サーバ１２０のＡＰＩ１３８から）。ユーザは、高品質の食生活を促進するために、食料製品データベース１３６又はレシピリポジトリ（例えばＳＭＡＲＴ ＲＥＣＩＰＥ ＨＵＢ１６０）を活用するように促進されてもよい。
【0074】
[0082]軽度から中程度のリスククラスタ９０８に属するユーザは、その前糖尿病リスクレベルに適した食事計画（例えば食事計画Ａ）を受信してもよい（例えばブロック９１４に示すように）。分析サーバは、ユーザデバイス１０２を介してユーザに、健康的な食事計画、カロリー制限、低グリセミック負荷、及び食事代替製品を推奨してもよい。カロリー制限は、２３～２７の体格指数（ＢＭＩ）を有するユーザでは５００ｋｃａｌ／日だけ削減することを含んでもよい。ユーザは、例えば２００～２５０ｋｃａｌ／日を含む、１食分の食事代替製品を推奨されてもよい。例えば、ユーザは、ＮＵＴＲＥＮ ＤＩＡＢＥＴＥＳなどの食事代替製品を活用するように促されてもよい。分析サーバは、ユーザデバイス１０２を介してユーザに、毎日のグリセミック負荷として８５～１００／１０００ｋｃａｌを推奨し、推奨食料製品と組み合わされた、グリセミック負荷が３３未満又は４５未満の低グリセミック負荷の食事を推奨してもよい。
【0075】
[0083]高度から非常に高度なリスククラスタ９１０に属するユーザは、その前糖尿病リスクレベルに適した食事計画（例えば食事計画Ｂ）を（例えばブロック９１６に示すように）受信してもよい。分析サーバはユーザに、健康的な食事計画、カロリー制限、低グリセミック負荷、及び食事代替製品を（例えばユーザデバイス１０２上のアプリ１１４を介して）推奨してもよい。カロリー制限は、肥満ユーザでは１０００ｋｃａｌ／日だけ削減することを含んでもよい。ユーザは、例えば５００ｋｃａｌを含む、２食分の食事代替製品を推奨されてもよい。例えばユーザは、ＯＰＴＩＦＡＳＴ及びＮＵＴＲＥＮ ＤＩＡＢＥＴＥＳなどの食事代替製品を活用するように促されてもよい。分析サーバは、ユーザデバイス１０２を介して、毎日のグリセミック負荷として１０００ｋｃａｌに対して８５をユーザに推奨してもよい。更に、分析サーバは、推奨食料製品と組み合わされた、２０未満又は３０未満のグリセミック負荷を含む低グリセミック負荷の食事を推奨してもよい。
【0076】
[0084]本開示に記載される開示された方法及び手順はすべて、１つ以上のコンピュータプログラム又は構成要素を使用して実施することができる。これらの構成要素は、ＲＡＭ、ＲＯＭ、フラッシュメモリ、磁気若しくは光学ディスク、光学メモリ、又は他の記憶媒体などの揮発性及び不揮発性メモリを含む、任意の従来のコンピュータ可読媒体又は機械可読媒体上の一連のコンピュータ命令として提供されてもよい。命令は、ソフトウェア又はファームウェアとして提供されてもよく、ＡＳＩＣ、ＦＰＧＡ、ＤＳＰ、又は任意の他の類似するデバイスなどのハードウェア構成要素においても、全体的又は部分的に実施されてもよい。命令は、一連のコンピュータ命令を実行するときに、開示された方法及び手順のすべて又は一部の性能を遂行する又は容易にする１つ以上のプロセッサによって実行されるように構成されてもよい。
【0077】
[0085]本明細書に記載される実施例に対する様々な変更及び改変が、当業者には明らかであることは理解されるべきである。そのような変更及び修正は、本主題の趣旨及び範囲から逸脱することなく、かつ意図される利点を損なわずに、なされ得る。したがって、このような変更及び修正は、添付の特許請求の範囲によって包含されることが意図されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】