IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ヌーム インコーポレイテッドの特許一覧

特開2022-101641ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体
<>
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図1
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図2
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図3
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図4
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図5
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図6
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図7
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図8
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図9
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図10
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図11
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図12
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図13
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図14
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図15
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図16
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図17
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図18
  • 特開-ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体 図19
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022101641
(43)【公開日】2022-07-06
(54)【発明の名称】ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体
(51)【国際特許分類】
   G16H 50/30 20180101AFI20220629BHJP
【FI】
G16H50/30
【審査請求】有
【請求項の数】1
【出願形態】OL
(21)【出願番号】P 2022070102
(22)【出願日】2022-04-21
(62)【分割の表示】P 2020018984の分割
【原出願日】2012-09-14
(31)【優先権主張番号】61/534,855
(32)【優先日】2011-09-14
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.ANDROID
2.iPhone
(71)【出願人】
【識別番号】514063869
【氏名又は名称】ヌーム インコーポレイテッド
【氏名又は名称原語表記】NOOM,INC.
(74)【代理人】
【識別番号】100105957
【弁理士】
【氏名又は名称】恩田 誠
(74)【代理人】
【識別番号】100068755
【弁理士】
【氏名又は名称】恩田 博宣
(74)【代理人】
【識別番号】100142907
【弁理士】
【氏名又は名称】本田 淳
(72)【発明者】
【氏名】ペタコフ、アルチェム
(72)【発明者】
【氏名】サイモン、マーク
(72)【発明者】
【氏名】グンナション、ケティル
(72)【発明者】
【氏名】リン、チョウ
(72)【発明者】
【氏名】シャフラノヴィッチ、ゲンナディ
【テーマコード(参考)】
5L099
【Fターム(参考)】
5L099AA15
(57)【要約】      (修正有)
【課題】ウェルネスタスクの完了を促進するウェルネスタスクの生成、表示、追跡に係るシステム、方法及び非一時的なマシン可読媒体を提供する。
【解決手段】プログラム順守をユーザに維持させる方法300において、ユーザの健康に関連した目標を決定するステップ、目標成就に向けたユーザの進捗度を決定するために収集する情報を識別するステップ、情報の一部を提供するようユーザに催促する特定度レベルを選択するステップ及び情報の一部を提供するよう特定度レベルでユーザに催促するステップを備える。
【選択図】図3
【特許請求の範囲】
【請求項1】
システムであって、
1個以上のコンピュータプロセッサと、
1個以上のコンピュータメモリと、
ユーザが健康目標の完了に向けて当該ユーザの進捗のモニタリングを担当するトレーナー人員と通信できるように構成された第1のユーザインターフェースと、
前記トレーナー人員が、前記ユーザからの要求に応答して、ユーザ用の1組のタスクを変更できるように構成された第2のユーザインターフェースと、
前記1個以上のコンピュータメモリに保存された1組の命令と、を備え、前記1組の命令は、前記1個以上のコンピュータプロセッサが複数の処理を実行するように構成されており、前記複数の処理は、
前記ユーザ用の1組のタスクを決定するステップであって、前記1組のタスクは、前記健康目標に関連する1つ以上の固定タスクを含み、前記1つ以上の固定タスクの少なくとも1つが当該健康目標に関連するユーザから基礎情報の収集に関連する、前記ユーザ用の1組のタスクを決定するステップと、
前記1つ以上の固定タスクのうち、ある固定タスクをスマートタスクに入れ替えるか否かを決定する1組のスマートタスクトリガを繰り返すステップであって、該スマートタスクが、当該ユーザの健康目標に関連する追加情報の提供を当該ユーザに促すことを含み、前記追加情報が、前記健康目標の完遂に向けた当該ユーザの進捗に関連し、前記スマートタスクトリガが、事前にユーザから取得されなかった特定の情報に関連する、前記1組のスマートタスクトリガを繰り返すステップと、
前記特定の情報を提供するようにユーザに促すステップと、
前記特定の情報に基づいて、前記健康目標を達成するためのユーザの進捗度と、前記1組のタスクに対するユーザの順守の程度とを更新するステップと、
前記第1のユーザインターフェースを介して前記ユーザからの要求を受け取るステップであって、前記要求は前記トレーナー人員が前記1組のタスクを変更することを要求することである、前記ユーザからの要求を受け取るステップと、
前記第2のユーザインターフェースを介して前記トレーナー人員から受け取った入力に基づく前記要求に応答して前記1組のタスクの変更を実行するステップと、
を備える、システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体に関する。
【背景技術】
【0002】
最新の健康またはウェルネスプログラムのほぼ全てに伴う最たる難題の1つは、その順守である。これは、特定の症状向けの医薬品の服用から、体重減量、筋肉増強、健康的なライフスタイルなどといったこれよりも遥かに抽象的なウェルネス目標までの、継続的な努力を要する全てのプログラムに該当する。
【発明の概要】
【発明が解決しようとする課題】
【0003】
順守は、特定の健康またはウェルネス目標の達成方法が複数存在する場合には特に困難となり、優柔不断さと迷いによって順守および最終成果が大幅に低下する。プログラムは日誌または日記のメタファに注目したものであってよい。このようなプログラムでは、ユーザは現実世界で行うことを単純に「記録する」(例えば、書き留める)だけでよい。システムは、ユーザが記録されたパターンを考察し、記録されたパターンに基づいて行動変容を行うための補助となるグラフや表を生成および提示することができるあるいはシステムは、例えば医師や医学療法士にかかった後に受け取ることが通例の処方箋と同様に、「カスタマイズされたプログラム」として機能することが可能である。
【課題を解決するための手段】
【0004】
本明細書では、システムはユーザに関する情報を受信し、この情報に基づいて、カスタムプログラムを作成しユーザに従わせ、またはユーザに1セットのカスタムプログラムの中から1つを選択させることができる。これらのシステムの典型例には様々な制限がある。例えば、こうしたシステムはユーザにはロボット的または代用的に映る可能性がある。
【図面の簡単な説明】
【0005】
図1】様々な例証的実施形態を展開できるクライアント-サーバシステムを示すネットワーク図である。
図2図2は、パーソナルトレーナーの抽象体を実現するように構成された、図1のアプリケーション120の例証的なモジュールの示すブロック図である。
図3】プログラム順守をユーザに維持させる方法の例証的な実施形態を示すフローチャートである。
図4】ユーザにプログラム順守を維持させる方法400の例証的な実施形態を示すフローチャートである。
図5】自動目標生成と人間による目標生成とにおける、クライアントとサーバ間の例証的な相互作用を示す相互作用図である。
図6】タスクベースのインターネット健康プログラムを実現するべく構成されたアプリケーション120の例証的な流れを示すブロック図である。
図7】ユーザの健康プログラムに関連した情報をユーザに提示するための例証的なユーザインターフェースを示すスクリーンショットである。
図8】何を食べたかについての詳細な情報を提供するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。
図9】何を食べたかについての要約した情報を提供するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。
図10】ユーザの運動活動に関する情報を入力するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。
図11】ワークアウトに関する情報を集めるための例証的なユーザインターフェースを示すスクリーンショットである。
図12】ユーザに運動タスクを提示して、このタスクを完了したかどうかをユーザに明示させるための例証的なユーザインターフェースを示すスクリーンショットである。
図13】ユーザに小記事を提示するための例証的なユーザインターフェースを示すスクリーンショットである。
図14】今後、タスクの実行に専念するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。
図15図1のアプリケーションにアクセスしているユーザのコンテキストの外にウィジェットを展開させた例証的なユーザインターフェースを示すスクリーンショットである。
図16】ユーザがトレーナー人員と直接通信できるようにするための例証的なユーザインターフェースを示すスクリーンショットである。
図17】ユーザがトレーナー人員と通信できるようにするための例証的なユーザインターフェースを示すスクリーンショットである。
図18図1のアプリケーションが使用するデータベースのテーブル間の例証的な関係を示すブロック図である。
図19】本明細書中で述べた任意の1つ以上の技法をマシンに実行させる命令を実行することができるコンピュータシステムの例証的な形態をしたマシンのブロック図である。
【発明を実施するための形態】
【0006】
これ以降、説明の目的で、本発明の主題の様々な実施形態を理解するために多くの特定の詳細について述べる。しかし当業者には、これら特定の詳細がなくても様々な実施形態を実施できることが明白になるだろう。
【0007】
様々な実施形態では、パーソナルトレーナー(またはコーチ)の抽象体を提供する方法およびシステムを提供しており、ユーザは適切な指示を適時に、ユーザをプログラムに従わせるための適切な応援と共に受けることができる。プログラムは途中で調整することが可能である。これにより、ユーザのプログラム順守とプログラムの最終的な成功との両方が向上する。
【0008】
様々な実施形態では、ウェルネスタスクの完了を促進する方法およびシステムを開示している。まず、ユーザの健康に関連した目標が決定される。ユーザのゴール完遂に向けた進捗を決定するために収集される情報が識別される。この情報の一部を提供するようユーザに促す特定度レベルが選択される。ユーザは、情報の一部の提供をこの決定された特定度レベルで催促される。目標完遂に向けたユーザの進捗度は、この情報の一部に基づいて決定される。
【0009】
本明細書で開示する方法および様々な実施形態は、1個以上のモジュール(例えばハードウェアモジュールまたはソフトウェアモジュール)を実装したコンピュータシステムとして実現することができる。本明細書で開示する方法および様々な実施形態は、マシン可読媒体に記憶された命令として具現化されてよく、この命令はプロセッサにより実行されるとプロセッサに上記方法を実行させる。
【0010】
図1はクライアントサーバシステム100を示すネットワーク図であり、このシステムにおいて様々な例証的な実施例を展開することができる。ネットワークシステム102は1個以上のクライアントに対して、サーバサイド機能を、ネットワーク104(例えば、インターネットまたはワイドエリアネットワーク(WAN))経由で提供する。図1は例えば、クライアントマシン110、112上で実行する、ウェブクライアント106(例えば、ワシントン州レッドモンドにあるマイクロソフト社(Microsoft Corporation)が開発したインターネットエクスプローラブラウザなどのブラウザ)と、プログラマチッククライアント108(例えばAndroidまたはiPhoneアプリケーション)を示す。
【0011】
APIサーバ114およびウェブサーバ116は1個以上のアプリケーションサーバ118につながれ、このアプリケーションサーバに対しプログラマチックインターフェースとウェブインターフェースをそれぞれ提供する。アプリケーションサーバ118は1個以上のアプリケーション120をホストする。同図中、次に、1個以上のデータベースまたはNoSQLあるいはノンリレーショナル・データストア126へのアクセスを容易化するために、アプリケーションサーバ118が1個以上のデータベースサーバ124につながれて示されている。
【0012】
図1に示すシステム100はクライアントサーバ構築を採用しているが、当然ながら様々な実施形態はこのようなアーキテクチャに限定されず、例えば分散またはピアツーピア型のアーキテクチャシステムにも同様に上手く応用される。様々なアプリケーション120は、必ずしもネットワーク機能を持たないスタンドアロンソフトウェアプログラムとして実現することも可能である。さらに、図1は、マシン130、110、112を1つのネットワークシステム102につないだ状態を示しているが、マシン130、110、112、ならびにアプリケーション128、106、108を複数のネットワークシステムにつなぐことも可能であることが当業者には容易に明白となるだろう。例えば、アプリケーション128、106、108を、複数の支払いプロセッサ(例えばビサ、マスターカード、アメリカンエクスプレス)に関連付けされた複数の支払いアプリケーションにつなぐことができる。
【0013】
ウェブクライアント106は、ウェブサーバ116によってサポートされたウェブインターフェース経由でアプリケーション120にアクセスする。同様に、プログラマチッククライアント108は、アプリケーション120が提供する様々なサービスおよび機能に、APIサーバ114によって提供されたプログラマチックインターフェース経由でアクセスする。クライアントまたはサーバを実行できるマシンの例証的なアーキテクチャを図19に関連して説明する。
【0014】
様々な実施形態では、ウェブサーバ116はアパッチウェブサーバであり、データベースサーバ124はMySQLリレーショナルデータベース管理システム(RDMS)である。
【0015】
以降で詳述するように、様々な実施形態では、クライアントはタスクベースのユーザインターフェースをユーザに提示し、クライアントセンサを介して黙示的に、またはデータ入力から明示的にデータを収集し、記事やチャレンジなどをユーザに表示する。Android携帯電話上で実行中のクライアントなどのいくつかのクライアントは、サーバ(例えばAPIサーバ114)に情報をクライアントへプッシュさせるプッシュ技術を実現することができる。このプッシュ機能は、1個以上のアプリケーション(例えばアプリケーション120)が、クライアント(例えばクライアント128、106、108)に新規のまたは更新されたタスクを通知するために使用することができる。別のクライアント上では、この通知を、メモリ常駐型プログラムによるポーリングによって実現できる。クライアントは、収集したデータをバックアップおよび分析の目的でサーバに送る。サーバ上で実行中のアプリケーション(例えばアプリケーション120)は、データの分析、バックアップ、およびタスク生成を扱うことができる。ユーザとの相互作用に基づいて効率的で精選された1組のタスクを正確な順序で生成することは、複雑な工程であり得る。
【0016】
図2は、パーソナルトレーナーの抽象体を実現するように構成されたアプリケーション120の例証的なモジュールを示すブロック図である。
プレゼンテーションモジュール202は、1組の毎日のタスクをユーザに提示する。様々な実施形態において、これらのタスクは、図7に示すようなタスクホイール上にグラフィック表示される。
【0017】
採点モジュール204は、ユーザがこれらタスクの各々の完了に向けて進捗すると採点を行う。採点モジュール204は、各タスクの状態をホイール上に示すことができる。
収集モジュール206は、ユーザがどのような目標(1個以上)を達成しようとしているかの情報など(例えば体重減量、背中の痛みの軽減など)、ユーザに関する情報を収集する。このような情報は、ユーザが手動または自動記録を介して明示的または黙示的に提供した情報から収集される。収集モジュール206は、ユーザから経時的にデータを収集し、このユーザから取得したデータに基づいてタスクの調整を行う。したがって、プログラムは、プログラム開始時にユーザから受信した情報だけでなく、さらにプログラムに参加したユーザからの情報に基づいてカスタマイズされる。
【0018】
選択モジュール208は、ユーザの1日のタスクの最良の1組を、コーチが受信したユーザに関する情報に基づいて選択する。選択アルゴリズムは、ユーザにプログラムを最大限順守させつつ目標に到達させられる最良のタスク数の決定に基づいて、タスク数を制限することができる(例えば1日に8~10タスク)。この決定は、収集モジュール206から受信した、ユーザの目標と、提案されたタスクの完遂履歴とに関する情報に基づいてよい。以下で、選択アルゴリズムについて詳述する。
【0019】
通信モジュール210は(例えば、ユーザとパーソナルトレーナーの相互作用をシミュレートするために)ユーザと通信する。例えば、通信モジュール210は、ユーザのタスク完了または目標到達への進捗度を示すメッセージを送信することができる。あるいは、通信モジュール210は、選択モジュール206がユーザに実行させる特定のタスクを選択した理由を1つ以上記載したメッセージを送信できる。様々な実施形態で、通信モジュール210はユーザへのメッセージを自動送信する(例えば、実際の人物が入力を行う作業を組み込まない)。別の実施形態では、通信モジュール210は、実際の人物からのメッセージを組み込む、または実際の人物がメッセージをユーザに直接送信する。
【0020】
通信モジュール210は、実際の人物からの入力をどの程度組み込むかを、様々な要因に基づいて決定する。例えば、通信モジュール210は、実際の人間からの入力を受け取りたいと言うユーザからの要求を、実際の人物から提供可能なこうした入力の供給によって、(例えば要望に基づいて)バランスを取っている。様々な実施形態にて、通信モジュール210は、ユーザが、ユーザ順守を向上させるのに必要な程度の人間どうしの相互作用を受けられるようにするのにちょうど十分な程度の実際の人物からの入力を、配備された人間で賄える上記レベルの人間どうしの相互作用を超えない範囲で、ユーザとの通信に組み込む。したがって、様々な実施形態において通信モジュール210は、通信がロボット的または柔軟性に欠けるもののようにユーザに映らず、さらに常に人間どうしの相互作用が必要にならないレベルの自動化度でユーザと通信することができる。
【0021】
図3は、プログラム順守をユーザに維持させる方法300の例証的な実施形態を示す。様々な実施形態にて、方法300はアプリケーション120によって実現できる。演算302は、収集モジュール206が、ユーザの健康に関連した目標を決定する。演算304では、収集モジュール206が、目標完遂に向けたユーザの進捗を判断するために収集すべき情報の識別を行う。収集モジュール206は、ユーザから経時的にデータを収集し、ユーザについて取得したデータに基づいてタスクを調整する(例えば、選択モジュール208によって選択する)ことができる。言い換えれば、プログラムは、その開始時にユーザについて収集したあらゆるデータと、さらにプログラムの寿命にわたって収集したデータとに基づいてカスタマイズされ得る。
【0022】
選択モジュール208は、目標までの過程で多数の(例えば数百または数千)異なるタスクを生成するか、またはその中から選択することができる。しかし、選択モジュール208は、これらタスクのサブセットをユーザに対して所与の期間しか提示できない。例えば、選択モジュール208は1日に8~10個のタスクしかユーザに提示できない。選択モジュール208は、どのタスクおよびタスク順序がユーザのプログラム順守を最も高めるかについての選択モジュール208の決定に基づいて、ユーザに提示する一連のタスクを選択および決定する。
【0023】
選択モジュール208は、様々な異なるタスクを実行するようユーザに「請う」(例えばユーザインターフェース経由)上で優れた柔軟性を持ってよい。これらのタスクには様々な種類がある。例えば、タスクは明示的データ収集タスク、手動記録タスク、自動追跡タスク、小記事を読むタスク、ミニチャレンジタスク、スケジューリング/今後の約束タスクであってよい。選択モジュール208は、これらのタイプならびにその他のタイプのタスクを生成または選択するように構成されてよい。
【0024】
明示的データ収集タスク:最も単純なタイプのタスクの1つ。このタスクはユーザに1つまたは1組の明示的な質問をする。これは、外部ツールまたはセンサ(例えば体重計やグルコース計)からの測定値についての質問、ユーザの過去の行動についての質問、ユーザの特定タスクの嗜好についての行動、またはその他のあらゆる一般的な質問であってよい。質問は多肢選択式、自由入力式、またはこれらあるいはその他形式の組み合わせであってよい。
【0025】
手動記録タスク:このタスクはデータ収集タスクと多少似ているが、より全般的/無向性のデータ収集機構を要する点が異なる。その1例は、朝食、昼食、夕食の非常に詳細なログを残すようユーザに要請するというものである。これらのタスクでは、ユーザは多くの情報を収集しなければならず、多大な労力が掛かるにもかかわらず、後にアプリケーション120が使用する情報はほんのいくつかである。ユーザが全てを記録するよう要求する代わりに、選択モジュール208が特定の場合にのみ記録をつけるようにユーザに要請するタスクを選択できる。さらに、選択モジュール208は、例えば、ユーザの目標到達に向けた進捗度を判断する上で、または、ユーザにプログラム順守を維持させつつ目標到達を最も補助すると考えられる追加のタスクを選択するべくタスクを生成する上で、アプリケーション120を最も支援する情報に基づいて、様々な詳細レベルの情報を提供するようユーザに要請するタスクを選択できる。例えば、選択モジュール208は、詳細な記録を伴うタスクを週1回選択してもよい。週のこれ以外の日には、選択モジュール208は、ユーザ行動(または習慣)、あるいはデータまたは変数(例えば、収集モジュール206が黙示的に収集したデータ)に基づいて詳細な記録を推測することができる。
【0026】
食事ログ作成タスクを使用して、関連概念を例示することができる。選択モジュール208は、まず、選択モジュール208が持っていない、ユーザが特に何を食べているのかについての情報に基づいて詳細なログ作成レベルのタスクを選択しておき、後々、減量の支援に適した食品を選択できるようにすることが可能である。選択モジュール208がこの詳細なログ作成レベルのタスクをひと月に選択するのは、ユーザにどのような提言をすればよいかを知るのに十分な数回のみでよい。図8は、選択モジュール206がユーザにこの詳細な情報を要請することができる例証的なユーザインターフェースを示す。
【0027】
これ以外の時においては、選択モジュール208はそれほど詳細でないログ作成レベルのタスクを選択してよい。例えば、選択モジュール208は、食べている料理の大まかな食品品質をユーザに提供させるタスクを選択できる。図9は、収集モジュール206がこの詳細度の低い情報の提供をユーザに要請することができる例証的なユーザインターフェースを示す。選択モジュール208は、ユーザの重荷になることなくしっかりとした食事を奨励できるので、この詳細度の低いタイプの記録を頻繁に選択してよい。選択モジュール208は、目標完遂に向けたユーザの進捗に関するデータの空白を、ユーザについて収集した様々な追加情報(体重など)に基づいて埋めることができる。例えば、選択モジュール208は、ユーザの変化のない体重に基づいて、ユーザの食事療法が変更されていないと判断することができる。あるいは、ユーザの体重の変動に基づいて、ユーザの食事療法が変更されたと判断することができる。この場合、ユーザの体重が変動していれば、選択モジュール208はより詳細な記録タスクを選択してユーザに実行させるか、あるいはユーザに記録タスクの完了を要請する頻度を上げることができる。
【0028】
運動ログ作成タスクを使用して、詳細レベルの異なる、運動に関連する記録タスクの選択を例示することもできる。例えば、図10は、収集モジュール206に(例えば手動でのログ記録によって)ユーザの運動に関する詳細な情報または詳細でない情報を収集させる例証的なユーザインターフェースを示す。
【0029】
自動追跡タスク:このタスクは記録タスクと似ているが、ユーザがデータを明示的に入力する必要がなく、代わりに、ユーザに関連したデバイス上で利用可能な1個以上の外部センサからの測定値に依存している点が異なる。例えば、この実施形態では、携帯電話上で実行中の「10分間歩行」タスクが、電話の加速度計およびGPSセンサを使用し、これらが測定した値を組み合わせてより正確な(また、GPS信号が途絶えた時には信頼性の高い)測定値を得る(図11参照)。運動のタイプがダンスの場合は、電話は加速度計のみを別モードで使用する。いくつかの自動追跡タスクでは、絶えず追跡を行っているのでユーザが追跡を開始する必要さえない。これらは最も望ましい目標のうちのいくつかである。省電力タイプの歩数計を使用して常に歩数を監視することができる。
【0030】
小記事を読むタスク:このタスクは、目標達成に関連した特定テーマの知識をユーザに与える。例えば、減量を試みている人の場合、これは「ダイエットソーダの危険性」という記事であってよい。様々な実施形態で、他のタスク(例えば記録タスク)へのユーザフィードバックに基づいてトリガされる。小記事タスクは、テキスト文書と「読み終えました」ボタンとをユーザに提示する(図13参照)。別の実施形態では、本発明は、ユーザが記事を読み終えるとミニテストを提示する。
【0031】
ミニチャレンジタスク:小記事タスクと類似するが、このタスクはユーザに特定の行為を行うよう要請する。例えば、「エレベータではなく階段を使いましょう」である(図12参照)。一実施形態では、これらのタスクは、他のタスク(例えば記録タスクまたは明示的データ収集タスク)に提供されたフィードバックに基づいてトリガされる。ミニチャレンジタスクはユーザにチャレンジの内容の説明と「実行しました」ボタンを提示する。別の実施形態では、本発明は、タスク完了を追跡する自動追跡機能を使用する。
【0032】
スケジューリング/今後の約束タスク:このタスクはユーザに、今後の計画を立てる、または単純に、今後、特定の目標に専念するように要請する。「プレコミットメント」とは、達成がずっと先に思えるタスクに人々を専念させるための(例えば、翌朝起きるのが大変そうでも夜目覚まし時計をセットするのと同じである)、強力な行動修正技術である。
【0033】
このようなタスクの一例は「食料品買い出し日」である。収集モジュール206が、何日に食料品の買い出しに行けるかをユーザに聞き、次に、選択モジュール208が、ユーザの返答に基づいて「健康な食料品買い出し」目標を適切な日にスケジュールする。
【0034】
別の例に、以後予定される従うべき運動スケジュールに専念するようユーザに要請する「運動スケジュールの設定」目標(図14参照)がある。スケジューリング後、また、ユーザが過去にコミットメントを守れなかったことがある場合には、選択モジュール208が、ユーザの今後の目標に対する意欲を再確認するために、別のコミットメント目標をスケジュールする。
【0035】
再び図3を参照すると、演算306で、選択モジュール208が、情報の一部を提供するよう(例えば収集モジュール206を介して)ユーザに催促するための特定度レベルを選択する。上述したように、特定度レベルは、タスク完了に向けたユーザの進捗度に関して選択モジュール208が(例えば、追加データの黙示的または明示的な収集から)得られなかった情報に基づいてよい。
【0036】
演算308で、収集モジュール206が、情報の一部を提供するよう、この特定度レベルでユーザに(例えばユーザインターフェース経由で)催促する。
図4は、ユーザにプログラム順守を維持させる方法400の例証的な実施形態を示す。演算402で、選択モジュール208が、ユーザの目標に基づいて複数のタスクを生成する。演算404で、通信モジュール210が、複数のタスクのうちの、或るタイプを持った1つのタスクを完了するようユーザに提言する。演算406で、選択モジュール208が、さらに或るタイプを持った追加のタスクに基づいて、上記複数のタスクの中から追加のタスクを選択する。演算408で、通信モジュール210が、この追加のタスクを完了するようユーザに提言する。こうすることで、アプリケーション120は、所与の時間内に実行する多様なタイプのタスクをユーザに提案することができ、これによりユーザのプログラム順守が強化される。
【0037】
本発明は、多様なタスクタイプの生成およびユーザへの提示に加えて、ユーザが各タスクを完了するごとに点数を与える。的確な得点方法こそ行動パターンの変容に重要であるかもしれない。
【0038】
様々な実施形態では、採点モジュール204は最高で100点の中から得点を使用するが、この得点は毎日0にリセットされる。ユーザは各タスクを完了する毎に、100点の分割点数を獲得する。ユーザは、全てのタスクを完了すると100点を獲得する。各タスクに割り当てられた100点の分割点数は、ユーザが望む目標/結果の達成におけるそのタスクの重要性を表し得る。例えば、ユーザの目標が減量である場合には、全得点のうちで食事療法関連の目標が運動関連の目標よりも大きな割合を占め、これにより食事療法タスクの完遂がより重要であるという見識をユーザに与えることができる。
【0039】
ユーザは全得点を獲得した時点で1日を終了できるが、この終了状態をユーザに明確に示すことができる。言い換えれば、ユーザは可能な限りの達成ではなく(例えば、食品または運動と同量の記録をこなすことが可能であっても)、特定の1組のタスクだけ完了することを奨励される。こうして、採点モジュール204は、ユーザが短期間のうちに熱中し過ぎることによる「過剰実行」の犠牲になり得ることを考慮に入れている。しかし、採点モジュール204は、妥当な範囲内で、割り当てられたタスク以上をこなすことを許可できる。具体的には、採点モジュール204は、ユーザが実行を選ぶかもしれない追加タスクのために20点を余分に用意しておくことができる。
【0040】
特定の1つのメトリック(例えば燃焼カロリー量)の周辺でユーザにモチベーションを持たせることは、所望の目標を達成する上でユーザに求められる広範囲の行動や、1つのメトリックを達成する上で他の人々が感じるであろう困難を反映しないので、その代わりに、採点モジュール204は、得点を努力の面から個人間で比較できるようにしている。
【0041】
採点モジュール204は、個人の毎日の得点を加算して組み合わせ、週間得点および総得点とすることができる。これにより、ユーザは目標に向けた長期間の進捗を目で確認し、計れるので、さらに長期的に継続するモチベーションを持つことができる。
【0042】
アプリケーション120の様々な実施形態は、採点機構の他にも様々な機構を使用して、指定されたタスクを完了するようユーザを奨励する。
図15は、ウィジェットを含んだユーザインターフェース1500の例証的な実施形態のスクリーンショットを示す。ウィジェットは、ユーザがアプリケーション120にアクセスしていない時でもユーザに提示される毎日の得点の小型化された表示であり(例えば、モバイルデバイス上のクライアントアプリケーション経由で提示される)、これにより、ユーザは得点をより頻繁に確認するよう奨励され、その結果、順守性が向上する。この実施形態では、ウィジェットはAndroidウィジェットとして実現されているが、得点を小型化して、通常のクライアントアプリケーションの外部にユーザに示せることができさえすれば、インフレーム、またはその他のHTML5実現におけるRPC方法などのあらゆる埋め込み技術を用いて実現することが可能である。
【0043】
さらに、様々な実施形態では、アプリケーション120は各種の機構を使用して、ユーザにソーシャルプレッシャー(訳注:オンライン上の世間の目による圧力)を掛ける。例えば、通信モジュール210は、ユーザにサポータ(または「相棒」)を指定させることができ、サポータは、ユーザが完了すべきタスクを受け取る度、ならびにタスクを完了する度に通知を受ける。通知の頻度は、毎時から毎月の間でサポータがカスタマイズできる。相棒は、心理的サポートと、プログラムへの実際のサポート(例えば、健康的な食事を料理する、一緒に散歩に行くなど)の両方を提供できる親しい友人または配偶者であってよい。
【0044】
別の例として、通信モジュール210はアプリケーション120をインターネット自助グループと統合することができる。このインターネット自助グループは、共通の目標や人口統計学的特徴に基づいてグループ化されたユーザの小規模グループであってよい(例えば、10~20ポンド(約4.5~9kg)の減量を望む、40歳以上の女性だけのグループ)。ユーザの許可があれば、こうしたグループは、特定ユーザの毎日、毎週、総合の得点、さらにそのユーザに割り当てられたタスクと完了したタスクとの全てにアクセスすることも可能である。このグループは、従来のサポートグループと同様に、順守を奨励するためのさらなる友好的圧力、ならびに個人の経験からのアドバイスを提供することができる。ユーザはグループフォーラムにアクセスし、全員が互いに通信し合うことができる。通信モジュール210によりクライアントアプリケーション経由で提示されたユーザインターフェースでは、各メンバーの横に毎日、毎週、総合の得点を表示し、これらの得点をグループメンバーの「ステータスシンボル」にしてもよい。
【0045】
様々な実施形態において、採点モジュール204は、「長期的な」順守を奨励するために1組のゲームメカニクスを組み込むことが可能である。一実施形態では、このようなメカニクスはレベルシステムを含むことができる。このレベルシステムでは、各ユーザはレベル1から開始し、週毎に、1日の平均獲得点数が80点以上であればレベルが1つ上がり、週毎に獲得点数が50~80点であればレベルは変更されず、週毎に50以下であればレベルが1つ下がる。さらに、ユーザは、平均得点が90点以上になった週には「バッジ」を獲得する。バッジはいかなる状況でも失われない。他の実施形態は、その他のレベルおよびバッジについての計算式を含むことができる。レベルとバッジの両方は、ユーザおよび様々なタイプのサポータに対して目立つように表示される。
【0046】
様々な実施形態において、採点モジュール204は、長期間にわたってタスクを順守した見返りとしてユーザ外部からの賞品を与えることで、モチベーションを向上させることができる。こうした賞品は、特定タイプのタスクを満たした場合や、所定期間で1組のタスクを達成した場合(例えば、この5日間に全ての目標)に受けられる、スポンサーからのオファー(例えば、5つのランニングタスクを続けて実行すると、ナイキの靴の割引)を含む。タスクインフラストラクチャは柔軟であるので、採点モジュール204は、広告提供パートナーが要求する特定の行動へのやる気を起させ、次に、この行動を達成したユーザに賞品を与えることができ、これは全てタスク順守の自然なコンテキストに含まれる。
【0047】
様々な実施形態において、タスク生成方法(例えば、選択モジュール208を介して生成する方法)は、特定の実施形態が示唆しようとしている健康目標に基づいていてよい。次の例は体重減量目標に関連するが、これと同一の方法および原理は他の目標にも適用できる。
【0048】
様々な実施形態において、選択モジュール208は、固定タスクと、条件付きの「スマート」タスクとの組み合わせを用いて、フルセットのタスクをユーザに生成する。最初は、選択モジュール208はユーザに関する情報を全く知得していない可能性があるので、ユーザから基礎情報を(例えば、収集モジュール206を介して)収集するための1組の固定の強化タスクを割り当てることができる。システムがユーザについて学習するにつれ、選択モジュール208は、スマートタスクが固定タスクから引き継ぎ、残りのコーチングプログラムにわたってユーザを誘導できるようにする。「スマート」タスクは、特定の条件が正である場合にしか生成されないタスクである。スマートタスクの平凡な例は、過去の約束のためにスケジュールされるタスクである。例えば、ある人物が毎週金曜日に買い物に行くと約束した場合、本発明が毎週金曜日に「健康的な食料品買い出し」目標を生成する。スマートタスクを生成するためには、選択モジュール208が1組のスマートタスクトリガを繰り返し、そのスマートタスクをスケジュールすべきかどうかを決定する。
【0049】
初期ブートストラップ固定タスクシーケンスは、後述のように様々なタスクを含むことができる。しかし、特定のタスクはそれぞれ大幅に変更できることが当業者には明らかであろう。
【0050】
1日目
1:コーチの紹介記事を読みましょう(記事タスク)。
2:あなたとあなたのウェルネス目標についての質問表に記入しましょう(明示的データ収集タスク)。
【0051】
3:食事記録を使って昼食を詳細に記録しましょう(記録タスク。図3参照)。
4:ミニチャレンジ:今日は階段を使いましょう。階段がどこにもない場合や、時間が遅い場合には、今すぐジャンピングジャックを20回行ってください(ミニチャレンジタスク)。
【0052】
2日目
1:今日は、油を使って調理していない5種類の野菜を食べましょう(ミニチャレンジタスク)。
【0053】
2:食品記録を使って夕食のログを残しましょう(記録タスク)。
3:最低限の運動ベースラインに関する記事を読みましょう(記事タスク)。
4:ホーム画面にNoomウィジェットをインストールしましょう(ミニチャレンジタスク/モチベーション)。
【0054】
5:5分間ウォーキングに行きましょう(自動追跡タスク)。
3日目
1:あなたの食習慣に関する基礎質問表に記入しましょう(明示的データ収集タスク)。
【0055】
2:1日のおおまかなログを残しましょう(記録タスク)。
3:運動スケジュールを再考しましょう(ミニチャレンジタスク)。
4:食料品買い出しの日をスケジュールしましょう(今後の約束タスク)。
【0056】
条件付きタスクの生成(「スマート」タスク)
3日目以降、選択モジュール208がスマート(条件付き)タスクの使用を開始する。別の実施形態では、この時点よりも以前に、より長い固定コーチングシーケンスを設けてもよい。
【0057】
(1)食品記録スマートタスクは、各種食事についての情報を提供するようユーザに促す。このタスクは、直近10日間に1日3食の食事のうち特定のものの記録が4回未満でないかチェックし、その食事のログを残すように0.3の確率でスケジュールする。
【0058】
(2)食品小記事スマートタスクは、健康的な食品を摂取するようユーザに促す。このスマートタスクは、一月前の食事データをチェックし、その人物が食べた個々の食品全てを、各食品を何回食べたかカウントしながら収集することでこれを行う。次に、タスクはこのカウントに基づいて個々の食品を分類し、リストを反復し、その食品に関する記事をトリガする。その記事が過去にユーザに提示されていれば、リスト中の次の食品を選ぶ。記事が見つかったが場合、0.8の確率でトリガされる。
【0059】
(3)直近3日間のそれぞれの日にユーザが80点以上を獲得した場合に、おめでとうスマートタスクがトリガされる。タスクがトリガされると、ユーザにおめでとうの言葉をお送り、今後もプログラムを継続するように促す小記事タスクを挿入する。このタスクは特定の確率(例えば0.8)でトリガされる。
【0060】
(4)アンケートスマートタスクは、5個で1組のアンケートを有し、この1組のアンケートはユーザがこの5個のアンケートのうち1個にまだ回答していない場合に、(例えば0.1の確率)ランダムにトリガされる。
【0061】
(5)チャレンジスマートタスクは、各々がランダムにトリガされる(例えば0.2の確率)1組のミニチャレンジを有する。別の実施形態では、これらのミニチャレンジは、アンケート結果を使用して、チャレンジのいくつかを条件付きでトリガすることができる。「5分間歩く」などのいくつかのミニチャレンジには、自動運動追跡が関与している。
【0062】
上述した1組のスマートタスクは明らかに網羅的でなく、各目標に特化し、常に改良開発されている。
タスク生成における自動学習。タスクベースのシステムによって、タスクの割り当ておよびその後の順守と、所望の成果に向けた進捗とに基づく効率的な学習が可能になる。選択モジュール208は強化学習(RL)を使用できる。例えば、選択モジュール208は、次の2週間にかけて特定の目標の割り当てが順守レベルに与える影響を計算することができる。これは、グローバルコンプライアンスおよび成果に向けた進捗の近似値としての役割を果たす。別の実施形態では、選択モジュール208が、1組の目標(レジメン)の割り当てが成果に与える影響を計算する。
【0063】
別の例では、選択モジュール208は、実験的な人員グループに特定の新たな実験的タスクを導入し、このタスクの挿入による影響を制御グループと対比させてモニタリングすることができる。
【0064】
人間による支援を介在させた目標生成およびコーチメッセージング選択モジュール208は、上述したように、効率的なオンライン健康プログラムの一部であるタスク生成、記録および追跡を自動化することができる。しかし、本発明はさらに、ユーザが追加のヘルプを必要とする場合、所望の目標に到達する前に平坦域に嵌ってしまった場合、あるいは自動レジメンでは許可されていない機能を必要とする場合などの様々な状況において、人間による相互作用を可能にする。
【0065】
通信モジュール210は、人間によるメッセージングや手動タスク調整などの多様な形式での人間による相互作用を可能にする。人間によるメッセージングについては、通信モジュール210が、ユーザとサポートコーチ人員の両方が互いにショートメッセージを送信できるようにする(図16参照)。こうしたメッセージを短く済ませるように設計することが可能であり(例えば250文字未満)、これにより、例えばユーザがきちんと構成されていないため処理が難しい情報をシステムに多く供給することを防止できる。例えば、ユーザに関する多くの情報は、収集モジュール206により、その目的のためだけに設計された適切な明示的データ収集タスクを介して収集される。
【0066】
手動タスク調整については、選択モジュール208が、ユーザが受け取るタスクの調整をコーチ人員に行わせるようにすることが可能である。この調整はユーザの要請によってトリガされるか、または人員に介入の警告を発する自動規則によってトリガされる。例えば、ある規則は、クライアントが2週続け所望の成果に向けた進捗予定の50%未満しか達成していない場合には、コーチ人員に警告を発すると明記されてよい。コーチ人員は警告を受けると、そのユーザのその日、または今後の任意の1日にスケジュールされたあらゆる目標を作成、削除、修正することができる。
【0067】
手動タスク調整および人間によるメッセージングは、多くの場合、相互に作用し合う。例えば、体重減量プログラムの一部として、コーチ人員がある人物の好みの野菜を知りたい場合、コーチはシステムに明示的データ収集タスクを挿入し(例えば選択モジュール208経由)、ユーザにその質問の理由を通知する(例えば通信モジュール210経由)。これにより、人間の介入をそれほど必要としないながらも、人間が関与した場合に得られる「暖かい」感じと責任とを作り出す強力な組み合わせが生まれる。
【0068】
図5は、自動(例えば日中、夜間)目標生成および人間が生成する目標生成における、クライアント(例えばクライアント128、106または108)とサーバ(例えばサーバ118)の間の例証的な相互作用500を示す。日中の目標生成の実行において、クライアントはユーザが入力したデータを収集する(例えば、サーバから受信した命令に応答してクライアントが提示させたユーザインターフェース経由)。するとサーバが、これに応答してタスクを生成する(例えば選択モジュール208経由)。クライアントがこれに応答し、これらのタスクを表示して、ユーザにタスクと相互作用させる(例えば、これらのタスクに関連したデータを入力させる)ことができる(例えばユーザインターフェース経由)。次に、これに応答し、サーバがこの入力に基づいてユーザを採点する(例えば採点モジュール204経由)。
【0069】
夜間の目標生成の実行において、サーバは、受信したユーザに関する情報に基づいてプログラムを調整する(例えば収集モジュール206経由)。これに応答したクライアントが新規タスクを受信して、これをユーザに提示する(例えばユーザインターフェース経由)。
【0070】
人間によって生成された目標の実現において、全自動式の処理に人間味を加えるために、コーチ人員がアプリケーション120に入力を提供することができる(例えば、通信モジュール210経由でユーザと通信することで、あるいは、実行すべきタスクを選択モジュール208経由で手動でユーザに提案することで行う)。
【0071】
図6は、タスクベースのインターネット健康プログラムを実現するべく構成されたアプリケーション120の例証的な流れ600を示すブロック図である。最初にユーザのデータおよび目標を取り入れる。毎日の目標が生成される。ユーザが追加のデータを明示的または黙示的に入力する。ユーザが(例えば、1日の目標をどのように完了したかについて)採点され、フィードバックが(例えばユーザのクライアントデバイス上に)表示される。上記明示的または黙示的に受信したデータに基づいて、インターネット健康プログラムをユーザに合うように調整する。オプションで、人間(例えば、ユーザの個人コーチ)がこの調整を補助する。
【0072】
図7は、アプリケーション120の例証的なユーザインターフェース700のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース700は、提案されたタスク、この提案のタスクまたは目標の完了に向けたユーザの進捗状態など、ユーザの健康プログラムに関する情報をユーザに提示する。
【0073】
図8は、アプリケーション120の例証的なユーザインターフェース800のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース800は、何を食べたかに関する詳細な情報を提供するようユーザに促す。
【0074】
図9は、アプリケーション120の例証的なユーザインターフェース900のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示)。ユーザインターフェース900は、何を食べたかに関する情報を、ユーザインターフェース800が要求したよりも大まかな形式で提供するようユーザに促す。
【0075】
図10は、アプリケーション120の例証的なユーザインターフェース1000のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース1000は、運動活動に関する情報を入力するようユーザに促す。ユーザインターフェース1000は、非常に詳細な情報またはそれほど詳細でない情報をユーザに催促するように構成されてよい。
【0076】
図11は、アプリケーション120の例証的なユーザインターフェース1100のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース1100は、アプリケーション120が、ユーザが実行したランニングワークアウトに関する情報を黙示的に集めることを示す。様々な実施形態では、ユーザは、ランニングワークアウトに関する情報の明示的な入力を催促されなくてもよい。
【0077】
図12は、アプリケーション120の例証的なユーザインターフェース1200のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース120は、実行すべき運動タスクをユーザに提示し、そのタスクを完遂したかどうかをユーザに記入させる。
【0078】
図13は、アプリケーション120の例証的なユーザインターフェース1300のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェースは、実行すべき小記事タスクをユーザに提示し、そのタスクを完了したかどうかをユーザに記入させる。タスクの選択は、選択モジュール208によって、先にユーザに提案された追加のタスクとは異なるタイプのタスクに基づいて行うことができる。
【0079】
図14は、アプリケーション120の例証的なユーザインターフェース1400のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース1400は、今後タスクの実行に専念するようユーザに促す。
【0080】
図15は、アプリケーション120の例証的なユーザインターフェース1500のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース1500は、アプリケーション120にアクセスしているユーザのコンテキストの外に表示されたウィジェットを含む。
【0081】
図16は、アプリケーション120の例証的なユーザインターフェース1600のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース1600は、ユーザがトレーナー人員と直接通信できるようにする(例えば通信モジュール210経由)。
【0082】
図17は、アプリケーション120の例証的なユーザインターフェース1700のスクリーンショットである(例えば、クライアントデバイス上で実行中のクライアント経由で提示される)。ユーザインターフェース1700は、タスクまたは目標の完了に向けたユーザの進捗のモニタリングを担当するトレーナー人員の、内部コンソールとして提示されてよい。トレーナー人員は、(例えば、ユーザにメッセージを送るため、またはユーザにタスクを提案するために)コンソール内の情報を使用してユーザと直接相互作用することができる。
【0083】
図18は、アプリケーション120が使用しているデータベース(例えばデータベース126)のテーブル間の例証的な関係1800を示すブロック図である。テーブルは、記事、記事の結果、食品入力、目標、ユーザ、Noomメッセージ(例えば、トレーナー人員の介在有りまたは無しの状態で、ユーザとアプリケーション120との間で通信されるメッセージを含む)。
【0084】
ここでは、特定の実施形態は、論理、または多数のコンポーネント、モジュール、機構を含むものとして記述されている。モジュールは、ソフトウェアモジュール(例えば、マシン可読媒体上で、あるいは送信信号にて具現化されるコード)、またはハードウェアモジュールのいずれかを構成してよい。ハードウェアモジュールは、特定の演算を実行できる有形ユニットであり、特定の様式で構成または配列できる。例証的な実施形態では、1個以上のコンピュータシステム(例えばスタンドアロン、クライアント、サーバコンピュータシステム)、あるいはコンピュータシステムの1個以上のハードウェアモジュール(例えば1個のプロセッサ、またはプロセッサのグループ)は、ソフトウェア(例えばアプリケーション、またはアプリケーション部分)によって、ここで述べた特定の演算を実行するべく動作するハードウェアモジュールとして構成されてよい。
【0085】
様々な実施形態では、ハードウェアモジュールは機械的または電子的に実現されてよい。例えば、ハードウェアモジュールは、特定の演算を実行するように、(例えば、フィールドプログラマブルゲートアレイ(FPGA)や特定用途向け集積回路(ASIC)のような専用プロセッサとして)永久的に構成された専用回路または論理を備えてよい。ハードウェアモジュールは、特定の演算を実行するようにソフトウェアによって一時的に構成されるプログラマブルな論理または回路(例えば、汎用プロセッサまたは他のプログラマブルプロセッサ内に含まれるもの)を備えていてもよい。ハードウェアモジュールを、専用の永久的に構成された回路において、あるいは(例えばソフトウェアによって)一時的に構成された回路において、機械的に実現するという決定には、コストおよび時間を考慮することで到達し得ることが理解される。
【0086】
したがって、用語「ハードウェアモジュール」は、有形な実体、つまり、特定の様式で動作するおよび/または特定の演算を実行するように、物理的に構成された、永久的に構成された(例えば実配線された)、または一時的に構成された(例えばプログラムされた)実体を包含するようのと理解されるべきである。ハードウェアモジュールが一時的に構成された(例えばプログラムされた)実施形態を考慮した場合、各ハードウェアモジュールをいかなる時においても構成またはインスタンス化する必要はない。例えば、ハードウェアモジュールが、ソフトウェアを用いて構成された汎用プロセッサを備えている場合に、汎用プロセッサを、異なる時において、それぞれ異なるハードウェアモジュールとして構成することができる。これに応じ、次にソフトウェアがプロセッサを、例えば或る時には特定のハードウェアモジュールとなるように、また或る時には別のハードウェアモジュールとなるように、構成することができる。
【0087】
ハードウェアモジュールは、他のハードウェアモジュールとの間で情報の提供、および情報の受信を行える。したがって、記載のハードウェアモジュールは通信可能につながれていると考えられる。複数のこうしたハードウェアモジュールが同時に存在する場合には、通信は、ハードウェアモジュールどうしを接続する(例えば適切な回路およびバス上の)信号送信によって達成できる。複数のハードウェアモジュールが異なる時間に構成またはインスタンス化される実施形態では、こうしたハードウェアモジュール間の通信は、例えば、複数のハードウェアモジュールがアクセスできるメモリ構造での情報の記憶と取り出しを介して達成できる。例えば、1個のハードウェアモジュールが演算を実行し、その演算の出力を、通信可能につながれたメモリデバイスに記憶することができる。すると、さらなるハードウェアモジュールが、後にメモリデバイスにアクセスし、この記憶された出力を取り出して処理することができる。ハードウェアモジュールは、入力装置または出力装置との通信を開始し、リソース上で動作する(例えば情報収集を行う)こともできる。
【0088】
ここで記載された例証的な方法の様々な動作は、少なくともその一部が、関連の動作を実行するべく一時的に構成された(例えばソフトウェアにより)または永久的に構成された1個以上のプロセッサによって実行され得る。こうしたプロセッサは、一時的または永久的のどちらの構成であっても、1個以上の動作または機能を実行するように動作する、プロセッサによって実現されるタイプのモジュールとなる。ここで言及しているモジュールは、いくつかの例証的実施形態では、プロセッサによって実現されるモジュールを備えてよい。
【0089】
同様に、ここで記載された方法は、少なくともその一部がプロセッサによって実現されてよい。例えば、方法の動作の少なくともいくつかは、1個以上のプロセッサ、またはプロセッサによって実現されるモジュールにより実行され得る。複数の動作のうちの特定のもののパフォーマンスを、1個のマシン内に常駐しているものだけでなく、多数のマシンに展開された1個以上のプロセッサ間に分散させることができる。この1個以上のプロセッサは、いくつかの例証的実施形態では1つの場所に配置でき(例えば、家庭環境やオフィス環境内に、またはサーバファームとして)、他の実施形態では多数の場所に展開できる。
【0090】
1個以上のプロセッサは、「クラウドコンピューティング」環境内で関連動作のパフォーマンスをサポートするように動作したり、「ソフトウェアアズアサービス」(SaaS)として動作することも可能である。例えば、複数の演算のうち少なくともいくつかをコンピュータグループによって(プロセッサを含んだマシンの例のように)実行でき、これらの演算にはネットワーク経由で(例えばネットワーク120)、および1個以上の適切なインターフェース経由で(例えばAPI)アクセスできるようになっている。
【0091】
例証的な実施形態はデジタル電子回路にて、またはコンピュータハードウェア、ファームウェア、ソフトウェア、あるいはこれらの組み合わせにて実現することができる。例証的な実施形態は、コンピュータプログラム製品を使用して実現できる。このプログラム製品は、例えば情報担体内で、つまり例えばマシン可読媒体内で、プログラマブルプロセッサや1個または複数のコンピュータのようなデータ処理装置によって、またはその動作を制御するために実行される、有形的に具現化されたコンピュータプログラムである。
【0092】
コンピュータプログラムは、コンパイルまたは解釈された言語を含むあらゆるプログラミング言語形式で書くことができ、また、スタンドアロンプログラムとしての形式と、またはモジュール、サブルーチン、あるいはコンピューティング環境での使用に適したその他のユニットとしての形式とを含むあらゆる形式にて展開することができる。コンピュータプログラムは、1つの場所にある、または複数の場所に分散されて通信ネットワークで相互接続された、1個以上のコンピュータ上で実行されるように展開できる。
【0093】
例証的な実施形態では、演算は、入力データ上で動作し出力を生成することで機能を実行するためにコンピュータプログラムを実行中の1個以上のプログラマブルプロセッサによって実行される。方法演算は専用論理回路(例えばFPGAまたはASIC)によっても実行でき、また、例証的な実施形態の装置をこの専用論理回路(例えばFPGAまたはASIC)として実現することができる。
【0094】
計算システムはクライアントとサーバを含むことができる。一般に、クライアントおよびサーバは互いに離れた場所にあり、通信ネットワーク経由で相互作用することが典型的である。クライアントとサーバの関係は、それぞれのコンピュータ上において実行中で、相互に対してクライアント‐サーバ関係を持ったコンピュータプログラムによって生じる。プログラマブル計算システムを展開する実施形態では、ハードウェアアーキテクチャとソフトウェアアーキテクチャの両方を考慮する必要がある点が理解されるだろう。具体的には、特定の機能を、永久的に構成されたハードウェア(例えばASIC)、一時的に構成されたハードウェア(例えばソフトウェアとプログラマブルプロセッサの組み合わせ)、またはこれらの組み合わせのいずれで実現するかは、設計上の選択となる。以下で、様々な例証的な実施形態にて展開できるハードウェア(例えばマシン)とソフトウェアアーキテクチャについて述べる。
【0095】
図19は、本明細書中で述べた任意の1つ以上の技法をマシンに実行させる命令を実行することができるコンピュータシステム1900の例証的な形態をしたマシンのブロック図である。代替的な実施形態では、マシンはスタンドアロンデバイスとして動作するか、または他のマシンに接続(例えばネットワーク接続)されていてよい。ネットワーク経由の展開では、マシンは、サーバ‐クライアントネットワーク環境におけるサーバまたはクライアントマシンの容量内で、または、ピアツーピア(または分散)ネットワーク環境におけるピアマシンとして動作できる。マシンは、パーソナルコンピュータ(PC)、タブレットPC、セットトップボックス(STB)、パーソナルデジタルアシスタント(PDA)、携帯電話(例えばiPhone、またはAndroidオペレーティングシステムを実行中の携帯電話)、ウェブ機器、ネットワークルータ、スイッチまたはブリッジ、あるいは、マシンがとる処置を特定する命令(シーケンシャルまたはその他)を実行できる任意のマシンであってよい。さらに、1個のマシンしか図示されていないが、用語「マシン」は、本明細書中で述べた任意の1つ以上の技法を実行するべく、個々にまたは共同で1組(または複数組)の命令を実行するあらゆるマシン集合体を含むものと取ることができる。
【0096】
例証的なコンピュータシステム1900は、プロセッサ1902(例えば中央処理ユニット(CPU)、グラフィック処理ユニット(GPU)、あるいは両方)、メインメモリ1904、スタティックメモリ1906を含んでおり、これらはバス1908を介して互いに通信する。コンピュータシステム1900はビデオディスプレイユニット1910(例えば、液晶ディスプレイ(LCD)またはブラウン管(CRT))をさらに含むことができる。コンピュータシステム1900はさらに、英数字入力デバイス1912(例えばキーボード)、ユーザインターフェース(UI)ナビゲーション(またはカーソル制御)デバイス1914(例えばマウス)、ディスクドライブユニット1916、信号生成デバイス1918(例えばスピーカ)、ネットワークインターフェースデバイス1920を含む。
【0097】
ディスクドライブユニット1916はマシン可読媒体1922を含む。このマシン可読媒体1922には、本明細書中で述べた任意の1つ以上の技法または機能を具現化する、またはこれらによって利用される1組以上の命令およびデータ構造(例えばソフトウェア)1924が記憶されている。命令1924は、コンピュータシステム1900によって実行されている間、メインメモリ1904内および/またはプロセッサ1902内に完全あるいは少なくとも部分的に常駐することもでき、また、メインメモリ1904とプロセッサ1902はマシン可読媒体の構成要素でもある。命令1924は、スタティックメモリ1906内にも完全または少なくとも部分的に常駐することができる。
【0098】
例証的な実施形態では、マシン可読媒体1922を単一の媒体として示しているが、用語「マシン可読媒体」は、1個以上の命令またはデータ構造を記憶する1個以上の媒体(例えば、集中または分散データベース、および/または、関連するキャッシュならびにサーバ)を含むことができる。用語「マシン可読媒体」はさらに、マシンによって実行される命令を記憶、暗号化、伝達できる、また、本実施形態の任意の1つ以上の技法をマシンに実行させる、また、上記命令によって利用される、あるいはこれと関連したデータ構造を記憶、暗号化、伝達できる、任意の有形媒体を含むようにも解釈される。したがって、用語「マシン可読媒体」は、固体メモリ、光学および磁気媒体を非限定的に含むものとして解釈される。マシン可読媒体の具体例には不揮発性メモリが含まれ、この不揮発メモリは以下を例証の形で含む。すなわち、消去可能プログラマブル読み取り専用メモリ(EPROM)、電気消去可能プログラマブル読み取り専用メモリ(EEPROM)、フラッシュメモリデバイスなどの半導体メモリデバイス;内蔵ハードディスクや取り外し可能ディスクなどの磁気ディスク;光磁気ディスク;コンパクトディスク読み取り専用メモリ(CD-ROM)やデジタル多目的ディスク(またはデジタルビデオディスク)読み取り専用メモリ(DVD-ROM)ディスク。
【0099】
さらに命令1924は、送信媒体を使用して、通信ネットワーク1926経由で送受信することができる。命令1924は、ネットワークインターフェースデバイス1920と、多数の周知の転送プロトコル(例えばHTTP)のうち任意の1つとを使用して送信することができる。通信ネットワークの例には、LAN、WAN、インターネット、携帯電話網、POTSネットワーク、無線データ網(例えばWiFiおよびWiMax網)が含まれる。用語「送信媒体」は、マシンによって実行される命令を記憶、暗号化、伝達でき、デジタルまたはアナログ通信信号を含むあらゆる無形媒体を含む、あるいは、こうしたソフトウェアの通信を促進するその他の無形媒体を含むものと解釈される。ネットワーク1926はネットワーク120のうちの1つであってよい。
【0100】
特定の例証的実施形態を参照して実施形態を説明したが、本開示の幅広い範囲から逸脱しない限り、種々の修正、変更が可能であることが当業者には明白であろう。したがって、本明細書および図面は限定的な意味ではなく、例示的な意味において考慮されるべきである。その一部を形成する添付の図面は、本発明の主題を実践できる特定の実施形態を非限定的な例示の方法で示している。例示された実施形態は、ここで開示された示唆を当業者が実践できるように、十分詳細に説明されている。これらの実施形態から他の実施形態を利用および導出でき、したがって本開示の範囲から逸脱しない限り、構造的および論理的な代用と変更が可能である。したがって、この詳細な説明は限定的な意味に解釈されるべきではなく、様々な実施形態の範囲は添付の請求項、ならびにこれらの請求項に権利が与えられる全範囲の同等物によってのみ定義される。
【0101】
本発明の主題のこうした実施形態は、ここでは、単に便宜的理由から用語「発明」によって、また、2つ以上の開示が存在する場合には、本出願の範囲を任意の1つの発明または発明的概念に故意に限定することを意図せず、個別的および/または集合的に言及される。したがって、ここまで特定の実施形態を例示および説明したが、同一の目的を達成できると推定された任意の配置が、ここで示した特定の実施形態の代用となり得ることが理解されるべきである。本開示は、種々の実施形態の任意および全ての改造または応用をカバーすることを意図する。ここでは、上述した実施形態と、本明細書で詳細に説明していないその他の実施形態との組み合わせが、上述の説明を再検討することで当業者に明白となるだろう。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19