JP7630221B2 - Computer system for implementing a network delivery service - Google Patents

Description

Related Applications

This application claims the benefit of priority from (1) U.S. Patent Application No. 15/802,385, filed November 2, 2017, (2) U.S. Patent Application No. 15/802,391, filed November 2, 2017, and (3) U.S. Patent Application No. 15/802,394, filed November 2, 2017, all of which are incorporated herein by reference in their entirety. This application is also a divisional application of Japanese Patent Application No. 2020-524524, filed October 31, 2018.

The examples described herein relate to computer systems that perform network delivery services.

Many on-demand services exist and offer users a variety of services, i.e., transportation, shipping, food delivery, groceries, pet sitting, assembled special teams, etc. On-demand services typically leverage resources available through mobile devices, such as wireless (e.g., cellular) devices. These mobile devices provide developers with a platform to access sensors and other resources available through the mobile devices. Many on-demand services include a dedicated application (sometimes called an "app") that communicates with the network services through which the on-demand service is provided.

In some examples, the network computing system performs actions to arrange transportation services for delivery orders.

In some examples, the network computing system estimates supply levels for a particular time interval for one or more regions. The supply level calculations may be based on an estimated number of order requests and a number of available service providers in the particular region that can provide transportation to fulfill the order requests. For each request in the particular region, the computer system selects a set of multiple suppliers for a supplier menu that is displayed on the requester's mobile device. The selection of suppliers for each requester may be based at least in part on the requester's current location and at least one of the estimated number of order requests or the estimated number of available service providers.

In a variation, the network computing system (1) predicts order preparation times of each supplier for the order request, and (2) arranges transportation for the delivery order by generating requests to service providers during a time interval prior to the order preparation time based at least in part on determining that the arrival times of matched service providers at each supplier are within a specified threshold from the order preparation time. The order delivery time to the requester may be estimated based at least in part on the predicted order preparation time and an estimated travel time from the supplier's location to the requester's location.

As used herein, a customer device refers to a device that corresponds to a desktop computer, a cellular device or a smartphone, a wearable device, a laptop computer, a tablet device, a television (IP television), or the like that can provide network connectivity and processing resources to communicate over a network with the system. A driver device may correspond to specialized hardware, an in-vehicle device, or an on-board computer, or the like. The customer device and/or the driver device may also run a specified application configured to communicate with the system 100.

Although some of the examples described herein relate to transportation services, the system 100 can enable other on-demand location-based services (e.g., food truck services, delivery services, entertainment services) to be arranged between an individual and a service provider. For example, a user can use the system to request an on-demand service such as a delivery service (e.g., food delivery, messenger service, food truck service, or product shipping) or an entertainment service (e.g., a mariachi band, a string quartet), and the system can select a service provider, e.g., a driver, a food provider, an orchestra, etc., and provide the on-demand service to the user.

One or more embodiments described herein provide that the methods, techniques, and operations performed by a computing device are performed in the form of a program or as a computer-implemented method. In the form of a program, as used herein, means by the use of code or a number of computer-executable instructions. These instructions may be stored in one or more memory resources of a computing device. The steps performed in the form of a program may or may not be automated.

One or more embodiments described herein may be implemented using a program module, engine, or component. A program module, engine, or component may include a program, a subroutine, a portion of a program, or a software or hardware component that can perform one or more of the described tasks or functions. As used herein, a module or component may exist independently of other modules or components on a hardware component. Alternatively, a module or component may be a shared element or process of other modules, programs, or machines.

Some embodiments described herein may typically require the use of a computing device, including processing and memory resources. For example, one or more embodiments described herein may be implemented in whole or in part on a computing device, such as a server, a desktop computer, a mobile phone or smartphone, a tablet, a wearable electronic device, a laptop computer, a printer, a digital picture frame, a network appliance (e.g., a router), and a tablet device. All memory, processing, and network resources may be used in connection with establishing, using, or implementing any of the embodiments described herein (including implementing any of the methods or implementing any of the systems).

Additionally, one or more of the embodiments described herein may be implemented using instructions executable by one or more processors. These instructions may be stored on a computer-readable medium. The machines illustrated or depicted below provide examples of processing resources and computer-readable media on which instructions for implementing embodiments of the invention may be stored and/or executed. In particular, many of the machines illustrated in the embodiments of the invention include a processor and various forms of memory for holding data and instructions. Examples of computer-readable media include fixed memory holding devices, such as hard drives of personal computers or servers. Other examples of computer storage media include portable storage units, such as CD or DVD units, flash memory (e.g., on smartphones, multifunction devices, or tablets), and magnetic memory. Computers, terminals, and network-enabled devices (e.g., portable devices such as mobile phones) are all examples of machines and devices that utilize processors, memories, and instructions stored on computer-readable media. Additionally, the embodiments may be implemented in the form of a computer program or a computer-usable storage medium capable of storing such a program.

1 illustrates an example network computing system for arranging transportation of a delivery order in accordance with one or more embodiments. 1 illustrates an example method for identifying a supplier for delivery services to an individual requester. 1 illustrates an example method for arranging transportation for multiple delivery orders. 1 illustrates an example method for arranging transportation of delivery orders in a manner that affects the supply level of the services provided. 1 illustrates another example method for arranging transportation of a delivery order to minimize service provider wait time. 1 illustrates an exemplary computer system upon which one or more embodiments may be implemented. FIG. 2 is a block diagram illustrating an example user device for use in the described embodiments.

1 illustrates an example of a network computing system for arranging transportation of a delivery order according to one or more embodiments. According to an embodiment, the network computing system 100 provides a network delivery service that may be utilized by requesters, suppliers, and service providers. The network computing system 100 may be implemented on a server, a combination of servers, and/or a distributed set of computing devices that communicate over a network, such as the Internet. Some embodiments also provide that the network computing system 100 is distributed using one or more servers and/or mobile devices. In some variations, the network computing system 100 is implemented as part of or in connection with a network system in which, for example, operators use service vehicles to provide point-to-point transportation related services. In variations, the network computing system 100 may be implemented using mobile devices of users, including service providers and requesters, each of which executes a corresponding service application that causes the computing device to act as an information inlet and/or outlet for the network computing system 100.

In some examples, system 100 implements a network platform in conjunction with applications running on mobile devices of users in a geographic area. For a particular geographic area, users may include (1) service vehicle operators (or "service providers"), (2) requesters who request and receive delivery orders transported by the service providers, and (3) suppliers who provide requested delivery orders for transportation. Although some examples describe suppliers (e.g., restaurants) in the context of food preparation, system 100 may be implemented to arrange for delivery of other types of deliverable items, such as groceries or service items. More generally, system 100 may be implemented to arrange for delivery of any type of item, including items that may require preparation.

Referring to the example of FIG. 1, the system 100 includes a requester device interface 110, a provider device interface 120, a request handling unit 128, a supplier interface 130, a matching unit 140, and one or more data stores for updating information about requesters, order requests, and providers. The system 100 may also include a supply subsystem 150 that enables the system 100 to adjust supply levels of the system 100.

As described in some examples, the supply subsystem 150 allows the supply levels of the system 100 to be estimated or otherwise confirmed with respect to actual or expected demand from requesters for a particular time period and with respect to a particular region (e.g., a city or part of a city). The supply subsystem 150 may also be utilized to adjust the supply levels with respect to how the system 100 provides network services to arrange for transportation of delivery orders. In particular, the supply subsystem 150 may make adjustments to the confirmed supply levels of the network services in a manner optimized for the purposes of the provided network services. In this manner, various aspects of the provided network services may be adjusted in response to fluctuations in the volume of demand from requesters, for example to maximize the number of order requests that can be effectively handled in a particular length of time. The optimizations that may be performed via the network services may also be performed at a group level to objectively accommodate the interests of service providers, suppliers, and requesters.

The requester device interface 110 includes or executes processes that operate on the network side of the system 100 to establish communication channels with individual devices of the requesters. The requesters may operate mobile devices (represented by mobile devices 104 in FIG. 1 ) on which corresponding service applications 106 may operate. The requesters may operate their respective service applications 106 to request delivery services and, in some variations, other types of transportation-related services, such as transportation of people between a starting point (or pick-up point) and a destination (or drop-off point). When a service application 106 is launched on the requester device 102, the requester device 102 may transmit requester information 103 to the system 100. The requester information 103 may include an account identifier 105 and a current location 107 of the requester device, which the service application 106 may obtain by connecting with a satellite receiver or other location-aware resource of the requester device 102. As will be described in more detail, the requester information 103 may also be communicated along with the order request 101. In some variations, at least some of the requester information 103 (e.g., current location) may be communicated before the order request 101 is made at the requester device 102.

According to some examples, the provider device 104 initiates communication with the system 100 using a service application 116. The service application 116 may correspond to a program (e.g., a set of instructions or code) downloaded and stored on the service provider's mobile device 104. The service provider may activate the service application 116 to receive order requests and/or other types of service requests (e.g., transportation requests) using the system 100. The service provider may operate a service vehicle to fulfill the assigned service requests. Once a communication channel is established by the provider device 104 using the service application 116, the provider device 104 may repeatedly or continuously communicate service information 109 to the network computing system 100. The service information 109 may include a provider identifier 111 and the provider's current location 113, which the service application may determine by connecting with a satellite receiver of the provider device 104.

The provider device interface 120 includes or executes processes that operate on the network side of the system 100 to establish communication channels with individual devices of the service providers. For example, the device interface 110 can establish secure sockets with different types of mobile devices that the service providers of the system 100 can use to provide services using their respective vehicles. In some examples, the service providers operate mobile devices (represented in FIG. 1 as mobile devices 104) on which corresponding service applications 116 may be running. Among other functions, the service applications 116 can automate operations including indicating the availability of the service providers to provide services, communicate location information that allows the system 100 to monitor the location of the service provider's vehicles, and receive information from the system 100 to enable the service providers to receive and fulfill order requests, in addition to communicating information to the system 100 including supply decisions for various purposes.

The system 100 may include an active provider data store 134 that maintains records 135 associating individual providers with their respective current location 113 and service status 133. As an example, each service provider may start a work shift by running a service application 116 (e.g., opening the application on the provider's device 104) and then switching a status feature provided by the service application 116 to "on duty". The service application 116 communicates the activation of the status feature to the system 100 via the provider device interface 120. The provider device interface 120 processes the service information 109 received from the individual service providers. For each service provider, the provider device interface 120 extracts the current location 113 of the provider device 104 and stores it together with the provider's identifier 115 in the provider status store 134. When the location of the service provider changes (e.g., with the movement of the service provider's vehicle), subsequent communication from the provider device 104 via the provider device interface 120 can be used to update the provider status store 134. In this way, the provider data storage unit 134 may reflect the latest current location of each service provider.

In some examples, the requester device interface 110 and the provider device interface 120 may each include or use an application programming interface (API), such as an external-facing API, to communicate data with the provider device 102 and the requester device 104, respectively. By providing an external-facing API, the system 100 may establish a secure communication channel over a network through a secure access channel in any number of ways, such as a web-based form, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), Remote Procedure Call (RPC), scripted access, etc.

The supplier interface 130 may correspond to a program interface that transmits an order request from a requester to a supplier terminal. In a food delivery situation, the supplier interface 130 transmits a delivery order to the supplier's computer system (e.g., a pre-order system, a point-of-sale device, a dedicated take-out terminal, etc.). In some examples, the supplier may operate a mobile device with a supplier service application to receive order requests from the system 100. The supplier may access the system 100, for example, via a website or application interface (e.g., a supplier service application), to accept order requests and provide information regarding the readiness of order requests. The supplier may also access the system 100 to provide a menu or description (including text and images) of deliverable items.

The system 100 may maintain a supplier library 126 that includes a record 125 for each supplier. Each supplier record 125 may associate a supplier with a supplier location 129 and an account identifier 127 as well as a set of deliverable items 131 offered by that supplier. The supplier may specify the items 131 via a supplier interface 130. The supplier items 131 may be provided as electronic documents or a combination of records provided by the supplier that are retrievable and may be presented on the requester device 102, for example in the form of a menu. By way of example, the supplier items 131 may include a restaurant menu or items for a restaurant menu.

According to some examples, when the requester launches the service application 106, the requester device 102 provides the system 100 with the requester's current location 107. In some variations, the requester can specify a service point for the delivery order that is different from the requester's current location 107. The requester device interface 110 communicates the requester's current location 107 (or the requester-specified service point) to the menu section 112, which may use the requester's current location to retrieve item information 117 from the supplier library 126 that represents a selection of the supplier's deliverable items 131. The requester device interface 110 may communicate the menu contents 119 to the requester device 102 via the service application 106. As described in some examples below, the menu contents 119 may also convey one or more service value parameters 171 that indicate a fee or consideration that the requester will incur to receive delivery of the requested item from the supplier. The user may browse the menu contents 119 to see a list of suppliers and see what items each available supplier has available for delivery. Upon making a selection for a delivery order, the service application 106 causes the requester device 102 to send an order request 101 to the system 100.

In some examples, the requester status store 132 records instances when the service application 106 is launched on the requester device 102. In such cases, the requester status store 132 may associate the record with the requester on the requester device 102 (e.g., based on account information provided by the requester device), and the record may indicate the requester's status as active. When an order request 101 is received from the requester device 102, the requester's record may be updated and associated with the order request 101.

The order request 101 may be received by the requester device interface 110 and recorded in the requester status store 132. In some examples, the requester device interface 110 and the menu section 112 may implement geographic constraints for individual requesters based on a service range parameter 169. The service range parameter 169 may specify the distance (e.g., travel distance) from the service point of the desired order request within which available suppliers may be made available to that requester for purposes of the order request. For example, the service range parameter 169 may be set to 2 miles (3.2 km) or 12 minutes of travel time, and the menu section 112 may implement a filter to exclude suppliers that are outside the distance specified in the range parameter 169. In this way, the service application 106 running on the requester device 102 is not provided with menu content 119 that indicates deliverable items from suppliers that are outside the range parameter 169.

Additionally or alternatively, the range parameter 169 may be used to establish tiers among suppliers for a particular order request 101 service point. The menu section 112 may execute tier logic 118 to set alternative order request rules for suppliers based at least in part on tier designations assigned to individual suppliers, for example. The tier logic 118 may assign tier designations based in part on the location of the supplier relative to the order request service point. Upon execution, the tier logic 118 may specify different minimum order sizes or values for a supplier's order request based in part on the supplier's tier designation. Additionally or alternatively, the tier logic 118 may use one or more service value parameters 171 to determine different service values for deliveries from different suppliers based on the supplier's tier designation for the service point.

According to some examples, the request handler 128 acts on the incoming order request 101 and updates the status of the order request 101 as the order request is processed. Initially, the request handler 128 may send a communication 139 to the supplier of the order request 101, where the communication 139 identifies the item(s) of the requester's order request 101. The communication 139 may be communicated to the selected supplier via the supplier interface 130. In some embodiments, the supplier may acknowledge or confirm receipt of the communication 139. For example, the supplier may provide input via a supplier services application by messaging or other platform that acknowledges receipt of the communication 139.

The request handler 128 may also initiate the matching component 140 to initiate the matching process to select a service provider for the order request 101. In some examples, the request handler 128 may determine when to initiate the matching component 140 based on an expected time when a delivery order corresponding to the order request 101 will be prepared. Determining when to initiate the matching component 140 may include, for example, the request handler 128 estimating an order preparation time. In particular, the request handler 128 may determine (e.g., delay) when to initiate the matching component 140 based on a comparison of the preparation time to the estimated length of time. This estimated length of time includes an estimated time interval during which the service provider will be matched with the delivery request and an estimated time interval during which the service provider will travel to the supplier to pick up the corresponding delivery order. As an example, the matching component 140 may be activated because the service provider's estimated arrival time at the supplier (e.g., the time to match the corresponding order request 101 with the service provider and the time for the service provider to travel to the supplier) is within a time threshold window from the estimated order preparation time for the supplier and/or the item in the order request 101.

Calculation of delivery order preparation times may be based on, for example, information related to suppliers. For example, the supplier storage unit 126 may associate preparation time values with suppliers and/or items that individual suppliers can fulfill delivery requests 101. As described in some examples, order preparation times may be calculated from a model that monitors order requests from individual suppliers over a particular period of time.

In some examples, the request handler 128 may determine from the estimated order time of the item and/or supplier that the preparation time is likely to be shorter than the estimated amount of time for the matched service provider to arrive at the supplier when matching the corresponding order request with the service provider. In such examples, the request handler 128 may delay sending a communication 139 (for the corresponding order request 101) to the supplier specified by the order request 101 until after the service provider has been matched to the order request 101. In such examples, the delay in sending the communication 139 for the order request 101 may be such that the estimated order preparation time falls within the estimated time window for the matched service provider to arrive at the supplier.

The matching unit 140 may match the order request 101 with available service providers based at least in part on the current location of the individual providers relative to the location of the provider. In some variations, the matching unit 140 may also match the order request 101 based on the desired arrival time of the provider at the provider's location. Thus, for example, the proximity of the service provider may not necessarily be a decisive selection criterion for the selection of a particular service provider.

In some examples, the request handler 128 may select and execute the bundling decision logic 138 to implement rules and parameters that determine when delivery orders may be bundled. Bundling refers to when a service provider handles two delivery orders. The bundling decision logic 138 may bundle according to one or more sets of rules and/or parameters. The decision may be made programmatically from these rules and parameters. The bundling decision logic 138 may vary such that different rules, parameters, and/or parameter values may be utilized to determine when bundling may occur. In particular, the bundling decision logic 138 may implement alternative rules that determine (1) whether bundling is possible under any circumstances, and (2) if bundling is possible, the conditions under which multiple delivery orders may be bundled. By way of example, conditions that may determine or influence a bundling decision may include (1) a same supplier condition, where bundling of delivery orders is permitted if the delivery orders are prepared by the same supplier; (2) a timing condition, where a time window may be established for when multiple order requests are prepared and/or delivered relative to one another before bundling is permitted; (3) a supplier location condition, where bundling of delivery orders is permitted if the delivery orders are prepared by suppliers that meet geographic conditions for the location and/or delivery point of each supplier; and/or (4) a supply condition, where the supply level calculation 155 determines or influences the bundling decision.

With regard to supply conditions, some examples provide that bundling may be maximized with respect to what is permitted, for example, if an inadequate number of service providers exist to handle order requests. Conversely, if there are too many service providers, bundling may be minimized since separate service providers may be used to deliver orders that could otherwise be bundled.

Regarding timing conditions, some examples provide that the batching decision logic 138 utilizes timing parameters 167 determined by the supply subsystem 150 to determine when to allow delivery orders to be batched. For example, the request handler 128 may utilize one or more timing parameters 167 to minimize waiting time while a service provider is at the supplier. For example, in a food preparation situation, if the service provider's arrival time is longer than the time it takes for the food to be prepared, the prepared food will be cold or less desirable. At the same time, if the service provider's arrival time is before the food is ready, the service provider will wait and therefore be underutilized. The request handler 128 may include logic to initiate the matching process during a time window before the expected preparation time of the requested delivery order, such that the assigned service provider will arrive at the supplier at the time the requested delivery order is prepared and available for pickup. FIG. 5 illustrates an example method that may be performed, for example, by the request handler 128, to control the selection of a service provider based at least in part on a determination of an optimal arrival time.

In a variation, the bundling decision logic 138 may allow delivery orders to be bundled if they are from the same supplier and can be delivered by a particular service provider to multiple recipients at different locations within a predefined time limit. The predefined time limit may be set, for example, to an order preparation time (or order pick-up time) and/or an order delivery time. For example, one or more timing parameters 167 may set a limit on when the last bundled order can be picked up and/or delivered relative to the delivery order preparation time and/or order request time (e.g., when the order request 101 is made). Additionally or alternatively, the timing parameters 167 may set a comparable time window between the respective pick-up or delivery times of the bundled delivery orders. In a variation, other timing parameters 167 may control when delivery orders from a particular supplier can be bundled.

With respect to the supplier location condition, the bundling decision logic 138 may implement alternative rules that allow a service provider to handle delivery orders from different suppliers, for example, provided that additional criteria are met. As an alternative to the same supplier condition, the bundling decision logic 138 may allow delivery orders from different suppliers to be bundled, for example, if the different suppliers meet a proximity condition with respect to their respective locations (e.g., the suppliers are in the same building, next to each other, on the same block, within walking distance, etc.). As another example, the bundling decision logic 138 may allow delivery orders from different suppliers to be bundled, for example, if the different suppliers meet a route condition, for example, the different suppliers are aligned for delivery purposes along a route.

Once the matching unit 140 has selected a provider for the order request 101, the request handler 128 can monitor the provider via updates to the provider location (e.g., maintained in the provider status store 134). In particular, the request handler 128 can track the provider to the supplier and from the supplier to the service point of the order request 101. The status of the requester's order request is repeatedly updated by the request handler 128 in the requester status store 132 and may indicate events such as (1) the order request 101 being communicated to the supplier, (2) the supplier acknowledging receipt of the order request, (3) one or more progress indications of the order request being prepared, including when the corresponding delivery order is ready, (4) the service provider picking up the corresponding delivery order, (5) the service provider's progress to the service point specified in the order request, and/or (6) the service provider's arrival at the requester's service point (e.g., the requester's current location or a specified point).

Also, in some examples, predictive information that may be useful to the requester may be determined and communicated to the requester device 102. For example, an estimated delivery time may be initially predicted before the requester places the order request 101. When the order request 101 is processed by the supplier, the delivery time may be updated for the requester. Similarly, the delivery time may be updated as the matching unit 140 identifies a service provider and while the request handling unit 128 tracks the service provider from pickup to the point of delivery of the order.

Similarly, the matching unit 140 (and/or the request handler 128) may change the associated status of the service provider to indicate, for example, one or more unavailable states. For example, the status of the service provider may include available, assigned to the order request, en route to supplier, at the supplier, en route to requester, and completing the order request.

As soon as it is detected that the service provider has completed the delivery service, the request handler 128 may launch the account manager 136. The account manager 136 may record the fulfillment of the order request with respect to the service provider, the supplier, and the requester's accounts. In some instances, a fee or consideration is debited from the requester's account for the delivery obtained. Similarly, the account manager 136 may credit the supplier's account for providing the delivery order. The service provider's account may also be credited based at least in part on the associated service value parameters 171 of the fulfilled order request 101.

According to some examples, the supply subsystem 150 includes a supply level calculation ("PLD") component 152, a forecasting component 154, and a supply level adjustment ("PLA") component 156. The PLD component 152 can estimate a supply level for a particular region during a current time interval or for a future time interval based on forecast information from the forecasting component 154. The supply level 155 can reflect a calculation of the adequacy of the number of service providers to the number of service requests to be handled in a particular time interval. The forecasting component 154 may generate a forecast for one or more aspects of the supply level calculation. For example, the forecasting component 154 can forecast the number of service requests that the system 100 will receive over the next time interval or during a future time interval. The forecasting component 154 may also forecast or otherwise estimate the number of service providers that are (or will be) available to fulfill order requests 101 in a particular region. The PLA section 156 can execute logic to adjust the supply level 155 of the system 100 to optimize for one or more service goals of the system 100.

The supply subsystem 150 may utilize a variety of models 153, including predictive models 153A and/or optimization models 153B. By way of example, the predictive models 153A may include tree-based models, deep learning models, neural network models, and/or regression models. By way of example, the predictive models 153A may be generated and trained to predict supply level estimates (e.g., number of order requests, conversion rates of requesters operating the service application without placing an order, etc.) and timing forecasts (e.g., order preparation times). The optimization models 153B may combine multiple supervised optimization models, including, for example, convex and non-convex models.

In some examples, the model creation unit 158 creates the models 153A, 153B using, for example, a machine learning process in which the models are trained and adjusted over time using real-time information (e.g., from the requester status storage unit 132 and/or the provider status storage unit 134) and historical information 159.

In some examples, the model generator 158 may create one or more models 153 for use by the supply subsystem 150. The supply models 153 may include a diversion model that enables the forecaster 154 to use real-time information to generate a forecast 157 of the number of order requests. The diversion model may utilize input real-time information, for example, from the requester status store 132, corresponding to the number of active requesters who have not yet made an order request. In a variation, the model generator 158 may analyze historical information 159 (e.g., a previous snapshot of the requester status store 132 in a previous time period) to detect (1) active requester session events consistent with a requester initiating a session with the system 100 by launching a service application 106 on his/her device 102, and (2) diversion events consistent with an active requester making an order request. Other information that may be discovered from the analysis of historical data may include, for example, the length of time that diversion events occur for each individual requester and the suppliers viewed by the active requesters. Model generator 158 may also record the occurrence of events (e.g., active requester session events, conversion events) over successive time intervals. For example, model generator 158 may use input parameters reflecting velocity values (or acceleration values or other derivatives thereof) for the number of order requests, the number of active requesters, and/or the number of converted requesters.

Additionally or alternatively, the model creation unit 158 may also create predictive models to be used to forecast delivery requests for future time intervals for which relevant real-time information does not yet exist. The model creation unit 158 may create such predictive models 153 using historical information, e.g., through statistical analysis, to predict the number of active requesters likely to be online during a particular time interval, the conversion rate of active requesters, and/or the number of order requests likely to be generated from users in a region.

When creating a conversion or other predictive model, the model creator 158 may also specify contextual information. For example, the model creator 158 may associate historical information with days of the week, times of the day, months of the year, events (e.g., sporting events), weather, and other relevant information.

The prediction unit 154 may utilize the model 153 created by the model creation unit 158 to generate one or more predictions 157 regarding requests during the current time interval and/or one or more future time intervals (e.g., the number of order requests that are likely to be received during a particular length of time). According to one example, the prediction unit 154 retrieves real-time information from the requester status storage unit 132 to predict the number of order requests that are likely to be received in the current (e.g., over the next hour) or in the near future time interval (over the next four hours). The real-time information may include, for example, the number of active requesters who have not yet made an order request, the amount of time each active requester spent viewing the menu contents 119 of each supplier, and/or the suppliers (e.g., supplier menus) that the requester viewed. Based on the real-time information, the prediction unit 154 may utilize, for example, a conversion model to predict the number of order requests that the system 100 will receive during the current or next time interval and the near time interval (e.g., the number of service requests that are likely to be received in the next four one-hour slots). Additionally or alternatively, the forecasting unit 154 may also utilize the model 153 created by the model creation unit 158 to estimate the number of order requests that the system 100 is expected to receive in future time intervals. For example, the model creation unit 158 may generate a timeline (e.g., an hourly order request forecast for each day of the upcoming week) showing the expected number of order requests for time slots of the upcoming future time interval.

According to some examples, the model creation unit 158 may also monitor the requester status storage unit 132 to compare the prediction unit 154's predictions 157 regarding the number of order requests received (or the number of active requesters, etc.) with actual results. Based on the comparison, the model creation unit 158 may adjust the model 153 used by the prediction unit 154.

In some variations, the modeler 158 may create and implement predictive models regarding timing-related characteristics of individual suppliers. The modeler 158 may monitor the requester status store 132 to determine a statistical sample of one or more timing-related characteristics of individual suppliers. As an example, a timing-related characteristic of a supplier may correspond to a preparation time for the supplier to prepare a delivery order. As another example, a timing-related characteristic may refer to the amount of time it typically takes a service provider to arrive at the supplier and depart with a delivery order. In this manner, the modeler 158 obtains data points for the length of time it takes a supplier (e.g., a restaurant) to prepare groceries for a delivery order. The timing-related characteristics may be associated with a supplier and a corresponding supplier record 125.

The PLD unit 152 may estimate supply levels 155 for current and future time intervals based on the forecasts 157 and the service provider availability forecasts. In some examples, the supply levels 155 correspond to a metric (e.g., a ratio) based on a comparison of (1) the estimated number of order requests received in a particular time period for a particular region and (2) the number of service providers expected to be available to provide delivery service to the order requests in that particular region. The estimated number of service providers may be calculated, for example, from real-time information (e.g., extracted from the provider status store 132) and historical information (e.g., a snapshot of the provider status store 132 at a previous time interval).

The PLA unit 156 may use a set of provisioning parameters 165 based on the provisioning level 155. The provisioning parameters 165 may define parameter values for use with rules, processes, or other logic of the network delivery service. Also, when the provisioning parameters 165 are changed, they generally affect the provisioning level of the network service according to a known relationship. According to some examples, a change in the provisioning parameters may increase or decrease the number of service requests (e.g., order requests) that the network computing system 100 may handle based on a known or expected relationship with the change in the provisioning parameters. The provisioning parameters 165 may be default values, for example, when the provisioning level 155 is neutral (e.g., the expected number of order requests matches available service providers) or is otherwise a desired value. When the provisioning level fluctuates away from the neutral or desired level, the PLA unit 156 may adjust the value of the provisioning parameters 165 to adjust the provisioning level 155.

The supply parameters 165 may affect various aspects of the delivery service performed by the system 100. Thus, for example, the PLA unit 156 may utilize multiple sets of supply parameters based on a sub-region or region of interest. According to multiple examples, the supply parameters 165 reflect aspects or aspects of the service provided by the system 100 that may be adjusted to cause a predicted change in the supply level 155 of the service provided. In particular, the values of the individual supply parameters 165 may be based on an optimization decision for one or more goals of the system 100. The optimization decision may be made by execution of one or more optimization processes (shown as optimization logic 166) that optimize aspects of the supply level for a particular service goal 161. The system 100 may achieve one or more service goals 161, such as maximizing the number of order requests handled in a particular length of time or minimizing the delivery time of received order requests. Thus, the values of the supply parameters 165 may be determined by a particular goal or set of goals of a selected optimization process.

According to some examples, the relationship between the individual supply parameters 165 and the supply level 155 may also be predetermined or otherwise known. For example, adjusting the value of a particular one of the supply parameters 165 may be known to have a favorable effect on increasing the number of service requests the system 100 handles, while at the same time adversely affecting another goal of reducing the service time of the order requests. The modeler 158 may establish a relationship between the values of the individual supply parameters 165 and the effect of the supply parameter values on the supply level 155, for example, for a particular region or time interval. Those relationships may be granular (e.g., a change in the supply parameter will increase the number of service requests the system 100 can handle), or more precise (e.g., a change in the supply parameter will have a percentage effect (e.g., 5%) on the conversion rate).

By way of example, the supply parameters 165 include one or more of timing parameters 167, service scope parameters 169, and service value parameters 171. The one or more timing parameters 167 may reflect a target time interval or time constraint (e.g., a maximum allowable time interval) by which a particular event in the fulfillment of an order request should occur. For example, the timing parameters 167 may reflect a target time or time constraint for one or more of: (1) a delivery time (e.g., from the time an order request 101 is made to the time the order is delivered to the requester); (2) a waiting time incurred by a service provider, e.g., measured as the interval between the service provider's arrival and departure from the service provider's location; (3) a time interval by which a delivery order is prepared and picked up; and/or (4) a time interval by which a delivery order is prepared and delivered. According to some examples, relaxing one or more of the timing parameters 167 may increase the amount of time by which multiple order requests may be matched with one another, thereby allowing the request handler 128 to batch more order requests.

The service range parameter 169 may reflect a range, such as a travel or absolute distance, between the supplier's location and the service point of the order request. In some examples, the service range parameter 169 may be expressed as a travel distance reflecting a travel time and/or distance from the supplier's location to the service point of the order request. The service range parameter 169 may be used by the menu unit 112, for example, to identify which suppliers in the supplier store 126 are available for the menu item 131. The menu unit 112 may query the supplier store 126 for suppliers in locations 129 that satisfy a proximity condition with respect to the requester's current location 107. The proximity condition is based on the service range parameter 169. By increasing the value of the service range parameter 169, the menu unit 112 may select more suppliers and use items 131 from those suppliers to create the menu content 119 on the requester device 102. Conversely, by decreasing the value of the service scope parameter 169, the menu section 112 may select fewer suppliers and use items 131 from those suppliers to create the menu content 119 for the requester device 102. Since requesters are more likely to place order requests 101 when more choices are available, an increase or decrease in the number of suppliers offered to an individual requester may affect the number of order requests 101 received by the system. For example, by increasing the service scope parameter 169, the supply subsystem 150 may predict an increase in conversion rate, such that more order requests 101 will be received over a particular period of time. The predicted number of order requests 101 may be used to engage existing service providers, generating more service requests for the service providers than usual. To meet a service level goal (e.g., a higher number of order requests fulfilled by the system 100), the optimization logic 166 may balance the value of the service scope 169 taking into account constraints such as additional costs to the service providers.

The service value parameter 171 may reflect a service value charged to the requester as part of a delivery order. As described in various examples, the service value parameter 171 may vary in response to factors such as the distance a service provider travels to fulfill a service order, the supplier's tier designation, and/or the availability of the service provider. In some examples, the service value parameter 171 may be used to adjust the number of service providers available during a particular time interval. For example, the service value parameter 171 may also be utilized by the account management 136, which may adjust the amount or value credited to the service provider based on changes in the service value parameter 171. For example, if more service providers are needed to enable handling of an unexpected number of order requests for a particular region, the service value parameter 171 may be increased to reflect a greater value and reward for service providers who facilitate order requests in that particular region. As shown by way of example in FIG. 1, the service value parameter 171 may be communicated to the provider device interface 120, from which the service value may be exposed to nearby providers. The provider device interface 120 may also publish an increase in the service value parameter 171 to attract more service providers. Thus, a change in the service value parameter 171 may increase or decrease the number of service providers working in a particular area.

FIG. 2 illustrates an example method for identifying a supplier for delivery service to an individual requester. FIG. 3 illustrates an example method for arranging transportation of multiple delivery orders. FIG. 4 illustrates an example method for arranging transportation of delivery orders in a manner that affects the supply level of the service provided. FIG. 5 illustrates another example method for arranging transportation of delivery orders to minimize service provider wait time. In describing the examples of FIGS. 2-5, components of the example of FIG. 1 are described for purposes of illustrating suitable components for performing the described steps or sub-steps.

Referring to the example of FIG. 2, the network computing system causes each requester's mobile device to transmit their location (210). For example, the requester device 102 may execute a service application 106 that accesses the mobile device's satellite receiver or other location-aware resource. The requester may open the service application 106 on his or her mobile device 102 and initiate a session with the network computing system 200.

When a session is initiated, the network computing system 200 transmits information (e.g., menu contents 119) to identify suppliers (e.g., restaurants) within a specified range from the requester (220). Suppliers may be identified by providing a supplier menu to the requester device. The requester may view menus from multiple suppliers within a specified service range relative to the requester's current location. The specified range may reflect a travel threshold distance between the supplier's location and the requester's current location. In some examples, the specified range for a particular region may be based at least in part on a supply level calculation (222) (e.g., a comparison of an estimated number of order requests to the number of available service providers). For example, as described in the example of FIG. 1, the specified range may be determined by service parameters 169 that the supply subsystem 150 may determine based on the calculated supply level 155 and the execution of an optimization process by the optimization logic 166. Thus, the system 100 may change the specified service range so that more or fewer suppliers are available to a particular requester. As the range increases, the system 100 may also adjust other parameters, such as the service value 171, based on a known or predicted relationship between the change in value of the service parameter and the supply level 155 (e.g., providing additional incentives for the service provider to drive additional miles).

Additionally or alternatively, in some examples, the selection of suppliers for a particular requester may be dynamic and based on the requester's current location (224). For example, system 100 may monitor the location of an individual requester's mobile device and reselect suppliers displayed on the mobile device based on the requester's updated location.

2 may reflect a time when the requester device 102 is in a pre-request state, such as when the requester opens the service application 106 to view available menus. The supply subsystem 150 may use the requester's pre-request state to determine supply levels 155 for the sub-region in which the requester is located. The supply subsystem 150 may also generate a prediction based, for example, on a prediction regarding whether the requester will generate an order request 101. For example, a prediction of whether a user will generate an order request 101 may be based in part on a prediction or observed conversion rate regarding the number of requesters who view menu content 119 from local suppliers and make an order request using the menu content 119.

Referring to the example of FIG. 3, the system 100 may perform a service to arrange for the transportation of order requests. When providing a service, the system 100 may receive order requests from requester devices in a particular region, each of which specifies a supplier (310). For each order request, the system 100 selects a service provider to transport the corresponding delivery order from the corresponding supplier to the requester (320). Also, when providing a service, the network computing system determines a supply level indicator for a current or future time interval for the particular region (330). The supply level indicator may be determined, at least in part, by the requester devices 102 communicating with the system 100 using the service application 106.

The system 100 selects a service provider for each order request by selecting one of a plurality of available decision logics to execute for a particular geographic region and at a particular time interval, where the selection of the decision logic is based at least in part on the determined supply level indicator (340). The system 100 executes the selected decision logic to determine whether the individual delivery orders generated in response to the order request can be consolidated for delivery to the requester. Once the delivery orders are consolidated, the same service provider may transport the delivery orders to their respective destinations.

According to some examples, the system 100 may execute a first decision logic to batch (342) multiple delivery orders for delivery to respective requesters based on the multiple delivery orders meeting at least a first timing criterion. As described in various examples, the timing criterion may be parameterized (e.g., timing parameter 167) and may be altered based on conditions such as those provided by the supply level markers and calculations. As an example, the system 100 may relax the timing parameter 167 to provide additional time for matched delivery orders to be generated.

In various examples, the timing criteria may be based on, for example, delivery times (e.g., the difference in delivery times for each of the bundled delivery orders). In other examples, the timing criteria may correspond to a latency incurred by the service provider, as measured by the interval between when the service provider arrives and when it leaves the supplier. Additionally or alternatively, the timing parameters may correspond to the time interval between when a delivery order is prepared and when it is picked up. Furthermore, the timing criteria may correspond to the time interval between when a delivery order is prepared and when it is delivered. According to some examples, relaxing one or more of the timing parameters 167 may allow the request handler 128 to bundle more order requests together, since the amount of time by which the order requests can be matched to each other increases.

Referring to the example of FIG. 4, the system 100 arranges (410) for transportation of delivery orders in a particular region according to a set of supply parameters. When arranging transportation of the delivery orders, the system 100 receives order requests from corresponding requester devices, each of which specifies a supplier. The system 100 also matches each received order request with a service provider for transporting the corresponding delivery order from the supplier to the service requester. The set of supply parameters may include a service value parameter and at least one of a service bundling parameter or a service scope parameter.

The network computing system calculates (420) a forecast of expected service requests to be received for a particular geographic area in the current or next time interval. In some examples, the forecast may be calculated from a model that utilizes real-time information. For example, the modeler 158 accesses the requester data store 132 to calculate the number of active requesters who have initiated a session with the system 100 but have not yet placed a delivery order.

The system 100 calculates (430) a supply level 155 for a particular region for an upcoming time interval based at least in part on the forecast. Based on the forecast, the system 100 makes a decision (440) as to whether to adjust any of a set of supply parameters 165 to change the supply level to a desired target value. Thus, the system 100 may change the values of the supply parameters 165 to adjust the determined or predicted supply level 155. For example, the service value 171 may be changed, e.g., to increase the number of service providers. Similarly, the service scope 169 may be increased or decreased to increase or decrease demand (e.g., conversion rates increase with more options for requesters).

In some examples, the supply parameters are adjusted (442) according to one or more optimization processes based on a service level objective. The service level objective may correspond, for example, to maximizing the number of service requests processed over a particular period of time, minimizing travel distances for service providers, and/or minimizing wait times for requesters' delivery orders.

In the example of FIG. 5, the system 100 receives order requests from requesters in a particular region and selects an individual service provider for each order request. The system 100 selects a service provider by predicting the order preparation time of the supplier of the order request (510). To predict the order preparation time, the system 100 may create a predictive model using historical information and/or real-time monitoring (512). For example, the model creation unit 158 of the system 100 may create a predictive model based on information found in the requester status store 132. In some examples, the model creation unit 158 may monitor the requester status store 132 and/or the supplier status store 134 to discover instances where the service provider arrived early at the supplier before the delivery order was prepared. Discovery may be made by identifying instances where the service provider had to wait before departing. An inference that may be made from the service provider waiting may be that the delivery order was not yet prepared when the supplier arrived at the supplier. In such cases, the departure time of the service provider may be used to estimate the preparation time of the delivery order. In some examples, the arrival and departure times may be determined automatically, for example, based on the current location of the provider device 104.

The system 100 may attempt to select a service provider during the time interval immediately preceding the predicted order preparation time (520). The matching component 140 may be initiated, for example, by the request handling component 128, to generate a request identifying a service provider that is assigned to travel to the supplier and that can arrive within a margin window from the predicted order preparation time (522). In some examples, a determination is made whether the order request can be matched with a service provider immediately (525). If the order request is matched with a service provider, the service provider may be tracked to arrive at the supplier within the margin window (528). The requester may also receive an estimated time for the delivery order to arrive at the requester based on the service provider's arrival time at the supplier (532). The system 100 may continue to monitor and update the requester through each stage of the delivery order.

If the matching unit 140 does not immediately find a match for the order request, the process may repeat 520. The request handling unit 128 may launch the matching unit 140 again at another time interval to find a match for the order request. The process may be repeated for the time interval immediately preceding the predicted order preparation time. The smaller the window for matching the order request with a service provider, the closer the area the matching unit 140 attempts to match to the supplier's location.

FIG. 6 illustrates an example computer system upon which one or more embodiments may be implemented. Computer system 600 may be implemented, for example, on a server or a combination of servers. For example, computer system 600 may be implemented as part of the example of FIG. 1. Computer system 600 may also perform methods such as those described in the examples of FIGS. 2-5.

In one embodiment, computer system 600 includes processing resources 610, memory resources 620 (e.g., read only memory (ROM) or random access memory (RAM)), storage 640, and a communication interface 650. Computer system 600 includes at least one processor 610 for processing information stored in main memory 620. Main memory 620 is provided by a random access memory (RAM) or other dynamic storage device for storing information and instructions executable by processor 610. Main memory 620 may also be used to store temporary variables or other intermediate information during execution of instructions executed by processor 610. Computer system 600 may also include memory resources 620 or other static storage devices for storing static information and instructions for processor 610. Storage device 640, such as a magnetic disk or optical disk, is provided for storing information and instructions.

The communication interface 650 enables the computer system 600 to communicate with one or more networks (e.g., a cellular network) using a network connection 680 (wireless or wired). Using the network connection 680, the computer system 600 can communicate with one or more computing devices, dedicated devices and modules, and one or more servers. The executable instructions stored in the memory 630 may include instructions 642 for implementing a network computing system such as described in the example of FIG. 1. The executable instructions stored in the memory 620 may also perform a method such as described in one or more examples of FIGS. 2-5.

Thus, the embodiments described herein relate to the use of computer system 600 to perform the techniques described herein. According to one aspect, the techniques are performed by computer system 600 in response to processor 610 executing one or more sequences of one or more instructions stored in memory 620. Such instructions may be read into memory 620 from another machine-readable medium, such as storage device 640. Execution of the sequences of instructions stored in memory 620 causes processor 610 to perform the process steps described herein. In other embodiments, hardwired circuitry may be used in place of or in combination with software instructions to implement the embodiments described herein. Thus, the embodiments described are not limited to any specific combination of hardware circuitry and software.

7 is a block diagram illustrating an example user device for use in the described embodiments. In one example, the user device 700 may execute a designated service application for a network service implemented by the network computing system 100 as described in the example of FIG. 1. In many embodiments, the user device 700 may include a portable computing device, such as a smartphone, a tablet computer, a laptop computer, a VR or AR headset device, or the like. Thus, the user device 700 may include typical phone and/or tablet features, such as a microphone 745, a camera 750, a satellite receiver 760, and a communication interface 710 for communicating with external entities using any number of wireless communication protocols. In some aspects, the user device 700 may store a designated application (e.g., a service app 732) in a local memory 730. In a variation, the memory 730 may store additional applications executable by one or more processors 740 of the user device 700 to enable access and interaction with one or more host servers over one or more networks 780.

In response to user input 718 (e.g., search input), the service application 732 may interact with the computer system 700 to display an application interface 742 on the display screen 720 of the user device 700. When the user device 700 is used as a requester device, the application interface 742 may be used to display menu contents 119 and enable the requester to make an ordering request on the network computing system 100.

Although the embodiments are described in detail herein with reference to the accompanying drawings, it should be understood that the concepts are not limited to those precise embodiments. Accordingly, the scope of those concepts is intended to be defined by the appended claims and their equivalents. Also, it is contemplated that certain features described individually or as part of an embodiment may be combined with those other individually described features or parts of other embodiments, even if those other features and embodiments do not mention that particular feature. Thus, the absence of a description of a combination should not preclude the right to such combination.

The following describes preferred embodiments of the present invention.

EMBODIMENT 1
one or more processors;
and a memory storing a set of instructions, the one or more processors accessing the set of instructions to cause each requester's mobile device to transmit its respective location to the network computing system;
Estimating, for a particular time interval, (1) a number of order requests received by the network computing system, each order request originating from a requester in a particular region and specifying an ordered item from a corresponding one of a plurality of suppliers in the particular region, and (2) a number of available service providers in the particular region that can provide transportation to fulfill the order requests;
A network computing system that selects, for each requester in the population, a set of multiple suppliers for the requester's supplier menu based at least in part on the location of the requester's mobile device and at least one of the estimated number of order requests or the estimated number of available service providers.

EMBODIMENT 2
2. The network computing system of claim 1, wherein the one or more processors select a supplier from the set of multiple suppliers for each of the individual requesters based at least in part on a travel distance between the supplier and the location of the requester.

EMBODIMENT 3
3. The network computing system of embodiment 2, wherein the one or more processors determine the travel distance threshold based at least in part on a comparison of the estimated number of order requests to a number of available service providers.

EMBODIMENT 4
4. The network computing system of embodiment 3, wherein the one or more processors repeatedly update the threshold value for the travel distance.

EMBODIMENT 5
3. The network computing system of claim 2, wherein the one or more processors estimate the number of order requests and the number of available service providers, respectively, by predicting the number of order requests and the number of available service providers, respectively, for an upcoming time interval.

EMBODIMENT 6
6. The network computing system of claim 5, wherein the one or more processors set the threshold for the travel distance based on a comparison of the predicted number of order requests and the predicted number of service providers.

EMBODIMENT 7
The network computing system of embodiment 6, wherein the one or more processors predict the number of order requests and the number of available service providers using historical information and real-time information obtained from mobile devices of individual requesters within the particular region.

EMBODIMENT 8
8. The network computing system of embodiment 7, wherein the real time information includes a count of the number of mobile devices that have a service application running and no corresponding service request pending from that mobile device.

EMBODIMENT 9
2. The network computing system of claim 1, wherein the one or more processors access the set of instructions to identify a plurality of sub-regions within the particular region, and the one or more processors select the plurality of suppliers for each requester among the total population based at least in part on a predefined sub-region that coincides with the requester's current location.

EMBODIMENT 10
2. The network computing system of claim 1, wherein for each requester among the population, the one or more processors select the set of multiple suppliers to include first tier suppliers and second tier suppliers, the second tier suppliers being associated with order request constraints that the first tier suppliers are not associated with.

EMBODIMENT 11
11. The network computing system of embodiment 10, wherein the order request constraint is an order size.

EMBODIMENT 12
11. The network computing system of claim 10, wherein for each requester among the entire population, the one or more processors determine that a supplier among the selected set is in the second tier based at least in part on the location of the supplier and the requester.

EMBODIMENT 13
2. The network computing system of claim 1, wherein the one or more processors cause the supplier menu to be displayed on a mobile device of each of the individual requesters.

EMBODIMENT 14
The network computing system of embodiment 1, wherein the one or more processors monitor the location of a mobile device of each requester among the entire population and reselect the set of multiple suppliers for the requester's supplier menu based at least in part on the location of the requester's mobile device after the location of the requester's mobile device changes.

EMBODIMENT 15
1. A method for fulfilling an order request, the method being executed by one or more processors, comprising:
causing each requester's mobile device to transmit its respective location to a network computing system;
estimating, for a particular time interval, (1) a number of order requests received by the network computing system, each order request originating from a requester in a particular region and specifying an ordered item from a corresponding one of a plurality of suppliers in the particular region, and (2) a number of available service providers in the particular region that can provide transportation to fulfill the order requests;
and for each requester in the population, selecting a set of a plurality of suppliers for the requester's supplier menu based at least in part on a location of the requester's mobile device and at least one of the estimated number of order requests or the estimated number of available service providers.

EMBODIMENT 16
16. The method of embodiment 15, wherein the step of selecting the set of multiple suppliers includes selecting a supplier from the set of multiple suppliers for each of the individual requesters based at least in part on a travel distance between the supplier and the location of the requester.

EMBODIMENT 17
17. The method of claim 16, wherein the step of selecting the set of multiple suppliers includes determining the travel distance threshold based at least in part on a comparison of the estimated number of order requests to a number of available service providers.

EMBODIMENT 18
16. The method of embodiment 15, wherein the estimating step includes forecasting each of the number of order requests and the number of available service providers for an upcoming time interval.

EMBODIMENT 19
20. The method of claim 18, wherein the step of selecting a set of a plurality of suppliers determines the travel distance threshold based on a comparison of the predicted number of order requests and the predicted number of service providers.

EMBODIMENT 20
a non-transitory computer readable medium storing a plurality of instructions which, when executed by one or more processors of a network computing system, cause the network computing system to cause each requester's mobile device to transmit its respective location to the network computing system;
estimating, for a particular time interval, (1) a number of order requests received by the network computing system, each order request originating from a requester in a particular region and specifying an ordered item from a corresponding one of a plurality of suppliers in the particular region, and (2) a number of available service providers in the particular region that can provide transportation to fulfill the order requests;
and selecting, for each requester in the population, a set of a plurality of suppliers for the requester's supplier menu based at least in part on a location of the requester's mobile device and at least one of the estimated number of order requests or the estimated number of available service providers.

EMBODIMENT 21
one or more processors;
and a memory storing a set of instructions, the one or more processors accessing the instructions to: receive a plurality of order requests, each order request originating from a corresponding one of a plurality of requester devices and specifying a supplier one of a plurality of suppliers;
for each of the plurality of order requests, selecting a service provider from a group of available service providers and transporting a corresponding delivery order from the corresponding supplier to the requester;
determining a supply level indicator for a particular geographic area during a particular time interval by communicating with a plurality of requester devices and a plurality of provider devices;
the one or more processors select the service provider for each of the plurality of order requests by executing decision logic based at least in part on the determined supply level indicator to determine whether individual delivery orders generated in response to each order request can be bundled for delivery to a respective requester.

EMBODIMENT 22
22. The network computing system of claim 21, wherein the decision logic includes at least first decision logic for batching a plurality of delivery orders for delivery to respective requesters based on the plurality of delivery orders meeting at least a first timing criterion.

EMBODIMENT 23
23. The network computing system of embodiment 22, wherein the at least a first timing criterion includes a difference between when each of the delivery orders is ready at a particular supplier being less than a specified threshold.

EMBODIMENT 24
23. The network computing system of embodiment 22, wherein the at least a first timing criterion includes an estimated time for delivery of each of the plurality of orders being less than a predetermined limit.

EMBODIMENT 25
23. The network computing system of embodiment 22, wherein the at least a first timing criterion comprises a travel distance between locations of requesters of each of the plurality of orders being less than a specified threshold.

EMBODIMENT 26
23. The network computing system of claim 22, wherein the first decision logic is at least less restrictive than the second decision logic such that execution of the one or more processors by the first decision logic results in more bundled delivery orders.

EMBODIMENT 27
27. The network computing system of claim 26, wherein each of the first decision logic and the second decision logic, when executed, batches the plurality of delivery orders for delivery to respective requesters based at least in part on the plurality of delivery orders satisfying at least one timing criterion, and the timing criterion of the first decision logic is based on a longer length of time than the timing criterion of the second decision logic.

EMBODIMENT 28
22. The network computing system of embodiment 21, wherein the supply level indicator is deemed to be indicative of a sudden increase in order requests in a recent time interval.

EMBODIMENT 29
22. A network computing system as described in embodiment 21, wherein the one or more processors determine the supply level indicator by detecting a number of requester devices that launch a service application from which an order request can be made in a time interval immediately preceding the particular time interval.

EMBODIMENT 30
22. A network computing system as described in embodiment 21, wherein the one or more processors determine the supply level indicator by detecting a number of requester devices executing a service application from which an order request can be made during a time interval immediately preceding the particular time interval.

EMBODIMENT 31
22. The network computing system of claim 21, wherein the one or more processors determine the supply level by estimating at least one of the number of order requests and the number of available service providers for the particular region in a time interval immediately preceding the particular time interval.

EMBODIMENT 32
22. The network computing system of claim 21, wherein the one or more processors access the set of instructions to calculate an arrival time for a service provider of a set of bundled delivery orders to arrive at a supplier of the set of bundled delivery orders.

EMBODIMENT 33
33. The network computing system of embodiment 32, wherein the one or more processors assign service providers to the set of batched delivery orders based at least in part on the calculated arrival times.

EMBODIMENT 34
33. The network computing system of embodiment 32, wherein the one or more processors calculate the arrival time based at least in part on an estimated order preparation time for each of the bundled set of delivery orders at the supplier.

EMBODIMENT 35
1. A method for fulfilling an order request, the method being executed by one or more processors, comprising:
For each of the plurality of order requests, selecting a service provider from a group of available service providers and transporting a corresponding delivery order from the corresponding supplier to the requester;
determining a supply level indicator for a particular geographic area during a particular time interval by communicating with a plurality of requester devices and a plurality of provider devices;
The method, wherein the step of selecting a service provider includes the step of batching a plurality of delivery orders resulting from the plurality of order requests with a particular service provider according to a set of rules based at least in part on the determined supply level indicator.

EMBODIMENT 36
36. The method of embodiment 35, wherein the step of batching a plurality of delivery orders includes selecting at least two delivery orders to batch based on a timing parameter.

EMBODIMENT 37
37. The method of embodiment 36, wherein determining the timing parameter is based at least in part on the determined supply level.

EMBODIMENT 38
37. The method of embodiment 36, wherein the timing parameters set a time limit for each delivery order of a plurality of bundled delivery orders being delivered to a corresponding location of a corresponding order request.

EMBODIMENT 39
36. The method of embodiment 35, wherein the step of determining the supply level indicator comprises forecasting the supply level indicator for an upcoming time interval.

EMBODIMENT 40
a non-transitory computer readable medium storing a plurality of instructions which, when executed by one or more processors of a network computing system, cause the network computing system to: for each of a plurality of order requests, select a service provider from a group of available service providers and transport a corresponding delivery order from the corresponding supplier to the requester;
determining a supply level indicator for a particular geographic area for a particular time interval by communicating with a plurality of requester devices and a plurality of provider devices;
The step of selecting a service provider includes the step of batching a plurality of delivery orders resulting from the plurality of order requests with a particular service provider according to a set of rules based at least in part on the determined supply level indicator.

EMBODIMENT 41
one or more processors;
and a memory storing a set of instructions, the one or more processors accessing the instructions to arrange for transportation of delivery orders in a particular geographic area in accordance with a set of supply parameters, the one or more processors performing the steps of: (A) receiving a plurality of delivery requests, each delivery request originating from a corresponding requester device and specifying a supplier among a plurality of suppliers; (B) matching each of the plurality of delivery requests with a service provider to transport the corresponding delivery order from the supplier to the requester of the delivery request;
the set of provisioning parameters includes a service value parameter and at least one of a service bundling parameter or a service scope parameter;
The one or more processors calculate a prediction of at least one of the number of service requests or the number of available service providers for an upcoming time interval;
determining a supply level for the particular region during the immediate time interval based at least in part on the forecast;
A network computing system that modifies the set of supply parameters to adjust the supply levels to desired target values.

EMBODIMENT 42
42. The network computing system of claim 41, wherein the one or more processors modify the set of supply parameters by increasing the time interval for matching two or more delivery orders from a single supplier to increase the number of delivery orders that are bundled together.

EMBODIMENT 43
42. The network computing system of embodiment 41, wherein the one or more processors modify the set of supply parameters by increasing or decreasing a service range that defines the distance between individual requesters and available suppliers.

EMBODIMENT 44
42. The network computing system of embodiment 41, wherein the one or more processors vary the set of supply parameters by executing an optimization process to identify one or more values for one or more of the set of supply parameters to optimize the number of delivery requests serviced in a particular length of time.

EMBODIMENT 45
42. The network computing system of embodiment 41, wherein the one or more processors modify the set of provisioning parameters by changing a value of a service value parameter.

EMBODIMENT 46
42. The network computing system of embodiment 41, wherein the one or more processors perform one or more operations to increase a number of available service providers in the particular region during the upcoming time interval.

EMBODIMENT 47
47. The network computing system of embodiment 46, wherein the one or more actions include generating incentives for available service providers in nearby areas to provide delivery services in the particular area.

EMBODIMENT 48
The network computing system of embodiment 41, wherein (1) the service range parameter specifies a maximum travel distance from a supplier's location to a delivery point, and (2) the service value parameter specifies a credit amount allocated to a service provider for transporting a delivery order from the supplier's location to the delivery point, and the one or more processors adjust the supply level by adjusting the service range parameter and the supply level parameter to modify the set of supply parameters.

EMBODIMENT 49
1. A method for providing delivery services, the method being executed by one or more processors, comprising:
(A) receiving a plurality of delivery requests, each delivery request originating from a corresponding requester device and specifying a supplier among a plurality of suppliers, and (B) matching each of the plurality of delivery requests with a service provider to transport a corresponding delivery order from the supplier to a requester of the delivery request, so as to arrange for transportation of the delivery orders in a particular region according to a set of supply parameters, the set of supply parameters including a service value parameter and at least one of a service bundling parameter or a service scope parameter;
calculating a forecast of at least one of the number of service requests or the number of available service providers for an upcoming time interval;
determining a supply level for the particular region during the immediate time interval based at least in part on the forecast;
and modifying the set of delivery parameters to adjust the delivery level to a desired target value.

EMBODIMENT 50
50. The method of embodiment 49, wherein modifying the set of supply parameters includes modifying a time interval for matching two or more order requests from a single supplier to increase the number of delivery orders bundled together.

EMBODIMENT 51
50. The method of embodiment 49, wherein modifying the set of supply parameters includes increasing or decreasing a service range that defines the distance between individual requesters and available suppliers.

EMBODIMENT 52
50. The method of embodiment 49, wherein the step of modifying the set of supply parameters includes running an optimization process to optimize the number of delivery requests serviced in a particular length of time.

EMBODIMENT 53
50. The method of embodiment 49, wherein modifying the set of supply parameters includes increasing a value of a service value parameter.

EMBODIMENT 54
50. The method of embodiment 49, further comprising performing one or more actions to change the number of available service providers in the particular region during the upcoming time interval to adjust the supply level to the desired target value.

EMBODIMENT 55
55. The method of embodiment 54, wherein the one or more actions include generating incentives for available service providers in nearby areas to provide delivery services within the particular area.

EMBODIMENT 56
The method of embodiment 49, wherein the service range parameter specifies a maximum travel distance from the supplier's location to the delivery point and the service value parameter specifies a credit amount allocated to a service provider for transporting a delivery order from the supplier's location to the delivery point, and the step of adjusting the supply level by modifying the set of supply parameters includes adjusting the service range parameter and the supply level parameter.

EMBODIMENT 57
A non-transitory computer readable medium storing a plurality of instructions, which, when executed by one or more processors of a network computing system, causes the network computing system to arrange for transportation of delivery orders in a particular region according to a set of supply parameters, comprising: (A) receiving a plurality of delivery requests, each delivery request originating from a corresponding requester device and specifying a supplier among a plurality of suppliers; and (B) matching each of the plurality of delivery requests with a service provider to transport the corresponding delivery order from the supplier to a requester of the delivery request, the set of supply parameters including a service value parameter and at least one of a service bundling parameter or a service scope parameter;
calculating a forecast of at least one of the number of service requests or the number of available service providers for an upcoming time interval;
determining a supply level for the particular region during the immediate time interval based at least in part on the forecast;
and c) modifying the set of delivery parameters to adjust the delivery level to a desired target value.

EMBODIMENT 58
58. The non-transitory computer-readable medium of embodiment 57, wherein modifying the set of supply parameters includes modifying a time interval for matching two or more order requests from a single supplier to increase the number of delivery orders bundled together.

EMBODIMENT 59
58. The non-transitory computer-readable medium of embodiment 57, wherein modifying the set of supply parameters includes increasing or decreasing a service range that defines the distance between individual requesters and available suppliers.

EMBODIMENT 60
58. The non-transitory computer-readable medium of embodiment 57, wherein modifying the set of supply parameters includes running an optimization process to optimize the number of delivery requests serviced in a particular length of time.

100 Network Computing System 101 Order Request 102 Requester Device 103 Requester Information 104 Provider Device 105 Requester Identifier 106, 116 Service Application 107 Requester Location 109 Service Information 110 Requester Device Interface 112 Menu Section 113 Provider Location 115 Provider Identifier 117 Item Information 118 Layer Logic 119 Menu Contents 120 Provider Device Interface 125 Supplier Record 126 Supplier Memory Section 127 Supplier Identifier 128 Request Handling Section 129 Supplier Location 130 Supplier Interface 132 Requester Status Memory Section 133 Service Status 134 Provider Status Memory Section 135 Provider Record 136 Account Management Section 138 Aggregation Decision Logic 150 Supply Subsystem 152 Supply Level Calculation Section 154 Forecasting unit 155 Supply level 156 Supply level adjustment unit 157 Forecasting 158 Model creation unit 159 History information 165 Supply parameters 166 Optimization logic 600 Computer system 610 Processor 620 Memory resources 640 Storage device 650 Communication interface 680 Network connection 700 User device 710 Communication interface 718 User input 720 Display screen 730 Memory 732 Service app 740 Processor 742 Application interface 745 Microphone 750 Camera 760 Satellite receiver 780 Network

Claims (13)

one or more processors;
a memory for storing a set of instructions;
wherein the one or more processors access the instructions to configure the network computing system to:
receiving a plurality of order requests, each order request originating from a corresponding one of the plurality of requester devices and specifying a supplier from the plurality of suppliers;
determining , using one or more predictive models, a supply level indicator for a particular geographic area during a particular time interval by communicating with a requester device and a plurality of provider devices in the particular geographic area , the determination including inputting into at least one of the one or more predictive models near real-time information regarding a number of active requesters in the particular geographic area who have initiated respective sessions using a requester application executing on the requester device, but have not yet submitted an order request using the requester application;
determining, based at least in part on the determined supply level indicator , whether to bundle two or more order requests among the plurality of order requests by selecting a single service provider to provide transportation for the two or more order requests . 2. The network computing system of claim 1, wherein satisfying at least a first timing criterion comprises a difference between when each of the two or more order requests is ready at a particular supplier being less than a specified threshold. The network computing system of claim 1, wherein the supply level indicator is deemed to indicate a sudden increase in order requests in a recent time interval. 2. The network computing system of claim 1, wherein said determining said supply level indicator comprises determining a number of requestor devices that launch said requestor application in a time interval immediately preceding said particular time interval. 2. The network computing system of claim 1, wherein said determining said supply level indicator comprises determining a number of requester devices executing said requester application in a time interval immediately preceding said particular time interval. 2. The network computing system of claim 1, wherein said determining said supply level indicator comprises estimating at least one of a number of order requests and a number of available service providers for said particular geographic area in a time interval immediately preceding said particular time interval. 2. The network computing system of claim 1, wherein the one or more processors access the set of instructions to cause the network computing system to calculate an arrival time for a service provider of a bundled set of order requests to arrive at a supplier of the bundled set of order requests. 8. The network computing system of claim 7, wherein the one or more processors access the instructions to cause the network computing system to assign service providers to the bundled set of order requests based at least in part on the calculated arrival times. 8. The network computing system of claim 7, wherein the one or more processors access the instructions to cause the network computing system to calculate the arrival time based at least in part on an estimated order preparation time for each of the bundled set of order requests at the supplier . 1. A method for fulfilling an order request, the method being executed by one or more processors, comprising:
receiving a plurality of order requests, each order request originating from a corresponding one of a plurality of requester devices and specifying a supplier one of a plurality of suppliers ;
determining a supply level indicator for a particular time interval for a particular geographic area using one or more predictive models by communicating with a requester device and a plurality of provider devices in the particular geographic area , the method comprising: inputting into at least one of the one or more predictive models near real-time information regarding a number of active requesters in the particular geographic area who have initiated respective sessions using a requester application executing on the requester device, but have not yet submitted an order request using the requester application ;
determining whether to bundle two or more of the plurality of order requests by selecting a single service provider to provide transportation for the two or more order requests based at least in part on the determined supply level indicator;
A method comprising : The method of claim 10 , wherein determining a timing parameter based at least in part on the determined supply level indicator is based at least in part on the determined supply level. 11. The method of claim 10 , further comprising: setting a time limit for each delivery order of a plurality of bundled delivery orders being delivered to a corresponding location of a corresponding order request, said timing parameter being configured. A non-transitory computer readable medium storing a plurality of instructions, the plurality of instructions, when executed by one or more processors of a network computing system, for implementing a method and system for implementing a network computing system comprising:
receiving a plurality of order requests, each order request originating from a corresponding one of a plurality of requester devices and specifying a supplier one of a plurality of suppliers ;
determining a supply level indicator for a particular time interval for a particular geographic area using one or more predictive models by communicating with a requester device and a plurality of provider devices in the particular geographic area , the method comprising: inputting into at least one of the one or more predictive models near real-time information regarding a number of active requesters in the particular geographic area who have initiated respective sessions using a requester application executing on the requester device, but have not yet submitted an order request using the requester application ;
determining whether to bundle two or more of the plurality of order requests by selecting a single service provider to provide transportation for the two or more order requests based at least in part on the determined supply level indicator;
2. A non-transitory computer readable medium for causing a computer to perform operations including:

Images