JP2022110048A - Application programming interfaces for structuring distributed systems - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system which allows entities to utilize delivery services provided by a service provider.

SOLUTION: In an architecture 100, a service provider exposes delivery services to a computing device associated with a merchant, buyer, and/or other parties using one or more Applicant Programming Interfaces (APIs) provided by the service provider. The one or more APIs enable merchants and/or other parties to automatically integrate the delivery services into technologies used by the merchants and/or other parties in order to facilitate delivery of items that are offered for acquisition by the merchants.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2022,JPO&INPIT

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 Dec. , all of which are incorporated herein by reference in their entirety.

Buyers often use websites and other technologies to purchase items from merchants for delivery to the buyer. In some cases, a distribution system or service can facilitate the distribution of goods (goods) and services offered by merchants. For example, a shipping service may provide an online site that identifies items from multiple merchants that are available for shipping. A buyer can navigate to an 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 may utilize a variety of techniques to accomplish delivery of an item to a buyer (purchaser). In particular, the shipping service may communicate with electronic devices associated with merchants and/or electronic devices associated with customers to deliver items. Customers also use techniques to interact with merchants, for example, to make appointments to purchase items or otherwise book their time or services. Similarly, a reservation service can facilitate the reservation of a merchant's location for a particular service. However, when merchants are associated with some of these delivery, booking, and other third-party services, they must manually control and coordinate information injection from different unconnected sources. , ultimately defeating the simplicity of operation promised by third-party services. Further, the association of merchant interfaces with third party services can disrupt other technologies that merchants employ to conduct their businesses.

The detailed description is described with reference to the accompanying drawings, in which the left-most 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 similarity. or refer to the same item or feature.

FIG. 1 shows an exemplary architecture in which the techniques described herein can be implemented.

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

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

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

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

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

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

FIG. 8 illustrates an exemplary process of communicating via one or more APIs exposed by service providers to provide status updates regarding orders.

FIG. 9 is exemplary data illustrating the process of harmonizing menu items across third-party services, dynamically modifying user interface icons based on contextual data, and harmonizing menu items across different services. A flow diagram is shown.

FIG. 10 illustrates an exemplary dataflow diagram illustrating the process of reconciling reservations and allocating open or duplicate reservations originating from multiple third party services.

The technology described herein enables an entity, through a service provider, to communicate with different services, such as applications for delivery services, so that the entity can communicate with different services without complex coding or modifications to the entity's source code. Provide a system and environment that allows different third party services to be configured, such as an application for booking services and an application for third party services. In some examples, a service provider uses one or more application programming interfaces (APIs) provided by the service provider to provide consensus to computing devices associated with merchants, buyers, and/or others. Publish your service. Service providers also use APIs to expose consensus services to computing devices associated with users, consumers, or developers of third party applications. In some examples, a service provider may be a third party operating remotely and/or independently from merchants, buyers, and/or others. One or more APIs are provided for acquisition by merchants, enabling merchants and/or others to automatically integrate consensus services into the technology used by merchants and/or others It can facilitate several tasks such as item delivery, restaurant reservations for both in-dining or pickup, and menu generation. For example, one or more APIs to the Consensus Service may allow an entity to automatically access information (e.g., carrier costs, estimated delivery times, etc.) regarding delivery of items by multiple delivery services, Consensus services such as facilitating delivery and ordering the preparation of items, scheduling delivery and preparation from the kitchen, scheduling appointments, and managing content to and from third party services may be enabled to use various other features provided by the service provider via.

First, the implementation is described with reference to a delivery service or third party service. In many instances, 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. Service Providers may track the location of a Third Party Service Device to select a Third Party Service Device for delivery, send updates regarding the delivery of an item, or otherwise track the location of an Item by a Third Party Service. Shipping can be facilitated. Additionally or alternatively, a service provider may work in conjunction with multiple merchant devices. Each merchant device may implement a global positioning system (GPS) receiver or other location sensor to provide location information to the service provider. The service provider can use the location of the merchant device to facilitate delivery of items offered for acquisition by the merchant and to perform other functions. Additionally or alternatively, the Service Provider may communicate with multiple Third Party Services and implement Third Party Service logic and systems to receive orders from customers for goods and services offered by the Merchant. can do. As described above, merchant, customer, and third party services and systems can interact with each other via APIs of the service provider's consensus system.

The consensus system then acts as a hub, eg, an order hub, for exposing 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 time or delivery time across multiple incoming services to automatically calculate new order analytics such as preparation time, delivery time, order for preparation. 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 of 10 hamburgers from a third party delivery service and another order of 5 hamburgers from a second third party delivery service, The consensus system updates in real time item availability, readiness, and delivery times for the first and second third party shipping services and any other third party shipping services. can be done. The consensus system can also predict and anticipate employee staffing for ordered items so that merchants have appropriate staff and inventory based on past orders from various services. The consensus system can also direct automatic replenishment of inventory/materials or automatic reordering from vendors based on the status of incoming orders through multiple third party services.

The Consensus System can also serve as a booking hub by utilizing one or more APIs for integration of third party booking services, centralized bookings, waiting lists, and scheduling management. The Consensus System can communicate with other third party reservation services to provide a central reservation system and dynamic allocation/reassignment of tables and preferred seats, and where dining-ins are not available Pick-up can also be provided on occasion. The consensus system monitors and analyzes demand for seating time and optimizes staffing and ingredients accordingly to support diners with preferred waiters/chefs for specific reservations or desired menu items. become Certain thresholds may be set for items such as the number of items and the number of customized appointments allowed during a shift. In addition, the consensus system assigns arbitrary seat quotas to each service based on usage metrics and reserves seats if one service cannot supply the user's request, regardless of whether the user is subscribed to other services. A user can be transferred from one service to another via an API to perform Additionally, the consensus system can be a hub for allocation of reserved seats and 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 the restaurant. The consensus system also integrates with other verticals supported by service providers. For example, 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. Integrates with the onboarding component, like so: The consensus system can also recommend restaurants based on aggregated reviews from all services, such as by weighting or relevance of each third party service.

A consensus system may be a hub, such as a menu hub, for content aggregation and analysis. In such embodiments, the consensus system dynamically sets prices based on how users order on different menus from third-party services, optimizing sales accordingly. is a unified manager for A consensus system can drive a single menu update applicable to all third party services and harmonize content on such services. The consensus system can also drive multiple or service-specific updates to consider usage metrics across third-party services. For example, menu content orders 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, a payment service may change menu orders based on order popularity or user 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 once the order is placed in the kitchen. In this way, payment services can leverage exposed APIs to determine how users navigate third-party service menus and what items users tend to add to checkout. and adjust the global menu for merchants (or specific menus for merchants and third-party services) accordingly.

As an example of the technology described herein, applications may run on computing devices associated with merchants, buyers, and/or others. Applications allow individuals (e.g., merchants, buyers, etc.) to perform actions, e.g., place orders for items offered for acquisition by merchants, reserve seats in restaurants, display content. , to provide updates for third-party services, and the like. For example, for a delivery service, through a user interface, an individual can select items to acquire and request that the items be delivered. For example, an individual may indicate an interest in placing items in an electronic shopping cart for purchase and having the items shipped. In some cases, an individual may provide information such as location of delivery, location of pickup, requested time of pickup, number of items being retrieved, size of item, whether item is associated with a given category, weight of item, etc. can be specified. In other examples, such information is automatically determined or obtained from a user profile or merchant profile.

Upon determining that an individual is interested in having an item shipped, the application, such as for a third-party shipping service, may contact the service provider to facilitate delivery of the item via a consensus service associated with the service provider. can communicate with third party service providers using APIs provided by For example, an application can send a request for the cost of shipping an item, an estimate of the time to ship the item, and so on. The third party service uses the associated shipping service to generate a shipping offer to ship the item to the buyer's location, e.g., to the service provider via the API for Consensus Service. can be done. A shipping offer may include shipping costs, estimated shipping times, and/or other information regarding the shipping of the item. Service providers can send delivery offers to the application for acceptance or rejection via the consensus service. In some examples, the application presents information to an individual interacting with the user interface, and the individual can provide input to accept or decline the offer. In other examples, an application may operate according to one or more criteria to automatically accept or reject a delivery offer (e.g., accept if cost is below a threshold, estimated delivery accept if the time is less than the threshold amount of time, etc.). In any event, the application can use the API to send an indication of acceptance or rejection of the delivery offer to the third party service.

The service provider may take steps to select a courier for delivery if the third party service has been notified of the acceptance of the delivery offer. For example, a service provider can track the location of multiple shipper devices over time, be within a certain distance to a pickup location, be available to make deliveries, and be able to transport items. A delivery person can be selected that meets one or more criteria, such as being associated with a vehicle. In some cases, the service provider may select a courier using a courier profile, user profile, merchant profile, or other information. The service provider can then send a communication to the shipper requesting that the shipper obtain the item from the merchant's facility and transport the item to the delivery location. During delivery of the item, the service provider may receive information from the shipper and/or merchant (eg, location information, confirmation that the delivery was picked up, etc.) to determine the status of the delivery. The service provider can send the status of the shipment to applications, merchant devices, buyer devices, and/or others so that individuals can be informed of the current status of the shipment.

In many cases, the technologies and environments described herein provide one or more APIs to access consensus services provided by service providers and to support delivery services, reservation services, and content services. . That is, one or more APIs can provide an 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 lead to relatively fast website and application implementations. Additionally, technology and environments may allow the integration of third party services to be implemented across a wide variety of contexts (eg, devices, platforms, etc.). Additionally, the technology and environment provide a flexible structure for modifying the underlying technology, eg, consensus services, used by service providers to implement third-party services. In other words, the underlying technology of the merchant platform is updated in a unified and/or simplified manner without requiring technology updates implemented by merchants, buyers, and/or others. good too. Additionally, the technology and environment may allow the underlying technology (eg, including algorithms, cost schemes, etc.) used by service providers to be maintained in a secure environment. Also, data shared by multiple third-party services need not be exposed to merchants, and furthermore, service providers are responsible for data control and data encapsulation based on third-party services, environment, location, time of day, etc. , which may be specific to the Third Party Service or the relationship between the Third Party Service and the Merchant Platform, such as terminals, applications, kitchen display systems, payment applications, etc. may

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

Benefits of a central restaurant system include better management of reservations, tracking of restaurant reviews from multiple sources, and elimination of double-booking during restaurant reservations or overbooking. Although the description refers to restaurants as an exemplary use case, it will be appreciated that the description can be extended to other use cases for reservations and appointments at salons, hospitals, yoga studios, and the like. Using the techniques described herein, reservations can be optimized and seat allocations can be assigned to third party reservation services in real time, for example, based on filling capacity.

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

In addition, the techniques herein can be used with various hardware and software platforms by porting the instructions and data of the consensus system through the API with little or no change to its source code. interface so that it can onboard and integrate with any third party service for delivery of items from the merchant to the buyer, or any other service without any formation or termination relationship with the merchant. can be provided. Through the interaction of computing devices, mobile devices, and sensors, implementations herein adapt to the ever-changing context of merchants, buyers, service domains, third-party services, hardware and software platforms, and third-party services themselves. and conditions, an unpredictable sharing ecosystem can be managed in which a large number of entities can participate.

In various implementations, the consensus system acts as a central server, or group of servers, ingesting data from various sources via APIs, porting instructions and data into a format understood by various services, and distributing the data. Filtering can be used to determine relevance to various merchants and services, and analytics can be used to structure or restructure various merchant tasks such as delivery, booking, content aggregation, or content display.

Some implementations herein describe bi-directional or push-pull APIs, where information travels in both directions and API endpoints are associated with both communicating applications. means However, some implementations may implement a unidirectional API 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. Additionally, the techniques described above and below can be implemented in several ways and in several contexts. As described in detail below, some example implementations and context are provided with reference to the following figures. However, the implementations and contexts below are a few of many.

FIG. 1 shows an exemplary architecture 100 that can implement the techniques described herein. The architecture 100 includes one or more users 104 (hereinafter "users 104"), one or more merchants 106 (hereinafter "merchant 106"), of applications such as consensus services, buyers at merchant locations, third party services, etc. one or more third party services 108 (hereinafter referred to as "delivery services 108", "courier services", "reservation services 108", "content services", and collectively third party services as the context requires); ), one or more card payment network computing devices 110, and/or one or more bank computing devices 112 to perform various operations (hereinafter “consensus service”). ), including service providers 102 associated with Third party services can also include services provided by service providers, for example, for delivery, booking, or content aggregation and management. Service providers 102 often provide one or more application programming interfaces (APIs) 114 to enable users 104 and/or merchants 106 to access consensus services provided by service provider 102. can do. APIs can be implemented as push APIs, pull APIs, or a combination of both. Thus, each application can create or share API endpoints for receiving and/or sending updates. For example, the push API allows push services to send push messages to web applications, sometimes asynchronously. The application server can send push messages at any time, even if the web application or user agent is inactive. Push services ensure reliable and efficient delivery to user agents. The push message is delivered to a service worker running at the origin of the web application, and the service worker can use the information in the message to update local state or display a notification to the user. The pull API operates to extract data, for example, based on a scheduled job that is set to run at certain intervals. The system continues polling sources until certain conditions are met.

Further, service provider 102 is often capable of facilitating a transaction between a buyer (first user) and a seller (second user), which is carried out over one or more card payment networks. It may involve communicating with computing device 110 and/or one or more bank computing devices 112 . Each of users 104, merchants 106, and/or third party services 108 can be associated with a computing device. For example, a third party service may run on a user device associated with user 104 or merchant device 106 . Additionally, in some examples, environment 100 may include additional service providers (service provider 116) for communicating with users 104 and/or merchants 106 to facilitate acquisition of items, as described in further detail below. )including. As shown, any computing device in architecture 100 can communicate with each other via one or more networks 118 .

A merchant may include any company or entity engaged in providing goods or services for acquisition by a buyer in exchange for consideration received from the buyer. Actions attributed to a merchant may include actions performed by the merchant's employees or other agents, and thus, unless specifically discussed herein, no distinction is made between merchants and their employees. can't break Further, a buyer can include any entity that obtains goods or services from a merchant by purchase, rental, lease, borrowing, licensing, or the like. Hereinafter, products and/or services may be referred to as items. Items can include finished goods, partially finished goods, raw materials, and the like. Thus, a merchant and a buyer can interact with each other to effect a transaction in which the buyer obtains one or more items from the merchant and, in return, the buyer provides payment to the merchant.

A third party service, such as a delivery service, can include entities engaged in the delivery of items. A third party service may obtain an item from a shipping pick-up location (eg, a merchant's location) and transport the item to a shipping drop-off location (eg, a buyer's location). Some implementations herein provide innovations that allow merchants to coordinate incoming shipping requests (also called orders) from different shipping portals 108 . Using such technology, merchants can coordinate and synchronize orders with respect to inventory, order times, customer loyalty ratings, and the like.

Third party services, such as restaurant management services, can include any entity that allows reservations at their location, such as online reservations or in-person reservations. Also, the term reservation is intended to include appointments, dining in person, pickup, and the like. A third party service may receive a request to make a reservation at a merchant location. Some implementations herein provide innovations that allow merchants to coordinate incoming reservation requests (also called reservations) from different reservation portals 108 . Using such technology, merchants can coordinate and synchronize orders with respect to seat availability, diner preferences, time, location, items available on menus, and the like.

Third party services, such as content aggregation services, can include any entity engaged in delivering items. Third party services know what their customers want to see, especially with respect to merchant stores, without any consideration of what other third party services are doing. content can be displayed without Some implementations herein provide innovations that allow merchants to coordinate content such as menus across different third party services 108 . Using such technology, merchants can coordinate and synchronize menus and other content with respect to third-party service profiles, 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 at the same time. Alternatively or additionally, menus and other such content, e.g., display of content, ordering of items, etc., may be affected by relationships between third-party services and merchants, availability of items, time of day, and other It can be configured according to such factors.

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

For example, an acquisition device may communicate with a merchant via service provider 102 through one or more APIs 114 while placing an order with merchant 106 . In particular, individuals (users 104 and/or merchants 106) can express an interest in placing items in an online shopping cart for purchase and having the items shipped. In response, the acquisition device may send a request to service provider 102 via one or more APIs 114 for information regarding delivery, booking, or content management. The service provider 102 communicates with a merchant or merchant inventory database (locally or remotely) to generate a shipping offer for delivery of the item by a shipping service associated with the service provider 102, and through an API call 134, submits the shipping offer. Can be sent to the acquisition device. Acquisition devices may display information in the delivery offer via the item acquisition interface 120(a) for acceptance or rejection. As shown in FIG. 1, the estimated amount of time and shipping cost to deliver the item is presented at 122 in the acquisition interface 120(a). The individual can accept the shipping offer and place the order by selecting 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 items ordered by another third party service or another user. In such cases, the service provider 102 may monitor the location of the shipper (e.g., third party service 108) assigned to deliver the item or may Such information may be obtained, information may be obtained from the merchant (eg, merchant 106) selling the item, and/or other information may be obtained. The service provider 102 can determine the status of delivery of the item and transmit the status of delivery to the acquisition device. The status of the delivery may be displayed via the item acquisition interface 120(b). The status is determined upon request from the acquisition device (eg, in response to messages sent via one or more APIs 114), periodically, and/or upon the occurrence of another event. , and/or provided to the acquisition device. As shown in FIG. 1, item retrieval interface 120(b), when selected, displays the current location of the assigned third party service device, the route traveled by the assigned third party service device, A button 126 may be included to display a map showing routes, etc. that may be further taken by the assigned third party service device to pick up or deliver the item.

In the example of FIG. 1, shipping service information request 128 represents communications sent by the acquisition device to service provider 102 via one or more APIs 114, while shipping service information 130 describes how the order is ordered. service providers, such as consensus calls to indicate how concurrent order requests will be handled, fraudulent requests, delivery times, seating charts, and other information for merchants to schedule and organize operations; 102 represents the communication sent back to the capture device. The delivery service information request 128 may include information regarding the delivery of the item (e.g., cost estimate, delivery time estimate, etc.), indication of acceptance/rejection of the delivery offer, request for information regarding delivery status, and the like. can. Shipping service information 130 may include shipping offers, information about the shipping status of items, and the like.

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

Service provider 102 may additionally or alternatively perform processing to manage third party services. 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 an item, and provide status information regarding delivery (eg, whether the item has been picked up or dropped off). confirmation from a third-party service, such as In exemplary environment 100, service provider 102 receives an indication of acceptance of a delivery offer or recommended offer from an acquisition device and selects a third party service to deliver the item. The service provider 102 can identify multiple third party service locations 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 can then send a delivery request 134 to the third party service 108 requesting delivery of the item, and in response the third party service 108 provides an indication of acceptance or rejection of the delivery request ( indicators, indications) can be sent.

In some cases, service provider 102 may allow any party within environment 100 to make payments. For example, service provider 102 may have funds from an account associated with user 104 transferred to an account associated with merchant 106 as payment for an item. Additionally, funds may be transferred from an account associated with service provider 102, merchant 106, and/or user 104 to an account associated with third party service 108 for shipping items. Payments to the service provider 102 can also be made to facilitate the transaction.

As noted above, service provider 102 may communicate with one or more card payment network computing devices 110 to conduct transactions electronically. One or more card payment network computing devices 110 may be associated with a card payment network (eg, MasterCard®, VISA®, etc.). Service provider 102 may also communicate with one or more bank computing devices 112 of one or more banks. For example, service provider 102 may communicate with acquiring banks, issuing banks, and/or banks that maintain user accounts for electronic payments.

The merchant bank may be a registered member of a card association (eg, Visa®, MasterCard®, etc.) and may be part of a card payment network. A card-issuing bank may issue a payment card to a user and may pay a merchant bank for purchases made by a cardholder for whom the card-issuing bank has issued a payment card. Thus, in some examples, the merchant bank's computing device may be included in the card payment network and may communicate with the card-issuing bank's computing device to obtain payment. Additionally, in some instances, a 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 communicate regarding transactions in which the user is participating. can be received. Additionally, there may be other financial institution computing devices involved in some types of transactions or alternative system architectures, so the above are just a few examples for the purposes of discussion.

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

As noted above, computing devices of architecture 100 may communicate via one or more networks 118 . The one or more networks 118 can be any type of network, such as a local area network or a wide area network such as the Internet, a wireless network such as a cellular network, a local wireless network such as Wi-Fi, and/or It may include short-range wireless communications such as Bluetooth® and Bluetooth® Low Energy, wired networks, or any other such networks, or any combination thereof. Accordingly, one or more of networks 118 may include wired and/or wireless communication technologies, including not only wired or fiber optic technologies, but also Bluetooth®, Bluetooth® Low Energy, Wi-Fi, and cellular communication technologies. Both techniques can be included. The components used for such communication may depend, at least in part, on the type of network, the environment chosen, or both. As a result, one or more computing devices of architecture 100 may be communicatively connected to one or more networks 118 in any manner, such as wired or wireless connections.

The techniques described herein may be implemented in various contexts and/or in various manners. As an example, the technology may be implemented using merchant-facing components (eg, applications, online sites, interfaces, etc. designed for merchants). In this example, a merchant 106 can place an order for a customer. Specifically, the customer may enter the premises of the merchant 106, call the merchant 106, send the merchant 106 a notification (eg, email, text message, social media post, etc.), or otherwise communicate with the merchant 106. can communicate with The merchant 106 interacts with a merchant-facing component (eg, an item acquisition interface 120 designed for use by the merchant) to select items identified by the customer and/or other information provided by the customer. (eg, shipping address, etc.) can be entered. Once the shipping offer is received from the service provider 102, the merchant 106 can communicate the information of the shipping offer to the customer (e.g., the shipping cost to the customer from the item acquisition interface 120 displaying a screen with the shipping cost). , send notifications, etc.). Alternatively, the merchant 106 may refrain from providing 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 (eg, not itemize), and so on. In any event, the merchant 106 can accept or reject the shipping offer and/or order the item based on the communication from the customer.

As another example, the technology may be implemented using customer-facing components (eg, applications designed for customers, online sites, interfaces, etc.). In this example, a customer can place an order directly with merchant 106 . Specifically, a customer may navigate to an online site associated with merchant 106 , open an application (e.g., desktop application, mobile application, etc.) associated with merchant 106 and place an order with merchant 106 . . In some instances, the customer may see shipping information during processing (e.g., shipping costs, estimated amount of time for shipping, etc.), while in other instances, the information may not be shown to the customer. , or other information (eg, total cost of the order). In addition, the customer can view shipping status updates via the customer facing component.

As yet another example, the techniques 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 can be set such that the delivery offer is automatically accepted/rejected if one or more of the criteria are met. Illustratively, a delivery offer can be: if the cost of delivery is below (or above) the threshold cost, if the estimated amount of time for delivery is below (or above) the threshold amount of time, if the estimated pickup time for delivery is before (or above) a certain amount of time (or later), it may be accepted (or rejected), such as when the estimated drop-off time for delivery is before (or after) a certain time. Thus, in some cases, information regarding shipping may not be displayed via the item retrieval interface 120 .

Similarly, in the case of a reservation, a reservation request may be made via an API call, by a merchant via a merchant device, by a customer via a customer device, by a third party device through settings made by the merchant or the customer, or It may be initiated automatically through a consensus service based on machine learning of transactions between merchants and customers. Content harmonization requests, such as pushing customized menus or harmonizing menus across different services, for content aggregation and analysis, content requests via API calls, by merchants through merchant devices, through customer devices It may be initiated by the customer, by a third party device through settings made by the merchant or the customer, or automatically through a consensus service based on machine learning of transactions between the merchant and the customer.

FIG. 2 shows exemplary details of service provider 102 (or service provider 116, as the case may be) of FIG. Service provider 102 may be implemented as one or more computing devices such as servers, laptop computers, desktop computers, and the like. One or more computing devices may be configured in a cluster, farm, data center, cloud computing environment, or combinations thereof. In one example, one or more computing devices provide cloud computing resources, including computing resources, storage resources, and the like. One or more computing devices of 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), graphics processing unit (GPU), microprocessor, digital signal processor, or the like.

Memory 204 may include software functionality organized as one or more "modules." The term "module" is intended to represent an exemplary division of the software for purposes of discussion, and is not intended to represent any type of requirement or required method, manner, or required 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 and more modules). divided into modules, etc.). Furthermore, although 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 are implemented by hardware logic components. May be implemented (eg, performed) in whole or in part. For example, without limitation, exemplary types of hardware logic components that can be used include Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Program Specific Standard Products (ASSPs), These include system-on-chip systems (SOCs), complex programmable logic devices (CPLDs), and the like. As shown, memory 204 can include consensus service 207 , recommendation module 208 , content aggregation module 210 , third party service module 212 , and payment transaction module 214 .

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

Recommendation module 208 may perform processing to generate offers, such as delivery offers, for delivery of items by delivery services associated with service provider 102 . Another type of offer may be a reservation offer showing a reservation for the user's reservation at a restaurant, or a seating chart 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, information 130 flows from the merchant device to the third party service, running on user device 104, for example. Service providers 102 often receive requests for delivery offers via one or more application programming interfaces (APIs) 216, and in response generate a delivery offer and send the delivery offer to the requesting entity. can do. The information included in the request for delivery proposals is described in more detail below with reference to FIG. The recommendation module 208 uses information contained in the request for a shipping offer, the status of the merchant's current or past orders, preparation times, and information about third party services stored in the third party service information data store 218 or elsewhere. (e.g., third party service current location, third party service profile information, third party data related to orders processed, order timing, order lag, etc.), stored in merchant data store 220 or elsewhere. A shipping offer can be generated based on information about the merchant (eg, current location of the merchant, merchant profile information, etc.), information about the user (eg, current location of the user, user profile, etc.), and the like.

Third Party Service Profile Information includes (i) Third Party Service delivery history information that indicates the average time for the Third Party Service to make a delivery (e.g., average time per mile, total average travel time, etc.); (ii) information indicating whether the third party service will be on time for delivery pickup and/or drop off; (iii) indicating the vehicle or type of vehicle that the third party service will use to transport the item; vehicle information (e.g., motorcycles, cars, vans, trucks, etc.); (iv) historical location information indicating where the Third Party Service is generally located (e.g., home address; facilities located above), etc.

Merchant profile information may include (i) the amount of time (e.g., exact, average, estimated, etc.) to prepare (e.g., cook the item, manufacture the item, etc.) the item or type of item for pickup; (ii) item information about the item that the merchant provides for acquisition (e.g., item identifier, information about item cost/weight/volume/size/category, etc.); (iii) to transport the item; Information about the packaging used by the merchant (eg, shipping box size, shape, weight, volume, etc.) is included.

Exemplary information that may be part of a delivery offer includes:
Item delivery cost - the price for using the service provider's 102 delivery service to deliver the item (e.g., 6 for a third party service to pick up food from a restaurant and deliver it to the customer's location). dollar fee). Shipping costs are determined by item characteristics, such as item size, shape, weight, volume, type, etc. (e.g., larger or heavier items may cost more, oddly shaped items (items that have fragile items) may cost more, fragile (fragile) items may cost more than non-vulnerable items), information about third-party services (e.g., cost may vary from third-party service to pickup 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., as preparation time decreases (or increases) pick-up location (e.g., cost may increase as the distance from a particular point to the pickup location increases); drop-off location (e.g., cost may increase (or decrease) from a particular point); may increase as the distance to the drop-off location increases), time of day (eg, costs may increase during peak delivery times such as in the evening), and other factors.
• Amount of time for delivery of the item (eg, estimated amount of time - delivery takes 20-30 minutes). The amount of time may generally be the time for the third party service to retrieve the item and transport it to the drop off location. However, in some examples, the amount of time can include the time to prepare the item by the merchant (e.g., the amount of time is the total time from ordering the item to its arrival at the customer's location). can include). The amount of time for delivery depends on the characteristics of the item, such as the size, shape, weight, volume, type, etc. of the item (e.g., larger or heavier items may take more time to deliver, unusual Shaped items (items with a given shape may take longer to deliver, fragile (fragile) items may take longer than non-fragile items), third party services (e.g., the amount of time for delivery may increase as the distance from the third party service to the pickup location increases; the amount of time for delivery may increase as the number of available third party services decreases; may increase, etc.), time of day (eg, the amount of time may increase during peak travel times, such as during rush hour), and other factors.
• Pick-up time for delivery of the item (eg, estimated day, week, month, year, etc., when 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 (eg, 2-2:30 PM). Additionally, in some cases, the delivery offer may include a deadline for the latest time for the third party service to pick up the item. Pickup times are information about the third party service (e.g., pick up times may move further away as the distance from the third party service to the pick up location increases, pick up times may vary from available third party may vary based on factors such as time of day (e.g., pick-up times travel further afield during peak delivery times such as rush hours), etc.
- The drop-off time for delivery of the item (eg, the estimated time of day, week, month, year, etc., when the third-party service will drop the item off). The drop-off time may be when the items are dropped off at the customer's location. In some cases, the drop-off time is a time window (eg, 3-4 PM). Drop-off time is based on item characteristics such as item size, shape, weight, volume, type, etc. (items with the shape of a Times may move further away as the distance from the 3rd party service to the pickup location increases, drop off time may move further away as the number of available 3rd party services decreases. ), time of day (eg, drop-off times move further away during peak delivery times, such as during rush hours), and other factors.
● When the shipping offer expires. In some cases, a delivery offer may expire if it is not accepted by a certain time (eg, time of day, day of week, month, year, etc.). Thus, a delivery offer may be associated with an expiration time (eg, 2:00 pm tomorrow, 2 hours from receipt of the delivery offer, etc.).
● A third party service that can provide an order, for example, if the third party service with which the order was placed is not possible due to carrier or other technical difficulties.
● A sequence of items for a kitchen display system. Items are ordered either by order ID or item ready time to allow a merchant to keep a single tablet for orders from different sources.
• A preparation or delivery timeline for the kitchen display system to show order updates to third party services.

The content aggregation module 210 can provide analytics information based on the aggregated data, such as menu updates, delivery information regarding delivery progress, reservation lists, and the like. For example, the content aggregation module 210 can receive requests for delivery status updates via one or more of the APIs 216 and, in response, generate information regarding the delivery status and send the information to the requesting entity. In other examples, such information regarding the status of shipping may be generated and transmitted automatically and/or upon the occurrence of another event. The Content Aggregation Module 210 provides an indication from the third party service regarding the location of the third party service, confirmation of pick-up of items at the merchant's location and/or drop-off at the customer's location, confirmation of pick-up. Information about the status of the delivery can be generated based on a variety of information, such as communications from merchants indicating the status of the item, communications from merchants about the status of preparing the item (e.g., amount of time left to cook the food). . Accordingly, the content aggregation module 210 may communicate with the third party services module 212 to receive location information regarding the shipper.

Third party services module 212 may manage third party services. For example, the third party services module 212 tracks the location of the shipper associated with the third party service (before, during, and/or after delivery) and selects the third party service for delivery. , communicate with the Third Party Service to facilitate deliveries, provide updates on delivery status, estimate travel times for the Third Party Service to various delivery locations at various times and/or days of the week, etc. can be done. To do so, the third party service module 212 retrieves the information included in the request for a delivery offer, the information included in the request for a delivery status update, the third party service information stored in the third party service information data store 218 or elsewhere. information about merchant services (e.g., current location of third-party services, third-party service profile information, etc.), information about merchants stored in merchant data store 220 or elsewhere (e.g., current location of merchant, merchant profile information; etc.), information about the buyer (eg, the buyer's current location, user profile, etc.) can be analyzed. In some examples, third party service module 212 can manage third party services through activation, movement, positioning, and/or deactivation, eg, through an API.

As an example, the third party services module 212 can select third party services to facilitate the shipper's transfer of items from the merchant to the buyer. In some cases, the third party service is selected in response to receiving acceptance of the delivery offer via one or more APIs 216 . In other examples, delivery is arranged in response to the occurrence of other events. The third party service module 212 can determine the location of the third party service relative to the merchant's location (e.g., select the third party service closest to the pickup location), the availability of the third party service (e.g., the first available select a third-party service), the type of vehicle used by the third-party service to transport the item (e.g., select a third-party service that can transport that type of item being shipped); Various information can be used to select a third party service, such as information about the item being shipped (eg, size, shape, volume, type, etc.). The third party service module 212 can then communicate with the selected third party service to arrange delivery. The service provider 102 may provide information regarding the number of items to be transferred, the location of the merchant (or multiple merchants if multiple items are to be delivered), requested pick-up and/or drop-off times, and the like. can. If it is determined that multiple trips are required for delivery (for example, due to the number of items being shipped, the size of the items being shipped, the transfer capacity of the Third Party Service, etc.); , the third party services module 212 can notify third party services of multiple movements and/or send instructions to multiple third party services to make deliveries. In addition, the third party service module 212 notifies the third party service of deliveries that are not urgent and may be performed during downtime periods when less than the 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 anytime this week"), or the third party service can notify one As time is available throughout the day, week, etc., deliveries can be made. In many cases, the third party service module 212 communicates with the third party service through non-API and/or separate channels rather than one or more APIs 216 used to expose delivery services to entities.

Payment transaction module 214 may facilitate payment transactions between merchants, users, and/or third party services. For example, trading module 214 may receive orders for trading, process trades, generate and/or store trade information for trades, and so on. During a transaction, a user (eg, customer) can obtain items from the merchant by purchasing, renting, leasing, borrowing, licensing, and the like. Items can refer to goods and/or services offered by a merchant. When paying for a transaction, the user can provide the payment amount due 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, transaction module 214 may be implemented by one or more computing devices configured to conduct secure electronic financial transactions.

Payment transaction module 214 can facilitate payment transactions initiated through various channels. As an example, a user may 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 (eg, notify the merchant that the order has been placed, request 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 (eg, text message, email, social media, etc.), etc. to indicate to the merchant that they would like to place an order. In any of these examples, the user can provide payment at any time, such as when ordering, while the item is being delivered, or at drop-off (eg, interacting with a third party service device).

Users can provide payment via a variety of methods such as cash, check, payment card, Near Field Communication (NFC), Bluetooth®, account, electronic payment, and the like. In some examples, payment transaction module 214 enables cardless payments for transactions between users and merchants based on interactions between users and user devices and between merchants and merchant devices. . Thus, in some examples, cardless payment transactions can include transactions conducted at a POS location, during which a user's electronic payment account is stored only when the user physically presents a payment card to a merchant at the POS location. charged without having to. As a result, the merchant does not need to receive details regarding the user's financial account for transactions to be processed. As an example, electronic payments may be charged to the credit card issuer or credit card number provided by the user when signing up with service provider 102 for an electronic payment account. As another example, a user may have prepaid amounts in an account maintained for use in making electronic payments. Other variations will be apparent to those skilled in the art.

In some cases, payment transaction module 214 may store transaction information in transaction information data store 222 . Transaction information may be received from merchant devices, buyer devices, third party service devices, and/or generated by service provider 102 . Transaction information may include information about the time, place, and/or amount of the transaction, information related to the item acquired (e.g., information identifying the item sold), type of payment used (e.g., cash, checks, payment cards, electronic payments, etc.), as well as additional information such as buyer information. For example, if a payment card is used, the transaction information may include data stored on the payment card (eg, Track 1 data (cardholder name, card number and other card information)). Additionally, when completing a transaction, the buyer can sometimes provide a receipt e-mail address for receiving receipts via e-mail. Other examples of transaction information that can be captured include item information (e.g., itemized list of items being acquired, price paid for each item, item description (size, flavor, color, etc.); Geolocation data indicating the geographic point of sale (POS) location of a particular transaction, online/offline card data, data describing merchants (e.g., merchant identifiers, merchant category codes (MCC), etc.), requests for delivery offers information included in a delivery offer, information included in a shipping offer, any type of data received upon authenticating a buyer to a social network, and/or various other types of information. In some examples, the transaction information may be used to store information about the merchant in the merchant data store 220 (e.g., the cost of items offered by the merchant may be stored in the transaction information for transactions at the merchant's premises). may be obtained from).

Although FIG. 2 depicts the components and data of service provider 102 as residing in a single location, these components and data may alternatively reside on different computing devices and/or different locations in any manner. It can be distributed over locations. As a result, the functions may be implemented 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 collocated together or separately and organized as, for example, virtual servers, server banks, and/or server farms. The functionality described may be provided by a single entity or company's server, or may be provided by multiple different buyers' or companies' servers and/or services.

FIG. 3 shows exemplary details of merchant device 300 . For example, merchant device 300 may be used by merchant 106 of FIG. The merchant device 300 may be a laptop computer, desktop computer, server, smart phone, electronic reader device, mobile handset, personal digital assistant (PDA), portable navigation device, portable gaming device, tablet computer, wearable computer (e.g., smartwatch, optical head-mounted displays (OHMD), portable media players, televisions, set-top boxes, in-vehicle computer systems, appliances, cameras, robots, hologram systems, security systems, home-based computer systems (e.g., intercom systems, home media system), projector, automated teller machine (ATM), and the like. In some implementations, merchant device 300 may perform third party services such as delivery services, reservation services, menu services, review services, and the like. 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 API endpoints for communicating with third party services and merchant devices 300, and API endpoints may provide API endpoints 114 for service providers to access. , do not have to. Accordingly, the service provider's consensus service 207 may be able to pull, push, or push and pull data from external services.

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

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 can include a central processing unit (CPU), graphics processing unit (GPU), microprocessor, digital signal processor, or the like. The one or more displays 308 may include a touch screen, liquid crystal display (LCD), light emitting diode (LED) display, organic LED display, plasma display, electronic paper display, or any other type of technology. Although not shown, merchant device 300 may include or be associated with other components such as cameras, microphones, speakers, projectors, printers, 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, compass, gyroscope, magnetometer, global positioning system (GPS), olfactory sensor (eg, for smell), or another sensor. Merchant device 300 may further include or be associated with a keyboard, mouse, pen, voice input device, touch input device. Memory 304 may include merchant module 310 and location module 312 .

Merchant module 310 (and/or location module 312) may represent a merchant facing component that may be used by merchants in general. In some examples, the customer may interact with the merchant facing component (eg, to confirm payment, provide shipping information, or provide other input). The merchant module 310 may perform various operations to help merchants facilitate transactions with customers, manage deliveries, manage inventory, and the like. Merchant module 310 may provide various interfaces and/or dashboards. In some cases, merchant module 310 may be referred to as an application, such as a retrieval application for delivery orders, pre-orders, and menu updates/preferences.

The merchant module 310 can communicate with the service provider 102 to use shipping services provided by the service provider 102 . As an example, a merchant may interact with an item acquisition interface provided by merchant module 310 (eg, item acquisition interface 120) to place an order for a customer. If the merchant module 310 determines that shipping may be requested (e.g., an automated determination based on the customer indicating that the order is desired to be shipped), the merchant module 310 generates a request for a shipping offer and sends a request to the service provider. A request can be sent to service provider 102 via one or more APIs to request information regarding the use of shipping services recommended by 102 . Request information may be provided by a customer or merchant, or obtained from a data source (eg, user profile, merchant profile, etc.). Exemplary information that may be part of a request for a delivery offer includes:
● Item Pickup Location - The location where the item is picked up from the merchant for delivery to the customer. Pick-up locations may generally be merchant locations (eg, facilities), but any location may be used, such as warehouses, residences, PO boxes, street corners, and the like. The pick-up location may be stationary or mobile (eg, for mobile merchants).
• Drop-off location (also called delivery location) - the location where items are delivered to the customer. The drop-off location can generally be the customer's location, such as a residence, PO box, street corner, facility where the customer is currently located. The drop-off location may be stationary or moving (eg, for moving customers).
● Requested Pickup Time - The time, week, month, year, etc., to obtain the item from the merchant for delivery. The requested time of pickup may be a specific time, a window of time, or the like. In some cases, the requested pick-up time may be as soon as possible (eg, if the item has already been made, or in other circumstances). If no pickup time is specified in the delivery offer request, service provider 102 may, for example, assume that the pickup time is as soon as possible.
● Quantity (number) of items acquired - The amount of items purchased from the merchant. In some cases, service provider 102 can use this information to determine the size of the order (eg, the amount of space required to transport the order).
● An item identifier that identifies the item to be retrieved. In some cases, service provider 102 uses this information to determine how much space is required to transport the order, the type of vehicle required to transport the item, the type of item (e.g. Information about items can be looked up to determine vulnerable versus non-vulnerable, corrupt versus non-corrupt, etc.).
• Characteristics of the item to be retrieved (eg, size, shape, weight, volume, type, category, etc.). In some cases, service provider 102 can use this information to determine the amount of space required to transport the item.
● Tags associated with the item being retrieved (eg, tags that indicate a particular category). For example, an item may be tagged with a predetermined label associated with a food category that requires special handling for delivery (e.g., a pizza that needs to be kept warm and/or upright or catered meals such as soups, food on trays that require special handling, televisions that need to be handled with care, etc.). In some examples, service provider 102 uses this information to determine how much space is required to transport the order, the type of vehicle required to transport the item, the type of item ( For example, vulnerable versus non-vulnerable, corrupt versus non-corrupt, etc.).
● the price of the order (eg, the cost of the item or order);
● Pick-up instructions for items. For example, a merchant may specify that a bicycle be picked up for delivery at the back of the store.
● Shipping 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 (eg, phone number, email address, customer geographic location, 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 a shipping offer, in some cases the information may be (at least partially) determined at the service provider 102 (e.g., the service provider 102 may receive the item identifier and look up the item size, usage, etc.).

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

Merchant module 310 may then communicate with 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 sends information indicating where the item is in the preparation process (e.g., nearly done, done, ovened, bagged, ready for pickup, etc.). do. In another example, the merchant module 310 can determine the status of the delivery by the shipping service (e.g., the particular location of the third party service's shipper, how far away the third party service is, whether the item is being dropped off, etc.). , whether the courier associated with the third party service is being transported to the pickup location, etc.) may be received from the service provider.

The merchant module 310 can receive orders through various channels. For example, the merchant module 310 distinguishes between a first order placed by a 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 the customer application. can receive. A second order may be received from another party, such as service provider 102 and/or a service provider associated with the merchant. In any event, orders may be managed by the same merchant module 310 via the service provider's API. That is, the merchant module 310 can monitor the preparation of the order, the presentation of information regarding the progress of the preparation of the order, the presentation of information regarding the delivery status of the order, and the like. Information about an order is often presented through an interface with information that designates the order as originating from a different channel.

Merchant module 310 may apply one or more schemes to provide payment for shipping services used by service provider 102 . As an example, shipping costs for using the shipping services of service provider 102 may be billed to the customer (eg, directly per item, per month, etc.). As another example, the merchant may, in each instance, or for example, order with more than a threshold number of items, order with more than a threshold quantity, a customer is associated with a particular status (e.g. decide to offer payment for shipping costs, such as when one or more criteria are met, such as paying a monthly subscription fee for a service or purchasing a certain number of items over time; (e.g., do not charge the customer).

A merchant can be billed by the service provider 102 for use of the consensus service that connects several delivery services in various ways, such as on a monthly, item-by-item basis, and should be paid to the merchant by the service provider 102. Balance the amount (eg, subtract the cost of the delivery service from the amount the service provider 102 should pay the merchant).

Merchant module 310 may additionally or alternatively perform other processing. In one example, the merchant module 310 accepts payment from the customer (eg, via a card reader, NFC connection to the customer device, Bluetooth connection to the customer device, etc.), provides a receipt for the item. (including printing receipts), receiving input from the customer for items acquired by the customer (e.g., confirmations, credit card signatures, etc.), etc. can be made easier. In another example, the merchant module 310 notifies the merchant of inventory levels (eg, number of items currently in stock), orders additional inventory, and views notifications from the service provider 102 regarding inventory. , offering inventory to others for acquisition, seeking financing for inventory, etc., to enable merchants to manage inventory. In yet another example, merchant module 310 can provide data analysis for sales, inventory, or other information.

Although the functionality of 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, functionality may be divided into separate applications and they may be linked together (eg, accessing one application by selecting a link within another application).

Location module 312 may determine the location of merchant device 300 . In some cases, the location is provided to the service provider 102 or used locally to determine the merchant's location, process transactions when the customer is within a particular proximity of the merchant device 300, and various other purposes. functions. The location module 312 determines the geographical location of the merchant device 300 from geolocation technologies (eg, satellite-based systems—Global Positioning System (GPS)), cell tower location data, wireless access point location data, radio beacon locations, etc.). can judge. Accordingly, the location module 312 utilizes data from a location sensor of the merchant device 300, such as a GPS receiver or communication interface that can determine the geographical location of the merchant device 300 (e.g., from cell towers or wireless access points). be able to.

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 typically does not change from day to day. However, in other types of businesses, the merchant device 300 may be used when the merchant operates a food truck, is a street vendor, cab driver, etc., or otherwise has a mobile business (e.g., buyer's home, Locations may change from time to time, such as when a merchant sells items at a business location.

FIG. 4 shows exemplary details of user device 400 . For example, user device 400 may be used by user 104 in FIG. User devices 400 include laptop computers, desktop computers, servers, smart phones, electronic reader devices, mobile handsets, personal digital assistants (PDAs), portable navigation devices, portable gaming devices, tablet computers, wearable computers (e.g., smart watches, optical head-mounted displays (OHMD), portable media players, televisions, set-top boxes, in-vehicle computer systems, appliances, cameras, robots, hologram systems, security systems, home-based computer systems (e.g., intercom systems, home media system), projector, automated teller machine (ATM), and the like. In some examples, merchant device 300 may be a mobile device. In one implementation, user device 400 can perform third party services such as delivery services, reservation services, menu services, review services, and the like. In one embodiment, user device 400 may interface with merchant services, such as merchant device 300 , via one or more consensus services 207 . In one example, a service provider provides API endpoints 114 for communicating with third party services and merchant devices 300, and API endpoints 114 may provide API endpoints for service providers to access. may or may not. Accordingly, the service provider's consensus service 207 may be able to pull, push, or push and pull data from the user device. Third party services can be hosted on third party servers, for example similar to service providers.

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 can 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, liquid crystal display (LCD), light emitting diode (LED) display, organic LED display, plasma display, electronic paper display, or any other type of technology. Although not shown, user device 400 may also include or be associated with other components such as cameras, microphones, speakers, projectors, printers, 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, compass, gyroscope, magnetometer, global positioning system (GPS), olfactory sensor (eg, for smell), or another sensor. User device 400 may further include or be associated with a keyboard, mouse, pen, voice input device, touch input device. Memory 404 may include customer module 410 and location module 412 .

Customer module 410 (and/or location module 412) may represent customer-facing components that may be used by customers in general. In some examples, a merchant may interact with the customer-facing component (eg, to confirm payment, provide shipping information, or provide other input). Customer module 410 may perform various operations to assist customers in facilitating transactions with merchants. In doing so, customer module 410 may provide various interfaces and/or dashboards. In some examples, customer module 410 may be referred to as an application, such as an item retrieval application. Further, in some examples, the customer module 410 is a local application that works in collaboration with a service provider associated with the merchant, such as a third party application 407, such as a delivery service, to order pizza from the pizza merchant. can be provided.

Customer module 410 can communicate with service provider 102 to use shipping services associated with service provider 102 . As an example, a customer may interact with an item acquisition interface provided by customer module 410 (eg, item acquisition interface 120) to place an order with a merchant. If the customer module 410 determines that shipping may be requested (e.g., automatic determination based on user profile settings or previous purchases, determination based on customer input indicating that they want the order shipped, etc.), the customer module 410 will: Requests may be sent to service provider 102 via one or more APIs to generate a request for delivery offers and to request information regarding the use of delivery services offered by service provider 102 . Information for the request may be provided by the customer or obtained from a data source (eg, user profile, etc.). In many cases, the customer module 410 provides the information included in the request for a shipping offer, but in some cases the information may be (at least partially) determined at the service provider 102 (e.g., the service provider 102 may receive item identifiers and research item size/usage, service provider 102 may identify customers, research customer preferences, etc.).

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

Customer module 410 may also communicate with service provider 102 via one or more APIs to request and/or receive information regarding the status of transactions. For example, the customer module 410 may indicate the status of item preparation (e.g., almost complete, completed, in oven, bagged, ready for pickup, etc.), status of delivery by the shipping service (e.g., Information may be received regarding the specific location of the courier, how far the courier is, whether the item has been dropped off, whether the courier is in transit to the pickup location, etc.). Such information can be presented to the customer. In one example, a map is displayed to the customer with an icon or other element indicating the location of the courier. Additionally or alternatively, advertisements may be displayed. By way of example, customer module 410 may display advertisements for online sites related to shipping items for merchants. Advertisements can encourage customers to use the online site for future orders instead of ordering directly from the merchant. In other diagrams, any type of advertisement can be displayed.

Customer module 410 may additionally or alternatively perform other processing. As an example, the customer module 410 can provide the user with information regarding merchants within a predetermined proximity range via the interface. A user can select a merchant and order goods with the merchant. Additionally or alternatively, the customer module 410 allows a user to provide payment for an item (eg, via a card reader, NFC connection to a merchant device, Bluetooth® connection to a merchant device, etc.), to receive receipts for In addition, customer module 410 may allow users to check-in with merchants to perform cardless payment transactions.

Location module 412 can determine the location of 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 proximity of a merchant device. do. The location module 412 extracts the geographic location of the user device 400 from geolocation technologies (eg, satellite-based systems—Global Positioning System (GPS)), cell tower location data, wireless access point location data, radio beacon locations, etc.). can be determined. Accordingly, the location module 412 utilizes 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 (eg, from cell towers or wireless access points). be able to.

In some implementations, the user device 400 is also configured to receive booking offers in response to booking requests triggered automatically via the user device 400, the merchant device 300, or, for example, via a service provider. be done. A user of user device 400 can accept or reject the booking offer. User device 400 may also provide preferences for the type of seat the user prefers for either current or future reservations. Preferences can also include chefs, items, merchant locations, times of day, alternate merchants, dishes of choice, etc., so that the service provider can, for example, request reservations if a preferred reservation is not available or from a different source. A substitute can be generated for the user if it conflicts with another reservation.

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

Processes 500, 600, and 700 (and each process described herein) are depicted as a logical flow graph, each action of which represents a sequence of actions that may be implemented in hardware, software, or a combination thereof. . In the context of software, an action represents computer-readable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform that action. Generally, computer-readable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be limiting, and any number of the described operations can be combined in any order and/or in parallel to implement processing. Additionally, 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 describes an exemplary process 500 of exposing one or more APIs to enable entities to use third party services in relation to other services offered by service provider 102 .

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

At 504, service provider 102 can receive a request for delivery of the 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 delivery location, pickup location, requested time of pickup, number of items to be retrieved, size of item, whether item is associated with a given category, weight of item, etc. . In some cases, the request is received from an application executable on a computing device associated with the merchant or customer. Requests may be for delivery of any type of item. In one example, the item is a computing device (e.g., tablet, etc.) configured with a merchant application (e.g., a proprietary merchant application that may not be available to the general public) that facilitates acquisition of the item with customers. be able to. Here, the request may seek to ship an item to the merchant in order to onboard (e.g., register) the merchant with the service provider to use purchasing resources provided by the service provider. The purchase resource may be used when the merchant interacts with the shipped computing device. In other examples, the items may be other types of items.

At 506, the service provider 102 can generate shipping offers for item delivery or order scheduling if multiple orders are received from multiple third-party services. The shipping offer 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, and a time limit for delivery of the item. can include an estimated drop-off time, etc. In some cases, the service provider 102 may provide an item (or delivery service) based on the current location of the third-party service, the item's pickup location, the item's drop-off location, the item's estimated preparation time by the merchant associated with the item, and the like. Any other information in the offer) can determine shipping costs. A delivery offer can 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 can send the shipping offer to a computing device, such as a computing device associated with the 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. An indication of acceptance or rejection may be received from the merchant or a computing device associated with the user.

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

At 514, the service provider 102 can identify a third party service among several third party services for transferring the item. Often such identification may be performed in response to receiving an indication of acceptance of the delivery offer. A 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 transfer the item. The communication may request that the associated third party service obtain the item from the pickup location and transport the item to the delivery location. The communication can include various information regarding the delivery, such as information in the request for delivery offer, information in the delivery offer, and the like. Communications may be sent via APIs different than those used to communicate with merchants or customers, via non-API channels, and the like. In some examples, service provider 102 may receive an indication of acceptance from a third party service device instruction that the third party service will deliver the item.

At 518, the service provider 102 can receive the location information and/or the shipping information. Location information and/or shipping information may be received from third party service devices and/or merchant devices. In many cases, such information may be received after delivery has commenced. Location information can generally indicate the location of third party services. Shipping information can 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 was picked up, and the like.

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

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

In some cases, service provider 102 may receive orders through multiple channels or multiple sources, such as third party services. If the order is received via a non-merchant channel (eg, directly from the customer), the service provider 102 can communicate with the merchant and request that the merchant fulfill the order. If accepted by the merchant, the merchant can send an indication of acceptance and the service provider 102 can proceed to facilitate delivery by a third party service. Additionally, the status of deliveries 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 sent to the merchant device or customer device.

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

At 602, the acquisition device can provide an interface, such as the item acquisition interface 120 of FIG. This includes presenting the item retrieval interface via the display. The interface may allow the user to place an order for the item. The interface may also be a kitchen display system that allows the merchant to view the orders, sorted by item in the order in which they should be prepared, so that similar items are displayed in the interior kitchen. Purposes may be aggregated to create new tickets, change flows for items that are no longer available, and so on. The interface can also be a free and unavailable reservation interface that indicates which reservations are reserved and from which sources. The interface may also be an interface of items currently available at the merchant, allowing the merchant to change menus in real time based on availability, popularity, merchant location, and the like.

At 604, the acquisition device can receive a selection of items for acquisition. For example, a user (eg, merchant, customer, etc.) can indicate an intention to purchase the item from the merchant by placing the item in an electronic shopping cart. In some cases, the user may provide other information such as delivery location, pickup location, pick-up requested time, number of items retrieved, size of item, whether item is associated with a given category, weight of item, etc. can also be provided. In other examples, such information may be determined automatically. Other types of information requested may be requests for order matching, requests for order sequencing, or requests for order consensus triggered by the merchant or automatically by the server.

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

At 608 , the acquisition device can send a request for delivery of the item to service provider 102 via one or more APIs associated with service provider 102 . The request may request a delivery offer. In some cases, the request may specify delivery location, pickup location, requested time of pickup, number of items to be retrieved, size of item, whether item is associated with a given category, weight of item, etc. can be shown. Delivery offers may also include booking offers, how booking quotas are distributed among the Third Party Services, how acceptance or delivery of orders is distributed among the Third Party Services, and information received from the Third Party Services. including how orders placed are ordered and how updates to orders such as menu updates, order updates, etc. are sent or received.

At 610 , the acquisition device can receive a delivery offer from service provider 102 . A shipping offer may include a cost for shipping the item by a shipping service associated with the service provider 102, an estimated amount of time for shipping the item, an estimated pick-up time for shipping the item, and an estimated drop for shipping the item. Off time and the like can be indicated.

At 612, the acquisition device may determine whether the delivery offer is accepted or rejected. In some examples, the acquisition device displays information contained within the delivery offer (e.g., cost for delivery of the item, estimated amount of time for delivery of the item, etc.) and accepts user input regarding acceptance of the delivery offer. can be received. In other examples, the acquisition device can automatically determine whether to accept or reject a delivery offer when one or more criteria are met. Accordingly, the acquisition device may refrain from displaying the information of the delivery offer in some cases.

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

At 616, the acquisition device can perform delivery status processing. For example, the acquisition device may send a request for the delivery status of the item via one or more APIs associated with service provider 102 . The acquisition 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 the third party service picked up the item) and the status of the delivery is sent to the customer device. good too.

FIG. 7 illustrates an exemplary process 700 for notifying a third party service or merchant device regarding item delivery, available/conflicting seat reservations, menu updates, and the like.

At 702, a third party service device can determine a geographic location of the third party service device, such as a user device. Geographic location is based on data from location sensors of third party service devices, such as satellite-based sensors (e.g., global positioning system (GPS), cell tower radios, wireless access point radios, radio beacon location sensors, etc.) may be determined by

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

At 706, the third party service device can receive a communication from the service provider 102 regarding delivery of the item. For example, a communication may include a request for a third party service associated with third party service device 500 to obtain an item from a merchant and transport the item to a customer. The request may specify a time frame for delivery (e.g., delivery time), number of items to be delivered, route of delivery, merchant location, 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 shipped (eg, obtained from the merchant's facility and transported to the shipping location). Notifications may be presented via displays, speakers, and the like. In some cases, the information is provided by a third-party service interface that facilitates delivery of the item (e.g., that the third-party service accepts delivery, confirms that delivery has taken place, requests additional delivery, etc.). displayed via an interface that enables Third party service device 500 may 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 send 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 sends a communication to the service provider 102 indicating that such task has been accepted. can do.

FIG. 8 illustrates an exemplary process 800 for communicating via one or more APIs exposed by service providers to provide status updates regarding orders. 8, elements shown at the bottom of FIG. 8 (below the lines established by one or more service provider APIs 802) can represent operations performed by a service provider, such as service provider 102. In FIG.

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

A customer may use computing device 801 to generate an order or order request. Accordingly, third party services 108 running on computing device 801 can be used to trigger such orders. A third party application, such as third party application 108, interfaces with service provider 102 by delivering a status update endpoint, or API endpoint 819, to provide details of order 826, from where the order was received. Get how it is scheduled in the list of orders, the status of preparation and delivery 824, etc. A service provider may also schedule an order to be shipped by a different company than the one used to place the order, for example, based on the user's proximity to a shipper belonging to another shipping company. .

A computing device 802 associated with the merchant is also shown. The left side of the user interface 806 displays a relatively high-level view of all orders (or a certain number of orders) placed with the merchant regardless of the channel through which the orders are placed (e.g., phone, customer application, website, etc.). Information can be displayed. Meanwhile, the right side of the user interface may display more detailed information about the selected order or orders. The left and right sides of user interface 806 are separated by line 808 . User interface 806 may be the interface of a kitchen display system where the service provider pushes real-time notifications or updates from orders received from multiple sources. Interface 806 also lists orders as scheduled by service provider 102 and helps manage 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 order by obtaining fulfillment information and determining the location of the third party service assigned to each of the merchant's (Company A's) orders. At 814 , the service provider can generate details about the status and send the details to 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 user interface 806 , such as order 816 , more detailed information specific to that order may be displayed on the right side of user interface 806 . In particular, as shown at 818 , computing device 804 may request additional status information regarding selected order 816 . At 820, the service provider can determine the status of the selected order by obtaining historical information and determining the location of the third party service assigned to the selected order. At 822 , the service provider can generate details about the status and send the details to computing device 804 for display via the right side of user interface 1206 . In some cases, the details displayed on the right may be more specific than the details displayed on the left. As such, merchants often see status information for orders placed through various types of channels.

In some examples, box 810 represents an API for obtaining status information about all of a merchant's orders (or a certain number of orders) that are currently being delivered by the service provider's delivery service. Box 818, on the other hand, may represent an API for obtaining status information for a merchant's particular order that is currently being delivered by the service provider's delivery service.

In some examples, this application discloses a system for providing optimized order scheduling, the system storing one or more processors and instructions executable by the one or more processors. and one or more non-transitory computer readable media, the instructions executing a first order from a first customer facing order application by an order scheduling application executing on a point of sale device associated with the merchant. receiving, the first order including one or more menu items prepared by the merchant for delivery to the address provided by the first customer-facing ordering application; sending by the first shipping application to the merchant's computing device an estimated pick-up time indicating the time the first shipping application estimates the arrival of the shipper or customer to pick up the first order; Determining a predicted pick-up time indicating an estimated time when the first order may be picked up by a delivery person or customer based on past orders associated with the first customer-facing application; and a second customer. Receiving a second order from the face-to-face ordering application, the second order including one or more menus prepared by the merchant; sending to the device an estimated pick-up time indicating the time the second shipping application estimates the arrival of the courier or other customer to pick up the second order; Determining a predicted pick-up time based on the order indicating when the delivery person or customer may pick up the second order; Generating an ordered list of orders based at least in part on the time and transmitting the ordered list of orders to a kitchen display system for preparing the orders according to the ordered list. program one or more processors to

FIG. 9 illustrates exemplary processing of an example service provider, such as service computing device 102 or an associated application, such as a consensus service, to dynamically change icons 902 of a user interface 904, such as a user interface, based on contextual data. be modified (changed) to 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 context data may be the location of the service computing device 900, time of day, day of the week, time of year (e.g., season), weather, merchant inventory, merchant preferences, customer preferences, items considered upsell items, cross-sell items, and so on. Items considered, sales and/or offers offered by merchants, and various other contextual factors corresponding to the use of service computing device 900 may be included. Contextual data can be generated automatically at the merchant device, through an application, or through data analysis, such as current or historical, at the server level. Contextual information can be obtained by tracking complete or incomplete order requests that are cart level information from third party applications.

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 can be determined based on analysis of one or more factors corresponding to use of service computing device 900 . In an exemplary embodiment, the analysis may include determining that the time of day corresponds to a breakfast menu. Based on this determination, service computing device 900 can display a first setting of icon 902(1) corresponding to the meal menu. In some examples, the analysis may include analyzing customer preferences and determining that the customer prefers certain menu items, such as the breakfast menu.

In various examples, analysis can include determining to emphasize one or more items. Emphasis may be provided by increasing the size, shape, color and/or hue of icons 902, by changing the placement of icons 902, or by other adjustments to make icons 902 stand out on the display. can. Highlights include merchant inventory, current weather, attempts to upsell items, attempts to cross-sell items, sales and/or specials offered by merchants, merchant transaction history (e.g., sales at a given time). known popular items sold, days of the week, times of the year (eg, seasons), known popular combinations of items sold, etc.).

[3] In some examples, the analysis may include determining to de-emphasize one or more items. Item de-emphasis can be based on the merchant's inventory, current weather, cross-sell attempts, and/or other factors that may discourage the merchant from selling a particular item. De-highlighting can be presented by removing icons 902 corresponding to one or more items from the display page. In various examples, user interface 904 can include multiple display pages. In some examples, de-highlighting may be presented by including icons corresponding to one or more items on display pages other than the main display page. For example, de-highlighting can include presenting an icon on the last page of 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 the customer has ordered the last 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 the 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 can include a time change from a time corresponding to the morning menu to a time corresponding to the lunch menu. In some examples, the second contextual data may include a determination of events near the merchant's location, or displayed on a screen at the merchant's location, which is the menu most likely to be ordered by the customer. It can affect items. In such an example, service computing device 900 may dynamically modify icon 902(1) to the second setting of icon 902(2) to accommodate customer preferences or external environment (e.g., cold/hot days). hot/cold beverage items recommended). For example, a merchant may typically adjust from breakfast to lunch menu at 11:00 am. However, the service computing device 900 may determine that the football game starts at 10:00 am and that the customer prefers to consume items on the lunch menu during the football game. Accordingly, service computing device 900 may adjust one or more of icons 902 to correspond to lunch menu items.

In some examples, the service computing device 900 can determine that an event is taking place near the merchant or will be presented on a display screen at the merchant location, and based on the event, one or more sales and/or special offers (eg, discounts, etc.) can be generated. In such an example, service computing device 900 may highlight icons 902 corresponding to one or more special offers. For example, a merchant can special offer hamburgers and alcoholic beverages during an event. Accordingly, the service computing device 900 can modify the icons corresponding to hamburgers and alcoholic beverages to be 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 purchase.

Alternatively or additionally, a first interface with icon 902(1) may correspond to a first third party service and a second interface with 902(2) may correspond to a second third party service. A three-party service can be supported, with merchants 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 behavior in menus related to third-party services (i.e., a menu of service A for a merchant may be a menu of service B for the same merchant). may be organized differently than the menu). A payment service's API can be used to collect customer interactions/behavior (menu scrolling activity, navigation preferences, order history, etc.) within its third party service application. Looking at order histories, payment services tend to have, for example, payment services or APIs where customers of service A typically order appetizers and customers of service B order desserts from a particular merchant. If so, that information can be used to reorganize the menu. Thus, in one embodiment, the payment service is based, for example, on order activity that the consensus service tracks during a particular time period (e.g., "Are customers from most third-party applications currently ordering steaks?" ), content/menu updates can be pushed up to all third party ordering applications. Additionally or alternatively, the Payment Service may reorganize the menu layout to generate a unique menu customized for each third party application based on what the Consensus Service learns about customer ordering behavior. can also be pushed out. Thus, the Consensus Service collects, analyzes, compares, and learns from current and historical data that the Shipping Service does not have access to. In addition, the consensus service allows separate services that otherwise do not communicate to communicate via the indirect channel created by the consensus service. Although the description describes APIs as being one form of channel, the description extends to cover other forms of channels between services, either directly or through intermediary services such as payment services. It should be understood that it is possible to

In some implementations, a server system for providing optimized content management, the system comprising one or more processors and one processor storing instructions executable by the one or more processors. and a non-transitory computer-readable medium as described above, wherein the instructions are to receive a content structure for the first service application and the second service application, the content structure being, for example, a menu Content updates, including how items are laid out or priced, are received and updated by content management applications running on point-of-sale devices associated with merchants to identify new menu items, deleted menu items, Receiving a first content update or review for a first merchant application containing items, the first content update including updates made to content such as menus for the first service application. , receiving, sending a content update to a first service application, sending to a second service application a content update similar to the content update of the first service application, and so on. Execute the step.

Alternatively, the service provider includes generating an organized structure of content based on the service application and the merchant via the content management application. For example, a first menu with a particular order and pricing of items for a first service application, and a second menu with a different order and pricing of items for a second service application. . Further, different items may be offered at different locations and service applications.

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

In some implementations, service provider 102 assigns a received reservation for merchant device 1002, which via an API (not shown) is sent to first reservation application 1004-1 and second reservation application 1004-1. It is configured to receive bookings from multiple booking applications, including application 1004-2. The API may be used to facilitate payment services, for example, as an aggregator that aggregates data from various booking applications, and these third party applications use the published API to provide Send reservation information. For example, a consensus service can collect data and order reservations accordingly. The consensus service can also leverage historical booking information that the service learns about each booking application and assigns a subset of seats based on what the service has learned, eg, via machine learning models. For example, a payment service can allocate seats based on factors such as frequency of cancellations, average arrival time of customers using its application, order size, and the like. The service provider 102 receives a plurality of reservations and executes a consensus service 132 to process the incoming reservations and provide them for merchants based on customer profiles and/or merchant profiles stored in database 1006 . to schedule. Database 1006 stores customer and merchant preferences and shows how reservations can be configured to best match those preferences. For example, consensus service 132 may move reservation 1004-3 from 6:30 to 7 PM depending on availability or past reservations made by customers. Similarly, reservation 1004-4 may be assigned at 8PM depending on the availability of particular seats or items. For example, some restaurants maintain rotating menus and, as such, service providers may be provided access to a user's dining preferences with the user's consent. Reservations can thus be moved to more preferred spots without user or merchant intervention. This application receives, by a payment service, such as a service provider, and from a first booking application, first data associated with an average number of bookings made using the first booking application over a period of time. receiving, by the payment service and from the second booking application, second data associated with an average number of bookings made using the second booking application over a period of time; by the payment service; receiving data regarding available seats in a restaurant; allocating a first portion of seats from the available seats to a first reservation application based at least on the first data, comprising: one or more users of the reservation application can reserve seats up to and including the first portion of seats, said allocating; two reservation applications, wherein one or more users of the second reservation application can reserve seats up to another portion of the seats, said allocating; during the reservation, at least one or more users determining if any seats are available on the second reservation application in response to the inability to reserve a seat using the first reservation application; providing instructions for transitioning a customer device from an interface to a second reservation application; receiving input from one or more users indicating reservations for seating within a restaurant using the second reservation application; disclosed.

In some implementations, a server system for providing optimized restaurant reservation scheduling comprises one or more processors and one or more non-transitory computers storing instructions executable by the one or more processors. and a readable medium, the instructions being to receive a first appointment from a first customer-facing appointment application by an appointment scheduling application executing a point-of-sale device associated with the merchant; includes one or more menu items prepared by the merchant for delivery to the address provided by the first customer in-person booking application; Sending to the device an estimated pick-up time indicating the estimated time of arrival of the courier or customer to pick up the first appointment by the first delivery application; and past appointments associated with the first customer-facing application. determining a predicted pick-up time indicating when the delivery person or customer is likely to pick up the first appointment based on; receiving a second reservation, the second reservation including one or more menus prepared by the merchant; transmitting an estimated pick-up time indicating the estimated time of arrival of the courier or other customer to pick up the second booking; and based on past bookings involving the second delivery application. , determining a predicted pick-up time indicating a time at which a delivery person or customer is likely to pick up the second reservation; generating an ordered list of reservations based on the order list; and transmitting the ordered list of reservations to the kitchen display system for preparation of the reservations according to the ordered list. program the processor.

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 specific features or acts described. Rather, the specific features and acts are disclosed herein as exemplary forms of implementing the embodiments.
section

A. 1. 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. wherein the instructions are to receive a first order from a first customer facing ordering application by an order scheduling application executing on a point of sale (POS) device associated with a merchant; includes one or more menu items prepared by the merchant for delivery to an address provided by the first customer facing ordering application; Determining a predicted pick-up time indicating an estimated time that a delivery person or said customer is likely to pick up said first order based on past orders including a first customer-facing application; and said order scheduling application. receiving a second order from a second customer facing ordering application from another customer, said second order including one or more menu items prepared by said merchant, said receiving and a prediction by a service computing device indicating when said delivery person or said customer is likely to pick up said second order based on past orders including said second customer facing order application. determining a pick-up time; and 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. , sending to a kitchen display system associated with the order scheduling application the ordered list of orders for preparing the orders according to the ordered list. A system that programs one or more processors.

B. providing an interface to at least one of said customer or said merchant via a display associated with a computing device, through which a delivery location, a pickup location, and a requested pickup time are obtained; receiving the ordered list of orders based on one of the number of items, the size of the items, whether the items are associated with a predetermined category, or the weight of the items; determining that information regarding shipping is requested, sending a request regarding shipping of the item to the service computing device via the one or more APIs, and receiving a shipping proposal from the service computing device; , a third party service for determining that a shipping offer has been accepted and transmitting an indication of acceptance of said shipping offer via said one or more APIs to facilitate delivery of said item; or The system of Section A, further comprising an application executable by one or more processors of said computing device associated with at least one of said merchants.

C. The order scheduling application is an application program interface that interfaces with the computing device associated with the merchant, the computing device associated with the third party service, and the computing device associated with the customer. The system of clause A or B, further configured to provide an interface (API).

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

E. The service computing device for receiving additional location information of a courier associated with the third party service and generating the first order or the second order based on the location information of the courier. and assigning delivery of the item to the identified third party service, Section B. The system described in .

F. 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 services. a computing device in communication with devices over one or more networks and associated with at least one of a customer or merchant, via one or more application programming interfaces (APIs) over said one or more networks Communicating further, the service computing device receives, via the one or more APIs provided by the service computing device, a request for delivery of an item designated by the customer to be obtained from a merchant. wherein said request includes delivery location, pickup location, requested time of pickup, number of items to be retrieved, size of said item, whether said item is associated with a predetermined category, or indicating at least one of the weight of the item, the request being made 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. receiving and generating, for the merchant, a delivery offer to prepare and deliver the item to the location of delivery, the delivery offer comprising: (a) the third party service; A preferred delivery service from among said plurality of third party delivery services associated with a device, wherein said plurality of third party delivery services is configured via said one or more APIs of said service computing device the preferred shipping service in communication with the merchant; (b) a sequence of requests including the request that the merchant uses to prepare; (c) an estimated amount of time for delivery of the item by the shipping service; and, using the one or more APIs, to the third party service associated with the preferred shipping service, the preferred shipping service sending the item from the merchant's facility. and sending a communication requesting that the item be transported to the location for delivery.

G. Said sequence of requests includes a sequence in which said merchant processes said requests, said sequence includes: time, location of said merchant, location of said customer, location of a delivery person capable of making said delivery, location of said delivery person, location of said order received, F. The system of clause F, wherein the system is based on at least one of: time ordered, merchant profile, customer profile, requested preparation time of said item, and availability of said item.

H. a service computing device, when executed by one or more processors, for providing the one or more processors with a computing device access to one or more merchants associated with the service computing device; exposing one or more application programming interfaces (APIs) by a computing device and accessing one or more third party services that can facilitate one or more actions associated with said merchant exposing the one or more application programming interface interfaces (APIs) by the service computing device for providing to the merchant and the third-party service via the one or more APIs; receiving from a computing device a request to process the action associated with the merchant; and generating an action suggestion to facilitate the action associated with the merchant, said generating and transmitting said action suggestion to said computing device associated with said third-party service or said merchant; configuring, by a service provider, via said one or more APIs, a payment flow based on said action proposal, said payment flow comprising a distribution of sub-actions between said third-party service and said merchant; One or more non-transitory computer-readable media storing executable instructions for performing operations including

I. The one or more actions include shipping an item, preparing said item, canceling said item, shipping an order, preparing said order, canceling said order, merging an order, splitting said order, reserving for a customer, The one or more non-transitory computer readable media described in Section H including appointments for customers, content updates across third party services, said item updates, said order updates.

J. The action suggestion is a delivery suggestion that indicates 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. One or more non-transitory computer-readable media according to any of Sections H or I.

K. Publishing 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 items offered for acquisition by the merchant. One or more non-transitory computer-readable media described in Section H, including enabling to facilitate.

L. The actions include: receiving a request for delivery status of the item from the computing device via the one or more APIs; receiving location information for the third party service device; The one or more non-transitory items of Section K, further comprising determining a status of delivery of the item by a third party service; and transmitting the status of delivery of the item to the computing device. computer readable medium.

M. The act may receive, via the one or more APIs, another request to deliver another item to the merchant to register the merchant with a service that facilitates acquisition of the item. wherein the other item comprises a merchant application that facilitates acquisition of the item with a customer, and the other request indicates a location for delivery of the other item; identifying the other third party service for transporting the other item based at least in part on the location of the third party service; Sending a communication to another third party service device associated with said other third party service requesting delivery of said other item to said location, clause K or L. 3. One or more non-transitory computer readable media as described in .

N. The actions 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. The one or more non-transitory computer-readable media of any of Sections HM, further comprising:

O. a display configured to display an interface; one or more processors communicatively connected to the display; and a processor communicatively connected to the one or more processors and executed by the one or more processors If so, to the one or more processors, on a display, a first carrier prepared by a merchant and for pickup for delivery to a first customer by a first carrier of a first delivery service. and on said display a second order prepared by said merchant and picked up for delivery to a second customer by a second carrier of a second delivery service and receiving on the display a delivery proposal including a sequence in which the merchant should prepare the first order and the second order, the sequence comprising one or more said receiving generated by a service computing device interfaced with said system having said display, said first delivery service, and said second delivery service via an application program interface (API); modifying the sequence through the display based on item availability in the first order or the second order; and based on the modification by initiating an API call to the service provider. A system comprising: causing a payment flow; and a memory storing executable instructions for performing an operation comprising:

P. The act sends, via the one or more APIs, to the service computing device a trigger to provide a shipping status of the item to the first shipping service or the second shipping service. and receiving from the service computing device a status of delivery of the item; and sending the status of delivery to the first delivery service or the second delivery service. The system of Section O.

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

R. The delivery proposal may include 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 the The system of any of clauses OQ, indicating at least one of estimated drop-off times for delivery of items.

S. The delivery proposal indicates at least one of costs for delivery of the item by a delivery service associated with the service computing device, and the action removes items from a group of items in an order. wherein said removal is based on availability, popularity, spoilage and time of day; displaying via said interface the cost of delivery of said item; and billing a customer associated with acquisition of the cost of shipping the order after removing the item.

T. The system of any of clauses OS, wherein the act further comprises providing consensus when the first order and the second order are placed substantially simultaneously.

U.S.A. 1. A system for providing optimized reservation scheduling, comprising one or more processors and one or more non-transitory computer-readable media storing instructions executable by the one or more processors. wherein the instructions are for receiving, by an appointment scheduling application running on a point of sale device associated with the merchant, from a customer a first appointment request from a first customer face-to-face appointment application; Based on said receiving and past orders associated with said first customer face-to-face booking application, said first booking request includes a preferred time for booking at a merchant location, said customer is prompted by a service computing device to: determining seats predicted to be likely to prefer the first reservation request; and receiving, by the reservation scheduling application, a second reservation request from a second customer face-to-face reservation application from another customer. based on said receiving and past orders associated with said second customer-facing booking application, wherein said second booking request includes other preferred times for bookings at said merchant location; determining, by a service computing device, a seat for which said other customer is likely to prefer said second reservation request; generating a seating chart based at least in part on said predicted seats corresponding to two reservation requests; and providing said seating chart with a table layout of said merchant locations on a kitchen display system associated with said reservation scheduling application. transmitting the seating chart for configuration according to the one or more processors.

V. An application executable by one or more processors of a computing device associated with at least one of a third party service or said merchant, said customer via a display associated with said computing device or providing an interface to at least one of said merchants, and through said interface, alternate merchants providing reservations, seat options at said merchant from which reservations were requested, timing of said reservations, and past seat preferences. receiving an update to the seating chart based on at least one alternate seating option that differs from the requested seat option based on a request; determining that information regarding the seating chart has been requested; sending, via one or more APIs and by the service computing device, a response to the request for an update to the seating chart; receiving a booking offer from the service computing device; and sending an indication of acceptance of the booking offer via the one or more APIs to facilitate the booking. system.

W. The appointment scheduling application provides an application program interface (API) to interface with the computing device associated with the merchant, the computing device associated with the third party service, and the computing device associated with the customer. The system of clause U or V, further configured to provide:

X. Further comprising a consensus application hosted on said service computing device, said consensus application receiving said first booking request and said second booking request from said first customer-facing booking application and said second customer-facing booking application, respectively. and wherein the consensus application processes the first reservation request and the second reservation request based on the customer's preferences.

Y. The service computing device receives further information of the customer associated with the reservation request, identifies one of the merchants different from the merchant from whom the reservation was requested, and based on the identification, the other merchant. V. The system of clause V, further configured to allocate seats at the merchant locations of .

Z. 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 services. a computing device in communication with devices over one or more networks and associated with at least one of a customer or merchant, via one or more application programming interfaces (APIs) over said one or more networks Communicating further, the service computing device receiving, via the one or more APIs provided by the service computing device, a request for a reservation with the merchant, the request being a merchant generating an appointment proposal for setting said appointment according to customer preferences for said receiving and presentation on a device associated with said merchant, indicating a preferred time for an appointment at a location; As such, the reservation offer includes (a) a seat at a merchant location from among a plurality of seat options, (b) another time slot corresponding to the request, and (c) an alternate seat if the merchant location is reserved. said generating and, using said one or more APIs, said identified third party service, including options, to said third party service device associated with said identified third party service; sending a communication requesting to reserve a seat at said merchant location.

AA. The processor is further configured to allocate reservations for merchants 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 receives, via a payment service, from the first reservation application, a first data-related reservation made using the first reservation application; and receives, via the payment service, the second receiving a second data-related reservation made using said second reservation application for a period of time from the reservation application of said payment service, and receiving data regarding available seats at a restaurant by said payment service; and allocating a first portion of seats from the available seats to the first reservation application based on at least first data, wherein a user of the first reservation application is a user of the the allocating, wherein up to and including a first portion of seats can be reserved; and allocating a second portion of the available seats to the second reservation application based on at least second data. wherein a user of said second booking application can reserve seats less than or equal to seats in another portion of said allocating and booking, and at least one user using said first booking application Determining whether any seats are available on the second reservation application in response to the inability to reserve a seat; and receiving input from the one or more users indicating reservations for the seats within the restaurant using the second reservation application. and the system of clause Z to perform one or more operations.

AB. 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 an operation, the operation being a service computing device exposing, by a service computing device, one or more application programming interfaces (APIs) to provide computing devices with access to one or more merchants associated with the merchant; one or more application programming interface interfaces ( and receiving requests from the computing devices of the merchant and the third party service via the one or more APIs to process actions associated with the merchant. and generating an action proposal that facilitates the action associated with the merchant, the action proposal including a sequence in which steps within the action are performed; sending the action proposal to the computing device associated with the merchant service or the merchant; and configuring, by the service provider, via the one or more APIs, a payment flow based on the action proposal based on the action proposal. and wherein said payment flow is based on a distribution of sub-actions between said third party service and said merchant. medium.

AC. The one or more actions include shipping an item, preparing the item, canceling the item, shipping an order, preparing the order, canceling the order, merging the order, splitting the order, booking a customer, customer appointments, content updates across third party services, said item updates, said order updates.

AD. The suggested action may be one of an alternate merchant offering a reservation, a seat option at the merchant at which the reservation was requested, the timing of the reservation, and an alternate seat option different from the requested seat option based on past seat preferences. One or more non-transitory computer readable media according to any of clauses AA-AC, which is a subscription offer indicating at least one.

AE. Publishing the one or more APIs includes exposing the one or more APIs to a computing device associated with a merchant so that the merchant can communicate with the merchant at one of a physical location or an online location. One or more non-transitory computer-readable media described in Section AB, including facilitating reservations or appointments for

AF. The acts were: receiving a request for modification to the reservation request from the computing device via the one or more APIs; and associated with the merchant and performed through a plurality of third party services. The method of clause AE, further comprising: accessing a seating chart containing reservations; determining whether said modification causes a race condition; and determining a new seat based on said determination. One or more non-transitory computer-readable media.

AG. The action is 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 seat options for said first request or said second request based on updated customer preferences, and updating a seating chart according to said identifying step; one or more non-transitory computer-readable media according to Section AE or AF, further comprising:

AH. The actions 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. The one or more non-transitory computer-readable media according to any of Sections AB-AG, further comprising:

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

AJ. Said act sends, via said one or more APIs, to said service computing device a trigger to provide a reservation status to said first reservation service or said second reservation service; causing a reservation status to be transmitted to the computing device associated with the customer.

AK. The system includes a merchant device, and the action is to receive, via the one or more APIs, another request to reserve another seat, the other seat reserving a previous reservation. identifying alternate seat options for the first request or the second request based on updated customer preferences; sending a communication to the merchant indicating an updated seating chart according to the step of:

AL. The reservation offer is one of an alternate merchant offering a reservation, a seat option at the merchant from which the reservation was requested, the timing of the reservation, and an alternate seat option that differs from the requested seat option based on past seat preferences. A system according to any of clauses AI-AK, indicating at least one.

AM. The reservation proposal 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, wherein the routing comprises the second reservation application. The system of any of clauses AI-AL, including transitioning from a first user interface associated with one booking application to a second user interface associated with the second booking application.

AN. The system of any of clauses AI-AM, wherein the act further comprises providing consensus if the first reservation and the second reservation occur substantially simultaneously.

AO. A system for providing optimized content management associated with menus, said system comprising one or more processors and one or more processors storing instructions executable by said one or more processors. a non-transitory computer-readable medium, wherein the instructions are executed by a content management application associated with a service computing device and on a point-of-sale device associated with the merchant to cause the merchant to receiving content updates relating to one or more menu items provided by a service provider, said content updates configured to be delivered to a customer-facing application; determining by the content management application whether the one or more additional customer-facing applications apply to the additional customer-facing applications of interfaced with the content management application via the determining and determining by the service computing device and that the content update applies to one or more additional customer facing applications. causing interfaces of said one or more additional customer-facing applications to be updated according to said content update via said one or more APIs; and notification indicating that said customer-facing application has received said content update; and transmitting to a kitchen display system associated with the merchant.

AP. further comprising an application executable by one or more processors of a computing device associated with at least one of a third-party service or merchant, wherein, via a display associated with said computing device, said customer or said providing an interface to at least one of the merchants; and receiving, via said interface, a notification indicating that said customer-facing application has received said content update for synchronizing across other customer-facing applications. determine that the content update is sent only to targeted customer-facing applications; and via the one or more APIs and by the service computing device, the other canceling the content updates from non-targeted customer facing applications, including customer facing applications of;

AQ. The content management application includes an application program interface (API) to interface with the computing device associated with the merchant, the computing device associated with the third party service, and the computing device associated with the customer. ), the system of clause AO or AP.

AR. further comprising a consensus application hosted on said service computing device, said consensus application being a merchant associated with one or more point of sale (POS) devices running one or more instances of said content management application; and wherein the consensus application selects one of the plurality of content updates based on the customer's preferences.

AS. The service computing device determines, based on an inventory database, whether to generate the content update, identifies which of the customer-facing applications should receive the content update, and identifies the identified customer. The system of any of clauses AO-AR, further configured to send the content update to a face-to-face application.

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 services. a computing device in communication with devices over one or more networks and associated with at least one of a customer or merchant, via one or more application programming interfaces (APIs) over said one or more networks Further communicating, wherein the service computing device receives requests for content updates via one or more APIs provided by the service computing device, the content updates being delivered to customer facing applications. and associated with one or more menu items provided by said merchant, said request executable on said computing device associated with at least one of said customer or said merchant said receiving, and whether said content updates applied to other customer-facing applications provided by said service computing device, generated via said one or more APIs from such applications; determining, via one or more APIs, wherein the other customer-facing applications are interfaced with the applications via one or more application programming interfaces (APIs); responsive to determining, by a service computing device, that the content update applies to other customer-facing applications, for the merchant to deliver the content update to the location of delivery associated with the customer-facing application; generating a proposal for delivery, the proposal being (a) one or more customer-facing applications from among a plurality of customer-facing applications associated with the third-party service device; the one or more customer-facing applications, wherein the plurality of customer-facing applications communicate with the merchant via the one or more APIs of the service computing device; and (c) an estimated time for delivery of said content update; sending, using an API, 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 provides an interface to at least one of the customer or the merchant via a display associated with the computing device through which the customer-facing application receives the content updates. and determining that the content update should only be sent to targeted customer-facing applications, via the one or more APIs, and on the service computing device. The system of clause AT further configured to revoke said content updates from non-targeted customer facing applications including said other customer facing applications by.

AV. 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 an operation, the operation being a service computing device exposing one or more application programming interfaces (APIs) to provide computing devices with access to one or more merchants associated with said service computing device; , the one or more application programming interfaces (APIs) for providing a computing device with access to one or more third party services that can facilitate one or more actions associated with the merchant; and receiving requests to process the actions associated with the merchant from the computing devices of the merchant and the third party service via the one or more APIs; , generating an action proposal that facilitates the action associated with the merchant, the action proposal including a sequence in which steps within the action are to be performed; sending the action proposal to the computing device associated with the merchant service or the merchant; and configuring, by the service provider, via the one or more APIs, a payment flow based on the action proposal based on the action proposal. and wherein said payment flow is based on a distribution of sub-actions between said third party service and said merchant. medium.

AW. The one or more actions include shipping an item, preparing the item, canceling the item, shipping an order, preparing the order, canceling the order, merging the order, splitting the order, booking a customer, customer appointments, content updates across third party services, said item updates, said order updates.

AX. One or more of the non-temporary actions of any of clauses AV or AW, wherein the action proposal is a content update proposal that indicates content to be updated and an identifier of a third party service to which the content update is sent. computer readable medium.

AY. Publishing the one or more APIs exposes the one or more APIs to a computing device associated with the merchant to facilitate the merchant updating content, including menu items. One or more non-transitory computer readable media described in Section AV, including enabling.

AZ. The actions include: receiving a request for item delivery status from the computing device via the one or more APIs; receiving location information for the third party service device; one or more of the non-transitory computers recited in Section AY, further comprising: determining a status of said content update by a third party service; and transmitting said status of said content update to said computing device. readable medium.

BA. The operations further include executing a consensus application hosted on the service computing device, the consensus application including one or more point of sale (POS) applications running one or more instances of a content management application. ) receiving a plurality of content updates from the merchant associated with the device, and wherein the consensus application selects one of the plurality of content updates based on the customer's preferences. One or more non-transitory computer-readable media.

BB. The actions 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. The one or more non-transitory computer-readable media according to any of Sections AV-BA, further comprising:

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

BD. The actions include sending, via the one or more APIs, to the service computing device a trigger for providing the content update to the first or second customer-facing application; receiving a status of content updates from a viewing device; and causing the status of delivery of the content updates to be sent to the first or second delivery service.

BE. The system includes a merchant device, and the action is receiving from the service computing device an order for acquisition of another item, the other item being a customer of the first delivery service. receiving user input indicating acceptance of the order that has been selected for retrieval via a device; and transmitting an indication of acceptance of the order to the service computing device. receiving a first status of delivery of said item and a second status of delivery of said other item; and displaying said first status of delivery and said second status of delivery of said item via said interface. The system of clause BC or BD, further comprising: causing.

BF. The system of any of clauses BC-BE, wherein the proposal indicates how to address the first content request across different merchant applications.

BG. The offer indicates whether the first content request applies to other customer-facing applications other than the identified one, and the actions include updating existing content and generating new content. and removing existing content. The system of any of clauses BC-BF.

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

Although the example sections above have been described with respect to one particular implementation, in the context of this specification the content of the example sections may refer to methods, devices, systems, computer-readable media, and/or other implementations. It should be understood that it can also be implemented via

Claims (15)

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 comprising:
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, said first order said receiving including one or more menu items prepared by said merchant for delivery to an address provided by the customer facing ordering application of
Determining, by a service computing device, a predicted pick-up time indicating an estimated time that a delivery person or said customer is likely to pick up said first order based on past orders containing said first customer-facing application. and
receiving, by the order scheduling application, a second order from another customer from a second customer-facing ordering application, the second order of one or more menu items prepared by the merchant; the receiving comprising
Determining, by a service computing device, a predicted pick-up time indicative of when the delivery person or the customer is likely to pick up the second order based on past orders containing the second customer-facing order application. and
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;
sending 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;
and programming the one or more processors to perform operations including: providing an interface to at least one of the customer or the merchant via a display associated with a computing device;
Via said interface, the delivery location, pickup location, requested pickup time, number of items to be retrieved, size of said item, whether said item is associated with a predetermined category, or weight of said item. receiving the ordered list of orders based on one of
determining that information regarding delivery of the item is requested;
sending a request for delivery of the item to the service computing device via the one or more APIs;
receiving a delivery offer from the service computing device;
determining that the delivery offer has been accepted;
associated with at least one of a third party service or said merchant for transmitting an indication of acceptance of said delivery offer via said one or more APIs to facilitate delivery of said item; 2. The system of claim 1, further comprising an application executable by one or more processors of said computing device running on said computer. The order scheduling application provides an application program interface (API) to interface with the computing device associated with the merchant, the computing device associated with the third party service, and the computing device associated with the customer. 2. The system of claim 1, further configured to provide: further comprising a consensus application hosted on said service computing device, said consensus application receiving said first order and said second order from said first customer-facing ordering application and said second customer-facing ordering application, respectively; 2. The system of claim 1, wherein orders are received and the consensus application schedules the first order and the second order for display on the kitchen display system. The service computing device comprises:
receiving further location information of the shipper associated with the third party service;
identifying one of a third party service that is different from the third party service used to generate the first order or the second order based on the location information of the shipper;
assigning delivery of the item to the identified third party service;
3. The system of claim 2, further configured to: to the one or more processors when executed by the one or more processors;
exposing one or more application programming interfaces (APIs) by the service computing device to provide the computing device with access to one or more merchants associated with the service computing device;
by the service computing device to provide the computing device with access to one or more third party services that can facilitate one or more actions associated with the merchant; exposing an application programming interface (API) for
receiving requests, via the one or more APIs, from computing devices of the merchant and the third party service to process the actions associated with the merchant;
generating an action proposal for facilitating the action associated with the merchant, the action proposal including a sequence in which steps in the action are performed;
sending the action suggestion to the computing device associated with the third party service or the merchant;
configuring, by the service provider, via the one or more APIs, a payment flow based on the action proposal, the payment flow comprising sub-actions between the third-party service and the merchant; said configuring is based on distribution;
One or more non-transitory computer-readable media storing executable instructions to perform operations including Exposing the one or more APIs enables the merchant to facilitate delivery of items offered for acquisition by the merchant. 7. The one or more non-transitory computer-readable media of claim 6, comprising publishing to a computing device associated with a. The operation is
receiving a request for 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 the status of delivery of the item by the third party service;
transmitting the status of delivery of the item to the computing device;
8. The one or more non-transitory computer-readable media of claim 7, further comprising: The operation is
receiving, via the one or more APIs, another request to deliver another item to the merchant to register the merchant with a service that facilitates acquisition of the item; said item is configured with a merchant application that facilitates acquisition of items with a customer, said other request indicating a location for delivery of said other item;
identifying the other third party service for transporting the other item based at least in part on the location of the other third party service;
other third party service associated with said other third party service to send a communication requesting that said other third party service deliver said other item to said location of delivery of said other item; sending to the device;
8. The one or more non-transitory computer-readable media of claim 7, further comprising: The operation is
obtaining training data regarding current and past actions performed by said merchant and said third party service;
training a machine learning model based on the training data to generate the action suggestions;
9. The one or more non-transitory computer-readable media of claim 8, further comprising: a system,
a display configured to display an interface;
one or more processors communicatively connected to the display;
communicatively connected to and executed by the one or more processors, to the one or more processors;
receiving on a display a first order to be prepared by a merchant and picked up for delivery to a first customer by a first courier of a first delivery service;
receiving a second order on the display to be prepared by the merchant and picked up for delivery to a second customer by a second courier of a second delivery service;
Receiving on the display a delivery proposal including a sequence in which the merchant should prepare the first order and the second order, the sequence comprising one or more application program interface (API) said receiving generated by a service computing device interfaced with said system having said display, said first delivery service, and said second delivery service via
modifying the sequence through the display based on item availability in the first order or the second order;
Generating a payment flow based on the modification by initiating an API call to the service provider;
a memory that stores executable instructions to perform operations including
A system with The operation is
sending, via the one or more APIs, to the service computing device a trigger for providing the delivery status of the item to the first delivery service or the second delivery service;
receiving status of delivery of the item from the service computing device;
sending the status of delivery to the first delivery service or the second delivery service;
12. The system of claim 11, further comprising: The system comprises a merchant device, the operation comprising:
receiving an order for acquisition of another item from the service computing device, the other item being selected for acquisition through a customer device of the first delivery service; to receive;
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;
displaying the first status of delivery and the second status of delivery via the interface;
12. The system of claim 11, further comprising: The delivery proposal may include 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 the 12. The system of claim 11, indicating at least one of estimated drop-off times for delivery of items. The delivery proposal indicates at least one of costs for delivery of the item by a delivery service associated with the service computing device, and the action comprises:
removing items from a group of items in an order, wherein the removal is based on availability, popularity, spoilage, and time of day;
causing the cost of shipping the item to be displayed via the interface;
12. The system of claim 11, comprising: billing a customer associated with acquiring the item for the cost of shipping the order after removing the item.

Images