JP7396243B2 - 情報処理装置、および情報処理システム - Google Patents

Description

本発明は、ユーザを補助する技術に関する。

日用品をはじめとする物品の定期的な購入をサポートするための技術がある。例えば、特許文献１には、ビーコン装置に設けられた注文ボタンが押下されたことをトリガとして、当該ビーコン装置に関連付いた商品を注文する処理を実行するシステムが開示されている。
特許文献１に記載されたビーコン装置を、冷蔵庫や洗面室といった、商品を貯蔵する場所の近傍に設置することで、商品の発注を簡便な操作で行わせることが可能になる。

特開２０１６－２２４６５０号公報

一方、従来技術においては、ユーザが自身で商品の在庫を管理し、発注を行わなければならないという点において改善の余地があった。在庫の管理を自動化するためには、対象の商品がユーザによってどの程度消費されたかを知る必要がある。

本発明は、ユーザによるアルコール飲料の消費量を推定することを目的とする。

本開示の第一の様態は、アルコールセンサを用いて、帰宅したユーザの呼気に含まれるアルコールを検出することと、前記アルコールの検出結果に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定することと、を実行する制御部を有する、情報処理装置である。

また、本開示の第二の様態は、ユーザの自宅に設置され前記ユーザの呼気に含まれるアルコールを検出するアルコールセンサと、制御部と、を有する情報処理システムである。具体的には、前記制御部は、前記アルコールセンサを用いて、帰宅したユーザの呼気に含まれるアルコールを検出することと、前記アルコールの検出結果に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定することと、を実行する。

また、本開示の第三の様態は、帰宅したユーザの呼気に含まれるアルコールを検出するステップと、前記アルコールの検出結果に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定するステップと、を含む、情報処理方法である。

また、他の態様として、上記の情報処理方法を実行するためのプログラム、または、上記のプログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本発明によれば、ユーザによるアルコール飲料の消費量を推定することができる。

情報処理システムの概要を説明する図。 第一の実施形態に係る情報処理システムの構成要素を詳細に示した図。 屋内におけるセンサの配置位置を説明する図。 記憶部に記憶される濃度データを説明する図。 空気中におけるアルコール濃度を説明する図。 第一の実施形態における推定データを説明する図。 記憶部に記憶される在庫データを説明する図。 制御部が有するモジュール間におけるデータの流れを示す図。 第一の実施形態において制御部が実行する処理のフローチャート。 第二の実施形態における推定データを説明する図。

ユーザによる所定の操作に基づいて、例えば、日用品やアルコール飲料などの予め定められた商品の購入を申し込むシステムが知られている。しかし、このようなシステムにおいては、ユーザ自身が商品の在庫を管理し、発注を行わなければならない。

本実施形態に係る情報処理装置は、この課題を解決するため、ユーザをセンシングした結果に基づいて、当該ユーザによるアルコール飲料の消費量を推定する。
具体的には、アルコールセンサを用いて、帰宅したユーザの呼気に含まれるアルコールを検出することと、前記アルコールの検出結果に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定することと、を実行する制御部を有することを特徴とする。

ユーザの呼気に含まれるアルコールの有無は、例えば、空気中のアルコールを検出するセンサ（アルコールセンサ）によって判定することができる。アルコールセンサは、例えば、帰宅した直後のユーザの呼気に含まれるアルコールを検出可能な位置に設置されることが好ましい。

制御部は、帰宅したユーザの呼気に含まれるアルコールに基づいて、帰宅後における当該ユーザによるアルコール飲料の消費量を推定する。例えば、帰宅時において、ユーザの呼気から十分な量のアルコールが検出された場合、当日中はこれ以上の飲酒をしないことが推定される。反対に、帰宅後に飲酒をする習慣があるユーザが、帰宅までにアルコールを摂取していなかった場合、自宅において飲酒をすることが推定される。このように、帰宅時における呼気中のアルコールの有無に基づいて、帰宅後におけるユーザの飲酒量（アルコール飲料の消費量）を推定することができる。

また、前記制御部は、前記ユーザの自宅の玄関に設置された前記アルコールセンサを用いて前記検出を行うことを特徴としてもよい。
玄関に設置されたセンサを利用することで、帰宅したユーザの呼気を捉えることが可能になる。

また、前記制御部は、前記ユーザの呼気からアルコールを検出しなかった場合に、帰宅後の前記ユーザによって所定量のアルコール飲料が消費されるものと推定することを特徴としてもよい。
また、前記制御部は、前記ユーザの呼気からアルコールを検出した場合と、しなかった場合とで、帰宅後の前記ユーザによってそれぞれ異なる量のアルコール飲料が消費されるものと推定することを特徴としてもよい。
アルコール飲料の推定消費量は、ユーザの飲酒習慣に基づいて予め決定することができる。

また、前記制御部は、前記アルコールセンサを用いて、前記ユーザの呼気に含まれるアルコール濃度を取得することを特徴としてもよい。
呼気中のアルコール濃度は、直接取得してもよいし、間接的に取得してもよい。例えば、ユーザの呼気が直接センサに当たらない場合、センサ周辺の空気中のアルコール濃度に基づいて、呼気に含まれるアルコールの濃度を算出してもよい。呼気中のアルコール濃度を用いることで、帰宅後においてユーザがどの程度の飲酒を行うかを推定することができる。

また、前記制御部は、前記ユーザの呼気からアルコールを検出した場合に、帰宅後の前記ユーザによって、前記取得したアルコール濃度に応じた量のアルコール飲料が消費されると推定することを特徴としてもよい。
例えば、帰宅時における呼気中のアルコール濃度が低いほど、自宅での飲酒量が多くなると推定することができる。

また、情報処理装置は、前記取得したアルコール濃度に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定するためのモデルを記憶する記憶部をさらに有することを特徴としてもよい。
取得したアルコール濃度と、帰宅後のユーザによる飲酒量とを関連付けたモデルを利用することで、推定の精度を向上させることができる。当該モデルは、ユーザの飲酒習慣に基づいて生成ないし更新されることが好ましい。

また、前記制御部は、前記ユーザの帰宅後に消費されたアルコール飲料の消費量の実績値をさらに取得することを特徴としてもよい。
また、前記ユーザの帰宅時に取得したアルコール濃度と、前記実績値と、に基づいて前記モデルを更新することを特徴としてもよい。

ユーザによる飲酒量の実績値をフィードバックすることで、より正確な推定が可能になる。実績値は、ユーザ本人に入力させてもよいし、ユーザをセンシングした結果に基づいて、装置が生成してもよい。

また、前記制御部は、前記ユーザの帰宅が予想される所定の時間帯に前記検出を行い、前記所定の時間帯における前記検出の結果に基づいて、前記推定を行うことを特徴としてもよい。
ユーザの帰宅が予想される時間帯においてデータの取得を行うことで、ユーザが帰宅したこと自体を検知せずとも、推定を行うことが可能になる。

以下、図面に基づいて、本開示の実施の形態を説明する。以下の実施形態の構成は例示であり、本開示は実施形態の構成に限定されない。

（第一の実施形態）
第一の実施形態に係る情報処理システムの概要について、図１を参照しながら説明する。本実施形態に係る情報処理システムは、ユーザの自宅に設置されたサーバ装置１００と、ユーザをセンシングするためのセンサ２００と、アルコール飲料の発注を受け付けるＥＣサーバ３００と、を含んで構成される。

センサ２００は、空気中におけるアルコールの濃度を検出するセンサである。センサ２００は、ユーザの自宅の玄関に設置され、帰宅したユーザの呼気に含まれるアルコールを検出することができる。

サーバ装置１００は、センサ２００を介して取得したデータに基づいて、ユーザが帰宅後においてアルコール飲料を消費するか（すなわち、飲酒をするか）否か、および、その消費量を推定する処理を実行する。また、推定の結果に基づいて、自宅におけるアルコー
ル飲料の在庫量を更新する処理と、必要に応じてアルコール飲料の発注を行う処理と、を実行する。
ＥＣサーバ３００は、ネットワークを介して商品（アルコール飲料）の注文を受け付ける装置である。ＥＣサーバ３００は、通信販売事業を運営する事業者によって管理される。

なお、サーバ装置１００はユーザの自宅内に設置されていてもよいが、遠隔地に設置されていてもよい。また、一台のサーバ装置１００が、複数のユーザを管轄してもよい。

図２は、本実施形態に係る情報処理システムの構成要素をより詳細に示した図である。ここではまず、センサ２００について説明する。
センサ２００は、空気中におけるアルコールの濃度を検出するアルコールセンサである。センサ２００は、ユーザの呼気に含まれるアルコールを検出することができれば、その種類および設置場所は問わない。図３は、ユーザの自宅玄関を表す平面図である。図示したように、センサ２００は、玄関の近傍に設置することができる。
なお、本実施形態では、センサ２００を玄関の近傍に設置したが、センサ２００は他の場所に設置されていてもよい。例えば、玄関ドアの外側に設置されていてもよいし、ユーザが自律走行車両に乗車して帰宅する場合、車両の内部に設けられていてもよい。

サーバ装置１００は、センサ２００から取得したデータ（以下、センサデータ）に基づいて、帰宅後における、ユーザによるアルコール飲料の消費量を推定する。さらに、サーバ装置１００は、ユーザの自宅におけるアルコール飲料の在庫量を管理し、必要に応じてアルコール飲料の発注を行う。

サーバ装置１００は、汎用のコンピュータにより構成することができる。すなわち、サーバ装置１００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを主記憶装置の作業領域にロードして実行し、プログラムの実行を通じて各構成部等が制御されることによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

制御部１０１は、サーバ装置１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部１０１は、データ取得部１０１１と、消費量推定部１０１２と、在庫管理部１０１３の３つの機能モジュールを有して構成される。各機能モジュールは、記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

データ取得部１０１１は、センサ２００からセンサデータを取得する。取得するセンサデータは、センサ２００の周辺（すなわち、帰宅直後のユーザの周辺）における空気中のアルコール濃度を示す。データ取得部１０１１が取得したセンサデータは、濃度データとして、後述する記憶部１０２に順次蓄積される。濃度データは、空気中のアルコール濃度の推移を示すデータである。

消費量推定部１０１２は、記憶された濃度データに基づいて、ユーザによる、帰宅後におけるアルコール飲料の消費量を推定する。
具体的には、ユーザが外出中（帰宅するよりも前）に飲酒をしたか否かを判定し、当該
判定の結果と、後述する推定データに基づいて、帰宅後における飲酒量（アルコール飲料の消費量）を推定する。推定した消費量は、在庫管理部１０１３へ送信される。

在庫管理部１０１３は、ユーザの自宅にあるアルコール飲料の在庫の量を表すデータ（在庫データ）を管理し、消費量推定部１０１２が推定したアルコール飲料の消費量に基づいて、当該在庫データを更新する。また、在庫管理部１０１３は、アルコール飲料の在庫量が所定値を下回った場合に、ＥＣサーバ３００に対して当該アルコール飲料の発注を行う。

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。

記憶部１０２は、前述した濃度データを記憶する。図４は、濃度データの例である。濃度データには、センサ２００がセンサデータを取得した日付と時刻、および、センシングによって得られた、空気中のアルコール濃度が含まれる。

また、記憶部１０２は、ユーザによる、帰宅後のアルコール飲料の消費量を推定するためのデータ（推定データ）を記憶する。第一の実施形態における推定データは、アルコールの検知有無と、ユーザが帰宅後に消費すると想定されるアルコール飲料の量とを関連付けたデータである。なお、本明細書では、ユーザが帰宅してから就寝するまでの期間を対象として、当該ユーザによるアルコール飲料の消費量を推定する。

ここで、図５を参照して、帰宅後のアルコール飲料の消費量を推定する方法について説明する。図５は、センサ２００が検出する、空気中のアルコール濃度の経時変化を示した図である。
例えば、ユーザが外出中において飲酒を行っていない場合、帰宅の前後において、センサ２００はアルコールを検知しない。すなわち、空気中のアルコール濃度の経時変化は図５（Ａ）に示したようになる。
一方、ユーザが外出中において飲酒を行った場合、帰宅の前後において、センサ２００がアルコールを検知する。この場合、空気中のアルコール濃度の経時変化は図５（Ｂ）に示したようになる。
ユーザの帰宅が予想される時間帯において、センサ２００がアルコールを検知した場合、制御部１０１は、ユーザが帰宅前に飲酒したと判定することができる。

図６（Ａ）は、推定データを説明する図である。本例では、ユーザの帰宅時にアルコールを検知しなかった場合、帰宅後において缶ビール（３５０ｍｌ）を１本消費する旨が示されている。また、ユーザの帰宅時にアルコールを検知した場合、帰宅後において飲酒を行わない旨が示されている。なお、本例では、アルコール飲料は一種類となっているが、図６（Ｂ）に示したように、ユーザが消費するアルコール飲料は複数種類であってもよい。

ユーザに対応する推定データは、事前に生成され、記憶部１０２に記憶される。推定データは、例示したようなテーブル形式であってもよいし、他の形式のデータであってもよい。また、推定データは、ユーザの自己申告に基づいて生成されてもよいし、ユーザをセンシングした結果に基づいて生成されてもよい。

また、記憶部１０２は、ユーザの自宅にあるアルコール飲料の在庫を管理するためのデータ（在庫データ）を記憶する。図７は、在庫データの例である。在庫データは、管理下
にあるアルコール飲料の在庫量と、日付および時刻を関連付けたデータである。

なお、アルコール飲料の在庫量は、種類別に表されてもよい。例えば、ユーザが消費するアルコール飲料が複数種類ある場合、種類ごとの在庫量を持っていてもよい。図７（Ａ）および図７（Ｂ）は、アルコール飲料の種類が一種類である場合の在庫データの例である。また、図７（Ｃ）は、アルコール飲料の種類が複数である場合の在庫データの例である。在庫データは、アルコール飲料が消費された場合、および、購入された場合に更新される。

通信部１０３は、サーバ装置１００をネットワークに接続するための通信インタフェースである。通信部１０３は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。

なお、図２に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

次に、制御部１０１が行う処理について、モジュール間で送受信されるデータを示した図である図８を参照しながら説明する。

データ取得部１０１１は、玄関に設置されたセンサ２００からセンサデータを受信し、当該センサデータを、濃度データとして記憶部１０２に蓄積する。濃度データは、前述したように、空気中のアルコール濃度の経時的な変化を示すデータである。

なお、濃度データには、センサ２００が検出した空気中のアルコール濃度をそのまま記録してもよいが、取得した値を補正したうえで記録してもよい。例えば、センサ２００が、ユーザの呼気を直接センシングするものでない場合、センサ周辺における空気中のアルコール濃度に基づいて、ユーザの呼気中におけるアルコール濃度を算出し、算出した値を記憶させてもよい。

消費量推定部１０１２は、取得した濃度データに基づいて、帰宅したユーザによるアルコール飲料の消費量を推定する。具体的には、「アルコールを検知した」というパターンと、「アルコールを検知していない」というパターンのいずれに当てはまるかを判定し、当該パターンに関連付いたアルコール飲料の摂取量を取得する。
例えば、図６（Ａ）の例において、センサ２００がアルコールを検知しなかった場合、ユーザが帰宅後に缶ビール（３５０ｍｌ）を一本飲むと推定することができる。また、図４（Ａ）の例において、センサ２００がアルコールを検知した場合、ユーザは帰宅後に飲酒しないと推定することができる。
また、図６（Ｂ）の例において、センサ２００がアルコールを検知しなかった場合、ユーザが帰宅後に缶ビール（３５０ｍｌ）を一本、および、日本酒を一合飲むと推定することができる。

判定結果は、在庫管理部１０１３へ送信される。
在庫として管理しているアルコール飲料の種類が一種類である場合、判定結果として、当該アルコール飲料の消費量（例えば、『３５０ｍｌ缶×１本』など）が送信される。また、在庫として管理しているアルコール飲料の種類が複数種類である場合、種類および消費量（例えば、『缶ビール（３５０ｍｌ缶）×１本』が送信される。

在庫管理部１０１３は、消費量推定部１０１２から送信された情報に基づいて、在庫データを更新する。具体的には、現在の在庫量から消費量を減算し、新たなレコードを追加
する。なお、在庫として管理しているアルコール飲料の種類が複数ある場合、該当する種類の在庫量を減算する。
さらに、在庫管理部１０１３は、アルコール飲料の在庫量が所定の基準を下回った場合に、これを発注する処理を実行する。例えば、所定の種類および所定の量のアルコール飲料を注文するためのデータ（発注データ）を生成し、所定のＥＣサーバ３００に送信する。

図９は、サーバ装置１００が行う処理のフローチャートである。図示した処理は、サーバ装置１００が起動中において周期的に実行される。

まず、ステップＳ１１で、データ取得部１０１１が、ユーザに対応する帰宅予想時間が到来したか否かを判定する。ユーザに対応する帰宅予想時間は、事前に設定される。例えば、ユーザが毎日１８時から２１時の間に帰宅する旨が設定されている場合、１８時を過ぎると肯定判定となる。帰宅予想時間が到来していない場合、所定の時間だけ待機したうえで同じ処理を繰り返す。

次に、ステップＳ１２で、データ取得部１０１１が、センサ２００からセンサデータを取得し、取得したセンサデータに基づいて、濃度データの新規レコードを生成し、追加する。

次に、ステップＳ１３で、帰宅予想時間が経過したか否かを判定する。前述した例の場合、２１時を過ぎた場合に肯定判定となる。帰宅予想時間が経過していない場合、処理はステップＳ１１に戻り、所定の周期でセンサデータの取得を繰り返す。帰宅予想時間が経過した場合、処理はステップＳ１４へ遷移する。

ステップＳ１４では、消費量推定部１０１２が、帰宅したユーザによるアルコール飲料の消費量を推定する。本ステップでは、記憶部１０２に記憶された濃度データおよび推定データを用いて、前述した方法によって、消費されると推定されるアルコール飲料の種類および量を決定する。すなわち、（１）帰宅したユーザの呼気からアルコールを検知した場合、当該ユーザは帰宅後において飲酒を行わないものと推定し、（２）帰宅したユーザの呼気からアルコールを検知しなかった場合、当該ユーザが帰宅後において所定量の飲酒を行うものと推定する。
判定結果は、在庫管理部１０１３へ送信される。

ステップＳ１５では、在庫管理部１０１３が、消費量推定部１０１２が行った推定の結果に基づいて在庫データを更新する。

ステップＳ１６では、在庫管理部１０１３が、管理下にあるアルコール飲料のうち、在庫量が所定値を下回ったものがあるか否かを判定する。ここで、在庫量が所定値を下回ったものがある場合、該当する飲料を発注するためのデータ（発注データ）を生成し、ＥＣサーバ３００へ送信する（ステップＳ１７）。在庫量が所定値を下回っていない場合、処理はステップＳ１１に戻る。

以上説明したように、第一の実施形態に係るシステムでは、センサによって、帰宅したユーザの呼気中のアルコールを検出し、検出結果に基づいて、ユーザが帰宅後に飲酒を行うか否かを推定する。また、推定結果に基づいてアルコール飲料の在庫量を更新し、追加発注を自律的に行う。かかる構成によると、ユーザが自身でアルコール飲料の在庫を管理し、発注タイミングを決定する必要がなくなるため、ユーザビリティを向上させることができる。

なお、第一の実施形態では、アルコール飲料の在庫量が所定値を下回った場合に、自動的にアルコール飲料の発注を行ったが、発注を行う代わりに、ユーザに対するレコメンドを行うようにしてもよい。この場合、ユーザの応答を待って発注を実行してもよい。

（第二の実施形態）
第一の実施形態では、ユーザの呼気中からアルコールが検出されたか否かに基づいて、アルコール飲料の消費量を推定した。
一方で、帰宅後における飲酒量の大小は、帰宅前における飲酒量に影響を受ける場合がある。例えば、外で多く飲酒した日は自宅では飲酒を行わず、反対に、外での飲酒量が少ない場合、帰宅後に飲み直す場合がある。

第二の実施形態は、これに対応するため、帰宅時に検出したアルコールの濃度に基づいて、帰宅後にユーザが消費するであろうアルコール飲料の消費量を推定する実施形態である。

第二の実施形態は、推定データとして、検出されたアルコールの濃度と、推定される消費量とを関連付けたデータを記憶させ、ステップＳ１４の処理において利用するという点において、第一の実施形態と相違する。

また、第二の実施形態では、制御部１０１が、ユーザの帰宅が予想される時間帯においてセンサデータを取得し、当該時間帯において取得した、最も高いアルコール濃度を示す値を用いて、推定データとの照合を行う。例えば、図５（Ｂ）の例の場合、符号５０１で示したタイミングで取得された値を利用して、推定データとの照合を行う。

図１０（Ａ）は、第二の実施形態における推定データの例である。本例の場合、例えば、検出されたアルコールの濃度の最高値が０．１ｍｇ／Ｌであった場合、ユーザが帰宅後に缶ビールを２本消費すると推定される。

なお、図１０（Ａ）の例では、アルコールの濃度として離散値を利用したが、推定データは、図１０（Ｂ）に示したように、検出されたアルコール濃度と、アルコール飲料の消費量との相関を連続値によって表したものであってもよい。
また、図１０（Ａ）の例では、アルコール飲料は一種類となっているが、ユーザが消費するアルコール飲料は複数種類であってもよい。

このような推定データは、ユーザが自宅で行った飲酒の実績に基づいて生成することが好ましい。例えば、ユーザの帰宅時に取得したアルコールの濃度と、その後に行った飲酒の実績（例えば、アルコール飲料の種類や飲酒量）とを取得することで、推定データを生成することができる。飲酒の実績は、ユーザに入力させてもよいし、センシングによって取得してもよい。さらに、当該実績を継続して（例えば、数日間にわたって）取得し、フィードバックすることで、生成した推定データを継続して更新してもよい。

さらに、推定データは、機械学習モデルであってもよい。例えば、呼気中におけるアルコール濃度を入力データ、当日中におけるアルコール飲料の消費量を教師データとして機械学習を実行することで、濃度データに基づいてアルコール飲料の消費量を推定する機械学習モデルを得ることができる。このように、ユーザごとの飲酒習慣を学習させて得られた機械学習モデルを利用することで、帰宅後におけるアルコール飲料の消費量を精度良く推定することができる。

第二の実施形態によると、ユーザが帰宅した後におけるアルコール飲料の消費量をより精度よく推定することができる。

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、過去の飲酒の実績に基づいて推定データを生成する例を挙げたが、推定データは、過去の実績以外のデータを用いて生成されてもよい。例えば、空気中のアルコール濃度に基づいて、ユーザの血中アルコール濃度を推定し、「血中アルコール濃度が所定値に達するまで飲酒を行う」という前提のもと、アルコール飲料の消費量を推定してもよい。

また、実施形態の説明では、センサ２００として、空気中のアルコールを検出するセンサを用いたが、においの原因となる複数種類の分子を検出可能なセンサ（においセンサ）を用いてもよい。なお、この場合、アルコールに対応するにおいのレベルを抽出するためのユニットないしロジックを併用することが好ましい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１００・・・サーバ装置
１０１・・・制御部
１０２・・・記憶部
１０３・・・通信部
２００・・・センサ
３００・・・ＥＣサーバ

Claims (19)

1. アルコールセンサを用いて、帰宅したユーザの呼気に含まれるアルコールを検出することと、
   前記アルコールの検出結果に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定することと、
   を実行する制御部を有する、情報処理装置。
2. 前記制御部は、前記ユーザの自宅の玄関に設置された前記アルコールセンサを用いて前記検出を行う、
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記ユーザの呼気からアルコールを検出しなかった場合に、帰宅後の前記ユーザによって所定量のアルコール飲料が消費されるものと推定する、
   請求項１または２に記載の情報処理装置。
4. 前記制御部は、前記ユーザの呼気からアルコールを検出した場合と、しなかった場合とで、帰宅後の前記ユーザによってそれぞれ異なる量のアルコール飲料が消費されるものと推定する、
   請求項１または２に記載の情報処理装置。
5. 前記制御部は、前記アルコールセンサを用いて、前記ユーザの呼気に含まれるアルコール濃度を取得する、
   請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記制御部は、前記ユーザの呼気からアルコールを検出した場合に、帰宅後の前記ユーザによって、前記取得したアルコール濃度に応じた量のアルコール飲料が消費されると推定する、
   請求項５に記載の情報処理装置。
7. 前記取得したアルコール濃度に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定するためのモデルを記憶する記憶部をさらに有する、
   請求項６に記載の情報処理装置。
8. 前記制御部は、前記ユーザの帰宅後に消費されたアルコール飲料の消費量の実績値をさらに取得する、
   請求項７に記載の情報処理装置。
9. 前記ユーザの帰宅時に取得したアルコール濃度と、前記実績値と、に基づいて前記モデルを更新する、
   請求項８に記載の情報処理装置。
10. 前記制御部は、前記ユーザの帰宅が予想される所定の時間帯に前記検出を行い、
    前記所定の時間帯における前記検出の結果に基づいて、前記推定を行う、
    請求項１から９のいずれか１項に記載の情報処理装置。
11. ユーザの自宅に設置され前記ユーザの呼気に含まれるアルコールを検出するアルコールセンサと、制御部と、を有し、
    前記制御部は、
    前記アルコールセンサを用いて、帰宅したユーザの呼気に含まれるアルコールを検出することと、
    前記アルコールの検出結果に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定することと、
    を実行する、情報処理システム。
12. 前記アルコールセンサは、前記ユーザの自宅の玄関に設置されたセンサである、
    請求項１１に記載の情報処理システム。
13. 前記制御部は、前記ユーザの呼気からアルコールを検出しなかった場合に、帰宅後の前記ユーザによって所定量のアルコール飲料が消費されるものと推定する、
    請求項１１または１２に記載の情報処理システム。
14. 前記制御部は、前記ユーザの呼気からアルコールを検出した場合と、しなかった場合とで、帰宅後の前記ユーザによってそれぞれ異なる量のアルコール飲料が消費されるものと推定する、
    請求項１１または１２に記載の情報処理システム。
15. 前記制御部は、前記アルコールセンサを用いて、前記ユーザの呼気に含まれるアルコール濃度を取得する、
    請求項１１から１４のいずれか１項に記載の情報処理システム。
16. 前記制御部は、前記ユーザの呼気からアルコールを検出した場合に、帰宅後の前記ユーザによって、前記取得したアルコール濃度に応じた量のアルコール飲料が消費されると推定する、
    請求項１５に記載の情報処理システム。
17. 前記取得したアルコール濃度に基づいて、帰宅後の前記ユーザによるアルコール飲料の消費量を推定するためのモデルを記憶する記憶部をさらに有する、
    請求項１６に記載の情報処理システム。
18. 前記制御部は、前記ユーザの帰宅後に消費されたアルコール飲料の消費量の実績値をさらに取得する、
    請求項１７に記載の情報処理システム。
19. 前記ユーザの帰宅時に取得したアルコール濃度と、前記実績値と、に基づいて前記モデルを更新する、
    請求項１８に記載の情報処理システム。

Images