WO2016193830A1

WO2016193830A1 - Repeat order notifications

Info

Publication number: WO2016193830A1
Application number: PCT/IB2016/052333
Authority: WO
Inventors: Vivien TSAO
Original assignee: Accenture Global Services Limited
Priority date: 2015-06-01
Filing date: 2016-04-25
Publication date: 2016-12-08
Also published as: CA2976615A1; CA2976615C

Abstract

Methods, systems, and apparatus for receiving a particular set of user data; obtaining a predictive model that estimates a likelihood of a user to order a food item, wherein the predictive model is generated using observation data that includes historic user data and user data from other user devices; providing the particular set of user data to the predictive model; obtaining an indication of a likelihood of the user to order a food item; based on the indication of a likelihood of the user to order a food item, determining whether to output a notification on the user device inviting the user to order a food item; and in response to determining to output a notification on the user device inviting the user to order a food item, selectively outputting a notification on the user device inviting the user to order a food item.

Description

REPEAT ORDER NOTIFICATIONS

CROSS-REFERENCE TO RELATED APPLICATION

[0001]This application claims the benefit of U.S. Provisional Patent Application No. 62/169,256, filed June 1 , 2015, the benefit of U.S. Patent Application No.

14/727,659, filed June 1 , 2015, the benefit of U.S. Patent Application No.

14/727,237, filed June 1 , 2015, and the benefit of U.S. Patent Application No.

14/815,414, filed July 31 , 2015, which are hereby incorporated by reference in their entirety.

TECHNICAL FIELD

[0002] This document generally describes technology related to computer- generated recommendations for electronic orders, such as orders for food items placed through mobile applications.

BACKGROUND

[0003] Mobile computing devices (e.g., smartphones, tablet computing devices, wearable computing devices) have been programmed to assist users with placing orders for goods and services. For example, users can download and install mobile applications ("mobile apps") for retailers, and can use the mobile apps to browse goods, select goods (e.g., place goods in an electronic shopping cart), purchase the selected goods (e.g., electronically checkout), designate a way for the user to get the goods (e.g., delivery, in-store pickup), and can track the progress of their orders (e.g., view order status).

[0004] Some mobile apps can include location-based services to provide users with information that is likely to be relevant the users' current locations. For example, a mobile app for a retailer with multiple physical stores can include location based services that allow a user to identify the closest store nearby for the retailer. For instance, a user of such a mobile app may select a feature to view the closest store nearby, and the mobile app can access the current location of the mobile computing device that is running the mobile app, provide it to a location service for the retailer, and receive in response a listing of the stores for the retailer that are closest to the mobile computing device's current location. SUMMARY

[0005] Innovative aspects of the subject matter described in this specification may be embodied in methods that include the actions of receiving a particular set of user data, the particular set of user data including user data obtained from a user device; obtaining a predictive model that estimates a likelihood of a user to order a food item, wherein the predictive model is generated using observation data that includes historic user data and user data from other user devices; providing the particular set of user data to the predictive model; obtaining, from the predictive model, an indication of a likelihood of the user to order a food item; based on the indication of a likelihood of the user to order a food item obtained from the predictive model, determining whether to output a notification on the user device inviting the user to order a food item; and in response to determining whether to output a notification on the user device inviting the user to order a food item, selectively outputting a notification on the user device inviting the user to order a food item.

[0006] Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination thereof installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

[0007] The foregoing and other embodiments can each optionally include one or more of the following features, alone or in combination. In some implementations the method includes the actions of receiving an acceptance of the invitation to order a food item; and processing the order for the food item.

[0008] In some implementations the predictive model comprises a first sub- predictive model and a second sub-predictive model, wherein the first sub-predictive model is configured to receive a data input and generate a respective output, and the generated respective output is provided as input to the second sub-predictive model. [0009] In certain aspects the first sub-predictive model is generated using observation data that includes a user's purchase history, browser history, search query history, calendar history and location history.

[0010] In some implementations the first sub-predictive model estimates an inclination of the user to cook.

[0011] In other implementations the first sub-predictive model estimates an inclination of the user to dine out.

[0012] In some aspects the first sub-predictive model estimates a likelihood of that the user has already ordered food within a recent time interval.

[0013] In other aspects the first sub-predictive model estimates a likelihood of that the user has already ordered a food item.

[0014] In certain implementations the first sub-predictive model estimates a likelihood that the user has performed an activity that is associated with ordering food.

[0015] In other implementations the first sub-predictive model estimates a likelihood that the user has performed an activity that is associated with not ordering food.

[0016] In some aspects the second sub-predictive model comprises a final predictive model component and the second sub-predictive model receives one or more outputs from the first sub-predictive model.

[0017] In certain aspects the second sub-predictive model estimates a likelihood of a user to order a food item, wherein the predictive model is generated using observation data that includes historic user data.

[0018] In some implementations the particular set of user data includes location information, time and date information, calendar entries information, weather information and mode of transport information.

[0019] In some implementations the predictive model comprises a decision tree.

[0020] In some aspects the indication of how likely a user of the user device wants to order a food item includes a confidence score.

[0021] In other aspects, determining whether to output a notification on the user device inviting the user to order a food item comprises generating a confidence score threshold and determining whether the confidence score exceeds or meets the confidence score threshold. [0022] In some implementations selectively outputting a notification on the user device inviting the user to order a food item comprises generating one or more food item recommendations; selecting a food item recommendation from the one or more food item recommendations; generating a notification inviting the user to order the food item; and providing the generated notification inviting the user to order the food item for display on the user device.

[0023] In another aspect, in response to a purchase, the vendor may generate a record of the purchase, including a purchase price, the goods purchased, the date, and the shipping address, and may email a receipt to a purchaser. A credit card company may generate a record that identifies the vendor, the purchase price, and a date. Customers may also generate records of their purchases, e.g., by entering a purchase price into an online money management application, or by posting information about the purchase to social media.

[0024] With the permission of the purchaser, a system may collect any or all of this information, and may process this information to generate a purchase history. The purchase history may include, for each purchase, a data item that includes data that identifies a customer, a purchase date, a type of good purchased, and a confidence score. The system generates these data items by comparing the purchase data, financial data, and social media data to identify purchases by different customers from different vendors. The system accesses data that identifies the types of goods sold by each vendor to generate the data items. The system then stores the data items.

[0025] The system analyzes the data items for patterns. Some of the patterns that the system may identify include a customer purchasing a particular type of good on specific days of the week, a customer purchasing a particular type of good the day after purchasing another type of good, or a customer purchasing or not purchasing a particular type of good on a specific day of the month. Based on these patterns, the system may infer or generate rules, such as rules for generating user interfaces for purchasing other goods or for providing marketing material. The rules may be created to entice a customer to purchase items the customer may already be inclined to purchase, or items that the customer may not typically purchase, as suggested by the patterns. For example, a rule may specify that, on specific days, a type of good that a customer is less likely to purchase should be moved to a more prominent position in an order taking user interface, or that a type of good that a customer is less likely to purchase should be discounted.

[0026] The next time that a customer accesses a vendor's website or opens a vendor's application, the system accesses the rules and identifies a rule that corresponds a current scenario. For example, a rule based on a pattern of repeated pizza purchase on Fridays by a particular customer may instruct an application to generate a user interface to discount salads and sandwiches when the customer accesses the application on Fridays. The system accesses this rule and generates a user interface to present to the user that includes pizza at the regular price and discounted salads and sandwiches. The customer may select a pizza as the customer typically does on Friday, but also purchase a salad and a sandwich because both are on sale, thus increasing the purchase total for the customer over what is expected.

[0027] According to one innovative aspect of the subject matter described in this specification may be implemented in a method that includes the actions of receiving, from one or more computers, order data, user data, and other data; based on the order data, the user data, and the other data, determining, for a particular user, an order confidence score that corresponds to a likelihood that the particular user ordered a particular good from a particular vendor on a particular day; receiving vendor-type mapping data that correlates each vendor with a type of good sold by a respective vendor; based on the vendor-type mapping data, determining a good-type confidence score that corresponds to the likelihood that the particular good or the particular vendor is associated with a particular type of good; based on the good- type confidence score and the order confidence score, determining a composite confidence score that corresponds to a likelihood that the particular user ordered the particular type of good on the particular day; and storing the composite confidence score, data identifying the particular user, data identifying the particular type of good, and data identifying the particular date.

[0028] These and other implementations can each optionally include one or more of the following features. The order data includes data associated with goods orders and dates that the goods were ordered. The user data includes data associated with location and application usage. The other data includes data associated with financial data, email data, and social media data. The vendor-type mapping data is received from one or more computers that store user ratings and reviews of vendors. The vendors are restaurants, the goods are food, and the types of goods are cuisines. The composite confidence score is an average of the good-type confidence score and the order confidence score.

[0029] Other implementations of this aspect include corresponding systems, apparatus, and computer programs recorded on computer storage devices, each configured to perform the operations of the methods.

[0030] According to one innovative aspect of the subject matter described in this specification may be implemented in a method that includes the actions of receiving, from an application running on a computing device, a request to order goods from a vendor, the request including data identifying a user of the computing device and the type of goods; identifying a particular rule, from a plurality of rules for generating a user interface of the application, that corresponds to the user, the type of the goods, and a current date; and based on the particular rule, generating an order-taking user interface.

[0031] These and other implementations can each optionally include one or more of the following features. The order-taking user interface identifies goods in a default configuration and at default prices. The order-taking user interface includes adjusting a default price for one or more of the goods listed in the order-taking user interface. Generating the order-taking user interface includes modifying the default configuration. The vendors are restaurants, the goods are food, and the types of goods are cuisines. Generating the order-taking user interface is further based on a location of the user. The actions further include identifying a second rule, from the plurality of rules that corresponds to the user, the type of the goods, and a current date, where generating the order-taking user interface is based further on the second rule.

[0032] Other implementations of this aspect include corresponding systems, apparatus, and computer programs recorded on computer storage devices, each configured to perform the operations of the methods.

[0033] According to one innovative aspect of the subject matter described in this specification may be implemented in a method that includes the actions of receiving data tuples that each include a confidence score, data identifying a user, data identifying a type of good, and data identifying a date, each confidence score corresponding to a likelihood that the user purchased a respective type of good on a respective date; identifying patterns among the data tuples; based on one or more of the patterns, generating a rule for generating an order-taking user interface of an application for ordering goods; and storing the rule.

[0034] These and other implementations can each optionally include one or more of the following features. The rule includes instructions for adjusting a default price for one or more of the goods listed in the order-taking user interface. The rule includes instructions for modifying a default configuration of the order-taking user interface. Identifying patterns among the plurality of data tuples includes identifying a first group of the data tuples that identify a same type of good; identifying a second group of the data tuples that include a confidence score that satisfies a threshold, the first group of the data tuples including the second group of the data tuples; and identifying a pattern of the respective dates in the second group of the data tuples. The one or more of the patterns identifies repeated purchase of a particular type of good. The goods are food, and the types of goods are cuisines. Generating a rule for generating an order-taking user interface of an application for ordering goods includes generating a rule for increasing purchases initiated through the order-taking user interface.

[0035] Other implementations of this aspect include corresponding systems, apparatus, and computer programs recorded on computer storage devices, each configured to perform the operations of the methods.

[0036] Particular implementations of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. A system may generate order-taking user interfaces to increase user purchases.

[0037] In another aspect, an alternative delivery destination for a package may be suggested to the package's recipient. The alternative delivery destination may be a location where the recipient may meet the agent on route to deliver the package. Multiple candidate alternative delivery destinations may be presented to the recipient, and the recipient may select one of the candidate alternative delivery destinations using a mobile device. The recipient may also receive a notification that the delivery agent is within some proximity to the original delivery destination.

[0038] In one aspect, a method includes determining a location of a delivery agent that is associated with a delivery route having one or more delivery destinations and determining that the location has satisfied one or more proximity criteria. The method also includes, in response to determining that the location has satisfied the one or more proximity criteria, providing an initial alternative delivery user interface to a device of a user that is associated with a particular delivery destination on the route, wherein the alternative delivery user interface includes a control for initiating an alternative delivery destination option. The method also includes receiving an indication that the control for initiating the alternative delivery destination option has been selected, determining one or more candidate alternative delivery destinations based at least on the location of the delivery agent and a location associated with the user, and providing an additional alternative delivery user interface to the device of the user, wherein the additional alternative delivery user interface includes one or more controls for selecting one or more corresponding alternative delivery destinations. The method also includes receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected and, in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, transmitting, to the delivery agent, an indication of the selected, particular alternative delivery destination.

[0039] Implementations may include one or more of the following features. The proximity criteria may include one or more of a proximity to the user, a proximity to a delivery destination, a proximity to a delivery route, a location within a designated geographic region, an estimated travel time associated with the user, or an estimated travel time associated with the delivery agent. The method may include in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining an updated delivery route. The method may include transmitting, to the delivery agent, the updated delivery route. Determining an updated delivery route may include excluding the particular delivery destination from the delivery route. The method may include in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining a delivery agent wait time associated with the particular alternative delivery destination.

[0040] Other implementations of these and other aspects include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices. A system of one or more computers can be so configured by virtue of software, firmware, hardware, or a combination of them installed on the system that in operation cause the system to perform the actions. One or more computer programs can be so configured by virtue of having instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

[0041] Advantageous implementations may include one or more of the following features. The techniques described may allow a package recipient to interact with the delivery process. User interaction may provide a degree of flexibility in the delivery process. The techniques may allow the delivery of a package to be more convenient for a recipient and/or a delivery agent. The techniques may reduce overall waiting time for a recipient. The techniques may allow minor changes to a previously planned delivery route to minimize affecting other recipients on that route. The techniques may provide notifications to keep the recipient informed of the location and delivery schedule of the delivery agent.

[0042] The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other potential features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

DESCRIPTION OF DRAWINGS

[0043] FIG. 1 depicts example mobile device user interfaces.

[0044] FIG. 2 depicts a block diagram of an example system for providing repeat order notifications.

[0045] FIG. 3 depicts a flowchart of an example process for providing a repeat order notification.

[0046] FIG. 4 illustrates various user interfaces that are displayed on a client device when a user orders goods from a vendor.

[0047] FIG. 5 illustrates an example system for ordering goods from a vendor.

[0048] FIG. 6 illustrates various user interfaces for ordering goods from a vendor.

[0049] FIG. 7 is a flow chart of an example process generating a confidence score that a user purchased a type of good on a particular date.

[0050] FIG. 8 is a flow chart of an example process for generating a user interface to order goods. [0051] FIG. 9 is a flow chart of an example process for generating rules to generate user interfaces for ordering goods.

[0052] FIG. 10A illustrates an example alternative delivery system.

[0053] FIGS. 10B-1 D illustrate example user interaction displays on a mobile device.

[0054] FIG. 10E illustrates an example notification display for a delivery agent.

[0055] FIGS. 1 1 A-B show example interfaces for a user's mobile device.

[0056] FIG. 12 illustrates a block diagram of an example alternative delivery system.

[0057] FIG. 13 is a flow chart illustrating an example process for providing an alternative delivery destination.

[0058] FIG. 14 depicts an example system for processing repeat order notifications.

[0059] FIG. 15 depicts an example computing device and a mobile computing device.

[0060] Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

[0061] This specification describes a system for providing repeat order notifications on a user device inviting a user to order a food item. The system employs a predictive model that estimates a likelihood of a user to order a food item, and based upon the estimated likelihood, outputs a corresponding notification on the user device inviting the user to order a food item. The predictive model is trained to estimate a likelihood of a user to order a food item using historical user data. For example, the historical user data may include frequented travel path information, food consumption pattern information, recent food order information and food type consumption patterns. The predictive model also uses other data obtained from the user device to estimate the likelihood of a user to order a food item, such as location information, time and date information, calendar entries information, weather information and mode of transport information.

[0062] FIG. 1 depicts two example mobile device user interfaces 100 and 120 presented at different occasions to a user 103 on a mobile device 101.

[0063] The user interface 100 depicted in FIG. 1 is a representative mobile device user interface. In this example, a time and date indicator 102 shows that it is currently 14: 17 on Monday, February 10. In addition, the user interface shows a weather indicator 104 which presents the weather conditions at the user's current location. The weather indicator 104 shows that the user is currently in London, England, that the current temperature is 46 degrees Fahrenheit and that the weather condition is drizzly. The location of the user may be determined using GPS or other similar mechanisms, for example IP address or cell tower triangulation. In some implementations, the mobile device may have access to a locations database which stores information identifying places of interest to the user, and geographic coordinates associated with the identified places of interest. Such places of interest can include a home address or regularly frequented locations such as a place of work, a gym, addresses or restaurants.

[0064] A calendar alert box 106 indicates to the user any upcoming prior arrangements, such as appointments, reminders or meetings. The calendar alert box may communicate with a task and calendar database to access calendar information, such as appointment information, task lists, and other similar information for a user of the mobile device. The calendar information may, for example, include information about start and end times of appointments in addition to the descriptions of the appointments, and contact information for other people expected to be at the appointments. The task lists may include descriptions of tasks or chores that the user needs to complete in the future. Data in the tasks and calendar database may be accessed to determine identifying information for users associated with appointments or tasks, beginning and ending times for various appointments or active periods for tasks, and other information about the appointments or tasks. In this example, the user interface 100 shows the user that he or she has organized a meeting with "Dave" to commence in 3 minutes time. In some implementations, the user device may also indicate that a prior arrangement is overdue, for example if the user is running 5 minutes late and has not deleted the calendar alert, the calendar alert box may show that the meeting was due to commence 5 minutes ago.

[0065] A text or short message service (SMS) alert box 108 indicates to the user any unread text messages received by the user. The text or SMS alert box 108 includes the name or phone number of the sender of the text message, and an excerpt of the message received. The text or SMS alert box 108 is one example of many alert boxes that may be presented to the user. For example, in some implementations the user interface 100 may present an email alert box upon receiving an unread email, a voice mail alert box upon receiving an unopened voice mail message, or an alert from a social media application upon receiving unread communication of some kind. In some implementations, the phone number of the sender of the text message is shown within the text or SMS alert box 108, e.g. the phone number 281 1-7300. In other implementations, the name of the sender of the text message is shown. The text or SMS alert box 108 may communicate with a contacts database in order to provide the name of the sender of the text message. The contacts database may include names of the user's contacts, telephone numbers for the contacts, and address information for the contacts. In some implementations the excerpt of the received message may include the first 10 words of the received text message, or if the message is shorter than the predetermined limit, the whole text message, e.g., the text message "Thanks for buying lunch! See you tomorrow."

[0066] The user interface also presents alert boxes from software applications installed and executing on the mobile device. For example, the application alert box 110 indicates a message for the user or a current status of the user from a software application executing on the mobile device. In this example, the user is executing the application "Calorie Counter" on the mobile device, and has received an alert from the software application. The alert indicates the user's daily progress, the user's daily calorie goal of 1 ,617 calories, the user's remaining 348 calories for that day and a percentage of the user's current calorie intake. In other implementations, the user interface may present multiple alert boxes from multiple software applications installed and executing on the mobile device. The alerts may display icons, video, graphics, images and text that include various indicators relating to the software application. [0067] The user interface 120 depicted in FIG. 1 is another representative mobile device user interface. In this example, a time and date indicator 122 shows that it is currently 18:38 on Friday, July 15. In addition, the user interface shows a weather indicator 124 which presents the weather conditions at the user's current location. The weather indicator 124 shows that the user is currently in San Diego, USA, that the current temperature is 86 degrees Fahrenheit and that the weather condition is sunny. In some implementations the mobile device may access a location database storing information identifying places of interest to the user, and determine whether or not the user is currently located in or near a place of interest. For example, the mobile device may determine that the current location of San Diego is the user's hometown.

[0068] Unlike the user interface 100, the user interface 120 does not include a calendar alert box, indicating that the user does not have any upcoming or overdue prior arrangements, such as appointments, reminders, meetings or tasks. Similarly, the user interface 120 also does not include a text or short message service (SMS) alert box indicating that the user has not received any unread text messages.

[0069] The user interface 120 includes an alert box 126 presenting an alert from the executing software application "Calorie Counter." The alert indicates the user's daily progress, the user's daily calorie goal of 1 ,617 calories, the user's remaining 748 calories for that day and a percentage of the user's current calorie intake.

[0070] The user interface 120 includes an order notification 128 for a food item. The order notification 128 is presented to the user on the user interface 120 based upon determining that the user is likely interested in ordering a food item. In this example, the mobile device may have received and processed a set of user data in order to determine that the user is likely interested in ordering a smoothie. For example, the mobile device may have recognized that the user is likely to order food, in particular a smoothie, on a Friday evening, as opposed to ordering food on a Monday afternoon, as depicted in user interface 100. Furthermore, the mobile device may also recognize that a user is more likely to order a smoothie in the summertime when the weather is fine, as opposed to winter when the weather is cold and wet, as depicted in user interface 100. In addition, the mobile device may use location data to recognize that the user is likely to order a smoothie from a specific restaurant/provider, for example from a restaurant in their hometown, or from a chain of restaurants in several towns.

[0071] In some implementations the mobile device may access calendar information and text message information in order to determine whether the user is likely to order a food item, for example the mobile device may recognize that the user is unlikely to want to order a food item immediately before an appointment, e.g., before a meeting with Dave in 3 minutes, or shortly after eating lunch. In addition, the mobile device may use information from executing software applications to determine whether a user is likely to order food. For example, as depicted in user interface 120, the mobile device may recognize that a user is more likely to want to order a smoothie if they are currently well within their allowed calorie intake for that day. Determining whether a user is likely interested in ordering a food item will be described in more detail below with reference to FIG. 3.

[0072] The order notification 128 invites the user to place an order for a food item, for example by presenting the message "Hey there! Do you want to order a smoothie?" The order notification 128 includes two selectable links 130 and 132 responsive to the invitation. In some implementations, upon selecting the link 132 "Maybe later," the order notification may remain on the user interface, may occupy a smaller space on the user interface, e.g., as a smaller icon, or may disappear entirely. In some implementations, upon selecting the link 130 "Sure!" the user may be presented with an alternative user interface displaying information relating to ordering a smoothie. Processing an order notification is described in more detail below with reference to FIG. 14.

[0073] FIG. 2 depicts a block diagram of an example system 200 for providing repeat order notifications. The system 200 can be capable of receiving data that includes user data from a user device. The received data can be provided to a predictive model, and a likelihood of a user to order a food item may be determined. Based on the determined likelihood, the system 200 can determine to output a notification on the user device inviting the user to order a food item. The system may generate an order recommendation and selectively output a corresponding notification on the user device inviting the user to order the recommended food item. [0074] Generally, the system 200 may include a predictive model 204, which includes a first sub-predictive model 206 that receives user data 202 and classifies the user data and a second sub-predictive model 208 that receives user data and an output from the first sub-predictive model and estimates a likelihood of a user to order a food item, and an order recommendation generator 210 that generates order recommendations to be presented to a user on a user device 212 in a repeat order notification 214.

[0075] The predictive model 204 receives as an input a set of user data 202. The user data includes raw observational data obtained from a user device. The raw data may include information regarding the current time and date, current weather conditions, current location, current mode of transport, recent appointments or activities, upcoming appointments or activities and recent communication.

[0076] The first sub-predictive model 206 may receive some or all of the user data input 202. The first sub-predictive model 206 includes one or more classifiers that use the user data input to generate outputs that may be used to estimate a likelihood of a user to order a food item. For example, the first sub-predictive model 206 may include a set of classifiers that receive a set of raw observational data and generate a set of outputs that estimate an inclination of a user to cook, an inclination of a user to dine out, a likelihood of that the user has already ordered food within a recent time interval, a likelihood of that the user has already ordered a food item, a likelihood of that the user has performed an activity that is associated with ordering food, or a likelihood of that the user has performed an activity that is associated with not ordering food. In some implementations, the first sub-predictive model is a decision tree. In other implementations, the first sub-predictive model includes one or more neural network layers and classifiers. The first sub-predictive model may be generated or trained using observation data that includes a user's purchase history, browser history, search query history, calendar history and location history.

[0077] The second sub-predictive model 208 may receive some of the user data input 202 and any outputs generated by the first sub-predictive model 206. The second sub-predictive model 208 is a final predictive model component of the predictive model 204. The second sub-predictive model 208 includes a food ordering classifier that uses the user data input 202 and any outputs generated by the first sub-predictive model 206 to estimate a likelihood of a user to order a food item. In some implementations the second sub-predictive model 210 is a decision tree. In other implementations the second sub-predictive model is a final layer of a neural network. The second sub-predictive model may be generated or trained using observation data that includes a user's purchase history, browser history, search query history, calendar history and location history.

[0078] The second sub-predictive model outputs an estimated likelihood of a user to order a food item. In some implementations the estimated likelihood is a confidence score reflecting the predictive model's confidence that the user is likely to order a food item. The estimated likelihood is determined using the received user data input 202 and any outputs generated by the first sub-predictive model 206. In some implementations, the outputs generated by the first sub-predictive model 206 may increase the likelihood of a user to order a food item. For example, if the second sub-predictive model receives a user data input indicating that the weather is warm and the user is driving towards a smoothie provider, as well as an indication from the first sub-predictive model that the user often purchases smoothies, the estimated likelihood of a user to order a smoothie may be high. In other implementations, the outputs generated by the first sub-predictive model 206 may decrease the likelihood of a user to order a food item. For example, if the second sub-predictive model receives a user data input indicating that the user is traveling home from work on a Friday evening at 7:30pm on a route past a pizza restaurant, as well as an indication from the first sub-predictive model that the user enjoys to cook, the estimated likelihood of a user to order a pizza may be low.

[0079] The order recommendation generator 210 may receive an indication that a user is likely to order a food item. The order recommendation generator 210 produces order recommendations to be presented to a user on a user device 212 in a repeat order notification 214. The order recommendation generator may generate food order recommendations using observation data that includes a user's purchase history, browser history, search query history, calendar history and location history. For example, the order recommendation generator may generate a recommendation to order a pepperoni pizza from a particular Italian restaurant based on observing a pattern in the observation data indicating that the user regularly orders a pepperoni pizza from a particular Italian restaurant. In other examples, the order

recommendation generator may generate a recommendation to order a smoothie from one or more food outlets based on observing a pattern in the observation data indicating that the user regularly orders different smoothies from different providers following a workout.

[0080] The user device 212 receives the order recommendation from the order recommendation generator 210 and presents a repeat order notification 214 to the user on the user device. The repeat order recommendation may include one or more user selectable links that enable the user to decline or accept the repeat order recommendation. For example, upon accepting the repeat order recommendation, the user device may execute an application accessible through a web browser running on a computing device that enables a customer to place an order. In other examples, the user device may execute a mobile application, SMS application, or voice interface to enable a user to process a repeat order notification and place an order. An example system for processing repeat order notifications is described in more detail below with reference to FIG. 14.

[0081] FIG. 3 is a flowchart of an example process 300 for providing a repeat order notification on a user device. For example, the process 300 can be performed by the system 200 in response to receiving a particular set of user data.

[0082] At step 302, the system receives a particular set of user data. The particular set of user data includes user data obtained from a user device. In some

implementations, the particular set of user data may include raw data obtained from a user device, such as information regarding the current time and date, current weather conditions, current location, current mode of transport, recent appointments or activities, upcoming appointments or activities and recent communication with friends, colleagues or family.

[0083] At step 304, the system obtains a predictive model that estimates a likelihood of a user to order a food item. In some implementations, the predictive model is a decision tree. In other implementations, the predictive model is a deep neural network including several classifiers. The predictive model is generated using observation data that includes historic user data and user data from other user devices. In some implementations, the historic user data may include information regarding a user's purchase history, browser history, search query history, calendar history and location history. The predictive model includes a first sub-predictive model and a second sub-predictive model. The first sub-predictive model is configured to receive a data input and generate a respective output, which is in turn provided as input to the second sub-predictive model.

[0084] In some implementations, the first sub-predictive model may estimate an inclination of the user to cook. The first sub-predictive model may be generated using observation data that includes historic user data and user data from other user devices, such as the type of food products a user buys, how regularly the user eats out, patterns or themes in a user's browser history and search query history. For example, if a user regularly shops in a shop selling cooking equipment, the first sub- predictive model may interpret this behavior as an indication that the user enjoys to cook. Similarly for if the user tends to buy raw ingredients or exotic ingredients. However, if the user tends to buy canned food or ready prepared meals, the first sub-predictive model may interpret this behavior as indication that the user does not enjoy cooking. In other examples, if a user's purchase history includes regular purchases at restaurants or cafes, the first sub-predictive model may interpret this behavior as an indication that the user does not enjoy to cook. Or, if a user's browser history shows that a user regularly searches for food recipes, or visits food-related blogs or websites, the first sub-predictive model may interpret this behavior as indicating that the user enjoys cooking.

[0085] In other implementations, the first sub-predictive model may estimate an inclination of the user to dine out. The first sub-predictive model may be generated using observation data that includes historic user data and user data from other user devices, such as how regularly the user dines out, or patterns and themes in a user's browser history and search query history. For example, if a user's purchase history includes regular purchases at restaurants or cafes, the first sub-predictive model may interpret this behavior as an indication that the user likes to dine out. Similarly, if the user's browser history and search query history shows that the user regularly searches for local restaurants or cafes, or reads and writes reviews about restaurants or cafes, the first sub-predictive model may interpret this behavior as indicating that the user likes to dine out.

[0086] In some implementations, the first sub-predictive model may estimate a likelihood that the user has already eaten within a recent time interval. The first sub- predictive model may be generated using observation data that includes historic user data and user data from other user devices, such as location data, recent appointments or activities, or communication history. For example, if a user's calendar shows that the user had an appointment to meet someone for lunch less than 2 hours ago, the first sub-predictive model may interpret this behavior as indicating that the user has already eaten recently, and would not be interested in ordering a food item in the near future. Similarly, if the user has spoken on the telephone, written an email or text message, or used some other form of

communication and discussed a recent meal or food consumption, the first sub- predictive model may interpret this behavior as indicating that the user has already eaten recently. In other examples, the first sub-predictive model may access a user's location history to determine whether a user has recently purchased and/or consumed a food item. For example, if the user was located at a restaurant for a duration of 30 minutes 1 hour prior to the current time, the first predictive model may determine a high likelihood of the user already having eaten. If, however, the user was located at a gym for a duration of 60 minutes 1 hour prior to the current time, the first predictive model may interpret this behavior as an indication that the user has not already eaten. In other examples, if a user's location history or purchase history shows that a user has already eaten pizza twice this week, the first sub-predictive model may interpret this behavior as indicating that the user would not be interested in ordering a pizza in the near future.

[0087] In other implementations, the first sub-predictive model may estimate a likelihood that the user has already ordered a food item. The first sub-predictive model may be generated using observation data that includes historic user data and user data from other user devices, such as purchase history or communication history. For example, if a user's purchase history shows that the user has recently purchased a food item from an ordering service, the first sub-predictive model may interpret this behavior as indicating that the user has already ordered a food item. Similarly, if the user has made a call or sent an email or text message to a food ordering service recently, or if the user has discussed ordering an item of food with a friend or family member via a telephone call or a text message, the first sub- predictive model may interpret this behavior as indicating that the user has already ordered a food item. [0088] In some implementations, the first sub-predictive model may estimate a likelihood that the user has performed an activity associated with ordering food. The first sub-predictive model may be generated using observation data that includes historic user data and user data from other user devices, such as location history, calendar history or communication history. For example, if a user's location history or calendar history shows that a user has recently visited a gym or performed some exercise, the first sub-predictive model may interpret this behavior as indicating that the user may be hungry and has performed an activity associated with ordering food.

[0089] In some implementations, the first sub-predictive model may estimate a likelihood that the user has performed an activity associated with not ordering food. The first sub-predictive model may be generated using observation data that includes historic user data and user data from other user devices, such as location history, calendar history or communication history. For example, if a user's location history or calendar history shows that a user has recently visited a dentist, the first sub-predictive model may interpret this behavior as indicating that the user may not wish to eat anything and has performed an activity associated with not ordering food. In other examples, if the user's communication history or calendar history shows that he or she has recently organized plans for dinner or lunch in the near future, the first sub-predictive model may interpret this behavior as indicating that the user may not wish to eat anything at the moment and has performed an activity associated with not ordering food.

[0090] The second sub-predictive model receives one or more outputs from the first sub-predictive model, and includes a final predictive model component. The second sub-predictive model estimates a likelihood of a user to order a food item, and is generated using observation data that includes historic user data.

[0091] At step 306, the system provides the particular set of user data to the predictive model.

[0092] At step 308, the system obtains an indication of a likelihood of the user to order a food item from the predictive model. The obtained indication of the user to order a food item includes confidence score indicative of the predictive model's confidence that the user would like to order a food item. [0093] At step 310, the system determines whether to output a notification on the user device inviting the user to order a food item, based on the indication of a likelihood of the user to order a food item obtained from the predictive model. In some implementations determining whether to output a notification on the user device includes generating a confidence score threshold and determining whether the obtained confidence score exceeds or meets the confidence score threshold. If the obtained confidence score exceeds or meets the confidence score, the system determines to output a notification on the user device.

[0094] In response to determining to output a notification on the user device inviting the user to order a food item, at step 312 the system selectively outputs a notification on the user device inviting the user to order a food item. In some implementations selectively outputting a notification on the user device inviting the user to order a food item includes generating one or more food item recommendations, selecting a food item recommendation from the one or more food item recommendations, generating a notification inviting the user to order the food item and providing the generated notification inviting the user to order the food item for display on the user device.

[0095] In some implementations, the food item recommendation includes a recommendation for a food item from a particular restaurant. For example, the system may determine that the user is most likely to order a pizza from a particular Italian restaurant. In other implementations, the food item recommendation may include a recommendation for a particular dish from one or more restaurants, for example a pepperoni pizza from one or more Italian restaurants. In yet other implementations, the food item recommendation may include both a

recommendation for a particular dish at a particular restaurant, for example for a pepperoni pizza from a particular Italian restaurant. In other implementations, the food item recommendation may include a recommendation for a food item to be ordered and collected, or for the food item to be ordered and delivered at an address specified by the user. In some implementations, the food item recommendation may include a selectable link to one or more of a corresponding website, online ordering facility or telephone number.

[0096] FIG. 4 illustrates various user interfaces that are displayed on a client device when a user orders goods from a vendor. Briefly, and as described in further detail below, scenarios 405a-105d illustrate a user 410 purchasing food using a mobile device 415 on various dates 420. To assist the user 410 in ordering food, the mobile device displays an ordering user interface 425 that includes the menu and prices. Once the user 410 selects the food to purchase, the mobile device displays a purchase user interface 430 that includes the order and the total.

[0097] In the example shown in FIG. 4, scenario 405a illustrates user 410a purchasing a pepperoni pizza using the mobile device 415a. On date 420a (in the figure, Friday, June 5), user 410a used a food ordering application on the mobile device 415a. The food ordering application running on the mobile device 415a may be an application for ordering from a particular restaurant, such as Pizza Restaurant, or may be an application for ordering from multiple restaurants, such as Pizza Restaurant and Sandwich Shop. The food ordering application displays an ordering interface 425a in the mobile device 415a. The ordering interface 425a includes a menu with the available foods and prices. In this example, the ordering interface 425a includes pizza at the top, with a cheese pizza at ten dollars and a pepperoni pizza at eleven dollars, subs in the middle, with a club at eight dollars, and salads at the bottom, with a Caesar salad at six dollars.

[0098] The user 410a selects the items to purchase from the user interface 425a. The next user interface displayed by the food ordering application is purchase user interface 430a. The purchase user interface 430a displays the items selected for purchase and the total price. In this example, the purchase user interface 430a displays one pepperoni pizza for a total of eleven dollars. The food ordering application may provide an additional user interface to accept payment information or include an interface to accept payment information on the user interface 430a.

[0099] Once the user places the order for food, the food ordering application may provide the order information to a server. The information may include the name of the restaurant, the food ordered, the date, and a user identifier. The server may aggregate the order information for user 410 and other users as well as other purchases by the user 410 and the other users. The server may receive order information from other applications or directly from restaurants and other vendors. Information received from other restaurants may only include information related to an order price and an order date. For example, a restaurant may provide information indication that a purchase for eleven dollars was made at 6:30pm on June 2. The server stores this information and analyzes it to identify ordering patterns for different users.

[00100] Scenario 405b illustrates a similar pizza order as scenario 405a. In scenario 405b, user 410b accesses a food ordering application running on mobile device 415b on date 420b, Friday June 12. When user 410b accesses the food ordering application, the food ordering application may send a request to a server to determine an appropriate configuration for the ordering user interface 425b. The server may provide instructions for configuring the ordering user interface 425b or provide a response that indicates the food ordering application should use the default ordering user interface configuration. In this example, the server analyzed the data from scenario 405a and did not identify any ordering patterns, and therefore, ordering user interface 425b is similar to ordering user interface 425b.

[00101] The user 410b selects the items to order from the ordering interface 425b. Purchase interface 430b indicates that the user 410b ordered one pepperoni pizza for a total of eleven dollars. As before, the food ordering application may provide this order information to the server. The server may identify that the same user 410 placed this order as the order illustrated in ordering interface 430a. The server analyzes the data from scenarios 405a and 405b and identifies that user 410 ordered a pepperoni pizza on consecutive Fridays. Based on these two orders, the server may determine that the user 410 is likely to order a pepperoni pizza on a Friday, but a confidence associated with that determination may not be high enough to modify an ordering interface 425 or to provide coupons or other marketing materials to user 410.

[00102] Scenario 405c illustrates a similar pizza order as scenarios 405a and 405b. In scenario 405c, user 410c accesses a food ordering application running on mobile device 415c on date 420c, Friday June 19. When user 410c accesses the food ordering application, the food ordering application may send a request to a server to determine an appropriate configuration for the ordering user interface 425c. As noted above, the server may have identified a pattern where the user 410 orders a pepperoni pizza each Friday. However, a confidence associated with that pattern may not satisfy a threshold. Therefore, the server may not provide any modification instructions to the food ordering application regarding the arrangement of user interface 425c. [00103] The user 410c selects the items to order from the ordering interface 425c. Purchase interface 430c indicates that the user 410c ordered one pepperoni pizza for a total of eleven dollars. As before, the food ordering application may provide this order information to the server. The server may now aggregate the orders from scenarios 405a, 405b, and 405c and identify a pattern of user 410 ordering a pepperoni pizza each Friday. The confidence associated with this pattern may be higher than when the server only had information from scenarios 405a and 405b and the confidence may be satisfy a threshold such that the server may generate a rule for generating the next ordering user interface. The rule may indicate that if user 410 attempts to place an order through the food ordering application on a Friday, then the food ordering application will display an ordering interface that includes discounts for salads and subs and place those discounts at a higher position on the ordering interface.

[00104] As illustrated in scenario 405d, user 41 Od accesses a food ordering application running on mobile device 415d on date 420d, Friday June 26. When user 410d accesses the food ordering application, the food ordering application may send a request to a server to determine an appropriate configuration for the ordering user interface 425d. As noted above, the server may have generated a rule for generating a user interface when the user 410 access the food ordering application on a Friday. Because the date 420d is Friday June 26, the server provides information to the food ordering application to generate a user interface 425d.

Ordering user interface 425d includes an indication that Pizza Restaurant current has a sale. Ordering user interface 425d lists subs at a more prominent position on the page, e.g., the top, with a club at four dollars instead of eight, salads in the middle, with a Caesar salad at three dollars instead of six, and with pizza in a less prominent position, e.g., at the bottom, with a cheese pizza at ten dollars and a pepperoni pizza at eleven dollars.

[00105] When viewing the ordering user interface 425d, the user 41 Od may decide that the sub and salad sales are too good to pass up and order a club sub and Caesar salad along with the usual pepperoni pizza. Purchase user interface 430d illustrates the additional purchases of the sub and salad for a total of $18. Even though Pizza Restaurant sold the sub and salad at a discount, the total purchase price for user 41 Od was greater than the previous purchase prices. [00106] FIG. 5 illustrates an example system 500 for ordering goods from a vendor. Briefly, and as described in further detail below, system 500 is configured to receive and analyze data related to vendor orders to identify patterns among users purchasing behavior. The system generates and stores rules for providing user interfaces and marketing information to users based on the patterns.

[00107] The system 500 receives data that includes vendor data 505, user data 510, and other data 515. The vendor data 505 includes data that vendors collect when each vendor makes a sale. In some implementations, the vendor data 505 includes the total purchase price and date of each order. For example, the vendor data 505 may include a data item that indicates that Pizza Restaurant sold twenty dollars of product on June 5, 2015 at 6:30pm. In some implementations, a data item may also include the products sold. For example, the twenty dollar order may also include information indicating that the order was for two cheese pizzas. In some

implementations, the vendor may also collect loyalty card information. Each time a customer purchases an item the customer may provide the customer's loyalty card so that the vendor may associate multiple purchases with the same customer. The vendor data 505 may also include information that associates multiple purchases with particular customers. For example, the vendor data 505 may include

information indicating that a particular customer purchased thirty dollars of goods on June 5 and that same customer, or at least a customer using the same loyalty card, purchased forty dollars of goods on June 9.

[00108] The user data 510 includes data received from a user's device, such as a mobile device, tablet computer, watch, television, laptop, desktop computer, or other computing device. The user's device may collect information through applications that a user accesses to purchase goods. The applications may be tied to a specific vendor. For example, the user may use an application for Pizza Restaurant to order food directly from Pizza Restaurant. The applications may be configured to place orders with multiple vendors. For example, an application may be configured to place orders with Pizza Restaurant, Sandwich Shop, and Veggie Palace. When a user places an order with a specific application, the application may collect data for the vendor name, the date and time, the goods ordered, the purchase price, a user identifier, and a device identifier. For example, a data item may include information related to a purchase of one hundred dollars for Cheetah running shoes from Shoe Store on June 3, 2015 at 3:00pm. The data item may also include information indicating that user runner41 made the purchase using the user's mobile device. The data item may also include location data. For example, if the user's mobile device includes a GPS, then the data item may include GPS coordinates of the location of the user's device when the user purchased the Cheetah running shoes.

[00109] The user data 510 may also include data that a user accesses through other applications that are not associated with ordering goods. The other applications may be applications that receive data when a user places an order or that a user posts data. For example, an email application may receive a receipt after a user orders goods and when the user reads the receipt, the contents of the email may be captured by the device and may include information such as the purchase time and date, goods ordered, vendor, and the user who placed the order. A social media application may receive data from a user when the user posts information related to a purchased product. A user may post "Just had a great meal at Pizza Restaurant." The text of the post, the location of the user device, any picture or video associated with the pose, and the time and date may be part of the associated data item.

[00110] The other data 515 includes data that is associated with purchasing goods and that may not be accessed by a user on a device. The other data 515 may include credit card data such as a list of purchase prices, vendors, and dates, paired with data identifying the owner of the credit card. Other financial information such as bank statements may be included in the other data 515. The other data 515 may include email and social media data. For example, a user may receive an email receipt after purchasing goods, but may not read the email. In this instance, the email may not be included in the user data 510 because the user did not read the email, but the email will likely be included in the other data 515. Emails that a user read may be included in both the user data 510 and the other data 515. The social media data may be posts that user did not create or access on one of the user's device. For example, a post may tag another user but the tagged user may not access the post on one of the user's devices. This post and similar posts may be included in the other data 515.

[00111] The order detector 525 of the system 500 receives the vendor data 505, user data 510, and other data 515 through the internet 520. In some

implementations, the order detector 525 requests the vendor data 505, the user data 510, and the other data 515. In some implementations, the computing devices that store the vendor data 505, the user data 510, or the other data 515 push the data to the order detector 525. One or more of the computing devices that store the vendor data 505, the user data 510, or the other data 515 may provide their data to the order detector 525 at any particular time.

[00112] The order detector 525 identifies orders for goods among the vendor data 505, the user data 510, and the other data 515. The order detector 525 analyzes the vendor data 505, the user data 510, and the other data 515 and associates an order confidence score with each order. For example, the order detector 525 may identify a credit card payment on Sally's credit card to Pizza Restaurant for ten dollars on June 4, 2015 at 7:00pm. The order detector 525 may create a data item, or data tuple, that includes data identifying Sally, Pizza Restaurant, ten dollars, and June 4, 2015 at 7:00pm. Because the purchase was on Sally's credit card, the order detector 525 may associate a high order confidence score, such at 0.95 with the data item. The order detector 525 may create another data item based on data from a social media post. The social media post may be "Just had a great meal at Sandwich Shop" that was posted using Jack's device to Jack's account at 5:00pm on June 3, 2015 while at 423 Elm St. The order detector 525 may create a data item that includes data identifying Jack, Sandwich Shop, 423 Elm St., and June 3, 2015 at 5:00pm. Because the post was posted using Jack's device to Jack's account, the order detector 525 may associate a high order confidence score, such at 0.90 with the data item. The order detector 525 may create another data item based on data from a vendor. The order detector 525 may receive data indicating that Veggie Palace sold ten dollars of goods on June 4, 2015 at 12:00pm. The order detector 525 may create a data item that includes data indicating Veggie Palace, ten dollars, and June 4, 2015 at 12:00pm and associate it with an order confidence score of 0.95.

[00113] The order detector 525 may receive data indicating that Sally posted a picture to social media of a slice of pizza on June 4, 2015 at 7:30pm. Based on this information, the order detector 525 may create a data item that includes data identifying Sally, pizza, and June 4, 2015 at 7:30pm. Because it is unclear if the pizza was Sally's, the order detector may associate this data item with a middle order confidence score of 0.45. The order detector 525 may also receive data indicating that Emily posted "I'm hungry" to social media at June 4, 2015 at 1 1 :45am while near Veggie Palace. The order detector 525 create a data item that includes data identifying Emily, Veggie Palace, and June 4, 2015 at 1 1 :45am. Because it is unclear if Emily purchased food from Veggie Palace on June 7, the order detector 525 associates this data item with an order confidence score of 0.15.

[00114] The order detector 525 includes an event correlator 530 to reconcile different data items that may correspond to the same event. The event correlator 530 may adjust order confidence scores or combine data items or both. For example, the event correlator 530 may compare the data item that includes data identifying Sally, Pizza Restaurant, ten dollars, June 4, 2015 at 7:00pm, and 0.95 and the data item that includes data identifying Sally, pizza, June 4, 2015 at 7:30pm and, 0.45. The event correlator 530 may compare those two data items and determine that they both correspond to the same purchase event. The resulting data item may include data identifying Sally, Pizza Restaurant, pizza, ten dollars, June 4, 2015 at 7:15pm. The event correlator 530 may increase the order confidence score to 0.97.

[00115] As another example, the event correlator 530 may compare the data item that includes data indicating Veggie Palace, ten dollars, June 4, 2015 at 12:00pm, and 0.95 and the data item that includes data identifying Emily, Veggie Palace, June 4, 2015 at 11 :45am, and 0.15. The event correlator 530 may compare these two data items and determine that there is a possibility that they both correspond to the same purchase event. The resulting data item may include data identifying Emily, Veggie Palace, ten dollars, June 4, 2015 at 12:00pm. The event correlator 530 may adjust the order confidence score to 0.30 because it may be unclear if the ten dollar order corresponds to Emily or if she even ate at Veggie Palace. The event correlator 530 may consider the popularity of various vendors when adjusting confidence scores. For example, if the event correlator 530 identifies many purchases around 12:00pm on June 4, 2015, the event correlator may be less certain that the ten dollar order correspond to Sally. If the event correlator 530 identifies few purchases around 12:00pm on June 4, 2015, the event correlator may be more certain that the ten dollar order correspond to Sally.

[00116] In some implementations, the event correlator 530 may delete data items when the event correlator 530 combines the data items into fewer data items. This may occur when the resulting order confidence score is higher than the previous order confidence scores. In some implementations, the event correlator 530 may not delete data items when the event correlator 530 combines the data items into fewer data items. This may occur when the resulting order confidence score is lower than the previous order confidence scores.

[00117] The order detector 525 provides the data items to the good-type classifier 535. the good-type classifier 535 matches a type of good that likely corresponds to the data item and updates the data item to reflect that type of good. The good-type classifier 535 also includes a good-type confidence score that reflects the certainty that the good-type corresponds to the data item. The good-type classifier 535 may access vendor-type mapping data 540 to determine the type of goods sold by a particular vendor. The vendor-type mapping data 540 may include data stored in good or product review web sites where the reviews are provided by an editor or directly by customers. The vendor-type mapping data 540 may also include data from websites that display goods for sale such as menus. The websites may be maintained by a vendor or by a third party.

[00118] In some implementations, the good-type classifier 540 may update the information stored in the vendor-type mapping data 540. The updated information may originate from the vendor data 505, the user data 510, and the other data 515. For example, order detector may have generated a data item that includes data identifying Emily, Veggie Palace, ten dollars, June 4, 2015 at 12:00pm. At 12: 15pm on that same day, Emily may have posted a picture of a salad to social media with the caption "Eating a salad at Veggie Palace." Using this information the good-type classifier 540 may update the vendor-type mapping data 540 for Veggie Palace to indicate that the restaurant sells salads.

[00119] As an example of the processing performed by the good-type classifier 535, the good type classifier 535 may receive a data item that includes data identifying Emily, Veggie Palace, ten dollars, June 4, 2015 at 12:00pm. Without considering a social media post by Emily with a picture of a salad and a caption describing a salad, the good type classifier 535 may access data related to Veggie Palace. The data related to Veggie Palace may include a menu and reviews by customers or editors. The good-type classifier 535 may analyze the menu and reviews to identify types of goods sold by Veggie Palace such as salads and sandwiches. This analysis may occur each time the good-type classifier 535 accesses the vendor-type mapping data 540 in response to receiving a data item, as the vendor-type mapping data 540 is updated, or periodically, such as when the good-type classifier 535 is not processing data items. Once the good-type classifier 535 determines that Veggie Palace sells salads and sandwiches with salads comprising most of the menu, the good-type classifier 535 may assign a good-type confidence score of 0.60 and the good-type salad to the data item that includes data identifying Emily, Veggie Palace, ten dollars, June 4, 2015 at 12:00pm. If the good-type classifier 535 takes into consideration the post of a picture of a salad, then the good-type confidence score may increase to 0.90.

[00120] The good-type classifier 535 may consider the popularity of particular items as described in reviews when calculating a good-type confidence score. The good- type classifier 535 may factor a higher likelihood that a customer purchases a popular good than an unpopular good. The good-type classifier 535 may identify the popular goods by analyzing the goods that are associated with higher praise in the reviews and less popular goods as the ones that are associated with more negative praise. Returning to the example with the data item that includes data identifying Emily, Veggie Palace, ten dollars, June 4, 2015 at 12:00pm, the good-type classifier 535 may analyze the reviews of Veggie Palace. Some of the reviews may be "The chef salad is great" and "Loved by chopped salad." There may be fewer positive review for the sandwiches. The good-type classifier 535 may factor in these reviews and calculate a good-type confidence score of 0.75 that the data item corresponds to a salad based on the reviews being more positive for the salad. The increase or decrease in the good-type confidence score may be proportional to the percentage of the reviews that discuss the good.

[00121] In some implementations, the good-type classifier 535 selects a good-type from a group of pre-determined good types. The pre-determined good types may be provided by an administrator or determined by the good-type classifier 535 after an initial processing of the vendor-type mapping data 540. For example, the good-type classifier 535 may analyze the vendor type mapping data 540 and determine that the type of goods are pizza, shoes, sandwiches, clothing, Chinese food, mobile devices, hardware, and makeup. [00122] The good-type classifier provides 535 the data items that include both order confidence scores and good-type confidence scores to the order database manager 540. The order database manager 540 analyzes the data items and stores data items, or data tuples, of a consistent structure in the inter-vendor good purchase history 550. These structured data items 555, or structured data tuples, may include a user identifier, a date, a good type, and a confidence score. For example, the order database manager 540 may receive a data item that includes data identifying Sally, Pizza Restaurant, pizza, ten dollars, June 4, 2015 at 7: 15pm with an order confidence score to 0.97 and a good-type confidence score of 0.95 to create a structured data item that includes data identifying Sally, June 4, 2015, pizza, and a confidence score. The confidence score may be a combination of the order confidence score and the good-type confidence score. In some implementations, the confidence score is an average of the order confidence score and the good-type confidence score.

[00123] The inter-vendor good purchase history 550 includes structured data items for each of the vendors. For example, the inter-vendor good purchase history 550 may include a structured data item 555 that includes data identifying Sally, June 4, 2015, pizza, and 0.96 and another structured data item 555 that includes data identifying Sally, June 14, 2015, pizza, and 0.78. Each of these structured data items 555 may correspond to a different vendor. Sally may have made the first purchase from Pizza Restaurant and the second purchase from Brothers Pizza.

[00124] The order database manager 540 accesses the inter-vendor good purchase history 550 and provides the structured data 555 to the order/marketing manager 560. The ordering/marketing manager 560 receives a request from an application running on a user device for instructions to generate or provide a user interface to the user for ordering goods. The ordering/marketing manager 560 may also providing marketing material to a user based on the previous behavior and predicted behavior of a user.

[00125] To determine the appropriate user interface or marketing material to provide to the user's device, the ordering/marketing manager 560 provides structured data or data tuples 555 to the pattern detector 565 to identify patterns in the inter-vendor good purchase history 550. The ordering/marketing manager 560 stores the patterns in the recognized patterns 570. The pattern detector 565 may identify patterns for each user identified in the inter-vendor good purchase history 550. For example, the pattern detector 565 may receive data items that identify Jack, June 5, pizza, 0.95; Jack, June 12, pizza, 0.95; and Jack, June 19, pizza, and 0.90. The pattern detector 565 may identify a pattern that Jack orders pizza each Friday. The ordering/marketing manager 560 may store that pattern in the recognized patterns 570.

[00126] The pattern detector 565 may consider the confidence scores when detecting patterns. The pattern detector 565 may weigh a data tuple with a higher confidence score more than a data tuple a lower confidence score. For example, the pattern detector 565 may receive data items that identify Jack, June 5, pizza, 0.95; Jack, June 12, pizza, 0.95; and Jack, June 19, pizza, and 0.90. Additionally the pattern detector 565 may receive data items that identify Jack, June 5, Chinese food, 0.40. Because the Chinese food data includes a lower confidence score, the pattern detector 565 weighs that data less and identifies the pattern that Jack orders pizza each Friday.

[00127] The pattern detector 565 may compare data tuples that include types of goods in the same group when identifying patterns. For example, the pattern detector 565 may identify patterns among data tuples that include types of foods or identify patterns among data tuples that include types of music. If the pattern detector 565 receives data items that include data identifying Jack, June 5, pizza, 0.95; Jack, June 12, pizza, 0.95; Jack, June 19, pizza, and 0.90; Jack, June 5, jazz, 0.85; and Jack, June 12, blues, 0.80, then the pattern detector may only compare the data items related to types of food, when identifying a pattern related to types of food. In this instance, the pattern detector 565 will identify the pattern that Jack orders pizza each Friday and likely will not identify a pattern among music orders.

[00128] The pattern detector 565 may compare data tuples to identify patterns that involve more than one type of good in a group of similar goods. As an example, the pattern detector 565 may identify a pattern such as Jack orders pizza and Chinese food in the same day or Jack orders pizza the day after ordering Chinese food. The pattern detector 565 may identify patterns that involve types of goods in different groups. As an example, the pattern detector 565 may identify a pattern such as Jack orders pizza and purchases jazz music the same day or Jack orders pizza and purchases jazz music the following day. [00129] The ordering/marketing manager 560 may periodically provide the structured data 555 to the pattern detector 565 or provide the structured data 555 when receiving a request for a user interface from a user device. For example, the ordering/marketing manager 560 may provide the structured data 555 to the pattern detector 565 each hour, day, week, or any similar interval. As another example, the ordering/marketing manager 560 may provide the structure data 555 to the pattern detector 565 when a user is accessing a vendor application.

[00130] The ordering/marketing manager 560 stores rules for generating and modifying user interfaces in the rules 575. The rules may include instructions for modifying user interfaces when a user is ordering goods from a vendor or when a user may be likely to order goods from a vendor. A user may be ordering goods from a vendor when the user accesses an application that is configured to order goods from the vendor such as a user accessing a pizza ordering application. The user may be likely to order goods from a vendor if the user is near a location of the vendor or if a pattern suggests that a user is more likely to order a particular type of good.

[00131] The ordering/marketing manager 560 may modify the rules in response to whether implementing a rule resulted in a purchase. As an example, a rule may state that Jack should receive a pizza coupon on Tuesday for purchase that day. This rule may be generated in response to the pattern detector 565 determining that Jack is likely to order pizza on Friday. To entice Jack to order pizza on other days of the week, the order/marketing manager 560 may provide a coupon to Jack for purchasing pizza on Tuesdays. If Jack does not purchase pizza on one or more Tuesdays, then the ordering/marketing manager 560 may adjust the coupon to be a discount for another day of the week, such as Mondays or a larger discount on Tuesdays.

[00132] As examples of rules that may be related to modifying user interfaces when a user is ordering goods, the ordering/marketing manager 560 may generate a rule discount goods that a user is less likely to purchase or place those goods more prominently in the user interface or both. Alternatively, the ordering/marketing manager 560 may generate a rule to increase the price of goods that a user is more likely to purchase or place those goods less prominently in the user interface or both. [00133] The ordering/marketing manager 560 provides the rules to the user interface generator 580. The user interface generator 560 may provide a portion of a user interface to a user device or may provide instructions that are specific to a type of device. For example, the user interface generator 560 may generate list of goods for sale, such as a menu, that a device may incorporate into a user interface where the user selects the goods to purchase.

[00134] FIG. 6 illustrates various user interfaces for ordering goods from a vendor. The user interfaces 600 are presented on a user device when a user executes a vendor's application that is used to purchase goods from a vendor. Portions of the user interfaces 600 or instructions to generate the user interfaces 600 may be provided by a user interface generator that receives rules from an ordering/marketing manager, such as the user interface generator 560 of FIG. 5.

[00135] User interface 610 illustrates an example default interface for ordering from Pizza Restaurant. The user interface generator generates user interface 610 in the absence of a particular rule for generating a user interface. The user interface 610 includes regular prices for products sold by Pizza Restaurant. The products include pizza, subs, and salads. A user may select the items from the user interface 610 to purchase the items.

[00136] User interface 620 illustrates an example user interface that the user interface generator generates in instances where a user may be more likely to purchase pizza. The corresponding rule may be to increase the price of pizza on Friday. In user interface 620, the price of the pizza has increased by one dollar and the price of the remaining items has remained the same. The rule may include an amount to increase the prices such as a specific amount or a percentage.

[00137] User interface 630 illustrates an example user interface that the user interface generator generates in instances where a user is more likely to purchase a particular type of good than other types of goods. In user interface 630, the price of the subs and salads has been reduced by fifty percent. The price of the subs and salads being reduced may be because the customer is more likely to purchase pizzas than subs and salads. The user interface 630 may be displayed on a Friday to a particular customer and the rule may be to reduce the price of items other than pizza on Friday to that particular customer. [00138] User interface 640 illustrates another example user interface that the user interface generator generates in instances where a user is more likely to purchase a particular type of good than other types of goods. In user interface 640, the price of the pizzas is increased and the subs and salads are listed at the top of the menu. The price increases and reconfiguration of the menu may be because the customer is more likely to purchase pizzas than subs and salads. The user interface 640 may be displayed on a Friday to a particular customer, and the rule may be to increase, on Friday, the price of pizza and place other items in more prominent positions on the user interface.

[00139] User interface 650 illustrates another example user interface that the user interface generator generates in instances where a user is more likely to purchase a particular type of good than other types of goods. In user interface 650, the price of the subs and salads has been reduced by fifty percent and the subs and salads are listed at the top of the menu. The price reductions and reconfiguration of the menu may be because the customer is more likely to purchase pizzas than subs and salads. The user interface 650 may be displayed on a Friday to a particular customer, and the rule may be to reduce, on Friday, the price of items other than pizza and place those items in more prominent positions on the user interface.

[00140] FIG. 7 is a flow chart of an example process 700 generating a confidence score that a user purchased a type of good on a particular date. In general, the process 700 analyzes data to identify purchases of goods by different users and score data corresponding to the user, the type of goods, and a date of purchase. The process 700 will be described as being performed by a computer system comprising one or more computers, for example, the system 500 as shown in FIG. 5.

[00141] The system receives, from one or more computers, order data, user data, and other data (710). The order data may be received from vendors and may include, for each order, a list of goods and a corresponding date. Instead of a list of goods or in addition to, the order data may include a purchase price. The user data may include data that is collected from a user's interactions with a computing device. If a user reads an email on a device and that email includes a receipt, then that email may be provided to the system as user data. If a user access an application to order goods, then that interaction and purchase may be provided to the system as user data. The user data may also include a location of the user when the interaction occurred or a time indicated on a receipt. The other data includes financial data, email data, and social media data. For example, the financial data may include a list of purchase amounts, vendors, and dates.

[00142] Based on the order data, the user data, and the other data, the system determines, for a particular user, an order confidence score that corresponds to a likelihood that the particular user ordered a particular good from a particular vendor on a particular day (720). To determine an order confidence score, the system identifies different purchases from among the received data. An emailed receipt for pizza from Pizza Restaurant and a charge that same day for Pizza Restaurant provides a high likelihood and thus a high order confidence score for a purchase of pizza from Pizza Restaurant on that day. A social media post of a hamburger that occurred near Burger Shop may provide a lower likelihood that a user purchased a hamburger and thus a lower order confidence score for a purchase of a hamburger from Burger Shop on that day.

[00143] The system receives vendor-type mapping data that correlates each vendor with a type of good sold by a respective vendor (730). In some implementations, the system receives the vendor-type mapping data from systems that store user ratings and review of vendors. In some implementations, the vendor-type mapping data may be extracted from vendor websites such as those that contain menus or other goods for sale.

[00144] Based on the vendor-type mapping data, the system determines a good- type confidence score that corresponds to the likelihood that the particular user ordered a particular type of good on the particular type of day (740). The good-type confidence score is related to a likelihood that a user purchased a particular type of good. In some implementations, the vendor is a restaurant, the good is food, and the type of good is a cuisine. The good-type confidence score may be higher if a vendor only sells one type of good, such as Sandwich Shop only selling sandwiches. The good-type confidence score may be lower if a vendor sells multiple types of goods, such as Jimmy's Restaurant selling Chinese food, Indian food, and tex-mex food.

[00145] Based on the good-type confidence score and the order confidence score, the system determines a composite confidence score that corresponds to a likelihood that the particular user ordered the particular type of good on the particular day (750). In some implementations, the composite confidence score is an arithmetic or geometric mean of the good-type confidence score and the order confidence score. For example, if the good-type confidence score is 0.80 and the order confidence score is 0.70, then the composite confidence score is 0.75.

[00146] The system stores the composite confidence score, data identifying the particular user, data identifying the particular type of good, and data identifying the particular date (760). In some implementations, the system stores this data in a fixed format. For example, each data item, or data tuple, may have a format of (composite confidence score, user identifier, type of good, date). In some implementations, the date also includes the time of day or a time range.

[00147] FIG. 8 is a flow chart of an example process 800 for generating a user interface to order goods. In general, the process 800 generated a user interface for ordering goods based on rules generated from previous purchases. The process 800 will be described as being performed by a computer system comprising one or more computers, for example, the system 500 as shown in FIG. 5.

[00148] The system receives, from an application running on a computing device, a request to order goods from a vendor, the request including data identifying a user of the computing device and the type of goods (810). The application running on the computing device may be a vendor specific application that is configured to sell goods from a particular vendor, or an application that is configured to sell goods from multiple vendors. The computing device may run a browser that loads a web page for one or more vendors to sell goods. The data identifying the user may be data tied to an identifier of the device such as a device address or may be data that identifies the user from logging into the application or the web page. To identify the type of goods, the system may retrieve vendor-type mapping data that corresponds to the vendor. In some implementations, the vendor is a restaurant, the goods are good, and the type of goods are cuisines. In some implementations, the request includes a location of the computing device.

[00149] The system identifies a particular rule, from a plurality of rules for generating a user interface of the application that corresponds to the user, the type of the goods, and a current date (820). The particular rule may include instructions for changing prices of particular goods or types of goods or modifying a layout of a default user interface. The particular rule may be specific to a user, a group of users, or users with a specific characteristic such as being at a particular location. In some implementations, a rule may specify to provide a user with marketing material based on a user activity, such as being near a specific location.

[00150] Based on the particular rule, the system generates an order-taking user interface (830). In some implementations, the order-taking user interface has a default configuration and default prices. The default order-taking user interface is provided to a user in the absence of a rule describing how to generate the order- taking user interface.

[00151] In some implementations, the system identifies a second rule that that corresponds to the user, the type of goods, and the current date. The system may generate the order-taking user interface according to both the first and second rule. In instances where the rules conflict, the system may not modify the order-taking interface or select one of the rules based upon whether following one of the rules resulted in the user purchasing more goods.

[00152] FIG. 9 is a flow chart of an example process 900 for generating rules to generate user interfaces for ordering goods. In general, the process 900 analyzes data tuples, or data items, to identify patterns and corresponding rules to generated order-taking user interfaces. The process 900 will be described as being performed by a computer system comprising one or more computers, for example, the system 500 as shown in FIG. 5.

[00153] The system receives data tuples that each include a confidence score, data identifying a user, data identifying a type of good, and data identifying a date, each confidence score corresponding to a likelihood that the user purchased a respective type of good on a respective date (910). In some implementations, the goods are food and the types of goods are cuisines. In some implementations, the system periodically receives the data tuples such as once per day or once per week. In some implementations, the system requests the data tuples in response to receiving a request for an order-taking user interface or marketing material. The system may request data tuples that correspond to a particular user. [00154] The system identifies patterns among the data tuples (920). To identify patterns in the data tuples, the system groups the data tuples into groups according to users. The system analyzes the data tuples in each group that include a confidence score that satisfies a threshold. The threshold may be dynamic depending on the number of data tuples in each group. The system may require data tuples with a higher confidence score when more data tuples correspond to a user. The threshold may also adjust based on a number of rules that correspond to a user. Fewer rules may trigger a reduced threshold. The patterns may be based on repeated purchase of a particular type of good. The repeated purchase may occur on a periodic basis or when a user is near a particular location. For example, a pattern may be that a user purchases pizza when within 0.1 miles of a pizza vendor.

[00155] Based on one or more of the patterns, the system generates a rule for generating an order-taking user interface of an application for ordering goods (930). Each rule may include instructions for adjusting prices listed for goods on the order- taking user interface or for modifying a default configuration of the order-taking user interface. The system generates the rule to increase purchases made by a user. In some implementations, the system generates rules to purchase different goods. For example, the system may generate a rule to discount salads for a user who purchases a lot of pizza. The system stores the rule (940).

[00156] In some implementations, package delivery routes are planned to minimize delivery times and fuel cost. However, the predetermined delivery destination is not always the most efficient location for a recipient to receive a package. For example, in some cases, a recipient is not present to receive the package when the delivery agent arrives at the destination. In some cases, the recipient may be closer to the delivery agent than to the delivery destination, and thus delivering the package to the predetermined destination may waste time and fuel. As another example, in some cases the recipient may be on his or her way to the delivery destination, but will not arrive in time to receive the package. In some of these cases, it may be more convenient and efficient for the recipient to meet the delivery agent and receive the package than to receive the package at the original delivery destination.

[00157] Accordingly, the present disclosure describes techniques determining and arranging an alternative delivery destination for a package that is already in the process of being delivered. One example technique notifies a package recipient that a package is nearing the delivery destination. The package recipient may be a user of a mobile device, and the notification may be made through an interface on the mobile device. The interface may provide the option of an alternative delivery destination to the user. If selected, an alternative delivery destination can be provided to the user as a location for the user to meet the delivery agent and receive the package. The alternative delivery destination may be provided to the delivery agent, and the delivery agent may also be provided with a wait time to wait at the alternative delivery destination for the user to arrive and receive the package.

[00158] FIG. 10A illustrates an example alternative delivery system 1000, FIGS. 10B-1 D illustrate example user interaction displays 1020, 1026, 1034 on a mobile device 1006, and FIG. 10E illustrates an example notification display 1042 for a delivery agent 1002. As shown in FIG. 10A, a delivery agent 1002 delivers packages to multiple delivery destinations 1012a-d along a predetermined delivery route 1008. The delivery agent 1002 may be, for example, a delivery truck, delivery carrier, or other agent. The delivery route 1008 includes several delivery stops 1010a-d, each respectively associated with delivery destinations 1012a-d. A delivery stop may be a location on a route associated with one or more delivery destinations. For example, a delivery destination may be a recipient's house, and the associated delivery stop may be a location on the street in front of the house where a delivery stuck may park to deliver the package to the house. Other example destinations, stops, and associations are possible.

[00159] User 1004 is a recipient of a package associated with delivery destination 1012c and delivery stop 1010c. The user 1004 uses mobile device 1006, which may be a smartphone, laptop, tablet computer, music player, wearable computer, or other type of computing device. The mobile device 1006 may provide to the user 1004 an interface including controls, notifications, interactive displays, a graphical user interface, images, or other displays of information. In some cases, the user 1004 may interact with the mobile device 1006 via a voice interface. The mobile device 1006 may run an application that enables interaction between the user 1004 and the delivery agent 1002. In particular, the interaction may provide an alternative delivery option, as described below. [00160] The alternative delivery system 1000 includes one or more associated proximity criteria. The proximity criteria may indicate a proximity relative to a location of the delivery agent 1002. The proximity criteria may include, for example, a proximity to the user 1004, a proximity to a delivery destination 1012a-d, and/or a proximity to a delivery route 1008. The proximity criteria may also include a designated geographic region such as a geofence, ZIP code, street, city, and/or other designation. The proximity criteria may also include an estimated travel time associated with the user 1004 and/or an estimated travel time associated with the delivery agent 1002. FIG. 10A shows an example proximity criterion 1014 as a physical distance from the delivery agent 1002, though in other implementations the proximity criterion may be based on other criteria, e.g., time criteria, or number of stops criteria.

[00161] If one or more proximity criteria are satisfied, an initial alternative delivery interface 1020 may be provided to the mobile device 1006 of the user 1004. For example, a distance-based proximity criterion may be satisfied if the delivery agent 1002 is within a predefined distance of the delivery destination 1012c associated with the user 1004. As another example, a time-based proximity criterion can be satisfied if the delivery for the delivery destination 1012c is estimated to occur within a predefined duration of time. In other cases, other proximity criteria may be satisfied differently.

[00162] FIG. 10B shows an example initial alternative delivery interface 1020 on a mobile device 1006. The initial interface 1020 is presented to the user 1004 if proximity criteria is satisfied. The initial interface 1020 may provide an "almost there" notification to the user 1004, indicating that the package associated with the user 1004 is nearing its delivery destination 1012c. In this manner, the absence of an "almost there" notification may indicate to the user 1004 that the package is not nearing the delivery destination 1012c. In addition to an "almost there" notification, the example interface 1020 may also present to the user 1004 the option of selecting an alternative delivery destination. The example initial alternative delivery interface 1020 provides example controls 1022, 1024 that the user 1004 may select. In this implementation, the user may select control 1022, "Yes, show me options," to indicate that the user 1004 wishes to be provided with alternative delivery options. Alternatively, the user 1004 may select control 1024, "No, deliver to destination," to indicate that the user 1004 wishes the package to be delivered to the package's original delivery destination 1012c.

[00163] Upon selecting the "Yes, show me options" control 1022, the user 1004 is presented with a second alternative delivery interface 1026, an example shown in FIG. 10C. The second interface 1026 presents a candidate alternative delivery destination to the user 1004. In other implementations, more than one candidate alternative delivery destination may be presented to the user 1004. The example second interface 1026 asks the user 1004 if the user 1004 wishes to meet the delivery agent 1002 at a candidate alternative delivery destination within a given period of time. The given period of time may be a time duration, a time of day, a time duration relative to a time of day, and/or another time specification.

[00164] The candidate alternative delivery destinations may be at least partially based on the location of the delivery agent 1002 and/or a location associated with the user 1004, described below in more detail. By way of the interface 1026, the user 1004 may arrange to meet the delivery agent 1002 at a particular candidate alternative delivery destination in order to receive the package at the location of that particular alternative delivery destination. In the example shown in FIG. 10C, the user 1004 is presented with an alternative delivery destination "2 Main St," corresponding to delivery destination 1012b and stop 1010b shown in FIG. 10A. The user 1004 is also provided a control 1028, "Yes, I'm on my way," to indicate that the user 1004 wishes to meet the delivery agent 1002 at the specified alternative delivery destination within the specified time period. The user 1004 is provided a control 1030, "No, deliver to destination," to indicate that the user 1004 does not wish to meet the delivery agent 1002 and instead wishes the package to be delivered to the original destination 1012c. The user 1004 may also be provided a control 1032, "other options," to indicate that the user 1004 wishes to be provided with other options. The other options may include other candidate alternative delivery destinations, other meeting times, or other features.

[00165] Turning to FIGS. 11A-B, FIGS. 1 1A-B show example interfaces 1 102, 1 108. The example interfaces 1 102, 1 108 may be included in or displayed in addition to interfaces 120, 126, 134. Example interface 1 102 in FIG. 11A displays multiple candidate alternative destinations 1 104a-c on a map 1 105. The alternative delivery destinations 1 104a-c may, for example, be stops on the delivery agent's route. The interface 1102 also includes the user's current location 11 14 on the map 1105. The interface 1102 also includes example controls 1 106a-c corresponding respectively to the candidate alternative destinations 1 104a-c. The controls 1106a-c also display, for each candidate alternative destination 1 104a-c, an approximate meeting time for the user to meet with the delivery agent at that destination. The user's location 1114 is closer to the candidate destinations 1 104a-b, and candidate destination 1104c is the farthest away from the user's location 1 1 14. The interface 1102 displays the farthest candidate destination 1 104c and corresponding control 1106c in a different color to indicate that it is the farthest from the user's location 1 114. In some cases, the interface 1102 may deactivate control 1 106c to disallow selection of the farthest candidate destination 1104c.

[00166] The example interface 1108 in FIG. 1 1 B displays multiple candidate alternative destinations 11 10a-c on a map 11 15. The interface 1108 also includes the user's current location 1 116 on the map 11 15. The interface 1 108 also includes example controls 11 12a-c corresponding respectively to the candidate alternative destinations 1 110a-c. The controls 11 12a-c also display, for each candidate alternative destination 11 10a-c, an estimated user travel time for the user to meet with the delivery agent at that destination. The estimated user travel time to the candidate destination 1 104a is greater than the estimated user travel time to the candidate destinations 1 104b-c. The interface 1 108 displays the candidate destination 1104a and corresponding control 11 12a in a different color to indicate that it is the farthest travel time from the user's location 1 114. In some cases, the interface 1108 may deactivate control 11 12a to disallow selection of the candidate destination 11 10a. For example, the candidate destination 11 10a may be disallowed because the user would not be able to reach that location 11 10a in time to meet a delivery agent for package receipt.

[00167] Turning back to FIGS. 10A-E, upon selecting the "Yes, I'm on my way" control 1028, the user 1004 is presented with a third alternative delivery interface 1034, an example shown in FIG. 10D. The third interface 1034 presents a notification that the delivery agent 1002 is expecting to meet the user 1004 at the alternative delivery destination within the given period of time. The third interface 1034 may also provide a countdown timer indicating a duration of time the delivery agent 1002 is expected to remain at the alternative delivery destination. The third interface 1034 may display other information, such as the location of the delivery agent 1002, the estimated time for the delivery agent 1002 to arrive at stop 1010b designated as the alternative delivery destination, or other information or controls. For example, the third interface 1034 may also include a control 1036 to indicate that the user 1004 wishes to cancel the alternative delivery and have the package delivered to the original destination 1012c. The user 1004 may also be provided a control 1038, "other options," to indicate that the user 1004 wishes to be provided with other options.

[00168] FIG. 10E shows an example delivery agent interface 1042 that can be provided to a computing device 1040 used by the delivery agent 1002. For example, the delivery agent interface 1040 may be provided on a mobile device, laptop, tablet computer, music player, wearable computer, or other computing system available to the delivery agent 1002. The delivery agent interface 1042 may be provided to the delivery agent 1002 upon the user 1004 selecting the "Yes, I'm on my way" control 1028. The example delivery agent interface 1042 shows a notification indicating that the user 1004 associated with stop 1010c has requested to meet at stop 1010b to pick up that user's package. The interface 1042 also shows a notification indicating that the delivery agent 1002 should wait at the stop 1010b for a duration of time for the user 1004 to pick up the package. The interface 1042 may include a countdown timer, other notifications, and/or other controls. For example, the interface 1042 may provide a control to increase or decrease the wait time, a control to propose a different meeting location to the user 1004, a control to propose a different meeting time to the user 1004, a control to notify the user 1004 that the delivery agent 1004 is early or late, a notification that the user 1004 has cancelled the alternative destination request, and/or other features.

[00169] Upon the user 1004 requesting an alternative delivery, the original stop 1010c may be removed from the delivery route 1008. The route 1008 may also be changed to account for the removal of stop 1010c, shown in FIG. 10A as route adjustment 1016. For example, the route 1008 may be planned to minimize distance traveled, minimize fuel consumption, minimize delivery times, or planned for other characteristics. In some cases, the route 1008 planning may include an optimization of one or more characteristics. [00170] Other implementations may use other interfaces, displays, and/or controls. In some implementations, the example first alternative delivery interface 1020 and other interfaces 1026, 1034 are provided via an application or program running on the mobile device 1006. In some implementations, the interfaces 1020, 1026, 1034 are provided via text messages, Short Message Service (SMS) messages, or other messaging services. In some cases, the user 1004 may receive alternative delivery notifications via such messages, and the user 1004 may indicate decisions by sending appropriate messages. In some cases, one or more interfaces may activate to a default control or default indication after a predetermined period of inactivity. As an illustrative example, if a user does not respond to an inquiry within a certain period of time, for example selecting a candidate alternative delivery destination, the alternate delivery request may be cancelled.

[00171] FIG. 12 is a block diagram of an example alternative delivery system 1200. The alternative delivery system 1200 may implement some or all of the alternative delivery system 100 shown in FIGS. 1A-E. The system 1200 includes a server 1204, a user mobile device 106, and a delivery agent 102. The server 1204, mobile device 106, and delivery agent 102 are configured to communicate over a network 1202. For example, the network 1202 can be a wireless network, a cellular network, or another type of network.

[00172] The example server 1204 includes a route database 1210 and a criteria database 1212. The route database 1210 may store information associated with delivery routes. For example, the route database 1210 may store current delivery routes, historical delivery routes, alternative delivery routes, the locations of historical delivery stops, locations of delivery agents, or other information associated with delivery routes. The criteria database 1212 may store information associated with proximity criteria, such as the example proximity criteria described previously or other proximity criteria. The criteria database 1212 may also store location information such as delivery agent locations, user locations, delivery stop locations, delivery destination locations, or other related information. For example, the criteria database 1212 may store information associated with a particular user such as historical alternative deliveries for that user, including successful and missed alternative deliveries, historically selected alternative delivery destinations, user preferences, or other information. In some implementations, the route database 1210 and the criteria database 1212 are part of each other. In some implementations, the route database 1210 and/or the criteria database 1212 are part of another database or system.

[00173] The server 1204 includes an alternative destination arranger 1206. The alternative destination arranger 1206 may determine alternative delivery destinations for a package. The alternative destination arranger 1206 may receive information from and transmit information to the user's mobile device 106 and the delivery agent 102. For example, the alternative destination arranger 1206 may receive an alternative delivery request from a user, determine one or more candidate alternative destinations, and transmit the candidate alternative destinations to the user. The alternative destination arranger 1206 may also receive a selection of a particular alternative destination from a user. The alternative destination arranger 1206 may communicate with the route database 1210 and/or the criteria database 1212.

[00174] The example alternative destination arranger 1206 includes a route planner 1214 and an alternative destination planner 1216. In some implementations, the alternative destination planner 1216 and the route planner 1214 are the same component. In some implementations, the alternative destination planner 1216 and/or the route planner 1214 are part of another component. The alternative destination planner 1206 may also include other components. The alternative destination planner 1206 and its components may be models, modules, algorithms, or other systems.

[00175] The alternative destination planner 1216 may determine one or more candidate alternative destinations. One or more of the candidate alternative destinations may be selected by a user. The candidate alternative destinations may be determined based on factors such as the location of the delivery agent, the location of the user, the location of the original delivery destination, the delivery route, locations of one or more delivery stops, traffic conditions, the current delivery schedule, delivery agent wait times, a number of unsuccessful historical meetings, or other factors. The alternative destination planner 1216 may determine an alternative delivery destination for a package that minimizes a total wait time for all recipients on that route. The alternative destination planner 1216 may determine an alternative delivery destination for a package based on historical alternative delivery data, for example historical data of the user's most selected alternative delivery destinations from previous deliveries.

[00176] The alternative destination planner 1216 may determine an alternative delivery destination for a package that coincides with a delivery stop on the route associated with the delivery of that package. The alternative destination planner 1216 may, for example, determine an alternative delivery destination that would minimize a distance or a travel time for the user and/or the delivery agent. For example, at the time the user indicates a wish for an alternative delivery destination, the user may be closer to a particular delivery destination on the route than all other delivery destinations on the route. In this case, the alternative destination planner 1216 may determine the particular delivery destination to be a candidate alternative delivery destination. In some cases, the alternative destination planner 1216 may determine an earlier delivery destination to be a candidate alternative delivery destination, and in some cases, the alternative destination planner 1216 may determine a subsequent delivery destination to be a candidate alternative delivery destination. The earlier delivery destination may be, for example, a delivery destination that is reached by the delivery agent before the original delivery destination, and the subsequent delivery destination may be, for example, a delivery destination that is reached by the delivery agent after the original delivery destination. In some cases, it may be more convenient or take less overall time for a user to receive the package at an earlier or subsequent candidate delivery destination.

[00177] In some cases, the alternative destination planner 1216 may determine a candidate alternative delivery destination that is not a predetermined delivery destination or a predetermined delivery stop. For example, the alternative destination planner 1216 may determine a candidate alternative delivery destination that is between two predetermined stops on a delivery route. As another example, the candidate destination may be determined at a location that is not part of the delivery route. The alternative destination planner 1216 may, for example, determine a candidate alternative delivery destination that minimizes potential or actual changes to the predetermined route.

[00178] The route planner 1214 may determine a planned delivery route. The planned delivery route may be an updated delivery route or an optimized delivery route. For example, a particular delivery stop may be removed from a preexisting route, and the route planner 1214 may determine a new alternative route excluding that particular delivery stop. The route planner 1214 may, for example, alter the preexisting route to coincide with one or more alternative delivery destinations. The route planner 1214 may determine a planned delivery route by minimizing alterations to the preexisting delivery route. The route planner 1214 may, for example, determine a planned delivery route by minimizing a distance or a travel time of the delivery route. The route planner 1214 may base the determination of delivery route on traffic conditions, delivery stop locations, alternative delivery locations, delivery agent wait times, or other factors.

[00179] FIG. 13 is a flow chart illustrating an example process 1300 for providing an alternative delivery destination. The example process 1300 may be implemented, for example, by some or all of alternative delivery system 100 or alternative delivery system 1 100.

[00180] At 1302, the location of a delivery agent is determined. The location of a delivery agent may be determined, for example, by one or more of a Global

Positioning System (GPS), a service set identifier (SSID) of a nearby detected wireless network, a detected phone mast signal, a wireless media access control (MAC) address, or other system. At 1304, the location of the delivery agent is determined to satisfy one or more proximity criteria. The proximity criteria can include some or all of the proximity criteria described previously, or other proximity criteria.

[00181] At 1306, an alternative delivery interface is provided to a mobile device of a user. The user may be associated with a particular delivery destination on the delivery route of the delivery agent. The alternative delivery user interface may include a control for initiating an alternative delivery destination option. At 1308, an indication is received that a control has been selected for initiating the alternative delivery destination option. For example, the indication may indicate that the user has selected the alternative delivery destination option on the alternative delivery interface provided to the mobile device.

[00182] At 1310, one or more candidate alternative delivery destinations are determined. The candidate alternative delivery destinations may be based on the location of the delivery agent and a location associated with the user. For example, a candidate alternative delivery destination may be based on the location of the delivery agent as determined in 1302, a current location of the delivery agent, a predicted location of the delivery agent, or another location associated with the delivery agent. The location associated with the user can be a determined location of the user, a predicted location associated with the user, a location of a delivery stop associated with the user, a delivery destination associated with the user, or another location associated with the user.

[00183] At 1312, an additional alternative delivery user interface is provided to the device of the user. The additional alternative delivery user interface may include one or more controls for selecting one or more of the corresponding alternative delivery destinations. The alternative delivery destinations may be the candidate alternative delivery destinations determined at 1310. At 1314, an indication is received that a particular control has been selected corresponding to a particular alternative delivery destination. For example, the indication can indicate that the user has selected a particular alternative delivery destination on the alternative delivery interface provided to the mobile device.

[00184] At 1316, the indication of the selected particular alternative destination is transmitted to the delivery agent. The indication can include, for example, some or all of the location of the selected particular alternative destination, a location of the user, a meeting time, a wait time, a delivery route change, or other information.

[00185] FIG. 14 depicts an example system 1400 for providing repeat order notifications and for processing repeat orders. As described in further detail below, the system 1400 may include a location determinator 1402, smart appliances 1410, a mobile application 1412, a web application 1414, a text or short message service (SMS) application 1416, a voice interface 1418, an ordering backend 1420, call center workstations 1422, local fulfillment center workstations 1430, and a supply chain, finance, or enterprise component 1440. The system 1400 may provide for real time order and delivery of an item. Real time delivery may include point-to-point delivery of small, tangible, purchased goods within a very short period of time of purchase, e.g., few minutes to a few hours. Purchased goods may include typical packaged goods that do not otherwise require real-time delivery, e.g., consumer electronics or office supplies, goods that degrade over a long period of time, e.g., groceries or flowers, or goods that degrade within a very short period of time, e.g., dry ice, ice cream, hot pizza or a cup of coffee.

[00186] The location determinator 1402 may determine location information for a customer. For example, the location determinator 1402 may determine a customer's location based on one or more of a service set identifier (SSID) of a nearby detected wireless network, a detected phone mast signal, determined global positioning system (GPS) information, an assigned Internet Protocol (IP) address, a landline location, or a wireless media access control (MAC) address. The location determinator 1402 may provide the location information to the smart appliances 1410, the mobile application 1412, the web application 1414, the text or short message service (SMS) application 1416, and the voice interface 1418.

[00187] The smart appliances 1410, the mobile application 1412, the web application 1414, the text or short message service (SMS) application 1416, and the voice interface 1418 may enable a customer to place an order. For example, one or more of the smart appliances 1410, the mobile application 1412, the web application 1414, the text or short message service (SMS) application 1416, and the voice interface 1418 may enable a customer to place an order for a cheese pizza to be delivered to the customer's home address at 7:00 PM. To enable customers to place orders, the smart appliances 1410, the mobile application 1412, the web application 1414, the text or short message service (SMS) application 1416, and the voice interface 1418 may provide interfaces through which the customer may confirm or specify a particular item to order, and a particular location for which the customer would like to obtain the item. For example, the smart appliances 1410, the mobile application 1412, the web application 1414, the text or short message service (SMS) application 1416, and the voice interface 1418 may visually or audibly provide notifications or prompts to the customer inviting the customer to order an item or requesting that the customer specify a particular item to order, a particular location to receive the item, and a particular time to receive the item.

[00188] More specifically, the smart appliances 1410 may be appliances that may be used to place orders. For example, the smart appliances 1410 may include a television that may be used by a customer to place an order for a pizza. The smart appliances 1410 may provide an interface for a customer to place an order. For example, the smart appliance 1410 may include a display that may render an interface for the customer to order a pizza. The smart appliances 1410 may provide orders to an ordering backend 1420. For example, the smart appliances 1410 may provide an order for a pizza through a network to the ordering backend 1420.

[00189] The mobile application 1412 may be an application running on a mobile device that provides a notification inviting a customer to place an order, and enables a customer to accept the invitation and place the order. For example, an application running on a customer's smart phone may invite a customer to place an order for a pizza, and may also enable the customer to place an order for pizza. A mobile device may include a smart phone, a tablet computer, or some other type of computing device that may be portably used. The mobile application 1412 may provide an interface for a customer to accept or place an order. For example, the mobile application 1412 may display on the mobile device an interface for the customer to order a pizza. The mobile application 1412 may provide orders to an ordering backend 1420. For example, the mobile application 1412 may provide an order for a pizza through a network to the ordering backend 1420.

[00190] The web application 1414 may be an application accessible through a web browser running on a computing device, where the application enables a customer to place an order. For example, a Java application may be rendered by a web browser on a desktop computer and enable a customer to place an order for pizza. A computing device may include a mobile device, a desktop computer, a laptop computer, or some other type of device that computes. The web application 1414 may provide an interface for a customer to place an order. For example, the web application 1414 may display an interface, in a web browser on a desktop computer, for the customer to order a pizza. The web application 1414 may provide orders to an ordering backend 1420. For example, the web application 1414 may provide an order for a pizza through a network to the ordering backend 1420.

[00191] The text or SMS application 1416 may be an application running on a mobile device that enables a customer to place an order by text or SMS. For example, an application running on a customer's smart phone may enable the customer to send a text or SMS message to the ordering backend 1420 to place an order for pizza. In some implementations, the application may provide a graphical user interface for the user to select a particular item, particular location, and a particular time to receive the item, and generate a SMS message indicating the selections and provide the SMS message to the ordering backend 1420.

[00192] The voice interface 1418 may be an interface that enables a customer to place an order by voice. For example, the voice interface 1418 may be a telephone that a customer may use to verbally order a pizza. The voice interface 1418 may communicate with the call center workstations 1422. For example, the voice interface 1418 may transmit audio captured by the voice interface 1418 to the call center workstations 1422, and similarly, output audio from the call center workstations 1422. The voice interface 1418 may additionally or alternatively communicate with a local voice-based order taking component 1432 of a local fulfillment center workstation 1430. For example, the voice interface 1418 may transmit audio captured by the voice interface 1418 to the local voice-based order taking component 1432, and similarly, output received audio from the local voice- based order taking component 1432.

[00193] The call center workstations 1422 may receive voice input from the voice interface 1418, generate orders based on the voice input, and provide the orders to the ordering backend 1420. For example, the call center workstations 1422 may audibly output voice input from the interface 1418 to allow customer service representatives to verbally interact with customers, and generate orders for the customers. In some implementations, the call center workstations 1422 may be automated and use speech recognition to generate orders for users. For example, the call center workstations 1422 may execute an Artificial Intelligence customer service agent program that may verbally speak to the customer to take the order and place the order directly for the customer.

[00194] The ordering backend 1420 may be a component that processes orders from customers. For example, the ordering backend may receive orders from the smart appliances 1410, mobile application 1412, web application 1414, text or SMS application 1416, the voice interface 1418, or the call center workstations 1422. The ordering backend 1420 may process orders based on determining, for each order, one or more local fulfillment center workstations 1430 to receive the order. For example, the ordering backend 1420 may determine that a first order for a pizza should be provided to a first local fulfillment center workstation and a second order for a pizza should be provided to a different, second local fulfillment center workstation.

[00195] The ordering backend 1420 may determine a local fulfillment center workstation to receive a particular order based on a location which the customer would like to obtain the item ordered. For example, the ordering backend 1420 may determine that a first order indicates the order is to be obtained at a location where the distance from the location to the local fulfillment center is within a distance threshold, and in response, determine to provide the first order to a workstation of the local fulfillment center. In another example, the ordering backend 1420 may determine that a second order is to be obtained at a location where the distance from the location to the local fulfillment center exceeds a distance threshold, and in response, determine the second order should be provided to a workstation of another local fulfillment center.

[00196] Additionally or alternatively, the ordering backend 1420 may determine a local fulfillment center workstation to receive a particular order based on availability of the local fulfillment center to fulfill the order. For example, the ordering backend 1420 may determine that a first order for a pizza can be fulfilled by a local fulfillment center as the local fulfillment center may still have capacity to provide the pizza. In another example, the ordering backend 1420 may determine that a second order for a pizza cannot be fulfilled by a local fulfillment center as the local fulfillment center may not have capacity to provide the pizza.

[00197] In response to determining the local fulfillment center workstations 1430 to receive an order, the ordering backend 1420 may provide the order to the local fulfillment center workstations 1430. For example, in response to determining that a local fulfillment center does deliver to the particular location requested by a customer and has capacity to fulfill an order for pizza, the ordering backend 1420 may determine to provide the order for pizza to the local fulfillment center workstations 1430 of the local fulfillment center.

[00198] In processing the orders, the ordering backend may also process payments for the orders. For example, the ordering backend 1420 may validate whether payment information provided in the order is correct. In another example, the ordering backend 1420 may place charges for orders using payment information provided in the order.

[00199] The ordering backend 1420 may include a bulk order processor 1424. The bulk order processor 1424 may enable the ordering backend 1420 to perform mass processing of orders. For example, the ordering backend 1420 may receive an extremely large number of orders within a given time frame from the smart appliances 1410, mobile application 1412, web application 1414, text or SMS application 1416, the voice interface 1418, or the call center workstations 1422. Processing such an amount of orders may include determining, for each order, one or more local fulfillment center workstations out of thousands of potential local fulfillment center workstations 1430 to receive the order.

[00200] The ordering backend 1420 may also include a bulk order router 1426. The bulk order router 1426 may enable the ordering backend 1420 to perform mass management of logistics, including delivery scheduling and collection scheduling of received orders. For example, the ordering backend may receive an extremely large number of orders within a given time frame from the smart appliances 1410, mobile application 1412, web application 1414, text or SMS application 1416, the voice interface 1418, or the call center workstations 1422. Managing the delivery scheduling or collection scheduling of such an amount of orders may include determining an order preparation schedule for each local fulfillment center workstation.

[00201] The ordering backend 1420 performs a variety of tasks relating to processing or routing bulk orders, including sorting, assigning, routing, queuing, distributing and scheduling, to name a few. The study, optimization and execution of these tasks requires the uses of techniques and results from well-developed, active areas of scientific research, such as operational research, combinatorial

optimization, graph theory (in particular network theory), queuing theory, and transport theory. Executing or providing optimal solutions to such tasks are proven to be complex and mathematically hard, particularly when considering large-scale systems. For example, e-commerce giant Amazon reported that they received, processed and delivered orders for 1426 items per second in the run up to Christmas in 2013, see for example http://articles.latimes.com/2013/dec/26/business/la-fi-tn- amazon-sold-426-items-per-second-cyber-mondav-20131226. [00202] Since scaling is an extremely important factor, particularly in the context of e-commerce, tasks relating to processing or routing bulk orders quickly become extremely difficult, if not impossible, to solve and require powerful computers implementing complex algorithms and elegant mathematical

programming techniques, as well as robust hardware architectures that can be parallelized. In some cases, it has even been shown that many tasks relating to the processing or routing of bulk orders are computationally intractable. In fact, the theory of computational complexity has introduced a concept of NP-hardness to classify such computationally intractable tasks.

[00203] For example, consider the intensely studied Traveling Salesman Problem (TSP), an NP-hard problem in combinatorial optimization. In its purest formulation, the TSP may be described as follows: given a list of cities and the distances between each pair of cities, what is the shortest route that visits each city exactly once, and returns to the original city. The TSP may also be modeled and described as a graph problem, wherein the cities are the graph's vertices and the distances between each pair of cities are the lengths of the graph's edges, or formulated as an integer linear program. The TSP has several applications in operational research, including planning and logistics, wherein the concept of a city may represent customers or orders, and the concept of a distance may represent travelling times or incurred costs. In some implementations, additional constraints may be imposed on the TSP, such as limiting an amount of resources or limiting to certain time windows. Finding increasingly efficient solutions to the TSP and other such complex, subtle operational research problems is an active area of scientific research, as evidenced by a plethora of technical textbooks, journals and scientific articles. See, for example "In Pursuit of the Travelling Salesman: Mathematics at the Limits of Computation," William Cook, Princeton University Press, 2011, "Dynamic programming strategies and reduction techniques for the traveling salesman problem with time windows and precedence constraints," L. Bianco, A. Mingozzi, and S. Ricciardelli, Operations Research, 145 (1997) 365-377 and "Scheduling vehicles from a central depot to a number of delivery points," G. Clarke and J. Wright, Operations Research 12 (1964) 568-581.

[00204] Another well-studied, fundamental combinatorial optimization problem in the field of operational research and optimization is the Assignment Problem (AP). In its most general form, the AP may be described as follows: given a number of agents, a number of tasks and a set of incurring costs for each potential agent-task assignment, perform all tasks by assigning one agent to each task, and one task to each agent, such that the total costs incurred is minimized. The AP also has several applications in areas such as planning and logistics. For example, the ordering backend 1420 may interpret the task of processing received orders as an

assignment problem, wherein a local fulfillment center workstation can be assigned to deliver an order, incurring some cost. The bulk order processor 1424, for example, may require that all orders are delivered by assigning one local fulfillment center to each order, and one order to each local fulfillment center, in such a way that the total cost of the assignment is minimized. It has been shown that such an assignment problem can be expressed mathematically as a standard linear program, see, for example "Algorithms for the Assignment and Transportation Problems," James Munkres, Journal of the Society for Industrial and Applied Mathematics Vol. 5, No. 1 (Mar, 1957), pp. 32-38.

[00205] Linear programming has been shown to be an extremely powerful, essential optimization technique widely applied in various fields of study such as business studies and economics, as well as industrial areas such as engineering, transportation and manufacturing. The sophisticated mathematical programming techniques used in linear programming have proven essential to the modeling of diverse types of problems in routing, scheduling and assignment, and in turn have led to the creation of powerful computer systems that enable businesses to reduce costs, improve profitability, use resources effectively, reduce risks and provide untold benefits in many other key dimensions. Mathematically, linear programming is a technique for the optimization of a linear objective function, subject to linear equality and linear inequality constraints. While this requirement may seem overly restrictive, many real-world business problems can be formulated in this manner. Today, commercial linear-programming codes are able to solve linear programs with millions of constraints. For example, the commercial, high-performance mathematical programming solver IBM ILOG CPLEX of IBM is able to solve linear programs with the number of megabytes required for computation approximately equal to the number of constraints divided by 1000, see http://www- 01.ibm.com/support/docview.wss?uid=swg21399933. [00206] When dealing with large-scale systems, system components, such as the ordering backend 120, may employ techniques and results from Queuing Theory - the mathematical study of waiting lines, or queues - in order to model incoming customers or orders and subsequently make business decisions relating to order fulfillment, resource requirements for providing a certain service, expected waiting time in a queue, average time in a queue, expected queue length, expected number of customers in a queue at a given time, and the probability of a system to be in a certain state, such as empty or full. For example, it has been shown that most queues in restaurant operations can be described by an M/M/1 queue, where arrivals are determined by a Poisson process with heavy periods around lunch and dinner time, and service times have an exponential distribution. In a complex system of multiple M/M/1 queues, or a queue network, deep and sophisticated mathematical techniques such as stochastic calculus may be employed to model or approximate the queuing process. For example, in some implementations a heavy traffic approximation may be used to approximate a queuing process by a reflected Brownian motion, Ornstein-Uhlenbeck process or more general diffusion process. Since queues are basic components to both external and internal business processes, including scheduling and inventory management, understanding the nature of queues and learning how to manage them is one of the most important areas in operational research and management. See, for example, "A Methodology and Implementation for Analytic Modeling in Electronic Commerce Applications," H. Edwards, M. Bauer, H. Lutfiyya, Y. Chan, M. Shields and P. Woo, Electronic

Commerce Technologies, Lecture notes in computer science, Volume 2040, 2001, pp 148-157 and "Stochastic Models in Queuing Theory", J. Medhi, Elsevier

Academic Press, 2002.

[00207] The local fulfillment center workstations 1430 may receive orders from the ordering backend 1420. For example, a particular local fulfillment center workstation may receive an order for pizza from the ordering backend 1420. The local fulfillment center workstations may be located on the premises of the local fulfillment center and used by agents of the local fulfillment center. For example, a local fulfillment center workstation of a pizza provider may be located in a kitchen of the pizza provider and used by bakers to determine what pizzas to bake and when to bake the pizzas. In another example, local fulfillment center workstations of a pizza provider may be located in delivery vehicles of the pizza provider and used by pizza deliverers to determine where to deliver each pizza or a delivery route for the pizzas. The delivery route may be dynamically planned based on types of orders and locations to which the orders will be delivered. In yet another example, a local fulfillment center workstation may be used by a cashier of a pizza provider and used by the cashier to place additional orders for customers within the restaurant or determine whether a customer is the correct customer to receive a pizza that is ordered for pickup at the restaurant.

[00208] The local fulfillment center workstations 1430 may provide information to agents of the local fulfillment center to fulfill orders. For example, a particular local fulfillment center workstation of a pizza provider may display an order number, a type of pizza ordered, a customer name for the order, a place of delivery for the order, and a time of delivery for the order. The local fulfillment center workstations 1430 may obtain the information to provide agents of the local fulfillment center from the orders received from the ordering backend 1420. For example, the orders received from the ordering backend 1420 may include data that indicates an order number, a type of pizza ordered, a customer name for the order, a place of delivery for the order, and a time of delivery for the order. In some implementations, the local fulfillment center workstations 1430 may prioritize the fulfillment of orders. For example, the local fulfillment center workstations 1430 may prioritize the fulfillment of orders based on when the orders are to be provided to the users.

[00209] The local fulfillment center workstations 1430 may include a local, voice-based order taking component 1432. For example, the local fulfillment center workstations 1430 may include a telephone-based system with which an employee of the local fulfillment center may speak to the customer. The local, voice-based order taking component 1432 may enable customers to place orders directly with the local fulfillment center. For example, the same local fulfillment center workstations 1430 that receive orders from the ordering backend 1420 may also be used to generate orders based on input from customer service agents using the local fulfillment center workstations 1430. In some implementations, the local, voice- based order taking component 1432 may be automated and use speech recognition to generate orders for users. [00210] The local fulfillment center workstations 1430 may additionally or alternatively communicate with a supply chain or finance or enterprise component of a third party. For example, a local fulfillment center workstation may place an order for more flour with a supply chain component of a third party that sells flour for pizza. In another example, a local fulfillment center workstation may communicate with a finance component to place payment charges for orders.

[00211] FIG. 15 shows an example of a computing device 1500 and a mobile computing device 1550 that can be used to implement the techniques described here. For example, the system 1500 and the mobile computing device 1550 can be used for the operations described in association with the process 300, process 700, process 800, process 900, and/or process 1300 according to some implementations. The computing device 1500 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The mobile computing device 1550 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smart-phones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to be limiting.

[00212] The computing device 1500 includes a processor 1502, a memory 1504, a storage device 1506, a high-speed interface 1508 connecting to the memory 1504 and multiple high-speed expansion ports 1510, and a low-speed interface 1512 connecting to a low-speed expansion port 1514 and the storage device 1506. Each of the processor 1502, the memory 1504, the storage device 1506, the high-speed interface 1508, the high-speed expansion ports 1510, and the low-speed interface 1512, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 1502 can process instructions for execution within the computing device 1500, including instructions stored in the memory 1504 or on the storage device 1506 to display graphical information for a GUI on an external input/output device, such as a display 1516 coupled to the high-speed interface 1508. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

[00213] The memory 1504 stores information within the computing device 1500. In some implementations, the memory 1504 is a volatile memory unit or units. In some implementations, the memory 1504 is a non-volatile memory unit or units. The memory 1504 may also be another form of computer-readable medium, such as a magnetic or optical disk.

[00214] The storage device 1506 is capable of providing mass storage for the computing device 1500. In some implementations, the storage device 1506 may be or contain a computer-readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. Instructions can be stored in an information carrier. The instructions, when executed by one or more processing devices (for example, processor 1502), perform one or more methods, such as those described above. The instructions can also be stored by one or more storage devices such as computer- or machine-readable mediums (for example, the memory 1504, the storage device 1506, or memory on the processor 1502).

[00215] The high-speed interface 1508 manages bandwidth-intensive operations for the computing device 1500, while the low-speed interface 1512 manages lower bandwidth-intensive operations. Such allocation of functions is an example only. In some implementations, the high-speed interface 1508 is coupled to the memory 1504, the display 1516 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 1510, which may accept various expansion cards (not shown). In the implementation, the low-speed interface 1512 is coupled to the storage device 1506 and the low-speed expansion port 1514. The low-speed expansion port 1514, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

[00216] The computing device 1500 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 1520, or multiple times in a group of such servers. In addition, it may be implemented in a personal computer such as a laptop computer 1522. It may also be implemented as part of a rack server system 1524. Alternatively, components from the computing device 1500 may be combined with other components in a mobile device (not shown), such as a mobile computing device 1550. Each of such devices may contain one or more of the computing device 1500 and the mobile computing device 1550, and an entire system may be made up of multiple computing devices communicating with each other.

[00217] The mobile computing device 1550 includes a processor 1552, a memory 1564, an input/output device such as a display 1554, a communication interface 1566, and a transceiver 1568, among other components. The mobile computing device 1550 may also be provided with a storage device, such as a micro-drive or other device, to provide additional storage. Each of the processor 1552, the memory 1564, the display 1554, the communication interface 1566, and the transceiver 1568, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.

[00218] The processor 1552 can execute instructions within the mobile computing device 1550, including instructions stored in the memory 1564. The processor 1552 may be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor 1552 may provide, for example, for coordination of the other components of the mobile computing device 1550, such as control of user interfaces, applications run by the mobile computing device 1550, and wireless communication by the mobile computing device 1550.

[00219] The processor 1552 may communicate with a user through a control interface 1558 and a display interface 1556 coupled to the display 1554. The display 1554 may be, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface 1556 may comprise appropriate circuitry for driving the display 1554 to present graphical and other information to a user. The control interface 1558 may receive commands from a user and convert them for submission to the processor 1552. In addition, an external interface 1562 may provide communication with the processor 1552, so as to enable near area communication of the mobile computing device 1550 with other devices. The external interface 1562 may provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces may also be used.

[00220] The memory 1564 stores information within the mobile computing device 1550. The memory 1564 can be implemented as one or more of a computer- readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. An expansion memory 1574 may also be provided and connected to the mobile computing device 1550 through an expansion interface 1572, which may include, for example, a SIMM (Single In Line Memory Module) card interface. The expansion memory 1574 may provide extra storage space for the mobile computing device 1550, or may also store applications or other information for the mobile computing device 1550. Specifically, the expansion memory 1574 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, the expansion memory 1574 may be provide as a security module for the mobile computing device 1550, and may be programmed with instructions that permit secure use of the mobile computing device 1550. In addition, secure applications may be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

[00221] The memory may include, for example, flash memory and/or NVRAM memory (non-volatile random access memory), as discussed below. In some implementations, instructions are stored in an information carrier that the

instructions, when executed by one or more processing devices (for example, processor 1552), perform one or more methods, such as those described above. The instructions can also be stored by one or more storage devices, such as one or more computer- or machine-readable mediums (for example, the memory 1564, the expansion memory 1574, or memory on the processor 1552). In some

implementations, the instructions can be received in a propagated signal, for example, over the transceiver 1568 or the external interface 1562.

[00222] The mobile computing device 1550 may communicate wirelessly through the communication interface 1566, which may include digital signal processing circuitry where necessary. The communication interface 1566 may provide for communications under various modes or protocols, such as GSM voice calls (Global System for Mobile communications), SMS (Short Message Service), EMS (Enhanced Messaging Service), or MMS messaging (Multimedia Messaging Service), CDMA (code division multiple access), TDMA (time division multiple access), PDC (Personal Digital Cellular), WCDMA (Wdeband Code Division Multiple Access), CDMA2000, or GPRS (General Packet Radio Service), among others. Such communication may occur, for example, through the transceiver 1568 using a radio-frequency. In addition, short-range communication may occur, such as using a Bluetooth, WFi, or other such transceiver (not shown). In addition, a GPS (Global Positioning System) receiver module 1570 may provide additional navigation- and location-related wireless data to the mobile computing device 1550, which may be used as appropriate by applications running on the mobile computing device 1550.

[00223] The mobile computing device 1550 may also communicate audibly using an audio codec 1560, which may receive spoken information from a user and convert it to usable digital information. The audio codec 1560 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of the mobile computing device 1550. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on the mobile computing device 1550.

[00224] The mobile computing device 1550 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 1580. It may also be implemented as part of a smart-phone 1582, personal digital assistant, or other similar mobile device.

[00225] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. For example, various forms of the flows shown above may be used, with steps re-ordered, added, or removed. Accordingly, other implementations are within the scope of the following claims.

[00226] For instances in which the systems and/or methods discussed here may collect personal information about users, or may make use of personal information, the users may be provided with an opportunity to control whether programs or features collect personal information, e.g., information about a user's social network, social actions or activities, profession, preferences, or current location, or to control whether and/or how the system and/or methods can perform operations more relevant to the user. In addition, certain data may be anonymized in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be anonymized so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained, such as to a city, ZIP code, or state level, so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about him or her and used.

[00227] Embodiments and all of the functional operations described in this specification may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this

specification and their structural equivalents, or in combinations of one or more of them. Embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus may include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus.

[00228] A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and it may be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[00229] The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[00230] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both.

[00231] The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data.

Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer may be embedded in another device, e.g., a tablet computer, a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[00232] To provide for interaction with a user, embodiments may be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input.

[00233] Embodiments may be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation, or any combination of one or more such back end, middleware, or front end components. The components of the system may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network ("LAN") and a wide area network ("WAN"), e.g., the Internet.

[00234] The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[00235] While this specification contains many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this specification in the context of separate

embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single

embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[00236] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[00237] In each instance where an HTML file is mentioned, other file types or formats may be substituted. For instance, an HTML file may be replaced by an XML, JSON, plain text, or other types of files. Moreover, where a table or hash table is mentioned, other data structures (such as spreadsheets, relational databases, or structured files) may be used.

[00238] Thus, particular embodiments have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims may be performed in a different order and still achieve desirable results.

Claims

1. A computer-implemented method comprising:

receiving a particular set of user data, the particular set of user data including user data obtained from a user device;

obtaining a predictive model that estimates a likelihood of a user to order a food item, wherein the predictive model is generated using observation data that includes historic user data and user data from other user devices;

providing the particular set of user data to the predictive model;

obtaining, from the predictive model, an indication of a likelihood of the user to order a food item;

based on the indication of a likelihood of the user to order a food item obtained from the predictive model, determining whether to output a notification on the user device inviting the user to order a food item; and

in response to determining whether to output a notification on the user device inviting the user to order a food item, selectively outputting a notification on the user device inviting the user to order a food item.

2. The method of claim 1 , wherein the predictive model comprises a first sub- predictive model and a second sub-predictive model, wherein the first sub-predictive model is configured to receive a data input and generate a respective output, and the generated respective output is provided as input to the second sub-predictive model.

3. The method of claim 2, wherein the first sub-predictive model is generated using observation data that includes a user's purchase history, browser history, search query history, calendar history and location history.

4. The method of claim 3, wherein the first sub-predictive model estimates an inclination of the user to cook.

5. The method of claim 3, wherein the first sub-predictive model estimates an inclination of the user to dine out.

6. The method of claim 3, wherein the first sub-predictive model estimates a likelihood of that the user has already ordered food within a recent time interval.

7. The method of claim 3, wherein the first sub-predictive model estimates a likelihood of that the user has already ordered a food item.

8. The method of claim 2, wherein the first sub-predictive model estimates a likelihood that the user has performed an activity that is associated with ordering food.

9. The method of claim 2, wherein the first sub-predictive model estimates a likelihood that the user has performed an activity that is associated with not ordering food.

10. The method of claim 2, wherein the second sub-predictive model comprises a final predictive model component and the second sub-predictive model receives one or more outputs from the first sub-predictive model.

11. The method of claim 10, wherein the second sub-predictive model estimates a likelihood of a user to order a food item, wherein the predictive model is generated using observation data that includes historic user data.

12. The method of claim 1 , wherein the particular set of user data includes location information, time and date information, calendar entries information, weather information and mode of transport information.

13. The method of claim 1 , wherein the predictive model comprises a decision tree.

14. The method of claim 1 , wherein the indication of how likely a user of the user device wants to order a food item includes a confidence score.

15 The method of claim 14, wherein determining whether to output a notification on the user device inviting the user to order a food item comprises: generating a confidence score threshold;

determining whether the confidence score exceeds or meets the confidence score threshold.

16 The method of claim 1 , wherein selectively outputting a notification on the user device inviting the user to order a food item comprises:

generating one or more food item recommendations;

selecting a food item recommendation from the one or more food item recommendations;

generating a notification inviting the user to order the food item;

providing the generated notification inviting the user to order the food item for display on the user device.

17. The method of claim 1 , further comprising:

receiving an acceptance of the invitation to order a food item;

processing the order for the food item.

18. A system comprising:

one or more computers; and

a computer-readable medium coupled to the one or more computers having instructions stored thereon which, when executed by the one or more computers, cause the one or more computers to perform operations comprising:

providing the particular set of user data to the predictive model;

based on the indication of a likelihood of the user to order a food item obtained from the predictive model, determining whether to output a notification on the user device inviting the user to order a food item;

19. A computer storage medium encoded with a computer program, the program comprising instructions that when executed by data processing apparatus cause the data processing apparatus to perform operations comprising:

providing the particular set of user data to the predictive model;

20. A computer-implemented method comprising:

receiving, from one or more computers, order data, user data, and other data; based on the order data, the user data, and the other data, determining, for a particular user, an order confidence score that corresponds to a likelihood that the particular user ordered a particular good from a particular vendor on a particular day; receiving vendor-type mapping data that correlates each vendor with a type of good sold by a respective vendor;

based on the vendor-type mapping data, determining a good-type confidence score that corresponds to the likelihood that the particular good or the particular vendor is associated with a particular type of good;

based on the good-type confidence score and the order confidence score, determining a composite confidence score that corresponds to a likelihood that the particular user ordered the particular type of good on the particular day; and storing the composite confidence score, data identifying the particular user, data identifying the particular type of good, and data identifying the particular date.

21. The method of claim 20, wherein the order data includes data associated with goods orders and dates that the goods were ordered.

22. The method of claim 20, wherein the user data includes data associated with location and application usage.

23. The method of claim 20, wherein the other data includes data associated with financial data, email data, and social media data.

24. The method of claim 20, wherein the vendor-type mapping data is received from one or more computers that store user ratings and reviews of vendors.

25. The method of claim 20, wherein:

the vendors are restaurants,

the goods are food, and

the types of goods are cuisines.

26 . The method of claim 20, wherein the composite confidence score is an average of the good-type confidence score and the order confidence score.

27. A system comprising:

one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising:

receiving, from an application running on a computing device, a request to order goods from a vendor, the request including data identifying a user of the computing device and the type of goods;

identifying a particular rule, from a plurality of rules for generating a user interface of the application, that corresponds to the user, the type of the goods, and a current date; and

based on the particular rule, generating an order-taking user interface.

28. The system of claim 27, wherein the order-taking user interface identifies goods in a default configuration and at default prices.

29. The system of claim 28, wherein generating the order-taking user interface comprises adjusting a default price for one or more of the goods listed in the order- taking user interface.

30. The system of claim 28, wherein generating the order-taking user interface comprises modifying the default configuration.

31. The system of claim 27, wherein:

the vendors are restaurants,

the goods are food, and

the types of goods are cuisines.

32. The system of claim 27, wherein generating the order-taking user interface is further based on a location of the user.

33. The system of claim 27, wherein the operations further comprise:

identifying a second rule, from the plurality of rules, that corresponds to the user, the type of the goods, and a current date,

wherein generating the order-taking user interface is based further on the second rule.

34. A non-transitory computer-readable medium storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform operations comprising:

receiving data tuples that each include a confidence score, data identifying a user, data identifying a type of good, and data identifying a date, each confidence score corresponding to a likelihood that the user purchased a respective type of good on a respective date;

identifying patterns among the data tuples; based on one or more of the patterns, generating a rule for generating an order-taking user interface of an application for ordering goods; and

storing the rule.

35. The medium of claim 34, wherein the rule includes instructions for adjusting a default price for one or more of the goods listed in the order-taking user interface.

36. The medium of claim 34, wherein the rule includes instructions for modifying a default configuration of the order-taking user interface.

37. The medium of claim 34, wherein identifying patterns among the plurality of data tuples comprises:

identifying a first group of the data tuples that identify a same type of good; identifying a second group of the data tuples that include a confidence score that satisfies a threshold, the first group of the data tuples including the second group of the data tuples; and

identifying a pattern of the respective dates in the second group of the data tuples.

38. The medium of claim 34, wherein the one or more of the patterns identifies repeated purchase of a particular type of good.

39. The medium of claim 34, wherein:

the goods are food, and

the types of goods are cuisines.

40. The medium of claim 34, wherein generating a rule for generating an order- taking user interface of an application for ordering goods comprises:

generating a rule for increasing purchases initiated through the order-taking user interface.

41. A computer-implemented method comprising:

determining a location of a delivery agent that is associated with a delivery route having one or more delivery destinations;

determining that the location has satisfied one or more proximity criteria;

in response to determining that the location has satisfied the one or more proximity criteria, providing an initial alternative delivery user interface to a device of a user that is associated with a particular delivery destination on the route, wherein the alternative delivery user interface includes a control for initiating an alternative delivery destination option;

receiving an indication that the control for initiating the alternative delivery destination option has been selected;

determining one or more candidate alternative delivery destinations based at least on the location of the delivery agent and a location associated with the user;

providing an additional alternative delivery user interface to the device of the user, wherein the additional alternative delivery user interface includes one or more controls for selecting one or more corresponding alternative delivery destinations;

receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected; and

in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, transmitting, to the delivery agent, an indication of the selected, particular alternative delivery destination.

42. The method of claim 41 , the proximity criteria comprises one or more of a proximity to the user, a proximity to a delivery destination, a proximity to a delivery route, a location within a designated geographic region, an estimated travel time associated with the user, and an estimated travel time associated with the delivery agent.

43. The method of claim 41 , further comprising in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining an updated delivery route.

44. The method of claim 43, further comprising transmitting, to the delivery agent, the updated delivery route.

45. The method of claim 43, wherein determining an updated delivery route comprises excluding the particular delivery destination from the delivery route.

46. The method of claim 41 , further comprising in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining a delivery agent wait time associated with the particular alternative delivery destination.

47. A system comprising:

determining that the location has satisfied one or more proximity criteria;

48. The system of claim 47, the proximity criteria comprises one or more of a proximity to the user, a proximity to a delivery destination, a proximity to a delivery route, a location within a designated geographic region, an estimated travel time associated with the user, and an estimated travel time associated with the delivery agent.

49. The system of claim 47, further comprising in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining an updated delivery route.

50. The system of claim 49, further comprising transmitting, to the delivery agent, the updated delivery route.

51. The system of claim 49, wherein determining an updated delivery route comprises excluding the particular delivery destination from the delivery route.

52. The system of claim 47, further comprising in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining a delivery agent wait time associated with the particular alternative delivery destination.

53. A computer-readable medium storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform operations comprising:

determining that the location has satisfied one or more proximity criteria;

providing an additional alternative delivery user interface to the device of the user, wherein the additional alternative delivery user interface includes one or more controls for selecting one or more corresponding alternative delivery destinations; receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected; and

54. The medium of claim 52, the proximity criteria comprises one or more of a proximity to the user, a proximity to a delivery destination, a proximity to a delivery route, a location within a designated geographic region, an estimated travel time associated with the user, and an estimated travel time associated with the delivery agent.

55. The medium of claim 52, further comprising in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining an updated delivery route.

56. The medium of claim 55, further comprising transmitting, to the delivery agent, the updated delivery route.

57. The medium of claim 55, wherein determining an updated delivery route comprises excluding the particular delivery destination from the delivery route.

58. The medium of claim 52, further comprising in response to receiving an indication that a particular control corresponding to a particular alternative delivery destination has been selected, determining a delivery agent wait time associated with the particular alternative delivery destination.