JP7470735B2 - An application programming interface for structuring distributed systems. - Google Patents

Description

PRIORITY This application claims priority to U.S. Patent Application Nos. 15/858,164, 15/858,000 and 15/858,100, all of which were filed on December 29, 2017, all of which are incorporated by reference in their entireties.

Buyers often use websites and other technologies to purchase items from merchants for delivery to the buyer. In some cases, a delivery system or service can facilitate the delivery of goods and services offered by the merchant. For example, a delivery service can provide an online site that identifies items from multiple merchants available for delivery. A buyer can navigate to the online site, select an item from a merchant, specify an address for delivery, and purchase the item for delivery to the buyer's address. A delivery service can utilize various technologies to accomplish the delivery of the item to a buyer. In particular, the delivery service can communicate with electronic devices associated with the merchant and/or electronic devices associated with the customer to deliver the item. The customer also uses technology to interact with the merchant, for example, to make a reservation to purchase an item or otherwise reserve their time or a service. Similarly, a reservation service can facilitate the reservation of a merchant's location for a particular service. However, when a merchant is associated with several of these delivery, reservation, and other third-party services, the merchant must manually control and coordinate the injection of information from different, unconnected sources, ultimately defeating the simplicity of operation promised by the third-party services. Additionally, the association of a merchant's interface with a third-party service may disrupt other technologies that a merchant employs to conduct its business.

The detailed description is described with reference to the accompanying drawings, in which the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. Use of the same reference number in the same or different drawings indicates similar or identical items or features.

FIG. 1 illustrates an example architecture in which the techniques described herein may be implemented.

FIG. 2 illustrates example details of a service provider that facilitates communication with and between multiple services and merchant portals.

FIG. 3 illustrates exemplary details of a merchant device receiving data from multiple different distributed services via a service provider.

FIG. 4 details an example user or consumer device that, in some implementations, hosts or accesses web or native third party services.

FIG. 5 illustrates an exemplary process for exposing one or more APIs to enable entities to use delivery services offered by a service provider.

FIG. 6 illustrates an exemplary process for communicating with a service provider via one or more APIs to use delivery services offered by the service provider.

FIG. 7 illustrates an exemplary process for notifying a third party service regarding the delivery of an item.

FIG. 8 illustrates an exemplary process for communicating via one or more APIs exposed by a service provider to provide status updates regarding an order.

FIG. 9 illustrates an exemplary data flow diagram illustrating a process for coordinating menu items across third party services and dynamically modifying user interface icons based on context data and a process for coordinating menu items across different services.

FIG. 10 illustrates an exemplary data flow diagram illustrating a process for reconciling reservations and allocating missing or overlapping reservations originating from multiple third party services.

The technology described herein provides a system and environment that allows an entity to compose different third-party services, such as an application for a delivery service, an application for a reservation service, and an application for a third-party service, through a service provider, such that the entity can communicate with the different services without complex coding or modifications to the entity's source code. In some examples, the service provider exposes the consensus service to computing devices associated with the merchant, the buyer, and/or other parties using one or more application programming interfaces (APIs) provided by the service provider. The service provider also exposes the consensus service to computing devices associated with users, consumers, or developers of the third-party applications using the APIs. In some examples, the service provider may be a third party operating remotely and/or independently from the merchant, the buyer, and/or other parties. The one or more APIs may enable the merchant and/or other parties to automatically integrate the consensus service into the technology used by the merchant and/or other parties to facilitate several tasks, such as delivery of items offered for acquisition by the merchant, restaurant reservations for both in-dining or pick-up, generating menus, etc. For example, one or more APIs to the consensus service may enable an entity to automatically access information regarding delivery of an item by multiple delivery services (e.g., delivery labor costs, estimated delivery times, etc.), facilitate delivery of the item by the delivery services, order preparation of the item, schedule delivery and preparation from the kitchen, schedule appointments, and use various other functions offered by the service provider through the consensus service, such as managing content to and from third-party services.

The implementation will be described first with reference to a delivery service or third-party service. In many examples, a service provider may operate a network of third-party service devices to deliver items to buyers and others. Each of the third-party service devices may implement a global positioning system (GPS) receiver or other location sensor to provide location information to the service provider. The service provider may track the location of the third-party service devices to select the third-party service device for delivery, send updates regarding delivery of the item, or otherwise facilitate delivery of the item by the third-party service. Additionally or alternatively, the service provider may operate in cooperation with multiple merchant devices. Each of the merchant devices may implement a global positioning system (GPS) receiver or other location sensor to provide location information to the service provider. The service provider may use the location of the merchant devices to facilitate delivery of items offered for acquisition by the merchant and perform other functions. Additionally or alternatively, the service provider may also communicate with multiple third-party services and may implement third-party service logic and systems to receive orders from customers for goods and services offered by the merchants. As described above, merchant, customer, and third party services and systems can interact with each other through the service provider's consensus system API.

The consensus system then acts as a hub, e.g., an order hub, to expose APIs for integrating third-party food ordering, delivery, or preparation services for central ordering in the point of sale system. The consensus system can update preparation or delivery times across multiple incoming services to automatically calculate new order analytics such as preparation time, delivery time, and preparation orders. The consensus system, in one embodiment, can leverage APIs to manage inventory information and provide order information. As an example of the technology described herein, if a merchant receives an order for 10 burgers from a third-party delivery service and another order for 5 burgers from a second third-party delivery service, the consensus system can update item availability, preparation, and delivery times in real time for the first and second third-party delivery services as well as any other third-party delivery services. The consensus system can also predict and anticipate employee staffing for ordered items so that the merchant has the appropriate staff and inventory based on past orders from various services. The consensus system can also direct automatic replenishment of inventory/ingredients or automatic reordering from vendors based on the status of incoming orders via multiple third-party services.

The consensus system can also act as a hub for reservations by utilizing one or more APIs for third party reservation service integration, centralized reservations, wait lists, and scheduling management. The consensus system can communicate with other third party reservation services to provide a central reservation system and dynamic allocation/reallocation of tables and preferred seats, and even offer pick-up when dine-in is not available. The consensus system monitors and analyzes seating demand and optimizes staffing and ingredients accordingly to support diners with preferred servers/chefs for specific reservations or desired menu items. Certain thresholds may be set for number of items, number of customized reservations allowed during a shift, etc. Additionally, the consensus system can assign any seating allocation to each service based on usage metrics and transfer users from one service to another via APIs to make reservations when one service cannot supply the user's request, regardless of whether the user subscribes to the other service. Additionally, the consensus system can be a hub for the allocation of reserved seats, and for the placement of seats in a manner that maps to customer profiles and merchant specifications. For example, frequent customers can be seated in the best areas of a restaurant. The consensus system also integrates with other verticals supported by the service provider. For example, the consensus system is integrated with an onboarding component so that when a new customer makes a reservation at a restaurant, the consensus system can create a customer profile and offer one of many third-party services that best fit the customer's profile. The consensus system can also recommend restaurants based on aggregated reviews from all services, such as by the weight or relevance of each third-party service.

The consensus system may be a hub, such as a menu hub, for content aggregation and analytics. In such an embodiment, the consensus system is a unified manager for dynamic pricing based on how users order on different menus from third-party services and optimize sales accordingly. The consensus system can drive a single menu update that is applicable to all third-party services, harmonizing the content on such services. The consensus system can also drive multiple updates or service-specific updates to account for usage metrics across third-party services. For example, the ordering of menu content can be set according to user popularity or usage across all third-party services, specific services, or even usage within specific areas within a service. For example, the payment service can modify the ordering of menus based on the popularity of the order or the user's behavior across different delivery services. For example, if the payment service does not have access to cart-level information from the third-party service, the payment service can capture such information as the order is placed in the kitchen. In this way, the payment service can leverage the exposed APIs to see how users navigate the third-party service menus and what items users tend to add but not check out, and adjust the global menu for the merchant (or specific menus for the merchant and the third-party service) accordingly.

As one example of the technology described herein, an application may run on a computing device associated with a merchant, a buyer, and/or others. The application may provide a user interface to enable an individual (e.g., a merchant, a buyer, etc.) to perform an action, such as placing an order for an item offered for acquisition by the merchant, reserving a table at a restaurant, viewing content, providing updates for a third party service, etc. For example, in the case of a delivery service, through the user interface, an individual may select an item to acquire and request that the item be delivered. For example, an individual may place an item in an electronic shopping cart for purchase and indicate an interest in having the item delivered. In some cases, an individual may specify a location for delivery, a location for pickup, a requested time for pickup, a number of items being acquired, a size of the item, whether the item is associated with a given category, a weight of the item, etc. In other examples, such information is automatically determined or obtained from a user profile or a merchant profile.

Once an individual has determined that they are interested in having an item delivered, an application for a third-party delivery service, etc., can communicate with the third-party service provider using an API provided by the service provider to facilitate delivery of the item via a consensus service associated with the service provider. For example, the application can send a request for the cost of delivery of the item, an estimated amount of delivery time for the item, etc. The third-party service can generate a delivery proposal for delivery to the service provider, e.g., via an API for the consensus service, for delivery of the item to the buyer's location using the associated delivery service. The delivery proposal may include the delivery cost, an estimated amount of delivery time, and/or other information regarding the delivery of the item. The service provider can send the delivery proposal via the consensus service to the application for acceptance or rejection. In some examples, the application presents information to an individual who interacts with a user interface, and the individual can provide input to accept or reject the proposal. In other examples, the application can operate according to one or more criteria to automatically accept or reject the delivery proposal (e.g., accept if the cost is below a threshold amount, accept if the estimated delivery time is below a threshold amount of time, etc.). In either case, the application can use the API to send an indication to the third-party service of accepting or rejecting the delivery offer.

The service provider may process the selection of a courier for delivery when the third party service is notified of the acceptance of the delivery offer. For example, the service provider may track the location of multiple courier devices over time and select a courier that meets one or more criteria, such as being within a certain distance to a pick-up location, being available to make the delivery, being associated with a transport vehicle capable of transporting the item, etc. In some cases, the service provider may select a courier using a courier profile, a user profile, a merchant profile, or other information. The service provider may then send a communication to the courier requesting that the courier pick up the item from the merchant's facility and transport the item to a delivery location. During delivery of the item, the service provider may receive information from the courier and/or merchant (e.g., location information, confirmation that the delivery has been picked up, etc.) and determine the status of the delivery. The service provider may send the status of the delivery to an application, a merchant device, a buyer device, and/or others, so that individuals may be notified of the current state of the delivery.

In many cases, the technologies and environments described herein provide one or more APIs to access the consensus services provided by the service provider and to support delivery services, reservation services, and content services. That is, the one or more APIs can provide the entity with a flexible structure for integrating various third-party services into the entity's technology. As an example, a merchant can integrate a third-party service into a website or application operated by the merchant without creating additional components to implement the third-party service. By doing so, the website or application can operate according to a thinner implementation (e.g., with fewer components) compared to a website or application that incorporates such features directly into the website or application. This can result in relatively fast implementation of the website or application. Furthermore, the technologies and environments can enable the integration of third-party services to be implemented across a wide variety of contexts (e.g., devices, platforms, etc.). Furthermore, the technologies and environments provide a flexible structure for modifying the underlying technology, e.g., the consensus service, used by the service provider to implement the third-party service. In other words, the underlying technology of the merchant platform may be updated in a uniform and/or simplified manner without requiring updates to the technology implemented by the merchant, the buyer, and/or others. Additionally, the technology and environment may enable the underlying technology used by the service provider (including, for example, algorithms, cost schemes, etc.) to be maintained in a secure environment. Also, data shared by multiple third party services need not be exposed to the merchant, and further, the service provider may create data controls and data encapsulation based on third party services, environment, location, time, etc., which may be specific to the third party service or specific to the relationship between the third party service and the merchant platform, such as a terminal, application, kitchen display system, payment application, etc.

The benefits of a central ordering system include better management of orders, scheduling of orders, and elimination of multiple tablets hanging around the walls listing orders for each third party service. Using the technology described herein, merchants can install a single kitchen display system that can track orders coming from different sources and manage orders, inventory, and order timing in real time or near real time.

Advantages of a central restaurant system include better management of reservations, tracking restaurant reviews from multiple sources, and eliminating double bookings while reserving or overbooking a restaurant. While the description refers to a restaurant as an example use case, it will be understood that the description can be extended to other use cases for reservations and appointments such as salons, hospitals, yoga studios, etc. Using the techniques described herein, reservations can be optimized and seating allocations can be assigned in real time to third party reservation services based on, for example, filling capacity.

Advantages of a central content consensus system include better management of content such as menus, prices, operating hours, etc., and all third-party services get the same updates from the merchant at the same time. With the techniques described herein, content can be harmonized across different third-party services so that prices, brand, and merchant look and feel are maintained consistently. The consensus system can be a unified manager for dynamic pricing and can optimize sales by tracking order data such as what and how much users are ordering on different menus. Alternatively, different updates can be pushed to the third-party services in real-time or near real-time to target different types of audiences, i.e., adjust menu prices across all menus based on availability/popularity. For example, by determining that a customer ordering at a first third-party service orders fast food early in the morning, the menu may be configured to present fast food items on the list, for example, in order of preparation time or popularity. Additionally or alternatively, pricing of items may be configured to map to data analytics. In some implementations, payment flows may be modified as the merchant modifies the items. For example, if a merchant decides to remove an item from their menu (sometimes called a removed item), but an order has already been placed for that item in addition to other items, the consensus system can modify the preparation and payment flow to exclude the rejected item so that the customer is either refunded or never charged for the item. In some implementations, the rejected item may be replaced with another item, e.g., a similar item, an item of similar cost, a new offer, a discount, a notification to the customer, etc.

Furthermore, the technology herein can enable any third-party service to be onboarded and integrated for delivery of items from a merchant to a buyer, or to provide any other service without any configuration or termination relationship with the merchant, since the consensus system through APIs can interface with various hardware and software platforms by porting instructions and data with no or little modification to its source code. Through the interaction of computing devices, mobile devices, and sensors, the implementations herein can manage an unpredictable shared ecosystem in which multiple entities can participate to accommodate the ever-changing circumstances and conditions of merchants, buyers, service areas, third-party services, hardware and software platforms, and the third-party services themselves.

In various implementations, the consensus system may act as a central server, or group of servers, ingesting data from various sources via APIs, porting instructions and data into formats understood by various services, filtering the data to determine relevance to various merchants and services, and using analytics to structure or restructure various merchant tasks such as delivery, booking, content aggregation, or content display.

Some implementations in this specification describe bidirectional or push-pull APIs, meaning that information moves in both directions and that API endpoints are associated with both communicating applications. However, some implementations may implement unidirectional APIs, so that applications only need to push information or pull information when requested.

This brief introduction is provided for the convenience of the reader and is not intended to limit the scope of the claims. Moreover, the techniques described above and below can be implemented in several ways and in several contexts. As described in more detail below and with reference to the following figures, several example implementations and contexts are provided. However, the following implementations and contexts are just a few of many.

FIG. 1 illustrates an exemplary architecture 100 in which the techniques described herein may be implemented. The architecture 100 includes a service provider 102 associated with a consensus system or application (hereinafter also referred to as a "consensus service") that communicates with one or more users 104 (hereinafter "users 104") of an application, such as a consensus service, a buyer at a merchant location, a third party service, etc., one or more merchants 106 (hereinafter "merchants 106"), one or more third party services 108 (hereinafter referred to as a "delivery service 108", a "delivery person service", a "reservation service 108", a "content service", and collectively, third party services, depending on the context), one or more card payment network computing devices 110, and/or one or more bank computing devices 112 to perform various operations. The third party services may also include services provided by the service provider, such as for delivery, reservations, or content aggregation and management. In many cases, the service provider 102 may provide one or more application programming interfaces (APIs) 114 to allow the users 104 and/or merchants 106 to access the consensus service provided by the service provider 102. The APIs may be implemented as push APIs, pull APIs, or a combination of both. Thus, each application may create or share API endpoints for receiving or sending updates, or both. For example, a push API allows a push service to send push messages to web applications, sometimes asynchronously. An application server may send push messages at any time, even if the web application or user agent is inactive. A push service ensures reliable and efficient delivery to the user agent. The push message is delivered to a service worker running at the origin of the web application, which may use the information in the message to update local state or display notifications to the user. A pull API operates to extract data, for example, based on a scheduled job set to run at an interval. The system continues to poll the source until a certain condition is met.

Additionally, in many cases, the service provider 102 can facilitate a transaction between a buyer (first user) and a seller (second user), which can include communicating with one or more card payment network computing devices 110 and/or one or more bank computing devices 112. Each of the user 104, the merchant 106, and/or the third party service 108 can be associated with a computing device. For example, the third party service may run on a user device associated with the user 104 or the merchant device 106. Additionally, in some examples, the environment 100 includes an additional service provider (service provider 116) for communicating with the user 104 and/or the merchant 106 to facilitate the acquisition of an item, as described in more detail below. As illustrated, any computing device of the architecture 100 can communicate with each other via one or more networks 118.

A merchant may include any business or entity engaged in providing goods or services for acquisition by a buyer in exchange for consideration received from the buyer. Actions attributable to a merchant may include actions performed by employees or other agents of the merchant, and thus, no distinction is made herein between a merchant and its employees, unless otherwise discussed. Additionally, a buyer may include any entity that acquires goods or services from a merchant, by purchasing, renting, leasing, borrowing, licensing, and the like. Hereinafter, goods and/or services may be referred to as items. Items may include finished goods, partially finished goods, raw materials, and the like. Thus, a merchant and a buyer may interact with each other to conduct a transaction in which a buyer acquires one or more items from a merchant and, in return, the buyer provides payment to the merchant.

A third party service, such as a delivery service, may include an entity engaged in the delivery of items. The third party service may retrieve items from a delivery pick-up location (e.g., a merchant's location) and transport the items to a delivery drop-off location (e.g., a buyer's location). Some implementations herein provide technology innovations that allow a merchant to reconcile delivery requests (also called orders) coming in from different delivery portals 108. With such technology, a merchant may coordinate and synchronize orders with respect to inventory, order time, customer loyalty ratings, etc.

Third party services, such as restaurant management services, can include any entity that enables reservations at their locations, such as online reservations or in-person reservations. Additionally, the term reservation is intended to include appointments, in-person dining, pick-up, and the like. The third party service can receive requests to make reservations at merchant locations. Some implementations herein provide technology innovations that allow merchants to reconcile reservation requests (also referred to as reservations) that come in from different reservation portals 108. With such technology, merchants can coordinate and synchronize orders with respect to seating availability, diner preferences, time, location, items available on the menu, and the like.

A third-party service, such as a content aggregation service, may include any entity engaged in delivering items. A third-party service may display content without any consideration of what other third-party services are doing, and without knowing what its customers want to see, particularly with respect to the merchant's store. Some implementations herein provide innovations that allow merchants to harmonize content, such as menus, across different third-party services 108. With such techniques, merchants may coordinate and synchronize menus and other content with respect to the third-party service's profile, time of day, location, and other such specifications. Menus or menu updates may be pushed as a single update or notification on all third-party services simultaneously. Alternatively or additionally, menus and other such content, such as display of content, ordering of items, etc., may be configured according to the relationship between the third-party service and the merchant, availability of items, time of day, and other such factors.

As described above, the service provider 102 exposes one or more APIs 114 of the consensus service to enable computing devices associated with the user 104 and/or the merchant 106 to access, harmonize, normalize, refactor, adjust, and/or interface with third-party services provided by the service provider 102, so that the merchant or user process is structured in an optimal manner. For ease of explanation, in the example of FIG. 1, the computing devices associated with the user 104 and/or the merchant 106 are referred to as "acquisition devices." In the example of FIG. 1, the acquisition devices communicate with the service provider 102 through one or more APIs 114 to facilitate actions such as delivery of items, seat reservations, menu updates, etc. The acquisition devices display various information regarding delivery of items received from the service provider 102 via the item acquisition interface 120. In this example, the acquisition devices perform a delivery service 108-1 for delivery of items such as pizza, while performing a delivery service 108-2 for delivery of items such as beverages. In some cases, the acquisition devices may be different and the merchant may receive two separate delivery requests from different third-party services. While making the request, the service provider may use the consensus service 132 to determine the received order and the timing of the order. The consensus service 132 may, for example, use machine learning models to determine when the order should be placed, which items can be collected for preparation, etc. The consensus service 132 schedules the order for a kitchen display system (not shown) associated with the merchant. In this way, the merchant does not need to maintain multiple tablets corresponding to the orders coming from different sources. A single tablet may, for example, indicate the source, timing, estimated time of delivery, and new order of preparation of the order based on the timing, source, location, time of preparation, etc. Similarly, for a reservation request, the consensus service 132 creates a single list of reservations and a method of distributing (distributing) the seats and reservations among users and merchants. Additionally, the consensus service may interface with the parties to communicate the progress of the request in real time or near real time.

For example, the acquisition device may communicate with the merchant via the service provider 102 through one or more APIs 114 while placing an order with the merchant 106. In particular, an individual (user 104 and/or merchant 106) may place an item in an online shopping cart for purchase and indicate an interest in having the item delivered. In response, the acquisition device may send a request to the service provider 102 via one or more APIs 114 for information regarding delivery, reservations, or content management. The service provider 102 may communicate with the merchant or a merchant inventory database (locally or remotely) to generate a delivery offer for delivery of the item by a delivery service associated with the service provider 102 and send the delivery offer to the acquisition device via an API call 134. The acquisition device may display the information of the delivery offer via the item acquisition interface 120(a) for acceptance or rejection. As shown in FIG. 1, an estimated amount of time and delivery cost for delivering the item are presented at 122 in the acquisition interface 120(a). The individual may accept the delivery offer and place the order by selecting a button 124.

Additionally, the acquisition device may communicate with the service provider 102 via one or more APIs 114 to obtain status updates regarding the delivery of an item ordered by another third party service or another user. In such a case, the service provider 102 may monitor the location of a courier (e.g., third party service 108) assigned to deliver the item or obtain such information from a third party service associated with the courier, obtain information from a merchant (e.g., merchant 106) selling the item, and/or obtain other information. The service provider 102 may determine the status of the delivery of the item and send the status of the delivery to the acquisition device. The status of the delivery may be displayed via the item acquisition interface 120(b). The status may be determined and/or provided to the acquisition device upon request from the acquisition device (e.g., in response to a message sent via one or more APIs 114), periodically, and/or upon the occurrence of another event. As shown in FIG. 1, the item acquisition interface 120(b) may include a button 126 that, when selected, displays a map showing the current location of the assigned third-party service device, the route traveled by the assigned third-party service device, the route that will be further taken by the assigned third-party service device to pick up or deliver the item, etc.

In the example of FIG. 1, the delivery service information request 128 represents a communication sent by the acquisition device to the service provider 102 via one or more APIs 114, while the delivery service information 130 represents a communication sent back to the acquisition device from the service provider 102, such as a consensus call to indicate how orders are sequenced, how concurrent order requests are handled, fraudulent requests, delivery times, seating charts, and other information for the merchant to schedule and organize operations. The delivery service information request 128 can include information regarding the delivery of the item (e.g., cost estimate, delivery time estimate, etc.), an indication of acceptance/rejection of the delivery offer, a request for information regarding the delivery status, etc. The delivery service information 130 can include the delivery offer, information regarding the delivery status of the item, etc.

In some cases, the acquisition device may operate in cooperation with the service provider 116. The service provider 116 and associated applications, such as a consensus service, may provide resources that operate remotely and/or independently from the acquisition device and/or the service provider 102. In one example, the service provider 116 may be associated with the merchant 106 to manage purchases, inventory, and/or perform other processes. The service provider 116 may provide an online site or operate in cooperation with local applications (e.g., desktop applications, mobile applications, etc.) on the acquisition device. By way of example, the service provider 116 may provide an online website for a pizza restaurant and all delivery services that customers can order, so that customers (and/or the pizza merchant) can place pizza orders with the pizza merchant. In this manner, communications sent to and/or received by the acquisition device from the service provider 102 may be routed through the service provider 116. In other words, the service provider 116 may operate as an intermediary between the acquisition device and the service provider 102, and between the merchant and the third-party services. This type of architecture allows data to be selectively shared privately between parties such that only data relevant to the parties is revealed. The service provider 116 can communicate with the service provider 102 via one or more APIs 114. This can provide a seamless integration of the delivery services provided by the service provider 102 into the technology associated with the merchant 106. Returning to the pizza restaurant example above, the pizza restaurant's website can integrate the delivery services of the service provider 102 by communicating with the service provider 102 via one or more APIs 114. In some cases, this can occur without the customer knowing that the pizza restaurant is using such a delivery service (e.g., so that the delivery appears to be provided by the merchant 106). In other examples, information can be communicated to the customer indicating that the delivery service is provided by the service provider 102 (e.g., a pop-up window indicating that the pizza is delivered by Company X). Although many functions are described as being performed by the service provider 116, any of these functions may be performed by the service provider 102.

The service provider 102 may additionally or alternatively perform processes to manage the third-party service. For example, the service provider 102 may communicate with the third-party service 108 to track the location of the third-party service 108, request delivery of the item, receive status information regarding the delivery (e.g., confirmation from the third-party service that the item has been picked up or dropped off), and so on. In the exemplary environment 100, the service provider 102 may receive an indication of acceptance of the delivery offer or recommendation offer from the acquisition device and select a third-party service to deliver the item. The service provider 102 may identify the locations of multiple third-party services and select a third-party service (in this case, the third-party service 108) to transport the item to the delivery location. The service provider 102 may then send a delivery request 134 to the third-party service 108 requesting delivery of the item, and in return, the third-party service 108 may send an indication of acceptance or rejection of the delivery request.

In some cases, the service provider 102 may cause a payment to be made to any party within the environment 100. For example, the service provider 102 may cause funds from an account associated with the user 104 to be transferred to an account associated with the merchant 106 as payment for an item. Additionally, funds may be transferred from accounts associated with the service provider 102, the merchant 106, and/or the user 104 to an account associated with a third-party service 108 for delivery of the item. Payment may further be made to the service provider 102 to facilitate the transaction.

As described above, the service provider 102 can communicate with one or more card payment network computing devices 110 to conduct transactions electronically. The one or more card payment network computing devices 110 can be associated with a card payment network (e.g., MasterCard®, VISA®, etc.). The service provider 102 can also communicate with one or more bank computing devices 112 of one or more banks. For example, the service provider 102 can communicate with an acquiring bank, a card issuing bank, and/or a bank that maintains a user account for electronic payments.

The acquiring bank may be a registered member of a card association (e.g., Visa®, MasterCard®, etc.) and may be part of a card payment network. The card issuing bank may issue a payment card to a user and may make payments to the acquiring bank for purchases made by the cardholder to whom the card issuing bank issued the payment card. Thus, in some examples, the computing device of the acquiring bank may be included in the card payment network and may communicate with the computing device of the card issuing bank to obtain payment. Additionally, in some examples, the user may use a debit card instead of a credit card, in which case the bank computing device of the bank corresponding to the debit card may receive communications regarding transactions in which the user is participating. Additionally, there may be computing devices of other financial institutions involved in several types of transactions or alternative system architectures, and thus the above are merely some examples for purposes of discussion.

The one or more card payment network computing devices 110 and/or the one or more bank computing devices 112 may be implemented as one or more computing devices, such as a server, a laptop computer, a desktop computer, etc. The one or more computing devices may be configured in a cluster, a farm, a data center, a cloud computing environment, or combinations thereof. In one example, the one or more computing devices provide cloud computing resources including computational resources, storage resources, etc.

As described above, the computing devices of the architecture 100 may communicate via one or more networks 118. The one or more networks 118 may be any type of network, such as a local area network or a wide area network such as the Internet, and may include a wireless network, such as a cellular network, a local wireless network, such as Wi-Fi, and/or a short-range wireless communication, such as Bluetooth® and Bluetooth® Low Energy, a wired network, or any other such network, or any combination thereof. Thus, the one or more networks 118 may include both wired and/or wireless communication technologies, including Bluetooth®, Bluetooth® Low Energy, Wi-Fi, and cellular communication technologies, as well as wired or optical fiber technologies. The components used for such communication may depend, at least in part, on the type of network, the selected environment, or both. As a result, the one or more computing devices of the architecture 100 may be communicatively connected to the one or more networks 118 in any manner, such as a wired or wireless connection.

The techniques described herein may be implemented in a variety of contexts and/or in a variety of manners. As an example, the techniques may be implemented with a merchant-facing component (e.g., an application, online site, interface, etc. designed for a merchant). In this example, a merchant 106 may place an order for a customer. Specifically, the customer may enter the merchant's 106 premises, call the merchant 106, send a notice (e.g., email, text message, social media post, etc.) to the merchant 106, or otherwise communicate with the merchant 106. The merchant 106 may interact with a merchant-facing component (e.g., an item acquisition interface 120 designed for use by the merchant) to select an item identified by the customer and/or enter other information provided by the customer (e.g., a shipping address, etc.). Once a shipping proposal is received from the service provider 102, the merchant 106 may communicate the shipping proposal information to the customer (e.g., display a screen with shipping costs, read the shipping costs to the customer from the item acquisition interface 120, send a notification, etc.). Alternatively, the merchant 106 may refrain from providing the shipping offer information to the customer. For example, the merchant 106 may decide to offer free shipping to the customer, include the shipping cost in the total cost of the order (e.g., without itemizing), etc. In any case, the merchant 106 may accept or reject the shipping offer and/or order the item based on the communication from the customer.

As another example, the techniques may be implemented with a customer-facing component (e.g., an application, online site, interface, etc. designed for a customer). In this example, a customer may place an order directly with a merchant 106. Specifically, the customer may navigate to an online site associated with the merchant 106, open an application associated with the merchant 106 (e.g., a desktop application, a mobile application, etc.) and place an order with the merchant 106. In some examples, the customer may view shipping information (e.g., shipping cost, estimated amount of time for delivery, etc.) during the process, while in other examples, the information may not be shown to the customer or included within other information (e.g., the total cost of the order). Additionally, the customer may view status updates of the delivery via the customer-facing component.

As yet another example, the technique may be performed automatically without user input. In this example, no information is displayed or otherwise communicated to the individual. For example, one or more criteria for accepting/rejecting a delivery offer may be set such that the delivery offer is automatically accepted/rejected if one or more criteria are met. By way of example, a delivery offer may be accepted (or rejected) if the cost of the delivery is below (or above) a threshold cost, if the estimated amount of time for the delivery is below (or above) a threshold amount of time, if the estimated pick-up time for the delivery is before (or after) a particular time, if the estimated drop-off time for the delivery is before (or after) a particular time, etc. Thus, in some cases, information regarding the delivery may not be displayed via the item acquisition interface 120.

Similarly, for reservations, reservation requests may be initiated by the merchant via a merchant device, by the customer via a customer device, by a third party device through settings made by the merchant or customer, or automatically through a consensus service based on machine learning of transactions between the merchant and customer. For content aggregation and analysis, content requests such as pushing a customized menu or reconciling menus across different services, content requests via API calls may be initiated by the merchant via a merchant device, by the customer via a customer device, by a third party device through settings made by the merchant or customer, or automatically through a consensus service based on machine learning of transactions between the merchant and customer.

2 illustrates exemplary details of the service provider 102 (or possibly the service provider 116) of FIG. 1. The service provider 102 may be implemented as one or more computing devices, such as a server, a laptop computer, a desktop computer, etc. The one or more computing devices may be configured in a cluster, a farm, a data center, a cloud computing environment, or combinations thereof. In one example, the one or more computing devices provide cloud computing resources, including computational resources, storage resources, etc. The one or more computing devices of the service provider 102 may include one or more processors 202, memory 204, and one or more network interfaces 206. The one or more processors 202 may include a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a digital signal processor, etc.

The memory 204 may include software functions organized as one or more "modules." The term "module" is intended to represent an exemplary division of software for discussion purposes, and is not intended to represent any type of requirement or required method, manner, or organization. Thus, while various "modules" or components are discussed, their functions and/or similar functions may be arranged differently (e.g., combined into fewer modules, divided into more modules, etc.). Furthermore, while certain functions are described herein as being implemented as software modules configured to be executed by a processor, in other embodiments, any or all of the functions may be implemented in whole or in part (e.g., performed) by hardware logic components. For example, but not limited to, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), program specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like. As shown, the memory 204 can include a consensus service 207, a recommendation module 208, a content aggregation module 210, a third party service module 212, and a payment transaction module 214.

The consensus service 207 can interface with third party services and other applications running on merchants and/or user devices via API endpoints. The consensus service 207 can also be configured to interface with databases associated with third party services and merchants. In one implementation, the consensus service 207 receives information from third party services 108 and/or merchants or user devices via push/pull/or push-pull mechanisms, schedules requests in an intelligent manner, and displays orders to merchants in an integrated manner by applying various rules and filters to requests coming from different sources. The consensus service can also delegate requests to specific third party services based on heuristic or machine learning models.

The recommendation module 208 can perform processing to generate suggestions, such as delivery suggestions for delivery of an item by a delivery service associated with the service provider 102. Another type of suggestion may be a reservation suggestion indicating a reservation for a user's reservation at a restaurant, or a seating plan associated with some user reservation request. Yet another type of suggestion may be, for example, a menu update triggered from a merchant's kitchen display system and pushed to a third party service. In this case, the information 130 flows from the merchant device to the third party service, e.g., executed on the user device 104. In many cases, the service provider 102 can receive a request for a delivery suggestion via one or more application programming interfaces (APIs) 216 and, in response, generate a delivery suggestion and send the delivery suggestion to the requesting entity. The information included in a request for a delivery suggestion is described in more detail below with reference to FIG. 3. The recommendation module 208 may generate delivery suggestions based on information included in the request for delivery suggestions, the merchant's current or past order status, preparation times, and information about the third party service stored in the third party service information data store 218 or elsewhere (e.g., the third party service's current location, third party service profile information, third party data related to processed orders, order timing, order lag, etc.), information about the merchant stored in the merchant data store 220 or elsewhere (e.g., the merchant's current location, merchant profile information, etc.), information about the user (e.g., the user's current location, user profile, etc.), etc.

Third-party service profile information may include (i) delivery history information of the third-party service indicating the average time it takes the third-party service to make a delivery (e.g., average time per mile, overall average travel time, etc.); (ii) information indicating whether the third-party service is on time for delivery pickup and/or drop-off; (iii) vehicle information indicating the vehicle or type of vehicle used by the third-party service to transport items (e.g., motorcycle, car, van, truck, etc.); and (iv) historical location information indicating where the third-party service is generally located (e.g., home address, facilities where the third-party service is located for a particular period of time, etc.).

Merchant profile information includes (i) item preparation information indicating the amount of time (e.g., exact, average, estimated, etc.) to prepare an item or type of item for pickup (e.g., cook the item, manufacture the item, etc.), (ii) item information regarding the item the merchant offers for acquisition (e.g., item identifier, information regarding item cost/weight/volume/size/category, etc.), (iii) information regarding the packaging the merchant uses to transport the item (e.g., shipping box size, shape, weight, volume, etc.), etc.

Exemplary information that may be part of the shipping offer includes:
● Delivery cost of the item - the price for using the delivery service of the service provider 102 to deliver the item (e.g., a $6 fee for a third party service to pick up food from a restaurant and deliver it to a customer's location). The delivery cost may vary based on factors such as the characteristics of the item, e.g., the size, shape, weight, volume, type, etc. of the item (e.g., larger or heavier items may cost more, oddly shaped items (items having a predetermined shape) may cost more, fragile (breakable) items may cost more than non-fragile items), information about the third party service (e.g., cost may increase with distance from the third party service to the pick-up location, cost may increase as the number of available third party services decreases), information about the preparation time of the item by the merchant (e.g., cost may increase (or decrease) as preparation time decreases (or increases)), location of pick-up (e.g., cost may increase as the distance from a particular point to the pick-up location increases), location of drop-off (e.g., cost may increase as the distance from a particular point to the drop-off location increases), time of day (e.g., cost may increase during peak delivery times such as the evening).
● The amount of time for delivery of the item (e.g., an estimated amount of time - delivery takes 20-30 minutes). The amount of time may generally be the time for the third party service to obtain the item and transport the item to a drop-off location. However, in some examples, the amount of time may include the time for the item to be prepared by the merchant (e.g., the amount of time may include the total time from ordering the item to it arriving at the customer's location). The amount of time for delivery may vary based on factors such as the characteristics of the item, e.g., the size, shape, weight, volume, type, etc. of the item (e.g., larger or heavier items may take more time to deliver, oddly shaped items (items having a certain shape may take more time to deliver, fragile (fragile) items may take more time than non-fragile items), information about the third party service (e.g., the amount of time for delivery may increase as the distance from the third party service to the pick-up location increases, the amount of time for delivery may increase as the number of available third party services decreases, etc.), time of day (e.g., the amount of time may increase during peak travel times such as during rush hour).
● A pick-up time for delivery of the item (e.g., an estimated date, time, week, month, year, etc. that the third party service will pick up the item). The pick-up time may be when the item is picked up from the merchant's location for delivery to the customer. In some cases, the pick-up time is a time window (e.g., 2-2:30 PM). Additionally, in some cases, the delivery offer may include a deadline as to the latest time the third party service will pick up the item. The pick-up time may vary based on factors such as information about the third party service (e.g., the pick-up time may move further away as the distance from the third party service to the pick-up location increases, the pick-up time moves further away as the number of available third party services decreases, etc.), the time of day (e.g., the pick-up time moves further away during peak delivery times such as rush hour, etc.).
● A drop-off time for delivery of the item (e.g., an estimated date, week, month, year, etc. that the third party service will drop off the item). The drop-off time may be when the item is dropped off at the customer's location. In some cases, the drop-off time is a time window (e.g., 3-4 PM). The drop-off time may vary based on factors such as the characteristics of the item, e.g., the size, shape, weight, volume, type of item, etc. (e.g., larger or heavier items may take more time to deliver, oddly shaped items (items having a certain shape) may take more time to deliver, fragile (fragile) items may take more time than non-fragile items), information about the third party service (e.g., the drop-off time may move further away as the distance from the third party service to the pickup location increases, the drop-off time may move further away as the number of available third party services decreases), time of day (e.g., the drop-off time moves further away during peak delivery times, such as during rush hour).
When a shipping offer expires: In some cases, a shipping offer may expire if it is not accepted by a particular time (e.g., time of day, day of the week, month, year, etc.). Thus, a shipping offer may be associated with an expiration time (e.g., tomorrow at 2pm, 2 hours from receipt of the shipping offer, etc.).
• Third party services that can fulfil your order if, for example, the third party service through which the order is placed is not possible due to delivery personnel or other technical difficulties.
- Sequencing of items for kitchen display systems. Items are sequenced either by order ID or item preparation time to allow a merchant to maintain a single tablet for orders from different sources.
● Preparation or delivery timelines for the kitchen display system to show order updates to third party services.

The content aggregation module 210 can provide analytical information based on aggregated data, such as menu updates, delivery information regarding the progress of a delivery, and reservation lists. For example, the content aggregation module 210 can receive a request for a delivery status update via one or more APIs 216 and, in response, generate information regarding the delivery status and transmit the information to the requesting entity. In other examples, such information regarding the status of a delivery can be generated and transmitted automatically and/or upon the occurrence of another event. The content aggregation module 210 can generate information regarding the status of a delivery based on various information, such as the location of the third party service, an indication from the third party service regarding confirmation of pick-up of the item at the merchant's location and/or drop-off at the customer's location, a communication from the merchant indicating confirmation of pick-up, a communication from the merchant regarding the status of preparing the item (e.g., the amount of time left to cook a dish), and the like. Thus, the content aggregation module 210 may communicate with the third party service module 212 to receive location information regarding the delivery person.

The third party service module 212 can manage third party services. For example, the third party service module 212 can track the location of a courier associated with the third party service (before, during, and/or after delivery), select a third party service for delivery, communicate with the third party service to facilitate delivery, provide updates on delivery status, predict travel times for the third party service to various delivery locations at various times and/or days of the week, etc. To do so, the third party service module 212 can analyze various information, such as information included in a request for a delivery offer, information included in a request for a delivery status update, information about the third party service stored in the third party service information data store 218 or elsewhere (e.g., the third party service's current location, third party service profile information, etc.), information about the merchant stored in the merchant data store 220 or elsewhere (e.g., the merchant's current location, merchant profile information, etc.), information about the buyer (e.g., the buyer's current location, user profile, etc.), etc. In some examples, the third party service module 212 can manage the third party services through activation, movement, positioning, and/or deactivation, for example, through an API.

As an example, the third party service module 212 can select a third party service to facilitate its courier to transport the items from the merchant to the buyer. In some cases, the third party service is selected in response to receiving an acceptance of the delivery offer via one or more APIs 216. In other examples, the delivery is arranged in response to the occurrence of other events. The third party service module 212 can use various information to select the third party service, such as the location of the third party service relative to the merchant's location (e.g., selecting the third party service closest to the pick-up location), the availability of the third party service (e.g., selecting an available third party service), the type of vehicle used by the third party service to transport the items (e.g., selecting a third party service that can transport the type of item being delivered), information about the item being delivered (e.g., size, shape, volume, type, etc.), etc. The third party service module 212 can then communicate with the selected third party service to arrange the delivery. The service provider 102 can provide information regarding the number of items to be transported, the location of the merchant (or multiple merchants if multiple items are being delivered), the requested pick-up and/or drop-off time, etc. If it is determined that multiple moves are required for delivery (e.g., due to the number of items being delivered, the size of the items being delivered, the transport capabilities (capacity) of the third party service, etc.), the third party service module 212 can notify the third party service of the multiple moves and/or send instructions to the third party service to make the delivery. Additionally, the third party service module 212 notifies the third party service of deliveries that are not urgent and may be performed during a downtime period in which less than a threshold number of deliveries are scheduled for the third party service. The third party service module 212 can notify the third party service of a time period (e.g., "Perform delivery between 8:00 PM and 10:00 PM any time this week") or the third party service can make the delivery as it is available throughout the day, week, etc. Often, the third party service module 212 communicates with the third party service through a non-API channel and/or a separate channel than the one or more APIs 216 used to expose the delivery service to the entity.

The payment transaction module 214 can facilitate payment transactions between merchants, users, and/or third party services. For example, the transaction module 214 can receive orders for a transaction, process the transaction, generate and/or store transaction information for the transaction, etc. During a transaction, a user (e.g., a customer) can acquire an item from a merchant by purchasing, renting, leasing, borrowing, licensing, etc. An item can refer to goods and/or services provided by a merchant. When paying for a transaction, a user can provide a payment amount to be paid to the merchant. In some cases, a transaction may be processed by electronically transferring funds from a financial account associated with the user to a financial account associated with the merchant. In some examples, the transaction module 214 can be implemented by one or more computing devices configured to perform secure electronic financial transactions.

The payment transaction module 214 can facilitate payment transactions initiated through various channels. As one example, a user can interact with a user device to place an order with a merchant. Here, the service provider 102 can communicate with the merchant to fulfill the order (e.g., notifying the merchant that an order has been placed and requesting the merchant to fulfill the order, etc.). As another example, a merchant can interact with a merchant device to place an order on behalf of a user. Here, the user can communicate with the merchant via phone, in person, notification (e.g., text message, email, social media, etc.) to indicate a desire to place an order with the merchant. In any of these examples, the user can provide payment at any time, such as when placing the order, while the item is being delivered, at drop-off (e.g., interacting with a third-party service device), etc.

A user may provide payment via a variety of methods, such as cash, check, payment card, Near Field Communication (NFC), Bluetooth, account, electronic payment, etc. In some examples, the payment transaction module 214 enables cardless payment for a transaction between a user and a merchant based on the user's interaction with a user device and the merchant's interaction with a merchant device. Thus, in some examples, a cardless payment transaction may include a transaction conducted at a POS location during which the user's electronic payment account is charged without the user having to physically present a payment card to the merchant at the POS location. As a result, the merchant does not have to receive details regarding the user's financial account for the transaction to be processed. As an example, the electronic payment may be charged to a credit card issuer or credit card number provided by the user when signing up with the service provider 102 for an electronic payment account. As another example, the user may have an amount pre-paid in an account maintained for use in making electronic payments. Other variations will be apparent to those skilled in the art.

In some cases, the payment transaction module 214 can store transaction information in the transaction information data store 222. The transaction information may be received from a merchant device, a buyer device, a third party service device, and/or generated by the service provider 102. The transaction information can include additional information such as information regarding the time, location, and/or amount of the transaction, information related to the item acquired (e.g., information identifying the item sold), the type of payment being used (e.g., cash, check, payment card, electronic payment, etc.), and buyer information. For example, if a payment card is used, the transaction information can include data stored on the payment card (e.g., track 1 data (cardholder name, card number, and other card information)). Additionally, when completing a transaction, the buyer can provide a receipt email address for receiving a receipt, sometimes via email. Other examples of transaction information that may be captured include item information (e.g., an itemized list of items being retrieved, the price being paid for each item, item descriptions (size, flavor, color, etc.)), geographic location data indicating the geographic Point of Sale (POS) location of a particular transaction, online/offline card data, data describing the merchant (e.g., merchant identifier, merchant category code (MCC), etc.), information included in a request for a shipping offer, information included in a shipping offer, any type of data received upon authentication to a buyer's social network, and/or various other types of information. In some examples, the transaction information may be used to store information about a merchant in the merchant data store 220 (e.g., the cost of an item offered by a merchant may be obtained from transaction information relating to a transaction at the merchant's facility).

2 depicts the components and data of the service provider 102 as residing in a single location, these components and data may alternatively be distributed in any manner across different computing devices and/or different locations. As a result, functionality may be realized by one or more computing devices, and the various functions described may be distributed in various ways across the various computing devices. Multiple computing devices may be located together or separately and organized, for example, as virtual servers, server banks, and/or server farms. The functions described may be provided by the servers of a single entity or company, or may be provided by the servers and/or services of multiple different buyers or companies.

FIG. 3 illustrates exemplary details of a merchant device 300. For example, the merchant device 300 may be used by the merchant 106 of FIG. 1. The merchant device 300 may be implemented as a laptop computer, a desktop computer, a server, a smart phone, an electronic reader device, a mobile handset, a personal digital assistant (PDA), a portable navigation device, a portable gaming device, a tablet computer, a wearable computer (e.g., a smart watch, an optical head mounted display (OHMD), etc.), a portable media player, a television, a set-top box, a computer system in an automobile, an appliance, a camera, a robot, a hologram system, a security system, a home-based computer system (e.g., an intercom system, a home media system, etc.), a projector, an automated teller machine (ATM), etc. In some implementations, the merchant device 300 may perform third party services, such as delivery services, reservation services, menu services, review services, etc. The merchant device 300 may interface with third party services and other services via one or more consensus services 207 in one embodiment. In one example, a service provider may provide an API endpoint for communicating with a third party service and a merchant device 300, which may or may not provide an API endpoint 114 for the service provider to access. Thus, the service provider's consensus service 207 may be able to pull, push, or push and pull data from an external service.

The merchant device 300 may also be associated with additional devices to manage incoming orders, reservations, appointments, notifications, updates, alerts, and the like. For example, the merchant device 300 may be associated with one or more tablets connected to or including a kitchen display system. Typically, a kitchen display system is configured to display incoming orders from various third party services on its own tablets. However, using the implementations described herein, the tablets may be integrated into one such that all orders, regardless of source, are synchronized and structured to be presented and handled on a single tablet. Similarly, for reservations, the merchant device 300 may be associated with an on-site reservation system that tracks the physical space for occupancy/availability.

The merchant device 300 may include one or more processors 302, memory 304, one or more network interfaces 306, and one or more displays 308. The one or more processors 302 may include a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a digital signal processor, or the like. The one or more displays 308 may include a touch screen, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED display, a plasma display, an electronic paper display, or any other type of technology. Although not shown, the merchant device 300 may include or be associated with other components such as a camera, a microphone, a speaker, a projector, a printer, and/or sensors. The one or more cameras may include a front-facing camera and/or a rear-facing camera. The one or more sensors may include an accelerometer, a compass, a gyroscope, a magnetometer, a global positioning system (GPS), an olfactory sensor (e.g., for smell), or another sensor. The merchant device 300 may further include or be associated with a keyboard, a mouse, a pen, a voice input device, a touch input device. The memory 304 may include a merchant module 310 and a location module 312.

The merchant module 310 (and/or location module 312) may represent merchant-facing components that may be used by a merchant generally. In some examples, a customer may interact with the merchant-facing components (e.g., to verify payment, provide delivery information, or provide other input). The merchant module 310 may perform various processes to assist the merchant in facilitating transactions with customers, managing deliveries, managing inventory, etc. The merchant module 310 may provide various interfaces and/or dashboards. In some cases, the merchant module 310 may be referred to as an application, such as an application for delivery orders, pre-orders, and retrieval applications for menu updates/preferences.

The merchant module 310 may communicate with the service provider 102 to use delivery services provided by the service provider 102. As an example, a merchant may interact with an item acquisition interface (e.g., item acquisition interface 120) provided by the merchant module 310 to place an order for a customer. If the merchant module 310 determines that delivery may be requested (e.g., an automatic determination based on a customer indicating that the order would like to be delivered, etc.), the merchant module 310 may generate a request for delivery suggestions and send a request to the service provider 102 via one or more APIs to request information regarding the use of delivery services recommended by the service provider 102. The information in the request may be provided by the customer or merchant or obtained from a data source (e.g., a user profile, a merchant profile, etc.). Exemplary information that may be part of the request for delivery suggestions includes the following:
● Item Pickup Location - the location where an item is obtained from the merchant for delivery to the customer. The pickup location may generally be the merchant's location (e.g., a facility), although any location may be used, such as a warehouse, residence, PO box, street corner, etc. The pickup location may be stationary or mobile (e.g., in the case of a mobile merchant).
● Drop-off location (also called delivery location) - the location where the item is delivered to the customer. A drop-off location can generally be the customer's location, such as a residence, a PO box, a street corner, a facility where the customer is currently located, etc. A drop-off location can be stationary or mobile (e.g., for mobile customers).
● Requested pickup time - the hour, week, month, year, etc., for obtaining the item from the merchant for delivery. The requested time of pickup may be a specific time, a window of time, etc. In some cases, the requested pickup time may be as early as possible (e.g., if the item has already been created, or in other circumstances). If no pickup time is specified in the request for a delivery offer, the service provider 102 may, for example, assume that the pickup time is as early as possible.
● Quantity (number) of items acquired—the amount of items purchased from the merchant. In some cases, the service provider 102 can use this information to determine the size of the order (e.g., the amount of space required to transport the order).
An item identifier that identifies the item being retrieved. In some cases, the service provider 102 can use this information to look up information about the item to determine how much space is needed to transport the order, the type of vehicle needed to transport the item, the type of item (e.g., fragile vs. non-fragile, perishable vs. non-perishable, etc.), etc.
Characteristics of the item being captured (e.g., size, shape, weight, volume, type, category, etc.) In some cases, this information can be used by the service provider 102 to determine the amount of space required to transport the item.
Tags associated with the items being retrieved (e.g., tags indicating a particular category). For example, items may be tagged with a predefined label associated with a category of food that requires special handling for delivery (e.g., pizza or soup that needs to be kept warm and/or upright, catered meals such as food on a tray that requires special handling, televisions that need to be handled with care, etc.). In some examples, the service provider 102 can use this information to determine how much space is needed to transport the order, the type of vehicle needed to transport the items, the type of item (e.g., fragile vs. non-fragile, perishable vs. non-perishable, etc.), etc.
● The price of the order (e.g. cost of an item or order).
- Pick-up instructions for the item. For example, a merchant may specify that a bike will be picked up for delivery at the rear of the store.
● Delivery instructions for the item. For example, a customer may request that an item be delivered during a particular time window, at a particular spot on the customer's property, in a particular type of vehicle, by a particular third party service, etc.
Customer contact information (e.g., phone number, email address, geographic location of the customer, etc.) As an example, customer contact information may include the customer's address.

Although the merchant module 310 is described as providing the information included in the request for delivery offers, in some cases the information may be determined (at least in part) at the service provider 102 (e.g., the service provider 102 may receive an item identifier, look up item size, quantity, etc.).

After submitting a request for a shipping proposal to the service provider 102, the merchant module 310 can receive the shipping proposal from the service provider 102. In some cases, information from the shipping proposal is communicated to the customer. For example, the merchant can inform the customer of the shipping cost, the estimated delivery time, and/or any other information. In other examples, the information from the shipping proposal may not be presented to the customer. For example, the merchant can view the shipping proposal information and/or include the cost in the total cost of the order. Thus, in some cases, it may appear to the customer that the shipping is being handled by the merchant. In any case, the merchant module 310 can send an indication of acceptance or rejection of the shipping proposal to the service provider 102 via one or more APIs.

The merchant module 310 can then communicate with the service provider 102 via one or more APIs to provide and/or receive information regarding the status of the transaction. For example, the merchant module 310 can send information indicating where the item is in the preparation process (e.g., nearly done, done, in the oven, bagged, ready for pickup, etc.). In another example, the merchant module 310 can receive information from the service provider regarding the status of a delivery by a delivery service (e.g., the specific location of a courier for the third party service, how far away the third party service is, whether the item has been dropped off, whether a courier associated with the third party service is in transit to a pick-up location, etc.).

The merchant module 310 may receive orders through various channels. For example, the merchant module 310 may receive a first order placed by the merchant on behalf of a customer based on a telephone conversation between the merchant and the customer, and a second order placed by another customer on a customer application. The second order may be received from another party, such as the service provider 102 and/or a service provider associated with the merchant. In either case, the orders may be managed by the same merchant module 310 through the service provider's API. That is, the merchant module 310 may monitor the preparation of the order, present information regarding the progress of the preparation of the order, present information regarding the delivery status of the order, etc. Often, information regarding the order is presented through an interface with information designating the order as originating from a different channel.

The merchant module 310 can apply one or more schemes to provide payment for the delivery services used by the service provider 102. As an example, the delivery costs for using the delivery services of the service provider 102 may be charged to the customer (e.g., directly per item, per month, etc.). As another example, the merchant may decide to provide payment for the delivery costs (e.g., not charge the customer) in each case or when one or more criteria are met, such as, for example, an order with more than a threshold number of items, an order with a quantity above a threshold amount, the customer is associated with a certain status (e.g., the customer has paid a monthly subscription fee for the delivery service or has purchased a certain number of items over time), etc.

The merchant can be billed by the service provider 102 for the use of the consensus service connecting several delivery services in various ways, such as monthly, per item, etc., and balances the amount due to the merchant by the service provider 102 (e.g., deducting the cost of the delivery service from the amount due to the service provider 102 to the merchant).

The merchant module 310 may additionally or alternatively perform other processing. In one example, the merchant module 310 may facilitate transactions with customers by accepting payments from customers (e.g., via a card reader, an NFC connection to the customer device, a Bluetooth connection to the customer device, etc.), providing receipts for items (including printing receipts), receiving input from customers for items acquired by the customer (e.g., confirmations, credit card signatures, etc.), and the like. In another example, the merchant module 310 may enable a merchant to manage inventory by notifying the merchant of inventory levels (e.g., the number of items currently in stock), ordering additional inventory, viewing notifications from the service provider 102 regarding inventory, offering inventory to others for acquisition, seeking financing for inventory, and the like. In yet another example, the merchant module 310 may provide data analytics for sales, inventory, or other information.

Although the functionality of the merchant module 310 is described as being contained in a single component, the functionality may be divided into any number of components. In some cases, the functionality may be divided into separate applications that are linked together (e.g., accessing one application by selecting a link in another application).

The location module 312 can determine the location of the merchant device 300. In some cases, the location is provided to the service provider 102 or used locally to facilitate various functions, such as determining the location of the merchant, processing transactions when a customer is located within a particular vicinity of the merchant device 300, etc. The location module 312 can determine the geographic location of the merchant device 300 from geo-positioning technology (e.g., satellite-based systems - Global Positioning System (GPS)), cell tower location data, wireless access point location data, radio beacon location, etc.). Thus, the location module 312 can utilize data from a location sensor of the merchant device 300, such as a GPS receiver or communication interface, that can determine the geographic location of the merchant device 300 (e.g., from a cell tower or wireless access point).

In some types of businesses, the merchant device 300 may be associated with the merchant's store or other business location and thus may be a fixed location that does not typically change from day to day. However, in other types of businesses, the merchant device 300 may move location from time to time, such as when the merchant operates a food truck, is a street vendor, cab driver, etc., or otherwise has a mobile business (e.g., in the case of a merchant who sells items at a buyer's home, business location, etc.).

FIG. 4 illustrates exemplary details of a user device 400. For example, the user device 400 may be used by the user 104 of FIG. 1. The user device 400 may be implemented as a laptop computer, a desktop computer, a server, a smart phone, an electronic reader device, a mobile handset, a personal digital assistant (PDA), a portable navigation device, a portable gaming device, a tablet computer, a wearable computer (e.g., a smart watch, an optical head mounted display (OHMD), etc.), a portable media player, a television, a set-top box, a computer system in an automobile, an appliance, a camera, a robot, a hologram system, a security system, a home-based computer system (e.g., an intercom system, a home media system, etc.), a projector, an automated teller machine (ATM), etc. In some examples, the merchant device 300 may be a mobile device. In one implementation, the user device 400 may perform third party services, such as a delivery service, a reservation service, a menu service, a review service, etc. In one embodiment, the user device 400 may interface with a merchant service, such as the merchant device 300, via one or more consensus services 207. In one example, the service provider provides an API endpoint 114 for communicating with the third party service and the merchant device 300, which may or may not provide an API endpoint for the service provider to access. Thus, the service provider's consensus service 207 may be able to pull, push, or push and pull data from the user device. The third party service may be hosted on a third party server, e.g., as well as the service provider.

The user device 400 may include one or more processors 402, memory 404, one or more network interfaces 406, and one or more displays 408. The one or more processors 402 may include a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a digital signal processor, or the like. The one or more displays 408 may include a touch screen, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED display, a plasma display, an electronic paper display, or any other type of technology. Although not shown, the user device 400 may also include or be associated with other components such as a camera, a microphone, a speaker, a projector, a printer, and/or a sensor. The one or more cameras may include a front camera and/or a rear camera. The one or more sensors may include an accelerometer, a compass, a gyroscope, a magnetometer, a global positioning system (GPS), an olfactory sensor (e.g., for smell), or another sensor. The user device 400 may further include or be associated with a keyboard, a mouse, a pen, a voice input device, a touch input device. The memory 404 may include a customer module 410 and a location module 412.

The customer module 410 (and/or location module 412) may represent customer-facing components that may be used by a customer generally. In some examples, a merchant may interact with the customer-facing components (e.g., to verify a payment, provide delivery information, or provide other input). The customer module 410 may perform various processes to assist the customer in facilitating a transaction with the merchant. In doing so, the customer module 410 may provide various interfaces and/or dashboards. In some examples, the customer module 410 may be referred to as an application, such as an item acquisition application. Additionally, in some examples, the customer module 410 may comprise a local application that works in conjunction with a service provider associated with the merchant, such as a third party application 407, such as a delivery service, to order a pizza from a pizza merchant.

The customer module 410 can communicate with the service provider 102 to use a delivery service associated with the service provider 102. As an example, a customer can interact with an item acquisition interface (e.g., item acquisition interface 120) provided by the customer module 410 to place an order with a merchant. If the customer module 410 determines that delivery may be requested (e.g., automatically based on a user profile setting or previous purchases, based on customer input indicating a desire to have the order delivered, etc.), the customer module 410 can generate a request for a delivery offer and send a request to the service provider 102 via one or more APIs to request information regarding the use of the delivery service provided by the service provider 102. The information in the request may be provided by the customer or may be obtained from a data source (e.g., a user profile, etc.). In many cases, the customer module 410 provides the information included in the request for delivery offers, but in some cases, the information may be determined (at least in part) at the service provider 102 (e.g., the service provider 102 may receive an item identifier and review item size/volume, the service provider 102 may identify the customer and review customer preferences, etc.).

After submitting a request for a shipping proposal to the service provider 102, the customer module 410 can receive the shipping proposal from the service provider 102. In some cases, information from the shipping proposal is communicated to the customer. For example, the item retrieval interface can display the shipping cost, the estimated delivery time, and/or any other information. In other examples, information from the shipping proposal may not be presented to the customer. For example, the item retrieval interface can include the shipping cost in the total cost of the order, rather than displaying the shipping cost as an itemized element. Thus, in some cases, it may appear to the customer that the shipping is being handled by the merchant. In any case, the customer module 410 can send an indication of acceptance or rejection of the shipping proposal to the service provider 102 via one or more APIs.

The customer module 410 may also communicate with the service provider 102 via one or more APIs to request and/or receive information regarding the status of a transaction. For example, the customer module 410 may receive information regarding the status of an item's preparation (e.g., nearly done, done, in the oven, bagged, ready for pickup, etc.), the status of delivery by a delivery service (e.g., the specific location of the courier, how far away the courier is, whether the item has been dropped off, whether the courier is in transit to a pick-up location, etc.), and the like. Such information may be presented to the customer. In one example, a map is displayed to the customer along with an icon or other element indicating the location of the courier. Additionally or alternatively, advertisements may be displayed. By way of example, the customer module 410 may display advertisements for online sites related to delivering items for the merchant. The advertisements may encourage the customer to use the online site to place future orders instead of ordering directly from the merchant. In other illustrations, any type of advertisement may be displayed.

The customer module 410 may additionally or alternatively perform other processing. As an example, the customer module 410 may provide the user with information about merchants within a given proximity range via an interface. The user may select a merchant and order an item with the merchant. Additionally or alternatively, the customer module 410 may enable the user to provide payment for items (e.g., via a card reader, an NFC connection to the merchant device, a Bluetooth connection to the merchant device, etc.), receive receipts for items, etc. Furthermore, the customer module 410 may enable the user to check in with a merchant to perform a cardless payment transaction.

The location module 412 can determine the location of the user device 400. In some examples, the location is provided to the service provider 102 or used locally to facilitate various functions, such as processing transactions when a customer is located within a particular vicinity of the merchant device. The location module 412 can determine the geographic location of the user device 400 from geographic positioning technologies (e.g., satellite-based systems--Global Positioning System (GPS)), cell tower location data, wireless access point location data, radio beacon location, etc.). Thus, the location module 412 can utilize data from a location sensor of the user device 400, such as a GPS receiver or communication interface, that can determine the geographic location of the user device 400 (e.g., from a cell tower or wireless access point).

In some implementations, the user device 400 is also configured to receive reservation suggestions in response to a reservation request triggered via the user device 400, the merchant device 300, or automatically, for example, via the service provider. The user of the user device 400 can accept or reject the reservation suggestion. The user device 400 can also provide preferences for the type of seating the user prefers for either the current reservation or a future reservation. Preferences can also include chefs, items, merchant locations, time of day, alternative merchants, cuisine of choice, etc., so that the service provider can generate alternatives for the user, for example, if the preferred reservation is not available or conflicts with another reservation from a different source.

5-7 show example processes 500, 600, and 700 for using the techniques described herein. For ease of illustration, the processes 500, 600, and 700 may be described as being performed by a computing device described herein, such as a service provider 102, a merchant device 300, a user device 400, and/or a third party service device, which may be a user device. However, the processes 500, 600, and 700 may be performed by other devices. Additionally, the devices may be used to perform other processes.

Processes 500, 600, and 700 (as well as each process described herein) are illustrated as a logical flow graph, each operation of which represents a sequence of operations that may be implemented in hardware, software, or a combination thereof. In the context of software, an operation represents computer-readable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the operation. Generally, computer-readable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular abstract data type. The order in which the operations are described is not intended to be construed as limiting, and any number of the described operations can be combined in any order and/or in parallel to perform the process. Furthermore, any number of the described operations may be omitted. In some examples, the operations described in processes 500, 600, and/or 700 as being performed by a device or service provider may be performed by an application running on the device or service provider.

FIG. 5 illustrates an example process 500 for exposing one or more APIs to enable an entity to use a third-party service that is related to other services provided by the service provider 102.

At 502, the service provider 102 can expose one or more APIs to provide computing devices with access to delivery resources of a delivery service that interfaces with the consensus service 207 of the service provider 102. For example, the service provider 102 can expose one or more APIs to computing devices associated with merchants and/or customers to facilitate delivery of items offered by the merchants through multiple delivery platforms.

At 504, the service provider 102 may receive a request for delivery of an item via one or more APIs. The request may be received from a computing device associated with the merchant or customer. The request may indicate a location of delivery, a location of pickup, a requested time of pickup, a number of items to be retrieved, a size of the items, whether the items are associated with a given category, the weight of the items, etc. In some cases, the request is received from an application executable on a computing device associated with the merchant or customer. The request may be for delivery of any type of item. In one example, the item may be a computing device (e.g., a tablet, etc.) configured with a merchant application (e.g., a proprietary merchant application that may not be available to the general public) that facilitates the retrieval of the item with the customer. Here, the request may ask the merchant to deliver the item in order to onboard (e.g., register) the merchant with the service provider to use purchasing resources provided by the service provider. The purchasing resources may be used when the merchant interacts with the delivered computing device. In other examples, the item may be other types of items.

At 506, the service provider 102 may generate a delivery proposal for delivery of the item or scheduling of the order if multiple orders are received from multiple third party services. The delivery proposal may include a cost for delivery of the item by a delivery service associated with the service provider 102, an estimated amount of time for delivery of the item by the delivery service, an estimated pick-up time for delivery of the item, an estimated drop-off time for delivery of the item, etc. In some cases, the service provider 102 may determine the cost of delivery of the item (or any other information in the delivery proposal) based on the current location of the third party service, the pick-up location of the item, the drop-off location of the item, an estimated preparation time of the item by the merchant associated with the item, etc. The delivery proposal may also include a series of orders for the kitchen display system so that the merchant can adjust order preparation accordingly.

At 508, the service provider 102 may send the delivery offer to a computing device, such as a computing device associated with a merchant or user.

At 510, the service provider 102 can receive an indication of acceptance or rejection of the delivery offer via one or more APIs. The indication of acceptance or rejection can be received from a computing device associated with the merchant or user.

At 512, the service provider 102 can receive the courier location information from the third-party service device. The location information can be received at any time, such as through an API different from the API used to communicate with the merchant or customer, through a non-API channel, etc. The location information can identify the current location of the third-party service device.

At 514, the service provider 102 may identify a third party service from among several third party services to transport the item. Often, such identification may be performed in response to receiving an indication of acceptance of the delivery offer. The third party service device may be identified based on various information, such as the location of the third party service device identified in the location information.

At 516, the service provider 102 can send a communication to the third party service device to transport the item. The communication can request that the associated third party service retrieve the item from the pickup location and transport the item to a location for delivery. The communication can include various information regarding the delivery, such as information in a request for delivery offer, information in a delivery offer, etc. The communication may be sent via a different API than that used to communicate with the merchant or customer, via a non-API channel, etc. In some examples, the service provider 102 can receive an indication of acceptance from the third party service device indicating that the third party service will deliver the item.

At 518, the service provider 102 may receive location information and/or delivery information. The location information and/or delivery information may be received from a third party service device and/or a merchant device. Often, such information may be received after delivery has been initiated. The location information may generally indicate the location of the third party service. The delivery information may include, for example, input from the third party service indicating the location of the third party service, information from the third party service or merchant indicating that the item has been picked up, etc.

At 520, the service provider 102 can determine the status of the delivery of the item being delivered. The status of the delivery can be based on the location information and/or the delivery information received at 822.

At 522, the service provider 102 can transmit the delivery status to a computing device associated with the merchant or customer. The computing device can display the delivery status to the merchant or customer.

In some cases, the service provider 102 may receive an order through multiple channels, or multiple sources, such as a third-party service. If the order is received through a non-merchant channel (e.g., directly from a customer), the service provider 102 may communicate with the merchant to request that the merchant fulfill the order. If accepted by the merchant, the merchant may send an indication of acceptance, and the service provider 102 may proceed to facilitate delivery by the third-party service. Additionally, the status of a delivery may be determined for any number of deliveries in progress. In some cases, multiple statuses for multiple items with a single merchant or customer may be determined and transmitted to a merchant device or customer device.

FIG. 6 illustrates an example process 600 for coordinating actions using a consensus service with a third party service that communicates with a service provider 102 via one or more APIs and is integrated with the service provider 102. The process 600 is described in the context of being performed by an acquisition device, such as a computing device associated with a merchant or a customer.

At 602, the acquisition device can provide an interface, such as item acquisition interface 120 of FIG. 1. This includes displaying the item acquisition interface via a display. The interface may allow the user to place an order for items. The interface may also be a kitchen display system that allows the merchant to view orders, sorted by item, in the order in which they should be prepared, so that similar items may be collected to create new tickets for internal kitchen purposes, change flows for items that are no longer available, etc. The interface may also be an interface of available and unavailable reservations, showing which reservations are booked and from which source. The interface may also be an interface of items currently available at the merchant, allowing the merchant to modify the menu in real time based on availability, popularity, merchant location, etc.

At 604, the acquisition device may receive a selection of items for acquisition. For example, a user (e.g., a merchant, a customer, etc.) may place items in an electronic shopping cart to indicate intent to purchase items from a merchant. In some cases, the user may also provide other information, such as a location of delivery, a location of pickup, a requested time of pickup, the number of items to be acquired, the size of the items, whether the items are associated with a given category, the weight of the items, etc. In other examples, such information may be determined automatically. Other types of information requested may be a request for order matching, a request for order sequencing, or a request for order consensus triggered by the merchant or automatically triggered by the server.

At 606, the capture device can determine that information regarding delivery of the items is requested. This can include receiving input from a user indicating an interest in having the items delivered, identifying a distance between the customer's location and the merchant's location (e.g., determining that delivery is requested if the distance is greater than a threshold), etc. In some examples, delivery information may be automatically determined to be requested for each order.

At 608, the acquisition device can send a request to the service provider 102 via one or more APIs associated with the service provider 102 for delivery of the items. The request can request delivery suggestions. In some cases, the request can indicate a delivery location, a pickup location, a requested time of pickup, the number of items to be picked up, the size of the items, whether the items are associated with a given category, the weight of the items, etc. The delivery suggestions can also include reservation suggestions, how to distribute reservation quotas among third party services, how to distribute order acceptance or delivery among third party services, how to sequence orders received from third party services, and how to send or receive updates to orders, such as menu updates, order updates, etc.

At 610, the acquisition device can receive a delivery offer from the service provider 102. The delivery offer can indicate a cost for delivery of the item by a delivery service associated with the service provider 102, an estimated amount of time for delivery of the item, an estimated pick-up time for delivery of the item, an estimated drop-off time for delivery of the item, etc.

At 612, the acquiring device may determine whether the delivery offer is accepted or rejected. In some examples, the acquiring device may display information contained within the delivery offer (e.g., the cost for delivery of the items, the estimated amount of time for delivery of the items, etc.) and receive user input regarding acceptance of the delivery offer. In other examples, the acquiring device may automatically determine whether to accept or reject the delivery offer when one or more criteria are met. Thus, the acquiring device may, in some cases, refrain from displaying information in the delivery offer.

At 614, the acquisition device can send an indication of acceptance or rejection of the delivery offer to the service provider 102 via one or more APIs associated with the service provider 102. This allows the service provider 102 to facilitate delivery of the item. In some examples, the customer may be charged for the delivery, and in other examples, the merchant or another merchant may be charged.

At 616, the acquiring device can perform delivery status processing. For example, the acquiring device can send a request for the delivery status of the item via one or more APIs associated with the service provider 102. The acquiring device can then receive the status of the delivery of the item from the service computing device 102 and display the status of the delivery. In other examples, the status of the delivery may be determined at the merchant device (e.g., based on knowing that a third-party service has picked up the item) and the status of the delivery may be sent to the customer device.

Figure 7 shows an example process 700 for notifying third party services or merchant devices regarding item delivery, available/conflicting seat reservations, menu updates, etc.

At 702, the third party service device can determine a geographic location of the third party service device, such as a user device. The geographic location may be determined based on data from a location sensor of the third party service device, such as a satellite-based sensor (e.g., Global Positioning System (GPS), cell tower radio, wireless access point radio, radio beacon location sensor, etc.).

At 704, the third party service device can provide location information to the service computing device 102. The location information can indicate a geographic location of the third party service device. The location information may be provided periodically, at specific times, on demand, etc.

At 706, the third party service device may receive a communication from the service provider 102 regarding the delivery of the item. For example, the communication may include a request for a third party service associated with the third party service device 500 to obtain the item from a merchant and transport the item to the customer. The request may specify a time frame for the delivery (e.g., delivery time), the number of items to be delivered, the route for the delivery, the location of the merchant, or any other information that may be useful in making the delivery.

At 708, the third party service device can present a notification requesting that the item be delivered (e.g., retrieved from the merchant's facility and transported to a delivery location). The notification may be presented via a display, speaker, etc. In some cases, information is displayed via a third party service interface that facilitates delivery of the item (e.g., an interface that allows the third party service to accept the delivery, confirm that the delivery has occurred, request additional deliveries, etc.). The third party service device 500 can present any information included in the communication received at 1006.

At 710, the third party service device can receive input from the third party service and/or transmit an acceptance or rejection regarding delivery of the item. For example, if the input indicates that the third party service accepts the task of delivering the item to the customer, the third party service device 500 can transmit a communication to the service provider 102 indicating that such task has been accepted.

FIG. 8 illustrates an example process 800 for communicating via one or more APIs exposed by a service provider to provide status updates regarding an order. In FIG. 8, the elements illustrated at the bottom of FIG. 8 (below the line established by one or more service provider APIs 802) may represent operations performed by a service provider, such as service provider 102.

In the example of FIG. 8, a computing device 801 associated with a user performing multiple third-party services enables the generation or creation of orders placed with a merchant associated with the merchant device 106, and a computing device 804 associated with the third-party services implements a user interface 806 that enables the generation or creation of orders placed with a merchant associated with the merchant device 106. As shown at 810, the incoming orders or orders listed on the left side of the user interface 806 can be obtained by requesting information from a service provider. At 812, the service provider can determine the status of the orders by obtaining fulfillment information and determining the location of the third-party services assigned to each of the merchant's (Company A) orders. At 814, the service provider can generate details regarding the status and send the details to the computing device 804 for display via the left side of the user interface 1206.

A customer can generate an order or order request using a computing device 801. Thus, such an order can be triggered using a third party service 108 running on the computing device 801. A third party application, such as the third party application 108, can interface with the service provider 102 by delivering a status update endpoint, or API endpoint 819, to get details of the order 826, how the order is scheduled in the list in the order in which it was received from, the status of preparation and delivery 824, etc. The service provider can also schedule the order to be delivered by a different company than the one used for the order, for example, based on the user's proximity to a courier belonging to another delivery company.

A computing device 802 associated with the merchant is also shown. The left side of the user interface 806 may display relatively high level information of all orders (or a certain number of orders) placed with the merchant regardless of the channel through which the order is placed (e.g., telephone, customer application, website, etc.), while the right side of the user interface may display more detailed information regarding one or more selected orders. The left and right sides of the user interface 806 are separated by a line 808. The user interface 806 may be an interface for a kitchen display system where the service provider pushes notifications or updates in real time from orders received from multiple sources. The interface 806 also lists orders as they are scheduled by the service provider 102 and assists in managing orders according to user preferences, availability, and other such factors.

As shown, status information regarding the delivery of items can be obtained by communicating with a service provider via one or more service provider APIs 802. For example, as shown at 810, status information for orders listed on the left side of user interface 806 can be obtained by requesting the information from a service provider. At 812, the service provider can determine the status of the orders by obtaining fulfillment information and determining the location of third party services assigned to each of the merchant's (Company A) orders. At 814, the service provider can generate details regarding the status and send the details to the computing device 804 for display via the left side of user interface 806.

When a merchant selects a particular order on the left side of the user interface 806, such as orders 816, more detailed information specific to that order may be displayed on the right side of the user interface 806. In particular, as shown at 818, the computing device 804 may request additional status information regarding the selected order 816. At 820, the service provider may determine the status of the selected order by retrieving historical information and determining the location of a third party service assigned to the selected order. At 822, the service provider may generate details regarding the status and send the details to the computing device 804 for display via the right side of the user interface 1206. In some cases, the details displayed on the right side may be more specific than the details displayed on the left side. In this manner, the merchant has more visibility into the status information of orders placed through various types of channels.

In some examples, box 810 represents an API for obtaining status information regarding all orders (or a particular number of orders) of a merchant currently being delivered by the service provider's delivery service, while box 818 may represent an API for obtaining status information for a particular order of a merchant currently being delivered by the service provider's delivery service.

In some examples, the present application discloses a system for providing optimized order scheduling, the system including one or more processors and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions including receiving, by an order scheduling application executing on a point of sale device associated with a merchant, a first order from a first customer-facing ordering application, the first order including one or more menu items to be prepared by the merchant for delivery to an address provided by the first customer-facing ordering application; transmitting, by a first delivery application, to a computing device of the merchant, an estimated pick-up time indicating a time when the first delivery application estimates the arrival of a delivery person or customer to pick up the first order; and determining, based on past orders involving the first customer-facing application, when the delivery person or customer is likely to pick up the first order. The one or more processors are programmed to perform operations including: determining a predicted pickup time indicating an estimated time; receiving a second order from a second customer-facing ordering application, the second order including one or more menu items prepared by a merchant; transmitting, by the first delivery application to a computing device of the merchant, an estimated pickup time indicating a time when the second delivery application estimates the arrival of a delivery person or other customer to pick up the second order; determining a predicted pickup time indicating a time when the delivery person or customer is likely to pick up the second order based on past orders involving the second delivery application; generating, by the order scheduling application, an ordered list of orders based at least in part on the predicted pickup times of the first order and the second order; and transmitting the ordered list of orders to a kitchen display system for preparing the orders according to the ordered list.

9 illustrates an exemplary process of one example of a service provider, such as the service computing device 102 or an associated application, such as a consensus service, dynamically modifying (changing) icons 902 of a user interface, such as a user interface 904, based on contextual data. For example, menu updates can be sent to the third party service based on the third party service's relationship with the merchant, item availability or popularity, and other contextual data. The contextual data can include the location of the service computing device 900, the time, the day of the week, the time of year (e.g., season), the weather, the merchant's inventory, the merchant's preferences, the customer's preferences, items considered to be upsell items, items considered to be cross-sell items, sales and/or specials offered by the merchant, and various other contextual factors corresponding to the use of the service computing device 900. The contextual data can be generated automatically at the merchant device, via an application, or via data analysis, such as current or historical, at the server level. The contextual information can be obtained by tracking complete or incomplete order requests from the third party application, which is cart-level information.

At 906, the service computing device 900 determines first context data and displays a first icon 902(1) based on the context data. The first context data may be determined based on an analysis of one or more factors corresponding to a use of the service computing device 900. In an exemplary example, the analysis may include a determination that a time of day corresponds to a breakfast menu. Based on this determination, the service computing device 900 may display a first setting of the icon 902(1) corresponding to the meal menu. In some examples, the analysis may include an analysis of customer preferences and a determination that the customer prefers a particular menu item, such as a breakfast menu.

In various examples, the analysis may include a determination to highlight one or more items. The highlighting may be presented by increasing the size, shape, color, and/or hue of the icon 902, by changing the placement of the icon 902, or by other adjustments to make the icon 902 stand out on the display. The highlighting may be based on the merchant's inventory, the current weather, attempts to upsell the item, attempts to cross-sell the item, sales and/or specials offered by the merchant, the merchant's transaction history (e.g., known popular items sold at a time, days of the week, times of the year (e.g., seasons), known popular combinations of items sold, etc.).

[3] In some examples, the analysis may include a determination to de-highlight one or more items. De-highlighting of the items may be based on the merchant's inventory, current weather, cross-selling attempts, and/or other factors that may discourage the merchant from selling a particular item. The de-highlighting may be presented by removing the icon 902 corresponding to the one or more items from the display page. In various examples, the user interface 904 may include multiple display pages. In some examples, the de-highlighting may be presented by including an icon corresponding to the one or more items on a display page other than the main display page. For example, the de-highlighting may include presenting the icon on a last page of the multiple display pages.

In various examples, the service computing device 900 can dynamically determine to highlight and/or de-highlight one or more items based on contextual factors. For example, if a customer orders a final muffin, the service computing device 900 can dynamically modify the user interface 904 by removing the muffin icon from the user interface and replacing it with a pastry icon.

At 908, the service computing device 900 determines second context data and displays a second icon 902(2) based on the context data. In various examples, the second context data may include a change in time of day from a time corresponding to a morning menu to a time corresponding to a lunch menu. In some examples, the second context data may include a determination of an event proximate to the merchant's location or displayed on a screen at the merchant's location that may affect the menu items most likely to be ordered by the customer. In such examples, the service computing device 900 may dynamically modify the icon 902(1) to a second setting of the icon 902(2) to accommodate a customer's preference or an external environment (e.g., hot/cold beverage items are recommended on a cold/hot day). For example, a merchant may normally adjust from a breakfast to a lunch menu at 11:00 a.m. However, the service computing device 900 may determine that a football game starts at 10:00 a.m. and that during the football game, customers prefer to consume items on the lunch menu. Thus, the service computing device 900 may adjust one or more of the icons 902 to those corresponding to lunch menu items.

In some examples, the service computing device 900 may determine that an event is occurring near a merchant or will be presented on a display screen at the merchant location, and may generate one or more sales and/or special offers (e.g., discounts, etc.) based on the event. In such examples, the service computing device 900 may highlight icons 902 corresponding to one or more special offers. For example, a merchant may be offering hamburgers and alcoholic beverages on special during an event. Thus, the service computing device 900 may modify the icons corresponding to the hamburgers and alcoholic beverages to make them more prominent. Additionally or alternatively, the service computing device may display a notification 910 that a particular item is offered at a discounted price to further encourage a purchase.

Alternatively or additionally, a first interface with icon 902(1) can correspond to a first third party service and a second interface with icon 902(2) can correspond to a second third party service, with the merchant sending different updates to the menu interface. In another embodiment, the interface for both one third party service and another third party service is the same, meaning that the same content is presented to the third party service. The contextual information underlying the menus may be tied to customer actions in the menus associated with the third party services (i.e., a menu for service A for a merchant may be organized differently than a menu for service B for the same merchant). The API of the payment service can be used to collect customer interactions/behaviors (menu scroll activity, navigation preferences, order history, etc.) within its third party service application. Looking at order history, the payment service can use that information to reorganize the menus, for example, if the payment service or API determines that service A customers typically order appetizers and service B customers tend to order desserts from a particular merchant. Thus, in one embodiment, the payment service can push up content/menu updates to all third-party ordering applications based on, for example, the ordering activity that the consensus service tracks during a particular time period (e.g., based on the query, "are customers from most of the third-party applications currently ordering steaks?"). Additionally or alternatively, the payment service can also push out content updates that reorganize menu layouts to generate unique menus that are customized for each third-party application based on what the consensus service learns about customer ordering behavior. Thus, the consensus service collects, analyzes, compares, and learns from current and historical data that the delivery service does not have access to. Additionally, the consensus service allows separate services that would not otherwise communicate to communicate through an indirect channel created by the consensus service. While the description describes an API as one form of channel, it should be understood that the description can be extended to cover other forms of channels between services, either directly or through an intermediary service such as a payment service.

In some implementations, a server system for providing optimized content management includes one or more processors and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions performing processing steps including receiving a content structure for a first service application and a second service application, the content structure including, for example, how menus are laid out or items are priced; receiving, by a content management application executing on a point of sale device associated with the merchant, a first content update or review for the first merchant application, the content update including new menu items, deleted menu items, the first content update including updates made to content such as menus for the first service application; sending the content update to the first service application; and sending a content update similar to the content update of the first service application to the second service application.

Alternatively, the service provider may generate, via a content management application, a structured structure of content based on the service application and the merchant. For example, a first menu with a particular ordering and pricing of items for a first service application, and a second menu with a different ordering and pricing of items for a second service application. Furthermore, different items may be offered at different locations and service applications.

Figure 10 is an example interface 1000 of a reservation on the consensus service 132 at a service provider 102 or merchant device 1008 running the consensus service. As shown, reservations can be managed in real time and are received from multiple sources such as reservation services such as Yelp (Copyright), OpenTable (Copyright), Resy (Copyright), etc.

In some implementations, the service provider 102 allocates the received reservations for the merchant device 1002, which is configured to receive reservations from multiple reservation applications, including a first reservation application 1004-1 and a second reservation application 1004-2, via an API (not shown). The API may be used to facilitate a payment service, for example, as an aggregator that aggregates data from the various reservation applications, and these third-party applications send reservation information to the merchant using the exposed API. For example, a consensus service can collect data and order reservations accordingly. The consensus service can also leverage historical reservation information, where the service learns about each reservation application and allocates a portion of the seats based on what the service has learned, for example, via machine learning models. For example, the payment service can allocate seats based on factors such as frequency of cancellations, average arrival time for customers using that application, order size, etc. The service provider 102 receives multiple reservations and runs a consensus service 132 to process the incoming reservations and schedule them for merchants based on customer and/or merchant profiles stored in the database 1006. The database 1006 stores customer and merchant preferences and indicates how reservations can be configured to best match those preferences. For example, the consensus service 132 can move reservation 1004-3 from 6:30 to 7 PM, depending on availability or past reservations made by the customer. Similarly, reservation 1004-4 can be assigned to 8 PM, depending on availability of specific seats or items. For example, some restaurants maintain rotating menus, and as such, the service provider may be provided with access to the user's dining preferences, with the user's consent. Thus, the reservation can be moved to a more preferred spot without user or merchant intervention. The present application relates to a method for providing a method for booking a restaurant using a payment service, such as a service provider, comprising: receiving, by a payment service, such as a service provider, and from a first reservation application, first data associated with an average number of reservations made using the first reservation application over a period of time; receiving, by the payment service, and from a second reservation application, second data associated with an average number of reservations made using the second reservation application over a period of time; receiving, by the payment service, data regarding available seats at the restaurant; allocating a first portion of seats from the available seats to the first reservation application based on at least the first data, wherein one or more users of the first reservation application are able to reserve seats less than the first portion of seats. the allocating; allocating a second portion of the available seats to a second reservation application based on at least the second data, where one or more users of the second reservation application can reserve seats less than another portion of the seats; determining whether any seats are available on the second reservation application in response to at least one or more users being unable to reserve seats using the first reservation application during the reservation; providing instructions to transition a customer device from an interface of the first reservation application to the second reservation application; receiving input from one or more users indicating a reservation of seats in the restaurant using the second reservation application; a method is disclosed.

In some implementations, a server system that provides optimized restaurant reservation scheduling includes one or more processors and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions including: receiving, by a reservation scheduling application executing on a point of sale device associated with a merchant, a first reservation from a first customer-facing reservation application, the first reservation including one or more menu items to be prepared by the merchant for delivery to an address provided by the first customer-facing reservation application; transmitting, by the first delivery application, to the merchant's computing device, an estimated pick-up time indicating a time when the first delivery application estimates the arrival of a delivery person or customer to pick up the first reservation; and determining, based on past reservations involving the first customer-facing application, a predicted pick-up time indicating when the delivery person or customer is likely to pick up the first reservation. receiving, by the appointment scheduling application, a second appointment from a second customer-facing appointment application from another customer, the second appointment including one or more menus prepared by the merchant; transmitting, by the first delivery application, to the merchant's computing device, an estimated pick-up time indicating a time when the second delivery application estimates the arrival of a delivery person or other customer to pick up the second appointment; determining, based on past appointments involving the second delivery application, a predicted pick-up time indicating a time when the delivery person or customer is likely to pick up the second appointment; generating, by the appointment scheduling application, an ordered list of appointments based at least in part on the predicted pick-up times of the first appointment and the second appointment; and transmitting, in accordance with the ordered list, the ordered list of appointments to a kitchen display system for preparation of the appointment.

Although the embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure is not necessarily limited to the particular features or acts described. Rather, the specific features and acts are disclosed herein as exemplary forms of implementing the embodiments.
section

A. A system for providing optimized order scheduling, comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions including: receiving, by an order scheduling application executing on a point of sale (POS) device associated with a merchant, a first order from a first customer-facing ordering application, the first order including one or more menu items to be prepared by the merchant for delivery to an address provided by the first customer-facing ordering application; determining, by a service computing device, a predicted pickup time indicating an estimated time when a delivery person or the customer will likely pick up the first order based on past orders with the first customer-facing ordering application; and receiving, by the order scheduling application, a second order from another customer. A system that programs the one or more processors to perform operations including: receiving a second order from a customer-facing ordering application, the second order including one or more menu items to be prepared by the merchant; determining, by a service computing device, a predicted pick-up time indicating a time when the delivery person or the customer will likely pick up the second order based on past orders involving the second customer-facing ordering application; generating, by the service computing device, an ordered list of orders based at least in part on the predicted pick-up times of the first order and the second order; and transmitting the ordered list of orders to a kitchen display system associated with the order scheduling application for preparing the orders according to the ordered list.

B. The system of clause A further comprising an application executable by one or more processors of the computing device associated with at least one of a third party service or the merchant to provide an interface to at least one of the customer or the merchant via a display associated with a computing device, receive via the interface the ordered list of orders based on one of a delivery location, a pickup location, a requested time for pickup, a number of items to be retrieved, a size of the items, whether the items are associated with a predefined category, or a weight of the items, determine that information regarding delivery of the items is requested, transmit a request for delivery of the items to the service computing device via the one or more APIs, receive a delivery offer from the service computing device, determine that the delivery offer has been accepted, and transmit an indication of acceptance of the delivery offer via the one or more APIs to facilitate delivery of the items.

C. The system of clauses A or B, wherein the order scheduling application is further configured to provide an application program interface (API) for interfacing with the computing devices associated with the merchant, the computing devices associated with the third party service, and the computing devices associated with the customer.

D. The system of any of clauses A-C, further comprising a consensus application hosted on the service computing device, the consensus application receiving the first order and the second order from the first customer-facing ordering application and the second customer-facing ordering application, respectively, and the consensus application scheduling the first order and the second order for display on the kitchen display system.

E. The system of clause B, wherein the service computing device is further configured to: receive additional location information of a courier associated with the third party service; identify one of the third party services different from the third party service used to generate the first order or the second order based on the location information of the courier; and assign delivery of the item to the identified third party service.

F. A system comprising a service computing device processor and a service computing device communication interface communicatively connected to the service computing device processor, the service computing device communication interface communicating with a plurality of third party service devices over one or more networks and further communicating with a computing device associated with at least one of a customer or a merchant over the one or more networks via one or more application programming interfaces (APIs), the service computing device receiving a request for delivery of an item designated by a customer to be retrieved from a merchant via the one or more APIs provided by the service computing device, the request indicating at least one of a delivery location, a pickup location, a requested time of pickup, a number of items to be retrieved, a size of the items, whether the items are associated with a predetermined category, or a weight of the items, The system is configured to: receive the request via the one or more APIs from an application executable on the computing device associated with at least one of the customer or the merchant; generate a delivery proposal for the merchant to prepare and deliver the item to the location for delivery, the delivery proposal including (a) a preferred delivery service from among a plurality of third-party delivery services associated with the third-party service device, the plurality of third-party delivery services communicating with the merchant via the one or more APIs of the service computing device; (b) a sequence of requests including the request used by the merchant to prepare; and (c) an estimated amount of time for delivery of the item by the delivery service; and use the one or more APIs to send a communication to the third-party service associated with the preferred delivery service requesting that the preferred delivery service retrieve the item from the merchant's facility and transport the item to the location for delivery.

G. The system of claim F, wherein the sequence of requests includes a sequence in which the merchant processes the requests, the sequence being based on at least one of time, a location of the merchant, a location of the customer, a location of a courier capable of making the delivery, a time the order was received, a merchant profile, a customer profile, a preparation time for the requested item, and availability of the item.

H. One or more non-transitory computer-readable media storing executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: exposing one or more application programming interfaces (APIs) by the service computing device to provide a computing device with access to one or more merchants associated with the service computing device; exposing the one or more application programming interfaces (APIs) by the service computing device to provide a computing device with access to one or more third party services that can facilitate one or more actions associated with the merchant; receiving requests from computing devices of the merchants and the third party services via the one or more APIs to process the actions associated with the merchants; generating action proposals to facilitate the actions associated with the merchants, the action proposals including a sequence in which steps within the actions are to be performed; transmitting the action proposals to the computing devices associated with the third party services or the merchants; and configuring, by the service provider via the one or more APIs, a payment flow based on the action proposals, the payment flow being based on a distribution of sub-actions between the third party services and the merchants.

I. One or more non-transitory computer readable media as described in clause H, wherein the one or more actions include delivering an item, preparing the item, canceling the item, delivering an order, preparing the order, canceling the order, merging orders, splitting the order, reserving for a customer, making an appointment for a customer, updating content across third party services, updating the item, and updating the order.

J. The one or more non-transitory computer-readable media of any of clauses H or I, wherein the action suggestion is a delivery suggestion indicating at least one of an estimated amount of time for delivery of the item, an estimated pick-up time for delivery of the item, or an estimated drop-off time for delivery of the item.

K. One or more non-transitory computer-readable media as described in clause H, wherein exposing the one or more APIs includes exposing the one or more APIs to a computing device associated with a merchant to enable the merchant to facilitate delivery of an item offered for acquisition by the merchant.

L. The one or more non-transitory computer-readable media of clause K, wherein the operations further include receiving a request for a delivery status of the item from the computing device via the one or more APIs, receiving location information of the third party service device, determining a status of the delivery of the item by the third party service, and transmitting the status of the delivery of the item to the computing device.

M. One or more non-transitory computer-readable media as described in clauses K or L, wherein the operations further include receiving, via the one or more APIs, a further request to deliver another item to the merchant to enroll the merchant in a service that facilitates acquisition of the item, the other item being configured with a merchant application that facilitates acquisition of the item with a customer, the other request indicating a location for delivery of the other item; identifying the other third party service to transfer the other item based at least in part on the location of the other third party service; and sending a communication to a other third party service device associated with the other third party service requesting that the other third party service deliver the other item to the location for delivery of the other item.

N. One or more non-transitory computer-readable media as described in any of paragraphs H-M, wherein the operations further include obtaining training data regarding current and past actions performed by the merchant and the third-party service, and training a machine learning model based on the training data to generate the action suggestions.

O. A display configured to display an interface; one or more processors communicatively connected to the display; and a method, when communicatively connected to the one or more processors and executed by the one or more processors, for receiving, on the display, a first order to be prepared by a merchant and picked up for delivery by a first courier of a first delivery service to a first customer; receiving, on the display, a second order to be prepared by the merchant and picked up for delivery by a second courier of a second delivery service to a second customer; and a sequence in which the merchant should prepare the first order and the second order. A system comprising: a memory storing executable instructions to perform operations including receiving a delivery offer on the display, the sequence being generated by a service computing device interfaced with the system having the display, the first delivery service, and the second delivery service via one or more application program interfaces (APIs); modifying the sequence through the display based on availability of items in the first order or the second order; and generating a payment flow based on the modification by initiating an API call to the service provider.

P. The system of clause O, wherein the operations further include sending a trigger to the service computing device via the one or more APIs to provide a delivery status of the item to the first delivery service or the second delivery service, receiving a status of the delivery of the item from the service computing device, and sending the status of the delivery to the first delivery service or the second delivery service.

Q. The system of clause O or P, wherein the system includes a merchant device, and the operations further include receiving from the service computing device an order for acquisition of another item, the other item being selected for acquisition through a customer device of the first delivery service; receiving user input indicating acceptance of the order; sending an indication of acceptance of the order to the service computing device; receiving a first status of delivery of the item and a second status of delivery of the other item; and displaying the first status of delivery and the second status of delivery via the interface.

R. The system of any of paragraphs O-Q, wherein the delivery proposal indicates at least one of a cost for delivery of the item by a delivery service interfaced with the service computing device, an estimated amount of time for delivery of the item, an estimated pick-up time for delivery of the item, or an estimated drop-off time for delivery of the item.

S. The system of any of paragraphs O-R, wherein the delivery suggestion indicates at least one of a cost for delivery of the item by a delivery service associated with the service computing device, and the action includes removing an item from a group of items in an order, the removal being based on availability, popularity, spoilage, and time of day, causing the removal and the cost of delivery of the item to be displayed via the interface, and charging a customer associated with acquiring the item the cost of delivery of the order after removing the item.

T. The system of any of paragraphs O-S, wherein the operations further include providing a consensus when the first order and the second order are placed substantially simultaneously.

U. A system for providing optimized appointment scheduling, comprising one or more processors and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions including: receiving, by an appointment scheduling application executing on a point of sale device associated with a merchant, a first appointment request from a customer from a first customer-facing appointment application, the first appointment request including a preferred time for the appointment at a merchant location; determining, by a service computing device based on past orders involving the first customer-facing appointment application, a seat that is predicted to be likely to favor the first appointment request by the customer; and receiving, by the appointment scheduling application, a second customer-facing appointment request from another customer from a second customer-facing appointment application. receiving a second reservation request from a customer facing reservation application, the second reservation request including another preferred time for a reservation at the merchant location; determining, by a service computing device, seats that are predicted to be likely to be preferred by the other customer for the second reservation request based on past orders involving the second customer facing reservation application; generating, by the service computing device, a seating chart based at least in part on the predicted seats corresponding to the first reservation request and the second reservation request; and transmitting the seating chart to a kitchen display system associated with the reservation scheduling application to configure a table layout at the merchant location according to the seating chart.

V. The system of clause U further includes an application executable by one or more processors of a computing device associated with at least one of a third party service or the merchants, the application providing an interface to at least one of the customer or the merchants via a display associated with the computing device, receiving updates to the seating plan via the interface based on at least one of an alternative merchant offering a reservation, a seating option at the merchant for which a reservation is requested, a timing of the reservation, and an alternative seating option that differs from the requested seating option based on past seating preferences, determining that information regarding the seating plan has been requested, transmitting a response to the request for updates to the seating plan via the one or more APIs and by the service computing device, receiving a reservation proposal from the service computing device, determining that the reservation proposal has been accepted, and transmitting an indication of acceptance of the reservation proposal via the one or more APIs to facilitate the reservation.

W. The system of clauses U or V, wherein the appointment scheduling application is further configured to provide an application program interface (API) for interfacing with the computing devices associated with the merchant, the computing devices associated with the third party service, and the computing devices associated with the customer.

X. The system of any of clauses U-W, further comprising a consensus application hosted on the service computing device, the consensus application receiving the first reservation request and the second reservation request from the first customer face-to-face booking application and the second customer face-to-face booking application, respectively, and the consensus application processing the first reservation request and the second reservation request based on the customer preferences.

Y. The system described in clause V, wherein the service computing device is further configured to receive further customer information associated with the reservation request, identify one of the merchants different from the merchant for which the reservation is requested, and assign a seat at the other merchant location based on the identification.

Z. A system comprising a service computing device processor and a service computing device communication interface communicatively connected to the service computing device processor, the service computing device communication interface communicating with a plurality of third party service devices over one or more networks and further communicating with a computing device associated with at least one of a customer or a merchant over the one or more networks via one or more application programming interfaces (APIs), the service computing device being configured to: receive a request for a reservation with the merchant via the one or more APIs provided by the service computing device, the request indicating a preferred time for the reservation at a merchant location; generate a reservation proposal for setting the reservation according to customer preferences for presentation on a device associated with the merchant, the reservation proposal including (a) a seat at the merchant location from among a plurality of seating options, (b) an alternative time slot corresponding to the request, and (c) an alternative seating option if the merchant location is booked; and use the one or more APIs to send a communication to the third party service device associated with the identified third party service requesting that the identified third party service reserve a seat at the merchant location.

AA. The processor is further configured to allocate a reservation for a merchant associated with the merchant device configured to receive reservations from a plurality of reservation applications including a first reservation application and a second reservation application, the processor including: receiving, via a payment service, from the first reservation application, a first data-related reservation made using the first reservation application; receiving, via the payment service, from the second reservation application, a second data-related reservation made using the second reservation application for a time period; receiving, via the payment service, data regarding available seats at a restaurant; and allocating, based on at least the first data, a first portion of seats from the available seats to the first reservation application; The system of clause Z performs one or more operations including: allocating a second portion of the available seats to the second reservation application based on at least second data, where a user of the second reservation application can reserve seats up to another portion of the available seats; determining whether any seats are available on the second reservation application during the reservation and in response to at least one user being unable to reserve seats using the first reservation application; providing instructions to transition a customer device from an interface of the first reservation application to the second reservation application; and receiving input from the one or more users indicating a reservation of the seats in the restaurant using the second reservation application.

A.B. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: exposing, by a service computing device, one or more application programming interfaces (APIs) to provide a computing device with access to one or more merchants associated with the service computing device; exposing, by the service computing device, one or more application programming interfaces (APIs) to provide a computing device with access to one or more third-party services that can facilitate one or more actions associated with the merchant; receiving, via the one or more APIs, requests from the computing devices of the merchants and the third-party services to process actions associated with the merchants; generating action proposals to facilitate the actions associated with the merchants, the action proposals including a sequence in which steps within the actions are to be performed; transmitting the action proposals to the computing devices associated with the third-party services or the merchants; and configuring, by the service provider, via the one or more APIs, a payment flow based on the action proposals, the payment flow being based on a distribution of sub-actions between the third-party services and the merchant.

AC. One or more non-transitory computer readable media as described in clause AB, wherein the one or more actions include delivering an item, preparing the item, canceling the item, delivering an order, preparing the order, canceling the order, merging an order, splitting the order, reserving a customer, making a customer appointment, updating content across third party services, updating the item, and updating the order.

AD. One or more non-transitory computer readable media as described in any of paragraphs AA-AC, wherein the action suggestion is a reservation suggestion indicating at least one of an alternative merchant offering a reservation, a seating option at the merchant for which a reservation is requested, a timing of the reservation, and an alternative seating option that differs from the requested seating option based on past seating preferences.

AE. The one or more non-transitory computer-readable media of clause AB, wherein exposing the one or more APIs includes exposing the one or more APIs to a computing device associated with a merchant to enable the merchant to facilitate a reservation or appointment with the merchant at one of a physical location or an online location.

AF. The one or more non-transitory computer readable media described in clause AE, wherein the operations further include receiving a request for a modification to the reservation request from the computing device via the one or more APIs, accessing a seating chart associated with the merchant and including reservations made through multiple third party services, determining whether the modification causes a conflict condition, and determining a new seat based on the determination.

AG. One or more non-transitory computer-readable media as described in clauses AE or AF, wherein the operations further include receiving, via the one or more APIs, another request to reserve another seat, the other seat matching a seat assigned to a previous reservation; identifying alternative seating options for the first request or the second request based on updated customer preferences; and sending a communication to the merchant indicating an updated seating plan in accordance with the identifying step.

AH. One or more non-transitory computer-readable media as described in any of paragraphs AB-AG, wherein the operations further include obtaining training data regarding current and past actions performed by the merchant and the third-party service, and training a machine learning model to generate action suggestions based on the training data.

A system comprising: a display configured to display an AI. interface; one or more processors communicatively connected to the display; and a memory communicatively connected to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: receiving, on the display, a first reservation at a first merchant location using a first reservation application; receiving, on the display, a second reservation at a second merchant location using a second reservation application; receiving, on the display, a reservation proposal including a seating plan for reserving seats corresponding to the first reservation and the second reservation, the seating plan being generated by a service computing device interfaced with the system having the display, the first reservation service, and the second reservation service via one or more application program interfaces (APIs); modifying the seating plan through the display based on real-time input from the merchant indicating a change in the seating plan; and initiating an API call to the service provider to cause a reallocation of seats based on the modification.

AJ. The system of clause AI, wherein the operations further include causing the service computing device to send a trigger via the one or more APIs to provide a reservation status to the first reservation service or the second reservation service, and to transmit the reservation status to the computing device associated with the customer.

AK. The system of clauses AI or AJ, wherein the system includes a merchant device, and the operations further include receiving, via the one or more APIs, another request to reserve another seat, the other seat matching a seat assigned to a previous reservation; identifying alternative seating options for the first request or the second request based on updated customer preferences; and sending a communication to the merchant indicating an updated seating plan in accordance with the identifying step.

AL. The system of any of paragraphs AI-AK, wherein the reservation suggestions indicate at least one of alternative merchants offering reservations, seating options at the merchant for which a reservation is requested, the timing of the reservation, and alternative seating options that differ from the requested seating options based on past seating preferences.

AM. The system of any of clauses AI-AL, wherein the reservation suggestion indicates at least one of options for reserving a public seat by routing the request from the first reservation application to the second reservation application, the routing including transitioning from a first user interface associated with the first reservation application to a second user interface associated with the second reservation application.

AN. The system of any of paragraphs AI-AM, wherein the operations further include providing a consensus when the first reservation and the second reservation are made substantially simultaneously.

AO. A system for providing optimized content management associated with a menu, the system comprising one or more processors and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions being executed by a content management application associated with a service computing device and on a point of sale device associated with a merchant to program the one or more processors to perform operations including: receiving content updates for one or more menu items offered by the merchant, the content updates being configured to be distributed to customer-facing applications by the content management application; determining by the content management application whether the content updates apply to one or more additional customer-facing applications, the one or more additional customer-facing applications being interfaced with the content management application via one or more application program interfaces (APIs); and, based on the content updates being determined to apply to one or more additional customer-facing applications by the service computing device, updating the interfaces of the one or more additional customer-facing applications according to the content updates via the one or more APIs; and sending a notification to a kitchen display system associated with the merchant indicating that the customer-facing applications have received the content updates.

AP. The system described in clause AO further includes an application executable by one or more processors of a computing device associated with at least one of a third party service or a merchant, providing an interface to at least one of the customers or the merchants via a display associated with the computing device; receiving a notification via the interface indicating that the customer-facing application has received the content update and synchronizing across other customer-facing applications; determining that the content update is sent only to targeted customer-facing applications; and canceling the content update from non-targeted customer-facing applications, including the other customer-facing applications, via the one or more APIs and by the service computing device.

AQ. The system described in paragraphs AO or AP, wherein the content management application is further configured to provide an application program interface (API) for interfacing with the computing devices associated with the merchant, the computing devices associated with the third party service, and the computing devices associated with the customer.

AR. The system of any of paragraphs AO-AQ, further comprising a consensus application hosted on the service computing device, the consensus application receiving a plurality of content updates from merchants associated with one or more point of sale (POS) devices executing one or more instances of the content management application, the consensus application selecting one of the plurality of content updates based on a preference of the customer.

AS. The system of any of paragraphs AO-AR, wherein the service computing device is further configured to determine whether to generate the content update based on an inventory database, identify which of the customer-facing applications should receive the content update, and transmit the content update to the identified customer-facing applications.

AT. A system comprising a service computing device processor and a service computing device communication interface communicatively coupled to the service computing device processor, the service computing device communication interface communicating with a plurality of third party service devices over one or more networks and further communicating with a computing device associated with at least one of a customer or a merchant over the one or more networks via one or more application programming interfaces (APIs), the service computing device receiving, via the one or more APIs provided by the service computing device, a request for a content update, the content update configured for delivery to a customer-facing application and relating to one or more menu items provided by the merchant, the request being generated via the one or more APIs from an application executable on the computing device associated with at least one of the customer or the merchant; and determining, via the one or more APIs provided by the service computing device, whether the content update is applied to other customer-facing applications. The system is configured to: determine that the other customer-facing application is interfaced with the application via one or more application program interfaces (APIs); and generate, in response to determining by the service computing device that the content update is applied to the other customer-facing application, a proposal for the merchant to deliver the content update to the location of delivery associated with the customer-facing application, the proposal including (a) one or more customer-facing applications from among a plurality of customer-facing applications associated with the third-party service device, the plurality of customer-facing applications communicating with the merchant via the one or more APIs of the service computing device; (b) a nature of the content update indicating an urgency to apply the content update; and (c) an estimated time of delivery of the content update; cause an interface of the other customer-facing application to be updated according to the content update; and send, using the one or more APIs, a notification to a kitchen display system associated with the merchant indicating that the customer-facing application has received the content update.

AU. The system described in clause AT, further configured to provide an interface to at least one of the customer or the merchant via a display associated with the computing device, receive via the interface the notification indicating that the customer-facing application has received the content update, determine that the content update should be sent only to the targeted customer-facing application, and cancel the content update from non-targeted customer-facing applications, including the other customer-facing applications, via the one or more APIs and by the service computing device.

A.V. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: exposing, by a service computing device, one or more application programming interfaces (APIs) to provide a computing device with access to one or more merchants associated with the service computing device; exposing, by the service computing device, one or more application programming interfaces (APIs) to provide a computing device with access to one or more third-party services that can facilitate one or more actions associated with the merchant; receiving, via the one or more APIs, requests from the computing devices of the merchants and the third-party services to process the actions associated with the merchant; generating action proposals to facilitate the actions associated with the merchant, the action proposals including a sequence in which steps within the actions are to be performed; transmitting the action proposals to the computing devices associated with the third-party services or the merchant; and configuring, by the service provider, via the one or more APIs, a payment flow based on the action proposals, the payment flow being based on a distribution of sub-actions between the third-party services and the merchant.

AW. One or more non-transitory computer readable media as described in clause AV, wherein the one or more actions include delivering an item, preparing the item, canceling the item, delivering an order, preparing the order, canceling the order, merging an order, splitting the order, reserving a customer, making a customer appointment, updating content across third party services, updating the item, and updating the order.

AX. One or more non-transitory computer-readable media described in any of paragraphs AV or AW, wherein the action proposal is a content update proposal indicating the content to be updated and an identifier of a third-party service to which the content update is to be sent.

AY. One or more non-transitory computer-readable media as described in clause AV, wherein exposing the one or more APIs includes exposing the one or more APIs to a computing device associated with the merchant to enable the merchant to facilitate updating content, including menu items.

AZ. One or more non-transitory computer-readable media as described in clause AY, wherein the operations further include receiving a request for a delivery status of an item from the computing device via the one or more APIs, receiving location information of the third party service device, determining a status of the content update by the third party service, and transmitting the status of the content update to the computing device.

BA. The one or more non-transitory computer-readable media of clauses AY or AZ, wherein the operations further include executing a consensus application hosted on the service computing device, the consensus application receiving a plurality of content updates from the merchants associated with one or more point-of-sale (POS) devices executing one or more instances of a content management application, and the consensus application selecting one of the plurality of content updates based on a preference of the customer.

BB. One or more non-transitory computer-readable media as described in any of Sections AV-BA, wherein the operations further include obtaining training data regarding current and past actions performed by the merchant and the third-party service, and training a machine learning model to generate the action suggestions based on the training data.

BC. A system comprising: a display configured to display an interface; one or more processors communicatively connected to the display; and a memory communicatively connected to the one or more processors and storing executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including receiving, by a server application, a first content request for delivery to a first device of a first customer-facing application; receiving, by the server application, a second content request for delivery to a second device of a second customer-facing application; and fulfilling, by the server application, the first content request and the second content request for one or more delivery locations. A system including: generating a proposal for a third-party service device, the proposal including: (a) one or more customer-facing applications from among a plurality of customer-facing applications associated with the third-party service device, the plurality of customer-facing applications communicating with the merchant via the one or more APIs of the service computing device; (b) a nature of the content update indicating an urgency for applying the content update; and (c) an estimated amount of time for delivery of the content update; initiating a trigger of the content update to the customer-facing application via the server application; and causing a payment flow based on the initiation by initiating an API call to the service provider.

BD. The system of clause BC, wherein the operations further include sending a trigger to the service computing device via the one or more APIs to provide the content update to the first or second customer-facing application, receiving a status of the content update from the service computing device, and causing the status of delivery of the content update to be sent to the first or second delivery service.

BE. The system of clauses BC or BD, wherein the system includes a merchant device, and the operations further include receiving from the service computing device an order for acquisition of another item, the other item being selected for acquisition via a customer device of the first delivery service; receiving user input indicating acceptance of the order; sending an indication of acceptance of the order to the service computing device; receiving a first status of delivery of the item and a second status of delivery of the other item; and displaying the first status of delivery and the second status of delivery via the interface.

BF. The system of any of paragraphs BC-BE, wherein the proposal illustrates a method for handling the first content request across different merchant applications.

BG. The system of any of paragraphs BC-BF, wherein the suggestions indicate whether the first content request applies to other customer-facing applications other than the identified ones, and the actions further include updating existing content, generating new content, and removing existing content.

BH. The system of any of paragraphs BC-BG, wherein the operations further include providing consensus when the first content request and the second content request are made substantially simultaneously.

Although the example passages above are described with respect to one particular implementation, it should be understood in the context of this specification that the contents of the example passages may also be implemented via a method, device, system, computer-readable medium, and/or another implementation.

Claims (5)

1. A system for providing optimized appointment scheduling, comprising:
one or more processors;
and one or more non-transitory computer-readable media storing instructions executable by the one or more processors, the instructions comprising:
receiving, by an appointment scheduling application executing on a point of sale device associated with a merchant, from a customer a first appointment request from a first customer-facing appointment application, the first appointment request including a preferred time for an appointment at a merchant location , the merchant location being a location where goods and/or services are offered by the merchant;
determining, by a service computing device, a seat that the customer is likely to prefer for the first reservation request based on past orders involving the first customer-facing reservation application;
receiving, by the appointment scheduling application, a second appointment request from a second customer-facing appointment application from another customer, the second appointment request including another preferred time for an appointment at the merchant location;
determining, by a service computing device, a seat that is predicted to be likely to be preferred by the other customer for the second reservation request based on past orders involving the second customer-facing reservation application;
generating, by the service computing device, a seating chart based at least in part on the predicted seats corresponding to the first reservation request and the second reservation request;
transmitting the seating plan to a kitchen display system associated with the reservation scheduling application to configure a table layout at the merchant location according to the seating plan;
and programming the one or more processors to perform operations including: an application executable by one or more processors of a computing device associated with at least one of a third party service or the merchant,
providing an interface to at least one of the customer or the merchant via a display associated with the computing device;
receiving, via the interface , updates to the seating chart based on at least one of a seat selection at the merchant for which a reservation is requested, a timing of the reservation, and an alternative seat selection that differs from the requested seat selection based on past seat preferences;
determining that information regarding the seating plan has been requested;
transmitting a response to the request for an update to the seating chart via one or more APIs and by the service computing device;
receiving a reservation proposal from the service computing device;
determining that the reservation proposal has been accepted;
transmitting, via the one or more APIs, an indication of acceptance of the reservation proposal to facilitate the reservation; and
The system of claim 1 further comprising an application that: 2. The system of claim 1, wherein the appointment scheduling application is further configured to provide an application program interface (API) for interfacing with computing devices associated with the merchant , computing devices associated with a third party service, and computing devices associated with the customer. The system of claim 1, further comprising a consensus application hosted on the service computing device, the consensus application receiving the first reservation request and the second reservation request from the first customer face-to-face booking application and the second customer face-to-face booking application, respectively, and the consensus application processing the first reservation request and the second reservation request based on the customer preferences. The service computing device includes:
receiving further customer information associated with the reservation request, identifying one of the merchants different from the merchant for which the reservation was requested;
The system of claim 2 , further configured to assign seats at other merchant locations based on the identification.

Images