特許 6792223 管理システム、情報処理装置及び情報処理方法

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

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

(11)【特許番号】6792223

(24)【登録日】2020年11月10日

(45)【発行日】2020年11月25日

(54)【発明の名称】管理システム、情報処理装置及び情報処理方法

(51)【国際特許分類】

   G16H 20/60 20180101AFI20201116BHJP

【ＦＩ】

   G16H20/60

【請求項の数】11

【全頁数】18

(21)【出願番号】特願2019-159830(P2019-159830)

(22)【出願日】2019年9月2日

【審査請求日】2020年1月6日

【早期審査対象出願】

(73)【特許権者】

【識別番号】517255566

【氏名又は名称】株式会社エクサウィザーズ

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】坂根 裕

(72)【発明者】

【氏名】石山 洸

(72)【発明者】

【氏名】前川 智明

(72)【発明者】

【氏名】江崎 日淑

【審査官】 山内 裕史

(56)【参考文献】

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

【文献】 米国特許出願公開第２０１５／０１７１９２７（ＵＳ，Ａ１）

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

【文献】 特開２０１２−１７０５２５（ＪＰ，Ａ）

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

Ｇ１６Ｈ １０／００ − ８０／００

Ｇ０６Ｑ １０／００ − ９９／００

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

【請求項1】

水量センサ及び無線通信部を備えた容器と、ユーザが利用する施設に設置された複数の受信機と、該受信機が受信したデータを管理する情報処理装置と、を有する管理システムであって、
前記無線通信部は、前記水量センサが検出した前記容器内の水量を含む無線信号を発信し、
前記受信機は、前記容器から前記無線信号を受信し、
前記情報処理装置は、
前記受信機から、前記無線信号に含まれる前記水量と、前記無線信号の受信時点における前記容器の周辺状況を示すデータとを取得する取得部と、
前記周辺状況を示すデータに基づいて前記容器の水量変化の原因を推定し、推定された前記原因と前記水量に基づいて前記ユーザの水分摂取量を推定する推定部と、
を備えることを特徴とする管理システム。

【請求項2】

前記推定部は、前記原因がユーザの水分摂取であると推定された期間における前記水量に基づいて、前記水分摂取量を推定する
請求項１に記載の管理システム。

【請求項3】

前記推定部は、前記周辺状況を示すデータに基づいて、前記容器が存在する前記施設内のエリアを特定し、特定されたエリアに基づいて、前記原因を推定する
請求項１又は請求項２に記載の管理システム。

【請求項4】

前記推定部は、前記容器が予め設定された水分摂取エリアに存在する場合、前記原因がユーザの水分摂取であると推定する
請求項１から請求項３までのいずれか１項に記載の管理システム。

【請求項5】

前記周辺状況を示すデータは、前記無線信号を受信した前記受信機の識別子を含み、
前記推定部は、前記受信機の識別子に基づいて、前記容器が存在する前記施設内のエリアを特定する
請求項１から請求項４までのいずれか１項に記載の管理システム。

【請求項6】

前記推定部は、前記周辺状況を示すデータに基づいて、前記容器の周辺に存在する物体を特定し、特定された前記物体に基づいて、前記原因を推定する
請求項１から請求項５までのいずれか１項に記載の管理システム。

【請求項7】

前記周辺状況を示すデータは、前記容器の周辺に存在する物体に取り付けられた発信機から発信された物体の識別子を含み、
前記推定部は、前記物体の識別子に基づいて、前記容器の周辺に存在する物体を特定する
請求項６に記載の管理システム。

【請求項8】

前記情報処理装置は、
前記水分摂取量が所定の目標値を満たすか否かを判定する判定部と、
前記目標値を満たさないと判定した場合、水分を摂取すべき旨のアラートを出力する出力部と
を備える請求項１から請求項７までのいずれか１項に記載の管理システム。

【請求項9】

前記推定部は、前記水量の単位時間当たりの変化量から前記水分摂取量を推定する
請求項１から請求項８までのいずれか１項に記載の管理システム。

【請求項10】

ユーザが利用する施設に設置された複数の受信機から、水量センサ及び無線通信部を備えた容器から受信した無線信号に含まれる前記容器内の水量と、前記無線信号の受信時点における前記容器の周辺状況を示すデータとを取得する取得部と、
前記水量と、前記周辺状況を示すデータとを前記受信時点と対応付けて記憶する記憶部と、
前記周辺状況を示すデータに基づいて前記容器の水量変化の原因を推定し、推定された前記原因と前記水量に基づいて前記ユーザの水分摂取量を推定する推定部と
を備えることを特徴とする情報処理装置。

【請求項11】

ユーザが利用する施設に設置された複数の受信機から、水量センサ及び無線通信部を備えた容器から受信した無線信号に含まれる前記容器内の水量と、前記無線信号の受信時点における前記容器の周辺状況を示すデータとを取得し、
前記水量と、前記周辺状況を示すデータとを前記受信時点と対応付けて記憶部に記憶し、
前記周辺状況を示すデータに基づいて前記容器の水量変化の原因を推定し、推定された前記原因と前記水量に基づいて前記ユーザの水分摂取量を推定する
処理をコンピュータが実行することを特徴とする情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、管理システム、情報処理装置及び情報処理方法に関する。

【背景技術】

【0002】

介護施設、病院等の施設において、施設利用者の健康状態を管理する種々のシステムが提案されている。例えば特許文献１では、施設内に設置したセンサによって被監視者の起床、離床等のイベントを検出すると共に、携帯端末を介して監視者から被監視者の水分摂取量、食事量等の入力を受け付け、看護又は介護の記録を生成する被監視者監視システム等が開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】国際公開第２０１８／００３５１７号

【発明の概要】

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

【0004】

一方で、多くの場合、施設利用者の水分摂取量を管理する場合、施設利用者が水分を摂取するたびに従業者が手動で摂取量を記録している。このため、水分摂取量の管理は従業者にとって大きな負担になっている。

【0005】

特許文献１に係る発明は、従業者（監視者）が携帯端末に手動で水分摂取量を入力するものであり、監視者の負担を軽減しているとは言えない。

【0006】

一つの側面では、ユーザの水分摂取量を好適に管理することができる管理システム等を提供することを目的とする。

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

【0007】

一つの側面に係る管理システムは、水量センサ及び無線通信部を備えた容器と、ユーザが利用する施設に設置された複数の受信機と、該受信機が受信したデータを管理する情報処理装置と、を有する管理システムであって、前記無線通信部は、前記水量センサが検出した前記容器内の水量を含む無線信号を発信し、前記受信機は、前記容器から前記無線信号を受信し、前記情報処理装置は、前記受信機から、前記無線信号に含まれる前記水量と、前記無線信号の受信時点における前記容器の周辺状況を示すデータとを取得する取得部と、前記周辺状況を示すデータに基づいて前記容器の水量変化の原因を推定し、推定された前記原因と前記水量に基づいて前記ユーザの水分摂取量を推定する推定部と、を備えることを特徴とする。

【発明の効果】

【0008】

一つの側面では、ユーザの水分摂取量を好適に管理することができる。

【図面の簡単な説明】

【0009】

【図1】水分摂取量の管理システムの構成例を示す模式図である。

【図2】サーバの構成例を示すブロック図である。

【図3】ユーザＤＢ、エリアＤＢ、受信ログＤＢ、及び摂取量ＤＢのレコードレイアウトの一例を示す説明図である。

【図4】容器の構成例を示すブロック図である。

【図5】飲料提供エリアに関する説明図である。

【図6】水分摂取量の推定処理に関する説明図である。

【図7】管理システムが実行する処理手順の一例を示すフローチャートである。

【図8】実施の形態２に係る管理システムの構成例を示す模式図である。

【図9】実施の形態２に係る容器の構成例を示すブロック図である。

【図10】実施の形態２に係る受信ログＤＢのレコードレイアウトの一例を示す説明図である。

【図11】実施の形態２に係る水分摂取量の推定処理に関する説明図である。

【図12】実施の形態２に係る管理システムが実行する処理手順の一例を示すフローチャートである。

【図13】上述のサーバの動作を示す機能ブロック図である。

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

【0010】

以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
図１は、水分摂取量の管理システムの構成例を示す模式図である。本実施の形態では、介護施設等の施設において、施設を利用するユーザが水分摂取の際に使用する容器２に、容器２内の水量を検出する水量センサと、水量の検出結果を発信する無線通信モジュールとを設けることで、ユーザの水分摂取量を管理する管理システムについて説明する。管理システムは、情報処理装置１、容器２、受信機３、施設端末４、従業者端末５を含む。情報処理装置１、施設端末４及び従業者端末５は、インターネット等のネットワークＮに接続されている。

【0011】

情報処理装置１は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバコンピュータ、パーソナルコンピュータ等である。本実施の形態では情報処理装置１がサーバコンピュータであるものとし、以下では簡潔のためサーバ１と読み替える。サーバ１は、容器２で検出した水量からユーザの水量摂取量を推定し、必要に応じて施設の従業者等にアラートを通知する。

【0012】

容器２は、ユーザが水分を摂取する際に使用するコップ等であり、容器２内の水量を検出する水量センサと、外部に水量の検出結果を発信するための無線通信モジュールとを備える。好適には、水量センサは容器２の内面に設けられた水位センサであり、無線通信モジュールはＢＬＥ（Bluetooth（登録商標） Low Energy）規格の通信モジュールである。容器２は、水量センサで検出した水量と、容器２の識別子である容器ＩＤとを含むビーコン信号（無線信号）を周囲に発信する。

【0013】

なお、本実施の形態では水量センサが水位センサであるものとするが、水量センサは例えば重量センサ、超音波センサなどであってもよく、水量の検出方法は特に限定されない。また、無線通信モジュールの通信規格はＢＬＥに限定されず、その他のBluetooth規格、あるいはＷｉ−ｆｉ（登録商標）、ＲＦＩＤ（Radio Frequency Identification）等の規格であってもよい。

【0014】

受信機３は、容器２から発信されたビーコン信号を受信するレシーバであり、容器２から水量の検出結果及び容器ＩＤを受信する。本実施の形態では複数の受信機３が施設内に分散して配置されており、各受信機３は、ＬＡＮ（Local Area Network）等の不図示の施設内ネットワークを介して、パーソナルコンピュータ等の施設端末４に接続されている。後述するように、受信機３は、施設内でユーザに飲料（水分）を提供可能なエリアとして定められた飲料提供エリアに設置されており、飲料提供エリアに容器２が存在する場合に、容器２からビーコン信号を受信して施設端末４に転送する。

【0015】

サーバ１は、施設端末４から受信機３が受信したビーコン信号のデータを取得し、水量の検出結果をデータベースに記憶する。サーバ１は、データベースに蓄積した水量の検出結果からユーザの水量摂取量を推定し、ユーザが摂取すべき水量として定められた所定の目標値と比較して、目標値未満である場合に、施設端末４、又は施設の各従業者が携帯する従業者端末５にアラートを通知する。

【0016】

図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、及び補助記憶部１４を備える。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰを読み出して実行することにより、種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための通信モジュールであり、外部と情報の送受信を行う。

【0017】

補助記憶部１４は、大容量メモリ、ハードディスク等の不揮発性記憶領域であり、制御部１１が処理を実行するために必要なプログラムＰ、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ１４１、エリアＤＢ１４２、受信ログＤＢ１４３、摂取量ＤＢ１４４を記憶している。ユーザＤＢ１４１は、水分摂取の管理対象である各ユーザの情報を格納するデータベースである。エリアＤＢ１４２は、施設内の各エリアの情報を格納するデータベースである。受信ログＤＢ１４３は、受信機３が受信したビーコン信号のログデータを格納するデータベースである。摂取量ＤＢ１４４は、容器２で検出した水量から推定されるユーザの水分摂取量を格納するデータベースである。

【0018】

なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであっても良く、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。

【0019】

また、本実施の形態においてサーバ１は上記の構成に限られず、例えば操作入力を受け付ける入力部、画像を表示する表示部等を含んでもよい。また、サーバ１は、ＣＤ（Compact Disk）−ＲＯＭ、ＤＶＤ（Digital Versatile Disc）−ＲＯＭ等の可搬型記憶媒体１ａを読み取る読取部を備え、可搬型記憶媒体１ａからプログラムＰを読み取って実行するようにしても良い。あるいはサーバ１は、半導体メモリ１ｂからプログラムＰを読み込んでも良い。

【0020】

図３は、ユーザＤＢ１４１、エリアＤＢ１４２、受信ログＤＢ１４３、及び摂取量ＤＢ１４４のレコードレイアウトの一例を示す説明図である。
ユーザＤＢ１４１は、ユーザＩＤ列、容器ＩＤ列、飲料提供エリア列を含む。ユーザＩＤは、各ユーザの識別子であるユーザＩＤを記憶している。容器ＩＤ列、及び飲料提供エリアはそれぞれ、ユーザＩＤと対応付けて、ユーザが使用する容器２の識別子である容器ＩＤ、及びユーザに水分摂取が許可される施設内の飲料提供エリアを記憶している。

【0021】

なお、以下の説明では便宜上、施設内で飲料を提供可能なエリアを「飲料提供エリア」と記し、飲料提供エリアの内、ユーザに水分摂取が許可されるエリアとしてユーザ別に設定された飲料提供エリアを「水分摂取エリア」と記して区別する。図３のＤＢ１４１では、値が「○」である飲料提供エリアが、各ユーザの水分摂取エリアに相当する。

【0022】

エリアＤＢ１４２は、受信機ＩＤ列、エリア列を含む。受信機ＩＤ列は、各受信機３の識別子である受信機ＩＤを記憶している。エリア列は、受信機ＩＤと対応付けて、受信機３が設置されている施設内のエリアを記憶している。

【0023】

受信ログＤＢ１４３は、時刻列、容器列、受信機列、水量列を含む。時刻列は、受信機３が容器２からビーコン信号を受信した時刻を記憶している。容器列、受信機列、及び水量列はそれぞれ、時刻と対応付けて、ビーコン信号を発信した容器２の容器ＩＤ、ビーコン信号を受信した受信機３の受信機ＩＤ、及び容器２が検出した水量を記憶している。

【0024】

摂取量ＤＢ１４４は、時間帯列、ユーザ列、水分摂取量列、修正済み摂取量列を含む。時間帯列は、一日の各時間帯を記憶している。ユーザ列、水分摂取量列、及び修正済み摂取量列はそれぞれ、時間帯と対応付けて、ユーザＩＤ、ユーザの水分摂取量、及び従業者が修正した水分摂取量を記憶している。

【0025】

図４は、容器２の構成例を示すブロック図である。容器２は、制御部２１、記憶部２２、発信部２３、水量センサ２４、バッテリ２５を備える。
制御部２１は、ＭＰＵ等の演算処理モジュールであり、発信部２３、水量センサ２４等の各部の動作を制御する。記憶部２２はＲＯＭ等の記憶領域であり、容器２の識別子である容器ＩＤを記憶している。発信部２３は、ビーコン信号を発信する無線通信モジュールであり、上述の如く、ＢＬＥ等の通信規格でビーコン信号を発信する。水量センサ２４は、容器２内の水量を検出するセンサであり、上述の如く、容器２の内面に設けられた水位センサである。バッテリ２５は、例えばボタン電池であり、容器２の各部に電力を供給する。

【0026】

なお、バッテリ２５を充電池とし、容器２を充電式のデバイスとしてもよい。また、パッシブタグのように、容器２を電源不要のデバイスとして構成してもよい。

【0027】

図５は、飲料提供エリアに関する説明図である。図５では、受信機３が設置された施設の見取り図を概念的に図示してある。
本実施の形態では、水分摂取の管理対象となるユーザに飲料（水分）を提供可能な飲料提供エリアを、施設側の運用によって予め制限する。例えば図５にハッチングで示すように、「食堂」、「居室」などでは飲料を提供する一方で、「浴室」、「トイレ」などでは飲料を提供しないものとする。

【0028】

施設内の各飲料提供エリアには、容器２からビーコン信号を受信するための受信機３が設置されている。なお、受信機３は飲料提供エリアだけでなく、飲料を提供しないその他のエリアにも設置してもよい。また、一の飲料提供エリアに複数の受信機３が設置されていてもよい。また、施設内のエリアは、部屋ごとに設定されてもよいし、１つの部屋に複数設定されてもよいし、部屋以外の空間（廊下、冷蔵庫周辺など）に設定されてもよい。

【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】

１ サーバ（情報処理装置）
１１ 制御部
１２ 主記憶部
１３ 通信部
１４ 補助記憶部
Ｐ プログラム
２ 容器
２１ 制御部
２２ 記憶部
２３ 発信部
２３ａ 無線通信部
２４ 水量センサ
２５ バッテリ
３ 受信機
４ 施設端末
５ 従業者端末

【要約】      （修正有）

【課題】ユーザの水分摂取量を好適に管理することができる管理システム等を提供する。
【解決手段】管理システムは、水量センサ及び無線通信部を備えた容器２と、ユーザが利用する施設に設置された複数の受信機３と、該受信機３が受信したデータを管理する情報処理装置１と、を有する。無線通信部は、水量センサが検出した容器内の水量を含む無線信号を発信する。受信機３は、容器２から無線信号を受信する。情報処理装置１は、受信機３から、無線信号に含まれる水量と、無線信号の受信時点における容器の周辺状況を示すデータとを取得する取得部と、周辺状況を示すデータに基づいて容器２の水量変化の原因を推定し、推定された原因と水量に基づいてユーザの水分摂取量を推定する推定部と、を備える。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】