(57)【特許請求の範囲】
【請求項１】
健康管理を行うユーザのデータを測定する携帯端末から測定データと、前記測定データを受信する予定日時を含む予定データとを取得し、前記測定データを取得した場合、前記取得した回数をカウントするデータ管理手段と、
前記予定データに基づき、前記測定の開始時期から終了時期までに発呼する回数である総発呼回数を計算し、前記予定日時に前記携帯端末から前記測定データを受信しない場合、前記携帯端末に発呼信号の送信を決定する発呼決定手段と、
前記決定に基づき、前記携帯端末に前記発呼信号を送信する発呼手段を含み、
前記発呼決定手段は、前記取得した回数と、前記総発呼回数が等しい場合、前記データ管理手段に通知を行い、
前記データ管理手段は、前記通知に基づいてアドバイスデータを作成するアドバイス作成手段に、前記測定データを送信する管理装置。
【請求項２】
前記予定データは、さらに前記測定の頻度を示す情報および前記発呼信号の送信先を含む請求項１の管理装置。
【請求項３】
前記携帯端末は、前記予定データを作成する予定作成手段をさらに備え、
前記測定データは、前記携帯端末が備える、脈拍または体温センサの測定のデータである請求項１または請求項２の管理装置。
【請求項４】
前記予定日時と、前記測定の時間帯である対象測定時間帯と、前記発呼信号の送信先とをＩＤによって関連付けて記憶する記憶手段を備える請求項３の管理装置。
【請求項５】
前記データ管理手段は、
前記測定データと、前記データ管理手段が前記携帯端末から測定データを受信した日時とを関連付けて記憶する請求項４の管理装置。
【請求項６】
前記データ管理手段は、
前記取得した回数をカウントした場合、前記受信した日時が該当する前記対象測定時間帯を含む前記ＩＤに対し、前記測定データが入力されたことを示す入力フラグを設定し、
前記発呼決定手段は、前記入力フラグが設定されていない場合、前記予定日時に前記携帯端末から前記測定データを受信していないと判断し、前記携帯端末に前記発呼信号の送信を決定する請求項５の管理装置。
【請求項７】
前記携帯端末は、センサ手段を有し、前記測定は、前記センサ手段によって行われる請求項６の管理装置。
【請求項８】
健康管理を行うユーザのデータを測定する携帯端末から測定データと、前記測定データを受信する予定日時を含む予定データとを取得し、前記測定データを取得した場合、前記取得した回数をカウントし、前記予定データに基づき、前記測定の開始から終了時期までに発呼する回数である総発呼回数を計算し、
前記予定日時に前記携帯端末から前記測定データを受信しない場合、前記携帯端末に発呼信号の送信を決定し、前記決定に基づき前記携帯端末に発呼信号を送信し、
前記取得した回数と、前記総発呼回数が等しい場合、測定データを分析しアドバイスデータを作成するアドバイス作成装置に、前記測定データを送信することをコンピュータに実行させる管理プログラム。
【請求項９】
健康管理を行うユーザのデータを測定する携帯端末から測定データと、前記測定データを受信する予定日時を含む予定データとを取得し、前記測定データを取得した場合、前記取得した回数をカウントし、前記予定データに基づき、前記測定の開始から終了時期までに発呼する回数である総発呼回数を計算し、
前記予定日時に前記携帯端末から前記測定データを受信しない場合、前記携帯端末に発呼信号を送信し、
前記取得した回数と、前記総発呼回数とが等しい場合、測定データを分析しアドバイスデータを作成するアドバイス作成装置に、前記測定データを送信することをコンピュータに実行させる管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は管理装置、プログラム及び方法に関する。
【背景技術】
【０００２】
携帯電話や、インターネットを利用した、健康管理システムが注目されている。場所や時間に拘束されることなく、身体に関するデータの送信が可能なこと、医療専門家の適切な助言が受けられることが、健康管理システムの特徴である。特許文献１は、測定情報を携帯端末によって、サーバ装置へ送信し、健康アドバイス情報をサーバ装置から、携帯情報端末に送信する方法を開示している。特許文献２は、生体情報センサを装着された携帯電話機から、生体情報を医療従事者の端末装置に送信することによって、会員がこの生体情報に基づく医療情報を受けるという医療情報提供装置を開示している。特許文献３は、携帯電話と合体させた脈拍計を開示しており、携帯電話を握るだけで脈拍が測定でき、測定結果を送信先に送付できるという効果を記載している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−２４５２５４号公報
【特許文献２】特開２００４−０４９３４５号公報
【特許文献３】特許第４４０１１４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の方法では、測定者が、生体情報測定装置から取得した生体データを携帯電話に入力するので、長期間にわたり定期的に測定を行う場合、データの取り忘れが発生する。
【０００５】
特許文献２の装置は、生体センサが携帯電話機に装着されているため、特許文献１の方法に較べると煩雑さは少ない。しかし、センサに身体の対象部分を押し当てることで行われる測定は、測定者の意志に委ねられる。したがって、やはり定期的測定においては、データの取り忘れが発生する。
【０００６】
特許文献３の装置は、携帯電話を握るだけで、脈拍が測定できるので、特許文献２の装置に較べると、測定は容易である。しかし、定期的な測定においては、携帯電話を握る動作を意識的に行わねばならず、やはりデータの取り忘れは発生する。
【０００７】
本発明の目的は上記の課題を解決して、データの取り忘れを防止し、予定していた測定を高い確度で実施することである。
【課題を解決するための手段】
【０００８】
本発明によれば、把持しているユーザのデータを測定する携帯端末から、測定データを受信する予定日時を記憶するデータ管理手段と前記予定日時に前記測定データを受信しないと、前記携帯端末に督促信号を送信する督促手段、を備える管理装置が得られる。
【０００９】
本発明によれば、把持しているユーザのデータを測定する携帯端末から、測定データを受信する予定日時を記憶するデータ管理処理と、前記予定日時に前記測定データを受信しないと、前記携帯端末に督促信号を送信する督促処理、とをコンピュータに実行させるアクセス管理プログラムが得られる。
【００１０】
本発明によれば、把持しているユーザのデータを測定する携帯端末から、測定データを受信する予定日時を記憶し、前記予定日時に前記測定データを受信しないと、前記携帯端末に督促信号を送信するアクセス管理方法が得られる。
【発明の効果】
【００１１】
本発明の効果は、ユーザが端末を把持することで行われる測定を、予定に合わせて高い確度で実施することを可能とすることである。
【図面の簡単な説明】
【００１２】
【図１】図１は本発明の第１の実施形態の構成を示すブロック図である。
【図２】図２は本発明の第１の実施形態の予定データの一例を示す図である。
【図３】図３は本発明の第１の実施形態の測定データテーブルの一例を示す図である。
【図４】図４は本発明の第１の実施形態の発呼予定テーブルの一例を示す図である。
【図５】図５は本発明の第１の実施形態の管理装置の督促部１４の処理を示すフローチャートである。
【図６】図６は本発明の第１の実施形態のユーザ端末装置２００の処理を示すフローチャートである。
【図７】図７は本発明の第１の実施形態の管理装置１００のデータ管理部１１の処理を示すフローチャートである。
【図８】図８は本発明の第１の実施形態の処理を示すシーケンスチャートである。
【図９】図９は本発明の第２の実施形態の処理を示すシーケンスチャートである。
【図１０】図１０は本発明の第３の実施形態の構成を示すブロック図である。
【発明を実施するための形態】
【００１３】
以下に本発明の実施形態が、図面を参照して詳細に説明される。
（第１の実施形態）
図１は、本発明の第１の実施形態におけるデータ集計装置の構成を示すブロック図である。本実施形態においては、ユーザが測定したユーザ自身の脈拍の測定データ（以降、脈拍データ、と呼ぶ）を定期的にコンテンツプロバイダ装置３００に送信し、コンテンツプロバイダ装置３００（ＣＰ装置３００とも呼ぶ）から、健康管理のための助言を受けるシステムに、本発明が適用されている。
【００１４】
管理装置１００は、データ管理部１１と、データ送信部１０と、督促部１４とを含んでいる。督促部１４は、発呼決定部１２と発呼部１３と、を含んでいる。
【００１５】
データ管理部１１は、ユーザ端末装置２００から予定データ及び測定データを取得し、これを自身が備える記憶部に格納する。予定データは、測定の頻度、または測定の期日を指定する。また、予定データは、測定データを送信する予定日時をも指定し、督促信号を受けるためのアドレスまたは、電話番号を指定する。頻度を指定する場合は、測定開始及び終了の期日か、もしくは、目標データ数を、頻度と合わせて指定する。また、予定データには、ユーザのアドレスまたは電話番号を含む、督促信号の送信先が指定されている。測定データは、測定データテーブルに格納される。図２は、予定データの例を示す。この例は、一日一回という頻度と、測定の開始時期、終了時期、督促信号の送信先である電話番号を指定している。図３は測定データテーブルの例を示す。測定データである１分間当たりの脈拍数は、このデータの受信日時と合わせて、測定データテーブルに格納される。データ管理部１１は、図示しないデータカウント部とカレンダー機能を有し、送信されたデータの個数を取得日時毎に計数し、記憶部に受信日時と関連付けて格納する。なお、データカウント部の計数したデータ数、カレンダー機能が出力する現在日時は、発呼決定部１２にも出力される。
【００１６】
発呼決定部１２は、予定データから、発呼する日時、及び総発呼回数を計算する。総発呼回数は、定期的な測定が完了するまでに、必要とされる発呼の回数の最大値である。計算結果と、予定データで指定された督促信号の送信先である電話番号とは、図示しない記憶部に、発呼予定テーブルとして格納する。図４は発呼予定テーブルの例を示す。各発呼日時のデータには、それぞれＩＤ番号を付されている。また、それぞれ、対象測定時間帯が指定されている。この対象測定時間帯は、波線〜の左側に表示された時刻から右側に表示された時刻の直前まで、と定義される。例えば「０：００〜２４：００」という表記は、０：００から２４：００の直前までを意味する。また、予定データで指定された、督促信号の送信先の電話番号が、各ＩＤ毎に格納されている。
【００１７】
なお、発呼予定テーブルは、データ管理部１１からも、発呼決定部１２からもデータの入出力が可能である。また、発呼予定テーブル発呼部１３、発呼部１３から、送信先の電話番号のデータを読み出すことができる。
【００１８】
データ管理部１１は、脈拍データが入力され、データカウント部がデータ数として自らに１を加算すると、発呼予定テーブルの、該当するＩＤの入力フラグ欄に“１“を入力する。該当するＩＤは、受信時刻が、対象測定時間帯に属する、ＩＤである。脈拍データの入力がない状態では、入力フラッグ欄には、”０“が入力されている。図４は、ＩＤ１からＩＤ４までが指定する日時に、脈拍データの入力があり、ＩＤ５以降は、脈拍データの入力がされていない、発呼予定テーブルの例を表している。予定される発呼の最大数は、総発呼回数Ｎと呼ばれ、ＩＤ番号の最大値に相当する。図４の場合、総発呼回数Ｎは１６となる。発呼決定部１２は、各ＩＤの示す対象測定時間帯に脈拍データの入力があったか否か、すなわち条件が達成されているか否かを、入力フラグの値で判断する。入力フラグが１の時は、発呼決定部１２は、条件が達成されている、と判断する。入力フラグが０の時、発呼決定部１２は、条件が達成されていないと判断する。条件が達成されていない場合、発呼決定部１２は、ユーザ端末装置２００の着信部２３に、督促のための発呼を行うことを決定し、発呼部１３に発呼信号の送信命令を出力する。発呼信号は、督促信号とも呼ばれる。発呼部１３は、発呼決定部１２の判断を受けて、発呼予定テーブルから、ユーザ端末装置２００の指定された電話番号を読み出し、該電話番号に発呼信号を送信する。データ管理部１１、データ送信部１０、発呼決定部１２、発呼部１３は、論理回路等を組み合わせたハードウェアで実現することができる。また、これらは、図示されていないプロセッサが、同じく図示されていないメモリに格納されているプログラムを実行することで実現されてもよい。
【００１９】
ユーザ端末装置２００は、データ送信部２０と、予定作成部２１と、データ測定部２２と、センサ部２４と、着信部２３と、通話部２５とを含んでいる。ユーザ端末装置２００としては、携帯端末、携帯電話を含む端末装置が用いられる。
【００２０】
センサ部２４は、ユーザの掌から、ユーザの脈拍信号を検出し、データ測定部２２に脈拍検出信号を出力する。測定は、ユーザの掌の一部をセンサ部２４に載せることによって行われてもよいし、ユーザがユーザ端末装置２００を把持することによって行われてもよい。また、接触、もしくは把持によって、脈拍の検出が、自動的に開始するよう、センサ部２４が設定されることもできる。センサ部２４は検出した脈拍信号をデータ測定部２２に送信する。
【００２１】
着信部２３は他の端末装置から通話要求信号を受信した場合、及び、発呼部１３から発呼信号を受信した場合、ユーザに着信通知を行う。着信部２３は、例えば、ユーザ端末装置２００に内蔵されている図示しないモータを駆動して、同じくユーザ端末装置２００に内蔵されている図示しない振動子を振動させる。ユーザが着信部２３に接続している図示しない通話ボタンを押下することにより、振動は停止する。この後、通話部２５は、他の端末との間で通話を開始する。着信部２３は、セッションが確立していることを通知する通話信号を出力し、これをデータ送信部２０に出力することができる。
【００２２】
通話部２５は、マイクロフォン及びスピーカから構成され、着信部２３で他の端末装置から通話要求信号を受信した場合、通話を実現する機能を有する。
【００２３】
データ測定部２２は、センサ部２４から脈拍信号を受信し、単位時間当たりの拍数を計数し、計数した結果得られた１分間当たりの脈拍数である脈拍データをデータ送信部２０に、出力する。
【００２４】
データ送信部２０は、予定データ、脈拍データを図示しない記憶部に格納する。また、データ送信部２０は、予定データ、脈拍データを、管理装置１００のデータ管理部１１に送信する。
【００２５】
予定作成部２１は、測定頻度または測定日時および発呼アドレスまたは電話番号を指定する予定データをデータ送信部２０に出力する。
【００２６】
ＣＰ装置３００は、集計装置を介して、ユーザ端末装置２００から送信されたデータの解析を行い、助言を含む各種メッセージをユーザ端末装置２００に送信する。
【００２７】
図５は、予定データを受信してから、ＣＰ装置３００に脈拍データを送信するまでの、管理装置１００の処理を示すフローチャートである。
【００２８】
データ管理部１１はユーザ端末装置２００のデータ送信部２０から、予定データを受信し、発呼決定部１２に出力する（Ｅ）。発呼決定部１２は予定データを取得する（ＳＨ−１）。
【００２９】
発呼決定部１２は、データ管理部１１が取得した予定データから、発呼日時、対象測定時間帯、総発呼回数Ｎを計算する（ＳＨ−２）。
【００３０】
発呼決定部１２は、計算の結果得た、複数の発呼日時及び対象測定時間帯を、ＩＤを付して関連付け、発呼予定テーブルに格納する。入力フラグには、この時点ではすべて“０”が入力されている。データ管理部１１がデータ入力を確認した場合に、“１”が入力される。
【００３１】
発呼決定部１２は、初回の発呼日時ＩＤを設定し、発呼日時ＩＤであるＨＫに初回の発呼日時ＩＤであるＨＫ０を設定する（ＳＨ−３）。図４の発呼テーブルを用いる場合は、発呼決定部１２は、ＨＫ０として“ＩＤ１”を設定する。
【００３２】
発呼決定部１２は、カレンダー機能により、現在日時をモニターし、その時点が、ＨＫが与える発呼日時ＩＤが有する発呼時刻より前か後かを判定する（ＳＨ−４）。
現在日時が、ＨＫが与える発呼時刻より後の場合（ＳＨ−４：ＹＥＳ）、発呼予定テーブルの入力フラッグが０か否かを判定する（ＳＨ−５）。入力フラッグが０ではない場合（ＳＨ−５：ＮＯ）、データ管理部１１は、総発呼回数Ｎから１を差し引く（ＳＨ−７）。発呼決定部１２はＮが１以上か否かを判定し（ＳＨ−８）、１以上である場合（ＳＨ−８：ＹＥＳ）、発呼日時ＩＤに１を加算し（ＳＨ−９）、ＳＨ−４からの処理を繰り返す。１より小さい場合（ＳＨ−８：ＮＯ）、発呼決定部１２は、データ管理部１１にＮ＜１を出力し（Ｄ）、データ管理部１１は保有する脈拍データをＣＰ装置３００に送信する。ＳＨ−５で、入力フラグが０の場合（ＳＨ−５：ＹＥＳ）、発呼決定部１２は、発呼部１３に発呼信号の発信を指示し（ＳＨ−６）、発呼部１３は、この指示を受けて発呼信号を送信する（Ａ）。発呼決定部１２は、データ管理部１１から、入力フラグに”1“が出力されているか否かを判定し（ＳＨ−１０）、出力されていない場合（ＳＨ−１０：ＮＯ）は待機する。受けている場合（ＳＨ−１０：ＹＥＳ）、発呼決定部１２はＳＨ−４からの処理を繰り返す（Ｆ）。
【００３３】
図６は、発呼信号を受けた場合の、ユーザ端末装置２００の処理を示すフローチャートである。このフローチャートは、図５のＡ以降の動作を表している。ユーザ端末装置２００の着信部２３は、発呼信号を受信する。着信部２３は、振動子を駆動することによって、ユーザ端末装置２００の筐体を振動させる（ＳＵ−１）。ユーザは、着信部２３に接続している通話ボタンを押下することによって、振動を停止させる。ユーザが筐体を把持することによって、センサ部２４はユーザからの脈拍を検知し、データ測定部２２に脈拍信号を出力する。データ測定部２２は、単位時間当たりの脈拍数を測定する（ＳＵ−２）。データ送信部２０は、データ測定部２２から出力された脈拍データを、記憶部に保存し、所定のタイミングで管理装置１００のデータ管理部１１に送信する（ＳＵ−３、Ｂ）。
【００３４】
図７は、管理装置１００のデータ管理部１１の処理を示すフローチャートである。データ管理部１１は、ユーザ端末装置２００のデータ送信部２０から予定データを受信し（ＳＫ−１）、発呼決定部１２にこれを出力する（Ｅ）。データ管理部１１は、データカウント部に、データ数初期値としてｎ＝０を設定する（ＳＫ−２）。データ管理部１１は、ユーザ端末装置２００から送信された脈拍データの入力の有無を判断し（ＳＫ−３）、データの入力を確認した場合（ＳＫ−３：ＹＥＳ）、データと受信日時とを測定データテーブルに格納する（ＳＫ−４）。この時、データカウンタ部の数値はデータ数ｎに１が加算されたものとなっている。データ管理部１１は、ｎの加算時に、データテーブルの最新の受信日時を検出し、発呼予定テーブルの、最新受信日時が属する対象測定時間帯のＩＤが有する入力フラグを１とし（ＳＫ−５）、発呼決定部１２にこれを出力する（ＳＫ−６、Ｃ）。データ管理部１１は、発呼決定部１２から総発呼回数Ｎ＜１が出力されているか否かを判断する（ＳＫ−６）。Ｎ＜１が出力されている場合（ＳＫ−６：ＹＥＳ）、データ管理部１１は、処理を完了し、ＣＰ装置３００に脈拍データを送信する。Ｎ＜１が出力されていない場合（ＳＫ−６：ＮＯ）、データ管理部１１は、ＳＫ−３からの処理を繰り返す。図６の発呼信号を受けて、脈拍データが送信される場合Ｂは、ＳＫ−４からの処理となる。
なお、Ｂは、図６におけるＢと接続しており、データ管理部１１が、データ送信部２０から、データの送信を受ける処理を示している。Ｄは、図５におけるＤと接続しており、発呼決定部１２から、Ｎ＜１が出力される処理を示している。
【００３５】
図８は、ユーザ端末装置２００、管理装置１００、ＣＰ装置３００間のデータのやりとりをシーケンスチャートで示したものである。図８において、それぞれ２つのＦ、Ｇは、互いが接続する関係であることを示している。
【００３６】
ユーザ端末装置２００の予定データ作成部２１は、予定データを作成し、ユーザ端末装置２００のデータ送信部２０に出力する（ＳＱ−１）。
【００３７】
データ送信部２０は、管理装置１００のデータ管理部１１に予定データを送信する（ＳＱ−２）。
【００３８】
データ管理部１１は、予定データを受信し（ＳＱ−３）、これを記憶部に格納し、発呼決定部１２に出力する（Ｅ）。データ管理部１１は、データ数の初期値をｎ＝０に設定する。（ＳＱ−４）。
【００３９】
以下、ＳＱ−５からＳＱ−１４はそれぞれ、図５のＳＨ−２からＳＨ−１１に対応するので、これらの処理に関する説明は省略される。
【００４０】
発呼決定部１２から、ＳＱ−９で発呼指示を受けた発呼部１３は、ユーザ端末装置２００の指定された電話番号に、発呼信号を送信する（ＳＱ−１５、Ａ）。ユーザ端末装置２００の着信部２３は、発呼信号を受信する（ＳＱ−２１）。ＳＱ−２２からＳＱ２３は、図６のＳＵ−２からＳＵ−３に対応する。
【００４１】
ＳＱ−２３で、ユーザ端末装置２００のデータ送信部２０から、管理装置１００のデータ管理部１１に送信された脈拍データは管理装置１００のデータ管理部１１に入力される（Ｂ）。
【００４２】
以下、ＳＱ−１６からＳＱ−２０はそれぞれ、図５のＳＫ−３からＳＫ−７に対応するので、これらの処理に関する説明は省略される。
【００４３】
入力フラグに“１”を入力した場合、データ管理部１１は、ＳＱ−１９で、発呼決定部１２に、これを出力する（Ｃ）。
【００４４】
ＳＱ−２０で、データ管理部１１が、発呼決定部１２からＮ＜１の出力されている（Ｄ）、と判断した場合、データ管理部１１は、データ送信部１０に、格納している全データを出力する。データ送信部１０は、このデータをＣＰ装置３００に送信する（ＳＱ２４）。ＣＰ３００は、このデータを受信して（ＳＱ−２５）解析し、助言をユーザ端末装置２００の着信部２３に送信する。
【００４５】
管理装置１００からの発呼とは別に、他の端末装置から、通話を受信して（ＳＱ−２６）、脈拍測定が実行された場合（ＳＱ−２７）も、管理装置１００のデータ管理部１１にデータが送信される。この場合、データ送信部２０は、記憶した脈拍データを記憶部に格納し（ＳＱ−２８）、通話が終了したか否かを、着信部２３が出力する通話信号の有無によって判断する（ＳＱ−２９）。データ送信部２０は、通話が終了した時点で、脈拍データを、データ管理部１１に送信する（ＳＱ−３０）。
【００４６】
次に説明する例は、図２の予定データにより、脈拍数の測定を行なう場合であり、第１の実施形態を具体的に説明するものである。ユーザ端末装置２００は、頻度として、一日一回、２０１１年１月１日から２０１１年１月１６日まで、脈拍データを測定する予定を、開始日である２０１１年１月１日より前に、管理装置１００のデータ管理部１１に送信する。
【００４７】
データ管理部１１は、この予定データを受取り、記憶部に格納するとともに、データカウント部に初期値０を設定する。
【００４８】
発呼決定部１２は、測定頻度が１日１回であり、測定回数が１６であることから、１日１回、合計１６回（総発呼回数Ｎ＝１６）の発呼を決定する。発呼決定部１２は、発呼の時刻を、ユーザ端末装置２００から指定されている場合は、その時刻に決定し、指定されていない場合は、任意の時刻に決める。また、予定データに、送信日時が指定されている場合は、発呼部１３が、指定された送信日時を、発呼の時刻として設定してもよい。ここで説明する例は、発呼決定部１２が、発呼時刻を正午と決定したものである。
【００４９】
発呼決定部１２は、各発呼日時、対象測定時間帯、入力フラグの組み合わせに、ＩＤを付して、図４に示す発呼予定テーブルに記憶する。発呼決定部１２は、発呼日時ＨＫに、初回発呼日時のＨＫ０として、“ＩＤ１”を設定する。発呼決定部１２は、現在時刻が発呼日時であるか否かを判断し、発呼日時である1月１日正午以降である場合、発呼予定テーブルの該当する入力フラグの値を判定する。値が“０”の場合、発呼部１３に発呼信号を出力するよう、通知する。
【００５０】
発呼部１３は、発呼信号と、脈拍測定を促すメッセージをユーザ端末装置２００の指定された電話番号０１−２３４５−６７８９に向けて送信する。着信部２３は、発呼信号を受けてユーザ端末装置２００の筐体を、振動子を駆動することによって振動させ、ユーザに発呼信号の着信を知らせる。ユーザ端末装置２００のユーザが、着信部２３を押圧して振動を止めた後、センサ２４に触れることにより、脈拍が測定され、脈拍測定デ―タが、データ送信部２０に、記憶される。なお、ユーザの把持により、ユーザの掌がセンサ２４に触れる構造であり、この接触とともに、自動的に脈拍測定を開始する構造のユーザ端末装置２００の場合、脈拍測定を促すメッセージは不要である。データ送信部２０に記憶された脈拍データは、取得後、所定の時間を経て、自動的に管理装置１００のデータ管理部１１に送信される。データ管理部１１は、送信された脈拍データを、受信した日時と関連づけて、図３の測定データテーブルに格納する。
【００５１】
データ管理部１１のデータカウント部は、データ数を１加算する。また、データ管理部１１は、この加算時に、発呼予定テーブルの、ＩＤ１の行の入力フラグを“１”とする。
データ管理部１１は、発呼決定部１２に、入力フラグ“１”を出力する。
【００５２】
発呼決定部１２は、この出力を受けて、再び、発呼日時が、現在日時より後であるか否を判断する。現在日時は、発呼日時である1月１日正午以降であって、該当する入力フラグの値が１であるので、発呼決定部１２は、総発呼回数Ｎに１６から１を差し引いた１５を設定する。また、発呼決定部１２は、発呼日時に次のＩＤとして“ＩＤ２”を設定し、再び、現在時刻が発呼日時であるか否かの判断を行なう。以降、発呼決定部１２は、同様の処理をＮ＝０になるまで繰り返す。  発呼決定部１２は、総発呼回数Ｎが０になった時点で、データ管理部１１に、Ｎ＝０を出力する。
【００５３】
データ管理部１１は、Ｎ＝０を受けて、測定データテーブルに格納しているすべての脈拍データをＣＰ装置３００に送信する。これらの脈拍データのセットには、管理装置１００からの発呼により測定されたものと、ユーザ端末装置２００がそれ以外の契機（他の端末装置からの発呼、ユーザの自発的な測定）により測定したもの、との両方を含むことがある。
【００５４】
ＣＰ装置３００は、データを分析し、統計データを元に、ユーザへのアドバイスデータを作成する。ＣＰ装置３００は、このアドバイスをユーザ端末装置２００にメールで送信し、ユーザは、ユーザ端末装置２００の画面でこれを参照することができる。ＣＰ装置３００は、統計データを、Ｗｅｂサイトに公開することもでき、ユーザは、ユーザ端末装置２００から、このＷｅｂサイトにアクセスすることにより、統計データをも参照することができる。ユーザ端末装置２００としては、携帯電話を用いることも可能である。
【００５５】
なお、本実施形態では、ＳＱ−２９において、通話が終わっているか否かの判断を行っているが、所定の時間が経過しているか否かの判断でも構わない。
【００５６】
また、本実施形態では、脈拍データという生体データを送信しているが、生体データとして、体温データが送られることも可能である。この場合は、体温センサが、センサ部２４に用いられる。
【００５７】
また、生体データ以外のデータが、測定対象となってもよい。例えば、気温、湿度を含む気象データが、送信されることも可能である。
【００５８】
また、本実施形態では、発呼決定部１２と発呼部１３に督促の決定に係る機能と督促の機能とを分担させているが、必ずしも分担させる必要はなく、発呼決定部１２または発呼部１３のどちらか１つが、両方の機能を有する構成であってもよい。
【００５９】
また、本実施形態では、予定データがアクセスの頻度を指定しているが、予定データは、アクセスのタイミングを指定してもよい。この場合、発呼決定部は、指定された発呼日時以降に、アクセスがない場合に、督促信号を送るように、発呼日時を決定する。
【００６０】
また、本実施形態では、一台のユーザ端末装置２００から、管理装置１００のデータ管理部１１に測定データが送られる場合に限定して説明したが、管理装置１００は、複数のユーザ端末装置２００に並行して対応することが可能である。その場合、管理装置１００の発呼部１３は、それぞれのユーザ端末装置２００が指定したアドレスまたは電話番号に督促信号を送ることができる。
【００６１】
また、ユーザ端末装置２００として、把持により脈拍測定を開始する機能を有し、脈拍データが自動的に管理装置１００に送信されるよう設定された、通話機能及び電子メール機能を有する携帯電話を用いることができる。この場合は、発呼部１３が、督促信号として、携帯電話に電子音もしくは振動を発生させる通話要求信号を送信することにより、ユーザが携帯電話を把持する行為により、管理装置１００に、脈拍データの送信が行われる。また、携帯電話がメール機能を備えている場合、督促信号は、督促メールの送信であってもよい。
【００６２】
上記の実施形態によれば、督促部１４が、ユーザ端末装置２００に、発呼信号を送って脈拍データの測定を促し、ユーザは携帯電話を把持して、自らの生体データを測定するので、ユーザがことさらに意識することなく、高い確度で測定が実施されることが可能である。
（第２の実施形態）
第１の実施形態では、データ送信部２０は、脈拍データを、測定結果を記憶部に格納し、その後、所定の時間を経て管理装置１００に送信した。第２の実施形態では、タスク間で１つのＣＰＵをタイムシェアリングするマルチタスクを可能とするＣＰＵを具備したユーザ端末装置２００が用いられる。構成は第１の実施形態と同じであるが、データ送信部２０は、通話や、インターネットの実行中であっても、これらの実施と並行して、データ管理部１１に脈拍データを送信する点が、第１の実施形態とは異なる。図９は、第２の実施形態における、ユーザ端末装置２００、管理装置１００、ＣＰ装置３００間のデータのやりとりをシーケンスチャートで示したものである。ＳＱ１〜ＳＱ２８は、第１の実施形態のシーケンスチャートを表す図８と同じである。第２の実施形態の場合、ＳＱ２９の判断シーケンスがなく、データ送信部２０は、通話の終わりを待つことなく、測定部が出力した脈拍データを、データ管理部１１に送信する（ＳＱ３０）。この場合、データ管理部１１が記録する受信日時は、測定日時とはほぼ一致する。
【００６３】
本実施形態では、通話の場合について説明したが、インターネットに接続している場合も、送信部２０は、その終了を待つことなく、脈拍データをデータ管理部１１に送信することができる。
【００６４】
第２の実施形態では、第１の実施形態に較べて、測定時刻と受信時刻の差が小さい。したがって、第２の実施形態によれば、所定の規則に基づく定期的な測定を、確実に実施することを可能とすることに加えて、測定時刻を重視する定期的な測定において、より精度の高い測定データが得られる。
（第３の実施形態）
図１０は本発明の第３の実施形態を示すブロック図である。本実施形態は、把持しているユーザのデータを測定する携帯端末から、測定データを受信する予定日時を記憶するデータ管理部１１と、この予定日時に測定データを受信しないと、上記の携帯端末に督促信号を送信する督促部１４、を備える管理装置１００である。
【００６５】
本実施形態によれば、所定の規則に基づく定期的な測定を、確実に実施することが可能である。
【符号の説明】
【００６６】
１０    データ送信部
１１    データ管理部
１２    発呼決定部
１３    発呼部
１４    督促部
２０    データ送信部
２１    予定作成部
２２    データ測定部
２３    着信部
２４    センサ部
２５    通話部
１００    管理装置
２００    ユーザ端末装置
３００    コンテンツプロバイダ装置
【図１】
0005866793.tif 000002
【図２】
0005866793.tif 000003
【図３】
0005866793.tif 000004
【図４】
0005866793.tif 000005
【図５】
0005866793.tif 000006
【図６】
0005866793.tif 000007
【図７】
0005866793.tif 000008
【図８】
0005866793.tif 000009
【図９】
0005866793.tif 000010
【図１０】
0005866793.tif 000011