特許 7184980 情報処理システム、情報処理サーバ、情報処理プログラム、および情報提供方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-11-28

(45)【発行日】2022-12-06

(54)【発明の名称】情報処理システム、情報処理サーバ、情報処理プログラム、および情報提供方法

(51)【国際特許分類】

   G16H 20/00 20180101AFI20221129BHJP

【ＦＩ】

G16H20/00

【請求項の数】 11

(21)【出願番号】P 2021136986

(22)【出願日】2021-08-25

(62)【分割の表示】P 2020085828の分割

【原出願日】2015-07-08

(65)【公開番号】P2021185515

(43)【公開日】2021-12-09

【審査請求日】2021-09-24

(31)【優先権主張番号】PCT/JP2014/070931

(32)【優先日】2014-08-07

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2014/078824

(32)【優先日】2014-10-29

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2014/078825

(32)【優先日】2014-10-29

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2014/078826

(32)【優先日】2014-10-29

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2014/078827

(32)【優先日】2014-10-29

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2014/078828

(32)【優先日】2014-10-29

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2014/078829

(32)【優先日】2014-10-29

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2015/061273

(32)【優先日】2015-04-10

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】PCT/JP2015/061274

(32)【優先日】2015-04-10

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000233778

【氏名又は名称】任天堂株式会社

(74)【代理人】

【識別番号】100158780

【弁理士】

【氏名又は名称】寺本 亮

(74)【代理人】

【識別番号】100121359

【弁理士】

【氏名又は名称】小沢 昌弘

(74)【代理人】

【識別番号】100130269

【弁理士】

【氏名又は名称】石原 盛規

(72)【発明者】

【氏名】服部 由里絵

【審査官】玉木 宏治

(56)【参考文献】

【文献】特開２０１１－１３００９９（ＪＰ，Ａ）

【文献】特開２００７－１９５６６４（ＪＰ，Ａ）

【文献】特開平１１－２４４３８３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００－８０／００

(57)【特許請求の範囲】

【請求項1】

非接触センサを用いてユーザの存在を検出するユーザ検出手段と、
前記ユーザの存在が検出されたことに基づいて、当該ユーザの入眠を誘導する第１コンテンツを再生する第１コンテンツ再生手段と、
前記非接触センサを用いて当該ユーザの入眠または睡眠に関する生体情報を取得する生体情報取得手段と、
前記ユーザの入眠が検出されたことに基づいて、前記第１コンテンツの再生を停止する第１コンテンツ停止手段と、
前記ユーザの起床を誘導する第２コンテンツを再生する第２コンテンツ再生手段と、
前記ユーザの起床が検出されたことに基づいて、前記第２コンテンツの再生を停止する第２コンテンツ停止手段とを備える、情報処理システム。

【請求項2】

前記第１コンテンツは楽曲である、請求項１に記載の情報処理システム。

【請求項3】

前記第２コンテンツは楽曲である、請求項１または請求項２に記載の情報処理システム。

【請求項4】

前記第１コンテンツ停止手段は、前記第１コンテンツの音量を次第に減少させた後で当該第１コンテンツの再生を停止する、請求項１から請求項３のいずれか１項に記載の情報処理システム。

【請求項5】

前記第１コンテンツ再生手段は、前記ユーザの存在が検出されたことに基づいて自動的に前記第１コンテンツの再生を開始する、請求項１から請求項４のいずれか１項に記載の情報処理システム。

【請求項6】

前記生体情報取得手段は、前記ユーザの入眠中において前記第１コンテンツの再生が停止されているか否かに関わらず前記生体情報を取得し、
前記第１コンテンツ再生手段は、前記ユーザの睡眠中に取得された前記生体情報に基づいて決定される第１コンテンツを、当該睡眠より後の当該ユーザの睡眠時において再生する、請求項１から請求項５のいずれか１項に記載の情報処理システム。

【請求項7】

前記第２コンテンツ停止手段は、前記第２コンテンツの再生中に取得される前記生体情報に基づいて、当該第２コンテンツの再生を停止するか否かを判定する、請求項１から請求項６のいずれか１項に記載の情報処理システム。

【請求項8】

前記第２コンテンツ再生手段は、前記ユーザが覚醒する前のタイミングまたは覚醒したタイミングに応じて前記第２コンテンツの再生を開始する、請求項１から請求項７のいずれか１項に記載の情報処理システム。

【請求項9】

非接触センサを用いてユーザの存在を検出するユーザ検出手段と、
前記ユーザの存在が検出されたことに基づいて、当該ユーザの入眠を誘導する第１コンテンツを再生する第１コンテンツ再生手段と、
前記非接触センサを用いて当該ユーザの入眠または睡眠に関する生体情報を取得する生体情報取得手段と、
前記ユーザの入眠が検出されたことに基づいて、前記第１コンテンツの再生を停止する第１コンテンツ停止手段と、
前記ユーザの起床を誘導する第２コンテンツを再生する第２コンテンツ再生手段と、
前記ユーザの起床が検出されたことに基づいて、前記第２コンテンツの再生を停止する第２コンテンツ停止手段とを備える、情報処理装置。

【請求項10】

情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、
非接触センサを用いてユーザの存在を検出するユーザ検出手段と、
前記ユーザの存在が検出されたことに基づいて、当該ユーザの入眠を誘導する第１コンテンツを再生する第１コンテンツ再生手段と、
前記非接触センサを用いて当該ユーザの入眠または睡眠に関する生体情報を取得する生体情報取得手段と、
前記ユーザの入眠が検出されたことに基づいて、前記第１コンテンツの再生を停止する第１コンテンツ停止手段と、
前記ユーザの起床を誘導する第２コンテンツを再生する第２コンテンツ再生手段と、
前記ユーザの起床が検出されたことに基づいて、前記第２コンテンツの再生を停止する第２コンテンツ停止手段として前記コンピュータを機能させる、情報処理プログラム。

【請求項11】

情報処理システムによって実行される情報処理方法であって、
非接触センサを用いてユーザの存在を検出するユーザ検出ステップと、
前記ユーザの存在が検出されたことに基づいて、当該ユーザの入眠を誘導する第１コンテンツを再生する第１コンテンツ再生ステップと、
前記非接触センサを用いて当該ユーザの入眠または睡眠に関する生体情報を取得する生体情報取得ステップと、
前記ユーザの入眠が検出されたことに基づいて、前記第１コンテンツの再生を停止する第１コンテンツ停止ステップと、
前記ユーザの起床を誘導する第２コンテンツを再生する第２コンテンツ再生ステップと、
前記ユーザの起床が検出されたことに基づいて、前記第２コンテンツの再生を停止する第２コンテンツ停止ステップとを備える、情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ側から端末側へ情報を提供する情報処理システム、情報処理サーバ、情報処理プログラム、および情報提供方法に関する。

【背景技術】

【0002】

従来、端末側で取得された情報をサーバ側へアップロードし、アップロードされた情報に対する分析結果をサーバ側から端末側へ提供するシステムがある。例えば、端末側の評価装置でユーザの睡眠データを取得し、サーバ側で睡眠データの分析を行い、分析結果を端末側の表示装置に表示するシステムがある（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１３－１６８０２６号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来においては、サーバ側から端末側へ提供される情報として、有用な情報を提供することができない可能性があった。

【0005】

それ故、本発明の目的は、有用な情報を提供することができる情報処理システム、情報処理サーバ、情報処理プログラム、および情報提供方法を提供することである。

【課題を解決するための手段】

【0006】

上記の課題を解決すべく、本発明は、以下の（１）～（１９）の構成を採用した。

【0007】

（１）
本発明の一例に係る情報処理システムは、分析手段と、第１更新手段とを備える。分析手段は、ユーザの健康に関する分析を当該ユーザの生体情報に基づいて行い、分析結果に基づく情報の提供を当該ユーザに対して行う。第１更新手段は、提供される情報を生体情報に基づいて決定するためのルールの少なくとも一部を、ユーザの生体情報に基づいてユーザ毎に更新する。分析手段は、更新によってユーザ毎に設定されたルールを用いて、ユーザに提供する情報を決定する。

【0008】

（２）
ルールは、ユーザ毎に更新される第１の部分と、ユーザを含む複数のユーザで共通の第２の部分とを含んでいてもよい。

【0009】

（３）
情報処理システムは、第１取得手段と、第２更新手段をさらに備えていてもよい。第１取得手段は、複数のユーザに関する各生体情報を取得する。第２更新手段は、各生体情報に含まれる少なくとも複数の生体情報に基づいて、第２の部分を更新する。

【0010】

（４）
情報処理システムは、１以上のユーザ端末と、ユーザ端末とネットワークを介して通信可能なサーバシステムとを含んでいてもよい。ユーザ端末は、分析手段および第１更新手段を少なくとも備えていてもよい。第１更新手段は、自身のユーザ端末によって取得された生体情報に基づいて第１の部分の更新を行ってもよい。サーバシステムは、複数のユーザに関する各生体情報を取得してもよい。第２更新手段は、サーバによって取得された複数の生体情報に基づいて第２の部分を更新してもよい。

【0011】

（５）
第１更新手段は、ユーザの生体情報と、当該ユーザによる入力とに基づいてルールの少なくとも一部をユーザ毎に更新してもよい。

【0012】

（６）
情報処理システムは、ユーザに対して質問を提示する質問提示手段をさらに備えていてもよい。第１更新手段は、質問に対する回答をユーザによる入力として用いてもよい。

【0013】

（７）
質問提示手段は、情報の提供が行われた後で取得されたユーザの生体情報に基づいて質問内容を決定して当該ユーザに対して質問を提示してもよい。第１更新手段は、情報の提供が行われた後で取得されたユーザの生体情報と、質問に対する回答とに基づいてルールの少なくとも一部をユーザ毎に更新してもよい。

【0014】

（８）
情報処理システムは、生体情報が検出されるときのユーザの周囲の環境に関する環境情報を取得する第２取得手段をさらに備えていてもよい。分析手段は、提供される情報を、ユーザの生体情報と、当該ユーザに関する環境情報とに基づいて決定してもよい。

【0015】

（９）
情報処理システムは、生体情報が検出されるときのユーザの周囲の環境に関する環境情報を取得する第２取得手段をさらに備えていてもよい。第１更新手段は、ルールの少なくとも一部を、ユーザの生体情報と、当該ユーザに関する環境情報とに基づいて更新してもよい。

【0016】

（１０）
第１更新手段は、ユーザの健康に関する情報を当該ユーザに対して提供してもよい。

【0017】

（１１）
第１更新手段は、ユーザの健康の健康を改善するための情報を当該ユーザに対して提供してもよい。

【0018】

（１２）
分析手段は、繰り返し取得された生体情報に基づいて分析を繰り返し実行してもよい。情報処理システムは、繰り返し取得された生体情報と、繰り返し実行された分析において算出された情報とのうちの少なくとも一部の情報を所定の記憶部に記憶する記憶制御手段をさらに備えていてもよい。第１更新手段は、記憶部に記憶された、複数回分の生体情報、および／または、複数回の分析において算出された情報に基づいてルールの少なくとも一部をユーザ毎に更新してもよい。

【0019】

（１３）
第１更新手段は、ルールの更新を繰り返し行ってもよい。

【0020】

（１４）
第１更新手段は、分析手段による分析が行われる度にルールの更新を行ってもよい。

【0021】

（１５）
生体情報は、ユーザの脈拍、呼吸、および、体動の少なくともいずれかを検出するセンサから取得されてもよい。

【0022】

（１６）
分析手段は、生体情報に基づいてユーザの睡眠および／または疲労に関する分析を行ってもよい。

【0023】

（１７）
本発明の他の一例に係る情報処理システムは、分析手段と、情報提供手段とを備える。分析手段は、ユーザの健康に関する分析を当該ユーザの生体情報に基づいて行い、分析結果に基づいて、ユーザに提供すべき情報を決定する。情報提供手段は、決定された情報を当該ユーザに提供する。分析手段は、提供すべき情報を決定するためのルールとして、複数のユーザに関して共通の第１のルールと、当該複数のユーザのそれぞれに対して個別に設定される第２のルールとの両方を用いて、ユーザに提供すべき情報を決定する。

【0024】

（１８）
分析手段は、ユーザに提供すべき情報を決定するための第１の情報を、生体情報と第１のルールとを用いて算出し、算出された第１の情報と第２のルールとを用いて、ユーザに提供すべき情報を決定してもよい。

【0025】

（１９）
分析手段は、生体情報と第２のルールとを用いて第２の情報を算出し、第１の情報を第２の情報によって補正することによって、ユーザに提供すべき情報を決定してもよい。

【0026】

なお、本発明の別の一例は、上記（１）～（１９）における情報処理システムに含まれる情報処理装置（例えば、携帯端末）またはサーバであってもよい。また、本発明の別の一例は、上記情報処理装置またはサーバのコンピュータを、上記（１）～（１９）における各手段のいくつかとして機能させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記情報処理システム、情報処理装置、またはサーバにおいて実行される情報処理方法であってもよい。

【発明の効果】

【0027】

本発明によれば、ユーザにとって有用な情報を提供することができる。

【図面の簡単な説明】

【0028】

【図1】第１の実施形態における情報処理システムの構成の一例を示すブロック図

【図2】端末システムの構成の一例を示す図

【図3】端末システムに含まれる各装置が配置される一例を示す図

【図4】主端末装置の処理部において健康情報を算出するための機能的構成の一例を示す機能ブロック図

【図5】主端末装置の処理部において実行される処理の流れの一例を示すフローチャート

【図6】情報処理システムにおける動作の流れの一例を示すタイミングチャート

【図7】データサーバに記憶されるデータの一例を示す図

【図8】ポータルサーバに記憶されるデータの一例を示す図

【図9】提供条件テーブルの一例を示す図

【図10】利用要求の一例を示す図

【図11】利用管理テーブルの一例を示す図

【図12】ユーザ提供履歴情報の一例を示す図

【図13】端末システムにおいて表示されるメインページの一例を示す図

【図14】追加提供条件テーブルの一例を示す図

【図15】追加提供条件の判定方法の一例を示す図

【図16】データサーバにおいて実行される処理の流れの一例を示すフローチャート

【図17】ポータルサーバにおいて実行される処理の流れの一例を示すフローチャート

【図18】条件更新テーブルの一例を示す図

【図19】変形例による効果を説明するための図

【図20】変形例における提供条件テーブルの一例を示す図

【図21】変化情報の一例を示す図

【図22】第２の実施形態における端末システムの詳細な構成の一例を示す図

【図23】第２の実施形態における端末システムの外観の一例を示す図

【図24】第２の実施形態における端末システムよる処理の流れの一例を示す図

【図25】候補楽曲を示す情報を提供するために携帯端末に表示される画像の一例を示す図

【図26】覚醒時に携帯端末に表示される画像の一例を示す図

【図27】端末システムの機能的構成の一例を示す機能ブロック図

【図28】ジャンル決定ルールの一例を示す図

【図29】楽曲決定ルールに含まれるテーブルの一例を示す図

【図30】ユーザに提示する質問を決定するためのテーブルの一例を示す図

【図31】更新内容を決定するためのルール更新テーブルの一例を示す図

【図32】携帯端末において実行される処理の流れの一例を示すフローチャート

【図33】第２の実施形態の変形例における端末システムの機能的構成の一例を示す機能ブロック図

【図34】第２の実施形態の他の変形例における端末システムの機能的構成の一例を示す機能ブロック図

【発明を実施するための形態】

【0029】

＜第１の実施形態＞
［１．情報処理システムの全体構成］
以下、図面を参照して、本実施形態に係る情報処理システム、情報処理サーバ、情報処理プログラム、および情報提供方法について説明する。まず、本実施形態に係る情報処理システムの全体構成について説明する。図１は、本実施形態における情報処理システムの構成の一例を示すブロック図である。図１に示すように、情報処理システムは、端末システム１と、データサーバ２と、サービスサーバ３とを含む。これらのシステムおよびサーバ１～３は、インターネットやモバイル通信網等のネットワーク４を介して互いに通信可能である。

【0030】

端末システム１は、ユーザの元（例えばユーザの自宅）に配置される。なお、図１では端末システム１を１つのみ示すが、情報処理システムは、ユーザ毎にそれぞれ設けられる複数の端末システムを含んでいる。本実施形態においては、端末システム１は、ユーザの生体情報を取得し、生体情報から得られる健康情報をデータサーバ２へアップロードする（図１参照）。ここで、生体情報は、ユーザの身体から検出される情報である。本実施形態においては、呼吸、脈拍、および体動が生体情報として取得される。健康情報は、ユーザの健康および／または身体に関する情報である。本実施形態においては、健康情報は、ユーザの睡眠に関する指標である睡眠指標、および、ユーザの疲労に関する指標である疲労指標を含む。このように、端末システム１は、ユーザの生体情報を検出し、検出結果から睡眠指標および疲労指標を計算してデータサーバ２へアップロードするものである。上記端末システム１は、ユーザの健康状態を検出するものであり、ＱＯＬ（Ｑｕａｌｉｔｙ ｏｆ Ｌｉｆｅ）センサということもできる。

【0031】

データサーバ２は、端末システム１から送信されてくるユーザの健康情報を記憶（蓄積）する。また、データサーバ２は、健康情報から得られる２次情報として統計量（例えば、所定期間における平均値等）を算出する。以下では、端末システム１から受信される健康情報と、それから得られる２次情報（統計量）とを総称して、健康情報と呼ぶことがある。

【0032】

サービスサーバ３は、データサーバ２に記憶された健康情報を用いて、端末システム１のユーザに対して各種の情報を提供する。以下では、サービスサーバがユーザに対して提供する情報を「提供情報」と呼ぶ。提供情報は、ユーザの健康情報が示す指標を改善するための情報である。詳細は後述するが、提供情報は例えば、上記指標を改善するための商品やサービス（例えば、睡眠を改善するためのグッズや、疲労を回復するためのサプリメント等）を紹介する情報である。すなわち、本実施例においては、提供情報はユーザに対するリコメンド情報ともいえる。サービスサーバ３は、データサーバ２から取得した健康情報を用いて、提供情報を提供するサービスを行う。また、本実施形態においては、サービスサーバ３は、提供情報によって紹介される商品および／またはサービス（以下「商品・サービス」と記載する）をユーザに販売するサービスも行う。

【0033】

なお、データサーバ２およびサービスサーバ３はそれぞれ、ＣＰＵおよびメモリを有する情報処理装置（すなわち、サーバ装置）を１以上含む。各サーバ２および３においては、ＣＰＵがメモリを用いて、自身に記憶された情報処理プログラムを実行することによって各種の情報処理が実行される。なお、本明細書では、「サーバ」とは、１つの情報処理装置（サーバ装置）を指す他、サーバが複数のサーバ装置によって構成される場合にはサーバ装置群（サーバシステム）全体を指す意味である。

【0034】

［２．端末システムの構成］
次に、本実施形態における端末システム１の構成について説明する。図２は、端末システム１の構成の一例を示す図であり、図３は、端末システム１に含まれる各装置が配置される一例を示す図である。図２および図３に示すように、端末システム１は、主端末装置１０と、副端末装置２０とを含む。本実施形態において、主端末装置１０および副端末装置２０は、例えばユーザの寝室に配置される（図３参照）。詳細は後述するが、端末システム１は、主にユーザの就寝中（睡眠中）に生体情報を取得し、睡眠指標および疲労指標を算出する。

【0035】

主端末装置１０は、生体情報を検出するセンサとして機能する。本実施形態においては、図３に示すように、主端末装置１０はユーザの枕元など、ユーザの周辺に配置され、就寝中におけるユーザの生体情報を検出する。

【0036】

図２に示すように、主端末装置１０は、生体情報を検出するセンサの一例であるドップラーセンサ１１を備える。ドップラーセンサ１１は、マイクロ波を発射するとともに、発射したマイクロ波の反射波を受信することによって、発射したマイクロ波の周波数と受信したマイクロ波の周波数との差に基づいて動体を検出する。詳細は後述するが、検出される生体情報であるドップラーセンサ１１の出力波形を解析（周波数分析等）することで、呼吸、脈拍、および体動といった生体情報をさらに算出することができる。本実施形態では、ユーザがセンサを装着しない状態で生体情報を検出可能な、非装着型のセンサ（ドップラーセンサ１１）を用いるので、ユーザの邪魔にならず（ユーザは睡眠を妨げられることなく）生体情報を検出することができる。

【0037】

主端末装置１０はカメラ１２を備える。カメラ１２は、ユーザを撮像するために用いられる。また、主端末装置１０はマイク１３を備える。マイク１３は、ユーザから発生する音（いびき等）および／または周囲の騒音等を検出するために用いられる。

【0038】

主端末装置１０は、主端末装置１０において実行される各種の情報処理を実行する処理部１５を備える。処理部１５は、主端末装置１０の各部１１～１４および１６～１９に接続される。処理部１５は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）およびメモリを有し、ＣＰＵがメモリを用いて、主端末装置１０に記憶された情報処理プログラムを実行することによって上記各種の情報処理が実行される。本実施形態においては、処理部１５は、上記情報処理として、センサによって検出された生体情報に基づいて健康情報を算出する処理等を実行する。また、主端末装置１０が情報処理装置（情報処理端末）として機能する場合、処理部１５は、当該機能のための各種の情報処理を実行する。

【0039】

主端末装置１０は、入出力インターフェースを備え、情報を入力したり閲覧したりするための情報処理装置（入出力端末）として機能する。具体的には、主端末装置１０は、操作入力部１４およびディスプレイ１６を備える。操作入力部１４は、ユーザによる操作入力を受け付ける任意の入力装置である。本実施形態においては、主端末装置１０は、ディスプレイ１６上に設けられるタッチパネルと、ボタンとを操作入力部１４として有する。ディスプレイ１６は、ユーザの生体情報および／または健康情報を表示したり、上記の提供情報を表示したりすることが可能である。また、ディスプレイ１６は、鏡として機能する構成を有していてもよい。

【0040】

主端末装置１０は、ＬＥＤ等の光源を有する照明部１７を備える。照明部１７の発光は、処理部１５によって制御される。照明部１７は、例えば、ユーザの睡眠中において睡眠状態に応じた適切な光を発するように制御されたり、ユーザの起床時に目覚ましの目的で光を発するように制御されたりしてもよい。

【0041】

主端末装置１０と副端末装置２０とは互いに通信可能である。一例として、主端末装置１０は、副端末装置２０との間の通信手段として、近距離無線通信部１８を備える。本実施形態において、近距離無線通信部１８は、無線ＬＡＮによって通信を行う機能を有する通信モジュールである。例えば、近距離無線通信部１８は、Ｗｉ－Ｆｉの認証を受けた通信モジュールである。

【0042】

また、主端末装置１０は、ネットワーク４に接続して、各サーバ２および３と通信する機能を有している。具体的には、主端末装置１０はモバイル通信部１９を備える。本実施形態において、モバイル通信部１９は、モバイル通信網に接続して通信を行う機能を有する通信モジュールである。例えば、モバイル通信部１９は、３Ｇの通信規格、あるいは、４Ｇ（ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）を含む）の通信規格に準拠した通信方式で通信を行う。なお、主端末装置１０が各サーバ２および３と通信するための方法は、Ｗｉ－Ｆｉの認証を受けた通信モジュールによって無線ＬＡＮを介して通信を行う方法であってもよい。また、主端末装置１０は、モバイル通信網を介して各サーバ２および３と通信する機能と、無線ＬＡＮを介して各サーバ２および３と通信を行う機能との両方を備えていてもよい。

【0043】

副端末装置２０は、主端末装置１０とは異なる生体情報を取得するセンサとして機能する。図３に示すように、副端末装置２０は、主端末装置１０の近傍に配置される。副端末装置２０は、その上に乗ったユーザの生体情報（体重等）を検出することが可能である。

【0044】

図２に示すように、副端末装置２０は荷重センサ２１を備える。荷重センサ２１は、副端末装置２０の上面に加えられる荷重を検出する。なお、副端末装置２０は、体重の他、体脂肪等を測定するための生体情報を検出するためのセンサを有していてもよい。

【0045】

また、副端末装置２０は、タッチパネル２２を備える。タッチパネル２２は、副端末装置２０の上面に設けられる。タッチパネル２２は、副端末装置２０の上面に乗ったユーザの足の形を検出することが可能である。

【0046】

副端末装置２０は、副端末装置２０において実行される各種の情報処理を実行する処理部２３を備える。処理部２３は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）およびメモリを有し、ＣＰＵがメモリを用いて、副端末装置２０に記憶された情報処理プログラムを実行することによって上記各種の情報処理が実行される。

【0047】

副端末装置２０は、主端末装置１０との間の通信手段として、近距離無線通信部２４を備える。近距離無線通信部２４は、主端末装置１０の近距離無線通信部１８と同様、無線ＬＡＮによって通信を行う機能を有する通信モジュールであり、例えばＷｉ－Ｆｉの認証を受けた通信モジュールである。本実施形態においては、ユーザが副端末装置２０の上に乗ったことが検出された場合、近距離無線通信部２４は、所定の通知信号および荷重センサ２１によって検出された生体情報を副端末装置２０から主端末装置１０へ送信する。

【0048】

［３．端末システムにおける処理動作］
次に、端末システム１において実行される処理動作について説明する。本実施形態においては、主端末装置１０は、通常モード、検出モード、およびスリープモードの３種類のモードで動作する。通常モードは、主端末装置１０が入出力端末として用いられる場合のモードであり、ユーザからの操作入力を受け付けて、操作入力に応じた処理を実行したり、処理結果の画像をディスプレイ１６に表示したりするモードである。検出モードは、就寝中におけるユーザの生体情報を検出し、健康情報を算出するモードである。スリープモードは、通常モードおよび検出モードにおいて実行される上記の処理が実行されず、電力消費が抑えられるモードである。ただし、スリープモードにおいても主端末装置１０は副端末装置２０からの信号を受信することが可能である。

【0049】

なお、副端末装置２０は、副端末装置２０の上にユーザが乗ったことを常時検知可能である。すなわち、副端末装置２０においては、荷重センサ２１およびタッチパネル２２の少なくとも一方が常時起動しており、副端末装置２０の上にユーザが乗ったことを検知する。なお、他の実施形態においては、副端末装置２０は、スリープモードと、（少なくとも処理部２３が動作する）オンモードとで動作可能であってもよい。スリープモードは、処理部２３が動作せず、荷重センサ２１およびタッチパネル２２の少なくとも１つが動作するモードである。オンモードは、少なくとも処理部２３が動作するモードである。このとき、副端末装置２０は、スリープモードである状態において自身の上にユーザが乗ったことが荷重センサ２１および／またはタッチパネル２２で検知されると、オンモードに移行してもよい。

【0050】

（検出モード時の処理）
以下、端末システム１がユーザの就寝中に検出モードで動作する際の処理について説明する。ユーザの就寝前において、主端末装置１０はスリープモードまたは通常モードであるとする。このとき、ユーザが副端末装置２０に乗る（図３に示す（１）参照）と、副端末装置２０の処理部２３は、副端末装置２０の上にユーザが乗ったことを検知し、荷重センサ２１の検出結果に基づいて体重を測定する。また、処理部２３は、タッチパネル２２の検出結果に基づいてユーザの足の形を算出する。なお、他の実施形態においては、副端末装置２０はカメラを備えていてもよく、処理部２３は、カメラによって撮影された画像に基づいて足の形を算出してもよい。

【0051】

本実施形態においては、処理部２３は、算出された足の形を用いてユーザに対する認証処理を実行する（図３に示す（２）参照）。すなわち、正当なユーザの足の形を示すデータは副端末装置２０において予め登録（記憶）されており、処理部２３は、算出された足の形と、登録された足の形とが一致するか否かを判定することによって、認証を行う。２つの足の形が一致すると判定した場合、処理部２３は、認証が成功したと判断する。この場合、処理部２３は、所定の認証通知を主端末装置１０へ送信する（図３に示す（３）参照）。なお、処理部２３は、上記認証通知とともに、副端末装置２０で検出された生体情報（体重等の情報）を主端末装置１０へ送信してもよい。一方、２つの足の形が一致しないと判定した場合、処理部２３は、認証が失敗したと判断する。この場合、処理部２３は、認証通知を主端末装置１０へ送信しない。

【0052】

主端末装置１０は、上記認証通知を受信すると、スリープモードまたは通常モードから検出モードへ移行する（図３に示す（４）参照）。これ以降、ユーザの生体情報が主端末装置１０によって取得されることになる。

【0053】

検出モードが開始されると、主端末装置１０の処理部１５はまず、生体情報の検出用センサ（本実施形態ではドップラーセンサ１１）を起動し、センサの検出結果の取得を開始する。なお、検出用センサとしてカメラ１２および／マイク１３を用いる場合には、処理部１５は、カメラ１２および／マイク１３を起動してもよい。検出モード中において、ドップラーセンサ１１は継続的に検出を行い、検出結果である出力波形を継続的に出力する。処理部１５は、ドップラーセンサ１１の検出結果（出力波形）に基づいて健康情報（睡眠指標および疲労指標）を算出する。

【0054】

（健康情報の算出）
以下、ドップラーセンサ１１の検出結果に基づいて健康情報（睡眠指標および疲労指標）を算出する処理について説明する。図４は、処理部１５において健康情報を算出するための機能的構成の一例を示す機能ブロック図である。図４に示すように、処理部１５は、波形解析部３１と、睡眠算出部３２と、自律神経算出部３３と、疲労算出部３４とを含む。

【0055】

波形解析部３１は、ドップラーセンサ１１が検出した生体情報（出力波形）に基づいて、呼吸、脈拍、および体動をさらなる生体情報として算出する。ここで、従来より、ドップラーセンサ１１の出力波形を周波数に応じて分離することによって、呼吸、脈拍、および体動を表す波形を得ることができることが知られている。波形解析部３１は、周波数解析等によって出力波形を、呼吸に対応する周波数帯域と、脈拍に対応する周波数帯域と、体動に対応する周波数帯域とに分離し、分離したそれぞれの波形データを出力する。図４に示すように、波形解析部３１の出力は、睡眠算出部３２および自律神経算出部３３にそれぞれ入力される。

【0056】

睡眠算出部３２は、生体情報（呼吸、脈拍、および体動）に基づいて各種の睡眠指標を算出する。ここで、従来より、呼吸、脈拍、および体動に基づいて睡眠指標を算出する方法が知られている。本実施形態においては、睡眠算出部３２は、以下の情報を示す睡眠指標を算出する。
・睡眠潜時（入眠潜時）
・中途覚醒時間
・中途覚醒回数
・睡眠効率
・総睡眠時間
・睡眠時活動量
・睡眠ステージ
・レム睡眠時間
・ノンレム睡眠時間
・睡眠品質
なお、他の実施形態においては、上記の睡眠指標のうちのいくつかのみが算出されてもよいし、上記の睡眠指標とは異なる種類の睡眠指標が算出されてもよい。

【0057】

自律神経算出部３３は、生体情報に基づいて、自律神経（交感神経および副交感神経）の働き度合いを示す指標（自律神経指標）を算出する。具体的には、生体情報に含まれる脈拍（ＲＲ間隔）の波形を、最大エントロピー法、フーリエ変換によって周波数解析し、当該波形の高周波成分（約０．１５～０．４０［Ｈｚ］）ＨＦと低周波成分（約０．０４～０．１５［Ｈｚ］）ＬＦとを算出する。ここで、上記高周波成分ＨＦは、副交感神経の働き度合いを示すことが知られており、上記低周波成分ＬＦは、交感神経の働き度合いを示すことが知られている。また、副交感神経の働き度合いと交感神経の働き度合いとの割合によって疲労度を評価できることが知られている（例えば、特開２０１０－２０１１１３号公報参照）。したがって、自律神経算出部３３は、自律神経指標として、上記高周波成分ＨＦと低周波成分ＬＦとの割合（ＬＦ／ＨＦ）を算出する。図４に示すように、自律神経算出部３３の出力は、疲労算出部３４において入力として用いられる。

【0058】

疲労算出部３４は、上記睡眠指標および自律神経指標に基づいて、疲労指標を算出する。なお、本実施形態においては、疲労指標として、疲労の度合い（レベル）を１から５の５段階で示す疲労度が算出される。疲労指標の算出方法は任意であるが、例えば以下の方法が考えられる。

【0059】

第１の方法は、睡眠指標から疲労指標を算出する方法である。ここで、睡眠指標は、疲労度との相関があると考えられる。例えば、疲労度が高いと推測される例としては、以下が挙げられる。
・睡眠潜時が長い。
・中途覚醒時間が長い。
・中途覚醒回数が多い。
・睡眠効率が悪い。
・総睡眠時間が短い。
・レム睡眠時間とノンレム睡眠時間とのバランスが悪い（レム睡眠時間とノンレム睡眠時間との比率が、正常な範囲から外れている）。
したがって、疲労算出部３４は、睡眠指標が上記の例に該当すれば疲労度が高くなり、上記の例に該当しなければ疲労度が低くなるように、疲労度を算出する。例えば、疲労算出部３４は、上記の各項目について該当するか否かを判定し、該当する数に応じたポイントを計算し、合計のポイントに応じて疲労度を算出するようにしてもよい。このとき、疲労算出部３４は、項目毎に重みを付してポイントを計算してもよい。また、各項目について基準値（例えば、総睡眠時間について「６時間」）を設定し、算出された睡眠指標の値が基準値から離れているほどポイントが大きくなるように、ポイントが計算されてもよい。

【0060】

以上のように、本実施形態においては、生体情報に基づいて、ユーザの睡眠に関する睡眠指標が算出され、睡眠指標に基づいて疲労指標が算出される。上記のように、睡眠指標と疲労の度合いとの間には相関があると考えられるので、睡眠指標に基づいて疲労指標を算出することによって、疲労指標の精度を向上することができる。

【0061】

第２の方法は、所定期間（例えば１週間）における睡眠時間に基づいて疲労度を算出する方法である。ここで、従来より、疲労リスク管理システム（ＦＲＭＳ（Ｆａｔｉｇｕｅ Ｒｉｓｋ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ））において、睡眠時間と労働時間とに基づいて疲労度を算出する手法がある。上記手法において例えば簡易的に労働時間を一定とすることで、睡眠時間（のみ）に基づいて疲労度を算出することができる。

【0062】

第３の方法は、自律神経指標に基づいて疲労度を算出する方法である。上述のように、交感神経と副交感神経との働き度合いのバランス、すなわち、上記の自律神経指標を用いて疲労度を評価できることが知られている。したがって、疲労算出部３４は、例えば、自律神経指標の値が基準値から離れるほど疲労度が高くなるように疲労度を算出する。

【0063】

本実施形態においては、疲労算出部３４は、上記３つの方法を用いて疲労度を算出する。具体的には、疲労算出部３４は、上記３つの方法でそれぞれ疲労度を算出し、算出された各疲労度に基づいて最終的な疲労度を算出する。疲労算出部３４は、例えば、３つの疲労度の平均値を最終的な疲労度としてもよいし、３つのうちいずれかの疲労度に重みを付して最終的な疲労度を算出してもよい。

【0064】

なお、他の実施形態においては、疲労指標の算出方法は任意であり、疲労指標の内容も任意である。他の実施形態においては、疲労指標として、疲労の種類毎に疲労度合いを示す値が算出されてもよい。例えば、他の実施形態においては、疲労指標は、急性疲労の度合いを示す値と、累積疲労の度合いを示す値と、精神疲労の度合いを示す値という３種類の値であってもよい。

【0065】

また、他の実施形態においては、カメラ１２および／またはマイク１３の検出結果を用いて健康情報を算出してもよい。例えば、カメラ１２で撮像されたユーザの画像に基づいて、脈拍および／または体動といった生体情報を算出することが可能である。したがって、処理部１５は、ドップラーセンサ１１の検出結果から得られるこれらの生体情報に加えて（または代えて）、カメラ１２による撮像画像から得られる生体情報を用いて睡眠指標（および疲労度）を算出してもよい。また、処理部１５は、マイク１３で検出されるいびきの音を考慮して睡眠指標を算出してもよい。

【0066】

図５は、主端末装置１０の処理部１５において実行される処理の流れの一例を示すフローチャートである。なお、図５においては、主に検出モードにおける処理が示されており、通常モードおよびスリープモードにおける処理は示されていない。

【0067】

なお、本出願において、図面（図５、図１６、図１７、および図３２）に示すフローチャートにおける各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。また、本明細書では、上記フローチャートの各ステップの処理を処理部のＣＰＵが実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。

【0068】

図５に示すステップＳ１において、処理部１５は、副端末装置２０からデータの受信を確認する。なお、ステップＳ１の実行時点では、主端末装置１０はスリープモードまたは通常モードである。スリープモードまたは通常モードにおいては、処理部１５は、ステップＳ１（およびＳ２）の処理を所定時間に１回の割合で繰り返し実行する。

【0069】

ステップＳ２において、処理部１５は、検出モードに移行するか否かを判定する。すなわち、処理部１５は、上記ステップＳ１で副端末装置２０から上述の認証通知を受信した場合、検出モードに移行すると判定し、認証通知を受信しなかった場合、検出モードに移行しないと判定する。ステップＳ２の判定結果が肯定である場合、ステップＳ３の処理が実行される。一方、ステップＳ２の判定結果が否定である場合、ステップＳ１の処理が再度実行される。

【0070】

ステップＳ３において、処理部１５は、主端末装置１０の動作モードを検出モードに移行させる。すなわち、処理部１５はドップラーセンサ１１を起動する。続くステップＳ４において、処理部１５は、ドップラーセンサ１１の検出結果を取得する。さらに、続くステップＳ５において、処理部１５は、検出結果に基づいて呼吸、脈拍、および体動をさらなる生体情報として算出する。検出モードにおいては、ステップＳ４～Ｓ６の一連の処理が所定時間に１回の割合で繰り返し実行される。したがって、検出モード中において、生体情報が繰り返し取得（算出）されて、処理部１５のメモリに逐次記憶される。

【0071】

ステップＳ６において、処理部１５は、検出モードを終了するか否かを判定する。本実施形態においては、検出モードを終了するか否かの判定は、ユーザが就寝中でなくなったか否かによって行われる。具体的には、処理部１５は、ドップラーセンサ１１の検出結果に基づいて、ドップラーセンサ１１の検出範囲からユーザがいなくなったか否かを判定する。そして、ユーザがいなくなった場合、処理部１５は、ユーザが就寝中でなくなったと判断し、検出モードを終了すると判定する。一方、ドップラーセンサ１１の検出範囲内にユーザがいる場合、処理部１５は、ユーザが就寝中であると判断し、検出モードを終了しないと判定する。ステップＳ６の判定結果が肯定である場合、ステップＳ７の処理が実行される。一方、ステップＳ６の判定結果が否定である場合、ステップＳ４の処理が再度実行される。

【0072】

ステップＳ７において、処理部１５は、ドップラーセンサ１１の検出結果に基づいて健康情報を算出する。すなわち、上記“（健康情報の算出）”の欄で述べたように、生体情報に基づいて睡眠指標および疲労指標が算出される。続くステップＳ８において、処理部１５は、ステップＳ７で算出された健康情報をデータサーバ２へ送信する。このように、本実施形態においては、健康情報は、自動的に（ユーザの操作を必要とせずに）生成されてデータサーバ２へ送信される。なお、他の実施形態においては、端末システム１からデータサーバ２へ送信される情報は、ユーザによる送信操作に応じて送信されてもよい。また、処理部１５は、上記認証通知とともに副端末装置２０から受信される情報（体重等の生体情報）を、健康情報とともにデータサーバ２へ送信してもよい。

【0073】

ステップＳ９において、処理部１５は、主端末装置１０の動作モードをスリープモードに移行させる。すなわち、処理部１５はドップラーセンサ１１の動作を停止させる。ステップＳ９によってスリープモードへと移行した後は、上述したステップＳ１の処理が再度実行される。

【0074】

以上のように、本実施形態においては、センサ（ドップラーセンサ１１）の検出結果である生体情報に基づいて健康情報を算出する処理は、端末（端末システム１）側で実行されたが、この処理は、端末側とサーバ側とでどのように分担されてもよい。例えば、他の実施形態においては、端末システム１は、生体情報をデータサーバ２へ送信し、データサーバ２が生体情報に基づいて健康情報を算出するようにしてもよい。なお、このとき、いくつかの健康情報（例えば、睡眠時間や睡眠効率等）は端末システム１においても算出され、適宜のタイミングでディスプレイ１６に表示されてもよい。これによれば、端末システム１は、データサーバ２からデータを取得しなくても、健康情報をユーザに提供することができる。また、データサーバ２が算出した健康情報が、端末システム１へ送信されて端末システム１において表示されてもよい。

【0075】

また、本実施形態において、端末システム１からデータサーバ２へ送信される健康情報は、検出モードの終了時に送信されるものとした。ここで、他の実施形態においては、端末システム１からデータサーバ２へ送信される送信情報（生体情報および／または健康情報）は、検出モード中において逐次送信されてもよい。

【0076】

（通常モードにおける処理）
本実施形態においては、主端末装置１０は、スリープモードにおいてユーザが所定の操作（例えば所定の電源ボタンを押下する操作）を行ったことに応じて、通常モードへ移行する。詳細は後述するが、通常モードでは、主端末装置１０はサービスサーバ３にアクセスして、ユーザの健康情報をディスプレイ１６に表示したり、サービスサーバ３から提供される提供情報をディスプレイ１６に表示したりする。また、主端末装置１０は、通常モードにおいてユーザが所定の操作（例えば所定の電源ボタンを押下する操作）を行ったことに応じて、スリープモードへ移行する。

【0077】

（端末システムによる作用効果）
以上のように、本実施形態においては、端末システムは、ユーザに関する第１の生体情報を検出する第１センサ（ドップラーセンサ１１）を備える第１装置（主端末装置１０）と、当該ユーザに関する生体情報であって、第１の生体情報とは異なる第２の生体情報を検出する第２センサ（荷重センサ２１）を備える第２装置（副端末装置２０）とを備える。また、端末システムは、第１の生体情報および第２の生体情報に基づく分析を行うサーバ（データサーバ２）と通信可能である。
また、端末システムは、上記第１の生体情報および第２の生体情報と、生体情報から得られる健康情報とのうち少なくとも一方を含む送信情報を、サーバ（データサーバ２）へ送信する。なお、第１の生体情報（およびそれに基づく健康情報）と、第２の生体情報（およびそれに基づく健康情報）とは、異なる装置から別々に送信されてもよい。サーバは、端末システムから送信されてくる送信情報に基づく分析を行う。
以上によって、端末システムは、２つの装置によって多くの生体情報を取得することができるので、サーバにおける分析の品質を向上することができる。すなわち、サーバにおいては、より多彩な分析あるいはより精度の良い分析を行うことができる。

【0078】

本実施形態において、上記第１センサ（ドップラーセンサ１１）は、就寝中におけるユーザの生体情報を検出し、第２センサ（荷重センサ２１）は、起床中（例えば、就寝前および起床後）におけるユーザの生体情報を検出する。これによれば、就寝中の期間においてもそうでない期間においても生体情報を取得することができるので、サーバにおける分析の品質を向上することができる。

【0079】

本実施形態において、上記第１センサは、ユーザがセンサに接触しない状態で生体情報を検出可能な非接触型のセンサであり、第２センサは、ユーザがセンサに接触した状態で生体情報を検出可能な接触型のセンサである。これによれば、就寝中においてはユーザが気にならない方法で生体情報を検出することができるとともに、起床中においてはより確実な方法で生体情報を検出することができる。

【0080】

本実施形態において、第１装置は、以下の手段を備える。
・第２センサが検出した第２の生体情報を第２装置から受信する受信手段
・第１センサが検出した第１の生体情報および第２装置から受信した第２の生体情報と、これらの生体情報に基づく健康情報とのうち少なくとも一方を含む送信情報を上記サーバ（データサーバ２）へ送信する送信手段
上記構成によれば、２つの装置で検出される生体情報（および／または健康情報）を、効率良くサーバへ送信することができる。また、第２装置はサーバとの間で通信を行う機能を有していなくてもよいので、装置の構成を簡易化することができる。

【0081】

詳細は後述するが、本実施形態において、サーバ（サービスサーバ３）は、分析結果に基づく情報（後述する提供情報）を端末システムへ送信する。第１装置は、上記サーバから送信されてくる情報を受信する受信手段と、受信された情報を表示する表示手段とを備える。これによれば、ユーザは、第１装置を用いて上記の情報を容易に閲覧することができる。また、生体情報を検出する第１装置において上記の情報が表示されるので、端末システムの構成を簡易化することができる。

【0082】

なお、他の実施形態においては、端末システム１は、提供情報を受信して表示する装置（情報端末）を主端末装置１０とは別に有していてもよい。この情報端末は、例えば、携帯端末、パーソナルコンピュータ、および、ゲーム装置等、ユーザが使用する任意の情報処理装置であってよい。例えば、ユーザの情報端末がサービスサーバ３にアクセスして提供情報を受信して表示するようにしてもよい。また、後述する商品・サービスの購入も情報端末を用いて行うことができるようにしてもよい。

【0083】

本実施形態において、第２装置は、第２の生体情報を検出したことに応じて、所定の通知（認証通知）を第１装置へ送信する。第１装置は、上記所定の通知を受信したことに応じて、第１の生体情報の検出を開始する。これによれば、第１装置において生体情報の検出動作を効率良く実行することができ、第１装置における情報処理の効率化を図ることができる。また、第１装置の省電力化を図ることができる。

【0084】

本実施形態において、第２装置は、第２の生体情報を検出したことに応じて、ユーザの生体情報（タッチパネル２２によって検出される足の形）を用いてユーザに対する認証処理を実行する。そして、第２装置は、認証処理が成功した場合（すなわち、予め登録された１以上のユーザのうちの１人のユーザであることが認証処理によって確認された場合）、上記所定の通知を第１装置へ送信する。これによれば、登録されたユーザであることが確認された場合に第１装置において生体情報の検出が開始されるので、検出処理を効率良く実行することができる。また、登録されたユーザが複数である場合には、検出処理の対象となるユーザを特定することができる。なお、認証処理に用いられる生体情報は、上記第２の生体情報であってもよいし、他の生体情報であってもよい。

【0085】

また、本実施形態においては、主端末装置１０は、副端末装置２０における認証処理が成功したことを条件として生体情報の測定（検出）を開始し、生体情報が検出されなくなったこと（ユーザが検出されなくなったこと）を条件として生体情報の測定を終了した。ここで、他の実施形態においては、生体情報の測定期間の決定方法は任意であり、他の方法で測定期間が決定されてもよい。

【0086】

例えば、他の実施形態においては、主端末装置１０は、センサ（ドップラーセンサ１１）によって間欠的に検出を行い、その検出結果に基づいて測定期間を決定してもよい。具体的には、主端末装置１０は、所定時間間隔でドップラーセンサ１１による検出を行うことによって、ユーザが検出されるか否か（ユーザが検出範囲内に存在するか否か）を判定する。ユーザが検出されない場合、主端末装置１０は、ドップラーセンサ１１による検出を停止する。この場合、測定は開始されない。一方、ユーザが検出される場合、主端末装置１０は、ドップラーセンサ１１による検出をそのまま継続することによって、測定を開始する。さらに、測定を開始した場合、主端末装置１０は、ドップラーセンサ１１によってユーザが検出される間、測定を継続する。つまり、上記実施形態と同様、主端末装置１０は、ユーザが検出されなくなったことに応じて、ドップラーセンサ１１による測定を終了する。以上によれば、ドップラーセンサ１１による測定期間を、ドップラーセンサ１１自身による（間欠的に行われる）検出結果に基づいて決定することができる。これによれば、他のセンサ等の装置を用いることなく、測定期間を決定することができるので、装置の構成を簡易化することができる。

【0087】

また、他の実施形態においては、ドップラーセンサ１１の測定期間は、ドップラーセンサ１１とは異なるセンサ（例えば人感センサ）の検出結果に基づいて決定されてもよい。例えば、端末システム１は、人感センサとして、赤外線センサおよび／またはカメラを用いてもよい。具体的には、端末システム１は、人感センサによって、間欠的に、または、連続してユーザを検知する。そして、人感センサによってユーザが検知される期間において、端末システム１は、ドップラーセンサ１１による測定を行う。これによっても、本実施形態の方法、および、上記ドップラーセンサ１１の検出結果に基づいて測定期間を決定する方法と同様、測定期間を自動的に決定することができる。すなわち、ユーザは測定（の開始および終了）のために操作を行う必要がないので、端末システム１の利便性を向上することができる。さらに言えば、ユーザに手間や負担をかけることなく生体情報の測定を行うことができるので、継続的な生体情報の取得が行いやすくなる。

【0088】

また、他の実施形態においては、ドップラーセンサ１１の測定期間は、予め定められていてもよい。例えば、端末システム１は、所定の時間帯（例えば、夜の２０時から翌朝の１０時までの時間帯）において測定を行うようにしてもよいし、（ユーザによる停止操作がない限り）測定を常時行うようにしてもよい。これによっても上記と同様、ユーザは測定の開始および終了のために操作を行う必要がないので、端末システム１の利便性を向上することができる。

【0089】

また、上記実施形態においては、端末システム１は、生体情報の測定を自動的に行うことに加えて、生体情報に基づく健康情報（睡眠指標および疲労指標）の算出を自動的に（換言すれば、ユーザによる特定の操作が無くても）行う。したがって、ユーザが特別な操作を行わなくても端末システム１において健康情報が算出されるので、端末システム１の利便性を向上することができる。

【0090】

本実施形態において、単一の装置である第１装置は、上記サーバとの間で携帯電話通信網を介して通信を行う第１通信手段（モバイル通信部１９）と、第２装置との間で近距離無線通信を行う第２通信手段（近距離無線通信部１８）とを備える。第１装置は、サーバおよび第２装置に対して容易に通信を行うことができる。

【0091】

以上のように、本実施形態における端末システム１では、非接触型のセンサ（ドップラーセンサ）を用いるので、ユーザはセンサを装着する必要が無い。また、就寝中において自動的に生体情報が測定されるので、ユーザは生体情報の測定を待つ必要が無く、測定のために煩雑な操作を行う必要も無い。さらに、就寝時のユーザの周辺にセンサを配置しておけば、測定の度に煩雑な設定作業を行う必要も無い。以上より、端末システム１によれば、ユーザに手間や負担をかけることなく生体情報の測定を行うことができるので、継続的な生体情報の取得が行いやすくなる。

【0092】

また、端末システム１は、ユーザの入眠あるいは起床（覚醒）を誘導するコンテンツ（音楽等）を再生してもよい。例えば、主端末装置１０は、ドップラーセンサ１１による検出を開始したことに応じて、ユーザに対して入眠を誘導するような音楽を再生してもよい。このとき、主端末装置１０は、ユーザの睡眠状態に応じてコンテンツの再生を制御するようにしてもよい。これによれば、ユーザの睡眠状態に応じた適切な方法でコンテンツを再生することができ、コンテンツを効果的に再生することができる。また、効果が小さいと思われる状況（例えば、ユーザが熟睡している状況）におけるコンテンツの再生を停止することによって、消費電力の低減を図ることができる。以下、一例である具体例を説明する。

【0093】

主端末装置１０は、ユーザの睡眠中において、ドップラーセンサ１１による検出結果（生体情報）に基づいてユーザの睡眠状態を判別する。例えば、主端末装置１０は、睡眠状態であるか否か、および、眠りの深さ（レム睡眠かノンレム睡眠か等）をリアルタイムに判別する。なお、上記「リアルタイムに判別する」とは、厳密な意味で即時に判別することに限らず、数秒程度の遅れを生じて判別することをも含む意味である。

【0094】

主端末装置１０は、睡眠中に判別されるユーザの睡眠状態に応じてコンテンツの再生を制御する。主端末装置１０は、コンテンツの再生／停止を睡眠状態に応じて制御してもよいし、再生方法（例えば、音量および／または再生速度等）を睡眠状態に応じて制御してもよい。例えば、主端末装置１０は、ユーザの入眠前に、ユーザに入眠を促すためのコンテンツの再生を開始しておき、ユーザが入眠したことに応じてコンテンツの再生を停止してもよい。あるいは、主端末装置１０は、ユーザが入眠したことに応じてコンテンツの再生音量を次第に減少させていき、ユーザの眠りが深くなった（例えばノンレム睡眠の状態となった）ことに応じてコンテンツの再生を停止してもよい。また例えば、主端末装置１０は、ユーザが覚醒したタイミングに応じて、コンテンツ（例えば、ユーザに覚醒を促すためのコンテンツ）の再生を開始してもよいし、ユーザがもうすぐ覚醒すると推測されるタイミングに応じて、コンテンツの再生を開始してもよい。

【0095】

なお、端末システム１においてユーザの睡眠時に再生されるコンテンツは、端末システム１に記憶されていてもよいし、外部装置（例えばサービスサーバ３）から取得されてもよい。例えば、サービスサーバ３は、商品・サービスの提供に関する提供処理（後述するステップＳ２２）において、上記コンテンツを端末システム１へ送信するようにしてもよい。

【0096】

［４．情報処理システムにおける処理動作］
次に、情報処理システムにおいて実行される処理動作について説明する。図６は、情報処理システムにおける動作の流れの一例を示すタイミングチャートである。以下では、大略的には次のような動作が情報処理システムにおいて行われる場合の処理動作を例として説明する。
＜１＞端末システム１において取得された健康情報がデータサーバ２へ繰り返し送信されて蓄積される。
＜２＞サービスサーバ３は、データサーバ２に蓄積された健康情報を用いて、商品・サービスを紹介する提供情報を生成して端末システム１へ提供する。
＜３＞端末システム１において提供情報を閲覧したユーザが、提供情報で紹介された商品・サービスを購入（無料の商品・サービスの場合には、商品・サービスを利用（享受）する旨の申し込み）する。
＜４＞商品・サービスの購入後、サービスサーバ３は、データサーバ２に蓄積された健康情報を用いて、追加の提供情報を生成して端末システム１へ提供する。

【0097】

ここで、本実施形態において、サービスサーバ３は、ポータルサーバ４１と、サービス提供サーバ４２とを含む。ポータルサーバ４１は、データサーバ２に蓄積された健康情報や上述した提供情報をユーザに提供するためのポータルサイトを管理するサーバである。ポータルサーバ４１は、データサーバ２へアクセスし、データサーバ２に蓄積された健康情報を用いて提供情報を生成してユーザ（端末システム１）に提供する機能を有する。

【0098】

また、サービス提供サーバ４２は、商品・サービスをユーザに提供する処理を実行するためのサーバである。ここで、本実施形態においては、サービス提供サーバ４２によって提供される商品・サービスの購入は、ポータルサーバ４１によって管理される。すなわち、上記ポータルサイトは、サービス提供サーバ４２によって提供される商品・サービスを販売するためのショッピングサイトの機能を有している。ユーザは、端末システム１を用いてポータルサイトにアクセスし、当該ポータルサイト内で上記商品・サービスを購入する。なお、典型的には、サービス提供サーバ４２は、個々の商品・サービスを提供するサービス事業者によって管理され、ポータルサーバ４１は、データサーバ２を管理する管理事業者によって管理される。サービス提供サーバ４２は、例えばサービス事業者毎に複数のサーバが設けられてもよい。

【0099】

＜１＞健康情報がデータサーバに蓄積される処理
上記“［３．端末システムにおける処理動作］”で述べたように、端末システム１は、健康情報をデータサーバ２へ送信（アップロード）する（図６に示すステップＳ１１）。本実施形態においては、端末システム１は、予めユーザ毎に設定されたユーザ識別情報とともに健康情報を送信する。なお、図６では図示を省略するが、端末システム１からデータサーバ２への健康情報の送信は、定期的に（本実施形態においては１日１回）継続して行われる。

【0100】

データサーバ２は、端末システム１から受信した健康情報をユーザ毎に記憶する。図７は、データサーバ２に記憶されるデータの一例を示す図である。図７に示すように、データサーバ２は、上記ユーザ識別情報と健康情報とを含むユーザ情報を、ユーザ毎に記憶する。すなわち、データサーバ２は、あるユーザの端末システム１から健康情報を受信すると、受信した健康情報を、当該あるユーザに関するユーザ情報内の健康情報に追加する。これによって、健康情報がデータサーバ２に蓄積される。

【0101】

また、データサーバ２は、適宜のタイミングで、受信した健康情報に基づいて２次情報を算出する（ステップＳ１２）。つまり、データサーバ２は健康情報を分析して２次情報を得る。上述のように、本実施形態においては、２次情報は、受信した健康情報から算出される統計量の情報である。例えば、２次情報として１週間の平均睡眠時間を算出する場合、データサーバ２は、１週間分の睡眠時間のデータが蓄積される度に、当該平均睡眠時間を算出する。本実施形態においては、２次情報も健康情報としてデータサーバ２において蓄積される。

【0102】

なお、図７に示すように、データサーバ２には、利用管理テーブルが記憶されるが、この利用管理テーブルについては後述する。

【0103】

＜２＞サービスサーバ３が提供情報を端末システム１へ提供する処理
端末システム１は、ユーザの指示に応じて、サービスサーバ３のポータルサーバ４１が管理するポータルサイトにアクセスする（ステップＳ１３）。すなわち、ユーザは、主端末装置１０を通常モードにして、ポータルサイトにアクセスする操作を行う。ポータルサイトへログインする方法は任意であり、従来と同様の方法が用いられてもよい。本実施形態においては、ログイン画面がディスプレイ１６に表示され、ユーザはユーザ識別情報とパスワードとを入力する。ポータルサーバ４１は、ユーザ識別情報とパスワードとを用いて認証を行い、認証が成功した場合、端末システム１（のユーザ）はポータルサイトにログインすることができる。

【0104】

なお、他の実施形態においては、ポータルサイトへのログインは、端末システム１において行われた個人認証を用いて行われてもよい。例えば、副端末装置２０において認証が成功した場合に、主端末装置１０がポータルサイトへアクセスしてログインが行われるようにしてもよい。このとき、主端末装置１０は、ユーザ識別情報およびパスワードの入力をユーザに要求しなくてもよい。

【0105】

ポータルサーバ４１は、ユーザの認証が成功した場合、ポータルサイトのメインページを端末システム１に送信してディスプレイ１６に表示させる。詳細は後述するが、メインページには、ユーザに対して提供する提供情報が含まれる。したがって、ユーザの認証が成功した場合、ポータルサーバ４１は、ユーザに対して提供する提供情報を生成する処理を実行する（ステップＳ１４～Ｓ１８）。

【0106】

提供情報の内容は、データサーバ２に記憶されている、ユーザの健康情報に基づいて決定される。そのため、ポータルサーバ４１は、まず、提供情報を決定するために必要な健康情報を利用する要求（利用要求）をデータサーバ２に対して行う（ステップＳ１４）。利用要求で要求される健康情報は、ポータルサーバ４１に記憶されている提供条件テーブルを用いて決定される。

【0107】

ここで、ポータルサーバ４１に記憶されるデータについて説明する。図８は、ポータルサーバ４１に記憶されるデータの一例を示す図である。図８に示すように、ポータルサーバ４１は、ユーザ毎のユーザ情報、提供条件テーブル、および、追加提供条件テーブルを記憶している。まず、ステップＳ１４の処理に関連するユーザ情報および提供条件テーブルについて説明し、追加提供条件テーブルの詳細については後述する。

【0108】

ポータルサーバ４１に記憶されるユーザ情報は、上述のユーザ識別情報、個人情報、およびユーザ提供履歴情報を含む。個人情報は、例えば、ユーザの名前、生年月日、年齢、および性別等、（生体情報を除く）ユーザ個人に関する情報である。ユーザ提供履歴情報は、ユーザに対してすでに提供された（提供済みの）提供情報の履歴を示す。ユーザ提供履歴情報の詳細は後述する。

【0109】

提供条件テーブルは、上記ステップＳ１４において、提供情報を生成するために必要な健康情報を決定するために用いられる。なお、提供条件テーブルは、予め設定されてポータルサーバ４１に記憶されるが、提供条件テーブルの内容は適宜のタイミングで更新されてもよい。

【0110】

図９は、提供条件テーブルの一例を示す図である。図９に示すように、提供条件テーブルは、提供条件と、提供内容とを関連付けたテーブルである。提供条件は、提供情報を提供する条件を示す。提供内容は、それに関連付けられる提供条件が満たされる場合に提供される提供情報の内容を示す。なお、図９においては、提供内容としては、例えば「商品Ａの紹介」等、提供情報の内容自体を示す情報が設定されるものとしている。ただし、ポータルサーバ４１において用意されている各提供情報にそれぞれ識別番号が付されている場合には、提供内容として、当該識別番号を示す情報が設定されてもよい。

【0111】

図９に示すように、本実施形態においては、提供条件は、ユーザ条件と健康条件とを含む。ユーザ条件は、提供情報を提供するユーザに関する条件である。ユーザ条件としては、「４０代男性」や「３０代男女」のように、ユーザ情報に含まれる個人情報に関する条件が設定される。

【0112】

健康条件は、提供情報を提供するユーザの健康（健康情報）に関する条件である。また、図９に示すように、健康条件には、健康条件の判定に利用される健康情報を示す利用情報が含まれる。利用情報は、図９に示す「（最近１週間の）平均疲労度」のように、データサーバ２に記憶される健康情報を加工した２次情報を示すものであってもよい。また、利用情報は、「（最近１週間の）疲労度」のように、健康情報自体（の種類）を示す情報であってもよい。つまり、利用要求は、健康情報を加工した２次情報を要求するものであってもよいし、健康情報自体を要求するものであってもよい。

【0113】

健康条件としては、例えば、「（最近１週間の平均疲労度が）４以上」や、「（最近１週間の平均睡眠時間が）５時間以下」のように、疲労指標や睡眠指標に関する条件が設定される。健康条件は、健康情報自体（例えば疲労度）に関する条件であってもよいし、当該健康情報から得られる情報（例えば平均疲労度）に関する条件であってもよい。

【0114】

また、健康条件は、１種類の健康情報に関する１つの条件で構成されるものに限らず、２種類以上の健康情報に関する複数の条件で構成されてもよい。例えば、健康条件は、疲労指標に関する条件と、睡眠指標に関する条件とから構成されてもよい。また、副端末装置２０で得られた情報（生体情報および／または生体情報から算出される健康情報）が主端末装置１０を介してデータサーバへ送信される場合、健康条件は、当該情報に関する条件を含んでいてもよい。

【0115】

上記ステップＳ１４において、ポータルサーバ４１は、上記の提供条件テーブルを用いて、データサーバ２に要求する健康情報を決定する。すなわち、ポータルサーバ４１は、提供条件テーブル内の提供条件を判定するために用いられる健康情報を特定し、特定された健康情報をデータサーバ２に要求する。具体的には、ポータルサーバ４１は、提供条件テーブルに含まれる各提供条件のうちで、ユーザ条件が満たされる提供条件を特定し、当該提供条件に含まれる利用情報を特定する。例えば、図９に示す提供条件テーブルが用いられる場合において、ポータルサイトにログインしたユーザが４０代の男性であった場合には、「最近１週間の平均疲労度」を示す利用情報が特定される。したがって、ポータルサーバ４１は、「最近１週間の平均疲労度」を要求する利用要求をデータサーバ２へ送信する。なお、ユーザ条件が満たされる提供条件が複数種類あった場合には、ポータルサーバ４１は、当該複数の提供条件に関連付けられる各利用情報を特定し、特定した利用情報が示す健康情報を要求する利用要求を送信する。

【0116】

なお、他の実施形態においては、提供条件テーブル内の提供条件と提供内容との組は、複数のグループに分類されていてもよい。例えば、上記組は、提供情報の内容（紹介される商品・サービス）、提供情報で紹介される商品・サービスのジャンル、提供情報で紹介される商品・サービスを提供する事業者、および／または、提供情報で紹介される商品・サービスの金額等に応じて複数のグループに分類されていてもよい。このとき、ポータルサーバ４１は、ユーザに予めグループを選択させておき、選択されたグループ内の組に含まれる提供条件のみについて、上記の利用情報を特定する処理を実行するようにしてもよい。例えば、上記組が商品・サービスのジャンル毎にグループに分類される場合において、睡眠を改善するためのグッズ（枕やアイマスク等）のジャンルと、疲労を解消するサプリメントのジャンルが設定されていてもよい。このとき、ユーザがサプリメントのジャンルのみを選択していた場合には、ポータルサーバ４１は、提供条件テーブルのうち、このジャンルに含まれる提供条件を処理対象として、利用情報を特定する処理を実行してもよい。これによれば、ユーザが選択したジャンルに含まれる提供情報のみがユーザに提供されることになり、ユーザが興味を持っているジャンルについて効果的に提供情報を提供することができる。また、利用情報を特定する処理によるポータルサーバ４１の処理負担を軽減することができる。

【0117】

また、提供条件テーブルは、ユーザがどのような健康状態にあるときに、どのような商品・サービスを紹介するかを表すものである。そのため、サービス提供側（サービス提供サーバ４２）が、提供条件テーブルの内容を変更することができるようにしてもよい。すなわち、ポータルサーバ４１は、サービス提供サーバ４２からの要求に応じて、提供条件テーブルの内容を変更してもよい。

【0118】

以上のように、ポータルサーバ４１からデータサーバ２へ送信される利用要求は、要求する健康情報を示す情報を含む。図１０は、利用要求の一例を示す図である。図１０に示すように、利用要求は、要求情報と、ユーザ識別情報と、サービス識別情報とを含む。要求情報は、取得を要求する健康情報を示す情報であり、上記特定された利用情報に基づいて決められる。本実施形態においては、要求情報は、取得を要求する健康情報の種類と、その健康情報が端末システム１において取得された時間（期間）とを含む。

【0119】

ユーザ識別情報は、取得する健康情報に対応するユーザを示す。すなわち、利用要求に含まれるユーザ識別情報は、利用要求によってどのユーザの健康情報を取得するかを示している。

【0120】

サービス識別情報は、サービス提供サーバによって提供される商品・サービスに対して付される識別情報である。サービス識別情報は、商品・サービスを提供するサービス事業者毎に設定されてもよいし、商品・サービスの種類毎に設定されてもよい。利用要求に含まれるサービス識別情報は、当該利用要求で要求される健康情報に対応する提供情報（提供条件テーブルにおいて当該健康情報を示す利用情報に関連付けられる提供内容）によって決められる。つまり、サービス識別情報は、提供情報に対応しているとも言える。本実施形態において、利用要求に含まれるサービス識別情報は、当該利用要求で要求される健康情報に対応する提供情報によって紹介される商品・サービスに対して付されたサービス識別情報、あるいは、当該商品・サービスを提供するサービス事業者に対して付されたサービス識別情報である。

【0121】

なお、ポータルサーバ４１は、提供条件テーブルに含まれる提供内容（あるいは、提供内容によって特定される商品・サービス、または、サービス事業者）に対してサービス識別情報を関連付けたテーブルを予め記憶している。ポータルサーバ４１は、このテーブルを参照して、利用要求に含めるべきサービス識別情報を特定する。

【0122】

利用要求を受信すると、データサーバ２は、利用要求に対する認証処理を行う（ステップＳ１５）。この認証処理は、利用要求に含まれる要求情報が示す健康情報が、当該利用要求に含まれるサービス識別情報が示すサービスにおいて利用可能か（換言すれば、提供情報の生成のために利用可能か）否かを判定する処理である。本実施形態において、上記認証処理は、データサーバ２に記憶されている利用管理テーブル（図７参照）を用いて行われる。

【0123】

図１１は、利用管理テーブルの一例を示す図である。図１１に示すように、利用管理テーブルは、サービス識別情報と、利用可能情報とを関連付けたテーブルである。利用可能情報は、データサーバ２に記憶される健康情報および２次情報のうち、当該利用可能情報に関連付けられるサービス識別情報が示す商品・サービスのために利用可能な（利用が許可される）情報を示す。利用可能情報は、例えば、「睡眠指標・疲労指標」、「全情報」、あるいは「睡眠指標」のように、健康情報の種類を示すものであってもよい。また、利用可能情報は、「最近１月の睡眠指標」のように、時系列で記憶される健康情報のうちで利用可能な健康情報の期間（換言すれば、健康情報が取得された時期）を示すものであってもよい。また、図１１には示していないが、利用可能情報は、例えば、「２０１３年１２月１日から２０１４年１２月１日まで利用可能」のように、サービスサーバ３が健康情報を利用することができる期間を示すものであってもよい。つまり、利用管理テーブルの利用可能情報は、健康情報の種類に関する条件を示すものであってもよいし、健康情報の取得時期に関する条件を示すものであってもよいし、健康情報の利用期間（利用可能期間）に関する条件を示すものであってもよい。図１１に示す例においては、商品Ａに対応するサービス識別情報には、睡眠指標と疲労指標とが利用可能であることを示す利用可能情報が関連付けられた組が含まれる。この組は、商品Ａを紹介する提供情報のために、睡眠指標および疲労指標が利用可能であることを表している。

【0124】

ステップＳ１５の認証処理において、データサーバ２は、受信した利用要求に含まれる要求情報が示す健康情報と、当該利用要求に含まれるサービス識別情報に対して（利用管理テーブルにおいて）関連付けられている利用可能情報が示す健康情報と一致するか否かを判定する。両者が一致する場合、データサーバ２は、認証成功と判断し、後述するステップＳ１６およびＳ１７の処理を実行する（図６参照）。一方、図示しないが、両者が一致しない場合、データサーバ２は、認証失敗と判断し、ステップＳ１６およびＳ１７の処理を実行しない。この場合、データサーバ２は、認証が失敗した旨の通知をポータルサーバ４１へ送信する。この場合、ポータルサーバ４１は、提供情報を生成せず、後述のＳ１９においてユーザには提供情報が提供されない（提供情報を含まないメインページが提供される）。

【0125】

認証が成功した場合、ポータルサーバ４１は、利用要求に応じた分析処理を実行する（ステップＳ１６）。上述のように、利用要求で要求される健康情報は、例えば「最近１週間の平均疲労度」のように、データサーバ２に記憶される健康情報を分析（加工）した結果得られる情報であることがある。このような場合、ポータルサーバ４１は、健康情報を分析する処理によって、利用要求で要求される健康情報を算出する。例えば、最近１週間の平均疲労度が要求される場合には、利用要求に含まれるユーザ識別情報が示すユーザの健康情報のうちで、最近１週間の疲労度から平均値が算出される。なお、利用要求で要求される健康情報が、端末システム１から取得された健康情報自体である場合、または、上記ステップＳ１２の分析処理によってすでに算出された２次情報である場合、ステップＳ１６では分析処理が実行されなくてもよい。

【0126】

次に、データサーバ２は、利用要求で要求された健康情報をポータルサーバ４１へ送信する（ステップＳ１７）。これによって、ポータルサーバ４１は健康情報を取得することができる。

【0127】

以上のように、本実施形態においては、サービスサーバ３は、提供情報を生成する場合、当該提供情報の生成に用いる情報の要求（利用要求）をデータサーバ２に対して行う。そして、データサーバ２は、サービスサーバ３からの要求に応じて、記憶されている情報（生体情報および／または健康情報）をサービスサーバへ送信する。これによれば、ユーザから取得した情報をデータサーバ２において管理するとともに、データサーバ２において記憶される情報をサービスサーバ３において利用することができる。

【0128】

さらに、本実施形態においては、上記利用要求は、提供情報の生成に用いる情報を示す要求情報と、データサーバ２に記憶される情報の利用に関する識別情報（サービス識別情報）とを含む。データサーバ２は、サービスサーバ３からの利用要求に含まれる識別情報に基づいて、当該要求に含まれる要求情報が示す情報を提供情報の生成のために利用が許可されるか否かを判定し、許可されると判定される場合、要求情報が示す情報をサービスサーバへ送信する。これによれば、データサーバ２は、サービスサーバ３による蓄積情報の利用を管理・制御することができ、サービス識別情報に応じて利用可能な情報の種類を異なるように管理・制御することができる。

【0129】

データサーバ２から健康情報を受信すると、ポータルサーバ４１は、受信した健康情報に基づいて提供情報を生成する（ステップＳ１８）。すなわち、ポータルサーバ４１は、受信した健康情報を用いて、上記提供条件テーブルにおいて提供条件（ユーザ条件および健康条件）が満たされる提供情報を特定する。例えば、図９に示す提供条件テーブルが用いられる場合において、４０代男性のユーザについて最近１週間の平均疲労度として４以上の値が受信された場合、商品Ａを紹介する提供情報が特定される。なお、提供条件が満たされる提供内容がなかった場合、提供情報は生成されず、提供情報は送信されない。また、ステップＳ１８の処理において特定される提供情報は、複数であってもよい。

【0130】

なお、上記ステップＳ１８の処理において、ポータルサーバ４１は、特定した提供情報についての履歴を記憶する。すなわち、ポータルサーバ４１は、ログインしたユーザについてのユーザ情報に含まれるユーザ提供履歴情報（図８参照）の内容を更新する。

【0131】

図１２は、ユーザ提供履歴情報の一例を示す図である。本実施形態において、ユーザ提供履歴情報は、提供内容情報と、提供日情報と、購入情報と、追加提供タイミング情報とからなる組の情報を含む。ユーザ提供履歴情報に含まれる提供内容情報は、上述の提供条件テーブルにおける提供内容と同様、ユーザに提供された提供情報の内容を示す。提供日情報は、それに関連付けられる提供情報が提供された時点（ここでは年月日）を示す。なお、本実施形態においては年月日を示す提供日情報が記憶されるが、年月日に加えて時刻を示す情報が記憶されてもよい。

【0132】

また、購入情報は、それに関連付けられる提供情報が紹介する商品・サービスの購入の有無を示す。また、追加提供タイミング情報は、それに関連付けられる提供情報の提供後に、提供情報の追加提供を行うか否か、および、追加提供を行う場合には追加提供を行うタイミングを示す。追加提供タイミング情報については後述する。

【0133】

上記ステップＳ１８の処理においては、ポータルサーバ４１は、特定した提供情報について、上記の組の情報をユーザ提供履歴情報に追加する。具体的には、ポータルサーバ４１は、ステップＳ１８の処理において特定した提供情報を示す提供内容情報と、当該提供情報を提供する年月日を示す提供日情報と、購入無しを示す購入情報と、追加提供無しを示す追加提供タイミング情報とをユーザ提供履歴情報に追加する。なお、ステップＳ１８の処理では、購入情報は「購入無し」、追加提供タイミング情報は「追加提供無し」を示すように記憶されるが、後述するように、これらの情報は商品等の購入があった場合に更新される。

【0134】

次に、ポータルサーバ４１は、特定した提供情報を含むウェブページを作成して端末システム１へ送信する（ステップＳ１９）。本実施形態においては、このウェブページは、端末システム１がポータルサイトにアクセス（ログイン）して最初に表示されるメインページ（トップページまたはホームページとも言う）である。ただし、他の実施形態においては、提供情報を含むページはメインページでなくてもよい。上記メインページが端末システム１で受信されると、主端末装置１０のディスプレイ１６においてメインページが表示される。これによって、ユーザに対して提供情報が提供されたことになる。

【0135】

図１３は、端末システムにおいて表示されるメインページの一例を示す図である。図１３に示すように、メインページは、提供情報欄５１と、履歴閲覧欄５２とを含む。提供情報欄５１には、提供情報（図１３では、商品として枕を紹介する情報）が表示される。本実施形態においては、提供情報欄５１内に表示される内容が提供情報によって規定される。なお、図１３においては、提供情報欄５１には１種類の提供情報のみが含まれるが、複数の提供情報が含まれていてもよい。

【0136】

提供情報欄５１は、提供情報に係る商品を購入するための購入ボタン５３を含む。すなわち、ユーザが購入ボタン５３を指定する入力を行うと、商品を購入するための商品購入ページがディスプレイ１６に新たに表示され、ユーザは商品を購入することができる。本実施形態においては、商品購入ページは、ポータルサーバ４１によって提供されるページ（ポータルサイト内のページ）であるとする。ただし、他の実施形態においては、サービス提供サーバによって提供されるページ（ポータルサイト外のページ）であってもよい。つまり、上記購入ボタン５３は、サービス提供サーバによって提供される商品購入ページへのリンクを示すものであってもよい。

【0137】

履歴閲覧欄５２は、データサーバ２に記憶されている健康情報の履歴を参照するために設けられる。本実施形態においては、履歴閲覧欄５２は、年月を示すボタンを含んでおり、ユーザがこのボタンを指定する入力を行うことで、指定された年月の健康情報を表示するページがディスプレイ１６に表示される。

【0138】

上記のように、本実施形態においては、サービスサーバ３は、ユーザの健康情報が示す指標を改善するための商品またはサービスに関する情報を含む提供情報を生成する。これによって、商品・サービスに関する有用な情報をユーザに提供することができる。また、サービスサーバ３は、商品・サービスをユーザが購入するためのウェブページの情報、または、当該ウェブページのリンク情報を含む提供情報を生成する。これによれば、ユーザは、商品・サービスを紹介する提供情報が提供された場合に、提供された商品・サービスを簡単な操作で購入することができ、ユーザの利便性を向上することができる。

【0139】

＜３＞商品の購入に関する処理
次に、メインページで表示された提供情報が示す商品をユーザが購入した場合における処理を説明する。上記商品購入ページにおいてユーザが商品を購入する操作入力を行うと、端末システム１は、購入指示の通知をポータルサーバ４１へ送信する（ステップＳ２０）。この購入指示の通知は、ユーザ識別情報と、購入する商品を識別する情報とを含んでいる。購入指示の通知を受信すると、ポータルサーバ４１は、購入に係る商品を提供するサービス提供サーバ４２へ購入通知を送信する（ステップＳ２１）。購入通知は、上記購入指示の通知に含まれていた、ユーザ識別情報と、購入する商品を識別する情報とを含んでいる。

【0140】

ポータルサーバ４１から購入通知を受信すると、サービス提供サーバ４２は、商品・サービスの提供に関する提供処理を実行する（ステップＳ２２）。例えば、ネットワークを介してデータを商品・サービスとして提供する場合、上記提供処理は、例えば当該商品またはサービスに係るデータを送信する処理である。なお、「商品またはサービスに係るデータ」とは、例えば音楽データや食事のレシピ、アプリケーションのデータ等である。「商品またはサービスに係るデータ」は、例えば、主端末装置１０の照明部１７に、ユーザの入眠あるいは起床を誘導する照明を行わせるためのデータ（アプリケーション）であってもよい。端末システム１がスピーカを備える場合には、ユーザの入眠あるいは起床を誘導する音楽を当該スピーカから出力させるためのデータ（アプリケーション）であってもよい。

【0141】

また、実際の物である商品（例えば、枕やアイマスク等の睡眠改善グッズ）を提供する場合には、提供処理は、例えば、商品の購入受け付けた旨の通知をユーザの端末システム１へ送信する処理や、商品を配送する通知をユーザの端末システム１へ送信する処理である。また、実際にサービス（例えば、マッサージ等）を提供する場合には、提供処理とは、サービスの購入を受け付けた旨の通知をユーザの端末システム１へ送信する処理や、サービスを提供する日時の通知をユーザの端末システム１へ送信する処理である。例えば、サービスサーバ３は、提供情報によってマッサージサービスを紹介し（例えば、ユーザの周辺のマッサージ店を紹介する）、ポータルサイト上でマッサージの予約（マッサージサービスの購入）を行うようにしてもよい。

【0142】

上記のように、サービスサーバ３は、商品またはサービスをユーザが購入する指示が端末システム１からあったことに応じて、当該商品またはサービスに係るデータを当該端末システム１へ送信してもよい。

【0143】

また、購入指示の通知を受信すると、ポータルサーバ４１は、商品が購入されたことを反映するように、購入指示を行ったユーザに関するユーザ提供履歴情報（図１２）を更新する（ステップＳ２３）。具体的には、ポータルサーバ４１は、購入指示に係る商品を紹介する提供情報に関連付けられる購入情報を「購入有り」を示す内容に更新する。また、ポータルサーバ４１は、当該提供情報に関連付けられる追加提供タイミング情報を、追加の提供情報を提供するタイミングを示す内容に更新する。

【0144】

ここで、本実施形態においては提供情報で紹介された商品・サービスが購入された場合、購入後において新たな提供情報が提供される。以下では、このように新たに追加して提供される提供情報を「追加提供情報」と呼ぶ。追加提供情報の内容は、最初の提供情報の内容とは異なる内容であってもよいし、同じ内容であってもよい。詳細は後述するが、追加提供情報の内容は、商品・サービスが購入された後でアップロードされたユーザの健康情報に基づいて決定される。

【0145】

上記ステップＳ２３では、追加提供情報の提供タイミングが決定され、ユーザ提供履歴情報内の追加提供タイミング情報は、決定されたタイミングを示す内容に更新される。ポータルサーバ４１は、提供された提供情報に応じて追加提供情報の提供タイミングを決定する。本実施形態においては、追加提供情報の提供タイミングは、ポータルサーバ４１に記憶されている追加提供条件テーブル（図８参照）を用いて決定される。

【0146】

図１４は、追加提供条件テーブルの一例を示す図である。追加提供条件テーブルは、追加提供情報の内容およびタイミングを決定するためのテーブルである。図１４に示すように、追加提供条件テーブルは、前回提供内容と、追加提供タイミングと、追加提供条件と、追加提供内容とを関連付けたテーブルである。追加提供条件テーブルは、提供条件テーブルと同様、予め設定されてポータルサーバ４１に記憶されるが、追加提供条件テーブルの内容が適宜のタイミングで更新されてもよい。また、提供条件テーブルと同様、サービス提供側（サービス提供サーバ４２）が、追加提供条件テーブルの内容を変更することができるようにしてもよい。

【0147】

前回提供内容は、前回に提供された提供情報の内容であり、換言すれば、追加提供情報が提供される起因となった提供情報の内容である。追加提供タイミングは、追加提供のタイミング、すなわち、追加提供タイミングに関連付けられる追加提供情報を提供するタイミングを示す。本実施形態においては、追加提供タイミングは、例えば、「購入後２週間」や「購入後１月」のように、商品・サービスが購入されてからの時間を示す。ただし、他の実施形態においては、追加提供タイミングは、前回に提供情報が提供された時点からの時間を示してもよいし、商品を実際に使用した時点やサービスを実際に受けた時点がポータルサーバ４１に取得される場合には、これらの時点からの時間を示してもよい。なお、追加提供条件および追加提供内容の詳細については後述する。

【0148】

ステップＳ２３においては、ポータルサーバ４１は、購入された商品を紹介する提供情報を特定し、特定された提供情報を示す前回提供内容に（追加提供条件テーブルにおいて）関連付けられる追加提供タイミングを特定する。ポータルサーバ４１は、特定された追加提供タイミングに基づいて、追加提供を行う時点（ここでは年月日）を算出する。ユーザ提供履歴情報内の追加提供タイミング情報は、算出された年月日の情報に更新される。例えば、現在（購入時点）が２０１３年１２月６日であり、特定された追加提供タイミングが「購入後２週間」であった場合、２０１３年１２月２０日を示す情報が追加提供タイミング情報として記憶される。

【0149】

＜４＞商品・サービスの購入後に追加提供情報が提供される処理
以上のように、本実施形態においては、商品・サービスが購入された場合、購入された商品・サービスを紹介する提供情報に基づいて、追加提供情報を提供するタイミングが決定される。ここで、ポータルサーバ４１は、各ユーザのユーザ提供履歴情報を定期的に参照することによって、追加提供タイミングが到来したか否かを定期的に判定する。そして、追加提供タイミングが到来したと判定された場合、ポータルサーバ４１は、追加提供タイミングが到来した追加提供情報をユーザに提供するための処理（図６に示すＳ２４～Ｓ２９）を実行する。つまり、商品の購入から所定期間（追加提供条件テーブルにおける追加提供タイミングによって特定される期間）が経過すると、上記処理が実行される（図６参照）。

【0150】

具体的には、提供タイミングが到来した追加提供情報がある場合、ポータルサーバ４１は、追加提供情報を決定するために必要な健康情報の利用を要求する利用要求をデータサーバ２へ送信する（ステップＳ２４）。なお、追加提供情報を決定するために必要な健康情報とは、追加提供情報の追加提供条件（図１４参照）を判定するために用いられる健康情報である。ステップＳ２４の処理においては、追加提供情報を決定するために必要な健康情報は、ポータルサーバ４１に記憶されている追加提供条件テーブルを用いて決定される。

【0151】

ここで、図１４に示すように、追加提供条件テーブルにおいては、前回提供内容と、（追加提供タイミングと、）追加提供条件と、追加提供内容とが関連付けられる。追加提供条件は、それに関連付けられる前回提供内容が示す提供情報について、追加提供情報が提供される条件（追加提供条件）を示す。

【0152】

追加提供条件は、追加提供条件の判定に利用される健康情報を示す利用情報を含む。この利用情報は、上記提供条件に含まれる利用情報と同様である。ただし、追加提供条件に含まれる利用情報は、例えば、「最近１週間の平均疲労度と、購入前１週間の平均疲労度」のように、商品・サービスの購入前および購入後の両方の健康情報を指定するように設定される場合がある。

【0153】

追加提供条件は、ユーザの健康情報に関する条件である。具体的には、追加提供条件は、「疲労度が改善」や「疲労度の改善無し」のように、健康情報の変化（健康情報が示すユーザの状態の変化）に関する条件であってもよい。また、追加提供条件は、上述した健康条件（図９参照）と同様であってもよく、例えば「最近１週間の平均睡眠時間が５時間以下」のように、健康情報が示すユーザの状態に関する条件が追加提供条件として設定されてもよい。

【0154】

追加提供内容は、それに関連付けられる追加提供条件が満たされる場合に提供される追加提供情報の内容を示す。追加提供条件テーブルに含まれる追加提供内容としては、上述の提供条件テーブルにおける提供内容と同様、提供情報の内容自体を示す情報が設定されてもよいし、提供情報に付される識別番号を示す情報が設定されてもよい。

【0155】

上記ステップＳ２４において、まず、ポータルサーバ４１は、ユーザ提供履歴情報を参照して、提供タイミングが到来した追加提供情報に対応する提供情報を特定する。すなわち、ポータルサーバ４１は、ユーザ提供履歴情報において、提供タイミングが到来した追加提供タイミング情報に関連付けられる提供内容情報が示す提供情報を特定する。

【0156】

次に、ポータルサーバ４１は、上記特定された提供情報に対応する追加提供情報の追加提供条件を特定する。すなわち、ポータルサーバ４１は、追加提供条件テーブルを参照して、上記特定された提供情報を示す前回提供内容に関連付けられる追加提供条件を特定する。そして、ポータルサーバ４１は、特定された追加提供条件に含まれる利用情報を特定し、特定された利用情報が示す健康情報を取得する利用要求をデータサーバ２へ送信する。すなわち、当該健康情報を示す要求情報を含む利用要求がデータサーバ２へ送信される。例えば、図１４に示す追加提供条件テーブルが用いられる場合において、「商品Ａの紹介」を示す提供情報が特定された場合を考える。この場合、「最近１週間の平均疲労度、購入前１週間の平均疲労度」を示す利用情報が特定されるので、この利用情報が示す健康情報を取得する利用要求をデータサーバ２へ送信する。

【0157】

なお、ステップＳ２４で送信される利用要求は、上記ステップＳ１４で送信される利用要求と同様、要求情報と、ユーザ識別情報と、サービス識別情報とを含む。これら３つの情報の内容は、上記ステップＳ１４の処理と同様の方法で決定される。なお、例えば、「最近１週間の平均疲労度と、購入前１週間の平均疲労度」を示す利用情報が特定される場合のように、要求情報が、購入時点を基準とした所定期間における健康情報を示す場合がある。この場合、ポータルサーバ４１は、上記所定期間を算出するために、ユーザ提供履歴情報の提供日情報が示す日を購入日として用いてもよいし、商品購入時の日付を予め記憶しておき、記憶しておいた日付を購入日として用いてもよい。

【0158】

ポータルサーバ４１からの利用要求に応じて、データサーバ２は、上記ステップＳ１５～Ｓ１７と同様の処理を実行する。すなわち、データサーバ２は、利用要求に対する認証処理を行い（Ｓ２５）、認証が成功した場合には、利用要求に応じた分析処理を、必要に応じて実行する（ステップＳ２６）。そして、利用要求で要求された健康情報をポータルサーバ４１へ送信する（ステップＳ２７）。

【0159】

データサーバ２から健康情報を受信すると、ポータルサーバ４１は、受信した健康情報に基づいて追加提供情報を生成する（ステップＳ２８）。すなわち、ポータルサーバ４１は、受信した健康情報を用いて、上記ステップＳ２４で特定された追加提供条件が満たされるか否かを判定する。そして、ポータルサーバ４１は、追加提供条件が満たされる追加提供内容の追加提供情報を生成する。なお、追加提供条件が満たされる追加提供内容がなかった場合、追加提供情報は生成されない。また、ステップＳ２８の処理において特定される追加提供情報は、複数であってもよい。

【0160】

図１５は、追加提供条件の判定方法の一例を示す図である。図１５に示すように、本実施形態においては、毎日取得された健康情報（図では疲労度）がデータサーバ２に記憶されている。上述のように、本実施形態においては、追加提供条件が満たされるか否かは、商品・サービスの購入前後の健康情報を比較することによって判定される場合がある。この場合には、まず、購入後におけるユーザの健康情報として、現在から過去の所定期間における健康情報が分析されるとともに、購入前におけるユーザの健康情報として、購入時から過去の所定期間における健康情報が分析される。例えば、図１５に示すように、データサーバ２は、ポータルサーバ４１からの利用要求に応じて、最近１週間の疲労度の平均と、購入前１週間の疲労度の平均とを分析結果として算出する。ポータルサーバ４１は、購入前における健康情報の分析結果（購入前１週間の平均疲労度）と、購入後における健康情報の分析結果（最近１週間の平均疲労度）とを比較することで、ユーザの健康状態が改善されたか否かを判定する。例えば、平均疲労度が所定値以上低減していれば、ポータルサーバ４１は、ユーザの健康状態（疲労度）が改善されたと判定し、平均疲労度が所定値よりも低減していなければ、ポータルサーバ４１は、ユーザの健康状態（疲労度）が改善されなかったと判定する。そして、ポータルサーバ４１は、判定結果に応じて異なる内容の追加提供情報を生成する。例えば、図１４に示す追加提供条件テーブルの例においては、最近１週間の平均疲労度と、購入前１週間の平均疲労度とに基づいて、疲労度が改善されたと判定されれば、商品Ｄを紹介する追加提供情報が生成される。また、疲労度が改善されなかったと判定されれば、商品Ｅを紹介する追加提供情報が生成される。

【0161】

上記のように、本実施形態においては、健康状態を分析するユーザについて蓄積された時系列データである複数の健康情報に基づいて分析（健康情報が取得された時間を考慮した時系列分析）が行われる。これによって、ユーザの健康状態の変化を知ることができるので、このような分析に基づいた提供情報を提供することによって、有用な情報を提供することができる。

【0162】

また、本実施形態においては、提供情報に含まれる商品またはサービスが購入された後で端末システムが取得した健康情報に基づく、当該商品またはサービスによる（健康状態の）改善効果に応じた追加提供情報を生成する。これによれば、商品・サービスによる効果を判断することができるとともに、判断結果に応じて適切な提供情報を提供することができる。

【0163】

上記のように、本実施形態においては、データサーバ２は、所定の基準時点（購入時点）の以前に端末システム１が取得した情報に基づく健康状態と、当該基準時点より後に端末システム１が取得した情報に基づく健康状態とを比較することによって分析を行う。これによれば、提供情報（または、提供情報で提供された商品・サービス）による健康状態の変化を精度良く分析することができ、かかる分析に応じた提供情報を生成することで、提供内容を有用なものにすることができる。

【0164】

なお、上記所定の基準時点は、例えば提供情報で紹介された商品・サービスの購入時点であるが、提供情報がユーザに提供されたことに起因する任意の時点でよい。例えば、基準時点は、提供情報が提供された時点であってもよい。また例えば、ユーザが商品の使用を開始した時点、および／または、ユーザがサービスの提供を受けた時点をサーバ側で知ることができる場合には、これらの時点が基準時点となってもよい。

【0165】

追加提供情報が生成されると、ポータルサーバ４１は、追加提供情報を端末システム１へ送信する（ステップＳ２９）。追加提供情報を送信する方法は任意であるが、本実施形態においては、追加提供情報がある旨のメッセージがプッシュ通知で端末システム１へ送信される。すなわち、ポータルサーバ４１は、追加提供情報が生成されると、ユーザによる操作が行われなくても（ポータルサイトにアクセスしなくても）メッセージが通知される方法で、メッセージを送信する。すなわち、上記メッセージを受けた端末システム１は、ユーザによる操作とは独立してメッセージをディスプレイ１６に表示する。このメッセージに応じて、ユーザは、端末システム１を用いてポータルサイトにアクセスする。そして、ユーザがポータルサイトにログインすると、ポータルサーバ４１は、追加提供情報が含まれるメインページを生成して端末システム１へ送信する。これによって、追加提供情報がユーザに対して提供されたことになる。

【0166】

上記のように、サービスサーバ３は、追加提供情報が生成されたことに応じて、ユーザの端末（端末システム１における端末装置（主端末装置１０））へ、当該端末装置に対するユーザの操作とは独立したタイミングで、追加提供情報の通知（上記メッセージ）を送信する。なお、他の実施形態においては、追加提供情報自体がプッシュ通知で端末システム１へ送信されてもよい。すなわち、ユーザによる操作とは独立して追加提供情報がポータルサーバ４１から端末システム１へ送信されてもよい。換言すれば、追加提供情報は、ポータルサイトへのアクセス無しに端末システム１において表示されるようにしてもよい。このように、追加提供情報の通知または追加提供情報がプッシュ通知で端末システム１へ送信されることによって、追加提供情報が生成されたことを適切なタイミングでユーザに通知することができる。

【0167】

また、他の実施形態においては、上記のメッセージは送信されなくてもよい。この場合、ポータルサーバ４１で追加提供情報が生成された時点ではユーザに通知されず、ユーザが次にポータルサイトへアクセスした際に追加提供情報が提供されることになる。

【0168】

なお、他の実施形態においては、（追加提供情報ではない）提供情報についても追加提供情報と同様、プッシュ通知が行われてもよい。すなわち、サービスサーバ３は、端末装置に対するユーザの操作とは独立したタイミングで、（追加提供情報ではない）提供情報の通知、または、提供情報自体を送信してもよい。より具体的には、ポータルサーバ４１は、所定の条件が満たされたことに応じて（例えば、所定の時刻となったことに応じて）、ステップＳ１４およびＳ１８の処理を実行するようにしてもよい。

【0169】

以上のようにして、本実施形態においては、提供情報が提供された後に追加提供情報が提供される。ここで、提供情報が提供された後において、端末システム１からの情報（健康情報）の分析処理と、分析結果に基づく追加提供情報の生成処理とが繰り返し実行されてもよい。例えば、ポータルサーバ４１は、追加提供条件テーブル（図１４参照）における追加提供タイミングとして、繰り返し到来するようなタイミング（例えば、商品の購入後２週間毎のタイミング）を設定してもよい。これによれば、上記の分析処理と生成処理が、当該タイミングが到来する毎に繰り返し実行されることになる。また例えば、ポータルサーバ４１は、追加提供条件テーブルにおける追加提供内容で示される提供情報を前回提供内容として含む組（前回提供内容と、追加提供タイミングと、追加提供条件と、追加提供内容との組）を設定してもよい。例えば、図１４に示す追加提供条件テーブルにおいて、商品Ｄを紹介する提供情報が前回提供内容として設定される組が設定されてもよい。これによれば、追加提供情報の提供に応じて商品Ｄをユーザが購入した場合、その後にさらなる追加提供情報が提供されることになる。以上のように、分析処理と生成処理とが繰り返されることによって、有用な情報を継続的にユーザに提供することができる。

【0170】

（データサーバ２における処理）
図１６は、データサーバ２において実行される処理の流れの一例を示すフローチャートである。本実施形態において、データサーバ２は、図１６に示すステップＳ３０～Ｓ３７の一連の処理を繰り返し実行する。この一連の処理は、データサーバ２が有する処理部であるＣＰＵが、データサーバ２が有するプログラム記憶部に記憶される所定の情報処理プログラムを実行することによって行われる。なお、データサーバ２が複数の情報処理装置によって構成される場合には、各情報処理装置のＣＰＵが分担して上記一連の処理を実行するようにしてもよい。

【0171】

まずステップＳ３０において、データサーバ２の処理部は、端末システム１から健康情報を受信したか否かを判定する（図６に示すＳ１１参照）。ステップＳ３０の判定結果が肯定である場合、ステップＳ３１の処理が実行され、ステップＳ３０の判定結果が否定である場合、後述するステップＳ３４の処理が実行される。

【0172】

ステップＳ３１において、処理部は、端末システム１から受信した健康情報を、データサーバ２が有する記憶部にユーザ毎に記憶する（図７参照）。ステップＳ３２において、処理部は、受信した健康情報に基づいて２次情報を算出するか否かを判定する。この判定は、例えば、２次情報を算出するタイミングが到来したか否か、あるいは、２次情報を算出するための健康情報が蓄積されたか否か等によって行われる。ステップＳ３２の判定結果が肯定である場合、ステップＳ３３の処理が実行され、ステップＳ３２の判定結果が否定である場合、後述するステップＳ３４の処理が実行される。

【0173】

ステップＳ３３において、処理部は、受信した健康情報に基づいて２次情報を算出し、データサーバ２が有する記憶部に、算出した２次情報を記憶する（図６に示すＳ１２参照）。以上のように、データサーバ２は、複数のユーザのいずれかから健康情報を受信する度に健康情報を記憶し（ステップＳ３１）、必要に応じて２次情報を算出して記憶する。

【0174】

ステップＳ３４において、処理部は、ポータルサーバ４１から利用要求を受信したか否かを判定する（図６に示すＳ１４，Ｓ２４参照）。ステップＳ３４の判定結果が肯定である場合、ステップＳ３５の処理が実行され、ステップＳ３４の判定結果が否定である場合、上記ステップＳ３０の処理が再度実行される。

【0175】

ステップＳ３５において、処理部は、ステップＳ３４で受信した利用要求に対する認証処理を実行し（図６に示すＳ１５，Ｓ２５参照）、認証が成功したか否かを判定する。ステップＳ３５の判定結果が肯定である場合、ステップＳ３６の処理が実行され、ステップＳ３５の判定結果が否定である場合、ステップＳ３７の処理が実行される。

【0176】

ステップＳ３６において、処理部は、利用要求で要求された健康情報をポータルサーバ４１へ送信する。すなわち、処理部は、記憶部に記憶されている健康情報に対して必要に応じて分析を行い、当該健康情報および／または分析結果である健康情報をポータルサーバ４１へ送信する（図６に示すＳ１６，Ｓ１７，Ｓ２６，Ｓ２７参照）。

【0177】

一方、ステップＳ３７において、処理部は、認証が失敗した旨の通知をポータルサーバ４１へ送信する。上記ステップＳ３６またはＳ３７の処理が完了すると、上記ステップＳ３０の処理が再度実行される。以上に示したＳ３０～Ｓ３７の処理によって、図６に示すデータサーバ２における動作が実現される。

【0178】

（ポータルサーバ４１における処理）
図１７は、ポータルサーバ４１において実行される処理の流れの一例を示すフローチャートである。ポータルサーバ４１は、図１７に示すステップＳ４１～Ｓ４９の一連の処理を繰り返し実行する。この一連の処理は、ポータルサーバ４１が有する処理部であるＣＰＵが、ポータルサーバ４１が有するプログラム記憶部に記憶される所定の情報処理プログラムを実行することによって行われる。なお、ポータルサーバ４１が複数の情報処理装置によって構成される場合には、各情報処理装置のＣＰＵが分担して上記一連の処理を実行するようにしてもよい。

【0179】

まずステップＳ４１において、ポータルサーバ４１の処理部は、端末システム１からのアクセスがあり、端末システム１のユーザによるログインが行われたか否かを判定する（図６に示すＳ１３）。ステップＳ４１の判定結果が肯定である場合、ステップＳ４２の処理が実行され、ステップＳ４１の判定結果が否定である場合、後述するステップＳ４４の処理が実行される。

【0180】

ステップＳ４２において、処理部は提供情報を生成する（図６に示すＳ１４，Ｓ１８参照）。ステップＳ４３において、処理部は、提供情報を含むメインページを生成して端末システム１へ送信する（図６に示すＳ１９参照）。なお、このとき、すでに生成されている追加提供情報であってまだ提供していない追加提供情報がある場合、処理部は、提供情報に加えて追加提供情報を含むメインページを生成する。なお、提供情報と追加提供情報とは、互いに区別可能な態様で（例えば、ページにおける表示位置、および／または、表示形態が異なるように）提供される。また、図示しないが、端末システム１においてメインページが表示されてから、ユーザがポータルサイトをログアウトするまでの期間においては、ユーザによる入力に応じてウェブページ（例えば健康情報の履歴が示すページ）を端末システム１に表示させる処理が適時実行される。

【0181】

ステップＳ４４において、処理部は、ポータルサイトにおいて提供情報で紹介された商品が購入されたか否かを判定する。この判定は、購入指示の通知を端末システム１から受信したか否かによって行われる。ステップＳ４４の判定結果が肯定である場合、ステップＳ４５の処理が実行され、ステップＳ４４の判定結果が否定である場合、後述するステップＳ４７の処理が実行される。

【0182】

ステップＳ４５において、処理部は、サービス提供サーバ４２へ購入通知を送信する（図６に示すＳ２１参照）。また、ステップＳ４６において、処理部は、商品の購入が行われたことを反映するように、ユーザ提供履歴情報を更新する（図６に示すＳ２３参照）。上述したように、このとき、追加提供情報の提供タイミングが決定される。

【0183】

ステップＳ４７において、処理部は、追加提供情報の提供タイミングが到来したか否かを判定する（図６に示すＳ２４参照）。ステップＳ４７の判定結果が肯定である場合、ステップＳ４８の処理が実行され、ステップＳ４７の判定結果が否定である場合、上記ステップＳ４１の処理が再度実行される。

【0184】

ステップＳ４８において、処理部は、提供タイミングが到来した追加提供情報を生成する（図６に示すＳ２８参照）。ステップＳ４９において、処理部は、追加提供情報があることをユーザに通知するための上記メッセージを端末システム１へ送信する（図６に示すＳ２９参照）。このメッセージが端末システム１において表示されたことに応じてユーザがポータルサイトへログインすると、上述のステップＳ４３の処理によってポータルサーバ４１から追加提供情報を含むメインページが端末システム１へ送信され、当該メインページが端末システム１において表示されることになる。ステップＳ４９の処理が完了すると、上記ステップＳ４１の処理が再度実行される。以上に示したＳ４１～Ｓ４９の処理によって、図６に示すポータルサーバ４１における動作が実現される。

【0185】

［５．本実施形態における作用効果］
以上のように、本実施形態においては、端末システム１は、健康情報をサーバシステム（サーバ側のシステム。上記実施形態では、データサーバ２およびサービスサーバ３）へ送信する。また、サーバシステムは、端末システム１からの送信情報（健康情報）を受信し、受信した送信情報をユーザと関連付けて記憶する。

【0186】

ここで、サーバシステムは、上記送信情報から得られる指標または送信情報に含まれる指標（ユーザに関する健康情報が示す指標、具体的には、睡眠指標、疲労指標）を改善するために当該ユーザに提供する提供情報を送信情報の分析結果に基づいて生成し、端末システム１へ送信する（Ｓ１８，Ｓ１９）。また、サーバシステムは、提供情報がユーザに提供された後で端末システム１が取得した送信情報の分析結果に基づいて、提供済みの提供情報とは異なる追加の提供情報を生成して端末システム１へ送信する（Ｓ２８，Ｓ２９）。

【0187】

上記によれば、１回目に提供情報が提供され、その後で取得された健康情報に基づいてユーザ状態が分析され、分析結果に基づいて新たな提供情報が生成される。これによれば、１回目の提供情報による効果（効果の有無を含む）を考慮して２回目の提供情報を提供することができるので、有用な情報をユーザに提供することができる。例えば、１回目の提供情報で紹介した商品・サービスが購入された場合に、購入後の健康情報に基づいて商品・サービスの効果を判断し、効果に応じた２回目の提供情報を提供することができるので、有用な情報をユーザに提供することができる。

【0188】

また、本実施形態においては、サーバシステム（データサーバ２）は、端末システムから受信した送信情報および当該送信情報から得られる情報（健康情報）をユーザと関連付けて記憶情報として記憶する（本実施形態では、蓄積する）。そして、データサーバ２は、記憶情報を用いて端末システムのユーザに対して提供情報を提供するサービスサーバ３から、記憶情報を提供情報の生成のために利用する要求（利用要求）として、提供情報の生成に用いる情報を示す要求情報と、当該提供情報に関するサービスを識別するためのサービス識別情報とを含む利用要求を受信する（Ｓ１４、Ｓ２４、図１０）。データサーバ２は、サービスサーバ３から受信された利用要求に含まれるサービス識別情報に基づいて、当該利用要求に含まれる利用情報が示す情報を提供情報の生成のために利用することが許可されるか否かを判定し（Ｓ１５，Ｓ２５）、許可されると判定される場合、記憶情報に基づく情報であって要求情報が示す情報をサービスサーバ３へ送信する。

【0189】

上記によれば、サーバシステムは、サービスサーバによる記憶情報の利用を管理・制御することができる。例えば、サーバシステムは、サービス識別情報に応じて利用可能な情報の種類ごとに記憶情報の利用を管理・制御することも可能である。このように、記憶情報の利用を管理・制御することによって、サーバシステムは、サービスサーバに記憶情報を利用させ、利用に応じた対価を請求するサービスを提供することができる。例えば、上記実施形態においては、データサーバ２およびポータルサーバ４１を管理する管理事業者は、サービス提供サーバ４２を管理するサービス事業者に対して記憶情報を利用させるサービスを提供することができる。

【0190】

また、サーバシステムは、サービス識別情報と、記憶情報に基づく情報であって当該サービス識別情報が示すサービスのために利用が許可される情報を示す利用許可情報（利用可能情報）とを関連付けた関連付け情報（利用管理テーブル）を記憶する。上記の判定は、関連付け情報に基づいて行われる。これによって、判定を容易に行うことができる。

【0191】

また、本実施形態において、サーバシステムは、サービスサーバから受信された利用要求に含まれる要求情報が示す情報を利用可能であるか否かを、記憶情報の種類、記憶情報の取得時期、および／または、記憶情報の利用期間に関する条件に基づいて判定する（Ｓ１５）。これによれば、記憶情報の種類および／または記憶情報の取得時期によって記憶情報の利用を管理することができる。また、記憶情報に利用期間を設定することができる。また、上記管理事業者がサービス事業者に対して上記のような記憶情報を利用させるサービスを行う場合、上記管理事業者は、例えば、利用可能な記憶情報に応じて記憶情報の利用料を設定することができる。

【0192】

また、本実施形態においては、サーバシステム（ポータルサーバ４１）は、商品・サービスを紹介する提供情報を送信情報に基づいて生成し（Ｓ１９）、提供情報が提供されたユーザから、当該提供情報により示される商品・サービスを購入する旨の購入指示を受け付ける（Ｓ２０）。これによれば、サーバシステムは、商品・サービスに関する提供情報を提供するだけでなく、提供情報によって紹介された商品・サービスを提供するサービスを行うことができる。また、ユーザは、サーバシステムから提供された商品・サービスを、当該サーバシステムに対する指示によって購入することができるので、購入の利便性を向上することができる。

【0193】

さらに、本実施形態においては、サービスサーバ３におけるポータルサーバ４１は、購入指示を受け付けたことに応じて所定の購入通知をサービス提供サーバ４２へ送信する。そして、サービス提供サーバ４２は、購入通知を受信したことに応じてサービス提供処理（Ｓ２２）を実行する。これによれば、商品・サービスの提供を行うサービス事業者側でサービス提供サーバ４２によってサービス提供処理を行うとともに、管理事業者側ではポータルサーバ４１によって商品・サービスの購入を管理することができる。

【0194】

また、本実施形態においては、情報処理システムは、ユーザの疲労を示す指標を算出する。すなわち、情報処理システムは、非装着型のセンサ（ドップラーセンサ１１）から生体情報を自動的に取得し、取得された生体情報を記憶する（Ｓ５）。そして、情報処理システムは、記憶されている生体情報に基づいて、ユーザの疲労指標を算出する（Ｓ７）。これによれば、ユーザに測定を意識させることなく、ユーザの疲労度合いを測定することができる。

【0195】

なお、端末システム１は、センサから生体情報を繰り返し取得する。そして、繰り返し取得された生体情報が蓄積記憶され、蓄積記憶された生体情報に基づいて、ユーザの疲労指標が算出される。これによって、これによれば、ユーザの疲労度合いを継続的に測定することができる。

【0196】

［６．変形例］
（提供条件を自動的に更新する変形例）
上記実施形態の変形例においては、提供条件は、各ユーザから取得された健康情報に基づいて自動的に更新されてもよい。ここで、提供情報で紹介された商品・サービスが購入された後で取得された健康情報は、当該商品・サービスをユーザが使用した後の健康状態を反映しているので、この健康情報から、当該商品・サービスをユーザが使用した効果を推測することができる。本変形例においては、ポータルサーバ４１は、このような効果に基づいて、提供条件を更新する。これによって、ユーザにとってより効果的な提供情報を提供することができる。以下、本変形例の詳細について説明する。

【0197】

本変形例においては、ポータルサーバ４１は、提供条件を更新するための条件更新テーブルを記憶している。図１８は、条件更新テーブルの一例を示す図である。図１８に示すように、条件更新テーブルは、提供内容と、更新条件と、更新内容とを提供情報毎に関連付けたテーブルである。提供内容は、提供条件テーブルにおける提供内容と同様、提供情報の内容を示す。

【0198】

更新条件は、提供情報に関する提供条件（提供条件テーブルにおいて当該提供情報に関連付けられる提供条件）を更新する条件を示す。本変形例においては、更新条件は、データ数条件と変更条件とを含む。データ数条件は、提供情報で紹介された商品・サービスの効果を示す効果情報のデータ数に関する条件である。ここで、効果情報は、商品・サービスの購入後に取得された健康情報の分析結果であり、例えば、追加提供条件を判定するために用いられた健康情報である。ポータルサーバ４１は、ある提供情報について商品・サービスが購入されたことに応じて、その後に追加提供条件が判定された場合、当該判定に用いられた健康情報を効果情報として記憶しておく。したがって、複数のユーザが上記商品・サービスが購入すると、購入したユーザの数に応じた数の効果情報がポータルサーバ４１に取得（記憶）されることになる。

【0199】

データ数条件は、上記のようにして記憶された効果情報の数（データ数）に関する条件である。データ数条件としては、例えば、「１００人分の効果情報が取得されたこと」を示す条件が設定される。

【0200】

変更条件は、データ数条件に係る効果情報に関する条件である。変更条件としては、例えば、「効果有りを示す効果情報が所定数以上であったこと」を示す条件が設定される。

【0201】

本変形例においては、ポータルサーバ４１は、ある提供情報について効果情報が記憶されたことに応じて、当該提供情報に係る提供条件を更新するか否かを判定する。具体的には、ポータルサーバ４１は、条件更新テーブルにおいて、当該提供情報の提供内容に関連付けられるデータ数条件を特定し、記憶されている効果情報のデータ数が、特定されたデータ数条件を満たすか否かを判定する。例えば、図１８に示す条件更新テーブルが用いられる場合には、ポータルサーバ４１は、記憶されている効果情報のデータ数が、１００に達したか（１００人分のユーザの効果情報が得られたか）否かを判定する。上記判定の結果、データ数条件が満たされないと判定した場合、ポータルサーバ４１は、提供条件を更新しないと判定する。

【0202】

一方、データ数条件が満たされたと判定した場合、ポータルサーバ４１は、記憶されている効果情報に基づいて、変更条件が満たされるか否かを判定する。例えば、図１８に示す条件更新テーブルが用いられる場合、ポータルサーバ４１は、記憶されている（１００個の）効果情報のうち、効果有りを示す効果情報が所定数（例えば７０）以上あるか否かを判定する。なお、「効果有りを示す効果情報」とは、例えば図１４に示した「疲労度が改善」という追加提供条件の判定結果が肯定となるような健康情報である。つまり、本変形例においては、効果情報が効果有りを示すか否かは、追加提供条件の判定結果に基づいて判断することができる。

【0203】

変更条件が満たされると判定した場合、ポータルサーバ４１は、当該変更条件に関連付けられる更新内容に従って、提供条件テーブルを更新する。ここで、更新内容は、例えば、「閾値を０．１減少する」のように、提供情報に対応する提供条件の更新内容を示す。例えば、図９に示す提供条件テーブルにおける上から１行目の提供条件「（最近１週間の平均疲労度が）４以上」について、図１８に示す更新内容「閾値を０．１減少する」に従って更新行われた場合には、更新後の提供条件は、「（最近１週間の平均疲労度が）３．９以上」となる。なお、更新内容は、提供条件を緩くするものであっても、厳しくするものであってもよい。

【0204】

なお、上記変形例においては、提供条件テーブルを更新する場合を例として説明したが、サービスサーバ３は、追加提供条件テーブルを更新するようにしてもよい。

【0205】

なお、上記変形例においては、変更条件が満たされたことに応じて提供条件テーブルの更新が行われるので、変更条件が繰り返し満たされることによって、更新は繰り返し（換言すれば、継続的に）行われることになる。

【0206】

以上のように、サーバシステムは、各端末システムから受信した送信情報および／または当該送信情報から得られる情報（健康情報）をユーザと関連付けて記憶情報として記憶する。また、サーバシステムは、記憶情報から得られる指標または記憶情報に含まれる指標を改善するために当該ユーザに提供する提供情報の生成に関する条件（生成すべき提供情報の内容を決定するための条件、具体的には、提供条件または追加提供条件）を記憶する。そして、サーバシステムは、記憶情報とこの条件とに基づいて提供情報を生成する。ここで、サーバシステムは、提供情報の提供を受けた複数のユーザに関する、当該提供情報の提供後に取得された送信情報に関する分析を行い、分析結果（上記効果情報）に基づいて上記条件を（自動的に）更新する。このように、条件を更新することによって、より効果的な提供情報を提供することができる。

【0207】

なお、上記変形例においては、提供条件を更新するために用いられる「提供情報の提供後に取得された情報」として、提供条件によって紹介される商品・サービスを購入した後に取得された情報が用いられる。つまり、「提供情報の提供後に取得された情報」として、提供情報の提供に起因して行われる所定の動作のタイミングよりも後に取得された情報が用いられてもよい。この所定の動作のタイミングとしては、上記変形例における「（提供条件によって紹介される）商品・サービスを購入したタイミング」、または、「（提供条件によって紹介される）商品・サービスを利用したタイミング」等が考えられる。

【0208】

また、上記条件（提供条件）は、健康情報に関する少なくとも１つの健康条件を含む。これによって、ユーザの健康情報に応じた提供情報を提供することができる。ここで、サーバシステムは、提供情報の提供後に取得された情報の分析結果に基づいて健康条件を更新する。これによって、提供情報の提供後におけるユーザの健康状態を分析し、その分析結果に応じて健康条件を更新することができる。

【0209】

また、上記変形例においては、端末システム１は、ユーザの生体情報を繰り返し取得し、また、送信情報を繰り返しサーバシステムへ送信する。サーバシステムは、複数のユーザの各端末システム１から送信情報を繰り返し受信して蓄積記憶し、蓄積記憶された記憶情報に基づいて提供条件を継続的に（繰り返し）更新する。そして、更新された条件に基づいて提供情報が生成される。図１９は、上記変形例による効果を説明するための図である。本変形例のように、提供条件が更新されることによって、サービスサーバ３は、より効果的な提供情報をユーザに対して提供することができる。そして、効果的な提供情報を提供することができれば、提供情報を提供するサービスを利用するユーザがより増えると期待できるので、データサーバ２は、より多くのユーザに関する健康情報を取得することができる。そして、より多くの健康情報を取得することができれば、提供条件をより効果的なものに更新することができる。このように、提供条件を自動的に更新することによって好循環が生じ、より効果的な提供情報を提供することができる。

【0210】

また、サーバシステムは、所定数の上記分析結果が算出可能となったことに応じて（所定人数分の分析結果を得ることができるようになったことに応じて）、上記条件を更新するか否かを判定する。これによれば、所望の量の分析結果が得られる場合に条件を更新するか否かが判定されるので、更新によって条件を精度良く改善することができる。

【0211】

なお、提供条件テーブルおよび更新条件テーブルの内容は上記に限らない。例えば、提供条件は、提供情報（提供内容）に対して付された優先順位（優先レベル）を含むものであってもよく、一度に複数の提供条件が満たされた場合には優先順位が高い（優先レベルが最も高い）提供情報が提供（生成）されるようにしてもよい。このとき、更新条件テーブルに含まれる更新内容は、優先順位を変更するものであってもよい。例えば、提供情報による改善効果があること（健康情報が示す指標が改善されたこと）を示す変更条件が満たされた場合には、優先順位を高くなるように変更されてもよい。具体的には、優先レベルが高いものから順に“５”から“１”までの優先レベルが設定されており、商品Ａを紹介する提供情報について優先レベルが“３”である場合において、更新条件テーブルは、商品Ａに関して改善効果があることを示す変更条件が満たされた場合には、優先レベルを“４”に変更するものであってもよい。

【0212】

また、上述のように、提供条件は、健康情報に関する複数の条件（項目）を含んでいてもよい。このとき、更新条件テーブルに含まれる更新内容は、項目の追加または削除を行うものでもよいし、項目に付された重みを変更するものであってもよい。

【0213】

（提供条件に関する変形例）
上記実施形態においては、提供情報を決定するための提供条件（提供条件テーブル）に加えて、追加提供情報を決定するための追加提供条件（追加提供条件テーブル）が設定される場合を例として説明した。ここで、他の実施形態においては、提供情報を決定するための提供条件のみが設定されるようにしてもよい。このとき、提供条件の内容が自動的に更新されてもよい。以下、上記実施形態の変形例として、提供条件テーブル（のみ）が設定され、提供条件が自動的に更新される例について説明する。

【0214】

図２０は、上記実施形態の変形例における提供条件テーブルの一例を示す図である。図２０に示すように、本変形例において、提供条件テーブルは、提供条件と、提供内容と、次回提供タイミングとを関連付ける。

【0215】

本変形例において、提供条件は、上述のユーザ条件および健康条件を含む複数の条件で構成される。具体的には、図２０において、提供条件は、ユーザの年齢に関するユーザ条件と、健康情報（ここでは睡眠指標）に関する３種類の健康条件とを含む。すなわち、提供条件は、総睡眠時間の最近１週間の平均に関する条件と、睡眠効率の最近１週間の平均に関する条件と、中途覚醒回数の最近１週間の平均に関する条件とを含む。なお、提供内容によってはこれらの条件全てが設定される必要は無い。例えば図２０に示す「商品Ｃの紹介」を示す提供内容に関連付けられる提供条件のように、提供内容によっては、複数の条件のうちのいくつかの条件が設定されなくてもよい。また、提供条件に含まれる条件は、上記に限らず、他のユーザ条件および／または他の健康条件を含んでもよいし、ユーザ条件および健康条件とは異なる他の条件（例えば、商品・サービスの購入履歴に関する条件等）を含んでいてもよい。このように、他の実施形態においては、提供条件は、複数のユーザ条件を含んでいてもよいし、健康条件を１つのみ含んでいてもよい。

【0216】

提供内容は、上記実施形態と同様、それに関連付けられる提供条件が満たされる場合に生成（提供）される提供情報の内容を示す。

【0217】

次回提供タイミングは、それに関連付けられる提供内容の提供情報が提供された場合に、その後において提供情報を（再度）提供する（正確には、提供情報を提供するか否かを判定する）タイミングを示す。本実施形態においては、次回提供タイミングは、上述の追加提供タイミング（図１４）と同様、商品・サービスが購入されてからの時間を示す。ただし、他の実施形態においては、次回提供タイミングは、前回に提供情報が提供された時点からの時間を示してもよい。また、商品を実際に使用した時点やサービスを実際に受けた時点がポータルサーバ４１に取得される場合には、これらの時点からの時間を示してもよい。

【0218】

本変形例においては、上記実施形態において示した提供条件テーブル（図９）に代えて、図２０に示す提供条件テーブルが用いられる。本変形例においても上記実施形態と同様、提供情報に関する判定処理（ステップＳ１４およびＳ１８）が実行される。この判定処理によって、提供情報を提供するか否か、および、提供する場合にはどの提供情報を提供するかが判定される。また、本変形例においても上記実施形態と同様、提供条件に含まれる各条件が満たされる場合、当該提供条件に関連付けられる提供内容の提供情報が提供される。例えば、図２０に示される提供条件テーブルによれば、ユーザの年齢が４０代であり、最近１週間の総睡眠時間の平均が６時間未満であり、最近１週間の睡眠効率の平均が８０％未満であり、かつ、最近１週間の中途覚醒回数の平均が３回以上である場合、商品Ａを紹介する提供情報が提供すべき情報として決定される。

【0219】

なお、提供条件が複数の条件を含む場合、他の実施形態においては、ポータルサーバ４１は、複数の条件のうちの所定数の条件が満たされた場合に提供条件が満たされたと判断するようにしてもよい。例えば、図２０の例においては、３つの健康条件のうち２つが満たされた（かつ、ユーザ条件が満たされた）場合に、提供条件が満たされたと判断するようにしてもよい。また、他の実施形態においては、ポータルサーバ４１は、提供条件に含まれる各条件についてそれぞれ重み（ポイント）を付しておき、当該各条件のうちで満たされた条件のポイントが所定値以上となった場合に提供条件が満たされたと判断するようにしてもよい。

【0220】

なお、提供条件が満たされた（換言すれば、提供条件に含まれる各条件が満たされた）か否かを判定する方法は任意である。すなわち、ポータルサーバ４１は、上記実施形態と同様に、まずユーザ条件を判定し、それから、条件が満たされるユーザ条件に関連付けられる健康条件を判定してもよい。また、ポータルサーバ４１は、ユーザ条件と健康条件とをそれぞれ個別に（並列的に）判定してもよい。

【0221】

本変形例においても上記実施形態と同様、満たされた提供条件が存在する場合には、それに関連付けられる内容の提供情報が端末システム１へ送信される（ステップＳ１９）。

【0222】

本変形例においては、提供情報で紹介される商品・サービスが購入された場合（ステップＳ２０）、ポータルサーバ４１は、当該提供情報に関連付けられる次回提供タイミングに基づいて、その後に提供情報を提供するタイミングを特定する。このタイミングを特定する方法は、上記実施形態において追加提供タイミングを特定する処理（ステップＳ２３）と同様の方法で行われてもよい。特定されたタイミングは、次回提供タイミング情報として記憶される。すなわち、本変形例においては、ポータルサーバ４１は、ユーザ提供履歴情報（図１２）における「追加提供タイミング情報」に代えて、次回提供タイミング情報を記憶する。

【0223】

本変形例において、ポータルサーバ４１は、各ユーザのユーザ提供履歴情報を定期的に参照することによって、次回提供タイミングが到来したか否かを定期的に判定する。そして、次回提供タイミングが到来したと判定された場合、ポータルサーバ４１は、提供条件テーブルを用いて、提供情報を提供するか否か、および、どの提供情報を提供するかを判定する。すなわち、ポータルサーバ４１は、次回提供タイミングが到来したと判定された場合、提供情報に関する判定処理（Ｓ１４およびＳ１８）を実行する。つまり、本変形例においては、ユーザがログインした場合以外に、次回提供タイミングが到来した場合にも、提供情報に関する判定処理が実行される。また、次回提供タイミングが到来した場合に用いられる提供条件テーブルは、ユーザがログインした場合に用いられる提供条件テーブルと同じであり、本変形例では追加提供条件テーブルは用いられない。

【0224】

次回提供タイミングの到来に応じて提供情報に関する判定処理が実行された結果、提供されるべき提供情報が生成（決定）された場合、ポータルサーバ４１は、提供情報がある旨のメッセージをプッシュ通知で端末システム１へ送信する。プッシュ通知の方法は、上記実施形態におけるステップＳ２９における方法と同様である。なお、他の実施形態においては、提供情報自体がプッシュ通知で端末システム１へ送信されてもよい。このように、本変形例においては、次回提供タイミングの到来に応じて提供情報が提供される場合には、提供情報の通知（または提供情報自体）がプッシュ通知で端末システム１へ送信される。これによって、提供情報が生成されたことを適切なタイミングでユーザに通知することができる。

【0225】

本変形例のように、情報処理システムは、追加提供条件テーブルを用いないものであってもよい。なお、追加提供タイミングを設定しない場合であっても、次回提供タイミングを設定することによって、サービスサーバ３は、商品・サービスの購入後における所望のタイミングで提供情報をユーザに提供することができる。

【0226】

本変形例においても上記実施形態と同様、ユーザの健康情報（の分析結果）に基づいて提供条件が更新される。本変形例でも上記実施形態と同様、更新のために条件更新テーブル（図１８）が用いられる。ここで、本変形例では、提供条件に複数の条件（健康条件）が含まれるので、条件更新テーブルに含まれる変更条件は、これら複数の条件に関する条件であってもよい。例えば図２０に示す提供条件テーブルが用いられる場合において、変更条件は以下であってもよい。
（ａ）商品の購入後に総睡眠時間または睡眠効率が改善したユーザのうち、商品の購入前に睡眠効率７０％から８０％であったユーザの割合が３０％以下であり、かつ、商品の購入前に睡眠効率が７０％以下であったユーザの割合が６０％以上であること
（ｂ）商品の購入後に総睡眠時間または睡眠効率が悪化したユーザのうち、商品の購入前に中途覚醒回数の条件を満たしていたユーザの割合が８０％以上であったこと
（ｃ）「商品の購入後に総睡眠時間または睡眠効率が改善したユーザのうち、商品の購入前に中途覚醒時間が１時間以上であったユーザの割合が８０％以上であること

【0227】

また、上記（ｃ）のように、変更条件は、提供条件テーブルに含まれる健康情報とは異なる健康情報（上記（ｃ）の例では、中途覚醒時間の情報）に関する条件を含んでいてもよい。

【0228】

また、提供条件に複数の条件（健康条件）が含まれる場合において、条件更新テーブルにおける更新内容は、当該複数の条件のうちいくつか（または全部）を更新するものであってもよい。例えば、図２０に示す提供条件テーブルが用いられる場合において、変更内容は、「睡眠効率の閾値を５減少させる」であってもよい。例えば、上記（ａ）の変更条件に対して、この変更内容が関連付けられていてもよい。

【0229】

また、変更内容は、提供条件テーブルに新たな条件を追加するものであってもよい。例えば、図２０に示す提供条件テーブルが用いられる場合において、変更内容は、「「中途覚醒時間が１時間以上であること」という健康条件を追加する」のように、新たな健康情報に関する条件を追加するものであってもよい。例えば、上記（ｃ）の変更条件に対して、この変更内容が関連付けられていてもよい。

【0230】

また、提供条件テーブルの各条件に重みが付される場合には、変更内容は、当該重みを変更するものであってもよい。例えば、変更内容は、「中途覚醒回数に関する条件の重み付けを軽くする」であってもよい。例えば、上記（ｂ）の変更条件に対して、この変更内容が関連付けられていてもよい。また、上述のように、提供情報に優先順位が付される場合には、変更内容は、この優先順位を変更するものであってもよい。

【0231】

また、更新条件に含まれるデータ数条件は、データ数が増加した場合に繰り返し満たされるような条件であってもよい。データ数条件は、例えば「効果情報が１００人分増加したこと」のように、所定数（１００人分）の効果情報が取得される度に満たされる条件であってもよい。この場合、サービスサーバ３は、増加した所定数（１００人）分のデータに基づいて変更条件の判定を行ってもよい。

【0232】

上記のように、サービスサーバ３は、分析結果の数に関する条件（データ数条件）が満たされることに応じて、当該条件を更新するか否かの判定を繰り返し実行してもよい。これによれば、更新を繰り返し実行することによって、提供条件（または追加提供条件）の内容を繰り返し改善することができる。その結果、提供条件をより精度の良いものとすることができる。

【0233】

上記のように、本変形例においては、提供条件を更新する処理として、以下のうち少なくとも１つを行う。
（ａ）提供条件に対して設定される優先順位の変更
（ｂ）健康条件内で規定されるパラメータ（例えば、健康条件において規定されている閾値）の変更
（ｃ）健康条件に対して設定されるパラメータの変更（例えば、健康条件に付される重み）
（ｄ）提供条件に含まれる健康条件の追加および／または削除
上記（ａ）～（ｄ）によって提供条件を更新することによって、提供条件をより精度の良いものとすることができる。

【0234】

（変化情報に関する変形例）
また、サービスサーバ３（ポータルサーバ４１）は、購入された商品・サービスについて、購入の前後の健康情報を示す変化情報を記憶しておいてもよい。このとき、変化情報は、上述の効果情報の一部として用いられてもよいし、または、効果情報を算出するために用いられてもよい。以下、上記実施形態における変形例として、変化情報が用いられる場合の一例について説明する。

【0235】

図２１は、変化情報の一例を示す図である。図２１において、変化情報は、購入情報と、ユーザ情報と、購入前健康情報と、購入後健康情報とを関連付けた組を示す情報である。購入情報は、ユーザに購入された商品・サービスを示す情報である。購入情報は、商品・サービスが購入される毎に追加して記憶される。したがって、図２１に示すように、変化情報は、単一の商品について上記の組を複数種類含むことがある。また、ユーザ情報は、商品・サービスを購入したユーザに関する情報である。本変形例では、ユーザの年齢および性別を示す情報がユーザ情報として記憶される。

【0236】

購入前健康情報は、商品を購入する前における（商品を購入した）ユーザの健康情報である。本変形例では、総睡眠時間、睡眠効率、および入眠潜時等の健康情報について、購入前１週間の平均値を示す情報が購入前健康情報として記憶される。なお、購入前健康情報として記憶される健康情報は、上記に限らず任意である。例えば、データサーバ２に記憶される各種類の健康情報について、購入前健康情報（および購入後健康情報）が記憶されてもよい。

【0237】

購入後健康情報は、商品を購入した後におけるユーザの健康情報である。購入後健康情報は、それに関連付けられる購入前健康情報が示す健康情報と同種の健康情報である。すなわち、図２１に示す例においては、総睡眠時間、睡眠効率、および入眠潜時等の健康情報に関する情報が購入後健康情報として記憶される。また、本実施形態においては、これらの健康情報について、購入後１週間の平均値を示す情報が購入後健康情報として記憶される。

【0238】

なお、購入前健康情報および購入後健康情報の内容は、購入情報が示す商品毎に異なる種類の健康情報に関する情報であってもよい。例えば、商品Ａおよび商品Ｂについては、総睡眠時間、睡眠効率、および入眠潜時の３種類の健康情報に関する情報（平均値）が購入前健康情報および購入後健康情報として記憶されるのに対して、商品Ｃについては、総睡眠時間および疲労度に関する情報が購入前健康情報および購入後健康情報として記憶されてもよい。

【0239】

なお、購入前健康情報および購入後健康情報の内容は、購入情報が示す商品毎に異なる内容であってもよい。例えば、商品Ａおよび商品Ｂについては、購入前１週間の平均値および購入後１週間の平均値が購入前健康情報および購入後健康情報として記憶されるのに対して、商品Ｃについては、購入前１月の平均値および購入後１月の平均値が購入前健康情報および購入後健康情報として記憶されてもよい。

【0240】

また、他の実施形態においては、変化情報は、ユーザの健康状態の変化を示すものであればどのような形式であってもよい。例えば、変化情報は、購入前健康情報および購入後健康情報に代えて、購入前後における健康情報の変化を示す情報を含んでいてもよい。変化情報は、例えば「総睡眠時間が０．５時間増加」や、「睡眠効率が改善」等を示す情報を含んでいてもよい。

【0241】

また、変化情報は、提供情報（商品・サービス等）毎に変化情報が記憶されてもよいし、ユーザ情報（年齢・性別等）毎に変化情報が記憶されてもよい。

【0242】

ポータルサーバ４１は、商品が購入された場合（Ｓ２０）、変化情報のうちの購入情報、ユーザ情報、および購入前健康情報を記憶する。なお、購入前健康情報の算出は、算出に用いられる情報をデータサーバ２から取得することによって行われる。なお、ポータルサーバ４１は、提供情報によって紹介された商品・サービスが購入された場合に限らず、提供情報によって紹介されていない商品・サービスがポータルサイトにおいて購入された場合にも変化情報を算出してもよい。これによって、サービスサーバ３は、商品・サービスの効果を判断するためのデータをより多く収集することができ、効果を精度良く判断することができる。

【0243】

また、商品購入から所定期間が経過すると、ポータルサーバ４１は、購入後健康情報を取得して記憶する。この所定期間は、予め定められた期間（図２１の例では１週間）である。上述のように、所定期間は、商品毎に異なる期間であってもよい。また、所定期間は、商品に対応する追加提供タイミングあるいは次回提供タイミングに対応する期間に設定されていてもよい。これによれば、ポータルサーバ４１は、変化情報を算出する処理と、追加提供情報（または提供情報）に関する判定処理とを同じタイミングで行うことができ、処理の効率化を図ることができる。例えば、上記２つの処理において、データサーバ２から情報を取得する処理や、取得した情報から統計値を算出する処理を共通化することができるので、処理の効率化を図ることができる。

【0244】

ポータルサーバ４１は、購入前健康情報の算出と同様、算出に用いられる情報をデータサーバ２から取得し、取得した情報を用いて購入後健康情報を算出する。また、購入前後における健康情報の変化を示す情報を算出する場合には、ポータルサーバ４１は、購入前健康情報および購入後健康情報に基づいて当該変化を示す情報を算出する。

【0245】

以上のようにして算出された変化情報は、例えば上述の効果情報（の一部）として用いられてもよいし、効果情報を算出するために用いられてもよい。また、他のユーザに関する健康情報の分析結果を用いて提供情報の生成が行われる場合（詳細は後述する）には、変化情報は、当該分析結果（の一部）として用いられてもよいし、当該分析結果を算出するために用いられてもよい。

【0246】

上記のように、サーバシステムは、ユーザに対して提供された提供情報と、当該提供情報がユーザに提供されたことに起因する所定の基準時点の前後における、ユーザの健康情報の変化とを関連付けた変化情報を記憶する。そして、サーバシステムは、変化情報に基づいて（変化情報を上記分析結果として用いて、または、変化情報を用いて得られる上記分析結果に基づいて）提供条件（または追加提供条件）を更新する。このように、変化情報を記憶しておくことによって、健康情報に関する分析結果を容易に算出し、更新を容易に行うことができる。

【0247】

（提供情報の生成に関する変形例）
他の実施形態においては、サーバシステムは、提供情報を提供する対象となるユーザとは異なる他の１以上のユーザに関する分析結果に基づいて提供情報を生成するようにしてもよい。例えば、サーバシステムは、他のユーザとして例えば以下のユーザを選出してもよい。
・提供情報を提供する対象となるユーザと同じ商品を購入している他のユーザ
・提供情報を提供する対象となるユーザとユーザ情報（年齢、世代および／または性別等）が共通する他のユーザ
・提供情報を提供する対象となるユーザと健康情報が近い他のユーザ
上記のように、サーバシステムは、提供情報を提供する対象となるユーザに関する情報に基づいて他のユーザを選出し、選出したユーザの健康情報に関する分析結果に基づいて提供情報の内容を決定してもよい。これによって、有益な提供情報をユーザに提供しやすくなる。

【0248】

（提供情報の内容に関する変形例）
上記実施形態においては、提供情報は、商品・サービスを紹介する情報（リコメンド情報）であった。ここで、上記実施形態および変形例において、提供情報は、ユーザの健康および／または身体に関する指標を改善するための任意の情報であってもよい。例えば、提供情報は、当該指標を改善するアドバイスを示すアドバイス情報であってもよい。アドバイス情報としては、例えば、（ａ）睡眠時の眠りが浅いことを表す健康情報が算出されたユーザに対して、運動することを勧めるアドバイス、（ｂ）疲労が溜まっていることを表す健康情報が算出されたユーザに対して、食事の栄養バランスを見直すことを勧めるアドバイス、および、（ｃ）睡眠時間または就寝時刻が不規則であることを表す健康情報が算出されたユーザに対して、生活習慣を改善することを勧めるアドバイス等が考えられる。なお、上記実施形態のように、提供情報（アドバイス情報等）が繰り返し提供される場合には、ある提供情報を提供した後のユーザの健康情報に基づいて、さらに提供情報が提供される。これによれば、アドバイス情報等の提供情報が繰り返し（継続的に）ユーザに提供されるので、健康の改善をユーザに対して効果的に促すことができる。

【0249】

また、提供情報がアドバイス情報である場合、サービスサーバ３は、アドバイス情報をユーザに提供した前後における健康情報を比較し、比較の結果に基づいて追加のアドバイス情報を、上述の追加提供情報として提供してもよい。すなわち、サービスサーバ３は、比較の結果、ユーザの健康が改善していると判定する場合と、改善していないと判定する場合とで、異なるアドバイス情報を提供してもよい。

【0250】

また、サービスサーバ３は、アドバイス情報の提供条件を更新するようにしてもよい。すなわち、サービスサーバ３は、サービスサーバ３は、アドバイス情報をユーザに提供した前後における健康情報を比較し、比較の結果、アドバイス情報の提供前後においてユーザの健康が改善したと判断した場合には、当該アドバイス情報が提供されやすくなるように、当該アドバイス情報の提供条件を更新してもよい。なお、提供情報がアドバイス情報である場合も、上記“（提供条件を自動的に更新する変形例）”に記載の変形例のように、例えば条件更新テーブルを用いることによって、更新条件を自動的に更新することができる。例えば、サービスサーバ３は、条件更新テーブルにおける更新条件として、アドバイス情報の提供前後におけるユーザの健康情報の変化に関する条件を設定してもよい。

【0251】

また、提供情報は、当該指標を改善するための商品・サービス自体のデータ（例えば、上述した、ユーザの入眠あるいは起床を誘導する音楽のデータ）であってもよい。つまり、提供情報は、ユーザに情報を紹介するもの（商品・サービスを紹介する情報、あるいは、アドバイス情報）であってもよいし、ユーザに提供すべきアドバイス自体、商品・サービスのデータ自体であってもよい。また、提供情報は、商品・サービスに関する情報（商品・サービスを紹介する情報、あるいは、商品・サービス（自体）のデータを含む情報）であってもよいし、（商品・サービスとは無関係の）アドバイス情報であってもよい。

【0252】

なお、上記実施形態および変形例では、提供情報は商品・サービスを紹介するものであったので、情報処理システムは、商品・サービスの購入時点（あるいは利用時点）を基準時点として用いて各種の処理を行った。例えば、上記実施形態では、上述の利用情報（図９）によって購入時点を基準時点とした期間が指定されたり、追加提供タイミング（図１４）あるいは次回提供タイミングの基準時点として購入時点が用いられたりした。また、上記変形例では、変化情報（図２１）の基準時点（変化情報は、基準時点の前後における健康情報の変化を示す）として購入時点が用いられた。これに対して、アドバイス情報あるいは上記商品・サービスのデータのように、提供情報自体を利用する場合には、提供情報の提供時点を基準として用いてもよい。

【0253】

（健康情報の内容に関する変形例）
上記実施形態においては、健康情報は、ユーザの睡眠および／または疲労に関する指標を示す情報であった。したがって、本実施形態によれば、ユーザの睡眠および／または疲労に応じた提供情報を提供することができる。なお、他の実施形態においては、健康情報は、睡眠および／または疲労に関する指標に加えて（または代えて）、肥満に関する指標（例えば、体重や体脂肪率や基礎代謝量等）、あるいは、肌状態に関する指標（例えば、肌の水分量や、シミの状態を示す指標等）を示す情報であってもよい。

【0254】

（サービスサーバの構成に関する変形例）
上記実施形態においては、サービスサーバ３はポータルサーバ４１とサービス提供サーバ４２とを含み、商品・サービスの購入を行うショッピングサイトはポータルサーバ４１によって管理されるものとした。ここで、サービスサーバ３の構成は任意であり、ポータルサーバ４１およびサービス提供サーバ４２の機能（役割）は上記実施形態に限らない。例えば、他の実施形態においては、１以上のサービス提供サーバがそれぞれショッピングサイトを管理し、ポータルサーバが管理するポータルサイトでは、提供情報を提供および健康情報の閲覧が可能であるようにしてもよい。このとき、ポータルサイトのページに含まれる提供情報には、ショッピングサイトへアクセスするためのリンク情報が含まれていてもよい。また、ショッピングサイトにおいて商品・サービスの購入が行われた場合には、ポータルサーバ４１において購入（購入履歴）を管理するべく、サービス提供サーバ４２からポータルサーバ４１へ購入の通知が送信されてもよい。また、他の実施形態においては、ポータルサーバ４１の機能とサービス提供サーバ４２の機能とが１つのサーバによって提供されてもよい。

【0255】

（商品・サービスに関する変形例）
また、他の実施形態においては、サービスサーバ３において提供される商品・サービスは、端末システム１に対して提供されるアプリケーションであってもよい。このとき、アプリケーションは、データサーバ２に記憶される情報（健康情報等）を利用するものであってもよい。上記アプリケーションは、例えば、端末システム１において取得される生体情報を用いてユーザの生存確認を行って他のユーザに通知を行う見守りサービスを行うためのアプリケーションであってもよい。

【0256】

また、他の実施形態においては、サーバにおいて、ゲームが提供されてもよい。ゲームを提供するサーバは、サービスサーバ３と同じサーバであってもよいし、専用のサーバ（ゲームサーバ）であってもよい。例えば、ポータルサーバ４１が管理するポータルサイト内においてゲームアプリケーションがユーザに提供されてもよい。なお、ゲームアプリケーションは、ポータルサイトを閲覧するためのブラウザ上で動作する種類のものであってもよいし、サーバから端末システム１にダウンロードされてインストールされる種類のものであってもよい。

【0257】

なお、ゲームアプリケーションは、サーバから端末システム１に提供される他、任意の方法で端末システム１に取得されてもよい。例えば、ゲームアプリケーションを記憶した記憶媒体が主端末装置１０に接続（または装着）されることによって、主端末装置１０においてゲームアプリケーションが実行されてもよい。

【0258】

また、ゲームアプリケーションは、主端末装置１０において実行されてもよいし、ユーザが有する他のユーザ端末（携帯端末、パーソナルコンピュータ、および、ゲーム装置等）において実行されてもよい。

【0259】

上記のようにユーザ端末（主端末装置１０、および／または、上記他のユーザ端末）においてゲームアプリケーションが実行される場合、ユーザの健康情報に対する評価結果がゲームに反映されてもよい。具体的には、サービスサーバ３は、データサーバ２に記憶されるユーザの健康情報に対する評価を行う。すなわち、サービスサーバ３は、健康情報が所定の条件を満たすか否かを判定する。この所定の条件とは、例えば、健康情報が示す疲労度が基準値以上の良い値である状態が所定期間継続したこと、あるいは、疲労度が所定の基準以上改善したこと等である。上記条件が満たされた場合、サービスサーバ３は、ゲーム上の特典をユーザに付与する。例えば、サービスサーバ３は、ゲーム内で利用するアイテム等のコンテンツをユーザに付与したり、ゲーム内のストーリーを進行させたりするようにしてもよい。このような特典を付与することによって、健康情報を算出することを継続する動機をユーザに与えることができる。

【0260】

上記において、端末システムとサーバシステムとを含む情報処理システムは、ゲームアプリケーションに基づくゲーム処理を実行する。ここで、情報処理システムは、ゲーム処理を実行する際に、サーバシステムに記憶されている健康情報を参照する。そして、参照した健康情報に基づいて（参照結果に応じて）当該ゲーム処理中の所定の処理が実行される。所定の処理は、例えば、上記のアイテムを付与する処理や、ゲーム内のストーリーを進める処理である。具体的には、情報処理システムは、ゲームアプリケーションで利用されるゲームデータを追加または更新する処理を行う。つまり、付与されるアイテムのゲームデータが追加されたり、新たなストーリーをプレイできるようにゲーム内のフラグが更新されたりする。

【0261】

なお、ゲーム処理は、サーバ側の情報処理装置（例えば、ゲームサーバ、または、サービスサーバ）で実行されてもよいし、端末側の情報処理装置（例えば、主端末装置１０、または、上記他のユーザ端末）で実行されてもよい。また、ゲーム処理は、サーバ側の情報処理装置と端末側の情報処理装置とが協働して実行されてもよい。つまり、ゲーム処理の一部の処理がサーバ側で実行され、他の一部の処理が端末側で実行されてもよい。例えば、ポータルサイトを閲覧するためのブラウザ上でゲームアプリケーションが動作する場合には、ゲーム処理はサーバ側で実行されたり、サーバ側と端末側とで協働して実行されたりする。また、ゲームアプリケーションが端末側の情報処理装置にインストールされる場合、あるいは、当該情報処理装置に接続される記憶媒体に記憶されるゲームアプリケーションが実行される場合には、ゲーム処理は、端末側で実行されたり、サーバ側と端末側とで協働して実行されたりする。

【0262】

また、ゲームデータの追加または更新は、サーバ側で実行されてもよいし、端末側で実行されてもよい。すなわち、ゲームデータを追加または更新する処理は、サーバ側の情報処理装置が、サーバ側または端末側の記憶部に記憶されるゲームデータに対して追加または更新を行うことによって実行されてもよい。また、ゲームデータを追加または更新する処理は、端末側の情報処理装置が、端末側の記憶部に記憶されるゲームデータに対して追加または更新を行うことによって実行されてもよい。

【0263】

なお、上記のようにゲームアプリケーションにおいて健康情報を利用（参照）する際には、ゲームアプリケーションのユーザに関する健康情報が参照される。例えば、上記ポータルサイトにユーザがログインした状態でゲームアプリケーションが利用される場合には、サーバは、ログイン時に入力されるユーザ識別情報によってユーザを特定することができる。すなわち、サーバは、ログイン時に入力されたユーザ識別情報を記憶しておき、ゲーム処理において健康情報を参照する際、記憶しておいたユーザ識別情報によって特定されるユーザの健康情報を参照する。

【0264】

また、上記ポータルサイトにユーザがログインしていない状態でゲームアプリケーションが利用される場合（あるいは、ログインしている端末とは異なる端末を用いてゲームアプリケーションが利用される場合）には、ゲーム処理の前またはゲーム処理中において、サーバは、ゲームアプリケーションを利用しているユーザを識別する。具体的には、ゲームアプリケーションを利用しているユーザ端末は、ゲーム処理の前またはゲーム処理中において、ユーザ識別情報の入力をユーザから受け付け、入力されたユーザ識別情報をサーバへ送信する。サーバは、ユーザ端末からのユーザ識別情報を用いて、参照すべき健康情報を特定する。ゲームデータの追加または更新がサーバ側で実行される場合には、サーバは、特定された健康情報を参照して、参照した健康情報に基づいてゲーム処理中の所定の処理（ゲームデータの追加または変更）を実行する。一方、ゲームデータの追加または更新が端末側で実行される場合には、サーバは、特定された健康情報をユーザ端末へ送信する。ユーザ端末は、受信した健康情報を参照して（つまり、サーバ側で記憶される健康情報を参照して）、参照した健康情報に基づいてゲーム処理中の所定の処理を実行する。

【0265】

上記においては、ユーザ識別情報は、ポータルサイトにおけるユーザのアカウントであるだけでなく、ゲームアプリケーションを提供するサービスにおけるアカウントを兼ねてもよい。この場合、複数のネットワークサービス（上記提供情報を提供するサービス、および、ゲームアプリケーションを提供するサービスを含む）におけるユーザのアカウントを共通にすることによって、ユーザは、異なるユーザ端末（プラットホームが異なる端末でもよい）において、複数のネットワークサービスを共通に利用することができるので、利便性が向上する。

【0266】

＜第２の実施形態＞
次に、第２の実施形態に係る情報処理システム、情報処理装置、情報処理プログラム、および情報処理方法について説明する。上記第１の実施形態における“（提供条件を自動的に更新する変形例）”では、ユーザ全体について提供条件を更新する例について説明した。第２の実施形態においては、ユーザ毎に提供条件を更新する例を説明する。第２の実施形態においては、ユーザ毎に提供条件がカスタマイズされるので、ユーザに適した情報を提供することができる。以下、第２の実施形態の詳細について説明する。

【0267】

［１．情報処理システムの構成］
第２の実施形態においては、情報処理システムは、第１の実施形態における端末システム１に代えて、後述する端末システム１００を含む構成とする。ただし、第２の実施形態においても第１の実施形態と同様、端末システムの構成は任意である。例えば、情報処理システムは、第１の実施形態における端末システム１と、第２の実施形態における端末システム１００との両方を含む構成であってもよい。つまり、情報処理システムは、異なる種類の端末システムを含むものであってもよい。

【0268】

次に、端末システム１００の構成の一例について説明する。図２２は、端末システム１００の詳細な構成の一例を示す図である。図２３は、端末システム１００の外観の一例を示す図である。図２２～図２３に示すように、端末システム１００は、携帯端末１０５と、ベース装置１０６とを備える。携帯端末１０５はユーザによって携帯される。ベース装置１０６は、例えばユーザの自宅に設置される。

【0269】

本実施形態において、携帯端末１０５は、携帯型の情報処理装置であり、ベース装置１０６は、携帯端末１０５を接続可能なクレードルである。図２３に示すように、携帯端末１０５は、ベース装置１０６に対して着脱可能に接続することが可能である。また、ベース装置１０６は携帯端末１０５に対して充電を行う機能を有しており、携帯端末１０５とベース装置１０６とが接続された場合、ベース装置１０６による携帯端末１０５に対する充電が可能となる。なお、他の実施形態においては、携帯端末１０５とベース装置１０６とは、ケーブルを介して着脱可能に接続される形態であってもよい。

【0270】

また、携帯端末１０５とベース装置１０６との通信方法は任意であり、ケーブルを介した有線通信によって行われてもよいし、電波通信や赤外線通信等の無線通信によって行われてもよい。また、携帯端末１０５とベース装置１０６との通信は、両者の間で直接行われる通信方法によって行われてもよいし、ＬＡＮやインターネット等のネットワークを介する通信方法によって行われてもよい。

【0271】

まず、本実施形態における携帯端末１０５の構成について説明する。携帯端末１０５は、携帯型の情報処理装置であり、本実施形態においては、例えば、携帯電話、スマートフォン、またはタブレット端末等といった多機能デバイスである。すなわち、携帯端末１０５は、一般的な多機能デバイスが有する各種の機能（例えば、入力機能、出力（表示）機能、情報処理機能、ネットワーク通信機能、通話機能、カメラ機能等）のうちのいくつかを有している。なお、ネットワーク通信機能は、インターネットを介した通信機能、および／または、モバイル通信網を介した通信機能である。携帯端末１０５は、既製の多機能デバイスに所定の機能をインストールすることで実現されてもよい。本実施形態において、携帯端末１０５は、上記多機能デバイスとして用いられることに加えて、上記健康情報を算出したり、上記ゲーム処理を実行したりするために用いられる。また、携帯端末１０５は、例えば腕時計型あるいはメガネ型の端末のように、ユーザに装着可能な情報処理装置（いわゆるウェアラブル端末）であってもよい。

【0272】

図２２に示すように、携帯端末１０５は通信部１１０を備える。通信部１１０は、ネットワーク４に接続して、サーバ（すなわち、データサーバ２および／またはサービスサーバ３）との通信を行う。本実施形態において、通信部１１０は、モバイル通信網（換言すれば、携帯電話通信網）に接続して通信を行う機能を有する通信モジュールである。例えば、通信部１１０は、３Ｇの通信規格、あるいは、４Ｇ（ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）を含む）の通信規格に準拠した通信方式で通信を行う。なお、携帯端末１０５がサーバと通信するための方法は任意であり、例えば、Ｗｉ－Ｆｉの認証を受けた通信モジュールによって無線ＬＡＮを介して通信を行う方法であってもよい。また、携帯端末１０５は、モバイル通信網を介してサーバと通信する機能と、無線ＬＡＮを介してサーバと通信を行う機能との両方を備えていてもよい。

【0273】

携帯端末１０５は処理部１１１を備える。処理部１１１は、携帯端末１０５において実行される各種の情報処理を実行する。処理部１１１は、携帯端末１０５の各部１１０，１１２～１１９に接続される。処理部１１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）およびメモリを有する。携帯端末１０５においては、ＣＰＵがメモリを用いて、携帯端末１０５に記憶された情報処理プログラムを実行することによって上記各種の情報処理が実行される。本実施形態においては、処理部１１１は、上記情報処理として、上述した健康情報を算出する処理、ゲーム処理、および、サーバから受信した情報（例えば上記サービス情報）をユーザに提供する処理等を実行する。また、携帯端末１０５が多機能デバイスとして動作する場合、処理部１１１は、各機能を実現するための情報処理を実行する。

【0274】

携帯端末１０５は、入出力インターフェースを備え、ユーザが情報を入力したり閲覧したりするための情報処理装置（換言すれば、入出力端末）として機能する。具体的には、携帯端末１０５は、操作入力部１１２、ディスプレイ１１７、および、スピーカ１１８を備える。操作入力部１１２は、ユーザによる操作入力を受け付ける任意の入力装置である。本実施形態においては、操作入力部１１２は、ディスプレイ１１７上に設けられるタッチパネルと、ボタンとを含む。他の実施形態において、携帯端末１０５は、操作入力部１１２として、携帯端末１０５を動かす操作を検出するためのセンサ（加速度センサやジャイロセンサ）を備えていてもよい。

【0275】

出力装置の一例であるディスプレイ１１７は、操作入力部１１２に対する入力に応じて携帯端末１０５において生成される各種の画像を表示したり、サーバから受信されたデータに基づく各種の画像（例えば、ネットワークサービスに関する画像）を表示したりする。出力装置の一例であるスピーカ１１８は、操作入力部１１２に対する入力に応じて携帯端末１０５において生成される各種の音を出力したり、サーバから受信されたデータに基づく各種の音（例えば、ネットワークサービスに関する音声や音楽）を出力したりする。

【0276】

携帯端末１０５は、上記健康情報を算出するための情報を検出するセンサを備える。本実施形態においては、携帯端末１０５は、位置検出部１１３、および、環境センサ１１４を備える。

【0277】

位置検出部１１３は、携帯端末１０５の位置を検出する。本実施形態においては、位置検出部１１３は、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）を用いて位置を検出する。位置検出部１１３は、例えばＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）センサ（例えば、ＧＰＳモジュール）である。なお、位置検出部１１３における位置検出方法は任意であり、位置検出部１１３は、例えばビーコンを用いて位置を検出してもよい。また例えば、位置検出部１１３は、気圧センサの検出結果に基づいて高度の変化を算出することで、ユーザの高度を示す情報（例えばビルの何階にいるかを示す情報）を算出してもよい。

【0278】

環境センサ１１４は、携帯端末１０５の周囲の環境を検出する。本実施形態においては、環境センサ１１４は、温度センサおよび湿度センサを含む。なお、他の実施形態においては、環境センサ１１４として、気圧センサ、照度センサ、騒音センサ、においセンサ等が含まれていてもよい。すなわち、環境センサ１１４は、温度、湿度、照度、気圧、音、およびにおいのうち少なくとも１つを検知するものであってもよい。また、他の実施形態においては、マイク１１５が周囲の騒音を検出するための環境センサとして用いられてもよい。

【0279】

また、携帯端末１０５は、マイク１１５を備える。マイク１１５は、携帯端末１０５の周囲の音を検出する。マイク１１５は、健康情報を算出するために用いられてもよい。例えば、携帯端末１０５は、マイク１１５によってユーザのいびきの音を検出し、検出結果に基づいて睡眠に関する情報を算出してもよい。なお、マイク１１５は、携帯端末１０５に対する音声入力を受け付けるために用いられてもよい。

【0280】

携帯端末１０５は、カメラ１１６を備える。カメラ１１６は、例えば、携帯端末１０５においてディスプレイ１１７が設けられる面と同じ側（すなわち、内側）に設けられる（図２３参照）。つまり、カメラ１１６は、携帯端末１０５を操作するユーザを撮像することが可能な位置に設けられる。なお、携帯端末１０５は、カメラ１１６による撮像画像に基づいてユーザの表情を判別し、ユーザの表情に基づいて疲労度を算出するようにしてもよい。

【0281】

携帯端末１０５は、ベース装置１０６と電気的に接続するためのコネクタ１１９を備える。本実施形態においては、携帯端末１０５がベース装置１０６に装着された場合（図２３参照）に、コネクタ１１９がベース装置１０６のコネクタ１２１と接触する。これによって、携帯端末１０５とベース装置１０６との通信が可能となる。

【0282】

なお、携帯端末１０５は、図示しない電池を備えており、携帯端末１０５の各部は、電池から供給される電力によって動作する。詳細は後述するが、本実施形態においては、ベース装置１０６によって携帯端末１０５の電池を充電することが可能である。

【0283】

次に、本実施形態におけるベース装置１０６の構成について説明する。本実施形態においては、ベース装置１０６は、例えばユーザの寝室に配置され、ユーザの就寝中においてユーザの睡眠に関する生体情報を検出するために用いられる。ここで、生体情報は、ユーザの身体から検出される情報である。本実施形態においては、呼吸、脈拍、および体動が生体情報として検出される。なお、他の実施形態においては、生体情報として検出される情報は任意であり、呼吸、脈拍、および体動のうちのいずれか１つまたは２つが検出されてもよいし、これら３つの情報とは異なる他の情報が検出されてもよい。また、ベース装置１０６は、就寝中におけるユーザに対してコンテンツ（例えば、ユーザに入眠を促すコンテンツ）や情報（例えば、睡眠に関する評価結果の情報）を提供するために用いられる。

【0284】

ベース装置１０６は、携帯端末１０５を着脱可能に支持する支持部を備える。具体的には、図２３に示すように、ベース装置１０６の筐体（具体的には、支持部）には、携帯端末１０５の一部の形状に応じた凹部が設けられる。この凹部に携帯端末１０５が挿入されることによって、携帯端末１０５がベース装置１０６に装着される。なお、ベース装置１０６が携帯端末１０５を支持するための機構は任意である。

【0285】

図２２に示すように、ベース装置１０６はコネクタ１２１を備える。上記凹部に携帯端末１０５が挿入された場合、携帯端末１０５のコネクタ１１９とベース装置１０６のコネクタ１２１とが接続される。その結果、携帯端末１０５とベース装置１０６との通信が可能となり、ベース装置１０６による携帯端末１０５に対する充電が可能となる。

【0286】

ベース装置１０６は、生体情報を検出するセンサの一例であるドップラーセンサ１２４を備える。ドップラーセンサ１２４は、マイクロ波を発射するとともに、発射したマイクロ波の反射波を受信することによって、発射したマイクロ波の周波数と受信したマイクロ波の周波数との差に基づいて動体を検出する。本実施形態においては、ドップラーセンサ１２４（より具体的には、出射部１２４ａ）は、ベース装置１０６の前方に向かって電波を照射する（図２３参照）。本実施形態においては、ドップラーセンサ１２４の検出対象はユーザであり、ドップラーセンサ１２４によってユーザの体動を検出する。詳細は後述するが、検出される生体情報（換言すれば、ドップラーセンサ１２４の出力波形）に対して周波数分析等の解析を行うことで、体動の他、呼吸および脈拍といった生体情報をさらに算出することができる。

【0287】

ベース装置１０６は、外部電源から電力を取得する電力取得部１２３を備える。本実施形態において、ベース装置１０６は、図示しない電源コードを介してＡＣアダプタおよび電源プラグに接続（着脱可能でもよい）されている。電源プラグが外部電源のコンセントに接続されることによって、ベース装置１０６の電力取得部１２３に電力が供給される。ベース装置１０６は、電力取得部１２３によって取得される、外部電源からの電力によって動作する。また、電力取得部１２３は、供給された電力をコネクタ１２１を介して携帯端末１０５へ送ることで携帯端末１０５の充電を行う。なお、他の実施形態においては、ベース装置１０６は、電池を有していてもよく、電池に充電された電力を携帯端末１０５へ送るようにしてもよい。また、本実施形態においては、コネクタを介して電力が供給される態様で充電が行われるが、他の実施形態においては、非接触充電によって電力が供給されてもよい。

【0288】

ベース装置１０６は、壁面（天井を含む）やスクリーンに画像を投影するプロジェクタ１２５を備える。プロジェクタ１２５は、ベース装置１０６から離れた面（凹凸があってもよい）に画像を投影することで当該面に画像を表示する任意の表示装置でよい。本実施形態においては、図２３に示すように、プロジェクタ１２５は、投光部（具体的には、レンズ）１２５ａが上方を向くように、すなわち、上方に向かって画像が投影されるようにベース装置１０６に設けられる。つまり、本実施形態においては、プロジェクタ１２５は、天井に画像を投影する。本実施形態において、プロジェクタ１２５は、例えば、ユーザに入眠や覚醒を促す画像（例えば、後述する入眠用コンテンツ等）を表示したり、ユーザが朝に覚醒した時に睡眠の評価結果を示す画像を表示したりしてもよい。

【0289】

本実施形態においては、ベース装置１０６は、天井に投影する画像を、必要に応じて、いわゆるプロジェクションマッピングの技術を用いて補正する。すなわち、ベース装置１０６は、プロジェクタ１２５の投影面（すなわち、天井）の凹凸および／または色に応じた画像が表示されるように当該画像を補正する。なお、画像の補正方法は従来から用いられている方法であってよい。また、ベース装置１０６は、画像の補正を行うためのカメラ１２７を備える。図２３に示すように、カメラ１２７は、プロジェクタ１２５によって画像が投影される場所を撮像範囲に含むような向きでベース装置１０６に設けられる。つまり、カメラ１２７は、プロジェクタ１２５と同じ方向（すなわち、上方）を向くように設けられる。

【0290】

また、ベース装置１０６はスピーカ１２６を備える。スピーカ１２６は、例えば、ユーザに入眠や覚醒を促す音（例えば、後述する入眠用コンテンツ等）を出力するために用いられる。

【0291】

ベース装置１０６は、ベース装置１０６の各部１２３～１２７を制御する制御部１２２を備える。制御部１２２は、ベース装置１０６の各部１２１，１２３～１２７に接続される。制御部１２２は、ベース装置１０６において実行される各種の制御処理を実行する。制御部１２２は、ＣＰＵおよびメモリを有する。ベース装置１０６においては、ＣＰＵがメモリを用いて、ベース装置１０６に記憶された情報処理プログラムを実行することによって上記各種の制御処理が実行される。例えば、制御部１２２は、電力取得部１２３を制御することによって、携帯端末１０５に対する充電動作を制御する。また、制御部１２２は、ベース装置においてユーザに提供するコンテンツや情報を、プロジェクタ１２５および／またはスピーカ１２６に再生させる。また、制御部１２２は、ドップラーセンサ１２４によって検出された情報を携帯端末１０５へ送信する。

【0292】

なお、ベース装置１０６は、図２２に示す構成に加えて、または代えて、他の構成を備えていてもよい。例えば、ベース装置１０６は、環境センサ、ディスプレイ、無指向性スピーカ、光源（例えば、照明）、および／または、におい発生装置等を備えていてもよい。なお、ベース装置１０６が環境センサを備える場合、携帯端末１０５は環境センサを備えていない構成であってもよい。また、携帯端末１０５およびベース装置１０６は、同種の環境センサ（すなわち、同じ情報を検出する環境センサ）を備えていてもよいし、異なる種類の環境センサを備えていてもよい。

【0293】

なお、第２の実施形態におけるデータサーバ２およびサービスサーバ３（本実施形態の説明において単に「サーバ」と記載することがある）の構成は、第１の実施形態と同様である。したがって、第２の実施形態においても第１の実施形態と同様、端末システム１００は健康情報をサーバへ送信し、サーバは健康情報に基づいて提供情報を生成して端末システム１００へ送信する。ただし、第２の実施形態では、ユーザに提供すべき提供情報を決定する処理が端末システム１００自身によっても実行される。そのため、第２の実施形態においては、サーバは提供情報を端末システム１００へ送信する処理を実行しなくてもよい。

【0294】

［２．端末システムにおける動作］
（２－１：端末システムにおける動作の概要）
次に、第２の実施形態における端末システム１００における動作の概要について説明する。以下では、ユーザに提供される提供情報として、入眠用コンテンツとして再生される楽曲が提供される場合を例として説明する。なお、入眠用コンテンツとは、ユーザに入眠を促すための音楽および／または映像（静止画でも動画でもよい）である。つまり、本実施形態においては、ユーザの入床時に、ユーザに入眠を促すための楽曲が再生される。ここで、端末システム１００は、再生すべき楽曲の候補（候補楽曲と呼ぶ）を示す情報をまずユーザに提示し、候補楽曲のうちからユーザが選択した楽曲を再生する。したがって、本実施形態においては、候補楽曲の情報が提供情報であると言うこともできるし、実際に再生される楽曲が提供情報であると言うこともできる。

【0295】

また、端末システム１００は、候補楽曲を決定するための決定ルールを予め記憶しており、当該決定ルールに従って候補楽曲を決定する。なお、決定ルールは、提供情報である候補楽曲の情報（あるいは実際に再生される楽曲）を決定するための条件であるので、上述した提供条件と言うことができる。ここで、本実施形態においては、決定ルールはユーザ毎に更新される。つまり、本実施形態においては、提供条件はユーザ毎に設定され、ユーザ毎にカスタマイズされる。以下、図２４を参照して、端末システム１００における処理の流れの概要を説明する。

【0296】

図２４は、第２の実施形態における端末システム１００による処理の流れの一例を示す図である。図２４は、ユーザが入床してからユーザが覚醒した後までの期間において端末システム１００が実行する処理を示している。

【0297】

第２の実施形態においても第１の実施形態と同様、端末システム１００は、ユーザが入床する際に生体情報の計測を開始する（ステップＳ１０１）。具体的には、ユーザは、入床時に携帯端末１０５をベース装置１０６に装着する。端末システム１００は、携帯端末１０５がベース装置１０６に装着されたことによって、ユーザが入床したと判別する（すなわち、入床を検知する）。入床が検知されたことに応じて、端末システム１００は、ユーザの健康情報を算出するための計測を開始する。

【0298】

第２の実施形態における健康情報の算出方法は第１の実施形態と同様であり、睡眠指標および疲労指標を含む健康情報が算出される。なお、第２の実施形態において、図４に示す各部の機能は携帯端末１０５が有するものとする。すなわち、第２の実施形態においては、ベース装置１０６から携帯端末１０５へ生体情報が送信され、携帯端末１０５が生体情報に基づいて健康情報を算出する。なお、他の実施形態においては、図４に示す各部の機能は携帯端末１０５に設けられてもよいし、ベース装置１０６に設けられてもよい。

【0299】

なお、計測を開始する条件は任意である。例えば他の実施形態において、携帯端末１０５とベース装置１０６とが無線通信可能である場合、計測を開始する旨の指示が携帯端末１０５からベース装置１０６へ送信されたことに応じて、ベース装置１０６は計測を開始するようにしてもよい。また、ベース装置１０６は、所定時間間隔で、自身の周囲にユーザが存在するか否かを、例えばドップラーセンサ１２４を用いて判定し、ユーザが存在すると判定したことに応じて計測を開始してもよい。

【0300】

次に、端末システム１００は、上記の候補楽曲を示す情報をユーザに提供する処理を実行する（ステップＳ１０２）。本実施形態においては、携帯端末１０５は、それまでに算出された健康情報（すなわち、過去の睡眠期間に取得された生体情報に基づいて算出された健康情報）に基づいて候補楽曲を決定する。詳細は後述するが、携帯端末１０５は、最近１週間の睡眠の傾向を特定し、傾向に応じた候補楽曲を決定する。例えば、寝付きが悪い（睡眠潜時が長い）と傾向があると特定された場合には、寝付きが良くなる効果があると考えられる楽曲が候補楽曲として決定される。携帯端末１０５は、決定された候補楽曲を示す情報（例えば、楽曲のタイトル）を、提供情報としてユーザに提供する。具体的には、決定した候補楽曲を示す情報が、携帯端末１０５のディスプレイ１１７に表示される。

【0301】

図２５は、候補楽曲を示す情報を提供するために携帯端末１０５に表示される画像の一例を示す図である。図２５に示すように、携帯端末１０５のディスプレイ１１７には、決定された候補楽曲を示す候補楽曲画像１３１が表示される。なお、本実施形態においては、候補楽曲として３つの楽曲（図２５では、楽曲Ａ～Ｃ）がユーザに提示される場合を例とするが、候補楽曲の数はいくつであってもよい。また、本実施形態においては、候補楽曲画像１３１とともに、ユーザに対するアドバイス情報を示すアドバイス画像１３２が表示される。アドバイス画像１３２については後述する。

【0302】

ディスプレイ１１７に楽曲情報画像１３１が表示されると、ユーザは、候補楽曲のうちから所望の楽曲を選択する（ステップＳ１０３）。楽曲の選択は、例えば、ディスプレイ１１７に表示される候補楽曲のうち、所望の楽曲の項目にタッチする操作によって行われる。この操作に応じて、携帯端末１０５は、選択された楽曲の再生を開始する（ステップＳ１０４）。具体的には、携帯端末１０５は、楽曲の音データをベース装置１０６へ送信し、音データを受信したベース装置１０６はスピーカ１２６から楽曲を出力する。なお、他の実施形態においては、ベース装置１０６のスピーカ１２６と共に（または代えて）携帯端末１０５のスピーカ１１８から楽曲が再生されてもよい。

【0303】

なお、携帯端末１０５が再生可能な楽曲のリスト（換言すれば、候補楽曲を選択するための楽曲のリスト）は、携帯端末１０５に記憶されていてもよいし、サーバに記憶されていてもよい。上記リストがサーバに記憶されている場合、携帯端末１０５は、適宜のタイミングで（例えば、上記ステップＳ１０２を実行するタイミングで）サーバからリストを取得する。また、上記リストに含まれる楽曲の音データは、携帯端末１０５に記憶されていてもよいし、サーバに記憶されていてもよい。楽曲の音データがサーバに記憶されている場合、携帯端末１０５は、例えば再生する楽曲が選択されたタイミングで、選択された楽曲の音データをサーバから取得する。

【0304】

また、本実施形態においては、ユーザが睡眠中の期間（睡眠期間と呼ぶ）において、端末システム１００は、当該期間中における生体情報（および健康情報）に基づいてユーザの睡眠状態を判別し、睡眠状態に応じて携帯端末１０５の動作を制御する。具体的には、携帯端末１０５は、取得された生体情報に基づいてユーザが入眠したか否かを判定する。そして、ユーザが入眠したと判定された場合、携帯端末１０５は、上記ステップＳ１０４で開始した楽曲の再生を停止する（ステップＳ１０５）。ユーザが入眠したため、楽曲を再生する必要性が低いからである。なお、他の実施形態においては、携帯端末１０５は、ユーザが入眠した時点から所定時間が経過したタイミングで楽曲の再生を停止してもよいし、ユーザが深い眠りについた（ノンレム睡眠の状態になった）と判定されたタイミングで楽曲の再生を停止してもよい。また、他の実施形態においては、楽曲は、ユーザの睡眠状態に応じて停止されなくてもよい。例えば、他の実施形態においては、楽曲の再生開始から所定時間が経過したタイミングで当該楽曲の再生が停止されてもよい。

【0305】

また、他の実施形態においては、端末システム１００は、楽曲の再生の制御に限らず、他の動作を制御してもよい。例えば、他の実施形態においては、端末システム１００は、ユーザの睡眠状態に応じて、携帯端末１０５の状態を変更する（例えば、電源をオフにする、待機状態にする、マナーモードにする等）制御を行ってもよい。

【0306】

ユーザが覚醒すると、端末システム１００は、今回の睡眠期間における健康情報を算出する（ステップＳ１０６）。上述したように、端末システム１００は、第１の実施形態と同様の方法で、今回の睡眠期間において取得された生体情報に基づいて健康情報を算出する。なお、ユーザが覚醒したことは、生体情報に基づいて判別することができる。

【0307】

次に、携帯端末１０５は、ユーザに対する質問を生成し、生成した質問をユーザに提示する（ステップＳ１０７）。詳細は後述するが、質問は、ステップＳ１０６で算出された健康情報に基づいて生成される。例えば、携帯端末１０５は、算出された健康情報から、中途覚醒回数がいつもより多い（すなわち、今回算出された中途覚醒回数と平均値との差が大きい）と判別される場合には、「ぐっすり眠れましたか？」といった質問を行う。また例えば、いつもよりもユーザの疲労度が高い場合には、携帯端末１０５は、「疲れは取れましたか？」といった質問を行う。

【0308】

図２６は、覚醒時に携帯端末１０５に表示される画像の一例を示す図である。図２６に示すように、ユーザが覚醒した際には、評価結果画像１３５と質問画像１３６とがディスプレイ１１７に表示される。

【0309】

評価結果画像１３５は、今回の睡眠期間における睡眠および疲労に関する評価結果を表す。具体的には、評価結果画像１３５は、生体情報（および健康情報）に基づいて算出された評価結果である、快眠度および元気度を表す。快眠度は、快眠の度合い（睡眠の質とも言える）を示す指標（具体的には数値）である。快眠度の算出方法は任意であるが、例えば、数値が大きいほど良い状態を表すように、上述の睡眠指標に基づいて算出される。また、元気度は、ユーザの健康状態（本実施形態においては、睡眠の状態、および、疲労の度合い）をユーザにとってわかりやすく提示する目的で算出される数値である。元気度は、例えば上述の疲労度に基づいて算出され、数値が大きいほど良い状態（換言すれば、疲労度が小さい）を表す。元気度の算出方法は任意であり、例えば、元気度は、１００から疲労度を減算することによって算出されてもよい。このように、本実施形態においては、健康情報に関する評価結果として、快眠度および元気度が算出される。なお、このような快眠度および元気度も健康情報の一種である。本実施形態においては、健康情報に関する評価結果が覚醒時にユーザに提示されるので、ユーザは、起きてすぐに評価結果を知ることができる。

【0310】

また、質問画像１３６は、ステップＳ１０７で生成された質問を表す。図２６においては、「ぐっすり眠れましたか？」という質問を表す質問画像１３６が生成されて表示されている。また、本実施形態においては、質問画像１３６は、ユーザが回答を行うためのボタン画像（具体的には、「はい」および「いいえ」を表すボタン画像）を含む。なお、ユーザの回答はどのような形式で行われてもよく、例えば、２種類以上の選択肢から回答を選択させる形式であってもよいし、数値を入力させる形式であってもよい。

【0311】

質問画像１３６がディスプレイ１１７に表示された場合、ユーザは、質問に対する回答を入力する（ステップＳ１０８）。本実施形態においては、ユーザは、質問画像１３６に含まれるボタン画像を指定する入力（具体的には、タッチする入力）を行うことによって回答を行う。

【0312】

回答が入力されたことに応じて、携帯端末１０５は、上記の決定ルールを更新する（ステップＳ１０９）。詳細は後述するが、決定ルールの更新は、ステップＳ１０６で算出された健康情報と、ステップＳ１０８で入力されたユーザの回答とに基づいて行われる。例えば、健康情報が健康状態が良いことを示すものであったり、ユーザの入力が健康状態が良いことを示す回答であったりする場合には、入眠時に再生された入眠用コンテンツの楽曲がユーザにとって効果があった（あるいは、効果が大きかった）と判断することができる。そのため、この場合には、当該楽曲が選択されやすくなるように決定ルールが更新される。一方、健康情報が悪い状態を示すものであったり、ユーザの入力が健康状態が悪いことを示す回答であったりする場合には、入眠時に再生された入眠用コンテンツの楽曲がユーザにとって効果がなかった（あるいは、効果が小さかった）と判断することができる。そのため、この場合には、当該楽曲が選択されにくくなるように決定ルールが更新される。

【0313】

以上のように、第２の実施形態においては、端末システム１００は、健康情報に基づいて決定される候補楽曲の情報をユーザに提供することができる（ステップＳ１０２）。これによって、端末システム１００は、入眠用コンテンツとして、健康情報に基づく適切な楽曲をユーザに対して勧めることができる。

【0314】

さらに、第２の実施形態においては、端末システム１００は、睡眠から覚醒した後で、提供された楽曲について効果（具体的には、効果の有無や効果の程度）を判別する（ステップＳ１０６，Ｓ１０７）。楽曲を決定するための決定ルールは、判別結果に応じて更新される。決定ルールは、個別のユーザの健康情報および個別のユーザの回答に基づいて更新されるので、決定ルールはユーザ毎にカスタマイズされていく。これによれば、端末システム１００は、個別のユーザに適した提供情報を提供することができ、個別のユーザにとって有用な情報を提供することができる。

【0315】

（２－２：楽曲提供処理）
次に、端末システム１００において実行される、楽曲提供処理（上記ステップＳ１０２～Ｓ１０４）の具体例について説明する。上述のように、楽曲提供処理は、ユーザの入眠時に再生する楽曲（および候補楽曲）を提供する処理である。

【0316】

図２７は、端末システム１００の機能的構成の一例を示す機能ブロック図である。本実施形態においては、楽曲提供処理を実行するための構成として、端末システム１００は、分析部１５１と、健康情報記憶部１５２と、ジャンル決定ルール記憶部１５３と、楽曲決定ルール記憶部１５４とを備える（質問提示部１５５および更新部１５６については後述する）。本実施形態において、上記各部１５１～１５４は、携帯端末１０５の処理部１１１および／または記憶部（不図示）によって実現される。具体的には、分析部１５１は、処理部１１１が所定の情報処理プログラムを実行することによって実現される。また、各記憶部１５２～１５４は、上記所定の記憶部によって実現される。上記所定の記憶部は、処理部１１１がアクセス可能な任意の記憶媒体であり、携帯端末１０５に内蔵される記憶媒体であってもよいし、携帯端末１０５に着脱可能な外部記憶媒体であってもよい。

【0317】

分析部１５１は、ユーザの健康に関する分析を当該ユーザの生体情報に基づいて行い、分析結果に基づく情報（候補楽曲の情報、および、再生される楽曲）の提供を当該ユーザに対して行う。図２７に示すように、分析部１５１は、健康情報算出部１６１と、状態特定部１６２と、ジャンル決定部１６３と、楽曲決定部１６４と、情報提供部１６５とを含む。

【0318】

健康情報算出部１６１は、ベース装置１０６において検出された生体情報を取得し、取得された生体情報に基づいて健康情報を算出する。健康情報を算出する方法は、第１の実施形態と同様である。算出された健康情報は、健康情報記憶部１５２へ出力される。

【0319】

健康情報記憶部１５２は、ベース装置１０６において検出された生体情報と、健康情報算出部１６１によって算出された健康情報とを記憶する。健康情報記憶部１５２は、最新のものから過去に所定の保存期間（例えば、３月）に取得された生体情報および健康情報を記憶する。したがって、生体情報および健康情報が取得された場合、健康情報記憶部１５２は、上記保存期間中の情報が保存されるように、情報を更新する。なお、本実施形態においては、健康情報記憶部１５２は、検出された生体情報および算出された健康情報の全ての種類を記憶する必要はなく、これらの生体情報および健康情報のうちで、候補楽曲を決定するために用いる情報を記憶してもよい。

【0320】

状態特定部１６２は、ユーザに関する健康情報に基づいて、当該ユーザの健康状態を特定（推測とも言える）する。本実施形態においては、状態特定部１６２は、ユーザの健康状態として、所定期間（例えば、最近１週間）における睡眠の傾向を算出する。具体的には、状態特定部１６２は、健康情報記憶部１５２から健康情報を取得し、取得された健康情報に基づいて、最近１週間の、入眠潜時の平均と中途覚醒回数の平均とを少なくとも算出する。なお、健康状態として算出される情報は任意である。状態特定部１６２は、例えば、入眠潜時および中途覚醒回数以外の他の睡眠指標に関する状態を算出してもよいし、疲労に関する状態を算出してもよい。また、健康状態として算出される情報は、本実施形態のように、ユーザの最新の健康情報（例えば、最新の１回の睡眠に応じて算出される健康情報）と過去の健康情報とに基づいて算出されてもよいし、他の実施形態においては、ユーザの最新の健康情報に基づいて算出されてもよい。また、健康状態として算出される情報は、ユーザの健康情報と、他のユーザの健康情報とに基づいて算出されてもよい。例えば、他の実施形態においては、状態特定部１６２は、ユーザの健康情報（例えば、上記睡眠潜時）と、他のユーザの健康情報から得られる情報（例えば、他のユーザに関する入眠潜時の平均値）との比較に基づく情報（例えば、ユーザの睡眠潜時と平均値との差）を、上記健康状態として算出してもよい。なお、他のユーザの健康情報は、サーバから適宜のタイミングで端末システム１００に取得されてよい。

【0321】

ジャンル決定部１６３は、状態特定部１６２によって特定された健康状態に基づいて、ユーザに提供するべき候補楽曲のジャンルを決定する。ここで、本実施形態においては、上述した携帯端末１０５が再生可能な各楽曲には、楽曲毎にジャンルがそれぞれ設定されている。すなわち、再生可能な楽曲のリストには、楽曲の識別情報と、当該楽曲のジャンルを示す情報とが関連付けられている。ジャンル決定部１６３は、上記各楽曲に設定されている複数種類のジャンルのうちから、所定数（ここでは１種類）のジャンルを決定する。

【0322】

ジャンルの決定は、ジャンル決定ルールを用いて行われる。ジャンル決定ルール記憶部１５３は、上記ジャンル決定ルールを記憶している。図２８は、ジャンル決定ルールの一例を示す図である。本実施形態においては、図２８に示すように、ジャンル決定ルールは、睡眠の傾向に関する条件（睡眠条件）と、ジャンルに付された重みの設定内容とを関連付けた情報である。なお、図示しないが、ジャンル決定ルールは、ジャンルと、当該ジャンルに対して予め付された基準の重み値とをジャンル毎に関連付けた情報を含む。

【0323】

ジャンル決定部１６３は、特定された健康情報が、ジャンル決定ルールに含まれる睡眠条件を満たすか否かを睡眠条件毎に判定し、満たされた睡眠条件に関連付けられる設定内容を特定する。ジャンル決定部１６３は、特定された設定内容に従って、ジャンルに付される重み値を変更する。例えば、図２８に示す例において、特定された健康情報が、睡眠潜時が１５分以下で、かつ、中途覚醒回数が１～３回であることを示す場合、ジャンルＡの重み値を０．５だけ加算する設定内容と、ジャンルＤの重み値を０．５だけ加算する設定内容が特定される。その結果、ジャンルＡおよびジャンルＤの重み値がそれぞれ０．５だけ増加される。

【0324】

上記のように、本実施形態においては、予め設定された基準の重み値に対して、ジャンル決定ルールを用いて変更が加えられる。ジャンル決定部１６３は、このようにして変更が加えられた重み値に基づいて、ジャンルを決定する。重み値に基づいてジャンルを決定する方法は任意である。例えば、ジャンル決定部１６３は、重み値が最大となるジャンルを選択してもよい。また例えば、ジャンル決定部１６３は、重み値に応じた確率でジャンルが選択されるように、乱数を用いてジャンルを決定してもよい。これによれば、ジャンルの決定にランダム性を持たせることができ、多くの種類のジャンルが選択される可能性を高めることができる。すなわち、携帯端末１０５は、多くの種類のジャンルの楽曲をユーザに対して提示することができる。

【0325】

楽曲決定部１６４は、ジャンル決定部１６３によって決定されたジャンルに含まれる楽曲のうちから候補楽曲を決定する。候補楽曲は、楽曲決定ルールを用いて決定される。楽曲決定ルール記憶部１５４は、楽曲決定ルールを記憶している。楽曲決定ルールは、携帯端末１０５が再生可能な各楽曲と、楽曲に付された重みとを楽曲毎に関連付けたテーブルを含む。図２９は、楽曲決定ルールに含まれるテーブルの一例を示す図である。本実施形態においては、図２９に示すように、テーブルにおいて各楽曲について重み値が関連付けられている。また、各楽曲についてジャンルが関連付けられている。

【0326】

楽曲決定部１６４は、決定されたジャンルに含まれる各楽曲のうちから、当該各楽曲に付された重み値に基づいて候補楽曲（本実施形態では３つの候補楽曲）を選択する。重み値に基づいて候補楽曲を選択する方法は任意である。例えば、楽曲決定部１６４は、決定されたジャンルに含まれる各楽曲のうちから、重み値が大きいものから順に所定数（ここでは３つ）の楽曲を候補楽曲として選択してもよい。また例えば、楽曲決定部１６４は、決定されたジャンルに含まれる各楽曲のうちから重み値に応じた確率で楽曲が選択されるように、乱数を用いて所定数の楽曲を選択してもよい。これによれば、楽曲の決定にランダム性を持たせることができ、多くの種類の楽曲が選択される可能性を高めることができる。すなわち、携帯端末１０５は、多くの種類の楽曲をユーザに対して提示することができる。

【0327】

情報提供部１６５は、楽曲決定部１６４によって決定された候補楽曲の情報（例えば、楽曲のタイトル）をユーザに提供する。具体的には、楽曲決定部１６４は、候補楽曲画像１３１（図２５参照）をディスプレイ１１７に表示する。なお、本実施形態においては、候補楽曲画像１３１は、候補楽曲のタイトルに加えて、例えば「寝付きの悪い人におすすめ！」といったリコメンド情報を含む（図２５参照）。また、候補楽曲画像１３１とともに、アドバイス情報を表すアドバイス画像１３２が表示される（図２５参照）。これらのリコメンド情報およびアドバイス情報の内容は、例えば、状態特定部１６２によって特定された健康状態に基づいて決定される。例えば、携帯端末１０５は、健康状態に関する条件と、提示すべきリコメンド情報およびアドバイス情報の内容とを関連付けたテーブルを予め記憶しておき、当該テーブルを用いてこれらの情報の内容を特定する。すなわち、携帯端末１０５は、テーブルに含まれる条件のうちで、上記健康状態によって満たされた条件に関連付けられるリコメンド情報およびアドバイス情報の内容を特定する。このようにして特定された情報の内容がリコメンド情報およびアドバイス情報としてディスプレイ１１７に表示される。

【0328】

さらに、情報提供部１６５は、候補楽曲のうちから１つを選択するユーザ入力を受け付け、ユーザによって選択された楽曲を、入眠用コンテンツとして再生すべき楽曲に決定する。そして、情報提供部１６５は、決定された楽曲の音データを取得し、スピーカ１１８を用いて当該楽曲を再生する。これによって、入眠用コンテンツとして楽曲がユーザに提供される。

【0329】

（２－３：決定ルールの更新処理）
次に、図２７を参照して、端末システム１００において実行される、決定ルールの更新処理の具体例について説明する。決定ルールの更新処理は、入眠用コンテンツである楽曲の効果（具体的には、ユーザの健康状態を改善する効果）を判別し、判別結果に応じて決定ルールを更新する処理である。本実施形態においては、決定ルールの更新処理を実行するための構成として、端末システム１００は、上記の健康情報算出部１６１と、質問提示部１５５と、更新部１５６とを備える。本実施形態において、上記各部１５５および１５６は、携帯端末１０５の処理部１１１が所定の情報処理プログラムを実行することによって実現される。

【0330】

上述のように、ユーザの覚醒時において、健康情報算出部１６１は、今回の睡眠期間（すなわち、当該覚醒前の睡眠期間、換言すれば、覚醒時が終期となる睡眠期間）中に取得された生体情報に基づいて健康情報を算出する（図２４に示すステップＳ１０６）。

【0331】

質問提示部１５５は、健康情報算出部１６１によって算出された健康情報に基づいて、ユーザに対する質問を提示する（図２４に示すステップＳ１０７）。本実施形態においては、質問提示部１５５は、予め用意された複数の質問のうちから、健康情報に基づいて１つを選択する。提示する質問を決定する方法は任意であるが、本実施形態においては、健康情報に関する条件と質問とを関連付けたテーブルを用いる。

【0332】

図３０は、ユーザに提示する質問を決定するためのテーブルの一例を示す図である。図３０に示すように、テーブルは、健康情報に関する条件と、当該条件を満たした場合に提示される質問とを関連付けるものである。質問提示部１５５は、テーブルに含まれる条件のうちで、算出された健康情報によって満たされる条件を特定し、特定された条件に関連付けられる質問を選択する。図３０に示す例においては、例えば、今回の睡眠期間における中途覚醒回数が、平均値（例えば、最近１週間の平均値）と比べて１回以上の差がある場合、「ぐっすり眠れましたか？」という質問が選択される。

【0333】

なお、質問を決定する方法は、本実施形態のように、ユーザに関する最新の健康情報と過去の健康情報とに基づく方法であってもよいし、他の実施形態においては、ユーザに関する最新の健康情報に基づく方法であってもよい。また、質問は、ユーザの健康情報と、他のユーザの健康情報とに基づいて決定されてもよい。例えば、他の実施形態においては、質問提示部１５５は、ユーザの健康情報（例えば、上記中途覚醒回数）と、他のユーザの健康情報から得られる情報（例えば、他のユーザに関する中途覚醒回数の平均値）との比較に基づく情報（例えば、ユーザの中途覚醒回数と平均値との差）に基づいて質問を決定してもよい。

【0334】

質問提示部１５５は、選択された質問を表す質問画像１３６を生成してディスプレイ１１７に表示する。なお、選択された質問が複数となる場合、そのうちの所定数（例えば１つ）の質問のみがユーザに提示されてもよいし、選択された全ての質問が提示されてもよい。上述のように、質問が提示されると、ユーザは、質問に対する回答を入力する（図２４に示すステップＳ１０８）。

【0335】

更新部１５６は、上記質問に対するユーザの回答入力を取得する。また、更新部１５６は、健康情報算出部１６１によって算出された健康情報を取得する。更新部１５６は、上記の健康情報とユーザの回答とに基づいて、決定ルールのうちの楽曲決定ルールを更新する。本実施形態においては、楽曲決定ルールの更新は、上述した条件更新テーブルの一例であるルール更新テーブルを用いて行われる。ルール更新テーブルは、例えば楽曲決定ルール記憶部１５４に記憶される。

【0336】

図３１は、更新内容を決定するためのルール更新テーブルの一例を示す図である。図３１に示すように、ルール更新テーブルは、健康情報またはユーザの回答に関する条件と、当該条件を満たした場合に実行される更新内容とを関連付けるものである。更新部１５６は、ルール更新テーブルに含まれる条件のうちで、健康情報またはユーザの回答によって満たされる条件を特定し、特定された条件に関連付けられる更新内容を特定する。図３１に示す例においては、例えば、睡眠時間が平均値（例えば最近１週間の平均睡眠時間）以上である場合、重み値を０．１加算することを示す更新内容が特定される。なお、更新部１５６は、満たされる条件が複数存在する場合は、それぞれの条件に関連付けられる複数の更新内容を特定する。

【0337】

なお、更新内容を決定する方法は、本実施形態のように、ユーザに関する最新の健康情報と過去の健康情報とに基づく方法であってもよいし、他の実施形態においては、ユーザに関する最新の健康情報に基づく方法であってもよい。また、更新内容は、ユーザの健康情報と、他のユーザの健康情報とに基づいて決定されてもよい。例えば、他の実施形態においては、更新部１５６は、ユーザの健康情報（例えば、上記睡眠時間）と、他のユーザの健康情報から得られる情報（例えば、他のユーザに関する睡眠時間の平均値）との比較に基づく情報（例えば、ユーザの睡眠時間と平均値との差）に基づいて更新内容を決定してもよい。

【0338】

更新部１５６は、特定された更新内容に従って、楽曲決定ルール記憶部１５４に記憶される楽曲決定ルールを更新する。具体的には、上述の楽曲決定ルールに含まれるテーブル（図２９参照）における、更新対象となる楽曲に関連付けられる重み値を、特定された更新内容に従って増加または減少させる。なお、「更新対象となる楽曲」は、今回の睡眠期間において入眠用コンテンツとして再生された楽曲である。

【0339】

なお、上記ルール更新テーブルは、健康情報が良い状態を示す条件、または、ユーザの回答が健康状態が良いことを示す条件に対して、重み値を増加させる（すなわち、更新対象となる楽曲が選択されやすくなる）ような更新内容を関連付ける（図３１参照）。また、上記ルール更新テーブルは、健康情報が悪い状態を示す条件、または、ユーザの回答が健康状態が悪いことを示す条件に対して、重み値を減少させる（すなわち、更新対象となる楽曲が選択されにくくなる）ような更新内容を関連付ける。したがって、本実施形態によれば、入眠用コンテンツとして再生された楽曲がユーザの睡眠を改善する効果があると推測される場合には、今後において当該楽曲が候補楽曲として提供されやすくなる。一方、入眠用コンテンツとして再生された楽曲がユーザの睡眠を改善する効果がないと推測される場合には、今後において当該楽曲が候補楽曲として提供されにくくなる。

【0340】

なお、他の実施形態においては、決定ルールの更新は、今回の睡眠期間に関する健康情報（すなわち、新たな健康情報）に加えて、過去に算出された健康情報に基づいて行われてもよい。例えば、携帯端末１０５は、新たな健康情報と過去の健康情報とに基づいて、ユーザの健康状態が改善したか否かを判定し、判定結果に応じて更新内容を決定してもよい。具体的には、携帯端末１０５は、ユーザの健康状態が改善したと判定された場合には、更新対象となる楽曲の重み値を増加させ、ユーザの健康状態が改善していないと判定された場合には、更新対象となる楽曲の重み値を減少させてもよい。

【0341】

本実施形態においては、更新部１５６は、算出された健康情報およびユーザの回答に基づいて決定ルールの更新を行ったが、他の実施形態においては、健康情報およびユーザの回答のいずれか一方に基づいて更新を行ってもよい。また、他の実施形態においては、更新部１５６は、楽曲決定ルールと共に（または代えて）ジャンル決定ルールを更新してもよい。

【0342】

また、決定ルールの更新方法は任意である。他の実施形態においては、更新部１５６は、決定ルールに含まれる更新内容（具体的には重み値）を変更することに代えて（または共に）、決定ルールに含まれる条件を変更してもよい。例えば、更新部１５６は、当該条件に含まれる閾値（例えば、図２８に示すジャンル決定ルールに含まれる睡眠条件における閾値）を変更してもよい。例えば、上記睡眠条件において、ユーザが睡眠不足であることを判断するための睡眠条件として、「睡眠時間が６時間以下」という条件が設定されている状況を考える。この状況において、実際の睡眠時間が６時間以下であるにもかかわらず、算出された健康情報（または、入力されたユーザの回答）が、健康状態が良いことを示す場合、更新部１５６は、「睡眠時間が６時間以下」という条件における閾値である“６時間以下”を、例えば“５時間５０分”に変更してもよい。

【0343】

以上のように、本実施形態においては、提供情報の内容を決定したり、提供ルールを更新したりする手段として、図２８～図３１に示すようなテーブルを用いる例を説明した。ここで、提供情報の内容を決定したり、提供ルールを更新したりする手段は任意である。例えば、提供情報の内容の決定は、分析エンジンによって実行されてもよい。分析エンジンは、例えば、（１）健康情報に基づく睡眠・疲労の解析、（２）解析に基づく特徴部分（問題点や良い点）の評価、（３）特徴部分が生じた原因の推測、および、（４）原因に対する解決策の提供、を所定のアルゴリズムによって行う。このとき、提供ルールの更新は、上記分析エンジンのプログラムを更新する（換言すれば、アルゴリズムを更新する）ことによって行われてもよい。

【0344】

［３．端末システムにおける処理の具体例］
次に、第２の実施形態における端末システムにおいて実行される処理の具体例について説明する。図３２は、携帯端末１０５において実行される処理の流れの一例を示すフローチャートである。本実施形態において、図３２に示す一連の処理は、ユーザが入床したと検知されたこと、すなわち、携帯端末１０５がベース装置１０６に装着されたことに応じて開始される。なお、他の実施形態においては、上記一連の処理は、携帯端末１０５とベース装置１０６との通信が開始されたことに応じて開始されてもよいし、ユーザが携帯端末１０５またはベース装置１０６に対して所定の開始操作を行ったことに応じて開始されてもよい。

【0345】

まずステップＳ１２０において、携帯端末１０５は、開始時処理を実行する。開始時処理は、図３２に示す一連の処理の開始に応じて（本実施形態では、ベース装置１０６に携帯端末１０５が装着されたことに応じて）実行される処理である。具体的には、端末システム１００は、健康情報を算出するための生体情報を検出するセンサ（すなわち、ドップラーセンサ１２４）による検出を開始する（上記ステップＳ１５１）。すなわち、携帯端末１０５の処理部１１１は、ベース装置１０６に対して、検出動作を開始する旨の指示を行う。この指示に応じて、ベース装置１０６の制御部１２２は、ドップラーセンサ１２４に検出動作を開始させる。

【0346】

また、ステップＳ１２０の開始時処理が実行される際に（換言すれば、携帯端末１０５がベース装置１０６に装着されたことに応じて）、ベース装置１０６は、充電開始処理を実行する。充電開始処理において、ベース装置１０６は、携帯端末１０５に対する充電を開始する。具体的には、制御部１２２は、充電を開始する旨の指示を電力取得部１２３に対して行う。この指示に応じて、電力取得部１２３は、外部電源から供給される電力を、コネクタ１２１を介して携帯端末１０５へ供給する。なお、ベース装置１０６は、外部電源に接続された状態（すなわち、電源プラグがコンセントに接続された状態）であるとする。なお、ベース装置１０６は、携帯端末１０５の電池残量を確認し、電池残量が所定量以下であることを条件として充電動作を開始するようにしてもよい。充電動作は、携帯端末１０５の電池が容量まで充電されたことに応じて終了する。

【0347】

ステップＳ１２１において、携帯端末１０５は、上述の楽曲提供処理（ステップＳ１０２～Ｓ１０４）を実行する。これによって、入眠用コンテンツである楽曲の再生が開始される。

【0348】

上記ステップＳ１２１の処理の後、以下に説明するステップＳ１２２～Ｓ１２５の処理が、ユーザの睡眠期間中において繰り返し実行される。なお、本実施形態においては、ステップＳ１２２～Ｓ１２５の処理ループは、所定時間に１回の割合で実行される。

【0349】

ステップＳ１２２において、携帯端末１０５は、ドップラーセンサ１２４の検出結果（すなわち、生体情報）を取得する。上記ステップＳ１２０の処理によって検出動作を開始したドップラーセンサ１２４は、検出結果（具体的には、出力波形）を制御部１２２へ出力する。制御部１２２は、検出結果を携帯端末１０５へ送信する。これによって、ドップラーセンサ１２４の検出結果が携帯端末１０５に取得される。なお、制御部１２２は、ドップラーセンサ１２４の検出結果の情報をそのまま携帯端末１０５へ送信してもよいし、検出結果に何らかの加工（例えば、検出結果の信号に含まれるノイズを除去する処理や、上記睡眠指標を算出する処理等）を行って携帯端末１０５へ送信してもよい。

【0350】

ステップＳ１２３において、携帯端末１０５は、睡眠情報（例えば、各種睡眠指標）を算出する。すなわち、処理部１１１は、ステップＳ１２２で取得された検出結果（すなわち、生体情報）に基づいて、各種睡眠指標を算出する。睡眠指標の算出は、第１の実施形態と同様の方法によって行われる。なお、ステップＳ１２３においては、処理部１１１は、後述するステップＳ１２４およびＳ１２５においてユーザの睡眠状態を判別するために用いられる睡眠情報を算出すればよい。ステップＳ１２３においては、処理部１１１は、睡眠期間が終了した時点でなければ算出できない睡眠指標（例えば、総睡眠時間）、疲労情報（換言すれば、疲労度）、および、元気度を算出しなくてもよい。

【0351】

ステップＳ１２４において、携帯端末１０５は、ユーザの睡眠状態に応じた情報処理を実行する。すなわち、処理部１１１は、ユーザの睡眠状態が所定の状態となったか否かを判定する。そして、所定の状態となったと判定された場合、携帯端末１０５（およびベース装置１０６）の動作、動作モード、および／または、設定が制御される。本実施形態においては、処理部１１１は、ユーザが入眠したと判定された場合、上記ステップＳ１２１で開始した楽曲の再生を停止する（図２４に示すステップＳ１０５参照）。

【0352】

ステップＳ１２５において、携帯端末１０５は、ユーザが覚醒したか否かを判定する。すなわち、処理部１１１は、ステップＳ１２２で取得される生体情報、および／または、ステップＳ１２３で算出される睡眠指標に基づいて、ユーザが覚醒したか否かを判定する。ユーザが覚醒したと判定された場合、ステップＳ１２６～Ｓ１２９の一連の処理が実行される。一方、ユーザが覚醒していないと判定された場合、ステップＳ１２２の処理が再度実行される。すなわち、ユーザが覚醒したと判定されるまで、ステップＳ１２２～Ｓ１２５の一連の処理が繰り返し実行される。

【0353】

ステップＳ１２６において、携帯端末１０５は、睡眠期間中に取得された生体情報に基づいて健康情報を算出する（図２４に示すステップＳ１０６）。健康情報の算出は、第１の実施形態と同様の方法によって行われる。

【0354】

ステップＳ１２７において、携帯端末１０５は、ステップＳ１２６で算出された健康情報に基づいて質問をユーザに提示し（図２４に示すステップＳ１０７）、当該質問に対する回答の入力をユーザから受け付ける（図２４に示すステップＳ１０８）。すなわち、処理部１１１は、上述の質問画像１３６をディスプレイ１１７に表示し、上記回答の入力を操作入力部１１２から取得する。

【0355】

ステップＳ１２８において、携帯端末１０５は、ステップＳ１２６で算出された健康情報と、ステップＳ１２７で入力されたユーザの回答とに基づいて、決定ルールを更新する（図２４に示すステップＳ１０９）。

【0356】

ステップＳ１２９において、携帯端末１０５は、ステップＳ１２６で算出された健康情報をサーバへ送信する。すなわち、処理部１１１は、算出された健康情報を通信部１１０によってサーバへ送信する。これによって、１回の睡眠期間に対する健康情報がサーバへ送信され、サーバにおいて保存されることになる。このように、本実施形態においては、携帯端末１０５は、送信すべき情報を自動的にサーバへ送信する。つまり、ユーザが指示を行わなくても、サーバへ情報がアップロードされる。

【0357】

上記ステップＳ１２９の後、携帯端末１０５は、図３２に示す一連の処理を終了する。このとき、処理部１１１は、ベース装置１０６に対して、検出動作を停止する旨の指示を行う。この指示に応じて、ベース装置１０６の制御部１２２は、ドップラーセンサ１２４に検出動作を停止させる。

【0358】

なお、本実施形態においては、上記睡眠期間中において、何らかの理由で携帯端末１０５がベース装置１０６から外された場合（例えば、ユーザが寝返りをうった際に携帯端末１０５に当たってしまった場合）、ベース装置１０６は、ドップラーセンサ１２４の検出結果を携帯端末１０５へ送信することができない。この場合、ベース装置１０６は、携帯端末１０５へ送信することができなかった検出結果のデータを自身の記憶部（例えば、メモリ等）に記憶しておく。そして、次に携帯端末１０５がベース装置１０６に装着されたことに応じて、ベース装置１０６は、記憶部に記憶されている検出結果のデータを携帯端末１０５へ送信する。上記データを受信した携帯端末１０５は、検出結果に基づいて睡眠指標を算出する（ステップＳ１２３）。なお、携帯端末１０５は、このとき算出された睡眠指標に基づく制御処理（ステップＳ１２４）を実行しなくてよい。このとき算出された睡眠指標は、過去の検出結果に基づくものであるからである。

【0359】

また、算出された睡眠指標に基づいて、ユーザが覚醒していると判定された場合（ステップＳ１２５の判定結果が肯定となる場合）、携帯端末１０５は、上記ステップＳ１２６～Ｓ１２９の処理を実行する。このように、ユーザの睡眠中に携帯端末１０５がベース装置１０６から外された場合であっても、次に携帯端末１０５がベース装置１０６に装着されると、決定ルールの更新が行われるとともに、健康情報がサーバへ送信される。したがって、例えば、ユーザが覚醒した時に、携帯端末１０５がベース装置１０６から外れていたことに気づいた場合には、ユーザは、携帯端末１０５をベース装置１０６に装着するとよい。これによって、端末システム１００は、決定ルールの更新を行うことができるとともに、健康情報をサーバへ送信することができる。

【0360】

なお、他の実施形態において、携帯端末１０５とベース装置１０６とが無線通信可能である場合には、携帯端末１０５がベース装置１０６から外れた場合であっても、上記ステップＳ１２２～Ｓ１２５の処理を継続して実行することができる。

【0361】

なお、携帯端末１０５は、図３２に示す処理の他、第１の実施形態における主端末装置１０が通常モードにおいて実行する処理と同様の処理を実行してもよい。すなわち、携帯端末１０５はサービスサーバ３にアクセスして、ユーザの健康情報をディスプレイ１６に表示したり、サービスサーバ３から提供される提供情報をディスプレイ１６に表示したりしてもよい。

【0362】

［４．第２の実施形態における変形例］
（複数のユーザの健康情報に基づく更新を行う変形例）
上記第２の実施形態においては、更新条件である決定ルールは、端末システム１００のユーザ個人の健康情報に基づいて更新された。ここで、他の実施形態においては、決定ルールは、複数のユーザの健康情報に基づいて更新されてもよい。また、上記第２の実施形態においては、決定ルールは、携帯端末１０５のユーザ用に更新された。つまり、決定ルールは、端末システム１００のユーザ個人にのみ用いられるものであった。ここで、他の実施形態においては、決定ルールは、複数のユーザについて共通の部分を含んでいてもよい。以下、第２の実施形態における変形例として、決定ルールの一部が、複数のユーザに対して共通に用いられ、複数のユーザの健康情報に基づいて更新される例について説明する。

【0363】

図３３は、第２の実施形態の変形例における端末システム１００の機能的構成の一例を示す機能ブロック図である。図３３においては、決定ルールの更新処理を実行するための構成として、端末システム１００は、上記の健康情報算出部１６１と、質問提示部１５５と、第１更新部１７１と、第２更新部１７２とを備える。なお、図３３において、図３２と同じ参照符号が付された構成要素は、図３２と同じであり、これらの構成要素については詳細な説明を省略する。

【0364】

第１更新部１７１は、第２の実施形態における更新部１５６と同じである。本変形例においては、端末システム１００は、第１更新部１７１に加えて第２更新部１７２を備える。本変形例において、上記各部１７１および１７２は、携帯端末１０５の処理部１１１が所定の情報処理プログラムを実行することによって実現される。

【0365】

第２更新部１７２は、決定ルールのうちのジャンル決定ルールを更新する。本変形例において、ジャンル決定ルールは、複数のユーザの健康情報に基づいて更新される。具体的には、サーバは、提供条件としてジャンル決定ルールを記憶しておくとともに、第１の実施形態と同様に、各端末システムから受信した健康情報をユーザ毎に記憶する。また、サーバは、健康情報とともに、入眠用コンテンツとして再生された楽曲を示す情報を各端末システムから受信し、健康情報に関連付けて記憶する。サーバは、所定のタイミングで、複数のユーザに関する健康情報に基づいて、ジャンル決定ルールを更新する。

【0366】

上記所定のタイミングは任意であり、例えば、サーバの管理者（ネットワークサービスの管理者）が決定するタイミングであってもよい。また例えば、上記所定のタイミングは、上述の“（提供条件を自動的に更新する変形例）”で述べたような、サーバにおいて設定されるデータ数条件および／または変更条件が満たされたタイミングであってもよい。例えば、サーバは、あるジャンルの楽曲が関連付けられる健康情報が所定数だけ取得されたタイミングを上記所定のタイミングとしてもよい。

【0367】

また、ジャンル決定ルールの更新の内容は任意である。本変形例においては、サーバは、あるジャンルの楽曲が関連付けられる健康情報に基づいて、当該あるジャンルの楽曲の効果を判断し、効果に応じてジャンル決定ルールを更新する。例えば、図２８に示すジャンル決定ルールを例として説明すると、ジャンルＣの楽曲が関連付けられる健康情報に基づいて、入眠潜時が短くなるように改善された効果があると判断される場合、サーバは、ジャンルＣの重み値に対する加算値（図２８では“＋１”）を増加させる。上記のように、サーバは、入眠用コンテンツとしての楽曲の効果として、健康情報の履歴（すなわち、複数回の睡眠期間における健康情報）に基づいて、健康状態が改善したか否かを表す情報を算出してもよい。

【0368】

ジャンル決定ルールを更新した場合、サーバは、更新内容を示す情報を含む更新通知を各端末システムへ送信する。各端末システムは、更新通知に従って、自身に記憶されているジャンル決定ルールを更新する。すなわち、サーバからの更新通知が端末システム１００において受信されると、第２更新部１７２は、更新通知が示す更新内容に従って、ジャンル決定ルール記憶部１５３に記憶されているジャンル決定ルールを更新する。これによって、サーバに記憶されるジャンル決定ルールと、端末システム１００に記憶されるジャンル決定ルールとの内容を同期させることができる。

【0369】

なお、サーバは、ネットワークサービスの全てのユーザに対して適用されるジャンル決定ルールを記憶していてもよいし、ネットワークサービスのユーザのうち、所定のグループに属するユーザに適用されるジャンル決定ルールを記憶していてもよい。所定のグループとは、例えば、性別、年齢、住所、および／または、趣味嗜好等に応じてユーザを区分するグループである。サーバが、上記グループに対応するジャンル決定ルールを記憶しており、当該ジャンル決定ルールを更新する場合には、サーバは、当該グループに属するユーザの端末システムへ更新通知を送信する。このとき、当該グループに属しないユーザの端末システムへは更新通知は送信されない。

【0370】

（ルールに関する変形例）
上記変形例においては、上記楽曲決定ルールがユーザ毎の健康情報に基づいてユーザ毎に更新され、上記ジャンル決定ルールが複数のユーザの健康情報に基づいて更新された。ここで、他の実施形態においては、端末システム１００は、ユーザ毎の健康情報と、複数のユーザの健康情報との両方に基づく任意の方法でルールの更新を行ってよい。例えば、他の実施形態においては、以下の方法によってルールの更新が行われてもよい。

【0371】

図３４は、第２の実施形態の他の変形例における端末システムの機能的構成の一例を示す機能ブロック図である。なお、図３４においては、端末システムの機能的構成の一部のみを示し、図２７または図３３と同じ部分については構成を省略している。図３４に示すように、本変形例においては、分析部１５１は、ジャンル決定部１６３および楽曲決定部１６４に代えて、第１楽曲決定部１８１および第２楽曲決定部１８３を備える。また、端末システム１００は、楽曲決定ルール記憶部１５４およびジャンル決定ルール記憶部１５３に代えて、第１楽曲決定ルール記憶部１８２および第２楽曲ルール記憶部１８４を備える。

【0372】

本変形例においては、第１楽曲決定部１８１は、状態特定部１６２によって特定された健康状態に基づいて、携帯端末１０５が再生可能な各楽曲の重み値を算出する。ここで、第１楽曲決定部１８１における重み値は、第１楽曲決定ルール記憶部１８２に記憶される第１のルールを用いて決定される。上記重み値の決定方法は任意である。例えば、図２８に示すジャンル決定ルールにおける設定内容を、楽曲に付された重みに関する設定内容に変更した情報を用いて重み値が決定されてもよい。すなわち、第１のルールは、睡眠の傾向に関する条件と、楽曲に付された重みに関する設定内容とを関連付けた情報であってもよい。このとき、第１楽曲決定部１８１は、状態特定部１６２によって特定された健康情報が、第１のルールに含まれる睡眠条件を満たすか否かを睡眠条件毎に判定し、満たされた睡眠条件に関連付けられる設定内容に従って、楽曲に付される重み値を変更する。なお、詳細は後述するが、本変形例において、上記第１のルールは、複数のユーザの健康情報に基づいて更新される（つまり、複数のユーザに関して共通の内容となる）。

【0373】

第２楽曲決定部１８３は、第１楽曲決定部１８１によって算出された各楽曲の重み値を、状態特定部１６２によって特定された健康状態に基づいて補正する。ここで、第２楽曲決定部１８３による補正は、第２楽曲決定ルール記憶部１８４に記憶される第２のルールを用いて行われる。補正の具体的な方法は任意である。例えば、第１のルールと同様、第２のルールとして、睡眠の傾向に関する条件と、楽曲に付された重みの補正内容とを関連付けた情報を用いて補正が行われてもよい。このとき、第２楽曲決定部１８３は、状態特定部１６２によって特定された健康情報が、第２のルールに含まれる睡眠条件を満たすか否かを睡眠条件毎に判定し、満たされた睡眠条件に関連付けられる設定内容に従って、楽曲に付される重み値を補正する。なお、詳細は後述するが、本変形例において、上記第２のルールは、ユーザ毎の健康情報に基づいて更新される（つまり、ユーザ毎にカスタマイズされる）。

【0374】

なお、第１楽曲決定部１８１において重み値の算出に用いられる健康状態の情報と、第２楽曲決定部１８３において重み値の補正に用いられる健康状態の情報とは、同じであってもよいし、異なっていてもよい。例えば、第１楽曲決定部１８１は、ユーザの最新の健康情報に基づいて状態特定部１６２によって特定される健康状態を用い、第２楽曲決定部１８３は、当該ユーザの過去の健康情報に基づいて状態特定部１６２によって特定される健康状態を用いてもよい。また例えば、第１楽曲決定部１８１は、第１の種類の健康状態（例えば、睡眠時間）を用い、第２楽曲決定部１８３は、第２の種類の健康状態（例えば、入眠潜時）を用いてもよい。

【0375】

第２楽曲決定部１８３は、補正後の重み値に基づいて上述の候補楽曲を選択する。そして、第２楽曲決定部１８３は、選択した候補楽曲を示す情報を情報提供部１６５へ出力する。なお、重み値に基づく候補楽曲の選択方法は、上記第２の実施形態と同様の方法であってもよい。

【0376】

上記のように、本変形例においては、上記決定ルールは、第１のルールと第２のルールを含む。ここで、本変形例において、第１のルールは、複数のユーザの健康情報に基づいて更新され、第２のルールは、ユーザ毎の健康情報に基づいて更新される（図３４参照）。これによって、本変形例においても上記第２の実施形態と同様、ユーザ毎に提供条件を更新することができ、ユーザ毎に提供条件がカスタマイズされる。

【0377】

第１のルールの更新方法は任意であるが、例えば、第１のルールは、上述の“（複数のユーザの健康情報に基づく更新を行う変形例）”におけるジャンル決定ルールの更新と同様の方法で更新されてもよい。つまり、第１のルールとジャンル決定ルールとは、重み値が楽曲に付されるものであるか楽曲のジャンルに付されるものであるかの違いはあるが、重み値を更新する方法としては同様の方法を用いることができる。例えば、ある楽曲について睡眠の改善効果があると判断された場合、サーバは、当該楽曲の重み値が大きく設定されやすくなるように第１のルールを更新する。そして、サーバは、第１のルールに関する更新内容を示す情報を含む更新通知を各端末システムへ送信する。各端末システムは、更新通知に従って、自身に記憶されている第１のルールを更新する。

【0378】

第２のルールの更新方法は任意であるが、例えば、第２のルールは、上記実施形態における楽曲決定ルールの更新と同様の方法で更新されてもよい。すなわち、端末システム１００は、ユーザが覚醒したことに応じたタイミングで、上記ルール更新テーブルに従って、第２のルールの更新内容を決定してもよい。例えば、端末システム１００は、入眠用コンテンツとして再生された楽曲がユーザの睡眠を改善する効果があると推測される場合には、今後において当該楽曲が候補楽曲として提供されやすくなるように、第２のルールを更新する。

【0379】

上記変形例によれば、複数のユーザに適用される第１のルールに基づく結果（重み値）が、ユーザ毎にカスタマイズされる第２のルールに基づいて補正され、補正後の結果に基づいて提供情報の内容（すなわち、候補楽曲）が決定される。これによれば、端末システム１００は、第２のルールによって個別のユーザの健康状態を反映した情報を提供することができるので、上記第２の実施形態と同様、各ユーザに適した提案を行うことができる。

【0380】

なお、上記変形例において、端末システム１００は、第１のルールに基づいて算出される重み値を用い、第２のルールを用いなくても（すなわち、第２のルールに基づく補正が行われなくても）候補楽曲を決定することができる。したがって、他の実施形態においては、端末システム１００は、所定の条件下で、第２のルールを用いずに、第１のルールに基づいて算出される重み値を用いて候補楽曲を決定するようにしてもよい。例えば、端末システム１００は、第２のルールを用いるか否かをユーザの指示に従って設定するようにしてもよい。また例えば、端末システム１００の利用の初期段階において、第２のルールの精度が低いと想定される場合（例えば、第２のルールが十分に更新されていない場合）には、第２のルールを用いないようにしてもよい。

【0381】

（環境情報に基づく提供情報を提供する変形例）
他の実施形態においては、端末システム１００は、環境センサ１１４によって検出される環境情報を用いて提供情報の提供を行ってもよい。具体的には、健康情報記憶部１５２は、ユーザの睡眠期間における環境情報を取得して記憶する。状態特定部１６２は、環境情報を考慮して睡眠の傾向を算出する。そして、ジャンル決定部１６３および／または楽曲決定部１６４は、環境情報を考慮して睡眠の傾向に基づいて候補楽曲を決定する。例えば、環境情報として気温が用いられる場合、状態特定部１６２は、端末システム１００のユーザについての、睡眠潜時と気温との関係を算出する。そして、当該ユーザについて気温が低い場合に寝付きが悪い（すなわち、睡眠潜時が長い）傾向がある場合であって、提供情報を提供する際（ユーザが入床した後）に取得された環境情報に基づいて気温が低いと判断される場合には、ジャンル決定部１６３は、寝付きが良くなる効果があると思われるジャンルが選択されやすくなるように重み値を変更してもよい。

【0382】

（環境情報に基づく更新を行う変形例）
また、他の実施形態においては、端末システム１００は、環境センサ１１４によって検出される環境情報を用いて決定ルールの更新を行ってもよい。具体的には、健康情報記憶部１５２は、ユーザの睡眠期間における環境情報を取得して記憶する。更新部１５６は、睡眠期間に取得された生体情報に基づいて算出された健康情報と、当該睡眠期間に取得された環境情報とに基づいて、決定ルールの更新内容を決定する。例えば、更新部１５６は、健康情報が示す中途覚醒回数に応じて、更新対象となる楽曲の重み値を変化させる場合において、重み値の変化量を睡眠期間中の気温に応じて決定してもよい。すなわち、睡眠期間中の気温が高すぎたり低すぎたりする場合には、気温が原因で中途覚醒回数が増えると考えられる。したがって、このような場合に中途覚醒が多くても、更新部１５６は、重み値の変化量（具体的には減少量）を相対的に小さくする。一方、睡眠期間中の気温が適温である（すなわち、所定範囲内である）場合には、気温が原因で中途覚醒回数が増えるとは考えられない。したがって、このような場合に中途覚醒が多ければ、更新部１５６は、重み値の変化量（具体的には減少量）を相対的に大きくする。

【0383】

（位置情報を用いる変形例）
また、他の実施形態においては、端末システム１００は、位置検出部１１３によって検出される位置情報に基づいて、提供情報の提供、および／または、決定ルールの更新を行ってもよい。例えば、端末システム１００は、位置情報に基づいて、１日におけるユーザの行動を示す行動情報を算出してもよい。行動情報は、１日の位置情報の履歴から算出される情報であり、例えば、ユーザの移動量（例えば、歩数でもよい）を示す情報であってもよいし、ユーザの行動内容（例えば、職場で仕事をした、スポーツジムに行った等）を示す情報であってもよい。端末システム１００は、上記行動情報に基づいて提供情報の内容を決定してもよい。端末システム１００は、例えば、行動情報からユーザの疲労度を算出し、疲労度に応じて異なるジャンルを選択するようにしてもよい。

【0384】

また、端末システム１００は、上記行動情報に基づいて決定ルールの更新内容を決定するようにしてもよい。例えば、端末システム１００は、ある日の行動情報からユーザの疲労度を算出し、次の日におけるユーザの覚醒時に決定ルールを更新する際において、当該疲労度に応じて更新内容を異ならせるようにしてもよい。

【0385】

（提供情報の変形例）
第２の実施形態においては、提供情報が、入眠用コンテンツとして再生される楽曲、および、その楽曲の候補となる楽曲（候補楽曲）である場合を例として説明した。ここで、提供情報の内容は任意であり、任意の提供情報について提供条件をユーザ毎に更新することが可能である。例えば、提供情報は、上記第１の実施形態における商品等をユーザに紹介するリコメンド情報、および／または、ユーザの健康状態を改善するためのアドバイス情報であってもよい。

【0386】

また例えば、携帯端末１０５が複数種類の機能（アプリケーション）を提供可能である場合、携帯端末１０５は、当該複数種類の機能のうちからおすすめの機能を提供情報としてユーザに提供（紹介とも言える）してもよい。具体的には、携帯端末１０５は、取得された健康情報から、寝付きが悪いと判断されたユーザに対しては、上述の入眠用コンテンツを再生する機能を紹介し、目覚めが悪いと判断されたユーザに対しては、覚醒用コンテンツ（覚醒を促す音楽および／または映像）を覚醒前に再生する機能を紹介するようにしてもよい。

【0387】

（ベース装置に関する変形例）
他の実施形態においては、ベース装置１０６は、携帯端末１０５を介さずにサーバと通信を行ってもよい。例えば、ベース装置１０６は、携帯端末１０５と同様に、ネットワーク４を介してサーバと通信を行う機能を有していてもよい。このとき、ベース装置１０６は、自身で検出した情報を直接サーバへ送信してもよいし、携帯端末１０５とサーバとの両方へ送信してもよい。また、ベース装置１０６は、提供情報をサーバから直接受信してもよい。このとき、サーバは、携帯端末１０５とベース装置１０６との両方に提供情報を送信してもよいし、いずれか一方に提供情報を送信してもよい。

【0388】

［５．第２の実施形態における作用効果］
上記第２の実施形態および変形例においては、情報処理システムは、ユーザの健康に関する分析を当該ユーザの生体情報に基づいて行い、分析結果に基づく情報の提供を当該ユーザに対して行う（ステップＳ１０２～Ｓ１０４，Ｓ１２１、分析部１５１）。また、情報処理システムは、提供される情報を生体情報に基づいて決定するためのルール（条件とも言える。具体的には、決定ルール）の少なくとも一部（具体的には、楽曲決定ルール）を、ユーザの生体情報に基づいてユーザ毎に更新する（ステップＳ１０９，Ｓ１２８、更新部１５６、第１更新部１７１）。情報処理システムは、更新によってユーザ毎に設定されたルール（すなわち、更新されることによってユーザ毎にカスタマイズされる結果となったルール）を用いて、ユーザに提供する情報を決定する。上記によれば、ルールをユーザ個人に適した内容に変更することができるので、それぞれのユーザに対して有用な情報を提供することができる。

【0389】

上記ルールの更新とは、例えば、次のような処理を含む意味である。
・提供する情報を決定するための情報処理プログラムの更新
・提供する情報を決定するためのルールが記述されたテーブルの更新
・提供する情報を決定するためのアルゴリズムの更新
・提供する情報を決定するための分析エンジンの更新

【0390】

なお、ルールの更新を行うための生体情報は、任意のタイミングで取得されたものであってよい。また、情報処理システムは、更新前のルールに従って決定された提供情報が提供された後で取得された生体情報に基づいて、当該ルール（すなわち、更新前のルール）を更新してもよい。これによれば、更新前のルールによる提供情報の効果（つまり、有効な情報を提供することができたか否か）を反映してルールを更新することができる。

【0391】

上記第２の実施形態および変形例においては、上記ルールは、ユーザ毎に更新される第１の部分（具体的には、楽曲決定ルール、または、上記第２のルール）と、当該ユーザを含む複数のユーザで共通の第２の部分（具体的には、ジャンル決定ルール、または、上記第１のルール）とを含む。換言すれば、情報処理システムは、提供すべき情報を決定するためのルールとして、複数のユーザに関して共通の第１のルールと、当該複数のユーザのそれぞれに対して個別に設定される第２のルール（例えば、第２のルールは、ユーザ毎に異なる内容に設定される）との両方を用いる。これによれば、第１の部分によって個別のユーザに適した情報を提供することができるとともに、複数のユーザで共通する部分についてはルールを共有化することによって、ルールを更新する処理を簡易化することができる。

【0392】

なお、上記第１の部分と第２の部分は、上記“（複数のユーザの健康情報に基づく更新を行う変形例）”および“（ルールに関する変形例）”で説明した変形例のように、同じ提供情報（すなわち、候補楽曲の情報）を決定するために用いられるものであってもよい。また、上記第１の部分と第２の部分は、上述の第１のルールおよび第２のルールのように、同種の情報（上記変形例においては、楽曲の重み値）を決定するために用いられるものであってもよい。また例えば、上記第１の部分と第２の部分は、異なる提供情報を決定するために用いられるものであってもよい。つまり、第１の部分に基づいて第１の提供情報の内容が決定され、第２の部分に基づいて第２の提供情報の内容が決定され、第１および第２の提供情報が（上記提供情報として）ユーザに提供されてもよい。

【0393】

なお、上記第２の実施形態の変形例においては、情報処理システムは、提供情報を決定するための第１の情報（具体的には、第１楽曲決定部１８１によって算出される重み値）を、生体情報と第１のルールとを用いて算出する。さらに、情報処理システムは、算出された第１の情報と第２のルールとを用いて、提供情報を決定する。上記によれば、各ユーザに共通の第１のルールに基づく結果（すなわち、第１の情報）を、ユーザに個別の第２のルールによって加工（具体的には、補正）することによって、提供情報を決定することができる。

【0394】

さらに、上記変形例においては、情報処理システムは、第２のルールと生体情報とを用いて第２の情報（具体的には、第１楽曲決定部１８１によって決定される、重み値の補正内容）を算出し、上記第１情報と上記第２情報とに基づいて（具体的には、第１の情報を前記第２の情報によって補正することによって）提供情報を決定する。このとき、第１の情報が、第２のルールを用いなくても提供情報を決定することができる種類の情報である場合には、端末システム１００は、第２のルールを用いずに第１の情報によって提供情報を決定する態様と、第２のルールを用いて提供情報を決定する態様との両方を実行することができる。

【0395】

上記第２の実施形態の変形例においては、情報処理システムは、複数のユーザに関する各生体情報を取得する（すなわち、各端末システムはそれぞれのユーザの生体情報を取得する、あるいは、サーバは各端末システムから各ユーザの生体情報を取得する）。また、情報処理システムは、各生体情報に含まれる少なくとも複数の生体情報に基づいて、上記第２の部分を更新する（すなわち、サーバは上記更新通知を端末システムへ送信する、あるいは、端末システムは更新通知に応じてジャンル決定ルールを更新する）。これによれば、複数のユーザで共通の第２の部分については、当該複数のユーザの健康状態を考慮した適切な内容へと更新することができる。なお、「生体情報に基づいて更新する」とは、生体情報に基づいて算出される健康情報に基づいて更新することを含む意味である。

【0396】

なお、上記変形例のように、第１の部分を更新する条件（換言すれば、タイミング）は、第２の部分を更新する条件と異なっていてもよい。また、第１の部分を更新する頻度は、第２の部分を更新する頻度よりも高くてもよい。第１の部分については、個人のユーザに関する健康情報に基づいて更新されるので、高い頻度で更新することでそのユーザに適した内容とすることができる。これに対して、第２の部分については、複数のユーザに関する健康情報に基づいて更新されるので、ある程度の数の健康情報に基づいて更新することによって、複数のユーザにとって適切な内容とすることができる。

【0397】

上記第２の実施形態の変形例においては、情報処理システムは、１以上のユーザ端末（例えば端末システム１００）と、ユーザ端末とネットワークを介して通信可能なサーバシステム（例えば、データサーバ２およびサービスサーバ３）とを含む。ユーザ端末は、ユーザの健康に関する分析と、ルールの更新とを実行する機能を有する。ユーザ端末は、自身のユーザ端末によって取得された生体情報に基づいて上記第１の部分の更新を行う。サーバシステムは、複数のユーザに関する各生体情報を取得する。第２の部分は、サーバによって取得された複数の生体情報に基づいて更新される。これによれば、サーバにおいて複数の生体情報を取得することによって、ルールの更新を容易に行うことができる。

【0398】

上記第２の実施形態および変形例においては、情報処理システムは、ユーザの生体情報と、当該ユーザによる入力（ステップＳ１０８）とに基づいてルールの少なくとも一部をユーザ毎に更新する。これによれば、ユーザの主観（すなわち、ユーザによる入力）を考慮してルールを更新することができる。なお、ユーザによる入力は、任意の入力であってよく、上記実施形態のような質問に対する回答の入力に限らない。例えば、情報処理システムは、ユーザが自発的に行った入力（例えば、検索サイトにおける検索ワードの入力）に基づいて更新を行うようにしてもよい。また、情報処理システムは、ユーザに対して質問を提示し（ステップＳ１０７、質問提示部１５５）、質問に対する回答を上記ユーザによる入力として用いる。これによれば、ユーザにとっては入力が行いやすくなるとともに、情報処理システムにとっては有用なユーザ入力を得ることができる。

【0399】

さらに、上記第２の実施形態および変形例においては、情報処理システムは、情報の提供が行われた後で取得されたユーザの生体情報に基づいて質問内容を決定して当該ユーザに対して質問を提示する。そして、情報処理システムは、情報の提供が行われた後で取得されたユーザの生体情報と、質問に対する回答とに基づいてルールを更新する。これによれば、情報処理システムは、適切な質問をユーザに提示することができ、ルールの更新を行うための有用な回答入力を得ることができる。

【0400】

上記第２の実施形態の変形例においては、情報処理システムは、生体情報が検出されるときの（例えば、ユーザの睡眠期間中の）ユーザの周囲の環境に関する環境情報を取得する。情報処理システムは、提供される情報を、ユーザの生体情報と、当該ユーザに関する環境情報とに基づいて決定する。これによれば、ユーザの周囲の環境を考慮することによって、より有用な情報をユーザに提供することができる。また、情報処理システムは、上記ルールの少なくとも一部を、ユーザの生体情報と、当該ユーザに関する環境情報とに基づいて更新する。これによれば、ユーザの周囲の環境を考慮することによって、より適切にルールを更新することができる。

【0401】

上記第２の実施形態の変形例においては、情報処理システムは、提供情報として、ユーザの健康に関する情報、および／または、ユーザの健康を改善するための情報を当該ユーザに対して提供する。ここで、上述した入眠用コンテンツの楽曲や候補楽曲は、「ユーザの健康に関する情報」と言うことができ、また、「ユーザの健康の健康を改善するための情報」と言うことができる。また、第１の実施形態におけるアドバイス情報およびリコメンド情報、あるいは、上述の“（提供情報の変形例）”で述べたような、健康を改善するための機能（アプリケーション）の情報も、「ユーザの健康に関する情報」と言うことができ、また、「ユーザの健康の健康を改善するための情報」と言うことができる。

【0402】

上記第２の実施形態の変形例においては、情報処理システムは、繰り返し取得された生体情報に基づいて分析を繰り返し実行する（具体的には、ユーザが睡眠を行う度に分析が行われる。）。また、情報処理システムは、繰り返し取得された生体情報と、繰り返し実行された分析において算出された情報とのうちの少なくとも一部の情報を所定の記憶部（具体的には、健康情報記憶部１５２）に記憶する。情報処理システムは、記憶部に記憶された、複数回分の前記生体情報、および／または、複数回の分析において算出された情報（具体的には、最近１週間の健康情報）に基づいて上記ルールの少なくとも一部をユーザ毎に更新する。これによれば、複数回の計測および／または分析の結果を用いて上記ルールが更新されるので、より有用な情報をユーザに提供することができるようになる。また、情報処理システムは、上記ルールの更新を繰り返し行うので、ルールをユーザに適した内容へと次第に変更することができる。さらに、情報処理システムは、分析が行われる度に上記ルールの更新を行う。これによれば、分析の度にルールが更新されるので、ルールをこまめに更新することができる。

【0403】

＜その他の変形例＞
（各装置間における処理の分担に関する変形例）
以上において説明した、端末側とサーバ側との間での処理の分担、サーバ装置間での処理の分担、および、端末システム内における各装置間での処理の分担の態様は一例であり、情報処理システムにおける各処理はどのように分担されてもよい。例えば、上記第２の実施形態においては、決定ルールは端末側に記憶されたが、他の実施形態においては、決定ルールの一部（例えば、ジャンル決定ルール）または全部がサーバ側に記憶されてもよい。このとき、提供情報の内容を決定する処理、および、決定ルールを更新する処理は、サーバ側で実行されてもよい。

【産業上の利用可能性】

【0404】

以上のように、本発明は、有用な情報を提供すること等を目的として、情報処理システムや情報処理サーバ等に利用することができる。

【符号の説明】

【0405】

１ 端末システム
２ データサーバ
３ サービスサーバ
１０ 主端末装置
１１ ドップラーセンサ
１２ カメラ
１３ マイク
１４ 操作入力部
１５ 処理部
１６ ディスプレイ
１７ 照明部
１８ 近距離無線通信部
１９ モバイル通信部
２０ 副端末装置
２１ 荷重センサ
２２ タッチパネル
２３ 処理部
２４ 近距離無線通信部
３１ 波形解析部
３２ 睡眠算出部
３３ 自律神経算出部
３４ 疲労算出部
４１ ポータルサーバ
４２ サービス提供サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】