JP7348175B2 - computer system that performs network delivery services - Google Patents

Description

Related applications

This application is based on (1) U.S. Patent Application No. 15/802385 filed on November 2, 2017, (2) U.S. Patent Application No. 15/802391 filed on November 2, 2017, and ( 3) claims the benefit of each priority of U.S. Patent Application No. 15/802,394 filed on November 2, 2017, all of which are hereby incorporated by reference in their entirety; .

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

Numerous on-demand services exist, offering users a variety of services, including transportation, shipping, food delivery, groceries, pet care, assembled special teams, and more. On-demand services typically utilize resources available via a mobile device, such as a wireless (eg, cell phone) device. These mobile devices provide a platform for developers to access sensors and other resources available through the mobile device. Many on-demand services include specialized applications (sometimes called "apps") through which the on-demand service communicates with the network services provided.

According to some examples, a network computing system performs operations and arranges transportation services for delivery orders.

In some examples, the network computing system estimates supply levels for a particular time interval for one or more regions. The supply level calculation may be based on the estimated number of order requests and the number of available service providers within that particular area who are able to provide transportation to fulfill the order requests. For each request within that particular region, the computer system selects a set of suppliers for a supplier menu displayed on the requester's mobile device. The selection of a supplier for an individual 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. good.

In a variation, the network computing system (1) predicts each supplier's order preparation time for the order request, and (2) the arrival time of the matched service provider to each supplier is specified from the order preparation time. Generating a request to a service provider during a time interval prior to the order preparation time based at least in part on the determination that the order is within the threshold arranges transportation for the delivery order. Order delivery time to the requester may be estimated based at least in part on predicted order preparation time and estimated travel time from the supplier's location to the requester's location.

As used herein, customer equipment may include a desktop computer, cellular device or smart phone, wearable device, laptop computer, tablet device, capable of providing network connectivity and processing resources to communicate with the system over a network; Refers to devices compatible with televisions (IP televisions), etc. The driver device may correspond to specialized hardware, on-vehicle equipment, on-board computers, etc. The customer device and/or driver device may also operate designated applications configured to communicate with the system 100.

Although some of the examples described herein relate to transportation services, the system 100 can be used to arrange other on-demand location-based services (e.g., food truck services, delivery services, entertainment services) between individuals and service providers. can be made possible. For example, users can use the system to request on-demand services such as delivery services (e.g., food delivery, messenger services, food truck services, or product shipments) or entertainment services (e.g., mariachi band, string quartet). ,This system can select service providers such as drivers, food ,bands, etc. and provide on-demand services to users.

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

One or more embodiments described herein may be implemented using program modules, engines, or components. A program module, engine, or component may include a program, subroutine, portion of a program, or 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 another module, program, or machine.

Some embodiments described herein may typically require the use of computing equipment, including processing and memory resources. For example, one or more embodiments described herein may be applied, in whole or in part, to computing devices, such as servers, desktop computers, mobile phones or smartphones, tablets, wearable electronic devices, laptop computers, printers, digital image frames, etc. , network equipment (eg, routers), and tablet devices. All memory, processing, and network resources may be used in connection with establishing, using, or implementing any of the embodiments described herein (including performing any method or implementing any system). good.

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

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

FIG. 1 illustrates an example network computing system for arranging transportation of delivery orders in accordance with one or more embodiments. According to embodiments, network computing system 100 provides network delivery services that can be utilized by requesters, suppliers, and service providers. Network computing system 100 may be implemented on a server, a combination of servers, and/or a distributed set of computing devices that communicate over a network, such as the Internet. Additionally, some examples provide that network computing system 100 is distributed using one or more servers and/or mobile devices. In some variations, network computing system 100 is implemented as part of or in connection with a network system in which, for example, operators provide point-to-point transportation-related services using service vehicles. In variations, network computing system 100 may be implemented using mobile devices of users, including service providers and requesters, where individual devices serve as information entry points and/or information entry points for network computing system 100. or run the corresponding service application to act as an exit.

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

Referring to the example of FIG. 1, the system 100 includes a requestor device interface 110, a provider device interface 120, a request handler 128, a supplier interface 130, a matcher 140, and information regarding requesters, order requests, and providers. One or more data stores to be updated. System 100 may also include a feeding subsystem 150 that allows system 100 to adjust feeding levels of system 100.

As discussed in some examples, the supply subsystem 150 provides information about the system 100 with respect to actual or anticipated requests from requesters during a particular time period and with respect to a particular region (e.g., a city or portion of a city). Allows supply levels to be estimated or otherwise confirmed. Supply subsystem 150 may also be utilized to adjust supply levels with respect to how system 100 provides network services to arrange transportation of delivery orders. In particular, the provisioning subsystem 150 may make adjustments to the confirmed provisioning level of network services in a manner that is optimized for the purposes of the provided network services. In this way, various aspects of the network service provided can be adjusted in response to fluctuations in the volume of requests from requesters, for example to maximize the number of order requests that can be effectively handled in a particular length of time. It can be done. Optimizations that may be performed over network services may also be performed at a group level to objectively accommodate the interests of service providers, suppliers, and requesters.

Requester device interface 110 includes or executes processes that operate on the network side of system 100 to establish communication channels with individual devices of requesters. The requester may operate a mobile device (represented by mobile device 104 in FIG. 1) on which a corresponding service application 106 may operate. Requesters operate their respective service applications 106 to provide delivery services and, in some variations, other types of transportation-related services, such as transportation between a starting point (or pick-up point) and a destination (or drop-off point). You may request transportation. When service application 106 is launched on requester device 102 , requester device 102 may send requester information 103 to system 100 . 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 to a satellite receiver or other location-aware resource of the requester device 102. Requester information 103 may also be communicated along with order request 101, as described in more detail. 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.

According to some examples, provider device 104 initiates communication with system 100 using service application 116. The service application 116 may correspond to a program (eg, a set of instructions or code) downloaded and stored on the service provider's mobile device 104. A service provider may launch a service application 116 to utilize system 100 to receive order requests and/or other types of service requests (eg, transportation requests). Service providers may operate service vehicles to fulfill assigned service requests. Once a communication channel is established by provider device 104 using service application 116 , provider device 104 may repeatedly or continuously communicate service information 109 to 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 to a satellite receiver of the provider device 104.

Provider device interface 120 includes or executes processes that operate on the network side of system 100 to establish communication channels with the service provider's individual devices. For example, device interface 110 can establish secure sockets with different types of mobile devices that service providers of system 100 can utilize when providing services using their respective vehicles. In some examples, a service provider operates a mobile device (represented by mobile device 104 in FIG. 1) on which a corresponding service application 116 may be running. Among other functions, service application 116 performs operations including communicating information including provisioning decisions to system 100 for various purposes, as well as indicating the availability of service providers offering services. communication from the system 100 to enable the service provider to receive and fulfill order requests; Can receive information.

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. By way of example, each service provider may operate the service application 116 (e.g., open an application on the provider's device 104) and then switch the status feature provided by the service application 116 to "on duty" to indicate the working hours. You may start. Service application 116 communicates activation of status features to system 100 via provider device interface 120 . Provider device interface 120 processes service information 109 received from 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 in the provider status storage 134 along with the provider's identifier 115. When the service provider's location changes (e.g., with movement of the service provider's vehicle), subsequent communications from the provider device 104 via the provider device interface 120 are used to update the provider status store 134. It can be done. In this way, the provider data storage unit 134 may reflect the latest current location of each service provider.

In some examples, the requester device interface 110 and the provider device interface 120 each include or use an application programming interface (API), such as an external facing API, to provide data to the provider device 102 and the requester, respectively. communication with the user device 104. By providing an externally facing API, the system 100 can provide a secure communication channel over a network in any number of ways via a secure access channel, such as web-based formats, programmatic access via RESTful APIs, simple object - Can be established using access protocol (SOAP), remote procedure call (RPC), script access, etc.

Supplier interface 130 may correspond to a program interface that transmits order requests from requesters to supplier terminals. In the context of food delivery, supplier interface 130 sends the delivery order to the supplier's computer system (eg, pre-order system, point of sale equipment, dedicated to-go terminal, etc.). In some examples, a supplier may operate a mobile device equipped with a service application for the supplier to receive order requests from system 100. Suppliers may access system 100, for example, via a website or application interface (eg, a supplier services application), to accept order requests and provide information regarding the readiness of order requests. Suppliers may also access system 100 to provide menus or descriptions (including text and images) of items available for delivery.

System 100 may maintain a supplier library 126 containing records 125 for each supplier. Each supplier record 125 may associate a supplier with an account identifier 127 in addition to a supplier location 129 and a set of deliverable items 131 provided by that supplier. Suppliers may specify items 131 via supplier interface 130 . Supplier item 131 may be provided as an electronic document or a combination of records provided by a supplier that may be retrieved and presented on requester device 102, for example in the form of a menu. By way of example, supplier items 131 may include a restaurant menu or items for a restaurant menu.

According to some examples, when a requester launches service application 106, requester device 102 provides system 100 with the requester's current location 107. In some variations, the requester may 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's specified service point) to the menu portion 112, which displays item information representing the supplier's selection of deliverable items 131. The requester's current location may be used to retrieve 117 from supplier library 126. Requester device interface 110 may communicate menu content 119 to requester device 102 via service application 106 . As explained in some examples below, the menu content 119 also includes one or more service value parameters indicating the fee or consideration that the requester would incur to receive delivery of the requested item from the supplier. 171 may be transmitted. The user may view the list of suppliers and scan the menu contents 119 to see the deliverable items each available supplier has. Immediately after making a selection for a delivery order, service application 106 causes requestor device 102 to send order request 101 to system 100.

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

Order request 101 may be received by requester device interface 110 and recorded in requester status storage 132 . In some examples, requester device interface 110 and menu portion 112 may implement geographic constraints on individual requesters based on service coverage parameters 169. Service range parameter 169 may specify the distance (e.g., travel distance) from the desired order request service point that available suppliers may be made available to the requester for the purpose of the order request. good. 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 portion 112 may include a filter to exclude suppliers that are outside the distance specified by the range parameter 169. May be executed. In this manner, service application 106 running on requester device 102 is not provided with menu content 119 indicating deliverable items from suppliers outside of range parameter 169.

Additionally or alternatively, range parameter 169 may be used to establish tiers among suppliers with respect to service points for a particular order request 101. Menu portion 112 may implement tier logic 118 that establishes alternative order request rules for suppliers based at least in part on tier designations assigned to individual suppliers, for example. Tier logic 118 may assign a tier designation based in part on the supplier's location relative to the service point of the order request. Based on implementation, 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 specifications. Additionally or alternatively, tier logic 118 may use one or more service value parameters 171 to determine different service values for deliveries from different suppliers based on the supplier's tier designation for the service point.

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

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

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

In some examples, the request handler 128 matches the corresponding order request with a service provider and determines that the preparation time is greater than the estimated length of time for the matched service provider to arrive at the supplier. This may be determined from the estimated order time of the item and/or supplier. In such an example, the request handler 128 may delay sending the message 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. It's okay. In such an example, the delay in sending correspondence 139 for order request 101 falls within the estimated time window for the matched service provider to arrive at the supplier's location. It may be designed as follows.

Matching unit 140 may match order request 101 with available service providers based at least in part on the current location of each provider relative to the provider's location. In some variations, matcher 140 may also match order requests 101 based on the supplier's desired time of arrival at the supplier. 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.

In some examples, request handler 128 may select and execute batch decision logic 138 to implement rules and parameters that determine when delivery orders can be batched. Bulkling refers to cases where the service provider handles two delivery orders. Collective decision logic 138 may aggregate according to one or more sets of rules and/or parameters. Decisions can be made programmatically from these rules and parameters. The bundling decision logic 138 may vary so that it may be utilized to determine when different rules, parameters, and/or parameter values can be lumped together. In particular, the consolidation decision logic 138 implements alternative rules that determine (1) whether consolidation is possible under any circumstances, and (2) if consolidation is possible, the conditions under which multiple delivery orders may be consolidated. You may. By way of example, conditions that may determine or influence a consolidation decision include (1) the same supplier condition that consolidation of delivery orders is allowed if the delivery orders are prepared by the same supplier; (2) (3) timing conditions that may establish time windows regarding when multiple order requests may be prepared and/or delivered to each other before consolidation is allowed; (3) regarding each supplier's location and/or delivery point; (4) supply level calculation 155 determines or influences the bundling decision; and/or (4) supply level calculations 155 permit bundling of delivery orders if the delivery orders are prepared by suppliers that meet the geographic conditions. may include supply conditions that the

With respect to supply conditions, some examples provide that consolidation may be maximized with respect to being allowed, eg, if an inadequate number of service providers are present to handle the order request. Conversely, if there are too many service providers, bundling may be minimized as separate service providers may be used to deliver orders that might otherwise be lumped together.

With respect to timing conditions, some examples provide that consolidation decision logic 138 utilizes timing parameters 167 determined by supply subsystem 150 to determine when delivery orders are allowed to be consolidated. For example, request handler 128 may utilize one or more timing parameters 167 to minimize wait time while a service provider is at a supplier. For example, in a food preparation situation, if the service provider's arrival time is longer than the time the food is 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 be waiting and therefore underutilized. The request handler 128 may include logic to initiate the matching process during a time window prior to the expected preparation time of the requested delivery order, such that the assigned service provider It will arrive at the supplier's location at the time it is prepared and available for pickup. FIG. 5 illustrates an example method that may be performed, for example, by request handler 128, to control selection of a service provider based at least in part on determining an optimal arrival time.

In a variation, the bundling decision logic 138 allows delivery orders to be batched so that they can be delivered from the same supplier by a particular service provider to multiple recipients at different locations within a predetermined time limit. If so, you may allow it. The predetermined time limit may be, for example, an order preparation time (or order collection time) and/or an order delivery time. For example, one or more timing parameters 167 may set limits on when the last consolidated order can be picked up and/or delivered, delivery order preparation time and/or order request time (e.g., when order request 101 is made). It may be set based on. Additionally or alternatively, timing parameter 167 may establish a comparable time window between each pick-up or delivery time of the bundled delivery orders. In variations, other timing parameters 167 may control when delivery orders from particular suppliers may be bundled.

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

Once the matching unit 140 selects a provider for the order request 101, the request handling unit 128 can monitor the provider via updating the provider location (eg, maintained in the provider status storage unit 134). In particular, the request handler 128 can track the supplier to the supplier and from the supplier to the point of service of the order request 101. The status of the requester's order request is repeatedly updated by the request handling unit 128 in the requester status storage unit 132, and is updated based on events such as (1) the order request 101 being communicated to the supplier, and (2) the supplier receiving the order request. (3) one or more progress indications of the order request have been provided, including when the corresponding delivery order is ready; (4) the service provider has picked up the corresponding delivery order; (5) proceeding to the service point specified in the service provider's order request; and/or (6) providing service to the requester's service point (e.g., the requester's current location or specified point). It may also indicate the arrival of a person.

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, the estimated delivery time is first anticipated before the requester places the order request 101. When the order request 101 is processed by the supplier, the delivery time may be updated for the requester. Similarly, delivery times may be updated when matching unit 140 identifies a service provider and while request handler 128 tracks the service provider from pickup to the point of delivery order.

Similarly, the matcher 140 (and/or the request handler 128) may change the relevant status of the service provider, such as to indicate one or more unavailability statuses. For example, the status of the service provider may include available, assigned to an order request, on the way to the supplier, at the supplier, on the way to the requester, and completing the order request.

Request handler 128 may activate account manager 136 as soon as it is detected that the service provider has completed the delivery service. Account management unit 136 may record fulfillment of order requests with respect to service provider, supplier, and requestor accounts. In some examples, a fee or consideration is withdrawn from the requester's account for the obtained delivery. Similarly, 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 parameter 171 of the fulfilled order request 101.

According to some examples, supply subsystem 150 includes a supply level determination (“PLD”) unit 152, a prediction unit 154, and a supply level adjustment (“PLA”) unit 156. The PLD unit 152 can estimate the supply level for a particular region during the current time interval or for a future time interval based on forecast information from the forecast unit 154. Supply level 155 may reflect an assessment of the adequacy of the number of service providers to the number of service requests to be serviced in a particular time interval. Predictor 154 may generate predictions for one or more aspects of supply level determination. For example, predictor 154 can predict the number of service requests that system 100 will receive over the next time interval or during future time intervals. Predictor 154 may also predict or otherwise estimate the number of service providers that are (or will be) available to fulfill order request 101 in a particular region. PLA unit 156 may execute logic to adjust supply level 155 of system 100 to optimize for one or more service objectives of system 100.

The supply subsystem 150 may utilize a variety of models 153, including a predictive model 153A and/or an optimization model 153B. By way of example, predictive model 153A may include a tree-based model, a deep learning model, a neural network model, and/or a regression model. By way of example, the predictive model 153A predicts supply level calculations (e.g., number of order requests, conversion rate of requesters operating the service application without placing orders, etc.) and timing predictions (e.g., order preparation time). may be generated and trained as follows. The optimization model 153B includes, for example, convex and non-convex models, and may combine a plurality of guidance optimization models.

In some examples, the model creator 158 may, for example, train and train the model over time using real-time information (e.g., from the requester context store 132 and/or the provider context store 134) and historical information 159. Models 153A, 153B are created using a tailored machine learning process.

In some examples, model creator 158 may create one or more models 153 for use by supply subsystem 150. Supply model 153 may include a conversion model that allows forecaster 154 to use real-time information to generate a forecast 157 of the number of order requests. The conversion model may utilize input real-time information corresponding to the number of active requesters who have not yet placed an order request, obtained from the requester status store 132, for example. In variations, modeler 158 analyzes historical information 159 (e.g., previous snapshots of requester status storage 132 from a previous time period) to determine whether (1) the requester is using service application 106 on his or her device 102; (2) an active requester session event consistent with initiating a session with the system 100 by invoking an active requester; and (2) a diversion event consistent with an active requester requesting an order. Other information that may be discovered from analysis of historical data may include, for example, the length of time that conversion events occur for each individual requester and the suppliers viewed by active requesters. Model generator 158 may also record the occurrence of events (eg, active requester session events, diversion events) over successive time intervals. For example, model generator 158 may include input parameters that reflect velocity values (or acceleration values or other derivatives thereof) with respect to the number of order requests, the number of active requesters, and/or the number of converted requesters. You may use it.

Additionally or alternatively, modeler 158 may also create predictive models for use in predicting delivery requests for future time intervals for which no relevant real-time information yet exists. The model creation unit 158 creates such a predictive model 153 using historical information, e.g., by statistical analysis, to determine the number of active requesters that are likely to be online during a particular time interval, the number of active The conversion rate of requesters in a region and/or the number of order requests likely to be generated from users in a region may be predicted.

When creating conversion or other predictive models, modeler 158 may also specify context information. For example, model creator 158 may associate historical information with days of the week, times of day, months of the year, events (eg, sporting events), weather, and other related information.

Predictor 154 utilizes model 153 created by modeler 158 to make one or more predictions 157 (e.g., of a particular length) regarding requests during the current time interval and/or one or more future time intervals. number of order requests that may be received during the time period). According to one example, the prediction unit 154 is configured to predict the number of order requests that may be received in the current (e.g., over the next hour) or near future time interval (e.g., over the next four hours). Then, real-time information is acquired from the requester status storage unit 132. Real-time information may include, for example, the number of active requesters who have not yet placed an order request, the amount of time each active requester spent viewing the menu content 119 of an individual supplier, and/or the number of active requesters who have not yet placed an order request. It may also include the suppliers viewed (eg, the supplier's menu). Based on the real-time information, the predictor 154 predicts the number of order requests (e.g., the next four The number of service requests that are likely to be received in one time slot may be predicted. Additionally or alternatively, forecaster 154 may also utilize model 153 created by modeler 158 to estimate the number of order requests that system 100 is expected to receive in future time intervals. For example, the model generator 158 may generate a schedule indicating the expected number of order requests for time slots of an upcoming future time interval (eg, an hourly order request forecast for each day of an upcoming week).

According to some examples, the modeler 158 may also compare the predictions 157 of the predictor 154 regarding the number of order requests received (or the number of active requesters, etc.) with the actual results. The requester status storage unit 132 may also be monitored. Based on the comparison, model generator 158 may adjust model 153 used by predictor 154.

In some variations, model generator 158 may develop and implement predictive models regarding timing-related characteristics of individual suppliers. Modeler 158 may monitor requestor context store 132 to determine statistical samples of one or more timing-related characteristics of individual suppliers. As an example, timing-related characteristics of a supplier may match the lead time for the supplier to prepare a delivery order. As another example, timing-related characteristics may refer to the amount of time a service provider typically spends arriving at a supplier and leaving with a delivery order. In this manner, modeler 158 obtains a data point of the length of time it takes a supplier (eg, restaurant) to prepare food items for a delivery order. Timing-related characteristics may be associated with a supplier and a corresponding supplier record 125.

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

PLA section 156 may use a set of feed parameters 165 based on feed level 155. Provisioning parameters 165 may define parameter values for use with network delivery service rules, processes, or other logic. Additionally, provisioning parameters 165, when changed, generally affect the provisioning level of network services according to known relationships. According to some examples, the change in the supply parameters increases or decreases the number of service requests (e.g., order requests) that network computing system 100 may handle based on a known or expected relationship with the change in the supply parameters. Sometimes. Supply parameter 165 may be a default value, for example, when supply level 155 is neutral (e.g., expected number of order requests matches available service providers) or otherwise a desired value. Good too. When the feed level fluctuates away from a neutral or desired level, the PLA section 156 may adjust the value of the feed parameter 165 to adjust the feed level 155.

Supply parameters 165 may affect various aspects of the delivery service performed by system 100. Thus, for example, PLA unit 156 may utilize multiple sets of supply parameters based on the subregion or region of interest. According to examples, the provisioning parameters 165 reflect aspects or aspects of the service provided by the system 100 that may be adjusted to cause anticipated changes in the provisioning level 155 of the provided service. In particular, the values of individual feeding parameters 165 may be based on optimization decisions for one or more goals of system 100. Optimization decisions may be made by executing one or more optimization processes (shown as optimization logic 166) that optimize aspects of the supply level for a particular service objective 161. System 100 may achieve one or more service objectives 161, such as maximizing the number of order requests handled in a particular length of time, or minimizing the delivery time of received order requests. . Accordingly, the values of feed parameters 165 may be determined by the particular goal or set of goals of the selected optimization process.

According to some examples, the relationship between individual feed parameters 165 and feed levels 155 may also be predetermined or otherwise known. For example, adjusting the value of a particular one of the supply parameters 165 may have a positive impact on increasing the number of service requests handled by the system 100, while at the same time negatively impacting another goal of reducing order request service times. may be known. The modeler 158 may establish a relationship between the value of the individual supply parameter 165 and the influence of the supply parameter value on the supply level 155, for example for a particular region or time interval. Those relationships can be granular (e.g., a change in a supply parameter will increase the number of service requests that the system 100 can handle) or more precise (e.g., a change in a supply parameter will have a percentage impact on the conversion rate (e.g., a change in a supply parameter will increase the number of service requests that the system 100 can handle) %).

By way of example, provisioning parameters 165 include one or more of timing parameters 167 , service scope parameters 169 , and service value parameters 171 . One or more timing parameters 167 may reflect a target time interval or time constraint (eg, a maximum allowed time interval) by which a particular event in fulfillment of an order request must occur. For example, the timing parameters 167 may include (1) delivery time (e.g., from the time the order request 101 is placed until the order is delivered to the requester), (2) latency experienced by the service provider, e.g. (3) the time interval between arrival and departure from the service provider; (3) the time interval between the preparation and pickup of a delivery order; and/or (4) the time interval between the preparation and delivery of a delivery order. A target time or time constraint for one or more of the intervals may be reflected. According to some examples, when one or more timing parameters 167 are relaxed, request handler 128 processes more order requests because the amount of time multiple order requests can be matched together increases. can be done in bulk.

The service range parameter 169 may reflect a range, such as a travel or absolute distance, between the supplier's location and the service point of the order request. In some examples, service range parameter 169 may be expressed as a travel distance that reflects the travel time and/or distance from the supplier's location to the service point of the order request. Service scope parameter 169 may be used by menu portion 112 to identify which suppliers in supplier store 126 may be used for menu item 131, for example. The menu unit 112 may inquire of the supplier storage unit 126 about the supplier located at the position 129 that satisfies the proximity condition regarding the requester's current position 107. This neighborhood condition is based on the service range parameter 169. By increasing the value of scope of service parameter 169, menu portion 112 may select more suppliers and include items 131 from those suppliers in creating menu content 119 on requester device 102. May be used. Conversely, by decreasing the value of scope of service parameter 169, menu portion 112 may select fewer suppliers and use items from those suppliers to create menu content 119 for requester device 102. 131 can be used. Since requesters are more likely to submit order requests 101 when more options are available, increases or decreases in the number of suppliers offered to individual requesters can affect the number of order requests 101 that the system receives. . For example, by increasing service scope parameter 169, supply subsystem 150 may anticipate 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 to generate more service requests than usual for the service provider. To meet service level objectives (e.g., a greater number of order requests fulfilled by system 100), optimization logic 166 considers constraints such as additional cost to the service provider to value service range 169. You may adjust the balance.

Service value parameter 171 may reflect the service value charged to the requester as part of the delivery order. As illustrated in various examples, service value parameters 171 may depend on factors such as the distance a service provider travels to fulfill a service order, supplier tier designation, and/or service provider availability. It may vary accordingly. In some examples, service value parameter 171 may be used to adjust the number of available service providers during a particular time interval. For example, the service value parameter 171 may also be utilized by the account manager 136, which can 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 be able to handle an unexpected number of order requests for a particular region, the service value parameter 171 may be increased to accommodate order requests in that particular region. May reflect greater value and reward for the helping service provider. As illustrated by the example of FIG. 1, service value parameters 171 may be communicated to provider device interface 120 from which service values may be exposed to nearby providers. Provider device interface 120 may also expose increases in service value parameters 171 to attract more service providers. Thus, changes in service value parameters 171 may increase or decrease the number of service providers working in a particular area.

FIG. 2 illustrates an example method for identifying suppliers for delivery services to individual requesters. FIG. 3 illustrates an example method for arranging transportation of multiple delivery orders. FIG. 4 illustrates an example method for arranging transportation of delivery orders in a manner that affects the supply level of services provided. FIG. 5 illustrates another example method for arranging transportation of delivery orders to minimize service provider wait time. When describing the example of FIGS. 2-5, components of the example of FIG. 1 will be described for the purpose of illustrating suitable components for performing the steps or substeps being described.

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

Once the session is initiated, network computing system 200 sends information (eg, menu content 119) to identify suppliers (eg, restaurants) within a specified range of the requester (220). A supplier may be identified by providing a supplier menu to the requester device. The requester may view menus from multiple providers within a specified service range relative to the requester's current location. The specified range may reflect a movement threshold distance between the supplier's location and the requester's current location. In some examples, the specified range for a particular region may be based at least in part on a supply level calculation (222) (e.g., based on an estimated number of order requests and available service providers). comparison of numbers). For example, as described in the example of FIG. 169. Accordingly, system 100 may modify the specified service scope so that more or fewer suppliers are available to a particular requester. As range increases, system 100 may also adjust other parameters, such as service value 171, based on known or predicted relationships between service parameter value changes and supply level 155 (e.g., service provide additional incentives for the provider to drive additional distance).

Additionally or alternatively, in some examples, supplier selection 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 supplier displayed on the mobile device based on the requester's updated location.

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

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

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

According to some examples, system 100 executes the first decision logic to determine the plurality of delivery orders for delivery to respective requesters based on the plurality of delivery orders that meet at least a first timing criterion. may be grouped together (342). As described in the various examples, the timing criteria may be parameterized (eg, timing parameters 167) and may be changed based on conditions such as provided by supply level markers and calculations. As an example, system 100 may relax timing parameter 167 to provide additional time for matched delivery orders to be generated.

In various examples, the timing criteria may be based on, for example, delivery times (eg, different delivery times for each of multiple delivery orders that are combined). In other examples, the timing criteria may match the latency experienced by the service provider as measured by the interval between when the service provider arrives and when the service provider leaves the supplier's location. 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 match the time interval between when a delivery order is prepared and when it is delivered. According to some examples, when one or more timing parameters 167 are relaxed, request handler 128 may batch more order requests because the amount of time order requests can be matched to each other increases. Can be done.

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

The network computing system calculates a prediction of expected service requests received in the current or next time interval for a particular region (420). In some examples, predictions may be calculated from models that utilize real-time information. For example, model generator 158 accesses requester data storage 132 and calculates the number of active requesters who have started a session with system 100 but have not yet placed a delivery order.

System 100 calculates a supply level 155 for a particular region during an immediate time interval based at least in part on the forecast (430). Based on the prediction, system 100 makes a decision as to whether to adjust any of the set of feed parameters 165 to change the feed level to the desired target value (440). Accordingly, system 100 may change the value of feed parameter 165 to adjust determined or predicted feed level 155. For example, service value 171 may be changed, for example to increase the number of service providers. Similarly, service coverage 169 may be increased or decreased to increase or decrease demand (eg, conversion rates increase as requesters have more options).

In some examples, the provisioning parameters are adjusted according to one or more optimization processes based on service level objectives (442). Service level objectives may be, for example, maximizing the number of service requests processed over a specified period of time, minimizing the distance traveled by a service provider, and/or minimizing the wait time for a requester's delivery order. It may be consistent with the

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

System 100 may attempt to select a service provider during a time interval immediately preceding the expected order preparation time (520). The matching unit 140 is activated, for example, by the request handling unit 128 to generate a request that identifies a service provider that is assigned to travel to the supplier and can arrive at a time within a margin window from the predicted order preparation time. (522). In some examples, a determination is made whether the order request can be immediately matched with a service provider (525). Once 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). System 100 may continue to monitor and update the requester through each stage of the delivery order.

If matching unit 140 cannot immediately find a matching service provider for the order request, the process may repeat 520. Request handler 128 may restart matcher 140 at another time interval to find a match for the order request. The process may be repeated for the time interval immediately preceding the expected order preparation time. As the window for matching an order request with a service provider becomes smaller, the region that the matcher 140 attempts to match becomes closer to the supplier's location.

FIG. 6 illustrates a computer system on 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. Additionally, computer system 600 can perform methods such as those described in the examples of FIGS. 2-5.

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

Communication interface 650 enables computer system 600 to communicate with one or more networks (eg, a cellular network) using network connection 680 (wireless or wired). Using network connection 680, 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 memory 630 may include instructions 642 to implement a network computing system such as that described in the example of FIG. The executable instructions stored in memory 620 may also perform methods such as those described in one or more of the examples of FIGS. 2-5.

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

FIG. 7 is a block diagram illustrating an example user device for use with the described embodiments. In one example, user device 700 may execute a designated service application for a network service implemented by network computing system 100 as described in the example of FIG. In many embodiments, user device 700 may include a mobile computing device, such as a smartphone, a tablet computer, a laptop computer, a VR or AR headset device, etc. As such, the user device 700 includes typical telephone and/or tablet features, such as a microphone 745, a camera 750, a satellite receiver 760, and communication devices that communicate with external entities using any number of wireless communication protocols. An interface 710 may be included. In some aspects, user device 700 can store a specified application (eg, service app 732) in local memory 730. In variations, memory 730 can store additional applications executable by one or more processors 740 of user device 700 to enable access and interaction with one or more host servers over one or more networks 780. .

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

Although embodiments are described in detail herein with reference to the accompanying drawings, it is to be understood that the concepts are not limited to those precise embodiments. It is therefore intended that the scope of such concepts be defined by the appended claims and their equivalents. Also, specific features described individually or as part of an embodiment may be used to refer to those other individually listed features or It is contemplated that it may be combined with some of the other embodiments. Therefore, the lack of a description of a combination should not preclude having rights to such a combination.
Preferred embodiments of the present invention will be described below.
Embodiment 1
one or more processors;
A memory that stores a set of instructions and
a network computing system comprising: the one or more processors accessing the instructions;
causing each requester's mobile device to transmit their respective locations to the network computing system;
The number of order requests received by (1) the network computing system for a particular time interval, where each order request originates from a requester in a particular region and is matched among a plurality of suppliers in said particular region; (2) the number of available service providers within said particular area that are capable of providing transportation to fulfill said order requests; Estimate,
For each requester of the total population, at least one of the location of the requester's mobile device and the estimated number of order requests or the estimated number of available service providers; A network computing system that selects a set of multiple suppliers for the requester's supplier menu based in part.
Embodiment 2
The one or more processors select a supplier of the set of multiple suppliers for each of the individual requesters at least a distance traveled between the supplier and the location of the requester. The network computing system of embodiment 1, selecting based in part.
Embodiment 3
3. The network 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 and a number of available service providers. calculation system.
Embodiment 4
4. The network computing system of embodiment 3, wherein the one or more processors repeatedly update the threshold of the travel distance.
Embodiment 5
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. , the network computing system according to Embodiment 2.
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. .
Embodiment 7
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. , the network computing system described in Embodiment 6.
Embodiment 8
9. The network computing system of embodiment 7, wherein the real-time information includes a count of the number of mobile devices where a service application is running and no corresponding service request from the mobile device is pending.
Embodiment 9
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 access the instructions for each requestor of the population. 2. The network computing system of embodiment 1, wherein the plurality of suppliers is selected based at least in part on a predetermined sub-region that matches a current location of a requester.
Embodiment 10
For each requester of the entire population, the one or more processors select the set of multiple suppliers to include a first tier supplier and a second tier supplier; The network computing system of embodiment 1, wherein a second tier supplier is associated with an order request constraint that the first tier supplier is not associated with.
Embodiment 11
11. The network computing system according to embodiment 10, wherein the order request constraint is an order size.
Embodiment 12
For each requestor of the entire population, the one or more processors may at least partially identify suppliers of the selected set to the second tier, the location of the suppliers, and the requestor. 11. The network computing system of embodiment 10, wherein the network computing system determines based on
Embodiment 13
2. The network computing system of embodiment 1, wherein the one or more processors cause the provider menu to be displayed on a respective mobile device of the individual requesters.
Embodiment 14
The one or more processors monitor the location of a mobile device of an individual requester of the entire population and select the set of multiple suppliers for the requester's supplier menu from the requester's 2. The network computing system of embodiment 1, wherein the reselection is based at least in part on a location of the requester's mobile device after the location of the mobile device changes.
Embodiment 15
A method for fulfilling an order request, the method being performed by one or more processors, the method comprising:
causing each requester's mobile device to transmit its respective location to the network computing system;
The number of order requests received by (1) said network computing system for a particular time interval, with each order request originating from a requester in a particular region and being matched among a plurality of suppliers in said particular region; (2) the number of available service providers within said particular area that are capable of providing transportation to fulfill said order requests; a step of estimating
For each requester of the entire population, at least a portion of 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; selecting a set of a plurality of suppliers for the requester's supplier menu based on the
method including.
Embodiment 16
The step of selecting the set of multiple suppliers includes selecting a supplier from the set of multiple suppliers for each of the individual requesters based on the location of the supplier and the requester. 16. The method of embodiment 15, comprising selecting based at least in part on distance traveled between.
Embodiment 17
Selecting the set of multiple suppliers determines the travel distance threshold based at least in part on a comparison of the estimated number of order requests and the number of available service providers. 17. The method of embodiment 16, comprising:
Embodiment 18
16. The method of embodiment 15, wherein the estimating step includes predicting each of the number of order requests and the number of available service providers for an upcoming time interval.
Embodiment 19
Embodiments wherein the step of selecting the set of multiple suppliers determines the travel distance threshold based on a comparison of the predicted number of order requests and the predicted number of service providers. 18. The method described in 18.
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 the network computing system;
causing individual requestor mobile devices to transmit their respective locations to the network computing system;
The number of order requests received by (1) said network computing system for a particular time interval, with each order request originating from a requester in a particular region and being matched among a plurality of suppliers in said particular region; (2) the number of available service providers within said particular area that are capable of providing transportation to fulfill said order requests; a step of estimating
For each requester of the entire population, at least a portion of 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; selecting a set of a plurality of suppliers for the requester's supplier menu based on the
A non-transitory computer-readable medium that performs operations on a non-transitory computer-readable medium.
Embodiment 21
one or more processors;
A memory that stores a set of instructions and
a network computing system comprising: the one or more processors accessing the instructions;
receiving a plurality of order requests, each order request originating from a corresponding one of the plurality of requestor devices and specifying a supplier of the plurality of suppliers;
for each of the plurality of order requests, selecting a service provider from a set of available service providers and transporting the corresponding delivery order from the corresponding supplier to the requester;
determining a supply level indicator for a particular region at a particular time interval by communicating with a plurality of requestor devices and a plurality of provider devices;
The one or more processors execute decision logic based at least in part on the determined supply level indicator to determine whether each delivery order generated in response to a respective order request is delivered to a respective requestor. A network computing system that selects the service provider for each of the plurality of order requests by determining whether the orders can be bundled for delivery.
Embodiment 22
Embodiment 21, wherein the decision logic includes at least first decision logic that bundles multiple delivery orders for delivery to respective requesters based on the multiple delivery orders meeting at least a first timing criterion. The described network computing system.
Embodiment 23
23. The network computing system of embodiment 22, wherein the at least first timing criterion includes a difference between when each of the delivery orders is ready at a particular supplier is less than a specified threshold.
Embodiment 24
23. The network computing system of embodiment 22, wherein the at least first timing criterion includes an estimated time of delivery of each of the plurality of orders being less than a predetermined limit.
Embodiment 25
23. The network computing system of embodiment 22, wherein the at least first timing criterion includes a travel distance between requester locations of each of the plurality of orders being less than a specified threshold.
Embodiment 26
23. The first decision logic is less restrictive than at least the second decision logic, such that when the one or more processors execute the first decision logic, more consolidated delivery orders result. network computing system.
Embodiment 27
Each of the first decision logic and the second decision logic, when executed, dispatches the plurality of delivery orders to respective requesters based at least in part on the plurality of delivery orders that meet at least one timing criterion. 27. The network computing system of embodiment 26, wherein the first decision logic timing criteria is based on a longer length of time compared to the second decision logic timing criteria.
Embodiment 28
22. The network computing system of embodiment 21, wherein the supply level indicator is considered to indicate a sudden increase in order requests in a recent time interval.
Embodiment 29
The one or more processors determine the supply level indicator by detecting a number of requestor devices that launch a service application from which an order request may be made in a time interval immediately preceding the particular time interval. The network computing system according to Form 21.
Embodiment 30
The one or more processors determine the supply level indicator by detecting the number of requestor devices running a service application from which order requests may be made in a time interval immediately preceding the particular time interval. , the network computing system according to embodiment 21.
Embodiment 31
The one or more processors determine the supply level by estimating at least one of a number of order requests and a number of available service providers in a time interval immediately preceding the particular time interval for the particular region. , the network computing system according to embodiment 21.
Embodiment 32
The one or more processors access the instructions to calculate an arrival time for a service provider of the bundled set of delivery orders to arrive at the supplier of the bundled set of delivery orders. , the network computing system according to embodiment 21.
Embodiment 33
33. The network computing system of embodiment 32, wherein the one or more processors assign a service provider to the consolidated set of delivery orders based at least in part on the calculated arrival time.
Embodiment 34
33. 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. Network computing system.
Embodiment 35
A method for fulfilling an order request, the method being performed by one or more processors, the method comprising:
selecting a service provider from the set of available service providers for each of the plurality of order requests and transporting the corresponding delivery order from the corresponding supplier to the requester;
determining a supply level indicator for a particular region at a particular time interval by communicating with a plurality of requestor devices and a plurality of provider devices;
including;
Selecting the service provider consolidates 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. A method, including steps.
Embodiment 36
36. The method of embodiment 35, wherein the step of bundling multiple delivery orders includes selecting at least two delivery orders to batch based on a timing parameter.
Embodiment 37
37. The method of embodiment 36, wherein determining the timing parameter is based at least in part on the determined supply level.
Embodiment 38
37. The method of embodiment 36, wherein the timing parameter sets a time limit for each delivery order of a plurality of consolidated delivery orders being delivered to a corresponding location of a corresponding order request.
Embodiment 39
36. The method of embodiment 35, wherein determining the supply level indicator includes predicting the supply level indicator for an immediate time interval.
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 the network computing system;
selecting a service provider from the set of available service providers for each of the plurality of order requests and transporting the corresponding delivery order from the corresponding supplier to the requester;
determining a supply level indicator for a particular region at a particular time interval by communicating with a plurality of requestor devices and a plurality of provider devices;
perform actions including
Selecting the service provider consolidates 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. A persistent computer-readable medium comprising steps.
Embodiment 41
one or more processors;
A memory that stores a set of instructions and
a network computing system comprising: the one or more processors accessing the instructions;
(A) a plurality of delivery requests, each delivery request originating from a corresponding requestor device to arrange transportation of delivery orders in a particular region according to a set of supply parameters; (B) matching each of the plurality of delivery requests with a service provider to transport the corresponding delivery order from the supplier to the requester of the delivery request; death,
The set of supply parameters includes a service value parameter and at least one of a service aggregation parameter or a service range parameter,
the one or more processors calculate a prediction of at least one of a number of service requests or a number of available service providers for an upcoming time interval;
calculating 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 feed parameters to adjust the feed level to a desired target value.
Embodiment 42
The one or more processors adjust the set of supply parameters by increasing the time interval between matching two or more delivery orders from one supplier to increase the number of delivery orders that are bundled. 42. The network computing system of embodiment 41, wherein the network computing system changes.
Embodiment 43
42. The one or more processors modify the set of provisioning parameters by increasing or decreasing a service range that defines a distance between an individual requester and an available supplier. Network computing system.
Embodiment 44
The one or more processors perform an optimization process to identify one or more values for one or more of the set of delivery parameters to determine the number of delivery requests serviced in a particular length of time. 42. The network computing system of embodiment 41, wherein the set of provision parameters is modified by optimizing.
Embodiment 45
42. The network computing system of embodiment 41, wherein the one or more processors change the set of provisioning parameters by changing a value of a service value parameter.
Embodiment 46
42. The network computation of embodiment 41, wherein the one or more processors perform one or more operations to increase the number of available service providers within the particular region during the immediate time interval. system.
Embodiment 47
47. The network computing system of embodiment 46, wherein the one or more operations include generating an incentive for available service providers within a nearby area to provide delivery services within the particular area.
Embodiment 48
(2) the service scope parameter defines the maximum travel distance from the supplier's location to the delivery point; and (2) the service value parameter defines the maximum travel distance from the supplier's location to the delivery point; the one or more processors modifying the set of supply parameters to adjust the supply level by adjusting the service scope parameter and the supply level parameter; The network computing system according to embodiment 41.
Embodiment 49
A method for providing a delivery service, the method being performed by one or more processors, the method comprising:
(A) a plurality of delivery requests, each delivery request originating from a corresponding requestor device to arrange transportation of delivery orders in a particular region according to a set of supply parameters; (B) matching each of the plurality of delivery requests with a service provider to transport the corresponding delivery order from the supplier to the requester of the delivery request; the set of supply parameters includes at least one of a service value parameter and a service aggregation 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;
calculating a supply level for the particular region during the immediate time interval based at least in part on the forecast;
changing the set of feed parameters to adjust the feed level to a desired target value;
method including.
Embodiment 50
Embodiments wherein the step of changing the set of supply parameters includes changing the time interval for matching two or more order requests from one supplier to increase the number of delivery orders that are bundled. 49. The method described in 49.
Embodiment 51
50. The method of embodiment 49, wherein changing the set of provisioning parameters includes increasing or decreasing a service range that defines the distance between individual requesters and available suppliers.
Embodiment 52
50. The method of embodiment 49, wherein modifying the set of supply parameters includes performing an optimization process to optimize the number of delivery requests serviced over a particular length of time.
Embodiment 53
50. The method of embodiment 49, wherein changing the set of provisioning parameters includes increasing a value of a service value parameter.
Embodiment 54
An implementation further comprising performing one or more operations to change the number of available service providers within the particular area during the immediate time interval and adjust the supply level to the desired target value. The method according to Form 49.
Embodiment 55
55. The method of embodiment 54, wherein the one or more operations include generating an incentive for available service providers within a nearby area to provide delivery services within the particular area.
Embodiment 56
The service range parameter defines a maximum travel distance from a supplier's location to a delivery point, and the service value parameter is allocated to a service provider for transporting a delivery order from the supplier's location to the delivery point. 50. The method of embodiment 49, wherein the step of defining a deposit amount to be received and changing the set of provisioning parameters to adjust the provisioning level includes adjusting the service coverage parameter and the provisioning level parameter.
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 the network computing system;
(A) a plurality of delivery requests, each delivery request originating from a corresponding requestor device to arrange transportation of delivery orders in a particular region according to a set of supply parameters; (B) matching each of the plurality of delivery requests with a service provider to transport the corresponding delivery order from the supplier to the requester of the delivery request; the set of supply parameters includes at least one of a service value parameter and a service aggregation 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;
calculating a supply level for the particular region during the immediate time interval based at least in part on the forecast;
changing the set of feed parameters to adjust the feed level to a desired target value;
A non-transitory computer-readable medium that performs operations on a non-transitory computer-readable medium.
Embodiment 58
Embodiments wherein the step of changing the set of supply parameters includes changing the time interval for matching two or more order requests from one supplier to increase the number of delivery orders that are bundled. 57. The persistent computer-readable medium according to 57.
Embodiment 59
58. The persistent computer-readable method of embodiment 57, wherein modifying the set of supply parameters includes increasing or decreasing a service range that defines a distance between an individual requester and an available supplier. Medium.
Embodiment 60
58. The persistent computer readable device of embodiment 57, wherein the step of modifying the set of supply parameters includes performing an optimization process to optimize the number of delivery requests serviced over a particular length of time. possible medium.

100 Network computing system 101 Order request 102 Requester device 103 Requester information 104 Provider device 105 Requester identifier 106, 116 Service application 107 Requester location 109 Service information 110 Requester device interface 112 Menu section 113 Provider location 115 Provider Identifier 117 Product information 118 Layer logic 119 Menu content 120 Supplier device interface 125 Supplier record 126 Supplier storage section 127 Supplier identifier 128 Request handling section
129 Supplier location 130 Supplier interface 132 Requester status storage unit 133 Service status 134 Provider status storage unit 135 Provider record 136 Account management unit 138 Unification decision logic 150 Supply subsystem 152 Supply level calculation unit 154 Prediction unit 155 Supply Level 156 Supply level adjustment unit 157 Prediction 158 Model creation unit 159 History information 165 Supply parameter 166 Optimization logic 600 Computer system
610 processor 620 memory resource 640 storage device 650 communication interface 680 network connection 700 user device 710 communication interface 718 user input 720 display screen 730 memory 732 service application 740 processor 742 application interface 745 microphone 750 camera 760 satellite receiver 780 network

Claims (15)

one or more processors;
A network computing system comprising: a memory storing a set of instructions;
the one or more processors access the instructions to cause individual requestor mobile devices to transmit their respective locations to the network computing system;
The number of order requests received by (1) the network computing system for a particular time interval, where each order request originates from a requester in a particular region and is matched among a plurality of suppliers in said particular region; (2) the number of available service providers within said particular area that are capable of providing transportation to fulfill said order requests; Estimate,
For each requester of the total population, at least one of the location of the requester's mobile device and the estimated number of order requests or the estimated number of available service providers; selecting a set of a plurality of suppliers for the requester's supplier menu based in part;
determining a travel distance threshold between the supplier and the requester's location based at least in part on a comparison of the estimated number of order requests and the number of available service providers; and selecting a supplier whose travel distance is within the determined threshold value for each of the individual requesters from among the set of multiple suppliers for each of the individual requesters ;
By predicting the number of order requests and the number of available service providers, respectively, for an upcoming time interval using a predictive model created using a machine learning process that is trained and adjusted over time. A network computing system that estimates the number of order requests and the number of available service providers, respectively . The network computing system of claim 1, wherein the one or more processors repeatedly update the threshold of the travel distance. The network computing system of claim 1 , 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. . 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. The network computing system according to claim 3 . 5. The network computing system of claim 4 , wherein the real-time information includes a count of the number of mobile devices on which a service application is running and no corresponding service request from the mobile device is pending. 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 access the instructions for each requestor of the population. 2. The network computing system of claim 1, wherein the plurality of suppliers is selected based at least in part on a predetermined sub-region that corresponds to a current location of a requester. For each requester of the entire population, the one or more processors select the set of multiple suppliers to include a first tier supplier and a second tier supplier; 2. The network computing system of claim 1, wherein second tier suppliers are associated with order requirement constraints that the first tier suppliers are not associated with. 8. The network computing system of claim 7 , wherein the order request constraint is order size. For each requestor of the entire population, the one or more processors may at least partially identify suppliers of the selected set to the second tier, the location of the suppliers, and the requestor. 8. The network computing system according to claim 7 , wherein the network computing system determines based on The network computing system of claim 1, wherein the one or more processors cause the provider menu to be displayed on a respective mobile device of the individual requestor. The one or more processors monitor the location of a mobile device of an individual requester of the entire population and select the set of multiple suppliers for the requester's supplier menu from the requester's The network computing system of claim 1, wherein the reselection is based at least in part on a location of the requester's mobile device after the location of the mobile device changes. A method for fulfilling an order request, the method being performed by one or more processors, the method comprising:
causing each requester's mobile device to transmit its respective location to the network computing system;
The number of order requests received by (1) said network computing system for a particular time interval, with each order request originating from a requester in a particular region and being matched among a plurality of suppliers in said particular region; (2) the number of available service providers within said particular area that are capable of providing transportation to fulfill said order requests; a step of estimating
For each requester of the entire population, at least a portion of 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; selecting a set of a plurality of suppliers for the requester's supplier menu based on the
determining a travel distance threshold between the supplier and the requester's location based at least in part on a comparison of the estimated number of order requests and the number of available service providers; and selecting a supplier whose travel distance is within the determined threshold for each of the individual requesters from among the set of multiple suppliers for each of the individual requesters; including
By predicting the number of order requests and the number of available service providers, respectively, for an upcoming time interval using a predictive model created using a machine learning process that is trained and adjusted over time. A method of estimating the number of order requests and the number of available service providers, respectively . 13. The method of claim 12 , wherein the estimating step includes predicting each of the number of order requests and the number of available service providers for an upcoming time interval. 5. The step of selecting the set of multiple suppliers determines the travel distance threshold based on a comparison of the predicted number of order requests and the predicted number of service providers. 13. The method described in 13 . a non-transitory computer-readable medium storing a plurality of instructions, the plurality of instructions, when executed by one or more processors of the network computing system, transmitting the instructions to the network computing system; transmitting the respective positions to the network computing system;
The number of order requests received by (1) said network computing system for a particular time interval, with each order request originating from a requester in a particular region and being matched among a plurality of suppliers in said particular region; (2) the number of available service providers within said particular area that are capable of providing transportation to fulfill said order requests; a step of estimating
For each requester of the entire population, at least a portion of 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; selecting a set of a plurality of suppliers for the requester's supplier menu based on the
determining a travel distance threshold between the supplier and the requester's location based at least in part on a comparison of the estimated number of order requests and the number of available service providers; and selecting a supplier whose travel distance is within the determined threshold for each of the individual requesters from among the set of multiple suppliers for each of the individual requesters; including
By predicting the number of order requests and the number of available service providers, respectively, for an upcoming time interval using a predictive model created using a machine learning process that is trained and adjusted over time. A non-transitory computer-readable medium is operable to perform acts of estimating, respectively, a number of order requests and a number of available service providers .

Images