(57)【特許請求の範囲】
【請求項１】
システムにおいて、
１つ以上のプロセッサと、
前記１つ以上のプロセッサに連結されたメモリと、
通信回路と、を含むサーバ
を備え、
前記メモリは、実行可能な命令を含み、前記実行可能な命令が、前記１つ以上のプロセッサによって実行されると、
前記１つ以上のプロセッサが、
ユーザからの入力に基づいた情報を、ユーザデバイスから、および前記通信回路を通じて、受信することと、
前記情報に基づいて、前記ユーザが購入することのできる１つ以上のアイテムを含む前記ユーザ向けのメニューを生成し、
前記通信回路を通じて、前記メニューを前記ユーザデバイスに送信することと、
前記ユーザデバイスに入力された前記１つ以上のアイテムのうちの第１のアイテムを含む注文情報を備える、第１のメッセージを、前記ユーザデバイスから、および前記通信回路を通じて、受信することと、
前記１つ以上のアイテムのうちの第２のアイテムを含む注文情報を備える、第２のメッセージを、前記通信回路を通じて、受信することと、
前記第１のメッセージおよび、前記第２のメッセージが所定の期間以内に受信されたか判断することと、
前記ユーザデバイスの位置情報と結びつけられた第１の位置情報と、複数の配達ステーションのデバイスの位置情報と結びつけられた第２の位置情報を前記通信回路を通じて受信し、
前記複数の配達ステーションのうち、前記ユーザデバイスの最も近くに配置された配達ステーションを特定することと、
前記第１および第２のメッセージが前記所定の期間以内に受信されたことに基づいて、
前記第１および第２のアイテム両方の準備ができた場合のみ、前記第１および第２のアイテムと関連するそれぞれの場所を示す配達リクエストを、特定された前記配達ステーションのデバイスに前記通信回路を通じて送信し、かつ、
前記第１および第２のアイテムが前記特定された配達ステーションのデバイスの第２のユーザによって配達されたときに確認を受信する、ことと、
を含む、業務を実行する、システム。
【請求項２】
請求項１に記載のシステムにおいて、
前記ユーザと関連する情報は、フライト状況を含み、
前記業務は、
前記フライト状況に基づいて、前記ユーザのコンピューティングデバイスに警報を送信することをさらに含む、システム。
【請求項３】
請求項１に記載のシステムにおいて、
前記業務は、
前記第１および第２のメッセージを受信したことに応じて、前記第１および第２のアイテムにそれぞれ対応する準備ステーションを特定することをさらに含む、システム。
【請求項４】
請求項３に記載のシステムにおいて、
前記業務は、
特定された前記準備ステーションに準備リクエストを送信することをさらに含む、システム。
【請求項５】
請求項４に記載のシステムにおいて、
前記特定された準備ステーションは、複数の準備ステーションのうちの１つであり、
前記業務は、
前記準備リクエストを前記特定された準備ステーションにのみ送信することをさらに含む、システム。
【請求項６】
請求項１に記載のシステムにおいて、
前記業務は、
第３のユーザと関連する第２の場所を示す補助リクエストを受信することと、
前記補助リクエストを表示することと、
前記補助リクエストが満たされたと判断することと、
をさらに含む、システム。
【請求項７】
請求項６に記載のシステムにおいて、
前記業務は、
前記補助リクエストが満たされたと判断することに応じて、前記補助リクエストをディスプレイから削除することをさらに含む、システム。
【請求項８】
実行可能な命令を含むコンピュータ可読記憶媒体において、
前記実行可能な命令が、少なくとも１つのプロセッサ及び通信回路を備えるサーバの、少なくとも１つのプロセッサによって実行されると、前記プロセッサは、
ユーザからの入力に基づいた情報をユーザデバイスから、および前記通信回路を通じて受信することと、
前記情報に基づいて、前記ユーザが購入することのできる１つ以上のアイテムを含む前記ユーザ向けのメニューを作成し、前記通信回路を通じて前記ユーザデバイスに送信することと、
前記ユーザデバイスに入力された前記１つ以上のアイテムのうちの第１のアイテムを含む注文情報である、第１のメッセージを、前記ユーザデバイスから、および前記通信回路を通じて受信することと、
前記１つ以上のアイテムのうちの第２のアイテムを含む注文情報を備える、第２のメッセージを、前記通信回路を通じて、受信することと、
前記第１のメッセージおよび、前記第２のメッセージが所定の期間以内に受信されたか判断することと、
前記ユーザデバイスの位置情報と結びつけられた第１の位置情報と、複数の配達ステーションのデバイスの位置情報と結びつけられた第２の位置情報を前記通信回路を通じて受信し、
前記複数の配達ステーションのうち、前記ユーザデバイスの最も近くに配置された配達ステーションを特定することと、
前記第１および第２のメッセージが前記所定の期間以内に受信されたことに基づいて、
前記第１および第２のアイテム両方の準備ができた場合のみ、前記第１および第２のアイテムと関連するそれぞれの場所を示す配達リクエストを、特定された前記配達ステーションのデバイスに前記通信回路を通じて送信し、かつ、
前記第１および第２のアイテムが前記特定された配達ステーションのデバイスの第２のユーザによって配達されたときに確認を受信する、ことと、
を含む、業務を実行する、コンピュータ可読記憶媒体。
【請求項９】
請求項８に記載のコンピュータ可読記憶媒体において、
前記ユーザと関連する情報は、フライト状況を含み、
前記業務は、
前記フライト状況に基づいて、前記ユーザのコンピューティングデバイスに警報を送信することをさらに含む、コンピュータ可読記憶媒体。
【請求項１０】
請求項８に記載のコンピュータ可読記憶媒体において、
前記業務は、
前記第１および第２のメッセージを受信したことに応じて、前記第１および第２のアイテムにそれぞれ対応する準備ステーションを特定することをさらに含む、コンピュータ可読記憶媒体。
【請求項１１】
請求項１０に記載のコンピュータ可読記憶媒体において、
前記業務は、
特定された前記準備ステーションに準備リクエストを送信することをさらに含む、コンピュータ可読記憶媒体。
【請求項１２】
請求項１１に記載のコンピュータ可読記憶媒体において、
前記特定された準備ステーションは、複数の準備ステーションのうちの１つであり、
前記業務は、
前記準備リクエストを前記特定された準備ステーションにのみ送信することをさらに含む、コンピュータ可読記憶媒体。
【請求項１３】
請求項８に記載のコンピュータ可読記憶媒体において、
前記業務は、
第３のユーザと関連する第２の場所を示す補助リクエストを受信することと、
前記補助リクエストを表示することと、
前記補助リクエストが満たされたと判断することと、
をさらに含む、コンピュータ可読記憶媒体。
【請求項１４】
請求項１３に記載のコンピュータ可読記憶媒体において、
前記業務は、
前記補助リクエストが満たされたと判断することに応じて、前記補助リクエストをディスプレイから削除することをさらに含む、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【開示の内容】
【０００１】
〔関連出願の相互参照〕
本出願は、２０１４年９月３０日出願の米国仮特許出願第６２／０５７，６９１号、および２０１５年４月１７日出願の米国特許出願第１４／６８９，５９０号の利益を主張するものであり、これらの特許出願双方の開示は、それぞれの全体が本明細書に記載されているかのように、参照によって本明細書に組み込まれるものである。
【０００２】
〔背景〕
例えば、独立型の店、競技場、ショッピングモール、もしくは空港などの、閉鎖的な小売業環境では、客は、典型的には、種々の店もしくは売店（concessions stands）から、アイテムを購入することができる。よって、購買決定は、しばしば、客の便利さに基づいて行われる。例えば、客が製品から遠く離れるほど、客がその製品に気づき得る可能性が低くなり、そのため、客がその製品を購入する可能性が低くなる。客が遠隔位置から商品を注文できるモデルが存在し、よって、その遠隔位置は、注文履行位置と呼ばれ得る。本明細書で使用される、遠隔位置とは、所与の客に物理的に近接していない任意の位置を指し得る。ほんの一例として、米国特許第７，９４５，４７７号および米国特許第６，４７３，７３９号は、顧客がタブレットの注文デバイスから注文することができるシステムを記載している。前述したシステムでは、ユーザは、システムへの認証を受けて、アカウントを通じてデバイスに割り当てられたままでいなければならないと思われ、これは、客にとってはいくつかの工程が必要である。これらのシステムのさらなる欠点は、ユーザが自分たちの割り当てられたデバイスに拘束されているため、デバイス間を自由に移動できないことであると思われる。
【０００３】
例えば空港もしくは競技場といった、展開の速い環境では、客は、遠隔的に製品を買うのに多くの工程を経る時間が無いことが多い。ユーザアカウントを必要とすること、支払いを事前に調整すること、および／または、支払いを預託することは、買い物をする妨げとなり得る。遠隔注文に対する既存のアプローチでは、例えばハードコードされたデバイス識別、認証、ユーザアカウントの設定、デバイスおよび客の位置決定といった、操作上の設定も大量に必要となる。さらに、既存のシステムは、共用リソースを含む企業環境で、遠隔的に注文を履行することに伴う問題に対応していないことが多い。よって、既存の遠隔注文および注文履行システムには、能率および能力が不足している。
【０００４】
〔概要〕
本明細書には、１つ以上のコンピューティングデバイスを用いて、業務を管理する、例えば、発注して、注文を履行するための、システム、方法、および装置が記載される。例としての実施形態によると、業務管理システムは、セルフオーダーシステム、セルフペイメントシステム、および注文履行システムを含み得る。セルフオーダーシステムと、セルフペイメントシステムと、注文履行システムとは、例えば無線ネットワークなど、これらのシステム同士を接続する通信システムを介して、互いに通信することができる。業務管理システムを使用すると、効果的に、かつ人とのやりとりを最小限にして、注文を行い、履行することができる。
【０００５】
例としての実施形態では、装置、例えばサーバは、プロセッサと、プロセッサに連結されたメモリと、を含む。メモリは、プロセッサによって実行されるとプロセッサに業務を実施させる、実行可能な命令を含む。業務は、客に関する情報を受信することを含む。客に関する情報に基づいて、その客に特化したメニューが生成され得る。このメニューは、客が購入することのできる、１つ以上のアイテムを含み得る。業務は、１つ以上のアイテムのうち少なくとも１つの選択されたアイテムを含む注文を受けることをさらに含み得る。業務は、客の近くに配置された配達ステーションを特定することと、特定された配達ステーションにリクエストを送ることと、をさらに含み得る。リクエストは、少なくとも１つの選択されたアイテムと、客に関連する場所と、を示すことができる。業務は、少なくとも１つの選択されたアイテムが客に配達されたときに確認を受け取ることをさらに含み得る。
【０００６】
前述した概要、ならびに、本開示の例としての実施形態に関する以下の詳細な説明は、添付図面と共に読めば、よりよく理解されるであろう。本開示の例としての実施形態を例示する目的で、図面を参照する。しかしながら、適用は図示する厳密な配列および手段に制限されるものではないことを、理解されたい。
【０００７】
〔例示的な実施形態の詳細な説明〕
本明細書では、１つ以上のコンピューティングデバイスを用いて、業務を管理する、例えば、発注し、注文を履行するための、システム、方法、および装置を説明する。最初に図１を参照すると、業務管理システム１００は、発注（もしくはオーダー）システム１０２と、支払システム１０６と、注文履行システム１０４と、を含み得る。発注システム１０２により、客は、スタッフの助けなしで注文を行うことができ、そのため、発注システム１０２は、自己発注（もしくはセルフオーダー）システム１０２として構成され得る。同様に、支払システム１０６により、客は、スタッフの助けなしで支払いを行うことができ、そのため、支払システムは、セルフペイメントシステム１０６として構成され得る。発注システム１０２と、支払システム１０６と、注文履行システム１０４とは、ネットワーク１１０など、システム同士を接続する通信システムを介して、互いと通信することができる。業務管理システム１００は、１つ以上のルールエンジン、例えば、ネットワーク１１０を介してアクセスされ得るビジネスルールエンジン、をさらに含み得る。例としてのルールエンジン１０８は、制限なく、リコメンデーションエンジン１０８ａと、注文待ちエンジン１０８ｂと、注文履行エンジン１０８ｃと、を含む。例示目的で、業務管理システム１００は、しばしば、レストランもしくは空港との関連で以下に説明されるが、業務管理システム１００が所望どおりの任意の適切な商業的環境で実行され得ることが、理解される。例えば、レストランに適用されると、以下でさらに説明するように、客は、業務管理システム１００を使用し、レストランの職員とやり取りせずに、メニューアイテムを見て、特定のメニューアイテムを注文し、注文したメニューアイテムを受け取ることができる。さらに、レストランの例を続けると、レストランは、リソースおよびタスクを管理し、注文を履行するために、業務管理システム１００を使用することができる。
【０００８】
（以下で説明する）図２〜図５および図７Ｂは、業務を管理するための方法および装置のさまざまな実施形態を例示している。これらの図面では、さまざまな工程または業務が、１つ以上のクライアント、サーバ、および／またはエンジンによって行われているところが示されている。これらの図面に例示されるクライアント、サーバ、エンジンは、通信ネットワーク内の論理構成体を表すことができ、また、以下で説明する図６Ａまたは図６Ｂに示す一般的構造のうちの１つを含み得る、このようなネットワークノードのメモリに記憶され、そのプロセッサ上で実行される、ソフトウェア（例えばコンピュータ実行可能命令）の形態で実施され得ることが、理解される。すなわち、図２〜図５、図７Ｂに示す方法は、例えば図６Ａまたは図６Ｂに示すノードもしくはコンピュータシステムなどの、ネットワークノードのメモリに記憶されたソフトウェア（例えばコンピュータ実行可能命令）の形態で実行されることができ、このコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図面に示す工程を行う。これらの図面に例示される任意の送信および受信工程が、ノードのプロセッサ、およびそれが実行するコンピュータ実行可能命令（例えばソフトウェア）の制御下で、ノードの通信回路によって実行され得ることも、理解される。
【０００９】
次に図２を参照すると、例示された実施形態に従って、発注システム１０２は、ネットワーク１１０を介してリコメンデーションエンジン１０８ａおよび１つ以上のサーバと通信する、１つ以上のコンピューティングデバイス１１２を含み得る。図２は、レストランのメニューからのアイテムもしくは空港で利用可能な製品などのアイテムを注文するための適切な通信アーキテクチャの一例を描いており、多くの適切な代替的通信アーキテクチャが構想されることが、理解される。例としてのシステム１０２が、開示する主題の説明を容易にするために単純化されており、本開示の範囲を制限することは意図していないことが、さらに理解されるであろう。他のデバイス、システム、構成が、システム１０２に加えて、またはシステム１０２の代わりに、本明細書に開示する実施形態を実施するのに使用されてよく、そのような実施形態はすべて、本開示の範囲内のものとして企図されている。
【００１０】
例としての実施形態では、クライアントアプリケーションは、１つ以上のコンピューティングデバイス１１２にインストールされ得る。このようなアプリケーションは、注文アプリケーションまたはカスタマーアプリケーションとも呼ぶ場合がある。あるいは、コンピューティングデバイス１１２は、例えばインターネットなどのネットワーク１１０を介して、注文アプリケーションにアクセスし得る。よって、場合によっては、注文アプリケーションは、クラウドベースの注文アプリケーションと呼ばれ得る。この注文アプリケーションを用いて、所与のコンピューティングデバイス１１２は、情報を、１つ以上のサーバ、例えばサーバ１１４に送信することができる。例としての実施形態では、サーバアプリケーションが、サーバ１１４などのコンピューティングデバイスにインストールされる。サーバアプリケーションは、ルールエンジン１０８を実行して、情報をコンピューティングデバイス１１２、特に注文アプリケーションに送信することができる。
【００１１】
例としての構成では、客１１６と呼ばれる場合もあるユーザ１１６は、コンピューティングデバイス１１２（例えばタブレットまたはスマートフォン）の注文アプリケーションを、例えばコンピューティングデバイス１１２上に表示されるアイコンを選択することによって、起動することができる。代替的な構成では、職員（例えば、ウェイター）が、コンピューティングデバイス１１２の注文アプリケーションを起動することができ、注文アプリケーションを介して客の注文を入力することができる。例としての実施形態では、サーバ１１４、特にサーバアプリケーションは、コンピューティングデバイス１１２によって表示されたアイテムを選択することができる。サーバ１１４は、所与のユーザ１１６のアイデンティティに基づいて、そのユーザ１１６に対してどのアイテムを表示するか決定することができる。サーバ１１４は、例えば、時刻、時期、特定のアイテムの現在量、利用可能な現在のリソースなどといった、さまざまなパラメータに基づいて、購入可能なアイテムを特定することができる。例えば、発注システム１０２がレストランの環境に配備される場合、サーバ１１４は、時刻に基づいて客に表示するメニューアイテム（例えば、朝食用食品、昼食用食品、または夕食用食品）を決定することができる。さらなる実施例として、サーバ１１４は、現在のリソースに基づいて表示される特定のアイテムを特定することができる。レストランスタッフが不足している場合、サーバ１１４は、レストランスタッフがフル稼働している場合にサーバが選択するメニューと比べて、限られたメニューを選択することができる。同様に、サーバ１１４は、厨房スタッフの能力に基づいて、コンピューティングデバイス１１２が表示する特定の食品アイテムを選択することができる。サーバ１１４は、特定のアイテムの量が所定の閾値未満、例えば１個などであった場合に、購入用の特定のアイテムを取り除くことができる。サーバ１１４が、所望のとおりに任意のパラメータに基づいてコンピューティングデバイス１１２が表示するアイテムを選択でき、アイテムが動的に調節されることが、理解されるであろう。
【００１２】
場合によっては、発注システム１０２は、空港で実行されてよく、そうすると、ルールエンジン１０８は、フライトに関連するパラメータに基づいて、購入用に表示されるアイテムを選択することができる。例えば、ルールエンジン１０８は、表示される具体的なフライト時刻もしくは状況を選択することができる。「ラストコール」シナリオと呼ばれ得る場合には、ルールエンジン１０８は、所定の時間にユーザに与えるアイテムを特定でき、この所定の時間は、ユーザに関連するフライトに基づいている。例えば、ルールエンジン１０８は、ドリンクを提供すべきであることを特定でき、コンピューティングデバイス１１２は、ユーザのフライトが搭乗または出発する予定となるより前の時間（例えば３０分前）に、購入用のドリンクを表示することができる。サーバ１１４は、コンピューティングデバイス１１２によって表示されるフライト状況が定期的にかつ／または変更に応じて更新されるように、実時間のフライト最新情報を受け取ることができる。例としての実施形態では、サーバ１１４は、客に関連するフライトの状況に基づいて、勘定を払うようユーザを促すことができる。ほんの一例として、所定の時間に、例えば、ユーザのフライトが搭乗を開始したときに、サーバ１１４は、ユーザ１１６のコンピューティングデバイス１１２にメッセージを送ることができ、コンピューティングデバイス１１２は、ユーザ１１６に、彼／彼女のフライトが搭乗を行っていることを知らせる。コンピューティングデバイス１１２は、可聴警報、視覚的警報などを出すことができる。
【００１３】
コンピューティングデバイス１１２を使用して、客１１６は、購入可能なアイテムを見ることができ、人とやり取りせずに、所望の購入用アイテムを選択することができる。例としての実施形態では、以下でさらに説明するように、客１１６が購入用アイテムを選択すると、選択されたアイテムを示すメッセージが、コンピューティングデバイス１１２から、ネットワーク１１０を介して、注文履行システム１０４に送信される。
【００１４】
認識されるように、前述した当事者および／または他の関連する当事者はそれぞれ、任意の数のそれぞれのデバイスを操作することができ、また、例えば、インターネットなどの広域ネットワーク（ＷＡＮ）またはローカルエリアネットワーク（ＬＡＮ）を含む、任意の数のネットワークを用いて、内外で通信することができる。１つ以上のサーバ１１４は、ユーザ、例えば管理者によって、構成され得る。
【００１５】
図６Ｂは、図１〜図５に例示するクライアント、サーバ、エンジン、もしくはデバイスのうちの１つなど、ネットワークのノードの例としてのハードウェア／ソフトウェアアーキテクチャのブロック図である。図６Ｂに示すように、ノード３０は、プロセッサ３２と、トランシーバー３４と、送信／受信要素３６と、スピーカー／マイク３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、取り外し不可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球位置把握システム（ＧＰＳ）チップセット５０と、他の周辺装置５２と、を含み得る。ノード３０は、トランシーバー３４および送信／受信要素３６などの通信回路も含み得る。ノード３０が実施形態と整合したままで、前述した要素の任意の部分的組み合わせを含み得ることが、認識されるであろう。任意の適切なノード３０は、例えば、自己発注アプリケーションもしくは注文履行アプリケーションなど、さまざまな業務管理アプリケーションを提供するように構成され得る。ノード３０がコンピューティングデバイス１１２を含み得ることが、理解され、コンピューティングデバイス１１２は、さまざまなデバイスとして構成されてよく、その例としては、デスクトップコンピューティングデバイス、サーバコンピューティングデバイス、または携帯用コンピューティングデバイス、例えばラップトップ型コンピュータ、タブレット、もしくはスマートフォン、が含まれる。認識されるように、前述した構成要素のいずれも、１つ以上の別個のデバイスおよび／または場所にわたって、分配され得る。
【００１６】
プロセッサ３２は、汎用プロセッサ、特殊用途のプロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連した１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械など、であってよい。プロセッサ３２は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはノード３０が無線環境で動作することを可能にする任意の他の機能を実行し得る。プロセッサ３２は、トランシーバー３４に連結されてよく、トランシーバー３４は、送信／受信要素３６に連結され得る。図６Ｂでは、プロセッサ３２およびトランシーバー３４が別々の構成要素として描かれているが、プロセッサ３２およびトランシーバー３４が電子パッケージまたはチップ内で互いに一体化され得ることが、認識されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えばブラウザ）ならびに／または無線アクセス層（ＲＡＮ）プログラムおよび／もしくは通信を実行することができる。プロセッサ３２は、例えば、アクセス層および／もしくはアプリケーション層などにおける、認証、セキュリティキーアグリーメント（security key agreement）、および／または暗号を使用した業務などのセキュリティ業務を実行することができる。
【００１７】
図６Ｂに示すように、プロセッサ３２は、その通信回路（例えばトランシーバー３４および送信／受信要素３６）に連結される。プロセッサ３２は、コンピュータ実行可能命令の実行により、通信回路を制御して、ノード３０を、それが接続されるネットワークを介して、他のノードと通信させることができる。具体的には、プロセッサ３２は、通信回路を制御して、本明細書（例えば図１〜図５）および請求項に記載する、送受信工程を行うことができる。図６Ｂでは、プロセッサ３２およびトランシーバー３４が別々の構成要素として描かれているが、プロセッサ３２およびトランシーバー３４が電子パッケージもしくはチップ内で互いに一体化され得ることが、理解されるであろう。
【００１８】
送信／受信要素３６は、ルールエンジン、コンピューティングデバイス、サーバなどを含む、他のノードに信号を送信するか、または他のノードから信号を受信するように構成され得る。例えば、ある実施形態では、送信／受信要素３６は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってよい。送信／受信要素３６は、さまざまなネットワークおよびエアーインターフェース、例えばＷＬＡＮ、ＷＰＡＮ、セルラー方式のもの（cellular）などをサポートすることができる。ある実施形態では、送信／受信要素３６は、例えば、ＩＲ信号、ＵＶ信号、もしくは可視光線信号を送信および／または受信するように構成された、エミッター／検出器であってよい。さらに別の実施形態では、送信／受信要素３６は、ＲＦ信号および光信号の両方を送受信するように構成され得る。送信／受信要素３６が、無線信号もしくは有線信号の任意の組み合わせを送信および／または受信するように構成され得ることが、認識されるであろう。
【００１９】
さらに、図６Ｂでは送信／受信要素３６が１つの要素として描かれているが、ノード３０は、任意の数の送信／受信要素３６を含み得る。さらに具体的には、ノード３０は、ＭＩＭＯテクノロジーを採用し得る。よって、ある実施形態では、ノード３０は、無線信号を送受信するための、２つ以上の送信／受信要素３６（例えば複数のアンテナ）を含み得る。
【００２０】
トランシーバー３４は、送信／受信要素３６によって送信されるべき信号を変調し、かつ、送信／受信要素３６によって受信される信号を復調するように構成され得る。前述のとおり、ノード３０は、多重モード能力を有し得る。よって、トランシーバー３４は、例えば、ＵＴＲＡおよびＩＥＥＥ  ８０２．１１など、複数のＲＡＴを介してノード３０が通信することができるように、複数のトランシーバーを含んでよい。
【００２１】
プロセッサ３２は、取り外し不可能のメモリ４４および／もしくは取り外し可能なメモリ４６など、任意のタイプの適切なメモリからの情報にアクセスし、かつそのメモリにデータを記憶させることができる。取り外し不可能のメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ３２は、物理的にはサーバもしくはホームコンピュータ上などのノード３０上に位置しないメモリからの情報にアクセスし、かつそのメモリにデータを記憶させることができる。プロセッサ３２は、ディスプレイもしくはインジケータ４２上の点灯パターン、画像、もしくは色を制御して、本明細書に記載するような注文状況を反映するように構成され得る。プロセッサ３２は、電源４８から電力を受け取ることができ、また、ノード３０のその他の構成要素への電力を分配および／または制御するように構成され得る。電源４８は、ノード３０に電力供給するための任意の適切なデバイスであってよい。例えば、電源４８は、１つ以上の乾電池（例えば、ニッケル‐カドミウム（ＮｉＣｄ）、ニッケル-亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ-ｉｏｎ）など）、太陽光電池、燃料電池など、を含み得る。
【００２２】
プロセッサ３２は、ＧＰＳチップセット５０に連結されることもでき、ＧＰＳチップセット５０は、ノード３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されている。ノード３０が、実施形態と整合した状態で、任意の適切な位置決定方法により位置情報を取得し得ることが、認識されるであろう。
【００２３】
プロセッサ３２は、他の周辺装置５２にさらに連結されてよく、他の周辺装置５２は、追加の特徴、機能性、および／または有線もしくは無線の接続性を提供する、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば、周辺装置５２は、加速度計、ｅコンパス（e-compass）、衛星トランシーバー、センサー、デジタルカメラ（写真もしくはビデオ用）、ユニバーサル・シリアル・バス（ＵＳＢ）ポート、振動デバイス、テレビトランシーバー（television transceiver）、ハンズフリーのヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線装置、デジタル音楽プレーヤー、メディアプレーヤーを含み得る。
【００２４】
さまざまな実施形態では、ディスプレイ／タッチパッド／インジケータ４２は、注文に関する情報を受信および／または提供することができる。ディスプレイ／タッチパッド／インジケータ４２により、ユーザは、ノード３０と通信することが可能となる。よって、ノード３０は、プロセッサ、プロセッサに連結されたディスプレイ、プロセッサと通信するメモリを含み得る。メモリは、その中に命令を記憶していてよく、その命令がプロセッサによって実行されると、コンピュータシステムは、業務、例えば本明細書に記載した業務を実施する。ディスプレイ４２は、図１〜図５を参照して説明した情報、ならびに、図８Ａ〜図３４に描かれたスクリーンショットおよびそれらの変形体、などの視覚情報を表示するように構成され得る。
【００２５】
次に図３を参照すると、例としての方法が描かれており、この方法は、空港の環境で実装される発注システム１０２内部で行われ得る。具体的には、空港内にあるユーザコンピューティングデバイス１１２ａが、ネットワーク１１０を介してサーバ１１４ａと通信し得る。例示された実施例によると、３０２では、一般的には客もしくはユーザアプリケーションとも呼ばれ得る、注文アプリケーションが、ユーザデバイス１１２ａにロードされる。例えば、ユーザアプリケーションは、ユーザデバイス１１２ａのユーザがユーザデバイス１１２ａにより表示されたアイコンを選択したら、ロードされることができる。３０４では、ユーザデバイス１１２ａは、ユーザデバイス１１２ａのユーザが注文アプリケーションを起動したことを示すメッセージをサーバ１１４ａに伝えることができる。３０６では、サーバは、フライトデータ、例えば、ユーザデバイス１１２ａが位置するターミナルと関連するフライトデータを検索することができる。３０８では、例示された実施形態によると、サーバ１１４ａは、フライトデータをユーザデバイス１１２ａに送信する。例えば、サーバ１１４ａは、ユーザデバイス１１２ａが位置するターミナルと関連する、更新済みの到着もしくは出発時刻を送信することができる。３１０では、ユーザデバイス１１２ａは、ユーザに関連する情報を収集することができる。例えば、ユーザアプリケーションは、ユーザに関連するフライト情報を受信することができる。場合によっては、ユーザアプリケーションは、ユーザの身元に基づいて、ユーザに関連する特徴を決定することができる。３１２では、ユーザデバイス１１２ａは、ユーザに関連する情報、例えば、フライト情報もしくは個人情報を、サーバ１１４ａに送信することができる。３１４では、サーバ１１４ａは、ユーザが購入することのできるアイテムを含むメニューを生成する。場合によっては、例えば、ユーザに送信する個人情報が提供されない場合、デフォルトメニューが生成され得る。デフォルトメニューは、時刻、利用可能なリソースなどに基づいていてよい。レストランの環境では、朝食時間、昼食時間、夕食時間、深夜時間などのそれぞれについて、デフォルトメニューがあってよい。同様に、さまざまなスタッフ配置構成のそれぞれについて、デフォルトメニューがあってよい。よって、サーバ１１４ａは、スタッフが限られているときには第１のデフォルトメニューを生成し、スタッフが限られていないときには、第１のデフォルトメニューより大きな第２のデフォルトメニューを生成することができる。
【００２６】
引き続き図３を参照すると、３１４では、サーバ１１４ａは、３１２で受信され得る個人情報に基づいて、カスタムメニューを生成することができる。ほんの一例として、ユーザが法律で飲酒が認められている年齢に達していないことを示す個人情報を、サーバ１１４ａが受信すると、サーバ１１４ａは、アルコール飲料を除外したカスタムメニューを生成することができる。さらなる例として、ユーザが特定の都市もしくは地域に赴いていることを示す個人情報を、サーバ１１４ａが受信すると、サーバ１１４ａは、その特定の都市もしくは地域に関連するアイテムを含むカスタムメニューを生成することができる。例えば、ユーザが海辺のリゾートタウンに赴いている場合、サーバ１１４ａは、その海辺に関連するアイテム、例えばサングラス、日焼け止めクリーム、タオル、スイムウェアなどを含む、カスタムメニューを生成することができる。さらに、３１４では、サーバ１１４ａは、リコメンデーションエンジン１０８ａを用いて、お勧め（recommendations）を作成することができる。ほんの一例として、ユーザに関連する目的地で雨が降っていると、サーバ１１４ａが判断したら、サーバ１１４ａは、ユーザに傘を勧めることができる。よって、傘がメニューに含まれ得る。したがって、以下でさらに説明するように、サーバ１１４ａは、例えば天気などの、外部パラメータからの情報に基づいて、さまざまなお勧めを作成することができる。他のお勧めは、他のパラメータに基づいていてよい。例えば、サーバ１１４ａは、客が食事を注文する前および／または後で、手の除菌用ローション（hand sanitizer）に関するお勧めを作成することができる。
【００２７】
３１６では、例示された実施例に従って、メニュー内容およびデジタルアセットが、ユーザデバイス１１２ａに送られる。デジタルアセットは、画像、動画、もしくは音を指すことができる。例えば、メニュー内容は、例えば食品の写真など、メニューと関連したデジタルアセット、および、例えば食品アイテムの説明文など、そのメニューと関連した文章を含み得る。３１８では、ユーザデバイス１１２ａは、ユーザから選択したものを受信する。この選択したものは、ユーザが購入したいと思うメニューアイテムに対応し得る。３２０では、ユーザデバイス１１２ａは、ユーザが選択したものをサーバ１１４ａに送る。３２２では、ユーザが選択したものに基づいて、サーバ１１４ａは、選択したもののコストを算出することができる。３２４では、サーバ１１４ａは、ユーザが支払う予定の最終コストを含むメッセージをユーザデバイス１１２ａに送ることができる。３２６では、サーバ１１４ａは、勘定書開始機能（open check function）を確認し得る。勘定書開始機能が当てはまる（true）と設定されていれば、注文は支払い無しで処理され得る。このようなシナリオでは、勘定書は、別のサーバから、またはユーザのコンピューティングデバイス１１２から、拾い上げられて、終了され得る。３２８では、ユーザデバイスは、サーバ１１４ａに最終注文を送信することができ、かつ／またはユーザデバイス１１２ａは、以下でさらに説明するように、支払情報をサーバ１１４ａに送ることができる。
【００２８】
図８Ａを参照すると、例としての発注ページ８００が、前述したように、注文を入力するのに使用され得る。例えば、ユーザ（例えば客もしくは職員）は、発注ページ８００に表示されたアイテムを選択することができる。ユーザが購入するアイテムを選択したら、その選択されたアイテムが、発注ページ８００の注文ウィンドウ８０２に表示され得る。選択されたアイテムと関連するオプションまたは修飾子が、発注ページ８００のオプションウィンドウ８０４に表示され得る。ユーザがアイテムを選択し終えたら、ユーザは、「次へ」オプション８０６を選択して、メニューに戻り、他のアイテムを注文に加えることができる。ユーザが選択したアイテムを注文から削除するか、または選択したアイテムに関連する選択された修飾子を削除することを望む場合、ユーザは、望ましくないアイテムまたは修飾子に関連する、削除オプション８０８を選択することができる。ユーザがアイテムを選択し終えたら、ユーザは、「注文する」オプション８１０を選択して、注文を注文履行システム１０４に送ることができ、注文履行システム１０４は、レストランの環境ではキッチンであってよい。「注文する」オプションを選択した後、支払ページ、例えば、図９Ａに示す支払ページ９００が、表わされ得る。ユーザがタッチスクリーンをタップするか、もしくはマウスをクリックすること、所望されるような任意の他の適切な手段によって、選択を行い得ることが、理解されるであろう。
【００２９】
図８Ｂを参照して、選択されたメニューアイテムが、修飾子の選択を必要とする場合、修飾子リマインダー８１２が表示され得る。例示された例として、ユーザがサンドイッチを選択した場合、ユーザがサンドイッチの中身を選択するまで、修飾子リマインダー８１２が表示される。別の例として、ユーザが１２個のベーグルを選択した場合、ユーザがベーグルの種類を選択するまで、修飾子リマインダー８１２が表示される。場合によっては、要件を満たした後、または修飾子を必要とする、選択されたメニューアイテムが削除された後、修飾子リマインダー８１２はもう表示されなくなる。図８Ｃを参照して、例としての実施形態によると、ユーザは、管理メッセージボックス８１４を介して、メッセージを、スタッフ、例えば管理者に、送信することができる。ユーザは、文字が制限された、例えば１４０文字のメッセージを入力することができる。管理メッセージボックス８１４に文字制限がないように構成され得るか、または管理メッセージボックス８１４が所望のとおりに任意の適切な文字制限を有するように構成され得ることが、理解されるであろう。ほんの一例として、客または職員などのユーザが、管理メッセージボックス８１４に命令を入力することができる。このような命令は、注文または客に関する好みを含み得る。ユーザは、送信オプション８１６を選択して、命令を注文履行システム１０４に送信することができる。ある実施例では、管理メッセージボックス８１４は、ユーザが例えばタップすることで、ヘッダー８１８を選択したときに、示され得る。
【００３０】
次に図９Ａを参照して、「注文する」オプション８１０を介して注文を行った後、支払ページ９００が表示され得る。支払ページ９００は、ユーザに支払いの選択肢を提示し得る。例示された実施例によれば、支払いの選択肢には、割引オプション９０２、現金オプション９０４、クレジットカードオプション９０６が含まれる。任意の適切な支払いオプションが、所望のとおりに支払ページ９００の一部として含まれ得ることが、理解されるであろう。図９Ｂを参照して、ユーザが現金オプション９０４を選択すると、現金ページ９０８が表示され得る。現金ページ９０８は、ユーザ、例えば職員が、客から受け取った現金の額を手入力できるように、数字を表示し得る。現金が入力されると、ユーザは、勘定書終了オプション（close check option）９１０を選択することができ、これにより、レジスターが開き、釣銭の額９１２がスクリーン上に示され得る。レジスターが開くと、職員は、釣銭の額９１２に表示された釣銭を出し、これによって取引を終えることができる。
【００３１】
図９Ｃを参照すると、場合によっては、実施例に示すように、客が出した現金の額９１４が、合計料金９１６を満たしていないか、またはこれを超えない。このような場合、図９Ｄに示すボックス９１８などの金額不足ボックス９１８が表示され得る。ボックス９１８は、客がクレジットカードで、支払うべき残りの金額を支払いたいかどうか尋ねることができる。ユーザが「はい」のオプション９２０を選択すると、クレジットページ９２４が表示され得る（図９Ｅ参照）。さらに、レジスターの扉（register door）が、現金を入れられるように開くことができ、職員は、客のクレジットカードを読み取り機に通して、残りの差額の責任を取る（account for）ことができる。クレジットページ９２４は、クレジットオプション９０６が選択された場合に表示されることもできる。図９Ｅを参照すると、チップボックス９２６を介してチップを入力することができる。ある実施例では、チップは、クレジットカードに適用され得る。チップが受け取られると、ユーザは、入力オプション９２８を選択でき、これに応じて、レシートが作成され得る。
【００３２】
図９Ｆを参照して、ユーザが割引オプション９０２を選択すると、割引ページ９３０が表示され得る。割引オプション９０２は、客の注文に対して割引を適用するため、職員によって選択され得る。図示のとおり、例示された実施例に従って、ユーザは、現金割引またはパーセント割引を適用することができる。入力オプション９３２が選択されると、割引が請求額に適用されて、新しい総額が出る。
【００３３】
次に図４を参照して、発注システム１０２を用いて注文を行った後、その注文は、注文履行システム１０４を用いて履行されることができる。例示された実施形態に従って、注文履行システム１０４は、メッセージングサーバ１１４ａを介して互いと通信する、１つ以上の準備ステーション１１８と、承認ステーション１２０と、配達ステーション１２２と、を含み得る。例としての実施形態では、通信は、エクステンシブル・メッセージング・アンド・プレゼンス・プロトコル（ＸＭＰＰ）の「チャットルーム」環境で実行される。システム１０４は、やはりメッセージングサーバ１１４ａを介して通信する、一人以上のユーザ、例えば、客１１６ａおよびマネージャー１１６ｂのコンピューティングデバイス１１２をさらに含み得る。準備ステーション１１８、承認ステーション１２０、配達ステーション１２２は、所望のとおりに任意の数のコンピューティングデバイス１１２を含み得る。図４は、例えば、レストランの中、または空港の中にいるかもしれない客１１６ａによって行われた注文などの注文を履行するための、適切な通信アーキテクチャの一例を描いており、多くの適切な代替的通信アーキテクチャが構想されることが認識される。例としてのシステム１０４が、開示される主題の説明を容易にするよう単純化されており、かつ本開示の範囲を制限することを意図していないことが、さらに認識されるであろう。システム１０４に加えて、またはシステム１０４の代わりに、他のデバイス、システム、構成を使用して、本明細書に開示する実施形態を実行することができ、そのような実施形態はすべて、本開示の範囲内として考えられる。
【００３４】
さらに図４を参照して、例としての実施形態によると、客１１６ａがコンピューティングデバイス１１２を介して注文を行った後、その注文は、サーバ１１４ａに送信され得る。所望のとおりに、任意の数のコンピューティングデバイス１１２がシステム１０４内にあってよく、コンピューティングデバイスはそれぞれ、独自に識別可能であってよいことが、理解されるであろう。一実施形態では、例えば注文などのメッセージは、ジャバスクリプト・オブジェクト・ノーテーション（ＪＳＯＮ）形式で送られる。例えば客のデバイスおよび／または配達ステーションのデバイスといった、クライアントは、それらの物理的位置を定期的に送ることができる。注文が履行プロセスを経て進行するにつれて、客１１６ａおよびマネージャー１１６ｂは、彼らのデバイス１１２に送信されたメッセージを介して、注文の状況の通知を受けることができる。例えば、サーバ１１４ａは、注文の状況が変化すると、コンピューティングデバイス１１２に警報を送信することができる。例としての態様では、注文がサーバ１１４ａによって受信されると、サーバ１１４ａは、注文の一部または注文全体に関連する所定の時間制限を特定することができる。所定の時間制限は、図１０を参照して以下で説明する設定ページ１０００を介して設定され得る。所定の時間制限は、注文が行われたときに所定の時間制限がサーバ１１４ａに送信されるよう、クライアントデバイスにおいてカスタマイズされ得る。例えば、複数のデバイス１１２が、同期化された動的データモデルを介してグループ化され得る。よって、グループ化されたデバイス１１２は、互いと交換可能であってよい。注文が所定の時間制限より遅れると、準備ステーション１１８および／または配達ステーション１２２にいるスタッフは、注文が時間すれすれである（nearly late）か、または予定より遅れている（running late）という通知を受けることができる。よって、スタッフは、状況の通知を受けることができ、かつ適切な行動をとることができる。
【００３５】
例としての実施形態によると、注文がサーバ１１４ａによって受信されると、サーバ１１４ａは、その注文を準備すべき、準備ステーション１１８のうちの１つを特定することができる。例えば、注文がアルコール飲料に対するものである場合、特定される準備ステーション１１８は、バーであるかもしれない。さらなる実施例として、注文がハンバーガーに対するものである場合、サーバ１１４ａは、グリルにあるコンピューティングデバイス１１２に注文を送信することができる。さらに、注文がサーバ１１４によって受信されると、その注文は、「初期」状態とされ得る。初期状態にある、注文、特に注文されたアイテムは、準備ステーション１１８で表示され得る。例としての実施形態では、準備ステーション１１８にあるコンピューティングデバイス１１２は、それらの注文をフィルタリングして、特定の準備ステーションによって準備され得るアイテムのみを、特定の準備ステーションによって表示する。例えば小売のアイテムなど、準備を必要としないアイテムは、この初期状態を飛ばして、以下で説明する準備承認済状態に向かって進むことができる。
【００３６】
アイテムが準備ステーション１１８で準備された後、アイテムの状況が「準備済み」であることを示すメッセージが、準備ステーション１１８にあるコンピューティングデバイス１１２からサーバ１１４ａへと送信され得る。場合によっては、準備ステーション１１８は、アイテムを承認のため承認ステーション１２０に送ることができる。他のアイテムは承認を必要としないので、承認ステーション１２０には送られない。アイテムが承認ステーションで承認されると、承認ステーションにあるコンピューティングデバイス１１２からサーバ１１４ａへとメッセージが送られ得る。このメッセージは、アイテムの状況が「準備承認済み」であることを示すことができる。アイテムがこの状態に到達すると、サーバ１１４ａは、アイテムが集荷の準備ができたという指示を、配達ステーション、特に配達ステーションのモバイルデバイス１１２に、送ることができる。例としてのレストランの設定では、配達ステーション１２２にあるモバイルデバイス１１２は、給仕人によって使用され得る。例としての実施形態では、配達ステーション１２２にあるコンピューティングデバイス１１２は、注文をフィルタリングし、特定の配達ステーションによって配達され得るアイテムのみを、特定の配達ステーションと関連するデバイスにより表示する。よって、モバイルデバイス１２２は、モバイルデバイス１２２のユーザが配達するエリアに関する注文のみを示すことを可能とする、フィルターを有し得る。配達ステーション１２２の一部であるデバイス１１２のユーザのうちの一人は、アイテムを配達する責任を負うために、デバイス１１２においてオプションを発動させることができる。その発動に応じて、メッセージがサーバ１１４ａに送信され得る。メッセージは、アイテムの状況が「配達中」であることを示すことができる。例としての実施形態では、位置特定器具が、配達者の位置をモニタリングするのに使用され得る。よって、客１１６ａのデバイス１１２は、例えば、誰がアイテムを配達しているのか、また、予想配達時刻など、配達に関連するさまざまな情報を受信することができる。
【００３７】
さらに図４を参照すると、アイテムが配達された後、その配達に関連するモバイルデバイス１１２は、配達が完了したことを示すメッセージをサーバ１１４ａに送信する。よって、サーバ１１４ａは、アイテムの状況を、「完了」に設定することができる。例えば前述した状況それぞれに関連する時間などの、配達情報は、所望のとおりに、任意の時間にサーバ１１４ａで保存され得る。例えば、情報をアーカイブに入れる時間制限が過ぎた後、注文情報は、例えばクラウドに、移動されて、サーバ１１４ａおよび／または注文履行システム１０４のデバイス１１２上のリソースを空いた状態にすることができる。例としての実施形態によると、所与のアイテムが前述した注文履行状態のうちのいずれかである間、そのアイテムは、撤回されるか、または、その前の状態に送り返されて、問題に取り組むことができる。デバイス１１２のうちの１つから、通知が送信されることができ、サーバ１１４ａは、適切なステーションに警報を広めることができる。例えば、撤回された注文は、注文が撤回されるか、または問題を抱えていることをスタッフに示す、視覚的警報で表示され得る。さらに、任意の時点で、客１１６ａは、サーバ１１４ａにサービスのリクエストを送信することができる。サーバ１１４ａは、客１１６ａが補助され得るように、そのリクエストを適切なデバイス１１２に広めることができる。例としての実施形態では、ルールエンジン１０８は、近接器具（proximity instrument）を用いて、どのデバイス１１２が客１１６に最も近いかを判断する。ルールエンジン１０８は、所与のデバイス１１２が客１１６に最も近いことをサーバ１１４ａに通知することができる。よって、サーバ１１４ａは、客１１６ａに最も近いデバイス１１２にサービスのリクエストを送信することができ、これにより、客の迅速な補助を確実にする。
【００３８】
次に図１０を参照すると、前述したとおり、例としての設定ページ１０００を使用して、注文履行システム１０４、例えば、レストランの環境でのキッチン、を設定することができる。図示のとおり、設定ページ１０００は、所望のとおりに任意のステーションタイプを設定するのに使用され得ることが、理解されるであろう。一実施例では、ユーザ、例えばマネージャーは、前述した所定の時間に対応する時間１００２を入力することができる。ほんの一例として、ユーザが時間１００２に６０分と入力すると、６０分が、注文が遅れているかどうかを判断するための所定の時間制限となる。よって、引き続きこの実施例を見ると、６０分が経過して、注文が客に配達されていない場合、準備ステーション１１８および／または配達ステーション１２２のスタッフは、注文が遅れていると通知を受けることができる。例えば、図１１を参照して、注文が遅れているか、または延着した場合、例としてのステータススクリーンページ１１００は、遅れた注文を、遅れていない注文とは異なる色で示すことによって、注文が遅れているか、または延着したと、示すことができる。所望どおりの任意のインジケータ（視覚的インジケータ、可聴インジケータなど）が、注文が遅れていることを示すのに使用され得ることが、理解されるであろう。同様に、ステータススクリーンページ１１００は、撤回したアイテムを、他のアイテムとは異なる色で示すことによって、または、所望のとおりに任意の他の適切な表示を介して、撤回したアイテム（キャンセルした注文）を示すことができる。さらに、もう少しで延着となる注文は、それらの注文が手早く処理され得るように、ステータススクリーンページ１１００によって表示され得る。図示のとおり、各注文は、テーブル番号１１０２および座席番号１１０４に従って表示され得る。さらに、図示のとおり、各注文は、注文に関連する時間１１０６を有し得る。この時間１１０６は、注文が行われてから経過した時間の長さを示すことができる。
【００３９】
再び図１０を参照すると、例としての設定ページ１０００は、所望のとおりに注文履行システムの他のパラメータを設定するのに使用されることもできる。例えば、ユーザは、それぞれの注文が、ユーザによって設定されることもできる、ある時間以内に行われた場合に、テーブルが自動的に互いに結合されるように、「テーブル自動結合」オプションを選択することができる。ほんの一例として、その時間が１０秒に設定されている場合、注文が互いから１０秒以内に行われたテーブルは、互いに組み合わせられて、それらのテーブルは、１つのカスタマーエクスペリエンスとして扱われる。これは、例えば、一人の人が２つ以上のテーブルの注文について支払いを行う場合に、有用となり得る。ユーザが所望のとおりに「テーブル自動結合」オプションを有効または無効にし得ることが、理解されるであろう。図示のとおり、設定ページ１０００は、「空間確保設定（Hold Room Config）」オプションも含み得る。このオプションは、選択されると、注文ライフサイクル（ordering lifecycle）のすべての段階における全アイテムの全体的な眺望を表示することができる。この「空間確保設定」オプションは、所与のアイテムがどの段階にあるかにかかわらず、伝票上注文されているアイテムをマネージャーが見ることができるので、管理に有用となり得る。一実施例では、異なる段階が異なる色で表わされ、マネージャーは、どのアイテムが配達されたか、どのアイテムが予定どおりであるか、どのアイテムが予定より早い、もしくは予定より遅れているか、を効率的に判断することができる。
【００４０】
次に図１２を参照すると、他の例としての注文が、別の例としてのステータススクリーンページ１２００によって表示されている。ほんの一例として、レストラン環境では、注文がテーブルに運ばれる準備ができたら、ユーザは、ステータススクリーン１２００上の注文をダブルタップしてよく、これにより、注文を取りに行って運ぶべきであることが、サーバに示され得る。あるいは、例としての実施形態によると、ユーザは、ステータススクリーン１２００上の注文をシングルタップして、注文内の個々のアイテムが運ばれる準備ができたことを示すことができる。例えば、ユーザが注文をシングルタップすると、個別アイテムページ１３００（図１３）が表示され得る。個別アイテムページ１３００は、選択された注文における各アイテムを含み得る。準備ができている所与のアイテムと関連する、販売オプション１３０２を選択することにより、サーバは、所与のアイテムが運ばれる準備ができたことを通知され、そのアイテムは、ステータススクリーン１２００から消えることができる。例としての実施形態によると、ユーザは、「すべてを販売」オプション１３０４を選択して、注文全てが運ばれる準備ができたことをサーバに通知することができ、注文すべてがステータススクリーン１２００から消えることができる。図１４も参照すると、例としてのステータススクリーンページ１４００は、送信（submission）から配達までの任意の状況を有するすべての注文を表示する。よって、ユーザは、どの注文がオープンである（準備もしくは配達されていない）か、どの注文がキッチンによってタップされ「オフ」になっているか、どの注文が給仕人（ウェイター）のうち一人のデバイスによってタップされ「オフ」になっているかを、判断するために、ステータススクリーン１４００を見ることができる。注文は、それに関連する異なる状況を示すために、ステータススクリーン１４００によって異なる色で表示され得る。
【００４１】
前述のとおり、１つ以上の準備ステーション１１８、承認ステーション１２０、配達ステーション１２２は、メッセージングサーバ１１４ａを介して互いと通信することができる。例としてのレストランでの実施に関して、マネージャーは、デバイス１１２を使用して給仕人と通信するのに、承認ステーション１２０を使用することができる。場合によっては、給仕人は、テーブルを管理するためにデバイス１１２を使用する。図１５Ａを参照すると、例としてのテーブルページ１５００が図示されている。テーブルページ１５００は、さまざまなテーブルを表示する。図示のとおり、テーブルは、番号が付けられているか、または別様に識別されることができる。例示された実施例によると、ユーザ（例えばウェイター）は、テーブルページ１５００上でテーブル６１を選択し、支払オプション１５０２を選択して、テーブル６１の伝票をクローズすることができる。チェックマーク１５０４などの表示は、所与のテーブルで表示されて、その所与のテーブルが未精算の注文と関連していること、および、所与のテーブルと関連する勘定が支払われていないことを示すことができる。図１５に描かれた例示された実施例によると、テーブル２２、２４、６１は、それらに関連した未精算の注文を有する。場合によっては、ユーザは、テーブル編集オプション１５０６を選択して、テーブルを追加したり、割り当てられたセクションからテーブルを除外したりすることができる。ユーザは、テーブルが既に関連した注文を有しているかどうかにかかわらず、アイテムをテーブルの勘定書に追加するよう、注文開始オプション１５０８を選択することができる。
【００４２】
図１６は、第１のユーザに特化した、別の例としてのテーブルページ１６００を描いている。例示された実施例によると、テーブル２１〜２７は、第１のユーザとは異なるユーザに割り当てられているので、テーブル２１〜２７は、第１のユーザと関連するテーブルページ１６００上には現れない。第１のユーザに割り当てられているテーブルは、テーブルページ１６００上で第１の色で表示され、示されることができ、どの人にもデバイス１１２にも割り当てられていないテーブルは、テーブルページ１６００上で第２の色で表示され示されることができる。例示された実施例によると、テーブル６１〜６７、７１は、第１のユーザに割り当てられ、例示されたテーブルのうち残りのものは、割り当てられていない。割り当て済みのテーブル、および割り当てられていないテーブルは、所望のとおりに任意の適切な視覚的インジケータによって示され得ることが、理解されるであろう。
【００４３】
例としての実施形態によると、ユーザ（例えば職員）は、発注システム１０２を用いて客の注文を入力することができる。例えば、図１７を参照して、職員は、コンピューティングデバイス１１２上で例としてのメニューページ１７００を見て、あるテーブル（例えばテーブル１１４）に特化した注文を入力することができる。場合によっては、メニューページ１７００は、注文開始オプション１５０８が選択された後で、デバイス１１２上に与えられる。さまざまなメニューアイテム１７０２が、メニューページ１７００上に表示され得る。選択された特定のメニューアイテムが、変更される能力を有するか、またはそれに関連した選択肢を有する場合、そのメニューアイテムが選択された後で修飾子ページ１８００（図１８を参照）が表示され得る。修飾子ページ１８００は、ユーザが、選択されたメニューアイテムに関連した選択を行うのを促すことができる。修飾子ページ１８００は、注文されているメニューアイテムの数量を変更する数量オプション１８０２を含み得る。メニューアイテムに関連した修飾子が選択された後、ユーザは、入力オプション１８０４を選択して、そのアイテムを勘定書に追加することができる。入力オプション１８０４を選択した後で、提案ボックス１９００が表示され得る。ほんの一例として、提案ボックス１９００は、注文と関連する客が特別な注意を必要とすること（例えばＶＩＰ）を示すのに使用され得る。提案ボックスは、準備ステーション１１８（例えばキッチン）に特別な指示を提供するのにも使用され得る。任意の提案が入力された後、伝票ページ２０００（図２０を参照）が表示されるように、「次へ」オプション１９０２が選択されてよい。
【００４４】
図２０を参照して、例としての伝票ページ２０００は、テーブル２４の例としての注文と関連している。伝票ページ２０００は、各アイテムと関連する状況を示すことができる。例えば、伝票ページ２０００は、各アイテムが準備ステーションに送られているかどうかに応じて、異なる色でアイテムを表示することができる。例えば、図２０を参照して、「フルーツデニッシュ」というアイテムが、赤で表示されて、キッチンに送られていることを示すことができ、「コカコーラ」というアイテムが、黒で表示されて、キッチンにまだ送られていないことを示すことができる。例としての実施形態では、ユーザは、アイテムに関連するオプション（例えばオプション２００２、２００４、２００６）が表示されるように、例えば、アイテム上でスワイプすることによって、キッチンに送られていないアイテムを編集することができる。ユーザは、アイテムを見かけどおり正確に２倍にするよう、２倍オプション２００２を選択することができる。すなわち、２倍オプション２００２は、アイテムの数量を１個から２個に変更することができる。ユーザは、準備ステーション１１８に送られていないアイテムと関連する数量または修飾子を変更するために、編集オプション２００４を選択し得る。ユーザは、アイテムを注文から削除（キャンセル）するために、削除オプション２００６を選択することができる。場合によっては、ユーザは、店内で食事をするオプション２００８、または持ち帰りオプション２０１０を選択して、キッチンにしかるべく通知することができる。注文の準備ができたら、ユーザは、「キッチンに送信」オプション２０１２を選択し、その注文を準備ステーション１１８に送信することができる。場合によっては、図２１を参照して、コースライン２１０２がドラッグアンドドロップされて、所望のとおりにコースを分割することができ、個々のアイテムは、アイテムが表示される順番を変更するために、ドラッグアンドドロップされ得る。よって、例えば、キッチンは、客が特定した順番でアイテムを見ることができるので、適切なコース中にアイテムを運ぶことができる。ある実施例では、アイテムの順番を変更するか、またはコースライン２１０２を動かすために、交換オプション２１０４が選択される。
【００４５】
図２２Ａを参照して、ユーザがどのようにしてテーブルを組み合わせることができるのかという実施例を説明するために、別の例としてのテーブルページ２２００が図示されている。ユーザは、テーブル組み合わせオプション２２０２を選択し、その後、互いに組み合わせられるべきテーブルを選択することができる。テーブルページ２２００は、例えば、注文がそれらのテーブルで行われていないために、組み合わせることのできないテーブルを示すことができる。例示された実施例によると、テーブル４５および４６が、それらと関連するチェックマークによって示されるように、互いと組み合わせられるよう選択される。テーブルが選択された後、ユーザは、結合オプション２２０４を選択して、組み合わせを実現することができる。場合によっては、組み合わせのために選択された第１のテーブルは親テーブルであり、選ばれたその他のテーブルの勘定書が、この親テーブルの勘定書に組み合わせられる。図２２Ｂを参照して、例示された実施例によると、テーブル４５が最初に選択されているので、テーブル４６の勘定書が、テーブル４５の勘定書へと組み合わせられる。図示のとおり、結合後、チェックマークは、親テーブルではない、結合されたテーブル（テーブル４６）から消えることができる。アイテムは、親テーブル（テーブル４５）を選択し、前述したように、注文開始オプション２２０６を選択することによって、結合された勘定書に追加され得る。
【００４６】
図２３を参照して、例としての勘定書分割ページ２３００が図示されている。ユーザは、勘定書を分割するために分割オプション２３０２を選択し得る。場合によっては、分割オプション２３０２がいったん選択されると、勘定書は、可能な限り均等に２つの勘定書へと分割される。ある実施例によると、勘定書を分割するために、１本以上の分割線２３０４が表示され得る。分割線２３０４は、どのように勘定書を分割するかを変更するために、ドラッグアンドドロップされ得る。ユーザは、個別の勘定書をそれぞれ見るために、クレジットオプション２３０６を選択し得る。例としての勘定書ページ２４００が図２４に示されている。勘定書インジケータ２４０２は、どの勘定書が表示されているかを示している。例示された実施例によると、勘定書インジケータ２４０２は、「３」であり、これは、表示された勘定書が３番目の勘定書であることを示す。ユーザは、客のために個別のレシートをそれぞれ印刷するため、印刷オプション２４０４を選択し得る。ユーザは、所与の注文と関連する勘定書をすべてスクロールするために、次の勘定書オプション２４０６を選択し得る。
【００４７】
例としての実施形態では、コンピューティングデバイス１１２は、ユーザ（例えばマネージャー）がさまざまなレベルの金銭上および営業上の情報を見ることができるように、ダッシュボード２５００（図２５を参照）を示し得る。ほんの一例として、マネージャーは、返金、メニューの更新、オーバーライド（overriding）など、さまざまな動作を行うことができる。
【００４８】
図２５を参照して、業務履行システム１０４と関連し得る、例としてのダッシュボード２５００が図示されている。図示のとおり、ユーザは、特定の勘定書を探すために、「勘定書を見つける」オプション２５０２を選択し得る。ダッシュボード２５００を使用して、ユーザは、図２６に描かれた販売報告ページ２６００などの販売報告ページを選択し得る。ユーザは、全日、１時間、または所望どおりの任意の特定された時間の、販売報告を選択することができる。ユーザは、データ日付オプション（data from option）２６０２におけるデータを選択することにより、１日を選択し得る。図示のとおり、実施例によると、販売報告ページ２６００は、２０１５年８月２６日の販売報告を示している。ユーザは、比較対象オプション（compare to option）２６０４で日付を選択することができ、比較対象オプション２６０４に対応する日付の販売が、データ日付オプション２６０２に対応する日付の販売と比較される。例えば、図示のとおり、差が、総数によって、またはパーセンテージの差によって、表示され得る。メインメニューオプション２６０６は、この報告をＥメール形式で送るために、選択され得る。ユーザは、例えば、価格、販売数量、特定の期間内のアイテムの販売により得られた収入など、特定のアイテムと関連するさまざまな属性を示すため、製品ミックスオプション２６０８を選択し得る。
【００４９】
図２７を参照して、例としての返金ページ２７００が描かれている。返金ページ２７００は、終了した任意の勘定書に対応し得る。ユーザは、返金してもらう個々のアイテムを選択し得る。例えば、返金のために選択されたアイテムは、返金ページ２７００上のチェックマークによって示され得る。どのアイテムを返金してもらうかユーザが選択した後で、ユーザは、確認オプション２７０２を選択でき、そうすると、理由ページ２８００（図２８を参照）が表示され得る。理由ページ２８００は、返金のさまざまな理由を表示し得る。場合によっては、ユーザは、理由を選択することが必要となる。ユーザは、返金に進む前に、返金の理由を選択するよう促される場合がある。図２９Ａを参照して、例としての無効ページ２９００が図示されている。返金ページ２７００とは対照的に、無効ページ２９００は、未精算である（支払われていない）任意の勘定書に対応し得る。ユーザは、無効にする個々のアイテムを選択し得る。ユーザがどのアイテムを無効にするか選択した後、ユーザは、確認オプション２９０２を選択し得る。これに応じて、ユーザは、理由ページ２８００を介して、無効にする理由を選択することが必要となる場合がある。理由を選択し、確認オプションを選択した後、無効確認２９０４が、表示され得る（図２９Ｂを参照）。図３０を参照すると、例としての割引ページ３０００が描かれている。割引ページ３０００は、未精算である（支払われていない）任意の勘定書に対応し得る。ユーザは、勘定を割引するパーセンテージを選択し得る。例としての割引ページ３０００には５０％および１００％と示されているが、割引額はこれらのパーセンテージに限られておらず、よって、任意の割引が、所望のとおりに表示され選択され得ることが、理解されるであろう。ユーザが割引額を選択した後、ユーザは、理由ページ２８００を介して割引理由を選択することが必要となる場合がある。
【００５０】
次に未精算勘定の例外（例えば、無効、割引、チップの調整）のキャンセルを見ると、ユーザは、メニューページ３１００のキャンセルオプション３１０２を選択し得る（図３１Ａを参照）。図３１Ｂを参照して、例外のリスト３１０４が、例外キャンセルページ３１０６に表示され得る。ユーザは、キャンセルされるべき例外をリスト３１０４から選択し得る。これに応じて、キャンセル理由ボックス３１０８が表示され得る（図３１Ｃを参照）。ユーザは、キャンセル理由を選択することが必要となる場合がある。
【００５１】
例としての実施形態によると、ユーザは、さまざまなメカニズムを介して特定の注文を見つけることができる。例えば、図３２を参照して、ユーザが日中報告、および注文閲覧をメインメニューから選択すると、注文閲覧ページ３２００が表示され得る。注文閲覧ページ３２００は、その日の注文を表示する。あるいは、ユーザは、（注文閲覧ページ３２００の検索バー３２０２を用いて）キーワード（例えばテーブルＩＤ、注文ＩＤ、特定の注文に関連する価格など）を検索バー３２０２に入力することによって、その注文を検索することができる。あるいは、ユーザが物理的なレシートを持っている場合、ユーザは、レシートから勘定書番号を、勘定書発見ページ３３００に入力することができる（図３３を参照）。さらに、ユーザは、勘定書発見ページ３３００上のホイール３３０２をスクロールして、その勘定書に関連する適切な日付を選択することができる。図３４を参照して、ユーザは、マスターメニューページ３４００を見て、メニューに変更を加えることができる。例えば、ユーザは、非アクティブ化オプション３４０２を選択することによりアイテムを非アクティブ化するか、価格更新オプション３４０４を選択することにより価格を更新するか、またはアイテムをメニューに追加することができる。ユーザはまた、マスターメニューページ３４００を使用して、各アイテムに関連した販売および価格ランキングを見ることができる。
【００５２】
次に図５を参照して、例示された実施形態によると、セルフペイメントシステム１０６は、客が使用するコンピューティングデバイス１１２と通信し得る、注文処理デバイス１２６を含み得る。図５は、例えば、レストランまたは空港内にいるかもしれない客が行った注文などの注文の支払いを行う適切な通信アーキテクチャの一例を描いており、数多くの適切な代替的通信アーキテクチャが構想されることが、認識される。例としてのシステム１０６は、開示される主題の説明を容易にするために単純化されていて、本開示の範囲を制限することは意図していないことが、さらに認識されるであろう。システム１０６に加えて、またはこれの代わりに、他のデバイス、システム、設定を使用して、本明細書に開示する実施形態を実行することができ、それらの実施形態はすべて、本開示の範囲内であることが企図されている。
【００５３】
客は、携帯式有線もしくは無線発注デバイスであってよい、デバイス１１２のうちの１つから、アイテムを仮想ショッピングカートに追加し、その追加したアイテムの注文を行うために、セルフペイメントシステム１０６を使用し得る。注文は、注文処理デバイス１２６によって受信され得る。注文処理デバイス１２６は、さまざまな通信、例えば、クレジットカードスワイプ／読取デバイスを含み得る、１つ以上の支払入力デバイス１２８とのすべての通信を制御およびモニタリングすることができる。注文処理デバイス１２６はまた、図５を参照して以下で説明する注文プロセスなど、取引中に生じた問題を自動的に検出および修正することができる。注文処理デバイス１２６はまた、注文処理中の正しい時間に確実に他のデバイスおよびサービスと情報をやり取りすることもできる。注文処理デバイス１２６は、スタンドアロンの単一取引デバイス（single transactional device）であってよい。あるいは、注文処理デバイス１２６は、例えば、複数のクレジットカードスワイプ／読取デバイスを支えるために、例えばＵＳＢハブ１３０などの追加デバイスと統合されてよい。
【００５４】
引き続き図５を参照すると、例としての注文処理が描かれている。例示された実施例によると、客は、デバイス１１２を使用して、アイテムを選択し、彼／彼女の仮想ショッピングカートに追加する。５０２で、客は、注文を送信する。注文は、コンピューティングデバイス１１２から注文処理デバイス１２６に送られ得る。５０４では、例示された実施例によると、注文処理デバイス１２６は、任意の利用可能なクレジットカードスワイプ／読取デバイスであってよい、支払入力部１２８への通信を始めることができる。５０６で、客は、例えば支払入力部１２８でクレジットカードをスワイプすることによって、支払いを提示するように通知され得る。注文処理デバイス１２６は、支払入力部１２８からクレジットカード情報を受信することができる。５０８で、注文処理デバイス１２６は、確実にクレジットカード情報を扱うことができる。複数の注文処理デバイス１２６がシステム１０６内にある、例としての設定では、１つ以上のサーバ１１４は、５１０において、市場のトレンド、潜在的な体系的問題を識別するため、または他の分析目的で、成功および不成功の取引のログをとることができる。例えば、サーバ１１４は、データベース１３４で、取引に関連する歴史的および分析的情報を記憶させ回収することができる。例としての実施形態では、例えばクレジットカード番号などの個人情報は、注文処理デバイス１２６では記憶されない。代わりに、５１２で、クレジットカード情報は、注文処理デバイス１２６から、インターネットであってよいネットワーク１１０を介して、クレジットカード支払プロセッサ１３２へと送信され得る。５１４では、プロセッサ１３２により承認されると、承認メッセージが、プロセッサ１３２から、ネットワーク１１０を介して、注文処理デバイス１２６へと送信され得る。５１６で、注文処理デバイス１２６は、支払が成功したことを客に通知することができ、デバイス１１２と注文処理デバイスとの間の接続は、さらなる通信から切断され得る。５１８では、例示された実施例によると、注文処理デバイス１２６は、仮想ショッピングカート情報を、例えばレストランのキッチンにあるコンピューティングデバイスなどの、注文履行出力デバイス１３６に送ることができる。５１８で、注文処理デバイス１２６は、仮想ショッピングカート情報をプリンタ１３８に送ることもでき、客のレシートを印刷することができる。例としての実施形態では、例えばクレジットカードの最後の４ケタなど、限られた客の情報が、出力デバイス１３６およびプリンタ１３８に送られる。さらに、複数の注文処理デバイス１２６がシステム１０６内部にある、例としての設定では、注文処理デバイス１２６は、５２０で、仮想ショッピングカート情報をサーバ１１４に送って、例えば、より高容量の要求に取り組むことができる。
【００５５】
概して図１および図２を、特に図７Ａおよび図７Ｂを参照して、リコメンデーションエンジン１０８ａを、例としての実施形態に従って、詳細に説明する。リコメンデーションエンジン１０８ａは、客のデバイス１１２に、具体的にはクライアントアプリケーションに、客が購入するよう提案されるアイテムを供給することができる。リコメンデーションエンジン１０８ａは、客が購入した以前のアイテムによって決定されるような、購入される可能性が高いメニュー内のアイテムであってよい、アップセルを勧めることによって、販売を増やすことができる。エンジン１０８ａは、所望の基準に従って、所定の数のお勧めを返すことができる。例としての基準には、食事の状況（例えば完了）、フライトの目的地履歴、アイテム制限（ベジタリアン、子供など）、アイテム購入履歴、お勧め実行履歴が含まれるが、これらに制限されない。よって、客に関連する注文履歴、メニュー、および設定が、リコメンデーションエンジン１０８ａによって受信され得る。例としての実施形態によると、設定とは、メニューアイテムがどのようにして組織化されるかを指す。アイテムは、１つのカテゴリー、またはカテゴリー群において、表示され得る。アイテムは、例えばアントレーまたは前菜など、スロット（slot）と関連していてもよい。
【００５６】
図２および図８Ａ〜図８Ｃを参照して説明したように、例えば、客は、発注システム１０２の例としてのレストランでの実施において、メニューを見ることができる。メニューは、勧められていないアイテムと比べて、ユーザのデバイス１１２上でより顕著に表示される、リコメンデーションエンジン１０８ａによって勧められたアイテムを含み得る。リコメンデーションエンジン１０８ａは、客の注文履歴へのアクセスを有し得る。注文履歴は、特定の客によって注文されたアイテム、特定の時間に注文された最もポピュラーなアイテム、特定のレストランで注文された最もポピュラーなアイテムなど、または、それらの任意の適切な組み合わせを含み得る。リコメンデーションエンジン１０８ａは、１つ以上のストラテジー７００を含み得る。ストラテジー７００は、どのアイテムがアップセルとして特定のユーザに提示されるかを決定する、１つのアルゴリズム、または１組のアルゴリズムであってよい。複数のストラテジー７００が、一度に実行され得る。
【００５７】
ある実施例では、特に図７Ｂを参照して、マニュアルアップセル７０１が実行される。例としてのマニュアルアップセルの実行では、アイテムが、特定のメニューアイテムのアップセルとして提示されるように予め選択される。例えば、客が７０４でアイテムを選択し、それを仮想カートに追加したら、客のデバイス１１２、特にクライアントアプリケーションが、選択されたアイテムと関連するアイテム（アップセル）について、サーバ１１４（例えば図２を参照）に問い合わせをすることができる（７０６）。７０８で、選択されたアイテムと関連するとして予め選択されたアップセルは、客によって購入されるよう、スロットレイアウトで表示され得る。
【００５８】
さらに図７Ｂを参照して、別の実施例では、重み付き無作為抽出ストラテジー７０３が、リコメンデーションエンジン１０８ａによって実行される。例えば、７０８で、所与の客が、アイテムを選択し、選択されたアイテムを仮想カートに追加する。７１０で、利用可能なアイテムが、アクティブなメニュー、そのアイテムと関連するカテゴリー、およびスロットレイアウトに基づいて決定される。所与の客がアイテムを選択し、選択されたアイテムを仮想カートに追加すると、客のデバイス１１２、特にクライアントアプリケーションが、選択されたアイテムと共に以前注文された他のアイテムについて、サーバ１１４（例えば図２を参照）に問い合わせすることができる。サーバ１１４は、所与の客と同じフライトに搭乗している客がどのアイテムを以前に購入したかを決定するようさらに問い合わせされ得る。サーバ１１４は、その問い合わせに答えることができ、そのため、問い合わせにマッチする１つ以上のアイテムを特定することができる。問い合わせでマッチしたアイテムは、ランク付けまたは重み付けされ得る。ほんの一例として、無制限に、マッチしたアイテムは、アイテムが他のアイテムと共に注文された頻度および／またはアイテムが特定のフライト目的地に関連する客により注文された頻度に従って、重みを与えられ得る。重みは、利用可能なアイテムでランク付けされ得る。７１２で、リコメンデーションエンジン１０８ａは、利用可能なアイテムそれぞれと関連する重みを検索する。重みは、注文履歴、アップセルフィードバック、およびブーストに基づいて検索され得る。アップセルフィードバックは、アイテムがアップセルで売り込まれた場合に注文された割合を示すことができる。このような割合は、成功率と呼ばれ得る。具体的には、成功率またはコンバージョン率を決定するため、アイテムが客にお勧めとして提示された回数を、お勧めの結果アイテムが購入された回数と比較することができる。コンバージョン率は、定期的に、例えば毎日、取り込まれ、計算され得る。コンバージョン率は、ストラテジー７００に含まれるように、重みの形態でリコメンデーションエンジン１０８ａに送達され得る。よって、例えば、強力に売れるものの、アップセルとして勧められるとあまり売れないアイテムは、あまり重み付けされず、そのため、あまり頻繁にはアップセルとして売り込まれない。ブーストは、例えば一時的に、アイテムの重みを調節することを指す。重みは、例えば絶対的パーセンテージまたは相対量だけ、上下にブーストされ得る。ブーストは、さまざまなパラメータに基づいて適用され得る。例えば、ブーストは、時刻または季節に基づいて適用され得る。
【００５９】
さらに図７Ｂを参照して、例示された重み付き無作為抽出（weighted random）の実施例によると、７１４で、マッチしたアイテムは、それらの重みに比例して無作為に選択されてアップセルを定めることができ、これにより、お勧めのアイテムが、選択されたアイテムと共に売れる可能性が最も高いアイテムとなる見込みが高まると共に、さまざまな他のアイテムも購入のために提示される。７１６で、無作為に選択されたアイテムは、客に購入されるようにスロットレイアウトで（例えばデバイス１１２によって）表示され得る。
【００６０】
別の実施例では、個人化選択ストラテジー７０５が、リコメンデーションエンジン１０８ａによって実行される。個人化選択ストラテジー７０５により、所与の客の好みが、繰り返しの購入を通じて特定されることができる。例えば、所与の客に関連する、お気に入りのブランド、食品の種類、食事の制限もしくは好みなど、が特定され得る。個人に合わせることで、共同のフィルタリングも可能になり得る。この実行において、所与の客の購入履歴が、他のすべての客の購入履歴と比較されて、所与の客に類似した客が購入しているアイテムを見つけることができる。例示された実施例によると、７１８で、所与の客は、例えば搭乗券などの、個人を特定できるものをスキャンして客のデバイス１１２に取り込むことができる。さまざまな個人情報が、個人を特定できるものと関連し得る。個人を特定できるものと関連し得る、例としての個人情報には、客の名前、誕生日、客の目的地、客の食事の好み、航空会社のロイヤルティプログラムのメンバーＩＤなどが含まれ得るが、これらに制限されない。７２０で、デバイス１１２は、やはり前述したように、個人情報をサーバ１１４に送ることができ、例えば、客と関連する注文履歴を呼び出すことができる。７２２で、サーバ１１４は、例えば搭乗券、クレジットカード、もしくは政府発行のＩＤと関連したデータであってよい、受信した個人情報を処理することができる。７２２で、サーバ１１４は、アイテムを選択し、所与の客に特化した（個人に合わせた）注文データを返す。例としての個人に合わせたデータには、客の過去の注文、客の食事制限、客の年齢、客に規制がかかっているアイテム（例えば、未成年の客ではアルコール）が含まれるが、これらに制限されない。アップセルで売り込まれ得る、選択されたアイテムは、個人に合わせたデータに対応し得る。７２６では、選択されたアイテムは、客に購入されるようスロットレイアウトで表示され得る。よって、アイテムは、客がアカウントにログインしていなくても、客にアップセルで売り込まれることができる。
【００６１】
一実施例では、前記で述べた、個人を特定できるものは、リコメンデーションエンジン１０８ａが客から受け取る唯一の情報である。例えば、個人を特定できるものが搭乗券を含む場合、リコメンデーションエンジン１０８ａは、搭乗券で個人を特定することができ、特定された個人の過去の購入を判断することができる。特定された個人に取引履歴が無い場合、リコメンデーションエンジン１０８ａは、その個人の初めての購入に関連するデータを集める。ある実施例では、独自の客識別子（unique customer identifier）が、所与の客による過去の購入に関連づけられ得る。その識別子は、その後の取引中に、リピート客を特定するのに使用され得る。前述のとおり、一実施例では、搭乗券は、現在の客を特定するメンバーＩＤ（例えばロイヤルティプログラムＩＤ）を特定するためにスキャンされる。マイルの現金化（mileage redemption）、クレジットカードなどといった、任意の支払い方法で行われた任意の購入が、メンバーＩＤと関連づけられる。この関連づけは、適切な場合、あらゆる過去の取引に結び付けられ得る。したがって、所与の客が以前に取引履歴がなくても、現在の購入で、その所与の客の取引履歴を開始することになる。場合によっては、データが、周期的に、例えば毎日、集められて、どのアイテムが誰に購入されたかを判断する。図７Ｂを参照すると、７５０で、購入データが、業務管理システム１００から毎日抽出され得る。抽出したデータは、例えば、制限なしに、メンバーＩＤ、購入と関連する会場名（venue name）、購入されたメニューアイテム名、購入されたメニューアイテムの数量、および購入日を含み得る。データメニューアイテムは、データが複数の会場（例えば異なるレストラン）にわたって集められ得るように、一般的な名前を与えられ得る。
【００６２】
例としての実施形態では、７５２で、注文は、メンバーごとのアイテム頻度リストに変換され、このリストは、それぞれの客がアイテムを何回注文したかを示すものである。注文は、客に関連するメンバーＩＤ、注文されたメニューアイテムの標準名、客が注文したメニューアイテムの合計数量によって分類され得る。場合によっては、メンバー（客）および注文されたそれぞれのメニューアイテムは、１つのＭｘＩマトリクスへとまとめられる。このマトリクスを用いて、７５４では、すべてのメンバーについて、他のすべてのメンバーに対する類似性が計算されて、所与の客に最も類似しているメンバーのリストを決定する。ほんの一例として、所与の客（対象の客）は、その所与の客と最も類似している、他の客１００人と関連付けられ得る。対象の客と類似する各メンバーが購入したアイテムは、７５６で、一緒に組み合わせられて、対象の客と関連付けられる上位アイテムのリストを決定することができる。上位アイテムのリストは、例えば、制限なしに、（対象の客の）メンバーＩＤ、標準化されたメニューアイテム（例えば、特定の店またはレストランに一般的であるか、または特異的でない）、およびメニューアイテムと関連するランクを含み得る。ランクは、対象の客に類似したメンバー間での、そのアイテムの人気を示すことができる。場合によっては、ランクは、類似したメンバーが何回そのメニューアイテムを注文したかを示すことができる。前述した定期的なデータ分析の結果、特定の客または特定の１組の客に対して、新たなお勧めを行うことができる。例えば、前述したプロセスを行った後、メンバーは、新たなもしくは異なる類似メンバー、新たなもしくは異なるメニューアイテムの関連付け、または、メニューアイテムと関連づけられた新たなもしくは異なるランクを有し得る。
【００６３】
前述したように、注文中、またはメンバーＩＤが搭乗券のスキャンにより利用可能である場合、個人に合わせたメンバーへのアイテムのお勧めを追加することができる。例えば、お勧めは、客のデバイス上に示されて、客が勧められたアイテムを購入するのを検討するよう促すことができる。ほんの一例として、ビールについてスロットが開いている場合、対象の客に関連する個人に合わせたお勧めのリストは、ビールについてチェックされ、上位にランク付けされたアイテムが、利用可能なスロットに示されるよう選択される。したがって、客は、他の類似メンバーが選択したことのあるアイテムと共に、自分たち自身が以前に選択したことのあるアイテムを見ることができる。
【００６４】
図６Ａは、例としてのコンピューティングシステム６２０のブロック図であり、コンピューティングシステム６２０も、図１〜図５に示したクライアント、サーバ、エンジン、もしくはデバイスなど、ネットワークの１つ以上のノードを実行するのに使用され得る。コンピューティングシステム６２０は、コンピュータもしくはサーバを含むことができ、またソフトウェアの形態であってよいコンピュータ可読命令によって主に制御されることができ、いつでも、またはいかなる手段によっても、このソフトウェアは記憶されるか、またはアクセスされる。このようなコンピュータ可読命令は、中央処理装置（ＣＰＵ）６５９内部で実行されて、コンピューティングシステム６２０を働かせることができる。多くの既知のワークステーション、タブレット、サーバ、およびパーソナルコンピュータにおいて、中央処理装置６５９は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実行される。他の機器では、中央処理装置６５９は、複数のプロセッサを含み得る。コプロセッサ６６０は、メインＣＰＵ６５９とは別個のオプションのプロセッサであり、追加機能を行ったり、ＣＰＵ６５９を補助したりする。ＣＰＵ６５９および／またはコプロセッサ６６０は、受注または注文の履行といった、業務管理のための開示されたシステムおよび方法に関連するデータを、受信、生成、処理することができる。
【００６５】
動作中、ＣＰＵ６５９は、命令を取得、復号、実行し、コンピュータのメインデータ転送パスであるシステムバス６２１を介して、情報を他のリソースとやり取りする。このようなシステムバスは、コンピューティングシステム６２０のコンポーネントを接続し、データ交換のための媒体を定める。システムバス６２１は、典型的には、データ送信のためのデータ回線、アドレス送信のためのアドレス回線（address lines）、割り込み信号（interrupts）を送りシステムバスを稼働させるための制御回線を含む。このようなシステムバス６２１の例は、ＰＣＩ（ペリフェラル・コンポーネント・インターコネクト）バスである。
【００６６】
システムバス６２１に連結されたメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）６６１および読出し専用メモリ（ＲＯＭ）６２３を含む。このようなメモリは、情報を記憶し検索することを可能にする回路を含む。ＲＯＭ６２３は一般的に、容易に修正できない格納データを含む。ＲＡＭ６６１に格納されたデータは、ＣＰＵ６５９または他のハードウェアデバイスによって、読み取られるか、または変更され得る。ＲＡＭ６６１および／またはＲＯＭ６２３へのアクセスは、メモリコントローラ６２２によって制御され得る。メモリコントローラ６２２は、命令が実行されると仮想アドレスを物理アドレスに翻訳する、アドレス翻訳機能を提供し得る。
【００６７】
さらに、コンピューティングシステム６２０は、命令をＣＰＵ６５９から周辺装置、例えばプリンタ６１２、キーボード６５１、マウス６５２、ディスクドライブ６３９に通信することを担う、周辺装置コントローラ６３５を含み得る。
【００６８】
ディスプレイコントローラ６３２によって制御されるディスプレイ６４２は、コンピューティングシステム６２０が生成する視覚的出力を表示するのに使用される。このような視覚的出力は、テキスト、グラフィック、アニメーション化したグラフィック、および動画を含み得る。ディスプレイ６４２は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、気体プラズマベースのフラットパネルディスプレイ、またはタッチパネルで実行され得る。ディスプレイコントローラ６３２は、ディスプレイ６４２に送られるビデオ信号を生成するのに必要な電子構成要素を含む。
【００６９】
さらに、コンピューティングシステム６２０は、コンピューティングシステム６２０を、例えば図５のネットワーク１１０などの外部通信ネットワークに接続するのに使用され得る、例えばネットワークアダプタ６３７などの通信回路を収容して、コンピューティングシステム６２０がネットワークの他のノードと通信することを可能にすることができる。通信回路は、単独で、または、ＣＰＵ９１と組み合わせられて、本明細書（例えば図２〜図５、図７Ｂ）および請求項で説明した送受信工程を実行するのに使用され得る。
【００７０】
前述のとおり、例としての実施形態によると、プロセッサは、客に関連する情報を受信することを含む、さまざまな業務を行うことができる。客に関する情報に基づいて、その客に特化したメニューを作成することができる。メニューは、客に購入され得る１つ以上のアイテムを含み得る。業務は、１つ以上のアイテムのうち少なくとも１つの選択されたアイテムを含む注文を受けることをさらに含む。業務は、客の近くに配置された配達ステーションを特定すること、および特定された配達ステーションにリクエストを送ること、をさらに含み得る。リクエストは、少なくとも１つの選択されたアイテム、および客に関連した場所を示すことができる。業務は、少なくとも１つの選択されたアイテムが客に配達されると、確認を受け取ることをさらに含み得る。客に関連する前述した情報は、フライト状況を含むことができ、そのフライト状況に基づいて、客のコンピューティングデバイスに警報を送ることができる。さらに、例としての実施形態では、注文の受け取りに応じて、業務は、少なくとも１つの選択されたアイテムに対応する準備ステーションを特定することを含み得る。準備リクエストが、特定された準備ステーションに送られ得る。例としての実施形態では、特定された準備ステーションは、複数の準備ステーションのうちの１つであり、準備リクエストは、特定された準備ステーションにのみ送られる。このプロセスによって行われる業務は、補助リクエストを受け取ることをさらに含んでよく、補助リクエストは、第２の客に関連する第２の場所を示すことができる。補助リクエストを表示することができ、プロセッサは、補助リクエストが満たされたことを判断することができる。補助リクエストが満たされたことを判断するのに応じて、業務は、補助リクエストをディスプレイから削除することを含み得る。
【００７１】
本明細書に記載した実施形態から明らかであるように、本発明のさまざまなシステム、方法、態様のすべてまたは一部は、ハードウェア、ソフトウェア、またはそれら両方の組み合わせにおいて具体化され得る。ソフトウェアにおいて具体化される場合、本発明の方法および装置、またはそれらのある態様もしくは一部は、プログラムコード（すなわちコンピュータ実行可能命令）の形態で具体化され得る。このプログラムコードは、フロッピーディスケット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、フラッシュメモリ、ソリッドステートドライブ、ハードディスクドライブ、または任意の他の機械可読記憶媒体を制限なしに含む、磁気記憶媒体、電気的記憶媒体、または光学的記憶媒体などの、コンピュータ可読記憶媒体に記憶されることができ、プログラムコードがコンピュータもしくはサーバなどの機器にロードされ、この機器によって実行されると、機器は、本発明を実行する装置となる。プログラムコードを実行するコンピュータは、プロセッサ、（揮発性および／もしくは不揮発性メモリおよび／もしくは記憶素子を含む）プロセッサによって読み取り可能な記憶媒体、少なくとも１つの入力デバイス、ならびに／または少なくとも１つの出力デバイスを含み得る。プログラムコードは、ハイレベルな手続き型またはオブジェクト指向のプログラミング言語において実行され得る。あるいは、プログラムコードは、アセンブリ言語またはマシン語において実行され得る。いずれの場合も、言語は、コンパイラ型言語またはインタープリタ型言語であってよい。汎用プロセッサ上で実行される場合、プログラムコードは、プロセッサと組み合わせられて、特定の論理回路に類似して動作する、独自の装置を提供することができる。本明細書で使用される用語「コンピュータ可読媒体」および「コンピュータ可読記憶媒体」は、過渡信号を含まない。本明細書で使用される用語「コンピュータ可読媒体」および「コンピュータ可読記憶媒体」は、伝搬信号を含まない。本明細書で使用される用語「コンピュータ可読媒体」および「コンピュータ可読記憶媒体」は、信号を含まない。本明細書で使用される用語「コンピュータ可読媒体」および「コンピュータ可読記憶媒体」は、有形で物理的な現実的構造を有していない信号とは対照的に、有形で物理的な現実的構造を有する媒体を指す。
【００７２】
前述した業務管理システム１００がレストランで実行される場合、業務管理システム１００を実行しないレストランと比べて、そのレストランで客が過ごす時間を減らすことができる。例えば、従来のサービス工程が、発注システム１０２および／または履行システム１０４によって排除され得る。具体的には、業務管理システム１００を使用すれば、補助のための職員を見つけるのに時間を費やす必要がなくなる。さらに、支払システム１０６は、支払にかかる時間を減らすことができる。さらになお、履行システム１０４は、給仕人が厨房スタッフとコミュニケーションをとって注文を入力するのに費やす時間を減らすことができる。
【００７３】
前記で例示したように、本発明は、アプリケーションに基づく環境で注文を行い、注文を配達するための、システム、方法、および装置を対象としている。前述した実施形態の広範な発明の概念から逸脱せずに、それらの実施形態に変更を加えることができる。したがって、本発明は、開示された特定の実施形態に制限されず、むしろ、請求項で定める発明の主旨および範囲に含まれるすべての改変をカバーすることが意図されている。
【００７４】
〔実施の態様〕
（１）  システムにおいて、
１つ以上のプロセッサと、
前記１つ以上のプロセッサに連結されたメモリと、
を含み、
前記メモリは、実行可能な命令を含み、前記実行可能な命令が、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサは、
客と関連する情報を受信することと、
前記客と関連する情報に基づいて、前記客に特化した、１つ以上のアイテムを含むメニューを生成することと、
前記１つ以上のアイテムのうち少なくとも１つの選択されたアイテムを含む注文を受信することと、
前記客の近くに配置された配達ステーションを特定することと、
前記少なくとも１つの選択されたアイテムおよび前記客と関連する場所を示す配達リクエストを、特定された前記配達ステーションに送信することと、
前記少なくとも１つの選択されたアイテムが前記客に配達されたときに確認を受信することと、
を含む、業務を実行する、システム。
（２）  実施態様１に記載のシステムにおいて、
前記客と関連する情報は、フライト状況を含み、
前記業務は、
前記フライト状況に基づいて、前記客のコンピューティングデバイスに警報を送信することをさらに含む、システム。
（３）  実施態様１に記載のシステムにおいて、
前記業務は、
前記注文を受信したことに応じて、前記少なくとも１つの選択されたアイテムに対応する準備ステーションを特定することをさらに含む、システム。
（４）  実施態様３に記載のシステムにおいて、
前記業務は、
特定された前記準備ステーションに準備リクエストを送信することをさらに含む、システム。
（５）  実施態様４に記載のシステムにおいて、
前記特定された準備ステーションは、複数の準備ステーションのうちの１つであり、
前記業務は、
前記準備リクエストを前記特定された準備ステーションにのみ送信することをさらに含む、システム。
【００７５】
（６）  実施態様１に記載のシステムにおいて、
前記業務は、
第２の客と関連する第２の場所を示す補助リクエストを受信することと、
前記補助リクエストを表示することと、
前記補助リクエストが満たされたと判断することと、
をさらに含む、システム。
（７）  実施態様６に記載のシステムにおいて、
前記業務は、
前記補助リクエストが満たされたと判断することに応じて、前記補助リクエストをディスプレイから削除することをさらに含む、システム。
（８）  実行可能な命令を含むコンピュータ可読記憶媒体であって、
前記実行可能な命令が、少なくとも１つのプロセッサによって実行されると、前記プロセッサは、
客と関連する情報を受信することと、
前記客と関連する情報に基づいて、前記客に特化した、１つ以上のアイテムを含むメニューを作成することと、
前記１つ以上のアイテムのうち少なくとも１つの選択されたアイテムを含む注文を受信することと、
前記客の近くに配置された配達ステーションを特定することと、
前記少なくとも１つの選択されたアイテムおよび前記客と関連する場所を示すリクエストを、特定された前記配達ステーションに送信することと、
前記少なくとも１つの選択されたアイテムが前記客に配達されたときに確認を受信することと、
を含む業務を実行する、コンピュータ可読記憶媒体。
（９）  実施態様８に記載のコンピュータ可読記憶媒体において、
前記客と関連する情報は、フライト状況を含み、
前記業務は、
前記フライト状況に基づいて、前記客のコンピューティングデバイスに警報を送信することをさらに含む、コンピュータ可読記憶媒体。
（１０）  実施態様８に記載のコンピュータ可読記憶媒体において、
前記業務は、
前記注文を受信したことに応じて、前記少なくとも１つの選択されたアイテムに対応する準備ステーションを特定することをさらに含む、コンピュータ可読記憶媒体。
【００７６】
（１１）  実施態様１０に記載のコンピュータ可読記憶媒体において、
前記業務は、
特定された前記準備ステーションに準備リクエストを送信することをさらに含む、コンピュータ可読記憶媒体。
（１２）  実施態様１１に記載のコンピュータ可読記憶媒体において、
前記特定された準備ステーションは、複数の準備ステーションのうちの１つであり、
前記業務は、
前記準備リクエストを前記特定された準備ステーションにのみ送信することをさらに含む、コンピュータ可読記憶媒体。
（１３）  実施態様８に記載のコンピュータ可読記憶媒体において、
前記業務は、
第２の客と関連する第２の場所を示す補助リクエストを受信することと、
前記補助リクエストを表示することと、
前記補助リクエストが満たされたと判断することと、
をさらに含む、コンピュータ可読記憶媒体。
（１４）  実施態様１３に記載のコンピュータ可読記憶媒体において、
前記業務は、
前記補助リクエストが満たされたと判断することに応じて、前記補助リクエストをディスプレイから削除することをさらに含む、コンピュータ可読記憶媒体。
（１５）  コンピュータ実行方法において、
客と関連する情報を受信することと、
前記客と関連する情報に基づいて、前記客に特化した、１つ以上のアイテムを含むメニューを生成することと、
前記１つ以上のアイテムのうち少なくとも１つの選択されたアイテムを含む注文を受信することと、
前記客の近くに配置された配達ステーションを特定することと、
前記少なくとも１つの選択されたアイテムおよび前記客と関連する場所を示すリクエストを、特定された前記配達ステーションに送信することと、
前記少なくとも１つの選択されたアイテムが前記客に配達されたときに確認を受信することと、
を含む、方法。
【００７７】
（１６）  実施態様１５に記載の方法において、
前記客と関連する情報は、フライト状況を含み、
前記方法は、
前記フライト状況に基づいて、前記客のコンピューティングデバイスに警報を送信することをさらに含む、方法。
（１７）  実施態様１５に記載の方法において、
前記方法は、
前記注文を受信したことに応じて、前記少なくとも１つの選択されたアイテムに対応する準備ステーションを特定することをさらに含む、方法。
（１８）  実施態様１７に記載の方法において、
前記方法は、
特定された前記準備ステーションに準備リクエストを送信することをさらに含む、方法。
（１９）  実施態様１８に記載の方法において、
前記特定された準備ステーションは、複数の準備ステーションのうちの１つであり、
前記方法は、
前記準備リクエストを前記特定された準備ステーションにのみ送信することをさらに含む、方法。
（２０）  実施態様１５に記載の方法において、
前記方法は、
第２の客と関連する第２の場所を示す補助リクエストを受信することと、
前記補助リクエストを表示することと、
前記補助リクエストが満たされたと判断することと、
をさらに含む、方法。
【００７８】
（２１）  実施態様２０に記載の方法において、
前記方法は、
前記補助リクエストが満たされたと判断することに応じて、前記補助リクエストをディスプレイから削除することをさらに含む、方法。
【図面の簡単な説明】
【００７９】
【図１】例としての実施形態による、例としての業務管理システムのブロック図であり、業務管理システムは、セルフオーダーシステムと、注文履行システムと、セルフペイメントシステムと、１つ以上のビジネスルールエンジンと、を含む。
【図２】例としての実施形態による、図１に描いたセルフオーダーシステムのブロック図である。
【図３】図２に描いたセルフオーダーシステムを用いたセルフオーダーの、例としてのコールフロー図である。
【図４】例としての実施形態による、図１に描いた注文履行システムのブロック図である。
【図５】図１に描いたセルフペイメントシステムのブロック図であり、この図は、例としての実施形態による、セルフペイメントシステムが実行し得る例としてのプロセスも描いている。
【図６Ａ】開示されるシステムおよび方法の態様を具現化し得る、コンピュータシステムの一実施形態のブロック図である。
【図６Ｂ】本開示に従って使用される、例としてのコンピューティングデバイスのブロック図である。
【図７Ａ】例としての実施形態による、リコメンデーションエンジン、およびリコメンデーションエンジンのさまざまな入力を描いたものである。
【図７Ｂ】リコメンデーションエンジンによって実行され得る、さまざまな例としての方法を描いたものである。
【図８Ａ】例としての注文ページのスクリーンショットである。
【図８Ｂ】例としての修飾子リマインダー（modifier reminder）を示すスクリーンショットである。
【図８Ｃ】例としての管理メッセージボックスを示すスクリーンショットである。
【図９Ａ】例としての支払いページのスクリーンショットである。
【図９Ｂ】例としての現金払いページのスクリーンショットである。
【図９Ｃ】例としての現金払いページのスクリーンショットである。
【図９Ｄ】例としての現金払いページのスクリーンショットである。
【図９Ｅ】例としてのチップボックスを示すスクリーンショットである。
【図９Ｆ】例としての割引ページのスクリーンショットである。
【図１０】例としての設定ページのスクリーンショットである。
【図１１】例としてのステータススクリーンページのスクリーンショットである。
【図１２】別の例としてのステータススクリーンページのスクリーンショットである。
【図１３】例としての個々のアイテムページのスクリーンショットである。
【図１４】さらに別の例としてのステータススクリーンページのスクリーンショットである。
【図１５】例としてのテーブルページのスクリーンショットである。
【図１６】別の例としてのテーブルページのスクリーンショットである。
【図１７】例としてのメニューページのスクリーンショットである。
【図１８】例としての修飾子ページのスクリーンショットである。
【図１９】例としての提案ボックスを示すスクリーンショットである。
【図２０】例としての伝票ページのスクリーンショットである。
【図２１】例としての伝票ページのスクリーンショットである。
【図２２Ａ】他の例としてのテーブルページのスクリーンショットである。
【図２２Ｂ】他の例としてのテーブルページのスクリーンショットである。
【図２３】他の例としてのテーブルページのスクリーンショットである。
【図２４】例としての勘定書ページのスクリーンショットである。
【図２５】例としてのダッシュボードのスクリーンショットである。
【図２６】例としての販売報告ページのスクリーンショットである。
【図２７】例としての返金ページのスクリーンショットである。
【図２８】例としての理由ページのスクリーンショットである。
【図２９Ａ】例としての無効ページのスクリーンショットである。
【図２９Ｂ】例としての無効ページのスクリーンショットである。
【図３０】例としての割引ページのスクリーンショットである。
【図３１Ａ】別の例としてのメニューページのスクリーンショットである。
【図３１Ｂ】例としてのキャンセル例外ページのスクリーンショットである。
【図３１Ｃ】例としてのキャンセル理由ボックスを示すスクリーンショットである。
【図３２】例としての注文閲覧ページのスクリーンショットである。
【図３３】例としての勘定書発見ページのスクリーンショットである。
【図３４】例としてのクイックコンテンツ管理ポップアップページのスクリーンショットである。
【図１】
0006728147.tif 000002
【図２】
0006728147.tif 000003
【図３】
0006728147.tif 000004
【図４】
0006728147.tif 000005
【図５】
0006728147.tif 000006
【図６Ａ】
0006728147.tif 000007
【図６Ｂ】
0006728147.tif 000008
【図７Ａ】
0006728147.tif 000009
【図７Ｂ】
0006728147.tif 000010
【図８Ａ】
0006728147.tif 000011
【図８Ｂ】
0006728147.tif 000012
【図８Ｃ】
0006728147.tif 000013
【図９Ａ】
0006728147.tif 000014
【図９Ｂ】
0006728147.tif 000015
【図９Ｃ】
0006728147.tif 000016
【図９Ｄ】
0006728147.tif 000017
【図９Ｅ】
0006728147.tif 000018
【図９Ｆ】
0006728147.tif 000019
【図１０】
0006728147.tif 000020
【図１１】
0006728147.tif 000021
【図１２】
0006728147.tif 000022
【図１３】
0006728147.tif 000023
【図１４】
0006728147.tif 000024
【図１５】
0006728147.tif 000025
【図１６】
0006728147.tif 000026
【図１７】
0006728147.tif 000027
【図１８】
0006728147.tif 000028
【図１９】
0006728147.tif 000029
【図２０】
0006728147.tif 000030
【図２１】
0006728147.tif 000031
【図２２Ａ】
0006728147.tif 000032
【図２２Ｂ】
0006728147.tif 000033
【図２３】
0006728147.tif 000034
【図２４】
0006728147.tif 000035
【図２５】
0006728147.tif 000036
【図２６】
0006728147.tif 000037
【図２７】
0006728147.tif 000038
【図２８】
0006728147.tif 000039
【図２９Ａ】
0006728147.tif 000040
【図２９Ｂ】
0006728147.tif 000041
【図３０】
0006728147.tif 000042
【図３１Ａ】
0006728147.tif 000043
【図３１Ｂ】
0006728147.tif 000044
【図３１Ｃ】
0006728147.tif 000045
【図３２】
0006728147.tif 000046
【図３３】
0006728147.tif 000047
【図３４】
0006728147.tif 000048