JP4675402B2 - 定期ケータリングシステム - Google Patents

Description

本発明は、ケータリングシステムに関し、特に、宅配業者が複数の顧客に対し、一定期間食材を配送するための定期ケータリングシステムに関する。

伝統的な加熱調理の方法として、「焼く」、「煮る」、「炒める」、「蒸す」などの基本的な手法が知られている。これら伝統的な加熱調理では、加熱調理手段が広く普及していることから、調理手順と加熱時間が使用者の体感事項として身についているとともに、食品の外観の変化や食材の硬さの変化などを仕上がり確認することにより、加熱調理の補正がある程度可能であり、加熱調理の失敗を防止することができる。

これら伝統的な加熱調理方法と異なる加熱調理方法として、電子レンジを使用したマイクロ波による高周波加熱調理が登場した。高周波加熱調理は、伝統的な加熱調理方法の体感事項が利用できず、特に、仕上がり確認が困難であることから、加熱調理の失敗を防止することが困難であった。このため、電子レンジ料理教室の開催や電子レンジに対応したクックブックの発行などによる啓蒙活動により、新たな体感事項を広める必要があった。

また、マイクロプロセッサーを利用して、加熱調理器内に、多種の調理レシピに適した加熱調理手順(調理シーケンス)を記憶し、使用者が、希望する調理レシピに適した調理メニューを選択することによって、お仕着せの範囲内とはいえ、調理レシピに適した加熱シーケンスによって加熱調理することができるようになった。

これに加えて、食品重量にあわせて加熱調理時間を制御する方法や加熱調理中の食品から発散される水蒸気やにおい成分をセンサーで検知することにより仕上がり検知して制御する方法が採用され、特定の食品と調理レシピでは、自動調理的に加熱調理することができるようになった。

このように、ほぼ４０年以上の長年に亘る啓蒙活動による体感事項の普及と各機器メーカーの技術革新による機器の進歩とにより、高周波加熱調理器は、依然として仕上がり確認が困難である特徴は残るものの、一般消費者から、伝統的な加熱調理の方法に準ずる周知の加熱調理機器としての認知を得ている。

ここに新たに加わったのが過熱水蒸気調理器である。過熱水蒸気調理器は、密閉性の高い加熱室内に載置した食品に対して、１００℃を超える過熱蒸気をシャワーのごとく吹き付けることによって食品を「焼く」調理方法である。

過熱水蒸気調理器の加熱方法は、水蒸気を利用する点で「蒸す」加熱調理と共通しているが、「蒸す」加熱調理が、基本的に、最高１００℃の蒸気によって食品に水分を与えつつ加熱調理するのに対して、過熱水蒸気調理器は、１００℃を超えて食品温度を上昇させ、「焼く」点が大きく異なる。

過熱水蒸気調理器は、加熱調理中の仕上がり確認が困難である。また、動作原理上、センサーによる仕上がり制御も困難である。

したがって、過熱水蒸気調理器は、現時点では、体感事項の乏しい加熱調理器である。
また、お仕着せメニューを離れた応用が困難であるため、同様の上記加熱機能を有する電子レンジと比較して高価であることと相俟って、「敷居の高い」加熱調理器と見られていると思われる。

一方、過熱水蒸気調理器は、高周波加熱調理器を含めた伝統的な加熱調理器にない特質を持っている。過熱水蒸気調理器は、例えば特許第４０６５０１０号に記載されたように、加熱調理の過程において、食品表面に蒸気を凝縮させ、食品内部から浮上する塩分や油脂分が凝縮水に取り込んで取去る機能を有する。このため、伝統的な加熱調理を行った食品と比較して塩分や油脂分が減少することから、塩分や摂取カロリーの低減により、ダイエット効果や生活習慣病の抑制効果があるものと予想されている。

一方、従来から、宅配業者が複数の顧客に対して食材を配送するシステムにおいて、様々な提案がなされている。

たとえば、特許文献１には、消費者からの希望のカロリー、希望価格などの検索条件情報からメニューの検索を行い、検索されたメニューを消費者に提示するシステムが提案されている。また、特許文献２には、消費者に提示したメニューのうち消費者によって選択されたメニューの材料、レシピを消費者の嗜好に合うように変更することが提案されている。
特開平１１−３１１７５号公報 特開２００２−２７９２５５号公報

しかしながら、特許文献２におけるレシピは、食材の材料（種類や量）のことを表わしており、食材の調理自体は消費者が実行する場合には、従来のように、消費者の嗜好に合うように食材の材料が変更されたとしても、消費者は、届けられた食材を上手く調理できるとは限らない。

また、上述のように、家庭用加熱調理器として新たに登場した過熱水蒸気調理器の普及拡大に当たっては、電子レンジの普及拡大に要したのと同等の啓蒙活動が必要であることが予想されるが、過熱水蒸気調理器の認知度と顧客満足度を迅速に高めるため、最新の情報システムを高度に利用することにより、一般消費者を過熱水蒸気調理器に引き合わせ、初心の段階での失敗体験を避け、かつ、速やかに過熱水蒸気調理器の特質を伝達することを可能とするビジネスシステムの登場が期待されている。

本発明は、上記のような問題を解決するためになされたものであって、その目的は、食材の調理自体は消費者（顧客）においてされる場合にでも、失敗なく届けられた食材を調理することのできる定期ケータリングシステムを提供することである。

この発明のある局面に従う定期ケータリングシステムは、宅配業者が複数の顧客に対し、一定期間食材を配送するためのケータリングシステムであって、宅配業者に保有される第１の端末と、各顧客に対し、一定期間貸し出される複数の調理器と、第１の端末とインターネットを介して接続され、調理器のメーカーに保有されるサーバとを備え、サーバは、調理器での調理シーケンスデータと、調理メニューに対応するレシピ情報とを記憶する第１のレシピ管理データベースを含み、レシピ情報は、各調理メニューに対応する食材データ、および、各調理メニューを特定する情報を有し、第１の端末は、顧客に関する情報を管理するための第１の顧客管理データベースと、サーバより送信された複数の調理メニューに関するレシピ情報を記憶するための第２のレシピ管理データベースと、顧客ごとに、顧客からの注文に基づいた調理メニューを特定する情報を記憶する予約注文管理データベースと、予約注文管理データベースから顧客に関連付けられた調理メニューを特定する情報を選択し、当該選択した調理メニューを特定する情報に基づいて調理シーケンスデータを特定する情報であるシーケンス識別データを生成し、当該シーケンス識別データを含む予約シーケンス情報を出力するための出力処理手段と、顧客からのフィードバック情報を取得し、取得したフィードバック情報をサーバに送信するための処理を行なう第１の情報処理手段とをさらに含み、各調理器は、ネットワークを介することなく登録される複数の前記調理シーケンスデータを記憶するための第１の記憶手段と、前記複数の調理シーケンスデータのうち、前記第１の端末より出力された前記予約シーケンス情報により特定される調理シーケンスデータに従い、前記宅配業者により配送された食材の調理を制御するための調理制御手段とを含み、サーバは、第１の端末からのフィードバック情報を記憶するための第２の記憶手段と、第２の記憶手段に記憶されたフィードバック情報に基づいて、第１のレシピ管理データベースに記憶された食材データを変更する第２の情報処理手段とを含む。

第１の顧客管理データベースは、顧客ごとに、複数のカロリー制限レベルのうちの１つを記憶し、レシピ情報は、調理メニューごとに、カロリー制限レベルに応じた複数のシーケンス識別データを有し、出力処理手段は、顧客ごとに、対応するカロリー制限レベルに応じてシーケンス識別データを選択し、選択されたシーケンス識別データを含む予約シーケンス情報を生成する。

サーバは、第１の端末により送信された顧客に関する情報を記憶する第２の顧客管理データベースを含み、レシピ情報は、各調理メニューとカロリー制限レベルとの組み合わせに対応付けられた、食材データおよび調理シーケンスデータを有する。
複数の調理器は、過熱水蒸気によって加熱調理する調理器であり、レシピ情報は、顧客に関する情報とフィードバック情報に基づき調整される。

好ましくは、サーバは、フィードバック情報に基づいて、カロリー制限レベルごとに人気メニューのランキング情報を生成し、生成したランキング情報を第１の端末に送信するための第２の情報処理手段をさらに含み、第１の端末は、サーバより送信されたランキング情報を反映させて、調理メニューに関する情報を提供するためのメニュー提供手段をさらに含む。

好ましくは、メニュー提供手段は、ランキング情報に基づいて、ランキングの順になるように調理メニューを並び替えて調理メニューに関する情報を提供する。

好ましくは、第１の顧客管理データベースは、顧客ごとに、調味料レベルをさらに記憶し、第１の情報処理手段は、さらに、フィードバック情報に基づいて、調味料レベルを調整する。

好ましくは、第１の端末とインターネットを介して接続され、各顧客により保有される第２の端末をさらに備え、出力処理手段は、第２の端末に、予約シーケンス情報を送信する。

好ましくは、第２の端末は、第１の端末より送信された予約シーケンス情報を調理器に転送するための処理を行なう転送処理手段を含み、第１の記憶手段は、第２の端末より転送された予約シーケンス情報をさらに記憶する。

好ましくは、第１の顧客管理データベースは、顧客ごとに、調理器のリース開始日時および契約期間を含む契約状況データをさらに記憶し、第１の端末は、契約状況データに基づいて、所定期間ごとに解約金を算出し、算出した解約金を顧客に報知するための処理を行なう報知処理手段をさらに含む。

好ましくは、報知処理手段は、解約金とともに、解約金の低減率をさらに報知する。
好ましくは、第１の端末は、食材を届ける顧客を識別するための顧客識別情報と、当該食材に対応する調理メニューを識別するためメニュー識別情報とに基づいて、認証情報を生成し、認証情報を、食材の配送に用いられる専用容器に添付するための書類データに付加するための配送処理手段をさらに含む。

好ましくは、認証情報は、顧客識別情報およびメニュー識別情報に所定のアルゴリズムを適用することにより計算される数値である。

本発明によると、調理器において、予約された調理メニューに対応する調理シーケンスデータに従い食材の調理が制御されるため、食材の調理を失敗することがなくなる。

また、調理器のメーカーは、顧客からのフィードバック情報を容易に取得することができる。

本発明の実施の形態について図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰返さない。

本発明の定期ケータリングシステムは、食材の宅配業者の顧客（会員）に特定の調理器を貸し出して（たとえばリースし）、調理器のメーカーは、食材に最適な調理シーケンスを顧客に提供する。以下に、本発明の定期ケータリングシステムの実施の形態について説明する。

＜システムの概要について＞
はじめに、本実施の形態における定期ケータリングシステムの概要について説明する。

現在はグルメ志向の時代であるが、一般消費者が特定の料理を食べたいと思ったとき、まず考えるのは、特定の料理をメニューに載せているレストラン等を訪れることである。この場合、プロの手配した食材を、プロの厨房機器を使用して、プロが調理したものが提供されるので、仕上がりは保証されているものである。

さて、家庭で特定の料理を調理して食べたいと思ったとき、あるいは、新しいタイプの調理器を購入したとき、初心者の犯しがちな失敗を避けて、確実においしい料理を味わうことは簡単ではない。

以前より、ケータリングサービスというサービスがある。これは、パーティーなどの開催に際して提供されるサービスであり、ケータリング業者が、食材や調理器具，食器類などを会場に持ち込んで、プロが料理して、来客に食事を提供するサービスである。

これらすべてをフルに提供するのが、一般に知られているケータリングであるが、これ
をここでは、「フルケータリング」という。

こうしたフルケータリングサービスの一部を消費者側が行う形態もある。つまり、食材や調理器具，食器類などを会場に持ち込むまでのケータリングは業者が行うが、料理などは消費者が行うものである。ここでは、これを、「ハーフケータリング」という。

ただし、食材や調理器具だけ受け取っても、詳細のレシピが不明では、料理の失敗が懸念される。したがって、ハーフケータリングにはレシピ提供が必須となる。

さて、いずれにしろ一般に知られているケータリングサービスは、コストの面からも，
料理の量から言っても、緊急対応のものであり、常時受け入れるものではない。

これに対して、本発明の定期ケータリングシステムは、このようなハーフケークリングの枠組みを一家族程度の量に置き換える代わりに、一定期間、継続して利用可能とする。その意味で、定期・常駐型ケータリングサービスといえる。

以上のように、調理器の貸し出しの期間は限定するが、その間のレシピ付き食材のおいしさを保証することと、定期使用権料の回収を確実にすることを両立させることが、本システムの要である。

（全体構成）
図１は、本発明の実施の形態における定期ケータリングシステム１の全体構成を示すブロック図である。

図１を参照して、定期ケータリングシステム１は、宅配業者２０がユーザー（顧客）３０に対し、一定期間食材を配送（ケータリング）するためのシステムであり、主に、調理器４００を販売するメーカー１０と、食材の配送を行なう宅配業者２０と、顧客であるユーザー３０と、調理器４００をリースするリース会社４０と、調理器４００のメンテナンス等を行なうメーカー関連会社５０とで運営される。リース会社４０は、メーカー１０に関連のリース会社であってもよいし、そうでなくてもよい。なお、図１では、一人のユーザー３０のみ示しているが、実際には、複数のユーザーが存在するものとする。

メーカー１０は、サーバ１００を保有する。宅配業者２０は、宅配業者端末２００を保有する。ユーザー３０は、ユーザー端末３００を保有していてもよい。サーバ１００と宅配業者端末２００とユーザー端末３００とは、インターネット６を介して接続される。

メーカー１０と宅配業者２０とは、本システム１に関するビジネス契約を結んでいる。宅配業者２０とユーザー３０とは、本システム１を機能させるための定期ケータリング契約を結んでいる。定期ケータリング契約が結ばれると、調理器４００をリースするリース会社４０と宅配業者２０との間でリース契約が結ばれる。

本実施の形態において、定期ケータリング契約は、年単位で所定期間（たとえば３年）を限度に行なわれる。３年越えて契約が希望される場合には、調理器４００を新製品に交換して新たな契約が結ばれる。

リース契約が結ばれると、リース会社４０は、メーカー１０に対し、調理器４００の代金を支払う。メーカー１０は、メーカー関連会社５０に、ユーザー３０の自宅に調理器４００を設置することを依頼する。メーカー関連会社５０は、設置依頼を受けると、ユーザー３０の自宅に、調理器４００を設置する。定期ケータリングサービスが始動されると、契約期間中、宅配業者２０がリース会社４０に対して月々のリース料を支払う。

このように、本実施の形態によると、ユーザー３０は、宅配業者２０と定期ケータリング契約を結ぶことで、調理器４００の定期使用権を得る。宅配業者２０が、ユーザー３０の代わりにリース会社４０とリース契約を結ぶため、ユーザー３０は調理器４００を借りるための煩わしい手続きをする必要がない。なお、このような形態に限定されず、宅配業者２０が、ユーザー３０とリース契約を結び、宅配業者２０がリース料のみを代払いしてもよい。

上記のようにして定期ケータリングサービスが始動されると、契約期間中、サーバ１００、宅配業者端末２００、ユーザー端末３００および調理器４００により定期ケータリングシステム１の機能が実現される。宅配業者端末２００は、読取装置２４０，２４１およびプリンタ２４２と接続されるが、これらの詳細な説明は後述する。

なお、定期ケータリングシステム１は、食材の発注および納入管理のシステム部分と、食材の個別配布のシステム部分とで構成されている。食材の発注および納入管理のシステム部分は、基本的に、工場の生産管理システムと同様の管理システムであり、公知技術の応用によって構成可能である。したがって、以下では、食材の個別配布のシステム部分についての特徴についてのみ説明する。

（物・情報の流れの概要）
図２は、本発明の実施の形態における定期ケータリングシステム１における物および情報の流れの概要を示す図である。

図２を参照して、メーカー１０は、宅配業者２０に対し、調理メニューごとのレシピを提供する。ここでの「レシピ」は、調理器４００のシーケンスデータを表わす。宅配業者２０は、ユーザー３０に対し、レシピ付きの食材を配送する。具体的には、料理に合わせてカッティングされた食材（調合された調味料を含む）と、調理器４００での食材の調理に必要なレシピ情報すなわち、シーケンスデータを特定するためのシーケンス識別データとの両方がユーザー３０に提供される。食材とレシピ情報との提供タイミングは、同時でなくてよい。

本実施の形態において、調理器４００は、宅配業者２０により頒布される食材の調理に使用する前提で、一定期間（ユーザーによる契約期間）の使用権がユーザー３０に付与される。したがって、ユーザー３０に提供される食材のレシピは、本システム１を構成する調理器４００に特化される。そのため、調理器４００で調理すると食材の仕上がりは保証されるが、他種の調理器では仕上がりは保証されない。

ユーザー３０は、レシピ付き食材のフィードバック情報を宅配業者２０の宅配業者端末２００に与える。宅配業者端末２００は、ユーザー３０から得たフィードバック情報を、メーカー１０のサーバ１００に転送する。メーカー１０は、フィードバック情報を得ることにより、所定の処理を実行する。具体的には、たとえば、新たなレシピの開発に役立てたり、現在ある調理メニューのランキング情報を作成したりすることもできる。なお、宅配業者端末２００においても、ユーザー３０から得たフィードバック情報に基づいて所定の処理をしてもよい。

なお、宅配業者２０は、ユーザー３０に代わってリース料を支払うため、対価の回収を可能とするために、頒布されるレシピ付き食材の価格に特定金額（たとえばメニューに応じて１００円〜３００円）上乗せしてもよい。

図３は、宅配業者２０とユーザー３０との間で行なわれる食材配送方法の一形態を示す図である。図３を参照して、本実施の形態では、各ユーザー３０に対し、２つの専用容器（通い箱）ＢＸ１０が用意される。宅配業者２０の配送担当者２０Ａは、食材入りの専用容器ＢＸ１０．１をユーザー３０に届ける。届けられた専用容器ＢＸ１０．１は、次回の配送までユーザー３０により保管される。ユーザー３０は、食材が届けられると、前回の配送に用いられた空の専用容器ＢＸ１０．２を、配送担当者２０Ａに返却する。

（専用容器について）
図４は、本発明の実施の形態における専用容器ＢＸ１０の外観例を示す図である。

図４を参照して、専用容器ＢＸ１０は、蓋部ＢＸ１０Ａと容器部ＢＸ１０Ｂとで構成される。蓋部ＢＸ１０Ａは、物流上の目的およびユーザー３０に対する情報伝達の目的等から、カードおよび／またはラベルを添付可能とされる。具体的には、蓋部ＢＸ１０Ａは、その上面６０１に、３つのカードホルダ７０１，７０２，７０３が設けられる。カードホルダ７０３には、後述のアンケート入力の容易化のために窓部７０３Ａが設けられてもよい。蓋部ＢＸ１０Ａの側面６０２には、カードホルダ７０４と、日付ラベルを貼付けるためのラベル貼付部７０５とが配置される。

容器部ＢＸ１０Ｂは、一般的な箱状容器であって、食品の収容に適した材質であること、繰返し使用に耐える強度を有することなど、自明の特性を有すればよい。容器として、断熱性を持たせるのがよいか、熱伝導性を持つ方がよいかは、輸送上の都合から適宜選定すればよい。すなわち、冷蔵室等の内部に格納して配送するのであれば、容器が熱伝導性を持つ方がよいが、冷蔵保管された容器を内部に添付した保冷剤で低温に保ちつつ輸送するのであれば、容器に断熱性を持たせるのがよい。

図５は、食材入りの専用容器ＢＸ１０．１の蓋部ＢＸ１０Ａの上面６０１に配置される３つのカードの内容例を示す図である。

図５を参照して、３つのカードホルダ７０１、７０２および７０３に、それぞれ３つのカード８０１、８０２および８０３が配置される。カード８０１には、顧客番号すなわち、食材を配送するユーザー３０の顧客番号が記載される。カード８０２には、専用容器ＢＸ１０．１内蔵の食材に対応する調理メニューを特定するためのメニュー番号が記載される。

カード８０３は、表面８０３１および裏面８０３２（図６）を有している。配送担当者２０Ａがユーザー３０に届ける専用容器ＢＸ１０．１に添付する場合には、表面８０３１が表になるようにカードホルダ７０３に配置されている。表面８０３１には、専用容器ＢＸ１０．１内蔵の食材に関する料理ガイドが記載される。具体的には、ユーザー３０特有の認証情報としての３桁の照合番号８１０、および、調理器４００で食材を調理するための操作手順８１１が記載されている。

図６は、空の専用容器ＢＸ１０．２の蓋部ＢＸ１０Ａの上面６０１に配置される３つのカードの内容例を示す図である。

図６を参照して、ユーザー３０は、専用容器ＢＸ１０返却の際に、裏面８０３２が表になるようにカード８０３を裏返す。裏面８０３２は、フィードバック情報として用いるためのアンケートとなっている。アンケートには、たとえば、顧客番号を二次元化したＱＲコード８２０、および、食材に関する評価の記入欄８２１とが記載されている。

このように、カード８０３は、配送の際にはお料理ガイドカードとして、返却の際にはお客様要望カードとして機能する。

図７は、専用容器ＢＸ１０の蓋部ＢＸ１０Ａの側面６０２に配置されるカード８０４およびラベル８０５の内容例を示す図である。

図７を参照して、カード８０４は、カードホルダ７０４内に配置され、図５に示したカード８０１と同様に、顧客番号が記載されている。ラベル８０５は、ラベル貼付部７０５に貼り付けられ、配送日が記載される。

専用容器ＢＸ１０の蓋部ＢＸ１０Ａの側面６０２に、このようなカード８０４およびラベル８０５が配置されることで、配送担当者２０Ａによる専用容器ＢＸ１０の配送をスムーズにすることができる。

図８は、本発明の実施の形態における食材配送車の保管棚８０の構成例を示す図である。

図８を参照して、保管棚８０は、複数の間仕切りを有し、専用容器ＢＸ１０が各棚に個別に収納可能である。これにより、専用容器ＢＸ１０をランダムにアクセスすることができる。したがって、新規食材の入った専用容器ＢＸ１０．１と回収した専用容器ＢＸ１０．２とが混在しても、カード８０４が表わす顧客番号ごとに、専用容器ＢＸ１０を支障なく管理することができる。また、日付ラベル８０５により、配送担当者２０Ａは、新旧の区別を目視で確認することができる。

配送担当者２０Ａは、図９に示すような配送確認表８２に基づいて、食材の配送を行なう。図８では、保管棚８０の上面８１上に配置されている。

図９は、配送確認表８２の具体例を示す図である。
図９を参照して、配送確認表８２は、保管棚８０における顧客ごとの専用容器ＢＸ１０の配置構成と同じ構成とされる。そうすることで、配送済みか回収済みかを容易に確認することができる。

＜ハードウェア構成について＞
次に、本実施の形態における定期ケータリングシステム１を構成する装置のハードウェア構成の一例について説明する。

（サーバのハードウェア構成）
図１０は、本発明の実施の形態におけるサーバ１００のハードウェア構成を示すブロック図である。

図１０を参照して、サーバ１００は、一般的なパーソナルコンピュータと同様の構成であってよく、各種演算処理を行なうためのＣＰＵ（Central Processing Unit）１１０と、各種データおよびプログラムを格納するＲＯＭ（Read Only Memory）１１１と、作業データ等を格納するＲＡＭ（Random Access Memory）１１２と、操作者からの指示を受け付けるための操作部１１３と、各種情報を表示するための表示部１１４と、インターネット６との通信を行なうための通信Ｉ／Ｆ（インターフェイス）１１６と、ハードディスク１１７と、記録媒体１１８ｂからのデータやプログラムを読み出し／書き込み可能なドライブ装置１１８ａとを備える。記録媒体１１８ｂは、たとえば、ＣＤ−ＲＯＭ（Compact Disc-ROM）などの光学媒体や、メモリカードなどであってよい。

（宅配業者端末のハードウェア構成）
図１１は、本発明の実施の形態における宅配業者端末２００のハードウェア構成を示すブロック図である。

図１１を参照して、宅配業者端末２００も、サーバ１００と同様の構成を有しており、ＣＰＵ２１０と、ＲＯＭ２１１と、ＲＡＭ２１２と、操作部２１３と、表示部２１４と、通信Ｉ／Ｆ２１６と、ハードディスク２１７と、記録媒体２１８ｂからのデータを読み出し／書き込み可能なドライブ装置２１８ａとを備える。

宅配業者端末２００は、読取装置２４０，２４１，プリンタ２４２との間で情報を入出力するための入出力Ｉ／Ｆ２１５もさらに備える。読取装置２４０は、メニューの申し込み用紙から、ユーザーが指定したメニューを読取り、入出力Ｉ／Ｆ２１５を介してＣＰＵ２１０に出力する。読取装置２４１は、上述のお客様要望カードとして機能するカード８０３に記述されたＱＲコードを読取り、入出力Ｉ／Ｆ２１５を介してＣＰＵ２１０に出力する。プリンタ２４２は、ＣＰＵ２１０からの制御信号に応じて、メニュー一覧表、カード８０１〜８０４、ラベル８０５などの印刷を行なう。

（ユーザー端末のハードウェア構成）
図１２は、本発明の実施の形態におけるユーザー端末３００のハードウェア構成を示すブロック図である。

図１２を参照して、ユーザー端末３００は、たとえば、一般的な携帯端末（携帯電話など）であり、ＣＰＵ３１０と、ＲＯＭ３１１と、ＲＡＭ３１２と、操作部３１３と、表示部３１４と、通信Ｉ／Ｆ３１６と、フラッシュメモリ３１７と、記録媒体３１８ｂからのデータやプログラムを読み出し／書き込み可能なドライブ装置３１８ａとを備える。記録媒体３１８ｂは、たとえば、メモリカードである。なお、ユーザー端末３００は、調理器４００との間でデータの送受信を可能にするための機構（図示せず）をさらに備えていてもよい。

（調理器の外観およびハードウェア構成）
図１３は、本発明の実施の形態における調理器４００の外観例を示す図である。

図１３を参照して、調理器４００は、加熱調理器（オーブン電子レンジ）であり、より特定的には、過熱水蒸気を用いて食品の加熱調理を行なうことのできる加熱調理器である。なお、本実施の形態では、調理器が加熱調理器であることとするが、食材を調理することのできる家庭用調理器であれば、限定的ではない。調理器４００の正面には、ドア４１０および操作パネル４０４が設けられている。

図１４は、本発明の実施の形態における調理器４００のハードウェア構成の一例を示す図である。

図１４を参照して、調理器４００は、制御部４０２と、操作パネル４０４と、水タンク（図示せず）内の水を蒸気発生装置（図示せず）内に給水するためのポンプ４０６と、排気通路（図示せず）を開閉するためのダンパ４０８と、送風ファン４１０と、蒸気過熱ヒータ４１２と、蒸気発生ヒータ４１４と、被加熱物を加熱するためにマイクロ波を発生するためのマグネトロン４１６と、記憶部４１８と、外部からの情報を入出力するためのドライブ装置４２０とを備える。

制御部４０２は、たとえば、マイクロコンピュータおよび入出力回路等で構成される。
操作パネル４０４は、たとえば液晶パネル等で構成され、操作者の指示を受け付け、かつ、各種情報を表示する。記憶部４１８は、不揮発性のメモリ（たとえばフラッシュメモリ）である。ドライブ装置４２０は、たとえば、上述の記録媒体３１８ｂに記録されたデータを読出すことができる。

なお、調理器４００は、ユーザー端末３００との間でデータの送受信を可能にするための機構（図示せず）をさらに備えていてもよい。具体的には、たとえば、特許第３７７８７２８号公報に記載の方法を用いて、中継装置を介して両者の間でデータが送受信されてもよい。その場合、中継装置である中継ボックスのＵＡＲＴインターフェイスを接続するための中継端子を調理器４００が備えていればよい。または、調理器４００が、シリアルデータ転送手段であるＵＳＢ接続端子とこれを使用してデータ転送する通信手順を具備していれば、ユーザー端末３００のＵＳＢ端子と調理器４００のＵＳＢ端子とを接続することで、両者の間でデータを送受信することが可能である。

＜機能構成について＞
次に、本実施の形態における定期ケータリングシステム１を構成する各装置の機能構成の一例について説明する。

（サーバの機能構成）
図１５は、本発明の実施の形態におけるサーバ１００の機能構成を示す機能ブロック図である。

図１５を参照して、サーバ１００は、その機能として、レシピ登録処理部１０２とフィードバック情報処理部１０４とを含む。サーバ１００のハードディスク１１７には、レシピ管理ＤＢ（データベース）１５２と、顧客管理ＤＢ１５４と、人気メニュー管理ＤＢ１５６とが含まれる。

まず、サーバ１００が備える各ＤＢについて説明する。
レシピ管理ＤＢ１５２は、調理器４００での複数の調理メニューに関するレシピ情報を管理し、メニューデータテーブル１５２１とシーケンスデータテーブル１５２２とを有する。図１６および図１７にそれぞれのデータ構造例を示す。

図１６は、レシピ管理ＤＢ１５２におけるメニューデータテーブル１５２１のデータ構造の一例を示す図である。

図１６を参照して、メニューデータテーブル１５２１は、各調理メニューに対応する食材データを記憶し、たとえば、メニュー（料理）を識別するためのメニュー番号２０００ごとに、メニュー（料理）名を示すデータ２００１と、食材を示すデータ２００２と、食材ごとの量を示すデータ２００３と、カロリー制限レベルを示すデータ２００４と、調理シーケンスＮｏを示すデータ２００５と、使用する食材や調味料に関するデータ２００６とが記録される。本実施の形態において、カロリー制限レベルは、たとえば０〜５の６段階存在する。１つのメニューに対し、カロリー制限レベルごとに、調理シーケンスＮｏが設けられている。

図１７は、レシピ管理ＤＢ１５２におけるシーケンスデータテーブル１５２２のデータ構造の一例を示す図である。

図１７を参照して、シーケンスデータテーブル１５２２は、調理シーケンスＮｏ２０１０ごとに、たとえば、予熱時間を示すデータ２０１１、予熱温度を示すデータ２０１２、加熱時間を示すデータ２０１３、加熱温度を示すデータ２０１４など、調理器４００での調理制御のためのシーケンスデータが格納される。

顧客管理ＤＢ１５４は、宅配業者２０と定期ケータリング契約を結んでいる複数のユーザー３０に関する情報を管理する。顧客に関する情報は、宅配業者端末２００より得られる。

図１８は、顧客管理ＤＢ１５４のデータ構造の一例を示す図である。
図１８を参照して、顧客管理ＤＢ１５４には、定期ケータリング契約を結んでいる顧客である各ユーザー３０を識別するための顧客番号２０２０ごとに、住所を示すデータ２０２１と、氏名を示すデータ２０２２と、メールアドレスを示すデータ２０２３と、契約状況を示すデータ２０３０と、カロリー制限レベルを示すデータ２０２４と、調味料レベルを示すデータ２０２５と、除外すべき食材に関する除外情報２０２６とが格納される。

なお、サーバ１００に保有されるＤＢ１５４では、調味料レベルを示すデータ２０２５および除外情報２０２６は含まれなくてもよい。また、サーバ１００に記憶される顧客管理ＤＢ１５４には、プライバシー保護等の観点より、住所を示すデータ２０２１と、氏名を示すデータ２０２２と、メールアドレスを示すデータ２０２３は含まれなくてもよい。

契約状況データ２０３０は、契約開始日および契約期間（最長３年）を含む。
調味料レベルは、たとえば１〜１５の１５段階ある。ユーザー３０からのフィードバック情報に基づいて、そのレベルが調整される。除外情報２０２６は、たとえば、アレルギー性、嗜好、宗教禁忌などの項目を有しており、それぞれの項目に、除外すべき食材（調味料も含む）についての情報が格納される。

人気メニュー管理ＤＢ１５６は、フィードバック情報処理部１０４による処理結果の情報を管理する。人気メニュー管理ＤＢ１５６の内容例については後述する。

次に、各処理部の機能の概要を説明する。
レシピ登録処理部１０２は、メーカー１０が開発したレシピ情報をレシピ管理ＤＢ１５２に格納する処理を行なう。このような処理は、公知の手法により行なうことができる。

フィードバック情報処理部１０４は、宅配業者端末２００より通信Ｉ／Ｆ１１６を介して得られたフィードバック情報に基づいて、所定の処理を実行する。詳細は後述する。また、ランキング情報などの人気メニューに関する情報を、通信Ｉ／Ｆ１１６を介して、宅配業者端末２００に送信する。

なお、上述の各処理部の機能は、代表的に、ＲＯＭ１１１中に格納されたソフトウェアを実行することで実現される。

（宅配業者端末の機能構成）
図１９は、本発明の実施の形態における宅配業者端末２００の機能構成を示す機能ブロック図である。

図１９を参照して、宅配業者端末２００は、その機能として、メニュー提供処理部２０２と、登録・出力処理部２０４と、報知処理部２０６と、配送処理部２０８と、フィードバック情報処理部２１０とを含む。宅配業者端末２００のハードディスク２１７には、顧客管理ＤＢ２５４と、レシピ管理ＤＢ２５２と、各月メニューＤＢ２５６と、予約注文管理ＤＢ２５８と、人気メニューＤＢ２６０とが含まれる。

まず、各ＤＢについて説明する。
レシピ管理ＤＢ２５２は、サーバより予め送信された複数の調理メニューに関するレシピ情報を管理し、たとえばメニューデータテーブル２５２１を含む。メニューデータテーブル２５２１は、各メニューに対応する、食材データおよび調理器４００での調理シーケンスデータを識別するためのシーケンス識別データ（調理シーケンスＮｏ）を有している。そのデータ構造は、図１６に示したメニューデータテーブル１５２１と同様であってよい。なお、宅配業者端末２００のレシピ管理ＤＢ２５２にも、図１７に示したシーケンスデータテーブル１５２２が格納されていてもよい。

顧客管理ＤＢ２５４は、定期ケータリング契約を結んでいる顧客である各ユーザー３０に関する情報を管理する。そのデータ構造は、図１８に示した顧客管理ＤＢ１５４と同様であってよい。したがって、ここでの説明は繰返さない。なお、顧客管理ＤＢ２５４への各種情報の登録は、公知の手法により実行可能である。

各月メニューＤＢ２５６には、毎月ユーザー３０に提供するためのメニューに関する情報が格納される。

図２０は、予約注文管理ＤＢ２５８のデータ構造の一例を示す図である。
図２０を参照して、予約注文管理ＤＢ２５８は、顧客番号２０４０に対応付けて、日にちごとのメニュー番号を示すデータ２０４１が格納される。つまり、予約注文管理ＤＢ２５８には、ユーザー３０ごとに、月単位で予約注文されたメニュー番号が格納される。

次に、各処理部の機能の概要を説明する。
メニュー提供処理部２０２は、毎月、ユーザー３０に調理メニューに関する情報を提供する処理を行なう。メニュー提供処理部２０２が実行する処理は、公知の手法で行なうことができる。たとえば、各月メニューＤＢ２５６に格納された情報に基づいて、メニュー一覧表をプリンタ２４２で印刷する。この場合、配送担当者２０Ａが食材と併せてメニュー一覧表を配送する。あるいは、ユーザー端末３００から宅配業者２０のホームページにアクセスすると、メニュー一覧を見ることができるようにしてもよい。

登録・出力処理部２０４は、読取装置２４０と接続され、申し込み票６１０から読取られた予約注文情報を取得し、予約注文管理ＤＢ２５８に格納する。また、登録・出力処理部２０４は、レシピ管理ＤＢ２５２内の情報に基づいて、ユーザー３０ごとに、予約された調理メニューに関する予約シーケンス情報を出力する。「予約シーケンス情報」には、少なくとも、予約された各メニューのシーケンスＮｏ、すなわち、調理制御に用いられるシーケンスデータを特定するための識別情報が含まれる。

ユーザー３０がユーザー端末３００を保有している場合、通信Ｉ／Ｆ２１６を介して予約シーケンス情報が出力される。ユーザー３０がユーザー端末３００を保有していない場合には、たとえば、記録媒体２１８ｂに予約シーケンス情報を記録することで、予約シーケンス情報が出力されてもよい。後者の場合、配送担当者２０Ａが食材を配送する際に記録媒体２１８ｂも持参し、配送担当者２０Ａまたはユーザー３０が、調理器４００に記録媒体２１８ｂを差し込むことで、予約シーケンス情報を調理器４００にセットしてもよい。

報知処理部２０６は、顧客管理ＤＢ２５４の契約状況データに基づいて、所定期間（たとえば月）ごとに、ユーザー３０の契約状況情報を報知する。「契約状況情報」は、少なくとも使用状況と、定期契約の解約手数料の情報とを含み、さらに、契約継続による料金低減状況をも含むことが好ましい。本実施の形態では、たとえば、毎月、ユーザー３０に発行する請求書に、このような契約状況約情報が印刷される。なお、これに代えて、ユーザー端末３００にて宅配業者２０のホームページにアクセスした場合に、契約状況情報が表示されるようにしてもよい。

ここで、報知処理部２０６により、契約状況情報を表示することとした背景は以下のとおりである。すなわち、ユーザー３０は一定期間の契約を前提に、宅配業者２０から食材提供を受けるが、転勤、病気等により契約を解除する必要が発生することがある。あるいは、一旦期間を決めて契約すると、解約の際に多額の解約手数料を取られるのではないか、あるいは、解約の時期によっては、解約手数料が割高になるのではないかとの不安に駆られて、本定期ケータリングシステム１に基づく定期ケータリング契約に対して、潜在的な不満が募る恐れがある。

定期ケータリング契約の解約手数料の設定方法とユーザー３０に対する開示は、ユーザー３０の満足感の充足が目的であるので、解約手数料を合理的な基準で設定し、これを随時ユーザー３０に開示する。これによって、随時解約可能という安心感を与えることができる。解約条件を明示することによりユーザー３０の不安を取り除けば、いつでも、一定の基準で解約手数料を支払うだけであることが明確になるので、結果として、定期ケータリング契約を継続する動機付けになることが期待できる。本実施の形態のような解約手数料の合理的な設定により解約手数料を明示する方法は、高額の解約手数料を設定することによってユーザー３０の拘束を図る方法に比べて、ユーザー３０に安心感を与えるので好ましい。なお、具体的な解約手数料の設定方法は後述する。

設定した解約手数料は、宅配開始前に締結する契約書等に明示するとともに、毎月の請求書に当月における解約料を印刷して、ユーザー３０に明確に伝えるようにする。これにより、ユーザー３０の安心感と、いつまで続けた方が得かといった推定（計算）がユーザー自身で行える効果がある。

配送処理部２０８は、予約注文管理ＤＢ２５８に基づいて、毎日、その日に予約していたユーザー３０に食材を配送するための処理を実行する。具体的には、専用容器ＢＸ１０．１に添付する書類データすなわち、４つのカード８０１，８０２，８０３，８０４および日付けラベル８０５と、配送確認表８２とを印刷する。

フィードバック情報処理部２１０は、ユーザー３０より、配送したレシピ付き食材に関するフィードバック情報を処理する。たとえば、お客様要望カード８０３（８０３２）のＱＲコードを読取装置２４１が読取ることでユーザーを特定し、上述のお客様要望カード８０３（８０３２）に記入されたアンケートの内容を入力する。そして、入力された内容をサーバ１００に転送する。また、フィードバック情報処理部２１０においても、ユーザー３０ごとに、入力された内容を反映する処理を行なう。また、フィードバック情報処理部２１０は、サーバ１００より送信された人気メニューに関する情報を、人気メニューＤＢ２６０に格納する。

なお、上述の各処理部の機能は、代表的に、ＲＯＭ２１１中に格納されたソフトウェアを実行することで実現される。

（ユーザー端末および調理器の機能構成）
図２１は、ユーザー端末３００および調理器４００それぞれの機能構成を示す機能ブロック図である。

図２１を参照して、ユーザー端末３００は、その機能として、転送処理部３０２を含む。転送処理部３０２は、宅配業者端末２００より送信された、対象のユーザー３０についての予約シーケンス情報を調理器４００に転送する処理を行なう。具体的には、たとえば、通信Ｉ／Ｆ３１６を介して、宅配業者端末２００が提供するホームページより、予約シーケンス情報をダウンロードする。そして、ドライブ装置３１８ａを介し、着脱可能な記録媒体３１８ｂにダウンロードした予約シーケンス情報を格納する。

調理器４００は、その機能として、取得処理部４３２と、メニュー特定処理部４３４と、調理制御部４３６とを含む。また、調理器４００の記憶部４１８には、ユーザー情報４１８１と、予約シーケンス情報４１８２と、シーケンスデータテーブル４１８３とが記憶される。記憶部４１８内のデータについては後述する。

取得処理部４３２は、ユーザー端末３００により転送されてきた予約シーケンス情報の取得処理を行なう。たとえば、取得処理部４３２は、ドライブ装置４２０を駆動し、メニュー情報が記録された記録媒体３１８ｂより予約シーケンス情報を取得する。そして、取得した予約シーケンス情報を、記憶部４１８に格納する。

メニュー特定処理部４３４は、操作パネル４０４からの操作信号に基づき、調理を開始するメニューを特定する処理を行なう。調理制御部４３６は、特定されたメニューの調理シーケンスデータに応じた調理制御を行なう。

上述の各処理部の機能は、代表的に、ＲＯＭ３１１，記憶部４１８中に格納されたソフトウェアを実行することで実現される。

図２２は、調理器４００の記憶部４１８に記憶されるユーザー情報４１８１のデータ構造の一例を示す図である。

図２２を参照して、ユーザー情報４１８１は、対象のユーザー３０についての顧客番号を示すデータ２０５０と、ユーザー名を示すデータ２０５１とを含む。

図２３は、予約シーケンス情報４１８２のデータ構造の一例を示す図である。
図２３を参照して、予約シーケンス情報４１８２は、日付を示すデータ２０６０ごとに、メニュー番号を示すデータ２０６１と、メニュー名を示すデータ２０６２と、調理シーケンスＮｏを示すデータ２０６３とが記憶される。

シーケンスデータテーブル４１８３のデータ構造は、図１７に示したシーケンスデータテーブル１５２２と同様である。したがって、説明は繰返さない。

本実施の形態において、調理器４００は、過熱水蒸気調理器であるため、同じ料理であっても、油分を落とす量なども調整することができる。したがって、サーバ１００において、レシピが開発（または変更）され、シーケンスデータテーブル１５２２にシーケンスデータを登録する際に、カロリー制限レベルが高い程、油分を落とす量を多くするようなシーケンスが設定されているものとする。

なお、ユーザー情報４１８１およびシーケンスデータテーブル４１８３の内容は、調理器４００がユーザー３０の自宅に設置される際に、予め、メーカー１０またはメーカー関連会社５０のサービスマンにより、予め、登録されているものとする。また、サーバ１００にて新規のレシピが開発された場合には、メーカー関連会社５０のサービスマンが新たなシーケンスデータを調理器４００にセットできるものとする。このように、メーカー関連会社５０のサービスマンが調理器４００のデータを更新できるのは、調理器４００の所有権がユーザー３０ではなくリース会社４０にあるためである。

＜動作について＞
次に、本実施の形態における定期ケータリングシステム１の動作について説明する。

（予約シーケンス情報格納処理）
図２４は、本発明の実施の形態の定期ケータリングシステム１において実行される予約シーケンス情報格納処理を示すフローチャートである。本実施の形態において、当該処理は、月単位で実行される。

図２４を参照して、宅配業者端末２００の読取装置２４０は、メニュー申込表６１０から注文情報を読取る（ステップＳ１００）。そして、登録出力処理部２０４は、ユーザー３０ごとに、注文情報が示す予約されたメニュー番号のデータを予約注文管理ＤＢ２５８に登録する（ステップＳ１０２）。

注文情報が登録されると、登録・出力処理部２０４は、対象のユーザー端末３００に対し、注文情報が登録されたことを通知する（ステップＳ１０６）。具体的には、たとえば、顧客管理ＤＢ２５４に格納されたメールアドレスを送信先とする電子メールを送信する。

ユーザー端末３００は、登録通知を受信すると（ステップＳ１０８）、転送処理部３０２は、ユーザー３０の指示に基づいて、宅配業者２０のホームページにアクセスする（ステップＳ１１０）。そうすると、宅配業者端末２００により、ホームページ画面が提供される（ステップＳ１１２）。ここで、ユーザー端末３００の表示部３１４に表示されるホームページの画面の一例を図２５に示す。

図２５を参照して、表示部３１４には、顧客番号を入力するための領域３００１と、調理メニューのダウンロードを指示するためのチェックボックス３００２と、実行を指示するためのボタン３００４とが表示される。なお、図２５に示されるように、契約状況の確認を指示するためのチェックボックス３００３がさらに設けられてもよい。

図２５に示した画面の領域３００１に、ユーザーより、顧客番号が入力され（ステップＳ１１４）、実行指示ボタン３００４が選択されると、転送処理部３０２は、予約シーケンス情報のダウンロードを要求する（ステップＳ１１６）。

宅配業者端末２００の登録・出力処理部２０４は、ダウンロードが要求されると、予約注文管理ＤＢ２５８より、入力された顧客番号に対応する１ヵ月分（代表的に翌月分）の注文情報（メニュー番号）を読出す（ステップＳ１１８）。そして、登録・出力処理部２０４は、読出された注文に基づいて、調理器４００に格納すべき予約シーケンス情報を生成する（ステップＳ１１９）。ステップＳ１１９において、登録・出力処理部２０４は、ユーザー３０ごとに適した調理シーケンスを選択する。具体的には、たとえば、予約されたメニュー番号が「ＬＣ２５８０」で、ユーザーのカロリー制限レベルが「１」であるとすると、ユーザーに適した調理シーケンスＮｏとして、それらを組み合わせた「ＬＣ２５８０１」が選択される。ここで生成された予約シーケンス情報は、図２３に示すように、メニュー番号とメニュー名も含む。

宅配業者端末２００の登録・出力処理部２０４は、生成した予約シーケンス情報を通信Ｉ／Ｆ２１６を介してユーザー端末３００に送信する（ステップＳ１２０）。これにより、ユーザー端末３００の転送処理部３０２によって、１ヵ月分の予約シーケンス情報がダウンロードされる（ステップＳ１２２）。ダウンロードされた予約シーケンス情報は、記録媒体（たとえばメモリカード）３１８ｂに書込まれる（ステップＳ１２４）。

ユーザー３０によって、予約シーケンス情報が書込まれたメモリカード３１８ｂが調理器４００のスロット（図示せず）に差し込まれると、調理器４００のドライブ装置４２０は、１ヵ月分の予約シーケンス情報をメモリカード３１８ｂから読出す（ステップＳ１２６）。取得処理部４３２は、読出された予約シーケンス情報を記憶部４１８に格納する（ステップＳ１２８）。ここで記憶された予約シーケンス情報が、図２３に示した予約シーケンス情報４１８２である。なお、本実施の形態では、少なくとも、今月分と翌月分との２ヵ月分の予約シーケンス情報が記憶されるものとする。

このようにして、毎月、ユーザーにより予約されたメニューの調理シーケンスデータを特定するための情報が調理器４００に格納される。なお、本実施の形態では、月単位で、注文を受付けることを前提としているが、限定的ではなく、たとえば、週単位で受付けてもよい。

（配送前の印刷処理）
図２６は、本発明の実施の形態の定期ケータリングシステム１における宅配業者端末２００によって実行される配送前の印刷処理を示すフローチャートである。当該処理は、たとえば、配送対象の食材がある日の当日の午前中に実行される。

図２６を参照して、宅配業者端末２００の配送処理部２０８は、対象の顧客（ユーザー３０）ごとに、認証情報として機能させるためのたとえば３桁の照合番号を算出する（ステップＳ２００）。

照合番号は、セキュリティと誤配防止の目的で採用しているものであるが、実際上、最低限の効果を奏するには、ユーザー３０の操作の際に、配布された食材の顧客番号とメニュー番号とが誤っていないことが確認できるだけでよい。ここでは、安易に推察されず、近隣での重複を避けられる程度のセキュリティを確保できると思われるような、照合番号の計算方法の一例を示す。すなわち、顧客番号とメニュー番号の各英文字で、英文字のアルファベット中の位置から導き出される４桁数字と、引き続く４桁数字とを、所定の計算式により演算することで、３桁の整数を導き出す。

顧客番号の２つの英文字から導き出される４桁数字を「第１特定番号」、メニュー番号の２つの英文字から導き出される４桁数字を「第２特定番号」とすると、照合番号は、“「第１特定番号」×８＋「顧客番号の数字」×４＋「第２特定番号」×２＋「メニュー番号の数字」×１＋定数（たとえば７８１）”により求められた数字（以下「基礎番号」という）の下３桁とする。定数は、無作為に選択した整数であってよい。

たとえば、顧客番号が「ＡＨ１００２」、メニュー番号が「ＬＣ２５８０」の場合について説明する。

「Ａ」は、０１番目、「Ｈ」は、０８番目であるので、「ＡＨ」は、これらを組み合わせた「０１０８」とする。「Ｌ」は、１２番目，「Ｃ」は、０３番目であるので、「ＬＣ」は、これらを組合わせた「１２０３」とする。そうすると、
基礎番号＝０１０８×８＋１００２×４＋１２０３×２＋２５８０×１＋７８１
＝１０６３９
と算出される。したがって、「１０６３９」の下３桁「６３９」を照合番号として使用する。

なお、以上の手法は、実用上支障のない範囲で一意性のある３桁数字を発生させる初級的なアルゴリズムの一例である。実際のシステム運用に当たっては、より高度な計算方法を採用してもよい。

配送処理部２０８は、オペレータによる操作に基づいて、対象の顧客ごとに、各カード８０１，８０３，８０３，８０４およびラベル８０５のデータを生成する（ステップＳ２０２）。また、配送処理部２０８は、図９に示したような配送確認表８２のデータを生成する（ステップＳ２０４）。

各データが生成されると、プリンタ２４２にて、各書類（カード，配送確認表など）が印刷される（ステップＳ２０６）。印刷された各カードおよびラベルは、専用容器ＢＸ１０．１に添付される。

このようにして必要な情報が添付された専用容器ＢＸ１０．１に、宅配業者２０の作業員は、ユーザー３０に配送するための食材を入れる。そして、図３に示したように、配送担当者２０Ａによって、食材が入った専用容器ＢＸ１０．１が当日中（好ましくは指定時間）に届けられる。

（調理処理）
図２７は、本発明の実施の形態の定期ケータリングシステム１において、調理器４００により実行される調理処理を示すフローチャートである。当該処理は、ユーザー３０より、定期ケータリング契約に基づく調理の開始の指示が入力された場合に、開始される。ユーザー３０は、専用容器ＢＸ１０．１に添付された料理ガイドカード８０３（８０３１）に記載された操作手順８１１（図５）に従い、操作パネル４０４を操作することができる。以下の処理は、ユーザー３０により、調理器４００の庫内に、届けられた食材が入れられていると仮定する。

なお、当該調理処理は、食材が届けられた日に実行されることが想定されるが、食材の種類によっては、翌日以降に調理しても良いものもあるため、必ずしも当日でなくてよい。

図２７を参照して、はじめに、調理器４００のメニュー特定処理部４３４は、操作パネル４０４に、照合番号の入力を促す表示を行なう（ステップＳ３０２）。たとえば、操作パネル４０４に、「お料理ガイドに記載された３桁の番号を入力して下さい」というメッセージが表示される。

ユーザー３０より照合番号の入力を受付けると（ステップＳ３０４）、受付けた照合番号より、所定のアルゴリズムで顧客番号とメニュー番号とを特定する（ステップＳ３０６）。具体的には、上述の照合番号算出アルゴリズムにより算出された３桁の番号を解析して、元の顧客番号とメニュー番号とを導出する処理を実行する。

次に、メニュー特定処理部４３４は、特定した顧客番号およびメニュー番号に基づいて、お客様名と料理名とを操作パネル４０４に表示する（ステップＳ３０８）。本実施の形態では、記憶部４１８のユーザー情報４１８１として、調理器４００の使用権を与えられた１人のユーザーについての情報のみが記憶されているため、特定された顧客番号が、記憶された顧客番号２０５０と異なる場合には、たとえば、エラーとして表示される。メニュー特定処理部４３４は、記憶部４１８の予約シーケンス情報４１８２内のメニュー番号２０６１より特定されたメニュー番号を検索し、合致したメニュー番号に対応するメニュー名を操作パネル４０４に表示する。なお、もしも、特定されたメニュー番号が、予約シーケンス情報４１８２内のメニュー番号２０６１に存在しない場合には、上記と同様に、たとえばエラー表示してよい。

次に、ユーザー３０より、開始指示が入力されると（ステップＳ３１０）、調理制御部４３６は、特定されたメニュー番号とユーザーのカロリー制限レベルにより定まる調理シーケンスＮｏを抽出し、抽出された調理シーケンスＮｏに応じた調理を開始する（ステップＳ３１２）。具体的には、予約シーケンス情報４１８２において、特定されたメニュー番号と対応付けられた調理シーケンスＮｏのデータ２０６３を抽出する。そして、シーケンスデータテーブル４１８３において、抽出された調理シーケンスＮｏに対応付けられたシーケンスデータを読出し、読出したシーケンスデータが示す内容（レシピ）に従い、調理制御を開始する。

このように、本実施の形態によると、ユーザー３０のカロリー制限レベルに応じた調理が自動的に実行される。そして、調理制御が終わると、レシピ通りの料理が出来上がる。これにより、ユーザー３０は、自身のカロリー制限レベルに応じた、レシピ通りの健康的で美味しい料理を味わうことができる。その結果、ユーザー３０は、定期ケータリングサービスを利用することにより、自身の好むレシピを味わいながら、肥満、高血圧、糖尿病などの病状を改善したり、摂取カロリーを低減したりすることが可能となる。

また、このような効果により、口コミ等によっても、定期ケータリングサービスを利用するユーザーが増えることも予想される。これにより、宅配業者２０は、顧客を増やすことができる。また、メーカー１０にとっては、ユーザーの成功体験を引用することにより、メーカー自身として主張が困難な表現によって調理器４００を宣伝することもできる。あるいは、調理器４００の効果、効用を統計的に意味のあるデータとして消費者一般に伝えることもできる。具体的には、ユーザー３０からのフィードバック情報を処理することによって、数多くのユーザーの評価を伝えることもできるし、地域ごとの人気メニューを本システムの会員（ユーザー３０）以外の消費者に宣伝することもできる。

なお、定期ケータリング契約を結んだユーザーの数に応じて、メーカー１０が宅配業者２０に所定金額支払うように定めていてもよい。または、宅配業者２０は、会員を増やすために調理器４００を一般消費者に宣伝するため、メーカー１０は、宅配業者２０との契約の際に、宣伝代行代金として所定金額支払うようにしてもよい。デフォルトの契約条件では、宅配業者２０は、ユーザー３０の代わりに、リース料を支払うが、このように、メーカー１０側から宅配業者２０にインセンティブを与えることで、本サービスのユーザーを増やす効果を生み出すことが期待できる。

また、宅配業者２０がこのようなインセンティブを本サービスの会員に対してその一部を還元することとしてもよく、そのような場合には、メーカー１０、宅配業者２０、ユーザー３０の三者にとって、より魅力的な契約条件を設定することが可能となる。これにより、さらに、本サービスのユーザーを増やす効果を生み出すことが期待できる。

このような、ポジディブフィードバック現象を生み出すことにより、メーカー１０、宅配業者２０、ユーザー３０の三者のそれぞれに対して、有意義な便益を提供することが、定期ケータリングシステム提供の主たる目的の一つであるので、高度な情報処理に基づいて、的確なインセンティブを提供するのが望ましい。

具体的には、宅配業者端末２００から、新規の顧客に関する情報が送られてきた場合に、サーバ１００は、インターネット６に接続された銀行サーバより、自動的に、所定金額、宅配業者端末２００の口座に送金することとしてもよい。

（フィードバック処理）
図２８は、本発明の実施の形態における定期ケータリングシステム１において実行されるフィードバック処理を示すフローチャートである。

図２８を参照して、宅配業者端末２００の読取装置２４１が、お客様要望カード８０３（８０３２）上のＱＲコード８２０を読取る（ステップＳ４０２）。宅配業者端末２００のフィードバック情報処理部２１０は、読取ったＱＲコードから顧客番号を特定する（ステップＳ４０４）。

次に、フィードバック情報処理部２１０は、オペレータによる、フィードバック情報すなわち、お客様要望カード８０３の評価の記入欄８２１（図６）に記入された内容の入力を受付ける（ステップＳ４０６）。なお、オペレータによる入力に限定されず、たとえば、申し込み用紙６１０を読取るための読取装置２４０により評価情報が読取られてもよい。

フィードバック情報処理部２１０は、受付けた内容に応じて、必要であれば、顧客管理ＤＢ２５４の調味料レベル２０２５を変更する（ステップＳ４０８）。具体的には、図６に示した記入欄８２１の評価項目２（味付け）の欄において、真中以外のボックスが塗り潰されていた場合に、ユーザー好みの味付けとなるように、調味料レベル２０２５を変更する。なお、フィードバック情報処理部２１０は、フィードバック情報に基づいて、調味量レベルの調整以外の処理を行なってもよい。

また、フィードバック情報処理部２１０は、入力されたフィードバック情報を顧客番号と対応付けてサーバ１００に送信する（ステップＳ４１０）。

サーバ１００のフィードバック情報処理部１０４は、フィードバック情報を受信する（ステップＳ４１２）。受信したフィードバック情報は、たとえばハードディスク１１７の所定の領域に記憶される。このように、本実施の形態によると、調理器４００で用いられるレシピに関するフィードバック情報を、宅配業者端末２００を介して容易にかつ頻繁に取得することができる。その結果、メーカー１０は、レシピの改良・開発を適宜行なうことができ、かつ、そのレシピを宅配業者２０に与えることができる。これにより、宅配業者２０は、自身でレシピの開発を行なわなくても、新規レシピや改良レシピを入手することができる。その結果、宅配業者２０は、レシピの開発等に投入する諸経費を削減することができる。宅配業者２０がこのような恩恵を受けることができることも、調理器４００のリース料をユーザー３０に代わって支払うことができる一因である。

なお、メーカー１０は、フィードバック情報を取得すると、たとえばその数に応じて所定金額支払うようにしてもよい。このように、フィードバック情報についても宅配業者２０にインセンティブを与えることで、多くのフィードバック情報を吸収することが可能となる。したがって、ここでも、上記と同様に、たとえば、宅配業者端末２００から、フィードバック情報が送られてきた場合に、サーバ１００は、インターネット６に接続された銀行サーバより、自動的に、所定金額、宅配業者端末２００の口座に送金することとしてもよい。

次に、図６に示した記入欄８２１の評価項目１〜４（料理の量、味付け、野菜、ご飯）それぞれについて、たとえば、月単位で集計する（ステップＳ４１４）。集計結果に基づき、料理ごとに、食材および調味料の量や種別を変更してもよい（ステップＳ４１６）。

本実施の形態では、フィードバック情報処理部１０４は、図６に示した記入欄８２１の評価項目６（全体として満足か否か）について、所定期間（たとえば月）単位で、カロリー制限別の人気メニューランキングを作成する（ステップＳ４１８）。具体的には、図２９を用いて説明する。

図２９は、人気メニュー管理ＤＢ１５６内に格納される、評価管理テーブル１５６１のデータ構造例を示す図である。

図２９を参照して、評価管理テーブル１５６１には、メニュー番号を示すデータ２０８０と、カロリー制限レベルを示すデータ２０８１と、５段階の満足レベル（２，１，０，−１，−２）のデータ欄２０８２が設けられる。

たとえば、５段階の満足レベルのうち、「２（満足）」と評価されていたとすると、フィードバック情報処理部１０４は、対応するメニュー番号の欄であって、対象ユーザーのカロリー制限レベルの行の、満足レベル「２」のデータ欄の値を１インクリメントする。このような処理は、フィードバック情報を受信したタイミングで行なわれてよい。そして、たとえば月初めなどに、カロリー制限レベルごとに、満足レベル「２」の値の大きい順に、図３０に示すような、人気メニューランキングテーブルを生成する。なお、満足レベル「２」の数値の絶対値によりランキングするものに限定されず、たとえば、相対値によりランキングしてもよい。

図３０は、人気メニュー管理ＤＢ１５６内に格納される、人気メニューランキングテーブル１５６２のデータ構造例を示す図である。

図３０を参照して、人気メニューランキングテーブル１５６２には、カロリー制限レベル２０９０と対応付けて、月ごとの人気メニュー２０９１が格納される。具体的には、満足レベル「２」の値の大きい順に、所定の順位（たとえば１０位）までのメニュー番号が格納される。

再び図２８を参照して、先月分の人気メニューランキングが生成されると、サーバ１００のフィードバック情報処理部１０４は、先月分の人気メニューランキングの情報、すなわち、ランキングされた順位と対応付けてメニュー番号の情報を、宅配業者端末２００に送信する（ステップＳ４２０）。

宅配業者端末２００のフィードバック情報処理部２１０は、先月分の人気メニューランキングの情報を受信すると（ステップＳ４２２）、ハードディスク２１７内の人気メニューＤＢ２６０に格納する。これにより、宅配業者端末２００の人気メニューＤＢ２６０にも、図３０の人気メニューランキングテーブル１５６２と同様のデータが格納される。

宅配業者端末２００は、人気メニューＤＢ２６０に格納された情報を、次月分のメニューに反映させる処理を行なう。たとえば、メニュー提供処理部２０２は、カロリー制限別の人気メニューランキングの情報を、次月分のメニュー表に追加する（ステップＳ４２４）。そうすることで、ユーザー３０にとっては自分の制限レベルでどれが美味しいかが分かるし、宅配業者２０の配送担当者２０Ａは、ユーザー３０がどのカロリー制限レベルか知らないので、プライバシーも守ることができる。

なお、ステップＳ４２４の処理において、各月メニューＤＢ２５６に格納された次月分のメニュー情報を、カロリー制限別ランキングに従い並び替えることで、次月分のメニュー表を作成してもよい。

（契約状況情報報知処理）
図３１は、本発明の実施の形態における定期ケータリングシステム１において実行される契約状況情報報知処理を示すフローチャートである。本実施の形態において、契約状況は、毎月発行される請求書に印刷されることで、ユーザー３０に報知される。

図３１を参照して、報知処理部２０６は、顧客ごとに、解約金を計算する（ステップＳ５０２）。具体的には、宅配業者端末２００が備える計時部（図示せず）が出力する現在の日付け（月日）と、顧客管理ＤＢ２５４の契約状況データ２０３０とに基づいて、解約金を計算する。

ここで、具体的な解約金の設定方法について説明する。たとえば、価格条件を、調理器４００の本体価格：100,000円/台、リース総額(1年)：111,600円/年・台とする。その場合、月額リース料は、月々9,300円である。一日分の食材費をたとえば1,000円と仮定すると、月額の食材費は30,000円(1,000円*30日)と推定する。そうすると、月額総費用は、39,300円（9,300円＋30，000円）である。

解約手数料を式で表わすと、以下のようになる。
途中解約料＝リース総額−（月額リース料×経過月数）＋宅配解約料
たとえば、４ヵ月使用後、５ヵ月目の冒頭に解約する場合の途中解約料は以下のように計算される。

途中解約料＝111,600円−（9,300円×4カ月）＋39,300円
＝113,700円
定期ケータリングシステム１では、契約終了時に、調理器４００の本体を引き取る必要がある。これには、例えば、引き取り費用として、技術料＋出張工事料として、10,000円程度の費用が発生する。契約期間満了による契約終了の場合は、引き取り費用は、定期ケータリング契約に含まれる費用として宅配業者２０が負担する。しかし、途中解約による契約終了の場合は、定期ケータリング契約外の費用となり、ユーザー３０が負担することが適当であると考えられる。

１年契約の場合の、経過月ごとの解約金の逓減具合の一例を図３２に示す。
上記のような取り扱いをする背景として、途中解約の場合は、本体価格の償却が完了していないため、宅配業者２０は、引き取った本体を整備、安全点検の上で中古販売するなどの施策によって本体価格の未償却分の一部を回収する必要がある。そのため、宅配業者２０にとって発生費用の吸収が困難である点が挙げられる。

再び図３１を参照して、報知処理部２０６は、予約注文管理ＤＢ２５８に記憶された先月分の注文データと、予め料理ごとに定められた代金とに基づいて、請求データを生成する（ステップＳ５０４）。そして、契約状況情報を載せた請求書を印刷する（ステップＳ５０６）。

以上のように、本実施の形態では、契約継続に伴う料金逓減状況を予告することにより、引き続き使用し、定期ケータリングシステム１の便益を享受し続けると、使用料金が逓減していく展望を与えることができるので、途中解約を抑制する効果が期待できる。

また、解約手数料と使用料逓減のデータを随時ユーザー３０に開示することよって、ユーザー３０が定期ケータリングサービスに満足である限り、契約継続する事の動機付けを与え、上記した途中解約による損失を逓減することができる。また、ユーザー３０の顧客満足度を高めることもでき、ユーザー３０は、定期ケータリングシステム１による宅配を満足して続けることができる。定期ケータリングシステム提供の主たる目的の一つは、消費者が過熱水蒸気調理器に対して潜在的に抱いている、初期コストに対する懸念と使いこなしに対する懸念を解消する心理的な効果を消費者に与えることであるので、ユーザーに対して束縛感を与えない課金システムが望ましい。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本発明の実施の形態における定期ケータリングシステムの全体構成を示すブロック図である。 本発明の実施の形態における定期ケータリングシステムにおける物および情報の流れの概要を示す図である。 宅配業者とユーザーとの間で行なわれる食材配送方法の一形態を示す図である。 本発明の実施の形態における専用容器の外観例を示す図である。 食材入りの専用容器の蓋部の上面に配置される３つのカードの内容例を示す図である。 空の専用容器の蓋部の上面に配置される３つのカードの内容例を示す図である。 専用容器の蓋部の側面に配置されるカードおよびラベルの内容例を示す図である。 本発明の実施の形態における食材配送車の保管棚の構成例を示す図である。 配送確認表の具体例を示す図である。 本発明の実施の形態におけるサーバのハードウェア構成を示すブロック図である。 本発明の実施の形態における宅配業者端末のハードウェア構成を示すブロック図である。 本発明の実施の形態におけるユーザー端末のハードウェア構成を示すブロック図である。 本発明の実施の形態における調理器の外観例を示す図である。 本発明の実施の形態における調理器のハードウェア構成の一例を示す図である。 本発明の実施の形態におけるサーバの機能構成を示す機能ブロック図である。 レシピ管理ＤＢにおけるメニューデータテーブルのデータ構造の一例を示す図である。 レシピ管理ＤＢにおけるシーケンスデータテーブルのデータ構造の一例を示す図である。 顧客管理ＤＢのデータ構造の一例を示す図である。 本発明の実施の形態における宅配業者端末の機能構成を示す機能ブロック図である。 予約注文管理ＤＢのデータ構造の一例を示す図である。 ユーザー端末および調理器それぞれの機能構成を示す機能ブロック図である。 調理器の記憶部に記憶されるユーザー情報のデータ構造の一例を示す図である。 予約シーケンス情報のデータ構造の一例を示す図である。 本発明の実施の形態の定期ケータリングシステムにおいて実行される予約シーケンス情報格納処理を示すフローチャートである。 ユーザー端末の表示部に表示される宅配業者のホームページの画面の一例を示す図である。 本発明の実施の形態の定期ケータリングシステムにおける宅配業者端末によって実行される配送前の印刷処理を示すフローチャートである。 本発明の実施の形態の定期ケータリングシステムにおいて、調理器により実行される調理処理を示すフローチャートである。 本発明の実施の形態における定期ケータリングシステムにおいて実行されるフィードバック処理を示すフローチャートである。 人気メニュー管理ＤＢ内に格納される、評価管理テーブルのデータ構造例を示す図である。 人気メニュー管理ＤＢ内に格納される、人気メニューランキングテーブルのデータ構造例を示す図である。 本発明の実施の形態における定期ケータリングシステムにおいて実行される契約状況情報報知処理を示すフローチャートである。 １年契約の場合の、経過月ごとの解約金の逓減具合の一例を示す図である。

符号の説明

１ 定期ケータリングシステム、６ インターネット、１０ メーカー
２０ 宅配業者、２０Ａ 配送担当者、３０ ユーザー、４０ リース会社
５０ メーカー関連会社、８０ 保管棚、８２ 配送確認表、１００ サーバ
１０２ レシピ登録処理部、１０４ フィードバック情報処理部
１１０，２１０，３１０ ＣＰＵ
１１１，２１１，３１１ ＲＯＭ
１１２，２１２，３１２ ＲＡＭ
１１３，２１３，３１３ 操作部
１１４，２１４，３１４ 表示部
１１７，２１７ ハードディスク、１１８ａ，２１８ａ，３１８ａ ドライブ装置
１１８ｂ，２１８ｂ，３１８ｂ 記録媒体
２００ 宅配業者端末、２０２ メニュー提供処理部、２０４ 登録・出力処理部
２０６ 報知処理部、２０８ 配送処理部、２１０ フィードバック情報処理部
２４０，２４１ 読取装置、２４２ プリンタ、３００ ユーザー端末
３０２ 転送処理部、３１７ フラッシュメモリ、４００ 調理器
４０２ 制御部、４０４ 操作パネル、４０６ ポンプ、４０８ ダンパ
４１０ 送風ファン、４１２ 蒸気加熱ヒータ、４１４ 蒸気発生ヒータ
４１６ マグネトロン、４１８ 記憶部、４２０ ドライブ装置
４３２ 取得処理部、４３４ メニュー特定処理部、４３６ 調理制御部
４８２ 記憶部、７０１，７０２，７０３ カードホルダ、７０５ ラベル貼付部
８０１，８０２，８０３，８０４ カード、８０５ ラベル
１５２１ メニューデータテーブル、１５２２ シーケンスデータテーブル
１５６１ 評価管理テーブル、１５６２ 人気メニューランキングテーブル
２５２１ メニューデータテーブル、４１８１ ユーザー情報
４１８２ 予約シーケンス情報、４１８３ シーケンスデータテーブル
ＢＸ１０ 専用容器、１５２ レシピ管理ＤＢ、１５４ 顧客管理ＤＢ
１５６ 人気メニュー管理ＤＢ、２５２ レシピ管理ＤＢ
２５４ 顧客管理ＤＢ、２５６ 各月メニューＤＢ、２５８ 予約注文管理ＤＢ
２６０ 人気メニューＤＢ、１１６，２１６，３１６ 通信Ｉ／Ｆ
２１５ 入出力Ｉ／Ｆ

Claims (10)

1. 宅配業者が複数の顧客に対し、一定期間食材を配送するためのケータリングシステムであって、
   前記宅配業者に保有される第１の端末と、
   各前記顧客に対し、一定期間貸し出される複数の調理器と、
   前記第１の端末とインターネットを介して接続され、前記調理器のメーカーに保有されるサーバとを備え、
   前記サーバは、
   前記調理器での調理シーケンスデータと、調理メニューに対応するレシピ情報とを記憶する第１のレシピ管理データベースを含み、
   前記レシピ情報は、
   各調理メニューに対応する食材データ、および、各調理メニューを特定する情報を有し、
   前記第１の端末は、
   前記顧客に関する情報を管理するための第１の顧客管理データベースと、
   前記サーバより送信された複数の調理メニューに関する前記レシピ情報を記憶するための第２のレシピ管理データベースと、
   前記顧客ごとに、前記顧客からの注文に基づいた調理メニューを特定する情報を記憶する予約注文管理データベースと、
   前記予約注文管理データベースから前記顧客に関連付けられた調理メニューを特定する情報を選択し、当該選択した調理メニューを特定する情報に基づいて前記調理シーケンスデータを特定する情報であるシーケンス識別データを生成し、当該シーケンス識別データを含む予約シーケンス情報を出力するための出力処理手段と、
   前記顧客からのフィードバック情報を取得し、取得した前記フィードバック情報を前記サーバに送信するための処理を行なう第１の情報処理手段とをさらに含み、
   各前記調理器は、
   ネットワークを介することなく登録される複数の前記調理シーケンスデータを記憶するための第１の記憶手段と、
   前記複数の調理シーケンスデータのうち、前記第１の端末より出力された前記予約シーケンス情報により特定される調理シーケンスデータに従い、前記宅配業者により配送された食材の調理を制御するための調理制御手段とを含み、
   前記サーバは、
   前記第１の端末からの前記フィードバック情報を記憶するための第２の記憶手段と、
   前記第２の記憶手段に記憶されたフィードバック情報に基づいて、前記第１のレシピ管理データベースに記憶された前記食材データを変更する第２の情報処理手段とを含み、
   前記第１の顧客管理データベースは、前記顧客ごとに、複数のカロリー制限レベルのうちの１つを記憶し、
   前記レシピ情報は、前記調理メニューごとに、前記カロリー制限レベルに応じた複数の前記シーケンス識別データを有し、
   前記出力処理手段は、前記顧客ごとに、対応する前記カロリー制限レベルに応じて前記シーケンス識別データを選択し、選択された前記シーケンス識別データを含む前記予約シーケンス情報を生成し、
   前記サーバは、前記第１の端末により送信された前記顧客に関する情報を記憶する第２の顧客管理データベースを含み、
   前記レシピ情報は、各前記調理メニューと前記カロリー制限レベルとの組み合わせに対応付けられた、前記食材データおよび前記調理シーケンスデータを有し、
   前記複数の調理器は、過熱水蒸気によって加熱調理する調理器であり、
   前記レシピ情報は、前記顧客に関する情報と前記フィードバック情報に基づき調整される、定期ケータリングシステム。
2. 前記サーバは、前記フィードバック情報に基づいて、前記カロリー制限レベルごとに人気メニューのランキング情報を生成し、生成した前記ランキング情報を前記第１の端末に送信するための第２の情報処理手段をさらに含み、
   前記第１の端末は、前記サーバより送信された前記ランキング情報を反映させて、前記調理メニューに関する情報を提供するためのメニュー提供手段をさらに含む、請求項１に記載の定期ケータリングシステム。
3. 前記メニュー提供手段は、前記ランキング情報に基づいて、ランキングの順になるように前記調理メニューを並び替えて前記調理メニューに関する情報を提供する、請求項２に記載の定期ケータリングシステム。
4. 前記第１の顧客管理データベースは、前記顧客ごとに、調味料レベルをさらに記憶し、
   前記第１の情報処理手段は、さらに、前記フィードバック情報に基づいて、前記調味料レベルを調整する、請求項３に記載の定期ケータリングシステム。
5. 前記第１の端末とインターネットを介して接続され、各前記顧客により保有される第２の端末をさらに備え、
   前記出力処理手段は、前記第２の端末に、前記予約シーケンス情報を送信する、請求項１〜請求項４のいずれかに記載の定期ケータリングシステム。
6. 前記第２の端末は、前記第１の端末より送信された前記予約シーケンス情報を前記調理器に転送するための処理を行なう転送処理手段を含み、
   前記第１の記憶手段は、前記第２の端末より転送された前記予約シーケンス情報をさらに記憶する、請求項５に記載の定期ケータリングシステム。
7. 前記第１の顧客管理データベースは、前記顧客ごとに、前記調理器のリース開始日時および契約期間を含む契約状況データをさらに記憶し、
   前記第１の端末は、前記契約状況データに基づいて、所定期間ごとに解約金を算出し、算出した前記解約金を前記顧客に報知するための処理を行なう報知処理手段をさらに含む、請求項１〜請求項６のいずれかに記載の定期ケータリングシステム。
8. 前記報知処理手段は、前記解約金とともに、前記解約金の低減率をさらに報知する、請求項７に記載の定期ケータリングシステム。
9. 前記第１の端末は、食材を届ける前記顧客を識別するための顧客識別情報と、当該食材に対応する調理メニューを識別するためメニュー識別情報とに基づいて、認証情報を生成し、前記認証情報を、食材の配送に用いられる専用容器に添付するための書類データに付加するための配送処理手段をさらに含む、請求項１〜請求項８のいずれかに記載の定期ケータリングシステム。
10. 前記認証情報は、前記顧客識別情報および前記メニュー識別情報に所定のアルゴリズムを適用することにより計算される数値である、請求項９に記載の定期ケータリングシステム。

Images