JP2023113586A - システム - Google Patents

Abstract

【課題】対象者の状態に応じて適切な提案を行うことを可能とするシステム等を提供すること。【解決手段】複数のサービスの評価データを記憶する記憶部と、対象者に対して、前記評価データに基づいて、前記サービスの情報を提供する制御部と、を備え、前記制御部は、前記サービスに関する定性データから求められた第１の評価と、前記対象者に基づく定量データから求められた第２の評価とに基づいて、前記評価データを出力する。【選択図】図１

Description

本実施形態は、システム等に関する。

対象者の状態に基づいて、通報先を切り替えることにより迅速な通報を行うことが可能なシステムが知られている（例えば、特許文献１参照）。

また、対象者の状態に応じて、適切な対策を提案できるシステムが知られている（例えば、特許文献２参照）。

特開２０１７－０１８３７９号公報 特開２０１９－９５９２７号公報

本開示の目的は、対象者の状態を適切に判定することを可能とするシステム等を提供することである。

上述した課題に鑑み、本開示の態様のシステムは、１の端末装置から、対象者の定量データを取得し、第１の評価を行うステップと、１の端末装置を含む複数の端末装置から、対象者に関する定性データを取得し、第２の評価を行うステップと、前記第１の評価と、前記第２の評価とから、対象者の状態を判定するステップと、を含むことを特徴とする。

本開示によれば、対象者の状態を適切に判定することを可能とするシステム等を提供することができるようになる。

第１実施形態におけるシステム全体の示した図である。 第１実施形態における対象者のフェーズを説明するための図である。 第１実施形態におけるサーバ装置の構成を説明する図である。 第１実施形態における対象者情報記憶領域の構成の一例を説明する図である。 第１実施形態における異常閾値テーブルの一例を説明する図である。 第１実施形態におけるレコメンドＤＢの一例を説明する図である。 第１実施形態における評価データの一例を説明する図である。 第１実施形態における端末装置の構成を説明する図である。 第１実施形態におけるサービス提供装置の構成を説明する図である。 第１実施形態における処理の一例について説明するフロー図である。 第１実施形態における処理の一例について説明するフロー図である。 第１実施形態における処理の一例について説明するフロー図である。 第１実施形態における処理の一例について説明するフロー図である。 第１実施形態における処理の一例について説明するフロー図である。 第１実施形態の評価データ出力処理において使用するテーブルの一例を説明する図である。 第１実施形態の評価データ出力処理において使用するテーブルの一例を説明する図である。 第１実施形態の評価データ出力処理において使用するテーブルの一例を説明する図である。 第１実施形態における動作例（画面例）を説明する図である。 第１実施形態における動作例（画面例）を説明する図である。 第１実施形態における動作例（画面例）を説明する図である。 第２実施形態における処理の一例について説明するフロー図である。 第２実施形態における処理の一例について説明するフロー図である。 第３実施形態における処理の一例について説明するフロー図である。 第３実施形態における処理の一例について説明するフロー図である。 第３実施形態におけるテーブルの一例について説明する図である。 第３実施形態におけるテーブルの一例について説明する図である。 第３実施形態におけるテーブルの一例について説明する図である。

以下、図面を参照して本開示の端末装置、ベッド装置、システムを実施するための一つの形態について説明する。なお、本開示の内容は、実施を行うための形態の一例を示しているに過ぎず、開示されている数値や、構成に限定されず、当業者であれば想到することができる均等の範囲も含まれるものである。

検出装置を利用することで、対象者の生体信号を検出し、生体情報を出力する処理装置が知られている。例えば、処理装置として、出力した生体情報から異常がおきたことを、例えば対象者自身に通知したり、スタッフ等や、対象者の家族に通知したりすることが多く知られている。

しかし、処理装置から異常があったことの通知（いわゆる事後報告）を受け取ったとしても、対象者本人や、対象者の家族は、異常に対してどのような対応をしてよいか解らなかった。また、対象者の家族から職場や学校への連絡が遅くなると、無断欠席や無断欠勤として扱われる場合があり、対象者に不利益が生じる場合があった。

また、処理装置から異常があったことの通知を受け取ったとしても、その後どのような対応をすれば異常な状態を改善したり、更なる状態の悪化を未然に防いだりすることができるかは解らなかった。また、このような異常について、学校や職場等の協力を得る必要がある場合があるが、学校や職場へは通知がされなければ、学校や職場においては協力を得ることが難しかった。

また、そのような異常な状態が発生しないような予防や、異常な状態に対処を把握することで、日常的に対象者に対して日常において注意すべき点や、対策等が提案されることはなかった。

また、上述システムは、例えば対象者の生体情報や、睡眠の状態といった対象者から得られる定量的なデータから、対象者の状態を判断しているに過ぎなかった。

このように、従来は定量的なデータのみで対象者の状態を判断しており、定性的なデータを加味して、対象者の状態を判断するといったことはできなかった。例えば、これらの定性的なデータを点数や、フラグという内容で表現することはできるが、定量的なデータのように単純に数値では比較することができない。

また、対象者がサービスを受けた後に、そのサービス提供者を評価することがある。例えば、システムがサービスを提供する提供先をレコメンドするときに、評価の高いものからレコメンドする場合がある。

しかし、この評価は、主にサービスを受けた対象者が主観的に行うものである。すなわち、従来の評価は、対象者が入力した定性データのみで評価が行われているため、サービスを利用して客観的に効果があったかは解らなかった。例えば、対象者が病院に通院することで、対象者の病状は改善したとしても、病院の受付等のスタッフの対応が悪いと低評価となってしまう場合があった。

このようなことに、鑑み、以下の実施形態で説明する発明は、上述した課題を１又は複数解決するものである。なお、以下の実施形態において、使用する文言は以下の通りである。

（１）サービス享受者
対象者、対象者の家族・パートナー（以下、「家族等」）、対象者の住む自治体、対象者が通学する学校、対象者が勤務する仕事先をいう。例えば、サービス享受者とは、サービスを受ける対象者や、その対象者が日常生活をする上で密接に関係する人や、所属するグループ（グループに所属する人）をいう。ここで、密接に関係する人は、家族やパートナー(以下、「家族等」)であってもよい。また、グループに所属する人は、対象者の住む自治体の担当者、通学する学校の生徒、勤務先の人、習い事先(塾や水泳スクール)や趣味・スポーツなどのサークルの仲間、ボランティア先での人をいう。また、サービス享受者は、複数の段階を設けてもよい。例えば、第１サービス享受者として対象者自身、第２サービス享受者として対象者と行動を共にする家族等（配偶者、親、子供等）、第３サービス享受者としてその他の者というレベルに分けてもよい。

（２）サービス提供者
対象者や、家族等に主にサービスを提供する者、事業者等である。サービス提供者は各種サービスを提供する。サービス提供者は、サービス種別毎に複数対応付けられる。例えば、「サービス種別」は、以下のように分類してもよい。

（Ａ）提供サービス（第１のサービス種別）
対象者自身がサービスの提供を受けるサービスである。例えば、対象者が医療機関を受診する、対象者がマッサージの施術を受ける、対象者の住宅の改装をするといったサービスである。

（Ｂ）提案サービス（第２のサービス種別）
対象者に対して商品、薬等といった具体的な物を提案するサービスである。例えば、対象者に対して「Ａ薬品」「Ｂ薬品」を提案したり、「ベッド装置Ｃ」「ベッド装置Ｄ」といった製品等を提案したりするサービスである。

（Ｃ）サポートサービス（第３のサービス種別）
サポートサービスとしては、例えば、見守りサービスや、駆けつけサービス等がある。見守りサービスは、例えばセンサ等による遠隔の見守りや、電話やメール等における定期的な連絡による見守り、人が訪問することによる訪問サービスによる見守りを含むサービスである。また、対象者が子供の場合は、子供に危険が及ばないか、通学・通園を正しく行えたかといった見守りサービスであってもよい。また、見守りサービスは、恒常的に行うサービスだけでなく、所定のタイミングだけ行うサービス（一時見守りサービス）であってもよい。

また、駆けつけサービスは、対象者の異常事態において、サービス提供者が対象者の元へ駆けつけるサービスである。対象者の異常状態としては、例えば、センサにより取得した対象者の生体情報値の異常、対象者の転倒、対象者の動きがない、火災又は火災に繋がる状態がシステムにより検出された場合に、サービス提供者が駆けつけることとしてもよい。

また、見守りサービスには、駆けつけサービスを含んでもよいし、駆けつけサービスには見守りサービスを含んでもよい。

「サービス種別」は組み合わせてもよい。例えば、まずサービス種別における医療機関（第１のサービス種別）と、当該医療機関における投薬の種類（第２のサービス種別）とを組み合わせることもある。

サービス提供者が提供するサービスの内容やサービスの種類のことを「サービス内容」という。サービス内容は、サービス提供者が行う内容（例えば、カウンセリング、見守りサービス、製品の提案）や、サービス提供者が提案した商品、薬の種類（例えば、寝具としてベッド装置Ａや、薬として鎮痛剤Ｂ等）を含む。また、サービス提供者及びサービス提供者が提供するサービス内容の一例として以下のようなものが考えられる。

・工務店
工務店は、例えば、介護用ベッドの設置や部屋の改装等の提案に対してサービスを提供する。

・家電店、家電量販店、メーカ等（家電店等）
家電店等は、例えば、新しい介護用品や電気製品、新製品の提案に対してサービスを提供する。家電店等は、サービス種別として「介護用品を交換したらどうですか」という提案や、具体的に交換する製品を特定して提案してもよい。

・水道事業者、水道会社（水道事業者等）
水道事業者等は、例えば、水道の利用状況に応じて対象者（サービス享受者のうち第１サービス享受者）の見守りを行うサービス（見守りサービス）の提案や、サービスの提供を行う。例えば、水道の利用が極端に減った場合、サービス提供者は対象者に異常が発生していると判断する。

・ガス事業者、ガス会社（ガス事業者等）
ガス事業者等は、例えば、ガスの利用量やガスの利用状況に応じて対象者に対する見守サービスの提案や、サービスの提供を行う。

・郵便局
郵便局は、例えば、郵便の配達時のタイミングを利用して、対象者に対する見守りサービスの提案や、サービスの提供を行う。

・セキュリティ会社、食事宅配会社、配送会社（セキュリティ会社等）
セキュリティ会社等は、例えば、対象者に対する見守りサービスの提案や、サービスの提供を行う。特にセキュリティ会社の場合、例えば異常事態における駆けつけサービスの提案や、サービスの提供を行ってもよい。

・引っ越し会社
引っ越し会社は、例えば、部屋の配置換えを行うサービスや、見守りサービスの提案や、サービスの提供を行う。

・タクシー会社
タクシー会社は、例えば、駆けつけサービスに関する提案、送迎サービスに関する提案や、サービスの提供を行う。

・スポーツジム
スポーツジムは、例えば、対象者の体力向上や、筋力向上に対してトレーニングに関するプログラムの提案や、施設を利用したサービスの提供を行う。

・住宅関連業者
住宅関連業者は、例えば、対象者の住宅に関連する住まいの提案や、住宅に関するサービスの提供を行う。

・家事代行業者
家事代行業者は、例えば、対象者の家事を代行する家事代行サービスや、見守りサービスの提案や、サービスの提供を行う。

・薬局
薬局は、例えば、対象者に対する健康に関するアドバイスや、対象者に勧める薬の種類、対象者に対する薬の飲み方に関する提案や、サービスの提供を行う。

・自治体
自治体は、例えば、対象者に勧める相談サービス、見守りサービスの提案、集いの場の紹介、特別養護老人ホームの提案、健康に関する提案や、サービスの提供を行う。

・医療機関（医師、看護師等）
医療機関は、例えば、対象者に対する健康不安に関する提案、診断・治療に関する提案、医療施術に対する相談、処方する薬の提案や、サービスの提供を行う。

・高齢者施設（介護士、理学・作業療法士等）
高齢者施設は、例えば、対象者に対して行う施術に対する相談、見守りサービスに関する提案や、サービスの提案を行う。に対してサービスの提供を行う。

・福祉施設（介護士、ケアマネ）
福祉施設は、例えば、見守りサービスに関する提案、対象者のケアプランに関する提案や、サービスの提供を行う。

・学校等の教育機関
教育機関は、例えば、見守りサービスに関する提案や、見守りサービスの提供、教育サービスの提供を行う。

・保険会社
保険会社は、例えば、対象者に対して新たな保険に関する提案、契約している保険の見直しの提案や、保険サービスの提供を行う。

・警察
警察は、例えば、見守りサービスや、駆けつけサービスに関する提案や、サービスの提供を行う。

・一般人（アイドルエコノミー）
他の一般人は、例えば、対象者の困りごと・心配事などの相談に関する提案、見守りサービスの提案、駆けつけサービスの提案、家事代行サービスの提案や、当該サービスの提供を行う。

・睡眠アドバイザ
睡眠アドバイザは、例えば、対象者の睡眠に関することの相談の提案、サービスの提供を行う。

・カウンセラー
カウンセラーは、例えば、対象者の悩み事に関する相談の提案や、相談を行うサービスの提供を行う。

・食事アドバイザ、栄養士（栄養士等）
栄養士等は、例えば、対象者の食事に関する提案や、食事についての相談に対するサービスの提供を行う。

（３）定量データ
定量データは、一般的には数値化できるデータである。例えば、定量データは以下のようなものをいう。

・呼吸数、心拍数、体温、血圧、ＳｐＯ２、体重、運動量といったデータ（値）。これらの値は、対象者の生体信号（例えば、体動に基づいて検出される心拍、呼吸、活動量等の生体情報）に基づいて連続的に測定可能な測定装置・検出装置から取得してもよい。また、体温計、血圧計といったスポットで測定可能な測定装置・検出装置から取得した値でもよい。
・食事量、水分量といった対象者やスタッフ等の報告により数値化できる値
・うつ度チェック簡易抑うつ症状尺度（ＱＩＳＤ－Ｊ）といった検査により計測できる値

（４）定性データ
定性データは、主に人に入力させることを目的とするデータである。例えば、対象者本人（第１サービス享受者）や、家族等のサービス享受者（第２サービス享受者）、それ以外のサービス享受者（第３サービス享受者）が選択したり、入力したりしたデータが定性データとなる。一般的に、定性データは、単純に数値化することができない状態情報や質的な情報をいう。定性データは、例えば、第１サービス享受者である対象者本人が、対象者の心情・感情（疲れた、眠い、熱っぽい等）や、原因・要因・理由・根拠（例えば、睡眠不足、飲み過ぎた、休みがなかった）等を入力した情報である。また、定性データは、第２サービス享受者である家族や、第３サービス享受者であるその他の者（例えば、学校の教職員、仕事先の上司、産業カウンセラー等）からみた対象者の状態（例えば、対象者がだるそう、眠そう、元気がなさそう、顔が赤い等）を入力した情報である。また、定性データは、例えば第２サービス享受者、第３サービス享受者が「休ませた方がよい」といった判断を示す情報入力した場合も含まれる。なお、定性データは、サービス提供者が入力してもよい。定性データは、入力者が主観的に判断したデータである。

なお、定性データは、入力後に数値化されたり、グループ化されたりしてもよい。また数値化、グループ化されたデータは、入力された定性データと併せて記憶されてもよい。例えば、第１サービス享受者である対象者が、だるさを５段階で入力した場合、その５段階を数値として記憶してもよい。

（５）評価データ
評価データは、サービスに関する評価値である。評価データは、サービス提供者を評価した評価値、サービス内容を評価した評価を含む。評価データについては、詳細は後述するが、定性的な評価値と、定量的な評価値とが含まれたものが好ましい。ここで、定性的な評価値は、対象者や、家族等を含むサービス享受者が、サービス提供者等を評価するために入力する評価値（数値ではない定性的な評価、数値で表現された定性スコアを含む）である。また、定量的な評価値は、例えば、対象者の定量データ（心拍、呼吸、血圧等の生体情報の変動）から算出される評価値（定量的な評価、定量スコア）である。

すなわち、定性的な評価値は対象者の主観的な評価であり、定量的な評価値は対象者の生体情報等に基づいて算出される客観的な評価である。したがって、評価値として数値化されているときでも、定性的な評価値は評価者の主観的な評価に基づいている。また、定量的な評価値は対象者の生体情報等に基づいて客観的に算出されている。

定性的な評価値は、評価する者によって重み付けを用いてもよい。例えば、第１サービス享受者（実際にサービスを受けた者、対象者）の評価を５倍、第２サービス享受者（家族等）の評価を３倍、その他の第３サービス享受者の評価を１倍と、サービスの提供を受けた者に近いほどスコアが高くなるように重み付けをしてもよい。

この定性的な評価値（定性スコア）と、定量的な評価値（定量スコア）にもとづいて算出されるのが評価データである。なお、定性的な評価値（定性スコア）と、定量的な評価値（定量スコア）とは重み付けを行って評価データが算出されてもよい。したがって、評価データは、定性的な評価値のみ示す場合があってもよく、定量的な評価値のみ示す場合があってもよい。

また、評価データは、単純に評価値といった点数で評価してもよいし、段階評価（例えば、よい、ふつう、わるい等）であってもよい。また、評価データは、サービス享受者から入力された定性的な評価（例えば、「今回のサービスはとてもよかったです」「スタッフの挨拶がとてもしっかりしていました」等のサービス享受者が入力した任意の文言からなる評価）を含んでもよい。また、装置に記憶された評価辞書ＤＢ（データベース）や、クラウドに記憶された評価辞書ＤＢに基づいて、入力された文言から評価値を算出してもよい。この場合、評価辞書ＤＢは、例えば、機械学習等の何れかの方法で学習した学習済みモデルであってもよい。評価データは、本実施形態では定性データはとは別に説明するが、サービス享受者が入力するという点から、定性データに含めてもよい。

また、定量的な評価値として、例えば、問診結果通り、１週間で完治すると言われた症状に対して、１週間未満で完治すれば「とても良い」、１週間で完治すれば「良い」、１週間以上続く場合は「悪い」等としてもよい。具体的には、睡眠障害を改善する処置が行われ、対象者の睡眠時間が６時間以上になった場合に改善したとする。このとき、１週間後に、平均睡眠時間が６時間となった場合は「良い」評価を与えてもよい。また、１週間経過しても、平均睡眠時間が６時間未満の場合は、「悪い」評価を与えてもよい。

また、定量データとしては、例えば、体温、血圧、ＳｐＯ２、血糖値といった生体情報値をそのまま利用して評価してもよい。例えば、対象者が高血圧の場合、対象者の血圧が正常血圧に含まれるようになった場合は定量的な評価は高くなる（例えば、点数であれば５点満点中の５点、相対的な評価であれば「よい」）。また、対象者の血圧が高血圧の範囲に含まれる場合、評価は低くなる。例えば、このとき高血圧治療ガイドラインで示された「正常高値血圧」（例えば、収縮期血圧が１２０－１２９、拡張期血圧が８０未満）であれば、先程より低い評価（例えば、点数であれば３点、相対的な評価であれば「少し改善」）としてもよい。このように、定性データ及び定量データを利用して評価することで、対象者の主観的な評価のみならず、客観的な評価を行うことができる。

（６）対処データ
対処データは、対象者に施した施術の内容や、治療の内容、投薬の内容を含むデータである。また、対処データは、対象者が購入した製品（介護用品や、家電、ベッド装置等）であってもよい。対処データは、サービス提供者が提供可能なサービス内容のうち、選択されたサービス内容を示してもよい。また、対処データは、選択されたサービス提供者自体を示してもよい。

［１．第１実施形態］
［１．１ システム概要］
第１実施形態におけるシステム概要について説明する。図１は、システム１の全体を説明する図である。システム１は、ネットワークＮＷを介して、サーバ装置１０と、対象者システム２と、通知先システム３と、サービス提供システム４と接続されている。

サーバ装置１０は、本システムを実現するのに必要な装置である。本実施形態では、サーバ装置１０が処理を行うが、サーバ装置１０は、１又は複数の装置から構成されてもよい。また、一部の実行する機能を、他の装置に分散したり、外部のサービス（例えば、クラウドサービス）において実現したりしてもよい。

対象者システム２は、サービス享受者のうち、対象者本人又は家族等が利用するシステムである。すなわち、主に対象者や、その家族等が直接利用するシステムであり、端末装置（端末装置２０）を１又は複数備えている。端末装置は、例えば、スマートフォン、タブレット、コンピュータといった情報処理装置であってもよいし、ベッド装置の側に置かれる専用の端末装置であってもよい。

取得装置２２は、対象者の生体信号や、体動を検知した電気信号などを取得可能な装置である。取得装置２２は、何れかの方法で、対象者の生体信号や、身体の動き、対象者の状態（例えば、睡眠の状態、行動等）を取得できればよい。例えば、ベッド装置の上に載置された対象者の動きを検出可能は圧力センサにより実現してもよい。また、カメラ等により対象者を撮影し、対象者の動きから対象者の状態を判定してもよい。

また、取得装置２２から出力されたデータに基づいて、他の装置（例えば、端末装置２０）で、定量データを取得してもよい。

また、端末装置２０と、取得装置２２は一体型に構成されてもよい。例えば、端末装置２０の加速度センサを利用し、対象者の動きを検出してもよい。また、端末装置２０が、ウェアラブルな装置の場合、例えばセンサから心拍、呼吸、体温、ＳｐＯ２といった生体情報を取得してもよい。

また、取得装置２２は、１又は複数から構成されてもよい。例えば、対象者の状態として取得する情報毎に別の装置を設けてもよい。また、端末装置２０の加速度センサと、外部のセンサとして取得装置２２とを組み合わせてもよい。ここで、取得装置２２の一例としては以下のようなものが考えられる。

（１）睡眠計、睡眠解析装置
例えば、圧力センサにより対象者の体の動きから対象者の心拍、呼吸、睡眠量（睡眠時間）、覚醒時間等を取得し、定量データとして出力してもよい。このような装置としては、出願人の製品として眠りＳＣＡＮ（登録商標）、アクティブスリープアナライザ等が知られている。取得装置２２は、定量データとして、睡眠に関するデータを取得し、出力することができる。

（２）離床判定装置
例えば、対象者の荷重を検知している荷重検出器の荷重の変化から、対象者の心拍、呼吸、睡眠量（睡眠時間）、覚醒時間、ベッド装置からの転落転倒の有無・回数等を取得し、定量データとして出力してもよい。このような装置としては、出願人の製品として離床キャッチ等が知られている。取得装置２２は、定量データとして、対象の一晩における離床回数、離床時間を出力してもよい。

（３）寝床内測定装置
例えば、マットレス上に載置されたセンサ（加速度センサ、荷重検出センサ）や、ベッド装置に設けられたセンサにより、加速度や荷重の変化から対象者の心拍、呼吸、睡眠量（睡眠時間）、覚醒時間、ベッド装置からの転落転倒の回数等を取得し、定量データとして出力してもよい。

（４）スマートウォッチ、活動量計
例えば、スマートウォッチに内蔵された加速センサや、光センサ、熱センサにより、対象者の心拍、呼吸、睡眠量（睡眠時間）、覚醒時間、酸素飽和度、体温、血圧、歩数等を取得し、定量データとして出力してもよい。

（５）測定装置
例えば、測定装置として、体重計から体重、体温計から体温、血圧計から血圧、パルスオキシメータから酸素飽和度、血糖測定器から血糖値を取得し、定量データとして出力してもよい。

（６）スマートフォンのアプリケーション
例えば、アプリケーションに入力したり、食事の際の画像を撮影したりすることで、対象者の食事量（栄養素）、うつ度チェック簡易抑うつ症状尺度（ＱＩＳＤ－Ｊ）のうつ度等を取得し、定量データとして出力してもよい。うつ度等は、対象者の入力したデータに基づく指標で有り、定性データでもあるが、数値化できる場合は定量データとして出力してもよい。

また、端末装置２０は、対象者、家族等により定性データや評価データを入力できてもよい。また、端末装置２０は、各種表示や、通報を行ってもよい。

通知先システム３は、対象者の状態に基づいて通知をしたり、定性データを入力したり、評価データを入力したりすることが可能なシステムである。通知先システム３は、１又は複数の端末装置（端末装置３０）を有している。通知先システム３の端末装置３０は、主に対象者及び家族等以外のサービス享受者が有する。端末装置３０は、例えば、スマートフォン、タブレット、コンピュータといった情報処理装置であってもよいし、専用の端末装置であってもよい。

なお、端末装置２０と、端末装置３０は、端末装置の使用者により使い分けているもので、ハードウェアは同様の構成であってもよい。端末装置２０及び端末装置３０は、例えば、必要なアプリケーションをインストールして実行することで、システム１で必要な機能を提供できる。また、サーバ装置１０から通知されたアクセス先（例えば、ＵＲＬ）にアクセスすることで、システム１で必要な機能を提供することにしてもよい。以下、端末装置２０と説明するときは、端末装置２０だけでなく、適宜端末装置３０に読み替えても良い。

サービス提供システム４は、サービス提供者が各種サービスを提供するシステムである。サービス提供システム４は、例えばサービス提供装置４０をサービス提供者毎に有していてもよい。サービス提供装置４０は、サービスを提供する場合に必要となる処理や、情報を提供可能な装置であり、例えばサーバ装置であったり、情報処理装置であったりしてもよい。また、サービス提供者は、サービス提供装置４０以外にも、例えばＳａａＳ（Software as a Service）、ＡＳＰ（Application Service Provider）等の形式でサービスを提供してもよい。

例えば、サービス提供システム４は、病院、クリニック、診療所、鍼灸院等の予約受付システムである。例えば、サービス提供者が病院の場合、診察の時間帯の予約を受け付けるサービスを提供するシステムである。

また、サービス提供システム４は、例えば、製品の販売、レンタルの申込み受付システムである。例えば、サービス提供者がメーカ、販売店等の場合、販売する製品の申込みや、レンタルする製品の申込みを受け付けるサービスを提供するシステムである。

このように、サービス提供システム４は、サービス提供者がサービスを提供する上で必要なシステムであればよい。例えば、食事宅配会社に対する食事宅配サービスの申込み、保険会社に対する保険申込み、学校に対する一時見守りサービスの申込み等のように、上述したサービス提供者が提供するサービス内容に対応したシステムを提供することができる。

ここで、本システムでは「定量データ」「定性データ」「対処データ」が有効に利用される。例えば、バイタルデータ等の生体情報から取得した「定量データ」は、対象者が平常状態のときと比較し、明らかな数値的な異常を把握するときに有効に活用できる。

しかし、定量データだけでは、どのようなことが起因して異常となっているかが解らない。定量データだけでは解らない原因を特定するために、定性データが有効に活用される。

例えば、定量データとして、対象者の体温が「３８．７℃」と取得する。この場合、この発熱が細菌性・ウィルス性のものか、打撲や骨折という外傷によるものか、心因性発熱という精神疾患によるものかは特定できない。通常の医療行為の場合、医師は、問診という方法で対象者から定性データを集めることで診療を行う。対象者から得た情報により、医師は考えられる疾患の範囲を絞り、更に必要な問診や、身体診察を考えたうえで診療を行っている。

また、定量データ及び定性データを利用することで、対象者に対して処置した内容（対処データ）により、対象者が適切に良好な状態になっているのかを評価することが可能となる。定量データにより客観的な評価を行い、定性データにより主観的な評価を行うことが可能となる。この２つのデータから、対象者に施した診察・治療や、提供したサービスといった処置した内容が正しかったか、適切であったかを判定することができる。また、仮に、対象者に対してより適切な処置になる処置の内容、サービス提供者をシステムからレコメンドすることが可能となる。

また、システム１は、図２に示すように、対象者の状態（段階）に応じて適切な対応が可能となるシステムである。ここで、対象者の状態（段階）は、対象者のフェーズとして定義される。

対象者のフェーズは、「予防」「対処」「生活支援」といった複数のフェーズを含んでいる。「対処」と「予防」と「生活支援」との一連のフェーズをサポートするサービスを提供できるコミュニティが存在することで、システムが利用者の状況に合わせてコミュニティから「対処」と「予防」と「生活支援」のそれぞれのフェーズに応じたサービスを提供することが可能となる。

例えば、対象者のフェーズとして「予防」の場合、対象者の異常が発生する前の心身機能の変化情報をインプットとし、システムは対象者に問題が起きないように未然に防ぐ方法やサービスを対象者や家族等、仕事先や学校等に提供することが可能となる。

また、対象者のフェーズとして「対処」の場合、事後報告の通知に合わせて適切なサービスやサポートを対象者や家族等、仕事先や学校等に提供することができる。また、対象者の治療や回復に役立てるための事後前の生体情報を医療関係者等に提供することが可能となる。

また、対象者のフェーズとして「生活支援」の場合、上述した「予防」、「対処」までのフェーズを把握した、その後に必要となるモノゴトについて適切なサービスやサポートを対象者や家族等、仕事先や学校等に提供することが可能となる。また、「生活支援」のフェーズでは、身体介護のような具体的な介護とは別に、高齢者や障害者などの利用者の意思を尊重し、その生活を支えることが可能となる。例えば生活支援は、介護福祉士が利用者の家を訪問して、利用者が自分で行うことが難しい炊事や、洗濯、買物等の家事を行う家事援助、就労支援、社会参加の場の確保といった、多岐にわたり対象者の日々の生活を支えることができる。

これらの対象者のフェーズは、対象者の状態に応じて切り替わってもよい。例えば、対象者のフェーズは、最初は「予防」から始まってもよい。ここで、対象者が入院・手術等の治療を行った場合、治療後については「対処」のフェーズに遷移する。

対象者のフェーズが「予防」から「対処」に変化することで、例えば各異常であると判定する閾値に変化が生じる。例えば、システム１は、対象者が異常な状態であると判定するための閾値のレベルを１段階上げてもよい。

対象者のフェーズは、例えば対象者に対して何らかの処置が行われたことをシステムが取得したときに、切り替えてもよい。また、対象者のフェーズは、対象者自身、家族、スタッフ（医療従事者や、介護施設のスタッフ等）が選択してもよい。また、対象者のフェーズは、対象者のカルテの情報から、疾病歴等から判定してもよい。

［１．２ 構成の説明］
以下、各装置の構成について説明する。なお、各装置とも図で示した構成は一例であり、必要に応じて機能部を追加してもよいし、削除してもよい。例えば、各装置の記憶部に記憶されるデータは、必要なものを記載しているが、必用なときにネットワークに接続された他のサーバ装置などから参照できれば十分であり、装置上に記憶していなくてもよい。また、一部の構成は外部装置で構成されてもよい。例えば、入力部は、ＵＳＢ等により接続された外部のキーボード、マウス、タッチパネル等であってもよい。

［１．２．１ サーバ装置］
図３は、サーバ装置１０の構成を説明する図である。サーバ装置１０は、制御部１００と、記憶部１２０と、通信部１６０とを含んでいる。

制御部１００は、サーバ装置１０の動作を制御しており、１又は複数の制御装置で構成している。例えば、ＣＰＵ（Central Processing Unit）等の制御装置であってもよいし、複数の機能を有するＳｏＣ（System on a Chip）であってもよい。

また、制御部１００は、記憶部１２０に記憶されている各種プログラムを読み出して実行することにより各種処理を実現することとなる。制御部１００は、プログラムを実行することで、異常判定部１０２、レコメンドデータベース（ＤＢ）管理部１０４として機能してもよい。

異常判定部１０２は、対象者が異常の状態にあるかを判定する。異常判定部１０２は、例えば端末装置２０から定量データを受信したり、定性データを受信したりすることで、異常を判定する。また、異常判定部１０２は、取得装置２２から直接定量データを受信してもよい。

また、対象者が異常な状態とは、対象者が通常の状態とは異なる状態をいう。ここで、通常の状態とは、生体情報値が正常な範囲に含まれているものをいう。ここで、正常な範囲に含まれる値としては、各学会が定めた基準や、治療ガイドラインで定められた基準を利用したものであってもよく、以下のような数値が考えられる。
・体温：３６．８９度±０．３４度（ワキ下検温、検温時間３０分）
・血圧：最高血圧が１３５ｍｍＨｇ未満、最低血圧が８５ｍｍＨｇ未満
・心拍数：１分間に約６０～１００回
・呼吸数：１分間に１２～２０回
・ＳＰＯ２：９６～９９％
・睡眠時間：７～８時間
・体重（ＢＭＩ）：１８．５～２５
なお、これらの基準となる正常な範囲は、先天性・後天性障害により正常の範囲が異なっていてもよい。

また、対象者が異常な状態とは、例えば以下のような状態が考えられる。
（１）定量データが異常値を示している場合
例えば、対象者の生体情報値（心拍数、呼吸数）などが正常の範囲を超えている場合に、異常値として検出し、対象者が異常の状態にあると判定してもよい。例えば、異常判定部１０２は、対象者の定量データの値の何れかが、異常閾値を超えている場合には、異常値として検出し、異常の状態と判定する。

また、異常閾値は、対象者の通常の状態を示す正常の範囲の上限、下限を設定してもよい。また、異常閾値は、対象者の生体情報値の平均値から±αの範囲の上限、下限を設定してもよい。

ここで、異常判定部１０２は、定量データとして、例えば、心拍数、呼吸数等の生体情報値に基づいて異常値を判定してもよい。また、異常判定部１０２は、定量データとして例えば、睡眠時間、離床回数、ナースコールの呼び出し回数等が、異常閾値を超えた場合に対象者に異常があると判定してもよい。また、異常判定部１０２は、例えば加速度センサ等を利用することにより、対象者が転倒したことを検出した場合も、異常を判定したとしてもよい。また、異常判定部１０２は、対象者が通常の行動と異なる場合（例えば、平均在床時間が平均睡眠時間より大幅に多い場合）に、対象者に異常があると判定してもよい。

（２）定性データにより異常と判定する場合
例えば、対象者自身が、「倒れた」「痛みがある」「眠れない」等を定性データとして入力する。この入力された定性データに基づいて、対象者が異常な状態として判定する。また、定性データを入力するのは対象者自身には限られず、家族等、学校・職場の人間、施設のスタッフ等であってもよい。

また、上述した定量データと、定性データとを組み合わせて判定してもよい。例えば、対象者の睡眠時間が異常を示す閾値を超えており、かつ、対象者が入力した定性データにより異常判定部１０２は、対象者が異常な状態である判定する。

例えば、異常を示す閾値が「睡眠時間が６時間未満」である場合に、対象者の睡眠時間が５時間であり、かつ、対象者が「眠れない」といった定性データを入力したことで、異常判定部１０２は、対象者が異常な状態であると判定してもよい。

また、異常判定部１０２は、機械学習をした学習モデルを有していてもよい。この場合、定量データ、定性データ及び対処データを入力値として、対象者の状態が異常であるか否か、学習モデルを利用して判定してもよい。また、異常判定部１０２は、学習モデルを再学習してもよい。異常判定部１０２は、定量データ、定性データに対して、対処データを教師データとして学習してもよい。

また、異常判定部１０２は、対象者のフェーズにおいて、異常と判定する基準を変更してもよい。例えば、後述する定量データを異常と判定する閾値を、フェーズ毎に記憶している場合、対象者のフェーズに応じて対象者の状態を判定してもよい。

レコメンドデータベース（ＤＢ）管理部１０４は、後述するレコメンドＤＢ１３０を管理する。例えば、レコメンドＤＢ管理部１０４は、対処データに基づいて、適切なレコメンドが出力できるようにレコメンドＤＢ１３０を更新する。また、レコメンドＤＢ管理部１０４は、サービスの提供を受けた対象者等が入力した評価値に基づいて、レコメンドＤＢ１３０を更新する。

記憶部１２０は、サーバ装置１０が動作するための各種データ及びプログラムを記憶している。制御部１００は、記憶部１２０に記憶されているプログラムを読み出して実行することにより、各種機能を実現することとなる。ここで、記憶部１２０は、半導体メモリ（例えば、ＳＳＤ（Solid State Drive）やＳＤカード（登録商標））や、磁気ディスク装置（例えば、ＨＤＤ（Hard Disk Drive））等により構成されている。また、記憶部１２０は、内蔵される記憶装置であってもよいし、着脱可能な外部記憶装置であってもよい。また、クラウド等の外部サーバの記憶領域であってもよい。

記憶部１２０は、対象者情報記憶領域１２２と、評価データ記憶領域１５０との領域を確保し、レコメンドＤＢ１３０と、サービスＤＢ１４０とを記憶する。

対象者情報記憶領域１２２は、対象者に関する情報（以下、対象者情報）を対象者毎に記憶する領域である。対象者情報記憶領域１２２は、対象者の属性に関する情報である属性情報を記憶する属性情報記憶領域１２２０と、対象者の定量データを記憶する定量データ記憶領域１２２１と、対象者の定性データを記憶する定性データ記憶領域１２２２と、対象者に対して処置された内容である対処データを記憶する対処データ記憶領域１２２３と、対象者毎に定量データが異常か否かを判定するときに利用する異常閾値を記憶する異常閾値テーブル１２２４とを有している。

図４は、対象者情報記憶領域１２２に記憶される対象者情報のデータ構成の一例を示した図である。対象者情報記憶領域１２２は、対象者の属性（属性情報）として、対象者を識別するための識別情報（例えば、対象者のＩＤとして「Ｍ０００１」）と、対象者の氏名（例えば、「東京 太郎」）と、対象者の生年月日（例えば、「1950年２月24日」）と、通報先となる家族の家族ＩＤ（例えば、「Ｍ００２１…」）と、通報先となる学校や仕事先のＩＤ（例えば、「Ｓ００１４５」）と、対象者が利用可能なサービスの情報（例えば、契約しているサービス提供者を識別するための情報として「Ｐ０１２５…」）とを記憶している。なお、属性情報は、対象者を示す情報であればよい。属性情報は、その他にも対象者の性別、身長、体重、といった情報を含んでもよい。また、属性情報は、例えば対象者のアレルギー、疾病歴等を含んでもよい。属性情報は、属性情報記憶領域１２２０に記憶される。

定量データ記憶領域１２２１は、当該対象者の定量データを記憶する。定量データは、例えば、外部の測定装置から連続的に取得し、時系列に記憶してもよい。また、定量データは、例えば、血圧や、体温を医師やスタッフ、本人等がスポットとして測定して、その都度記憶してもよい。定量データは、連続的に取得される生体情報値や、離散的に測定され、測定したタイミングや、所定の間隔で取得される生体情報値が含まれる。対処データ定量データとして記憶するものの例としては、睡眠量、睡眠及び覚醒の時間、心拍数、呼吸数、血圧、体重、酸素飽和度、食事量（栄養素）、うつ度チェック簡易抑うつ症状尺度等である。

定性データ記憶領域１２２２は、例えば通信部１６０を介して端末装置２０又は端末装置３０から受信した定性データを記憶する。定性データは、主にサービス享受者から入力された定性データを記憶する。定性データは、サービス享受者が判断して入力した値であり、例えば選択値であったり、具体的な内容であったりしてもよい。例えば、定性データは「寝つきが悪い」「つかれる」「足が痛い」という対象者の状態を示すものであってもよい、項目別の評価点数であってもよい。また、定性データ記憶領域１２２２は、定性データを入力した日時や、定性データを入力した者を併せて記憶してもよい。

対処データ記憶領域１２２３は、対象者に対して処置した内容を示す対処データが記憶される。また、対処データは、そのときの対象者に関する情報（例えば、生体情報）を含んでもよい。また、対象者に関する情報は、対応をしたときの対象者に関する情報だけでなく、所定期間蓄積されたデータ（すなわち、生体情報等の遷移を示すデータ）を含んでもよい。対処データは、併せてサービス提供者と、サービス提供者に受けて対応を受けたサービス内容とを併せて記憶してもよい。

異常閾値テーブル１２２４は、システム１が異常値として判定する閾値を記憶するテーブルである。例えば、「心拍数」が「１３５以上」と記憶されている場合、心拍数が「１３５以上」となった場合に、対象者が異常な状態であると判定する。ここで、異常な状態とは、対象者が正常な状態でないことをいう。対象者が正常な状態とは、主観的には対象者が問題を感じていない状態であり、客観的には医者等の治療を必要としない状態である。異常な状態は、緊急性を有する状態（例えば、転倒をした、呼吸に異常がある、ＳｐＯ２の値がかなり低い、４０℃近い高熱がある等）と、緊急性を要しない状態（例えば、対象者の主観としてだるさを感じる、睡眠時間が短い、ＢＭＩ値が高い、微熱がある等）とを含む。

なお、異常閾値テーブル１２２４は、複数の値を記憶してもよい。この場合、システム１は、複数の値に基づいて、異常を判定する。例えば、「心拍数１２５以上が１分以上」と記憶されている場合、システム１は、対象者の心拍数１２５以上となっている状態が１分以上継続した場合に、対象者が異常な状態と判定する。

また、異常閾値は、対象者のフェーズ（「予防」「対処」「生活支援」）に応じて記憶してもよい。例えば、対象者のフェーズが「予防」のとき、異常閾値を「心拍数１３５以上」とする。しかし、この対象者が「対処」のフェーズに移行したときは、対象者のフェーズが「予防」のときと比較して、低めの閾値を記憶してもよい。すなわち、異常判定部１０２は、対象者のフェーズが「予防」のときと比較して「対処」のときのほうが厳しめに異常と判定するようにしてもよい。

例えば、対象者のフェーズに応じた異常閾値テーブル１２２４の一例を図５に示す。図５は、異常閾値を、対象者のフェーズ毎に示している。異常閾値テーブル１２２４では、予防、対処、生活支援のフェーズ毎に、例えば対象者の情報として、体温、血圧、心拍数、呼吸数、ＳｐＯ２、睡眠時間、体重（ＢＭＩ）が設定されている。異常判定部１０２は、対象者のフェーズに応じたパラメータを異常閾値として設定できる。

レコメンドＤＢ１３０は、システム１が、対象者にサービスを提案する内容や、提案したサービスに対応する提供先（サービス提供者）について含むデータベースである。レコメンドＤＢ１３０は、種々の方法で示すことができるが、例えば、図６で示すように、制御部１００が、対象者が異常と判定する原因（判定原因）と、判定原因に対応する対処法と、その場合に、ユーザ等に表示するメッセージである対策メッセージと、サービス提供先としてレコメンドするサービス提供者との情報を含んでもよい。ここで、判定原因は、異常判定部１０２が異常と判定した結果を記憶してもよい。例えば、図６では、異常判定部１０２が、対象者の「睡眠時間６時間未満がＸ日間連続した」と判定し、その場合の対処方法が記憶されている。また、図６は、説明の都合上「判定原因」を文章で記載しているが、単にパラメータだけを記憶してもよいし、異常判定部１０２が出力する異常を示すコードを記憶してもよい。

すなわち、図６では、説明の都合上、便宜的に判定原因や、対策のメッセージ等について具体的なメッセージとして含んでいるが、レコメンドＤＢ１３０は、例えば判定する為の判定閾値などの数値を具体的に記憶していてもよい。

また、レコメンドＤＢ１３０は、サービス提供者だけでなく、サービス内容を併せて記憶してもよい。例えば、図６において、サービス提供者「Ｇ００２（メーカ）」に対応付けて、サービス内容として、提案する商品や、装置の情報を記憶してもよい。また、図６においてサービス提供者「Ｈ００１」（睡眠外来）に対応付けて、サービスの内容として検査の方法、投薬に関する内容といった情報を記憶してもよい。

また、レコメンドＤＢ１３０は、サービス種別を記憶してもよい。例えば、サーバ装置１０は、判定原因が睡眠不足に対して「病院に行く」「寝具を変える」「寝る前に体操をする」といった異なるサービス種別を記憶してもよい。この場合、対象者がサービスの種別を選択した場合、サーバ装置１０は、更にレコメンドＤＢ１３０を参照することで、サービス提供者をレコメンドしてもよい。

また、レコメンドＤＢ１３０は、機械学習をした学習モデルであってもよい。すなわち、制御部１００が、レコメンドＤＢ１３０の学習モデルに基づいて抽出した基準（特徴量の組合せ）に応じて、レコメンドを出力することができる。

レコメンドＤＢ１３０に記憶される対処法、対策メッセージは、主に端末装置２０や、端末装置３０に通知するためのメッセージである。対処法、対策メッセージは、例えば、通知先毎に記憶してもよい。例えば、対象者、家族等、対象者・家族等以外のサービス享受者宛の対処法、対策メッセージをそれぞれ記憶してもよい。

また、レコメンドＤＢ１３０は、サービス提供者の情報を１又は複数記憶している。例えば、判定原因が「睡眠時間５時間未満がＸ日間連続する＋生体情報から無呼吸を検出」の場合、サービス提供者として「Ｈ００１」（睡眠外来）を記憶している。これにより、システム１は、対象者等のサービス享受者に、睡眠外来のレコメンドを行うことが可能となる。

サービスＤＢ１４０は、サービスに関する情報を記憶する。例えば、サービス提供者に関する情報をサービスＤＢ１４０は記憶する。サービス提供者に関する情報は、サービス提供者の事業者名、サービス種別、住所、ＵＲＬ、サービス内容といったものを含んでもよい。また、サービス内容は、別に記憶してもよい。例えば、介護用品や、ベッド装置、家電等の製品情報をサービス内容として記憶してもよい。また、サービス提供者の情報をサービス種別毎に記憶してもよい。

評価データ記憶領域１４２は、サービスに関する評価が記憶される。ここで、サービスに関する評価は、例えば、サービス種別、サービス提供者、サービス内容毎に記憶される。また、記憶される評価は、定性データ及び定量データに基づいて算出される評価値であってもよいし、必要な項目に分けて記憶されてもよい。

すなわち、対象者等のサービス享受者から入力された定性データ及び対象者に基づく定量データから求められた評価データが評価データ記憶領域１５０に記憶される。例えば、制御部１００は、評価データに基づいて、対象者に適切なサービス提供者のレコメンドを行う。

図７に評価データ記憶領域１５０に記憶される評価データの一例を示す。例えば、図７（ａ）に示すように、サービス提供者の名称（例えば、病院名「ＡＢＣ病院」）と、サービス提供者の地域（例えば、「東京都千代田区」）とを基本情報として記憶する。なお、これらの情報は、サービスＤＢ１４０にサービス提供者に関する情報として記憶される一部の情報である。図７（ａ）では説明のためにサービス提供者の名称を示しているが、例えば、サービスを識別する識別コードを利用し、評価値を対応付けて記憶してもよい。

また、評価データは、属性毎に記憶してもよい。例えば、属性として「年代」と、評価した場合の症状（例えば、「睡眠障害」）と、評価（例えば、「４．６」）とを記憶している。

なお、評価データは、定量データ及び定性データから求められた評価値をそのまま記憶してもよいし、評価値の平均値を記憶してもよい。

ここで、対象者の属性を示すものは、年齢（年代）の他に、性別、身長、体重、地域、基礎疾患の有無等で分類されてもよい。また、症状は、異常判定部１０２の判定結果や、対象者に対する処置内容、対象者が入力した主訴により分類されてもよい。

上述した分類方法は好ましい方法ではあるが、それ以外にも、評価データ記憶領域１４２は、制御部１００がレコメンドに必要な分類で評価値が記憶されていればよい。

また、他の評価データの一例して、図７（ｂ）に示す。図７（ｂ）は、対象者の症状と、対象者の症状に対応したサービス内容（対象者が処置として選択した対処データ）と、対象者の属性と、評価値とを記憶している。例えば、対象者の症状として、睡眠不足と特定されている場合、評価データにはサービス内容として寝具提案が記憶されている。この寝具提案のサービス内容には、提案した寝具（ベッド装置Ａ、ベッド装置Ｂ）の評価値が属性毎に記憶されている。

制御部１００は、図７（ｂ）の評価データを参照することで、対象者の症状及び属性（図７（ｂ）では年代）に応じて、もっとも評価の高い評価内容（この場合はベッド装置の種類）をレコメンドすることが可能となる。

また、評価データは、定量データに基づく評価値と、定性データに基づく評価値とを分けて記憶してもよい。また、定性データに基づく評価値は、評価項目（例えば、体調が改善した、施設のスタッフがよかった、金額が安かった）毎に記憶してよい。評価データが細かく記憶されていると、例えば対象者により「スタッフの感じがよい施設」といった項目が選択された場合に、スタッフの感じがよい施設の評価値が高いサービス提供者を適切にレコメンドすることができる。

通信部１６０は、他の装置と通信を行う。例えば、ネットワークに接続するＬＡＮインタフェースや、他の装置と接続するＵＳＢや、近距離無線通信部が含まれる。通信部１６０は、ＬＴＥ／５Ｇといった携帯電話通信網に接続可能な通信装置であってもよい。

［１．２．２ 端末装置］
図８は、端末装置２０の構成を説明する図である。端末装置２０は、制御部２００と、記憶部２１０と、通信部２５０とを含んでいる。

制御部２００は、端末装置２０の動作を制御しており、１又は複数の制御装置で構成している。例えば、ＣＰＵ（Central Processing Unit）等の制御装置であってもよいし、複数の機能を有するＳｏＣ（System on a Chip）であってもよい。

また、制御部２００は、記憶部２２０に記憶されている各種プログラムを読み出して実行することにより各種処理を実現することとなる。制御部２００は、プログラムを実行することで、定量データ取得部２０２として機能してもよい。

定量データ取得部２０２は、取得装置２２から定量データを取得する処理を実行する。定量データ取得部２０２は、設定された内容により、所定の生体情報や、数値化できる情報を取得し、定量データとして定量データ記憶領域２１２に記憶する。

定量データ取得部２０２は、例えば所定のタイミングで割込みを行い、定期的に生体情報等を取得してもよい。具体的には、定量データ取得部２０２は、例えば１秒毎、５秒毎、３０秒毎、１分毎といった所定の間隔毎にデータを取得する。また、毎日定期的な時間（例えば、２１時、６時等）に取得してもよいし、所定のタイミング（例えば、対象者が在床したとき）に取得してもよい。このように、定量データ取得部２０２は、連続的に定量データを取得することができる。

また、定量データ取得部２０２は、任意のタイミングで生体情報等を取得してもよい。例えば、体温計で測定した体温は、測定時にスポット的に取得する。これにより、例えば定量データが離散的なデータであっても取得することができる。

なお、本実施形態では、定量データ取得部２０２が、取得装置２２から一度定量データを取得し、定量データ記憶領域２１２に記憶することとして説明する。例えば、取得装置２２から、生体信号を示す信号（例えばアナログ信号）を受信し、制御部２００が定量データを変換（算出）してもよい。

記憶部２１０は、端末装置２０が動作するための各種データ及びプログラムを記憶している。制御部２００は、記憶部２１０に記憶されているプログラムを読み出して実行することにより、各種機能を実現することとなる。ここで、記憶部２２０は、半導体メモリ（例えば、ＳＳＤ（Solid State Drive）やＳＤカード（登録商標））や、磁気ディスク装置（例えば、ＨＤＤ（Hard Disk Drive））等により構成されている。また、記憶部２２０は、内蔵される記憶装置であってもよいし、着脱可能な外部記憶装置であってもよい。また、クラウド等の外部サーバの記憶領域であってもよい。

記憶部２１０は、定量データ記憶領域２１２に、定量データ取得部２０２が取得した定量データを記憶する。また、記憶部２１０は、定性データ記憶領域２１４に、入力部２３０から入力された定性データを記憶する。定量データ及び定性データは、記憶部２１０に一時的に記憶されてもよいし、時系列に記憶されてもよい。また、定量データ、定性データは、直接サーバ装置１０に記憶されてもよいし、クラウドサービス等のネットワーク上に記憶されてもよい。

入力部２３０は、対象者からの操作入力を受け付ける。例えば、対象者により、対象者の状態を取得する開始の操作が行われたり、定性データの入力が行われたりと、各種操作入力が行われる。入力部２３０は、タッチパネルのパネル入力装置や、操作ボタンにより構成されてもよい。また、入力部２３０は、音声入力やカメラ等による画像による入力であってもよい。

出力部２４０は、各種情報を出力する。例えば、液晶ディスプレイの表示装置や、ＬＥＤ等の発光部材、音や音声を出力するスピーカ、他の記録媒体にデータを出力するインタフェース等で構成される。また、入力部２３０と、出力部２４０とを一体に構成することにより、タッチパネルとして構成してもよい。

通信部２５０は、他の装置と通信を行う。例えば、ネットワークに接続するＬＡＮインタフェースや、他の装置と接続するＵＳＢや、近距離無線通信部が含まれる。通信部２５０は、ＬＴＥ／５Ｇといった携帯電話通信網に接続可能な通信装置であってもよい。

取得部２６０は、他の装置からデータを受信する。例えば、取得装置２２と有線または無線通信で接続し、取得装置２２から種々のデータを受信する。取得部２６０は、例えば、ＵＳＢや、ＲＳ－２３２Ｃといった優先／無線で接続可能なものであってもよいし、Ｂｌｕｅｔｏｏｔｈ（登録商標）のような近距離無線通信の送受信が可能なものでもよい。また、ＮＦＣ等のように、接続時に一括してデータを取得してもよいし、取得装置２２と通信を維持し、常時データを取得してもよい。また、例えば無線ＬＡＮ等で取得装置２２と通信可能であれば、例えば通信部２５０が代わりに機能してもよい。

なお、端末装置２０について説明したが、端末装置３０においても構成はほぼ同一である。図８の構成は、端末装置（端末装置２０及び端末装置３０）の一般的な構成であり、これらの構成のうち必要な機能を有すればよい。例えば、入力部２３０や、出力部２４０を、外部の入力装置や、出力装置で実現等、端末装置自体に一部の機能を有していなくてもよい。また、図８の記憶部２１０が記憶するプログラムや情報は必要に応じて記憶すればよい。例えば、端末装置３０の場合、取得部２６０の構成は不要であり、定量データ記憶領域２１２の記憶領域も確保する必要はない。

［１．２．３ サービス提供装置］
図９は、サービス提供装置４０の構成の一例を示す図である。サービス提供装置４０は、制御部４００と、記憶部４３０と、通信部４５０とを含んでいる。

制御部４００は、サービス提供装置４０の動作を制御しており、１又は複数の制御装置で構成している。例えば、ＣＰＵ（Central Processing Unit）等の制御装置であってもよいし、複数の機能を有するＳｏＣ（System on a Chip）であってもよい。

制御部４００は、記憶部４２０に記憶されたプログラムを実行することでサービス提供部４０２として機能してもよい。

サービス提供部４０２は、サービス運営者が提供するサービスを実現する。例えば、病院であれば、外来の受付サービスを提供する。また、警備会社であれば、警備要請や、かけつけサービスといった受付を提供する。また、メーカであれば、製品を販売するサービス（販売サイト）を提供する。サービス提供部４０２は、サービス運営者が必要に応じてサービス享受者に対してサービスを提供する機能を実現する。

記憶部４２０は、サービス提供装置４０が動作するための各種データ及びプログラムを記憶している。制御部４００は、記憶部４２０に記憶されているプログラムを読み出して実行することにより、各種機能を実現することとなる。ここで、記憶部４２０は、半導体メモリ（例えば、ＳＳＤ（Solid State Drive）やＳＤカード（登録商標））や、磁気ディスク装置（例えば、ＨＤＤ（Hard Disk Drive））等により構成されている。また、記憶部４２０は、内蔵される記憶装置であってもよいし、着脱可能な外部記憶装置であってもよい。また、クラウド等の外部サーバの記憶領域であってもよい。

通信部４５０は、他の装置と通信を行う。例えば、ネットワークに接続するＬＡＮインタフェース等が含まれる。通信部４５０は、ＬＴＥ／５Ｇといった携帯電話通信網に接続可能な通信装置であってもよい。

［１．３ 処理の説明］
つづいて、本実施形態における処理について、図を参照して説明する。

［１．３．１ システムの概要処理］
まず、システム１の全体の流れについて、図１０を参照して説明する。図１０では、システム１は、まずは対象者に関するデータを取得する（ステップＳ１０）。例えば、システム１のサーバ装置１０は、定量データ、定性データ、対処データを１又は複数取得することができる。また、サーバ装置１０がデータを取得するタイミングは、その都度取得してもよいし、所定時間毎に取得してもよい。また、所定のイベントのタイミング（例えば、対象者が在床したタイミングや、体が動いたタイミング）毎に取得してもよい。これらのデータは、サーバ装置１０が、端末装置２０を経由して取得してもよい。また、サーバ装置１０は、直接取得装置２２から取得してもよい。また、サーバ装置１０は、対象者等から手入力で入力されたデータを取得してもよい。また、サーバ装置１０は、定性データであれば、例えば家族等が使っている端末装置２０や、その他のサービス享受者が使っている端末装置３０からデータを取得してもよい。

続いて、サーバ装置１０は取得したデータ（定量データ、定性データ、対処データ）に基づいて、サービスに関する情報を対象者に提供する（ステップＳ２０）。サービスに関する情報を提供するとは、例えば、複数あるサービスの中から、サービスの種別、サービス提供者、サービス内容について、１又は複数の情報を対象者に提供する。

サーバ装置１０が、対象者にサービスの情報を提供する具体的な方法として、例えば、サーバ装置１０は、提案処理を行う（ステップＳ２２）。ここで、提案処理は、例えば、システム１が、対象者が利用するサービス種別等を提案する。例えば、サーバ装置１０は、定量データが異常を示している場合、サービス享受者から定性データを取得する。このように、サーバ装置１０は、取得した定量データや、定性データに基づいて、どのようなサービスを対象者が受けた方がよいかを提案する提案処理を実行する（ステップＳ２２）。

また、サーバ装置１０は、例えば対象者の対処データ（例えば、直前に選択されたサービス提供者や、サービス内容）に基づいて、対象者のフェーズを判定してもよい。そして、サーバ装置１０は、対象者のフェーズに応じて、定量データが異常であるかを判定し、提案処理を実行してもよい。

また、サーバ装置１０は、取得した定量データと、定性データと併せて、評価データに基づいてサービスの種別等を提案してもよい。すなわち、サーバ装置１０は、定量データ及び定性データと、評価データとを参照することで、より適切なサービスの種別等の提案を行うことができる。

また、サーバ装置１０は、提案処理において、例えば、定性データを入力する端末装置を選択してもよい。定性データを入力する者として、第１サービス享受者及び／又は第２サービス享受者を適切に選択する。例えば、精神疾患のような場合、第１サービス享受者ではなく、第２サービス享受者のみに提案を行ってもよい。また、サーバ装置１０は、第３サービス享受者に定性データを入力させてもよい。

ここで、対象者は提案の中から適切なサービスを含む提案を選択する。このとき、サーバ装置１０は、選択された提案がサービスを利用する（サービス提供者が提供するサービスを利用する）ものである場合（ステップＳ２４；Ｙｅｓ）、当該サービスを提供するサービス提供者の中から、好ましいサービス提供者や、サービス内容をレコメンドするレコメンド処理を実行する（ステップＳ２６）。

なお、サーバ装置１０は、ステップＳ２２において例えば定量データ、定性データに基づいて提案を行うが、対象者のある環境因子等の他の情報により適切な提案を行ってもよい。また、サーバ装置１０は、提案処理において、機械学習済である学習モデルをつかって、取得した定量データ、定性データ等に基づいて、提案を行ってもよい。

また、サーバ装置１０は、提案処理において、サービス等を提案するが、当該提案の通知先として、対象者、家族等を判定し、適切な通知先（提案先）にサービスの提案を行ってもよい。また、サーバ装置１０は、サービスの提案を複数回行ってもよい。例えば、サーバ装置１０は、最初に第１の提案を行う。その後、対象者だけでなく、家族等や、学校や仕事場の人に第１の提案に対して回答（定性データ）を入力してもらう。ここで、入力する定性データは、原因や、感想を入力するだけでなく、選択肢に対する「はい」「いいえ」といったものも含むものとする。

そして、第１の提案に対する回答（定性データ）に基づき、サーバ装置１０（システム１）は、第２の提案を行う。第２の提案は、例えば対象者が受けるべきサービス種別に関する提案であてもよいし、サービス提供者や、サービス内容のレコメンドを行う処理であってもよい。

本実施形態では、サーバ装置１０が実行する処理として、提案処理（ステップＳ２２）と、レコメンド処理（ステップＳ２６）と分けて説明するが、併せて実行してもよい。サーバ装置１０は、提案処理（ステップＳ２２）、レコメンド処理（ステップＳ２６）を実行することにより、対象者が受けるべきサービスに関する情報を提供したり、サービスのレコメンドを出力したりすることができる。

つづいて、サーバ装置１０は、選択されたサービスに対する評価処理を実行する（ステップＳ３０）。例えば、対象者（第１サービス享受者）は、選択したサービス提供者及び／又はサービス内容に対して、実際にサービスを受けた上で評価を入力する。また、サーバ装置１０は、対象者だけでなく、他のサービス享受者から評訂正データとして評価を取得してもよい。

また、サーバ装置１０は、対象者がサービスの提供を受けた後の定量データ（例えば生体情報（体重等）の変化、睡眠時間の変化等）を取得する。サーバ装置１０は、取得した対象者の生体情報等の定量データから、サービスを受けた前後で実際に定量データの数値が改善しているかを判定する。そして、サーバ装置１０は、具体的な数値に基づいて、提供を受けたサービスの有効性や、対象者がどの程度問題点を解消したかを客観的なデータに基づいて判定する。

このように、サーバ装置１０は、対象者が感じた主観的な評価（定性データによる評価）と、対象者から取得された定量データに基づく客観的な評価（定量データによる評価）とを組み合わせて、サービス（選択したサービス種別、サービス提供者、サービス内容）を評価する

これにより、サーバ装置１０は、例えばステップＳ２２においてサービスを提案するときに、単に定量データから第１の提案を行うだけでなく、定量データと定性データとを合わせた内容から第１の提案を行うことができる。また、サーバ装置１０は、定量データと、定性データとに限られず、更に評価データを併せて第１の提案を行うことができる。

また、サーバ装置１０は、対象者が対処のフェーズの場合、対象者のフェーズを考慮した上で、第１の提案を行ってもよい。また、サーバ装置１０は、第２の提案を行う場合も、定量データと、定性データとを掛け合わせてもよい。また、サーバ装置１０は、第２の提案を行う場合も、対処データを更に参照してもよい。

また、システム１は、ステップＳ２２において、提案処理ということで、サービス等の提案を行っているが、単に通知だけを行ってもよい。例えば、システム１は、対象者、家族等、会社（職場）、学校、病院等のサービス享受者に異常データに基づく通知を行ってもよい。これにより、サービス享受者は、例えば対象者の様子を伺ってもよい。また、システム１から通知を受けたことにより、学校又は職場は欠席や欠勤の連絡として把握してもよい。

［１．３．２ 提案処理］
システム１において、サーバ装置１０が実行する提案処理について図１１を参照して説明する。なお、提案処理を実行するとき、制御部１００は予め対象者が異常な状態であると判定する閾値や、対象者が異常な状態であると判定するための条件を、異常閾値テーブル１２２４（例えば、図５に記載の異常閾値テーブル１２２４）から読み出してもよい。なお、制御部１００は、異常閾値テーブル１２２４から、対象者に応じて異常閾値を読み出してもよい。また、制御部１００は、異常閾値テーブル１２２４に共通する異常閾値を記憶している場合は、システム開示しに一律に読み出してもよい。また、制御部１００は、異常閾値テーブル１２２４に記憶されている異常閾値が更新された場合、その都度新し異常閾値を異常閾値テーブル１２２４から読み出してもよい。

制御部１００は、対象者の情報を取得する（ステップＳ１０２）。ここで、制御部１００は、例えば定量データを端末装置２０（又は取得装置２２）から取得する。

制御部１００は、取得した対象者の情報である定量データから、対象者に異常があるかを判定する（ステップＳ１０４）。ここで、異常判定部１０２は、定量データに基づいて、対象者の状態が異常であるかを判定するが、例えば以下のような条件に合致した場合に異常な状態（対象者に異常がある）と判定してもよい。また、以下の異常閾値（パラメータ）は一例であり、対象者毎に異なるものであってもよい。本実施形態では、異常閾値テーブル１２２４に記憶されているが、例えば外部から取得した異常閾値であってもよい。

（１）がん、脳卒中、心筋梗塞となる可能性がある場合
・５時間以下の睡眠が１週間以上つづく
・週１５０分の緩い運動又は週７５分の激しい運動をしない人（運動不足）
・１週間以上最高血圧が１４０ｍｍＨｇ以上続いている
・１週間以上体温３７度以上が続いている
・１週間以上食事がファストフードや揚げ物などの割合が多く、偏った食事となっている
・体重が６～１２ヶ月で５％以上減少している

これらの条件に１又は複数合致する場合、異常判定部１０２は、がん、脳卒中、心筋梗塞となる可能性があるとして、対象者が異常な状態であると判定する。

（２）うつ病等の精神疾患となる可能性がある場合
・４時間半以下の睡眠が５日以上続く
・週１５０分の緩い運動又は週７５分の激しい運動をしない人（運動不足）
・１週間以上最高血圧が１４０ｍｍＨｇ以上続いている
・１週間以上体温３７度以上が続いている
・１週間以上食事がファストフードや揚げ物などの割合が多く、偏った食事となっている
・体重が６～１２ヶ月で５％以上減少している
・うつ度チェック簡易抑うつ症状尺度（ＱＩＤＳ－Ｊ）で軽度以上判定

これらの条件に１又は複数合致する場合、異常判定部１０２は、うつ病等の精神疾患となる可能性があるとして、対象者が異常な状態であると判定する。

なお、異常判定部１０２は、対象者のフェーズに応じて、判定する閾値を変更してもよい。例えば、異常判定部１０２は、対象者のフェーズが「予防」と比較して「対処」の場合は、より厳しい閾値（判定基準）を採用してもよい。

つづいて、制御部１００は、異常判定部１０２により、対象者が異常な状態であると判定した場合、対象者に異常が生じていると判定した場合、所定の端末装置に対象者が異常な状態や、対象者に異常が生じている旨を通知してもよい（ステップＳ１０６）。

例えば、制御部１００は、対象者本人が使用している端末装置２０や、家族等が使用している端末装置２０に、対象者が異常な状態であること（又は異常が発生したこと）を通知してもよい。また、制御部１００は、対象者に異常が発生したことを他のサービス享受者に通知してもよい。また、制御部１００は、対象者の異常な状態に応じて通知先を切り替えてもよい。例えば、定量データが第１レベルの異常閾値を超えたときは第２サービス享受者（家族等）が使用する端末装置２０に通知する。しかし、定量データがより深刻な第２レベルの異常閾値を超えているときは、家族等の端末装置２０と併せて、病院、学校等の第３のサービス享受者が使用する端末装置３０に対象者が異常な状態となっていることを併せて通知してもよい。

つづいて、制御部１００は、定性データを入力する端末装置を特定する（ステップＳ１０８）。制御部１００は、対象者自身に定性データを入力してもらう他に、対象者以外の第２サービス享受者（家族等）や、第３サービス享受者（学校等）のうち、誰に定性データを入力してもらうかを特定する。

この制御部１００は、定性データを入力する端末装置を、定量データに基づいて決定してもよい。例えば、対象者の定量データから判定された異常な状態がより深刻な場合、より多くの端末装置に定性データを入力してもらうことを決定してもよい。また、制御部１００は、対象者の異常な状態の種類に応じて定性データを入力してもらう端末装置を決定してもよい。例えば、単なる風邪の場合は第１サービス享受者（対象者）の端末装置２０のみ通知するが、精神的な要因が疑われる場合（例えば、うつ病が疑われる場合）は、第２サービス享受者（家族等）や、第３サービス享受者（学校等）のサービス享受者に定性データを入力してもらってもよい。

また、制御部１００は、対象者の属性に応じて定性データを入力してもらう端末装置を特定してもよい。例えば、第１サービス享受者（対象者）が子供（未成年）の場合、対象者自身以外に、第２サービス享受者（家族等）、第３サービス享受者（学校等）に定性データを入力してもらってもよい。

制御部１００は、対象者情報記憶領域１２２（属性情報記憶領域１２２０）に記憶されている通知先を参照して、ステップＳ１０６の通知先や、ステップＳ１０８の定性データを入力する端末装置を特定してもよい。このとき、制御部１００は、対象者情報記憶領域１２２（属性情報記憶領域１２２０）に記憶されている通知先の全てに通知してもよいし、対象者の状態や、属性に応じて通知先を選択してもよい。

例えば、制御部１００は、まず対象者本人の自端末装置（端末装置２０）に、定性データの入力要求を送信する（ステップＳ１１０）。このとき、端末装置２０（制御部２００
）は、定性データの入力要求に応じた入力画面を表示する。

対象者は、端末装置２０において、定性データを入力する。制御部１００は、端末装置２０から、対象者が入力した定性データを受信する（ステップＳ１１２）。

なお、制御部１００は、対象者以外の端末装置も定性データを入力することを特定した場合、対象者以外が使用する他の端末装置（端末装置２０、端末装置３０）に同様に定性データの入力要求を送信する（ステップＳ１１４）。そして、制御部１００は、対象者以外が使用する他の端末装置（端末装置２０、端末装置３０）から、定性データを受信する（ステップＳ１１６）。

ここで、第１サービス享受者である対象者が定性データを入力する処理（ステップＳ１１０及びステップＳ１１２）と、それ以外のサービス享受者（第２サービス享受者、第３サービス享受者）が入力するタイミングは並列処理であってもよいし、逐次処理であってもよい。また、それぞれの処理を複数回実行してもよい。

例えば、まず、制御部１００は、第１の定性データの入力として、対象者本人に定性データを入力させる（ステップＳ１１０及びステップＳ１１２）。そして、制御部１００は、対象者の定性データの入力から、他のサービス享受者に入力を促した方がよい場合、改めてステップＳ１１４及びステップＳ１１６を実行してもよい。また、このとき、制御部１００は、再度ステップＳ１１４及びステップＳ１１６を実行することで、対象者に対して先程と異なる定性データを入力させてもよい。

制御部１００は、定量データ及び定性データに基づいて、サービス等を提案する（ステップＳ１１８）。ここで、制御部１００が提案する内容は、例えば以下の内容等が含まれる。

・サービス提供者のサービスを受ける提案をし、併せてサービス種別提案を行う
・対象者の生活習慣の改善を促すための提案を行う及び／又は対象者が生活習慣の改善を促進できるよう対象者以外が支援・協力するための提案を行う
・対象者に休暇を促す等、行動についての提案を行う及び／又は対象者が休暇を取得できるよう対象者以外が支援・協力するための提案を行う

例えば、制御部１００は、睡眠を改善する場合は、睡眠そのものを改善するためにサービス種別として寝具の購入等の提案をしてもよい。また、制御部１００は、睡眠を改善する場合は、サービス種別として、睡眠アドバイザや、カウンセラーの利用を提案してもよい。また、制御部１００は、複数のサービス種別を提案し、対象者に選択させてもよい。例えば、制御部１００は、対象者の睡眠を改善する場合、「寝具を購入する」「睡眠アドバイザを利用する」といった複数のサービス種別を提案してもよい。また、制御部１００は、更にサービス種別のなかで、レコメンドを行ってもよい。例えば、制御部１００は、対象者の睡眠を改善する場合、「睡眠アドバイザを利用することがお勧めです」とレコメンドし、併せて「寝具を購入してもよいでしょう」と他のサービス種別を提案してもよい。

制御部１００は、サービス種別の提案（レコメンド）については、定性データ、定量データと、評価データとを参照して提案（レコメンド）を行ってもよい。例えば、対象者の定性データ、定量データから提案可能な複数のサービス種別のうち、評価データの点数が高いサービス種別をレコメンドしてもよい。

ここで、制御部１００は、サービス種別毎に評価データを記憶している場合は、サービス種別毎の評価データの高い順にレコメンドをすればよい。また、制御部１００は、サービス種別に含まれるサービス提供者や、サービス内容の評価値を、サービス種別毎に平均値を算出し、高い順にレコメンドをしてもよい。また、制御部１００は、サービス種別に含まれるサービス提供者や、サービス内容の評価値のうち、評価値の高い順に含まれるサービス種別をレコメンドしてもよい。

また、制御部１００は、対象者が運動不足であると判定すれば、対象者にサービス種別としてスポーツジム、自治体、コミュニティを利用することを提案してもよい。また、制御部１００は、サービス種別として、食事の提案として宅配食事サービスを提案したり、栄養関連のアドバイザの利用を提案したりしてもよい。また、制御部１００は、それ以外にも家事代行、保険の提案、心療内科の受診の提案等のサービス種別に基づいてサービスを提案してもよい。これらのサービスを提案するときに、対象者等に更にレコメンドに必要な質問（新たな定性データの入力）を行ってもよい。

なお、ステップＳ１０６において制御部１００は、対象者自身や、家族等、学校や職場といったサービス享受者に、対象者が異常の状態である又は異常な状態の可能性があることを通知するが、通知先を条件毎に変えてもよい。例えば、制御部１００は、対象者ががん、脳卒中、心筋梗塞となる可能性があることをサービス享受者に通知するが、例えば、対象者（第１サービス享受者）には通知しないとしてもよい。例えば、制御部１００は、対象者ががんや心筋梗塞等のリスクが高い疾病の可能性が高い場合は、第２サービス享受者である家族等のみに通知したり、精神疾患の可能性が高い場合は、第２サービス享受者である家族等及び第３サービス享受者である学校又は職場に通知するとしてもよい。

また、制御部１００は、対象者の状態が異常である可能性としてレベルを併せて通知してもよい。例えば、制御部１００は、対象者の状態が「直ちに危険な状態」であるか、「（直ちに危険な状態ではないが）このままでは近い将来病気になる可能性がある」等のレベルに併せたメッセージを通知してもよい。

また、制御部１００は、対象者の学校や職場に対して欠席連絡や早退連絡の通知をしてもよい。また、制御部１００は、対象者に対して、欠席連絡や早退連絡をした旨を通知してもよい。また、制御部１００は、対象者や家族等に対して、欠席連絡や早退連絡をするための操作画面を通知してもよい。

［１．３．３ レコメンド処理］
システム１は、サービス享受者に、サービスを提案する場合、適切なサービス提供者及び／又はサービス内容（以下、サービス等という）をレコメンドしてもよい。図１２は、システム１が、サービス等をレコメンドする場合のレコメンド処理の動作について説明するフローチャートである。

まず、制御部１００は、図１１のステップＳ１１８において、選択された提案、が、サービス提供者を利用するサービス種別であるかを判定する（ステップＳ１３２）。ここで、サービス提供者を利用しない場合、制御部１００は、サービス提供者を利用しないサービスの内容を対象者にレコメンドする（ステップＳ１３２；Ｎｏ→Ｓ１４２）。

ここで、サービス提供者を利用しない提案とは、例えば、生活改善（早く寝る、部屋を暗くする、運動をする等）の対象者の行動や、食事のアドバイス、学校・職場を休むといったサービス提供者を利用しなくとも対象者が対処することが可能な対処方法の提案である。

制御部１００は、サービス提供者を利用しない提案である対処方法について、評価値に基づいてレコメンドをしてもよい。例えば、制御部１００は、サービス享受者が入力した評価に基づいて、今回の対処方法の評価値を記憶する。制御部１００は、対象者に対処方法をレコメンドするときに、評価値の高い対処方法からレコメンドしてもよい。

また、サービス提供者を利用する提案が選択されている場合（ステップＳ１３２；Ｙｅｓ）、サービス等の取得をする（ステップＳ１３４）。すなわち、制御部１００は、レコメンドＤＢ１３０を参照し、今回の提案に応じてサービス提供者や、サービス内容を取得する。ここで、制御部１００は、異常判定部１０２の判定結果に応じて提供を受けるサービス提供者を提案しているが、更に適切なサービス提供者に絞り込んで取得してもよい。

例えば、制御部１００は、提案するサービス提供者の中から、定量データ及び／又は定性データに基づいて、更に絞り込んでサービス提供者を取得してもよい。具体的に、制御部１００は、定量データとして対象者が高熱を発している場合は、近所のサービス提供者を優先的に取得してもよい。また、制御部１００は、定性データとして対象者が「だるさ」を入力している場合は、近所のサービス提供者を優先的に取得してもよい。また、定量データが対象者の深刻な状態を示している場合は、定性データの内容にかかわらず、サービス提供者として大学病院等を優先的に取得してもよい。

つづいて、制御部１００は、評価データに基づいて、サービス等のレコメンドを行う（ステップＳ１３６）。例えば、制御部１００は、取得したサービス提供者の中から、評価値の高い順にソートした結果を、端末装置２０に出力する。端末装置２０は、評価値の高い順にサービス提供者を表示することでどのようなサービス提供者からサービスを受ければ評価が高いかを対象者に示すことができる。

また、制御部１００は、サービス内容を併せてレコメンドしてもよい。例えば、制御部１００は、取得したサービス内容の中から、評価値の高い順にソートした結果を端末装置２０に出力する。端末装置２０は、受信したサービス内容を表示することで、どのようなサービスを受けるとよいのかを対象者に示すことができる。

また、サービス提供者と、サービス内容とは合わせて出力されてもよいし、切り替えて出力されてもよい。

また、制御部１００は、最も評価値の高いサービス提供者、サービス内容だけを出力してもよい。利用者が、そのサービス提供者、サービス内容を選択しなかった場合、制御部１００は、次に評価値の高いサービス提供者、サービス内容を出力してもよい。

このように、ユーザは評価の高いサービス提供者を確認するだけでなく、サービス内容を確認することも可能となる。また、この評価値は、後述するように実際にサービスの提供を受けたサービス享受者が評価したものである。また、対象者の状態（定量データ及び定性データ）に近い他の者が入力した評価値が参照されることから、一般的な評価ではなく、対象者の状態に応じた評価に基づいてサービス等を選択することが可能となる。

また、制御部１００は、サービス提供者に通知が必要な場合、サービス提供者に通知を行う（ステップＳ１３８；Ｙｅｓ→ステップＳ１４０）。例えば、サービス提供者が診療やカウンセリングの予約を受け付けている場合、サービス提供者のサービス提供装置４０に対象者がサービスを受けたい旨を通知する。サービス提供装置４０のサービス提供部４０２は、対象者の端末装置２０に対して予約画面を出力する。対象者は、端末装置２０に、サービス提供者の予約画面が表示され、予約を行うことが可能となる。

［１．３．４ 評価処理］
サービス提供者からサービスを受けた場合、サービス享受者は、サービス提供者及びサービス内容の評価を行う。ここで、システム１において実行される評価処理について、図１３を参照して説明する。

まず、制御部１００は、利用者がサービスを受け終わった場合、すなわち、サービスの提供が終了した場合（ステップＳ１６２；Ｙｅｓ）、サービス享受者からサービス等の評価を定性データとして取得する（ステップＳ１６４）。

ここで、本実施形態に記載した一例では、サービス享受者が段階別に評価した内容を取得する。例えば、サービス享受者は「悪い」「少し悪い」「普通」「よい」「かなりよい」の５段階で評価してもよい。あるいは「またサービス利用したいかどうか」、「他の方に利用を勧めたいかどうか」などの観点で５段階評価してもよい。また、サービス享受者は星の数（例えば、１つの星から５つ星といった５段階評価）で評価してもよい。また、サービス享受者は、評価を数値（点数）で入力してもよい。点数で入力された評価は、更にレベル別に振り分けられ、例えば１０段階で出力されてもよい。

このように、ステップＳ１６４において入力される定性データは、サービス享受者により主観的な評価である。例えば、サービス享受者である対象者が、自分で改善している、効果があったと感じた場合は高い評価とすることができる。

制御部１００は、実際にサービスを受けた対象者の端末装置２０から定性データとして評価を取得するだけでなく、家族等の他のサービス享受者から評価を取得してもよい。例えば、子供がサービスの提供を受けた場合、その子供の家族等や、学校の職員が観察した子供の様子に基づいて、あるいは子供と話をした結果に基づいて定性データ（評価）を端末装置２０、端末装置３０で入力してもよい。

つづいて、制御部１００は、対象者の情報として定量データを取得する（ステップＳ１６６）。例えば、制御部１００は、対象者の体温や、血圧、睡眠時間といった定量データを取得する。制御部１００は、定量データを取得するタイミングとして、例えば、サービスの提供を受ける前と、受けた後で取得してもよい。また、制御部１００は、定期的に定量データを取得してもよい。

つづいて、制御部１００は、ステップＳ１６４で取得した定性データ（評価）と、ステップＳ１６６で取得した定量データに基づいて、評価データを出力する処理（評価データ出力処理）を実行する。制御部１００が、評価データ出力処理を実行し、出力した評価データを評価データ記憶領域１４２に記憶する。

これにより、評価データは、定量データに基づく評価と、定性データに基づく評価とが併せたものとして出力される。

なお、評価データは、サービス等に基づいて出力されるが、サービス種別に基づいても出力されてもよい。

［１．３．５ 評価データ出力処理］
評価データ出力処理について、図１４を参照して説明する。まず、制御部１００は、定性データに基づき、定性スコアを算出する（ステップＳ１８２）。ここで、定性スコアは、定性データに基づく評価レベルである。例えば、制御部１００は、対象者から定性データとして「悪い」「少し悪い」「普通」「よい」「かなりよい」といったレベルが選択されたときは、定性スコアはそのまま「悪い」「少し悪い」「普通」「よい」「かなりよい」と出力してもよい。また、制御部１００は、定性データとして文言が入力されたときは、文言に対応する定性スコアを出力してもよい。例えば、制御部１００は、対象者から「だるい」「熱っぽい」という文字が入力されたときは、定性スコアとして「悪い」（又は悪いに対応する値）を出力してもよい。また、制御部１００は、対象者から「好調」「よく眠れた」という文字が入力されたときは、定性スコアとして「良い」（又は良いに対応する値）を出力してもよい。

続いて、制御部１００は、定量データに基づき、定量スコアを算出する（ステップＳ１８４）。例えば、制御部１００は、定量データとして取得されている生体情報（心拍数、呼吸数、血圧、血糖値等）に基づいて。定量スコアを算出してもよい。

そして、制御部１００は、定性スコア、定量スコアから評価値を算出する。制御部１００は、対象者の情報と、評価値とを評価データとして出力する（ステップＳ１８８）。すなわち、評価データは、評価データ記憶領域１４２に記憶される。ここで、対象者の情報には、例えば対象者の属性に関する情報（例えば、年齢、性別、体重、症状等）が含まれてもよい。また、後述するように、対象者の情報には、実際に選択されたサービス提供者や、サービス内容が対処データとして含まれてもよい。

評価データ出力処理について、図１５から図１７を参照して説明する。図１５は、制御部１００が、ステップＳ１６８において、評価値を算出するときに参照するテーブルである。例えば、定量データは、「悪い」「少し悪い」「普通」「よい」「かなりよい」の５段階で定量スコアとして評価可能である。また、定性データについても、同様に５段階で定性スコアとして評価可能である。そして、定量スコアと、定性スコアとから、制御部１００は、図１５のテーブルを参照して評価値を算出する。

例えば、定量スコアが「少し悪い」、定性スコアが「普通」と判定されている場合、制御部１００は、評価値として「６０」を出力してもよい。また、評価値に対応して、評価を出力してもよい。

例えば、評価値が
０以上５０未満・・・悪い
５０以上７０未満・・・少し悪い
７０以上７５未満・・・普通
７５以上８５未満・・・よい
８５以上 ・・・かなりよい
と評価を行ってもよい。

また、定量データの評価は、対象者のフェーズ毎に判定条件を変更してもよい。例えば、図１６は、対象者のフェーズが「対処」の場合、制御部１００が定量スコアを算出するときに参照可能なテーブルの一例である。また、図１７は、対象者のフェーズが「予防」の場合、制御部１００が定量スコアを算出するときに参照可能なテーブルの一例である。例えば、図１６に示すように、対象者の定量データ（一例として、睡眠、体温血圧を図示）に基づくテーブルは、定量データを判定するときに利用する閾値と、期間とが含まれている。

例えば、制御部１００は、定量データとして、対象者の体温が「３８℃以上」の状態が３日以上続いている場合、「悪い」と判定する。なお、期間は、連続した日数であってもよいし、所定の期間内における該当する日数であってもよい。

そして、制御部１００は、定量データに基づいて「悪い」「少し悪い」等と判定した後、対応する定量スコアを算出する。例えば、制御部１００は、「悪い」場合は「１」、「少し悪い」場合は「２」といった定量スコアを算出してもよい。図１６又は図１７のテーブルを参照して算出した定量スコアに基づいて、制御部１００は、評価値を算出することが可能となる。

また、図１６、図１７のテーブルに記憶される値は、相対的な値であってもよい。例えば、通常の体温（対象者の平均体温や、平熱と感じる体温）からの差を記憶してもよい。

制御部１００は、対象者の定量データを取得することで、サービスの提供を受ける前と、サービスの提供を受けた後で、改善したか否かを評価することができる。

例えば、対象者が睡眠障害を生じているために、カウンセリングのサービスについて提供を受けたとする。このとき、制御部１００は、カウンセリングのサービスを受ける前の睡眠時間と、カウンセリングのサービスを受けた後の睡眠時間とを比較する。例えば、制御部１００は、睡眠時間が異常閾値以内に収まった場合は評価レベルを「５」、睡眠時間が増えたが、睡眠時間が異常閾値以内にまだ収まっていない場合は評価レベルを「３」、睡眠時間の改善が見られない場合は「１」等の評価を行ってもよい。

なお、上述した評価処理（評価データ出力処理）は、定性データと、定量データとを利用して評価値を算出する場合について説明したが、この評価値と対応する対象者の情報には、選択されたサービス提供者及びサービス内容を含む対処データを含めてもよい。

例えば、図１３の評価処理において、ステップＳ１６６の後に、対処データを取得する。対処データとしては、対象者が受けたサービス提供者、サービス内容に関する情報が含まれる。また、サービス提供者だけでなく、サービス種別を含んでもよい。

一例を挙げると、例えばサービス提供者が医療機関であれば、医療機関の情報（病院名、治療した医師名、投薬した内容、施術した内容）を対処データとして含めてもよい。また、サービス提供者がメーカであれば、提案した介護用品、マットレス・ベッド装置の種類、機能などが対処データに含めてもよい。また、対処データは、サービス内容であってもよいし、更にサービス提供者が追加した内容であってもよい。

そして、制御部１００は、対象者の情報に対処データを含め、対象者の情報と、評価値とを併せた評価データを出力する。すなわち、図７（ａ）（ｂ）に示すように、対象者の属性や、対処データ（図７（ａ）の場合は症状）毎に評価値を出力することが可能となる。これにより、制御部１００は、例えば、ベッド装置や、介護製品毎の評価値を出力してもよい。また、制御部１００は、対象者の状態に応じて、病院や、クリニック、介護施設毎に評価値を出力してもよい。

また、定性データとして、対象者だけでなく、サービス享受者の何れかが定性データを入力してもよい。そして、サービス享受者が入力した定性データの平均を定性データとして利用してもよい。また、サービス享受者が入力した定性データに重み付けを付けて評価値を出力してもよい。例えば、第１サービス享受者が入力した定性データ×１．０、第２サービス享受者が入力した定性データ×０．６、第３サービス享受者が入力した定性データ×０．４として定性スコアを算出し、評価値を出力してもよい。

［１．４ 動作例］
つづいて、本実施形態の動作例について説明する。まず、図１８は、端末装置２０の表示画面について、模式的に示した図である。以下の動作例は、上述した処理を利用してもよいし、以下の動作例を実現するための処理を制御部１００が実行してもよい。

［１．４．１ 第１動作例］
例えば、表示画面Ｗ１００は、サーバ装置１０から睡眠時間に関する通知を表示している画面である。例えば、表示画面に「本日の睡眠時間６時間３８分」と表示している。また、表示画面Ｗ１００は、併せて睡眠日誌（睡眠の深度や、睡眠／覚醒を示すグラフ、離床／在床を示すグラフ）を含めてもよい。

表示画面Ｗ１０２は、定性データの入力を対象者が使用する端末装置２０に表示している画面の一例である。また、表示画面Ｗ１０４は、定性データの入力を家族等が使用する端末装置２０に表示している画面の一例である。また、表示画面Ｗ１０６は、サービス享受者として、例えば定性データの入力を職場の人（上司等）や、学校の先生が使用する端末装置３０に表示している画面の一例である。

各端末装置から、端末装置の利用者が定性データを入力する。例えば、対象者には、表示画面Ｗ１０２に示すように「気分はいかがですか？」と表示される。ここで、端末装置２０を利用する対象者は、「よい」「普通」「悪い」といった定性データを選択してもよい。また、端末装置２０を利用する対象者は、自由な文章を入力してもよい。例えば、表示画面Ｗ１０２では「よく眠れて気分がよい」と対象者が直接入力してもよい。

また、家族等は、端末装置２０に表示された表示画面Ｗ１０４を利用して定性データを入力する。また、学校の先生は、端末装置３０に表示された表示画面Ｗ１０６を利用して定性データを入力する。

ここで、図１８では、対象者を含むサービス共有者は、全て「対象者の様子はよい」と入力している。そこで、サーバ装置１０は、特に問題ないと判定し「今日も元気にいってらっしゃい」というメッセージを含む表示画面Ｗ１０８を、対象者が利用する端末装置２０に表示する。

また、学校の先生も問題ないと判定していることから、家族等が利用する端末装置２０にも「学校などでもGoodでした。ご安心ください。」というメッセージを含む表示画面Ｗ１１０を表示する。

このように、図１８に示すように、対象者を含むサービス享受者が入力した定性データに基づいてサービス享受者の端末装置にそれぞれメッセージや提案が表示される。

［１．４．２ 第２動作例］
図１９を参照して、次の動作例について説明する。図１９では、まず表示画面Ｗ２００に本日の睡眠時間が領域Ｒ２００に、睡眠日誌が領域Ｒ２０２に表示されている。

次に、表示画面Ｗ２０２は、定性データの入力を対象者が使用する端末装置２０に表示している画面の一例である。また、表示画面Ｗ２０４は、定性データの入力を家族等が使用する端末装置２０に表示している画面の一例である。また、表示画面Ｗ２０６は、サービス享受者として、例えば定性データの入力を学校の先生が使用する端末装置３０に表示している画面の一例である。

ここで、対象者は、端末装置２０において、定性データを「普通」と入力している。また、対象者以外のサービス享受者は、「よい」と定性データを選択している。

表示画面Ｗ２０８は、サーバ装置１０が判定した結果を表示している。表示画面Ｗ２０８は、対象者以外のサービス享受者は、特に問題ないことを入力している。したがって、表示画面Ｗ２０８は、「家族もＧｏｏｄでした！」と、家族等からの評価に問題がないことを表示している。

しかし、対象者は定性データとして、表示画面Ｗ２０２で「普通」と選択していることから、サーバ装置１０は、睡眠時間の異常を改善する提案を行っている。表示画面Ｗ２０８で、改善するか否かの確認を、対象者に選択させる。

対象者が改善を選択すると、サーバ装置１０は、更に「睡眠クリニックに行くこと」を提案する。ここで、対象者が「予約」を選択すると、サーバ装置１０は、サービス提供者として、睡眠クリニックをレコメンドする。また、対象者が「他の提案」を選択すると、サーバ装置１０は、他の内容の提案を行う。

また、表示画面Ｗ２１０は、例えば、家族等を端末装置２０に表示される表示画面Ｗ２１０の一例である。表示画面Ｗ２１０では、サービス享受者である学校の先生の定性データの入力結果に基づく表示（学校などでもGoodでした。ご安心下さい。）がされるとともに、対象者本人の定性データの入力結果に基づく表示（少しだけ睡眠不足のようです）が表示される。

［１．４．３ 第３動作例］
図２０は、第３動作例を説明する図である。例えば、表示画面Ｗ３００は、対象者の端末装置２０に表示される画面の一例である。

例えば、表示画面Ｗ３００は、サーバ装置１０から提案された内容が表示されている。すなわち、表示画面Ｗ３００は、対象者に対して定性データを入力させる表示画面であり、「寝付き悪い」「眠り浅い」「寝具があわない」「ストレス」等が選択可能に表示されている。

ここで、対象者が「寝付き悪い」と選択すると、サーバ装置１０は、睡眠カウンセラーに相談することを提案する。表示画面Ｗ３０２は、対象者に対して睡眠カウンセラーに相談するため、面談に通うことを提案している。また、サーバ装置１０は、睡眠カウンセラーの中から、対象に適合するものを、評価データの高い順に表示している。

ここで、サーバ装置１０は、対象者の属性や、対象者の定量データ、対象者の定性データに適切な施設（ここではクリニック、病院等）を評価値の高い順に表示している。対象者は、表示画面Ｗ３０２の中から、一のサービス提供者を選択する。そうすると、当該選択されたサービス提供者（例えば、クリニック、病院等）の予約を行うことができる。例えば、表示画面Ｗ３０４は、選択されたサービス提供者（例えば、Ａ病院）の予約サイトが表示されている。対象者は、表示画面Ｗ３０４を利用することで、レコメンドされたサービス提供者の施設を予約することができる。

対象者がサービスの提供を受けた後に、評価を入力する画面が表示画面Ｗ３０６である。サーバ装置１０は、対象者に対して、定性データ（評価）を入力させるために、対象者が利用する端末装置２０に表示画面Ｗ３０６を表示する。また、サーバ装置１０は、対象者以外のサービス享受者に定性データの入力を要求してもよい。例えば、表示画面Ｗ３０８は、家族等が使用する端末装置２０に表示される表示画面Ｗ３０８の一例である。対象者が、サービスの提供を受けた後の評価を本人以外が行ってもよい。

このように、ユーザは、システム１を利用することで、適切なサービスの提案を受けることが可能となる。また、ユーザは、システム１から提案されたサービスの提供を受ける場合に、適切なサービス提供者のレコメンドを受けることができる。また、ユーザは、実際にサービスの提供を受けた後に、サービス提供者が提供したサービスについて評価をすることができる。このとき、システム１は、対象者から入力された定性データ（評価）と併せて、定量データを取得し、評価の算出に利用する。これにより、システム１では、定性データに基づく単に主観的な評価だけではなく、取得された定量データに基づき適切に対処が行われているかを客観的に評価することができる。システム１は、これらの評価を評価データとして記憶することで、次の提案、レコメンドに友好的に活用することが可能となる。

［２．第２実施形態］
なお、システム１を活用した実施形態について、第２実施形態について説明する。なお、第２実施形態は、第１実施形態のシステム１において適用されるものであり、以下異なる点を中心に説明する。

［２．１ 予防処理］
対象者のフェーズが「予防」のときにシステム１を利用する場合の一例について説明する。図２１は、システム１を対象者が「予防」のフェーズの場合に利用するときの処理の一例である。

制御部１００は、対象者のデータを取得する（ステップＳ２０２）。取得するデータは、対象者の定量データであるが、定性データを併せて取得してもよい。続いて、制御部１００（異常判定部１０２）は、異常判定処理を行い、異常の可能性があった場合は、提案処理を実行する（ステップＳ２０８）。

制御部１００は、対象者から、提案が選択されると、提案に応じて通報処理が実行されてもよい（ステップＳ２１０；Ｙｅｓ→ステップＳ２１２）。例えば、対象者の定量データとして体温が３７度５分以上ある場合、本人が定性データとして「休む」と選択された場合には、通報処理として学校や職場に欠席連絡が行われる。

また、制御部１００は、対象者が入力した定性データにかかわらず通報処理を実行してもよい。例えば、対象者の体温が３７度５分以上ある場合、自動的に学校や職場に通報（連絡）をしてもよい。これにより、例えば学校や職場から、対象者に休むことを促すことが可能となる。

とくに、近年のコロナウィルスの感染拡大に鑑み、感染症対策から、体調の悪い場合は自宅待機をする要請が大きい。システム１は、定量データに基づいて通報を学校や職場に行うことで、対象者に自宅待機を促すことも可能となる。

また、対象者がうつ病等の精神疾患を抱えている場合、家族等だけでなく、社会全体が対象者の様子を見守る必要がある。この場合、サービス享受者に適切に通報することで、サービス享受者は対象者に注意を払うことが可能となる。

また、システム１は、対象者の状態が異常であり、危険性がある（例えば、重篤な症状が生じている）場合に、例えば警備会社へ通報をしたり、医療機関へ通報をしたりしてもよい。また、システム１は、対象者の重篤度、緊急度に応じて例えば救急車の手配といった通報を行ってもよい。

そして、制御部１００は、レコメンド処理を実行することで（ステップＳ２１４）、対象者に対して適切なサービス提供者をレコメンドすることが可能となる。上述したように、制御部１００は、サービス提供者をレコメンドする場合、評価データに基づいて適切にレコメンドすることが可能となる。

制御部１００は、単に評価値が高いサービス提供者を表示するだけはなく、対象者の属性に基づいた評価データを取得する。また、評価データは、主観的になりがちな定性データ（評価）だけではく、サービスの提供前後の定量データも併せて算出された評価値を利用することで、適切にレコメンドをすることが可能となる。

そして、制御部１００は、実際に選択されたサービス提供者にサービスの依頼を行う（ステップＳ２１６）。制御部１００は、対象者がサービスの提供を受けた後に、評価データを出力する（ステップＳ２１８）。

例えば、制御部１００は、対象者や、家族等から入力されたサービスの満足度を定性データ（評価）として取得する。また、制御部１００は、対象者の定量データに基づいて、サービスを受けたことにより、どの程度改善したかを判定する。

制御部１００は、定性データと、定量データとを併せて評価データを算出し、出力する。この出力された評価データは、再度レコメンド処理や、提案処理で利用される。

なお、制御部１００は、ステップＳ２０８の提案処理や、ステップＳ２１４のレコメンド処理として、対象者の行動をレコメンドしてもよい。例えば、端末装置３０から取得した定性データに基づき、例えば「家族や先生もあなたのお休みを提案しています」というメッセージを表示してもよい。

また、制御部１００は、異常判定に使用した異常データの深刻度により、レコメンド内容を変えてもよい。例えば、制御部１００は、対象者の睡眠時間の平均時間が２～４時間の人は、カウンセラーへの相談をレコメンドする。しかし、制御部１００は、対象者の平均睡眠時間が０～２時間の人は、病院へ行くことをレコメンドしてもよい。

また、制御部１００は、提供したサービスについての評価として、例えば、感情や理由等の定性データ（例えば、言葉遣いがよい、清潔感がある、対応が早くて丁寧等）を取得してもよい。

また、ステップＳ２１４のレコメンド処理において、レコメンドＤＢ１３０を更新してもよい。例えば、レコメンドＤＢ管理部１０４により、新しいサービス提供者を追加したり、レコメンドの判定するパラメータ等を更新してもよい。例えば、レコメンドされた提案された中に所望するサービス提供者が表示されていない場合に、対象者や家族等のサービス享受者が追加してもよい。

［２．２ 対処処理］
対象者のフェーズが「対処」のときに、システム１を利用する場合の一例について説明する。図２２は、システム１を対象者が「対処」のフェーズの場合に利用するときの処理の一例である。ここで、対象者のフェーズが「対処」の場合、異常閾値は、対象者のフェーズが「予防」より厳しめにした方が好ましい。すなわち、対象者のフェーズが「対処」の場合、システム１は、対象者の定量データがより異常と判定しやすい閾値に変更するとした方が好ましい。

制御部１００は、対象者のデータを取得する（ステップＳ３０２）。取得するデータは、対象者の定量データであるが、定性データを併せて取得してもよい。続いて、制御部１００（異常判定部１０２）は、異常判定処理を行い、異常の可能性があった場合は、通報処理を実行する（ステップＳ３０８）。

例えば、制御部１００は、対象者の心拍数が所定の閾値以下や、呼吸数が所定の閾値以下になった場合に、対象者が異常の可能性があると判定する。また、対象者が転倒した場合も異常の可能性があるとして検出する。ここで、対象者が「対処」のフェーズの場合、制御部１００は、それ以前に対象者に行った処置・手術・投薬等の対処データに応じて異常の可能性を判定することが好ましい。

例えば、頻脈・徐脈になる可能性の高い薬が投与された場合、制御部１００（異常判定部１０２）は、定量データのうち、心拍数を重要度が高いパラメータとして異常の可能性を判定する。また、対象者に対して高血圧の治療をした場合、制御部１００（異常判定部１０２）は、定量データのうち、血圧を重要度が高いパラメータとして異常の可能性を判定する。

制御部１００は、対象者に異常の可能性があると判定すると（ステップＳ３０６；Ｙｅｓ）、通報処理を実行する（ステップＳ３０８）。制御部１００は、通報処理を実行すると、例えば、救急車を手配したり、サービス享受者やサービス提供者の中から最短で駆けつけ対応できる人を呼び出したり、対象者の対応に応じた処理を出力したりする。また、制御部１００は、サービス享受者である家族等や、学校又は職場へ連絡してもよい。

ここで、制御部１００は、異常の可能性があると判定したときの定量データ等から必要な情報を解析処理し（ステップＳ３１０）、必要な異常データ（生体情報等）をサービス提供者に送信する処理を実行する（ステップＳ３１２）。例えば、制御部１００は、対象者の定量データ（生体情報値）をそのまま医療機関の端末装置や、救急隊員の端末装置に送信してもよい。また、制御部１００は、人工知能により解析し、生体情報値に重み付けをして送信してもよい。また、制御部１００は、対象者に症状の入力を促してもよい。制御部１００は、入力された症状（例えば、「頭が痛い」「お腹が痛い」等）を、定性データとして、異常データに併せて送信してもよい。

適切な対処が救急隊員や、医療機関の医師により行われた場合、制御部１００は、対処データを記憶する（ステップＳ３１４）。すなわち、制御部１００は、対象者の定量データ（例えば、生体情報値や、生体情報値の遷移）、対象者が入力した定性データ、対象者に対して施された処置等の情報を、対処データとして記憶してもよい。

［３．第３実施形態］
つづいて、第３実施形態について説明する。第３実施形態は、対象者である第１サービス享受者、家族等の第２サービス享受者、学校や職場等の対象者が所属する所属先にいる者である第３サービス享受者により、それぞれ定性評価（定性データ）を入力させて、対象者の状態を判定する実施形態である。

すなわち、本実施形態では、対象者の状態を判定する判定値を算出する。そして、判定値に基づいて、対象者が異常であるか否かを判定することができる。

ここで、本実施形態は、上述した実施形態と異なる点を中心に説明する。例えば、対象者に対する定性データの入力は、図１８に示す表示画面の例で入力可能である。また、本実施形態にかかる処理を、図２３及び図２４を参照に説明する。

まず、第１サービス享受者から第３サービス享受者まで、判定値を出力するための情報を収集する。本実施形態では、制御部１００は、判定値を算出するために定量スコア（定量データ）と、定性スコアとを利用する。更に、定性スコアは表情スコア及び／又は入力スコアに基づいて算出される。

まず、制御部２００は、対象者から定量データを取得する（図２３のステップＳ１００２）。制御部２００は、例えば、対象者の心拍数、呼吸数、血圧、睡眠時間等の定量データを取得する。

続いて、制御部２００は、対象者から表情スコアを取得する（ステップＳ１００４）。例えば、表情スコアを算出する一例を、図２５（ａ）を参照して説明する。

図２５（ａ）は、例えば、制御部２００が対象者の表情の評価を行うパラメータとして、対象者の顔の血色及び、対象者の口角の角度を用いる一例を示す図である。例えば、対象者の顔の血色が普通だが、口角の角度がよいときは、表情スコアとして「２．５」と決定する。

ここで、対象者の顔の血色や、口角の角度は、端末装置２０に接続されたカメラ装置により撮影された対象者の表情から判定してもよい。制御部２００は、対象者が撮影された画像データから、これらの表情スコアを算出する。

なお、対象者の表情の評価は、対象者の外見や、動きから評価可能なものである。図２５（ａ）で説明した以外でも、例えば、制御部２００は、対象者の声の大きさ、声色、声質といった音声を入力として評価してもよい。また、制御部２００は、対象者の動き、姿勢、視線の動き、顔の表情といった外見から評価してもよい。制御部２００は、例えば、機械学習により学習された学習辞書を参照して、対象者の表情の評価を行ってもよい。

つづいて、制御部２００は、対象者から入力スコアを取得する（ステップＳ１００６）。ここで、対象者が入力可能な入力スコアは、例えば、３段階（良い、普通、悪い）で入力されてもよい。また、制御部２００は、対象者から入力された文字データに基づいて入力スコアを求めてもよい。一例を示すと、制御部２００は、対象者により「だるい」「熱っぽい」等の文字列が入力されたとき、入力スコアを「悪い」としてもよい。

同じように、ステップＳ１００８、ステップＳ１０１０は、それぞれの端末装置２０、端末装置３０が、端末装置を利用するサービス享受者から対象者の定性スコアを取得する。端末装置２０は、第２サービス享受者又は第３サービス享受者が、対象者の状態を見て、「良い、普通、悪い」の３段階を入力することで入力スコアを取得してもよい。

また、本実施形態では、入力スコアとして、３段階以外にも、例えば５段階で入力してもよい。また、入力スコアは、文字列が直接入力されてもよい。例えば、ユーザにより「体調が悪い」「だるい」といったことが入力されたとき、制御部２００は、定性スコアを「悪い」として出力してもよい。

そして、端末装置２０は、取得又は算出したデータやスコア（例えば、定量データ、表情データ、入力データ、定量スコア、表情スコア、入力スコア）を、サーバ装置１０に送信する。

また、第２サービス享受者（例えば家族等）が利用している端末装置２０は、対象者に対する入力スコア取得する（ステップＳ１００８）。また、第３サービス享受者（例えば職場の上司や、学校の先生等）が利用している端末装置３０において、対象者に対する入力スコアを取得する（ステップＳ１０１０）。

なお、端末装置２０において、各データ、各スコアを取得したタイミングでサーバ装置１０に送信すればよい。また、端末装置２０において、所定時間、サービス享受者から入力がないときは、特にスコアを取得しなくてもよい。すなわち、端末装置２０において、ステップＳ１００２からステップＳ１０１０に記載された処理は、適時実行されるものである。端末装置２０は、取得可能となったスコアをサーバ装置１０に送信すればよい。

評価依頼のための特定時刻に到達したとき（ステップＳ１０１２；Ｙｅｓ）、サーバ装置１０の制御部１００は、必要に応じてデータの入力の依頼を行う（ステップＳ１０１４）。ここで、特定時刻とは、例えばシステムが評価を行うために利用するデータやスコアを、サービス享受者に対して入力を依頼する時刻である。例えば、特定時刻は、毎日８時３０分と設定されているとき、制御部１００は、評価をするために利用される入力データ（入力スコア）を入力する要求を端末装置２０に対して行う。

例えば、ステップＳ１００２において、対象者の定量データが取得できていないとき、制御部１００は、端末装置２０に対して定量データを取得する要求を送信する。また、ステップＳ１００４において、対象者の表情スコアが取得できてきないときは、制御部１００は、端末装置２０に対して表情スコアを取得する要求を行う。

また、制御部１００は、ステップＳ１００６、ステップＳ１００８、ステップＳ１０１０において、入力スコアが取得できていない端末装置２０に対して、入力データを入力してもらう要求を行う（ステップＳ１０１４）。

また、制御部１００は、定量スコア、定性スコアを取得する（ステップＳ１０１６）。ここで、制御部１００は、取得した定量データから、定量スコアを求める。例えば、図１６で示したように、定量データに対応する定量スコア（悪い、少し悪い、普通、よい、かなりよい）を求めてもよい。また、制御部１００は、ここでは定量スコアを求めず、判定値を算出するときに、定量データを直接参照してもよい。

また、制御部１００は、入力スコア及び／又は表情スコアから定性スコアを算出する。ここで、定性スコアを算出する方法の一例として、図２５（ｂ）を参照して説明する。

まず、制御部１００は、それぞれのサービス享受者が入力した入力データに基づく入力スコアと、対象者の表情から算出される表情スコアを算出する。ここで、入力データは定性データの１つであり、入力者の主観に基づいて入力されているデータである。そして、制御部１００は、対象者の表情スコアと、入力スコアとの合計値とを定性スコアとする。

例えば、制御部１００は、対象者の表情スコアが「良い」と判定されているとき、表情スコアを「２．５」とする。また、制御部１００は、対象者により体調について「悪い」と入力されているとき、入力スコアを「０．５」とする。制御部１００は、表情スコア「２．５」と入力スコア「０．５」との合計「３」を定性スコアとする。また、図２６（ｃ）を参照すると、「３」に対応すると、対象者の定性スコアに基づく状態は「普通」となる。

このように、対象者の定性スコアは、対象者が主観的に入力した入力スコアに加えて、対象者の表情に基づく表情スコアが加味されて定性スコアが算出される。

同じように、第２サービス享受者、第３サービス享受者が主観的に入力した対象者の状態を示す入力スコアに基づいて、制御部１００は、それぞれの定性スコアを算出する。制御部１００は、第２サービス享受者の定性スコアは、第２サービス享受者が入力した入力スコアと、表情スコアとを利用して算出する。また、制御部１００は、第３サービス享受者の定性スコアは、第３サービス享受者が入力した入力スコアと、表情スコアとを利用して算出する。

また、第２サービス享受者、第３サービス享受者が入力した入力スコアに対応する対象者の表情スコアは、第１サービス享受者の端末装置２０で取得された表情スコアであってもよいし、第２サービス享受者、第３サービス享受者のそれぞれの端末装置２０で取得可能な表情スコアであってもよい。例えば、家族等が、家族等の利用している端末装置２０で定性スコアを入力した後、家族等が当該端末装置２０を使って対象者を撮影し、対象者の表情スコアを別に取得してもよい。

また、表情スコアと、入力スコアとの一方しかないときは、図２５（ｂ）の右側の列の値を定性スコアとして使用する。例えば、入力スコアの入力が対象者からないとき、制御部１００は表情スコアに基づいて定性スコアを出力する。例えば、制御部１００は、表情スコアが「良い」に対応するものであれば、定性スコアとして「５」を出力する。また、表情スコアがないとき、制御部１００は、入力スコアに基づいて定性スコアを出力する。この場合、入力スコアが「良い」であれば、定性スコアは「５」と出力される。また、入力スコアが「普通」であれば定性スコアは「３」、「悪い」であれば定性スコアは「１」が出力される。

続いて、評価処理を実行する特定時刻となったときは（ステップＳ１０１８；Ｙｅｓ）、制御部１００は評価処理を実行する（ステップＳ１０２０）。制御部１００は、評価処理を実行することで、定量データ（定量スコア）や、定性スコアに基づいて、対象の状態が評価されることで、対象者の状態を判定する。

図２６は、対象者の定量データ（定量スコア）及び定性データ（定性スコア）から、判定値を算出するときに利用されるテーブルである。制御部１００は、例えば、定量データが「体温」のときは、一番上の表を利用し、定量データが「睡眠時間」のときは、中央の表を利用する。また、制御部１００は、定量データが心拍数のときは、下段の表を利用する。図２６の表は、例えば記憶部１２０に判定値テーブルとして記憶してもよい。

例えば、制御部１００は、定量データが対象者の体温のときは、上の表を利用するが、対象者の体温が「３７．０℃」のとき、定量データは「３７．０℃」となる。この場合、定量スコアは「少し悪い」状態となる。そして、対象者の定性データが「普通」であれば、当該対象者の判定値は「６０」となる。

制御部１００は、第１のサービス享受者（対象者本人）、第２のサービス享受者（家族等）、第３のサービス享受者（職場の上司、学校の先生等）のそれぞれの判定値を算出する。ここで、図２６の判定値テーブルは、第１のサービス享受者（対象者本人）、第２のサービス享受者（家族等）、第３のサービス享受者（職場の上司、学校の先生等）によって、異なるパラメータのテーブルを記憶部１２０に記憶してもよい。

そして、制御部１００は、対象者のフェーズに応じて、対象者の状態を「良い」「悪い」と判定してもよい。例えば、対象者のフェーズが「予防」のとき、制御部１００は、判定値が「５１点以上」であれば対象者の状態は「良い」と判定し、「５０点以下」であれば対象者の状態は「悪い」と判定する。

また、対象者のフェーズが「生活支援」のとき、制御部１００は、判定値が「６１点以上」であれば対象者の状態は「良い」と判定し、「６０点以下」であれば対象者の状態は「悪い」と判定する。

このように、第１のサービス享受者（対象者本人）、第２のサービス享受者（家族等）、第３のサービス享受者（職場の上司、学校の先生等）の定量スコア及び定性スコアの状態から、各サービス享受者から対象者に対しての評価が行われる。

そして、制御部１００は、判定値に基づいて対象者に異常があると判定したときは（ステップＳ１０２２；Ｙｅｓ）、必要に応じた通知先に異常を通知する（ステップＳ１０２４）。

ここで、制御部１００は、第１のサービス享受者（対象者本人）、第２のサービス享受者（家族等）、第３のサービス享受者（職場の上司、学校の先生等の所属先）から、対象者が「良い」「悪い」と判定されていることから、当該判定に基づいて、対象者に異常があるかを判定する。

図２７は、対象者の異常を判定するルールが記憶されている異常判定テーブルである。異常判定テーブルは、例えば記憶部１２０に記憶されてもよい。図２７に示すように、第１のサービス享受者（対象者本人）、第２のサービス享受者（家族等）、第３のサービス享受者（職場の上司、学校の先生等の所属先）の判定結果としての対象者の評価「良い」「悪い」「評価なし（－）」に対応して、対象者が異常か否かを判断した結果が示されている。

例えば、図２７を参照すると、制御部１００は、対象者本人が自己の評価が「悪い」と判定したときは、対象者に異常があると判定する。また、対象者が自己の評価が「良い」と判定されたとしても、制御部１００は、例えば家族等によって対象者の評価が「悪い」と判定された状態が２日続くかまたは４日中２日あったときは、対象者に異常があると判定する。

また、制御部１００は、判定値が「０」については、対象者を「対処」のフェーズに遷移させ、必ず異常を通知してもよい。例えば、図２６では、対象者の定量データが心拍数において、心拍数の状態が０～２０ｂｐｍの間で３分以上継続したとき、制御部１００は、対象者のフェーズを対処フェーズに遷移し、異常を通知すると設定してもよい。この場合、上述した判定結果に関わらず、制御部１００は、異常を通知するとしてもよい。

図２４は、評価値に基づき、サービス判定を行うことが可能な処理フローである。例えば、制御部１００は、評価値に基づき、サービスの評価を更新する（ステップＳ１１０２）。例えば、対象者がサービスの提供を受けた前後に評価が上昇したのであれば、サービス提供者に対する評価が上昇する。また、対象者がサービスの提供を受けた前後で評価が下降したのであれば、サービス事業者に対する評価値が下降する。ここで、サービス提供者に対する評価の判断基準として、判定値を利用してもうよい。例えば、判定値が上昇したということは、評価が上昇したと判断してもよい。他方、判定値が下降しているということは、評価が下降したと判断してもよい。

また、制御部１００は、サービス提供者に、対象者の状態を通知してもよい（ステップＳ１１０４）。例えば、制御部１００は、本日の定量データ、定性データ、定量スコア、定性スコアをサービス提供者に送信してもよい。制御部１００は、サービス提供者からの情報に基づいて、サービス提供者や、サービスのレコメンドを実行してもよい（ステップＳ１１０６）。

例えば、定量スコアが「悪い」「少し悪い」状態であったり、定性スコアが「悪い」「少し悪い」状態であったりしたときに、制御部１００はレコメンドを実行してもよい。また、判定値に基づいて「悪い」と判定されるとき、制御部１００はレコメンドを実行してもよい。

ここで、制御部１００は、対象者本人又は家族等、所属先の上司、管理者等からサービスが受諾されたときは（ステップＳ１１１０）、サービスを提供する（ステップＳ１１１２）。そして、第１のサービス享受者（対象者本人）、第２のサービス享受者（家族等）、第３のサービス享受者（職場の上司、学校の先生等の所属先）から評価を取得する（ステップＳ１１１４～ステップＳ１１２２）。当該処理は、図２３のステップＳ１００２～ステップＳ１０１０と同様の処理であるため、説明を省略する。

そして、上述の処理の後、定量データ及び定性データから対象者がサービスの提供を受けた後の評価値が算出され、評価値に基づいてサービス提供者の評価（点数）を更新する。

［４．効果］
上述したように、本実施形態に開示した態様によれば、複数のサービスの中から対象者に対してサービスに関する情報を提示したり、サービスの中から評価のよいサービスをレコメンドしたりすることが可能となる。

また、本開示によれば、サービスの情報を提示して提案する場合、サービス享受者が行った評価を参照し、評価の高いサービスから提案を行うことが可能となる。また、サービスの提案は、異なるサービス種別を複数示してもよいし、同じサービス内で異なるサービス提供者を複数示してもよい。また、異なるサービス種別と、異なるサービス提供者とを並行して提案してもよい。

また、本開示によれば、評価を行う場合に、サービス享受者の主観的な評価である定性データと、対象者（第１サービス享受者）の生体情報や、対象者の状態といった客観的なデータである定量データから評価を行うことができる。したがって、対象者としては効果があったと感じても、定量データに基づけば対象者の状態が改善されていない等と実際には効果が薄かったサービスの評価が低くなり、レコメンドされにくくなる。また、対象者としては、施設のスタッフの対応等で主観的な評価を低くしたとしても、定量データに基づけば対象者の状態が改善されている等と実際に効果があるサービスの評価を高くすることで、レコメンドされやすくなる。

［５．変形例］
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。

また、実施形態において各装置で動作するプログラムは、上述した実施形態の機能を実現するように、ＣＰＵ等を制御するプログラム（コンピュータを機能させるプログラム）である。そして、これら装置で取り扱われる情報は、その処理時に一時的に一時記憶装置（例えば、ＲＡＭ）に蓄積され、その後、各種ＲＯＭやＨＤＤ、ＳＳＤの記憶装置に格納され、必要に応じてＣＰＵによって読み出し、修正・書き込みが行なわれる。

また、市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送したりすることができる。この場合、サーバコンピュータの記憶装置も本発明に含まれるのは勿論である。

なお、上述した実施形態において、システム１は、単に提案処理のみを実行してもよい。例えば、対象者がサービスの提供を受ける場合、サービス提供者の情報や、サービス内容について、評価データにもとづく情報の提供を行ってもよい。

例えば、対象者が近所の病院にかかろうとしたとき、近所の病院の評価をランキングで表示する。対象者は、表示されたランキングを参照して、評価の高い病院を選択することができる。この表示されている評価は、サービスを受けた者の定性データに基づく主観的な評価だけでなく、定量データに基づく客観的な評価も含まれている。したがって、対象者としては、適切な評価に基づいて病院を選ぶことができる。

１ システム
１０ サーバ装置
１００ 制御部
１０２ 異常判定部、１０４ レコメンドＤＢ管理部
１２０ 記憶部
１２２ 対象者情報記憶領域
１２２０ 属性情報記憶領域
１２２１ 定量データ記憶領域
１２２２ 定性データ記憶領域
１２２３ 対処データ記憶領域
１２２４ 異常閾値テーブル
１３０ レコメンドＤＢ
１４０ サービス提供者情報記憶領域
１４２ 評価データ記憶領域
２０、３０ 端末装置
２００ 制御部
２０２ 定量データ取得部
２１０ 記憶部
２１２ 定量データ記憶領域
２１４ 定性データ記憶領域
２３０ 入力部
２４０ 出力部
２５０ 通信部
２６０ 取得部
２２ 取得装置
４０ サービス提供装置
４００ 制御部
４０２ サービス提供部
４２０ 記憶部
４３０ 通信部

Claims (5)

1. １の端末装置から、対象者の定量データを取得し、第１の評価を行うステップと、
   １の端末装置を含む複数の端末装置から、対象者に関する定性データを取得し、第２の評価を行うステップと、
   前記第１の評価と、前記第２の評価とから、対象者の状態を判定するステップと、
   を含むシステム。
2. 前記定性データは、前記対象者の状態を主観的に示すデータと、前記対象者の状態を表情から取得する表情データとに基づいて取得される
   請求項１に記載のシステム。
3. 複数のサービスの評価データを記憶する記憶部を有しており、
   前記対象者に対して、前記評価データに基づいて、前記サービスの情報を提供するステップを含み、
   前記第１の評価と、前記第２の評価とに基づいて、前記評価データを算出する
   請求項１に記載のシステム。
4. 前記対象者から取得した生体情報に基づいて生体情報値を算出するステップを有し、
   前記定量データは、前記生体情報値に基づくデータである請求項１に記載のシステム。
5. 前記生体情報値の異常値を判定するための閾値を記憶する記憶部を有しており
   前記生体情報値と、前記閾値とを比較することで、前記第１の評価を行う請求項４に記載のシステム。

Images