(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-11-11
(45)【発行日】2024-11-19
(54)【発明の名称】調理担当決定システム及びプログラム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20241112BHJP
【ＦＩ】
G06Q50/10
【請求項の数】
10
(21)【出願番号】P 2024011255
(22)【出願日】2024-01-29
【審査請求日】2024-02-08
(73)【特許権者】
【識別番号】000198787
【氏名又は名称】積水ハウス株式会社
(74)【代理人】
【識別番号】100117101
【弁理士】
【氏名又は名称】西木 信夫
(74)【代理人】
【識別番号】100120318
【弁理士】
【氏名又は名称】松田 朋浩
(72)【発明者】
【氏名】慎 彩実
(72)【発明者】
【氏名】佐藤 深雪
(72)【発明者】
【氏名】近藤 雅之
(72)【発明者】
【氏名】後藤 浩一
(72)【発明者】
【氏名】板津呂 真夕
(72)【発明者】
【氏名】瀬戸 千裕
【審査官】田川 泰宏
(56)【参考文献】
【文献】特開２００９－１６９６０５（ＪＰ，Ａ）
【文献】特開２０２０－１７７４４７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ー９９／００
(57)【特許請求の範囲】
【請求項1】
複数の住人の生体データを検出する生体センサと、通知装置と、
上記生体センサ及び上記通知装置と通信可能な制御装置と、を備えており、
上記制御装置は、
上記生体センサから生体データを取得する生体データ取得処理と、
上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、
特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、
決定した調理担当を、上記通知装置を通じて通知する通知処理と、を実行する、調理担当決定システム。
【請求項2】
上記制御装置は、決定した調理担当を日付と対応付けて実績データとしてメモリに記憶させる記憶処理をさらに実行し、
上記調理担当決定処理は、上記実績データにさらに基づいて、調理担当の候補から除外する住人を決定して調理担当を決定する処理である、請求項１に記載の調理担当決定システム。
【請求項3】
上記制御装置と通信可能な入力インタフェースをさらに備えており、上記制御装置は、
上記通知装置に、メモリに記憶された質問を所定時刻に通知させる質問通知処理と、
当該質問に対する住人の回答であって、上記入力インタフェースを通じて入力された当該回答を取得する回答取得処理と、をさらに実行し、
上記調理担当決定処理は、上記回答にさらに基づいて調理担当を決定する処理である、請求項１または２に記載の調理担当決定システム。
【請求項4】
上記質問は、複数の質問項目を有しており、上記質問項目は、複数の回答選択肢をそれぞれ有しており、
上記回答選択肢は、点数と対応付けられており、
上記調理担当決定処理は、上記回答に基づいて算出された総合点数が示す体調に基づいて調理担当を決定する処理である、請求項３に記載の調理担当決定システム。
【請求項5】
上記体調特定処理は、メモリに記憶された基礎生体データに対する上記生体データの変位量に基づいて各住人の体調をそれぞれ特定する処理である、請求項１に記載の調理担当決定システム。
【請求項6】
料理の種類と調理レベルとがメモリにおいて対応付けられており、上記制御装置は、
決定した調理担当の体調レベルに応じた調理レベルの料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行し、
上記通知処理は、決定した調理担当及び料理の種類を通知する処理である、請求項１に記載の調理担当決定システム。
【請求項7】
料理の種類と体調レベルとがメモリにおいて対応付けられており、上記制御装置は、
調理担当に決定した住人以外の住人の体調レベルに応じた種類の料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行し、
上記通知処理は、決定した調理担当及び料理の種類を通知する処理である、請求項１または６に記載の調理担当決定システム。
【請求項8】
上記調理担当決定処理は、上記体調特定処理において特定した住人の体調が、調理を行い得る全住人について閾値レベルを超えて悪いと判断したことに基づいて、調理担当に代えて、メモリに記憶された提案を通知することに決定し、
上記通知処理は、決定した調理担当或いは上記提案を上記通知装置を通じて通知する処理である、請求項１に記載の調理担当決定システム。
【請求項9】
上記提案は、予めメモリに登録された連絡情報を含む、請求項８に記載の調理担当決定システム。
【請求項10】
第１通信インタフェース及び第１コンピュータを有する情報処理装置に実装される第１プログラムと、ディスプレイ、第２通信インタフェース、及び第２コンピュータを有するユーザ端末に実装される第２プログラムと、を備え、
上記第２プログラムは、
複数の住人の生体データを検出する生体センサから生体データを取得する生体データ取得処理と、
取得した上記生体データを上記第２通信インタフェースを通じて上記情報処理装置に送信する生体データ送信処理と、を上記第２コンピュータに実行させ、
上記第１プログラムは、
受信した上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、
特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、
決定した調理担当を上記第１通信インタフェースを通じて上記ユーザ端末に送信する調理担当送信処理と、を上記第１コンピュータに実行させ、
上記第２プログラムは、
受信した調理担当を上記ディスプレイに表示する通知処理を上記第２コンピュータに実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、今日の調理担当を決定するシステムに関する。
【背景技術】
【0002】
特許文献１は、複数の住人からなる家族において、家事を各住人に割り振る家事分担システムを開示する。この家事分担システムは、住宅の各部屋にそれぞれ設置された複数のカメラと、生体センサと、コントローラとを備える。コントローラは、カメラの撮像画像と、生体センサが取得した住人の生体情報とに基づいて、家事を行なっている間の住人のストレス度を算出する。コントローラは、先月における住人の家事中のストレス度に基づいて、今月の家事の分担を決定する。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２０－１７７４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献１に開示されたシステムでは、家事実行中に感じるストレスに基づいて家事の分担を決定し、家事以外のストレスが考慮されないという問題がある。また、特許文献１に開示されたシステムでは、１月などのある程度の期間における家事分担を決定するから、例えば体調が悪い場合であっても、分担された家事を行なわなければならないという問題がある。
【0005】
本発明は、前述された事情に鑑みてなされたものであり、その目的は、体調の悪い住人に調理を行なわせてしまうことを防止可能な調理担当決定システムを提供することにある。
【課題を解決するための手段】
【0006】
(1) 本発明に係る調理担当決定システムは、複数の住人の生体データを検出する生体センサと、通知装置と、上記生体センサ及び上記通知装置と通信可能な制御装置と、を備える。上記制御装置は、上記生体センサから生体データを取得する生体データ取得処理と、上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、決定した調理担当を、上記通知装置を通じて通知する通知処理と、を実行する。
【0007】
所定時刻は、食事の調理を開始する前の時刻に設定される。制御装置は、所定時刻になると、生体センサから生体データを取得し、取得した生体データに基づいて各住人の今日（所定日）の体調をそれぞれ特定し、特定した各住人の今日の体調に基づいて、今日の食事の調理担当を決定して住人に通知する。
【0008】
(2) 上記制御装置は、決定した調理担当を日付と対応付けて実績データとしてメモリに記憶させる記憶処理をさらに実行してもよい。上記調理担当決定処理は、上記実績データに基づいて調理担当の候補から除外する住人を決定して調理担当を決定する処理である。
【0009】
本発明に係る調理担当決定システムによって決定された調理担当は、日付と対応付けて実績データとしてメモリに記憶される。当該実績データにおいて、例えば２日連続で調理担当となった住人は、次の調理担当候補から外される。その結果、住人間において調理の分担の公平性が保たれる。
【0010】
(3) 本発明に係る調理担当決定システムは、上記制御装置と通信可能な入力インタフェースをさらに備えていてもよい。上記制御装置は、上記通知装置に、メモリに記憶された質問を所定時刻に通知させる質問通知処理と、当該質問に対する住人の回答であって、上記入力インタフェースを通じて入力された当該回答を取得する回答取得処理と、をさらに実行し、上記調理担当決定処理は、上記回答にさらに基づいて調理担当を決定する処理である。
【0011】
精神的疲労は、生体データの変化として現れないことがある。制御装置は、質問に対する回答により、生体データに現れない精神的疲労も特定することができる。したがって、本発明に係る調理担当決定システムは、各住人の身体的且つ精神的な疲労に基づいて、調理担当を決定することができる。
【0012】
(4) 上記質問は、複数の質問項目を有しており、上記質問項目は、複数の回答選択肢をそれぞれ有しており、上記回答選択肢は、メモリにおいて点数と対応付けられており、上記調理担当決定処理は、上記回答に基づいて算出された総合点数に基づいて調理担当を決定する処理であってもよい。
【0013】
各質問項目に対する回答は回答選択肢の選択によって行なわれ、当該回答選択肢は点数と対応付けられているから、制御装置は、住人の精神的疲労を数値化（点数化）して取得し、数値によって各住人の精神的疲労度を決定することができる。
【0014】
(5) 上記体調特定処理は、メモリに記憶された基礎生体データに対する上記生体データの変位量に基づいて各住人の体調をそれぞれ特定する処理であってもよい。
【0015】
住人の体調は、基礎生体データに対する生体データの変位量に基づいて特定される。したがって、制御装置は、住人の体調を数値として取得することができる。
【0016】
(6) 料理の種類と調理レベルとがメモリにおいて対応付けられていてもよい。上記制御装置は、決定した調理担当の体調レベルに応じた調理レベルの料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行する。上記通知処理は、決定した調理担当及び料理の種類を通知する処理である。
【0017】
例えば、調理を行い得る全住人の体調が悪く、比較的体調の良い住人が調理担当に決定された場合、調理レベルが低い料理、すなわち簡単に調理を行なえる料理が、調理担当に決定された住人に提案される。その結果、体調の悪い調理担当の負担を低減することができる。
【0018】
(7) 料理の種類と体調レベルとがメモリにおいて対応付けられていてもよい。上記制御装置は、調理担当に決定した住人以外の住人の体調レベルに応じた種類の料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行する。上記通知処理は、決定した調理担当及び料理の種類を通知する処理である。
【0019】
調理担当に決定された住人以外の住人の体調に応じた種類のメニュー（料理）が決定され、調理担当に通知される。その結果、体調が悪い住人は、お粥や湯豆腐など消化のよい料理を食べることができる。
【0020】
(8) 上記調理担当決定処理は、上記体調特定処理において特定した住人の体調が、調理を行い得る全住人について閾値レベルを超えて悪いと判断したことに基づいて、調理担当に代えて、メモリに記憶された提案を通知することに決定し、上記通知処理は、決定した調理担当或いは上記提案を上記通知装置を通じて通知する処理であってもよい。
【0021】
調理を行い得る全住人の体調が悪い場合、調理担当が決定されず、出前をとることなどの提案が住人に対してされる。
【0022】
(9) 上記提案は、予めメモリに登録された連絡情報を含んでいてもよい。
【0023】
連絡情報は、例えば料理を配達してくれる店舗の電話番号やメールアドレスやＵＲＬ、或いは、近くに住む親の電話番号やメールアドレスなどである。住人は、通知された連絡情報が示す店舗に連絡して料理の配達を注文し、或いは近所に住む親に調理の依頼を行う。
【0024】
(10) 本発明に係るプログラムは、第１通信インタフェース及び第１コンピュータを有する情報処理装置に実装される第１プログラムと、ディスプレイ、第２通信インタフェース、及び第２コンピュータを有するユーザ端末に実装される第２プログラムと、を備える。上記第２プログラムは、複数の住人の生体データを検出する生体センサから生体データを取得する生体データ取得処理と、取得した上記生体データを上記第２通信インタフェースを通じて上記情報処理装置に送信する生体データ送信処理と、を上記第２コンピュータに実行させる。上記第１プログラムは、受信した上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、決定した調理担当を上記第１通信インタフェースを通じて上記ユーザ端末に送信する調理担当送信処理と、を上記第１コンピュータに実行させる。上記第２プログラムは、受信した調理担当を上記ディスプレイに表示する通知処理を上記第２コンピュータに実行させる。
【0025】
本発明は、プログラムの発明として捉えることもできる。
【発明の効果】
【0026】
本発明に係る調理担当決定システムは、体調の悪い住人に調理を行なわせてしまうことを防止することができる。
【図面の簡単な説明】
【0027】
【発明を実施するための形態】
【0028】
以下、本発明の実施形態について説明する。なお、以下に説明される実施形態は本発明の一例にすぎず、本発明の要旨を変更しない範囲で、本発明の実施形態を適宜変更できることは言うまでもない。また、図４から図６に示すフローチャートに示された各処理（各ステップ）は、本発明の要旨を変更しない範囲で実行順を適宜変更されてもよいし、一部が省略されてもよいし、他の処理を追加されてもよいし、同等の他の処理に代えられてもよい。
【0029】
［調理担当決定システム１０の概要］
本実施形態で説明される調理担当決定システム１０（図１参照）は、今日の夕食の調理担当を候補者の中から決定して通知するサービスを提供するシステムである。サービスが提供される対象は、１つの住宅において、調理を行ない得る者（以下、「調理適格者」とも称する。）が複数存在する家族である。調理適格者は、例えば夫、妻、母親、父親、成人した子供などである。調理を行なえない者は、例えば未成年の子供や、高齢の母親、父親、祖父、及び祖母などである。調理適格者は、自己が所持するユーザ端末に、サービスを提供する事業者（以下、「サービス提供者」とも称する。）が提供するアプリケーションプログラムをダウンロードすることにより、サービスの提供を受ける。
本実施形態で説明される調理担当決定システム１０（図１参照）は、今日の夕食の調理担当を候補者の中から決定して通知するサービスを提供するシステムである。サービスが提供される対象は、１つの住宅において、調理を行ない得る者（以下、「調理適格者」とも称する。）が複数存在する家族である。調理適格者は、例えば夫、妻、母親、父親、成人した子供などである。調理を行なえない者は、例えば未成年の子供や、高齢の母親、父親、祖父、及び祖母などである。調理適格者は、自己が所持するユーザ端末に、サービスを提供する事業者（以下、「サービス提供者」とも称する。）が提供するアプリケーションプログラムをダウンロードすることにより、サービスの提供を受ける。
【0030】
サービス提供者は、例えば住宅の建築を行なった事業者である。サービス提供者は、住宅の施工主に対して提供する種々のサービスの１つとして、調理担当決定システム１０を用いたサービスの提供を行う。種々のサービスとは、例えば、住宅のメンテナンスに関するサービスや、住宅において快適な生活を行うことを支援するサービスである。調理担当決定システム１０は、例えば他のサービスを提供するシステムと連動して運用される。例えば、調理担当決定システム１０は、他のシステムに使用されるデータを提供する。或いは、調理担当決定システム１０は、運用に必要なデータを他のシステムから取得する。つまり、調理担当決定システム１０は、他のシステムのためのデータ収集システムとしても機能する。
【0031】
ただし、調理担当決定システム１０は、単独のシステムとして運用されてもよいし、住宅の建築を行なった事業者以外の事業者によって運用されてもよい。
【0032】
［調理担当決定システム１０の構成］
図１に示されるように、調理担当決定システム１０は、複数のウエアラブル端末２０と、ユーザ端末３０と、管理サーバ４０とを備える。なお、図１では、１つのウエアラブル端末２０のみが示されており、他のウエアラブル端末２０の図示が省略されている。
図１に示されるように、調理担当決定システム１０は、複数のウエアラブル端末２０と、ユーザ端末３０と、管理サーバ４０とを備える。なお、図１では、１つのウエアラブル端末２０のみが示されており、他のウエアラブル端末２０の図示が省略されている。
【0033】
［ウエアラブル端末２０］
ウエアラブル端末２０は、住人の生体データを取得する装置である。ウエアラブル端末２０は、住人が所持する装置であってもよいし、サービス提供者が住人に販売或いは貸与する装置であってもよい。例えば一般の市販品がウエアラブル端末２０として使用される。ウエアラブル端末２０は、生体センサの一例である。
ウエアラブル端末２０は、住人の生体データを取得する装置である。ウエアラブル端末２０は、住人が所持する装置であってもよいし、サービス提供者が住人に販売或いは貸与する装置であってもよい。例えば一般の市販品がウエアラブル端末２０として使用される。ウエアラブル端末２０は、生体センサの一例である。
【0034】
ウエアラブル端末２０は、調理適格を有する住人の身体に装着されて使用される。装着箇所は、住人の腕、頭部、脚、胴体などのいずれであってもよい。
【0035】
ウエアラブル端末２０は、中央演算処理装置であるＣＰＵ２１、端末メモリ２２、通信インタフェース２３、及びセンサ群２４と、これらを接続する不図示の通信バスと、を備える。
【0036】
端末メモリ２２は、例えばＲＯＭ、ＲＡＭ、及びＥＥＰＲＯＭや、その他の記憶素子によって構成されている。なお、端末メモリ２２は、どのような種類の記憶素子で構成されていてもよい。
【0037】
図１には示されていないが、端末メモリ２２は、オペレーティングシステムであるＯＳと、端末プログラムと、ユーザ端末３０との通信に必要な設定データと、を記憶している。
【0038】
端末プログラムは、センサ群２４の各種センサの駆動制御や、ユーザ端末３０との通信制御などをＣＰＵ２１に実行させる。
【0039】
通信に必要な設定データとは、ウエアラブル端末２０の装着者が所持するユーザ端末３０の通信アドレスなど、ユーザ端末３０との通信に必要なデータである。設定データは、例えばユーザ端末３０を通じてウエアラブル端末２０に登録される。
【0040】
通信インタフェース２３は、ユーザ端末３０と近距離無線通信を行うインタフェースである。なお、ウエアラブル端末２０は、通信インタフェース２３に代えて、或いは通信インタフェース２３に加えて、移動体通信網を介してインターネット１１に接続される通信インタフェースを備えていてもよい。
【0041】
センサ群２４は、装着者の体温、血圧、心拍数、呼吸数、睡眠状態を検知する各種のセンサを有している。各種のセンサは、温度センサ２５、光センサ２６、加速度センサ２７、及び生体電位センサ２８である。
【0042】
温度センサ２５は、例えば、装着者が発した赤外線を受光し、受光した赤外線量に応じた温度、すなわち装着者の体温を出力する。
【0043】
光センサ２６は、装着者に向かって光を照射し、装着者の血管で反射された光を受光する。光センサ２６は、照射光の照射から反射光の受光までの時間や、照射光と反射光との位相差などに基づいて生成したデータを出力する。当該データは、血管を流れる血液の量（血流量）を示す。光センサ２６が出力するデータは、装着者の血圧や心拍数や睡眠状態か否かを示す生体データの生成に用いられる。
【0044】
加速度センサ２７は、装着者の身体の傾き、衝撃、及び振動に応じたデータを出力する。加速度センサ２７が出力するデータは、装着者の血圧や心拍数や呼吸数や睡眠状態か否かを示す生体データの生成に用いられる。
【0045】
生体電位センサ２８は、装着者が発する微弱な生体電位を検出し、心電図や脳波や筋電図を示すデータを出力する。生体電位センサ２８が出力するデータは、睡眠状態か否かを示す生体データの生成に用いられる。
【0046】
ウエアラブル端末２０の端末メモリ２２に実装された端末プログラム（不図示）は、センサ群２４が出力した各データに基づいて、装着者の体温、睡眠時間、血圧、心拍数、及び呼吸数を示す生体データを生成する。当該端末プログラムは、定期的に、或いはユーザ端末３０からの要求に応じて、通信インタフェース２３を通じて生体データをユーザ端末３０に送信する。
【0047】
［ユーザ端末３０］
ユーザ端末３０は、ユーザ（住人）が所持する通信端末である。ユーザ端末３０は、例えばスマートフォン（登録商標）やタブレット（登録商標）やパーソナルコンピュータ（いわゆるＰＣ）などである。
ユーザ端末３０は、ユーザ（住人）が所持する通信端末である。ユーザ端末３０は、例えばスマートフォン（登録商標）やタブレット（登録商標）やパーソナルコンピュータ（いわゆるＰＣ）などである。
【0048】
ユーザ端末３０は、家族に属する住人の全員が所持していてもよいし、調理適格者のみが所持していてもよいし、調理適格者以外の住人が所持していてもよい。例えば、１つのユーザ端末３０が、複数のウエアラブル端末２０からそれぞれ生体データを受信して管理サーバ４０に送信する設定とされている場合、ユーザ端末３０は、１台だけであってもよい。なお、以下では、調理適格を有する住人がユーザ端末３０をそれぞれ所持し、且つ調理適格を有さない住人もユーザ端末３０を所持する例が説明される。
【0049】
ユーザ端末３０は、中央演算処理装置であるＣＰＵ３１、端末メモリ３２、通信インタフェース３３、３４、タッチパネル３５、スピーカ３６、及びクロックモジュール３７と、これらを接続する不図示の通信バスと、を備える。ＣＰＵ３１は、第２コンピュータの一例である。
【0050】
端末メモリ３２は、例えばＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、ハードディスクドライブ、ソリッドステートドライブ（いわゆるＳＳＤ）、及びＵＳＢメモリや、その他の記憶素子及び記憶装置によって構成されている。なお、端末メモリ３２は、どのような種類の記憶素子及び記憶装置で構成されていてもよい。
【0051】
端末メモリ３２は、オペレーティングシステムであるＯＳ３８と、アプリケーションプログラム３９と、通信に必要な設定データと、を記憶している。なお、図１では、アプリケーションプログラム３９は、「アプリ３９」と略して示されている。端末メモリ３２は、メモリの一例である。
【0052】
アプリケーションプログラム３９は、ユーザ端末３０の所持者によってウェブサイトからダウンロードされてユーザ端末３０に実装されたプログラムである。なお、アプリケーションプログラム３９は、ユーザ端末３０に実装されたブラウザ上で動作するプログラムであってもよい。アプリケーションプログラム３９は、ウエアラブル端末２０から生体データを取得し、取得した生体データを管理サーバ４０に送信する機能を有する。また、アプリケーションプログラム３９は、ＯＳ３８を通じて画面をタッチパネル３５に表示させる機能を有する。また、アプリケーションプログラム３９は、タッチパネル３５を通じてユーザの入力を受け付ける機能を有する。アプリケーションプログラム３９は、単一のプログラムであってもよいし、近距離通信モジュール、インターネット通信モジュール、ＵＩ（ユーザインタフェース）モジュール、及び本体モジュールなどの複数のプログラムからなるプログラムであってもよい。アプリケーションプログラム３９は、第２プログラムの一例である。
【0053】
通信に必要な設定データとは、ウエアラブル端末２０の通信アドレス及び管理サーバ４０の通信アドレスなど、ウエアラブル端末２０及び管理サーバ４０との通信に必要なデータである。管理サーバ４０との通信に必要な設定データは、アプリケーションプログラム３９のダウンロード時に端末メモリ３２に記憶される。ウエアラブル端末２０との通信に必要な設定データは、ユーザ端末３０の所持者によってユーザ端末３０に登録される。
【0054】
通信インタフェース３３は、近距離無線通信を行うインタフェースである。近距離無線通信は、例えばＷｉ－Ｆｉ（登録商標）などの無線ＬＡＮ（登録商標）や、ブルートゥース（登録商標）などである。近接無線通信が無線ＬＡＮの場合、ユーザ端末３０は、住宅に設置されたルータなどを介してウエアラブル端末２０と通信を行う。近接無線通信がブルートゥース（登録商標）の場合、ユーザ端末３０は、ウエアラブル端末２０と直接、近接無線通信を行う。ユーザ端末３０がウエアラブル端末２０と通信可能であれば、通信規格（通信プロトコル）は特に限定されない。
【0055】
通信インタフェース３４は、不図示の移動体通信網及びインターネット１１を介して管理サーバ４０と通信を行うインタフェースである。通信インタフェース３３、３４は、第２通信インタフェースの一例である。
【0056】
タッチパネル３５は、ディスプレイと、ディスプレイに重畳された透明な膜状のタッチセンサと、を備える。つまり、タッチパネル３５は、表示機能の他、ユーザの入力を受け付ける入力インタフェースとしても機能する。なお、ユーザ端末３０は、入力インタフェースとして、音声入力を受け付けるマイクロフォンを備えていてもよい。タッチパネル３５は、通知装置及びディスプレイの一例である。タッチパネル３５及びマイクロフォンは、入力インタフェースの一例である。
【0057】
スピーカ３６は、入力された音声データを音声に変換して出力する。
【0058】
クロックモジュール３７は、日時情報を出力する。なお、ユーザ端末３０は、インターネット１１を通じて日時情報を取得可能であれば、クロックモジュールを備えていなくてもよい。
【0059】
ユーザ端末３０は、管理サーバ４０から受け取った今日の調理担当をタッチパネル３５に表示させ、或いはスピーカ３６に出力させることにより、住人に通知する。ユーザ端末３０、タッチパネル３５、及びスピーカ３６は、通知装置の一例である。
【0060】
クロックモジュール３７は、日時情報を出力する。なお、ユーザ端末３０が、通信インタフェース３３、３４を通じて日時情報を取得する場合、ユーザ端末３０は、クロックモジュール３７を有していなくてもよい。
【0061】
［管理サーバ４０］
管理サーバ４０は、サービス提供者が所持するサーバであってもよいし、サービス提供者が使用権限を有するレンタルサーバであってもよい。
管理サーバ４０は、サービス提供者が所持するサーバであってもよいし、サービス提供者が使用権限を有するレンタルサーバであってもよい。
【0062】
管理サーバ４０は、単一のサーバであってもよいし、複数のサーバで構成されたクラウドサーバであってもよい。管理サーバ４０は、情報処理装置の一例である。
【0063】
管理サーバ４０は、中央演算処理装置であるＣＰＵ４１、サーバメモリ４２、及び通信インタフェース４３と、これらを接続する不図示の通信バスと、を備える。管理サーバ４０のＣＰＵ４１は、制御装置の一例である。また、管理サーバ４０のＣＰＵ４１及びユーザ端末３０のＣＰＵ３１は、制御装置の一例である。ＣＰＵ４１は、第１コンピュータの一例である。
【0064】
通信インタフェース４３は、例えばインターネット１１に接続された不図示のゲートウェイ装置と接続される。つまり、管理サーバ４０は、ゲートウェイ装置を介してインターネット１１と接続されている。通信インタフェース４３は、第１通信インタフェースの一例である。
【0065】
サーバメモリ４２は、例えばＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、ハードディスクドライブ、ソリッドステートドライブ、及びＵＳＢメモリや、その他の記憶素子及び記憶装置によって構成されている。また、サーバメモリ４２の一部は、ストレージサーバによって構成されていてもよい。
【0066】
サーバメモリ４２は、オペレーティングシステムであるＯＳ４４と、管理プログラム４５と、管理データベースとを記憶している。
【0067】
管理プログラム４５は、図４から図６に示された処理を実行するプログラムである。管理プログラム４５は、単一のプログラムであってもよいし、通信モジュールやＵＩモジュールや本体モジュールなどの複数のプログラムからなるプログラムであってもよい。管理プログラム４５は、第１プログラムの一例である。管理プログラム４５及びアプリケーションプログラム３９は、プログラムの一例である。
【0068】
管理データベースは、図２及び図３に示されたデータベース及びテーブルを有する。管理データベースは、表を示すデータと、表へのデータの登録及び表からのデータの読み出しなどを行う制御プログラムと、を有している。管理プログラム４５は、ＯＳ４４を通じて当該制御プログラムにデータの読み出しや登録（書き込み）を指示する。
【0069】
管理データベースは、図２（Ａ）に示されるユーザ管理データベースを含む。ユーザ管理データベースは、ユーザ（住人）に関する情報と、ユーザが属する家族に関する情報とが登録されるデータベースである。
【0070】
ユーザ管理データベースは、「ユーザＩＤ」、「姓名」、「続柄」、「性別」、「年齢」、「調理適格」、「ユーザ端末」、「端末情報」、「ウエアラブル」、「基礎生体データ」、「住所」「ヘルプ者情報」、及び「出前店情報」の各名称がそれぞれ付された複数のカラム（列）を有する。
【0071】
「ユーザＩＤ」の名称が付されたカラムのフィールドは、ユーザ（住人）を個々に識別する識別情報であるユーザＩＤを登録される。ユーザ管理データベースに登録された各レコード（行）は、ユーザＩＤによって個々に識別される。
【0072】
「ユーザＩＤ」の名称が付されたカラムは、「家族」の名称が付されたサブカラムと、「個別」の名称が付されたサブカラムとを備える。「家族」の名称が付されたサブカラムのフィールドには、住人が属する家族を識別する家族ＩＤが登録される。つまり、同一の家族に属する住人は、同一の家族ＩＤを有する。「個別」の名称が付されたサブカラムのフィールドには、住人が属する家族において個人を個別に識別するＩＤが登録される。つまり、各住人は、家族単位で識別され、且つ個人単位でも識別され得る。
【0073】
「姓名」の名称が付されたカラムのフィールドは、住人の姓名を登録される。
【0074】
「続柄」の名称が付されたカラムのフィールドは、契約者、或いは契約者との関係（続柄）を登録される。契約者とは、住宅の建築をサービス提供者に発注した者（施工主）、或いはサービスの提供を受けることをサービス提供者に申請した者を意味する。
【0075】
「性別」の名称が付されたカラムのフィールドは、男又は女を登録される。
【0076】
「年齢」の名称が付されたカラムのフィールドは、住人の年齢を登録される。
【0077】
「調理適格」の名称が付されたカラムのフィールドは、調理適格フラグを登録される。調理適格フラグは、調理適格者であることを示す「１」或いは調理適格者でないことを示す「０」である。
【0078】
なお、調理担当として選択され得る住人は、調理適格を有する住人のみであるから、調理適格を有さない住人については、ユーザ管理データベースに登録されなくてもよい。しかしながら、決定された調理担当を、調理担当に決定された者以外の住人にも通知する場合、調理適格者でない住人についても、ユーザ管理データベースに登録される。また、調理担当決定システム１０が情報収集システムを兼ねる場合、或いは調理担当決定システム１０が他のサービスを提供するシステムと連動する場合、調理適格を有さない住人の情報も、可能な範囲でユーザ管理データベースに登録される。
【0079】
「ユーザ端末」の名称が付されたカラムのフィールドは、ユーザ端末３０を所持していることを示す「１」或いはユーザ端末３０を所持していないことを示す「０」を登録される。なお、ユーザ端末３０を所持しない住人については、ユーザ管理データベースに登録されなくてもよい。
【0080】
「端末情報」の名称が付されたカラムのフィールドは、住人が所持するユーザ端末３０の通信に関する情報が登録される。通信に関する情報とは、通信アドレスやメールアドレスが含まれる。通信に関する情報は、例えば管理サーバ４０からユーザ端末３０に、決定された調理担当を通知する場合に使用される。
【0081】
「ウエアラブル」の名称が付されたカラムのフィールドは、ウエアラブル端末２０を装着して生体データを取得可能な住人であることを示す「１」、或いはウエアラブル端末２０を装着しておらず生体データを取得不可の住人であることを示す「０」を登録される。なお、調理適格が「１」である住人については、「ウエアラブル」の名称が付されたカラムのフィールドに、必ず「１」が登録される。
【0082】
「基礎生体データ」の名称が付されたカラムのフィールドには、体温などの住人の基礎生体データを登録される。基礎生体データは、住人の体調の特定に使用される。なお、住人の体調は、調理担当の決定の他、提案する料理の種類の決定にも用いられる。したがって、基礎生体データは、調理適格を有する住人だけでなく、他の住人についても登録されることが望ましい。また、調理担当決定システム１０が情報収集システムを兼ねる場合、或いは調理担当決定システム１０が他のサービスを提供するシステムと連動する場合、調理適格を有さない住人の基礎生体データもユーザ管理データベースに登録されることが望ましい。
【0083】
「基礎生体データ」の名称が付されたカラムは、「体温」、「睡眠時間」、「血圧」、「心拍数」、「呼吸数」の名称がそれぞれ付された複数のサブカラムを備える。
【0084】
「体温」の名称が付されたサブカラムのフィールドは、住人の通常時の体温を登録される。通常時の体温は、ウエアラブル端末２０が過去に検出した体温の平均値であってもよいし、住人の性別及び年齢に応じた一般的な体温であってもよいし、住人がアプリケーションプログラム３９を通じて申告した体温であってもよい。
【0085】
「睡眠時間」の名称が付されたサブカラムのフィールドは、住人の通常時の睡眠時間を登録される。通常時の睡眠時間は、ウエアラブル端末２０が過去に検出した睡眠時間の平均値であってもよいし、住人の性別及び年齢に応じた一般的な睡眠時間であってもよいし、住人がアプリケーションプログラム３９を通じて申告した睡眠時間であってもよい。
【0086】
「血圧」の名称が付されたサブカラムのフィールドは、住人の通常時の血圧を登録される。通常時の血圧は、ウエアラブル端末２０が過去に検出した血圧の平均値であってもよいし、住人の性別及び年齢に応じた一般的な血圧であってもよいし、住人がアプリケーションプログラム３９を通じて申告した血圧であってもよい。
【0087】
「心拍数」の名称が付されたサブカラムのフィールドは、住人の通常時の心拍数を登録される。通常時の心拍数は、ウエアラブル端末２０が過去に検出した心拍数の平均値であってもよいし、住人の性別及び年齢に応じた一般的な心拍数であってもよいし、住人がアプリケーションプログラム３９を通じて申告した心拍数であってもよい。
【0088】
「呼吸数」の名称が付されたサブカラムのフィールドは、住人の通常時の呼吸数を登録される。通常時の呼吸数は、ウエアラブル端末２０が過去に検出した呼吸数の平均値であってもよいし、住人の性別及び年齢に応じた一般的な呼吸数であってもよいし、住人がアプリケーションプログラム３９を通じて申告した呼吸数であってもよい。
【0089】
「住所」の名称が付されたカラムのフィールドは、住人（家族）の住所が登録される。
【0090】
「ヘルプ者情報」の名称が付されたカラムのフィールドは、家族が住む住宅に近い場所に住む親など、当該家族に対して調理支援を行ない得る者（以下、「ヘルプ者」とも称する。）に関する情報を登録される。当該情報は、ヘルプ者の姓名や、住所や、電話番号や、メールアドレスなどである。なお、ヘルプ者がいない場合、ヘルプ者が居ないことを示す「０」が登録される。
【0091】
「出前店情報」の名称が付されたカラムのフィールドは、家族が住む住宅に料理を配達可能な店舗（以下、「出前店」とも称する。）に関する情報を登録される。当該情報は、出前店の名称や、出前店の種類や、配達可能な料理名や、料金や、電話番号や、メールアドレスや、ＵＲＬなどである。出前店の種類は、例えば中華、ピザ、和食、寿司などである。
【0092】
「姓名」、「続柄」、「性別」、「年齢」、「調理適格」、「ユーザ端末」、「端末情報」、「ウエアラブル」、「基礎生体データ」、「住所」、「ヘルプ者情報」は、ユーザ端末３０へのアプリケーションプログラム３９のダウンロード時或いはダウンロード後に、ユーザによってユーザ端末３０に入力される。アプリケーションプログラム３９は、入力された「姓名」、「続柄」、「性別」、「年齢」、「調理適格」、「ユーザ端末」、「端末情報」、「ウエアラブル」、「基礎生体データ」、「住所」、「ヘルプ者情報」を含む申請データを、インターネット１１を通じて管理サーバ４０に送信する。管理サーバ４０の管理プログラム４５は、申請データを受信したことに基づいて、ユーザ管理データベースに新たなレコードを生成し、生成したレコードに、ユニークなユーザＩＤを付すとともに、申請データに含まれる「姓名」、「続柄」、「性別」、「年齢」、「調理適格」、「ユーザ端末」、「端末情報」、「ウエアラブル」、「基礎生体データ」、「住所」、「ヘルプ者情報」を登録する。
【0093】
なお、管理データベースは、一般的な基礎生体データと、性別と、年齢とを対応付けた対応テーブルを有していてもよい。その場合、管理サーバ４０は、申請データに含まれる「性別」及び「年齢」と対応する基礎生体データを上記テーブルから取得して、新たに生成したレコードに登録する。つまり、初期の基礎生体データとして、ユーザが申告したデータが使用されてもよいし、性別及び年齢に応じた一般的なデータが使用されてもよい。そして、管理サーバ４０は、ウエアラブル端末２０によって取得した生体データに基づいて、初期の基礎生体データを、各住人の特性に合わせて更新してもよい。
【0094】
また、サービス提供者が、住人が住む住宅を建築した建築事業者である場合、「姓名」、「続柄」、「性別」、「年齢」、「調理適格」、「ユーザ端末」、「端末情報」、「ウエアラブル」、「基礎生体データ」、「住所」、「ヘルプ者情報」は、住宅の注文時（受注時）、或いは建築後、住人から聞き取りを行なったサービス提供者のオペレータによってユーザ管理データベースに登録されてもよい。
【0095】
また、「姓名」、「続柄」、「性別」、「年齢」、「調理適格」、「ユーザ端末」、「端末情報」、「ウエアラブル」、「基礎生体データ」、「住所」、「ヘルプ者情報」は、各住人がそれぞれユーザ端末３０を用いて管理サーバ４０に送信してもよいし、契約者が代表して管理サーバ４０に送信してもよい。なお、ユーザ端末３０を所持しない住人に関する情報については、契約者など、ユーザ端末３０を所持する住人がユーザ端末３０を用いて管理サーバ４０に送信する。
【0096】
「出前店情報」は、住人自身が検索を行なってピックアップした店舗を、ユーザ端末３０を用いて管理サーバ４０に送信することによってユーザ管理データベースに登録されてもよいし、ユーザ管理データベースに登録された住人の住所に基づいて管理プログラム４５が検索を行なって、ユーザ管理データベースに登録してもよい。
【0097】
管理データベースは、図２（Ｂ）に示される実績管理データベースを含む。実績管理データベースは、過去に決定した調理担当のユーザＩＤが日付と対応付けて登録されるデータベースである。実績管理データベースに登録される各レコードは、家族ＩＤを用いて相互に識別される。つまり、家族ごとに、調理担当となった住人のユーザＩＤが日付と対応付けて登録される。なお、調理担当が決定されず、ヘルプ者が調理支援を行なった場合、或いは出前を依頼した場合、ユーザＩＤに代えて、「０」が実績管理データベースに登録される。
【0098】
管理データベースは、図２（Ｃ）に示される調理データベースを含む。調理データベースは、各料理のデータを管理するデータベースである。調理データベースは、「料理名」、「調理レベル」、及び「総合点数（体調レベル）」の各名称がそれぞれ付された複数のカラムを有する。
【0099】
「料理名」の名称が付されたカラムのフィールドは、回鍋肉や雑炊や湯豆腐などの料理名を登録される。つまり、料理名ごとにレコードが生成される。
【0100】
「調理レベル」の名称が付されたカラムのフィールドは、調理に手間がかからないことを示す「０」或いは調理に手間がかかることを示す「１」を登録される。つまり、調理レベル「０」が付された料理は、簡単調理を示し、調理レベル「１」が付された料理は、しっかり調理を示す。調理担当に決定した住人の体調が良い場合、調理レベルが「１」の料理（メニュー）が調理担当に提案され、調理担当に決定した住人の体調が悪い場合、調理レベルが「０」の料理（メニュー）が調理担当に提案される。
【0101】
「総合点数（体調レベル）」の名称が付されたカラムのフィールドは、体調レベルを示す総合点数を登録される。体調レベルは、当該料理がどのような体調の者に適した料理であるかを示す。例えば、雑炊や湯豆腐は、総合点数（体調レベル）が「５以上」であって体調の悪い者に適した料理であり、回鍋肉は、総合点数（体調レベル）が４以下であって体調が良い者に適した料理である。
【0102】
調理担当に決定した住人に対して提案（推奨）される料理は、調理担当に決定した住人の体調と、料理を食べる他の住人の体調とに基づいて決定（選択）される。
【0103】
管理データベースは、図２（Ｄ）に示される質問点数化テーブルを含む。質問点数化テーブルは、質問に対して住人が選択した回答選択肢と点数とを対応付けたテーブルである。図２（Ｄ）に示す例では、「気持ち」を問う質問に対する回答選択肢「問題なし」は「０」点と対応付けられ、回答選択肢「しんどい」は「２」点と対応付けられ、回答選択肢「立ち直れない」は「５」点と対応付けられている。また、「眠気」を問う質問に対する回答選択肢「問題なし」は「０」点と対応付けられ、回答選択肢「眠かった」は「１」点と対応付けられている。また、女性に対する限定質問である「生理」に対する回答選択肢「１－３日目」は「１」点と対応付けられ、回答選択肢「それ以外」は「０」点と対応付けられている。「気持ち」、「眠気」、及び「生理」は、質問項目の一例である。
【0104】
質問点数化テーブルにより、生体データに現れない精神的疲労が数値化される。
【0105】
管理データベースは、図３（Ａ）に示される生体データ点数化テーブルを含む。生体データ点数化テーブルは、ウエアラブル端末２０によって取得された住人の生体データを、ユーザ管理データベース（図２（Ａ）参照）に登録された基礎生体データを用いて点数化するためのテーブルである。
【0106】
生体データ点数化テーブルは、「体温」に関するレコードと、「睡眠時間」に関するレコードと、「血圧」に関するレコードと、「心拍数」に関するレコードと、「呼吸数」に関するレコードと、を有する。
【0107】
「体温」に関するレコードでは、通常時の体温である基礎生体データの体温Ａに対する住人の今日の体温の変位量（「Ａ－体温」の絶対値）に応じて４段階で点数化されている。具体的には、当該変位量が０．４℃以下である場合、「０」点であり、当該変位量が０．４℃を超え０．８℃以下である場合、「１」点であり、当該変位量が０．８℃を超え１．６℃以下である場合「３」点であり、当該変位量が１．６℃を超える場合、「５」点である。なお、今日の体温とは、夕食の調理を開始する時刻よりも所定時間だけ前の所定時刻における体温である。
【0108】
「睡眠時間」に関するレコードでは、通常時の睡眠時間である基礎生体データの睡眠時間Ｂに対する住人の昨夜の睡眠時間の変位量に応じて４段階で点数化されている。具体的には、昨夜の睡眠時間が、通常時の睡眠時間の９割を確保できていれば（０．９倍以上）、「０」点であり、昨夜の睡眠時間が、通常時の睡眠時間の８割を確保できていれば（０．８倍以上０．９倍未満）、「１」点であり、昨夜の睡眠時間が、通常時の睡眠時間の６割を確保できていれば（０．６倍以上０．８倍未満）、「３」点であり、昨夜の睡眠時間が、通常時の睡眠時間の６割未満であれば、「５」点である。
【0109】
「血圧」に関するレコードでは、通常時の血圧である基礎生体データの血圧Ｃに対する住人の今日の血圧の変位量（「Ｃ－血圧」の絶対値）に応じて２段階で点数化されている。当該変位量が５ｍｍＨｇ以下である場合、「０」点であり、当該変位量が５ｍｍＨｇを超える場合、「１」点である。なお、今日の血圧とは、上記所定時刻における血圧である。
【0110】
「心拍数」に関するレコードでは、通常時の心拍数である基礎生体データの心拍数Ｄに対する住人の今日の心拍数の変位量（「Ｄ－心拍数」の絶対値）に応じて２段階で点数化されている。当該変位量が７回／分以下である場合、「０」点であり、当該変位量が７回／分を超える場合、「１」点である。なお、今日の心拍数とは、上記所定時刻における心拍数である。
【0111】
「呼吸数」に関するレコードでは、通常時の呼吸数である基礎生体データの呼吸数Ｅに対する住人の今日の呼吸数の変位量（「Ｅ－呼吸数」の絶対値）に応じて２段階で点数化されている。当該変位量が３回／分以下である場合、「０」点であり、当該変位量が３回／分を超える場合、「１」点である。なお、今日の呼吸数とは、上記所定時刻における呼吸数である。
【0112】
生体データ点数化テーブルにより、住人の身体的疲労が数値化される。
【0113】
管理データベースは、図３（Ｂ）に示される判定テーブルを含む。判定テーブルは、調理適格を有する住人の今日の体調を特定して調理担当を決定するためのテーブルである。判定テーブルは、毎日生成或いは更新される。なお、今日の体調とは、上記所定時刻における身体的且つ精神的疲労を意味する。
【0114】
判定テーブルは、「ユーザＩＤ」、「姓名」、「生体データ点数」、「質問回答点数」、「総合点数」、「連続担当フラグ」、「調理担当フラグ」、及び「ヘルプ／出前フラグ」の各名称がそれぞれ付された複数のカラムを有する。
【0115】
「ユーザＩＤ」及び「姓名」の名称が付されたカラムのフィールドは、ユーザ管理データベース（図２（Ａ）参照）と同様に、ユーザＩＤ及び住人の氏名がそれぞれ登録される。
【0116】
「ユーザＩＤ」の「家族」の名称が付されたカラムのフィールドに登録された家族ＩＤにより、各レコードは、家族ごとに識別される。つまり、家族ごとにレコードが生成される。各レコードは、家族に含まれる住人のうち、ユーザ管理データベース（図２（Ａ）参照）の「ウエアラブル」に「１」が登録された住人ごとに生成されたサブレコードを有する。つまり、ウエアラブル端末２０を装着した住人のみが、体調を特定される。なお、ウエアラブル端末２０を装着しない住人についても、サブレコードが生成されてもよい。その場合、ウエアラブル端末２０を装着していない住人については、質問回答のみから体調を特定される。ウエアラブル端末２０を装着していない住人について特定された体調は、調理担当に決定された住人に対して提案される料理の種類の決定に用いられる。
【0117】
「生体データ点数」の名称が付されたカラムは、「体温」、「体温点数」、「睡眠時間」、「睡眠点数」、「血圧」、「血圧点数」、「心拍数」、「心拍点数」、「呼吸数」、及び「呼吸点数」の名称がそれぞれ付されたサブカラムを有する。
【0118】
「体温」の名称が付されたサブカラムは、ウエアラブル端末２０によって取得された住人の体温を登録される。
【0119】
「体温点数」の名称が付されたサブカラムのフィールドは、ウエアラブル端末２０によって取得された住人の体温に基づいて決定された体温点数を登録される。詳しく説明すると、管理サーバ４０の管理プログラム４５は、取得した「住人の今日の体温」と、「当該住人の通常時の体温Ａ」との差の絶対値を算出する。「当該住人の通常時の体温Ａ」は、ユーザ管理データベース（図２（Ａ）参照）に登録された基礎生体データにおける体温である。管理プログラム４５は、算出した「通常時の体温Ａと今日の体温との差の絶対値」と、生体データ点数化テーブルとに基づいて点数を決定し、決定した点数を、「体温点数」の名称が付されたサブカラムのフィールドに登録する。判定テーブルにおける「山田太郎」の例では、基礎生体データの体温が３６．６℃であり、今日の体温が３７．５℃であるから、差の絶対値は０．９℃である。生体データ点数化テーブルにおいて「０．９℃」と対応付けられているのは、「３」点である。
【0120】
「睡眠時間」の名称が付されたサブカラムは、ウエアラブル端末２０によって取得された住人の睡眠時間を登録される。
【0121】
「睡眠点数」の名称が付されたサブカラムのフィールドは、ウエアラブル端末２０によって取得された住人の昨夜の睡眠時間に基づいて決定された睡眠点数を登録される。詳しく説明すると、管理サーバ４０の管理プログラム４５は、住人の通常時の睡眠時間Ｂをユーザ管理データベース（図２（Ａ）参照）から読み出す。管理プログラム４５は、「住人の昨夜の睡眠時間」が、「通常時の住人の睡眠時間」の何割であるかを算出する。管理プログラム４５は、算出した割合と、生体データ点数化テーブルとに基づいて点数を決定し、決定した点数を、「睡眠点数」の名称が付されたサブカラムのフィールドに登録する。判定テーブルにおける「山田太郎」の例では、基礎生体データの睡眠時間が６．５時間であり、昨夜の睡眠時間が５．５時間であるから、「住人の昨夜の睡眠時間」は、「通常時の住人の睡眠時間」の８．４割であり、生体データ点数化テーブルにおいて「８．４割」と対応付けられた点数は「１」点である。
【0122】
「血圧」の名称が付されたサブカラムは、ウエアラブル端末２０によって取得された住人の血圧を登録される。
【0123】
「血圧点数」の名称が付されたサブカラムのフィールドは、ウエアラブル端末２０によって取得された住人の血圧に基づいて決定された血圧点数を登録される。詳しく説明すると、管理サーバ４０の管理プログラム４５は、取得した「住人の今日の血圧」と、「当該住人の通常時の血圧Ｃ」との差の絶対値を算出する。「当該住人の通常時の血圧Ｃ」は、ユーザ管理データベース（図２（Ａ）参照）に登録された基礎生体データにおける血圧である。管理プログラム４５は、算出した「通常時の血圧Ｃと今日の血圧との差の絶対値」と、生体データ点数化テーブルとに基づいて点数を決定し、決定した点数を、「血圧点数」の名称が付されたサブカラムのフィールドに登録する。判定テーブルにおける「山田太郎」の例では、基礎生体データの血圧が１２５ｍｍＨｇであり、今日の血圧が１３５ｍｍＨｇであるから、差の絶対値は１０ｍｍＨｇである。生体データ点数化テーブルにおいて「１０ｍｍＨｇ」と対応付けられているのは、「１」点である。
【0124】
「心拍数」の名称が付されたサブカラムは、ウエアラブル端末２０によって取得された住人の心拍数を登録される。
【0125】
「心拍点数」の名称が付されたサブカラムのフィールドは、ウエアラブル端末２０によって取得された住人の心拍数に基づいて決定された心拍点数を登録される。詳しく説明すると、管理サーバ４０の管理プログラム４５は、取得した「住人の今日の心拍数」と、「当該住人の通常時の心拍数Ｄ」との差の絶対値を算出する。「当該住人の通常時の心拍数Ｄ」は、ユーザ管理データベース（図２（Ａ）参照）に登録された基礎生体データにおける心拍数である。管理プログラム４５は、算出した「通常時の心拍数Ｄと今日の心拍数との差の絶対値」と、生体データ点数化テーブルとに基づいて点数を決定し、決定した点数を、「心拍点数」の名称が付されたサブカラムのフィールドに登録する。判定テーブルにおける「山田太郎」の例では、基礎生体データの心拍数が７２回／分、今日の心拍数が８０回／分であるから、差の絶対値は８回である。生体データ点数化テーブルにおいて「８回」と対応付けられているのは、「１」点である。
【0126】
「呼吸数」の名称が付されたサブカラムは、ウエアラブル端末２０によって取得された住人の呼吸数を登録される。
【0127】
「呼吸点数」の名称が付されたサブカラムのフィールドは、ウエアラブル端末２０によって取得された住人の呼吸数に基づいて決定された呼吸点数を登録される。詳しく説明すると、管理サーバ４０の管理プログラム４５は、取得した「住人の今日の呼吸数」と、「当該住人の通常時の呼吸数Ｅ」との差の絶対値を算出する。「当該住人の通常時の呼吸数Ｅ」は、ユーザ管理データベース（図２（Ａ）参照）に登録された基礎生体データにおける呼吸数である。管理プログラム４５は、算出した「通常時の呼吸数Ｅと今日の呼吸数との差の絶対値」と、生体データ点数化テーブルとに基づいて点数を決定し、決定した点数を、「呼吸点数」の名称が付されたサブカラムのフィールドに登録する。判定テーブルにおける「山田太郎」の例では、基礎生体データの呼吸数が１６回／分、今日の呼吸数が２０回／分であるから、差の絶対値は４回である。生体データ点数化テーブルにおいて「４回」と対応付けられているのは、「１」点である。
【0128】
「質問回答点数」の名称が付されたカラムのフィールドは、住人に対して行なった各質問「気持ち」、「眠気」、「生理」に対する住人の回答と、質問点数化テーブル（図２（Ｄ）参照）とから決定された点数を登録される。
【0129】
「総合点数」の名称が付されたカラムのフィールドは、生体データ点数と、質問回答点数との合計点が登録される。判定テーブルにおける「山田太郎」の例では、生体データ点数が「３」、「１」、「１」、「１」、「１」点であり、質問回答点数が「２」、「１」、「０」点であるから、総合点数は「１０」点である。総合点数は、体調及び体調レベルの一例である。
【0130】
「連続担当フラグ」の名称が付されたカラムのフィールドは、昨日及び一昨日の２日連続で調理担当を行なった住人である場合は「１」を登録され、それ以外では「０」を登録される。管理サーバ４０の管理プログラム４５は、実績管理データベース（図２（Ｂ）参照）に登録されたデータに基づいて、「連続担当フラグ」の名称が付されたカラムのフィールドに「１」または「０」を登録する。なお、ヘルプ者への調理支援の依頼或いは出前の注文がされて、住人が調理を行なっていない場合、住人が調理を行なっていない日を除いて「２日連続」が判断される。例えば、ある住人が、１日前（昨日）と３日前とに調理を行ない、２日前（一昨日）は出前が注文された場合、当該住人に対して、連続担当フラグが登録される。連続担当フラグは、実績データの一例である。
【0131】
「調理担当フラグ」の名称が付されたカラムのフィールドは、今日の調理担当に決定した住人である場合は「１」を登録され、今日の調理担当ではない場合は「０」を登録される。管理サーバ４０の管理プログラム４５は、図５及び図６に示される決定通知登録処理において調理担当を決定し、調理担当に決定した住人に対して「１」を登録し、それ以外の住人に対して「０」を登録する。
【0132】
「ヘルプ／出前フラグ」の名称が付されたカラムのフィールドは、ヘルプ者に対して調理支援の要請をすること、或いは出前を依頼することに決定したことを示す「１」、或いは調理担当を決定したことを示す「０」を登録される。管理サーバ４０の管理プログラム４５は、図５及び図６に示される決定通知登録処理においてヘルプ者への支援要請或いは出前を依頼することに決定した場合に、「ヘルプ／出前フラグ」の名称が付されたカラムのフィールド「１」を登録し、調理担当に決定した場合に「０」を登録する。
【0133】
［調理担当決定システム１０の動作］
以下では、管理サーバ４０及びユーザ端末３０が実行する管理処理（図４参照）について説明がされる。なお、管理処理において管理サーバ４０が実行する各処理（各ステップ）は、管理サーバ４０のＣＰＵ４１が実行する処理であり、且つ管理サーバ４０の管理プログラム４５がＣＰＵ４１に実行させる処理でもある。また、管理処理においてユーザ端末３０が実行する各処理（各ステップ）は、ユーザ端末３０のＣＰＵ３１が実行する処理であり、且つユーザ端末３０のアプリケーションプログラム３９がＣＰＵ３１に実行させる処理でもある。
以下では、管理サーバ４０及びユーザ端末３０が実行する管理処理（図４参照）について説明がされる。なお、管理処理において管理サーバ４０が実行する各処理（各ステップ）は、管理サーバ４０のＣＰＵ４１が実行する処理であり、且つ管理サーバ４０の管理プログラム４５がＣＰＵ４１に実行させる処理でもある。また、管理処理においてユーザ端末３０が実行する各処理（各ステップ）は、ユーザ端末３０のＣＰＵ３１が実行する処理であり、且つユーザ端末３０のアプリケーションプログラム３９がＣＰＵ３１に実行させる処理でもある。
【0134】
図４に示されるように、ウエアラブル端末２０は、生体データを取得し、取得した生体データを端末メモリ２２に一時記憶させる（Ｓ１１）。生体データの取得は、例えば所定の時間間隔で行なわれ、或いは所定時刻ごとに行なわれる。また、ウエアラブル端末２０は、通信インタフェース２３を通じてユーザ端末３０と通信確立（ハンドシェイク）を行った後（Ｓ１２）、取得した生体データをユーザ端末３０に送信する（Ｓ１３）。ステップＳ１２の通信確立は、例えば生体データの取得間隔よりも長い間隔で実行されて、複数回分の生体データがまとめてユーザ端末３０に送信されてもよいし、当該複数回分の生体データの平均値がユーザ端末３０に送信されてもよい。或いは、ウエアラブル端末２０は、ユーザ端末３０の要求に応じて、最も新しい生体データをユーザ端末３０に送信してもよい。つまり、ウエアラブル端末２０は、生体データを定期的に送信してもよいし、必要な場合にのみ生体データを送信してもよい。
【0135】
ユーザ端末３０は、ウエアラブル端末２０が送信した生体データを、通信インタフェース３３を通じて受信する（Ｓ１３）。ステップＳ１３の処理は、生体データ取得処理の一例である。ユーザ端末３０は、生体データ取得処理を毎日行う。毎日は、所定日の一例である。
【0136】
ユーザ端末３０は、受信した生体データを、端末メモリ３２に一時的に記憶させる（Ｓ１４）。また、ユーザ端末３０は、所定時刻になったか否かを判断する（Ｓ１５）。所定時刻は、夕食の調理を開始する時刻よりも所定時間（例えば１時間）だけ前の時刻である。ユーザ端末３０は、所定時刻になるまで（Ｓ１５：Ｎｏ）、ステップＳ１２からＳ１４までの処理を繰り返し実行する。
【0137】
ユーザ端末３０は、所定時刻になったと判断すると（Ｓ１５：Ｙｅｓ）、質問回答画面（図７及び図８参照）をタッチパネル３５に表示させる（Ｓ１６）。具体的には、ユーザ端末３０の端末メモリ３２は、質問回答画面を示す画面データを予め記憶する。当該画面データは、例えばＨＴＭＬデータであり、アプリケーションプログラム３９のダウンロード時に端末メモリ３２に記憶される。ユーザ端末３０は、端末メモリ３２に記憶された画面データをタッチパネル３５に入力することにより、質問回答画面をタッチパネル３５に表示させる。なお、質問回答画面を示す画面データは、サーバメモリ４２に記憶されていてもよい。その場合、ユーザ端末３０は、当該画面データを、インターネット１１を通じて管理サーバ４０から取得する。ステップＳ１６の処理は、質問通知処理の一例である。
【0138】
質問回答画面は、図７（Ａ）に示される第１画面、図７（Ｂ）に示される第２画面、図８（Ａ）に示される第３画面、及び図８（Ｂ）に示される第４画面を含む。ユーザ端末３０は、先ず、図７（Ａ）に示される第１画面をタッチパネル３５に表示させる。
【0139】
第１画面は、「本日の調子を選択してください」の文字と、「次へ」アイコン５０とを有する。ユーザ端末３０を所持する住人は、「次へ」アイコン５０を選択する。
【0140】
【0141】
第２画面は、「本日のお気持ちは？」の文字と、互いに対応付けられたラジオボタン５１及び「問題ない」の文字と、互いに対応付けられたラジオボタン５２及び「しんどい」の文字と、互いに対応付けられたラジオボタン５３及び「立ち直れない」の文字と、「次へ」アイコン５４と、を有する。ユーザ端末３０を所持する住人は、いずれかのラジオボタン５１、５２、５３を選択した後、「次へ」アイコン５４を選択する。
【0142】
【0143】
第３画面は、「本日の日中の眠気は？」の文字と、互いに対応付けられたラジオボタン５５及び「問題ない」の文字と、互いに対応付けられたラジオボタン５６及び「眠かった」の文字と、「次へ」アイコン５７と、を有する。ユーザ端末３０を所持する住人は、いずれかのラジオボタン５５、５６を選択した後、「次へ」アイコン５７を選択する。
【0144】
【0145】
第４画面は、「生理周期」の文字と、互いに対応付けられたラジオボタン５８及び「１－３日目」の文字と、互いに対応付けられたラジオボタン５９及び「それ以外」の文字と、「終了」アイコン６０と、を有する。ユーザ端末３０を所持する住人は、いずれかのラジオボタン５８、５９を選択した後、「終了」アイコン６０を選択する。
【0146】
なお、第４画面がタッチパネル３５に表示されるのは、女性である住人が所持するユーザ端末３０のみである。アプリケーションプログラム３９は、ユーザ端末３０の所持者の性別を端末メモリ３２に予め記憶させており、端末メモリ３２に記憶された性別が女性である場合、第４画面をタッチパネル３５に表示させ、男性である場合、タッチパネル３５に第４画面を表示させない。男性である住人が所持するユーザ端末３０では、第３画面において、「次へ」アイコン５７に代えて「終了」アイコン６０が表示される。
【0147】
ユーザ端末３０が、住人によるラジオボタン５１～５３、５５、５６、５８、５９の選択を受け付けるステップＳ１７の処理は、回答取得処理の一例である。また、ラジオボタン５１～５３、５５、５６、５８、５９は、回答選択肢の一例である。
【0148】
図４に示されるように、ユーザ端末３０は、第３画面或いは第４画面において「終了」アイコン６０が選択されたことに基づいて（Ｓ１７）、回答情報を端末メモリ３２に一時記憶させる（Ｓ１８）。回答情報は、質問に対して住人が選択したラジオボタンを示す情報である。
【0149】
ユーザ端末３０は、端末メモリ３２に一時記憶された生体データ及び回答情報と、端末メモリ３２に予め記憶されたユーザＩＤとを含む送信データを生成する（Ｓ１９）。ユーザ端末３０は、生成した送信データを含むＨＴＴＰリクエストを、通信インタフェース３３或いは通信インタフェース３４、及びインターネット１１を通じて管理サーバ４０に送信する（Ｓ２０）。以下では、通信インタフェース３３或いは通信インタフェース３４を、通信インタフェース３３等とも称する。ステップＳ２０の処理は、生体データ送信処理の一例である。
【0150】
管理サーバ４０は、ユーザ端末３０が送信したＨＴＴＰリクエストを受信する（Ｓ２０）。管理サーバ４０は、ＨＴＴＰリクエストを受信したことを示すＡＣＫ（肯定応答）を含むＨＴＴＰレスポンスを、通信インタフェース４３及びインターネット１１を通じてユーザ端末３０に返信する（Ｓ２１）。管理サーバ４０が、質問回答及び生体データを含むＨＴＴＰリクエストを受信するステップＳ２０の処理は、回答取得処理及び生体データ取得処理の一例である。
【0151】
管理サーバ４０は、ステップＳ２０において受信した送信情報に含まれるユーザＩＤと一致するユーザＩＤを有するレコードを、ユーザ管理データベース（図２（Ａ）参照）において特定する。管理サーバ４０は、特定したレコードに登録されたデータを読み出し、サーバメモリ４２における演算処理領域に一時記憶させる（Ｓ２２）。
【0152】
管理サーバ４０は、ステップＳ２２において読み出した基礎生体データと、ステップＳ２０で受信した生体データと、生体データ点数化テーブル（図３（Ａ）参照）とに基づいて、住人の生体データを点数化する（Ｓ２３）。管理サーバ４０は、生体データに関する点数を、判定テーブル（図３（Ｂ）参照）に登録する（Ｓ２３）。例えば、判定テーブルにおける姓名「山田太郎」について、体温点数「３」点、睡眠点数「１」点、血圧点数「１」点、心拍点数「１」点、呼吸点数「１」点が判定テーブルに登録される。なお、生体データに関する点数は、主に住人の身体的な疲労度を示し、点数が高い程、住人の身体的疲労が高く、点数が低いほど、住人の身体的疲労が低い。住人の身体的疲労が高いことは、体調が悪いことを示し、住人の身体的疲労が低いことは、体調が良いことを示す。
【0153】
また、管理サーバ４０は、ステップＳ２０で受信した回答情報と、質問点数化テーブル（図２（Ｄ）参照）とに基づいて、質問に対する住人の回答を点数化する（Ｓ２４）。管理サーバ４０は、質問回答に関する点数を、判定テーブル（図３（Ｂ）参照）に登録する（Ｓ２４）。例えば、判定テーブルにおける姓名「山田太郎」について、気持ち「２」点、眠気「１」点、生理「０」点が判定テーブルに登録される。なお、質問回答に関する点数は、住人の精神的な疲労度を示し、点数が高い程、住人の精神的疲労が高く、点数が低いほど、住人の精神的疲労が低い。精神的疲労が高いことは、調子が悪いことを示し、精神的疲労が低いことは、調子が良いことを示す。
【0154】
管理サーバ４０は、ステップＳ２３において算出した生体データに関する点数と、ステップＳ２４において算出した質問回答に関する点数とを加算して総合点数を算出する（Ｓ２５）。管理サーバ４０は、算出した総合点数を、判定テーブル（図３（Ｂ）参照）に登録する（Ｓ２５）。総合点数を算出して判定テーブルに登録するステップＳ２２からＳ２５までの処理は、体調特定処理の一例である。
【0155】
また、管理サーバ４０は、ステップＳ２０で受信したユーザＩＤのうちの家族部分である家族ＩＤと一致する家族ＩＤを有するレコードを特定し、昨日の調理担当となった住人のユーザＩＤ及び一昨日の調理担当となった住人のユーザＩＤを読み出す。管理サーバ４０は、読み出した２つのユーザＩＤが一致した場合、２日連続で調理担当を行なった住人として、判定テーブルにおいて当該住人のユーザＩＤと一致するユーザＩＤを有するレコードに、「１」の連続担当フラグを登録し、それ以外の住人のレコードについては、「０」の連続担当フラグを登録する（Ｓ２６）。
【0156】
管理サーバ４０は、総合点数及び連続担当フラグに基づいて、調理担当を決定し、或いはヘルプ／出前に決定して通知及び登録を行う決定通知登録処理を実行する（Ｓ２７）。
【0157】
【0158】
図５に示されるように、管理サーバ４０は、判定テーブル（図３（Ｂ）参照）において、調理適格を有する住人の全員の総合点数が５点以上であるか否かを判断する（Ｓ３１）。総合点数の「５点」は、閾値レベルの一例である。
【0159】
管理サーバ４０は、調理適格を有する全住人の総合点数が５点以上であると判断すると（Ｓ３１：Ｙｅｓ）、当該全住人が質問回答において「立ち直れない」を選択しているか否かを判断する（Ｓ３２）。ステップＳ３２の判断は、判定テーブルにおいて「気持ち」に５点が登録されているか否かによって判断される。
【0160】
管理サーバ４０は、調理適格を有する全住人が質問回答において「立ち直れない」を選択していると判断すると（Ｓ３２：Ｙｅｓ）、ステップＳ２２においてユーザ管理データベースから読み出したレコードにヘルプ者情報（図２（Ａ）参照）が登録されているか否かを判断する（Ｓ３３）。つまり、ステップＳ３３では、対象の家族について、調理支援を要請し得るヘルプ者が存在するか否かが判断される。
【0161】
管理サーバ４０は、ヘルプ者情報が登録されていると判断すると（Ｓ３３：Ｙｅｓ）、ユーザ管理データベース（図２（Ａ）参照）からヘルプ者情報を読み出す（Ｓ３４）。一方、各住人がそれぞれ所持するユーザ端末３０（アプリケーションプログラム３９）は、問い合わせ情報を含むＨＴＴＰリクエストを、通信インタフェース３３等及びインターネット１１を通じて管理サーバ４０に定期的にそれぞれ送信する（Ｓ３５）。管理サーバ４０は、受信したＨＴＴＰリクエストに対する応答として、ステップＳ３４において読み出したヘルプ者情報を含むＨＴＴＰレスポンスを、通信インタフェース４３及びインターネット１１を通じてユーザ端末３０に送信する（Ｓ３６）。ヘルプ者情報は、住人に対して通知される提案の一例である。ヘルプ者情報に含まれるヘルプ者の住所や電話番号やメールアドレスは、連絡情報の一例である。
【0162】
なお、ヘルプ者情報を送信するユーザ端末３０は、代表者としてユーザ管理データベースに予め登録された住人が所持するユーザ端末３０であってもよいし、調理適格を有する住人が所持するユーザ端末３０であってもよいし、総合点数が最も低い（最も体調が良い）住人が所持するユーザ端末３０であってもよいし、全てのユーザ端末３０であってもよい。
【0163】
ユーザ端末３０は、通信インタフェース３３等を通じてＨＴＴＰレスポンスを受信する（Ｓ３６）。ユーザ端末３０は、受信したＨＴＴＰレスポンスに含まれるヘルプ者情報に基づいてヘルプ送信フォーマットを生成し、タッチパネル３５に表示させる（Ｓ３７）。詳しく説明すると、ユーザ端末３０の端末メモリ３２は、アプリケーションプログラム３９のダウンロード時に、ヘルプ依頼画面のフォーマットデータを記憶する。ユーザ端末３０は、当該フォーマットデータの入力フィールドに、ステップＳ３６において受信したヘルプ者情報（ヘルプ者の姓名）を入力してヘルプ依頼画面データを生成し、ヘルプ依頼画面（図９（Ａ）参照）をタッチパネル３５に表示させる。
【0164】
図９（Ａ）に示されるように、ヘルプ依頼画面は、「全員が体調不良です」の文字と、「００様に調理支援を依頼しますか？」の文字と、「依頼する」アイコン６１と、「依頼しない」アイコン６２と、を有する。ステップＳ３７の処理は、通知処理の一例である。ヘルプ依頼画面が表示されたユーザ端末３０の所持者（住人）は、支援を依頼する場合、「依頼する」アイコン６１を選択し（図５のＳ３８）、支援を依頼しない場合、「依頼しない」アイコン６２を選択する（図５のＳ３８）。
【0165】
図５に示されるように、ユーザ端末３０は、住人が「依頼する」アイコン６１を選択した場合、ステップＳ３６において受信したヘルプ者情報を用いて、調理支援を依頼することを示す情報をヘルプ者が所持する通信端末に送信する（Ｓ３９）。なお、調理支援の依頼に代えて、レトルト食品等の買い出しの依頼などがヘルプ者に送信されてもよい。調理支援の依頼を受けたヘルプ者は、当該依頼を受け入れ、或いは断る。
【0166】
ユーザ端末３０は、調理支援を依頼することを示す情報を送信した後、ヘルプ確認画面（図９（Ｂ）参照）をタッチパネル３５に表示させる（Ｓ４０）。ヘルプ確認画面は、ヘルプ者が調理支援を受諾したか断ったかを確認するための画面である。
【0167】
図９（Ｂ）に示されるように、ヘルプ確認画面は、「００様の調理支援を受けることができますか？」の文字と、「受けられる」アイコン６３と、「受けられない」アイコン６４と、を有する。ユーザ端末３０の所持者（住人）は、ヘルプ者が調理支援の要請を受け入れた場合、「受けられる」アイコン６３を選択し（図５のＳ４１）、ヘルプ者が調理支援の要請を断った場合、或いは返事を受けることができなかった場合、「受けられない」アイコン６４を選択する（図５のＳ４１）。
【0168】
ユーザ端末３０は、ヘルプ者の調理支援を受けることができるか否かを示すヘルプ通知情報を含むＨＴＴＰリクエストを生成し、生成したＨＴＴＰリクエストを、通信インタフェース３３等及びインターネット１１を通じて管理サーバ４０に送信する（Ｓ４２）。
【0169】
管理サーバ４０は、通信インタフェース４３を通じてＨＴＴＰリクエストを受信する（Ｓ４２）。管理サーバ４０は、ステップＳ４２で受信したヘルプ通知情報が、ヘルプ者が調理支援を受諾したことを示すか否かを判断する（Ｓ４３）。管理サーバ４０は、ヘルプ者が調理支援を受諾したと判断すると（Ｓ４３：Ｙｅｓ）、「１」のヘルプ／出前フラグを判定テーブル（図３（Ｂ）参照）に登録し、且つ実績管理データベースにおける「調理担当」の名称が付されたカラムのフィールドに、「０」を登録し（Ｓ４４）、決定通知登録処理（図４のＳ２７）を終了する。他方、管理サーバ４０は、ヘルプ者が調理支援を断ったと判断すると（Ｓ４３：Ｎｏ）、ステップＳ２２においてユーザ管理データベース（図２（Ａ）参照）から読み出した出前店情報を含むＨＴＴＰレスポンスを、ステップＳ４２において受信したＨＴＴＰリクエストに対する応答として、通信インタフェース４３及びインターネット１１を通じてユーザ端末３０に返信する（Ｓ４５）。出前店情報は、住人に対して通知される提案の一例である。出前店情報に含まれる電話番号やメールアドレスやＵＲＬは、連絡情報の一例である。
【0170】
ユーザ端末３０は、出前店情報を含むＨＴＴＰレスポンスを、通信インタフェース３３等を通じて受信する（Ｓ４５）。ユーザ端末３０は、受信した出前店情報を有する出前店表示画面（不図示）を、タッチパネル３５に表示させる（Ｓ４６）。出前店表示画面は、店舗名、料理名、及び金額を示す文字と、「ＯＫ」アイコンとを有する。ステップＳ４６の処理は、通知処理の一例である。住人は、タッチパネル３５に表示された出前店のなかから、出前店及び料理を選択して、注文を行う。住人は、出前店名や料理名等を確認した後、「ＯＫ」アイコンを選択する（Ｓ４７）。
【0171】
ユーザ端末３０は、出前店表示画面において「ＯＫ」アイコンが選択されたことに基づいて、出前が注文されたことを示す出前情報を含むＨＴＴＰリクエストを、通信インタフェース３３等及びインターネット１１を通じて管理サーバ４０に送信する（Ｓ４８）。
【0172】
管理サーバ４０は、通信インタフェース４３を通じてＨＴＴＰリクエストを受信する（Ｓ４８）。なお、図５には示されていないが、管理サーバ４０は、ＨＴＴＰリクエストを受信したことを示すＡＣＫ（肯定応答）を含むＨＴＴＰレスポンスを、通信インタフェース４３及びインターネット１１を通じてユーザ端末３０に返信する。
【0173】
管理サーバ４０は、ステップＳ４８において、出前通知情報を受信したことに基づいて、「１」のヘルプ／出前フラグを判定テーブル（図３（Ｂ）参照）に登録し、且つ実績管理データベースにおける「調理担当」の名称が付されたカラムのフィールドに、「０」を登録し（Ｓ４４）、決定通知登録処理（図４のＳ２７）を終了する。
【0174】
管理サーバ４０は、ステップＳ３３において、ヘルプ者情報がユーザ管理データベース（図２（Ａ）参照）に登録されていないと判断すると（Ｓ３３：Ｎｏ）、ステップＳ２２においてユーザ管理データベースから読み出した出前店情報を含むＨＴＴＰレスポンスを、ステップＳ３５において受信したＨＴＴＰリクエストに対する応答としてユーザ端末３０に返信する（Ｓ４５）。出前店情報を含むＨＴＴＰレスポンスを返信されるユーザ端末３０は、代表者としてユーザ管理データベースに予め登録された住人が所持するユーザ端末３０であってもよいし、調理適格を有する住人が所持するユーザ端末３０であってもよいし、総合点数が最も低い（最も体調が良い）住人が所持するユーザ端末３０であってもよいし、全てのユーザ端末３０であってもよい。
【0175】
このように、全住人が「立ち直れない」を選択している場合であって（Ｓ３２：Ｙｅｓ）、ヘルプ者が登録されている場合は（Ｓ３３：Ｙｅｓ）、ヘルプ者への調理支援が住人に提案され、ヘルプ者が登録されていない場合は（Ｓ３３：Ｎｏ）、出前店への注文が住人に提案される。また、全住人の体調が悪いが（Ｓ３１：Ｙｅｓ）、１人でも「立ち直れない」を選択していない住人がいる場合は、当該住人に、出前店への注文が提案される。
【0176】
管理サーバ４０は、ステップＳ３２において、全住人が「立ち直れない」との回答を選択していないと判断すると（Ｓ３２：Ｎｏ）、すなわち、１人でも「立ち直れない」との回答を選択していない住人がいると判断すると、ステップＳ２２においてユーザ管理データベースから読み出した出前店情報を含むＨＴＴＰレスポンスを、ステップＳ３５において受信したＨＴＴＰリクエストに対する応答としてユーザ端末３０に返信する（Ｓ４５）。なお、出前店情報を含むＨＴＴＰレスポンスを返信されるユーザ端末３０は、「立ち直れない」との回答を選択していない住人が所持するユーザ端末３０である。ただし、出前店情報を含むＨＴＴＰレスポンスを返信されるユーザ端末３０は、代表者としてユーザ管理データベースに予め登録された住人が所持するユーザ端末３０であってもよいし、調理適格を有する住人が所持するユーザ端末３０であってもよいし、総合点数が最も低い（最も体調が良い）住人が所持するユーザ端末３０であってもよいし、全てのユーザ端末３０であってもよい。
【0177】
図５及び図６に示されるように、管理サーバ４０は、ステップＳ３１において、調理適格を有する全住人の全総合点数が５点以上でないと判断すると（Ｓ３１：Ｎｏ）、すなわち、１人でも総合点数が５点未満（４点以下）の住人がいると判断すると、調理適格を有する住人のうち、総合点数が最も低い住人を特定する（Ｓ５１）。特定された住人は、調理適格を有し、かつ総合点数が５点未満（４点以下）の住人（以下、「体調良好者」とも称する）である。
【0178】
図６に示されるように、管理サーバ４０は、体調良好者が２人以上いるか否かを判断する（Ｓ５２）。管理サーバ４０は、体調良好者が２人以上いると判断すると（Ｓ５２：Ｙｅｓ）、当該体調良好者について、昨日及び一昨日の２日連続で調理担当であったか否かを判断する（Ｓ５３）。具体的には、管理サーバ４０は、連続担当フラグが判定テーブル（図３（Ｂ）参照）に登録されているか否かによって、２日連続で調理担当であったか否かを判断する。管理サーバ４０は、２日連続で調理担当であった住人（体調良好者）を、ステップＳ５１で特定した住人から除外する（Ｓ５４）。つまり、２日連続で調理担当に決定された住人は、体調が良い場合であっても、次の調理担当の選択から除外される。
【0179】
管理サーバ４０は、体調良好者のうち、過去の調理頻度が最も低い住人を調理担当に決定する（Ｓ５５）。過去の調理頻度は、例えば、今日（本日）から所定期間前までに調理を行なった回数である。所定期間は、例えば１日である。つまり、体調良好者のうち、昨日調理を行なっていない住人が調理担当に決定される。或いは、所定期間は１月である。つまり、過去１月の調理回数が最も少ない住人が、調理担当に決定される。したがって、調理適格を有す住人間の公平性が保たれる。昨日の調理担当或いは前月の調理担当回数（過去の調理頻度）は、過去の調理実績の一例である。ステップＳ５５の処理は、調理担当決定処理の一例である。
【0180】
次に管理サーバ４０は、調理担当に決定した住人の体調（総合点数）と、他の住人の体調（総合点数）とに基づいて、調理担当に提案する調理のメニューである推奨メニューを決定する（Ｓ５６）。推奨メニューは、例えば複数の料理の料理名である。ステップＳ５６の処理は、メニュー決定処理の一例である。
【0181】
詳しく説明すると、管理サーバ４０は、調理担当に決定した住人の総合点数が所定点数（例えば４点）以下であって当該住人の体調が良いか否かを判断する。管理サーバ４０は、調理担当に決定した住人の総合点数が４点以下であって体調が良いと判断すると、調理レベルに「１」を登録された料理（しっかりメニュー）を、調理データベースからピックアップする。
【0182】
次に、管理サーバ４０は、調理担当に決定した住人以外の全住人（料理を食べる住人）の総合点数に基づいて、ピックアップした料理から、料理を食べる住人の体調に合わせた料理をさらにピックアップする。例えば、料理を食べる全住人の総合点数が４点以下であって体調が良いと判断すると、総合点数として「４点以下」を登録された「回鍋肉」などの料理がピックアップされる。料理を食べる住人の１人の総合点数が４点以上であって体調が悪いと判断すると、総合点数として「５点以下」を登録された「雑炊」などの料理がピックアップされる。
【0183】
管理サーバ４０は、調理担当に決定した住人のユーザＩＤと、推奨メニューと、他の住人のユーザＩＤ及び総合点数（体調）と、を含むＨＴＴＰレスポンスを生成する。管理サーバ４０は、生成したＨＴＴＰレスポンスを、通信インタフェース４３及びインターネット１１を通じて、各住人のユーザ端末３０に、ステップＳ３５で受信したＨＴＴＰリクエストに対する応答としてそれぞれ送信する（Ｓ５７）。なお、当該ＨＴＴＰレスポンスは、調理適格者が所持するユーザ端末３０のみに送信されてもよい。ステップＳ５７の処理は、調理担当送信処理の一例である。
【0184】
ユーザ端末３０は、管理サーバ４０が送信したＨＴＴＰレスポンスを、通信インタフェース３３等を通じて受信する（Ｓ５７）。ユーザ端末３０は、受信したユーザＩＤ、推奨メニュー、及び総合点数に基づいて、調理担当通知画面（図１０及び図１１）をタッチパネル３５に表示させる（Ｓ５８）。ステップＳ５８の処理は、通知処理の一例である。
【0185】
詳しく説明すると、ユーザ端末３０の端末メモリ３２は、アプリケーションプログラム３９のダウンロード時に、調理担当通知画面のフォーマットデータを記憶する。当該フォーマットデータは、調理担当に決定された住人用のデータと、それ以外の住人のデータとを含む。ユーザ端末３０は、ＨＴＴＰレスポンスに含まれるユーザＩＤ等の各データに基づいて、フォーマットデータの入力フィールドに入力するデータを生成し、調理担当通知画面を示す画面データを生成する。ユーザ端末３０は、生成した画面データをタッチパネル３５に入力して調理担当通知画面をタッチパネル３５に表示させる。
【0186】
図１０（Ａ）は、調理担当に決定された住人のユーザ端末３０のタッチパネル３５に表示される第１調理担当通知画面を示す。第１調理担当通知画面は、「本日の夕食の調理担当は、あなたです。」の文字と、「お義母様は、体調不良です。」の文字と、「次へ」アイコン６５と、を有する。なお、「お義母様は、体調不良です。」の文字は、例えば総合点数が５点以上の住人がいる場合に表示される。調理担当に決定された住人は、自分が調理担当に決定されたこと、及び体調の悪い住人がいることを、第１調理担当通知画面によって認識する。調理担当に決定された住人は、これらの事項を確認した後、「次へ」アイコン６５を選択する。ユーザ端末３０は、「次へ」アイコン６５が選択されたことに基づいて、図１０（Ｂ）に示されるメニュー推奨画面をタッチパネル３５に表示させる。
【0187】
図１０（Ｂ）に示されるメニュー推奨画面は、「お義母様が体調不良のため、お義母様用に、以下のメニューをお勧めします。」の文字と、候補のメニュー（料理名）と、「ＯＫ」アイコン６６と、を有する。調理担当に決定された住人は、推奨されたメニューの中から、夕食のメニューを選択し、「ＯＫ」アイコン６６を選択する（図６のＳ５９）。
【0188】
図１１（Ａ）は、調理担当に決定された住人以外の住人のユーザ端末３０のタッチパネル３５に表示される第２調理担当通知画面を示す。第２調理担当通知画面は、「本日の夕食の調理担当は、山田太郎さんです。」の文字と、「家族全員の体調は、良好です。」の文字と、「しっかりメニューをお勧めします。」の文字と、「次へ」アイコン６７と、を有する。調理担当に決定された住人以外の住人は、調理担当に決定された住人の名前や、体調の悪い住人がいることや、家族全員の体調が良いことなどを第２調理担当通知画面によって認識する。調理担当に決定された住人以外の住人は、これらの事項を確認した後、「次へ」アイコン６６を選択する。ユーザ端末３０は、「次へ」アイコン６７が選択されたことに基づいて、図１１（Ｂ）に示されるメニュー推奨画面をタッチパネル３５に表示させる。
【0189】
図１１（Ｂ）に示されるメニュー推奨画面は、「推奨メニュー」の文字と、推奨メニュー（料理名）と、「ＯＫ」アイコン６８と、を有する。調理担当に決定された住人以外の住人は、推奨メニューの中から特に食べたい希望の料理があれば、調理担当に決定された住人に、希望する料理を知らせる。調理担当に決定された住人は、例えば、図１０（Ｂ）に表示された推奨メニューの中から、家族が希望する料理を選択して「ＯＫ」アイコン６６を選択する（図６のＳ５９）。なお、図１１（Ｂ）に示されるメニュー推奨画面において、調理担当に決定された住人以外の住人が「ＯＫ」アイコン６８を選択すると、ユーザ端末３０は、メニュー推奨画面の表示を終了させる。
【0190】
図６に示されるように、ユーザ端末３０は、メニュー推奨画面（図１０（Ｂ）参照）において住人による「ＯＫ」アイコン６６の選択を受け付けたことに基づいて、調理担当に決定された住人が選択したメニュー（料理名）を有する通知情報を含むＨＴＴＰリクエストを、通信インタフェース３３等及びインターネット１１を通じて管理サーバ４０に送信する（Ｓ６０）。
【0191】
管理サーバ４０は、ユーザ端末３０が送信したＨＴＴＰリクエストを、通信インタフェース４３を通じて受信する（Ｓ６０）。管理サーバ４０は、ステップＳ５５において決定した調理担当の住人のユーザＩＤと、ステップＳ６０で受信したメニュー（料理名）とを、実績管理データベース（図２（Ｂ）参照）に登録し（Ｓ６１）、決定通知登録処理（図４のＳ２７）を終了する（リターン）。なお、図２（Ｂ）では、調理担当となった住人が選択したメニュー（料理名）の表示が省略されている。実績管理データベースに登録されたメニューは、例えばステップＳ５６における推奨メニューの決定に用いられる。例えば、管理サーバ４０は、ピックアップしたメニュー（料理名）のうち、過去の調理回数が少ない料理名或いは多い料理名（得意料理）を上位にして、調理担当に決定した住人のユーザ端末３０に表示させる。ステップＳ６１の処理は、記憶処理の一例である。実績データベースに登録されるユーザＩＤ及びメニュー（料理名）は、実績データの一例である。
【0192】
このように、最も体調の良い者が２人以上いる場合は（Ｓ５２：Ｙｅｓ）、２日連続で調理を行なっていない住人を除外し（Ｓ５４）、残った住人のうち、調理頻度が低い住人が調理担当に決定される（Ｓ５５）。
【0193】
管理サーバ４０は、ステップＳ５２において、総合点数の一番低い住人が１人だけであると判断すると（Ｓ５２：Ｎｏ）、総合点数の一番低い住人が、昨日及び一昨日の２日連続で調理担当を行なったか否かを判断する（Ｓ６２）。当該判断は、判定テーブル（図３（Ｂ）参照）に登録された連続調理フラグに基づいて行なわれる。
【0194】
管理サーバ４０は、総合点数の一番低い住人（以下、「特定者」とも称する。）が、昨日及び一昨日の２日連続で調理担当を行なった者でないと判断すると（Ｓ６２：Ｎｏ）、特定者を調理担当に決定する（Ｓ６３）。その後、管理サーバ４０及びユーザ端末３０は、上述したステップＳ５６からＳ６１までの処理を実行し、決定通知登録処理（図４のＳ２７）を終了する（リターン）。ステップＳ６３の処理は、調理担当決定処理の一例である。
【0195】
管理サーバ４０は、ステップＳ６２において、特定者が２日連続で調理担当を行なったと判断すると（Ｓ６２：Ｙｅｓ）、特定者以外の全住人が、質問に対して「立ち直れない」の回答選択肢を選択したか否かを判断する（Ｓ６４）。管理サーバ４０は、特定者以外の全住人が、質問に対して「立ち直れない」の回答選択肢を選択したと判断すると（Ｓ６４：Ｙｅｓ）、特定者を調理担当に決定する（Ｓ６３）。つまり、特定者以外の全住人が、「立ち直れない」の回答選択肢を選択している場合、特定者が２日連続で調理担当を行なった場合であっても、例外的に特定者を調理担当に決定する。
【0196】
管理サーバ４０は、ステップＳ６４において、特定者以外に「立ち直れない」の回答選択肢を選択していない住人がいると判断すると（Ｓ６４：Ｎｏ）、「立ち直れない」の回答選択肢を選択していない住人（２番目に総合点数が低い住人）を調理担当に決定する（Ｓ６５）。その後、管理サーバ４０は、上述したステップＳ５６からＳ６１までの処理を実行し、決定通知登録処理（図４のＳ２７）を終了する（リターン）。なお、２番目に総合点数が低い住人が２人以上いる場合、管理サーバ４０は、過去の調理実績に基づいて調理担当を決定する。例えば管理サーバ４０は、先月の調理担当回数が低い方の住人を調理担当に決定する。
【0197】
このように、最も体調の良い者が２日連続で調理担当でなかった場合、調理担当に決定され（Ｓ６２：Ｎｏ→Ｓ６３）、最も体調の良い者が２日連続で調理担当であった場合（Ｓ６２：Ｙｅｓ）、他の住人が「立ち直れない」を選択している場合にのみ例外的に調理担当に決定される（Ｓ６４：Ｙｅｓ→Ｓ６３）。そして、最も体調の良い者が２日連続で調理担当であり（Ｓ６２：Ｙｅｓ）、かつ他の住人のうちの１人でも「立ち直れない」を選択していない場合、当該住人が調理担当に決定される（Ｓ６４：Ｎｏ→Ｓ６５）。
【0198】
［実施形態の作用効果］
本実施形態では、管理サーバ４０は、夕食の調理開始前の所定時刻における調理適格を有する各住人の体調（身体的疲労）を生体データに基づいてそれぞれ特定し、特定した各住人の体調に基づいて、今日（所定日）の食事の調理担当を決定して住人に通知する。したがって、調理担当決定システム１０は、体調の悪い住人に調理を行なわせてしまうことを防止することができる。
本実施形態では、管理サーバ４０は、夕食の調理開始前の所定時刻における調理適格を有する各住人の体調（身体的疲労）を生体データに基づいてそれぞれ特定し、特定した各住人の体調に基づいて、今日（所定日）の食事の調理担当を決定して住人に通知する。したがって、調理担当決定システム１０は、体調の悪い住人に調理を行なわせてしまうことを防止することができる。
【0199】
本実施形態では、調理担当に決定された住人のユーザＩＤは、日付と対応付けて実績データ管理データベースに登録される。そして、実績データ管理データベースに登録されたユーザＩＤに基づいて生成された連続担当フラグに基づいて、調理担当が決定される。したがって、調理適格を有する住人間において調理の分担の公平性が保たれる。
【0200】
本実施形態では、生体データからでは特定することが難しい精神的疲労を、住人に対する質問の回答により特定している。したがって、調理担当決定システム１０は、調理適格を有する住人の身体的疲労だけでなく、精神的疲労も考慮して今日の調理担当を決定することができる。
【0201】
本実施形態では、質問点数化テーブルにおいて、質問に対する回答選択肢（ラジオボタン５１～５３、５５、５６、５８、５９）が点数と対応付けられている。したがって、調理担当決定システム１０は、住人の精神的疲労を数値によって特定することができる。
【0202】
本実施形態では、住人の体調（身体的疲労）は、基礎生体データに対する生体データの変位量に基づいて特定される。したがって、調理担当決定システム１０は、住人の体調を数値として特定することができる。
【0203】
本実施形態では、調理担当に決定された住人の体調に合わせた調理レベル（簡単調理／しっかり調理）のメニューが当該住人に推奨される。したがって、調理担当決定システム１０は、調理担当に決定された住人の体調が悪い場合、当該住人の調理の負担を低減することができる。
【0204】
本実施形態では、調理担当に決定された住人以外の住人の体調に応じた種類のメニューが決定され、調理担当に通知される。しがって、調理担当決定システム１０は、体調が悪い住人に、お粥や湯豆腐など消化のよい料理を食べさせることができる。
【0205】
本実施形態では、調理適格を有する全住人の体調が悪い場合、調理担当が決定されず、ヘルプ者への調理支援の依頼、或いは出前をとることなどの提案が住人に対してされる。したがって、調理担当決定システム１０は、体調の悪い住人に調理をさせてしまうことを防止することができる。
【0206】
本実施形態では、ヘルプ者の連絡先或いは出前店の連絡先が住人に通知される。したがって、調理担当決定システム１０は、住人におけるヘルプ者への調理支援依頼及び出前の注文を容易にすることができる。
【0207】
［変形例］
実施形態では、調理担当決定システム１０が管理サーバ４０を備える例が説明された。しかしながら、調理担当決定システム１０は、データ収集機能を必要とされない場合、管理サーバ４０に代えて、住宅に設置されるパーソナルコンピュータ（いわゆるＰＣ）を備えていてもよい。つまり、調理担当決定システム１０は、外部のサーバとは切り離されたスタンドアローンのシステムであってもよい。当該ＰＣは、例えば住人が所持するＰＣであり、或いは住宅の管理用にサービス提供者が住宅に設置したＰＣである。当該ＰＣは、管理プログラム４５と同等の処理を実行するプログラムを実装される。当該ＰＣは、住宅に付設されたＬＡＮを通じて、或いは直接、ユーザ端末３０やウエアラブル端末２０と通信を行う。当該ＰＣは、情報処理装置の一例である。
実施形態では、調理担当決定システム１０が管理サーバ４０を備える例が説明された。しかしながら、調理担当決定システム１０は、データ収集機能を必要とされない場合、管理サーバ４０に代えて、住宅に設置されるパーソナルコンピュータ（いわゆるＰＣ）を備えていてもよい。つまり、調理担当決定システム１０は、外部のサーバとは切り離されたスタンドアローンのシステムであってもよい。当該ＰＣは、例えば住人が所持するＰＣであり、或いは住宅の管理用にサービス提供者が住宅に設置したＰＣである。当該ＰＣは、管理プログラム４５と同等の処理を実行するプログラムを実装される。当該ＰＣは、住宅に付設されたＬＡＮを通じて、或いは直接、ユーザ端末３０やウエアラブル端末２０と通信を行う。当該ＰＣは、情報処理装置の一例である。
【0208】
実施形態では、調理担当決定システム１０が管理サーバ４０を備え、管理サーバ４０が調理担当を決定する例が説明された。しかしながら、調理担当決定システム１０が管理サーバ４０を備えず、ユーザ端末３０及びウエアラブル端末２０のみで構成されていてもよい。その場合、管理プログラム４５が実行する処理は、ユーザ端末３０のアプリケーションプログラム３９が実行する。また、ユーザ管理データベース等の管理データベースは、アプリケーションプログラム３９のダウンロード時に、ユーザ端末３０の端末メモリ３２に記憶される。端末メモリ３２に記憶される管理データベースは、１つの家族のみを管理するデータベースとなる。この場合、ユーザ端末３０のＣＰＵ３１は、制御装置の一例である。
【0209】
実施形態では、ユーザ端末３０が備えるタッチパネル３５及びスピーカ３６が通知装置の一例である場合が説明された。しかしながら、通知装置は、住宅に設置されたモニタ（ディスプレイ）やスピーカなどであってもよい。
【0210】
実施形態では、生体センサの一例としてウエアラブル端末２０が説明された。しかしながら、住人の生体データを取得可能であれば、ウエアラブルセンサ２０に代えて、設置型の生体センサなど、他の生体センサが用いられてもよい。
【0211】
実施形態では、ウエアラブル端末２０が、温度センサ２５、光センサ２６、加速度センサ２７、及び生体電位センサ２８を備える例が説明された。しかしながら、ウエアラブル端末２０は、温度センサ２５、光センサ２６、加速度センサ２７、及び生体電位センサ２８以外のセンサを備えていてもよい。またウエアラブル端末２０は、温度センサ２５、光センサ２６、加速度センサ２７、及び生体電位センサ２８のうちの一部のセンサを備えていなくてもよい。
【0212】
実施形態では、住人の体調を特定するための生体データが、体温、睡眠時間、血圧、心拍数、及び呼吸数である例が説明された。しかしながら、住人の体調を特定するための生体データは、体温、睡眠時間、血圧、心拍数、及び呼吸数以外の生体データであってもよい。また、生体データは、体温、睡眠時間、血圧、心拍数、及び呼吸数のうちの一部であってもよい。つまり、管理サーバ４０が取得する住人の生体データの種類は、住人の体調を特定可能であれば、どのような種類の生体データであってもよい。
【0213】
実施形態では、ウエアラブル端末２０が、取得した生体データをユーザ端末３０に送信する例が説明された。しかしながら、ウエアラブル端末２０は、取得した生体データを、通信インタフェース２３及びインターネット１１を通じて管理サーバ４０に直接送信してもよい。
【0214】
実施形態では、ウエアラブル端末２０とユーザ端末３０とが別個の装置である例が説明された。しかしながら、ウエアラブル端末２０とユーザ端末３０とが１つの装置であってもよい。
【0215】
実施形態では、生体データ及び質問回答に基づいて、調理適格を有する住人の体調を特定する例が説明された。しかしながら、調理適格を有する住人の体調は、生体データのみから特定されてもよい。つまり、調理適格を有する住人の体調は、身体的疲労のみで特定さてもよい。
【0216】
実施形態では、特定した今日の住人の体調と、過去の調理実績とに基づいて調理担当を決定する例が説明された。しかしながら、特定した今日の住人の体調のみに基づいて調理担当が決定されてもよい。例えば、体調の最も良い（総合点数の最も低い）住人が調理担当に決定され、体調の最も良い住人が複数いる場合、当該住人のいずれを調理担当にするかを当該住人に選択させてもよい。
【0217】
実施形態では、質問に対する回答選択肢が点数と対応付けられて質問回答が点数化される例が説明された。しかしながら、回答選択肢の複数の組合せに順位を付けて、住人の精神的疲労度を数値化するのではなく、精神的疲労に関する順位付けを住人に対して行なってもよい。例えば、「立ち直れない」、「眠かった」、「１－３日目」を選択した住人の順位を１位とし、「問題なし」、「問題なし」、「その他」を選択した住人の順位を最下位として、各住人に精神的疲労に関する順位付けをしてもよい。そして、生体データから特定された身体的疲労度が同じである場合、精神的疲労に関する順位が最も低い住人が調理担当に決定されてもよい。
【0218】
実施形態では、調理担当に決定された住人の体調と、他の住人の体調とに基づいて推奨メニューが決定される例が説明された。しかしながら、調理担当に決定された住人の体調のみから推奨メニューが決定されてもよいし、調理担当に決定された住人以外の住人の体調のみから推奨メニューが決定されてもよい。
【0219】
実施形態では、決定された調理担当がタッチパネル３５に表示されることで住人に通知される例が説明された。すなわち、タッチパネル３５が通知装置の一例である場合が説明された。しかしながら、決定された調理担当は、ユーザ端末３０が備えるスピーカ３６を通じて音声によって住人に通知されてもよい。その場合、スピーカは、通知装置の一例である。
【0220】
実施形態では、調理担当決定システム１０が、毎日の夕食の調理担当を決定する例が説明された。しかしながら、調理担当決定システム１０は、同様にして、毎日の朝食或いは昼食の調理担当を決定してもよい。また、調理担当決定システム１０は、毎週の土曜日及び日曜日などの休日の夕食の調理担当を決定してもよい。その場合、毎週の土曜日及び日曜日は、所定日の一例である。
【0221】
実施形態では、調理適格を有する全住人の体調が悪い場合は、調理担当の決定に代えて、ヘルプ者への調理支援の依頼、或いは出前をとることなどの提案が住人に対して行われる例が説明された。しかしながら、当該提案が行われなくてもよく、例えば、調理適格を有する全住人の体調が悪い場合、通知処理にて全住人が調理不可能である旨のみが通知されてもよい。
【0222】
［付記１］
複数の住人の生体データを検出する生体センサと、
通知装置と、
上記生体センサ及び上記通知装置と通信可能な制御装置と、を備えており、
上記制御装置は、
上記生体センサから生体データを取得する生体データ取得処理と、
上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、
特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、
決定した調理担当を、上記通知装置を通じて通知する通知処理と、を実行する、調理担当決定システム。
複数の住人の生体データを検出する生体センサと、
通知装置と、
上記生体センサ及び上記通知装置と通信可能な制御装置と、を備えており、
上記制御装置は、
上記生体センサから生体データを取得する生体データ取得処理と、
上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、
特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、
決定した調理担当を、上記通知装置を通じて通知する通知処理と、を実行する、調理担当決定システム。
【0223】
［付記２］
上記制御装置は、
決定した調理担当を日付と対応付けて実績データとしてメモリに記憶させる記憶処理をさらに実行し、
上記調理担当決定処理は、上記実績データにさらに基づいて、調理担当の候補から除外する住人を決定して調理担当を決定する処理である、付記１に記載の調理担当決定システム。
上記制御装置は、
決定した調理担当を日付と対応付けて実績データとしてメモリに記憶させる記憶処理をさらに実行し、
上記調理担当決定処理は、上記実績データにさらに基づいて、調理担当の候補から除外する住人を決定して調理担当を決定する処理である、付記１に記載の調理担当決定システム。
【0224】
［付記３］
上記制御装置と通信可能な入力インタフェースをさらに備えており、
上記制御装置は、
上記通知装置に、メモリに記憶された質問を所定時刻に通知させる質問通知処理と、
当該質問に対する住人の回答であって、上記入力インタフェースを通じて入力された当該回答を取得する回答取得処理と、をさらに実行し、
上記調理担当決定処理は、上記回答にさらに基づいて調理担当を決定する処理である、付記１または２に記載の調理担当決定システム。
上記制御装置と通信可能な入力インタフェースをさらに備えており、
上記制御装置は、
上記通知装置に、メモリに記憶された質問を所定時刻に通知させる質問通知処理と、
当該質問に対する住人の回答であって、上記入力インタフェースを通じて入力された当該回答を取得する回答取得処理と、をさらに実行し、
上記調理担当決定処理は、上記回答にさらに基づいて調理担当を決定する処理である、付記１または２に記載の調理担当決定システム。
【0225】
［付記４］
上記質問は、複数の質問項目を有しており、
上記質問項目は、複数の回答選択肢をそれぞれ有しており、
上記回答選択肢は、点数と対応付けられており、
上記調理担当決定処理は、上記回答に基づいて算出された総合点数が示す体調に基づいて調理担当を決定する処理である、付記３に記載の調理担当決定システム。
上記質問は、複数の質問項目を有しており、
上記質問項目は、複数の回答選択肢をそれぞれ有しており、
上記回答選択肢は、点数と対応付けられており、
上記調理担当決定処理は、上記回答に基づいて算出された総合点数が示す体調に基づいて調理担当を決定する処理である、付記３に記載の調理担当決定システム。
【0226】
［付記５］
上記体調特定処理は、メモリに記憶された基礎生体データに対する上記生体データの変位量に基づいて各住人の体調をそれぞれ特定する処理である、付記１に記載の調理担当決定システム。
上記体調特定処理は、メモリに記憶された基礎生体データに対する上記生体データの変位量に基づいて各住人の体調をそれぞれ特定する処理である、付記１に記載の調理担当決定システム。
【0227】
［付記６］
料理の種類と調理レベルとがメモリにおいて対応付けられており、
上記制御装置は、
決定した調理担当の体調レベルに応じた調理レベルの料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行し、
上記通知処理は、決定した調理担当及び料理の種類を通知する処理である、付記１に記載の調理担当決定システム。
料理の種類と調理レベルとがメモリにおいて対応付けられており、
上記制御装置は、
決定した調理担当の体調レベルに応じた調理レベルの料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行し、
上記通知処理は、決定した調理担当及び料理の種類を通知する処理である、付記１に記載の調理担当決定システム。
【0228】
［付記７］
料理の種類と体調レベルとがメモリにおいて対応付けられており、
上記制御装置は、
調理担当に決定した住人以外の住人の体調レベルに応じた種類の料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行し、
上記通知処理は、決定した調理担当及び料理の種類を通知する処理である、付記１または６に記載の調理担当決定システム。
料理の種類と体調レベルとがメモリにおいて対応付けられており、
上記制御装置は、
調理担当に決定した住人以外の住人の体調レベルに応じた種類の料理を、調理担当に提案する料理に決定するメニュー決定処理をさらに実行し、
上記通知処理は、決定した調理担当及び料理の種類を通知する処理である、付記１または６に記載の調理担当決定システム。
【0229】
［付記８］
上記調理担当決定処理は、
上記体調特定処理において特定した住人の体調が、調理を行い得る全住人について閾値レベルを超えて悪いと判断したことに基づいて、調理担当に代えて、メモリに記憶された提案を通知することに決定し、
上記通知処理は、決定した調理担当或いは上記提案を上記通知装置を通じて通知する処理である、付記１に記載の調理担当決定システム。
上記調理担当決定処理は、
上記体調特定処理において特定した住人の体調が、調理を行い得る全住人について閾値レベルを超えて悪いと判断したことに基づいて、調理担当に代えて、メモリに記憶された提案を通知することに決定し、
上記通知処理は、決定した調理担当或いは上記提案を上記通知装置を通じて通知する処理である、付記１に記載の調理担当決定システム。
【0230】
［付記９］
上記提案は、予めメモリに登録された連絡情報を含む、付記８に記載の調理担当決定システム。
上記提案は、予めメモリに登録された連絡情報を含む、付記８に記載の調理担当決定システム。
【0231】
［付記１０］
第１通信インタフェース及び第１コンピュータを有する情報処理装置に実装される第１プログラムと、
ディスプレイ、第２通信インタフェース、及び第２コンピュータを有するユーザ端末に実装される第２プログラムと、を備え、
上記第２プログラムは、
複数の住人の生体データを検出する生体センサから生体データを取得する生体データ取得処理と、
取得した上記生体データを上記第２通信インタフェースを通じて上記情報処理装置に送信する生体データ送信処理と、を上記第２コンピュータに実行させ、
上記第１プログラムは、
受信した上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、
特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、
決定した調理担当を上記第１通信インタフェースを通じて上記ユーザ端末に送信する調理担当送信処理と、を上記第１コンピュータに実行させ、
上記第２プログラムは、
受信した調理担当を上記ディスプレイに表示する通知処理を上記第２コンピュータに実行させる、プログラム。
第１通信インタフェース及び第１コンピュータを有する情報処理装置に実装される第１プログラムと、
ディスプレイ、第２通信インタフェース、及び第２コンピュータを有するユーザ端末に実装される第２プログラムと、を備え、
上記第２プログラムは、
複数の住人の生体データを検出する生体センサから生体データを取得する生体データ取得処理と、
取得した上記生体データを上記第２通信インタフェースを通じて上記情報処理装置に送信する生体データ送信処理と、を上記第２コンピュータに実行させ、
上記第１プログラムは、
受信した上記生体データに基づいて、所定日の所定時刻における各住人の体調をそれぞれ特定する体調特定処理と、
特定した各住人の体調に基づいて、上記所定日の調理担当を決定する調理担当決定処理と、
決定した調理担当を上記第１通信インタフェースを通じて上記ユーザ端末に送信する調理担当送信処理と、を上記第１コンピュータに実行させ、
上記第２プログラムは、
受信した調理担当を上記ディスプレイに表示する通知処理を上記第２コンピュータに実行させる、プログラム。
【符号の説明】
【0232】
１０・・・調理担当決定システム
１１・・・インターネット
２０・・・ウエアラブル端末（生体センサの一例）
２４・・・センサ群
３０・・・ユーザ端末
３１・・・ＣＰＵ（制御装置及び第２コンピュータの一例）
３２・・・端末メモリ
３３、３４・・・通信インタフェース（第２通信インタフェースの一例）
３５・・・タッチパネル（通知装置及び入力インタフェースの一例）
３６・・・スピーカ（通知装置の一例）
３７・・・クロックモジュール
３９・・・アプリケーションプログラム（第２プログラムの一例）
４０・・・管理サーバ（情報処理装置の一例）
４１・・・ＣＰＵ（制御装置及び第１コンピュータの一例）
４２・・・サーバメモリ（メモリの一例）
４３・・・通信インタフェース（第１通信インタフェースの一例）
４５・・・管理プログラム（第１プログラムの一例）
５１～５３、５５、５６、５８、５９・・・ラジオボタン（回答選択肢の一例）
１１・・・インターネット
２０・・・ウエアラブル端末（生体センサの一例）
２４・・・センサ群
３０・・・ユーザ端末
３１・・・ＣＰＵ（制御装置及び第２コンピュータの一例）
３２・・・端末メモリ
３３、３４・・・通信インタフェース（第２通信インタフェースの一例）
３５・・・タッチパネル（通知装置及び入力インタフェースの一例）
３６・・・スピーカ（通知装置の一例）
３７・・・クロックモジュール
３９・・・アプリケーションプログラム（第２プログラムの一例）
４０・・・管理サーバ（情報処理装置の一例）
４１・・・ＣＰＵ（制御装置及び第１コンピュータの一例）
４２・・・サーバメモリ（メモリの一例）
４３・・・通信インタフェース（第１通信インタフェースの一例）
４５・・・管理プログラム（第１プログラムの一例）
５１～５３、５５、５６、５８、５９・・・ラジオボタン（回答選択肢の一例）
【要約】
【課題】体調の悪い住人に調理を行なわせてしまうことを防止可能な調理担当決定システムを提供する。
【解決手段】調理担当決定システム１０は、住人が装着するウエアラブル端末２０と、ユーザが所持するユーザ端末３０と、管理サーバ４０とを備える。管理サーバ４０は、ユーザ端末３０を介して、体温や血圧や睡眠時間や心拍数や呼吸数などの住人の生体データをウエアラブル端末２０から取得する。管理サーバ４０は、取得した生体データに基づいて、住人の今日の体調を特定する。管理サーバ４０は、体調が悪いと判断した住人を、今日の夕食の調理担当の候補から外し、他の住人の中から調理担当を決定する。管理サーバ４０は、決定した調理担当を、ユーザ端末３０を通じて住人に通知する。
【選択図】図１
【解決手段】調理担当決定システム１０は、住人が装着するウエアラブル端末２０と、ユーザが所持するユーザ端末３０と、管理サーバ４０とを備える。管理サーバ４０は、ユーザ端末３０を介して、体温や血圧や睡眠時間や心拍数や呼吸数などの住人の生体データをウエアラブル端末２０から取得する。管理サーバ４０は、取得した生体データに基づいて、住人の今日の体調を特定する。管理サーバ４０は、体調が悪いと判断した住人を、今日の夕食の調理担当の候補から外し、他の住人の中から調理担当を決定する。管理サーバ４０は、決定した調理担当を、ユーザ端末３０を通じて住人に通知する。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】