(57)【要約】【課題】受け付けた商品の注文を集計した集計結果を常に最新の状態に保つことができるとともに、配達中に発生したトラブルに対応するのに要する時間を配達予想時刻に反映させる商品注文システムを提供すること。【解決手段】注文された商品の配達状況を判断し、その判断結果を注文の集計結果に反映させて注文者に報知するので、集計結果を常に最新の状態に保つことができるとともに、配達中にトラブルが発生した場合でも、そのトラブルに対応するのに要する時間を配達予想時間に反映させることができ、配達予定時間が過ぎても商品が配達されないことに起因するストレスの発生を防ぐことができる。【選択図】図２６
2006285641.tif 000002
【特許請求の範囲】
【請求項１】
利用者からの商品の注文を示す注文情報を、入力手段を介して受け付け可能な受付手段と、
前記受付手段が受け付けた前記注文情報を運営者に報知する運営者側報知手段と、
前記受付手段が受け付けた前記注文情報を参照して、前記注文情報が示す商品が運営者によって用意されたか否かを判断する用意完了判断手段と、
前記受付手段が受け付けた前記注文情報を集計する集計手段と、
前記集計手段による集計結果から、前記注文された商品の配達予想時刻を算出する配達予想時刻算出手段と、
前記配達予想時刻算出手段によって算出された前記配達予想時刻を利用者に報知する利用者側報知手段と、
前記注文された商品が配達されたことをＲＦタグによって検知可能であり、前記注文された商品が配達されたことを検知したときにはその旨を示す配達完了情報を送出する配達完了検知手段と、
前記用意完了判断手段によって前記注文情報が示す商品が用意されたと判断された場合には、前記配達完了検知手段によって送出された配達完了情報に基づき、前記注文された商品が配達されたか否かを判断する配達完了判断手段と、
を備え、
前記集計手段は、前記配達完了判断手段による判断結果を前記集計結果に反映させることを特徴とする商品注文システム。
【請求項２】
請求項１に記載の商品注文システムにおいて、
前記判断手段は、前記準備完了判断手段によって前記注文された商品が準備されたと判断されてから所定時間が経過しても前記配達完了検知手段からの配達完了情報を受け取らない場合にはトラブル発生と判断すること
を特徴とする商品注文システム。
【請求項３】
請求項２に記載の商品注文システムにおいて、
前記受付手段は、前記判断手段によってトラブル発生と判断された場合には、そのトラブルによって配達されなかった商品に関する注文情報を再度受け付けたこととし、
前記運営者側報知手段は、前記受付手段が再度受け付けた前記注文情報を運営者に報知するとともに、その注文を優先的に処理する旨を運営者に報知すること
を特徴とする商品注文システム。
【請求項４】
請求項１〜請求項３の何れかに記載の商品注文システムにおいて、
前記配達予想時刻算出手段は、前記集計手段による集計結果から、前記商品を注文した場合の配達予想時刻を注文可能な商品ごとに算出し、
前記利用者側報知手段は、前記配達予想時刻算出手段によって算出された注文可能な商品ごとの配達予想時刻を報知すること
を特徴とする商品注文システム。
【請求項５】
請求項１〜請求項４の何れかに記載の商品注文システムにおいて、
前記集計手段は、商品ごとに注文回数を集計し、
前記利用者側報知手段は、前記集計手段によって集計された商品ごとの注文回数を報知すること
を特徴とする商品注文システム。
【請求項６】
請求項５に記載の商品注文システムにおいて、
前記集計手段は、集計した商品ごとの注文回数に基づき、注文回数が多い商品を抽出し、
前記利用者側報知手段は、前記集計手段によって抽出された商品を報知すること
を特徴とする商品注文システム。
【請求項７】
請求項１〜請求項６の何れかに記載の商品注文システムにおいて、
利用終了時刻までの残り時間を算出する残時間算出手段を備え、
前記配達予想時刻算出手段は、前記商品を注文した場合の配達予想時刻を注文可能な商品ごとに算出する際には、前記残時間算出手段によって算出された利用終了時刻までの残り時間を参照して利用終了時刻以降に配達可能となる商品を除外すること
を特徴とする商品注文システム。
【請求項８】
請求項１〜請求項７の何れかに記載の商品注文システムにおいて、
楽曲データに基づいてカラオケ演奏を行う複数のカラオケ装置と、
前記カラオケ装置に演奏させるべき演奏楽曲をユーザに選曲させ、前記選曲された演奏楽曲を前記カラオケ装置に通知する選曲通知機能を有するリモコン端末と、
を備え、
前記リモコン端末は、前記入力手段を備えており、
前記複数のカラオケ装置のうちの一つのカラオケ装置と前記リモコン端末とがデータ通信可能である場合には、そのリモコン端末とデータ通信可能なカラオケ装置が設置された位置をリモコン端末が存在する位置と特定する位置特定手段を備えること
を特徴とする商品注文システム。
【請求項９】
請求項８に記載の商品注文システムにおいて、
前記リモコン端末は、前記カラオケ装置のシリアルナンバーを示す情報を取得可能なシリアルナンバー取得手段を備えており、
前記位置特定手段は、前記リモコン端末のシリアルナンバー取得手段が取得したシリアルナンバーを示す情報に基づいてそのシリアルナンバーに関連付けられたカラオケ装置を特定し、その特定したカラオケ装置が設置された位置をリモコン端末が存在する位置と特定すること
を特徴とする商品注文システム。
【請求項１０】
請求項８または請求項９に記載の商品注文システムにおいて、
前記リモコン端末を載置するためのクレードルと、
前記リモコン端末が前記クレードルに載置されているか否かを判断する載置判断手段と、を備え、
前記位置特定手段は、前記載置判断手段によって前記リモコン端末が前記クレードルに載置されていると判断された場合には、そのクレードルが設置された位置を前記リモコン端末が存在する位置と特定すること
を特徴とする商品注文システム。
【請求項１１】
請求項１〜請求項１０の何れかに記載の商品注文システムにおいて、
前記判断手段によって前記注文された商品が配達されたと判断された場合にレシートを発行するレシート発行手段を備えることを特徴とする商品注文システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受け付けた商品の注文を集計した集計結果を常に最新の状態に保つことができるとともに、例えば配達中に発生したトラブルに対応するのに要する時間を配達予想時刻に反映させることができる商品注文システムに関する。
【背景技術】
【０００２】
従来より、カラオケＬＡＮシステムを利用することで、カラオケ選曲と同じ手順で飲食物等の商品を注文できるとともに客室端末へ受付応答を行うクライアントサーバ型カラオケＬＡＮシステムが知られている（例えば、特許文献１参照。）。
【０００３】
このようなクライアントサーバ型カラオケＬＡＮシステムにおいては、次のような作用を奏する。すなわち、カラオケサーバ機が、楽曲番号を受け取るとこれが本来の楽曲番号ではなくて飲食物などの商品注文番号に該当するか否かを判定する。判定の結果、受け取った番号が商品注文番号だった場合、カラオケサーバ機は、該当の商品に関するサービス取り扱い情報を参照して、該当の注文が受付可能か否かの判断を含んだ注文応答メッセージ情報を作成してカラオケＬＡＮシステムの運用者向けに出力するとともに客室端末へ送出する。客室端末は、受け取った注文応答メッセージ情報に従って、該当の商品に関して名称及び注文の受付可否などのメッセージをディスプレイに出力する。
【特許文献１】特開平１０−１６１６７０（第４〜５頁、図４）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、上述のようなクライアントサーバ型カラオケＬＡＮシステムにおいては、例えば注文品が到着しないといったトラブル発生時に、そのことが上述のディスプレイによるメッセージ表示に反映されないため、そのことが起因とするストレスが利用者に発生するという問題があった。
【０００５】
なお、上述のようなカラオケシステムにおいては、カラオケ店舗が通常の飲食店とは異なってカラオケルームが管理者ルームおよび厨房ルームから隔離されているため、次のようなカラオケシステムに特有の課題がある。すなわち、カラオケルームが管理者ルームおよび厨房ルームから隔離されているため、カラオケルームにいる店員と管理者ルームや厨房ルームにいる店員とが互いに声をかけ合うことができず、カラオケルームにて食事などが注文されたことが管理者ルームや厨房ルームでは確認しづらい状況にある。
【０００６】
また、同様な課題は、漫画を読みたい利用者に対して漫画を読む部屋を貸し出して、漫画の貸し本と飲食の提供サービスを行うルーム形式の漫画喫茶店や、飲食の提供サービスを行うホテルなど、にもある。
【０００７】
本発明は、このような不具合に鑑みなされたものであり、その目的とするところは、受け付けた商品の注文を集計した集計結果を常に最新の状態に保つことができるとともに、配達中に発生したトラブルに対応するのに要する時間を配達予想時刻に反映させる商品注文システムを提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するためになされた請求項１に係る商品注文システムは、注文された商品の配達状況を判断し、その判断結果を注文の集計結果に反映させて注文者に報知することを特徴とする。
【０００９】
具体的には、受付手段が、利用者からの商品の注文を示す注文情報を受け付け可能であり、運営者側報知手段が、受付手段が受け付けた注文情報を運営者に報知するとともに、用意完了判断手段が、受付手段が受け付けた注文情報を参照して、注文情報が示す商品が運営者によって用意されたか否かを判断する。また、集計手段が、受付手段が受け付けた注文情報を集計する。そして、配達予想時刻算出手段が、集計手段による集計結果から「注文された商品の配達予想時刻」を算出し、利用者側報知手段が、配達予想時刻算出手段によって算出された配達予想時刻を利用者に報知する。
【００１０】
また、配達完了検知手段が、注文された商品が配達されたことをＲＦタグによって検知可能であり、注文された商品が配達されたことを検知したときにはその旨を示す配達完了情報を送出する。上述の用意完了判断手段によって注文情報が示す商品が用意されたと判断された場合には、配達完了判断手段が、配達完了検知手段によって送出された配達完了情報に基づき、注文された商品が配達されたか否かを判断する。そして、集計手段が、配達完了判断手段による判断結果を集計結果に反映させる。
【００１１】
このような本発明によれば、注文された商品の配達状況を判断し、その判断結果を注文の集計結果に反映させて注文者に報知するので、図２９に例示するような従来構成とは異なり、集計結果を常に最新の状態に保つことができるとともに、配達中にトラブルが発生した場合でも、そのトラブルに対応するのに要する時間を配達予想時間に反映させることができ、配達予定時間が過ぎても商品が配達されないことに起因するストレスの発生を防ぐことができる。
【００１２】
この場合、配達開始から所定時間経過した場合には、例えば配達担当者が商品を破損したことなどのトラブルが発生したと判断することが考えられる。具体的には、請求項２のように、判断手段が、準備完了判断手段によって注文された商品が準備されたと判断されてから所定時間が経過しても配達完了検知手段からの配達完了情報を受け取らない場合にはトラブル発生と判断し、運営者側報知手段が、判断手段によってトラブル発生と判断された場合にはその旨を報知することが考えられる。
【００１３】
このようにすれば、配達担当者からの報告を待たずにトラブル発生と判断できるので、例えば代替品を用意するなどトラブル発生に対して先回りして対応することができ、したがって、そのトラブルに対応するのに要する時間を短縮することができる。
【００１４】
また、上述のようにトラブルが発生した場合には、そのことを運営者に報知してそのトラブルで破損した商品を優先的に用意するよう促すことが考えられる。具体的には、請求項３のように、受付手段が、判断手段によってトラブル発生と判断された場合にはそのトラブルによって配達されなかった商品に関する注文情報を再度受け付けたこととし、運営者側報知手段が、受付手段が再度受け付けた注文情報を運営者に報知するとともに、その注文を優先的に処理する旨を運営者に報知することが考えられる。このようにすれば、そのトラブルで破損した商品の代替品を、後から注文された商品よりも先に用意して配達することができる。
【００１５】
ところで、例えば人気がある商品を注文した場合には、その商品の注文数が多いために配達までの待ち時間が長い場合がある。そこで、仮に注文した場合の配達予想時刻を商品ごとに報知することが考えられる。具体的には、請求項４のように、配達予想時刻算出手段が、集計手段による集計結果から、商品を注文した場合の配達予想時刻を注文可能な商品ごとに算出し、利用者側報知手段が、配達予想時刻算出手段によって算出された「注文可能な商品ごとの配達予想時刻」を報知することが考えられる。このようにすれば、仮に注文した場合の配達予想時刻を商品ごとに報知するので、例えば利用者が待ち時間が長い商品を敬遠するといった具合にその報知内容を注文時の参考にしてもらうことができる。
【００１６】
また、商品の過去の注文回数を商品ごとに集計し、その集計結果を報知することが考えられる。具体的には、請求項５のように、集計手段が商品ごとに注文回数を集計し、利用者側報知手段が、前記集計手段によって集計された商品ごとの注文回数を報知することが考えられる。なおこの場合、人気が高い商品のみを報知してもよい。具体的には、請求項６のように、集計手段が、集計した商品ごとの注文回数に基づき、注文回数が多い商品を抽出し、利用者側報知手段が、集計手段によって抽出された商品を報知することが考えられる。このようにすれば、例えば注文から配達までに要する時間が長いと予想される人気が高い商品を敬遠するといった具合に、その報知内容を注文時に参考してもらうことができる。また、人気が低い商品を注文してもらうよう促すことができ、その分売り上げが増加することが期待できる。
【００１７】
ところで、例えばカラオケルームの利用終了時刻までの残り時間が短い場合には、注文した商品が到着する時刻が、その利用終了時刻以降である可能性がある。そこで、上述のように、注文した場合の配達予想時刻を商品ごとに報知する際には、利用終了時刻以降に配達可能となる商品を除外することが考えられる。具体的には、請求項７のように、利用終了時刻までの残り時間を算出する残時間算出手段を備え、配達予想時刻算出手段が、商品を注文した場合の配達予想時刻を注文可能な商品ごとに算出する際には、残時間算出手段によって算出された利用終了時刻までの残り時間を参照して利用終了時刻以降に配達可能となる商品を除外することが考えられる。このようにすれば、注文可能な商品ごとの配達予想時刻リストから利用終了時刻以降に配達可能となる商品が除外されるので、そのような商品が誤って注文されることを防ぐことができる。
【００１８】
ところで、商品注文システムが、例えばカラオケボックスなどの複数の配達場所を有する店舗に適用された場合には、商品が注文された場所を特定して商品を配達する必要がある。
【００１９】
そこで、例えばカラオケボックスの場合には、カラオケ装置とリモコン端末との通信状態で、商品を配達する場所を特定することが考えられる。具体的には、請求項８のように、商品注文システムが、楽曲データに基づいてカラオケ演奏を行う複数のカラオケ装置と、前記カラオケ装置に演奏させるべき演奏楽曲をユーザに選曲させ、前記選曲された演奏楽曲を前記カラオケ装置に通知する選曲通知機能を有するリモコン端末と、を備えている。このうち、リモコン端末が入力手段を備えている。そして、位置特定手段が、複数のカラオケ装置のうちの一つのカラオケ装置とリモコン端末とがデータ通信可能である場合には、そのリモコン端末とデータ通信可能なカラオケ装置が設置された位置をリモコン端末が存在する位置と特定する。
【００２０】
このようにすれば、商品注文システムが、例えばカラオケボックスなどの複数の配達場所を有する店舗に適用された場合において、カラオケ装置とリモコン端末との通信状態でリモコン端末が存在する場所を特定し、その特定した場所を商品が注文された場所であるとみなして商品を配達することができる。
【００２１】
この場合、商品が注文された場所を特定する手法としては、（イ）カラオケ装置のシリアルナンバーを取得することで商品が注文された場所を特定することが考えられる。具体的には、請求項９のように、リモコン端末が、カラオケ装置のシリアルナンバーを示す情報を取得可能なシリアルナンバー取得手段を備えており、位置特定手段が、リモコン端末のシリアルナンバー取得手段が取得したシリアルナンバーを示す情報に基づいてそのシリアルナンバーに関連付けられたカラオケ装置を特定し、その特定したカラオケ装置が設置された位置をリモコン端末が存在する位置と特定することが考えられる。
【００２２】
ここで、位置特定手段とは、具体的に実施形態中の構成を挙げて説明すると、実施形態のリモコン端末２の制御部５２と、カラオケ装置１の制御部１２と、ＷＥＢサーバ４が動作させることよって、最終的にＷｅｂサーバ４がリモコン端末２の存在するカラオケ−ルームを特定する手段である。以下、実施形態中の構成を挙げてその処理手順を説明する。
【００２３】
なお、上述のカラオケ装置と、カラオケ装置が設置されたカラオケルームとの関係は、図５に例示するように、予めＷＥＢサーバ４のＲＡＭ４ｄに、カラオケ装置１が設置されたカラオケルームの位置とカラオケ装置１のシリアルナンバーとの対応関係を示す表（カラオケ装置位置表）が記憶されているものとする。
【００２４】
また、カラオケ装置１のシリアルナンバーとは具体的にはカラオケ装置１の製造番号や、ＭＡＣアドレス、ＩＰアドレスなど、カラオケ装置１固有の番号である。
リモコン端末２の制御部５２が、赤外線通信部５４を介して赤外線通信で、カラオケ装置１の赤外線通信部２０へ位置特定信号（リモコン端末２の固有の番号、例えばリモコン端末２に内蔵された無線ＬＡＮ通信部６８のＩＰアドレス）を送信する。
【００２５】
一方、カラオケ装置１の制御部１２が、赤外線通信部２０を介して位置特定信号を受信する。また、カラオケ装置１の制御部１２が、位置特定信号からリモコン端末２のＩＰアドレスを抽出する。カラオケ装置の制御部１２が、インターフェイス部１４から、ＬＡＮ１００に接続された無線アクセスポイント５を介して、前記リモコン端末２のＩＰアドレス（リモコン端末２に内蔵された無線ＬＡＮ通信部６８のＩＰアドレスのこと）、つまりリモコン端末２の無線ＬＡＮ通信部６８へ、カラオケ装置１のシリアルナンバーを送信する。
【００２６】
また、リモコン端末２の制御部５２が、無線ＬＡＮ通信部５２を介してカラオケ装置１のシリアルナンバーを取得する。
そして、リモコン端末２の制御部５２が、無線ＬＡＮ通信部５２を介してカラオケ装置１のシリアルナンバーをＷｅｂサーバ４に送信する。
【００２７】
また、ＷＥＢサーバ４が、カラオケ装置１の位置表から、カラオケ装置１が設置されたカラオケルームの位置とカラオケ装置１のシリアルナンバーとの対応関係を知り、リモコン端末２が存在するのは、カラオケ装置１と位置特定信号の通信を行ったカラオケ装置１が設置されたカラオケルームであると特定する。このことは次のような理由による。すなわち、位置特定信号の送信に、無線ＬＡＮを使用せず、赤外線を使用するのは、赤外線は壁によって遮断されるので、隣の部屋のカラオケ装置と通信して、位置を隣の部屋と間違えて特定することを防ぐためである。
【００２８】
このようにすれば、複数のカラオケボックス（カラオケルーム）が密集した状態で、リモコン端末２の位置はカラオケ装置１が設置されたカラオケルームであると特定することができる。
【００２９】
また、上述のような商品が注文された場所を特定する手法としては、（ロ）クレードルとリモコン端末との接続状態で、商品が注文された場所を特定することが考えられる。具体的には、請求項１１のように、リモコン端末を載置するためのクレードルと、リモコン端末がクレードルに載置されているか否かを判断する載置判断手段と、を備え、位置特定手段が、載置判断手段によってリモコン端末がクレードルに載置されていると判断された場合には、そのクレードルが設置された位置をリモコン端末が存在する位置と特定することが考えられる。
【００３０】
ここで、載置判断手段とは、具体的に実施形態中の構成を挙げて説明すると、リモコン端末２の制御部５２が、ＵＳＢ通信部７０とクレードル７６に内蔵されたＵＳＢ／ＬＡＮ変換部７８との間でＵＳＢ通信が行えたかどうかを検出することによって、位置特定手段に対して、赤外線通信ではなく、クレードル７６のＩＰアドレスを利用してカラオケ端末２が存在するカラオケルームを特定させる手段である。以下、実施形態中の構成を挙げてその処理手順を説明する。
【００３１】
なお、クレードル７６に内蔵されたＵＳＢ／ＬＡＮ変換部７８にはＬＡＮ１００に対して予めＩＰアドレスが付与されている。
また、クレードル７６と、クレードル７６が設置されたカラオケルームの関係は、予めＷＥＢサーバ４のＲＡＭ４ｄに、クレードル７６が設置されたカラオケルームの位置とクレードル７６に内蔵されたＵＳＢ／ＬＡＮ変換部のＩＰアドレスとの対応関係を示す表（クレードル位置表）として、記憶されているものとする。
【００３２】
まず、リモコン端末２の制御部５２が、ＵＳＢ通信部７０とクレードル７６のＵＳＢ／ＬＡＮ変換部７８との間でＵＳＢ通信が行えたかどうかを検出する。ＵＳＢ通信が行えた事を検出した以降は、Ｗｅｂサーバ４の位置検出手段が、赤外線通信でなく、以下の手順でリモコン端末２の位置を検出する。
【００３３】
すなわち、ＵＳＢ通信が行えた事を検出した以降は、リモコン端末２の制御部５２が、ＵＳＢ／ＬＡＮ変換部７６のＩＰアドレスを取得する。
また、制御部１２が、ＷＥＢサーバ４にクレードル７６（ＵＳＢ／ＬＡＮ変換部７８のＩＰアドレス）のＩＰアドレスを通知する。
【００３４】
また、Ｗｅｂサーバ４が、クレードル位置表から、クレードル７６が設置されたカラオケルームの位置とクレードル７６のＩＰアドレスとの対応関係を知り、リモコン端末２が存在するのは、クレードル７６とＵＳＢ通信を行ったクレードル７６が設置されたカラオケルームであると特定する。
【００３５】
このようにすれば、複数のカラオケボックス（カラオケ装置の部屋）が密集した状態で、赤外線通信を使用しなくてもリモコン端末が存在するカラオケルームを特定することができるので、より短い時間でリモコン端末がクレードルに載置されているカラオケルームを特定できる効果がある。
【００３６】
ところで、従来構成ではトラブルが発生して配達がされていない場合でもレシートが発行されるため、注文品が配達されたと勘違いするおそれがある。そこで、注文された商品が配達されたと判断された場合にレシートを発行することが考えられる。具体的には、請求項１０のように、判断手段によって注文された商品が配達されたと判断された場合にレシートを発行するレシート発行手段を備えることが考えられる。
【００３７】
このように配達が確認された場合にレシートを発行することにより、上述のようにトラブルが発生して配達がされていない場合にレシートが発行されて注文品が配達されたと利用者に勘違いされるおそれがない。
【発明を実施するための最良の形態】
【００３８】
以下に本発明の実施形態を図面とともに説明する。
［実施形態］
図１は商品注文システム１００の全体構成を示すブロック図である。また、図２は、カラオケシステム１１０の全体構成を示すブロック図である。また、図５はＷＥＢサーバ４の全体構成を示すブロック図である。また、図９（ａ）は、質問器Ａ〜Ｄ、ＲＦタグおよびＲＦタグ制御部の構成を示す説明図であり、図９（ｂ）は皿および皿に取り付けられたＲＦタグを示す説明図（１）であり、図９（ｃ）は皿および皿に取り付けられたＲＦタグの別実施形態を示す説明図（２）である。また、図１０（ａ）はＲＦタグ制御部３、テーブルシート７およびＲＦタグの各構成を示す説明図（１）であり、図１０（ｂ）はＲＦタグ制御部３、テーブルシート７およびＲＦタグの各構成を示す説明図（２）である。また、図１１（ａ）はテーブルシート７の構成を示す説明図である。また、図２１は、厨房端末６の全体構成を示すブロック図である。
【００３９】
［商品注文システム１００の構成の説明］
商品注文システム１００は、図１に示すように、楽曲データに基づいてカラオケ演奏を行うカラオケ装置１、カラオケ装置１に演奏させるべき演奏楽曲をユーザに選曲させ、選曲された演奏楽曲をカラオケ装置１に通知する選曲通知機能を有するリモコン端末２、ＲＦタグ制御部３、ＷＥＢサーバ４、無線ＬＡＮアクセスポイント５および厨房端末６が互いにデータ通信可能に構成されたものである。
【００４０】
また、商品注文システム１００は、カラオケボックスに設置されている。すなわち、カラオケボックスは、カラオケルーム（ルームＩＤ：Ｒ１〜Ｒ３）、管理者ルームおよび厨房ルームを備えており、各カラオケルームにはカラオケ装置１、リモコン端末２、ＲＦタグ制御部３およびテーブルシート７が設置され、管理者ルームにはＷＥＢサーバ４および無線ＬＡＮアクセスポイント５が設置され、厨房ルームには厨房端末６が設置されている。
【００４１】
［カラオケシステム１１０の構成の説明］
また、カラオケシステム１１０は、図２に示すように、カラオケ装置１とリモコン端末２とから構成され、これらカラオケ装置１とリモコン端末２とがデータ通信可能に構成されたものである。
【００４２】
［カラオケ装置１の構成の説明］
カラオケ装置１は、図２に示すように、カラオケ装置１全体の動作を制御する制御部１２、カラオケ装置１をネットワーク１００に接続するためのインターフェイス部１４、演奏楽曲の伴奏内容および歌詞を示す楽曲データや映像データなどを記憶するハードディスク（ＨＤＤ）１６、複数のキー・スイッチからなる操作部１８、リモコン端末２や携帯電話からの赤外線信号を赤外線通信規格（ＩｒＤＡ（登録商標、以下同様））に従って受信するための赤外線通信部２０、操作部１８からの信号を処理する操作処理部２２、ハードディスク１６に記憶された楽曲データから演奏楽曲のオーディオ信号（音響，音声に関する信号）を生成し、生成されたオーディオ信号およびマイクロフォン２６から入力されたオーディオ信号を増幅してスピーカ２８へ出力する音声制御部２４、ＭＩＤＩ音源３０、映像情報を一時的に記憶するビデオＲＡＭ３２、映像データに基づく映像の再生を制御する映像再生部３４、ビデオＲＡＭ３２に記憶された映像情報および映像再生部３４により再生される映像の表示部３６での表示を制御する映像制御部３８などを備えている。また、制御部１２と音声制御部とはＵＳＢ４０によって接続されている。また、制御部１２は、各種処理を実行する。
【００４３】
［リモコン端末２の構成の説明］
リモコン端末２は、図２に示すように、リモコン端末２全体の動作を制御する制御部５２、カラオケ装置１に赤外線信号を赤外線通信規格（ＩｒＤＡ）に従って送信する赤外線通信部５４、各種情報を記憶するメモリ５６、表示部５８の表示領域に沿って設置されるタッチパネルおよび複数のキー・スイッチからなる操作部６０、操作部６０からの信号を処理する操作処理部６２、映像情報を一時的に記憶するビデオＲＡＭ６４、ビデオＲＡＭ６４に記憶された映像情報の表示部５８での表示を制御する映像制御部６６、ネットワーク１００に接続された無線ＬＡＮアクセスポイント５との間で無線ＬＡＮ規格（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ規格，ＨｏｍｅＲＦ規格，Ｂｌｕｅｔｏｏｔｈ規格など）に従った無線通信を行うための無線ＬＡＮ通信部６８、ＵＳＢ制御部７０などを備えている。
【００４４】
このうち無線ＬＡＮ通信部６８は、カラオケ装置１から無線ＬＡＮアクセスポイント５を介して送信された各種データを受信可能である。
また、制御部５２は、無線ＬＡＮ通信部６８によって受信された歌詞データで示される歌詞を表示部５８に表示させる機能を有する。また、制御部５２は、無線ＬＡＮ通信部６８によりカラオケ装置１とデータ通信可能である場合には、そのカラオケ装置１からシリアルナンバーを示す情報を取得することにより、カラオケ装置１が設置された位置を当該リモコン端末２が存在する位置と特定する機能を有する。また、制御部５２は、ＷＥＢサーバ４によって算出された配達予想時刻を表示部５８に表示させることによって利用者に報知する機能を有する。
【００４５】
なお、リモコン端末２は入力手段に該当する。また、制御部５２および表示部５８は利用者側報知手段に該当する
［ＷＥＢサーバ４の構成の説明］
ＷＥＢサーバ４は、図５に示すように、ＬＡＮインターフェイス４ｂ、ＲＯＭ４ｃ、ＲＡＭ４ｄ、ＣＰＵ４ｅ、制御インターフェイス４ｆ、を備えている。なお、これらＬＡＮインターフェイス４ｂ、ＲＯＭ４ｃ、ＲＡＭ４ｄ、ＣＰＵ４ｅおよび制御インターフェイス４ｆについては、バス４ａによって互いに接続されている。また、ＬＡＮインターフェイス４ｂはバスを介してＬＡＮに接続されている。
【００４６】
ＲＡＭ４ｄには、図２７（ａ）に例示するように、メニューＩＤ、メニュー名、価格、調理時間、およびオーダー種別を関連付けた対応表（メニューテーブル）が記憶されている。また、ＲＡＭ４ｄには、図２７（ｂ）に例示するように、メニューＩＤ、ルームＩＤ、個数、および配達予定時刻を示す情報を関連付けた対応表（メニュー注文情報）が記憶されている。また、ＲＡＭ４ｄには、図２７（ｃ）に例示するように、メニューＩＤ、メニュー名、価格、調理時間、および（調理）予想完了時間を関連付けた対応表（メニュー情報）が記憶されている。
【００４７】
また、ＲＡＭ４ｄには、図２８（ａ）に例示するように、認証個人ＩＤ、課金額、およびルームＩＤを関連付けた対応表（ルーム情報テーブル）が記憶されている。また、ＲＡＭ４ｄには、図２８（ｂ）に例示するように、オーダー情報、およびＷＥＢサーバ４に送信されるオーダー情報を関連付けた対応表（オーダー情報テーブル）が記憶されている。
また、ＲＡＭ４ｄには、図２８（ｃ）に例示するように、各ルームからの注文、およびステータスを関連付けた対応表（厨房依頼情報テーブル）が記憶されている。
【００４８】
また、ＣＰＵ４ｅは、利用者からの商品の注文を示す注文情報を、リモコン端末２を介して受け付け、その受け付けた注文情報を厨房端末６に転送する機能を有する。
また、ＣＰＵ４ｅは、受け付けた注文情報を集計する機能を有する。また、ＣＰＵ４ｅは、注文情報を集計した集計結果から、「注文された商品の配達予想時刻」を算出する機能を有する。また、ＣＰＵ４ｅは、ＲＦタグ制御部３から受信した配達完了情報に基づき、先に集計した集計結果に反映させる機能を有する。
【００４９】
なお、ＣＰＵ４ｅは、集計手段、配達予想時刻算出手段および残時間算出手段に該当する。また、ＣＰＵ４ｅは、ＬＡＮインターフェイス４ｂとともに受付手段に該当する。
［ＲＦタグ制御部３、テーブルシート７、およびＲＦタグ８の構成の説明］
ＲＦタグ制御部３は、図９（ａ）に示すように、ＬＡＮインターフェイス３ｂ、ＲＯＭ３ｃ、ＲＡＭ３ｄ、ＣＰＵ３ｅ、制御インターフェイス３ｆ、を備えている。なお、これらＬＡＮインターフェイス３ｂ、ＲＯＭ３ｃ、ＲＡＭ３ｄ、ＣＰＵ３ｅおよび制御インターフェイス３ｆについては、バス３ａによって互いに接続されている。また、ＬＡＮインターフェイス３ｂはバスを介してＬＡＮに接続されている。
【００５０】
ＲＡＭ３ｄは、図２０（ａ）に例示するように、メニューＩＤ、ＲＦタグＩＤおよび部屋ＩＤなどを関連付けた対応表を記憶している。また、ＲＡＭ３ｄは、図２０（ｂ）に例示するように、メニューＩＤとＲＦタグＩＤとを関連付けた対応表を記憶している。
【００５１】
ＣＰＵ３ｅは、質問器Ａ〜Ｄによって送出された配達完了情報（ＲＦタグＩＤ）に基づき、注文された商品が配達されたか否かを判断する機能を有する。なお、ＣＰＵ３ｅは配達完了判断手段に該当する。
【００５２】
また、ＲＦタグ制御部３の制御インターフェイス３ｆには、質問器Ａ〜Ｄが接続されている。各質問器は、制御インターフェイス、送信機（以下「ＴＸ」）、受信機（以下「ＲＸ」）、およびアンテナを備えており、テーブル７ａの上に設置されたテーブルシート７の内部に設置されている（図１参照）。なお、本実施形態では、４つの質問器Ａ〜Ｄが、テーブルシート７の内部に設置されている。具体的には、これら４つの質問器Ａ〜Ｄは、テーブルシート７の内部にてシート状の２層の絶縁体の間に配置されている（図１１（ａ）参照）。また、各質問器のアンテナについては、ループ状に形成されて質問器の筐体の外部に配置されている（図１１（ｂ）参照）。
【００５３】
また、各質問器は、注文された商品が配達されたことをＲＦタグによって検知可能であり、注文された商品が配達されたことを検知したときにはその旨を示す配達完了情報を送出する機能を有する（図１０（ａ）および（ｂ）参照）。具体的には、各質問器は、ＲＦタグのＩＤを送信するよう要求する旨の質問信号をアンテナから送信する機能、および例えば料理が盛られた皿がテーブルシート７に載せられた場合にその皿に取り付けられたＲＦタグから送信されたＩＤを、アンテナを介して取得し、その取得したＩＤを、制御インターフェイスを介してＲＦタグ制御部３へ送信する機能を有している（図１０（ｂ）参照）。なお、質問器Ａ〜Ｄは配達完了検知手段に該当する。
【００５４】
また、ＲＦタグ８は、ＩＤ記憶部、ＴＸ、ダイオード、電源およびアンテナを備えており、料理を盛るための皿の裏側に設置されている（図９（ｂ）参照）。なお、アンテナについては、ＲＦタグ８の内部に内蔵されている。また、ＲＦタグ８は、各質問器から送信された質問信号に応答して、各タグに割り当てられたＩＤをＩＤ記憶部から読み出してアンテナを介して送信する機能を有する。
【００５５】
［厨房端末６の構成の説明］
厨房端末６は、図２１に示すように、ＬＡＮインターフェイス３ｂ、ＲＯＭ６ｃ、ＲＡＭ６ｄ、ＣＰＵ６ｅ、入力インターフェイス６ｆ、ＶＩＤＥＯインターフェイス６ｇ、を備えている。なお、これらＬＡＮインターフェイス６ｂ、ＲＯＭ６ｃ、ＲＡＭ６ｄ、ＣＰＵ６ｅ、入力インターフェイス６ｆおよびＶＩＤＥＯインターフェイス６ｇについては、バス６ａによって互いに接続されている。また、ＬＡＮインターフェイス６ｂはバスを介してＬＡＮに接続されている。また、入力インターフェイス６ｆには、キーボード６ｈが接続されている。また、ＶＩＤＥＯインターフェイス６ｇにはテレビジョン（ＴＶ）６ｉが接続されている。なお、ＣＰＵ６ｅには、ＣＰＵ６ｅが動作するための各種プログラムを記憶するＲＯＭと、ＣＰＵ６ｅがデータなどを一時的に記憶するためのＲＡＭとが内蔵されている。
【００５６】
ＲＡＭ６ｄの「Ｃ１」領域には、図２３（ａ）に例示するように、注文された部屋の番号、注文を受け付けた受付時間、およびその注文の注文内容を関連付けた対応表が記憶されている。また、ＲＯＭ６ｄの「Ｃ１」領域には、図２３（ｂ）に例示するように、注文された注文品の番号、およびその注文品を調理するのに使用する調理機器の番号を関連付けた対応表が記憶されている。
【００５７】
また、ＲＡＭ６ｄには、図２３（ｃ）に例示するように、注文された注文品のＩＤおよびその注文品の名称（調理品名）を関連付けた対応表が記憶されている。
また、ＲＡＭ６ｄの「Ｃ１」から「Ｃ５」の各領域には、図２４（ａ）〜（ｄ）に例示するように、注文された注文品を、調理端末ごとに注文順序および調理順序に並べた一覧表が記憶されている。
【００５８】
また、ＣＰＵ６ｅは、ＷＥＢサーバ４から転送された注文情報をテレビジョン６ｉに表示させて運営者に報知する機能を有する。また、ＣＰＵ６ｅは、ＷＥＢサーバ４から転送された注文情報を参照して、注文情報が示す商品が運営者によって用意されたか否かを判断する機能を有する。
【００５９】
なお、ＣＰＵ６ｅは、用意完了判断手段に該当する。また、ＣＰＵ６ｅは、テレビジョン６ｉとともに運営者側報知手段に該当する。
［リモコン端末の注文発信処理の説明］
以下に、リモコン端末２の制御部５２により実行される注文発信処理の処理手順を図３のフローチャート、図１５および図１６に基づいて説明する。なお、図１５は従来のカラオケボックスにおける、注文・調理・搬送・受取を示すタイムチャートであり、図１６は本実施形態のカラオケボックスにおける、注文・調理・搬送・受取を示すタイムチャートである。
【００６０】
この注文発信処理は、リモコン端末２が起動している間に繰り返し実行される。
まず、操作部６０を介する利用者からの指示によってオーダーエントリーとなるまで待機し（Ｓ２１０：ＮＯ））、オーダーエントリーとなった場合には（Ｓ２１０：ＹＥＳ）、ＷＥＢサーバ４からメニュー情報（図２７（ｂ）参照）を取得し、仮注文情報があれば待ち時間を加算する（Ｓ２２０）。さらに、先に取得したメニュー情報および先に計算した待ち時間を表示部５８に表示させる（Ｓ２３０）。
【００６１】
続いて、操作部６０における個人認証タブが押されたか否かを判断する（Ｓ２４０）。個人認証タブが押されたと判断した場合には（Ｓ２４０：ＹＥＳ）、個人ＩＤをメモリ５６に記憶しておき（Ｓ２５０）、予めＷＥＢサーバ４から取得して表示部５８に表示しておいたメニューテーブル（図２７（ａ）参照）から注文品が選択されるまで待機する（Ｓ２６０：ＮＯ）。なお、個人認証タブが押されていないと判断した場合にも（Ｓ２４０：ＮＯ）、同様に上述のメニューテーブルから注文品が選択されるまで待機する（Ｓ２６０：ＮＯ）。メニューテーブルから注文品が選択された場合には（Ｓ２６０：ＹＥＳ）、メニューテーブルに対応したメニューＩＤをメモリ５６に記憶させる。なお、メモリ５６に個人ＩＤが記憶されている場合には、その個人ＩＤをメニューＩＤと共に仮注文としてメモリ５６に記憶させる。
【００６２】
続いて、操作部６０における注文キーが押されていない場合には（Ｓ２８０：ＮＯ）、Ｓ２１０に戻ってＳ２１０以下の処理を繰り返す。一方、注文キーが押された場合には（Ｓ２８０：ＹＥＳ）、注文が確定したと判断し、部屋ＩＤ、記憶した全てのメニューＩＤおよび個人ＩＤをＷＥＢサーバ４に送信する（図２８（ｂ）参照）。そして、本処理を終了する。
【００６３】
［リモコン端末の注文確認処理の説明］
以下に、リモコン端末２の制御部５２により実行される注文確認処理の処理手順を図４のフローチャート、図１５および図１６に基づいて説明する。この注文確認処理は、リモコン端末２が起動している間に繰り返し実行される。
【００６４】
まず、操作部６０を介する利用者からの指示によって「注文確認」となるまで待機し（Ｓ３１０：ＮＯ）、注文確認となった場合には（Ｓ３１０：ＹＥＳ）、ＷＥＢサーバ４からメニュー注文情報（図２７（ｂ）参照）を取得し（Ｓ３２０）、その取得したメニュー注文情報および先に取得したメニューテーブルを参照して注文メニューと待ち時間とを表示部５６に表示させる（Ｓ３３０）。
【００６５】
続いて、操作部６０を介する利用者からの指示によって「注文確認」を終了する指示がなされたか否かを判断し、注文確認を終了しない場合には（Ｓ３４０：ＮＯ）、Ｓ３２０に戻りＳ３２０以下の処理を繰り返し実行することで上述の注文確認を続行する。一方、注文確認を終了する場合には（Ｓ３４０：ＹＥＳ）、本処理を終了する。
【００６６】
［ＷＥＢサーバの注文受付処理の説明］
以下に、ＷＥＢサーバ４のＣＰＵ４ｅにより実行される注文受付処理の処理手順を図６のフローチャート、図１５および図１６に基づいて説明する。この注文受付処理は、ＷＥＢサーバ４が起動している間に繰り返し実行される。
【００６７】
まず、リモコン端末２から送信された情報がオーダー情報（図２８（ｂ）参照）であるか否かを判断し、リモコン端末２から送信された情報がオーダー情報でない場合およびリモコン端末２から情報が送信されてはいない場合には（Ｓ４１０：ＮＯ）、リモコン端末２からオーダー情報が送信されるまで待機する。リモコン端末２から送信された情報がオーダー情報である場合には（Ｓ４１０：ＹＥＳ）、そのオーダー情報に含まれる情報のうちオーダーメニューＩＤおよび数量を示す情報（厨房依頼情報、図２８（ｃ）参照）を厨房端末６に送信する（Ｓ４２０）。
【００６８】
そして、メニューテーブル（図２７（ａ）参照）を参照して、オーダーメニューＩＤに対応する価格情報を取得し、部屋もしくは個人ＩＤの請求額に加算する（Ｓ４３０、ルーム情報テーブル（図２８（ａ）参照）。そして、本処理を終了する。
【００６９】
［ＷＥＢサーバの注文状況発信処理の説明］
以下に、ＷＥＢサーバ４のＣＰＵ４ｅにより実行される注文状況発信処理の処理手順を図７のフローチャート、図１５および図１６に基づいて説明する。この注文状況発信処理は、ＷＥＢサーバ４が起動している間に繰り返し実行される。
【００７０】
まず、厨房端末６から調理完了を示す情報を受信したか否かを確認し、調理完了を示す情報を受信していたならばステータスを配送中に変更する（Ｓ５１０、図２４参照）。続いて、ＲＦタグ制御部３から配達完了を示す情報を受信したかを確認し、配達完了を示す情報を受信していたならば、その配達完了情報のメニューＩＤとルームＩＤからステータスを配達完了に変更する（Ｓ５２０、図２７（ｂ）参照）。さらに、配送予定時間（ｔｐｃ）を過ぎたら、ステータスをトラブルとし、厨房端末６に対して緊急再注文を行う（Ｓ５３０、図２４参照）。続いて、メニュー注文情報（図２７（ｂ）参照）の予想完了時間を更新する（Ｓ５４０）。
【００７１】
続いて、リモコン端末２から送信された情報が注文状況確認であるか否かを判断する。リモコン端末２から送信された情報が注文状況確認ではない場合には（Ｓ５５０：ＮＯ）、Ｓ５１０に戻って以下の処理を再び実行する。一方、リモコン端末２から送信された情報が注文状況確認である場合には(Ｓ５５０：ＹＥＳ)、注文状況をリモコン端末２に対して送信する（Ｓ５６０、図２７（ｂ）参照）。そして、本処理を終了する。
【００７２】
［ＷＥＢサーバのメニュー取得処理の説明］
以下に、ＷＥＢサーバ４のＣＰＵ４ｅにより実行されるメニュー取得処理の処理手順を図８のフローチャート、図１５および図１６に基づいて説明する。このメニュー取得処理は、ＷＥＢサーバ４が起動している間に繰り返し実行される。
【００７３】
まず、リモコン端末２から送信された情報がメニュー取得であるか否かを判断し（Ｓ６１０）、リモコン端末２から送信された情報がメニュー取得ではない場合には（Ｓ６１０：ＮＯ）、リモコン端末２からメニュー取得を示す情報が送信されるまで待機する。リモコン端末２から送信された情報がメニュー取得である場合には（Ｓ６１０：ＹＥＳ）、メニュー情報（図２７（ｃ）参照）をリモコン端末２に送信するとともに、厨房端末６のスタックメニューの調理時間と表示メニューの調理時間とを加算した値をリモコン端末２へ送信する（Ｓ６２０）。そして、本処理を終了する。
【００７４】
［ＲＦタグ制御部のメイン処理の説明］
以下に、ＲＦタグ制御部３のＣＰＵ３ｅにより実行されるメイン処理の処理手順を図１７のフローチャートに基づいて説明する。このメイン処理は、ＲＦタグ制御部３が起動している間に繰り返し実行される。
【００７５】
まず、Ａサイクル（後述）を実行する（Ｓ７１０）。続いて、Ｂサイクル（後述）を実行し（Ｓ７２０）、Ｃサイクル（後述）を実行し（Ｓ７３０）、Ｄサイクル（後述）を実行する（７４０）。
【００７６】
続いて、ＲＡＭ３ｄが記憶するテーブル（図２０（ａ）参照）を参照し、項目「Ａ」〜項目「Ｄ」における行方向の論理和を項目「ＯＲ」に書き込み（Ｓ７５０）、項目「ＯＲ」に対応するメニューＩＤとルームＩＤとを読み出してＷＥＢサーバ４に送信する（Ｓ７６０）。そして、本処理を終了する。
【００７７】
なお、ここで言う「論理和を項目「ＯＲ」に書き込む（Ｓ７５０）」、というのはＲＦタグのＩＤをビット単位で論理和をとることではなく、図３のレジスタ群Ａ〜Ｄにそれぞれに記憶しているＲＦタグのＩＤを、ＡからＤまでお互いを比較して、同じ番号のＲＦタグのＩＤが重複していた場合に、１つのＲＦタグのＩＤとして扱うことを意味する。
【００７８】
具体的には、例えば、図３においてＡ〜Ｄサイクルが終了した時点で次の（１）〜（４）のようになる。
（１）質問器Ａのレジスタ群Ａは、ＲＦタグのＩＤとしてＫ１，Ｋ２を記憶している。
【００７９】
（２）質問器Ｂのレジスタ群Ｂは、ＲＦタグのＩＤとしてＫ２を記憶している。
（３）質問器Ｃのレジスタ群Ｃは、ＲＦタグのＩＤとしてＫ２，Ｋ３を記憶している。
（４）質問器Ｄのレジスタ群Ｄは、ＲＦタグのＩＤとしてＫ２，Ｋ３，Ｋ４を記憶している。
【００８０】
そして、項目「Ａ」〜「Ｄ」における行方向の論理和を項目「ＯＲ」に書き込む手順（Ｓ７６０）が実行されると、ＲＦタグ制御部３のＲＡＭ３ｄの項目「ＯＲ」にはＲＦタグのＩＤとしてＫ１，Ｋ２，Ｋ３，Ｋ４が記憶され、ＲＦタグ制御部３は、前記ＩＤの値（Ｋ１，Ｋ２，Ｋ３，Ｋ４）とＲＦタグ制御部が設置されているカラオケルームのＩＤをＷｅｂサーバ４に送信する。
【００８１】
なお、上述のＳ７６０の手順が実行される以前に、ＲＦタグ制御部３のＬＡＮインターフェイス３ｄは固有のＩＰアドレスが予め付与されており、カラオケルームのＩＤとカラオケ装置のシリアルナンバーとの対応関係は予めＷｅｂサーバ４に記憶されているものとする。つまり、Ｗｅｂサーバ４はＲＦタグ制御部３からカラオケルームのＩＤを受信すれば、カラオケ装置１が設置されたカラオケルームに、カラオケ装置１と共に設置された、ＲＦタグ制御部３が接続されたテーブルシート７が置かれたテーブルの位置も特定できる。
【００８２】
また、ＲＦタグ制御部３の位置を特定する別の方法としては、ＲＦタグ制御部３のＩＰアドレスとカラオケルームのＩＤの対応関係を示す表をＷＥＢサーバ４に記憶し、リモコン端末２を特定したのと同様に、ＲＦタグ制御部３のＩＰアドレスからテーブルの位置を特定してもよい。
【００８３】
［ＲＦタグ制御部のＡ（Ｂ〜Ｄ）サイクルに関する処理の説明］
以下に、ＲＦタグ制御部３のＣＰＵ３ｅにより実行されるＡ（Ｂ〜Ｄ）サイクルに関する処理の処理手順を図１８のフローチャートおよび図１２〜図１４に基づいて説明する。なお、図１２は、質問器Ａからの質問信号Ａｑに対するＲＦタグＫ１〜Ｋ４の応答信号ＩＤの応答タイミングを示すタイムチャートであり、図１３は、サイクルＡ〜Ｄにおける質問器Ａ〜ＤおよびＲＦタグＫ１〜Ｋ４の応答具合を示すタイムチャート（１）であり、図１４は、サイクルＡ〜Ｄにおける質問器Ａ〜ＤおよびＲＦタグＫ１〜Ｋ４の応答具合を示すタイムチャート（２）である。
【００８４】
このＡ（Ｂ〜Ｄ）サイクルに関する処理は、ＲＦタグ制御部３のメイン処理において、Ｓ７１０（Ｓ７２０〜Ｓ７４０）に移行した際に実行される。
なお、以下の説明では、Ａサイクルについて説明し、Ｂ〜ＤサイクルについてはＡサイクルと同様であるためその説明は省略する。
【００８５】
まず、ＲＡＭ３ｄが記憶するテーブル（図２０（ａ）参照）を参照し、ＲＡＭ３ｄにおける項目「Ａ（Ｎ）」の値をリセットする（Ｓ８０５）。続いて、項目「Ａ（Ｎ）」の値を数値「１」に設定し（Ｓ８１０）、質問器Ａのアンテナスイッチを「ＴＸ」側に設定し（Ｓ８１５）、その「ＴＸ」から質問信号「Ａｑ」を送信する（Ｓ８２０）。そして、上述のアンテナスイッチを「ＲＸ」側に設定し（Ｓ８２５）、応答時間内にＲＦタグ８からＩＤを受信したか否かを判断する（Ｓ８３０）。応答時間内にＲＦタグ８からＩＤを受信した場合には（Ｓ８３０：ＹＥＳ）、項目「Ａ（Ｎ）」の値にＩＤ値を設定する（Ｓ８３５）。一方、応答時間内にＲＦタグ８からＩＤを受信していない場合には（Ｓ８３０：ＮＯ）、項目「Ａ（Ｎ）」の値に数値「０」を設定する（Ｓ８４０）。
【００８６】
そして、項目「Ａ（Ｎ）」の値に数値「１」を加算し（Ｓ８４５）、その項目「Ａ（Ｎ）」の値が数値「３」よりも大きいか否かを判断する（Ｓ８５０）。その項目「Ａ（Ｎ）」の値が数値「３」以下である場合には（Ｓ８５０：ＮＯ）、Ｓ８３０に戻りＳ８３０以下の処理を再び実行する。一方、その項目「Ａ（Ｎ）」の値が数値「３」よりも大きい場合には（Ｓ８５０：ＹＥＳ）、リターンする。
【００８７】
［ＲＦタグ制御部のＲＦタグに関する処理の説明］
以下に、ＲＦタグ制御部３のＣＰＵにより実行されるＲＦタグに関する処理の処理手順を図１９のフローチャートに基づいて説明する。このＲＦタグＫに関する処理は、ＲＦタグ制御部３が起動している間に繰り返し実行される。
【００８８】
まず、各質問器が質問信号を受信したか否かを判断し（Ｓ９１０）、各質問器から質問信号を受信していない場合には待機する。一方、質問器Ａ〜Ｄの何れかから質問信号を受信した場合には、その質問信号に応答したＲＦタグ８のＩＤに応じて予め設定された「ＴＫ」時間の間待機する（Ｓ９２０）。
【００８９】
続いて、その質問信号に応答したＲＦタグ８のＩＤを各質問器へ送信する（Ｓ９３０）。そして、本処理を終了する。
［厨房端末の調理に関する処理の説明］
以下に、厨房端末６のＣＰＵ６ｅにより実行される調理に関する処理の処理手順を図２２のフローチャートに基づいて説明する。この調理に関する処理は、厨房端末６が起動している間に繰り返し実行される。
【００９０】
まず、ＷＥＢサーバ４からオーダー情報（図２８（ｂ）参照）が到着したか否かを判断し（Ｓ１０１０）、ＷＥＢサーバ４からオーダー情報が到着していない場合には（Ｓ１０１０：ＮＯ）、ＷＥＢサーバ４からオーダー情報が到着するまで待機する。ＷＥＢサーバ４からオーダー情報が到着した場合には（Ｓ１０１０：ＹＥＳ）、次の（１）〜（４）の処理を行う。すなわち、（１）ＲＡＭ６ｄの項目「Ｃ１」にカラオケルームごとのオーダー情報を受付時間と食事の種類ごとに分けて書き込み（Ｓ１０２０、図２３〜図２３（ｃ）参照）、（２）ＲＡＭ６ｄの項目「Ｃ１」とＲＯＭ６ｃの記憶内容とを対応させ、（３）ＲＡＭ６ｄの項目「Ｃ１」の内容をＲＡＭ６ｄの項目「Ｃ２」およびＲＡＭ６ｄの項目「Ｃ４」に分けて書き込み、（４）これらＲＡＭ６ｄの項目「Ｃ２」およびＲＡＭ６ｄの項目「Ｃ４」の記憶内容をテレビジョン６ｉに表示させる（Ｓ１０３０）。
【００９１】
続いて、キーボード６ｈから注文品の調理完了入力があるか否かを判断し（Ｓ１０４０）、キーボード６ｈから注文品の調理完了入力がない場合には（Ｓ１０４０：ＮＯ）、キーボードから注文品の調理完了入力があるまで待機する。キーボード６ｈから注文品の調理完了入力がある場合には（Ｓ１０４０：ＹＥＳ）、ＲＡＭ６ｄの項目「Ｃ２」およびＲＡＭ６ｄの項目「Ｃ４」の内容を、調理完了したものについては書き込み、ＲＡＭ６ｄの項目「Ｃ３」およびＲＡＭ６ｄの項目「Ｃ５」としてテレビジョン６ｉに表示させる（Ｓ１０５０）。
【００９２】
続いて、キーボード６ｈからルームＩＤごとに調理完了が全て入力されたか否かを判断する（Ｓ１０６０）。ルームＩＤごとに調理完了が全て入力されていない場合には（Ｓ１０６０：ＮＯ）、Ｓ１０４０に戻りＳ１０４０以下のステップを再び実行する。一方、ルームＩＤごとに調理完了が全て入力された場合には（Ｓ１０６０：ＹＥＳ）、ＷＥＢサーバ４にルームＩＤごとに注文品の調理完了を通知する（Ｓ１０７０）。そして、ルームＩＤの調理完了としてＲＡＭ６ｄの項目「Ｃ１」〜項目「Ｃ５」の内容をクリアする（Ｓ１０８０）。そして、本処理を終了する。
【００９３】
［効果］
このように実施形態の商品注文システム１００によれば、注文された商品の配達状況を判断し、その判断結果を注文の集計結果に反映させて注文者に報知するので（図２５参照）、図２９に例示するような従来のオーダーエントリーシステムを備えるカラオケシステムとは異なり、集計結果を常に最新の状態に保つことができるとともに、厨房からカラオケルームへの配達中にトラブルが発生した場合でも、そのトラブルに対応するのに要する時間を配達予想時間に反映させることができ、配達予定時間が過ぎても商品が配達されないことに起因する注文客のストレスの発生を防ぐことができる。
【００９４】
また、このように実施形態の商品注文システム１００によれば、ＷＥＢサーバ４のＣＰＵ４ｅが、厨房端末６から注文された商品が準備されて配達が開始されたとの連絡を受けてから所定時間が経過してもＲＦタグ制御部３からの注文品の配達完了情報を受け取らない場合にはトラブル発生と判断する（図２６参照）。このようにすれば、配達担当者からの報告を待たずにトラブル発生と判断できるので、例えば代替品を用意するなどトラブル発生に対して先回りして対応することができ、したがって、そのトラブルに対応するのに要する時間を短縮することができる。
【００９５】
また、このように実施形態の商品注文システム１００によれば、ＷＥＢサーバ４のＣＰＵ４ｅが、トラブル発生と判断された場合にはそのトラブルによって配達されなかった商品に関する注文情報を再度受け付けたこととし、厨房端末６のＣＰＵ６ｅが、ＷＥＢサーバ４が再度受け付けた注文情報をテレビジョン６ｉに表示させることによって運営者に報知するとともに、その注文を優先的に処理する旨をテレビジョン６ｉに表示させることによって運営者に報知する（図２６参照）。このようにすれば、そのトラブルで破損した商品の代替品を、後から注文された商品よりも先に用意して配達することができる。
【００９６】
また、このように実施形態の商品注文システム１００によれば、ＷＥＢサーバ４のＣＰＵ４ｅが、注文の集計結果から、商品を注文した場合の配達予想時刻をリモコン端末２がＷＥＢサーバ４にアクセスしたときに注文可能な商品ごとに算出し、その算出結果である「注文可能な商品ごとの配達予想時刻」をリモコン端末２の表示部５８に表示させることができるようにＷＥＢ画面を変更する（図２５参照）。このようにすれば、仮に注文した場合の配達予想時刻を商品ごとに報知でき、例えば利用者が待ち時間が長い商品を敬遠するといった具合にその報知内容を注文時の参考にしてもらうことができる。
【００９７】
また、このように実施形態の商品注文システム１００によれば、ＷＥＢサーバ４のＣＰＵ４ｅが、商品ごとに注文回数を集計し、リモコン端末２がＷＥＢサーバ４にアクセスしたときに、リモコン端末２の表示部５８が、その集計結果である「商品ごとの注文回数」を報知できるようにＷＥＢ画面を変更する。なおこの場合、人気が高い商品のみを報知してもよい。具体的には、ＷＥＢサーバ４のＣＰＵ４ｅが、集計した商品ごとの注文回数に基づき、注文回数が多い商品を抽出し、リモコン端末２の表示部５８が、その抽出された商品を報知するといった具合である。このようにすれば、例えば注文から配達までに要する時間が長いと予想される人気が高い商品を敬遠するといった具合に、その報知内容を注文時に参考してもらうことができる。また、人気が低い商品を注文してもらうよう促すことができ、その分売り上げが増加することが期待できる。
【００９８】
また、このように実施形態の商品注文システム１００によれば、ＷＥＢサーバ４のＣＰＵ４ｅが、各カラオケルームにおける利用終了時刻までの残り時間を算出し、商品を注文した場合の配達予想時刻を注文可能な商品ごとに算出する際には、先に算出された利用終了時刻までの残り時間を参照して、利用終了時刻以降に配達可能となる商品を除外する。このようにすれば、注文可能な商品ごとの配達予想時刻リストから利用終了時刻以降に配達可能となる商品が除外されるので、そのような商品が誤って注文されることを防ぐことができる。
【００９９】
［他の実施形態］
以上、本発明の一実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、様々な態様にて実施することが可能である。
【０１００】
（１）上記実施形態では、リモコン端末２の表示部５８が、利用者に対して各種情報を表示するよう構成されているが、これには限られず、カラオケ装置１がＷＥＢサーバ４にアクセスして、カラオケ装置１の表示部３６が、上述のような各種情報を表示するように構成してもよい。
【０１０１】
（２）上記実施形態では、ＲＦタグ８のアンテナについてはＲＦタグ８の内部に内蔵されているが（図９（ｂ）参照）、これには限られず、ＲＦタグ８のアンテナをループ状に形成して皿の周囲に配置するようにしてもよい（図９（ｃ）参照）。このようにすれば、アンテナの長さを長く設定することができ、より低い周波数で、またより高感度でＲＦタグを利用することができる。
【０１０２】
（３）上記実施形態では、４つの質問器Ａ〜Ｄが、テーブルシート７の内部にてシート状の２層の絶縁体の間に配置されているが（図１１（ａ）参照）、これには限られず、
各質問器を、シート状の３層の絶縁体の間に分散させて配置してもよい（図１１（ｃ）参照）。このようにすれば、テーブルシート１０７に内蔵させる質問器の数量を増やすことができ、より精度のよいＲＦタグ８の検知が可能となる。なおこの場合、各絶縁体の厚み寸法については、これら絶縁体の自重や皿の重量によってせん断されない程度に設定する必要がある。
【０１０３】
（４）カラオケボックスの場合には、カラオケ装置１とリモコン端末２との通信状態で、商品を配達する場所を特定するようにしてもよい。このようにすれば、商品注文システム１００が、例えばカラオケボックスなどの複数の配達場所を有する店舗に適用された場合において、カラオケ装置１とリモコン端末２との通信状態でリモコン端末２が存在する場所を特定し、その特定した場所を商品が注文された場所であるとみなして商品を配達することができる。
【０１０４】
（５）この場合、商品が注文された場所を特定する手法としては、（イ）カラオケ装置１のシリアルナンバーを取得することで商品が注文された場所を特定することが考えられる。具体的には、リモコン端末２が、カラオケ装置１のシリアルナンバーを示す情報を取得可能であり、ＷＥＢサーバ４のＣＰＵ４ｅが、リモコン端末２が取得したカラオケ装置１のシリアルナンバーを示す情報に基づいてそのシリアルナンバーに関連付けられたカラオケ装置１を特定し、その特定したカラオケ装置１が設置された位置をリモコン端末２が存在する位置と特定するといった具合である。なおこの場合、リモコン端末２はシリアルナンバー取得手段に該当する。
【０１０５】
なお、カラオケボックスの利用形態として、リモコン端末２を予め各カラオケ−ルームに設置するのではなく、図２９に示す管理者ルームにてカラオケ受付時にカラオケ利用者に対してリモコン端末２を借与し、退出時には前記カラオケ端末２を管理者へ返却することがある。
【０１０６】
これはカラオケルーム数よりリモコン端末２の数量が少ない場合には各カラオケルームにリモコン端末２を設置することができない利用形態や、また、リモコン端末２の盗難等を防ぐための利用形態である。
【０１０７】
このような場合においても、予めＷＥＢサーバ４のＲＡＭ４ｄに、カラオケ装置１が設置されたカラオケルームの位置とカラオケ装置１のシリアルナンバーとの対応関係を示す表（カラオケ装置１の位置表）を記憶して、上述のような手法を実施すれば、予めリモコン端末２は使用時に商品を注文した場所を特定できるから、予めリモコン端末２をカラオケルームに設置する必要がなくなるため、カラオケルームの効率利用や、盗難を防ぐセキュリティ向上の効果がある。
【０１０８】
（６）また、上述のような商品が注文された場所を特定する手法としては、（ロ）クレードル７６とリモコン端末２との接続状態で、商品が注文された場所を特定するようにしてもよい。具体的には、ＷＥＢサーバ４のＣＰＵ４ｅが、リモコン端末２がクレードル７６に載置されているか否かを判断し、リモコン端末２がクレードル７６に載置されている場合には、そのクレードル７６が設置された位置をリモコン端末２が存在する位置と特定するといった具合である。なおこの場合、ＷＥＢサーバ４のＣＰＵ４ｅは載置判断手段および位置特定手段に該当する。
【０１０９】
なお、上述のようにカラオケボックスの利用形態として、リモコン端末２を予め各カラオケ−ルームに設置するのではなく、図２９に示す管理者ルームにてカラオケ受付時にカラオケ利用者に対してリモコン端末２を借与し、退出時には前記カラオケ端末２を管理者へ返却することがある。
【０１１０】
これはカラオケルーム数よりリモコン端末２の数量が少ない場合には各カラオケルームにリモコン端末２を設置することができない利用形態や、また、リモコン端末２の盗難等を防ぐための利用形態である。
【０１１１】
このような場合においても、予めＷＥＢサーバ４のＲＡＭ４ｄに、クレードル７６が設置されたカラオケルームの位置とクレードル７６に内蔵されたＵＳＢ／ＬＡＮ変換部７８のＩＰアドレスとの対応関係を示す表（クレードル位置表）として記憶しておき、上述のような手法を用いれば、上述の別実施形態（５）と同様な効果を得ることが出来、更に、赤外線通信をリモコン端末２とカラオケ装置１の間で行わないため、上述の別実施形態（５）より短い時間でリモコン端末２がクレードル７６に載置されているカラオケルームを特定できる効果がある。
【０１１２】
（７）ＰＯＳ端末を備え、注文された商品が配達されたとＷＥＢサーバ４のＣＰＵ４ｅによって判断された場合には、そのＰＯＳ端末が、レシートを発行するようにしてもよい。なお、ＰＯＳ端末はレシート発行手段に該当する。このように配達が確認された場合にレシートを発行することにより、上述のようにトラブルが発生して配達がされていない場合にレシートが発行されて注文品が配達されたと利用者に勘違いされるおそれがない。
【図面の簡単な説明】
【０１１３】
【図１】商品注文システムの全体構成を示すブロック図である。
【図２】カラオケシステムの全体構成を示すブロック図である。
【図３】リモコン端末の制御部が実行するリモコン注文発信処理を示すフローチャートである。
【図４】リモコン端末の制御部が実行するリモコン注文確認処理を示すフローチャートである。
【図５】ＷＥＢサーバの全体構成を示すブロック図である。
【図６】ＷＥＢサーバのＣＰＵが実行する注文受付処理を示すフローチャートである。
【図７】ＷＥＢサーバのＣＰＵが実行する注文状況発信処理を示すフローチャートである。
【図８】ＷＥＢサーバのＣＰＵが実行するメニュー取得処理を示すフローチャートである。
【図９】（ａ）は質問器、ＲＦタグおよびＲＦタグ制御部の構成を示す説明図であり、（ｂ）は皿および皿に取り付けられたＲＦタグを示す説明図（１）であり、（ｃ）は皿および皿に取り付けられたＲＦタグの別実施形態を示す説明図（２）である。
【図１０】（ａ）はＲＦタグ制御部、テーブルシートおよびＲＦタグの各構成を示す説明図（１）であり、（ｂ）はＲＦタグ制御部、テーブルシートおよびＲＦタグの各構成を示す説明図（２）である。
【図１１】（ａ）はテーブルシートの構成を示す説明図であり、（ｂ）は別実施形態の質問器Ａの構成を示す説明図であり、（ｃ）は別実施形態のテーブルシートの構成を示す説明図である。
【図１２】質問器Ａからの質問信号Ａｑに対するＲＦタグ８（Ｋ１〜Ｋ４）の応答信号ＩＤの応答タイミングを示すタイムチャートである。
【図１３】サイクルＡ〜Ｄにおける質問器Ａ〜ＤおよびＲＦタグ８（Ｋ１〜Ｋ４）の応答具合を示すタイムチャート（１）である。
【図１４】サイクルＡ〜Ｄにおける質問器Ａ〜ＤおよびＲＦタグＫ１〜Ｋ４の応答具合を示すタイムチャート（２）である。
【図１５】従来のカラオケボックスにおける、注文・調理・搬送・受取を示すタイムチャートである。
【図１６】本実施形態のカラオケボックスにおける、注文・調理・搬送・受取を示すタイムチャートである。
【図１７】ＲＦタグ制御部のＣＰＵが実行するＲＦタグ制御処理を示すフローチャートである。
【図１８】ＲＦタグ制御部のＣＰＵが実行するＡサイクルに関する処理を示すフローチャートである。
【図１９】ＲＦタグ制御部のＣＰＵが実行するＲＦタグに関する処理を示すフローチャートである。
【図２０】（ａ）はＲＦタグ制御部のＲＡＭが記憶するテーブルを示す説明図（１）であり、（ｂ）はＲＦタグ制御部のＲＡＭが記憶するテーブルを示す説明図（２）である。
【図２１】厨房端末の全体構成を示すブロック図である。
【図２２】厨房端末のＣＰＵが実行する調理に関する処理を示すフローチャートである。
【図２３】（ａ）はＷＥＢサーバのＲＡＭが記憶するテーブルを示す説明図（１）であり、（ｂ）はＷＥＢサーバのＲＡＭが記憶するテーブルを示す説明図（２）であり、（ｃ）はＷＥＢサーバのＲＡＭが記憶するテーブルを示す説明図（３）である。
【図２４】（ａ）は厨房端末のＲＡＭが記憶するテーブルを示す説明図（１）であり、（ｂ）は厨房端末のＲＡＭが記憶するテーブルを示す説明図（２）であり、（ｃ）は厨房端末のＲＡＭが記憶するテーブルを示す説明図（３）であり、（ｄ）は厨房端末のＲＡＭが記憶するテーブルを示す説明図（４）である。
【図２５】商品注文システムのシグナルフロー（正常終了時）を示す説明図である。
【図２６】商品注文システムのシグナルフロー（事故発生時）を示す説明図である。
【図２７】（ａ）はリモコン端末などに表示させるメニュー例（１）を示す説明図（１）であり、（ｂ）はリモコン端末などに表示させるメニュー例（２）を示す説明図（２）であり、（ｃ）はリモコン端末などに表示させるメニュー例（３）を示す説明図（３）である。
【図２８】（ａ）はルーム情報テーブルを示す説明図であり、（ｂ）はオーダー情報を示す説明図であり、（ｃ）は厨房依頼情報を示す説明図である。
【図２９】従来のオーダーエントリーシステムを備えるカラオケボックスの見取り図である。
【符号の説明】
【０１１４】
１…カラオケ装置、２…リモコン端末、３…ＲＦタグ制御部、３ａ，４ａ，６ａ…バス、３ｂ，４ｂ，６ｂ…ＬＡＮインターフェイス、３ｃ，４ｃ，６ｃ…ＲＯＭ、３ｄ，４ｄ，６ｄ…ＲＡＭ、３ｅ，４ｅ，６ｅ…ＣＰＵ、３ｆ，４ｆ，６ｆ…制御インターフェイス、４…ＷＥＢサーバ、５…無線ＬＡＮアクセスポイント、６…厨房端末、６ｇ…ＶＩＤＥＯインターフェイス、６ｈ…キーボード、６ｉ…テレビジョン、７，１０７…テーブルシート、７ａ…テーブル、８…ＲＦタグ、１２…制御部、１４…インターフェイス部、１６…ハードディスク（ＨＤＤ）、１８…操作部、２０…赤外線通信部、２２…操作処理部、２４…音声制御部、２６…マイクロフォン、２８…スピーカ、３０…ＭＩＤＩ音源、３２…ビデオＲＡＭ、３４…映像再生部、３６…表示部、３８…映像制御部、４０…ＵＳＢ、５２…制御部、５４…赤外線通信部、５６…メモリ、５８…表示部、６０…操作部、６２…操作処理部、６４…ビデオＲＡＭ、６６…映像制御部、６８…無線ＬＡＮ通信部、７０…ＵＳＢ制御部、７６…クレードル、７８…ＵＳＢ／ＬＡＮ変換機、１００…商品注文システム、１１０…カラオケシステム
【図１】
2006285641.tif 000003
【図２】
2006285641.tif 000004
【図３】
2006285641.tif 000005
【図４】
2006285641.tif 000006
【図５】
2006285641.tif 000007
【図６】
2006285641.tif 000008
【図７】
2006285641.tif 000009
【図８】
2006285641.tif 000010
【図１０】
2006285641.tif 000011
【図１２】
2006285641.tif 000012
【図１３】
2006285641.tif 000013
【図１４】
2006285641.tif 000014
【図１７】
2006285641.tif 000015
【図１８】
2006285641.tif 000016
【図１９】
2006285641.tif 000017
【図２０】
2006285641.tif 000018
【図２１】
2006285641.tif 000019
【図２２】
2006285641.tif 000020
【図２３】
2006285641.tif 000021
【図２４】
2006285641.tif 000022
【図２５】
2006285641.tif 000023
【図２６】
2006285641.tif 000024
【図２７】
2006285641.tif 000025
【図２８】
2006285641.tif 000026
【図２９】
2006285641.tif 000027
【図９】
2006285641.tif 000028
【図１１】
2006285641.tif 000029
【図１５】
2006285641.tif 000030
【図１６】
2006285641.tif 000031