特許7470735分散システムを構造化するためのアプリケーションプログラミングインタフェース
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-04-10
(45)【発行日】2024-04-18
(54)【発明の名称】分散システムを構造化するためのアプリケーションプログラミングインタフェース
(51)【国際特許分類】
G06Q 10/02 20120101AFI20240411BHJP
【ＦＩ】
G06Q10/02
【請求項の数】
5
【外国語出願】
(21)【出願番号】P 2022077137
(22)【出願日】2022-05-09
(62)【分割の表示】P 2020533744の分割
【原出願日】2018-12-13
(65)【公開番号】P2022110048
(43)【公開日】2022-07-28
【審査請求日】2022-05-18
(31)【優先権主張番号】15/858,000
(32)【優先日】2017-12-29
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/858,164
(32)【優先日】2017-12-29
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/858,100
(32)【優先日】2017-12-29
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】318002448
【氏名又は名称】ブロック， インコーポレイテッド
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】ベル， ブルース
(72)【発明者】
【氏名】イエン， ケヴィン
(72)【発明者】
【氏名】ウェスターマン， カール
【審査官】関 博文
(56)【参考文献】
【文献】特開２０１７－１４２７２７（ＪＰ，Ａ）
【文献】特開２０１３－０２０６２６（ＪＰ，Ａ）
【文献】特開２０１６－１４８９７６（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１７／００６１５１８（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／００１１３１９（ＵＳ，Ａ１）
【文献】特開２０１７－２２０１７３（ＪＰ，Ａ）
【文献】米国特許第０９２６９１０３（ＵＳ，Ｂ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
最適化された予約スケジューリングを提供するためのシステムであって、１つ以上のプロセッサと、
前記１つ以上のプロセッサによって実行可能な命令を記憶する１つ以上の非一時的なコンピュータ可読媒体とを備え、前記命令は、
商人に関連付けられた販売時点管理デバイス上で実行される予約スケジューリングアプリケーションによって、顧客から、第１の顧客対面予約アプリケーションからの第１の予約要求を受信することであって、前記第１の予約要求は商人位置における予約の好適な時間を含み、前記商人位置は、前記商人によって商品及び／又はサービスが提供される位置である、前記受信することと、
前記第１の顧客対面予約アプリケーションに関わる過去の注文に基づいて、サービスコンピューティングデバイスによって、前記顧客が前記第１の予約要求について好む可能性が高いと予測される座席を判定することと、
前記予約スケジューリングアプリケーションによって、他の顧客から、第２の顧客対面予約アプリケーションからの第２の予約要求を受信することであって、前記第２の予約要求は前記商人位置における予約の他の好適な時間を含む、前記受信することと、
前記第２の顧客対面予約アプリケーションに関わる過去の注文に基づいて、サービスコンピューティングデバイスによって、前記他の顧客が前記第２の予約要求について好む可能性が高いと予測される座席を判定することと、
前記サービスコンピューティングデバイスによって、前記第１の予約要求および前記第２の予約要求に対応する前記予測される座席に少なくとも部分的に基づいて座席表を生成することと、
前記予約スケジューリングアプリケーションに関連付けられたキッチンディスプレイシステムに、前記商人位置のテーブルレイアウトを前記座席表に従って構成させるための前記座席表を送信することと、
を含む動作を実行するように前記１つ以上のプロセッサをプログラムする、システム。
【請求項2】
第三者サービスまたは前記商人のうちの少なくとも１つに関連付けられたコンピューティングデバイスの１つ以上のプロセッサによって実行可能なアプリケーションであって、前記コンピューティングデバイスに関連付けられたディスプレイを介して、前記顧客または前記商人の少なくとも１つにインタフェースを提供することと、
前記インタフェースを介して、予約が要求された前記商人における座席選択、前記予約のタイミング、および過去の座席選好に基づく前記要求された座席選択とは異なる代替座席選択の少なくとも１つに基づいて、前記座席表に対する更新を受信することと、
前記座席表に関する情報が要求されたことを判定することと、
１つ以上のＡＰＩを介しておよび前記サービスコンピューティングデバイスによって、前記座席表に対する更新に関する前記要求に対する応答を送信することと、
前記サービスコンピューティングデバイスから予約提案を受信することと、
予約提案が受諾されたことを判定することと、
前記１つ以上のＡＰＩを介して、前記予約提案の受諾の指標を送信して、前記予約を容易にすることと、
を行うアプリケーションをさらに含む、請求項１に記載のシステム。
【請求項3】
前記予約スケジューリングアプリケーションは、前記商人に関連付けられたコンピューティングデバイス、第三者サービスに関連付けられたコンピューティングデバイス、前記顧客に関連付けられたコンピューティングデバイスとインタフェース接続するアプリケーションプログラムインタフェース（ＡＰＩ）を提供するようにさらに構成される、請求項１に記載のシステム。
【請求項4】
前記サービスコンピューティングデバイス上でホストされるコンセンサスアプリケーションをさらに含み、前記コンセンサスアプリケーションは、前記第１の顧客対面予約アプリケーションおよび前記第２の顧客対面予約アプリケーションからそれぞれ前記第１の予約要求および前記第２の予約要求を受信し、前記コンセンサスアプリケーションは、前記顧客の好みに基づいて前記第１の予約要求および前記第２の予約要求を処理する、請求項１に記載のシステム。
【請求項5】
前記サービスコンピューティングデバイスは、前記予約要求に関連付けられた顧客のさらなる情報を受信し、前記予約が要求された前記商人とは異なる商人のうちの１つを識別し、
前記識別に基づいて他の商人位置において座席を割り当てる
ようにさらに構成される、請求項２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
優先権
本出願は、米国特許出願番号１５/８５８，１６４、１５／８５８，０００および１５／８５８，１００に対する優先権を主張し、それら全ては２０１７年１２月２９日に出願されたものであり、それらの全てはその全体が参照により本明細書に組み込まれる。
本出願は、米国特許出願番号１５/８５８，１６４、１５／８５８，０００および１５／８５８，１００に対する優先権を主張し、それら全ては２０１７年１２月２９日に出願されたものであり、それらの全てはその全体が参照により本明細書に組み込まれる。
【0002】
買い手はしばしば、ウェブサイトおよび他の技術を使用して、買い手への配送のために商人からアイテムを購入する。場合によっては、配送システムまたはサービスが、商人によって提供される商品（グッズ）およびサービスの配送を容易にすることができる。例えば、配送サービスは、配送のために利用可能な複数の商人からのアイテム（品目、商品）を識別するオンラインサイトを提供することができる。買い手は、オンラインサイトに移動し、商人からアイテムを選択し、配送のための住所を指定し、買い手の住所への配送のためにアイテムを購入することができる。配送サービスは、買い手（購入者）へのアイテムの配送を達成するために様々な技術を利用することができる。特に、配送サービスは、アイテムを配送するために、商人に関連付けられた電子デバイスおよび／または顧客に関連付けられた電子デバイスと通信することができる。また、顧客は例えば、アイテムを購入するための予約を行うか、さもなければ、自分の時間またはサービスを予約するために、商人と対話するための技術を使用する。同様に、予約サービスは、特定のサービスに対する商人の位置の予約を容易にすることができる。しかし、商人がこれらの配送、予約、および他の第三者サービスのいくつかに関連付けられている場合、商人は異なる接続されていないソースからの情報注入を手動で制御および調整しなければならず、最終的には、第三者サービスによって約束される動作の単純さが役に立たなくなる。さらに、商人のインタフェースと第三者サービスとの関連付けは、商人が自身のビジネスを実行するために採用する他の技術を混乱させる可能性がある。
【図面の簡単な説明】
【0003】
詳細な説明は、添付の図面を参照して記載され、その中において、参照番号の左端の数字は、参照番号が最初に現れる図面を識別する同じまたは異なる図面における同じ参照番号の使用は、類似または同一のアイテムまたは特徴を示す。
【0004】
【0005】
【0006】
【0007】
【0008】
【0009】
【0010】
【0011】
【0012】
【0013】
【発明を実施するための形態】
【0014】
本明細書で説明される技術は、エンティティがエンティティのソースコードに対する複雑なコーディングまたは修正なしに異なるサービスと通信することができるように、エンティティがサービスプロバイダを介して、配送サービスのためのアプリケーション、予約サービスのためのアプリケーション、第三者サービスのためのアプリケーションなど、異なる第三者サービスを構成することを可能にするシステムおよび環境を提供する。いくつかの例では、サービスプロバイダが、サービスプロバイダによって提供される１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を使用して、商人、買い手、および／または他の者に関連付けられたコンピューティングデバイスにコンセンサスサービスを公開する。また、サービスプロバイダは、ＡＰＩを使用して第三者アプリケーションのユーザ、消費者、または開発者に関連付けられたコンピューティングデバイスにコンセンサスサービスを公開する。いくつかの例では、サービスプロバイダは、商人、買い手、および／または他の者から遠隔的に、および／または独立して動作する第三者であってもよい。１つ以上のＡＰＩは、商人および／または他者が、商人および／または他者によって使用される技術にコンセンサスサービスを自動的に統合することを可能にして、商人による取得のために提供されるアイテムの配送、インダイニング（食事）またはピックアップの両方のためのレストランの予約、メニューの生成など、いくつかのタスクを容易にすることができる。例えば、コンセンサスサービスへの１つ以上のＡＰＩは、エンティティが、複数の配送サービスによるアイテムの配送に関する情報（例えば、配送人コスト、推定配送時間など）に自動的にアクセスし、配送サービスによるアイテムの配送を容易にし、アイテムの準備を注文すること、キッチンからの配送および準備をスケジュールすること、予約をスケジュールすること、および第三者サービスとの間で行き来するコンテンツを管理することなど、コンセンサスサービスを介してサービスプロバイダによって提供される様々な他の機能を使用することを可能にすることができる。
【0015】
最初に、配送サービスまたは第三者サービスを参照して、実装について説明する。多くの例では、サービスプロバイダが買い手および他者にアイテムを配送するために第三者サービスデバイスのネットワークを動作させることができる。第三者サービスデバイスの各々は、全地球測位システム（ＧＰＳ）受信機または他の位置センサを実装して、位置情報をサービスプロバイダに提供することができる。サービスプロバイダは、第三者サービスデバイスの位置を追跡して、配送のための第三者サービスデバイスを選択し、アイテムの配送に関する更新を送信し、または他の方法で第三者サービスによるアイテムの配送を容易にすることができる。加えて、または代替として、サービスプロバイダは、複数の商人デバイスと協働して動作することができる。各商人デバイスは、全地球測位システム（ＧＰＳ）受信機または他の位置センサを実装して、位置情報をサービスプロバイダに提供することができる。サービスプロバイダは、商人デバイスの位置を使用して、商人によって取得のために提供されるアイテムの配送を容易にし、他の機能を実行することができる。さらに、または代替として、サービスプロバイダは、複数の第三者サービスと通信することもでき、第三者サービスロジックおよびシステムを実装して、商人によって提供される商品およびサービスに対する顧客からの注文を受信することができる。上述のように、商人、顧客、および第三者のサービスおよびシステムは、サービスプロバイダのコンセンサスシステムのＡＰＩを介して互いに対話することができる。
【0016】
次いで、コンセンサスシステムは販売時点管理システムにおける中央注文のために、第三者の食品注文、配送、または準備サービスを統合するためのＡＰＩを公開するためのハブ、例えば、注文ハブとして機能する。コンセンサスシステムは、準備時間、配送時間、準備の注文などの新しい注文分析を自動的に計算するために、到来する複数のサービスにわたって準備時間または配送時間を更新することができる。コンセンサスシステムは、一実施形態では、ＡＰＩを活用して、在庫情報を管理し、注文情報を提供することができる。本明細書で説明する技術の一例として、商人が第三者配送サービスから１０個のハンバーガーの注文を受け取り、第２の第三者配送サービスから５個のハンバーガーの別の注文を受け取った場合、コンセンサスシステムは、第１の第三者配送サービスおよび第２の第三者配送サービスならびに任意の他の第三者配送サービスについて、アイテムの利用可能性、準備、および配送時間をリアルタイムで更新することができる。コンセンサスシステムはまた、商人が様々なサービスからの過去の注文に基づいて適切なスタッフおよび在庫を有するように、注文されたアイテムに対する従業員のスタッフ配置を予測および予期することができる。コンセンサスシステムはまた、複数の第三者サービスを介して入ってくる注文のステータスに基づいて、在庫／材料の自動補充、またはベンダからの自動再注文を指示することができる。
【0017】
コンセンサスシステムは、第三者予約サービスの統合、集中予約、待機リスト、スケジューリング管理のための１つ以上のＡＰＩを利用することによって、予約のハブとして機能することもできる。コンセンサスシステムは、他の第三者予約サービスと通信して、中央予約システムと、テーブルおよび好ましい座席の動的な割当て／再割当てとを提供することができ、さらには、ダイニングインが利用可能でない場合にピックアップを提供することもできる。コンセンサスシステムは、座席時間の需要を監視し、分析し、それに応じて、特定の予約または所望のメニューアイテムのための好ましい給仕人／シェフで食事者をサポートするために、スタッフ配置および材料を最適化する。アイテム数や、シフト中に許可されるカスタマイズされた予約の数などに対して、特定の閾値が設定される場合がある。さらに、コンセンサスシステムは、使用メトリックに基づいて各サービスに任意の座席割当数を割り当て、ユーザが他のサービスに加入しているかどうかにかかわらず、１つのサービスがユーザの要求を供給できない場合に予約を行うために、ＡＰＩを介して１つのサービスから別のサービスにユーザを転送することができる。さらに、コンセンサスシステムは、予約された座席の割り当てのためのハブ、および顧客プロファイルおよび商人仕様にマッピングする方法での座席の配置のためのハブとすることができる。例えば、頻繁に訪れる顧客は、レストランの最良の領域に座ることができる。コンセンサスシステムはまた、サービスプロバイダによってサポートされる他のバーティカル（vertical）と統合する。例えば、コンセンサスシステムは、新しい顧客がレストランで予約するときに、コンセンサスシステムが顧客プロファイルを作成して、顧客のプロファイルに最も適した多くの第三者サービスのうちの１つを提供することができるように、オンボーディングコンポーネントと統合される。コンセンサスシステムはまた、各第三者サービスの重みまたは関連性などによって、すべてのサービスからの集約されたレビューに基づいてレストランを推奨することができる。
【0018】
コンセンサスシステムは、コンテンツの集約および解析のためのメニューハブなどのハブであってもよい。そのような実施形態では、コンセンサスシステムは、ユーザが第三者サービスから異なるメニュー上でどのように注文し、それに応じて売上（セールス）を最適化するかに基づいて、動的に価格設定するための統一マネージャである。コンセンサスシステムはすべての第三者サービスに適用できる単一のメニュー更新を推進し、そのようなサービス上のコンテンツを調和させることができる。コンセンサスシステムは、複数の更新またはサービス固有の更新を推進して、第三者サービス全体の使用メトリックを考慮することもできる。たとえば、メニューコンテンツの注文は、すべての第三者サービス、特定のサービス、さらにはサービス内の特定の領域内の使用状況全体にわたるユーザの人気または使用状況に応じて設定できる。たとえば、支払サービスは、注文の人気や、異なる配送サービス間でのユーザの行動に基づいて、メニューの注文を変更することができる。例えば、支払サービスが第三者サービスからのカートレベル情報にアクセスできない場合、支払サービスは、注文がキッチンに出されると、そのような情報を捕捉することができる。このようにして、支払サービスは、公開されたＡＰＩを利用して、ユーザが第三者のサービスメニューをどのように移動するか、およびどのようなアイテムをユーザが追加する傾向があるがチェックアウトを行わない傾向があるかを確認し、それに応じて商人用のグローバルメニュー（または商人と第三者サービス用の特定のメニュー）を調整することができる。
【0019】
本明細書で説明する技術の一例として、アプリケーションは、商人、買い手、および／または他のものに関連付けられたコンピューティングデバイス上で実行することができる。アプリケーションは、個人（例えば、商人、買い手など）がアクションを実行すること、例えば、商人によって取得のために提供されたアイテムの注文を行うこと、レストランの席を予約すること、コンテンツを表示すること、第三者サービスの更新を提供することなどを可能にするためのユーザインタフェースを提供することができる。例えば、配送サービスの場合、ユーザインタフェースを介して、個人は、取得するアイテムを選択し、アイテムが配送されることを要求することができる。例えば、個人は、購入のために電子ショッピングカートにアイテムを入れ、アイテムを配送させることに関心を示すことができる。場合によっては、個人は、配送の場所、ピックアップの場所、ピックアップの要求された時間、取得されているアイテムの数、アイテムのサイズ、アイテムが所定のカテゴリに関連付けられているかどうか、アイテムの重量などを指定することができる。他の例では、このような情報は、ユーザプロファイルまたは商人プロファイルから自動的に判定されたり、取得されたりする。
【0020】
個人がアイテムを配送させることに関心があると判定すると、第三者配送サービスなどのためのアプリケーションは、サービスプロバイダに関連付けられたコンセンサスサービスを介してアイテムの配送を容易にするために、サービスプロバイダによって提供されるＡＰＩを使用して第三者サービスプロバイダと通信することができる。例えば、アプリケーションは、アイテムの配送のコスト、アイテムの配送時間の推定量などの要求を送信することができる。第三者サービスは、関連する配送サービスを使用して、アイテムを買い手の位置に配送するための、例えば、コンセンサスサービスのためのＡＰＩを介してサービスプロバイダに配送するための配送提案を生成することができる。配送提案は、配送コスト、配送時間の推定量および／またはアイテムの配送に関するその他の情報を含んでもよい。サービスプロバイダは、コンセンサスサービスを介して、配送提案を、受諾または拒否のためのアプリケーションに送信することができる。いくつかの例では、アプリケーションは、ユーザインタフェースと対話する個人に情報を提示し、個人は提案を受諾するか、または拒否するための入力を提供することができる。他の例では、アプリケーションは、１つ以上の基準に従って動作して、配送提案を自動的に受諾するか、または拒否することができる（たとえば、コストが閾値未満である場合に受諾する、推定配送時間が閾値時間量未満である場合に受諾するなど）。いずれにしても、アプリケーションは、ＡＰＩを使用して、配送提案の受諾または拒否のインジケーション（指標、指示）を第三者サービスに送信することができる。
【0021】
サービスプロバイダは、配送提案の受諾について第三者のサービスが通知された場合、配送のための配送人を選択する処理を行うことができる。例えば、サービスプロバイダは、経時的に複数の配送人デバイスの位置を追跡し、ピックアップ位置まで特定の距離内にあること、配送を行うために利用可能であること、アイテムを移送することができる移送車両に関連付けられていることなど、１つ以上の基準を満たす配送人を選択することができる。場合によっては、サービスプロバイダは、配送人（クーリエ）プロファイル、ユーザプロファイル、商人プロファイル、または他の情報を使用して配送人を選択することができる。次いで、サービスプロバイダは、配送人に、配送人が商人の施設からアイテムを入手し、そのアイテムを配送場所に移送することを要求する通信を送信することができる。アイテムの配送中、サービスプロバイダは、配送人および／または商人から情報（例えば、位置情報、配送がピックアップされたことの確認など）を受信し、配送のステータスを判定することができる。サービスプロバイダは、アプリケーション、商人デバイス、買い手デバイス、および／または他のものに配送のステータスを送信することができ、その結果、個人に、配送の現在の状態を通知することができる。
【0022】
多くの場合、本明細書で説明する技術および環境は、サービスプロバイダによって提供されるコンセンサスサービスにアクセスし、配送サービス、予約サービス、およびコンテンツサービスをサポートするために、１つ以上のＡＰＩを提供する。すなわち、１つ以上のＡＰＩは、エンティティの技術に様々な第三者サービスを統合するための柔軟な構造をエンティティに提供することができる。一例として、商人は、第三者サービスを実施するための追加のコンポーネントを作成することなく、商人によって動作されるウェブサイトまたはアプリケーションに第三者サービスを統合することができる。そうすることによって、ウェブサイトまたはアプリケーションは、そのような特徴をウェブサイトまたはアプリケーションに直接組み込むウェブサイトまたはアプリケーションと比較して、より薄い実装（例えば、より少ない構成要素で）に従って動作することができる。これにより、ウェブサイトやアプリケーションの実装が比較的高速になる可能性がある。さらに、技術および環境は、第三者サービスの統合が多種多様な文脈（たとえば、デバイス、プラットフォームなど）にわたって実施されることを可能にし得る。さらに、技術および環境は、第三者サービスを実装するためにサービスプロバイダによって使用される、基礎となる技術、たとえばコンセンサスサービスを修正するための柔軟な構造を提供する。言い換えれば、商人プラットフォームの基礎となる技術は、商人、買い手、および／または他の者によって実施される技術の更新を必要とせずに、統一されたおよび／または単純化された方法で更新されてもよい。さらに、技術および環境は、サービスプロバイダによって使用される基礎技術（例えば、アルゴリズム、コストスキームなどを含む）が、安全な環境において維持されることを可能にしてもよい。また、複数の第三者サービスによって共有されるデータは、商人に公開される必要はなく、さらに、サービスプロバイダは、第三者サービス、環境、位置、時刻などに基づいて、データ制御およびデータカプセル化を作成することができ、これは、第三者サービスに特有であるか、または端末、アプリケーション、キッチンディスプレイシステム、支払アプリケーションなどの第三者サービスと商人プラットフォームとの間の関係に特有であってもよい。
【0023】
中央注文システムの利点には、注文のより良好な管理、注文のスケジューリング、および各第三者サービスの注文をリストする壁の周りにぶら下がる複数のタブレットの排除が含まれる。本明細書に記載される技術を用いて、商人は、異なるソースから来る注文を追跡し、注文、在庫、および注文のタイミングをリアルタイムまたはほぼリアルタイムに管理することができる単一のキッチンディスプレイシステムをインストールすることができる。
【0024】
中央レストランシステムの利点には、予約のより良い管理、複数のソースからのレストランのレビューの追跡、およびレストランの予約中または過剰予約中のダブルブッキングの排除が含まれる。説明は例示的なユースケースとしてレストランについて言及するが、説明はサロン、病院、ヨガスタジオなどの予約およびアポイントのための他のユースケースに拡張できることが理解されるのであろう。本明細書で説明する技術を用いて、予約を最適化することができ、座席割り当てを、例えば、充填容量（キャパシティ）に基づいて、リアルタイムで第三者予約サービスに割り当てることができる。
【0025】
中央コンテンツコンセンサスシステムの利点はメニュー、価格、動作時間などのコンテンツのより良好な管理を含み、すべての第三者サービスは、商人から同時に同じ更新を得る。本明細書で説明される技術を用いて、コンテンツは、価格、ブランド、および商人のルックアンドフィールが一貫して維持されるように、異なる第三者サービスにわたって調和させることができる。コンセンサスシステムは、動的な価格設定のための統一されたマネージャとすることができ、ユーザが異なるメニュー上で何をどのくらい注文しているかなどの注文データを追跡することによって、販売（セールス）を最適化することができる。あるいは、異なる種類の視聴者をターゲットにするために、すなわち、利用可能性／人気に基づいてすべてのメニューにわたってメニュー価格を調整するために、異なる更新をリアルタイムまたはほぼリアルタイムで第三者サービスにプッシュすることができる。例えば、第１の第三者サービスで注文する顧客が早朝にファストフードを注文すると判定することによって、メニューは例えば、準備時間または人気の順に、リスト上にファストフードアイテムを提示するように構成されてもよい。それに加えて、またはその代わりに、アイテムの価格設定は、データ分析にマッピングするように構成されてもよい。いくつかの実装形態では、商人がアイテムを修正すると、支払フローが修正され得る。例えば、商人が自分のメニューからアイテムを取り除くこと（削除アイテムと呼ばれることもある）を決定したものの、他のアイテムに加えてそのアイテムについて既に注文がなされている場合、コンセンサスシステムは、顧客がそのアイテムについて返金されるか、または決して課金されないように、拒絶アイテムを除外するように準備および支払フローを修正することができる。いくつかの実装形態では、拒絶アイテムは、別のアイテム、例えば、類似アイテム、類似コストのアイテム、新しいオファー、割引（ディスカウント）、顧客への通知などで置き換えられてもよい。
【0026】
さらに、本明細書の技術は、ＡＰＩを通じたコンセンサスシステムがそのソースコードに変更を加えることなく、またはほとんど変更を加えずに、命令およびデータを移植することによって、様々なハードウェアおよびソフトウェアプラットフォームとインタフェースすることができるので、任意の第三者サービスをオンボード化し、商人から買い手へのアイテムの配送のために統合すること、または商人との任意の構成または終了関係なしに任意の他のサービスを提供することを可能にすることができる。コンピューティングデバイス、モバイルデバイス、およびセンサの対話を通じて、本明細書の実装形態は、商人、買い手、サービス領域、第三者サービス、ハードウェアおよびソフトウェアプラットフォーム、ならびに第三者サービス自体の常に変化する状況および条件に対応するために、多数のエンティティが参加することができる予測不可能な共有エコシステムを管理することができる。
【0027】
様々な実装において、コンセンサスシステムは、中央サーバ、またはサーバのグループとして機能し、ＡＰＩを介して様々なソースからデータを取り込み、命令およびデータを様々なサービスによって理解されるフォーマットに移植し、データをフィルタリングして様々な商人およびサービスとの関連性を判定し、分析を使用して、配送、予約、コンテンツ集約、またはコンテンツ表示などの様々な商人タスクを構造化または再構造化することができる。
【0028】
本明細書のいくつかの実装形態は、双方向ＡＰＩまたはプッシュプルＡＰＩを記載し、それらは、情報が両方向に移動すること、及び、ＡＰＩエンドポイントが、通信を行う両方のアプリケーションに関連付けられることを意味する。しかしながら、いくつかの実装は、アプリケーションが情報をプッシュするか、要求されたときに情報をプルするだけでよいように、単一方向ＡＰＩを実行することができる。
【0029】
この簡単な導入は、読者の便宜のために提供され、特許請求の範囲を限定することを意図しない。さらに、上記および下記の技術は、いくつかの方法およびいくつかの文脈で実施することができる。以下に詳細に説明するように、以下の図を参照して、いくつかの例の実装と文脈が提供されている。しかし、以下の実装と文脈は多くのうちの数個である。
【0030】
図１は、本明細書で説明する技術を実施することができる例示的なアーキテクチャ１００を示す。アーキテクチャ１００は、コンセンサスサービス、商人位置における買い手、第三者サービス等のアプリケーションの１つ以上のユーザ１０４（以下、「ユーザ１０４」）、１つ以上の商人１０６（以下、「商人１０６」）、１つ以上の第三者サービス１０８（以下、文脈に応じて「配送サービス１０８」、「配送人サービス」、「予約サービス１０８」、「コンテンツサービス」、および、まとめて第三者サービスと称される）、１つ以上のカード支払ネットワークコンピューティングデバイス１１０、および／または、様々な処理を実行するために１つ以上の銀行コンピューティングデバイス１１２と通信する、コンセンサスシステムまたはアプリケーション（以下、「コンセンサスサービス」とも称される）に関連付けられたサービスプロバイダ１０２を含む。第三者サービスはまた、サービスプロバイダによって提供される、例えば、配送、予約、またはコンテンツの集約および管理のためのサービスを含むことができる。多くの場合、サービスプロバイダ１０２は、ユーザ１０４および／または商人１０６がサービスプロバイダ１０２によって提供されるコンセンサスサービスにアクセスすることを可能にするために、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）１１４を提供することができる。ＡＰＩ は、プッシュＡＰＩ、プルＡＰＩ、またはその両方の組み合わせとして実装できる。したがって、各アプリケーションは、更新を受信または送信するための、あるいはその両方のためのＡＰＩエンドポイントを作成または共有できる。例えば、プッシュAPIは、プッシュメッセージをウェブアプリケーションに、時には非同期で、プッシュサービスを送信することを可能にする。アプリケーションサーバは、ウェブアプリケーションまたはユーザエージェントが非アクティブな場合でも、いつでもプッシュメッセージを送信することができる。プッシュサービスは、ユーザエージェントへの確実かつ効率的な配信を保証する。プッシュメッセージは、ウェブアプリケーションの発信元で動作するサービスワーカに配信され、サービスワーカはメッセージ内の情報を使用して、ローカル状態を更新するか、またはユーザに通知を表示することができる。プルＡＰＩは、例えば、ある間隔で実行するように設定されたスケジュールされたジョブに基づいて、データを抽出するように動作する。システムは、特定の条件が満たされるまでソースのポーリングを継続する。
【0031】
さらに、多くの場合、サービスプロバイダ１０２は、買い手（第１のユーザ）と売り手（第２のユーザ）との間の取引を容易にすることができ、この取引は、１つ以上のカード支払ネットワークコンピューティングデバイス１１０および／または１つ以上の銀行コンピューティングデバイス１１２と通信することを含むことができる。ユーザ１０４、商人１０６、および／または第三者サービス１０８のそれぞれは、コンピューティングデバイスに関連付けることができる。例えば、第三者サービスは、ユーザ１０４または商人デバイス１０６に関連付けられたユーザデバイス上で実行されてもよい。さらに、いくつかの例では、環境１００は、さらに詳細に後述するように、アイテムの取得を容易にするために、ユーザ１０４および／または商人１０６と通信するための追加のサービスプロバイダ（サービスプロバイダ１１６）を含む。図示されるように、アーキテクチャ１００のいずれかのコンピューティングデバイスは、１つ以上のネットワーク１１８を介して互いに通信することができる。
【0032】
商人は、買い手から受け取った対価と引き換えに、買い手による取得のための商品またはサービスの提供に従事する任意の企業またはエンティティを含むことができる。商人に起因するアクションは、商人の従業員または他のエージェントによって実行されるアクションを含むことができ、したがって、本明細書では、特に論じない限り、商人とその従業員との間の区別は行われない。さらに、買い手は、購入、レンタル、リース、借用、ライセンス供与などによって、商人から商品またはサービスを取得する任意のエンティティを含むことができる。以下、商品及び／又はサービスをアイテムと呼ぶことがある。アイテムは、完成品、部分完成品、原材料などを含むことができる。したがって、商人および買い手は、互いに対話して、買い手が商人から１つ以上のアイテムを取得し、その代わりに、買い手が支払いを商人に提供する取引を行うことができる。
【0033】
配送サービスなどの第三者サービスは、アイテムの配送に従事するエンティティを含むことができる。第三者サービスは、配送ピックアップ位置（例えば、商人の位置）からアイテムを取得し、そのアイテムを配送ドロップオフ位置（例えば、買い手の位置）に移送することができる。本明細書のいくつかの実装形態は、異なる配送ポータル１０８から入ってくる配送要求（注文とも呼ばれる）を商人が調和させることを可能にする技術革新を提供する。このような技術を用いて、商人は、在庫、発注時間、顧客のロイヤリティ格付けなどに関して注文を調整し、同期させることができる。
【0034】
レストラン管理サービスのような第三者サービスは、オンライン予約または本人予約のような、それらの位置での予約を可能にする任意のエンティティを含むことができる。また、予約という用語は、アポイントメント、本人のダイニング、ピックアップなどを含むことを意図している。第三者サービスは、商人位置で予約を行うための要求を受信することができる。本明細書のいくつかの実装形態は、異なる予約ポータル１０８から入ってくる予約要求（予約とも呼ばれる）を商人が調和させることを可能にする技術革新を提供する。そのような技術を用いて、商人は、座席の利用可能性、食事者の好み、時間、位置、およびメニュー上で利用可能なアイテムなどに関して注文を調整し、同期させることができる。
【0035】
コンテンツ集約サービスなどの第三者サービスは、アイテムを配送することに従事する任意のエンティティを含むことができる。第三者サービスは、他の第三者サービスがどのようなものを実施しているかを何ら考えることなく、また、特に商人のストアに関して、自分の顧客がどのようなものを見たいかを知ることなく、コンテンツを表示することができる。本明細書でのいくつかの実装は、異なる第三者サービス１０８にわたって、メニューのようなコンテンツを商人が調和させることを可能にする技術革新を提供する。そのような技術を用いて、商人は、第三者サービスのプロファイル、時刻、位置、および他のそのような仕様に関して、メニューおよび他のコンテンツを調整し、同期させることができる。メニューまたはメニューの更新は、すべての第三者サービス上で同時に単一の更新または通知としてプッシュすることができる。代替的に又は追加的に、メニュー及び他のそのようなコンテンツ、例えば、コンテンツのディスプレイ、アイテムの注文等は、第三者サービスと商人との関係、アイテムの利用可能性、時刻、及び他のそのような要因に従って構成することができる。
【0036】
上述のように、サービスプロバイダ１０２は、コンセンサスサービスの１つ以上のＡＰＩ１１４を公開して、ユーザ１０４および／または商人１０６に関連付けられたコンピューティングデバイスが、サービスプロバイダ１０２によって提供される第三者サービスにアクセスし、調和し、正規化し、リファクタリングし、調整し、および／またはインタフェースすることを可能にし、その結果、商人またはユーザプロセスが最適な方法で構造化される。説明の簡単化のため、図１の例では、ユーザ１０４及び／又は商人１０６に関連付けられたコンピューティングデバイスは、「取得デバイス」と呼ばれる。図１の例では、取得デバイスは、アイテムの配送、座席予約、メニューの更新等のアクションを容易にするために、１つ以上のＡＰＩ１１４を通じてサービスプロバイダ１０２と通信する。取得デバイスは、アイテム取得インタフェース１２０を介して、サービスプロバイダ１０２から受信したアイテムの配送に関する様々な情報を表示する。この例では、取得デバイスがピザなどのアイテムの配送のための配送サービス１０８－１を実行し、一方、飲料などのアイテムの配送のための配送サービス１０８－２を実行する。場合によっては、取得デバイスは異なっていてもよく、商人は、異なる第三者サービスから２つの別個の配送要求を受信してもよい。要求を出している間、サービスプロバイダは、コンセンサスサービス１３２を使用して、受信された注文および注文のタイミングを判定することができる。コンセンサスサービス１３２は例えば、機械学習モデルを使用して、注文をいつ行うべきか、どのアイテムを準備のために集めることができるか、等を判定する。コンセンサスサービス１３２は、商人に関連付けられたキッチンディスプレイシステム（図示せず）の注文をスケジュールする。このように、商人は、異なるソースから来る注文に対応する複数のタブレットを維持する必要がない。単一のタブレットは例えば、注文のタイミング、ソース、位置、準備の時間などに基づいて、注文のソース、タイミング、配送の推定時間、および準備の新しい順序を示す。同様に、予約要求に対して、コンセンサスサービス１３２は、予約の単一のリストと、ユーザおよび商人の間で座席および予約を分配（分散）する方法とを作成する。さらに、コンセンサスサービスは、リアルタイムまたはほぼリアルタイムで要求の進行を通信するために当事者とインタフェースすることができる。
【0037】
例えば、取得デバイスは、商人１０６と注文を行いつつ、１つ以上のＡＰＩ１１４を通じてサービスプロバイダ１０２を介して商人と通信してもよい。特に、個人（ユーザ１０４および／または商人１０６）は、購入のためにオンラインショッピングカートにアイテムを入れ、そのアイテムを配送させることに関心を示すことができる。これに応答して、取得デバイスは、配送、予約、またはコンテンツ管理に関する情報を求める要求を、１つ以上のＡＰＩ１１４を介してサービスプロバイダ１０２に送信することができる。サービスプロバイダ１０２は、商人または商人在庫データベース（ローカルまたはリモートで）と通信して、サービスプロバイダ１０２に関連付けられた配送サービスによるアイテムの配送に関する配送提案を生成し、ＡＰＩ呼び出し１３４を通じて、その配送提案を取得デバイスに送信することができる。取得デバイスは、受諾または拒否のために、アイテム取得インタフェース１２０（ａ）を介して配送提案の情報を表示することができる。図１に示すように、アイテムを配送するための推定時間量および配送コストが、取得インタフェース１２０（ａ）における１２２において提示される。個人は、配送提案を受諾し、ボタン１２４を選択することによって注文を行うことができる。
【0038】
さらに、取得デバイスは、１つ以上のＡＰＩ１１４を介してサービスプロバイダ１０２と通信して、別の第三者サービスまたは別のユーザによって注文されたアイテムの配送に関するステータス更新を取得することができる。このような場合、サービスプロバイダ１０２は、アイテムを配送するために割り当てられた配送人（例えば、第三者サービス１０８）の位置を監視し、または、配送人に関連付けられた第三者サービスからこのような情報を取得し、アイテムを販売している商人（例えば、商人１０６）から情報を取得し、および／または、他の情報を取得することができる。サービスプロバイダ１０２は、アイテムの配送のステータスを判定し、配送のステータスを取得デバイスに送信することができる。配送のステータスは、アイテム取得インタフェース１２０（ｂ）を介して表示されてもよい。ステータスは、取得デバイスからの要求に応じて（例えば、１つ以上のＡＰＩ１１４を介して送信されるメッセージに応答して）、定期的に、および／または別のイベントの発生に応じて、判定され、および／または取得デバイスに提供され得る。図１に示されるように、アイテム取得インタフェース１２０（ｂ）は、選択されたときに、割り当てられた第三者サービスデバイスの現在の位置、割り当てられた第三者サービスデバイスによって移動される経路、アイテムをピックアップ又は配送するために割り当てられた第三者サービスデバイスによってさらに取られるのであろう経路等を示す地図を表示するボタン１２６を含むことができる。
【0039】
図１の例では、配送サービス情報要求１２８は、取得デバイスによって１つ以上のＡＰＩ１１４を介してサービスプロバイダ１０２に送信される通信を表し、一方、配送サービス情報１３０は、注文がどのように順序付けられるか、同時注文要求がどのように処理されるか、不正要求、配送時間、座席表、および商人が動作をスケジュールして編成するための他の情報、を示すためのコンセンサスコールなどの、サービスプロバイダ１０２から取得デバイスに送り返される通信を表す。配送サービス情報要求１２８は、アイテムの配送に関する情報（例えば、コスト見積り、配送時間見積り等）、配送提案の受諾／拒否のインジケーション（指標、表示）、配送ステータスに関する情報の要求等を含むことができる。配送サービス情報１３０は、配送提案、アイテムの配送ステータスに関する情報などを含むことができる。
【0040】
場合によっては、取得デバイスは、サービスプロバイダ１１６と協働して動作することができる。サービスプロバイダ１１６、およびコンセンサスサービスなどの関連するアプリケーションは、取得デバイスおよび／またはサービスプロバイダ１０２から遠隔でおよび／または独立して動作するリソースを提供することができる。一例では、サービスプロバイダ１１６は、購入、在庫を管理し、および／または他の処理を実行するために、商人１０６に関連付けられてもよい。サービスプロバイダ１１６は、オンラインサイトを提供したり、取得デバイス上のローカルアプリケーション（例えば、デスクトップアプリケーション、モバイルアプリケーションなど）と協働して動作したりすることができる。例示すると、サービスプロバイダ１１６は、顧客（および／またはピザ商人）がピザ商人とピザの注文を行うことができるように、ピザレストランおよび顧客が注文することができるすべての配送サービスのためのオンラインウェブサイトを提供することができる。このように、取得デバイスによってサービスプロバイダ１０２との間で送信および／または受信される通信は、サービスプロバイダ１１６を介してルーティングされてもよい。言い換えると、サービスプロバイダ１１６は、取得デバイスとサービスプロバイダ１０２との間、および商人と第三者サービスとの間の仲介として動作することができる。この種のアーキテクチャは、当事者に関連するデータのみが明らかにされるように、データが当事者間で選択的に秘密に共有されることを可能にする。サービスプロバイダ１１６は、１つ以上のＡＰＩ１１４を介してサービスプロバイダ１０２と通信することができる。これは、サービスプロバイダ１０２によって提供される配送サービスの、商人１０６に関連する技術へのシームレスな統合を提供することができる。上記のピザレストランの例に戻ると、ピザレストランのウェブサイトは、１つ以上のＡＰＩ１１４を介してサービスプロバイダ１０２と通信することによって、サービスプロバイダ１０２の配送サービスを統合することができる。場合によっては、これは、ピザレストランがそのような配送サービスを使用していることを顧客が知ることなく（例えば、配送が商人１０６によって提供されているように見えるように）起こり得る。他の例では、配送サービスがサービスプロバイダ１０２によって提供されていることを示す情報（例えば、ピザがＸ社によって配送されることを示すポップアップウィンドウ）を顧客に通信することができる。多くの機能がサービスプロバイダ１１６によって実行されるものとして記述されているが、これらの機能のいずれかは、サービスプロバイダ１０２によって実行されてもよい。
【0041】
サービスプロバイダ１０２は追加的に、または代替的に、第三者サービスを管理するための処理を実行することができる。例えば、サービスプロバイダ１０２は、第三者サービス１０８と通信して、第三者サービス１０８の位置を追跡し、アイテムの配送を要求し、配送に関するステータス情報（例えば、アイテムがピックアップまたはドロップオフされたという第三者サービスからの確認）を受信し、等々することができる。例示的な環境１００では、サービスプロバイダ１０２は、取得デバイスから配送提案または推奨提案の受諾のインジケーション（指標、指示）を受信し、アイテムを配送するために第三者サービスを選択する。サービスプロバイダ１０２は、複数の第三者サービスの位置を識別し、第三者サービス（この場合、第三者サービス１０８）を選択して、アイテムを配送位置に移送することができる。次いで、サービスプロバイダ１０２は、アイテムの配送を要求する第三者サービス１０８に配送要求１３４を送信することができ、その返答として、第三者サービス１０８は、配送要求の受諾または拒否のインジケーション（指標、表示）を送信することができる。
【0042】
場合によっては、サービスプロバイダ１０２は、環境１００内の任意の当事者に支払いを行わせることができる。例えば、サービスプロバイダ１０２は、ユーザ１０４に関連付けられた口座からの資金を、アイテムに対する支払いとして商人１０６に関連付けられた口座に転送させることができる。さらに、資金は、サービスプロバイダ１０２、商人１０６、および／またはユーザ１０４に関連付けられた口座から、アイテムを配送するための第三者サービス１０８に関連付けられた口座に転送され得る。取引を容易にするために、サービスプロバイダ１０２への支払いをさらに行うことができる。
【0043】
上述のように、サービスプロバイダ１０２は、取引を電子的に行うために、１つ以上のカード支払ネットワークコンピューティングデバイス１１０と通信することができる。１つ以上のカード支払ネットワークコンピューティングデバイス１１０は、カード支払ネットワーク（例えば、ＭａｓｔｅｒＣａｒｄ（登録商標）、ＶＩＳＡ（登録商標）など）に関連付けることができる。サービスプロバイダ１０２はまた、１つ以上の銀行の１つ以上の銀行コンピューティングデバイス１１２と通信することができる。例えば、サービスプロバイダ１０２は、加盟店銀行（acquiring bank）、カード発行銀行（issuing bank）、および／または電子支払いのためのユーザ口座を維持する銀行と通信することができる。
【0044】
加盟店銀行は、カード協会の登録された会員（例えば、Ｖｉｓａ（登録商標）、ＭａｓｔｅｒＣａｒｄ（登録商標）など）であってもよく、カード支払ネットワークの一部であってもよい。カード発行銀行は、ユーザに支払カードを発行することができ、カード発行銀行が支払カードを発行したカード所有者によって行われた購入に対して、加盟店銀行に支払いを行うことができる。したがって、いくつかの例では、加盟店銀行のコンピューティングデバイスは、カード支払ネットワークに含まれてもよく、支払いを得るためにカード発行銀行のコンピューティングデバイスと通信してもよい。さらに、いくつかの例では、ユーザは、クレジットカードの代わりにデビットカードを使用することができ、その場合、デビットカードに対応する銀行の銀行コンピューティングデバイスは、ユーザが参加している取引に関する通信を受信することができる。さらに、いくつかのタイプの取引または代替システムアーキテクチャに関与する他の金融機関のコンピューティングデバイスが存在してもよく、したがって、上記は、議論の目的のためのいくつかの例にすぎない。
【0045】
１つ以上のカード支払ネットワークコンピューティングデバイス１１０および／または１つ以上の銀行コンピューティングデバイス１１２は、サーバ、ラップトップコンピュータ、デスクトップコンピュータなどの１つ以上のコンピューティングデバイスとして実装されてもよい。１つ以上のコンピューティングデバイスは、クラスタ、ファーム、データセンタ、クラウドコンピューティング環境、またはそれらの組合せで構成することができる。一例では、１つ以上のコンピューティングデバイスは、計算リソース、記憶リソースなどを含むクラウドコンピューティングリソースを提供する。
【0046】
上述したように、アーキテクチャ１００のコンピューティングデバイスは、１つ以上のネットワーク１１８を介して通信してもよい。１つ以上のネットワーク１１８は、ローカルエリアネットワークまたはインターネットなどのワイドエリアネットワークなどの任意のタイプのネットワークとすることができ、セルラネットワークなどのワイヤレスネットワーク、Ｗｉ－Ｆｉなどのローカルワイヤレスネットワーク、および／またはＢｌｕｅｔｏｏｔｈ（登録商標）およびＢｌｕｅｔｏｏｔｈ（登録商標）ローエナジーなどの近距離無線通信、有線ネットワーク、または任意の他のそのようなネットワーク、またはそれらの任意の組合せを含むことができる。したがって、１つ以上のネットワーク１１８は、有線または光ファイバ技術だけでなく、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）ローエナジー、Ｗｉ－Ｆｉ、およびセルラ通信技術を含む、有線および／または無線通信技術の両方を含むことができる。そのような通信に使用される構成要素は、ネットワークのタイプ、選択された環境、またはその両方に少なくとも部分的に依存することができる。その結果、アーキテクチャ１００の１つ以上のコンピューティングデバイスは、有線または無線接続などの任意の方法で、１つ以上のネットワーク１１８に通信可能に接続することができる。
【0047】
本明細書で説明される技術は、様々なコンテキストで、および／または様々な方式で実装され得る。一例として、本技術は、商人対面コンポーネント（例えば、商人用に設計されたアプリケーション、オンラインサイト、インタフェースなど）を用いて実装され得る。この例では、商人１０６が顧客のために注文することができる。具体的には、顧客は、商人１０６の施設に入り、商人１０６と電話し、商人１０６に通知（例えば、電子メール、テキストメッセージ、ソーシャルメディアポストなど）を送信し、またはそうでなければ商人１０６と通信することができる。商人１０６は、商人対面コンポーネント（例えば、商人が使用するように設計されたアイテム取得インタフェース１２０）と対話して、顧客によって識別されたアイテムを選択し、かつ／または顧客によって提供された他の情報（例えば、配送先住所など）を入力することができる。配送提案がサービスプロバイダ１０２から受信されると、商人１０６は、配送提案の情報を顧客に通信することができる（例えば、配送コストを伴う画面を表示する、アイテム取得インタフェース１２０から顧客への配送コストを読み取る、通知を送信するなど）。あるいは、商人１０６は、配送提案の情報を顧客に提供することを控えることができる。例えば、商人１０６は、顧客に無料で配送を提供すること、注文の総コストに配送コストを含めること（例えば、項目別にすることなく）などを決定することができる。いずれにしても、商人１０６は、顧客からの通信に基づいて、配送提案を受諾または拒否し、かつ／またはアイテムを注文することができる。
【0048】
別の例として、本技術は、顧客対面コンポーネント（例えば、顧客用に設計されたアプリケーション、オンラインサイト、インタフェースなど）を用いて実装され得る。この例では、顧客が商人１０６に直接注文することができる。具体的には、顧客は、商人１０６に関連付けられたオンラインサイトに移動し、商人１０６に関連付けられたアプリケーション（例えば、デスクトップアプリケーション、モバイルアプリケーションなど）を開いて、商人１０６に注文を行うことができる。いくつかの例では、顧客は、処理中に配送情報（例えば、配送コスト、配送のための推定時間量など）を見ることができ、一方、他の例では、情報は、顧客に示されないか、または他の情報（例えば、注文の総コスト）内に含まれないことがある。さらに、顧客は、顧客対面コンポーネントを介して配送のステータス更新を見ることができる。
【0049】
さらに別の例として、本技術は、ユーザ入力なしに自動的に実施されてもよい。この例では、情報は、表示されないか、そうでなければ個人に伝達されない。例えば、１つ以上の基準を満たした場合に配送提案が自動的に受諾／拒否されるように、配送提案の受諾／拒否のための１つ以上の基準を設定することができる。例示すると、配送提案は、配送コストが閾値コストを下回る（または上回る）場合、配送の推定時間量が閾値時間量を下回る（または上回る）場合、配送の推定ピックアップ時間が特定の時間の前（または後）である場合、配送の推定ドロップオフ時間が特定の時間の前（または後）である場合などに、受諾（または拒否）されてもよい。このように、場合によっては、配送に関する情報は、アイテム取得インタフェース１２０を介して表示されないことがある。
【0050】
同様に、予約の場合、予約要求は、ＡＰＩ呼び出しを介して、商人デバイスを介して商人によって、顧客デバイスを介して顧客によって、商人または顧客によって行われた設定を通じて第三者デバイスによって、または、商人と顧客との間の取引の機械学習に基づいてコンセンサスサービスを通じて自動的に、開始されてもよい。コンテンツの集約および分析のために、カスタマイズされたメニューを押すこと、または異なるサービスにわたってメニューを調和させることなどのコンテンツ調和要求、ＡＰＩ呼出しを介したコンテンツ要求は、商人デバイスを通じて商人によって、顧客デバイスを通じて顧客によって、商人または顧客によって行われた設定を通じて第三者デバイスによって、または、商人と顧客との間の取引の機械学習に基づいてコンセンサスサービスを通じて自動的に、開始されてもよい。
【0051】
図２は、図１のサービスプロバイダ１０２（または場合によってはサービスプロバイダ１１６）の例示的な詳細を示す。サービスプロバイダ１０２は、サーバ、ラップトップコンピュータ、デスクトップコンピュータなどの１つ以上のコンピューティングデバイスとして実装することができる。１つ以上のコンピューティングデバイスは、クラスタ、ファーム、データセンタ、クラウドコンピューティング環境、またはそれらの組合せで構成することができる。一例では、１つ以上のコンピューティングデバイスは、計算リソース、記憶リソースなどを含むクラウドコンピューティングリソースを提供する。サービスプロバイダ１０２の１つ以上のコンピューティングデバイスは、１つ以上のプロセッサ２０２、メモリ２０４、および１つ以上のネットワークインタフェース２０６を含んでもよい。１つ以上のプロセッサ２０２は、中央演算処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、マイクロプロセッサ、デジタル信号プロセッサなどを含むことができる。
【0052】
メモリ２０４は、１つ以上の「モジュール」として構成されたソフトウェア機能を含むことができる。用語「モジュール」は、議論のためにソフトウェアの例示的な分割を表すことを意図しており、任意のタイプの要件または必要な方法、やり方、または必要な編成を表すことを意図していない。したがって、様々な「モジュール」または構成要素が議論されているが、それらの機能および／または同様の機能は異なるように配置することができる（たとえば、より少ない数のモジュールに組み合わされ、より多くのモジュールに分割されるなど）。さらに、特定の機能はここではプロセッサによって実行されるように構成されたソフトウェアモジュールとして実装されるものとして説明されるが、他の実施形態では、機能のいずれかまたはすべてが、ハードウェア論理コンポーネントによって全体的または部分的に実装されてもよい（例えば、実行されてもよい）。例えば、限定はしないが、使用することができる例示的なタイプのハードウェア論理構成要素には、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、プログラム固有標準製品（ＡＳＳＰ）、システムオンチップシステム（ＳＯＣ）、複合プログラマブル論理デバイス（ＣＰＬＤ）などが含まれる。図示のように、メモリ２０４は、コンセンサスサービス２０７、推奨モジュール２０８、コンテンツ集約モジュール２１０、第三者サービスモジュール２１２、及び支払取引モジュール２１４を含むことができる。
【0053】
コンセンサスサービス２０７は、ＡＰＩエンドポイントを介して、第三者サービス、および商人および／またはユーザデバイス上で実行される他のアプリケーションとインタフェースすることができる。コンセンサスサービス２０７は、第三者サービスおよび商人に関連するデータベースとインタフェースするように構成することもできる。一実装形態では、コンセンサスサービス２０７は、プッシュ機構／プル機構／またはプッシュプル機構を介して、第三者サービス１０８および／または商人もしくはユーザデバイスから情報を受信し、インテリジェントな方法で要求をスケジュールし、様々なルールおよびフィルタを異なるソースから入ってくる要求に適用することによって、統合された方法で商人に注文を表示する。コンセンサスサービスは、ヒューリスティック（発見的）モデルまたは機械学習モデルに基づいて、特定の第三者サービスに要求を委任することもできる。
【0054】
推奨モジュール２０８は、サービスプロバイダ１０２に関連付けられた配送サービスによるアイテムの配送に関する配送提案などの提案を生成するための処理を実行することができる。別の種類の提案は、レストランでのユーザの予約に関する予約を示す予約提案、またはいくつかのユーザ予約要求に関連する座席表であってもよい。さらに別の種類の提案は、例えば、商人のキッチンディスプレイシステムからトリガされて、第三者サービスにプッシュするメニュー更新であってもよい。この場合、情報１３０は、商人デバイスから第三者サービスに流れ、例えばユーザデバイス１０４上で実行される。多くの場合、サービスプロバイダ１０２は、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）２１６を介して配送提案の要求を受信し、それに応答して、配送提案を生成し、その配送提案を要求エンティティに送信することができる。配送提案の要求に含まれる情報については、図３を参照して以下でさらに詳細に説明する。推奨モジュール２０８は、配送提案の要求に含まれる情報、商人の現在または過去の注文の状況、準備時間、および第三者サービス情報データストア２１８または他の場所に格納された第三者サービスに関する情報（例えば、第三者サービスの現在位置、第三者サービスプロファイル情報、処理された注文に関連する第三者データ、注文タイミング、注文ラグなど）、商人データストア２２０または他の場所に格納された商人に関する情報（例えば、商人の現在位置、商人プロファイル情報など）、ユーザに関する情報（例えば、ユーザの現在位置、ユーザプロファイルなど）などに基づいて、配送提案を生成することができる。
【0055】
第三者サービスプロファイル情報には、（ｉ）第三者サービスが配送を行うための平均時間（例えば、マイル当たりの平均時間、全平均移動時間等）を示す第三者サービスの配送履歴情報、（ｉｉ）第三者サービスが配送ピックアップおよび／またはドロップオフについて時間通りであるか否かを示す情報、（ｉｉｉ）第三者サービスがアイテムを移送するために使用する車両または車両の種類を示す車両情報（例えば、バイク、自動車、バン、トラック等）、（ｉｖ）第三者サービスが一般的にどこに位置するかを示す履歴位置情報（例えば、ホームの住所、第三者サービスが特定の時間以上位置する施設等）等が含まれる。
【0056】
商人プロファイル情報には、（ｉ）ピックアップのためのアイテムまたはアイテムの種類を準備する（例えば、アイテムを調理する、アイテムを製造する等）ための時間量（例えば、正確、平均、推定等）を示すアイテム準備情報、（ｉｉ）商人が取得のために提供するアイテムに関するアイテム情報（例えば、アイテム識別子、アイテムコスト／重量／体積／サイズ／カテゴリに関する情報等）、（ｉｉｉ）アイテムを移送するために商人が使用するパッケージに関する情報（例えば、配送ボックスのサイズ、形状、重量、体積等）等が含まれる。
【0057】
配送提案の一部であってもよい例示的な情報は以下を含む：
●アイテムの配送コスト－アイテムを配送するためにサービスプロバイダ１０２の配送サービスを使用するための価格（例えば、レストランから食べ物をピックアップし、それを顧客の位置に配送するための第三者サービスに対する６ドルの料金）。配送コストは、アイテムの特性、例えば、アイテムのサイズ、形状、重量、体積、タイプ等（例えば、より大きい又はより重いアイテムはより多くのコストがかかり得る、奇妙な形状のアイテム（所定の形状を有するアイテム）はより多くのコストがかかり得る、脆弱な（壊れやすい）アイテムは非脆弱なアイテムよりもコストがかかり得る）、第三者サービスに関する情報（例えば、コストは第三者サービスからピックアップ位置までの距離で増加し得る、利用可能な第三者サービスの数が減少することにつれてコストが増加し得る）、商人によるアイテムの準備時間に関する情報（例えば、準備時間が減少（又は増加）するにつれてコストが増加（又は減少）し得る）、ピックアップの位置（例えば、特定のポイントからピックアップ位置までの距離が増加するにつれてコストが増加し得る）、ドロップオフの位置（例えば、コストは特定のポイントからドロップオフ位置までの距離が増加するにつれて増加し得る）、時刻（例えば、コストは、夕方などのピーク配送時間中は増加し得る）などの要因に基づいて変化し得る。
●アイテムの配送のための時間量（例えば、推定時間量－配送には２０～３０分を要する）。時間量は一般に、第三者サービスがアイテムを取得してそのアイテムをドロップオフ位置に移送する時間であってもよい。しかしながら、いくつかの例では、時間量は、商人によってアイテムを準備する時間を含むことができる（例えば、時間量は、アイテムを注文してからそれが顧客の位置に到着するまでの合計時間を含むことができる）。配送のための時間量は、アイテムの特性、例えば、アイテムのサイズ、形状、重量、体積、タイプ等（例えば、より大きい又はより重いアイテムは配送するためにより多くの時間を要し得る、奇抜な形状のアイテム（所定の形状を有するアイテムは配送するためにより多くの時間を要し得る、脆弱な（壊れやすい）アイテムは非脆弱なアイテムよりも多くの時間を要し得る）、第三者サービスに関する情報（例えば、第三者サービスからピックアップ位置までの距離が増加するにつれて配送のための時間量が増加し得る、利用可能な第三者サービスの数が減少するにつれて配送のための時間量が増加し得る、等）、時刻（例えば、ラッシュアワーの間のようなピーク移動時間の間に時間量が増加し得る）などの要因に基づいて変化し得る。
●アイテムの配送のためのピックアップ時間（例えば、第三者サービスがアイテムをピックアップする推定日時、週、月、年等）。ピックアップ時間は、アイテムが顧客への配送のために商人の位置からピックアップされるときであってもよい。場合によっては、ピックアップ時間は、時間ウィンドウ（例えば、２～２：３０ＰＭ）である。さらに、場合によっては、配送提案は、第三者サービスがアイテムをピックアップする最新の時間に関する期限を含むことができる。ピックアップ時間は、第三者サービスに関する情報（例えば、ピックアップ時間は、第三者サービスからピックアップ位置までの距離が増加するにつれてより遠くに移動することができ、ピックアップ時間は、利用可能な第三者サービスの数が減少するにつれてより遠くに移動するなど）、時刻（例えば、ピックアップ時間は、ラッシュアワーなどのピーク配送時間中により遠くに移動するなど）などの要因に基づいて変化し得る。
●アイテムの配送のためのドロップオフ時間（例えば、第三者サービスがアイテムをドロップオフする推定日時、週、月、年等）。ドロップオフ時間は、アイテムが顧客の位置でドロップオフされるときであってもよい。場合によっては、ドロップオフ時間は、時間ウィンドウ（例えば、３～４ＰＭ）である。ドロップオフ時間は、アイテムの特性、例えば、アイテムのサイズ、形状、重量、体積、タイプなど（例えば、より大きいまたはより重いアイテムは配送により多くの時間を要し得る、奇抜な形状のアイテム（所定の形状を有するアイテム）は配送により多くの時間を要し得る、脆弱な（壊れやすい）アイテムは非脆弱なアイテムより多くの時間を要し得る）、第三者サービスに関する情報（例えば、ドロップオフ時間は、第三者サービスからピックアップ位置までの距離が増加するにつれて、より遠くに移動し得る、ドロップオフ時間は、利用可能な第三者サービスの数が減少するにつれて、より遠くに移動し得る）、時刻（例えば、ドロップオフ時間は、ラッシュアワー中などのピーク配送時間中により遠くに移動する）などの要因に基づいて変化し得る。
●配送提案が期限切れとなる時期。場合によっては、配送提案は、特定の時間（例えば、時刻、曜日、月、年など）までに受諾されない場合、期限切れになることがある。したがって、配送提案は、期限切れの時間（例えば、明日の午後２時、配送提案の受信から２時間など）に関連付けられてもよい。
●例えば、注文が行われた第三者サービスが配送人または他の技術的困難性のために不可能である場合に、発注を提供することができる第三者サービス。
●キッチンディスプレイシステムのためのアイテムのシーケンス。アイテムは、異なるソースからの注文のために単一のタブレットを商人が保持できるようにするために、注文ＩＤまたはアイテム準備時間のいずれかによって配列される。
●キッチンディスプレイシステムが、注文の更新を第三者サービスに示すための準備タイムラインまたは配送タイムライン。
●アイテムの配送コスト－アイテムを配送するためにサービスプロバイダ１０２の配送サービスを使用するための価格（例えば、レストランから食べ物をピックアップし、それを顧客の位置に配送するための第三者サービスに対する６ドルの料金）。配送コストは、アイテムの特性、例えば、アイテムのサイズ、形状、重量、体積、タイプ等（例えば、より大きい又はより重いアイテムはより多くのコストがかかり得る、奇妙な形状のアイテム（所定の形状を有するアイテム）はより多くのコストがかかり得る、脆弱な（壊れやすい）アイテムは非脆弱なアイテムよりもコストがかかり得る）、第三者サービスに関する情報（例えば、コストは第三者サービスからピックアップ位置までの距離で増加し得る、利用可能な第三者サービスの数が減少することにつれてコストが増加し得る）、商人によるアイテムの準備時間に関する情報（例えば、準備時間が減少（又は増加）するにつれてコストが増加（又は減少）し得る）、ピックアップの位置（例えば、特定のポイントからピックアップ位置までの距離が増加するにつれてコストが増加し得る）、ドロップオフの位置（例えば、コストは特定のポイントからドロップオフ位置までの距離が増加するにつれて増加し得る）、時刻（例えば、コストは、夕方などのピーク配送時間中は増加し得る）などの要因に基づいて変化し得る。
●アイテムの配送のための時間量（例えば、推定時間量－配送には２０～３０分を要する）。時間量は一般に、第三者サービスがアイテムを取得してそのアイテムをドロップオフ位置に移送する時間であってもよい。しかしながら、いくつかの例では、時間量は、商人によってアイテムを準備する時間を含むことができる（例えば、時間量は、アイテムを注文してからそれが顧客の位置に到着するまでの合計時間を含むことができる）。配送のための時間量は、アイテムの特性、例えば、アイテムのサイズ、形状、重量、体積、タイプ等（例えば、より大きい又はより重いアイテムは配送するためにより多くの時間を要し得る、奇抜な形状のアイテム（所定の形状を有するアイテムは配送するためにより多くの時間を要し得る、脆弱な（壊れやすい）アイテムは非脆弱なアイテムよりも多くの時間を要し得る）、第三者サービスに関する情報（例えば、第三者サービスからピックアップ位置までの距離が増加するにつれて配送のための時間量が増加し得る、利用可能な第三者サービスの数が減少するにつれて配送のための時間量が増加し得る、等）、時刻（例えば、ラッシュアワーの間のようなピーク移動時間の間に時間量が増加し得る）などの要因に基づいて変化し得る。
●アイテムの配送のためのピックアップ時間（例えば、第三者サービスがアイテムをピックアップする推定日時、週、月、年等）。ピックアップ時間は、アイテムが顧客への配送のために商人の位置からピックアップされるときであってもよい。場合によっては、ピックアップ時間は、時間ウィンドウ（例えば、２～２：３０ＰＭ）である。さらに、場合によっては、配送提案は、第三者サービスがアイテムをピックアップする最新の時間に関する期限を含むことができる。ピックアップ時間は、第三者サービスに関する情報（例えば、ピックアップ時間は、第三者サービスからピックアップ位置までの距離が増加するにつれてより遠くに移動することができ、ピックアップ時間は、利用可能な第三者サービスの数が減少するにつれてより遠くに移動するなど）、時刻（例えば、ピックアップ時間は、ラッシュアワーなどのピーク配送時間中により遠くに移動するなど）などの要因に基づいて変化し得る。
●アイテムの配送のためのドロップオフ時間（例えば、第三者サービスがアイテムをドロップオフする推定日時、週、月、年等）。ドロップオフ時間は、アイテムが顧客の位置でドロップオフされるときであってもよい。場合によっては、ドロップオフ時間は、時間ウィンドウ（例えば、３～４ＰＭ）である。ドロップオフ時間は、アイテムの特性、例えば、アイテムのサイズ、形状、重量、体積、タイプなど（例えば、より大きいまたはより重いアイテムは配送により多くの時間を要し得る、奇抜な形状のアイテム（所定の形状を有するアイテム）は配送により多くの時間を要し得る、脆弱な（壊れやすい）アイテムは非脆弱なアイテムより多くの時間を要し得る）、第三者サービスに関する情報（例えば、ドロップオフ時間は、第三者サービスからピックアップ位置までの距離が増加するにつれて、より遠くに移動し得る、ドロップオフ時間は、利用可能な第三者サービスの数が減少するにつれて、より遠くに移動し得る）、時刻（例えば、ドロップオフ時間は、ラッシュアワー中などのピーク配送時間中により遠くに移動する）などの要因に基づいて変化し得る。
●配送提案が期限切れとなる時期。場合によっては、配送提案は、特定の時間（例えば、時刻、曜日、月、年など）までに受諾されない場合、期限切れになることがある。したがって、配送提案は、期限切れの時間（例えば、明日の午後２時、配送提案の受信から２時間など）に関連付けられてもよい。
●例えば、注文が行われた第三者サービスが配送人または他の技術的困難性のために不可能である場合に、発注を提供することができる第三者サービス。
●キッチンディスプレイシステムのためのアイテムのシーケンス。アイテムは、異なるソースからの注文のために単一のタブレットを商人が保持できるようにするために、注文ＩＤまたはアイテム準備時間のいずれかによって配列される。
●キッチンディスプレイシステムが、注文の更新を第三者サービスに示すための準備タイムラインまたは配送タイムライン。
【0058】
コンテンツ集約モジュール２１０は、メニュー更新、配送の進行に関する配送情報、予約リストなど、集約されたデータに基づいて分析情報を提供することができる。例えば、コンテンツ集約モジュール２１０は、１つ以上のＡＰＩ２１６を介して、配送ステータス更新の要求を受信し、その応答として、配送ステータスに関する情報を生成し、その情報を要求エンティティに送信することができる。他の例では、配送のステータスに関するそのような情報は、自動的に、および／または別のイベントの発生時に生成され、送信され得る。コンテンツ集約モジュール２１０は、第三者サービスの位置、商人の位置におけるアイテムのピックアップの確認および／または顧客の位置におけるドロップオフに関する第三者サービスからのインジケーション（指標、指示）、ピックアップの確認を示す商人からの通信、アイテムを準備するステータスに関する商人からの通信（例えば、料理を調理するために残された時間量）など、様々な情報に基づいて配送のステータスに関する情報を生成することができる。したがって、コンテンツ集約モジュール２１０は、配送人に関する位置情報を受信するために、第三者サービスモジュール２１２と通信してもよい。
【0059】
第三者サービスモジュール２１２は、第三者サービスを管理することができる。例えば、第三者サービスモジュール２１２は（配送前、配送中、および／または配送後の）第三者サービスに関連付けられた配送人の位置を追跡し、配送のために第三者サービスを選択し、配送を容易にするために第三者サービスと通信し、配送ステータスに関する更新を提供し、様々な時刻および／または曜日の様々な配送位置への第三者サービスの移動時間を予測することなどができる。そうするために、第三者サービスモジュール２１２は、配送提案の要求に含まれる情報、配送ステータス更新の要求に含まれる情報、第三者サービス情報データストア２１８または他の場所に格納された第三者サービスに関する情報（例えば、第三者サービスの現在位置、第三者サービスプロファイル情報など）、商人データストア２２０または他の場所に格納された商人に関する情報（例えば、商人の現在位置、商人プロファイル情報など）、買い手に関する情報（例えば、買い手の現在位置、ユーザプロファイルなど）などの様々な情報を分析することができる。いくつかの例では、第三者サービスモジュール２１２は、アクティブ化、移動、ポジショニング、および／または非アクティブ化を通じて、たとえばＡＰＩを通じて、第三者サービスを管理することができる。
【0060】
一例として、第三者サービスモジュール２１２は、第三者サービスを選択して、その配送人がアイテムを商人から買い手に移送するのを容易にすることができる。場合によっては、第三者サービスは、１つ以上のＡＰＩ２１６を介して配送提案の受諾を受信することに応答して選択される。他の例では、配送は他のイベントの発生に応じてアレンジされる。第三者サービスモジュール２１２は、商人の位置に対する第三者サービスの位置（例えば、ピックアップ位置に最も近い第三者サービスを選択する）、第三者サービスの利用可能性（例えば、利用可能な第三者サービスを選択する）、アイテムを移送するために第三者サービスによって使用される車両のタイプ（例えば、配送されるそのタイプのアイテムを移送することができる第三者サービスを選択する）、配送されるアイテムに関する情報（例えば、サイズ、形状、体積、タイプなど）などのような、第三者サービスを選択するために様々な情報を使用することができる。次いで、第三者サービスモジュール２１２は、選択された第三者サービスと通信して、配送を手配（アレンジ）することができる。サービスプロバイダ１０２は、移送するアイテムの数、商人（または複数のアイテムが配送される場合には複数の商人）の位置、要求されたピックアップ時間および／またはドロップオフ時間などに関する情報を提供することができる。配送のために複数の移動が必要であると判定された場合（例えば、配送されるアイテムの数、配送されるアイテムのサイズ、第三者サービスの移送能力（キャパシティ）などに起因して）、第三者サービスモジュール２１２は、第三者サービスに複数の移動を通知し、かつ／または複数の第三者サービスに命令を送信して、配送を行うことができる。さらに、第三者サービスモジュール２１２は、緊急ではなく、第三者サービスのために閾値数未満の配送がスケジュールされるダウンタイム期間中に実行され得る配送を第三者サービスに対して通知する。第三者サービスモジュール２１２は、第三者サービスに期間を通知することができ（例えば、「今週のいつでも午後８時から午後１０時の間に配送を実行する」）、または第三者サービスは、１日、１週間などを通して時間が空いているので、配送を行うことができる。多くの場合、第三者サービスモジュール２１２は、エンティティに配送サービスを公開するために使用される１つ以上のＡＰＩ２１６よりも、非ＡＰＩチャネルおよび／または別個のチャネルを通じて第三者サービスと通信する。
【0061】
支払取引モジュール２１４は、商人、ユーザ、および／または第三者サービスの間の支払取引を容易にすることができる。例えば、取引モジュール２１４は、取引に関する注文を受信し、取引を処理し、取引に関する取引情報を生成および／または格納することなどができる。取引中、ユーザ（例えば、顧客）は、購入、レンタル、リース、借用、ライセンス供与などによって、商人からアイテムを取得することができる。アイテムは、商人によって提供される商品および／またはサービスを指すことができる。取引に対して支払うとき、ユーザは、商人に支払われるべき支払額を提供することができる。場合によっては、取引は、ユーザに関連付けられた金融口座から商人に関連付けられた金融口座に資金を電子的に転送することによって処理されてもよい。いくつかの例では、取引モジュール２１４は、安全な電子金融取引を実行するように構成された１つ以上のコンピューティングデバイスによって実装され得る。
【0062】
支払取引モジュール２１４は、様々なチャネルを介して開始される支払取引を容易にすることができる。一例として、ユーザは、商人に注文を行うためにユーザデバイスと対話することができる。ここで、サービスプロバイダ１０２は、注文を履行するために商人と通信することができる（例えば、注文が出されたことを商人に通知し、注文を履行するよう商人に要求するなど）。別の例として、商人は、商人デバイスと対話して、ユーザに代わって注文を行うことができる。ここで、ユーザは電話、本人、通知（例えば、テキストメッセージ、電子メール、ソーシャルメディアなど）などを介して商人と通信して、商人に注文を行うことを望むことを示すことができる。これらの例のいずれにおいても、ユーザは注文時、アイテムが配送されている間、ドロップオフ時（例えば、第三者サービスデバイスと対話する）など、いつでも支払いを提供することができる。
【0063】
ユーザは、現金、小切手、支払カード、近距離無線通信（ＮＦＣ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、口座、電子支払いなどの様々な方法を介して支払いを提供することができる。いくつかの例では、支払取引モジュール２１４は、ユーザとユーザデバイスとの対話、および商人と商人デバイスとの対話に基づいて、ユーザと商人との間の取引のためのカードレス支払いを可能にする。したがって、いくつかの例では、カードレス支払い取引は、ＰＯＳ位置で行われる取引を含むことができ、その間に、ユーザの電子支払口座は、ユーザがＰＯＳ位置で商人に支払カードを物理的に提示する必要なしに課金される。その結果、商人は、処理される取引のためにユーザの金融口座に関する詳細を受け取る必要がない。一例として、電子支払いは、電子支払口座についてサービスプロバイダ１０２にサインアップするときにユーザが提供したクレジットカード発行者またはクレジットカード番号に課金されてもよい。別の例として、ユーザは、電子支払いを行う際に使用するために維持される口座に前払いされた金額を有することができる。他の変形も当業者には明らかであろう。
【0064】
場合によっては、支払取引モジュール２１４は、取引情報データストア２２２に取引情報を格納することができる。取引情報は、商人デバイス、買い手デバイス、第三者サービスデバイスから受信され、および／またはサービスプロバイダ１０２によって生成されてもよい。取引情報は、取引の時間、場所、および／または量に関する情報、取得されたアイテムに関連する情報（例えば、販売されたアイテムを識別する情報）、使用されている支払いのタイプ（例えば、現金、小切手、支払カード、電子支払いなど）、ならびに買い手情報などの追加情報を含むことができる。例えば、支払カードが使用される場合、取引情報は、支払カードに記憶されたデータ（例えば、トラック１のデータ（カード所持者名、カード番号および他のカード情報））を含むことができる。さらに、取引を完了するとき、買い手は、時には電子メールを介してレシートを受け取るためのレシート電子メールアドレスを提供することができる。取り込むことができる取引情報の他の例には、アイテム情報（例えば、取得されているアイテムの項目別リスト、各アイテムについて支払われている価格、アイテムの記述（サイズ、風味、色など））、特定の取引の地理的POS(Point of Sale)位置を示す地理的位置データ、オンライン／オフラインカードデータ、商人を記述するデータ（例えば、商人識別子、商人カテゴリコード（ＭＣＣ）など）、配送提案の要求に含まれる情報、配送提案に含まれる情報、買い手のソーシャルネットワークへの認証時に受信される任意のタイプのデータ、および／または様々な他のタイプの情報が含まれる。いくつかの例では、取引情報は、商人データストア２２０に商人に関する情報を格納するために使用されてもよい（例えば、商人によって提供されるアイテムのコストは、商人の施設での取引に関する取引情報から取得されてもよい）。
【0065】
図２は、サービスプロバイダ１０２の構成要素およびデータが単一の場所に存在するものとして示しているが、これらの構成要素およびデータは代替的に、任意の方法で異なるコンピューティングデバイスおよび／または異なる位置にわたって分散させることができる。その結果、機能は、１つ以上のコンピューティングデバイスによって実現されてもよく、説明されている様々な機能は様々なコンピューティングデバイスにわたって様々な方法で分散される。複数のコンピューティングデバイスは、一緒にまたは別々に配置され、例えば、仮想サーバ、サーババンク、および／またはサーバファームとして編成されてもよい。説明される機能は、単一のエンティティまたは企業のサーバによって提供されてもよく、または複数の異なる買い手または企業のサーバおよび／またはサービスによって提供されてもよい。
【0066】
図３は、商人デバイス３００の例示的な詳細を示す。例えば、商人デバイス３００は、図１の商人１０６によって使用されてもよい。商人デバイス３００は、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、スマートフォン、電子リーダデバイス、モバイルハンドセット、携帯情報端末（ＰＤＡ）、ポータブルナビゲーションデバイス、ポータブルゲームデバイス、タブレットコンピュータ、ウェアラブルコンピュータ（例えば、スマートウォッチ、光学ヘッドマウントディスプレイ（ＯＨＭＤ）など）、ポータブルメディアプレーヤ、テレビ、セットトップボックス、自動車内のコンピュータシステム、機器、カメラ、ロボット、ホログラムシステム、セキュリティシステム、ホームベースのコンピュータシステム（例えば、インターコムシステム、ホームメディアシステムなど）、プロジェクタ、現金自動預け払い機（ＡＴＭ）などとして実装され得る。いくつかの実施態様では、商人デバイス３００は、配送サービス、予約サービス、メニューサービス、レビューサービスなどの第三者サービスを実行することができる。商人デバイス３００は、一実施形態では、１つ以上のコンセンサスサービス２０７を介して第三者サービスおよび他のサービスとインタフェースすることができる。一例では、サービスプロバイダは、第三者サービスおよび商人デバイス３００と通信するためのＡＰＩエンドポイントを提供し、ＡＰＩエンドポイントは、サービスプロバイダがアクセスするためのＡＰＩエンドポイント１１４を提供してもよいし、しなくてもよい。従って、サービスプロバイダのコンセンサスサービス２０７は、外部サービスからデータをプルし、プッシュし、またはプッシュおよびプルすることができるかもしれない。
【0067】
商人デバイス３００はまた、入ってくる注文、予約、アポイントメント、通知、更新、警告などを管理するために、追加のデバイスに関連付けられてもよい。例えば、商人デバイス３００は、キッチンディスプレイシステムに接続された、またはキッチンディスプレイシステムを含む、１つ以上のタブレットに関連付けられてもよい。典型的には、キッチンディスプレイシステムは、様々な第三者サービスから入ってくる注文を自分自身のタブレット上に表示するように構成される。しかしながら、本明細書に記載される実施態様を使用して、ソースに関係なくすべての注文が同期され、単一のタブレット上に提示されて取り扱われるように構造化されるように、タブレットは１つに統合されてもよい。同様に、予約のために、商人デバイス３００は、占有性／利用可能性に関する物理的空間を追跡するオンサイト予約システムに関連付けられてもよい。
【0068】
商人デバイス３００は、１つ以上のプロセッサ３０２、メモリ３０４、１つ以上のネットワークインタフェース３０６、および１つ以上のディスプレイ３０８を含み得る。１つ以上のプロセッサ３０２は、中央演算処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、マイクロプロセッサ、デジタル信号プロセッサなどを含むことができる。１つ以上のディスプレイ３０８は、タッチスクリーン、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ、有機ＬＥＤディスプレイ、プラズマディスプレイ、電子ペーパーディスプレイ、または任意の他のタイプの技術を含むことができる。図示されていないが、商人デバイス３００は、カメラ、マイクロフォン、スピーカ、プロジェクタ、プリンタ、および／またはセンサなどの他の構成要素を含むか、またはそれらに関連付けられてもよい。１つ以上のカメラは、前面カメラおよび／または後面カメラを含むことができる。１つ以上のセンサは加速度計、コンパス、ジャイロスコープ、磁力計、全地球測位システム（ＧＰＳ）、嗅覚センサ（例えば、におい用）、または別のセンサを含んでもよい。商人デバイス３００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスさらに含むか、またはそれらに関連付けられてもよい。メモリ３０４は、商人モジュール３１０および位置モジュール３１２を含むことができる。
【0069】
商人モジュール３１０（および／または位置モジュール３１２）は、一般に商人によって使用され得る商人対面コンポーネントを表し得る。いくつかの例では、顧客は、（例えば、支払いを確認し、配送情報を提供し、または他の入力を提供するために）商人対面コンポーネントと対話することができる。商人モジュール３１０は、商人が顧客との取引を容易にすること、配送を管理すること、在庫を管理することなどを支援するために、種々の処理を実行することができる。商人モジュール３１０は、様々なインタフェースおよび／またはダッシュボードを提供することができる。場合によっては、商人モジュール３１０は、配送注文、予約注文、およびメニュー更新／選好のための取得アプリケーションなどのアプリケーションと呼ばれてもよい。
【0070】
商人モジュール３１０は、サービスプロバイダ１０２と通信して、サービスプロバイダ１０２によって提供される配送サービスを使用することができる。一例として、商人は、商人モジュール３１０によって提供されるアイテム取得インタフェース（例えば、アイテム取得インタフェース１２０）と対話して、顧客のために注文を行うことができる。商人モジュール３１０が配送が要求され得ると判定した場合（例えば、注文が配送されることを望むことを示す顧客に基づく自動判定など）、商人モジュール３１０は、配送提案の要求を生成し、サービスプロバイダ１０２によって推奨される配送サービスの使用に関する情報を要求するために、１つ以上のＡＰＩを介してサービスプロバイダ１０２に要求を送信することができる。要求の情報は、顧客または商人によって提供されたり、データソース（例えば、ユーザプロファイル、商人プロファイルなど）から取得されたりしてもよい。配送提案の要求の一部であり得る例示的な情報は、以下を含む：
●アイテムのピックアップ位置－顧客への配送のために商人からアイテムが取得される位置。ピックアップ位置は、一般に、商人の位置（例えば、施設）であってもよいが、倉庫、住宅、ＰＯボックス、街角などの任意の位置が使用されてもよい。ピックアップ位置は、（例えば、移動する商人の場合には）静止していても移動していてもよい。
●ドロップオフ位置（配送位置とも呼ばれる）－アイテムが顧客に配送される位置。ドロップオフ位置は、一般に、住宅、ＰＯボックス、街角、顧客が現在位置する施設などの顧客の位置とすることができる。ドロップオフ位置は、（例えば、移動する顧客の場合には）静止していても移動していてもよい。
●要求されたピックアップ時間－配送のために商人からアイテムを取得するための時間、週、月、年など。ピックアップの要求された時間は、特定の時間、時間のウィンドウなどであってもよい。場合によっては、要求されたピックアップ時間は、（例えば、アイテムがすでに作成されている場合、または他の状況において）できるだけ早くてもよい。配送提案の要求においてピックアップ時間が指定されていない場合、サービスプロバイダ１０２は、例えば、ピックアップ時間ができるだけ早いと仮定することができる。
●取得されるアイテムの量（数）－商人から購入されるアイテムの量。場合によっては、サービスプロバイダ１０２は、この情報を使用して、注文のサイズ（例えば、注文を移送するために必要なスペースの量）を判定することができる。
●取得されるアイテムを識別するアイテム識別子。場合によっては、サービスプロバイダ１０２は、この情報を使用して、注文を移送するためにどれだけのスペースが必要であるか、アイテムを移送するために必要な車両のタイプ、アイテムのタイプ（例えば、脆弱対非脆弱、腐敗対非腐敗など）などを判定するために、アイテムに関する情報をルックアップすることができる。
●取得されるアイテムの特性（例えば、サイズ、形状、重量、ボリューム、タイプ、カテゴリなど）。場合によっては、サービスプロバイダ１０２がこの情報を使用して、アイテムを移送するために必要な空間の量を判定することができる。
●取得されるアイテムに関連付けられたタグ（例：特定のカテゴリを示すタグ）。例えば、アイテムは、配送のために特別な取扱いを必要とする食品のカテゴリに関連付けられた所定のラベルでタグ付けされてもよい（例えば、暖かく及び／又は直立した状態に保つ必要があるピザ又はスープ、特別な取扱いを必要とするトレイ上の食品などの仕出し料理、注意深く取り扱われる必要があるテレビなど）。いくつかの例では、サービスプロバイダ１０２は、この情報を使用して、注文を移送するためにどれだけのスペースが必要であるか、アイテムを移送するために必要な車両のタイプ、アイテムのタイプ（例えば、脆弱対非脆弱、腐敗対非腐敗など）などを判定することができる。
●注文の価格（例えば、アイテムまたは注文のコスト）。
●アイテムに関するピックアップ命令。例えば、商人は、自転車が店舗の後部で配送のためにピックアップされることを指定することができる。
●アイテムに関する配送指示。例えば、顧客は、特定の時間ウィンドウの間に、顧客のプロパティに関する特定のスポットで、特定のタイプの車両で、特定の第三者サービスなどによって、アイテムが配送されることを要求することができる。
●顧客連絡先情報（例えば、電話番号、電子メールアドレス、顧客の地理的位置など）。一例として、顧客連絡先情報は、顧客の住所を含むことができる。
●アイテムのピックアップ位置－顧客への配送のために商人からアイテムが取得される位置。ピックアップ位置は、一般に、商人の位置（例えば、施設）であってもよいが、倉庫、住宅、ＰＯボックス、街角などの任意の位置が使用されてもよい。ピックアップ位置は、（例えば、移動する商人の場合には）静止していても移動していてもよい。
●ドロップオフ位置（配送位置とも呼ばれる）－アイテムが顧客に配送される位置。ドロップオフ位置は、一般に、住宅、ＰＯボックス、街角、顧客が現在位置する施設などの顧客の位置とすることができる。ドロップオフ位置は、（例えば、移動する顧客の場合には）静止していても移動していてもよい。
●要求されたピックアップ時間－配送のために商人からアイテムを取得するための時間、週、月、年など。ピックアップの要求された時間は、特定の時間、時間のウィンドウなどであってもよい。場合によっては、要求されたピックアップ時間は、（例えば、アイテムがすでに作成されている場合、または他の状況において）できるだけ早くてもよい。配送提案の要求においてピックアップ時間が指定されていない場合、サービスプロバイダ１０２は、例えば、ピックアップ時間ができるだけ早いと仮定することができる。
●取得されるアイテムの量（数）－商人から購入されるアイテムの量。場合によっては、サービスプロバイダ１０２は、この情報を使用して、注文のサイズ（例えば、注文を移送するために必要なスペースの量）を判定することができる。
●取得されるアイテムを識別するアイテム識別子。場合によっては、サービスプロバイダ１０２は、この情報を使用して、注文を移送するためにどれだけのスペースが必要であるか、アイテムを移送するために必要な車両のタイプ、アイテムのタイプ（例えば、脆弱対非脆弱、腐敗対非腐敗など）などを判定するために、アイテムに関する情報をルックアップすることができる。
●取得されるアイテムの特性（例えば、サイズ、形状、重量、ボリューム、タイプ、カテゴリなど）。場合によっては、サービスプロバイダ１０２がこの情報を使用して、アイテムを移送するために必要な空間の量を判定することができる。
●取得されるアイテムに関連付けられたタグ（例：特定のカテゴリを示すタグ）。例えば、アイテムは、配送のために特別な取扱いを必要とする食品のカテゴリに関連付けられた所定のラベルでタグ付けされてもよい（例えば、暖かく及び／又は直立した状態に保つ必要があるピザ又はスープ、特別な取扱いを必要とするトレイ上の食品などの仕出し料理、注意深く取り扱われる必要があるテレビなど）。いくつかの例では、サービスプロバイダ１０２は、この情報を使用して、注文を移送するためにどれだけのスペースが必要であるか、アイテムを移送するために必要な車両のタイプ、アイテムのタイプ（例えば、脆弱対非脆弱、腐敗対非腐敗など）などを判定することができる。
●注文の価格（例えば、アイテムまたは注文のコスト）。
●アイテムに関するピックアップ命令。例えば、商人は、自転車が店舗の後部で配送のためにピックアップされることを指定することができる。
●アイテムに関する配送指示。例えば、顧客は、特定の時間ウィンドウの間に、顧客のプロパティに関する特定のスポットで、特定のタイプの車両で、特定の第三者サービスなどによって、アイテムが配送されることを要求することができる。
●顧客連絡先情報（例えば、電話番号、電子メールアドレス、顧客の地理的位置など）。一例として、顧客連絡先情報は、顧客の住所を含むことができる。
【0071】
商人モジュール３１０は、配送提案の要求に含まれる情報を提供するものとして説明されるが、場合によっては、情報は、サービスプロバイダ１０２において（少なくとも部分的に）判定されてもよい（例えば、サービスプロバイダ１０２は、アイテム識別子を受信し、アイテムサイズ、従量などを調べてもよい）。
【0072】
配送提案の要求をサービスプロバイダ１０２に提出した後、商人モジュール３１０は、サービスプロバイダ１０２から配送提案を受信することができる。場合によっては、配送提案からの情報は、顧客に伝達される。例えば、商人は、配送コスト、推定配送時間、および／または任意の他の情報を顧客に通知することができる。他の例では、配送提案からの情報は、顧客に提示されなくてもよい。例えば、商人は、配送提案の情報を見ることができ、および／または注文の総コストにそのコストを含めることができる。したがって、場合によっては、顧客には、配送が商人によって処理されているように見えることがある。いずれにしても、商人モジュール３１０は、１つ以上のＡＰＩを介して、配送提案の受諾または拒否のインジケーション（指標、指示）をサービスプロバイダ１０２に送信することができる。
【0073】
その後、商人モジュール３１０は、１つ以上のＡＰＩを介してサービスプロバイダ１０２と通信し、取引のステータスに関する情報を提供および／または受信することができる。例えば、商人モジュール３１０は、アイテムが準備処理のどこにあるか（例えば、ほぼ完了したか、完了したか、オーブンに入ったか、袋詰めされたか、ピックアップの準備ができたかなど）を示す情報を送信する。別の例では、商人モジュール３１０は、配送サービスによる配送のステータス（例えば、第三者サービスの配送人の特定の位置、第三者サービスがどれだけ離れているか、アイテムがドロップオフされているかどうか、第三者サービスに関連付けられた配送人が、ピックアップ位置に移送中であるかなど）に関する情報をサービスプロバイダから受信することができる。
【0074】
商人モジュール３１０は、様々なチャネルを介して注文を受け取ることができる。例えば、商人モジュール３１０は、商人と顧客との間の電話会話に基づく顧客の代わりに商人によって発注される第１の注文と、顧客アプリケーション上で別の顧客によって発注される第２の注文とを受信することができる。第２の注文は、サービスプロバイダ１０２および／または商人に関連付けられたサービスプロバイダなどの別の当事者から受信され得る。いずれにせよ、注文は、サービスプロバイダのＡＰＩを介して同じ商人モジュール３１０によって管理されてもよい。すなわち、商人モジュール３１０は、注文の準備、注文の準備の進行に関する情報の提示、注文の配送ステータスに関する情報の提示などを監視することができる。多くの場合、注文に関する情報は、注文を異なるチャネルから発信されたものとして指定する情報とのインタフェースを通じて提示される。
【0075】
商人モジュール３１０は、サービスプロバイダ１０２によって使用される配送サービスに対する支払いを提供するために、１つ以上のスキームを適用することができる。一例として、サービスプロバイダ１０２の配送サービスを使用するための配送コストは、顧客に請求されてもよい（例えば、アイテムごとに直接、月ごとになど）。別の例として、商人は、各事例において、または、例えば、閾値数を超えるアイテムを有する注文、閾値量を超える量を有する注文、顧客が特定のステータスに関連付けられている（例えば、顧客が配送サービスのための月次加入料を支払ったか、または経時的に特定の数のアイテムを購入した）などの１つ以上の基準が満たされた場合などに、配送コストの支払いを提供することを決定し得る（例えば、顧客に課金しない）。
【0076】
商人は、毎月、アイテムごとになどの様々な方法で、いくつかの配送サービスを接続するコンセンサスサービスの使用のためにサービスプロバイダ１０２によって請求されることができ、サービスプロバイダ１０２によって商人に支払われるべき量のバランスをとる（例えば、サービスプロバイダ１０２が商人に支払うべき量から配送サービスのコストを差し引く）。
【0077】
商人モジュール３１０は、追加的に、または代替的に、他の処理を実行してもよい。一例では、商人モジュール３１０は、（例えば、カードリーダ、顧客デバイスへのＮＦＣ接続、顧客デバイスへのＢｌｕｅｔｏｏｔｈ（登録商標）接続などを介して）顧客からの支払いを受け入れること、アイテムの領収書を提供すること（領収書を印刷することを含む）、（例えば、確認、クレジットカードの署名などの）顧客によって取得されるアイテムのための顧客からの入力を受信することなどによって、顧客との取引を容易にすることができる。別の例では、商人モジュール３１０は、商人に在庫レベル（例えば、現在在庫中のアイテムの数）を通知すること、追加の在庫を注文すること、在庫に関するサービスプロバイダ１０２からの通知を閲覧すること、他者に取得のための在庫を提供すること、在庫のための資金調達を求めることなどによって、商人が在庫を管理することを可能にすることができる。さらに別の例では、商人モジュール３１０は、販売、在庫、または他の情報のためのデータ分析を提供することができる。
【0078】
商人モジュール３１０の機能は、単一の構成要素に含まれるものとして説明されるが、機能は任意の数の構成要素に分割されてもよい。場合によっては、機能は、別々のアプリケーションに分割され、それらは互いにリンクされることがある（例えば、別のアプリケーション内のリンクを選択することによって１つのアプリケーションにアクセスする）。
【0079】
位置モジュール３１２は、商人デバイス３００の位置を判定することができる。場合によっては、位置は、サービスプロバイダ１０２に提供されるか、またはローカルで使用されて、商人の位置の判定、顧客が商人デバイス３００の特定の近傍内に位置する場合の取引の処理など、様々な機能を容易にする。位置モジュール３１２は、地理位置決め技術（例えば、衛星ベースのシステム－全地球測位システム（ＧＰＳ））、セルタワー位置データ、ワイヤレスアクセスポイント位置データ、無線ビーコン位置など）から、商人デバイス３００の地理的位置を判定することができる。したがって、位置モジュール３１２は、商人デバイス３００の地理的位置を（例えば、セルタワーまたはワイヤレスアクセスポイントから）判定することができるＧＰＳ受信機または通信インタフェースなど、商人デバイス３００の位置センサからのデータを利用することができる。
【0080】
いくつかのタイプのビジネスでは、商人デバイス３００は、商人の店または他のビジネス位置に関連付けられてもよく、したがって、通常、日々変化しない固定位置であってもよい。しかしながら、他のタイプのビジネスでは、商人デバイス３００は、商人がフードトラックを運営する場合、ストリートベンダー、キャブドライバーなどである場合、またはそうでなければモバイルビジネスを有する場合（例えば、買い手の家、ビジネス位置などでアイテムを販売する商人の場合）など、位置を時々移動することができる。
【0081】
図４は、ユーザデバイス４００の例示的な詳細を示す。例えば、ユーザデバイス４００は、図１のユーザ１０４によって使用されてもよい。ユーザデバイス４００は、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、スマートフォン、電子リーダデバイス、モバイルハンドセット、パーソナルデジタルアシスタント（ＰＤＡ）、ポータブルナビゲーションデバイス、ポータブルゲームデバイス、タブレットコンピュータ、ウェアラブルコンピュータ（例えば、スマートウォッチ、光学ヘッドマウントディスプレイ（ＯＨＭＤ）など）、ポータブルメディアプレーヤ、テレビ、セットトップボックス、自動車内のコンピュータシステム、機器、カメラ、ロボット、ホログラムシステム、セキュリティシステム、ホームベースのコンピュータシステム（例えば、インターコムシステム、ホームメディアシステムなど）、プロジェクタ、現金自動預け払い機（ＡＴＭ）などとして実装され得る。いくつかの例では、商人デバイス３００は、モバイルデバイスであってもよい。一実装形態では、ユーザデバイス４００は、配送サービス、予約サービス、メニューサービス、レビューサービスなどの第三者サービスを実行することができる。一実施形態では、ユーザデバイス４００は、１つ以上のコンセンサスサービス２０７を介して、商人デバイス３００などの商人サービスとインタフェースすることができる。一例では、サービスプロバイダは、第三者サービスおよび商人デバイス３００と通信するためのＡＰＩエンドポイント１１４を提供し、ＡＰＩエンドポイント１１４は、サービスプロバイダがアクセスするためのＡＰＩエンドポイントを提供してもよいし、しなくてもよい。従って、サービスプロバイダのコンセンサスサービス２０７は、ユーザデバイスからデータをプル、プッシュ、またはプッシュおよびプルすることができるかもしれない。第三者サービスは、たとえばサービスプロバイダと同様に、第三者サーバ上でホストすることができる。
【0082】
ユーザデバイス４００は、１つ以上のプロセッサ４０２、メモリ４０４、１つ以上のネットワークインタフェース４０６、および１つ以上のディスプレイ４０８を含み得る。１つ以上のプロセッサ４０２は、中央演算処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、マイクロプロセッサ、デジタル信号プロセッサなどを含むことができる。１つ以上のディスプレイ４０８は、タッチスクリーン、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）ディスプレイ、有機ＬＥＤディスプレイ、プラズマディスプレイ、電子ペーパーディスプレイ、または任意の他のタイプの技術を含むことができる。図示されていないが、ユーザデバイス４００はまた、カメラ、マイクロフォン、スピーカ、プロジェクタ、プリンタ、および／またはセンサなどの他の構成要素を含んでもよく、またはそれらに関連付けられてもよい。１つ以上のカメラは、前面カメラおよび／または後面カメラを含むことができる。１つ以上のセンサは、加速度計、コンパス、ジャイロスコープ、磁力計、全地球測位システム（ＧＰＳ）、嗅覚センサ（例えば、におい用）、または別のセンサを含んでもよい。ユーザデバイス４００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスさらに含むか、またはそれらに関連付けられてもよい。メモリ４０４は、顧客モジュール４１０および位置モジュール４１２を含むことができる。
【0083】
顧客モジュール４１０（および／または位置モジュール４１２）は、一般に顧客によって使用され得る顧客対面コンポーネントを表すことができる。いくつかの例では、商人が（例えば、支払いを確認し、配送情報を提供し、または他の入力を提供するために）顧客対面コンポーネントと対話することができる。顧客モジュール４１０は、顧客が商人との取引を容易にするのを支援するために、種々の処理を実行することができる。そのようにする場合、顧客モジュール４１０は、様々なインタフェースおよび／またはダッシュボードを提供することができる。いくつかの例では、顧客モジュール４１０は、アイテム取得アプリケーションなどのアプリケーションと呼ばれることがある。さらに、いくつかの例では、顧客モジュール４１０は、ピザ商人からピザを注文するために、配送サービスなどの第三者アプリケーション４０７など、商人に関連付けられたサービスプロバイダと協働して動作するローカルアプリケーションを備えることができる。
【0084】
顧客モジュール４１０は、サービスプロバイダ１０２と通信して、サービスプロバイダ１０２に関連付けられた配送サービスを使用することができる。一例として、顧客は、顧客モジュール４１０によって提供されるアイテム取得インタフェース（例えば、アイテム取得インタフェース１２０）と対話して、商人に注文を行うことができる。顧客モジュール４１０が配送が要求され得ると判定した場合（例えば、ユーザプロファイルの設定または以前の購入に基づく自動判定、注文を配送させたい旨を示す顧客入力に基づく判定など）、顧客モジュール４１０は、配送提案の要求を生成し、サービスプロバイダ１０２によって提供される配送サービスの使用に関する情報を要求するために、１つ以上のＡＰＩを介してサービスプロバイダ１０２に要求を送信することができる。要求の情報は、顧客によって提供されてもよく、データソース（例えば、ユーザプロファイルなど）から取得されてもよい。多くの場合、顧客モジュール４１０は、配送提案の要求に含まれる情報を提供するが、場合によっては、情報は、サービスプロバイダ１０２において（少なくとも部分的に）判定されてもよい（例えば、サービスプロバイダ１０２は、アイテム識別子を受信し、アイテムサイズ／従量を調査してもよく、サービスプロバイダ１０２は、顧客を識別し、顧客の好みを調査してもよい、など）。
【0085】
配送提案の要求をサービスプロバイダ１０２に提出した後、顧客モジュール４１０は、サービスプロバイダ１０２から配送提案を受信することができる。場合によっては、配送提案からの情報は、顧客に伝達される。例えば、アイテム取得インタフェースは、配送コスト、推定配送時間、および／または任意の他の情報を表示することができる。他の例では、配送提案からの情報が顧客に提示されなくてもよい。例えば、アイテム取得インタフェースは、配送コストを項目化された要素として表示せず、注文の総コストに配送コストを含めることができる。したがって、場合によっては、顧客には、配送が商人によって処理されているように見えることがある。いずれにしても、顧客モジュール４１０は、１つ以上のＡＰＩを介して、配送提案の受諾または拒否のインジケーション（指標、指示）をサービスプロバイダ１０２に送信することができる。
【0086】
顧客モジュール４１０は、取引のステータスに関する情報を要求および／または受信するために、１つ以上のＡＰＩを介してサービスプロバイダ１０２と通信することもできる。例えば、顧客モジュール４１０は、アイテムの準備のステータス（例えば、ほぼ完了した、完了した、オーブンに入った、袋詰めされた、ピックアップの準備ができた等）、配送サービスによる配送のステータス（例えば、配送人の特定の位置、配送人がどれだけ離れているか、アイテムがドロップオフされたかどうか、配送人がピックアップ位置に輸送中であるかどうか等）等に関する情報を受信することができる。このような情報は、顧客に提示することができる。一例では、配送人の位置を示すアイコンまたは他の要素と共に顧客に地図が表示される。これに加えて、またはこれに代えて、広告を表示することができる。例示すると、顧客モジュール４１０は、商人のためのアイテムを配送することに関連するオンラインサイトの広告を表示することができる。広告は、商人に直接注文する代わりに、将来注文するためにオンラインサイトを使用することを顧客に奨励することができる。他の図では、任意の種類の広告を表示することができる。
【0087】
顧客モジュール４１０は、追加的に、または代替的に、他の処理を実行することができる。一例として、顧客モジュール４１０は、ユーザに対して所定の近接範囲内にある商人に関する情報をインタフェースを介して提供することができる。ユーザは、商人を選択し、商人と共に商品を注文することができる。加えて、または代替として、顧客モジュール４１０は、ユーザが（例えば、カードリーダ、商人デバイスへのＮＦＣ接続、商人デバイスへのＢｌｕｅｔｏｏｔｈ（登録商標）接続などを介して）アイテムの支払いを提供し、アイテムの領収書を受信することなどを可能にすることができる。さらに、顧客モジュール４１０は、ユーザがカードレス支払取引を実行するために商人にチェックインすることを可能にすることができる。
【0088】
位置モジュール４１２は、ユーザデバイス４００の位置を判定することができる。いくつかの例では、位置は、サービスプロバイダ１０２に提供されるか、またはローカルで使用されて、商人デバイスの特定の近傍内に顧客が位置するときの取引の処理など、様々な機能を容易にする。位置モジュール４１２は、地理的位置決め技術（例えば、衛星ベースのシステム－全地球測位システム（ＧＰＳ））、セルタワー位置データ、ワイヤレスアクセスポイント位置データ、無線ビーコン位置など）から、ユーザデバイス４００の地理的位置を判定することができる。したがって、位置モジュール４１２は、ユーザデバイス４００の地理的位置を（たとえば、セルタワーまたはワイヤレスアクセスポイントから）判定することができるＧＰＳ受信機または通信インタフェースなど、ユーザデバイス４００の位置センサからのデータを利用することができる。
【0089】
一部の実装では、ユーザデバイス４００は、ユーザデバイス４００、商人デバイス３００を介して、または例えばサービスプロバイダを介して自動的にトリガされた予約要求に応答して予約提案を受信するようにも構成される。ユーザデバイス４００のユーザは、予約提案を受諾又は拒否することができる。ユーザデバイス４００はまた、現在の予約または将来の予約のいずれかのためにユーザが好む座席の種類の好みを提供することができる。好みはまた、シェフ、アイテム、商人の位置、時刻、代替商人、選択の料理などを含むことができ、その結果、サービスプロバイダは、例えば、好みの予約が利用可能でない場合、または異なるソースからの別の予約と競合する場合に、ユーザのための代替物を生成することができる。
【0090】
図５～図７は、本明細書で説明する技術を使用するための例示的な処理５００、６００、および７００を示す。例示を容易にするために、処理５００、６００、および７００は、サービスプロバイダ１０２、商人デバイス３００、ユーザデバイス４００、および／またはユーザデバイスとすることができる第三者サービスデバイスなど、本明細書で説明するコンピューティングデバイスによって実行されるものとして説明することができる。しかしながら、処理５００、６００、および７００は、他のデバイスによって実行されてもよい。さらに、デバイスは、他の処理を実行するために使用されてもよい。
【0091】
処理５００、６００、および７００（ならびに本明細書で説明される各処理）は論理フローグラフとして示され、その各動作は、ハードウェア、ソフトウェア、またはそれらの組合せで実装され得る動作のシーケンスを表す。ソフトウェアの文脈では、動作は、１つ以上のプロセッサによって実行されるときに、その動作を実行する１つ以上のコンピュータ可読記憶媒体上に記憶されたコンピュータ可読命令を表す。一般に、コンピュータ可読命令は、特定の機能を実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が説明される順序は限定として解釈されることを意図されておらず、説明される動作の任意の数は処理を実施するために任意の順序および／または並列に組み合わせることができる。さらに、説明された動作の任意の数は省略されてもよい。いくつかの例では、デバイスまたはサービスプロバイダによって実行されるものとして、処理５００、６００、および／または７００で説明される動作は、デバイスまたはサービスプロバイダ上で実行されるアプリケーションによって実行され得る。
【0092】
図５は、サービスプロバイダ１０２によって提供される他のサービスに関連する第三者のサービスをエンティティが使用できるようにするために、１つ以上のＡＰＩを公開する例示処理５００を説明している。
【0093】
５０２において、サービスプロバイダ１０２は、サービスプロバイダ１０２のコンセンサスサービス２０７とインタフェースする配送サービスの配送リソースへのアクセスをコンピューティングデバイスに提供するために、１つ以上のＡＰＩを公開することができる。例えば、サービスプロバイダ１０２は、複数の配送プラットフォームによって商人によって提供されるアイテムの配送を容易にするために、商人および／または顧客に関連付けられたコンピューティングデバイスに１つ以上のＡＰＩを公開することができる。
【0094】
５０４において、サービスプロバイダ１０２は、１つ以上のＡＰＩを介して、アイテムの配送に関する要求を受信することができる。要求は、商人または顧客に関連するコンピューティングデバイスから受信されてもよい。要求は、配送の位置、ピックアップの位置、ピックアップの要求された時間、取得されるアイテムの数、アイテムのサイズ、アイテムが所定のカテゴリに関連付けられているかどうか、アイテムの重量などを示すことができる。場合によっては、要求は、商人または顧客に関連付けられたコンピューティングデバイス上で実行可能なアプリケーションから受信される。要求は、任意のタイプのアイテムの配送に対するものであってもよい。一例では、アイテムは、顧客とのアイテムの取得を容易にする商人アプリケーション（例えば、一般大衆が利用できない可能性がある独自の商人アプリケーション）で構成されたコンピューティングデバイス（例えば、タブレットなど）とすることができる。ここで、要求は、サービスプロバイダによって提供される購入リソースを使用するために、商人をサービスプロバイダにオンボードする（例えば、登録する）ために、商人にアイテムを配送することを求めることができる。購入リソースは、商人が配送されたコンピューティングデバイスと対話するときに使用されてもよい。他の例では、アイテムは、他のタイプのアイテムであってもよい。
【0095】
５０６において、サービスプロバイダ１０２は、複数の第三者サービスから複数の注文が受信された場合、アイテムの配送また注文のスケジューリングに関する配送提案を生成することができる。配送提案は、サービスプロバイダ１０２に関連付けられた配送サービスによるアイテムの配送のためのコスト、配送サービスによるアイテムの配送のための推定時間量、アイテムの配送のための推定ピックアップ時間、アイテムの配送のための推定ドロップオフ時間などを含むことができる。場合によっては、サービスプロバイダ１０２は、第三者サービスの現在の位置、アイテムのピックアップ位置、アイテムのドロップオフ位置、アイテムに関連付けられた商人によるアイテムの推定準備時間などに基づいて、アイテム（または配送提案内の任意の他の情報）の配送コストを判定することができる。配送提案はまた、キッチンディスプレイシステムのための一連の注文を含むことができ、その結果、商人は、それに応じて注文準備を調整することができる。
【0096】
５０８において、サービスプロバイダ１０２は、商人またはユーザに関連付けられたコンピューティングデバイスなどのコンピューティングデバイスに配送提案を送信することができる。
【0097】
５１０において、サービスプロバイダ１０２は、１つ以上のＡＰＩを介して、配送提案の受諾または拒否のインジケーション（指標、指示）を受信することができる。受諾または拒否のインジケーションは、商人またはユーザに関連付けられたコンピューティングデバイスから受信され得る。
【0098】
５１２において、サービスプロバイダ１０２は、第三者サービスデバイスから配送人の位置情報を受信することができる。位置情報は、商人または顧客と通信するために使用されるＡＰＩとは異なるＡＰＩを介して、非ＡＰＩチャネルを介してなど、任意の時間に受信することができる。位置情報は、第三者サービスデバイスの現在の位置を識別することができる。
【0099】
５１４において、サービスプロバイダ１０２は、アイテムを移送するために、いくつかの第三者サービスの中から第三者サービスを識別することができる。多くの場合、そのような識別は、配送提案の受諾のインジケーション（指標、指示）を受信することに応答して実行され得る。第三者サービスデバイスは、位置情報において識別された第三者サービスデバイスの位置などの様々な情報に基づいて識別され得る。
【0100】
５１６において、サービスプロバイダ１０２は、アイテムを移送するために第三者サービスデバイスに通信を送信することができる。通信は、関連する第三者サービスがピックアップ位置からアイテムを取得し、そのアイテムを配送の位置に移送することを要求することができる。通信は、配送提案の要求の中の情報、配送提案の中の情報など、配送に関する様々な情報を含むことができる。通信は、商人または顧客との通信に使用されるものとは異なるＡＰＩ を介して、非ＡＰＩ チャネルなどを介して送信される場合がある。いくつかの例では、サービスプロバイダ１０２は、第三者サービスがアイテムを配送することを示す第三者サービスデバイス指示から受諾のインジケーション（指標、指示）を受信することができる。
【0101】
５１８において、サービスプロバイダ１０２は、位置情報および／または配送情報を受信することができる。位置情報および／または配送情報は、第三者サービスデバイスおよび／または商人デバイスから受信され得る。多くの場合、そのような情報は、配送が開始された後に受信され得る。位置情報は一般に、第三者サービスの位置を示すことができる。配送情報は、例えば、第三者サービスの位置を示す第三者サービスからの入力、アイテムがピックアップされたことを示す第三者サービスまたは商人からの情報などを含むことができる。
【0102】
５２０において、サービスプロバイダ１０２は、配送されているアイテムの配送のステータスを判定することができる。配送のステータスは、８２２で受信された位置情報および／または配送情報に基づくことができる。
【0103】
５２２において、サービスプロバイダ１０２は、商人または顧客に関連するコンピューティングデバイスに配送ステータスを送信することができる。コンピューティングデバイスは、商人または顧客への配送ステータスを表示することができる。
【0104】
場合によっては、サービスプロバイダ１０２は、複数のチャネル、または第三者サービスのような複数のソースを介して注文を受信することができる。注文が非商人チャネルを介して（例えば、顧客から直接）受信される場合、サービスプロバイダ１０２は、商人と通信して、商人が注文を履行することを要求することができる。商人によって受諾された場合、商人は受諾のインジケーション（指標、指示）を送信することができ、サービスプロバイダ１０２は、第三者サービスによる配送を容易にすることを進めることができる。さらに、配送のステータスは、進行中の任意の数の配送について判定されてもよい。場合によっては、単一の商人または顧客を伴う複数のアイテムに対する複数のステータスが判定され、商人デバイスまたは顧客デバイスに送信されてもよい。
【0105】
図６は、１つ以上のＡＰＩを介してサービスプロバイダ１０２と通信し、サービスプロバイダ１０２と統合された第三者サービスを使用してコンセンサスサービスを使用したアクションを調整するための例の処理６００を示す。処理６００は、商人または顧客に関連付けられたコンピューティングデバイスなどの取得デバイスによって実行されるという文脈で説明される。
【0106】
６０２において、取得デバイスは、図１のアイテム取得インタフェース１２０などのインタフェースを提供することができる。これには、ディスプレイを介してアイテム取得インタフェースを表示することが含まれる。インタフェースは、ユーザがアイテムの注文を行うことを可能にしてもよい。インタフェースはまた、商人が注文を見ることを可能にするキッチンディスプレイシステムであってもよく、注文はそれらが準備されるべき順序で、アイテムごとに分類され、その結果、同様のアイテムが、内部キッチン目的のために新しいチケットを作成するために集められてもよく、もはや利用可能でないアイテムのためのフローを変更するなどであってもよい。インタフェースは、どの予約が予約され、どのソースから予約されているかを示す、空いているおよび利用不可能な予約のインタフェースにもなり得る。インタフェースはまた、商人において現在利用可能なアイテムのインタフェースであってもよく、商人は、利用可能性、人気、商人の位置などに基づいて、リアルタイムでメニューを変更することができる。
【0107】
６０４において、取得デバイスは、取得のためのアイテムの選択を受信することができる。例えば、ユーザ（例えば、商人、顧客等）は、商品を電子ショッピングカートに入れて、商人からアイテムを購入する意図を示すことができる。場合によっては、ユーザが配送の場所、ピックアップの位置、ピックアップの要求時間、取得されるアイテムの数、アイテムのサイズ、アイテムが所定のカテゴリに関連付けられているかどうか、アイテムの重量などの他の情報を提供することもできる。他の例では、そのような情報は、自動的に判定されてもよい。要求される他の種類の情報は、注文照合の要求、注文順序付けの要求、または商人によってトリガされるか又はサーバによって自動的にトリガされる注文コンセンサスの要求であってもよい。
【0108】
６０６において、取得デバイスは、アイテムの配送に関する情報が要求されていることを決定することができる。これは、アイテムを配送させることへの関心を示す入力をユーザから受信すること、顧客の位置と商人の位置との間の距離を識別すること（例えば、距離が閾値よりも大きい場合、配送が要求されていると判定すること）などを含むことができる。いくつかの例では、配送情報は、各注文に対して要求されていることが自動的に判定されてもよい。
【0109】
６０８において、取得デバイスは、サービスプロバイダ１０２に関連付けられた１つ以上のＡＰＩを介して、サービスプロバイダ１０２に、アイテムの配送に関する要求を送信することができる。当該要求は、配送提案を要求することができる。場合によっては、要求は、配送の位置、ピックアップの位置、ピックアップの要求された時間、取得されるアイテムの数、アイテムのサイズ、アイテムが所定のカテゴリに関連付けられているかどうか、アイテムの重量などを示すことができる。配送提案はまた、予約提案、第三者サービス間で予約割当数をどのように分配するか、第三者サービス間で注文の受諾または配送をどのように分配するか、第三者サービスから受信した注文をどのように順序付けるか、およびメニュー更新、注文更新などの注文に対する更新をどのように送信または受信するかを含む。
【0110】
６１０において、取得デバイスは、サービスプロバイダ１０２から配送提案を受信することができる。配送提案は、サービスプロバイダ１０２に関連付けられた配送サービスによるアイテムの配送のためのコスト、アイテムの配送のための推定時間量、アイテムの配送のための推定ピックアップ時間、アイテムの配送のための推定ドロップオフ時間などを示すことができる。
【0111】
６１２において、取得デバイスは、配送提案が受諾されるか、または拒否されるかを判定し得る。いくつかの例では、取得デバイスは、配送提案内に含まれる情報（例えば、アイテムの配送のためのコスト、アイテムの配送のための推定時間量など）を表示し、配送提案の受諾に関するユーザ入力を受信することができる。他の例では、取得デバイスは、１つ以上の基準が満たされたときに、配送提案を受諾するか、または拒否するかを自動的に判定することができる。したがって、取得デバイスは、場合によっては、配送提案の情報を表示することを控えることができる。
【0112】
６１４において、取得デバイスは、サービスプロバイダ１０２に関連付けられた１つ以上のＡＰＩを介して、配送提案の受諾または拒否のインジケーション（指標、指示）をサービスプロバイダ１０２に送信することができる。これにより、サービスプロバイダ１０２は、アイテムの配送を容易にすることができる。いくつかの例では、顧客が配送に対して課金されてもよく、他の例では、商人または他の商人が課金されてもよい。
【0113】
６１６において、取得デバイスは、配送ステータス処理を実行することができる。例えば、取得デバイスは、サービスプロバイダ１０２に関連する１つ以上のＡＰＩを介して、アイテムの配送ステータスの要求を送信することができる。その後、取得デバイスは、サービスコンピューティングデバイス１０２から、アイテムの配送のステータスを受信し、配送のステータスを表示することができる。他の例では、配送のステータスは、（例えば、第三者サービスがアイテムをピックアップしたことを知ることに基づいて）商人デバイスにおいて判定されてもよく、配送のステータスは、顧客デバイスに送信されてもよい。
【0114】
図７は、アイテムの配送、空いている／競合する座席の予約、メニュー更新などに関して第三者サービスまたは商人デバイスに通知するための例示的な処理７００を示す。
【0115】
７０２において、第三者サービスデバイスは、ユーザデバイスなどの第三者サービスデバイスの地理的位置を判定することができる。地理的位置は、衛星ベースのセンサ（例えば、全地球測位システム（ＧＰＳ）、セルタワー無線、ワイヤレスアクセスポイント無線、無線ビーコン位置センサなど）などの、第三者サービスデバイスの位置センサからのデータに基づいて判定されてもよい。
【0116】
７０４において、第三者サービスデバイスは、サービスコンピューティングデバイス１０２に位置情報を提供することができる。位置情報は、第三者サービスデバイスの地理的位置を示すことができる。位置情報は、定期的に、特定の時間に、要求に応じて、等々で提供されてもよい。
【0117】
７０６において、第三者サービスデバイスは、アイテムの配送に関する通信をサービスプロバイダ１０２から受信することができる。例えば、通信は、第三者サービスデバイス５００に関連付けられた第三者サービスが商人からアイテムを取得し、そのアイテムを顧客に移送することを求める要求を含むことができる。要求は、配送のための時間枠（例えば、配送時間）、配送すべきアイテムの数、配送のルート、商人の位置、または配送を行う際に有用であり得る任意の他の情報を指定し得る。
【0118】
７０８において、第三者サービスデバイスは、アイテムが配送されることを要求する通知を提示することができる（例えば、商人の施設から取得され、配送位置に移送される）。通知は、ディスプレイ、スピーカなどを介して提示されてもよい。場合によっては、情報が、アイテムの配送を容易にする第三者サービスインタフェース（例えば、第三者サービスが配送を受諾すること、配送が行われたことを確認すること、追加の配送を要求することなどを可能にするインタフェース）を介して表示される。第三者サービスデバイス５００は、１００６で受信される通信に含まれる任意の情報を提示することができる。
【0119】
７１０において、第三者サービスデバイスは、第三者サービスからの入力を受信し、および／またはアイテムの配送に関する受諾または拒否を送信することができる。例えば、第三者サービスが顧客にアイテムを配送するタスクを受諾することを入力が示す場合、第三者サービスデバイス５００は、そのようなタスクが受諾されたことを示す通信をサービスプロバイダ１０２に送信することができる。
【0120】
図８は、注文に関するステータス更新を提供するために、サービスプロバイダによって公開される１つ以上のＡＰＩを介して通信する例示的な処理８００を示す。図８では、図８の下部（１つ以上のサービスプロバイダＡＰＩ８０２によって確立された線の下）に示された要素は、サービスプロバイダ１０２などのサービスプロバイダによって実行される動作を表すことができる。
【0121】
図８の例では、複数の第三者サービスを実行するユーザに関連するコンピューティングデバイス８０１は、商人デバイス１０６と関連する商人に発注された注文の生成または作成を可能にし、第三者サービスに関連するコンピューティングデバイス８０４は、商人デバイス１０６と関連する商人に発注された注文の生成または作成を可能にするユーザインタフェース８０６を実装する。８１０に示すように、サービスプロバイダから情報を要求することによって、入って来る注文またはユーザインタフェース８０６の左側にリストされた注文を取得することができる。８１２において、サービスプロバイダは、履行情報を取得し、かつ商人（会社Ａ）の注文のそれぞれに割り当てられた第三者サービスの位置を判定することによって、注文のステータスを判定することができる。８１４において、サービスプロバイダは、ステータスに関する詳細を生成し、その詳細をユーザインタフェース１２０６の左側を介して表示するためにコンピューティングデバイス８０４に送信することができる。
【0122】
顧客は、コンピューティングデバイス８０１を使用して注文または注文要求を生成することができる。したがって、コンピューティングデバイス８０１上で実行される第三者サービス１０８を使用して、そのような注文をトリガすることができる。第三者アプリケーション１０８のような第三者アプリケーションは、ステータス更新エンドポイント、またはＡＰＩエンドポイント８１９を配信することにより、サービスプロバイダ１０２とインタフェースして、注文８２６の詳細、注文がどこからでも受信された順のリスト内でどのようにスケジュールされるか、準備および配送８２４のステータスなどを取得する。また、サービスプロバイダは、例えば、ユーザが別の配送会社に属する配送人に近接していることに基づいて、注文ために使用されたものとは異なる会社によって配送される注文をスケジュールすることもできる。
【0123】
商人に関連するコンピューティングデバイス８０２も示されている。ユーザインタフェース８０６の左側は、注文が出されるチャネル（例えば、電話、顧客アプリケーション、ウェブサイトなど）にかかわらず、商人に出されたすべての注文（または特定の数の注文）の比較的高レベルの情報を表示することができる。一方、ユーザインタフェースの右側には、選択された１つ以上の注文に関するより詳細な情報が表示されてもよい。ユーザインタフェース８０６の左側と右側は、線８０８によって分離されている。ユーザインタフェース８０６は、サービスプロバイダが複数のソースから受信された注文からリアルタイムで通知または更新をプッシュするキッチンディスプレイシステムのインタフェースであってもよい。インタフェース８０６はまた、サービスプロバイダ１０２によってスケジュールされるように、注文をリストし、ユーザの好み、利用可能性、および他のそのような要因による注文の管理を支援する。
【0124】
図示されるように、アイテムの配送に関するステータス情報は、１つ以上のサービスプロバイダＡＰＩ８０２を介してサービスプロバイダと通信することによって取得することができる。例えば、８１０に示されているように、ユーザインタフェース８０６の左側にリストされている注文のステータス情報は、サービスプロバイダに情報を要求することによって取得することができる。８１２において、サービスプロバイダは、履行情報を取得し、商人（会社Ａ）の注文のそれぞれに割り当てられた第三者サービスの位置を判定することによって、注文のステータスを判定することができる。８１４において、サービスプロバイダは、ステータスに関する詳細を生成し、その詳細をユーザインタフェース８０６の左側を介して表示するためにコンピューティングデバイス８０４に送信することができる。
【0125】
商人が、注文８１６のようなユーザインタフェース８０６の左側の特定の注文を選択する場合、その注文に特有のより詳細な情報がユーザインタフェース８０６の右側に表示されてもよい。特に、８１８に示すように、コンピューティングデバイス８０４は、選択された注文８１６に関する追加のステータス情報を要求してもよい。８２０において、サービスプロバイダは、履歴情報を取得し、選択された注文に割り当てられた第三者サービスの位置を判定することによって、選択された注文のステータスを判定することができる。８２２において、サービスプロバイダは、ステータスに関する詳細を生成し、その詳細をユーザインタフェース１２０６の右側を介して表示するためにコンピューティングデバイス８０４に送信することができる。場合によっては、右側に表示される詳細が左側に表示される詳細よりも具体的であってもよい。このように、商人は、様々なタイプのチャネルを介して発注された注文のステータス情報を多く見る。
【0126】
いくつかの例では、ボックス８１０は、サービスプロバイダの配送サービスによって現在配送されている商人のすべての注文（または特定の数の注文）に関するステータス情報を取得するためのＡＰＩを表す。一方、ボックス８１８は、サービスプロバイダの配送サービスによって現在配送されている商人の特定の注文のステータス情報を取得するためのＡＰＩを表してもよい。
【0127】
いくつかの例では、本出願は、最適化された注文スケジューリングを提供するためのシステムを開示し、このシステムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行可能な命令を記憶する１つ以上の非一時的なコンピュータ可読媒体とを含み、命令は、商人に関連付けられた販売時点管理デバイス上で実行される注文スケジューリングアプリケーションによって、第１の顧客対面注文アプリケーションから第１の注文を受信することであってと、第１の注文は、第１の顧客対面注文アプリケーションによって提供される住所に配送するために商人によって準備される１つ以上のメニューアイテムを含む、受信することと、第１の配送アプリケーションによって、商人のコンピューティングデバイスに、第１の配送アプリケーションが第１の注文をピックアップするための配送人または顧客の到着を推定する時間を示す推定ピックアップ時間を送信することと、第１の顧客対面アプリケーションに関わる過去の注文に基づいて、配送人または顧客が第１の注文をピックアップする可能性があるときの推定時間を示す予測ピックアップ時間を判定することと、第２の顧客対面注文アプリケーションから第２の注文を受信することであって、第２の注文は商人によって準備される１つ以上のメニューを含む、受信することと、第１の配送アプリケーションによって、商人のコンピューティングデバイスに、第２の配送アプリケーションが第２の注文をピックアップするために配送人または他の顧客の到着を推定する時間を示す推定ピックアップ時間を送信することと、第２の配送アプリケーションに関わる過去の注文に基づいて、配送人または顧客が第２の注文をピックアップする可能性がある時間を示す予測ピックアップ時間を判定することと、注文スケジューリングアプリケーションによって、第１の注文および第２の注文の予測ピックアップ時間に少なくとも部分的に基づいて注文の順序付きリストを生成することと、順序付きリストに従って注文を準備するために注文の順序付きリストをキッチンディスプレイシステムに送信することと、を含む動作を実行するように１つ以上のプロセッサをプログラムする。
【0128】
図９は、サービスコンピューティングデバイス１０２またはコンセンサスサービスなどの関連するアプリケーションなどのサービスプロバイダの一例の例示的な処理を示し、コンテキストデータに基づいて、ユーザインタフェースなどのユーザインタフェース９０４のアイコン９０２を動的に修正（変更）する。たとえば、メニュー更新は、第三者サービスと商人との関係、アイテムの利用可能性または人気、およびその他のコンテキストデータに基づいて、第三者サービスに送信することができる。コンテキストデータは、サービスコンピューティングデバイス９００の位置、時間、曜日、年の時間（例えば、季節）、天気、商人の在庫、商人の好み、顧客の好み、アップセルアイテムと見なされるアイテム、クロスセルアイテムと見なされるアイテム、商人によって提供される販売および／または特売、ならびにサービスコンピューティングデバイス９００の使用に対応する様々な他のコンテキスト要因を含むことができる。コンテキストデータは、商人デバイスで、アプリケーションを介して、またはサーバレベルでの現在または履歴などのデータ分析を介して自動的に生成することができる。コンテキスト情報は、カートレベル情報である完全または不完全な注文要求を第三者アプリケーションから追跡することによって得ることができる。
【0129】
９０６において、サービスコンピューティングデバイス９００は、第１のコンテキストデータを判定し、コンテキストデータに基づいて第１のアイコン９０２（１）を表示する。第１のコンテキストデータは、サービスコンピューティングデバイス９００の使用に対応する１つ以上の要因の分析に基づいて判定することができる。例示的な実施例では、分析は、時刻が朝食メニューに対応するという判定を含むことができる。この判定に基づいて、サービスコンピューティングデバイス９００は、食事メニューに対応するアイコン９０２（１）の第１の設定を表示することができる。いくつかの例では、分析は、顧客の好みの分析と、朝食メニューなどの特定のメニューアイテムを顧客が好むという判定とを含むことができる。
【0130】
様々な例では、分析は、１つ以上のアイテムを強調するための判定を含むことができる。強調は、アイコン９０２のサイズ、形状、色および／または色相を増加させることによって、アイコン９０２の配置を変更することによって、またはアイコン９０２をディスプレイ上で目立たせるためのその他の調整によって提示することができる。強調は、商人の在庫、現在の天候、アイテムをアップセルしようとする試み、アイテムをクロスセルしようとする試み、商人によって提供される販売および／または特売、商人の取引履歴（例えば、ある時間に販売された既知の人気のあるアイテム、曜日、年の時間（例えば、季節）、販売されたアイテムの既知の人気のある組合せなど）に基づくことができる。
【0131】
[3] いくつかの例では、分析は、１つ以上のアイテムを強調解除する判定を含むことができる。アイテムの強調解除は、商人の在庫、現在の天気、クロスセルの試み、および／または商人が特定のアイテムの販売を思いとどまらせることができる他の要因に基づくことができる。強調解除は、表示ページから１つ以上のアイテムに対応するアイコン９０２を除去することによって提示することができる。様々な例において、ユーザインタフェース９０４は、複数の表示ページを含むことができる。いくつかの例では、強調解除は、メイン表示ページ以外の表示ページ上の１つ以上のアイテムに対応するアイコンを含めることによって提示することができる。たとえば、強調解除には、複数の表示ページの最後のページにアイコンを提示することを含めることができる。
【0132】
様々な例において、サービスコンピューティングデバイス９００は、コンテキスト要因に基づいて、１つ以上のアイテムを強調および／または強調解除するように動的に判定することができる。例えば、顧客が最後のマフィンを注文した場合、サービスコンピューティングデバイス９００は、ユーザインタフェースからマフィンアイコンを除去することによってユーザインタフェース９０４を動的に修正し、それをペーストリーアイコンに置き換えることができる。
【0133】
９０８において、サービスコンピューティングデバイス９００は、第２のコンテキストデータを判定し、コンテキストデータに基づいて第２のアイコン９０２（２）を表示する。様々な例において、第２のコンテキストデータは、午前メニューに対応する時間からランチメニューに対応する時間への時刻の変化を含むことができる。いくつかの例では、第２のコンテキストデータは、商人の位置に近いイベントの判定を含むことができ、あるいは商人の位置の画面に表示され、これは顧客によって注文される可能性が最も高いメニューアイテムに影響を与える可能性がある。そのような例では、サービスコンピューティングデバイス９００は、アイコン９０２（１）をアイコン９０２（２）の第２の設定に動的に修正して、顧客の好みまたは外部環境（例えば、寒い／暑い日に熱い／冷たい飲料アイテムが推奨される）に対応することができる。例えば、商人は、通常、朝食から昼食メニューに午前１１時に調整することができる。しかしながら、サービスコンピューティングデバイス９００は、フットボールゲームが午前１０時に開始し、フットボールゲーム中に、顧客がランチメニュー上のアイテムを消費することを好むと判定することができる。したがって、サービスコンピューティングデバイス９００は、アイコン９０２の１つ以上をランチメニューアイテムに対応するものに調整してもよい。
【0134】
いくつかの例では、サービスコンピューティングデバイス９００がイベントが商人の近くで行われているか、または商人位置のディスプレイ画面上に提示されることになると判定することができ、イベントに基づいて１つ以上の販売および／または特売（たとえば、割引など）を生成することができる。このような例では、サービスコンピューティングデバイス９００は、１つ以上の特売に対応するアイコン９０２を強調することができる。例えば、商人は、イベント中にハンバーガー及びアルコール飲料を特別に提供することができる。したがって、サービスコンピューティングデバイス９００は、ハンバーガーおよびアルコール飲料に対応するアイコンを目立たせるように修正することができる。さらに、または代替として、サービスコンピューティングデバイスは、購入をさらに奨励するために、特定のアイテムが割引価格で提供されるという通知９１０を表示することができる。
【0135】
代替として、または追加として、アイコン９０２（１）を有する第１のインタフェースは、第１の第三者サービスに対応することができ、９０２（２）を有する第２のインタフェースは、第２の第三者サービスに対応することができ、商人は、メニューインタフェースに異なる更新を送信する。別の実施態様では、１つの第三者サービスと別の第三者サービスとの両方のためのインタフェースは同じであり、それは、同じ内容が第三者サービスに提示されることを意味する。メニューの基礎となるコンテキスト情報は、第三者サービスに関連するメニューで顧客の行動に結びついている可能性がある（すなわち、商人のためのサービスＡのメニューは、同じ商人のためのサービスＢのメニューとは異なるように編成されてもよい）。支払サービスのＡＰＩ は、その第三者サービスアプリケーション内で顧客とのやり取り／行動（メニュースクロールアクティビティ、ナビゲーション設定、注文履歴など） を収集するために使用することができる。注文履歴を見ると、支払サービスは、例えば、支払サービスまたはＡＰＩがサービスＡの顧客が典型的には前菜（アペタイザ）を注文し、サービスＢの顧客が特定の商人からデザートを注文する傾向があると判定した場合、その情報を使用してメニューを再編成することができる。したがって、一実施形態では、支払サービスは、例えば、コンセンサスサービスが特定の期間中に追跡する注文アクティビティに基づいて（例えば、「第三者アプリケーションの大部分からの顧客が現在ステーキを注文しているか」というクエリに基づいて）、コンテンツ／メニューの更新をすべての第三者注文アプリケーションにプッシュアップすることができる。さらに、または代替として、支払サービスは、コンセンサスサービスが顧客の注文行動について学習するものに基づいて各第三者アプリケーションにカスタマイズされる固有のメニューを生成するように、メニューレイアウトを再編成するコンテンツ更新をプッシュアウトすることもできる。したがって、コンセンサスサービスは、配送サービスがアクセスできない現在のデータおよび履歴データから、収集、分析、比較、および学習を行う。さらに、コンセンサスサービスは、そうでなければ通信しない別個のサービスが、コンセンサスサービスによって作成された間接チャネルを介して通信することを可能にする。説明は、ＡＰＩをチャネルの１つの形成であると説明するが、説明は、サービス間のチャネルの他の形成を、直接に、または支払サービスのような仲介サービスを介して、カバーするように拡張することができることを理解されたい。
【0136】
一部の実装において、最適化されたコンテンツ管理を提供するためのサーバシステムであって、前記システムは、１つ以上のプロセッサと、当該１つ以上のプロセッサによって実行可能な命令を記憶する１つ以上の非一時的なコンピュータ読み取り可能な媒体と、を備え、当該命令は、第１のサービスアプリケーションおよび第２のサービスアプリケーションのためのコンテンツ構造を受信することであって、コンテンツ構造は例えば、メニューがレイアウトされるまたはアイテムが価格設定される方法を含む、受信することと、商人に関連付けられた販売時点管理デバイス上で実行されるコンテンツ管理アプリケーションによって、コンテンツ更新が新しいメニューアイテム、削除されたメニューアイテムを含む第１の商人アプリケーションのための第１のコンテンツ更新又はレビューを受信することであって、第１のコンテンツ更新は第１のサービスアプリケーションのためのメニューなどのコンテンツになされた更新を含む、受信することと、コンテンツ更新を第１のサービスアプリケーションに送信することと、第２のサービスアプリケーションに、第１のサービスアプリケーションのコンテンツ更新に類似したコンテンツ更新を送信することと、等を含む処理ステップを実行する。
【0137】
あるいは、サービスプロバイダは、コンテンツ管理アプリケーションによって、サービスアプリケーションおよび商人に基づいてコンテンツの構成された構造を生成することを含む。例えば、第１のサービスアプリケーションのためのアイテムの特定の注文および価格設定を有する第１のメニュー、および第２のサービスアプリケーションのためのアイテムの別の注文および価格設定を有する第２のメニューである。さらに、異なるアイテムは、異なる位置およびサービスアプリケーションで提供されてもよい。
【0138】
図１０は、コンセンサスサービスを実行するサービスプロバイダ１０２または商人デバイス１００８におけるコンセンサスサービス１３２上の予約の例示的なインタフェース１０００である。図に示すように、予約は、リアルタイムで管理することができ、予約は、Ｙｅｌｐ（著作権）、ＯｐｅｎＴａｂｌｅ（著作権）、Ｒｅｓｙ（著作権）などの予約サービスなどの複数のソースから受信される。
【0139】
一部の実装では、サービスプロバイダ１０２は、商人デバイス１００２のために受信した予約を割り当て、この予約は、ＡＰＩ(図示せず）を介して、第１の予約アプリケーション１００４－１および第２の予約アプリケーション１００４－２を含む複数の予約アプリケーションから予約を受信するように構成される。ＡＰＩは、例えば、様々な予約アプリケーションからのデータを集約するアグリゲータとして、支払サービスを容易にするために使用されてもよく、これらの第三者アプリケーションは、公開されたＡＰＩを使用して商人に予約情報を送信する。例えば、コンセンサスサービスは、データを収集し、それに応じて予約を順序付けることができる。コンセンサスサービスはまた、サービスが各予約アプリケーションについて学習し、サービスが学習したことに基づいて、例えば機械学習モデルを介して、座席の一部を割り当てる履歴予約情報を活用することができる。例えば、キャンセルの頻度、そのアプリケーションを使用する顧客の平均到着時間、注文サイズなどの要因に基づいて、支払サービスは、座席を割り当てることができる。サービスプロバイダ１０２は、複数の予約を受信し、コンセンサスサービス１３２を実行して、入って来る予約を処理し、データベース１００６に記憶された顧客プロファイルおよび／または商人プロファイルに基づいて、商人のためにそれらをスケジュールする。データベース１００６は、顧客および商人の好みを格納し、予約がどのようにしてそれらの好みに最も一致するように構成され得るかを示す。例えば、コンセンサスサービス１３２は、利用可能性または顧客によって行われた過去の予約に応じて、予約１００４－３を６：３０から７ＰＭに移動させることができる。同様に、予約１００４－４は、特定の座席またはアイテムの利用可能性に応じて、８ＰＭに割り当てることができる。例えば、いくつかのレストランは回転メニューを維持し、そのようなものとして、サービスプロバイダは、ユーザの同意によって、ユーザの食事の好みへのアクセスを提供されてもよい。したがって、予約は、ユーザまたは商人の介入なしに、より好ましいスポットに移動することができる。この本出願は、サービスプロバイダのような支払サービスによって、および第１の予約アプリケーションから、ある期間にわたって第１の予約アプリケーションを使用して行われた平均予約数に関連付けられた第１のデータを受信する；、支払サービスによって、および第２の予約アプリケーションから、ある期間にわたって第２の予約アプリケーションを使用して行われた平均予約数に関連付けられた第２のデータを受信する；、支払サービスによって、レストランにおける利用可能な座席に関するデータを受信する；、利用可能な座席から座席の第１の部分を、少なくとも第１のデータに基づいて、第１の予約アプリケーションに割り当てることであって、第１の予約アプリケーションの１つ以上のユーザは座席の第１の部分以下の座席を予約することができる、前記割り当てる；、利用可能な座席の第２の部分を、少なくとも第２のデータに基づいて、第２の予約アプリケーションに割り当てることであって、第２の予約アプリケーションの１以上ユーザが座席の他の部分以下の座席を予約することができる、前記割り当てる；、予約中に、少なくとも１以上のユーザは第１の予約アプリケーションを使用して座席を予約することができないことに応じて、第２の予約アプリケーション上で何れかの座席が利用可能であるかどうかを判定する；、第１の予約アプリケーションのインタフェースから第２の予約アプリケーションに顧客デバイスを移行させるための命令を提供する；、第２の予約アプリケーションを使用してレストラン内の座席の予約を示す入力を１以上のユーザから受信する；方法を開示している。
【0140】
いくつかの実装形態では、最適化されたレストラン予約スケジューリングを提供するサーバシステムは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行可能な命令を格納する１つ以上の非一時的なコンピュータ可読媒体とを備え、命令は、商人に関連付けられた販売時点管理デバイスを実行する予約スケジューリングアプリケーションによって、第１の顧客対面予約アプリケーションから第１の予約を受信することであって、第１の予約は、第１の顧客対面予約アプリケーションによって提供される住所に配送するための、商人によって準備される１つ以上のメニューアイテムを含む、受信することと、第１の配送アプリケーションによって、商人のコンピューティングデバイスに、第１の配送アプリケーションが第１の予約をピックアップするための配送人または顧客の到着を推定する時間を示す推定ピックアップ時間を送信することと、第１の顧客対面アプリケーションに関わる過去の予約に基づいて、配送人または顧客が第１の予約をピックアップする可能性があるときを示す予測ピックアップ時間を判定することと、予約スケジューリングアプリケーションによって、別の顧客から、第２の顧客対面予約アプリケーションから第２の予約を受信することであって、第２の予約は商人によって準備される１つ以上のメニューを含む、受信することと、第１の配送アプリケーションによって、商人のコンピューティングデバイスに、第２の配送アプリケーションが第２の予約をピックアップするために配送人または他の顧客の到着を推定する時間を示す推定ピックアップ時間を送信することと、第２の配送アプリケーションに関わる過去の予約に基づいて、配送人または顧客が第２の予約をピックアップする可能性がある時間を示す予測ピックアップ時間を判定することと、予約スケジューリングアプリケーションによって、第１の予約および第２の予約の予測ピックアップ時間に少なくとも部分的に基づいて、予約の順序リストを生成することと、順序リストに従って、予約の準備のために、キッチンディスプレイシステムに予約の順序リストを送信することと、を含む動作を実行するように１以上のプロセッサをプログラムする。
【0141】
実施形態は構造的特徴および／または方法論的動作に特有の言語で説明されてきたが、本開示は説明された特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、特定の特徴および動作は、実施形態を実施する例示的な形態として本明細書に開示される。
節
節
【0142】
Ａ．最適化された注文スケジューリングを提供するためのシステムであって、１つ以上のプロセッサと、前記１つ以上のプロセッサによって実行可能な命令を記憶する１つ以上の非一時的なコンピュータ可読媒体とを備え、前記命令は、第１の顧客対面注文アプリケーションからの第１の注文を、商人に関連付けられた販売地点（ＰＯＳ）デバイス上で実行する注文スケジューリングアプリケーションによって受信することであって、前記第１の注文は前記第１の顧客対面注文アプリケーションによって提供される住所への配送のために前記商人によって準備される１つ以上のメニューアイテムを含む、前記受信することと、サービスコンピューティングデバイスによって、前記第１の顧客対面アプリケーションを含む過去の注文に基づいて、配送人または前記顧客が前記第１の注文をピックアップする可能性が高い推定時間を示す予測ピックアップ時間を判定することと、前記注文スケジューリングアプリケーションによって、別の顧客から、第２の顧客対面注文アプリケーションから第２の注文を受信することであって、前記第２の注文は前記商人によって準備される１つ以上のメニューアイテムを含む、前記受信することと、サービスコンピューティングデバイスによって、前記第２の顧客対面注文アプリケーションを含む過去の注文に基づいて、前記配送人または前記顧客が前記第２の注文をピックアップする可能性が高い時間を示す予測ピックアップ時間を判定することと、前記サービスコンピューティングデバイスによって、前記第１の注文および前記第２の注文の前記予測ピックアップ時間に少なくとも部分的に基づいて、注文の順序付けられたリストを生成することと、前記注文スケジューリングアプリケーションに関連付けられたキッチンディスプレイシステムに、前記順序付けられたリストに従って前記注文を準備するための前記注文の前記順序付けられたリストを送信することと、を含む動作を実行するように前記１つ以上のプロセッサをプログラムする、システム。
【0143】
Ｂ．コンピューティングデバイスに関連付けられたディスプレイを介して、前記顧客または前記商人のうちの少なくとも１つにインタフェースを提供し、前記インタフェースを介して、配送場所、ピックアップの場所、ピックアップの要求時間、取得されるアイテムの数、前記アイテムのサイズ、前記アイテムが所定のカテゴリに関連付けられているかどうか、または、前記アイテムの重量のうちの１つに基づいて注文の前記順序付けられたリストを受信し、前記アイテムの配送に関する情報が要求されていることを判定し、前記１つ以上のＡＰＩを介して前記サービスコンピューティングデバイスに、前記アイテムの配送に関する要求を送信し、前記サービスコンピューティングデバイスから配送提案を受信し、配送提案が受諾されたことを判定し、前記アイテムの配送を容易にするために、前記１つ以上のＡＰＩを介して前記配送提案の受諾の指標を送信するための、第三者サービスまたは前記商人のうちの少なくとも１つに関連付けられている前記コンピューティングデバイスの１つ以上のプロセッサによって実行可能なアプリケーションをさらに含む、節Ａに記載のシステム。
【0144】
Ｃ．前記注文スケジューリングアプリケーションは、前記マーチャント商人に関連する付けられた前記コンピューティングデバイス、前記第三者サービスに関連付けられた前記コンピューティングデバイス、前記顧客に関連付けられたコンピューティングデバイスとインターフェースインタフェースするアプリケーションプログラムインターフェースインタフェース（ＡＰＩ）を提供するようにさらに構成される、節Ａ又はＢに記載のシステム。
【0145】
Ｄ．前記サービスコンピューティングデバイス上でホストされるコンセンサスアプリケーションをさらに含み、前記コンセンサスアプリケーションは、前記第１の顧客対面注文アプリケーションおよび前記第２の顧客対面注文アプリケーションからそれぞれ前記第１の注文および前記第２の注文を受信し、前記コンセンサスアプリケーションは、前記キッチンディスプレイシステム上に表示するために前記第１の注文および前記第２の注文をスケジュールする、節Ａ乃至Ｃの何れかに記載のシステム。
【0146】
Ｅ．前記サービスコンピューティングデバイスは、前記第三者サービスに関連付けられた配送人のさらなる位置情報を受信し、前記配送人の位置情報に基づいて前記第１の注文または前記第２の注文を生成するために使用された前記第三者サービスとは異なる第三者サービスのうちの１つを識別し、前記識別された第三者サービスに前記アイテムの配送を割り当てる、ようにさらに構成される、節Ｂに記載のシステム。
【0147】
Ｆ．サービスコンピューティングデバイスプロセッサと、前記サービスコンピューティングデバイスプロセッサと通信可能に接続されたサービスコンピューティングデバイス通信インタフェースとを備えるシステムであって、前記サービスコンピューティングデバイス通信インタフェースは、複数の第三者のサービスデバイスと１つ以上のネットワークを介して通信し、且つ、顧客または商人の少なくとも１つと関連付けられたコンピューティングデバイスと、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記１つ以上のネットワークを通じてさらに通信し、前記サービスコンピューティングデバイスは、前記サービスコンピューティングデバイスによって提供される前記１つ以上のＡＰＩを介して、商人から取得されることを顧客によって指定されたアイテムの配送に関する要求を受信することであって、前記要求は、配送の位置、ピックアップの位置、ピックアップの要求された時間、取得されるアイテムの数、前記アイテムのサイズ、前記アイテムが所定のカテゴリに関連付けられているかどうか、または前記アイテムの重量のうちの少なくとも１つを示し、前記要求は、前記顧客又は前記商人の少なくとも１つと関連付けられた前記コンピューティングデバイス上で実行可能であるアプリケーションから前記１つ以上のＡＰＩを介して受信される、前記受信することと、前記商人について、前記アイテムを準備して配送の前記位置に配送する配送提案を生成することであって、前記配送提案は、（ａ）前記第三者サービスデバイスに関連付けられた複数の前記第三者配送サービスの中からの好適な配送サービスであって、前記複数の第三者配送サービスは、前記サービスコンピューティングデバイスの前記１つ以上のＡＰＩを介して前記商人と通信する、前記好適な配送サービスと、（ｂ）前記商人が準備のために使用する前記要求を含む要求のシーケンスと、（ｃ）前記配送サービスによる前記アイテムの配送の推定時間量、を含む、前記生成することと、前記１つ以上のＡＰＩを使用して、前記好適な配送サービスと関連付けられている前記第三者サービスに、前記好適な配送サービスが前記商人の施設から前記アイテムを取得して前記アイテムを配送の前記位置に移送することを要求する通信を送信することと、をするように構成されるシステム。
【0148】
Ｇ．要求の前記シーケンスは、前記商人が前記要求を処理するシーケンスを含み、前記シーケンスは、時間、前記商人の位置、前記顧客の位置、前記配送を行うことができる配送人の位置、前記注文が受信された時間、商人プロファイル、顧客プロファイル、要求された前記アイテムの準備時間、および前記アイテムの利用可能性のうちの少なくとも１つに基づくものである、節Ｆに記載のシステム。
【0149】
Ｈ．１つ以上のプロセッサにより実行される場合に、前記１以上のプロセッサに、サービスコンピューティングデバイスに関連付けられた１つ以上の商人へのアクセスをコンピューティングデバイスに提供するために、前記サービスコンピューティングデバイスによって１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を公開することと、前記商人に関連付けられた１つ以上のアクションを容易にすることができる１つ以上の第三者サービスへのアクセスをコンピューティングデバイスに提供するために、前記サービスコンピューティングデバイスによって、前記１つ以上のアプリケーションプログラミングインタフェースインタフェース（ＡＰＩ）を公開することと、前記１つ以上のＡＰＩを介して、前記商人および前記第三者サービスのコンピューティングデバイスから、前記商人に関連付けられた前記アクションを処理するための要求を受信することと、前記商人に関連付けられた前記アクションを容易にするためのアクション提案を生成することであって、前記アクション提案は、前記アクション内のステップが実行されるシーケンスを含む、前記生成することと、前記第三者サービスまたは前記商人に関連付けられた前記コンピューティングデバイスに前記アクション提案を送信することと、前記サービスプロバイダによって、前記１つ以上のＡＰＩを介して、前記アクション提案に基づく支払いフローを構成することであって、前記支払いフローは、前記第三者サービスと前記商人との間のサブアクションの分配に基づくものである、前記構成することと、を含む動作を実行させる実行可能命令を記憶する１つ以上の非一時的なコンピュータ可読媒体。
【0150】
Ｉ．１つ以上のアクションは、アイテムの配送、前記アイテムの準備、前記アイテムのキャンセル、注文の配送、前記注文の準備、前記注文のキャンセル、注文のマージ、前記注文の分割、顧客のための予約、顧客のためのアポイントメント、第三者サービスにわたるコンテンツの更新、前記アイテムの更新、前記注文の更新を含む、節Ｈに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0151】
Ｊ．前記アクション提案は、前記アイテムの配送のための推定時間量、前記アイテムの配送のための推定ピックアップ時間、または前記アイテムの配送のための推定ドロップオフ時間のうちの少なくとも１つを示す配送提案である、節ＨまたはＩのいずれかに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0152】
Ｋ．前記１つ以上のＡＰＩを公開することは、前記１つ以上のＡＰＩを商人に関連付けられたコンピューティングデバイスに公開して、前記商人が、前記商人による取得のために提供されるアイテムの配送を容易にすることを可能にすることを含む、節Ｈに記載の１つ以上の非一時的コンピュータ可読媒体。
【0153】
Ｌ．前記動作は、前記１つ以上のＡＰＩを介して、前記コンピューティングデバイスから、前記アイテムの配送ステータスの要求を受信することと、前記第三者サービスデバイスの位置情報を受信することと、前記第三者サービスによる前記アイテムの配送のステータスを判定することと、前記アイテムの配送の前記ステータスを前記コンピューティングデバイスに送信することと、をさらに含む、節Ｋに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0154】
Ｍ．前記動作は、前記１つ以上のＡＰＩを介して、前記アイテムの取得を容易にするサービスに商人を登録するために他のアイテムを前記商人に配送するための他の要求を受信することとであって、前記他のアイテムは、顧客とのアイテムの取得を容易にする商人アプリケーションで構成され、前記他の要求は、前記他のアイテムの配送の位置を示す、前記受信することと、他の第三者サービスの位置に少なくとも部分的に基づいて前記他のアイテムを移送するために前記他の第三者サービスを識別することと、前記他の第三者サービスが前記他のアイテムの配送の前記位置に前記他のアイテムを配送することを要求する通信を、前記他の第三者サービスに関連付けられている他の第三者サービスデバイスへ送信することと、をさらに含む、節Ｋ又はＬに記載の１つ以上の非一時的コンピュータ可読媒体。
【0155】
Ｎ．前記動作は、前記商人および前記第三者サービスによって実行された現在および過去のアクションに関する訓練データを取得することと、前記アクション提案を生成するために、前記訓練データに基づいて機械学習モデルを訓練することと、をさらに含む、節Ｈ－Ｍの何れかに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0156】
Ｏ．インタフェースを表示するように構成されたディスプレイと、前記ディスプレイに通信可能に接続された１つ以上のプロセッサと、前記１つ以上のプロセッサに通信可能に接続され、前記１つ以上のプロセッサによって実行される場合に、前記１つ以上のプロセッサに、ディスプレイ上で、商人によって準備され、かつ第１の配送サービスの第１の配送人によって第１の顧客に配送するためにピックアップするための、第１の注文を受信することと、前記ディスプレイ上で、前記商人によって準備され、かつ第２の配送サービスの第２の配送人によって第２の顧客に配送するためにピックアップするための、第２の注文を受信することと、前記商人が前記第１の注文および前記第２の注文を準備すべきシーケンスを含む配送提案を、前記ディスプレイ上で受信することであって、前記シーケンスは、１つ以上のアプリケーションプログラムインタフェース（ＡＰＩ）を介して、前記ディスプレイを有する前記システム、前記第１の配送サービス、および前記第２の配送サービスとインタフェースされたサービスコンピューティングデバイスによって生成される、前記受信することと、前記第１の注文または前記第２の注文におけるアイテムの利用可能性に基づいて、前記ディスプレイを通じて前記シーケンスを修正することと、前記サービスプロバイダへのＡＰＩ呼び出しを開始することによって、前記修正に基づいて支払いフローを生じさせることと、を含む動作を実行させる実行可能な命令を記憶するメモリと、を備えるシステム。
【0157】
Ｐ．前記動作は、前記１つ以上のＡＰＩを介して、前記サービスコンピューティングデバイスに、前記アイテムの配送ステータスを前記第１の配送サービスまたは前記第２の配送サービスに提供するためのトリガを送信することと、前記サービスコンピューティングデバイスから、前記アイテムの配送のステータスを受信することと、配送の前記ステータスを、前記第１の配送サービスまたは前記第２の配送サービスに送信することと、をさらに含む、節Ｏに記載のシステム。
【0158】
Ｑ．前記システムは商人デバイスを備え、前記動作は、前記サービスコンピューティングデバイスから、他のアイテムの取得のための注文を受信することであって、前記他のアイテムは、前記第１の配送サービスの顧客デバイスを通じて取得のために選択されている、前記受信することと、前記注文の受諾を示すユーザ入力を受信することと、前記サービスコンピューティングデバイスへ前記注文の受諾の指標を送信することと、前記アイテムの配送の第１のステータスおよび前記他のアイテムの配送の第２のステータスを受信することと、配送の前記第１のステータスおよび配送の前記第２のステータスを、前記インタフェースを介して表示することと、をさらに含む、節Ｏ又はＰに記載のシステム。
【0159】
Ｒ．前記配送提案は、前記サービスコンピューティングデバイスとインタフェースされた配送サービスによる前記アイテムの配送のためのコスト、前記アイテムの配送のための推定時間量、前記アイテムの配送のための推定ピックアップ時間、または前記アイテムの配送のための推定ドロップオフ時間のうちの少なくとも１つを示す、節Ｏ－Ｑの何れかに記載のシステム。
【0160】
Ｓ．前記配送提案は、前記サービスコンピューティングデバイスに関連付けられた配送サービスによる前記アイテムの配送のためのコストのうちの少なくとも１つを示し、前記動作は、１つの注文においてアイテムのグループからアイテムを除去することであって、前記除去は、利用可能性、人気、腐敗、および時刻に基づくものである、前記除去することと、前記アイテムの配送のコストを前記インタフェースを介して表示させることと、前記アイテムの取得に関連付けられた顧客に、前記アイテムを除去した後の前記注文の配送のコストを請求することとを含む、節Ｏ－Ｒの何れかに記載のシステム。
【0161】
Ｔ．前記動作は、前記第１の注文および前記第２の注文が実質的に同時に行われる場合にコンセンサスを提供することをさらに含む、節Ｏ－Ｓのいずれかに記載のシステム。
【0162】
Ｕ．最適化された予約スケジューリングを提供するためのシステムであって、１つ以上のプロセッサと、前記１つ以上のプロセッサによって実行可能な命令を記憶する１つ以上の非一時的なコンピュータ可読媒体とを備え、前記命令は、商人に関連付けられた販売時点管理デバイス上で実行される予約スケジューリングアプリケーションによって、顧客から、第１の顧客対面予約アプリケーションからの第１の予約要求を受信することであって、前記第１の予約要求は商人位置における予約の好適な時間を含む、前記受信することと、前記第１の顧客対面予約アプリケーションに関わる過去の注文に基づいて、サービスコンピューティングデバイスによって、前記顧客が前記第１の予約要求を好む可能性が高いと予測される座席を判定することと、前記予約スケジューリングアプリケーションによって、他の顧客から、第２の顧客対面予約アプリケーションからの第２の予約要求を受信することであって、前記第２の予約要求は前記商人位置における予約の他の好適な時間を含む、前記受信することと、前記第２の顧客対面予約アプリケーションに関わる過去の注文に基づいて、サービスコンピューティングデバイスによって、前記他の顧客が前記第２の予約要求を好む可能性が高いと予測される座席を判定することと、前記サービスコンピューティングデバイスによって、前記第１の予約要求および前記第２の予約要求に対応する前記予測される座席に少なくとも部分的に基づいて座席表を生成することと、前記予約スケジューリングアプリケーションに関連付けられたキッチンディスプレイシステムに、前記商人位置のテーブルレイアウトを前記座席表に従って構成させるための前記座席表を送信することと、を含む動作を実行するように前記１つ以上のプロセッサをプログラムする、システム。
【0163】
Ｖ．第三者サービスまたは前記商人のうちの少なくとも１つに関連付けられたコンピューティングデバイスの１つ以上のプロセッサによって実行可能なアプリケーションであって、前記コンピューティングデバイスに関連付けられたディスプレイを介して、前記顧客または前記商人の少なくとも１つにインタフェースを提供することと、前記インタフェースを介して、予約を提供する代替商人、予約が要求された前記商人における座席オプション、前記予約のタイミング、および過去の座席選好に基づく前記要求された座席オプションとは異なる代替座席オプションの少なくとも１つに基づいて、前記座席表に対する更新を受信することと、前記座席表に関する情報が要求されたことを判定することと、前記１つ以上のＡＰＩを介しておよび前記サービスコンピューティングデバイスによって、前記座席表に対する更新に関する前記要求に対する応答を送信することと、前記サービスコンピューティングデバイスから予約提案を受信することと、予約提案が受諾されたことを判定することと、前記１つ以上のＡＰＩを介して、前記予約提案の受諾の指標を送信して、前記予約を容易にすること、を行うアプリケーションをさらに含む、節Ｕに記載のシステム。
【0164】
Ｗ．前記予約スケジューリングアプリケーションは、前記商人に関連付けられた前記コンピューティングデバイス、前記第三者サービスに関連付けられた前記コンピューティングデバイス、前記顧客に関連付けられたコンピューティングデバイスとインタフェースするアプリケーションプログラムインタフェース（ＡＰＩ）を提供するようにさらに構成される、節Ｕ又はＶに記載のシステム。
【0165】
Ｘ．前記サービスコンピューティングデバイス上でホストされるコンセンサスアプリケーションをさらに含み、前記コンセンサスアプリケーションは、前記第１の顧客対面予約アプリケーションおよび前記第２の顧客対面予約アプリケーションからそれぞれ前記第１の予約要求および前記第２の予約要求を受信し、前記コンセンサスアプリケーションは、前記顧客の好みに基づいて前記第１の予約要求および前記第２の予約要求を処理する、節Ｕ－Ｗの何れかに記載のシステム。
【0166】
Ｙ．前記サービスコンピューティングデバイスは、前記予約要求に関連付けられた顧客のさらなる情報を受信し、前記予約が要求された前記商人とは異なる商人のうちの１つを識別し、前記識別に基づいて前記他の商人位置において座席を割り当てるようにさらに構成される、節Ｖに記載のシステム。
【0167】
Ｚ．サービスコンピューティングデバイスプロセッサと、前記サービスコンピューティングデバイスプロセッサと通信可能に接続されたサービスコンピューティングデバイス通信インタフェースとを備えるシステムであって、前記サービスコンピューティングデバイス通信インタフェースは、複数の第三者のサービスデバイスと１つ以上のネットワークを介して通信し、且つ、顧客または商人の少なくとも１つと関連付けられたコンピューティングデバイスと、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記１つ以上のネットワークを通じてさらに通信し、前記サービスコンピューティングデバイスは、前記サービスコンピューティングデバイスによって提供される前記１つ以上のＡＰＩを介して、前記商人との予約に関する要求を受信することであって、前記要求は、商人位置での予約の好適な時間を示す、前記受信することと前記商人に関連付けられたデバイス上での提示のために、顧客の好みに従って前記予約を設定するための予約提案を生成することであって、前記予約提案は、（ａ）複数の座席オプションの中からの商人位置における座席、(ｂ)前記要求に対応する別のタイムスロット、および（ｃ）商人位置が予約されているなら代替座席オプションを含む、前記生成することと、前記１つ以上のＡＰＩを使用して、前記識別された第三者サービスに関連付けられている前記第三者サービスデバイスに、前記識別された第三者サービスが前記商人位置における座席を予約することを要求する通信を送信することと、を行うように構成されている、システム。
【0168】
ＡＡ．前記プロセッサは、第１の予約アプリケーションおよび第２の予約アプリケーションを含む複数の予約アプリケーションから予約を受信するように構成された前記商人デバイスに関連付けられた商人のために予約を割り当てるようにさらに構成され、前記プロセッサは、支払サービスによって、前記第１の予約アプリケーションから、前記第１の予約アプリケーションを使用して行われた第１のデータ関連予約を受信することと、前記支払サービスによって、前記第２の予約アプリケーションから、時間期間に前記第２の予約アプリケーションを使用して行われた第２のデータ関連予約を受信することと、前記支払サービスによって、レストランでの利用可能な座席に関するデータを受信することと、少なくとも第１のデータに基づいて、前記利用可能な座席から座席の第１の部分の座席を前記第１の予約アプリケーションに割り当てることであって、前記第１の予約アプリケーションのユーザは前記第１の部分の座席以下の座席を予約できる、前記割り当てることと、少なくとも第２のデータに基づいて、前記利用可能な座席のうちの第２の部分の座席を前記第２の予約アプリケーションに割り当てることであって、前記第２の予約アプリケーションのユーザは他の部分の座席以下の座席を予約できる、前記割り当てることと、予約中、および少なくとも１つのユーザが前記第１の予約アプリケーションを使用して座席を予約することができないことに応答して、前記第２の予約アプリケーション上で何れかの座席が利用可能であるかどうかを判定することと、前記第１の予約アプリケーションのインタフェースから前記第２の予約アプリケーションに顧客デバイスを遷移させるための命令を提供することと、前記第２の予約アプリケーションを使用して前記レストラン内の前記座席の予約を示す入力を前記１つ以上のユーザから受信することと、を含む１つ以上の動作を実行する、節Ｚに記載のシステム。
【0169】
ＡＢ．１つ以上のプロセッサにより実行される場合に、動作を前記１つ以上のプロセッサに実行させる命令を記憶する１つ以上の非一時的なコンピュータ可読媒体であって、前記動作は、サービスコンピューティングデバイスに関連付けられた１つ以上の商人へのアクセスをコンピューティングデバイスに提供するために、サービスコンピューティングデバイスによって、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を公開することと、前記商人に関連付けられた１つ以上のアクションを容易にすることができる１つ以上の第三者サービスへのアクセスをコンピューティングデバイスに提供するために、前記サービスコンピューティングデバイスによって、前記１つ以上のアプリケーションプログラミングインターフェースインタフェース（ＡＰＩ）を公開することと、前記１つ以上のＡＰＩを介して、前記商人および前記第三者サービスの前記コンピューティングデバイスから、前記商人に関連付けられたアクションを処理するための要求を受信することと、前記商人に関連付けられた前記アクションを容易にするアクション提案を生成することであって、前記アクション提案は前記アクション内のステップが実行されるシーケンスを含む、前記生成することと、前記第三者サービスまたは前記商人に関連付けられた前記コンピューティングデバイスに前記アクション提案を送信することと、前記サービスプロバイダによって、前記１つ以上のＡＰＩを介して、前記アクション提案に基づいて支払フローを構成することであって、前記支払フローは、前記第三者サービスと前記商人との間のサブアクションの分配に基づくものである、前記構成することと、を含む、１つ以上の非一時的なコンピュータ可読媒体。
【0170】
ＡＣ．前記１つ以上のアクションは、アイテムの配送、前記アイテムの準備、前記アイテムのキャンセル、注文の配送、前記注文の準備、前記注文のキャンセル、注文のマージ、前記注文の分割、顧客の予約、顧客のアポイントメント、第三者サービスにわたるコンテンツの更新、前記アイテムの更新、前記注文の更新を含む、節ＡＢに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0171】
ＡＤ．前記アクション提案は、予約を提供する代替商人、予約が要求された前記商人における座席オプション、前記予約のタイミング、および過去の座席選好に基づく前記要求された座席オプションとは異なる代替座席オプションのうちの少なくとも１つを示す予約提案である、節ＡＡ－ＡＣの何れかに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0172】
ＡＥ．前記１つ以上のＡＰＩを公開することは、商人に関連付けられたコンピューティングデバイスに前記１つ以上のＡＰＩを公開して、前記商人が物理的位置またはオンライン位置のうちの１つにおける前記商人との予約またはアポイントメントを容易にすることを可能にすることを含む、節ＡＢに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0173】
ＡＦ．前記動作は、前記１つ以上のＡＰＩを介して、前記コンピューティングデバイスから、前記予約要求に対する修正の要求を受信することと、前記商人に関連付けられ、且つ複数の第三者サービスを通じて行われた予約を含む、座席表にアクセスすることと、前記修正が競合条件を引き起こすか否かを判定することと、前記判定に基づいて新しい座席を判定することと、をさらに含む、節ＡＥに記載の１つ以上の非一時的コンピュータ可読媒体。
【0174】
ＡＧ．前記動作は、前記１つ以上のＡＰＩを介して、他の座席を予約するための他の要求を受信することであって、前記他の座席は、以前の予約に割り当てられた座席と一致する、前記受信することと、更新された顧客選好に基づいて、前記第１の要求または前記第２の要求のための代替の座席オプションを識別することと、前記識別するステップに従って、更新する座席表を示す通信を前記商人に送信することと、をさらに含む、節ＡＥまたはＡＦに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0175】
ＡＨ．前記動作は、前記商人および前記第三者サービスによって実行される現在および過去のアクションに関する訓練データを取得することと、前記訓練データに基づいて、アクション提案を生成するために機械学習モデルを訓練することとをさらに含む、節ＡＢ－ＡＧの何れかに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0176】
ＡＩ．インタフェースを表示するように構成されたディスプレイと、前記ディスプレイに通信可能に接続された１つ以上のプロセッサと、前記１つ以上のプロセッサに通信可能に接続され、且つ前記１つ以上のプロセッサにより実行される場合に前記１つ以上のプロセッサに動作を実行させる実行可能な命令を記憶するメモリと、を備えるシステムであって、前記動作は、ディスプレイ上で、第１の予約アプリケーションを使用して第１の商人位置で第１の予約を受信することと、前記ディスプレイ上で、第２の予約アプリケーションを使用して第２の商人位置で第２の予約を受信することと、前記ディスプレイ上で、前記第１の予約および前記第２の予約に対応する座席を予約するための座席表を含む予約提案を受信することであって、前記座席表は、１つ以上のアプリケーションプログラムインタフェース（ＡＰＩ）を介して、前記ディスプレイを有する前記システム、前記第１の予約サービス、および前記第２の予約サービスとインタフェースされたサービスコンピューティングデバイスによって生成される、座席表における変更を示す前記商人からのリアルタイム入力に基づいて、前記ディスプレイ通じて前記座席表を修正することと、前記サービスプロバイダに対するＡＰＩ呼び出しを開始することによって、前記修正に基づく座席の再割り当てを引き起こすことと、を含む、システム。
【0177】
ＡＪ．前記動作は、前記１つ以上のＡＰＩを介して、前記サービスコンピューティングデバイスに、前記第１の予約サービスまたは前記第２の予約サービスに予約ステータスを提供するためのトリガを送信することと、前記予約ステータスを前記顧客に関連付けられた前記コンピューティングデバイスへ送信させることとをさらに含む、節ＡＩに記載のシステム。
【0178】
ＡＫ．前記システムは商人デバイスを含み、前記動作は、前記１つ以上のＡＰＩを介して、他の座席を予約するための他の要求を受信することであって、前記他の座席は、以前の予約に割り当てられた座席と一致する、前記受信することと、更新された顧客選好に基づいて、前記第１の要求または前記第２の要求のための代替の座席オプションを識別することと、前記識別するステップに従って、更新する座席表を示す通信を前記商人に送信することと、をさらに含む、節ＡＩまたはＡＪに記載のシステム。
【0179】
ＡＬ．前記予約提案は、予約を提供する代替商人、予約が要求された前記商人における座席オプション、前記予約のタイミング、および過去の座席選好に基づく前記要求された座席オプションとは異なる代替座席オプションのうちの少なくとも１つを示す、節ＡＩ－ＡＫの何れかに記載のシステム。
【0180】
ＡＭ．前記予約提案は、前記要求を前記第１の予約アプリケーションから前記第２の予約アプリケーションにルーティングすることによって、公的な座席を予約するオプションのうちの少なくとも１つを示し、前記ルーティングは、前記第１の予約アプリケーションに関連付けられた第１のユーザインタフェースから、前記第２の予約アプリケーションに関連付けられた第２のユーザインタフェースへ遷移することを含む、節ＡＩ－ＡＬの何れかに記載のシステム。
【0181】
ＡＮ．前記動作は、前記第１の予約および前記第２の予約が実質的に同時に行われる場合にコンセンサスを提供することをさらに含む、節ＡＩ－ＡＭの何れかに記載のシステム。
【0182】
ＡＯ．メニューに関連付けられた最適化されたコンテンツ管理を提供するためのシステムであって、前記システムは、１つ以上のプロセッサと、前記１つ以上のプロセッサによって実行可能な命令を記憶する１つ以上の非一時的なコンピュータ可読媒体とを備え、前記命令は、サービスコンピューティングデバイスに関連付けられたコンテンツ管理アプリケーションによって、且つ、商人に関連付けられた販売時点情報管理デバイス上で実行されることによって、前記商人によって提供される１つ以上のメニューアイテムに関するコンテンツ更新を受信することであって、前記コンテンツ更新は顧客対面アプリケーションに配信するように構成される、前記受信することと、前記コンテンツ更新が１つ以上の追加の顧客対面アプリケーションに適用されるかどうかを、前記コンテンツ管理アプリケーションによって判定することであって、前記１つ以上の追加の顧客対面アプリケーションは、１つ以上のアプリケーションプログラムインタフェース（ＡＰＩ）を介して前記コンテンツ管理アプリケーションとインタフェースされる、前記判定することと、前記サービスコンピューティングデバイスによって、且つ、前記コンテンツ更新が１つ以上の追加の顧客対面アプリケーションに適用されると判定されることに基づいて、前記１つ以上の追加の顧客対面アプリケーションのインタフェースを、前記１つ以上のＡＰＩを介して前記コンテンツ更新に従って更新させることと、前記顧客対面アプリケーションが前記コンテンツ更新を受信したことを示す通知を、前記商人に関連付けられたキッチンディスプレイシステムに送信することと、を含む動作を前記１つ以上のプロセッサが実行するようにプログラムする、システム。
【0183】
ＡＰ．第三者サービス又は商人の少なくとも１つに関連付けられているコンピューティングデバイスの１つ以上のプロセッサによって実行可能なアプリケーションをさらに含み、前記コンピューティングデバイスに関連付けられたディスプレイを介して、前記顧客または前記商人の少なくとも１つにインタフェースを提供し；、前記インタフェースを介して、前記顧客対面アプリケーションが前記コンテンツ更新を受信したことを示す通知を受信して他の顧客対面アプリケーションにまたがって同期化することを示す通知を受信し；、前記コンテンツ更新が、ターゲットとなる顧客対面アプリケーションにのみ送信されることを判定し；、前記１つ以上のＡＰＩを介して、且つ、前記サービスコンピューティングデバイスによって、前記他の顧客対面アプリケーションを含む、ターゲットとされていない顧客対面アプリケーションから前記コンテンツ更新を取り消す；、節ＡＯに記載のシステム。
【0184】
ＡＱ．前記コンテンツ管理アプリケーションは、前記商人に関連付けられた前記コンピューティングデバイス、前記第三者サービスに関連付けられた前記コンピューティングデバイス、前記顧客に関連付けられたコンピューティングデバイスとインタフェースするためにアプリケーションプログラムインタフェース（ＡＰＩ）を提供するようにさらに構成される、節ＡＯ又はＡＰに記載のシステム。
【0185】
ＡＲ．前記サービスコンピューティングデバイス上でホストされるコンセンサスアプリケーションをさらに含み、前記コンセンサスアプリケーションは、前記コンテンツ管理アプリケーションの１つ以上のインスタンスを実行する１つ以上の販売時点管理（ＰＯＳ）デバイスに関連付けられた商人から複数のコンテンツ更新を受信し、前記コンセンサスアプリケーションは、前記顧客の選好に基づいて前記複数のコンテンツ更新のうちの１つを選択する、節ＡＯ－ＡＱの何れかに記載のシステム。
【0186】
ＡＳ．前記サービスコンピューティングデバイスは、在庫データベースに基づいて、前記コンテンツ更新を生成すべきかどうかを判定し、前記顧客対面アプリケーションのうちのどれが前記コンテンツ更新を受信すべきかを識別し、前記識別された顧客対面アプリケーションに前記コンテンツ更新を送信するようにさらに構成される、節ＡＯ－ＡＲの何れかに記載のシステム。
【0187】
ＡＴ．サービスコンピューティングデバイスプロセッサと、前記サービスコンピューティングデバイスプロセッサと通信可能に接続されたサービスコンピューティングデバイス通信インタフェースとを備えるシステムであって、前記サービスコンピューティングデバイス通信インタフェースは、複数の第三者のサービスデバイスと１つ以上のネットワークを介して通信し、且つ、顧客または商人の少なくとも１つと関連付けられたコンピューティングデバイスと、１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記１つ以上のネットワークを通じてさらに通信し、前記サービスコンピューティングデバイスは、前記サービスコンピューティングデバイスによって提供される１つ以上のＡＰＩを介して、コンテンツ更新の要求を受信することであって、前記コンテンツ更新は顧客対面アプリケーションに配信するように構成され、且つ前記商人によって提供される１つ以上のメニューアイテムに関連しており、前記要求は、前記顧客または前記商人の少なくとも１つに関連付けられた前記コンピューティングデバイス上で実行可能なアプリケーションから、前記１つ以上のＡＰＩを介して生成される、前記受信することと、前記コンテンツ更新が他の顧客対面アプリケーションに適用されるかどうかを、前記サービスコンピューティングデバイスによって提供される前記１つ以上のＡＰＩを介して、判定することであって、前記他の顧客対面アプリケーションは１つ以上のアプリケーションプログラムインタフェース（ＡＰＩ）を介して前記アプリケーションとインタフェースされる、前記判定することと、前記サービスコンピューティングデバイスによって、前記コンテンツ更新が他の顧客対面アプリケーションに適用されると判定することに応じて、前記商人のために、前記顧客対面アプリケーションと関連付けられた配送の前記位置に前記コンテンツ更新を配信するための提案を生成することであって、前記提案は、（ａ）前記第三者サービスデバイスに関連付けられた複数の顧客対面アプリケーションの中からの１つ以上の顧客対面アプリケーションであって、前記複数の顧客対面アプリケーションは前記サービスコンピューティングデバイスの前記１つ以上のＡＰＩを介して前記商人と通信する、前記１つ以上の顧客対面アプリケーション、（ｂ）前記コンテンツ更新を適用する緊急性を示すコンテンツ更新の性質、および（ｃ）前記コンテンツ更新の配信の推定時間を含む、前記生成することと、前記コンテンツ更新に従って前記他の顧客対面アプリケーションのインタフェースを更新させることと、前記１つ以上のＡＰＩを使用して、前記商人に関連付けられたキッチンディスプレイシステムに、前記顧客対面アプリケーションが前記コンテンツ更新を受信したことを示す通知を送信することと、を行うように構成される、システム。
【0188】
ＡＵ．前記システムは、前記コンピューティングデバイスに関連付けられたディスプレイを介して、前記顧客または前記商人のうちの少なくとも１つにインタフェースを提供し、前記インタフェースを介して、前記顧客対面アプリケーションが前記コンテンツ更新を受信したことを示す前記通知を受信し、前記コンテンツ更新がターゲットとされた顧客対面アプリケーションにのみ送信されるべきであると判定し、前記１つ以上のＡＰＩを介して、且つ、前記サービスコンピューティングデバイスによって、前記コンテンツ更新を、前記他の顧客対面アプリケーションを含むターゲットとされていない顧客対面アプリケーションから取り消すようにさらに構成される、節ＡＴに記載のシステム。
【0189】
ＡＶ．１つ以上のプロセッサにより実行される場合に、動作を前記１つ以上のプロセッサに実行させる命令を記憶する１つ以上の非一時的なコンピュータ可読媒体であって、前記動作は、サービスコンピューティングデバイスによって、前記サービスコンピューティングデバイスに関連付けられた１つ以上の商人へのアクセスをコンピューティングデバイスに提供するために１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を公開することと、前記サービスコンピューティングデバイスによって、前記商人に関連付けられた１つ以上のアクションを容易にすることができる１つ以上の第三者サービスへのアクセスをコンピューティングデバイスに提供するために前記１つ以上のアプリケーションプログラミングインタフェース（ＡＰＩ）を公開することと、前記１つ以上のＡＰＩを介して、前記商人および前記第三者サービスの前記コンピューティングデバイスから、前記商人に関連付けられた前記アクションを処理するための要求を受信することと、前記商人に関連付けられた前記アクションを容易にするアクション提案を生成することであって、前記アクション提案は前記アクション内のステップが実行されるべきシーケンスを含む、前記生成することと、前記第三者サービスまたは前記商人に関連付けられた前記コンピューティングデバイスに前記アクション提案を送信することと、前記サービスプロバイダによって、前記１つ以上のＡＰＩを介して、前記アクション提案に基づいて支払フローを構成することであって、前記支払フローは、前記第三者サービスと前記商人との間のサブアクションの分配に基づくものである、前記構成することと、を含む、１つ以上の非一時的なコンピュータ可読媒体。
【0190】
ＡＷ．前記１つ以上のアクションは、アイテムの配送、前記アイテムの準備、前記アイテムのキャンセル、注文の配送、前記注文の準備、前記注文のキャンセル、注文のマージ、前記注文の分割、顧客の予約、顧客のアポイントメント、第三者サービスにわたるコンテンツの更新、前記アイテムの更新、前記注文の更新を含む、節ＡＶに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0191】
ＡＸ．前記アクション提案は、更新されるコンテンツと、前記コンテンツ更新が送信される第三者サービスの識別子とを示すコンテンツ更新提案である、節ＡＶ又はＡＷの何れかに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0192】
ＡＹ．前記１つ以上のＡＰＩを公開することは、前記１つ以上のＡＰＩを、前記商人に関連付けられたコンピューティングデバイスに公開して、前記商人がメニューアイテムを含むコンテンツの更新を容易にすることを可能にすることを含む、節ＡＶに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0193】
ＡＺ．前記動作は、前記１つ以上のＡＰＩを介して、前記コンピューティングデバイスから、アイテムの配送ステータスの要求を受信することと、前記第三者サービスデバイスの位置情報を受信することと、前記第三者サービスによる前記コンテンツ更新のステータスを判定することと、前記コンピューティングデバイスに、前記コンテンツ更新の前記ステータスを送信することと、をさらに含む、節ＡＹに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0194】
ＢＡ．前記動作は、前記サービスコンピューティングデバイス上でホストされるコンセンサスアプリケーションを実行することをさらに含み、前記コンセンサスアプリケーションは、コンテンツ管理アプリケーションの１つ以上のインスタンスを実行する１つ以上の販売時点管理（ＰＯＳ）デバイスに関連付けられた前記商人から複数のコンテンツ更新を受信し、前記コンセンサスアプリケーションは、前記顧客の選好に基づいて前記複数のコンテンツ更新のうちの１つを選択する、節ＡＹ又はＡＺに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0195】
ＢＢ．前記動作は、前記商人および前記第三者サービスによって実行される現在および過去のアクションに関する訓練データを取得することと、前記訓練データに基づいて、前記アクション提案を生成するために機械学習モデルを訓練することとをさらに含む、節ＡＶ－ＢＡの何れかに記載の１つ以上の非一時的なコンピュータ可読媒体。
【0196】
ＢＣ．インタフェースを表示するように構成されたディスプレイと、前記ディスプレイに通信可能に接続された１つ以上のプロセッサと、前記１つ以上のプロセッサに通信可能に接続され、且つ前記１つ以上のプロセッサにより実行される場合に前記１つ以上のプロセッサに動作を実行させる実行可能な命令を記憶するメモリと、を備えるシステムであって、前記動作は、サーバアプリケーションによって、第１の顧客対面アプリケーションの第１のデバイスへの配送のための第１のコンテンツ要求を受信することと、前記サーバアプリケーションによって、第２の顧客対面アプリケーションの第２のデバイスへの配送のための第２のコンテンツ要求を受信することと、前記サーバアプリケーションによって、１つ以上の配送の位置に対して前記第１のコンテンツ要求および前記第２のコンテンツ要求を満たすための提案を生成することであって、前記提案は、（ａ）前記第三者サービスデバイスに関連付けられた複数の顧客対面アプリケーションの中からの１つ以上の顧客対面アプリケーションであって、前記複数の顧客対面アプリケーションは前記サービスコンピューティングデバイスの前記１つ以上のＡＰＩを介して前記商人と通信する、前記１つ以上の顧客対面アプリケーション、（ｂ）前記コンテンツ更新を適用すべき緊急性示すコンテンツ更新の性質、（ｃ）コンテンツ更新の配送のための推定時間量を含む、前記生成することと、前記サーバアプリケーションを介して、前記顧客対面アプリケーションへの前記コンテンツ更新のトリガを開始することと、前記サービスプロバイダへのＡＰＩ呼び出しを開始することによって、前記開始に基づく支払フローを引き起こすことと、を含むシステム。
【0197】
ＢＤ．前記動作は、前記１つ以上のＡＰＩを介して、前記サービスコンピューティングデバイスに、前記コンテンツ更新を前記第１または第２の顧客対面アプリケーションに提供するためのトリガを送信することと、前記サービスコンピューティングデバイスから、コンテンツ更新のステータスを受信することと、前記コンテンツ更新の配送の前記ステータスを前記第１または第２の配送サービスへ送信させることとをさらに含む、節ＢＣに記載のシステム。
【0198】
ＢＥ．前記システムは商人デバイスを含み、前記動作は、前記サービスコンピューティングデバイスから、他のアイテムの取得のための注文を受信することであって、前記他のアイテムは、前記第１の配送サービスの顧客デバイスを介して取得するために選択されている、前記受信することと、前記注文の受諾を示すユーザ入力を受信することと、前記注文の受諾の指標を前記サービスコンピューティングデバイスに送信することと、前記アイテムの配送の第１のステータスおよび前記他のアイテムの配送の第２のステータスを受信することと、配送の前記第１のステータスおよび配送の前記第２のステータスを前記インタフェースを介して表示させることと、をさらに含む、節ＢＣ又はＢＤに記載のシステム。
【0199】
ＢＦ．前記提案は、異なる商人アプリケーションにわたる前記第１のコンテンツ要求に対処する方法を示す、節ＢＣ－ＢＥの何れかに記載のシステム。
【0200】
ＢＧ．前記提案は、前記第１のコンテンツ要求が前記識別されたもの以外の他の顧客対面アプリケーションに適用されるかどうかを示し、前記動作は、既存のコンテンツを更新することと、新しいコンテンツを生成することと、既存のコンテンツを除去することと、をさらに含む、節ＢＣ－ＢＦの何れかに記載のシステム。
【0201】
ＢＨ．前記動作は、前記第１のコンテンツ要求および前記第２のコンテンツ要求が実質的に同時に行われるときにコンセンサスを提供することをさらに含む、節ＢＣ－ＢＧの何れかに記載のシステム。
【0202】
上記の例示的な節は１つの特定の実装形態に関して説明されているが、本明細書の文脈では例示的な節の内容が方法、デバイス、システム、コンピュータ可読媒体、および／または別の実装形態を介して実装することもできることを理解されたい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】