JP2014123215A - 電子機器 - Google Patents

Abstract

【課題】ユーザの食に関する嗜好を反映した店舗を提案可能な電子機器を提供する。
【解決手段】電子機器は、少なくとも一人のユーザの携帯端末と通信可能な通信部（９１０）と、前記通信部を介して、前記少なくとも一人のユーザの食の嗜好に関する情報を、前記複数のユーザの携帯端末から入力する入力部（９２０）と、を備えている。
【選択図】図２１

Description

本発明は、電子機器に関する。

従来より、ユーザと店とをマッチングするシステムが提案されている（特許文献１参照）。

特開２０１２−９９０９５号公報

しかしながら、従来のシステムでは、提案される店舗が、ユーザの食に関する嗜好を十分に反映したものではない場合があった。

本発明は上記の課題に鑑みてなされたものであり、ユーザの食に関する嗜好を反映した店舗を提案可能な電子機器を提供することを目的とする。

本発明の電子機器（９０）は、少なくとも一人のユーザの携帯端末と通信可能な通信部（９１０）と、前記通信部を介して、前記少なくとも一人のユーザの食の嗜好に関する情報を、前記少なくとも一人のユーザの携帯端末から入力する入力部（９２０）と、を備えている。

また、本発明の電子機器は、食に関する情報を記憶する第１記憶部（９３０）と、前記入力部が入力した情報と、前記第１記憶部が記憶している情報とを比較する比較部（９２０）と、を備えていてもよい。この場合において、前記比較部は、前記入力部が入力した情報に重み付けを行うこととしてもよい。また、この場合において、前記重み付けは、前記食の嗜好に関する情報を送信するユーザの携帯端末の配列状態に応じて行われることとしてもよい。また、前記第１記憶部が記憶している情報は、料理に関する情報であることとしてもよいし、店舗に関する情報であることとしてもよい。

また、本発明の電子機器は、前記入力部が入力した情報を記憶する第２記憶部（９３０）を備えていてもよい。この場合において、前記第２記憶部は、複数のユーザの食の嗜好に関する情報を記憶し、前記第２記憶部から、少なくとも一人のユーザの食の嗜好に関する情報を選択する選択部（９２０）を備えることとしてもよい。

また、本発明では、前記選択部は、所定のタイミングで所定の外力を加えられた携帯端末を所有するユーザの食の嗜好に関する情報を、前記第２記憶部から選択することとしてもよい。また、本発明では、前記入力部は、所定のタイミングで所定の外力を加えられた携帯端末から、前記携帯端末を所有するユーザの食の嗜好に関する情報を入力することとしてもよい。

なお、本発明をわかりやすく説明するために、上記においては一実施形態を表す図面の符号に対応つけて説明したが、本発明は、これに限定されるものではなく、後述の実施形態の構成を適宜改良しても良く、また、少なくとも一部を他の構成物に代替させても良い。更に、その配置について特に限定のない構成要件は、実施形態で開示した配置に限らず、その機能を達成できる位置に配置することができる。

本発明の電子機器は、ユーザの食に関する嗜好を反映した店舗を提案することができるという効果を奏する。

第１の実施形態に係る電子機器システムの構成を示す図である。 第１の実施形態に係る電子機器システムを利用している状況を示す図である。 図３（Ａ）は食品情報テーブルの一例を示す図であり、図３（Ｂ）は食事履歴テーブルの一例を示す図である。 携帯端末の制御部が実行する食事履歴データの蓄積処理の一例を示すフローチャートである。 図５（Ａ）〜図５（Ｃ）は、図４の食事履歴データの蓄積処理を説明するための図である。 図６（Ａ）は、食事履歴データの表示例を示す図であり、図６（Ｂ）は、食事に関するアドバイスの表示例を示す図である。 メニュー提案処理の一例を示すフローチャートである。 図８（Ａ）は食品の問い合わせ処理の一例を示すフローチャートであり、図８（Ｂ）は食品の問い合わせに対する応答処理の一例を示すフローチャートである。 第２の実施形態に係る電子機器システムの構成を示す図である。 第２の実施形態に係る電子機器システムを利用している状況を示す図である。 食事情報テーブルの登録処理の一例を示すフローチャートである。 食事情報テーブルへの、食事情報データの蓄積処理の一例を示すフローチャートである。 図１３（Ａ）〜図１３（Ｄ）は、図１２の食事情報データの蓄積処理を説明するための図である。 メニュー情報の一例を示す図である。 図１５（Ａ）〜図１５（Ｃ）は、図１２の食事情報データの蓄積処理を説明するための図である。 図１６（Ａ）〜図１６（Ｃ）は、食事情報データの分析処理を説明するための図である。 ブッフェ形式の場合に、店舗端末の制御部が実行する処理の一例を示すフローチャートである。 第３の実施形態に係る電子機器システムの構成を示す図である。 店舗端末の制御部が実行するメニュー提案処理の一例を示すフローチャートである。 図２０（Ａ）〜図２０（Ｃ）は、図１９のメニュー提案処理を説明するための図である。 第４の実施形態に係る電子機器システムの構成を示す図である。 サーバの制御部が実行する店舗の提案処理の一例を示すフローチャートである。 図２３（Ａ）〜図２３（Ｃ）は、図２２の店舗の提案処理を説明するための図である。 複数の携帯端末の配置の一例を示す図である。

《第１の実施形態》
以下、第１の実施形態について、図１〜図８に基づいて、詳細に説明する。図１には、第１の実施形態にかかる電子機器システム１０００Ａの構成がブロック図にて示されている。また、図２には、電子機器システム１０００Ａを利用している状況が示されている。

電子機器システム１０００Ａは、ユーザが食事を行うときに利用するシステムである。電子機器システム１０００Ａは、図１、図２に示すように、例えば、箸、スプーン、フォーク等の食器１にそれぞれ設けられる食器用機器１０Ａ，１０Ｂと、携帯端末３０，４０，５０と、を備える。なお、本実施形態では、父親が食器用機器１０Ａと携帯端末３０とを使用し、子供が食器用機器１０Ｂと携帯端末４０とを使用し、母親が携帯端末５０を使用するものとする。

（食器用機器１０Ａ，１０Ｂ）
食器用機器１０Ａ，１０Ｂは同一の構成を有するため、以後、特に区別する必要のない限り、食器用機器１０Ａ，１０Ｂを食器用機器１０と記載し説明を行う。図１に示すように、食器用機器１０は、検出部１１、電極部１２、人体通信部１３、メモリ１４、および制御部１５を有する。

検出部１１は、食器１に接触した食品に関する情報を検出し、制御部１５に出力する。本実施形態では、検出部１１は、食品と接触する部分（例えば、フォークの先端）に設けられた電極と、ユーザの人体と接触する部分（例えば、フォークの持ち手）に設けられた電極とを備え、「食品→口→人体」の間の抵抗値を検出し、出力する。

電極部１２は、信号電極とグラウンド電極とを有し、ユーザを介して携帯端末３０と人体通信を行うための電極である。この電極部１２は、食器１内でユーザの身体と接触しやすい場所に設けられる。例えば、電極部１２は、接触するユーザの手に触れやすいように、図２に示すように、食器１の持ち手部分に設けられる。

人体通信部１３は、バンドパスフィルタを有した電気回路から構成される送信部を有し、送信するデータを変調して送信信号を生成する。なお、人体通信部に受信機能を持たせるようにしてもよい。本実施形態においては、人体通信部１３は、検出部１１が検出した、食器１に接触した食品に関する情報（ユーザが食品を口にした場合の抵抗値）を携帯端末３０に送信する。なお、以下の実施形態において、人体通信に変えて、Ｂｌｕｅｔｏｏｔｈ（登録商標）や、ＲＦＩＤ（Radio Frequency Identification）であるＦｅｌｉＣａ（登録商標）モジュールや、ＴｒａｎｓｆｅｒＪｅｔ（登録商標）等の近接通信を適用することも可能である。

メモリ１４は、不揮発性の半導体メモリ（例えば、フラッシュメモリ）である。

制御部１５は、ＣＰＵ（Central Processing Unit）を備え、食器用機器１０全体を制御するものである。本実施形態においては、制御部１５は、検出部１１が検出した各食品の抵抗値を携帯端末３０に送信する制御を行う。

（携帯端末３０，４０）
携帯端末３０，４０は、ユーザにより携帯された状態で利用される情報機器である。携帯端末３０，４０としては、携帯電話、スマートフォン、ＰＨＳ（Personal Handy-phone System）、ＰＤＡ（Personal Digital Assistant）等を採用することができるが、本実施形態では、携帯端末３０，４０は、スマートフォンであるものとする。また、本実施形態においては、携帯端末３０，４０は、電話機能やインターネット等に接続するための通信機能、および、プログラムを実行するためのデータ処理機能等を有する。なお、本実施形態において、携帯端末３０，４０は、同一の構成を有するため、代表して携帯端末３０について説明する。

携帯端末３０は、電極部３００、人体通信部３０２，無線通信部３０４、ＧＰＳ（Global Positioning System）モジュール３０６、フラッシュメモリ３０８、表示部３１０、タッチパネル３１２、マイク３１４、スピーカ３１６、撮像部３１８、カレンダ部３２０および制御部３２２を有する。

電極部３００は、信号電極とグラウンド電極とを有し、ユーザを介して食器用機器１０と人体通信を行うための電極である。

人体通信部３０２は、バンドパスフィルタを有した電気回路から構成される送受信部を有し、入力した受信信号を復調して受信データを生成する一方、送信するデータを変調して送信信号を生成する。人体通信には、人体に微弱な電流を流して、その電流を変調して情報を伝達する電流方式や、人体の表面に誘起する電界を変調して情報を伝達する電界方式などがあり、電界方式の場合は、ユーザが電極部３００に直接触れていなくても人体通信が可能である。このため、本実施形態では、ユーザがポケット（例えば胸ポケット）に携帯端末３０を入れておいた場合でも人体通信が成立するように、電界方式が用いられているものとする。なお、携帯端末３０もしくは４０を所持するユーザが女性の場合には、携帯端末３０（４０）をポケットではなく、ポシェットなどの鞄に収納する場合があり、このような場合は近接通信を利用するのが好ましい。

無線通信部３０４は、外部機器と通信するためのものであり、各種の無線通信を適用可能である。本実施形態においては、無線通信部３０４は、携帯端末５０に対して携帯端末３０のユーザの食事に関するデータを送信するものである。

ＧＰＳモジュール３０６は、携帯端末３０の位置（例えば緯度および経度）を検出するセンサである。

フラッシュメモリ３０８は、不揮発性の半導体メモリであり、制御部３２２によって実行される携帯端末３０を制御するためのプログラム、および、携帯端末３０を制御するための各種パラメータを記憶する。また、フラッシュメモリ３０８は、食品毎の抵抗値を格納する食品情報テーブルと、ユーザの食事に関するデータ（食事履歴データ）を格納する食事履歴テーブルと、を記憶する。ここで、食品情報テーブル及び食事履歴テーブルについて説明する。

図３（Ａ）は、食品情報テーブルの一例を示す図であり、図３（Ｂ）は、食事履歴テーブルの一例を示す図である。

図３（Ａ）に示すように、食品情報テーブルは、「食品名」および「抵抗値」の項目を有する。「食品名」の項目には、食品の名称が入力され、「抵抗値」の項目には、食品の抵抗値（予め計測され、登録されている抵抗値）とユーザの抵抗値（食品を保持していない食器１をユーザに咥えさせた状態で検出部１１が検出する抵抗値）との合計値、すなわち、ユーザが食品を口にした場合に検出部１１が検出するであろう抵抗値、が入力されている。なお、携帯端末３０のユーザ（父親）と携帯端末４０のユーザ（子供）ではユーザ自身の抵抗値が異なるため、携帯端末３０，４０それぞれのフラッシュメモリ３０８に格納されている食品情報テーブルでは、同一の食品名であっても、その抵抗値は異なる値となる。

食事履歴テーブルは、図３（Ｂ）に示すように、「開始日時」と、「終了日時」と、「順番」と、「食品名」と、を項目として備える。

「開始日時」の項目は、ユーザ（父親、子供）が食事を開始した日時を格納する。「終了日時」の項目は、ユーザ（父親、子供）が食事を終了した日時を格納する。「順番」の項目は、当該食事において、食べた食品の順番を一意に識別するための番号を格納する。「食品名」の項目は、各順番において、ユーザ（父親、子供）が食べた食品の名前を格納する。図３（Ｂ）が携帯端末３０のフラッシュメモリ３０８に格納されている食事履歴テーブルである場合には、父親が、２０１２年１１月６日の１１時５０分に食事を開始し、ハンバーグ→白米→ハンバーグ→人参→レタスの順に食べ、１２時に食事を終了したこと、が食事履歴テーブルに記録されていることになる。

図１に戻り、表示部３１０は、例えば液晶表示素子を用いたデバイスであり、携帯端末３０本体の所定面（以下、主面と呼ぶ）に設けられ、画像、各種情報およびボタン等の操作入力用画像を表示する。また、本実施形態においては、表示部３１０は、ユーザの食事履歴データを表示したり、食に関するアドバイスを表示する。

タッチパネル３１２は、ユーザが触れたことに応じて情報を入力する。タッチパネル３１２は、表示部３１０上または表示部３１０に組み込まれて設けられる。従って、タッチパネル３１２は、ユーザが表示部３１０の表面をタッチすることにより、種々の情報を入力する。

マイク３１４は、携帯端末３０本体の主面側の、表示部３１０の下方に設けられ、ユーザが電話機能を使用する際に口元に位置するようになっている。

スピーカ３１６は、携帯端末３０本体の主面側の、表示部３１０の上方に設けられ、ユーザが電話機能を使用する際に耳元に位置するようになっている。

撮像部３１８は、例えば、表示部３１０の上方でスピーカ３１６の近傍に設けられており、ユーザが携帯端末３０を保持している際（使用している際）のユーザの状況を撮像するものである。この撮像部３１８は、撮影レンズや、ＲＧＢベイヤー配列の撮像素子（ＣＣＤおよびＣＭＯＳデバイス）などから構成されている。なお、撮像部３１８を携帯端末３０の主面の反対側の面に設けてもよい。

カレンダ部３２０は、年、月、日、時刻といった時間情報を取得して、制御部３２２に出力する。なお、カレンダ部３２０に計時機能を持たせて、ユーザの食事にかかる時間を計測するようにしてもよい。

制御部３２２は、ＣＰＵを有し、携帯端末３０全体を制御する。本実施形態においては、制御部３２２は、ユーザの食事に関するデータの収集を行う。また、制御部３２２は、ユーザの食事に関するデータ（食事履歴テーブル（図３（Ｂ））に含まれるデータ）に基づいて、ユーザの食に関するアドバイスを生成して、表示部３１０に表示する。

（携帯端末５０）
携帯端末５０は、携帯端末３０，４０と同様の構成としてもよいが、図１に示すように、電極部や人体通信部を省略した構成としてもよい。ここでは、携帯端末５０の構成のうち、携帯端末３０，４０と異なる点についてのみ説明する。

無線通信部５０４は、外部機器と通信するためのものであり、各種の無線通信を適用可能である。本実施形態においては、無線通信部５０４は、無線通信部３０４との通信により、制御部３２２から、父親や子供の食事に関するデータを受信する。

フラッシュメモリ５０８は、例えば、不揮発性の半導体メモリであり、本実施形態では、無線通信部５０４が受信した父親や子供の食事に関するデータを記憶したり、地図情報や、各種プログラムを記憶する。

制御部５２２は、ＣＰＵを有し、携帯端末５０全体を制御する。本実施形態においては、制御部５２２は、父親や子供の食事に関するデータ（例えば、昼食において食べた食品の情報）を表示部５１０に表示したり、夕食のメニュー、食材、お店に関する情報を母親に提供する。

（食事履歴データの蓄積処理）
次に、図４〜図６を用いて、携帯端末３０の制御部３２２が実行する食事履歴データの蓄積処理の一例について説明する。図４は、制御部３２２が実行する、ユーザ（父親）の食事履歴データの蓄積処理の一例を示すフローチャートである。なお、前提として、父親は、社員食堂で昼食（メニューは、ご飯、味噌汁、サラダ、ハンバーグ）を食べようとしているものとする。

図４の処理では、まず、ステップＳ１０において、制御部３２２が、食器用機器１０との間で人体通信が成立したか否か判断する。このステップＳ１０では、ユーザ（父親）が食事を始めるために、図２に示すように食器１（図２ではフォーク）を手に取ったか否かを判断している。ここでの判断が否定された場合、すなわち、食器用機器１０との人体通信が成立していない場合には、制御部３２２は、ステップＳ１０の判断が肯定されるまでステップＳ１０の処理を繰り返す。ステップＳ１０の判断が肯定された段階、すなわち、食器用機器１０との人体通信が成立した段階で、制御部３２２は、ステップＳ１２に移行する。

ステップＳ１２に移行すると、制御部３２２は、ユーザ（父親）が食事を開始したとして、カレンダ部３２０から、日時情報を取得し、当該日時を、食事履歴テーブルの「開始日時」に登録する。例えば、父親が食事を始めるためにフォークを手にとることで、携帯端末３０と食器用機器１０との間で人体通信が成立すると（Ｓ１０／ＹＥＳ）、制御部３２２は、図５（Ａ）に示すように、食事履歴テーブルの「開始日時」にカレンダ部３２０から取得した日時を登録する。なお、カレンダ部３２０が計時機能を有する場合には、制御部３２２は、ステップＳ１２において、カレンダ部３２０を用いて計時を開始し、食事にかかる時間を計測してもよい。

次のステップＳ１４では、制御部３２２は、検出部１１の検出値に変化があったか否か判断する。このステップＳ１４では、ユーザ（父親）が新たな食品を口にしたか否かを判断している。ここでの判断が否定された場合、すなわち、検出部１１の検出値に変化がない場合には、制御部３２２は、ステップＳ１４の判断が肯定されるまで、ステップＳ１４の処理を繰り返す。そして、検出部１１の検出値に変化があった段階で、ステップＳ１４の判断は肯定され、制御部３２２は、ステップＳ１６に移行する。

ステップＳ１６に移行すると、制御部３２２は、検出部１１の検出結果を取得する。そして、次のステップＳ１８において、ユーザが食べた食品を特定し、ステップＳ２０において、フラッシュメモリ３０８が記憶する食事履歴テーブルに登録する。例えば、父親がハンバーグを口にした場合に、食器用機器１０の検出部１１が、抵抗値Ｄを検出したものとする。この場合、制御部３２２は、メモリ１４に格納された食品情報テーブル（図３（Ａ））と、検出部１１が検出した抵抗値Ｄとを比較し、父親が食べた食品がハンバーグであると特定し、図５（Ｂ）に示すように、食事履歴テーブルに父親が１番目に食べた食品として、“ハンバーグ”を登録する。

図４に戻り、次のステップＳ２２では、制御部３２２は、ユーザが食事を終了したか否か判断する。ユーザが食事を終了したか否かは、例えば、食器用機器１０との人体通信が成立しない時間が所定時間（例えば５〜１０分）続いたか否かによって判断してもよいし、あるいは、ＧＰＳモジュール３０６によって取得した携帯端末３０の位置が、社員食堂から所定距離離れたか否かによって判断してもよい。

ステップＳ２２の判断が否定された場合、すなわち、ユーザがまだ食事を終了していない場合、制御部３２２は、ステップＳ１４に戻り、ステップＳ１４〜Ｓ２０の処理を、ユーザ（父親）が食事を終えるまで繰り返す。これにより、図５（Ｃ）に示すようなユーザの食事履歴データを、ユーザに特別な操作を強いることなく自動的に蓄積することができる。なお、図５（Ｃ）からは、父親が、ハンバーグ、ご飯、ハンバーグ、サラダ、…、の順に口にしたことが分かる。

その後、ステップＳ２２の判断が肯定された場合、すなわち、父親が食事を終了した場合、制御部３２２は、ステップＳ２４に移行し、カレンダ部３２０から日時情報を取得し、当該日時を食事履歴テーブルの「終了日時」に登録する（図３（Ｂ）参照）。

次いで、ステップＳ２８では、制御部３２２は、食事履歴テーブル（図３（Ｂ））に記録されているデータに基づき、食事に関するデータや、アドバイスを生成して、表示部３１０に表示する。この場合、例えば、図６（Ａ）に示すように、制御部３２２は、食品を食べた順番や、食事にかかった時間を表示部３１０に表示することとしてもよい。あるいは、制御部３２２は、ユーザ（父親）が食事の最初に野菜（食物繊維）などの消化吸収に時間のかかるものを食べ、次いで汁物を食べ、その後に肉などのたんぱく質を食べ、最後にご飯（炭水化物）を食べたか（血糖値が上がりにくい食べ方をしているか）を判定し、図６（Ｂ）に示すように表示部３１０に判定結果を表示することとしてもよい。この場合、制御部３２２は、さらに、食べる順番に関するアドバイス（「最初に野菜を食べると血糖値低下に効果があります」などのアドバイス）を表示してもよい。また、制御部３２２は、食事にかかった時間に基づいて、早食い傾向であるか否かを表示部３１０に表示してもよい。また、制御部３２２は、フラッシュメモリ３０８に記憶されている食事履歴データに基づいて、例えば、肉食が続いているなどユーザの食事の傾向を表示部３１０に表示してもよい。

図４に戻り、制御部３２２は、ステップＳ３０において、今回の食事履歴データを、例えば、他のユーザが所持する携帯端末（例えば、母親が所有する携帯端末５０）や外部機器に送信し、本処理を終了する。これにより、食事履歴データを他者と共有したり、活用したりすることが可能となる。なお、制御部３２２は、ステップＳ３０において、表示部３１０に表示したデータのうちどれを誰に送信するかをタッチパネル３１２を用いてユーザ（父親）に選択させてもよい。また、ユーザに一度選択させた後は、データや送信先の選択を省略するようにしてもよい。

なお、上記においては、社員食堂での食事を例に採り説明したが、ユーザが家庭内やレストランで食器用機器１０が設けられた食器１を利用すれば、制御部３２２は、様々な場所での食事履歴データを取得することが可能である。

（メニュー提案処理）
次に、図４のステップＳ３０において携帯端末３０が送信した食事履歴データを使用して、携帯端末５０の制御部５２２が実行するメニュー提案処理について説明する。なお、本実施形態では、携帯端末５０の制御部５２２が、メニュー提案処理を実行することとするが、携帯端末３０，４０の制御部３２２が、自機に記憶されている食事履歴データに基づいて本処理を実行してもよい。

図７は、母親が所持する携帯端末５０の制御部５２２が実行するメニュー提案処理の一例を示すフローチャートである。

図７の処理では、まず、ステップＳ１００において、制御部５２２が、携帯端末（ここでは、父親の携帯端末３０とする）からの食事履歴データ（図３（Ｂ）の食事履歴テーブルのデータ）の受信が完了したか否か判定する。ここでの判断が否定された場合、すなわち、携帯端末３０からのデータ受信が完了していない場合には、データ受信が完了するまで、制御部５２２はステップＳ１００の処理を繰り返す。そして、データ受信が完了した段階で、ステップＳ１００の判断が肯定され、制御部５２２は、ステップＳ１０２に移行する。

ステップＳ１０２に移行すると、制御部５２２は、取得した食事履歴データに基づいて、表示部５１０に、携帯端末３０のユーザ（父親）が食べた食事に関するデータを表示する。次いで、ステップＳ１０４において、制御部５２２は、フラッシュメモリ５０８に記憶されている食事履歴データを、所定期間分（例えば、１週間分）、表示部５１０に表示する。

次いで、ステップＳ１０６では、制御部５２２が、フラッシュメモリ５０８に記憶されているメニューから、表示部５１０に表示されているメニューと重ならないメニューの候補をいくつか選択し、表示部５１０に表示する。この場合、制御部５２２は、例えば、カレンダ部５２０からの季節情報に基づいて候補となるメニューを選択してもよいし、無線通信部５０４を介して外部機器から取得した情報（例えば、近隣のスーパーでは食材Ａが安いという情報や、食材Ｂが旬であるという情報）に基づいてメニュー候補を選択してもよい。

次いで、ステップＳ１０８では、制御部５２２は、複数のメニュー候補の１つがユーザ（母親）によって選択されたか否か判断する。ここでの判断が肯定された場合、すなわち、複数のメニュー候補のうちの１つがタッチパネル３１２から選択された場合、制御部５２２は、ステップＳ１１０に移行する。

ステップＳ１１０に移行すると、制御部５２２は、選択されたメニューに関する情報を、表示部５１０に表示する。例えば、制御部５２２は、ＧＰＳモジュール５０６が検出した携帯端末５０の位置情報（すなわち、母親の位置情報）と、フラッシュメモリ５０８に記憶されている地図とに基づいて、選択したメニューの食材を購入できる店舗情報や、当該店舗までのルートなどを表示部５１０に表示する。この場合、制御部５２２は、無線通信部５０４を介して外部機器から取得した店舗での特売情報等に基づいて、選択したメニューの食材を安く購入できる店舗を表示部５１０に表示してもよい。また、制御部５２２は、選択したメニューのレシピや調理時間を表示部５１０上に表示することとしてもよい。制御部５２２は、表示部５１０上に表示を行った後、図７の全処理を終了する。

一方、ステップＳ１０８の判断が否定された場合、すなわち、メニュー候補が選択されていない場合には、制御部５２２は、ステップＳ１１２に移行する。ステップＳ１１２では、制御部５２２は、ユーザ（母親）からの終了指示を受け付けたか否か判断する。例えば、制御部５２２は、表示部５１０上に表示された終了ボタンがユーザ（母親）によって押されたか否か判断する。

ステップＳ１１２の判断が否定された場合、すなわち、ユーザ（母親）からの終了指示を受け付けていない場合には、制御部５２２は、ステップＳ１０８に戻る。一方、ステップＳ１１２の判断が肯定された場合、すなわち、ユーザ（母親）からの終了指示を受け付けた場合には、制御部５２２は、図７の全処理を終了する。

なお、上記説明においては、制御部５２２は、父親の携帯端末３０から食事履歴データを取得して、メニュー提案処理を行う場合について説明したが、これに限らず、子供の携帯端末４０から食事履歴データを取得して、メニュー提案処理を行うこととしてもよい。また、制御部５２２は、父親の携帯端末３０と子供の携帯端末４０から食事履歴データをそれぞれ取得して、各食事履歴データを考慮してメニュー提案処理を行うこととしてもよい。

なお、上述した図７の処理は、携帯端末３０からデータが送信された場合に実行されるものとしたが、これに限られるものではなく、例えば、毎日、所定の時刻（例えば、昼食が終了する１３時ごろや、夕食の買い物に出かける前の時刻（１５時ごろ））に、携帯端末５０が携帯端末３０から食事履歴データを取得するようにしてもよい。また、携帯端末５０の制御部５２２は、携帯端末３０，４０から食事履歴データを取得するのではなく、以下に説明するように、特定の食品に関する情報を取得してもよい。

（食品問い合わせ処理）
図８（Ａ）は、携帯端末５０の制御部５２２が、携帯端末３０のユーザが特定の食品を食べたか否かを問い合わせる処理（食品問い合わせ処理）の一例を示すフローチャートである。また、図８（Ｂ）は、問い合わせを受けた携帯端末３０の制御部３２２が実行する問い合わせに対する応答処理の一例を示すフローチャートである。

図８（Ａ）の処理では、まず、ステップＳ２００において、制御部５２２が、ユーザから、問い合わせ対象となる食品の入力を受け付ける。そして、次のステップＳ３０２において、問い合わせ対象の食品を、携帯端末３０に送信する。例えば、母親が、携帯端末３０のユーザ（父親）が「ブロッコリー」を食べたか否か知りたいとする。この場合、制御部５２２は、母親による操作に応じて、「ブロッコリー」を問い合わせ対象の食品として、携帯端末３０に送信する。

一方、携帯端末３０の制御部３２２は、図８（Ｂ）のステップＳ３００において、携帯端末５０から問い合わせを受信したか否かを判断する。ここでの判断が肯定された場合、すなわち、携帯端末５０から問い合わせを受信した場合には、制御部３２２は、次のステップＳ３０２において、問い合わせ対象の食品を携帯端末５０から受信する。ここでは、問い合わせ対象の食品として、「ブロッコリー」を受信する。

次いで、ステップＳ３０４では、制御部３２２は、問い合わせ対象の食品をユーザが食べたか否かを、食事履歴テーブル（図３（Ｂ））に格納された食事履歴データに基づいて判断し、その結果を携帯端末５０に送信し、処理を終了する。例えば、図３（Ｂ）に示す食事履歴テーブルにおいて、「ブロッコリー」は登録されていない。この場合、携帯端末３０は、父親がブロッコリーを食べていないと判断し、例えば、「ブロッコリー未摂取」と携帯端末５０に送信する。

図８（Ａ）に戻り、携帯端末５０の制御部５２２は、ステップＳ２０２以降、ステップＳ２０４において、問い合わせ対象の食品を携帯端末３０のユーザが食べたか否かの結果を受信するまで待機している。したがって、制御部５２２は、携帯端末３０においてステップＳ３０４が実行された段階でステップＳ２０６に移行し、受信した結果を表示部３１０に表示し、処理を終了する。これにより、母親は、父親が「ブロッコリー」を食べなかったことを確認できるので、父親の好き嫌いを知ることができる。また、例えば、父親の昼食として母親がお弁当を作った場合に、父親が嫌いな食材を口にしたかどうか、残飯として破棄してしまったかどうかを知ることもできる。

なお、上記においては、母親が問い合わせ対象の食品を１品入力しているが、これに限らず、複数品目を入力することとしてもよい。また、上記においては、母親の携帯端末５０から父親の携帯端末３０に対して問い合わせる場合について説明したが、母親の携帯端末５０から子供の携帯端末４０に対して問い合わせることとしてもよい。

以上、詳細に説明したように、第１の実施形態によれば、携帯端末３０，４０は、食品と接触し食品に関する情報を検出する検出部１１を有する食器用機器１０との間で人体通信を行う人体通信部３０２と、人体通信部３０２を介して取得した検出部１１の検出結果に基づき得られた情報を表示する表示部３１０と、を備えている。これにより、携帯端末３０，４０は、ユーザに特別な操作を強いることなく自動的にユーザの食に関する行動を記録し、ユーザに提供することができる。また、ユーザは、自身の食に関する行動を確認することができる。

また、本第１の実施形態では、表示部３１０は、検出部１１が検出した食品の順番を表示するため、ユーザは、自分の食事をとる際の傾向（例えば、おかずを先に食べてしまう等）を把握することが可能となる。

また、本第１の実施形態では、携帯端末３０，４０が、人体通信部３０２とは異なる無線通信部３０４を備え、無線通信部３０４は、食事履歴データを携帯端末５０等の外部機器に送信する。したがって、本実施形態によれば、携帯端末３０，４０の食事履歴データを他者と共有したり、活用したりすることが可能となる。例えば、父親及び子供の食事履歴データを受信した母親は、受信した食事履歴データを、次の食事のメニューの考案に活用することができる。これにより、父親や子供の昼食のメニューと夕食のメニューとが同じになるなどの事態の発生を避けることが可能となる。

また、本第１の実施形態では、携帯端末３０，４０が、食品毎の抵抗値を記憶するフラッシュメモリ３０８を備えているので、制御部３２２は、検出部１１が検出した抵抗値から、食品を特定することができる。

また、本第１の実施形態では、携帯端末３０，４０が、人体通信部３０２が、食器用機器１０と通信をしたことに応じて、日時を取得する、あるいは、計時を行うカレンダ部３２０を備えており、表示部３１０は、カレンダ部３２０により取得された食事開始時間、食事終了時間や、食事にかかった時間を表示する。これにより、ユーザは、自身が食事にかける時間の傾向を知ることができる。

また、本第１の実施形態において、表示部３１０は、食事に関するアドバイスを表示するので、ユーザは、自身の食事に関するアドバイスを受けることができ、食事状況の改善に役立てることができる。

なお、上記第１の実施形態では、図６（Ａ）に示すように、制御部３２２が、食事履歴データに基づいて、ユーザが摂取した食品に関する情報を表示部３１０上に表示する場合について説明したが、これに限られるものではない。例えば、制御部３２２は、フラッシュメモリ３０８に記憶されている食品のうち、検出部１１が検出していない食品を表示部３１０上に表示してもよい。これにより、ユーザは、自分が摂取していない食品について認識することができる。また、制御部３２２は、ユーザが一日に摂取した品目数やカロリー数を表示部３１０上に表示してもよい。

なお、上記第１の実施形態では、食器用機器１０が、検出部１１において検出された食材の抵抗値を携帯端末３０，４０に送信することとしていたが、これに限られるものではない。例えば、食器用機器１０のメモリ１４が食品情報テーブル（図３（Ａ））を記憶し、制御部１５が、検出部１１が測定した抵抗値と、メモリ１４が記憶する食品情報テーブルのデータとを比較することで特定した食品や料理を、携帯端末３０，４０に送信することとしてもよい。この場合、図４に示す処理において、ステップＳ１８の処理を省略することができる。

なお、制御部３２２は、ユーザが食事中に食器を置いた時間や回数などをフラッシュメモリ３０８に記憶してもよい。制御部３２２は、食器用機器１０との人体通信が成立しているか否かに基づいて、ユーザが食事中に食器を置いたか否かを判断できる。この場合、制御部３２２は、ユーザが食事中に食器を置いた時間や回数なども、表示部３１０に表示することができる。

なお、上記第１の実施形態では、食器用機器１０の検出部１１が、ユーザが食品を口にした場合の抵抗値を検出するものとしていたが、これに限られるものではなく、検出部１１は、例えば、食器１と接触した食品の固さ、水分量、塩分量、糖分等を検出してもよい。この場合、食品情報テーブルは、食品毎に、抵抗値のほかに、固さ、水分量、塩分量、糖分等のデータを備えるようにすればよい。食品の様々な特性情報を用いることにより、より正確に食品を特定することが可能となる。

また、上記第１の実施形態では、携帯端末３０，４０がスマートフォンである場合について説明したが、これに限られるものではなく、携帯端末３０，４０の構成及び機能を、メガネ、補聴器、時計などの人体に身につけるものへ適用することとしてもよい。

《第２の実施形態》
次に、第２の実施形態について説明する。本第２の実施形態は、レストランなどの飲食施設において電子機器システムを利用する場合の例である。図９は、第２の実施形態に係る電子機器システム１０００Ｂの構成を示すブロック図である。また、図１０は、電子機器システム１０００Ｂを利用している状況を示す図である。

図９に示すように、電子機器システム１０００Ｂは、食器用機器１０Ａ，１０Ｂと、フロア用機器６０と、店舗端末７０と、撮像ユニット８０と、を備える。なお、食器用機器１０Ａ，１０Ｂの構成及び機能は、第１の実施形態で説明したものと同一であるため、説明を省略する。また、以後の説明において、特に区別する必要のない限り、食器用機器１０Ａ，１０Ｂを食器用機器１０と記載し説明を行う。

（フロア用機器６０）
フロア用機器６０は、各テーブルの床に設けられており、図９に示すように、床電極部６１０と、人体通信部６２０と、制御部６３０と、通信部６４０と、を有する。

床電極部６１０は、図１０に示すように、顧客が座るテーブルの床に設けられ、複数の顧客や椅子に対応するように、部分電極６１０−１〜６１０−ｎ（ｎは任意の整数）を有している。部分電極６１０−１〜６１０−ｎは、信号電極とグラウンド電極とを有し、ユーザを介して食器用機器１０と人体通信を行うための電極である。

人体通信部６２０は、バンドパスフィルタを有した電気回路から構成される送受信部を有し、入力した受信信号を復調して受信データを生成する一方、送信するデータを変調して送信信号を生成する。本第２の実施形態では、人体通信部６２０は、床電極部６１０及び顧客を介して、食器１に設けられた食器用機器１０と人体通信を行う。なお、人体通信部６２０として電界方式を採用した場合には、顧客が靴を履いていたり、靴下を着用していても人体通信は可能である、すなわち、本実施形態における接触は、人体との直接的な接触のみならず、衣服や靴を介在させた接触も含む概念である。

通信部６４０は、後述の店舗端末７０と通信を行うものであり、その通信方式は有線、無線などいずれを採用してもよい。

制御部６３０は、ＣＰＵを備え、食器用機器１０から受信した食品に関する情報を通信部６４０を用いて店舗端末７０に送信する制御を行う。

（撮像ユニット８０）
撮像ユニット８０は、図９に示すように、撮像部８１０と、制御部８２０と、通信部８３０と、を有する。

撮像部８１０は、レストランの天井や壁に設けられ、レンズ系、撮像素子、画像処理回路を備える。なお、不図示の駆動系により、撮像部８１０をチルト方向に駆動するようにしてもよい。この場合、撮像部８１０は、フロア用機器６０から顧客が座っている位置情報を取得し、当該位置情報に基づいてその撮像位置を変えることにより、特定の顧客を撮像することができる。なお、撮像部８１０は、店舗の大きさやレイアウトに応じて複数設けてもよい。

通信部８３０は、撮像部８１０が撮像した画像データを店舗端末７０に送信するものであり、その通信方式は有線、無線などいずれを採用してもよい。

制御部８２０は、ＣＰＵを有し、撮像ユニット８０全体を制御するものである。本実施形態では、制御部８２０は、後述の店舗端末７０の指示に基づき、指定された顧客を撮像するように、不図示の駆動部により撮像部８１０の撮像位置を調節する。また、制御部８２０は、撮像部８１０が撮像した画像データを、店舗端末７０に送信する制御を行う。

（店舗端末７０）
店舗端末７０は、図９に示すように、通信部７１０と、画像解析部７２０と、メモリ部７３０と、カレンダ部７４０と、表示部７５０と、スピーカ７６０と、制御部７７０と、を有する。

通信部７１０は、フロア用機器６０の通信部６４０および撮像ユニット８０の通信部８３０と、無線や有線などにより通信を行うものである。通信部７１０は、フロア用機器６０の通信部６４０から顧客の食事に関する情報（食事情報データ）を受信するとともに、撮像ユニット８０の通信部８３０から顧客の画像データを受信する。

画像解析部７２０は、撮像ユニット８０が撮像した画像データに基づき、顧客の人数を検出したり、顧客の属性を解析する。

メモリ部７３０は、不揮発性の半導体メモリ（例えば、フラッシュメモリ）を含み、店舗で提供する食事のメニュー情報（図１４）や、食品名とその抵抗値とを関連付けた食品情報テーブル（図３（Ａ）参照）を記憶する。なお、本第２の実施形態における食品情報テーブルでは、「抵抗値」の項目に食品そのものの抵抗値が入力されているものとする。また、メモリ部７３０は、後述する制御部７７０の制御の下、フロア用機器６０から取得した顧客の食事情報データと、画像解析部７２０が解析した顧客の属性情報とを関連づけて食事情報テーブル（図１３（Ａ）等）に記憶する。

カレンダ部７４０は、日時情報を制御部７７０に出力するとともに、制御部７７０の指示に基づき計時を行う計時機能を有する。

表示部７５０は、レストランの従業員用の表示を行う。例えば、表示部７５０は、各顧客に対して次に料理を出すタイミングなどを表示する。

スピーカ７６０は、音声出力装置であり、レストランの従業員への各種音声案内を行う。具体的には、スピーカ７６０は、従業員の注意を前述の表示部７５０に向けるための音声を出力したり、表示部７５０の表示内容を音声で案内したりする。

制御部７７０は、ＣＰＵを有し、店舗端末７０および電子機器システム１０００Ｂ全体を制御するものである。本実施形態において、制御部７７０は、撮像ユニット８０に顧客画像の撮像を指示する。また、制御部７７０は、フロア用機器６０から取得した食事情報データや、画像解析部７２０から取得した顧客の属性をメモリ部７３０に記憶する。また、制御部７７０は、顧客が摂取しなかった食品等を分析する。

（食事情報データの登録・蓄積処理）
次に、制御部７７０が実行する、食事情報データの登録・蓄積処理の一例について、図１１及び図１２のフローチャートを用いて説明する。

（登録処理）
制御部７７０は、まず、図１１のフローチャートが示す、食事情報テーブルの登録処理を行う。この処理は、顧客毎の食事情報データを蓄積するための準備処理にあたる。

図１１の処理では、まず、ステップＳ４００において、制御部７７０は、撮像ユニット８０を制御して、テーブルに着席したグループの顧客画像を撮像する。なお、ステップＳ４００が実行されるタイミングとしては、例えば、従業員が店舗端末７０に対して撮像指示を出したタイミングであってもよいし、人感センサ等で人が着席したことを検出したタイミングであってもよいし、その他のタイミングであってもよい。

次いで、ステップＳ４０１では、制御部７７０は、撮像した顧客画像を解析する画像解析部７２０からグループを構成する顧客の人数を取得する。この場合、画像解析部７２０は、人がいない状態の画像との比較により、顧客の人数を解析するなどすることができる。

次のステップＳ４０２では、制御部７７０は、画像解析部７２０から、当該グループを構成する顧客の属性情報を取得する。なお、制御部７７０は、属性情報を取得した段階で、各顧客の位置に基づいて、各顧客と部分電極６１０−１〜６１０−ｎのいずれかとを対応付ける。次いで、ステップＳ４０３では、制御部７７０は、当該グループを構成する顧客の食事情報データを記録するためのテーブルを、メモリ部７３０に新規に登録し、処理を終了する。この図１１に示す処理によって、図１３（Ａ）に示すように、当該グループに対して、食事情報データを記録するための食事情報テーブルが登録される。

ここで、食事情報テーブルについて詳細に説明する。図１３（Ａ）に示すように、食事情報テーブルは、「グループＩＤ」、「顧客ＩＤ」、「顧客属性」、「部分電極」、「食事開始日時」、「食事終了日時」、「メニュー名」、「料理名」、「順番」、及び「食品名」の項目を有する。

「グループＩＤ」は、来店した顧客グループを一意に識別するための情報である。「顧客ＩＤ」は、グループＩＤで識別されるグループを構成する顧客を一意に識別するための情報である。「顧客属性」の項目には、画像解析部７２０から取得した、顧客ＩＤで識別される顧客の属性が登録される。図１３（Ａ）の例では、グループＩＤ“Ｇ００１”のグループは、３人の顧客から構成され、その属性は、２０代女性、４０代男性、３０代男性である。「部分電極」の項目には、各顧客の位置に対応する部分電極６１０−１〜６１０−ｎの識別子が登録される。

「食事開始日時」の項目には、各顧客が食事を開始した日時が格納される。「食事終了日時」の項目には、各顧客が食事を終了した日時が格納される。「メニュー名」の項目には、各顧客が注文したメニューの名前が格納される。「料理名」の項目には、各メニューに含まれる料理の名前が格納される。「順番」は、当該食事において、顧客が食べた食品の順番を一意に識別するための項目である。「食品名」の項目は、各順番において、顧客が食べた食品の名前を格納する。

（蓄積処理）
次に、制御部７７０が実行する、各顧客の食事情報データの蓄積処理について説明する。図１２は、テーブルに着席したグループの各顧客の食事情報データを蓄積する処理の一例を示すフローチャートである。なお、図１２の処理が実行される前提として、顧客に一度食器１（フォークなど）を咥えさせることで、顧客自身の抵抗値を制御部７７０が取得しているものとする。ただし、これに限らず、例えば、コップに食器用機器１０を設けておき、水を飲むために顧客がコップに口をつけたときの抵抗値を顧客自身の抵抗値として制御部７７０が取得することとしてもよい。

図１２の処理では、まず、ステップＳ４０４において、制御部７７０が、食器用機器１０との人体通信が成立したか否か判断する。このステップＳ４０４では、顧客が食事を始めるために、食器を手に取ったか否かを判断している。ここでの判断が否定された場合、すなわち、食器用機器１０との人体通信が成立していない場合には、制御部７７０は、食器用機器１０との人体通信が成立するまで、ステップＳ４０４の処理を繰り返す。そして、食器用機器１０との人体通信が成立した段階で、ステップＳ４０４の判断が肯定され、制御部７７０は、ステップＳ４０５に移行する。

ステップＳ４０５に移行すると、制御部７７０は、カレンダ部７４０から日時情報を取得し、食事情報テーブルにおいて、人体通信が成立した顧客の「食事開始日時」の項目を更新する。ここで、例えば、図１３（Ａ）のグループＩＤ“Ｇ００１”を構成する顧客ＩＤ“Ｃ０１”の２０代女性（以後、顧客Ｃ０１と記載する）が、フォークを手に取った場合（Ｓ４０４／ＹＥＳ）、制御部７７０は、図１３（Ｂ）に示すように、食事情報テーブルにおいて、顧客Ｃ０１の「食事開始日時」の項目を更新する（Ｓ４０５）。なお、図１３（Ｂ）においては、顧客Ｃ０２，Ｃ０３については、まだ、人体通信が成立していないため、「食事開始日時」の項目が更新されていない。

図１２に戻り、次のステップＳ４０６では、制御部７７０が、顧客がコースメニューを注文したか否か判断する。ここでの判断が肯定された場合、すなわち、顧客がコースメニューを注文した場合、制御部７７０は、ステップＳ４０８に移行する。なお、顧客が注文したメニューの情報は、レストランの従業員等が保持するＰＯＳ端末等から店舗端末７０に入力され、メモリ部７３０に格納されるものとする。

ステップＳ４０８に移行すると、制御部７７０は、顧客が注文したメニュー情報をメモリ部７３０から取得する。このとき、制御部７７０は、食事情報テーブルの「メニュー名」の項目を更新すると共に、取得したメニュー情報に基づき、当該メニューで最初に提供される料理を「料理名」の項目に登録する。なお、本第２の実施形態では、顧客Ｃ０１が“Ａコース”を注文したものとする。この場合、制御部７７０は、「メニュー名」の項目に“Ａコース”を登録する（図１３（Ｃ）参照）。さらに、図１４に示すメニュー情報において、Ａコースで最初に提供される料理は、“前菜”であるため、制御部７７０は、「料理名」の項目に“前菜”を登録する（図１３（Ｃ）参照）。

次のステップＳ４１０では、制御部７７０は、検出部１１の検出値に変化があったか否か判断する。このステップＳ４１０では、顧客が新たな食品を口にしたか否かを判定している。ここでの判断が否定された場合、すなわち、検出部１１の検出値に変化がない場合には、制御部７７０は、ステップＳ４１０の判断が肯定されるまで、ステップＳ４１０の処理を繰り返す。そして、検出部１１の検出値に変化があった段階で、ステップＳ４１０の判断が肯定され、制御部７７０は、ステップＳ４１２に移行する。

ステップＳ４１２に移行すると、制御部７７０は、検出部１１の検出結果を取得する。そして、次のステップＳ４１４では、制御部７７０は、メモリ部７３０に記憶されている食品情報テーブル（図３（Ａ））に基づいて、顧客が食べた食品を特定する。なお、制御部７７０は、検出部１１の検出結果（抵抗値）から、予め測定されている顧客自身の抵抗値を差し引いた値を食品の抵抗値とする。そして、制御部７７０は、算出された抵抗値と、食品情報テーブルの抵抗値とを比較して、顧客が食べた食品名を特定する。次いで、ステップＳ４１６では、制御部７７０が、特定された食品名を用いて、食事情報テーブルを更新する。なお、制御部７７０は、食事情報テーブルの「順番」及び「食品名」の項目を更新する。

次のステップＳ４１８では、制御部７７０は、顧客が、現在提供されている料理を食べ終えたか否か判断する。顧客が料理を食べ終えたか否かは、例えば、食器用機器１０との人体通信が成立しない時間が所定時間（例えば５〜１０分）続いたか否かによって判断することができる。

ステップＳ４１８の判断が否定された場合、すなわち、顧客が、現在提供されている料理をまだ食べ終えていない場合、制御部７７０は、ステップＳ４１０に戻る。一方、ステップＳ４１８の判断が肯定された場合、すなわち、顧客が、現在提供されている料理を食べ終えた場合には、制御部７７０は、ステップＳ４２０に移行する。

ステップＳ４２０に移行すると、制御部７７０は、コースメニューが終了したか否かを判断する。具体的には、制御部７７０は、コースメニューに含まれる料理及びその提供順と、ユーザに現在提供されている料理とを比較することによって、コースメニューが終了したか否か判断する。例えば、図１３（Ｄ）に示すように、顧客Ｃ０１が、前菜を食べ終えていたとする。これに対し、顧客Ｃ０１が注文したＡコースは、前菜の後にメイン料理を提供することになっている（図１４参照）。したがって、制御部７７０は、コースメニューがまだ終了していないと判断する。一方、図１５（Ａ）に示すように、顧客Ｃ０１が、デザートを食べ終えていた場合には、顧客Ｃ０１が注文したＡコースは、デザートが最後に提供される料理であるため（図１４参照）、制御部７７０は、コースメニューが終了したと判断する。

ステップＳ４２０の判断が否定された場合、すなわち、コースメニューがまだ終了していない場合には、制御部７７０は、ステップＳ４２２において、表示部７５０や、スピーカ７６０を用いて、顧客に次の料理を提供するよう従業員に報知する。例えば、Ａコースは、前菜の後にメイン料理を提供することになっているため（図１４）、図１３（Ｄ）のように前菜を食べ終えている顧客Ｃ０１に、メイン料理を提供するよう従業員に報知する。これにより、従業員は、適切なタイミングで顧客に次の料理を提供することができる。なお、ステップＳ４２２において従業員に対し、次の料理を提供するよう報知した段階で、制御部７７０は、食事情報テーブルの「料理名」の項目に、ステップＳ４２２で報知した料理の名前を登録する。例えば、制御部７７０は、ステップＳ４２２においてメイン料理の提供を従業員に報知した場合、食事情報テーブルの「料理名」の項目に、“メイン”を登録する（図１５（Ｂ）参照）。

ステップＳ４２２の処理の後は、制御部７７０は、ステップＳ４１０に戻り、ステップＳ４１０以降の処理を実行する。

一方、ステップＳ４２０の判断が肯定された場合、すなわち、コースメニューが終了した場合には、制御部７７０は、ステップＳ４２４において、カレンダ部７４０から日時情報を取得し、食事情報テーブルの「食事終了日時」の項目を更新する（図１５（Ｃ）参照）。そして、制御部７７０は、ステップＳ４２６に移行する。

ところで、ステップＳ４０６において、顧客がコースメニューを注文しなかった場合、すなわち、単品の料理が複数注文された場合、制御部７７０は、ステップＳ４２８において、顧客が注文したメニューの情報（オーダ情報）（ＰＯＳ端末等から店舗端末７０に入力される）を取得する。

その後は、制御部７７０は、ステップＳ４３０〜Ｓ４３８の処理を、前述したステップＳ４１０〜Ｓ４１８と同様に実行する。そして、ステップＳ４３８の判断が肯定された段階で、ステップＳ４４０に移行し、制御部７７０は、顧客が注文した料理を全て提供したか否か判断する。なお、全ての料理が提供されたか否かは、ステップＳ４２８で取得したオーダ情報と、検出部１１の検出値とに基づいて判断することができる。この判断が否定された場合、すなわち、全ての料理の提供がまだ終わっていない場合には、制御部７７０は、ステップＳ４４２において、未だ提供していない料理（例えば食後のコーヒーやデザートなど）を提供するよう従業員に報知する。これにより、従業員は、適切なタイミングで顧客に料理を提供することができる。なお、制御部７７０は、ステップＳ４４２の処理の後は、ステップＳ４３０に戻る。

そして、全ての料理が提供された場合、すなわち、ステップＳ４４０の判断が肯定された場合には、制御部７７０は、ステップＳ４２４において、カレンダ部７４０から日時情報を取得し、食事情報テーブルの「食事終了日時」の項目を更新する。そして、制御部７７０は、ステップＳ４２６に移行する。

ステップＳ４２６に移行すると、制御部７７０は、各顧客の食事情報データを分析する。ここでは、一例として、制御部７７０は、図１６（Ａ）のメニュー情報（図１４（Ａ）と同様）と、図１６（Ｂ）の食事情報テーブルとに基づき、未摂取食品情報（図１６（Ｃ））を抽出する。図１６（Ａ）に示すメニュー情報は、各料理で使用されている食品の情報を含んでいる。したがって、食事情報テーブルが格納する顧客が各料理で摂取した食品と、メニュー情報において各料理で使用されている食品とを比較することで、制御部７７０は、未摂取食品情報を顧客ごとに抽出することが可能である。これにより、顧客が摂取しなかった食品に関するデータを取得することができるので、店舗の従業員等は、当該データをメニュー開発等に役立てることができる。

なお、制御部７７０は、顧客が食品を摂取しなかった理由を分析して、図１６（Ｃ）に示す未摂取食品情報に記録するようにしてもよい。例えば、顧客が摂取しなかった食品が、コースメニューの第１品目に含まれる食品であれば、制御部７７０は、顧客が食品を摂取しなかった理由が、「顧客がその食品が苦手」であるためと判断し、未摂取食品情報に記録する。また、顧客がコースメニューの終盤で食品を摂取せず、その後もほとんど料理を口にしなかった場合であれば、制御部７７０は、顧客が食品を摂取しなかった理由は、「満腹であった」ためと判断し、未摂取食品情報に記録する。このように、未摂取の理由を記録することで、顧客属性と未摂取の理由とから、料理の量の適否等を推測することも可能となる。例えば、４０代女性の顧客が「満腹であった」ため、メイン料理に含まれる食品を残したような場合には、コースメニューの量が多すぎると推測できる。これにより、未摂取食品情報を、メニュー開発等にさらに有効に活用することが可能となる。

なお、上記ステップＳ４２６の処理が実行された後は、制御部７７０は、図１２の全処理を終了する。

以上、詳細に説明したように、本第２の実施形態によれば、店舗端末７０は、ユーザが保持する食器１に設けられ食品に関するデータを検出する検出部１１から、ユーザを介した人体通信によって、該食品に関するデータを取得する通信部７１０と、取得した当該食品に関するデータに基づいて、顧客の食事に関するデータ（食事情報データ）を記憶するメモリ部７３０と、を備えている。これにより、店舗端末７０は、顧客や従業員に特別な操作を強いることなく、顧客の食に関する行動を自動的に記録することができる。

また、本第２の実施形態では、メモリ部７３０は、食品毎の抵抗値を食品情報テーブルに記憶しており、制御部７７０が、検出部１１が検出した食品の抵抗値と、食品情報テーブルとを比較するので、顧客が口にした食品を特定することができる。

また、本第２の実施形態では、制御部７７０は、メニュー情報及び食事情報テーブルに基づいて、顧客が残した食品をメモリ部７３０に記憶する。これにより、顧客が残した食品に関するデータを蓄積することができるので、レストランの経営者や従業員等は、当該データを調理方法の検討や、メニュー開発等に活用することが可能となる。

また、本第２の実施形態では、制御部７７０は、食事情報データに基づいて、顧客に食事を提供するタイミングを決定するので、レストランの従業員は、適切なタイミングで顧客に食事を提供できる。この場合において、本第２の実施形態では、店舗端末７０は、食事データに基づいて、顧客に食事を提供するタイミングを報知する表示部７５０やスピーカ７６０を備えているので、従業員は顧客に食事を提供する適切なタイミングを知ることができる。

また、本第２の実施形態では、店舗端末７０は、食器用機器１０との人体通信に基づいて、日時情報の取得や計時を行うカレンダ部７４０を備えているので、顧客が食事にかけた時間等を蓄積することができる。なお、メニュー毎に食事にかかる時間を食事情報テーブルに格納しておき、分析を行うこととしてもよい。また、店舗の回転率や混雑時の待ち時間等の計算を行うために、蓄積したデータを活用することとしてもよい。

また、本第２の実施形態では、店舗端末７０は、通信部７１０が、顧客を撮像する撮像ユニット８０から取得した顧客の撮像データに基づいて、顧客の属性を検出する画像解析部７２０を備えているので、顧客の属性と、食に関する行動とを関連づけることができるため、顧客属性別のメニューの開発や、料理の量の検討等、食事情報データの活用の幅が広がる。

また、本第２の実施形態では、検出部１１は、顧客の手と接触し、通信部７１０は、顧客の足と接触する床電極部６１０を介した人体通信により、検出部１１から食品に関するデータを入力するので、顧客に意識させることなく、食事情報データの取得が可能となる。

また、本第２の実施形態では、食器用機器１０は、食品と接触し、食品の抵抗値を検出する検出部１１と、検出部１１が検出した抵抗値を、外部機器に送信する人体通信部１３とを備えている。これにより、顧客や従業員に特別な操作を強いることなく、食器用機器１０が設けられた食器１を使用して顧客が口にした食品に関する情報を店舗端末７０に送信し、顧客の食に関する行動を記録することができる。

なお、上記第２の実施形態では、フロア用機器６０を用いて人体通信を行う場合について説明したが、これに限らず、フロア用機器６０に代えて、フロア用機器６０と同一の構成の機器を椅子の座板等に設けることとしてもよい。また、人体通信ではなく近接通信を用いる場合には、前述の椅子に加え、テーブルや、壁なども利用することができる。

なお、上記第２の実施形態では、食器用機器は、検出部１１が検出した抵抗値をフロア用機器６０に送信していたが、これに限られるものではない。食器用機器１０が備えるメモリ１４が、食品とその抵抗値とを関連付けた食品情報テーブル（図３（Ａ））を記憶し、制御部７７０が、検出部１１が検出した抵抗値と、メモリ１４が記憶している食品情報テーブルのデータとを比較し、人体通信部１３は、比較によって特定された食品を送信してもよい。これにより、顧客や従業員に特別な操作を強いることなく、店舗端末７０は、顧客が口にした食品の情報を取得でき、顧客の食に関する行動を記録することが可能となる。

なお、上記第２の実施形態は、コースまたはアラカルト形式で料理を提供している店舗での利用例について説明したが、ブッフェ形式で料理を提供する店舗にも第２の実施形態を適用することができる。以下、ブッフェ形式で料理を提供する店舗における例について説明する。

（ブッフェ形式で料理を提供する店舗における例（変形例））
図１７は、レストランがブッフェ形式で料理を提供している場合に、制御部７７０が実行する処理の一例を示すフローチャートである。なお、ブッフェ形式の場合、食器用機器１０Ａ，１０Ｂは、例えば、大皿に盛られた料理を取り分けるための食器１（例えば、トング、菜箸、お玉等）に設けられるものとし、どの食器１が、どの料理の取り分けに用いられるかが定まっているものとする。また、食器用機器１０Ａ，１０Ｂの検出部１１は、食器１で保持した料理の重量を直接的又は間接的に検出することが可能なセンサであるものとする。

図１７の処理では、まず、ステップＳ５００において、制御部７７０は、食器用機器１０との人体通信が成立したか否かを判断する。このステップＳ５００の処理では、顧客が、大皿に盛られた料理を取り分けるために、食器１に接触したか否かを判断している。ステップＳ５００の判断が否定された場合、すなわち、食器用機器１０との人体通信が成立していない場合には、制御部７７０は、人体通信が成立するまで、ステップＳ５００の処理を繰り返す。そして、食器用機器１０との人体通信が成立した段階で、ステップＳ５００の判断が肯定され、制御部７７０は、ステップＳ５０２に移行する。

ステップＳ５０２に移行すると、制御部７７０は、食器用機器１０の検出部１１による検出結果（本実施形態では、食器１で保持した料理の重量）を取得する。なお、制御部７７０は食器用機器１０の識別子も取得するものとする。これにより、制御部７７０は、顧客がどの料理をどのくらいの量だけ取り分けたのかを認識することができる。

次いで、ステップＳ５０４では、制御部７７０が、ステップＳ５０２で取得した検出結果（料理の重量）と、過去に同一の食器１で保持した料理の重量とを合計（積算）する。

次のステップＳ５０６で、制御部７７０は、ステップＳ５０４において特定された料理について、料理を補充する条件が満たされたか否か判断する。具体的には、制御部７７０は、同一の料理の取り分け量（ステップＳ５０４の積算値）が料理ごとに予め定められている閾値を超えた場合に、料理を補充する条件が満たされたと判断する。

ステップＳ５０６の判断が肯定された場合、すなわち、料理を補充する条件が満たされた場合、制御部７７０は、ステップＳ５０８において、従業員の料理の補充が必要であることを報知する。これにより、従業員は、適切なタイミングで料理を補充することができ、顧客が食べたい料理が補充されていないという状況を防ぐことができる。なお、ステップＳ５０８の後は、制御部７７０は、ステップＳ５００に戻る。なお、レストランの従業員は、料理を補充した後に、その旨を店舗端末７０に入力することとしてもよい。制御部７７０は、当該入力があった段階で、補充された料理の取り分け量の積算値をリセットすることとしてもよい。また、制御部７７０は、ステップＳ５０８において報知した後に、補充された料理の取り分け量の積算値をリセットすることとしてもよい。

一方、ステップＳ５０６の判断が否定された場合、すなわち、料理を補充する条件が満たされていない場合には、制御部７７０は、ステップＳ５００からの処理を再び実行する。

このように、レストランがブッフェ形式で料理を提供している場合にも、店舗端末７０の制御部７７０は、食器用機器１０から顧客が取り分けた料理の重量を取得するので、当該重量に基づいて、料理を補充するタイミング等を決定することができる。なお、制御部７７０は、顧客が料理を取り分けた量や回数を料理ごとにメモリ部７３０に記憶してもよい。また、営業時間終了後に、制御部７７０は、顧客があまり取り分けなかった料理の情報を「未選択料理情報」としてメモリ部７３０に記憶するようにしてもよい。これにより、顧客の料理を取り分ける行動の履歴データを蓄積することが可能となり、人気の高い料理や、人気のない料理の分析や、顧客が最初に食べる傾向のある料理（例えば、ボリュームのある肉料理、脂っこい料理）、最後のほうに食べる傾向のある料理（例えば、果物やケーキなどのデザート）の分析等を行うことが可能となる。さらに、レストランの経営者や従業員は、分析結果に基づいて、メニュー構成や作る順番や食品の仕入れ量等を検討することが可能となる。

なお、上記変形例では、制御部７７０が、取り分けた料理の重量を取得する場合について説明したが、これに限らず、制御部７７０は、料理を取り分けた回数を取得することとしてもよい。この場合、制御部７７０は、ステップＳ５０６において、料理を取り分けた回数の合計が予め定められている閾値を超えた場合に料理を補充する条件が満たされたと判断することとしてもよい。

《第３の実施形態》
次に、第３の実施形態について説明する。

図１８は、第３の実施形態に係る電子機器システム１０００Ｃを示すブロック図である。図１８に示すように、電子機器システム１０００Ｃは、食器用機器１０Ａ，１０Ｂと、携帯端末３０と、店舗端末７０と、を備える。なお、食器用機器１０Ａ，１０Ｂは、上記第１、第２の実施形態と同様となっている。

携帯端末３０では、制御部３２２がフラッシュメモリ３０８に記憶されている食事履歴データ（図２０（Ａ））を、無線通信部３０４を介して、店舗端末７０に送信するが、携帯端末３０のその他の構成等については、上記第１の実施形態と同様となっている。なお、図２０（Ａ）の食事履歴データは、第１の実施形態の食事履歴テーブルと同様の方法で蓄積され、フラッシュメモリ３０８に蓄積されているものとする。

店舗端末７０では、制御部７７０が無線通信部３０４を介して店を訪れた顧客の食事履歴データを取得するとともに、店舗のメニューと、顧客の食事履歴データとを比較し、携帯端末３０のユーザに対して、ユーザに適したメニューを提案するが、店舗端末７０のその他の構成等については、上記第２の実施形態と同様となっている。

ここで、制御部７７０が実行するメニューの提案処理について、図１９のフローチャートに沿って説明する。なお、図１９の処理が行われる前提として、携帯端末３０のユーザが、食事をするためにレストランなどの店舗に入店しようとしているものとする。

図１９の処理では、まず、ステップＳ７００において、制御部７７０は、携帯端末３０のフラッシュメモリ３０８に記憶されている食事履歴データ（図２０（Ａ））を取得する。なお、ステップＳ７００の処理は、店舗内に入った携帯端末３０から店舗端末７０に対して食事履歴データが送られてきた段階で実行することとすればよい。なお、携帯端末３０の制御部３２２は、位置情報（ＧＰＳモジュール３０６から取得できる）に基づいて、顧客が店舗に入ったことを検出した段階で、店舗端末７０に対して食事履歴データを送信するようにすればよい。

次のステップＳ７０２では、制御部７７０が、メモリ部７３０に記憶されているメニュー情報（図２０（Ｂ））を取得する。

次いで、ステップＳ７０４では、制御部７７０が、店舗が提供するメニューの中から顧客が好みそうなメニューを顧客に対して提案する。ここでは、制御部７７０は、ステップＳ７００で取得した食事履歴データに基づいて携帯端末３０の顧客の好き・嫌いを分析し、メニュー情報の中から、顧客が好みそうなメニューを提案する。例えば、図２０（Ａ）に示す食事履歴データを取得した場合、ハンバーグや生姜焼きといった肉料理が多いことから、制御部７７０は、顧客が「肉料理が好きである」と分析する。そして、図２０（Ｂ）に示すメニュー情報の中から、肉料理を含むメニューを選択し、顧客に提案する。図２０（Ｂ）に示すメニュー情報において、肉料理を含むメニューは、“Ａコース”及び“肉料理Ａ”である。したがって、制御部７７０は、顧客に提案すべきメニューを、例えば、図２０（Ｃ）に示すように、表示部７５０上に表示する。これにより、従業員は、初めて来店した顧客であっても、顧客に適したメニューを提案することができる。なお、制御部７７０は、従業員が使用するオーダー用の端末（ＰＯＳ端末）に表示させてもよい。以上の処理により、図１９の全処理が終了する。

なお、制御部７７０は、普段肉料理が多い顧客であれば、栄養バランスを考慮して、肉料理とは異なる料理（魚料理や野菜料理）を提案するようにしてもよい。制御部７７０がいずれの提案を行うかは、携帯端末３０のユーザが設定してもよい。

以上、詳細に説明したように、第３の実施形態によれば、制御部７７０が、メニュー情報と、顧客の食事履歴データとに基づいて、顧客に適したメニューを提案するので、初めて来店した顧客にも、顧客の嗜好を反映したメニューを提案することができる。

なお、上記第３の実施形態では、携帯端末３０のフラッシュメモリ３０８は食事履歴データだけでなく、例えば、ユーザのアレルギー食材等を記憶するようにしてもよい。この場合、アレルギー食材のデータを店舗端末７０に送信することにより、例えば、ユーザは、アレルギー食材を含まないメニューの提案を受けたり、あるいは、アレルギー食材を除いた料理の提供を受けることができる。

なお、上記第３の実施形態では、制御部７７０が、店舗の従業員に対して顧客に適したメニューを提案する場合について説明したが、これに限らず、制御部７７０は、顧客に対して適したメニューを提案することとしてもよい。例えば、制御部７７０は、顧客の携帯端末に対して適したメニューを送信することとしてもよいし、顧客が操作可能なメニュー選択用の機器（テーブルに設置されている）に対して表示することとしてもよい。

《第４の実施形態》
次に、第４の実施形態について説明する。第４の実施形態は、ユーザの食の嗜好に基づいて、ユーザに適した店舗を紹介するものである。

図２１には、第４の実施形態に係る電子機器システム１０００Ｄがブロック図にて示されている。図２１に示すように、電子機器システム１０００Ｄは、携帯端末３０，４０と、サーバ９０と、ネットワーク１００と、を備える。

（携帯端末３０，４０）
携帯端末３０，４０の構成及び機能は、第１〜第３の実施形態と同様であるが、フラッシュメモリ３０８が、ユーザの食の嗜好に関する情報を記憶する点、無線通信部３０４が、ネットワーク１００を介して、ユーザの食の嗜好に関する情報を、サーバ９０に送信する点が異なっている。なお、ユーザの食の嗜好に関する情報は、例えば、ユーザがタッチパネル３１２を用いて、携帯端末３０に入力してもよいし、第１の実施形態において説明したフラッシュメモリ３０８に記憶されている食事履歴データに基づいて、制御部３２２が分析してもよい。

（サーバ９０）
サーバ９０は、図２１に示すように、通信部９１０と、制御部９２０と、記憶部９３０と、を有する。

通信部９１０は、ネットワーク１００を介して、携帯端末３０，４０と通信するためのものである。記憶部９３０は、不揮発性の半導体メモリ（フラッシュメモリ）や、ハードディスクドライブであり、レストラン等の店舗に関する情報を記憶する。また、記憶部９３０は、携帯端末３０，４０から送信された各ユーザの食の嗜好に関する情報を記憶する。制御部９２０は、ＣＰＵを有し、サーバ９０全体を制御する。また、制御部９２０は、通信部９１０を介して、ユーザの食の嗜好に関する情報を取得し、記憶部９３０に記憶する。また、制御部９２０は、記憶部９３０に記憶されている店舗に関する情報と、ユーザの食の嗜好に関する情報とを比較して、ユーザに適した店舗をユーザに紹介する（ユーザに適した店舗の情報を携帯端末３０，４０に対して送信する）。

以下、サーバ９０の制御部９２０が実行する処理について、図２２のフローチャートを用いて具体的に説明する。ここでは、携帯端末３０のユーザＸと、携帯端末４０のユーザＹとが一緒に食事に行くために、携帯端末３０，４０をそれぞれ操作して自身の食の嗜好に関する情報をサーバ９０に送信するものとする。

図２１の処理では、まず、ステップＳ６００において、制御部９２０は、携帯端末から食の嗜好に関する情報（以下、「嗜好データ」と呼ぶ）を受信したか否か判断する。ここでの判断が否定された場合、すなわち、携帯端末３０，４０から嗜好データを受信していない場合には、制御部９２０は、嗜好データを受信するまでステップＳ６００の処理を繰り返す。そして、嗜好データを受信した段階で、ステップＳ６００の判断が肯定され、制御部９２０は、ステップＳ６０２に移行する。なお、ユーザＸとユーザＹは、サーバ９０に対して同一のＩＤやパスワードでログインするなどすることで、一緒に食事をするメンバーであることを制御部９２０に認識させることができる。

ステップＳ６０２に移行すると、制御部９２０は、受信した嗜好データを分析する。また、ステップＳ６０４では、制御部９２０は、分析結果に基づいて、提案する店舗を決定する。例えば、携帯端末３０から図２３（Ａ）に示すユーザＸの嗜好データを受信し、携帯端末４０から図２３（Ｂ）に示すユーザＹの嗜好データを受信したとする。この場合、制御部９２０は、ユーザＹが鶏肉を好きなため、ユーザＸが好きな焼き鳥を、ユーザＹも好きである可能性が高いとして、図２３（Ｃ）に示す店舗情報テーブルの中から、“焼き鳥”に「分類」されている店舗“Ｏ”を提案する。第４の実施形態の電子機器システム１０００Ｄは、ユーザＸと、ユーザＹとが初対面であったり、互いに遠慮するような間柄の場合に、サーバ９０が店舗情報を提供してくれるので、ユーザＸおよびユーザＹにとって使い勝手のよいシステムとなっている。

なお、上述のステップＳ６０２において、嗜好データを分析する場合、制御部９２０は、各携帯端末から受信した嗜好データに重み付けをしてもよい。例えば、ユーザＸとユーザＹとで好みが全く一致しない場合に、ユーザＸの嗜好データに重みを付け（ユーザＸの嗜好データを重視して）、店舗を提案してもよい。この場合、いずれかのユーザにどのユーザの嗜好を優先させるかを入力させてもよいし、各ユーザの上下関係（上司−部下の関係）を入力させ、当該上下関係に基づいて制御部９２０がどのユーザの嗜好を優先させるかを決定してもよい。更には、複数の携帯端末の配列状態に応じて、どのユーザの嗜好を優先させるかを決定してもよい。例えば、図２４に示すように携帯端末が配列された状態で、嗜好データが各携帯端末から送信された場合には、制御部９２０は、一番上に配置されている携帯端末３０から送信された嗜好データを、携帯端末４０から送信された嗜好データよりも重視して店舗の提案を行うことができる。これにより、複数の携帯端末の配列を変えれば、重み付けされる嗜好データを容易に変更することができるため、ユーザに重み付けに関する情報を入力させる必要がなくなり、ユーザの利便性も向上する。なお、携帯端末の配列情報は、各携帯端末が有する各種センサ（重量センサや撮像部、光量センサ、接触センサなど）を用いて検出することができる。

図２２に戻り、ステップＳ６０６では、制御部９２０は、ステップＳ６０４において決定した店舗情報を携帯端末３０，４０に送信し、図２２の全処理を終了する。本処理により、店舗情報を受信したユーザＸ、Ｙは、両者の好みに共通した店舗の提案を受けることができる。なお、上記においては、２人のユーザが嗜好データを送信する場合について説明したが、３人以上のユーザが嗜好データを送信してもよいし、１人のユーザのみが嗜好データを送信することとしてもよい。また。制御部９２０は、店舗の情報を、ユーザの一部にのみ通知することとしてもよい。この場合、ユーザ間で幹事設定されたユーザに対してのみ店舗の情報を通知することとしてもよい。また、ユーザが予算や店舗の好み（和食、洋食、テーブル席、座敷など）を設定した場合には、予算や好みも加味して、店舗を提案することとしてもよい。

以上、詳細に説明したように、第４の実施形態によれば、サーバ９０は、少なくとも一人のユーザの携帯端末と通信可能な通信部９１０と、通信部９１０を介して、少なくとも一人のユーザの食の嗜好に関する情報（嗜好データ）を、前記ユーザの携帯端末から入力する制御部９２０と、備えている。これにより、サーバ９０は、携帯端末のユーザの食の嗜好に関する情報を取得することができる。また、サーバ９０は、店舗に関する情報を記憶する記憶部９３０を備えており、制御部９２０は、ユーザの食の嗜好に関する情報と、店舗に関する情報を比較するので、制御部９２０は、ユーザの食の嗜好にあった店舗をユーザに対して提案することができる。

また、本第４の実施形態においては、制御部９２０が、ユーザの食の嗜好に関する情報に重み付けを行うので、複数のユーザの嗜好を全て反映した店舗の提案が難しい場合に、重視すべきユーザ（例えば、お客様や上司）の嗜好を反映した店舗を提案することができる。

なお、上記第４の実施形態では、記憶部９３０が店舗情報を記憶する場合について説明したが、これに限られるものではなく、記憶部９３０は、料理に関する情報を記憶してもよい。この場合、制御部９２０は、各ユーザの食の嗜好を反映した料理を提案することができる。また、制御部９２０は、ユーザの少なくとも１人がアレルギー体質である場合には、アレルギー食材を含まない料理を提案することとしてもよい。

また、上記第４の実施形態では、記憶部９３０は、携帯端末から送信されたユーザの嗜好データを記憶してもよい。これにより、ユーザは、店舗の提案を受けようとするたびに、自身の嗜好データを送信する必要がなくなり、ユーザの利便性が向上する。

なお、上記第４の実施形態では、携帯端末３０，４０のユーザＸ，Ｙが、店舗の提案を受けるために、自身の嗜好データを送信する処理を行っていたが、これに限られるものではない。制御部９２０は、所定のタイミングで所定の外力を加えられた携帯端末から、ユーザの嗜好データを取得するようにしてもよい。例えば、特定のアプリケーションを起動した状態の複数の携帯端末同士をユーザが乾杯するようにぶつけあった場合に、ぶつかりあった携帯電話の制御部３２２がサーバ９０の制御部９２０に対してユーザの嗜好データを送信するするようにしてもよい。これにより、ユーザの利便性を向上することができる。

上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

１ 食器
１０Ａ，１０Ｂ 食器用機器
１１ 検出部
１３ 人体通信部
１４ メモリ
１５ 制御部
３０ 携帯端末
７０ 店舗端末
８０ 撮像ユニット
９０ サーバ
３０２ 人体通信部
３０４ 無線通信部
３０８ フラッシュメモリ
３１０ 表示部
３２０ カレンダ部
６１０ 床電極部
７２０ 画像解析部
７３０ メモリ部
７４０ カレンダ部
７５０ 表示部
７６０ スピーカ
７７０ 制御部
９１０ 通信部
９２０ 制御部
９３０ 記憶部

Claims (10)

1. 少なくとも一人のユーザの携帯端末と通信可能な通信部と、
   前記通信部を介して、前記少なくとも一人のユーザの食の嗜好に関する情報を、前記少なくとも一人のユーザの携帯端末から入力する入力部と、
   を備えたことを特徴とする電子機器。
2. 食に関する情報を記憶する第１記憶部と、
   前記入力部が入力した情報と、前記第１記憶部が記憶している情報とを比較する比較部と、
   を備えたことを特徴とする請求項１記載の電子機器。
3. 前記比較部は、前記入力部が入力した情報に重み付けを行うことを特徴とする請求項２記載の電子機器。
4. 前記重み付けは、前記食の嗜好に関する情報を送信するユーザの携帯端末の配列状態に応じて行われることを特徴とする請求項３に記載の電子機器。
5. 前記第１記憶部が記憶している情報は、料理に関する情報であることを特徴とする請求項２から４のいずれか一項記載の電子機器。
6. 前記第１記憶部が記憶している情報は、店舗に関する情報であることを特徴とする請求項２から５のいずれか一項記載の電子機器。
7. 前記入力部が入力した情報を記憶する第２記憶部を備えたことを特徴とする請求項１から６のいずれか一項記載の電子機器。
8. 前記第２記憶部は、複数のユーザの食の嗜好に関する情報を記憶し、
   前記第２記憶部から、少なくとも一人のユーザの食の嗜好に関する情報を選択する選択部を備えたことを特徴とする請求項７記載の電子機器。
9. 前記選択部は、所定のタイミングで所定の外力を加えられた携帯端末を所有するユーザの食の嗜好に関する情報を、前記第２記憶部から選択することを特徴とする請求項８記載の電子機器。
10. 前記入力部は、所定のタイミングで所定の外力を加えられた携帯端末から、前記携帯端末を所有するユーザの食の嗜好に関する情報を入力することを特徴とする請求項１から９のいずれか一項載の電子機器。

Images