Note: Descriptions are shown in the official language in which they were submitted.
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
COMPUTING SYSTEM TO IMPLEMENT NETWORK DELIVERY SERVICE
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of priority to each of (i) U.S.
Patent
Application No. 15/802,385, filed November 2, 2017, (ii) U.S. Patent
Application No.
15/802,391, filed November 2, 2017, and (iii) U.S. Patent Application No.
15/802,394,
filed November 2, 2017. All of the aforementioned priority applications are
hereby
incorporated by reference in their respective entireties.
TECHNICAL FIELD
[0002] Examples described herein relate to a computing system to implement
network
delivery service.
BACKGROUND
[0003] Numerous on-demand services exist to offer users a variety of services:
transportation, shipping, food delivery, groceries, pet sitting, mobilized
task force and
others. Typically, 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.
Many 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] FIG. 1 illustrates an example of a network computing system for
arranging
transport of delivery orders, according to one or more examples.
[0005] FIG. 2 illustrates an example method for identifying suppliers for
delivery service
to individual requesters.
[0006] FIG. 3 illustrates an example method for arranging transport for
multiple delivery
orders.
[0007] FIG. 4 illustrates an example method for arranging transport for
delivery orders in
a manner that affects a provisioning level of the provided service.
[0008] FIG. 5 illustrates another example method for arranging transport for
delivery
orders to minimize service provider wait time.
1
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
[0009] FIG. 6 illustrates a computer system on which one or more embodiments
can be
implemented.
[0010] FIG. 7 is a block diagram illustrating an example user device for use
with
examples as described.
DETAILED DESCRIPTION
[0011] According to some examples, a network computing system implements
operations
to arrange transport services for delivery orders.
[0012] In some examples, 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. For individual requesters within the given region, 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.
[0013] In variations, 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.
[0014] As used herein, 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.
[0015] While some examples described herein relate to transport services, the
system 100
can enable other on-demand location-based services (e.g., a food truck
service, a delivery
2
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
service, an entertainment service) to be arranged between individuals and
service
providers. For example, 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.
[0016] 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, as used herein, 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.
[0017] One or more embodiments described herein can be implemented using
programmatic modules, engines, or components. 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. As used herein, a module or component can exist on a hardware
component
independently of other modules or components. Alternatively, a module or
component
can be a shared element or process of other modules, programs or machines.
[0018] Some embodiments described herein can generally require the use of
computing
devices, including processing and memory resources. For example, 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
implementation of any system).
[0019] Furthermore, 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. In particular, the numerous machines shown
with
3
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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
(e.g.,
mobile devices, such as cell phones) are all examples of machines and devices
that utilize
processors, memory, and instructions stored on computer-readable mediums.
Additionally, embodiments may be implemented in the form of computer-programs,
or a
computer usable carrier medium capable of carrying such a program.
[0020] FIG. 1 illustrates an example of a network computing system for
arranging
transport of delivery orders, according to one or more examples. According to
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. In some variations, 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. In variations, 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.
[0021] In some examples, the system 100 implements a network platform, in
connection
with applications that run on mobile devices of the population of users. For a
given
geographic region, 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.
4
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
[0022] With reference to an example of FIG. 1, 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.
[0023] As described with some examples, 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. In this manner, 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. Moreover, 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.
[0024] 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).
When the service application 106 is launched on the requester device 102, the
requester
device 102 may transmit requester information 103 to the system 100. The
requester
information 103 may include an account identifier 105, 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
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
(e.g., current location) may be communicated before a order request 101 is
made on the
requester device 102.
[0025] According to some examples, 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. Once the communication
channel is
established by the provider device 104 using the service application 116, the
provider
device 104 may repeatedly or continuously communicate service information 109
to the
network computing system 100. The service information 109 may include 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.
[0026] 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. For example, 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. In some
examples, 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. Among other
functionality, 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
communicating information to the system 100 for various purposes, including
provisioning determination.
[0027] 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. By way of example, 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
6
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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. As 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 can be used to update the provider status
store 134. In
this way, the service data store 134 may reflect the most current location of
each service
provider.
[0028] In some examples, 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. By providing the externally facing API, 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.
[0029] The supplier interface 130 may correspond to a programmatic interface
that
transmits order requests from requesters to a terminal of a supplier. The
context of food
delivery, 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. In some examples, 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.
Additionally, the
supplier may access the system 100 in order to provide menus or descriptions
(including
text and images) of available items for delivery.
[0030] 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
7
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
on a requester device 102 in the form of, for example, a menu. By way of
example, the
supplier items 131 may include a restaurant menu, or items for a restaurant
menu.
[0031] According to some examples, when the requester launches the service
application
106, the requester device 102 provides the system 100 with the current
location 107 of the
requester. In some variations, 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. As described with
some
examples below, 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.
[0032] In some examples, the requester status store 132 records instances when
the
service application 106 is launched on the requester device 102. In such
cases, the
requester status store 132 may associate 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.
[0033] The order request 101 may be received by the requester device interface
110 and
recorded in a requester-status store 132. In some examples, 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. For example, the service range parameter 169 may be
set to 2
8
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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.
[0034] As an addition or variation, 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. Based on
implementation, 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. As an addition or variation, 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.
[0035] According to some examples, 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
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. In
some
implementations, the supplier may acknowledge or confirm the communication
139. For
example, the supplier may provide input through a supplier service
application, by
messaging or other platform to acknowledge the communication 139.
[0036] The request handling component 128 can also trigger the matching
component
140 to initiate a matching process to select a service provider for the order
request 101. In
some examples, 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. In particular, the request handling
component 128
may time (e.g., delaying) the trigger for the matching component 140 based on
a
9
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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. By way of example, 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.
[0037] The determination of the delivery order preparation time may be made
based on,
for example, information associated with the supplier. For example, 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. As described
with some
examples, the order preparation time may be developed from models which
monitor order
requests from individual suppliers over a given time period.
[0038] In some examples, 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
communication 139 (for the corresponding order request 101) to the supplier
specified by
the respective order request 101 until after a service provider is matched to
the respective
order request 101. In such examples, 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.
[0039] 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.
[0040] In some examples, the request handling component 128 may select and
implement
batch decision logic 138, in order to implement rules and parameters for
determining
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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. In particular, 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. By way of example, 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.
[0041] With respect to provisioning conditions, some examples provide that
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.
[0042] With respect to timing conditions, some examples provide for the batch
decision
logic 138 to utilize timing parameters 167, as determined by the provisioning
subsystem
150, in order to determine when batching of delivery orders is permitted. For
example,
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
11
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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.
[0043] In variations, 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. For example, 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). As an addition or alternative, 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. In variations,
other timing
parameter(s) 167 may control when delivery orders can be batched from a given
supplier.
[0044] With respect to supplier location conditions, 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. As
an alternative to a same supplier condition, for example, 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.). As another example, 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.
[0045] Once the matching component 140 selects a provider for the order
request 101, 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
12
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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).
[0046] Additionally, in 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 may be predicted initially before the
requester
makes the order request 101. As the order request 101 is processed by the
supplier, the
delivery time may be updated for the requester. Likewise, 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.
[0047] Similarly, the matching component 140 (and/or the request handling
component
128) may change the associated state of the service provider, to reflect, for
example, one
or more unavailable states. For example, 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.
[0048] Once the service provider is detected to have completed the delivery
service, 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.
[0049] According to some examples, 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
13
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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. For
example, 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.
[0050] The provisioning sub-system 150 may utilize a variety of models 153,
including
predictive models 153A and/or optimization models 153B. By way of example, the
predictive models 153A can include tree-based models, deep learning models,
neural
network models, and/or regression models. By way of example, the predictive
models
153A may be generated and trained to predict 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.
[0051] In some examples, a model development component 158 develops respective
models 153A, 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.
[0052] In some examples, 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. In variations, 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
14
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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. Additionally, 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. For example, 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.
[0053] As an addition or alternative, 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.
[0054] In determining conversion or other predictive models, 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.
[0055] 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. Based on the
real-time
information, the forecasting component 154 may utilize, for example, a
conversion model
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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). As an
addition or
variation, 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. For example, 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).
[0056] According to some examples, 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.
[0057] In some variations, 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. By way of example, a timing-related characteristic of a
supplier may
correspond to preparation time for the supplier to prepare a delivery order.
As another
example, 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. In this way, 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.
[0058] 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. In some examples, 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
16
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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).
[0059] 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. 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. When the provisioning level fluctuates away from a neutral or
desirable
level, the PLA component 156 may adjust the value of the provisioning
parameters 165 in
order to adjust the provisioning level 155.
[0060] The provisioning parameters 165 may affect various facets of the
delivery service
implemented by system 100. Thus, for example the PLA component 156 may utilize
multiple sets of provisioning parameters based on the sub-region or region
considered.
According to examples, 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. In particular, 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.
[0061] According to some examples, a relationship between the individual
provisioning
parameters 165 and the provisioning level 155 may also be predetermined or
otherwise
17
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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).
[0062] By way of example, 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. For example, 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. According to some examples, when one or more timing parameters 167
are
relaxed, 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.
[0063] 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.
In some examples, 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
18
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
respect to the current location 107 of the requester, where the proximity
condition is
based on the service range parameter 169. By increasing the value of 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.
For
example, by increasing the service range parameter 169, 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).
[0064] 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. For example, if more service providers are
needed to
facilitate handling of an unexpected number of order requests for a given
area, 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. As shown by an
example of
FIG. 1, 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
19
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
parameter 171 may increase or decrease the number of service providers who
operate in a
given region.
[0065] 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.
illustrates another example method for arranging transport for delivery orders
to
minimize service provider wait time. In describing examples of 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.
[0066] With reference to an example of FIG. 2, a network computing system
causes the
mobile device of individual requesters to transmit their respective location
(210). For
example, 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.
[0067] When the session is initiated, 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). 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. In
some examples,
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. 1, 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. Thus, the system 100 may change the designated service
range so
that a greater or lesser number of suppliers are available to a given
requester. With
increase in range, 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
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
on a known or predicted relationship between the change in the value of the
respective
service parameters and the provisioning level 155.
[0068] As an addition or variation, in some examples, the selection of
suppliers for a
given requester may be dynamic and based on the current location of the
requester (224).
For example, 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.
[0069] An example of 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. For
example, 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.
[0070] With reference to an example of FIG. 3, the system 100 may implement a
service
to arrange transport for order requests. In providing the service, the system
100 may
receive order requests from requester devices of a given region, with each
order request
specifying a respective supplier (310). For each of the order requests, the
system 100
selects a service provider to transport a corresponding delivery order from a
corresponding supplier to a location of the requester (320). Additionally, in
providing the
service, 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.
[0071] 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.
21
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
When delivery orders are batched, the same service provider may transport the
respective
delivery orders to their respective destinations.
[0072] According to some examples, 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).
As described with
various examples, 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. By way of example, the system 100 may relax the
timing
parameter 167 in order to provide additional time for matched delivery orders
to take
place.
[0073] In various examples, 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). In other examples, 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. As an
addition or
variation, the timing parameter may correspond to a time interval from when a
delivery
order is prepared until it is picked up. Still further, the timing criterion
may correspond to
a time interval from when a delivery order is prepared until it is delivered.
According to
some examples, when one or more timing parameters 167 are relaxed, 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.
[0074] With reference to an example of FIG. 4, the system 100 arranges
transport for
delivery orders in a given region, in accordance with a set of provisioning
parameters
(410). In arranging transport for delivery orders, 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.
[0075] 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). In some examples, the forecast may be determined from a model that
utilizes real-
time information. For example, the model determination component 158 accesses
the
22
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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.
[0076] 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.
For example,
the service value 171 may be changed to, for example, increase the number of
service
providers. Likewise, the service range 169 may be increased or decreased to
increase or
decrease demand (e.g., conversion rate increases with more choices for
requesters).
[0077] In some examples, 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.
[0078] In an example of FIG. 5, 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). In order to predict the order preparation
time, the
system 100 may develop a predictive model using historical information and/or
real-time
monitoring (512). For example, the model development component 158 of the
system 100
may develop a predictive model based on information determined from the
requester
status store 132. In some examples, 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. In such
cases, the
departure time of the service provider may be used to estimate the preparation
time for
the delivery order. In some examples, the arrival and departure times may be
determined
automatically, based on, for example, the current location of the provider
device 104.
23
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
[0079] 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.
[0080] If the matching component 140 fails to immediately find a matched
service
provider for the order request, then 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.
[0081] 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. For example, the computer system 600 may be
implemented as
part of the of an example of FIG. 1. Likewise, the computer system 600 can
implement a
method such as described with examples of FIG. 2 through FIG. 5.
[0082] In one implementation, 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
24
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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.
[0083] The communication interface 650 enables the computer system 600 to
communicate with one or more networks (e.g., cellular network) through use of
the
network link 680 (wireless or a wire). Using the network link 680, the
computer system
600 can communicate with one or more computing devices, specialized devices
and
modules, and one or more servers. 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.
[0084] As such, examples described herein are related to the use of the
computer system
600 for implementing the techniques described herein. According to an aspect,
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.
In alternative implementations, hard-wired circuitry may be used in place of
or in
combination with software instructions to implement examples described herein.
Thus,
the examples described are not limited to any specific combination of hardware
circuitry
and software.
[0085] FIG. 7 is a block diagram illustrating an example user device for use
with
examples as described. In an example, 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. In many
implementations, 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. As such, 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
communicate with external entities using any number of wireless communication
protocols. In certain aspects, the user device 700 can store a designated
application (e.g.,
a service app 732) in a local memory 730. In variations, the memory 730 can
store
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
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.
[0086] In response to a user input 718 (e.g., search input), 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. When the user device 700 is used as a
requester device,
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.
[0087] Although examples 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 examples. Accordingly, it is intended that the scope of the concepts
be defined by
the following claims and their equivalents. Furthermore, it is contemplated
that a
particular feature described either individually or as part of an example can
be combined
with other individually described features, or parts of other examples, even
if the other
features and examples make no mentioned of the particular feature. Thus, the
absence of
describing combinations should not preclude having rights to such
combinations.
For reasons of completeness, various aspects of the disclosure are set out in
the following
numbered clauses:
Clause 1. A network computing system comprising:
one or more processors;
a memory to store a set of instructions;
wherein the one or more processors access the instructions to:
receive a plurality of order requests, each order request originating from a
corresponding requester device of the plurality of requester devices and
specifying
a respective supplier of a plurality of suppliers;
for each of the plurality of order requests, select a service provider from a
pool of available service providers, to transport a corresponding delivery
order
from a corresponding supplier to a location of the requester;
determine a provisioning level indicator for a given region in a given time
interval by communicating with a plurality of requester devices and a
plurality of
provider devices;
26
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
wherein the one or more processors select the service provider for each of
the plurality of order requests by implementing, based at least in part on the
determined provisioning level indicator, decision logics to determine whether
individual delivery orders, generated in response to respective order
requests, can
be batched for delivery to respective requesters.
Clause 2. The network computing system of clause 1, wherein the decision
logics
includes at least 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.
Clause 3. The network computing system of clause 2, wherein the at least a
first
timing criterion includes a difference between when each delivery order is
ready at a
given supplier being less than a designated threshold.
Clause 4. The network computing system of clause 2, wherein the at least a
first
timing criterion includes an estimated time of delivery of each of the
multiple orders
being less than a predetermined limit.
Clause 5. The network computing system of clause 2, wherein the at least
first
timing criterion includes a travel distance between a location of a respective
requester of
each of the multiple orders being less than a designated threshold.
Clause 6. The network computing system of clause 2, wherein the first
decision logic
is less restrictive than at least a second decision logic, such that a greater
number of
batched delivery orders result when the one or more processors implement the
first
decision logic.
Clause 7. The network computing system of clause 6, wherein each of the
first
decision logic and the second decision logic, when implemented, batch multiple
delivery
orders for delivery to respective requesters based at least in part on the
multiple delivery
orders satisfying at least a respective timing criterion, and wherein the
respective timing
criterion of the first decision logic is based on a longer measure of time as
compared to
the respective timing criterion of the second decision logic.
27
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
Clause 8. The network computing system of clause 1, wherein the
provisioning level
indicator is deemed to be indicative of a surge in order requests for an
upcoming time
interval.
Clause 9. The network computing system of clause 1, wherein the one or more
processors determine the provisioning level indicator by detecting a number of
requester
devices that launch a service application from which a order request can be
made, in a
time interval that precedes the given time interval.
Clause 10. The network computing system of clause 1, wherein the one or
more
processors determine the provisioning level indicator by detecting a number of
requester
devices that are running a service application from which a order request can
be made, in
a time interval that precedes the given time interval.
Clause 11. The network computing system of clause 1, wherein the one or
more
processors determine the provisioning level by estimating, for the given
region, at least
one of a number of order requests and a number of available service providers,
during a
time interval that precedes the given time interval.
Clause 12. The network computing system of clause 1, wherein the one or
more
processors access the instructions to determine an arrival time for a service
provider of a
batched set of delivery orders to arrive at a supplier of the batched set of
delivery orders.
Clause 13. The network computing system of clause 12, wherein the one or
more
processors assign a service provider for the batched set of delivery orders
based at least in
part on the determined arrival time.
Clause 14. The network computing system of clause 12, wherein the one or
more
processors determine the arrival time based at least in part on an estimated
order
preparation time for the supplier and each of the delivery orders of the
batched set.
Clause 15. A method for fulfilling order requests, the method being
implemented by
one or more processors and comprising:
28
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
for each of a plurality of order requests, selecting a service provider from a
pool of
available service providers, to transport a corresponding delivery order from
a
corresponding supplier to a location of the requester;
determining a provisioning level indicator for a given region in a given time
interval by communicating with a plurality of requester devices and a
plurality of
provider devices; and
wherein selecting the service provider includes batching multiple delivery
orders
resulting from the plurality of order requests with a given service provider,
in accordance
with a set of rules that are based at least in part on the determined
provisioning level.
Clause 16. The method of clause 15, wherein batching multiple delivery
orders
includes selecting at least two delivery orders to be batched based on a
timing parameter.
Clause 17. The method of clause 16, wherein determining the timing
parameter based
at least in part on the determined provisioning level.
Clause 18. The method of clause 16, wherein the timing parameter sets a
time limit
for each delivery order of multiple batched delivery orders being delivered to
a
corresponding location of the corresponding order request.
Clause 19. The method of clause 15, wherein determining the provisioning
level
indicator includes forecasting the provisioning level indicator for an
upcoming time
interval.
Clause 20. A non-transitory computer-readable medium that stores
instructions, which
when executed by one or more processors of a network computer system cause the
network computer system to perform operations that include:
for each of the plurality of order requests, selecting a service provider from
a pool
of available service providers, to transport a corresponding delivery order
from a
corresponding supplier to a location of the requester; and
determining a provisioning level indicator for a given region in a given time
interval by communicating with a plurality of requester devices and a
plurality of
provider devices; and
29
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
wherein selecting the service provider includes batching multiple delivery
orders resulting from the plurality of order requests with a given service
provider,
in accordance with a set of rules that are based at least in part on the
determined
provisioning level.
Clause 21. A network computing system comprising:
one or more processors;
a memory to store a set of instructions;
wherein the one or more processors access the instructions to:
arrange transport for delivery orders in a given region, in accordance with
a set of provisioning parameters, including A) receiving a plurality of
delivery
requests, each delivery request originating from a corresponding requester
device
and specifying a respective supplier of a plurality of suppliers; and B)
matching
each of the plurality of delivery requests to a respective service provider,
to
transport a corresponding delivery order from the respective supplier to a
location
of the respective requester of the delivery request;
wherein the set of provisioning parameters includes a service value
parameter, and at least one of a service batching parameter or a service
range parameter;
determine, for an upcoming time interval, a forecast for at least one of a
number of service requests or a number of available service providers;
determine a provisioning level for the given region during the upcoming
time interval, based at least in part on the forecast; and
change the set of provisioning parameters to adjust the provisioning level
to a desired target.
Clause 22. The network computing system of clause 21, wherein the one or
more
processors change the set of provisioning parameters by increasing a time
interval to
match two or more delivery orders from a supplier, in order to increase a
number of
batched delivery orders.
Clause 23. The network computing system of clause 21, wherein the one or
more
processors change the set of provisioning parameters by increasing or
decreasing a
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
service range that defines a distance between individual requesters and
available
suppliers.
Clause 24. The network computing system of clause 21, wherein the one or
more
processors change the set of provisioning parameters by performing an
optimization
process to identify one or more values for one or more of the provisioning
parameters of
the set, to optimize a number of delivery requests that are serviced in a
given duration of
time.
Clause 25. The network computing system of clause 21, wherein the one or
more
processors change the set of provisioning parameters by changing a value of a
service
value parameter.
Clause 26. The network computing system of clause 21, wherein the one or
more
processors implement one or more operations to increase a number of available
service
providers in the given region during the upcoming time interval.
Clause 27. The network computing system of clause 26, wherein the one or
more
operations include generating an incentive for available service providers in
a nearby
region to provide delivery service in the given region.
Clause 28. The network computing system of clause 21, wherein the service
range
parameter defines a maximum distance of travel from a location of a respective
supplier
and a delivery location, and (ii) a service value parameter that defines a
credit that is
allocated to the service provider for transporting the delivery order from the
location of
the respective supplier and the delivery location, and wherein the one or more
processors
change the set of provisioning parameters to adjust the provisioning level by
adjusting the
service range parameter and the provisioning level parameter.
Clause 29. A method for providing a delivery service, the method being
implemented
by one or more processors and comprising:
arranging transport for delivery orders in a given region, in accordance with
a set
of provisioning parameters, including A) receiving a plurality of delivery
requests, each
delivery request originating from a corresponding requester device and
specifying a
31
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
respective supplier of a plurality of suppliers; and B) matching each of the
plurality of
delivery requests to a respective service provider, to transport a
corresponding delivery
order from the respective supplier to a location of the respective requester
of the delivery
request;
wherein the set of provisioning parameters includes a service value
parameter, and at least one of a service batching parameter or a service range
parameter;
determining, for an upcoming time interval, a forecast for at least one of a
number
of service requests or a number of available service providers;
determining a provisioning level for the given region during the upcoming time
interval, based at least in part on the forecast; and
changing the set of provisioning parameters to adjust the provisioning level
to a
desired target.
Clause 30. The method of clause 29, wherein changing the set of
provisioning
parameters includes changing a time interval to match two or more order
requests from a
supplier, in order to increase a number of batched delivery orders.
Clause 31. The method of clause 29, wherein changing the set of
provisioning
parameters includes increasing or decreasing a service range that defines a
distance
between individual requesters and available suppliers.
Clause 32. The method of clause 29, wherein changing the set of
provisioning
parameters includes performing an optimization process to optimize a number of
delivery
requests that are serviced in a given duration of time.
Clause 33. The method of clause 29, wherein changing the set of
provisioning
parameters includes increasing a value of a service value parameter.
Clause 34. The method of clause 29, further comprising implementing one or
more
operations to change a number of available service providers in the given
region during
an upcoming time interval to adjust the provisioning level to the desired
target.
32
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
Clause 35. The method of clause 34, wherein the one or more operations
include
generating an incentive for available service providers in a nearby region to
provide
delivery service in the given region.
Clause 36. The method of clause 29, wherein the service range parameter
that defines
a maximum distance of travel from a location of a respective supplier and a
delivery
location, and the service value parameter defines a credit that is allocated
to the service
provider for transporting the delivery order from the location of the
respective supplier
and the delivery location, and wherein changing the set of provisioning
parameters to
adjust the provisioning level includes adjusting the service range parameter
and the
provisioning level parameter.
Clause 37. A non-transitory computer-readable medium that stores
instructions, which
when executed by one or more processors of a network computer system cause the
network computer system to perform operations that include:
arranging transport for delivery orders in a given region, in accordance with
a set
of provisioning parameters, including A) receiving a plurality of delivery
requests, each
delivery request originating from a corresponding requester device and
specifying a
respective supplier of a plurality of suppliers; and B) matching each of the
plurality of
delivery requests to a respective service provider, to transport a
corresponding delivery
order from the respective supplier to a location of the respective requester
of the delivery
request;
wherein the set of provisioning parameters includes a service value
parameter, and at least one of a service batching parameter or a service range
parameter;
determining, for an upcoming time interval, a forecast for at least one of a
number
of service requests or a number of available service providers;
determining a provisioning level for the given region during the upcoming time
interval, based at least in part on the forecast; and
changing the set of provisioning parameters to adjust the provisioning level
to a
desired target.
Clause 38. The non-transitory computer-readable medium of clause 37,
wherein
changing the set of provisioning parameters includes changing a time interval
to match
33
Amended Sheet ¨ IPEA/SG
CA 03080498 2020-04-24
International Application Number: US2018058554
Article 34 Amendments
submitted with Demand for IPEA dated 31 Aug 2019
SUBSTITUTE SHEET
two or more order requests from a supplier, in order to increase a number of
batched
delivery orders.
Clause 39. The non-transitory computer-readable medium of clause 37,
wherein
changing the set of provisioning parameters includes increasing or decreasing
a service
range that defines a distance between individual requesters and available
suppliers.
Clause 40. The non-transitory computer-readable medium of clause 37,
wherein
changing the set of provisioning parameters includes performing an
optimization process
to optimize a number of delivery requests that are serviced in a given
duration of time.
34
Amended Sheet ¨ IPEA/SG
