特許 7054166 健康支援システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-04-05

(45)【発行日】2022-04-13

(54)【発明の名称】健康支援システム

(51)【国際特許分類】

   G16H 20/30 20180101AFI20220406BHJP

【ＦＩ】

G16H20/30

【請求項の数】 5

(21)【出願番号】P 2017217011

(22)【出願日】2017-11-10

(65)【公開番号】P2019087182

(43)【公開日】2019-06-06

【審査請求日】2020-06-19

【前置審査】

(73)【特許権者】

【識別番号】503362784

【氏名又は名称】栢 孝文

(74)【代理人】

【識別番号】100166372

【弁理士】

【氏名又は名称】山内 博明

(72)【発明者】

【氏名】栢 孝文

【審査官】橘 均憲

(56)【参考文献】

【文献】特開２０１７－１６２３５４（ＪＰ，Ａ）

【文献】特開２０１５－０２６２０８（ＪＰ，Ａ）

【文献】特開２０１５－２２５６２７（ＪＰ，Ａ）

【文献】特開平７－１７５４０４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１３／０１１７０４０（ＵＳ，Ａ１）

【文献】麻生 祐輝，外６名，グループ内貢献心とグループ間競争心を刺激するヘルスケア促進システム，情報処理学会研究報告［ｏｎｌｉｎｅ］ ，日本，情報処理学会，2017年11月08日，Vol.2017-MBL-85, No.20，pp.1-6

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

Ｇ１６Ｈ １０／００－８０／００

(57)【特許請求の範囲】

【請求項1】

各ユーザから当該ユーザ自身の年齢・性別・身長・体重などの個人データを含む健康に関する問診データを受信する受信手段と、
前記受信手段によって受信された問診データから当該ユーザの属性に基づくグループを特定するグループ特定手段と、
前記グループ特定手段によって特定されたグループに属する特定のユーザの問診データ又はこれに基づく情報を当該グループに属する他のユーザに対して報知する報知手段とを備える、健康支援装置を有し、
前記各ユーザのユーザ端末が有するＧＰＳ機能と地図アプリケーションソフトウェアとに基づいてユーザ端末本体の現在地を特定する現在地特定手段と、
前記現在地特定手段によって特定されたユーザ端末本体の現在地が所定時間内に移動するか否かを判定する判定手段と、
前記判定手段による判定結果に従って活動度の高低を算出する算出手段と、
前記算出手段による算出結果をユーザに報知する報知手段と、
を備える健康支援システム。

【請求項2】

前記所定時間内における前記現在地が定期的に同じ行動パターンであることが確認された場合に、活動度の高低の算出に必要な問い合わせを行う問い合わせ手段を備え、
前記算出手段は、前記判定手段による判定結果に代えて前記問い合わせ手段による問い合わせに対する回答結果に従って活動度の高低を算出する、請求項１記載の健康支援システム。

【請求項3】

前記算出手段は、前記ユーザ端末に対して手入力する行動内容に基づく活動度の高低も算出する、請求項１記載の健康支援システム。

【請求項4】

前記算出手段は、前記ユーザ端末を含む機器の利用回数・頻度に基づく活動度の高低も算出する、請求項１記載の健康支援システム。

【請求項5】

前記算出手段は、更に、前記機器に対する利用開始から終了までの時間も考慮して活動度の高低も算出する、請求項４記載の健康支援システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、健康支援装置及び健康支援システムに関し、特に、体にいいと言われている仮説の妥当性を検証する、健康支援装置及び健康支援システムに関する。

【背景技術】

【0002】

特許文献１には、本出願人による、複数のミッションを含むｎ回目のミッションデータを複数のユーザ端末に対して送信するとともに、当該ｎ回目のミッションデータを遂行したユーザから各々送信されるｎ回目の問診データ及び前記ｎ回目のミッションデータに係るユーザのミッション達成率を受信する手段と、前記ｎ回目のミッションデータに係るユーザのミッション達成率を考慮して前記ｎ回目の問診データで改善が見受けられる問診事項が存在する場合に、前記複数のミッションのうち少なくとも一のミッションの負荷を高めたｎ＋１回目のミッションデータを前記ユーザ端末に対して送信するとともに、前記ｎ＋１回目のミッションデータを遂行したユーザから各々送信されるｎ＋１回目の問診データ及び前記ｎ＋１回目のミッションデータに係るユーザのミッション達成率を受信する手段と、前記ｎ＋１回目のミッションデータに係るユーザのミッション達成率を考慮して、前記ｎ＋１回目の問診データで前記問診事項に更なる改善が見受けられる場合に前記一のミッションが当該問診事項の改善に寄与していると判定する手段と、を備える仮説検証装置が開示されている。特許文献１によれば、やがてはミッションの各々が、どのようなユーザにとって好ましいかということが非常に高確度でわかるようになり、これにより、ユーザにおいても自身にとって有益なミッションを遂行しようというインセンティブが働くことになるという効果が得られる。

【先行技術文献】

【特許文献】

【0003】

【文献】特許６１５２３１３号公報

【発明の開示】

【発明が解決しようとする課題】

【0004】

特許文献１に開示されている発明によって、ユーザにとって有益なミッションをユーザに対して提供することによって、ユーザに当該ミッションを遂行しようというインセンティブを与えることができるようになったが、当該ミッションを継続的に遂行させるという点については改善の余地があることが分かった。

【0005】

実際に、折角判明させたユーザにとって有益なミッションが、ユーザによって継続的に利用されないとなするならば、健康状態の向上効果も限定的となる。したがって、ミッションを継続的に遂行させるために改善することは重要である。

【0006】

そこで、本発明は、有益な情報に基づいて健康状態を向上させるために、ユーザにとって有益なミッションをユーザに継続的に遂行させるインセンティブを付与することを課題とする。

【課題を解決するための手段】

【0007】

本発明者は、ミッションを継続的に遂行させるためには、健康の見える化などによって、そのユーザの健康状態が他のユーザの健康状態と相対的にどのような位置にあるか、簡単に言うと、そのユーザの健康状態の良し悪しを報知することが役立つのではないかと考えるに至り、この観点からの研究を行うことで、一定の成果が得られることが分かった。

【0008】

すなわち、上記課題を解決するための本発明の健康支援装置は、
各ユーザから当該ユーザ自身の年齢・性別・身長・体重などの個人データを含む健康に関する問診データを受信する受信手段と、
前記受信手段によって受信された問診データから当該ユーザの属性に基づくグループを特定する特定手段と、
前記特定手段によって特定されたグループに属する特定のユーザの問診データ又はこれに基づく情報を当該グループに属する他のユーザに対して報知する報知手段とを備える。

【0009】

こうすると、あるユーザに対して、そのユーザと個人データが共通する特定のユーザの健康状態を報知することができるので、例えば
・特定のユーザとしてグループ内で健康状態が良いユーザを選定すれば、当該特定のユーザを目標に健康状態の向上を図ろうというインセンティブを付与るすことができるであろうし、
・特定のユーザとしてグループ内で健康状態を数値化した場合に中間値或いは平均値に近いユーザを選定すれば、そのユーザよりも数値化した健康状態が悪ければそれを越えようとさせ、そのユーザよりも数値化した健康状態が良ければ現状を維持或いは更なる向上を目指そうとさせようとするインセンティブを付与るすことができるであろうし、
・特定のユーザとしてグループ内で初回の問診データを相互に比較して共通点が多いユーザを選定するようにすれば、そのユーザの現在の健康状態が初回よりも良ければ、そのユーザを目標として健康状態の向上を目指そうとさせようとするインセンティブを付与るすことができるであろうし、
・特定のユーザとしてグループ内でランダムにユーザを選定するようにすれば、例えばそのユーザよりも健康状態が劣っている部分があれば、その部分を是正するようにし、劣っていない部分があれば、その部分については少なくとも現状維持をしようとするインセンティブを付与るすことができるであろう。

【0010】

前記問診データには、ユーザの普段の食生活、例えば、外食の頻度、コンビニエンスストアで販売されている弁当を食べる頻度が含まれる。また、問診データには、普段の頭痛の有無、普段の腹痛の有無、風邪の引きやすさ、体を動かす習慣の有無等を含む活動度のいくつかが含まれる。

【0011】

また、本発明の健康支援システムは、
上記健康支援装置と、
前記他のユーザが遂行すべきミッションを特定する仮説検証装置と、
を備える。

【図面の簡単な説明】

【0012】

【図1】本発明の実施形態の健康支援システムの模式的な構成図である。

【図2】図１の問診データ等ＤＢ４００に登録されるグループＡの各ユーザの問診データ等の例を示す図である。

【図3】図１の作成手段２６０によって作成されるグループＡの各ユーザの問診データ等及び判定結果の例を示す図である。

【図4】図１に示す管理者サーバ２００の動作のうち仮説検証に関する動作を示すフローチャートである。

【図5】図１に示す管理者サーバ２００の動作のうち仮説検証に関する動作を示すフローチャートである。

【図6】図１の作成手段２６０によって作成されるユーザに報知される対比表の例を示す図である。

【符号の説明】

【0013】

１００ ユーザ端末
２００ 管理者サーバ
２１０ 通信手段
２２０ グループ特定手段
２３０ ミッションデータ選択手段
２４０ 登録手段
２５０ 判定手段
２６０ 作成手段
３００ 属性－ミッションデータベース（属性－ミッションＤＢ）
４００ 問診データ等データベース（問診データ等ＤＢ）
５００ 管理者端末

【発明の実施の形態】

【0014】

以下、本発明の実施形態について、図面を参照して説明する。なお、本明細書では、主として、まず、ユーザが遂行すべきミッションを特定することに関する説明を行い、その後に、特定されたミッションをユーザに継続的に遂行させることに関する説明を行う。

【0015】

図１は、本発明の実施形態の健康支援システムの模式的な構成図である。図１には、以下説明する、ユーザ端末１００と、管理者サーバ２００と、属性－ミッションデータベース（以下、「属性－ミッションＤＢ」と称する。）３００と、問診データ等データベース（以下、「問診データ等ＤＢ」と称する。）４００と、管理者端末５００とを示している。

【0016】

ユーザ端末１００は、ユーザによって操作される端末であり、主として、管理者サーバ２００から送信される、仮説であるところの複数のミッションを含むミッションデータを受信し、ユーザによる当該ミッションの遂行後に、当該ユーザの問診データを送信するものである。ユーザ端末１００は、管理者サーバ２００との間で無線又は有線通信を行うことが可能な、携帯電話機、スマートフォン、パーソナルコンピュータなどとすることができる。ユーザ端末１００は、スマートフォン、ノート型パーソナルコンピュータのような携帯型端末であってもよいし、デスクトップ型パーソナルコンピュータのように据置型端末であってもよい。

【0017】

管理者サーバ２００は、本実施形態の健康支援システムの管理者によって管理されるサーバである。管理者サーバ２００は、仮説検証装置としての役割と健康支援装置としての役割とを担う。管理者サーバ２００は、以下説明する、通信手段２１０と、グループ特定手段２２０と、ミッションデータ選択手段２３０と、登録手段２４０と、判定手段２５０と、作成手段２６０と、を備える。これらの各手段による機能は、たとえば、ＣＰＵとメモリとの協働によって実現すればよい。

【0018】

通信手段２１０は、ユーザ端末１００から送信される問診データ等の各種データを受信するとともに、ユーザ端末１００に対してミッションデータなどの各種データを送信するものである。なお、問診データとは、病院等においてなされる健康診断或いは初診の際に被験者或いは患者から回答してもらう性別、年齢、体重などの個人データ、飲酒量、喫煙量など、可能であればこれらに加えて血圧、血糖値、更には、目覚めの善悪、頭痛持ち・腹痛持ちの有無、持病の有無、風邪の引きやすさ、体を動かす習慣の有無等を含む活動度などの種々の属性データを適宜含められるようにしている。加えて、ユーザの普段の食生活、例えば、外食の頻度、コンビニエンスストアで販売されている弁当を食べる頻度を含められるようにしている。

【0019】

グループ特定手段２２０は、通信手段２１０によって受信された問診データから、当該
ユーザの属性に基づくグループを特定するものである。ユーザの属性とは、性別、年齢、体重などのユーザの個人データに関する属性をいい、そのグループとは、例えば、「『やせ型』の『３０代男性』で『一日当たりタバコ１０本程度吸う』、『目覚めの悪さを自覚している』グループＡ」、「『肥満型』の『４０代女性』で『週にビール３本・日本酒３合程度飲む』グループＢ」、「『闘士型』の『２０代男性』で『風邪をひきやすいと自覚している』グループＣ」などに区分けされたグループをいう。なお、ここまで細かい条件でグループ分けするのではなく、例えば、性別・年齢（年代）だけでグループ分けしてもよいし、以下の例に示す程度の条件でグルーピンプ分けしてもよい。

【0020】

ここで、仮にミッションの妥当性を検証するために、研究者等がモニターを募ろうとしても、通常、上記のような細分化したグループを実現するのに充分な何万人ものモニター数を集めることは非常に困難である。したがって、ここまで細分化したグループを実現できず、「やせ型の３０代男性のグループ」、「肥満型の４０代女性で多少飲酒をするグループ」、「闘士型の２０代男性のグループ」といったグループ分け程度しか行うことができない。

【0021】

しかし、本実施形態の健康支援システムの場合には、ユーザ端末１００さえ操作できればよく、今日のネットワークの進歩、ユーザ端末の普及率からすれば、ユーザの総数は非常に大きな数となるので、上記のような細分化したグループを容易に実現することができる。

【0022】

ミッションデータ選択手段２３０は、グループ特定手段２２０によって特定されたグループ情報に基づいて、属性－ミッションＤＢ３００を参照し、当該グループ情報に対応するミッションデータを選択するものである。また、ミッションデータ選択手段２３０は、ユーザ端末１００からミッション終了後に問診データが送信されてきた場合に、当該問診データに含まれるミッションの達成率、問診データにおける属性の変化等に基づいて、次にユーザに課すミッションを選択するものである。

【0023】

登録手段２４０は、通信手段２１０によって受信された問診データ等の各種データを、問診データ等ＤＢ４００に登録するものである。具体的には、各々のグループに属するユーザ毎に、相互に問診データ等を経時的に紐づけて登録する。

【0024】

判定手段２５０は、ミッションデータ選択手段２３０によって選択されたミッションデータの遂行による、ユーザの問診データにおける属性の変化の有無を判定するものである。判定手段２５０は、問診データ等ＤＢ４００に登録されている各種データに基づいて、主として、ユーザの属するグループ毎に、ユーザ毎のミッションの達成率を考慮してユーザの属性の変化の有無を判定する。

【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】

本実施形態では、ユーザ端末１００としてスマートフォンを用いる場合を例に説明したが、パーソナルコンピュータを用いる場合には問診データ等はブラウザを通じて管理者サーバ２００に送信するようにすればよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】