以下、本発明の実施の形態について、図面を参照して詳細に説明する。
<提供するサービスの全体像>
まず、本実施の形態に係る提供するサービスの全体像について、図1を用いて説明する。図1は、本実施の形態における調理支援システムの概要について説明する図である。図1Aには、本実施の形態における調理支援システムの全体像が示されている。
グループ10は、例えば企業、団体、家庭等であり、その規模を問わない。グループ10には、複数の機器10a(例えば、後述する端末100、調理機器200)である機器A、機器Bおよびホームゲートウェイ10bが存在する。
複数の機器10aは、インターネットと接続可能な機器(例えば、スマートフォン、タブレット、PC、TV等)である。ただし、複数の機器10aは、それ自身ではインターネットと接続不可能な機器であっても、ホームゲートウェイ10bを介してインターネットと接続可能となるものであればよい。また、グループ10には複数の機器10aを使用するユーザ1が存在する。ユーザ1は、例えば、調理を行う者である。
データセンタ運営会社11には、クラウドサーバ11aが存在する。クラウドサーバ11aとはインターネットを介して様々な機器と連携する仮想化サーバである。データセンタ運営会社11は、データ管理やクラウドサーバ11aの管理、それらを行うデータセンタの運営等を行っている。データセンタ運営会社11が行っている役務については詳細を後述する。
ここで、データセンタ運営会社11は、データ管理またはクラウドサーバ11aの運営等のみを行っている会社に限らない。例えば複数の機器10aのうちの一つの機器を開発・製造している機器メーカが、併せてデータ管理やクラウドサーバ11aの管理等を行っている場合は、機器メーカがデータセンタ運営会社11に該当する(図1B参照)。
また、データセンタ運営会社11は一つの会社に限らない。例えば機器メーカおよび他の管理会社が共同もしくは分担してデータ管理やクラウドサーバ11aの運営を行っている場合は、両者もしくはいずれか一方がデータセンタ運営会社11に該当するものとする(図1C参照)。
サービスプロバイダ12は、サーバ12a(例えば、後述するサーバ300)を保有している。サーバ12aは、目的に応じて複数あってもよい。
なお、上記サービスにおいてホームゲートウェイ10bは必須ではない。例えば、クラウドサーバ11aが全てのデータ管理を行っている場合等は、ホームゲートウェイ10bは不要となる。また、グループ10内のあらゆる機器がインターネットに接続されている場合のように、それ自身ではインターネットと接続不可能な機器は存在しない場合もある。
次に、上記サービスにおける情報の流れを説明する。まず、グループ10の機器Aまたは機器Bは、それぞれ、所定の情報を、データセンタ運営会社11のクラウドサーバ11aに送信する。クラウドサーバ11aは、機器Aまたは機器Bの情報を集積する(図1Aの(a))。
なお、上記情報は、インターネットを介して複数の機器10a自体から直接クラウドサーバ11aに提供される場合もある。または、上記情報は、複数の機器10aから一旦ホームゲートウェイ10bに情報が集積され、ホームゲートウェイ10bからクラウドサーバ11aに提供されてもよい。
次に、データセンタ運営会社11のクラウドサーバ11aは、集積した情報を一定の単位でサービスプロバイダ12に提供する。ここで、一定の単位は、データセンタ運営会社11が集積した情報を整理してサービスプロバイダ12に提供することのできる単位でもよいし、サービスプロバイダ12が要求した単位でもよい。一定の単位と記載したが、一定でなくてもよく、状況に応じて提供する情報量が変化する場合もある。
クラウドサーバ11aに集積された情報は、必要に応じてサービスプロバイダ12が保有するサーバ12aに保存される(図1Aの(b))。そして、サービスプロバイダ12は、保存した情報を、ユーザに提供するサービスに適合する情報に整理し、ユーザに提供する。提供するユーザは、複数の機器10aを使用するユーザ1でもよいし、グループ10の外部のユーザ2でもよい。
ユーザへのサービス提供方法は、例えば、サービスプロバイダ12から直接ユーザへ提供されてもよい(図1Aの(f)、(e))。また、ユーザへのサービス提供方法は、例えば、データセンタ運営会社11のクラウドサーバ11aを再度経由して、ユーザに提供されてもよい(図1Aの(c)、(d))。また、データセンタ運営会社11のクラウドサーバ11aが、集積した情報を、ユーザに提供するサービスに適合する情報に整理し、サービスプロバイダ12に提供してもよい。
なお、ユーザ1とユーザ2とは、別でも同一でもよい。
<調理支援システムの構成>
次に、本実施の形態に係る調理支援システムの構成例について、図2を用いて説明する。図2は、本実施の形態の調理支援システムの構成の一例を示すブロック図である。
図2に示すように、調理支援システムは、端末100、調理機器200、およびサーバ300を有する。
図2において、端末100とサーバ300は、ネットワーク400を介して接続される。また、調理機器200とサーバ300も、ネットワーク400を介して接続される。ネットワーク400は、無線ネットワークでもよいし、有線ネットワークでもよいし、有線ネットワークと無線ネットワークとが混在したネットワークでもよい。
まず、端末100の構成について説明する。
端末100(本発明の端末装置の一例)は、サーバ300により提供される調理工程画像を表示する情報処理装置であり、例えば、スマートフォン、タブレット、PC、TVなどである。調理工程画像とは、所定の料理のレシピにおける調理工程に対応する画像である(詳細は後述)。
端末100は、入力部101、通知部102、記憶部103、送受信部104、制御部105を備える。
入力部101は、ボタン、タッチパネルなどの入力デバイスである。
通知部102は、ディスプレイなどの表示デバイス(表示部の一例)、または、スピーカなどの出力デバイスである。例えば、通知部102は、調理工程画像を画面に表示する。
記憶部103は、メモリ、ハードディスク装置などの記憶デバイスである。例えば、記憶部103は、送受信部104で受信された調理工程画像の情報(以下、調理工程画像情報という)を記憶する。また、例えば、記憶部103は、ユーザIDを記憶する。ユーザIDは、端末100のユーザを識別可能な情報である。
送受信部104は、他の装置と通信する通信インターフェースである。例えば、送受信部104は、サーバ300から調理工程画像情報を受信する。また、例えば、送受信部104は、所定の調理工程が完了した旨を示す完了情報をサーバ300へ送信する。
制御部105は、種々の情報処理を実行するプロセッサなどの制御デバイスである。例えば、制御部105は、送受信部104で受信された調理工程画像情報を記憶部103に格納し、所定のタイミングで記憶部103から調理工程画像情報を読み出し、調理工程画像を表示するように通知部102を制御する。
また、例えば、制御部105は、調理工程画像の表示中に入力部101により工程完了操作が受け付けられた場合、上記完了情報を生成する。工程完了操作とは、例えば、ユーザが調理工程(表示中の調理工程画像により示される調理工程)を完了した際に入力部101に対して行う操作である。また、完了情報は、上述したとおり、所定の調理工程が完了したことを示す情報である。この完了情報には、記憶部103から読み出されたユーザIDのほか、レシピを識別可能な情報であるレシピIDと、調理工程を識別可能な情報である調理工程IDとが含まれる。レシピIDと調理工程IDは、サーバ300から受信された調理工程画像情報に付加されている。そして、制御部105は、生成した完了情報をサーバ300へ送信するように送受信部104を制御する。
以上、端末100の構成について説明した。
次に、調理機器200の構成について説明する。
調理機器200は、端末100のユーザにより使用される調理機器であり、例えば、電子レンジ、IH(Induction Heating)調理器、ガスコンロ、またはフライパンなどである。なお、調理機器200は、これらに限定されない。
調理機器200は、入力部201、記憶部202、制御部203、送受信部204を備える。
入力部201は、情報の入力を受け付ける入力デバイスである。この入力部201は、ボタン、タッチパネルなど、ユーザの操作を受け付ける操作受付デバイスを有するとともに、バーコードリーダ、QRコード(登録商標)リーダ、ICタグリーダなどの情報読取デバイスを有する。例えば、入力部201は、操作受付デバイスとして機能する場合、調理機器200の機能(例えば、加熱機能)の実行を指示する操作を受け付ける。また、例えば、入力部201は、情報読取デバイスとして機能する場合、容器500から容器ID501を取得する。容器ID501は、容器500を識別可能な情報である。
ここで、容器500の一例について説明する。図3に示すように、容器500は、例えば樹脂などで形成された、密閉可能な容器である。ユーザは、下ごしらえした食材を容器500に収容し、冷蔵庫または冷凍庫などに保管する。図示は省略しているが、例えば、容器500の蓋には、容器ID501を表すバーコードまたはQRコードが付加される。あるいは、容器500の蓋には、容器ID501を記録したICタグが付加されてもよい。本実施の形態では、例えば、一人(上記グループ10でもよい)のユーザにより複数の容器500が使用されるとする。以上、容器500の一例について説明した。
記憶部202は、メモリ、ハードディスク装置などの記憶デバイスである。例えば、記憶部202は、ユーザIDを記憶する。
制御部203は、種々の情報処理を実行するプロセッサなどの制御デバイスである。例えば、制御部203は、入力部201により受け付けられた入力操作に応じて調理機器200の機能を制御する。
また、例えば、制御部203は、入力部201により容器ID501が取得されると、記憶部202からユーザIDを読み出し、ユーザIDと容器ID501を含む容器情報を生成する。そして、制御部203は、生成した容器情報をサーバ300へ送信するように送受信部204を制御する。
送受信部204は、他の装置と通信する通信インターフェースである。例えば、送受信部204は、サーバ300へ容器情報を送信する。
以上、調理機器200の構成について説明した。
次に、サーバ300の構成について説明する。
サーバ300(本発明のサーバ装置の一例)、端末100に調理工程画像を提供するとともに、端末100のユーザにより使用される容器500を管理する情報処理装置である。
サーバ300は、送受信部301、記憶部302、制御部303を備える。
送受信部301は、他の装置と通信する通信インターフェースである。例えば、送受信部301は、端末100へ調理工程画像情報を送信する。また、例えば、送受信部301は、端末100から上述した完了情報を受信する。また、例えば、送受信部301は、調理機器200から上述した容器情報を受信する。
記憶部302は、メモリ、ハードディスク装置などの記憶デバイスである。例えば、記憶部302は、調理工程画像情報、レシピ情報、容器画像情報、容器管理情報を記憶する。以下、各情報について説明する。
調理工程画像情報は、調理工程画像の画像データ(例えば、HTML/XHTML等のウェブページのデータ)である。調理工程画像とは、上述したとおり、所定の料理のレシピにおける調理工程に対応する画像である。例えば、調理工程画像は、調理方法等が文字、図形、記号、写真等により示される画像である。本実施の形態では、所定のレシピは複数の調理工程を含むものとする。よって、調理工程画像は、各調理工程に対応して予め用意されている。また、各調理工程画像が端末100の画面に表示される順番は、調理工程の順番に対応して予め定められている。
また、各調理工程画像情報には、レシピIDおよび調理工程ID(例えば、図4参照)が付加されている。また、下ごしらえの調理工程に対応する調理工程画像情報には、メタデータが付加されている。このメタデータは、調理工程画像により示される調理工程が食材収容工程であることを示すデータである。食材収容工程とは、ユーザが、所定の食材の下ごしらえを行い、その食材を容器500に収容し、冷蔵庫または冷凍庫等に保管する調理工程である。
レシピ情報は、レシピごとの調理工程を示すテーブルである。レシピ情報の例を図4に示す。図4に示すように、レシピ情報では、レシピIDと、調理工程IDとが対応付けられている。例えば、レシピID「R1」に対しては、3つの調理工程に対応する調理工程IDが対応付けられている。例えば、調理工程ID「R1−ST1」は、第1の調理工程(最初の調理工程)に対応するIDである。また、調理工程ID「R1−ST2」は、第2の調理工程(2番目の調理工程)に対応するIDである。また、調理工程ID「R1−ST3」は、第3の調理工程(最後の調理工程。仕上げの調理工程ともいう)に対応するIDである。よって、図4のレシピ情報では、調理工程IDは、調理工程の順に登録されている。
容器画像情報(容器態様情報の一例)は、容器画像の画像データ(例えば、JPEG/GIF/PNG/BMP等の画像ファイル)である。容器画像は、例えば、容器500の態様が文字、写真等により示される画像である。本実施の形態では例として、容器画像は、容器500の外観の写真を示す画像であるとする。本実施の形態では、上述したとおり、一人のユーザにより複数の容器500が使用されるとする。よって、容器画像は、各容器500に対応して予め用意されている。そして、各容器画像情報には、容器ID501が付加されている。
容器管理情報は、一人のユーザにより使用される複数の容器500それぞれの使用状況(使用中であるか否か)を示すテーブルである。容器管理情報の例を図5に示す。図5に示すように、容器管理情報では、ユーザIDと、容器IDと、レシピIDと、調理工程IDとが対応付けられている。図5では例として、ユーザID「U001」のユーザに使用される容器500として、容器ID「C1」〜「C10」に対応する10個の容器500が登録されている。図5では、容器ID「C1」〜「C10」に対応するレシピIDおよび調理工程IDが全て未登録(ブランク)である。これは、容器ID「C1」〜「C10」に対応する10個の容器500がいずれも使用されていないことを示している。ここで、例えば、ユーザによりレシピR1(レシピID「R1」に対応するレシピ)の第2の調理工程(調理工程ID「R1−ST2」に対応する調理工程)が実行され、容器ID「C1」に対応する容器500が使用されたとする。この場合、後述する制御部303により、図5の容器管理情報において、容器ID「C1」に対応するレシピIDと調理工程IDのそれぞれに「R1」と「R1−ST2」が登録される。これにより、容器ID「C1」に対応する容器500が使用中であることが示されることになる。
以上、記憶部302に記憶される各情報について説明した。
制御部303は、種々の情報処理を実行するプロセッサなどの制御デバイスである。以下、制御部303が行う処理の一例について説明する。
まず、制御部303は、端末100へ送信する調理工程画像情報として、所定レシピの全調理工程にそれぞれ対応する調理工程画像情報を記憶部302から読み出す。ここでいうレシピは、端末100のユーザにより要求されたレシピでもよいし、または、制御部303が所定の基準に従って選択したレシピでもよい。次に、制御部303は、読み出した調理工程画像情報のうち、上述したメタデータ(調理工程画像により示される調理工程が食材収容工程であることを示すデータ)が付加されている調理工程画像情報を特定する。
次に、制御部303は、端末100のユーザに対応する容器管理情報(例えば、図5参照)を記憶部302から読み出し、その容器管理情報において、レシピIDおよび調理工程IDが登録されていない(すなわち、ブランクである)容器IDのうち、任意の1つを選択する。この容器IDに対応する容器に食材が収容される。
次に、制御部303は、選択した容器IDと同じ容器IDが付加されている容器画像情報を記憶部302から読み出す。次に、制御部303は、読み出した容器画像情報と、メタデータが付加されている調理工程画像情報とを合成する。これにより、食材収容工程に対応する調理工程画像には容器画像が含まれることになる(後述の図7参照)。
次に、制御部303は、容器管理情報において、選択した容器IDに対応付けられているレシピIDおよび調理工程IDに対し、特定した調理工程画像情報に付加されている調理工程IDおよびレシピIDを仮登録する。そして、制御部303は、仮登録により更新した容器管理情報を記憶部302に格納する。ここで、仮登録とは、例えば、食材収容工程において複数の容器が使用される場合、先に選択された容器が再び選択されることを防ぐために行われる。
次に、制御部303は、記憶部302から読み出した全ての調理工程画像情報を端末100へ送信するように送受信部301を制御する。ここでいう全ての調理工程画像情報には、容器画像が合成された調理工程画像の調理工程画像情報が含まれている。また、ここでいう全ての調理工程画像情報には、レシピIDおよび調理工程IDが付加されている。
その後、制御部303は、送受信部301により端末100からの完了情報が受信されると、完了情報に含まれるユーザIDと同じユーザIDを含む容器管理情報を記憶部302から読み出す。この場合の完了情報は、食材収容工程が完了されたことを示す。
次に、制御部303は、読み出した容器管理情報において、完了情報に含まれるレシピIDおよび調理工程IDと同じレシピIDおよび調理工程ID(すなわち、仮登録されているレシピIDと調理工程ID)を本登録する。本登録とは、容器管理情報における登録を確定することである。そして、制御部303は、本登録により更新した容器管理情報を記憶部302に格納する。
なお、一定時間が経過しても、仮登録されたレシピIDおよび調理工程IDを含む完了情報が端末100から受信されない場合、制御部303は、容器管理情報において、仮登録のレシピIDおよび調理工程IDを削除し、ブランクに戻す。
その後、制御部303は、送受信部301により調理機器200からの容器情報が受信されると、容器情報に含まれるユーザIDと同じユーザIDを含む容器管理情報を記憶部302から読み出す。
次に、制御部303は、容器管理情報において、容器情報に含まれる容器IDと同じ容器IDに対応付けられているレシピIDおよび調理工程IDを特定する。そして、制御部303は、容器管理情報を記憶部302に格納する。
次に、制御部303は、記憶部302からレシピ情報を読み出す。次に、制御部303は、レシピ情報において、特定したレシピIDと同じレシピIDに対応付けられている調理工程IDのうち、特定した調理工程IDが示す調理工程の次の調理工程(以下、後続調理工程という)を示す調理工程IDを特定する。次に、制御部303は、後続調理工程を示す調理工程IDが付加されている調理工程画像情報を記憶部302から読み出す。なお、後続調理工程は、容器500(容器情報に含まれる容器IDが付加されている容器500)に収容された食材が使用され、容器500が空になる調理工程(以下、食材使用工程という)であるとする。
次に、制御部303は、記憶部302から読み出した調理工程画像情報を端末100へ送信するように送受信部301を制御する。ここでいう調理工程画像情報には、レシピIDおよび調理工程IDが付加されている。
その後、制御部303は、送受信部301により端末100から完了情報が受信されると、完了情報に含まれるユーザIDと同じユーザIDを含む容器管理情報を記憶部302から読み出す。この場合の完了情報は、食材使用工程が完了されたことを示す。
次に、制御部303は、読み出した容器管理情報において、完了情報に含まれるレシピIDおよび調理工程IDと同じレシピIDおよび調理工程ID(すなわち、本登録されているレシピIDと調理工程ID)を削除し、ブランクに戻す。そして、制御部303は、登録の削除により更新した容器管理情報を記憶部302に格納する。これにより、容器500が空になったことが判定可能となる。
以上、制御部303が行う処理の一例について説明した。
<調理支援システムの動作>
次に、本実施の形態に係る調理支援システムの動作例について、図6を用いて説明する。図6は、本実施の形態の調理支援システムの動作例を示すフローチャートである。
以下では例として、図4のレシピID「R1」に示されるレシピ(以下、レシピR1という)の調理工程画像がサーバ200から端末100へ提供される場合について説明する。また、端末100のユーザのユーザIDは、図5の「U001」であるとする。
また、以下では、調理工程ID「R1−ST1」に示される調理工程を「第1の調理工程」、調理工程ID「R1−ST2」に示される調理工程を「第2の調理工程」、調理工程ID「R1−ST3」に示される調理工程を「第3の調理工程」という。
また、以下では、第1の調理工程に対応する調理工程画像を「第1の調理工程画像」といい、その画像データを「第1の調理工程画像情報」という。また、第2の調理工程に対応する調理工程画像を「第2の調理工程画像」といい、その画像データを「第2の調理工程画像情報」という。また、第3の調理工程に対応する調理工程画像を「第3の調理工程画像」といい、その画像データを「第3の調理工程画像情報」という。
まず、サーバ300において、制御部303は、レシピR1の第1〜第3の調理工程画像情報を記憶部302から読み出し、それらのうち、メタデータが付加されている調理工程画像情報を特定する(ステップS11)。ここでは例として、第2の調理工程が食材収容工程であるとし、第2の調理工程画像情報にメタデータが付加されているとする。
次に、制御部303は、特定した調理工程画像情報と、容器画像情報とを合成する(ステップS12)。例えば、制御部303は、図5の容器管理情報を記憶部302から読み出し、その容器管理情報において、レシピIDおよび調理工程IDがブランクである容器IDのうち、任意の1つを選択する。ここでは例として、容器ID「C1」が選択されるとする。次に、制御部303は、選択した容器ID「C1」を表すバーコードなどが付加されている容器画像情報を記憶部302から読み出す。次に、制御部303は、読み出した容器画像情報と、ステップS11で特定した第2の調理工程画像情報とを合成する。これにより、第2の調理工程画像には、蓋などに容器ID「C1」が付加されている容器500(以下、容器500C1という)の容器画像が含まれることになる(後述の図7参照)。
次に、制御部303は、容器管理情報において、レシピIDと調理工程IDの仮登録を行う(ステップS13)。例えば、制御部303は、図5の容器管理情報において、選択した容器ID「C1」に対し、ステップS11で特定した第2の調理工程画像情報に付加されているレシピID「R1」および調理工程ID「R1−DT2」を仮登録する。そして、制御部303は、その容器管理情報を記憶部302に格納する。
上記仮登録の後、制御部303は、レシピR1の第1〜第3の調理工程画像情報を端末100へ送信するように送受信部301を制御する。ここで、第2の調理工程画像情報は、第2の調理工程画像に容器500C1を示す容器画像が合成された画像データである。また、第1の調理工程画像情報には、レシピID「R1」と調理工程ID「R1−ST1」が付加されている。また、第2の調理工程画像情報には、レシピID「R1」と調理工程ID「R1−ST2」が付加されている。また、第3の調理工程画像情報には、レシピID「R1」と調理工程ID「R1−ST3」が付加されている。
次に、送受信部301は、レシピR1の第1〜第3の調理工程画像情報を端末100へ送信する(ステップS14)。
次に、端末100において、送受信部104は、サーバ300からレシピR1の第1〜第3の調理工程画像情報を受信する(ステップS15)。次に、制御部105は、第1〜第3の調理工程画像情報を記憶部103に格納する。そして、制御部105は、所定のタイミングで記憶部103から第1〜第3の調理工程画像情報を読み出し、第1〜第3の調理工程画像を調理工程順に表示するように通知部102を制御する。
次に、通知部102は、第1〜第3の調理工程画像それぞれの画面表示を行う(ステップS16)。なお、画面表示は、ユーザによる画面表示の遷移操作に基づいて遷移が行われてもよい。遷移操作とは、例えば、画面表示が調理工程順に遷移する順遷移を指示する操作、または、画面表示が調理工程順とは逆の順に遷移する逆遷移を指示する操作である。
ここで、図7を用いて、第2の調理工程画像の表示例について説明する。図7は、端末100における第2の調理工程画像の表示例を示す。図7の例では、第2の調理工程画像が端末100のタッチパネル110(入力部101と通知部102の一例)に表示されるとする。
図7に示すように、タッチパネル110に表示される第2の調理工程画像は、メッセージ21、完了ボタン22、容器画像23を含む。メッセージ21は、第2の調理工程の調理方法を文字で表す画像である。完了ボタン22は、ユーザの工程完了操作を受け付ける領域を表す画像である。容器画像23は、容器500C1の外観を示す画像である。
このような第2の調理工程画像の表示中において、ユーザは、メッセージ21に従って、食材の下ごしらえを行い、容器画像23が示す容器500C1に食材を入れ、容器500C1を冷蔵庫に保管する。その後、ユーザは、完了ボタン22をタッチし、工程完了操作を行う。ここで、ユーザは、第3の調理工程には進まず、レシピR1の調理を中断するとする。これにより、端末100における調理工程画像の画面表示も終了する。
なお、上記説明では、メッセージ21に示すように、下ごしらえ後の食材の保管方法として冷蔵庫での保管が指定された例としたが、保管方法は、これに限定されず、例えば、冷凍庫保管、チルド保管、常温保管などであってもよい。また、図7の調理工程画像において、複数の保管方法の中からユーザが所望の保管方法を選択できるように提示してもよい。
以上、第2の調理工程画像の表示例について説明した。以下、フローの説明に戻る。
入力部101により第2の調理工程の完了を示す工程完了操作が受け付けられた場合、制御部105は、完了情報を生成する(ステップS17)。例えば、制御部105は、記憶部103から読み出したユーザID「U001」と、第2の調理工程画像情報に付加されているレシピID「R1」および調理工程ID「R1−ST2」とを含む完了情報(第1完了情報の一例)を生成する。
次に、送受信部104は、完了情報をサーバ300へ送信する(ステップS18)。
次に、サーバ300において、送受信部301は、端末100から完了情報を受信する(ステップS19)。
次に、制御部303は、容器管理情報において、レシピIDと調理工程IDの本登録を行う(ステップS20)。例えば、制御部303は、完了情報に含まれるユーザID「U001」を含む図5の容器管理情報を記憶部302から読み出す。この容器管理情報は、上記ステップS13で仮登録が行われたものである。次に、制御部303は、容器管理情報において、完了情報に含まれるレシピID「R1」および調理工程ID「R1−ST2」を仮登録から本登録に変更する。そして、制御部303は、その容器管理情報を記憶部302に格納する。
なお、一定時間が経過しても、レシピID「R1」および調理工程ID「R1−ST2」を含む完了情報が端末100から受信されない場合、制御部303は、容器管理情報において、仮登録されているレシピID「R1」および調理工程ID「R1−ST2」を削除し、ブランクに戻す。
このようにして、容器500C1が使用中であることがサーバ300に登録される。
次に、ユーザが、レシピR1の調理を再開する場合について説明する。例えば、ユーザは、冷蔵庫に保管しておいた容器500C1取り出し、その容器500C1を調理機器200(例えば、電子レンジとする)の庫内に入れるとする。
まず、調理機器200において、入力部201は、容器500C1に付加されている容器ID「C1」を取得する(ステップS21)。
次に、制御部203は、記憶部202からユーザID「U001」を読み出し、そのユーザID「U001」と容器ID「C1」を含む容器情報を生成する(ステップS22)。この容器情報は、換言すれば、調理の再開、すなわち第3の調理工程の開始を示す開始情報である。
次に、送受信部204は、容器情報をサーバ300へ送信する(ステップS23)。
次に、サーバ300において、送受信部301は、調理機器200から容器情報を受信する(ステップS24)。
次に、制御部303は、記憶部302から調理工程画像情報を読み出す(ステップS25)。ここで読み出される調理工程画像情報は、例えば、第2の調理工程の次の第3の調理工程に対応する第3の調理工程画像の画像データである。ここで、読み出し対象となる第3の調理工程画像情報を特定する処理の一例について説明する。
例えば、制御部303は、容器情報に含まれるユーザID「U001」を含む図5の容器管理情報を記憶部302から読み出す。この容器管理情報は、上記ステップS20で本登録が行われたものである。次に、制御部303は、容器管理情報において、容器情報に含まれる容器ID「C1」に対応付けられているレシピID「R1」および調理工程ID「R1−ST2」を特定する。そして、制御部303は、容器管理情報を記憶部302に格納する。
次に、制御部303は、記憶部302から図4のレシピ情報を読み出す。次に、制御部303は、レシピ情報において、特定したレシピID「R1」に対応付けられている調理工程ID「R1−ST1」〜「R1−ST3」のうち、特定した調理工程ID「R1−ST2」が示す第2の調理工程の次の調理工程の調理工程IDを特定する。ここでは、第3の調理工程を示す調理工程ID「R1−ST3」が特定される。次に、制御部303は、特定した調理工程ID「R1−ST3」が付加されている第3の調理工程画像情報を記憶部302から読み出す。なお、第3の調理工程は、容器500C1に収容された食材が使用され、容器500C1が空になる調理工程であるとする。
以上、ステップS25の一例として、読み出し対象となる第3の調理工程画像情報を特定する処理について説明した。以下、フローの説明に戻る。
次に、送受信部301は、レシピR1の第3の調理工程画像情報を端末100へ送信する(ステップS26)。この第3の調理工程画像情報には、レシピID「R1」および調理工程ID「R1−ST3」が付加されている。
次に、端末100において、送受信部104は、サーバ300からレシピR1の第3の調理工程画像情報を受信する(ステップS27)。次に、制御部105は、第3の調理工程画像情報を記憶部103に格納する。そして、制御部105は、所定のタイミングで記憶部103から第3の調理工程画像情報を読み出し、第3の調理工程画像を表示するように通知部102を制御する。
次に、通知部102は、第3の調理工程画像の画面表示を行う(ステップS28)。
ここで、図8を用いて、第3の調理工程画像の表示例について説明する。図8は、端末100における第3の調理工程画像の表示例を示す。
図8に示すように、タッチパネル110に表示される第3の調理工程画像は、完了ボタン22、メッセージ24を含む。完了ボタン22は、図7で説明したものと同じである。メッセージ24は、第3の調理工程の調理方法を文字で表す画像である。なお、図8の例では、メッセージ24は、電子レンジを用いた場合の調理方法を示すものとしたが、IH調理器を用いた場合の調理方法を示すものであってもよい。
このような第3の調理工程画像の表示中において、ユーザは、メッセージ24に従って、調理機器200により容器500C1の食材の加熱を行った後、食器に食材の盛り付けを行い、容器500C1を空にする。その後、ユーザは、完了ボタン22をタッチし、工程完了操作を行う。
以上、第3の調理工程画像の表示例について説明した。以下、フローの説明に戻る。
入力部101により第3の調理工程の完了を示す工程完了操作が受け付けられた場合、制御部105は、完了情報を生成する(ステップS29)。例えば、制御部105は、記憶部103から読み出したユーザID「U001」と、第3の調理工程画像情報に付加されているレシピID「R1」および調理工程ID「R1−ST3」とを含む完了情報(第2完了情報の一例)を生成する。
次に、送受信部104は、完了情報をサーバ300へ送信する(ステップS30)。
次に、サーバ300において、送受信部301は、端末100から完了情報を受信する(ステップS31)。
次に、制御部303は、容器管理情報において、レシピIDと調理工程IDの削除を行う(ステップS32)。例えば、制御部303は、完了情報に含まれるユーザID「U001」を含む図5の容器管理情報を記憶部302から読み出す。次に、制御部303は、容器管理情報において、完了情報に含まれるレシピID「R1」および調理工程ID「R1−ST2」を削除し、ブランクに戻す。そして、制御部303は、その容器管理情報を記憶部302に格納する。
このようにして、容器500C1が使用中ではないことがサーバ300に登録される。
なお、上記動作例の説明では、複数の調理工程のうち食材収容工程が1つである場合について説明したが、上記動作例は、食材収容工程が複数ある場合にも適用可能である。
以上のことから、本実施の形態によれば、ユーザは、調理を再開する際に、続きの調理工程画像を端末に表示させるための操作を行う必要がない。また、本実施の形態によれば、複数のレシピの各食材を複数の容器に分けて保管した場合、ユーザは、調理を再開する際に、どの容器にどのレシピの食材が入っているかを確認する必要がない。したがって、ユーザは調理工程の続きを容易に再開できる。
<実施の形態の変形例>
以上、本発明の実施の形態について説明したが、本発明は、その趣旨を逸脱しない範囲において種々の変形が可能である。以下、上記実施の形態の変形例について説明する。
(変形例1)
上記実施の形態では、例として、制御部303が食材収容工程に使用する容器500を任意に選択する場合について説明したが、制御部303が容器500の属性に基づいて容器500を選択してもよい。この具体例について以下に説明する。
サーバ300の記憶部302では、図9に示す容器管理情報が記憶される。図9に示すように、容器IDごとに、容器500の属性を示す情報(容器属性情報の一例)として容量と耐熱可否が登録されている。容量は、容器500の容量を示す情報である。耐熱可否は、容器500が調理機器200の加熱に耐えられるか否か(耐熱可の場合はOK、耐熱不可の場合はNG)を示す情報である。
また、記憶部302では、調理工程画像情報ごとに、調理工程の調理条件を示すメタデータ(調理条件情報の一例)が付加されている。調理条件とは、例えば、容器に収容される食材の量、加熱温度、加熱時間などである。
まず、制御部303は、食材収容工程の調理工程画像情報を特定した場合(図6のステップS11)、その情報に付加されているメタデータの調理条件(以下、第1の調理条件という)を読み出す。ここでは例として、第1の調理条件は、容器に収容される食材の量であるとする。
次に、制御部303は、上記食材収容工程の次の調理工程の調理工程画像情報を特定し、その情報に付加されているメタデータの調理条件(以下、第2の調理条件という)を読み出す。ここでは例として、第2の調理条件は、加熱温度および加熱時間であるとする。
次に、制御部303は、図9の容器管理情報に登録されている容器500の属性のうち、第1の調理条件と第2の調理条件の両方を満たす容器IDを検索する。例えば、制御部303は、容量が食材の量より大きく、かつ、耐熱性を有する容器IDを検索する。そして、制御部303は、上述したとおり、検索できた容器IDが付加された容器画像情報を記憶部302から読み出し、その容器画像情報と、食材収容工程の調理工程画像情報とを合成する(図6のステップS12)。
このように本変形例によれば、調理条件に適した容器をユーザに提示することができる。
なお、上記説明では、第1の調理条件を満たす大きさの容器IDを検索する場合としたが、第1の調理条件を満たす材質の容器IDを検索するようにしてもよい。例えば、食材収容工程で使用可能な材質(例えば、耐水性、耐油性、防臭性など)の容器の容器IDを検索するようにしてもよい。
(変形例2)
例えば、ユーザが、複数のレシピの下ごしらえを休日にまとめて行い、各食材を複数の容器500に収容して保管しておき、平日のそれぞれにおいて所定のレシピの調理を行う場合がある。このような場合、複数の容器500が冷蔵庫などに混在して保管されることになるため、ユーザが使用すべき容器500を間違えることが起こりうる。そこで、本変形例では、使用すべき容器500ではない旨をユーザに知らせることで上記間違いを防止する。この具体例について以下に説明する。
サーバ300の記憶部302では、図10に示す容器管理情報が記憶される。図10に示すように、容器IDごとに、調理予定日が登録されている。調理予定日は、調理工程IDが示す調理工程より後の調理工程(例えば、上述した後続調理工程)が行われる予定日を示す情報(調理予定日情報の一例)である。
この調理予定日は、制御部303が所定の基準に基づいて選択したものでもよいし、端末100のユーザが選択したものでもよい。前者の場合、調理予定日は、例えば、レシピIDおよび調理工程IDとともに、仮登録(図6のステップS13)、本登録(図5のステップS20)により登録されるようにしてもよい。一方、後者の場合、調理予定日は、例えば、端末100における食材収容工程の調理工程画像の表示の際(図6のステップS16)にユーザにより選択され、完了情報に含まれてサーバ300へ送信された後、本登録(図5のステップS20)により登録されるようにしてもよい。
制御部303は、送受信部301により調理機器200から容器情報が受信された場合(ステップS24)、図10の容器管理情報において、容器情報に含まれる容器IDと同じ容器IDに対応付けられている調理予定日が現在の日にちと一致するか否かを判定する。この判定の結果、日にちが一致しない場合、制御部303は、記憶部302から、予め用意された警告情報を読み出す。この警告情報は、現在の日にちが調理予定日ではない旨を表す画像および音声の少なくとも一方の情報(第1の警告情報の一例)である。そして、制御部303は、警告情報を端末100および調理機器200の少なくとも一方へ送信するように送受信部301を制御する。そして、端末100および調理機器200の少なくとも一方では、警告情報の出力が行われる。これにより、ユーザは、冷蔵庫等から取り出して調理に使用しようとした容器500がその日に使用すべきものはないことを認識できる。
このように本変形例によれば、ユーザが複数のレシピの下ごしらえを行い、複数の容器500が混在して保管される場合でも、ユーザは、使用すべき容器500を間違えることがない。
なお、図10の容器管理情報において、調理予定日以外に、保管方法(例えば、冷蔵庫保存、冷凍庫保存等)に対応した保管期限が登録されてもよい。この場合、サーバ300の制御部303は、現在時刻が保管期限に近づいた場合(例えば、現在時刻が保管期限の24時間前となった時)、警告情報を端末100へ送信するように送受信部301を制御してもよい。この警告情報は、例えば、食材の保管期限が近いことをユーザに知らせる旨(容器、レシピ、調理工程の各情報を含んでもよい)の画像である。このように、容器管理情報において食材ごとに保管期限を管理し、保管期限が近付いたときにユーザに通知することで、保管中の食材が無駄になることを防ぐことができる。
また、現在時刻が保管期限に近付いた場合、その保管期限に対応する保管方法より長く食材を保管できる保管方法がある場合、サーバ300の制御部303は、上記警告情報において、その保管方法をユーザに提示してもよい。例えば、現在時刻が冷蔵庫保存に対応する保管期限に近付いた場合、冷蔵庫保存よりも食材を長く保管できる冷凍庫保存がユーザに提示される。このように、現在実行中の保管方法に替わる保管方法をユーザに提示することにより、保管中の食材が無駄になることを防ぐことができる。なお、ユーザにより保管方法が変更された場合、容器管理情報の保管期限は、変更後の保管方法に対応して更新される。
(変形例3)
例えば、制御部303が食材収容工程に使用する容器500を選択する際に、複数の容器500が全て使用されている場合(すなわち、容器管理情報において全ての容器IDにレシピIDおよび調理工程IDが本登録されている場合)がありうる。この場合、制御部303は、記憶部302から、予め用意された警告情報を読み出す。この警告情報(第2の警告情報の一例)は、全ての容器500が使用中である旨を表す画像および音声の少なくとも一方の情報である。そして、制御部303は、警告情報を端末100および調理機器200の少なくとも一方へ送信するように送受信部301を制御する。そして、端末100および調理機器200の少なくとも一方では、警告情報の出力が行われる。これにより、ユーザは、全ての容器500が使用中であることを認識できる。
なお、上記説明では、例として、全ての容器500が使用中である場合について説明したが、容器500に空きがある場合でも、その容器500が上記変形例2で説明した調理条件を満たさない場合には、調理条件に適した容器がない旨を示す警告情報(第2の警告情報の一例)が出力されるようにしてもよい。
このように本変形例によれば、ユーザが使用可能な容器500がない場合、その旨をユーザに知らせることができる。
(変形例4)
上記実施の形態では、例として、容器500の容器ID501を調理機器200が取得する場合について説明したが、端末100の入力部101が容器ID501を取得してもよい。この場合、端末100は、容器ID501の取得後、上述した調理機器200と同じ処理動作(図6のステップS22〜S23)を行う。
このように本変形例によれば、後続調理工程が調理機器200を使用しない調理工程である場合でも、図6で説明した処理動作(図6のステップS24〜S32)を実現できる。
(変形例5)
上記実施の形態において、制御部303が後続調理工程を特定し、その調理工程画像情報を記憶部302から読み出した場合(図6のステップS25)、制御部303は、後続調理工程を実行するように調理機器200を制御してもよい。この具体例について以下に説明する。
例えば、記憶部302から読み出される後続調理工程の調理工程画像情報には、上記変形例1で説明した調理条件を示すメタデータが付加されているとする。ここでは例として、調理条件は、加熱温度および加熱時間であるとする。
制御部303は、上記加熱温度と加熱時間に基づいて調理機器200(例えば、電子レンジ)の加熱機能を制御する制御情報を生成し、その制御情報を調理機器200へ送信するように送受信部301を制御する。制御情報を受信した調理機器200は、制御情報に示される加熱温度および加熱時間に基づいて加熱機能を制御する。
なお、制御部303は、上記制御情報を調理機器200へ送信した場合、制御部303は、後続調理工程の調理工程画像情報(例えば、図8の調理工程画像の情報)の代わりに、例えば「電子レンジに容器を入れて下さい」といった指示メッセージを含む画像の情報を端末100へ送信してもよい。これにより、端末100のタッチパネル110には、上記指示メッセージを含む画像が表示される。
このように本変形例によれば、ユーザは、調理機器200に対して操作を行うことなく、調理機器200において後続調理工程を実行することができる。
(変形例6)
上記実施の形態では、例として、完了ボタン22のタッチにより工程完了操作が行われる場合について説明したが、工程完了操作は音声入力により行われてもよい。例えば、端末100のマイク(入力部101の一例)がユーザの発した所定の音声を入力し、制御部105がその入力音声を認識することで、工程完了操作として受け付けるようにしてもよい。あるいは、上記音声入力以外の手段として、ジェスチャ入力により工程完了操作が受付けられてもよい。
このように本変形例によれば、調理中において手が汚れたり、または手が離せなかったりする場合でも、ユーザは端末100に触れることなく、工程完了操作を行うことができる。
(変形例7)
上記実施の形態では、端末100において調理工程画像を表示するとしたが、端末100のスピーカ(通知部102の一例)において、所定の料理のレシピにおける調理工程に対応する音声(例えば、調理工程を説明する音声)を出力するようにしてもよい。この音声は調理工程画像とともに出力されてもよいし、または、音声だけが出力されてもよい。
(変形例8)
上記実施の形態では、サーバ300が容器管理情報に基づいて空き容器を選択し、その空き容器を端末100のユーザに提示し、ユーザがその容器を使用する例としたが、ユーザが空き容器を選択してもよい。例えば、端末100においてある調理工程画像が画面表示された際に、ユーザが空いている容器500を選択し、その容器IDを端末100または調理機器200に読み取らせてもよい。その後、容器IDは、端末100または調理機器200からサーバ300へ送信され、サーバ300において、レシピIDおよび調理工程ID(画面表示中の調理工程画像に対応するレシピIDおよび調理工程ID)とともに容器管理情報に本登録される。
(変形例9)
上記実施の形態において、最後(仕上げ)の調理工程に対応する複数の調理工程画像を予め用意しておき、その調理工程が行われる時間に応じた調理工程画像をユーザに提示してもよい。
この場合、最後の調理工程に対応する複数の調理工程画像には、所定の時間帯(例えば、朝、夜など)が対応付けられている。朝に対応する調理工程画像は、調理時間のかからない調理方法(例えば、電子レンジを用いた調理方法)を示す画像である。また、夜に対応する調理工程画像は、調理時間がかかる調理方法(例えば、フライパンを用いた調理方法)を示す画像である。
そして、サーバ300の制御部303は、現在時刻が朝に相当する場合、最後の調理工程に対応する複数の調理工程画像のうち、朝に対応する調理工程画像を選択する。一方、制御部303は、現在時刻が夜に相当する場合、最後の調理工程に対応する複数の調理工程画像のうち、夜に対応する調理工程画像を選択する。このように選択された調理工程画像は、サーバ300から端末100へ送信され、端末100において画面表示される。
このように、同じ調理工程でも、調理時間をとりにくい朝では時短優先で電子レンジを用いた調理方法が提示され、調理時間がとりやすい夜では美味しさ優先でフライパンを用いた調理方法が提示される。
また、最後の調理工程に対応する複数の調理工程画像には、所定の調理機器(例えば、電子レンジ、IH調理器など)が対応付けられてもよい。電子レンジに対応する調理工程画像は、電子レンジを用いた調理方法を示す画像である。また、IH調理器に対応する調理工程画像は、IH調理器を用いた調理方法を示す画像である。
そして、調理機器200は、容器情報を生成する際(図6のステップS22)、容器IDとともに、調理機器200の種別(例えば、電子レンジ、IH調理器など)を示す種別情報を含む容器情報を生成する。そして、この容器情報は、サーバ300へ送信される。
そして、サーバ300の制御部303は、調理機器200から受信した容器情報に含まれる種別情報が電子レンジを示す場合、最後の調理工程に対応する複数の調理工程画像のうち、電子レンジに対応する調理工程画像を選択する。一方、制御部303は、調理機器200から受信した容器情報に含まれる種別情報がIH調理器を示す場合、最後の調理工程に対応する複数の調理工程画像のうち、IH調理器に対応する調理工程画像を選択する。このように選択された調理工程画像は、サーバ300から端末100へ送信され、端末100において画面表示される。
このように、同じ調理工程でも、容器IDが読み取られた調理機器200に応じて調理方法が提示される。
(変形例10)
上記実施の形態では、例として、サーバ300を用いる場合について説明したが、サーバ300で行われる処理動作(例えば、図6のステップS11〜S14、S20、S24〜S26、S32)を端末100が行うようにしてもよい。なお、この場合、端末100は、調理工程画像情報、レシピ情報、容器画像情報、および容器管理情報を、記憶部103に保持していてもよいし、または、サーバ300または図示しない記憶装置から適宜取得してもよい。
以上、本実施の形態の変形例を説明した。なお、上記変形例は任意に組み合わせてもよい。
<コンピュータプログラムによる実現例>
以上、本発明に係る実施形態について図面を参照して詳述してきたが、上述した端末100、調理機器200、およびサーバ300(以下、各装置という)の機能は、コンピュータプログラムにより実現され得る。
図11は、各部の機能をプログラムにより実現するコンピュータのハードウェア構成を示す図である。このコンピュータ1000は、入力ボタン、タッチパッドなどの入力装置1001、ディスプレイ、スピーカなどの出力装置1002、CPU(Central Processing Unit)1003、ROM(Read Only Memory)1004、RAM(Random Access Memory)1005を備える。また、コンピュータは、ハードディスク装置、SSD(Solid State Drive)などの記憶装置1006、DVD−ROM(Digital Versatile Disk Read Only Memory)、USB(Universal Serial Bus)メモリなどの記録媒体から情報を読み取る読取装置1007、ネットワークを介して通信を行う送受信装置1008を備える。上記各部は、バス1009により接続される。
そして、読取装置1007は、上記各部の機能を実現するためのプログラムを記録した記録媒体からそのプログラムを読み取り、記憶装置1006に記憶させる。あるいは、送受信装置1008が、ネットワークに接続されたサーバ装置と通信を行い、サーバ装置からダウンロードした上記各部の機能を実現するためのプログラムを記憶装置1006に記憶させる。
そして、CPU1003が、記憶装置1006に記憶されたプログラムをRAM1005にコピーし、そのプログラムに含まれる命令をRAM1005から順次読み出して実行することにより、上記各部の機能が実現される。また、プログラムを実行する際、RAM1005または記憶装置1006には、各実施の形態で述べた各種処理で得られた情報が記憶され、適宜利用される。
<クラウドサービスの類型>
また、上記実施の形態において説明された技術は、例えば、以下のクラウドサービスの類型において実現されうる。しかし、上記実施の形態において説明された技術が実現される類型はこれに限られるものでない。
(サービスの類型1:自社データセンタ型)
図12は、サービスの類型1(自社データセンタ型)を示す図である。本類型は、サービスプロバイダ12がグループ10から情報を取得し、ユーザに対してサービスを提供する類型である。本類型では、サービスプロバイダ12が、データセンタ運営会社の機能を有している。即ち、サービスプロバイダ12が、ビッグデータの管理をするクラウドサーバ11aを保有している。従って、データセンタ運営会社は存在しない。
本類型では、サービスプロバイダ12は、データセンタ(クラウドサーバ11a)を運営、管理している(1200c)。また、サービスプロバイダ12は、OS(1200b)及びアプリケーション(1200a)を管理する。サービスプロバイダ12は、サービスプロバイダ12が管理するOS(1200b)及びアプリケーション(1200a)を用いてサービス提供を行う(1200d)。
(サービスの類型2:IaaS利用型)
図13は、サービスの類型2(IaaS利用型)を示す図である。ここでIaaSとはインフラストラクチャー・アズ・ア・サービスの略であり、コンピュータシステムを構築および稼動させるための基盤そのものを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。
本類型では、データセンタ運営会社11がデータセンタ(クラウドサーバ11a)を運営、管理している(1200c)。また、サービスプロバイダ12は、OS(1200b)及びアプリケーション(1200a)を管理する。サービスプロバイダ12は、サービスプロバイダ12が管理するOS(1200b)及びアプリケーション(1200a)を用いてサービス提供を行う(1200d)。
(サービスの類型3:PaaS利用型)
図14は、サービスの類型3(PaaS利用型)を示す図である。ここでPaaSとはプラットフォーム・アズ・ア・サービスの略であり、ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供するクラウドサービス提供モデルである。
本類型では、データセンタ運営会社11は、OS(1200b)を管理し、データセンタ(クラウドサーバ11a)を運営、管理している(1200c)。また、サービスプロバイダ12は、アプリケーション(1200a)を管理する。サービスプロバイダ12は、データセンタ運営会社11が管理するOS(1200b)及びサービスプロバイダ12が管理するアプリケーション(1200a)を用いてサービス提供を行う(1200d)。
(サービスの類型4:SaaS利用型)
図15は、サービスの類型4(SaaS利用型)を示す図である。ここでSaaSとはソフトウェア・アズ・ア・サービスの略である。例えばデータセンタ(クラウドサーバ11a)を保有しているプラットフォーム提供者が提供するアプリケーション1200aを、データセンタ(クラウドサーバ11a)を保有していない会社・個人(利用者)がインターネットなどのネットワーク経由で使用できる機能を有するクラウドサービス提供モデルである。
本類型では、データセンタ運営会社11は、アプリケーション(1200a)を管理し、OS(1200b)を管理し、データセンタ(クラウドサーバ11a)を運営、管理している(1200c)。また、サービスプロバイダ12は、データセンタ運営会社11が管理するOS(1200b)及びアプリケーション(1200a)を用いてサービス提供を行う(1200d)。
以上いずれの類型においても、サービスプロバイダ12がサービス提供行為を行ったものとする。また例えば、サービスプロバイダ12若しくはデータセンタ運営会社11は、OS1200b、アプリケーション1200a若しくはビッグデータのデータベース等を自ら開発してもよいし、また、第三者に外注させてもよい。