JP7072068B2 - Application programming interface for structuring distributed systems - Google Patents

Description

Priority This application claims priority to US Patent Application Nos. 15 / 858, 164, 15 / 858, 000 and 15 / 858, 100, all of which were filed on December 29, 2017. All of them are incorporated herein by reference in their entirety.

Buyers often use websites and other techniques to purchase items from merchants for delivery to the buyer. In some cases, delivery systems or services can facilitate the delivery of goods and services provided by merchants. For example, a delivery service can provide an online site that identifies items (items, goods) from multiple merchants available for delivery. Buyers can go 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. Delivery services can utilize various techniques to achieve delivery of items to the buyer (buyer). In particular, the delivery service can communicate with the electronic device associated with the merchant and / or the electronic device associated with the customer to deliver the item. Customers also use techniques for interacting with merchants, for example, to make reservations to purchase items or to reserve their time or service. Similarly, the booking service can facilitate the booking of a merchant's location for a particular service. However, if the merchant is associated with some of these deliveries, bookings, and other third party services, the merchant must manually control and coordinate the injection of information from different unconnected sources. Eventually, the simplicity of operation promised by third-party services becomes useless. In addition, associating a merchant's interface with a third-party service can confuse other technologies that a merchant employs to run his or her business.

A detailed description is given with reference to the accompanying drawings, in which the number at the left end of the reference number is similar to the use of the same reference number in the same or different drawings that identify the drawing in which the reference number first appears. Or indicate the same item or feature.

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

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 a plurality of different distributed services via a service provider.

FIG. 4 details an example of a user or consumer device hosting or accessing a web or native third party service in some implementations.

FIG. 5 shows an exemplary process for exposing one or more APIs to allow an entity to use the delivery service provided by the service provider.

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

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

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

FIG. 9 is exemplary data showing 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. The flow diagram is shown.

FIG. 10 shows an exemplary data flow diagram showing the process of harmonizing reservations and allocating unfinished or duplicate reservations originating from a plurality of third party services.

The techniques described herein are applications for delivery services, through a service provider, that allow an entity to communicate with different services without complicated coding or modification to the entity's source code. It provides systems and environments that allow different third-party services to be configured, such as applications for booking services and applications for third-party services. In some examples, a service provider uses one or more application programming interfaces (APIs) provided by the service provider to consensus on computing devices associated with merchants, buyers, and / or others. Publish the 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, the service provider may be a third party operating remotely and / or independently of the merchant, buyer, and / or others. One or more APIs are provided for acquisition by the merchant, allowing the merchant and / or others to automatically integrate the consensus service into the technology used by the merchant and / or others. Several tasks can be facilitated, such as delivering items, reserving restaurants for both in-dining or pick-up, and generating menus. For example, one or more APIs to a consensus service allow an entity to automatically access information about the delivery of an item by multiple delivery services (eg, delivery person cost, estimated delivery time, etc.) for the item by the delivery service. Consensus services such as facilitating delivery, ordering preparations for items, scheduling deliveries and preparations from the kitchen, scheduling reservations, and managing content to and from third-party services. It can be made possible to use various other features provided by the service provider through.

First, the implementation will be described with reference to the delivery service or the third party service. In many examples, a service provider can operate a network of third party service devices to deliver items to buyers and others. Each of the third party service devices can implement a Global Positioning System (GPS) receiver or other location sensor to provide location information to the service provider. The service provider tracks the location of the third party service device, selects the third party service device for delivery, sends an update regarding the delivery of the item, or otherwise the third party service of the item. Delivery can be facilitated. In addition, or as an alternative, the service provider can work with multiple merchant devices. Each merchant device can 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 perform other functions. In addition, or as an alternative, service providers can also communicate with multiple third-party services, implementing third-party service logic and systems to receive customer orders for goods and services offered by merchants. can do. As mentioned above, the services and systems of merchants, customers, and third parties can interact with each other through the API of the service provider's consensus system.

The consensus system then acts as a hub for publishing APIs for integrating third party food ordering, delivery, or preparation services for central ordering in point-of-sale systems, such as ordering hubs. The consensus system can update the preparation time or delivery time across multiple incoming services to automatically calculate new order analysis such as preparation time, delivery time, and preparation order. In one embodiment, the consensus system can utilize the API to manage inventory information and provide order information. As an example of the techniques described herein, if a merchant receives an order for 10 hamburgers from a third party delivery service and another order for 5 hamburgers from a second third party delivery service. The Consensus System shall update the availability, preparation, and delivery time of items in real time for the First Third Party Delivery Service, the Second Third Party Delivery Service, and any other third party delivery service. Can be done. The consensus system can also predict and anticipate employee staffing for ordered items so that merchants have the appropriate staff and inventory based on past orders from various services. The consensus system can also direct automatic inventory / material replenishment 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 reservation hub by utilizing one or more APIs for integration of third party reservation services, centralized reservations, wait lists, scheduling management. The consensus system can communicate with other third party booking services to provide a central booking system and dynamic allocation / reassignment of tables and preferred seats, and even dining in is not available. Pickups can also be provided in case. The consensus system monitors and analyzes seating time demands and optimizes staffing and materials to support meals with preferred waiters / chefs for specific bookings or desired menu items accordingly. To be. Certain thresholds may be set for the number of items, the number of customized reservations allowed during the shift, and so on. In addition, the consensus system allocates any number of seat allocations to each service based on usage metrics and reserves when one service is unable to serve the user's request, regardless of whether the user has subscribed to another service. You can transfer users from one service to another via the API. In addition, the consensus system can be a hub for reserved seat allocation and a hub for seat placement in a manner that maps to customer profiles and merchant specifications. For example, frequent customers can sit in the best areas of the restaurant. The consensus system also integrates with other verticals supported by the service provider. For example, a consensus system can create a customer profile when a new customer makes a reservation at a restaurant to provide one of the many third party services that best suit the customer's profile. So integrated with the onboarding component. The consensus system can also recommend restaurants based on aggregated reviews from all services, such as by the weight or relevance of each third party service.

The consensus system may be a hub, such as a menu hub, for content aggregation and analysis. In such an embodiment, the consensus system dynamically pricing based on how the user places an order from a third party service on a different menu and optimizes sales accordingly. Is a unified manager for. The consensus system can promote a single menu update applicable to all third party services and harmonize the content on such services. The consensus system can also drive multiple updates or service-specific updates to account for usage metrics across third-party services. For example, ordering menu content can be set according to user popularity or usage across all third party services, specific services, and even usage within a specific area within the service. For example, a payment service can change a menu order based on the popularity of the order or the user's behavior between different delivery services. For example, if the payment service does not have access to cart-level information from a third-party service, the payment service may capture such information once the order is placed in the kitchen. In this way, the payment service leverages the published API to check out how the user navigates the service menu of a third party and what items the user tends to add. You can see if you tend not to do so and adjust the global menu for merchants (or specific menus for merchants and third party services) accordingly.

As an example of the techniques described herein, an application can be run on a computing device associated with a merchant, a buyer, and / or others. The application is for an individual (eg, a merchant, a buyer, etc.) to perform an action, for example, to place an order for an item provided for acquisition by a merchant, to reserve a seat in a restaurant, or to display content. , A user interface can be provided to enable the provision of updates to third-party services, and the like. For example, in the case of a delivery service, an individual may select an item to acquire and request that the item be delivered via the user interface. For example, an individual may be interested in placing an item in an electronic shopping cart for purchase and having the item delivered. In some cases, an individual may have a delivery location, a pickup location, the requested time for pickup, the number of items acquired, the size of the item, whether the item is associated with a given category, the weight of the item, etc. Can be specified. In another example, such information is automatically determined or retrieved from the user profile or merchant profile.

When an individual determines that he or she is interested in delivering an item, an application for a third-party delivery service, etc., is a service provider to facilitate delivery of the item through a consensus service associated with the service provider. You can use the API provided by to communicate with a third-party service provider. For example, the application can send requests such as the cost of shipping an item, an estimated delivery time of an item, and so on. The third party service may use the associated delivery service to generate a delivery proposal for delivering the item to the buyer's location, eg, to the service provider via the API for consensus service. Can be done. The delivery proposal may include delivery cost, estimated delivery time and / or other information regarding the delivery of the item. The service provider can send the delivery proposal to the application for acceptance or rejection via the consensus service. In some examples, the application may present information to an individual interacting with the user interface, and the individual may provide input to accept or reject the proposal. In another example, the application can operate according to one or more criteria to automatically accept or reject delivery proposals (eg, accept if the cost is below a threshold, estimated delivery). Accept if the time is less than the threshold time amount). In any case, the application can use the API to send an indication (indicator, instruction) of acceptance or rejection of the delivery proposal to a third party service.

The service provider may take action to select a delivery person for delivery when a third party service is notified of the acceptance of the delivery proposal. For example, a service provider can track the location of multiple delivery person devices over time, be within a certain distance to the pickup location, be available for delivery, and be able to transport items. You can select a delivery person who meets one or more criteria, such as being associated with a vehicle. In some cases, the service provider may use the courier profile, user profile, merchant profile, or other information to select the courier. The service provider can then send the delivery person a communication requesting that the delivery person obtain the item from the merchant's facility and transfer the item to the delivery location. During delivery of the item, the service provider can receive information from the deliverer and / or merchant (eg, location information, confirmation that the delivery has been picked up, etc.) and determine the status of the delivery. The service provider can send the status of the delivery to the application, the merchant device, the buyer device, and / or others, so that the individual can be notified of the current status of the delivery.

Often, the techniques and environments described herein provide one or more APIs to access consensus services provided by service providers and support delivery, booking, 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 may 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 (eg, with fewer components) compared to the website or application that incorporates such features directly into the website or application. .. This can result in relatively fast implementation of websites and applications. In addition, the technology and environment may allow the integration of third party services to take place across a wide variety of contexts (eg, devices, platforms, etc.). In addition, the technology and environment provide a flexible structure for modifying the underlying technology, such as 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 the need for technology updates carried out by merchants, buyers, and / or others. May be good. In addition, the technology and environment may allow the underlying technology used by the service provider (including, for example, algorithms, cost schemes, etc.) to be maintained in a secure environment. In addition, data shared by multiple third-party services does not need to be exposed to merchants, and service providers can also control and capsule data based on third-party services, environment, location, time, and so on. Can be created, which is specific to third-party services or the relationship between third-party services such as terminals, applications, kitchen display systems, payment applications and merchant platforms. You may.

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

Benefits of the central restaurant system include better management of reservations, tracking of restaurant reviews from multiple sources, and elimination of double bookings 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 bookings and appointments such as salons, hospitals, yoga studios, etc. The techniques described herein can be used to optimize reservations and assign seat allocations to third party reservation services in real time, eg, based on filling capacity.

Benefits of a central content consensus system include better management of content such as menus, prices, uptime, etc. All third party services get the same updates from merchants at the same time. Using the techniques described herein, content can be harmonized across different third party services so that the price, brand, and merchant look and feel are consistently maintained. The consensus system can be a unified manager for dynamic pricing, selling by tracking order data such as what and how much the user is ordering on different menus. Can be optimized. Alternatively, push different updates to third party services in real time or near real time to target different types of viewers, i.e. to adjust menu prices across all menus based on availability / popularity. can do. For example, by determining that a customer ordering through a first third party service orders fast food early in the morning, the menu is configured to present fast food items on the list, for example, in order of preparation time or popularity. You may. In addition to, or instead, item pricing may be configured to map to data analysis. In some implementations, the payment flow can be modified when the merchant modifies the item. For example, if a merchant decides to remove an item from his menu (sometimes called a deleted item), but an order has already been placed for that item in addition to other items, the consensus system allows the customer to do so. You can modify the preparation and payment flow to exclude rejected items so that the item is refunded or never charged. In some implementations, rejected items may be replaced with other items, such as similar items, similar cost items, new offers, discounts, customer notifications, and so on.

In addition, the techniques herein work with a variety of hardware and software platforms by porting instructions and data to a consensus system through the API with little or no modification to its source code. Since it can be interfaced, any third party service can be onboarded and integrated for delivery of items from the merchant to the buyer, or any other service without any configuration or termination relationship with the merchant. Can be made possible to provide. Through the interaction of computing devices, mobile devices, and sensors, the implementations of this specification are constantly changing situations of merchants, buyers, service areas, third-party services, hardware and software platforms, and third-party services themselves. And to accommodate conditions, it is possible to manage an unpredictable shared ecosystem 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 different sources via API, porting instructions and data into a format understood by different services, and transferring the data. You can filter to determine relevance to different merchants and services, and use analysis to structure or restructure different merchant tasks such as delivery, booking, content aggregation, or content display.

Some implementations herein describe bidirectional APIs or push-pull APIs, in which information travels in both directions and the API endpoint is associated with both applications communicating. Means. However, some implementations can perform a unidirectional API so that the application only has to push the information or pull the 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. In addition, the techniques described above and below can be practiced in several methods and in some contexts. Some example implementations and contexts are provided with reference to the figures below, as described in detail below. However, the following implementations and contexts are just a few of many.

FIG. 1 shows an exemplary architecture 100 capable of implementing the techniques described herein. The architecture 100 comprises one or more users 104 (hereinafter "users 104") and one or more merchants 106 (hereinafter "merchant 106") of applications such as consensus services, buyers at merchant positions, and third-party services. One or more third-party services 108 (hereinafter, depending on the context, "delivery service 108", "deliverer service", "reservation service 108", "content service", and collectively referred to as third-party service. A consensus system or application that communicates with one or more card payment network computing devices 110 and / or one or more bank computing devices 112 to perform various processes (the "Consensus Service". Also referred to as) includes the service provider 102 associated with. Third party services can also include services provided by service providers, such as for delivery, booking, or content aggregation and management. Often, the service provider 102 provides one or more application programming interfaces (APIs) 114 to allow the user 104 and / or the merchant 106 to access the consensus service provided by the 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 messages to be sent to a web application, sometimes asynchronously. The application server can send push messages at any time, even when the web application or user agent is inactive. Push services ensure reliable and efficient delivery to user agents. Push messages are delivered to a service worker running at the origin of the web application, who can use the information in the message to update the local state or display a notification to the user. The pull API acts, for example, to extract data based on a scheduled job set to run at certain intervals. The system continues polling the source until certain conditions are met.

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

A merchant may include any entity or entity engaged in providing an entity or service for acquisition by the buyer in exchange for consideration received from the buyer. Actions attributed to a merchant can include actions performed by an employee of the merchant or other agents, and therefore, unless otherwise discussed herein, the distinction between a merchant and its employees is lined up. I won't get it. In addition, the buyer may include any entity that obtains an entity or service from a merchant by purchasing, renting, leasing, borrowing, licensing, etc. Hereinafter, goods and / or services may be referred to as items. Items can include finished goods, partially finished goods, raw materials, and the like. Thus, the merchant and the buyer can interact with each other to make a transaction in which the buyer obtains one or more items from the merchant and instead the buyer provides payment to the merchant.

A third party service, such as a delivery service, can include an entity engaged in the delivery of an item. The third party service can retrieve the item from the delivery pickup location (eg, the merchant's location) and transfer the item to the delivery drop-off location (eg, the buyer's location). Some implementations of this specification provide innovations that allow merchants to reconcile delivery requests (also referred to as orders) coming from different delivery portals 108. Using such techniques, merchants can adjust and synchronize orders with respect to inventory, ordering times, customer loyalty ratings, and so on.

Third party services such as restaurant management services can include any entity that allows bookings at those locations, such as online bookings or personal bookings. The term booking is also intended to include appointments, personal dining, pick-ups, and the like. Third party services can receive requests to make reservations at the merchant location. Some implementations of this specification provide innovations that allow merchants to reconcile booking requests (also referred to as bookings) coming from different booking portals 108. Using such techniques, merchants can adjust and synchronize orders with respect to seat availability, meal preferences, time, location, and items available on the menu.

Third party services such as content aggregation services can include any entity engaged in delivering the item. Third-party services know what their customers want to see, without having to think about what other third-party services are doing, and especially with respect to merchant stores. Content can be displayed without any need. Some implementations herein provide innovations that allow merchants to reconcile content such as menus across different third party services 108. Using such techniques, merchants can adjust and synchronize menus and other content with respect to profiles, times, locations, and other such specifications of third party services. Menus or menu updates can be pushed as a single update or notification at the same time on all third party services. Alternatively or additionally, menus and other such content, such as displaying content, ordering items, etc., are the relationship between third party services and merchants, the availability of items, the time of day, and others. It can be configured according to such factors.

As mentioned above, the service provider 102 exposes one or more APIs 114 of the consensus service so that the computing device associated with the user 104 and / or the merchant 106 is a third party service provided by the service provider 102. Allows access, harmonization, normalization, refactoring, coordination, and / or interface, so that the merchant or user process is optimally structured. For the sake of brevity, in the example of FIG. 1, the computing device associated with the user 104 and / or the merchant 106 is referred to as the "acquisition device". 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 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 delivery requests from different third party services. While making the request, the service provider can use the consensus service 132 to determine the received order and the timing of the order. The consensus service 132 uses, for example, a machine learning model to determine when an order should be placed, which items can be collected for preparation, and so on. The consensus service 132 schedules an order for the kitchen display system (not shown) associated with the merchant. In this way, the merchant does not have to maintain multiple tablets to accommodate orders coming from different sources. A single tablet shows, for example, the source of an order, the timing, the estimated time of delivery, and the new order of preparation, based on, for example, the timing of the order, the source, the location, the time of preparation, and so on. Similarly, in response to a reservation request, the consensus service 132 creates a single list of reservations and a method of distributing (distributing) seats and reservations among users and merchants. In addition, the consensus service can interface with the parties to communicate the progress of the request in real time or near real time.

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

In addition, the acquisition device can communicate with the service provider 102 via one or more APIs 114 to acquire status updates regarding the delivery of items ordered by another third party service or another user. In such cases, service provider 102 monitors the location of the delivery person (eg, third party service 108) assigned to deliver the item, or from a third party service associated with the delivery person. Such information can be obtained, information can be obtained from the merchant selling the item (eg, merchant 106), and / or other information can be obtained. The service provider 102 can determine the delivery status of the item and send the delivery status to the acquisition device. The delivery status may be displayed via the item acquisition interface 120 (b). The status is determined in response to a request from the capture device (eg, in response to a message sent over one or more APIs 114), periodically, and / or in response to the occurrence of another event. , And / or may be provided to the acquisition device. As shown in FIG. 1, the item acquisition interface 120 (b), when selected, is the current location of the assigned third party service device, the route traveled by the assigned third party service device, It may include a button 126 that displays a map showing routes etc. that may be further taken by a third party service device assigned to pick up or deliver the item.

In the example of FIG. 1, the delivery service information request 128 represents the communication transmitted by the acquisition device to the service provider 102 via one or more APIs 114, while the delivery service information 130 represents how the orders are ordered. A service provider, such as a consensus call to show how a concurrent order request is processed, fraudulent requests, delivery times, seating plans, and other information for merchants to schedule and organize actions. Represents the communication sent back from 102 to the acquisition device. The delivery service information request 128 may include information regarding the delivery of the item (eg, cost estimate, delivery time estimate, etc.), acceptance / rejection indication (index, display) of the delivery proposal, request for information regarding the delivery status, and the like. can. The delivery service information 130 can include delivery proposals, information about the delivery status of the item, and the like.

In some cases, the acquisition device can work with the service provider 116. Service provider 116, and related applications such as consensus services, can provide resources that operate remotely and / or independently from the acquisition device and / or service provider 102. In one example, service provider 116 may be associated with merchant 106 to manage purchases, inventory, and / or other processing. The service provider 116 can provide an online site or work with a local application (eg, desktop application, mobile application, etc.) on the acquisition device. Illustratively, service provider 116 is an online web for pizza restaurants and all delivery services that customers can order so that customers (and / or pizza merchants) can place pizza orders with pizza merchants. The site can be provided. In this way, the communication transmitted and / or received by the acquisition device to and from the service provider 102 may be routed through the service provider 116. In other words, the service provider 116 can act as an intermediary between the acquisition device and the service provider 102, and between the merchant and the third party service. This type of architecture allows data to be selectively and secretly shared between parties so that only the data relevant to the parties is revealed. The service provider 116 can communicate with the service provider 102 via one or more APIs 114. It can provide seamless integration of the delivery service provided by service provider 102 into the technology associated with merchant 106. Returning to the pizza restaurant example above, the pizza restaurant website can integrate the delivery service of the service provider 102 by communicating with the service provider 102 via one or more APIs 114. In some cases, this can happen without the customer knowing that the pizza restaurant is using such a delivery service (eg, as the delivery appears to be provided by Merchant 106). In another example, information can be communicated to the customer indicating that the delivery service is provided by the service provider 102 (eg, a pop-up window indicating that the pizza is delivered by Company X). 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 communicates with the third party service 108 to track the location of the third party service 108, request delivery of the item, and status information about the delivery (eg, the item was picked up or dropped off). You can receive confirmation from a third-party service), and so on. In the exemplary environment 100, the service provider 102 receives an indication of acceptance of a delivery proposal or recommended proposal from the acquiring device and selects a third party service to deliver the item. The service provider 102 can identify the location of the plurality of third party services and select the third party service (in this case, the third party service 108) to transfer the item to the delivery location. The service provider 102 can then send a delivery request 134 to a third party service 108 requesting delivery of the item, in response the third party service 108 indicating acceptance or rejection of the delivery request ( Indicators, display) can be sent.

In some cases, the service provider 102 may have any party within the environment 100 pay. For example, the service provider 102 may transfer funds from the account associated with the user 104 to the account associated with the merchant 106 as payment for the item. In addition, funds may be transferred from the account associated with the service provider 102, the merchant 106, and / or the user 104 to the account associated with the third party service 108 for delivering the item. Further payments can be made to the service provider 102 to facilitate the transaction.

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

The merchant bank may be a registered member of the Card Association (eg, Visa®, MasterCard®, etc.) or may be part of a card payment network. The card-issuing bank can issue a payment card to the user, and the card-issuing bank can pay the merchant bank for purchases made by the cardholder who issued the 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. In addition, in some examples, the user may use a debit card instead of a credit card, in which case the bank computing device of the bank that supports the debit card will communicate about the transaction in which the user is participating. Can be received. In addition, there may be computing devices from other financial institutions involved in some type of transaction or alternative system architecture, so the above are just a few examples for discussion purposes.

The one or more card payment network computing devices 110 and / or the one or more bank computing devices 112 may be implemented as one or more computing devices such as servers, laptop computers, desktop computers, and the like. One or more computing devices can be configured with clusters, farms, data centers, cloud computing environments, or a combination thereof. In one example, one or more computing devices provide cloud computing resources, including computational and storage resources.

As mentioned above, the computing device 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 can include short-range wireless communications such as Bluetooth® and Bluetooth® Low Energy, wired networks, or any other such network, or any combination thereof. Thus, one or more networks 118 include wired and / or wireless communication, including Bluetooth®, Bluetooth® Low Energy, Wi-Fi, and cellular communication technologies, as well as wired or fiber optic technology. Both technologies can be included. The components used for such communication can be at least partially dependent on the type of network, the environment selected, or both. As a result, one or more computing devices of architecture 100 can be communicably connected to one or more networks 118 by any method, such as a wired or wireless connection.

The techniques described herein can be implemented in different contexts and / or in different ways. As an example, the art may be implemented using merchant face-to-face components (eg, applications, online sites, interfaces, etc. designed for merchants). In this example, the merchant 106 can place an order for the customer. Specifically, the customer enters Merchant 106's facility, calls Merchant 106, sends a notification to Merchant 106 (eg, email, text message, social media post, etc.), or otherwise Merchant 106. Can communicate with. The merchant 106 interacts with the merchant face-to-face component (eg, the item acquisition interface 120 designed for use by the merchant) to select the item identified by the customer and / or other information provided by the customer. You can enter (for example, the shipping address). Upon receiving the delivery proposal from the service provider 102, the merchant 106 can communicate the delivery proposal information to the customer (eg, the delivery cost from the item acquisition interface 120 to the customer, displaying a screen with the delivery cost). Read, send notifications, etc.). Alternatively, the merchant 106 may refrain from providing the customer with information on the delivery proposal. For example, the merchant 106 may decide to provide the customer with free delivery, include the delivery cost in the total cost of the order (eg, without itemization), and so on. In any case, the merchant 106 may accept or reject the delivery offer and / or order the item based on the communication from the customer.

As another example, the technique may be implemented using customer face-to-face components (eg, applications, online sites, interfaces, etc. designed for the customer). In this example, the customer can place an order directly with the merchant 106. Specifically, a customer can navigate to an online site associated with Merchant 106, open an application associated with Merchant 106 (eg, a desktop application, a mobile application, etc.) and place an order with Merchant 106. .. In some examples, the customer can see delivery information (eg, delivery cost, estimated time for delivery, etc.) during processing, while in other examples, the information is not shown to the customer. , Or other information (eg, the total cost of the order) may not be included. In addition, customers can see delivery status updates via the customer face-to-face component.

As yet another example, the technique may be implemented automatically without user input. In this example, the information is not displayed or otherwise not communicated to the individual. For example, one or more criteria for accepting / rejecting a delivery proposal can be set so that the delivery proposal is automatically accepted / rejected if one or more criteria are met. Illustratively, a delivery proposal states that if the delivery cost is below (or above) the threshold cost, if the estimated delivery time is below (or above) the threshold time, then the estimated delivery pickup time is before (or above) a certain time. If (after), it may be accepted (or rejected), for example, if the estimated drop-off time for delivery is before (or after) a certain time. Thus, in some cases, delivery information may not be displayed via the item acquisition interface 120.

Similarly, in the case of a reservation, the booking request is made via an API call, by the merchant through the merchant device, by the customer through the customer device, by a third party device through the settings made by the merchant or the customer, or. It may be initiated automatically through a consensus service based on the machine learning of transactions between merchants and customers. Content harmonization requests, such as pressing customized menus or harmonizing menus across different services for content aggregation and analysis, content requests via API calls are made by the merchant through the merchant device, through the customer device. It may be initiated automatically by the customer, through settings made by the merchant or customer, by a third party device, or 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 in some cases) of FIG. Service provider 102 can be implemented as one or more computing devices such as servers, laptop computers, desktop computers, and the like. One or more computing devices can be configured with clusters, farms, data centers, cloud computing environments, or a combination thereof. In one example, one or more computing devices provide cloud computing resources, including computational and storage resources. 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), a graphics processing unit (GPU), a microprocessor, a digital signal processor, and the like.

Memory 204 may include software functions configured as one or more "modules". The term "module" is intended to represent an exemplary division of software for discussion and is not intended to represent any type of requirement or required method, method, or required organization. Therefore, although various "modules" or components are being discussed, their functionality and / or similar functionality can be arranged differently (eg, combined into a smaller number of modules and more. Divided into modules, etc.). Further, certain functions are described herein as being implemented as software modules configured to be performed by a processor, but in other embodiments any or all of the functions are by hardware logic components. It may be implemented in whole or in part (eg, it may be implemented). For example, but not limited to, 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), and more. System-on-chip systems (SOCs), compound programmable logic devices (CPLDs), and the like are included. As shown, the memory 204 can include a consensus service 207, a recommended module 208, a content aggregation module 210, a third party service module 212, and a payment transaction module 214.

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

The recommendation module 208 can perform processing to generate a proposal, such as a delivery proposal for the delivery of an item by the delivery service associated with the service provider 102. Another type of proposal may be a reservation proposal indicating a reservation for a user's reservation at a restaurant, or a seating plan associated with some user reservation requests. Yet another type of suggestion may be, for example, a menu update triggered by the merchant's kitchen display system and pushed to a third party service. In this case, the information 130 flows from the merchant device to the third party service and is executed, for example, on the user device 104. Often, the service provider 102 receives a delivery proposal request via one or more application programming interfaces (APIs) 216, responds to it, generates a delivery proposal, and sends the delivery proposal to the requesting entity. can do. The information contained in the delivery proposal request will be described in more detail below with reference to FIG. Recommendation module 208 contains information contained in the request for a delivery proposal, the status of the merchant's current or past orders, preparation time, and information about third-party services stored in the third-party service information data store 218 or elsewhere. (For example, the current location of the third party service, third party service profile information, third party data related to the processed order, order timing, order lag, etc.), stored in the merchant data store 220 or elsewhere. Delivery proposals can be generated based on information about the merchant (eg, merchant's current location, merchant profile information, etc.), information about the user (eg, user's current location, user profile, etc.), and so on.

The third party service profile information includes (i) delivery history information of the third party service indicating the average time for the third party service to deliver (for example, average time per mile, total average travel time, etc.). (Ii) Information indicating whether the third party service is on time for delivery pickup and / or dropoff, (iii) indicating the vehicle or vehicle type used by the third party service to transport the item. Vehicle information (eg, bikes, cars, vans, trucks, etc.), (iv) Historical location information indicating where third party services are generally located (eg, home address, third party services at a particular time) Facilities located above) etc. are included.

The merchant profile information includes (i) the amount of time (eg, accuracy, average, estimation, etc.) for preparing the item or item type for pickup (eg, cooking the item, manufacturing the item, etc.). Item preparation information to indicate, (ii) item information about the item provided by the merchant for acquisition (eg, item identifier, item cost / weight / volume / size / category information, etc.), (iii) to transfer the item. Contains information about the package used by the merchant (eg, shipping box size, shape, weight, volume, etc.).

Illustrative information that may be part of a delivery proposal includes:
● Delivery cost of item-6 for a third party service to pick up food from a restaurant and deliver it to the customer's location, for example, the price to use the delivery service of service provider 102 to deliver the item. Dollar fee). Shipping costs are the characteristics of the item, such as the size, shape, weight, volume, type, etc. of the item (eg, larger or heavier items can cost more, strangely shaped items (predetermined shape). (Items you have) can cost more, vulnerable (fragile) items can cost more than non-vulnerable items), information about third-party services (eg, costs are picked up from third-party services) Information about the merchant's time to prepare an item (eg, as the preparation time decreases (or increases)), which can increase in distance to, and the cost can increase as the number of available third-party services decreases). Cost can increase (or decrease), pickup position (eg, cost can increase as the distance from a particular point to the pickup position increases), drop-off position (eg, cost can start from a particular point) It can change based on factors such as (which can increase as the distance to the drop-off position increases), time (eg, cost can increase during peak delivery times such as evening).
● Amount of time for delivery of items (eg estimated time-delivery takes 20-30 minutes). The amount of time may generally be the time for a third party service to acquire the item and transfer it to the drop-off location. However, in some examples, the amount of time can include the time it takes to prepare the item by the merchant (for example, the amount of time is the total time from ordering an item to arriving at the customer's location). Can include). The amount of time for delivery is wacky, such as the characteristics of the item, eg size, shape, weight, volume, type, etc. of the item (eg, larger or heavier items may take more time to deliver). Shaped items (items with a given shape can take more time to deliver, vulnerable (fragile) items can take more time than non-vulnerable items), third-party services Information about (eg, the amount of time for delivery may increase as the distance from the third party service to the pick-up location increases, the amount of time for delivery as the number of available third party services decreases. It can change based on factors such as (may increase, etc.), time (eg, the amount of time may increase during peak travel times, such as during rush hours).
● Pickup time for delivery of an item (eg, estimated date and time when a third party service picks up the item, week, month, year, etc.). 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 pickup time is a time window (eg, 2 to 2:30 PM). In addition, in some cases, delivery proposals may include a deadline for the latest time for a third party service to pick up the item. Pickup time is information about third party services (eg, pickup time can move farther as the distance from the third party service to the pick up position increases, and pickup time is available third party. It can change based on factors such as moving farther as the number of services decreases), time (eg, pick-up time moves farther during peak delivery times such as rush hours).
● Drop-off time for delivery of items (eg, estimated date and time when a third party service will drop off the item, week, month, year, etc.). The drop-off time may be when the item is dropped off at the customer's location. In some cases, the drop-off time is a time window (eg, 3-4 PM). Drop-off time is the characteristic of the item, eg, the size, shape, weight, volume, type, etc. of the item (eg, larger or heavier items can take more time to deliver, unusually shaped items (predetermined). (Items with the shape of) can take more time to deliver, vulnerable (fragile) items can take more time than non-vulnerable items), information about third-party services (eg drop-off) Time can move farther as the distance from the third party service to the pick-up location increases, drop-off time can move farther as the number of available third party services decreases. ), Time (eg, drop-off time moves farther during peak delivery times, such as during rush hours), and so on.
● When the delivery proposal expires. In some cases, delivery proposals may expire if they are not accepted by a certain time (eg, time, day of the week, month, year, etc.). Therefore, the delivery proposal may be associated with an expired time (eg, tomorrow at 2:00 pm, two hours after receipt of the delivery proposal, etc.).
● For example, a third party service that can provide an order if the third party service for which the order was placed is not possible due to the delivery person or other technical difficulties.
● A sequence of items for the kitchen display system. Items are arranged by either order ID or item preparation time to allow the merchant to hold 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 analysis information based on aggregated data such as menu updates, delivery information regarding the progress of delivery, reservation lists, and the like. For example, the content aggregation module 210 may receive a delivery status update request via one or more APIs 216, generate delivery status information in response, and send that information to the requesting entity. In another example, such information about the status of delivery may be generated and transmitted automatically and / or when another event occurs. The content aggregation module 210 confirms the pick-up of the item at the position of the third-party service, the position of the merchant, and / or the indication (index, instruction) from the third-party service regarding the drop-off at the position of the customer, and the confirmation of the pickup. Information about the status of delivery can be generated based on a variety of information, such as communication from the merchant to indicate, communication from the merchant regarding the status of preparing the item (eg, the amount of time left to cook the dish). .. Therefore, the content aggregation module 210 may communicate with the third party service module 212 in order to receive location information about the delivery person.

The third party service module 212 can manage third party services. For example, the third party service module 212 tracks the location of the deliverer associated with the third party service (before, during, and / or after delivery) and selects the third party service for delivery. , Communicating with third party services to facilitate delivery, providing updates regarding delivery status, predicting the travel time of third party services to different delivery locations at different times and / or days, etc. Can be done. To do so, the third party service module 212 may store the information contained in the delivery proposal request, the information contained in the delivery status update request, the third party service information data store 218 or elsewhere. Information about the person service (eg, the current location of the third party service, third party service profile information, etc.), information about the merchant stored in the merchant data store 220 or elsewhere (eg, the current location of the merchant, merchant profile information, etc.) , Etc.), information about the buyer (eg, buyer's current location, user profile, etc.) and various other information can be analyzed. In some examples, the third party service module 212 can manage third party services through activation, movement, positioning, and / or deactivation, eg, through API.

As an example, the third party service module 212 may select a third party service to facilitate the delivery of the item 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 another example, delivery is arranged in response to the occurrence of other events. The third party service module 212 determines the location of the third party service relative to the merchant's location (eg, selecting the third party service closest to the pick-up location), the availability of the third party service (eg, available first). (Choose a tripartite service), the type of vehicle used by a third-party service to transport the item (eg, choose a third-party service that can transport that type of item delivered),. Various information can be used to select third party services, such as information about the items to be delivered (eg, size, shape, volume, type, etc.). The third party service module 212 can then communicate with the selected third party service to arrange delivery. Service provider 102 may provide information about the number of items to be transferred, the location of the merchant (or multiple merchants if multiple items are delivered), the requested pick-up time and / or drop-off time, and the like. can. If it is determined that multiple moves are required for delivery (eg, due to the number of items delivered, the size of the items delivered, the transport capacity of a third party service, etc.) , The third party service module 212 may notify the third party service of a plurality of moves and / or send an order to the plurality of third party services for delivery. In addition, the third party service module 212 informs the third party service of deliveries that are not urgent and may be performed during the downtime period during which subthreshold deliveries are scheduled for the third party service. The third party service module 212 can notify the third party service of the period (eg, "perform delivery at any time of the week between 8 pm and 10 pm"), or the third party service is 1. Since time is available throughout the day, week, etc., delivery can be performed. Often, the third party service module 212 communicates with the third party service through non-API channels and / or separate channels rather than one or more API 216s used to expose the delivery service to the entity.

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

The payment transaction module 214 can facilitate payment transactions initiated via various channels. As an example, a user can interact with a user device to place an order with a merchant. Here, the service provider 102 can communicate with the merchant to fulfill the order (eg, notify the merchant that the order has been placed and request the merchant to fulfill the order). As another example, the merchant can interact with the merchant device to place an order on behalf of the user. Here, the user can communicate with the merchant via telephone, principal, notifications (eg, text messages, email, social media, etc.) to indicate that he or she wishes to place an order with the merchant. In any of these examples, the user can provide payment at any time, such as at the time of ordering, while the item is being delivered, or at the time of drop-off (eg, interacting with a third party service device).

Users can provide payments via various methods such as cash, checks, payment cards, near field communication (NFC), Bluetooth®, accounts, electronic payments and the like. In some examples, the payment transaction module 214 enables cardless payments for transactions between users and merchants based on user-to-user device interactions and merchant-to-merchant device interactions. .. Thus, in some examples, a cardless payment transaction can include a transaction that takes place at a POS position, while the user's electronic payment account physically presents the payment card to the merchant at the POS position. You will be charged without having to. As a result, the merchant does not need to receive details about the user's financial account for the transaction 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 for the service provider 102 for the electronic payment account. As another example, a user can have a prepaid amount in an account that is maintained for use when making electronic payments. Other variants will be apparent to those of skill in the art.

In some cases, the payment transaction module 214 may store transaction information in the 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 includes information about the time, place, and / or quantity of the transaction, information related to the acquired item (eg, information identifying the item sold), and the type of payment used (eg, cash,). Checks, payment cards, electronic payments, etc.), as well as additional information such as buyer information can be included. For example, when a payment card is used, the transaction information can include data stored in the payment card (eg, track 1 data (cardholder name, card number and other card information)). In addition, upon completing a transaction, the buyer can sometimes provide a receipt email address for receiving receipts via email. Other examples of transaction information that can be captured include item information (eg, an itemized list of acquired items, the price paid for each item, a description of the item (size, flavor, color, etc.)). Geographical location data indicating the geographic POS (Point of Sale) location of a particular transaction, online / offline card data, data describing the merchant (eg, merchant identifier, merchant category code (MCC), etc.), request for delivery proposal Contains information contained in, information contained in delivery proposals, any type of data received when authenticating to the buyer's social network, and / or various other types of information. In some examples, transaction information may be used to store information about the merchant in the merchant data store 220 (eg, the cost of an item provided by a merchant is the transaction information about the transaction at the merchant's facility. May be obtained from).

FIG. 2 shows the components and data of service provider 102 as being in a single location, but these components and data are alternative to different computing devices and / or different in any way. It can be distributed over positions. As a result, the functionality may be implemented by one or more computing devices, and the various features described are distributed in different ways across different computing devices. Multiple computing devices may be placed 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 server, or by multiple different buyers or company servers and / or services.

FIG. 3 shows exemplary details of the merchant device 300. For example, the merchant device 300 may be used by the merchant 106 in FIG. The merchant device 300 includes a laptop computer, a desktop computer, a server, a smartphone, an electronic reader device, a mobile handset, a mobile information terminal (PDA), a portable navigation device, a portable game device, a tablet computer, a wearable computer (for example, a smart watch, an optical device). Head-mounted displays (OHMD), portable media players, televisions, set-top boxes, in-vehicle computer systems, equipment, cameras, robots, hologram systems, security systems, home-based computer systems (eg, intercom systems, homes, etc.) It can be implemented as a media system, etc.), a projector, an automatic cash deposit / payment machine (ATM), and the like. In some embodiments, the merchant device 300 can perform third party services such as delivery service, booking service, menu service, review service and the like. In one embodiment, the merchant device 300 can interface with third party services and other services via one or more consensus services 207. In one example, the service provider may provide API endpoints for communicating with third party services and the merchant device 300, and the API endpoint may provide API endpoints 114 for access by the service provider. , You don't have to. Thus, the service provider's consensus service 207 may be able to pull, push, or push and pull data from external services.

The merchant device 300 may also be associated with additional devices to manage incoming orders, reservations, appointments, notifications, updates, alerts, and so on. For example, the merchant device 300 may be connected to or associated with one or more tablets, 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 embodiments described herein, a tablet is configured so that all orders, regardless of source, are synchronized and presented and handled on a single tablet. It may be integrated into one. Similarly, for booking, the merchant device 300 may be associated with an onsite booking system that tracks the physical space for occupancy / availability.

The merchant device 300 may include one or more processors 302, memory 304, one or more network interfaces 306, and one or more displays 308. The one or more processors 302 can include a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a digital signal processor, and the like. The one or more displays 308 can include touch screens, liquid crystal displays (LCDs), light emitting diode (LED) displays, organic LED displays, plasma displays, electronic paper displays, or any other type of technology. Although not shown, the merchant device 300 may include or be associated with other components such as cameras, microphones, speakers, projectors, printers, and / or sensors. One or more cameras may include a front camera and / or a rear camera. The one or more sensors may include an accelerometer, compass, gyroscope, magnetic field meter, Global Positioning System (GPS), sensory sensor (eg, for odor), or another sensor. The merchant device 300 may further include or be associated with a keyboard, mouse, pen, voice input device, touch input device. The memory 304 may include a merchant module 310 and a location module 312.

The merchant module 310 (and / or the position module 312) may represent a merchant face-to-face component that may be commonly used by a merchant. In some examples, the customer can interact with the merchant face-to-face component (for example, to confirm payment, provide delivery information, or provide other input). The merchant module 310 can perform various processes to assist the merchant in facilitating transactions with customers, managing deliveries, managing inventories, and the like. The merchant module 310 can provide various interfaces and / or dashboards. In some cases, the merchant module 310 may be referred to as applications such as delivery orders, pre-orders, and acquisition applications for menu updates / preferences.

The merchant module 310 can communicate with the service provider 102 to use the delivery service provided by the service provider 102. As an example, the merchant can interact with the item acquisition interface provided by the merchant module 310 (eg, the item acquisition interface 120) to place an order on behalf of the customer. If the merchant module 310 determines that delivery may be requested (eg, a customer-based automatic determination indicating that the order wishes to be delivered), the merchant module 310 generates a request for a delivery proposal and the service provider. A request may be sent to the service provider 102 via one or more APIs to request information regarding the use of the delivery service recommended by 102. The request information may be provided by the customer or merchant, or may be obtained from a data source (eg, user profile, merchant profile, etc.). Illustrative information that can be part of a delivery proposal request includes:
● Item Pickup Position-The location where the item is picked up from the merchant for delivery to the customer. The pickup position may generally be the position of a merchant (eg, a facility), but any position such as a warehouse, house, PO box, street corner, etc. may be used. The pickup position may be stationary or moving (eg, in the case of a moving merchant).
● Drop-off location (also known as delivery location) -The location where the item is delivered to the customer. The drop-off location can generally be the location of the customer, such as a house, PO box, street corner, facility where the customer is currently located. The drop-off position may be stationary or moving (eg, in the case of a moving customer).
● Requested Pickup Time-Time, week, month, year, etc. to get the item from the merchant for delivery. The requested time for pickup may be a specific time, a window of time, or the like. In some cases, the requested pickup time may be as fast as possible (eg, if the item has already been created, or in other situations). If the pick-up time is not specified in the delivery proposal request, service provider 102 can assume, for example, that the pick-up time is as early as possible.
● Amount (number) of items acquired-Amount of items purchased from merchants. In some cases, the service provider 102 can use this information to determine the size of the order (eg, the amount of space required to transfer the order).
● An item identifier that identifies the item to be retrieved. In some cases, the service provider 102 may use this information to determine how much space is needed to transfer the order, the type of vehicle required to transfer the item, the type of item (eg, for example). Information about an item can be looked up to determine (vulnerable vs. non-vulnerable, corrupt vs. non-corruption, etc.).
● The characteristics of the item to be acquired (eg size, shape, weight, volume, type, category, etc.). In some cases, the service provider 102 can use this information to determine the amount of space needed to transport the item.
● Tags associated with the retrieved item (for example, tags that indicate a particular category). For example, items may be tagged with a given label associated with a category of food that requires special handling for delivery (eg, pizza or that needs to be kept warm and / or upright). Catered food such as soups, foods on trays that require special handling, televisions that need to be handled carefully, etc.). In some examples, the service provider 102 uses this information to determine how much space is needed to transfer the order, the type of vehicle required to transfer the item, the type of item ( For example, vulnerable vs. non-vulnerable, corrupt vs. non-corruption, etc.) can be determined.
● The price of the order (for example, the cost of the item or order).
● Pick-up instructions for items. For example, the merchant can specify that the bicycle will be picked up for delivery at the rear of the store.
● Delivery instructions for items. 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, on a particular type of vehicle, by a particular third party service, or the like. ..
● Customer contact information (for example, phone number, email address, customer geographic location, etc.). As an example, customer contact information can include the customer's address.

The merchant module 310 is described as providing the information contained in the request for a delivery proposal, but in some cases the information may be determined (at least in part) by the service provider 102 (eg, the service provider). 102 may receive the item identifier and check the item size, metered amount, etc.).

After submitting the delivery proposal request to the service provider 102, the merchant module 310 can receive the delivery proposal from the service provider 102. In some cases, the information from the delivery proposal is communicated to the customer. For example, the merchant may inform the customer of delivery costs, estimated delivery times, and / or any other information. In another example, the information from the delivery proposal does not have to be presented to the customer. For example, the merchant can see the information on the delivery proposal and / or include that cost in the total cost of the order. Therefore, in some cases, the delivery may appear to the customer to be processed by the merchant. In any case, the merchant module 310 can send the acceptance or rejection indication (index, instruction) of the delivery proposal to the service provider 102 via one or more APIs.

The merchant module 310 can then communicate with the service provider 102 via one or more APIs to provide and / or receive information about the status of the transaction. For example, the merchant module 310 sends information indicating where the item is in the preparation process (eg, almost completed, completed, ovened, bagged, ready for pickup, etc.). do. In another example, the merchant module 310 determines the status of delivery by the delivery service (eg, the specific location of the delivery person of the third party service, how far the third party service is, and whether the item has been dropped off. , Whether the delivery person associated with the third party service is in transit to the pick-up location, etc.) can be received from the service provider.

The merchant module 310 can receive orders via various channels. For example, the merchant module 310 places 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 be received. The second order may be received from another party, such as service provider 102 and / or the service provider associated with the merchant. In any case, the order 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 an order, the presentation of information regarding the progress of preparation of an order, the presentation of information regarding the delivery status of an 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.

The merchant module 310 may apply one or more schemes to provide payment for the delivery service used by the service provider 102. As an example, the delivery cost for using the delivery service of service provider 102 may be charged to the customer (eg, directly per item, monthly, etc.). As another example, the merchant may, in each case, or, for example, an order with an item exceeding the threshold number, an order having an quantity exceeding the threshold amount, the customer being associated with a particular status (eg, the customer delivering). Decided to offer payment for shipping costs if one or more criteria are met, such as paying a monthly subscription fee for the service or purchasing a certain number of items over time) It can (for example, do not charge the customer).

The merchant can be billed by the service provider 102 for the use of the consensus service connecting several delivery services in various ways, such as monthly, per item, etc., and should be paid to the merchant by the service provider 102. Balance the quantity (eg, subtract the cost of the delivery service from the quantity payable by the service provider 102 to the merchant).

The merchant module 310 may additionally or optionally perform other processing. In one example, the merchant module 310 accepts payments from a customer (eg, via a card reader, NFC connection to a customer device, Bluetooth® connection to a customer device, etc.) and provides a receipt for the item. Transactions with customers by doing (including printing receipts), receiving customer input for items obtained by the customer (eg, confirmation, credit card signing, etc.), etc. Can be facilitated. In another example, the merchant module 310 notifies the merchant of the inventory level (eg, the number of items currently in stock), orders additional inventory, and views notifications from the service provider 102 regarding inventory. It can allow merchants to manage inventory, by providing inventory for acquisition to others, asking for funding for inventory, and so on. In yet another example, the merchant module 310 can provide data analysis for sale, inventory, or other information.

The function of the merchant module 310 is described as being contained in a single component, but the function may be divided into any number of components. In some cases, functionality may be split into separate applications, which may be linked to each other (eg, access one application by selecting a link within another application).

The position module 312 can determine the position of the merchant device 300. In some cases, the location may be provided to the service provider 102 or used locally to determine the location of the merchant, process the transaction if the customer is located within a particular neighborhood of the merchant device 300, and so on. Facilitate functions. The location module 312 locates the geographic location of the merchant device 300 from geo-positioning technology (eg, satellite-based systems-Global Positioning System (GPS)), cell tower location data, wireless access point location data, wireless beacon location, etc.). It can be determined. Therefore, the location module 312 utilizes data from the merchant device 300's position sensor, such as a GPS receiver or communication interface that can determine the geographic location of the merchant device 300 (eg, from a cell tower or wireless access point). be able to.

For some types of business, the merchant device 300 may be associated with a merchant's store or other business location, and thus may be a fixed position that does not usually change daily. However, in other types of business, the merchant device 300 is when the merchant operates a food truck, is a street vendor, a cab driver, etc., or otherwise has a mobile business (eg, the buyer's house, etc.). You can move from time to time, such as (for merchants who sell items at business locations).

FIG. 4 shows exemplary details of the user device 400. For example, the user device 400 may be used by the user 104 in FIG. The user device 400 includes a laptop computer, a desktop computer, a server, a smartphone, an electronic reader device, a mobile handset, a personal digital assistant (PDA), a portable navigation device, a portable game device, a tablet computer, a wearable computer (for example, a smart watch, an optical device). Head-mounted displays (OHMD), portable media players, televisions, set-top boxes, in-vehicle computer systems, equipment, cameras, robots, hologram systems, security systems, home-based computer systems (eg, intercom systems, homes, etc.) It can be implemented as a media system, etc.), a projector, an automatic cash deposit / payment machine (ATM), and the like. In some examples, the merchant device 300 may be a mobile device. In one implementation, the user device 400 can execute a third party service such as a delivery service, a reservation service, a menu service, and a review service. In one embodiment, the user device 400 can interface with a merchant service, such as the merchant device 300, via one or more consensus services 207. In one example, the service provider may provide the API endpoint 114 for communicating with the third party service and the merchant device 300, and the API endpoint 114 may provide the API endpoint for access by the service provider. You don't have to. Thus, 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 a third party server, for example, like a service provider.

The user device 400 may include one or more processors 402, memory 404, one or more network interfaces 406, and one or more displays 408. The one or more processors 402 can include a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a digital signal processor, and the like. The one or more displays 408 can include touch screens, liquid crystal displays (LCDs), light emitting diode (LED) displays, organic LED displays, plasma displays, electronic paper displays, or any other type of technology. Although not shown, the user device 400 may also include or be associated with other components such as cameras, microphones, speakers, projectors, printers, and / or sensors. One or more cameras may include a front camera and / or a rear camera. The one or more sensors may include an accelerometer, compass, gyroscope, magnetic field meter, Global Positioning System (GPS), sensory sensor (eg, for odor), or another sensor. The user device 400 may further include or be associated with a keyboard, mouse, pen, voice input device, touch input device. The memory 404 can include a customer module 410 and a location module 412.

Customer module 410 (and / or location module 412) can represent a customer face-to-face component that may be commonly used by a customer. In some examples, a merchant can interact with a customer-facing component (for example, to confirm payment, provide delivery information, or provide other input). The customer module 410 can perform various processes to help the customer facilitate transactions with the merchant. In doing so, the customer module 410 can provide various interfaces and / or dashboards. In some examples, the customer module 410 may be referred to as an application such as an item acquisition application. Further, in some examples, the customer module 410 works 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.

The customer module 410 can communicate with the service provider 102 to use the delivery service associated with the service provider 102. As an example, the customer can interact with the item acquisition interface provided by the customer module 410 (eg, the item acquisition interface 120) to place an order with the merchant. If the customer module 410 determines that delivery may be requested (eg, automatic determination based on user profile settings or previous purchases, determination based on customer input indicating that the order is desired to be delivered, etc.), the customer module 410 may determine. A request can be sent to the service provider 102 via one or more APIs to generate a request for a delivery proposal and request information about the use of the delivery service provided by the service provider 102. The request information may be provided by the customer or may be obtained from a data source (eg, user profile, etc.). Often, the customer module 410 provides the information contained in the delivery proposal request, but in some cases the information may be determined (at least in part) by service provider 102 (eg, service provider 102). May receive the item identifier and investigate the item size / pay-as-you-go, the service provider 102 may identify the customer, investigate the customer's preferences, etc.).

After submitting the delivery proposal request to the service provider 102, the customer module 410 can receive the delivery proposal from the service provider 102. In some cases, the information from the delivery proposal is communicated to the customer. For example, the item acquisition interface can display delivery costs, estimated delivery times, and / or any other information. In another example, the information from the delivery proposal does not have to be presented to the customer. For example, the item acquisition interface may not display the shipping cost as an itemized element and may include the shipping cost in the total cost of the order. Therefore, in some cases, the delivery may appear to the customer to be processed by the merchant. In any case, the customer module 410 can send an indication (index, instruction) of acceptance or rejection of the delivery proposal 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 about the status of a transaction. For example, the customer module 410 may have an item ready status (eg, almost completed, completed, ovened, bagged, pick-up ready, etc.), delivery service delivery status (eg, eg). You can receive information about the delivery person's specific location, how far the delivery person is, whether the item has been dropped off, whether the delivery person is in transit to the pickup position, and so on. 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 delivery person's location. Advertisements may be displayed in addition to or in place of this. By way of example, the customer module 410 can display an advertisement for an online site related to delivering an item for a merchant. Advertising can encourage customers to use online sites to place orders in the future instead of ordering directly from the merchant. In other figures, 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 about merchants within a predetermined proximity range via an interface. The user can select a merchant and order the goods with the merchant. In addition, or as an alternative, the customer module 410 provides payment for the item by the user (eg, via a card reader, NFC connection to the merchant device, Bluetooth connection to the merchant device, etc.). It can be possible to receive receipts of. In addition, the customer module 410 can allow the user to check in to the merchant to perform a cardless payment transaction.

The position module 412 can determine the position of the user device 400. In some examples, the location is provided to the service provider 102 or used locally to facilitate various functions such as handling transactions when the customer is located within a particular neighborhood of the merchant device. do. The location module 412 is based on geolocation technology (eg, satellite-based systems-Global Positioning System (GPS)), cell tower location data, wireless access point location data, wireless beacon location, etc., to the geolocation of the user device 400. Can be determined. Therefore, the location module 412 utilizes data from the position 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 a cell tower or wireless access point). be able to.

In some implementations, the user device 400 is also configured to receive a reservation proposal in response to an automatically triggered reservation request via the user device 400, the merchant device 300, or, for example, through a service provider. Will be done. The user of the user device 400 can accept or reject the reservation proposal. The user device 400 can also provide a preference for the seat type preferred by the user for either current or future reservations. Preferences can also include chefs, items, merchant locations, times, alternative merchants, dishes of choice, etc., so that the service provider can, for example, if a preference reservation is not available or from a different source. An alternative can be generated for the user in case of conflict with another reservation.

5-7 show 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 a service provider 102, a merchant device 300, a user device 400, and / or a third party service device which can be a user device. It can be described as being performed by the computing device being described. However, processes 500, 600, and 700 may be performed by other devices. In addition, the device may be used to perform other processing.

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

FIG. 5 illustrates an exemplary process 500 that exposes one or more APIs to enable an entity to use third party services related to other services provided by service provider 102.

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

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

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

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

At 510, the service provider 102 may receive indications (indicators, instructions) of acceptance or rejection of delivery proposals via one or more APIs. Acceptance or rejection indications may be received from the computing device associated with the merchant or user.

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

At 514, the service provider 102 can identify a third party service from among several third party services in order to transport the item. In many cases, such identification can be performed in response to receiving an indication (indicator, instruction) of acceptance of the delivery proposal. The third party service device can 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 may send a communication to a third party service device to transfer the item. Communication may require the associated third party service to retrieve the item from the pickup location and transfer the item to the delivery location. The communication can include various information about delivery, such as information in a request for a delivery proposal, information in a delivery proposal, and so on. The communication may be transmitted over a non-API channel, etc., via an API different from that used to communicate with the merchant or customer. In some examples, the service provider 102 may receive acceptance indications (indicators, instructions) from a third party service device instruction indicating that the third party service will deliver the item.

At 518, the service provider 102 can receive location information and / or delivery information. Location and / or delivery information may be received from third party service devices and / or merchant devices. In many cases, such information may be received after delivery has begun. Location information can generally indicate the location of a third party service. Delivery information can include, for example, input from a third party service indicating the location of the third party service, information from a third party service indicating that an item has been picked up, or information from a merchant.

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

At 522, the service provider 102 may send the delivery status to the computing device associated with the merchant or customer. The computing device can display the delivery 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 may communicate with the merchant to request that the merchant fulfill the order. If accepted by the merchant, the merchant may send an indication of acceptance (indicators, instructions) and the service provider 102 may proceed to facilitate delivery by a third party service. In addition, 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 a service provider 102 via one or more APIs and coordinating actions using a consensus service using a third party service integrated with the service provider 102. show. Processing 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 displaying the item acquisition interface via the display. The interface may also allow the user to place an order for an item. The interface may also be a kitchen display system that allows merchants to view orders, where orders are sorted by item in the order in which they should be prepared, resulting in similar items in the internal kitchen. It may be collected to create a new ticket for the purpose, change the flow for items that are no longer available, and so on. The interface can also be an interface for vacant and unavailable reservations that indicate which reservations are reserved and from which sources they are reserved. The interface may also be an interface for items currently available to the merchant, allowing the merchant to change menus in real time based on availability, popularity, merchant location, and so on.

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

At 606, the acquisition device can determine that information regarding the delivery of the item is requested. It receives input from the user indicating an interest in having the item delivered, identifies the distance between the customer's location and the merchant's location (eg, if the distance is greater than the threshold, the delivery is It can be determined that it is requested) and the like. In some examples, delivery information may be automatically determined to be required for each order.

At 608, the acquisition device may send a request for delivery of an item to the service provider 102 via one or more APIs associated with the service provider 102. The request can request a delivery proposal. In some cases, the request may include delivery location, pickup location, requested time for pickup, number of items retrieved, item size, whether the item is associated with a given category, item weight, etc. Can be shown. Delivery proposals also receive reservation proposals, how to distribute reservation quotas between third party services, how to accept orders or distribute deliveries between third party services, and receive from third party services. Includes how to order the ordered orders and how to send or receive updates for the order, such as menu updates, order updates, etc.

At 610, the acquisition device can receive a delivery proposal from the service provider 102. The delivery proposal is the cost for delivery of the item by the delivery service associated with the service provider 102, the estimated time for delivery of the item, the estimated pickup time for delivery of the item, the estimated drop for delivery of the item. It can indicate the off time and so on.

At 612, the acquisition device may determine whether the delivery proposal is accepted or rejected. In some examples, the capture device displays the information contained within the delivery proposal (eg, cost for delivery of the item, estimated time for delivery of the item, etc.) and user input for acceptance of the delivery proposal. Can be received. In another example, the acquisition device can automatically determine whether to accept or reject a delivery proposal when one or more criteria are met. Therefore, the acquisition device may refrain from displaying the delivery proposal information in some cases.

At 614, the acquisition device can send an indication (indicator, instruction) of acceptance or rejection of a delivery proposal 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 delivery, in other cases a 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 delivery status of an item via one or more APIs associated with service provider 102. The acquisition device can then receive the delivery status of the item from the service computing device 102 and display the delivery status. In another example, the delivery status may be determined on the merchant device (eg, based on knowing that a third party service has picked up the item), and the delivery status is sent to the customer device. May be good.

FIG. 7 illustrates an exemplary process 700 for notifying a third party service or merchant device regarding delivery of items, reservation of vacant / competing seats, menu updates, and the like.

At 702, the third party service device can determine the geographic location of the third party service device, such as the user device. Geographic location is based on data from location sensors on third-party service devices, such as satellite-based sensors (eg, Global Positioning System (GPS), cell tower radios, wireless access point radios, radio beacon position sensors, etc.). May be determined.

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

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

At 708, the third party service device may present a notification requesting that the item be delivered (eg, taken from the merchant's facility and transferred to the delivery location). The notification may be presented via a display, a speaker, or the like. In some cases, the information may require a third-party service interface that facilitates the delivery of the item (eg, the third-party service accepts the delivery, confirms that the delivery has been made, or requires additional delivery. Displayed via an interface that allows things such as. The third party service device 500 can present any information contained in the communication received at 1006.

At 710, the third party service device may receive input from the third party service and / or send an acceptance or refusal regarding the 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 shows an exemplary process 800 communicating via one or more APIs exposed by a service provider to provide status updates for an order. In FIG. 8, the elements shown at the bottom of FIG. 8 (below the line established by one or more service provider API 802) can represent actions performed by a service provider such as service provider 102.

In the example of FIG. 8, the computing device 801 associated with the user performing the plurality of third party services enables the merchant device 106 and the associated merchant to generate or create an order placed on the third party service. The associated computing device 804 implements a user interface 806 that allows the merchant device 106 and the associated merchant to generate or create an order placed. As shown in 810, by requesting information from the service provider, an incoming order or an order listed on the left side of the user interface 806 can be obtained. At 812, the service provider can determine the status of an order by acquiring performance information and determining the location of a third party service assigned to each of the merchant (company A) orders. At 814, the service provider can generate details about the status and send the details to the computing device 804 for display via the left side of the user interface 1206.

The customer can use the computing device 801 to generate an order or order request. Therefore, a third party service 108 running on the computing device 801 can be used to trigger such an order. A third party application, such as the third party application 108, interfaces with the service provider 102 by delivering a status update endpoint, or API endpoint 819, to receive order 826 details, the order from anywhere. Get the status of preparation and delivery 824, how scheduled in the list in order. The service provider can also schedule orders delivered by a different company than the one used to place the order, for example, based on the user's proximity to a delivery person belonging to another shipping company. ..

A computing device 802 associated with a merchant is also shown. The left side of the user interface 806 is a relatively high level of all orders (or a certain number of orders) placed to a merchant, regardless of the channel on which the order is placed (eg, phone, customer application, website, etc.). Information can be displayed. On the other hand, on the right side of the user interface, more detailed information about one or more selected orders may be displayed. The left and right sides of the user interface 806 are separated by a line 808. The user interface 806 may be the interface of the kitchen display system where the service provider pushes notifications or updates in real time from orders received from multiple sources. Interface 806 also lists orders and assists in managing orders due to user preferences, availability, and other such factors, as scheduled by service provider 102.

As shown, status information regarding the delivery of an item can be obtained by communicating with the service provider via one or more service provider API802. For example, as shown in 810, the order status information listed on the left side of the user interface 806 can be obtained by requesting the information from the service provider. At 812, the service provider can determine the status of an order by acquiring performance information and determining the location of a third party service assigned to each of the merchant (company A) orders. At 814, the service provider can generate details about the status and send the details to the computing device 804 for display via the left side of the user interface 806.

If the merchant selects a particular order on the left side of the user interface 806, such as order 816, more detailed information specific to that order may be displayed on the right side of the user interface 806. In particular, as shown in 818, the computing device 804 may request additional status information for the selected order 816. At 820, the service provider can determine the status of the selected order by acquiring 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 the computing device 804 for display via the right side of user interface 1206. In some cases, the details displayed on the right side may be more specific than the details displayed on the left side. In this way, merchants see a lot of status information for orders placed through different types of channels.

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

In some examples, the present application discloses a system for providing optimized order scheduling, which stores one or more processors and instructions that can be executed by one or more processors. The instructions include the first order from the first customer face-to-face ordering application by the order scheduling application running on the point-of-sale management device associated with the merchant, including one or more non-temporary computer-readable media. To receive, the first order comprises one or more menu items prepared by the merchant for delivery to the address provided by the first customer face-to-face ordering application. 1. Determining an estimated pick-up time that indicates the estimated time when a courier or customer may pick up a first order, based on past orders related to the first customer-facing application, and a second customer. Receiving a second order from a face-to-face order application, the second order containing one or more menus prepared by the merchant, receiving and computing the merchant by the first delivery application. Sending to the device an estimated pickup time indicating the time it takes for the second delivery application to estimate the arrival of the courier or other customer to pick up the second order, and the past involvement of the second delivery application. Based on the order, the delivery person or customer determines the estimated pickup time, which indicates the time when the second order may be picked up, and the order scheduling application allows for the estimated pickup of the first and second orders. Performs actions that include generating an ordered list of orders based on at least part of the time, and sending the ordered list of orders to the kitchen display system to prepare the order according to the ordered list. To program one or more processors.

FIG. 9 illustrates exemplary processing of an example of a service provider such as a service computing device 102 or a related application such as a consensus service, dynamically moving an icon 902 of a user interface 904 such as a user interface 902 based on contextual data. Modify (change) to. For example, menu updates can be sent to a third party service based on the relationship between the third party service and the merchant, the availability or popularity of the item, and other contextual data. Contextual data includes the location, time, day, year time (eg, season), weather, merchant inventory, merchant preferences, customer preferences, items considered upsell items, and cross-sell items for the service computing device 900. It can include items considered, sales and / or bargains offered by merchants, and various other contextual factors that correspond to the use of the Service Computing Device 900. Contextual data can be automatically generated on a merchant device via an application or through data analysis such as current or history at the server level. Contextual information can be obtained by tracking complete or incomplete order requests, which are cart-level information, from a third-party application.

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

In various examples, the analysis can include a decision to emphasize one or more items. Emphasis may be presented by changing the placement of the icon 902 by increasing the size, shape, color and / or hue of the icon 902, or by making other adjustments to make the icon 902 stand out on the display. can. Emphasis is on the merchant's inventory, current weather, attempts to upsell the item, attempts to cross-sell the item, sales and / or bargains offered by the merchant, and the merchant's transaction history (eg, sold at a given time). It can be based on known popular items that have been sold, day of day, time of year (eg, season), known popular combinations of items sold, and so on.

[3] In some examples, the analysis may include a decision to deemphasize one or more items. Item deemphasizing can be based on the merchant's inventory, current weather, cross-selling attempts, and / or other factors that can discourage the merchant from selling a particular item. De-emphasis can be presented by removing the icon 902 corresponding to one or more items from the display page. In various examples, the user interface 904 can include a plurality of display pages. In some examples, de-emphasis can be presented by including an icon corresponding to one or more items on a display page other than the main display page. For example, dehighlighting 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 unemphasize one or more items based on context factors. For example, if the customer orders 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 replace it with a pastery icon.

At 908, the service computing device 900 determines the second context data and displays the second icon 902 (2) based on the context data. In various examples, the second context data can include a change in time from the time corresponding to the morning menu to the time corresponding to the lunch menu. In some examples, the second contextual data can include the determination of an event close to the merchant's location, or is displayed on the screen of the merchant's location, which is the menu most likely to be ordered by the customer. May affect items. In such an example, the service computing device 900 dynamically modifies the icon 902 (1) to the second setting of the icon 902 (2) to a customer preference or external environment (eg, cold / hot days). Hot / cold beverage items are recommended). For example, a merchant can usually adjust from breakfast to lunch menu at 11:00 am. However, the service computing device 900 can determine that the football game starts at 10 am and that the customer prefers to consume the items on the lunch menu during the football game. Therefore, the service computing device 900 may adjust one or more of the 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 a merchant or will be presented on the display screen at the merchant's location, one or more based on the event. And / or bargains (eg, discounts, etc.) can be generated. In such an example, the service computing device 900 can highlight the icon 902 corresponding to one or more bargains. For example, merchants may specially serve hamburgers and alcoholic beverages during the event. Therefore, the service computing device 900 can be modified to make the icons corresponding to hamburgers and alcoholic beverages stand out. Further, or as an alternative, the service computing device may display a notification 910 that a particular item will be offered at a discounted price to further encourage the purchase.

Alternatively or additionally, the first interface with the icon 902 (1) can accommodate the first third party service, and the second interface with the 902 (2) is the second second. A tripartite service can be accommodated and the merchant sends 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, which means that the same content is presented to the third party service. The underlying contextual information of the menu may be tied to the customer's behavior in the menu related to the third party service (ie, the menu of service A for the merchant is the menu of service B for the same merchant. It may be organized differently from the menu). The payment service API can be used to collect customer interactions / behaviors (menu scrolling activity, navigation settings, order history, etc.) within its third party service application. Looking at the order history, payment services tend to be, for example, a payment service or API where a customer of service A typically orders an appetizer and a customer of service B orders dessert from a particular merchant. If it is determined that the information is used, the menu can be reorganized. Thus, in one embodiment, the payment service is based on, for example, the ordering activity that the consensus service tracks during a particular time period (eg, "whether customers from the majority of third party applications are currently ordering steaks". (Based on the query), content / menu updates can be pushed up to all third-party ordering applications. In addition, or as an alternative, the payment service reorganizes the menu layout so that the consensus service produces a unique menu that is customized for each third-party application based on what the consensus service learns about the customer's ordering behavior. Can also be pushed out. Therefore, the consensus service collects, analyzes, compares, and learns from current and historical data that the delivery service cannot access. In addition, the consensus service allows separate services that would otherwise not communicate to communicate over the indirect channels created by the consensus service. The description describes the API as one formation of channels, but the description extends to cover other formations of channels between services, either directly or through intermediary services such as payment services. Please understand that you can.

In some implementations, a server system for providing optimized content management, wherein the system stores one or more processors and instructions that can be executed by the one or more processors. With the above non-temporary computer readable medium, the instruction is to receive a content structure for a first service application and a second service application, wherein the content structure is, for example, a menu. Content updates are new menu items, deleted menus by content management applications that are laid out or items are priced, received and run on the point-of-sale management device associated with the merchant. Receiving a first content update or review for a first merchant application containing an item, the first content update including an update made to content such as a menu for the first service application. , Receiving, sending content updates to the first service application, sending content updates similar to the content updates of the first service application to the second service application, etc. Perform the steps.

Alternatively, the service provider involves generating a structured structure of content based on the service application and the merchant by means of a content management application. For example, a first menu with a particular order and pricing of an item for a first service application, and a second menu with another order and pricing of an item for a second service application. .. In addition, different items may be offered in different locations and service applications.

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

In some implementations, service provider 102 allocates a reservation received for merchant device 1002, which reservation is made via API (not shown), first reservation application 1004-1 and second reservation. It is configured to receive reservations from multiple reservation applications, including application 1004-2. APIs 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 published APIs to reach merchants. Send reservation information. For example, a consensus service can collect data and order reservations accordingly. The consensus service can also take advantage of historical reservation information that allocates a portion of a seat, eg, via a machine learning model, based on what the service learns about each booking application and what the service has learned. For example, payment services can allocate seats based on factors such as the frequency of cancellations, the average arrival time of customers using the application, the order size, and so on. Service provider 102 receives a plurality of reservations, executes consensus service 132, processes incoming reservations, and / or for merchants based on the customer profile and / or merchant profile stored in database 1006. Schedule. Database 1006 stores customer and merchant preferences and shows how bookings can be configured to best match those preferences. For example, consensus service 132 can move reservations 1004-3 from 6:30 to 7 PM, depending on availability or past reservations made by the customer. Similarly, reservations 1004-4 can be assigned to 8 PM, depending on the availability of a particular seat or item. For example, some restaurants maintain a rotating menu, as such, the service provider may be provided with access to the user's dining preferences with the consent of the user. Therefore, the booking can be moved to a more preferred spot without the intervention of the user or merchant. This application receives first data associated with an average number of reservations made using the first reservation application over a period of time by a payment service such as a service provider and from the first reservation application. Receives second data associated with the average number of reservations made using the second booking application over a period of time; by the payment service; by the payment service. Receiving data about available seats in a restaurant; assigning a first portion of a seat from the available seats to a first booking application based on at least the first data, the first. One or more users of the booking application may reserve seats below the first portion of the seat, said allocation; the second portion of the available seats, based on at least the second data. By assigning to two reservation applications, one or more users of the second reservation application may reserve seats below the other portion of the seat, said allocation; at least one user during the reservation. Determining if any seat is available on the second reservation application in response to the inability to reserve a seat using the first reservation application; Provides instructions for migrating a customer device from the interface to a second booking application; using the second booking application to receive input from one or more users indicating a seat reservation in a restaurant; It is disclosed.

In some embodiments, a server system that provides optimized restaurant reservation scheduling is one or more processors and one or more non-temporary computers that store instructions that can be executed by one or more processors. The instruction is to receive the first reservation from the first customer face-to-face reservation application by the reservation scheduling application running the point-of-sale management device associated with the merchant, comprising a readable medium, the first reservation. Receiving, including one or more menu items prepared by the merchant for delivery to the address provided by the first customer face-to-face booking application, and computing by the merchant by the first delivery application. Sending to the device an estimated pickup time indicating the estimated time for the delivery person or customer to arrive for the first delivery application to pick up the first reservation, and past reservations relating to the first customer-to-face application. From another customer, from a second customer-to-face booking application, by determining the predicted pick-up time that indicates when the delivery person or customer may pick up the first booking, and by the booking scheduling application. The second reservation is to receive the second reservation, which comprises one or more menus prepared by the merchant, and by the first delivery application, to the merchant's computing device. Based on the fact that the second delivery application sends an estimated pickup time indicating the estimated time for the delivery person or other customer to arrive to pick up the second reservation, and the past reservations associated with the second delivery application. Determines the estimated pickup time, which indicates the time at which the delivery person or customer may pick up the second reservation, and the reservation scheduling application allows at least a portion of the estimated pickup time for the first and second reservations. One or more to perform actions including generating an order list of reservations and sending the order list of reservations to the kitchen display system in preparation for the reservation according to the order list. Program your processor.

Although embodiments have been described in languages specific to structural features and / or methodological behaviors, it should be understood that the present disclosure is not necessarily limited to the particular features or behaviors described. Rather, specific features and behaviors are disclosed herein as exemplary embodiments that implement embodiments.
section

A. A system for providing optimized order scheduling, comprising one or more processors and one or more non-transitory computer-readable media that store instructions that can be executed by the one or more processors. The instruction is to receive a first order from a first customer face-to-face ordering application by an order scheduling application running on a point of sale (POS) device associated with a merchant, said first. The order comprises one or more menu items prepared by the merchant for delivery to the address provided by the first customer face-to-face order application, said receiving and by the service computing device. Based on past orders, including a first customer-to-face application, determining an estimated pick-up time that indicates the estimated time that the delivery person or said customer is likely to pick up the first order and said order scheduling application. By receiving a second order from a second customer face-to-face order application from another customer, wherein the second order comprises one or more menu items prepared by the merchant. And predictive time by which the service computing device is likely to pick up the second order by the delivery person or the customer based on past orders including the second customer face-to-face ordering application. Determining the pick-up time and generating an ordered list of orders by the service computing device, at least partially based on the predicted pick-up times of the first order and the second order. To perform an operation comprising sending the ordered list of the order to prepare the order according to the ordered list to the kitchen display system associated with the order scheduling application. A system that programs one or more processors.

B. An interface is provided to at least one of the customer or the merchant via a display associated with the computing device, and the delivery location, pickup location, pick-up request time, are acquired through the interface. Receives the ordered list of orders based on the number of items, the size of the item, whether the item is associated with a given category, or one of the weights of the item, and of the item. Determines that delivery information is requested, sends a delivery request for the item to the service computing device via the one or more APIs, and receives a delivery proposal from the service computing device. , A third-party service for determining that a delivery proposal has been accepted and sending an indicator of acceptance of the delivery proposal via the one or more APIs to facilitate delivery of the item. A system according to section A, further comprising an application runn by one or more processors of the computing device associated with at least one of the merchants.

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

D. Further including a consensus application hosted on the service computing device, the consensus application is the first order and the second from the first customer face-to-face order application and the second customer face-to-face order application, respectively. The system according to any of sections A to C, wherein the consensus application receives an order and schedules the first order and the second order for display on the kitchen display system.

E. The service computing device receives additional location information of the delivery person associated with the third party service and generates the first order or the second order based on the location information of the delivery person. Further configured to identify one of the third party services different from the third party service used in and assign delivery of the item to the identified third party service, section B. The system described in.

F. A system including a service computing device processor and a service computing device communication interface communicably connected to the service computing device processor, wherein the service computing device communication interface is a service of a plurality of third parties. A computing device that communicates with a device over one or more networks and is associated with at least one of a customer or merchant and through the one or more networks through one or more application programming interfaces (APIs). Further communicating, the service computing device receives a request for delivery of an item designated by the customer to be obtained from the merchant via the one or more APIs provided by the service computing device. That is, the request may be a delivery location, a pickup location, a requested time for pickup, the number of items acquired, the size of the item, whether the item is associated with a given category, or Representing at least one of the weights of the item, the request is made via the one or more APIs from an application that can be run on the computing device associated with at least one of the customer or the merchant. Receiving, said receiving, and for the merchant, generating a delivery proposal that prepares the item and delivers it to the location of delivery, wherein the delivery proposal is (a) the third party service. A preferred delivery service from among the plurality of third party delivery services associated with the device, wherein the plurality of third party delivery services are via the one or more APIs of the service computing device. The preferred delivery service to communicate with the merchant, (b) the sequence of requests including the request used by the merchant for preparation, and (c) the estimated time for delivery of the item by the delivery service. The suitable delivery service is from the merchant's facility to the third party service associated with the suitable delivery service using the generation and the one or more APIs, including the item. A system configured to obtain and send a communication requesting that the item be transported to the location of delivery.

G. The sequence of requests includes a sequence in which the merchant processes the request, the sequence includes time, the position of the merchant, the position of the customer, the position of the deliverer capable of making the delivery, the order received. The system according to Section F, which is based on at least one of the time given, the merchant profile, the customer profile, the requested preparation time for the item, and the availability of the item.

H. The service computing device to provide the computing device with access to one or more merchants associated with the service computing device to the one or more processors when executed by one or more processors. Compute devices that expose one or more application programming interfaces (APIs) and access to one or more third-party services that can facilitate one or more actions associated with said merchant. To expose the one or more application programming interface interfaces (APIs) by the service computing device and to provide to the merchant and the third party services via the one or more APIs. Receiving a request from a computing device to process the action associated with the merchant and generating an action proposal to facilitate the action associated with the merchant. The action proposal comprises the sequence in which the steps in the action are performed, the generation of the action proposal, the transmission of the action proposal to the computing device associated with the third party service or the merchant, and the said. The service provider constitutes a payment flow based on the action proposal via the one or more APIs, wherein the payment flow is the distribution of sub-actions between the third party service and the merchant. One or more non-transitory computer-readable media that stores executable instructions for performing operations, including the above-mentioned configuration, which is based on.

I. One or more actions include delivery of an item, preparation of the item, cancellation of the item, delivery of an order, preparation of the order, cancellation of the order, merging of orders, splitting of the order, reservation for a customer, One or more non-temporary computer-readable media as described in Section H, including appointments for customers, content updates across third party services, item updates, order updates.

J. The action proposal is a delivery proposal indicating at least one of an estimated time amount for delivery of the item, an estimated pickup time for delivery of the item, or an estimated drop-off time for delivery of the item. One or more non-temporary computer-readable media described in either Section H or I.

K. Publishing the one or more APIs exposes the one or more APIs to a computing device associated with the merchant, and the merchant delivers the items offered for acquisition by the merchant. One or more non-temporary computer-readable media described in Section H, including making it possible to facilitate.

L. The operation is to receive a request for the delivery status of the item from the computing device, to receive the location information of the third party service device, and to receive the location information of the third party service device, via the one or more APIs. One or more non-temporary items described in Section K, further comprising determining the delivery status of the item by a third party service and transmitting the status of the item delivery to the computing device. Computer-readable medium.

M. The operation is to receive another request for delivering another item to the merchant in order to register the merchant in a service that facilitates the acquisition of the item via the one or more APIs. The other item is configured with a merchant application that facilitates the acquisition of the item with the customer, the other request indicating the location of delivery of the other item, the receiving and the other. Identifying the other third party service to transport the other item based at least in part to the location of the third party service, and the other third party service of the delivery of the other item. Section K or L, further comprising sending a communication requesting delivery of the other item to said location to another third party service device associated with said other third party service. One or more non-temporary computer-readable media described in.

N. The action acquires training data on current and past actions performed by the merchant and the third party service, and trains a machine learning model based on the training data to generate the action proposal. One or more non-temporary computer-readable media according to any of Section HM, further comprising:

O. A display configured to display an interface, one or more processors communicably connected to said display, and communicably connected to said one or more processors and executed by said one or more processors. First, to the one or more processors, on the display, prepared by the merchant and picked up for delivery to the first customer by the first delivery person of the first delivery service. Orders for receiving and picking up on the display for delivery to a second customer by the merchant and by the second delivery person of the second delivery service. Is to receive on the display a delivery proposal comprising the sequence in which the merchant should prepare the first order and the second order, wherein the sequence is one or more. Receiving and being generated by a service computing device interfaced with said system having said display, said first delivery service, and said second delivery service through an application program interface (API). Based on the modification by modifying the sequence through the display and initiating an API call to the service provider based on the availability of the item in the first order or the second order. A system with a memory that stores executable instructions that generate a payment flow and perform actions including.

P. The operation is to send a trigger for providing the delivery status of the item to the first delivery service or the second delivery service to the service computing device via the one or more APIs. And receiving the delivery status of the item from the service computing device and transmitting the delivery status to the first delivery service or the second delivery service. The system described in Section O.

Q. The system comprises a merchant device, the operation of which is to receive an order for acquisition of another item from the service computing device, wherein the other item is a customer of the first delivery service. Receiving said reception, receiving user input indicating acceptance of the order, and sending an index of acceptance of the order to the service computing device, said to be selected for acquisition through the device. Receiving a first status of delivery of an item and a second status of delivery of the other item and displaying said first status of delivery and said second status of delivery via said interface. And the system according to section O or P, further comprising.

R. The delivery proposal is the cost for delivery of the item by a delivery service interfaced with the service computing device, the estimated amount of time for delivery of the item, the estimated pickup time for delivery of the item, or said. The system according to any of Sections OQ, which indicates at least one of the estimated drop-off times for delivery of an item.

S. The delivery proposal indicates at least one of the costs for delivery of the item by the delivery service associated with the service computing device, and the action removes the item from the group of items in one order. That is, the removal is based on availability, popularity, corruption, and time, the removal, displaying the cost of delivery of the item via the interface, and the item. The system according to any of Section OR, comprising charging the customer associated with the acquisition of the cost of delivery of the order after removing the item.

T. The system according to any of Section OS, wherein the operation further comprises providing consensus when the first order and the second order are made substantially simultaneously.

U. A system for providing optimized reservation scheduling, comprising one or more processors and one or more non-transitory computer-readable media that store instructions that can be executed by the one or more processors. The instruction is to receive a first reservation request from a first customer-to-customer face-to-face reservation application from a customer by a reservation scheduling application running on a point-of-sale management device associated with the merchant. The first reservation request comprises the preferred time of the reservation at the merchant location, the customer is provided by the service computing device based on the receipt and the past order relating to the first customer face-to-face reservation application. Determining which seat is expected to prefer the first reservation request and receiving a second reservation request from the second customer-to-face reservation application from another customer by the reservation scheduling application. The second reservation request is based on the receipt and past orders relating to the second customer-to-face booking application, including other suitable times for the reservation at the merchant location. The service computing device determines which seat the other customer is likely to prefer the second reservation request, and the service computing device determines the first reservation request and the first reservation request. Generating a seating chart based at least in part on the predicted seats corresponding to the booking request of 2 and the seating chart for the merchant position on the kitchen display system associated with the booking scheduling application. A system that programs the one or more processors to perform an operation comprising transmitting the seating chart to be configured in accordance with.

V. An application run by one or more processors of a computing device associated with a third party service or at least one of the merchants, said customer through a display associated with the computing device. Or to provide an interface to at least one of the merchants and through the interface to an alternative merchant providing the reservation, seating options in the merchant for which the reservation was requested, timing of the reservation, and past seat preferences. Receiving an update to the seating plan and determining that information about the seating plan has been requested, based on at least one of the alternative seating options different from the requested seating option. Sending a response to the request for an update to the seating plan, receiving a booking proposal from the service computing device, and accepting the booking proposal via one or more APIs and by the service computing device. Described in Section U, further comprising an application for determining that and facilitating the reservation by transmitting an index of acceptance of the reservation proposal via the one or more APIs. system.

W. The reservation scheduling application comprises an application program interface (API) 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 according to section U or V, further configured to provide.

X. Further including a consensus application hosted on the service computing device, the consensus application is the first reservation request and the second from the first customer face-to-face reservation application and the second customer face-to-face reservation application, respectively. The system according to any of Section UW, which receives the reservation request and processes the first reservation request and the second reservation request based on the customer's preference.

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

Z. A system including a service computing device processor and a service computing device communication interface communicably connected to the service computing device processor, wherein the service computing device communication interface is a service of a plurality of third parties. A computing device that communicates with a device over one or more networks and is associated with at least one of a customer or merchant and through the one or more networks through one or more application programming interfaces (APIs). Further communicating, the service computing device is to receive a request for booking with the merchant via the one or more APIs provided by the service computing device, wherein the request is a merchant. It is to generate a reservation proposal for setting the reservation according to the customer's preference for the receipt and presentation on the device associated with the merchant, indicating a suitable time for the reservation at the location. The reservation proposal is (a) a seat in a merchant position from among a plurality of seat options, (b) another time slot corresponding to the request, and (c) an alternative seat if the merchant position is reserved. The identified third-party service to the third-party service device associated with the identified third-party service using said generation and said one or more APIs, including options. Is configured to send and perform communications requesting that a seat be reserved at said merchant location.

AA. The processor is further configured to allocate reservations for a merchant associated with said 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 the first data-related reservation made using the first reservation application from the first reservation application by the payment service, and the second reservation service by the payment service. Receives a second data-related reservation made using the second booking application during the time period from the booking application of, and receives data about available seats in the restaurant by the payment service. That is, to allocate a seat in the first portion of the seat from the available seat to the first reservation application, based on at least the first data, the user of the first reservation application said. Allocate seats in the second portion of the available seats to the second reservation application, based on the allocation and at least the second data, which can reserve seats below the first portion of the seat. That is, the user of the second reservation application can reserve a seat below the seat of the other portion, the allocation and the reservation, and at least one user using the first reservation application. Determining whether any seat is available on the second reservation application in response to the inability to reserve a seat, and the second from the interface of the first reservation application. To provide an instruction for transitioning a customer device to the reservation application of, and to receive an input indicating reservation of the seat in the restaurant from the one or more users using the second reservation application. The system according to section Z, which performs one or more actions, including.

AB. One or more non-temporary computer-readable media that stores instructions that cause the one or more processors to perform an operation when performed by one or more processors, wherein the operation is a service computing device. Publishing one or more Application Programming Interfaces (APIs) by a service computing device to provide access to one or more merchants associated with said merchants. To provide a computing device with access to one or more third-party services that can facilitate one or more actions, the service computing device allows the one or more application programming interface interface. Publishing APIs) and receiving requests from said merchants and said computing devices of said third party services to process actions associated with said merchants via said one or more APIs. And to generate an action proposal that facilitates the action associated with the merchant, wherein the action proposal comprises a sequence in which the steps within the action are performed. To send the action proposal to the person service or the computing device associated with the merchant, and to configure the payment flow based on the action proposal by the service provider via the one or more APIs. The payment flow is based on the distribution of sub-actions between the third party service and the merchant, including the configuration and one or more non-transitory computer readable. Medium.

AC. The one or more actions are delivery of the item, preparation of the item, cancellation of the item, delivery of the order, preparation of the order, cancellation of the order, merging of orders, splitting of the order, reservation of the customer, customer. One or more non-temporary computer-readable media described in Section AB, including appointments, content updates across third party services, item updates, order updates.

AD. The action proposal is of an alternative seat option different from the requested seat option based on the alternative merchant providing the reservation, the seat option in the merchant for which the reservation was requested, the timing of the reservation, and the past seat preference. One or more non-temporary computer-readable media according to any of the sections AA-AC, which is a reservation proposal indicating at least one.

AE. Publishing the one or more APIs exposes the one or more APIs to a computing device associated with the merchant, with the merchant in one of physical or online locations with the merchant. One or more non-temporary computer-readable media described in Section AB, including making it possible to facilitate reservations or appointments.

AF. The operation was performed via the one or more APIs, receiving a request for modification of the reservation request from the computing device, being associated with the merchant, and through a plurality of third party services. As described in Section AE, further including accessing the seating plan, including reservations, determining whether the modification causes a race condition, and determining a new seat based on the determination. One or more non-temporary computer-readable media.

AG. The action is to receive another request to reserve another seat via the one or more APIs, the other seat matching the seat assigned to the previous reservation. , Receiving and identifying alternative seating options for the first or second request based on the updated customer preference, and the seating plan to be updated according to the identifying steps. One or more non-temporary computer-readable media according to section AE or AF, further comprising transmitting a communication indicating the above to the merchant.

AH. The action acquires training data on current and past actions performed by the merchant and the third party service, and trains a machine learning model to generate action suggestions based on the training data. One or more non-temporary computer-readable media described in any of Section AB-AG, further comprising the above.

AI. A display configured to display an interface, one or more processors communicably connected to the display, and communicably connected to and executed by the one or more processors. A system comprising a memory for storing an executable instruction that causes the one or more processors to perform an operation when the operation is performed, wherein the operation is performed on a display using a first reserved application. Receiving a first reservation at a merchant position, receiving a second reservation at a second merchant position using a second reservation application on the display, and receiving a second reservation at the merchant position. Receiving a reservation proposal that includes a seating plan for reserving a seat corresponding to the first reservation and the second reservation, wherein the seating plan comprises one or more application program interfaces (APIs). To real-time input from the merchant indicating changes in the seating plan generated by the system having the display, the first reservation service, and a service computing device interfaced with the second reservation service. Based on, a system comprising modifying the seating plan through the display and triggering a seat reassignment based on the modification by initiating an API call to the service provider.

AJ. The operation is to send a trigger for providing a reservation status to the first reservation service or the second reservation service to the service computing device via the one or more APIs. The system according to section AI, further comprising transmitting the booking status to the computing device associated with the customer.

AK. The system includes a merchant device, the operation of which is to receive another request to reserve another seat via the one or more APIs, wherein the other seat is a previous reservation. Identifying alternative seating options for the first or second request, based on the receipt and updated customer preferences that match the seats assigned to the identification. The system according to section AI or AJ, further comprising sending a communication indicating the seating plan to be updated to the merchant in accordance with the steps to be performed.

AL. The reservation proposal is of an alternative seat option different from the requested seat option based on the alternative merchant providing the reservation, the seat option in the merchant for which the reservation was requested, the timing of the reservation, and the past seat preference. The system according to any of the sections AI-AK, indicating at least one.

AM. The reservation proposal presents at least one of the options for reserving a public seat by routing the request from the first reservation application to the second reservation application, wherein the routing is the first. The system according to any of Section AI-AL, comprising transitioning from a first user interface associated with a reservation application to a second user interface associated with the second reservation application.

AN. The system according to any of Section AI-AM, wherein the operation further comprises providing consensus when the first reservation and the second reservation are made substantially simultaneously.

AO. A system for providing optimized content management associated with a menu, wherein the system stores one or more processors and one or more instructions that can be executed by the one or more processors. Equipped with a non-temporary computer-readable medium, the instruction is executed by the content management application associated with the service computing device and on the point-of-sale information management device associated with the merchant. Receiving content updates for one or more menu items provided by, said content updates are configured to be delivered to a customer-facing application, said receiving and said one or more content updates. The content management application determines whether or not it applies to the additional customer-facing application of the one or more additional customer-facing applications via one or more application program interfaces (APIs). Based on the determination that is interfaced with the content management application and that the service computing device determines that the content update applies to one or more additional customer-facing applications. To update the interface of the one or more additional customer-facing applications in accordance with the content update via the one or more APIs, and to indicate that the customer-facing application has received the content update. A system in which one or more processors are programmed to perform an operation, including sending to a kitchen display system associated with the merchant.

AP. Further including an application runn by one or more processors of a computing device associated with at least one of a third party service or merchant, said customer or said through a display associated with said computing device. Provide an interface to at least one of the merchants; through said interface, receive a notification indicating that the customer-facing application has received the content update and synchronize across other customer-facing applications. Receiving the following notification; determining that the content update is sent only to the targeted customer-facing application; the other via the one or more APIs and by the service computing device. Undoing said content updates from untargeted customer-facing applications, including customer-facing applications; the system described in Section AO.

AQ. The content management application is 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 according to section AO or AP, further configured to provide.

AR. Further including a consensus application hosted on the service computing device, the consensus application is a merchant associated with one or more point-of-sale (POS) devices running one or more instances of the content management application. The system according to any one of Sections AO-AQ, which receives a plurality of content updates from the Consensus Application and selects one of the plurality of content updates based on the customer's preference.

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

AT. A system including a service computing device processor and a service computing device communication interface communicably connected to the service computing device processor, wherein the service computing device communication interface is a service of a plurality of third parties. A computing device that communicates with a device over one or more networks and is associated with at least one of a customer or merchant and through the one or more networks through one or more application programming interfaces (APIs). Further communicating, the service computing device is to receive a content update request via one or more APIs provided by the service computing device, the content update being delivered to a customer-to-face application. And related to one or more menu items provided by the merchant, the request can be performed on the computing device associated with the customer or at least one of the merchants. The service computing device provides the reception and whether the content update applies to other customer-facing applications, generated from the application via the one or more APIs. The determination and the determination, wherein the determination is made via one or more APIs, wherein the other customer-facing application is interfaced with the application via one or more application program interfaces (APIs). Responding to the service computing device determining that the content update applies to another customer-facing application, the content update is made to the location of the delivery associated with the customer-facing application for the merchant. To generate a proposal for delivery, the proposal is (a) one or more customer-facing applications from among a plurality of customer-facing applications associated with the third-party service device. The plurality of customer-facing applications communicate with the merchant via the one or more APIs of the service computing device, the one or more customer-facing applications, (b) the urgency of applying the content update. 1. A system configured to use the API to send a notification to the kitchen display system associated with the merchant 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 update. Upon receiving the notification indicating that the content update has been performed, it is determined that the content update should be transmitted only to the targeted customer-facing application, and the service computing device is used via the one or more APIs. The system according to section AT, further configured to undo the content update from a non-targeted customer face-to-face application, including said other customer face-to-face applications.

AV. One or more non-temporary computer-readable media that stores instructions that cause the one or more processors to perform an operation when performed by one or more processors, wherein the operation is a service computing device. By exposing one or more Application Programming Interfaces (APIs) to provide access to the one or more merchants associated with the service computing device to the computing device. One or more Application Programming Interfaces (APIs) to provide a computing device with access to one or more third-party services that can facilitate one or more actions associated with said merchant. And to receive requests from the merchant and the computing device of the third party service to process the action associated with the merchant via the one or more APIs. The generation of an action proposal that facilitates the action associated with the merchant, wherein the action proposal comprises a sequence in which the steps within the action should be performed. To send the action proposal to the person service or the computing device associated with the merchant, and to configure the payment flow based on the action proposal by the service provider via the one or more APIs. The payment flow is based on the distribution of sub-actions between the third party service and the merchant, including the configuration and one or more non-transitory computer readable. Medium.

AW. The one or more actions are delivery of the item, preparation of the item, cancellation of the item, delivery of the order, preparation of the order, cancellation of the order, merging of orders, splitting of the order, reservation of the customer, customer. One or more non-temporary computer-readable media described in Section AV, including appointments, content updates across third-party services, item updates, order updates.

AX. The action proposal is one or more non-temporary described in either section AV or AW, which is a content update proposal indicating the content to be updated and the identifier of the third party service to which the content update is transmitted. Computer-readable medium.

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

AZ. The operation is to receive a request for the delivery status of the item from the computing device, to receive the location information of the third party service device, and to receive the location information of the third party service device via the one or more APIs. One or more non-temporary computers described in Section AY, further comprising determining the status of the content update by a third party service and transmitting the status of the content update to the computing device. Readable medium.

BA. The operation further comprises executing a consensus application hosted on the service computing device, wherein the consensus application is one or more point-of-sale management (POS) running one or more instances of a content management application. ) Receiving a plurality of content updates from the merchant associated with the device and the consensus application selecting one of the plurality of content updates based on the customer's preference, as described in Section AY or AZ. One or more non-temporary computer-readable media.

BB. The action acquires training data on current and past actions performed by the merchant and the third party service, and trains a machine learning model to generate the action proposal based on the training data. One or more non-temporary computer-readable media described in any of the sections AV-BA, further comprising:

BC. A display configured to display an interface, one or more processors communicably connected to the display, and communicably connected to and executed by the one or more processors. A system comprising a memory for storing an executable instruction that causes the one or more processors to execute an operation when the operation is performed, wherein the operation is a first of a customer-facing application by a server application. Receiving a first content request for delivery to a device and receiving a second content request for delivery of a second customer-facing application to a second device by the server application. The server application is to generate a proposal for satisfying the first content request and the second content request for one or more delivery locations, wherein the proposal is (a) said. One or more customer-face-to-face applications from among a plurality of customer-face-to-face applications associated with a third-party service device, wherein the plurality of customer-face-to-face applications is via the one or more APIs of the service computing device. Includes the one or more customer-facing applications that communicate with the merchant, (b) the nature of the content update indicating the urgency to apply the content update, and (c) the estimated amount of time for delivery of the content update. By initiating the generation, initiating the trigger of the content update to the customer-facing application via the server application, and initiating an API call to the service provider, a payment flow based on the initiation. The system that causes and includes.

BD. The operation is to send a trigger for providing the content update to the first or second customer-facing application to the service computing device via the one or more APIs, and the service computing. The system according to section BC, further comprising receiving the status of the content update from the ing device and causing the status of the delivery of the content update to be transmitted to the first or second delivery service.

BE. The system includes a merchant device, the operation of which is to receive an order for acquisition of another item from the service computing device, wherein the other item is a customer of the first delivery service. Receiving said reception, receiving user input indicating acceptance of the order, and sending an index of acceptance of the order to the service computing device, which is selected to be acquired via the device. Receiving the first status of delivery of the item and the second status of delivery of the other item, and displaying the first status of delivery and the second status of delivery via the interface. The system according to section BC or BD, further comprising:

BF. The system according to any of Section BC-BE, wherein the proposal shows a method of addressing the first content request across different merchant applications.

BG. The proposal indicates whether the first content request applies to other customer-facing applications other than the identified one, the behavior of which is to update existing content and generate new content. The system according to any of Section BC-BF, further comprising: and removing existing content.

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

The exemplary clauses above are described for one particular implementation, but in the context of this specification, the content of the exemplary clauses is a method, device, system, computer readable medium, and / or another implementation. It should be understood that it can also be implemented via.

Claims (4)

A system for providing optimized order scheduling,
With one or more processors
It comprises one or more non-temporary computer-readable media that stores instructions that can be executed by the one or more processors.
The first order from the first customer face-to-face order application is received by an order scheduling application running on a point-of-sale (POS) device associated with the merchant, the first order being said first. Receiving and including one or more menu items prepared by the merchant for delivery to the address provided by the customer face-to-face ordering application.
A service computing device provides an estimated pick-up time that indicates the estimated time a delivery person or customer is likely to pick up the first order based on past orders, including the first customer face-to-face ordering application. Judgment and
The order scheduling application is to receive a second order from a second customer face-to-face order application from another customer, wherein the second order is one or more menu items prepared by the merchant. Including, said to receive and
The service computing device determines an estimated pickup time that indicates the time at which the delivery person or the customer is likely to pick up the second order, based on past orders including the second customer face-to-face order application. To do and
The service computing device generates an ordered list of orders, at least partially based on the predicted pick-up times of the first order and the second order.
Sending the ordered list of orders to the kitchen display system associated with the order scheduling application to prepare the order according to the ordered list.
A system that programs one or more of the processors to perform an operation comprising:
An interface is provided to at least one of the customer or the merchant via a display associated with the computing device.
Through the interface, the delivery location, the location of the pickup, the requested time of pickup, the number of items acquired, the size of the item, whether the item is associated with a given category, or the weight of the item. Received the ordered list of orders based on one of them,
Determining that information regarding the 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.
Receive a delivery offer from the service computing device
Determine that the delivery proposal has been accepted and
To facilitate delivery of the item, send an indicator of acceptance of the delivery proposal via the one or more APIs.
A system, further comprising an application that can be run by one or more processors of the computing device associated with a third party service or at least one of the merchants . The order scheduling application comprises an application program interface (API) 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 claim 1, further configured to provide. Further including a consensus application hosted on the service computing device, the consensus application is the first order and the second from the first customer face-to-face order application and the second customer face-to-face order application, respectively. The system of claim 1, wherein the consensus application receives an order and schedules the first order and the second order for display on the kitchen display system. The service computing device is
Upon receiving further location information of the delivery person associated with the third party service,
Identify one of the third party services different from the third party service used to generate the first order or the second order based on the delivery person's location information.
Assign delivery of the item to the identified third party service,
The system according to claim 1 , further configured as described above.

Images