《第1の実施形態》
以下、第1の実施形態について、図1〜図8に基づいて、詳細に説明する。図1には、第1の実施形態にかかる電子機器システム1000Aの構成がブロック図にて示されている。また、図2には、電子機器システム1000Aを利用している状況が示されている。
電子機器システム1000Aは、ユーザが食事を行うときに利用するシステムである。電子機器システム1000Aは、図1、図2に示すように、例えば、箸、スプーン、フォーク等の食器1にそれぞれ設けられる食器用機器10A,10Bと、携帯端末30,40,50と、を備える。なお、本実施形態では、父親が食器用機器10Aと携帯端末30とを使用し、子供が食器用機器10Bと携帯端末40とを使用し、母親が携帯端末50を使用するものとする。
(食器用機器10A,10B)
食器用機器10A,10Bは同一の構成を有するため、以後、特に区別する必要のない限り、食器用機器10A,10Bを食器用機器10と記載し説明を行う。図1に示すように、食器用機器10は、検出部11、電極部12、人体通信部13、メモリ14、および制御部15を有する。
検出部11は、食器1に接触した食品に関する情報を検出し、制御部15に出力する。本実施形態では、検出部11は、食品と接触する部分(例えば、フォークの先端)に設けられた電極と、ユーザの人体と接触する部分(例えば、フォークの持ち手)に設けられた電極とを備え、「食品→口→人体」の間の抵抗値を検出し、出力する。
電極部12は、信号電極とグラウンド電極とを有し、ユーザを介して携帯端末30と人体通信を行うための電極である。この電極部12は、食器1内でユーザの身体と接触しやすい場所に設けられる。例えば、電極部12は、接触するユーザの手に触れやすいように、図2に示すように、食器1の持ち手部分に設けられる。
人体通信部13は、バンドパスフィルタを有した電気回路から構成される送信部を有し、送信するデータを変調して送信信号を生成する。なお、人体通信部に受信機能を持たせるようにしてもよい。本実施形態においては、人体通信部13は、検出部11が検出した、食器1に接触した食品に関する情報(ユーザが食品を口にした場合の抵抗値)を携帯端末30に送信する。なお、以下の実施形態において、人体通信に変えて、Bluetooth(登録商標)や、RFID(Radio Frequency Identification)であるFeliCa(登録商標)モジュールや、TransferJet(登録商標)等の近接通信を適用することも可能である。
メモリ14は、不揮発性の半導体メモリ(例えば、フラッシュメモリ)である。
制御部15は、CPU(Central Processing Unit)を備え、食器用機器10全体を制御するものである。本実施形態においては、制御部15は、検出部11が検出した各食品の抵抗値を携帯端末30に送信する制御を行う。
(携帯端末30,40)
携帯端末30,40は、ユーザにより携帯された状態で利用される情報機器である。携帯端末30,40としては、携帯電話、スマートフォン、PHS(Personal Handy-phone System)、PDA(Personal Digital Assistant)等を採用することができるが、本実施形態では、携帯端末30,40は、スマートフォンであるものとする。また、本実施形態においては、携帯端末30,40は、電話機能やインターネット等に接続するための通信機能、および、プログラムを実行するためのデータ処理機能等を有する。なお、本実施形態において、携帯端末30,40は、同一の構成を有するため、代表して携帯端末30について説明する。
携帯端末30は、電極部300、人体通信部302,無線通信部304、GPS(Global Positioning System)モジュール306、フラッシュメモリ308、表示部310、タッチパネル312、マイク314、スピーカ316、撮像部318、カレンダ部320および制御部322を有する。
電極部300は、信号電極とグラウンド電極とを有し、ユーザを介して食器用機器10と人体通信を行うための電極である。
人体通信部302は、バンドパスフィルタを有した電気回路から構成される送受信部を有し、入力した受信信号を復調して受信データを生成する一方、送信するデータを変調して送信信号を生成する。人体通信には、人体に微弱な電流を流して、その電流を変調して情報を伝達する電流方式や、人体の表面に誘起する電界を変調して情報を伝達する電界方式などがあり、電界方式の場合は、ユーザが電極部300に直接触れていなくても人体通信が可能である。このため、本実施形態では、ユーザがポケット(例えば胸ポケット)に携帯端末30を入れておいた場合でも人体通信が成立するように、電界方式が用いられているものとする。なお、携帯端末30もしくは40を所持するユーザが女性の場合には、携帯端末30(40)をポケットではなく、ポシェットなどの鞄に収納する場合があり、このような場合は近接通信を利用するのが好ましい。
無線通信部304は、外部機器と通信するためのものであり、各種の無線通信を適用可能である。本実施形態においては、無線通信部304は、携帯端末50に対して携帯端末30のユーザの食事に関するデータを送信するものである。
GPSモジュール306は、携帯端末30の位置(例えば緯度および経度)を検出するセンサである。
フラッシュメモリ308は、不揮発性の半導体メモリであり、制御部322によって実行される携帯端末30を制御するためのプログラム、および、携帯端末30を制御するための各種パラメータを記憶する。また、フラッシュメモリ308は、食品毎の抵抗値を格納する食品情報テーブルと、ユーザの食事に関するデータ(食事履歴データ)を格納する食事履歴テーブルと、を記憶する。ここで、食品情報テーブル及び食事履歴テーブルについて説明する。
図3(A)は、食品情報テーブルの一例を示す図であり、図3(B)は、食事履歴テーブルの一例を示す図である。
図3(A)に示すように、食品情報テーブルは、「食品名」および「抵抗値」の項目を有する。「食品名」の項目には、食品の名称が入力され、「抵抗値」の項目には、食品の抵抗値(予め計測され、登録されている抵抗値)とユーザの抵抗値(食品を保持していない食器1をユーザに咥えさせた状態で検出部11が検出する抵抗値)との合計値、すなわち、ユーザが食品を口にした場合に検出部11が検出するであろう抵抗値、が入力されている。なお、携帯端末30のユーザ(父親)と携帯端末40のユーザ(子供)ではユーザ自身の抵抗値が異なるため、携帯端末30,40それぞれのフラッシュメモリ308に格納されている食品情報テーブルでは、同一の食品名であっても、その抵抗値は異なる値となる。
食事履歴テーブルは、図3(B)に示すように、「開始日時」と、「終了日時」と、「順番」と、「食品名」と、を項目として備える。
「開始日時」の項目は、ユーザ(父親、子供)が食事を開始した日時を格納する。「終了日時」の項目は、ユーザ(父親、子供)が食事を終了した日時を格納する。「順番」の項目は、当該食事において、食べた食品の順番を一意に識別するための番号を格納する。「食品名」の項目は、各順番において、ユーザ(父親、子供)が食べた食品の名前を格納する。図3(B)が携帯端末30のフラッシュメモリ308に格納されている食事履歴テーブルである場合には、父親が、2012年11月6日の11時50分に食事を開始し、ハンバーグ→白米→ハンバーグ→人参→レタスの順に食べ、12時に食事を終了したこと、が食事履歴テーブルに記録されていることになる。
図1に戻り、表示部310は、例えば液晶表示素子を用いたデバイスであり、携帯端末30本体の所定面(以下、主面と呼ぶ)に設けられ、画像、各種情報およびボタン等の操作入力用画像を表示する。また、本実施形態においては、表示部310は、ユーザの食事履歴データを表示したり、食に関するアドバイスを表示する。
タッチパネル312は、ユーザが触れたことに応じて情報を入力する。タッチパネル312は、表示部310上または表示部310に組み込まれて設けられる。従って、タッチパネル312は、ユーザが表示部310の表面をタッチすることにより、種々の情報を入力する。
マイク314は、携帯端末30本体の主面側の、表示部310の下方に設けられ、ユーザが電話機能を使用する際に口元に位置するようになっている。
スピーカ316は、携帯端末30本体の主面側の、表示部310の上方に設けられ、ユーザが電話機能を使用する際に耳元に位置するようになっている。
撮像部318は、例えば、表示部310の上方でスピーカ316の近傍に設けられており、ユーザが携帯端末30を保持している際(使用している際)のユーザの状況を撮像するものである。この撮像部318は、撮影レンズや、RGBベイヤー配列の撮像素子(CCDおよびCMOSデバイス)などから構成されている。なお、撮像部318を携帯端末30の主面の反対側の面に設けてもよい。
カレンダ部320は、年、月、日、時刻といった時間情報を取得して、制御部322に出力する。なお、カレンダ部320に計時機能を持たせて、ユーザの食事にかかる時間を計測するようにしてもよい。
制御部322は、CPUを有し、携帯端末30全体を制御する。本実施形態においては、制御部322は、ユーザの食事に関するデータの収集を行う。また、制御部322は、ユーザの食事に関するデータ(食事履歴テーブル(図3(B))に含まれるデータ)に基づいて、ユーザの食に関するアドバイスを生成して、表示部310に表示する。
(携帯端末50)
携帯端末50は、携帯端末30,40と同様の構成としてもよいが、図1に示すように、電極部や人体通信部を省略した構成としてもよい。ここでは、携帯端末50の構成のうち、携帯端末30,40と異なる点についてのみ説明する。
無線通信部504は、外部機器と通信するためのものであり、各種の無線通信を適用可能である。本実施形態においては、無線通信部504は、無線通信部304との通信により、制御部322から、父親や子供の食事に関するデータを受信する。
フラッシュメモリ508は、例えば、不揮発性の半導体メモリであり、本実施形態では、無線通信部504が受信した父親や子供の食事に関するデータを記憶したり、地図情報や、各種プログラムを記憶する。
制御部522は、CPUを有し、携帯端末50全体を制御する。本実施形態においては、制御部522は、父親や子供の食事に関するデータ(例えば、昼食において食べた食品の情報)を表示部510に表示したり、夕食のメニュー、食材、お店に関する情報を母親に提供する。
(食事履歴データの蓄積処理)
次に、図4〜図6を用いて、携帯端末30の制御部322が実行する食事履歴データの蓄積処理の一例について説明する。図4は、制御部322が実行する、ユーザ(父親)の食事履歴データの蓄積処理の一例を示すフローチャートである。なお、前提として、父親は、社員食堂で昼食(メニューは、ご飯、味噌汁、サラダ、ハンバーグ)を食べようとしているものとする。
図4の処理では、まず、ステップS10において、制御部322が、食器用機器10との間で人体通信が成立したか否か判断する。このステップS10では、ユーザ(父親)が食事を始めるために、図2に示すように食器1(図2ではフォーク)を手に取ったか否かを判断している。ここでの判断が否定された場合、すなわち、食器用機器10との人体通信が成立していない場合には、制御部322は、ステップS10の判断が肯定されるまでステップS10の処理を繰り返す。ステップS10の判断が肯定された段階、すなわち、食器用機器10との人体通信が成立した段階で、制御部322は、ステップS12に移行する。
ステップS12に移行すると、制御部322は、ユーザ(父親)が食事を開始したとして、カレンダ部320から、日時情報を取得し、当該日時を、食事履歴テーブルの「開始日時」に登録する。例えば、父親が食事を始めるためにフォークを手にとることで、携帯端末30と食器用機器10との間で人体通信が成立すると(S10/YES)、制御部322は、図5(A)に示すように、食事履歴テーブルの「開始日時」にカレンダ部320から取得した日時を登録する。なお、カレンダ部320が計時機能を有する場合には、制御部322は、ステップS12において、カレンダ部320を用いて計時を開始し、食事にかかる時間を計測してもよい。
次のステップS14では、制御部322は、検出部11の検出値に変化があったか否か判断する。このステップS14では、ユーザ(父親)が新たな食品を口にしたか否かを判断している。ここでの判断が否定された場合、すなわち、検出部11の検出値に変化がない場合には、制御部322は、ステップS14の判断が肯定されるまで、ステップS14の処理を繰り返す。そして、検出部11の検出値に変化があった段階で、ステップS14の判断は肯定され、制御部322は、ステップS16に移行する。
ステップS16に移行すると、制御部322は、検出部11の検出結果を取得する。そして、次のステップS18において、ユーザが食べた食品を特定し、ステップS20において、フラッシュメモリ308が記憶する食事履歴テーブルに登録する。例えば、父親がハンバーグを口にした場合に、食器用機器10の検出部11が、抵抗値Dを検出したものとする。この場合、制御部322は、メモリ14に格納された食品情報テーブル(図3(A))と、検出部11が検出した抵抗値Dとを比較し、父親が食べた食品がハンバーグであると特定し、図5(B)に示すように、食事履歴テーブルに父親が1番目に食べた食品として、“ハンバーグ”を登録する。
図4に戻り、次のステップS22では、制御部322は、ユーザが食事を終了したか否か判断する。ユーザが食事を終了したか否かは、例えば、食器用機器10との人体通信が成立しない時間が所定時間(例えば5〜10分)続いたか否かによって判断してもよいし、あるいは、GPSモジュール306によって取得した携帯端末30の位置が、社員食堂から所定距離離れたか否かによって判断してもよい。
ステップS22の判断が否定された場合、すなわち、ユーザがまだ食事を終了していない場合、制御部322は、ステップS14に戻り、ステップS14〜S20の処理を、ユーザ(父親)が食事を終えるまで繰り返す。これにより、図5(C)に示すようなユーザの食事履歴データを、ユーザに特別な操作を強いることなく自動的に蓄積することができる。なお、図5(C)からは、父親が、ハンバーグ、ご飯、ハンバーグ、サラダ、…、の順に口にしたことが分かる。
その後、ステップS22の判断が肯定された場合、すなわち、父親が食事を終了した場合、制御部322は、ステップS24に移行し、カレンダ部320から日時情報を取得し、当該日時を食事履歴テーブルの「終了日時」に登録する(図3(B)参照)。
次いで、ステップS28では、制御部322は、食事履歴テーブル(図3(B))に記録されているデータに基づき、食事に関するデータや、アドバイスを生成して、表示部310に表示する。この場合、例えば、図6(A)に示すように、制御部322は、食品を食べた順番や、食事にかかった時間を表示部310に表示することとしてもよい。あるいは、制御部322は、ユーザ(父親)が食事の最初に野菜(食物繊維)などの消化吸収に時間のかかるものを食べ、次いで汁物を食べ、その後に肉などのたんぱく質を食べ、最後にご飯(炭水化物)を食べたか(血糖値が上がりにくい食べ方をしているか)を判定し、図6(B)に示すように表示部310に判定結果を表示することとしてもよい。この場合、制御部322は、さらに、食べる順番に関するアドバイス(「最初に野菜を食べると血糖値低下に効果があります」などのアドバイス)を表示してもよい。また、制御部322は、食事にかかった時間に基づいて、早食い傾向であるか否かを表示部310に表示してもよい。また、制御部322は、フラッシュメモリ308に記憶されている食事履歴データに基づいて、例えば、肉食が続いているなどユーザの食事の傾向を表示部310に表示してもよい。
図4に戻り、制御部322は、ステップS30において、今回の食事履歴データを、例えば、他のユーザが所持する携帯端末(例えば、母親が所有する携帯端末50)や外部機器に送信し、本処理を終了する。これにより、食事履歴データを他者と共有したり、活用したりすることが可能となる。なお、制御部322は、ステップS30において、表示部310に表示したデータのうちどれを誰に送信するかをタッチパネル312を用いてユーザ(父親)に選択させてもよい。また、ユーザに一度選択させた後は、データや送信先の選択を省略するようにしてもよい。
なお、上記においては、社員食堂での食事を例に採り説明したが、ユーザが家庭内やレストランで食器用機器10が設けられた食器1を利用すれば、制御部322は、様々な場所での食事履歴データを取得することが可能である。
(メニュー提案処理)
次に、図4のステップS30において携帯端末30が送信した食事履歴データを使用して、携帯端末50の制御部522が実行するメニュー提案処理について説明する。なお、本実施形態では、携帯端末50の制御部522が、メニュー提案処理を実行することとするが、携帯端末30,40の制御部322が、自機に記憶されている食事履歴データに基づいて本処理を実行してもよい。
図7は、母親が所持する携帯端末50の制御部522が実行するメニュー提案処理の一例を示すフローチャートである。
図7の処理では、まず、ステップS100において、制御部522が、携帯端末(ここでは、父親の携帯端末30とする)からの食事履歴データ(図3(B)の食事履歴テーブルのデータ)の受信が完了したか否か判定する。ここでの判断が否定された場合、すなわち、携帯端末30からのデータ受信が完了していない場合には、データ受信が完了するまで、制御部522はステップS100の処理を繰り返す。そして、データ受信が完了した段階で、ステップS100の判断が肯定され、制御部522は、ステップS102に移行する。
ステップS102に移行すると、制御部522は、取得した食事履歴データに基づいて、表示部510に、携帯端末30のユーザ(父親)が食べた食事に関するデータを表示する。次いで、ステップS104において、制御部522は、フラッシュメモリ508に記憶されている食事履歴データを、所定期間分(例えば、1週間分)、表示部510に表示する。
次いで、ステップS106では、制御部522が、フラッシュメモリ508に記憶されているメニューから、表示部510に表示されているメニューと重ならないメニューの候補をいくつか選択し、表示部510に表示する。この場合、制御部522は、例えば、カレンダ部520からの季節情報に基づいて候補となるメニューを選択してもよいし、無線通信部504を介して外部機器から取得した情報(例えば、近隣のスーパーでは食材Aが安いという情報や、食材Bが旬であるという情報)に基づいてメニュー候補を選択してもよい。
次いで、ステップS108では、制御部522は、複数のメニュー候補の1つがユーザ(母親)によって選択されたか否か判断する。ここでの判断が肯定された場合、すなわち、複数のメニュー候補のうちの1つがタッチパネル312から選択された場合、制御部522は、ステップS110に移行する。
ステップS110に移行すると、制御部522は、選択されたメニューに関する情報を、表示部510に表示する。例えば、制御部522は、GPSモジュール506が検出した携帯端末50の位置情報(すなわち、母親の位置情報)と、フラッシュメモリ508に記憶されている地図とに基づいて、選択したメニューの食材を購入できる店舗情報や、当該店舗までのルートなどを表示部510に表示する。この場合、制御部522は、無線通信部504を介して外部機器から取得した店舗での特売情報等に基づいて、選択したメニューの食材を安く購入できる店舗を表示部510に表示してもよい。また、制御部522は、選択したメニューのレシピや調理時間を表示部510上に表示することとしてもよい。制御部522は、表示部510上に表示を行った後、図7の全処理を終了する。
一方、ステップS108の判断が否定された場合、すなわち、メニュー候補が選択されていない場合には、制御部522は、ステップS112に移行する。ステップS112では、制御部522は、ユーザ(母親)からの終了指示を受け付けたか否か判断する。例えば、制御部522は、表示部510上に表示された終了ボタンがユーザ(母親)によって押されたか否か判断する。
ステップS112の判断が否定された場合、すなわち、ユーザ(母親)からの終了指示を受け付けていない場合には、制御部522は、ステップS108に戻る。一方、ステップS112の判断が肯定された場合、すなわち、ユーザ(母親)からの終了指示を受け付けた場合には、制御部522は、図7の全処理を終了する。
なお、上記説明においては、制御部522は、父親の携帯端末30から食事履歴データを取得して、メニュー提案処理を行う場合について説明したが、これに限らず、子供の携帯端末40から食事履歴データを取得して、メニュー提案処理を行うこととしてもよい。また、制御部522は、父親の携帯端末30と子供の携帯端末40から食事履歴データをそれぞれ取得して、各食事履歴データを考慮してメニュー提案処理を行うこととしてもよい。
なお、上述した図7の処理は、携帯端末30からデータが送信された場合に実行されるものとしたが、これに限られるものではなく、例えば、毎日、所定の時刻(例えば、昼食が終了する13時ごろや、夕食の買い物に出かける前の時刻(15時ごろ))に、携帯端末50が携帯端末30から食事履歴データを取得するようにしてもよい。また、携帯端末50の制御部522は、携帯端末30,40から食事履歴データを取得するのではなく、以下に説明するように、特定の食品に関する情報を取得してもよい。
(食品問い合わせ処理)
図8(A)は、携帯端末50の制御部522が、携帯端末30のユーザが特定の食品を食べたか否かを問い合わせる処理(食品問い合わせ処理)の一例を示すフローチャートである。また、図8(B)は、問い合わせを受けた携帯端末30の制御部322が実行する問い合わせに対する応答処理の一例を示すフローチャートである。
図8(A)の処理では、まず、ステップS200において、制御部522が、ユーザから、問い合わせ対象となる食品の入力を受け付ける。そして、次のステップS302において、問い合わせ対象の食品を、携帯端末30に送信する。例えば、母親が、携帯端末30のユーザ(父親)が「ブロッコリー」を食べたか否か知りたいとする。この場合、制御部522は、母親による操作に応じて、「ブロッコリー」を問い合わせ対象の食品として、携帯端末30に送信する。
一方、携帯端末30の制御部322は、図8(B)のステップS300において、携帯端末50から問い合わせを受信したか否かを判断する。ここでの判断が肯定された場合、すなわち、携帯端末50から問い合わせを受信した場合には、制御部322は、次のステップS302において、問い合わせ対象の食品を携帯端末50から受信する。ここでは、問い合わせ対象の食品として、「ブロッコリー」を受信する。
次いで、ステップS304では、制御部322は、問い合わせ対象の食品をユーザが食べたか否かを、食事履歴テーブル(図3(B))に格納された食事履歴データに基づいて判断し、その結果を携帯端末50に送信し、処理を終了する。例えば、図3(B)に示す食事履歴テーブルにおいて、「ブロッコリー」は登録されていない。この場合、携帯端末30は、父親がブロッコリーを食べていないと判断し、例えば、「ブロッコリー未摂取」と携帯端末50に送信する。
図8(A)に戻り、携帯端末50の制御部522は、ステップS202以降、ステップS204において、問い合わせ対象の食品を携帯端末30のユーザが食べたか否かの結果を受信するまで待機している。したがって、制御部522は、携帯端末30においてステップS304が実行された段階でステップS206に移行し、受信した結果を表示部310に表示し、処理を終了する。これにより、母親は、父親が「ブロッコリー」を食べなかったことを確認できるので、父親の好き嫌いを知ることができる。また、例えば、父親の昼食として母親がお弁当を作った場合に、父親が嫌いな食材を口にしたかどうか、残飯として破棄してしまったかどうかを知ることもできる。
なお、上記においては、母親が問い合わせ対象の食品を1品入力しているが、これに限らず、複数品目を入力することとしてもよい。また、上記においては、母親の携帯端末50から父親の携帯端末30に対して問い合わせる場合について説明したが、母親の携帯端末50から子供の携帯端末40に対して問い合わせることとしてもよい。
以上、詳細に説明したように、第1の実施形態によれば、携帯端末30,40は、食品と接触し食品に関する情報を検出する検出部11を有する食器用機器10との間で人体通信を行う人体通信部302と、人体通信部302を介して取得した検出部11の検出結果に基づき得られた情報を表示する表示部310と、を備えている。これにより、携帯端末30,40は、ユーザに特別な操作を強いることなく自動的にユーザの食に関する行動を記録し、ユーザに提供することができる。また、ユーザは、自身の食に関する行動を確認することができる。
また、本第1の実施形態では、表示部310は、検出部11が検出した食品の順番を表示するため、ユーザは、自分の食事をとる際の傾向(例えば、おかずを先に食べてしまう等)を把握することが可能となる。
また、本第1の実施形態では、携帯端末30,40が、人体通信部302とは異なる無線通信部304を備え、無線通信部304は、食事履歴データを携帯端末50等の外部機器に送信する。したがって、本実施形態によれば、携帯端末30,40の食事履歴データを他者と共有したり、活用したりすることが可能となる。例えば、父親及び子供の食事履歴データを受信した母親は、受信した食事履歴データを、次の食事のメニューの考案に活用することができる。これにより、父親や子供の昼食のメニューと夕食のメニューとが同じになるなどの事態の発生を避けることが可能となる。
また、本第1の実施形態では、携帯端末30,40が、食品毎の抵抗値を記憶するフラッシュメモリ308を備えているので、制御部322は、検出部11が検出した抵抗値から、食品を特定することができる。
また、本第1の実施形態では、携帯端末30,40が、人体通信部302が、食器用機器10と通信をしたことに応じて、日時を取得する、あるいは、計時を行うカレンダ部320を備えており、表示部310は、カレンダ部320により取得された食事開始時間、食事終了時間や、食事にかかった時間を表示する。これにより、ユーザは、自身が食事にかける時間の傾向を知ることができる。
また、本第1の実施形態において、表示部310は、食事に関するアドバイスを表示するので、ユーザは、自身の食事に関するアドバイスを受けることができ、食事状況の改善に役立てることができる。
なお、上記第1の実施形態では、図6(A)に示すように、制御部322が、食事履歴データに基づいて、ユーザが摂取した食品に関する情報を表示部310上に表示する場合について説明したが、これに限られるものではない。例えば、制御部322は、フラッシュメモリ308に記憶されている食品のうち、検出部11が検出していない食品を表示部310上に表示してもよい。これにより、ユーザは、自分が摂取していない食品について認識することができる。また、制御部322は、ユーザが一日に摂取した品目数やカロリー数を表示部310上に表示してもよい。
なお、上記第1の実施形態では、食器用機器10が、検出部11において検出された食材の抵抗値を携帯端末30,40に送信することとしていたが、これに限られるものではない。例えば、食器用機器10のメモリ14が食品情報テーブル(図3(A))を記憶し、制御部15が、検出部11が測定した抵抗値と、メモリ14が記憶する食品情報テーブルのデータとを比較することで特定した食品や料理を、携帯端末30,40に送信することとしてもよい。この場合、図4に示す処理において、ステップS18の処理を省略することができる。
なお、制御部322は、ユーザが食事中に食器を置いた時間や回数などをフラッシュメモリ308に記憶してもよい。制御部322は、食器用機器10との人体通信が成立しているか否かに基づいて、ユーザが食事中に食器を置いたか否かを判断できる。この場合、制御部322は、ユーザが食事中に食器を置いた時間や回数なども、表示部310に表示することができる。
なお、上記第1の実施形態では、食器用機器10の検出部11が、ユーザが食品を口にした場合の抵抗値を検出するものとしていたが、これに限られるものではなく、検出部11は、例えば、食器1と接触した食品の固さ、水分量、塩分量、糖分等を検出してもよい。この場合、食品情報テーブルは、食品毎に、抵抗値のほかに、固さ、水分量、塩分量、糖分等のデータを備えるようにすればよい。食品の様々な特性情報を用いることにより、より正確に食品を特定することが可能となる。
また、上記第1の実施形態では、携帯端末30,40がスマートフォンである場合について説明したが、これに限られるものではなく、携帯端末30,40の構成及び機能を、メガネ、補聴器、時計などの人体に身につけるものへ適用することとしてもよい。
《第2の実施形態》
次に、第2の実施形態について説明する。本第2の実施形態は、レストランなどの飲食施設において電子機器システムを利用する場合の例である。図9は、第2の実施形態に係る電子機器システム1000Bの構成を示すブロック図である。また、図10は、電子機器システム1000Bを利用している状況を示す図である。
図9に示すように、電子機器システム1000Bは、食器用機器10A,10Bと、フロア用機器60と、店舗端末70と、撮像ユニット80と、を備える。なお、食器用機器10A,10Bの構成及び機能は、第1の実施形態で説明したものと同一であるため、説明を省略する。また、以後の説明において、特に区別する必要のない限り、食器用機器10A,10Bを食器用機器10と記載し説明を行う。
(フロア用機器60)
フロア用機器60は、各テーブルの床に設けられており、図9に示すように、床電極部610と、人体通信部620と、制御部630と、通信部640と、を有する。
床電極部610は、図10に示すように、顧客が座るテーブルの床に設けられ、複数の顧客や椅子に対応するように、部分電極610−1〜610−n(nは任意の整数)を有している。部分電極610−1〜610−nは、信号電極とグラウンド電極とを有し、ユーザを介して食器用機器10と人体通信を行うための電極である。
人体通信部620は、バンドパスフィルタを有した電気回路から構成される送受信部を有し、入力した受信信号を復調して受信データを生成する一方、送信するデータを変調して送信信号を生成する。本第2の実施形態では、人体通信部620は、床電極部610及び顧客を介して、食器1に設けられた食器用機器10と人体通信を行う。なお、人体通信部620として電界方式を採用した場合には、顧客が靴を履いていたり、靴下を着用していても人体通信は可能である、すなわち、本実施形態における接触は、人体との直接的な接触のみならず、衣服や靴を介在させた接触も含む概念である。
通信部640は、後述の店舗端末70と通信を行うものであり、その通信方式は有線、無線などいずれを採用してもよい。
制御部630は、CPUを備え、食器用機器10から受信した食品に関する情報を通信部640を用いて店舗端末70に送信する制御を行う。
(撮像ユニット80)
撮像ユニット80は、図9に示すように、撮像部810と、制御部820と、通信部830と、を有する。
撮像部810は、レストランの天井や壁に設けられ、レンズ系、撮像素子、画像処理回路を備える。なお、不図示の駆動系により、撮像部810をチルト方向に駆動するようにしてもよい。この場合、撮像部810は、フロア用機器60から顧客が座っている位置情報を取得し、当該位置情報に基づいてその撮像位置を変えることにより、特定の顧客を撮像することができる。なお、撮像部810は、店舗の大きさやレイアウトに応じて複数設けてもよい。
通信部830は、撮像部810が撮像した画像データを店舗端末70に送信するものであり、その通信方式は有線、無線などいずれを採用してもよい。
制御部820は、CPUを有し、撮像ユニット80全体を制御するものである。本実施形態では、制御部820は、後述の店舗端末70の指示に基づき、指定された顧客を撮像するように、不図示の駆動部により撮像部810の撮像位置を調節する。また、制御部820は、撮像部810が撮像した画像データを、店舗端末70に送信する制御を行う。
(店舗端末70)
店舗端末70は、図9に示すように、通信部710と、画像解析部720と、メモリ部730と、カレンダ部740と、表示部750と、スピーカ760と、制御部770と、を有する。
通信部710は、フロア用機器60の通信部640および撮像ユニット80の通信部830と、無線や有線などにより通信を行うものである。通信部710は、フロア用機器60の通信部640から顧客の食事に関する情報(食事情報データ)を受信するとともに、撮像ユニット80の通信部830から顧客の画像データを受信する。
画像解析部720は、撮像ユニット80が撮像した画像データに基づき、顧客の人数を検出したり、顧客の属性を解析する。
メモリ部730は、不揮発性の半導体メモリ(例えば、フラッシュメモリ)を含み、店舗で提供する食事のメニュー情報(図14)や、食品名とその抵抗値とを関連付けた食品情報テーブル(図3(A)参照)を記憶する。なお、本第2の実施形態における食品情報テーブルでは、「抵抗値」の項目に食品そのものの抵抗値が入力されているものとする。また、メモリ部730は、後述する制御部770の制御の下、フロア用機器60から取得した顧客の食事情報データと、画像解析部720が解析した顧客の属性情報とを関連づけて食事情報テーブル(図13(A)等)に記憶する。
カレンダ部740は、日時情報を制御部770に出力するとともに、制御部770の指示に基づき計時を行う計時機能を有する。
表示部750は、レストランの従業員用の表示を行う。例えば、表示部750は、各顧客に対して次に料理を出すタイミングなどを表示する。
スピーカ760は、音声出力装置であり、レストランの従業員への各種音声案内を行う。具体的には、スピーカ760は、従業員の注意を前述の表示部750に向けるための音声を出力したり、表示部750の表示内容を音声で案内したりする。
制御部770は、CPUを有し、店舗端末70および電子機器システム1000B全体を制御するものである。本実施形態において、制御部770は、撮像ユニット80に顧客画像の撮像を指示する。また、制御部770は、フロア用機器60から取得した食事情報データや、画像解析部720から取得した顧客の属性をメモリ部730に記憶する。また、制御部770は、顧客が摂取しなかった食品等を分析する。
(食事情報データの登録・蓄積処理)
次に、制御部770が実行する、食事情報データの登録・蓄積処理の一例について、図11及び図12のフローチャートを用いて説明する。
(登録処理)
制御部770は、まず、図11のフローチャートが示す、食事情報テーブルの登録処理を行う。この処理は、顧客毎の食事情報データを蓄積するための準備処理にあたる。
図11の処理では、まず、ステップS400において、制御部770は、撮像ユニット80を制御して、テーブルに着席したグループの顧客画像を撮像する。なお、ステップS400が実行されるタイミングとしては、例えば、従業員が店舗端末70に対して撮像指示を出したタイミングであってもよいし、人感センサ等で人が着席したことを検出したタイミングであってもよいし、その他のタイミングであってもよい。
次いで、ステップS401では、制御部770は、撮像した顧客画像を解析する画像解析部720からグループを構成する顧客の人数を取得する。この場合、画像解析部720は、人がいない状態の画像との比較により、顧客の人数を解析するなどすることができる。
次のステップS402では、制御部770は、画像解析部720から、当該グループを構成する顧客の属性情報を取得する。なお、制御部770は、属性情報を取得した段階で、各顧客の位置に基づいて、各顧客と部分電極610−1〜610−nのいずれかとを対応付ける。次いで、ステップS403では、制御部770は、当該グループを構成する顧客の食事情報データを記録するためのテーブルを、メモリ部730に新規に登録し、処理を終了する。この図11に示す処理によって、図13(A)に示すように、当該グループに対して、食事情報データを記録するための食事情報テーブルが登録される。
ここで、食事情報テーブルについて詳細に説明する。図13(A)に示すように、食事情報テーブルは、「グループID」、「顧客ID」、「顧客属性」、「部分電極」、「食事開始日時」、「食事終了日時」、「メニュー名」、「料理名」、「順番」、及び「食品名」の項目を有する。
「グループID」は、来店した顧客グループを一意に識別するための情報である。「顧客ID」は、グループIDで識別されるグループを構成する顧客を一意に識別するための情報である。「顧客属性」の項目には、画像解析部720から取得した、顧客IDで識別される顧客の属性が登録される。図13(A)の例では、グループID“G001”のグループは、3人の顧客から構成され、その属性は、20代女性、40代男性、30代男性である。「部分電極」の項目には、各顧客の位置に対応する部分電極610−1〜610−nの識別子が登録される。
「食事開始日時」の項目には、各顧客が食事を開始した日時が格納される。「食事終了日時」の項目には、各顧客が食事を終了した日時が格納される。「メニュー名」の項目には、各顧客が注文したメニューの名前が格納される。「料理名」の項目には、各メニューに含まれる料理の名前が格納される。「順番」は、当該食事において、顧客が食べた食品の順番を一意に識別するための項目である。「食品名」の項目は、各順番において、顧客が食べた食品の名前を格納する。
(蓄積処理)
次に、制御部770が実行する、各顧客の食事情報データの蓄積処理について説明する。図12は、テーブルに着席したグループの各顧客の食事情報データを蓄積する処理の一例を示すフローチャートである。なお、図12の処理が実行される前提として、顧客に一度食器1(フォークなど)を咥えさせることで、顧客自身の抵抗値を制御部770が取得しているものとする。ただし、これに限らず、例えば、コップに食器用機器10を設けておき、水を飲むために顧客がコップに口をつけたときの抵抗値を顧客自身の抵抗値として制御部770が取得することとしてもよい。
図12の処理では、まず、ステップS404において、制御部770が、食器用機器10との人体通信が成立したか否か判断する。このステップS404では、顧客が食事を始めるために、食器を手に取ったか否かを判断している。ここでの判断が否定された場合、すなわち、食器用機器10との人体通信が成立していない場合には、制御部770は、食器用機器10との人体通信が成立するまで、ステップS404の処理を繰り返す。そして、食器用機器10との人体通信が成立した段階で、ステップS404の判断が肯定され、制御部770は、ステップS405に移行する。
ステップS405に移行すると、制御部770は、カレンダ部740から日時情報を取得し、食事情報テーブルにおいて、人体通信が成立した顧客の「食事開始日時」の項目を更新する。ここで、例えば、図13(A)のグループID“G001”を構成する顧客ID“C01”の20代女性(以後、顧客C01と記載する)が、フォークを手に取った場合(S404/YES)、制御部770は、図13(B)に示すように、食事情報テーブルにおいて、顧客C01の「食事開始日時」の項目を更新する(S405)。なお、図13(B)においては、顧客C02,C03については、まだ、人体通信が成立していないため、「食事開始日時」の項目が更新されていない。
図12に戻り、次のステップS406では、制御部770が、顧客がコースメニューを注文したか否か判断する。ここでの判断が肯定された場合、すなわち、顧客がコースメニューを注文した場合、制御部770は、ステップS408に移行する。なお、顧客が注文したメニューの情報は、レストランの従業員等が保持するPOS端末等から店舗端末70に入力され、メモリ部730に格納されるものとする。
ステップS408に移行すると、制御部770は、顧客が注文したメニュー情報をメモリ部730から取得する。このとき、制御部770は、食事情報テーブルの「メニュー名」の項目を更新すると共に、取得したメニュー情報に基づき、当該メニューで最初に提供される料理を「料理名」の項目に登録する。なお、本第2の実施形態では、顧客C01が“Aコース”を注文したものとする。この場合、制御部770は、「メニュー名」の項目に“Aコース”を登録する(図13(C)参照)。さらに、図14に示すメニュー情報において、Aコースで最初に提供される料理は、“前菜”であるため、制御部770は、「料理名」の項目に“前菜”を登録する(図13(C)参照)。
次のステップS410では、制御部770は、検出部11の検出値に変化があったか否か判断する。このステップS410では、顧客が新たな食品を口にしたか否かを判定している。ここでの判断が否定された場合、すなわち、検出部11の検出値に変化がない場合には、制御部770は、ステップS410の判断が肯定されるまで、ステップS410の処理を繰り返す。そして、検出部11の検出値に変化があった段階で、ステップS410の判断が肯定され、制御部770は、ステップS412に移行する。
ステップS412に移行すると、制御部770は、検出部11の検出結果を取得する。そして、次のステップS414では、制御部770は、メモリ部730に記憶されている食品情報テーブル(図3(A))に基づいて、顧客が食べた食品を特定する。なお、制御部770は、検出部11の検出結果(抵抗値)から、予め測定されている顧客自身の抵抗値を差し引いた値を食品の抵抗値とする。そして、制御部770は、算出された抵抗値と、食品情報テーブルの抵抗値とを比較して、顧客が食べた食品名を特定する。次いで、ステップS416では、制御部770が、特定された食品名を用いて、食事情報テーブルを更新する。なお、制御部770は、食事情報テーブルの「順番」及び「食品名」の項目を更新する。
次のステップS418では、制御部770は、顧客が、現在提供されている料理を食べ終えたか否か判断する。顧客が料理を食べ終えたか否かは、例えば、食器用機器10との人体通信が成立しない時間が所定時間(例えば5〜10分)続いたか否かによって判断することができる。
ステップS418の判断が否定された場合、すなわち、顧客が、現在提供されている料理をまだ食べ終えていない場合、制御部770は、ステップS410に戻る。一方、ステップS418の判断が肯定された場合、すなわち、顧客が、現在提供されている料理を食べ終えた場合には、制御部770は、ステップS420に移行する。
ステップS420に移行すると、制御部770は、コースメニューが終了したか否かを判断する。具体的には、制御部770は、コースメニューに含まれる料理及びその提供順と、ユーザに現在提供されている料理とを比較することによって、コースメニューが終了したか否か判断する。例えば、図13(D)に示すように、顧客C01が、前菜を食べ終えていたとする。これに対し、顧客C01が注文したAコースは、前菜の後にメイン料理を提供することになっている(図14参照)。したがって、制御部770は、コースメニューがまだ終了していないと判断する。一方、図15(A)に示すように、顧客C01が、デザートを食べ終えていた場合には、顧客C01が注文したAコースは、デザートが最後に提供される料理であるため(図14参照)、制御部770は、コースメニューが終了したと判断する。
ステップS420の判断が否定された場合、すなわち、コースメニューがまだ終了していない場合には、制御部770は、ステップS422において、表示部750や、スピーカ760を用いて、顧客に次の料理を提供するよう従業員に報知する。例えば、Aコースは、前菜の後にメイン料理を提供することになっているため(図14)、図13(D)のように前菜を食べ終えている顧客C01に、メイン料理を提供するよう従業員に報知する。これにより、従業員は、適切なタイミングで顧客に次の料理を提供することができる。なお、ステップS422において従業員に対し、次の料理を提供するよう報知した段階で、制御部770は、食事情報テーブルの「料理名」の項目に、ステップS422で報知した料理の名前を登録する。例えば、制御部770は、ステップS422においてメイン料理の提供を従業員に報知した場合、食事情報テーブルの「料理名」の項目に、“メイン”を登録する(図15(B)参照)。
ステップS422の処理の後は、制御部770は、ステップS410に戻り、ステップS410以降の処理を実行する。
一方、ステップS420の判断が肯定された場合、すなわち、コースメニューが終了した場合には、制御部770は、ステップS424において、カレンダ部740から日時情報を取得し、食事情報テーブルの「食事終了日時」の項目を更新する(図15(C)参照)。そして、制御部770は、ステップS426に移行する。
ところで、ステップS406において、顧客がコースメニューを注文しなかった場合、すなわち、単品の料理が複数注文された場合、制御部770は、ステップS428において、顧客が注文したメニューの情報(オーダ情報)(POS端末等から店舗端末70に入力される)を取得する。
その後は、制御部770は、ステップS430〜S438の処理を、前述したステップS410〜S418と同様に実行する。そして、ステップS438の判断が肯定された段階で、ステップS440に移行し、制御部770は、顧客が注文した料理を全て提供したか否か判断する。なお、全ての料理が提供されたか否かは、ステップS428で取得したオーダ情報と、検出部11の検出値とに基づいて判断することができる。この判断が否定された場合、すなわち、全ての料理の提供がまだ終わっていない場合には、制御部770は、ステップS442において、未だ提供していない料理(例えば食後のコーヒーやデザートなど)を提供するよう従業員に報知する。これにより、従業員は、適切なタイミングで顧客に料理を提供することができる。なお、制御部770は、ステップS442の処理の後は、ステップS430に戻る。
そして、全ての料理が提供された場合、すなわち、ステップS440の判断が肯定された場合には、制御部770は、ステップS424において、カレンダ部740から日時情報を取得し、食事情報テーブルの「食事終了日時」の項目を更新する。そして、制御部770は、ステップS426に移行する。
ステップS426に移行すると、制御部770は、各顧客の食事情報データを分析する。ここでは、一例として、制御部770は、図16(A)のメニュー情報(図14(A)と同様)と、図16(B)の食事情報テーブルとに基づき、未摂取食品情報(図16(C))を抽出する。図16(A)に示すメニュー情報は、各料理で使用されている食品の情報を含んでいる。したがって、食事情報テーブルが格納する顧客が各料理で摂取した食品と、メニュー情報において各料理で使用されている食品とを比較することで、制御部770は、未摂取食品情報を顧客ごとに抽出することが可能である。これにより、顧客が摂取しなかった食品に関するデータを取得することができるので、店舗の従業員等は、当該データをメニュー開発等に役立てることができる。
なお、制御部770は、顧客が食品を摂取しなかった理由を分析して、図16(C)に示す未摂取食品情報に記録するようにしてもよい。例えば、顧客が摂取しなかった食品が、コースメニューの第1品目に含まれる食品であれば、制御部770は、顧客が食品を摂取しなかった理由が、「顧客がその食品が苦手」であるためと判断し、未摂取食品情報に記録する。また、顧客がコースメニューの終盤で食品を摂取せず、その後もほとんど料理を口にしなかった場合であれば、制御部770は、顧客が食品を摂取しなかった理由は、「満腹であった」ためと判断し、未摂取食品情報に記録する。このように、未摂取の理由を記録することで、顧客属性と未摂取の理由とから、料理の量の適否等を推測することも可能となる。例えば、40代女性の顧客が「満腹であった」ため、メイン料理に含まれる食品を残したような場合には、コースメニューの量が多すぎると推測できる。これにより、未摂取食品情報を、メニュー開発等にさらに有効に活用することが可能となる。
なお、上記ステップS426の処理が実行された後は、制御部770は、図12の全処理を終了する。
以上、詳細に説明したように、本第2の実施形態によれば、店舗端末70は、ユーザが保持する食器1に設けられ食品に関するデータを検出する検出部11から、ユーザを介した人体通信によって、該食品に関するデータを取得する通信部710と、取得した当該食品に関するデータに基づいて、顧客の食事に関するデータ(食事情報データ)を記憶するメモリ部730と、を備えている。これにより、店舗端末70は、顧客や従業員に特別な操作を強いることなく、顧客の食に関する行動を自動的に記録することができる。
また、本第2の実施形態では、メモリ部730は、食品毎の抵抗値を食品情報テーブルに記憶しており、制御部770が、検出部11が検出した食品の抵抗値と、食品情報テーブルとを比較するので、顧客が口にした食品を特定することができる。
また、本第2の実施形態では、制御部770は、メニュー情報及び食事情報テーブルに基づいて、顧客が残した食品をメモリ部730に記憶する。これにより、顧客が残した食品に関するデータを蓄積することができるので、レストランの経営者や従業員等は、当該データを調理方法の検討や、メニュー開発等に活用することが可能となる。
また、本第2の実施形態では、制御部770は、食事情報データに基づいて、顧客に食事を提供するタイミングを決定するので、レストランの従業員は、適切なタイミングで顧客に食事を提供できる。この場合において、本第2の実施形態では、店舗端末70は、食事データに基づいて、顧客に食事を提供するタイミングを報知する表示部750やスピーカ760を備えているので、従業員は顧客に食事を提供する適切なタイミングを知ることができる。
また、本第2の実施形態では、店舗端末70は、食器用機器10との人体通信に基づいて、日時情報の取得や計時を行うカレンダ部740を備えているので、顧客が食事にかけた時間等を蓄積することができる。なお、メニュー毎に食事にかかる時間を食事情報テーブルに格納しておき、分析を行うこととしてもよい。また、店舗の回転率や混雑時の待ち時間等の計算を行うために、蓄積したデータを活用することとしてもよい。
また、本第2の実施形態では、店舗端末70は、通信部710が、顧客を撮像する撮像ユニット80から取得した顧客の撮像データに基づいて、顧客の属性を検出する画像解析部720を備えているので、顧客の属性と、食に関する行動とを関連づけることができるため、顧客属性別のメニューの開発や、料理の量の検討等、食事情報データの活用の幅が広がる。
また、本第2の実施形態では、検出部11は、顧客の手と接触し、通信部710は、顧客の足と接触する床電極部610を介した人体通信により、検出部11から食品に関するデータを入力するので、顧客に意識させることなく、食事情報データの取得が可能となる。
また、本第2の実施形態では、食器用機器10は、食品と接触し、食品の抵抗値を検出する検出部11と、検出部11が検出した抵抗値を、外部機器に送信する人体通信部13とを備えている。これにより、顧客や従業員に特別な操作を強いることなく、食器用機器10が設けられた食器1を使用して顧客が口にした食品に関する情報を店舗端末70に送信し、顧客の食に関する行動を記録することができる。
なお、上記第2の実施形態では、フロア用機器60を用いて人体通信を行う場合について説明したが、これに限らず、フロア用機器60に代えて、フロア用機器60と同一の構成の機器を椅子の座板等に設けることとしてもよい。また、人体通信ではなく近接通信を用いる場合には、前述の椅子に加え、テーブルや、壁なども利用することができる。
なお、上記第2の実施形態では、食器用機器は、検出部11が検出した抵抗値をフロア用機器60に送信していたが、これに限られるものではない。食器用機器10が備えるメモリ14が、食品とその抵抗値とを関連付けた食品情報テーブル(図3(A))を記憶し、制御部770が、検出部11が検出した抵抗値と、メモリ14が記憶している食品情報テーブルのデータとを比較し、人体通信部13は、比較によって特定された食品を送信してもよい。これにより、顧客や従業員に特別な操作を強いることなく、店舗端末70は、顧客が口にした食品の情報を取得でき、顧客の食に関する行動を記録することが可能となる。
なお、上記第2の実施形態は、コースまたはアラカルト形式で料理を提供している店舗での利用例について説明したが、ブッフェ形式で料理を提供する店舗にも第2の実施形態を適用することができる。以下、ブッフェ形式で料理を提供する店舗における例について説明する。
(ブッフェ形式で料理を提供する店舗における例(変形例))
図17は、レストランがブッフェ形式で料理を提供している場合に、制御部770が実行する処理の一例を示すフローチャートである。なお、ブッフェ形式の場合、食器用機器10A,10Bは、例えば、大皿に盛られた料理を取り分けるための食器1(例えば、トング、菜箸、お玉等)に設けられるものとし、どの食器1が、どの料理の取り分けに用いられるかが定まっているものとする。また、食器用機器10A,10Bの検出部11は、食器1で保持した料理の重量を直接的又は間接的に検出することが可能なセンサであるものとする。
図17の処理では、まず、ステップS500において、制御部770は、食器用機器10との人体通信が成立したか否かを判断する。このステップS500の処理では、顧客が、大皿に盛られた料理を取り分けるために、食器1に接触したか否かを判断している。ステップS500の判断が否定された場合、すなわち、食器用機器10との人体通信が成立していない場合には、制御部770は、人体通信が成立するまで、ステップS500の処理を繰り返す。そして、食器用機器10との人体通信が成立した段階で、ステップS500の判断が肯定され、制御部770は、ステップS502に移行する。
ステップS502に移行すると、制御部770は、食器用機器10の検出部11による検出結果(本実施形態では、食器1で保持した料理の重量)を取得する。なお、制御部770は食器用機器10の識別子も取得するものとする。これにより、制御部770は、顧客がどの料理をどのくらいの量だけ取り分けたのかを認識することができる。
次いで、ステップS504では、制御部770が、ステップS502で取得した検出結果(料理の重量)と、過去に同一の食器1で保持した料理の重量とを合計(積算)する。
次のステップS506で、制御部770は、ステップS504において特定された料理について、料理を補充する条件が満たされたか否か判断する。具体的には、制御部770は、同一の料理の取り分け量(ステップS504の積算値)が料理ごとに予め定められている閾値を超えた場合に、料理を補充する条件が満たされたと判断する。
ステップS506の判断が肯定された場合、すなわち、料理を補充する条件が満たされた場合、制御部770は、ステップS508において、従業員の料理の補充が必要であることを報知する。これにより、従業員は、適切なタイミングで料理を補充することができ、顧客が食べたい料理が補充されていないという状況を防ぐことができる。なお、ステップS508の後は、制御部770は、ステップS500に戻る。なお、レストランの従業員は、料理を補充した後に、その旨を店舗端末70に入力することとしてもよい。制御部770は、当該入力があった段階で、補充された料理の取り分け量の積算値をリセットすることとしてもよい。また、制御部770は、ステップS508において報知した後に、補充された料理の取り分け量の積算値をリセットすることとしてもよい。
一方、ステップS506の判断が否定された場合、すなわち、料理を補充する条件が満たされていない場合には、制御部770は、ステップS500からの処理を再び実行する。
このように、レストランがブッフェ形式で料理を提供している場合にも、店舗端末70の制御部770は、食器用機器10から顧客が取り分けた料理の重量を取得するので、当該重量に基づいて、料理を補充するタイミング等を決定することができる。なお、制御部770は、顧客が料理を取り分けた量や回数を料理ごとにメモリ部730に記憶してもよい。また、営業時間終了後に、制御部770は、顧客があまり取り分けなかった料理の情報を「未選択料理情報」としてメモリ部730に記憶するようにしてもよい。これにより、顧客の料理を取り分ける行動の履歴データを蓄積することが可能となり、人気の高い料理や、人気のない料理の分析や、顧客が最初に食べる傾向のある料理(例えば、ボリュームのある肉料理、脂っこい料理)、最後のほうに食べる傾向のある料理(例えば、果物やケーキなどのデザート)の分析等を行うことが可能となる。さらに、レストランの経営者や従業員は、分析結果に基づいて、メニュー構成や作る順番や食品の仕入れ量等を検討することが可能となる。
なお、上記変形例では、制御部770が、取り分けた料理の重量を取得する場合について説明したが、これに限らず、制御部770は、料理を取り分けた回数を取得することとしてもよい。この場合、制御部770は、ステップS506において、料理を取り分けた回数の合計が予め定められている閾値を超えた場合に料理を補充する条件が満たされたと判断することとしてもよい。
《第3の実施形態》
次に、第3の実施形態について説明する。
図18は、第3の実施形態に係る電子機器システム1000Cを示すブロック図である。図18に示すように、電子機器システム1000Cは、食器用機器10A,10Bと、携帯端末30と、店舗端末70と、を備える。なお、食器用機器10A,10Bは、上記第1、第2の実施形態と同様となっている。
携帯端末30では、制御部322がフラッシュメモリ308に記憶されている食事履歴データ(図20(A))を、無線通信部304を介して、店舗端末70に送信するが、携帯端末30のその他の構成等については、上記第1の実施形態と同様となっている。なお、図20(A)の食事履歴データは、第1の実施形態の食事履歴テーブルと同様の方法で蓄積され、フラッシュメモリ308に蓄積されているものとする。
店舗端末70では、制御部770が無線通信部304を介して店を訪れた顧客の食事履歴データを取得するとともに、店舗のメニューと、顧客の食事履歴データとを比較し、携帯端末30のユーザに対して、ユーザに適したメニューを提案するが、店舗端末70のその他の構成等については、上記第2の実施形態と同様となっている。
ここで、制御部770が実行するメニューの提案処理について、図19のフローチャートに沿って説明する。なお、図19の処理が行われる前提として、携帯端末30のユーザが、食事をするためにレストランなどの店舗に入店しようとしているものとする。
図19の処理では、まず、ステップS700において、制御部770は、携帯端末30のフラッシュメモリ308に記憶されている食事履歴データ(図20(A))を取得する。なお、ステップS700の処理は、店舗内に入った携帯端末30から店舗端末70に対して食事履歴データが送られてきた段階で実行することとすればよい。なお、携帯端末30の制御部322は、位置情報(GPSモジュール306から取得できる)に基づいて、顧客が店舗に入ったことを検出した段階で、店舗端末70に対して食事履歴データを送信するようにすればよい。
次のステップS702では、制御部770が、メモリ部730に記憶されているメニュー情報(図20(B))を取得する。
次いで、ステップS704では、制御部770が、店舗が提供するメニューの中から顧客が好みそうなメニューを顧客に対して提案する。ここでは、制御部770は、ステップS700で取得した食事履歴データに基づいて携帯端末30の顧客の好き・嫌いを分析し、メニュー情報の中から、顧客が好みそうなメニューを提案する。例えば、図20(A)に示す食事履歴データを取得した場合、ハンバーグや生姜焼きといった肉料理が多いことから、制御部770は、顧客が「肉料理が好きである」と分析する。そして、図20(B)に示すメニュー情報の中から、肉料理を含むメニューを選択し、顧客に提案する。図20(B)に示すメニュー情報において、肉料理を含むメニューは、“Aコース”及び“肉料理A”である。したがって、制御部770は、顧客に提案すべきメニューを、例えば、図20(C)に示すように、表示部750上に表示する。これにより、従業員は、初めて来店した顧客であっても、顧客に適したメニューを提案することができる。なお、制御部770は、従業員が使用するオーダー用の端末(POS端末)に表示させてもよい。以上の処理により、図19の全処理が終了する。
なお、制御部770は、普段肉料理が多い顧客であれば、栄養バランスを考慮して、肉料理とは異なる料理(魚料理や野菜料理)を提案するようにしてもよい。制御部770がいずれの提案を行うかは、携帯端末30のユーザが設定してもよい。
以上、詳細に説明したように、第3の実施形態によれば、制御部770が、メニュー情報と、顧客の食事履歴データとに基づいて、顧客に適したメニューを提案するので、初めて来店した顧客にも、顧客の嗜好を反映したメニューを提案することができる。
なお、上記第3の実施形態では、携帯端末30のフラッシュメモリ308は食事履歴データだけでなく、例えば、ユーザのアレルギー食材等を記憶するようにしてもよい。この場合、アレルギー食材のデータを店舗端末70に送信することにより、例えば、ユーザは、アレルギー食材を含まないメニューの提案を受けたり、あるいは、アレルギー食材を除いた料理の提供を受けることができる。
なお、上記第3の実施形態では、制御部770が、店舗の従業員に対して顧客に適したメニューを提案する場合について説明したが、これに限らず、制御部770は、顧客に対して適したメニューを提案することとしてもよい。例えば、制御部770は、顧客の携帯端末に対して適したメニューを送信することとしてもよいし、顧客が操作可能なメニュー選択用の機器(テーブルに設置されている)に対して表示することとしてもよい。
《第4の実施形態》
次に、第4の実施形態について説明する。第4の実施形態は、ユーザの食の嗜好に基づいて、ユーザに適した店舗を紹介するものである。
図21には、第4の実施形態に係る電子機器システム1000Dがブロック図にて示されている。図21に示すように、電子機器システム1000Dは、携帯端末30,40と、サーバ90と、ネットワーク100と、を備える。
(携帯端末30,40)
携帯端末30,40の構成及び機能は、第1〜第3の実施形態と同様であるが、フラッシュメモリ308が、ユーザの食の嗜好に関する情報を記憶する点、無線通信部304が、ネットワーク100を介して、ユーザの食の嗜好に関する情報を、サーバ90に送信する点が異なっている。なお、ユーザの食の嗜好に関する情報は、例えば、ユーザがタッチパネル312を用いて、携帯端末30に入力してもよいし、第1の実施形態において説明したフラッシュメモリ308に記憶されている食事履歴データに基づいて、制御部322が分析してもよい。
(サーバ90)
サーバ90は、図21に示すように、通信部910と、制御部920と、記憶部930と、を有する。
通信部910は、ネットワーク100を介して、携帯端末30,40と通信するためのものである。記憶部930は、不揮発性の半導体メモリ(フラッシュメモリ)や、ハードディスクドライブであり、レストラン等の店舗に関する情報を記憶する。また、記憶部930は、携帯端末30,40から送信された各ユーザの食の嗜好に関する情報を記憶する。制御部920は、CPUを有し、サーバ90全体を制御する。また、制御部920は、通信部910を介して、ユーザの食の嗜好に関する情報を取得し、記憶部930に記憶する。また、制御部920は、記憶部930に記憶されている店舗に関する情報と、ユーザの食の嗜好に関する情報とを比較して、ユーザに適した店舗をユーザに紹介する(ユーザに適した店舗の情報を携帯端末30,40に対して送信する)。
以下、サーバ90の制御部920が実行する処理について、図22のフローチャートを用いて具体的に説明する。ここでは、携帯端末30のユーザXと、携帯端末40のユーザYとが一緒に食事に行くために、携帯端末30,40をそれぞれ操作して自身の食の嗜好に関する情報をサーバ90に送信するものとする。
図21の処理では、まず、ステップS600において、制御部920は、携帯端末から食の嗜好に関する情報(以下、「嗜好データ」と呼ぶ)を受信したか否か判断する。ここでの判断が否定された場合、すなわち、携帯端末30,40から嗜好データを受信していない場合には、制御部920は、嗜好データを受信するまでステップS600の処理を繰り返す。そして、嗜好データを受信した段階で、ステップS600の判断が肯定され、制御部920は、ステップS602に移行する。なお、ユーザXとユーザYは、サーバ90に対して同一のIDやパスワードでログインするなどすることで、一緒に食事をするメンバーであることを制御部920に認識させることができる。
ステップS602に移行すると、制御部920は、受信した嗜好データを分析する。また、ステップS604では、制御部920は、分析結果に基づいて、提案する店舗を決定する。例えば、携帯端末30から図23(A)に示すユーザXの嗜好データを受信し、携帯端末40から図23(B)に示すユーザYの嗜好データを受信したとする。この場合、制御部920は、ユーザYが鶏肉を好きなため、ユーザXが好きな焼き鳥を、ユーザYも好きである可能性が高いとして、図23(C)に示す店舗情報テーブルの中から、“焼き鳥”に「分類」されている店舗“O”を提案する。第4の実施形態の電子機器システム1000Dは、ユーザXと、ユーザYとが初対面であったり、互いに遠慮するような間柄の場合に、サーバ90が店舗情報を提供してくれるので、ユーザXおよびユーザYにとって使い勝手のよいシステムとなっている。
なお、上述のステップS602において、嗜好データを分析する場合、制御部920は、各携帯端末から受信した嗜好データに重み付けをしてもよい。例えば、ユーザXとユーザYとで好みが全く一致しない場合に、ユーザXの嗜好データに重みを付け(ユーザXの嗜好データを重視して)、店舗を提案してもよい。この場合、いずれかのユーザにどのユーザの嗜好を優先させるかを入力させてもよいし、各ユーザの上下関係(上司−部下の関係)を入力させ、当該上下関係に基づいて制御部920がどのユーザの嗜好を優先させるかを決定してもよい。更には、複数の携帯端末の配列状態に応じて、どのユーザの嗜好を優先させるかを決定してもよい。例えば、図24に示すように携帯端末が配列された状態で、嗜好データが各携帯端末から送信された場合には、制御部920は、一番上に配置されている携帯端末30から送信された嗜好データを、携帯端末40から送信された嗜好データよりも重視して店舗の提案を行うことができる。これにより、複数の携帯端末の配列を変えれば、重み付けされる嗜好データを容易に変更することができるため、ユーザに重み付けに関する情報を入力させる必要がなくなり、ユーザの利便性も向上する。なお、携帯端末の配列情報は、各携帯端末が有する各種センサ(重量センサや撮像部、光量センサ、接触センサなど)を用いて検出することができる。
図22に戻り、ステップS606では、制御部920は、ステップS604において決定した店舗情報を携帯端末30,40に送信し、図22の全処理を終了する。本処理により、店舗情報を受信したユーザX、Yは、両者の好みに共通した店舗の提案を受けることができる。なお、上記においては、2人のユーザが嗜好データを送信する場合について説明したが、3人以上のユーザが嗜好データを送信してもよいし、1人のユーザのみが嗜好データを送信することとしてもよい。また。制御部920は、店舗の情報を、ユーザの一部にのみ通知することとしてもよい。この場合、ユーザ間で幹事設定されたユーザに対してのみ店舗の情報を通知することとしてもよい。また、ユーザが予算や店舗の好み(和食、洋食、テーブル席、座敷など)を設定した場合には、予算や好みも加味して、店舗を提案することとしてもよい。
以上、詳細に説明したように、第4の実施形態によれば、サーバ90は、少なくとも一人のユーザの携帯端末と通信可能な通信部910と、通信部910を介して、少なくとも一人のユーザの食の嗜好に関する情報(嗜好データ)を、前記ユーザの携帯端末から入力する制御部920と、備えている。これにより、サーバ90は、携帯端末のユーザの食の嗜好に関する情報を取得することができる。また、サーバ90は、店舗に関する情報を記憶する記憶部930を備えており、制御部920は、ユーザの食の嗜好に関する情報と、店舗に関する情報を比較するので、制御部920は、ユーザの食の嗜好にあった店舗をユーザに対して提案することができる。
また、本第4の実施形態においては、制御部920が、ユーザの食の嗜好に関する情報に重み付けを行うので、複数のユーザの嗜好を全て反映した店舗の提案が難しい場合に、重視すべきユーザ(例えば、お客様や上司)の嗜好を反映した店舗を提案することができる。
なお、上記第4の実施形態では、記憶部930が店舗情報を記憶する場合について説明したが、これに限られるものではなく、記憶部930は、料理に関する情報を記憶してもよい。この場合、制御部920は、各ユーザの食の嗜好を反映した料理を提案することができる。また、制御部920は、ユーザの少なくとも1人がアレルギー体質である場合には、アレルギー食材を含まない料理を提案することとしてもよい。
また、上記第4の実施形態では、記憶部930は、携帯端末から送信されたユーザの嗜好データを記憶してもよい。これにより、ユーザは、店舗の提案を受けようとするたびに、自身の嗜好データを送信する必要がなくなり、ユーザの利便性が向上する。
なお、上記第4の実施形態では、携帯端末30,40のユーザX,Yが、店舗の提案を受けるために、自身の嗜好データを送信する処理を行っていたが、これに限られるものではない。制御部920は、所定のタイミングで所定の外力を加えられた携帯端末から、ユーザの嗜好データを取得するようにしてもよい。例えば、特定のアプリケーションを起動した状態の複数の携帯端末同士をユーザが乾杯するようにぶつけあった場合に、ぶつかりあった携帯電話の制御部322がサーバ90の制御部920に対してユーザの嗜好データを送信するするようにしてもよい。これにより、ユーザの利便性を向上することができる。
上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。