(57)【要約】  本発明は、リモートケアサービスを実施するシステムと方法に関する。まず、過去のフィードバックを活用してプロバイダとレシピエントのプロフィールを最適化することでサービスのプロバイダがサービスのレシピエントにマッチングされる。次に、最も効果的にケアをレシピエントに配達するために、プロバイダのスケジュールが最適化される。このシステムはプロバイダトレシピエントのアポイントメントとの間の効率的なルート設定を提供するように構成されている。ケアの配達により、システムは、サービスの全てのタスクが完了したことの確認を収集することもできる。プロバイダとレシピエントはそれぞれシステムに遭遇したことのフィードバックを提供することもできる。プロバイダはアポイントメントに関するメッセージをレシピエントの知人と家族に直接送ることができる。
2018518783.tif 000002
【特許請求の範囲】
【請求項１】
リモートサービスマネージメントを監視するためのコンピュータに実装されるサービスマネージメントシステムであって、該サービスマネージメントシステムは、
複数のプロバイダの中から１人のプロバイダをサービスのレシピエントにマッチングさせるように構成されているマッチング最適化装置であって、該マッチングはプロバイダとレシピエントのフィードバックされたスコアとプロフィールに基づいてマッチングを最適化することを含んでいる、マッチング最適化装置と、
レシピエントのニーズをプロバイダの予約状況と照合することでサービスの予定を決めるように構成されているスケジュール設定装置と、
レシピエントの位置へプロバイダをルート設定するように構成されているルート設定装置と、
サービスの配達を確認するように構成されている確認装置と、
を含んでいる、サービスマネージメントシステム。
【請求項２】
サービスは、食事の世話、付添い、身なりの世話および個人的補助のうちの少なくとも１種のタスクを含んでいる、請求項１記載のサービスマネージメントシステム。
【請求項３】
サービスの配達の確認はプロバイダからタスク完了のフィードバックを受け取ることを含んでいる、請求項２記載のサービスマネージメントシステム。
【請求項４】
プロバイダとレシピエントの前記マッチングは、前記プロフィールを、高いフィードバック評価に対応してプロフィールにおけるトレンドを特定することにより発生する理想的なプロフィールに照合させる、請求項１記載のサービスマネージメントシステム。
【請求項５】
レシピエントからプロバイダに関するフィードバックを収集するように構成されているフィードバックモジュールをさらに含んでいる、請求項１記載のサービスマネージメントシステム。
【請求項６】
前記フィードバックモジュールは、プロバイダからレシピエントに関するフィードバックを収集するようにさらに構成されている請求項５記載のサービスマネージメントシステム。
【請求項７】
前記フィードバックは秘密裏に収集される、請求項６記載のサービスマネージメントシステム。
【請求項８】
プロバイダからのメッセージを受け取り、当該メッセージをレシピエントの家族や知人に提供するように構成されているメッセージ装置をさらに含んでいる、請求項１記載のサービスマネージメントシステム。
【請求項９】
前記メッセージ装置はプロバイダから記録を受け取るようにさらに構成されている、請求項８記載のサービスマネージメントシステム。
【請求項１０】
前記メッセージ装置は前記レシピエントにサービスを提供する他のプロバイダに前記記録を提供するようにさらに構成されている、請求項９記載のサービスマネージメントシステム。
【請求項１１】
リモートサービスマネージメントを監視するためのコンピュータに実装される方法であって、
複数のプロバイダの中から１人のプロバイダをサービスのレシピエントにマッチングさせるステップであって、該マッチングステップはプロバイダとレシピエントのフィードバックされたスコアとプロフィールに基づいてコンピュータ上でマッチングを最適化することを含んでいる、マッチングステップと、
レシピエントのニーズをプロバイダの予約状況と照合することでサービスの予定を決めるステップと、
レシピエントの位置へプロバイダをルート設定するステップと、
サービスの配達を確認するステップと、
を含んでいる方法。
【請求項１２】
サービスは、食事の世話、付添い、身なりの世話および個人的補助のうちの少なくとも１種のタスクを含んでいる、請求項１１記載の方法。
【請求項１３】
サービスの配達の前記確認ステップはプロバイダからタスク完了のフィードバックを受け取ることを含んでいる、請求項１２記載の方法。
【請求項１４】
プロバイダのレシピエントへの前記マッチングステップは、前記プロフィールを、高いフィードバック評価に対応してプロフィールにおけるトレンドを特定することにより発生する理想的なプロフィールに照合させる、請求項１１記載の方法。
【請求項１５】
レシピエントから前記プロバイダに関するフィードバックを収集するステップをさらに含んでいる、請求項１１記載の方法。
【請求項１６】
前記フィードバックモジュールは、プロバイダからレシピエントに関するフィードバックを収集するステップをさらに含んでいる、請求項１５記載の方法。
【請求項１７】
前記フィードバックは秘密裏に収集される、請求項１６記載の方法。
【請求項１８】
プロバイダからのメッセージを受け取り、当該メッセージをレシピエントの家族や知人に提供するステップをさらに含んでいる、請求項１１記載の方法。
【請求項１９】
プロバイダから記録を受け取るステップをさらに含んでいる、請求項１１記載の方法。
【請求項２０】
レシピエントにサービスを提供する他のプロバイダに前記記録を提供するステップをさらに含んでいる、請求項１９記載の方法。
【請求項２１】
レシピエントにサービスプロバイダをマッチングさせるコンピュータに実装されるシステムであって、
第１の複数のプロバイダから収集される過去のプロバイダのプロフィール情報、複数のレシピエントから収集される過去のレシピエントのプロフィール情報、および配達されたサービスの質に関する前記第１の複数のプロバイダからと前記複数のレシピエントからの過去のフィードバックの過去のデータソースと、
該過去のプロバイダのプロフィール情報と前記過去のレシピエントのプロフィール情報を収集された前記フィードバックに照合させることで最適なプロフィールマッチングを発生させるように構成されているマッチング最適化装置と、
第２の複数のプロバイダからプロバイダのプロフィール情報を収集し、１人のレシピエントからレシピエントのプロフィール情報を収集するように構成されている搭載装置と、
前記最適なプロフィールマッチングへの前記プロバイダのプロフィール情報およびレシピエントのプロフィール情報の類似性に基づいて、前記第２の複数のプロバイダの中のプロバイダの少なくとも１人に前記レシピエントをマッチングさせるように構成されているマッチング装置と、
を含んでいるシステム。
【請求項２２】
サービスは、食事の世話、付添い、身なりの世話および個人的補助のうちの少なくとも１種を含んでいる、請求項２１記載のシステム。
【請求項２３】
前記過去のプロバイダのプロフィール情報は、プロバイダの氏名、画像、性別、誕生日、位置、資格証明書、経験、および個人的好き嫌いのうちの少なくとも１種を含んでいる、請求項２１記載のシステム。
【請求項２４】
前記過去のレシピエントのプロフィール情報およびレシピエントのプロフィールは、レシピエントの氏名、画像、性別、位置、体重、誕生日、ケアニーズ、身体的限界、精神的限界、ペット情報のうちの少なくとも１種、及び、好きな食べ物、好きな休日、最も大切な記憶、好きな人物のうちの少なくとも１種を含んでいる、請求項２１記載のシステム。
【請求項２５】
前記の少なくとも１人のプロバイダに対してマッチングを表示し、
該少なくとも１人のプロバイダのうちの少なくとも１人のプロバイダから申請情報を収集し、
レシピエントおよびレシピエントの家族や知人のうちの少なくとも１人に対して申請した該少なくとも１人のプロバイダのうちの少なくとも１人のプロバイダを提示し、
どのプロバイダが選択されたかの情報を受け取る、
ように構成されている取引経路をさらに含んでいる、請求項２１記載のシステム。
【請求項２６】
申請した前記少なくとも１人のプロバイダのうちの前記少なくとも１人のプロバイダの提示は、それぞれのプロバイダのプロフィールと費用の表示を含んでいる、請求項２５記載のシステム。
【請求項２７】
前記マッチングされたレシピエントと少なくとも１人のプロバイダに関するフィードバックを収集するように構成されているフィードバックモジュールをさらに含んでいる、請求項２１記載のシステム。
【請求項２８】
前記のマッチングを実行する装置は、収集されたフィードバックに対応してマッチングをアップデートする、請求項２７記載のシステム。
【請求項２９】
前記のマッチングを実行する装置は、レシピエントおよびそれぞれのプロバイダの適合性スコアを生成するように構成されている、請求項２１記載のシステム。
【請求項３０】
前記マッチングに先行して位置と資格によって前記第２の複数のプロバイダを分別するためのフィルタリング装置をさらに含んでいる、請求項２１記載のシステム。
【請求項３１】
サービスプロバイダをレシピエントにマッチングさせるコンピュータに実行させる方法であって、
第１の複数のプロバイダから過去のプロバイダのプロフィール情報を収集するステップと、
複数のレシピエントから過去のレシピエントのプロフィール情報を収集するステップと、
前記第１の複数のプロバイダと複数のレシピエントから配達されたサービスの質に関する過去のフィードバックを収集するステップと、
コンピュータで、前記過去のプロバイダのプロフィール情報と前記過去のレシピエントのプロフィール情報とを収集された前記フィードバックと照合することで最適なプロフィールマッチングを発生させるステップと、
第２の複数のプロバイダからプロバイダのプロフィール情報を収集するステップと、
１人のレシピエントからレシピエントのプロフィール情報を収集するステップと、
前記最適なプロフィールマッチングへの前記プロバイダのプロフィール情報および前記レシピエントのプロフィール情報の類似性に基づいて前記第２の複数のプロバイダの中のプロバイダの少なくとも１人に、前記レシピエントをマッチングさせるステップと、
を含んでいる方法。
【請求項３２】
サービスは、食事の世話、付添い、身なりの世話および個人的補助のうちの少なくとも１種を含んでいる、請求項３１記載の方法。
【請求項３３】
前記過去のプロバイダのプロフィール情報およびプロバイダのプロフィールは、プロバイダの氏名、画像、性別、誕生日、位置、資格証明書、経験、および個人的好き嫌いのうちの少なくとも１種を含んでいる、請求項３１記載の方法。
【請求項３４】
前記過去のレシピエントのプロフィール情報およびレシピエントのプロフィールは、レシピエントの氏名、画像、性別、位置、体重、誕生日、ケアニーズ、身体的限界、精神的限界、ペット情報のうちの少なくとも１種、及び、好きな食べ物、好きな休日、最も大切な記憶、好きな人物のうちの少なくとも１種を含んでいる、請求項３１記載の方法。
【請求項３５】
前記の少なくとも１人のプロバイダに対してマッチングを表示し、
該少なくとも１人のプロバイダのうちの少なくとも１人のプロバイダから申請情報を収集するステップと、
レシピエントおよびレシピエントの家族や知人のうちの少なくとも１人に対して申請した該少なくとも１人のプロバイダのうちの該少なくとも１人のプロバイダを提示するステップと、
どのプロバイダが選択されたかの情報を受け取るステップと、
をさらに含んでいる、請求項３１記載の方法。
【請求項３６】
申請した前記少なくとも１人のプロバイダのうちの前記少なくとも１人のプロバイダを提示するステップは、それぞれのプロバイダのプロフィールと費用を表示することを含んでいる、請求項３５記載の方法。
【請求項３７】
前記マッチングされたレシピエントと少なくとも１人のプロバイダに関するフィードバックを収集するステップをさらに含んでいる、請求項３１記載の方法。
【請求項３８】
収集されたフィードバックに対応してマッチングをアップデートするステップをさらに含んでいる、請求項３７記載の方法。
【請求項３９】
レシピエントおよびそれぞれのプロバイダの適合性スコアの発生させるステップをさらに含んでいる、請求項３１記載の方法。
【請求項４０】
前記のマッチングに先行して位置と資格によって前記第２の複数のプロバイダを分別するステップをさらに含んでいる、請求項３１記載の方法。
【請求項４１】
ケアレシピエントに付加価値サービスを提供するコンピュータを活用するシステムであって、
レシピエントのためのサービスのリクエストを受け取るように構成されているリクエストモジュールと、
精査された付加価値サービスのデータベースからの付加価値サービスをマッチングさせるように構成されているマッチング装置と、を含んでおり、
このマッチングはレシピエントの限界と位置および付加価値サービスの評価を考慮に入れたものであり、さらに、
その付加価値サービスの承認を、レシピエントおよびレシピエントの知人や家族のうちの少なくとも１人から受け取るように構成されている確認モジュールを含んでいるシステム。
【請求項４２】
付加価値サービスは、イベント、プロのサービス、個人サービスおよびアクティビティのうちの少なくとも１種を含んでいる、請求項４１記載のシステム。
【請求項４３】
前記アクティビティは、社会活動、散歩、スポーツ活動、芸術クラス、ゲーム、およびアトラクション参加のうちの少なくとも１種を含んでいる、請求項４２記載のシステム。
【請求項４４】
前記イベントは、演劇、映画、スポーツイベント、パレード、コメディショー、およびバラエティショーのうちの少なくとも１種を含んでいる、請求項４２記載のシステム。
【請求項４５】
前記個人サービスは、食事の世話、付添い、身だしなみの世話、および個人補助のうちの少なくとも１種を含んでいる、請求項４２記載のシステム。
【請求項４６】
前記プロのサービスは、住居の修繕サービス、配管サービス、法律サービス、塗装サービス、清掃サービス、および金融サービスのうちの少なくとも１種を含んでいる、請求項４２記載のシステム。
【請求項４７】
前記レシピエントの限界は肉体的および精神的限界を含んでいる、請求項４１記載のシステム。
【請求項４８】
前記マッチング装置は、レシピエントのプロフィールに対して付加価値サービスを最適化するように構成されており、該プロフィールには好き嫌いの項目が含まれている、請求項４１記載のシステム。
【請求項４９】
前記リクエストは、レシピエント、レシピエントの家族や知人、およびレシピエントケアのプロバイダのうちの少なくとも１人によって提出され、あるいは導入されている、請求項４１記載のシステム。
【請求項５０】
前記リクエストは、以前の付加価値サービスの提供時間から、レシピエントに関するプロバイダの記録の自然言語処理を介して導入される、請求項４９記載のシステム。
【請求項５１】
ケアレシピエントに付加価値サービスを提供するコンピュータを活用した方法であって、
レシピエントのためのサービスのリクエストを受け取るステップと、
精査された付加価値サービスのデータベースからの付加価値サービスをコンピュータによってマッチングさせるステップと、
を含んでおり、このマッチングはレシピエントの限界と位置および付加価値サービスの評価を考慮に入れたものであり、
その付加価値サービスの承認を、レシピエントおよびレシピエントの知人や家族のうちの少なくとも１人から受け取るステップをさらに含んでいる方法。
【請求項５２】
付加価値サービスは、イベント、プロのサービス、個人サービスおよびアクティビティのうちの少なくとも１種を含んでいる、請求項５１記載の方法。
【請求項５３】
前記アクティビティは、社会活動、散歩、スポーツ活動、芸術クラス、ゲーム、およびアトラクション参加のうちの少なくとも１種を含んでいる、請求項５２記載の方法。
【請求項５４】
前記イベントは、演劇、映画、スポーツイベント、パレード、コメディショー、およびバラエティショーのうちの少なくとも１種を含んでいる、請求項５２記載の方法。
【請求項５５】
前記個人サービスは、食事の世話、付添い、身だしなみの世話、および個人補助のうちの少なくとも１種を含んでいる、請求項５２記載の方法。
【請求項５６】
前記プロのサービスは、住居の修繕サービス、配管サービス、法律サービス、塗装サービス、清掃サービス、および金融サービスのうちの少なくとも１種を含んでいる、請求項５２記載の方法。
【請求項５７】
前記レシピエントの限界は肉体的および精神的限界を含んでいる、請求項５１記載の方法。
【請求項５８】
前記マッチングさせるステップは、レシピエントのプロフィールに対して付加価値サービスを最適化し、該プロフィールには好き嫌いの項目が含まれている、請求項５１記載の方法。
【請求項５９】
前記リクエストは、レシピエント、レシピエントの家族や知人、およびレシピエントケアのプロバイダのうちの少なくとも１人によって提出され、あるいは導入される、請求項５１記載の方法。
【請求項６０】
前記リクエストは、以前の付加価値サービスの提供時間から、レシピエントに関するプロバイダの記録の自然言語処理を介して導入される、請求項５９記載の方法。
【請求項６１】
ケアのレシピエントの監視のためのコンピュータを活用したシステムであって、
ケアのプロバイダがレシピエントのケアを完了したことの確認を受け取るように構成されている確認装置と、
プロバイダからケアの配達に関するメッセージを受け取るように構成されているメッセージシステムと、
前記確認とメッセージをレシピエントの知人や家族に伝達するように構成されているアプリケーションインターフェースと、
ケアの中断および緊急事態を特定するためにプロバイダから位置データを収集し、レシピエントの位置からフィードを収集するように構成されている安全モジュールと、
を含んでいるシステム。
【請求項６２】
前記安全モジュールは、不一致が存在するか否かを決定するために、プロバイダがレシピエントの位置で過ごした時間の長さを、その位置で実施されるべきタスクと照合する、請求項６１記載のシステム。
【請求項６３】
前記安全モジュールは、不一致が存在するか否かを決定するために、プロバイダの時間と位置を前記の確認と照合する、請求項６１記載のシステム。
【請求項６４】
収集された前記フィードは、ビデオフィード、オーディオフィード、緊急信号、およびプロバイダからのメッセージのうちの少なくとも１種を含んでいる、請求項６１記載のシステム。
【請求項６５】
前記フィードは、プロバイダがレシピエントの位置に存在するときに収集される、請求項６４記載のシステム。
【請求項６６】
前記安全モジュールは、誘因となる事象のために前記フィードを分析するようにさらに構成されており、この誘因となる事象には、助けを求める可聴呼び出し、予期せぬ動作、および設定時間の無動作のうちの少なくとも１つが含まれる、請求項６４記載のシステム。
【請求項６７】
前記安全モジュールは、誘因となる事象が検出されたら、前記フィードを人間のオペレータに伝達するようにさらに構成されている、請求項６６記載のシステム。
【請求項６８】
前記人間のオペレータによって指示されたとき、プロバイダまたは緊急応答者を派遣するための派遣モジュールをさらに含んでいる、請求項６７記載のシステム。
【請求項６９】
前記派遣の結果を報告するように構成されている報告モジュールをさらに含んでいる、請求項６８記載のシステム。
【請求項７０】
前記メッセージシステムはプロバイダとレシピエントの知人や家族との間で双方向コミュニケーションを提供するように構成されている、請求項６１記載のシステム。
【請求項７１】
ケアレシピエントを監視するためのコンピュータを活用した方法であって、
ケアのプロバイダがレシピエントのケアを完了したことの確認を受け取るステップと、
プロバイダからケアの配達に関するメッセージを受け取るステップと、
前記確認とメッセージをレシピエントの知人や家族に伝達するステップと、
プロバイダから位置データを収集し、レシピエントの位置からフィードを収集するステップと、
前記位置データと前記フィードに基づいてケアの中断と緊急性を特定するステップと、
を含んでいる方法。
【請求項７２】
ケアの中断と緊急性の前記特定ステップは、不一致が存在するか否かを決定するために、プロバイダがレシピエントの位置で過ごした時間の長さを、その位置で実施されるべきタスクと照合することを含んでいる、請求項７１記載の方法。
【請求項７３】
ケアの中断と緊急性の前記特定ステップは、不一致が存在するか否かを決定するために、プロバイダの時間と位置を前記確認と照合することを含んでいる、請求項７１記載の方法。
【請求項７４】
収集された前記フィードは、ビデオフィード、オーディオフィード、緊急信号、およびプロバイダからのメッセージのうちの少なくとも１種を含んでいる、請求項７１記載の方法。
【請求項７５】
前記フィードは、プロバイダがレシピエントの位置に存在するときに収集される、請求項７４記載の方法。
【請求項７６】
誘因となる事象のために前記フィードを分析するステップをさらに含んでおり、この誘因となる事象には、助けを求める可聴呼び出し、予期せぬ動作、および設定時間の無動作のうちの少なくとも１つが含まれる、請求項７４記載の方法。
【請求項７７】
誘因となる事象が検出されたら、前記フィードを人間のオペレータに伝達するステップをさらに含んでいる、請求項７６記載の方法。
【請求項７８】
前記人間のオペレータによって指示されたとき、プロバイダまたは緊急応答者を派遣するステップをさらに含んでいる、請求項７７記載の方法。
【請求項７９】
前記派遣の結果を報告するステップをさらに含んでいる、請求項７８記載の方法。
【請求項８０】
プロバイダとレシピエントの知人や家族との間で双方向コミュニケーションを提供するステップをさらに含んでいる、請求項７１記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は個人のリモートケア（遠隔世話）を実施させるシステムと方法に関する。
【背景技術】
【０００２】
そのようなシステムおよび方法はケアレシピエント（ケア受領者）のためのリモートケアの効果および独立感覚および安全感覚を増し、ケアレシピエントの家族や友人（知人）のために関係維持感覚および充足感を増すであろう。加えて、そのようなシステムおよび方法はケアプロバイダ（ケア提供者）に効率的なスケジュール設定やルート設定を提供し、さらに効率よくサービスを配達（デリバリ、提供）させるであろう。
【０００３】
ホームケアは典型的には２つのサブセットに分割される。すなわち、ホーム（自宅）での医療ケアと非医療ケアである。非医療ケアには典型的には、例えば、食事ケア、身だしなみケア、洗い物ケア、入浴習慣の補助ケア、並びに多くの家事ケア（掃除、洗濯、郵便物の受け取り、等々）などのアクティビティ（動的ケア）が含まれる。この補助は多くの個人にとって非常に必須である。これらホームケアサービスなしにはレシピエントはしばしば独立した生活が送れず、強制的に家族のもとに引っ越し、あるいは適当なケア施設に入所しなければならないであろう。
【０００４】
ホームケアサービスは、ほとんどの場合に老人によって利用される。しかし、ホームケアのレシピエントは幅広い年齢層であり得、精神的または肉体的に不自由であったり、外傷性障害あるいは手術後の回復時であったり、中毒からの回復患者であったり、増大されたケアニーズ（項目）を必要とする個人であったりする。しかしながら、多くの先進国の老齢化動向によれば、特に老人のためのホームケアの必要性は大きく増加することが予測されている。
【０００５】
現在、ホームケアはしばしばレシピエント（またはレシピエントの友人（以下知人と称す）および家族）とケア提供者との間の直接的な個別契約を介して、あるいは代理業者との間の個別契約を通じて提供されている。知人や家族はレシピエントの近所に住んでいないことがあり、適したケアを確保するには困難が存在し、さらには、思い遣りを伴って適切にケアを提供することのストレスや不安が存在する。ケアレシピエントから離れて住んでいる家族にとっては適したケアプロバイダを見つけることさえ非常に困難であり得、ましてやレシピエントのケアニーズを適切にマネージメント（管理）することは困難である。代理業者を活用することでケア提供者を見つける困難は軽減するが、代理業者は（代理業者を介在しない直接的な関係を通じて）ビジネスチャンスを失う懸念からケアプロバイダとレシピエントの家族との間の直接触の提供に気が進まない。
【０００６】
さらに、大多数のケア代理業者は、ケアプロバイダの配分、スケジュール設定、レシピエントへのプロバイダのマッチング（調和斡旋）、等々において低レベルであるとの悪評がある。しばしばプロバイダのスケジュール設定は机上の手作業で行われる。さらに高度な代理業者は初歩のスケジュール設定ソフトウェアを有していることもあろうが、現状はこれが代理業者の高度化の限度である。
【０００７】
従って現在、代理業者または個人のアレンジ（調節）を困らせている多数の弱点に対処することができるレシピエントのリモートケアを実施するシステムおよび方法を緊急に必要としていることは明白である。そのようなシステムおよび方法は、レシピエント記録へのさらに効率的なプロバイダルート設定、ケアプロバイダとレシピエントとの改善されたマッチング、ケアの質向上、並びに、ケアレシピエントの家族と知人の心の平安をもたらす。加えて、そのようなシステムおよび方法は、レシピエントの人生の質と安全を改善する高度化された付加価値サービスを可能にするであろう。                                                            
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記を達成するため、および本発明に従って、リモートサービスを実行可能にするためのシステムおよび方法が提供される。特に、このリモートサービスマネージメント（遠隔サービス管理）のためのシステムと方法は、透明性のあるマッチングと、スケジュール設定と、ルート設定と、サービス配達並びにサービス品質の確認に向けられている。これは、特に老人または何らかの機能において肉体的あるいは精神的に限界（制限、制約）があるその他の人々のケアにおいて、また子守り、ペットケア、付添いサービス、等々のケアにおいて有用性が高い。
【課題を解決するための手段】
【０００９】
本発明のシステムと方法は、まずサービスプロバイダをサービスレシピエントにマッチングさせることでサービスマネージメント（サービス管理）を実行する。このマッチングはいくつかの方法で実行でき、レシピエントとプロバイダのマッチングの決定を助けるように市場原理（取引環境、取引経路）形態のプラットフォームを利用することさえ可能である。実施形態によっては、レシピエントとプロバイダの交流に関する履歴フィードバックが保存でき、レシピエントとプロバイダのプロフィール（人物像）内のどの特性が効果的なマッチングをさせるか特定するために利用できる。個人の最適なマッチングを決定するため、進行中のマッチングにおいてこれらの特性が分析できる。
【００１０】
続いて、プロバイダのためのスケジュールが、プロバイダに最も効果的にケアをレシピエントに配達（デリバリ）させるために最適化される。このスケジュール設定はレシピエントのケアニーズ、プロバイダの予約状況、およびプロバイダの現在位置、並びに他のアポイントメント（予約設定）の提供位置を考慮に入れることができる。このシステムは、レシピエントのアポイントメントに関してプロバイダに効率的なルート設定を提供するように構成することもできる。
【００１１】
ケアの配達で、このシステムはサービスの全てのタスク（サービス提供）が完了したことの確認の収集もする。しばしばこれらサービスには、食事の世話、付添い、身だしなみケアおよび個人的な補助のごときアクティビティ（活動）が含まれる。プロバイダとレシピエントはそれぞれ秘密形態でこのシステムに出会い（遭遇）フィードバックを提供することもできる。このフィードバックはさらなるケアニーズをガイド（案内）するのに活用でき、将来のレシピエントとプロバイダのマッチングの好適化を助ける。
【００１２】
プロバイダは、アポイントメント、スケジュール設定および関心事に関するメッセージを直接的にレシピエントの知人または家族に送ることができる。この連絡は双方向であってもよい。このように、これらメッセージのアップデートを通じてレシピエントの知人や家族には心の平安が提供され、ほぼリアルタイムでケア配達の状況をチェックすることができる。
【００１３】
レシピエントの知人や家族にメッセージを送ることができるのに加えて、プロバイダはケアに関する記録（メモ）を記載することもできる。これら記録はプロバイダの利用のために保存することができ、そのレシピエントにケアを提供している他のサービスプロバイダと共有することもできる。
【００１４】
最後に、このシステムはケアプロバイダが課せられたタスクを適切に完了しつつあることを確認するために監視させることができる。例えば、特定のアクティビティが実行されているとき、場所、タイミング、加速計で計測される加速度およびフィードバックレスポンス（応答）の観点でパターン（定型様式）が開発される。これらのパターンは分析され、プロバイダのためのタスク完了の確率が計算できる。もしプロバイダが要求されるタスクを十分に実行していない疑いが存在するなら、改善のためのアクション（行動）をとることができる。
【００１５】
上述した本発明の様々な特徴は単独で、あるいは組み合わせて実施することができる。本発明のこれら、および他の特徴は以下の発明の詳細な説明中で、以下の図面と共にさらに詳細に説明されるであろう。
【００１６】
本発明をさらに明確に確認するため、いくつかの実施例が例示を目的とした添付の図面を参考にして説明されるであろう。
【図面の簡単な説明】
【００１７】
【図１】ある実施例に従ったリモートケアを実施するためのシステムの例示的ブロック図である。
【図２】ある実施例に従ったリモートケアマネージメントシステムの例示的ブロック図である。
【図３】ある実施例に従ったリモートケアマネージメントシステムのサービスプロバイダサポートモジュールの例示的ブロック図である。
【図４】ある実施例に従ったリモートケアマネージメントシステムの知人と家族のサポートモジュールの例示的ブロック図である。
【図５】ある実施例に従ったリモートケアマネージメントシステムのケアレシピエントサポートモジュールの例示的ブロック図である。
【図６】ある実施例に従ったリモートケアマネージメントシステムの支援サーバの例示的ブロック図である。
【図７】ある実施例に従ったリモートケア配達のプロセスのための例示的フロー図である。
【図８】ある実施例に従ったプロバイダ搭載のサブプロセスの例示的フロー図である。
【図９】ある実施例に従ったプロバイダをレシピエントにマッチングさせるサブプロセスの例示的フロー図である。
【図１０】ある実施例に従ったケア配達を監視するサブプロセスの例示的フロー図である。
【図１１】ある実施例に従った付加価値サービスをオファーするサブプロセスの例示的フロー図である。
【図１２】ある実施例に従ったフィードバックの回収のサブプロセスの例示的フロー図である。
【図１３】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１４Ａ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１４Ｂ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１５】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１６Ａ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１６Ｂ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１７】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１８】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図１９】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２０】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２１】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２２】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２３】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２４】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２５Ａ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２５Ｂ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２５Ｃ】ある実施例に従ったプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的スクリーンショットである。
【図２６Ａ】ある実施例に従ったリモートケアマネージメントのためのシステムを実行することができる例示的コンピュータシステムである。
【図２６Ｂ】ある実施例に従ったリモートケアマネージメントのためのシステムを実行することができる例示的コンピュータシステムである。
【発明を実施するための形態】
【００１８】
本発明を添付の図面に図示されている複数の実施例に関連させて詳細に説明する。以下の説明では、本発明の実施例の完全な理解を提供するために多数の特定細部が記載されている。しかしながら、当該技術の専門家であれば理解しようが、それら実施例はそれら特定細部の一部または全部を利用せずとも実施できる。その他の場合には、本発明を不必要に曖昧にしないように、よく知られているプロセスステップ及び／又は構造は詳細には説明されていない。実施例の特徴および利点は、図面と以下の説明からさらによく理解されるであろう。
【００１９】
本発明の代表的な実施例の態様、特徴および利点は添付図面と関連する以下の説明によってさらに理解が進むであろう。当該技術の専門家であれば、ここで説明されている本発明の実施例は説明のみを目的としており、本発明の限定を意図したものではないことを理解するであろう。この説明中に開示されている全ての特徴は、特に別途明示的に記載がない限り、同一または類似の目的を達成する代用特徴による置換が可能である。従って、その改良形態の多数の他の実施態様はここで定義されている本発明のスコープ内に入り、その均等物であると考えられる。よって、絶対的及び／又は順次的用語、例えば、“であろう”、“ではないであろう”、“なるであろう”、“ならないであろう”、“なければならない”、“なってはならない”、“第１の”、“当初は”、“次は”、“続いて”、“以前に”、“その後”、“最後に”、および“最終的に”などは本発明のスコープの限定を意味しておらず、ここに開示されている実施例は単なる代表例である。
【００２０】
ここに開示されているシステムと方法はリモートケア（遠隔ケア）のマネージメント（管理）に向けられている。典型的にはこのケアは独立して生活するために必要とされるアクティビティの補助のための非医療ケアである。用語“リモート”とは、レシピエントの居場所に補助が配達されるという意味である。多くの場合に、これにはレシピエントのホーム（住居）への補助の配達が含まれるが、提供されるサービスは必要とされる任意の場所（例えばスーパマーケット）へ配達（デリバリ）されることができる。
【００２１】
この開示を通して、食事の介護、身だしなみの手伝い、処方薬スケジュールの遵守アシスト、掃除およびその他の家事、等々のアクティビティのためのケアサービス、等々が特に強調されている。しかし、ここに開示しているシステムと方法はそのようなサービス内容に限定されることを必要としていない。例えば、そのようなリモートサービスは付添いサービス、特定のアクティビティ（身体的セラピー等）のアシスタンス、または子供の世話その他のサービスを含むことができる。
【００２２】
さらに、互換式に理解されることが意図されている多数の用語がこの明細書を通して利用されている。例えば、用語“プロバイダ（提供者）”、“サービスプロバイダ”、“ケア提供者”および“ケアプロバイダ”はしばしば、レシピエント（受領者）の居場所に赴いて必要とされるサービスを提供する個人に言及するよう互換的に使用されている。同様に、“サービス”、“アシスタンス”および“ケア”はしばしば、レシピエントに提供されている内容に言及されるように使用されている。また、“知人（友人）と家族”、“家族”、“顧客”は、レシピエントの健康に関心を寄せる第三者に言及するように使用できる。この個人はレシピエントの医者、セラピスト、保険会社、または他の非家族であることさえある。これら第三者はしばしばケアサービスの支払いに責任がある。しかし、これは常に必須とされているわけではない。さらに、“知人と家族”は典型的には単一の存在として言及されているが、レシピエントのケアに関するフィードバックを望む異なるグループであることも可能である。
【００２３】
以下の開示は一連のサブセクションを含んでいる。これらサブセクションは開示の限定を一切意図したものではなく、単に明確性と理解の容易化を目的としている。よって、１つのセクションの開示内容は、適用が可能であるなら別なセクションのプロセスまたは説明にも同様に適用できる。
【００２４】
Ｉ．リモートケアマネージメントシステム
説明のため、図１はリモートケアを実施するシステム１００の例示的概略ブロック図を提供する。ここには３人主要関係者が図示されている。すなわちサービスプロバイダ１０２、サービスレシピエント１１２およびレシピエントの知人／家族１２２である。これら人物は全てコンピュータ装置１０４、１１４、１２４にそれぞれアクセスを有している。
【００２５】
プロバイダ１０２によって採用されている装置１０４は任意のコンピュータ装置でよい。しかし、理想的にはその装置はモバイル装置（ネットワーク接続維持）であり、ＧＰＳを含んでいる。スマートフォンは便利なプラットフォームを提供し、しばしば装置１０４はスマートフォン、スマートウォッチその他類似装置でよい。
【００２６】
スマートフォンはレシピエント（受領者）１１２の装置１１４としても機能するが、実施形態によっては、レシピエント１１２は老人であり、あるいは肉体的または精神的な限界（制限、制約）を有している。それらレシピエント１１２のために、装置１１４ができるだけユーザフレンドリーであることが望ましい。しばしば、大きな表記文字、明るいスクリーン、タッチ機能および頑丈であることが重要である。ｉＰａｄ（登録商標）のごときタブレットやその類似装置が、そのスクリーンサイズがスマートフォンのものよりも大きいという理由でレシピエント１１２の装置１１４として適しているであろう。これで画面がさらに大きく、内蔵されたタッチスクリーンを備えている。
【００２７】
タブレットが“機能ロック”付きで、レシピエント１１２がインターフェースを簡素化するように限定されたオプションにだけアクセスできるようにすることができる。実施形態によっては、与えられた装置１１４で可能な機能はレシピエント１１２のケアニーズと技術的能力に対応させることができる。例えば、認知症を患うレシピエントは装置１１４が機能的に非常に限定されていることを必要とするであろう。恐らく、基本的なリマインダー機能やプロバイダに関する情報機能の提供に絞ることが必要であろう。もっと精神的に能力があり、技術的に問題がないレシピエントはウェブアクセス、ストリーミングメディアコンテンツ、Ｅメールアクセス、等々の大幅に増加した機能性を備えた装置１１４を所有できる。
【００２８】
実施形態によっては、レシピエント１１２の装置１１４が、レシピエントが装置に求める基準に構成されたカスタム仕上げであることがさらに望ましいであろう。例えば、実施形態によっては、もしレシピエントがパーキンソン病の進行段階であり、頻繁に落下させることなく装置を操作することが困難であるなら、装置は物理的損傷に対して抵抗性があるように硬質化させることができる。同様に、装置１１４によっては防水性で、触知インターフェースまたは音声インターフェース（視覚障害者用）を備え、（バッテリ式装置ではない）取り外し不能なコードを備えるも記録することが有益であろう。
【００２９】
レシピエントの知人／家族１２２によって利用される装置１２４は、概してさらに多彩である。典型的にはこれら装置１２４はフィードバック通信に使用され、よってインターネット接続が可能な任意の装置で普通は十分である。
【００３０】
それぞれの装置はネットワーク１０６を介してリモートケアマネージメントシステム１０８にアクセスできる。ネットワーク１０６は典型的にはインターネットを含んでいるが、例えば、コーポレートＷＡＮ、セルラーネットワーク、またはそれらの組み合わせのごとき他のネットワークを含むこともできる。リモートケアマネージメントシステム１０８はデータストア１１０にアクセスを有し、それは当該関係者のそれぞれの情報を含んだものであり、アクセス許可、プロフィール情報、位置、フィードバック、等々を含んでいる。
【００３１】
この実施例の図には単独レシピエント１１２、サービスプロバイダ１０２および家族／知人１２２が描かれているが、典型的にはリモートケアマネージメントシステム１０８にアクセスする非常に多くのこれらエントリが存在する。しばしば、単独レシピエント１１２はアシスタンスを提供する１人以上のプロバイダ１０２を有するであろう。同様に、１人のプロバイダ１０２は典型的には一週間で複数のレシピエント１１２の世話をする。さらに、既に述べたように、単独レシピエント１１２が家族／友人１２２を有していない場合や、そのように分類可能な非常に多数の個人を有して場合もある。
【００３２】
図２に移ると、リモートケアマネージメントシステム１０８のさらに詳細な例示的ブロック図が提供されている。このリモートケアマネージメントシステム１０８は典型的には装置から記録ラフィックを管理し、ケアの配達を実施するために該当装置をアップデートする１以上のサーバを含んでいる。
【００３３】
特に、リモートケアマネージメントシステム１０８は、プロバイダ、レシピエントおよび家族／知人にサポートを提供する少なくとも４つの論理サブシステムを有している。さらに、リモートケアマネージメントシステム１０８は処理を要する数多くのバックエンドアクティビティを実行する。これらの要求に応えるため、リモートケアマネージメントシステム１０８はサービスプロバイダサポートモジュール２１０、知人／家族サポートモジュール２２０、レシピエントサポートモジュール２３０および支援サーバ２４０を含んでいる。これらサブシステムのそれぞれは続く図面において詳細に説明されるであろう。
【００３４】
図３はサービスプロバイダサポートモジュール２１０の例示的ブロック図である。このモジュールは、どこで、いつプロバイダがアポイントメントを有しているか計算するスケジューラ（スケジュール手段）３１０を含んでいる。実施形態によっては、最も効率よく所定のレシピエントにケアを配達するために、スケジューラはプロバイダの位置に基づいて最善化プロセスを利用する。有利な実施形態によっては、フレキシブルにプロバイダのスケジュールをアップデートするために、スケジューラは移動時間、交通状態、移動モード、等々を考慮に入れることができる。例えば、もしプロバイダが、予測不能な問題のためにアポイントメントに長時間を必要としているなら、スケジューラはスケジュール全体を適宜にシフトさせるように構成できる。影響を受けるレシピエントはその遅延を通知されるであろう。
【００３５】
上述の実施例において、もしその遅延が大きければ、スケジューラはどのアポイントメントが重要（便利が基準ではない）であるかを決定するように構成でき、全ての重要なアポイントメントがタイムリーに処理されるのを確実にすることができる。重要度が低いアポイントメント予約は再スケジュール設定されるか、代わりのプロバイダが、プロバイダの予約状況と場所に基づいてフレキシブルにレシピエント記録にルート設定されることができる。
【００３６】
サービスプロバイダサポートモジュール２１０は、プロバイダの次のアポイントメントの方向と最適化されたルート設定を提供するためにプロバイダの位置とレシピエントの位置を利用するマッピング手段３２０も含むことができる。そのような特性は、プロバイダに自分のルートを視認させ、交通渋滞を回避させ、最も効率よく１つのアポイントメント位置から次のアポイントメント位置へと行かせることができる。
【００３７】
サービスプロバイダサポートモジュール２１０は、プロバイダ１０２にレシピエントの知人／家族１２２に直接的に通信させるメッセージシステム３３０も含むことができる。これで“間断のない”状況アップデートをプロバイダとリモート（離れた）関係者との間で通信させることができる。
【００３８】
最後に、サービスプロバイダサポートモジュール２１０はレシピエントフィードバックモジュール３４０を含むことができる。以下で詳細に説明するように、プロバイダとレシピエントに、マネージメントシステム１０８への相互に関するフィードバックを提供させる性能はプロバイダ−レシピエントペアリングの最適化を可能にする。正直なフィードバックを得るために、このフィードバックは要約形態または集積形態にて提供することができる。
【００３９】
図４に移ると、知人／家族サポートモジュール２２０の例示的ブロック図が提供されている。知人／家族サポートモジュール２２０は通知モジュール４１０、付加価値サービスモジュール４２０および請求システム４３０で成る。
【００４０】
通知モジュール４１０はレシピエント１１２に関するアップデートと通知を知人／家族１２２に提供する。これらアップデートはプロバイダ１０２によって発生（生成）されたメッセージを含むことができ、さらにサービス、請求サイクル、等々に関するリマインダーとステータスアップデートを含むことができる。
【００４１】
付加価値サービスモジュール４２０はレシピエント１１２のプロフィール、趣味およびニーズの分析に基づいた追加サービスまたは追加の機会をオファー（提供）する。従来のケア代理業者とは異なり、本開示システムは透明性と、レシピエントのケアを改善するためのデータセットのテコ入れ能力の恩恵を受けている。ケアサービスを申し込んだ際に入力された膨大なプロフィールを含んだレシピエントに関する豊富な情報が収集される。このプロフィールは、年齢、性別、体重、身長、趣味、以前の職業経験、所在地、ペット、肉体的および精神的な限界、個人的達成物、伝統、好きな休日、好きな受け取ったギフト、最も大切な記憶、好きな人物、主観的“完全日”、友人に最も価値を置くもの、等々を含むことができる。このプロフィールはレシピエント自身によって編集することができ、レシピエントの知人や家族によって編集することもできる。
【００４２】
この限定的なプロフィールに加えて、やがてレシピエント１１２にケアを施す様々なプロバイダ１０２が交流に関して記録（ノート）およびアップデートを発生（生成）させる。実施形態によっては、レシピエント１１２の好みに関する追加の洞察を発生させるため、これら記録とメッセージは自然語プロセス技術を利用して分析できる。例えば、プロバイダはレシピエントの知人／家族に、自分が“本当に今日の散歩を楽しんだ”というメッセージを送ることができる。別の日に別なプロバイダは、レシピエントが“花について語ること、特にバラについて語ることを楽しむ“と記した記録を作成することができる。
【００４３】
付加価値サービスモジュール４２０は、それら収集した洞察やプロフィールに基づいてイベントや追加のサービスの最適化を実行することができる。例えば、もし、共通の地理的位置でケアを受領する十分な数の個人が類似の関心事を共有するなら、そのシステムは植物園への外出をチャータするオファーを発生（生成）させることができる。散歩、庭、花、社会活動に関心があり、そのような活動のための肉体能力を維持しているレシピエントには、付加価値サービスモジュール４２０を介してオファーが提供できる。そのような活動にはしばしば追加料金が発生し、よって、そのようなオファーはまず（ケアを金銭的にサポートすると考えられる）知人／家族１２２に提供できる。金銭的に決定を委ねられている人物により承認された後、そのオファーはレシピエントに回され、関心があるか否かが尋ねられる。オファーの承認または断りはオファーされている付加価値サービスをさらに改善するようにトラッキング（追跡調査）できる。
【００４４】
付加価値サービスはアクティビティの大きな可能性を含んでいる。それらは、例えばコンサートツアーへの出席のごとき特別なイベントを含むことができ、前記した植物園のごとき定期的な“遠足”を含むこともできる。またそれらは無料または低コストの定型サービス、例えば、類似した関心事を有する個人間の懇親会を含むこともできる。イベントに加えて、付加価値サービスはレシピエントの安全、健康、等々を増進させることを目指した他のサービスを含むことができる。例えば、レシピエントが医者の予約をとることに問題を有していることにプロバイダが気付けば、このシステムはレシピエントのプロフィールに照らして適した移動手段を決定し、医療機関の予約が予定通りに進行することを確実にするようにオファーすることができる。例えば、もしレシピエントが精神的および感情的に比較的健全であるなら、予約を確実に予定通りに進行させるには単純な配車サービスで十分であろう。しかしながら、例えば車椅子あるいは認知症のレシピエントには特別な設備が必要であろう。付加価値サービスが受け入れられた後に必要な移動手段が手配される。
【００４５】
付加価値サービスの別例は商業ベースの非プロバイダ（プロバイダ以外）サービスを含むことができるであろう。例えば、プロバイダはレシピエントがペットの世話や自宅の基本的な維持管理に困難を有していると記録に記すことができる。これはシステムに、犬の散歩サービスまたは便利屋サービスのアレンジのオファーと翻訳することができる。実施形態によってはケアプロバイダと共に、これら追加サービスのプロバイダは、信頼できる個人のみがレシピエントに関わることができることを確実にするために審査されることができる。不幸にも、サービスプロバイダが老人あるいは取り残された他の社会の人々を騙す傾向が存在する。しばしば、利用可能な保護はほとんど存在しない。ここで提供される付加価値サービスは、（プロバイダの観察を介して）サービスが実際に必要とされていることを保証することでこのようなリスクを最小限にし、（好かれたプロバイダの地位を維持するために）自分のクライアントを公正に扱うことに天賦の関心を有する信用できる個人によってサービスが配達されることを確実にする。
【００４６】
システムが提供できる追加の付加価値サービスはレシピエント監視サービスを含むことができる。虚弱な健康状態のレシピエントの場合、またはアルツハイマー症のごとき精神的な障害を有するレシピエントの場合、何百キロまたは何千キロも離れている可能性もある知人や家族には大きな心理的負担がかかる可能性がある。それらの心配に対処できる自動化された監視サービスを導入することが可能である。
【００４７】
監視サービスはビデオ及び／又はオーディオ監視を含むことができ、さらに健康統計を含むことができる。健康データの収集のためにレシピエントの装置は基本的健康データを自動的な形態で単に収集するプラットフォームを含むことができる。例えば、この装置は血中酸素添加および脈拍データを収集する光トランスジューサを含むことができる。実施形態によっては血圧計も含むことができ、それによってシステムによる血圧データの収集を可能にする。この装置はまた、体重、活動レベル、および転倒の証拠、または他の急激な加速のごとき追加の情報を収集するために体重計、血糖モニタ、歩数計、加速度計、等々の周辺装置と共に無線ネットワークに連結することもできる。あるいは、そのようなデータはレシピエントにケアを提供している誰かによって入力されることもできる。
【００４８】
ビデオ監視及び／又はオーディオ監視に関して、監視のレベルはレシピエントの望みによってバランスされるであろう。稀には、レシピエントのホームはレシピエントの安全を保障するビデオ−オーディオ監視を備えている。他の中間的な監視は、自動的に監視し、もし動作レベルが所定の閾値以下であれば警告を提供するモニタセンサを含むことができる。例えば、レシピエントがベッド内で一晩中比較的に動作しない状態であっても、これはシステムによって許容範囲内と設定されることができるが、２０分間、廊下内で比較的に動かないレシピエントは、レシピエントを動作不能にしている転倒または他の事故を示しているかも知れない。そのような動作センサシステムは、“問題”が検出されたときだけ起動するビデオシステムと結合させることができる。これで転倒のごとき問題の迅速で効果的な検出が可能になるであろう。
【００４９】
あるいは、ビデオシステムを備えた、あるいはビデオシステムを備えていないモーションセンサシステムによって検出された“問題”は“チェックイン”を提供するためにレシピエントのプロバイダの１人を自宅にルート設定することができる。これらサービスは、レシピエントの健康の保証を助け、知人や家族に心の平安を提供する。
【００５０】
もちろん、本開示内に全てをリストアップすることは厄介であるぐらい、そのような監視サービスの非常に多数の変更例が存在する。例えば、レシピエント装置１１４を中央に配置し、動作センサまたはカメラを含むことができる。よって、その監視はホーム全体ではなく１つの部屋に限定される。あるいはホーム内に設置されたセンサではなく、レシピエントは一日に周期的に自身の装置１１４を介した“チェックイン”の提供を要求され、もしレシピエントがチェックインしなければケア提供者による自宅訪問が発生するようにすることができる。
【００５１】
別な安全サービスは、知人や家族に提供中のケア状況を見させ、レシピエントとホームの状態も併せて見させるボディカメラを有したケアプロバイダを含むことができる。
【００５２】
さらに、知人／家族サポートモジュール２２０の最後の特徴は請求システム４３０である。この請求システムはプロバイダによるサービス料および付加価値サービス料の支払い、並びにケアマネージメントシステム全体の利用料金の支払いをさせるものである。前述したように従来のケア代理業者は、代理業者の役割を排除し、顧客に対する料金引き下げの可能性に繋がるプロバイダの直接雇用のアレンジの虞等の数多くの理由によってプロバイダとレシピエントの知人および家族との間の直接接触を制限している。インターフェースプラットフォームは価値をプロバイダの単なる特定とは無関係化するのでシステムはそのような懸念を育まない。
【００５３】
図５はケアレシピエントサポートモジュール２３０の例示的ブロック図である。サービスプロバイダプロファイラ（プロフィール分析手段）５１０はレシピエントにプロバイダの画像を提供し、プロバイダがいつレシピエントのホームに到着するかを示す。これで誰かが予期せぬ形態で来訪することによる驚嘆と不要な恐怖が排除される。
【００５４】
同様に、レシピエントは評価システム５２０を介してプロバイダを評価するようにリクエスト（要請）される。レシピエントのプロバイダによる評価と同様に、正直なフィードバックを可能にするよう、これら評価は秘密保持でき、あるいは、要約形態または集積形態で提供できる。この評価システムはプロバイダ−レシピエントマッチングの判断、並びにプロバイダ適格性の判断を向上させるために活用される。
【００５５】
そのような機能に対応する十分な能力をレシピエントが有するとみなされる場合には、一部のレシピエントの装置に緊急応答モジュール５３０を利用可能にすることができる。これでレシピエントは装置１１４上の“パニック”形態ボタンを選択するだけで緊急時ケアのために容易に助けを求めることができる。あるいはレシピエントに緊急状況時に迅速に助けを要請させることができるウェアラブルインターフェースまたは装置を提供することができる。
【００５６】
最後に、一部のレシピエントのためにメッセージシステム５４０はケアプロバイダ、家族と知人、医療関係者、精神衛生カウンセラー、精神ガイダンスカウンセラー、等々との直接的な通信を可能にする。このメッセージシステムは、システムを金銭的に支える個人に承認されたら付加価値サービスをレシピエントに提示するように利用することもできる。
【００５７】
さらに、図６は支援サーバ２４０の例示的ブロック図を提供する。この支援サーバ２４０は、サービスプロバイダマッチング装置６１０を介してプロバイダをレシピエントにマッチング（適合）させるごとき必須の活動を実行する。このマッチングプロセスは以下でさらに詳細に説明されており、最も成功したレシピエント−プロバイダマッチングを保証するためにフィードバックに基づいたプロフィールマッチングおよび最適化を利用する。
【００５８】
スケジュールオプチマイザ（最適化装置）６２０は、プロバイダの位置、レシピエントの位置とニーズ、およびプロバイダの限界に基づいてプロバイダ１２０のためのスケジュールを最適化する。共同でルートオプチマイザ６３０はそれぞれのレシピエントアポイントメントへのプロバイダのルート設定を実行する。場合によっては、プロバイダによって利用される移動手段の形態（自動車、自転車、公共輸送手段、等々）がこのルート設定において考慮されるであろう。さらに別の実施形態ではルートオプチマイザ６３０は効率をさらに高めるためにプロバイダ及び／又はレシピエントの共同移送のためのアレンジをすることができる。例えば、多くのレシピエントは既に、移動性を維持するために身体不自由者のためのバスサービスに依存しているかも知れない。もしこれらシェアライドサービスが専用ルートを有しているならプロバイダはアポイントメントに出向くためにそれら存在するインフラを活用することができる。
【００５９】
リモートケアのマネージメントのために採用されるシステムは相当程度詳細に説明されたので、ケアの効率を好適化するために採用されるプロセスの説明をすることにする。
【００６０】
ＩＩ．リモートケアマネージメント方法
以下の図面と説明はリモートケアをマネージメントする方法のいくつかの代表的な実施例に過ぎない。ケアマネージメントの実効性を改善するために開示されている方法の変更と置換は本発明のスコープ内にあると考えるべきである。
【００６１】
図７はリモートケアの配達のプロセスのための例示的フロー図７００である。当初的にサービスプロバイダはオンボード（搭載）状態（７１０）である。図８は、ある実施形態に従ったプロバイダオンボード化のサブプロセスのさらに詳細なフロー図である。ここで、プロバイダの情報はシステムによって受領される（８１０）。プロバイダ情報は参考情報、資格証明書、個人のプロフィール、証明書および以前の仕事履歴を含むことができる。場合によっては健康データ、限界、重要記録、等々の追加の情報が必要であろう。
【００６２】
プロバイダの資格が、ネットワークへのエントリに必要な最低限の資格と比較される（８２０）。これら資格はサービスプロバイダの予約状況、サービスニーズ、等々によって相当に変わり得る。例えば、場所によっては食事の世話や基本的な身の回りの世話をする軽作業プロバイダの強い需要が存在するかも知れない。そのようなプロバイダのための最低資格は大部分のレシピエントが、例えば後期の認知症患者である場所でのプロバイダの資格より大幅に低いものであろう。
【００６３】
プロバイダがこれら基本的な条件を満たすか否かの決定が実行される（８３０）。もし満たしていなければ、そのプロバイダはプロバイダとしてシステムに参加する資格はない（８９０）。しかし、もしプロバイダが基本的条件を満たしていれば、次の段階は一連の背景チェックを実行することである（８４０）。これら背景チェックは、プロバイダの以前の職歴、資格証明および申請者に関して提供された人物証明書の内容に関する情報を評価する。さらに犯罪歴チェックが実行され、場合によっては申請人のソーシャルメディアアカウントおよびクレジットスコアのチェックも必要であろう。
【００６４】
プロバイダはしばしば、虐待、窃盗または詐欺から自身を守ることができない個人の自宅内で非常に密着して作業するユニークな特権と責任を有している。よってプロバイダは非常に注意深くスクリーニングされなければならない。もし申請人が背景チェックを通過しなければ（８５０）、彼らは適格基準から外れる（８９０）。
【００６５】
しかし、もし申請人が全ての背景チェックを通過すれば、次の段階はサービスプロバイダのプロフィールを好適プロフィールと比較することである（８６０）。本開示システムと方法は、プロバイダの経験、資格証明、職業情報および他の背景情報に関する比較的に豊富なデータセットを収集するため、このデータは、レシピエントのニーズ基準をほぼ満たすことであろうプロバイダのプロフィールを発生（生成）させるために活用される。従って、新プロバイダのためのオンボード化プロセス中に、申請人のデータは要求されるプロバイダのプロフィールと比較できる。申請人の情報と要求プロフィールとの間の相違の程度が測られ、申請人がプラットフォームのために適格であるかどうかを決定する閾値と比較される。この閾値はフレキシブルであってもよく、高い閾値は多数のプロバイダが既にオンボード化されている場合に適用され、低い閾値はさらに多くのプロバイダが必要なときに適用される。説明した候補者の詳細な調査に加えて、申請人の適格性を判定するために一連の本人直接評価が同様に利用できる。
【００６６】
もし申請人のプロフィールが閾値を遥かに下回れば（８７０）、申請人はその時点ではプラットフォームには受け入れられない（８９０）。しかしながら、もし申請人が適性に関するそれぞれの質問を通過すれば、彼らはプロバイダとして受け入れられる（８８０）。この受け入れは、彼らが自身の装置１０４で機能するアプリケーションを介してケアマネージメントシステム１０８へのアクセスを有することの確認を含んでいる。プロバイダのレシピエントとのマッチング（適合）を実行するために、彼らの予約状況、移動手段、等々に関する追加の情報がさらに収集されることができる。
【００６７】
図７に戻ると、プロバイダオンボード化後にそのサービスプロバイダはレシピエントとマッチング（適合）され（７２０）、それは図９で相当程度詳細に開示されている。このマッチングステップは当初的にはレシピエントの位置によってプロバイダを分別する（９１０）。プロバイダがレシピエントから離れ過ぎて活用が困難であれば直ちに潜在的なマッチングから廃棄される。
【００６８】
続いて、対象のレシピエントに十分に近いプロバイダが、必要とされる資格により分別される（９２０）。この分別はレシピエントの個人的な要求に全面的に依拠する。例えば、もしレシピエントが移動のために身体的補助を必要とするなら、プロバイダはそれを提供できなければならない。別例は、レシピエントがスペイン語のみを話す場合には、効果的にケアを配達するためには複数言語を話すプロバイダが必要である。あるいはレシピエントは特殊技能、特殊資格、等々を備えたプロバイダを必要とする場合もあろう。
【００６９】
プロバイダの位置と、レシピエントの特殊なニーズを満たす条件によってプロバイダの候補リストを狭める本開示プロセスは今日の代理業者が既に実行しているものに類似する。典型的には、これらアクションは、ここで開示する自動化プロセスを介してではなく手作業で実行される。本発明システムが従来の取り組みに勝るのは、それぞれのプロフィールに基づいて、レシピエントのために適したプロバイダが最適化されることである（９３０）。既に述べたように、レシピエントとプロバイダとの両方の豊富な情報が収集される。さらに、一緒に活動することの満足度に関してプロバイダとレシピエントの両方からフィードバックが収集される。このビッグデータセットからプロフィール両立性の傾向が特定化され、これらの相関付けに重点が置かれる。よって、新規にプロバイダとレシピエントのマッチングが考慮されるとき、彼らのプロフィールはこれら過去の特定化に照合比較できる。すなわちレシピエントに対して最適な“適合性”を有するプロバイダが選択できる。
【００７０】
もし特定のレシピエントに“適合”するプロバイダが複数で存在するなら、プロバイダを偏ることなく選別するために、彼らのそれぞれのスケジュールを分析することができる（９４０）。これで仕事の公正な配分が保証され、過労の問題が回避できる。しかし、理解されるであろうが別実施形態では、別なプロバイダに仕事を回す前に１人のプロバイダのスケジュールを完全に満たすことが好適であろう。よって、プロバイダの好み、プロバイダの数、および市場競争に基づいて仕事量の均衡のためにいくつかの方法が採用できる。
【００７１】
あるいは、このシステムはそのレシピエント及び／又は家族に何人かの適したプロバイダを提示でき、彼らにプロバイダを選択させることができる。プロバイダが異なる金額レベルで請求することも可能であろうし、これら請求額の相違をプロバイダの選択時に考察に入れることができる。
【００７２】
上述の複雑なマッチングプロセスに代わって、プロバイダとレシピエントのマッチングに市場原理（取引環境、取引経路）を活用することも可能である。このような別実施形態ではプロバイダはケアを必要とするレシピエントを通知されるであろう。ケア配達の大体の位置、特殊ニーズ、必要なケアスケジュール、さらにプロフィール詳細のごとき詳細情報もプロバイダに利用可能にできるであろう。もしそのプロバイダに関心があれば、レシピエントに対して志願（申請）できる。最も良さそうなプロバイダを選択するため、レシピエント及び／又は家族構成員は全ての対象プロバイダのプロフィールを閲覧できる。
【００７３】
そのような市場原理スタイルのマッチングプロセスはプロフィールマッチングに先行することができ、プロバイダにはさらにフレキシブルなサービス料金の設定を可能にする。よって、さらに高い教育／経験／資格を有するプロバイダは、さらに高い料金を要求するために彼らの専門性を生かすことができる。事実、このシステムがここに開示する市場原理（取引経路）から独立してプロバイダをレシピエントにマッチングするときでさえ、様々なプロバイダは異なる料金体系を設定できる。
【００７４】
さらに、レシピエントの位置とニーズが考慮される場合には混成アプローチが採用でき、“適合性インデックス”を描画するためにプロフィール最適化が実行される。このインデックスは単純なスケールであり得、例えば１から１０の数字でよく、候補のプロバイダとレシピエントとの間のマッチングが良好であるとシステムが信じるか否かを表わす。これはプロバイダが候補の仕事を追い求めるか否かを決定するときに彼らによって活用できる。同様に、このインデックスはレシピエントによって、関心を抱くプロバイダ間で選択するときに利用することができる。
【００７５】
別な混成アプローチは、対象レシピエントのために全ての適したプロバイダを特定し、それぞれのプロバイダに働く機会を提供する。適性はプロバイダがレシピエントの全ての基本的ニーズを満たし、レシピエントが居住する地理的位置においてサービスを提供することを求める。一旦プロバイダに働く機会が提示されると、サブセットは説明したものに類似した方法の市場原理的アプローチで“申請”することを選択するであろう。しかし、レシピエントの知人と家族に、このアプローチによってどの候補プロバイダを利用するかを最終的に決定させる代わりに、このシステムはレシピエントと全ての候補プロバイダとの間の適合性を最適化する。その後に最適なに“適合”したプロバイダにレシピエントのケア権利が付与される。
【００７６】
図７に戻ると、プロバイダをレシピエントにマッチングした後にサービスがプロバイダによって配達されるが（７３０）、このことは図１０に関して詳細に説明されている。当初的に、このシステムはプロバイダのためにアポイントメントスケジュールを最適化する（１０１０）。このプロセスは、それぞれのレシピエントにサービスを提供するためにプロバイダが十分な容量（余裕）を有するか否かを考察する。多くのレシピエントは１日に１回以上のケアを必要とするであろう。しかし、レシピエントによっては、さらに少ない頻度の訪問を希望しており、スケジュール設定プロセスは、１人のプロバイダのために様々なレシピエント間でダブルブッキングが発生しないことを確実化する。このスケジュール設定プロセスはレシピエントのニーズと好み、並びにレシピエントの所在位置も考慮に入れる。
【００７７】
例えば、１人のレシピエントはベッドから起き出すのに助けが必要であり、それが朝一番のサービスであるとスケジュール設定されている。次のアポイントメントは通勤の負担を最低限にするため（およびレシピエントと最大限の時間を一緒に過ごすため）近場のサービスをスケジュール設定することができる。３番目のアポイントメントは食事の世話を必要とするレシピエントにスケジュール設定でき、続いて一般的な身だしなみの世話のために近くの別のレシピエントにスケジュール設定できる。その後にプロバイダは上記の食事の世話のために戻らなければならないかも知れない。
【００７８】
最後に、スケジュール設定最適化はプロバイダの実績から学習し、必要に応じて成果を利用できる。例えば、もしプロバイダが３番目と４番目のアポイントメント間に毎回遅れるようなら、スケジューラは時間通りに４番目のアポイントメントに来られるようプロバイダに余裕を持たせるために４番目のアポイントメントの時間を遅らせることができる。
【００７９】
次のステップは様々なアポイントメント間でプロバイダのために最適なルート設定を提供することである（１０２０）。プロバイダの装置１０４はＧＰＳ機能を含んでおり、マッピングプログラムは容易に利用が可能であるため、プロバイダがアポイントメント間で最も効率的にルート設定されることを確実にすることは比較的に容易なタスクである。しかし、前述したように本システムの実施形態によっては、プロバイダの移動手段の好みに基づいた最適なルート設定をさらに可能にし、あるいはプロバイダをプライベートシェアリング形態の交通手段とマッチングさせることさえ可能である。
【００８０】
レシピエントは自分の装置１１４でプロバイダに関する情報を含んだアポイントメントに関する情報が与えられる（１０３０）。前述したように、この情報はプロバイダの画像、プロバイダの氏名、およびアポイントメントの時間を含むことができる。この情報は、レシピエントがアポイントメントを受け入れる準備できていることを確認させ、誰かがレシピエントのホームに進入することに関わるストレスを減少させる。
【００８１】
同様に、プロバイダにはケアのインストラクションとレシピエントのプロフィールへのアクセスを含んだレシピエントに関する情報が与えられる（１０４０）。さらに、過去のアポイントメントから引き継がれたプロバイダの記録を表示することができ、重要な事柄を全てプロバイダにリマインドさせる。実施形態によっては、レシピエントにケアを提供している他のプロバイダの記録を表示させることさえ可能であろう。
【００８２】
例えば、レシピエントが認知症であり、しばしば常軌を逸して行動すると想定する。この個人は複数のケアプロバイダを利用しているかも知れない。朝にレシピエントは食事を拒絶しており、概して頑固である。最初のケアプロバイダは次のケアプロバイダのために、レシピエントの気分に問題があることを注意し、食事を欠いているため食事の世話に優先順位があることを記した記録を残すことができる。これで、以前に可能であったケア内容よりもさらに改善された協調ケアが可能になる。
【００８３】
プロバイダがレシピエントの位置（典型的にはレシピエントの住居）に到着し、表示されたケアを配達する。プロバイダはケアマネージメントシステムに、サービスが付与されたという確認を送る（１０５０）。この確認は、料金請求を目的として、レシピエントが要求されたケアを受けていることを証明するために重要であり、レシピエントの知人や家族にケアが提供されていることをチェックインさせる。
【００８４】
最後に、適用可能である場合には、付加価値サービスがオファーできる（１０６０）。これら付加価値サービスのオファーは図１１に関してさらに詳細に説明されており、このシステムはまず付加価値サービスのリクエスト（要請）または推薦を受ける（１１１０）。これは、新規サービス（例えば、予定されているイベント）の予約状況、プロバイダによる推奨（例えば、スクリーンが修理を必要としていることを示すメッセージ、あるいはレシピエントが社交ピクニックを利用できることを示すメッセージ）、知人や家族からの推奨（例えば、知人がレシピエントに特別な旅行をプレゼントするようリクエストする誕生日を祝福するため）、あるいはレシピエント自身によって促されることができる。場合によってはレシピエントの装置１０４は、レシピエントが閲覧できる利用可能な付加価値サービスのカタログを有することができる。レシピエントが興味を持てるような何かを発見したら、彼らは追加情報のリクエストを発することができる（金銭的な決定権者による承認の必要有）。
【００８５】
付加価値サービスのリクエストが為されたら、このシステムはレシピエントのプロフィールを利用可能な付加価値サービスとマッチングさせ、最適な適合を決定する（１１２０）。例えば、壊れたスクリーンを修繕するリクエストに関しては、スクリーンを遅滞なく修繕できる可能性がある誰かを特定するために審査を経ている便利屋のリストがレシピエントの位置を考慮して検討される。同様に、社交イベントのリクエストのためには、このシステムは、レシピエントが楽しめ、物理的に出席が可能なイベントを見つけるためにレシピエントの興味に照らして開催予定のイベントを調べることができる。
【００８６】
次のステップは、提示サービスに関心があるか否かを調べるためにレシピエントに付加価値サービスをオファーすることである（１１３０）。もし関心があれば、次は適正な承認が確保されていることを確認することである（１１４０）。金銭的に自己管理することができる精神的な能力を有するレシピエントの場合には、レシピエントは必要な承認を提供する完全な能力がある。しかし、レシピエントの精神的能力が低下している場合にしばしば起こり得ることであるが、知人または家族に金銭的に依存する環境では承認は適した個人から求められる。
【００８７】
承認が確保された後に付加価値サービスが提供できる（１１５０）。これらサービスの意図はレシピエントのためにそのプロセスを容易化することである。よって、このシステムは、スクリーンを修繕するための便利屋の訪問を、ケアプロバイダからの既に予定が決められているアポイントメントと調和させるように試みることである。これで当該プロバイダは質問に応答することができ、必要とされているとろにアクセスを提供し、レシピエントのストレスを軽減させることができる。同様に、このシステムは、いかなる付加価値イベントであっても、食事の世話、付添い、移動、等々の支援に対応できるように構成できる。
【００８８】
図７に戻ると、全てのサービスがプロバイダによって提供された後、プロバイダとレシピエントのマッチングを改善し、問題点を洗い出すためにフィードバックが求められる（７４０）。図１２は一部の実施例に従ったフィードバック収集のサブプロセスに関する追加の詳細を図示する。
【００８９】
前述したように、本開示システムのユニークな利点の１つは、プロバイダがレシピエントの知人および家族に提供される透明性のレベルである。この目的のため、ケアマネージメントシステムを通じて彼らの間のコミュニケーションが可能になっている。プロバイダは知人と家族にアップデートされたメッセージを送ることができる。同様に、実施例によっては、このメッセージ機能は双方向性である。
【００９０】
このメッセージ機能に加えて、秘密扱いのフィードバックがプロバイダとレシピエントから収集できる（１２２０）。このフィードバックはプロバイダとレシピエントとの間のサービスの質向上に利用でき、さらに他のレシピエントとプロバイダとの間の将来のマッチングの最適化を助けるように利用できる。同様に、前述したごとく、人気が高いプロバイダの特質を確認するためにプロバイダの評価が利用できる。このようにフィードバックは有用であるが、評価者の過去の評価、プラットフォーム上の期間、または特定個人的特質を含むことができる様々な要因を考慮し、評価の潜在的な信頼性に基づいてレシピエントにより提供されたフィードバックを標準化することが必要であろう（１２３０）。
【００９１】
収集されたフィードバックが、配達されているサービスにおいて調整が必要であることを示せば（１２４０）、適した調整が実施されるであろう。典型的にはこれには、提供されているケアの変更を含むか、あるいはプロバイダとレシピエントの再マッチングを含むことができる（１２５０）。しかし調整が必要ではないとフィードバックが示す場合には、ケアは一切の変更なく継続することができる（１２６０）。
【００９２】
ＩＩＩ．実施例
リモートケアのマネージメントのためのシステムと方法をある程度詳細に説明したので、次に１以上の装置に採用されているこのシステムの実施態様の様々な例の説明に移ることにする。この説明を助けるため、図１３から図２５Ｃにはプロバイダとレシピエントにそれぞれ提供される様々なユーザインターフェーススクリーンの例示的なスクリーンショットを図示する。これらスクリーンショットは例示としてのみ提供されており、ここに開示された発明のスコープを不当な制限することなく発明を明確化することが意図されている。
【００９３】
図１３はプロバイダのスマートフォンあるいは他のモバイル装置に表示されるホームスクリーン１３００を図示する。ここでホームスクリーンはトップにプロバイダの氏名とプロフィール画像を示しており、選択される一連のナビゲーションメニューを含んでいる。特にプロバイダにはツール、予約状況、顧客、仕事、支払い、およびセッティングのナビゲーションメニューが与えられる。いくつかのナビゲーションメニューは続くスクリーンショット図でさらに詳細に探査されるであろう。
【００９４】
セッティングツールはプロバイダに自身の表示セッティングを構成させ、自己証明（パスワードとユーザネーム）、連絡先情報、資格認定証、サービス地域、等々をログインさせる。この予約状況メニューは彼らが仕事を引き受けることができる日時をプロバイダに選択させる。この予約状況情報はこのシステムによって実行されるスケジュール設定プロセス中に活用できる。支払いメニューはプロバイダが提供したサービスに対して行われる支払いをプロバイダにコーディネートさせることができる。
【００９５】
図１４Ａに移ると、本実施例のために“今日”メニュースクリーンショット１４００Ａが図示されている。ここでは様々なアポイントメントがプロバイダに提示されており、それらにはアポイントメント時間、アポイントメント時間の長さ、アポイントメントタイプ、アポイントメント先、アポイントメント実行内容、アポイントメント位置（場所）および到着時アポイントメントクロックイン能力（スタート時間記録）が含まれる。一方、図１４Ｂには、プロバイダがアポイントメントでクロックインしたら同じ“今日”メニュー例のスクリーンショット１４００Ｂが示される。全ての仕事が実行されたときプロバイダはアポイントメントが“完了”したことを示すことができる。
【００９６】
実施例によっては、ルート設定システムを再設定するためにアドレス（居場所）がプロバイダによって選択されることができ、これは前述したように複数のアポイントメント間でプロバイダのルート設定を最適化する。同様に実施形態によっては、図示されているタスクは別なインストラクションを含んだ実行されるべきタスクの完全説明にまで図示のショートカットアイコンから拡張されるように選択できる。
【００９７】
さらに、実施形態によっては、対象レシピエントのためのプロフィール、タスクおよび記録をプルアップするためにレシピエントの氏名または画像が選択できる。図１５はこのメニューの例示的スクリーンショット１５００を図示しており、そこではタスクが当初アポイントメントのために選択されている。そのアクティビティに関するいくらかの詳細を含んでアクティビティが提供される。例えば、このレシピエントはアポイントメント毎に少なくとも３０分の散歩と付添いを希望する。レシピエントが何を楽しむか、関心あるトピック、等々の詳細も同様に提供される。この分野は将来の参考としてプロバイダによって修正が可能であり、対象レシピエントの他のプロバイダと共有されることもできる。
【００９８】
それぞれのアクティビティは所定の仕事の完了をトラッキングするため記録グルボックスを含むことができる。全てのタスクが完了すると、アポイントメントの完了を描画するためにプロバイダはクロックアウト（終了時間記録）するオプションも有する。図１６Ａに示すように、アポイントメントの完了でプロバイダはそのアポイントメントを評価するように依頼されることができる（１６００Ａ）。正直なフィードバックを担保するためこの評価はレシピエントからは秘密に保たれる。このデータはレシピエントによるプロバイダの評価と共にレシピエントをプロバイダに最良にマッチングさせるために利用され、必要に応じて、レシピエントに提供されているサービスを前述のように変更することができる。この評価に加えて、プロバイダにはレシピエントの家族と知人のためのメッセージを作成する機会が与えられる。図１６Ｂは、プロバイダが家族のためにレビューとメッセージを入力したときのスクリーンショット１６００Ｂを図示する。このメッセージはアポイントメントの進行状況をトラッキングする機能と共に、従来式に提供されているサービスのほとんどで現在得られていない大きな安心を家族に提供する。
【００９９】
図１７はレシピエントのファイルの記録部分の例示的スクリーンショット１７００を図示する。これら記録はプロバイダによって任意の時に作成および編集でき、プロバイダのためのリマインダーを維持するために使用される。ここに図示されているように対象レシピエントの家族はレシピエントによる宝くじの購入を制限するようにプロバイダにリクエストしている。さらにプロバイダはアポイントメントでレシピエントがリクエストしたアクティビティのタイプに関する記録を含ませている。図１８はプロバイダが新規記録を作成するように選択した１例のスクリーンショット１８００を図示する。前述のように、これら記録はそのプロバイダ専用とすることができ、あるいはレシピエントを訪問する全てのケアプロバイダ間で共有することができる。
【０１００】
図１９はプロバイダの顧客メニューの例示的スクリーンショット１９００を図示する。このページから任意の顧客／レシピエントが選択でき、彼らのプロフィールとケアプランがプロバイダに対して提示される。例えば、レシピエントの氏名または画像が選択されるとプロフィールページ２０００が図２０に表示される。このレシピエントのプロフィールには彼らの氏名、画像および諸々個人情報が含まれる。例示として表示されているこのプロフィールおよびこの情報のどれもレシピエントのプロフィールに含まれることができる。しかし、実施例によってはレシピエントのプロフィールが、このシステムおよびプロバイダの対象ニーズ、あるいはレシピエントの好みに基づいて、実質的には程度の差こそあれ情報を含むことができることも理解されるべきである。
【０１０１】
この例示的プロフィールでは、次のアポイントメント、アドレス、年齢、性別、身長、体重、好きな挨拶、肉体的限界、精神的限界、ペット、匂いに対する敏感性、プロバイダによる屋内上履使用の可否、現在または過去の職業、最高実績、受け取った最高ギフト、好きな休日、最も大切な記憶、最適な特徴、好きな人物、完全日および友情価値付けが全て表示される。さらに、典型的なプロフィールは、プロバイダとレシピエントとの間の交流ナビゲーションに有用である可能性を備えた家族、好き会話トピック、好きな食べ物、好きなアクティビティ、好きなテレビ番組、抑え難い欲望、等々の情報も含んでいる。
【０１０２】
さらに進むと、ケアプランメニューが選択されると、レシピエントに関係するタスク、最近の記録、アポイントメントのスケジュールが図２１に図示されているスクリーン２１００に表示されている。これでプロバイダはレシピエントのニーズの概要とスケジュール設定された交流を迅速に見つけることができる。
【０１０３】
図２２はプロバイダのホームスクリーンで選択できる仕事メニューの例示的スクリーンショット２２００を図示する。前述したようにプロバイダとレシピエントはシステムの実施形態に応じて、いくつかの方法でマッチングできる。場合によっては、このシステムはレシピエントをプロバイダとペア化するためにマッチングの最適化を活用することができる。しかしながら、他の実施形態においては、与えられた機会をプロバイダに直接的に追及させる市場原理スタイルの交流（交換）が発生できる。ここで説明する例示的スクリーンショットはそのような市場原理（取引経路）の１例を示す実施例である。ここでは新規機会がマッチング最適化に基づいてまずプロバイダに提示できる。そのような実施形態においては多数のプロバイダがその機会のために選択され、それぞれには、その機会を受け入れるか断るオプションが提供される（最初にリストされた仕事におけるパターン）。彼らの決定が確実に伝わるように、レシピエント、時間、タスクおよび位置に関する詳細がプロバイダに提供される。
【０１０４】
もしプロバイダがその機会を追及すると決定したら、ステータスは“新規”から“検討中”に変化し、プロバイダの情報はレシピエント及び／又はレシピエントの知人と家族に送られる。レシピエント及び／又はレシピエントの知人／家族が、幾人かの関心を寄せるプロバイダの情報を収集したら、彼らがベストマッチングと考えるプロバイダを選択することができる。
【０１０５】
プロバイダの観点からは、もしレシピエントが別なプロバイダを選択すれば、仕事ステータスは“検討中”から“充填”に変化するであろう。あるいは、もし彼らがその機会に受け入れられたら、ステータスは“承認”にアップデートされる。このように、プロバイダは市場原理スタイルの交換を介して効率的にレシピエントにマッチングされる。アプリケーションプロセスの一部として、プロバイダの評価、最適化プロセスにより決定された適合、支払条件、等々に関する情報がレシピエント及び／又はレシピエントの知人／家族にも提供できる。また、前述したように、彼らが機会を追及するときはプロバイダのプロフィールも含まれる。
【０１０６】
図２３はそのようなプロバイダのプロフィールの例示的スクリーンショット２３００を図示する。レシピエントのプロフィールとほぼ同様に、プロバイダの氏名および画像が含まれており、誕生日、契約情報、資格証明書および個人的好み（趣味、好き嫌い）等の個人情報も含まれる。さらに、一部のプロフィールには職業履歴、使用言語および他の関連情報も含まれる。繰り返すがこのプロフィール情報は、適したプロバイダが対象レシピエントとマッチングされることを確実にするためにマッチング最適化によって活用できる。
【０１０７】
レシピエント側に話を移すと、本開示のシステムは予定されているアポイントメントに関する情報を提供するレシピエントのホーム内で使用されている装置を含んでいる。一般的には、ユーザエラーの可能性を制限するため、柔軟な制限された機能を提供するように、この装置はロック機能を有している。このことは特に老齢で、技術に疎く、あるいは精神的にハンディを有するレシピエントのために重要である。しかし、技術的に能力があるレシピエントにとっては、装置は、そこで運用されるアプリケーションを搭載するタブレット、スマートフォンまたはラップトップを含むことができる。そのような装置は、前述したように高性能化された機能を有することができる。
【０１０８】
図２４は、予定されているアポイントメントに関する情報がレシピエントに対して提示されているそのような１実施例による例示的スクリーンショット２４００を図示する。ここには現在の日時と、アポイントメントの時間、プロバイダの氏名と画像が共に表示されている。この実施例では、装置はアップロードされる写真も有することができ、レシピエントが個人写真を見るオプションを提供することができる。
【０１０９】
図２５Ａで示すように、プロバイダ自身の装置によるアポイントメントのクロックアウトによって示されるアポイントメントの完了で、レシピエントの装置はプロバイダに関するフィードバック２５００Ａをリクエストできる。繰り返すが、正直な回答を促すため、このフィードバックは秘密扱いにすることができ、マッチング最適化およびケアアジャストメントプロセスにおいて利用される。図２５Ｂは、レシピエントがプロバイダの評価を選択したときの画面２５００Ｂを、図２５Ｃはそのフィードバックが成功裏に提出されたときの画面２５００Ｃを図示する。
【０１１０】
最後に、図２６Ａと図２６Ｂは、本発明の実施例を運用するのに適しているコンピュータシステム２６００を図示する。図２６Ａはコンピュータシステム２６００の１つの可能な物理的形態を示す。もちろん、コンピュータシステム２６００は、プリント回路ボード、集積回路および小型手持ち装置から大型スーパコンピュータまでカバーする多数の物理的形態を有することができる。コンピュータシステム２６００はモニタ２６０２、ディスプレー２６０４、ハウジング２６０６、ディスクドライブ２６０８、キーボード２６１０およびマウス２６１２を含むことができる。ディスク２６１４は、コンピュータシステム２６００との間でデータを送るのに使用されるコンピュータ読み取り可能媒体である。
【０１１１】
図２６Ｂはコンピュータシステム２６００のブロック図の１例である。システムバス２６２０には多彩なサブシステムが取り付けられている。プロセッサ２６２２（中央処理装置すなわちＣＰＵともいう）がメモリ２６２４を含んだ記憶装置に接続されている。メモリ２６２４はランダムアクセスメモリ（ＲＡＭ）とリードオンリメモリ（ＲＯＭ）を含んでいる。当分野では周知であるがＲＯＭはデータとインストラクションをＣＰＵに片方向で移すのに利用され、ＲＡＭは典型的にはデータとインストラクションを双方向で移すのに利用される。これら両タイプのメモリは以下で述べるコンピュータ読み取り可能媒体の任意の適したものを含むことができる。固定ディスク２６２６もプロセッサ２６２２に双方向的に接続できる。それは追加のデータ保存能力を提供し、以下で述べる任意のコンピュータ読み取り可能媒体を含むことができる。固定ディスク２６２６は、プログラム、データ、等々の保存に使用でき、典型的にはプライマリ（一次）記憶媒体よりも遅いセカンダリ（二次）記憶媒体（ハードディスク等）である。固定ディスク２６２６内に保存された情報は適した場合にはメモリ２６２６内にバーチャルメモリとして標準形態で取り込みが可能であることは理解されるであろう。取り出し可能なディスク２６１４は以下で説明する任意のコンピュータ読み取り可能媒体の形態を採用することができる。
【０１１２】
プロセッサ２６２２は、ディスプレー２６０４、キーボード２６１０、マウス２６１２およびスピーカ２６３０のごとき様々な入力／出力装置にも接続されている。一般に入力／出力装置は、ビデオディスプレー、トラックボール、マウス、キーボード、マイクロフォン、タッチ式ディスプレー、トランスジューサカードリーダ、磁気テープまたは紙テープリーダ、タブレット、スタイラス、ボイスまたは文字認識器、バイオメトリックリーダ、モーションセンサ、脳波リーダ、その他のコンピュータの任意のものでよい。プロセッサ２６２２はオプションでネットワークインターフェース２６４０を使用して別コンピュータまたはテレコミュニケーションネットワークに接続できる。そのようなネットワークインターフェース２６４０によって、前述のケアマネージメントを実行する過程でプロセッサ２６２２が情報をそのネットワークから受け取ること、または情報をそのネットワークに出力することが想定されている。さらに、本発明の方法の実施形態はプロセッサ２６２２で単独に、あるいは処理の一部を共有するリモートＣＰＵと共にインターネットのごときネットワークで実行することができる。
【０１１３】
まとめると、本発明はリモートケアの配達のマネージメントのためのシステムと方法を提供する。そのようなシステムの利点には、プロバイダのさらに効率的なルート設定とスケジュール設定、レシピエントとプロバイダの改善されたマッチング、およびレシピエントの家族や知人に心の平安を提供する向上した透明性を通じてケア配達の効率を改善する能力が含まれる。
【０１１４】
本発明をいくつかの実施例を使用して説明してきたが、それらの別例、改良例、変更例、代替均等例が存在しており、それらは本発明のスコープ内に含まれるものである。本発明の説明を助けるためにサブセクションのタイトルが提供されているが、それらタイトルは単に説明の為であり、本発明のスコープの制限は意図されていない。
【０１１５】
本発明の方法と装置を実施する多数の代替方法が存在することも述べておく。よって、以下の請求項は、それら全ての別例、改良例、変更例、代替均等例を本発明の真の精神およびスコープ内に含むと解釈されることが意図されている。
【図１】
2018518783.tif 000003
【図２】
2018518783.tif 000004
【図３】
2018518783.tif 000005
【図４】
2018518783.tif 000006
【図５】
2018518783.tif 000007
【図６】
2018518783.tif 000008
【図７】
2018518783.tif 000009
【図８】
2018518783.tif 000010
【図９】
2018518783.tif 000011
【図１０】
2018518783.tif 000012
【図１１】
2018518783.tif 000013
【図１２】
2018518783.tif 000014
【図１３】
2018518783.tif 000015
【図１４Ａ】
2018518783.tif 000016
【図１４Ｂ】
2018518783.tif 000017
【図１５】
2018518783.tif 000018
【図１６Ａ】
2018518783.tif 000019
【図１６Ｂ】
2018518783.tif 000020
【図１７】
2018518783.tif 000021
【図１８】
2018518783.tif 000022
【図１９】
2018518783.tif 000023
【図２０】
2018518783.tif 000024
【図２１】
2018518783.tif 000025
【図２２】
2018518783.tif 000026
【図２３】
2018518783.tif 000027
【図２４】
2018518783.tif 000028
【図２５Ａ】
2018518783.tif 000029
【図２５Ｂ】
2018518783.tif 000030
【図２５Ｃ】
2018518783.tif 000031
【図２６Ａ】
2018518783.tif 000032
【図２６Ｂ】
2018518783.tif 000033
【国際調査報告】
2018518783.tif 000034
2018518783.tif 000035
2018518783.tif 000036