JP2016512623A - さまざまな認知能力レベルの人々のためのコンテクスト依存型アプリケーション／イベント起動 - Google Patents

Abstract

認知能力または運動能力が低下した患者が使用するように設計された患者機器は、家族または看護スタッフが使用して患者のユーザ経験をカスタマイズするように設計されたネットワークベースのポータルと統合する。家族は、ポータルを用いて、ユーザインタフェースのカスタマイズ事項ならびに患者機器上で実行されるコンテンツおよびアプリケーションをプッシュする。家族はまた、ポータルを介して遠隔で患者機器を制御できる。患者機器は、カスタマイズ可能なインタフェース要素のセットに関する使用データならびにプッシュされたコンテンツおよびアプリケーションに関する使用データを収集する。これらのデータは、ポータルへのフィードバックとして送信され、どのユーザインタフェース機能、コンテンツおよびアプリケーションが使用されているか、ならびに、どのユーザインタフェース機能、コンテンツおよびアプリケーションが使用されていないかを、ポータルが家族に示すことを可能にする。ポータルを介して収集された合計データは、ユーザインタフェース機能の選択を助けるように使用されるランキング点数を生成する。【選択図】図１

Description

本開示は、認知能力または運動能力が低下した人が、来たるべきイベントを管理し、近親者との繋がりを維持するのを援助するための、コンピュータで実装されたシステムに関する。

初期から軽度のアルツハイマー病または痴呆症の人々は、記憶喪失および複雑な機器を作動できないことの両方で苦しんでいる。これらの人々は、イベントまたはアクティビティを逸すること、もしくはその他の時刻依存型の案件を忘れることをいつも心配している。その結果、これらの人々はいつも、自分自身に宛てた夥しい量のメモを書く。それらのメモが溜まると、結果として、別の混乱が生じる。どのメモが重要なのか、それらが何時重要になるのかを忘れてしまうからである。

スマートフォンやタブレット機器などの携帯機器が普及するにつれ、認知能力または運動能力が低下した人が重要なイベントを思い出すための一助として、これらの機器を利用することが考えられる。しかし、このことは、一見したところほど決して単純でない。認知能力が低下した人は、これらの携帯機器と対話することが非常に困難であり得る。第１に、認知能力が低下しているので、機器上で実行される特定のユーザインタフェース機能またはアプリケーションの使用方法を理解できないかもしれない。第２に、よくあることだが、認知能力が低下した人は身体的障害も有しており、機器上のユーザインタフェース機能を操作することが困難かもしれない。

さらに悪いことには、特定の人物の認知能力または運動能力に十分に適したユーザインタフェースを設計しようとすると、万人に適用可能なソリューションが得られなくなる。さらに、残念ながらよくあることだが、人の能力は時間の経過とともに低下する。例えば、現時点で完全に適応したユーザインタフェースであっても、６ヵ月後にはユーザのニーズを満たすことができないかもしれない。

家族は助けることを願っているが、彼らもまたユーザインタフェースの複雑さに苦戦するかもしれない。家族は年老いてゆく愛する人に有用な携帯機器をあげたと思うかもしれないが、その機器が実際に助けになっているかどうかを知る手段はほとんど無い。本当によくあることだが、携帯機器は老人にとってあまりに馴染みの無いものであり且つ複雑すぎて有用ではないので、老人の部屋に使われずに置いてあることがよくある。機器が用いられていないことを家族が最終的に知っても、家族はその状況を変えるための効果的な手段を持っていない。典型的な家族は、認知障害者または運動障害者のためのユーザインタフェース設計の専門家ではないからである。

このセクションは、開示内容の概要を提供するものであり、開示内容の全範囲またはその特徴の全てを包括的に提供するものではない。

本開示は、上記問題に対して、統合型患者機器（例えば、携帯機器）とネットワークベースのポータルとを組合せた形態のソリューションを提供するものである。患者機器は、認知能力または運動能力が低下した患者が使用するように設計されている。患者機器は、家族または看護スタッフが使用して患者のユーザ経験をカスタマイズするように設計されたネットワークベースのポータルと統合されている。家族または看護スタッフは、ポータルを使用して、ユーザインタフェースのカスタマイズ事項ならびに患者機器上で実行されるコンテンツおよびアプリケーションをプッシュする。家族または看護スタッフは、ポータルを介して遠隔で患者機器を制御することもできる。

患者機器は、カスタマイズ可能なインタフェース要素のセットについての使用データおよびプッシュされたコンテンツおよびアプリケーションについての使用データを収集する。これらのデータはフィードバックとしてポータルに送信され、それによりポータルは、家族または看護スタッフに対して、どのユーザインタフェース機能、コンテンツおよびアプリケーションが用いられたか、用いられなかったかを見せることができる。ポータルを介して収集された合計データは、ユーザインタフェース機能の選択を助けるために使用されるランキングのメトリック（点数）を生成する。

ポータルは、ユーザインタフェース（ＵＩ）要素の統合データベースまたはキットを含み、このデータベースまたはキットから家族または看護スタッフが選択して、特定の患者のために特別に設計された、カスタマイズされたユーザインタフェースおよびユーザ経験を作成してもよい。統合データベース内に格納されている場合、各UI要素には、その特定の患者に対するそのUI要素の分かりやすさおよび使いやすさをランク付けする、少なくとも一つの認知能力点数または運動能力点数が関連付けられている。

家族が特定のアプリケーションのユーザインタフェースや、患者機器自体のグローバルな動作さえもカスタマイズしたい場合、その家族は、各UI要素のこれら認知能力点数および運動能力点数を比較して、その特定の患者のために最適なものを選択することができる。

患者が機器を使用すると、使用された各UI要素およびいつ使用されたかに関する実際の使用データが収集される。これらのデータから、フィードバック信号がポータルに送信され、これにより、ポータルコンピュータは、この使用データを考慮に入れて、実際に患者に使用された（または使用されなかった）さまざまなＵＩ要素にどのような使用点数を与えるかを決定することができる。ポータルコンピュータはまた、患者機器を使用している患者の全母集団を示す、複雑さの合計統計値および点数を生成するクラウドベースのアグリゲーションコンピュータと使用統計値を共有するようにプログラムされている。好ましくは、これらの使用統計値は、患者のプライバシーが確保されるよう患者特有の情報を明らかにすることなく、クラウドベースのアグリゲーションコンピュータと共有される。

必要に応じて、統合データベースは、機器に対してプッシュされるコンテンツのさまざまな異なる選択に関連付けて、同様の適合性点数を格納するように構成されてもよい。この場合、もし６０分の長い動画が機器に対してプッシュされたのに患者が２分間しか見なかったならば、その使用データはこの特定の患者についてのコンテンツの適合性レベルが低いことを反映しており、よって、低適合性点数がそのコンテンツに割り当てられる。この低適合性点数は、選択されて患者機器に対してプッシュされたコンテンツが患者にはあまりに「難しい」かまたは興味が無いのかもしれない、ということを家族または看護スタッフに示している。

同様に、統合データベースは、機器上で実行すべく機器に対してプッシュされるアプリケーションのさまざまな異なる選択に関連付けて、同様の適合性点数を格納するように構成されてもよい。例えば、インスタントメッセージングアプリケーションが患者機器に対してプッシュされたものの、使用点数がこのアプリケーションが一度も使用されていないことを示す場合、低適合性点数が割り当てられる。この低適合性点数は、選択されて患者機器に対してプッシュされたインスタントメッセージングアプリケーションがこの特定の患者にはあまりに「難しい」かまたは興味が無いのかもしれない、ということを家族または看護スタッフに示している。

従って、１つの局面によれば、本開示は、認知能力または運動能力が低下した人を援助するための、コンピュータで実装されたシステムを記載している。このシステムは、ディスプレイと、ディスプレイに接続されたプロセッサと、ポータルコンピュータと通信するための通信ポートとを有する患者機器を含む。患者機器のプロセッサは、患者機器に対してプッシュされた選択されたユーザインタフェース要素の患者による使用に関して、フィードバックデータをポータルコンピュータに提供するようにプログラムされている。

ポータルコンピュータは、プロセッサと付随するメモリとを有し、前記付随するメモリは、能力点数を各ユーザインタフェース要素に関連付ける予め規定されたデータ構造に応じた、複数のユーザインタフェース要素を格納する付随するメモリ。ポータルコンピュータは、複数のユーザインタフェース要素を、ポータルコンピュータのユーザに対して、能力点数に基づいた提示配置で提示するようにプログラムされている。ポータルコンピュータは、さらに、第１のユーザが、上記配置で提示されたユーザインタフェース要素から少なくとも１つのインタフェース要素を選択し、その後、選択したユーザインタフェース要素を患者機器に対してプッシュできるように、プログラムされている。

更なる利用可能な分野は、本明細書の記載事項から明らかになる。この概要の説明および具体例は、説明の目的のみを意図したものであり、本開示の範囲を限定すること意図したものではない。

本願明細書に記載した図面は、選択された実施形態を説明するためのものに過ぎず、全ての考え得る実施態様を記載したものではなく、また、本開示の範囲を限定しようとするものでもない。

図１は、システムアーキテクチャの概要を示す図であって、ユーザと、表示装置と、サーバ型システムと、ネットワークとを示す図である。 図２は、表示装置に表示されたメッセージ画面の一例を示す図である。 図３は、リマインダを受領確認した後に表示装置に表示されたメッセージ画面の一例を示す図である。 図４は、全システム内のどこにシステムロジックを配置するべきかについての別のアプローチの例を示す図である。 図５は、システムにより用いられる例示的なデータベース要素を示す図である。 図６は、表示装置のための簡略化されたロジックフローの一例を示す図である。 図７は、特定の表示装置のための、グループメッセージおよび異なる種類のユーザの関係を示す図である。 図８は、表示装置についてグループユーザとマスターユーザとの関係をセットアップするためのプロセスの一例を示す図である。 図９は、リマインダの受領確認を説明するために、システムの部分集合を示す図である。 図１０は、表示装置のための例示的なハードウェアブロック図を示す図である。 図１１は、リマインダメッセージの作成および／または編集をおこなうためのユーザインタフェースの一例を示す図である。 図１２は、特定の表示装置について全てのアクティブなリマインダおよびメッセージをレビューするためにマスターユーザが見るユーザインタフェースの一例を示す図である。 図１３は、特定の表示装置について全てのアクティブなリマインダおよびメッセージをレビューするためにレギュラーユーザが見るユーザインタフェースの一例を示す図である。 図１４は、スマートフォンおよびその他のモバイル機器に合わせてフォーマットされた同様のユーザインタフェースの一例を示す図である。 図１５は、グループリマインダおよびメッセージを閲覧するためにグループユーザが見るユーザインタフェースの一例を示す図である。 図１６は、インスタントメッセージの作成または編集をおこなうためのユーザインタフェースの一例を示す図である。 図１７は、特定の表示装置についてパラメータを管理するためのユーザインタフェースの一例を示す図である。 図１８は、既存のプリセットリマインダを示すユーザインタフェースの一例を示す図である。 図１９は、プリセットリマインダを選択するためのユーザインタフェースの一例を示す図である。 図２０は、表示装置の調子をどのように監視できるかを示す図である。 図２１は、ディスプレイおよびマスターユーザの構成を示す図である。 図２２は、数例のリマインダメッセージを表示している表示装置の一例を示す図である。 図２３は、イベントまたはアプリケーションが開示されたシステムを用いてどのように自動的に起動されるかについての基礎的要素を示す実体図である。 図２４は、認知能力がイベントまたはアプリケーションの起動においてどのように要因となるかを説明する高レベルフローチャートである。 図２５は、どのようにコンテクストが収集されて、システム内の各種要素によって使用されるかを説明するフローチャートである。 図２６は、システムによって実施される開始イベントフローを説明するフローチャートである。 図２７は、システムによって実施されるイベント起動フローを説明するフローチャートである。 図２８は、システムの例示的な使用を示す使用事例図である。 図２９は、システムの対話レベルが認知能力に基づき且つ好みおよび技術コンテクスト情報に基づいてどのようにカスタマイズされるかを示す対話図である。 図３０は、システムによってコンピュータメモリ内に維持されたデータ構造が認知能力に反映される場合、認知能力がシステムによってどのようにモデル化されるかを示す図である。 図３１は、タブレットベースのウェブ実現型システムの一実施形態を示すブロック図である。 図３２は、いくつかの例示的なアプリケーション／イベントが起動された画面表示の一例を示す図である。 図３３は、コンピュータで実装されたシステムならびにその関連データベースおよびデータ構造を示すブロック図である。 図３４は、患者機器およびネットワークベースのポータルコンピュータがどのように統合されているかを示すブロック図である。 図３５は、例示的なカレンダーアプリケーションを備えた、患者機器の例示的なディスプレイ画面を示す図である。 カスタマイズ事項がどのように患者機器に対してプッシュされるか、ならびに、使用データがどのように収集されるかを示す、ユーザインタフェースおよびデータ構造の図である。 カスタマイズ事項がどのように患者機器に対してプッシュされるか、ならびに、使用データがどのように収集されるかを示す、ユーザインタフェースおよびデータ構造の図である。 患者機器からの使用フィードバックがどのように表示されるかを示す、ポータルコンピュータによって生成される比較ディスプレイを示す図である。 患者機器からの使用フィードバックがどのように表示されるかを示す、ポータルコンピュータによって生成される比較ディスプレイを示す図である。 図３８は、患者機器の設定がカスタマイズされる、ポータルコンピュータによって生成される例示的なディスプレイ画面を示す図である。 図３９は、患者機器の設定がカスタマイズされ、患者機器に対してプッシュするアプリケーションが選択される、ポータルコンピュータによって生成される例示的なディスプレイ画面を示す図である。 図４０は、選択されたデジタルコンテンツが追加されるように患者機器用のアプリケーション（例えば、音楽アプリケーションおよび動画アプリケーション）の設定がカスタマイズされる、ポータルコンピュータによって生成される例示的なディスプレイ画面を示す図である。 図４１は、患者機器用の音声―動画チャットアプリケーション（例えば、Ｓｋｙｐｅ）の設定がポータルコンピュータからカスタマイズされる、ポータルコンピュータによって生成される例示的なディスプレイ画面を示す図である。 アプリケーションまたはＵＩ要素に関連付けて能力点数を表示するための２つの異なる実施形態を示す図であって、この表示は、患者機器使用時の患者の経験をカスタマイズするのに使用するために、ポータルコンピュータのディスプレイ上に提示される。 アプリケーションまたはＵＩ要素に関連付けて能力点数を表示するための２つの異なる実施形態を示す図であって、この表示は、患者機器使用時の患者の経験をカスタマイズするのに使用するために、ポータルコンピュータのディスプレイ上に提示される。 図４３は、患者機器のソフトウェアアーキテクチャを説明する図である。 図４４は、ポータル機器がどのようにしてメッセージングにより患者機器のＡＰＩと通信するかを示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。 図４５は、クラッシュ報告がどのように処理されるかを示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。 図４６は、アップデータブロードキャストレシーバを示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。 図４７は、ラッパーアクティビティスタートを示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。 図４８は、ラッパーアクティビティダウンローダを示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。 図４９は、ラッパーアクティビティクラッシュを示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。 図５０は、バンドル設定の更新を示す、ポータル機器のソフトウェアアーキテクチャを説明する図である。

概要
本開示のシステムは、遠隔地またはローカル地にある人（例えば、友人、家族、管理者）が、適切な時刻に比較的簡易な表示装置上に適切なメッセージングにより表示される、リマインダメッセージを作成することを可能にする。この表示装置は、閲覧者がいかなるコントロール要素とも対話する必要が無いので、アルツハイマー病の人はその操作方法を学ぶ必要がない。この表示装置が必要とする唯一の対話は、１回の初期設定ステップにおいて行われ、また、１つのボタンを押すことだけを要求するオプションのリマインダ受領確認時に行われる。

システムは、インターネットおよび／またはローカルエリアネットワーク（ＬＡＮ）等のネットワークを介して動作する。人々（友人、家族、管理者）は、任意の近年のブラウザを介してシステムと繋がる。そして、システムは、ネットワークを介して表示装置と対話する。

システムは、複数の表示装置および複数のアカウントを含み、リマインダメッセージを作成する能力を、複数の人に与えることができる。マスターアカウントは、他のアカウントからのメッセージを編集する能力や、その他の権限をも与えられている。援助生活ホーム等の状況の場合、グループ管理者アカウントが、表示装置のグループに、または１台の表示装置に、メッセージを送信することができる。しかし、特定の表示装置に直接関連付けられたアカウントは、必要に応じて、そのようなグループメッセージを隠すことができる。

１台の特定の表示装置に関連付けられたアカウント所有者は、グループメッセージを含む互いのリマインダを見ることができるので、友人および家族は、そのリマインダが宛てられた人物の予定されたまたは現在のアクティビティについて知ることができる。しかし、プライバシー保護のため、閲覧の許可が与えられない限り、グループアカウント所有者は自分たち自身のグループメッセージしか見ることができない。

メッセージングは、前もって設定することができ、それらが言及しているイベントを基準として適切な時刻に表示させることができる。音声を含むメッセージングの内容および詳細さのレベルは、対象イベントにどれくらい近いかに応じて変化する。一旦そのイベントが始まると、イベントが終了するまでメッセージングが続き、その後、このメッセージングの内容は、イベント終了時点を基準として現在はどの時点であるかに応じて変化する。

リマインダは、特定の間隔（１日毎〜１年毎）で自動的に繰り返されて、さまざまな状況およびイベントを含むようにプログラムされ得る。

リマインダは、必要に応じて、閲覧者が受領確認することを要求し得る。複数の受領確認リクエストを同時にアクティブにし得る。このようなリマインダが受領確認されない場合、遠隔ユーザ（友人、家族および管理者）は、ステータスの確認および／またはショートメッセージサービスまたは電子メールによる警告の受信を行い得る。

タイピングを減らせるように、プリセットリマインダが設けられている。アカウント所有者は、システムが定義したプリセットメッセージを使用するか、または、将来使用するために自分自身のメッセージを作成することができる。アカウントユーザは、プリセットメッセージをカスタマイズすることができる。

メッセージは、いかなる特定のイベントにも結び付けられていない「インスタントメッセージ」であってもよい。このようなインスタントメッセージは、比較的短い時間表示され、且つ、閲覧者がそのメッセージを見るためにいかなるアクションも要求しない。

機器の障害、電力喪失、または通信不通などの潜在的な障害状況を回避するため、システムは、各表示装置の調子を監視し、そのような障害について、適切なアカウント所有者および／または管理者に警告することができる。

ある局面において、本システムは、患者の認知能力、すなわち、第三者による完全な管理状態から、共同管理状態（shared control)、そして自立的活動状態の患者に至る範囲、に応じたハイブリッドな介護援助を、自動的且つ自然な様態で提供することを旨とする。システムの第三者制御は、ローカルまたは遠隔であり得る。更に、システム自体は、認知能力の更なる向上または低下に基づいて、提供される対話のレベルを患者に適応させていく。

したがって、システムは、以下に示す中核的な機能に基づいて、イベントのトリガリング（例えば、ディスプレイ上におけるアプリケーション／イベントの起動）を自動的且つ自然に適応させるように動作する：
Ａ． 第三者（例えば、家族）によって、イベント／アプリを準備／セットする。
Ｂ． イベントコンテクストの推定。コンテクストは、開始しようとするイベントに応じて、いくつかの形態（医学的形態、状況的形態など）をとり得る。
Ｃ． コンテクストの現在の状況およびその者の認知能力とのマッチングに基づくイベントの起動。

システムはさらに、上記の中核的な機能に加えて、以下に示すものを含む多数の追加的な利点を提供する：
・ アプリケーションは、邪魔にならない様態（例えば、患者が眠っていない場合には音声メッセージ）で、自動的に開始できる。
・ 起動およびアプリケーションとの対話は、患者の認知能力にあわせてカスタマイズできる。
・ 患者は、アプリケーション／イベントをどのように起動するかを知る必要なく、多数のサービス（例えば、家族の画像、テレビ会議または動画リマインダ、音楽観賞）を楽しむことができる。
・ 患者の個人的な好みを考慮してシステムのサービスをカスタマイズすることができる。
・ ソリューションは、明示的な対話（イベント／アプリケーションを準備する第三者の観点からみた場合）に対する暗黙的な対話（患者の観点からみた場合）を含む。
・ 我々のソリューションは、いつアプリケーション／イベントを起動するか、ならびに、どのようにアプリケーション／イベントを起動するかに関する。

詳細な説明
添付の図面を参照して、実施形態の例をより詳細に説明する。

図１は、システムアーキテクチャの概要を示す図であって、１組の異なる種類の遠隔ユーザと、サーバシステムと、１組の表示装置（以下、単に「ディスプレイ」または「複数のディスプレイ」とも呼ぶ）とを示している。各ユーザ１００、１１０は、ネットワーク１３０を介してシステムと対話する。ネットワーク１３０は、複数のワイドエリアネットワーク（インターネット等）またはローカルエリアネットワークを組み合わせたものであり得る。各ユーザは、特定のディスプレイ１４０と関連付けられている。図中、マスターユーザＡ１００および関連するノーマルユーザ１１０は、ディスプレイＡと対話する。さらに、ディスプレイＢ等と関連付けられた別の組のユーザが存在する。

ユーザーアカウントは、ディスプレイが中心になっている。各ディスプレイと関連付けられた少なくとも１人のマスターユーザ１００が存在する。マスターユーザは、ディスプレイがどのように見えるかについて、最終的な制御を有している。マスターユーザは、以下のことを行うことができる：
ｏ 新しいイベントリマインダおよびメッセージを作成すること。
ｏ 自身が作成したイベントリマインダおよびメッセージ、もしくは管理下のディスプレイに属する他のマスターユーザまたはノーマルユーザが作成したイベントリマインダおよびメッセージを編集すること。
ｏ 当該ディスプレイについて、新しいマスターユーザまたはノーマルユーザを作成すること。
ｏ グループイベントが当該ディスプレイ上で有効化されるかどうかを制御すること（グループユーザを参照）。
ｏ 当該ディスプレイに送信された特定のグループイベントリマインダを隠すまたは見せること。このイベントがマスターユーザ（またはノーマルユーザ）が計画した他のイベントとコンフリクトする場合、グループイベントリマインダを隠すことが必要かもしれない。
ｏ 当該ディスプレイに対して作成したイベントリマインダおよびメッセージは、誰が作成したものであっても見ることができる。
ｏ 他の人が使用することもできるプリセットイベントリマインダを作成および編集すること。
ｏ ディスプレイの詳細（名前、位置、タイムゾーンなど）を変更すること。
ｏ 自身のユーザ詳細（名前、ユーザー名、電子メールアドレスおよびパスワード等）を変更すること。

ノーマルユーザまたはレギュラーユーザ１１０は、メッセージをこのディスプレイ上に配置することができるが、有している権限が少ない：
・ 自分自身が作成したイベントリマインダおよびメッセージを編集すること。
・ 当該ディスプレイに送信された特定のグループイベントリマインダを隠すまたは見せること。
・ 当該ディスプレイに対して作成したイベントリマインダおよびメッセージは、誰が作成したものであっても見ることができる。
・ 他の人が使用することもできるプリセットイベントリマインダを作成および編集すること。
・ 自分自身のユーザ詳細（名前、ユーザー名、電子メールアドレスおよびパスワード等）を変更すること。

グループユーザ１２０は、複数のディスプレイと関連付けられ得る。図１は、１つのグループユーザのみを示し、特定の施設に、このグループユーザがアクセスを有する３台のディスプレイ（Ａ、Ｂ、Ｃ）が配置されている状況を説明する。マスターユーザは、以下のことを行うことができる：
・ 電子メール招待状を送信することによって、マスターユーザをこのグループに加入するよう招待すること。このような招待を送信するために、グループユーザは、マスターユーザの「ユーザー名」を求める必要がある。グループに加入する旨の電子メール招待状を受信したマスターユーザは、リンクをクリックして招待を受けなければならない。マスターユーザは、グループイベントのいずれかまたは全てをディスプレイ上に表示させないように無効化する権限を依然保有している。
・ このグループユーザからのグループイベントを受け入れるように有効化された全てのディスプレイに送信されるグループイベントリマインダおよびインスタントメッセージを作成および編集すること。
・ イベントリマインダまたはインスタントメッセージが（全てのディスプレイではなく）１台のディスプレイのみに送信されることを指定すること。
・ グループユーザは、特定のアイテムを公開する許可を与えない限りにおいて、いずれのディスプレイでも、マスターユーザおよびノーマルユーザによって作成されたイベントリマインダおよびメッセージを見ることができない。
・ 自分自身のユーザ詳細（名前、ユーザー名、電子メールアドレスおよびパスワード等）を変更すること。

サーバ１５０は、各ユーザによるシステムへのアクセスおよび各ディスプレイの更新を含む、システムの管理を行う。１台のサーバ１５０が世界中に点在する多数のユーザおよびディスプレイのセットを管理できるので、図１は可能なことのうち部分集合のみを示す。データベース１６０は、全てのユーザ、ディスプレイおよびメッセージに関する情報の全てを格納している。パスワードおよび電子メールアドレス等の取り扱いに注意を要する情報は、暗号化した状態に保たれている。

典型的な動作において、ユーザは、ウェブブラウザまたは専用のアプリケーションを介してシステムと対話して、リマインダを作成する。このリマインダはデータベースに格納され、その後、サーバが、どのリマインダが適切な時刻に各特定のディスプレイに送信されるべきかを決定する。ユーザは、適宜編集を行うことおよびメッセージを隠すことを含む、全てのリマインダおよびメッセージのステータスを閲覧することができる。

ディスプレイは、それらが送信されるというメッセージを表示するのみである。それらは、必要に応じて、これらのメッセージの若干の管理を行って、動作中に必要な通信量を最小化することができる。これらのディスプレイは、必要に応じて、要求された場合に、メッセージに応答する簡単な手段（例えば、ディスプレイにタッチする、言葉で返事する等）を閲覧者に提供してもよく、この応答はサーバに送り返される。

図２は、ディスプレイ上に表示され得る典型的な種類のメッセージのセットを示す。人がアルツハイマー病にかかっている場合、複雑なメッセージおよびグラフィックスは混乱につながり得るので、メッセージングは、シンプルで、直接的で、且つ状況に対して適切である必要がある。

ディスプレイ２００の最上段は、現在の日付および時刻のみを示す。「朝」または「夕方」等、その日の時間帯も表示される。時刻および日付は、ネットワークから自動的に取得される。ディスプレイがあるタイムゾーンに存在する間に、ユーザが他のタイムゾーンに居るということが起こり得るので、ディスプレイのタイムゾーンは、ディスプレイのマスターユーザによってなされる選択１７１０により決定される。

本図面では、人は左から右へと読み進めるものだと仮定しているので、サンプルディスプレイにおいて、イベントまたはリマインダの「タイトル」２１０は左側に表示される。もちろん、文化が異なればこのルールも異なり得、どのようにディスプレイを配置するかについての調整は、それぞれの国に適応され得る。

メッセージのタイトルは、入力メニュー１１００内のタイトルの長さを限定することにより、わざと短くしてある。

メッセージタイトル（およびメッセージングの他の部分）を表示するために用いるサイズおよびフォントカラーは、対象イベントにどれくらい近いかに応じて変化する。イベントの開始（および、イベントが任意の長さを有する場合は、イベントの終了）に近づくにつれ、フォントが徐々に大きくなり、フォントカラーはより緊急性の高い色へと変化する。

メッセージタイトルが短か過ぎる場合もあり得るので、第２行目２１０は、メッセージまたは指示を追加することができる。この第２行目はオプションであり、時刻がイベントにより近くなるまで非表示にすることができる。第２行目を遅れて表示させることは、あまり早くにあまりに多くの情報を表示することは読み手を混乱させるだけである、という仮定に基づいたものである。

付加的なメッセージング２４０、２５０をリマインダに追加して、イベントがいつ行われることになっているのかについての手掛かりを与える。補足的なタイミングメッセージの文言は、シンプルな口語体で作成される。「約２時間後に」のような文言で同じ意味を伝達できる場合、イベントが「２０１１年４月１０日午前１１時３０分」に開始される予定であると言うのは、読み手にとってあまりに混乱させるものであろう。このようなタイミングメッセージングがどのように働くかについてのアルゴリズムは、かなり複雑であり得、且つ、閲覧者の文化様式および言語様式に合わせて調整する必要がある。いつもそうであるように、メッセージングは最小に維持される必要がある。しかし、与えられる情報が少なすぎる場合、それもまた問題であり得る。

図２２は、より多くのメッセージングの例が動作中のディスプレイに表示されている様子を示す。

サンプルメッセージ「朝の薬」は、応答（この場合、「ＯＫボタン」２２０を押すこと）を求めている。応答方法についての指示は、言葉または他の手段で与えられ得る。この図では、ＯＫボタンは単にディスプレイ上のグラフィックであり、システムは、タッチ感応型ディスプレイ１０１５システムを用いて、このボタンを押したことを感知する。後述するように、応答のステータスを監視することができる。

図３は、図１と同様のサンプルディスプレイを示す。但し、ＯＫボタンが、チェックされたボックスのアイコン３２０と置き換えられた１点で異なっている。このアイコン（または同様の種類のインジケータ）は、メッセージが実行されたことを閲覧者に伝える。人は時々、薬の服用など、定期的に行っている何かを既に実行したことを忘れることがある。チェックされたボックスのアイコンは、リマインダの別の形として機能する。

図４は、システムのロジックを分配する２つの方法を示す。

上段のバージョンは、サーバ側４００、４１０にほぼ全てのロジックを配置しており、ディスプレイ４３０は、インターネット４２０に接続されたブラウザ等のシンクライアントと同程度である。そのような配置は、新型のタブレットコンピュータ等の市販製品をディスプレイに使用することができることを意味している。

この配置では、タブレットコンピュータは、基本的に、ブラウザディスプレイとして使用される。さまざまなウェブページにおけるＨＴＭＬおよびＰＨＰコマンドは、何を表示すべきか、ならびに、いつそれを表示すべきかを決定する。

ネットワーク時間を読み、次のオートリダイレクトコマンド（header( 'Location: page_url.php' ) ）を計算することにより、毎分の開始直後または他の選択された時刻に行われるディスプレイのリフレッシュがウェブページ内にプログラムされる。リフレッシュ毎に、ディスプレイは、表示された時刻を更新し、新しいメッセージを取得し、現在アクティブなリマインダメッセージの文言およびフォントを更新することができる。要求された場合には、ＨＴＭＬ５内に見つかったコマンドまたはその代替物により、音声を再生し得る。

下段のバージョンは、メッセージングロジックの一部をクライアント側４４０に配置する。将来のイベントに関する情報は、ディスプレイのローカルデータベース４６０に格納され得る。その後、ディスプレイのシステム内に配置されたアルゴリズムは、サーバのシステムと通信する必要なく、所与の時刻に何を表示すべきかを決定し得る。ディスプレイは、依然、メッセージの更新を取得するために周期的にサーバと通信する必要があるが、そのような通信の頻度はより低くなり得る。システムのロジックの大部分、特にマスター、ノーマル、グループのインターフェーシング、アカウント管理および全般的なシステム管理のための部分は、依然、サーバ４５０内に配置されている。

実施は多数の方法をもってなされ得る。一方のバージョンにおいて、ソフトウェアコードは、ＡＪＡＸ等の言語を用いて、ディスプレイのブラウザに効果的にダウンロードされ得る。

他のバージョンとして、ディスプレイは、存在する場合には、不揮発性メモリに常駐するソフトウェアアプリケーションを含み得る。このソフトウェアは、ディスプレイが最初にオンにされた時に自動的に実行されるようにされ得る。このことは、電力の遮断および通信の遮断が自動的に対処され得ることを意味している。

図５は、システムで使用した典型的なデータベース５００テーブルのカテゴリを示す。動作の間、サーバに格納されたアルゴリズムは、各ディスプレイ、ユーザおよび状況をどのように扱うかを決定するために、以下のデータベーステーブルにアクセスする。

ディスプレイ５０５のためのテーブルは、ディスプレイに関連付けられた名前およびタイムゾーン等、各単体のディスプレイに関する情報を含む。ユーザ５１０のためのテーブルは、名前、コンタクト情報、パスワードおよびユーザーアカウントの種類を含む、各ユーザに関する情報を含んでいる。このテーブルに現れるユーザは、１台のディスプレイまたは１組のディスプレイ（グループユーザである場合）に関連付けられている。メッセージテーブル５１５は、個々のメッセージの各々がいつどのように表示されるべきかに関する情報、誰がそのメッセージを作成したのかに関する情報、およびメッセージの種類に関する情報を含む、全てのメッセージを保持している。これら３つのテーブルは、システムにより使用されるデータベースの中核を含む。

中核的なテーブルに加えて、重要な補足的なテーブルが多数存在する。ディスプレイチェックテーブル５２０は、各ディスプレイの調子を格納するために使用される。プリセットテーブルは、タイピングをある程度減らすために使用され得る、予め定義されたメッセージを格納する。これらのプリセットメッセージは、メッセージテーブルに格納されたレギュラーメッセージと同じ情報のほとんどの部分を含む。グループリクエストテーブルは、グループユーザがマスターユーザに対しておこなったグループへの加入を求めるリクエストを格納するために使用される。グループハイドテーブルは、特定のグループメッセージが特定のディスプレイ上に表示されるべきかどうかを決定する情報を格納するために使用される。ＯＫボタンテーブルは、そのような応答を要求する各メッセージについて、応答のステータスを格納する。命令テーブルは、ユーザインタフェースのための、ローカライズされた（異なる言語の）命令および文言を格納するために使用される。画像テーブルは、特定のメッセージに関連付けられ得る画像を格納するために使用される。音声テーブルは、特定のメッセージまたは状況に関連付けられ得る適切なフォーマットの音声ファイルを格納するために使用される。

図６は、まず、アルゴリズムおよびデータベーステーブルがどのように協働して全てのディスプレイを管理するかを示す。

周期的にデータベース６００を参照して、現在どのメッセージがアクティブであるかが確認される（６１０）。メッセージテーブル内のエントリが、現在のタイムゾーン、日付および時刻６５０に基づいてメッセージを表示すべきであることを示している場合、そのメッセージはアクティブである。

次に、特定のメッセージがグループユーザから来た場合、グループハイドテーブルにアクセスして（６１５）、このメッセージをこの特定のディスプレイ上に表示すべきかどうかを判定する。

次に、ＯＫボタンテーブルにアクセスして（６２０）、この特定の時刻に応答が要求されるかどうかを判定する。メッセージは、イベントが始まる前の所定時間まで応答を要求せずに表示され得る。したがって、例えば、閲覧者は、イベントが近づいてきていることを知ることができる。しかし、イベントがちょうど行われようとするまでは、閲覧者からの応答は要求されない。

次に、メッセージテーブルおよび他のテーブルに格納されたパラメータに基づき、正確な文言およびフォントの選択がコンパイルされる（６２５）。各状況にあわせていかにメッセージングを調整するかは、科学と言うより芸術の領域と言ってもよいぐらいだが、本開示の重要な要素は、そのような調整がシステムと一体になっている点にある。

次に、メッセージまたは状況と関連付けられた任意の音声が存在する場合、音声テーブルがアクセスされて、適宜メッセージ内にコンパイルされる（６３０）。以前のステップで先に選択された文言およびフォントと同様に、音声もまた調整され得る。

同様に、メッセージと関連付けられた任意のグラフィックスまたは画像が存在する場合、これらもまた６３５に一体にされている。やはり、状況に応じた調整が行われ得る。

最後に、完成した、コンパイルされたメッセージが、ディスプレイ上に表現される（６４０）。これは、以前のステップにおいてメッセージの一部であると判定された任意のテキスト、音声および／または画像を含む。その後、ディスプレイおよびメッセージは、必要に応じて、リフレッシュタイマーに基づいてリフレッシュされる。

図７は、メッセージを特定のディスプレイ上に配置した場合の、グループユーザ７００、マスターユーザＢ７１５およびレギュラーユーザＢ７２０の関係の一部を示す。

最もシンプルな状況は、マスターユーザがメッセージＢ１７３０をディスプレイＢ７６０上に配置しようとする時である。ディスプレイＢがこのユーザによって管理されているので、このメッセージは許可される。ディスプレイＡ、ディスプレイＣ７７０およびディスプレイＤ７８０等のネットワーク上の他のディスプレイは、メッセージＢ１を無視する。同様に、ユーザＢはメッセージＢ２７３５を同じディスプレイＢ上に配置することができる。このユーザは、マスターユーザＢによってそうする権限を与えられたからである。

マスターユーザＢはまた、レギュラーユーザＢによって作成されたメッセージＢ２を編集または削除する能力を有する。レギュラーユーザＢもまたメッセージＢ２を編集することができるが、このユーザはマスターユーザＢよって作成されたメッセージＢ１を編集することはできない。

マスターユーザＢおよびレギュラーユーザＢは、ディスプレイＢに宛てられた全てのメッセージを、それらが現在このディスプレイ上に表示されているか否かに拘わらず、見ることができる。

この図において、グループユーザは、２つのグループメッセージ７０５、７１０を作成するものとして示されている。これらのグループメッセージは、このグループに属する全てのディスプレイ７６０、７７０に送信される可能性があるが、このグループの一部ではないディスプレイ７８０には、ディスプレイ７８０が同じネットワーク上に存在する場合であっても、送信されない。

グループメッセージが任意のディスプレイに宛てられている場合、そのディスプレイに関連付けられたマスターユーザおよびレギュラーユーザは、このメッセージを見ることができる。マスターユーザまたはレギュラーユーザのいずれかが、あるグループメッセージがある予定されているイベントとコンフリクトすると判断した場合、ユーザはこのグループメッセージを隠す能力を有する。個々のグループメッセージは表示するまたは隠すことが許可され得るので、隠されている状態のグループメッセージ２７１０（７５０）とは別個に、グループメッセージ１７０５を隠すことができる（７４５）。このマスターユーザＢおよびレギュラーユーザＢによる判断は、他のディスプレイ７７０、７８０上に何が表示されるかということに影響を及ぼさない。

図８は、特定のディスプレイが特定のグループの一部であるかどうかについて判定する処理のフローを示す。ディスプレイの制御はそのディスプレイのマスターユーザに帰属するので、グループユーザはまず、マスターユーザのユーザー名を要求する必要がある（８００）。マスターユーザが同意する場合（８１０）、グループユーザは、そのマスターユーザに、グループに加入する旨の招待状を電子メールで送信できる（８２０）。この電子メールは、暗号化された鍵の付いた特別なリンクを含み、このリンクをクリックすると、マスターユーザは、そのディスプレイが加入したばかりのグループを表示するウェブページに移動する（８３０）。この観点から、グループユーザのグループメッセージは、マスターユーザがこのディスプレイをグループから排除する（８５０）かまたはその特定のグループメッセージを隠す（８６０）と決断しない限り、当該ディスプレイ上に表示される（８４０）。ノーマルユーザはまた、（ステップ８６０と同様に）個々のグループメッセージを隠すことができるが、グループからディスプレイを排除することはできない。

図９は、図１のバリエーションを示し、ＯＫボタンまたは受領確認システムがどのように動作するかについて説明するために用いられる。まず、リマインダメッセージが、ディスプレイの閲覧者による受領確認の必要性を指定するマスターユーザ９００、レギュラーユーザ９１０またはグループユーザ９１５によって作成される。メッセージは、データベース９８０内に保存され、適切なタイミングでディスプレイ９４０に供出される（９７０）。その後、特定の時刻に、ＯＫボタンが、他の言語的または視覚的なプロンプトと共に表示される（９５０）。あるいは、外部機器９６０を作動して、ある種のアクションを要求し得る。その後、要求された受領確認が閲覧者によりなされて、データベース９８０内にログ付けされる。その後、さまざまなユーザが、ウェブページを介して、受領確認がなされたかどうかを見ることができる。あるいは、サーバは、ショートメッセージ（ＳＭＳ）または電子メールを送信するか、もしくは電話をかけ得る。

図１０は、ディスプレイの典型的なハードウェアブロック図を示す。ディスプレイは、プロセッサ１０００、命令動作および変数のためのメモリ１０４０、ＢＩＯＳのための不揮発性メモリ１０４５、オペレーティングシステム１０５０およびアプリケーション１０５５、電源１０６０およびオプションのバッテリー１０６５、ディスプレイ１０１０およびオプションのタッチパネルシステム１０１５、ならびに、ＷＡＮ／ＬＡＮ１０３５に接続するためのネットワーキング（有線および／または無線）１０３０を含む要素の、典型的なセットから構成される。

このディスプレイは、スタンドアロン製品であるかまたは別の製品の一部であり得る。例えば、このディスプレイは、テレビに内蔵され得る。その場合、タッチパネルユーザインタフェースは、遠隔制御構成と置き換えられ得る。他の要素のほとんどの全てがすでに今日のテレビの一部であるので、これらの要素は共有され且つ活用され得る。

図１１は、リマインダメッセージを入力または編集するための、ユーザインタフェーススクリーンショットの一例を示す。これは、ウェブページの一部またはアプリケーションの一部であり得る。

この例は、メッセージタイトルまたはヘッドラインを入力する場所１１００から始まる。また、説明の第２行目を入力する場所１１０５もある。行数を増やすことができるが、本図面は、これらの２つの部分だけに説明を限定して、閲覧者へのメッセージをシンプルに保つ。

一旦イベントが始まると、メッセージを変更するほうが有用である場合がある。例えば、メッセージは、誕生日に至るまでの日には、「もうすぐあなたの誕生日」であり得るが、誕生日当日には、「誕生日おめでとう」となり得る。このオプションを設けるために、メッセージタイトルおよびメモの第２のセットが与えられる（１１１０）。

その後、各リマインダメッセージは、開始日および時刻１１２０を与えられる。休日および誕生日等のある種のイベントは、実際その日自体についてのイベントなので、イベントは「終日」と指定され得る（１１２５）。

そのイベントが終日イベントでない場合、その次に指定するのは、そのイベントがどれくらいの長さ続くか（１１３０）である。イベントが１日未満しか続かない場合、イベントの長さは分や時間などで特定され得る。イベントが複数の日にわたって行われる場合、特定の日付および時刻１１４０を指定することによって、イベントの終了を定義し得る。

次に、いつディスプレイ上にイベントを表示し始めるか（１１５０）を特定し得る。イベントを表示し始めるタイミングは、イベントの種類ならびにユーザおよび閲覧者の好みに大いに依存しており、イベントの長さに縛られていない。

必要に応じて、イベントへの注意をひくために音声リマインダを再生し得る。このような音声メッセージングをいつ再生し始めるか（１１６０）は、いつイベントを表示し始めるかとは独立に指定することができる。但し、メッセージが視覚的に表示されるまで、音声メッセージングを開始すべきではない。音声メッセージングの種類は独立に選択され得る（１１６５）。

リマインダメッセージの受領確認が要求された場合、ユーザがチェックできるチェックボックスが設けられている（１１７０）。さらに、特定の期間の後に（イベントの終了までに）受領確認がなされていない場合に警告されることをユーザが希望する場合には、その目的のために別のチェックボックス１１７５が提供されている。

ある程度予測可能にイベントが繰り返される場合、システムは、このイベントをどのように繰り返すかをユーザに特定させる（１１８０）。１日毎から１年毎までの多数の繰り返しオプションおよびそれらの間のいくつかのオプションが提供され得る。ＰＣ、ＰＤＡおよび電話システムにおいて使用されるカレンダーシステムとは異なり、ディスプレイの閲覧者による混乱を避けるために、繰り返されるイベントの１回のみを一度に示す。

図１２は、ディスプレイ上に表示することが予定されている全てのメッセージをレビューおよび管理するためにマスターユーザが見る典型的なユーザインタフェースを示す。これは、ウェブページ上で見られ得るか、または、アプリケーションの一部であり得る。

インタフェースは、どのディスプレイを表示しているか（１２００）、ならびに、ディスプレイが配置された場所の時刻等の他の補足情報、および、このディスプレイがグループメッセージを受け入れるように有効化されているかどうか（１２０５）を表示する。

モバイル機器でより使いやすいフォーマットで情報を表示するためのボタン（１２１０）が設けられている（このモードに自動的に切り替えることも可能である）。新規リマインダメッセージを追加するためのボタン（１２１５）または新規インスタントメッセージを追加するためのボタン（１２２０）が設けられている。ディスプレイ自体がその瞬間にどのように見えるかを確認するためのボタン（１２２５）が設けられている。他に、ヘルプおよび使用頻度の低い管理機能を表示するためのボタン（１２３０）が設けられている。

メインテーブルは、このディスプレイについて現在挙げられている全てのアクティブなイベントのサマリーを示す。テーブルの列は、タイトルおよびメモ（１２４０、１２４５）、イベントがいつ始まるか、ならびに、さまざまな時刻においてディスプレイが何をしなければならないかについての情報（１２５０）、イベントがいつ終了するか、ならびに、それらイベントを繰り返すかどうかまたはイベントをどのように繰り返すかについての情報（１２５５）、いつイベントの表示を開始するか、もしくは、イベントが現在ディスプレイ上に表示されているかどうかについての情報（１２６０）を示している。受領確認が要求されるかどうか、または、受領確認がされたかどうか、ならびに、受領確認がなされなかった場合に警告を発するべきかどうかに関する情報も示されている（１２７０）。最後の列は、誰がメッセージを作成したか（１２７５）を示し、且つ、メッセージがこのユーザが編集できるメッセージである場合に編集ボタンを示す（１２８０）。図１２はマスターユーザ用なので、このユーザは、他のマスターユーザまたはレギュラーユーザによって作成されたいずれのメッセージについても編集権限を有している。特定のメッセージが他の誰かによって作成された場合、編集ボタンは少し異なって見えるように形成され得る（１２８０）。

２個以上のイベントが重複またはコンフリクトする場合に表示されるフラグは、ここでは図示していない。異なるユーザが同じディスプレイ上にイベントリマインダを配置しようとすることができるので、あるユーザが他とコンフリクトするイベントを偶然作成することがあり得、よって、そのようなコンフリクトを何らかの形で表示することが重要である。

グループメッセージに対して、編集ボタンの代わりに、そのグループメッセージを隠すかまたは表示するために使用するボタンが設けられている。この場合、メッセージが閲覧可能であれば開いた目１２８５を表示し、そうでなければ閉じた目を表示する。この機能の具体的な実施態様は、ユーザインタフェースのプリファレンスに応じて異なり得る。

図１３は、リマインダメッセージを管理するための同様の図面を示す。この図だけが、それがノーマルユーザにどのように見えるかを示す。ノーマルユーザは自分自身が入力したメッセージしか編集できないので、列挙されたメッセージの部分集合に対してのみ編集ボタンが表示されており（１３００）、他人が作成したメッセージに編集ボタンは表示されない（１３１０）。ノーマルユーザはグループメッセージを隠すことおよび表示することができるので、それを行うためのボタンも表示されている（１３２０）。

図１４は、これらのインタフェースがモバイル機器にどのように見えるかを示す。インタフェース全体のうちの一部のみを表示し、残りの部分はスクローリングまたはページングによって見ることができる。「フルバージョン」のインタフェースを見る手段も設けられている（１４００）。

図１５は、インタフェースがグループユーザにどのように見えるかを示す。用いられた例は１つのグループメッセージを有するだけだったので、１つのメッセージ１５００のみをこのテーブルに示す。マスターユーザやノーマルユーザとは異なり、グループユーザはグループメッセージを編集することができるので、編集ボタンが表示されている。

図１６は、ディスプレイにインスタントメッセージを送信するための典型的インタフェースを示す。メッセージタイトル１６００および詳細用の第２行目１６１０のために場所が設けられている。また、どれくらいの期間メッセージを表示するのかを指定する手段が設けられている（１６２０）。

電話またはＰＣで使用される典型的インスタントメッセージとは異なり、本開示に記載されたディスプレイの種類の閲覧者は、より受動的な閲覧者である。メッセージをディスプレイ上に表示させるための閲覧者によるアクションは要求されないが、その一方で、この人が必ずメッセージに気付くという保証もない。メッセージへの注意を喚起するために、音声通知を指定し得る（１６３０）。あるいは（ここでは図示しないが）、先に説明したメッセージと同様に、受領確認を要求するようにメッセージを作成し得る。

図１７は、システムの管理機能（ここではディスプレイ（図中の名称は「フレーム」）の管理）の一部を示す。各ディスプレイには、名前１７００を与えることができる。その名前は、通常、ディスプレイを閲覧している人の名前である。次は、ディスプレイのタイムゾーンを指定する手段である（１７１０）。あるいは、タイムゾーン情報は、ディスプレイが接続されたネットワークを介して取得され得る。

次に、都市または部屋番号等の何らかの形式での位置の説明を指定し得る（１７２０）。ディスプレイ名および位置の組合せは、各ディスプレイをユニークに特定するのを助ける。

このディスプレイがグループメッセージを受け入れることがＯＫである場合、そのためにチェックボックス１７３０が設けられている。このチェックボックスは、マスターユーザが電子メール招待状をクリックした場合（８３０）に、自動的にチェックが入るが、その後、いつでも、チェックを外すことや再びチェックを入れることができる。

図１８は、プリセットリマインダを管理するためのインタフェースを示す。いくつかのプリセットリマインダが、システムによって定義されており、ここでは管理者から来たものとして示されている（１８２０）。いくつかのプリセットが、マスターユーザ、ノーマルユーザまたはグループユーザによって定義されていてもよい。ユーザが編集権限（通常のリマインダメッセージと同様のルールに従う編集権限）を有する場合、編集ボタンが表示される（１８１０）。

図１９は、プリセットを選ぶための簡単な手段を示す。一旦プリセットが定義されると、新規リマインダメッセージを作成する際に、プリセット用のボタン（図示しないが、図１１に示したのと同様のインタフェース上に現れる）をクリックすることにより、プリセットが選択可能である（１９００）。一旦プリセットが選択されても、その後修正することもカスタマイズすることも可能である。したがって、ユーザは、パラメータ、日付、時刻などの特定のセットに縛られない。

図２０は、所与のディスプレイの組の調子を監視するように設計された低レベル動作を示す。ディスプレイは、偶発的にオフされたり、電力または通信を喪失したり、もしくは、ハードウェアの故障が起きたりし得る。ディスプレイは通常、それを管理する人の近くに存在しないので、ディスプレイの調子についての何らかのインディケーションを得る手段が設けられている必要がある。

そのためにまずはじめに、ディスプレイが、ネットワーク２０２０を介してサーバに周期的な「生存(keep-alive)」信号２０００を送信する。生存信号の周期は、プリセットされ得（２０１０）、ニーズに応じて、あまり頻度が高い必要はない。

サーバ（この図面中では「システム」）は、サーバが監視している全てのディスプレイからの生存信号を受け入れる。それらディスプレイのうちの１台またはそれ以上が生存信号を送信しなかった場合（２０４０）、警告を送信し得る（２０５０）。あるいは、ウェブページを更新して、疑わしいディスプレイの名前および位置を掲載し得る。

その間、ユーザ２０６０は、ディスプレイの近くに存在していないにも拘わらず、ディスプレイのステータスの閲覧および／または警告の受信を行える。

図２１は、低レベルの管理機能、ディスプレイおよびマスターユーザの他のセットアップを示す。

各ディスプレイについて、固有のアカウントを作成する必要がある。このアカウントは、システム管理者によって作成され得る（２１００）。この管理者は、サービスプロバイダまたは工場に居る者であり得る。ディスプレイがこのシステムで動作するように特定的に構成された固有の機器である場合、固有のアカウントコード（おそらくアルゴリズム的に生成される）が、ディスプレイの不揮発性メモリに格納され得る。サービスプロバイダがディスプレイのアカウントを作成している場合、固有のコードを作成するために、様々な手段を用いてもよい。一旦作成されると、これらの固有のアカウントコードは、システムデータベース１６０、５０５にも格納される。

次に、システム管理者は、新しいマスターユーザアカウントを作成する。このアカウントは、固有のユーザー名および特定のディスプレイへのポインタからなる。パスワード（望ましくは、固有のパスワード）も生成される。また、このシステム専用のディスプレイが製造される場合、マスターユーザのセットアップはディスプレイの工場においてなされ得る。あるいは、サービスプロバイダが、マスターユーザアカウントの詳細を作成し得る。いずれの方法でも、この情報は、一旦作成されると、同じデータベース１６０、５１０にも格納される。

次に、新しいマスターユーザは、新しいユーザー名およびパスワードを与えられる。その後、このマスターユーザは、システムにログインする（２１２０）。一旦ログインすると、この人は、新規リマインダメッセージを作成でき（２１３０）、上で説明したように、他のユーザ等を作成することができる。

このステップの前か後に、マスターユーザは、（例えば、アルツハイマー病の人）が使用することを意図して、ディスプレイをインストールする。インストールは、ディスプレイをシステムにログインさせること（２１４０）を含む。システムへのログインは、２つのステップを含む。第１のステップは、ネットワーク接続を確立することである。この接続は、使用するネットワーク接続性の具体的な種類に応じて、多くの方法で達成され得る。接続性は、さまざまな有線（例えば、ケーブルを介したＬＡＮ、電話を介したモデム）または無線の（例えば、Ｗｉ‐Ｆｉ、セル方式、ブルートゥース）手段を介して達成され得る。例えば、Ｗｉ‐Ｆｉ接続を介して利用可能な既存のインターネットサービスがある場合、ディスプレイはまず、このＷｉ‐Ｆｉへのリンクを確立する必要がある。

ディスプレイをシステムにログインさせるための第２のステップは、先に確立されたディスプレイの固有識別コードをシステムに認識させることである（２１００）。このステップは、ディスプレイによって手動または自動的に実行され得る。

手動で実行された場合、ディスプレイ上の画面は、ユーザー名およびパスワード等の、ディスプレイのアカウントログイン情報を要求する。ユーザは、要求された情報を入力するために、さまざまな入力デバイス（例えば、タッチスクリーン、遠隔制御またはキーボード）のいずれかを使用し得る。

自動的に実行された場合、ディスプレイは、その固有の識別情報を不揮発性メモリから読み出し、この情報をシステムに与える。要求された情報がディスプレイの不揮発性メモリに一旦与えられると、ディスプレイの自動ログインは、工場またはマスターユーザのいずれかによってなされ得る。

パスワードは、特に、サーバに与えられる前に暗号化される。暗号化は、プライバシー保護のために必要である。

図２２は、プロトタイプの表示装置を示す。この表示装置は、卓上に配置できるように、スタンド内に設置されている。あるいは、このようなディスプレイは、壁に組み込まれ得るかまたは、テレビ等の他の機器の一部であり得る。

図２および図３と同様に、メッセージングは、各イベントに対する現在時刻に合うように調整されることに留意されたい。例えば、「ジェリーと夕食」は、「２日後」と表示される（２２１０）。これは、火曜日の午後６時である（２２１５）。誕生日は「３日後」である。この誕生日は終日イベントなので、時刻は与えられず、「水曜日」とだけ表示される（２２２０）。

「アリスを訪問する」イベントは、もう少し多くの詳細を表示している（２２３０）。このイベントは複数日イベントであり、「約１週間後」の「１２月１７日」に開始され、３日間続くことがわかる（２２３５）。

これらのメッセージの各々は、それがイベントにどれだけ近いか、ならびに、イベントが開始したかどうかまたはちょうど終了したかどうかに応じて、時間の経過とともに自動的に変化する。

写真が日中に撮影されたので、図示したサンプルディスプレイは白い背景を有する。誰か眠っている人を妨げる可能性を減らすため、夜間には、ディスプレイの背景は黒くなり、そして、フォントカラーはそれに応じて読みやすくなるように調整される。ディスプレイが夜間モードになるタイミングは、任意であり得るか、マスターユーザが選択したオプションにより設定され得るか、もしくは、ディスプレイにより検出されたＩＰアドレスのジオロケーションにより決定されるように、ディスプレイが世界のどこに配置されているかに応じて自動的に調整され得る。

ここで、図３３を参照して、認知能力が低下した人が、来るべきイベントを管理するのを援助するための、コンピュータで実装されたシステムについて説明する。コンピュータで実装されたシステムは、その全体が参照符号１０で示されており、コンピュータシステム１２を含む。コンピュータシステム１２は、本願明細書において分類的な様態で記載されたさまざまな機能を扱うために、１台のコンピュータまたはネットワーク化された１群のコンピュータを用いて実装されてもよい。コンピュータシステム１２は、電子データベース１４と、必要に応じて、データベース１４に格納されたデータを解析するために使用される解析システムとを管理する。データベース１４は、患者についての時刻依存型イベント（およびその他のコンテクスト依存型イベント）に関する複数の情報アイテムを格納するように構成されたデータ記憶装置として機能する。解析システムは、例えば、特定の患者の認知能力における傾向を解析して、患者の認知能力に適合するようにシステムの性能を調整したり、また、患者に関するフィードバック情報を患者の介護者等の関係者に提供するようにプログラムされてもよい。

必要に応じて、いくつかの異なるプレゼンテーション機器が、１人の患者に使用されてもよい。例えば、１台の機器が患者によって操作されるタブレットコンピュータで、もう１台の機器が患者の部屋の壁掛け型のテレビディスプレイであってもよい。システムは、どの機器を用いて患者と対話するかを動的に制御し得る。ある場合には、両方の機器を同時に用いてもよい。システムは、各機器に個別に送信されるプレゼンテーションをカスタマイズすることが可能である。したがって、テレビディスプレイについての複雑さのレベルは、所与の状況において、タブレットコンピュータについて使用されるそれとは異なり得る。システムは、コンテクスト情報と、更には患者の認知能力とを使用して、患者のニーズに対して適宜各ディスプレイを適応させることが可能である。

コンピュータシステム１２はまた、患者に提供される記憶ゲームを生成するようにプログラムされてもよい。したがって、記憶ゲーム生成部１６がコンピュータシステムに接続されているとして図示されている。生成部はまた、コンピュータシステム１２をプログラムすることによって、患者の認知能力に基づいて適切な記憶ゲームを生成し、利用可能とするように実装されてもよいことが理解される。記憶ゲームは、患者の記憶をはたらかせるために大いに役立ち得、患者の病気の進行を遅らせる可能性がある。さらに、患者がゲームをプレイした際に自動的に取得されたフィードバック情報を用いて、患者の現在の認知能力に関する情報が収集され、この収集された情報は、他のシステムによって使用される。このことについては、以下に、より詳細に説明する。

コンピュータシステム１２は、好ましくは、サードパーティアプリケーション開発者が、システム１０と対話（例えば、データベースからのデータの読み出しまたはデータベースへのデータの書き込み）するソフトウェアアプリケーションおよび物理デバイスを開発することを可能にする、一組の標準化された入力／出力およびそれらに付随する通信プロトコルを提示するアプリケーションプログラムインタフェース（ＡＰＩ）をさらに含む。

コンピュータシステム１２はウェブサーバ２２を含み、このウェブサーバ２２により、介護者２６および患者２８がコンピュータシステム１２とやりとりする。この点に即して、タブレット、ラップトップコンピュータ、デスクトップコンピュータ、スマートフォンなどのコンピュータ機器による閲覧および対話のために、ウェブページが提供される。コンピュータシステム１２は、ローカルエリアネットワーク（ＬＡＮ）２４に接続されてもよい。ＬＡＮ２４は、他のコンピュータ機器が、例えば、看護ホームのスタッフ３０によって利用されるワークステーションコンピュータ端末などの、コンピュータシステム１２と通信することを可能にする。

データベース１４は、コンピュータシステムによって実行されるサービスの提供を容易にする予め定義されたデータ構造に従って構築されたデータを格納するように構成されている。データベースは、それぞれが該当コンテクスト属性およびそれに関連付けられたトリガの１つのセットに関連付けられた、複数の情報アイテム（情報コンテンツ）を格納するデータ構造３２を含む。例えば、情報コンテンツの１つのアイテムは、患者が検眼士の予約をしている旨のリマインダメッセージであり得る。そのメッセージに関連付けられているのは、予約がいつ予定されているかを示すトリガデータであり得る。また、そのメッセージに関連付けられているのは、メッセージがどんな機器上で閲覧されているかに基づいてメッセージをどのような大きさで表示すべきか等の、他のコンテクスト属性であり得る。このメッセージの表示の一例として、図３２を参照。

予約が時間的にまだ先である場合、そのイベントについて格納された情報コンテンツは、非常に一般的なテキストリマインダを含み得、１つのレコードとしてデータ構造３２に格納されている。イベントの時刻が近付くと、システムは、イベントに関するより詳細な情報（「あなたの古い眼鏡を持って行く」旨のリマインダ等）を提供し得る。これは、第２のレコードとしてデータ構造内に格納される。システムは、現在のコンテクストに適合するものを選択することによって、情報の適切なアイテムを選択する。

この点に関して、システムはまた、他のデータ構造内に、患者の所在地や任意の該当する医学的状態の属性などの、患者についての現在のコンテクストを格納する。これらは、コンテクストデータ構造３４として図示されている。コンテクスト属性のさらなる詳細について、以下に説明する。コンピュータシステム１２は、どの情報コンテンツを構造３２から取得するかを決定する際に、構造３４内の現在のコンテクスト属性を用いる。

患者の現在のコンテクストに加えて、コンピュータシステムは、患者の認知能力を示すデータを格納する認知能力データ構造３６を更に維持する。これは、例えば、スライディングスケール（例えば、１〜１０のスケール）として表するのに適した相対値として定量化されてもよい。患者の認知能力は、介護者または看護ホームスタッフによる明示的な入力によって評価されてもよい。あるいは、システムは、記憶ゲーム生成部１８からのフィードバックを介して、または、患者が一般的にどれくらい上手くシステムと対話することが可能かを解析することによって、認知能力データ自体を確立することができる。

ある実施形態において、システムは、患者のコンテクスト、技術的コンテクストおよび状況コンテクスト等の具体的な情報を考慮して第三者によって設定されたセットパラメータに基づいて、特定のアプリケーションおよびイベントを自動的に起動する。図２３は、どのアプリケーション／イベントを起動するのか、いつそれを起動するのか、ならびに、どのようにそれを起動するのかを決定するプロセスにおいて考慮される、鍵となる検討事項を示す。コンテクスト情報がパラメータ設定を満たす場合、アプリケーションおよび／またはイベントの実行が開始される。これは、タブレットコンピュータ等のコンピュータ端末上で個人が見るかまたは使用するなんらかの情報または対話を提供する。システムはまた、患者の認知能力に基づいて対話能力のレベルを調節する。目的は、患者またはユーザに、該当しまた時に必要でもある情報およびサービスを得るための、邪魔にならない自動的な手段を提供することである。

図２３において、第三者は、一般に少なくともなんらかの形で介護に関与している個人または団体である。このような第三者は、リマインダを入力すること、テレビ会議を開始すること、画像をアップロードすること、予約を設定すること、ならびに遠隔介護の他の機能に対する権限を有していてもよい。本明細書において、「介護者」という用語は、そのような第三者を指し、家族、医師、看護スタッフなどを含み得る。

図２３に示すように、コンテクストもまた、有用な情報を提供する。システムは、介護者が気付いていないかもしれない他の要因についての知識を持って、イベント／アプリケーションのいくつかを開始することが可能である。これらは、看護ホームまたは他の患者センターにおける現在の状況（カメラ、マイク、看護師／医師による入力、医療センサー等によって検出可能な現在の状況）、アクティブな／利用可能な技術情報（例えば、人の腕時計にリマインダを送らず、それをＴＶに表示する）、ならびに医療情報（医療センサ、現在の医師報告、ユーザによる現状レポートから得られたデータ）を含む。

認知能力
図２３に示すように、患者の認知能力もまた、システムの重要な局面を形成する。患者の認知能力とは、患者が電子システム、タブレットまたはシステムにおける他の機器と対話する能力の（評点スケール上での）現在のレベルである。評点が高い場合、患者は、おそらく自分自身で機器と対話でき、なんらかのコンテクストまたは第三者の支援からの援助をそれほど必要としないかもしれない。評点が低い場合、システムおよび第三者は、より多くの支援を提供し得る。認知能力スケール、およびそれがどのように決定されるかについて、図２９および図３０を参照して以下にさらに説明する。

コンピュータで実装されたシステムは、患者の認知能力を示す電子データレコードを取得し、格納する。ある実施形態において、電子データは、それぞれが０〜１０の範囲などの適切な範囲において数値で表される個別のスキル測定値または評価値（スキル変数）の集まりに対応する。必要に応じて、個別の測定値または評価に基づいて、総合認知能力評点または合計評価を計算し、格納してもよい。

ダイナミックレンダリングシステムは、これらのスキル変数を用いて、患者のスキルセットに基づき最も適当な様態で事実を表現する。この実施形態において、コンピュータのメモリに格納されたスキル変数の集まりは、患者の総合「認知能力」に対応する。

スキル変数は、静的または動的であり得るセットを含む。ある変数は人間のオペレータにより測定または評価され、別の変数はシステムにより履歴観察およびセンサデータに基づいて自動的に評価される。以下は、システムによって利用されるスキル変数のリストである。この点に関し、システムは、これらの変数の全てを要求しないかもしれず、またこの開示の範囲内に含まれるがここには挙げていない他の変数が存在することが、当業者に理解される。
・ 心配レベル
・ 視覚障害またはスキル
・ 短期間記憶スキル
・ 長期間記憶スキル
・ 名前／身近な人の顔を認識且つ記憶していること
・ 読解スキル
・ 注意スキル
・ 時間および空間の検知
・ 発話スキル
・ 聴解スキル
・ 単純な論理的問題を解決する能力
・ 推理スキル（動きおよび事実の通常の暗示された結果を理解する能力）

必要に応じて、これらのスキル変数をコンピュータシステムによってアルゴリズム的に組み合わせて、単一値の「認知能力」スコアを導出してもよい。適切なスコア付けメカニズムは、以下に示すアルツハイマー病の臨床的に認識された段階に基づいてもよい。
ステージ１：障害なし
ステージ２：ごく緩やかに低下
ステージ３：緩やかに低下
ステージ４：穏やかに低下
ステージ５：やや深刻な低下
ステージ６：深刻な低下
ステージ７：非常に深刻な低下

コンテクスト
システムは、認知能力に加えて、患者に該当するコンテクスト情報も考慮する。図２４は、認知能力が異なる人々のための、このコンテクスト依存型のアプリケーション／イベント起動の高レベルフローチャートを示す。（ステップ１）第三者（例えば、家族、友人、介護者）が、情報を入力し、イベントおよびアプリケーションを開始するためのパラメータを設定する。（ステップ２）一旦システムが準備されると、システムは、コンテクスト情報を収集して格納する。イベント等に関するこのようなコンテクスト情報は、好ましくは、患者関連情報、状況／外部情報、イベント／アプリケーション／機器情報という、３つの下位コンテクストからなる。（ステップ３）コンテクストがシステムの準備されたセッティングを満たす場合、イベントが開始され得る。（ステップ４）開始された場合、システムは、患者についての対話レベルをカスタマイズしつつ、アプリケーションを起動する。

ある実施形態において、イベント（アプリケーションやタスクなどであるイベント）のコンテクストは、患者関連コンテクスト、状況または外部条件コンテクスト、技術コンテクストという、３つの下位コンテクストからなり得る。これらのコンテクストの状態は、システムの一部を構成するコンピュータのメモリ内のコンテクストデータ構造内に格納される。

患者関連のコンテクスト
患者関連コンテクストは、患者から入手可能な全ての情報を含む（これに限られない）。この情報は、コンテクストデータ構造内に、データとして格納される。患者関連コンテクストデータの例として、以下のものが挙げられる：
・ センサから得られる医療コンテクスト（例えばバイタルサイン）
・ デジタルの医療記録（履歴）
・ 患者の挙動（例えば、眠っているまたは眠っていない）
・ 患者の位置（例えば、室内において、ディスプレイを見ている）
・ 患者の好み（例えば、音声による開始／通知の好み、サウンド、動画、ＴＶ番組、画像の好み）
・ 家族／介護者の要望

状況または外部条件コンテクスト
状況／外部コンテクストは、患者が外部ソースから入手可能な全ての情報を含む（これに限られない）。この情報は、同様に、コンテクストデータ構造内にデータとして格納される。状況または外部条件コンテクストデータの例として、以下のものが挙げられる：
・ 気象情報
・ 時刻
・ 第三者情報（例えば身元）
・ テレビの視聴および放送中の番組
・ 患者の部屋の他の人

技術コンテクスト
イベントアプリケーション／機器コンテクストは、システムを構成する機器から入手可能な全ての情報を含む。機器自体と通信することによって収集されるこの情報は、同様に、コンテクストデータ構造内にデータとして格納される。技術コンテクストデータの例として、以下のものが挙げられる：
・ タブレット表示装置のステータス
・ 利用可能な帯域幅の量
・ ディスプレイの種類（例えばサイズ）
・ ネットワークの種類
・ 利用可能な他の機器（スマートウォッチ、室内のテレビ、システムの他の構成要素）

技術コンテクストは、将来異なる機器をネットワークに追加して追加の機能を追加し得るので、有用である。例えば、患者または患者の介護者が「私を助けて」ネックレス、新たなテレビ、またはデジタル画像フレームを購入した場合、システムはこれらの新技術を含むコンテクストを認識し得る（例えばマスタータブレット機器の代わりに画像フレーム上に画像を表示するなど、システムがその挙動を修正することを可能にする）。

各イベント／アプリケーションは、特定のコンテクスト（最も一般的なコンテクストの部分集合）を用いて開始される。

ポーリングコンテクスト情報
図２５は、システムが図２４のステップ２から収集するポーリングコンテクスト情報を示す。前述のように、情報は３つのカテゴリに分類される。医療記録などの患者関連の情報は、第三者が手動でシステムデータベースに入力する必要がする。しかし、現在の医療情報は、固定型および携帯型のセンサを介してシステムによりコンスタントに収集される。

一旦全てのコンテクスト情報が収集されると、システムは、データを解析し、第三者によって設定されたパラメータ（図２６）に基づいて、イベントが開始されるかどうかを判定する。開始コンテクストが満たされたと判定された場合、システムは、イベントが起動されるかどうかを評価する。例えば、スケジュールリマインダが特定の時刻にオフである場合、システムは、患者が部屋に居るかどうかを判定する必要がある。患者が部屋に居ない場合、システムは警告を起動しない。しかし、患者が在室中であることが確認された場合、システムはイベントを開始する。同様に、例えば家族がビデオコールをしたいが、コンテクストが（プライオリティランキングに基づいて）現在仮眠時間であることまたは現在医師が治療中であることを示す場合には、システムは警告またはイベントを起動しない。同様に、患者が未だ夕食中であり、投薬が夕食後になされることになっている場合、システムは投薬についてのリマインダを起動しない。

開始イベントの他の例として、以下のものが挙げられる：
・ 人が転倒する
・ 時間が指定されたイベント（例えば、投薬／リマインダ）
・ 睡眠、食事、血圧
・ 第三者による開始
・ 他人の入室
・ 音声コマンド

図２７に示すように、患者の認知能力に応じて、患者の注意を得る方法は、より押し付けがましく明白なものであってもよい。警告が、タブレットディスプレイ画面の方へ患者を引きつけ、その時に、カメラが患者の存在を検出する。その存在が患者であると認識された場合（識別は、顔認識、音声または他の電子識別システムにより実施され得る）、システムは、アプリケーション／コンテンツをシームレスに起動する。イベントを起動すると、システムは、患者の認知レベルを再度考慮して、対話能力のレベルおよび解釈の必要性を適切に調節する。例えば、患者がビデオコールを受信している場合、システムは患者に警告する。患者の機能が完全である場合、システムは、患者がビデオコールを受け入れるかまたは拒否するためのオプションを表示する。認知レベルが低い患者の場合、システムは、ビデオコールを自動的に開始する前に患者の身元を認証するか、もしくは、図２８に示すように、コールを発信している第三者がアプリケーションを自動的に開始し得る。

患者のためのインタフェースをカスタマイズする際に、システムはいくつかの要因（図２９）を考慮に入れる。まず最初に、患者の認知能力は、第三者が手動で入力する必要がある。しかし、患者がシステムを利用し続けるにしたがって、システムは、以前の対話から患者のスキルの履歴を記録し、それに適応するようになる。システムはまた、現在の認知能力を試験するように特に設計されたミニゲームを提供することもでき、したがって、システムは、それがどのようにユーザと対話すべきかを自動的に更新することができる。

加えて、システムは、患者および第三者の個人（例えば、医師、介護者、家族、友人など）の好みを適用する。したがって、患者は、システムのイベントを使用または解釈することが難しくない。システムのインタフェースは、同様に、患者の好みおよび認知レベルに応じて変化する。認知的に（または技術的に）能力不足な人々のためのシンプル且つ自動的なインタフェースから、独立し且つ認知レベルが高い患者のためのより複雑で且つ手動のインタフェースに至るまで広範囲に亘る（図３０）。

アプリケーションの実際の使用（アプリケーションの起動だけでなく、ユーザインタフェース、ボタンおよび／または対話モードの変更も含む）を決定された認知能力ファクタに基づいて調節することは、アプリケーションを患者にとって有用なものにするために重要である。

ある実施形態は、患者の認知レベルの手入力を要求するが、システムは、患者にシステム内で試験を行わせることによって、患者に適応する。この実施形態は、日々変化する認知レベルに合わせて構成されてもよい。システムのパラメータは、第三者によってルーチン的に調節され得る。あるいは、システムは、毎日または毎週または隔週でテストを実施して、患者のニーズに自動的に応じるように構成され得る。

システムのカスタマイズは、コンテクストが開始された時に起動されるイベントに限定されない。システムは、休止状態であるときに、イベントを起動してもよい。例えば、起動が設定されたイベントが無いが、患者が在室中であることが観察された場合、システムタブレットディスプレイは、暗くなるか、画像ショーを表示するか、もしくは、反射鏡になってもよい。

図３１は、システムが、タブレット画面と、イベントデータベースと、複数のウェブアプリケーションと、ＲＦ通信（例えば、ブルートゥース）と、多数の機器（例えば、カメラ、マイク、スピーカ、コンピュータ、携帯機器など）への接続とを含む、一実施形態を示す。システムは、ウェブＡＰＩも表示する。図３２は、起動されたアプリケーション／イベントを含むユーザインタフェースの一例を示す。

必要に応じて、介護者または他の第三者に追加のディスプレイを提供し得る。この追加ディスプレイは、タブレットまたはスマートフォン上に実装され得、患者が何をしようとしているのかに関する情報および患者が過去に行ったアクティビティに関する情報、ならびに患者の医学的状態に関するフィードバックを、介護者に提供する。このフィードバックループは、安心できる情報を介護者に提供する。一般的な使用において、この追加ディスプレイは、患者が使用する機器上に表示される情報とは異なる情報を提示する。患者に対して提示される情報のように、介護者に提示される情報は、データベースシステムに格納された情報に由来する。データベースシステムは、看護ホームまたはヘルスケアプロバイダと関連付けられたサーバによってサポートされてもよく、または、インターネットベースまたはクラウドの計算リソースを用いてサービスを提供するサービスプロバイダによってサポートされてもよい。

追加の説明的な使用事例
開示されたシステムの考えられる用途のいくつかをさらに説明するため、開示されたコンピュータで実装されたシステムにより可能になる以下の使用事例を検討する：
・ 患者がディスプレイを見ているときに起動される、遠隔地の第三者によって開始される動画通信。可聴信号により患者の注意を喚起して、患者をディスプレイに向けることができる。
・ ブルートゥース通信を介して接続された機器から読み取ったデータに基づき、医学的状態によって開始されるアプリケーション（例えば、読み取ったデータが患者が脱水状態であることを示す場合に送信される患者のディスプレイへのメッセージ）。
・ 患者の挙動（例えば、患者が在室中で、眠っていない）の理解によって開始されるアプリケーション。
・ その日の所定の時刻に基づく作動。
・ 外部条件に応じてディスプレイ上に表示されるメッセージ（例えば、屋外が寒いことがわかったことに基づいて、患者に暖かいジャケットを着るように忠告する、もしくは、火事の場合に、緊急メッセージおよび何をすべきかを表示する）。
・ ディスプレイが他の情報を表示しない場合にディスプレイ上に表示される画像（つまり技術コンテクストはコンフリクトを示さず、患者のコンテクストは、患者が画像を楽しんでよいその日の時間帯を示している）。

プライオリティおよびコンフリクト解消
いくつかのアプリケーションが準備された場合、いくつかのコンテクストが同時に満たされるとコンフリクトが起こり得る。この問題を解決するために、各アプリケーション／イベントは、プライオリティのレベルを割り当てられている。同じプライオリティの場合、キューに最初に登録されたものが実行される。

図３４を参照して、患者機器５０とネットワークベースのポータルコンピュータ５５との統合の概要について、ここで説明する。

患者機器
ディスプレイ２００を有する患者機器５０は、概ね上述のように構成されて、認知能力および／または運動能力が低下した人にサービスを提供する。患者機器は、ＷｉＦｉ無線通信ポートまたはセル方式データ通信ポート等の通信ポートを有し、それにより、機器がインターネットを通じて通信することを可能にする。あるいは、機器に表示される情報は、患者の部屋のＴＶ５２に送信され得る。ＴＶ５２は、コンピュータネットワーク通信能力を備え得、それにより、ＴＶ５２はポータルコンピュータ５５と直接通信することができる。あるいは、テレビ５２は、患者機器５０に表示された情報をそっくりそのまま表示するディスプレイとして動作するように構成され得る。後者の場合、ＴＶ５２は患者機器５０と通信状態であり、機器５０がポータルコンピュータ５５との通信を処理する。

図３５は、患者機器のディスプレイ２００上に表示された例示的な画面を示す。この場合、患者機器上で動作するカレンダーアプリケーションによって、例示的な画面が生成される。

患者機器をプログラムする方法
患者機器は、さまざまな異なるハードウェアおよびソフトウェアアーキテクチャを使用して実装されてもよい。タブレットフォームファクター(tablet form factor)が、目下のところ好ましい。

ある実施形態において、患者機器は、ｉＯＳオペレーティングシステム、Ａｎｄｒｏｉｄオペレーティングシステム、ＷｉｎｄｏｗｓＳｕｒｆａｃｅオペレーティングシステムまたは他のシステムを使用するタブレットコンピュータを用いて実装されてもよい。このような実装において、患者機器は、ネイティブな機器のオペレーティングシステム（例えば、ｉＯＳ、Ａｎｄｒｏｉｄなど）上で動作するアプリケーション（アプリ）として実装されてもよい。

別の実施形態において、患者機器は、ハードウェアインタフェースレイヤを含むスタンドアロンアプリケーションとして患者機器ソフトウェアを実行して、スタンドアロンアプリケーションが、ディスプレイ２００に画像を送信し、ディスプレイに関連付けられたタッチスクリーン機器を介してタッチインタフェースコマンドに応答できるようになる、タブレットコンピュータを用いて実装される。

患者機器は、図４３に示すソフトウェアアーキテクチャを用いる。このソフトウェアアーキテクチャにより、患者機器のプロセッサは、ここに記載する機能を実行するようにプログラムされる。もちろん、異なるアーキテクチャを用いてもよい。図示のとおり、ソフトウェアアーキテクチャは、ネイティブな機器オペレーティングシステム２３１に基づき構築されてもよい。アップデータ２１３は、予め定義された時間周波数でポータル５５に接続して新しいラッパー２１５ソフトウエアリリースを探す、専用のソフトウェアコンポーネントである。

ラッパー２１５は、低レベルのネイティブな機器オペレーティングシステム２１１をＵＩおよびアプリケーションレンダリングパッケージに接続する専用のミドルウェアである。ラッパー２１５は、ローカルバッファを遠隔ポータル５５に同期させるための機器ＡＰＩを実装する。これらのＡＰＩは、機器の認証と、アクティビティ、メッセージ、画像および動画のダウンロードと、ユーザ設定およびカスタマイズ事項のダウンロードと、最新のバンドル２１７の点検およびダウンロード（ＵＩ設計および機器固有のアプリケーションを含む）とを含む。

ラッパー２１５は、バンドル２１７を介して提供されたコードおよび情報を実行する。機器に表示される最終的なＵＩは、ロードしたバンドル２１７情報、ならびに、ズームレベル、有効化／無効化されたアプリ、ボリュームレベル、有効化／無効化された音声合成(Text-to-Speech)、お気に入りのアプリケーション、新規なイベントプロンプトオプション等の機器固有の設定に応じて、完全にカスタマイズ可能である。

バンドル２１７は、全てのＵＩおよびアプリケーション固有のコードを含む。システムは、各ディスプレイについて、対象を非常に絞ったバンドルの配布を可能にする。これにより、フォント、新規なアプリケーションの作成、全てのグラフィックコンポーネントのリサイズおよび再配布など、あらゆるユーザインタフェースアスペクトをカスタマイズすることができる。

したがって、バンドルは、全てのイベントクエリおよび表示ロジックを含む。ラッパーは、バンドルを開始し、バンドルを更新し、オペレーティングシステムに関連する機能をバンドルに提供する（例えば、音声合成、リブート、ＷｉＦｉリスタート）。アップデータは、ラッパーの更新を許可し、ラッパーを開始する。

このアップデータ―バンドル―ラッパー構成を実装する際、Ａｎｄｒｏｉｄオペレーティングシステムに基づくある実施形態が以下のように構成されてもよい。
アップデータ：アップデータは、患者機器に手動でインストールされる。アップデータは、目に見えるユーザインタフェースを提供せず、通常は更新を要求しない。アップデータは、患者機器がブートされると開始または起動されるか、もしくは、患者機器の画面上に表示された適切なタッチ可能なアイコンを介してユーザにより開始されてもよい。一旦開始されると、アップデータは、（利用可能であれば）ラッパーを開始し、所定の時間間隔毎（例えば１０分毎）にラッパーの更新がないかチェックする。インストールされたラッパーが無いせいでネットワーク障害が生じた場合、アップデータは、より頻繁な間隔（例えば１分毎）で再チェックする。アップデータは、新しいラッパーをインストールする。

ネイティブなオペレーティングシステムがＡｎｄｒｏｉｄオペレーティングシステムである場合、アップデータはＡｎｄｒｏｉｄＡＰＫを用いて実装されてもよい。Ａｎｄｒｏｉｄサービスは、そのアラームマネージャにより、１０分毎に実行されるようにスケジュールされている。また、ＡｎｄｒｏｉｄＡＰＫを用いて、サービスの実行をスケジュールし、且つ、ラッパーアクティビティを開始する。また、ＡＰＫを用いて、レシーバハンドリングオンブートメッセージ(receiver handling onboot message)および開始アクティビティ(starting activity)をブロードキャストする。
ラッパー：ラッパーは、アップデータにより自動的にインストールされる。それは、目に見えるアイコンを有しておらず、常にアップデータにより開始される。ラッパーは、新たなバンドルをチェックし且つインストールする。ラッパーは、システムリスタートを周期的に実行し、また、ＷｉＦｉリスタートを周期的に実行する。これらのステップを実行することにより、何らかの理由でネットワーク接続が失われた場合に、患者機器が強制的に接続状態を再確立することが確実にされる。ラッパーはまた、図４５に示すように、クラッシュ報告メッセージをポータルコンピュータに送信する責任がある。
バンドル：バンドルは、ラッパーにより自動的にインストールされる。バンドルは、ＨＴＭＬ５、ＣＳＳ、ＪＳ Ａｐｐ等のプロトコルをサポートする。アップデータやラッパーとは異なり、バンドルは、例えばカレンダの形で、患者機器上で現実に見ることが可能である。バンドルは、イベントＡＰＩを使用し、且つ、全てのイベントの表示を処理する。バンドルはまた、ラッパーにいかなる表示設定変更も通知する。

バンドルは、ＨＴＭＬ５、ＣＳＳで、ジャバスクリプト（ＪＳ）圧縮されたｔａｒファイルとして実装される。バンドルは、
ＡＪＡＸリクエスト、
Ｚｅｐｔｏ．ｊｓ
ＪＱｕｅｒｙ（例えば、ＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒのみ）
ＴＴＳおよび設定プラグインとのＣｕｓｔｏｍＪＳ通信
等のプロトコルおよび技術を使用し且つサポートするように構成されてもよい。
以下のＨＴＭＬ５ ＡＰＩがサポートされている：
ファイルシステム（Filesystem）
ウェブストレージ（Webstorage）
オーディオ（Audio）
ファイルライター（File Writer）

アップデータ―ラッパー―バンドル機構がどのように動くかについて更に説明するため、ここで図４６〜図５０を参照する。図４６は、患者機器がそのブートアップシーケンスを終えたあとに実行されるアップデータブロードキャストレシーバ動作を示す。プロシージャは簡単である。アップデータアクティビティ開始プロシージャが起動されることにより、アップデータがロードされ、実行される。すると、アップデータブロードキャストレシーバプロシージャが終了する。

図４７に示すように、次にラッパーが開始される。プロシージャは、まず、（もしあれば）クラッシュ報告を送信し、レポート送信がうまく送信されたことをテストし、その後、クラッシュ報告のローカルコピーを削除する。その後、プロシージャは、下位ハードウェアへのルートアクセスが作動可能かどうかを確認する為にテストを行う。作動可能でない場合、ユーザへのレポートが生成され、ラッパーアクティビティスタートシーケンスが終了される。このユーザへのレポートは、トラブルシューティングを目的として提供される。患者機器の通常のユーザは、このメッセージを理解することを期待されていない。

ルートアクセスの確立に成功した場合、ラッパーアクティビティスタートプロシージャは、機器自動アップデートを無効化し、ＷｉＦｉリブートのスケジュールを設定し、ダウンローダをリスタートしその後実行する。変更された設定はまた、図示したように、リブートを開始する。

ラッパーのダウンローダアクティビティを、図４８に図示する。ダウンロードされる新たなバンドルがない場合、ラッパーアクティビティは、所定の期間、単にスリープ状態であり、その後、新たなバンドルが存在するかどうかを確認する為にテストを再度行う。新たなバンドルが存在する場合、バンドルがダウンロードされ、アクティビティダウンローダは、ファイルが適切にダウンロードされたかどうかを確認する為にチェックする。ここでは、ダウンロードされたコードが転送の間に改変されなかったことを保証するために、ファイルのＭＤ５チェックサムをチェックすることを含む。その後、コードがインストールされ、プロシージャは所定の期間再びスリープ状態に入る。ダウンロードプロシージャまたは次のテストおよびローディングプロシージャのいずれかが失敗した場合、アクティビティダウンローダは、異なる所定の期間スリープ状態に入る（失敗後スリープ期間）。

クラッシュ処理ラッパーアクティビティプロシージャを図４９に示す。クラッシュが発生すると、ラッパーは、クラッシュ発生時のタイムスタンプを含む、関係する例外（エラー）情報を収集する。この例外情報はローカルストレージに保存され、所定時間（例えば１０秒）後に機器をリスタートさせるように、アラームのスケジュールを設定する。しばしば、クラッシュまたは例外は、ネットワーク接続の断続的な喪失に起因し得る。したがって、スケジュール設定されたリセットは、リブートすることによりこの問題に対処するように、クラッシュ処理プロシージャ内にプログラムされる。

バンドル機構により用いられるプロシージャを図５０に示す。このプロシージャは、設定が更新されることになっている場合に、患者機器上でバンドルにより実行される。プロシージャは、ポータルコンピュータ（サーバ）から新しい設定を取り出し、ポータルコンピュータが、適切な認証情報(credentials)を新しい設定に関連付けたことを保証するために（これらの新しい設定がこの機器に向けられたものであることを保証するために）テストを行い、その後、いずれかの設定が実際に変更されたかどうか判定するためにチェックが行われる。いずれかの設定が実際に変更された場合、設定が更新され、ラッパーコードが通知される。認証情報をチェックする際、患者機器が必要な認証情報を以前に与えられていた場合、機器のユーザは何もする必要がない。しかし、認証情報が存在しない場合、または、それらがポータルコンピュータからの指定にマッチしない場合、ユーザは、ログイン画面で、必要な認証情報を入力することを促される。更新の詳細をチェックする際、設定が変更されなかったとバンドル設定更新プロシージャが判定した場合、プロシージャは、所定のリフレッシュレート期間の間、スリープモードに入る。

非限定的な例として、以下のリフレッシュレートを確立してもよい。これらは全て、ポータルを介した対話によりプログラム的に変更されてもよい。

設定管理
上記のテーブルにおいて、以下の設定を、ポータルコンピュータを用いて変更または設定してもよい。
・ リフレッシュレート：ポータルコンピュータ（サーバ）からのカレンダイベントリフレッシュ
・ プリファレンスリフレッシュレート：ポータルコンピュータからの設定リフレッシュ
・ 有効化されたＴＴＳ：アプリケーション（例えばカレンダー）音声合成を有効化／無効化する
・ ソフトウェア更新レート：バンドル更新チェックレート
・ ソフトウェア更新失敗レート：失敗時およびカレンダーが無い場合のバンドル更新チェックレート
・ リブートレート：周期的リブートレート
・ ＷｉＦｉリスタートレート：周期的ＷｉＦｉリスタート

ポータルコンピュータ
ポータルコンピュータは、ネットワーク化されたコンピュータ、または、適切なネットワーク接続を通じて患者機器５０と通信する統合されたコンピュータの集まりである。例えば、ポータルコンピュータおよび患者機器は、仮想プライベートネットワーク（ＶＰＮ）接続を用いるなど、インターネットを介してセキュアチャネルを通じて通信するようにプログラムされてもよい。患者機器とポータルとの統合を実装するために使用されるデータが格納されるデータベースとして機能するようにプログラムされたデータストレージシステム５６が、ポータルコンピュータに関連付けられている。必要に応じて、ポータルコンピュータは、上記のコンピュータシステム１２（もしくはサーバ１５０およびデータベース１６０）を用いて実装され得る。あるいは、別個のコンピュータを用いてポータルコンピュータ５５を実装してもよい。

家族（または介護施設のスタッフ）は、ポータルコンピュータと対話することにより、患者機器５０のユーザインタフェースをカスタマイズし、特定のコンテンツまたは特定のアプリケーションを選択し、遠隔制御により患者機器を直接制御する。ポータルコンピュータにより入力された情報は患者機器５０に対してプッシュされ、機器が患者によってどのように使用されているかに関するフィードバックがポータルコンピュータに送り返される。

一般に、ポータルコンピュータ５５は、そのデータストレージシステム５６内に、ＵＩ要素の集まりまたはキット、ならびに、デジタルコンテンツ（例えば、画像、動画、音楽）および患者機器５０に対してプッシュされ得るアプリケーションプログラム（そのアプリケーションプログラムはその後患者機器５０において実行される）を、格納する。これを行うため、ポータルコンピュータ５５は、家族または介護施設スタッフが患者機器が機能する方法をカスタマイズすることができるように機能する。このようなカスタマイズは、以下の３つのカテゴリに分類されてもよい：ＵＩ要素のカスタマイズ（概略的に参照符号６０で示す）、コンテンツおよびアプリケーションのカスタマイズ（概略的に参照符号６８で示す）、遠隔制御能力（概略的に参照符号７０で示す）。

選択されたＵＩ要素、アプリケーションおよびコンテンツを含むカスタマイズ事項は、ポータルコンピュータから患者機器に対してプッシュされる。ポータルコンピュータは、全てのＵＩ要素設定情報および所与のアプリケーション選択情報を格納するデータ構造を含むパッケージを組み立てる。パッケージは、さまざまな異なるデータ圧縮アルゴリズムのいずれかを用いて圧縮され、その後、セキュアチャネルを介して患者機器に送信されてもよい。患者機器は、パッケージを復元し、そこに含まれている要素設定情報およびアプリケーション選択情報を抽出する。その後、これらのデータは患者機器のメモリ内のバッファに配置され、その一方で、機器の現在の設定が、バックアップのために患者機器のメモリ内に保存される。その後、バッファに配置されたデータが現在の要素設定およびアプリケーション選択設定とスワップされ、任意の実行中のアプリケーションは、リブートするか、さもなければ新しい設定をリロードするように命令される。

データパッケージはまた、患者機器上で実行される実行可能なアプリケーションの実際のコピー、ならびに、家族によって提供された画像、音楽、動画および他のマルチメディアコンテンツ等のコンテンツも含み得る。ポータルコンピュータが患者機器の状態を保存するので、ポータルコンピュータは、実行可能なアプリケーション（保存された状態情報に応じて患者機器に既に存在している）のコピーを再送信しない。家族または他の介護者が、特定の実行可能なアプリケーションを隠すかまたは患者機器から削除することを選択した場合、アプリケーション選択設定は、ポータルコンピュータから患者機器に送達されたパッケージ内に格納される。このアプリケーション選択設定は、患者機器から記憶領域を取り戻す必要があると考えられない限り実際にアプリケーションを患者機器から削除すること無く、実行可能なアプリケーションを見せなくすることにより、患者機器によって実施される。したがって、家族または介護者がアプリケーションを再有効化することを後に決定した場合、それは単にアプリケーション選択設定を介してスイッチオンされるだけであり得、患者機器に対して再度プッシュされる必要はない。

ポータルコンピュータをプログラムする方法
ポータルコンピュータは、インターネットを通じて通信するように接続されたネットワーク化されたコンピュータによって実装されてもよい。ポータルコンピュータは、少なくとも一つのプロセッサと、ポータルコンピュータにここで説明する機能を実装させるプログラム命令が格納される、関連付けられた一時的でない(non-transient)メモリとを有する。好ましくは、ポータルコンピュータは、ディスプレイモニタと、キーボード、マウスおよび／またはタッチスクリーン等の適切な入力デバイスとを備えている。

ポータルコンピュータは、以下のソフトウェアアーキテクチャを使用する。このソフトウェアアーキテクチャにより、ポータルコンピュータのプロセッサは、ここで説明する機能を実行するようにプログラムされる。もちろん、異なるアーキテクチャを使用してもよい。

ポータル通信ソフトウェアアーキテクチャを図４４に示す。図示のとおり、ポータルコンピュータとして動作しているネットワーク化されたコンピュータは、患者機器との間でメッセージの送受信を行う。図４４は、ポータルコンピュータおよび患者機器のＡＰＩがどのように構成されて、このメッセージングを介して対話するかを示す。ポータルソフトウェアＡＰＩの更なる記述を、ここで説明する。

図４４に示すように、ポータルコンピュータは、ラッパー更新ＡＰＩ２１９を含むように構成されている。ラッパー更新ＡＰＩ２１９は、患者機器上のアップデータ２１３と通信し、いつ新たなラッパーが送達されて患者機器にインストールされるかを示すために使用される「新しいバージョンのラッパーをチェックする」メッセージを仲介する。ポータルコンピュータはまた、患者機器上で実行されるイベントを仲介するイベントＡＰＩ２２１を含む。イベントＡＰＩは、「ログイン」、「イベントリストを入手」および「カレンダプリファレンスを入手」を含むメッセージに応答する。イベントＡＰＩはまた、患者機器に対してプッシュされた他のアプリケーションで、同様のメッセージを処理する。ポータルコンピュータは、「新しいバージョンのバンドルをチェックする」メッセージを介して患者機器におけるバンドルの更新を仲介するバンドル更新ＡＰＩ２２３を更に含む。最後に、ポータルコンピュータは、追加のポータルソフトウェアＡＰＩ２２５を含む。これら追加のポータルソフトウェアＡＰＩ２２５により、ポータルコンピュータは、インターネット上で利用可能なクラウドサービス等の他のシステムと接続され得る。

図４５を参照すると、ポータルコンピュータはまた、患者機器から送信されたクラッシュ報告のログ付けを行うセントリークラッシュ(sentry crash)報告モジュール２２７を含む。このようなクラッシュ報告は、例えば、ネットワーク接続の断続的な喪失などにより先に説明したアップデータ―ラッパー―バンドル機構が適切に動作しない場合に生成されてもよい。クラッシュ報告はまた、例えば、カレンダーアプリケーション等の、患者機器上で実行中のアプリケーションから送信されてもよい。

ポータルソフトウェアＡＰＩの記述
Login − サーバ上のクライアントを認証する方法を提供する。一旦認証されると、ＡＰＩＫＥＹは返される。この鍵は、ほぼ全ての他の方法のための認証として使用される。
Params：
username：Resident Display Login, 居住者のディスプレイタブレットにおいて得られる；
token：Resident Display Password, 居住者のディスプレイタブレットにおいて得られる；
uhid：UNIQUEハードウェア識別子。システムはユーザ１人あたり１台の機器のみを受け入れる。逆もまた同様。

Log out − これは、以前に取得したＡＰＩＫＥＹを無効にする。
Params：
apikey：/login方法で得られたAPIKEY。

get_update_version − このクライアントについて最新の利用可能なバージョンのバンドルを返す。
Params：
apikey：/login方法で得られたAPIKEY。

get_wrapper_update − 最新バージョンのラッパーを返してダウンロードする。この場合、識別としてＡＰＩＫＥＹの代わりにクライアントＵＨＩＤを使用する。この時点において、クライアントは未だログインしていない。
Params：
uhid：UNIQUEハードウェア識別子。システムはユーザ１人あたり１台の機器のみを受け入れる。逆もまた同様。

Sync_Api − クライアントが必要とする全てのデータを提供する。これは、設定、イベント、メッセージおよび他のメディアリソース（写真、音楽および動画）を含む。この方法への各リクエストは、E-Tagという名前のヘッダフィールド内のＳＨＡ１ハッシュを返す。

このハッシュが、次のリクエストに使用される。サーバは、この情報を用いて、以前に提供されたコンテンツに変更があったかどうかを判定する。変更があった場合、新しいデータが、200ステータスコードと共に返される。変更がなかった場合、304が返される。これは、サーバＣＰＵの使用を減らすだけでなく、帯域幅も節約する。

メディアリソース（画像、音楽および動画）は、ローカルに格納されることになっている。各メディアは、システム全体において固有の名前を有する。
Accept：所望の応答フォーマットを示すために使用され得る。
On4-Token：/login方法で得られたAPIKEY。
On4-Version：アプリケーションバージョン。
On4-TzOffset：ＵＴＣ時間と現地時間との時差（秒）。現地時間がＵＴＣ時間よりも遅い場合には、マイナスの符号を用いる必要がある。
On4-Position：機器の緯度および経度。この情報を用いて、正確な気象情報を機器に提供する。
On4-Time：現在のＵＴＣタイムスタンプ。ＮＯＷについて、値０（ゼロ）が受け入れられる。サーバは、この時間から３日先までのイベントを返す。
If-None-Match：最後のリクエストから得られたE-Tag値、もしくは、第１のコールが提供されるか何も提供されない場合にはエンプティ。

ＵＩ要素のカスタマイズおよび能力点数
患者機器５０を使用するときに患者が対話するユーザインタフェースは、家族（またはスタッフメンバー）によって選択された後患者機器に対してプッシュされ得るＵＩ要素６２のキットからなる。ＵＩ要素は、データストレージシステム５６に保存されており、ユーザインタフェース要素の特別に選択されたセットを構成する。これらユーザインタフェース要素の各々は、所与のレベルの認識能力および／または運動能力にマッチし、患者が毎日必要とする情報を患者に提供し、家族および患者が連絡を取りあうことを可能にするように、等級付けされている。

家族または看護スタッフが所与の患者のニーズに対して適切なＵＩ要素を選択することを容易にする為に、キット６２内の個々のＵＩ要素６４の各々には、認知能力および／または運動能力点数６６が少なくとも一つ関連付けられている。能力点数は、そのＵＩ要素を使用する際にユーザが有する難易度に基づき、数字のスコアを各ＵＩ要素に割り当てるものである。キット６２は、自動のＵＩ要素から、使用がきわめて簡単なＵＩ要素や、使用するのは高度であるＵＩ要素に至るまで、さまざまな冗長であったり機能が重複するＵＩ要素を含むので、特定の患者の能力に対して適切なものが選択され得る。

必要に応じて、各ＵＩ要素に複数の点数を関連付け得る。したがって、認知能力点数に加えて、運動能力点数（視力、聴力、手の器用さ）を関連付けてもよい。異なるアプリケーションまたはコンテンツの難易度にランク付けするために、適用可能であれば、認知能力および他の能力点数を適用してもよい。

例えば、高い認知能力および高い運動技術を有するユーザは、画像閲覧アプリケーションでどの写真を見たいかを選択するために、ドロップダウンメニューのＵＩ要素をどのように使用するかを理解するのに困難は無いかもしれない。より能力の低い人は、ドロップダウンメニューを操作できないかもしれないが、どのように前進ボタンおよび後退ボタンを用いて、一旦患者のために自動的に選択された写真をブラウズすればよいかについては理解できるかもしれない。さらに能力の低い人は、いかなるＵＩ要素も操作できないかもしれない。その場合、アプリケーションが自動スライドショーを実行する。自動スライドショーにおいて、写真は、患者によって制御されない、予め定義されたレートで選択される。

これは、図３６ａおよび３６ｂに図示されており、患者機器に対してプッシュされた基本の写真閲覧アプリケーションを備えている。図３６ａは、平均的な視力および並の認知能力を有する患者のためにカスタマイズされたディスプレイを示す。したがって、図３６ａにおいて、日および時刻は「通常の」大きさの文字で表示され、「次の写真」、「前の写真」および「前に戻る」のボタン８０が表示され且つアクティブである。この患者にとって、左側を向いたボタンを押して「戻る」および右側を向いたボタンを押して「進む」という見込みは、困難な作業ではない。

それに対して、図３６ｂのユーザインタフェースは、視力が平均未満であり且つ認知能力が限られた（またはおそらく手の器用さが限られた）人のためのポータルを用いてカスタマイズされている。したがって、日および時刻は、「大きい」サイズで表示され、「次の写真」、「前の写真」および「前に戻る」のボタンは隠されている。ボタン８０の除去を説明するために、写真閲覧アプリケーションのスライドショー機能８２は「自動」に切り替えられており、これにより、第１の画像から次の画像へ、またその次の画像へと、画像が自動的に循環される。この場合、患者は画面を見ればよいだけである。押すべきボタンは存在しない。

認知能力点数および他の能力点数の使用
ＵＩ要素のフルキットを提供することにより、ポータルコンピュータ５５は、各患者のために高度に洗練され且つ高度にカスタマイズされたユーザ経験を選択的に組み立てることができる。しかし、異なる能力点数レベルにある、このような多数の異なるＵＩ要素を有してしまうことには、困難がないわけではない。典型的な家族または看護スタッフは、ユーザインタフェース設計において、ほとんどまたは全く経験が無いかもしれない。

したがって、ＵＩをカスタマイズするプロセスを単純化するために、ポータルコンピュータは、認知能力点数（および他の点数）に応じてＵＩ要素をソートおよびランク付けし、それにより、患者機器のユーザインタフェースをカスタマイズしようとしている人に、適切なものが最初に提供される。図４２ａおよび４２ｂは、これがどのように達成されるかについて、２つの別の実施形態を示す。図４２ａにおいて、ディスプレイ５７は、患者機器のディスプレイに表示されているもの（この場合、カレンダーアプリケーション（参照符号８１））のイメージを、クロック―日付―天気ヘッダ（参照符号８３）と共に提示する。患者機器のディスプレイの右辺に沿って、アプリケーションセレクタ８５が設けられている。アプリケーションセレクタ８５において、アプリケーションに対応するアイコンは、患者機器に対してプッシュされるために利用可能である。ディスプレイ５７はまた、各アプリケーションの能力点数が表示されるランキングウインドウ８７を含む。なお、クロック―日付―天気ヘッダは、画像アプリケーション（４の点数を有する、すなわち難易度が平均を超えている）と比較して、このインタフェース要素が比較的使い易いことを示す「２」の点数を有する点に留意されたい。ランキングウインドウは、特定の患者の実際の使用統計値もしくはアグリゲーションサーバコンピュータ７４（図３４）によって生成された合計統計値のいずれかに基づき得る、システムによって割り当てられた点数を示すことが理解される。複数の異なる点数が実装されている場合（例えば、認知能力点数および運動能力点数）、ポータルコンピュータのユーザは、家族または看護スタッフが、適切なラジオボタン（参照符号８９）を選択することによって点数を切り換えることを許可する。これらのボタンのいずれかを選択することにより、表示されたアプリケーションのランキングを切り換えて、選択された選択肢を反映する。

図４２ｂは、患者機器に対してプッシュするために選択するアプリケーションを提示する異なる方法を示す。この実施形態において、アプリケーションセレクタウインドウ９１は、全ての利用可能なアプリケーションを列挙する。列挙されたアプリケーションは、所望の点数のラジオボタンの選択（参照符号８９）に基づき、能力点数の順にソートされている。その後、家族または看護スタッフは、選択されたアプリケーションを、プッシュウインドウ９３までドラッグし得る。こうすることにより、プッシュウインドウ内のアプリケーションは、患者機器に対してプッシュされるアプリケーションとしてマークされる。この場合、３つのアプリケーションが選択されている。ポータルコンピュータは、プッシュウインドウにドラッグされたアプリケーションに基づいて、平均難易度および最大難易度を表示する。これにより、家族または看護スタッフは、選択されたアプリケーションのパレットが患者に課す難易度を容易に理解することができる。

あるいは、ポータルコンピュータ５５は、以前に得られた患者の能力についての知識に基づき、自動的に適切な構成を選択するようにプログラムされる。この演繹的な知識は、後述するように、患者機器からの使用統計値のフィードバックから得られる。

アプリケーション選択に関して基本的な選択が一旦なされると、ポータルはまた、より詳細な画面を提供する。この画面により、家族または看護スタッフは、特定のアプリケーションに特有のさらなる詳細を設定することができる。この点に関して、図３８および図３９は、基本的な表示およびユーザ対話機能を設定するための例示的な画面を示す。図３９は、図４２ｂのものと同様の、アプリケーション選択構造９１および９３を含む。図４０は、患者機器に対してプッシュされるコンテンツのリストに音楽および動画コンテンツを追加するために使用される、別の例示的な画面を示す。図４１は、家族または看護スタッフにより、患者が定期的に通信したい人と共に、Ｓｋｙｐｅ等のメッセージングアプリケーションをプリセットするために使用される例示的な画面を示す。

遠隔制御
いくつかの場合においては、家族はアプリケーションまたはコンテンツを患者と共有したいかもしれないが、そのアプリケーションまたはコンテンツのためのユーザインタフェースは、患者の認知能力を超えているかもしれない。このような場合、ポータルは遠隔制御能力を提供し、それにより、家族はポータルを介して操作して、患者機器に提示されるものを直接制御できる。

例えば、患者機器を介した通話またはビデオチャットの間、家族は、以前患者機器に対してコンテンツとしてプッシュされた数枚の画像を患者に見せたいかもしれない。遠隔制御能力を用いると、家族は、例えばスライドプレゼンテーションアプリケーションを直接起動して、患者に画像を見せることができる。

使用データの収集、フィードバックおよび合算
使用データの収集およびフィードバックのコンセプトは、患者機器―ポータルコンピュータ統合にとって重要である。患者が患者機器を使用すると、どのアプリケーションおよびコンテンツが閲覧されたかならびにそれはいつのことか、またどのＵＩ要素が使用されたかならびにそれはいつのことかを示すデータが、リアルタイムに収集される。その後、これらの収集されたデータは、フィードバックとしてポータルコンピュータに通信される。

フィードバックは、いくつかの点において重要である。第一に、特定のユーザインタフェース要素、コンテンツまたはアプリケーションが使用されていない場合、または患者により誤って使用されている場合に、フィードバックは家族に警告する。これにより、家族は、ユーザインタフェース、コンテンツおよびアプリケーションが患者の認知能力によりマッチするように、カスタマイズすることができる。図３７ａおよび図３７ｂに示すように、患者機器から提供されたフィードバックは、さまざまな方法で家族に提示され得る。２つの方法について説明した。

図３７ａにおいて、ポータルコンピュータに取り付けられたディスプレイ５７は、患者機器上に表示される、画面のイメージを提供する。このディスプレイは、リアルタイムに更新されて、患者が現在何をしているかを表示する。この場合、患者は、最後に「カレンダー」ボタンを押して、カレンダーアプリケーションを閲覧している。図３７ｂは、代替の「ヒートマップ」図を示す。ここで、患者機器のユーザによって作動され得る各ＵＩ要素はオーバレイと共に示されており、ＵＩ要素の各々が最後の測定期間の間にどれくらいの頻度で使用されたかについてのヒートマップまたはグラフィック比較図を示している。図３７ｂにおいて、異なる大きさの円の形状のグラフィック表示が、相対的な使用統計値を示すために使用される。円が大きくなるほど、そのＵＩ要素の使用頻度は高い。必要に応じて、グラフィック表示と共に、またはグラフィック表示の代わりに、数字の統計値を表示し得る。もちろん、ヒートマップをグラフィックで表現する他の方法を用いてもよい。

第２に、フィードバックはまた、クラウド７２内のインターネットベースのアグリゲーションサーバコンピュータ７４（図３４）に送信されてもよく、ここで多数のユーザに亘って使用点数統計値が合算される。その後、合算されたデータを用いて、ＵＩ要素の各々について認知能力点数を更新する。このようにして、各ＵＩ要素の難易度は、時間の経過とともに集められる使用統計値に基づいて微調整される。必要に応じて、合算データは、重み付けされ、特定の患者からの使用データと組み合わされ、混合された認知能力点数が提供され得る。

これらの合算されたデータはまた、特定の患者のための「おすすめの」ユーザインタフェース構成を自動的に構成するときに、ポータルコンピュータ５５により使用される。これを達成するために、ポータルコンピュータは、患者機器に対してプッシュされ得るポータルコンピュータに格納されたアプリケーションの各々についておすすめのカスタマイズ構成を示す一組のＵＩ要素テンプレートを、アグリゲーションサーバコンピュータから受け取る。これらのテンプレートは、ＵＩ要素が複数の異なる能力レベルの各々と一致するように選択されるように、合計使用統計値を用いて作成される。

合算された統計的データをコンパイルするために、患者の現在の認知能力点数以外の患者に関する個人情報は、クラウドへ移送されない。したがって、合算により、必然的に、ＵＩ要素Ａは認知能力がレベル３未満の人に使用されなかったことや、ＵＩ要素Ｂは認知能力がレベル５未満の人に使用されなかったこと等が発見される。

アグリゲーションサーバコンピュータをプログラムする方法
アグリゲーションサーバコンピュータは、ネットワーク化されたコンピュータ、または、適切なネットワーク接続を通じてポータルコンピュータと通信する、あるいは直接患者機器と通信する、統合されたコンピュータの集まりである。アグリゲーションサーバコンピュータは、少なくとも一つのプロセッサと、アグリゲーションサーバコンピュータにここで説明する機能を実装させるプログラム命令が格納される、関連付けられた非トランジェント(non-transient)メモリとを有する。

例示的なアグリゲーションコンピュータは、ポータルコンピュータは、以下のソフトウェアアーキテクチャを使用する。このソフトウェアアーキテクチャにより、ポータルコンピュータのプロセッサは、ここで説明する機能を実行するようにプログラムされる。もちろん、異なるアーキテクチャを使用してもよい。

データ収集ソフトウェアエージェント
「データ収集」ソフトウェアエージェントは、患者機器内部で常時実行されるように維持される。データ収集ソフトウェアは、メッセージ、画像、動画、アクティビティ等、全てのシステムアナウンスメント、ならびに、タッチ、アプリケーション選択およびスクロール等、全てのユーザ対話を、ローカルバッファにログ付けする。全てのログデータポイントは、タイムスタンプを押されて、それが行われた正確な時刻を反映する。カスタマイズ可能な頻度レートに応じて、新たなログデータポイントが、Ｌｏｇ＿ＡＰＩを用いてポータルにアップロードされる。

Log_API − この方法により、クライアントは、情報ログをサーバに送信することができる。これは、任意の重要な／該当する情報を送信するために使用し得る。
Params：
apikey：/login方法で得られたAPIKEY。
data JSON：以下のフォーマットで一つ以上のオブジェクトを含むアレイ：

[ "メッセージ": "サンプルメッセージ", //送信するメッセージ"イベント時刻 ": 1380566627, //メッセージ作成時刻を表しているＵＮＩＸタイムスタンプ "レベル ": "情報" //ログレベル. 有効なオプションは: 情報, デバグ, 警告およびエラー]

ログの例：

患者機器上で実行されているデータ収集のためのソースコードの例

アグリゲーションサーバコンピュータ７４は、全てのアプリケーションおよびＵＩ要素に亘る合計能力点数を、システム（例えば、認知能力点数、運動能力点数等）によって使用される各々の異なる能力点数について計算するようにプログラムされる。これを行うため、アグリゲーションサーバは、アグリゲーションサービスに参加している各ポータルコンピュータから送信された使用データパケットを受信するようにプログラムされる。ポータルコンピュータの各々は、そのポータルコンピュータと通信している患者機器から受け取ったフィードバックから抽出された情報を含む使用データパケットを周期的に送信するようにプログラムされる。

使用データパケットは一つ以上のレコードからなる。それらレコードの各々は以下の情報を含む：
・ ポータルＩＤ（送信ポータルコンピュータの固有の指示子）
・ 能力点数指示（レコードが認知能力、運動能力または他の何らかの能力の次元を表すかどうか）
・ 患者の現在の能力（データが収集された患者についての能力レベル）
・ ＵＩ要素ＩＤ（このレコードにおいて報告されている特定のユーザインタフェース要素またはアプリケーションについての固有の指示子）
・ 報告期間（ポータルコンピュータがデータを収集した期間）
・ 使用カウント（報告期間の間にＵＩ要素またはアプリケーションが患者によって使用された回数）

データパケットは患者の身元を開示するいかなる情報も含まない点に留意されたい。患者について知られていることは、患者の現在割り当てられている能力レベルだけである。

アグリゲーションサーバコンピュータは、受け取ったデータパケットからデータを抽出し、格納する。データはこのように、各々が複数の異なる患者に供されている可能性のある複数のポータルコンピュータについて蓄積される。したがって、アグリゲーションサーバによって収集されたデータは、患者のある母集団を表しており、異なるＵＩ要素およびアプリケーションの各々を使用する際にその母集団が経験した難易度を示している。合算されたデータから、アグリゲーションサーバは使用統計値を計算し、これらはその後それぞれのポータルコンピュータに送り返される。

使用統計値は、例えば、各ＵＩ要素およびアプリケーションについて、合計の（母集団全体に亘る）点数を含む。例えば、これらの合計点数は、例えば、ＩＤ番号５１２を有するＵＩ要素が、能力レベル３を報告した患者の母集団の９０％により使用されたが、能力レベル２を報告した患者の母集団の２０％にしか使用されなかったこと、を示すかもしれない。このように生成された統計値は、参加しているポータルコンピュータに返送され得、ポータルコンピュータにおいて、ある特定の患者のためのＵＩ構成を設計する際に、ＵＩ要素およびアプリケーションをランク付けして家族または看護スタッフに提示するために使用される。

アグリゲーションサーバコンピュータによって生成された使用統計値は、ＵＩ要素の各々が、さまざまな能力レベルを有し広範であり得る母集団によって、どのように受け取られ、理解されるかを表す。個々の患者は、母集団とは異なる特定の能力レベルを有するかもしれない。例えば、特定の患者は、能力レベル３の母集団と、かなり一貫して略一致するかもしれないが、特定のＵＩ要素またはアプリケーションを使用する際には、特異的に、レベル４の能力を有するかもしれない。ポータルコンピュータは、その患者から収集した使用データを使用し、母集団からの特定のＵＩ要素ランキングを無視して、特定の患者の能力に適合することにより、この事実を考慮し得る。このことは、各患者についてのＵＩ要素ランキングの表をポータルコンピュータのデータストレージシステム５６内に格納することにより達成されてもよい。まず最初に、全てのＵＩ要素ランキングは、合計母集団から受け取った値を割り当てられる。しかし、特定のＵＩ要素ランキングを無視して特定の患者の能力に適合すると、これらの値は、上書きされて、その患者についてタブレットに格納された合計データに取って代わる。このようにして、ポータルコンピュータは、ＵＩ要素およびアプリケーションの各々についてのＵＩ要素ランキングを、それらが以前その患者によって使用されたことがなくても、表示できる。その後、その患者が特定のＵＩ要素に対してどのように反応するかについての経験が得られると、最終的にその患者の固有の特徴を反映するようにテーブルが更新される。

合計母集団データによって生成されたＵＩ要素ランキングはまた、特定の患者の能力レベルを確定する際に、ポータルコンピュータによって使用されてもよい。このことは、時間の経過とともに（合計ランキング点数に基づいて）次第に上昇する難易度でＵＩ要素およびアプリケーションを患者機器に対してシステム的にプッシュし、どのＵＩ要素またはアプリケーションを患者が十分に利用できないのかが確定（患者機器から提供されたフィードバックに基づいて）されるまでこれを行うことによりなされる。そうして、患者の能力レベルは、患者が一貫して行うことができた最大能力レベルに等しいと確定されてもよい。ここでの目的は、患者に試練を与えることではなく、それよりも、選択したＵＩ要素およびアプリケーションを患者が快適に使用できるベースラインを確定することである。

ＵＩ要素のキット
ポータルコンピュータ５５のデータストレージシステム５６に格納されたＵＩ要素のキット６２は、重複し且つ幾分冗長な機能を提供する。例えば、患者によってなされる最もシンプルなジェスチャ命令は、「画面上のどこでもいいからタッチする」ことであり得る。同じことをするためのより高度なものは、ボタンが実行する機能のラベルが付いた１つのボタンを押すことであり得る。さらに高度なものとして、タブ状の選択肢群を有するメニューバーであって、下位レベルは無いようなメニューバー（要するにラベルが付いたボタンの列）が挙げられる。さらに高度なものとしては、１階層下のサブメニュー選択肢を提供するメニュー、と言った具合である。

このＵＩ要素のキットから選択して、図３６ａおよび図３６ｂは、どのようにポータルを用いて患者機器上におけるユーザ経験をカスタマイズし得るかを示す。既に説明したように、図３６ａおよび図３６ｂは、異なるレベルの能力について設定された例示的な写真閲覧アプリケーションを表す。

このユーザインタフェースカスタマイズ機能を実施するために、各アプリケーション（この場合写真閲覧アプリケーション）は、全ての設定可能なユーザインタフェース要素の状態を格納する、患者機器のローカルメモリにおいて定義されたデータ構造を含む。これらの要素の例を図３６ａおよび図３６ｂに示し、「前の写真」、「次の写真」、「戻る」、「スライドショー状態」、「ヘッダバー日付―時刻プレゼンテーションサイズ」、「リマインダ」等を含む。これらは、設定し得るユーザインタフェース要素のいくつかの例にすぎないことが理解される。

これらのユーザインタフェース設定変数の状態は、ポータルを介したアプリケーションとの対話により変更される。ポータルを使用して、これらの変数の状態が変更されてもよく、変更された場合に、それらは、アプリケーションが患者機器上での実行時にどのように動作するかに影響を及ぼす。

ユーザインタフェース状態変数を保存することに加えて、各アプリケーションに関連付けられたデータ構造はまた、リアルタイムで捕捉されたデータを格納し、患者機器を作動させて特定のユーザインタフェース機能が患者によって使用されたときの各インスタンスを記録する。図３５ａおよび図３５ｂに示したある実施形態において、カウンタは、インクリメントされて、データ構造の使用履歴部分に格納される。日付およびタイムスタンプ情報も、データ構造に格納されてもよく、厳密にいつユーザインタフェース機能が患者に使用されたかを記録する。図示した実施形態において、インクリメントされた数は、予め定義された（カスタマイズ可能な）期間内に特定の機能がアクセスされた回数を表す。図示の通り、３０日の期間が選択されている。例えば、「２３１．３０」は、「前の写真」ボタンが過去３０日の間に２３１回を作動されたことを示す。使用履歴において捕捉されたデータは、フィードバック情報としてポータルに送信され、また、合計統計値を収集するクラウドサーバにも送信される（後でより詳細に説明する）。使用履歴情報を収集することにより、ポータルが、家族または介護者に対して、各アプリケーションのどの機能を患者が使用することができるかを表示することができる。図３６ｂに示すように、１度も使用されていない機能をオフに切り換え得る。

上記実施形態の説明は、図示および説明を目的として提供されたものである。網羅的であることや、開示内容を限定することを意図したものではない。特定の実施形態の個々の要素または特徴は、概して、その特定の実施形態に限定されないが、適用可能であれば、交換可能であり、且つ、具体的に図示または説明されなくても選択された実施形態において使用され得る。同様のことを、さまざまな方法で改変してもよい。そのような改変は開示内容からの逸脱とは見なされず、また、そのような修正の全てが本開示の範囲内に含まれるものとする。

付録
例示的なコンピュータプログラムコードがポータルコンピュータ上で実行され、ポータルコンピュータデータベースから設定を取り出し、それら設定を患者機器に送信して、患者機器のディスプレイを設定する。

Claims (21)

1. 認知能力または運動能力が低下した人を援助するための、コンピュータで実装されたシステムであって、
   ディスプレイと、前記ディスプレイに接続されたプロセッサと、通信ポートとを有する患者機器と、
   前記通信ポートを介して前記患者機器と通信するポータルコンピュータとを備えたシステムであって、
   前記ポータルコンピュータは、プロセッサと付随するメモリとを有し、前記付随するメモリは、能力点数を各ユーザインタフェース要素に関連付ける予め規定されたデータ構造に応じた、複数のユーザインタフェース要素を格納し、
   前記ポータルコンピュータは、前記複数のユーザインタフェース要素を、前記ポータルコンピュータのユーザに対して、前記能力点数に基づいた提示配置で提示するようにプログラムされており、
   前記ポータルコンピュータは、第１のユーザが、前記配置で提示されたユーザインタフェース要素から少なくとも１つのインタフェース要素を選択し、その後、前記選択したユーザインタフェース要素を前記患者機器に対してプッシュできるように、プログラムされている、コンピュータで実装されたシステム。
2. 前記患者機器の前記プロセッサは、前記患者機器に対してプッシュされた前記選択されたユーザインタフェース要素の前記患者による使用に関して、フィードバックデータを前記ポータルコンピュータに提供するようにプログラムされている、請求項１に記載のコンピュータで実装されたシステム。
3. 前記ポータルコンピュータはさらに、異なる能力レベルへのユーザインタフェース適合性に関する統計値をコンパイルするアグリゲータコンピュータに対して、フィードバックデータを報告するようにプログラムされている、請求項１に記載のコンピュータで実装されたシステム。
4. 前記ポータルコンピュータは、ユーザインタフェース要素に関連付けられた前記能力点数を、複数の患者から収集し合算されたユーザインタフェース使用データに基づいて更新するようにプログラムされている、請求項１に記載のコンピュータで実装されたシステム。
5. 前記ポータルコンピュータは、複数のアプリケーションを、前記ポータルコンピュータの第１のユーザに対して提示するようにプログラムされており、
   前記ポータルコンピュータは、前記第１のユーザが少なくとも１つのアプリケーションを選択し、その後、前記アプリケーションが前記患者機器の前記プロセッサによって実行されるべく、前記アプリケーションを設定して前記患者機器に対してプッシュできるように、プログラムされている、
   請求項１に記載のコンピュータで実装されたシステム。
6. 前記ポータルコンピュータは、複数のアプリケーションを、前記ポータルコンピュータの第１のユーザに対して、前記能力点数に基づいた提示配置で提示するようにプログラムされており、
   前記ポータルコンピュータは、前記第１のユーザが、前記配置で提示されたアプリケーションから少なくとも１つのアプリケーションを選択し、その後、前記アプリケーションが前記患者機器の前記プロセッサによって実行されるべく、前記アプリケーションを前記患者機器に対してプッシュできるように、プログラムされている、
   請求項１に記載のコンピュータで実装されたシステム。
7. 前記ポータルコンピュータと通信し、且つ、前記能力点数を前記ポータルコンピュータに提供するようにプログラムされているアグリゲータコンピュータをさらに含む、請求項１に記載のコンピュータで実装されたシステム。
8. 前記ポータルコンピュータと通信し、且つ、前記ポータルコンピュータから使用データを受け取り、前記使用データに基づいて能力点数を計算し、前記計算された能力点数を前記ポータルコンピュータに提供するようにプログラムされているアグリゲータコンピュータをさらに含む、請求項１に記載のコンピュータで実装されたシステム。
9. 前記ポータルコンピュータは、前記患者機器上で実行できるように適応されたアプリケーションプログラムを格納し、
   前記ポータルコンピュータは、前記格納されたアプリケーションの中から選択されたものを、前記患者機器に対してプッシュするようにプログラムされている、
   請求項１に記載のコンピュータで実装されたシステム。
10. 前記ポータルコンピュータは、能力点数を、前記格納されたアプリケーションプログラムの各々に関連付ける、請求項９に記載のコンピュータで実装されたシステム。
11. 前記ポータルコンピュータは、能力点数を前記格納されたアプリケーションプログラムの各々に関連付け、それらアプリケーションを、前記ポータルコンピュータの前記ユーザに対して、前記能力点数に基づいた提示配置で提示する、請求項９に記載のコンピュータで実装されたシステム。
12. 前記能力点数は認知能力点数である、請求項１に記載のコンピュータで実装されたシステム。
13. 前記能力点数は運動能力点数である、請求項１に記載のコンピュータで実装されたシステム。
14. 前記ポータルコンピュータは、前記患者機器に対してプッシュするユーザインタフェース要素を自動的に提案し、前記提案の作成に際しては前記患者の能力に関する知識および前記能力点数を用いる、請求項１に記載のコンピュータで実装されたシステム。
15. 前記ポータルコンピュータは、自動的にユーザインタフェース要素を選択して前記患者機器に対してプッシュし、前記選択に際しては前記患者の能力に関する知識および前記能力点数を用いる、請求項１に記載のコンピュータで実装されたシステム。
16. 前記ポータルコンピュータは、前記患者機器の前記通信ポートを介して通信して、前記患者機器を遠隔操作する、請求項１に記載のコンピュータで実装されたシステム。
17. 前記ポータルコンピュータは、カレンダー、メッセージ、画像閲覧、動画閲覧、音楽、天気、音声チャット、音声動画チャットからなる群より選択された、前記患者機器上で実行できるように適応されたアプリケーションプログラムを格納する、請求項１に記載のコンピュータで実装されたシステム。
18. 認知能力または運動能力が低下した人を援助するための、コンピュータで実装されたシステムであって、
    ディスプレイと、前記ディスプレイに接続されたプロセッサと、通信ポートとを有する患者機器と、
    前記通信ポートを介して前記患者機器と通信するポータルコンピュータとを備えたシステムであって、
    前記コンピュータは、プロセッサと、複数の異なるユーザインタフェース要素に関する情報を格納する付随するメモリとを有し、
    前記ポータルコンピュータは、前記複数の異なるユーザインタフェース要素の部分集合を特定する情報を前記患者機器を特定する情報に関連付けて格納するためのデータ構造を、前記付随するメモリ内に規定しており、
    前記ポータルコンピュータは、前記ポータルコンピュータのユーザが、前記ポータルコンピュータのユーザが前記患者機器の前記ユーザに適していると判断した、前記複数の異なるユーザインタフェース要素から選択された部分集合を特定する情報を前記データ構造に埋め込むことができるように、プログラムされており、
    前記ポータルコンピュータは、前記情報が埋め込まれたデータ構造に基づいて前記通信ポートを介して通信し、前記患者機器に、前記ユーザインタフェース要素の部分集合を用いて、前記患者機器の前記ディスプレイを設定させる、コンピュータで実装されたシステム。
19. 前記情報が埋め込まれたデータ構造に基づく情報は、前記患者機器に対してプッシュされる、請求項１８に記載のコンピュータで実装されたシステム。
20. 前記情報が埋め込まれたデータ構造に基づく情報は、前記患者機器によって、前記ポータルコンピュータからプルされる、請求項１８に記載のコンピュータで実装されたシステム。
21. 前記患者機器は、前記通信ポートを介して前記ポータルコンピュータと周期的に通信するアップデータ機能を実行して、前記情報が埋め込まれたデータ構造内の情報が、前記患者機器の前記ディスプレイの設定に用いている情報と異なるか否かを判定する、請求項１８に記載のコンピュータで実装されたシステム。

Images