<第1の実施形態>
[1.情報処理システムの全体構成]
以下、図面を参照して、本実施形態に係る情報処理システム、情報処理サーバ、情報処理プログラム、および情報提供方法について説明する。まず、本実施形態に係る情報処理システムの全体構成について説明する。図1は、本実施形態における情報処理システムの構成の一例を示すブロック図である。図1に示すように、情報処理システムは、端末システム1と、データサーバ2と、サービスサーバ3とを含む。これらのシステムおよびサーバ1~3は、インターネットやモバイル通信網等のネットワーク4を介して互いに通信可能である。
端末システム1は、ユーザの元(例えばユーザの自宅)に配置される。なお、図1では端末システム1を1つのみ示すが、情報処理システムは、ユーザ毎にそれぞれ設けられる複数の端末システムを含んでいる。本実施形態においては、端末システム1は、ユーザの生体情報を取得し、生体情報から得られる健康情報をデータサーバ2へアップロードする(図1参照)。ここで、生体情報は、ユーザの身体から検出される情報である。本実施形態においては、呼吸、脈拍、および体動が生体情報として取得される。健康情報は、ユーザの健康および/または身体に関する情報である。本実施形態においては、健康情報は、ユーザの睡眠に関する指標である睡眠指標、および、ユーザの疲労に関する指標である疲労指標を含む。このように、端末システム1は、ユーザの生体情報を検出し、検出結果から睡眠指標および疲労指標を計算してデータサーバ2へアップロードするものである。上記端末システム1は、ユーザの健康状態を検出するものであり、QOL(Quality of Life)センサということもできる。
データサーバ2は、端末システム1から送信されてくるユーザの健康情報を記憶(蓄積)する。また、データサーバ2は、健康情報から得られる2次情報として統計量(例えば、所定期間における平均値等)を算出する。以下では、端末システム1から受信される健康情報と、それから得られる2次情報(統計量)とを総称して、健康情報と呼ぶことがある。
サービスサーバ3は、データサーバ2に記憶された健康情報を用いて、端末システム1のユーザに対して各種の情報を提供する。以下では、サービスサーバがユーザに対して提供する情報を「提供情報」と呼ぶ。提供情報は、ユーザの健康情報が示す指標を改善するための情報である。詳細は後述するが、提供情報は例えば、上記指標を改善するための商品やサービス(例えば、睡眠を改善するためのグッズや、疲労を回復するためのサプリメント等)を紹介する情報である。すなわち、本実施例においては、提供情報はユーザに対するリコメンド情報ともいえる。サービスサーバ3は、データサーバ2から取得した健康情報を用いて、提供情報を提供するサービスを行う。また、本実施形態においては、サービスサーバ3は、提供情報によって紹介される商品および/またはサービス(以下「商品・サービス」と記載する)をユーザに販売するサービスも行う。
なお、データサーバ2およびサービスサーバ3はそれぞれ、CPUおよびメモリを有する情報処理装置(すなわち、サーバ装置)を1以上含む。各サーバ2および3においては、CPUがメモリを用いて、自身に記憶された情報処理プログラムを実行することによって各種の情報処理が実行される。なお、本明細書では、「サーバ」とは、1つの情報処理装置(サーバ装置)を指す他、サーバが複数のサーバ装置によって構成される場合にはサーバ装置群(サーバシステム)全体を指す意味である。
[2.端末システムの構成]
次に、本実施形態における端末システム1の構成について説明する。図2は、端末システム1の構成の一例を示す図であり、図3は、端末システム1に含まれる各装置が配置される一例を示す図である。図2および図3に示すように、端末システム1は、主端末装置10と、副端末装置20とを含む。本実施形態において、主端末装置10および副端末装置20は、例えばユーザの寝室に配置される(図3参照)。詳細は後述するが、端末システム1は、主にユーザの就寝中(睡眠中)に生体情報を取得し、睡眠指標および疲労指標を算出する。
主端末装置10は、生体情報を検出するセンサとして機能する。本実施形態においては、図3に示すように、主端末装置10はユーザの枕元など、ユーザの周辺に配置され、就寝中におけるユーザの生体情報を検出する。
図2に示すように、主端末装置10は、生体情報を検出するセンサの一例であるドップラーセンサ11を備える。ドップラーセンサ11は、マイクロ波を発射するとともに、発射したマイクロ波の反射波を受信することによって、発射したマイクロ波の周波数と受信したマイクロ波の周波数との差に基づいて動体を検出する。詳細は後述するが、検出される生体情報であるドップラーセンサ11の出力波形を解析(周波数分析等)することで、呼吸、脈拍、および体動といった生体情報をさらに算出することができる。本実施形態では、ユーザがセンサを装着しない状態で生体情報を検出可能な、非装着型のセンサ(ドップラーセンサ11)を用いるので、ユーザの邪魔にならず(ユーザは睡眠を妨げられることなく)生体情報を検出することができる。
主端末装置10はカメラ12を備える。カメラ12は、ユーザを撮像するために用いられる。また、主端末装置10はマイク13を備える。マイク13は、ユーザから発生する音(いびき等)および/または周囲の騒音等を検出するために用いられる。
主端末装置10は、主端末装置10において実行される各種の情報処理を実行する処理部15を備える。処理部15は、主端末装置10の各部11~14および16~19に接続される。処理部15は、CPU(Central Processing Unit)およびメモリを有し、CPUがメモリを用いて、主端末装置10に記憶された情報処理プログラムを実行することによって上記各種の情報処理が実行される。本実施形態においては、処理部15は、上記情報処理として、センサによって検出された生体情報に基づいて健康情報を算出する処理等を実行する。また、主端末装置10が情報処理装置(情報処理端末)として機能する場合、処理部15は、当該機能のための各種の情報処理を実行する。
主端末装置10は、入出力インターフェースを備え、情報を入力したり閲覧したりするための情報処理装置(入出力端末)として機能する。具体的には、主端末装置10は、操作入力部14およびディスプレイ16を備える。操作入力部14は、ユーザによる操作入力を受け付ける任意の入力装置である。本実施形態においては、主端末装置10は、ディスプレイ16上に設けられるタッチパネルと、ボタンとを操作入力部14として有する。ディスプレイ16は、ユーザの生体情報および/または健康情報を表示したり、上記の提供情報を表示したりすることが可能である。また、ディスプレイ16は、鏡として機能する構成を有していてもよい。
主端末装置10は、LED等の光源を有する照明部17を備える。照明部17の発光は、処理部15によって制御される。照明部17は、例えば、ユーザの睡眠中において睡眠状態に応じた適切な光を発するように制御されたり、ユーザの起床時に目覚ましの目的で光を発するように制御されたりしてもよい。
主端末装置10と副端末装置20とは互いに通信可能である。一例として、主端末装置10は、副端末装置20との間の通信手段として、近距離無線通信部18を備える。本実施形態において、近距離無線通信部18は、無線LANによって通信を行う機能を有する通信モジュールである。例えば、近距離無線通信部18は、Wi-Fiの認証を受けた通信モジュールである。
また、主端末装置10は、ネットワーク4に接続して、各サーバ2および3と通信する機能を有している。具体的には、主端末装置10はモバイル通信部19を備える。本実施形態において、モバイル通信部19は、モバイル通信網に接続して通信を行う機能を有する通信モジュールである。例えば、モバイル通信部19は、3Gの通信規格、あるいは、4G(LTE(Long Term Evolution)を含む)の通信規格に準拠した通信方式で通信を行う。なお、主端末装置10が各サーバ2および3と通信するための方法は、Wi-Fiの認証を受けた通信モジュールによって無線LANを介して通信を行う方法であってもよい。また、主端末装置10は、モバイル通信網を介して各サーバ2および3と通信する機能と、無線LANを介して各サーバ2および3と通信を行う機能との両方を備えていてもよい。
副端末装置20は、主端末装置10とは異なる生体情報を取得するセンサとして機能する。図3に示すように、副端末装置20は、主端末装置10の近傍に配置される。副端末装置20は、その上に乗ったユーザの生体情報(体重等)を検出することが可能である。
図2に示すように、副端末装置20は荷重センサ21を備える。荷重センサ21は、副端末装置20の上面に加えられる荷重を検出する。なお、副端末装置20は、体重の他、体脂肪等を測定するための生体情報を検出するためのセンサを有していてもよい。
また、副端末装置20は、タッチパネル22を備える。タッチパネル22は、副端末装置20の上面に設けられる。タッチパネル22は、副端末装置20の上面に乗ったユーザの足の形を検出することが可能である。
副端末装置20は、副端末装置20において実行される各種の情報処理を実行する処理部23を備える。処理部23は、CPU(Central Processing Unit)およびメモリを有し、CPUがメモリを用いて、副端末装置20に記憶された情報処理プログラムを実行することによって上記各種の情報処理が実行される。
副端末装置20は、主端末装置10との間の通信手段として、近距離無線通信部24を備える。近距離無線通信部24は、主端末装置10の近距離無線通信部18と同様、無線LANによって通信を行う機能を有する通信モジュールであり、例えばWi-Fiの認証を受けた通信モジュールである。本実施形態においては、ユーザが副端末装置20の上に乗ったことが検出された場合、近距離無線通信部24は、所定の通知信号および荷重センサ21によって検出された生体情報を副端末装置20から主端末装置10へ送信する。
[3.端末システムにおける処理動作]
次に、端末システム1において実行される処理動作について説明する。本実施形態においては、主端末装置10は、通常モード、検出モード、およびスリープモードの3種類のモードで動作する。通常モードは、主端末装置10が入出力端末として用いられる場合のモードであり、ユーザからの操作入力を受け付けて、操作入力に応じた処理を実行したり、処理結果の画像をディスプレイ16に表示したりするモードである。検出モードは、就寝中におけるユーザの生体情報を検出し、健康情報を算出するモードである。スリープモードは、通常モードおよび検出モードにおいて実行される上記の処理が実行されず、電力消費が抑えられるモードである。ただし、スリープモードにおいても主端末装置10は副端末装置20からの信号を受信することが可能である。
なお、副端末装置20は、副端末装置20の上にユーザが乗ったことを常時検知可能である。すなわち、副端末装置20においては、荷重センサ21およびタッチパネル22の少なくとも一方が常時起動しており、副端末装置20の上にユーザが乗ったことを検知する。なお、他の実施形態においては、副端末装置20は、スリープモードと、(少なくとも処理部23が動作する)オンモードとで動作可能であってもよい。スリープモードは、処理部23が動作せず、荷重センサ21およびタッチパネル22の少なくとも1つが動作するモードである。オンモードは、少なくとも処理部23が動作するモードである。このとき、副端末装置20は、スリープモードである状態において自身の上にユーザが乗ったことが荷重センサ21および/またはタッチパネル22で検知されると、オンモードに移行してもよい。
(検出モード時の処理)
以下、端末システム1がユーザの就寝中に検出モードで動作する際の処理について説明する。ユーザの就寝前において、主端末装置10はスリープモードまたは通常モードであるとする。このとき、ユーザが副端末装置20に乗る(図3に示す(1)参照)と、副端末装置20の処理部23は、副端末装置20の上にユーザが乗ったことを検知し、荷重センサ21の検出結果に基づいて体重を測定する。また、処理部23は、タッチパネル22の検出結果に基づいてユーザの足の形を算出する。なお、他の実施形態においては、副端末装置20はカメラを備えていてもよく、処理部23は、カメラによって撮影された画像に基づいて足の形を算出してもよい。
本実施形態においては、処理部23は、算出された足の形を用いてユーザに対する認証処理を実行する(図3に示す(2)参照)。すなわち、正当なユーザの足の形を示すデータは副端末装置20において予め登録(記憶)されており、処理部23は、算出された足の形と、登録された足の形とが一致するか否かを判定することによって、認証を行う。2つの足の形が一致すると判定した場合、処理部23は、認証が成功したと判断する。この場合、処理部23は、所定の認証通知を主端末装置10へ送信する(図3に示す(3)参照)。なお、処理部23は、上記認証通知とともに、副端末装置20で検出された生体情報(体重等の情報)を主端末装置10へ送信してもよい。一方、2つの足の形が一致しないと判定した場合、処理部23は、認証が失敗したと判断する。この場合、処理部23は、認証通知を主端末装置10へ送信しない。
主端末装置10は、上記認証通知を受信すると、スリープモードまたは通常モードから検出モードへ移行する(図3に示す(4)参照)。これ以降、ユーザの生体情報が主端末装置10によって取得されることになる。
検出モードが開始されると、主端末装置10の処理部15はまず、生体情報の検出用センサ(本実施形態ではドップラーセンサ11)を起動し、センサの検出結果の取得を開始する。なお、検出用センサとしてカメラ12および/マイク13を用いる場合には、処理部15は、カメラ12および/マイク13を起動してもよい。検出モード中において、ドップラーセンサ11は継続的に検出を行い、検出結果である出力波形を継続的に出力する。処理部15は、ドップラーセンサ11の検出結果(出力波形)に基づいて健康情報(睡眠指標および疲労指標)を算出する。
(健康情報の算出)
以下、ドップラーセンサ11の検出結果に基づいて健康情報(睡眠指標および疲労指標)を算出する処理について説明する。図4は、処理部15において健康情報を算出するための機能的構成の一例を示す機能ブロック図である。図4に示すように、処理部15は、波形解析部31と、睡眠算出部32と、自律神経算出部33と、疲労算出部34とを含む。
波形解析部31は、ドップラーセンサ11が検出した生体情報(出力波形)に基づいて、呼吸、脈拍、および体動をさらなる生体情報として算出する。ここで、従来より、ドップラーセンサ11の出力波形を周波数に応じて分離することによって、呼吸、脈拍、および体動を表す波形を得ることができることが知られている。波形解析部31は、周波数解析等によって出力波形を、呼吸に対応する周波数帯域と、脈拍に対応する周波数帯域と、体動に対応する周波数帯域とに分離し、分離したそれぞれの波形データを出力する。図4に示すように、波形解析部31の出力は、睡眠算出部32および自律神経算出部33にそれぞれ入力される。
睡眠算出部32は、生体情報(呼吸、脈拍、および体動)に基づいて各種の睡眠指標を算出する。ここで、従来より、呼吸、脈拍、および体動に基づいて睡眠指標を算出する方法が知られている。本実施形態においては、睡眠算出部32は、以下の情報を示す睡眠指標を算出する。
・睡眠潜時(入眠潜時)
・中途覚醒時間
・中途覚醒回数
・睡眠効率
・総睡眠時間
・睡眠時活動量
・睡眠ステージ
・レム睡眠時間
・ノンレム睡眠時間
・睡眠品質
なお、他の実施形態においては、上記の睡眠指標のうちのいくつかのみが算出されてもよいし、上記の睡眠指標とは異なる種類の睡眠指標が算出されてもよい。
自律神経算出部33は、生体情報に基づいて、自律神経(交感神経および副交感神経)の働き度合いを示す指標(自律神経指標)を算出する。具体的には、生体情報に含まれる脈拍(RR間隔)の波形を、最大エントロピー法、フーリエ変換によって周波数解析し、当該波形の高周波成分(約0.15~0.40[Hz])HFと低周波成分(約0.04~0.15[Hz])LFとを算出する。ここで、上記高周波成分HFは、副交感神経の働き度合いを示すことが知られており、上記低周波成分LFは、交感神経の働き度合いを示すことが知られている。また、副交感神経の働き度合いと交感神経の働き度合いとの割合によって疲労度を評価できることが知られている(例えば、特開2010-201113号公報参照)。したがって、自律神経算出部33は、自律神経指標として、上記高周波成分HFと低周波成分LFとの割合(LF/HF)を算出する。図4に示すように、自律神経算出部33の出力は、疲労算出部34において入力として用いられる。
疲労算出部34は、上記睡眠指標および自律神経指標に基づいて、疲労指標を算出する。なお、本実施形態においては、疲労指標として、疲労の度合い(レベル)を1から5の5段階で示す疲労度が算出される。疲労指標の算出方法は任意であるが、例えば以下の方法が考えられる。
第1の方法は、睡眠指標から疲労指標を算出する方法である。ここで、睡眠指標は、疲労度との相関があると考えられる。例えば、疲労度が高いと推測される例としては、以下が挙げられる。
・睡眠潜時が長い。
・中途覚醒時間が長い。
・中途覚醒回数が多い。
・睡眠効率が悪い。
・総睡眠時間が短い。
・レム睡眠時間とノンレム睡眠時間とのバランスが悪い(レム睡眠時間とノンレム睡眠時間との比率が、正常な範囲から外れている)。
したがって、疲労算出部34は、睡眠指標が上記の例に該当すれば疲労度が高くなり、上記の例に該当しなければ疲労度が低くなるように、疲労度を算出する。例えば、疲労算出部34は、上記の各項目について該当するか否かを判定し、該当する数に応じたポイントを計算し、合計のポイントに応じて疲労度を算出するようにしてもよい。このとき、疲労算出部34は、項目毎に重みを付してポイントを計算してもよい。また、各項目について基準値(例えば、総睡眠時間について「6時間」)を設定し、算出された睡眠指標の値が基準値から離れているほどポイントが大きくなるように、ポイントが計算されてもよい。
以上のように、本実施形態においては、生体情報に基づいて、ユーザの睡眠に関する睡眠指標が算出され、睡眠指標に基づいて疲労指標が算出される。上記のように、睡眠指標と疲労の度合いとの間には相関があると考えられるので、睡眠指標に基づいて疲労指標を算出することによって、疲労指標の精度を向上することができる。
第2の方法は、所定期間(例えば1週間)における睡眠時間に基づいて疲労度を算出する方法である。ここで、従来より、疲労リスク管理システム(FRMS(Fatigue Risk Management System))において、睡眠時間と労働時間とに基づいて疲労度を算出する手法がある。上記手法において例えば簡易的に労働時間を一定とすることで、睡眠時間(のみ)に基づいて疲労度を算出することができる。
第3の方法は、自律神経指標に基づいて疲労度を算出する方法である。上述のように、交感神経と副交感神経との働き度合いのバランス、すなわち、上記の自律神経指標を用いて疲労度を評価できることが知られている。したがって、疲労算出部34は、例えば、自律神経指標の値が基準値から離れるほど疲労度が高くなるように疲労度を算出する。
本実施形態においては、疲労算出部34は、上記3つの方法を用いて疲労度を算出する。具体的には、疲労算出部34は、上記3つの方法でそれぞれ疲労度を算出し、算出された各疲労度に基づいて最終的な疲労度を算出する。疲労算出部34は、例えば、3つの疲労度の平均値を最終的な疲労度としてもよいし、3つのうちいずれかの疲労度に重みを付して最終的な疲労度を算出してもよい。
なお、他の実施形態においては、疲労指標の算出方法は任意であり、疲労指標の内容も任意である。他の実施形態においては、疲労指標として、疲労の種類毎に疲労度合いを示す値が算出されてもよい。例えば、他の実施形態においては、疲労指標は、急性疲労の度合いを示す値と、累積疲労の度合いを示す値と、精神疲労の度合いを示す値という3種類の値であってもよい。
また、他の実施形態においては、カメラ12および/またはマイク13の検出結果を用いて健康情報を算出してもよい。例えば、カメラ12で撮像されたユーザの画像に基づいて、脈拍および/または体動といった生体情報を算出することが可能である。したがって、処理部15は、ドップラーセンサ11の検出結果から得られるこれらの生体情報に加えて(または代えて)、カメラ12による撮像画像から得られる生体情報を用いて睡眠指標(および疲労度)を算出してもよい。また、処理部15は、マイク13で検出されるいびきの音を考慮して睡眠指標を算出してもよい。
図5は、主端末装置10の処理部15において実行される処理の流れの一例を示すフローチャートである。なお、図5においては、主に検出モードにおける処理が示されており、通常モードおよびスリープモードにおける処理は示されていない。
なお、本出願において、図面(図5、図16、図17、および図32)に示すフローチャートにおける各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて(または代えて)別の処理が実行されてもよい。また、本明細書では、上記フローチャートの各ステップの処理を処理部のCPUが実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、CPU以外のプロセッサや専用回路が実行するようにしてもよい。
図5に示すステップS1において、処理部15は、副端末装置20からデータの受信を確認する。なお、ステップS1の実行時点では、主端末装置10はスリープモードまたは通常モードである。スリープモードまたは通常モードにおいては、処理部15は、ステップS1(およびS2)の処理を所定時間に1回の割合で繰り返し実行する。
ステップS2において、処理部15は、検出モードに移行するか否かを判定する。すなわち、処理部15は、上記ステップS1で副端末装置20から上述の認証通知を受信した場合、検出モードに移行すると判定し、認証通知を受信しなかった場合、検出モードに移行しないと判定する。ステップS2の判定結果が肯定である場合、ステップS3の処理が実行される。一方、ステップS2の判定結果が否定である場合、ステップS1の処理が再度実行される。
ステップS3において、処理部15は、主端末装置10の動作モードを検出モードに移行させる。すなわち、処理部15はドップラーセンサ11を起動する。続くステップS4において、処理部15は、ドップラーセンサ11の検出結果を取得する。さらに、続くステップS5において、処理部15は、検出結果に基づいて呼吸、脈拍、および体動をさらなる生体情報として算出する。検出モードにおいては、ステップS4~S6の一連の処理が所定時間に1回の割合で繰り返し実行される。したがって、検出モード中において、生体情報が繰り返し取得(算出)されて、処理部15のメモリに逐次記憶される。
ステップS6において、処理部15は、検出モードを終了するか否かを判定する。本実施形態においては、検出モードを終了するか否かの判定は、ユーザが就寝中でなくなったか否かによって行われる。具体的には、処理部15は、ドップラーセンサ11の検出結果に基づいて、ドップラーセンサ11の検出範囲からユーザがいなくなったか否かを判定する。そして、ユーザがいなくなった場合、処理部15は、ユーザが就寝中でなくなったと判断し、検出モードを終了すると判定する。一方、ドップラーセンサ11の検出範囲内にユーザがいる場合、処理部15は、ユーザが就寝中であると判断し、検出モードを終了しないと判定する。ステップS6の判定結果が肯定である場合、ステップS7の処理が実行される。一方、ステップS6の判定結果が否定である場合、ステップS4の処理が再度実行される。
ステップS7において、処理部15は、ドップラーセンサ11の検出結果に基づいて健康情報を算出する。すなわち、上記“(健康情報の算出)”の欄で述べたように、生体情報に基づいて睡眠指標および疲労指標が算出される。続くステップS8において、処理部15は、ステップS7で算出された健康情報をデータサーバ2へ送信する。このように、本実施形態においては、健康情報は、自動的に(ユーザの操作を必要とせずに)生成されてデータサーバ2へ送信される。なお、他の実施形態においては、端末システム1からデータサーバ2へ送信される情報は、ユーザによる送信操作に応じて送信されてもよい。また、処理部15は、上記認証通知とともに副端末装置20から受信される情報(体重等の生体情報)を、健康情報とともにデータサーバ2へ送信してもよい。
ステップS9において、処理部15は、主端末装置10の動作モードをスリープモードに移行させる。すなわち、処理部15はドップラーセンサ11の動作を停止させる。ステップS9によってスリープモードへと移行した後は、上述したステップS1の処理が再度実行される。
以上のように、本実施形態においては、センサ(ドップラーセンサ11)の検出結果である生体情報に基づいて健康情報を算出する処理は、端末(端末システム1)側で実行されたが、この処理は、端末側とサーバ側とでどのように分担されてもよい。例えば、他の実施形態においては、端末システム1は、生体情報をデータサーバ2へ送信し、データサーバ2が生体情報に基づいて健康情報を算出するようにしてもよい。なお、このとき、いくつかの健康情報(例えば、睡眠時間や睡眠効率等)は端末システム1においても算出され、適宜のタイミングでディスプレイ16に表示されてもよい。これによれば、端末システム1は、データサーバ2からデータを取得しなくても、健康情報をユーザに提供することができる。また、データサーバ2が算出した健康情報が、端末システム1へ送信されて端末システム1において表示されてもよい。
また、本実施形態において、端末システム1からデータサーバ2へ送信される健康情報は、検出モードの終了時に送信されるものとした。ここで、他の実施形態においては、端末システム1からデータサーバ2へ送信される送信情報(生体情報および/または健康情報)は、検出モード中において逐次送信されてもよい。
(通常モードにおける処理)
本実施形態においては、主端末装置10は、スリープモードにおいてユーザが所定の操作(例えば所定の電源ボタンを押下する操作)を行ったことに応じて、通常モードへ移行する。詳細は後述するが、通常モードでは、主端末装置10はサービスサーバ3にアクセスして、ユーザの健康情報をディスプレイ16に表示したり、サービスサーバ3から提供される提供情報をディスプレイ16に表示したりする。また、主端末装置10は、通常モードにおいてユーザが所定の操作(例えば所定の電源ボタンを押下する操作)を行ったことに応じて、スリープモードへ移行する。
(端末システムによる作用効果)
以上のように、本実施形態においては、端末システムは、ユーザに関する第1の生体情報を検出する第1センサ(ドップラーセンサ11)を備える第1装置(主端末装置10)と、当該ユーザに関する生体情報であって、第1の生体情報とは異なる第2の生体情報を検出する第2センサ(荷重センサ21)を備える第2装置(副端末装置20)とを備える。また、端末システムは、第1の生体情報および第2の生体情報に基づく分析を行うサーバ(データサーバ2)と通信可能である。
また、端末システムは、上記第1の生体情報および第2の生体情報と、生体情報から得られる健康情報とのうち少なくとも一方を含む送信情報を、サーバ(データサーバ2)へ送信する。なお、第1の生体情報(およびそれに基づく健康情報)と、第2の生体情報(およびそれに基づく健康情報)とは、異なる装置から別々に送信されてもよい。サーバは、端末システムから送信されてくる送信情報に基づく分析を行う。
以上によって、端末システムは、2つの装置によって多くの生体情報を取得することができるので、サーバにおける分析の品質を向上することができる。すなわち、サーバにおいては、より多彩な分析あるいはより精度の良い分析を行うことができる。
本実施形態において、上記第1センサ(ドップラーセンサ11)は、就寝中におけるユーザの生体情報を検出し、第2センサ(荷重センサ21)は、起床中(例えば、就寝前および起床後)におけるユーザの生体情報を検出する。これによれば、就寝中の期間においてもそうでない期間においても生体情報を取得することができるので、サーバにおける分析の品質を向上することができる。
本実施形態において、上記第1センサは、ユーザがセンサに接触しない状態で生体情報を検出可能な非接触型のセンサであり、第2センサは、ユーザがセンサに接触した状態で生体情報を検出可能な接触型のセンサである。これによれば、就寝中においてはユーザが気にならない方法で生体情報を検出することができるとともに、起床中においてはより確実な方法で生体情報を検出することができる。
本実施形態において、第1装置は、以下の手段を備える。
・第2センサが検出した第2の生体情報を第2装置から受信する受信手段
・第1センサが検出した第1の生体情報および第2装置から受信した第2の生体情報と、これらの生体情報に基づく健康情報とのうち少なくとも一方を含む送信情報を上記サーバ(データサーバ2)へ送信する送信手段
上記構成によれば、2つの装置で検出される生体情報(および/または健康情報)を、効率良くサーバへ送信することができる。また、第2装置はサーバとの間で通信を行う機能を有していなくてもよいので、装置の構成を簡易化することができる。
詳細は後述するが、本実施形態において、サーバ(サービスサーバ3)は、分析結果に基づく情報(後述する提供情報)を端末システムへ送信する。第1装置は、上記サーバから送信されてくる情報を受信する受信手段と、受信された情報を表示する表示手段とを備える。これによれば、ユーザは、第1装置を用いて上記の情報を容易に閲覧することができる。また、生体情報を検出する第1装置において上記の情報が表示されるので、端末システムの構成を簡易化することができる。
なお、他の実施形態においては、端末システム1は、提供情報を受信して表示する装置(情報端末)を主端末装置10とは別に有していてもよい。この情報端末は、例えば、携帯端末、パーソナルコンピュータ、および、ゲーム装置等、ユーザが使用する任意の情報処理装置であってよい。例えば、ユーザの情報端末がサービスサーバ3にアクセスして提供情報を受信して表示するようにしてもよい。また、後述する商品・サービスの購入も情報端末を用いて行うことができるようにしてもよい。
本実施形態において、第2装置は、第2の生体情報を検出したことに応じて、所定の通知(認証通知)を第1装置へ送信する。第1装置は、上記所定の通知を受信したことに応じて、第1の生体情報の検出を開始する。これによれば、第1装置において生体情報の検出動作を効率良く実行することができ、第1装置における情報処理の効率化を図ることができる。また、第1装置の省電力化を図ることができる。
本実施形態において、第2装置は、第2の生体情報を検出したことに応じて、ユーザの生体情報(タッチパネル22によって検出される足の形)を用いてユーザに対する認証処理を実行する。そして、第2装置は、認証処理が成功した場合(すなわち、予め登録された1以上のユーザのうちの1人のユーザであることが認証処理によって確認された場合)、上記所定の通知を第1装置へ送信する。これによれば、登録されたユーザであることが確認された場合に第1装置において生体情報の検出が開始されるので、検出処理を効率良く実行することができる。また、登録されたユーザが複数である場合には、検出処理の対象となるユーザを特定することができる。なお、認証処理に用いられる生体情報は、上記第2の生体情報であってもよいし、他の生体情報であってもよい。
また、本実施形態においては、主端末装置10は、副端末装置20における認証処理が成功したことを条件として生体情報の測定(検出)を開始し、生体情報が検出されなくなったこと(ユーザが検出されなくなったこと)を条件として生体情報の測定を終了した。ここで、他の実施形態においては、生体情報の測定期間の決定方法は任意であり、他の方法で測定期間が決定されてもよい。
例えば、他の実施形態においては、主端末装置10は、センサ(ドップラーセンサ11)によって間欠的に検出を行い、その検出結果に基づいて測定期間を決定してもよい。具体的には、主端末装置10は、所定時間間隔でドップラーセンサ11による検出を行うことによって、ユーザが検出されるか否か(ユーザが検出範囲内に存在するか否か)を判定する。ユーザが検出されない場合、主端末装置10は、ドップラーセンサ11による検出を停止する。この場合、測定は開始されない。一方、ユーザが検出される場合、主端末装置10は、ドップラーセンサ11による検出をそのまま継続することによって、測定を開始する。さらに、測定を開始した場合、主端末装置10は、ドップラーセンサ11によってユーザが検出される間、測定を継続する。つまり、上記実施形態と同様、主端末装置10は、ユーザが検出されなくなったことに応じて、ドップラーセンサ11による測定を終了する。以上によれば、ドップラーセンサ11による測定期間を、ドップラーセンサ11自身による(間欠的に行われる)検出結果に基づいて決定することができる。これによれば、他のセンサ等の装置を用いることなく、測定期間を決定することができるので、装置の構成を簡易化することができる。
また、他の実施形態においては、ドップラーセンサ11の測定期間は、ドップラーセンサ11とは異なるセンサ(例えば人感センサ)の検出結果に基づいて決定されてもよい。例えば、端末システム1は、人感センサとして、赤外線センサおよび/またはカメラを用いてもよい。具体的には、端末システム1は、人感センサによって、間欠的に、または、連続してユーザを検知する。そして、人感センサによってユーザが検知される期間において、端末システム1は、ドップラーセンサ11による測定を行う。これによっても、本実施形態の方法、および、上記ドップラーセンサ11の検出結果に基づいて測定期間を決定する方法と同様、測定期間を自動的に決定することができる。すなわち、ユーザは測定(の開始および終了)のために操作を行う必要がないので、端末システム1の利便性を向上することができる。さらに言えば、ユーザに手間や負担をかけることなく生体情報の測定を行うことができるので、継続的な生体情報の取得が行いやすくなる。
また、他の実施形態においては、ドップラーセンサ11の測定期間は、予め定められていてもよい。例えば、端末システム1は、所定の時間帯(例えば、夜の20時から翌朝の10時までの時間帯)において測定を行うようにしてもよいし、(ユーザによる停止操作がない限り)測定を常時行うようにしてもよい。これによっても上記と同様、ユーザは測定の開始および終了のために操作を行う必要がないので、端末システム1の利便性を向上することができる。
また、上記実施形態においては、端末システム1は、生体情報の測定を自動的に行うことに加えて、生体情報に基づく健康情報(睡眠指標および疲労指標)の算出を自動的に(換言すれば、ユーザによる特定の操作が無くても)行う。したがって、ユーザが特別な操作を行わなくても端末システム1において健康情報が算出されるので、端末システム1の利便性を向上することができる。
本実施形態において、単一の装置である第1装置は、上記サーバとの間で携帯電話通信網を介して通信を行う第1通信手段(モバイル通信部19)と、第2装置との間で近距離無線通信を行う第2通信手段(近距離無線通信部18)とを備える。第1装置は、サーバおよび第2装置に対して容易に通信を行うことができる。
以上のように、本実施形態における端末システム1では、非接触型のセンサ(ドップラーセンサ)を用いるので、ユーザはセンサを装着する必要が無い。また、就寝中において自動的に生体情報が測定されるので、ユーザは生体情報の測定を待つ必要が無く、測定のために煩雑な操作を行う必要も無い。さらに、就寝時のユーザの周辺にセンサを配置しておけば、測定の度に煩雑な設定作業を行う必要も無い。以上より、端末システム1によれば、ユーザに手間や負担をかけることなく生体情報の測定を行うことができるので、継続的な生体情報の取得が行いやすくなる。
また、端末システム1は、ユーザの入眠あるいは起床(覚醒)を誘導するコンテンツ(音楽等)を再生してもよい。例えば、主端末装置10は、ドップラーセンサ11による検出を開始したことに応じて、ユーザに対して入眠を誘導するような音楽を再生してもよい。このとき、主端末装置10は、ユーザの睡眠状態に応じてコンテンツの再生を制御するようにしてもよい。これによれば、ユーザの睡眠状態に応じた適切な方法でコンテンツを再生することができ、コンテンツを効果的に再生することができる。また、効果が小さいと思われる状況(例えば、ユーザが熟睡している状況)におけるコンテンツの再生を停止することによって、消費電力の低減を図ることができる。以下、一例である具体例を説明する。
主端末装置10は、ユーザの睡眠中において、ドップラーセンサ11による検出結果(生体情報)に基づいてユーザの睡眠状態を判別する。例えば、主端末装置10は、睡眠状態であるか否か、および、眠りの深さ(レム睡眠かノンレム睡眠か等)をリアルタイムに判別する。なお、上記「リアルタイムに判別する」とは、厳密な意味で即時に判別することに限らず、数秒程度の遅れを生じて判別することをも含む意味である。
主端末装置10は、睡眠中に判別されるユーザの睡眠状態に応じてコンテンツの再生を制御する。主端末装置10は、コンテンツの再生/停止を睡眠状態に応じて制御してもよいし、再生方法(例えば、音量および/または再生速度等)を睡眠状態に応じて制御してもよい。例えば、主端末装置10は、ユーザの入眠前に、ユーザに入眠を促すためのコンテンツの再生を開始しておき、ユーザが入眠したことに応じてコンテンツの再生を停止してもよい。あるいは、主端末装置10は、ユーザが入眠したことに応じてコンテンツの再生音量を次第に減少させていき、ユーザの眠りが深くなった(例えばノンレム睡眠の状態となった)ことに応じてコンテンツの再生を停止してもよい。また例えば、主端末装置10は、ユーザが覚醒したタイミングに応じて、コンテンツ(例えば、ユーザに覚醒を促すためのコンテンツ)の再生を開始してもよいし、ユーザがもうすぐ覚醒すると推測されるタイミングに応じて、コンテンツの再生を開始してもよい。
なお、端末システム1においてユーザの睡眠時に再生されるコンテンツは、端末システム1に記憶されていてもよいし、外部装置(例えばサービスサーバ3)から取得されてもよい。例えば、サービスサーバ3は、商品・サービスの提供に関する提供処理(後述するステップS22)において、上記コンテンツを端末システム1へ送信するようにしてもよい。
[4.情報処理システムにおける処理動作]
次に、情報処理システムにおいて実行される処理動作について説明する。図6は、情報処理システムにおける動作の流れの一例を示すタイミングチャートである。以下では、大略的には次のような動作が情報処理システムにおいて行われる場合の処理動作を例として説明する。
<1>端末システム1において取得された健康情報がデータサーバ2へ繰り返し送信されて蓄積される。
<2>サービスサーバ3は、データサーバ2に蓄積された健康情報を用いて、商品・サービスを紹介する提供情報を生成して端末システム1へ提供する。
<3>端末システム1において提供情報を閲覧したユーザが、提供情報で紹介された商品・サービスを購入(無料の商品・サービスの場合には、商品・サービスを利用(享受)する旨の申し込み)する。
<4>商品・サービスの購入後、サービスサーバ3は、データサーバ2に蓄積された健康情報を用いて、追加の提供情報を生成して端末システム1へ提供する。
ここで、本実施形態において、サービスサーバ3は、ポータルサーバ41と、サービス提供サーバ42とを含む。ポータルサーバ41は、データサーバ2に蓄積された健康情報や上述した提供情報をユーザに提供するためのポータルサイトを管理するサーバである。ポータルサーバ41は、データサーバ2へアクセスし、データサーバ2に蓄積された健康情報を用いて提供情報を生成してユーザ(端末システム1)に提供する機能を有する。
また、サービス提供サーバ42は、商品・サービスをユーザに提供する処理を実行するためのサーバである。ここで、本実施形態においては、サービス提供サーバ42によって提供される商品・サービスの購入は、ポータルサーバ41によって管理される。すなわち、上記ポータルサイトは、サービス提供サーバ42によって提供される商品・サービスを販売するためのショッピングサイトの機能を有している。ユーザは、端末システム1を用いてポータルサイトにアクセスし、当該ポータルサイト内で上記商品・サービスを購入する。なお、典型的には、サービス提供サーバ42は、個々の商品・サービスを提供するサービス事業者によって管理され、ポータルサーバ41は、データサーバ2を管理する管理事業者によって管理される。サービス提供サーバ42は、例えばサービス事業者毎に複数のサーバが設けられてもよい。
<1>健康情報がデータサーバに蓄積される処理
上記“[3.端末システムにおける処理動作]”で述べたように、端末システム1は、健康情報をデータサーバ2へ送信(アップロード)する(図6に示すステップS11)。本実施形態においては、端末システム1は、予めユーザ毎に設定されたユーザ識別情報とともに健康情報を送信する。なお、図6では図示を省略するが、端末システム1からデータサーバ2への健康情報の送信は、定期的に(本実施形態においては1日1回)継続して行われる。
データサーバ2は、端末システム1から受信した健康情報をユーザ毎に記憶する。図7は、データサーバ2に記憶されるデータの一例を示す図である。図7に示すように、データサーバ2は、上記ユーザ識別情報と健康情報とを含むユーザ情報を、ユーザ毎に記憶する。すなわち、データサーバ2は、あるユーザの端末システム1から健康情報を受信すると、受信した健康情報を、当該あるユーザに関するユーザ情報内の健康情報に追加する。これによって、健康情報がデータサーバ2に蓄積される。
また、データサーバ2は、適宜のタイミングで、受信した健康情報に基づいて2次情報を算出する(ステップS12)。つまり、データサーバ2は健康情報を分析して2次情報を得る。上述のように、本実施形態においては、2次情報は、受信した健康情報から算出される統計量の情報である。例えば、2次情報として1週間の平均睡眠時間を算出する場合、データサーバ2は、1週間分の睡眠時間のデータが蓄積される度に、当該平均睡眠時間を算出する。本実施形態においては、2次情報も健康情報としてデータサーバ2において蓄積される。
なお、図7に示すように、データサーバ2には、利用管理テーブルが記憶されるが、この利用管理テーブルについては後述する。
<2>サービスサーバ3が提供情報を端末システム1へ提供する処理
端末システム1は、ユーザの指示に応じて、サービスサーバ3のポータルサーバ41が管理するポータルサイトにアクセスする(ステップS13)。すなわち、ユーザは、主端末装置10を通常モードにして、ポータルサイトにアクセスする操作を行う。ポータルサイトへログインする方法は任意であり、従来と同様の方法が用いられてもよい。本実施形態においては、ログイン画面がディスプレイ16に表示され、ユーザはユーザ識別情報とパスワードとを入力する。ポータルサーバ41は、ユーザ識別情報とパスワードとを用いて認証を行い、認証が成功した場合、端末システム1(のユーザ)はポータルサイトにログインすることができる。
なお、他の実施形態においては、ポータルサイトへのログインは、端末システム1において行われた個人認証を用いて行われてもよい。例えば、副端末装置20において認証が成功した場合に、主端末装置10がポータルサイトへアクセスしてログインが行われるようにしてもよい。このとき、主端末装置10は、ユーザ識別情報およびパスワードの入力をユーザに要求しなくてもよい。
ポータルサーバ41は、ユーザの認証が成功した場合、ポータルサイトのメインページを端末システム1に送信してディスプレイ16に表示させる。詳細は後述するが、メインページには、ユーザに対して提供する提供情報が含まれる。したがって、ユーザの認証が成功した場合、ポータルサーバ41は、ユーザに対して提供する提供情報を生成する処理を実行する(ステップS14~S18)。
提供情報の内容は、データサーバ2に記憶されている、ユーザの健康情報に基づいて決定される。そのため、ポータルサーバ41は、まず、提供情報を決定するために必要な健康情報を利用する要求(利用要求)をデータサーバ2に対して行う(ステップS14)。利用要求で要求される健康情報は、ポータルサーバ41に記憶されている提供条件テーブルを用いて決定される。
ここで、ポータルサーバ41に記憶されるデータについて説明する。図8は、ポータルサーバ41に記憶されるデータの一例を示す図である。図8に示すように、ポータルサーバ41は、ユーザ毎のユーザ情報、提供条件テーブル、および、追加提供条件テーブルを記憶している。まず、ステップS14の処理に関連するユーザ情報および提供条件テーブルについて説明し、追加提供条件テーブルの詳細については後述する。
ポータルサーバ41に記憶されるユーザ情報は、上述のユーザ識別情報、個人情報、およびユーザ提供履歴情報を含む。個人情報は、例えば、ユーザの名前、生年月日、年齢、および性別等、(生体情報を除く)ユーザ個人に関する情報である。ユーザ提供履歴情報は、ユーザに対してすでに提供された(提供済みの)提供情報の履歴を示す。ユーザ提供履歴情報の詳細は後述する。
提供条件テーブルは、上記ステップS14において、提供情報を生成するために必要な健康情報を決定するために用いられる。なお、提供条件テーブルは、予め設定されてポータルサーバ41に記憶されるが、提供条件テーブルの内容は適宜のタイミングで更新されてもよい。
図9は、提供条件テーブルの一例を示す図である。図9に示すように、提供条件テーブルは、提供条件と、提供内容とを関連付けたテーブルである。提供条件は、提供情報を提供する条件を示す。提供内容は、それに関連付けられる提供条件が満たされる場合に提供される提供情報の内容を示す。なお、図9においては、提供内容としては、例えば「商品Aの紹介」等、提供情報の内容自体を示す情報が設定されるものとしている。ただし、ポータルサーバ41において用意されている各提供情報にそれぞれ識別番号が付されている場合には、提供内容として、当該識別番号を示す情報が設定されてもよい。
図9に示すように、本実施形態においては、提供条件は、ユーザ条件と健康条件とを含む。ユーザ条件は、提供情報を提供するユーザに関する条件である。ユーザ条件としては、「40代男性」や「30代男女」のように、ユーザ情報に含まれる個人情報に関する条件が設定される。
健康条件は、提供情報を提供するユーザの健康(健康情報)に関する条件である。また、図9に示すように、健康条件には、健康条件の判定に利用される健康情報を示す利用情報が含まれる。利用情報は、図9に示す「(最近1週間の)平均疲労度」のように、データサーバ2に記憶される健康情報を加工した2次情報を示すものであってもよい。また、利用情報は、「(最近1週間の)疲労度」のように、健康情報自体(の種類)を示す情報であってもよい。つまり、利用要求は、健康情報を加工した2次情報を要求するものであってもよいし、健康情報自体を要求するものであってもよい。
健康条件としては、例えば、「(最近1週間の平均疲労度が)4以上」や、「(最近1週間の平均睡眠時間が)5時間以下」のように、疲労指標や睡眠指標に関する条件が設定される。健康条件は、健康情報自体(例えば疲労度)に関する条件であってもよいし、当該健康情報から得られる情報(例えば平均疲労度)に関する条件であってもよい。
また、健康条件は、1種類の健康情報に関する1つの条件で構成されるものに限らず、2種類以上の健康情報に関する複数の条件で構成されてもよい。例えば、健康条件は、疲労指標に関する条件と、睡眠指標に関する条件とから構成されてもよい。また、副端末装置20で得られた情報(生体情報および/または生体情報から算出される健康情報)が主端末装置10を介してデータサーバへ送信される場合、健康条件は、当該情報に関する条件を含んでいてもよい。
上記ステップS14において、ポータルサーバ41は、上記の提供条件テーブルを用いて、データサーバ2に要求する健康情報を決定する。すなわち、ポータルサーバ41は、提供条件テーブル内の提供条件を判定するために用いられる健康情報を特定し、特定された健康情報をデータサーバ2に要求する。具体的には、ポータルサーバ41は、提供条件テーブルに含まれる各提供条件のうちで、ユーザ条件が満たされる提供条件を特定し、当該提供条件に含まれる利用情報を特定する。例えば、図9に示す提供条件テーブルが用いられる場合において、ポータルサイトにログインしたユーザが40代の男性であった場合には、「最近1週間の平均疲労度」を示す利用情報が特定される。したがって、ポータルサーバ41は、「最近1週間の平均疲労度」を要求する利用要求をデータサーバ2へ送信する。なお、ユーザ条件が満たされる提供条件が複数種類あった場合には、ポータルサーバ41は、当該複数の提供条件に関連付けられる各利用情報を特定し、特定した利用情報が示す健康情報を要求する利用要求を送信する。
なお、他の実施形態においては、提供条件テーブル内の提供条件と提供内容との組は、複数のグループに分類されていてもよい。例えば、上記組は、提供情報の内容(紹介される商品・サービス)、提供情報で紹介される商品・サービスのジャンル、提供情報で紹介される商品・サービスを提供する事業者、および/または、提供情報で紹介される商品・サービスの金額等に応じて複数のグループに分類されていてもよい。このとき、ポータルサーバ41は、ユーザに予めグループを選択させておき、選択されたグループ内の組に含まれる提供条件のみについて、上記の利用情報を特定する処理を実行するようにしてもよい。例えば、上記組が商品・サービスのジャンル毎にグループに分類される場合において、睡眠を改善するためのグッズ(枕やアイマスク等)のジャンルと、疲労を解消するサプリメントのジャンルが設定されていてもよい。このとき、ユーザがサプリメントのジャンルのみを選択していた場合には、ポータルサーバ41は、提供条件テーブルのうち、このジャンルに含まれる提供条件を処理対象として、利用情報を特定する処理を実行してもよい。これによれば、ユーザが選択したジャンルに含まれる提供情報のみがユーザに提供されることになり、ユーザが興味を持っているジャンルについて効果的に提供情報を提供することができる。また、利用情報を特定する処理によるポータルサーバ41の処理負担を軽減することができる。
また、提供条件テーブルは、ユーザがどのような健康状態にあるときに、どのような商品・サービスを紹介するかを表すものである。そのため、サービス提供側(サービス提供サーバ42)が、提供条件テーブルの内容を変更することができるようにしてもよい。すなわち、ポータルサーバ41は、サービス提供サーバ42からの要求に応じて、提供条件テーブルの内容を変更してもよい。
以上のように、ポータルサーバ41からデータサーバ2へ送信される利用要求は、要求する健康情報を示す情報を含む。図10は、利用要求の一例を示す図である。図10に示すように、利用要求は、要求情報と、ユーザ識別情報と、サービス識別情報とを含む。要求情報は、取得を要求する健康情報を示す情報であり、上記特定された利用情報に基づいて決められる。本実施形態においては、要求情報は、取得を要求する健康情報の種類と、その健康情報が端末システム1において取得された時間(期間)とを含む。
ユーザ識別情報は、取得する健康情報に対応するユーザを示す。すなわち、利用要求に含まれるユーザ識別情報は、利用要求によってどのユーザの健康情報を取得するかを示している。
サービス識別情報は、サービス提供サーバによって提供される商品・サービスに対して付される識別情報である。サービス識別情報は、商品・サービスを提供するサービス事業者毎に設定されてもよいし、商品・サービスの種類毎に設定されてもよい。利用要求に含まれるサービス識別情報は、当該利用要求で要求される健康情報に対応する提供情報(提供条件テーブルにおいて当該健康情報を示す利用情報に関連付けられる提供内容)によって決められる。つまり、サービス識別情報は、提供情報に対応しているとも言える。本実施形態において、利用要求に含まれるサービス識別情報は、当該利用要求で要求される健康情報に対応する提供情報によって紹介される商品・サービスに対して付されたサービス識別情報、あるいは、当該商品・サービスを提供するサービス事業者に対して付されたサービス識別情報である。
なお、ポータルサーバ41は、提供条件テーブルに含まれる提供内容(あるいは、提供内容によって特定される商品・サービス、または、サービス事業者)に対してサービス識別情報を関連付けたテーブルを予め記憶している。ポータルサーバ41は、このテーブルを参照して、利用要求に含めるべきサービス識別情報を特定する。
利用要求を受信すると、データサーバ2は、利用要求に対する認証処理を行う(ステップS15)。この認証処理は、利用要求に含まれる要求情報が示す健康情報が、当該利用要求に含まれるサービス識別情報が示すサービスにおいて利用可能か(換言すれば、提供情報の生成のために利用可能か)否かを判定する処理である。本実施形態において、上記認証処理は、データサーバ2に記憶されている利用管理テーブル(図7参照)を用いて行われる。
図11は、利用管理テーブルの一例を示す図である。図11に示すように、利用管理テーブルは、サービス識別情報と、利用可能情報とを関連付けたテーブルである。利用可能情報は、データサーバ2に記憶される健康情報および2次情報のうち、当該利用可能情報に関連付けられるサービス識別情報が示す商品・サービスのために利用可能な(利用が許可される)情報を示す。利用可能情報は、例えば、「睡眠指標・疲労指標」、「全情報」、あるいは「睡眠指標」のように、健康情報の種類を示すものであってもよい。また、利用可能情報は、「最近1月の睡眠指標」のように、時系列で記憶される健康情報のうちで利用可能な健康情報の期間(換言すれば、健康情報が取得された時期)を示すものであってもよい。また、図11には示していないが、利用可能情報は、例えば、「2013年12月1日から2014年12月1日まで利用可能」のように、サービスサーバ3が健康情報を利用することができる期間を示すものであってもよい。つまり、利用管理テーブルの利用可能情報は、健康情報の種類に関する条件を示すものであってもよいし、健康情報の取得時期に関する条件を示すものであってもよいし、健康情報の利用期間(利用可能期間)に関する条件を示すものであってもよい。図11に示す例においては、商品Aに対応するサービス識別情報には、睡眠指標と疲労指標とが利用可能であることを示す利用可能情報が関連付けられた組が含まれる。この組は、商品Aを紹介する提供情報のために、睡眠指標および疲労指標が利用可能であることを表している。
ステップS15の認証処理において、データサーバ2は、受信した利用要求に含まれる要求情報が示す健康情報と、当該利用要求に含まれるサービス識別情報に対して(利用管理テーブルにおいて)関連付けられている利用可能情報が示す健康情報と一致するか否かを判定する。両者が一致する場合、データサーバ2は、認証成功と判断し、後述するステップS16およびS17の処理を実行する(図6参照)。一方、図示しないが、両者が一致しない場合、データサーバ2は、認証失敗と判断し、ステップS16およびS17の処理を実行しない。この場合、データサーバ2は、認証が失敗した旨の通知をポータルサーバ41へ送信する。この場合、ポータルサーバ41は、提供情報を生成せず、後述のS19においてユーザには提供情報が提供されない(提供情報を含まないメインページが提供される)。
認証が成功した場合、ポータルサーバ41は、利用要求に応じた分析処理を実行する(ステップS16)。上述のように、利用要求で要求される健康情報は、例えば「最近1週間の平均疲労度」のように、データサーバ2に記憶される健康情報を分析(加工)した結果得られる情報であることがある。このような場合、ポータルサーバ41は、健康情報を分析する処理によって、利用要求で要求される健康情報を算出する。例えば、最近1週間の平均疲労度が要求される場合には、利用要求に含まれるユーザ識別情報が示すユーザの健康情報のうちで、最近1週間の疲労度から平均値が算出される。なお、利用要求で要求される健康情報が、端末システム1から取得された健康情報自体である場合、または、上記ステップS12の分析処理によってすでに算出された2次情報である場合、ステップS16では分析処理が実行されなくてもよい。
次に、データサーバ2は、利用要求で要求された健康情報をポータルサーバ41へ送信する(ステップS17)。これによって、ポータルサーバ41は健康情報を取得することができる。
以上のように、本実施形態においては、サービスサーバ3は、提供情報を生成する場合、当該提供情報の生成に用いる情報の要求(利用要求)をデータサーバ2に対して行う。そして、データサーバ2は、サービスサーバ3からの要求に応じて、記憶されている情報(生体情報および/または健康情報)をサービスサーバへ送信する。これによれば、ユーザから取得した情報をデータサーバ2において管理するとともに、データサーバ2において記憶される情報をサービスサーバ3において利用することができる。
さらに、本実施形態においては、上記利用要求は、提供情報の生成に用いる情報を示す要求情報と、データサーバ2に記憶される情報の利用に関する識別情報(サービス識別情報)とを含む。データサーバ2は、サービスサーバ3からの利用要求に含まれる識別情報に基づいて、当該要求に含まれる要求情報が示す情報を提供情報の生成のために利用が許可されるか否かを判定し、許可されると判定される場合、要求情報が示す情報をサービスサーバへ送信する。これによれば、データサーバ2は、サービスサーバ3による蓄積情報の利用を管理・制御することができ、サービス識別情報に応じて利用可能な情報の種類を異なるように管理・制御することができる。
データサーバ2から健康情報を受信すると、ポータルサーバ41は、受信した健康情報に基づいて提供情報を生成する(ステップS18)。すなわち、ポータルサーバ41は、受信した健康情報を用いて、上記提供条件テーブルにおいて提供条件(ユーザ条件および健康条件)が満たされる提供情報を特定する。例えば、図9に示す提供条件テーブルが用いられる場合において、40代男性のユーザについて最近1週間の平均疲労度として4以上の値が受信された場合、商品Aを紹介する提供情報が特定される。なお、提供条件が満たされる提供内容がなかった場合、提供情報は生成されず、提供情報は送信されない。また、ステップS18の処理において特定される提供情報は、複数であってもよい。
なお、上記ステップS18の処理において、ポータルサーバ41は、特定した提供情報についての履歴を記憶する。すなわち、ポータルサーバ41は、ログインしたユーザについてのユーザ情報に含まれるユーザ提供履歴情報(図8参照)の内容を更新する。
図12は、ユーザ提供履歴情報の一例を示す図である。本実施形態において、ユーザ提供履歴情報は、提供内容情報と、提供日情報と、購入情報と、追加提供タイミング情報とからなる組の情報を含む。ユーザ提供履歴情報に含まれる提供内容情報は、上述の提供条件テーブルにおける提供内容と同様、ユーザに提供された提供情報の内容を示す。提供日情報は、それに関連付けられる提供情報が提供された時点(ここでは年月日)を示す。なお、本実施形態においては年月日を示す提供日情報が記憶されるが、年月日に加えて時刻を示す情報が記憶されてもよい。
また、購入情報は、それに関連付けられる提供情報が紹介する商品・サービスの購入の有無を示す。また、追加提供タイミング情報は、それに関連付けられる提供情報の提供後に、提供情報の追加提供を行うか否か、および、追加提供を行う場合には追加提供を行うタイミングを示す。追加提供タイミング情報については後述する。
上記ステップS18の処理においては、ポータルサーバ41は、特定した提供情報について、上記の組の情報をユーザ提供履歴情報に追加する。具体的には、ポータルサーバ41は、ステップS18の処理において特定した提供情報を示す提供内容情報と、当該提供情報を提供する年月日を示す提供日情報と、購入無しを示す購入情報と、追加提供無しを示す追加提供タイミング情報とをユーザ提供履歴情報に追加する。なお、ステップS18の処理では、購入情報は「購入無し」、追加提供タイミング情報は「追加提供無し」を示すように記憶されるが、後述するように、これらの情報は商品等の購入があった場合に更新される。
次に、ポータルサーバ41は、特定した提供情報を含むウェブページを作成して端末システム1へ送信する(ステップS19)。本実施形態においては、このウェブページは、端末システム1がポータルサイトにアクセス(ログイン)して最初に表示されるメインページ(トップページまたはホームページとも言う)である。ただし、他の実施形態においては、提供情報を含むページはメインページでなくてもよい。上記メインページが端末システム1で受信されると、主端末装置10のディスプレイ16においてメインページが表示される。これによって、ユーザに対して提供情報が提供されたことになる。
図13は、端末システムにおいて表示されるメインページの一例を示す図である。図13に示すように、メインページは、提供情報欄51と、履歴閲覧欄52とを含む。提供情報欄51には、提供情報(図13では、商品として枕を紹介する情報)が表示される。本実施形態においては、提供情報欄51内に表示される内容が提供情報によって規定される。なお、図13においては、提供情報欄51には1種類の提供情報のみが含まれるが、複数の提供情報が含まれていてもよい。
提供情報欄51は、提供情報に係る商品を購入するための購入ボタン53を含む。すなわち、ユーザが購入ボタン53を指定する入力を行うと、商品を購入するための商品購入ページがディスプレイ16に新たに表示され、ユーザは商品を購入することができる。本実施形態においては、商品購入ページは、ポータルサーバ41によって提供されるページ(ポータルサイト内のページ)であるとする。ただし、他の実施形態においては、サービス提供サーバによって提供されるページ(ポータルサイト外のページ)であってもよい。つまり、上記購入ボタン53は、サービス提供サーバによって提供される商品購入ページへのリンクを示すものであってもよい。
履歴閲覧欄52は、データサーバ2に記憶されている健康情報の履歴を参照するために設けられる。本実施形態においては、履歴閲覧欄52は、年月を示すボタンを含んでおり、ユーザがこのボタンを指定する入力を行うことで、指定された年月の健康情報を表示するページがディスプレイ16に表示される。
上記のように、本実施形態においては、サービスサーバ3は、ユーザの健康情報が示す指標を改善するための商品またはサービスに関する情報を含む提供情報を生成する。これによって、商品・サービスに関する有用な情報をユーザに提供することができる。また、サービスサーバ3は、商品・サービスをユーザが購入するためのウェブページの情報、または、当該ウェブページのリンク情報を含む提供情報を生成する。これによれば、ユーザは、商品・サービスを紹介する提供情報が提供された場合に、提供された商品・サービスを簡単な操作で購入することができ、ユーザの利便性を向上することができる。
<3>商品の購入に関する処理
次に、メインページで表示された提供情報が示す商品をユーザが購入した場合における処理を説明する。上記商品購入ページにおいてユーザが商品を購入する操作入力を行うと、端末システム1は、購入指示の通知をポータルサーバ41へ送信する(ステップS20)。この購入指示の通知は、ユーザ識別情報と、購入する商品を識別する情報とを含んでいる。購入指示の通知を受信すると、ポータルサーバ41は、購入に係る商品を提供するサービス提供サーバ42へ購入通知を送信する(ステップS21)。購入通知は、上記購入指示の通知に含まれていた、ユーザ識別情報と、購入する商品を識別する情報とを含んでいる。
ポータルサーバ41から購入通知を受信すると、サービス提供サーバ42は、商品・サービスの提供に関する提供処理を実行する(ステップS22)。例えば、ネットワークを介してデータを商品・サービスとして提供する場合、上記提供処理は、例えば当該商品またはサービスに係るデータを送信する処理である。なお、「商品またはサービスに係るデータ」とは、例えば音楽データや食事のレシピ、アプリケーションのデータ等である。「商品またはサービスに係るデータ」は、例えば、主端末装置10の照明部17に、ユーザの入眠あるいは起床を誘導する照明を行わせるためのデータ(アプリケーション)であってもよい。端末システム1がスピーカを備える場合には、ユーザの入眠あるいは起床を誘導する音楽を当該スピーカから出力させるためのデータ(アプリケーション)であってもよい。
また、実際の物である商品(例えば、枕やアイマスク等の睡眠改善グッズ)を提供する場合には、提供処理は、例えば、商品の購入受け付けた旨の通知をユーザの端末システム1へ送信する処理や、商品を配送する通知をユーザの端末システム1へ送信する処理である。また、実際にサービス(例えば、マッサージ等)を提供する場合には、提供処理とは、サービスの購入を受け付けた旨の通知をユーザの端末システム1へ送信する処理や、サービスを提供する日時の通知をユーザの端末システム1へ送信する処理である。例えば、サービスサーバ3は、提供情報によってマッサージサービスを紹介し(例えば、ユーザの周辺のマッサージ店を紹介する)、ポータルサイト上でマッサージの予約(マッサージサービスの購入)を行うようにしてもよい。
上記のように、サービスサーバ3は、商品またはサービスをユーザが購入する指示が端末システム1からあったことに応じて、当該商品またはサービスに係るデータを当該端末システム1へ送信してもよい。
また、購入指示の通知を受信すると、ポータルサーバ41は、商品が購入されたことを反映するように、購入指示を行ったユーザに関するユーザ提供履歴情報(図12)を更新する(ステップS23)。具体的には、ポータルサーバ41は、購入指示に係る商品を紹介する提供情報に関連付けられる購入情報を「購入有り」を示す内容に更新する。また、ポータルサーバ41は、当該提供情報に関連付けられる追加提供タイミング情報を、追加の提供情報を提供するタイミングを示す内容に更新する。
ここで、本実施形態においては提供情報で紹介された商品・サービスが購入された場合、購入後において新たな提供情報が提供される。以下では、このように新たに追加して提供される提供情報を「追加提供情報」と呼ぶ。追加提供情報の内容は、最初の提供情報の内容とは異なる内容であってもよいし、同じ内容であってもよい。詳細は後述するが、追加提供情報の内容は、商品・サービスが購入された後でアップロードされたユーザの健康情報に基づいて決定される。
上記ステップS23では、追加提供情報の提供タイミングが決定され、ユーザ提供履歴情報内の追加提供タイミング情報は、決定されたタイミングを示す内容に更新される。ポータルサーバ41は、提供された提供情報に応じて追加提供情報の提供タイミングを決定する。本実施形態においては、追加提供情報の提供タイミングは、ポータルサーバ41に記憶されている追加提供条件テーブル(図8参照)を用いて決定される。
図14は、追加提供条件テーブルの一例を示す図である。追加提供条件テーブルは、追加提供情報の内容およびタイミングを決定するためのテーブルである。図14に示すように、追加提供条件テーブルは、前回提供内容と、追加提供タイミングと、追加提供条件と、追加提供内容とを関連付けたテーブルである。追加提供条件テーブルは、提供条件テーブルと同様、予め設定されてポータルサーバ41に記憶されるが、追加提供条件テーブルの内容が適宜のタイミングで更新されてもよい。また、提供条件テーブルと同様、サービス提供側(サービス提供サーバ42)が、追加提供条件テーブルの内容を変更することができるようにしてもよい。
前回提供内容は、前回に提供された提供情報の内容であり、換言すれば、追加提供情報が提供される起因となった提供情報の内容である。追加提供タイミングは、追加提供のタイミング、すなわち、追加提供タイミングに関連付けられる追加提供情報を提供するタイミングを示す。本実施形態においては、追加提供タイミングは、例えば、「購入後2週間」や「購入後1月」のように、商品・サービスが購入されてからの時間を示す。ただし、他の実施形態においては、追加提供タイミングは、前回に提供情報が提供された時点からの時間を示してもよいし、商品を実際に使用した時点やサービスを実際に受けた時点がポータルサーバ41に取得される場合には、これらの時点からの時間を示してもよい。なお、追加提供条件および追加提供内容の詳細については後述する。
ステップS23においては、ポータルサーバ41は、購入された商品を紹介する提供情報を特定し、特定された提供情報を示す前回提供内容に(追加提供条件テーブルにおいて)関連付けられる追加提供タイミングを特定する。ポータルサーバ41は、特定された追加提供タイミングに基づいて、追加提供を行う時点(ここでは年月日)を算出する。ユーザ提供履歴情報内の追加提供タイミング情報は、算出された年月日の情報に更新される。例えば、現在(購入時点)が2013年12月6日であり、特定された追加提供タイミングが「購入後2週間」であった場合、2013年12月20日を示す情報が追加提供タイミング情報として記憶される。
<4>商品・サービスの購入後に追加提供情報が提供される処理
以上のように、本実施形態においては、商品・サービスが購入された場合、購入された商品・サービスを紹介する提供情報に基づいて、追加提供情報を提供するタイミングが決定される。ここで、ポータルサーバ41は、各ユーザのユーザ提供履歴情報を定期的に参照することによって、追加提供タイミングが到来したか否かを定期的に判定する。そして、追加提供タイミングが到来したと判定された場合、ポータルサーバ41は、追加提供タイミングが到来した追加提供情報をユーザに提供するための処理(図6に示すS24~S29)を実行する。つまり、商品の購入から所定期間(追加提供条件テーブルにおける追加提供タイミングによって特定される期間)が経過すると、上記処理が実行される(図6参照)。
具体的には、提供タイミングが到来した追加提供情報がある場合、ポータルサーバ41は、追加提供情報を決定するために必要な健康情報の利用を要求する利用要求をデータサーバ2へ送信する(ステップS24)。なお、追加提供情報を決定するために必要な健康情報とは、追加提供情報の追加提供条件(図14参照)を判定するために用いられる健康情報である。ステップS24の処理においては、追加提供情報を決定するために必要な健康情報は、ポータルサーバ41に記憶されている追加提供条件テーブルを用いて決定される。
ここで、図14に示すように、追加提供条件テーブルにおいては、前回提供内容と、(追加提供タイミングと、)追加提供条件と、追加提供内容とが関連付けられる。追加提供条件は、それに関連付けられる前回提供内容が示す提供情報について、追加提供情報が提供される条件(追加提供条件)を示す。
追加提供条件は、追加提供条件の判定に利用される健康情報を示す利用情報を含む。この利用情報は、上記提供条件に含まれる利用情報と同様である。ただし、追加提供条件に含まれる利用情報は、例えば、「最近1週間の平均疲労度と、購入前1週間の平均疲労度」のように、商品・サービスの購入前および購入後の両方の健康情報を指定するように設定される場合がある。
追加提供条件は、ユーザの健康情報に関する条件である。具体的には、追加提供条件は、「疲労度が改善」や「疲労度の改善無し」のように、健康情報の変化(健康情報が示すユーザの状態の変化)に関する条件であってもよい。また、追加提供条件は、上述した健康条件(図9参照)と同様であってもよく、例えば「最近1週間の平均睡眠時間が5時間以下」のように、健康情報が示すユーザの状態に関する条件が追加提供条件として設定されてもよい。
追加提供内容は、それに関連付けられる追加提供条件が満たされる場合に提供される追加提供情報の内容を示す。追加提供条件テーブルに含まれる追加提供内容としては、上述の提供条件テーブルにおける提供内容と同様、提供情報の内容自体を示す情報が設定されてもよいし、提供情報に付される識別番号を示す情報が設定されてもよい。
上記ステップS24において、まず、ポータルサーバ41は、ユーザ提供履歴情報を参照して、提供タイミングが到来した追加提供情報に対応する提供情報を特定する。すなわち、ポータルサーバ41は、ユーザ提供履歴情報において、提供タイミングが到来した追加提供タイミング情報に関連付けられる提供内容情報が示す提供情報を特定する。
次に、ポータルサーバ41は、上記特定された提供情報に対応する追加提供情報の追加提供条件を特定する。すなわち、ポータルサーバ41は、追加提供条件テーブルを参照して、上記特定された提供情報を示す前回提供内容に関連付けられる追加提供条件を特定する。そして、ポータルサーバ41は、特定された追加提供条件に含まれる利用情報を特定し、特定された利用情報が示す健康情報を取得する利用要求をデータサーバ2へ送信する。すなわち、当該健康情報を示す要求情報を含む利用要求がデータサーバ2へ送信される。例えば、図14に示す追加提供条件テーブルが用いられる場合において、「商品Aの紹介」を示す提供情報が特定された場合を考える。この場合、「最近1週間の平均疲労度、購入前1週間の平均疲労度」を示す利用情報が特定されるので、この利用情報が示す健康情報を取得する利用要求をデータサーバ2へ送信する。
なお、ステップS24で送信される利用要求は、上記ステップS14で送信される利用要求と同様、要求情報と、ユーザ識別情報と、サービス識別情報とを含む。これら3つの情報の内容は、上記ステップS14の処理と同様の方法で決定される。なお、例えば、「最近1週間の平均疲労度と、購入前1週間の平均疲労度」を示す利用情報が特定される場合のように、要求情報が、購入時点を基準とした所定期間における健康情報を示す場合がある。この場合、ポータルサーバ41は、上記所定期間を算出するために、ユーザ提供履歴情報の提供日情報が示す日を購入日として用いてもよいし、商品購入時の日付を予め記憶しておき、記憶しておいた日付を購入日として用いてもよい。
ポータルサーバ41からの利用要求に応じて、データサーバ2は、上記ステップS15~S17と同様の処理を実行する。すなわち、データサーバ2は、利用要求に対する認証処理を行い(S25)、認証が成功した場合には、利用要求に応じた分析処理を、必要に応じて実行する(ステップS26)。そして、利用要求で要求された健康情報をポータルサーバ41へ送信する(ステップS27)。
データサーバ2から健康情報を受信すると、ポータルサーバ41は、受信した健康情報に基づいて追加提供情報を生成する(ステップS28)。すなわち、ポータルサーバ41は、受信した健康情報を用いて、上記ステップS24で特定された追加提供条件が満たされるか否かを判定する。そして、ポータルサーバ41は、追加提供条件が満たされる追加提供内容の追加提供情報を生成する。なお、追加提供条件が満たされる追加提供内容がなかった場合、追加提供情報は生成されない。また、ステップS28の処理において特定される追加提供情報は、複数であってもよい。
図15は、追加提供条件の判定方法の一例を示す図である。図15に示すように、本実施形態においては、毎日取得された健康情報(図では疲労度)がデータサーバ2に記憶されている。上述のように、本実施形態においては、追加提供条件が満たされるか否かは、商品・サービスの購入前後の健康情報を比較することによって判定される場合がある。この場合には、まず、購入後におけるユーザの健康情報として、現在から過去の所定期間における健康情報が分析されるとともに、購入前におけるユーザの健康情報として、購入時から過去の所定期間における健康情報が分析される。例えば、図15に示すように、データサーバ2は、ポータルサーバ41からの利用要求に応じて、最近1週間の疲労度の平均と、購入前1週間の疲労度の平均とを分析結果として算出する。ポータルサーバ41は、購入前における健康情報の分析結果(購入前1週間の平均疲労度)と、購入後における健康情報の分析結果(最近1週間の平均疲労度)とを比較することで、ユーザの健康状態が改善されたか否かを判定する。例えば、平均疲労度が所定値以上低減していれば、ポータルサーバ41は、ユーザの健康状態(疲労度)が改善されたと判定し、平均疲労度が所定値よりも低減していなければ、ポータルサーバ41は、ユーザの健康状態(疲労度)が改善されなかったと判定する。そして、ポータルサーバ41は、判定結果に応じて異なる内容の追加提供情報を生成する。例えば、図14に示す追加提供条件テーブルの例においては、最近1週間の平均疲労度と、購入前1週間の平均疲労度とに基づいて、疲労度が改善されたと判定されれば、商品Dを紹介する追加提供情報が生成される。また、疲労度が改善されなかったと判定されれば、商品Eを紹介する追加提供情報が生成される。
上記のように、本実施形態においては、健康状態を分析するユーザについて蓄積された時系列データである複数の健康情報に基づいて分析(健康情報が取得された時間を考慮した時系列分析)が行われる。これによって、ユーザの健康状態の変化を知ることができるので、このような分析に基づいた提供情報を提供することによって、有用な情報を提供することができる。
また、本実施形態においては、提供情報に含まれる商品またはサービスが購入された後で端末システムが取得した健康情報に基づく、当該商品またはサービスによる(健康状態の)改善効果に応じた追加提供情報を生成する。これによれば、商品・サービスによる効果を判断することができるとともに、判断結果に応じて適切な提供情報を提供することができる。
上記のように、本実施形態においては、データサーバ2は、所定の基準時点(購入時点)の以前に端末システム1が取得した情報に基づく健康状態と、当該基準時点より後に端末システム1が取得した情報に基づく健康状態とを比較することによって分析を行う。これによれば、提供情報(または、提供情報で提供された商品・サービス)による健康状態の変化を精度良く分析することができ、かかる分析に応じた提供情報を生成することで、提供内容を有用なものにすることができる。
なお、上記所定の基準時点は、例えば提供情報で紹介された商品・サービスの購入時点であるが、提供情報がユーザに提供されたことに起因する任意の時点でよい。例えば、基準時点は、提供情報が提供された時点であってもよい。また例えば、ユーザが商品の使用を開始した時点、および/または、ユーザがサービスの提供を受けた時点をサーバ側で知ることができる場合には、これらの時点が基準時点となってもよい。
追加提供情報が生成されると、ポータルサーバ41は、追加提供情報を端末システム1へ送信する(ステップS29)。追加提供情報を送信する方法は任意であるが、本実施形態においては、追加提供情報がある旨のメッセージがプッシュ通知で端末システム1へ送信される。すなわち、ポータルサーバ41は、追加提供情報が生成されると、ユーザによる操作が行われなくても(ポータルサイトにアクセスしなくても)メッセージが通知される方法で、メッセージを送信する。すなわち、上記メッセージを受けた端末システム1は、ユーザによる操作とは独立してメッセージをディスプレイ16に表示する。このメッセージに応じて、ユーザは、端末システム1を用いてポータルサイトにアクセスする。そして、ユーザがポータルサイトにログインすると、ポータルサーバ41は、追加提供情報が含まれるメインページを生成して端末システム1へ送信する。これによって、追加提供情報がユーザに対して提供されたことになる。
上記のように、サービスサーバ3は、追加提供情報が生成されたことに応じて、ユーザの端末(端末システム1における端末装置(主端末装置10))へ、当該端末装置に対するユーザの操作とは独立したタイミングで、追加提供情報の通知(上記メッセージ)を送信する。なお、他の実施形態においては、追加提供情報自体がプッシュ通知で端末システム1へ送信されてもよい。すなわち、ユーザによる操作とは独立して追加提供情報がポータルサーバ41から端末システム1へ送信されてもよい。換言すれば、追加提供情報は、ポータルサイトへのアクセス無しに端末システム1において表示されるようにしてもよい。このように、追加提供情報の通知または追加提供情報がプッシュ通知で端末システム1へ送信されることによって、追加提供情報が生成されたことを適切なタイミングでユーザに通知することができる。
また、他の実施形態においては、上記のメッセージは送信されなくてもよい。この場合、ポータルサーバ41で追加提供情報が生成された時点ではユーザに通知されず、ユーザが次にポータルサイトへアクセスした際に追加提供情報が提供されることになる。
なお、他の実施形態においては、(追加提供情報ではない)提供情報についても追加提供情報と同様、プッシュ通知が行われてもよい。すなわち、サービスサーバ3は、端末装置に対するユーザの操作とは独立したタイミングで、(追加提供情報ではない)提供情報の通知、または、提供情報自体を送信してもよい。より具体的には、ポータルサーバ41は、所定の条件が満たされたことに応じて(例えば、所定の時刻となったことに応じて)、ステップS14およびS18の処理を実行するようにしてもよい。
以上のようにして、本実施形態においては、提供情報が提供された後に追加提供情報が提供される。ここで、提供情報が提供された後において、端末システム1からの情報(健康情報)の分析処理と、分析結果に基づく追加提供情報の生成処理とが繰り返し実行されてもよい。例えば、ポータルサーバ41は、追加提供条件テーブル(図14参照)における追加提供タイミングとして、繰り返し到来するようなタイミング(例えば、商品の購入後2週間毎のタイミング)を設定してもよい。これによれば、上記の分析処理と生成処理が、当該タイミングが到来する毎に繰り返し実行されることになる。また例えば、ポータルサーバ41は、追加提供条件テーブルにおける追加提供内容で示される提供情報を前回提供内容として含む組(前回提供内容と、追加提供タイミングと、追加提供条件と、追加提供内容との組)を設定してもよい。例えば、図14に示す追加提供条件テーブルにおいて、商品Dを紹介する提供情報が前回提供内容として設定される組が設定されてもよい。これによれば、追加提供情報の提供に応じて商品Dをユーザが購入した場合、その後にさらなる追加提供情報が提供されることになる。以上のように、分析処理と生成処理とが繰り返されることによって、有用な情報を継続的にユーザに提供することができる。
(データサーバ2における処理)
図16は、データサーバ2において実行される処理の流れの一例を示すフローチャートである。本実施形態において、データサーバ2は、図16に示すステップS30~S37の一連の処理を繰り返し実行する。この一連の処理は、データサーバ2が有する処理部であるCPUが、データサーバ2が有するプログラム記憶部に記憶される所定の情報処理プログラムを実行することによって行われる。なお、データサーバ2が複数の情報処理装置によって構成される場合には、各情報処理装置のCPUが分担して上記一連の処理を実行するようにしてもよい。
まずステップS30において、データサーバ2の処理部は、端末システム1から健康情報を受信したか否かを判定する(図6に示すS11参照)。ステップS30の判定結果が肯定である場合、ステップS31の処理が実行され、ステップS30の判定結果が否定である場合、後述するステップS34の処理が実行される。
ステップS31において、処理部は、端末システム1から受信した健康情報を、データサーバ2が有する記憶部にユーザ毎に記憶する(図7参照)。ステップS32において、処理部は、受信した健康情報に基づいて2次情報を算出するか否かを判定する。この判定は、例えば、2次情報を算出するタイミングが到来したか否か、あるいは、2次情報を算出するための健康情報が蓄積されたか否か等によって行われる。ステップS32の判定結果が肯定である場合、ステップS33の処理が実行され、ステップS32の判定結果が否定である場合、後述するステップS34の処理が実行される。
ステップS33において、処理部は、受信した健康情報に基づいて2次情報を算出し、データサーバ2が有する記憶部に、算出した2次情報を記憶する(図6に示すS12参照)。以上のように、データサーバ2は、複数のユーザのいずれかから健康情報を受信する度に健康情報を記憶し(ステップS31)、必要に応じて2次情報を算出して記憶する。
ステップS34において、処理部は、ポータルサーバ41から利用要求を受信したか否かを判定する(図6に示すS14,S24参照)。ステップS34の判定結果が肯定である場合、ステップS35の処理が実行され、ステップS34の判定結果が否定である場合、上記ステップS30の処理が再度実行される。
ステップS35において、処理部は、ステップS34で受信した利用要求に対する認証処理を実行し(図6に示すS15,S25参照)、認証が成功したか否かを判定する。ステップS35の判定結果が肯定である場合、ステップS36の処理が実行され、ステップS35の判定結果が否定である場合、ステップS37の処理が実行される。
ステップS36において、処理部は、利用要求で要求された健康情報をポータルサーバ41へ送信する。すなわち、処理部は、記憶部に記憶されている健康情報に対して必要に応じて分析を行い、当該健康情報および/または分析結果である健康情報をポータルサーバ41へ送信する(図6に示すS16,S17,S26,S27参照)。
一方、ステップS37において、処理部は、認証が失敗した旨の通知をポータルサーバ41へ送信する。上記ステップS36またはS37の処理が完了すると、上記ステップS30の処理が再度実行される。以上に示したS30~S37の処理によって、図6に示すデータサーバ2における動作が実現される。
(ポータルサーバ41における処理)
図17は、ポータルサーバ41において実行される処理の流れの一例を示すフローチャートである。ポータルサーバ41は、図17に示すステップS41~S49の一連の処理を繰り返し実行する。この一連の処理は、ポータルサーバ41が有する処理部であるCPUが、ポータルサーバ41が有するプログラム記憶部に記憶される所定の情報処理プログラムを実行することによって行われる。なお、ポータルサーバ41が複数の情報処理装置によって構成される場合には、各情報処理装置のCPUが分担して上記一連の処理を実行するようにしてもよい。
まずステップS41において、ポータルサーバ41の処理部は、端末システム1からのアクセスがあり、端末システム1のユーザによるログインが行われたか否かを判定する(図6に示すS13)。ステップS41の判定結果が肯定である場合、ステップS42の処理が実行され、ステップS41の判定結果が否定である場合、後述するステップS44の処理が実行される。
ステップS42において、処理部は提供情報を生成する(図6に示すS14,S18参照)。ステップS43において、処理部は、提供情報を含むメインページを生成して端末システム1へ送信する(図6に示すS19参照)。なお、このとき、すでに生成されている追加提供情報であってまだ提供していない追加提供情報がある場合、処理部は、提供情報に加えて追加提供情報を含むメインページを生成する。なお、提供情報と追加提供情報とは、互いに区別可能な態様で(例えば、ページにおける表示位置、および/または、表示形態が異なるように)提供される。また、図示しないが、端末システム1においてメインページが表示されてから、ユーザがポータルサイトをログアウトするまでの期間においては、ユーザによる入力に応じてウェブページ(例えば健康情報の履歴が示すページ)を端末システム1に表示させる処理が適時実行される。
ステップS44において、処理部は、ポータルサイトにおいて提供情報で紹介された商品が購入されたか否かを判定する。この判定は、購入指示の通知を端末システム1から受信したか否かによって行われる。ステップS44の判定結果が肯定である場合、ステップS45の処理が実行され、ステップS44の判定結果が否定である場合、後述するステップS47の処理が実行される。
ステップS45において、処理部は、サービス提供サーバ42へ購入通知を送信する(図6に示すS21参照)。また、ステップS46において、処理部は、商品の購入が行われたことを反映するように、ユーザ提供履歴情報を更新する(図6に示すS23参照)。上述したように、このとき、追加提供情報の提供タイミングが決定される。
ステップS47において、処理部は、追加提供情報の提供タイミングが到来したか否かを判定する(図6に示すS24参照)。ステップS47の判定結果が肯定である場合、ステップS48の処理が実行され、ステップS47の判定結果が否定である場合、上記ステップS41の処理が再度実行される。
ステップS48において、処理部は、提供タイミングが到来した追加提供情報を生成する(図6に示すS28参照)。ステップS49において、処理部は、追加提供情報があることをユーザに通知するための上記メッセージを端末システム1へ送信する(図6に示すS29参照)。このメッセージが端末システム1において表示されたことに応じてユーザがポータルサイトへログインすると、上述のステップS43の処理によってポータルサーバ41から追加提供情報を含むメインページが端末システム1へ送信され、当該メインページが端末システム1において表示されることになる。ステップS49の処理が完了すると、上記ステップS41の処理が再度実行される。以上に示したS41~S49の処理によって、図6に示すポータルサーバ41における動作が実現される。
[5.本実施形態における作用効果]
以上のように、本実施形態においては、端末システム1は、健康情報をサーバシステム(サーバ側のシステム。上記実施形態では、データサーバ2およびサービスサーバ3)へ送信する。また、サーバシステムは、端末システム1からの送信情報(健康情報)を受信し、受信した送信情報をユーザと関連付けて記憶する。
ここで、サーバシステムは、上記送信情報から得られる指標または送信情報に含まれる指標(ユーザに関する健康情報が示す指標、具体的には、睡眠指標、疲労指標)を改善するために当該ユーザに提供する提供情報を送信情報の分析結果に基づいて生成し、端末システム1へ送信する(S18,S19)。また、サーバシステムは、提供情報がユーザに提供された後で端末システム1が取得した送信情報の分析結果に基づいて、提供済みの提供情報とは異なる追加の提供情報を生成して端末システム1へ送信する(S28,S29)。
上記によれば、1回目に提供情報が提供され、その後で取得された健康情報に基づいてユーザ状態が分析され、分析結果に基づいて新たな提供情報が生成される。これによれば、1回目の提供情報による効果(効果の有無を含む)を考慮して2回目の提供情報を提供することができるので、有用な情報をユーザに提供することができる。例えば、1回目の提供情報で紹介した商品・サービスが購入された場合に、購入後の健康情報に基づいて商品・サービスの効果を判断し、効果に応じた2回目の提供情報を提供することができるので、有用な情報をユーザに提供することができる。
また、本実施形態においては、サーバシステム(データサーバ2)は、端末システムから受信した送信情報および当該送信情報から得られる情報(健康情報)をユーザと関連付けて記憶情報として記憶する(本実施形態では、蓄積する)。そして、データサーバ2は、記憶情報を用いて端末システムのユーザに対して提供情報を提供するサービスサーバ3から、記憶情報を提供情報の生成のために利用する要求(利用要求)として、提供情報の生成に用いる情報を示す要求情報と、当該提供情報に関するサービスを識別するためのサービス識別情報とを含む利用要求を受信する(S14、S24、図10)。データサーバ2は、サービスサーバ3から受信された利用要求に含まれるサービス識別情報に基づいて、当該利用要求に含まれる利用情報が示す情報を提供情報の生成のために利用することが許可されるか否かを判定し(S15,S25)、許可されると判定される場合、記憶情報に基づく情報であって要求情報が示す情報をサービスサーバ3へ送信する。
上記によれば、サーバシステムは、サービスサーバによる記憶情報の利用を管理・制御することができる。例えば、サーバシステムは、サービス識別情報に応じて利用可能な情報の種類ごとに記憶情報の利用を管理・制御することも可能である。このように、記憶情報の利用を管理・制御することによって、サーバシステムは、サービスサーバに記憶情報を利用させ、利用に応じた対価を請求するサービスを提供することができる。例えば、上記実施形態においては、データサーバ2およびポータルサーバ41を管理する管理事業者は、サービス提供サーバ42を管理するサービス事業者に対して記憶情報を利用させるサービスを提供することができる。
また、サーバシステムは、サービス識別情報と、記憶情報に基づく情報であって当該サービス識別情報が示すサービスのために利用が許可される情報を示す利用許可情報(利用可能情報)とを関連付けた関連付け情報(利用管理テーブル)を記憶する。上記の判定は、関連付け情報に基づいて行われる。これによって、判定を容易に行うことができる。
また、本実施形態において、サーバシステムは、サービスサーバから受信された利用要求に含まれる要求情報が示す情報を利用可能であるか否かを、記憶情報の種類、記憶情報の取得時期、および/または、記憶情報の利用期間に関する条件に基づいて判定する(S15)。これによれば、記憶情報の種類および/または記憶情報の取得時期によって記憶情報の利用を管理することができる。また、記憶情報に利用期間を設定することができる。また、上記管理事業者がサービス事業者に対して上記のような記憶情報を利用させるサービスを行う場合、上記管理事業者は、例えば、利用可能な記憶情報に応じて記憶情報の利用料を設定することができる。
また、本実施形態においては、サーバシステム(ポータルサーバ41)は、商品・サービスを紹介する提供情報を送信情報に基づいて生成し(S19)、提供情報が提供されたユーザから、当該提供情報により示される商品・サービスを購入する旨の購入指示を受け付ける(S20)。これによれば、サーバシステムは、商品・サービスに関する提供情報を提供するだけでなく、提供情報によって紹介された商品・サービスを提供するサービスを行うことができる。また、ユーザは、サーバシステムから提供された商品・サービスを、当該サーバシステムに対する指示によって購入することができるので、購入の利便性を向上することができる。
さらに、本実施形態においては、サービスサーバ3におけるポータルサーバ41は、購入指示を受け付けたことに応じて所定の購入通知をサービス提供サーバ42へ送信する。そして、サービス提供サーバ42は、購入通知を受信したことに応じてサービス提供処理(S22)を実行する。これによれば、商品・サービスの提供を行うサービス事業者側でサービス提供サーバ42によってサービス提供処理を行うとともに、管理事業者側ではポータルサーバ41によって商品・サービスの購入を管理することができる。
また、本実施形態においては、情報処理システムは、ユーザの疲労を示す指標を算出する。すなわち、情報処理システムは、非装着型のセンサ(ドップラーセンサ11)から生体情報を自動的に取得し、取得された生体情報を記憶する(S5)。そして、情報処理システムは、記憶されている生体情報に基づいて、ユーザの疲労指標を算出する(S7)。これによれば、ユーザに測定を意識させることなく、ユーザの疲労度合いを測定することができる。
なお、端末システム1は、センサから生体情報を繰り返し取得する。そして、繰り返し取得された生体情報が蓄積記憶され、蓄積記憶された生体情報に基づいて、ユーザの疲労指標が算出される。これによって、これによれば、ユーザの疲労度合いを継続的に測定することができる。
[6.変形例]
(提供条件を自動的に更新する変形例)
上記実施形態の変形例においては、提供条件は、各ユーザから取得された健康情報に基づいて自動的に更新されてもよい。ここで、提供情報で紹介された商品・サービスが購入された後で取得された健康情報は、当該商品・サービスをユーザが使用した後の健康状態を反映しているので、この健康情報から、当該商品・サービスをユーザが使用した効果を推測することができる。本変形例においては、ポータルサーバ41は、このような効果に基づいて、提供条件を更新する。これによって、ユーザにとってより効果的な提供情報を提供することができる。以下、本変形例の詳細について説明する。
本変形例においては、ポータルサーバ41は、提供条件を更新するための条件更新テーブルを記憶している。図18は、条件更新テーブルの一例を示す図である。図18に示すように、条件更新テーブルは、提供内容と、更新条件と、更新内容とを提供情報毎に関連付けたテーブルである。提供内容は、提供条件テーブルにおける提供内容と同様、提供情報の内容を示す。
更新条件は、提供情報に関する提供条件(提供条件テーブルにおいて当該提供情報に関連付けられる提供条件)を更新する条件を示す。本変形例においては、更新条件は、データ数条件と変更条件とを含む。データ数条件は、提供情報で紹介された商品・サービスの効果を示す効果情報のデータ数に関する条件である。ここで、効果情報は、商品・サービスの購入後に取得された健康情報の分析結果であり、例えば、追加提供条件を判定するために用いられた健康情報である。ポータルサーバ41は、ある提供情報について商品・サービスが購入されたことに応じて、その後に追加提供条件が判定された場合、当該判定に用いられた健康情報を効果情報として記憶しておく。したがって、複数のユーザが上記商品・サービスが購入すると、購入したユーザの数に応じた数の効果情報がポータルサーバ41に取得(記憶)されることになる。
データ数条件は、上記のようにして記憶された効果情報の数(データ数)に関する条件である。データ数条件としては、例えば、「100人分の効果情報が取得されたこと」を示す条件が設定される。
変更条件は、データ数条件に係る効果情報に関する条件である。変更条件としては、例えば、「効果有りを示す効果情報が所定数以上であったこと」を示す条件が設定される。
本変形例においては、ポータルサーバ41は、ある提供情報について効果情報が記憶されたことに応じて、当該提供情報に係る提供条件を更新するか否かを判定する。具体的には、ポータルサーバ41は、条件更新テーブルにおいて、当該提供情報の提供内容に関連付けられるデータ数条件を特定し、記憶されている効果情報のデータ数が、特定されたデータ数条件を満たすか否かを判定する。例えば、図18に示す条件更新テーブルが用いられる場合には、ポータルサーバ41は、記憶されている効果情報のデータ数が、100に達したか(100人分のユーザの効果情報が得られたか)否かを判定する。上記判定の結果、データ数条件が満たされないと判定した場合、ポータルサーバ41は、提供条件を更新しないと判定する。
一方、データ数条件が満たされたと判定した場合、ポータルサーバ41は、記憶されている効果情報に基づいて、変更条件が満たされるか否かを判定する。例えば、図18に示す条件更新テーブルが用いられる場合、ポータルサーバ41は、記憶されている(100個の)効果情報のうち、効果有りを示す効果情報が所定数(例えば70)以上あるか否かを判定する。なお、「効果有りを示す効果情報」とは、例えば図14に示した「疲労度が改善」という追加提供条件の判定結果が肯定となるような健康情報である。つまり、本変形例においては、効果情報が効果有りを示すか否かは、追加提供条件の判定結果に基づいて判断することができる。
変更条件が満たされると判定した場合、ポータルサーバ41は、当該変更条件に関連付けられる更新内容に従って、提供条件テーブルを更新する。ここで、更新内容は、例えば、「閾値を0.1減少する」のように、提供情報に対応する提供条件の更新内容を示す。例えば、図9に示す提供条件テーブルにおける上から1行目の提供条件「(最近1週間の平均疲労度が)4以上」について、図18に示す更新内容「閾値を0.1減少する」に従って更新行われた場合には、更新後の提供条件は、「(最近1週間の平均疲労度が)3.9以上」となる。なお、更新内容は、提供条件を緩くするものであっても、厳しくするものであってもよい。
なお、上記変形例においては、提供条件テーブルを更新する場合を例として説明したが、サービスサーバ3は、追加提供条件テーブルを更新するようにしてもよい。
なお、上記変形例においては、変更条件が満たされたことに応じて提供条件テーブルの更新が行われるので、変更条件が繰り返し満たされることによって、更新は繰り返し(換言すれば、継続的に)行われることになる。
以上のように、サーバシステムは、各端末システムから受信した送信情報および/または当該送信情報から得られる情報(健康情報)をユーザと関連付けて記憶情報として記憶する。また、サーバシステムは、記憶情報から得られる指標または記憶情報に含まれる指標を改善するために当該ユーザに提供する提供情報の生成に関する条件(生成すべき提供情報の内容を決定するための条件、具体的には、提供条件または追加提供条件)を記憶する。そして、サーバシステムは、記憶情報とこの条件とに基づいて提供情報を生成する。ここで、サーバシステムは、提供情報の提供を受けた複数のユーザに関する、当該提供情報の提供後に取得された送信情報に関する分析を行い、分析結果(上記効果情報)に基づいて上記条件を(自動的に)更新する。このように、条件を更新することによって、より効果的な提供情報を提供することができる。
なお、上記変形例においては、提供条件を更新するために用いられる「提供情報の提供後に取得された情報」として、提供条件によって紹介される商品・サービスを購入した後に取得された情報が用いられる。つまり、「提供情報の提供後に取得された情報」として、提供情報の提供に起因して行われる所定の動作のタイミングよりも後に取得された情報が用いられてもよい。この所定の動作のタイミングとしては、上記変形例における「(提供条件によって紹介される)商品・サービスを購入したタイミング」、または、「(提供条件によって紹介される)商品・サービスを利用したタイミング」等が考えられる。
また、上記条件(提供条件)は、健康情報に関する少なくとも1つの健康条件を含む。これによって、ユーザの健康情報に応じた提供情報を提供することができる。ここで、サーバシステムは、提供情報の提供後に取得された情報の分析結果に基づいて健康条件を更新する。これによって、提供情報の提供後におけるユーザの健康状態を分析し、その分析結果に応じて健康条件を更新することができる。
また、上記変形例においては、端末システム1は、ユーザの生体情報を繰り返し取得し、また、送信情報を繰り返しサーバシステムへ送信する。サーバシステムは、複数のユーザの各端末システム1から送信情報を繰り返し受信して蓄積記憶し、蓄積記憶された記憶情報に基づいて提供条件を継続的に(繰り返し)更新する。そして、更新された条件に基づいて提供情報が生成される。図19は、上記変形例による効果を説明するための図である。本変形例のように、提供条件が更新されることによって、サービスサーバ3は、より効果的な提供情報をユーザに対して提供することができる。そして、効果的な提供情報を提供することができれば、提供情報を提供するサービスを利用するユーザがより増えると期待できるので、データサーバ2は、より多くのユーザに関する健康情報を取得することができる。そして、より多くの健康情報を取得することができれば、提供条件をより効果的なものに更新することができる。このように、提供条件を自動的に更新することによって好循環が生じ、より効果的な提供情報を提供することができる。
また、サーバシステムは、所定数の上記分析結果が算出可能となったことに応じて(所定人数分の分析結果を得ることができるようになったことに応じて)、上記条件を更新するか否かを判定する。これによれば、所望の量の分析結果が得られる場合に条件を更新するか否かが判定されるので、更新によって条件を精度良く改善することができる。
なお、提供条件テーブルおよび更新条件テーブルの内容は上記に限らない。例えば、提供条件は、提供情報(提供内容)に対して付された優先順位(優先レベル)を含むものであってもよく、一度に複数の提供条件が満たされた場合には優先順位が高い(優先レベルが最も高い)提供情報が提供(生成)されるようにしてもよい。このとき、更新条件テーブルに含まれる更新内容は、優先順位を変更するものであってもよい。例えば、提供情報による改善効果があること(健康情報が示す指標が改善されたこと)を示す変更条件が満たされた場合には、優先順位を高くなるように変更されてもよい。具体的には、優先レベルが高いものから順に“5”から“1”までの優先レベルが設定されており、商品Aを紹介する提供情報について優先レベルが“3”である場合において、更新条件テーブルは、商品Aに関して改善効果があることを示す変更条件が満たされた場合には、優先レベルを“4”に変更するものであってもよい。
また、上述のように、提供条件は、健康情報に関する複数の条件(項目)を含んでいてもよい。このとき、更新条件テーブルに含まれる更新内容は、項目の追加または削除を行うものでもよいし、項目に付された重みを変更するものであってもよい。
(提供条件に関する変形例)
上記実施形態においては、提供情報を決定するための提供条件(提供条件テーブル)に加えて、追加提供情報を決定するための追加提供条件(追加提供条件テーブル)が設定される場合を例として説明した。ここで、他の実施形態においては、提供情報を決定するための提供条件のみが設定されるようにしてもよい。このとき、提供条件の内容が自動的に更新されてもよい。以下、上記実施形態の変形例として、提供条件テーブル(のみ)が設定され、提供条件が自動的に更新される例について説明する。
図20は、上記実施形態の変形例における提供条件テーブルの一例を示す図である。図20に示すように、本変形例において、提供条件テーブルは、提供条件と、提供内容と、次回提供タイミングとを関連付ける。
本変形例において、提供条件は、上述のユーザ条件および健康条件を含む複数の条件で構成される。具体的には、図20において、提供条件は、ユーザの年齢に関するユーザ条件と、健康情報(ここでは睡眠指標)に関する3種類の健康条件とを含む。すなわち、提供条件は、総睡眠時間の最近1週間の平均に関する条件と、睡眠効率の最近1週間の平均に関する条件と、中途覚醒回数の最近1週間の平均に関する条件とを含む。なお、提供内容によってはこれらの条件全てが設定される必要は無い。例えば図20に示す「商品Cの紹介」を示す提供内容に関連付けられる提供条件のように、提供内容によっては、複数の条件のうちのいくつかの条件が設定されなくてもよい。また、提供条件に含まれる条件は、上記に限らず、他のユーザ条件および/または他の健康条件を含んでもよいし、ユーザ条件および健康条件とは異なる他の条件(例えば、商品・サービスの購入履歴に関する条件等)を含んでいてもよい。このように、他の実施形態においては、提供条件は、複数のユーザ条件を含んでいてもよいし、健康条件を1つのみ含んでいてもよい。
提供内容は、上記実施形態と同様、それに関連付けられる提供条件が満たされる場合に生成(提供)される提供情報の内容を示す。
次回提供タイミングは、それに関連付けられる提供内容の提供情報が提供された場合に、その後において提供情報を(再度)提供する(正確には、提供情報を提供するか否かを判定する)タイミングを示す。本実施形態においては、次回提供タイミングは、上述の追加提供タイミング(図14)と同様、商品・サービスが購入されてからの時間を示す。ただし、他の実施形態においては、次回提供タイミングは、前回に提供情報が提供された時点からの時間を示してもよい。また、商品を実際に使用した時点やサービスを実際に受けた時点がポータルサーバ41に取得される場合には、これらの時点からの時間を示してもよい。
本変形例においては、上記実施形態において示した提供条件テーブル(図9)に代えて、図20に示す提供条件テーブルが用いられる。本変形例においても上記実施形態と同様、提供情報に関する判定処理(ステップS14およびS18)が実行される。この判定処理によって、提供情報を提供するか否か、および、提供する場合にはどの提供情報を提供するかが判定される。また、本変形例においても上記実施形態と同様、提供条件に含まれる各条件が満たされる場合、当該提供条件に関連付けられる提供内容の提供情報が提供される。例えば、図20に示される提供条件テーブルによれば、ユーザの年齢が40代であり、最近1週間の総睡眠時間の平均が6時間未満であり、最近1週間の睡眠効率の平均が80%未満であり、かつ、最近1週間の中途覚醒回数の平均が3回以上である場合、商品Aを紹介する提供情報が提供すべき情報として決定される。
なお、提供条件が複数の条件を含む場合、他の実施形態においては、ポータルサーバ41は、複数の条件のうちの所定数の条件が満たされた場合に提供条件が満たされたと判断するようにしてもよい。例えば、図20の例においては、3つの健康条件のうち2つが満たされた(かつ、ユーザ条件が満たされた)場合に、提供条件が満たされたと判断するようにしてもよい。また、他の実施形態においては、ポータルサーバ41は、提供条件に含まれる各条件についてそれぞれ重み(ポイント)を付しておき、当該各条件のうちで満たされた条件のポイントが所定値以上となった場合に提供条件が満たされたと判断するようにしてもよい。
なお、提供条件が満たされた(換言すれば、提供条件に含まれる各条件が満たされた)か否かを判定する方法は任意である。すなわち、ポータルサーバ41は、上記実施形態と同様に、まずユーザ条件を判定し、それから、条件が満たされるユーザ条件に関連付けられる健康条件を判定してもよい。また、ポータルサーバ41は、ユーザ条件と健康条件とをそれぞれ個別に(並列的に)判定してもよい。
本変形例においても上記実施形態と同様、満たされた提供条件が存在する場合には、それに関連付けられる内容の提供情報が端末システム1へ送信される(ステップS19)。
本変形例においては、提供情報で紹介される商品・サービスが購入された場合(ステップS20)、ポータルサーバ41は、当該提供情報に関連付けられる次回提供タイミングに基づいて、その後に提供情報を提供するタイミングを特定する。このタイミングを特定する方法は、上記実施形態において追加提供タイミングを特定する処理(ステップS23)と同様の方法で行われてもよい。特定されたタイミングは、次回提供タイミング情報として記憶される。すなわち、本変形例においては、ポータルサーバ41は、ユーザ提供履歴情報(図12)における「追加提供タイミング情報」に代えて、次回提供タイミング情報を記憶する。
本変形例において、ポータルサーバ41は、各ユーザのユーザ提供履歴情報を定期的に参照することによって、次回提供タイミングが到来したか否かを定期的に判定する。そして、次回提供タイミングが到来したと判定された場合、ポータルサーバ41は、提供条件テーブルを用いて、提供情報を提供するか否か、および、どの提供情報を提供するかを判定する。すなわち、ポータルサーバ41は、次回提供タイミングが到来したと判定された場合、提供情報に関する判定処理(S14およびS18)を実行する。つまり、本変形例においては、ユーザがログインした場合以外に、次回提供タイミングが到来した場合にも、提供情報に関する判定処理が実行される。また、次回提供タイミングが到来した場合に用いられる提供条件テーブルは、ユーザがログインした場合に用いられる提供条件テーブルと同じであり、本変形例では追加提供条件テーブルは用いられない。
次回提供タイミングの到来に応じて提供情報に関する判定処理が実行された結果、提供されるべき提供情報が生成(決定)された場合、ポータルサーバ41は、提供情報がある旨のメッセージをプッシュ通知で端末システム1へ送信する。プッシュ通知の方法は、上記実施形態におけるステップS29における方法と同様である。なお、他の実施形態においては、提供情報自体がプッシュ通知で端末システム1へ送信されてもよい。このように、本変形例においては、次回提供タイミングの到来に応じて提供情報が提供される場合には、提供情報の通知(または提供情報自体)がプッシュ通知で端末システム1へ送信される。これによって、提供情報が生成されたことを適切なタイミングでユーザに通知することができる。
本変形例のように、情報処理システムは、追加提供条件テーブルを用いないものであってもよい。なお、追加提供タイミングを設定しない場合であっても、次回提供タイミングを設定することによって、サービスサーバ3は、商品・サービスの購入後における所望のタイミングで提供情報をユーザに提供することができる。
本変形例においても上記実施形態と同様、ユーザの健康情報(の分析結果)に基づいて提供条件が更新される。本変形例でも上記実施形態と同様、更新のために条件更新テーブル(図18)が用いられる。ここで、本変形例では、提供条件に複数の条件(健康条件)が含まれるので、条件更新テーブルに含まれる変更条件は、これら複数の条件に関する条件であってもよい。例えば図20に示す提供条件テーブルが用いられる場合において、変更条件は以下であってもよい。
(a)商品の購入後に総睡眠時間または睡眠効率が改善したユーザのうち、商品の購入前に睡眠効率70%から80%であったユーザの割合が30%以下であり、かつ、商品の購入前に睡眠効率が70%以下であったユーザの割合が60%以上であること
(b)商品の購入後に総睡眠時間または睡眠効率が悪化したユーザのうち、商品の購入前に中途覚醒回数の条件を満たしていたユーザの割合が80%以上であったこと
(c)「商品の購入後に総睡眠時間または睡眠効率が改善したユーザのうち、商品の購入前に中途覚醒時間が1時間以上であったユーザの割合が80%以上であること
また、上記(c)のように、変更条件は、提供条件テーブルに含まれる健康情報とは異なる健康情報(上記(c)の例では、中途覚醒時間の情報)に関する条件を含んでいてもよい。
また、提供条件に複数の条件(健康条件)が含まれる場合において、条件更新テーブルにおける更新内容は、当該複数の条件のうちいくつか(または全部)を更新するものであってもよい。例えば、図20に示す提供条件テーブルが用いられる場合において、変更内容は、「睡眠効率の閾値を5減少させる」であってもよい。例えば、上記(a)の変更条件に対して、この変更内容が関連付けられていてもよい。
また、変更内容は、提供条件テーブルに新たな条件を追加するものであってもよい。例えば、図20に示す提供条件テーブルが用いられる場合において、変更内容は、「「中途覚醒時間が1時間以上であること」という健康条件を追加する」のように、新たな健康情報に関する条件を追加するものであってもよい。例えば、上記(c)の変更条件に対して、この変更内容が関連付けられていてもよい。
また、提供条件テーブルの各条件に重みが付される場合には、変更内容は、当該重みを変更するものであってもよい。例えば、変更内容は、「中途覚醒回数に関する条件の重み付けを軽くする」であってもよい。例えば、上記(b)の変更条件に対して、この変更内容が関連付けられていてもよい。また、上述のように、提供情報に優先順位が付される場合には、変更内容は、この優先順位を変更するものであってもよい。
また、更新条件に含まれるデータ数条件は、データ数が増加した場合に繰り返し満たされるような条件であってもよい。データ数条件は、例えば「効果情報が100人分増加したこと」のように、所定数(100人分)の効果情報が取得される度に満たされる条件であってもよい。この場合、サービスサーバ3は、増加した所定数(100人)分のデータに基づいて変更条件の判定を行ってもよい。
上記のように、サービスサーバ3は、分析結果の数に関する条件(データ数条件)が満たされることに応じて、当該条件を更新するか否かの判定を繰り返し実行してもよい。これによれば、更新を繰り返し実行することによって、提供条件(または追加提供条件)の内容を繰り返し改善することができる。その結果、提供条件をより精度の良いものとすることができる。
上記のように、本変形例においては、提供条件を更新する処理として、以下のうち少なくとも1つを行う。
(a)提供条件に対して設定される優先順位の変更
(b)健康条件内で規定されるパラメータ(例えば、健康条件において規定されている閾値)の変更
(c)健康条件に対して設定されるパラメータの変更(例えば、健康条件に付される重み)
(d)提供条件に含まれる健康条件の追加および/または削除
上記(a)~(d)によって提供条件を更新することによって、提供条件をより精度の良いものとすることができる。
(変化情報に関する変形例)
また、サービスサーバ3(ポータルサーバ41)は、購入された商品・サービスについて、購入の前後の健康情報を示す変化情報を記憶しておいてもよい。このとき、変化情報は、上述の効果情報の一部として用いられてもよいし、または、効果情報を算出するために用いられてもよい。以下、上記実施形態における変形例として、変化情報が用いられる場合の一例について説明する。
図21は、変化情報の一例を示す図である。図21において、変化情報は、購入情報と、ユーザ情報と、購入前健康情報と、購入後健康情報とを関連付けた組を示す情報である。購入情報は、ユーザに購入された商品・サービスを示す情報である。購入情報は、商品・サービスが購入される毎に追加して記憶される。したがって、図21に示すように、変化情報は、単一の商品について上記の組を複数種類含むことがある。また、ユーザ情報は、商品・サービスを購入したユーザに関する情報である。本変形例では、ユーザの年齢および性別を示す情報がユーザ情報として記憶される。
購入前健康情報は、商品を購入する前における(商品を購入した)ユーザの健康情報である。本変形例では、総睡眠時間、睡眠効率、および入眠潜時等の健康情報について、購入前1週間の平均値を示す情報が購入前健康情報として記憶される。なお、購入前健康情報として記憶される健康情報は、上記に限らず任意である。例えば、データサーバ2に記憶される各種類の健康情報について、購入前健康情報(および購入後健康情報)が記憶されてもよい。
購入後健康情報は、商品を購入した後におけるユーザの健康情報である。購入後健康情報は、それに関連付けられる購入前健康情報が示す健康情報と同種の健康情報である。すなわち、図21に示す例においては、総睡眠時間、睡眠効率、および入眠潜時等の健康情報に関する情報が購入後健康情報として記憶される。また、本実施形態においては、これらの健康情報について、購入後1週間の平均値を示す情報が購入後健康情報として記憶される。
なお、購入前健康情報および購入後健康情報の内容は、購入情報が示す商品毎に異なる種類の健康情報に関する情報であってもよい。例えば、商品Aおよび商品Bについては、総睡眠時間、睡眠効率、および入眠潜時の3種類の健康情報に関する情報(平均値)が購入前健康情報および購入後健康情報として記憶されるのに対して、商品Cについては、総睡眠時間および疲労度に関する情報が購入前健康情報および購入後健康情報として記憶されてもよい。
なお、購入前健康情報および購入後健康情報の内容は、購入情報が示す商品毎に異なる内容であってもよい。例えば、商品Aおよび商品Bについては、購入前1週間の平均値および購入後1週間の平均値が購入前健康情報および購入後健康情報として記憶されるのに対して、商品Cについては、購入前1月の平均値および購入後1月の平均値が購入前健康情報および購入後健康情報として記憶されてもよい。
また、他の実施形態においては、変化情報は、ユーザの健康状態の変化を示すものであればどのような形式であってもよい。例えば、変化情報は、購入前健康情報および購入後健康情報に代えて、購入前後における健康情報の変化を示す情報を含んでいてもよい。変化情報は、例えば「総睡眠時間が0.5時間増加」や、「睡眠効率が改善」等を示す情報を含んでいてもよい。
また、変化情報は、提供情報(商品・サービス等)毎に変化情報が記憶されてもよいし、ユーザ情報(年齢・性別等)毎に変化情報が記憶されてもよい。
ポータルサーバ41は、商品が購入された場合(S20)、変化情報のうちの購入情報、ユーザ情報、および購入前健康情報を記憶する。なお、購入前健康情報の算出は、算出に用いられる情報をデータサーバ2から取得することによって行われる。なお、ポータルサーバ41は、提供情報によって紹介された商品・サービスが購入された場合に限らず、提供情報によって紹介されていない商品・サービスがポータルサイトにおいて購入された場合にも変化情報を算出してもよい。これによって、サービスサーバ3は、商品・サービスの効果を判断するためのデータをより多く収集することができ、効果を精度良く判断することができる。
また、商品購入から所定期間が経過すると、ポータルサーバ41は、購入後健康情報を取得して記憶する。この所定期間は、予め定められた期間(図21の例では1週間)である。上述のように、所定期間は、商品毎に異なる期間であってもよい。また、所定期間は、商品に対応する追加提供タイミングあるいは次回提供タイミングに対応する期間に設定されていてもよい。これによれば、ポータルサーバ41は、変化情報を算出する処理と、追加提供情報(または提供情報)に関する判定処理とを同じタイミングで行うことができ、処理の効率化を図ることができる。例えば、上記2つの処理において、データサーバ2から情報を取得する処理や、取得した情報から統計値を算出する処理を共通化することができるので、処理の効率化を図ることができる。
ポータルサーバ41は、購入前健康情報の算出と同様、算出に用いられる情報をデータサーバ2から取得し、取得した情報を用いて購入後健康情報を算出する。また、購入前後における健康情報の変化を示す情報を算出する場合には、ポータルサーバ41は、購入前健康情報および購入後健康情報に基づいて当該変化を示す情報を算出する。
以上のようにして算出された変化情報は、例えば上述の効果情報(の一部)として用いられてもよいし、効果情報を算出するために用いられてもよい。また、他のユーザに関する健康情報の分析結果を用いて提供情報の生成が行われる場合(詳細は後述する)には、変化情報は、当該分析結果(の一部)として用いられてもよいし、当該分析結果を算出するために用いられてもよい。
上記のように、サーバシステムは、ユーザに対して提供された提供情報と、当該提供情報がユーザに提供されたことに起因する所定の基準時点の前後における、ユーザの健康情報の変化とを関連付けた変化情報を記憶する。そして、サーバシステムは、変化情報に基づいて(変化情報を上記分析結果として用いて、または、変化情報を用いて得られる上記分析結果に基づいて)提供条件(または追加提供条件)を更新する。このように、変化情報を記憶しておくことによって、健康情報に関する分析結果を容易に算出し、更新を容易に行うことができる。
(提供情報の生成に関する変形例)
他の実施形態においては、サーバシステムは、提供情報を提供する対象となるユーザとは異なる他の1以上のユーザに関する分析結果に基づいて提供情報を生成するようにしてもよい。例えば、サーバシステムは、他のユーザとして例えば以下のユーザを選出してもよい。
・提供情報を提供する対象となるユーザと同じ商品を購入している他のユーザ
・提供情報を提供する対象となるユーザとユーザ情報(年齢、世代および/または性別等)が共通する他のユーザ
・提供情報を提供する対象となるユーザと健康情報が近い他のユーザ
上記のように、サーバシステムは、提供情報を提供する対象となるユーザに関する情報に基づいて他のユーザを選出し、選出したユーザの健康情報に関する分析結果に基づいて提供情報の内容を決定してもよい。これによって、有益な提供情報をユーザに提供しやすくなる。
(提供情報の内容に関する変形例)
上記実施形態においては、提供情報は、商品・サービスを紹介する情報(リコメンド情報)であった。ここで、上記実施形態および変形例において、提供情報は、ユーザの健康および/または身体に関する指標を改善するための任意の情報であってもよい。例えば、提供情報は、当該指標を改善するアドバイスを示すアドバイス情報であってもよい。アドバイス情報としては、例えば、(a)睡眠時の眠りが浅いことを表す健康情報が算出されたユーザに対して、運動することを勧めるアドバイス、(b)疲労が溜まっていることを表す健康情報が算出されたユーザに対して、食事の栄養バランスを見直すことを勧めるアドバイス、および、(c)睡眠時間または就寝時刻が不規則であることを表す健康情報が算出されたユーザに対して、生活習慣を改善することを勧めるアドバイス等が考えられる。なお、上記実施形態のように、提供情報(アドバイス情報等)が繰り返し提供される場合には、ある提供情報を提供した後のユーザの健康情報に基づいて、さらに提供情報が提供される。これによれば、アドバイス情報等の提供情報が繰り返し(継続的に)ユーザに提供されるので、健康の改善をユーザに対して効果的に促すことができる。
また、提供情報がアドバイス情報である場合、サービスサーバ3は、アドバイス情報をユーザに提供した前後における健康情報を比較し、比較の結果に基づいて追加のアドバイス情報を、上述の追加提供情報として提供してもよい。すなわち、サービスサーバ3は、比較の結果、ユーザの健康が改善していると判定する場合と、改善していないと判定する場合とで、異なるアドバイス情報を提供してもよい。
また、サービスサーバ3は、アドバイス情報の提供条件を更新するようにしてもよい。すなわち、サービスサーバ3は、サービスサーバ3は、アドバイス情報をユーザに提供した前後における健康情報を比較し、比較の結果、アドバイス情報の提供前後においてユーザの健康が改善したと判断した場合には、当該アドバイス情報が提供されやすくなるように、当該アドバイス情報の提供条件を更新してもよい。なお、提供情報がアドバイス情報である場合も、上記“(提供条件を自動的に更新する変形例)”に記載の変形例のように、例えば条件更新テーブルを用いることによって、更新条件を自動的に更新することができる。例えば、サービスサーバ3は、条件更新テーブルにおける更新条件として、アドバイス情報の提供前後におけるユーザの健康情報の変化に関する条件を設定してもよい。
また、提供情報は、当該指標を改善するための商品・サービス自体のデータ(例えば、上述した、ユーザの入眠あるいは起床を誘導する音楽のデータ)であってもよい。つまり、提供情報は、ユーザに情報を紹介するもの(商品・サービスを紹介する情報、あるいは、アドバイス情報)であってもよいし、ユーザに提供すべきアドバイス自体、商品・サービスのデータ自体であってもよい。また、提供情報は、商品・サービスに関する情報(商品・サービスを紹介する情報、あるいは、商品・サービス(自体)のデータを含む情報)であってもよいし、(商品・サービスとは無関係の)アドバイス情報であってもよい。
なお、上記実施形態および変形例では、提供情報は商品・サービスを紹介するものであったので、情報処理システムは、商品・サービスの購入時点(あるいは利用時点)を基準時点として用いて各種の処理を行った。例えば、上記実施形態では、上述の利用情報(図9)によって購入時点を基準時点とした期間が指定されたり、追加提供タイミング(図14)あるいは次回提供タイミングの基準時点として購入時点が用いられたりした。また、上記変形例では、変化情報(図21)の基準時点(変化情報は、基準時点の前後における健康情報の変化を示す)として購入時点が用いられた。これに対して、アドバイス情報あるいは上記商品・サービスのデータのように、提供情報自体を利用する場合には、提供情報の提供時点を基準として用いてもよい。
(健康情報の内容に関する変形例)
上記実施形態においては、健康情報は、ユーザの睡眠および/または疲労に関する指標を示す情報であった。したがって、本実施形態によれば、ユーザの睡眠および/または疲労に応じた提供情報を提供することができる。なお、他の実施形態においては、健康情報は、睡眠および/または疲労に関する指標に加えて(または代えて)、肥満に関する指標(例えば、体重や体脂肪率や基礎代謝量等)、あるいは、肌状態に関する指標(例えば、肌の水分量や、シミの状態を示す指標等)を示す情報であってもよい。
(サービスサーバの構成に関する変形例)
上記実施形態においては、サービスサーバ3はポータルサーバ41とサービス提供サーバ42とを含み、商品・サービスの購入を行うショッピングサイトはポータルサーバ41によって管理されるものとした。ここで、サービスサーバ3の構成は任意であり、ポータルサーバ41およびサービス提供サーバ42の機能(役割)は上記実施形態に限らない。例えば、他の実施形態においては、1以上のサービス提供サーバがそれぞれショッピングサイトを管理し、ポータルサーバが管理するポータルサイトでは、提供情報を提供および健康情報の閲覧が可能であるようにしてもよい。このとき、ポータルサイトのページに含まれる提供情報には、ショッピングサイトへアクセスするためのリンク情報が含まれていてもよい。また、ショッピングサイトにおいて商品・サービスの購入が行われた場合には、ポータルサーバ41において購入(購入履歴)を管理するべく、サービス提供サーバ42からポータルサーバ41へ購入の通知が送信されてもよい。また、他の実施形態においては、ポータルサーバ41の機能とサービス提供サーバ42の機能とが1つのサーバによって提供されてもよい。
(商品・サービスに関する変形例)
また、他の実施形態においては、サービスサーバ3において提供される商品・サービスは、端末システム1に対して提供されるアプリケーションであってもよい。このとき、アプリケーションは、データサーバ2に記憶される情報(健康情報等)を利用するものであってもよい。上記アプリケーションは、例えば、端末システム1において取得される生体情報を用いてユーザの生存確認を行って他のユーザに通知を行う見守りサービスを行うためのアプリケーションであってもよい。
また、他の実施形態においては、サーバにおいて、ゲームが提供されてもよい。ゲームを提供するサーバは、サービスサーバ3と同じサーバであってもよいし、専用のサーバ(ゲームサーバ)であってもよい。例えば、ポータルサーバ41が管理するポータルサイト内においてゲームアプリケーションがユーザに提供されてもよい。なお、ゲームアプリケーションは、ポータルサイトを閲覧するためのブラウザ上で動作する種類のものであってもよいし、サーバから端末システム1にダウンロードされてインストールされる種類のものであってもよい。
なお、ゲームアプリケーションは、サーバから端末システム1に提供される他、任意の方法で端末システム1に取得されてもよい。例えば、ゲームアプリケーションを記憶した記憶媒体が主端末装置10に接続(または装着)されることによって、主端末装置10においてゲームアプリケーションが実行されてもよい。
また、ゲームアプリケーションは、主端末装置10において実行されてもよいし、ユーザが有する他のユーザ端末(携帯端末、パーソナルコンピュータ、および、ゲーム装置等)において実行されてもよい。
上記のようにユーザ端末(主端末装置10、および/または、上記他のユーザ端末)においてゲームアプリケーションが実行される場合、ユーザの健康情報に対する評価結果がゲームに反映されてもよい。具体的には、サービスサーバ3は、データサーバ2に記憶されるユーザの健康情報に対する評価を行う。すなわち、サービスサーバ3は、健康情報が所定の条件を満たすか否かを判定する。この所定の条件とは、例えば、健康情報が示す疲労度が基準値以上の良い値である状態が所定期間継続したこと、あるいは、疲労度が所定の基準以上改善したこと等である。上記条件が満たされた場合、サービスサーバ3は、ゲーム上の特典をユーザに付与する。例えば、サービスサーバ3は、ゲーム内で利用するアイテム等のコンテンツをユーザに付与したり、ゲーム内のストーリーを進行させたりするようにしてもよい。このような特典を付与することによって、健康情報を算出することを継続する動機をユーザに与えることができる。
上記において、端末システムとサーバシステムとを含む情報処理システムは、ゲームアプリケーションに基づくゲーム処理を実行する。ここで、情報処理システムは、ゲーム処理を実行する際に、サーバシステムに記憶されている健康情報を参照する。そして、参照した健康情報に基づいて(参照結果に応じて)当該ゲーム処理中の所定の処理が実行される。所定の処理は、例えば、上記のアイテムを付与する処理や、ゲーム内のストーリーを進める処理である。具体的には、情報処理システムは、ゲームアプリケーションで利用されるゲームデータを追加または更新する処理を行う。つまり、付与されるアイテムのゲームデータが追加されたり、新たなストーリーをプレイできるようにゲーム内のフラグが更新されたりする。
なお、ゲーム処理は、サーバ側の情報処理装置(例えば、ゲームサーバ、または、サービスサーバ)で実行されてもよいし、端末側の情報処理装置(例えば、主端末装置10、または、上記他のユーザ端末)で実行されてもよい。また、ゲーム処理は、サーバ側の情報処理装置と端末側の情報処理装置とが協働して実行されてもよい。つまり、ゲーム処理の一部の処理がサーバ側で実行され、他の一部の処理が端末側で実行されてもよい。例えば、ポータルサイトを閲覧するためのブラウザ上でゲームアプリケーションが動作する場合には、ゲーム処理はサーバ側で実行されたり、サーバ側と端末側とで協働して実行されたりする。また、ゲームアプリケーションが端末側の情報処理装置にインストールされる場合、あるいは、当該情報処理装置に接続される記憶媒体に記憶されるゲームアプリケーションが実行される場合には、ゲーム処理は、端末側で実行されたり、サーバ側と端末側とで協働して実行されたりする。
また、ゲームデータの追加または更新は、サーバ側で実行されてもよいし、端末側で実行されてもよい。すなわち、ゲームデータを追加または更新する処理は、サーバ側の情報処理装置が、サーバ側または端末側の記憶部に記憶されるゲームデータに対して追加または更新を行うことによって実行されてもよい。また、ゲームデータを追加または更新する処理は、端末側の情報処理装置が、端末側の記憶部に記憶されるゲームデータに対して追加または更新を行うことによって実行されてもよい。
なお、上記のようにゲームアプリケーションにおいて健康情報を利用(参照)する際には、ゲームアプリケーションのユーザに関する健康情報が参照される。例えば、上記ポータルサイトにユーザがログインした状態でゲームアプリケーションが利用される場合には、サーバは、ログイン時に入力されるユーザ識別情報によってユーザを特定することができる。すなわち、サーバは、ログイン時に入力されたユーザ識別情報を記憶しておき、ゲーム処理において健康情報を参照する際、記憶しておいたユーザ識別情報によって特定されるユーザの健康情報を参照する。
また、上記ポータルサイトにユーザがログインしていない状態でゲームアプリケーションが利用される場合(あるいは、ログインしている端末とは異なる端末を用いてゲームアプリケーションが利用される場合)には、ゲーム処理の前またはゲーム処理中において、サーバは、ゲームアプリケーションを利用しているユーザを識別する。具体的には、ゲームアプリケーションを利用しているユーザ端末は、ゲーム処理の前またはゲーム処理中において、ユーザ識別情報の入力をユーザから受け付け、入力されたユーザ識別情報をサーバへ送信する。サーバは、ユーザ端末からのユーザ識別情報を用いて、参照すべき健康情報を特定する。ゲームデータの追加または更新がサーバ側で実行される場合には、サーバは、特定された健康情報を参照して、参照した健康情報に基づいてゲーム処理中の所定の処理(ゲームデータの追加または変更)を実行する。一方、ゲームデータの追加または更新が端末側で実行される場合には、サーバは、特定された健康情報をユーザ端末へ送信する。ユーザ端末は、受信した健康情報を参照して(つまり、サーバ側で記憶される健康情報を参照して)、参照した健康情報に基づいてゲーム処理中の所定の処理を実行する。
上記においては、ユーザ識別情報は、ポータルサイトにおけるユーザのアカウントであるだけでなく、ゲームアプリケーションを提供するサービスにおけるアカウントを兼ねてもよい。この場合、複数のネットワークサービス(上記提供情報を提供するサービス、および、ゲームアプリケーションを提供するサービスを含む)におけるユーザのアカウントを共通にすることによって、ユーザは、異なるユーザ端末(プラットホームが異なる端末でもよい)において、複数のネットワークサービスを共通に利用することができるので、利便性が向上する。
<第2の実施形態>
次に、第2の実施形態に係る情報処理システム、情報処理装置、情報処理プログラム、および情報処理方法について説明する。上記第1の実施形態における“(提供条件を自動的に更新する変形例)”では、ユーザ全体について提供条件を更新する例について説明した。第2の実施形態においては、ユーザ毎に提供条件を更新する例を説明する。第2の実施形態においては、ユーザ毎に提供条件がカスタマイズされるので、ユーザに適した情報を提供することができる。以下、第2の実施形態の詳細について説明する。
[1.情報処理システムの構成]
第2の実施形態においては、情報処理システムは、第1の実施形態における端末システム1に代えて、後述する端末システム100を含む構成とする。ただし、第2の実施形態においても第1の実施形態と同様、端末システムの構成は任意である。例えば、情報処理システムは、第1の実施形態における端末システム1と、第2の実施形態における端末システム100との両方を含む構成であってもよい。つまり、情報処理システムは、異なる種類の端末システムを含むものであってもよい。
次に、端末システム100の構成の一例について説明する。図22は、端末システム100の詳細な構成の一例を示す図である。図23は、端末システム100の外観の一例を示す図である。図22~図23に示すように、端末システム100は、携帯端末105と、ベース装置106とを備える。携帯端末105はユーザによって携帯される。ベース装置106は、例えばユーザの自宅に設置される。
本実施形態において、携帯端末105は、携帯型の情報処理装置であり、ベース装置106は、携帯端末105を接続可能なクレードルである。図23に示すように、携帯端末105は、ベース装置106に対して着脱可能に接続することが可能である。また、ベース装置106は携帯端末105に対して充電を行う機能を有しており、携帯端末105とベース装置106とが接続された場合、ベース装置106による携帯端末105に対する充電が可能となる。なお、他の実施形態においては、携帯端末105とベース装置106とは、ケーブルを介して着脱可能に接続される形態であってもよい。
また、携帯端末105とベース装置106との通信方法は任意であり、ケーブルを介した有線通信によって行われてもよいし、電波通信や赤外線通信等の無線通信によって行われてもよい。また、携帯端末105とベース装置106との通信は、両者の間で直接行われる通信方法によって行われてもよいし、LANやインターネット等のネットワークを介する通信方法によって行われてもよい。
まず、本実施形態における携帯端末105の構成について説明する。携帯端末105は、携帯型の情報処理装置であり、本実施形態においては、例えば、携帯電話、スマートフォン、またはタブレット端末等といった多機能デバイスである。すなわち、携帯端末105は、一般的な多機能デバイスが有する各種の機能(例えば、入力機能、出力(表示)機能、情報処理機能、ネットワーク通信機能、通話機能、カメラ機能等)のうちのいくつかを有している。なお、ネットワーク通信機能は、インターネットを介した通信機能、および/または、モバイル通信網を介した通信機能である。携帯端末105は、既製の多機能デバイスに所定の機能をインストールすることで実現されてもよい。本実施形態において、携帯端末105は、上記多機能デバイスとして用いられることに加えて、上記健康情報を算出したり、上記ゲーム処理を実行したりするために用いられる。また、携帯端末105は、例えば腕時計型あるいはメガネ型の端末のように、ユーザに装着可能な情報処理装置(いわゆるウェアラブル端末)であってもよい。
図22に示すように、携帯端末105は通信部110を備える。通信部110は、ネットワーク4に接続して、サーバ(すなわち、データサーバ2および/またはサービスサーバ3)との通信を行う。本実施形態において、通信部110は、モバイル通信網(換言すれば、携帯電話通信網)に接続して通信を行う機能を有する通信モジュールである。例えば、通信部110は、3Gの通信規格、あるいは、4G(LTE(Long Term Evolution)を含む)の通信規格に準拠した通信方式で通信を行う。なお、携帯端末105がサーバと通信するための方法は任意であり、例えば、Wi-Fiの認証を受けた通信モジュールによって無線LANを介して通信を行う方法であってもよい。また、携帯端末105は、モバイル通信網を介してサーバと通信する機能と、無線LANを介してサーバと通信を行う機能との両方を備えていてもよい。
携帯端末105は処理部111を備える。処理部111は、携帯端末105において実行される各種の情報処理を実行する。処理部111は、携帯端末105の各部110,112~119に接続される。処理部111は、CPU(Central Processing Unit)およびメモリを有する。携帯端末105においては、CPUがメモリを用いて、携帯端末105に記憶された情報処理プログラムを実行することによって上記各種の情報処理が実行される。本実施形態においては、処理部111は、上記情報処理として、上述した健康情報を算出する処理、ゲーム処理、および、サーバから受信した情報(例えば上記サービス情報)をユーザに提供する処理等を実行する。また、携帯端末105が多機能デバイスとして動作する場合、処理部111は、各機能を実現するための情報処理を実行する。
携帯端末105は、入出力インターフェースを備え、ユーザが情報を入力したり閲覧したりするための情報処理装置(換言すれば、入出力端末)として機能する。具体的には、携帯端末105は、操作入力部112、ディスプレイ117、および、スピーカ118を備える。操作入力部112は、ユーザによる操作入力を受け付ける任意の入力装置である。本実施形態においては、操作入力部112は、ディスプレイ117上に設けられるタッチパネルと、ボタンとを含む。他の実施形態において、携帯端末105は、操作入力部112として、携帯端末105を動かす操作を検出するためのセンサ(加速度センサやジャイロセンサ)を備えていてもよい。
出力装置の一例であるディスプレイ117は、操作入力部112に対する入力に応じて携帯端末105において生成される各種の画像を表示したり、サーバから受信されたデータに基づく各種の画像(例えば、ネットワークサービスに関する画像)を表示したりする。出力装置の一例であるスピーカ118は、操作入力部112に対する入力に応じて携帯端末105において生成される各種の音を出力したり、サーバから受信されたデータに基づく各種の音(例えば、ネットワークサービスに関する音声や音楽)を出力したりする。
携帯端末105は、上記健康情報を算出するための情報を検出するセンサを備える。本実施形態においては、携帯端末105は、位置検出部113、および、環境センサ114を備える。
位置検出部113は、携帯端末105の位置を検出する。本実施形態においては、位置検出部113は、GNSS(Global Navigation Satellite System)を用いて位置を検出する。位置検出部113は、例えばGPS(Global Positioning System)センサ(例えば、GPSモジュール)である。なお、位置検出部113における位置検出方法は任意であり、位置検出部113は、例えばビーコンを用いて位置を検出してもよい。また例えば、位置検出部113は、気圧センサの検出結果に基づいて高度の変化を算出することで、ユーザの高度を示す情報(例えばビルの何階にいるかを示す情報)を算出してもよい。
環境センサ114は、携帯端末105の周囲の環境を検出する。本実施形態においては、環境センサ114は、温度センサおよび湿度センサを含む。なお、他の実施形態においては、環境センサ114として、気圧センサ、照度センサ、騒音センサ、においセンサ等が含まれていてもよい。すなわち、環境センサ114は、温度、湿度、照度、気圧、音、およびにおいのうち少なくとも1つを検知するものであってもよい。また、他の実施形態においては、マイク115が周囲の騒音を検出するための環境センサとして用いられてもよい。
また、携帯端末105は、マイク115を備える。マイク115は、携帯端末105の周囲の音を検出する。マイク115は、健康情報を算出するために用いられてもよい。例えば、携帯端末105は、マイク115によってユーザのいびきの音を検出し、検出結果に基づいて睡眠に関する情報を算出してもよい。なお、マイク115は、携帯端末105に対する音声入力を受け付けるために用いられてもよい。
携帯端末105は、カメラ116を備える。カメラ116は、例えば、携帯端末105においてディスプレイ117が設けられる面と同じ側(すなわち、内側)に設けられる(図23参照)。つまり、カメラ116は、携帯端末105を操作するユーザを撮像することが可能な位置に設けられる。なお、携帯端末105は、カメラ116による撮像画像に基づいてユーザの表情を判別し、ユーザの表情に基づいて疲労度を算出するようにしてもよい。
携帯端末105は、ベース装置106と電気的に接続するためのコネクタ119を備える。本実施形態においては、携帯端末105がベース装置106に装着された場合(図23参照)に、コネクタ119がベース装置106のコネクタ121と接触する。これによって、携帯端末105とベース装置106との通信が可能となる。
なお、携帯端末105は、図示しない電池を備えており、携帯端末105の各部は、電池から供給される電力によって動作する。詳細は後述するが、本実施形態においては、ベース装置106によって携帯端末105の電池を充電することが可能である。
次に、本実施形態におけるベース装置106の構成について説明する。本実施形態においては、ベース装置106は、例えばユーザの寝室に配置され、ユーザの就寝中においてユーザの睡眠に関する生体情報を検出するために用いられる。ここで、生体情報は、ユーザの身体から検出される情報である。本実施形態においては、呼吸、脈拍、および体動が生体情報として検出される。なお、他の実施形態においては、生体情報として検出される情報は任意であり、呼吸、脈拍、および体動のうちのいずれか1つまたは2つが検出されてもよいし、これら3つの情報とは異なる他の情報が検出されてもよい。また、ベース装置106は、就寝中におけるユーザに対してコンテンツ(例えば、ユーザに入眠を促すコンテンツ)や情報(例えば、睡眠に関する評価結果の情報)を提供するために用いられる。
ベース装置106は、携帯端末105を着脱可能に支持する支持部を備える。具体的には、図23に示すように、ベース装置106の筐体(具体的には、支持部)には、携帯端末105の一部の形状に応じた凹部が設けられる。この凹部に携帯端末105が挿入されることによって、携帯端末105がベース装置106に装着される。なお、ベース装置106が携帯端末105を支持するための機構は任意である。
図22に示すように、ベース装置106はコネクタ121を備える。上記凹部に携帯端末105が挿入された場合、携帯端末105のコネクタ119とベース装置106のコネクタ121とが接続される。その結果、携帯端末105とベース装置106との通信が可能となり、ベース装置106による携帯端末105に対する充電が可能となる。
ベース装置106は、生体情報を検出するセンサの一例であるドップラーセンサ124を備える。ドップラーセンサ124は、マイクロ波を発射するとともに、発射したマイクロ波の反射波を受信することによって、発射したマイクロ波の周波数と受信したマイクロ波の周波数との差に基づいて動体を検出する。本実施形態においては、ドップラーセンサ124(より具体的には、出射部124a)は、ベース装置106の前方に向かって電波を照射する(図23参照)。本実施形態においては、ドップラーセンサ124の検出対象はユーザであり、ドップラーセンサ124によってユーザの体動を検出する。詳細は後述するが、検出される生体情報(換言すれば、ドップラーセンサ124の出力波形)に対して周波数分析等の解析を行うことで、体動の他、呼吸および脈拍といった生体情報をさらに算出することができる。
ベース装置106は、外部電源から電力を取得する電力取得部123を備える。本実施形態において、ベース装置106は、図示しない電源コードを介してACアダプタおよび電源プラグに接続(着脱可能でもよい)されている。電源プラグが外部電源のコンセントに接続されることによって、ベース装置106の電力取得部123に電力が供給される。ベース装置106は、電力取得部123によって取得される、外部電源からの電力によって動作する。また、電力取得部123は、供給された電力をコネクタ121を介して携帯端末105へ送ることで携帯端末105の充電を行う。なお、他の実施形態においては、ベース装置106は、電池を有していてもよく、電池に充電された電力を携帯端末105へ送るようにしてもよい。また、本実施形態においては、コネクタを介して電力が供給される態様で充電が行われるが、他の実施形態においては、非接触充電によって電力が供給されてもよい。
ベース装置106は、壁面(天井を含む)やスクリーンに画像を投影するプロジェクタ125を備える。プロジェクタ125は、ベース装置106から離れた面(凹凸があってもよい)に画像を投影することで当該面に画像を表示する任意の表示装置でよい。本実施形態においては、図23に示すように、プロジェクタ125は、投光部(具体的には、レンズ)125aが上方を向くように、すなわち、上方に向かって画像が投影されるようにベース装置106に設けられる。つまり、本実施形態においては、プロジェクタ125は、天井に画像を投影する。本実施形態において、プロジェクタ125は、例えば、ユーザに入眠や覚醒を促す画像(例えば、後述する入眠用コンテンツ等)を表示したり、ユーザが朝に覚醒した時に睡眠の評価結果を示す画像を表示したりしてもよい。
本実施形態においては、ベース装置106は、天井に投影する画像を、必要に応じて、いわゆるプロジェクションマッピングの技術を用いて補正する。すなわち、ベース装置106は、プロジェクタ125の投影面(すなわち、天井)の凹凸および/または色に応じた画像が表示されるように当該画像を補正する。なお、画像の補正方法は従来から用いられている方法であってよい。また、ベース装置106は、画像の補正を行うためのカメラ127を備える。図23に示すように、カメラ127は、プロジェクタ125によって画像が投影される場所を撮像範囲に含むような向きでベース装置106に設けられる。つまり、カメラ127は、プロジェクタ125と同じ方向(すなわち、上方)を向くように設けられる。
また、ベース装置106はスピーカ126を備える。スピーカ126は、例えば、ユーザに入眠や覚醒を促す音(例えば、後述する入眠用コンテンツ等)を出力するために用いられる。
ベース装置106は、ベース装置106の各部123~127を制御する制御部122を備える。制御部122は、ベース装置106の各部121,123~127に接続される。制御部122は、ベース装置106において実行される各種の制御処理を実行する。制御部122は、CPUおよびメモリを有する。ベース装置106においては、CPUがメモリを用いて、ベース装置106に記憶された情報処理プログラムを実行することによって上記各種の制御処理が実行される。例えば、制御部122は、電力取得部123を制御することによって、携帯端末105に対する充電動作を制御する。また、制御部122は、ベース装置においてユーザに提供するコンテンツや情報を、プロジェクタ125および/またはスピーカ126に再生させる。また、制御部122は、ドップラーセンサ124によって検出された情報を携帯端末105へ送信する。
なお、ベース装置106は、図22に示す構成に加えて、または代えて、他の構成を備えていてもよい。例えば、ベース装置106は、環境センサ、ディスプレイ、無指向性スピーカ、光源(例えば、照明)、および/または、におい発生装置等を備えていてもよい。なお、ベース装置106が環境センサを備える場合、携帯端末105は環境センサを備えていない構成であってもよい。また、携帯端末105およびベース装置106は、同種の環境センサ(すなわち、同じ情報を検出する環境センサ)を備えていてもよいし、異なる種類の環境センサを備えていてもよい。
なお、第2の実施形態におけるデータサーバ2およびサービスサーバ3(本実施形態の説明において単に「サーバ」と記載することがある)の構成は、第1の実施形態と同様である。したがって、第2の実施形態においても第1の実施形態と同様、端末システム100は健康情報をサーバへ送信し、サーバは健康情報に基づいて提供情報を生成して端末システム100へ送信する。ただし、第2の実施形態では、ユーザに提供すべき提供情報を決定する処理が端末システム100自身によっても実行される。そのため、第2の実施形態においては、サーバは提供情報を端末システム100へ送信する処理を実行しなくてもよい。
[2.端末システムにおける動作]
(2-1:端末システムにおける動作の概要)
次に、第2の実施形態における端末システム100における動作の概要について説明する。以下では、ユーザに提供される提供情報として、入眠用コンテンツとして再生される楽曲が提供される場合を例として説明する。なお、入眠用コンテンツとは、ユーザに入眠を促すための音楽および/または映像(静止画でも動画でもよい)である。つまり、本実施形態においては、ユーザの入床時に、ユーザに入眠を促すための楽曲が再生される。ここで、端末システム100は、再生すべき楽曲の候補(候補楽曲と呼ぶ)を示す情報をまずユーザに提示し、候補楽曲のうちからユーザが選択した楽曲を再生する。したがって、本実施形態においては、候補楽曲の情報が提供情報であると言うこともできるし、実際に再生される楽曲が提供情報であると言うこともできる。
また、端末システム100は、候補楽曲を決定するための決定ルールを予め記憶しており、当該決定ルールに従って候補楽曲を決定する。なお、決定ルールは、提供情報である候補楽曲の情報(あるいは実際に再生される楽曲)を決定するための条件であるので、上述した提供条件と言うことができる。ここで、本実施形態においては、決定ルールはユーザ毎に更新される。つまり、本実施形態においては、提供条件はユーザ毎に設定され、ユーザ毎にカスタマイズされる。以下、図24を参照して、端末システム100における処理の流れの概要を説明する。
図24は、第2の実施形態における端末システム100による処理の流れの一例を示す図である。図24は、ユーザが入床してからユーザが覚醒した後までの期間において端末システム100が実行する処理を示している。
第2の実施形態においても第1の実施形態と同様、端末システム100は、ユーザが入床する際に生体情報の計測を開始する(ステップS101)。具体的には、ユーザは、入床時に携帯端末105をベース装置106に装着する。端末システム100は、携帯端末105がベース装置106に装着されたことによって、ユーザが入床したと判別する(すなわち、入床を検知する)。入床が検知されたことに応じて、端末システム100は、ユーザの健康情報を算出するための計測を開始する。
第2の実施形態における健康情報の算出方法は第1の実施形態と同様であり、睡眠指標および疲労指標を含む健康情報が算出される。なお、第2の実施形態において、図4に示す各部の機能は携帯端末105が有するものとする。すなわち、第2の実施形態においては、ベース装置106から携帯端末105へ生体情報が送信され、携帯端末105が生体情報に基づいて健康情報を算出する。なお、他の実施形態においては、図4に示す各部の機能は携帯端末105に設けられてもよいし、ベース装置106に設けられてもよい。
なお、計測を開始する条件は任意である。例えば他の実施形態において、携帯端末105とベース装置106とが無線通信可能である場合、計測を開始する旨の指示が携帯端末105からベース装置106へ送信されたことに応じて、ベース装置106は計測を開始するようにしてもよい。また、ベース装置106は、所定時間間隔で、自身の周囲にユーザが存在するか否かを、例えばドップラーセンサ124を用いて判定し、ユーザが存在すると判定したことに応じて計測を開始してもよい。
次に、端末システム100は、上記の候補楽曲を示す情報をユーザに提供する処理を実行する(ステップS102)。本実施形態においては、携帯端末105は、それまでに算出された健康情報(すなわち、過去の睡眠期間に取得された生体情報に基づいて算出された健康情報)に基づいて候補楽曲を決定する。詳細は後述するが、携帯端末105は、最近1週間の睡眠の傾向を特定し、傾向に応じた候補楽曲を決定する。例えば、寝付きが悪い(睡眠潜時が長い)と傾向があると特定された場合には、寝付きが良くなる効果があると考えられる楽曲が候補楽曲として決定される。携帯端末105は、決定された候補楽曲を示す情報(例えば、楽曲のタイトル)を、提供情報としてユーザに提供する。具体的には、決定した候補楽曲を示す情報が、携帯端末105のディスプレイ117に表示される。
図25は、候補楽曲を示す情報を提供するために携帯端末105に表示される画像の一例を示す図である。図25に示すように、携帯端末105のディスプレイ117には、決定された候補楽曲を示す候補楽曲画像131が表示される。なお、本実施形態においては、候補楽曲として3つの楽曲(図25では、楽曲A~C)がユーザに提示される場合を例とするが、候補楽曲の数はいくつであってもよい。また、本実施形態においては、候補楽曲画像131とともに、ユーザに対するアドバイス情報を示すアドバイス画像132が表示される。アドバイス画像132については後述する。
ディスプレイ117に楽曲情報画像131が表示されると、ユーザは、候補楽曲のうちから所望の楽曲を選択する(ステップS103)。楽曲の選択は、例えば、ディスプレイ117に表示される候補楽曲のうち、所望の楽曲の項目にタッチする操作によって行われる。この操作に応じて、携帯端末105は、選択された楽曲の再生を開始する(ステップS104)。具体的には、携帯端末105は、楽曲の音データをベース装置106へ送信し、音データを受信したベース装置106はスピーカ126から楽曲を出力する。なお、他の実施形態においては、ベース装置106のスピーカ126と共に(または代えて)携帯端末105のスピーカ118から楽曲が再生されてもよい。
なお、携帯端末105が再生可能な楽曲のリスト(換言すれば、候補楽曲を選択するための楽曲のリスト)は、携帯端末105に記憶されていてもよいし、サーバに記憶されていてもよい。上記リストがサーバに記憶されている場合、携帯端末105は、適宜のタイミングで(例えば、上記ステップS102を実行するタイミングで)サーバからリストを取得する。また、上記リストに含まれる楽曲の音データは、携帯端末105に記憶されていてもよいし、サーバに記憶されていてもよい。楽曲の音データがサーバに記憶されている場合、携帯端末105は、例えば再生する楽曲が選択されたタイミングで、選択された楽曲の音データをサーバから取得する。
また、本実施形態においては、ユーザが睡眠中の期間(睡眠期間と呼ぶ)において、端末システム100は、当該期間中における生体情報(および健康情報)に基づいてユーザの睡眠状態を判別し、睡眠状態に応じて携帯端末105の動作を制御する。具体的には、携帯端末105は、取得された生体情報に基づいてユーザが入眠したか否かを判定する。そして、ユーザが入眠したと判定された場合、携帯端末105は、上記ステップS104で開始した楽曲の再生を停止する(ステップS105)。ユーザが入眠したため、楽曲を再生する必要性が低いからである。なお、他の実施形態においては、携帯端末105は、ユーザが入眠した時点から所定時間が経過したタイミングで楽曲の再生を停止してもよいし、ユーザが深い眠りについた(ノンレム睡眠の状態になった)と判定されたタイミングで楽曲の再生を停止してもよい。また、他の実施形態においては、楽曲は、ユーザの睡眠状態に応じて停止されなくてもよい。例えば、他の実施形態においては、楽曲の再生開始から所定時間が経過したタイミングで当該楽曲の再生が停止されてもよい。
また、他の実施形態においては、端末システム100は、楽曲の再生の制御に限らず、他の動作を制御してもよい。例えば、他の実施形態においては、端末システム100は、ユーザの睡眠状態に応じて、携帯端末105の状態を変更する(例えば、電源をオフにする、待機状態にする、マナーモードにする等)制御を行ってもよい。
ユーザが覚醒すると、端末システム100は、今回の睡眠期間における健康情報を算出する(ステップS106)。上述したように、端末システム100は、第1の実施形態と同様の方法で、今回の睡眠期間において取得された生体情報に基づいて健康情報を算出する。なお、ユーザが覚醒したことは、生体情報に基づいて判別することができる。
次に、携帯端末105は、ユーザに対する質問を生成し、生成した質問をユーザに提示する(ステップS107)。詳細は後述するが、質問は、ステップS106で算出された健康情報に基づいて生成される。例えば、携帯端末105は、算出された健康情報から、中途覚醒回数がいつもより多い(すなわち、今回算出された中途覚醒回数と平均値との差が大きい)と判別される場合には、「ぐっすり眠れましたか?」といった質問を行う。また例えば、いつもよりもユーザの疲労度が高い場合には、携帯端末105は、「疲れは取れましたか?」といった質問を行う。
図26は、覚醒時に携帯端末105に表示される画像の一例を示す図である。図26に示すように、ユーザが覚醒した際には、評価結果画像135と質問画像136とがディスプレイ117に表示される。
評価結果画像135は、今回の睡眠期間における睡眠および疲労に関する評価結果を表す。具体的には、評価結果画像135は、生体情報(および健康情報)に基づいて算出された評価結果である、快眠度および元気度を表す。快眠度は、快眠の度合い(睡眠の質とも言える)を示す指標(具体的には数値)である。快眠度の算出方法は任意であるが、例えば、数値が大きいほど良い状態を表すように、上述の睡眠指標に基づいて算出される。また、元気度は、ユーザの健康状態(本実施形態においては、睡眠の状態、および、疲労の度合い)をユーザにとってわかりやすく提示する目的で算出される数値である。元気度は、例えば上述の疲労度に基づいて算出され、数値が大きいほど良い状態(換言すれば、疲労度が小さい)を表す。元気度の算出方法は任意であり、例えば、元気度は、100から疲労度を減算することによって算出されてもよい。このように、本実施形態においては、健康情報に関する評価結果として、快眠度および元気度が算出される。なお、このような快眠度および元気度も健康情報の一種である。本実施形態においては、健康情報に関する評価結果が覚醒時にユーザに提示されるので、ユーザは、起きてすぐに評価結果を知ることができる。
また、質問画像136は、ステップS107で生成された質問を表す。図26においては、「ぐっすり眠れましたか?」という質問を表す質問画像136が生成されて表示されている。また、本実施形態においては、質問画像136は、ユーザが回答を行うためのボタン画像(具体的には、「はい」および「いいえ」を表すボタン画像)を含む。なお、ユーザの回答はどのような形式で行われてもよく、例えば、2種類以上の選択肢から回答を選択させる形式であってもよいし、数値を入力させる形式であってもよい。
質問画像136がディスプレイ117に表示された場合、ユーザは、質問に対する回答を入力する(ステップS108)。本実施形態においては、ユーザは、質問画像136に含まれるボタン画像を指定する入力(具体的には、タッチする入力)を行うことによって回答を行う。
回答が入力されたことに応じて、携帯端末105は、上記の決定ルールを更新する(ステップS109)。詳細は後述するが、決定ルールの更新は、ステップS106で算出された健康情報と、ステップS108で入力されたユーザの回答とに基づいて行われる。例えば、健康情報が健康状態が良いことを示すものであったり、ユーザの入力が健康状態が良いことを示す回答であったりする場合には、入眠時に再生された入眠用コンテンツの楽曲がユーザにとって効果があった(あるいは、効果が大きかった)と判断することができる。そのため、この場合には、当該楽曲が選択されやすくなるように決定ルールが更新される。一方、健康情報が悪い状態を示すものであったり、ユーザの入力が健康状態が悪いことを示す回答であったりする場合には、入眠時に再生された入眠用コンテンツの楽曲がユーザにとって効果がなかった(あるいは、効果が小さかった)と判断することができる。そのため、この場合には、当該楽曲が選択されにくくなるように決定ルールが更新される。
以上のように、第2の実施形態においては、端末システム100は、健康情報に基づいて決定される候補楽曲の情報をユーザに提供することができる(ステップS102)。これによって、端末システム100は、入眠用コンテンツとして、健康情報に基づく適切な楽曲をユーザに対して勧めることができる。
さらに、第2の実施形態においては、端末システム100は、睡眠から覚醒した後で、提供された楽曲について効果(具体的には、効果の有無や効果の程度)を判別する(ステップS106,S107)。楽曲を決定するための決定ルールは、判別結果に応じて更新される。決定ルールは、個別のユーザの健康情報および個別のユーザの回答に基づいて更新されるので、決定ルールはユーザ毎にカスタマイズされていく。これによれば、端末システム100は、個別のユーザに適した提供情報を提供することができ、個別のユーザにとって有用な情報を提供することができる。
(2-2:楽曲提供処理)
次に、端末システム100において実行される、楽曲提供処理(上記ステップS102~S104)の具体例について説明する。上述のように、楽曲提供処理は、ユーザの入眠時に再生する楽曲(および候補楽曲)を提供する処理である。
図27は、端末システム100の機能的構成の一例を示す機能ブロック図である。本実施形態においては、楽曲提供処理を実行するための構成として、端末システム100は、分析部151と、健康情報記憶部152と、ジャンル決定ルール記憶部153と、楽曲決定ルール記憶部154とを備える(質問提示部155および更新部156については後述する)。本実施形態において、上記各部151~154は、携帯端末105の処理部111および/または記憶部(不図示)によって実現される。具体的には、分析部151は、処理部111が所定の情報処理プログラムを実行することによって実現される。また、各記憶部152~154は、上記所定の記憶部によって実現される。上記所定の記憶部は、処理部111がアクセス可能な任意の記憶媒体であり、携帯端末105に内蔵される記憶媒体であってもよいし、携帯端末105に着脱可能な外部記憶媒体であってもよい。
分析部151は、ユーザの健康に関する分析を当該ユーザの生体情報に基づいて行い、分析結果に基づく情報(候補楽曲の情報、および、再生される楽曲)の提供を当該ユーザに対して行う。図27に示すように、分析部151は、健康情報算出部161と、状態特定部162と、ジャンル決定部163と、楽曲決定部164と、情報提供部165とを含む。
健康情報算出部161は、ベース装置106において検出された生体情報を取得し、取得された生体情報に基づいて健康情報を算出する。健康情報を算出する方法は、第1の実施形態と同様である。算出された健康情報は、健康情報記憶部152へ出力される。
健康情報記憶部152は、ベース装置106において検出された生体情報と、健康情報算出部161によって算出された健康情報とを記憶する。健康情報記憶部152は、最新のものから過去に所定の保存期間(例えば、3月)に取得された生体情報および健康情報を記憶する。したがって、生体情報および健康情報が取得された場合、健康情報記憶部152は、上記保存期間中の情報が保存されるように、情報を更新する。なお、本実施形態においては、健康情報記憶部152は、検出された生体情報および算出された健康情報の全ての種類を記憶する必要はなく、これらの生体情報および健康情報のうちで、候補楽曲を決定するために用いる情報を記憶してもよい。
状態特定部162は、ユーザに関する健康情報に基づいて、当該ユーザの健康状態を特定(推測とも言える)する。本実施形態においては、状態特定部162は、ユーザの健康状態として、所定期間(例えば、最近1週間)における睡眠の傾向を算出する。具体的には、状態特定部162は、健康情報記憶部152から健康情報を取得し、取得された健康情報に基づいて、最近1週間の、入眠潜時の平均と中途覚醒回数の平均とを少なくとも算出する。なお、健康状態として算出される情報は任意である。状態特定部162は、例えば、入眠潜時および中途覚醒回数以外の他の睡眠指標に関する状態を算出してもよいし、疲労に関する状態を算出してもよい。また、健康状態として算出される情報は、本実施形態のように、ユーザの最新の健康情報(例えば、最新の1回の睡眠に応じて算出される健康情報)と過去の健康情報とに基づいて算出されてもよいし、他の実施形態においては、ユーザの最新の健康情報に基づいて算出されてもよい。また、健康状態として算出される情報は、ユーザの健康情報と、他のユーザの健康情報とに基づいて算出されてもよい。例えば、他の実施形態においては、状態特定部162は、ユーザの健康情報(例えば、上記睡眠潜時)と、他のユーザの健康情報から得られる情報(例えば、他のユーザに関する入眠潜時の平均値)との比較に基づく情報(例えば、ユーザの睡眠潜時と平均値との差)を、上記健康状態として算出してもよい。なお、他のユーザの健康情報は、サーバから適宜のタイミングで端末システム100に取得されてよい。
ジャンル決定部163は、状態特定部162によって特定された健康状態に基づいて、ユーザに提供するべき候補楽曲のジャンルを決定する。ここで、本実施形態においては、上述した携帯端末105が再生可能な各楽曲には、楽曲毎にジャンルがそれぞれ設定されている。すなわち、再生可能な楽曲のリストには、楽曲の識別情報と、当該楽曲のジャンルを示す情報とが関連付けられている。ジャンル決定部163は、上記各楽曲に設定されている複数種類のジャンルのうちから、所定数(ここでは1種類)のジャンルを決定する。
ジャンルの決定は、ジャンル決定ルールを用いて行われる。ジャンル決定ルール記憶部153は、上記ジャンル決定ルールを記憶している。図28は、ジャンル決定ルールの一例を示す図である。本実施形態においては、図28に示すように、ジャンル決定ルールは、睡眠の傾向に関する条件(睡眠条件)と、ジャンルに付された重みの設定内容とを関連付けた情報である。なお、図示しないが、ジャンル決定ルールは、ジャンルと、当該ジャンルに対して予め付された基準の重み値とをジャンル毎に関連付けた情報を含む。
ジャンル決定部163は、特定された健康情報が、ジャンル決定ルールに含まれる睡眠条件を満たすか否かを睡眠条件毎に判定し、満たされた睡眠条件に関連付けられる設定内容を特定する。ジャンル決定部163は、特定された設定内容に従って、ジャンルに付される重み値を変更する。例えば、図28に示す例において、特定された健康情報が、睡眠潜時が15分以下で、かつ、中途覚醒回数が1~3回であることを示す場合、ジャンルAの重み値を0.5だけ加算する設定内容と、ジャンルDの重み値を0.5だけ加算する設定内容が特定される。その結果、ジャンルAおよびジャンルDの重み値がそれぞれ0.5だけ増加される。
上記のように、本実施形態においては、予め設定された基準の重み値に対して、ジャンル決定ルールを用いて変更が加えられる。ジャンル決定部163は、このようにして変更が加えられた重み値に基づいて、ジャンルを決定する。重み値に基づいてジャンルを決定する方法は任意である。例えば、ジャンル決定部163は、重み値が最大となるジャンルを選択してもよい。また例えば、ジャンル決定部163は、重み値に応じた確率でジャンルが選択されるように、乱数を用いてジャンルを決定してもよい。これによれば、ジャンルの決定にランダム性を持たせることができ、多くの種類のジャンルが選択される可能性を高めることができる。すなわち、携帯端末105は、多くの種類のジャンルの楽曲をユーザに対して提示することができる。
楽曲決定部164は、ジャンル決定部163によって決定されたジャンルに含まれる楽曲のうちから候補楽曲を決定する。候補楽曲は、楽曲決定ルールを用いて決定される。楽曲決定ルール記憶部154は、楽曲決定ルールを記憶している。楽曲決定ルールは、携帯端末105が再生可能な各楽曲と、楽曲に付された重みとを楽曲毎に関連付けたテーブルを含む。図29は、楽曲決定ルールに含まれるテーブルの一例を示す図である。本実施形態においては、図29に示すように、テーブルにおいて各楽曲について重み値が関連付けられている。また、各楽曲についてジャンルが関連付けられている。
楽曲決定部164は、決定されたジャンルに含まれる各楽曲のうちから、当該各楽曲に付された重み値に基づいて候補楽曲(本実施形態では3つの候補楽曲)を選択する。重み値に基づいて候補楽曲を選択する方法は任意である。例えば、楽曲決定部164は、決定されたジャンルに含まれる各楽曲のうちから、重み値が大きいものから順に所定数(ここでは3つ)の楽曲を候補楽曲として選択してもよい。また例えば、楽曲決定部164は、決定されたジャンルに含まれる各楽曲のうちから重み値に応じた確率で楽曲が選択されるように、乱数を用いて所定数の楽曲を選択してもよい。これによれば、楽曲の決定にランダム性を持たせることができ、多くの種類の楽曲が選択される可能性を高めることができる。すなわち、携帯端末105は、多くの種類の楽曲をユーザに対して提示することができる。
情報提供部165は、楽曲決定部164によって決定された候補楽曲の情報(例えば、楽曲のタイトル)をユーザに提供する。具体的には、楽曲決定部164は、候補楽曲画像131(図25参照)をディスプレイ117に表示する。なお、本実施形態においては、候補楽曲画像131は、候補楽曲のタイトルに加えて、例えば「寝付きの悪い人におすすめ!」といったリコメンド情報を含む(図25参照)。また、候補楽曲画像131とともに、アドバイス情報を表すアドバイス画像132が表示される(図25参照)。これらのリコメンド情報およびアドバイス情報の内容は、例えば、状態特定部162によって特定された健康状態に基づいて決定される。例えば、携帯端末105は、健康状態に関する条件と、提示すべきリコメンド情報およびアドバイス情報の内容とを関連付けたテーブルを予め記憶しておき、当該テーブルを用いてこれらの情報の内容を特定する。すなわち、携帯端末105は、テーブルに含まれる条件のうちで、上記健康状態によって満たされた条件に関連付けられるリコメンド情報およびアドバイス情報の内容を特定する。このようにして特定された情報の内容がリコメンド情報およびアドバイス情報としてディスプレイ117に表示される。
さらに、情報提供部165は、候補楽曲のうちから1つを選択するユーザ入力を受け付け、ユーザによって選択された楽曲を、入眠用コンテンツとして再生すべき楽曲に決定する。そして、情報提供部165は、決定された楽曲の音データを取得し、スピーカ118を用いて当該楽曲を再生する。これによって、入眠用コンテンツとして楽曲がユーザに提供される。
(2-3:決定ルールの更新処理)
次に、図27を参照して、端末システム100において実行される、決定ルールの更新処理の具体例について説明する。決定ルールの更新処理は、入眠用コンテンツである楽曲の効果(具体的には、ユーザの健康状態を改善する効果)を判別し、判別結果に応じて決定ルールを更新する処理である。本実施形態においては、決定ルールの更新処理を実行するための構成として、端末システム100は、上記の健康情報算出部161と、質問提示部155と、更新部156とを備える。本実施形態において、上記各部155および156は、携帯端末105の処理部111が所定の情報処理プログラムを実行することによって実現される。
上述のように、ユーザの覚醒時において、健康情報算出部161は、今回の睡眠期間(すなわち、当該覚醒前の睡眠期間、換言すれば、覚醒時が終期となる睡眠期間)中に取得された生体情報に基づいて健康情報を算出する(図24に示すステップS106)。
質問提示部155は、健康情報算出部161によって算出された健康情報に基づいて、ユーザに対する質問を提示する(図24に示すステップS107)。本実施形態においては、質問提示部155は、予め用意された複数の質問のうちから、健康情報に基づいて1つを選択する。提示する質問を決定する方法は任意であるが、本実施形態においては、健康情報に関する条件と質問とを関連付けたテーブルを用いる。
図30は、ユーザに提示する質問を決定するためのテーブルの一例を示す図である。図30に示すように、テーブルは、健康情報に関する条件と、当該条件を満たした場合に提示される質問とを関連付けるものである。質問提示部155は、テーブルに含まれる条件のうちで、算出された健康情報によって満たされる条件を特定し、特定された条件に関連付けられる質問を選択する。図30に示す例においては、例えば、今回の睡眠期間における中途覚醒回数が、平均値(例えば、最近1週間の平均値)と比べて1回以上の差がある場合、「ぐっすり眠れましたか?」という質問が選択される。
なお、質問を決定する方法は、本実施形態のように、ユーザに関する最新の健康情報と過去の健康情報とに基づく方法であってもよいし、他の実施形態においては、ユーザに関する最新の健康情報に基づく方法であってもよい。また、質問は、ユーザの健康情報と、他のユーザの健康情報とに基づいて決定されてもよい。例えば、他の実施形態においては、質問提示部155は、ユーザの健康情報(例えば、上記中途覚醒回数)と、他のユーザの健康情報から得られる情報(例えば、他のユーザに関する中途覚醒回数の平均値)との比較に基づく情報(例えば、ユーザの中途覚醒回数と平均値との差)に基づいて質問を決定してもよい。
質問提示部155は、選択された質問を表す質問画像136を生成してディスプレイ117に表示する。なお、選択された質問が複数となる場合、そのうちの所定数(例えば1つ)の質問のみがユーザに提示されてもよいし、選択された全ての質問が提示されてもよい。上述のように、質問が提示されると、ユーザは、質問に対する回答を入力する(図24に示すステップS108)。
更新部156は、上記質問に対するユーザの回答入力を取得する。また、更新部156は、健康情報算出部161によって算出された健康情報を取得する。更新部156は、上記の健康情報とユーザの回答とに基づいて、決定ルールのうちの楽曲決定ルールを更新する。本実施形態においては、楽曲決定ルールの更新は、上述した条件更新テーブルの一例であるルール更新テーブルを用いて行われる。ルール更新テーブルは、例えば楽曲決定ルール記憶部154に記憶される。
図31は、更新内容を決定するためのルール更新テーブルの一例を示す図である。図31に示すように、ルール更新テーブルは、健康情報またはユーザの回答に関する条件と、当該条件を満たした場合に実行される更新内容とを関連付けるものである。更新部156は、ルール更新テーブルに含まれる条件のうちで、健康情報またはユーザの回答によって満たされる条件を特定し、特定された条件に関連付けられる更新内容を特定する。図31に示す例においては、例えば、睡眠時間が平均値(例えば最近1週間の平均睡眠時間)以上である場合、重み値を0.1加算することを示す更新内容が特定される。なお、更新部156は、満たされる条件が複数存在する場合は、それぞれの条件に関連付けられる複数の更新内容を特定する。
なお、更新内容を決定する方法は、本実施形態のように、ユーザに関する最新の健康情報と過去の健康情報とに基づく方法であってもよいし、他の実施形態においては、ユーザに関する最新の健康情報に基づく方法であってもよい。また、更新内容は、ユーザの健康情報と、他のユーザの健康情報とに基づいて決定されてもよい。例えば、他の実施形態においては、更新部156は、ユーザの健康情報(例えば、上記睡眠時間)と、他のユーザの健康情報から得られる情報(例えば、他のユーザに関する睡眠時間の平均値)との比較に基づく情報(例えば、ユーザの睡眠時間と平均値との差)に基づいて更新内容を決定してもよい。
更新部156は、特定された更新内容に従って、楽曲決定ルール記憶部154に記憶される楽曲決定ルールを更新する。具体的には、上述の楽曲決定ルールに含まれるテーブル(図29参照)における、更新対象となる楽曲に関連付けられる重み値を、特定された更新内容に従って増加または減少させる。なお、「更新対象となる楽曲」は、今回の睡眠期間において入眠用コンテンツとして再生された楽曲である。
なお、上記ルール更新テーブルは、健康情報が良い状態を示す条件、または、ユーザの回答が健康状態が良いことを示す条件に対して、重み値を増加させる(すなわち、更新対象となる楽曲が選択されやすくなる)ような更新内容を関連付ける(図31参照)。また、上記ルール更新テーブルは、健康情報が悪い状態を示す条件、または、ユーザの回答が健康状態が悪いことを示す条件に対して、重み値を減少させる(すなわち、更新対象となる楽曲が選択されにくくなる)ような更新内容を関連付ける。したがって、本実施形態によれば、入眠用コンテンツとして再生された楽曲がユーザの睡眠を改善する効果があると推測される場合には、今後において当該楽曲が候補楽曲として提供されやすくなる。一方、入眠用コンテンツとして再生された楽曲がユーザの睡眠を改善する効果がないと推測される場合には、今後において当該楽曲が候補楽曲として提供されにくくなる。
なお、他の実施形態においては、決定ルールの更新は、今回の睡眠期間に関する健康情報(すなわち、新たな健康情報)に加えて、過去に算出された健康情報に基づいて行われてもよい。例えば、携帯端末105は、新たな健康情報と過去の健康情報とに基づいて、ユーザの健康状態が改善したか否かを判定し、判定結果に応じて更新内容を決定してもよい。具体的には、携帯端末105は、ユーザの健康状態が改善したと判定された場合には、更新対象となる楽曲の重み値を増加させ、ユーザの健康状態が改善していないと判定された場合には、更新対象となる楽曲の重み値を減少させてもよい。
本実施形態においては、更新部156は、算出された健康情報およびユーザの回答に基づいて決定ルールの更新を行ったが、他の実施形態においては、健康情報およびユーザの回答のいずれか一方に基づいて更新を行ってもよい。また、他の実施形態においては、更新部156は、楽曲決定ルールと共に(または代えて)ジャンル決定ルールを更新してもよい。
また、決定ルールの更新方法は任意である。他の実施形態においては、更新部156は、決定ルールに含まれる更新内容(具体的には重み値)を変更することに代えて(または共に)、決定ルールに含まれる条件を変更してもよい。例えば、更新部156は、当該条件に含まれる閾値(例えば、図28に示すジャンル決定ルールに含まれる睡眠条件における閾値)を変更してもよい。例えば、上記睡眠条件において、ユーザが睡眠不足であることを判断するための睡眠条件として、「睡眠時間が6時間以下」という条件が設定されている状況を考える。この状況において、実際の睡眠時間が6時間以下であるにもかかわらず、算出された健康情報(または、入力されたユーザの回答)が、健康状態が良いことを示す場合、更新部156は、「睡眠時間が6時間以下」という条件における閾値である“6時間以下”を、例えば“5時間50分”に変更してもよい。
以上のように、本実施形態においては、提供情報の内容を決定したり、提供ルールを更新したりする手段として、図28~図31に示すようなテーブルを用いる例を説明した。ここで、提供情報の内容を決定したり、提供ルールを更新したりする手段は任意である。例えば、提供情報の内容の決定は、分析エンジンによって実行されてもよい。分析エンジンは、例えば、(1)健康情報に基づく睡眠・疲労の解析、(2)解析に基づく特徴部分(問題点や良い点)の評価、(3)特徴部分が生じた原因の推測、および、(4)原因に対する解決策の提供、を所定のアルゴリズムによって行う。このとき、提供ルールの更新は、上記分析エンジンのプログラムを更新する(換言すれば、アルゴリズムを更新する)ことによって行われてもよい。
[3.端末システムにおける処理の具体例]
次に、第2の実施形態における端末システムにおいて実行される処理の具体例について説明する。図32は、携帯端末105において実行される処理の流れの一例を示すフローチャートである。本実施形態において、図32に示す一連の処理は、ユーザが入床したと検知されたこと、すなわち、携帯端末105がベース装置106に装着されたことに応じて開始される。なお、他の実施形態においては、上記一連の処理は、携帯端末105とベース装置106との通信が開始されたことに応じて開始されてもよいし、ユーザが携帯端末105またはベース装置106に対して所定の開始操作を行ったことに応じて開始されてもよい。
まずステップS120において、携帯端末105は、開始時処理を実行する。開始時処理は、図32に示す一連の処理の開始に応じて(本実施形態では、ベース装置106に携帯端末105が装着されたことに応じて)実行される処理である。具体的には、端末システム100は、健康情報を算出するための生体情報を検出するセンサ(すなわち、ドップラーセンサ124)による検出を開始する(上記ステップS151)。すなわち、携帯端末105の処理部111は、ベース装置106に対して、検出動作を開始する旨の指示を行う。この指示に応じて、ベース装置106の制御部122は、ドップラーセンサ124に検出動作を開始させる。
また、ステップS120の開始時処理が実行される際に(換言すれば、携帯端末105がベース装置106に装着されたことに応じて)、ベース装置106は、充電開始処理を実行する。充電開始処理において、ベース装置106は、携帯端末105に対する充電を開始する。具体的には、制御部122は、充電を開始する旨の指示を電力取得部123に対して行う。この指示に応じて、電力取得部123は、外部電源から供給される電力を、コネクタ121を介して携帯端末105へ供給する。なお、ベース装置106は、外部電源に接続された状態(すなわち、電源プラグがコンセントに接続された状態)であるとする。なお、ベース装置106は、携帯端末105の電池残量を確認し、電池残量が所定量以下であることを条件として充電動作を開始するようにしてもよい。充電動作は、携帯端末105の電池が容量まで充電されたことに応じて終了する。
ステップS121において、携帯端末105は、上述の楽曲提供処理(ステップS102~S104)を実行する。これによって、入眠用コンテンツである楽曲の再生が開始される。
上記ステップS121の処理の後、以下に説明するステップS122~S125の処理が、ユーザの睡眠期間中において繰り返し実行される。なお、本実施形態においては、ステップS122~S125の処理ループは、所定時間に1回の割合で実行される。
ステップS122において、携帯端末105は、ドップラーセンサ124の検出結果(すなわち、生体情報)を取得する。上記ステップS120の処理によって検出動作を開始したドップラーセンサ124は、検出結果(具体的には、出力波形)を制御部122へ出力する。制御部122は、検出結果を携帯端末105へ送信する。これによって、ドップラーセンサ124の検出結果が携帯端末105に取得される。なお、制御部122は、ドップラーセンサ124の検出結果の情報をそのまま携帯端末105へ送信してもよいし、検出結果に何らかの加工(例えば、検出結果の信号に含まれるノイズを除去する処理や、上記睡眠指標を算出する処理等)を行って携帯端末105へ送信してもよい。
ステップS123において、携帯端末105は、睡眠情報(例えば、各種睡眠指標)を算出する。すなわち、処理部111は、ステップS122で取得された検出結果(すなわち、生体情報)に基づいて、各種睡眠指標を算出する。睡眠指標の算出は、第1の実施形態と同様の方法によって行われる。なお、ステップS123においては、処理部111は、後述するステップS124およびS125においてユーザの睡眠状態を判別するために用いられる睡眠情報を算出すればよい。ステップS123においては、処理部111は、睡眠期間が終了した時点でなければ算出できない睡眠指標(例えば、総睡眠時間)、疲労情報(換言すれば、疲労度)、および、元気度を算出しなくてもよい。
ステップS124において、携帯端末105は、ユーザの睡眠状態に応じた情報処理を実行する。すなわち、処理部111は、ユーザの睡眠状態が所定の状態となったか否かを判定する。そして、所定の状態となったと判定された場合、携帯端末105(およびベース装置106)の動作、動作モード、および/または、設定が制御される。本実施形態においては、処理部111は、ユーザが入眠したと判定された場合、上記ステップS121で開始した楽曲の再生を停止する(図24に示すステップS105参照)。
ステップS125において、携帯端末105は、ユーザが覚醒したか否かを判定する。すなわち、処理部111は、ステップS122で取得される生体情報、および/または、ステップS123で算出される睡眠指標に基づいて、ユーザが覚醒したか否かを判定する。ユーザが覚醒したと判定された場合、ステップS126~S129の一連の処理が実行される。一方、ユーザが覚醒していないと判定された場合、ステップS122の処理が再度実行される。すなわち、ユーザが覚醒したと判定されるまで、ステップS122~S125の一連の処理が繰り返し実行される。
ステップS126において、携帯端末105は、睡眠期間中に取得された生体情報に基づいて健康情報を算出する(図24に示すステップS106)。健康情報の算出は、第1の実施形態と同様の方法によって行われる。
ステップS127において、携帯端末105は、ステップS126で算出された健康情報に基づいて質問をユーザに提示し(図24に示すステップS107)、当該質問に対する回答の入力をユーザから受け付ける(図24に示すステップS108)。すなわち、処理部111は、上述の質問画像136をディスプレイ117に表示し、上記回答の入力を操作入力部112から取得する。
ステップS128において、携帯端末105は、ステップS126で算出された健康情報と、ステップS127で入力されたユーザの回答とに基づいて、決定ルールを更新する(図24に示すステップS109)。
ステップS129において、携帯端末105は、ステップS126で算出された健康情報をサーバへ送信する。すなわち、処理部111は、算出された健康情報を通信部110によってサーバへ送信する。これによって、1回の睡眠期間に対する健康情報がサーバへ送信され、サーバにおいて保存されることになる。このように、本実施形態においては、携帯端末105は、送信すべき情報を自動的にサーバへ送信する。つまり、ユーザが指示を行わなくても、サーバへ情報がアップロードされる。
上記ステップS129の後、携帯端末105は、図32に示す一連の処理を終了する。このとき、処理部111は、ベース装置106に対して、検出動作を停止する旨の指示を行う。この指示に応じて、ベース装置106の制御部122は、ドップラーセンサ124に検出動作を停止させる。
なお、本実施形態においては、上記睡眠期間中において、何らかの理由で携帯端末105がベース装置106から外された場合(例えば、ユーザが寝返りをうった際に携帯端末105に当たってしまった場合)、ベース装置106は、ドップラーセンサ124の検出結果を携帯端末105へ送信することができない。この場合、ベース装置106は、携帯端末105へ送信することができなかった検出結果のデータを自身の記憶部(例えば、メモリ等)に記憶しておく。そして、次に携帯端末105がベース装置106に装着されたことに応じて、ベース装置106は、記憶部に記憶されている検出結果のデータを携帯端末105へ送信する。上記データを受信した携帯端末105は、検出結果に基づいて睡眠指標を算出する(ステップS123)。なお、携帯端末105は、このとき算出された睡眠指標に基づく制御処理(ステップS124)を実行しなくてよい。このとき算出された睡眠指標は、過去の検出結果に基づくものであるからである。
また、算出された睡眠指標に基づいて、ユーザが覚醒していると判定された場合(ステップS125の判定結果が肯定となる場合)、携帯端末105は、上記ステップS126~S129の処理を実行する。このように、ユーザの睡眠中に携帯端末105がベース装置106から外された場合であっても、次に携帯端末105がベース装置106に装着されると、決定ルールの更新が行われるとともに、健康情報がサーバへ送信される。したがって、例えば、ユーザが覚醒した時に、携帯端末105がベース装置106から外れていたことに気づいた場合には、ユーザは、携帯端末105をベース装置106に装着するとよい。これによって、端末システム100は、決定ルールの更新を行うことができるとともに、健康情報をサーバへ送信することができる。
なお、他の実施形態において、携帯端末105とベース装置106とが無線通信可能である場合には、携帯端末105がベース装置106から外れた場合であっても、上記ステップS122~S125の処理を継続して実行することができる。
なお、携帯端末105は、図32に示す処理の他、第1の実施形態における主端末装置10が通常モードにおいて実行する処理と同様の処理を実行してもよい。すなわち、携帯端末105はサービスサーバ3にアクセスして、ユーザの健康情報をディスプレイ16に表示したり、サービスサーバ3から提供される提供情報をディスプレイ16に表示したりしてもよい。
[4.第2の実施形態における変形例]
(複数のユーザの健康情報に基づく更新を行う変形例)
上記第2の実施形態においては、更新条件である決定ルールは、端末システム100のユーザ個人の健康情報に基づいて更新された。ここで、他の実施形態においては、決定ルールは、複数のユーザの健康情報に基づいて更新されてもよい。また、上記第2の実施形態においては、決定ルールは、携帯端末105のユーザ用に更新された。つまり、決定ルールは、端末システム100のユーザ個人にのみ用いられるものであった。ここで、他の実施形態においては、決定ルールは、複数のユーザについて共通の部分を含んでいてもよい。以下、第2の実施形態における変形例として、決定ルールの一部が、複数のユーザに対して共通に用いられ、複数のユーザの健康情報に基づいて更新される例について説明する。
図33は、第2の実施形態の変形例における端末システム100の機能的構成の一例を示す機能ブロック図である。図33においては、決定ルールの更新処理を実行するための構成として、端末システム100は、上記の健康情報算出部161と、質問提示部155と、第1更新部171と、第2更新部172とを備える。なお、図33において、図32と同じ参照符号が付された構成要素は、図32と同じであり、これらの構成要素については詳細な説明を省略する。
第1更新部171は、第2の実施形態における更新部156と同じである。本変形例においては、端末システム100は、第1更新部171に加えて第2更新部172を備える。本変形例において、上記各部171および172は、携帯端末105の処理部111が所定の情報処理プログラムを実行することによって実現される。
第2更新部172は、決定ルールのうちのジャンル決定ルールを更新する。本変形例において、ジャンル決定ルールは、複数のユーザの健康情報に基づいて更新される。具体的には、サーバは、提供条件としてジャンル決定ルールを記憶しておくとともに、第1の実施形態と同様に、各端末システムから受信した健康情報をユーザ毎に記憶する。また、サーバは、健康情報とともに、入眠用コンテンツとして再生された楽曲を示す情報を各端末システムから受信し、健康情報に関連付けて記憶する。サーバは、所定のタイミングで、複数のユーザに関する健康情報に基づいて、ジャンル決定ルールを更新する。
上記所定のタイミングは任意であり、例えば、サーバの管理者(ネットワークサービスの管理者)が決定するタイミングであってもよい。また例えば、上記所定のタイミングは、上述の“(提供条件を自動的に更新する変形例)”で述べたような、サーバにおいて設定されるデータ数条件および/または変更条件が満たされたタイミングであってもよい。例えば、サーバは、あるジャンルの楽曲が関連付けられる健康情報が所定数だけ取得されたタイミングを上記所定のタイミングとしてもよい。
また、ジャンル決定ルールの更新の内容は任意である。本変形例においては、サーバは、あるジャンルの楽曲が関連付けられる健康情報に基づいて、当該あるジャンルの楽曲の効果を判断し、効果に応じてジャンル決定ルールを更新する。例えば、図28に示すジャンル決定ルールを例として説明すると、ジャンルCの楽曲が関連付けられる健康情報に基づいて、入眠潜時が短くなるように改善された効果があると判断される場合、サーバは、ジャンルCの重み値に対する加算値(図28では“+1”)を増加させる。上記のように、サーバは、入眠用コンテンツとしての楽曲の効果として、健康情報の履歴(すなわち、複数回の睡眠期間における健康情報)に基づいて、健康状態が改善したか否かを表す情報を算出してもよい。
ジャンル決定ルールを更新した場合、サーバは、更新内容を示す情報を含む更新通知を各端末システムへ送信する。各端末システムは、更新通知に従って、自身に記憶されているジャンル決定ルールを更新する。すなわち、サーバからの更新通知が端末システム100において受信されると、第2更新部172は、更新通知が示す更新内容に従って、ジャンル決定ルール記憶部153に記憶されているジャンル決定ルールを更新する。これによって、サーバに記憶されるジャンル決定ルールと、端末システム100に記憶されるジャンル決定ルールとの内容を同期させることができる。
なお、サーバは、ネットワークサービスの全てのユーザに対して適用されるジャンル決定ルールを記憶していてもよいし、ネットワークサービスのユーザのうち、所定のグループに属するユーザに適用されるジャンル決定ルールを記憶していてもよい。所定のグループとは、例えば、性別、年齢、住所、および/または、趣味嗜好等に応じてユーザを区分するグループである。サーバが、上記グループに対応するジャンル決定ルールを記憶しており、当該ジャンル決定ルールを更新する場合には、サーバは、当該グループに属するユーザの端末システムへ更新通知を送信する。このとき、当該グループに属しないユーザの端末システムへは更新通知は送信されない。
(ルールに関する変形例)
上記変形例においては、上記楽曲決定ルールがユーザ毎の健康情報に基づいてユーザ毎に更新され、上記ジャンル決定ルールが複数のユーザの健康情報に基づいて更新された。ここで、他の実施形態においては、端末システム100は、ユーザ毎の健康情報と、複数のユーザの健康情報との両方に基づく任意の方法でルールの更新を行ってよい。例えば、他の実施形態においては、以下の方法によってルールの更新が行われてもよい。
図34は、第2の実施形態の他の変形例における端末システムの機能的構成の一例を示す機能ブロック図である。なお、図34においては、端末システムの機能的構成の一部のみを示し、図27または図33と同じ部分については構成を省略している。図34に示すように、本変形例においては、分析部151は、ジャンル決定部163および楽曲決定部164に代えて、第1楽曲決定部181および第2楽曲決定部183を備える。また、端末システム100は、楽曲決定ルール記憶部154およびジャンル決定ルール記憶部153に代えて、第1楽曲決定ルール記憶部182および第2楽曲ルール記憶部184を備える。
本変形例においては、第1楽曲決定部181は、状態特定部162によって特定された健康状態に基づいて、携帯端末105が再生可能な各楽曲の重み値を算出する。ここで、第1楽曲決定部181における重み値は、第1楽曲決定ルール記憶部182に記憶される第1のルールを用いて決定される。上記重み値の決定方法は任意である。例えば、図28に示すジャンル決定ルールにおける設定内容を、楽曲に付された重みに関する設定内容に変更した情報を用いて重み値が決定されてもよい。すなわち、第1のルールは、睡眠の傾向に関する条件と、楽曲に付された重みに関する設定内容とを関連付けた情報であってもよい。このとき、第1楽曲決定部181は、状態特定部162によって特定された健康情報が、第1のルールに含まれる睡眠条件を満たすか否かを睡眠条件毎に判定し、満たされた睡眠条件に関連付けられる設定内容に従って、楽曲に付される重み値を変更する。なお、詳細は後述するが、本変形例において、上記第1のルールは、複数のユーザの健康情報に基づいて更新される(つまり、複数のユーザに関して共通の内容となる)。
第2楽曲決定部183は、第1楽曲決定部181によって算出された各楽曲の重み値を、状態特定部162によって特定された健康状態に基づいて補正する。ここで、第2楽曲決定部183による補正は、第2楽曲決定ルール記憶部184に記憶される第2のルールを用いて行われる。補正の具体的な方法は任意である。例えば、第1のルールと同様、第2のルールとして、睡眠の傾向に関する条件と、楽曲に付された重みの補正内容とを関連付けた情報を用いて補正が行われてもよい。このとき、第2楽曲決定部183は、状態特定部162によって特定された健康情報が、第2のルールに含まれる睡眠条件を満たすか否かを睡眠条件毎に判定し、満たされた睡眠条件に関連付けられる設定内容に従って、楽曲に付される重み値を補正する。なお、詳細は後述するが、本変形例において、上記第2のルールは、ユーザ毎の健康情報に基づいて更新される(つまり、ユーザ毎にカスタマイズされる)。
なお、第1楽曲決定部181において重み値の算出に用いられる健康状態の情報と、第2楽曲決定部183において重み値の補正に用いられる健康状態の情報とは、同じであってもよいし、異なっていてもよい。例えば、第1楽曲決定部181は、ユーザの最新の健康情報に基づいて状態特定部162によって特定される健康状態を用い、第2楽曲決定部183は、当該ユーザの過去の健康情報に基づいて状態特定部162によって特定される健康状態を用いてもよい。また例えば、第1楽曲決定部181は、第1の種類の健康状態(例えば、睡眠時間)を用い、第2楽曲決定部183は、第2の種類の健康状態(例えば、入眠潜時)を用いてもよい。
第2楽曲決定部183は、補正後の重み値に基づいて上述の候補楽曲を選択する。そして、第2楽曲決定部183は、選択した候補楽曲を示す情報を情報提供部165へ出力する。なお、重み値に基づく候補楽曲の選択方法は、上記第2の実施形態と同様の方法であってもよい。
上記のように、本変形例においては、上記決定ルールは、第1のルールと第2のルールを含む。ここで、本変形例において、第1のルールは、複数のユーザの健康情報に基づいて更新され、第2のルールは、ユーザ毎の健康情報に基づいて更新される(図34参照)。これによって、本変形例においても上記第2の実施形態と同様、ユーザ毎に提供条件を更新することができ、ユーザ毎に提供条件がカスタマイズされる。
第1のルールの更新方法は任意であるが、例えば、第1のルールは、上述の“(複数のユーザの健康情報に基づく更新を行う変形例)”におけるジャンル決定ルールの更新と同様の方法で更新されてもよい。つまり、第1のルールとジャンル決定ルールとは、重み値が楽曲に付されるものであるか楽曲のジャンルに付されるものであるかの違いはあるが、重み値を更新する方法としては同様の方法を用いることができる。例えば、ある楽曲について睡眠の改善効果があると判断された場合、サーバは、当該楽曲の重み値が大きく設定されやすくなるように第1のルールを更新する。そして、サーバは、第1のルールに関する更新内容を示す情報を含む更新通知を各端末システムへ送信する。各端末システムは、更新通知に従って、自身に記憶されている第1のルールを更新する。
第2のルールの更新方法は任意であるが、例えば、第2のルールは、上記実施形態における楽曲決定ルールの更新と同様の方法で更新されてもよい。すなわち、端末システム100は、ユーザが覚醒したことに応じたタイミングで、上記ルール更新テーブルに従って、第2のルールの更新内容を決定してもよい。例えば、端末システム100は、入眠用コンテンツとして再生された楽曲がユーザの睡眠を改善する効果があると推測される場合には、今後において当該楽曲が候補楽曲として提供されやすくなるように、第2のルールを更新する。
上記変形例によれば、複数のユーザに適用される第1のルールに基づく結果(重み値)が、ユーザ毎にカスタマイズされる第2のルールに基づいて補正され、補正後の結果に基づいて提供情報の内容(すなわち、候補楽曲)が決定される。これによれば、端末システム100は、第2のルールによって個別のユーザの健康状態を反映した情報を提供することができるので、上記第2の実施形態と同様、各ユーザに適した提案を行うことができる。
なお、上記変形例において、端末システム100は、第1のルールに基づいて算出される重み値を用い、第2のルールを用いなくても(すなわち、第2のルールに基づく補正が行われなくても)候補楽曲を決定することができる。したがって、他の実施形態においては、端末システム100は、所定の条件下で、第2のルールを用いずに、第1のルールに基づいて算出される重み値を用いて候補楽曲を決定するようにしてもよい。例えば、端末システム100は、第2のルールを用いるか否かをユーザの指示に従って設定するようにしてもよい。また例えば、端末システム100の利用の初期段階において、第2のルールの精度が低いと想定される場合(例えば、第2のルールが十分に更新されていない場合)には、第2のルールを用いないようにしてもよい。
(環境情報に基づく提供情報を提供する変形例)
他の実施形態においては、端末システム100は、環境センサ114によって検出される環境情報を用いて提供情報の提供を行ってもよい。具体的には、健康情報記憶部152は、ユーザの睡眠期間における環境情報を取得して記憶する。状態特定部162は、環境情報を考慮して睡眠の傾向を算出する。そして、ジャンル決定部163および/または楽曲決定部164は、環境情報を考慮して睡眠の傾向に基づいて候補楽曲を決定する。例えば、環境情報として気温が用いられる場合、状態特定部162は、端末システム100のユーザについての、睡眠潜時と気温との関係を算出する。そして、当該ユーザについて気温が低い場合に寝付きが悪い(すなわち、睡眠潜時が長い)傾向がある場合であって、提供情報を提供する際(ユーザが入床した後)に取得された環境情報に基づいて気温が低いと判断される場合には、ジャンル決定部163は、寝付きが良くなる効果があると思われるジャンルが選択されやすくなるように重み値を変更してもよい。
(環境情報に基づく更新を行う変形例)
また、他の実施形態においては、端末システム100は、環境センサ114によって検出される環境情報を用いて決定ルールの更新を行ってもよい。具体的には、健康情報記憶部152は、ユーザの睡眠期間における環境情報を取得して記憶する。更新部156は、睡眠期間に取得された生体情報に基づいて算出された健康情報と、当該睡眠期間に取得された環境情報とに基づいて、決定ルールの更新内容を決定する。例えば、更新部156は、健康情報が示す中途覚醒回数に応じて、更新対象となる楽曲の重み値を変化させる場合において、重み値の変化量を睡眠期間中の気温に応じて決定してもよい。すなわち、睡眠期間中の気温が高すぎたり低すぎたりする場合には、気温が原因で中途覚醒回数が増えると考えられる。したがって、このような場合に中途覚醒が多くても、更新部156は、重み値の変化量(具体的には減少量)を相対的に小さくする。一方、睡眠期間中の気温が適温である(すなわち、所定範囲内である)場合には、気温が原因で中途覚醒回数が増えるとは考えられない。したがって、このような場合に中途覚醒が多ければ、更新部156は、重み値の変化量(具体的には減少量)を相対的に大きくする。
(位置情報を用いる変形例)
また、他の実施形態においては、端末システム100は、位置検出部113によって検出される位置情報に基づいて、提供情報の提供、および/または、決定ルールの更新を行ってもよい。例えば、端末システム100は、位置情報に基づいて、1日におけるユーザの行動を示す行動情報を算出してもよい。行動情報は、1日の位置情報の履歴から算出される情報であり、例えば、ユーザの移動量(例えば、歩数でもよい)を示す情報であってもよいし、ユーザの行動内容(例えば、職場で仕事をした、スポーツジムに行った等)を示す情報であってもよい。端末システム100は、上記行動情報に基づいて提供情報の内容を決定してもよい。端末システム100は、例えば、行動情報からユーザの疲労度を算出し、疲労度に応じて異なるジャンルを選択するようにしてもよい。
また、端末システム100は、上記行動情報に基づいて決定ルールの更新内容を決定するようにしてもよい。例えば、端末システム100は、ある日の行動情報からユーザの疲労度を算出し、次の日におけるユーザの覚醒時に決定ルールを更新する際において、当該疲労度に応じて更新内容を異ならせるようにしてもよい。
(提供情報の変形例)
第2の実施形態においては、提供情報が、入眠用コンテンツとして再生される楽曲、および、その楽曲の候補となる楽曲(候補楽曲)である場合を例として説明した。ここで、提供情報の内容は任意であり、任意の提供情報について提供条件をユーザ毎に更新することが可能である。例えば、提供情報は、上記第1の実施形態における商品等をユーザに紹介するリコメンド情報、および/または、ユーザの健康状態を改善するためのアドバイス情報であってもよい。
また例えば、携帯端末105が複数種類の機能(アプリケーション)を提供可能である場合、携帯端末105は、当該複数種類の機能のうちからおすすめの機能を提供情報としてユーザに提供(紹介とも言える)してもよい。具体的には、携帯端末105は、取得された健康情報から、寝付きが悪いと判断されたユーザに対しては、上述の入眠用コンテンツを再生する機能を紹介し、目覚めが悪いと判断されたユーザに対しては、覚醒用コンテンツ(覚醒を促す音楽および/または映像)を覚醒前に再生する機能を紹介するようにしてもよい。
(ベース装置に関する変形例)
他の実施形態においては、ベース装置106は、携帯端末105を介さずにサーバと通信を行ってもよい。例えば、ベース装置106は、携帯端末105と同様に、ネットワーク4を介してサーバと通信を行う機能を有していてもよい。このとき、ベース装置106は、自身で検出した情報を直接サーバへ送信してもよいし、携帯端末105とサーバとの両方へ送信してもよい。また、ベース装置106は、提供情報をサーバから直接受信してもよい。このとき、サーバは、携帯端末105とベース装置106との両方に提供情報を送信してもよいし、いずれか一方に提供情報を送信してもよい。
[5.第2の実施形態における作用効果]
上記第2の実施形態および変形例においては、情報処理システムは、ユーザの健康に関する分析を当該ユーザの生体情報に基づいて行い、分析結果に基づく情報の提供を当該ユーザに対して行う(ステップS102~S104,S121、分析部151)。また、情報処理システムは、提供される情報を生体情報に基づいて決定するためのルール(条件とも言える。具体的には、決定ルール)の少なくとも一部(具体的には、楽曲決定ルール)を、ユーザの生体情報に基づいてユーザ毎に更新する(ステップS109,S128、更新部156、第1更新部171)。情報処理システムは、更新によってユーザ毎に設定されたルール(すなわち、更新されることによってユーザ毎にカスタマイズされる結果となったルール)を用いて、ユーザに提供する情報を決定する。上記によれば、ルールをユーザ個人に適した内容に変更することができるので、それぞれのユーザに対して有用な情報を提供することができる。
上記ルールの更新とは、例えば、次のような処理を含む意味である。
・提供する情報を決定するための情報処理プログラムの更新
・提供する情報を決定するためのルールが記述されたテーブルの更新
・提供する情報を決定するためのアルゴリズムの更新
・提供する情報を決定するための分析エンジンの更新
なお、ルールの更新を行うための生体情報は、任意のタイミングで取得されたものであってよい。また、情報処理システムは、更新前のルールに従って決定された提供情報が提供された後で取得された生体情報に基づいて、当該ルール(すなわち、更新前のルール)を更新してもよい。これによれば、更新前のルールによる提供情報の効果(つまり、有効な情報を提供することができたか否か)を反映してルールを更新することができる。
上記第2の実施形態および変形例においては、上記ルールは、ユーザ毎に更新される第1の部分(具体的には、楽曲決定ルール、または、上記第2のルール)と、当該ユーザを含む複数のユーザで共通の第2の部分(具体的には、ジャンル決定ルール、または、上記第1のルール)とを含む。換言すれば、情報処理システムは、提供すべき情報を決定するためのルールとして、複数のユーザに関して共通の第1のルールと、当該複数のユーザのそれぞれに対して個別に設定される第2のルール(例えば、第2のルールは、ユーザ毎に異なる内容に設定される)との両方を用いる。これによれば、第1の部分によって個別のユーザに適した情報を提供することができるとともに、複数のユーザで共通する部分についてはルールを共有化することによって、ルールを更新する処理を簡易化することができる。
なお、上記第1の部分と第2の部分は、上記“(複数のユーザの健康情報に基づく更新を行う変形例)”および“(ルールに関する変形例)”で説明した変形例のように、同じ提供情報(すなわち、候補楽曲の情報)を決定するために用いられるものであってもよい。また、上記第1の部分と第2の部分は、上述の第1のルールおよび第2のルールのように、同種の情報(上記変形例においては、楽曲の重み値)を決定するために用いられるものであってもよい。また例えば、上記第1の部分と第2の部分は、異なる提供情報を決定するために用いられるものであってもよい。つまり、第1の部分に基づいて第1の提供情報の内容が決定され、第2の部分に基づいて第2の提供情報の内容が決定され、第1および第2の提供情報が(上記提供情報として)ユーザに提供されてもよい。
なお、上記第2の実施形態の変形例においては、情報処理システムは、提供情報を決定するための第1の情報(具体的には、第1楽曲決定部181によって算出される重み値)を、生体情報と第1のルールとを用いて算出する。さらに、情報処理システムは、算出された第1の情報と第2のルールとを用いて、提供情報を決定する。上記によれば、各ユーザに共通の第1のルールに基づく結果(すなわち、第1の情報)を、ユーザに個別の第2のルールによって加工(具体的には、補正)することによって、提供情報を決定することができる。
さらに、上記変形例においては、情報処理システムは、第2のルールと生体情報とを用いて第2の情報(具体的には、第1楽曲決定部181によって決定される、重み値の補正内容)を算出し、上記第1情報と上記第2情報とに基づいて(具体的には、第1の情報を前記第2の情報によって補正することによって)提供情報を決定する。このとき、第1の情報が、第2のルールを用いなくても提供情報を決定することができる種類の情報である場合には、端末システム100は、第2のルールを用いずに第1の情報によって提供情報を決定する態様と、第2のルールを用いて提供情報を決定する態様との両方を実行することができる。
上記第2の実施形態の変形例においては、情報処理システムは、複数のユーザに関する各生体情報を取得する(すなわち、各端末システムはそれぞれのユーザの生体情報を取得する、あるいは、サーバは各端末システムから各ユーザの生体情報を取得する)。また、情報処理システムは、各生体情報に含まれる少なくとも複数の生体情報に基づいて、上記第2の部分を更新する(すなわち、サーバは上記更新通知を端末システムへ送信する、あるいは、端末システムは更新通知に応じてジャンル決定ルールを更新する)。これによれば、複数のユーザで共通の第2の部分については、当該複数のユーザの健康状態を考慮した適切な内容へと更新することができる。なお、「生体情報に基づいて更新する」とは、生体情報に基づいて算出される健康情報に基づいて更新することを含む意味である。
なお、上記変形例のように、第1の部分を更新する条件(換言すれば、タイミング)は、第2の部分を更新する条件と異なっていてもよい。また、第1の部分を更新する頻度は、第2の部分を更新する頻度よりも高くてもよい。第1の部分については、個人のユーザに関する健康情報に基づいて更新されるので、高い頻度で更新することでそのユーザに適した内容とすることができる。これに対して、第2の部分については、複数のユーザに関する健康情報に基づいて更新されるので、ある程度の数の健康情報に基づいて更新することによって、複数のユーザにとって適切な内容とすることができる。
上記第2の実施形態の変形例においては、情報処理システムは、1以上のユーザ端末(例えば端末システム100)と、ユーザ端末とネットワークを介して通信可能なサーバシステム(例えば、データサーバ2およびサービスサーバ3)とを含む。ユーザ端末は、ユーザの健康に関する分析と、ルールの更新とを実行する機能を有する。ユーザ端末は、自身のユーザ端末によって取得された生体情報に基づいて上記第1の部分の更新を行う。サーバシステムは、複数のユーザに関する各生体情報を取得する。第2の部分は、サーバによって取得された複数の生体情報に基づいて更新される。これによれば、サーバにおいて複数の生体情報を取得することによって、ルールの更新を容易に行うことができる。
上記第2の実施形態および変形例においては、情報処理システムは、ユーザの生体情報と、当該ユーザによる入力(ステップS108)とに基づいてルールの少なくとも一部をユーザ毎に更新する。これによれば、ユーザの主観(すなわち、ユーザによる入力)を考慮してルールを更新することができる。なお、ユーザによる入力は、任意の入力であってよく、上記実施形態のような質問に対する回答の入力に限らない。例えば、情報処理システムは、ユーザが自発的に行った入力(例えば、検索サイトにおける検索ワードの入力)に基づいて更新を行うようにしてもよい。また、情報処理システムは、ユーザに対して質問を提示し(ステップS107、質問提示部155)、質問に対する回答を上記ユーザによる入力として用いる。これによれば、ユーザにとっては入力が行いやすくなるとともに、情報処理システムにとっては有用なユーザ入力を得ることができる。
さらに、上記第2の実施形態および変形例においては、情報処理システムは、情報の提供が行われた後で取得されたユーザの生体情報に基づいて質問内容を決定して当該ユーザに対して質問を提示する。そして、情報処理システムは、情報の提供が行われた後で取得されたユーザの生体情報と、質問に対する回答とに基づいてルールを更新する。これによれば、情報処理システムは、適切な質問をユーザに提示することができ、ルールの更新を行うための有用な回答入力を得ることができる。
上記第2の実施形態の変形例においては、情報処理システムは、生体情報が検出されるときの(例えば、ユーザの睡眠期間中の)ユーザの周囲の環境に関する環境情報を取得する。情報処理システムは、提供される情報を、ユーザの生体情報と、当該ユーザに関する環境情報とに基づいて決定する。これによれば、ユーザの周囲の環境を考慮することによって、より有用な情報をユーザに提供することができる。また、情報処理システムは、上記ルールの少なくとも一部を、ユーザの生体情報と、当該ユーザに関する環境情報とに基づいて更新する。これによれば、ユーザの周囲の環境を考慮することによって、より適切にルールを更新することができる。
上記第2の実施形態の変形例においては、情報処理システムは、提供情報として、ユーザの健康に関する情報、および/または、ユーザの健康を改善するための情報を当該ユーザに対して提供する。ここで、上述した入眠用コンテンツの楽曲や候補楽曲は、「ユーザの健康に関する情報」と言うことができ、また、「ユーザの健康の健康を改善するための情報」と言うことができる。また、第1の実施形態におけるアドバイス情報およびリコメンド情報、あるいは、上述の“(提供情報の変形例)”で述べたような、健康を改善するための機能(アプリケーション)の情報も、「ユーザの健康に関する情報」と言うことができ、また、「ユーザの健康の健康を改善するための情報」と言うことができる。
上記第2の実施形態の変形例においては、情報処理システムは、繰り返し取得された生体情報に基づいて分析を繰り返し実行する(具体的には、ユーザが睡眠を行う度に分析が行われる。)。また、情報処理システムは、繰り返し取得された生体情報と、繰り返し実行された分析において算出された情報とのうちの少なくとも一部の情報を所定の記憶部(具体的には、健康情報記憶部152)に記憶する。情報処理システムは、記憶部に記憶された、複数回分の前記生体情報、および/または、複数回の分析において算出された情報(具体的には、最近1週間の健康情報)に基づいて上記ルールの少なくとも一部をユーザ毎に更新する。これによれば、複数回の計測および/または分析の結果を用いて上記ルールが更新されるので、より有用な情報をユーザに提供することができるようになる。また、情報処理システムは、上記ルールの更新を繰り返し行うので、ルールをユーザに適した内容へと次第に変更することができる。さらに、情報処理システムは、分析が行われる度に上記ルールの更新を行う。これによれば、分析の度にルールが更新されるので、ルールをこまめに更新することができる。
<その他の変形例>
(各装置間における処理の分担に関する変形例)
以上において説明した、端末側とサーバ側との間での処理の分担、サーバ装置間での処理の分担、および、端末システム内における各装置間での処理の分担の態様は一例であり、情報処理システムにおける各処理はどのように分担されてもよい。例えば、上記第2の実施形態においては、決定ルールは端末側に記憶されたが、他の実施形態においては、決定ルールの一部(例えば、ジャンル決定ルール)または全部がサーバ側に記憶されてもよい。このとき、提供情報の内容を決定する処理、および、決定ルールを更新する処理は、サーバ側で実行されてもよい。