Computer system for implementing a network delivery service

Abstract

To provide a system for reasonably implementing a network delivery service.SOLUTION: A network computing system estimates a provisioning level for a given time interval for one or more regions. The provisioning level determination may be based on an estimated number of order requests, and on the number of available service providers in the given region that are available to provide transport in fulfilling the order requests. For individual requests within the given region, the computer system selects a set of multiple suppliers for a supplier menu that is displayed on a mobile device of the requester. The selection of suppliers for individual requesters may be based at least in part on a current location of the requesters, and on at least one of the estimated number of order requests or the estimated number of available service providers.SELECTED DRAWING: Figure 1

Description

Related Applications

[0001] This application claims the benefit of priority from (1) U.S. Patent Application No. 15 / 802385, filed November 2, 2017, (2) U.S. Patent Application No. 15 / 802391, filed November 2, 2017, and (3) U.S. Patent Application No. 15 / 802394, filed November 2, 2017, all of which are incorporated herein by reference in their entirety. This application is a divisional application of Japanese Patent Application No. 2020-524524, filed October 31, 2018. [Technical field]

[0002] The examples described herein relate to computer systems that implement network delivery services. [Background technology]

[0003] Many on-demand services exist and provide users with 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 dedicated applications (sometimes called "apps") that communicate with the network services through which the on-demand service is provided. Summary of the Invention

[0004] According to some examples, the network computing system performs operations to arrange transportation services for delivery orders.

[0005] In some examples, the network computing system estimates supply levels for a particular time interval for one or more regions. The supply level determination may be based on the estimated number of order requests and the 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 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.

[0006] In a variation, the network computing system arranges transportation for the delivery order by (1) predicting an order preparation time of each supplier for the order request, and (2) generating a request to the service provider during a time interval prior to the order preparation time based at least in part on a determination that the arrival time of the matched service provider at each supplier is 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.

[0007] As used herein, customer equipment refers to equipment corresponding to a desktop computer, cellular device or smartphone, wearable device, laptop computer, tablet device, television (IP television), etc. that can provide network connectivity and processing resources to communicate over a network with the system. Driver equipment may correspond to specialized hardware, in-vehicle equipment, or on-board computers, etc. Customer equipment and / or driver equipment may also run designated applications configured to communicate with system 100.

[0008] 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.

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

[0010] 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.

[0011] 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. Memory, processing, and network resources may all 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).

[0012] 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 the 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 storage 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. [Brief description of the drawings]

[0013] [Figure 1] 1 illustrates an example network computing system for arranging transportation of a delivery order in accordance with one or more embodiments. [Diagram 2] 1 illustrates an example method for identifying a supplier for delivery services to an individual requester. [Diagram 3] 1 illustrates an example method for arranging transportation for multiple delivery orders. [Figure 4] 1 illustrates an example method for arranging transportation of delivery orders in a manner that affects the supply level of the services provided. [Diagram 5] 1 illustrates another example method for arranging transportation of a delivery order to minimize service provider wait time. [Figure 6] 1 illustrates an exemplary computer system upon which one or more embodiments may be implemented. [Figure 7] FIG. 2 is a block diagram illustrating an example user device for use in the described embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] FIG. 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 a requester, a supplier, and a service provider. The network computing system 100 may be implemented on a server, a combination of multiple 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.

[0015] 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 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.

[0016] 1, system 100 includes a requestor device interface 110, a provider device interface 120, a request handler 128, a supplier interface 130, a matcher 140, and one or more data stores for updating information about requestors, order requests, and providers. System 100 may also include a supply subsystem 150 that enables system 100 to regulate supply levels of system 100.

[0017] 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 over the network services may also be performed at a group level to objectively accommodate the interests of service providers, suppliers, and requesters.

[0018] 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 a portion of the requester information 103 (eg, current location) may be communicated before the order request 101 is made at the requester device 102 .

[0019] 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 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.

[0020] 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 utilize when providing 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 enables 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.

[0021] 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 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 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 may be used to update the provider status store 134. Thus, the provider data store 134 may reflect the most recent current location of each service provider.

[0022] In some examples, the requestor 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 requestor device 104, respectively. By providing an external-facing API, the system 100 may establish a secure communication channel over a network via a secure access channel in any number of ways, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), remote procedure calls (RPC), scripted access, etc.

[0023] 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 the order requests. The supplier may also access the system 100 to provide a menu or description (including text and images) of deliverable items.

[0024] 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 an account identifier 127 as well as a supplier location 129 and 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.

[0025] 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 deliverable items 131 of the supplier. 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.

[0026] In some examples, the requester status store 132 records instances when a service application 106 is launched on a requester device 102. In such cases, the requester status store 132 may associate a record with the requester of 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.

[0027] The order request 101 may be received by the requester device interface 110 and stored 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 define 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.

[0028] 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.

[0029] 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) in 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.

[0030] 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 a 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's location (e.g., the time to match a corresponding order request 101 with the service provider and the time for the service provider to travel to the supplier's location) is within a time threshold window from the estimated order preparation time for the supplier and / or the item in the order request 101.

[0031] Calculation of delivery order preparation times may be based on information related to suppliers, for example. For example, the supplier store 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.

[0032] In some instances, 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 match the corresponding order request with the service provider and arrive at the supplier. In such instances, 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 instances, the delay in sending a 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.

[0033] 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. Thus, for example, the proximity of a service provider may not necessarily be a decisive selection criterion for the selection of a particular service provider.

[0034] 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, whereby bundling of delivery orders is permitted if the delivery orders are prepared by the same supplier; (2) a timing condition, whereby 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, whereby bundling of delivery orders is permitted if the delivery orders are prepared by suppliers that meet geographic conditions regarding the location and / or delivery point of each supplier; and / or (4) a supply condition, whereby the supply level calculation 155 determines or influences the bundling decision.

[0035] With respect 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 are present 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.

[0036] With respect to 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 that time when 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.

[0037] In a variation, the batching decision logic 138 may allow delivery orders to be batched 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 batched 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 batched delivery orders. In a variation, other timing parameters 167 may control when delivery orders from a particular supplier can be batched.

[0038] With respect to the supplier location condition, the batching 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 batching decision logic 138 may allow delivery orders from different suppliers to be batched, 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 batching decision logic 138 may allow delivery orders from different suppliers to be batched, for example, if the different suppliers meet a route condition, for example, the different suppliers are aligned for delivery purposes along a route.

[0039] 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 has been communicated to the supplier; (2) the supplier has acknowledged receipt of the order request; (3) one or more progress indications of the order request have been prepared, including when a corresponding delivery order is ready; (4) the service provider has picked 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).

[0040] 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. As 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 component 140 identifies a service provider and while the request handling component 128 tracks the service provider from pickup to the point of delivery of the order.

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

[0042] Upon detection that the service provider has completed the delivery service, the request handler 128 may initiate the account manager 136. The account manager 136 may record the fulfillment of the order request with respect to the service provider, supplier, and requester 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.

[0043] 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 for the number of service requests to be handled in a particular time interval. The forecasting component 154 can 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 can 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 component 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.

[0044] 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.

[0045] 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 store 132 and / or the provider status store 134) and historical information 159.

[0046] In some examples, the model generator 158 may generate 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.

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

[0048] When creating a conversion or other predictive model, the model generator 158 may also specify contextual information. For example, the model generator 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.

[0049] The prediction unit 154 may utilize the model 153 created by the model creation unit 158 ​​to generate one or more predictions 157 for requests during the current time interval and / or one or more future time intervals (e.g., the number of order requests 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 likely to be received in the current (e.g., over the next hour) or upcoming future time intervals (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 looking at 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 upcoming time intervals (e.g., the number of service requests likely to be received in the next four one-hour slots). Additionally or alternatively, the forecasting component 154 may also utilize the model 153 generated by the model generation component 158 ​​to estimate the number of order requests that the system 100 is expected to receive in future time intervals. For example, the model generation component 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.

[0050] According to some examples, the model generator 158 may also monitor the requester status store 132 to compare the predictions 157 of the predictor 154 regarding the number of order requests received (or the number of active requesters, etc.) with actual results. Based on the comparison, the model generator 158 may adjust the model 153 used by the predictor 154.

[0051] In some variations, the model generator 158 may create and implement predictive models regarding timing-related characteristics of individual suppliers. The model generator 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 model generator 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.

[0052] The PLD unit 152 may estimate supply levels 155 for current and future time intervals based on the forecasts 157 and 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).

[0053] 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 ​​to 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 the 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.

[0054] 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 amount 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.

[0055] According to some examples, the relationship between the individual supply parameters 165 and the supply levels 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 relationships between the values ​​of the individual supply parameters 165 and the effect of the supply parameter values ​​on the supply levels 155, for example, for a particular region or time interval. These relationships may be granular (e.g., changing the supply parameter will increase the number of service requests the system 100 can handle), or more precise (e.g., changing the supply parameter will have a percentage effect (e.g., 5%) on the conversion rate).

[0056] By way of example, the supply parameters 165 include one or more of a timing parameter 167, a service scope parameter 169, and a service value parameter 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 until 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 allow the request handler 128 to batch more order requests together, increasing the amount of time by which multiple order requests may be matched with one another.

[0057] The service range parameter 169 may reflect a range, such as 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 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 section 112, for example, to identify which suppliers in the supplier store 126 are available for the menu item 131. The menu section 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. This proximity condition is based on the service range parameter 169. By increasing the value of the service range parameter 169, the menu section 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 objective (e.g., a greater 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.

[0058] 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 will travel to fulfill a service order, the tier designation of the supplier, 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 facilitating 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.

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

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

[0061] When a session is initiated, the network computing system 200 transmits information (e.g., menu contents 119) to identify (220) suppliers (e.g., restaurants) within a specified range from the requester. 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 determination (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 determined supply level 155 and performance 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 distances).

[0062] Additionally or alternatively, in some instances, 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 the suppliers displayed on the mobile device based on the requester's updated location.

[0063] 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.

[0064] 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 (310) order requests from requester devices in a particular region, each of which specifies a supplier. For each order request, the system 100 selects (320) a service provider to transport the corresponding delivery order from the corresponding supplier to the requester. Also, when providing a service, the network computing system determines (330) a supply level indicator for a current or future time interval for the particular region. 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.

[0065] 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.

[0066] 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.

[0067] 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 waiting time incurred by a 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.

[0068] 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 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.

[0069] The network computing system calculates (420) a forecast of expected service requests to be received for the current or next time interval for a particular geographic area. In some instances, the forecast may be calculated from a model that utilizes real-time information. For example, the model generator 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.

[0070] 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 coverage 169 may be increased or decreased to increase or decrease demand (e.g., conversion rates increase with more options for requesters).

[0071] In some examples, the supply parameters are adjusted 442 according to one or more optimization processes based on service level objectives, which 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.

[0072] 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 the service provider by predicting the order preparation time of the supplier for the order request (510). To predict the order preparation time, the system 100 may develop a predictive model using historical information and / or real-time monitoring (512). For example, the model creation unit 158 ​​of the system 100 may develop the 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 .

[0073] The system 100 may attempt to select a service provider during the time interval immediately preceding the expected 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 expected order preparation time (522). In some instances, 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.

[0074] If the matching component 140 does not immediately find a match for the order request, the process may repeat 520. The request handling component 128 may launch the matching component 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 component 140 attempts to match to the supplier's location.

[0075] 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.

[0076] 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 may be 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 for storing temporary variables or other intermediate information during execution of instructions to be 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.

[0077] 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, special purpose devices and modules, and one or more servers. The executable instructions stored in the memory 630 may include instructions 642 that implement a network computing system such as described in the example of FIG. 1. The executable instructions stored in the memory 620 may also implement a method such as described in one or more examples of FIGS. 2-5.

[0078] 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.

[0079] FIG. 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.

[0080] 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.

[0081] 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 refer to that particular feature. Thus, the absence of a description of a combination should not preclude the right to such combination.

[0082] Preferred embodiments of the present invention will be described below in detail.

[0083] EMBODIMENT 1 one or more processors; A memory for storing a set of instructions; wherein the one or more processors have access to the set of instructions. causing each requester's portable device to transmit its respective location to said 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 a plurality of 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.

[0084] 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.

[0085] 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.

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

[0087] EMBODIMENT 5 The network computing system of embodiment 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.

[0088] EMBODIMENT 6 6. The network computing system of embodiment 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.

[0089] 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.

[0090] 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.

[0091] 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 a total population based at least in part on a predefined sub-region that coincides with the requester's current location.

[0092] 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 a first tier supplier and a second tier supplier, the second tier supplier being associated with an order request constraint that the first tier supplier is not associated with.

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

[0094] 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.

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

[0096] 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 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.

[0097] 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; for each requester of 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; The method includes:

[0098] EMBODIMENT 16 16. The method of claim 15, wherein the step of selecting the set of suppliers includes selecting a supplier from the set of 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] EMBODIMENT 20 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: causing each requester's mobile device to transmit its respective location to said 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; for each requester of 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; 2. A non-transitory computer readable medium for causing a computer to perform operations including:

[0103] EMBODIMENT 21 one or more processors; A memory for storing a set of instructions; wherein the one or more processors have access to the set of instructions. 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; 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.

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

[0105] 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.

[0106] 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.

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

[0108] 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 consolidated delivery orders.

[0109] 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.

[0110] 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.

[0111] EMBODIMENT 29 22. The network computing system of claim 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.

[0112] EMBODIMENT 30 22. The network computing system of claim 21, wherein the one or more processors determine the supply level indicator by detecting a number of requester devices that are executing a service application from which an order request can be made during a time interval immediately preceding the particular time interval.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] EMBODIMENT 34 33. The network computing system of claim 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.

[0117] 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; Including, 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.

[0118] 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 for batching based on a timing parameter.

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

[0120] 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.

[0121] 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.

[0122] EMBODIMENT 40 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: 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; Executing an operation including The non-transitory computer readable medium, 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.

[0123] EMBODIMENT 41 one or more processors; A memory for storing a set of instructions; wherein the one or more processors have access to the set of instructions. (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 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.

[0124] 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.

[0125] 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.

[0126] EMBODIMENT 44 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.

[0127] 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.

[0128] 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.

[0129] 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 within the particular area.

[0130] EMBODIMENT 48 The network computing system of embodiment 41, wherein (1) the service range parameter specifies a maximum travel distance from the supplier's location to the 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.

[0131] EMBODIMENT 49 1. A method for providing a delivery service, 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; modifying said set of delivery parameters to adjust said delivery level to a desired target value; The method includes:

[0132] 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.

[0133] 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.

[0134] 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.

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

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

[0137] 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.

[0138] 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.

[0139] EMBODIMENT 57 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: (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; modifying said set of delivery parameters to adjust said delivery level to a desired target value; 2. A non-transitory computer readable medium for causing a computer to perform operations including:

[0140] 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.

[0141] 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.

[0142] 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. [Explanation of symbols]

[0143] 100 Network Computing System 101 Order Request 102 Requester device 103 Requester information 104 Provider device 105 Requester Identifier 106, 116 Service Applications 107 Requester position 109 Service Information 110 Requester Device Interface 112 Menu Section 113 Provider position 115 Provider identifier 117 Product Information 118 Layer Logic 119 Menu Contents 120 Provider Device Interface 125 Supplier Records 126 Supplier Storage 127 Supplier Identifier 128 Request Handling Department 129 Supplier position 130 Supplier Interface 132 Requester status memory unit 133 Service Status 134 Provider status memory unit 135 Donor Records 136 Account Management Department 138 Packaging decision logic 150 Supply Subsystem 152 Supply Level Calculation Department 154 Prediction Department 155 Supply Level 156 Supply level adjustment unit 157 Predictions 158 Model Creation Department 159 History Information 165 Supply parameters 166 Optimization Logic 600 Computer Systems 610 Processor 620 Memory Resources 640 Storage device 650 Communication Interface 680 Network Connection 700 user devices 710 Communication Interface 718 User Input 720 display screen 730 Memory 732 Service Apps 740 Processor 742 Application Interface 745 Microphone 750 Camera 760 Satellite Receiver 780 Network

Claims

1. 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 includes the difference between the time each of the two or more order requests is ready at a particular supplier being less than a specified threshold.

3. 2. The network computing system of claim 1, wherein said supply level indicator is deemed to be indicative of a sudden increase in order demand in a recent time interval.

4. 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.

5. 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.

6. 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.

7. 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. 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.

9. 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.

10. 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:

11. 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.

12. 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.

13. 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