特開 2022-101641 ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022101641

(43)【公開日】2022-07-06

(54)【発明の名称】ウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体

(51)【国際特許分類】

   G16H 50/30 20180101AFI20220629BHJP

【ＦＩ】

G16H50/30

【審査請求】有

【請求項の数】1

【出願形態】ＯＬ

(21)【出願番号】P 2022070102

(22)【出願日】2022-04-21

(62)【分割の表示】P 2020018984の分割

【原出願日】2012-09-14

(31)【優先権主張番号】61/534,855

(32)【優先日】2011-09-14

(33)【優先権主張国・地域又は機関】US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＡＮＤＲＯＩＤ

２．ｉＰｈｏｎｅ

(71)【出願人】

【識別番号】514063869

【氏名又は名称】ヌーム インコーポレイテッド

【氏名又は名称原語表記】ＮＯＯＭ，ＩＮＣ．

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】ペタコフ、アルチェム

(72)【発明者】

【氏名】サイモン、マーク

(72)【発明者】

【氏名】グンナション、ケティル

(72)【発明者】

【氏名】リン、チョウ

(72)【発明者】

【氏名】シャフラノヴィッチ、ゲンナディ

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA15

(57)【要約】      （修正有）

【課題】ウェルネスタスクの完了を促進するウェルネスタスクの生成、表示、追跡に係るシステム、方法及び非一時的なマシン可読媒体を提供する。
【解決手段】プログラム順守をユーザに維持させる方法３００において、ユーザの健康に関連した目標を決定するステップ、目標成就に向けたユーザの進捗度を決定するために収集する情報を識別するステップ、情報の一部を提供するようユーザに催促する特定度レベルを選択するステップ及び情報の一部を提供するよう特定度レベルでユーザに催促するステップを備える。
【選択図】図３

【特許請求の範囲】

【請求項1】

システムであって、
１個以上のコンピュータプロセッサと、
１個以上のコンピュータメモリと、
ユーザが健康目標の完了に向けて当該ユーザの進捗のモニタリングを担当するトレーナー人員と通信できるように構成された第１のユーザインターフェースと、
前記トレーナー人員が、前記ユーザからの要求に応答して、ユーザ用の１組のタスクを変更できるように構成された第２のユーザインターフェースと、
前記１個以上のコンピュータメモリに保存された１組の命令と、を備え、前記１組の命令は、前記１個以上のコンピュータプロセッサが複数の処理を実行するように構成されており、前記複数の処理は、
前記ユーザ用の１組のタスクを決定するステップであって、前記１組のタスクは、前記健康目標に関連する１つ以上の固定タスクを含み、前記１つ以上の固定タスクの少なくとも１つが当該健康目標に関連するユーザから基礎情報の収集に関連する、前記ユーザ用の１組のタスクを決定するステップと、
前記１つ以上の固定タスクのうち、ある固定タスクをスマートタスクに入れ替えるか否かを決定する１組のスマートタスクトリガを繰り返すステップであって、該スマートタスクが、当該ユーザの健康目標に関連する追加情報の提供を当該ユーザに促すことを含み、前記追加情報が、前記健康目標の完遂に向けた当該ユーザの進捗に関連し、前記スマートタスクトリガが、事前にユーザから取得されなかった特定の情報に関連する、前記１組のスマートタスクトリガを繰り返すステップと、
前記特定の情報を提供するようにユーザに促すステップと、
前記特定の情報に基づいて、前記健康目標を達成するためのユーザの進捗度と、前記１組のタスクに対するユーザの順守の程度とを更新するステップと、
前記第１のユーザインターフェースを介して前記ユーザからの要求を受け取るステップであって、前記要求は前記トレーナー人員が前記１組のタスクを変更することを要求することである、前記ユーザからの要求を受け取るステップと、
前記第２のユーザインターフェースを介して前記トレーナー人員から受け取った入力に基づく前記要求に応答して前記１組のタスクの変更を実行するステップと、
を備える、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はウェルネスタスクの生成、表示、追跡に係るシステム、方法、非一時的なマシン可読媒体に関する。

【背景技術】

【0002】

最新の健康またはウェルネスプログラムのほぼ全てに伴う最たる難題の１つは、その順守である。これは、特定の症状向けの医薬品の服用から、体重減量、筋肉増強、健康的なライフスタイルなどといったこれよりも遥かに抽象的なウェルネス目標までの、継続的な努力を要する全てのプログラムに該当する。

【発明の概要】

【発明が解決しようとする課題】

【0003】

順守は、特定の健康またはウェルネス目標の達成方法が複数存在する場合には特に困難となり、優柔不断さと迷いによって順守および最終成果が大幅に低下する。プログラムは日誌または日記のメタファに注目したものであってよい。このようなプログラムでは、ユーザは現実世界で行うことを単純に「記録する」（例えば、書き留める）だけでよい。システムは、ユーザが記録されたパターンを考察し、記録されたパターンに基づいて行動変容を行うための補助となるグラフや表を生成および提示することができるあるいはシステムは、例えば医師や医学療法士にかかった後に受け取ることが通例の処方箋と同様に、「カスタマイズされたプログラム」として機能することが可能である。

【課題を解決するための手段】

【0004】

本明細書では、システムはユーザに関する情報を受信し、この情報に基づいて、カスタムプログラムを作成しユーザに従わせ、またはユーザに1セットのカスタムプログラムの中から１つを選択させることができる。これらのシステムの典型例には様々な制限がある。例えば、こうしたシステムはユーザにはロボット的または代用的に映る可能性がある。

【図面の簡単な説明】

【0005】

【図1】様々な例証的実施形態を展開できるクライアント-サーバシステムを示すネットワーク図である。

【図2】図２は、パーソナルトレーナーの抽象体を実現するように構成された、図１のアプリケーション１２０の例証的なモジュールの示すブロック図である。

【図3】プログラム順守をユーザに維持させる方法の例証的な実施形態を示すフローチャートである。

【図4】ユーザにプログラム順守を維持させる方法４００の例証的な実施形態を示すフローチャートである。

【図5】自動目標生成と人間による目標生成とにおける、クライアントとサーバ間の例証的な相互作用を示す相互作用図である。

【図6】タスクベースのインターネット健康プログラムを実現するべく構成されたアプリケーション１２０の例証的な流れを示すブロック図である。

【図7】ユーザの健康プログラムに関連した情報をユーザに提示するための例証的なユーザインターフェースを示すスクリーンショットである。

【図8】何を食べたかについての詳細な情報を提供するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。

【図9】何を食べたかについての要約した情報を提供するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。

【図10】ユーザの運動活動に関する情報を入力するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。

【図11】ワークアウトに関する情報を集めるための例証的なユーザインターフェースを示すスクリーンショットである。

【図12】ユーザに運動タスクを提示して、このタスクを完了したかどうかをユーザに明示させるための例証的なユーザインターフェースを示すスクリーンショットである。

【図13】ユーザに小記事を提示するための例証的なユーザインターフェースを示すスクリーンショットである。

【図14】今後、タスクの実行に専念するようユーザに促すための例証的なユーザインターフェースを示すスクリーンショットである。

【図15】図１のアプリケーションにアクセスしているユーザのコンテキストの外にウィジェットを展開させた例証的なユーザインターフェースを示すスクリーンショットである。

【図16】ユーザがトレーナー人員と直接通信できるようにするための例証的なユーザインターフェースを示すスクリーンショットである。

【図17】ユーザがトレーナー人員と通信できるようにするための例証的なユーザインターフェースを示すスクリーンショットである。

【図18】図１のアプリケーションが使用するデータベースのテーブル間の例証的な関係を示すブロック図である。

【図19】本明細書中で述べた任意の１つ以上の技法をマシンに実行させる命令を実行することができるコンピュータシステムの例証的な形態をしたマシンのブロック図である。

【発明を実施するための形態】

【0006】

これ以降、説明の目的で、本発明の主題の様々な実施形態を理解するために多くの特定の詳細について述べる。しかし当業者には、これら特定の詳細がなくても様々な実施形態を実施できることが明白になるだろう。

【0007】

様々な実施形態では、パーソナルトレーナー（またはコーチ）の抽象体を提供する方法およびシステムを提供しており、ユーザは適切な指示を適時に、ユーザをプログラムに従わせるための適切な応援と共に受けることができる。プログラムは途中で調整することが可能である。これにより、ユーザのプログラム順守とプログラムの最終的な成功との両方が向上する。

【0008】

様々な実施形態では、ウェルネスタスクの完了を促進する方法およびシステムを開示している。まず、ユーザの健康に関連した目標が決定される。ユーザのゴール完遂に向けた進捗を決定するために収集される情報が識別される。この情報の一部を提供するようユーザに促す特定度レベルが選択される。ユーザは、情報の一部の提供をこの決定された特定度レベルで催促される。目標完遂に向けたユーザの進捗度は、この情報の一部に基づいて決定される。

【0009】

本明細書で開示する方法および様々な実施形態は、１個以上のモジュール（例えばハードウェアモジュールまたはソフトウェアモジュール）を実装したコンピュータシステムとして実現することができる。本明細書で開示する方法および様々な実施形態は、マシン可読媒体に記憶された命令として具現化されてよく、この命令はプロセッサにより実行されるとプロセッサに上記方法を実行させる。

【0010】

図１はクライアントサーバシステム１００を示すネットワーク図であり、このシステムにおいて様々な例証的な実施例を展開することができる。ネットワークシステム１０２は１個以上のクライアントに対して、サーバサイド機能を、ネットワーク１０４（例えば、インターネットまたはワイドエリアネットワーク（ＷＡＮ））経由で提供する。図１は例えば、クライアントマシン１１０、１１２上で実行する、ウェブクライアント１０６（例えば、ワシントン州レッドモンドにあるマイクロソフト社（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）が開発したインターネットエクスプローラブラウザなどのブラウザ）と、プログラマチッククライアント１０８（例えばＡｎｄｒｏｉｄまたはｉＰｈｏｎｅアプリケーション）を示す。

【0011】

ＡＰＩサーバ１１４およびウェブサーバ１１６は１個以上のアプリケーションサーバ１１８につながれ、このアプリケーションサーバに対しプログラマチックインターフェースとウェブインターフェースをそれぞれ提供する。アプリケーションサーバ１１８は１個以上のアプリケーション１２０をホストする。同図中、次に、１個以上のデータベースまたはＮｏＳＱＬあるいはノンリレーショナル・データストア１２６へのアクセスを容易化するために、アプリケーションサーバ１１８が１個以上のデータベースサーバ１２４につながれて示されている。

【0012】

図１に示すシステム１００はクライアントサーバ構築を採用しているが、当然ながら様々な実施形態はこのようなアーキテクチャに限定されず、例えば分散またはピアツーピア型のアーキテクチャシステムにも同様に上手く応用される。様々なアプリケーション１２０は、必ずしもネットワーク機能を持たないスタンドアロンソフトウェアプログラムとして実現することも可能である。さらに、図１は、マシン１３０、１１０、１１２を１つのネットワークシステム１０２につないだ状態を示しているが、マシン１３０、１１０、１１２、ならびにアプリケーション１２８、１０６、１０８を複数のネットワークシステムにつなぐことも可能であることが当業者には容易に明白となるだろう。例えば、アプリケーション１２８、１０６、１０８を、複数の支払いプロセッサ（例えばビサ、マスターカード、アメリカンエクスプレス）に関連付けされた複数の支払いアプリケーションにつなぐことができる。

【0013】

ウェブクライアント１０６は、ウェブサーバ１１６によってサポートされたウェブインターフェース経由でアプリケーション１２０にアクセスする。同様に、プログラマチッククライアント１０８は、アプリケーション１２０が提供する様々なサービスおよび機能に、ＡＰＩサーバ１１４によって提供されたプログラマチックインターフェース経由でアクセスする。クライアントまたはサーバを実行できるマシンの例証的なアーキテクチャを図１９に関連して説明する。

【0014】

様々な実施形態では、ウェブサーバ１１６はアパッチウェブサーバであり、データベースサーバ１２４はＭｙＳＱＬリレーショナルデータベース管理システム（ＲＤＭＳ）である。

【0015】

以降で詳述するように、様々な実施形態では、クライアントはタスクベースのユーザインターフェースをユーザに提示し、クライアントセンサを介して黙示的に、またはデータ入力から明示的にデータを収集し、記事やチャレンジなどをユーザに表示する。Ａｎｄｒｏｉｄ携帯電話上で実行中のクライアントなどのいくつかのクライアントは、サーバ（例えばＡＰＩサーバ１１４）に情報をクライアントへプッシュさせるプッシュ技術を実現することができる。このプッシュ機能は、１個以上のアプリケーション（例えばアプリケーション１２０）が、クライアント（例えばクライアント１２８、１０６、１０８）に新規のまたは更新されたタスクを通知するために使用することができる。別のクライアント上では、この通知を、メモリ常駐型プログラムによるポーリングによって実現できる。クライアントは、収集したデータをバックアップおよび分析の目的でサーバに送る。サーバ上で実行中のアプリケーション（例えばアプリケーション１２０）は、データの分析、バックアップ、およびタスク生成を扱うことができる。ユーザとの相互作用に基づいて効率的で精選された1組のタスクを正確な順序で生成することは、複雑な工程であり得る。

【0016】

図２は、パーソナルトレーナーの抽象体を実現するように構成されたアプリケーション１２０の例証的なモジュールを示すブロック図である。
プレゼンテーションモジュール２０２は、1組の毎日のタスクをユーザに提示する。様々な実施形態において、これらのタスクは、図７に示すようなタスクホイール上にグラフィック表示される。

【0017】

採点モジュール２０４は、ユーザがこれらタスクの各々の完了に向けて進捗すると採点を行う。採点モジュール２０４は、各タスクの状態をホイール上に示すことができる。
収集モジュール２０６は、ユーザがどのような目標（1個以上）を達成しようとしているかの情報など（例えば体重減量、背中の痛みの軽減など）、ユーザに関する情報を収集する。このような情報は、ユーザが手動または自動記録を介して明示的または黙示的に提供した情報から収集される。収集モジュール２０６は、ユーザから経時的にデータを収集し、このユーザから取得したデータに基づいてタスクの調整を行う。したがって、プログラムは、プログラム開始時にユーザから受信した情報だけでなく、さらにプログラムに参加したユーザからの情報に基づいてカスタマイズされる。

【0018】

選択モジュール２０８は、ユーザの１日のタスクの最良の1組を、コーチが受信したユーザに関する情報に基づいて選択する。選択アルゴリズムは、ユーザにプログラムを最大限順守させつつ目標に到達させられる最良のタスク数の決定に基づいて、タスク数を制限することができる（例えば１日に８～１０タスク）。この決定は、収集モジュール２０６から受信した、ユーザの目標と、提案されたタスクの完遂履歴とに関する情報に基づいてよい。以下で、選択アルゴリズムについて詳述する。

【0019】

通信モジュール２１０は（例えば、ユーザとパーソナルトレーナーの相互作用をシミュレートするために）ユーザと通信する。例えば、通信モジュール２１０は、ユーザのタスク完了または目標到達への進捗度を示すメッセージを送信することができる。あるいは、通信モジュール２１０は、選択モジュール２０６がユーザに実行させる特定のタスクを選択した理由を１つ以上記載したメッセージを送信できる。様々な実施形態で、通信モジュール２１０はユーザへのメッセージを自動送信する（例えば、実際の人物が入力を行う作業を組み込まない）。別の実施形態では、通信モジュール２１０は、実際の人物からのメッセージを組み込む、または実際の人物がメッセージをユーザに直接送信する。

【0020】

通信モジュール２１０は、実際の人物からの入力をどの程度組み込むかを、様々な要因に基づいて決定する。例えば、通信モジュール２１０は、実際の人間からの入力を受け取りたいと言うユーザからの要求を、実際の人物から提供可能なこうした入力の供給によって、（例えば要望に基づいて）バランスを取っている。様々な実施形態にて、通信モジュール２１０は、ユーザが、ユーザ順守を向上させるのに必要な程度の人間どうしの相互作用を受けられるようにするのにちょうど十分な程度の実際の人物からの入力を、配備された人間で賄える上記レベルの人間どうしの相互作用を超えない範囲で、ユーザとの通信に組み込む。したがって、様々な実施形態において通信モジュール２１０は、通信がロボット的または柔軟性に欠けるもののようにユーザに映らず、さらに常に人間どうしの相互作用が必要にならないレベルの自動化度でユーザと通信することができる。

【0021】

図３は、プログラム順守をユーザに維持させる方法３００の例証的な実施形態を示す。様々な実施形態にて、方法３００はアプリケーション１２０によって実現できる。演算３０２は、収集モジュール２０６が、ユーザの健康に関連した目標を決定する。演算３０４では、収集モジュール２０６が、目標完遂に向けたユーザの進捗を判断するために収集すべき情報の識別を行う。収集モジュール２０６は、ユーザから経時的にデータを収集し、ユーザについて取得したデータに基づいてタスクを調整する（例えば、選択モジュール２０８によって選択する）ことができる。言い換えれば、プログラムは、その開始時にユーザについて収集したあらゆるデータと、さらにプログラムの寿命にわたって収集したデータとに基づいてカスタマイズされ得る。

【0022】

選択モジュール２０８は、目標までの過程で多数の（例えば数百または数千）異なるタスクを生成するか、またはその中から選択することができる。しかし、選択モジュール２０８は、これらタスクのサブセットをユーザに対して所与の期間しか提示できない。例えば、選択モジュール２０８は１日に８～１０個のタスクしかユーザに提示できない。選択モジュール２０８は、どのタスクおよびタスク順序がユーザのプログラム順守を最も高めるかについての選択モジュール２０８の決定に基づいて、ユーザに提示する一連のタスクを選択および決定する。

【0023】

選択モジュール２０８は、様々な異なるタスクを実行するようユーザに「請う」（例えばユーザインターフェース経由）上で優れた柔軟性を持ってよい。これらのタスクには様々な種類がある。例えば、タスクは明示的データ収集タスク、手動記録タスク、自動追跡タスク、小記事を読むタスク、ミニチャレンジタスク、スケジューリング／今後の約束タスクであってよい。選択モジュール２０８は、これらのタイプならびにその他のタイプのタスクを生成または選択するように構成されてよい。

【0024】

明示的データ収集タスク：最も単純なタイプのタスクの１つ。このタスクはユーザに１つまたは１組の明示的な質問をする。これは、外部ツールまたはセンサ（例えば体重計やグルコース計）からの測定値についての質問、ユーザの過去の行動についての質問、ユーザの特定タスクの嗜好についての行動、またはその他のあらゆる一般的な質問であってよい。質問は多肢選択式、自由入力式、またはこれらあるいはその他形式の組み合わせであってよい。

【0025】

手動記録タスク：このタスクはデータ収集タスクと多少似ているが、より全般的／無向性のデータ収集機構を要する点が異なる。その１例は、朝食、昼食、夕食の非常に詳細なログを残すようユーザに要請するというものである。これらのタスクでは、ユーザは多くの情報を収集しなければならず、多大な労力が掛かるにもかかわらず、後にアプリケーション１２０が使用する情報はほんのいくつかである。ユーザが全てを記録するよう要求する代わりに、選択モジュール２０８が特定の場合にのみ記録をつけるようにユーザに要請するタスクを選択できる。さらに、選択モジュール２０８は、例えば、ユーザの目標到達に向けた進捗度を判断する上で、または、ユーザにプログラム順守を維持させつつ目標到達を最も補助すると考えられる追加のタスクを選択するべくタスクを生成する上で、アプリケーション１２０を最も支援する情報に基づいて、様々な詳細レベルの情報を提供するようユーザに要請するタスクを選択できる。例えば、選択モジュール２０８は、詳細な記録を伴うタスクを週１回選択してもよい。週のこれ以外の日には、選択モジュール２０８は、ユーザ行動（または習慣）、あるいはデータまたは変数（例えば、収集モジュール２０６が黙示的に収集したデータ）に基づいて詳細な記録を推測することができる。

【0026】

食事ログ作成タスクを使用して、関連概念を例示することができる。選択モジュール２０８は、まず、選択モジュール２０８が持っていない、ユーザが特に何を食べているのかについての情報に基づいて詳細なログ作成レベルのタスクを選択しておき、後々、減量の支援に適した食品を選択できるようにすることが可能である。選択モジュール２０８がこの詳細なログ作成レベルのタスクをひと月に選択するのは、ユーザにどのような提言をすればよいかを知るのに十分な数回のみでよい。図８は、選択モジュール２０６がユーザにこの詳細な情報を要請することができる例証的なユーザインターフェースを示す。

【0027】

これ以外の時においては、選択モジュール２０８はそれほど詳細でないログ作成レベルのタスクを選択してよい。例えば、選択モジュール２０８は、食べている料理の大まかな食品品質をユーザに提供させるタスクを選択できる。図９は、収集モジュール２０６がこの詳細度の低い情報の提供をユーザに要請することができる例証的なユーザインターフェースを示す。選択モジュール２０８は、ユーザの重荷になることなくしっかりとした食事を奨励できるので、この詳細度の低いタイプの記録を頻繁に選択してよい。選択モジュール２０８は、目標完遂に向けたユーザの進捗に関するデータの空白を、ユーザについて収集した様々な追加情報（体重など）に基づいて埋めることができる。例えば、選択モジュール２０８は、ユーザの変化のない体重に基づいて、ユーザの食事療法が変更されていないと判断することができる。あるいは、ユーザの体重の変動に基づいて、ユーザの食事療法が変更されたと判断することができる。この場合、ユーザの体重が変動していれば、選択モジュール２０８はより詳細な記録タスクを選択してユーザに実行させるか、あるいはユーザに記録タスクの完了を要請する頻度を上げることができる。

【0028】

運動ログ作成タスクを使用して、詳細レベルの異なる、運動に関連する記録タスクの選択を例示することもできる。例えば、図１０は、収集モジュール２０６に（例えば手動でのログ記録によって）ユーザの運動に関する詳細な情報または詳細でない情報を収集させる例証的なユーザインターフェースを示す。

【0029】

自動追跡タスク：このタスクは記録タスクと似ているが、ユーザがデータを明示的に入力する必要がなく、代わりに、ユーザに関連したデバイス上で利用可能な１個以上の外部センサからの測定値に依存している点が異なる。例えば、この実施形態では、携帯電話上で実行中の「１０分間歩行」タスクが、電話の加速度計およびＧＰＳセンサを使用し、これらが測定した値を組み合わせてより正確な（また、ＧＰＳ信号が途絶えた時には信頼性の高い）測定値を得る（図１１参照）。運動のタイプがダンスの場合は、電話は加速度計のみを別モードで使用する。いくつかの自動追跡タスクでは、絶えず追跡を行っているのでユーザが追跡を開始する必要さえない。これらは最も望ましい目標のうちのいくつかである。省電力タイプの歩数計を使用して常に歩数を監視することができる。

【0030】

小記事を読むタスク：このタスクは、目標達成に関連した特定テーマの知識をユーザに与える。例えば、減量を試みている人の場合、これは「ダイエットソーダの危険性」という記事であってよい。様々な実施形態で、他のタスク（例えば記録タスク）へのユーザフィードバックに基づいてトリガされる。小記事タスクは、テキスト文書と「読み終えました」ボタンとをユーザに提示する（図１３参照）。別の実施形態では、本発明は、ユーザが記事を読み終えるとミニテストを提示する。

【0031】

ミニチャレンジタスク：小記事タスクと類似するが、このタスクはユーザに特定の行為を行うよう要請する。例えば、「エレベータではなく階段を使いましょう」である（図１２参照）。一実施形態では、これらのタスクは、他のタスク（例えば記録タスクまたは明示的データ収集タスク）に提供されたフィードバックに基づいてトリガされる。ミニチャレンジタスクはユーザにチャレンジの内容の説明と「実行しました」ボタンを提示する。別の実施形態では、本発明は、タスク完了を追跡する自動追跡機能を使用する。

【0032】

スケジューリング／今後の約束タスク：このタスクはユーザに、今後の計画を立てる、または単純に、今後、特定の目標に専念するように要請する。「プレコミットメント」とは、達成がずっと先に思えるタスクに人々を専念させるための（例えば、翌朝起きるのが大変そうでも夜目覚まし時計をセットするのと同じである）、強力な行動修正技術である。

【0033】

このようなタスクの一例は「食料品買い出し日」である。収集モジュール２０６が、何日に食料品の買い出しに行けるかをユーザに聞き、次に、選択モジュール２０８が、ユーザの返答に基づいて「健康な食料品買い出し」目標を適切な日にスケジュールする。

【0034】

別の例に、以後予定される従うべき運動スケジュールに専念するようユーザに要請する「運動スケジュールの設定」目標（図１４参照）がある。スケジューリング後、また、ユーザが過去にコミットメントを守れなかったことがある場合には、選択モジュール２０８が、ユーザの今後の目標に対する意欲を再確認するために、別のコミットメント目標をスケジュールする。

【0035】

再び図３を参照すると、演算３０６で、選択モジュール２０８が、情報の一部を提供するよう（例えば収集モジュール２０６を介して）ユーザに催促するための特定度レベルを選択する。上述したように、特定度レベルは、タスク完了に向けたユーザの進捗度に関して選択モジュール２０８が（例えば、追加データの黙示的または明示的な収集から）得られなかった情報に基づいてよい。

【0036】

演算３０８で、収集モジュール２０６が、情報の一部を提供するよう、この特定度レベルでユーザに（例えばユーザインターフェース経由で）催促する。
図４は、ユーザにプログラム順守を維持させる方法４００の例証的な実施形態を示す。演算４０２で、選択モジュール２０８が、ユーザの目標に基づいて複数のタスクを生成する。演算４０４で、通信モジュール２１０が、複数のタスクのうちの、或るタイプを持った１つのタスクを完了するようユーザに提言する。演算４０６で、選択モジュール２０８が、さらに或るタイプを持った追加のタスクに基づいて、上記複数のタスクの中から追加のタスクを選択する。演算４０８で、通信モジュール２１０が、この追加のタスクを完了するようユーザに提言する。こうすることで、アプリケーション１２０は、所与の時間内に実行する多様なタイプのタスクをユーザに提案することができ、これによりユーザのプログラム順守が強化される。

【0037】

本発明は、多様なタスクタイプの生成およびユーザへの提示に加えて、ユーザが各タスクを完了するごとに点数を与える。的確な得点方法こそ行動パターンの変容に重要であるかもしれない。

【0038】

様々な実施形態では、採点モジュール２０４は最高で１００点の中から得点を使用するが、この得点は毎日０にリセットされる。ユーザは各タスクを完了する毎に、１００点の分割点数を獲得する。ユーザは、全てのタスクを完了すると１００点を獲得する。各タスクに割り当てられた１００点の分割点数は、ユーザが望む目標／結果の達成におけるそのタスクの重要性を表し得る。例えば、ユーザの目標が減量である場合には、全得点のうちで食事療法関連の目標が運動関連の目標よりも大きな割合を占め、これにより食事療法タスクの完遂がより重要であるという見識をユーザに与えることができる。

【0039】

ユーザは全得点を獲得した時点で１日を終了できるが、この終了状態をユーザに明確に示すことができる。言い換えれば、ユーザは可能な限りの達成ではなく（例えば、食品または運動と同量の記録をこなすことが可能であっても）、特定の１組のタスクだけ完了することを奨励される。こうして、採点モジュール２０４は、ユーザが短期間のうちに熱中し過ぎることによる「過剰実行」の犠牲になり得ることを考慮に入れている。しかし、採点モジュール２０４は、妥当な範囲内で、割り当てられたタスク以上をこなすことを許可できる。具体的には、採点モジュール２０４は、ユーザが実行を選ぶかもしれない追加タスクのために２０点を余分に用意しておくことができる。

【0040】

特定の１つのメトリック（例えば燃焼カロリー量）の周辺でユーザにモチベーションを持たせることは、所望の目標を達成する上でユーザに求められる広範囲の行動や、１つのメトリックを達成する上で他の人々が感じるであろう困難を反映しないので、その代わりに、採点モジュール２０４は、得点を努力の面から個人間で比較できるようにしている。

【0041】

採点モジュール２０４は、個人の毎日の得点を加算して組み合わせ、週間得点および総得点とすることができる。これにより、ユーザは目標に向けた長期間の進捗を目で確認し、計れるので、さらに長期的に継続するモチベーションを持つことができる。

【0042】

アプリケーション１２０の様々な実施形態は、採点機構の他にも様々な機構を使用して、指定されたタスクを完了するようユーザを奨励する。
図１５は、ウィジェットを含んだユーザインターフェース１５００の例証的な実施形態のスクリーンショットを示す。ウィジェットは、ユーザがアプリケーション１２０にアクセスしていない時でもユーザに提示される毎日の得点の小型化された表示であり（例えば、モバイルデバイス上のクライアントアプリケーション経由で提示される）、これにより、ユーザは得点をより頻繁に確認するよう奨励され、その結果、順守性が向上する。この実施形態では、ウィジェットはＡｎｄｒｏｉｄウィジェットとして実現されているが、得点を小型化して、通常のクライアントアプリケーションの外部にユーザに示せることができさえすれば、インフレーム、またはその他のＨＴＭＬ５実現におけるＲＰＣ方法などのあらゆる埋め込み技術を用いて実現することが可能である。

【0043】

さらに、様々な実施形態では、アプリケーション１２０は各種の機構を使用して、ユーザにソーシャルプレッシャー（訳注：オンライン上の世間の目による圧力）を掛ける。例えば、通信モジュール２１０は、ユーザにサポータ（または「相棒」）を指定させることができ、サポータは、ユーザが完了すべきタスクを受け取る度、ならびにタスクを完了する度に通知を受ける。通知の頻度は、毎時から毎月の間でサポータがカスタマイズできる。相棒は、心理的サポートと、プログラムへの実際のサポート（例えば、健康的な食事を料理する、一緒に散歩に行くなど）の両方を提供できる親しい友人または配偶者であってよい。

【0044】

別の例として、通信モジュール２１０はアプリケーション１２０をインターネット自助グループと統合することができる。このインターネット自助グループは、共通の目標や人口統計学的特徴に基づいてグループ化されたユーザの小規模グループであってよい（例えば、１０～２０ポンド（約４．５～９ｋｇ）の減量を望む、４０歳以上の女性だけのグループ）。ユーザの許可があれば、こうしたグループは、特定ユーザの毎日、毎週、総合の得点、さらにそのユーザに割り当てられたタスクと完了したタスクとの全てにアクセスすることも可能である。このグループは、従来のサポートグループと同様に、順守を奨励するためのさらなる友好的圧力、ならびに個人の経験からのアドバイスを提供することができる。ユーザはグループフォーラムにアクセスし、全員が互いに通信し合うことができる。通信モジュール２１０によりクライアントアプリケーション経由で提示されたユーザインターフェースでは、各メンバーの横に毎日、毎週、総合の得点を表示し、これらの得点をグループメンバーの「ステータスシンボル」にしてもよい。

【0045】

様々な実施形態において、採点モジュール２０４は、「長期的な」順守を奨励するために１組のゲームメカニクスを組み込むことが可能である。一実施形態では、このようなメカニクスはレベルシステムを含むことができる。このレベルシステムでは、各ユーザはレベル１から開始し、週毎に、１日の平均獲得点数が８０点以上であればレベルが１つ上がり、週毎に獲得点数が５０～８０点であればレベルは変更されず、週毎に５０以下であればレベルが１つ下がる。さらに、ユーザは、平均得点が９０点以上になった週には「バッジ」を獲得する。バッジはいかなる状況でも失われない。他の実施形態は、その他のレベルおよびバッジについての計算式を含むことができる。レベルとバッジの両方は、ユーザおよび様々なタイプのサポータに対して目立つように表示される。

【0046】

様々な実施形態において、採点モジュール２０４は、長期間にわたってタスクを順守した見返りとしてユーザ外部からの賞品を与えることで、モチベーションを向上させることができる。こうした賞品は、特定タイプのタスクを満たした場合や、所定期間で１組のタスクを達成した場合（例えば、この５日間に全ての目標）に受けられる、スポンサーからのオファー（例えば、５つのランニングタスクを続けて実行すると、ナイキの靴の割引）を含む。タスクインフラストラクチャは柔軟であるので、採点モジュール２０４は、広告提供パートナーが要求する特定の行動へのやる気を起させ、次に、この行動を達成したユーザに賞品を与えることができ、これは全てタスク順守の自然なコンテキストに含まれる。

【0047】

様々な実施形態において、タスク生成方法（例えば、選択モジュール２０８を介して生成する方法）は、特定の実施形態が示唆しようとしている健康目標に基づいていてよい。次の例は体重減量目標に関連するが、これと同一の方法および原理は他の目標にも適用できる。

【0048】

様々な実施形態において、選択モジュール２０８は、固定タスクと、条件付きの「スマート」タスクとの組み合わせを用いて、フルセットのタスクをユーザに生成する。最初は、選択モジュール２０８はユーザに関する情報を全く知得していない可能性があるので、ユーザから基礎情報を（例えば、収集モジュール２０６を介して）収集するための１組の固定の強化タスクを割り当てることができる。システムがユーザについて学習するにつれ、選択モジュール２０８は、スマートタスクが固定タスクから引き継ぎ、残りのコーチングプログラムにわたってユーザを誘導できるようにする。「スマート」タスクは、特定の条件が正である場合にしか生成されないタスクである。スマートタスクの平凡な例は、過去の約束のためにスケジュールされるタスクである。例えば、ある人物が毎週金曜日に買い物に行くと約束した場合、本発明が毎週金曜日に「健康的な食料品買い出し」目標を生成する。スマートタスクを生成するためには、選択モジュール２０８が１組のスマートタスクトリガを繰り返し、そのスマートタスクをスケジュールすべきかどうかを決定する。

【0049】

初期ブートストラップ固定タスクシーケンスは、後述のように様々なタスクを含むことができる。しかし、特定のタスクはそれぞれ大幅に変更できることが当業者には明らかであろう。

【0050】

１日目
１：コーチの紹介記事を読みましょう（記事タスク）。
２：あなたとあなたのウェルネス目標についての質問表に記入しましょう（明示的データ収集タスク）。

【0051】

３：食事記録を使って昼食を詳細に記録しましょう（記録タスク。図３参照）。
４：ミニチャレンジ：今日は階段を使いましょう。階段がどこにもない場合や、時間が遅い場合には、今すぐジャンピングジャックを２０回行ってください（ミニチャレンジタスク）。

【0052】

２日目
１：今日は、油を使って調理していない５種類の野菜を食べましょう（ミニチャレンジタスク）。

【0053】

２：食品記録を使って夕食のログを残しましょう（記録タスク）。
３：最低限の運動ベースラインに関する記事を読みましょう（記事タスク）。
４：ホーム画面にＮｏｏｍウィジェットをインストールしましょう（ミニチャレンジタスク／モチベーション）。

【0054】

５：５分間ウォーキングに行きましょう（自動追跡タスク）。
３日目
１：あなたの食習慣に関する基礎質問表に記入しましょう（明示的データ収集タスク）。

【0055】

２：１日のおおまかなログを残しましょう（記録タスク）。
３：運動スケジュールを再考しましょう（ミニチャレンジタスク）。
４：食料品買い出しの日をスケジュールしましょう（今後の約束タスク）。

【0056】

条件付きタスクの生成（「スマート」タスク）
３日目以降、選択モジュール２０８がスマート（条件付き）タスクの使用を開始する。別の実施形態では、この時点よりも以前に、より長い固定コーチングシーケンスを設けてもよい。

【0057】

（１）食品記録スマートタスクは、各種食事についての情報を提供するようユーザに促す。このタスクは、直近１０日間に１日３食の食事のうち特定のものの記録が４回未満でないかチェックし、その食事のログを残すように０．３の確率でスケジュールする。

【0058】

（２）食品小記事スマートタスクは、健康的な食品を摂取するようユーザに促す。このスマートタスクは、一月前の食事データをチェックし、その人物が食べた個々の食品全てを、各食品を何回食べたかカウントしながら収集することでこれを行う。次に、タスクはこのカウントに基づいて個々の食品を分類し、リストを反復し、その食品に関する記事をトリガする。その記事が過去にユーザに提示されていれば、リスト中の次の食品を選ぶ。記事が見つかったが場合、０．８の確率でトリガされる。

【0059】

（３）直近３日間のそれぞれの日にユーザが８０点以上を獲得した場合に、おめでとうスマートタスクがトリガされる。タスクがトリガされると、ユーザにおめでとうの言葉をお送り、今後もプログラムを継続するように促す小記事タスクを挿入する。このタスクは特定の確率（例えば０．８）でトリガされる。

【0060】

（４）アンケートスマートタスクは、５個で１組のアンケートを有し、この１組のアンケートはユーザがこの５個のアンケートのうち１個にまだ回答していない場合に、（例えば０．１の確率）ランダムにトリガされる。

【0061】

（５）チャレンジスマートタスクは、各々がランダムにトリガされる（例えば０．２の確率）１組のミニチャレンジを有する。別の実施形態では、これらのミニチャレンジは、アンケート結果を使用して、チャレンジのいくつかを条件付きでトリガすることができる。「５分間歩く」などのいくつかのミニチャレンジには、自動運動追跡が関与している。

【0062】

上述した１組のスマートタスクは明らかに網羅的でなく、各目標に特化し、常に改良開発されている。
タスク生成における自動学習。タスクベースのシステムによって、タスクの割り当ておよびその後の順守と、所望の成果に向けた進捗とに基づく効率的な学習が可能になる。選択モジュール２０８は強化学習（ＲＬ）を使用できる。例えば、選択モジュール２０８は、次の２週間にかけて特定の目標の割り当てが順守レベルに与える影響を計算することができる。これは、グローバルコンプライアンスおよび成果に向けた進捗の近似値としての役割を果たす。別の実施形態では、選択モジュール２０８が、１組の目標（レジメン）の割り当てが成果に与える影響を計算する。

【0063】

別の例では、選択モジュール２０８は、実験的な人員グループに特定の新たな実験的タスクを導入し、このタスクの挿入による影響を制御グループと対比させてモニタリングすることができる。

【0064】

人間による支援を介在させた目標生成およびコーチメッセージング選択モジュール２０８は、上述したように、効率的なオンライン健康プログラムの一部であるタスク生成、記録および追跡を自動化することができる。しかし、本発明はさらに、ユーザが追加のヘルプを必要とする場合、所望の目標に到達する前に平坦域に嵌ってしまった場合、あるいは自動レジメンでは許可されていない機能を必要とする場合などの様々な状況において、人間による相互作用を可能にする。

【0065】

通信モジュール２１０は、人間によるメッセージングや手動タスク調整などの多様な形式での人間による相互作用を可能にする。人間によるメッセージングについては、通信モジュール２１０が、ユーザとサポートコーチ人員の両方が互いにショートメッセージを送信できるようにする（図１６参照）。こうしたメッセージを短く済ませるように設計することが可能であり（例えば２５０文字未満）、これにより、例えばユーザがきちんと構成されていないため処理が難しい情報をシステムに多く供給することを防止できる。例えば、ユーザに関する多くの情報は、収集モジュール２０６により、その目的のためだけに設計された適切な明示的データ収集タスクを介して収集される。

【0066】

手動タスク調整については、選択モジュール２０８が、ユーザが受け取るタスクの調整をコーチ人員に行わせるようにすることが可能である。この調整はユーザの要請によってトリガされるか、または人員に介入の警告を発する自動規則によってトリガされる。例えば、ある規則は、クライアントが２週続け所望の成果に向けた進捗予定の５０％未満しか達成していない場合には、コーチ人員に警告を発すると明記されてよい。コーチ人員は警告を受けると、そのユーザのその日、または今後の任意の１日にスケジュールされたあらゆる目標を作成、削除、修正することができる。

【0067】

手動タスク調整および人間によるメッセージングは、多くの場合、相互に作用し合う。例えば、体重減量プログラムの一部として、コーチ人員がある人物の好みの野菜を知りたい場合、コーチはシステムに明示的データ収集タスクを挿入し（例えば選択モジュール２０８経由）、ユーザにその質問の理由を通知する（例えば通信モジュール２１０経由）。これにより、人間の介入をそれほど必要としないながらも、人間が関与した場合に得られる「暖かい」感じと責任とを作り出す強力な組み合わせが生まれる。

【0068】

図５は、自動（例えば日中、夜間）目標生成および人間が生成する目標生成における、クライアント（例えばクライアント１２８、１０６または１０８）とサーバ（例えばサーバ１１８）の間の例証的な相互作用５００を示す。日中の目標生成の実行において、クライアントはユーザが入力したデータを収集する（例えば、サーバから受信した命令に応答してクライアントが提示させたユーザインターフェース経由）。するとサーバが、これに応答してタスクを生成する（例えば選択モジュール２０８経由）。クライアントがこれに応答し、これらのタスクを表示して、ユーザにタスクと相互作用させる（例えば、これらのタスクに関連したデータを入力させる）ことができる（例えばユーザインターフェース経由）。次に、これに応答し、サーバがこの入力に基づいてユーザを採点する（例えば採点モジュール２０４経由）。

【0069】

夜間の目標生成の実行において、サーバは、受信したユーザに関する情報に基づいてプログラムを調整する（例えば収集モジュール２０６経由）。これに応答したクライアントが新規タスクを受信して、これをユーザに提示する（例えばユーザインターフェース経由）。

【0070】

人間によって生成された目標の実現において、全自動式の処理に人間味を加えるために、コーチ人員がアプリケーション１２０に入力を提供することができる（例えば、通信モジュール２１０経由でユーザと通信することで、あるいは、実行すべきタスクを選択モジュール２０８経由で手動でユーザに提案することで行う）。

【0071】

図６は、タスクベースのインターネット健康プログラムを実現するべく構成されたアプリケーション１２０の例証的な流れ６００を示すブロック図である。最初にユーザのデータおよび目標を取り入れる。毎日の目標が生成される。ユーザが追加のデータを明示的または黙示的に入力する。ユーザが（例えば、１日の目標をどのように完了したかについて）採点され、フィードバックが（例えばユーザのクライアントデバイス上に）表示される。上記明示的または黙示的に受信したデータに基づいて、インターネット健康プログラムをユーザに合うように調整する。オプションで、人間（例えば、ユーザの個人コーチ）がこの調整を補助する。

【0072】

図７は、アプリケーション１２０の例証的なユーザインターフェース７００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース７００は、提案されたタスク、この提案のタスクまたは目標の完了に向けたユーザの進捗状態など、ユーザの健康プログラムに関する情報をユーザに提示する。

【0073】

図８は、アプリケーション１２０の例証的なユーザインターフェース８００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース８００は、何を食べたかに関する詳細な情報を提供するようユーザに促す。

【0074】

図９は、アプリケーション１２０の例証的なユーザインターフェース９００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示）。ユーザインターフェース９００は、何を食べたかに関する情報を、ユーザインターフェース８００が要求したよりも大まかな形式で提供するようユーザに促す。

【0075】

図１０は、アプリケーション１２０の例証的なユーザインターフェース１０００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１０００は、運動活動に関する情報を入力するようユーザに促す。ユーザインターフェース１０００は、非常に詳細な情報またはそれほど詳細でない情報をユーザに催促するように構成されてよい。

【0076】

図１１は、アプリケーション１２０の例証的なユーザインターフェース１１００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１１００は、アプリケーション１２０が、ユーザが実行したランニングワークアウトに関する情報を黙示的に集めることを示す。様々な実施形態では、ユーザは、ランニングワークアウトに関する情報の明示的な入力を催促されなくてもよい。

【0077】

図１２は、アプリケーション１２０の例証的なユーザインターフェース１２００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１２０は、実行すべき運動タスクをユーザに提示し、そのタスクを完遂したかどうかをユーザに記入させる。

【0078】

図１３は、アプリケーション１２０の例証的なユーザインターフェース１３００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェースは、実行すべき小記事タスクをユーザに提示し、そのタスクを完了したかどうかをユーザに記入させる。タスクの選択は、選択モジュール２０８によって、先にユーザに提案された追加のタスクとは異なるタイプのタスクに基づいて行うことができる。

【0079】

図１４は、アプリケーション１２０の例証的なユーザインターフェース１４００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１４００は、今後タスクの実行に専念するようユーザに促す。

【0080】

図１５は、アプリケーション１２０の例証的なユーザインターフェース１５００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１５００は、アプリケーション１２０にアクセスしているユーザのコンテキストの外に表示されたウィジェットを含む。

【0081】

図１６は、アプリケーション１２０の例証的なユーザインターフェース１６００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１６００は、ユーザがトレーナー人員と直接通信できるようにする（例えば通信モジュール２１０経由）。

【0082】

図１７は、アプリケーション１２０の例証的なユーザインターフェース１７００のスクリーンショットである（例えば、クライアントデバイス上で実行中のクライアント経由で提示される）。ユーザインターフェース１７００は、タスクまたは目標の完了に向けたユーザの進捗のモニタリングを担当するトレーナー人員の、内部コンソールとして提示されてよい。トレーナー人員は、（例えば、ユーザにメッセージを送るため、またはユーザにタスクを提案するために）コンソール内の情報を使用してユーザと直接相互作用することができる。

【0083】

図１８は、アプリケーション１２０が使用しているデータベース（例えばデータベース１２６）のテーブル間の例証的な関係１８００を示すブロック図である。テーブルは、記事、記事の結果、食品入力、目標、ユーザ、Ｎｏｏｍメッセージ（例えば、トレーナー人員の介在有りまたは無しの状態で、ユーザとアプリケーション１２０との間で通信されるメッセージを含む）。

【0084】

ここでは、特定の実施形態は、論理、または多数のコンポーネント、モジュール、機構を含むものとして記述されている。モジュールは、ソフトウェアモジュール（例えば、マシン可読媒体上で、あるいは送信信号にて具現化されるコード）、またはハードウェアモジュールのいずれかを構成してよい。ハードウェアモジュールは、特定の演算を実行できる有形ユニットであり、特定の様式で構成または配列できる。例証的な実施形態では、１個以上のコンピュータシステム（例えばスタンドアロン、クライアント、サーバコンピュータシステム）、あるいはコンピュータシステムの１個以上のハードウェアモジュール（例えば１個のプロセッサ、またはプロセッサのグループ）は、ソフトウェア（例えばアプリケーション、またはアプリケーション部分）によって、ここで述べた特定の演算を実行するべく動作するハードウェアモジュールとして構成されてよい。

【0085】

様々な実施形態では、ハードウェアモジュールは機械的または電子的に実現されてよい。例えば、ハードウェアモジュールは、特定の演算を実行するように、（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）のような専用プロセッサとして）永久的に構成された専用回路または論理を備えてよい。ハードウェアモジュールは、特定の演算を実行するようにソフトウェアによって一時的に構成されるプログラマブルな論理または回路（例えば、汎用プロセッサまたは他のプログラマブルプロセッサ内に含まれるもの）を備えていてもよい。ハードウェアモジュールを、専用の永久的に構成された回路において、あるいは（例えばソフトウェアによって）一時的に構成された回路において、機械的に実現するという決定には、コストおよび時間を考慮することで到達し得ることが理解される。

【0086】

したがって、用語「ハードウェアモジュール」は、有形な実体、つまり、特定の様式で動作するおよび／または特定の演算を実行するように、物理的に構成された、永久的に構成された（例えば実配線された）、または一時的に構成された（例えばプログラムされた）実体を包含するようのと理解されるべきである。ハードウェアモジュールが一時的に構成された（例えばプログラムされた）実施形態を考慮した場合、各ハードウェアモジュールをいかなる時においても構成またはインスタンス化する必要はない。例えば、ハードウェアモジュールが、ソフトウェアを用いて構成された汎用プロセッサを備えている場合に、汎用プロセッサを、異なる時において、それぞれ異なるハードウェアモジュールとして構成することができる。これに応じ、次にソフトウェアがプロセッサを、例えば或る時には特定のハードウェアモジュールとなるように、また或る時には別のハードウェアモジュールとなるように、構成することができる。

【0087】

ハードウェアモジュールは、他のハードウェアモジュールとの間で情報の提供、および情報の受信を行える。したがって、記載のハードウェアモジュールは通信可能につながれていると考えられる。複数のこうしたハードウェアモジュールが同時に存在する場合には、通信は、ハードウェアモジュールどうしを接続する（例えば適切な回路およびバス上の）信号送信によって達成できる。複数のハードウェアモジュールが異なる時間に構成またはインスタンス化される実施形態では、こうしたハードウェアモジュール間の通信は、例えば、複数のハードウェアモジュールがアクセスできるメモリ構造での情報の記憶と取り出しを介して達成できる。例えば、１個のハードウェアモジュールが演算を実行し、その演算の出力を、通信可能につながれたメモリデバイスに記憶することができる。すると、さらなるハードウェアモジュールが、後にメモリデバイスにアクセスし、この記憶された出力を取り出して処理することができる。ハードウェアモジュールは、入力装置または出力装置との通信を開始し、リソース上で動作する（例えば情報収集を行う）こともできる。

【0088】

ここで記載された例証的な方法の様々な動作は、少なくともその一部が、関連の動作を実行するべく一時的に構成された（例えばソフトウェアにより）または永久的に構成された１個以上のプロセッサによって実行され得る。こうしたプロセッサは、一時的または永久的のどちらの構成であっても、１個以上の動作または機能を実行するように動作する、プロセッサによって実現されるタイプのモジュールとなる。ここで言及しているモジュールは、いくつかの例証的実施形態では、プロセッサによって実現されるモジュールを備えてよい。

【0089】

同様に、ここで記載された方法は、少なくともその一部がプロセッサによって実現されてよい。例えば、方法の動作の少なくともいくつかは、１個以上のプロセッサ、またはプロセッサによって実現されるモジュールにより実行され得る。複数の動作のうちの特定のもののパフォーマンスを、１個のマシン内に常駐しているものだけでなく、多数のマシンに展開された１個以上のプロセッサ間に分散させることができる。この１個以上のプロセッサは、いくつかの例証的実施形態では１つの場所に配置でき（例えば、家庭環境やオフィス環境内に、またはサーバファームとして）、他の実施形態では多数の場所に展開できる。

【0090】

１個以上のプロセッサは、「クラウドコンピューティング」環境内で関連動作のパフォーマンスをサポートするように動作したり、「ソフトウェアアズアサービス」（ＳａａＳ）として動作することも可能である。例えば、複数の演算のうち少なくともいくつかをコンピュータグループによって（プロセッサを含んだマシンの例のように）実行でき、これらの演算にはネットワーク経由で（例えばネットワーク１２０）、および１個以上の適切なインターフェース経由で（例えばＡＰＩ）アクセスできるようになっている。

【0091】

例証的な実施形態はデジタル電子回路にて、またはコンピュータハードウェア、ファームウェア、ソフトウェア、あるいはこれらの組み合わせにて実現することができる。例証的な実施形態は、コンピュータプログラム製品を使用して実現できる。このプログラム製品は、例えば情報担体内で、つまり例えばマシン可読媒体内で、プログラマブルプロセッサや１個または複数のコンピュータのようなデータ処理装置によって、またはその動作を制御するために実行される、有形的に具現化されたコンピュータプログラムである。

【0092】

コンピュータプログラムは、コンパイルまたは解釈された言語を含むあらゆるプログラミング言語形式で書くことができ、また、スタンドアロンプログラムとしての形式と、またはモジュール、サブルーチン、あるいはコンピューティング環境での使用に適したその他のユニットとしての形式とを含むあらゆる形式にて展開することができる。コンピュータプログラムは、１つの場所にある、または複数の場所に分散されて通信ネットワークで相互接続された、１個以上のコンピュータ上で実行されるように展開できる。

【0093】

例証的な実施形態では、演算は、入力データ上で動作し出力を生成することで機能を実行するためにコンピュータプログラムを実行中の１個以上のプログラマブルプロセッサによって実行される。方法演算は専用論理回路（例えばＦＰＧＡまたはＡＳＩＣ）によっても実行でき、また、例証的な実施形態の装置をこの専用論理回路（例えばＦＰＧＡまたはＡＳＩＣ）として実現することができる。

【0094】

計算システムはクライアントとサーバを含むことができる。一般に、クライアントおよびサーバは互いに離れた場所にあり、通信ネットワーク経由で相互作用することが典型的である。クライアントとサーバの関係は、それぞれのコンピュータ上において実行中で、相互に対してクライアント‐サーバ関係を持ったコンピュータプログラムによって生じる。プログラマブル計算システムを展開する実施形態では、ハードウェアアーキテクチャとソフトウェアアーキテクチャの両方を考慮する必要がある点が理解されるだろう。具体的には、特定の機能を、永久的に構成されたハードウェア（例えばＡＳＩＣ）、一時的に構成されたハードウェア（例えばソフトウェアとプログラマブルプロセッサの組み合わせ）、またはこれらの組み合わせのいずれで実現するかは、設計上の選択となる。以下で、様々な例証的な実施形態にて展開できるハードウェア（例えばマシン）とソフトウェアアーキテクチャについて述べる。

【0095】

図１９は、本明細書中で述べた任意の１つ以上の技法をマシンに実行させる命令を実行することができるコンピュータシステム１９００の例証的な形態をしたマシンのブロック図である。代替的な実施形態では、マシンはスタンドアロンデバイスとして動作するか、または他のマシンに接続（例えばネットワーク接続）されていてよい。ネットワーク経由の展開では、マシンは、サーバ‐クライアントネットワーク環境におけるサーバまたはクライアントマシンの容量内で、または、ピアツーピア（または分散）ネットワーク環境におけるピアマシンとして動作できる。マシンは、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話（例えばｉＰｈｏｎｅ、またはＡｎｄｒｏｉｄオペレーティングシステムを実行中の携帯電話）、ウェブ機器、ネットワークルータ、スイッチまたはブリッジ、あるいは、マシンがとる処置を特定する命令（シーケンシャルまたはその他）を実行できる任意のマシンであってよい。さらに、１個のマシンしか図示されていないが、用語「マシン」は、本明細書中で述べた任意の１つ以上の技法を実行するべく、個々にまたは共同で１組（または複数組）の命令を実行するあらゆるマシン集合体を含むものと取ることができる。

【0096】

例証的なコンピュータシステム１９００は、プロセッサ１９０２（例えば中央処理ユニット（ＣＰＵ）、グラフィック処理ユニット（ＧＰＵ）、あるいは両方）、メインメモリ１９０４、スタティックメモリ１９０６を含んでおり、これらはバス１９０８を介して互いに通信する。コンピュータシステム１９００はビデオディスプレイユニット１９１０（例えば、液晶ディスプレイ（ＬＣＤ）またはブラウン管（ＣＲＴ））をさらに含むことができる。コンピュータシステム１９００はさらに、英数字入力デバイス１９１２（例えばキーボード）、ユーザインターフェース（ＵＩ）ナビゲーション（またはカーソル制御）デバイス１９１４（例えばマウス）、ディスクドライブユニット１９１６、信号生成デバイス１９１８（例えばスピーカ）、ネットワークインターフェースデバイス１９２０を含む。

【0097】

ディスクドライブユニット１９１６はマシン可読媒体１９２２を含む。このマシン可読媒体１９２２には、本明細書中で述べた任意の１つ以上の技法または機能を具現化する、またはこれらによって利用される１組以上の命令およびデータ構造（例えばソフトウェア）１９２４が記憶されている。命令１９２４は、コンピュータシステム１９００によって実行されている間、メインメモリ１９０４内および／またはプロセッサ１９０２内に完全あるいは少なくとも部分的に常駐することもでき、また、メインメモリ１９０４とプロセッサ１９０２はマシン可読媒体の構成要素でもある。命令１９２４は、スタティックメモリ１９０６内にも完全または少なくとも部分的に常駐することができる。

【0098】

例証的な実施形態では、マシン可読媒体１９２２を単一の媒体として示しているが、用語「マシン可読媒体」は、１個以上の命令またはデータ構造を記憶する１個以上の媒体（例えば、集中または分散データベース、および／または、関連するキャッシュならびにサーバ）を含むことができる。用語「マシン可読媒体」はさらに、マシンによって実行される命令を記憶、暗号化、伝達できる、また、本実施形態の任意の１つ以上の技法をマシンに実行させる、また、上記命令によって利用される、あるいはこれと関連したデータ構造を記憶、暗号化、伝達できる、任意の有形媒体を含むようにも解釈される。したがって、用語「マシン可読媒体」は、固体メモリ、光学および磁気媒体を非限定的に含むものとして解釈される。マシン可読媒体の具体例には不揮発性メモリが含まれ、この不揮発メモリは以下を例証の形で含む。すなわち、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、電気消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリデバイスなどの半導体メモリデバイス；内蔵ハードディスクや取り外し可能ディスクなどの磁気ディスク；光磁気ディスク；コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）やデジタル多目的ディスク（またはデジタルビデオディスク）読み取り専用メモリ（ＤＶＤ－ＲＯＭ）ディスク。

【0099】

さらに命令１９２４は、送信媒体を使用して、通信ネットワーク１９２６経由で送受信することができる。命令１９２４は、ネットワークインターフェースデバイス１９２０と、多数の周知の転送プロトコル（例えばＨＴＴＰ）のうち任意の１つとを使用して送信することができる。通信ネットワークの例には、ＬＡＮ、ＷＡＮ、インターネット、携帯電話網、ＰＯＴＳネットワーク、無線データ網（例えばＷｉＦｉおよびＷｉＭａｘ網）が含まれる。用語「送信媒体」は、マシンによって実行される命令を記憶、暗号化、伝達でき、デジタルまたはアナログ通信信号を含むあらゆる無形媒体を含む、あるいは、こうしたソフトウェアの通信を促進するその他の無形媒体を含むものと解釈される。ネットワーク１９２６はネットワーク１２０のうちの１つであってよい。

【0100】

特定の例証的実施形態を参照して実施形態を説明したが、本開示の幅広い範囲から逸脱しない限り、種々の修正、変更が可能であることが当業者には明白であろう。したがって、本明細書および図面は限定的な意味ではなく、例示的な意味において考慮されるべきである。その一部を形成する添付の図面は、本発明の主題を実践できる特定の実施形態を非限定的な例示の方法で示している。例示された実施形態は、ここで開示された示唆を当業者が実践できるように、十分詳細に説明されている。これらの実施形態から他の実施形態を利用および導出でき、したがって本開示の範囲から逸脱しない限り、構造的および論理的な代用と変更が可能である。したがって、この詳細な説明は限定的な意味に解釈されるべきではなく、様々な実施形態の範囲は添付の請求項、ならびにこれらの請求項に権利が与えられる全範囲の同等物によってのみ定義される。

【0101】

本発明の主題のこうした実施形態は、ここでは、単に便宜的理由から用語「発明」によって、また、２つ以上の開示が存在する場合には、本出願の範囲を任意の１つの発明または発明的概念に故意に限定することを意図せず、個別的および／または集合的に言及される。したがって、ここまで特定の実施形態を例示および説明したが、同一の目的を達成できると推定された任意の配置が、ここで示した特定の実施形態の代用となり得ることが理解されるべきである。本開示は、種々の実施形態の任意および全ての改造または応用をカバーすることを意図する。ここでは、上述した実施形態と、本明細書で詳細に説明していないその他の実施形態との組み合わせが、上述の説明を再検討することで当業者に明白となるだろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】