健康管理システム、健康管理端末、健康管理プログラム、サービスサーバプログラムおよび記録媒体
【課題】実際に健康改善の取り組みをおこなっているユーザが報奨の申し込みをおこなうことができる健康管理システムを提供する
【解決手段】本発明に係る健康管理システムでは、健康機器１０２が、ユーザの生理状態および運動状態の少なくとも何れかを測定し、測定結果を健康データとして健康管理端末１０１に供給する。健康管理端末１０１は、報奨提供元サーバ１０４から送信される報奨情報に含まれる申込条件情報と健康機器１０２から供給された健康データとを用いて、健康データが申込条件を満たしているか否かを判定し、満たしている場合に報奨の申込をおこなう。また、報奨の申し込みがおこなわれるまでは、カバー画像が健康管理端末１０１に表示される。
【解決手段】本発明に係る健康管理システムでは、健康機器１０２が、ユーザの生理状態および運動状態の少なくとも何れかを測定し、測定結果を健康データとして健康管理端末１０１に供給する。健康管理端末１０１は、報奨提供元サーバ１０４から送信される報奨情報に含まれる申込条件情報と健康機器１０２から供給された健康データとを用いて、健康データが申込条件を満たしているか否かを判定し、満たしている場合に報奨の申込をおこなう。また、報奨の申し込みがおこなわれるまでは、カバー画像が健康管理端末１０１に表示される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、健康改善の取り組みをおこなうユーザの健康情報を利用して、報奨の申し込みをおこなう健康管理システム、健康管理端末、健康管理プログラムおよびサービスサーバプログラムに関するものである。
【背景技術】
【０００２】
近年、問題となっているメタボリックシンドロームおよび生活習慣病などの疾患は、運動および食事などの生活習慣の悪さが原因となっている。これらの疾患にならないためには、その原因である生活習慣を改善することが必要不可欠である。しかしこれらの疾患は痛みなどを伴わないため、ユーザにとっては切迫感がない。そのため、生活習慣を改善するための行動をユーザが継続できないという課題が生じる。
【０００３】
ユーザのモチベーションを高めて、生活習慣を改善するためのユーザの行動を継続させる手段として、従来では、ユーザが利用する健康機器、ならびにパソコンおよび電子辞書など、ユーザが所有する端末を利用して、特定のコンテンツを入手したり、アニメーションおよび音楽情報などのコンテンツの表示内容を変化させたりして、ユーザのモチベーションを高める手段がある。
【０００４】
特許文献１に記載の健康管理方法では、ユーザが特定の製造者の健康商品を購入したり、特定の販売店で健康商品を購入したりすることによって、ユーザにサービスポイントが付与される。ユーザは、この付与されたポイントを利用して、趣味および娯楽、商品の広告ならびにニュースなどのコンテンツを入手することができる。ユーザは、これらのコンテンツを入手することをモチベーションとして、健康商品を継続して購入することになる。また、コンテンツを提供する前に、ユーザに対してアンケートをおこなうため、アンケート情報に基づいて、コンテンツ情報およびポイント情報の魅力を高めることができる。
【特許文献１】特開２００２−１５０７２号公報（平成１４年１月１８日公開）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に記載の健康管理方法では、ユーザが健康商品を購入するだけでポイントが付与されるため、購入後に実際にその健康商品を本人が利用または摂取したかどうかは考慮されていない。例えば、ユーザ以外の人が利用するための健康商品をユーザが購入し、ポイントを貯めるといった方法も可能である。この場合は、ユーザ自身が健康商品を利用しないため、生活習慣改善という目的が達成できないことになる。
【０００６】
一方で、健康商品の製造者や販売者にとっては、ユーザからのアンケート情報は自社製品の改善および改良のためには有益な情報となる。しかしながら、特許文献１に記載の健康管理方法においては、上記したように、健康商品を利用するユーザと、健康商品を購入するユーザとが一致しない可能性がある。そのため、健康意識および該当する健康商品に対するアンケート情報としては信憑性に欠ける。
【０００７】
そこで、本発明は上記の問題点に鑑みてなされたものであり、その目的は、実際に健康改善の取り組みをおこなっているユーザが報奨の申し込みをおこなうことができる健康管理システムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明に係る健康管理システムは、上記の課題を解決するために、健康情報測定装置と、報奨提供元サーバと、健康管理端末とを含む健康管理システムであって、上記健康情報測定装置は、ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、上記測定手段によって得られる測定結果を健康情報として上記健康管理端末に供給する健康情報供給手段とを備えており、上記報奨提供元サーバは、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記健康管理端末に対して直接または間接に送信する第１報奨情報送信手段を備えており、上記健康管理端末は、上記報奨情報を受信する報奨情報受信手段と、上記健康情報を上記健康情報測定装置から取得する健康情報取得手段と、上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴としている。
【０００９】
なお、健康情報は、測定結果である数値または数値の集合のみならず、測定した日時も併せて含んでいてもよい。また、判定手段が健康情報を用いる場合、測定値をそのまま用いる場合のみならず、測定値に対して特定の処理を施して得られる値を用いる場合も含むことを意図している。
【００１０】
上記構成によれば、健康管理端末は、報奨提供元サーバにある報奨情報を、報奨提供元サーバの第１報奨情報送信手段から直接または間接に受信し、取得する。また、健康情報測定装置は、ユーザの生理状態および運動状態の少なくとも何れかを表す健康情報を測定し、測定結果を健康管理端末に供給する。報奨情報には、報奨の申し込みに必要な健康情報の条件を指定する条件情報が含まれている。健康管理端末は、健康情報測定装置によって供給された健康情報がこの条件情報に指定される条件を満たしているかを判定できる。健康管理端末は、この条件を満たしていると判定した場合に、報奨の申し込みをおこなうことができる。健康管理端末は、報奨の申し込みをおこなうまで、素材情報を提示する。
【００１１】
このように、実際に測定したユーザの生理状態および運動状態の少なくとも何れかを、健康情報として用いるため、実際に生活習慣改善のための行動を取っているユーザのみが報奨の申し込みをおこなうことができるようになる。これにより、ユーザに対して、生活習慣改善のための行動を実際に起こさせることが効果的にできるという効果を奏する。
【００１２】
本発明の健康管理システムにおいては、サービスサーバをさらに含み、上記サービスサーバは、上記報奨情報を、上記報奨提供元サーバから受信する報奨情報受付手段と、上記報奨情報受付手段が受信した上記報奨情報を上記健康管理端末に送信する第２報奨情報送信手段とを備えており、上記報奨提供元サーバから上記健康管理端末への上記報奨情報の送信、および上記健康管理端末における上記報奨情報の受信は、上記サービスサーバを介しておこなわれることが好ましい。
【００１３】
上記構成によれば、報奨提供元サーバが複数あったとしても、各報奨提供元サーバの報奨情報は一旦サービスサーバに送信され、サービスサーバを介して健康管理端末に送信される。したがって、健康管理端末は、報奨提供元サーバがあった場合に、それぞれの報奨提供元サーバから報奨情報を受信する必要はなく、サービスサーバから送信される報奨情報を受信することにより、各報奨提供元サーバの報奨情報を一括して取得することができる。
【００１４】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記報奨提供元サーバへのアクセス先の情報であるアクセス先情報をさらに含み、上記報奨提供元サーバは、上記健康管理端末からの上記報奨の申し込みを受け付ける報奨受付手段をさらに備えており、上記健康管理端末は、上記報奨提供元サーバへアクセスすることにより上記報奨の申し込みをおこなうことが好ましい。
【００１５】
上記構成によれば、健康管理端末に報奨提供元サーバへのアクセス先が送信されるため、健康管理端末は報奨提供元サーバへアクセスすることにより、報奨の申し込みをおこなうことができる。これにより報奨提供元は、報奨の申し込みを受け付けるための新たなサーバおよび受付手段が不要となる。
【００１６】
さらに本発明の健康管理システムにおいては、上記健康管理端末は、受信した上記報奨情報に含まれる上記素材情報の提示態様を、上記健康情報取得手段により取得された上記健康情報に応じて決定する、提示態様決定手段をさらに備えていることが好ましい。
【００１７】
上記構成によれば、測定された健康情報に応じて、素材情報の提示態様が決定される。そのため、取得した健康情報に応じて、素材情報の提示態様を変化させることができる。これにより、健康情報に応じて、ユーザが飽きない変化のあるコンテンツ表示をおこなうことができ、健康情報を取得するためのユーザのモチベーションを高めることができる。
【００１８】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、上記健康管理端末は、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、上記提示態様決定手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、上記提示態様を変更することが好ましい。
【００１９】
なお、単位判定手段が健康情報を用いる場合、判定手段が健康情報を用いる場合と同様に、測定値をそのまま用いる場合のみならず、測定値に対して特定の処理を施して得られる値を用いる場合も含むことを意図している。
【００２０】
上記構成によれば、健康管理端末は、健康情報が単位条件情報に指定される条件を満たしているかを判定し、満たしていると判定した場合に、提示する素材の提示態様を変更できる。すなわち、健康情報が単位条件をクリアするごとに、ユーザに対して提示する素材情報の提示態様を変更できる。したがって、健康情報の達成度が上がるとコンテンツ表示が変化するため、ユーザは飽きずに健康改善の取り組みをおこなうことができる。
【００２１】
さらに本発明の健康管理システムにおいては、上記報奨情報は、２種類以上の素材情報を含むことが好ましい。
【００２２】
上記構成によれば、ユーザに対して表示される素材情報が複数となり、ユーザに飽きさせずに健康改善の取り組みをおこなわせることができる。また、報奨提供元サーバ側にとっても、素材情報として広告を使用することにより１種類だけではなく複数の広告および宣伝をおこなうことができ、有効な広告をおこなうことができる。
【００２３】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、上記報奨の内容を表示する報奨表示画像をさらに含み、上記報奨情報は、上記報奨表示画像を表示させる単位時間を指定する表示単位時間情報をさらに含み、上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記表示単位時間情報を用いて上記報奨表示画像を表示させる時間を決定し、決定した時間、上記報奨表示画像を上記素材情報提示手段に提示させることが好ましい。
【００２４】
上記構成によれば、健康管理端末は、取得した健康情報に応じて、報奨表示画像を表示する時間を変更させることができる。そのため、ユーザは、報奨表示画像を長時間表示させるために、健康情報の達成度を上げようとがんばるようになる。すなわち健康改善の取り組みをおこなうためのユーザのモチベーションを高めることができる。
【００２５】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、上記報奨表示画像とは異なるカバー画像をさらに含み、上記提示態様決定手段は、上記報奨表示画像を表示させていない間、上記カバー画像を上記素材情報提示手段に提示させることが好ましい。
【００２６】
上記構成によれば、健康管理端末は、報奨表示画像を表示させないときはカバー画像を表示させている。すなわち、報奨表示画像を表示していない状態においてはカバー画像が常に表示されている。そのため、報奨を提供する側は、カバー画像を自社の広告や宣伝の表示にしておけば、有効な広告をおこなうことができる。
【００２７】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、動画を含み、上記報奨情報は、上記動画を再生させる単位時間を指定する再生単位時間情報をさらに含み、上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記再生単位時間情報を用いて上記動画を再生する時間を決定し、決定した時間、上記動画を再生し、上記素材情報提示手段に提示させることが好ましい。
【００２８】
上記構成によれば、健康管理端末は、取得した健康情報に応じて、動画を再生表示する時間を変更させることができる。すなわち、動画の再生時間が、取得した健康情報の数値に応じて変更する。そのため、ユーザは、動画を長時間再生させるために、健康情報の数値が上げようとがんばるようになる。すなわち健康改善の取り組みをおこなうためのユーザのモチベーションを高めることができる。また、ユーザは健康情報の単位条件をクリアするたびに何回も動画を再生することになる。したがって、報奨を提供する側は、動画に自社の広告や宣伝を含めておけば、度重なる動画再生により、効果的な広告や宣伝をすることができる。
【００２９】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、２種類以上の静止画を含み、上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記２種類以上の静止画のうちの何れを提示させるかを選択して、選択した上記静止画を上記素材情報提示手段に提示させることが好ましい。
【００３０】
上記構成によれば、健康情報が単位条件をクリアするたびに、素材情報が切り替わって表示される。これにより、ユーザは、健康情報の達成度が上がるたびに次に何が表示されるのかが楽しみになり、モチベーションを維持しながら健康改善の取り組みをおこなうことができる。また、報奨を提供する側は、素材情報を自社の広告や宣伝の表示にしておけば、複数の広告や宣伝をユーザに提示できるので、効果的な広告や宣伝をおこなうことができる。
【００３１】
さらに本発明の健康管理システムにおいては、上記申込条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることが好ましい。また、上記単位条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることが好ましい。
【００３２】
上記構成によれば、報奨を申し込むための条件または素材情報の提示態様を変更するための条件は、ユーザの生理状態または運動状態を表す数値を指定するばかりでなく、ユーザが測定をおこなった回数も指定することができる。健康情報の数値を利用する場合には、年齢や性別の違いによって基本的な体力が異なるため、大人および男性の方が有利である場合もある。これに対して、測定をおこなった回数とすることで、誰でも差別なくチャレンジすることができる。また、継続して測定する人は、健康への意識が高く真面目であると捉えることができる。そのため、そのようなユーザを報奨提供元サーバへ誘導することができれば、報奨提供元である企業にとっても、意識の高いユーザを得ることができ、より効果の高い宣伝および広告をおこなうことができる。
【００３３】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、上記判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第１重み付加手段を有しており、上記判定手段では、上記第１重み付加手段によって生成された上記重み付き健康情報が上記申込条件を満たしている場合に、上記健康情報が上記申込条件を満たしていると判定することが好ましい。
【００３４】
同様に、上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、上記単位判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第２重み付加手段を有しており、上記単位判定手段では、上記第２重み付加手段によって生成された上記重み付き健康情報が上記単位条件を満たしている場合に、上記健康情報が上記単位条件を満たしていると判定することが好ましい。
【００３５】
上記構成によれば、健康管理端末は、重みを付加した健康情報を用いて申込条件または単位条件の判定をおこなうことができる。健康情報に重み付けをおこなうことで、ユーザは、付加される重みが大きいときには健康改善のための取り組みを積極的におこなうようになり、モチベーションが高まる。また、報奨を提供する側は、例えば、「週末にたくさん歩くユーザ」といったように、自社が希望するユーザのプロファイルをより細かく特定することができる。そのため、報奨を提供する側は、効果的な宣伝および広告をおこなうことができる。
【００３６】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記報奨提供元サーバが報奨の申し込みを受け付ける期限条件を指定する期限条件情報をさらに含み、上記健康管理端末は、上記健康情報が上記期限条件を満たしているか否かを判定する期限判定手段をさらに備えており、上記期限判定手段によって上記健康情報が上記期限条件を満たしている判定されたときに、上記報奨申込手段により上記報奨を申し込むことが好ましい。
【００３７】
上記構成によれば、健康管理端末は、健康情報が報奨を提供する側によって指定される期限の条件を満たす場合に、報奨の申し込みをおこなうことができる。報奨申し込みの期限が設定されていることにより、ユーザは期限までに報奨の申し込みができるように努力するため、健康改善の取り組みをおこなうためのモチベーションも高まる。また、報奨を提供する側は、いつまでもずるずるとチャレンジしている積極性の低いユーザを除外することができる。そのため、自社が希望するユーザのプロファイルをより細かく特定することができ、効果的な宣伝や広告をおこなうことができる。また、新商品の宣伝に利用する際には、新商品のアピール期間があるため、ある程度期間を限定する必要がある。上記構成を備える本発明の健康管理システムによれば、期限を設定することができるので、アピール期間を指定することができる。
【００３８】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記健康管理端末が上記報奨提供元サーバへアクセスするよりも前に上記素材情報提示手段が提示する申込前情報と、該申込前情報を提示させるか否かを指定する申込前表示情報とをさらに含み、上記素材情報提示手段は、上記申込前表示情報に応じて、上記報奨提供元サーバへアクセスするよりも前であり、かつ、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定された後に、上記申込前情報を提示することが好ましい。
【００３９】
上記構成によれば、健康管理端末は、健康情報が申込条件を満たした後、報奨の申し込みをおこなう前に、申込前情報を表示することができる。例えば、申込前情報をユーザへの質問にしておけば、申し込み前表示として、ユーザへ質問をした上で報奨申し込みが可能になるものとすることができる。これにより、報奨申し込み過程で表示した広告および宣伝を理解しているユーザに対してのみ、報奨を提供することができ、また、これら理解度の高いユーザに対して、その後のマーケティング活動への参加募集を行なうことができる。また、例えば、申し込み前に、報奨申し込みにあたっての同意事項を表示させることができ、申し込み時の個人情報を、報奨提供元の新商品紹介やアンケート情報の発信に利用することに対する意向確認をすることができる。これにより、ただ単に健康データを測定して健康意識の高いユーザだけではなく、本当に報奨提供元のその後のマーケティングおよび宣伝活動に利用できるユーザを把握することができる。
【００４０】
したがって、申込前情報を表示することで、報奨申し込み後に報奨提供元にとって利用価値の高いユーザを確認することができる。
【００４１】
さらに本発明の健康管理システムにおいては、上記健康管理端末は、上記報奨提供元サーバから送信される、上記ユーザが入力するための項目を指定する入力項目情報を受信する入力項目情報受信手段と、受信した上記入力項目情報に指定される項目を上記ユーザが入力するための情報入力手段と、上記情報入力手段を介してユーザが入力したユーザ入力情報を上記報奨提供元サーバへ送信するユーザ入力情報送信手段とをさらに備えており、上記報奨提供元サーバは、上記入力項目情報を上記健康管理端末に送信する入力項目情報送信手段と、上記健康管理端末から送信される上記ユーザ入力情報を受信するユーザ入力情報受信手段と、受信した上記ユーザ入力情報を記憶するユーザ入力情報記憶手段とを備えていることが好ましい。
【００４２】
上記構成によれば、報奨提供元サーバは、アンケートやユーザの個人情報を取得するための情報を健康管理端末に送信できる。健康管理端末は、報奨提供元サーバから送信される上記情報を受信し、指定された項目に対する回答を入力することができる。そして、報奨提供元サーバは、健康管理端末から送信されるアンケート結果やユーザの個人情報を取得し、記憶することができる。これにより、報奨提供元サーバは、アンケートや個人情報を収集できる。これらの情報は、マーケティングまたはこれからの広告および宣伝活動に利用できる。そのため、報奨を提供する側は、マーケティング等に有効な情報を得ることができ、報奨を提供するメリットが高まる。また、報奨を申し込むユーザは健康情報を積極的に測定して条件をクリアしたユーザである。そのため、ユーザのプロファイルをある程度特定することができるので、より報奨提供元の希望に沿ったアンケート情報や個人情報を収集することができる。
【００４３】
さらに本発明の健康管理システムにおいては、上記健康管理端末は、受信した上記報奨情報とは異なる報奨情報をさらに受信し、使用している上記報奨情報を該異なる報奨情報に置換する報奨情報変更手段をさらに備えていることが好ましい。
【００４４】
上記構成によれば、健康管理システムは、チャレンジする対象報奨を変更することができる。対象となる報奨を変更可能にすることで、ユーザは自分自身の状況に応じて、より応募しやすい報奨に変更したり、もっとがんばれそうな場合はより条件が高い魅力的な報奨にチャレンジしたりすることができる。そのため、自己の状態に応じたチャレンジができ、無理のない継続した健康維持および健康改善を図ることができる。
【００４５】
また、本発明に係る健康管理システムは、上記の課題を解決するために、健康情報測定装置と、報奨提供元サーバと、サービスサーバと、健康管理端末とを含む健康管理システムであって、上記健康情報測定装置は、ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、上記測定手段により測定された結果を健康情報として上記健康管理端末を介して上記サービスサーバに供給する健康情報供給手段とを備えており、上記報奨提供元サーバは、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記サービスサーバに送信する第１報奨情報送信手段を備えており、上記サービスサーバは、上記報奨情報を上記報奨提供元サーバから受信する報奨情報受付手段と、上記健康情報を上記健康管理端末から取得する健康情報受付手段と、上記報奨情報受付手段が取得した報奨情報に含まれる上記素材情報を、上記健康管理端末に送信する第２報奨情報送信手段と、上記健康情報が上記報奨情報受付手段により受信された上記報奨情報に含まれる上記申込条件を満たしているか否かを判定する判定手段と、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記健康管理端末に対して上記報奨の申し込みをおこなうことの許可を与える申込許可情報を送信する申込許可送信手段とを備えており、上記健康管理端末は、上記素材情報を、上記サービスサーバから受信する報奨情報受信手段と上記申込許可情報を受信したときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴としており、さらに、上記サービスサーバは、上記健康情報受付手段により取得された上記健康情報に応じた上記素材情報提示手段における上記素材情報の提示態様を指定する提示態様情報を生成する提示態様情報生成手段と、上記提示態様情報を上記健康管理端末に送信する提示態様送信手段とをさらに備えており、上記健康管理端末は、上記提示態様情報を受信する提示態様受信手段をさらに備えており、上記素材情報提示手段は、上記提示態様受信手段によって受信された上記提示態様情報に応じた提示態様にしたがって、上記素材情報を提示することが好ましく、また、上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、上記サービスサーバは、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、上記提示態様情報生成手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、異なる上記提示態様を指定する上記提示態様情報を生成することが好ましい。
【００４６】
上記構成によれば、健康管理端末は、健康情報測定装置から供給された健康情報をサービスサーバに送信する。サービスサーバは、報奨提供元サーバから受信した報奨情報と、健康管理端末から受信した健康情報とを用いて、健康情報が申込条件または単位条件を満たしているかを判定し、その判定結果に応じた情報を健康管理端末に送信している。したがって、健康管理端末では、健康管理情報が申込条件および単位条件を満たしているかの判定をおこなうそれぞれの構成が不要となる。そのため、健康管理端末をより簡易な構成にすることができる。
【００４７】
本発明に係る健康管理端末は、上記課題を解決するために、報奨提供元サーバから報奨情報を取得し、健康情報測定装置がユーザの生理状態および運動状態の少なくとも何れかを測定することにより得られる健康情報に応じて報奨の申し込みをおこなう健康管理端末であって、上記報奨情報は、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、該報奨の申し込みをおこなうまで上記ユーザに提示する素材情報とを含み、上記報奨情報を上記報奨提供元サーバから直接または間接に受信する報奨情報受信手段と、上記健康情報測定装置から供給される上記健康情報を取得する健康情報取得手段と、上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記報奨の申し込みをおこなう報奨申込手段と、上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴としている。
【００４８】
上記構成によれば、本発明に係る健康管理システムと同様の効果を奏する。
【００４９】
なお、上記健康管理端末および上記サービスサーバは、コンピュータによって実現してもよい。この場合、コンピュータを上記各手段として動作させることにより上記健康管理端末および上記サービスサーバをコンピュータにおいて実現する健康管理プログラムおよびサービスサーバプログラム、ならびにその健康管理プログラムまたはサービスサーバプログラムを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
【発明の効果】
【００５０】
本発明に係る健康管理システムでは、以上のように、健康情報測定装置によって測定され、供給された健康情報を利用して、この健康情報が条件を満たした場合に、報奨の申し込みをおこなう。そのため、報奨を得ようとするユーザは、健康情報の達成度を上げるために、実際に健康改善の取り組みをおこなうことになり、より効果的に生活習慣を改善することができる。
【発明を実施するための最良の形態】
【００５１】
〔実施の形態１〕
本発明に係る健康管理システムの一実施形態について、図１から図１３に基づいて説明すれば以下の通りである。
【００５２】
（健康管理システムの構成）
はじめに、本実施の形態に係る健康管理システムについて、図２を参照して以下に説明する。
【００５３】
図２は、本発明に係る健康管理システム（以下、ヘルスケアシステムという）１００の一実施形態を示す概略構成図である。図２に示すように、ヘルスケアシステム１００は、健康管理端末１０１、健康機器（健康情報測定装置）１０２、サービスサーバ１０３および報奨提供元サーバ１０４を含んで構成されている。
【００５４】
健康管理端末１０１は、ユーザが所有し、健康管理をおこなうための端末であり、携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）などの携帯端末、またはＴＶおよびパソコンなどの固定設置された端末である。
【００５５】
健康機器１０２は、健康管理端末１０１と有線もしくは無線で通信可能であり、健康機器１０２で測定した健康データ（健康情報）を健康管理端末１０１へ送信する。健康機器１０２は、複数存在してもよい。また、健康機器１０２は健康管理端末１０１から独立に存在するものである場合だけでなく、例えば、健康機器１０２として歩数測定機能を有する装置が、健康管理端末１０１に組み込まれている場合など、健康機器１０２と健康管理端末１０１とが一体となっているものであってもよい。なお、本実施の形態では、健康データとして歩数を例にして説明する。
【００５６】
サービスサーバ１０３は、健康管理端末１０１および報奨提供元サーバ１０４とネットワークで通信可能である。サービスサーバ１０３は、測定、記録された健康データから報奨の申し込みができる条件を含む報奨情報を、報奨提供元サーバ１０４から受信して、健康管理端末１０１に対して送信するものである。
【００５７】
報奨提供元サーバ１０４は、報奨提供元が作成した報奨情報をサービスサーバ１０３へ送信し、また、ユーザから報奨の申し込みを受け付けるものである。報奨提供元サーバ１０４は、複数存在してもよい。
【００５８】
（健康機器）
健康機器１０２の構成について、図６を参照して以下に説明する。
【００５９】
図６は、健康機器１０２の構成を示すブロック図である。図６に示すように、健康機器１０２は、測定部（測定手段）６０１および健康データ供給部（健康情報供給手段）６０２を含んで構成されている。
【００６０】
測定部６０１は、ユーザが実施した運動の種類および強度などの運動状態またはユーザの血圧および体温などの生理状態を測定する部分である。運動状態の測定としては、例えば、歩数の測定が挙げられる。また、生理状態の測定としては、体重、体脂肪、血圧、血糖値、脈拍および基礎体温などの測定が挙げられる。本実施の形態では、健康データとして歩数を用いているため、測定部６０１は歩数を測定するものである。
【００６１】
健康データ供給部６０２は、測定部によって測定された健康データの実測値を、健康管理端末１０１に供給するための部分である。また、実測値とともに測定日時も同時に供給できる。具体的には、Ｂｌｕｅｔｏｏｔｈ（登録商標）および赤外線通信などの無線接続、またはＵＳＢ接続などの有線接続による通信手段を介して、健康管理端末１０１に健康データを供給する部分である。健康機器１０２と健康管理端末１０１とが一体となっている場合には、後述する健康データ取得部２０１とバスを介して接続されていればよい。あるいは健康データ供給部６０２が、後述する健康データ記憶部２０２と直接接続されていてもよい。この場合には、健康データ供給部６０２が後述する健康データ取得部２０１として機能する。
【００６２】
（健康管理端末）
健康管理端末１０１の構成について、図１を参照して以下に説明する。
【００６３】
図１は、健康管理端末１０１の構成を示すブロック図である。図１に示すように、健康管理端末１０１は、端末情報処理部２４０、端末情報記憶部２３０および情報提示部（素材情報提示手段）２０９を含んで構成されている。
【００６４】
情報提示部２０９は、画像や各種情報をユーザに提示するためのインターフェースであり、ＬＣＤ（液晶ディスプレイ）などの表示手段およびスピーカなどである。
【００６５】
端末情報記憶部２３０は、種々のデータを記憶しているものである。本実施の形態では、端末情報記憶部２３０には、後述の健康データ取得部２０１が健康機器１０２から取得した健康データを記憶しておくための健康データ記憶部２０２、および後述の報奨情報取得部２０３がサービスサーバ１０３から受信した報奨情報を記憶しておくための報奨情報記憶部２０４を含んでいる。端末情報記憶部２３０は、例えば、ハードディスク、フラッシュメモリ、ＲＡＭなどの記憶装置を用いることができる。
【００６６】
端末情報処理部２４０は、健康管理端末１０１における種々の情報処理をおこなうためのものであり、健康データ取得部（健康情報取得手段）２０１、報奨情報取得部（報奨情報受信手段）２０３、対象健康データカウント部（判定手段、単位判定手段）２０５、条件チェック部（判定手段、単位判定手段）２０６、提示内容更新部（単位判定手段、提示態様決定手段）２０７、および報奨申し込み部（報奨申込手段）２０８を含んで構成されている。端末情報処理部２４０は、例えば中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの装置を用いることができる。
【００６７】
健康データ取得部２０１は、健康機器１０２から、Ｂｌｕｅｔｏｏｔｈおよび赤外線通信などの無線接続、またはＵＳＢ接続などの有線接続による通信手段を介して、またはバスを介して、健康機器１０２から健康データを取得するためのものである。健康データ取得部２０１は、取得した健康データを健康データ記憶部２０２に蓄積させることができる。
【００６８】
なお、健康管理端末１０１と健康機器１０２が一体となっている場合、例えば、健康機器１０２の測定部６０１が歩数をカウントできるセンサ（加速度センサ等）であり、当該センサを健康管理端末１０１が内蔵している場合には、同様に健康管理端末１０１に内蔵されている健康データ供給部６０２が直接健康データ記憶部２０２に健康データ（歩数データ）を記憶させてもよい。この場合には、健康データ供給部６０２が健康データ取得部２０１として機能する。
【００６９】
報奨情報取得部２０３は、無線通信装置を介して、サービスサーバ１０３から報奨情報を受信して取得する部分である。報奨情報については、詳細は後述するが、ユーザがどの報奨にチャレンジするかを選択できるような情報であることが望ましい。報奨情報取得部２０３では、サービスサーバ１０３から受信した報奨情報リストのうち、ユーザが選択した報奨情報をサービスサーバ１０３に送信する。報奨情報取得部２０３は、取得した報奨情報を報奨情報記憶部２０４に記憶させることができる。
【００７０】
対象健康データカウント部２０５は、報奨を獲得するための条件の対象となる健康データを集計する部分である。対象健康データカウント部２０５は、報奨情報記憶部２０４に記憶している報奨情報を読み出して、報奨を獲得するための条件の対象となる健康データを認識する。次いで、この認識に基づいて健康データ記憶部２０２から健康データを読み出して、条件チェックするために健康データを集計する。例えば、報奨がもらえる条件となる健康データが「歩数データの累積」であれば、健康データ記憶部２０２において記憶している歩数データから、対象期間（報奨へのチャンレンジを開始した日〜現在）の累積歩数を算出する。
【００７１】
条件チェック部２０６は、対象健康データカウント部２０５が集計した健康データが、報奨情報にて指定されている条件を満たすか否かを判定する部分である。条件チェック部２０６は、報奨情報記憶部２０４に記憶している報奨情報にて指定されている２つの条件：（１）報奨獲得の条件である申込条件（申込条件情報）、および（２）条件未達の段階においてユーザへ提示内容を変更する単位の条件である単位条件（単位条件情報）を読み込む。そして、対象健康データカウント部２０５が集計した健康データが、上記（１）および（２）の条件をクリアしているかどうかを判定する。
【００７２】
提示内容更新部２０７は、情報提示部２０９に提示させる内容を決定、変更する部分である。提示内容更新部２０７は、条件チェック部２０６による判定の結果を受けて、情報提示部２０９に提示させる内容を決定する。条件チェック部２０６における判定結果が上記（１）の条件をクリアしていれば、情報提示部２０９に報奨提供元サーバへの申し込み用のボタンを表示させる。上記（１）の条件は満たさないが上記（２）の条件を満たす場合には、健康データに応じた提示内容に変更させる。
【００７３】
報奨申し込み部２０８は、ユーザによる申し込み用ボタンの押下をトリガーとして、報奨の申し込みをおこなう指示を受け付け、報奨提供元サーバ１０４へ報奨の申し込みを送信する部分である。報奨申し込み先の情報については、ＵＲＬ、メールアドレスおよび電話番号などの形式で、あらかじめ健康管理端末１０１に記憶されているか、または報奨提供元サーバ１０４から送信される報奨情報に含まれている。
【００７４】
報奨申し込み部２０８は、申し込み条件をクリアした段階で、申し込み先の情報を読み込み、報奨の申し込みをおこなう。報奨申し込み部２０８による報奨の申し込みは、インターネットによる特定のホームページ接続での申し込み、メール送信による申し込み、電話による申し込みであり得る。
【００７５】
図３は、健康データ記憶部２０２に記憶される健康データのテーブルの一例を示す図である。図３に示すように、この例では、健康データを日付ごとの歩数の累積値として記憶している。本実施の形態では示さないが、時間ごとの歩数および曜日ごとの歩数などを記憶していてもよい。
【００７６】
（サービスサーバ）
サービスサーバ１０３の構成について、図４を参照して以下に説明する。
【００７７】
図４は、サービスサーバ１０３の構成を示すブロック図である。図４に示すように、サービスサーバ１０３は、報奨情報受付部（報奨情報受付手段）４０１、報奨情報蓄積部４０２およびサービスサーバ報奨情報送信部（第２報奨情報送信手段）４０３を含んで構成されている。
【００７８】
報奨情報受付部４０１は、報奨提供元サーバ１０４から送信される報奨情報を受信する部分である。受信の媒体としては、インターネットが可能であり、報奨情報の登録用のウェブページを用意しておいて、報奨提供元サーバ１０４において作成された報奨情報を、このウェブページからサービスサーバ１０３に登録することができる。
【００７９】
報奨情報蓄積部４０２は、報奨情報受付部４０１において報奨提供元サーバ１０４から受信した報奨情報を蓄積、登録しておく部分である。
【００８０】
サービスサーバ報奨情報送信部４０３は、報奨情報蓄積部４０２で記憶しておいた報奨情報およびそのリストを、健康管理端末１０１へ送信する部分である。
【００８１】
なお、本実施の形態においては、健康管理システム１００にサービスサーバ１０３を含め、報奨提供元サーバ１０４から提供される報奨情報を、サービスサーバ１０３を介して健康管理端末１０１に送信しているが、別の実施形態として、ヘルスケアシステム１００にサービスサーバ１０３を含めずに、報奨情報を報奨提供元サーバ１０４から直接健康管理端末１０１に送信することも可能である。報奨提供元サーバ１０４が複数ある場合には、各報奨情報の管理および健康管理端末１０１における操作の観点から、ヘルスケアシステム１００は、サービスサーバ１０３を含んでいることが好ましい。
【００８２】
（報奨提供元サーバ）
報奨提供元サーバ１０４の構成について、図５を参照して以下に説明する。
【００８３】
図５は、報奨提供元サーバ１０４の構成を示すブロック図である。図５に示すように、報奨提供元サーバ１０４は、提供元報奨情報送信部（第１報奨情報送信手段）５０１、および報奨申込受付部（報奨受付手段）５０２を含んで構成されている。
【００８４】
提供元報奨情報送信部５０１は、サービスサーバ１０３に対して報奨情報を送信する部分である。
【００８５】
報奨申込受付部５０２は、測定された健康データが上記報奨情報に含まれている健康データの目標値をクリアしたときに、健康管理端末１０１からの報奨の申し込みを受け付ける部分である。
【００８６】
なお、報奨情報の本体については、報奨提供元サーバ１０４または報奨提供元サーバ１０４と通信可能な別の媒体において、後述の図６に示すような所定のフォーマットで作成され得る。
【００８７】
（報奨情報）
報奨情報について、図７，８および１０を参照して以下に説明する。
【００８８】
図７は、報奨情報の具体例を示す図である。この報奨情報は、報奨提供元サーバ１０４から、サービスサーバ１０３に対して送信されるものである。図７に示すように、報奨情報は、提供者名、単位（単位条件）、条件（申込条件）、カバー画像名、報奨画像名および報奨申込先に関する情報が含んで構成されている。
【００８９】
提供者名は、報奨情報を提供した人または団体の名称で、例えば、報奨を提供する企業名またはサークル名である。この提供社名は、ユーザが報奨を選択する際に表示される。
【００９０】
単位は、表示内容を切り替えるための１単位あたりの健康データである。図７では、単位が「累積歩数１０，０００歩」となっているが、これは、累積歩数が１０，０００歩、２０，０００歩、３０，０００歩、…と１０，０００歩クリアするごとに表示内容を切り替えるという意味である。
【００９１】
条件は、報奨を申し込むことができる健康データの条件である。図７では、「累積歩数１２０，０００歩」となっているが、これは、累積歩数が１２０，０００歩をクリアした段階で、後述の報奨申し込み先の情報に基づいて、報奨提供元サーバ１０４へのアクセスが可能になる条件である。
【００９２】
カバー画像名および報奨画像名は、報奨をクリアするまでに表示内容を切り替える際に利用する画像ファイルの名称である。図７では、それぞれファイル名のみ記憶しており、実体となる画像ファイルは別に保存している。カバー画像および報奨画像は、報奨画像の上にカバー画像が重なった状態になっており、報奨画像がカバー画像により隠された状態になっている。本実施の形態では、カバー画像は、健康データの単位＝１０，０００歩をクリアするごとに、部分的に非表示状態にすることで、背景に隠れていた報奨画像が見えてくるようになる。健康データの単位が１０，０００歩、報奨を申し込むための条件は１２０，０００歩であるので、報奨を申し込むための条件が満たされるまでに、表示の更新は１２回おこなわれることになる。
【００９３】
報奨申し込み先は、条件に達した際に報奨を申し込むアクセス先の情報であり、具体的には、報奨提供元サーバまたは報奨提供元企業のＵＲＬ、メールアドレスおよび電話番号などである。
【００９４】
図８は、サービスサーバ１０３の報奨情報蓄積部４０２において登録、蓄積される報奨情報の例を示す図である。図８に示すように、報奨情報蓄積部４０２では、図７に示すような報奨情報を、報奨提供元サーバ１０４より受信して、順次蓄積していく。また、各報奨情報を識別するために、報奨ＩＤを付与して記憶しておく。
【００９５】
図１０は、健康管理端末１０１における報奨情報の一覧の表示例を示す図である。サービスサーバ報奨情報送信部４０３は、報奨情報蓄積部４０２に記憶している報奨情報に基づいて、健康管理端末１０１が表示可能な形式（ＨＴＭＬ、ＸＭＬおよびＪＰＧ画像など）で、報奨情報の一覧を健康管理端末１０１に送信する。図１０の表示例では、３つの報奨情報が表示されており、報奨の提供社名と、報奨申し込みの条件になる歩数の値が表示されている。健康管理端末１０１はこの情報を表示し、どの報奨にチャレンジするかをユーザに選択させる。
【００９６】
（ヘルスケアシステムの処理）
次に、以上のように構成されたヘルスケアシステム１００にて実行される処理について、図９を参照して以下に説明する。
【００９７】
図９は、ヘルスケアシステム１００の処理の流れを示すフローチャートである。図９を参照しながら、ステップＳ１００〜Ｓ１０９、ステップＳ１１０〜Ｓ１１２、およびステップＳ１１３〜Ｓ１１４について説明すれば以下の通りである。
【００９８】
報奨提供元サーバ１０４の提供元報奨情報送信部５０１が、登録するための報奨情報をサービスサーバ１０３に対して送信する（Ｓ１１３）。ここで報奨情報は、図７に示す内容である。
【００９９】
サービスサーバ１０３の報奨情報受付部４０１は、提供元報奨情報送信部５０１から送信された報奨情報を受信し、受信した報奨情報を報奨情報蓄積部４０２に登録し、記憶する（Ｓ１１０）。サービスサーバ１０３は、後述するステップＳ１００における健康管理端末１０１からの問い合わせを受け付けると、蓄積している報奨情報の一覧を健康管理端末１０１に対して送信する（Ｓ１１１）。
【０１００】
健康管理端末１０１は、チャレンジ可能な報奨情報がないかサービスサーバに問い合わせる（アクセスする）（Ｓ１００）。健康管理端末１０１は、サービスサーバ１０３から送信された報奨情報の一覧を受け付け、情報提示部２０９に、図９に示されるような報奨情報の一覧を表示させる（Ｓ１０１）。健康管理端末１０１は、どの報奨にチャレンジするかの選択をユーザから受け付け、その選択結果をサービスサーバ１０３へ送信する（Ｓ１０２）。
【０１０１】
サービスサーバ１０３が選択結果を受け付けると、サービスサーバ報奨情報送信部４０３は、選択結果に基づく報奨情報の本体（図１０に示す情報）を健康管理端末１０１へ送信する（Ｓ１１２）。
【０１０２】
報奨情報取得部２０３は、ステップＳ１１２において送信された報奨情報の本体を受信し、報奨情報記憶部２０４に記憶しておく（Ｓ１０３）。
【０１０３】
この間、健康機器１０２の測定部６０１は、ユーザの歩数（健康情報）の測定を開始し、計測している。
【０１０４】
次に、健康管理端末１０１の健康データ取得部２０１は、報奨を申し込むために必要な健康データを健康機器１０２から取得する。なお、本実施の形態においては、健康管理端末１０１が歩数をカウントできるセンサ（加速度センサ等）を内蔵しており、健康機器１０２と一体となっているものである。測定部６０１が、健康データの測定をおこない（Ｓ１０４）、対象健康データカウント部２０５が、報奨情報に指定されている対象データをカウントする（Ｓ１０５）。図７に示す報奨情報の場合、単位条件および申込条件の判定に累積歩数が必要なので、対象健康データカウント部２０５は累積歩数をカウントする。その後、条件チェック部２０６は、カウントした累積歩数が報奨情報に指定されている申込条件＝１２０，０００歩をクリアしたかどうかを判断（判定）する（Ｓ１０６）。条件をクリアしていない場合（Ｓ１０６のＮＯ側）、条件チェック部２０６は単位条件をクリアしたかどうかを判断する（Ｓ１０７）。単位条件をクリアしている場合は（Ｓ１０７のＹＥＳ側）、提示内容更新部２０７は提示態様を変更して、表示内容の更新をおこなう（Ｓ１０８）。
【０１０５】
ここで、表示内容の更新について具体的に説明する。本実施の形態では、健康データの測定は、健康管理端末１０１において報奨選択以前より継続しておこなわれており、報奨情報を選択した段階から、歩数データに基づいて、報奨申し込みのためのチャレンジが始まる。したがって、報奨を選択した日が「２００８／７／１７」の場合には、報奨チャレンジの対象となるのは「２００８／７／１７」以降の歩数データとなる。したがって、対象健康データカウント部２０５は、表示内容の更新タイミング（１日１回定期的に、もしくは、ユーザのボタン操作時など）に、報奨チャレンジの対象となる累積の歩数データをカウントする（Ｓ１０５）。例えば、カウントした日が「２００８／７／１９」の場合、健康管理端末１０１の健康データ記憶部２０２において記憶されている図３に示す健康データから「２００８／７／１７〜２００８／７／１９」の歩数データを累積すると、累積歩数データは「１３，０００歩」となる。この場合は、図７に示す報奨情報において、条件となる「１２０，０００歩」をクリアしていないことになる。そのため、条件チェック部２０６は、条件をクリアしていないと判断する（Ｓ１０６のＮＯ側）。この場合、条件チェック部２０６は、単位条件をクリアしているかどうかのチェックをおこなう（Ｓ１０７）。単位条件は、図７に示す通り「１０，０００歩」であり、累積歩数データは「１３，０００歩」である。よって、単位条件はクリアしているので、条件チェック部２０６は、単位条件をクリアしていると判断する（Ｓ１０７のＹＥＳ側）。単位条件を満たしていると条件チェック部２０６が判断すると、提示内容更新部２０７は提示態様を変更して、表示内容を更新する（Ｓ１０８）。
【０１０６】
累積歩数データを増やしていき、条件である「１２０，０００歩」を超えた場合（Ｓ１０６のＹＥＳ側）、健康管理端末１０１は、報奨情報に含まれているアクセス先にアクセスして、報奨を申し込む（Ｓ１０９）。報奨提供元サーバ１０４の報奨申込受付部５０２は、健康管理端末１０１からの報奨申し込みを受信し、申し込みを受け付ける（Ｓ１１４）。
【０１０７】
次に、上記処理をおこなっているときの、健康管理端末１０１の情報提示部２０９に表示される内容について、図１１〜図１３を参照して以下に説明する。
【０１０８】
図１１は、画像の具体例を示す図であり、（ａ）はカバー画像を、（ｂ）は報奨画像（報奨表示画像）の例である。図１１（ａ）に示す例では、カバー画像は、報奨の提供元である「ＡＢＣ ＳＴＥＰ」の企業の宣伝をした画像である。カバー画像は、条件をクリアするまでは健康管理端末１０１に表示される。そのため、広告および宣伝として使用すると、報奨提供元にとって有効である。
【０１０９】
報奨画像は、報奨の内容を示す画像である。条件がクリアされるまでは、カバー画像に隠れて表示される。初期状態では、報奨画像の上に、カバー画像が重なった状態である。すなわち、報奨画像はカバー画像によって隠されている。
【０１１０】
図１２は、申込条件をクリアしていない状態における情報提示部２０９に表示される表示例を示す図である。本実施の形態では、図１２に示すように、カバー画像を複数の領域（ピース）に分割し、領域ごとにカバー画像の表示／非表示を選択し、カバー画像を部分的に非表示にしていくことで、報奨画像を徐々に表示する。分割されたカバー画像のすべてを非表示にしないと（すなわち、申込条件をクリアしないと）、報奨画像の全貌が明らかにならないようにしている。
【０１１１】
提示内容更新部２０７では、累計歩数データ＝１３，０００歩と、図７に示す報奨情報における単位条件＝１０，０００歩および条件＝１２０，０００歩とを用いて、カバー画像をいくつ非表示状態にできるかどうかを計算する。すなわち、カバー画像は、目標値である条件（１２０，０００）を、表示を切り替えるための単位条件（１０，０００）で割った結果である１２領域（１２０，０００÷１０，０００）に分割されることになる。逆に言うと、分割後のカバー画像の１領域を非表示にするには、１０，０００歩の歩数データが必要であり、分割後のカバー画像の全ての領域を非表示にするには、１２０，０００歩の歩数データが必要になるということである。
【０１１２】
現在、累積歩数データが１３，０００歩であるので、分割後のカバー画像の１領域を非表示にできることになる。図１２には、「めくれるピース数 １個」として表示している。カバー画像が１２個の領域に分割されて、中心あたりの１領域が非表示となっており、また、背景に報奨画像が重なっているので、カバー画像が非表示になっている部分から、報奨画像が見えるようになっている。累積歩数データが増えるにしたがって、分割後のカバー画像における非表示にできる領域が増えるので、背景画像の全体像が見えるようになり、報奨の内容が明らかになってくる。報奨の内容が徐々に明らかになれば、ユーザがこの報奨をなんとしても獲得するためにもっと歩いて歩数データを増やす効果もあり、ユーザのモチベーションを高めることができる。
【０１１３】
なお、図１２において、分割後のカバー画像は、提示内容更新部２０７で自動的に非表示にする部分を決めても良いし、健康管理端末１０１に操作部を備えている場合には、どこを非表示にするかをユーザに選択させてもよい。
【０１１４】
同様に、累積歩数データが「２３，０００歩」の場合、条件はクリアしていないが（Ｓ１０６のＮＯ側）、単位条件はクリアしているので（Ｓ１０７のＹＥＳ側）、表示内容を更新することになる（Ｓ１０８）。上述の通り、分割後のカバー画像の１領域を非表示にするには１０，０００歩必要なので、累積歩数データ＝２３，０００歩の場合には、カバー画像の２つの領域を非表示にできる。
【０１１５】
図１３は、条件をクリアした状態の健康管理端末１０１の情報提示部２０９における表示例を示す図である。図１３に示すように、分割されたカバー画像は、すべて非表示となり、報奨申し込み先へアクセスすることができるボタン（報奨申込手段）１３０１が表示されている。図７の報奨情報においては、報奨申し込み先は、報奨提供元サーバ１０４へアクセスするためのＵＲＬであるので、ボタン１３０１を押して報奨を申し込むと、報奨提供元サーバ１０４上のホームページが表示される。このホームページ上で、報奨を提供するための送付先住所を入力させることで、アンケートの入力をさせるなどしてマーケティングに利用することができる。実際に健康改善の取り組みをおこなった結果健康データの条件をクリアしたユーザの健康管理端末１０１からのみ申し込みがなされるので、アンケートについても有益な情報や感想を得ることができる。
【０１１６】
このように、本発明のヘルスケアシステム１００によれば、報奨提供元サーバ１０４からの報奨情報をサービスサーバ１０３を介して、さらに健康管理端末１０１へ送信する。健康管理端末１０１においては、実測した健康データに応じて、報奨情報に指定されている単位条件および申込条件に基づき表示内容が切り替わる。また用いるデータは健康機器１０２によって実際に測定したデータであるため、ユーザは、報奨の全貌が明らかになるまでがんばって健康データを測定しようというモチベーションおよび健康改善のための取り組みを継続しておこなおうというモチベーションが高まる。また、報奨提供元にとっても、健康データという条件を指定して、ユーザの行動および生活状態をある程度絞り込むことができるので、より良い広告および宣伝情報を提供することができる。
【０１１７】
なお、本実施の形態においては、健康データとして歩数データを利用しているが、これに限定されるものではなく、例えば、体重、体脂肪、血圧、血糖値、脈拍および基礎体温などの健康データも利用可能である。
【０１１８】
例えば、体重データを利用する場合、図７に示す報奨情報において、単位条件「単位＝減量値 −０．５ｋｇ」、申込条件「条件＝減量値 −３ｋｇ」というように設定できる。また、図９に示すフローチャートに基づくと、ステップＳ１０４において体重計（健康情報測定装置）からデータを無線もしくは有線で取得することで、体重データを取得する。次に、健康管理端末１０１において対象データのカウントをおこなうが（Ｓ１０５）、健康データ記憶部２０２に記憶されている体重データを参照して、記録開始日の体重（例えば７５．６ｋｇとする）を基準として、以降の体重データとの差をとる。例えば、報奨へのチャレンジ開始後１０日目に測定した体重が「７４．８ｋｇ」の場合、開始日からの差は「−０．８ｋｇ（７４．８ｋｇ−７５．６ｋｇ）」である。この「−０．８ｋｇ」が対象データとなる。次に、対象データに基づいてチェックをおこなう。申込条件である「減量値 −３ｋｇ」はクリアしていないが（Ｓ１０６のＮＯ側）、単位条件である「減量値 −０．５ｋｇ」はクリアしている（Ｓ１０７のＹＥＳ側）。単位条件が更新されているので、図７の報奨情報に指定されているカバー画像および報奨画像により提示内容を更新する（Ｓ１０８）。このように、体重データの場合は、減量／増量の目標値（上記例では「−３ｋｇ」）を設定して、それに対してチャレンジするようにすると有効である。また、上記例では、各条件を、開始日からの減量値として設定したが、具体的な目標体重「６５．０ｋｇ」というようにしてもよい。具体的な体重目標については、例えば、健康上適切だといわれている標準的な体重値（ＢＭＩ（Ｂｏｄｙ Ｍａｓｓ Ｉｎｄｅｘ）が２２となるような体重）を目標値にして、この標準体重を目指してがんばるようにすると、健康支援としても有効である。
【０１１９】
また、体脂肪データを用いる場合も、体重データとほぼ同じようにできる。すなわち、体脂肪データをそのまま利用する場合は、申込条件を「体脂肪率 −３％」とし、単位条件を「体脂肪率 −０．２％」とすることで、開始時点での体脂肪率からの差分を対象データとし、単位条件および申込条件のチェックをおこなう。
【０１２０】
また、血圧データを利用する場合は、至適血圧と言われている「収縮期血圧１３０ｍｍＨｇ以下、かつ、拡張期血圧８０ｍｍＨｇ以下」となった日が何日あるかといった形態で利用できる。例えば、図７において、申込条件が「至適血圧 ３０日間」となり、単位条件が「至適血圧 ２日間」と指定できる。報奨チャレンジ後、健康データ記憶部２０２で記憶している血圧値に基づいて、至適血圧を満たす日が何日あるかをチェックする。例えば、至適血圧を満たす日が開始日からカウントして「５日間」であった場合、単位条件（２日間）はクリアしているが（Ｓ１０７のＹＥＳ側）、申込条件（３０日間）はクリアしていない（Ｓ１０６のＮＯ側）、というようになる。なお、血圧データでは、データの性質上、がんばって数値自体を増やすものでも減らすものでもなく、継続して測定して傾向を把握して適切な医療措置をとることが重要になる。そのため、血圧データを利用する場合には、後述する実施の形態５における利用方法が望ましい。
【０１２１】
血糖値データおよび脈拍データを利用する場合も、血圧データと同様である。また、血糖値データおよび脈拍データでは、数値として何ｍｇ／ｄＬ増えたか／減ったかというよりも、継続して記録しておくことが重要になる。そのため、血糖値データおよび脈拍データを利用する場合にも、後述する実施の形態５における利用方法が望ましい。
【０１２２】
基礎体温データは、データ自体に個人差があり、また体調のチェックが目的であり、がんばって上げたり下げたりするものではない。そのため、基礎体温データを利用する場合には、後述する実施の形態５における利用方法が望ましい。
【０１２３】
〔実施の形態２〕
本発明に係るヘルスケアシステムの第２の実施形態について、図１４および図１５に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１２４】
第１の実施の形態では、カバー画像を複数の領域に分割して、部分的に非表示にすることによって、背景にある報奨画像を表示させるようにしている。本実施の形態では、一定時間、カバー画像に代えて報奨画像を表示させるものである。そして取得した健康データに応じて、報奨画像を表示させる時間を変更している。
【０１２５】
図１４は、報奨情報の具体例を示す図である。図７に示す報奨情報と異なり、「表示単位＝０．２秒」が追加されている。表示単位（表示単位時間情報）については、歩数データの累積値が「単位＝１０，０００歩」を超えるごとに、報奨画像の表示時間が０．２秒ずつ増えていくことを意味する。すなわち、累積歩数が２０，０００歩、３０，０００歩になった場合には、報奨画像の表示時間はそれぞれ「０．４秒」、「０．６秒」となる。累積歩数に基づく表示時間の決定は、提示内容更新部２０７においておこなわれる。
【０１２６】
図１５は、健康管理端末１０１における表示例を示す図である。図１５では、カバー画像が表示されている。図１５に示す状況では、累計歩数は３３，０００歩である。したがって、報奨画像の表示時間は０．６秒（０．２秒×３）となる。ボタン１５０１は、報奨画像の表示を開始するためのボタンである。ボタン１５０１を押すと、０．６秒間だけカバー画像に代えて報奨画像が表示される。０．６秒経過後は、再び、カバー画像が表示され、報奨画像は見えなくなる。
【０１２７】
なお、別の実施の形態として、指定された表示時間、報奨画像を表示し、報奨画像が表示されていない間は、画像をなにも表示させないという形態も可能である。
【０１２８】
以上のように、本実施の形態では、健康データに応じて、報奨画像が表示される時間が変更される。具体的には、累積歩数が増加すれば、報奨画像の表示時間が長くなる。そのため、ユーザは、報奨画像をもっと長時間表示させるために、健康データを増やす（累積歩数を増加させる）ようにがんばるようになる。すなわち、ユーザのモチベーションを高めることができる。また、報奨画像を表示していない状態においてはカバー画像が常に表示されており、ボタンを押された場合のみ報奨画像に切り替わって表示される。そのため、報奨提供元サーバにとっては、カバー画像に自社の広告および宣伝の表示をしておけば、有効な宣伝および広告をおこなうことができる。
【０１２９】
〔実施の形態３〕
本発明に係るヘルスケアシステムの第３の実施形態について、図１６および図１７に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１３０】
第１および第２の実施の形態では、カバー画像および報奨画像ともに、静止画像を用いている。本実施の形態では、動画を用いて、報奨内容を表示させている。
【０１３１】
図１６は、動画を用いる場合における報奨情報の具体例を示す図である。図７および図１４で示した報奨情報とは異なり、「カバー画像名」、「報奨画像名」および「表示単位」の情報がなくなり、「報奨動画名＝Gohoubi-movie.mpg」および「再生単位＝１０秒」が追加されている。報奨動画名は、取得した健康データの数値に応じて再生する動画のファイル名である。また、再生単位（再生単位時間情報）は、単位歩数＝１０，０００歩ずつ歩数データが増えるごとに増加させる、再生時間の増加単位である。図１６に示す報奨情報を用いる場合には、１０，０００歩増えるごとに、１０秒ずつ再生時間が増えることになる。累積歩数に基づく再生時間の決定は、提示内容更新部２０７においておこなわれる。
【０１３２】
図１７は、健康管理端末１０１における表示例を示す図である。図１７に示す例では、累積歩数が１３，０００歩なので、図１６に示す報奨情報を参照して、報奨動画の再生時間は１０秒間となる。図１７（ａ）は報奨動画を再生する前の状態を示し、図１７（ｂ）は報奨動画の再生途中の状態を示す。図１７（ａ）に示すように、再生前の状態では「ビデオを再生する」というボタンが表示されている。このボタンを押すと、図１７（ｂ）に示すように、報奨動画を、再生時間である１０秒間だけ再生して、１０秒終了後には停止する。その後、健康データが増えるにつれて、すなわち、累積歩数が増加するにつれて、再生時間が１０秒単位で増えていくことになる。
【０１３３】
以上のように、本実施の形態では、動画の再生時間が、健康データの数値に応じて変更する。具体的には、累積歩数が増加すれば、動画の再生時間が長くなる。そのため、ユーザは、動画をもっと長時間再生できるようにするために、健康データの数値をもっと増やす（累積歩数を増加させる）ようにがんばるようになる。すなわち、ユーザのモチベーションを高めて、健康改善をおこなうことができるようになる。また、健康データを利用して段階的に動画再生することにより、ユーザは健康データの単位条件をクリアするたびに何回も動画再生することになる。そのため、報奨提供者側においても、効果的な広告および宣伝をおこなうことができる。
【０１３４】
〔実施の形態４〕
本発明に係るヘルスケアシステムの第４の実施形態について、図１８〜図２０に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１３５】
第１の実施の形態では、カバー画像の種類は１種類である。本実施の形態では、複数のカバー画像を用いている。
【０１３６】
図１８は、本実施の形態の報奨情報の具体例を示す図である。図１８に示すように、複数（図１８では１２枚）のカバー画像（cover1.jpg, cover2.jpg, …）が登録されている点が、実施の形態１とは異なる。
【０１３７】
図１９は、カバー画像の具体例を示す図である。図１９では、説明のために３種類のみ例示しているが、報奨情報に登録されているカバー画像の数だけ、すなわち、図１８の報奨情報を用いる場合には、１２枚存在することになる。
【０１３８】
図２０は、健康管理端末１０１における表示例を示す図である。実施の形態１では、１枚のカバー画像を１２の領域（＝１２０，０００歩÷１０，０００歩）に分割して、分割画像１領域ずつ部分的に非表示にしていた。本実施の形態では、図１９に示すカバー画像を、報奨情報に指定されている単位＝１０，０００歩ごとにカバー画像自体を切り替えて表示する。表示の順番は、登録されている画像ごとに順番で良い（図１８に示す報奨情報の場合には、cover1.jpg→cover2.jpg→…の順番）。図２０（ａ）は、カバー画像の一つが表示されている状態を示し、図２０（ｂ）は、申込条件をクリアし報奨画像が表示されている状態を示している。図２０（ａ）に示す状態では、現在の累積の歩数が１３，０００歩なので、カバー画像２００１の部分は、図１９に示す「cover1.jpg」を表示している。歩数データが上がって、２３，０００歩になった場合は、カバー画像２００１には「cover2.jpg」を表示する。また、図２０（ｂ）は、歩数データが累積されて、報奨情報に記載されている申込条件＝１２０，０００歩を超えた状態である。この場合は、カバー画像が表示されずに、報奨画像が表示されている。また、報奨申込先へアクセス可能なボタン２００２が表示されている。
【０１３９】
以上のように、複数のカバー画像が切り替わって表示されるので、ユーザは健康データが増えるたびに、次に何が表示されるのかが楽しみになり、モチベーションを維持しながら、健康改善の取り組みをおこなうことができる。また、複数のカバー画像がユーザに提示されるため、報奨提供先においても、カバー画像に自社の広告および宣伝の表示をしておけば、効果的な宣伝および広告をおこなうことができる。
【０１４０】
〔実施の形態５〕
本発明に係るヘルスケアシステムの第５の実施形態について、図２１〜図２６に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１４１】
前述の実施の形態では、申込条件および単位条件の判定に利用する健康データは、実測した健康データの数値自体（歩数）である。本実施の形態では、利用する健康データは、測定された数値データ自体ではなく、健康データを測定、記録した回数である。
【０１４２】
図２１は、健康管理端末１０１の健康データ記憶部２０２に格納されているテーブルを示している。「日付」は歩数データを記録した日にちを、「歩数データ」はその日の歩数データを表わしている。ここで、「２００８／７／２０」は、歩数データが「０歩」であることを示す。記録としては「０歩」として数値データとしては存在するが、まったく歩いていないという状態となるため、ここでは記録日数としてはカウントしない。また、「２００８／７／２４」は、歩数データの欄が「−」で表示されている。これは、本当に歩数を記録をしていないことを意味し、例えば歩数計自体の電池切れなど、歩数計が作動していなかった場合が該当する。歩数データが記録されている場合は、測定部６０１が測定した歩数データは、健康データ供給部６０２から健康データ取得部２０１を通して、健康管理端末１０１の健康データ記憶部２０２に記憶される。歩数データの欄に数値が記録されている日は、歩数の記録があった日である。なお、本実施の形態では、歩数の１日分の累計値を記録しているが、データの欄に、１日のうち１時間毎の歩数が記録されており、その１時間ごとの歩数データの有無で判断しても良い。
【０１４３】
図２２は、報奨情報の具体例を示す図である。単位条件として「歩数記録 ３日間」、申込条件として「歩数記録 ６０日間」が指定されている。これは、提示内容を更新する単位条件が「歩数を記録した日が合計３日」であり、申込条件をクリアするには「歩数の記録をした日が合計６０日」必要ということである。歩数記録の有無については、対象健康データカウント部２０５において集計する。ここで、実施の形態１に示すように達成度に応じてカバー画像を分割して表示させる場合に、カバー画像「Sky-Cover.jpg」を分割する個数については、申込条件である６０日を、単位条件となる３日で割った日数＝２０（６０日÷３日＝２０個）である。
【０１４４】
次に、歩数を記録した日数のカウント方法について説明する。ここで、図２１に示すテーブルを参照して、報奨へのチャンレンジを始めた日を「２００８／７／１７」、表示する日を「２００８／７／２４」とした場合、「２００８／７／１７〜２００８／７／２４」までで、カウントの対象となり得る歩数データを記録した日は「２００８／７／１７」「２００８／７／１８」「２００８／７／１９」「２００８／７／２２」の４日間となる。
【０１４５】
上記例によると、申込条件である「歩数記録 ６０日間」はクリアしていないが、単位条件である「歩数記録 ３日間」はクリアしていることになる。また、提示内容更新にあたっては、カバー画像（Sky-Cover.jpg）を分割した画像１領域を非表示にする。
【０１４６】
健康管理端末１０１における表示イメージを、図２３から２５を用いて説明する。図２３は、カバー画像（Sky-Cover.jpg）の具体例を示す図である。図２４は、報奨画像（Sky-Gohoubi.jpg）の具体例を示す図である。図２５は、健康管理端末１０１における表示イメージである。前述の通り、２００８／７／２４の段階では、歩数を記録した日数の合計が４日間であるため、分割後のカバー画像は１領域を非表示にできる。図２５では、カバー画像を２０個に分割し、分割後の１領域（左下の領域）を非表示にしている。非表示にしたことで、背景となっている報奨画像（Sky-Cover.jpg）の一部が見えるようになっている。
【０１４７】
また、上記に示した例では、単純に記録の有無をカウントしたが、連続して記録しないと、単位条件および申込条件をクリアできないようにしてもよい。図２６に、報奨情報の別の例を示す。ここでは、単位条件として「歩数記録 連続７日間」を１単位としている。連続して７日間記録しないと、単位条件がクリアできないので、単位条件クリアはより困難になる。また、報奨獲得のための条件は「連続７日間の記録 ５回」としている。これは、連続７日間歩数を記録し、それを５回以上クリアしないと、申込条件がクリアできないことを意味している。連続した７日間の記録については、図２１に示す健康データ記憶部２０２に格納されているテーブルを参照して、対象期間（２００７／７／１７〜７／２４）の間で記録のある日が７日以上連続している期間があるかどうかをチェックする。図２１に示すテーブルの例では、７日間連続して記録がされていないため、対象データは「０」となる。したがって、申込条件をクリアしておらず、また、単位条件もクリアしていないことになる。そのため、カバー画像を１領域分も非表示にできない。
【０１４８】
以上の通り、本発明では、記録をおこなった日数により報奨獲得のチャレンジをすることもまた可能である。健康情報の数値を利用する場合には、年齢や性別の違いによって基本的な体力が異なるため、大人および男性の方が有利である場合もある。これに対して、測定、記録をおこなった回数とすることで、誰でも差別なくチャレンジすることができる。また、継続して測定する人は、健康への意識が高い。そのため、報奨提供元である企業は、意識の高いユーザを得ることができ、より効果の高い宣伝および広告をおこなうことができる。
【０１４９】
前述の実施の形態において説明したように、血圧データ、血糖値データ、脈拍データおよび基礎体温データを利用する場合には、そのデータの性質上、本実施の形態での利用方法が望ましい。これによりユーザは、これらのデータを継続して測定するようになり、健康管理に気を配るようになる。
【０１５０】
また、体重データおよび体脂肪データもまた本実施の形態に利用することができる。体重データを利用する場合には、図２１に示すテーブルにおいて「歩数データ」が「体重データ」になっている。そして、図２２に示す報奨情報において単位条件を「体重記録 ３日間」、申込条件を「体重記録 ６０日間」と置き換えるだけで対応できる。また体脂肪データを用いる場合にも同様に、体脂肪率を測定した日数で同じように対応できる。
【０１５１】
〔実施の形態６〕
本発明に係るヘルスケアシステムの第６の実施形態について、図２７，２８および５７に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１５２】
前述の実施の形態では、申込条件および単位条件の判定に利用する健康データは、実測した健康データの数値そのものである。本実施の形態では、対象データを集計する際に、データに重み付けをおこなって、対象データを算出し、重みを付けたデータを用いて各条件を満たしているかの判定をおこなっている。
【０１５３】
図５７は、本実施の形態に係る健康管理端末１０１の概略構成を示すブロック図である。図５７に示すように、健康管理端末１０１は、重み付きデータ算出部（判定手段、単位判定手段、第１重み付加手段、第２重み付加手段）２２１をさらに含んで構成される。重み付きデータ算出部２２１は、後述するカウント基準（重み付け情報）を用いて、集計する健康データに重みを付けて、重み付きの健康データを算出する部分である。
【０１５４】
図２７は、本実施の形態における報奨情報の具体例を示す図である。図２７に示すように、実施の形態１と異なり、「カウント基準」が指定されている。これは、対象となる健康データを対象健康データカウント部２０５でカウントする際に、単に健康データ記憶部２０２において記録している健康データ（この例では歩数データ）の記録数値の通り集計するのではなく、重み付きデータ算出部２２１において記録データに重み付けをおこなった上で集計するための、重み付け基準である。この例では「月〜金：１．０倍、土・日：３．０倍」となっている。これは、曜日ごとに重み付けを変化させ、月〜金曜日の歩数データについては、そのまま（１．０倍）で集計し、土曜日および日曜日の歩数データについては、３．０倍した上で集計することを意味している。
【０１５５】
この場合、条件チェック部２０６は、この重みが付加された後の重み付き歩数データ（重み付き健康情報）が、申込条件および単位条件を満たしているかをチェックする。そして、条件チェック部２０６は、重みが付加された後のデータがそれぞれの条件を満たしている場合に、健康データがそれぞれの条件を満たしていると判定して、その後の処理を実行させる。
【０１５６】
図２８は、健康データ記憶部２０２に格納されている健康データの具体例を示す図である。ここで、対象期間を２００８／７／１７〜７／１９とし、図２７に示す報奨情報を用いた場合、重み付きデータ算出部２２１において、２００８／７／１７＝９２３４歩（１．０倍）、２００８／７／１８＝６２３４歩（１．０倍）、２００８／７／１９＝２２５９６歩（７５３２歩×３．０）、というような重み付けをおこなう。対象健康データカウント部２０５は、この重み付きデータを用いて、累積歩数＝３８０６４歩を算出する。カバー画像の表示方法が実施の形態１における表示方法である場合には、図２７に示す報奨情報を参照すると、表示切り替えの単位は「累積歩数１０，０００歩」なので、累積歩数＝３８０６４歩のときは、分割後のカバー画像を３つの領域を非表示にできる。したがって、提示内容更新部２０７は、分割したカバー画像の３つの領域を非表示にするように表示を切り替える。
【０１５７】
これにより、ユーザは、付加される重みが高いときには健康改善のための取り組みを積極的におこなうようになり、モチベーションが高まる。また、報奨を提供する側は、例えば、「週末にたくさん歩くユーザ」といったように、自社が希望するユーザのプロファイルをより細かく特定することができる。そのため、報奨を提供する側は、効果的な宣伝および広告をおこなうことができる。
【０１５８】
なお、本実施の形態では、重み付けとして、歩数データが増える場合のみ示したが、重みが１．０未満（０．５倍）や、マイナスの値にすることで、減点をおこなうこともできる。さらに、「０倍」に設定するようにすれば、カウントする対象データを絞り込むことができる。また、データを定倍するだけではなく、「土曜日と日曜日の歩数＋１０００歩」といったように、加算データとして重み付けをおこなってもよい。
【０１５９】
〔実施の形態７〕
本発明に係るヘルスケアシステムの第７の実施形態について、図２９〜図３１および図５８に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１６０】
前述の実施形態と異なり、本実施の形態では、条件として、報奨申し込みの締め切り期限も指定している。
【０１６１】
図５８は、本実施の形態に係る健康管理端末１０１の概略構成を示すブロック図である。図５８に示すように、健康管理端末１０１は、期限判定部（期限判定手段）２２２をさらに備えている。期限判定部２２２は、申込条件の判定に用いられる健康データが、報奨の申し込み期限の条件を満たしているかを判定する部分である。
【０１６２】
図２９は、本実施の形態における報奨情報の具体例を示す図である。図２９に示すように、実施の形態１と異なり、期限を指定する情報（期限条件情報）が含まれており「期限：７日間」が指定されている。これは、報奨を選択して、チャレンジを開始した日からの経過日数が７日以内でないと、報奨へ申し込みができないことを意味する。例えば、チャレンジを開始した日が「２００８／７／１７」である場合、期限である「２００８／７／２３」までに、条件＝累積歩数１２０，０００歩をクリアすることが必要になる。
【０１６３】
図３０は、健康管理端末１０１の表示イメージを示す図である。図３０に示すように、申し込み期限である７日間を過ぎた場合は、期限が切れたことを示すメッセージを表示する。このとき、再度チャレンジする場合は（「再度チャレンジ」ボタン押下）、チャレンジ開始日や累積歩数データをクリアして、再度チャレンジをおこなうことができる。なお、このような情報を健康管理端末１０１に表示させるために、期限を指定する情報とともに、これらの情報も報奨情報に含めて健康管理端末１０１に送信すればよい。
【０１６４】
次に、期限のチェックを含むヘルスケアシステム１００にて実行される処理について、図３１を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１６５】
図３１は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、ステップＳ２０６として、期限判定部２２２が、健康データが期限以内のデータであるかどうかのチェックをおこなう。期限以内と判定されると（Ｓ２０６のＹＥＳ側）、条件チェック部２０６は、申込条件または単位条件をクリアしているかどうかのチェックをおこなう。判定に使用する健康データが期限を越えている場合には（Ｓ２０６のＮＯ側）、期限判定部２２２は、図３０に示すような期限切れメッセージを情報提示部２０９に表示させる（Ｓ２１１）。
【０１６６】
なお、今回は、期限として「開始した日からの経過日数」を指定したが、他にも「２００８／９／３０」といったような具体的な日付でもよい。
【０１６７】
このように、報奨の申し込み期限が設定されていることにより、ユーザは期限までに報奨の申し込みができるように努力するため、健康改善の取り組みをおこなうためのモチベーションも高まる。また、報奨を提供する側は、いつまでもずるずるとチャレンジしている積極性の低いユーザを除外することができる。そのため、自社が希望するユーザのプロファイルをより細かく特定することができる。また、新商品の宣伝に利用する際には、新商品のアピール期間があるため、ある程度期間を限定する必要があるが、期限を設定することにより、アピール期間を指定することができる。
【０１６８】
〔実施の形態８〕
本発明に係るヘルスケアシステムの第８の実施形態について、図３２〜３４ならびに図４２および４３に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１６９】
本実施の形態では、報奨情報に指定されている申込条件をクリアしたあと、報奨申し込みをする前に補足情報を表示している。ここで、補足情報の例としては、報奨にチャレンジしている段階で表示している広告および宣伝が正しく伝わっているかをユーザに質問する（クイズをする）ものである。これにより、報奨を提供する企業は、本当に有効な申し込みのみに絞り込むことができる。また別の例としては、報奨を提供するに当たっての報奨提供元の確認事項を表示するものである。
【０１７０】
図３２は、本実施の形態における報奨情報の具体例を示す図である。実施の形態１と異なり、申込前表示（申込前表示情報）および申込前表示データ（申込前情報）が追加されている。申込前表示は、申し込み前に申込前表示データを表示するか否か、および種類を示すフラグである。この例では、「１」が指定されており、申し込み前の表示をおこなって「クイズ」を表示する。また、「０」の場合は、申し込み前の表示をおこなわず、申込条件クリア後、すぐに報奨申し込み先へとアクセスできるボタンを表示する。また、「２」の場合は、報奨を申し込むにあたって、報奨提供元の確認事項を表示させる。申込前表示データは、申込前表示で指定した表示種類（クイズ、確認事項）に対応する表示データの中身である。ここでは、クイズを出すための問題文、回答文の選択肢、および答えのデータが含まれている。
【０１７１】
図３３は、健康管理端末１０１における表示イメージを示す図である。図３３（ａ）は、申込条件をクリアしたあと、図３２に示す報奨情報で指定された申込前表示データにしたがって、表示イメージ３３０１にクイズを表示している図である。ここで、答えが選択されて「決定」ボタンが押下されると、選択された選択肢が、報奨情報で指定されている答えと一致しているかどうかをチェックする。図３３（ｂ）は、選択の結果、正解した場合の表示を示す図である。正解である場合には、図３３（ｂ）に示す表示イメージ３３０２のように、正解のメッセージ表示をおこなって、報奨申し込み先へアクセスできるボタン３３０３を表示する。不正解の場合の画面は、ここでは図示していないが、不正解であるメッセージを表示して、報奨申し込み先へのアクセスボタン３３０３は表示されない。なお、不正解の場合は、対象となる健康データの情報をクリア（０歩）にしてもよいし、もう一度クイズにチャレンジさせるようにしてもよい。
【０１７２】
次に、報奨情報に申込前表示および申込前表示データが含まれるヘルスケアシステム１００にて実行される処理について、図３４を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１７３】
図３４は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、ステップＳ３０５において条件をクリアした場合は（ＹＥＳ側）、健康管理端末１０１は、報奨情報記憶部２０４に記憶している報奨情報から、申し込み前の表示が指定されているかどうか（申込前表示のフラグが０以外であるかどうか）をチェックする（Ｓ３０９）。申し込み前の表示がある場合は（Ｓ３０９のＹＥＳ側）、報奨情報に指定されている通りの申し込み前の表示をおこなった上で（Ｓ３１０）、報奨申し込みのためのボタンを表示する（Ｓ３１１）。ここで、ステップ３１０において、申し込み前の表示がクイズの場合は、クイズに正解したかどうかのチェックをおこなった上で、正解した場合にのみ、報奨申込（Ｓ３１１）へ進むことができる。
【０１７４】
以上のように、申込条件をクリアした後、申し込み前の表示を利用すれば、カバー画像を用いて報奨提供元の企業の宣伝や広告をおこなった際に、本当にユーザが宣伝や広告の内容を理解しているかどうかをチェックすることができる。これにより、報奨を提供する側は、報奨の申し込みをおこなうユーザの絞込みをおこなえるので、効果的な宣伝および広告をおこなうことができる。
【０１７５】
また上述のように、申込前表示は、報奨を申し込むにあたって報奨提供元の確認事項を表示させるものであることもできる。以下に、申込前表示がユーザへの確認表示の場合の例について説明する。
【０１７６】
図４２は、報奨情報の具体例を示す図である。上述のクイズの場合と異なる点は、「申込前表示」のフラグが「２：確認表示」になっている点と、申込前表示データの内容である。図４３は、申込前表示の表示イメージを示す図である。報奨申込の条件に達した場合、図４２に示す報奨情報に従って、図４３のような申込前表示をおこなう。ここでは、報奨申込時に報奨提供元サーバ１０４で把握可能な健康管理端末１０１に対応するメールアドレスを利用してもいいかどうかを確認するための確認表示をおこなっている。「同意して申し込み」を選択した場合は、健康管理端末１０１に対応するメールアドレスを報奨提供元サーバ１０４から今後発信される新商品情報および特典情報の配信に利用できることに同意したことを示す。「同意しないで申し込み」を選択した場合は、上記利用には同意せずに、報奨に申し込むことを示す。この報奨提供元サーバ１０４への送信データの区別であるが、図４２の報奨情報の申込前表示データにおいて、「<input type=button value=1>同意して申し込み</input>」という記載があるが、この「value=1」「value=2」を、報奨申し込み時に、報奨提供元サーバ１０４に対して送信する。図４２の報奨情報の例では、報奨申込先がメールアドレスになっているので、メールの本文に「value=1」ということを記載して、送信する。「value」データを受け取った報奨提供元サーバ１０４は、「value」データに従って、申し込み時に把握したメールアドレスを、以降に利用するかどうかを判断する。
【０１７７】
以上により、報奨提供元サーバにとっては、報奨申し込み時に収集した健康管理端末１０１の情報を、申込を受け付けた報奨の提供に利用するだけではなく、以降の情報配信等にも有効に活用することができる。
【０１７８】
〔実施の形態９〕
本発明に係るヘルスケアシステムの第９の実施形態について、図３５〜図３８に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１７９】
本実施の形態では、健康管理端末１０１から報奨の申し込みをおこなった後、報奨提供元サーバ１０４から健康管理端末１０１に対して、アンケートや送付先情報などの入力をさせている。
【０１８０】
図３５は、本実施の形態における報奨提供元サーバ１０４の概略構成を示すブロック図である。図３５に示すように、実施の形態１と異なり、報奨提供元サーバ１０４は、入力項目送受信部（入力項目情報送信手段、ユーザ入力情報受信手段）５０３、ユーザ情報蓄積部（ユーザ入力情報記憶手段）５０４およびアンケート情報蓄積部（ユーザ入力情報記憶手段）５０５をさらに備えて構成されている。
【０１８１】
入力項目送受信部５０３は、報奨申込受付部５０２において報奨の申し込みを受け付けた後、健康管理端末１０１に対して、アンケート情報や、個人情報の入力項目（入力項目情報）を送信する部分である。また、入力項目送受信部５０３は、健康管理端末１０１からそれらの入力された情報（ユーザ入力情報）を受信する部分でもある。
【０１８２】
アンケート情報は、報奨提供元の企業による自社のイメージや製品に対する感想などである。個人情報は、報奨の送付先としても利用するが、これ以降に報奨提供元企業が、自社のマーケティング活動に利用することができるように、同意を得た上で利用し得るものである。また、アンケート情報および個人情報を指定するフォーマットとしては、例えば、健康管理端末１０１でウェブページを表示できる場合は、ＨＴＭＬを利用する。なお、これに限らず、ＸＭＬ等で指定してもよい。
【０１８３】
ユーザ情報蓄積部５０４は、健康管理端末１０１より受信したユーザの個人情報を記憶する部分である。
【０１８４】
アンケート情報蓄積部５０５は、健康管理端末１０１より受信したアンケート情報を記憶する部分である。
【０１８５】
図３６は、本実施の形態における健康管理端末１０１の概略構成を示すブロック図である。図３６に示すように、実施の形態１と異なり、情報入力部（情報入力手段）２１１と、ユーザ情報記憶部２１０と、入力項目情報送受信部（入力項目情報受信手段、ユーザ入力情報送信手段）２１２とをさらに備えて構成されている。
【０１８６】
入力項目情報送受信部２１２は、報奨提供元サーバから送信されるアンケート情報や、個人情報の入力項目を受信する部分である。また、入力項目情報送受信部２１２は、受信した入力項目に基づいて、ユーザが入力した情報を報奨提供元サーバへ送信する部分でもある。
【０１８７】
情報入力部２１１は、報奨提供元サーバ１０４から受信した入力項目に基づいて、ユーザが情報を入力する部分である。具体的には、入力項目を液晶などの表示手段に表示し、キーボード、テンキーおよびタッチパネルなどを用いて、入力をおこなう。
【０１８８】
ユーザ情報記憶部２１０は、住所および氏名などのユーザの個人情報を記憶している部分である。このように、あらかじめ健康管理端末１０１において個人情報が記憶されている場合は、これら記憶している個人情報を、入力項目情報送受信部２１２を介して報奨提供元サーバ１０４に対して送信すればよい。
【０１８９】
図３７は、健康管理端末１０１における情報入力画面の一例を示す図である。図３７に示すように、アンケート情報と、報奨の送付先の情報と、今後報奨提供元サーバからのお知らせ情報を受信するかどうかのチェックとが表示されている。これらの入力項目は、ＨＴＭＬの形で、報奨提供元サーバ１０４から指定される項目である。
【０１９０】
次に、ユーザにアンケート情報、個人情報を入力させるヘルスケアシステム１００にて実行される処理について、図３８を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１９１】
図３８は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、報奨申し込みをした後、健康管理端末１０１と報奨提供元サーバ１０４との間で、ユーザ情報のやり取りをおこなっている。健康管理端末１０１において報奨申し込み部２０８が報奨の申し込みをおこなうと（Ｓ４０９）、報奨提供元サーバ１０４の報奨申込受付部５０２は、報奨の申し込みを受け付ける（Ｓ４１５）。すると、入力項目送受信部５０３は、健康管理端末１０１に対して入力させる入力項目を送信する（Ｓ４１７）。健康管理端末１０１の入力項目情報送受信部２１２は、報奨提供元サーバ１０４から送信された入力すべき項目を受信する（Ｓ４１０）。情報入力部２１１を介して指定された入力項目がユーザにより入力されると、入力項目情報送受信部２１２は、報奨提供元サーバ１０４に対して入力された情報を送信する（Ｓ４１１）。報奨提供元サーバ１０４の入力項目送受信部５０３は、健康管理端末１０１から送信された項目を受信し、ユーザ情報蓄積部５０４またはアンケート情報蓄積部５０５に記憶させる（Ｓ４１８）。
【０１９２】
以上のように、本実施の形態に係るヘルスケアシステム１００によれば、報奨提供元サーバ１０４は、アンケート情報や個人情報を収集できる。これらの情報はマーケティングまたはこれからの広告および宣伝活動に利用できるため、報奨を提供する企業にとっては、報奨を提供するメリットが高まる。また、報奨を申し込むユーザは健康情報を積極的に測定して条件をクリアしたユーザである。そのため、報奨を提供する企業は、ユーザのプロファイルをある程度特定することができるので、より希望に沿ったアンケート情報や個人情報を収集することができる。
【０１９３】
〔実施の形態１０〕
本発明に係るヘルスケアシステムの第１０の実施形態について、図３９〜図４１および図５９に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１９４】
本実施の形態では、報奨のチャレンジの途中で、チャレンジする報奨を変更している。
【０１９５】
図５９は、本実施の形態における健康管理端末１０１の概略構成を示すブロック図である。図５９に示すように、実施の形態１と異なり、健康管理端末１０１は、報奨変更部（報奨情報変更手段）２２３をさらに備えて構成されている。報奨変更部２２３は、チャレンジする報奨を変更するために、報奨情報の一覧および新たにチャレンジする報奨の報奨情報をサービスサーバ１０３に要求し、受信した報奨情報に基づき、健康管理端末１０１において用いる報奨情報を変更するための部分である。
【０１９６】
図３９は、健康管理端末１０１における表示イメージを示す図である。実施の形態１と異なり、チャレンジしている報奨を変更する報奨変更ボタン３９０１が表示されている。報奨変更ボタンについては、健康管理端末１０１側で準備するものであってもよいし、報奨情報に「報奨変更可否」に関してフラグで指定がされており、変更可能な報奨の場合のみ、この報奨変更ボタン３９０１を表示するようにしてもよい。
【０１９７】
図４０は、健康管理端末１０１において、報奨変更をおこなう場合の報奨選択画面を示す図である。図１０に示す最初に報奨を選択する場合と異なる点は、今現在チャレンジしている報奨とは異なる報奨情報のみ、表示している点である。これについては、図８に示すように、報奨情報には、サービスサーバ１０３において報奨ＩＤが付与されるので、報奨ＩＤを用いて、現在チャレンジしている報奨と、それ以外の報奨とを識別できる。報奨変更部２２３は、サービスサーバ１０３から送信される図８に示すような報奨情報リストを受信すると、現在チャレンジしている報奨を、図８における「報奨ＩＤ＝ｈ０００１」であると識別し、それ以外の報奨を選択可能な状態で情報提示部２０９に表示させる。また、図４０に示すように、報奨変更部２２３は、今までチャレンジしてきた累積歩数を保持したまま変更することもできる。すなわち、図３９では、累積歩数が３３，０００歩である。この値は、健康管理端末１０１における健康データ記憶部２０２において記憶されている値である。この３３，０００歩を維持したまま、別の報奨にチャレンジできる。
【０１９８】
次に、報奨を変更する場合に、ヘルスケアシステム１００にて実行される処理について、図４１を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１９９】
図４１は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、提示内容更新部２０７が表示内容を更新したあと（Ｓ５０８）、報奨変更部２２３は、報奨変更ボタンが押下されたかどうかをチェックする（Ｓ５０９）。報奨変更ボタンは、図３９に示すような報奨変更ボタン３９０１である。報奨変更ボタンが押下された場合（Ｓ５０９のＹＥＳ側）、報奨変更部２２３は、サービスサーバ１０３に対して、報奨の変更をするために報奨情報の一覧を要求する（Ｓ５１０）。報奨変更部２２３は、サービスサーバ１０３から送信される報奨情報の一覧データを受け付けると、変更可能な報奨情報を情報提示部２０９に表示させる。報奨変更部２２３は、ユーザからの選択を受け付けると、選択された報奨の報奨情報をサービスサーバ１０３に要求する（Ｓ５１１）。要求後に、報奨情報取得部２０３がサービスサーバ１０３から選択された報奨情報を取得すると、報奨変更部２２３は、対象となる報奨を変更する（Ｓ５１２）。報奨変更後、健康管理端末１０１は、引き続き、健康データの測定に戻る（Ｓ５０４）。
【０２００】
サービスサーバ１０３側においては、健康管理端末１０１から報奨変更の要求を受け付けると、報奨情報の一覧を送信する（Ｓ５１８）。健康管理端末１０１において選択された報奨情報の要求を受け付けると、その報奨情報を健康管理端末１０１に送信する（Ｓ５１９）。
【０２０１】
以上のように対象となる報奨を変更可能にすることで、ユーザは自分自身の状況に応じて、より応募しやすい報奨に変更したり、もっとがんばれそうな場合はより条件が高い魅力的な報奨にチャレンジしたりすることができる。そのため、自己の状態に応じたチャレンジができ、無理のない継続した健康維持および健康改善を図ることができる。
【０２０２】
〔実施の形態１１〕
本発明に係るヘルスケアシステムの第１１の実施形態について、図４４〜図４９に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０２０３】
これまでの実施の形態では、報奨情報として報奨獲得の対象となる健康データが１種類の場合について説明したが、本実施の形態では複数の健康データを利用して報奨を獲得する例について説明する。
【０２０４】
図４４は、本実施の形態における健康管理端末１０１の概略構成を示すブロック図である。前述の健康管理端末１０１と異なり、ポイント換算部２１３が追加されている。
【０２０５】
ポイント換算部２１３は、後述する報奨情報に指定されている換算ルールに基づいて、健康機器１０２の測定部６０１により測定した健康データを、ポイントに換算する部分である。この換算したポイントに基づき条件チェック部２０６において単位条件情報および条件情報をクリアしているかどうかの判定をおこなう。
【０２０６】
図４５は、本実施の形態における報奨情報の例を示す図である。図４５に示すように、実施の形態１における報奨情報と異なり、「換算ルール」が追加されている。また、単位条件および申込条件が「ポイント」で指定されている。前述の実施の形態では、１種類の健康データ（歩数ならば１０００歩）で申込条件および単位条件が指定されていた。これに対し、本実施の形態における報奨情報では、健康データを「ポイント」という共通の単位に換算して、複数の健康データを組み合わせて利用できるようにしている。換算ルールでは、各健康データをポイントに換算するルールを指定している。図４５に示す報奨情報の例では、１ポイント獲得するためには、「健康データ＝歩数の場合：累積歩数＝１０，０００歩」「健康データ＝体重の場合：１週間平均での体重減０．２ｋｇ」「健康データ＝血圧の場合：記録回数２回」「健康データ＝食事の場合：目標摂取カロリー値から±１００ｋｃａｌ以内の日が２日」といったように、４種類の健康データを利用してポイントを獲得できる。また、これら換算したポイントの総計を用いて、単位条件５ポイント、申込条件１００ポイントをクリアしたかどうかの判定をおこなう。
【０２０７】
図４６は、健康管理端末１０１の健康データ記憶部２０２に格納されている報奨情報の例を示す図である。図４６に示すように、４種類の健康データの測定データが格納されている。これらの健康データは、健康データ取得部２０１によって健康データ供給部６０２から有線／無線で収集したデータ（体重、血圧）、健康管理端末１０１に内蔵されているセンサ（測定部６０１）によって測定したデータ（歩数）である。また、付加的情報として、健康管理端末１０１のメニュー入力部２１７により入力された食事の摂取カロリーデータを含んでもよい。
【０２０８】
次に、健康データをポイントに換算する場合に、ヘルスケアシステム１００にて実行される処理について、図４７を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０２０９】
実施の形態１と異なる点は、（ｉ）健康データを測定した後（Ｓ６０４）、対象健康データのカウントをおこなう際に（Ｓ６０５、実施の形態１のＳ１０５に対応）ポイント換算に必要な健康データを集計する処理をおこなう点、および（ｉｉ）それら集計された健康データに基づいてポイントをカウントする処理（Ｓ６０６）が追加されている点である。
【０２１０】
健康データを測定（Ｓ６０４）した後、対象健康データカウント部２０５は、報奨情報に含まれる換算ルールを元に、各ポイント換算用の健康データを集計する。次に、これら集計した対象データに基づいて、ポイント換算部２１３が、ポイントをカウントする（Ｓ６０６）。条件チェック部２０６は、ポイント換算部がカウントしたポイントに基づいて、申込条件および単位条件をクリアしているかどうかのチェックをおこなう（Ｓ６０７，Ｓ６０８）。カウントしたポイントが申込条件および単位条件を満たしている場合に、条件チェック部２０６は、健康データが各条件を満たしていると判定する（Ｓ６０７，Ｓ６０８）。
【０２１１】
以下に、ポイント換算に必要な健康データの集計、およびポイントの換算について説明する。
【０２１２】
まず、対象健康データカウント部２０５は、報奨情報に含まれる換算ルールを参照して、図４６に示す健康データ記憶部に格納されている健康データから、必要なデータを抽出する。例えば、報奨チャレンジを開始した日が「２００８／７／１７」で、集計する日が「２００８／７／１９」であった場合には、歩数データについては「２００８／７／１７〜１９」の３日間で「２８，８７４歩」である。体重データについては、集計対象期間の３日間では１週間に満たしていないので、対象データは０である。血圧データについては、「２００８／７／１７〜１９」では２回（７／１７，７／１９）記録されている。食事データについては、図４５に示す換算ルールでは「目標摂取カロリー値から±１００ｋｃａｌ以内を達成した日が２日＝１ポイント」である。ここで、目標摂取カロリーについては、年齢、性別、身体活動レベル（低い、ふつう、高い）から判断される推奨摂取カロリーを目標摂取カロリー値として利用する。この推奨摂取カロリーについては、例えば厚生労働省から発表されている一般的な推奨値を用いるなどする。例えば、ユーザの年齢、性別、身体活動レベルに基づいた目標摂取カロリーが「１７００ｋｃａｌ」とする。一方で、図４６に示す健康データを参照して、「２００８／７／１７〜１９」の間で、７／１７の摂取カロリーは１，７３４ｋｃａｌであるので、ポイント換算の「１７００ｋｃａｌ以内」を満たす。７／１８については２，１００ｋｃａｌであるので、「１７００ｋｃａｌ以内」を満たさない。７／１９は食事の摂取カロリーの記録がない。従って、食事データについては、「１７００ｋｃａｌ以内」を満たす日は１日である。以上のようにして、ポイント換算に必要なデータを抽出し、集計する。
【０２１３】
次に、ポイント換算部２１３は、対象健康データカウント部２０５が集計したこれら対象データに基づいて、ポイントをカウントする。図４５に示す報奨情報に含まれる換算ルールを参照して、歩数は「累積歩数１０，０００歩＝１ポイント」であるので、歩数については２ポイント（２８，８７４歩÷１０，０００）獲得したことになる。体重データについては、対象データは０であるので、０ポイントである。血圧データについては、この換算ルールでは「記録回数２回＝１ポイント」である。対象データは２回（７／１７，７／１９）なので、１ポイント獲得である。食事データについては、「１７００ｋｃａｌ以内」を満たす日が１日なので、ポイント換算ルールである「目標摂取カロリー値から±１００ｋｃａｌ以内を達成した日が２日＝１ポイント」によれば、０ポイントである。従って、「２００８／７／１７〜１９」の間で、獲得したポイント数は、３ポイント（２＋０＋１＋０）となる。
【０２１４】
条件チェック部２０６は、この集計結果である３ポイントに基づいて、申込条件および単位条件をクリアしているかどうかのチェックをおこなう。ここで、図４５を参照して、単位条件＝５ポイント、申込条件１００ポイントであるので、いずれもクリアしていないことになる。したがって、引き続き健康データ測定（Ｓ６０４）に戻る。
【０２１５】
一方、集計する日が「２００８／７／２３」であった場合、図４６に示す健康データを参照して対象データをカウントすると、歩数データの場合は、累計歩数＝６５，１０７歩である。体重データの場合は、「２００８／７／１７〜２３」の７日間の平均は「７５．３ｋｇ」となる。従って、開始日のデータである「２００８／７／１７＝７５．５ｋｇ」の差をとると「０．２ｋｇ」となる。血圧データの場合は、「２００８／７／１７〜２３」の間の記録日数は「５日間」となる。食事データの場合は、「１７００ｋｃａｌ±１００ｋｃａｌ」となる日は「２日間」（７／１７，７／２３）となる。
【０２１６】
次に、これら集計した対象データに基づいて、２００８／７／２３時点でのポイントの換算をおこなうと、歩数データの場合は「６ポイント」、体重データの場合は「１ポイント」、血圧データの場合は「２ポイント」、食事データについては「１ポイント」となり、合計すると獲得ポイントは「１０ポイント」（６＋１＋２＋１）となる。
【０２１７】
条件チェック部２０６は、この１０ポイントに基づいて、申込条件および単位条件をクリアしているかどうかのチェックをおこなう。図４５に示す報奨情報を参照して、申込条件である１００ポイントはクリアしていないが、単位条件である５ポイントはクリアしている。従って、提示内容更新部は、表示内容の更新をおこなう。ここでは、実施の形態１と同様に、報奨画像（Gohoubi.jpg）の上をカバー画像（Cover.jpg）が覆って表示されており、カバー画像を分割して、単位条件をクリアするごとに１ピース非表示になる。また、カバー画像の分割数は、申込条件÷単位条件、すなわち、２０個（１００÷５）に分割する。また、２００８／７／２３時点においては、１０ポイント獲得しているので、カバー画像を２ピース非表示にできる。図４８は、ポイントを１０ポイント獲得した時点での健康管理端末１０１の表示イメージを示す図である。図４８に示すように、１０ポイント獲得時点では、２ピースを非表示にしている。
【０２１８】
図４９は、申込条件である１００ポイントを獲得した場合の健康管理端末１０１の表示イメージを示す図である。この場合は、実施の形態１と同様に、図４５に示す報奨情報に基づいて、報奨申込先へのボタン１３０１が表示される。
【０２１９】
以上のように、報奨情報において対象となる健康データを複数とすることで、例えば運動が苦手で歩数でのポイントは獲得できないけれども、血圧や食事はきちんと測定して目標を守っている人は、ポイントを獲得でき、同じ報奨にチャレンジすることができる。したがって、ユーザが申し込みできる報奨の幅が広がり、ユーザのモチベーションが高まる。
【０２２０】
〔実施の形態１２〕
本発明に係るヘルスケアシステムの第１２の実施形態について、図５０〜図５５に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０２２１】
これまでの実施の形態では、健康管理端末１０１で、報奨情報の単位条件情報および申込条件情報をチェックして、表示内容を変更するという例を示してきた。本実施の形態では、健康データの測定および取得は健康管理端末でおこなうが、これらの測定および取得した健康データをサービスサーバに送信し、サービスサーバ側で単位条件情報および申込条件情報のチェックをおこなって、表示更新や報奨申込をおこなうための表示データ（素材情報、申込許可情報）を健康管理端末へ送信するという例を示す。本実施の形態に示すヘルスケアシステム１００’は、健康管理端末１０１’、健康機器１０２、サービスサーバ１０３’および報奨提供元サーバ１０４を含んで構成されている。
【０２２２】
（健康管理端末およびサービスサーバの構成）
図５０は、本実施の形態における健康管理端末１０１’の概略構成を示すブロック図である。図５０に示すように、実施の形態１と異なる点としては、本実施の形態では単位条件および申込条件のチェックをサービスサーバ側でおこなうため、対象健康データカウント部、条件チェック部および提示内容更新部は、後述するサービスサーバ１０３’にてその機能を担うので必要ない。また、取得した健康データは、健康データ送信部２１８を通してサービスサーバ１０３’に送信され、サービスサーバ１０３’において記憶される。そのため、健康管理端末１０１’に健康データ記憶部は含まれていない。一方で、健康管理端末１０１’は、健康データ送信部２１８、受信部（報奨情報受信手段、提示態様受信手段）２１４、表示部（素材情報提示手段）２１５、および選択部２１６をさらに含んで構成されている。
【０２２３】
健康データ送信部２１８は、取得した健康データをサービスサーバ１０３’に送信する部分である。
【０２２４】
受信部２１４は、サービスサーバ１０３’において単位条件情報および申込条件情報のチェックに基づいて更新された報奨の表示データ、および報奨情報を選択する際の図１０に示すような一覧を選択するための表示データを受信する部分である。
【０２２５】
表示部２１５は、受信部２１４で受信した表示データを表示する部分である。
【０２２６】
選択部２１６は、報奨の申し込みおよび報奨情報の選択をおこなう部分である。
【０２２７】
図５１は、サービスサーバ１０３’の概略構成を示すブロック図である。図５１に示すように、実施の形態１と異なる点としては、報奨選択受付部４０４、健康データ受信部（健康情報受付手段）４０５、ユーザデータ記憶部４０６、対象健康データカウント部（判定手段）４０７、条件チェック部（判定手段）４０８、表示データ作成部（提示態様情報生成手段）４０９、および表示データ送信部（申込許可送信手段、提示態様送信手段）４１０をさらに含んで構成されている点である。
【０２２８】
報奨選択受付部４０４は、健康管理端末１０１’に対して報奨情報の一覧を送信する。また、チャレンジする報奨情報が健康管理端末１０１’において選択された場合、その選択結果のデータを受信し、受け付ける。選択結果は、健康管理端末１０１’に対して報奨情報の一覧を送信する際にサービスサーバ１０３’で付与されたそれぞれの報奨ＩＤのデータとして受信する。
【０２２９】
健康データ受信部４０５は、健康管理端末１０１’が取得し、サービスサーバ１０３’に対して送信された健康データを受信する部分である。
【０２３０】
ユーザデータ記憶部４０６は、報奨選択受付部４０４で受信した選択結果、および健康データ受信部４０５で受信した健康データを記憶しておく部分である。
【０２３１】
対象健康データカウント部４０７は、ユーザデータ記憶部４０６で記憶している健康データに基づいて、健康管理端末１０１’において選択された、報奨を獲得するための条件の対象となる健康データを集計する部分である。この際、報奨情報は、報奨情報蓄積部４０２に記憶されている報奨情報を参照する。
【０２３２】
条件チェック部４０８は、対象健康データカウント部４０７が集計した健康データに基づいて、報奨情報の単位条件情報および申込条件情報をクリアしているか否かを判定する部分である。条件チェック部４０８は、報奨情報蓄積部４０２に記憶している報奨情報にて指定されている２つの条件：（１）報奨獲得の条件、および（２）条件未達の段階においてユーザへ提示内容を変更するための単位の条件を読み込む。そして、対象健康データカウント部４０７が集計した健康データが、上記（１）および（２）の条件をクリアしているかどうかを判定する。
【０２３３】
表示データ作成部４０９は、条件チェック部４０８において判定された判定結果に基づいて、健康データに応じて健康管理端末１０１’における表示を更新するための表示データ、および報奨申し込みをおこなうためのボタンを備えた表示データを作成する部分である。この作成データの具体例としては、健康管理端末１０１’において表示可能なデータであればよく、ＨＴＭＬ、ＸＭＬなどが挙げられる。また、それらに必要な画像データ（ＪＰＥＧファイルなど）も一緒に加工される。
【０２３４】
表示データ送信部４１０は、表示データ作成部４０９で作成された表示データを健康管理端末１０１’に対して送信する部分である。健康管理端末１０１’では、サービスサーバ１０３’から受信した表示データを、健康管理端末１０１’における受信部２１４で受信し、表示部２１５で表示する。
【０２３５】
報奨情報としては、図７に示すような報奨情報を用いることができる。この報奨情報は、報奨提供元サーバ１０４から提供されたデータである。
【０２３６】
図５２は、サービスサーバ１０３’における報奨情報蓄積部４０２において蓄積される報奨情報の例を示す図である。図５２に示すように、報奨情報蓄積部４０２では、報奨提供元サーバ１０４から提供された報奨情報を順次蓄積していく。また各報奨情報を識別するために、報奨ＩＤを付与して記憶しておく。
【０２３７】
図５３は、サービスサーバ１０３’におけるユーザデータ記憶部４０６に記憶されるデータの具体例を示す図である。ここでは、各データを、報奨選択テーブルおよび健康データテーブルにして、２つのテーブルを記憶している。図５３（ａ）は報奨選択テーブルを表し、図５３（ｂ）は健康データテーブルを表している。
【０２３８】
報奨選択テーブルは、健康管理端末１０１’において選択された報奨情報の選択結果、および報奨にチャレンジした履歴情報を記憶しておく。「端末ＩＤ」は、健康管理端末１０１’を一意に特定するためのＩＤである。「選択報奨ＩＤ」は、健康管理端末１０１’において選択された報奨情報の報奨ＩＤを記憶しておく。これは、報奨選択受付部４０４において健康管理端末１０１’より受信した報奨ＩＤに対応する。「報奨開始日」は、報奨が選択された日を記憶しておく。「報奨終了日」は、健康管理端末１０１’において申込条件情報をクリアした日を記憶しておく。「状態」は、報奨へのチャレンジの状態を示す。本実施の形態では、「１」は申込条件情報もクリアして報奨チャレンジが完了した状態、「０」はチャレンジする報奨を途中で変更するなどして報奨チャレンジを途中でとめた状態、そして「２」は報奨へチャレンジ中の状態を示している。従って、「端末ＩＤ＝Ｕ１０００１」の健康管理端末１０１’は、現在、「状態＝２」となっている「報奨ＩＤ＝ｈ０００１」の報奨にチャレンジ中ということが分かる。
【０２３９】
健康データテーブルは、健康管理端末１０１’より受信した健康データを記憶している。「端末ＩＤ」は、健康データを取得した健康管理端末１０１’を一意に特定するためのＩＤである。「日付」、「歩数」、「体重」、「血圧」および「食事（摂取カロリー）」は、健康管理端末１０１’より受信した健康データに基づいて、日付ごとにそれぞれの健康データを記憶しておく。なお、本実施の形態では、４種類の健康データのみ示しているが、これに限定されるものではない。
【０２４０】
（ヘルスケアシステムの処理）
次に、以上のように構成されたヘルスケアシステム１００’にて実行される処理について、図５４を参照して以下に説明する。なお、本実施の形態では、実施の形態１と同様に、健康管理端末１０１’に歩数をカウントできるセンサが内蔵されており、健康機器１０２と健康管理端末１０１’とが一体になっている健康管理端末１０１’を用いる場合について説明するが、これに限定されるものではない。
【０２４１】
図５４は、ヘルスケアシステム１００’の処理の流れを示すフローチャートである。図５４を参照しながら、ステップＳ７００〜Ｓ７０９、ステップＳ７１０〜Ｓ７１９、ステップＳ７２０〜Ｓ７２１について説明すれば以下の通りである。
【０２４２】
まず、報奨提供元サーバ１０４の提供元報奨情報送信部５０１が、報奨情報をサービスサーバ１０３’に対して送信する（Ｓ７２０）。
【０２４３】
サービスサーバ１０３’の報奨情報受付部４０１は、提供元報奨情報送信部５０１から送信された報奨情報を受信し、受信した報奨情報を報奨情報蓄積部４０２に記憶する（Ｓ７１０）。サービスサーバ１０３’は、報奨情報の一覧を健康管理端末１０１’へ送信する（Ｓ７１１）。健康管理端末１０１’では、それら受信した報奨情報の一覧を表示して、ユーザにより選択された報奨情報の報奨ＩＤをサービスサーバ１０３へ送信する（Ｓ７０２）。サービスサーバ１０３’の報奨選択受付部４０４は、健康管理端末１０１’で選択され、送信された報奨情報を受信し、ユーザデータ記憶部４０６に記憶しておく（７１２）。報奨情報が選択されたことにより、健康管理端末１０１’における報奨へのチャレンジが開始されたことになる。次いで、表示データ作成部４０９は、報奨情報に指定されているカバー画像および報奨画像に基づいて、健康管理端末１０１’に対して表示データを送信する。健康管理端末１０１’の受信部２１４は、表示データを受信する。表示部２１５は、受信した表示データに基づいて表示をおこなう（Ｓ７０３）。図５５（ａ）は、健康管理端末１０１’においてチャレンジ開始時に表示される画面を示す図である。当然、対象となる健康データ（累積歩数）は無いので「累積歩数＝０歩」となっている。
【０２４４】
次に、健康管理端末１０１’において、健康データの測定が開始された場合は（Ｓ７０４のＹＥＳ側）、健康データ取得部は、測定された健康データを取得する（Ｓ７０５）。次いで、健康データ送信部２１８は、取得された健康データをサービスサーバ１０３’に対して送信する（Ｓ７０６）。
【０２４５】
サービスサーバ１０３’の健康データ受信部４０５は、健康管理端末１０１’から健康データを受信すると（Ｓ７１４のＹＥＳ側）、受信した健康データをユーザデータ記憶部４０６に健康データテーブルとして記憶しておく。対象健康データカウント部４０７は、ユーザデータ記憶部４０６の報奨選択テーブルの選択報奨ＩＤに基づいて、現在チャレンジ中の報奨情報を報奨情報蓄積部４０２より参照して、対象となる健康データを集計する（Ｓ７１５）。
【０２４６】
図５３に示されている報奨選択テーブルを参照すると、現在チャレンジ中の報奨は、「報奨ＩＤ＝ｈ０００１」の報奨である。また、図５２に示されている報奨情報蓄積部４０２に蓄積されている報奨情報を参照すると、「報奨ＩＤ＝ｈ０００１」の報奨における対象となる健康データの条件は、「単位条件情報＝累積歩数１０，０００歩」および「申込条件情報＝累積歩数１２０，０００歩」である。したがって、対象データとしては累積歩数を集計する。対象データの集計については、ユーザデータ記憶部４０６の健康データテーブルを参照する。報奨選択テーブルでは、報奨開始日が「２００８／７／１７」なので、報奨開始日〜現在までの歩数を、累積歩数として集計する。ここで、現在（集計する日）を「２００８／７／１９」とすると、対象となる健康データ（累積歩数）は「２８，８７４歩」となる。
【０２４７】
次に、対象となる健康データに基づいて、報奨情報の単位条件および申込条件をクリアしているかどうかの判定をおこなう。まず、条件チェック部４０８は、申込条件と集計した対象健康データとを比較して、対象健康データが申込条件をクリアしているか否かの判定をおこなう（Ｓ７１６）。上述のように報奨情報蓄積部４０２を参照すると、「報奨ＩＤ＝ｈ０００１」の単位条件情報は「累積歩数１０，０００歩」であり、申込条件情報は「累積歩数１２０，０００歩」である。この場合、条件チェック部４０８は、申込条件情報「累積歩数１２０，０００歩」と集計した対象健康データ「２８，８７４歩」とを比較して、申込条件情報をクリアしていないと判定する（Ｓ７１６のＮＯ側）。申込条件をクリアしていないと判定すると、条件チェック部４０８は、単位条件と集計した対象健康データとを比較して、単位条件をクリアしているか否かを判定する（Ｓ７１７）。ここで、単位条件は「累積歩数１０，０００歩」であるため、条件チェック部４０８は、単位条件「累積歩数１０，０００歩」と集計した対象健康データ「２８，８７４」とを比較して、単位条件をクリアしていると判定する（Ｓ７１７のＹＥＳ側）。単位条件をクリアしている場合、表示データ作成部４０９は、報奨情報に指定されているカバー画像および報奨画像を利用して、健康管理端末１０１’に表示させる表示用データを作成する（Ｓ７１８）。表示データ送信部４１０は、表示データ作成部４０９が作成した表示データを、健康管理端末１０１’に送信する（Ｓ７１８）。
【０２４８】
ここで表示データを更新する具体例については、実施の形態１に示す健康管理端末１０１の提示内容更新部２０７と同様であり、カバー画像を１２個の領域に分割して、「単位条件＝累積歩数１０，０００歩」をクリアするごとに、分割したカバー画像の領域を１つ１つ非表示にしていく。対象健康データカウント部４０７による集計の結果、現在の累積歩数は「２８，８７４歩」であるため、分割したカバー画像の２つの領域を非表示にできる。サービスサーバ１０３’の表示データ作成部４０９’は、このような表示データを、ＨＴＭＬおよびＸＭＬなど、健康管理端末１０１’で表示可能な形式で作成する。
【０２４９】
健康管理端末１０１’では、受信した表示データを表示部２１５に表示する（Ｓ７０７）。図５５（ｂ）は、健康管理端末１０１’の表示部２１５における表示例を示す図である。累積歩数＝２８，８７４歩に基づいて、１２個に分割されたカバー画像の２つの領域が非表示となっている。そして、カバー画像が非表示となっている部分に、報奨画像が表示されている。
【０２５０】
ユーザが生活習慣改善のための行動をとると、健康管理端末１０１’において取得される累積歩数が増加する。これにより集計した対象健康データが、申込条件情報「累積歩数１２０，０００歩」の条件を満たしている場合には、条件チェック部４０８は、上記のステップＳ７１６において、集計した対象健康データが申込条件情報をクリアしていると判定する（Ｓ７１６のＹＥＳ側）。すると、サービスサーバ１０３’の表示データ作成部４０９は、報奨申し込み用の表示データを作成する（Ｓ７１９）。
【０２５１】
報奨申し込み用の表示データは、健康管理端末１０１’から報奨情報に指定されている報奨申し込み先（ＵＲＬ、メールアドレス、など）にアクセスすることを可能とする表示データである。具体的には、報奨提供元サーバ１０４にアクセスするようにボタンが表示される。
【０２５２】
健康管理端末１０１’の受信部２１４が報奨申し込み用の表示データをサービスサーバ１０３’から受信すると、健康管理端末１０１’は表示データを表示部２１５に表示する（Ｓ７０７）。このとき表示部２１５には、図１３に示すような画像が表示される。表示部２１５には、ユーザが報奨を申し込むことができるように、報奨情報に指定されている報奨申し込み先へアクセスするためのボタン１３０１が表示される。健康管理端末１０１’において、このボタンが操作される（押下げされる）と、（Ｓ７０８のＹＥＳ側）、報奨申し込み部２０８は、報奨提供元サーバ１０４に対して報奨の申し込みをおこなう（Ｓ７０９）。
【０２５３】
報奨提供元サーバ１０４では、報奨申込受付部５０２が、健康管理端末１０１’からの報奨の申し込みを受け付ける（Ｓ７２１）。
【０２５４】
以上のように、本実施の形態では、報奨へのチャレンジをおこなう際に、健康管理端末１０１’において、報奨情報に指定されている単位条件および申込条件をクリアしているかどうかの判定をおこなうのではなく、サービスサーバ１０３’において判定をおこなう。これにより、健康管理端末１０１’側では、対象健康データカウント部、条件チェック部、提示内容更新部などの構成を必要としない。したがって、健康管理端末１０１’は、携帯電話や、さらには小さな表示部およびデータ送受信部を備えた機器（例えば、表示部およびデータ送信機能付きの歩数計）といったように、サーバと比べて処理能力が低いものを利用し得る。健康データのカウントや表示用のデータ生成などといった計算処理を必要とするものはサービスサーバ１０３’で作成し、健康管理端末１０１’では、それら作成された表示データを受信し、表示するだけにしておけばよい。
【０２５５】
ここで、本実施の形態におけるさらなる実施態様について説明する。本実施の形態では、サービスサーバ１０３’において、図５３に示すような報奨選択テーブルにより、各健康管理端末１０１’が報奨のチャレンジを最後まで完了したかどうかのステータスが把握できる。したがって、その報奨情報のステータスに基づいて、ユーザが次にチャレンジする報奨を提案することが可能になる。
【０２５６】
図５６は、健康管理端末１０１における表示例を示す図である。これは、ユーザが報奨にチャレンジする前、ステップＳ７１１においてサービスサーバ１０３’から送信される報奨情報の一覧を、ステップＳ７０１において健康管理端末１０１’の表示部２１５が表示しているときの表示例である。サービスサーバ１０３’では、ユーザデータ記憶部４０６において格納されている報奨選択テーブルを参照して、過去に報奨チャレンジが完了した報奨情報に基づいて、同じ報奨提供元から報奨情報が登録された場合には、新しい報奨情報を健康管理端末１０１’に通知する。
【０２５７】
具体的には、図５３に示す報奨選択テーブルを参照する場合、サービスサーバ１０３’の情報検索部（不図示）４１１が、報奨選択テーブルにおける「端末ＩＤ＝Ｕ１０００１」の健康管理端末１０１’の報奨選択テーブルを参照して、「状態＝１」になっている報奨ＩＤを参照する。図５３に示す報奨選択テーブルでは、報奨ＩＤ＝ｒ１５３４，ｈ３５３４の報奨チャレンジが完了している。また、情報検索部４１１は、報奨情報蓄積部４０２に格納されている報奨情報を参照し、報奨ＩＤ＝ｒ１５３４の報奨が「Ｓｋｙ健康食品」から提供されていることを認識する。そこで情報検索部４１１は、報奨情報蓄積部４０２に記憶されている報奨情報の中から、「Ｓｋｙ健康食品」から提供されている報奨情報を検索する。ここで、「Ｓｋｙ健康食品」からは、報奨ＩＤ＝ｒ１５３５の報奨が登録されている。報奨選択テーブルを参照すると、この報奨は報奨選択テーブルに登録されていないため、端末ＩＤ＝Ｕ１０００１の健康管理端末１０１’は、まだこの報奨にはチャレンジしていないことが分かる。この場合、情報検索部４１１は、新しい報奨情報が登録されたことを、表示データ送信部４１０を介して健康管理端末１０１’に通知する。健康管理端末１０１’では、図５６に示すように、報奨情報の一覧を表示するときに、新しい報奨情報が登録されたことが通知される。
【０２５８】
以上のように、本実施の形態によれば、サービスサーバ１０３’のユーザデータ記憶部４０６には、健康管理端末１０１’による報奨へのチャレンジが完了したのかの履歴情報が記憶されているため、報奨提供元サーバ１０４から報奨が提供された場合に、過去の報奨チャレンジの履歴に基づいて、ユーザが過去に完了した報奨情報に関連する新着の情報を健康管理端末１０１’に通知できる。これにより、健康管理端末１０１’を利用するユーザにとっては、自身が過去に申込条件をクリアして報奨をもらった実績がある報奨情報と関連のある新着情報を通知を受けられる。そのため、ユーザ自身も過去の実績に基づいてチャレンジしやすく、新たな意欲がわき、報奨を獲得するためのモチベーションを高めながら継続して健康管理をおこなうことができる。また、サービスサーバ１０３’では健康管理端末１０１’の報奨情報の履歴情報を記憶しているため、健康管理端末１０１’への情報の通知をおこなうことができる。これにより報奨にチャレンジする健康管理端末１０１’が増えて、サービスとして盛り上げることができる。また、サービスサーバ１０３’では、報奨提供元サーバ１０４に対しても、健康管理端末１０１’における報奨チャレンジの情報を知らせることができる。従って、健康管理端末１０１’が報奨チャレンジをしている状況、興味等を知らせることができるので、報奨提供元サーバ１０４を管理する報奨提供元は、報奨情報の企画・作成にあたっての参考情報を取得することができる。これによりユーザが興味を引く報奨情報を、報奨提供元サーバ１０４を介してサービスサーバ１０３’に提供でき、その結果、魅力的な報奨情報がサービスサーバ１０３’に集まることになる。よって、健康管理端末１０１’を利用するユーザにとっても、モチベーション高く健康管理をおこなうことができる。
【０２５９】
なお、モチベーションを高めるために、健康データをポイントに換算し、たまったポイント数に応じて、金券および商品といった報奨と交換するインセンティブサービスにおいて、以下の（１）〜（３）のような課題が生じ得る。（１）報奨の原資がサービスを利用するユーザが納める利用料である場合、利用するユーザにとっては、利用料を支払ってまでも健康データを測定してがんばって報奨を得るのは、対価となる報奨が魅力的かつ高付加価値である場合のみである。それ以外の場合には、健康データの測定が続かない。また、インセンティブサービスの報奨の種類が限られる場合は（例えば、商品券１種類のみ）、継続しても毎回同じ報奨になるため、モチベーションが高まらない。（２）報奨の原資が、ユーザが所属する健康保健組合が納める利用料である場合、ユーザが利用料を支払う前述の場合の課題と同様に、報奨の内容や種類がモチベーションとなっているため、種類や内容が豊富でない限り、組合員自身が利用料無料であってもモチベーションは高まらない。（３）報奨の原資が、インセンティブサービスへの協賛企業からの利用料である場合、協賛企業にとっては、広告料を支払うからには、効果的に広告情報を提示したいが、広告の提示タイミングや、どのようなユーザに対して広告を提示するかについては、インセンティブサービス側がおこなうため、協賛企業側は広告情報となるデータのみ提供する。また、上述の通り、ユーザおよび健康保健組合が、サービス利用に消極的であれば、効果的な広告手段とはならない。さらに、協賛企業にとっては、有効な広告および宣伝ができない（費用に対する効果が少ない）となれば、インセンティブサービスへの利用料も少なくなるため、結果として報奨の種類が少なかったり、報奨の内容が画一的であったりといった、悪循環へとつながる。
【０２６０】
本発明のヘルスケアシステムによれば、上記の課題を解決し、モチベーション高く健康管理をおこなうことができる。
【０２６１】
（付記事項）
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【０２６２】
例えば、健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４の各ブロックは、ハードウェアロジックによって構成してもよいし、次のようにＣＰＵを用いてソフトウェアによって実現してもよい。
【０２６３】
すなわち、健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（central processing unit）、上記プログラムを格納したＲＯＭ（read only memory）、上記プログラムを展開するＲＡＭ（random access memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０２６４】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。
【０２６５】
また、健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（virtual private network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【０２６６】
なお、本発明のヘルスケアシステムは、以下の点を特徴点としていると換言することも可能である。すなわち、健康管理端末と、サービスサーバと、報奨提供元サーバとからなるヘルスケアシステムであって、健康管理端末は、報奨の申し込みに必要な健康データの条件となる条件情報と、提示用の素材情報と、上記報奨提供元サーバへのアクセス先であるアクセス先情報とを含む報奨情報を、上記サービスサーバより取得する報奨情報受信手段と、健康データを取得する健康データ取得手段と、上記取得した健康データに基づいて、上記素材情報の提示態様を変更する提示更新手段と、上記健康データが、上記条件情報に達した場合に、上記アクセス先情報に基づいて、上記報奨提供元サーバへアクセスする報奨申込手段と、を含み、上記サービスサーバは、上記報奨提供元サーバから上記報奨情報を受信する報奨情報受付手段と、上記健康管理端末に対して、上記報奨情報を送信する報奨情報送信手段と、を含み、上記報奨提供元サーバは、上記サービスサーバに対して、上記報奨情報を登録する報奨情報登録手段と、上記健康管理端末からの報奨申し込みを受け付ける報奨受付手段と、備えることを特徴としているとも換言することができる。
【産業上の利用可能性】
【０２６７】
本発明は、健康改善の取り組みをおこなうユーザをサポートするためのシステムに好適に適用することができる。
【図面の簡単な説明】
【０２６８】
【図１】本発明の一実施形態におけるヘルスケアシステムに用いられる健康管理端末の構成を示すブロック図である。
【図２】本発明の一実施形態におけるヘルスケアシステムの概略構成を示す図である。
【図３】本発明の一実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図４】本発明の一実施形態におけるヘルスケアシステムに用いられるサービスサーバの構成を示すブロック図である。
【図５】本発明の一実施形態におけるヘルスケアシステムに用いられる報奨提供元サーバの構成を示すブロック図である。
【図６】本発明の一実施形態におけるヘルスケアシステムに用いられる健康機器の構成を示すブロック図である。
【図７】本発明の一実施形態における報奨情報の構成を示す図である。
【図８】本発明の一実施形態における報奨情報蓄積部に格納される報奨情報を示す図である。
【図９】本発明の一実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図１０】本発明の一実施形態における健康管理端末の情報提示部での表示例を示す図である。
【図１１】本発明の一実施形態における健康管理端末に表示される画像であり、（ａ）はカバー画像を表し、（ｂ）は報奨画像を表している。
【図１２】本発明の一実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図１３】本発明の一実施形態の条件クリア後における健康管理端末での表示例を示す図である。
【図１４】本発明の別の実施形態における報奨情報の構成を示す図である。
【図１５】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図１６】本発明の別の実施形態における報奨情報の構成を示す図である。
【図１７】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図であり、（ａ）は動画を再生させる前の表示画面を表し、（ｂ）は動画を再生している途中の表示画面を表す。
【図１８】本発明の別の実施形態における報奨情報の構成を示す図である。
【図１９】本発明の別の実施形態における健康管理端末に表示される複数のカバー画像のうちの一部を示す図である。
【図２０】本発明の別の実施形態における健康管理端末の表示画面を表す図であり、（ａ）は条件未達段階における表示画面を表し、（ｂ）は条件達成後における表示画面を表している。
【図２１】本発明の別の実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図２２】本発明の別の実施形態における報奨情報の構成を示す図である。
【図２３】本発明の別の実施形態における健康管理端末に表示されるカバー画像である。
【図２４】本発明の別の実施形態における健康管理端末に表示される報奨画像である。
【図２５】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図２６】本発明の別の実施形態における報奨情報の構成を示す図である。
【図２７】本発明の別の実施形態における報奨情報の構成を示す図である。
【図２８】本発明の別の実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図２９】本発明の別の実施形態における報奨情報の構成を示す図である。
【図３０】本発明の別の実施形態における申込期限が過ぎた場合の健康管理端末での表示画面を表す図である。
【図３１】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図３２】本発明の別の実施形態における報奨情報の構成を示す図である。
【図３３】本発明の別の実施形態における条件クリア後の健康管理端末での表示画面を表す図であり、（ａ）は、クイズを表示している表示例を表しており、（ｂ）は、（ａ）のクイズ正解後における表示例を表している。
【図３４】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図３５】本発明の別の実施形態におけるヘルスケアシステムに用いられるユーザ情報蓄積部、アンケート情報蓄積部を備える報奨提供元サーバの構成を示すブロック図である。
【図３６】本発明の別の実施形態におけるヘルスケアシステムに用いられるユーザ情報記憶部を備える健康管理端末の構成を示すブロック図である。
【図３７】本発明の別の実施形態における個人情報を入力させるための表示画面を表す図である。
【図３８】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図３９】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図４０】本発明の別の実施形態における報奨情報を変更する際の健康管理端末での表示例を示す図である。
【図４１】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図４２】本発明の別の実施形態における報奨情報の構成を示す図である。
【図４３】本発明の別の実施形態における条件クリア後の健康管理端末での表示画面を表す図であり、報奨申し込みに当たっての確認事項を表示している表示例を表している。
【図４４】本発明の別の実施形態におけるヘルスケアシステムに用いられるポイント換算部を備える健康管理端末の構成を示すブロック図である。
【図４５】本発明の別の実施形態における報奨情報の構成を示す図である。
【図４６】本発明の別の実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図４７】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図４８】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図４９】本発明の別の実施形態の条件クリア後における健康管理端末での表示例を示す図である。
【図５０】本発明の別の実施形態におけるヘルスケアシステムに用いられる受信部、選択部を備える健康管理端末の構成を示すブロック図である。
【図５１】本発明の別の実施形態におけるヘルスケアシステムに用いられる、対象健康データカウント部、条件チェック部を備えるサービスサーバの構成を示すブロック図である。
【図５２】本発明の別の実施形態における報奨情報蓄積部に格納される報奨情報を示す図である。
【図５３】本発明の別の実施形態におけるユーザデータ記憶部に格納されるデータを示す図であり、（ａ）は報奨選択テーブルを表し、（ｂ）は健康データテーブルを表す。
【図５４】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図５５】（ａ）および（ｂ）は、本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図５６】本発明の別の実施形態における新しい情報を通知する際の健康管理端末での表示画面を表す図である。
【図５７】本発明の別の実施形態におけるヘルスケアシステムに用いられる重み付きデータ算出部を備える健康管理端末の構成を示すブロック図である。
【図５８】本発明の別の実施形態におけるヘルスケアシステムに用いられる期限判定部を備える健康管理端末の構成を示すブロック図である。
【図５９】本発明の別の実施形態におけるヘルスケアシステムに用いられる報奨変更部を備える健康管理端末の構成を示すブロック図である。
【符号の説明】
【０２６９】
１００，１００’ ヘルスケアシステム（健康管理システム）
１０１，１０１’ 健康管理端末
１０２ 健康機器（健康情報測定装置）
１０３，１０３’ サービスサーバ
１０４ 報奨提供元サーバ
２０１ 健康データ取得部（健康情報取得手段）
２０２ 健康データ記憶部
２０３ 報奨情報取得部（報奨情報受信手段）
２０４ 報奨情報記憶部
２０５ 対象健康データカウント部（判定手段、単位判定手段）
２０６ 条件チェック部（判定手段、単位判定手段）
２０７ 提示内容更新部（単位判定手段、提示態様決定手段）
２０８ 報奨申し込み部（報奨申込手段）
２０９ 情報提示部（素材情報提示手段）
２１０ ユーザ情報記憶部
２１１ 情報入力部（情報入力手段）
２１２ 入力項目情報送受信部（入力項目情報受信手段、ユーザ入力情報送信手段）
２１３ ポイント換算部
２１４ 受信部（報奨情報受信手段、提示態様受信手段）
２１５ 表示部（素材情報提示手段）
２１６ 選択部
２２１ 重み付きデータ算出部（判定手段、単位判定手段、第１重み付加手段、第２重み付加手段）
２２２ 期限判定部（期限判定手段）
２２３ 報奨変更部（報奨情報変更手段）
２３０ 端末情報記憶部
２４０ 端末情報処理部
４０１ 報奨情報受付部（報奨情報受付手段）
４０２ 報奨情報蓄積部
４０３ サービスサーバ報奨情報送信部（第２報奨情報送信手段）
４０５ 健康データ受信部（健康情報受付手段）
４０７ 対象健康データカウント部（判定手段）
４０８ 条件チェック部（判定手段）
４０９ 表示データ作成部（提示態様情報生成手段）
４１０ 表示データ送信部（申込許可送信手段、提示態様送信手段）
５０１ 提供元報奨情報送信部（第１報奨情報送信手段）
５０２ 報奨申込受付部（報奨受付手段）
５０３ 入力項目送受信部（入力項目情報送信手段、ユーザ入力情報受信手段）
５０４ ユーザ情報蓄積部（ユーザ入力情報記憶手段）
５０５ アンケート情報蓄積部（ユーザ入力情報記憶手段）
６０１ 測定部（測定手段）
６０２ 健康データ供給部（健康情報供給部）
１３０１ ボタン（報奨申込手段）
【技術分野】
【０００１】
本発明は、健康改善の取り組みをおこなうユーザの健康情報を利用して、報奨の申し込みをおこなう健康管理システム、健康管理端末、健康管理プログラムおよびサービスサーバプログラムに関するものである。
【背景技術】
【０００２】
近年、問題となっているメタボリックシンドロームおよび生活習慣病などの疾患は、運動および食事などの生活習慣の悪さが原因となっている。これらの疾患にならないためには、その原因である生活習慣を改善することが必要不可欠である。しかしこれらの疾患は痛みなどを伴わないため、ユーザにとっては切迫感がない。そのため、生活習慣を改善するための行動をユーザが継続できないという課題が生じる。
【０００３】
ユーザのモチベーションを高めて、生活習慣を改善するためのユーザの行動を継続させる手段として、従来では、ユーザが利用する健康機器、ならびにパソコンおよび電子辞書など、ユーザが所有する端末を利用して、特定のコンテンツを入手したり、アニメーションおよび音楽情報などのコンテンツの表示内容を変化させたりして、ユーザのモチベーションを高める手段がある。
【０００４】
特許文献１に記載の健康管理方法では、ユーザが特定の製造者の健康商品を購入したり、特定の販売店で健康商品を購入したりすることによって、ユーザにサービスポイントが付与される。ユーザは、この付与されたポイントを利用して、趣味および娯楽、商品の広告ならびにニュースなどのコンテンツを入手することができる。ユーザは、これらのコンテンツを入手することをモチベーションとして、健康商品を継続して購入することになる。また、コンテンツを提供する前に、ユーザに対してアンケートをおこなうため、アンケート情報に基づいて、コンテンツ情報およびポイント情報の魅力を高めることができる。
【特許文献１】特開２００２−１５０７２号公報（平成１４年１月１８日公開）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に記載の健康管理方法では、ユーザが健康商品を購入するだけでポイントが付与されるため、購入後に実際にその健康商品を本人が利用または摂取したかどうかは考慮されていない。例えば、ユーザ以外の人が利用するための健康商品をユーザが購入し、ポイントを貯めるといった方法も可能である。この場合は、ユーザ自身が健康商品を利用しないため、生活習慣改善という目的が達成できないことになる。
【０００６】
一方で、健康商品の製造者や販売者にとっては、ユーザからのアンケート情報は自社製品の改善および改良のためには有益な情報となる。しかしながら、特許文献１に記載の健康管理方法においては、上記したように、健康商品を利用するユーザと、健康商品を購入するユーザとが一致しない可能性がある。そのため、健康意識および該当する健康商品に対するアンケート情報としては信憑性に欠ける。
【０００７】
そこで、本発明は上記の問題点に鑑みてなされたものであり、その目的は、実際に健康改善の取り組みをおこなっているユーザが報奨の申し込みをおこなうことができる健康管理システムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明に係る健康管理システムは、上記の課題を解決するために、健康情報測定装置と、報奨提供元サーバと、健康管理端末とを含む健康管理システムであって、上記健康情報測定装置は、ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、上記測定手段によって得られる測定結果を健康情報として上記健康管理端末に供給する健康情報供給手段とを備えており、上記報奨提供元サーバは、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記健康管理端末に対して直接または間接に送信する第１報奨情報送信手段を備えており、上記健康管理端末は、上記報奨情報を受信する報奨情報受信手段と、上記健康情報を上記健康情報測定装置から取得する健康情報取得手段と、上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴としている。
【０００９】
なお、健康情報は、測定結果である数値または数値の集合のみならず、測定した日時も併せて含んでいてもよい。また、判定手段が健康情報を用いる場合、測定値をそのまま用いる場合のみならず、測定値に対して特定の処理を施して得られる値を用いる場合も含むことを意図している。
【００１０】
上記構成によれば、健康管理端末は、報奨提供元サーバにある報奨情報を、報奨提供元サーバの第１報奨情報送信手段から直接または間接に受信し、取得する。また、健康情報測定装置は、ユーザの生理状態および運動状態の少なくとも何れかを表す健康情報を測定し、測定結果を健康管理端末に供給する。報奨情報には、報奨の申し込みに必要な健康情報の条件を指定する条件情報が含まれている。健康管理端末は、健康情報測定装置によって供給された健康情報がこの条件情報に指定される条件を満たしているかを判定できる。健康管理端末は、この条件を満たしていると判定した場合に、報奨の申し込みをおこなうことができる。健康管理端末は、報奨の申し込みをおこなうまで、素材情報を提示する。
【００１１】
このように、実際に測定したユーザの生理状態および運動状態の少なくとも何れかを、健康情報として用いるため、実際に生活習慣改善のための行動を取っているユーザのみが報奨の申し込みをおこなうことができるようになる。これにより、ユーザに対して、生活習慣改善のための行動を実際に起こさせることが効果的にできるという効果を奏する。
【００１２】
本発明の健康管理システムにおいては、サービスサーバをさらに含み、上記サービスサーバは、上記報奨情報を、上記報奨提供元サーバから受信する報奨情報受付手段と、上記報奨情報受付手段が受信した上記報奨情報を上記健康管理端末に送信する第２報奨情報送信手段とを備えており、上記報奨提供元サーバから上記健康管理端末への上記報奨情報の送信、および上記健康管理端末における上記報奨情報の受信は、上記サービスサーバを介しておこなわれることが好ましい。
【００１３】
上記構成によれば、報奨提供元サーバが複数あったとしても、各報奨提供元サーバの報奨情報は一旦サービスサーバに送信され、サービスサーバを介して健康管理端末に送信される。したがって、健康管理端末は、報奨提供元サーバがあった場合に、それぞれの報奨提供元サーバから報奨情報を受信する必要はなく、サービスサーバから送信される報奨情報を受信することにより、各報奨提供元サーバの報奨情報を一括して取得することができる。
【００１４】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記報奨提供元サーバへのアクセス先の情報であるアクセス先情報をさらに含み、上記報奨提供元サーバは、上記健康管理端末からの上記報奨の申し込みを受け付ける報奨受付手段をさらに備えており、上記健康管理端末は、上記報奨提供元サーバへアクセスすることにより上記報奨の申し込みをおこなうことが好ましい。
【００１５】
上記構成によれば、健康管理端末に報奨提供元サーバへのアクセス先が送信されるため、健康管理端末は報奨提供元サーバへアクセスすることにより、報奨の申し込みをおこなうことができる。これにより報奨提供元は、報奨の申し込みを受け付けるための新たなサーバおよび受付手段が不要となる。
【００１６】
さらに本発明の健康管理システムにおいては、上記健康管理端末は、受信した上記報奨情報に含まれる上記素材情報の提示態様を、上記健康情報取得手段により取得された上記健康情報に応じて決定する、提示態様決定手段をさらに備えていることが好ましい。
【００１７】
上記構成によれば、測定された健康情報に応じて、素材情報の提示態様が決定される。そのため、取得した健康情報に応じて、素材情報の提示態様を変化させることができる。これにより、健康情報に応じて、ユーザが飽きない変化のあるコンテンツ表示をおこなうことができ、健康情報を取得するためのユーザのモチベーションを高めることができる。
【００１８】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、上記健康管理端末は、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、上記提示態様決定手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、上記提示態様を変更することが好ましい。
【００１９】
なお、単位判定手段が健康情報を用いる場合、判定手段が健康情報を用いる場合と同様に、測定値をそのまま用いる場合のみならず、測定値に対して特定の処理を施して得られる値を用いる場合も含むことを意図している。
【００２０】
上記構成によれば、健康管理端末は、健康情報が単位条件情報に指定される条件を満たしているかを判定し、満たしていると判定した場合に、提示する素材の提示態様を変更できる。すなわち、健康情報が単位条件をクリアするごとに、ユーザに対して提示する素材情報の提示態様を変更できる。したがって、健康情報の達成度が上がるとコンテンツ表示が変化するため、ユーザは飽きずに健康改善の取り組みをおこなうことができる。
【００２１】
さらに本発明の健康管理システムにおいては、上記報奨情報は、２種類以上の素材情報を含むことが好ましい。
【００２２】
上記構成によれば、ユーザに対して表示される素材情報が複数となり、ユーザに飽きさせずに健康改善の取り組みをおこなわせることができる。また、報奨提供元サーバ側にとっても、素材情報として広告を使用することにより１種類だけではなく複数の広告および宣伝をおこなうことができ、有効な広告をおこなうことができる。
【００２３】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、上記報奨の内容を表示する報奨表示画像をさらに含み、上記報奨情報は、上記報奨表示画像を表示させる単位時間を指定する表示単位時間情報をさらに含み、上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記表示単位時間情報を用いて上記報奨表示画像を表示させる時間を決定し、決定した時間、上記報奨表示画像を上記素材情報提示手段に提示させることが好ましい。
【００２４】
上記構成によれば、健康管理端末は、取得した健康情報に応じて、報奨表示画像を表示する時間を変更させることができる。そのため、ユーザは、報奨表示画像を長時間表示させるために、健康情報の達成度を上げようとがんばるようになる。すなわち健康改善の取り組みをおこなうためのユーザのモチベーションを高めることができる。
【００２５】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、上記報奨表示画像とは異なるカバー画像をさらに含み、上記提示態様決定手段は、上記報奨表示画像を表示させていない間、上記カバー画像を上記素材情報提示手段に提示させることが好ましい。
【００２６】
上記構成によれば、健康管理端末は、報奨表示画像を表示させないときはカバー画像を表示させている。すなわち、報奨表示画像を表示していない状態においてはカバー画像が常に表示されている。そのため、報奨を提供する側は、カバー画像を自社の広告や宣伝の表示にしておけば、有効な広告をおこなうことができる。
【００２７】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、動画を含み、上記報奨情報は、上記動画を再生させる単位時間を指定する再生単位時間情報をさらに含み、上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記再生単位時間情報を用いて上記動画を再生する時間を決定し、決定した時間、上記動画を再生し、上記素材情報提示手段に提示させることが好ましい。
【００２８】
上記構成によれば、健康管理端末は、取得した健康情報に応じて、動画を再生表示する時間を変更させることができる。すなわち、動画の再生時間が、取得した健康情報の数値に応じて変更する。そのため、ユーザは、動画を長時間再生させるために、健康情報の数値が上げようとがんばるようになる。すなわち健康改善の取り組みをおこなうためのユーザのモチベーションを高めることができる。また、ユーザは健康情報の単位条件をクリアするたびに何回も動画を再生することになる。したがって、報奨を提供する側は、動画に自社の広告や宣伝を含めておけば、度重なる動画再生により、効果的な広告や宣伝をすることができる。
【００２９】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記素材情報として、２種類以上の静止画を含み、上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記２種類以上の静止画のうちの何れを提示させるかを選択して、選択した上記静止画を上記素材情報提示手段に提示させることが好ましい。
【００３０】
上記構成によれば、健康情報が単位条件をクリアするたびに、素材情報が切り替わって表示される。これにより、ユーザは、健康情報の達成度が上がるたびに次に何が表示されるのかが楽しみになり、モチベーションを維持しながら健康改善の取り組みをおこなうことができる。また、報奨を提供する側は、素材情報を自社の広告や宣伝の表示にしておけば、複数の広告や宣伝をユーザに提示できるので、効果的な広告や宣伝をおこなうことができる。
【００３１】
さらに本発明の健康管理システムにおいては、上記申込条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることが好ましい。また、上記単位条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることが好ましい。
【００３２】
上記構成によれば、報奨を申し込むための条件または素材情報の提示態様を変更するための条件は、ユーザの生理状態または運動状態を表す数値を指定するばかりでなく、ユーザが測定をおこなった回数も指定することができる。健康情報の数値を利用する場合には、年齢や性別の違いによって基本的な体力が異なるため、大人および男性の方が有利である場合もある。これに対して、測定をおこなった回数とすることで、誰でも差別なくチャレンジすることができる。また、継続して測定する人は、健康への意識が高く真面目であると捉えることができる。そのため、そのようなユーザを報奨提供元サーバへ誘導することができれば、報奨提供元である企業にとっても、意識の高いユーザを得ることができ、より効果の高い宣伝および広告をおこなうことができる。
【００３３】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、上記判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第１重み付加手段を有しており、上記判定手段では、上記第１重み付加手段によって生成された上記重み付き健康情報が上記申込条件を満たしている場合に、上記健康情報が上記申込条件を満たしていると判定することが好ましい。
【００３４】
同様に、上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、上記単位判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第２重み付加手段を有しており、上記単位判定手段では、上記第２重み付加手段によって生成された上記重み付き健康情報が上記単位条件を満たしている場合に、上記健康情報が上記単位条件を満たしていると判定することが好ましい。
【００３５】
上記構成によれば、健康管理端末は、重みを付加した健康情報を用いて申込条件または単位条件の判定をおこなうことができる。健康情報に重み付けをおこなうことで、ユーザは、付加される重みが大きいときには健康改善のための取り組みを積極的におこなうようになり、モチベーションが高まる。また、報奨を提供する側は、例えば、「週末にたくさん歩くユーザ」といったように、自社が希望するユーザのプロファイルをより細かく特定することができる。そのため、報奨を提供する側は、効果的な宣伝および広告をおこなうことができる。
【００３６】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記報奨提供元サーバが報奨の申し込みを受け付ける期限条件を指定する期限条件情報をさらに含み、上記健康管理端末は、上記健康情報が上記期限条件を満たしているか否かを判定する期限判定手段をさらに備えており、上記期限判定手段によって上記健康情報が上記期限条件を満たしている判定されたときに、上記報奨申込手段により上記報奨を申し込むことが好ましい。
【００３７】
上記構成によれば、健康管理端末は、健康情報が報奨を提供する側によって指定される期限の条件を満たす場合に、報奨の申し込みをおこなうことができる。報奨申し込みの期限が設定されていることにより、ユーザは期限までに報奨の申し込みができるように努力するため、健康改善の取り組みをおこなうためのモチベーションも高まる。また、報奨を提供する側は、いつまでもずるずるとチャレンジしている積極性の低いユーザを除外することができる。そのため、自社が希望するユーザのプロファイルをより細かく特定することができ、効果的な宣伝や広告をおこなうことができる。また、新商品の宣伝に利用する際には、新商品のアピール期間があるため、ある程度期間を限定する必要がある。上記構成を備える本発明の健康管理システムによれば、期限を設定することができるので、アピール期間を指定することができる。
【００３８】
さらに本発明の健康管理システムにおいては、上記報奨情報は、上記健康管理端末が上記報奨提供元サーバへアクセスするよりも前に上記素材情報提示手段が提示する申込前情報と、該申込前情報を提示させるか否かを指定する申込前表示情報とをさらに含み、上記素材情報提示手段は、上記申込前表示情報に応じて、上記報奨提供元サーバへアクセスするよりも前であり、かつ、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定された後に、上記申込前情報を提示することが好ましい。
【００３９】
上記構成によれば、健康管理端末は、健康情報が申込条件を満たした後、報奨の申し込みをおこなう前に、申込前情報を表示することができる。例えば、申込前情報をユーザへの質問にしておけば、申し込み前表示として、ユーザへ質問をした上で報奨申し込みが可能になるものとすることができる。これにより、報奨申し込み過程で表示した広告および宣伝を理解しているユーザに対してのみ、報奨を提供することができ、また、これら理解度の高いユーザに対して、その後のマーケティング活動への参加募集を行なうことができる。また、例えば、申し込み前に、報奨申し込みにあたっての同意事項を表示させることができ、申し込み時の個人情報を、報奨提供元の新商品紹介やアンケート情報の発信に利用することに対する意向確認をすることができる。これにより、ただ単に健康データを測定して健康意識の高いユーザだけではなく、本当に報奨提供元のその後のマーケティングおよび宣伝活動に利用できるユーザを把握することができる。
【００４０】
したがって、申込前情報を表示することで、報奨申し込み後に報奨提供元にとって利用価値の高いユーザを確認することができる。
【００４１】
さらに本発明の健康管理システムにおいては、上記健康管理端末は、上記報奨提供元サーバから送信される、上記ユーザが入力するための項目を指定する入力項目情報を受信する入力項目情報受信手段と、受信した上記入力項目情報に指定される項目を上記ユーザが入力するための情報入力手段と、上記情報入力手段を介してユーザが入力したユーザ入力情報を上記報奨提供元サーバへ送信するユーザ入力情報送信手段とをさらに備えており、上記報奨提供元サーバは、上記入力項目情報を上記健康管理端末に送信する入力項目情報送信手段と、上記健康管理端末から送信される上記ユーザ入力情報を受信するユーザ入力情報受信手段と、受信した上記ユーザ入力情報を記憶するユーザ入力情報記憶手段とを備えていることが好ましい。
【００４２】
上記構成によれば、報奨提供元サーバは、アンケートやユーザの個人情報を取得するための情報を健康管理端末に送信できる。健康管理端末は、報奨提供元サーバから送信される上記情報を受信し、指定された項目に対する回答を入力することができる。そして、報奨提供元サーバは、健康管理端末から送信されるアンケート結果やユーザの個人情報を取得し、記憶することができる。これにより、報奨提供元サーバは、アンケートや個人情報を収集できる。これらの情報は、マーケティングまたはこれからの広告および宣伝活動に利用できる。そのため、報奨を提供する側は、マーケティング等に有効な情報を得ることができ、報奨を提供するメリットが高まる。また、報奨を申し込むユーザは健康情報を積極的に測定して条件をクリアしたユーザである。そのため、ユーザのプロファイルをある程度特定することができるので、より報奨提供元の希望に沿ったアンケート情報や個人情報を収集することができる。
【００４３】
さらに本発明の健康管理システムにおいては、上記健康管理端末は、受信した上記報奨情報とは異なる報奨情報をさらに受信し、使用している上記報奨情報を該異なる報奨情報に置換する報奨情報変更手段をさらに備えていることが好ましい。
【００４４】
上記構成によれば、健康管理システムは、チャレンジする対象報奨を変更することができる。対象となる報奨を変更可能にすることで、ユーザは自分自身の状況に応じて、より応募しやすい報奨に変更したり、もっとがんばれそうな場合はより条件が高い魅力的な報奨にチャレンジしたりすることができる。そのため、自己の状態に応じたチャレンジができ、無理のない継続した健康維持および健康改善を図ることができる。
【００４５】
また、本発明に係る健康管理システムは、上記の課題を解決するために、健康情報測定装置と、報奨提供元サーバと、サービスサーバと、健康管理端末とを含む健康管理システムであって、上記健康情報測定装置は、ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、上記測定手段により測定された結果を健康情報として上記健康管理端末を介して上記サービスサーバに供給する健康情報供給手段とを備えており、上記報奨提供元サーバは、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記サービスサーバに送信する第１報奨情報送信手段を備えており、上記サービスサーバは、上記報奨情報を上記報奨提供元サーバから受信する報奨情報受付手段と、上記健康情報を上記健康管理端末から取得する健康情報受付手段と、上記報奨情報受付手段が取得した報奨情報に含まれる上記素材情報を、上記健康管理端末に送信する第２報奨情報送信手段と、上記健康情報が上記報奨情報受付手段により受信された上記報奨情報に含まれる上記申込条件を満たしているか否かを判定する判定手段と、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記健康管理端末に対して上記報奨の申し込みをおこなうことの許可を与える申込許可情報を送信する申込許可送信手段とを備えており、上記健康管理端末は、上記素材情報を、上記サービスサーバから受信する報奨情報受信手段と上記申込許可情報を受信したときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴としており、さらに、上記サービスサーバは、上記健康情報受付手段により取得された上記健康情報に応じた上記素材情報提示手段における上記素材情報の提示態様を指定する提示態様情報を生成する提示態様情報生成手段と、上記提示態様情報を上記健康管理端末に送信する提示態様送信手段とをさらに備えており、上記健康管理端末は、上記提示態様情報を受信する提示態様受信手段をさらに備えており、上記素材情報提示手段は、上記提示態様受信手段によって受信された上記提示態様情報に応じた提示態様にしたがって、上記素材情報を提示することが好ましく、また、上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、上記サービスサーバは、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、上記提示態様情報生成手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、異なる上記提示態様を指定する上記提示態様情報を生成することが好ましい。
【００４６】
上記構成によれば、健康管理端末は、健康情報測定装置から供給された健康情報をサービスサーバに送信する。サービスサーバは、報奨提供元サーバから受信した報奨情報と、健康管理端末から受信した健康情報とを用いて、健康情報が申込条件または単位条件を満たしているかを判定し、その判定結果に応じた情報を健康管理端末に送信している。したがって、健康管理端末では、健康管理情報が申込条件および単位条件を満たしているかの判定をおこなうそれぞれの構成が不要となる。そのため、健康管理端末をより簡易な構成にすることができる。
【００４７】
本発明に係る健康管理端末は、上記課題を解決するために、報奨提供元サーバから報奨情報を取得し、健康情報測定装置がユーザの生理状態および運動状態の少なくとも何れかを測定することにより得られる健康情報に応じて報奨の申し込みをおこなう健康管理端末であって、上記報奨情報は、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、該報奨の申し込みをおこなうまで上記ユーザに提示する素材情報とを含み、上記報奨情報を上記報奨提供元サーバから直接または間接に受信する報奨情報受信手段と、上記健康情報測定装置から供給される上記健康情報を取得する健康情報取得手段と、上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記報奨の申し込みをおこなう報奨申込手段と、上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴としている。
【００４８】
上記構成によれば、本発明に係る健康管理システムと同様の効果を奏する。
【００４９】
なお、上記健康管理端末および上記サービスサーバは、コンピュータによって実現してもよい。この場合、コンピュータを上記各手段として動作させることにより上記健康管理端末および上記サービスサーバをコンピュータにおいて実現する健康管理プログラムおよびサービスサーバプログラム、ならびにその健康管理プログラムまたはサービスサーバプログラムを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
【発明の効果】
【００５０】
本発明に係る健康管理システムでは、以上のように、健康情報測定装置によって測定され、供給された健康情報を利用して、この健康情報が条件を満たした場合に、報奨の申し込みをおこなう。そのため、報奨を得ようとするユーザは、健康情報の達成度を上げるために、実際に健康改善の取り組みをおこなうことになり、より効果的に生活習慣を改善することができる。
【発明を実施するための最良の形態】
【００５１】
〔実施の形態１〕
本発明に係る健康管理システムの一実施形態について、図１から図１３に基づいて説明すれば以下の通りである。
【００５２】
（健康管理システムの構成）
はじめに、本実施の形態に係る健康管理システムについて、図２を参照して以下に説明する。
【００５３】
図２は、本発明に係る健康管理システム（以下、ヘルスケアシステムという）１００の一実施形態を示す概略構成図である。図２に示すように、ヘルスケアシステム１００は、健康管理端末１０１、健康機器（健康情報測定装置）１０２、サービスサーバ１０３および報奨提供元サーバ１０４を含んで構成されている。
【００５４】
健康管理端末１０１は、ユーザが所有し、健康管理をおこなうための端末であり、携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）などの携帯端末、またはＴＶおよびパソコンなどの固定設置された端末である。
【００５５】
健康機器１０２は、健康管理端末１０１と有線もしくは無線で通信可能であり、健康機器１０２で測定した健康データ（健康情報）を健康管理端末１０１へ送信する。健康機器１０２は、複数存在してもよい。また、健康機器１０２は健康管理端末１０１から独立に存在するものである場合だけでなく、例えば、健康機器１０２として歩数測定機能を有する装置が、健康管理端末１０１に組み込まれている場合など、健康機器１０２と健康管理端末１０１とが一体となっているものであってもよい。なお、本実施の形態では、健康データとして歩数を例にして説明する。
【００５６】
サービスサーバ１０３は、健康管理端末１０１および報奨提供元サーバ１０４とネットワークで通信可能である。サービスサーバ１０３は、測定、記録された健康データから報奨の申し込みができる条件を含む報奨情報を、報奨提供元サーバ１０４から受信して、健康管理端末１０１に対して送信するものである。
【００５７】
報奨提供元サーバ１０４は、報奨提供元が作成した報奨情報をサービスサーバ１０３へ送信し、また、ユーザから報奨の申し込みを受け付けるものである。報奨提供元サーバ１０４は、複数存在してもよい。
【００５８】
（健康機器）
健康機器１０２の構成について、図６を参照して以下に説明する。
【００５９】
図６は、健康機器１０２の構成を示すブロック図である。図６に示すように、健康機器１０２は、測定部（測定手段）６０１および健康データ供給部（健康情報供給手段）６０２を含んで構成されている。
【００６０】
測定部６０１は、ユーザが実施した運動の種類および強度などの運動状態またはユーザの血圧および体温などの生理状態を測定する部分である。運動状態の測定としては、例えば、歩数の測定が挙げられる。また、生理状態の測定としては、体重、体脂肪、血圧、血糖値、脈拍および基礎体温などの測定が挙げられる。本実施の形態では、健康データとして歩数を用いているため、測定部６０１は歩数を測定するものである。
【００６１】
健康データ供給部６０２は、測定部によって測定された健康データの実測値を、健康管理端末１０１に供給するための部分である。また、実測値とともに測定日時も同時に供給できる。具体的には、Ｂｌｕｅｔｏｏｔｈ（登録商標）および赤外線通信などの無線接続、またはＵＳＢ接続などの有線接続による通信手段を介して、健康管理端末１０１に健康データを供給する部分である。健康機器１０２と健康管理端末１０１とが一体となっている場合には、後述する健康データ取得部２０１とバスを介して接続されていればよい。あるいは健康データ供給部６０２が、後述する健康データ記憶部２０２と直接接続されていてもよい。この場合には、健康データ供給部６０２が後述する健康データ取得部２０１として機能する。
【００６２】
（健康管理端末）
健康管理端末１０１の構成について、図１を参照して以下に説明する。
【００６３】
図１は、健康管理端末１０１の構成を示すブロック図である。図１に示すように、健康管理端末１０１は、端末情報処理部２４０、端末情報記憶部２３０および情報提示部（素材情報提示手段）２０９を含んで構成されている。
【００６４】
情報提示部２０９は、画像や各種情報をユーザに提示するためのインターフェースであり、ＬＣＤ（液晶ディスプレイ）などの表示手段およびスピーカなどである。
【００６５】
端末情報記憶部２３０は、種々のデータを記憶しているものである。本実施の形態では、端末情報記憶部２３０には、後述の健康データ取得部２０１が健康機器１０２から取得した健康データを記憶しておくための健康データ記憶部２０２、および後述の報奨情報取得部２０３がサービスサーバ１０３から受信した報奨情報を記憶しておくための報奨情報記憶部２０４を含んでいる。端末情報記憶部２３０は、例えば、ハードディスク、フラッシュメモリ、ＲＡＭなどの記憶装置を用いることができる。
【００６６】
端末情報処理部２４０は、健康管理端末１０１における種々の情報処理をおこなうためのものであり、健康データ取得部（健康情報取得手段）２０１、報奨情報取得部（報奨情報受信手段）２０３、対象健康データカウント部（判定手段、単位判定手段）２０５、条件チェック部（判定手段、単位判定手段）２０６、提示内容更新部（単位判定手段、提示態様決定手段）２０７、および報奨申し込み部（報奨申込手段）２０８を含んで構成されている。端末情報処理部２４０は、例えば中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの装置を用いることができる。
【００６７】
健康データ取得部２０１は、健康機器１０２から、Ｂｌｕｅｔｏｏｔｈおよび赤外線通信などの無線接続、またはＵＳＢ接続などの有線接続による通信手段を介して、またはバスを介して、健康機器１０２から健康データを取得するためのものである。健康データ取得部２０１は、取得した健康データを健康データ記憶部２０２に蓄積させることができる。
【００６８】
なお、健康管理端末１０１と健康機器１０２が一体となっている場合、例えば、健康機器１０２の測定部６０１が歩数をカウントできるセンサ（加速度センサ等）であり、当該センサを健康管理端末１０１が内蔵している場合には、同様に健康管理端末１０１に内蔵されている健康データ供給部６０２が直接健康データ記憶部２０２に健康データ（歩数データ）を記憶させてもよい。この場合には、健康データ供給部６０２が健康データ取得部２０１として機能する。
【００６９】
報奨情報取得部２０３は、無線通信装置を介して、サービスサーバ１０３から報奨情報を受信して取得する部分である。報奨情報については、詳細は後述するが、ユーザがどの報奨にチャレンジするかを選択できるような情報であることが望ましい。報奨情報取得部２０３では、サービスサーバ１０３から受信した報奨情報リストのうち、ユーザが選択した報奨情報をサービスサーバ１０３に送信する。報奨情報取得部２０３は、取得した報奨情報を報奨情報記憶部２０４に記憶させることができる。
【００７０】
対象健康データカウント部２０５は、報奨を獲得するための条件の対象となる健康データを集計する部分である。対象健康データカウント部２０５は、報奨情報記憶部２０４に記憶している報奨情報を読み出して、報奨を獲得するための条件の対象となる健康データを認識する。次いで、この認識に基づいて健康データ記憶部２０２から健康データを読み出して、条件チェックするために健康データを集計する。例えば、報奨がもらえる条件となる健康データが「歩数データの累積」であれば、健康データ記憶部２０２において記憶している歩数データから、対象期間（報奨へのチャンレンジを開始した日〜現在）の累積歩数を算出する。
【００７１】
条件チェック部２０６は、対象健康データカウント部２０５が集計した健康データが、報奨情報にて指定されている条件を満たすか否かを判定する部分である。条件チェック部２０６は、報奨情報記憶部２０４に記憶している報奨情報にて指定されている２つの条件：（１）報奨獲得の条件である申込条件（申込条件情報）、および（２）条件未達の段階においてユーザへ提示内容を変更する単位の条件である単位条件（単位条件情報）を読み込む。そして、対象健康データカウント部２０５が集計した健康データが、上記（１）および（２）の条件をクリアしているかどうかを判定する。
【００７２】
提示内容更新部２０７は、情報提示部２０９に提示させる内容を決定、変更する部分である。提示内容更新部２０７は、条件チェック部２０６による判定の結果を受けて、情報提示部２０９に提示させる内容を決定する。条件チェック部２０６における判定結果が上記（１）の条件をクリアしていれば、情報提示部２０９に報奨提供元サーバへの申し込み用のボタンを表示させる。上記（１）の条件は満たさないが上記（２）の条件を満たす場合には、健康データに応じた提示内容に変更させる。
【００７３】
報奨申し込み部２０８は、ユーザによる申し込み用ボタンの押下をトリガーとして、報奨の申し込みをおこなう指示を受け付け、報奨提供元サーバ１０４へ報奨の申し込みを送信する部分である。報奨申し込み先の情報については、ＵＲＬ、メールアドレスおよび電話番号などの形式で、あらかじめ健康管理端末１０１に記憶されているか、または報奨提供元サーバ１０４から送信される報奨情報に含まれている。
【００７４】
報奨申し込み部２０８は、申し込み条件をクリアした段階で、申し込み先の情報を読み込み、報奨の申し込みをおこなう。報奨申し込み部２０８による報奨の申し込みは、インターネットによる特定のホームページ接続での申し込み、メール送信による申し込み、電話による申し込みであり得る。
【００７５】
図３は、健康データ記憶部２０２に記憶される健康データのテーブルの一例を示す図である。図３に示すように、この例では、健康データを日付ごとの歩数の累積値として記憶している。本実施の形態では示さないが、時間ごとの歩数および曜日ごとの歩数などを記憶していてもよい。
【００７６】
（サービスサーバ）
サービスサーバ１０３の構成について、図４を参照して以下に説明する。
【００７７】
図４は、サービスサーバ１０３の構成を示すブロック図である。図４に示すように、サービスサーバ１０３は、報奨情報受付部（報奨情報受付手段）４０１、報奨情報蓄積部４０２およびサービスサーバ報奨情報送信部（第２報奨情報送信手段）４０３を含んで構成されている。
【００７８】
報奨情報受付部４０１は、報奨提供元サーバ１０４から送信される報奨情報を受信する部分である。受信の媒体としては、インターネットが可能であり、報奨情報の登録用のウェブページを用意しておいて、報奨提供元サーバ１０４において作成された報奨情報を、このウェブページからサービスサーバ１０３に登録することができる。
【００７９】
報奨情報蓄積部４０２は、報奨情報受付部４０１において報奨提供元サーバ１０４から受信した報奨情報を蓄積、登録しておく部分である。
【００８０】
サービスサーバ報奨情報送信部４０３は、報奨情報蓄積部４０２で記憶しておいた報奨情報およびそのリストを、健康管理端末１０１へ送信する部分である。
【００８１】
なお、本実施の形態においては、健康管理システム１００にサービスサーバ１０３を含め、報奨提供元サーバ１０４から提供される報奨情報を、サービスサーバ１０３を介して健康管理端末１０１に送信しているが、別の実施形態として、ヘルスケアシステム１００にサービスサーバ１０３を含めずに、報奨情報を報奨提供元サーバ１０４から直接健康管理端末１０１に送信することも可能である。報奨提供元サーバ１０４が複数ある場合には、各報奨情報の管理および健康管理端末１０１における操作の観点から、ヘルスケアシステム１００は、サービスサーバ１０３を含んでいることが好ましい。
【００８２】
（報奨提供元サーバ）
報奨提供元サーバ１０４の構成について、図５を参照して以下に説明する。
【００８３】
図５は、報奨提供元サーバ１０４の構成を示すブロック図である。図５に示すように、報奨提供元サーバ１０４は、提供元報奨情報送信部（第１報奨情報送信手段）５０１、および報奨申込受付部（報奨受付手段）５０２を含んで構成されている。
【００８４】
提供元報奨情報送信部５０１は、サービスサーバ１０３に対して報奨情報を送信する部分である。
【００８５】
報奨申込受付部５０２は、測定された健康データが上記報奨情報に含まれている健康データの目標値をクリアしたときに、健康管理端末１０１からの報奨の申し込みを受け付ける部分である。
【００８６】
なお、報奨情報の本体については、報奨提供元サーバ１０４または報奨提供元サーバ１０４と通信可能な別の媒体において、後述の図６に示すような所定のフォーマットで作成され得る。
【００８７】
（報奨情報）
報奨情報について、図７，８および１０を参照して以下に説明する。
【００８８】
図７は、報奨情報の具体例を示す図である。この報奨情報は、報奨提供元サーバ１０４から、サービスサーバ１０３に対して送信されるものである。図７に示すように、報奨情報は、提供者名、単位（単位条件）、条件（申込条件）、カバー画像名、報奨画像名および報奨申込先に関する情報が含んで構成されている。
【００８９】
提供者名は、報奨情報を提供した人または団体の名称で、例えば、報奨を提供する企業名またはサークル名である。この提供社名は、ユーザが報奨を選択する際に表示される。
【００９０】
単位は、表示内容を切り替えるための１単位あたりの健康データである。図７では、単位が「累積歩数１０，０００歩」となっているが、これは、累積歩数が１０，０００歩、２０，０００歩、３０，０００歩、…と１０，０００歩クリアするごとに表示内容を切り替えるという意味である。
【００９１】
条件は、報奨を申し込むことができる健康データの条件である。図７では、「累積歩数１２０，０００歩」となっているが、これは、累積歩数が１２０，０００歩をクリアした段階で、後述の報奨申し込み先の情報に基づいて、報奨提供元サーバ１０４へのアクセスが可能になる条件である。
【００９２】
カバー画像名および報奨画像名は、報奨をクリアするまでに表示内容を切り替える際に利用する画像ファイルの名称である。図７では、それぞれファイル名のみ記憶しており、実体となる画像ファイルは別に保存している。カバー画像および報奨画像は、報奨画像の上にカバー画像が重なった状態になっており、報奨画像がカバー画像により隠された状態になっている。本実施の形態では、カバー画像は、健康データの単位＝１０，０００歩をクリアするごとに、部分的に非表示状態にすることで、背景に隠れていた報奨画像が見えてくるようになる。健康データの単位が１０，０００歩、報奨を申し込むための条件は１２０，０００歩であるので、報奨を申し込むための条件が満たされるまでに、表示の更新は１２回おこなわれることになる。
【００９３】
報奨申し込み先は、条件に達した際に報奨を申し込むアクセス先の情報であり、具体的には、報奨提供元サーバまたは報奨提供元企業のＵＲＬ、メールアドレスおよび電話番号などである。
【００９４】
図８は、サービスサーバ１０３の報奨情報蓄積部４０２において登録、蓄積される報奨情報の例を示す図である。図８に示すように、報奨情報蓄積部４０２では、図７に示すような報奨情報を、報奨提供元サーバ１０４より受信して、順次蓄積していく。また、各報奨情報を識別するために、報奨ＩＤを付与して記憶しておく。
【００９５】
図１０は、健康管理端末１０１における報奨情報の一覧の表示例を示す図である。サービスサーバ報奨情報送信部４０３は、報奨情報蓄積部４０２に記憶している報奨情報に基づいて、健康管理端末１０１が表示可能な形式（ＨＴＭＬ、ＸＭＬおよびＪＰＧ画像など）で、報奨情報の一覧を健康管理端末１０１に送信する。図１０の表示例では、３つの報奨情報が表示されており、報奨の提供社名と、報奨申し込みの条件になる歩数の値が表示されている。健康管理端末１０１はこの情報を表示し、どの報奨にチャレンジするかをユーザに選択させる。
【００９６】
（ヘルスケアシステムの処理）
次に、以上のように構成されたヘルスケアシステム１００にて実行される処理について、図９を参照して以下に説明する。
【００９７】
図９は、ヘルスケアシステム１００の処理の流れを示すフローチャートである。図９を参照しながら、ステップＳ１００〜Ｓ１０９、ステップＳ１１０〜Ｓ１１２、およびステップＳ１１３〜Ｓ１１４について説明すれば以下の通りである。
【００９８】
報奨提供元サーバ１０４の提供元報奨情報送信部５０１が、登録するための報奨情報をサービスサーバ１０３に対して送信する（Ｓ１１３）。ここで報奨情報は、図７に示す内容である。
【００９９】
サービスサーバ１０３の報奨情報受付部４０１は、提供元報奨情報送信部５０１から送信された報奨情報を受信し、受信した報奨情報を報奨情報蓄積部４０２に登録し、記憶する（Ｓ１１０）。サービスサーバ１０３は、後述するステップＳ１００における健康管理端末１０１からの問い合わせを受け付けると、蓄積している報奨情報の一覧を健康管理端末１０１に対して送信する（Ｓ１１１）。
【０１００】
健康管理端末１０１は、チャレンジ可能な報奨情報がないかサービスサーバに問い合わせる（アクセスする）（Ｓ１００）。健康管理端末１０１は、サービスサーバ１０３から送信された報奨情報の一覧を受け付け、情報提示部２０９に、図９に示されるような報奨情報の一覧を表示させる（Ｓ１０１）。健康管理端末１０１は、どの報奨にチャレンジするかの選択をユーザから受け付け、その選択結果をサービスサーバ１０３へ送信する（Ｓ１０２）。
【０１０１】
サービスサーバ１０３が選択結果を受け付けると、サービスサーバ報奨情報送信部４０３は、選択結果に基づく報奨情報の本体（図１０に示す情報）を健康管理端末１０１へ送信する（Ｓ１１２）。
【０１０２】
報奨情報取得部２０３は、ステップＳ１１２において送信された報奨情報の本体を受信し、報奨情報記憶部２０４に記憶しておく（Ｓ１０３）。
【０１０３】
この間、健康機器１０２の測定部６０１は、ユーザの歩数（健康情報）の測定を開始し、計測している。
【０１０４】
次に、健康管理端末１０１の健康データ取得部２０１は、報奨を申し込むために必要な健康データを健康機器１０２から取得する。なお、本実施の形態においては、健康管理端末１０１が歩数をカウントできるセンサ（加速度センサ等）を内蔵しており、健康機器１０２と一体となっているものである。測定部６０１が、健康データの測定をおこない（Ｓ１０４）、対象健康データカウント部２０５が、報奨情報に指定されている対象データをカウントする（Ｓ１０５）。図７に示す報奨情報の場合、単位条件および申込条件の判定に累積歩数が必要なので、対象健康データカウント部２０５は累積歩数をカウントする。その後、条件チェック部２０６は、カウントした累積歩数が報奨情報に指定されている申込条件＝１２０，０００歩をクリアしたかどうかを判断（判定）する（Ｓ１０６）。条件をクリアしていない場合（Ｓ１０６のＮＯ側）、条件チェック部２０６は単位条件をクリアしたかどうかを判断する（Ｓ１０７）。単位条件をクリアしている場合は（Ｓ１０７のＹＥＳ側）、提示内容更新部２０７は提示態様を変更して、表示内容の更新をおこなう（Ｓ１０８）。
【０１０５】
ここで、表示内容の更新について具体的に説明する。本実施の形態では、健康データの測定は、健康管理端末１０１において報奨選択以前より継続しておこなわれており、報奨情報を選択した段階から、歩数データに基づいて、報奨申し込みのためのチャレンジが始まる。したがって、報奨を選択した日が「２００８／７／１７」の場合には、報奨チャレンジの対象となるのは「２００８／７／１７」以降の歩数データとなる。したがって、対象健康データカウント部２０５は、表示内容の更新タイミング（１日１回定期的に、もしくは、ユーザのボタン操作時など）に、報奨チャレンジの対象となる累積の歩数データをカウントする（Ｓ１０５）。例えば、カウントした日が「２００８／７／１９」の場合、健康管理端末１０１の健康データ記憶部２０２において記憶されている図３に示す健康データから「２００８／７／１７〜２００８／７／１９」の歩数データを累積すると、累積歩数データは「１３，０００歩」となる。この場合は、図７に示す報奨情報において、条件となる「１２０，０００歩」をクリアしていないことになる。そのため、条件チェック部２０６は、条件をクリアしていないと判断する（Ｓ１０６のＮＯ側）。この場合、条件チェック部２０６は、単位条件をクリアしているかどうかのチェックをおこなう（Ｓ１０７）。単位条件は、図７に示す通り「１０，０００歩」であり、累積歩数データは「１３，０００歩」である。よって、単位条件はクリアしているので、条件チェック部２０６は、単位条件をクリアしていると判断する（Ｓ１０７のＹＥＳ側）。単位条件を満たしていると条件チェック部２０６が判断すると、提示内容更新部２０７は提示態様を変更して、表示内容を更新する（Ｓ１０８）。
【０１０６】
累積歩数データを増やしていき、条件である「１２０，０００歩」を超えた場合（Ｓ１０６のＹＥＳ側）、健康管理端末１０１は、報奨情報に含まれているアクセス先にアクセスして、報奨を申し込む（Ｓ１０９）。報奨提供元サーバ１０４の報奨申込受付部５０２は、健康管理端末１０１からの報奨申し込みを受信し、申し込みを受け付ける（Ｓ１１４）。
【０１０７】
次に、上記処理をおこなっているときの、健康管理端末１０１の情報提示部２０９に表示される内容について、図１１〜図１３を参照して以下に説明する。
【０１０８】
図１１は、画像の具体例を示す図であり、（ａ）はカバー画像を、（ｂ）は報奨画像（報奨表示画像）の例である。図１１（ａ）に示す例では、カバー画像は、報奨の提供元である「ＡＢＣ ＳＴＥＰ」の企業の宣伝をした画像である。カバー画像は、条件をクリアするまでは健康管理端末１０１に表示される。そのため、広告および宣伝として使用すると、報奨提供元にとって有効である。
【０１０９】
報奨画像は、報奨の内容を示す画像である。条件がクリアされるまでは、カバー画像に隠れて表示される。初期状態では、報奨画像の上に、カバー画像が重なった状態である。すなわち、報奨画像はカバー画像によって隠されている。
【０１１０】
図１２は、申込条件をクリアしていない状態における情報提示部２０９に表示される表示例を示す図である。本実施の形態では、図１２に示すように、カバー画像を複数の領域（ピース）に分割し、領域ごとにカバー画像の表示／非表示を選択し、カバー画像を部分的に非表示にしていくことで、報奨画像を徐々に表示する。分割されたカバー画像のすべてを非表示にしないと（すなわち、申込条件をクリアしないと）、報奨画像の全貌が明らかにならないようにしている。
【０１１１】
提示内容更新部２０７では、累計歩数データ＝１３，０００歩と、図７に示す報奨情報における単位条件＝１０，０００歩および条件＝１２０，０００歩とを用いて、カバー画像をいくつ非表示状態にできるかどうかを計算する。すなわち、カバー画像は、目標値である条件（１２０，０００）を、表示を切り替えるための単位条件（１０，０００）で割った結果である１２領域（１２０，０００÷１０，０００）に分割されることになる。逆に言うと、分割後のカバー画像の１領域を非表示にするには、１０，０００歩の歩数データが必要であり、分割後のカバー画像の全ての領域を非表示にするには、１２０，０００歩の歩数データが必要になるということである。
【０１１２】
現在、累積歩数データが１３，０００歩であるので、分割後のカバー画像の１領域を非表示にできることになる。図１２には、「めくれるピース数 １個」として表示している。カバー画像が１２個の領域に分割されて、中心あたりの１領域が非表示となっており、また、背景に報奨画像が重なっているので、カバー画像が非表示になっている部分から、報奨画像が見えるようになっている。累積歩数データが増えるにしたがって、分割後のカバー画像における非表示にできる領域が増えるので、背景画像の全体像が見えるようになり、報奨の内容が明らかになってくる。報奨の内容が徐々に明らかになれば、ユーザがこの報奨をなんとしても獲得するためにもっと歩いて歩数データを増やす効果もあり、ユーザのモチベーションを高めることができる。
【０１１３】
なお、図１２において、分割後のカバー画像は、提示内容更新部２０７で自動的に非表示にする部分を決めても良いし、健康管理端末１０１に操作部を備えている場合には、どこを非表示にするかをユーザに選択させてもよい。
【０１１４】
同様に、累積歩数データが「２３，０００歩」の場合、条件はクリアしていないが（Ｓ１０６のＮＯ側）、単位条件はクリアしているので（Ｓ１０７のＹＥＳ側）、表示内容を更新することになる（Ｓ１０８）。上述の通り、分割後のカバー画像の１領域を非表示にするには１０，０００歩必要なので、累積歩数データ＝２３，０００歩の場合には、カバー画像の２つの領域を非表示にできる。
【０１１５】
図１３は、条件をクリアした状態の健康管理端末１０１の情報提示部２０９における表示例を示す図である。図１３に示すように、分割されたカバー画像は、すべて非表示となり、報奨申し込み先へアクセスすることができるボタン（報奨申込手段）１３０１が表示されている。図７の報奨情報においては、報奨申し込み先は、報奨提供元サーバ１０４へアクセスするためのＵＲＬであるので、ボタン１３０１を押して報奨を申し込むと、報奨提供元サーバ１０４上のホームページが表示される。このホームページ上で、報奨を提供するための送付先住所を入力させることで、アンケートの入力をさせるなどしてマーケティングに利用することができる。実際に健康改善の取り組みをおこなった結果健康データの条件をクリアしたユーザの健康管理端末１０１からのみ申し込みがなされるので、アンケートについても有益な情報や感想を得ることができる。
【０１１６】
このように、本発明のヘルスケアシステム１００によれば、報奨提供元サーバ１０４からの報奨情報をサービスサーバ１０３を介して、さらに健康管理端末１０１へ送信する。健康管理端末１０１においては、実測した健康データに応じて、報奨情報に指定されている単位条件および申込条件に基づき表示内容が切り替わる。また用いるデータは健康機器１０２によって実際に測定したデータであるため、ユーザは、報奨の全貌が明らかになるまでがんばって健康データを測定しようというモチベーションおよび健康改善のための取り組みを継続しておこなおうというモチベーションが高まる。また、報奨提供元にとっても、健康データという条件を指定して、ユーザの行動および生活状態をある程度絞り込むことができるので、より良い広告および宣伝情報を提供することができる。
【０１１７】
なお、本実施の形態においては、健康データとして歩数データを利用しているが、これに限定されるものではなく、例えば、体重、体脂肪、血圧、血糖値、脈拍および基礎体温などの健康データも利用可能である。
【０１１８】
例えば、体重データを利用する場合、図７に示す報奨情報において、単位条件「単位＝減量値 −０．５ｋｇ」、申込条件「条件＝減量値 −３ｋｇ」というように設定できる。また、図９に示すフローチャートに基づくと、ステップＳ１０４において体重計（健康情報測定装置）からデータを無線もしくは有線で取得することで、体重データを取得する。次に、健康管理端末１０１において対象データのカウントをおこなうが（Ｓ１０５）、健康データ記憶部２０２に記憶されている体重データを参照して、記録開始日の体重（例えば７５．６ｋｇとする）を基準として、以降の体重データとの差をとる。例えば、報奨へのチャレンジ開始後１０日目に測定した体重が「７４．８ｋｇ」の場合、開始日からの差は「−０．８ｋｇ（７４．８ｋｇ−７５．６ｋｇ）」である。この「−０．８ｋｇ」が対象データとなる。次に、対象データに基づいてチェックをおこなう。申込条件である「減量値 −３ｋｇ」はクリアしていないが（Ｓ１０６のＮＯ側）、単位条件である「減量値 −０．５ｋｇ」はクリアしている（Ｓ１０７のＹＥＳ側）。単位条件が更新されているので、図７の報奨情報に指定されているカバー画像および報奨画像により提示内容を更新する（Ｓ１０８）。このように、体重データの場合は、減量／増量の目標値（上記例では「−３ｋｇ」）を設定して、それに対してチャレンジするようにすると有効である。また、上記例では、各条件を、開始日からの減量値として設定したが、具体的な目標体重「６５．０ｋｇ」というようにしてもよい。具体的な体重目標については、例えば、健康上適切だといわれている標準的な体重値（ＢＭＩ（Ｂｏｄｙ Ｍａｓｓ Ｉｎｄｅｘ）が２２となるような体重）を目標値にして、この標準体重を目指してがんばるようにすると、健康支援としても有効である。
【０１１９】
また、体脂肪データを用いる場合も、体重データとほぼ同じようにできる。すなわち、体脂肪データをそのまま利用する場合は、申込条件を「体脂肪率 −３％」とし、単位条件を「体脂肪率 −０．２％」とすることで、開始時点での体脂肪率からの差分を対象データとし、単位条件および申込条件のチェックをおこなう。
【０１２０】
また、血圧データを利用する場合は、至適血圧と言われている「収縮期血圧１３０ｍｍＨｇ以下、かつ、拡張期血圧８０ｍｍＨｇ以下」となった日が何日あるかといった形態で利用できる。例えば、図７において、申込条件が「至適血圧 ３０日間」となり、単位条件が「至適血圧 ２日間」と指定できる。報奨チャレンジ後、健康データ記憶部２０２で記憶している血圧値に基づいて、至適血圧を満たす日が何日あるかをチェックする。例えば、至適血圧を満たす日が開始日からカウントして「５日間」であった場合、単位条件（２日間）はクリアしているが（Ｓ１０７のＹＥＳ側）、申込条件（３０日間）はクリアしていない（Ｓ１０６のＮＯ側）、というようになる。なお、血圧データでは、データの性質上、がんばって数値自体を増やすものでも減らすものでもなく、継続して測定して傾向を把握して適切な医療措置をとることが重要になる。そのため、血圧データを利用する場合には、後述する実施の形態５における利用方法が望ましい。
【０１２１】
血糖値データおよび脈拍データを利用する場合も、血圧データと同様である。また、血糖値データおよび脈拍データでは、数値として何ｍｇ／ｄＬ増えたか／減ったかというよりも、継続して記録しておくことが重要になる。そのため、血糖値データおよび脈拍データを利用する場合にも、後述する実施の形態５における利用方法が望ましい。
【０１２２】
基礎体温データは、データ自体に個人差があり、また体調のチェックが目的であり、がんばって上げたり下げたりするものではない。そのため、基礎体温データを利用する場合には、後述する実施の形態５における利用方法が望ましい。
【０１２３】
〔実施の形態２〕
本発明に係るヘルスケアシステムの第２の実施形態について、図１４および図１５に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１２４】
第１の実施の形態では、カバー画像を複数の領域に分割して、部分的に非表示にすることによって、背景にある報奨画像を表示させるようにしている。本実施の形態では、一定時間、カバー画像に代えて報奨画像を表示させるものである。そして取得した健康データに応じて、報奨画像を表示させる時間を変更している。
【０１２５】
図１４は、報奨情報の具体例を示す図である。図７に示す報奨情報と異なり、「表示単位＝０．２秒」が追加されている。表示単位（表示単位時間情報）については、歩数データの累積値が「単位＝１０，０００歩」を超えるごとに、報奨画像の表示時間が０．２秒ずつ増えていくことを意味する。すなわち、累積歩数が２０，０００歩、３０，０００歩になった場合には、報奨画像の表示時間はそれぞれ「０．４秒」、「０．６秒」となる。累積歩数に基づく表示時間の決定は、提示内容更新部２０７においておこなわれる。
【０１２６】
図１５は、健康管理端末１０１における表示例を示す図である。図１５では、カバー画像が表示されている。図１５に示す状況では、累計歩数は３３，０００歩である。したがって、報奨画像の表示時間は０．６秒（０．２秒×３）となる。ボタン１５０１は、報奨画像の表示を開始するためのボタンである。ボタン１５０１を押すと、０．６秒間だけカバー画像に代えて報奨画像が表示される。０．６秒経過後は、再び、カバー画像が表示され、報奨画像は見えなくなる。
【０１２７】
なお、別の実施の形態として、指定された表示時間、報奨画像を表示し、報奨画像が表示されていない間は、画像をなにも表示させないという形態も可能である。
【０１２８】
以上のように、本実施の形態では、健康データに応じて、報奨画像が表示される時間が変更される。具体的には、累積歩数が増加すれば、報奨画像の表示時間が長くなる。そのため、ユーザは、報奨画像をもっと長時間表示させるために、健康データを増やす（累積歩数を増加させる）ようにがんばるようになる。すなわち、ユーザのモチベーションを高めることができる。また、報奨画像を表示していない状態においてはカバー画像が常に表示されており、ボタンを押された場合のみ報奨画像に切り替わって表示される。そのため、報奨提供元サーバにとっては、カバー画像に自社の広告および宣伝の表示をしておけば、有効な宣伝および広告をおこなうことができる。
【０１２９】
〔実施の形態３〕
本発明に係るヘルスケアシステムの第３の実施形態について、図１６および図１７に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１３０】
第１および第２の実施の形態では、カバー画像および報奨画像ともに、静止画像を用いている。本実施の形態では、動画を用いて、報奨内容を表示させている。
【０１３１】
図１６は、動画を用いる場合における報奨情報の具体例を示す図である。図７および図１４で示した報奨情報とは異なり、「カバー画像名」、「報奨画像名」および「表示単位」の情報がなくなり、「報奨動画名＝Gohoubi-movie.mpg」および「再生単位＝１０秒」が追加されている。報奨動画名は、取得した健康データの数値に応じて再生する動画のファイル名である。また、再生単位（再生単位時間情報）は、単位歩数＝１０，０００歩ずつ歩数データが増えるごとに増加させる、再生時間の増加単位である。図１６に示す報奨情報を用いる場合には、１０，０００歩増えるごとに、１０秒ずつ再生時間が増えることになる。累積歩数に基づく再生時間の決定は、提示内容更新部２０７においておこなわれる。
【０１３２】
図１７は、健康管理端末１０１における表示例を示す図である。図１７に示す例では、累積歩数が１３，０００歩なので、図１６に示す報奨情報を参照して、報奨動画の再生時間は１０秒間となる。図１７（ａ）は報奨動画を再生する前の状態を示し、図１７（ｂ）は報奨動画の再生途中の状態を示す。図１７（ａ）に示すように、再生前の状態では「ビデオを再生する」というボタンが表示されている。このボタンを押すと、図１７（ｂ）に示すように、報奨動画を、再生時間である１０秒間だけ再生して、１０秒終了後には停止する。その後、健康データが増えるにつれて、すなわち、累積歩数が増加するにつれて、再生時間が１０秒単位で増えていくことになる。
【０１３３】
以上のように、本実施の形態では、動画の再生時間が、健康データの数値に応じて変更する。具体的には、累積歩数が増加すれば、動画の再生時間が長くなる。そのため、ユーザは、動画をもっと長時間再生できるようにするために、健康データの数値をもっと増やす（累積歩数を増加させる）ようにがんばるようになる。すなわち、ユーザのモチベーションを高めて、健康改善をおこなうことができるようになる。また、健康データを利用して段階的に動画再生することにより、ユーザは健康データの単位条件をクリアするたびに何回も動画再生することになる。そのため、報奨提供者側においても、効果的な広告および宣伝をおこなうことができる。
【０１３４】
〔実施の形態４〕
本発明に係るヘルスケアシステムの第４の実施形態について、図１８〜図２０に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１３５】
第１の実施の形態では、カバー画像の種類は１種類である。本実施の形態では、複数のカバー画像を用いている。
【０１３６】
図１８は、本実施の形態の報奨情報の具体例を示す図である。図１８に示すように、複数（図１８では１２枚）のカバー画像（cover1.jpg, cover2.jpg, …）が登録されている点が、実施の形態１とは異なる。
【０１３７】
図１９は、カバー画像の具体例を示す図である。図１９では、説明のために３種類のみ例示しているが、報奨情報に登録されているカバー画像の数だけ、すなわち、図１８の報奨情報を用いる場合には、１２枚存在することになる。
【０１３８】
図２０は、健康管理端末１０１における表示例を示す図である。実施の形態１では、１枚のカバー画像を１２の領域（＝１２０，０００歩÷１０，０００歩）に分割して、分割画像１領域ずつ部分的に非表示にしていた。本実施の形態では、図１９に示すカバー画像を、報奨情報に指定されている単位＝１０，０００歩ごとにカバー画像自体を切り替えて表示する。表示の順番は、登録されている画像ごとに順番で良い（図１８に示す報奨情報の場合には、cover1.jpg→cover2.jpg→…の順番）。図２０（ａ）は、カバー画像の一つが表示されている状態を示し、図２０（ｂ）は、申込条件をクリアし報奨画像が表示されている状態を示している。図２０（ａ）に示す状態では、現在の累積の歩数が１３，０００歩なので、カバー画像２００１の部分は、図１９に示す「cover1.jpg」を表示している。歩数データが上がって、２３，０００歩になった場合は、カバー画像２００１には「cover2.jpg」を表示する。また、図２０（ｂ）は、歩数データが累積されて、報奨情報に記載されている申込条件＝１２０，０００歩を超えた状態である。この場合は、カバー画像が表示されずに、報奨画像が表示されている。また、報奨申込先へアクセス可能なボタン２００２が表示されている。
【０１３９】
以上のように、複数のカバー画像が切り替わって表示されるので、ユーザは健康データが増えるたびに、次に何が表示されるのかが楽しみになり、モチベーションを維持しながら、健康改善の取り組みをおこなうことができる。また、複数のカバー画像がユーザに提示されるため、報奨提供先においても、カバー画像に自社の広告および宣伝の表示をしておけば、効果的な宣伝および広告をおこなうことができる。
【０１４０】
〔実施の形態５〕
本発明に係るヘルスケアシステムの第５の実施形態について、図２１〜図２６に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１４１】
前述の実施の形態では、申込条件および単位条件の判定に利用する健康データは、実測した健康データの数値自体（歩数）である。本実施の形態では、利用する健康データは、測定された数値データ自体ではなく、健康データを測定、記録した回数である。
【０１４２】
図２１は、健康管理端末１０１の健康データ記憶部２０２に格納されているテーブルを示している。「日付」は歩数データを記録した日にちを、「歩数データ」はその日の歩数データを表わしている。ここで、「２００８／７／２０」は、歩数データが「０歩」であることを示す。記録としては「０歩」として数値データとしては存在するが、まったく歩いていないという状態となるため、ここでは記録日数としてはカウントしない。また、「２００８／７／２４」は、歩数データの欄が「−」で表示されている。これは、本当に歩数を記録をしていないことを意味し、例えば歩数計自体の電池切れなど、歩数計が作動していなかった場合が該当する。歩数データが記録されている場合は、測定部６０１が測定した歩数データは、健康データ供給部６０２から健康データ取得部２０１を通して、健康管理端末１０１の健康データ記憶部２０２に記憶される。歩数データの欄に数値が記録されている日は、歩数の記録があった日である。なお、本実施の形態では、歩数の１日分の累計値を記録しているが、データの欄に、１日のうち１時間毎の歩数が記録されており、その１時間ごとの歩数データの有無で判断しても良い。
【０１４３】
図２２は、報奨情報の具体例を示す図である。単位条件として「歩数記録 ３日間」、申込条件として「歩数記録 ６０日間」が指定されている。これは、提示内容を更新する単位条件が「歩数を記録した日が合計３日」であり、申込条件をクリアするには「歩数の記録をした日が合計６０日」必要ということである。歩数記録の有無については、対象健康データカウント部２０５において集計する。ここで、実施の形態１に示すように達成度に応じてカバー画像を分割して表示させる場合に、カバー画像「Sky-Cover.jpg」を分割する個数については、申込条件である６０日を、単位条件となる３日で割った日数＝２０（６０日÷３日＝２０個）である。
【０１４４】
次に、歩数を記録した日数のカウント方法について説明する。ここで、図２１に示すテーブルを参照して、報奨へのチャンレンジを始めた日を「２００８／７／１７」、表示する日を「２００８／７／２４」とした場合、「２００８／７／１７〜２００８／７／２４」までで、カウントの対象となり得る歩数データを記録した日は「２００８／７／１７」「２００８／７／１８」「２００８／７／１９」「２００８／７／２２」の４日間となる。
【０１４５】
上記例によると、申込条件である「歩数記録 ６０日間」はクリアしていないが、単位条件である「歩数記録 ３日間」はクリアしていることになる。また、提示内容更新にあたっては、カバー画像（Sky-Cover.jpg）を分割した画像１領域を非表示にする。
【０１４６】
健康管理端末１０１における表示イメージを、図２３から２５を用いて説明する。図２３は、カバー画像（Sky-Cover.jpg）の具体例を示す図である。図２４は、報奨画像（Sky-Gohoubi.jpg）の具体例を示す図である。図２５は、健康管理端末１０１における表示イメージである。前述の通り、２００８／７／２４の段階では、歩数を記録した日数の合計が４日間であるため、分割後のカバー画像は１領域を非表示にできる。図２５では、カバー画像を２０個に分割し、分割後の１領域（左下の領域）を非表示にしている。非表示にしたことで、背景となっている報奨画像（Sky-Cover.jpg）の一部が見えるようになっている。
【０１４７】
また、上記に示した例では、単純に記録の有無をカウントしたが、連続して記録しないと、単位条件および申込条件をクリアできないようにしてもよい。図２６に、報奨情報の別の例を示す。ここでは、単位条件として「歩数記録 連続７日間」を１単位としている。連続して７日間記録しないと、単位条件がクリアできないので、単位条件クリアはより困難になる。また、報奨獲得のための条件は「連続７日間の記録 ５回」としている。これは、連続７日間歩数を記録し、それを５回以上クリアしないと、申込条件がクリアできないことを意味している。連続した７日間の記録については、図２１に示す健康データ記憶部２０２に格納されているテーブルを参照して、対象期間（２００７／７／１７〜７／２４）の間で記録のある日が７日以上連続している期間があるかどうかをチェックする。図２１に示すテーブルの例では、７日間連続して記録がされていないため、対象データは「０」となる。したがって、申込条件をクリアしておらず、また、単位条件もクリアしていないことになる。そのため、カバー画像を１領域分も非表示にできない。
【０１４８】
以上の通り、本発明では、記録をおこなった日数により報奨獲得のチャレンジをすることもまた可能である。健康情報の数値を利用する場合には、年齢や性別の違いによって基本的な体力が異なるため、大人および男性の方が有利である場合もある。これに対して、測定、記録をおこなった回数とすることで、誰でも差別なくチャレンジすることができる。また、継続して測定する人は、健康への意識が高い。そのため、報奨提供元である企業は、意識の高いユーザを得ることができ、より効果の高い宣伝および広告をおこなうことができる。
【０１４９】
前述の実施の形態において説明したように、血圧データ、血糖値データ、脈拍データおよび基礎体温データを利用する場合には、そのデータの性質上、本実施の形態での利用方法が望ましい。これによりユーザは、これらのデータを継続して測定するようになり、健康管理に気を配るようになる。
【０１５０】
また、体重データおよび体脂肪データもまた本実施の形態に利用することができる。体重データを利用する場合には、図２１に示すテーブルにおいて「歩数データ」が「体重データ」になっている。そして、図２２に示す報奨情報において単位条件を「体重記録 ３日間」、申込条件を「体重記録 ６０日間」と置き換えるだけで対応できる。また体脂肪データを用いる場合にも同様に、体脂肪率を測定した日数で同じように対応できる。
【０１５１】
〔実施の形態６〕
本発明に係るヘルスケアシステムの第６の実施形態について、図２７，２８および５７に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１５２】
前述の実施の形態では、申込条件および単位条件の判定に利用する健康データは、実測した健康データの数値そのものである。本実施の形態では、対象データを集計する際に、データに重み付けをおこなって、対象データを算出し、重みを付けたデータを用いて各条件を満たしているかの判定をおこなっている。
【０１５３】
図５７は、本実施の形態に係る健康管理端末１０１の概略構成を示すブロック図である。図５７に示すように、健康管理端末１０１は、重み付きデータ算出部（判定手段、単位判定手段、第１重み付加手段、第２重み付加手段）２２１をさらに含んで構成される。重み付きデータ算出部２２１は、後述するカウント基準（重み付け情報）を用いて、集計する健康データに重みを付けて、重み付きの健康データを算出する部分である。
【０１５４】
図２７は、本実施の形態における報奨情報の具体例を示す図である。図２７に示すように、実施の形態１と異なり、「カウント基準」が指定されている。これは、対象となる健康データを対象健康データカウント部２０５でカウントする際に、単に健康データ記憶部２０２において記録している健康データ（この例では歩数データ）の記録数値の通り集計するのではなく、重み付きデータ算出部２２１において記録データに重み付けをおこなった上で集計するための、重み付け基準である。この例では「月〜金：１．０倍、土・日：３．０倍」となっている。これは、曜日ごとに重み付けを変化させ、月〜金曜日の歩数データについては、そのまま（１．０倍）で集計し、土曜日および日曜日の歩数データについては、３．０倍した上で集計することを意味している。
【０１５５】
この場合、条件チェック部２０６は、この重みが付加された後の重み付き歩数データ（重み付き健康情報）が、申込条件および単位条件を満たしているかをチェックする。そして、条件チェック部２０６は、重みが付加された後のデータがそれぞれの条件を満たしている場合に、健康データがそれぞれの条件を満たしていると判定して、その後の処理を実行させる。
【０１５６】
図２８は、健康データ記憶部２０２に格納されている健康データの具体例を示す図である。ここで、対象期間を２００８／７／１７〜７／１９とし、図２７に示す報奨情報を用いた場合、重み付きデータ算出部２２１において、２００８／７／１７＝９２３４歩（１．０倍）、２００８／７／１８＝６２３４歩（１．０倍）、２００８／７／１９＝２２５９６歩（７５３２歩×３．０）、というような重み付けをおこなう。対象健康データカウント部２０５は、この重み付きデータを用いて、累積歩数＝３８０６４歩を算出する。カバー画像の表示方法が実施の形態１における表示方法である場合には、図２７に示す報奨情報を参照すると、表示切り替えの単位は「累積歩数１０，０００歩」なので、累積歩数＝３８０６４歩のときは、分割後のカバー画像を３つの領域を非表示にできる。したがって、提示内容更新部２０７は、分割したカバー画像の３つの領域を非表示にするように表示を切り替える。
【０１５７】
これにより、ユーザは、付加される重みが高いときには健康改善のための取り組みを積極的におこなうようになり、モチベーションが高まる。また、報奨を提供する側は、例えば、「週末にたくさん歩くユーザ」といったように、自社が希望するユーザのプロファイルをより細かく特定することができる。そのため、報奨を提供する側は、効果的な宣伝および広告をおこなうことができる。
【０１５８】
なお、本実施の形態では、重み付けとして、歩数データが増える場合のみ示したが、重みが１．０未満（０．５倍）や、マイナスの値にすることで、減点をおこなうこともできる。さらに、「０倍」に設定するようにすれば、カウントする対象データを絞り込むことができる。また、データを定倍するだけではなく、「土曜日と日曜日の歩数＋１０００歩」といったように、加算データとして重み付けをおこなってもよい。
【０１５９】
〔実施の形態７〕
本発明に係るヘルスケアシステムの第７の実施形態について、図２９〜図３１および図５８に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１６０】
前述の実施形態と異なり、本実施の形態では、条件として、報奨申し込みの締め切り期限も指定している。
【０１６１】
図５８は、本実施の形態に係る健康管理端末１０１の概略構成を示すブロック図である。図５８に示すように、健康管理端末１０１は、期限判定部（期限判定手段）２２２をさらに備えている。期限判定部２２２は、申込条件の判定に用いられる健康データが、報奨の申し込み期限の条件を満たしているかを判定する部分である。
【０１６２】
図２９は、本実施の形態における報奨情報の具体例を示す図である。図２９に示すように、実施の形態１と異なり、期限を指定する情報（期限条件情報）が含まれており「期限：７日間」が指定されている。これは、報奨を選択して、チャレンジを開始した日からの経過日数が７日以内でないと、報奨へ申し込みができないことを意味する。例えば、チャレンジを開始した日が「２００８／７／１７」である場合、期限である「２００８／７／２３」までに、条件＝累積歩数１２０，０００歩をクリアすることが必要になる。
【０１６３】
図３０は、健康管理端末１０１の表示イメージを示す図である。図３０に示すように、申し込み期限である７日間を過ぎた場合は、期限が切れたことを示すメッセージを表示する。このとき、再度チャレンジする場合は（「再度チャレンジ」ボタン押下）、チャレンジ開始日や累積歩数データをクリアして、再度チャレンジをおこなうことができる。なお、このような情報を健康管理端末１０１に表示させるために、期限を指定する情報とともに、これらの情報も報奨情報に含めて健康管理端末１０１に送信すればよい。
【０１６４】
次に、期限のチェックを含むヘルスケアシステム１００にて実行される処理について、図３１を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１６５】
図３１は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、ステップＳ２０６として、期限判定部２２２が、健康データが期限以内のデータであるかどうかのチェックをおこなう。期限以内と判定されると（Ｓ２０６のＹＥＳ側）、条件チェック部２０６は、申込条件または単位条件をクリアしているかどうかのチェックをおこなう。判定に使用する健康データが期限を越えている場合には（Ｓ２０６のＮＯ側）、期限判定部２２２は、図３０に示すような期限切れメッセージを情報提示部２０９に表示させる（Ｓ２１１）。
【０１６６】
なお、今回は、期限として「開始した日からの経過日数」を指定したが、他にも「２００８／９／３０」といったような具体的な日付でもよい。
【０１６７】
このように、報奨の申し込み期限が設定されていることにより、ユーザは期限までに報奨の申し込みができるように努力するため、健康改善の取り組みをおこなうためのモチベーションも高まる。また、報奨を提供する側は、いつまでもずるずるとチャレンジしている積極性の低いユーザを除外することができる。そのため、自社が希望するユーザのプロファイルをより細かく特定することができる。また、新商品の宣伝に利用する際には、新商品のアピール期間があるため、ある程度期間を限定する必要があるが、期限を設定することにより、アピール期間を指定することができる。
【０１６８】
〔実施の形態８〕
本発明に係るヘルスケアシステムの第８の実施形態について、図３２〜３４ならびに図４２および４３に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１６９】
本実施の形態では、報奨情報に指定されている申込条件をクリアしたあと、報奨申し込みをする前に補足情報を表示している。ここで、補足情報の例としては、報奨にチャレンジしている段階で表示している広告および宣伝が正しく伝わっているかをユーザに質問する（クイズをする）ものである。これにより、報奨を提供する企業は、本当に有効な申し込みのみに絞り込むことができる。また別の例としては、報奨を提供するに当たっての報奨提供元の確認事項を表示するものである。
【０１７０】
図３２は、本実施の形態における報奨情報の具体例を示す図である。実施の形態１と異なり、申込前表示（申込前表示情報）および申込前表示データ（申込前情報）が追加されている。申込前表示は、申し込み前に申込前表示データを表示するか否か、および種類を示すフラグである。この例では、「１」が指定されており、申し込み前の表示をおこなって「クイズ」を表示する。また、「０」の場合は、申し込み前の表示をおこなわず、申込条件クリア後、すぐに報奨申し込み先へとアクセスできるボタンを表示する。また、「２」の場合は、報奨を申し込むにあたって、報奨提供元の確認事項を表示させる。申込前表示データは、申込前表示で指定した表示種類（クイズ、確認事項）に対応する表示データの中身である。ここでは、クイズを出すための問題文、回答文の選択肢、および答えのデータが含まれている。
【０１７１】
図３３は、健康管理端末１０１における表示イメージを示す図である。図３３（ａ）は、申込条件をクリアしたあと、図３２に示す報奨情報で指定された申込前表示データにしたがって、表示イメージ３３０１にクイズを表示している図である。ここで、答えが選択されて「決定」ボタンが押下されると、選択された選択肢が、報奨情報で指定されている答えと一致しているかどうかをチェックする。図３３（ｂ）は、選択の結果、正解した場合の表示を示す図である。正解である場合には、図３３（ｂ）に示す表示イメージ３３０２のように、正解のメッセージ表示をおこなって、報奨申し込み先へアクセスできるボタン３３０３を表示する。不正解の場合の画面は、ここでは図示していないが、不正解であるメッセージを表示して、報奨申し込み先へのアクセスボタン３３０３は表示されない。なお、不正解の場合は、対象となる健康データの情報をクリア（０歩）にしてもよいし、もう一度クイズにチャレンジさせるようにしてもよい。
【０１７２】
次に、報奨情報に申込前表示および申込前表示データが含まれるヘルスケアシステム１００にて実行される処理について、図３４を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１７３】
図３４は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、ステップＳ３０５において条件をクリアした場合は（ＹＥＳ側）、健康管理端末１０１は、報奨情報記憶部２０４に記憶している報奨情報から、申し込み前の表示が指定されているかどうか（申込前表示のフラグが０以外であるかどうか）をチェックする（Ｓ３０９）。申し込み前の表示がある場合は（Ｓ３０９のＹＥＳ側）、報奨情報に指定されている通りの申し込み前の表示をおこなった上で（Ｓ３１０）、報奨申し込みのためのボタンを表示する（Ｓ３１１）。ここで、ステップ３１０において、申し込み前の表示がクイズの場合は、クイズに正解したかどうかのチェックをおこなった上で、正解した場合にのみ、報奨申込（Ｓ３１１）へ進むことができる。
【０１７４】
以上のように、申込条件をクリアした後、申し込み前の表示を利用すれば、カバー画像を用いて報奨提供元の企業の宣伝や広告をおこなった際に、本当にユーザが宣伝や広告の内容を理解しているかどうかをチェックすることができる。これにより、報奨を提供する側は、報奨の申し込みをおこなうユーザの絞込みをおこなえるので、効果的な宣伝および広告をおこなうことができる。
【０１７５】
また上述のように、申込前表示は、報奨を申し込むにあたって報奨提供元の確認事項を表示させるものであることもできる。以下に、申込前表示がユーザへの確認表示の場合の例について説明する。
【０１７６】
図４２は、報奨情報の具体例を示す図である。上述のクイズの場合と異なる点は、「申込前表示」のフラグが「２：確認表示」になっている点と、申込前表示データの内容である。図４３は、申込前表示の表示イメージを示す図である。報奨申込の条件に達した場合、図４２に示す報奨情報に従って、図４３のような申込前表示をおこなう。ここでは、報奨申込時に報奨提供元サーバ１０４で把握可能な健康管理端末１０１に対応するメールアドレスを利用してもいいかどうかを確認するための確認表示をおこなっている。「同意して申し込み」を選択した場合は、健康管理端末１０１に対応するメールアドレスを報奨提供元サーバ１０４から今後発信される新商品情報および特典情報の配信に利用できることに同意したことを示す。「同意しないで申し込み」を選択した場合は、上記利用には同意せずに、報奨に申し込むことを示す。この報奨提供元サーバ１０４への送信データの区別であるが、図４２の報奨情報の申込前表示データにおいて、「<input type=button value=1>同意して申し込み</input>」という記載があるが、この「value=1」「value=2」を、報奨申し込み時に、報奨提供元サーバ１０４に対して送信する。図４２の報奨情報の例では、報奨申込先がメールアドレスになっているので、メールの本文に「value=1」ということを記載して、送信する。「value」データを受け取った報奨提供元サーバ１０４は、「value」データに従って、申し込み時に把握したメールアドレスを、以降に利用するかどうかを判断する。
【０１７７】
以上により、報奨提供元サーバにとっては、報奨申し込み時に収集した健康管理端末１０１の情報を、申込を受け付けた報奨の提供に利用するだけではなく、以降の情報配信等にも有効に活用することができる。
【０１７８】
〔実施の形態９〕
本発明に係るヘルスケアシステムの第９の実施形態について、図３５〜図３８に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１７９】
本実施の形態では、健康管理端末１０１から報奨の申し込みをおこなった後、報奨提供元サーバ１０４から健康管理端末１０１に対して、アンケートや送付先情報などの入力をさせている。
【０１８０】
図３５は、本実施の形態における報奨提供元サーバ１０４の概略構成を示すブロック図である。図３５に示すように、実施の形態１と異なり、報奨提供元サーバ１０４は、入力項目送受信部（入力項目情報送信手段、ユーザ入力情報受信手段）５０３、ユーザ情報蓄積部（ユーザ入力情報記憶手段）５０４およびアンケート情報蓄積部（ユーザ入力情報記憶手段）５０５をさらに備えて構成されている。
【０１８１】
入力項目送受信部５０３は、報奨申込受付部５０２において報奨の申し込みを受け付けた後、健康管理端末１０１に対して、アンケート情報や、個人情報の入力項目（入力項目情報）を送信する部分である。また、入力項目送受信部５０３は、健康管理端末１０１からそれらの入力された情報（ユーザ入力情報）を受信する部分でもある。
【０１８２】
アンケート情報は、報奨提供元の企業による自社のイメージや製品に対する感想などである。個人情報は、報奨の送付先としても利用するが、これ以降に報奨提供元企業が、自社のマーケティング活動に利用することができるように、同意を得た上で利用し得るものである。また、アンケート情報および個人情報を指定するフォーマットとしては、例えば、健康管理端末１０１でウェブページを表示できる場合は、ＨＴＭＬを利用する。なお、これに限らず、ＸＭＬ等で指定してもよい。
【０１８３】
ユーザ情報蓄積部５０４は、健康管理端末１０１より受信したユーザの個人情報を記憶する部分である。
【０１８４】
アンケート情報蓄積部５０５は、健康管理端末１０１より受信したアンケート情報を記憶する部分である。
【０１８５】
図３６は、本実施の形態における健康管理端末１０１の概略構成を示すブロック図である。図３６に示すように、実施の形態１と異なり、情報入力部（情報入力手段）２１１と、ユーザ情報記憶部２１０と、入力項目情報送受信部（入力項目情報受信手段、ユーザ入力情報送信手段）２１２とをさらに備えて構成されている。
【０１８６】
入力項目情報送受信部２１２は、報奨提供元サーバから送信されるアンケート情報や、個人情報の入力項目を受信する部分である。また、入力項目情報送受信部２１２は、受信した入力項目に基づいて、ユーザが入力した情報を報奨提供元サーバへ送信する部分でもある。
【０１８７】
情報入力部２１１は、報奨提供元サーバ１０４から受信した入力項目に基づいて、ユーザが情報を入力する部分である。具体的には、入力項目を液晶などの表示手段に表示し、キーボード、テンキーおよびタッチパネルなどを用いて、入力をおこなう。
【０１８８】
ユーザ情報記憶部２１０は、住所および氏名などのユーザの個人情報を記憶している部分である。このように、あらかじめ健康管理端末１０１において個人情報が記憶されている場合は、これら記憶している個人情報を、入力項目情報送受信部２１２を介して報奨提供元サーバ１０４に対して送信すればよい。
【０１８９】
図３７は、健康管理端末１０１における情報入力画面の一例を示す図である。図３７に示すように、アンケート情報と、報奨の送付先の情報と、今後報奨提供元サーバからのお知らせ情報を受信するかどうかのチェックとが表示されている。これらの入力項目は、ＨＴＭＬの形で、報奨提供元サーバ１０４から指定される項目である。
【０１９０】
次に、ユーザにアンケート情報、個人情報を入力させるヘルスケアシステム１００にて実行される処理について、図３８を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１９１】
図３８は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、報奨申し込みをした後、健康管理端末１０１と報奨提供元サーバ１０４との間で、ユーザ情報のやり取りをおこなっている。健康管理端末１０１において報奨申し込み部２０８が報奨の申し込みをおこなうと（Ｓ４０９）、報奨提供元サーバ１０４の報奨申込受付部５０２は、報奨の申し込みを受け付ける（Ｓ４１５）。すると、入力項目送受信部５０３は、健康管理端末１０１に対して入力させる入力項目を送信する（Ｓ４１７）。健康管理端末１０１の入力項目情報送受信部２１２は、報奨提供元サーバ１０４から送信された入力すべき項目を受信する（Ｓ４１０）。情報入力部２１１を介して指定された入力項目がユーザにより入力されると、入力項目情報送受信部２１２は、報奨提供元サーバ１０４に対して入力された情報を送信する（Ｓ４１１）。報奨提供元サーバ１０４の入力項目送受信部５０３は、健康管理端末１０１から送信された項目を受信し、ユーザ情報蓄積部５０４またはアンケート情報蓄積部５０５に記憶させる（Ｓ４１８）。
【０１９２】
以上のように、本実施の形態に係るヘルスケアシステム１００によれば、報奨提供元サーバ１０４は、アンケート情報や個人情報を収集できる。これらの情報はマーケティングまたはこれからの広告および宣伝活動に利用できるため、報奨を提供する企業にとっては、報奨を提供するメリットが高まる。また、報奨を申し込むユーザは健康情報を積極的に測定して条件をクリアしたユーザである。そのため、報奨を提供する企業は、ユーザのプロファイルをある程度特定することができるので、より希望に沿ったアンケート情報や個人情報を収集することができる。
【０１９３】
〔実施の形態１０〕
本発明に係るヘルスケアシステムの第１０の実施形態について、図３９〜図４１および図５９に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０１９４】
本実施の形態では、報奨のチャレンジの途中で、チャレンジする報奨を変更している。
【０１９５】
図５９は、本実施の形態における健康管理端末１０１の概略構成を示すブロック図である。図５９に示すように、実施の形態１と異なり、健康管理端末１０１は、報奨変更部（報奨情報変更手段）２２３をさらに備えて構成されている。報奨変更部２２３は、チャレンジする報奨を変更するために、報奨情報の一覧および新たにチャレンジする報奨の報奨情報をサービスサーバ１０３に要求し、受信した報奨情報に基づき、健康管理端末１０１において用いる報奨情報を変更するための部分である。
【０１９６】
図３９は、健康管理端末１０１における表示イメージを示す図である。実施の形態１と異なり、チャレンジしている報奨を変更する報奨変更ボタン３９０１が表示されている。報奨変更ボタンについては、健康管理端末１０１側で準備するものであってもよいし、報奨情報に「報奨変更可否」に関してフラグで指定がされており、変更可能な報奨の場合のみ、この報奨変更ボタン３９０１を表示するようにしてもよい。
【０１９７】
図４０は、健康管理端末１０１において、報奨変更をおこなう場合の報奨選択画面を示す図である。図１０に示す最初に報奨を選択する場合と異なる点は、今現在チャレンジしている報奨とは異なる報奨情報のみ、表示している点である。これについては、図８に示すように、報奨情報には、サービスサーバ１０３において報奨ＩＤが付与されるので、報奨ＩＤを用いて、現在チャレンジしている報奨と、それ以外の報奨とを識別できる。報奨変更部２２３は、サービスサーバ１０３から送信される図８に示すような報奨情報リストを受信すると、現在チャレンジしている報奨を、図８における「報奨ＩＤ＝ｈ０００１」であると識別し、それ以外の報奨を選択可能な状態で情報提示部２０９に表示させる。また、図４０に示すように、報奨変更部２２３は、今までチャレンジしてきた累積歩数を保持したまま変更することもできる。すなわち、図３９では、累積歩数が３３，０００歩である。この値は、健康管理端末１０１における健康データ記憶部２０２において記憶されている値である。この３３，０００歩を維持したまま、別の報奨にチャレンジできる。
【０１９８】
次に、報奨を変更する場合に、ヘルスケアシステム１００にて実行される処理について、図４１を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０１９９】
図４１は、本実施の形態におけるヘルスケアシステム１００の処理の流れを示すフローチャートである。実施の形態１と異なり、提示内容更新部２０７が表示内容を更新したあと（Ｓ５０８）、報奨変更部２２３は、報奨変更ボタンが押下されたかどうかをチェックする（Ｓ５０９）。報奨変更ボタンは、図３９に示すような報奨変更ボタン３９０１である。報奨変更ボタンが押下された場合（Ｓ５０９のＹＥＳ側）、報奨変更部２２３は、サービスサーバ１０３に対して、報奨の変更をするために報奨情報の一覧を要求する（Ｓ５１０）。報奨変更部２２３は、サービスサーバ１０３から送信される報奨情報の一覧データを受け付けると、変更可能な報奨情報を情報提示部２０９に表示させる。報奨変更部２２３は、ユーザからの選択を受け付けると、選択された報奨の報奨情報をサービスサーバ１０３に要求する（Ｓ５１１）。要求後に、報奨情報取得部２０３がサービスサーバ１０３から選択された報奨情報を取得すると、報奨変更部２２３は、対象となる報奨を変更する（Ｓ５１２）。報奨変更後、健康管理端末１０１は、引き続き、健康データの測定に戻る（Ｓ５０４）。
【０２００】
サービスサーバ１０３側においては、健康管理端末１０１から報奨変更の要求を受け付けると、報奨情報の一覧を送信する（Ｓ５１８）。健康管理端末１０１において選択された報奨情報の要求を受け付けると、その報奨情報を健康管理端末１０１に送信する（Ｓ５１９）。
【０２０１】
以上のように対象となる報奨を変更可能にすることで、ユーザは自分自身の状況に応じて、より応募しやすい報奨に変更したり、もっとがんばれそうな場合はより条件が高い魅力的な報奨にチャレンジしたりすることができる。そのため、自己の状態に応じたチャレンジができ、無理のない継続した健康維持および健康改善を図ることができる。
【０２０２】
〔実施の形態１１〕
本発明に係るヘルスケアシステムの第１１の実施形態について、図４４〜図４９に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０２０３】
これまでの実施の形態では、報奨情報として報奨獲得の対象となる健康データが１種類の場合について説明したが、本実施の形態では複数の健康データを利用して報奨を獲得する例について説明する。
【０２０４】
図４４は、本実施の形態における健康管理端末１０１の概略構成を示すブロック図である。前述の健康管理端末１０１と異なり、ポイント換算部２１３が追加されている。
【０２０５】
ポイント換算部２１３は、後述する報奨情報に指定されている換算ルールに基づいて、健康機器１０２の測定部６０１により測定した健康データを、ポイントに換算する部分である。この換算したポイントに基づき条件チェック部２０６において単位条件情報および条件情報をクリアしているかどうかの判定をおこなう。
【０２０６】
図４５は、本実施の形態における報奨情報の例を示す図である。図４５に示すように、実施の形態１における報奨情報と異なり、「換算ルール」が追加されている。また、単位条件および申込条件が「ポイント」で指定されている。前述の実施の形態では、１種類の健康データ（歩数ならば１０００歩）で申込条件および単位条件が指定されていた。これに対し、本実施の形態における報奨情報では、健康データを「ポイント」という共通の単位に換算して、複数の健康データを組み合わせて利用できるようにしている。換算ルールでは、各健康データをポイントに換算するルールを指定している。図４５に示す報奨情報の例では、１ポイント獲得するためには、「健康データ＝歩数の場合：累積歩数＝１０，０００歩」「健康データ＝体重の場合：１週間平均での体重減０．２ｋｇ」「健康データ＝血圧の場合：記録回数２回」「健康データ＝食事の場合：目標摂取カロリー値から±１００ｋｃａｌ以内の日が２日」といったように、４種類の健康データを利用してポイントを獲得できる。また、これら換算したポイントの総計を用いて、単位条件５ポイント、申込条件１００ポイントをクリアしたかどうかの判定をおこなう。
【０２０７】
図４６は、健康管理端末１０１の健康データ記憶部２０２に格納されている報奨情報の例を示す図である。図４６に示すように、４種類の健康データの測定データが格納されている。これらの健康データは、健康データ取得部２０１によって健康データ供給部６０２から有線／無線で収集したデータ（体重、血圧）、健康管理端末１０１に内蔵されているセンサ（測定部６０１）によって測定したデータ（歩数）である。また、付加的情報として、健康管理端末１０１のメニュー入力部２１７により入力された食事の摂取カロリーデータを含んでもよい。
【０２０８】
次に、健康データをポイントに換算する場合に、ヘルスケアシステム１００にて実行される処理について、図４７を参照して説明する。なお、ここでは、実施の形態１におけるヘルスケアシステム１００における処理と異なる点についてのみ説明する。それ以外の処理については、実施の形態１における場合と同様である。
【０２０９】
実施の形態１と異なる点は、（ｉ）健康データを測定した後（Ｓ６０４）、対象健康データのカウントをおこなう際に（Ｓ６０５、実施の形態１のＳ１０５に対応）ポイント換算に必要な健康データを集計する処理をおこなう点、および（ｉｉ）それら集計された健康データに基づいてポイントをカウントする処理（Ｓ６０６）が追加されている点である。
【０２１０】
健康データを測定（Ｓ６０４）した後、対象健康データカウント部２０５は、報奨情報に含まれる換算ルールを元に、各ポイント換算用の健康データを集計する。次に、これら集計した対象データに基づいて、ポイント換算部２１３が、ポイントをカウントする（Ｓ６０６）。条件チェック部２０６は、ポイント換算部がカウントしたポイントに基づいて、申込条件および単位条件をクリアしているかどうかのチェックをおこなう（Ｓ６０７，Ｓ６０８）。カウントしたポイントが申込条件および単位条件を満たしている場合に、条件チェック部２０６は、健康データが各条件を満たしていると判定する（Ｓ６０７，Ｓ６０８）。
【０２１１】
以下に、ポイント換算に必要な健康データの集計、およびポイントの換算について説明する。
【０２１２】
まず、対象健康データカウント部２０５は、報奨情報に含まれる換算ルールを参照して、図４６に示す健康データ記憶部に格納されている健康データから、必要なデータを抽出する。例えば、報奨チャレンジを開始した日が「２００８／７／１７」で、集計する日が「２００８／７／１９」であった場合には、歩数データについては「２００８／７／１７〜１９」の３日間で「２８，８７４歩」である。体重データについては、集計対象期間の３日間では１週間に満たしていないので、対象データは０である。血圧データについては、「２００８／７／１７〜１９」では２回（７／１７，７／１９）記録されている。食事データについては、図４５に示す換算ルールでは「目標摂取カロリー値から±１００ｋｃａｌ以内を達成した日が２日＝１ポイント」である。ここで、目標摂取カロリーについては、年齢、性別、身体活動レベル（低い、ふつう、高い）から判断される推奨摂取カロリーを目標摂取カロリー値として利用する。この推奨摂取カロリーについては、例えば厚生労働省から発表されている一般的な推奨値を用いるなどする。例えば、ユーザの年齢、性別、身体活動レベルに基づいた目標摂取カロリーが「１７００ｋｃａｌ」とする。一方で、図４６に示す健康データを参照して、「２００８／７／１７〜１９」の間で、７／１７の摂取カロリーは１，７３４ｋｃａｌであるので、ポイント換算の「１７００ｋｃａｌ以内」を満たす。７／１８については２，１００ｋｃａｌであるので、「１７００ｋｃａｌ以内」を満たさない。７／１９は食事の摂取カロリーの記録がない。従って、食事データについては、「１７００ｋｃａｌ以内」を満たす日は１日である。以上のようにして、ポイント換算に必要なデータを抽出し、集計する。
【０２１３】
次に、ポイント換算部２１３は、対象健康データカウント部２０５が集計したこれら対象データに基づいて、ポイントをカウントする。図４５に示す報奨情報に含まれる換算ルールを参照して、歩数は「累積歩数１０，０００歩＝１ポイント」であるので、歩数については２ポイント（２８，８７４歩÷１０，０００）獲得したことになる。体重データについては、対象データは０であるので、０ポイントである。血圧データについては、この換算ルールでは「記録回数２回＝１ポイント」である。対象データは２回（７／１７，７／１９）なので、１ポイント獲得である。食事データについては、「１７００ｋｃａｌ以内」を満たす日が１日なので、ポイント換算ルールである「目標摂取カロリー値から±１００ｋｃａｌ以内を達成した日が２日＝１ポイント」によれば、０ポイントである。従って、「２００８／７／１７〜１９」の間で、獲得したポイント数は、３ポイント（２＋０＋１＋０）となる。
【０２１４】
条件チェック部２０６は、この集計結果である３ポイントに基づいて、申込条件および単位条件をクリアしているかどうかのチェックをおこなう。ここで、図４５を参照して、単位条件＝５ポイント、申込条件１００ポイントであるので、いずれもクリアしていないことになる。したがって、引き続き健康データ測定（Ｓ６０４）に戻る。
【０２１５】
一方、集計する日が「２００８／７／２３」であった場合、図４６に示す健康データを参照して対象データをカウントすると、歩数データの場合は、累計歩数＝６５，１０７歩である。体重データの場合は、「２００８／７／１７〜２３」の７日間の平均は「７５．３ｋｇ」となる。従って、開始日のデータである「２００８／７／１７＝７５．５ｋｇ」の差をとると「０．２ｋｇ」となる。血圧データの場合は、「２００８／７／１７〜２３」の間の記録日数は「５日間」となる。食事データの場合は、「１７００ｋｃａｌ±１００ｋｃａｌ」となる日は「２日間」（７／１７，７／２３）となる。
【０２１６】
次に、これら集計した対象データに基づいて、２００８／７／２３時点でのポイントの換算をおこなうと、歩数データの場合は「６ポイント」、体重データの場合は「１ポイント」、血圧データの場合は「２ポイント」、食事データについては「１ポイント」となり、合計すると獲得ポイントは「１０ポイント」（６＋１＋２＋１）となる。
【０２１７】
条件チェック部２０６は、この１０ポイントに基づいて、申込条件および単位条件をクリアしているかどうかのチェックをおこなう。図４５に示す報奨情報を参照して、申込条件である１００ポイントはクリアしていないが、単位条件である５ポイントはクリアしている。従って、提示内容更新部は、表示内容の更新をおこなう。ここでは、実施の形態１と同様に、報奨画像（Gohoubi.jpg）の上をカバー画像（Cover.jpg）が覆って表示されており、カバー画像を分割して、単位条件をクリアするごとに１ピース非表示になる。また、カバー画像の分割数は、申込条件÷単位条件、すなわち、２０個（１００÷５）に分割する。また、２００８／７／２３時点においては、１０ポイント獲得しているので、カバー画像を２ピース非表示にできる。図４８は、ポイントを１０ポイント獲得した時点での健康管理端末１０１の表示イメージを示す図である。図４８に示すように、１０ポイント獲得時点では、２ピースを非表示にしている。
【０２１８】
図４９は、申込条件である１００ポイントを獲得した場合の健康管理端末１０１の表示イメージを示す図である。この場合は、実施の形態１と同様に、図４５に示す報奨情報に基づいて、報奨申込先へのボタン１３０１が表示される。
【０２１９】
以上のように、報奨情報において対象となる健康データを複数とすることで、例えば運動が苦手で歩数でのポイントは獲得できないけれども、血圧や食事はきちんと測定して目標を守っている人は、ポイントを獲得でき、同じ報奨にチャレンジすることができる。したがって、ユーザが申し込みできる報奨の幅が広がり、ユーザのモチベーションが高まる。
【０２２０】
〔実施の形態１２〕
本発明に係るヘルスケアシステムの第１２の実施形態について、図５０〜図５５に基づいて説明すれば以下の通りである。なお、説明の便宜上、前述の実施の形態で用いたものと同じ機能を有する部材には同じ参照符号を付して、その説明を省略する。
【０２２１】
これまでの実施の形態では、健康管理端末１０１で、報奨情報の単位条件情報および申込条件情報をチェックして、表示内容を変更するという例を示してきた。本実施の形態では、健康データの測定および取得は健康管理端末でおこなうが、これらの測定および取得した健康データをサービスサーバに送信し、サービスサーバ側で単位条件情報および申込条件情報のチェックをおこなって、表示更新や報奨申込をおこなうための表示データ（素材情報、申込許可情報）を健康管理端末へ送信するという例を示す。本実施の形態に示すヘルスケアシステム１００’は、健康管理端末１０１’、健康機器１０２、サービスサーバ１０３’および報奨提供元サーバ１０４を含んで構成されている。
【０２２２】
（健康管理端末およびサービスサーバの構成）
図５０は、本実施の形態における健康管理端末１０１’の概略構成を示すブロック図である。図５０に示すように、実施の形態１と異なる点としては、本実施の形態では単位条件および申込条件のチェックをサービスサーバ側でおこなうため、対象健康データカウント部、条件チェック部および提示内容更新部は、後述するサービスサーバ１０３’にてその機能を担うので必要ない。また、取得した健康データは、健康データ送信部２１８を通してサービスサーバ１０３’に送信され、サービスサーバ１０３’において記憶される。そのため、健康管理端末１０１’に健康データ記憶部は含まれていない。一方で、健康管理端末１０１’は、健康データ送信部２１８、受信部（報奨情報受信手段、提示態様受信手段）２１４、表示部（素材情報提示手段）２１５、および選択部２１６をさらに含んで構成されている。
【０２２３】
健康データ送信部２１８は、取得した健康データをサービスサーバ１０３’に送信する部分である。
【０２２４】
受信部２１４は、サービスサーバ１０３’において単位条件情報および申込条件情報のチェックに基づいて更新された報奨の表示データ、および報奨情報を選択する際の図１０に示すような一覧を選択するための表示データを受信する部分である。
【０２２５】
表示部２１５は、受信部２１４で受信した表示データを表示する部分である。
【０２２６】
選択部２１６は、報奨の申し込みおよび報奨情報の選択をおこなう部分である。
【０２２７】
図５１は、サービスサーバ１０３’の概略構成を示すブロック図である。図５１に示すように、実施の形態１と異なる点としては、報奨選択受付部４０４、健康データ受信部（健康情報受付手段）４０５、ユーザデータ記憶部４０６、対象健康データカウント部（判定手段）４０７、条件チェック部（判定手段）４０８、表示データ作成部（提示態様情報生成手段）４０９、および表示データ送信部（申込許可送信手段、提示態様送信手段）４１０をさらに含んで構成されている点である。
【０２２８】
報奨選択受付部４０４は、健康管理端末１０１’に対して報奨情報の一覧を送信する。また、チャレンジする報奨情報が健康管理端末１０１’において選択された場合、その選択結果のデータを受信し、受け付ける。選択結果は、健康管理端末１０１’に対して報奨情報の一覧を送信する際にサービスサーバ１０３’で付与されたそれぞれの報奨ＩＤのデータとして受信する。
【０２２９】
健康データ受信部４０５は、健康管理端末１０１’が取得し、サービスサーバ１０３’に対して送信された健康データを受信する部分である。
【０２３０】
ユーザデータ記憶部４０６は、報奨選択受付部４０４で受信した選択結果、および健康データ受信部４０５で受信した健康データを記憶しておく部分である。
【０２３１】
対象健康データカウント部４０７は、ユーザデータ記憶部４０６で記憶している健康データに基づいて、健康管理端末１０１’において選択された、報奨を獲得するための条件の対象となる健康データを集計する部分である。この際、報奨情報は、報奨情報蓄積部４０２に記憶されている報奨情報を参照する。
【０２３２】
条件チェック部４０８は、対象健康データカウント部４０７が集計した健康データに基づいて、報奨情報の単位条件情報および申込条件情報をクリアしているか否かを判定する部分である。条件チェック部４０８は、報奨情報蓄積部４０２に記憶している報奨情報にて指定されている２つの条件：（１）報奨獲得の条件、および（２）条件未達の段階においてユーザへ提示内容を変更するための単位の条件を読み込む。そして、対象健康データカウント部４０７が集計した健康データが、上記（１）および（２）の条件をクリアしているかどうかを判定する。
【０２３３】
表示データ作成部４０９は、条件チェック部４０８において判定された判定結果に基づいて、健康データに応じて健康管理端末１０１’における表示を更新するための表示データ、および報奨申し込みをおこなうためのボタンを備えた表示データを作成する部分である。この作成データの具体例としては、健康管理端末１０１’において表示可能なデータであればよく、ＨＴＭＬ、ＸＭＬなどが挙げられる。また、それらに必要な画像データ（ＪＰＥＧファイルなど）も一緒に加工される。
【０２３４】
表示データ送信部４１０は、表示データ作成部４０９で作成された表示データを健康管理端末１０１’に対して送信する部分である。健康管理端末１０１’では、サービスサーバ１０３’から受信した表示データを、健康管理端末１０１’における受信部２１４で受信し、表示部２１５で表示する。
【０２３５】
報奨情報としては、図７に示すような報奨情報を用いることができる。この報奨情報は、報奨提供元サーバ１０４から提供されたデータである。
【０２３６】
図５２は、サービスサーバ１０３’における報奨情報蓄積部４０２において蓄積される報奨情報の例を示す図である。図５２に示すように、報奨情報蓄積部４０２では、報奨提供元サーバ１０４から提供された報奨情報を順次蓄積していく。また各報奨情報を識別するために、報奨ＩＤを付与して記憶しておく。
【０２３７】
図５３は、サービスサーバ１０３’におけるユーザデータ記憶部４０６に記憶されるデータの具体例を示す図である。ここでは、各データを、報奨選択テーブルおよび健康データテーブルにして、２つのテーブルを記憶している。図５３（ａ）は報奨選択テーブルを表し、図５３（ｂ）は健康データテーブルを表している。
【０２３８】
報奨選択テーブルは、健康管理端末１０１’において選択された報奨情報の選択結果、および報奨にチャレンジした履歴情報を記憶しておく。「端末ＩＤ」は、健康管理端末１０１’を一意に特定するためのＩＤである。「選択報奨ＩＤ」は、健康管理端末１０１’において選択された報奨情報の報奨ＩＤを記憶しておく。これは、報奨選択受付部４０４において健康管理端末１０１’より受信した報奨ＩＤに対応する。「報奨開始日」は、報奨が選択された日を記憶しておく。「報奨終了日」は、健康管理端末１０１’において申込条件情報をクリアした日を記憶しておく。「状態」は、報奨へのチャレンジの状態を示す。本実施の形態では、「１」は申込条件情報もクリアして報奨チャレンジが完了した状態、「０」はチャレンジする報奨を途中で変更するなどして報奨チャレンジを途中でとめた状態、そして「２」は報奨へチャレンジ中の状態を示している。従って、「端末ＩＤ＝Ｕ１０００１」の健康管理端末１０１’は、現在、「状態＝２」となっている「報奨ＩＤ＝ｈ０００１」の報奨にチャレンジ中ということが分かる。
【０２３９】
健康データテーブルは、健康管理端末１０１’より受信した健康データを記憶している。「端末ＩＤ」は、健康データを取得した健康管理端末１０１’を一意に特定するためのＩＤである。「日付」、「歩数」、「体重」、「血圧」および「食事（摂取カロリー）」は、健康管理端末１０１’より受信した健康データに基づいて、日付ごとにそれぞれの健康データを記憶しておく。なお、本実施の形態では、４種類の健康データのみ示しているが、これに限定されるものではない。
【０２４０】
（ヘルスケアシステムの処理）
次に、以上のように構成されたヘルスケアシステム１００’にて実行される処理について、図５４を参照して以下に説明する。なお、本実施の形態では、実施の形態１と同様に、健康管理端末１０１’に歩数をカウントできるセンサが内蔵されており、健康機器１０２と健康管理端末１０１’とが一体になっている健康管理端末１０１’を用いる場合について説明するが、これに限定されるものではない。
【０２４１】
図５４は、ヘルスケアシステム１００’の処理の流れを示すフローチャートである。図５４を参照しながら、ステップＳ７００〜Ｓ７０９、ステップＳ７１０〜Ｓ７１９、ステップＳ７２０〜Ｓ７２１について説明すれば以下の通りである。
【０２４２】
まず、報奨提供元サーバ１０４の提供元報奨情報送信部５０１が、報奨情報をサービスサーバ１０３’に対して送信する（Ｓ７２０）。
【０２４３】
サービスサーバ１０３’の報奨情報受付部４０１は、提供元報奨情報送信部５０１から送信された報奨情報を受信し、受信した報奨情報を報奨情報蓄積部４０２に記憶する（Ｓ７１０）。サービスサーバ１０３’は、報奨情報の一覧を健康管理端末１０１’へ送信する（Ｓ７１１）。健康管理端末１０１’では、それら受信した報奨情報の一覧を表示して、ユーザにより選択された報奨情報の報奨ＩＤをサービスサーバ１０３へ送信する（Ｓ７０２）。サービスサーバ１０３’の報奨選択受付部４０４は、健康管理端末１０１’で選択され、送信された報奨情報を受信し、ユーザデータ記憶部４０６に記憶しておく（７１２）。報奨情報が選択されたことにより、健康管理端末１０１’における報奨へのチャレンジが開始されたことになる。次いで、表示データ作成部４０９は、報奨情報に指定されているカバー画像および報奨画像に基づいて、健康管理端末１０１’に対して表示データを送信する。健康管理端末１０１’の受信部２１４は、表示データを受信する。表示部２１５は、受信した表示データに基づいて表示をおこなう（Ｓ７０３）。図５５（ａ）は、健康管理端末１０１’においてチャレンジ開始時に表示される画面を示す図である。当然、対象となる健康データ（累積歩数）は無いので「累積歩数＝０歩」となっている。
【０２４４】
次に、健康管理端末１０１’において、健康データの測定が開始された場合は（Ｓ７０４のＹＥＳ側）、健康データ取得部は、測定された健康データを取得する（Ｓ７０５）。次いで、健康データ送信部２１８は、取得された健康データをサービスサーバ１０３’に対して送信する（Ｓ７０６）。
【０２４５】
サービスサーバ１０３’の健康データ受信部４０５は、健康管理端末１０１’から健康データを受信すると（Ｓ７１４のＹＥＳ側）、受信した健康データをユーザデータ記憶部４０６に健康データテーブルとして記憶しておく。対象健康データカウント部４０７は、ユーザデータ記憶部４０６の報奨選択テーブルの選択報奨ＩＤに基づいて、現在チャレンジ中の報奨情報を報奨情報蓄積部４０２より参照して、対象となる健康データを集計する（Ｓ７１５）。
【０２４６】
図５３に示されている報奨選択テーブルを参照すると、現在チャレンジ中の報奨は、「報奨ＩＤ＝ｈ０００１」の報奨である。また、図５２に示されている報奨情報蓄積部４０２に蓄積されている報奨情報を参照すると、「報奨ＩＤ＝ｈ０００１」の報奨における対象となる健康データの条件は、「単位条件情報＝累積歩数１０，０００歩」および「申込条件情報＝累積歩数１２０，０００歩」である。したがって、対象データとしては累積歩数を集計する。対象データの集計については、ユーザデータ記憶部４０６の健康データテーブルを参照する。報奨選択テーブルでは、報奨開始日が「２００８／７／１７」なので、報奨開始日〜現在までの歩数を、累積歩数として集計する。ここで、現在（集計する日）を「２００８／７／１９」とすると、対象となる健康データ（累積歩数）は「２８，８７４歩」となる。
【０２４７】
次に、対象となる健康データに基づいて、報奨情報の単位条件および申込条件をクリアしているかどうかの判定をおこなう。まず、条件チェック部４０８は、申込条件と集計した対象健康データとを比較して、対象健康データが申込条件をクリアしているか否かの判定をおこなう（Ｓ７１６）。上述のように報奨情報蓄積部４０２を参照すると、「報奨ＩＤ＝ｈ０００１」の単位条件情報は「累積歩数１０，０００歩」であり、申込条件情報は「累積歩数１２０，０００歩」である。この場合、条件チェック部４０８は、申込条件情報「累積歩数１２０，０００歩」と集計した対象健康データ「２８，８７４歩」とを比較して、申込条件情報をクリアしていないと判定する（Ｓ７１６のＮＯ側）。申込条件をクリアしていないと判定すると、条件チェック部４０８は、単位条件と集計した対象健康データとを比較して、単位条件をクリアしているか否かを判定する（Ｓ７１７）。ここで、単位条件は「累積歩数１０，０００歩」であるため、条件チェック部４０８は、単位条件「累積歩数１０，０００歩」と集計した対象健康データ「２８，８７４」とを比較して、単位条件をクリアしていると判定する（Ｓ７１７のＹＥＳ側）。単位条件をクリアしている場合、表示データ作成部４０９は、報奨情報に指定されているカバー画像および報奨画像を利用して、健康管理端末１０１’に表示させる表示用データを作成する（Ｓ７１８）。表示データ送信部４１０は、表示データ作成部４０９が作成した表示データを、健康管理端末１０１’に送信する（Ｓ７１８）。
【０２４８】
ここで表示データを更新する具体例については、実施の形態１に示す健康管理端末１０１の提示内容更新部２０７と同様であり、カバー画像を１２個の領域に分割して、「単位条件＝累積歩数１０，０００歩」をクリアするごとに、分割したカバー画像の領域を１つ１つ非表示にしていく。対象健康データカウント部４０７による集計の結果、現在の累積歩数は「２８，８７４歩」であるため、分割したカバー画像の２つの領域を非表示にできる。サービスサーバ１０３’の表示データ作成部４０９’は、このような表示データを、ＨＴＭＬおよびＸＭＬなど、健康管理端末１０１’で表示可能な形式で作成する。
【０２４９】
健康管理端末１０１’では、受信した表示データを表示部２１５に表示する（Ｓ７０７）。図５５（ｂ）は、健康管理端末１０１’の表示部２１５における表示例を示す図である。累積歩数＝２８，８７４歩に基づいて、１２個に分割されたカバー画像の２つの領域が非表示となっている。そして、カバー画像が非表示となっている部分に、報奨画像が表示されている。
【０２５０】
ユーザが生活習慣改善のための行動をとると、健康管理端末１０１’において取得される累積歩数が増加する。これにより集計した対象健康データが、申込条件情報「累積歩数１２０，０００歩」の条件を満たしている場合には、条件チェック部４０８は、上記のステップＳ７１６において、集計した対象健康データが申込条件情報をクリアしていると判定する（Ｓ７１６のＹＥＳ側）。すると、サービスサーバ１０３’の表示データ作成部４０９は、報奨申し込み用の表示データを作成する（Ｓ７１９）。
【０２５１】
報奨申し込み用の表示データは、健康管理端末１０１’から報奨情報に指定されている報奨申し込み先（ＵＲＬ、メールアドレス、など）にアクセスすることを可能とする表示データである。具体的には、報奨提供元サーバ１０４にアクセスするようにボタンが表示される。
【０２５２】
健康管理端末１０１’の受信部２１４が報奨申し込み用の表示データをサービスサーバ１０３’から受信すると、健康管理端末１０１’は表示データを表示部２１５に表示する（Ｓ７０７）。このとき表示部２１５には、図１３に示すような画像が表示される。表示部２１５には、ユーザが報奨を申し込むことができるように、報奨情報に指定されている報奨申し込み先へアクセスするためのボタン１３０１が表示される。健康管理端末１０１’において、このボタンが操作される（押下げされる）と、（Ｓ７０８のＹＥＳ側）、報奨申し込み部２０８は、報奨提供元サーバ１０４に対して報奨の申し込みをおこなう（Ｓ７０９）。
【０２５３】
報奨提供元サーバ１０４では、報奨申込受付部５０２が、健康管理端末１０１’からの報奨の申し込みを受け付ける（Ｓ７２１）。
【０２５４】
以上のように、本実施の形態では、報奨へのチャレンジをおこなう際に、健康管理端末１０１’において、報奨情報に指定されている単位条件および申込条件をクリアしているかどうかの判定をおこなうのではなく、サービスサーバ１０３’において判定をおこなう。これにより、健康管理端末１０１’側では、対象健康データカウント部、条件チェック部、提示内容更新部などの構成を必要としない。したがって、健康管理端末１０１’は、携帯電話や、さらには小さな表示部およびデータ送受信部を備えた機器（例えば、表示部およびデータ送信機能付きの歩数計）といったように、サーバと比べて処理能力が低いものを利用し得る。健康データのカウントや表示用のデータ生成などといった計算処理を必要とするものはサービスサーバ１０３’で作成し、健康管理端末１０１’では、それら作成された表示データを受信し、表示するだけにしておけばよい。
【０２５５】
ここで、本実施の形態におけるさらなる実施態様について説明する。本実施の形態では、サービスサーバ１０３’において、図５３に示すような報奨選択テーブルにより、各健康管理端末１０１’が報奨のチャレンジを最後まで完了したかどうかのステータスが把握できる。したがって、その報奨情報のステータスに基づいて、ユーザが次にチャレンジする報奨を提案することが可能になる。
【０２５６】
図５６は、健康管理端末１０１における表示例を示す図である。これは、ユーザが報奨にチャレンジする前、ステップＳ７１１においてサービスサーバ１０３’から送信される報奨情報の一覧を、ステップＳ７０１において健康管理端末１０１’の表示部２１５が表示しているときの表示例である。サービスサーバ１０３’では、ユーザデータ記憶部４０６において格納されている報奨選択テーブルを参照して、過去に報奨チャレンジが完了した報奨情報に基づいて、同じ報奨提供元から報奨情報が登録された場合には、新しい報奨情報を健康管理端末１０１’に通知する。
【０２５７】
具体的には、図５３に示す報奨選択テーブルを参照する場合、サービスサーバ１０３’の情報検索部（不図示）４１１が、報奨選択テーブルにおける「端末ＩＤ＝Ｕ１０００１」の健康管理端末１０１’の報奨選択テーブルを参照して、「状態＝１」になっている報奨ＩＤを参照する。図５３に示す報奨選択テーブルでは、報奨ＩＤ＝ｒ１５３４，ｈ３５３４の報奨チャレンジが完了している。また、情報検索部４１１は、報奨情報蓄積部４０２に格納されている報奨情報を参照し、報奨ＩＤ＝ｒ１５３４の報奨が「Ｓｋｙ健康食品」から提供されていることを認識する。そこで情報検索部４１１は、報奨情報蓄積部４０２に記憶されている報奨情報の中から、「Ｓｋｙ健康食品」から提供されている報奨情報を検索する。ここで、「Ｓｋｙ健康食品」からは、報奨ＩＤ＝ｒ１５３５の報奨が登録されている。報奨選択テーブルを参照すると、この報奨は報奨選択テーブルに登録されていないため、端末ＩＤ＝Ｕ１０００１の健康管理端末１０１’は、まだこの報奨にはチャレンジしていないことが分かる。この場合、情報検索部４１１は、新しい報奨情報が登録されたことを、表示データ送信部４１０を介して健康管理端末１０１’に通知する。健康管理端末１０１’では、図５６に示すように、報奨情報の一覧を表示するときに、新しい報奨情報が登録されたことが通知される。
【０２５８】
以上のように、本実施の形態によれば、サービスサーバ１０３’のユーザデータ記憶部４０６には、健康管理端末１０１’による報奨へのチャレンジが完了したのかの履歴情報が記憶されているため、報奨提供元サーバ１０４から報奨が提供された場合に、過去の報奨チャレンジの履歴に基づいて、ユーザが過去に完了した報奨情報に関連する新着の情報を健康管理端末１０１’に通知できる。これにより、健康管理端末１０１’を利用するユーザにとっては、自身が過去に申込条件をクリアして報奨をもらった実績がある報奨情報と関連のある新着情報を通知を受けられる。そのため、ユーザ自身も過去の実績に基づいてチャレンジしやすく、新たな意欲がわき、報奨を獲得するためのモチベーションを高めながら継続して健康管理をおこなうことができる。また、サービスサーバ１０３’では健康管理端末１０１’の報奨情報の履歴情報を記憶しているため、健康管理端末１０１’への情報の通知をおこなうことができる。これにより報奨にチャレンジする健康管理端末１０１’が増えて、サービスとして盛り上げることができる。また、サービスサーバ１０３’では、報奨提供元サーバ１０４に対しても、健康管理端末１０１’における報奨チャレンジの情報を知らせることができる。従って、健康管理端末１０１’が報奨チャレンジをしている状況、興味等を知らせることができるので、報奨提供元サーバ１０４を管理する報奨提供元は、報奨情報の企画・作成にあたっての参考情報を取得することができる。これによりユーザが興味を引く報奨情報を、報奨提供元サーバ１０４を介してサービスサーバ１０３’に提供でき、その結果、魅力的な報奨情報がサービスサーバ１０３’に集まることになる。よって、健康管理端末１０１’を利用するユーザにとっても、モチベーション高く健康管理をおこなうことができる。
【０２５９】
なお、モチベーションを高めるために、健康データをポイントに換算し、たまったポイント数に応じて、金券および商品といった報奨と交換するインセンティブサービスにおいて、以下の（１）〜（３）のような課題が生じ得る。（１）報奨の原資がサービスを利用するユーザが納める利用料である場合、利用するユーザにとっては、利用料を支払ってまでも健康データを測定してがんばって報奨を得るのは、対価となる報奨が魅力的かつ高付加価値である場合のみである。それ以外の場合には、健康データの測定が続かない。また、インセンティブサービスの報奨の種類が限られる場合は（例えば、商品券１種類のみ）、継続しても毎回同じ報奨になるため、モチベーションが高まらない。（２）報奨の原資が、ユーザが所属する健康保健組合が納める利用料である場合、ユーザが利用料を支払う前述の場合の課題と同様に、報奨の内容や種類がモチベーションとなっているため、種類や内容が豊富でない限り、組合員自身が利用料無料であってもモチベーションは高まらない。（３）報奨の原資が、インセンティブサービスへの協賛企業からの利用料である場合、協賛企業にとっては、広告料を支払うからには、効果的に広告情報を提示したいが、広告の提示タイミングや、どのようなユーザに対して広告を提示するかについては、インセンティブサービス側がおこなうため、協賛企業側は広告情報となるデータのみ提供する。また、上述の通り、ユーザおよび健康保健組合が、サービス利用に消極的であれば、効果的な広告手段とはならない。さらに、協賛企業にとっては、有効な広告および宣伝ができない（費用に対する効果が少ない）となれば、インセンティブサービスへの利用料も少なくなるため、結果として報奨の種類が少なかったり、報奨の内容が画一的であったりといった、悪循環へとつながる。
【０２６０】
本発明のヘルスケアシステムによれば、上記の課題を解決し、モチベーション高く健康管理をおこなうことができる。
【０２６１】
（付記事項）
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【０２６２】
例えば、健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４の各ブロックは、ハードウェアロジックによって構成してもよいし、次のようにＣＰＵを用いてソフトウェアによって実現してもよい。
【０２６３】
すなわち、健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（central processing unit）、上記プログラムを格納したＲＯＭ（read only memory）、上記プログラムを展開するＲＡＭ（random access memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０２６４】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。
【０２６５】
また、健康管理端末１０１および１０１’、サービスサーバ１０３および１０３’、ならびに報奨提供元サーバ１０４を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（virtual private network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【０２６６】
なお、本発明のヘルスケアシステムは、以下の点を特徴点としていると換言することも可能である。すなわち、健康管理端末と、サービスサーバと、報奨提供元サーバとからなるヘルスケアシステムであって、健康管理端末は、報奨の申し込みに必要な健康データの条件となる条件情報と、提示用の素材情報と、上記報奨提供元サーバへのアクセス先であるアクセス先情報とを含む報奨情報を、上記サービスサーバより取得する報奨情報受信手段と、健康データを取得する健康データ取得手段と、上記取得した健康データに基づいて、上記素材情報の提示態様を変更する提示更新手段と、上記健康データが、上記条件情報に達した場合に、上記アクセス先情報に基づいて、上記報奨提供元サーバへアクセスする報奨申込手段と、を含み、上記サービスサーバは、上記報奨提供元サーバから上記報奨情報を受信する報奨情報受付手段と、上記健康管理端末に対して、上記報奨情報を送信する報奨情報送信手段と、を含み、上記報奨提供元サーバは、上記サービスサーバに対して、上記報奨情報を登録する報奨情報登録手段と、上記健康管理端末からの報奨申し込みを受け付ける報奨受付手段と、備えることを特徴としているとも換言することができる。
【産業上の利用可能性】
【０２６７】
本発明は、健康改善の取り組みをおこなうユーザをサポートするためのシステムに好適に適用することができる。
【図面の簡単な説明】
【０２６８】
【図１】本発明の一実施形態におけるヘルスケアシステムに用いられる健康管理端末の構成を示すブロック図である。
【図２】本発明の一実施形態におけるヘルスケアシステムの概略構成を示す図である。
【図３】本発明の一実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図４】本発明の一実施形態におけるヘルスケアシステムに用いられるサービスサーバの構成を示すブロック図である。
【図５】本発明の一実施形態におけるヘルスケアシステムに用いられる報奨提供元サーバの構成を示すブロック図である。
【図６】本発明の一実施形態におけるヘルスケアシステムに用いられる健康機器の構成を示すブロック図である。
【図７】本発明の一実施形態における報奨情報の構成を示す図である。
【図８】本発明の一実施形態における報奨情報蓄積部に格納される報奨情報を示す図である。
【図９】本発明の一実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図１０】本発明の一実施形態における健康管理端末の情報提示部での表示例を示す図である。
【図１１】本発明の一実施形態における健康管理端末に表示される画像であり、（ａ）はカバー画像を表し、（ｂ）は報奨画像を表している。
【図１２】本発明の一実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図１３】本発明の一実施形態の条件クリア後における健康管理端末での表示例を示す図である。
【図１４】本発明の別の実施形態における報奨情報の構成を示す図である。
【図１５】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図１６】本発明の別の実施形態における報奨情報の構成を示す図である。
【図１７】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図であり、（ａ）は動画を再生させる前の表示画面を表し、（ｂ）は動画を再生している途中の表示画面を表す。
【図１８】本発明の別の実施形態における報奨情報の構成を示す図である。
【図１９】本発明の別の実施形態における健康管理端末に表示される複数のカバー画像のうちの一部を示す図である。
【図２０】本発明の別の実施形態における健康管理端末の表示画面を表す図であり、（ａ）は条件未達段階における表示画面を表し、（ｂ）は条件達成後における表示画面を表している。
【図２１】本発明の別の実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図２２】本発明の別の実施形態における報奨情報の構成を示す図である。
【図２３】本発明の別の実施形態における健康管理端末に表示されるカバー画像である。
【図２４】本発明の別の実施形態における健康管理端末に表示される報奨画像である。
【図２５】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図２６】本発明の別の実施形態における報奨情報の構成を示す図である。
【図２７】本発明の別の実施形態における報奨情報の構成を示す図である。
【図２８】本発明の別の実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図２９】本発明の別の実施形態における報奨情報の構成を示す図である。
【図３０】本発明の別の実施形態における申込期限が過ぎた場合の健康管理端末での表示画面を表す図である。
【図３１】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図３２】本発明の別の実施形態における報奨情報の構成を示す図である。
【図３３】本発明の別の実施形態における条件クリア後の健康管理端末での表示画面を表す図であり、（ａ）は、クイズを表示している表示例を表しており、（ｂ）は、（ａ）のクイズ正解後における表示例を表している。
【図３４】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図３５】本発明の別の実施形態におけるヘルスケアシステムに用いられるユーザ情報蓄積部、アンケート情報蓄積部を備える報奨提供元サーバの構成を示すブロック図である。
【図３６】本発明の別の実施形態におけるヘルスケアシステムに用いられるユーザ情報記憶部を備える健康管理端末の構成を示すブロック図である。
【図３７】本発明の別の実施形態における個人情報を入力させるための表示画面を表す図である。
【図３８】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図３９】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図４０】本発明の別の実施形態における報奨情報を変更する際の健康管理端末での表示例を示す図である。
【図４１】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図４２】本発明の別の実施形態における報奨情報の構成を示す図である。
【図４３】本発明の別の実施形態における条件クリア後の健康管理端末での表示画面を表す図であり、報奨申し込みに当たっての確認事項を表示している表示例を表している。
【図４４】本発明の別の実施形態におけるヘルスケアシステムに用いられるポイント換算部を備える健康管理端末の構成を示すブロック図である。
【図４５】本発明の別の実施形態における報奨情報の構成を示す図である。
【図４６】本発明の別の実施形態における健康データ記憶部に格納される健康データのテーブルを示すである。
【図４７】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図４８】本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図４９】本発明の別の実施形態の条件クリア後における健康管理端末での表示例を示す図である。
【図５０】本発明の別の実施形態におけるヘルスケアシステムに用いられる受信部、選択部を備える健康管理端末の構成を示すブロック図である。
【図５１】本発明の別の実施形態におけるヘルスケアシステムに用いられる、対象健康データカウント部、条件チェック部を備えるサービスサーバの構成を示すブロック図である。
【図５２】本発明の別の実施形態における報奨情報蓄積部に格納される報奨情報を示す図である。
【図５３】本発明の別の実施形態におけるユーザデータ記憶部に格納されるデータを示す図であり、（ａ）は報奨選択テーブルを表し、（ｂ）は健康データテーブルを表す。
【図５４】本発明の別の実施形態におけるヘルスケアシステムの処理の流れを示すフローチャートである。
【図５５】（ａ）および（ｂ）は、本発明の別の実施形態の条件未達段階における健康管理端末での表示例を示す図である。
【図５６】本発明の別の実施形態における新しい情報を通知する際の健康管理端末での表示画面を表す図である。
【図５７】本発明の別の実施形態におけるヘルスケアシステムに用いられる重み付きデータ算出部を備える健康管理端末の構成を示すブロック図である。
【図５８】本発明の別の実施形態におけるヘルスケアシステムに用いられる期限判定部を備える健康管理端末の構成を示すブロック図である。
【図５９】本発明の別の実施形態におけるヘルスケアシステムに用いられる報奨変更部を備える健康管理端末の構成を示すブロック図である。
【符号の説明】
【０２６９】
１００，１００’ ヘルスケアシステム（健康管理システム）
１０１，１０１’ 健康管理端末
１０２ 健康機器（健康情報測定装置）
１０３，１０３’ サービスサーバ
１０４ 報奨提供元サーバ
２０１ 健康データ取得部（健康情報取得手段）
２０２ 健康データ記憶部
２０３ 報奨情報取得部（報奨情報受信手段）
２０４ 報奨情報記憶部
２０５ 対象健康データカウント部（判定手段、単位判定手段）
２０６ 条件チェック部（判定手段、単位判定手段）
２０７ 提示内容更新部（単位判定手段、提示態様決定手段）
２０８ 報奨申し込み部（報奨申込手段）
２０９ 情報提示部（素材情報提示手段）
２１０ ユーザ情報記憶部
２１１ 情報入力部（情報入力手段）
２１２ 入力項目情報送受信部（入力項目情報受信手段、ユーザ入力情報送信手段）
２１３ ポイント換算部
２１４ 受信部（報奨情報受信手段、提示態様受信手段）
２１５ 表示部（素材情報提示手段）
２１６ 選択部
２２１ 重み付きデータ算出部（判定手段、単位判定手段、第１重み付加手段、第２重み付加手段）
２２２ 期限判定部（期限判定手段）
２２３ 報奨変更部（報奨情報変更手段）
２３０ 端末情報記憶部
２４０ 端末情報処理部
４０１ 報奨情報受付部（報奨情報受付手段）
４０２ 報奨情報蓄積部
４０３ サービスサーバ報奨情報送信部（第２報奨情報送信手段）
４０５ 健康データ受信部（健康情報受付手段）
４０７ 対象健康データカウント部（判定手段）
４０８ 条件チェック部（判定手段）
４０９ 表示データ作成部（提示態様情報生成手段）
４１０ 表示データ送信部（申込許可送信手段、提示態様送信手段）
５０１ 提供元報奨情報送信部（第１報奨情報送信手段）
５０２ 報奨申込受付部（報奨受付手段）
５０３ 入力項目送受信部（入力項目情報送信手段、ユーザ入力情報受信手段）
５０４ ユーザ情報蓄積部（ユーザ入力情報記憶手段）
５０５ アンケート情報蓄積部（ユーザ入力情報記憶手段）
６０１ 測定部（測定手段）
６０２ 健康データ供給部（健康情報供給部）
１３０１ ボタン（報奨申込手段）
【特許請求の範囲】
【請求項１】
健康情報測定装置と、報奨提供元サーバと、健康管理端末とを含む健康管理システムであって、
上記健康情報測定装置は、
ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、
上記測定手段によって得られる測定結果を健康情報として上記健康管理端末に供給する健康情報供給手段とを備えており、
上記報奨提供元サーバは、
報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記健康管理端末に対して直接または間接に送信する第１報奨情報送信手段を備えており、
上記健康管理端末は、
上記報奨情報を受信する報奨情報受信手段と、
上記健康情報を上記健康情報測定装置から取得する健康情報取得手段と、
上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、
上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、
上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴とする健康管理システム。
【請求項２】
サービスサーバをさらに含み、
上記サービスサーバは、上記報奨情報を上記報奨提供元サーバから受信する報奨情報受付手段と、
上記報奨情報受付手段が受信した上記報奨情報を上記健康管理端末に送信する第２報奨情報送信手段とを備えており、
上記報奨提供元サーバから上記健康管理端末への上記報奨情報の送信、および上記健康管理端末における上記報奨情報の受信は、上記サービスサーバを介しておこなわれることを特徴とする請求項１に記載の健康管理システム。
【請求項３】
上記報奨情報は、上記報奨提供元サーバへのアクセス先の情報であるアクセス先情報をさらに含み、
上記報奨提供元サーバは、上記健康管理端末からの上記報奨の申し込みを受け付ける報奨受付手段をさらに備えており、
上記健康管理端末は、上記報奨提供元サーバへアクセスすることにより上記報奨の申し込みをおこなうことを特徴とする請求項１または２に記載の健康管理システム。
【請求項４】
上記健康管理端末は、受信した上記報奨情報に含まれる上記素材情報の提示態様を、上記健康情報取得手段により取得された上記健康情報に応じて決定する、提示態様決定手段をさらに備えていることを特徴とする請求項１から３までの何れか１項に記載の健康管理システム。
【請求項５】
上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、
上記健康管理端末は、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、
上記提示態様決定手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、上記提示態様を変更することを特徴とする請求項４に記載の健康管理システム。
【請求項６】
上記報奨情報は、２種類以上の素材情報を含むことを特徴とする請求項１から５までの何れか１項に記載の健康管理システム。
【請求項７】
上記報奨情報は、上記素材情報として、上記報奨の内容を表示する報奨表示画像を含み、
上記報奨情報は、上記報奨表示画像を表示させる単位時間を指定する表示単位時間情報をさらに含み、
上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記表示単位時間情報を用いて上記報奨表示画像を表示させる時間を決定し、決定した時間、上記報奨表示画像を上記素材情報提示手段に提示させることを特徴とする請求項５に記載の健康管理システム。
【請求項８】
上記報奨情報は、上記素材情報として、上記報奨表示画像とは異なるカバー画像をさらに含み、
上記提示態様決定手段は、上記報奨表示画像を表示させていない間、上記カバー画像を上記素材情報提示手段に提示させることを特徴とする請求項７に記載の健康管理システム。
【請求項９】
上記報奨情報は、上記素材情報として、動画を含み、
上記報奨情報は、上記動画を再生させる単位時間を指定する再生単位時間情報をさらに含み、
上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記再生単位時間情報を用いて上記動画を再生する時間を決定し、決定した時間、上記動画を再生し、上記素材情報提示手段に提示させることを特徴とする請求項５に記載の健康管理システム。
【請求項１０】
上記報奨情報は、上記素材情報として、２種類以上の静止画を含み、
上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記２種類以上の静止画のうちの何れを提示させるかを選択して、選択した上記静止画を上記素材情報提示手段に提示させることを特徴とする請求項５に記載の健康管理システム。
【請求項１１】
上記申込条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることを特徴とする請求項１から１０までの何れか１項に記載の健康管理システム。
【請求項１２】
上記単位条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることを特徴とする請求項５から１０までの何れか１項に記載の健康管理システム。
【請求項１３】
上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、
上記判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第１重み付加手段を有しており、
上記判定手段では、上記第１重み付加手段によって生成された上記重み付き健康情報が上記申込条件を満たしている場合に、上記健康情報が上記申込条件を満たしていると判定することを特徴とする請求項１から１２までの何れか１項に記載の健康管理システム。
【請求項１４】
上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、
上記単位判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第２重み付加手段を有しており、
上記単位判定手段では、上記第２重み付加手段によって生成された上記重み付き健康情報が上記単位条件を満たしている場合に、上記健康情報が上記単位条件を満たしていると判定することを特徴とする請求項５から１０までの何れか１項に記載の健康管理システム。
【請求項１５】
上記報奨情報は、上記報奨提供元サーバが報奨の申し込みを受け付ける期限条件を指定する期限条件情報をさらに含み、
上記健康管理端末は、上記健康情報が上記期限条件を満たしているか否かを判定する期限判定手段をさらに備えており、上記期限判定手段によって上記健康情報が上記期限条件を満たしている判定されたときに、上記報奨申込手段により上記報奨を申し込むことを特徴とする請求項１から１４までの何れか１項に記載の健康管理システム。
【請求項１６】
上記報奨情報は、上記健康管理端末が上記報奨提供元サーバへアクセスするよりも前に上記素材情報提示手段が提示する申込前情報と、該申込前情報を提示させるか否かを指定する申込前表示情報とをさらに含み、
上記素材情報提示手段は、上記申込前表示情報に応じて、上記報奨提供元サーバへアクセスするよりも前であり、かつ、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定された後に、上記申込前情報を提示することを特徴とする請求項３に記載の健康管理システム。
【請求項１７】
上記健康管理端末は、
上記報奨提供元サーバから送信される、上記ユーザが入力するための項目を指定する入力項目情報を受信する入力項目情報受信手段と、
受信した上記入力項目情報に指定される項目を上記ユーザが入力するための情報入力手段と、
上記情報入力手段を介してユーザが入力したユーザ入力情報を上記報奨提供元サーバへ送信するユーザ入力情報送信手段とをさらに備えており、
上記報奨提供元サーバは、
上記入力項目情報を上記健康管理端末に送信する入力項目情報送信手段と、
上記健康管理端末から送信される上記ユーザ入力情報を受信するユーザ入力情報受信手段と、
受信した上記ユーザ入力情報を記憶するユーザ入力情報記憶手段とを備えていることを特徴とする請求項１から１６までの何れか１項に記載の健康管理システム。
【請求項１８】
上記健康管理端末は、受信した上記報奨情報とは異なる報奨情報をさらに受信し、使用している上記報奨情報を該異なる報奨情報に置換する報奨情報変更手段をさらに備えていることを特徴とする請求項１から１７までの何れか１項に記載の健康管理システム。
【請求項１９】
健康情報測定装置と、報奨提供元サーバと、サービスサーバと、健康管理端末とを含む健康管理システムであって、
上記健康情報測定装置は、
ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、
上記測定手段により測定された結果を健康情報として上記健康管理端末を介して上記サービスサーバに供給する健康情報供給手段とを備えており、
上記報奨提供元サーバは、
報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記サービスサーバに送信する第１報奨情報送信手段を備えており、
上記サービスサーバは、
上記報奨情報を上記報奨提供元サーバから受信する報奨情報受付手段と、
上記健康情報を上記健康管理端末から取得する健康情報受付手段と、
上記報奨情報受付手段が取得した報奨情報に含まれる上記素材情報を、上記健康管理端末に送信する第２報奨情報送信手段と、
上記健康情報が上記報奨情報受付手段により受信された上記報奨情報に含まれる上記申込条件を満たしているか否かを判定する判定手段と、
上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記健康管理端末に対して上記報奨の申し込みをおこなうことの許可を与える申込許可情報を送信する申込許可送信手段とを備えており、
上記健康管理端末は、
上記素材情報を、上記サービスサーバから受信する報奨情報受信手段と
上記申込許可情報を受信したときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、
上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴とする健康管理システム。
【請求項２０】
上記サービスサーバは、上記健康情報受付手段により取得された上記健康情報に応じた上記素材情報提示手段における上記素材情報の提示態様を指定する提示態様情報を生成する提示態様情報生成手段と、
上記提示態様情報を上記健康管理端末に送信する提示態様送信手段とをさらに備えており、
上記健康管理端末は、上記提示態様情報を受信する提示態様受信手段をさらに備えており、
上記素材情報提示手段は、上記提示態様受信手段によって受信された上記提示態様情報に応じた提示態様にしたがって、上記素材情報を提示することを特徴とする請求項１９に記載の健康管理システム。
【請求項２１】
上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、
上記サービスサーバは、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、
上記提示態様情報生成手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、異なる上記提示態様を指定する上記提示態様情報を生成することを特徴とする請求項２０に記載の健康管理システム。
【請求項２２】
報奨提供元サーバから報奨情報を取得し、健康情報測定装置がユーザの生理状態および運動状態の少なくとも何れかを測定することにより得られる健康情報に応じて報奨の申し込みをおこなう健康管理端末であって、
上記報奨情報は、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、該報奨の申し込みをおこなうまで上記ユーザに提示する素材情報とを含み、
上記報奨情報を上記報奨提供元サーバから直接または間接に受信する報奨情報受信手段と、
上記健康情報測定装置から供給される上記健康情報を取得する健康情報取得手段と、
上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、
上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記報奨の申し込みをおこなう報奨申込手段と、
上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴とする健康管理端末。
【請求項２３】
請求項１から２１までの何れか１項に記載の健康管理システムの上記健康管理端末または請求項２２に記載の健康管理端末を動作させる健康管理プログラムであって、コンピュータを上記健康管理端末の上記各手段として機能させるための健康管理プログラム。
【請求項２４】
請求項２から２１までの何れか１項に記載の健康管理システムの上記サービスサーバを動作させるサービスサーバプログラムであって、コンピュータを上記サービスサーバの上記各手段として機能させるためのサービスサーバプログラム。
【請求項２５】
請求項２３に記載の健康管理プログラムを記録しているコンピュータ読み取り可能な記録媒体。
【請求項２６】
請求項２４に記載のサービスサーバプログラムを記録しているコンピュータ読み取り可能な記録媒体。
【請求項１】
健康情報測定装置と、報奨提供元サーバと、健康管理端末とを含む健康管理システムであって、
上記健康情報測定装置は、
ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、
上記測定手段によって得られる測定結果を健康情報として上記健康管理端末に供給する健康情報供給手段とを備えており、
上記報奨提供元サーバは、
報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記健康管理端末に対して直接または間接に送信する第１報奨情報送信手段を備えており、
上記健康管理端末は、
上記報奨情報を受信する報奨情報受信手段と、
上記健康情報を上記健康情報測定装置から取得する健康情報取得手段と、
上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、
上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、
上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴とする健康管理システム。
【請求項２】
サービスサーバをさらに含み、
上記サービスサーバは、上記報奨情報を上記報奨提供元サーバから受信する報奨情報受付手段と、
上記報奨情報受付手段が受信した上記報奨情報を上記健康管理端末に送信する第２報奨情報送信手段とを備えており、
上記報奨提供元サーバから上記健康管理端末への上記報奨情報の送信、および上記健康管理端末における上記報奨情報の受信は、上記サービスサーバを介しておこなわれることを特徴とする請求項１に記載の健康管理システム。
【請求項３】
上記報奨情報は、上記報奨提供元サーバへのアクセス先の情報であるアクセス先情報をさらに含み、
上記報奨提供元サーバは、上記健康管理端末からの上記報奨の申し込みを受け付ける報奨受付手段をさらに備えており、
上記健康管理端末は、上記報奨提供元サーバへアクセスすることにより上記報奨の申し込みをおこなうことを特徴とする請求項１または２に記載の健康管理システム。
【請求項４】
上記健康管理端末は、受信した上記報奨情報に含まれる上記素材情報の提示態様を、上記健康情報取得手段により取得された上記健康情報に応じて決定する、提示態様決定手段をさらに備えていることを特徴とする請求項１から３までの何れか１項に記載の健康管理システム。
【請求項５】
上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、
上記健康管理端末は、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、
上記提示態様決定手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、上記提示態様を変更することを特徴とする請求項４に記載の健康管理システム。
【請求項６】
上記報奨情報は、２種類以上の素材情報を含むことを特徴とする請求項１から５までの何れか１項に記載の健康管理システム。
【請求項７】
上記報奨情報は、上記素材情報として、上記報奨の内容を表示する報奨表示画像を含み、
上記報奨情報は、上記報奨表示画像を表示させる単位時間を指定する表示単位時間情報をさらに含み、
上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記表示単位時間情報を用いて上記報奨表示画像を表示させる時間を決定し、決定した時間、上記報奨表示画像を上記素材情報提示手段に提示させることを特徴とする請求項５に記載の健康管理システム。
【請求項８】
上記報奨情報は、上記素材情報として、上記報奨表示画像とは異なるカバー画像をさらに含み、
上記提示態様決定手段は、上記報奨表示画像を表示させていない間、上記カバー画像を上記素材情報提示手段に提示させることを特徴とする請求項７に記載の健康管理システム。
【請求項９】
上記報奨情報は、上記素材情報として、動画を含み、
上記報奨情報は、上記動画を再生させる単位時間を指定する再生単位時間情報をさらに含み、
上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記再生単位時間情報を用いて上記動画を再生する時間を決定し、決定した時間、上記動画を再生し、上記素材情報提示手段に提示させることを特徴とする請求項５に記載の健康管理システム。
【請求項１０】
上記報奨情報は、上記素材情報として、２種類以上の静止画を含み、
上記提示態様決定手段は、上記単位判定手段によって得られる結果に応じて、上記２種類以上の静止画のうちの何れを提示させるかを選択して、選択した上記静止画を上記素材情報提示手段に提示させることを特徴とする請求項５に記載の健康管理システム。
【請求項１１】
上記申込条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることを特徴とする請求項１から１０までの何れか１項に記載の健康管理システム。
【請求項１２】
上記単位条件情報は、上記測定手段によって得られる数値または上記測定手段が測定をおこなった回数を指定するものであることを特徴とする請求項５から１０までの何れか１項に記載の健康管理システム。
【請求項１３】
上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、
上記判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第１重み付加手段を有しており、
上記判定手段では、上記第１重み付加手段によって生成された上記重み付き健康情報が上記申込条件を満たしている場合に、上記健康情報が上記申込条件を満たしていると判定することを特徴とする請求項１から１２までの何れか１項に記載の健康管理システム。
【請求項１４】
上記報奨情報は、上記健康情報取得手段が取得した上記健康情報に対して重み付けをおこなうための重み付け情報をさらに含み、
上記単位判定手段は、上記重み付け情報を用いて上記健康情報に重みを付けた重み付き健康情報を生成する第２重み付加手段を有しており、
上記単位判定手段では、上記第２重み付加手段によって生成された上記重み付き健康情報が上記単位条件を満たしている場合に、上記健康情報が上記単位条件を満たしていると判定することを特徴とする請求項５から１０までの何れか１項に記載の健康管理システム。
【請求項１５】
上記報奨情報は、上記報奨提供元サーバが報奨の申し込みを受け付ける期限条件を指定する期限条件情報をさらに含み、
上記健康管理端末は、上記健康情報が上記期限条件を満たしているか否かを判定する期限判定手段をさらに備えており、上記期限判定手段によって上記健康情報が上記期限条件を満たしている判定されたときに、上記報奨申込手段により上記報奨を申し込むことを特徴とする請求項１から１４までの何れか１項に記載の健康管理システム。
【請求項１６】
上記報奨情報は、上記健康管理端末が上記報奨提供元サーバへアクセスするよりも前に上記素材情報提示手段が提示する申込前情報と、該申込前情報を提示させるか否かを指定する申込前表示情報とをさらに含み、
上記素材情報提示手段は、上記申込前表示情報に応じて、上記報奨提供元サーバへアクセスするよりも前であり、かつ、上記判定手段によって上記健康情報が上記申込条件を満たしていると判定された後に、上記申込前情報を提示することを特徴とする請求項３に記載の健康管理システム。
【請求項１７】
上記健康管理端末は、
上記報奨提供元サーバから送信される、上記ユーザが入力するための項目を指定する入力項目情報を受信する入力項目情報受信手段と、
受信した上記入力項目情報に指定される項目を上記ユーザが入力するための情報入力手段と、
上記情報入力手段を介してユーザが入力したユーザ入力情報を上記報奨提供元サーバへ送信するユーザ入力情報送信手段とをさらに備えており、
上記報奨提供元サーバは、
上記入力項目情報を上記健康管理端末に送信する入力項目情報送信手段と、
上記健康管理端末から送信される上記ユーザ入力情報を受信するユーザ入力情報受信手段と、
受信した上記ユーザ入力情報を記憶するユーザ入力情報記憶手段とを備えていることを特徴とする請求項１から１６までの何れか１項に記載の健康管理システム。
【請求項１８】
上記健康管理端末は、受信した上記報奨情報とは異なる報奨情報をさらに受信し、使用している上記報奨情報を該異なる報奨情報に置換する報奨情報変更手段をさらに備えていることを特徴とする請求項１から１７までの何れか１項に記載の健康管理システム。
【請求項１９】
健康情報測定装置と、報奨提供元サーバと、サービスサーバと、健康管理端末とを含む健康管理システムであって、
上記健康情報測定装置は、
ユーザの生理状態および運動状態の少なくとも何れかを測定する測定手段と、
上記測定手段により測定された結果を健康情報として上記健康管理端末を介して上記サービスサーバに供給する健康情報供給手段とを備えており、
上記報奨提供元サーバは、
報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、上記健康管理端末が該報奨の申し込みをおこなうまで、上記ユーザに提示する素材情報とを含む報奨情報を上記サービスサーバに送信する第１報奨情報送信手段を備えており、
上記サービスサーバは、
上記報奨情報を上記報奨提供元サーバから受信する報奨情報受付手段と、
上記健康情報を上記健康管理端末から取得する健康情報受付手段と、
上記報奨情報受付手段が取得した報奨情報に含まれる上記素材情報を、上記健康管理端末に送信する第２報奨情報送信手段と、
上記健康情報が上記報奨情報受付手段により受信された上記報奨情報に含まれる上記申込条件を満たしているか否かを判定する判定手段と、
上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記健康管理端末に対して上記報奨の申し込みをおこなうことの許可を与える申込許可情報を送信する申込許可送信手段とを備えており、
上記健康管理端末は、
上記素材情報を、上記サービスサーバから受信する報奨情報受信手段と
上記申込許可情報を受信したときに、報奨の申し込みをおこなう指示を受け付けて上記報奨の申し込みをおこなう報奨申込手段と、
上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴とする健康管理システム。
【請求項２０】
上記サービスサーバは、上記健康情報受付手段により取得された上記健康情報に応じた上記素材情報提示手段における上記素材情報の提示態様を指定する提示態様情報を生成する提示態様情報生成手段と、
上記提示態様情報を上記健康管理端末に送信する提示態様送信手段とをさらに備えており、
上記健康管理端末は、上記提示態様情報を受信する提示態様受信手段をさらに備えており、
上記素材情報提示手段は、上記提示態様受信手段によって受信された上記提示態様情報に応じた提示態様にしたがって、上記素材情報を提示することを特徴とする請求項１９に記載の健康管理システム。
【請求項２１】
上記報奨情報は、上記素材情報の提示態様を変更するための上記健康情報の条件である単位条件を指定する単位条件情報をさらに含み、
上記サービスサーバは、上記判定手段によって上記健康情報が上記申込条件を満たしていないと判定されたときに、上記健康情報が上記単位条件を満たしているか否かを判定する単位判定手段をさらに備えており、
上記提示態様情報生成手段は、上記単位判定手段によって上記健康情報が上記単位条件情報を満たしていると判定されたときに、異なる上記提示態様を指定する上記提示態様情報を生成することを特徴とする請求項２０に記載の健康管理システム。
【請求項２２】
報奨提供元サーバから報奨情報を取得し、健康情報測定装置がユーザの生理状態および運動状態の少なくとも何れかを測定することにより得られる健康情報に応じて報奨の申し込みをおこなう健康管理端末であって、
上記報奨情報は、報奨を申し込むための上記健康情報の条件である申込条件を指定する申込条件情報と、該報奨の申し込みをおこなうまで上記ユーザに提示する素材情報とを含み、
上記報奨情報を上記報奨提供元サーバから直接または間接に受信する報奨情報受信手段と、
上記健康情報測定装置から供給される上記健康情報を取得する健康情報取得手段と、
上記健康情報が上記報奨情報受信手段により受信された上記報奨情報に含まれる上記申込条件情報に指定される上記申込条件を満たしているか否かを判定する判定手段と、
上記判定手段によって上記健康情報が上記申込条件を満たしていると判定されたときに、上記報奨の申し込みをおこなう報奨申込手段と、
上記報奨申込手段が上記報奨の申し込みをおこなうまで、上記報奨情報受信手段が受信した上記報奨情報に含まれる上記素材情報を上記ユーザに提示する素材情報提示手段とを備えていることを特徴とする健康管理端末。
【請求項２３】
請求項１から２１までの何れか１項に記載の健康管理システムの上記健康管理端末または請求項２２に記載の健康管理端末を動作させる健康管理プログラムであって、コンピュータを上記健康管理端末の上記各手段として機能させるための健康管理プログラム。
【請求項２４】
請求項２から２１までの何れか１項に記載の健康管理システムの上記サービスサーバを動作させるサービスサーバプログラムであって、コンピュータを上記サービスサーバの上記各手段として機能させるためのサービスサーバプログラム。
【請求項２５】
請求項２３に記載の健康管理プログラムを記録しているコンピュータ読み取り可能な記録媒体。
【請求項２６】
請求項２４に記載のサービスサーバプログラムを記録しているコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図５６】
【図５７】
【図５８】
【図５９】
【公開番号】特開２０１０−９７５５３（Ｐ２０１０−９７５５３Ａ）
【公開日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願番号】特願２００８−２６９８５７（Ｐ２００８−２６９８５７）
【出願日】平成２０年１０月２０日（２００８．１０．２０）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願日】平成２０年１０月２０日（２００８．１０．２０）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]