運動量管理システム、運動量管理サーバおよび運動量管理プログラム
【課題】１週間や数ヶ月あるいはこれ以上といったある程度長い期間を対象として理想とする運動量を達成させることのできる運動量管理システム、運動量管理サーバおよび運動量管理プログラムを得る。
【解決手段】運動量の管理を行おうとするユーザ１１１は携帯端末１１２と歩数計１１３を所持する。サービスセンタアプリケーションサーバ１０３はユーザ１１１の設定した基本プランに対して、歩数計１１３から歩数に関する情報を得ながら携帯端末１１２に対して過去に達成した運動量に対する過不足を演算して、ウォーキング等の運動のための次回の推奨プランを提示したり、休日における運動を兼ねた旅行等のプランを提示することで、運動量から見た比較的長い期間の健康管理を行う。
【解決手段】運動量の管理を行おうとするユーザ１１１は携帯端末１１２と歩数計１１３を所持する。サービスセンタアプリケーションサーバ１０３はユーザ１１１の設定した基本プランに対して、歩数計１１３から歩数に関する情報を得ながら携帯端末１１２に対して過去に達成した運動量に対する過不足を演算して、ウォーキング等の運動のための次回の推奨プランを提示したり、休日における運動を兼ねた旅行等のプランを提示することで、運動量から見た比較的長い期間の健康管理を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、個人の運動量を管理する運動量管理システム、運動量管理サーバおよび運動量管理プログラムに係わり、特に継続的な運動を視野に置いた運動量管理システム、運動量管理サーバおよび運動量管理プログラムに関する。
【背景技術】
【０００２】
健康の維持や増進に多くの者が関心を持っており、また実践に勤めている。歩数計を使用してウォーキングの際の歩数の一日の目標を定めて健康を維持しようとする者も多い。ところで、歩数計を使用した場合、歩幅の広い人と狭い人で同じ歩数でも歩いた距離が異なってくる。したがって、歩幅補正手段を備えることで、正確な歩行距離を算出する工夫が行われている（たとえば特許文献１参照）。この第１の提案によれば、出発地から目標地まで移動したときの歩数計数手段の歩数計数値と地図上で計測した距離の２つの値から、そのユーザの歩幅を求めて、これに歩数を掛け合わせることによって正確な歩行距離を算出するようにしている。
【０００３】
そこで、このように歩数計によって歩行距離が算出できる点を利用して、ＧＰＳ（Global Positioning System）で測定ができないエリア内での位置情報を求めようとする第２の提案も行われている。
【０００４】
また、歩数計をこのような距離の測定や位置情報の特定に利用するだけでなく、前記したような健康管理に利用する提案も行われている（特許文献３参照）。この第３の提案では、ユーザ自身の健康管理に必要な情報を参照してその者が健康管理のために採るべき経路を案内するものである。具体的には個人の日常の健康管理に必要な情報を管理情報記憶手段に記憶しておき、地図情報記憶手段、自己位置検出手段および管理情報記憶手段から得られる情報に基づいて、そのユーザのための推奨経路を探索するようにしている。そして、例えば、喘息気味のユーザであれば空気の悪い場所を通らない経路を選択したり、運動不足気味のユーザであれば所定距離以上の徒歩を要するコースを選択するようにすることで、健康管理を行っている。
【特許文献１】特開平１０−０３８６０２号公報（第００１５段落、図１）
【特許文献２】特開２００１−２２７９７３号公報（第００１９段落、図２）
【特許文献３】特開平１０−１４８５３９号公報（第０００９、第００２５、第００２６段落、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
この第３の提案では１日にとるべき消費カロリの目標を定めて、これに応じた消費カロリとなるような推奨経路の検索を行っている。そして、日々の消費カロリが目標に達するようにすることで、ユーザの健康管理を行っている。ところが、仕事が忙しくて運動を行う時間がない日や、運動を行おうとしても悪天候でできない日がある。また、運動を行う時間があっても体調が不良でこれを断念せざるを得ない日もある。このように、運動の計画を行っても毎日これを順調に消化できるものではない。運動を１日単位に緻密にスケジュールしている場合には、一日でも予定を消化しないと、運動を継続する意味がなくなったような気がしたり、目標を達成できないような気がして継続意思の大きな障害となる場合が多い。
【０００６】
また、体脂肪計付の体重計や心拍計を取り付けた腕時計のような健康管理用器具が数多く売り出されており、その中には日々の測定データをコンピュータに送って、１週間や数ヶ月単位でデータを収集して健康管理を行うようにしたものも登場している。このような健康管理用器具では、たとえば東海道を模擬的に歩いて制覇するといったようなプログラムを備えており、ユーザに比較的長期の運動を薦めて体重や体脂肪の減少を図るといったものが多い。ところが、このようなプログラムでは最終目標となる距離は定まっていても、目標達成のための期間は定まっていない。したがって、健康に対して大きく寄与しないような少量ずつ運動を行うユーザもいれば、１日当たりの歩く量を過度に設定して体の過度の負担を招くユーザもいる。
【０００７】
この結果として、従来のいずれの場合でも歩数計や体重計を購入する時点で運動に対する意欲はあるものの、個人個人の方向性が定まらず、運動を適正な量行いながら長期的に継続することができない場合が多かった。
【０００８】
そこで本発明の目的は、１週間や数ヶ月あるいはこれ以上といったある程度長い期間を対象として理想とする運動量を達成させることのできる運動量管理システム、運動量管理サーバおよび運動量管理プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
本発明では、（イ）個人の運動量を測定する運動量測定手段と、（ロ）前記した個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信し、運動量目標値設定手段によって設定された目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、（ニ）この過不足演算手段の演算結果を表示する運動量過不足表示手段とを運動量管理システムに具備させる。
【００１０】
すなわち本発明では、管理の対象となる個人のある期間における運動量の目標値を設定し、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信して、目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する。そして、この過不足演算手段の演算結果を運動量過不足表示手段に表示することで、運動が不足したときにはこれを補うように運動を行えるようにして、あるいは平日に仕事で忙しいような場合には、休日にその分の運動を行えるようにして、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１１】
また、本発明では、（イ）個人の運動量を測定する運動量測定手段と、（ロ）前記した個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間の運動量を逐次受信し、運動量目標値設定手段によって設定された目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、（ニ）この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、（ホ）この運動計画作成手段の作成した運動計画を前記した個人の見うる装置に表示する運動計画表示手段とを運動量管理システムに具備させる。
【００１２】
すなわち本発明では、管理の対象となる個人のある期間における運動量の目標値を設定し、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信して、目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する。そして、この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成してその個人の見うる装置に表示することにして、運動が足りなかったような場合には運動のためのプランをその都度変更できるようにしている。また、たとえば平日に仕事で忙しいような場合には、休日にその分の運動を行えるプランを提示して、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１３】
また、本発明では、（イ）個人のある期間における運動量の目標値を取得する運動量目標値取得手段と、（ロ）前記した個人の運動量を運動量の測定を行う運動量測定手段が測定した前記した期間よりも短い区間で逐次受信する運動量受信手段と、（ハ）運動量目標値取得手段によって取得された目標値を期間の終了時に達成できるための運動量受信手段が運動量をそれぞれ受信した時点における運動量の過不足を演算する過不足演算手段と、（ニ）この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、（ホ）この運動計画作成手段の作成した運動計画を前記した個人の見うる装置に送信してこれに表示させる運動計画表示用送信手段とを運動量管理サーバに具備させる。
【００１４】
すなわち本発明では、個人の運動の管理を行う運動量管理サーバを設け、これに個人のある期間における運動量の目標値を取得させると共に、その個人の運動量を運動量測定手段が測定した前記した期間よりも短い区間で逐次受信するようにし、運動量目標値取得手段によって取得された目標値を期間の終了時に達成できるようにするために運動量をそれぞれ受信した時点における運動量の過不足を演算して、この演算結果を基にして次の区間あるいはこれ以降の運動計画を作成するようにしている。そして、作成した運動計画を前記した個人の見うる装置に送信することで、運動が足りなかったような場合には運動のためのプランをその都度変更できるようにしている。また、たとえば平日に仕事で忙しいような場合には、休日にその分の運動を行えるプランを提示して、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１５】
また、本発明の運動量管理プログラムは、（イ）個人の運動量を測定する運動量測定手段と前記した個人の所持する通信端末との間で通信を行う運動量管理のための管理サーバのコンピュータに、（ロ）前記した個人のある期間における運動量の目標値を通信端末から取得する運動量目標値取得処理と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、（ニ）運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、（ホ）この過不足演算処理の演算結果を通信端末に送信して表示させる運動量過不足表示用送信処理とを実行させることを特徴とする。
【００１６】
すなわち本発明では、運動量管理プログラムとして、運動量管理のための管理サーバのコンピュータに、個人のある期間における運動量の目標値を通信端末から取得する運動量目標値取得処理と、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、この過不足演算処理の演算結果を通信端末に送信して表示させる運動量過不足表示用送信処理とを実行させることで、個人がその運動量を測定する運動量測定手段と、管理サーバとの通信を行う通信端末を所持することで運動量の管理を行えるようにしている。すなわち、運動が不足したときにはこれを補うように運動を行えるようにして、あるいは平日に仕事で忙しいような場合には、休日にその分の運動を行えるようにして、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１７】
また、本発明の運動量管理プログラムは、（イ）個人の運動量を測定する運動量測定手段と前記した個人の所持する通信手段との間で通信を行う運動量管理のための管理サーバのコンピュータに、（ロ）前記した個人のある期間における運動量の目標値を通信手段から取得する運動量目標値取得処理と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、（ニ）運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、（ホ）この過不足演算処理の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成処理と、（へ）この運動計画作成処理で作成した運動計画を通信手段に送信して表示させる運動計画表示用送信処理とを実行させることを特徴とする。
【００１８】
すなわち本発明では、運動量管理プログラムとして、運動量管理のための管理サーバのコンピュータに、その個人のある期間における運動量の目標値を通信手段から取得する運動量目標値取得処理と、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、この過不足演算処理の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成処理と、この運動計画作成処理で作成した運動計画を通信手段に送信して表示させる運動計画表示用送信処理とを実行させることで、個人がその運動量を測定する運動量測定手段と、管理サーバとの通信を行う通信端末を所持することで運動量の管理を行えるようにしている。すなわち、運動が不足したときにはこれを補うように運動を行えるようにして、あるいは平日に仕事で忙しいような場合には、休日にその分の運動を行えるようにして、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【発明の効果】
【００１９】
以上説明したように本発明によれば、個人が従来から勘で行っていた比較的長期における運動量の配分および減量等の健康管理のための運動計画を、その時々の運動量をチェックするだけでなく、その個人が行った過去の運動の実績から将来の運動の推奨プランや現時点までの運動の過不足を提示することにしたので、運動ができない事情が発生したときに無理に運動したり、無理なスケジュールを実行することによる運動計画の短期間での挫折や健康の悪化を防止することができる。しかも、その時々の運動量を消化するプランが具体的に提示されることで、必要な運動量を比較的容易に確保することができる。
【００２０】
また、平日の運動量が不足したようなときには、単に休日の運動を強制するのではなく、運動を伴った旅行等のプランを提示し、レジャーの要素を加味した健康管理の提案が行われるので、運動量の管理を長期間無理なく継続することができる。特に通信端末を多くの個人が所持するようになっているので、運動量の管理を行う管理サーバとの通信できめ細かな運動量管理を実現できる本発明の意義は大きい。
【発明を実施するための最良の形態】
【００２１】
以下実施例につき本発明を詳細に説明する。
【実施例１】
【００２２】
図１は、本発明の一実施例における運動量管理システムの構成を表わしたものである。この運動量管理システム１００は、インターネット１０１と、モバイルネットワーク１０２からなる通信ネットワークを利用するようになっている。インターネット１０１には、本実施例で経路ナビゲーションサービスを提供するサービスセンタアプリケーションサーバ１０３と、この要請によって各種の情報を提供する幾つかのサーバが接続されている。本実施例で使用されるサーバとしては、地図に関する情報を提供する地図情報サーバ１０４と、交通機関、すなわち各種の乗物に関する情報を提供する乗物情報サーバ１０５と、天候に関する情報を提供する天候情報サーバ１０６がある。これ以外のサーバが運動量管理システム１００を構成してもよい。また、地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６等のサーバはこれらの一部または全部が統合されたサーバであってもよい。
【００２３】
モバイルネットワーク１０２は、移動体と無線通信を行うネットワークである。本実施例では簡略化した例を示すために１つのモバイルネットワーク１０２がユーザ１１１の携帯端末１１２と歩数計１１３のそれぞれと接続される構成となっている。ここで、携帯端末１１２とは、携帯電話機、ＰＨＳ（Personal Handy-phone System）あるいは通信カードを取り付けるか通信機能を内蔵したＰＤＡ（Personal Digital Assistant）や携帯型のパーソナルコンピュータといった携帯可能な通信端末をいう。本実施例の携帯端末１１２はＤＧＰＳ（Differential Global Positioning System）機能を備えており、位置測定用人工衛星１１４を複数使用して現在位置の取得が可能になっている。
【００２４】
図２は、本実施例で使用される携帯端末の構成の要部を表わしたものである。この携帯端末１１２は、本実施例では携帯電話機であり、ＣＰＵ１２１を内蔵している。ＣＰＵ１２１はデータバス等のバス１２２を介して装置内の各部と接続されている。このうち、ＲＯＭ（リード・オンリ・メモリ）１２３は制御プログラムを格納するものであり、必要に応じてその内容が書き換えられるようになっている。ＲＡＭ（ランダム・アクセス・メモリ）１２４は作業用メモリとしての役割を持っている。表示部１２５は、液晶あるいは有機ＥＬディスプレイ（organic electroluminescence display）からなっている。通信制御部１２６は、図１に示したモバイルネットワーク１０２の図示しない基地局と無線通信を行うようになっている。ＤＧＰＳ通信部１２７は、図１に便宜的に１台のみ示した位置測定用人工衛星１１４や図示しない基準局からＤＧＰＳ補正情報を受信して、携帯端末１１２の現在位置を算出するようになっている。
【００２５】
地磁気センサ１２８は、地磁気を検出することで現在位置における方位を電子的に得るようになっており、電子コンパスを実現している。加速度センサ１２９は、２軸あるいは３軸の加速度を検出するものであり、ユーザ１１１の動作を検出することができる。脈拍センサ１３０は、図示しない発光ダイオードが発する赤外線の反射光を、同じく図示しないフォトディテクタで検出し、血流の変化を測定するようになっている。温度センサ１３１は、ユーザ１１１の体温や気温を測定するのに使用される。高度計１３２は、たとえば気圧の変化によって高度を測定するものである。この高度計１３２はユーザ１１１が歩行を行っているときの歩いた距離との関係で平坦地を歩行したか傾斜地を歩行したかを判別することができるだけでなく、高度の測定結果はＤＧＰＳによる位置測定の精度の向上のためにも使用することができる。操作部１３３は、ダイヤルキー等の各種キーおよびニューロポインタ（登録商標）等のポインティングデバイスから構成されており、ユーザ１１１が各種データを入力したり、必要な指示を入力することができるようになっている。
【００２６】
図３は、本実施例で使用される歩数計の概要を表わしたものである。歩数計１１３は、同じくＣＰＵ１４１を備えており、バス１４２を介して各部と接続されている。ＲＯＭ１４３はこの歩数計１１３の各種機能を実現するための制御プログラムを格納しており、ＲＡＭ１４４は作業用メモリとして使用されている。加速度センサ１４５はユーザ１１１の動きに伴う歩数計１１３の上下方向あるいは水平方向の加速度の変化を検出して歩数の計数に利用される。表示部１４６は、歩数の計数結果等の所定のデータを表示する部分であり、携帯端末１１２で説明したように液晶あるいは有機ＥＬディスプレイで構成されている。通信制御部１４７は、歩数の検出結果を予め設定した時刻あるいはユーザ１１１の指示によって、図１で示したモバイルネットワーク１０２を経由して、インターネット１０１上のサービスセンタアプリケーションサーバ１０３に送出するための通信を行う。操作パネル１４８は、歩数のクリアや歩幅の入力等のようにユーザ１１１の入力操作のために使用される。
【００２７】
歩数計１１３は、次に説明する運動量管理システムの一部として活用できるが、ユーザ１１１はこれを本実施例のシステムと切り離して使用することも可能である。たとえば、１日の歩行のカロリを計算して、表示部１４６に表示することができる。なお、ユーザ１１１の所持する携帯端末１１２が図２に示したように加速度センサ１２９を備え、この結果、歩数計としての機能を実現できる場合には、歩数計１１３を必ずしも所持する必要はない。
【００２８】
図１に示したサービスセンタアプリケーションサーバ１０３、地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６は、それぞれ通信機能を持ったパーソナルコンピュータと実質的に同一の機能を備えている。したがって、これらのハードウェアの説明は省略する。
【００２９】
サービスセンタアプリケーションサーバ１０３は、運動量管理システム１００をユーザ１１１に提供する事業者が管理するものであり、次に示す各種データをインターネット１０１あるいはモバイルネットワーク１０２を介して取得するようになっている。
（１）ユーザ１１１が予め登録した歩数計１１３が送信した歩数情報（歩数のカウント値）
（２）モバイルネットワーク１０２に接続された携帯端末１１２または図示しないパーソナルコンピュータ等の情報処理装置からユーザ１１１が入力した基本データ等の各種のデータ。ここでユーザ１１１が入力した基本データとは、たとえば運動量管理システム１００の適用を行おうとするユーザ１１１の住所、最寄のバス停、鉄道の最寄駅、勤務先の住所、勤務先の最寄のバス停あるいは最寄駅、１日の目標となる歩数、メールアドレス、通常の出社時刻、通常の退社時刻、帰宅後あるいは休日の散歩計画を一例として挙げることができる。ここで１日の目標とは、ある程度の長い期間に対する目標値を１日に割り算して平均化したものをいう。もちろん、平日における１日の目標と、休日における１日の目標が異なってもよいが、これはある期間に達成すべき運動量を歩数に換算し、１日当たりの値に直したものをウォーキング等の運動に割ける時間の割合を考慮して調整したものと考えることができる。
（３）携帯端末１１２から送られてくる位置情報
（４）携帯端末１１２から送られてくるユーザ１１１の帰宅情報
【００３０】
一方、地図情報サーバ１０４は、地図についての詳細なデータベースを有しており、ＤＧＰＳによる最良で１メール程度の精度の位置情報を基にした位置の問い合わせに対して、対応する地図情報の回答を行うようになっている。また、乗物情報サーバ１０５は、全国各地の鉄道、バス、ケーブルカー等の情報源にリンクして、これらの乗物の時刻表、料金、路線、指定席の有無等の問い合わせに対して回答を行うようになっている。天候情報サーバ１０６は、ＤＧＰＳ等による位置情報と日時の指定を行った問い合わせに対して天候、温度、湿度、日の出、日の入り、満潮の時刻および波の高さ等の気象情報を回答するようになっている。
【００３１】
サービスセンタアプリケーションサーバ１０３は、このような地図情報サーバ１０４、乗物情報サーバ１０５あるいは天候情報サーバ１０６と通信を行いながら、ユーザ１１１に推奨する推奨プランを複数算出して、携帯端末１１２の表示部１２５に表示する。このとき、ユーザ１１１の所持する携帯端末１１２から送られてくる各種のセンサ情報も参考にされる。センサ情報とは、たとえばＤＧＰＳ通信部１２７による位置情報、温度センサ１３１によるそのときの温度、高度計１３２による現在位置の高度といった情報である。
【００３２】
ここで、推奨プランとは、基本プランを基にしてユーザにそれぞれの時点で提示されるプランである。推奨プランでは、たとえば地図上で出発点と終点を示したナビゲーションシステムの対象となるコースと、そのコースでユーザ１１１が歩行する区間での必要とする歩数、そのコースで出発点から終点に辿り着くまでの予想時間、そのコースの一部に交通機関を利用する場合の電車、バス等の乗り降りの時刻および料金を示した乗車情報、季節や天候を考慮した優先度、平均的な消費カロリ、想定される年齢層が示される。推奨プランには、該当するコースで出発点から終点に辿り着くまでに現われる代表的な景色の写真やウエブ上でのリンク先が添付されていてもよい。これらユーザ１１１の選択対象となる推奨プランは、推奨プラン概要情報として予め指定された送付先に対して、図２で示す通信制御部１２６によって電子メールで送信されるようになっている。
【００３３】
ユーザ１１１は、操作部１３３を用いて携帯端末１１２に先に説明した基本データを入力すると共に、これらを必要に応じて修正する。そして、通信制御部１２６を使用してサービスセンタアプリケーションサーバ１０３に送信する。また、サービスセンタアプリケーションサーバ１０３からユーザ１１１の入力したデータに対する各種の対応情報が電子メールで携帯端末１１２に送られてきた場合には、これらを通信制御部１２６で受信して、表示部１２５に表示する。このうち、サービスセンタアプリケーションサーバ１０３から幾つかの推奨プランが送られてきた場合には、これを表示部１２５に具体的に表示して、ユーザ１１１の選択を促す。そしてユーザ１１１の選択した内容を再度、サービスセンタアプリケーションサーバ１０３に送信して、プランの具体化を進めるようになっている。
【００３４】
地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６は、それぞれサービスセンタアプリケーションサーバ１０３からのインターネット１０１を介して行われる問い合わせに対して、運動量管理システム１００で必要とされ、あるいは有効活用される各種情報を回答（提供）する。この際に、事前に必要に応じて作成されたアプリケーションインターフェースプログラムがサービスセンタアプリケーションサーバ１０３、地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６で動作する。ここで各種情報とは、地図情報、経路情報、乗り物時刻表情報、乗り換え案内、道路鉄道情報、天候情報、花粉情報、災害情報、健康情報、観光情報、旅行情報、宿泊情報、ニュース情報、占い情報等の情報をいう。
【００３５】
ここには、本実施例で使用される地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６といった限定的なサーバの本来のサービスを超えて将来、新しいサーバの追加によってサービスされる有益な情報が含まれていてもよいことは当然である。たとえば、地磁気センサ１２８の出力を用いた電子コンパス機能による進路のトレース機能の提供や、加速度センサ１２９の出力を用いた経路における微細なアップダウン情報の提供、ＤＧＰＳ通信部１２７の出力する位置情報からユーザの現在いる場所を含めた狭い範囲内でのピンポイント天候情報、経路が国境に近い山岳部等の危険地帯の場合における経路内治安情報、電車やホームにおける予想される利用時間における混雑度情報である。また、携帯端末１１２に脈拍センサ１３０の他にオプションとして各種の医療検査装置を取り付けた場合には、体温、脳波、心拍数、心電波形、各種の血中濃度等のユーザ１１１のリアルタイムな体調情報をサービスセンタアプリケーションサーバ１０３が受け取って、医療サーバともいうべきものに送り、ここから得られるデータを参考にして推奨プランを設定したり、あるいはユーザ１１１の選択したプランの実行時にこれを増強方向あるいは抑制方向に修正したり、場合によってはプランの実行そのものを停止させる指示も行われる。
【００３６】
次に運動量管理システム１００の実際の運用を説明する。
【００３７】
図４は、ユーザが携帯端末を使用して運動量管理システムを利用する場合の携帯端末の処理の概要を表わしたものである。図１および図２と共に説明する。まず、サービスのエンドユーザ（最終利用者）としてのユーザ１１１は、携帯端末１１２をインターネット１０１上のサービスセンタアプリケーションサーバ１０３に接続して（ステップＳ２０１）、これとの間で所定の認証手続きを行う（ステップＳ２０２）。ユーザ１１１がまだこのシステムの会員でない場合には、事前に会員登録を行って認証のためのユーザＩＤ（Identification）およびパスワードを発行させる手続きを行っておく。この会員登録の際に、ユーザ１１２は先に示した個人の固有情報（ユーザ１１１の住所、最寄のバス停、鉄道の最寄駅、勤務先の住所、勤務先の最寄のバス停あるいは最寄駅、メールアドレス、通常の出社時刻、通常の退社時刻、帰宅後あるいは休日の散歩計画等の情報）をサービスセンタアプリケーションサーバ１０３に登録しておく。会員登録は、ユーザ１１１の携帯端末１１２で行うこともできるが、図１に示していない自宅あるいはオフィスに配置されたパーソナルコンピュータを使用して行うことも可能である。
【００３８】
認証が成功したら携帯端末１１２にメニュー画面の情報がサービスセンタアプリケーションサーバ１０３から送られてきて表示部１２５に表示される（ステップＳ２０３）。ここで携帯端末１１２はユーザ１１１が新たなプランの作成の項目を選択するかプランの実施の項目を選択するかを監視している（ステップＳ２０４、Ｓ２０５）。ユーザ１１１が操作部１３３を操作して新たなプランの作成を指示した場合には（ステップＳ２０４：Ｙ）、プラン作成モードが実行される（ステップＳ２０６）。これに対して、決定したプランを実施する場合あるいは実施中である場合には（ステップＳ２０５：Ｙ）、プラン実施モードが実行される（ステップＳ２０７）。
【００３９】
＜サービス運用前の基本データの設定＞
【００４０】
図５は、図４で示したプラン作成モードの実行における携帯端末の処理の様子を表わしたものである。ユーザ１１１は、プラン作成モードで携帯端末１１２から今回実施するプランに関する基本データを入力する（ステップＳ２２１）。たとえば旅行中の健康管理であれば、旅行先の場所と１日の目標とする消費エネルギあるいは歩数計１１３を用いた歩数および実施期間を入力する。図３に示した歩数計１１３を使用せず、市販のその他の歩数計を使用する場合にはその旨を入力する。また、自宅とオフィスの間を往復する通勤日の健康管理であれば、その旨の場所の指定と１日の目標とする消費エネルギあるいは歩数計１１３を用いた歩数および実施期間を入力する。なお、会員登録の際に入力した個人の固有情報で今回変更するもの、あるいは変更可能なものがあれば、その内容も入力する。たとえば退社時刻が曜日によって異なったり、向こう数ヶ月間の残業の多少による退社時刻の予測が立てられれば、その内容をサービスセンタアプリケーションサーバ１０３の質問に答える形で携帯端末１１２から入力して送信する。この後、携帯端末１１２はサービスセンタアプリケーションサーバ１０３から基本プランが送られてくるのを待機する（ステップＳ２２２）。
【００４１】
＜基本プランの設定＞
【００４２】
図６は、サービスセンタアプリケーションサーバによる基本プランの設定処理の流れを表わしたものである。図１と共に説明する。サービスセンタアプリケーションサーバ１０３は、携帯端末１１２から基本データを受信すると（ステップＳ２４１：Ｙ）、そのユーザの固有情報と今回、健康管理のために実施するプランの実施地域および実施期間に関する得られたデータを基にして、地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの関係するサーバに関連情報を問い合わせる（ステップＳ２４２）。たとえば通勤日における健康管理であれば、そのユーザ１１１の自宅とオフィスの間の経路に関する情報および散歩計画の基となる経路に関する情報を地図情報サーバ１０４に問い合わせ、出社時刻、通常の退社時刻等における交通機関の情報を乗物情報サーバ１０５に問い合わせ、実施地域における実施期間での天候の長期予報と短期予報とを天候情報サーバ１０６に問い合わせる。
【００４３】
これらの関連情報が地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの関係するサーバから受信されたら（ステップＳ２４３：Ｙ）、これらの関連情報を基にして、たとえば経路、要する歩数、必要な時間からなる基本プランを複数算出する（ステップＳ２４４）。この際に、ユーザ１１１が指定した歩数を達成するために、たとえばバス通勤の場合であれば乗車するバス停を変更したり、電車の乗降駅を変更したり、散歩に割り当てる歩数との調整を行う。各種の組み合わせで、交通機関の経路案内の既存のアプリケーションソフトウェアのように複数の基本プランを作成する。作成された基本プランは該当するユーザ１１１の携帯端末１１２に送信される（ステップＳ２４５）。
【００４４】
図５に戻って携帯端末側の処理の説明を続ける。ユーザ側の携帯端末１１２ではステップＳ２２２でサービスセンタアプリケーションサーバ１０３から基本プランを受信すると（Ｙ）、これをその表示部１２５に表示する（ステップＳ２２３）。そして、複数の基本プランの中で実施すべきプランがあればこれをユーザ１１１が操作部１３３を使用して選択すると（ステップＳ２２４：Ｙ）、その選択内容を示す番号を送信する（ステップＳ２２５）。このとき、ステップＳ２２３で表示された基本プランが最終的なものとなる。そこでこの内容を携帯端末１１２の不揮発メモリ領域に格納して保存する（ステップＳ２２６）。
【００４５】
一方、ステップＳ２２３で表示部１２５に示された基本プランのいずれも最終プランとして選択の対象になり得ない場合には（ステップＳ２２４：Ｎ）、操作部１３３から修正が指示される（ステップＳ２２７：Ｙ）。そこで、この場合にはユーザ１１１が希望する修正内容をそのとき表示部１２５に表示された内容を指定する形で編集が行われる（ステップＳ２２８）。このようにして作成された修正内容は携帯端末１１２からサービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２２９）。
【００４６】
なお、ユーザ１１１の意図する基本プランがサービスセンタアプリケーションサーバ１０３にうまく伝達されず、修正が理想的に行われない場合には、この図には示していないがサービスセンタアプリケーションサーバ１０３側のオペレータにユーザ１１１が修正希望内容を作成して電子メールで送信し、人手による修正処理も可能である。ただし、この場合には基本プランの作成に時間を要したり、制御プログラムを用いて自動的にプランが作成される場合よりも人件費が掛かる分だけ課金が多く発生する場合がある。
【００４７】
再び図６に戻ってサービスセンタアプリケーションサーバ１０３側での基本プランの設定処理の様子を説明する。携帯端末１１２から修正内容が送られてきたら（ステップＳ２４６：Ｙ）、地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの修正内容に必要なデータを所持するサーバに修正のための関連情報の問い合わせが行われる（ステップＳ２４７）。たとえば、ある基本プランは大枠で賛成するが、その中の電車の一駅を歩いて歩数を伸ばすという箇所に対して、一駅先は急行が停車しない駅なのでバス停まで歩く距離を遠くした方がよいというユーザ１１１からの修正要求があったとする。この場合には、サービスセンタアプリケーションサーバ１０３がパスの路線図における各バス停の歩行距離を乗物情報サーバ１０５に問い合わせ、ここから目標とする歩数を満足させるバス停を探すことになる。
【００４８】
要求した関連情報が地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの該当する１または複数のサーバから得られたら（ステップＳ２４８）、サービスセンタアプリケーションサーバ１０３は基本プランを修正する（ステップＳ２４９）。このとき、修正の可能性が複数存在するときには、複数の基本プランが作成されて、これらのうちの１つをユーザ１１１に選択させる形にして、これらの基本プランを再び携帯端末１１２に送出する（ステップＳ２４５）。
【００４９】
図５のステップＳ２２５で説明したようにユーザ１１１が最適の基本プランを見つけてこれを選択した場合には、選択した旨の受信が行われる（ステップＳ２５０：Ｙ）。サービスセンタアプリケーションサーバ１０３はこの受信があると、ユーザ１１１が選択した番号の基本プランを決定内容として登録して（ステップＳ２５１）、この基本プランに参加する独立して制御を行うセンサに対してそれらの制御すべき内容を通知する（ステップＳ２５２）。歩数計１１３が独立してモバイルネットワーク１０２を経由して検出結果を通知するものとしてユーザ１１１がサービスセンタアプリケーションサーバ１０３に設定していたとする。この場合には歩数計１１３に対して期間と時間を指定して検出結果をサービスセンタアプリケーションサーバ１０３に通知する旨の制御内容が通知されることになる。このような歩数計１１３を使用せずに通信機能を備えない簡易な歩数計を使用する場合には、歩数計の検出結果はユーザ１１１がサービスセンタアプリケーションサーバ１０３の指示に従ってこれに送信することになる。ステップＳ２５２の処理が行われると、基本プランの設定処理が終了する（エンド）。なお、基本プランの修正が１回で終了しない場合には、ステップＳ２４６に示した修正内容の受信が所定の回数繰り返され、そのたびに修正された複数のプランの中の１つが最終的に選択されることになる。
【００５０】
＜基本プランによる１日目の実施＞
【００５１】
このようにして基本プランの設定が行われたら、ユーザ１１１は図５のステップＳ２２６で保存した基本プランに従って１日目は指示された経路による歩行を実施する。このとき、図１に示した歩数計１１３がユーザ１１１の歩行を記録する。図２に示した脈拍センサ１３０あるいはオプションで取り付けた各種のセンサもユーザ１１１の健康状態をチェックすることになる。
【００５２】
図７は、本実施例のユーザの自宅と会社の間の経路の概要を表わしたものである。ユーザ１１１の自宅１５１の傍にはＡ1バス停が存在し、Ａ10バス停との間にバス１５２が運行している。Ａ10バス停の傍に電車のＢ1駅があり、ここからＢ10駅まで急行電車１５３が走っている。Ｂ10駅から徒歩で５分弱の距離のところに勤務先のＣ会社１５４がある。自宅１５１の傍には公園１５５があり、ウォーキングを行うことができる。Ｃ会社１５４とＢ10駅まではアーケード付の商店街１５６があり、昼休みには食事をしたりウィンドウショッピングを行うことができる。また、雨の時にも傘をささずに歩くことができる。
【００５３】
図８は、このユーザの平日の基本プランを表わしたものである。図１に示したユーザ１１１は朝８時に図７に示した自宅１５１を出発し、８時５分発のバス１５２に乗車してＡ10バス停で降車して、傍のＢ1駅から急行電車１５３に乗る。そしてＢ10駅からＣ会社１５４まで歩いて行く。１２時から１３時までが昼休みであり、１７時３０分に業務が終了して、１８時５０分に自宅に帰る。着替えをして、１９時から３０分程度、公園１５５でウォーキングを行う。
【００５４】
図９は、歩数計の処理の様子を表わしたものである。歩数計１１３はサービスセンタアプリケーションサーバ１０３から制御内容が送信されてくると（ステップＳ２７１：Ｙ）、今まで格納されていた制御内容の該当する箇所を上書きして内容の更新を行うようになっている（ステップＳ２７２）。歩数計１１３のように独立してサービスセンタアプリケーションサーバ１０３との間の通信制御を行うセンサに対して送られる制御内容には、ステップＳ２５２（図６）で示した１つの基本プランに沿った通常のものと、状況の変化に対応して送ってくる臨時のものとがある。たとえば、心拍計が独立して通信制御されるセンサとして使用されている場合、通常は歩行等の運動期間が開始する前の心拍数がまずサービスセンタアプリケーションサーバ１０３に送信され、運動期間が終了した時点で運動中の平均値が次に送信される。ところが、運動前の心拍数が平常よりも高いような場合や、体温が平熱以上のような場合のように何らかの異常の発生が察知される場合には、心拍数の測定結果を送信時間間隔を狭めて繰り返し送信させるような臨時の制御内容がサービスセンタアプリケーションサーバ１０３から心拍計に送信され（ステップＳ２７１：Ｙ）、次に新たな制御内容が送られてくるまでの間、そのセンサは更新された制御内容で制御を行うことになる。
【００５５】
本実施例の歩数計１１３の場合、図６のステップＳ２５２で制御内容を受信したら、これを基にして測定を開始する日時が到来したかの監視（ステップＳ２７３）と、測定を終了する日時が到来したかの監視（ステップＳ２７４）を逐次行う。たとえばサービスセンタアプリケーションサーバ１０３から送られてきた制御内容が、以下のようなものであったとする。
【００５６】
（１）期間 ２００５年１０月１日から２００６年１月３１日まで。
（２）午前０時から正午の１２時まで測定を行って第１回の送信を行う。
（３）正午の１２時から帰宅した時刻の夕方１８時５０分までの測定を行って第２回目の送信を行う。
（４）公園でのウォーキングや家庭内の歩行の測定を行って、１日の終了する２４時に第３回目の送信を行う。
【００５７】
このような制御内容の場合、歩数計１１３は２００５年１０月１日の午前０時が到来すると測定開始日時になったので（ステップＳ２７３：Ｙ）、測定値を“０”にリセットして歩数の測定を開始する（ステップＳ２７５）。もちろん、ユーザ１１１が歩数計１１３を身につけておらず就寝中の場合には、朝起きるまでカウントは行われない。この後、同年１０月１日の正午になると、第１回目の測定終了日時となり（ステップＳ２７４：Ｙ）、今まで測定した測定値が読み取られ、サービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２７６）。この送信動作と平行して同年１０月１日の正午に測定値の読み取りが終了したら、午前中の測定値がリセットされて午後の測定が開始される（ステップＳ２７３：Ｙ、ステップＳ２７５）。そして、夕方１８時５０分になると、２回目の測定終了日時ということで（ステップＳ２７４：Ｙ）、正午の１２時から開始した測定値が読み取られ、サービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２７６）。そして再び測定値がリセットされて１日の終了する２４時までの測定が開始される（ステップＳ２７３：Ｙ、ステップＳ２７５）。この後、１日の終了する２４時に１日の最後の測定（３回目の測定）が終了して（ステップＳ２７４：Ｙ）、そのときの測定値がサービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２７６）。
【００５８】
歩数計１１３による２日目以降の測定も同様である。ただし、本実施例では前日の測定結果を次の日以降の測定に反映させるようにしている。したがって、１日目については、この例で示したように合計３回の送信を歩数計１１３が行う必要は必ずしもなく、１日の終了する２４時に１日の合計の測定値を送信するようにしてもよい。１日目について測定値の送信が３回行われたような場合、サービスセンタアプリケーションサーバ１０３はユーザ１１１に対応付けてこれらの測定値を受信すると、単純に加算して１日分の測定値とする。なお、サービスセンタアプリケーションサーバ１０３との通信機能を備えない簡易な歩数計を使用した場合、ユーザ１１１は携帯端末１１２に予め定めた時刻ごとに測定値を見てその結果を通知する。サービスセンタアプリケーションサーバ１０３からメールがそれぞれの時刻ごとに送信され、これに返答する形で測定値を知らせるようにしてもよい。
【００５９】
なお、上記のようなスケジュールの場合、ユーザ１１１は平日と土曜日あるいは日曜日等の休日で異なった行動を採る。すなわち、平日は通勤を行うが、休日はこれを行わない。しかしながら、ユーザ１１１の選択した基本プランでは１日３回の測定を行う場合にそれぞれの測定期間および測定結果の報告はすべての日で同一の時刻でよいということで、制御内容に平日と休日の区別を行っていない。平日と休日でこれらに違いがある場合には、制御内容の指定を更に細かく行うことになる。また、平日であっても休暇を採って通勤を行わないような場合や、出張で通常と異なる勤務形態を採るような場合には、サービスセンタアプリケーションサーバ１０３に通知して制御内容を必要に応じて変えることが可能である。ただし、本実施例では前日までの測定結果を次の日以降に反映させていくので、歩数等の目標値をそれぞれの日で厳密に達成する必要はなく、多少の過不足を生じさせながら期間全体で帳尻を合わせるようにすることができる。
【００６０】
また、図９では時刻を基にして歩数計の制御を行っているが、現実にはユーザ１１１の帰宅時刻等の各種設定時刻はスケジュールと一致しない場合が多い。そこで、サービスセンタアプリケーションサーバ１０３は携帯端末１１２のＤＧＰＳ通信部１２７が測定した位置情報を必要に応じて取得し、ユーザが経路のどの位置に居るかを判別することで自宅１５１に到着したとかＣ会社１５４から退社したタイミングを正確に判別するようにしている。ただし、本実施例では煩雑になるため、時刻通りにユーザ１１１が行動しているものとして単純に説明を行う。
【００６１】
＜基本プランの修正による２日目以降の実施＞
【００６２】
さて、２日目以降ではサービスセンタアプリケーションサーバ１０３が今までのウォーキング等のプログラムによるユーザ１１１の運動量を把握しながら、基本プランを随時補正しする。そして、その時々の気象等の運動環境の変化も加味しながらその日、その時の推奨プランを作成してユーザ１１１に提示することになる。
【００６３】
図１０は、サービスセンタアプリケーションサーバによる２日目以降の処理の流れを表わしたものである。２日目以降では、ユーザ１１１が最初の行動を開始する数時間前にサービスセンタアプリケーションサーバ１０３がその日の推奨プランを作成する。本実施例では、図８の平日の基本プランによると朝８時にユーザ１１１が自宅を出発する。そこでこれよりも２時間早い午前６時になると（ステップＳ２９１：Ｙ）、サービスセンタアプリケーションサーバ１０３は推奨プランを作成する際に必要とする各種のサーバにアクセスして、当日のための情報を取得する。本実施例の場合には乗物情報サーバ１０５と天候情報サーバ１０６にアクセスして当日の情報を取得し（ステップＳ２９２）、前日の歩数計１１３の測定値と当日の天候等の情報から、基本プランを修正した推奨プランを複数作成する（ステップＳ２９３）。
【００６４】
たとえば、前日の歩数が目標値に大きく及ばなかったような場合には、自宅１５１から最寄のＡ1バス停まで歩いてバス１５２に乗っていたものを、少しだけ早く出発して次のＡ2バス停まで歩いてバス１５２に乗るような第１の推奨プランや、Ａ1バス停から乗車することを変更しない代わりに、昼休みにＣ会社１５４からＢ10駅まで往復することを新たに追加する第２の推奨プラン等の複数の推奨プランを提示する。このようにして歩数の足りなかった分を補う修正を行う。
【００６５】
もちろん、気象上の原因で推奨プランを作成あるいは修正することも可能である。たとえば当日は台風が近づいてきており、Ｂ1駅と図示しないＢ3駅の間が冠水してその区間の鉄道が不通となっていたような場合、自宅１５１から図示しないＤ1バス停まで歩いて行って、ここから他の図示しないバスルートを利用してＢ3駅の近くまでバスで行くといった推奨プランへの変更を行うことができる。
【００６６】
このようなプラン変更の場合、自宅１５１からＤ1バス停までの距離がＡ1バス停までの距離よりも遠い場合には、その分だけ運動量が増加することになる。したがって、前日までの運動量が特に不足していないユーザの場合、次の推奨プランではたとえば公園１５５でのウォーキングの時間を短縮させるといったプランの修正を行うことになる。もちろん、ユーザ１１１は運動量の超過を次の休日に持ち越して、体の休息を図ることも可能である。
【００６７】
なお、サービスセンタアプリケーションサーバ１０３は各種の推奨プランを作成するとき、午前と午後で気象条件が異なるような場合には、ユーザ１１１にこれを気象情報と共に提示して、ウォーキングの実現し易い環境あるいは運動を適正に行える環境を提案することができる。たとえば、ユーザ１１１が通常は自宅１５１からＡ2バス停まで歩いて、その分の歩数を稼いでいたとする。朝の天候が雨で夕方の天候が晴になるような場合には、朝は自宅１５１の傍のＡ1バス停からバス１５２に乗り、帰りは自宅１５１からＡ2バス停よりも遠いＡ3バス停で降りて自宅１５１に帰るというような推奨プランを提案することで、雨に濡れずに必要とする運動量を確保することができる。
【００６８】
ステップＳ２９３で推奨プランを作成したら、サービスセンタアプリケーションサーバ１０３は当日用に作成したこれら複数の推奨プランを携帯端末１１２に電子メールで送信する（ステップＳ２９４）。そして、その後、ユーザの携帯端末１１２との間でプランの選択や修正のための処理を行う（ステップＳ２９５）。具体的には、ユーザ１１１が複数の推奨プランの中から１つを最終的なプランとして選択すれば、これが実施するプランとして確定する。また、ユーザ１１１が内容を指定して修正を要求してきた場合には、これを反映した１または複数の推奨プランが作成されてステップＳ２９４で再び携帯端末１１２に送信されることになる。ここで、推奨プランの修正を行うためにサービスセンタアプリケーションサーバ１０３は地図情報サーバ１０４、乗物情報サーバ１０５あるいは天候情報サーバ１０６に対して新たなデータを要求する場合があることは当然である。
【００６９】
このようにして最終的に１つの推奨プランが選択されたら、サービスセンタアプリケーションサーバ１０３は当日の第１回目に実行される推奨プランをユーザの携帯端末１１２に送信することになる（ステップＳ２９６）。本実施例の場合には朝８時から正午の１２時までの推奨プランがユーザ１１１の自宅１５１を出発する前の十分早い時刻に推奨プランが提示される。したがって、ユーザ１１１は指示された時刻に歩数計１１３を携行して自宅１５１を出発し、午前中のエクササイズを実行することになる。
【００７０】
サービスセンタアプリケーションサーバ１０３は当日の２回目以降の推奨プラン開始前の所定の時刻の到来を監視している（ステップＳ２９７）。本実施例では２回目の推奨プランが開始される正午の１２時がこの時刻となる。この時刻が到来すると（Ｙ）、サービスセンタアプリケーションサーバ１０３は２回目の推奨プランを実施するのに必要な各種サーバの情報を取得する（ステップＳ２９８）。たとえば天候が変わっており、昼休み中に雨が降りそうなときには天候情報サーバ１０６にアクセスして最新の予測情報が取得される。特に追加的に必要とされる情報が存在しない場合には、地図情報サーバ１０４、乗物情報サーバ１０５あるいは天候情報サーバ１０６へのアクセスは省略することができる。サービスセンタアプリケーションサーバ１０３は以上の処理の後、１回目の推奨プランによる運動量の取得結果を加味して推奨プランを必要により修正する（ステップＳ２９９）。そして、その推奨プランをユーザの携帯端末１１２に送信する（ステップＳ３００）。
【００７１】
このように当日の２回目以降では推奨プランの大幅な修正は行われない。これは、ユーザ１１１がステップＳ２９５で当日のプランを詳細に煮詰めているので、煩雑な手続きを省略するためである。もちろん、ユーザによってはシステムの初期設定のときに、たとえば早朝の詳細な修正等の処理を就寝前の時間帯に移動させる等の各種変更が可能である。
【００７２】
サービスセンタアプリケーションサーバ１０３は、この他、歩数計１１３あるいは携帯端末１１２に備えられたＤＧＰＳ通信部１２７、地磁気センサ１２８、加速度センサ１２９、脈拍センサ１３０、温度センサ１３１および高度計１３２といった部品から得られるデータを受信すると（ステップＳ３０１）、これらを解析して緊急処理が必要であるかどうかを判別する（ステップＳ３０２）。そして、たとえば歩行中に脈拍センサ１３０が異常な数値変化を示しているというような場合には（Ｙ）、予め定めた緊急処理を実行する（ステップＳ３０３）。たとえば、携帯端末１１２に対して脈拍が異常に高いことを記した定型文からなる電子メールを送信し、ウォーキングの速度を低下させる指示を行う。
【００７３】
特に緊急性を要しないデータが受信された場合には（ステップＳ３０２：Ｎ）、次回の推奨プランの作成のためのデータとしてサービスセンタアプリケーションサーバ１０３の図示しない作業領域に一時的に格納する（ステップＳ３０４）。たとえば、歩数計１１３から送られてくる歩数情報は、この作業領域から所定のタイミングで読み出されて、次の推奨プランの作成のために使用される。
【００７４】
以上のサービスセンタアプリケーションサーバ１０３の制御を基にして２日目のユーザの行動例を具体的に説明する。たとえばユーザ１１１が水平な土地を歩くと仮定して歩数計１１３で１日１００００歩を達成することを目標としていたとする。なお、本実施例では図１に示した地図情報サーバ１０４によってユーザ１１１が歩行する道の傾斜の度合いの概要をサービスセンタアプリケーションサーバ１０３が判別しており、歩数に対する運動量の補正を行っているが、この詳細は省略し、水平な土地を歩くものと仮定して説明する。
【００７５】
歩数計１１３から得られたユーザ１１１の初日の歩数情報が８０００歩であったとする。この場合、１日目で２０００歩が不足していたことになる。ユーザ１１１の歩幅が０．５であるとすると、これは水平な土地の１キロメールに相当する。サービスセンタアプリケーションサーバ１０３は、基本プランの自宅から最寄のＡ1バス停まで歩いてバス１５２に乗る経路と、Ａ2バス停あるいはＡ3バス停まで歩いてバス１５２に乗る３系統の変更案を作成し、それぞれについて昼休みおよび自宅１５１に到着してからの商店街１５６あるいは公園１５５で行うウォーキングの時間の増加量によって２０００歩の不足を実質的に補う推奨プランを作成する。１系統についてそれぞれ３通りの案があるとして、全部で９通りの推奨プランが初期的に作成される。サービスセンタアプリケーションサーバ１０３は、その日に雨が降るような場合には、アーケード付の商店街１５６のようにウォーキングに障害が生じないようなコースを増加分に積極的に割り当てたり、傘をさしながら長時間歩くコースを除外して、最終的に実現可能性の高い幾つかの推奨プランを決定する（図１０ステップＳ２９３）。
【００７６】
この推奨プランは、朝６時過ぎに携帯端末１１２に送信される。ユーザ１１１は、朝起きた時点で携帯端末１１２の電子メールをチェックして、送信されてきた複数の推奨プランを見て、その中で実行したいものがあればそれを選択する。また、修正が必要な場合にはその旨の通知を行う（ステップＳ２９５）。このようにして当日の１回目の推奨プランが確認のために携帯端末１１２に送られてくる。ここでユーザ１１１は、自宅１５１を早く出発してＡ2バス停まで歩く推奨プランを選択したものとする。
【００７７】
図１１は、ユーザが選択した２日目の推奨プランを表わしたものである。この推奨プランで基本プランから変更された項目には※１６１が付されており、また、訂正された箇所には太字処理を行ったり、その部分の色を変える等の強調表示が行われている。これは、ユーザ１１１が変更箇所を容易に確認できるようにするためである。この２日目の推奨プランでは「自宅出発」が朝８時から朝７時５３分に変更されており、バス１５２（図７）に乗る場所もＡ1バス停から１つ先のＡ2バス停に変更されている。また、昼休みのウォーキングが新たに１０分間新設され、自宅１５１に帰った後に行うウォーキングが３０分から３５分に変更されている。また、推奨プランの末尾のコメント欄１６２には、「２０００歩の運動不足を解消しよう！」というメッセージが記入されており、ユーザ１１１への１日の目標が示されている。
【００７８】
ユーザ１１１は食事をいつもより早くして、朝７時５３分よりも更に早く７時４５分に自宅１５１を出発したものとする。ユーザ１１１の歩行は歩数計１１３で計数され、また、歩行経路は図２に示した携帯端末のＤＧＰＳ通信部１２７から適宜、サービスセンタアプリケーションサーバ１０３に送信される。この結果、ユーザ１１１が自宅１５１を出発した時刻がサービスセンタアプリケーションサーバ１０３に通知される。また、ユーザ１１１がＡ2バス停に到着する時点で、サービスセンタアプリケーションサーバ１０３は更に次のＡ3バス停のバス発車時刻と、Ａ3バス停に到達するために必要な時間から現在の歩行スピードによる到達予想時刻を携帯端末１１２に送信する。ユーザ１１１は到達予想時刻がＡ3バス停のバス発車時刻よりも早ければ、Ａ3バス停を目指して歩き続けることができる。なお、このようにユーザ１１１が現実にバスに乗ろうとしている状況で、サービスセンタアプリケーションサーバ１０３は乗物情報サーバ１０５と追加的に交信して、バスの実際の運行状況から各バス停のバス発車時刻をリアルタイムに書き換えることができる。
【００７９】
このようにしてユーザ１１１がＡ3バス停からバスに乗車したとすると、これによりＣ会社１５４に行くまでの歩行は目標を超えて達成されたことになる。その後も会社内で仕事のための移動が歩数計１１３によって積算されていく。会社内でエレベータの利用を控え、階段を積極的に利用することでも歩数の計数の増加につながる。
【００８０】
昼の１２時になると、歩数計１１３が当日の１回目のカウント値としての歩数計１１３をサービスセンタアプリケーションサーバ１０３に送信する。サービスセンタアプリケーションサーバ１０３はたとえばこの情報と天候情報サーバ１０６から新たに得られた情報を基にして、当日の２回目の推奨プランの修正を行う（ステップＳ２９９）。
【００８１】
図１２は、当日２回目の推奨プランを表わしたものである。２回目の推奨プランでは、１回目の推奨プランの消化状況と、２回目以降の推奨プランが携帯端末１１２の表示部１２５（図２）に表示される。１回目でユーザ１１１はＡ3バス停まで余計に歩いてバス１５２に乗ったばかりでなく、Ｂ10駅に着いた後はＣ会社１５４まで回り道をしてウォーキングを５分間余計に行っている。これらのユーザ１１１の努力によって、昼休みに商店街１５６を１０分間散策すれば、帰宅後に課せられていた５分超過の３５分のウォーキングが通常の３０分で済むことに推奨プランの修正が行われている。推奨プランの末尾のコメント欄１６２には、１回目に示された２０００歩の超過目標が７００歩に減少している。
【００８２】
なお、コメント欄１６２に表示される過不足の歩数等の情報は、必ずしも当日の終了時に運動量の帳尻が合うようにする観点からの情報である必要はない。仕事が数日間集中して運動不足となったような場合、次の１日で不足した運動量を取り戻すように過度の運動を行うことは体を壊す要因となる。そこで、ユーザは１日の最大歩数あるいは最大運動量を定めてこれの許す範囲で不足した歩数を数日間掛けて埋め合わせたり、数日あるいは１週間程度で帳尻が合うように不足分を平均化して、それぞれの日に分けるようにしてもよい。また、病気の後のような場合には、数日間、運動量を通常時の基本プランと同一あるいはこれよりも低く設定して、その後に運動不足分を順次取り戻すように日々の推奨プランを割り当てることも可能である。
【００８３】
ところで、ユーザ１１１は昼休みに近くの友人が食事を誘ったため、指示された１０分間のウォーキング（辺りの散策）ができなかったとする。ただし、午後に仕事先の会社を訪問する仕事が発生し、往復で２０分のウォーキングが新たに発生したとする。歩数計１１３および携帯端末のＤＧＰＳ通信部１２７がこれらについても監視し、サービスセンタアプリケーションサーバ１０３に通知する。これらの結果、サービスセンタアプリケーションサーバ１０３はユーザ１１１の帰宅した夕方１８時５０分に２回目の測定結果を集計して、天候情報サーバ１０６等から新たに得られた各種の情報も加味しながら３回目の推奨プランを携帯端末１１２に送信する（図１０ステップＳ３００）。なお、帰宅時間は携帯端末のＤＧＰＳ通信部１２７の通信結果によって最終的に判別されるので、サービスセンタアプリケーションサーバ１０３は帰宅後の推奨プランを帰宅の時間のずれに係らず正確に算出することができる。
【００８４】
図１３は、当日最後の３回目の推奨プランを表わしたものである。３回目の推奨プランでは、１回目および２回目の推奨プランの消化状況と、３回目の推奨プランが携帯端末１１２の表示部１２５（図２）に表示される。２回目が終了した時点で昨日の２０００歩の不足が解消され、更に３００歩が超過したので、帰宅後に行われる公園１５５（図７）でのウォーキングが３０分から２０分に短縮されている。コメント欄１６２には、現時点で３００歩目標が超過したことと、運動量の過不足が当日の運動で解消すれば、明日は基本プランと一致した推奨プランの実施が可能であることが記されている。
【００８５】
なお、この帰宅後に行われる当日３回目の推奨プランは、帰宅までに行われた歩行プランに対して、その不足分を補うリカバリプランとして位置づけることもできる。すなわち、この実施例でユーザ１１１は帰宅後の公園１５５でのウォーキングを基本プランに加えたが、帰宅の時点で目標とするウォーキング等による運動量に到達することを前提として、到達できなかったときにのみリカバリとして付加的なウォーキングを追加するようにしてもよい。
【００８６】
＜当日の運動達成状況と翌日の推奨プランの確認＞
【００８７】
図１４は、ユーザがサービスセンタアプリケーションサーバに対して運動に関して各種の表示要求を行った場合の処理の流れを表わしたものである。ユーザ１１１は携帯端末１１２を健康管理に関する所定のモードに設定して、幾つかの表示要求を行うことができる。本実施例では、一日の運動を終了したときの当日の実績の表示要求と、１日の現時点における目標達成状況の表示要求と、翌日の推奨プランの表示要求の３つを行うことができる。
【００８８】
ユーザ１１１は、１日の運動が終了した時点でその１日の実績の表示を要求することができる。サービスセンタアプリケーションサーバ１０３がこの要求を受信すると（ステップＳ３１１：Ｙ）、当日の最終結果をすでに受信しているかどうかのチェックが行われる（ステップＳ３１２）。先に説明した例では、３回目の送信が１日の終了する深夜２４時に行われるようになっている。これは、ユーザ１１１によっては遅く帰ってくる日もあるし、深夜に自宅のウォーキングマシンでウォーキングを行うこともある。そこで、その日の歩数計１１３の計数はできるだけ日にちが変わる直前で行うようにしているためである。
【００８９】
しかしながら、ユーザ１１１によっては自宅１５１に帰って夕食を食べた後は公園１５５等の場所による運動を行わないことにしており、むしろその日の運動が終わったとして、１日の実績を検討したいと思う者もある。そこでサービスセンタアプリケーションサーバ１０３は当日の実績の表示要求を行った携帯端末が最終結果を受信しているかどうかを判別する（ステップＳ３１２）。そして、最終結果がまだサービスセンタアプリケーションサーバ１０３に送られていないことが判別した場合には（Ｎ）、携帯端末１１２に対してその日の最終結果の送信を要求する（ステップＳ３１３）。そして、最終結果が受信された時点で（ステップＳ３１４：Ｙ）、当日の実績の報告を作成して（ステップＳ３１５）、これを該当する携帯端末１１２に送信する（ステップＳ３１６）。この場合、携帯端末１１２は規定の時間に行われる３回目の送信を行わない。実施例では１日の終了する深夜２４時に第３回目の送信を行うことにしているが、これよりも前にその日の最終報告がサービスセンタアプリケーションサーバ１０３に行われたことになるので、重複した報告を避けることになる。ステップＳ３１２で既に当日の最終結果をサービスセンタアプリケーションサーバ１０３が受信している場合には（Ｙ）、要求された時点で当日の実績報告を作成して（ステップＳ３１５）、携帯端末１１２に送信することになる（ステップＳ３１６）。
【００９０】
また、サービスセンタアプリケーションサーバ１０３に対してその時々の目標達成状況の要求があった場合には（ステップＳ３１７：Ｙ）、現時点での歩数計１１３の歩数のカウント値の送信を歩数計１１３に要求する（ステップＳ３１８）。たとえば、リカバリ処理として先のユーザ１１１が公園１５５でウォーキングを行っている最中で、目標を達成したかを知りたい場合がある。このようなとき、サービスセンタアプリケーションサーバ１０３は歩数計１１３に現時点の計数した歩数の送信を要求し、結果を受信したら（ステップＳ３１９：Ｙ）、その日の今までの歩数に加算して目標との差し引きを行い、目標達成状況報告を作成する（ステップＳ３２０）。そして、これを携帯端末１１２に送信して表示させることになる（ステップＳ３１６）。なお、ユーザ１１１が独自に通信機能を有する歩数計１１３を使用せず、簡易な歩数計を代わりに使用していた場合には、携帯端末１１２に対して現時点の計数した歩数の送信が要求されることになる。この場合、ユーザ１１１はその簡易な歩数計の数値を見て、これを携帯端末１１２からサービスセンタアプリケーションサーバ１０３に送信することになる。
【００９１】
また、ユーザ１１１は就寝前の所定の時点に翌日の推奨プランを把握しておきたい場合がある。このような場合、サービスセンタアプリケーションサーバ１０３に対して翌日プラン要求が携帯端末１１２から送信されることになる。サービスセンタアプリケーションサーバ１０３は翌日プラン要求を受信すると（ステップＳ３２１：Ｙ）、ステップＳ３１２で説明したようにその日の最終結果が受信されているかどうかを判別し（ステップＳ３２２）、まだ受信されていない場合には（Ｎ）、これを要求して（ステップＳ３２３）、取得する（ステップＳ３２４：Ｙ）。そして、翌日の推奨プランを作成する（ステップＳ３２５）。翌日の推奨プランは、図１０のステップＳ２９１で１回目のプランの開始２時間前（実施例では朝６時）に作成するようにしていたのを先倒しすることになる。これにより、たとえば早朝に発生した交通機関の障害や天候の急変に対応することはできないが、朝起きる時間や朝食の時間を就寝前に確定させることができる。
【００９２】
もちろん、システムの設定によっては図１０のステップＳ２９１〜Ｓ２９３の処理を再度行わせ、このとき就寝前に決定した推奨プランも含めて複数のプランを提示させて、ユーザ１１１に選択させるようにしてもよい。これにより、ユーザ１１１は前日に立てた推奨プランだけでなく、当日の状況に応じて新たに作成された推奨プランも含めて、当日実際に実施するプランを選択することができる。
【００９３】
以上説明した実施例では説明を簡略化するために歩数計１１３を用いたウォーキング中心とした健康管理を説明した。本発明はこれに限らず、歩数計１１３の１カウント当たりのカロリ消費量をウォーキングの場合に換算することで、ジョギングを組み合わせた健康管理に適用することができる。この場合のウォーキングとジョギングの判別には、たとえば携帯端末１１２のＤＧＰＳ通信部１２７の測定した位置情報の変化を用いたり、加速度センサ１２９の検出結果を用いることができる。また、ユーザ１１１が運動の種別を携帯端末１１２から入力することも可能である。
【００９４】
ウォーキングやジョギング以外に同様にしてサイクリング、ローラスケーティング、テニスといった各種のスポーツを含めた健康管理を行うことができる。また、１週間のうちの何日かをスポーツジムに通っている者は、その施設を出た時点等の所望の時点で、予め作成したフォームにエロビクスを３０分行ったとか、プールで１キロ泳いだとかのデータを携帯端末１１２からサービスセンタアプリケーションサーバ１０３に送信することで、これらの運動を加味したある期間における運動量の管理を行うことができる。
【００９５】
また、実施例では平日におけるユーザの自宅と勤務地の間の往復および近所でのウォーキングについて説明したが、日曜日等の休日についても本発明を適用して比較的長期間にわたった健康管理を実現することができる。これを次に変形例として説明する。
【００９６】
＜本発明の変形例＞
【００９７】
図１５は、本発明の変形例として、図５のステップＳ２２１で説明した基本データの入力における休日プランの入力画面の一例を表わしたものである。ここでは、ウォーキングに関するプランを表わしている。図１に示したユーザ１１１は携帯端末１１２あるいは図示しないパーソナルコンピュータを用いてサービスセンタアプリケーションサーバ１０３にアクセスし、この休日プランの入力画面１７１を表示することができる。
【００９８】
休日プランの入力画面１７１には、その休日の１日当たりの目標とする歩数を入力欄１７２に入力する。平日にウォーキングを順調に行う想定の場合には、ここには通常の１日に課せられている歩数を入力すればよいが、平日は忙しく十分な運動を行えないことが想定される場合には、休日にこれらの運動不足を補う歩数を入力すればよい。
【００９９】
ウォーキングコースは、ユーザ１１１の自宅１５１からあまり離れていない箇所で行う「付近の散策コース」と、電車やバス、マイカーあるいは飛行機といった交通機関を利用して多少の遠出をする「レジャーを兼ねたウォーキングコース」に分かれている。後者の場合には日数入力欄１７３に出発から帰るまでの日数を入力する。また、行き先の希望を特定するための選択肢１７４が設けられており、これらについてのラジオボタンが配置されている。更に、ウォーキングの参加者がユーザ本人だけか、グループで参加するかを入力することで、年齢に応じたコースの選定が行えるようになっている。更に、送信ボタン１７５の横には観光情報ボタン１７６が配置されており、ユーザ１１１はウォーキングに適した観光場所についての各地の情報を収集することができる。これによって観光場所が特定した場合には、行き先の希望を特定するための選択肢１７４の「観光地」の箇所の観光地入力欄１７７に具体的に観光地を入力すればよい。
【０１００】
図１６は、この変形例におけるサービスセンタアプリケーションサーバによる休日プランの処理の様子を表わしたものである。サービスセンタアプリケーションサーバ１０３は、図１５に示した休日プランの受信があると（ステップＳ３４１：Ｙ）、「付近の散策コース」が指定されている場合（ステップＳ３４２：Ｙ）、予め作成しておいた全国の散策コース集からユーザ１１１の住んでいる地区のデータを抽出する（ステップＳ３４３）。そしてこれをコース案内としてユーザ１１１の携帯端末１１２あるいは特定のパーソナルコンピュータに送信する（ステップＳ３４４）。
【０１０１】
休日プランが「レジャーを兼ねたウォーキングコース」であった場合には（ステップＳ３４２：Ｎ）、送られてきたデータにおけるレジャーの日数、参加する者の年齢サイズ構成および希望地に合わせて全国のウォーキングに適した場所を複数検索する（ステップＳ３４５）。このとき、観光地が「おまかせ」として指定されていた場合には天候情報サーバ１０６に問い合わせて実施日に天候がよい観光地でスケジュールおよびウォーキングに適するものを複数選択する。観光場所が指定されている場合には、その中でウォーキングに適する場所を複数ピックアップする。そして、抽出した複数の場所を、たとえばサービスセンタアプリケーションサーバ１０３の運営会社に対して観光協会、旅行会社、ホテル業界等の紹介元から紹介料が多く徴収できるもの、あるいはその可能性が大きいものから順に所定数のコースを抽出して（ステップＳ３４６）、コース案内を送出する（ステップＳ３４４）。
【０１０２】
したがって、サービスセンタアプリケーションサーバ１０３の運営会社は、観光協会、旅行会社、鉄道、バス会社等の旅行関連会社とタイアップして、ユーザ１１１が満足するウォーキングのための各種のコースを作成し、「レジャーを兼ねたウォーキングコース」の内容を充実させることで、収益を増やすことができる。もちろん、運営会社はユーザ１１１からウォーキングコース案内の料金を会費等の形で徴収することもできるし、ウォーキング等の運動関連のグッズの販売や関連ホームページへのリンクによって手数料を得ることも可能である。
【０１０３】
本実施例のサービスセンタアプリケーションサーバ１０３は、ウォーキングに関連した休日に関する各種の予約業務も行っている。ユーザ１１１から予約を受信すると（ステップＳ３４７：Ｙ）、ホテル、旅館等の宿泊施設や、電車、飛行機等の乗物の予約を行い、手数料を含めた課金を行う（ステップＳ３４８）。
【０１０４】
なお、図１５に示した休日プランは、ユーザ１１１の基本データの作成の一環として提示することにしているが、これに限るものではない。サービスセンタアプリケーションサーバ１０３は、個々のユーザの運動の過不足をチェックして、たとえば平日に運動量が連続して不足している者がいれば、不足した歩数を補うためのウォーキングプランを休日用に作成して、これをプッシュ型メールで発信することも有効である。これにより、ユーザ１１１が仕事に追われて休日の予定を考えられない状況でも、休日の推奨プランを提示され、これに連動したホテルの宿泊予約や鉄道の予約を行えることで、運動量の不足を解消すると共に、気分転換や家庭サービスを図ることができる。
【０１０５】
また、ユーザ１１１が休日のウォーキングに乗り気でないことが、送信されてくるデータから推測されるような場合には、占いのメールを送信し、占いで示された方角を目的地とするウォーキングプランを紹介することもウォーキングの実践に（または健康増進に）有効である。これにより、潜在的な休日のウォーキング需要を開拓し、また観光地めぐり等の観光需要の掘り起こしを図ることができる。
【０１０６】
更に、ユーザ１１１の自宅１５１や勤務地を基点としてウォーキングのプランを立てるだけでなく、出張時の場所をサービスセンタアプリケーションサーバ１０３に指定して、ウォーキングの起点を全国に展開することも可能である。また、ウォーキングについても単に健康のためというだけでなく、レジャーとしての楽しみを加味したり、家族等の同伴者の観光という色彩を強めることで、休日のウォーキングの実践を容易にすることができる。更に、ウォーキングという特殊性を利用して、交通の便が悪い場所のホテルをウォーキングコースに入れることで周囲の景観と併せて経済的で魅力あるコースを誕生させることができる。また、このようなホテルからウォーキングプランを付加した広告を依頼されたり、宿泊の契約成立時にロイヤルティの支払いが行われることを条件に広告を掲載することで、新たなビジネスを展開することができる。
【０１０７】
なお、以上説明した実施例および変形例では通信ネットワークとしてインターネット１０１とモバイルネットワーク１０２を使用したが、通信ネットワークの種類はこれらに限定されるものではない。ユーザが自宅やスポーツジム等の屋内で運動を行うことに限定して運動量を管理するものであれば、有線による通信ネットワークのみで運動量管理システムを構成することも可能である。通信ネットワークには、ＣＡＴＶ（CAble TeleVision）、無線ＬＡＮ（Local Area Network）等の各種の通信ネットワークが混在してもよい。
【図面の簡単な説明】
【０１０８】
【図１】本発明の一実施例における運動量管理システムの構成を表わしたシステム構成図である。
【図２】本実施例で使用される携帯端末の構成の要部を表わしたブロック図である。
【図３】本実施例で使用される歩数計の概要を表わしたブロック図である。
【図４】本実施例のユーザが携帯端末を使用して運動量管理システムを利用する場合の携帯端末の処理の概要を表わした流れ図である。
【図５】図４で示したプラン作成モードの実行における携帯端末の処理の様子を表わした流れ図である。
【図６】本実施例でサービスセンタアプリケーションサーバによる基本プランの設定処理を表わした流れ図である。
【図７】本実施例のユーザの自宅と会社の間の経路の概要を表わした説明図である。
【図８】本実施例でユーザの平日の基本プランを表わした携帯端末の表示部の平面図である。
【図９】本実施例の歩数計の処理の様子を表わした流れ図である。
【図１０】本実施例でサービスセンタアプリケーションサーバによる２日目以降の処理を表わした流れ図である。
【図１１】本実施例でユーザが選択した２日目の推奨プランを表わした携帯端末の表示部の平面図である。
【図１２】本実施例で当日２回目の推奨プランを表わした携帯端末の表示部の平面図である。
【図１３】本実施例で当日最後の３回目の推奨プランを表わした携帯端末の表示部の平面図である。
【図１４】本実施例でユーザがサービスセンタアプリケーションサーバに対して運動に関して各種の表示要求を行った場合の処理の流れ図である。
【図１５】本発明の変形例で休日プランの入力画面の一例を表わした平面図である。
【図１６】この変形例でサービスセンタアプリケーションサーバによる休日プランの処理の様子を表わした流れ図である。
【符号の説明】
【０１０９】
１００ 運動量管理システム
１０１ インターネット
１０２ モバイルネットワーク
１０３ サービスセンタアプリケーションサーバ
１０４ 地図情報サーバ
１０５ 乗物情報サーバ
１０６ 天候情報サーバ
１１１ ユーザ
１１２ 携帯端末
１１３ 歩数計
１１４ 位置測定用人工衛星
１２１、１４１ ＣＰＵ
１２３、１４３ ＲＯＭ
１２４、１４４ ＲＡＭ
１２５、１４６ 表示部
１２９、１４５
１３０ 脈拍センサ
１３１ 温度センサ
１３２ 高度計
１３３ 操作部
１５１ 自宅
１５２ バス
１５３ 急行電車
１５４ Ｃ会社
１５５ 公園
１５６ アーケード付の商店街
【技術分野】
【０００１】
本発明は、個人の運動量を管理する運動量管理システム、運動量管理サーバおよび運動量管理プログラムに係わり、特に継続的な運動を視野に置いた運動量管理システム、運動量管理サーバおよび運動量管理プログラムに関する。
【背景技術】
【０００２】
健康の維持や増進に多くの者が関心を持っており、また実践に勤めている。歩数計を使用してウォーキングの際の歩数の一日の目標を定めて健康を維持しようとする者も多い。ところで、歩数計を使用した場合、歩幅の広い人と狭い人で同じ歩数でも歩いた距離が異なってくる。したがって、歩幅補正手段を備えることで、正確な歩行距離を算出する工夫が行われている（たとえば特許文献１参照）。この第１の提案によれば、出発地から目標地まで移動したときの歩数計数手段の歩数計数値と地図上で計測した距離の２つの値から、そのユーザの歩幅を求めて、これに歩数を掛け合わせることによって正確な歩行距離を算出するようにしている。
【０００３】
そこで、このように歩数計によって歩行距離が算出できる点を利用して、ＧＰＳ（Global Positioning System）で測定ができないエリア内での位置情報を求めようとする第２の提案も行われている。
【０００４】
また、歩数計をこのような距離の測定や位置情報の特定に利用するだけでなく、前記したような健康管理に利用する提案も行われている（特許文献３参照）。この第３の提案では、ユーザ自身の健康管理に必要な情報を参照してその者が健康管理のために採るべき経路を案内するものである。具体的には個人の日常の健康管理に必要な情報を管理情報記憶手段に記憶しておき、地図情報記憶手段、自己位置検出手段および管理情報記憶手段から得られる情報に基づいて、そのユーザのための推奨経路を探索するようにしている。そして、例えば、喘息気味のユーザであれば空気の悪い場所を通らない経路を選択したり、運動不足気味のユーザであれば所定距離以上の徒歩を要するコースを選択するようにすることで、健康管理を行っている。
【特許文献１】特開平１０−０３８６０２号公報（第００１５段落、図１）
【特許文献２】特開２００１−２２７９７３号公報（第００１９段落、図２）
【特許文献３】特開平１０−１４８５３９号公報（第０００９、第００２５、第００２６段落、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
この第３の提案では１日にとるべき消費カロリの目標を定めて、これに応じた消費カロリとなるような推奨経路の検索を行っている。そして、日々の消費カロリが目標に達するようにすることで、ユーザの健康管理を行っている。ところが、仕事が忙しくて運動を行う時間がない日や、運動を行おうとしても悪天候でできない日がある。また、運動を行う時間があっても体調が不良でこれを断念せざるを得ない日もある。このように、運動の計画を行っても毎日これを順調に消化できるものではない。運動を１日単位に緻密にスケジュールしている場合には、一日でも予定を消化しないと、運動を継続する意味がなくなったような気がしたり、目標を達成できないような気がして継続意思の大きな障害となる場合が多い。
【０００６】
また、体脂肪計付の体重計や心拍計を取り付けた腕時計のような健康管理用器具が数多く売り出されており、その中には日々の測定データをコンピュータに送って、１週間や数ヶ月単位でデータを収集して健康管理を行うようにしたものも登場している。このような健康管理用器具では、たとえば東海道を模擬的に歩いて制覇するといったようなプログラムを備えており、ユーザに比較的長期の運動を薦めて体重や体脂肪の減少を図るといったものが多い。ところが、このようなプログラムでは最終目標となる距離は定まっていても、目標達成のための期間は定まっていない。したがって、健康に対して大きく寄与しないような少量ずつ運動を行うユーザもいれば、１日当たりの歩く量を過度に設定して体の過度の負担を招くユーザもいる。
【０００７】
この結果として、従来のいずれの場合でも歩数計や体重計を購入する時点で運動に対する意欲はあるものの、個人個人の方向性が定まらず、運動を適正な量行いながら長期的に継続することができない場合が多かった。
【０００８】
そこで本発明の目的は、１週間や数ヶ月あるいはこれ以上といったある程度長い期間を対象として理想とする運動量を達成させることのできる運動量管理システム、運動量管理サーバおよび運動量管理プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
本発明では、（イ）個人の運動量を測定する運動量測定手段と、（ロ）前記した個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信し、運動量目標値設定手段によって設定された目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、（ニ）この過不足演算手段の演算結果を表示する運動量過不足表示手段とを運動量管理システムに具備させる。
【００１０】
すなわち本発明では、管理の対象となる個人のある期間における運動量の目標値を設定し、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信して、目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する。そして、この過不足演算手段の演算結果を運動量過不足表示手段に表示することで、運動が不足したときにはこれを補うように運動を行えるようにして、あるいは平日に仕事で忙しいような場合には、休日にその分の運動を行えるようにして、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１１】
また、本発明では、（イ）個人の運動量を測定する運動量測定手段と、（ロ）前記した個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間の運動量を逐次受信し、運動量目標値設定手段によって設定された目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、（ニ）この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、（ホ）この運動計画作成手段の作成した運動計画を前記した個人の見うる装置に表示する運動計画表示手段とを運動量管理システムに具備させる。
【００１２】
すなわち本発明では、管理の対象となる個人のある期間における運動量の目標値を設定し、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信して、目標値を期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する。そして、この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成してその個人の見うる装置に表示することにして、運動が足りなかったような場合には運動のためのプランをその都度変更できるようにしている。また、たとえば平日に仕事で忙しいような場合には、休日にその分の運動を行えるプランを提示して、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１３】
また、本発明では、（イ）個人のある期間における運動量の目標値を取得する運動量目標値取得手段と、（ロ）前記した個人の運動量を運動量の測定を行う運動量測定手段が測定した前記した期間よりも短い区間で逐次受信する運動量受信手段と、（ハ）運動量目標値取得手段によって取得された目標値を期間の終了時に達成できるための運動量受信手段が運動量をそれぞれ受信した時点における運動量の過不足を演算する過不足演算手段と、（ニ）この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、（ホ）この運動計画作成手段の作成した運動計画を前記した個人の見うる装置に送信してこれに表示させる運動計画表示用送信手段とを運動量管理サーバに具備させる。
【００１４】
すなわち本発明では、個人の運動の管理を行う運動量管理サーバを設け、これに個人のある期間における運動量の目標値を取得させると共に、その個人の運動量を運動量測定手段が測定した前記した期間よりも短い区間で逐次受信するようにし、運動量目標値取得手段によって取得された目標値を期間の終了時に達成できるようにするために運動量をそれぞれ受信した時点における運動量の過不足を演算して、この演算結果を基にして次の区間あるいはこれ以降の運動計画を作成するようにしている。そして、作成した運動計画を前記した個人の見うる装置に送信することで、運動が足りなかったような場合には運動のためのプランをその都度変更できるようにしている。また、たとえば平日に仕事で忙しいような場合には、休日にその分の運動を行えるプランを提示して、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１５】
また、本発明の運動量管理プログラムは、（イ）個人の運動量を測定する運動量測定手段と前記した個人の所持する通信端末との間で通信を行う運動量管理のための管理サーバのコンピュータに、（ロ）前記した個人のある期間における運動量の目標値を通信端末から取得する運動量目標値取得処理と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、（ニ）運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、（ホ）この過不足演算処理の演算結果を通信端末に送信して表示させる運動量過不足表示用送信処理とを実行させることを特徴とする。
【００１６】
すなわち本発明では、運動量管理プログラムとして、運動量管理のための管理サーバのコンピュータに、個人のある期間における運動量の目標値を通信端末から取得する運動量目標値取得処理と、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、この過不足演算処理の演算結果を通信端末に送信して表示させる運動量過不足表示用送信処理とを実行させることで、個人がその運動量を測定する運動量測定手段と、管理サーバとの通信を行う通信端末を所持することで運動量の管理を行えるようにしている。すなわち、運動が不足したときにはこれを補うように運動を行えるようにして、あるいは平日に仕事で忙しいような場合には、休日にその分の運動を行えるようにして、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【００１７】
また、本発明の運動量管理プログラムは、（イ）個人の運動量を測定する運動量測定手段と前記した個人の所持する通信手段との間で通信を行う運動量管理のための管理サーバのコンピュータに、（ロ）前記した個人のある期間における運動量の目標値を通信手段から取得する運動量目標値取得処理と、（ハ）運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、（ニ）運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、（ホ）この過不足演算処理の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成処理と、（へ）この運動計画作成処理で作成した運動計画を通信手段に送信して表示させる運動計画表示用送信処理とを実行させることを特徴とする。
【００１８】
すなわち本発明では、運動量管理プログラムとして、運動量管理のための管理サーバのコンピュータに、その個人のある期間における運動量の目標値を通信手段から取得する運動量目標値取得処理と、運動量測定手段が測定した前記した期間よりも短い区間で運動量を逐次受信する運動量受信処理と、運動量目標値取得処理によって取得された目標値を期間の終了時に達成できるための運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、この過不足演算処理の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成処理と、この運動計画作成処理で作成した運動計画を通信手段に送信して表示させる運動計画表示用送信処理とを実行させることで、個人がその運動量を測定する運動量測定手段と、管理サーバとの通信を行う通信端末を所持することで運動量の管理を行えるようにしている。すなわち、運動が不足したときにはこれを補うように運動を行えるようにして、あるいは平日に仕事で忙しいような場合には、休日にその分の運動を行えるようにして、ある程度長い期間を対象として理想とする運動量を達成させるようにしている。
【発明の効果】
【００１９】
以上説明したように本発明によれば、個人が従来から勘で行っていた比較的長期における運動量の配分および減量等の健康管理のための運動計画を、その時々の運動量をチェックするだけでなく、その個人が行った過去の運動の実績から将来の運動の推奨プランや現時点までの運動の過不足を提示することにしたので、運動ができない事情が発生したときに無理に運動したり、無理なスケジュールを実行することによる運動計画の短期間での挫折や健康の悪化を防止することができる。しかも、その時々の運動量を消化するプランが具体的に提示されることで、必要な運動量を比較的容易に確保することができる。
【００２０】
また、平日の運動量が不足したようなときには、単に休日の運動を強制するのではなく、運動を伴った旅行等のプランを提示し、レジャーの要素を加味した健康管理の提案が行われるので、運動量の管理を長期間無理なく継続することができる。特に通信端末を多くの個人が所持するようになっているので、運動量の管理を行う管理サーバとの通信できめ細かな運動量管理を実現できる本発明の意義は大きい。
【発明を実施するための最良の形態】
【００２１】
以下実施例につき本発明を詳細に説明する。
【実施例１】
【００２２】
図１は、本発明の一実施例における運動量管理システムの構成を表わしたものである。この運動量管理システム１００は、インターネット１０１と、モバイルネットワーク１０２からなる通信ネットワークを利用するようになっている。インターネット１０１には、本実施例で経路ナビゲーションサービスを提供するサービスセンタアプリケーションサーバ１０３と、この要請によって各種の情報を提供する幾つかのサーバが接続されている。本実施例で使用されるサーバとしては、地図に関する情報を提供する地図情報サーバ１０４と、交通機関、すなわち各種の乗物に関する情報を提供する乗物情報サーバ１０５と、天候に関する情報を提供する天候情報サーバ１０６がある。これ以外のサーバが運動量管理システム１００を構成してもよい。また、地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６等のサーバはこれらの一部または全部が統合されたサーバであってもよい。
【００２３】
モバイルネットワーク１０２は、移動体と無線通信を行うネットワークである。本実施例では簡略化した例を示すために１つのモバイルネットワーク１０２がユーザ１１１の携帯端末１１２と歩数計１１３のそれぞれと接続される構成となっている。ここで、携帯端末１１２とは、携帯電話機、ＰＨＳ（Personal Handy-phone System）あるいは通信カードを取り付けるか通信機能を内蔵したＰＤＡ（Personal Digital Assistant）や携帯型のパーソナルコンピュータといった携帯可能な通信端末をいう。本実施例の携帯端末１１２はＤＧＰＳ（Differential Global Positioning System）機能を備えており、位置測定用人工衛星１１４を複数使用して現在位置の取得が可能になっている。
【００２４】
図２は、本実施例で使用される携帯端末の構成の要部を表わしたものである。この携帯端末１１２は、本実施例では携帯電話機であり、ＣＰＵ１２１を内蔵している。ＣＰＵ１２１はデータバス等のバス１２２を介して装置内の各部と接続されている。このうち、ＲＯＭ（リード・オンリ・メモリ）１２３は制御プログラムを格納するものであり、必要に応じてその内容が書き換えられるようになっている。ＲＡＭ（ランダム・アクセス・メモリ）１２４は作業用メモリとしての役割を持っている。表示部１２５は、液晶あるいは有機ＥＬディスプレイ（organic electroluminescence display）からなっている。通信制御部１２６は、図１に示したモバイルネットワーク１０２の図示しない基地局と無線通信を行うようになっている。ＤＧＰＳ通信部１２７は、図１に便宜的に１台のみ示した位置測定用人工衛星１１４や図示しない基準局からＤＧＰＳ補正情報を受信して、携帯端末１１２の現在位置を算出するようになっている。
【００２５】
地磁気センサ１２８は、地磁気を検出することで現在位置における方位を電子的に得るようになっており、電子コンパスを実現している。加速度センサ１２９は、２軸あるいは３軸の加速度を検出するものであり、ユーザ１１１の動作を検出することができる。脈拍センサ１３０は、図示しない発光ダイオードが発する赤外線の反射光を、同じく図示しないフォトディテクタで検出し、血流の変化を測定するようになっている。温度センサ１３１は、ユーザ１１１の体温や気温を測定するのに使用される。高度計１３２は、たとえば気圧の変化によって高度を測定するものである。この高度計１３２はユーザ１１１が歩行を行っているときの歩いた距離との関係で平坦地を歩行したか傾斜地を歩行したかを判別することができるだけでなく、高度の測定結果はＤＧＰＳによる位置測定の精度の向上のためにも使用することができる。操作部１３３は、ダイヤルキー等の各種キーおよびニューロポインタ（登録商標）等のポインティングデバイスから構成されており、ユーザ１１１が各種データを入力したり、必要な指示を入力することができるようになっている。
【００２６】
図３は、本実施例で使用される歩数計の概要を表わしたものである。歩数計１１３は、同じくＣＰＵ１４１を備えており、バス１４２を介して各部と接続されている。ＲＯＭ１４３はこの歩数計１１３の各種機能を実現するための制御プログラムを格納しており、ＲＡＭ１４４は作業用メモリとして使用されている。加速度センサ１４５はユーザ１１１の動きに伴う歩数計１１３の上下方向あるいは水平方向の加速度の変化を検出して歩数の計数に利用される。表示部１４６は、歩数の計数結果等の所定のデータを表示する部分であり、携帯端末１１２で説明したように液晶あるいは有機ＥＬディスプレイで構成されている。通信制御部１４７は、歩数の検出結果を予め設定した時刻あるいはユーザ１１１の指示によって、図１で示したモバイルネットワーク１０２を経由して、インターネット１０１上のサービスセンタアプリケーションサーバ１０３に送出するための通信を行う。操作パネル１４８は、歩数のクリアや歩幅の入力等のようにユーザ１１１の入力操作のために使用される。
【００２７】
歩数計１１３は、次に説明する運動量管理システムの一部として活用できるが、ユーザ１１１はこれを本実施例のシステムと切り離して使用することも可能である。たとえば、１日の歩行のカロリを計算して、表示部１４６に表示することができる。なお、ユーザ１１１の所持する携帯端末１１２が図２に示したように加速度センサ１２９を備え、この結果、歩数計としての機能を実現できる場合には、歩数計１１３を必ずしも所持する必要はない。
【００２８】
図１に示したサービスセンタアプリケーションサーバ１０３、地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６は、それぞれ通信機能を持ったパーソナルコンピュータと実質的に同一の機能を備えている。したがって、これらのハードウェアの説明は省略する。
【００２９】
サービスセンタアプリケーションサーバ１０３は、運動量管理システム１００をユーザ１１１に提供する事業者が管理するものであり、次に示す各種データをインターネット１０１あるいはモバイルネットワーク１０２を介して取得するようになっている。
（１）ユーザ１１１が予め登録した歩数計１１３が送信した歩数情報（歩数のカウント値）
（２）モバイルネットワーク１０２に接続された携帯端末１１２または図示しないパーソナルコンピュータ等の情報処理装置からユーザ１１１が入力した基本データ等の各種のデータ。ここでユーザ１１１が入力した基本データとは、たとえば運動量管理システム１００の適用を行おうとするユーザ１１１の住所、最寄のバス停、鉄道の最寄駅、勤務先の住所、勤務先の最寄のバス停あるいは最寄駅、１日の目標となる歩数、メールアドレス、通常の出社時刻、通常の退社時刻、帰宅後あるいは休日の散歩計画を一例として挙げることができる。ここで１日の目標とは、ある程度の長い期間に対する目標値を１日に割り算して平均化したものをいう。もちろん、平日における１日の目標と、休日における１日の目標が異なってもよいが、これはある期間に達成すべき運動量を歩数に換算し、１日当たりの値に直したものをウォーキング等の運動に割ける時間の割合を考慮して調整したものと考えることができる。
（３）携帯端末１１２から送られてくる位置情報
（４）携帯端末１１２から送られてくるユーザ１１１の帰宅情報
【００３０】
一方、地図情報サーバ１０４は、地図についての詳細なデータベースを有しており、ＤＧＰＳによる最良で１メール程度の精度の位置情報を基にした位置の問い合わせに対して、対応する地図情報の回答を行うようになっている。また、乗物情報サーバ１０５は、全国各地の鉄道、バス、ケーブルカー等の情報源にリンクして、これらの乗物の時刻表、料金、路線、指定席の有無等の問い合わせに対して回答を行うようになっている。天候情報サーバ１０６は、ＤＧＰＳ等による位置情報と日時の指定を行った問い合わせに対して天候、温度、湿度、日の出、日の入り、満潮の時刻および波の高さ等の気象情報を回答するようになっている。
【００３１】
サービスセンタアプリケーションサーバ１０３は、このような地図情報サーバ１０４、乗物情報サーバ１０５あるいは天候情報サーバ１０６と通信を行いながら、ユーザ１１１に推奨する推奨プランを複数算出して、携帯端末１１２の表示部１２５に表示する。このとき、ユーザ１１１の所持する携帯端末１１２から送られてくる各種のセンサ情報も参考にされる。センサ情報とは、たとえばＤＧＰＳ通信部１２７による位置情報、温度センサ１３１によるそのときの温度、高度計１３２による現在位置の高度といった情報である。
【００３２】
ここで、推奨プランとは、基本プランを基にしてユーザにそれぞれの時点で提示されるプランである。推奨プランでは、たとえば地図上で出発点と終点を示したナビゲーションシステムの対象となるコースと、そのコースでユーザ１１１が歩行する区間での必要とする歩数、そのコースで出発点から終点に辿り着くまでの予想時間、そのコースの一部に交通機関を利用する場合の電車、バス等の乗り降りの時刻および料金を示した乗車情報、季節や天候を考慮した優先度、平均的な消費カロリ、想定される年齢層が示される。推奨プランには、該当するコースで出発点から終点に辿り着くまでに現われる代表的な景色の写真やウエブ上でのリンク先が添付されていてもよい。これらユーザ１１１の選択対象となる推奨プランは、推奨プラン概要情報として予め指定された送付先に対して、図２で示す通信制御部１２６によって電子メールで送信されるようになっている。
【００３３】
ユーザ１１１は、操作部１３３を用いて携帯端末１１２に先に説明した基本データを入力すると共に、これらを必要に応じて修正する。そして、通信制御部１２６を使用してサービスセンタアプリケーションサーバ１０３に送信する。また、サービスセンタアプリケーションサーバ１０３からユーザ１１１の入力したデータに対する各種の対応情報が電子メールで携帯端末１１２に送られてきた場合には、これらを通信制御部１２６で受信して、表示部１２５に表示する。このうち、サービスセンタアプリケーションサーバ１０３から幾つかの推奨プランが送られてきた場合には、これを表示部１２５に具体的に表示して、ユーザ１１１の選択を促す。そしてユーザ１１１の選択した内容を再度、サービスセンタアプリケーションサーバ１０３に送信して、プランの具体化を進めるようになっている。
【００３４】
地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６は、それぞれサービスセンタアプリケーションサーバ１０３からのインターネット１０１を介して行われる問い合わせに対して、運動量管理システム１００で必要とされ、あるいは有効活用される各種情報を回答（提供）する。この際に、事前に必要に応じて作成されたアプリケーションインターフェースプログラムがサービスセンタアプリケーションサーバ１０３、地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６で動作する。ここで各種情報とは、地図情報、経路情報、乗り物時刻表情報、乗り換え案内、道路鉄道情報、天候情報、花粉情報、災害情報、健康情報、観光情報、旅行情報、宿泊情報、ニュース情報、占い情報等の情報をいう。
【００３５】
ここには、本実施例で使用される地図情報サーバ１０４、乗物情報サーバ１０５および天候情報サーバ１０６といった限定的なサーバの本来のサービスを超えて将来、新しいサーバの追加によってサービスされる有益な情報が含まれていてもよいことは当然である。たとえば、地磁気センサ１２８の出力を用いた電子コンパス機能による進路のトレース機能の提供や、加速度センサ１２９の出力を用いた経路における微細なアップダウン情報の提供、ＤＧＰＳ通信部１２７の出力する位置情報からユーザの現在いる場所を含めた狭い範囲内でのピンポイント天候情報、経路が国境に近い山岳部等の危険地帯の場合における経路内治安情報、電車やホームにおける予想される利用時間における混雑度情報である。また、携帯端末１１２に脈拍センサ１３０の他にオプションとして各種の医療検査装置を取り付けた場合には、体温、脳波、心拍数、心電波形、各種の血中濃度等のユーザ１１１のリアルタイムな体調情報をサービスセンタアプリケーションサーバ１０３が受け取って、医療サーバともいうべきものに送り、ここから得られるデータを参考にして推奨プランを設定したり、あるいはユーザ１１１の選択したプランの実行時にこれを増強方向あるいは抑制方向に修正したり、場合によってはプランの実行そのものを停止させる指示も行われる。
【００３６】
次に運動量管理システム１００の実際の運用を説明する。
【００３７】
図４は、ユーザが携帯端末を使用して運動量管理システムを利用する場合の携帯端末の処理の概要を表わしたものである。図１および図２と共に説明する。まず、サービスのエンドユーザ（最終利用者）としてのユーザ１１１は、携帯端末１１２をインターネット１０１上のサービスセンタアプリケーションサーバ１０３に接続して（ステップＳ２０１）、これとの間で所定の認証手続きを行う（ステップＳ２０２）。ユーザ１１１がまだこのシステムの会員でない場合には、事前に会員登録を行って認証のためのユーザＩＤ（Identification）およびパスワードを発行させる手続きを行っておく。この会員登録の際に、ユーザ１１２は先に示した個人の固有情報（ユーザ１１１の住所、最寄のバス停、鉄道の最寄駅、勤務先の住所、勤務先の最寄のバス停あるいは最寄駅、メールアドレス、通常の出社時刻、通常の退社時刻、帰宅後あるいは休日の散歩計画等の情報）をサービスセンタアプリケーションサーバ１０３に登録しておく。会員登録は、ユーザ１１１の携帯端末１１２で行うこともできるが、図１に示していない自宅あるいはオフィスに配置されたパーソナルコンピュータを使用して行うことも可能である。
【００３８】
認証が成功したら携帯端末１１２にメニュー画面の情報がサービスセンタアプリケーションサーバ１０３から送られてきて表示部１２５に表示される（ステップＳ２０３）。ここで携帯端末１１２はユーザ１１１が新たなプランの作成の項目を選択するかプランの実施の項目を選択するかを監視している（ステップＳ２０４、Ｓ２０５）。ユーザ１１１が操作部１３３を操作して新たなプランの作成を指示した場合には（ステップＳ２０４：Ｙ）、プラン作成モードが実行される（ステップＳ２０６）。これに対して、決定したプランを実施する場合あるいは実施中である場合には（ステップＳ２０５：Ｙ）、プラン実施モードが実行される（ステップＳ２０７）。
【００３９】
＜サービス運用前の基本データの設定＞
【００４０】
図５は、図４で示したプラン作成モードの実行における携帯端末の処理の様子を表わしたものである。ユーザ１１１は、プラン作成モードで携帯端末１１２から今回実施するプランに関する基本データを入力する（ステップＳ２２１）。たとえば旅行中の健康管理であれば、旅行先の場所と１日の目標とする消費エネルギあるいは歩数計１１３を用いた歩数および実施期間を入力する。図３に示した歩数計１１３を使用せず、市販のその他の歩数計を使用する場合にはその旨を入力する。また、自宅とオフィスの間を往復する通勤日の健康管理であれば、その旨の場所の指定と１日の目標とする消費エネルギあるいは歩数計１１３を用いた歩数および実施期間を入力する。なお、会員登録の際に入力した個人の固有情報で今回変更するもの、あるいは変更可能なものがあれば、その内容も入力する。たとえば退社時刻が曜日によって異なったり、向こう数ヶ月間の残業の多少による退社時刻の予測が立てられれば、その内容をサービスセンタアプリケーションサーバ１０３の質問に答える形で携帯端末１１２から入力して送信する。この後、携帯端末１１２はサービスセンタアプリケーションサーバ１０３から基本プランが送られてくるのを待機する（ステップＳ２２２）。
【００４１】
＜基本プランの設定＞
【００４２】
図６は、サービスセンタアプリケーションサーバによる基本プランの設定処理の流れを表わしたものである。図１と共に説明する。サービスセンタアプリケーションサーバ１０３は、携帯端末１１２から基本データを受信すると（ステップＳ２４１：Ｙ）、そのユーザの固有情報と今回、健康管理のために実施するプランの実施地域および実施期間に関する得られたデータを基にして、地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの関係するサーバに関連情報を問い合わせる（ステップＳ２４２）。たとえば通勤日における健康管理であれば、そのユーザ１１１の自宅とオフィスの間の経路に関する情報および散歩計画の基となる経路に関する情報を地図情報サーバ１０４に問い合わせ、出社時刻、通常の退社時刻等における交通機関の情報を乗物情報サーバ１０５に問い合わせ、実施地域における実施期間での天候の長期予報と短期予報とを天候情報サーバ１０６に問い合わせる。
【００４３】
これらの関連情報が地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの関係するサーバから受信されたら（ステップＳ２４３：Ｙ）、これらの関連情報を基にして、たとえば経路、要する歩数、必要な時間からなる基本プランを複数算出する（ステップＳ２４４）。この際に、ユーザ１１１が指定した歩数を達成するために、たとえばバス通勤の場合であれば乗車するバス停を変更したり、電車の乗降駅を変更したり、散歩に割り当てる歩数との調整を行う。各種の組み合わせで、交通機関の経路案内の既存のアプリケーションソフトウェアのように複数の基本プランを作成する。作成された基本プランは該当するユーザ１１１の携帯端末１１２に送信される（ステップＳ２４５）。
【００４４】
図５に戻って携帯端末側の処理の説明を続ける。ユーザ側の携帯端末１１２ではステップＳ２２２でサービスセンタアプリケーションサーバ１０３から基本プランを受信すると（Ｙ）、これをその表示部１２５に表示する（ステップＳ２２３）。そして、複数の基本プランの中で実施すべきプランがあればこれをユーザ１１１が操作部１３３を使用して選択すると（ステップＳ２２４：Ｙ）、その選択内容を示す番号を送信する（ステップＳ２２５）。このとき、ステップＳ２２３で表示された基本プランが最終的なものとなる。そこでこの内容を携帯端末１１２の不揮発メモリ領域に格納して保存する（ステップＳ２２６）。
【００４５】
一方、ステップＳ２２３で表示部１２５に示された基本プランのいずれも最終プランとして選択の対象になり得ない場合には（ステップＳ２２４：Ｎ）、操作部１３３から修正が指示される（ステップＳ２２７：Ｙ）。そこで、この場合にはユーザ１１１が希望する修正内容をそのとき表示部１２５に表示された内容を指定する形で編集が行われる（ステップＳ２２８）。このようにして作成された修正内容は携帯端末１１２からサービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２２９）。
【００４６】
なお、ユーザ１１１の意図する基本プランがサービスセンタアプリケーションサーバ１０３にうまく伝達されず、修正が理想的に行われない場合には、この図には示していないがサービスセンタアプリケーションサーバ１０３側のオペレータにユーザ１１１が修正希望内容を作成して電子メールで送信し、人手による修正処理も可能である。ただし、この場合には基本プランの作成に時間を要したり、制御プログラムを用いて自動的にプランが作成される場合よりも人件費が掛かる分だけ課金が多く発生する場合がある。
【００４７】
再び図６に戻ってサービスセンタアプリケーションサーバ１０３側での基本プランの設定処理の様子を説明する。携帯端末１１２から修正内容が送られてきたら（ステップＳ２４６：Ｙ）、地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの修正内容に必要なデータを所持するサーバに修正のための関連情報の問い合わせが行われる（ステップＳ２４７）。たとえば、ある基本プランは大枠で賛成するが、その中の電車の一駅を歩いて歩数を伸ばすという箇所に対して、一駅先は急行が停車しない駅なのでバス停まで歩く距離を遠くした方がよいというユーザ１１１からの修正要求があったとする。この場合には、サービスセンタアプリケーションサーバ１０３がパスの路線図における各バス停の歩行距離を乗物情報サーバ１０５に問い合わせ、ここから目標とする歩数を満足させるバス停を探すことになる。
【００４８】
要求した関連情報が地図情報サーバ１０４、乗物情報サーバ１０５、天候情報サーバ１０６のうちの該当する１または複数のサーバから得られたら（ステップＳ２４８）、サービスセンタアプリケーションサーバ１０３は基本プランを修正する（ステップＳ２４９）。このとき、修正の可能性が複数存在するときには、複数の基本プランが作成されて、これらのうちの１つをユーザ１１１に選択させる形にして、これらの基本プランを再び携帯端末１１２に送出する（ステップＳ２４５）。
【００４９】
図５のステップＳ２２５で説明したようにユーザ１１１が最適の基本プランを見つけてこれを選択した場合には、選択した旨の受信が行われる（ステップＳ２５０：Ｙ）。サービスセンタアプリケーションサーバ１０３はこの受信があると、ユーザ１１１が選択した番号の基本プランを決定内容として登録して（ステップＳ２５１）、この基本プランに参加する独立して制御を行うセンサに対してそれらの制御すべき内容を通知する（ステップＳ２５２）。歩数計１１３が独立してモバイルネットワーク１０２を経由して検出結果を通知するものとしてユーザ１１１がサービスセンタアプリケーションサーバ１０３に設定していたとする。この場合には歩数計１１３に対して期間と時間を指定して検出結果をサービスセンタアプリケーションサーバ１０３に通知する旨の制御内容が通知されることになる。このような歩数計１１３を使用せずに通信機能を備えない簡易な歩数計を使用する場合には、歩数計の検出結果はユーザ１１１がサービスセンタアプリケーションサーバ１０３の指示に従ってこれに送信することになる。ステップＳ２５２の処理が行われると、基本プランの設定処理が終了する（エンド）。なお、基本プランの修正が１回で終了しない場合には、ステップＳ２４６に示した修正内容の受信が所定の回数繰り返され、そのたびに修正された複数のプランの中の１つが最終的に選択されることになる。
【００５０】
＜基本プランによる１日目の実施＞
【００５１】
このようにして基本プランの設定が行われたら、ユーザ１１１は図５のステップＳ２２６で保存した基本プランに従って１日目は指示された経路による歩行を実施する。このとき、図１に示した歩数計１１３がユーザ１１１の歩行を記録する。図２に示した脈拍センサ１３０あるいはオプションで取り付けた各種のセンサもユーザ１１１の健康状態をチェックすることになる。
【００５２】
図７は、本実施例のユーザの自宅と会社の間の経路の概要を表わしたものである。ユーザ１１１の自宅１５１の傍にはＡ1バス停が存在し、Ａ10バス停との間にバス１５２が運行している。Ａ10バス停の傍に電車のＢ1駅があり、ここからＢ10駅まで急行電車１５３が走っている。Ｂ10駅から徒歩で５分弱の距離のところに勤務先のＣ会社１５４がある。自宅１５１の傍には公園１５５があり、ウォーキングを行うことができる。Ｃ会社１５４とＢ10駅まではアーケード付の商店街１５６があり、昼休みには食事をしたりウィンドウショッピングを行うことができる。また、雨の時にも傘をささずに歩くことができる。
【００５３】
図８は、このユーザの平日の基本プランを表わしたものである。図１に示したユーザ１１１は朝８時に図７に示した自宅１５１を出発し、８時５分発のバス１５２に乗車してＡ10バス停で降車して、傍のＢ1駅から急行電車１５３に乗る。そしてＢ10駅からＣ会社１５４まで歩いて行く。１２時から１３時までが昼休みであり、１７時３０分に業務が終了して、１８時５０分に自宅に帰る。着替えをして、１９時から３０分程度、公園１５５でウォーキングを行う。
【００５４】
図９は、歩数計の処理の様子を表わしたものである。歩数計１１３はサービスセンタアプリケーションサーバ１０３から制御内容が送信されてくると（ステップＳ２７１：Ｙ）、今まで格納されていた制御内容の該当する箇所を上書きして内容の更新を行うようになっている（ステップＳ２７２）。歩数計１１３のように独立してサービスセンタアプリケーションサーバ１０３との間の通信制御を行うセンサに対して送られる制御内容には、ステップＳ２５２（図６）で示した１つの基本プランに沿った通常のものと、状況の変化に対応して送ってくる臨時のものとがある。たとえば、心拍計が独立して通信制御されるセンサとして使用されている場合、通常は歩行等の運動期間が開始する前の心拍数がまずサービスセンタアプリケーションサーバ１０３に送信され、運動期間が終了した時点で運動中の平均値が次に送信される。ところが、運動前の心拍数が平常よりも高いような場合や、体温が平熱以上のような場合のように何らかの異常の発生が察知される場合には、心拍数の測定結果を送信時間間隔を狭めて繰り返し送信させるような臨時の制御内容がサービスセンタアプリケーションサーバ１０３から心拍計に送信され（ステップＳ２７１：Ｙ）、次に新たな制御内容が送られてくるまでの間、そのセンサは更新された制御内容で制御を行うことになる。
【００５５】
本実施例の歩数計１１３の場合、図６のステップＳ２５２で制御内容を受信したら、これを基にして測定を開始する日時が到来したかの監視（ステップＳ２７３）と、測定を終了する日時が到来したかの監視（ステップＳ２７４）を逐次行う。たとえばサービスセンタアプリケーションサーバ１０３から送られてきた制御内容が、以下のようなものであったとする。
【００５６】
（１）期間 ２００５年１０月１日から２００６年１月３１日まで。
（２）午前０時から正午の１２時まで測定を行って第１回の送信を行う。
（３）正午の１２時から帰宅した時刻の夕方１８時５０分までの測定を行って第２回目の送信を行う。
（４）公園でのウォーキングや家庭内の歩行の測定を行って、１日の終了する２４時に第３回目の送信を行う。
【００５７】
このような制御内容の場合、歩数計１１３は２００５年１０月１日の午前０時が到来すると測定開始日時になったので（ステップＳ２７３：Ｙ）、測定値を“０”にリセットして歩数の測定を開始する（ステップＳ２７５）。もちろん、ユーザ１１１が歩数計１１３を身につけておらず就寝中の場合には、朝起きるまでカウントは行われない。この後、同年１０月１日の正午になると、第１回目の測定終了日時となり（ステップＳ２７４：Ｙ）、今まで測定した測定値が読み取られ、サービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２７６）。この送信動作と平行して同年１０月１日の正午に測定値の読み取りが終了したら、午前中の測定値がリセットされて午後の測定が開始される（ステップＳ２７３：Ｙ、ステップＳ２７５）。そして、夕方１８時５０分になると、２回目の測定終了日時ということで（ステップＳ２７４：Ｙ）、正午の１２時から開始した測定値が読み取られ、サービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２７６）。そして再び測定値がリセットされて１日の終了する２４時までの測定が開始される（ステップＳ２７３：Ｙ、ステップＳ２７５）。この後、１日の終了する２４時に１日の最後の測定（３回目の測定）が終了して（ステップＳ２７４：Ｙ）、そのときの測定値がサービスセンタアプリケーションサーバ１０３に送信される（ステップＳ２７６）。
【００５８】
歩数計１１３による２日目以降の測定も同様である。ただし、本実施例では前日の測定結果を次の日以降の測定に反映させるようにしている。したがって、１日目については、この例で示したように合計３回の送信を歩数計１１３が行う必要は必ずしもなく、１日の終了する２４時に１日の合計の測定値を送信するようにしてもよい。１日目について測定値の送信が３回行われたような場合、サービスセンタアプリケーションサーバ１０３はユーザ１１１に対応付けてこれらの測定値を受信すると、単純に加算して１日分の測定値とする。なお、サービスセンタアプリケーションサーバ１０３との通信機能を備えない簡易な歩数計を使用した場合、ユーザ１１１は携帯端末１１２に予め定めた時刻ごとに測定値を見てその結果を通知する。サービスセンタアプリケーションサーバ１０３からメールがそれぞれの時刻ごとに送信され、これに返答する形で測定値を知らせるようにしてもよい。
【００５９】
なお、上記のようなスケジュールの場合、ユーザ１１１は平日と土曜日あるいは日曜日等の休日で異なった行動を採る。すなわち、平日は通勤を行うが、休日はこれを行わない。しかしながら、ユーザ１１１の選択した基本プランでは１日３回の測定を行う場合にそれぞれの測定期間および測定結果の報告はすべての日で同一の時刻でよいということで、制御内容に平日と休日の区別を行っていない。平日と休日でこれらに違いがある場合には、制御内容の指定を更に細かく行うことになる。また、平日であっても休暇を採って通勤を行わないような場合や、出張で通常と異なる勤務形態を採るような場合には、サービスセンタアプリケーションサーバ１０３に通知して制御内容を必要に応じて変えることが可能である。ただし、本実施例では前日までの測定結果を次の日以降に反映させていくので、歩数等の目標値をそれぞれの日で厳密に達成する必要はなく、多少の過不足を生じさせながら期間全体で帳尻を合わせるようにすることができる。
【００６０】
また、図９では時刻を基にして歩数計の制御を行っているが、現実にはユーザ１１１の帰宅時刻等の各種設定時刻はスケジュールと一致しない場合が多い。そこで、サービスセンタアプリケーションサーバ１０３は携帯端末１１２のＤＧＰＳ通信部１２７が測定した位置情報を必要に応じて取得し、ユーザが経路のどの位置に居るかを判別することで自宅１５１に到着したとかＣ会社１５４から退社したタイミングを正確に判別するようにしている。ただし、本実施例では煩雑になるため、時刻通りにユーザ１１１が行動しているものとして単純に説明を行う。
【００６１】
＜基本プランの修正による２日目以降の実施＞
【００６２】
さて、２日目以降ではサービスセンタアプリケーションサーバ１０３が今までのウォーキング等のプログラムによるユーザ１１１の運動量を把握しながら、基本プランを随時補正しする。そして、その時々の気象等の運動環境の変化も加味しながらその日、その時の推奨プランを作成してユーザ１１１に提示することになる。
【００６３】
図１０は、サービスセンタアプリケーションサーバによる２日目以降の処理の流れを表わしたものである。２日目以降では、ユーザ１１１が最初の行動を開始する数時間前にサービスセンタアプリケーションサーバ１０３がその日の推奨プランを作成する。本実施例では、図８の平日の基本プランによると朝８時にユーザ１１１が自宅を出発する。そこでこれよりも２時間早い午前６時になると（ステップＳ２９１：Ｙ）、サービスセンタアプリケーションサーバ１０３は推奨プランを作成する際に必要とする各種のサーバにアクセスして、当日のための情報を取得する。本実施例の場合には乗物情報サーバ１０５と天候情報サーバ１０６にアクセスして当日の情報を取得し（ステップＳ２９２）、前日の歩数計１１３の測定値と当日の天候等の情報から、基本プランを修正した推奨プランを複数作成する（ステップＳ２９３）。
【００６４】
たとえば、前日の歩数が目標値に大きく及ばなかったような場合には、自宅１５１から最寄のＡ1バス停まで歩いてバス１５２に乗っていたものを、少しだけ早く出発して次のＡ2バス停まで歩いてバス１５２に乗るような第１の推奨プランや、Ａ1バス停から乗車することを変更しない代わりに、昼休みにＣ会社１５４からＢ10駅まで往復することを新たに追加する第２の推奨プラン等の複数の推奨プランを提示する。このようにして歩数の足りなかった分を補う修正を行う。
【００６５】
もちろん、気象上の原因で推奨プランを作成あるいは修正することも可能である。たとえば当日は台風が近づいてきており、Ｂ1駅と図示しないＢ3駅の間が冠水してその区間の鉄道が不通となっていたような場合、自宅１５１から図示しないＤ1バス停まで歩いて行って、ここから他の図示しないバスルートを利用してＢ3駅の近くまでバスで行くといった推奨プランへの変更を行うことができる。
【００６６】
このようなプラン変更の場合、自宅１５１からＤ1バス停までの距離がＡ1バス停までの距離よりも遠い場合には、その分だけ運動量が増加することになる。したがって、前日までの運動量が特に不足していないユーザの場合、次の推奨プランではたとえば公園１５５でのウォーキングの時間を短縮させるといったプランの修正を行うことになる。もちろん、ユーザ１１１は運動量の超過を次の休日に持ち越して、体の休息を図ることも可能である。
【００６７】
なお、サービスセンタアプリケーションサーバ１０３は各種の推奨プランを作成するとき、午前と午後で気象条件が異なるような場合には、ユーザ１１１にこれを気象情報と共に提示して、ウォーキングの実現し易い環境あるいは運動を適正に行える環境を提案することができる。たとえば、ユーザ１１１が通常は自宅１５１からＡ2バス停まで歩いて、その分の歩数を稼いでいたとする。朝の天候が雨で夕方の天候が晴になるような場合には、朝は自宅１５１の傍のＡ1バス停からバス１５２に乗り、帰りは自宅１５１からＡ2バス停よりも遠いＡ3バス停で降りて自宅１５１に帰るというような推奨プランを提案することで、雨に濡れずに必要とする運動量を確保することができる。
【００６８】
ステップＳ２９３で推奨プランを作成したら、サービスセンタアプリケーションサーバ１０３は当日用に作成したこれら複数の推奨プランを携帯端末１１２に電子メールで送信する（ステップＳ２９４）。そして、その後、ユーザの携帯端末１１２との間でプランの選択や修正のための処理を行う（ステップＳ２９５）。具体的には、ユーザ１１１が複数の推奨プランの中から１つを最終的なプランとして選択すれば、これが実施するプランとして確定する。また、ユーザ１１１が内容を指定して修正を要求してきた場合には、これを反映した１または複数の推奨プランが作成されてステップＳ２９４で再び携帯端末１１２に送信されることになる。ここで、推奨プランの修正を行うためにサービスセンタアプリケーションサーバ１０３は地図情報サーバ１０４、乗物情報サーバ１０５あるいは天候情報サーバ１０６に対して新たなデータを要求する場合があることは当然である。
【００６９】
このようにして最終的に１つの推奨プランが選択されたら、サービスセンタアプリケーションサーバ１０３は当日の第１回目に実行される推奨プランをユーザの携帯端末１１２に送信することになる（ステップＳ２９６）。本実施例の場合には朝８時から正午の１２時までの推奨プランがユーザ１１１の自宅１５１を出発する前の十分早い時刻に推奨プランが提示される。したがって、ユーザ１１１は指示された時刻に歩数計１１３を携行して自宅１５１を出発し、午前中のエクササイズを実行することになる。
【００７０】
サービスセンタアプリケーションサーバ１０３は当日の２回目以降の推奨プラン開始前の所定の時刻の到来を監視している（ステップＳ２９７）。本実施例では２回目の推奨プランが開始される正午の１２時がこの時刻となる。この時刻が到来すると（Ｙ）、サービスセンタアプリケーションサーバ１０３は２回目の推奨プランを実施するのに必要な各種サーバの情報を取得する（ステップＳ２９８）。たとえば天候が変わっており、昼休み中に雨が降りそうなときには天候情報サーバ１０６にアクセスして最新の予測情報が取得される。特に追加的に必要とされる情報が存在しない場合には、地図情報サーバ１０４、乗物情報サーバ１０５あるいは天候情報サーバ１０６へのアクセスは省略することができる。サービスセンタアプリケーションサーバ１０３は以上の処理の後、１回目の推奨プランによる運動量の取得結果を加味して推奨プランを必要により修正する（ステップＳ２９９）。そして、その推奨プランをユーザの携帯端末１１２に送信する（ステップＳ３００）。
【００７１】
このように当日の２回目以降では推奨プランの大幅な修正は行われない。これは、ユーザ１１１がステップＳ２９５で当日のプランを詳細に煮詰めているので、煩雑な手続きを省略するためである。もちろん、ユーザによってはシステムの初期設定のときに、たとえば早朝の詳細な修正等の処理を就寝前の時間帯に移動させる等の各種変更が可能である。
【００７２】
サービスセンタアプリケーションサーバ１０３は、この他、歩数計１１３あるいは携帯端末１１２に備えられたＤＧＰＳ通信部１２７、地磁気センサ１２８、加速度センサ１２９、脈拍センサ１３０、温度センサ１３１および高度計１３２といった部品から得られるデータを受信すると（ステップＳ３０１）、これらを解析して緊急処理が必要であるかどうかを判別する（ステップＳ３０２）。そして、たとえば歩行中に脈拍センサ１３０が異常な数値変化を示しているというような場合には（Ｙ）、予め定めた緊急処理を実行する（ステップＳ３０３）。たとえば、携帯端末１１２に対して脈拍が異常に高いことを記した定型文からなる電子メールを送信し、ウォーキングの速度を低下させる指示を行う。
【００７３】
特に緊急性を要しないデータが受信された場合には（ステップＳ３０２：Ｎ）、次回の推奨プランの作成のためのデータとしてサービスセンタアプリケーションサーバ１０３の図示しない作業領域に一時的に格納する（ステップＳ３０４）。たとえば、歩数計１１３から送られてくる歩数情報は、この作業領域から所定のタイミングで読み出されて、次の推奨プランの作成のために使用される。
【００７４】
以上のサービスセンタアプリケーションサーバ１０３の制御を基にして２日目のユーザの行動例を具体的に説明する。たとえばユーザ１１１が水平な土地を歩くと仮定して歩数計１１３で１日１００００歩を達成することを目標としていたとする。なお、本実施例では図１に示した地図情報サーバ１０４によってユーザ１１１が歩行する道の傾斜の度合いの概要をサービスセンタアプリケーションサーバ１０３が判別しており、歩数に対する運動量の補正を行っているが、この詳細は省略し、水平な土地を歩くものと仮定して説明する。
【００７５】
歩数計１１３から得られたユーザ１１１の初日の歩数情報が８０００歩であったとする。この場合、１日目で２０００歩が不足していたことになる。ユーザ１１１の歩幅が０．５であるとすると、これは水平な土地の１キロメールに相当する。サービスセンタアプリケーションサーバ１０３は、基本プランの自宅から最寄のＡ1バス停まで歩いてバス１５２に乗る経路と、Ａ2バス停あるいはＡ3バス停まで歩いてバス１５２に乗る３系統の変更案を作成し、それぞれについて昼休みおよび自宅１５１に到着してからの商店街１５６あるいは公園１５５で行うウォーキングの時間の増加量によって２０００歩の不足を実質的に補う推奨プランを作成する。１系統についてそれぞれ３通りの案があるとして、全部で９通りの推奨プランが初期的に作成される。サービスセンタアプリケーションサーバ１０３は、その日に雨が降るような場合には、アーケード付の商店街１５６のようにウォーキングに障害が生じないようなコースを増加分に積極的に割り当てたり、傘をさしながら長時間歩くコースを除外して、最終的に実現可能性の高い幾つかの推奨プランを決定する（図１０ステップＳ２９３）。
【００７６】
この推奨プランは、朝６時過ぎに携帯端末１１２に送信される。ユーザ１１１は、朝起きた時点で携帯端末１１２の電子メールをチェックして、送信されてきた複数の推奨プランを見て、その中で実行したいものがあればそれを選択する。また、修正が必要な場合にはその旨の通知を行う（ステップＳ２９５）。このようにして当日の１回目の推奨プランが確認のために携帯端末１１２に送られてくる。ここでユーザ１１１は、自宅１５１を早く出発してＡ2バス停まで歩く推奨プランを選択したものとする。
【００７７】
図１１は、ユーザが選択した２日目の推奨プランを表わしたものである。この推奨プランで基本プランから変更された項目には※１６１が付されており、また、訂正された箇所には太字処理を行ったり、その部分の色を変える等の強調表示が行われている。これは、ユーザ１１１が変更箇所を容易に確認できるようにするためである。この２日目の推奨プランでは「自宅出発」が朝８時から朝７時５３分に変更されており、バス１５２（図７）に乗る場所もＡ1バス停から１つ先のＡ2バス停に変更されている。また、昼休みのウォーキングが新たに１０分間新設され、自宅１５１に帰った後に行うウォーキングが３０分から３５分に変更されている。また、推奨プランの末尾のコメント欄１６２には、「２０００歩の運動不足を解消しよう！」というメッセージが記入されており、ユーザ１１１への１日の目標が示されている。
【００７８】
ユーザ１１１は食事をいつもより早くして、朝７時５３分よりも更に早く７時４５分に自宅１５１を出発したものとする。ユーザ１１１の歩行は歩数計１１３で計数され、また、歩行経路は図２に示した携帯端末のＤＧＰＳ通信部１２７から適宜、サービスセンタアプリケーションサーバ１０３に送信される。この結果、ユーザ１１１が自宅１５１を出発した時刻がサービスセンタアプリケーションサーバ１０３に通知される。また、ユーザ１１１がＡ2バス停に到着する時点で、サービスセンタアプリケーションサーバ１０３は更に次のＡ3バス停のバス発車時刻と、Ａ3バス停に到達するために必要な時間から現在の歩行スピードによる到達予想時刻を携帯端末１１２に送信する。ユーザ１１１は到達予想時刻がＡ3バス停のバス発車時刻よりも早ければ、Ａ3バス停を目指して歩き続けることができる。なお、このようにユーザ１１１が現実にバスに乗ろうとしている状況で、サービスセンタアプリケーションサーバ１０３は乗物情報サーバ１０５と追加的に交信して、バスの実際の運行状況から各バス停のバス発車時刻をリアルタイムに書き換えることができる。
【００７９】
このようにしてユーザ１１１がＡ3バス停からバスに乗車したとすると、これによりＣ会社１５４に行くまでの歩行は目標を超えて達成されたことになる。その後も会社内で仕事のための移動が歩数計１１３によって積算されていく。会社内でエレベータの利用を控え、階段を積極的に利用することでも歩数の計数の増加につながる。
【００８０】
昼の１２時になると、歩数計１１３が当日の１回目のカウント値としての歩数計１１３をサービスセンタアプリケーションサーバ１０３に送信する。サービスセンタアプリケーションサーバ１０３はたとえばこの情報と天候情報サーバ１０６から新たに得られた情報を基にして、当日の２回目の推奨プランの修正を行う（ステップＳ２９９）。
【００８１】
図１２は、当日２回目の推奨プランを表わしたものである。２回目の推奨プランでは、１回目の推奨プランの消化状況と、２回目以降の推奨プランが携帯端末１１２の表示部１２５（図２）に表示される。１回目でユーザ１１１はＡ3バス停まで余計に歩いてバス１５２に乗ったばかりでなく、Ｂ10駅に着いた後はＣ会社１５４まで回り道をしてウォーキングを５分間余計に行っている。これらのユーザ１１１の努力によって、昼休みに商店街１５６を１０分間散策すれば、帰宅後に課せられていた５分超過の３５分のウォーキングが通常の３０分で済むことに推奨プランの修正が行われている。推奨プランの末尾のコメント欄１６２には、１回目に示された２０００歩の超過目標が７００歩に減少している。
【００８２】
なお、コメント欄１６２に表示される過不足の歩数等の情報は、必ずしも当日の終了時に運動量の帳尻が合うようにする観点からの情報である必要はない。仕事が数日間集中して運動不足となったような場合、次の１日で不足した運動量を取り戻すように過度の運動を行うことは体を壊す要因となる。そこで、ユーザは１日の最大歩数あるいは最大運動量を定めてこれの許す範囲で不足した歩数を数日間掛けて埋め合わせたり、数日あるいは１週間程度で帳尻が合うように不足分を平均化して、それぞれの日に分けるようにしてもよい。また、病気の後のような場合には、数日間、運動量を通常時の基本プランと同一あるいはこれよりも低く設定して、その後に運動不足分を順次取り戻すように日々の推奨プランを割り当てることも可能である。
【００８３】
ところで、ユーザ１１１は昼休みに近くの友人が食事を誘ったため、指示された１０分間のウォーキング（辺りの散策）ができなかったとする。ただし、午後に仕事先の会社を訪問する仕事が発生し、往復で２０分のウォーキングが新たに発生したとする。歩数計１１３および携帯端末のＤＧＰＳ通信部１２７がこれらについても監視し、サービスセンタアプリケーションサーバ１０３に通知する。これらの結果、サービスセンタアプリケーションサーバ１０３はユーザ１１１の帰宅した夕方１８時５０分に２回目の測定結果を集計して、天候情報サーバ１０６等から新たに得られた各種の情報も加味しながら３回目の推奨プランを携帯端末１１２に送信する（図１０ステップＳ３００）。なお、帰宅時間は携帯端末のＤＧＰＳ通信部１２７の通信結果によって最終的に判別されるので、サービスセンタアプリケーションサーバ１０３は帰宅後の推奨プランを帰宅の時間のずれに係らず正確に算出することができる。
【００８４】
図１３は、当日最後の３回目の推奨プランを表わしたものである。３回目の推奨プランでは、１回目および２回目の推奨プランの消化状況と、３回目の推奨プランが携帯端末１１２の表示部１２５（図２）に表示される。２回目が終了した時点で昨日の２０００歩の不足が解消され、更に３００歩が超過したので、帰宅後に行われる公園１５５（図７）でのウォーキングが３０分から２０分に短縮されている。コメント欄１６２には、現時点で３００歩目標が超過したことと、運動量の過不足が当日の運動で解消すれば、明日は基本プランと一致した推奨プランの実施が可能であることが記されている。
【００８５】
なお、この帰宅後に行われる当日３回目の推奨プランは、帰宅までに行われた歩行プランに対して、その不足分を補うリカバリプランとして位置づけることもできる。すなわち、この実施例でユーザ１１１は帰宅後の公園１５５でのウォーキングを基本プランに加えたが、帰宅の時点で目標とするウォーキング等による運動量に到達することを前提として、到達できなかったときにのみリカバリとして付加的なウォーキングを追加するようにしてもよい。
【００８６】
＜当日の運動達成状況と翌日の推奨プランの確認＞
【００８７】
図１４は、ユーザがサービスセンタアプリケーションサーバに対して運動に関して各種の表示要求を行った場合の処理の流れを表わしたものである。ユーザ１１１は携帯端末１１２を健康管理に関する所定のモードに設定して、幾つかの表示要求を行うことができる。本実施例では、一日の運動を終了したときの当日の実績の表示要求と、１日の現時点における目標達成状況の表示要求と、翌日の推奨プランの表示要求の３つを行うことができる。
【００８８】
ユーザ１１１は、１日の運動が終了した時点でその１日の実績の表示を要求することができる。サービスセンタアプリケーションサーバ１０３がこの要求を受信すると（ステップＳ３１１：Ｙ）、当日の最終結果をすでに受信しているかどうかのチェックが行われる（ステップＳ３１２）。先に説明した例では、３回目の送信が１日の終了する深夜２４時に行われるようになっている。これは、ユーザ１１１によっては遅く帰ってくる日もあるし、深夜に自宅のウォーキングマシンでウォーキングを行うこともある。そこで、その日の歩数計１１３の計数はできるだけ日にちが変わる直前で行うようにしているためである。
【００８９】
しかしながら、ユーザ１１１によっては自宅１５１に帰って夕食を食べた後は公園１５５等の場所による運動を行わないことにしており、むしろその日の運動が終わったとして、１日の実績を検討したいと思う者もある。そこでサービスセンタアプリケーションサーバ１０３は当日の実績の表示要求を行った携帯端末が最終結果を受信しているかどうかを判別する（ステップＳ３１２）。そして、最終結果がまだサービスセンタアプリケーションサーバ１０３に送られていないことが判別した場合には（Ｎ）、携帯端末１１２に対してその日の最終結果の送信を要求する（ステップＳ３１３）。そして、最終結果が受信された時点で（ステップＳ３１４：Ｙ）、当日の実績の報告を作成して（ステップＳ３１５）、これを該当する携帯端末１１２に送信する（ステップＳ３１６）。この場合、携帯端末１１２は規定の時間に行われる３回目の送信を行わない。実施例では１日の終了する深夜２４時に第３回目の送信を行うことにしているが、これよりも前にその日の最終報告がサービスセンタアプリケーションサーバ１０３に行われたことになるので、重複した報告を避けることになる。ステップＳ３１２で既に当日の最終結果をサービスセンタアプリケーションサーバ１０３が受信している場合には（Ｙ）、要求された時点で当日の実績報告を作成して（ステップＳ３１５）、携帯端末１１２に送信することになる（ステップＳ３１６）。
【００９０】
また、サービスセンタアプリケーションサーバ１０３に対してその時々の目標達成状況の要求があった場合には（ステップＳ３１７：Ｙ）、現時点での歩数計１１３の歩数のカウント値の送信を歩数計１１３に要求する（ステップＳ３１８）。たとえば、リカバリ処理として先のユーザ１１１が公園１５５でウォーキングを行っている最中で、目標を達成したかを知りたい場合がある。このようなとき、サービスセンタアプリケーションサーバ１０３は歩数計１１３に現時点の計数した歩数の送信を要求し、結果を受信したら（ステップＳ３１９：Ｙ）、その日の今までの歩数に加算して目標との差し引きを行い、目標達成状況報告を作成する（ステップＳ３２０）。そして、これを携帯端末１１２に送信して表示させることになる（ステップＳ３１６）。なお、ユーザ１１１が独自に通信機能を有する歩数計１１３を使用せず、簡易な歩数計を代わりに使用していた場合には、携帯端末１１２に対して現時点の計数した歩数の送信が要求されることになる。この場合、ユーザ１１１はその簡易な歩数計の数値を見て、これを携帯端末１１２からサービスセンタアプリケーションサーバ１０３に送信することになる。
【００９１】
また、ユーザ１１１は就寝前の所定の時点に翌日の推奨プランを把握しておきたい場合がある。このような場合、サービスセンタアプリケーションサーバ１０３に対して翌日プラン要求が携帯端末１１２から送信されることになる。サービスセンタアプリケーションサーバ１０３は翌日プラン要求を受信すると（ステップＳ３２１：Ｙ）、ステップＳ３１２で説明したようにその日の最終結果が受信されているかどうかを判別し（ステップＳ３２２）、まだ受信されていない場合には（Ｎ）、これを要求して（ステップＳ３２３）、取得する（ステップＳ３２４：Ｙ）。そして、翌日の推奨プランを作成する（ステップＳ３２５）。翌日の推奨プランは、図１０のステップＳ２９１で１回目のプランの開始２時間前（実施例では朝６時）に作成するようにしていたのを先倒しすることになる。これにより、たとえば早朝に発生した交通機関の障害や天候の急変に対応することはできないが、朝起きる時間や朝食の時間を就寝前に確定させることができる。
【００９２】
もちろん、システムの設定によっては図１０のステップＳ２９１〜Ｓ２９３の処理を再度行わせ、このとき就寝前に決定した推奨プランも含めて複数のプランを提示させて、ユーザ１１１に選択させるようにしてもよい。これにより、ユーザ１１１は前日に立てた推奨プランだけでなく、当日の状況に応じて新たに作成された推奨プランも含めて、当日実際に実施するプランを選択することができる。
【００９３】
以上説明した実施例では説明を簡略化するために歩数計１１３を用いたウォーキング中心とした健康管理を説明した。本発明はこれに限らず、歩数計１１３の１カウント当たりのカロリ消費量をウォーキングの場合に換算することで、ジョギングを組み合わせた健康管理に適用することができる。この場合のウォーキングとジョギングの判別には、たとえば携帯端末１１２のＤＧＰＳ通信部１２７の測定した位置情報の変化を用いたり、加速度センサ１２９の検出結果を用いることができる。また、ユーザ１１１が運動の種別を携帯端末１１２から入力することも可能である。
【００９４】
ウォーキングやジョギング以外に同様にしてサイクリング、ローラスケーティング、テニスといった各種のスポーツを含めた健康管理を行うことができる。また、１週間のうちの何日かをスポーツジムに通っている者は、その施設を出た時点等の所望の時点で、予め作成したフォームにエロビクスを３０分行ったとか、プールで１キロ泳いだとかのデータを携帯端末１１２からサービスセンタアプリケーションサーバ１０３に送信することで、これらの運動を加味したある期間における運動量の管理を行うことができる。
【００９５】
また、実施例では平日におけるユーザの自宅と勤務地の間の往復および近所でのウォーキングについて説明したが、日曜日等の休日についても本発明を適用して比較的長期間にわたった健康管理を実現することができる。これを次に変形例として説明する。
【００９６】
＜本発明の変形例＞
【００９７】
図１５は、本発明の変形例として、図５のステップＳ２２１で説明した基本データの入力における休日プランの入力画面の一例を表わしたものである。ここでは、ウォーキングに関するプランを表わしている。図１に示したユーザ１１１は携帯端末１１２あるいは図示しないパーソナルコンピュータを用いてサービスセンタアプリケーションサーバ１０３にアクセスし、この休日プランの入力画面１７１を表示することができる。
【００９８】
休日プランの入力画面１７１には、その休日の１日当たりの目標とする歩数を入力欄１７２に入力する。平日にウォーキングを順調に行う想定の場合には、ここには通常の１日に課せられている歩数を入力すればよいが、平日は忙しく十分な運動を行えないことが想定される場合には、休日にこれらの運動不足を補う歩数を入力すればよい。
【００９９】
ウォーキングコースは、ユーザ１１１の自宅１５１からあまり離れていない箇所で行う「付近の散策コース」と、電車やバス、マイカーあるいは飛行機といった交通機関を利用して多少の遠出をする「レジャーを兼ねたウォーキングコース」に分かれている。後者の場合には日数入力欄１７３に出発から帰るまでの日数を入力する。また、行き先の希望を特定するための選択肢１７４が設けられており、これらについてのラジオボタンが配置されている。更に、ウォーキングの参加者がユーザ本人だけか、グループで参加するかを入力することで、年齢に応じたコースの選定が行えるようになっている。更に、送信ボタン１７５の横には観光情報ボタン１７６が配置されており、ユーザ１１１はウォーキングに適した観光場所についての各地の情報を収集することができる。これによって観光場所が特定した場合には、行き先の希望を特定するための選択肢１７４の「観光地」の箇所の観光地入力欄１７７に具体的に観光地を入力すればよい。
【０１００】
図１６は、この変形例におけるサービスセンタアプリケーションサーバによる休日プランの処理の様子を表わしたものである。サービスセンタアプリケーションサーバ１０３は、図１５に示した休日プランの受信があると（ステップＳ３４１：Ｙ）、「付近の散策コース」が指定されている場合（ステップＳ３４２：Ｙ）、予め作成しておいた全国の散策コース集からユーザ１１１の住んでいる地区のデータを抽出する（ステップＳ３４３）。そしてこれをコース案内としてユーザ１１１の携帯端末１１２あるいは特定のパーソナルコンピュータに送信する（ステップＳ３４４）。
【０１０１】
休日プランが「レジャーを兼ねたウォーキングコース」であった場合には（ステップＳ３４２：Ｎ）、送られてきたデータにおけるレジャーの日数、参加する者の年齢サイズ構成および希望地に合わせて全国のウォーキングに適した場所を複数検索する（ステップＳ３４５）。このとき、観光地が「おまかせ」として指定されていた場合には天候情報サーバ１０６に問い合わせて実施日に天候がよい観光地でスケジュールおよびウォーキングに適するものを複数選択する。観光場所が指定されている場合には、その中でウォーキングに適する場所を複数ピックアップする。そして、抽出した複数の場所を、たとえばサービスセンタアプリケーションサーバ１０３の運営会社に対して観光協会、旅行会社、ホテル業界等の紹介元から紹介料が多く徴収できるもの、あるいはその可能性が大きいものから順に所定数のコースを抽出して（ステップＳ３４６）、コース案内を送出する（ステップＳ３４４）。
【０１０２】
したがって、サービスセンタアプリケーションサーバ１０３の運営会社は、観光協会、旅行会社、鉄道、バス会社等の旅行関連会社とタイアップして、ユーザ１１１が満足するウォーキングのための各種のコースを作成し、「レジャーを兼ねたウォーキングコース」の内容を充実させることで、収益を増やすことができる。もちろん、運営会社はユーザ１１１からウォーキングコース案内の料金を会費等の形で徴収することもできるし、ウォーキング等の運動関連のグッズの販売や関連ホームページへのリンクによって手数料を得ることも可能である。
【０１０３】
本実施例のサービスセンタアプリケーションサーバ１０３は、ウォーキングに関連した休日に関する各種の予約業務も行っている。ユーザ１１１から予約を受信すると（ステップＳ３４７：Ｙ）、ホテル、旅館等の宿泊施設や、電車、飛行機等の乗物の予約を行い、手数料を含めた課金を行う（ステップＳ３４８）。
【０１０４】
なお、図１５に示した休日プランは、ユーザ１１１の基本データの作成の一環として提示することにしているが、これに限るものではない。サービスセンタアプリケーションサーバ１０３は、個々のユーザの運動の過不足をチェックして、たとえば平日に運動量が連続して不足している者がいれば、不足した歩数を補うためのウォーキングプランを休日用に作成して、これをプッシュ型メールで発信することも有効である。これにより、ユーザ１１１が仕事に追われて休日の予定を考えられない状況でも、休日の推奨プランを提示され、これに連動したホテルの宿泊予約や鉄道の予約を行えることで、運動量の不足を解消すると共に、気分転換や家庭サービスを図ることができる。
【０１０５】
また、ユーザ１１１が休日のウォーキングに乗り気でないことが、送信されてくるデータから推測されるような場合には、占いのメールを送信し、占いで示された方角を目的地とするウォーキングプランを紹介することもウォーキングの実践に（または健康増進に）有効である。これにより、潜在的な休日のウォーキング需要を開拓し、また観光地めぐり等の観光需要の掘り起こしを図ることができる。
【０１０６】
更に、ユーザ１１１の自宅１５１や勤務地を基点としてウォーキングのプランを立てるだけでなく、出張時の場所をサービスセンタアプリケーションサーバ１０３に指定して、ウォーキングの起点を全国に展開することも可能である。また、ウォーキングについても単に健康のためというだけでなく、レジャーとしての楽しみを加味したり、家族等の同伴者の観光という色彩を強めることで、休日のウォーキングの実践を容易にすることができる。更に、ウォーキングという特殊性を利用して、交通の便が悪い場所のホテルをウォーキングコースに入れることで周囲の景観と併せて経済的で魅力あるコースを誕生させることができる。また、このようなホテルからウォーキングプランを付加した広告を依頼されたり、宿泊の契約成立時にロイヤルティの支払いが行われることを条件に広告を掲載することで、新たなビジネスを展開することができる。
【０１０７】
なお、以上説明した実施例および変形例では通信ネットワークとしてインターネット１０１とモバイルネットワーク１０２を使用したが、通信ネットワークの種類はこれらに限定されるものではない。ユーザが自宅やスポーツジム等の屋内で運動を行うことに限定して運動量を管理するものであれば、有線による通信ネットワークのみで運動量管理システムを構成することも可能である。通信ネットワークには、ＣＡＴＶ（CAble TeleVision）、無線ＬＡＮ（Local Area Network）等の各種の通信ネットワークが混在してもよい。
【図面の簡単な説明】
【０１０８】
【図１】本発明の一実施例における運動量管理システムの構成を表わしたシステム構成図である。
【図２】本実施例で使用される携帯端末の構成の要部を表わしたブロック図である。
【図３】本実施例で使用される歩数計の概要を表わしたブロック図である。
【図４】本実施例のユーザが携帯端末を使用して運動量管理システムを利用する場合の携帯端末の処理の概要を表わした流れ図である。
【図５】図４で示したプラン作成モードの実行における携帯端末の処理の様子を表わした流れ図である。
【図６】本実施例でサービスセンタアプリケーションサーバによる基本プランの設定処理を表わした流れ図である。
【図７】本実施例のユーザの自宅と会社の間の経路の概要を表わした説明図である。
【図８】本実施例でユーザの平日の基本プランを表わした携帯端末の表示部の平面図である。
【図９】本実施例の歩数計の処理の様子を表わした流れ図である。
【図１０】本実施例でサービスセンタアプリケーションサーバによる２日目以降の処理を表わした流れ図である。
【図１１】本実施例でユーザが選択した２日目の推奨プランを表わした携帯端末の表示部の平面図である。
【図１２】本実施例で当日２回目の推奨プランを表わした携帯端末の表示部の平面図である。
【図１３】本実施例で当日最後の３回目の推奨プランを表わした携帯端末の表示部の平面図である。
【図１４】本実施例でユーザがサービスセンタアプリケーションサーバに対して運動に関して各種の表示要求を行った場合の処理の流れ図である。
【図１５】本発明の変形例で休日プランの入力画面の一例を表わした平面図である。
【図１６】この変形例でサービスセンタアプリケーションサーバによる休日プランの処理の様子を表わした流れ図である。
【符号の説明】
【０１０９】
１００ 運動量管理システム
１０１ インターネット
１０２ モバイルネットワーク
１０３ サービスセンタアプリケーションサーバ
１０４ 地図情報サーバ
１０５ 乗物情報サーバ
１０６ 天候情報サーバ
１１１ ユーザ
１１２ 携帯端末
１１３ 歩数計
１１４ 位置測定用人工衛星
１２１、１４１ ＣＰＵ
１２３、１４３ ＲＯＭ
１２４、１４４ ＲＡＭ
１２５、１４６ 表示部
１２９、１４５
１３０ 脈拍センサ
１３１ 温度センサ
１３２ 高度計
１３３ 操作部
１５１ 自宅
１５２ バス
１５３ 急行電車
１５４ Ｃ会社
１５５ 公園
１５６ アーケード付の商店街
【特許請求の範囲】
【請求項１】
個人の運動量を測定する運動量測定手段と、
前記個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信し、前記運動量目標値設定手段によって設定された目標値を前記期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、
この過不足演算手段の演算結果を表示する運動量過不足表示手段
とを具備することを特徴とする運動量管理システム。
【請求項２】
個人の運動量を測定する運動量測定手段と、
前記個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信し、前記運動量目標値設定手段によって設定された目標値を前記期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、
この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、
この運動計画作成手段の作成した運動計画を前記個人の見うる装置に表示する運動計画表示手段
とを具備することを特徴とする運動量管理システム。
【請求項３】
前記運動計画作成手段は、運動量の過不足を解消する運動プランを組み込んだ旅行計画を作成する手段であることを特徴とする請求項２記載の運動量管理システム。
【請求項４】
前記運動計画作成手段は、前記個人の２点間の移動時に計画される運動量から、前記２点を結ぶ経路とその経路中での前記計画される運動量との関係で前記個人が運動を行う区間の組み合わせを複数通り設定する経路・運動区間設定手段と、この経路・運動区間設定手段によって設定された経路と運動を行う区間の組み合わせの中から前記個人の選択したものを運動計画として決定する運動計画決定手段とを具備することを特徴とする請求項２記載の運動量管理システム。
【請求項５】
前記経路・運動区間設定手段は、運動を行う場所の天候を確認する天候確認手段と、この天候確認手段によって確認された天候との関係で前記個人が運動を適正とする区間を選択する経路・区間選択手段を具備することを特徴とする請求項４記載の運動量管理システム。
【請求項６】
前記過不足演算手段が前記個人の平日における運動量の不足を演算したとき、前記運動計画作成手段はこの運動量の不足を補う休日の運動プランを提示することを特徴とする請求項３記載の運動量管理システム。
【請求項７】
前記運動量はウォーキングを行う際の歩数として測定されることを特徴とする請求項１〜請求項４、請求項６いずれかに記載の運動量管理システム。
【請求項８】
前記運動量測定手段は、加速度計を備えた携帯端末であることを特徴とする請求項１または請求項２記載の運動量管理システム。
【請求項９】
前記運動計画作成手段は、過不足演算手段の演算結果が不足となっているとき、この不足を解消する次の区間あるいはこれ以降の運動計画を作成することを特徴とする請求項２記載の運動量管理システム。
【請求項１０】
個人のある期間における運動量の目標値を取得する運動量目標値取得手段と、
前記個人の運動量を運動量の測定を行う運動量測定手段が測定した前記期間よりも短い区間で逐次受信する運動量受信手段と、
前記運動量目標値取得手段によって取得された目標値を前記期間の終了時に達成できるための前記運動量受信手段が運動量をそれぞれ受信した時点における運動量の過不足を演算する過不足演算手段と、
この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、
この運動計画作成手段の作成した運動計画を前記個人の見うる装置に送信してこれに表示させる運動計画表示用送信手段
とを具備することを特徴とする運動量管理サーバ。
【請求項１１】
個人の運動量を測定する運動量測定手段と前記個人の所持する通信端末との間で通信を行う運動量管理のための管理サーバのコンピュータに、
前記個人のある期間における運動量の目標値を前記通信端末から取得する運動量目標値取得処理と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信する運動量受信処理と、
前記運動量目標値取得処理によって取得された目標値を前記期間の終了時に達成できるための前記運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、
この過不足演算処理の演算結果を前記通信端末に送信して表示させる運動量過不足表示用送信処理
とを実行させることを特徴とする運動量管理プログラム。
【請求項１２】
個人の運動量を測定する運動量測定手段と前記個人の所持する通信手段との間で通信を行う運動量管理のための管理サーバのコンピュータに、
前記個人のある期間における運動量の目標値を前記通信手段から取得する運動量目標値取得処理と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信する運動量受信処理と、
前記運動量目標値取得処理によって取得された目標値を前記期間の終了時に達成できるための前記運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、
この過不足演算処理の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成処理と、
この運動計画作成処理で作成した運動計画を前記通信手段に送信して表示させる運動計画表示用送信処理
とを実行させることを特徴とする運動量管理プログラム。
【請求項１３】
前記運動計画作成処理は、運動計画を基にして運動が行われる場所の地図情報を格納する地図情報サーバ、前記場所に関する交通機関の情報を格納する乗物サーバおよび前記場所に関する気候情報を格納する気候情報サーバからそれぞれ必要とする情報を取得して前記運動計画を作成することを特徴とする請求項１２記載の運動量管理プログラム。
【請求項１４】
前記過不足演算処理で前記個人の平日における運動量の不足を演算したとき、前記運動計画作成処理でこの運動量の不足を補う休日の運動プランを提示することを特徴とする請求項１２または請求項１３記載の運動量管理プログラム。
【請求項１】
個人の運動量を測定する運動量測定手段と、
前記個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信し、前記運動量目標値設定手段によって設定された目標値を前記期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、
この過不足演算手段の演算結果を表示する運動量過不足表示手段
とを具備することを特徴とする運動量管理システム。
【請求項２】
個人の運動量を測定する運動量測定手段と、
前記個人のある期間における運動量の目標値を設定する運動量目標値設定手段と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信し、前記運動量目標値設定手段によって設定された目標値を前記期間の終了時に達成できるためのそれぞれの受信時点における運動量の過不足を演算する過不足演算手段と、
この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、
この運動計画作成手段の作成した運動計画を前記個人の見うる装置に表示する運動計画表示手段
とを具備することを特徴とする運動量管理システム。
【請求項３】
前記運動計画作成手段は、運動量の過不足を解消する運動プランを組み込んだ旅行計画を作成する手段であることを特徴とする請求項２記載の運動量管理システム。
【請求項４】
前記運動計画作成手段は、前記個人の２点間の移動時に計画される運動量から、前記２点を結ぶ経路とその経路中での前記計画される運動量との関係で前記個人が運動を行う区間の組み合わせを複数通り設定する経路・運動区間設定手段と、この経路・運動区間設定手段によって設定された経路と運動を行う区間の組み合わせの中から前記個人の選択したものを運動計画として決定する運動計画決定手段とを具備することを特徴とする請求項２記載の運動量管理システム。
【請求項５】
前記経路・運動区間設定手段は、運動を行う場所の天候を確認する天候確認手段と、この天候確認手段によって確認された天候との関係で前記個人が運動を適正とする区間を選択する経路・区間選択手段を具備することを特徴とする請求項４記載の運動量管理システム。
【請求項６】
前記過不足演算手段が前記個人の平日における運動量の不足を演算したとき、前記運動計画作成手段はこの運動量の不足を補う休日の運動プランを提示することを特徴とする請求項３記載の運動量管理システム。
【請求項７】
前記運動量はウォーキングを行う際の歩数として測定されることを特徴とする請求項１〜請求項４、請求項６いずれかに記載の運動量管理システム。
【請求項８】
前記運動量測定手段は、加速度計を備えた携帯端末であることを特徴とする請求項１または請求項２記載の運動量管理システム。
【請求項９】
前記運動計画作成手段は、過不足演算手段の演算結果が不足となっているとき、この不足を解消する次の区間あるいはこれ以降の運動計画を作成することを特徴とする請求項２記載の運動量管理システム。
【請求項１０】
個人のある期間における運動量の目標値を取得する運動量目標値取得手段と、
前記個人の運動量を運動量の測定を行う運動量測定手段が測定した前記期間よりも短い区間で逐次受信する運動量受信手段と、
前記運動量目標値取得手段によって取得された目標値を前記期間の終了時に達成できるための前記運動量受信手段が運動量をそれぞれ受信した時点における運動量の過不足を演算する過不足演算手段と、
この過不足演算手段の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成手段と、
この運動計画作成手段の作成した運動計画を前記個人の見うる装置に送信してこれに表示させる運動計画表示用送信手段
とを具備することを特徴とする運動量管理サーバ。
【請求項１１】
個人の運動量を測定する運動量測定手段と前記個人の所持する通信端末との間で通信を行う運動量管理のための管理サーバのコンピュータに、
前記個人のある期間における運動量の目標値を前記通信端末から取得する運動量目標値取得処理と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信する運動量受信処理と、
前記運動量目標値取得処理によって取得された目標値を前記期間の終了時に達成できるための前記運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、
この過不足演算処理の演算結果を前記通信端末に送信して表示させる運動量過不足表示用送信処理
とを実行させることを特徴とする運動量管理プログラム。
【請求項１２】
個人の運動量を測定する運動量測定手段と前記個人の所持する通信手段との間で通信を行う運動量管理のための管理サーバのコンピュータに、
前記個人のある期間における運動量の目標値を前記通信手段から取得する運動量目標値取得処理と、
前記運動量測定手段が測定した前記期間よりも短い区間で運動量を逐次受信する運動量受信処理と、
前記運動量目標値取得処理によって取得された目標値を前記期間の終了時に達成できるための前記運動量受信処理が行われたそれぞれの時点での運動量の過不足を演算する過不足演算処理と、
この過不足演算処理の演算結果を基にして次の区間あるいはこれ以降の運動計画を作成する運動計画作成処理と、
この運動計画作成処理で作成した運動計画を前記通信手段に送信して表示させる運動計画表示用送信処理
とを実行させることを特徴とする運動量管理プログラム。
【請求項１３】
前記運動計画作成処理は、運動計画を基にして運動が行われる場所の地図情報を格納する地図情報サーバ、前記場所に関する交通機関の情報を格納する乗物サーバおよび前記場所に関する気候情報を格納する気候情報サーバからそれぞれ必要とする情報を取得して前記運動計画を作成することを特徴とする請求項１２記載の運動量管理プログラム。
【請求項１４】
前記過不足演算処理で前記個人の平日における運動量の不足を演算したとき、前記運動計画作成処理でこの運動量の不足を補う休日の運動プランを提示することを特徴とする請求項１２または請求項１３記載の運動量管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００７−１１５２００（Ｐ２００７−１１５２００Ａ）
【公開日】平成１９年５月１０日（２００７．５．１０）
【国際特許分類】
【出願番号】特願２００５−３０８９０１（Ｐ２００５−３０８９０１）
【出願日】平成１７年１０月２４日（２００５．１０．２４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成１９年５月１０日（２００７．５．１０）
【国際特許分類】
【出願日】平成１７年１０月２４日（２００５．１０．２４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]