JP4946756B2 - 運動支援装置、運動支援プログラムおよび運動支援システム - Google Patents

Description

本発明は、運動支援装置、運動支援プログラムおよび運動支援システムに関する。より具体的には、運動中のユーザのバイタルデータに基づいて、運動コンテンツを選択して提示する運動支援装置、運動支援プログラムおよび運動支援システムに関する。

従来から、サーバから、ネットワークを介して接続されたユーザ端末へ運動コンテンツを提供し、ユーザの運動を支援する運動支援システムが知られている。例えば、特許文献１に記載の運動支援システムは、心拍数や血圧等、ユーザのバイタルデータを運動中に検出し、ユーザの運動量が目標とする範囲を超えた場合には、ユーザに提示する運動コンテンツを運動負荷の異なるものに変更して、ユーザが過不足なく運動を行えるように図っている。
特開２００６−２５５０２８号公報

しかしながら、特許文献１に記載の運動支援システムでは、変更後の運動コンテンツとして、サーバ（センタ装置）に予め記憶された運動負荷が段階的に異なる複数の運動コンテンツのうち、現在の負荷に対して１段階上または下の運動コンテンツが一律に選択される。また、各運動コンテンツに予め設定された運動負荷の大きさが変更されることはない。よって、例えば、１段階上の運動負荷が、あるユーザには最適であっても、他のあるユーザには重過ぎる場合がある。すなわち、その時点のユーザにとって最適な運動負荷の運動コンテンツに変更されるとは限らないという問題があった。

本発明は、上記問題点を解決するためになされたものであり、同じ属性のユーザの過去のバイタルデータを考慮して、最適な運動コンテンツを選択することが可能な運動支援装置、運動支援プログラムおよび運動支援システムを提供することを目的とする。

上記目的を達成するために、請求項１に係る発明の運動支援装置は、運動中のユーザのバイタルデータに基づいて、運動コンテンツを選択して提示する運動支援装置であって、年齢、性別、体格の少なくとも１つを含む属性ごとに、複数の運動コンテンツと、少なくとも１名の過去のユーザが他の運動コンテンツからの移行後に各運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である予想変化量とを対応づけて記憶するコンテンツ記憶手段と、前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツから、現在のユーザの属性に対応する複数の運動コンテンツの組み合わせである運動メニューを選択するコンテンツ選択手段と、前記現在のユーザのバイタルデータである現在データを、前記現在のユーザが前記運動メニューに従って運動している間に取得するデータ取得手段と、前記データ取得手段により取得された前記現在データの大きさが予め設定された上限値および下限値によって定められる所定範囲内にあるか否かを判断する判断手段と、前記判断手段により、前記現在データの大きさが前記所定範囲内にないと判断された場合に、前記現在データに基づき、前記現在のユーザが一つ前に提示された運動コンテンツからの移行後に現在提示中の運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である実変化量を算出する算出手段と、前記運動メニューに従って次に提示する予定の運動コンテンツである次コンテンツを、前記実変化量および前記現在のユーザの属性に対応する前記複数の運動コンテンツの前記予想変化量に基づいて、前記コンテンツ記憶手段に記憶された他の運動コンテンツに変更するコンテンツ変更手段と、前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツのうち、前記現在のユーザが実際に体験した運動コンテンツと対応づけられた前記予想変化量を、前記算出手段によって算出された前記実変化量に書き換えるデータ書換え手段とを備えている。

また、請求項２に係る発明の運動支援装置では、請求項１に記載の発明の構成に加え、前記コンテンツ変更手段は、前記判断手段によって前記現在データの大きさが前記上限値よりも大きいと判断された場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも小さい前記予想変化量に対応する運動コンテンツを選択し、前記判断手段によって前記現在データの大きさが前記下限値よりも小さいと判断された場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする。

また、請求項３に係る発明の運動支援装置では、請求項２に記載の発明の構成に加え、前記コンテンツ変更手段は、前記判断手段によって前記現在データの大きさが前記上限値よりも大きいと判断された場合には、前記他の運動コンテンツとして、前記実変化量が大きくなるほどより小さい前記予想変化量に対応する運動コンテンツを選択し、前記判断手段によって前記現在データの大きさが前記下限値よりも小さいと判断された場合には、前記他の運動コンテンツとして、前記実変化量が小さくなるほどより大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする。

さらに、請求項４に係る発明の運動支援プログラムは、請求項１〜３のいずれかに記載の運動支援装置の各種処理手段としてコンピュータを機能させることを特徴とする。

また、請求項５に係る発明の運動支援システムは、ユーザ端末と、前記ユーザ端末にネットワークを介して接続され、前記ユーザ端末へ運動コンテンツを配信する運動コンテンツサーバを備えた運動支援システムであって、前記ユーザ端末は、前記運動コンテンツサーバに対して、運動コンテンツの組み合わせである運動メニューの配信を要求する配信要求手段と、前記運動コンテンツサーバから配信された前記運動メニューを、現在のユーザである現在ユーザに提示する提示手段と、前記現在ユーザが前記運動メニューに従って運動している間のバイタルデータである現在データを検出するデータ取得手段と、前記データ取得手段によって取得された前記現在データが、予め設定された上限値および下限値によって定められる所定範囲内にあるか否かを判断する判断手段と、前記判断手段によって前記現在データの大きさが前記所定範囲内にないと判断された場合に、前記現在データに基づき、前記現在のユーザが一つ前に提示された運動コンテンツからの移行後に現在提示中の運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である実変化量を算出する算出手段と、前記運動コンテンツサーバに対して、前記算出手段によって算出された前記実変化量を送信するとともに、前記運動メニューで次に提示する予定の運動コンテンツである次コンテンツを、他の運動コンテンツに変更するように要求する変更要求手段と、前記次コンテンツを、前記変更要求手段からの要求に応じて前記運動コンテンツサーバから送信された前記他の運動コンテンツに置き換えるコンテンツ置き換え手段と、前記運動コンテンツサーバに対して、前記ユーザが実際に体験した運動コンテンツと対応付けて、前記データ取得手段によって取得された前記現在データを送信するデータ送信手段とを備え、前記運動コンテンツサーバは、年齢、性別、体格の少なくとも１つを含む属性ごとに、複数の運動コンテンツと、少なくとも１名の過去のユーザが他の運動コンテンツからの移行後に各運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である予想変化量とを対応づけて記憶するコンテンツ記憶手段と、前記コンテンツ要求手段からの要求を受けた場合に、前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツから、前記現在のユーザの属性に対応する前記運動メニューを選択するコンテンツ選択手段と、前記ユーザ端末に対して、前記コンテンツ選択手段によって選択された前記運動メニューを配信する配信手段と、前記変更要求手段からの要求を受けた場合に、前記次コンテンツの変更後のコンテンツとして、前記実変化量および前記現在のユーザの属性に対応する前記複数のコンテンツの前記予想変化量に基づいて、前記コンテンツ記憶手段に記憶された他の運動コンテンツを選択するコンテンツ変更手段と、前記コンテンツ変更手段によって選択された前記他のコンテンツを前記ユーザ端末に配信する変更配信手段と、前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツのうち、前記データ送信手段により送信された前記現在ユーザが実際に体験した運動コンテンツと対応づけられた前記予想変化量を、前記現在データに従って算出された前記実変化量に書き換えるデータ書換え手段とを備えている。

また、請求項６に係る発明の運動支援システムでは、請求項５に記載の発明の構成に加え、前記ユーザ端末の前記変更要求手段は、前記判断手段の判断結果を前記運動コンテンツサーバに送信し、前記運動コンテンツサーバの前記コンテンツ変更手段は、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記上限値よりも大きいことを示す場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも小さい前記予想変化量に対応する運動コンテンツを選択し、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記下限値よりも小さいことを示す場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする。

また、請求項７に係る発明の運動支援システムでは、請求項６に記載の発明の構成に加え、前記運動コンテンツサーバの前記コンテンツ変更手段は、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記上限値よりも大きいことを示す場合には、前記他の運動コンテンツとして、前記実変化量が大きくなるほどより小さい前記予想変化量に対応する運動コンテンツを選択し、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記下限値よりも小さいことを示す場合には、前記他の運動コンテンツとして、前記実変化量が小さくなるほどより大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする。

請求項１に係る発明の運動支援装置では、実際に過去のユーザが他の運動コンテンツの後に運動コンテンツに従って運動した時に測定されたバイタルデータの変化量が、予想変化量として、属性ごとに運動コンテンツと対応付けて記憶されている。そして、現在のユーザの運動中のバイタルデータが所定範囲になければ、現在のユーザが一つ前の運動コンテンツの後に現在提示中の運動コンテンツに従って運動した時に測定されたバイタルデータの変化量が、実変化量として算出される。さらに、次に提示される予定の運動コンテンツが、実変化量および現在のユーザの属性に対応する運動コンテンツの予想変化量に基づいて変更される。すなわち、同じ属性を有する過去のユーザが運動を行った際、実際にバイタルデータがどのように変化したかを考慮して変更後の運動コンテンツが選択される。したがって、変更後の運動コンテンツが一律に設定されている場合に比べ、運動中の現在のユーザにとって最適な運動コンテンツに変更することができる。

請求項２に係る発明の運動支援装置では、現在のユーザのバイタルデータが上限値を超えた場合は、次に提示される予定の運動コンテンツが、予想変化量がより小さい運動コンテンツに変更される。また、現在のユーザのバイタルデータが下限値に満たない場合は、次に提示される予定の運動コンテンツが、予想変化量がより大きい運動コンテンツに変更される。したがって、請求項１に記載の発明の効果に加え、バイタルデータが上限値を超える無理な運動や、下限値に満たない負荷が軽すぎる運動をしている状態から、バイタルデータが両者の間におさまる適切な運動状態に推移させることができる。

請求項３に係る発明の運動支援装置では、現在のユーザのバイタルデータが上限値または下限値に満たない場合、次に提示される予定の運動コンテンツが、実変化量の大きさに応じて、それを相殺する予想変化量に対応する運動コンテンツに変更される。したがって、請求項２に記載の発明の効果に加え、無理な運動や負荷が軽すぎる運動をしている状態から、速やかに適切な運動状態に推移させることができる。

請求項４に係る発明の運動支援プログラムは、請求項１〜３のいずれかに記載の運動支援装置の各種処理手段としてコンピュータを機能させることができる。したがって、請求項１〜３のいずれかに記載の発明の効果を奏することができる。

請求項５に係る発明の運動支援システムでは、ユーザ端末で取得される現在のユーザの運動中のバイタルデータが所定範囲にない場合、現在のユーザが一つ前の運動コンテンツの後に現在提示中の運動コンテンツに従って運動した時に測定されたバイタルデータの変化量が、実変化量として算出される。さらに、ユーザ端末から運動コンテンツサーバに対して、実変化量とともに、次に提示される予定の運動コンテンツの変更要求が送信される。運動コンテンツサーバには、実際に過去のユーザが他の運動コンテンツの後に運動コンテンツに従って運動した時に測定されたバイタルデータの変化量が、予想変化量として、属性ごとに運動コンテンツと対応づけて記憶されており、次に提示される予定の運動コンテンツが、実変化量および現在のユーザの属性に対応する運動コンテンツの予想変化量に基づいて変更される。すなわち、同じ属性を有する過去のユーザが運動を行った際、実際にバイタルデータがどのように変化したかを考慮して変更後の運動コンテンツが選択される。したがって、変更後の運動コンテンツが一律に設定されている場合に比べ、運動中の現在のユーザにとって最適な運動コンテンツに変更することができる。

請求項６に係る発明の運動支援システムでは、ユーザ端末において取得される現在のユーザのバイタルデータが上限値を超えた場合は、運動コンテンツサーバにおいて、次に提示される予定の運動コンテンツが、予想変化量がより小さい運動コンテンツに変更される。また、現在のユーザのバイタルデータが下限値に満たない場合は、次に提示される予定の運動コンテンツが、予想変化量がより大きい運動コンテンツに変更される。したがって、請求項５に記載の発明の効果に加え、バイタルデータが上限値を超える無理な運動や、下限値に満たない負荷が軽すぎる運動をしている状態から、バイタルデータが両者の間におさまる適切な運動状態に推移させることができる。

請求項７に係る発明の運動支援システムでは、現在のユーザのバイタルデータが上限値または下限値に満たない場合、運動コンテンツサーバにおいて、次に提示される予定の運動コンテンツが、実変化量の大きさに応じて、それを相殺する予想変化量に対応する運動コンテンツに変更される。したがって、請求項６に記載の発明の効果に加え、無理な運動や負荷が軽すぎる運動をしている状態から、速やかに適切な運動状態に推移させることができる。

以下、本発明を具体化した一実施の形態である運動支援システム１００について、図面を参照して説明する。なお、参照する図面は、本発明が採用しうる技術的特徴を説明するために用いられるものであり、記載されている装置の構成、各種処理のフローチャートなどは、特に特定的な記載がない限り、それのみに限定する趣旨ではなく、単なる説明例である。

まず、図１を参照して、本実施形態に係る運動支援システム１００の概略構成について説明する。図１は、運動支援システム１００の概略構成を示すシステム構成図である。図１に示すように、運動支援システム１００は、ユーザ３に運動コンテンツを提示するサーバ１と、サーバ１にネットワーク５を介して接続されたユーザ端末２とを構成の主体とする。サーバ１は、例えばスポーツジムやフィットネススタジオに設置されるものであり、会員のユーザ端末２に対して、ユーザ３が参照して運動を行うための運動メニューを送信することができる。本実施形態では、ネットワーク５としてインターネットを採用しており、各会員は、自宅に設置したユーザ端末２にサーバ１から送信される運動メニューに従って各自好きな時間に運動を行うことができる。なお、図１では、ユーザ端末２は１台しか図示されていないが、サーバ１には会員数に応じた台数のユーザ端末２が接続可能である。また、ネットワーク５として、必ずしも本実施形態のようにインターネットを採用する必要はなく、例えば、スポーツジム内に設置されたユーザ端末２をＬＡＮでサーバ１に接続した形態とすることももちろん可能である。

サーバ１からユーザ端末２に運動メニューが送信されると、ユーザ端末２では、受信した運動メニューを構成する複数の運動コンテンツがディスプレイ２８に順に表示される。ユーザ３は、バイタルデータ（例えば、心拍数）を計測するセンサユニット３０を装着し、表示される運動に従って運動を行う。ユーザ端末２は、センサユニット３０から逐次送信されるバイタルデータを基に、ユーザ３が適度な運動を行っているか否かを判断する。その結果、無理な運動や負荷が軽すぎる運動を行っていると判断されると、ユーザ端末２は、次に提示される予定の運動コンテンツを変更するようにサーバ１に要求する。サーバ１には、全会員に関する個人情報と、会員の個人情報を基に定められた属性グループと運動目的毎に、運動メニューを構成する運動コンテンツが記憶されている。サーバ１は、ユーザ端末２からの変更要求を受けると、その会員の属性と、変更要求とともに送信されてくる会員のバイタルデータの変化量に基づき、変更後の運動コンテンツを選択し、ユーザ端末２に送信する。なお、これらの処理の詳細については後述する。

次に、図２〜図６を参照して、サーバ１の構成について説明する。図２は、サーバ１の電気的構成を示すブロック図である。図３は、会員情報データベース１４１０の説明図である。図４は、運動コンテンツデータベース１４２０の説明図である。図５は、デフォルトメニュー記憶エリア１４３に記憶された心拍数の理想推移とデフォルトメニューの説明図である。図６は、変更候補データベース１４４０の説明図である。

まず、図２を参照して、サーバ１の電気的構成について説明する。図２に示すように、サーバ１は、バス１０を介して相互に接続されたＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ハードディスク装置（ＨＤＤ）１４、入出力インターフェース１５および通信用インターフェース（Ｉ／Ｆ）１６を備えている。ＲＯＭ１２は、ＢＩＯＳ等、サーバ１を動作させるための各種のプログラムを記憶しており、ＣＰＵ１１は、ＲＯＭ１２に記憶されたプログラムに従って、サーバ１の動作を制御する。ＲＡＭ１３は、各種データを一時的に記憶する記憶素子である。ＨＤＤ１４については、後で詳述する。入出力インターフェース１５は、データの受け渡しの仲介を行うもので、ディスプレイ１７、マウス１８およびキーボード１９が接続されている。通信用Ｉ／Ｆ１６は、ネットワーク５に接続し、ユーザ端末２等の外部機器との間でデータの送受信を行うためのものである。

次に、図２〜図６を参照して、ＨＤＤ１４に設けられた記憶エリアと、そこに記憶される情報について説明する。図２に示すように、ＨＤＤ１４には、会員情報データベース（ＤＢ）記憶エリア１４１、運動コンテンツデータベース（ＤＢ）記憶エリア１４２、デフォルトメニュー記憶エリア１４３、変更候補データベース（ＤＢ）記憶エリア１４４およびプログラム記憶エリア１４５を含む複数の記憶エリアが設けられている。会員情報ＤＢ記憶エリア１４１には、運動支援システム１００の会員すべての個人情報が登録された会員情報ＤＢ１４１０が記憶されている。運動コンテンツＤＢ記憶エリア１４２には、ユーザ端末２に送信する運動メニューの構成要素となる運動コンテンツが登録された運動コンテンツＤＢ１４２０が記憶されている。デフォルトメニュー記憶エリア１４３には、各属性グループおよび運動目的毎に定められたバイタルデータの理想推移１４３１と、理想推移を実現するために設定された標準的な運動メニュー１４３０（以下、デフォルトメニュー１４３０という）とが記憶されている。変更候補ＤＢ記憶エリア１４４には、各属性グループ毎に、ある運動から他の運動へ移行した時のバイタルデータの変化量が記憶されている。プログラム記憶エリア１４５には、後述する運動コンテンツ配信処理を含む各種の処理をサーバ１に実行させるための各種プログラムが記憶されている。

ここで、図３を参照して、会員情報ＤＢ記憶エリア１４１に記憶された会員情報ＤＢ１４１０について説明する。図３に示すように、会員情報ＤＢ１４１０には、会員毎に、各会員に固有の識別コードである会員ＩＤと、会員の氏名（Ａ、Ｂ、Ｃ等）、性別、年齢、身長、体重、属性グループおよび前回運動支援システム１００を利用して運動を行った際の心拍数データが会員情報として登録されている。なお、本実施形態では、「属性グループ」とは、性別、年齢、身長および体重に基づいて分類されたグループをいう。例えば、性別が「男」、年齢が「１０代」、身長が「１６５ｃｍ未満」、体重が「５５ｋｇ未満」のグループは「属性グループＡ」、性別が「女」、年齢が「３０代」、身長が「１５０ｃｍ以上１６０ｃｍ未満」、体重が「６０ｋｇ以上７０ｋｇ未満」のグループは「属性グループＫ」等と分類されている。なお、図３には図示されていないが、会員情報ＤＢ１４１０には、会員の住所、電話番号、メールアドレス、会員の利用するユーザ端末２の識別情報等、その他の情報も記憶されている。また、図３には会員Ａ〜会員Ｃまでの３名分のデータしか図示されていないが、実際には、運動支援システム１００の会員すべてのデータが記憶されている。

次に、図４を参照して、運動コンテンツＤＢ記憶エリア１４２に記憶されている運動コンテンツＤＢ１４２０について説明する。図４に示すように、運動コンテンツＤＢ１４２０には、複数の異なる運動毎に、運動の名前である運動名、数分程度継続する運動の動画データおよび音声データが１組として記憶されている。なお、本実施形態では、運動コンテンツＤＢ１４２０に１組として記憶されている、ある運動の運動名、動画データおよび音声データを総称して運動コンテンツというものとする。本実施形態では、サーバ１は、会員の属する属性グループおよび会員の運動目的に応じて、運動コンテンツＤＢ１４２０に記憶された複数の運動コンテンツを組み合わせて順に並べた運動メニューを作成し、ユーザ端末２に送信する。なお、この処理については、後で詳述する。また、図４には運動コンテンツ１〜運動コンテンツ３のデータしか図示されていないが、実際には、他にも運動コンテンツがある場合には、すべての運動コンテンツのデータが記憶されている。

図５を参照して、デフォルトメニュー記憶エリア１４３に記憶されている理想推移１４３１とデフォルトメニュー１４３０との関係について説明する。図５は、運動を行った際の時間およびバイタルデータの一例である心拍数の推移を示すグラフであり、実線が理想推移１４３１を示し、点線がデフォルトメニュー１４３０に従って運動した場合の予想推移１４３２を示している。また、時間軸のＴ１〜Ｔ７は、それぞれに１つの運動コンテンツが割り当てられる時間枠である。理想推移１４３１は、各属性グループおよび運動目的に適合する理想的な心拍数の推移として一律に定められており、あわせて心拍数の上限値および下限値も各属性グループおよび運動目的に応じて定められている。詳細は後述するが、デフォルトメニュー１４３０は、理想推移１４３１と、変更候補ＤＢ１４４０（図６参照）に記憶された心拍数の変化量とを比較して設定される。具体的には、例えば、図５に示す理想推移１４３１では、最初の時間枠Ｔ１と２番目の時間枠２に亘って心拍数が上昇し、時間枠Ｔ３で上昇率が緩やかになり、時間枠Ｔ４〜Ｔ５では変化せず、その後、時間枠Ｔ６〜Ｔ７で下降するのが理想的であるとされている。そこで、このように心拍数が推移するような変化量が記憶されている運動コンテンツが時間枠Ｔ１〜Ｔ７の各々について選択され、選択された運動コンテンツの運動名がデフォルトメニュー１４３０として記憶されている。図５の例では、時間枠Ｔ１〜Ｔ７に対応して、運動１、運動２、運動３、運動５、運動８、運動９、運動１１が順に並べられたデフォルトメニュー１４３０が記憶されている。デフォルトメニュー記憶エリア１４３には、属性グループおよび運動目的毎に、前述のようなバイタルデータの理想推移１４３１とデフォルトメニュー１４３０とが記憶されている。

次に、図６を参照して、変更候補ＤＢ記憶エリア１４４に記憶されている変更候補ＤＢ１４４０について説明する。図６に示すように、変更候補ＤＢ１４４０には、属性グループ毎に、運動名、その運動からの移行後の運動名、および移行前と後のバイタルデータの予想変化量が対応づけられて記憶されている。なお、図６には属性グループＡ〜属性グループＣ、および運動コンテンツ１〜運動コンテンツ３のデータしか図示されていないが、実際には、分類されたすべての属性グループのすべての運動コンテンツのデータが記憶されている。なお、本実施形態では、バイタルデータとして心拍数を採用する。また、予想変化量は、後述するように、その属性グループに属する会員が実際に運動を行った時に測定されたバイタルデータ（心拍数データ）に基づいて更新されるが、この処理については後で詳述する。

以下に、図７を参照して、ユーザ端末２の構成について説明する。図７は、ユーザ端末２の電気的構成を示すブロック図である。図７に示すように、ユーザ端末２は、バス２０を介して相互に接続されたＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、ハードディスク装置（ＨＤＤ）２４、入出力インターフェース（Ｉ／Ｆ）２５、センサ通信用Ｉ／Ｆ２６、および通信用Ｉ／Ｆ２７を備えている。ＲＯＭ２２は、ＢＩＯＳ等、ユーザ端末２を動作させるための各種のプログラムを記憶しており、ＣＰＵ２１は、ＲＯＭ２２に記憶されたプログラムに従って、ユーザ端末２の動作を制御する。ＲＡＭ２３は、各種データを一時的に記憶させる記憶素子である。ＨＤＤ２４については後述する。入出力Ｉ／Ｆ２５は、データの受け渡しの仲介を行う。入出力Ｉ／Ｆ２５には、運動コンテンツ等が表示されるディスプレイ２８と、ディスプレイ２８に表示された各種の項目を指で押圧操作することにより指示入力を可能とするタッチパネル２９が接続されている。さらに、入出力Ｉ／Ｆ２５には、運動の指示を音声出力するスピーカー（図示外）も接続されている。センサ通信用Ｉ／Ｆ２６は無線通信用のアンテナ２６１を備えており、会員が装着するセンサユニット３０から心拍数データを受信する。なお、詳細は図示されていないが、センサユニット３０は、心拍数センサ、無線通信用の通信回路およびアンテナ３１とを備えている。通信用Ｉ／Ｆ２７は、ネットワーク５に接続し、サーバ１等の外部機器との間でデータの送受信を行うためのものである。

図７に示すように、ＨＤＤ２４には、ユーザ情報記憶エリア２４１およびプログラム記憶エリア２４２を含む複数の記憶エリアが設けられている。ユーザ情報記憶エリア２４１には、ユーザ端末２を利用する会員の個人情報が記憶されている。なお、この個人情報については、サーバ１の会員情報ＤＢ１４１０に記憶されている情報と同様であるため、ここでの説明は省略する。また、プログラム記憶エリア２４２には、後述する運動支援処理を含む各種の処理をユーザ端末２に実行させるための各種のプログラムが記憶されている。

以下に、図８〜図１０を参照して、ユーザ端末２で行われる運動支援処理について説明する。図８は運動支援処理のフローチャートである。図９は、運動支援処理中に実行される運動コンテンツ変更判断処理のフローチャートである。図１０は、運動コンテンツ変更判断処理における判断過程を説明するための心拍数の上限値、下限値および実推移の説明図である。なお、図８および図９に示す処理は、ＨＤＤ２４のプログラム記憶エリア２４２に記憶されたプログラムに従って、ＣＰＵ２１が実行する。また、以下の説明では、処理が行われるユーザ端末２の利用者として登録されているのは会員Ａであるものとする。

図１０に示す運動支援処理は、ユーザ端末２を利用する運動支援システム１００の会員Ａによって、ディスプレイ２８に内蔵されたタッチパネル２９（図１参照）を介してプログラム起動の指示が入力されると開始される。処理が開始されると、ＣＰＵ２１はまず、ユーザ端末２を利用する会員Ａの会員ＩＤをＨＤＤ２４のユーザ情報記憶エリア２４１から読出し、ログインのためにサーバ１に送信する（Ｓ１）。会員ＩＤを受信したサーバ１では、後述するように認証処理が行われ、認証結果がユーザ端末２に送信される。これを受信したユーザ端末２のＣＰＵ２１は、認証結果がＯＫであるか否かを判断する（Ｓ２）。認証結果がＯＫの場合には（Ｓ２：ＹＥＳ）、ＣＰＵ２１は、サーバ１から送信される画面情報に基づいて、ディスプレイ２８に運動目的を選択するためのボタンを複数表示させ、会員Ａに入力を促す。運動目的としては、例えば「筋力増強」、「ダイエット」、「運動不足解消」がある。会員Ａが、所望の運動目的に対応するボタンを押圧操作すると、タッチパネル２９によりこの入力が検出され、入力された運動目的がＲＡＭ２３に取得される（Ｓ３）。

続いてＣＰＵ２１は、Ｓ３で取得した運動目的を記載して、運動メニューの配信要求をサーバ１に送信する（Ｓ４）。詳細は後述するが、これを受けたサーバ１では、ユーザ端末２の会員Ａの属性と運動目的に応じて、複数の運動コンテンツからなる運動メニューと、心拍数の上限値および下限値とが設定され、ユーザ端末２に配信される。例えば、図５のデフォルトメニュー１４３０に従って、運動１、運動２、運動３、運動５、運動８、運動９および運動１１の順で構成された運動メニューと、上限値および下限値がユーザ端末２に配信される。ＣＰＵ２１は、運動メニュー、上限値および下限値を受信して、ＲＡＭ２３に記憶させる（Ｓ５）。

続いてＣＰＵ２１は、サーバ１から受信し、ＲＡＭ２３に記憶された運動メニューを構成する複数の運動コンテンツのうち、最初の運動コンテンツを選択する（Ｓ６）。前述のデフォルトメニューの例（図５参照）では、ここで運動１の運動コンテンツが選択される。そして、ＣＰＵ２１は、選択された運動コンテンツの動画データおよび音声データを再生し、運動の手本となる映像をディスプレイ２８（図１参照）に表示させ、指示音声をスピーカー（図示外）から出力する（Ｓ７）。また、ＣＰＵ２１は、ＲＡＭ２３に記憶された時間カウンタによって、運動コンテンツの再生開始からの経過時間のカウントを開始する（Ｓ８）。

本実施形態では、会員Ａが装着したセンサユニット３０は、常時会員Ａの心拍数をモニタし、ユーザ端末２に送信している。ＣＰＵ２１は、センサユニット３０からアンテナ３１を介して送信される心拍数データを受信して、図１０に示す実推移１４３５としてＲＡＭ２３に取得し（Ｓ９）、判定時間になったか否かを監視している（Ｓ１０）。なお、判定時間とは、運動コンテンツ毎に定められた時間枠Ｔｎにおいて、開始から所定の時間が経過した時点に定められた時間ｔｎであり、運動メニューとともに配信され、ＲＡＭ２３に記憶されている。例えば、図１０に示すように、最初の運動コンテンツ（運動１）が再生される時間枠Ｔ１では、時間カウンタが、運動１に対応付けてＲＡＭ２３に記憶されている判定時間ｔ１になったか否かが判断される。時間カウンタが判定時間ｔｎに達していなければ（Ｓ１０：ＮＯ）、そのまま心拍数データの記憶を続ける（Ｓ９）。そして、判定時間ｔｎになると（Ｓ１０：ＹＥＳ）、ＣＰＵ２１は、ＲＡＭ２３に記憶されている運動メニューを参照して、次の運動コンテンツがまだあるか否かを判断する（Ｓ１１）。

前述のように、図５のデフォルトメニュー１４３０に従って運動メニューが配信されていれば、ＲＡＭ２３には、運動１の次の運動コンテンツとして、運動２が記憶されている（Ｓ１１：ＹＥＳ）。このような場合には、運動コンテンツ変更判断処理が行われる（Ｓ１２、図１１）。運動コンテンツ変更判断処理は、運動中の会員Ａの心拍数が所定範囲を超えているか否かを判断し、超えている場合には、心拍数が所定範囲に推移するように次に提示される運動コンテンツを変更する処理である。

図９に示すように、運動コンテンツ変更判断処理が開始されると、ＣＰＵ２１はまず、ＲＡＭ２３に記憶された心拍数の上限値、下限値と心拍数データとに基づき、判定時間ｔｎ時点のユーザ端末２の会員Ａの心拍数が下限値以上かつ上限値以下であるか否かを判断する（Ｓ２１）。例えば、図１０の例では、最初の運動コンテンツ（運動１）が再生される時間枠Ｔ１では、判定時間ｔ１時点の心拍数ｂ１は、この会員Ａの属性グループと会員Ａが選択した運動目的に応じて定められた下限値Ｌ１に等しい。すなわち、心拍数ｂ１は、下限値Ｌ１以上かつ上限値Ｕ１以下である（Ｓ２１：ＹＥＳ）。この場合、ＣＰＵ２１は、次の運動コンテンツを変更することなく運動を継続してよいと判定する（Ｓ３１）。そして、現在再生中の運動コンテンツの再生が終了するまで待機し（Ｓ２８：ＮＯ→Ｓ２８）、再生が終了すると（Ｓ２８：ＹＥＳ）、次の運動コンテンツの処理を行うために時間カウンタをリセットする（Ｓ２９）。その後、ＣＰＵ２１は、ＲＡＭ２３に記憶されている運動メニューから次の運動コンテンツを選択する（Ｓ３０）。図１０の例では、ここで２番目に設定された運動２の運動コンテンツが選択され、図９の処理は終了して、図８の運動支援処理に戻る。

図８の処理に戻ると、２番目の運動コンテンツについても、前述と同様にＳ７〜Ｓ１０の処理が行われ、時間枠Ｔ２について定められた判定時間ｔ２になると（Ｓ１０：ＹＥＳ）、次の運動コンテンツの有無が判断される（Ｓ１１）。例えば、図５のデフォルトメニュー１４３０に従って運動メニューが配信されていれば、ＲＡＭ２３には、運動２の次に運動３の運動コンテンツが記憶されている（Ｓ１１：ＹＥＳ）。よって、ＣＰＵ２１は、次に提示される予定の運動３について、運動コンテンツ変更判断処理を行う（Ｓ１２、図９）。今度は、判定時間ｔ２時点の会員Ａの心拍数ｂ２が、下限値Ｌ１以上かつ上限値Ｕ１以下であるか否かが判断される（Ｓ２１）。図１０に示す例では、会員Ａの心拍数ｂ２は、上限値Ｕ１を超えているため（Ｓ２１：ＮＯ）、ＣＰＵ２１は、次の運動コンテンツを変更しなければならないと判定し（Ｓ２２）、変更処理を行う。

ＣＰＵ２１はまず、現在再生中の運動コンテンツに従って運動を開始した直後の単位時間当たりの心拍数の変化量Δｂ／ｔを算出する（Ｓ２３）。具体的には、図１０に示すように、運動コンテンツの再生開始時点の心拍数と、再生開始時点から単位時間ｔ（例えば１５秒）後の心拍数との差Δｂを単位時間ｔで割った数が、変化量Δｂ／ｔとして算出される。ここで変化量Δｂ／ｔを算出するのは、１つ前の運動から現在の運動に移行することにより、会員Ａの心拍数が急激に変化したのか、緩やかに変化したのか、変化の程度を把握し、サーバ１において変更後の運動コンテンツを選択する際に考慮するためである。変化量Δｂ／ｔの算出後（Ｓ２３）、ＣＰＵ２１は、サーバ１に対して、変化量Δｂ／ｔおよび現在の運動コンテンツの運動名（前述の例では「運動２」）を通知し、次の運動コンテンツ（前述の例では「運動３」）を他の運動コンテンツに変更してユーザ端末２に送信するように要求する（Ｓ２４）。

詳細は後述するが、変更要求を受信したサーバ１では、ユーザ端末２から送信された会員Ａの属性および心拍数の変化量Δｂ／ｔに基づいて、次の運動コンテンツとして最適なものが検索される。その結果、現在設定されている次の運動コンテンツよりも適したものがない場合、サーバ１からユーザ端末２には、変更不可の通知が送信される。この変更不可の通知を受信した場合（Ｓ２５：ＹＥＳ）、ＣＰＵ２１は、そのままＳ２８へ進み、前述のように、Ｓ２８〜Ｓ３０の処理を行う。すなわち、現在再生中の運動コンテンツの再生が終了すると（Ｓ２８：ＹＥＳ）、時間カウンタをリセットし（Ｓ２９）、最初に配信されたままの運動メニューから次（３番目）の運動コンテンツを選択して（Ｓ３０）、図８の運動支援処理に戻る。

一方、変更不可の通知ではなく、サーバ１で選択された他の最適な運動コンテンツがユーザ端末２に送信されてきた場合には（Ｓ２５：ＹＥＳ）、ＣＰＵ２１はこれを受信して、変更運動コンテンツとしてＲＡＭ２３に記憶させる（Ｓ２６）。そして、Ｓ５で受信し、ＲＡＭ２３に記憶されている運動メニューのうち、次に再生する予定の運動コンテンツを、受信した変更運動コンテンツに置き換えることにより、運動メニューを更新する（Ｓ２７）。例えば、図５のデフォルトメニュー１４３０に従って運動メニューが配信され、運動２の再生中に変更要求がなされた場合には（Ｓ２４）、運動２の次の運動３が、受信した変更運動コンテンツに置き換えられる。その後、現在再生中の運動コンテンツの再生が終了すると（Ｓ２８：ＹＥＳ）、時間カウンタをリセットし（Ｓ２９）、変更された運動メニューから次の運動コンテンツ（変更運動コンテンツ）を選択して（Ｓ３０）、図８の運動支援処理に戻り、同様の処理を繰り返す。

このようにして、適宜、次の運動コンテンツを変更しながら、順次、ＲＡＭ２３に記憶された運動メニューを構成する複数の運動コンテンツの再生が行われる。その結果、最後の運動コンテンツになると、次の運動コンテンツはなくなる（Ｓ１１：ＮＯ）。この場合、ＣＰＵ２１は、最後の運動コンテンツの再生が終了するまで待機し（Ｓ１３：ＮＯ→Ｓ１３）、再生が終了すると（Ｓ１３：ＹＥＳ）、サーバ１に終了通知を送信し（Ｓ１４）、さらに結果データを送信する（Ｓ１５）。具体的には、会員Ａが実際に行った運動の運動名と、センサユニット３０から送信され、ＲＡＭ２３に記憶されていた会員Ａの心拍数データとが、結果データとして送信される。結果データを送信すると（Ｓ１５）、図８の運動支援処理は終了する。

以下に、図１１〜図１３を参照して、サーバ１において行われる運動コンテンツ配信処理について説明する。図１１は、運動コンテンツ配信処理のフローチャートである。図１２は、会員情報ＤＢ１４１０に記憶される心拍数データの説明図である。図１３は、更新された変更候補ＤＢ１４４０の説明図である。なお、図１１に示す運動コンテンツ配信処理は、ＲＯＭ１２に記憶されたプログラムに従って、ＣＰＵ１１が実行する。

図１１に示す運動コンテンツ配信処理は、サーバ１に接続されているいずれかのユーザ端末２からログインのための会員ＩＤを受信すると開始される。なお、以下では、利用者として会員Ａが登録されているユーザ端末２から会員ＩＤを受信したものとして説明する。処理が開始されると、ＣＰＵ１１はまず、受信した会員Ａの会員ＩＤを、ＲＡＭ１３に記憶させる（Ｓ５１）。そして、ＨＤＤ１４の会員情報ＤＢ１４１０（図３参照）を検索して、ユーザ端末２から受信した会員ＩＤが登録されているか否かに基づき、ログイン認証の可否を確認し（Ｓ５２）、結果を送信する（Ｓ５３）。具体的には、会員情報ＤＢ１４１０に会員ＩＤが記憶されていれば、会員Ａは運動支援システム１００の会員であるため、ＣＰＵ２１はログイン許可を許可し、運動目的を入力するための画面情報をユーザ端末２に送信する。一方、会員ＩＤが記憶されていなければ、会員Ａは運動支援システム１００の会員でないとして、認証が否認される。

サーバ１から認証結果を受信したユーザ端末２では、前述のように、会員Ａにより運動目的の入力が行われ、運動メニューの送信要求がサーバ１に送信される。サーバ１のＣＰＵ１１は、運動メニューの送信要求を受信すると、Ｓ５１で受信し、ＲＡＭ１３に記憶されている会員ＩＤに対応付けて、送信要求に含まれる運動目的を記憶させる（Ｓ５４）。図５を参照して前述したように、ＨＤＤ１４のデフォルトメニュー記憶エリア１４３には、各属性グループおよび運動目的毎に、複数の運動コンテンツの運動名が並べられたデフォルトメニュー１４３０が記憶されている。ＣＰＵ１１は、会員情報ＤＢ１４１０から、ＲＡＭ１３に記憶された会員ＩＤの（会員Ａの）会員情報を読み出して、会員Ａの属性に対応する属性グループを特定する。そして、デフォルトメニュー記憶エリア１４３から、特定された属性グループおよび運動目的に対応するデフォルトメニュー１４３０を選択する（Ｓ５５）。前述したように、デフォルトメニューは、運動メニューを構成する複数の運動コンテンツの運動名である。そこで、ＣＰＵ１１は、デフォルトメニューの運動名に従って、運動コンテンツＤＢ１４２０から該当する運動コンテンツを順に読み出し、ユーザ端末２に配信する会員Ａ用の運動メニューを作成する。そして、作成した運動メニューをユーザ端末２に配信する（Ｓ５６）。

その後、運動メニューを受信したユーザ端末２では、前述したように、会員Ａに運動コンテンツが提示されるが、会員Ａの運動中の心拍数が所定範囲を超えると、ユーザ端末２からサーバ１に対して次の運動コンテンツを変更するように要求が送信される。サーバ１のＣＰＵ１１は、ユーザ端末２からの変更要求を受信すると（Ｓ５７：ＹＥＳ）、そこに含まれる心拍数の変化量Δｂ／ｔおよびユーザ端末２で現在再生中の運動コンテンツの運動名をＲＡＭ１３に記憶させる（Ｓ５８）。そして、変更候補ＤＢ１４４０（図６参照）を検索して、変更に適した運動コンテンツの有無を確認する（Ｓ５９）。具体的には、会員Ａの属性グループのデータのうち、現在再生中の運動コンテンツからの移行後のデータを対象として、変化量Δｂ／ｔを考慮して、心拍数を所定範囲におさまるように推移させられる運動があるか否かを判断する。

例えば、ユーザ端末２において、会員Ａがサーバ１から最初に配信された運動メニューに従って運動を行ったところ、図１０に示すような心拍数データが得られたとする。この場合、運動２の時間枠Ｔ２の判定時間ｔ２において、会員Ａの心拍数ｂ２は上限値Ｕ１を超えている。よって、ユーザ端末２からサーバ１に対して、現在の運動コンテンツの運動名である運動２と、運動１から運動２への移行時の心拍数の変化量Δｂ／ｔとが通知され、運動２の次の運動コンテンツを変更するように要求される。なお、このときの変化量Δｂ／ｔは「＋３」、会員Ａが属する属性グループが「Ａ」だとする。この場合、まず、図６に示す変更候補ＤＢ１４４０の属性グループＡの運動１から運動２への移行データが参照される。変更候補ＤＢ１４４０には、運動１から運動２へ運動が移行した時の心拍数の予想変化量は＋２であると記憶されている。しかし、会員Ａが、運動１の後、運動２へ移行した時の実際の心拍数の変化量Δｂ／ｔは＋３である。すなわち、実変化量の予想変化量に対する割合は、１．５である。前述したように、運動２の運動中に会員Ａの心拍数は上限値を超えているため、次の運動ではこれを上限値以下に落とす必要がある。しかし、当初の運動メニュー通り、続いて運動２から運動３に移行した場合の心拍数の予想変化量は＋１であるから、このまま運動３に移行すれば、心拍数はさらに上昇し、上限値を超えたままになると予想される。ここで、変更候補ＤＢ１４４０に記憶された運動２からの移行後の運動の心拍数の予想変化量が、すべて運動３の＋１より大きい数値だったとする。この場合には、運動３を他のいずれの運動に変更しても、運動３以上に心拍数が上昇してしまうと予想される。したがって、この場合、ＣＰＵ１１は、運動３を他の運動に変更することは不可能と判断し（Ｓ６１：ＮＯ）、ユーザ端末２に対して、変更不可の通知を送信し（Ｓ６４）、ユーザ端末２から変更要求を受信したか否かの監視に戻る（Ｓ５７）。

一方、変更候補ＤＢ１４４０に、運動３の心拍数の予想変化量＋１より小さい数値の運動が記憶されていれば、運動３を他の運動に変更することができる（Ｓ６１：ＹＥＳ）。そこで、ＣＰＵ１１は、変更候補ＤＢ１４４０から、運動２の後の運動として最適なものを選択する（Ｓ６２）。具体的には、運動１から運動２へ移行した時の実変化量の予想変化量に対する増加割合１．５を相殺するために、運動２から運動３への移行時の予想変化量＋１に−１．５を乗じて得られる「−１．５」を予想変化量とする運動コンテンツを選択する。図６の例では、運動２からの移行時の予想変化量が−１．５の運動コンテンツはないため、予想変化量がこれに最も近い運動８または運動７の運動コンテンツが選択される。例えば、できるだけ緩やかに心拍数を変化させるために、予想変化量の絶対値がより小さい運動８が選択される。このようにして、会員Ａの属性グループと、会員Ａの現在の運動開始時の心拍数の変化量とに基づいて、変更後の運動コンテンツとして最適なものが選択される（Ｓ６２）。その後、ＣＰＵ１１は、変更後の運動コンテンツをユーザ端末２へ送信し（Ｓ６３）、ユーザ端末２から変更要求を受信したか否かの監視に戻る（Ｓ５７）。

ユーザ端末２から変更要求を受信しない場合には（Ｓ５７：ＮＯ）、ＣＰＵ１１は、ユーザ端末２から終了通知を受信したか否かを判断する（Ｓ７１）。終了通知とは、前述したように、ユーザ端末２において、運動メニューを構成するすべての運動コンテンツの再生が終了するとサーバ１に送信される通知である。これを受信すると（Ｓ７１：ＹＥＳ）、ＣＰＵ１１は、続いてユーザ端末２から結果データを受信し、受信した結果データをＲＡＭ１３に記憶させる（Ｓ７２）。結果データとは、前述したように、会員Ａが実際に行った運動の運動名および会員Ａが装着するセンサユニット３０により運動中に測定され、ユーザ端末２で記憶されていた会員Ａの心拍数データである（図１２参照）。

ユーザ端末２から結果データ（図１２参照）を受信すると、ＣＰＵ１１はまず、図３に示す会員情報ＤＢ１４１０の会員Ａの心拍数データを受信したデータで上書きして更新する（Ｓ７３）。そして、変更候補ＤＢ１４４０の心拍数の予想変化量を更新して、更新後の変化量に基づき、データの並べ替えを行う（Ｓ７４）。具体的には、まず、図１２に示す結果データから、各運動コンテンツから次の運動コンテンツへの移行時の心拍数の変化量Δｂ／ｔを算出し、変更候補ＤＢ１４４０の該当するデータの予想変化量を書き換える。例えば、図１２に示す会員Ａの結果データにおいて、運動１から運動２への移行時の実際の心拍数の変化量が＋３、運動２から運動８への移行時の変化量が−２．５、運動８から運動５への変化量が＋０．５だったとする。すると、変更候補ＤＢ１４４０では、図１３に示すように、運動１から運動２へ移行した場合の心拍数の予想変化量が、＋２から＋３に書き換えられる。また、運動２から運動８へへ移行した場合の心拍数の予想変化量が、−１から−２．５に書き換えられ、運動８の順序は変化量が−２の運動７の次に変更される。なお、図示はされていないが、運動８から運動５への移行データおよびそれ以降の運動についても、同様に処理が行われる。

続いて、更新された変更候補ＤＢ１４４０に基づいて、デフォルトメニュー記憶エリア１４３に記憶されたデフォルトメニュー１４３０の更新も行われる（Ｓ７５）。図５を参照して前述したように、デフォルトメニュー１４３０は、変更候補ＤＢ１４４０に記憶されたデータに基づき、属性グループおよび運動目的毎に定められた理想推移１４３１に沿って心拍数が推移するような運動を選択して組み合わせたものである。したがって、図１３に示すように変更候補ＤＢ１４４０が更新されると、理想推移１４３１に合わせて選択されるべき運動が変化する場合がある。例えば、元の理想推移１４３１とデフォルトメニュー１４３０が図５に示す通りだった場合、前述のように運動１から運動２へ移行した時の心拍数の変化量が＋２から＋３に書き換えられた結果、運動２は理想推移１４３１には適合しなくなったとする。このような場合には、例えば、デフォルトメニューの２番目の運動を、運動２から、より理想推移１４３１に適合する運動５（変化量１．５）に変更する。同様にして、時間枠Ｔ１〜Ｔｎの各々について、理想推移１４３１に最適な運動コンテンツが適宜選択されてデフォルトメニュー１４３０が更新された後（Ｓ７５）、サーバ１の運動コンテンツ配信処理は終了する。

以上に説明したように、本実施形態では、サーバ１の変更候補ＤＢ１４４０に、性別、年齢、身長、体重等に基づいて分類された属性グループ毎に、運動名と、この運動を行ったときの心拍数の予想変化量とが対応付けて記憶されている。なお、心拍数の予想変化量には、会員が過去に実際にこの運動を行った際に測定された心拍数の変化量を用いている。また、属性グループおよび運動目的毎に、標準的な運動コンテンツの組み合わせであるデフォルトメニューが設定されており、最初はこのデフォルトメニューに従って、会員のユーザ端末２に運動コンテンツが配信される。運動中は、会員が装着するセンサユニット３０によってバイタルデータである心拍数が常時測定されており、このデータがユーザ端末２に送信され、記憶されている。そして、会員の心拍数が、属性グループおよび運動目的に応じて定められた所定範囲を超えると、サーバ１に対して、この時再生中の運動コンテンツの運動を開始した時の心拍数の変化量とともに、次の運動コンテンツの変更要求が送信される。サーバ１では、会員の属性と心拍数の変化量とに基づいて、変更候補ＤＢ１４４０から、会員の心拍数を所定範囲に戻すのに最適な運動コンテンツが選択され、変更後の運動コンテンツとしてユーザ端末２に配信される。運動がすべて終了すると、会員が実際に行った運動の運動名と運動中に測定された心拍数データとが、結果データとしてサーバ１に送信される。サーバ１では、この結果データに基づき、各運動コンテンツに対応づけて記憶された心拍数の予想変化量を更新する。

このように、本実施形態では、過去に同じ属性グループに属する会員が運動を行った際、実際に心拍数がどのように変化したかが変更候補ＤＢ１４４０に記憶されており、これを考慮して変更後の運動コンテンツが選択される。したがって、変更後の運動コンテンツが一律に設定されている場合に比べ、現在運動中の会員にとって最適な運動コンテンツに変更することができる。

また、心拍数が属性グループと運動目的に応じて設定された上限値を超えた場合には、変更候補ＤＢ１４４０から、変更後の運動コンテンツとして、予想変化量がより小さく、実際の心拍数の変化量を相殺することができる運動コンテンツが選択される。同様に、心拍数が下限値に満たない場合には、変更候補ＤＢ１４４０から、変更後の運動コンテンツとして、予想変化量がより大きく、実際の心拍数の変化量を相殺することができる運動コンテンツが選択される。したがって、会員を、無理な運動や負荷が軽すぎる運動をしている状態から、速やかに適切な運動状態に推移させることができる。

本実施形態において、サーバ１およびユーザ端末２が、本発明の「運動支援装置」に相当する。ＨＤＤ１４の変更候補ＤＢ１４４０が、「コンテンツ記憶手段」に相当する。図１１のＳ５５で、デフォルトメニューを選択するサーバ１のＣＰＵ１１が、「コンテンツ選択手段」に相当する。図８のＳ９で、心拍数データを取得するユーザ端末２のＣＰＵ２１が、「データ取得手段」に相当する。図９のＳ２１で、心拍数データが上限値または下限値以内にあるか否かを判断するＣＰＵ２１が、「判断手段」に相当する。図１１のＳ６２で、変更候補ＤＢから変更後の運動コンテンツを選択するサーバ１のＣＰＵ１１が、「コンテンツ変更手段」に相当する。図１１のＳ７４で、変更候補ＤＢ１４４０を更新するＣＰＵ１１が、「データ書換え手段」に相当する。

また、本実施形態において、運動支援システム１００が、本発明の「運動支援システム」に相当し、ユーザ端末２およびサーバ１が、それぞれ「ユーザ端末」および「運動コンテンツサーバ」に相当する。また、図８のＳ４で、サーバ１に運動メニューの配信要求を送信するユーザ端末２のＣＰＵ２１が、「配信要求手段」に相当する。図８のＳ７で、受信した運動メニューを構成する運動コンテンツを再生するＣＰＵ２１が、「提示手段」に相当する。図８のＳ９で、センサユニット３０から送信された心拍数データを取得するＣＰＵ２１が、「データ取得手段」に相当する。図９のＳ２１で、心拍数データが上限値または下限値以内にあるか否かを判断するＣＰＵ２１が、「判断手段」に相当する。図９のＳ２４で、サーバ１に運動コンテンツの変更要求を送信するＣＰＵ２１が、「変更要求手段」に相当する。図９のＳ２７で、次の運動コンテンツを変更後の運動コンテンツに置き換えて運動メニューを更新するＣＰＵ２１が、「コンテンツ置き換え手段」に相当する。図８のＳ１５で、サーバ１に結果データを送信するＣＰＵ２１が、「データ送信手段」に相当する。

さらに、サーバ１の変更候補ＤＢ１４４０が、「コンテンツ記憶手段」に相当する。図１１のＳ５５で、デフォルトメニューを選択するサーバ１のＣＰＵ１１が、「コンテンツ選択手段」に相当する。図１１のＳ５６で、ユーザ端末２に運動メニューを配信するＣＰＵ１１が、「配信手段」に相当する。図１１のＳ６２で、変更候補ＤＢから変更後の運動コンテンツを選択するサーバ１のＣＰＵ１１が、「コンテンツ変更手段」に相当する。図１１のＳ７４で、変更候補ＤＢ１４４０を更新するＣＰＵ１１が、「データ書換え手段」に相当する。

なお、前述の実施形態に示される運動支援システム１００の構成は例示であり、本発明は各種の変形が可能なことはいうまでもない。例えば、前述の実施形態では、バイタルデータとして心拍数を採用しているが、心拍数の他、血圧や体温等を採用することができる。この場合、センサユニット３０には、心拍数センサに代えて、血圧センサや体温センサを設ければよい。

また、前述の実施形態では、運動支援システム１００の会員は、性別、年齢、身長および体重に基づいて、複数の属性グループに分類されている。しかし、属性として、例えば、病歴、体脂肪率、肺活量等、前述した以外の情報を利用してもよい。

また、前述の実施形態では、運動支援システム１００は、サーバ１とサーバ１にネットワーク５を介して接続されたユーザ端末２から構成されており、各ユーザ端末２について、運動支援システム１００の会員１名が特定されている。しかしながら、ユーザ端末２の利用者として、必ずしも１名の会員が特定される必要はなく、またユーザ端末２は１台であっても複数台であっても構わない。この場合、各会員が自己に付与されている識別コード（会員ＩＤ）を用いて適宜いずれかのユーザ端末２からサーバ１にログインすることにより、サーバ１でユーザ端末２を利用中の会員を特定すればよい。また、同時に複数人で利用することはできなくなるが、サーバ１とユーザ端末２を別の装置とせず、サーバ１のみで構成することも可能である。この場合は、サーバ１に、前述の実施形態ではユーザ端末２に設けられていたディスプレイ２８およびタッチパネル２９と、会員が装着するセンサユニット３０との通信を可能とするセンサ通信用Ｉ／Ｆ２６（図７参照）とを設ければよい。

また、前述の実施形態では、各運動コンテンツの時間枠Ｔｎ毎に定められた判定時間ｔｎに会員の心拍数が所定の上限値を超えたり、下限値に満たなかったりすると、次の運動コンテンツの変更要求がなされている。しかしながら、時間枠Ｔｎ毎に複数回判断を行い、心拍数が所定の上限値を超えた回数および下限値に満たなかった回数が所定回数以上になった場合や、所定回数連続して上限値を超えたり、下限値に満たなかったりした場合に限って変更要求を行ってもよい。

運動支援システム１００の概略構成を示すシステム構成図である サーバ１の電気的構成を示すブロック図である。 会員情報データベース１４１０の説明図である。 運動コンテンツデータベース１４２０の説明図である。 デフォルトメニュー記憶エリア１４３に記憶された心拍数の理想推移とデフォルトメニューの説明図である。 変更候補データベース１４４０の説明図である。 ユーザ端末２の電気的構成を示すブロック図である。 運動支援処理のフローチャートである。 運動支援処理中に実行される運動コンテンツ変更判断処理のフローチャートである。 運動コンテンツ変更判断処理における判断過程を説明するための心拍数の上限値、下限値および実推移の説明図である。 運動コンテンツ配信処理のフローチャートである。 会員情報ＤＢ１４１０に記憶される心拍数データの説明図である。 更新された変更候補ＤＢ１４４０の説明図である。

符号の説明

１００ 運動支援システム
１ サーバ
１１ ＣＰＵ
１４ ＨＤＤ
１４１０ 会員情報ＤＢ
１４２０ 運動コンテンツＤＢ
１４４０ 変更候補ＤＢ
２ ユーザ端末
２１ ＣＰＵ
３０ センサユニット

Claims (7)

1. 運動中のユーザのバイタルデータに基づいて、運動コンテンツを選択して提示する運動支援装置であって、
   年齢、性別、体格の少なくとも１つを含む属性ごとに、複数の運動コンテンツと、少なくとも１名の過去のユーザが他の運動コンテンツからの移行後に各運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である予想変化量とを対応づけて記憶するコンテンツ記憶手段と、
   前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツから、現在のユーザの属性に対応する複数の運動コンテンツの組み合わせである運動メニューを選択するコンテンツ選択手段と、
   前記現在のユーザのバイタルデータである現在データを、前記現在のユーザが前記運動メニューに従って運動している間に取得するデータ取得手段と、
   前記データ取得手段により取得された前記現在データの大きさが予め設定された上限値および下限値によって定められる所定範囲内にあるか否かを判断する判断手段と、
   前記判断手段により、前記現在データの大きさが前記所定範囲内にないと判断された場合に、前記現在データに基づき、前記現在のユーザが一つ前に提示された運動コンテンツからの移行後に現在提示中の運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である実変化量を算出する算出手段と、
   前記運動メニューに従って次に提示する予定の運動コンテンツである次コンテンツを、前記実変化量および前記現在のユーザの属性に対応する前記複数の運動コンテンツの前記予想変化量に基づいて、前記コンテンツ記憶手段に記憶された他の運動コンテンツに変更するコンテンツ変更手段と、
   前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツのうち、前記現在のユーザが実際に体験した運動コンテンツと対応づけられた前記予想変化量を、前記算出手段によって算出された前記実変化量に書き換えるデータ書換え手段とを備えたことを特徴とする運動支援装置。
2. 前記コンテンツ変更手段は、前記判断手段によって前記現在データの大きさが前記上限値よりも大きいと判断された場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも小さい前記予想変化量に対応する運動コンテンツを選択し、前記判断手段によって前記現在データの大きさが前記下限値よりも小さいと判断された場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする請求項１に記載の運動支援装置。
3. 前記コンテンツ変更手段は、前記判断手段によって前記現在データの大きさが前記上限値よりも大きいと判断された場合には、前記他の運動コンテンツとして、前記実変化量が大きくなるほどより小さい前記予想変化量に対応する運動コンテンツを選択し、前記判断手段によって前記現在データの大きさが前記下限値よりも小さいと判断された場合には、前記他の運動コンテンツとして、前記実変化量が小さくなるほどより大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする請求項２に記載の運動支援装置。
4. 請求項１〜３のいずれかに記載の運動支援装置の各種処理手段としてコンピュータを機能させる運動支援プログラム。
5. ユーザ端末と、前記ユーザ端末にネットワークを介して接続され、前記ユーザ端末へ運動コンテンツを配信する運動コンテンツサーバを備えた運動支援システムであって、
   前記ユーザ端末は、
   前記運動コンテンツサーバに対して、運動コンテンツの組み合わせである運動メニューの配信を要求する配信要求手段と、
   前記運動コンテンツサーバから配信された前記運動メニューを、現在のユーザである現在ユーザに提示する提示手段と、
   前記現在ユーザが前記運動メニューに従って運動している間のバイタルデータである現在データを取得するデータ取得手段と、
   前記データ取得手段によって取得された前記現在データが、予め設定された上限値および下限値によって定められる所定範囲内にあるか否かを判断する判断手段と、
   前記判断手段によって前記現在データの大きさが前記所定範囲内にないと判断された場合に、前記現在データに基づき、前記現在のユーザが一つ前に提示された運動コンテンツからの移行後に現在提示中の運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である実変化量を算出する算出手段と、
   前記運動コンテンツサーバに対して、前記算出手段によって算出された前記実変化量を送信するとともに、前記運動メニューで次に提示する予定の運動コンテンツである次コンテンツを、他の運動コンテンツに変更するように要求する変更要求手段と、
   前記次コンテンツを、前記変更要求手段からの要求に応じて前記運動コンテンツサーバから送信された前記他の運動コンテンツに置き換えるコンテンツ置き換え手段と、
   前記運動コンテンツサーバに対して、前記ユーザが実際に体験した運動コンテンツと対応付けて、前記データ取得手段によって取得された前記現在データを送信するデータ送信手段とを備え、
   前記運動コンテンツサーバは、
   年齢、性別、体格の少なくとも１つを含む属性ごとに、複数の運動コンテンツと、少なくとも１名の過去のユーザが他の運動コンテンツからの移行後に各運動コンテンツに従って運動した時に測定されたバイタルデータの変化量である予想変化量とを対応づけて記憶するコンテンツ記憶手段と、
   前記コンテンツ要求手段からの要求を受けた場合に、前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツから、前記現在のユーザの属性に対応する前記運動メニューを選択するコンテンツ選択手段と、
   前記ユーザ端末に対して、前記コンテンツ選択手段によって選択された前記運動メニューを配信する配信手段と、
   前記変更要求手段からの要求を受けた場合に、前記次コンテンツの変更後のコンテンツとして、前記実変化量および前記現在のユーザの属性に対応する前記複数のコンテンツの前記予想変化量に基づいて、前記コンテンツ記憶手段に記憶された他の運動コンテンツを選択するコンテンツ変更手段と、
   前記コンテンツ変更手段によって選択された前記他のコンテンツを前記ユーザ端末に配信する変更配信手段と、
   前記コンテンツ記憶手段に記憶された前記複数の運動コンテンツのうち、前記データ送信手段により送信された前記現在ユーザが実際に体験した運動コンテンツと対応づけられた前記予想変化量を、前記現在データに従って算出された前記実変化量に書き換えるデータ書換え手段と
   を備えたことを特徴とする運動支援システム。
6. 前記ユーザ端末の前記変更要求手段は、前記判断手段の判断結果を前記運動コンテンツサーバに送信し、
   前記運動コンテンツサーバの前記コンテンツ変更手段は、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記上限値よりも大きいことを示す場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも小さい前記予想変化量に対応する運動コンテンツを選択し、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記下限値よりも小さいことを示す場合には、前記他の運動コンテンツとして、前記次コンテンツの前記予想変化量よりも大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする請求項５に記載の運動支援システム。
7. 前記運動コンテンツサーバの前記コンテンツ変更手段は、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記上限値よりも大きいことを示す場合には、前記他の運動コンテンツとして、前記実変化量が大きくなるほどより小さい前記予想変化量に対応する運動コンテンツを選択し、前記変更要求手段から送信された前記判断結果が前記現在データの大きさが前記下限値よりも小さいことを示す場合には、前記他の運動コンテンツとして、前記実変化量が小さくなるほどより大きい前記予想変化量に対応する運動コンテンツを選択することを特徴とする請求項６に記載の運動支援システム。

Images