JP2019197269A

JP2019197269A - 健康サポートシステム

Info

Publication number: JP2019197269A
Application number: JP2018089390A
Authority: JP
Inventors: 正一浜田; Shoichi Hamada; 翔木村; Sho Kimura; 浩久今村; Hirohisa Imamura; 平野浩次; Koji Hirano; 浩次平野
Original assignee: Renesas Electronics Corp
Current assignee: Renesas Electronics Corp
Priority date: 2018-05-07
Filing date: 2018-05-07
Publication date: 2019-11-14
Also published as: US20190341151A1

Abstract

【課題】ユーザの健康状態の推定および健康状態の改善を促す健康サポートシステムを構築する。【解決手段】健康サポートシステムは、ユーザの生体情報を取得する第一センシング装置と、抽象化データに基づいて動作する第一アクチュエータ装置と、前記第一センシング装置と前記第一アクチュエータ装置とにネットワークを介して接続される第一サーバと、を前記ユーザが普段生活を行う日常生活空間に備える。前記第一センシング装置または前記サーバは前記生体情報に基づいて前記抽象化データを生成する。前記抽象化データは前記ユーザの健康状態を推定して分類したものである。前記第一アクチュエータ装置は前記ユーザの健康状態の改善を促す。【選択図】図１

Description

本開示は健康サポートシステムに関し、例えば家電機器を用いた健康サポートシステムに適用可能である。

家電機器は、一般家庭に広く浸透し、人々の生活を大きく変化させてきた。例えば、冷蔵庫や洗濯機などの白物家電は家事の効率を大幅に向上させ、テレビやステレオなどの映像音響機器は新しい娯楽を提供してきた。これら複数の家電機器とホームサーバとにより家電システムを構成したり（例えば、特開２００２−３１５０７９号公報）、複数の家電機器をネットワークで接続して家電システムを構成したりすることが提案されている（例えば、特開２０１５−１８４５６３号公報）。

特開２００２−３１５０７９号公報特開２０１５−１８４５６３号公報

日常生活における活動をサポートする機能を持つ装置（例えば、家電機器、住宅施設品、車載装置）を用いて、ユーザの健康状態の推定および健康状態の改善を促す健康サポートシステムを構築する。
その他の課題と新規な特徴は、本開示の記述および添付図面から明らかになるであろう。

本開示のうち、代表的なものの概要を簡単に説明すれば、下記のとおりである。
すなわち、健康サポートシステムは、日常生活空間にあるセンシング装置でセンシングされたセンシングデータに基づいてユーザの健康状態を推定して抽象化し、抽象化された前記健康状態の抽象化データに基づいてアクチュエータ装置が前記ユーザの健康状態の改善を促す。

上記健康サポートシステムによれば、ユーザの健康状態の推定および健康状態の改善を促すことができる。

日常生活空間の健康サポートシステムの構成例を示す図である。図１のセンシング装置、アクチュエータ装置およびバイ・ファンクション装置の概略構成を示すブロック図である。図２のセンシング装置に内蔵されたセンサおよびそのセンシング情報を処理するマイクロコンピュータ（ＭＣＵ）のブロック図である。図２のアクチュエータ装置に内蔵されたＭＣＵおよびアクチュエータのブロック図である。自宅と健康情報データベースを持ち出す外出先との構成を示す図である。図５Ａのホテルのアクチュエータ装置、バイ・ファンクション装置およびセンシング装置の構成例を示す図である。図５Ａの民泊住居のアクチュエータ装置、バイ・ファンクション装置およびセンシング装置の装置例を示す図である。自宅およびホテルでの健康生活サポートシステムを説明する図である。自宅とホテルとの健康情報データベースの記録内容を示す図である。図７Ａの自宅のホームサーバの健康情報データベースの記録内容を拡大して示す図である。図７Ａのホテルの端末の健康情報データベースの記録内容を拡大して示す図である。図７Ａの自宅のホームサーバの健康情報データベースの記録内容を拡大して示す図である。温暖地域の自宅から寒冷地域のホテルに外出した場合を示す図である。自宅のホームサーバとホテルの端末と民泊住居のホームサーバの動作をシーケンス図で示す図である。ホテルの端末とセンシング装置とアクチュエータ装置の動作をシーケンス図で示す図である。お腹の調子による装置制御処理のフローチャートである。トイレによるデータ取得処理を示すフローチャートである。トイレ１４０ａによるセンシングデータの取り得る組合せを表で表す図である。お腹の調子の抽象化処理のフローチャートである。お腹の調子の抽象化処理のフローチャートである。トイレ１４０ａのセンシングデータを中間データに変換するテーブルを示す図である。トイレ２４０ａのセンシングデータを中間データに変換するテーブルを示す図である。トイレ３４０ａのセンシングデータを中間データに変換するテーブルを示す図である。中間データを１日単位で積算した表を示す図である。お腹の体調を抽象化する条件を示す図である。ある期間において下痢を検出した場合のお腹の体調記録例を示す図である。図１９の下痢回数を折れ線グラフで表した図である。自宅のアクチュエータ装置等の動作を示すフローチャートである。風邪判定の概要を示すフローチャートである。ユーザの体温変化履歴を示す図である。発熱風邪判定表を示す図である。発熱風邪検知処理のフローチャートである。ユーザの開鼻声スペクトラム履歴を示す図である。閉鼻声スペクトラム履歴を示す図である。閉鼻声風邪判定表の一例を示す図である。閉鼻声風邪検知処理のフローチャートである。ユーザの咳の音声波形パターンを示す図である。咳回数風邪判定表の一例を示す図である。咳回数風邪検知処理のフローチャートである。ユーザのくしゃみの音声波形パターンを示す図である。鼻風邪音声回数判定表の一例を示す図である。鼻風邪音声回数検知処理のフローチャートである。ユーザのくしゃみ動作パターンを示す図である。鼻風邪動作回数判定表の一例を示す図である。鼻風邪動作回数検知処理のフローチャートである。各センシング結果から導出した風邪レベルから抽象化データを総合判定する例である。ストレスレベル抽象化の処理を示すフローチャートである。センシングデータから抽象化の中間データを抽出するテーブルである。ストレス判定テーブルの一例を示す図である。自宅からタクシーを用いて外出する場合の健康情報データベース持ち出し例を説明する図である。アクチュエータ装置の一例であるエアクッションの構成を示す図である。

以下、実施形態および実施例について、図面を用いて説明する。ただし、以下の説明において、同一構成要素には同一符号を付し繰り返しの説明を省略することがある。

＜実施形態＞
（日常空間の健康サポート）
普段生活を行う居住空間（以下、日常生活空間という。）における健康サポートシステムについて図１〜４を用いて説明する。図１は日常生活空間の健康サポートシステムの構成例を示す図である。図２は図１のセンシング装置、アクチュエータ装置およびバイ・ファンクション装置の概略構成を示すブロック図である。図３は図２のセンシング装置に内蔵されたセンサおよびそのセンシング情報を処理するマイクロコンピュータ（ＭＣＵ）のブロック図である。図４は図２のアクチュエータ装置に内蔵されたＭＣＵおよびアクチュエータ機器のブロック図である。

図１に示すように、日常生活空間の一例である自宅１００は、サーバの一例であるホームサーバ１１０と、アクチュエータ装置１２０と、バイ・ファンクション装置１３０と、センシング装置１４０と、それらを接続するネットワークの一例であるホームネットワーク１５０と、を備える。

ホームサーバ１１０はＣＰＵと入力部と表示部と通信部と記憶部とを備え、記憶部は健康情報データベース１１１および健康情報データベース１１１より解析した機器の最適な制御情報である機器制御情報１１２を格納している。ホームサーバ１１０の健康情報データベース１１１はマスターデータである。

また、ホームサーバ１１０の通信部は自宅１００に設置されたアクチュエータ装置１２０、バイ・ファンクション装置１３０およびセンシング装置１４０との通信ＩＦ（インタフェース）を持ち、データ送受信の機能を有する。また、アクチュエータ装置１２０、バイ・ファンクション装置１３０およびセンシング装置１４０はすべて通信ＩＦを有しており、ホームネットワーク１５０を介してホームサーバ１１０と機能分類に応じた内容の通信を行う。

アクチュエータ装置１２０は、外部より制御を行うことで機器動作や情報表示する機能を有する、受動的な動作を行う装置であり、ホームサーバ１１０より機器制御情報１１２の制御信号を受信し、設定や動作を変更する。例えば、照明１２０ａやＴＶ（テレビジョン）１２０ｂ、電子レンジ１２０ｃ、炊飯器１２０ｄ、冷蔵庫１２０ｅ等の家電機器、および風呂１２０ｆ等の住宅施設品がアクチュエータ装置１２０に該当し、ホームサーバ１１０より受信した装置のユーザ（利用者）である居住者（住人）の健康状態に応じて最適な動作を提案する。

センシング装置１４０は、各装置に内蔵されたセンサなどによりセンシング情報を取得し動作状況を外部にデータ送信する機能を有する装置であり、ホームサーバ１１０に対しセンシング情報を送信する。例えば、トイレ１４０ａ等の住宅施設品、ベッド１４０ｂ等の家具、および電話機１４０ｃ、電動歯ブラシ１４０ｄ、ドライヤ１４０ｅ等の家電機器がセンシング装置１４０に該当し、体温、脈拍、心拍、声の調子、咳の回数など生体情報を取得し、抽象化健康情報（以下、抽象化データという。）を推定し、ホームサーバ１１０に送信する。抽象化データの推定はホームサーバ１１０で行ってもよい。

バイ・ファンクション装置１３０はアクチュエータ装置１２０とセンシング装置１４０の両方の機能を持ち、外部からの制御およびセンサによるセンシング情報を他機器にデータ送信、およびセンシング情報を自己の制御にも用いることができる、能動的な装置である。バイ・ファンクション装置１３０はセンシング機能を有するアクチュエータ装置であり、アクチュエータ機能を有するセンシング装置である。バイ・ファンクション装置１３０はホームサーバ１１０から制御信号を受信したり、センシング情報を送信したりする。例えば、エアコン１３０ａや洗濯機１３０ｃ等の家電機器および洗面台１３０ｂ等の住宅施設品がバイ・ファンクション装置１３０に該当する。

図２に示すように、センシング装置１４０はホームサーバ１１０を介してアクチュエータ装置１２０およびバイ・ファンクション装置１３０を動作させる。センシング装置１４０はマイクロコントローラ（ＭＣＵ）１４１とセンサ１４２とを備える。センサ１４２は例えば温度センサ、着座センサ、湿度センサ、音量センサ等である。ＭＣＵ１４１はセンサ１４２のセンシング情報を処理し抽象化しホームサーバ１１０に送信する。

アクチュエータ装置１２０はＭＣＵ１２１とアクチュエータ１２３とを備える。アクチュエータ１２３は例えばモータ、スピーカ、ヒータ、灯り等である。ＭＣＵ１２１はホームサーバ１１０からの機器制御情報１１２に基づいてアクチュエータ１２３を動作させる。

バイ・ファンクション装置１３０はＭＣＵ１３１とセンサ１３２とアクチュエータ１３３とを備える。センサ１３２は例えば温度センサ、着座センサ、湿度センサ、音量センサ等である。アクチュエータ１３３は例えばモータ、スピーカ、ヒータ、灯り等である。ＭＣＵ１３１はセンサ１３２のセンシング情報を処理し抽象化しホームサーバ１１０に送信する。ＭＣＵ１３１はホームサーバ１１０からの機器制御情報１１２または自身がセンシング情報を処理し抽象化した情報に基づいてアクチュエータ機器１２３を動作させる。

図３に示すように、センサ１４２（温度センサ１４２ａ、着座センサ１４２ｂ、湿度センサ１４２ｃ、音量センサ１４２ｄ）から出力された信号はＭＣＵ１４１に内蔵された周辺装置（Peripheral）１４４（アナログ／デジタル変換器（ＡＤＣ）１４４ａやタイマ（ＴＩＭＥＲ）１４４ｂ、汎用Ｉ／Ｏポート（ＧＰＩＯ）１４４ｃ、シリアルインタフェース（Serial ＩＦ）１４４ｄなど）でＭＣＵ１４１に取り込まれる。ＣＰＵ１４５の解析により記憶装置１４６の不揮発性メモリ（ＦＬＡＳＨ）１４６ａおよび揮発性メモリ（ＲＡＭ）１４５ｂに記録されているセンシング情報のパターンから抽象化データを選択する。抽象化データは周辺装置１４４の通信モジュール（シリアルインタフェース（Serial IF）１４４ｄ）でホームサーバ１１０に送信される。ＣＰＵ１４５により実行されるソフトウェアプログラムは記憶装置１４６に格納される。抽象化データの選択は記憶装置１４６にある既存データを読み出すのではなく、ＭＣＵ１４１内でセンシング情報を蓄積および学習したデータからユーザの健康状態を割り出し、抽象化データを生成するＡＩ機能であってもよい。

図４に示すように、ＣＰＵ１２５はホームサーバ１１０から受信した抽象化データを解析し、記憶装置１２６の不揮発性メモリ（ＦＬＡＳＨ）１２６ａおよび揮発性メモリ（ＲＡＭ）１２６ｂに記録されている最適な制御方法を選択する。ＣＰＵ１２５は周辺装置１２４であるデジタル／アナログ変換器（ＤＡＣ）１２４ｅやタイマ１２４ｂを制御し、アクチュエータ１２３のモータ（Motor）１２３ａやスピーカ（Speaker）１２３ｂ、ヒータ（Heater）１２３ｃ、灯り（Lighting）１２３ｄ、その他の家電機器（Other Home Appliance）１２３ｅの駆動制御を行う。制御方法の選択方法は、記憶装置１２６に保存された既存制御データを読み出すのではなく、ＭＣＵ１２１内で蓄積および学習したデータから最適な制御方法を割り出すＡＩ機能であってもよい。

次に、健康サポートシステムの動作について説明する。
（１）センシング情報から抽象化データの作成
自宅１００に設置され、かつホームネットワーク１５０に接続されたセンシング装置４０やバイ・ファンクション装置１３０が装置使用状況などを各装置自身で収集する。情報収集手段としては、電源ＯＮ、ＯＦＦや機器のコース設定、センサなどによる接触情報などがある。各装置は収集したデータを解析し、居住者の抽象的な体調をホームネットワーク１５０を通じてホームサーバ１１０の健康情報データベース１１１に蓄積する。

ホームサーバ１１０は機器制御情報１１２を蓄積して解析し、居住者の抽象的な体調を健康情報データベース１１１に格納してもよい。例えば室内温度や炊飯器の調理設定など長期間同じ使い方であれば健康状態は良好のように記録する。一定期間平常時と異なる使い方や設定を検知すると体調に問題があると判断し、ストレス状態や風邪のような症状と、症状の度合いを抽象的な健康情報（抽象化データ）として記録する。
（２）抽象化データに基づいたアクチュエータ装置の制御
自宅１００では、健康情報データベース１１１を基に機器制御情報１１２を生成し、設置されたアクチュエータ装置１２０およびバイ・ファンクション装置１３０に制御信号を送信し自動制御を行ったり、情報表示を行ったりする。居住者の体調に合わせて各装置の設定を変更したり、体調を整える装置の使い方を居住者に提案したりすることもできる。

ここではホームサーバ１１０により機器制御情報１１２を生成し装置を制御する方法を記述したが、健康情報データベース１１１に格納された体調等の健康情報を直接アクチュエータ装置１２０およびバイ・ファンクション装置１３０に送信し、各装置が居住者の体調にあわせて自動制御したり、情報提供を行ったりする構成としもよい。

（多拠点での健康サポート）
次に、日常生活空間および普段生活を行わない居住空間（以下、非日常生活空間という。）における健康サポートシステムについて図５Ａ〜５Ｃ、６、７Ａ〜７Ｄを用いて説明する。

図５Ａは自宅と、健康情報データベースを持ち出す外出先との構成を示す図である。図５Ｂはホテルのアクチュエータ装置、バイ・ファンクション装置およびセンシング装置の構成例を示す図である。図５Ｃは民泊住居のアクチュエータ装置、バイ・ファンクション装置およびセンシング装置の装置例を示す図である。図６は自宅およびホテルでの健康生活サポートシステムを説明する図である。図７Ａは自宅とホテルとの健康情報データベースの記録内容を示す図である。図７Ｂ、７Ｄは図７Ａの自宅のホームサーバの健康情報データベースの記録内容を拡大して示す図であり、図７Ｃは図７Ａのホテルの端末の健康情報データベースの記録内容を拡大して示す図である。

非日常生活空間の一例であるビジネスホテル等のホテル２００は、自宅１００より装置の少ない生活空間である。非日常生活空間の他例である民泊住居３００は、自宅１００より装置の多い生活空間である。ここで、民泊とは、宿泊用に提供された個人宅の一部や空き別荘、マンションの空き室などに宿泊することである。

ホテル２００の端末２１０および民泊住居３００のホームサーバ３１０はホームサーバ１１０と同様の機能を持つが、健康情報データベース１１１を持ち帰るか、別生活空間に移動した場合に消去される点が異なる。

図５Ｂ、５Ｃに示すように、アクチュエータ装置２２０、バイ・ファンクション装置２３０、センシング装置２４０、アクチュエータ装置３２０、バイ・ファンクション装置３３０およびセンシング装置３４０は、アクチュエータ装置１２０、バイ・ファンクション装置１３０およびセンシング装置１４０と同様の装置種類であるが、設置されている装置の数量や機種、機能が異なるものである。例えば、ホテル２００のアクチュエータ装置２２０には電子レンジおよび炊飯器が含まれていない。また、バイ・ファンクション装置２３０には洗濯機が含まれていない。また、センシング装置２４０には電話機および電動歯ブラシが含まれていない。一方、民泊住居３００のアクチュエータ装置３２０には電子レンジが含まれていないが、ガスレンジ３２０ｇ、ＩＨ調理器３２０ｈおよび空気清浄器３２０ｉが含まれている。また、センシング装置３４０には、トイレ１４０ａの代わりに洗浄トイレ３４０ａが含まれ、ＡＩスピーカ３４０ｆが含まれている。

次に、自宅およびホテルでの健康サポートシステムの動作について説明する。
（１）抽象化データの作成
図７Ｂに示すように、ホームサーバ１１０内の健康情報データベース１１１には毎日の居住者の体調が記録されている。体調の記録である「健康情報記録」には、例えば「お腹」、「ストレス」等の状態が記録される。健康情報データベース１１１には、「ステータス」として自宅、外出等の「環境設定」も記録される。
（２）抽象化データに基づいたアクチュエータ装置の制御
（３）抽象化データのホテルや民泊住居への持ち込み
健康情報データベース１１１は、不揮発性メモリなどのデータ保存手段やインターネットなどのネットワークを通じて自宅１１０からホテル２００へ持ち出すことが可能である。

図５Ａに示すように、ユーザは自宅１００からホテル２００および民泊住居３００に健康情報データベース１１１を持ち出す。

持ち出した健康情報データベース１１１は非日常生活空間であるホテル２００や民泊住居３００に持ち込むことで、その空間に設置され装置に応じて最適な制御を行い、居住者の快適な空間を作り出すことができる。

１０月８日より出張のためホテル２００へ外出し、自宅１００から持ち出した健康情報データベース１１１を端末２１０にロードすると当日以前までのデータによってアクチュエータ装置２２０、バイ・ファンクション装置２３０およびセンシング装置２４０の制御を行う。また、当日よりホテル２００の室内のバイ・ファンクション装置２３０およびセンシング装置２４０により抽象化した健康情報を取得し、図７ＣのＣに示すように、持ち出した健康情報データベース１１１へデータを追記していく。この場合、「環境設定」の蘭には「外出」が記録される。１０月９日より体調を崩す（下痢になる）と、ホテル２００の室内において体調に合わせたアクチュエータ装置２２０およびバイ・ファンクション装置２３０の制御を行う。
（４）自宅１００の装置と同じ環境でなくとも、ホテル２００、民泊住居３００に設置されている装置は、可能な限り最適な動作を提供する。

日常生活空間である自宅１００と非日常生活空間であるホテル２００、および民泊住居３００とでは、設置している装置の過不足や機種が異なる場合がある。その性能差を吸収するため、ホテル２００の端末２１０および民泊住居３００のホームサーバ３１０は、その空間に設置された装置の情報と、ロードされた抽象化した健康情報データベース１１１の内容を基に、各装置の最適な制御方法を自動で決定する。
（５）ホテル２００や民泊住居３００で蓄積した抽象化データは自宅１００に持ち帰ることで、継続して健康状態に応じた装置のサポートを受けることができる。

１０月１１日に帰宅したが、体調は戻っておらず普段の装置の制御とは異なる設定を行うが、図７Ｃに示すように健康情報データベース１１１にはホテル２００の室内で取得した抽象化データが記録されており、帰宅してホームサーバ１１０へロードすると図７Ｄに示すように外出時のデータが統合されその情報を基にホテル２００の室内の環境と同じ、体調不良時における快適環境を継続して受けることが出来る。図７ＤのＤは帰宅後に記録されたデータである。

外出先など生活空間が変わった場合でも、持出しデータによりそのときの健康状態に最適な装置の制御を自動で行うことができ、快適な空間を得られる。また、健康情報と設置されている装置とからユーザに適した生活環境を再現するよう装置の制御を行うため、生活空間を移動した場合でも装置の操作を意識することはない。また、ユーザの健康情報を携帯化することにより、普段の生活空間で蓄積したデータに引き続き外出先でのデータを追記することができるため、データの連続性を確保することができる。また、外出先でユーザの使用状況を取得することができるようになるため、どこにいても体調変化の兆候や発生を早期に知ることができ健康維持ができる。さらに、帰宅後に外出先で収集したデータと自宅のデータとを統合できるため、安定した健康サポートを受けることができる。

次に、外環境が異なる地域へ健康情報データベースを持ち出した場合の装置の動作例について図８、９Ａ、９Ｂを用いて説明する。図８は温暖地域の自宅から寒冷地域のホテルに外出した場合を示す図である。図９Ａは自宅のホームサーバとホテルの端末と民泊住居のホームサーバの動作をシーケンス図で示す図である。図９Ｂはセンシング装置とホームサーバとアクチュエータ装置の動作をシーケンス図で示した図である。

外出先地域（ホテル２００）の外環境が自宅１００の外環境と異なる場合、外出先の気候状況に合わせて装置の設定を微調整する。自宅１００の外環境の気候情報（例えば気温データ）を取得し健康情報データベース１１１に記録しておく。例えば温暖地域の自宅１００から寒冷地域への旅行などの場合で大きく気温差がある時期は、寒冷地域のホテル２００でも外環境の気候情報を取得し、エアコンの温度を上げたり、日照時間が異なるのであれば早めに点灯させたり、冷蔵庫の温度を高めに設定したり、風呂を温めにすることを表示したりする。

ステップＳ１：温暖地域の自宅１００のホームサーバ１１０はセンシング装置１４０またはバイ・ファンクション装置１３０から抽象化データを取得し健康情報データベース（抽象化データベース）１１１に蓄積する（ステップＳ１ａ）。抽象化データベースを寒冷地のホテル２００の端末２１０に持ち込む（ホームサーバ１１０が端末２１０に送信する）（ステップＳ１ｂ）。

ステップＳ２：ホテル２００の端末２１０は持出し中であることをホームサーバ１１０の通知する（ステップＳ２ａ）。端末２１０は健康情報データベース１１１の抽象化データをアクチュエータ装置２２０に送信する（ステップＳ２ｂ）。

アクチュエータ装置２２０は抽象化データと外環境情報である気候情報とで設定され（ステップＳ２ｃ）、設定完了を端末２１０に通知する（Ｓ２ｄ）。センシング装置２４０はセンシングデータを取得し（ステップＳ２ｅ）、端末２１０に送信する（ステップＳ２ｆ）。または、取得したセンシングデータを抽象化して抽象化データを端末２１０に送信する（ステップＳ２ｆ）。

端末２１０は受信完了をセンシング装置２４０に送信する（ステップＳ２ｇ）。抽象化データを健康情報データベース１１１に追記する（ステップＳ２ｈ）。ステップＳ２ｂからステップＳ２ｈを繰り返す。

健康情報データベース１１１を自宅１００に持ち帰る（端末２１０がホームサーバ１１０に送信する）（ステップＳ２ｉ）。

ステップＳ３：ホームサーバ１１０は持ち出した健康情報データベースと持ち帰った健康情報データベース１１１との抽象化データの差分を反映する（ステップＳ３ａ）。ホームサーバ１１０は端末２１０の健康情報データベース１１１を削除する（ステップＳ３ｂ）。ホームサーバ１１０はセンシング装置１４０またはバイ・ファンクション装置１３０から抽象化データを取得し健康情報データベース１１１に蓄積する（ステップＳ３ｃ）。抽象化データベースを温暖地域の民泊住居３００のホームサーバ３１０に持ち込む（ホームサーバ１１０がホームサーバ３１０に送信する）（ステップＳ３ｄ）。

ステップＳ４：民泊住居３００のホームサーバ３１０は持出し中であることをホームサーバ１１０の通知する（ステップＳ４ａ）。ホームサーバ３１０はセンシング装置３４０またはバイ・ファンクション家電３３０から抽象化データを取得し抽象化データを健康情報データベース１１１に追記する（ステップＳ４ｂ）。健康情報データベース１１１を自宅１００に持ち帰る（ホームサーバ３１０がホームサーバ１１０に送信する）（ステップＳ４ｃ）。

ステップＳ５：ホームサーバ１１０は持ち出した健康情報データベースと持ち帰った健康情報データベース１１１との抽象化データの差分を反映する（ステップＳ５ａ）。

実施形態では、非日常生活空間としてホテルや民泊住居の例を説明したが、これに限定されるものではなく、自家用車やタクシー、電車等の車内空間、自家用船舶やクルーズ客船等の船内空間、自家用飛行機や旅客機等の機内空間であってもよい。

実施形態によれば、下記の効果がある。
（１）日常生活空間に設置されたセンシング装置により、意識することなく、その居住者（ユーザ）の抽象化された健康状態を把握することができる。
（２）センシング装置の情報によりアクチュエータ装置を直接制御する場合、それぞれの機種や機器数に一対一の関係が必要な特殊制御系となる。言い換えれば、センシング装置とアクチュエータ装置との間に一対一の関係が存在しない場合、その制御関係を保つことができない。一方、センシング装置からのセンシングデータに基づいた抽象化された健康状態をもとに、アクチュエータ装置が健康サポートする場合、必ずしもセンシング装置とアクチュエータ装置との間に一対一の関係が存在しなくともよい。その結果、居住者が異なるアクチュエータ装置から構成される仮の生活空間（例えば、民泊・ホテル）等に仮泊した場合や仮の生活空間で移動する場合においても、抽象化された健康状態情報を持ち運ぶことで、その場に存在するアクチュエータ装置により健康サポートを行うことができる。すなわち、センシング装置からのセンシングデータに基づいた抽象化された健康状態をもとに、アクチュエータ装置に健康サポートをさせることで、それら装置による制御の汎用性・可搬性が付与される。
（３）上記（１）と（２）により、居住者（ユーザ）は、意識することなく、生活空間の場所・様式によらず、常に健康サポートを受けることが可能となる。

以下、健康状態の抽象化およびそれに基づくアクチュエータ装置等の動作の例について幾つかの実施例を用いて説明する。

次に、センサを有する便器を備えるトイレでユーザのお腹の調子を判定する例を説明する。

ここで、自宅１００のトイレ１４０ａはセンサ付き便器を備え、便座の昇降状態を検知するセンサ、便座にユーザの体重を測定する重量センサ、便器内に落ちた物質の重量を測定するセンサ、および便器内の水の汚れを測定する水汚れセンサを内蔵しており、各種センサの測定結果を組み合わせて排泄状態およびユーザの体調を判定する構成である。ホテル２００のトイレ２４０ａは、トイレ１４０ａの重量センサ、水汚れセンサが省略された、センサの少ない下位機種の便器を備える。民泊居住３００のトイレ３４０ａは、トイレ１４０ａのセンサに加え、匂いセンサや感音センサを内蔵した上位機種の便器を備える。以下、トイレ１４０ａ，２４０ａ，３４０ａを区別する必要がない場合は単にトイレという。

お腹の調子による装置制御処理の概要について図１０を用いて説明する。図１０はお腹の調子による装置制御処理のフローチャートである。お腹の調子による装置制御処理は以下のステップを有する。

ステップＳ２１０ではセンシング装置１４０によるセンシングデータの取得、例えばトイレ１４０ａは内蔵されるセンサによるデータ取得処理を行う。

ステップＳ２２０ではセンシングデータの解析・抽象化、例えばトイレ１４０ａはお腹の調子レベル判定処理（抽象化）を行う。

ステップＳ２３０では抽象化データによるアクチュエータ装置等制御、例えばアクチュエータ装置１２０またはバイ・ファンクション装置１３０の制御処理を行う。

（データ取得処理）
トイレの内蔵センサによるデータ取得処理（ステップＳ２１０）について図１１、１２を用いて説明する。図１１はトイレによるデータ取得処理を示すフローチャートである。図１２はトイレ１４０ａによるセンシングデータの取り得る組合せを表で表す図である。

まず、トイレはユーザがトイレに入るかどうかを判断し（ステップＳ２１１）、ユーザがトイレに入ると、使用時間計測を行うためタイマをスタートさせる（ステップＳ２１２）。トイレは洗浄レバーが未操作かどうかを判断し（ステップＳ２１８）、ユーザが洗浄レバーを操作すると排泄終了と認識し、タイマを止め使用時間を記録する（ステップＳ２１Ａ）。使用時間は入室および退室時刻から算出してもよい。タイマスタートと同時に各種センサは初期値を測定し記録する（ステップＳ２１３）。その後は逐次センサ測定を行い（ステップＳ２１９）、洗浄レバー操作まで排泄内容のモニタリングを行う。

トイレは、便座が上がっている状態（ステップＳ２１４でＮＯ）で洗浄レバーが操作された場合（ステップＳ２１８でＮＯの場合）、各センシングデータの格納処理を行い（ステップＳ２１Ｂ）、水の汚れセンサの初期値とモニタリング時の値を比較し、少量の汚れ（濁り）を検知したならば、男性が小便を行ったと判断する。なお、トイレ２４０ａは水の汚れセンサを備えていないが、汚れを検知しなくても、普段の使用時間から排泄を行ったと判断することができる。

トイレは、便座が下がっている状態（ステップＳ２１４でＹＥＳ）で、かつ便座への着座を検知すると（ステップＳ２１４でＹＥＳの場合）、各種センサは着座状態の排泄処理開始と認識し、再度初期値を測定する（ステップＳ２１７）。洗浄レバーが操作されると（ステップＳ２１８でＮＯの場合）排泄終了と判断し、各センシングデータの格納処理を行う（ステップＳ２１Ｂ）。トイレ１４０ａはセンシングデータを各種センサの初期値とモニタリング時の値を比較し、図１２に示すように、着座の有無、水濁りの状態、着座時間、排出までの時間、体重変化および水中重量変化として記憶装置１４６に格納する。

（抽象化処理）
お腹の調子の抽象化処理（お腹の調子レベル判定処理）（ステップＳ２２０）について図１３Ａ、１３Ｂ、１４〜２０を用いて説明する。図１３Ａ、１３Ｂはお腹の調子の抽象化処理のフローチャートである。図１４はトイレ１４０ａのセンシングデータを中間データに変換するテーブルを示す図である。図１５はトイレ２４０ａのセンシングデータを中間データに変換するテーブルを示す図である。図１６はトイレ３４０ａのセンシングデータを中間データに変換するテーブルを示す図である。図１７は中間データを１日単位で積算した表を示す図である。図１８はお腹の体調を抽象化する条件を表にした図である。図１９はある期間において下痢を検出した場合のお腹の体調記録例を示す図である。図２０は図１９の下痢回数を折れ線グラフで表した図である。

トイレ使用毎の体調判定処理はお腹の調子の抽象化処理によって行う。トイレ１４０ａにおける処理を以下説明する。判定処理は、トイレ設備によりセンサ構成が異なるため例示のフローチャートの手順に限らない場合があるが、トイレ２４０ａおよびトイレ３４０ａも同様に処理する。また処理効率化のための処理削減、および高機能化のための処理追加を行ってもよく、判定処理は例示の限りではない。

トイレ１４０ａは使用されたかどうかを判断し（ステップＳ２２１）、使用された場合、ステップＳ２１０で取得したセンシングデータ（図１２）に基づいて中間データを生成する（ステップＳ２２２）。センシングデータを図１４の変換テーブルを用いて中間データに変換する処理を行う（ステップＳ２２２ａ）。各種センサの測定結果からユーザのお腹の調子を判断するには、トイレ使用毎の体調判定表である中間データ変換テーブル（図１４〜１６）を用いてデータと合致するものを選択する。センシングデータの組み合わせによりお腹の体調が平常か、下痢気味か、便秘気味かを判断する。

なお、図１５に示すように、トイレ２４０ａのセンサはトイレ１４０ａよりセンサが少ないため判定に使う項目が減る傾向にある。そのため測定結果に対し体調信頼度係数を乗じ、体調判定の精度を上げる工夫をする。図１６に示すように、トイレ３４０ａのセンサはトイレ１４０ａよりセンサが多いため、体調判断の精度が向上する。

体調判定表は例示の組み合わせに限らず、便器の搭載センサにより項目を変更したり、他の体調を追加したり、通信手段を用いた項目アップデートが行われてもよい。また体調判定表はお腹の調子を体調ポイントとして表し、下痢気味を＋１、便秘気味を−１として判定を行ったり、プログラムのフラグに割り当て判定を行ったりしてもよい。なお、体調ポイントで判断する場合、例えば０ポイント以外を体調異常として判断するが、個人の体質により常に０以外となることも考えられる。その場合、期間の制限は設けないが、長期間の累積データを持ち、これをユーザの体調判断の基準データとし、１日ごとの記録との剥離から体調判断を行ってもよい。さらに体調判定表を用意せず、日々の使用状況から使用者の体調を類推するシステムであってもよい。

次に、トイレ１４０ａは所定期間（例えば１日）が経過したかどうかを判断し（ステップＳ２２２ｂ）、所定期間が経過していない場合、排便回数や下痢回数、便秘回数の積算を行う（ステップＳ２２２ｃ）。所定期間が経過した場合は、図１７に示すように、お腹の体調履歴に記録する（ステップＳ２２２ｄ）。図１７の表には各体調データの判断頻度が履歴として記録される。例えば、破線Ａで囲った箇所は、ステップＳ２２２ｃで積算される１日の排便情報であり、破線Ｂで囲った箇所は１日の排便状況の積算回数（中間データの積算）である。

次に、トイレ１４０ａは、図１８に示すような中間データの抽象化条件に基づいて抽象化データを生成する。図１８は履歴の体調頻度がある条件にあてはまる場合に抽象化データとして体調を確定させるためのものである。判定日数などの期間は症状や個人差に合わせて変更可能である。例えば、２日以上連続で下痢判定があるかどうかを判断し（ステップＳ２２３）、ＹＥＳの場合、直近１週間以上連続で下痢判定があるかどうかを判断しステップＳ２２４）、ＹＥＳの場合、抽象化データとして「下痢レベル２」を生成する（ステップＳ２２５ａ）。ステップＳ２２４でＮＯの場合、トイレ１４０ａは抽象化データとして「下痢レベル１」を生成する（ステップＳ２２５ｂ）。

ステップＳ２２３で、ＮＯの場合、２日以上連続で便秘判定があるかどうかを判断し（ステップＳ２２７）、ＹＥＳの場合、直近２週間のうち７日以上で便秘判定があるかどうかを判断し（ステップＳ２２８）、ＹＥＳの場合、抽象化データとして「便秘レベル２」を生成する（ステップＳ２２５ｃ）。ステップＳ２２８でＮＯの場合、トイレ１４０ａは抽象化データとして「便秘レベル１」を生成する（ステップＳ２２５ｄ）。ステップＳ２２７でＮＯの場合、トイレ１４０ａは抽象化データとして「平常」を生成する（ステップＳ２２５ｅ）。

図１９、２０に示すように、１０月５日までは下痢回数は０であり、快調であることを示している。一方で、１０月６日より下痢回数が１回になり下痢気味であることを示している。

体調に異常なしの期間は特に通知を行わないが、下痢回数が１回以上の日数が２日目となる（２日連続下痢が検出されて抽象化データが「下痢レベル１」になる）１０月７日にトイレはホームサーバ１１０に健康情報（抽象化データ）を送信する。抽象化データを受信したホームサーバ１１０はアクチュエータ装置１２０またはバイ・ファンクション装置１３０に健康情報や制御信号を送信する。この情報送信は中間データの平常が２日以上継続（抽象化データは「平常」）になる１０月１１日まで続き、アクチュエータ装置１２０またはバイ・ファンクション装置１３０はユーザの体調に合わせ、少しでも快適に過ごせるよう各自の制御を行ったり、体調を戻すため食事や行動の提案をユーザに対し行ったりする。

本実施例は１日ごとの記録より体調判定を行っているが、例えば１時間ごとのトイレ使用状況を用いて、使用回数が増加したら体調変化の予兆など、体調変化の予測を行いユーザに対し早期の通知を行う使い方をしてもよい。

（アクチュエータ装置等の制御処理）
図２１は自宅のアクチュエータ装置等の動作を示すフローチャートである。
アクチュエータ装置１２０がホームサーバ１１０より抽象化データを受信すると、健康状態の分類およびそのレベルから最適な処理を選択し制御する。この処理はバイ・ファンクション装置１３０も同様に適用される。また、アクチュエータ装置２２０およびバイ・ファンクション装置２３０が端末２１０より抽象化データを受信しても同様の処理を行い、アクチュエータ装置３２０およびバイ・ファンクション装置３３０がホームサーバ３１０より抽象化データを受信しても同様の処理を行う。

アクチュエータ装置１２０は受信処理を行い（ステップＳ２３１）、受信した健康情報（抽象化データ）がお腹、風邪、ストレス等の分類を判定する（ステップＳ２３２）。お腹の場合、健康情報（抽象化データ）のレベル判定を行う（ステップＳ２３３）。「平常」の場合、下記の平常時の処理を行い（ステップＳ２３４ａ）、「下痢レベル１」の場合、下記の下痢レベル１の処理を行い（ステップＳ２３４ｂ）、「下痢レベル２」の場合、下記の下痢レベル２の処理を行い（ステップＳ２３４ｃ）、「便秘レベル１」の場合、下記の便秘レベル１の処理を行い（ステップＳ２３４ｄ）、「便秘レベル２」の場合、下記の便秘レベル２の処理を行う（ステップＳ２３４ｅ）。

なお、ステップ２３１〜Ｓ２３３をホームサーバ１１０で行い、ステップＳ２３４ａ〜Ｓ２３４ｅをアクチュエータ装置１２０またはバイ・ファンクション装置１３０で行ってもよい。

ステップＳ２３４ａの平常時の処理は、例えば、エアコン１３０ａは平常時の運転を行う。冷蔵庫１２０ｅは音声ガイダンスで例えば「庫内の材料で作れるメニューを考えます。」と提案する。洗面台１３０ｂの前に立つと、洗面台１３０ｂは音声ガイダンスにより例えば「今日も快調ですね。」と告げる。また、洗面台１３０ｂは内蔵ディスプレイ上に健康体シンボルを表示する。

ステップＳ２３４ｂの下痢レベル１の処理は、例えば、エアコン１３０ａはお腹が冷えないよう設定温度を１℃上げる。冷蔵庫１２０ｅは音声ガイダンスで例えば「お腹の調子が悪いですか？スポーツドリンクで水分補給しましょう。」と提案する。洗面台１３０ｂの前に立つと、洗面台１３０ｂは音声ガイダンスにより下痢気味であることを例えば「お腹が下り気味です。水分補給と消化に良い食事をしましょう。」と告げ、体調改善に向けたアドバイスを提案する。また、洗面台１３０ｂは内蔵ディスプレイ上に身体シンボルを表示し、身体シンボルのお腹の部分を点滅等により強調表示することで、一目で体調不良を確認できるようにする。

ステップＳ２３４ｃの下痢レベル２の処理は、例えば、エアコン１３０ａは下痢レベル１と同じ動作をする。冷蔵庫１２０ｅは音声ガイダンスで例えば「お腹の調子が悪いですね。消化によいメニューを考えます。」と提案する。洗面台１３０ｂの前に立つと、洗面台１３０ｂは音声ガイダンスにより下痢気味であることを例えば「下痢が長引いています。お医者さんへ相談も考えましょう。」と告げる。また、洗面台１３０ｂは内蔵ディスプレイ上に身体シンボルを表示し、身体シンボルのお腹の部分を点滅等により強調表示する。

ステップＳ２３４ｄの便秘レベル１の処理は、例えば、エアコン１３０ａは足の冷えによる便秘解消、または悪化を防ぐためルーバーを下方向に向け、足元を温めるよう動作する。冷蔵庫１２０ｅはお腹の張りがある場合は野菜や果物のように食物繊維を摂取できる食材を音声ガイダンスで例えば「お腹が張っていますか？野菜や果物を多めに取りましょう。」と提案する。洗面台１３０ｂの前に立つと、洗面台１３０ｂは音声ガイダンスにより便秘気味であることを例えば「便秘気味ですね。水分補給と食物繊維を含む食事をしましょう。」と告げ、体調改善に向けたアドバイスを提案する。また、洗面台１３０ｂは「長時間踏ん張ると痔になります。」と音声ガイダンで注意を促す。また、洗面台１３０ｂは内蔵ディスプレイ上に身体シンボルを表示し、お腹の部分を点滅等により強調表示することで、一目で体調不良を確認できるようにする。炊飯器１２０ｄは音声ガイダンスで「便秘ですか？おかゆは、どうでしょう。」と提案する。

ステップＳ２３４ｄの便秘レベル２の処理は、例えば、エアコン１３０ａは「便秘レベル１」の動作に加え、設定温度を１℃上げる。冷蔵庫１２０ｅは音声ガイダンスで例えば「お腹が張っていますね。食物繊維が取れるメニューを考えます。」と提案する。洗面台１３０ｂの前に立つと、洗面台１３０ｂは音声ガイダンスにより例えば「便秘が長引いています。お医者さんへ相談も考えましょう。」と告げる。また、洗面台１３０ｂは、「便秘レベル１」と同様に、内蔵ディスプレイ上に身体シンボルを表示し、お腹の部分を点滅等により強調表示する。

ホテル２００は自宅１００とは装置構成や装置機能が異なるため同じ体調の情報でも動作が異なる。例えば冷蔵庫２２０ｅには通常食材は用意されない。そのため、ホテル内の食堂やカフェでの食事を促す提案を行う。洗面台２３０ｂは表示機能がないので、洗面台１３０ｂと同様の音声ガイダンスのみを行う。なお、エアコン２３０ａはエアコン１３０ａと同様の機能であるので、エアコン１３０ａと同様の動作を行う。

例えば、ステップＳ２３４ａの平常の処理では、冷蔵庫２２０ｅは音声ガイダンスで「お食事は当ホテル食堂の本日のお勧め○○はいかがでしょうか。」と提案する。

ステップＳ２３４ｂの下痢レベル１の処理では、冷蔵庫２２０ｅは音声ガイダンスで「お腹の調子が悪いですか？スポーツドリンクで水分補給しましょう。当ホテルの売店は１Ｆロビー前にあります。」と提案する。

ステップＳ２３４ｃの下痢レベル２の処理では、冷蔵庫２２０ｅは音声ガイダンスで「お腹の調子が悪いですね。お食事は消化に良い△△を当ホテル食堂にてご用意しています。」と告げる。

ステップＳ２３４ｄの便秘レベル１の処理は、「お腹が張っていますか？野菜や果物を多めに取りましょう。当ホテルカフェにて軽食をご用意しています。」と提案する。

ステップＳ２３４ｅの便秘レベル２の処理は、「お腹が張っていますね。お食事はお通じを促すのに良い××を当ホテル食堂にてご用意しています。」と告げる。

風邪判定の例を図２２〜３７を用いて説明する。図２２は風邪判定の概要を示すフローチャートである。

本例は居住者であるユーザの体温、発声内容（閉鼻音、咳、くしゃみ、鼻啜音、こう
鼻音）、および動作（くしゃみ、こう鼻動作）をセンシングおよび信号処理（ステップＳ３１０〜Ｓ３３０）により、平常時と風邪をひいたときの違いを検知し風邪と判断する処理の例である。

（体温から風邪を判定する方法）
（１）ユーザ体温の測定
ユーザの体温は、センシング装置１４０またはバイ・ファンクション装置１３０に内蔵される温度センサなどで測定を行う。装置はユーザの体温変動を継続的かつ定期的に記録し、図２３に示すようなユーザ体温変動の履歴を蓄積する。図２３では半日毎に体温を記録しているが、より精密に体温変動を検知するため測定間隔を短くしたりしてもよい。またこの体温変動の履歴より、事前にユーザの平熱が算出されているものとする。
（２）ユーザ体温を風邪レベルに変換
図２４は発熱風邪判定表を示す図である。図２５は発熱風邪検知処理のフローチャートである。

センシング装置１４０またはバイ・ファンクション装置１３０は体温測定後、検知タイマをスタートさせて（ステップＳ３１１）、検知タイマをカウントアップする（ステップＳ３１２）。検知タイマが設定周期になったかどうか判断し、ＹＥＳの場合は検知タイマをリセットする（ステップＳ３１４）。定期的にユーザ体温を検知して、設定された周期が経過すると、その都度風邪判定を行う（ステップＳ３１５）。本例では体温上昇量（ユーザの最新の体温測定値と平熱情報の差分）から、図２４に示すように、５段階の抽象化された風邪判定（抽象化データ）に分類する。

風邪判定０は測定された体温が平熱に対し０〜０．３℃高い状態であり、ステップＳ３１５で風邪判定０と判定された場合、風邪レベル０の処理を行う（ステップＳ３１６ａ）。

風邪判定１は測定された体温が平熱に対し０．４〜０．６℃高い状態であり、ステップＳ３１５で風邪判定１と判定された場合、風邪レベル１の処理を行う（ステップＳ３１６ｂ）。

風邪判定２は測定された体温が平熱に対し０．７〜１．０℃高い状態であり、ステップＳ３１５で風邪判定２と判定された場合、風邪レベル２の処理を行う（ステップＳ３１６ｃ）。

風邪判定３は測定された体温が平熱に対し１．１〜１．９℃高い状態であり、ステップＳ３１５で風邪判定３と判定された場合、風邪レベル３の処理を行う（ステップＳ３１６ｄ）。

風邪判定４は測定された体温が平熱に対し２．０℃以上高い状態であり、ステップＳ３１５で風邪判定４と判定された場合、風邪レベル４の処理を行う（ステップＳ３１６ｅ）。

図２５のユーザ体温変化は、図２７に示すように、１０月３１日の２回目は風邪判定２、１１月１日の１回目は風邪判定３、１１月１日の２回目は風邪判定２と、判定される。

体温履歴を更新し（ステップＳ３１７）、ステップＳ３１２に戻る。

健康状態の分類は、体温の絶対温度を閾値とし、健康状態を分類する方法でもよい。また、運動や入浴、過剰な空調などによる一時的な体温上昇も考えられる。これらと区別するために、１時間以上継続して体温上昇量が維持された場合に発熱風邪判定に移行し、１時間以内に平温に戻った場合は、風邪判定０（健康）と判定するような処理を追加してもよい。

（発声から風邪を判定する方法）
発声から風邪を判定する方法には、例えば閉鼻声による風邪判定、咳による風邪判定、くしゃみ、鼻啜音およびこう鼻音による鼻風邪判定がある。

［閉鼻声による風邪判定］
まず、閉鼻声による風邪判定について図２６Ａ、２６Ｂ、２７、２８を用いて説明する。図２６Ａはユーザの開鼻声スペクトラム履歴を示す図であり、図２６Ｂは閉鼻声スペクトラム履歴を示す図である。図２７は閉鼻声風邪判定表の一例を示す図である。図２８は閉鼻声風邪検知処理のフローチャートである。

センシング装置１４０に内蔵されるマイクを用い、図２６Ａに示すようなユーザの通常時の音声（開鼻声）スペクトラム履歴を保存し、風邪により変化した鼻声（閉鼻声）の程度を、図２６Ｂに示すようなユーザ音声スペクトラムの部分的な周波数帯域（ＦＢ）のレベルの変化量（Ｌｃ−Ｌｏ）から数値化し、鼻水、鼻づまりによる風邪の症状のレベルを抽象化データとする閉鼻声風邪判定を行う。閉鼻声のレベル（Ｌｃ）は開鼻声のレベル（Ｌｏ）よりも大きい。

センシング装置１４０またはバイ・ファンクション装置１３０は音声スペクトラム測定後、検知タイマをスタートさせて（ステップＳ３１１）、検知タイマをカウントアップする（ステップＳ３１２）。検知タイマが設定周期になったかどうか判断し（ステップＳ３１３）、ＹＥＳの場合は検知タイマをリセットする（ステップＳ３１４）。所定期間が経過すると、閉鼻声検知による風邪の判定を行う（ステップＳ３２５）。本例では音声スペクトラムの閉鼻声周波数帯のレベル変化量（閉鼻声のレベルと開鼻声のレベルの差分）から、図２７に示すように、５段階の抽象化された風邪判定に分類する。

風邪判定０は測定された閉鼻声のレベルが通常の開鼻声に対し０％以上１％未満高い状態であり、ステップＳ３２５で風邪判定０と判定された場合、風邪レベル０の処理を行う（ステップＳ３１６ａ）。

風邪判定１は測定された閉鼻声のレベルが通常の開鼻声に対し１％以上２％未満高い状態であり、ステップＳ３２５で風邪判定１と判定された場合、風邪レベル１の処理を行う（ステップＳ３１６ｂ）。

風邪判定２は測定された閉鼻声のレベルが通常の開鼻声に対し２％以上３％未満高い状態であり、ステップＳ３２５で風邪判定２と判定された場合、風邪レベル２の処理を行う（ステップＳ３１６ｃ）。

風邪判定３は測定された閉鼻声のレベルが通常の開鼻声に対し３％以上４％未満高い状態であり、ステップＳ３２５で風邪判定３と判定された場合、風邪レベル３の処理を行う（ステップＳ３１６ｄ）。

風邪判定４は測定された閉鼻声のレベルが通常の開鼻声に対し４％以上高い状態であり、ステップＳ３２５で風邪判定４と判定された場合、風邪レベル４の処理を行う（ステップＳ３１６ｅ）。

図２７に示すように、１０月３１日の２回目は風邪判定１、１１月１日の１回目は風邪判定２、１１月１日の２回目は風邪判定１と、判定される。

音声スペクトラム履歴を更新し（ステップＳ３２７）、ステップＳ３１２に戻る。

［咳による風邪判定］
次に、咳による風邪判定について図２９〜３１を用いて説明する。図２９はユーザの咳の音声波形パターンを示す図である。図３０は咳回数風邪判定表の一例を示す図である。図３１は咳回数風邪検知処理のフローチャートである。

センシング装置１４０に内蔵されるマイクを用い図２９に示すようなユーザの咳の音声波形パターンを検知し、その咳の回数の履歴を保存する。通常時その咳の回数との変化量から風邪の症状のレベルを抽象化データとする、咳回数風邪判定を行う。

センシング装置１４０またはバイ・ファンクション装置１３０は音声波形パターン測定後、検知タイマをスタートさせて（ステップＳ３１１）、検知タイマをカウントアップする（ステップＳ３１２）。検知タイマが設定周期になったかどうか判断し（ステップＳ３１３）、ＹＥＳの場合は検知タイマをリセットする（ステップＳ３１４）。所定期間が経過すると、咳による風邪の判定を行う（ステップＳ３３５、Ｓ３３６）。本例では音声波形パターンから咳を検知し（ステップＳ３３５）、その回数を咳回数風邪検知カウンタで累積し、測定された咳回数と通常時の咳の回数との差分から、図３０に示すように、５段階の抽象化された風邪判定に分類する（ステップＳ３３６）。

風邪判定０は測定された咳回数が通常時の咳回数に対し０回以上１０回未満多い状態であり、ステップＳ３３６で風邪判定０と判定された場合、風邪レベル０の処理を行う（ステップＳ３１６ａ）。

風邪判定１は測定された咳回数が通常時の咳回数に対し１０回以上２０回未満多い状態であり、ステップＳ３３６で風邪判定１と判定された場合、風邪レベル１の処理を行う（ステップＳ３１６ｂ）。

風邪判定２は測定された咳回数が通常時の咳回数に対し２０回以上３０回未満多い状態であり、ステップＳ３３６で風邪判定２と判定された場合、風邪レベル２の処理を行う（ステップＳ３１６ｃ）。

風邪判定３は測定された咳回数が通常時の咳回数に対し３０回以上４０回未満多い状態であり、ステップＳ３３６で風邪判定３と判定された場合、風邪レベル３の処理を行う（ステップＳ３１６ｄ）。

風邪判定４は測定された咳回数が通常時の咳回数に対し４１回以上多い状態であり、ステップＳ３３６で風邪判定４と判定された場合、風邪レベル４の判定処理を行う（ステップＳ３１６ｅ）。図３０に示すように、１０月３１日の２回目は風邪判定１、１１月１日の１回目は風邪判定２、１１月１日の２回目は風邪判定１と、判定される。

咳回数風邪検知カウンタの履歴を更新し（ステップＳ３３７）、ステップＳ３１２に戻る。

［鼻風邪判定］
次に、くしゃみ、鼻啜音およびこう鼻音による鼻風邪判定について図３２〜３４を用いて説明する。図３２はユーザのくしゃみの音声波形パターンを示す図である。図３３は鼻風邪音声回数判定表の一例を示す図である。図３４は鼻風邪音声回数検知処理のフローチャートである。

センシング装置１４０に内蔵されるマイクを用い図３２に示すようなユーザのくしゃみの音声波形パターンを検知し、その回数の履歴を保存する。同様にユーザの鼻啜音（鼻を啜る音）やこう鼻音（鼻をかむ音）の回数の履歴を保存し、通常時との変化量から風邪の症状のレベルを抽象化データとする、鼻風邪音声回数判定を行う。くしゃみ、鼻啜音およびこう鼻音の回数を鼻風邪音声回数という。

センシング装置１４０またはバイ・ファンクション装置１３０は音声波形パターン測定後、検知タイマをスタートさせて（ステップＳ３１１）、検知タイマをカウントアップする（ステップＳ３１２）。検知タイマが設定周期になったかどうか判断し（ステップＳ３１３）、ＹＥＳの場合は検知タイマをリセットする（ステップＳ３１４）。所定期間が経過すると、音声波形パターンによる風邪の判定を行う（ステップＳ３４５〜Ｓ３４７）。本例では音声波形パターンからくしゃみを検知し（ステップＳ３４５）、または鼻啜音を検知し（ステップＳ３４６）、またはこう鼻音を検知（ステップＳ３４７）する。その回数を鼻風邪検知カウンタで累積し、測定されたくしゃみの回数と通常時のくしゃみの回数との差分、または測定された鼻啜音の回数と通常時の鼻啜音の回数との差分、または測定されたこう鼻音の回数と通常時のこう鼻音の回数との差分から、図３３に示すように、５段階の抽象化された風邪判定に分類する（ステップＳ３４８）。

風邪判定０は測定された鼻風邪音声回数が通常時の鼻風邪音声回数に対し０回以上１０回未満多い状態であり、ステップＳ３４８で風邪判定０と判定された場合、風邪レベル０の処理を行う（ステップＳ３１６ａ）。

風邪判定１は測定された鼻風邪音声回数が通常時の鼻風邪音声回数に対し１０回以上２０回未満多い状態であり、ステップＳ３４８で風邪判定１と判定された場合、風邪レベル１の処理を行う（ステップＳ３１６ｂ）。

風邪判定２は測定された鼻風邪音声回数が通常時の鼻風邪音声回数に対し２０回以上３０回未満多い状態であり、ステップＳ３４８で風邪判定２と判定された場合、風邪レベル２の処理を行う（ステップＳ３１６ｃ）。

風邪判定３は測定された鼻風邪音声回数が通常時の鼻風邪音声回数に対し３０回以上４０回未満多い状態であり、ステップＳ３４８で風邪判定３と判定された場合、風邪レベル３の処理を行う（ステップＳ３１６ｄ）。

風邪判定４は測定された鼻風邪音声回数が通常時の鼻風邪音声回数に対し４１回以上多い状態であり、ステップＳ３４８で風邪判定４と判定された場合、風邪レベル４の処理を行う（ステップＳ３１６ｅ）。

図３３に示すように、１０月３１日の２回目は風邪判定１、１１月１日の１回目は風邪判定２、１１月１日の２回目は風邪判定１と、判定される。

鼻風邪検知カウンタの履歴を更新し（ステップＳ３４９）、ステップＳ３１２に戻る。

（動作から風邪を判定する方法）
鼻風邪に伴う動作による風邪判定について図３５〜３７を用いて説明する。図３５はユーザのくしゃみ動作パターンを示す図である。図３６は鼻風邪動作回数判定表の一例を示す図である。図３７は鼻風邪動作回数検知処理のフローチャートである。

センシング装置１４０に内蔵されるムービカメラを用い図３５に示すようなユーザのくしゃみ動作パターンを検知し、その回数の履歴を保存する。同様にユーザのこう鼻動作（鼻をかむ動作）の回数の履歴を保存し、通常時との変化量から風邪の症状のレベルを抽象データとする、鼻風邪動作回数判定を行う。

センシング装置１４０またはバイ・ファンクション装置１３０は鼻風邪動作測定後、検知タイマをスタートさせて（ステップＳ３１１）、検知タイマをカウントアップする（ステップＳ３１２）。検知タイマが設定周期になったかどうか判断し（ステップＳ３１３）、ＹＥＳの場合は検知タイマをリセットする（ステップＳ３１４）。所定期間が経過すると、鼻風邪動作による風邪の判定を行う（ステップＳ３５５〜Ｓ３５７）。本例ではユーザの動作からくしゃみ動作を検知し（ステップＳ３５５）、またはこう鼻動作を検知し（ステップＳ３５６）、その回数を鼻風邪動作検知カウンタで累積し、測定されたくしゃみ動作の回数と通常時のくしゃみ動作の回数との差分、または測定されたこう鼻動作の回数と通常時のこう鼻動作の回数との差分から、図３６に示すように、５段階の抽象化された風邪判定に分類する（ステップＳ３５７）。

風邪判定０は測定された鼻風邪動作回数が通常時の鼻風邪動作回数に対し０回以上１０回未満多い状態であり、ステップＳ３５７で風邪判定０と判定された場合、風邪レベル０の処理を行う（ステップＳ３１６ａ）。

風邪判定１は測定された鼻風邪動作回数が通常時の鼻風邪音声回数に対し１０回以上２０回未満多い状態であり、ステップＳ３５７で風邪判定１と判定された場合、風邪レベル１の処理を行う（ステップＳ３１６ｂ）。

風邪判定２は測定された鼻風邪動作回数が通常時の鼻風邪動作回数に対し２０回以上３０回未満多い状態であり、ステップＳ３５７で風邪判定２と判定された場合、風邪レベル２の処理を行う（ステップＳ３１６ｃ）。

風邪判定３は測定された鼻風邪動作回数が通常時の鼻風邪動作回数に対し３０回以上４０回未満多い状態であり、ステップＳ３５７で風邪判定３と判定された場合、風邪レベル３の処理を行う（ステップＳ３１６ｄ）。

風邪判定４は測定された鼻風邪動作回数が通常時の鼻風邪動作回数に対し４１回以上多い状態であり、ステップＳ３５７で風邪判定４と判定された場合、風邪レベル４の処理を行う（ステップＳ３１６ｅ）。

図３６に示すように、１０月３１日の２回目は風邪判定１、１１月１日の１回目は風邪判定２、１１月１日の２回目は風邪判定１と、判定される。

鼻風邪動作検知カウンタの履歴を更新し（ステップＳ３５８）、ステップＳ３１２に戻る。

［総合判定］
ただし、鼻風邪音声回数判定や鼻風邪動作回数判定は花粉症やアレルギー性鼻炎など風邪以外の症状に対して風邪判定をしてしまう可能性があるため、発熱風邪判定や咳回数風邪判定などと併用することが望ましい。図３８は各センシング結果から導出した風邪レベルから抽象化データを総合判定する例である。

風邪判定の抽象化データは、閉鼻声風邪判定レベルや咳回数風邪判定レベル、鼻風邪回数判定レベルなどの複数の情報により総合判定する。図３８に示すように、各風邪症状により判定した風邪レベルは、体温風邪判定では風邪レベル１、咳回数風邪判定では風邪レベル２、閉鼻声風邪判定では風邪レベル４、鼻啜音回数風邪判定で風邪レベル２、と異なるが、ユーザの体調不良を見逃さないという観点で判定した場合、総合判断は風邪レベル４が選択される。ここで、風邪レベル０は健康、風邪レベル１および風邪レベル２は風邪気味、風邪レベル３および風邪レベル４は風邪とする。

総合判定は各風邪症状により判定した風邪レベルに重みづけをする、またはレベルの平均値をとるなど手法は問わず、抽象化データが出力されるものである。総合判定することにより、自宅１００で使用しているバイ・ファンクション装置１３０、例えば温度センサまたはサーモグラフィを備える装置が旅行先のホテル２００に無い場合でもセンシング装置２４０からの情報を使用するなど相互補完をしながら風邪判定を継続することが出来る。

（アクチュエータ装置等の動作）
風邪判定の抽象化データが確定されると、アクチュエータ装置１２０またはバイ・ファンクション装置１３０はユーザに対して風邪判定抽象データに応じた動作をする。例えば、バイ・ファンクション装置１３０は風邪を引いているユーザに対して空調設定温度や設定湿度を高くしたり、設定を変更する提案をしたりすることができる。

アクチュエータ装置１２０およびバイ・ファンクション装置１３０の風邪判定レベル毎の動作（ステップＳ３１６ａ〜Ｓ３１６ｅ）の一例を以下に説明する。

ステップＳ３１６ａの風邪レベル０の処理では、例えば、エアコン１３０ａは通常温度設定に従って動作し、加湿器除湿器は通常湿度設定に従って動作する。

ステップＳ１６ｂの風邪レベル１の処理では、例えば、エアコン１３０ａは通常温度設定より１℃高い温度に設定され、加湿器除湿器は通常湿度設定より１％高い湿度に設定される。洗面台１３０ｂは、音声ガイダンスで例えば「食事の前に手を洗いましょう。」と提案する。

ステップＳ３１６ｃの風邪レベル２の処理では、例えば、エアコン１３０ａは通常温度設定より２℃高い温度に設定され、加湿器除湿器は通常湿度設定より２％高い湿度に設定される。冷蔵庫１２０ｅは音声ガイダンスで、例えば「暖かいスープはどうですか？」と提案する。炊飯器１２０ｄは音声ガイダンスで、例えば「消化の良いお粥はいかがでしょうか？」と提案する。洗面台１３０ｂは音声ガイダンスで、例えば「食事の前に手を洗いましょう。」と提案する。電子レンジ１２０ｃは音声ガイダンスで、例えば「電子レンジで蒸しタオルが作れますよ？」と提案する。

ステップＳ３１６ｄの風邪レベル３の処理では、例えば、エアコン１３０ａは通常温度設定より３℃高い温度に設定され、加湿器除湿器は通常湿度設定より３％高い湿度に設定される。冷蔵庫１２０ｅは音声ガイダンスで、例えば「野菜たっぷりのお鍋はどうですか？」と提案する。炊飯器１２０ｄは音声ガイダンスで、例えば「消化の良いお粥はいかがでしょうか？」と提案する。洗面台１３０ｂは音声ガイダンスで、例えば「手洗い、うがいをしましょう。」と提案する。電子レンジ１２０ｃは音声ガイダンスで、例えば「電子レンジで蒸しタオルが作れますよ？」と提案する。

ステップＳ３１６ｅの風邪レベル４の処理では、例えば、エアコン１３０ａは通常温度設定より５℃高い温度に設定され、加湿器除湿器は通常湿度設定より５％高い湿度に設定される。冷蔵庫１２０ｅは音声ガイダンスで、例えば「身体が温まる辛いお鍋はどうですか？」と提案する。炊飯器１２０ｄは音声ガイダンスで、例えば「お鍋の最後に雑炊はいかがですか？」と提案する。洗面台１３０ｂは音声ガイダンスで、例えば「手洗い、うがいをしましょう。」と提案する。電子レンジ１２０ｃは音声ガイダンスで、例えば「電子レンジで卵酒が作れますよ？」と提案する。

また、外環境が異なる環境へ移動した場合のアクチュエータ装置２２０およびバイ・ファンクション装置１３０の動作例を以下に説明する。温暖地域から寒冷地に外出（健康情報データベース１１１を移動）した場合、移動先の地域に応じた追加制御が適用される。

風邪レベル０の処理では、例えば、エアコン１３０ａは通常温度設定に従って動作し、加湿器除湿器は通常湿度設定に従って動作するが、エアコン２３０ａは温度設定をエアコン１３０ａよりも２℃高くし、ホテル２００の加湿器除湿器は湿度設定を自宅の加湿器除湿器の湿度設定より５％高く設定する。冷蔵庫２２０ｅは庫内温度を弱に設定する。

風邪レベル１の処理では、例えば、エアコン１３０ａは通常温度設定より１℃高い温度に設定され、加湿器除湿器は通常湿度設定より１％高い湿度に設定されるが、エアコン２３０ａは温度設定をエアコン１３０ａよりも２℃高くし、ホテル２００の加湿器除湿器は湿度設定を自宅の加湿器除湿器の湿度設定より５％高く設定する。冷蔵庫２２０ｅは庫内温度を弱に設定する。

風邪レベル２の処理では、例えば、エアコン１３０ａは通常温度設定より２℃高い温度に設定され、加湿器除湿器は通常湿度設定より２％高い湿度に設定されるが、エアコン２３０ａは温度設定をエアコン１３０ａよりも２℃高くし、ホテル２００の加湿器除湿器は湿度設定を自宅の加湿器除湿器の湿度設定より５％高く設定する。冷蔵庫１２０ｅは音声ガイダンスで「暖かいスープはどうですか？」と提案するが、冷蔵庫２２０ｅは庫内温度を弱に設定する。

風邪レベル３の処理では、例えば、エアコン１３０ａは通常温度設定より３℃高い温度に設定され、加湿器除湿器は通常湿度設定より３％高い湿度に設定されるが、エアコン２３０ａは温度設定をエアコン１３０ａよりも２℃高くし、ホテル２００の加湿器除湿器は湿度設定を自宅の加湿器除湿器の湿度設定より５％高く設定する。冷蔵庫１２０ｅは音声ガイダンスで「野菜たっぷりのお鍋はどうですか？」と提案するが、冷蔵庫２２０ｅは庫内温度を弱に設定する。

風邪レベル４の処理では、例えば、エアコン１３０ａは通常温度設定より５℃高い温度に設定され、加湿器除湿器は通常湿度設定より５％高い湿度に設定されるが、エアコン２３０ａは温度設定をエアコン１３０ａよりも２℃高くし、ホテル２００の加湿器除湿器は湿度設定を自宅の加湿器除湿器の湿度設定より５％高く設定する。冷蔵庫１２０ｅは音声ガイダンスで「身体が温まる辛いお鍋はどうですか？」と提案するが、冷蔵庫２２０ｅは庫内温度を弱に設定する。

居住者のストレス軽減に向けた健康サポートを行う例について図３９〜４１を用いて説明する。図３９はストレスレベル抽象化の処理を示すフローチャートである。図４０はセンシングデータから抽象化の中間データを抽出するテーブルである。図４１はストレス判定テーブルの一例を示す図である。

センシング装置１４０およびバイ・ファンクション装置１３０は、音声による感情認識情報、カメラの顔認識による感情認識情報、脈拍数、行動量情報、肩こりの情報など、居住者のストレスレベルを判定するための情報を、ホームサーバ１１０に送信する。

まず、自宅１００に存在するセンシング装置１４０およびバイ・ファンクション装置１３０からセンシング可能なストレス情報を抽出し、図４０に示すようなセンシングデータ（「眉間のしわ数」、「脈拍」、「心拍」、「歩数」）を蓄積する（ステップＳ４１１）。図４０の「抽象化のための中間データ」に示すようなストレス状態（「感情」、「通常時の脈拍変動」、「熟睡度（睡眠時の脈拍変動）」、「行動」、「肩こり」）を抽出するテーブルを設定し（ステップＳ４０１）、格納する（ステップＳ４０１）。抽象化のための中間データの「感情」は、例えば「眉間のしわ数」等により「幸福が多い」、「平常が多い」、「怒り多い」に分類される。「通常時の脈拍変動」は、例えば「脈拍」により「１０％未満」、「２０％未満」、「２０％以上」に分類される。「熟睡度（睡眠時の脈拍変動）」は、例えば「心拍」により「５未満」、「１０未満」、「１０以上」に分類される。「行動」は、例えば「歩数」により「活発」、「普通」、「ほとんど動かない」に分類される。「肩こり」は、例えば「心拍」により「ほとんどない」、「少しある」、「非常にある」に分類される。

次にホームサーバ１１０は、センシング装置１４０およびバイ・ファンクション装置１３０から受信したストレス情報を、図４０に示すような予め設定したストレス抽出テーブルに基づいて居住者のストレス状態を数値化（点数化）する（ステップＳ４１２）。図４１に示すような予め蓄積された（ステップＳ４０３）ストレス判定テーブル（点数と抽象化データの関係）に基づいてストレス状態を抽象化し（ステップＳ４１３）、抽象化したストレス情報（抽象化データ）を蓄積する（ステップＳ４１４）。本実施例では高ストレス、中ストレス、ストレスなしの３段階に抽象化している。高ストレスの状態が長期間継続する場合に超高ストレスレベルを増やす等も可能である。

次に、ホームサーバ１１０は抽象化データをアクチュエータ装置１２０およびバイ・ファンクション装置１３０へ送信する。アクチュエータ装置１２０およびバイ・ファンクション装置１３０（例えば、ＴＶ１２０ｂ、ＣＤプレーヤ、冷蔵庫１２０ｅ、洗面台１３０ｂ、照明１２０ａ、風呂１２０ｆ等）の各装置は、それぞれが受信した抽象化データに基づいて、居住者に対してストレス軽減に向けた健康サポートを提供する。アクチュエータ装置１２０およびバイ・ファンクション装置１３０の動作例を以下に説明する。

抽象化データが「ストレスなし」の場合、洗面台１３０ｄは、例えば「おはよう！今日も一日元気に頑張ろう！」と告げる。

「中ストレス」の場合、ＴＶ１２０ｂは、例えば、ストレス発散に効果的な運動、お勧めの趣味、ストレス解消グッズ情報を提供する。ＣＤプレーヤは、例えば、睡眠時にリラックスしやすい音楽を流したり、起床時にさわやかな朝をイメージした音楽を流したりする。冷蔵庫１２０ｅは、例えば、ストレスに効果的な食材（ビタミンＢ群、ビタミンＣ等が豊富な食材）を使った献立を提案する。洗面台１３０ｄは、例えば「おはよう！少しストレスが溜まっているよ！あまり無理しないで！」と告げる。照明１２０ａは睡眠時、段階的に明るさを調整する。風呂１２０ｆは、お湯の温度を４０℃に設定し、最低１０分の入浴を音声ガイダンスで提案する。

「高ストレス」の場合、ＴＶ１２０ｂは、例えば、ストレス発散に効果的な運動、お勧めの趣味、ストレス解消グッズ情報、医療機関情報を提供する。ＣＤプレーヤは、例えば、睡眠時にリラックスしやすい音楽を流したり、起床時にさわやかな朝をイメージした音楽を流したり、癒しのＢＧＭを流したりする。冷蔵庫１２０ｅは、例えば、ストレスに効果的な食材（ビタミンＢ群、ビタミンＣ等が豊富な食材）を使った献立を提案したり、サプリメントの飲用を提案したりする。洗面台１３０ｄは、例えば「おはよう！だいぶストレスが溜まっているね！何でもひとりで抱え込まないで！」と告げる。照明１２０ａは睡眠時、段階的に明るさを調整する。風呂１２０ｆは、お湯の温度を４０℃に設定し、最低１０分の入浴を音声ガイダンスで提案する。

日常生活空間などで取得した抽象化データは、建物以外の非日常空間に設けられるアクチュエータ装置においても適用できる。移動手段に備えられたアクチュエータ装置の制御について図４２、４３を用いて説明する。図４２は自宅からタクシーを用いて外出する場合の健康情報データベース持ち出し例を説明する図である。図４３はアクチュエータ装置の一例であるエアクッションの構成を示す図である。

自宅１００のトイレ４４０ａは、トイレ１４０ａやトイレ２４０ａなどのセンサ内蔵便器に、さらに血液センサが追加された便器を備える。トイレ４４０ａには便秘や下痢のレベル判定機能の他に、血液センサによる痔のレベル判定機能が追加されている。トイレ４４０ａは排便時に血液成分を検出した場合、ユーザが痔を患っていると判断し、血液濃度により痔のレベルを判定し、抽象化データとして出力する機能を持つ。ホームサーバ１１０は痔のレベルを抽象化データとして健康情報データベース１１１に蓄積する。抽象化データは例えば「痔疾患無」、「痔レベル１」、「痔レベル２」にレベル分けされる。自宅１００からタクシー４００を利用して外出する場合に乗車時に乗客の抽象化データを健康情報データベース１１１からタクシー４００の端末４１０にロードする。

タクシー４００は、図４３に示すようなエアクッション４３０ｄを備えている。エアクッション４３０ｄは複数のブロックを有するエアクッション本体４３０１と、エアクッション本体４３０１の各ブロックに空気を供給するエア供給チューブ４３０２と、エアクッション本体４３０１が有する弁を制御するブロック弁制御線４３０３と、エアクッション本体４３０１の各ブロックに供給する空気を生成するエアコンプレッサ４３０４と、各ブロックの空気の充填と排気を制御する動作制御部４３０５と、を備える。エアクッション本体４３０１はいくつかのブロック毎に弁を持ち、各ブロックが独立して空気の充填と排出制御が可能な構成になっている。

乗客が痔を持っていると判断された場合、エアクッション４３０ｄはエアクッション本体４３０１の中央部の空気のみ排出しドーナツ状のクッションを形成する。これにより乗客は着座時のお尻の痛みが軽減されるため、着座体勢や疾病状況を気にすることなくタクシー４００に乗車でき、快適に移動することが可能となる。

痔の抽象化データによる車内装置の動作制御例を以下に説明する。

痔疾患無の場合、エアコン４３０ａは平常時の運転を行い、エアクッション４３０ｄは全ブロックに空気を充填する。

痔レベル１の場合、エアコン４３０ａは乗客の足元が冷えないように足元の送風比率を上げて温める。エアクッション４３０ｄは中心ブロックの空気を排気し、外周ブロックに空気を充填する。

痔レベル２の場合、エアコン４３０ａは、「痔レベル１」の動作に加え、設定温度を１℃上げる。エアクッション４３０ｄは中心ブロックの空気を排気し、外周ブロックに空気を充填する。また、「風邪レベル１」以上の場合も設定温度を１℃上げる。

以上、本発明者によってなされた発明を実施形態および実施例に基づき具体的に説明したが、本発明は、上記実施形態および実施例に限定されるものではなく、種々変更可能であることはいうまでもない。

１００・・・自宅（日常生活空間）
１１０・・・ホームサーバ
１１１・・・健康情報データベース
１１２・・・機器制御情報
１２０・・・アクチュエータ装置
１２１・・・ＭＣＵ
１２３・・・アクチュエータ
１３０・・・バイ・ファンクション装置
１４０・・・センシング装置
１４１・・・ＭＣＵ
１４２・・・センサ
１５０・・・ホームネットワーク

Claims

日常生活空間にあるセンシング装置でセンシングされたセンシングデータに基づいてユーザの健康状態を推定して抽象化し、抽象化された前記健康状態の抽象化データに基づいてアクチュエータ装置が前記ユーザの健康状態の改善を促す健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシング装置が前記センシングデータに基づいて前記ユーザの健康状態を分類しレベル分けして抽象化する健康サポートシステム。
請求項１の健康サポートシステムにおいて、
ホームサーバが前記センシングデータに基づいて前記ユーザの健康状態を分類しレベル分けして抽象化する健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記抽象化データをデータベースに蓄積し、前記データベースが前記日常生活空間と異なる非日常生活空間に持ち出される健康サポートシステム。
請求項４の健康サポートシステムにおいて、
前記抽象化データに基づいて前記非日常生活空間のアクチュエータ装置が前記ユーザの健康サポートを行う健康サポートシステム。
請求項４の健康サポートシステムにおいて、
前記非日常生活空間のセンシング装置がセンシングしたセンシングデータに基づいて前記非日常生活空間のセンシング装置が前記ユーザの健康状態を抽象化し、抽象化された健康情報の抽象化データが前記データベースに追記され、前記データベースが前記日常生活空間へ持ち帰えられる健康サポートシステム。
請求項４の健康サポートシステムにおいて、
前記非日常生活空間の前記アクチュエータ装置が動作する時に外部環境を取り込む健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシング装置はアクチュエータ機能を含み、
前記アクチュエータ装置はセンシング機能を含む健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシングデータはトイレが取得したものであり、
前記抽象化データは、お腹の調子の平常、第一下痢レベル、第二下痢レベル、第一便秘レベルおよび第二便秘レベルにレベル化される健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシングデータは前記センシング装置の温度センサまたはサーモグラフィが取得した前記ユーザの体温であり、
前記抽象化データは、取得した前記体温に基づいて、平常、第一風邪レベル、第二風邪レベル、第三風邪レベルおよび第四風邪レベルにレベル化される健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシングデータは前記センシング装置のマイクが取得した前記ユーザの音声情報であり、
前記抽象化データは、取得した前記音声情報に基づいて、平常、第一風邪レベル、第二風邪レベル、第三風邪レベルおよび第四風邪レベルにレベル化される健康サポートシステム。
請求項１１の健康サポートシステムにおいて、
前記音声情報は閉鼻声のスペクトラム、咳の音声波形パターン、くしゃみの音声波形パターン、鼻啜音の音声波形パターン、こう鼻音の音声波形パターンの少なくとも一つである健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシングデータは前記センシング装置のムービカメラが取得した前記ユーザの動作であり、
前記抽象化データは、取得した前記動作に基づいて、平常、第一風邪レベル、第二風邪レベル、第三風邪レベルおよび第四風邪レベルにレベル化される健康サポートシステム。
請求項１３の健康サポートシステムにおいて、
前記動作はくしゃみ動作およびこう鼻動作の少なくとも一つである健康サポートシステム。
請求項１の健康サポートシステムにおいて、
前記センシングデータは前記センシング装置が取得した前記ユーザの感情情報および生体情報であり、
前記抽象化データは、取得した前記感情情報および生体情報に基づいて、平常、第一ストレスレベルおよび第二ストレスレベルにレベル化される健康サポートシステム。
ユーザの生体情報を取得する第一センシング装置と、
抽象化データに基づいて動作する第一アクチュエータ装置と、
前記第一センシング装置と前記第一アクチュエータ装置とにネットワークを介して接続される第一サーバと、
を前記ユーザが普段生活を行う日常生活空間に備え、
前記第一センシング装置または前記第一サーバは前記生体情報に基づいて前記抽象化データを生成し、
前記抽象化データは前記ユーザの健康状態を推定して分類したものであり、
前記第一アクチュエータ装置は前記ユーザの健康状態の改善を促す健康サポートシステム。
請求項１６の健康サポートシステムにおいて、さらに、
ユーザの生体情報を取得する第二センシング装置と、
抽象化データに基づいて動作する第二アクチュエータ装置と、
前記第二センシング装置と前記第二アクチュエータ装置とに接続される第二サーバまたは端末と、
を前記日常生活空間と異なる非日常生活空間に備え、
前記日常生活空間の前記抽象化データを前記第一サーバのデータベースに蓄積し、前記データベースが前記非日常生活空間に持ち出される健康サポートシステム。
請求項１７の健康サポートシステムにおいて、
前記データベースに蓄積された抽象化データに基づいて前記第二アクチュエータ装置が前記ユーザの健康状態の改善を促す健康サポートシステム。
請求項１７の健康サポートシステムにおいて、
前記第二センシング装置がセンシングしたセンシングデータに基づいて前記第二センシング装置または前記第二サーバまたは前記端末が前記ユーザの生体情報を抽象化し、抽象化された前記生体情報の抽象化データが前記データベースに追記され、前記データベースが前記日常生活空間へ持ち帰えられる健康サポートシステム。
請求項１７の健康サポートシステムにおいて、
前記第二アクチュエータ装置が動作する時に外部環境を取り込む健康サポートシステム。