WO2019089827A1 - Système informatique pour mettre en œuvre un service de livraison en réseau - Google Patents

Système informatique pour mettre en œuvre un service de livraison en réseau Download PDF

Info

Publication number
WO2019089827A1
WO2019089827A1 PCT/US2018/058554 US2018058554W WO2019089827A1 WO 2019089827 A1 WO2019089827 A1 WO 2019089827A1 US 2018058554 W US2018058554 W US 2018058554W WO 2019089827 A1 WO2019089827 A1 WO 2019089827A1
Authority
WO
WIPO (PCT)
Prior art keywords
delivery
order
service
requester
computing system
Prior art date
Application number
PCT/US2018/058554
Other languages
English (en)
Inventor
Oleksii Nikulkov
Chen Peng
Benjamin Morris DREIER
Xiao Zhang
Shayan Ehsani
Fei Lu
Kiarash Amiri
Zhengli Sun
Arthur James FRIEND V
Robert Zeller
Joseph Mccarthy
Original Assignee
Uber Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/802,391 external-priority patent/US20190132702A1/en
Priority claimed from US15/802,385 external-priority patent/US20190132699A1/en
Priority claimed from US15/802,394 external-priority patent/US20190130320A1/en
Application filed by Uber Technologies, Inc. filed Critical Uber Technologies, Inc.
Priority to BR112020008572-3A priority Critical patent/BR112020008572A2/pt
Priority to CA3080498A priority patent/CA3080498A1/fr
Priority to JP2020524524A priority patent/JP7348175B2/ja
Publication of WO2019089827A1 publication Critical patent/WO2019089827A1/fr
Priority to JP2023145289A priority patent/JP2023162429A/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • Examples described herein relate to a computing system to implement network delivery service.
  • on-demand services leverage resources available through mobile devices, such as wireless (e.g., cellular telephony) devices, which offer developers a platform that can access sensors and other resources available through the mobile device.
  • mobile devices such as wireless (e.g., cellular telephony) devices, which offer developers a platform that can access sensors and other resources available through the mobile device.
  • on-demand services include dedicated applications (sometimes referred to as "apps") to communicate with a network service through which an on-demand service is offered.
  • FIG. 1 illustrates an example of a network computing system for arranging transport of delivery orders, according to one or more examples.
  • FIG. 2 illustrates an example method for identifying suppliers for delivery service to individual requesters.
  • FIG. 3 illustrates an example method for arranging transport for multiple delivery orders.
  • FIG. 4 illustrates an example method for arranging transport for delivery orders in a manner that affects a provisioning level of the provided service.
  • FIG. 5 illustrates another example method for arranging transport for delivery orders to minimize service provider wait time.
  • FIG. 6 illustrates a computer system on which one or more embodiments can be implemented.
  • FIG. 7 is a block diagram illustrating an example user device for use with examples as described.
  • a network computing system implements operations to arrange transport services for delivery orders.
  • a network computing system estimates a provisioning level for a given time interval for one or more regions.
  • the provisioning level determination may be based on an estimated number of order requests, and a number of available service providers in the given region that are available to provide transport in fulfilling the order requests.
  • the computer system selects a set of multiple suppliers for a respective supplier menu that is displayed on a mobile device of the requester. The selection of suppliers for individual requesters may be based at least in part on a current location of the requesters, and at least one of the estimated number of order requests or the estimated number of available service providers.
  • a network computing system arranges transport for delivery orders by (i) predicting an order preparation time of the respective supplier for the order request; (ii) during a time interval that precedes the order preparation time, generating a request for a service provider, based at least in part on a determination that an arrival time of a matched service provider to the respective supplier is within a designated threshold of the order preparation time.
  • An order delivery time for the requester may be estimated based at least in part on the predicted order preparation time and an estimated trip time from a location of the supplier to a location of requester.
  • a client device refers to devices corresponding to desktop computers, cellular devices or smartphones, wearable devices, laptop computers, tablet devices, television (IP Television), etc., that can provide network connectivity and processing resources for communicating with the system over a network.
  • a driver device can also correspond to custom hardware, in- vehicle devices, or on-board computers, etc. The client device and/or the driver device can also operate a designated application configured to communicate with the system 100.
  • the system 100 can enable other on-demand location-based services (e.g., a food truck service, a delivery service, an entertainment service) to be arranged between individuals and service providers.
  • a user can request an on-demand service, such as a delivery service (e.g., food delivery, messenger service, food truck service, or product shipping) or an entertainment service (e.g., mariachi band, string quartet) using the system, and the system can select a service provider, such as a driver, food provider, band, etc., to provide the on-demand service for the user.
  • a delivery service e.g., food delivery, messenger service, food truck service, or product shipping
  • an entertainment service e.g., mariachi band, string quartet
  • One or more embodiments described herein provide that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method.
  • Programmatically means through the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of the computing device.
  • a programmatically performed step may or may not be automatic.
  • a programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions.
  • a module or component can exist on a hardware component independently of other modules or components.
  • a module or component can be a shared element or process of other modules, programs or machines.
  • Some embodiments described herein can generally require the use of computing devices, including processing and memory resources.
  • computing devices including processing and memory resources.
  • one or more embodiments described herein may be implemented, in whole or in part, on computing devices such as servers, desktop computers, cellular or smartphones, tablets, wearable electronic devices, laptop computers, printers, digital picture frames, network equipment (e.g., routers) and tablet devices.
  • Memory, processing, and network resources may all be used in connection with the establishment, use, or performance of any embodiment described herein (including with the performance of any method or with the
  • one or more embodiments described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium.
  • Machines shown or described with figures below provide examples of processing resources and computer- readable mediums on which instructions for implementing embodiments of the invention can be carried and/or executed.
  • the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions.
  • Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers.
  • Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on smartphones, multifunctional devices or tablets), and magnetic memory.
  • Computers, terminals, network enabled devices are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums.
  • embodiments may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.
  • FIG. 1 illustrates an example of a network computing system for arranging transport of delivery orders, according to one or more examples.
  • a network computing system 100 provides a network delivery service that can be utilized by requesters, suppliers and service providers.
  • the network computing system 100 may be implemented on a server, on a combination of servers, and/or on a distributed set of computing devices which communicate over a network such as the Internet. Still further, some examples provide for the network computing system 100 to be distributed using one or more servers and/or mobile devices.
  • the network computing system 100 is implemented as part of, or in connection with a network system, where, for example, operators use service vehicles to provide transport-related services between locations.
  • the network computing system 100 may be implemented using mobile devices of users, including service providers and requesters, with the individual devices executing a corresponding service application that causes the computing device to operate as an information inlet and/or outlet for the network computing system 100.
  • the system 100 implements a network platform, in connection with applications that run on mobile devices of the population of users.
  • the users can include (i) operators (or "service providers") of service vehicles, (ii) requesters who request and receive delivery orders transported by service providers, and (iii) suppliers, who provide requested delivery orders for transport. While some examples describe suppliers in context of food preparation (e.g., restaurant), the system 100 can be implemented to arrange delivery for other kinds of deliverable items, such as groceries, or serviced items. More generally, the system 100 may be implemented to arrange delivery of any type of item, including items which may require preparation. [0022] With reference to an example of FIG.
  • the system 100 includes a requester device interface 110, a provider device interface 120, a request handling component 128, a supplier interface 130, a matching component 140, and one or more data stores which update information about requesters, order requests and providers. Additionally, the system 100 may include a provisioning subsystem 150, to enable system 100 to adjust a provisioning level of the system 100.
  • the provisioning sub-system 150 enables a provisioning level of the system 100 to be estimated or otherwise ascertained with respect to an actual or expected demand from requesters in a given time period, and with respect to a given region (e.g., city or portions of city). Additionally, the provisioning sub-system 150 can be utilized to adjust the provisioning level with respect to the manner in which the system 100 provides a network service to arrange transport for delivery orders. In particular, the provisioning sub-system 150 can make adjustments to the ascertained provisioning level of the network service, in a manner that is optimized for objectives of the provided network service.
  • various facets of the provided network service can be adjusted with fluctuations in demand from requesters, in order to, for example, maximize a number of order requests which can effectively be handled in a given duration of time.
  • the optimization which can be performed through the network service may be implemented on a group level, so as to objectively accommodate the interests of service providers, suppliers, and requesters.
  • the requester device interface 110 includes or performs processes that run on the network-side of the system 100 to establish communication channels with individual devices of requesters.
  • the requesters may operate mobile devices (represented in FIG. 1 by the mobile device 104) on which a corresponding service application 106 may execute.
  • the requesters may operate respective service applications 106 to request delivery services, and in some variations, other types transport-related services, such as human transport between a start location (or pickup location) and a destination (or drop-off).
  • the requester device 102 may transmit requester information 103 to the system 100.
  • the requester information 103 may include an account identifier 105, as well as the current location of the requester device 107, which the service application 106 may obtain by interfacing with a satellite receiver or other location-aware resource of the requester device 102. As described in greater detail, the requester information 103 can also be communicated with an order request 101. In some variations, at least some of the requester information 103 (e.g., current location) may be communicated before a order request 101 is made on the requester device 102.
  • the provider device 104 initiates communications with the system 100 using the service application 116.
  • the service application 116 may correspond to a program (e.g., a set of instructions or code) that is downloaded and stored on the mobile device 104 of the service provider.
  • the service provider can launch the service application 116 in order to utilize the system 100 to receive order requests and/or other type of service requests (e.g., transport requests).
  • the service provider may operate a service vehicle to fulfill assigned service requests.
  • the provider device 104 may repeatedly or continuously communicate service information 109 to the network computing system 100.
  • the service information 109 may include the provider's identifier 111, and the provider's current location 113, which may be determined by the service application interfacing with a satellite receiver of the provider device 104.
  • the provider device interface 120 includes or performs processes that run on the network-side of the system 100 to establish communication channels with individual devices of service providers.
  • the device interface 110 can establish secure sockets with different types of mobile devices, which service providers of the system 100 can utilize when providing services using their respective vehicles.
  • the service providers operate mobile devices (represented in FIG. 1 by the mobile device 104) on which a corresponding service application 116 may be operated.
  • the service application 116 can automate operations which include indicating the availability of the service provider to provide service, communicate location information to enable the system 100 to monitor the location of the service provider's vehicle, receive information from the system 100 to facilitate the service provider in receiving order requests and fulfilling order requests, as well as
  • the system 100 may include an active provider data store 134 that maintains records 135 that associate individual providers with their respective current location 113 and service status 133.
  • each service provider may start a shift by operating the service application 116 (e.g., opening the application on the provider's device 104), and then toggling a state feature provided by the service application 116 to On duty' .
  • the service application 116 communicates the activation of the state feature to the system 100 via the provider device interface 120.
  • the provider device interface 120 processes the service information 109 received from individual service providers. For each service provider, the provider device interface 120 extracts and stores the current location 113 of the provider device 104 with the provider's identifier 115 in the provider status store 134.
  • the service data store 134 may reflect the most current location of each service provider.
  • the requester device interface 110 and the provider device interface 120 can each include or use an application programming interface (API), such as an externally facing API, to communicate data with the provider and requester devices 102, 104, respectively.
  • API application programming interface
  • the system 100 can establish secure communication channels via secure access channels over the network through any number of methods, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), remote procedure call (RPC), scripting access, etc.
  • the supplier interface 130 may correspond to a programmatic interface that transmits order requests from requesters to a terminal of a supplier.
  • the supplier interface 130 transmits delivery orders to a computer system (e.g., reservation ordering system, point-of-sale device, dedicated take-out terminal, etc.) of the supplier.
  • the supplier may operate a mobile device on which a service application for suppliers is provided, in order to receive order requests from the system 100.
  • the supplier may access the system 100 via, for example, a website or application interface (e.g., supplier service application) in order to accept order requests, as well as to provide information as to the preparation status of a order request.
  • the supplier may access the system 100 in order to provide menus or descriptions (including text and images) of available items for delivery.
  • the system 100 may maintain a supplier library 126, which includes a record 125 for each supplier.
  • Each supplier record 125 may associate a respective supplier with an account identifier 127, as well as a supplier location 129 and a set of deliverable items 131 provided by that supplier.
  • the supplier may specify the items 131 via the supplier interface 130.
  • the supplier items 131 may be provided as an electronic document, or combination of records provided by the supplier, which can be retrievable and rendered on a requester device 102 in the form of, for example, a menu.
  • the supplier items 131 may include a restaurant menu, or items for a restaurant menu.
  • the requester device 102 when the requester launches the service application 106, the requester device 102 provides the system 100 with the current location 107 of the requester.
  • the requester can specify a service location for the delivery order that is different than the requester's current location 107.
  • the requester device interface 110 may communicate the requester's current location 107 (or alternatively, the service location specified by the requester) to a menu component 112, and the menu component 112 may use the current location of the requester to retrieve item information 117, representing a selection of the supplier's deliverable items 131, from the supplier library 126.
  • the requester device interface 110 may communicate menu content 119 to the requester device 102, via the service application 106.
  • the menu content 119 may also communicate one or more service value parameters 171, indicating a charge or consideration which the requester will incur for receiving delivery of a requested item from the supplier.
  • the user can browse through the menu content 119 in order to view a list of suppliers, and view items which each available supplier has available for delivery.
  • the service application 106 may enable the user to interact with the menu on the requester device 102, in order to select items for a delivery order. Upon making a selection for delivery order, the service application 106 may cause the requester device 102 to transmit a order request 101 to the system 100.
  • the requester status store 132 records instances when the service application 106 is launched on the requester device 102. In such cases, the requester status store 132 may associate a record with the requester of the requester device 102 (e.g., based on the account information provided by the requester device), and the record may reflect the state of the requester 100 to as being active. Once the order request 101 is received from the requester device 102, the requester's record may be updated and associated with the order request 101.
  • the order request 101 may be received by the requester device interface 110 and recorded in a requester-status store 132.
  • the requester device interface 110 and the menu component 112 may implement a geographic constraint for individual requesters, based on a service range parameter 169.
  • the service range parameter 169 may define a distance (e.g., travel distance) from the service location of the desired order request, from which available suppliers may be made available to the requester for purpose of order requests.
  • the service range parameter 169 may be set to 2 miles or 12 minutes of travel time, and the menu component 112 may implement a filter to remove suppliers who are outside of a distance identified by the range parameter 169. In this way, the service application 106 running on the requester device 102 is not provided with menu content 119 reflecting deliverable items from a supplier that is outside of the range parameter 169.
  • the range parameter 169 may be used to establish tiers amongst suppliers, with respect to the service location of a given order request 101.
  • the menu component 112 may, for example, implement tier logic 118 that sets alternative order request rules for suppliers based at least in part on a tier designation assigned to individual suppliers.
  • the tier logic 118 may assign tier designations based in part on the location of the supplier as compared to the service location of the order request.
  • the tier logic 118 may designate different minimum order sizes or values for order requests of suppliers, based in part on the tier designations of the respect suppliers.
  • the tier logic 118 may implement one or more service value parameters 171 to determine different service values for delivery from different suppliers, based on the tier designation of the respective suppliers with respect to the service location.
  • the request handling component 128 acts on the incoming order request 101, and updates the status of the order request 101 as the order request is processed. Initially, the request handling component 128 may send a communication 139 to the supplier of the order request 101, where the communication
  • the communication 139 identifies the items of a requester's order request 101.
  • the communication 139 may be communicated to a selected supplier view the supplier interface 130.
  • the supplier may acknowledge or confirm the communication 139.
  • the supplier may provide input through a supplier service application, by messaging or other platform to acknowledge the communication 139.
  • the request handling component 128 can also trigger the matching component
  • the request handling component 128 may time when to trigger the matching component 140, based on an expected time when the corresponding delivery order for the order request 101 is prepared.
  • the timing of when to trigger the matching component 140 may include, for example, the request handling component 128 estimating an order preparation time.
  • the request handling component 128 may time (e.g., delaying) the trigger for the matching component 140 based on a comparison of the preparation time and an estimated duration that includes an estimated time interval for when a service provider is matched to the delivery request and an estimated time interval for when the service provider travels to the location of the supplier to pick up the corresponding delivery order.
  • the matching component 140 may be triggered so that the estimated arrival time of the service provider at the location of the supplier (e.g., time to match corresponding order request 101 to service provider and time for service provider to travel to location of the supplier) is within a threshold window of time of an estimated order preparation time for the supplier and/or items of the respective order request 101.
  • the determination of the delivery order preparation time may be made based on, for example, information associated with the supplier.
  • the supplier store 126 may associate preparation time values with the supplier, and/or with the items that individual suppliers make available for delivery requests 101.
  • the order preparation time may be developed from models which monitor order requests from individual suppliers over a given time period.
  • the request handling component 128 may determine, from the estimated order time of an item and/or supplier, that the preparation time is likely to be less than the estimated duration for matching the corresponding order request to a service provider and for the matched service provider to arrive at the location of the supplier. In such examples, the request handling component 128 may delay sending the
  • the delay in sending the communication 139 for the respective order request 101 may be measured so that the estimated order preparation time falls within a window of time that is estimated for a matched service provider to arrive at the location of the supplier.
  • the matching component 140 may match the order request 101 to an available service provider based at least in part on the current location of individual providers with respect to the location of the supplier. In some variations, the matching component 140 may also match the order request 101 based on a desired arrival time for the provider at the location of the supplier. Thus, for example, the proximity of the service provider may not necessarily be a decisive selection criterion for selecting a given service provider.
  • the request handling component 128 may select and implement batch decision logic 138, in order to implement rules and parameters for determining when delivery orders can be batched.
  • Batching may refer to instances when a service provider handles two delivery orders.
  • the batch decision logic 138 may implement batching in accordance with one or multiple set of rules and/or parameters from which a decision can programmatically be made.
  • the batch decision logic 138 may vary, so that different rules, parameters, and/or parametric values may be utilized to determine when batching can be performed.
  • the batch decision logic 138 may implement alternative rules that determine (i) whether or not batching is permitted under any circumstances; and (ii) if batching is permitted, conditions under which multiple delivery orders may be batched.
  • the conditions which may determine or influence batching decisions may include (i) a same supplier condition, in which batching of delivery orders is permitted when the delivery orders are prepared by a same supplier; (ii) a timing condition, which may set a window of time with respect to when order requests are prepared and/or delivered with respect to one another before batching is permitted; (iii) a supplier location condition, in which batching of delivery orders is permitted when the delivery orders are prepared by suppliers that satisfy a geographic condition with respect to each supplier's location and/or delivery location; and/or (iv) provisioning conditions, where a provisioning level determination 155 determines or influences batching decisions.
  • batching may be maximized with respect to permissibility when, for example, an inadequate number of service providers are present to handle order requests. Conversely, batching may be minimized when there is oversupply of service providers, as separate service providers can be used to deliver orders which could otherwise be batched.
  • timing parameters 167 may be utilized, as determined by the provisioning subsystem 150, in order to determine when batching of delivery orders is permitted.
  • the request handling component 128 may utilize one or more timing parameters 167 to minimize a wait time incurred by the service provider while at the supplier. For example, in the context of food preparation, if the arrival time of the service provider exceeds the time when the food is prepared, the prepared food may become cold or less desirable. At the same time, if the arrival time of the service provider is before when the prepared food is ready, the service provider is waiting, and thus underutilized.
  • the request handling component 128 may include logic to initiate the matching process in a window of time that precedes an expected preparation time for the requested delivery order, so that an assigned service provider will arrive at the supplier location just when the requested delivery order is prepared and ready for pickup.
  • FIG. 5 illustrates an example method which can be implemented by, for example, the request handling component 128 to control the selection of a service provider based at least in part on a determination of an optimized arrival time.
  • the batch decision logic 138 may permit delivery orders to be batched if they are from the same supplier, and deliverable by a given service provider to multiple recipients at different locations within a predetermined time limit.
  • the predetermined time limit may be set to, for example, order preparation time (or order pickup time) and/or order delivery time.
  • one or more timing parameters 167 may set a limit of when the last batched order can be picked up and/or delivered with respect to the delivery order's preparation time and/or order request time (e.g., when the respective order request 101 was made).
  • the timing parameter 167 may set a comparable window of time as between the pickup time or delivery time of each delivery order that is to be batched.
  • other timing parameter(s) 167 may control when delivery orders can be batched from a given supplier.
  • the batch decision logic 138 may implement alternative rules, which enable, for example, a service provider to handle delivery orders from different suppliers, subject to additional criteria being satisfied.
  • the batch decision logic 138 may permit delivery orders from different providers to be batched, provided that, for example, the different suppliers satisfy a proximity condition with regard to their respective locations (e.g., suppliers are in same building, next to each other, on same block, within walking distance, etc.).
  • the batch decision logic 138 may permit delivery orders from different providers to be batched, provided that, for example, the different suppliers satisfy a routing condition, such as the different suppliers being aligned along a route for purpose of delivery.
  • the request handling component 128 can monitor the provider via updates to the provider location (e.g., as maintained in the provider status store 134). In particular, the request handling component 128 can track the provider to the location of the supplier, and from the location of the supplier to the service location of the order request 101.
  • the status of the requester's order request may be repeatedly updated by the request handling component 128 in the requester status store 132, to reflect events such as (i) the order request 101 being communicated to the supplier; (ii) the supplier acknowledging the order request; (iii) one or more progress indicators for the order request being prepared, including when a corresponding delivery order is ready; (iv) a service provider picking up the corresponding delivery order; (v) progress of the service provider to the service location identified in a order request; and/or (vi) arrival of the service provider at the service location of the requester (e.g., the requester's current location, or specified location).
  • events such as (i) the order request 101 being communicated to the supplier; (ii) the supplier acknowledging the order request; (iii) one or more progress indicators for the order request being prepared, including when a corresponding delivery order is ready; (iv) a service provider picking up the corresponding delivery order; (v) progress of the service provider to the service location identified in a order request
  • predictive information that may be useful to the requester may be determined and communicated to the requester device 102.
  • the estimated delivery time may be predicted initially before the requester makes the order request 101.
  • the delivery time may be updated for the requester.
  • the delivery time may be updated as the matching component 140 identifies a service provider and as the request handling component 128 tracks the service provider from pickup to the location of the delivery order.
  • the matching component 140 may change the associated state of the service provider, to reflect, for example, one or more unavailable states.
  • the states of the service provider may include available, assigned to order request, on route to supplier, at supplier, on route to requester, and completing order request.
  • the request handling component 128 may trigger an account manager 136.
  • the account manager 136 may record the fulfillment of the order request with respect to the accounts of the service provider, supplier, and requester. In some examples, a charge or other consideration is withdrawn from an account of the requester for the acquired delivery. Likewise, the account manager 136 may credit an account of the supplier for providing the delivery order. The account of the service provider may also be credited based at least partially on the service value parameter 171 associated with the fulfilled order request 101.
  • the provisioning sub-system 150 includes a provisioning level determination (“PLD”) component 152, a forecasting component 154 and a provisioning level adjustment (“PLA”) component 156.
  • the PLD component 152 can estimate a provisioning level for a given region, either during a current time interval or for a future time interval, based on forecasted information from the forecasting component 154.
  • the provisioning level 155 can reflect a determination, for a given interval of time, of the adequacy of the number of service providers for the number of service requests that are to be handled.
  • the forecasting component 154 may generate a forecast for one or more facets of the provisioning level determination.
  • the forecasting component 154 can predict the number of service requests that are to be received by the system 100 over an immediate time interval, or for a time interval in the future.
  • the forecasting component 154 may also forecast, or otherwise estimate a number of service providers that are (or will be) available in a given region to fulfill order requests 101.
  • the PLA component 156 can implement logic to adjust the provisioning level 155 of the system 100, in a manner that optimizes for one or more service objectives of the system 100.
  • the provisioning sub-system 150 may utilize a variety of models 153, including predictive models 153A and/or optimization models 153B.
  • the predictive models 153 A can include tree-based models, deep learning models, neural network models, and/or regression models.
  • the predictive models 153A may be generated and trained to predict provisioning level determinations (e.g., number of order requests, conversion rate from requesters who have service application running without placing order, etc.) and timing predictions (e.g., order preparation time).
  • the optimization models 153B may include, for example, respective convex and non- convex models, and combine tutorial optimization models.
  • a model development component 158 develops respective models 153 A, 153B using machine learning processes, by which, for example, the models are trained and tuned over time, using real-time information (e.g., from requester data store 132 and/or provider data store 134) and historical information 159.
  • the model development component 158 may develop one or more models 153 for use by the provisioning subsystem 150.
  • the provisioning models 153 may include a conversion model that enables the forecasting component 154 to use real-time information to generate a forecast 157 for the number of order requests.
  • the conversion model may, for example, utilize as input real-time information, obtained from the requester status store 132, corresponding to the number of active requesters who have not yet made a order request.
  • the model development component 158 may analyze historical information 159 (e.g., prior snapshots of the requester status store 132 during prior time periods) to detect (i) an active requester session event, coinciding with a requester initiating a session with the system 100 by launching the service application 106 on their respective device 102; and (ii) a conversion event, coinciding with an active requester making a order request.
  • Other information which may be determined from analysis of historical data may include, for example, a length of time for a conversion event to take place for individual requesters, and the suppliers which an active requester viewed.
  • the model development component 158 may record the occurrences of events (e.g., active requester session event, conversion event) over a continuous interval of time.
  • the model development component 158 may utilize input parameters which reflect a velocity value (or acceleration value or other derivative thereof) with request to a number of order requests, a number of active requesters, and/or a number of converted requesters.
  • the model development component 158 may also develop predictive models for use in forecasting delivery requests for future intervals, when pertinent real-time information does not yet exist.
  • the model development component 158 may develop such predictive models 153 using historical information, such as through statistical analysis, to predict a number of active requesters that may come online in a given time interval, a conversion rate of active requesters, and/or a number of order requests which may be generated from the population of users.
  • the model development component 158 may also account for contextual information. For example, the model development component 158 may associate the historical information with day of week, time of day, month of year, events (e.g., sporting events), weather and other related information.
  • events e.g., sporting events
  • the forecasting component 154 may utilize the models 153 generated by the model development component 158 to make one or more forecasts 157 as to demand in a current time interval and/or one or more future time intervals (e.g., number of order requests which may be received in a given duration of time). According to an example, the forecasting component 154 obtains real-time information from the requester status store 132 in order to forecast a number of order requests which may be received in a current (e.g., over the next hour) or near future interval (over the next four hours).
  • the real-time information may include, for example, a number of active requesters who have yet to make an order request, the amount of time each active requester has spent viewing the menu content 119 for individual suppliers, and/or the suppliers (e.g., respective menu of suppliers) which were viewed by the respective requesters.
  • the forecasting component 154 may utilize, for example, a conversion model to predict a number of order requests which the system 100 will receive in a current or immediate time interval, as well as for upcoming time intervals (e.g., number of service requests which may be received in the next four 1-hour time slots).
  • the forecasting component 154 may also utilize the models 153 generated by the model development component 158 to estimate the number of order requests that the system 100 is expected to receive in future time intervals.
  • the model development component 158 may generate a schedule that identifies an expected number of order requests for time slots of an upcoming future time interval (e.g., hourly order request projections for each day of an upcoming week).
  • the model development component 158 may also monitor the requester status store 132 in order to compare a forecast 157 of the forecasting component 154 with respect to the number of order requests received (or the number of active requesters, etc.) with the actual outcome. Based on the comparison, the model development component 158 may tune the models 153 deployed by the forecasting component 154.
  • the model development component 158 may develop and implement predictive models regarding timing-related characteristics of individual suppliers.
  • the model determination component 158 may monitor the requester status store 132 to determine statistical samples of one or more timing-related characteristics of individual suppliers.
  • a timing-related characteristic of a supplier may correspond to preparation time for the supplier to prepare a delivery order.
  • the timing-related characteristics can identify the amount of time that a service provider typically expends upon arriving at the location of the supplier and departing with the delivery order.
  • the model determination component 158 obtains data points for the length of in which a supplier (e.g., restaurant) takes to prepare a food item for a delivery order.
  • the timing related characteristics may be associated with the supplier and the corresponding supplier record 125.
  • the PLD component 152 may estimate the provisioning level 155 for current and future intervals of time based on forecasts 157, as well as service provider availability projections.
  • the provisioning level 155 corresponds to a metric (e.g., a ratio) that is based on a comparison of (i) an estimated number of order requests received in a given time period for a given region, and (ii) a number of service providers in the given region that are likely to be available to provide delivery service for the order requests.
  • the estimated number of service providers may be determined from, for example, real-time information (e.g., as determined from the provider status store 132), as well as from historical information (e.g., snapshots of the provider status store 132 in prior time intervals).
  • the PLA component 156 may implement a set of provisioning parameters 165 based on the provisioning level 155.
  • the provisioning parameters 165 may define respective parametric values for use with rules, process or other logic of a network delivery service. Additionally, the provisioning parameters 165, when changed, affect a provisioning level of the network service in accordance with a generally known relationship. According to some examples, a change in a provisioning parameter may increase or decrease a number of service requests (e.g., order requests) that the network computing system 100 may handle, based on a known or expected relationship with respect to the change in the provisioning parameter.
  • service requests e.g., order requests
  • the provisioning parameters 165 may have a default value when, for example, the provisioning level 155 is neutral (e.g., expected number of order requests to match available service providers), or otherwise at a desired value.
  • the PLA component 156 may adjust the value of the provisioning parameters 165 in order to adjust the provisioning level 155.
  • the provisioning parameters 165 may affect various facets of the delivery service implemented by system 100.
  • the PLA component 156 may utilize multiple sets of provisioning parameters based on the sub-region or region considered.
  • the provisioning parameters 165 reflect a facet or aspect of the service provided by the system 100 which can be adjusted to cause a predicted change to the provisioning level 155 of the service provided.
  • the values for the individual provisioning parameters 165 may be based on an optimization determination for one or more objectives of the system 100. The optimization determination may be made through implementation of one or more optimization processes (shown as optimization logic 166) which optimize aspects of the provisioning level for a particular service objective 161.
  • the system 100 may implement one or multiple service objectives 161, such as maximizing a number of order requests which are handled in a given duration of time, or minimizing a delivery time for order requests which are received.
  • the values of the provisioning parameters 165 may thus be determined by the particular objective, or set of objectives, of the selected optimization process.
  • a relationship between the individual provisioning parameters 165 and the provisioning level 155 may also be predetermined or otherwise known. For example, an adjustment in the value of a given one of the provisioning parameters 165 may be known to have a likely impact in increasing the number of service requests which are handled by the system 100, while at the same time negatively impacting another objective of reducing the service time for order requests.
  • the model development component 158 may, for example, establish relationships between the values of the individual provisioning parameters 165 and the impact of the provisioning parameter value on the provisioning level 155 for a given region or time interval.
  • the relationships may be granular (e.g., a change to provisioning parameter will increase the number of service requests which can be handled through the system 100) or more precise (e.g., a change to provisioning parameter will have a percentage impact (e.g., 5%) on the conversion rate).
  • the provisioning parameters 165 include one or more timing parameters 167, a service range parameter 169, and a service value parameter 171.
  • the one or more timing parameters 167 may reflect a target time interval or a time-limited constraint (e.g., maximum acceptable time interval) by which a particular event in the fulfillment of a order request is to take place.
  • the timing parameter 167 may reflect either a target time or time-limited constraint, for one or more of (i) the delivery time (e.g., from the time that the order request 101 is made until when the order is delivered to the requester); (ii) a wait time incurred by the service provider, such as measured by an interval between when the service provider arrives and departs from the location of the supplier; (iii) a time interval from when a delivery order is prepared until it is picked up; and/or (iv) a time interval from when a delivery order is prepared until it is delivered.
  • the request handling component 128 is able to batch a greater number of order requests, as the amount of time by which order requests can be matched to one another is increased.
  • the service range parameter 169 may reflect a range, such as a travel or absolute distance, between the location of the supplier and the service location of an order request.
  • the service range parameter 169 may be expressed as a travel distance, reflecting a time and/or distance of travel from the location of the supplier to the service location of the order request.
  • the service range parameter 169 may be used by, for example, the menu component 112 to identify which suppliers of the supplier store 126 can be used for the menu items 131.
  • the menu component 112 may query the supplier store 126 for suppliers who have locations 129 that satisfy a proximity condition with respect to the current location 107 of the requester, where the proximity condition is based on the service range parameter 169.
  • the menu component 112 may select a greater number of suppliers from which items 131 may be used to generate the menu content 119 on the requester device 102. Conversely, by decreasing the value of the service range parameter 169, the menu component 112 may select a fewer number of supplies from which items 131 can be used to generate menu content 119 for the requester device 102.
  • the increase or decrease with respect to the number of suppliers which are provided to individual requesters can affect the number of order requests 101 which the system receives, as requesters are more likely to generate order requests 101 when a greater number of options are available.
  • the provisioning sub-system 150 may forecast an increase in the conversion rate, such that a greater number of order requests 101 are received over a given time period.
  • the forecasted number of order requests 101 may be used to engage existing service providers and generally generate a greater number of service requests for service provider.
  • the optimization logic 166 may balance the value of the service range 169 in view of constraints such as added cost to service providers, in order to meet a service level objective (e.g., greater number of order requests fulfilled through the system 100).
  • the service value parameter 171 may reflect a service value that is charged to the requester as part of the delivery order. As described with various examples, the service value parameter 171 may fluctuate to accommodate factors such as distance a service provider travels to fulfill the service order, tier designations for suppliers and/or availability of service providers. In some examples, the service value parameter 171 may be used to adjust the number of available service providers during a given time interval. For example, the service value parameter 171 may also be utilized by the account manager 136, which can adjust a credit or value to the service provider based on changes to the service value parameter 171.
  • the service value parameter 171 may be raised, reflecting greater value and reward for service providers to assist with order requests in the given region.
  • the service value parameter 171 may be communicated to the provider device interface 120, where the service value may be published to nearby providers.
  • the provider device interface 120 may also publish the increase in the service value parameter 171 to draw in more service providers. In this way, the change in the service value parameter 171 may increase or decrease the number of service providers who operate in a given region.
  • FIG. 2 illustrates an example method for identifying suppliers for delivery service to individual requesters.
  • FIG. 3 illustrates an example method for arranging transport for multiple delivery orders.
  • FIG. 4 illustrates an example method for arranging transport for delivery orders in a manner that affects a provisioning level of the provided service.
  • FIG. 5 illustrates another example method for arranging transport for delivery orders to minimize service provider wait time.
  • FIG. 2 through FIG. 5 reference is made to elements of an example of FIG. 1 for purpose of illustrating a suitable component for performing a step or sub-step being described.
  • a network computing system causes the mobile device of individual requesters to transmit their respective location (210).
  • the requester devices 102 may execute service applications 106 which access a satellite receiver or other location-aware resource of the mobile device.
  • a requester may open the service application 106 on their respective mobile device 102 to initiate a session with the network computing system 200.
  • the network computing system 200 transmits information (e.g., menu content 119) to identify suppliers (e.g., restaurants) within a designated range of the requester (220).
  • suppliers e.g., restaurants
  • the suppliers may be identified by providing a supplier menu to the requester device.
  • the requester may browse menus from multiple suppliers that are within the designated service range with respect to the current location of the requester.
  • the designated range may reflect a threshold distance of travel between the location of the supplier and the current location of the requester.
  • the designated range may be based at least in part on a provisioning level determination for the given region (222) (e.g., a comparison of the estimated number of order requests and the number of available service providers). For example, as described with an example of FIG.
  • the designated range may be determined by the service parameter 169, which the provisioning sub-system 150 may determine based on the determined provisioning level 155 and the implementation of optimization processes by the optimization logic 166.
  • the system 100 may change the designated service range so that a greater or lesser number of suppliers are available to a given requester.
  • system 100 may also adjust other parameters, such as the service value 171 (e.g., provide additional incentive for service providers to drive extra distance), based on a known or predicted relationship between the change in the value of the respective service parameters and the provisioning level 155.
  • the selection of suppliers for a given requester may be dynamic and based on the current location of the requester (224).
  • the system 100 may monitor the location of the mobile devices of individual requesters, and reselect the suppliers that are displayed on the respective mobile devices based on an updated location of the requester.
  • FIG. 2 may reflect when the requester device 102 is placed in a pre-requests state, such as when the requester opens the service application 106 to browse available menus.
  • the provisioning sub-system 150 may utilize the pre-request state of the requester in determining the provisioning level 155 for a sub-region where the requester is located.
  • the provisioning sub-system 150 may also generate a forecast based on, for example, a prediction as to whether the requester will generate an order request 101.
  • the prediction of whether the user will generate the order request 101 may be based in part on a predicted or observed conversion rate as to the number of requesters who view menu content 119 from suppliers of the region and those who generate a respective order request using the menu content 119.
  • the system 100 may implement a service to arrange transport for order requests.
  • the system 100 may receive order requests from requester devices of a given region, with each order request specifying a respective supplier (310).
  • the system 100 selects a service provider to transport a corresponding delivery order from a
  • the network computing system determines a provisioning level indicator for the given region, for a current or future time interval (330).
  • the provisioning level indicator may be determined at least in part by requester devices 102, which communicate with the system 100 using the respective service application 106.
  • the system 100 selects the service provider for individual order requests by selecting one of multiple available decision logics to implement for the given region in the given time interval, where the selection of the decision logic is based at least in part on the determined provisioning level indicator (340).
  • the system 100 may implement the selected decision logic to determine whether individual delivery orders, generated in response to respective order requests, can be batched for delivery to respective requesters. When delivery orders are batched, the same service provider may transport the respective delivery orders to their respective destinations.
  • the system 100 may implement a first decision logic to batch multiple delivery orders for delivery to respective requesters based on the multiple delivery orders satisfying at least a first timing criterion (342).
  • the timing criterion may be parameterized (e.g., timing parameter 167) and subject to change, based on conditions such as provided by provisioning level markers and determinations.
  • the system 100 may relax the timing parameter 167 in order to provide additional time for matched delivery orders to take place.
  • the timing criterion may be based on, for example, the delivery time (e.g., change in delivery time for each of multiple delivery orders that are batched together).
  • the timing criterion may correspond to a wait time incurred by the service provider, such as measured by an interval between when the service provider arrives and departs from the location of the supplier.
  • the timing parameter may correspond to a time interval from when a delivery order is prepared until it is picked up.
  • the timing criterion may correspond to a time interval from when a delivery order is prepared until it is delivered.
  • the request handling component 128 is able to batch a greater number of order requests, as the amount of time by which order requests can be matched to one another is increased.
  • the system 100 arranges transport for delivery orders in a given region, in accordance with a set of provisioning parameters (410).
  • the system 100 receives order requests from corresponding requester devices, with each order request specifying a respective supplier. Additionally, the system 100 matches each received order request to a respective service provider, in order to transport a corresponding delivery order from a respective supplier to a location of the respective requester of the service request.
  • the set of provisioning parameters may include a service value parameter, and at least one of a service batching parameter or a service range parameter.
  • the network computing system may determine a forecast for expected service requests that are received for a given region, during a current or immediate time interval (420).
  • the forecast may be determined from a model that utilizes realtime information.
  • the model determination component 158 accesses the requester data store 132 to determine the number of active requesters who initiated a session with the system 100, but who have not yet made a delivery order.
  • the system 100 determines the provisioning level 155 for the given region during the upcoming time interval, based at least in part on the forecast (430). Based on the forecast, the system 100 makes a determination as to whether any of the provisioning parameters 165 in the set should be adjusted to change the provisioning level to a desired target (440). Thus, the system 100 may change the value of the provisioning parameters 165 in order to adjust the determined or forecasted provisioning level 155.
  • the service value 171 may be changed to, for example, increase the number of service providers.
  • the service range 169 may be increased or decreased to increase or decrease demand (e.g., conversion rate increases with more choices for requesters).
  • the provisioning parameters are adjusted in accordance with one or more optimization processes which are based on service level objectives (442).
  • the service level objectives may correspond to, for example, maximizing a number of service requests which are processed over a given time period, minimizing a travel distance of service providers, and/or minimizing a wait time of requesters for delivery orders.
  • the system 100 receives order requests from requesters of a given region, and the system selects individual service providers for each order request.
  • the system 100 selects the service provider by predicting an order preparation time of the supplier of the order request (510).
  • the system 100 may develop a predictive model using historical information and/or real-time monitoring (512).
  • the model development component 158 of the system 100 may develop a predictive model based on information determined from the requester status store 132.
  • the model development component 158 may monitor the requester status store 132 and/or the provider status store 134 in order to determine instances when a service provider arrived at the location of the supplier early, before the delivery order was prepared.
  • the determination may be made by identifying instances when the service provider had to wait before leaving.
  • the presumption that can be made from the service provider waiting may be that the delivery order was not yet prepared at the time when the provider arrives at the location of the supplier.
  • the departure time of the service provider may be used to estimate the preparation time for the delivery order.
  • the arrival and departure times may be determined automatically, based on, for example, the current location of the provider device 104.
  • the system 100 may attempt to select a service provider during a time interval that precedes the predicted order preparation time (520).
  • the matching component 140 may, for example, be triggered by the request handling component 128 to generate a request to identify a service provider who can be assigned to travel to the location of the supplier and arrive at a time that is within a window of margin with respect to the predicted order preparation time (522). In some examples, a determination is made as to whether the order request can be immediately matched to a service provider (525). If the order request is matched to the service provider, then the service provider may be tracked to arrive at the supplier within the window of margin (528). Additionally, the requester may receive an estimated time for the delivery order to arrive at the requester' s location based on the arrival time of the service provider at the location of the supplier (532). The system 100 may continue to monitor and update the requester through the stags of the delivery order.
  • the process may be repeated at (520).
  • the service handling component 128 may trigger the matching component 140 again, at a different time interval, to find a match for the order request.
  • the process may be repeated over the time interval preceding the predicted order preparation time. As the window to match the order request to the service provider gets smaller, the region(s) which the matching component 140 attempts to match becomes closer to the location of the supplier.
  • FIG. 6 illustrates a computer system on which one or more embodiments can be implemented.
  • a computer system 600 can be implemented on, for example, a server or combination of servers.
  • the computer system 600 may be implemented as part of the of an example of FIG. 1.
  • the computer system 600 can implement a method such as described with examples of FIG. 2 through FIG. 5.
  • the computer system 600 includes processing resources 610, memory resources 620 (e.g., read-only memory (ROM) or random-access memory (RAM)), a storage device 640, and a communication interface 650.
  • the computer system 600 includes at least one processor 610 for processing information stored in the main memory 620, such as provided by a random-access memory (RAM) or other dynamic storage device, for storing information and instructions which are executable by the processor 610.
  • the main memory 620 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 610.
  • the computer system 600 may also include the memory resources 620 or other static storage device for storing static information and instructions for the processor 610.
  • the storage device 640 such as a magnetic disk or optical disk, is provided for storing information and instructions.
  • the communication interface 650 enables the computer system 600 to
  • the executable instructions stored in the memory 630 can include instructions 642, to implement a network computing system such as described with an example of FIG. 1.
  • the executable instructions stored in the memory 620 may also implement a method, such as described with one or more examples of FIG. 2 through FIG. 5.
  • examples described herein are related to the use of the computer system 600 for implementing the techniques described herein.
  • techniques are performed by the computer system 600 in response to the processor 610 executing one or more sequences of one or more instructions contained in the memory 620.
  • Such instructions may be read into the memory 620 from another machine-readable medium, such as the storage device 640.
  • Execution of the sequences of instructions contained in the memory 620 causes the processor 610 to perform the process steps described herein.
  • hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein.
  • the examples described are not limited to any specific combination of hardware circuitry and software.
  • FIG. 7 is a block diagram illustrating an example user device for use with examples as described.
  • a user device 700 may execute a designated service application for a network service implemented through a network computing system 100 such as described with an example of FIG. 1.
  • a user device 700 can include a mobile computing device, such as a smartphone, tablet computer, laptop computer, VR or AR headset device, and the like.
  • the user device 700 can include typical telephony and/or tablet features such as a microphone 745, a camera 750, a satellite receiver 760, and a communication interface 710 to
  • the user device 700 can store a designated application (e.g., a service app 732) in a local memory 730.
  • a designated application e.g., a service app 732
  • the memory 730 can store additional applications executable by one or more processors 740 of the user device 700, enabling access and interaction with one or more host servers over one or more networks 780.
  • the service application 732 can interact with the computer system 700 to display an application interface 742 on a display screen 720 of the user device 700.
  • the application interface 742 can be used to display menu content 119, and enable the requester to make order requests from the network computing system 100.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Selon l'invention, un système informatique de réseau estime un niveau d'approvisionnement pour un intervalle de temps donné pour une ou plusieurs régions. La détermination de niveau d'approvisionnement peut être basée sur un nombre estimé de demandes de commande, et un certain nombre de fournisseurs de services disponibles dans la région donnée qui sont disponibles pour fournir un transport pour le traitement des demandes de commande. Pour des demandeurs individuels dans la région donnée, le système informatique sélectionne un ensemble de multiples fournisseurs pour un menu de fournisseurs respectif qui est affiché sur un dispositif mobile du demandeur. La sélection de fournisseurs pour des demandeurs individuels peut être basée au moins en partie sur un emplacement actuel des demandeurs, et au moins sur le nombre estimé de demandes de commande et/ou le nombre estimé de fournisseurs de services disponibles.
PCT/US2018/058554 2017-11-02 2018-10-31 Système informatique pour mettre en œuvre un service de livraison en réseau WO2019089827A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
BR112020008572-3A BR112020008572A2 (pt) 2017-11-02 2018-10-31 sistema de computação para implementar serviço de entrega em rede
CA3080498A CA3080498A1 (fr) 2017-11-02 2018-10-31 Systeme informatique pour mettre en ƒuvre un service de livraison en reseau
JP2020524524A JP7348175B2 (ja) 2017-11-02 2018-10-31 ネットワーク配達サービスを実行するコンピュータシステム
JP2023145289A JP2023162429A (ja) 2017-11-02 2023-09-07 ネットワーク配達サービスを実行するコンピュータシステム

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US15/802,391 US20190132702A1 (en) 2017-11-02 2017-11-02 Network computer system to selectively batch delivery orders
US15/802,391 2017-11-02
US15/802,394 2017-11-02
US15/802,385 2017-11-02
US15/802,385 US20190132699A1 (en) 2017-11-02 2017-11-02 Computing system to implement network delivery service
US15/802,394 US20190130320A1 (en) 2017-11-02 2017-11-02 Network computer system to implement dynamic provisioning for fulfilling delivery orders

Publications (1)

Publication Number Publication Date
WO2019089827A1 true WO2019089827A1 (fr) 2019-05-09

Family

ID=66333633

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/058554 WO2019089827A1 (fr) 2017-11-02 2018-10-31 Système informatique pour mettre en œuvre un service de livraison en réseau

Country Status (4)

Country Link
JP (2) JP7348175B2 (fr)
BR (1) BR112020008572A2 (fr)
CA (1) CA3080498A1 (fr)
WO (1) WO2019089827A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114710562A (zh) * 2022-03-31 2022-07-05 珠海市鸿瑞信息技术股份有限公司 基于大数据的设备应用日志关联分析系统及方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023009364A (ja) * 2021-07-07 2023-01-20 保 池田 販売システム

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140011522A1 (en) * 2012-07-03 2014-01-09 Uber Technologies, Inc. System and method for providing dynamic supply positioning for on-demand services
KR20140101501A (ko) * 2013-02-08 2014-08-20 에스케이플래닛 주식회사 위치정보 기반의 상품 구매 방법, 이를 위한 시스템 및 장치
CN104751272A (zh) * 2015-03-04 2015-07-01 径圆（上海）信息技术有限公司 智能订单调度方法、服务器、电动车、移动终端及系统
US20150363843A1 (en) * 2014-04-23 2015-12-17 United Parcel Service Of America, Inc. Dynamic provisioning of pick-up, delivery, transportation, and/or sortation options
US20160140589A1 (en) * 2014-11-14 2016-05-19 International Business Machines Corporation Retail customer engagement zones
US20160210591A1 (en) * 2015-01-19 2016-07-21 9316-2832 Quebec Inc. System and Method for Managing and Optimizing Delivery Networks
US20160353235A1 (en) * 2015-06-01 2016-12-01 Accenture Global Services Limited Location-based order recommendations
WO2017148202A1 (fr) * 2016-03-03 2017-09-08 Beijing Didi Infinity Technology And Development Co., Ltd. Systèmes et procédés permettant de déterminer une distribution prédite d'une moment futur de service de transport
US20180225796A1 (en) * 2017-02-08 2018-08-09 Uber Technologies, Inc. Resource Allocation in a Network System
WO2018209263A1 (fr) * 2017-05-11 2018-11-15 Uber Technologies, Inc. Système informatique de réseau permettant de positionner des fournisseurs de services à l'aide de déterminations de niveaux d'approvisionnement

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090048890A1 (en) * 2007-08-16 2009-02-19 Burgh Stuart G Delivery Management System for Quick Service Restaurants
US9269103B1 (en) * 2015-02-19 2016-02-23 Square, Inc. Combining orders for delivery
US10133995B1 (en) * 2015-02-19 2018-11-20 Square, Inc. Courier network management
US9639908B1 (en) * 2015-03-20 2017-05-02 Square, Inc. Variable delivery zones for delivery orders

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140011522A1 (en) * 2012-07-03 2014-01-09 Uber Technologies, Inc. System and method for providing dynamic supply positioning for on-demand services
KR20140101501A (ko) * 2013-02-08 2014-08-20 에스케이플래닛 주식회사 위치정보 기반의 상품 구매 방법, 이를 위한 시스템 및 장치
US20150363843A1 (en) * 2014-04-23 2015-12-17 United Parcel Service Of America, Inc. Dynamic provisioning of pick-up, delivery, transportation, and/or sortation options
US20160140589A1 (en) * 2014-11-14 2016-05-19 International Business Machines Corporation Retail customer engagement zones
US20160210591A1 (en) * 2015-01-19 2016-07-21 9316-2832 Quebec Inc. System and Method for Managing and Optimizing Delivery Networks
CN104751272A (zh) * 2015-03-04 2015-07-01 径圆（上海）信息技术有限公司 智能订单调度方法、服务器、电动车、移动终端及系统
US20160353235A1 (en) * 2015-06-01 2016-12-01 Accenture Global Services Limited Location-based order recommendations
WO2017148202A1 (fr) * 2016-03-03 2017-09-08 Beijing Didi Infinity Technology And Development Co., Ltd. Systèmes et procédés permettant de déterminer une distribution prédite d'une moment futur de service de transport
US20180225796A1 (en) * 2017-02-08 2018-08-09 Uber Technologies, Inc. Resource Allocation in a Network System
WO2018209263A1 (fr) * 2017-05-11 2018-11-15 Uber Technologies, Inc. Système informatique de réseau permettant de positionner des fournisseurs de services à l'aide de déterminations de niveaux d'approvisionnement

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114710562A (zh) * 2022-03-31 2022-07-05 珠海市鸿瑞信息技术股份有限公司 基于大数据的设备应用日志关联分析系统及方法

Also Published As

Publication number Publication date
BR112020008572A2 (pt) 2020-10-06
JP2023162429A (ja) 2023-11-08
JP7348175B2 (ja) 2023-09-20
JP2021501945A (ja) 2021-01-21
CA3080498A1 (fr) 2019-05-09

Similar Documents

Publication Publication Date Title
US20220414593A1 (en) Network computer system to implement predictive time-based determinations for fulfilling delivery orders
US20190132699A1 (en) Computing system to implement network delivery service
US20190132702A1 (en) Network computer system to selectively batch delivery orders
US20190130320A1 (en) Network computer system to implement dynamic provisioning for fulfilling delivery orders
US10731998B2 (en) Network computer system to arrange pooled transport services
US10928210B2 (en) Method and system for shared transport
US12044542B2 (en) Optimization of network service based on an existing service
US20160300318A1 (en) Fare determination system for on-demand transport arrangement service
US20200065734A1 (en) Network computing system to coordinate timing of delivery services
US20190392357A1 (en) Request optimization for a network-based service
US20180308038A1 (en) Network system capable of grouping multiple service requests
JP2023162429A (ja) ネットワーク配達サービスを実行するコンピュータシステム
US20190095965A1 (en) System and method to detect service assignment outcomes in connection with arranged services
CN111562991A (zh) 用于基于网络的服务的情景通知

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18873897

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 3080498

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2020524524

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112020008572

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112020008572

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20200429

122 Ep: pct application non-entry in european phase

Ref document number: 18873897

Country of ref document: EP

Kind code of ref document: A1