特開 2024-110699 情報処理装置及び情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024110699

(43)【公開日】2024-08-16

(54)【発明の名称】情報処理装置及び情報処理プログラム

(51)【国際特許分類】

   G06Q 50/12 20120101AFI20240808BHJP

【ＦＩ】

G06Q50/12

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023015438

(22)【出願日】2023-02-03

(71)【出願人】

【識別番号】000003562

【氏名又は名称】東芝テック株式会社

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(72)【発明者】

【氏名】綿田 将悟

【テーマコード（参考）】

5L049

5L050

【Ｆターム（参考）】

5L049CC24

5L050CC24

(57)【要約】

【課題】 複数の客席間でのサービス提供レベルのばらつきを抑えられるような調理支援を可能とする。
【解決手段】 実施形態の情報処理装置は、管理手段及び決定手段を備える。管理手段は、調理開始待ちの料理を、その料理の注文がなされた客席に関連付けて管理する。決定手段は、管理手段により管理されている料理の調理に関する諸条件を考慮しつつ、かつ複数の客席のそれぞれでの料理提供の待機時間の平準化を図りつつ、管理手段により管理されている料理の調理開始順序を決定する。
【選択図】 図４

【特許請求の範囲】

【請求項1】

調理開始待ちの料理を、その料理の注文がなされた客席に関連付けて管理する管理手段と、
前記管理手段により管理されている料理の調理に関する諸条件を考慮しつつ、かつ複数の客席のそれぞれでの料理提供の待機時間の平準化を図りつつ、前記管理手段により管理されている料理の調理開始順序を決定する決定手段と、
を具備する情報処理装置。

【請求項2】

前記決定手段は、調理に関する諸条件としては、料理のカテゴリ、調理に要する標準的な時間、調理可能なスタッフの人数、該当の料理を同時に調理可能な数を考慮する、
請求項１に記載の情報処理装置。

【請求項3】

前記決定手段は、調理に関する諸条件としては、料理毎に予め定められルールを考慮する、請求項１に記載の情報処理装置。

【請求項4】

前記決定手段は、調理に関する諸条件を考慮して、互いに異なる複数の調理開始順序を候補順序として定め、これら複数の候補順序のうちで複数の客席のそれぞれの待機時間が平準化する候補順序を選択して調理開始順序として決定する、
請求項１に記載の情報処理装置。

【請求項5】

前記決定手段は、複数の候補順序のそれぞれに関して、複数の客席のそれぞれの待機時間の平均値及び最大値と、諸条件を満たさない度合いを表す値との総和を求めて、当該の総和がより小さな候補順序を選択して調理開始順序として決定する、
請求項４に記載の情報処理装置。

【請求項6】

コンピュータを、
調理開始待ちの料理を、その料理の注文がなされた客席に関連付けて管理する管理手段と、
前記管理手段により管理されている料理の調理に関する諸条件を考慮しつつ、かつ複数の客席のそれぞれでの料理提供の待機時間の平準化を図りつつ、前記管理手段により管理されている料理の調理開始順序を決定する決定手段と、
して機能させるための情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、情報処理装置及び情報処理プログラムに関する。

【背景技術】

【0002】

飲食店等における調理支援を行うシステムは提案されている。
しかしながら、従来のシステムにおいては、調理時間の短縮を目的として、効率的に調理を行い得るように支援するものであった。
このため、例えば一部の客席で注文された複数の料理が、別の客席で注文された料理よりも優先的に調理されてしまい、サービス提供レベルの客席毎でのばらつきを生じさせてしまう場合があった。
このような事情から、複数の客席間でのサービス提供レベルのばらつきを抑えられるような調理支援が望まれていた。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００５－５６０５０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明が解決しようとする課題は、複数の客席間でのサービス提供レベルのばらつきを抑えられるような調理支援を行える情報処理装置及び情報処理プログラムを提供することである。

【課題を解決するための手段】

【0005】

実施形態の情報処理装置は、管理手段及び決定手段を備える。管理手段は、調理開始待ちの料理を、その料理の注文がなされた客席に関連付けて管理する。決定手段は、管理手段により管理されている料理の調理に関する諸条件を考慮しつつ、かつ複数の客席のそれぞれでの料理提供の待機時間の平準化を図りつつ、管理手段により管理されている料理の調理開始順序を決定する。

【図面の簡単な説明】

【0006】

【図1】一実施形態に係る調理支援装置の要部回路構成を示すブロック図。

【図2】図１中のメニューデータベースに含まれる１つのデータレコードのデータ構造を模式的に表す図。

【図3】図１中のポリシーデータベースに含まれる１つのデータレコードのデータ構造を模式的に表す図。

【図4】支援処理のフローチャート。

【図5】図１中の注文データに含まれる１つのデータレコードのデータ構造を模式的に表す図。

【図6】図１中の履歴データベースに含まれる１つのデータレコードのデータ構造を模式的に表す図。

【図7】図１中の制約データに含まれる１つのデータレコードのデータ構造を模式的に表す図。

【図8】待機時間のイメージを表す図。

【図9】指示画面の一例を表す図。

【発明を実施するための形態】

【0007】

以下、実施の形態の一例について図面を用いて説明する。なお、本実施の形態では、複数の客席を備える飲食店で提供する料理の調理を支援するための調理支援装置を例に説明する。
図１は本実施形態に係る調理支援装置１の要部回路構成を示すブロック図である。
調理支援装置１は、通信ネットワーク４を介して通信可能とされた注文入力装置２及び調理者端末３とともに調理支援システムを構成する。
調理支援装置１は、調理待ちとなっている料理の調理開始順序を判定し、調理を行うスタッフを支援するための情報処理を実行する情報処理装置である。

【0008】

注文入力装置２は、料理の注文を入力するためのユーザインタフェース装置である。注文入力装置２は、例えば接客を担当する店員により持ち運ばれて、当該店員が操作者となるハンディタイプ、あるいは、客席に設置されて、当該客席を使用する客が操作者となる客席端末タイプなどの様々なタイプのいずれであってもよい。あるいは注文入力装置２としては、客が所持するスマートフォンなどの情報通信端末が用いられてもよい。

【0009】

調理者端末３は、調理を行うスタッフの個々に割り当てられ、そのスタッフによる調理を支援するためのユーザインタフェース装置である。調理者端末３としては、例えばタブレットコンピュータを用いることが想定される。
通信ネットワーク４は、インターネット、ＶＰＮ（virtual private network）、ＬＡＮ（local area network）、公衆通信網、移動体通信網などを、単独又は適宜に組み合わせて用いることができる。通信ネットワーク４としては、一例として、ＬＡＮが用いられる。

【0010】

調理支援装置１は、ＣＰＵ（central processing unit）１１、メイン記憶ユニット１２、補助記憶ユニット１３、表示ユニット１４、操作ユニット１５、通信モジュール１６及び伝送路１７等を備える。ＣＰＵ１１、メイン記憶ユニット１２、補助記憶ユニット１３、表示ユニット１４、操作ユニット１５、通信モジュール１６は、伝送路１７を介して接続される。

【0011】

ＣＰＵ１１、メイン記憶ユニット１２及び補助記憶ユニット１３を伝送路１７で接続することによって、調理支援装置１を制御するための情報処理を行うコンピュータを構成する。
ＣＰＵ１１は、上記コンピュータの中枢部分に相当する。ＣＰＵ１１は、オペレーティングシステム及びアプリケーションプログラムなどの情報処理プログラムに従って、調理支援装置１としての機能を実現するべく情報処理を実行する。

【0012】

メイン記憶ユニット１２は、上記コンピュータの主記憶部分に相当する。メイン記憶ユニット１２は、読み出し専用のメモリ領域と書き換え可能なメモリ領域とを含む。メイン記憶ユニット１２は、読み出し専用のメモリ領域では上記の情報処理プログラムの一部を記憶する。またメイン記憶ユニット１２は、ＣＰＵ１１が各部を制御するための処理を実行する上で必要なデータを読み出し専用のメモリ領域又は書き換え可能なメモリ領域で記憶する場合もある。メイン記憶ユニット１２は、書き換え可能なメモリ領域を、ＣＰＵ１１によるワークエリアとして使用する。メイン記憶ユニット１２は，ワークエリアとして使用するメモリ領域に、注文データＤＡＡ及び制約データＤＡＢを記憶する。注文データＤＡＡは、注文されて調理開始待ちとなっている料理を、その料理の注文がなされた客席に関連付けて管理するためのデータである。制約データＤＡＢは、調理開始待ちとなっている料理の調理開始順序を決めるに当たっての制約を管理するためのデータである。注文データＤＡＡ及び制約データＤＡＢの詳細は後述する。

【0013】

補助記憶ユニット１３は、上記コンピュータの補助記憶部分に相当する。補助記憶ユニット１３は、例えばＥＥＰＲＯＭ（electric erasable programmable read-only memory）、ＨＤＤ（hard disc drive）、ＳＳＤ（solid state drive）、あるいはその他の周知の各種の記憶デバイスを利用できる。補助記憶ユニット１３は、ＣＰＵ１１が各種の処理を行う上で使用するデータと、ＣＰＵ１１での処理によって生成されたデータとを記憶する。補助記憶ユニット１３は、上記の情報処理プログラムを記憶する場合もある。補助記憶ユニット１３は、本実施形態では、情報処理プログラムの１つである調理支援プログラムＰＲＡを記憶する。補助記憶ユニット１３の記憶領域の一部は、メニューデータベースＤＢＡ、ポリシーデータベースＤＢＢ及び履歴データベースＤＢＣを記憶する領域として利用される。

【0014】

表示ユニット１４は、調理支援装置１の管理者などに対して各種の情報を提示するための表示を行う。表示ユニット１４は、画面表示デバイス、文字表示デバイス、発光デバイスなどの周知の様々な表示デバイスを単独又は組み合わせて用いて構成されてよい。典型的には、表示ユニット１４としては、液晶表示デバイス等の画面表示デバイスを備える。

【0015】

操作ユニット１５は、操作者による操作を受ける。操作ユニット１５は、タッチセンサ、キーボード、ポインティングデバイス、スイッチなどの周知の様々な操作デバイスを単独又は組み合わせて用いて構成されてよい。典型的には、操作ユニット１５として、キーボードと、マウスなどのポインティングデバイスとを備える。

【0016】

通信モジュール１６は、通信ネットワーク４を介したデータ通信を行うための通信処理を実行する。通信モジュール１６は、例えばＬＡＮ（local area network）用の既存の通信デバイスを用いることができる。
伝送路１７は、アドレスバス、データバス及び制御信号線等を含み、接続された各部の間で授受されるデータ及び制御信号を伝送する。

【0017】

調理支援装置１のハードウェアとしては、例えば汎用のサーバ装置を用いることができる。そして調理支援装置１は、ローカルサーバ及びクラウドサーバのいずれの形態として運用されても構わない。調理支援装置１の譲渡は、例えば調理支援プログラムＰＲＡが補助記憶ユニット１３に記憶された状態で行われる。しかしながら、調理支援プログラムＰＲＡが補助記憶ユニット１３に記憶されない状態のハードウェアと、調理支援プログラムＰＲＡとが別々に譲渡された上で、調理支援プログラムＰＲＡが補助記憶ユニット１３に書き込まれるのでも構わない。調理支援プログラムＰＲＡの譲渡は、磁気ディスク、光磁気ディスク、光ディスク、半導体メモリなどのようなリムーバブルな記録媒体に記録して、あるいはネットワークを介して行われてよい。

【0018】

メニューデータベースＤＢＡは、調理支援装置１が利用される飲食店にて提供され得る料理を管理するためのデータベースである。
図２はメニューデータベースＤＢＡに含まれる１つのデータレコードＲＥＡのデータ構造を模式的に表す図である。
メニューデータベースＤＢＡは、それぞれ別々の料理に関連付けられた図２に表すデータレコードＲＥＡの集合である。データレコードＲＥＡは、フィールドＦＡＡ，ＦＡＢ，ＦＡＣ，ＦＡＤ，ＦＡＥ，ＦＡＦを含む。

【0019】

フィールドＦＡＡには、関連付けられた料理の識別子としての料理ＩＤがセットされる。フィールドＦＡＢには、関連付けられた料理の料理名がセットされる。フィールドＦＡＣには、関連付けられた料理が属するカテゴリがセットされる。フィールドＦＡＤには、関連付けられた料理の調理に要する標準的な時間として定められた調理時間がセットされる。フィールドＦＡＥには、関連付けられた料理の調理を担当するスタッフとして定められた調理可能スタッフの識別子としてのスタッフＩＤがセットされる。フィールドＦＡＦには、関連付けられた料理を同時に調理することが可能な数として予め定められた同時調理数がセットされる。なお、この例では、料理に対して一意に調理時間及び同時調理数を定義する。しかしながら、例えばスタッフごとの調理スキルの差を考慮して、スタッフ毎に、あるいはスタッフのスキルレベルに応じて異なる調理時間及び同時調理数が設定されても構わない。

【0020】

なお、各フィールドにセットされる具体的なデータの内容は、店舗の管理者などによって適宜に定められてよい。一例として、あるデータレコードＲＥＡの各フィールドには、「ＦＯ１０１」「刺身の盛り合わせ」「刺身」「７分」「ＳＴ０１」「２」がそれぞれセットされる。また一例として、別のあるデータレコードＲＥＡの各フィールドには、「ＦＯ２０５」「エビの天麩羅」「揚げ物」「６分」「ＳＴ０１，ＳＴ０２」「２」がそれぞれセットされる。なお、フィールドＦＡＣは、カテゴリの識別子としてのカテゴリＩＤがセットされても構わない。
メニューデータベースＤＢＡは、調理支援装置１の外部に備えられた記憶デバイスに記憶されていても構わない。

【0021】

ポリシーデータベースＤＢＢは、店舗ポリシーに基づく料理の提供に関わる制約を管理するためのデータベースである。
図３はポリシーデータベースＤＢＢに含まれる１つのデータレコードＲＥＢのデータ構造を模式的に表す図である。
ポリシーデータベースＤＢＢは、それぞれ別々の店舗ポリシーに関連付けられた図３に表すデータレコードＲＥＢの集合である。データレコードＲＥＢは、フィールドＦＢＡ，ＦＢＢ，ＦＢＣ，ＦＢＤを含む。

【0022】

フィールドＦＢＡには、関連付けられた店舗ポリシーの識別子としてのポリシーＩＤがセットされる。フィールドＦＢＢには、関連付けられた店舗ポリシーの対象となる料理の料理名がセットされる。フィールドＦＢＣには、関連付けられた店舗ポリシーの対象となるカテゴリがセットされる。フィールドＦＢＤには、関連付けられた店舗ポリシーに基づく制約の内容がセットされる。

【0023】

なお、各フィールドにセットされる具体的なデータの内容は、店舗の管理者などによって適宜に定められてよい。一例として、あるデータレコードＲＥＢの各フィールドには、「ＰＯ００１」「」「刺身」「揚げ物カテゴリの料理よりも先に調理する」がそれぞれセットされる。また一例として、別のあるデータレコードＲＥＢの各フィールドには、「ＰＯ００２」「」「デザート」「デザート以外の料理より後に調理する」がそれぞれセットされる。また一例として、別のあるデータレコードＲＥＢの各フィールドには、「ＰＯ００３」「お子様ランチ」「」「注文受付から１０分以内に調理する」がそれぞれセットされる。なお、フィールドＦＢＣは、カテゴリの識別子としてのカテゴリＩＤがセットされても構わない。「」は、有意なデータがセットされていない状態を表す。
ポリシーデータベースＤＢＢは、調理支援装置１の外部に備えられた記憶デバイスに記憶されていても構わない。

【0024】

メニューデータベースＤＢＡ及びポリシーデータベースＤＢＢは、店舗のメニュー変更及び店舗ポリシーの変更に伴うメンテナンス作業によって更新されることはあるが、その頻度は低く、少なくとも後述する支援処理に伴って更新されるものではない。
履歴データベースＤＢＣは、これまでに受けられた注文を管理するためのデータベースである。履歴データベースＤＢＣの詳細については後述する。

【0025】

次に以上のように構成された調理支援装置１の動作について説明する。
ＣＰＵ１１は、調理支援装置１による調理支援の開始が、例えば操作ユニット１５での操作により指示されると、調理支援プログラムＰＲＡに従って、以下に説明する支援処理を行う。
図４は支援処理のフローチャートである。
なお、以下に説明する処理の内容は一例であって、一部の処理の順序の変更、一部の処理の省略、あるいは別の処理の追加などは適宜に可能である。

【0026】

ＡＣＴ１１としてＣＰＵ１１は、新規の注文があったか否かを確認する。そしてＣＰＵ１１は、該当の事象を確認できないならばＮＯと判定し、ＡＣＴ１２へと進む。
ＡＣＴ１２としてＣＰＵ１１は、調理状況に変化が生じたか否かを確認する。そしてＣＰＵ１１は、該当の事象を確認できないならばＮＯと判定し、ＡＣＴ１１へと戻る。
かくしてＣＰＵ１１は、ＡＣＴ１１及びＡＣＴ１２としては、注文又は調理状況の変化を待ち受ける。

【0027】

店員は、客の注文を聞き取った上で、注文入力装置２を操作して注文された料理を指定する。あるいは客は、注文入力装置２を操作して、注文する料理を指定する。注文入力装置２は、このような操作に応じて、１つの料理が指定される毎に、あるいは複数の料理が指定された後、注文実行が指示されたことに応じて、指定された料理のそれぞれの料理ＩＤを調理支援装置１に対して通信ネットワーク４を介して通知する。このときに注文入力装置２は、客が使用する客席の識別子としての客席ＩＤも調理支援装置１に対して通知する。注文入力装置２は例えば、料理の指定に前後して店員により入力される客席ＩＤを調理支援装置１に対して通知する。あるいは注文入力装置２は例えば、当該注文入力装置２が設置される客席に応じて予め設定されて記憶している客席ＩＤを調理支援装置１に対して通知する。あるいは注文入力装置２は例えば、客席に表示されて客席ＩＤを表したバーコードなどを読み取って、当該の客席ＩＤを調理支援装置１に対して通知する。店員は、客の要望があるならばそれを聞き取った上で、注文入力装置２を操作して当該の要望を入力する。あるいは客は、注文入力装置２を操作して、要望を入力する。注文入力装置２は、このような操作がなされているならば、入力された要望も調理支援装置１に対して通知する。

【0028】

このような通知が調理支援装置１にて通信モジュール１６により受けられると、ＣＰＵ１１は注文があったとしてＡＣＴ１１にてＹＥＳと判定し、ＡＣＴ１３へと進む。
ＡＣＴ１３としてＣＰＵ１１は、新たな注文を管理の対象として追加するべく注文データＤＡＡを更新する。ＣＰＵ１１は例えば、今回通知された１つ又は複数の料理のそれぞれに関連付けたデータレコードを注文データＤＡＡに追加する。
かくして注文データＤＡＡは、注文された料理のそれぞれに関連付けられたデータレコードの集合である。

【0029】

図５は注文データＤＡＡに含まれる１つのデータレコードＲＥＣのデータ構造を模式的に表す図である。
データレコードＲＥＣは、フィールドＦＣＡ，ＦＣＢ，ＦＣＣ，ＦＣＤ，ＦＣＥ，ＦＣＦ，ＦＣＧを含む。

【0030】

ＣＰＵ１１は例えば、既に利用されている注文ＩＤとは別の注文ＩＤを予め定められたルールに従って決定し、フィールドＦＣＡにセットする。ＣＰＵ１１は例えば、該当の注文に関する受注時刻を予め定められたルールで決定し、フィールドＣＡＢにセットする。ＣＰＵ１１は例えば、注文入力装置２から通知された客席ＩＤをフィールドＦＣＣにセットする。ＣＰＵ１１は例えば、注文入力装置２から通知された料理ＩＤの１つをフィールドＦＣＤにセットする。ＣＰＵ１１は例えば、フィールドＦＣＤに上記のようにセットした料理ＩＤで識別される注文料理が注文された個数をフィールドＦＣＦにセットする。ＣＰＵ１１は例えば、客の要望が通知されているならば、それをフィールドＦＣＧにセットする。そしてＣＰＵ１１は、これらによって生成されるデータレコードＲＥＣを含むように注文データＤＡＡを更新する。

【0031】

ＣＰＵ１１は一例として、各フィールドを「ＯＤ００１」「１２：００」「ＳＥ０１」「ＦＯ１０１」「刺身の盛り合わせ」「１」「」としたデータレコードＲＥＣを注文データＤＡＡに追加する。ＣＰＵ１１は一例として、各フィールドを「ＯＤ００２」「１２：００」「ＳＥ０１」「ＦＯ２０５」「エビの天麩羅」「１」「」としたデータレコードＲＥＣを注文データＤＡＡに追加する。ＣＰＵ１１は一例として、各フィールドを「ＯＤ００３」「１２：０５」「ＳＥ０２」「ＦＯ３０２」「鶏のから揚げ」「２」「サラダよりも先に出す」としたデータレコードＲＥＣを注文データＤＡＡに追加する。フィールドＦＤＨは、例えば「＞サラダ」のような形態のデータをセットされるのでも構わないし、予め定められた様々な要望事項のそれぞれに定めた識別子としての要望ＩＤをセットされるのでも構わない。

【0032】

ＡＣＴ１４としてＣＰＵ１１は、新たな注文を管理の対象として追加するべく履歴データベースＤＢＣを更新する。ＣＰＵ１１は例えば、今回通知された１つ又は複数の注文料理のそれぞれに関連付けたデータレコードを履歴データベースＤＢＣに追加する。
かくして履歴データベースＤＢＣは、過去に注文された料理のそれぞれに関連付けられたデータレコードの集合である。

【0033】

図６は履歴データベースＤＢＣに含まれる１つのデータレコードＲＥＤのデータ構造を模式的に表す図である。
データレコードＲＥＤは、フィールドＦＤＡ，ＦＤＢ，ＦＤＣ，ＦＤＤ，ＦＤＥ，ＦＤＦ，ＦＤＧ，ＦＤＨ，ＦＤＩを含む。

【0034】

ＣＰＵ１１は、フィールドＦＤＡ，ＦＤＢ，ＦＤＣ，ＦＤＤ，ＦＤＥ，ＦＤＨには、同じ料理に関連付けて注文データＤＡＡに追加したデータレコードＲＥＣのフィールドＦＣＡ，ＦＣＢ，ＦＣＣ，ＦＣＤ，ＦＣＦ，ＦＣＧにセットしたのと同様のデータをセットする。ＣＰＵ１１は、フィールドＦＤＦには、関連付けられた料理の調理状態を表すデータとして「未着手」をセットする。ＣＰＵ１１は、フィールドＦＤＧには、関連付けられた注文料理の調理の担当スタッフを表すものとして、いずれのスタッフＩＤもセットしない。ＣＰＵ１１は、フィールドＦＤＩには、関連付けられた注文料理の客への提供時刻を表すものとして有意なデータをセットしない。そしてＣＰＵ１１は、これらによって生成されるデータレコードＲＥＤを含むように履歴データベースＤＢＣを更新する。

【0035】

ＣＰＵ１１は一例として、各フィールドを「ＯＤ００１」「１２：００」「ＳＥ０１」「ＦＯ１０１」「１」「未着手」「」「」「」としたデータレコードＲＥＤを履歴データベースＤＢＣに追加する。ＣＰＵ１１は一例として、各フィールドを「ＯＤ００２」「１２：００」「ＳＥ０１」「ＦＯ２０５」「１」「未着手」「」「」「」としたデータレコードＲＥＤを履歴データベースＤＢＣに追加する。ＣＰＵ１１は一例として、各フィールドを「ＯＤ００３」「１２：００」「ＳＥ０２」「ＦＯ３０２」「２」「未着手」「」「サラダよりも先に出す」「」としたデータレコードＲＥＤを履歴データベースＤＢＣに追加する。

【0036】

一方、スタッフは、注文されている料理の調理を開始する場合には、対象となる料理に関する調理開始を宣言するための予め定められた操作を、当該のスタッフに割り当てられた調理者端末３にて行う。スタッフは、調理を完了した場合には、対象となる料理に関する調理完了を宣言するための予め定められた操作を、当該のスタッフに割り当てられた調理者端末３にて行う。調理者端末３は、これらの操作に応じて、対象となる料理に関する注文ＩＤと、調理者端末３の識別子としての端末ＩＤとの通知を伴って、調理開始又は調理完了を調理支援装置１に対して通信ネットワーク４を介して通知する。

【0037】

このような通知が調理支援装置１にて通信モジュール１６により受けられると、ＣＰＵ１１は調理状況に変化があったとして図４のＡＣＴ１２にてＹＥＳと判定し、ＡＣＴ１５へと進む。
ＡＣＴ１５としてＣＰＵ１１は、管理している調理状況を通知に応じて変更するべく履歴データベースＤＢＣを更新する。
ＣＰＵ１１は例えば、調理開始が通知されたならば、通知された注文ＩＤがフィールドＦＤＡにセットされているデータレコードＲＥＤを履歴データベースＤＢＣから探し出し、該当のデータレコードのフィールドＦＤＦを「調理中」に書き換えるとともに、通知された端末ＩＤに予め関連付けられたスタッフＩＤをフィールドＦＤＧにセットする。なお、端末ＩＤとスタッフＩＤとの関連付けは、複数の調理者端末３のそれぞれをどのスタッフに割り当てるかに応じて予め定められて、例えば補助記憶ユニット１３に記憶されるデータテーブルにより管理される。ただし、調理者端末３の個々にスタッフＩＤを記憶させておき、調理開始の通知に際してスタッフＩＤを調理者端末３から調理支援装置１に通知するのでもよい。

【0038】

ＣＰＵ１１は例えば、調理完了が通知されたならば、通知された注文ＩＤがフィールドＦＤＡにセットされているデータレコードＲＥＤを履歴データベースＤＢＣから探し出し、該当のデータレコードのフィールドＦＤＦを「調理完了」に書き換えるとともに、フィールドＦＤＩに現在時刻をセットする。なお、ここでフィールドＦＤＩにセットする時刻は、調理完了した料理が客に提供されるまでに要する時間を考慮して予め定められた補正時間が現在時刻から経過した時刻としてもよい。またＣＰＵ１１は、ここではフィールドＦＤＩには何らのデータもセットせず、例えば注文入力装置２から通知された提供完了時刻、あるいは注文入力装置２から提供完了が通知された時刻を、その通知に応じてフィールドＦＤＩにセットするのでも構わない。この場合は例えば、接客を担当するスタッフが、料理を客席に提供した旨を宣言するための予め定められた操作を注文入力装置２で行うようにする。あるいは客が、料理が提供された旨を宣言するための予め定められた操作を注文入力装置２で行うようにする。そして当該の操作に応じて注文入力装置２が、上記の通知を行うようにすればよい。

【0039】

ＡＣＴ１６としてＣＰＵ１１は、今回の通知が調理開始であるか否かを確認する。そしてＣＰＵ１１は、調理開始の通知であったならばＹＥＳと判定し、ＡＣＴ１７へと進む。
ＡＣＴ１７としてＣＰＵ１１は、調理が開始された注文の管理を終了するべく注文データＤＡＡを更新する。ＣＰＵ１１は例えば、通知された注文ＩＤがフィールドＦＣＡにセットされているデータレコードＲＥＣを注文データＤＡＡから削除する。かくしてＣＰＵ１１は、注文データＤＡＡを用いて、調理開始待ちの料理を、その料理の注文がなされた客席に関連付けて管理する。つまり調理支援プログラムＰＲＡに基づく情報処理をＣＰＵ１１が実行することによって、ＣＰＵ１１を中枢部分とするコンピュータは管理手段として機能する。

【0040】

ＣＰＵ１１は、ＡＣＴ１４又はＡＣＴ１７を終えると、ＡＣＴ１８へと進む。またＣＰＵ１１は、調理完了が通知されているためにＡＣＴ１６にてＮＯと判定したならば、ＡＣＴ１７をパスしてＡＣＴ１８へと進む。つまりＣＰＵ１１は、調理状況が「未着手」である注文に関して何らかの変化が生じた場合、つまり調理開始待ちの状況が変化した場合には、ＡＣＴ１８へと進む。

【0041】

そしてＣＰＵ１１は、ＡＣＴ１８～ＡＣＴ２６で、最適化機能を用いて、各種の制約条件を満たしつつ、各客席の待機時間のばらつきを小さく抑えられるような調理順及びスタッフ割り当てを決定する。本実施形態では、最適化機能として、局所探索法を使用する。局所探索法は、適当な初期解から出発し、解の近傍にそれより優位な解があれば置き換える、という処理を繰り返し実行して、更新が行われなくなったときの解を最適解とする。なお、この図４に表す支援処理は、一部の処理を調理支援プログラムＰＲＡとは別の情報処理プログラムに基づいて実行しても構わない。例えばＣＰＵ１１は、図４のＡＣＴ１８～ＡＣＴ２６の処理は、調理支援プログラムＰＲＡとは別の調理順番決定プログラムに基づいて実行しても構わない。

【0042】

ＡＣＴ１８としてＣＰＵ１１は、変化した後の調理開始待ちの状況に応じて、未着手である注文についての調理順及びスタッフ割り当てを決定するための制約条件を、例えば以下の例のように設定する。ＣＰＵ１１は、注文データＤＡＡに含まれるデータレコードＲＥＣのそれぞれについて、メニューデータベースＤＢＡを参照の上で、調理を担当するスタッフに関する制約（以下、スタッフ制約と称する）を抽出する。ＣＰＵ１１は、注文データＤＡＡに含まれるデータレコードＲＥＣのそれぞれについて、メニューデータベースＤＢＡ及びポリシーデータベースＤＢＢを参照の上で、店舗ポリシーに基づく制約（以下、ポリシー制約と称する）を抽出する。ＣＰＵ１１は、注文データＤＡＡに含まれるデータレコードＲＥＣのうちでフィールドＦＣＧに有意なデータがセットされているデータレコードＲＥＣのそれぞれについて、客要望に基づく制約（以下、要望制約と称する）を抽出する。制約の内容は、「調理割り当てはスタッフＳＴＡである」などの条件文、あるいはそれを表現する条件式とされる。さらにＣＰＵ１１は、抽出した制約のそれぞれに関して、違反ペナルティを定義する。違反ペナルティは、設計パラメータとして事前に定義しておけばよく、できれば違反したくない弱い制約については違反ペナルティを小さく、必ず違反したくない強い制約については違反ペナルティを大きく設定しておくことが想定される。
そしてＣＰＵ１１は、これら抽出した各種の制約のそれぞれを制約条件として設定する。ＣＰＵ１１は、設定した制約条件を管理するために、制約データＤＡＢを生成する。制約データＤＡＢは、制約条件の個々に関連付けたデータレコードの集合となる。

【0043】

図７は制約データＤＡＢに含まれる１つのデータレコードＲＥＥのデータ構造を模式的に表す図である。
データレコードＲＥＥは、フィールドＦＥＡ，ＦＥＢ，ＦＥＣ，ＦＥＤ，ＦＥＥを含む。ＣＰＵ１１は、制約データＤＡＢに含まれるデータレコードＲＥＥの個々を識別可能に、予め定められたルールに従って識別子を決定し、これを制約ＩＤとしてフィールドＦＥＡにセットする。ＣＰＵ１１は例えば、関連付けられた制約が、スタッフ制約、ポリシー制約及び要望制約のいずれであるかの区分を表すデータをフィールドＦＥＢにセットする。ＣＰＵ１１は例えば、関連付けられた制約の対象となる注文の注文ＩＤをフィールドＦＥＣにセットする。ＣＰＵ１１は例えば、関連付けられた制約の内容をフィールドＦＥＤにセットする。ＣＰＵ１１は例えば、関連付けられた制約に関して定義した違反ペナルティをフィールドＦＥＥにセットする。

【0044】

これによりデータレコードＲＥＥは、各フィールドに、例えば「ＣＯ００１」「スタッフ制約」「ＯＤ００１」「調理割り当てはスタッフＳＴＡである」「１００」といった具合に、あるいは例えば「ＣＯ００２」「ポリシー制約」「ＯＤ００１」「揚げ物よりも先に出す」「３０」といった具合に、あるいは例えば「ＣＯ００５」「要望制約」「ＯＤ００３」「サラダよりも先に出す」「５０」といった具合に、各データがセットされたものとなる。

【0045】

図４中のＡＣＴ１９としてＣＰＵ１１は、調理開始待ちとなっている注文に関する調理順番及びスタッフへの割当に関する初期の候補解を生成する。ＣＰＵ１１は例えば、注文データＤＡＡに含まれる全てのデータレコードＲＥＣのフィールドＦＣＡにセットされている注文ＩＤを抽出する。次にＣＰＵ１１は例えば、抽出した注文ＩＤを、スタッフに対応した複数の順列リストのデータ構造にランダムに振り分ける。具体例としてＣＰＵ１１は、「ＯＤ０２」「ＯＤ０３」「ＯＤ０４」「ＯＤ０５」「ＯＤ０６」なる５つの注文ＩＤを抽出した場合に、これを例えばスタッフＳＴＡに対応する順列リストとして｛ＯＤ０４，ＯＤ０２｝、スタッフＳＴＢに対応する順列リストとして｛ＯＤ０３，ＯＤ０６，ＯＤ０５｝のようにランダムに振り分ける。ここで｛ＯＤ０４，ＯＤ０２｝のように表される順列リストは、対応するスタッフＳＴＡが、まず注文ＩＤが「ＯＤ０４」である注文の対象となっている料理を調理し、その後に注文ＩＤが「ＯＤ０２」である注文の対象となっている料理を調理することを意味する。

【0046】

ＡＣＴ２０としてＣＰＵ１１は、候補解に関するエネルギ関数を評価する。ＣＰＵ１１は、メニューデータベースＤＢＡの各データレコードＲＥＡのフィールドＦＡＤにセットされている調理時間を参照し、候補解を各スタッフの調理スケジュールに変換することで、各客席の待機時間を算出する。具体的にはＣＰＵ１１は例えば、スタッフごとに候補解での調理順に調理時間を積み上げることにより、各料理の提供時刻を求める。ＣＰＵ１１はこの際、候補解には含まれない、該当のスタッフが調理中である注文の残りの調理時間も考慮する。またＣＰＵ１１は、順番が連続する複数の注文の対象となる料理が同じであれば、複数の注文を１つにまとめることで、１つの注文分の調理時間とする。ただし、まとめられる注文個数は、その料理にメニューデータベースＤＢＡにて関連付けられているデータレコードＲＥＡのフィールドＦＡＦにセットされた同時調理数を上限とする。つまりＣＰＵ１１は例えば、同時調理数が「３」の料理に対して、その料理の注文が５つ連続していた場合は、３つと２つの２回分の調理時間とする。このようにすることで、得られる解に同時調理が可能か否かを考慮することができる。そしてＣＰＵ１１は例えば、客席毎に、上記の処理によって求めた各料理の提供時刻の最も早い時刻と、既に料理を提供済みの注文に履歴データベースＤＢＣにて関連付けられているデータレコードのフィールドＦＤＩにセットされている提供時刻のうちの最も遅い提供時刻との差分として待機時間を算出する。

【0047】

図８はこのように算出される待機時間のイメージを表す図である。
図８は、上述の具体例のように、スタッフＳＴＡに対応する順列リストとして｛ＯＤ０４，ＯＤ０２｝、スタッフＳＴＢに対応する順列リストとして｛ＯＤ０３，ＯＤ０６，ＯＤ０５｝が設定されている場合である。そして、注文ＩＤが「ＯＤ０２」である注文は客席ＩＤが「ＳＥ０１」である客席での注文であり、注文ＩＤが「ＯＤ０３」及び「ＯＤ０５」である注文は客席ＩＤが「ＳＥ０２」である客席での注文であり、注文ＩＤが「ＯＤ０６」である注文は客席ＩＤが「ＳＥ０３」である客席での注文である場合である。そして、客席ＩＤが「ＳＥ０１」である客席は待機時間ＷＴａ、客席ＩＤが「ＳＥ０２である客席は待機時間ＷＴｂ、客席ＩＤが「ＳＥ０３」である客席は待機時間ＷＴｃとなる。

【0048】

ＣＰＵ１１は次に、全ての制約条件に対して、候補解が意味する調理順及び担当割り当てがその制約条件を満たしているかチェックし、制約条件を満たしていない制約条件に対して定義されている違反ペナルティの総和として、ペナルティ値を算出する。ＣＰＵ１１は例えば、メニューデータベースＤＢＡにて担当スタッフとして設定されていないスタッフに調理が割り当てられている場合は制約違反であるから、該当の制約条件に対して定義されている違反ペナルティをペナルティ値に計上する。かくしてペナルティ値は、各料理の調理順序の決定に考慮する諸条件を満たさない度合いを表す値の一例である。

【0049】

ＣＰＵ１１は次に、各客席の待機時間とペナルティ値とから、候補解のエネルギ関数の出力値を求める。エネルギ関数は、制約条件を満たし、各客席の待機時間が短くなるほど出力値が小さく、高評価を意味する。例えばＣＰＵ１１は、エネルギ関数の出力値を以下のような数式により算出する。ただし、Ｔａｖｅは各客席の待機時間の平均値である。Ｔｍａｘは各客席の待機時間のうちの最大値である。Ｖｐはペナルティ値である。
出力値＝Ｔａｖｅ＋Ｔｍａｘ＋Ｖｐ
なお、以下においては、候補解に関するエネルギ関数の出力値を、候補出力値と称することとする。

【0050】

ＡＣＴ２１としてＣＰＵ１１は、候補解から近傍解を生成する。ＣＰＵ１１は例えば、候補解に対して、ランダムに選択した１つの注文を、ランダムに選択した別の割り振り位置へ移動する。あるいはＣＰＵ１１は例えば、候補解に対して、ランダムに選択した２つの注文の割り振り位置を交換する。これらの移動及び交換は、どちらか一方を実行するのでも、あるいは両方を実行されるのでも構わない。さらには上記の移動及び交換の少なくとも一方が、複数回繰り返して実行されるのでも構わない。一般的に近傍解の生成における解の変更操作は、確率的に決定されるとよいとされる。

【0051】

ＡＣＴ２２としてＣＰＵ１１は、近傍解に関するエネルギ関数を評価する。ここでのＣＰＵ１１の処理は、処理の対象が候補解から近傍解に変更される他は、ＡＣＴ２０と同様な処理であってよい。そして以下においては、近傍解に関するエネルギ関数の出力値を、近傍出力値と称することとする。

【0052】

ＡＣＴ２３としてＣＰＵ１１は、候補解に対して近傍解が優位であるか否かを確認する。ＣＰＵ１１は例えば、候補出力値と近傍出力値とに関して予め定められた判定条件が成立する場合に、近傍解が優位であると判定する。上記の判定条件は、例えば調理支援装置１の設計者又は調理支援プログラムＰＲＡの作成者などによって適宜に定められて構わないが、一例として［候補近傍値＞近傍出力値］が成立することとする。そしてＣＰＵ１１は、近傍解が優位であるならばＹＥＳと判定しＡＣＴ２４へと進む。

【0053】

ＡＣＴ２４としてＣＰＵ１１は、候補解及び候補出力値を更新する。つまりＣＰＵ１１は、近傍解及び近傍出力値を、新たな候補解及び候補出力値とする。そしてＣＰＵ１１はこののち、ＡＣＴ２５へと進む。なおＣＰＵ１１は、近傍解が優位であると判定できないためにＡＣＴ２３にてＮＯと判定したならば、ＡＣＴ２４をパスしてＡＣＴ２５へと進む。つまりＣＰＵ１１は、近傍解が優位であると判定できない場合には、候補解及び候補出力値を更新しない。

【0054】

ＡＣＴ２５としてＣＰＵ１１は、後述するように予め定められた終了条件が成立したか否かを確認する。そしてＣＰＵ１１は、終了条件が成立していないならばＮＯと判定し、ＡＣＴ２１以降を繰り返す。これにより、上記のように更新後の候補解に対する近傍解の生成と、近傍解が優位である場合の候補解の更新とを繰り返す。
終了条件は、例えば調理支援装置１の設計者又は調理支援プログラムＰＲＡの作成者などによって適宜に定められて構わないが、一例として、ＡＣＴ２１～ＡＣＴ２５のループを繰り返す中で、５回連続で候補解の更新が行われなかった場合とすることが想定される。つまりＣＰＵ１１は、ＡＣＴ２３にてＮＯと判定してＡＣＴ２５へと進むことが５回連続した場合に、ＡＣＴ２５にてＹＥＳと判定し、ＡＣＴ２６へと進む。

【0055】

ＡＣＴ２６としてＣＰＵ１１は、調理者端末３のそれぞれで表示させる指示画面を更新する。指示画面は、候補解が意味する調理順及び担当割り当てを各スタッフに通知するとともに、調理開始及び調理完了の宣言のための操作を受けるためのＧＵＩ（graphical user interface）画面である。つまりＣＰＵ１１は、スタッフのそれぞれに対応する個別の内容の指示画面をそれぞれ生成し、各指示画面の表示を、対応するスタッフに割り当てられた調理者端末３に対して指示することで、調理者端末３で表示される指示画面を更新させる。つまりＣＰＵ１１は、終了条件が成立した時点における候補解を、探索結果としての最終の解、すなわち最適解とし、この最適解が意味する調理順及び担当割り当てを指示画面により各スタッフに通知する。

【0056】

かくして調理支援プログラムＰＲＡに基づく情報処理をＣＰＵ１１が実行することによって、ＣＰＵ１１を中枢部分とするコンピュータは調理開始順序を決定する決定手段として機能する。そしてこの機能に関してＣＰＵ１１は、調理開始順序についての複数の候補となる初期の候補解及び近傍解の中から複数の客席のそれぞれでの待機時間が平準化する解を採用することで、調理開始順序を決定している。
なお、全ての制約を満たす調理順が存在しない場合もあり得るため、最適解としては、ペナルティ値の小さい制約違反のある解が選ばれる場合もあり得る。

【0057】

図９は指示画面ＳＣＡの一例を表す図である。
指示画面ＳＣＡは、テーブルＴＡＡ、ボタンＢＵＡ，ＢＵＢを表す。
ＣＰＵ１１は、１人のスタッフに関して割り当てる料理のそれぞれについての料理名、個数、客席ＩＤ、調理時間及び調理状態を並べた行を、調理順に列方向に並べてテーブルＴＡＡを生成する。ＣＰＵ１１は、テーブルＴＡＡに表す各情報は、調理時間を除いて履歴データベースＤＢＣから得ればよい。ＣＰＵ１１は、調理時間はメニューデータベースＤＢＡから得る。なお図９においては、料理名を「ＡＡＡＡＡＡ」のように簡略化して表しているが、実際には「刺身の盛り合わせ」のような文字列が表される。ＣＰＵ１１は、調理状態が「未着手」である料理に関する行においては、調理状態の欄を空欄とする。しかしながらＣＰＵ１１は、該当の欄に、例えば「未着手」のような文字列を表すのでも構わない。

【0058】

ＣＰＵ１１は、調理状態が「調理中」である料理に関する行の横に、ボタンＢＵＡを表す。ボタンＢＵＡは、横に並ぶ行に表された料理の調理完了をスタッフが宣言するためのソフトキーである。ＣＰＵ１１は、調理状態が「未着手」である料理に関する行の横に、ボタンＢＵＢを表す。ボタンＢＵＢは、横に並ぶ行に表された料理の調理開始をスタッフが宣言するためのソフトキーである。かくしてボタンＢＵＡ，ＢＵＢのそれぞれの表示数及び表示位置は、各料理の調理状態に応じて様々に変化する。ボタンＢＵＡ，ＢＵＢは、ある時点の指示画面ＳＣＡにおいては１つも表されない場合もある。

【0059】

そしてＣＰＵ１１は、調理者端末３のそれぞれにて表示される指示画面ＳＣＡを更新し終えたならば、図４中のＡＣＴ１１及びＡＣＴ１２の待ち受け状態に戻る。かくしてＣＰＵ１１は、ボタンＢＵＡをタップする操作を、ＡＣＴ１２にて調理完了を宣言するための予め定められた操作として受ける。またＣＰＵ１１は、ボタンＢＵＢをタップする操作を、ＡＣＴ１２にて調理開始を宣言するための予め定められた操作として受ける。そこで調理者端末３は、ボタンＢＵＡ又はボタンＢＵＢがタップされたならば、ボタンが操作されたことを、指示画面ＳＣＡに表されたボタンＢＵＡ，ＢＵＢのいずれが操作されたかを判別可能に通知する。そしてＣＰＵ１１は、この通知に基づいて、前述のようにＡＣＴ１５の処理を実行する。

【0060】

以上のように調理支援装置１は、複数の客席から入った注文について、店舗のポリシーや顧客の要望になるべく沿いつつも、各客席のそれぞれでの料理提供の待機時間の平準化を図れるような調理順を決定する。かくして、このように決定された調理順に従ってスタッフが調理することによって、各客席に偏りなく料理を提供することができ、複数の客席間でのサービス提供レベルのばらつきを抑えることができる。そして、これにより、客に不公平感を与えないことにより、店舗利用に関する客の満足度を向上させることができる。

【0061】

この実施形態は、次のような種々の変形実施が可能である。
前記実施形態では、最適化機能として局所探索法を用いて説明した。しかしながら、使用する最適化機能及び設計方法はこれに限らず実現が可能である。例えば、イジングモデルなどの数理モデルに定式化して汎用的なソルバで求解する方法を用いても構わない。

【0062】

複数の情報処理装置の協働によって調理支援装置１としての機能が実現されるのでも構わない。例えば、図４中のＡＣＴ１１～ＡＣＴ１７及びＡＣＴ２６の処理と、ＡＣＴ１８～ＡＣＴ２６の処理とは、互いに連携しながら別々の情報処理装置により実行されても構わない。

【0063】

図４中のＡＣＴ１３及びＡＣＴ１７での注文データの更新は、ＰＯＳ端末などの販売処理装置での登録処理と連携して、当該の登録処理で生成される注文リストを参照することで行われても構わない。

【0064】

指示画面は、図９に表すような指示画面ＳＣＡに代えて、複数のスタッフが担当する料理を混在して表すとともに、各料理を調理すべきスタッフを認識可能とした画面としても構わない。

【0065】

情報処理によりＣＰＵ１１が実現する各機能は、その一部又は全てをロジック回路などのようなプログラムに基づかない情報処理を実行するハードウェアにより実現することも可能である。また上記の各機能のそれぞれは、上記のロジック回路などのハードウェアにソフトウェア制御を組み合わせて実現することも可能である。

【0066】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0067】

１…調理支援装置、２…注文入力装置、３…調理者端末、４…通信ネットワーク、１１…ＣＰＵ、１２…メイン記憶ユニット、１３…補助記憶ユニット、１４…表示ユニット、１５…操作ユニット、１６…通信モジュール、１７…伝送路。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】