JP7400681B2

JP7400681B2 - 情報処理装置、情報処理方法、およびプログラム

Info

Publication number: JP7400681B2
Application number: JP2020166991A
Authority: JP
Inventors: 豊和中嶋; 貴之羽鳥; 修一澤田; 大輝久保; 智基石川; 尚哉岡
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2020-10-01
Filing date: 2020-10-01
Publication date: 2023-12-19
Anticipated expiration: 2040-10-01
Also published as: US20220108371A1; JP2022059329A; CN114282959A

Description

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

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

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

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

本発明は、ユーザによる嗜好品の摂取量を推定することを目的とする。

本開示の第一の様態は、
ユーザをセンシングするにおいセンサの出力を取得することと、前記においセンサの出力に基づいて、前記ユーザによる、所定の嗜好品の摂取量を推定することと、を実行する制御部を有する、情報処理装置である。

また、本開示の第二の様態は、ユーザをセンシングするにおいセンサの出力を取得する取得ステップと、前記においセンサの出力に基づいて、前記ユーザによる、所定の嗜好品の摂取量を推定する推定ステップと、を含む、情報処理方法である。

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

本発明によれば、ユーザによる嗜好品の摂取量を推定することができる。

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

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

本実施形態に係る情報処理装置は、嗜好品の発注タイミングを決定するために、所定の嗜好品の摂取量（すなわち、消費量）を推定する装置である。
具体的には、ユーザをセンシングするにおいセンサの出力を取得することと、前記においセンサの出力に基づいて、前記ユーザによる、所定の嗜好品の摂取量を推定することと、を実行する制御部を有することを特徴とする。

所定の嗜好品とは、摂取時に特有のにおいを発するものであって、典型的には、アルコール飲料や煙草などである。においセンサがユーザをセンシングした結果を取得することで、例えば、ユーザが、アルコール飲料や煙草を摂取していることを推定することができる。

においセンサは、においの強度を識別することができれば、その検出対象は特定のものに限られない。例えば、所定のにおい分子を検出した結果に基づいて、においのレベルを判定するものであってもよいし、アルコールガスを検出した結果に基づいて、アルコール臭のレベルを判定するものであってもよい。

さらに、制御部は、においセンサの出力に基づいて、ユーザによる嗜好品の摂取量を推定する。例えば、アルコール飲料は、摂取を開始すると徐々に呼気中のアルコール濃度が上昇し、これが継続する。また、煙草は、喫煙開始とともに、周辺におけるにおいレベルが急上昇し、喫煙終了とともに徐々に低下し始める。よって、においセンサの出力を監視することで、ユーザによるこれらの嗜好品の摂取量を推定することができる。

また、前記制御部は、前記においセンサが検知した、においの濃度の経時変化に基づいて前記推定を行うことを特徴としてもよい。
例えば、対象が煙草であって、においの濃度が周期的に上昇している場合、連続して喫煙していることが推定できる。

また、情報処理装置は、前記においの濃度の経時変化に基づいて前記摂取量を決定するためのモデルを記憶する記憶部をさらに有することを特徴としてもよい。
においの濃度の経時変化を定義するモデルを記憶させ、センサによって取得されたデータと照合することで、所定の嗜好品が摂取されたことを判定することができる。当該モデルは、例えば、機械学習モデルであってもよい。また、におい濃度の経時変化が、嗜好品の種類によって異なる特性を有する場合、情報処理装置は、複数のモデルを記憶してもよい。

また、前記においセンサは、空気中のアルコール濃度を検出可能なセンサであって、前記制御部は、検出したアルコール濃度の経時変化に基づいて、前記ユーザによる酒類の摂取量を推定することを特徴としてもよい。
空気中のアルコール濃度の経時変化を利用することで、ユーザによる飲酒量を推定することができる。この場合、においセンサは、ユーザが日常的に飲酒を行う場所（例えば、ダイニング等）に設置されていることが好ましい。

また、前記制御部は、前記ユーザが摂取したアルコール飲料の度数に関する情報をさらに取得し、前記アルコール飲料の度数にさらに基づいて、前記摂取量を推定することを特徴としてもよい。
ユーザが摂取したアルコール飲料の度数が高いほど、当該ユーザの周辺におけるアルコール濃度の上昇が早くなる。よって、ユーザが摂取しているアルコール飲料の度数をさらに用いることで、摂取量の推定をより正確に行うことが可能になる。

また、前記においセンサは、前記ユーザの自宅内に設置されたセンサであることを特徴としてもよい。
かかる構成によると、ユーザの自宅内におけるアルコール飲料の摂取量（消費量）を推定することができる。

また、前記制御部は、前記自宅の換気状況に関する情報をさらに取得し、当該情報にさらに基づいて前記推定を行うことを特徴としてもよい。
居室において換気が行われていた場合、空気中のアルコール濃度が通常よりも早く低下することが予想される。従って、換気状況をさらに用いて推定を行うことで、その精度を向上させることができる。

また、情報処理装置は、前記ユーザの自宅におけるアルコール飲料の在庫量をさらに記憶することを特徴としてもよい。さらに、前記制御部は、前記推定した摂取量に基づいて、前記記憶された在庫量を減算することを特徴としてもよい。
かかる構成によると、ユーザの自宅におけるアルコール飲料の在庫量を推定することが可能になる。

また、前記制御部は、前記在庫量が所定値を下回った場合に、前記アルコール飲料を発注するためのトリガを生成することを特徴としてもよい。
かかる構成によると、例えば、アルコール飲料の在庫を切らさないように、当該アルコール飲料を自動的に発注することが可能になる。

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

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

センサ２００は、空気中におけるアルコールの濃度を検出するセンサである。ユーザがアルコール飲料を摂取すると、呼気中のアルコールが、センサ２００によって検出される。
サーバ装置１００は、（１）センサ２００の出力に基づいて、ユーザによるアルコール飲料の摂取量（消費量）を推定する処理と、（２）推定結果に基づいて、自宅におけるアルコール飲料の在庫量を更新する処理と、（３）必要に応じてアルコール飲料の発注を行う処理と、を実行する。
ＥＣサーバ３００は、ネットワークを介して商品（アルコール飲料）の注文を受け付け
る装置である。ＥＣサーバ３００は、通信販売事業を運営する事業者によって管理される。

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

図２は、本実施形態に係る情報処理システムの構成要素をより詳細に示した図である。ここではまず、センサ２００について説明する。
センサ２００は、空気中におけるアルコールの濃度を検出する一つ以上のセンサから構成される。センサ２００は、アルコール飲料を摂取したユーザの呼気を検出することができれば、その種類は問わない。ただし、ユーザがアルコール飲料を摂取する場所が定まっている場合、当該場所の近傍に設置されることが好ましい。例えば、ユーザが、自宅のダイニングテーブルにおいてアルコール飲料を摂取する場合、ダイニングテーブルの近傍にセンサ２００を配置することが好ましい。
なお、センサ２００は、複数のセンサから構成されていてもよい。例えば、ユーザが、自宅内の複数の場所でアルコール飲料を摂取する場合、当該複数の場所のそれぞれにセンサ２００が設置されていてもよい。

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

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

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

データ取得部１０１１は、センサ２００からセンサデータを取得する。取得するセンサデータは、センサ２００の周辺（すなわち、ユーザの周辺）における空気中のアルコール濃度を示す。なお、センサ２００が複数ある場合、データ取得部１０１１は、データを送信したセンサの識別子を取得してもよい。データ取得部１０１１が取得したセンサデータは、濃度データとして、後述する記憶部１０２に順次蓄積される。濃度データは、空気中のアルコール濃度の経時変化を示すデータである。

摂取量判定部１０１２は、記憶された濃度データに基づいて、ユーザによるアルコール飲料の摂取量を判定する。
具体的には、後述する評価モデルを用いて、記憶されたアルコール濃度の経時変化と一
致するパターンを特定し、当該パターンに紐付いたアルコール飲料の摂取量を特定する。例えば、蓄積された濃度データによって示されたアルコール濃度の経時変化が、「３５０ｍｌの缶ビールを２本消費した」というパターンに一致すると判定する。当該判定の結果は、在庫管理部１０１３へ送信される。

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

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

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

また、記憶部１０２は、ユーザごとの評価モデルを記憶する。評価モデルとは、空気中のアルコール濃度の経時変化と、ユーザが消費したアルコール飲料の量とを関連付けたモデルである。

ここで、図４を参照して、評価モデルについて説明する。図４は、空気中のアルコール濃度の経時変化を、ユーザによる飲酒のパターンごとに示した図である。
例えば、ユーザが缶ビールを１缶消費した場合、空気中のアルコール濃度が、図４（Ａ）で示したような変化をするものとする。また、ユーザが缶ビールを２缶消費した場合、空気中のアルコール濃度が、図４（Ｂ）で示したような変化をするものとする。これらのパターンをモデル化して記憶し、空気中のアルコール濃度の経時変化と照合することで、ユーザがどのパターンに合致する飲酒を行ったかを特定することができる。

図５は、評価モデルの構造を説明する図である。例えば、空気中のアルコール濃度の経時変化が、パターン１と合致した場合、ユーザが、３５０ｍｌの缶ビールを１本消費したことが推定できる。評価モデルには、このように、空気中のアルコール濃度の経時変化を複数のパターンによって表したデータが含まれる。
ユーザに対応する評価モデルは、記憶部１０２に事前に記憶される。評価モデルは、例えば、機械学習によって生成されてもよい。

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

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

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

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

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

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

なお、濃度データには、センサ２００が検出した空気中のアルコール濃度をそのまま記録してもよいが、ユーザとセンサとの位置関係が一定ではない場合、取得した値を補正することが好ましい。
図８は、ユーザが居室内において飲酒を行う場所を例示した平面図である。例えば、符号８０１，８０２で示したように、ユーザが複数の場所で飲酒を行い、これを、別々のセンサ２００Ａおよび２００Ｂでセンシングする場合、飲酒量が同一であっても、それぞれのセンサが検出する空気中のアルコール濃度は異なりうる。これは、センサとユーザとの位置関係（距離）が異なるためである。
よって、宅内において二つ以上のセンサ２００を利用する場合、センサごとに異なる基準を用いて、空気中のアルコール濃度を、比較可能な値に変換することが好ましい。例えば、空気中のアルコール濃度に基づいて、ユーザの呼気中におけるアルコール濃度を推定し、推定した値を濃度データとして記憶させてもよい。

摂取量判定部１０１２は、取得した濃度データに基づいて、直近の所定の期間におけるユーザのアルコール飲料の消費量を判定する。
具体的には、濃度データによって表された空気中のアルコール濃度の経時変化が、評価モデルに定義された複数のパターンのうちのどれに一致するかを判定し、当該パターンに関連付いたアルコール飲料の摂取量を取得する。例えば、図４（Ａ）のパターンに一致した場合、ユーザが３５０ｍｌの缶ビールを１本飲んだと判定することができる。

なお、評価モデルとして、機械学習モデルを利用してもよい。例えば、アルコール濃度の経時変化を入力データ、アルコール飲料の消費量を教師データとして機械学習を実行することで、濃度データに基づいてアルコール飲料の消費量を推定する機械学習モデルを得ることができる。

なお、パターンの一致／不一致を判定する方法は、例示した方法に限られない。例えば、継続時間、濃度を表す数値が立ち上がったタイミングや回数、濃度を表す数値の減衰などに基づいて、アルコール濃度の経時変化が所定のパターンと一致しているか否かを判定してもよい。

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

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

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

まず、ステップＳ１１で、データ取得部１０１１が、センサ２００からセンサデータを取得する。
次に、ステップＳ１２で、データ取得部１０１１が、取得したセンサデータに基づいて、アルコールを検出している状態にあるか否かを判定する。アルコールを検出していない状態、すなわち、空気中のアルコール濃度がゼロ（または実質的にゼロ）であった場合、処理はステップＳ１１に戻る。空気中からアルコールを検出した場合、処理はステップＳ１３へ進む。

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

次に、ステップＳ１４で、ユーザによる飲酒が終了したか否かを判定する。ユーザが飲酒を終了したことは、センサデータに基づいて判定してもよい。例えば、検出したアルコール濃度が所定値を下回った場合、飲酒が終了したと判定することができる。
また、ユーザが飲酒を終了したことは、例示した以外の他のセンサを用いて判定してもよい。例えば、人感センサや画像センサの出力に基づいて、ユーザがダイニングテーブルを離れたと判定した場合に、飲酒が終了したと判定してもよい。さらに、冷蔵庫ドアの開閉をセンシング可能な場合、開閉が所定の時間以上行われなかった場合に、飲酒が終了したと判定してもよい。飲酒が終了したと判定した場合、処理はステップＳ１５へ遷移する。それ以外の場合、処理はステップＳ１１へ遷移する。

ステップＳ１５では、摂取量判定部１０１２が、ユーザによるアルコール飲料の摂取量を判定する。本ステップでは、記憶部１０２に記憶された評価モデルを用いて、摂取されたアルコール飲料の種類および量を判定する。判定結果は、在庫管理部１０１３へ送信される。

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

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

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

（第二の実施形態）
第一の実施形態では、空気中のアルコール濃度の経時変化に基づいて、アルコール飲料の消費量を推定した。一方で、空気中のアルコール濃度の経時変化は、消費されたアルコール飲料の度数等に影響を受けるため、度数が異なるアルコール飲料が複数ある場合、何が消費されたかを正確に判定できないケースが生じうる。例えば、空気中のアルコール濃度の経時変化が同じであっても、アルコール度数が低いものを多く摂取したのか、アルコール度数が高いものを少量摂取したのかが判定できない場合がある。

第二の実施形態は、これに対応するため、付加的な情報として、ユーザが摂取したアルコール飲料の種類または度数を利用する実施形態である。

第二の実施形態では、評価モデルにおいて、ユーザが摂取したアルコール飲料の種類ないし度数ごとに複数のパターンを記憶する。図１０は、第二の実施形態における評価モデルの例である。本例では、アルコール度数が５％のビール、アルコール度数が７％のカクテル、アルコール度数が１５％の日本酒といったように、複数の飲料ごとにパターンが定義されている。

図１１は、第二の実施形態において制御部１０１が実行する処理のフローチャートである。点線で示したステップは、第一の実施形態と同様であるため詳細な説明は省略する。
ステップＳ１０では、摂取量判定部１０１２が、ユーザが摂取しているアルコール飲料の種類および／または度数を取得する。ユーザが摂取しているアルコール飲料の種類や度数は、例えば、ユーザをセンシングした結果に基づいて判定してもよい。
ステップＳ１１～Ｓ１４の処理は、第一の実施形態と同様である。

ステップＳ１５Ａでは、摂取量判定部１０１２が、記憶された評価モデルから、判定された種類および／または度数に対応するデータを抽出し、第一の実施形態と同様の方法によってアルコール飲料の摂取量を推定する。
ステップＳ１６～Ｓ１８の処理は、第一の実施形態と同様である。

第二の実施形態によると、アルコール度数が異なる複数のアルコール飲料がある場合であっても、その消費量を精度よく推定することができる。

（第三の実施形態）
第一および第二の実施形態では、室内における空気中のアルコール濃度を検出対象とした。一方、室内で空調や換気が動作している場合、においの強度が通常よりも早く減衰するため、正しい判定を行えないケースが存在する。
第三の実施形態は、これに対応するため、室内における空調（換気）の動作状況に基づいて、アルコールの濃度を補正する実施形態である。

図１２は、空気中のアルコール濃度の変化を示したグラフである。図示したように、換気を伴う空調が動作している場合、空気中のアルコール成分が屋外に排出されるため、その濃度が早く減衰する。これに対応するためには、換気を伴う空調が動作している場合に、比較を行うためのパターンを補正することが好ましい。

図１３は、第三の実施形態において制御部１０１が実行する処理のフローチャートである。点線で示したステップは、第一の実施形態と同様であるため詳細な説明は省略する。
ステップＳ１０Ａでは、摂取量判定部１０１２が、センサ２００が設置されている部屋
における換気（ないし、換気を伴う空調）の状況を所定の装置から取得する。所定の装置とは、例えば、住宅の空調または換気を制御するホームサーバであってもよいし、エアコンや換気扇のコントローラであってもよい。
ステップＳ１１～Ｓ１４の処理は、第一の実施形態と同様である。

ステップＳ１５Ｂでは、ステップＳ１５と同様に、アルコール飲料の摂取量を推定するが、ステップＳ１０Ａで判定した換気の状況に基づいて、評価モデルに含まれるパターンを補正するという点において第一または第二の実施形態と相違する。補正は、例えば、アルコールの濃度に、換気の強度に応じた所定の係数を乗算することで行ってもよい。また、換気量が取得可能な場合、換気量に応じてアルコール濃度の減衰をシミュレーションし、シミュレーション結果に基づいてパターンを上書きしてもよい。
ステップＳ１６～Ｓ１８の処理は、第一の実施形態と同様である。

第三の実施形態によると、屋内において換気が動作している場合であっても、アルコール飲料の消費量を推定することが可能になる。

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

また、実施形態の説明では、嗜好品としてアルコール飲料を挙げたが、摂取時ににおいを発するものであれば、煙草などにも適用することができる。この場合も、前述した評価モデルを用いて喫煙本数などを判定することができる。

また、実施形態の説明では、センサ２００として、空気中のアルコールを検出するセンサを用いたが、においの原因となる複数種類の分子を検出可能なセンサ（においセンサ）を用いてもよい。なお、においの原因となる分子には様々なものがあるため、においセンサを利用する場合、アルコール臭のみを判定対象とする必要がある。よって、この場合、センサ２００の出力に基づいて、アルコールに対応するにおいのレベルを抽出するためのユニットないしロジックを追加することが好ましい。

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

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

１００・・・サーバ装置
１０１・・・制御部
１０２・・・記憶部
１０３・・・入出力部
２００・・・センサ
３００・・・ＥＣサーバ

Claims

記憶部と前記記憶部に接続する制御部とを有する情報処理装置であって、
前記記憶部は、空気中のアルコール濃度の経時変化のパターンとユーザが摂取した酒類の摂取量とを関連付けたモデルを複数含む決定モデルであって空気中のアルコール濃度の経時変化に基づいて前記摂取量を決定するための決定モデルと、前記ユーザの自宅におけるアルコール飲料の在庫量と、を記憶し、
前記制御部は、
前記ユーザの自宅内に設置され、前記ユーザをセンシングし、空気中のアルコール濃度を検出可能なセンサが検出したアルコール濃度を取得することと、
前記取得されたアルコール濃度をアルコール濃度の経時変化を示す濃度データとして前記記憶部に記憶することと、
前記記憶された濃度データと決定モデルとに基づいて、前記決定モデルに含まれる複数のモデルのうち、前記濃度データで示されるアルコール濃度の経時変化に一致するパターンを有するモデルを特定することと、
前記特定されたモデルが有する前記パターンに関連付けられた酒類の摂取量を特定することにより、前記ユーザによる、酒類の摂取量を推定することと、
を実行する、情報処理装置。
前記制御部は、前記ユーザが摂取したアルコール飲料の度数に関する情報をさらに取得し、前記アルコール飲料の度数にさらに基づいて、前記摂取量を推定する、
請求項１に記載の情報処理装置。
前記制御部は、前記自宅の換気状況に関する情報をさらに取得し、当該情報にさらに基づいて前記推定を行う、
請求項１または２に記載の情報処理装置。
前記制御部は、前記推定した摂取量に基づいて、前記記憶された在庫量を減算する、
請求項１から３のいずれか１項に記載の情報処理装置。
前記制御部は、前記在庫量が所定値を下回った場合に、前記アルコール飲料を発注するためのトリガを生成する、
請求項４に記載の情報処理装置。
コンピュータが、
ユーザの自宅内に設置され、前記ユーザをセンシングし、空気中のアルコール濃度を検出可能なセンサが検出したアルコール濃度の経時変化を示す濃度データと、空気中のアルコール濃度の経時変化のパターンと前記ユーザが摂取した酒類の摂取量とを関連付けたモデルを複数含む決定モデルであって空気中のアルコール濃度の経時変化に基づいて前記摂取量を決定するための決定モデルと、前記ユーザの自宅におけるアルコール飲料の在庫量と、を取得する取得ステップと、
前記取得された濃度データと決定モデルとに基づいて、前記決定モデルに含まれる複数のモデルのうち、前記濃度データで示されるアルコール濃度の経時変化に一致するパターンを有するモデルを特定する特定ステップと、
前記特定されたモデルが有する前記パターンに関連付けられた酒類の摂取量を特定することにより、前記ユーザによる、酒類の摂取量を推定する推定ステップと、
を含む、情報処理方法。
前記推定ステップでは、前記コンピュータが、前記ユーザが摂取したアルコール飲料の度数に関する情報をさらに取得し、前記アルコール飲料の度数にさらに基づいて、前記摂取量を推定する、
請求項６に記載の情報処理方法。
前記推定ステップでは、前記コンピュータが、前記自宅の換気状況に関する情報をさらに取得し、当該情報にさらに基づいて前記推定を行う、
請求項６または７に記載の情報処理方法。
前記推定ステップでは、前記コンピュータが、前記取得した在庫量と、前記推定した摂取量と、に基づいて、前記アルコール飲料を発注するためのトリガを生成する、
請求項６から８のいずれか１項に記載の情報処理方法。
請求項６から９のいずれか１項に記載の情報処理方法を前記コンピュータに実行させるためのプログラム。