Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02839208 2014-01-15
ORDER PROCESSING FOR REMOTELY ORDERED GOODS
TECHNICAL FIELD
[0001] The present disclosure relates to ordering systems for ordering goods,
and more
particularly to scheduling of order processing for remotely ordered goods and
organizing the
completed orders. The present disclosure also relates to obtaining dynamic
arrival estimates
for arrival at a destination.
BACKGROUND
[0002] There are many remote ordering systems available that allow a user to
place an order
for goods using a networked mobile wireless telecommunication computing
device, such as a
smartphone. However, these systems do not account for the fact that the travel
time and the
preparation time may be different, resulting either in loss of quality or the
individual having to
wait. For example, before leaving work a user could use his or her smartphone
to place an
online order for food to be picked up from a restaurant, such as a pizzeria or
a quick service
restaurant, either on his or her lunch break or on the way home. However, in
most cases the
user will arrive at the restaurant either to find that the food has been ready
for some time and
is rapidly losing heat and freshness, or else the user will have to wait for
the food to be ready,
wasting valuable time.
[0003] Moreover, if the user arrives at the restaurant during a busy time,
such as the lunch or
dinner rush, there may be considerable disorganization and disorder. One
possible solution is
to provide a dedicated position within the restaurant for users picking up
remote orders.
However, even if a dedicated position is provided, where a large number of
users have used
their smartphones to place remote food orders and arrive at the restaurant
around the same
time, the restaurant staff must still match the orders to the respective
users, which takes time.
Even if the food is ready and fresh when the user arrives, the time taken for
the restaurant staff
to isolate a particular user's order from a large number of other remotely
placed orders can be
significant. This tends to defeat the purpose of placing a remote order in
advance, and leads
to irritation of the user and may also allow the food quality to degrade, even
if it happened to
have been ready precisely when the user arrived.
- 1 -
CA 02839208 2014-01-15
SUMMARY
[0004] A user can use a networked computing device, for example a networked
mobile
wireless telecommunication computing device such as a smartphone, to identify
a suitable
location of a provider of goods, view a list of items available from the
provider, and generate
an order for goods in advance. The completed orders are organized according to
the expected
order of arrival of the users so when a user arrives, his or her order can be
easily pulled and
presented. Preferably, in cases where the goods are of a type which degrade
fairly rapidly
after preparation, processing of the order is also timed so that the order
will generally be
completed at about the same time as the user arrives.
[0005] One method for processing a plurality of orders for goods at a provider
location
comprises (i) obtaining arrival estimates for when each of a plurality of
users is expected to
arrive, with each user associated with a respective order, (ii) using the
arrival estimates to
schedule processing of the orders, (iii) obtaining an arrival sequence
estimate for the users
indicating a sequence in which the users are expected to arrive, (iv)
processing the orders to
produce completed orders, and (v) organizing the completed orders according to
the arrival
sequence estimate.
[0006] Another method for processing a plurality of orders for goods at a
provider location
comprises (i) obtaining an arrival sequence estimate for each of a plurality
of users indicating
a sequence in which the users are expected to arrive, with each user
associated with a
respective order, (ii) using the arrival sequence estimate to schedule
processing of the orders,
(iii) processing the orders to produce completed orders, and (iv) organizing
the completed
orders according to the arrival sequence estimate.
[0007] A method for fulfilling a plurality of orders for goods at a provider
location comprises
(i) obtaining an arrival sequence estimate for each of a plurality of users
indicating a sequence
in which the users are expected to arrive, with each user associated with a
respective order,
and (ii) organizing completed orders according to the arrival sequence
estimate.
- 2 -
CA 02839208 2014-01-15
[0008] Preferably, the arrival sequence estimate is continuously updated and
the step of
organizing completed orders according to the arrival sequence estimate is
repeated responsive
to a change in the arrival sequence estimate.
[0009] Processing the orders to produce completed orders may comprise assembly
of
components of the orders into the completed orders.
[0010] The arrival sequence estimate may be obtained by ordering users
according to their
respective radial distances from a target. The radial distances may be
obtained using location
information received from networked mobile wireless telecommunication
computing devices
carried by the users. The location information may comprise, for example,
global positioning
system coordinates and/or cellular repeater triangulation coordinates.
[0011] In one embodiment, a two-stage process is used to determine an arrival
estimate for a
travelling target, such as a user travelling to a provider to pick up a
remotely placed order for
goods. The first stage uses conventional map-based techniques to estimate how
long it will
take the target to traverse an expected path toward the destination along a
series of roads,
sidewalks or other constrained paths, for example a user walking, driving or
bicycling to a
provider location. The second stage estimates how long it will take the target
to travel to the
destination along a direct linear path, for example a user walking from a
parking lot into the
provider location.
[0012] A computer-implemented method for obtaining a dynamic arrival estimate
for arrival
at a destination comprises, during at least a first trip portion comprising
travel within a
constrained travel path network, calculating the dynamic arrival estimate
based on an expected
travel path toward the destination through the constrained travel path
network, and during at
least a second trip portion subsequent to the first trip portion, calculating
the dynamic arrival
estimate based on a radial distance from the destination.
[0013] A transition from the first trip portion to the second trip portion may
be determined,
for example, by detecting a departure from the constrained travel path network
or by the
dynamic arrival estimate falling below a predetermined threshold.
- 3 -
CA 02839208 2014-01-15
[0014] Data processing systems and computer program products for implementing
the above
methods are also described.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] These and other features will become more apparent from the following
description in
which reference is made to the appended drawings wherein:
FIGURE 1 is a flow chart showing generally a first exemplary method for
scheduling
processing of an order for goods at a provider location;
FIGURE lA is a flow chart showing a method that is a particular exemplary
embodiment of
the method of Figure 1;
FIGURE 2 is a flow chart showing a first exemplary implementation of the
method of Figure
1A;
FIGURE 2A is a flow chart showing a second exemplary implementation of the
method of
Figure 1A;
FIGURE 3A shows a schematic representation of a first exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider;
FIGURE 3B shows a schematic representation of a second exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider;
FIGURE 3C shows a schematic representation of a third exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider;
FIGURE 3D shows a schematic representation of a fourth exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider;
FIGURE 3E shows a schematic representation of a fifth exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider;
- 4 -
CA 02839208 2014-01-15
FIGURE 4A shows schematically the operation of a communication process for the
embodiment shown in Figure 3A;
FIGURE 4B shows schematically the operation of a communication process for the
embodiment shown in Figure 3B;
FIGURE 4C shows schematically the operation of a communication process for the
embodiment shown in Figure 3C;
FIGURE 4D shows schematically the operation of a communication process for the
embodiment shown in Figure 3D;
FIGURE 4E shows schematically the operation of a communication process for the
embodiment shown in Figure 3E;
FIGURE 5A shows a schematic representation of a first exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider
aggregator;
FIGURE 5B shows a schematic representation of a second exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider
aggregator;
FIGURE 5C shows a schematic representation of a third exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider
aggregator;
FIGURE 5D shows a schematic representation of a fourth exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider
aggregator;
FIGURE 5E shows a schematic representation of a fifth exemplary arrangement
for
implementing a method for scheduling processing of an order by a provider
aggregator;
FIGURE 6 is a flow chart illustrating a first exemplary implementation of the
method of
Figure 2;
- 5 -
CA 02839208 2014-01-15
FIGURE 6A is a flow chart illustrating a first exemplary implementation of the
method of
Figure 2A;
FIGURE 6B is a flow chart illustrating a second exemplary implementation of
the method of
Figure 2A;
FIGURE 7 is a flow chart illustrating a second exemplary implementation of the
method of
Figure 2;
FIGURE 7A is a flow chart illustrating a third exemplary implementation of the
method of
Figure 2A;
FIGURE 7B is a flow chart illustrating a fourth exemplary implementation of
the method of
Figure 2A;
FIGURE 8 illustrates schematically an arrangement and method for communicating
at least
one commercial solicitation;
FIGURE 9 is a schematic representation of an exemplary smartphone, which may
be used in
implementing various methods described herein;
FIGURE 10 is a schematic representation of an exemplary computer system, which
may be
used in implementing various methods described herein;
FIGURE 11 is a flow chart showing a first exemplary method for processing a
plurality of
orders for goods at a provider location;
FIGURE 11A is a flow chart showing a second exemplary method for processing a
plurality
of orders for goods at a provider location;
FIGURE 12A is a schematic representation showing a first exemplary method for
obtaining an
arrival sequence estimate;
- 6 -
CA 02839208 2014-01-15
FIGURE 12B is a schematic representation showing a second exemplary method for
obtaining
an arrival sequence estimate;
FIGURE 13 is a flow chart showing an exemplary computer-implemented method for
obtaining a dynamic arrival estimate for arrival at a destination;
FIGURE 14 is a flow chart showing a third exemplary method for processing a
plurality of
orders for goods at a provider location;
FIGURE 14A is a flow chart showing an exemplary method for fulfilling a
plurality of orders
for goods at a provider location;
FIGURE 15A shows a main landing page for an exemplary remote ordering
application;
FIGURE 15B shows an exemplary search results page of the remote ordering
application of
Figure 15A, returning search results for local providers in list form;
FIGURE 15C shows an exemplary search results page of the remote ordering
application of
Figure 15A, returning search results for local providers in map form;
FIGURE 15D shows an exemplary favourites page of the remote ordering
application of
Figure 15A, listing favourite orders;
FIGURE 15E shows an exemplary orders page of the remote ordering application
of Figure
15A, listing saved orders;
FIGURE 15F shows an exemplary orders page of the remote ordering application
of Figure
15A, listing active orders;
FIGURE 15G shows an exemplary menu page of the remote ordering application of
Figure
15A, for placing an order after a provider is selected;
FIGURE 15H shows an exemplary menu item detail page of the remote ordering
application
of Figure 15A;
- 7 -
CA 02839208 2014-01-15
FIGURE 151 shows a check-out menu page of the remote ordering application of
Figure 15A;
FIGURE 15J shows an exemplary link page of the remote ordering application of
Figure 15A,
generated responsive to selection of a "link" button in the page of Figure
151;
FIGURE 15K shows an exemplary navigation information page of the remote
ordering
application of Figure 15A, with navigation information presented as a map;
FIGURE 15L shows an exemplary navigation information page of the remote
ordering
application of Figure 15A, with navigation information presented as a list of
written
directions;
FIGURE 15M shows an exemplary "offers" page of an exemplary remote ordering
application;
FIGURE 16A shows an exemplary page for a "Pending Orders" function of an
exemplary
provider order fulfillment support application;
FIGURE 16B shows an exemplary page for a "New Orders" function of the provider
order
fulfillment support application of Figure 16A;
FIGURE 16C shows an exemplary page for a "Preparation" function of the
provider order
fulfillment support application of Figure 16A;
FIGURE 16D shows an exemplary page for an "Incoming Orders" function of the
provider
order fulfillment support application of Figure 16A; and
FIGURE 16E shows an exemplary page for a "Completed Orders" function of the
provider
order fulfillment support application of Figure 16A.
DETAILED DESCRIPTION
[0016] As described and illustrated herein systems, methods and computer
program products
are provided for scheduling processing at a provider location of an order
associated with a
user, typically so that completion of processing of the order substantially
coincides with
- 8 -
CA 02839208 2014-01-15
arrival of the user at the provider location. These systems, methods and
computer program
products have particular application in the processing of orders for goods
that spoil rapidly,
such as in quick service restaurants, although they are not limited to these
applications and
may also be used, for example, in stores selling groceries or merchandise that
is not subject
rapid spoilage or degradation. In addition, various embodiments facilitate
organization of the
completed orders according to the sequence in which the users are expected to
arrive, so as to
improve the efficiency of order pickup. The approaches described herein may
have
environmental benefits, for example by reducing the amount of time spent
idling in a drive-
through line.
[0017] Referring first to Figure 1, an exemplary method for scheduling
processing of an order
for goods at a provider location is shown generally at 100. The method 100 is
generally
implemented by a computer system. In some embodiments, the method 100 may be
implemented by a networked mobile wireless telecommunication computing device
such as a
smartphone or tablet computer; in other embodiments the method 100 may be
implemented by
server-type data processing systems such as order processing systems
associated with a
provider.
[0018] At step 102, the method 100 obtains an arrival estimate for when a user
associated
with the order is expected to arrive at the provider location, and at step
106, the method 100
uses the arrival estimate to schedule processing of the order. Physical
processing of the order
at the provider location may then proceed according to the scheduling
determined at step 106.
[0019] As described in greater detail below, an arrival estimate may be
obtained by using
position information derived from a global positioning system (GPS) navigation
system, from
an address input manually into a data processing system by a user, from
wireless triangulation,
from information from a local Internet Service Provider (ISP) or by any other
suitable
technique.
[0020] Embodiments of the method 100 in Figure 1 relying on only a single,
initial arrival
estimate, without using any estimate relating to how long the order will take
to process, may
- 9 -
CA 02839208 2014-01-15
advantageously be used to efficiently schedule the sequence of order
processing for multiple
users in situations where spoilage or degradation of the goods being prepared
is unlikely to be
an issue. For example, two users may have submitted orders for substantially
non-perishable
goods that are to be picked up from a provider location where only a single
stock picker is
available, and the respective arrival estimates indicate that one user will
arrive in ten minutes
and the other user will arrive in twenty minutes. The method 100 in Figure 1
could be used to
schedule processing of these two orders, with the order for the user who is
ten minutes away
being processed before the order for the user who is twenty minutes away. In
this
embodiment, it is not necessary to update the arrival estimate, since the
goods will not spoil or
degrade if the arrival estimate is somewhat inaccurate.
[0021] Preferably, using the arrival estimate to schedule processing of the
order at step 106
comprises using the arrival estimate to schedule processing of the order so
that completion of
processing of the order is expected to substantially coincide with arrival of
the user at the
provider location. In one embodiment, the method 100 may determine a
processing start time
so that arrival of the user is expected to coincide with completion of order
processing. For
example, where the arrival estimate is a time of day (e.g. 1:47 p.m.) that the
user is expected
to arrive at the provider location, the method 100 may use the arrival
estimate to retrieve a
start time for processing the order from a look-up table. The start times in
the lookup tables
may be based solely on the arrival estimate (time of day), or may be based on
the arrival
estimate (time of day) and some indication of the size of the order, such as
the number of
items in the order or the cost of the order. Thus, the lookup table may
comprise rows
corresponding to times of day (or ranges thereof) and columns corresponding to
cost (or
ranges thereof) for the order, and the start time may be retrieved from the
cell that is in the
row corresponding to the arrival estimate and in the column corresponding to
the cost of the
order.
[0022] Figure lA shows an exemplary method 100A for scheduling processing of
an order for
goods at a provider location. The method 100A in Figure 1A is a particular
implementation of
the method 100 in Figure 1, with the same reference numerals referring to
corresponding
steps. The method 100A uses an order completion estimate, in addition to the
arrival
-10-
CA 02839208 2014-01-15
estimate, to schedule processing of the order so that completion of processing
of the order is
expected to substantially coincide with arrival of the user at the provider
location. Thus, at
step 104 the method 100A obtains an order completion estimate for when
processing of the
order is expected to be completed, and at step 106 the method 100A uses both
the arrival
estimate and the order completion estimate to schedule processing of the
order. The order
completion estimate could be a fixed value (e.g. in a fast food restaurant
most orders can be
completed in less than three minutes), may be obtained from a lookup table
based on the size
of the order (e.g. number of items or cost of the order), or may be calculated
dynamically from
the items in the order. Steps 102 and 104 may be performed in any order.
[0023] In one embodiment, where the arrival estimate is a time of day and the
order
completion estimate is a duration (e.g. a number of minutes), processing of
the order may be
scheduled by simply subtracting the order completion estimate from the arrival
estimate. For
example, if the arrival estimate is 1:50 p.m. and the order completion
estimate is six minutes,
processing of the order could be scheduled to begin at 1:44 p.m. so that
completion of order
processing is expected to coincide with arrival of the user at the provider
location at 1:50 p.m.
In this embodiment, the arrival estimate and the order completion estimate are
not directly
compared to one another, and the arrival estimate and the order completion
estimate are not
updated.
[0024] In other embodiments, using the arrival estimate and the order
completion estimate to
schedule processing of the order (step 106A) comprises comparing the arrival
estimate and the
order completion estimate and updating at least one of the arrival estimate
and the order
completion estimate, such that the then-current arrival estimate and the then-
current order
completion estimate are compared. In cases where the goods being ordered will
perish or
degrade rapidly once prepared, such as in a quick service or "fast food"
restaurant, it may be
important to obtain updates to arrival estimate and/or the order completion
estimate to
enhance precision of the scheduling. Updating of the arrival estimate may be
particularly
important in this context, as a user may encounter unexpected delays, such as
traffic
congestion. If only an initial arrival estimate is used, a food order whose
preparation was
scheduled so that order completion coincides with the original arrival
estimate may in fact be
-11-
CA 02839208 2014-01-15
spoiled or degraded when a delayed user actually arrives. Additionally, an
initial order
completion estimate may become inaccurate if not updated, for example if there
are
significant changes in volume at a provider location, which may create a
backlog or a
temporary shortage of some items.
[0025] Reference is now made to Figure 2, which shows an exemplary method 200
for
scheduling processing of an order for goods at a provider location. The
exemplary method
200 is a first exemplary implementation of the method 100A of Figure 1A.
[0026] At step 202, an order for goods is received. The order will be
associated with a
provider location where the order is to be processed, as well as being
associated with a user
who is to pick up the order. For example, the order may specify the provider
location by
allowing the user to select from a list of provider locations when submitting
the order. The
list may be based on the user's present location. In some embodiments, the
order may be
entered into the user's data processing system, such as a home computer or a
networked
mobile wireless telecommunication computing device such as a smartphone, and
the user's
data processing system may complete all of the steps of the method 200. In
other
embodiments, the order may be received at a data processing system associated
with the
provider, and the method 200 would be executed by the data processing system
associated
with the provider. A data processing system associated with a provider may be,
for example
the order processing system for the provider location that is to process the
order for goods, or
a central order processing system for a plurality of provider locations (e.g.
a restaurant chain
having a plurality of locations), or a data processing system of a provider
aggregator that
processes orders for a plurality of different providers, each of which may
have one or more
provider locations.
[0027] At step 204, which corresponds to step 102 of the method 100A in Figure
1A, the
method 200 obtains an arrival estimate for when the user associated with the
order is expected
to arrive at the provider location that is processing the order. The arrival
estimate is
associated with the order for goods received at step 102. The arrival estimate
may be, for
example, an estimated travel time of the user to the provider location from
the user's current
-12-
CA 02839208 2014-01-15
location, or an estimated arrival time of the user at the provider location,
based on the user's
current location. The arrival estimate may be obtained in a number of ways.
Typically, the
arrival estimate will be based on the user's initial location, using
conventional map-based
navigation technology such as that used in GPS navigation systems or Internet-
based travel
calculation systems like Google Maps or MapQuest to determine an estimated
travel time (e.g.
15 minutes) to, or estimated time of arrival (e.g. 9:15 a.m.) at, the provider
location. Such
calculations may take into account factors such as time of day, traffic
patterns, and the like, as
is known in the art. For example, where the order is initially entered into a
GPS-equipped
smartphone, the smartphone may use its GPS system to determine the initial
location, that is,
the current location of the smartphone. The smartphone could then use
appropriate software to
calculate an initial arrival estimate, which the smartphone could then use in
implementing the
method 200, or transmit to a data processing system associated with the
provider where the
method 200 is being implemented by the latter data processing system.
Alternatively, where
the method 200 is being implemented by a data processing system associated
with the
provider, the smartphone may simply determine and transmit its current
location to the data
processing system associated with the provider. Other techniques for obtaining
an initial
location to use in calculating the arrival estimate include cellular
triangulation, determination
from ISP data, and manual entry of a location.
[0028] Map-based navigation technology determines an expected travel path that
the user will
follow along the various roads and calculates the expected trip duration based
on the expected
speed on each travel path segment. This approach generally assumes that the
trip is complete
when an object has arrived at the street address associated with the
destination, and therefore
generally does not account for time taken to park a vehicle or walk to a
provider location. As
a result, map-based trip duration estimates may underestimate the total travel
time. Where the
address used as the destination for a map-based trip duration estimate is
imprecise, such as the
street address for a large shopping mall, this underestimate may be
considerable.
Accordingly, arrival estimates generated using map-based navigation technology
will
preferably be adjusted to account for these additional portions of the trip.
These adjustments
may be a fixed value, for example assuming that it will take three minutes to
park the car and
-13-
CA 02839208 2014-01-15
walk to the provider building, or may be generated dynamically, as described
in greater detail
below.
[0029] At step 206, which corresponds to step 104 of the method 100A in Figure
1A, the
method 200 obtains an order completion estimate for when processing of the
order is expected
to be completed. Like the arrival estimate, the order completion estimate is
also associated
with the order for goods received at step 102. The order completion estimate
may be, for
example, an estimated duration of the processing of the order (e.g. 4
minutes), or an estimated
completion time for the order (e.g. 12:06 p.m.) given a specified start time
for the order when
the order processing will be complete. The order completion estimate may be
generated in a
number of different ways.
[0030] As noted above, in some embodiments a fixed value may be used as the
order
completion estimate. For example, where the method 200 is to be used in
conjunction with a
fast food restaurant, the order completion estimate may be set to a constant
value based on the
length of time for preparing a typical order and which will provide an
adequate estimate for
most cases. Thus, if in a particular fast food restaurant 90% of orders can be
completed in
three minutes or less, a constant value of three minutes may be used as the
order completion
estimate. If the order is completed sooner (e.g. one and a half or two
minutes) spoilage will
not be an issue (as compared to the three minute estimate), and those cases
that take longer
(e.g. four or five minutes) are unlikely to keep the user waiting for a
substantial period of
time.
[0031] In other embodiments, the order completion estimate may be generated
dynamically.
A dynamically generated order completion estimate may be based on the time of
day, the
number and/or type of items ordered, the current staffing level at the
relevant provider
location, the current volume of business at the relevant provider location, or
some
combination of the foregoing as well as other relevant factors.
[0032] In some embodiments, orders may be treated as a unit for the purpose of
scheduling
processing where this will not have a substantial adverse effect on quality.
In such
-14-
CA 02839208 2014-01-15
embodiments, the order completion estimate may be the longest estimated
preparation time of
the components contained in the order. For example, if an order is for a
hamburger, drink and
fries and the estimated preparation time for the hamburger is three minutes
while the
estimated preparation time for the drink and fries are one minute each, the
order completion
estimate may be three minutes (since the menu items can be processed in
parallel) and
scheduling is based on that three minute estimate, with processing of each
component
beginning at the same time. In other embodiments, orders may be broken down
into
components, with processing of each component being scheduled separately. In
particular, the
order completion estimate may comprise a component completion estimate for
each
component (or group of components) of an order, with processing of individual
components
(or groups of components) being scheduled separately. For example, in a food
order whose
components include a well-done steak and an ice cream sundae, it is preferable
to begin
cooking the steak well before beginning to make the ice cream sundae.
[0033] In some embodiments that are particularly well suited to restaurant
applications, the
estimated preparation time for each menu item can be varied based on volume.
For example,
the nominal estimated preparation time for a hamburger may be three minutes
but might be
increased to five minutes during peak hours. This increase can be triggered
automatically at
the appropriate times, or manually, and may be applied to individual menu
items separately or
universally to all menu items.
[0034] Although Figure 2 shows step 204 being performed before step 206, in
other
embodiments step 206 may be performed before step 204.
[0035] Steps 208 and 210 together correspond to step 106A of the method 100A
shown in
Figure 1. At step 208, the method 200 compares the arrival estimate and the
order completion
estimate. In response to a determination at step 208 that the arrival estimate
and the order
completion estimate substantially coincide, the method 200 proceeds to step
220 and provides
a signal to commence processing of the order. Step 220 will typically comprise
transmitting
either the order itself, or a signal to commence processing of the order, to a
provider or a
particular provider location that will process the order.
-15-
CA 02839208 2014-01-15
[0036] Several methodologies may be used to determine whether the arrival
estimate and the
order completion estimate substantially coincide. In a preferred embodiment,
the arrival
estimate and the order completion estimate will be considered to substantially
coincide when
they are within a predetermined threshold from one another, for example one or
two minutes.
Where both the order completion estimate and the arrival estimate are times of
day, or both
the order completion estimate and the arrival estimate are time periods (e.g.
an estimated
processing time and an estimated travel time, respectively), they may be
compared directly.
Where the arrival estimate and the order completion estimate are in different
forms, such as
where one is a time of day and the other is a time period, they may be
prepared for comparison
by converting one to the other. For example, if the arrival estimate is a time
period but the
order completion estimate is a time of day, the arrival estimate can be
converted to a time of
day by adding the time period to the current time of day, or the order
completion estimate can
be converted to a time period by subtracting the current time of day
therefrom.
[0037] In some instances, a user will be close enough to the provider location
that will
process the order that it will take longer to process the order than it will
for the user to arrive
at that provider location. It is therefore preferred that at step 208, the
arrival estimate and the
order completion estimate are deemed to coincide when comparing the arrival
estimate and
the order completion estimate indicates that the user associated with the
order is expected to
arrive at the provider location before the order is expected to be completed.
Thus, for
example, in response to a determination at step 208 that the estimated
processing time for the
order is approximately equal to or exceeds the initial estimated travel time,
the method 200
would proceed to step 220 and provide a signal to commence processing of the
order for
goods. This procedure will cause order processing to commence substantially
immediately
following receipt of the order so as to minimize the amount of time that the
user will have to
wait. In addition, in such situations the method 200 may notify the user that
they are closer to
the provider location than the estimated processing time, and may also
continue to compare
the arrival estimate and the order completion estimate and notify the user
when he or she
should depart so that his or her arrival will substantially coincide with
order completion.
-16-
CA 02839208 2014-01-15
[0038] In response to a determination at step 208 that the arrival estimate
and the order
completion estimate do not substantially coincide, the method 200 proceeds to
step 210 and
obtains an updated arrival estimate, an updated order completion estimate, or
obtains both an
updated arrival estimate and an updated order completion estimate.
[0039] Step 210A shows updating of the order completion estimate, and step
210B shows
updating of the arrival estimate; when both steps 210A and 210B are carried
out these steps
may be carried out in any order. Either step 210A or step 210B may be omitted
in appropriate
circumstances. For example, where the arrival estimate and the order
completion estimate are
both represented as a time of day, step 210B may be omitted and the arrival
estimate may be
held constant with only the order completion estimate being updated (step
210A), since the
order completion estimate will depend on the time at which processing begins.
In this
situation, updating the order completion estimate at step 210A would comprise
updating the
start time upon which the order completion estimate is based. In another
example, where the
arrival estimate and the order completion estimate are both represented as a
time period or
duration, step 210A may be omitted and the order completion estimate may be
held constant,
with only the arrival estimate being updated (step 210B), since the time
period that is the
arrival estimate in this case will generally decrease as time elapses. In this
situation, updating
the arrival estimate may comprise decrementing the previous arrival estimate
based on the
amount of time that has elapsed, i.e. counting down. Thus, where the arrival
estimate is an
estimated travel time, determining the updated estimated travel time may
comprise
decrementing a most recent previously estimated travel time by an interval
substantially equal
to the time elapsed since determination of the most recent previously
estimated travel time.
Alternatively, updating the arrival estimate may comprise executing a new
calculation of the
arrival estimate. In such an embodiment, where the arrival estimate is an
estimated travel
time, obtaining the updated estimated travel time may comprise, in the case of
a networked
mobile wireless telecommunication computing device, updating the current
location,
calculating the updated estimated travel time from the updated location, the
provider location
and an updated travel route between the updated location and the provider
location, for
example from an onboard GPS system. Where the arrival estimate is an estimated
travel time
-17-
CA 02839208 2014-01-15
and the method 200 is being executed by a data processing system associated
with a provider,
updating the estimated travel time by the data processing system may comprise
the data
processing system querying a mobile wireless telecommunication computing
device
associated with the user, receiving, in response to the query, an
identification of an updated
location, and then the data processing system calculating the updated
estimated travel time
from the updated location, the provider location and an updated travel route
between the
updated location and the provider location. The updated travel route may be
obtained from
the mobile wireless telecommunication computing device or determined by the
data
processing system associated with the provider. The updated travel route will
typically be a
projected travel route based on the current location of the user, since the
actual travel route
cannot be known with certainty since it has not yet been taken.
[0040] The updated order completion estimate determined at step 210A may be
obtained in
the same way as the initial order completion estimate determined at step 206.
For example,
where the order completion estimate is obtained from a lookup table based on a
given start
time for the order, updating the order completion estimate may comprise
accessing the same
lookup table again using the then-current start time. Similarly, updating of
the order
completion estimate at step 210A may comprise dynamically recalculating the
order
completion estimate in embodiments where the order completion estimate is
generated
dynamically, such as where the order completion estimate may change due to the
volume of
business at a particular provider location, for example. Alternatively, the
updated order
completion estimate at step 210A may be determined in a different way than the
initial order
completion estimate obtained at step 206.
[0041] Similarly, the updated arrival estimate determined at step 210B may be
obtained in the
same way as the initial arrival estimate determined at step 204, such as by
obtaining a
dynamically recalculated arrival estimate. In one embodiment, a dynamically
updated
location for the user, such as from a GPS-equipped smartphone, may be used to
generate an
updated arrival estimate in the same way that the original arrival estimate
was generated. For
example, the user's updated location may indicate that the user has deviated
from the
anticipated route upon which the previous arrival estimate was based. In other
embodiments,
-18-
CA 02839208 2014-01-15
the updated arrival estimate determined at step 210B may be obtained in a
different way than
the initial arrival estimate obtained at step 204. For example, the initial
arrival estimate
obtained at step 204 may be an estimated travel time dynamically calculated,
such as from a
GPS or manually entered location, and may be updated simply by decrementing
according to
elapsed time. Such an approach may be used, for example, if the order is
transmitted from a
desktop computer and is not associated with a networked mobile wireless
telecommunication
computing device.
[0042] Alternatively, step 210B may be performed in more than one way, such as
by
generating a dynamically updated arrival estimate based on new GPS location
data on every
Xth update while decrementing the previous estimate for the other updates, or
decrementing
the arrival estimates between updates thereof.
[0043] Optionally, a delay may be interposed between steps 208 and 210 to
limit the use of
processing resources; that is, the order completion estimate and/or the
arrival estimate would
be updated periodically at intervals rather than constantly. Typically,
mapping applications on
networked mobile wireless telecommunication computing devices will check for
position
updates at set intervals; this consumes battery life and may also require data
usage and thereby
increase user costs. As such, in one preferred embodiment the frequency with
which the
arrival estimate is updated may be varied based on the arrival estimate
itself¨ the closer the
arrival estimate is to the order completion estimate, the more frequently the
arrival estimate
will be updated.
[0044] After updating either the order completion estimate or the arrival
estimate or both at
step 210, the method 200 returns to step 208 to again compare the order
completion estimate
and the arrival estimate to see if they substantially coincide. Thus, the
second and subsequent
iterations of step 208 compare the then-current arrival estimate to the then-
current order
completion estimate, with at least one, and possibly both, of the then-current
arrival estimate
and order completion estimate being an updated arrival estimate and order
completion
estimate, respectively. Alternatively, in the second and subsequent iterations
of step 208 the
then-current arrival estimate may be the initial arrival estimate with only
the order completion
-19-
CA 02839208 2014-01-15
estimate being updated, or the then-current order completion estimate may be
the initial order
completion estimate, with only the arrival estimate being updated.
[0045] Figure 2A shows another exemplary method 200A for scheduling processing
of an
order for goods at a provider location. The method 200A shown in Figure 2A is
similar to the
method 200 shown in Figure 2, with like reference numerals identifying
corresponding steps,
and includes additional optional steps 212 to 218 (shown with dashed lines)
for providing
notification to a user and allowing a user to delay the commencement of order
processing, for
example if the user is caught in traffic or decides to stop unexpectedly.
[0046] In the method 200A shown in Figure 2A, after a determination at step
208 that the
arrival estimate and the order completion estimate substantially coincide,
instead of
proceeding immediately to step 220 to provide the signal to commence order
processing, the
method 200A proceeds to step 212 and sends a notification to the user that
order processing is
about to begin, and then waits for a predetermined time to give the user an
opportunity to
provide a delay instruction, which may be a fixed or a variable, user-selected
delay. The
method 200A then proceeds to step 214 to check whether a delay instruction has
been
received from the user. Responsive to a determination at step 214 that no
delay instruction
has been received, the method 200A proceeds to step 220 and provides the
signal to
commence order processing.
[0047] If the method 200A determines at step 214 that a delay instruction has
been received,
the method then proceeds to step 216 to check whether the delay has elapsed.
If the method
200A determines at step 216 that the delay has elapsed, the method 200A
returns to step 212
to send a further notification to the user and give the user an opportunity to
provide a further
delay instruction. If the method 200A determines at step 216 that the delay
has not yet
elapsed, then the method 200A proceeds to step 218 to check whether a command
to cancel
the delay instruction has been received. Responsive to a determination at step
218 that no
delay cancel command has been received, the method 200 returns to step 216 to
again check
whether the delay has elapsed. If the method 200A determines at step 218 that
a delay cancel
-20-
CA 02839208 2014-01-15
command has been received, then the method 200A proceeds to step 220 and
provides the
signal to commence order processing.
[0048] In embodiments in which a delay instruction can be provided, the order
completion
estimate may include a buffer time to account for the time associated with
steps 212 to 218.
[0049] While Figure 2A shows step 218 occurring after step 216, these steps
may be
performed in the reverse order; i.e. the method 200A could check for a delay
cancel command
before checking if the delay has elapsed, or steps 216 and 218 may be
performed substantially
simultaneously. In some embodiments, the user may not be provided with an
opportunity to
cancel a delay instruction, in which case step 218 may be omitted. In some
embodiments, a
user may only be permitted to provide a single delay instruction, in which
case (if a delay
cancel option is provided) step 218 would precede step 216 and the method 200A
may
proceed directly from step 216 to step 220 when it is determined that the
delay has elapsed.
[0050] Figure 3A shows a schematic representation of a first exemplary
arrangement for
implementing a method for scheduling processing of an order by a provider. As
shown in
Figure 3A, a networked mobile wireless telecommunication computing device in
the form of a
smartphone 310 has a display 312 and user interface 314 in the form of a
keyboard. In the
illustrated embodiment, the display 312 and user interface 314 are separate;
in other
embodiments the display and user interface may be integrated into a single,
touch-sensitive
interactive screen, as is known in the art, and the keyboard may be omitted.
The smartphone
310 is in communication with a network 320, such as the Internet or a private
network, by way
of a wireless telecommunication system 324 represented schematically by a
wireless
transmission tower. The wireless telecommunication system 324 exchanges
wireless
communication signals 326 with the smartphone 310, and also exchanges
communication
signals 328 with the network 320, thereby enabling the smartphone 310 to
communicate with
the network 320. The communication signals 328 between the wireless
telecommunication
system 324 and the network 320 may be wired or wireless.
-21-
CA 02839208 2014-01-15
[0051] The smartphone 310 is equipped with a locating system, which in the
illustrated
embodiment is a global positioning system ("GPS") receiver 340 that receives
signals 344
from orbiting satellites 342 and, either directly or in cooperation with a
processor of the
smartphone 310, determines the position of the smartphone 10. For simplicity
of illustration
only a single satellite 342 is shown, in operation a plurality of satellites
342 are used in a
global positioning system, as is known in the art.
[0052] In the embodiment shown in Figure 3A, the method 200 from Figure 2 is
implemented
by the smartphone 310. The smartphone 310 includes a remote ordering
application 350 in
the form of computer-readable data and instructions stored in the memory (not
shown in
Figure 3A; see Figure 9) of the smartphone 310 for execution by the processing
unit (see
Figure 9) of the smartphone 310. The remote ordering application 350 enables a
user (not
shown in Figure 3A) of the smartphone 10 to generate an order for goods, and
includes an
item list 352 and optionally includes payment support 354. The remote ordering
application
350 may be, for example, a separate application program installed on the
smartphone 310 or
may be a page or pages within a web browser application on the smartphone 310,
including a
browser-executable software program. The item list 352 will generally comprise
a list of
items available from a provider 360 (discussed further below), prices
associated with each
item on the item list 352, and possibly additional information about the
items. For example,
where the provider 360 is a restaurant or a chain of restaurants, the item
list 352 would
typically comprise at least a list of menu items and the prices of those menu
items, and
possibly images and/or descriptions of the menu items. The item list 352 can
be maintained
remotely and transmitted to the smartphone 310 in response to a request, or
the item list 352
may be stored on the smartphone 10 and be periodically updated, for example
when updating
a remote ordering application.
[0053] Preferably, the remote ordering application 350 provides for voice
control so that it
can be used by a driver in a motor vehicle without the driver having to use
his or her hands to
control the remote ordering application 350, and uses text-to-voice or similar
functionality to
enable orders to be audibly read back to the user.
-22-
CA 02839208 2014-01-15
[0054] The optional payment support 354 is used by the remote ordering
application 350 to
facilitate payment for an order for goods generated by the remote ordering
application 350. In
one embodiment, the payment support 354 enables a user to enter payment
information, such
as a credit card number or a prepaid value card number, at the time an order
is generated; in
another embodiment the payment support 354 stores payment information for
reuse. In a
further embodiment, the payment support 354 links to an external payment
service 368, such
as a credit card processor or that provided by PayPal, having an address at
2211 North First
Street, San Jose, California 95131, to facilitate payment for an order. Such
linking may be
direct, or may be via a separate application program provided by the external
payment service
368 and stored on the smartphone 310. In another embodiment, a data processing
system
associated with the provider 360 may store payment information. For example, a
person may
establish a user account with a provider 360, which account may include
identifying
information for the person as well as enabling information for one or more
payment methods,
such as a credit card, bank account or prepaid value storage, that can be used
to pay for goods
either upon receipt of an order or upon collection of the goods by a user. In
such
embodiments, the payment support 354 may be used to select among multiple
payment
methods.
[0055] In one embodiment, payment processing is handled by first pre-
authorizing a credit
card transaction at the time the order 372 is confirmed, which pre-
authorization may be
initiated, for example, by the user selecting an "I'm on my way" button, and
completed once
the user has collected the goods and the provider has marked the order as
"complete" on their
side, in each case as described in greater detail below. This method of
payment processing is
advantageous because it avoids certain complications that would arise if the
payment
transaction were completed before the goods were collected, such as
chargebacks in the event
that the user is dissatisfied.
[0056] In other embodiments, the remote ordering application 350 may not
include any
payment support 354 and payment may be made in any conventional manner when
the user
collects the goods at the provider location 366. Because the payment support
354 and the use
of the external payment service 368 is optional, the payment support 354 as
well as the
-23 -
CA 02839208 2014-01-15
external payment service 368 and the communications 368P, 368C therewith are
shown in
dashed lines in Figure 3A.
[0057] In the embodiment illustrated in Figure 3A, the remote ordering
application 350 is
distributed by a provider 360 who makes goods available for sale, lease,
rental and the like.
For example, the provider 360 may be, without limitation, a restaurant, or a
retailer such as a
grocery store, general merchandise store, liquor or beer store or a video
rental store. The
provider 360 may have any number of individual locations at which goods may be
provided to
a user, ranging from a single location to thousands of locations. The
locations may be owned
by the provider, or may be franchises of the provider, or some combination
thereof The
provider 360 has an order processing system 362 for receiving and processing
orders for
goods generated by the remote ordering application 350 and received via the
network 320, and
then dispatching the orders for physical processing and fulfillment 364 at a
physical provider
location 366 (see Figure 4) operated by the provider 360. The order processing
system 362
will typically be a server-type data processing system, which may comprise one
or more
individual computer systems coupled to the network 320. The order processing
system 362
may be a central order processing system that communicates with the point-of-
sale order
processing systems at individual physical provider locations 366, or the
provider locations 366
may be provided with a computer system or terminal linked to the order
processing system
362 to display incoming orders. Typically, the physical provider location 366
is a retail outlet.
Where the provider 360 operates a plurality of such provider locations 366,
the order
processing system 362 will route the order to the appropriate provider
location 366. The
provider location 366 may be selected based on the current location of the
smartphone 310, a
destination location or a planned travel route, in each case with the user
being asked to
confirm the provider location 366. Alternatively, the user may manually enter
a desired
provider location 366. Certain provider locations 366 may also be stored as
"favorites" for
frequent use.
[0058] In operation, in the embodiment shown in Figure 3A a user will use the
remote
ordering application 350 to generate an order 372 for goods that are available
from the
provider 360; the order is received in the smartphone 310, thereby fulfilling
step 202 of the
-24 -
CA 02839208 2014-01-15
method 200 shown in Figure 2 and the method 200A shown in Figure 2A. In one
embodiment, the order 372 may be a previously created order, which may be
stored on the
smartphone 310 or retrieved by the smartphone 310 from a remote system. For
example, a
user could create "favorite" orders or reuse a previous order. In the
exemplary embodiment
shown in Figure 3A, the order 372 includes an identification 374 of the type
and quantity of
goods being ordered as well as payment information 376. The payment
information 376 may
be a credit card number and associated information, or may comprise an
indication that
payment instructions 368P were sent to an external payment service 368
associated with the
smartphone 310. In other embodiments, where permitted by the order processing
system 362,
an order for goods need not include payment information, and in such
circumstances may
include other information, such as a telephone number or other identifier for
the smartphone
310. In embodiments in which the order 372 does not include payment
information 376, the
user can pay for the goods at the time of collection at the provider location
366, or a user's
credit card, bank account or a prepaid value storage may be automatically
charged once the
user has collected the goods.
[0059] The smartphone 310 then obtains an order completion estimate for the
order 372 (step
206 of the method 200 shown in Figure 2 and the method 200A shown in Figure
2A). The
order completion estimate may be calculated by the smartphone 310 based on
information
stored in the remote ordering application 350, or alternatively (not shown in
Figure 3A) the
smartphone 310 may transmit information about the items to be ordered (but not
the order 372
itself) to the order processing system 362 and receive the order completion
estimate from the
order processing system 362.
[0060] After the order 372 has been generated, at the appropriate time, as
explained in greater
detail below, the order 372 is transmitted by the smartphone 310 through the
network 320 to
the order processing system 362 operated by the provider 360. Where the order
372 includes
payment information 376, the order processing system 362 processes the payment
information
376 and, responsive to successful processing of the payment information 376,
transmits an
order receipt 378 to the smartphone 310. Where the payment information 376 is
a credit card
number and associated information, the order processing system 362 can process
this
-25-
CA 02839208 2014-01-15
information in a known manner, and the order receipt 378 may be transmitted to
the
smartphone 310 using the remote ordering application 350, via e-mail to an e-
mail account
associated with the smartphone 310, by text message to a phone number
associated with the
smartphone, or by other suitable technique. Where the payment information 376
indicates
that payment instructions 368P were sent to an external payment service 368,
the order
processing system will receive and verify payment confirmation 368C from the
external
payment service 368 and, once payment is verified, transmit the order receipt
378 via the
network either directly to the smartphone 310 as shown in Figure 3A, or to the
external
payment service 368 for transmission by the external payment service 368 to
the smartphone
310. In embodiments where the order 372 does not include payment information
376, such as
where the goods are to be paid for upon collection at the provider location
366, the payment
processing steps may be omitted although an order receipt 378 will typically
still be
transmitted to confirm placement of the order even though it does not confirm
payment. The
order receipt 378 preferably includes an order identifier 3781 so that the
order receipt 378 can
be connected to the order 372. For example, the order identifier 3781 can be a
numeric,
alphabetic or alphanumeric code and/or can repeat the identification 374 of
the type and
quantity of goods from the order 372. Alternatively, the order identifier 3781
can be a bar
code or quick-response (QR) code. After receiving the order receipt 378, the
smartphone 310
can store, retrieve and reproduce the order receipt 378, for example by
presenting the order
receipt 378 on the display 312. In permitted cases where the order 372 does
not include
payment information 376, a separate payment confirmation can be transmitted
once payment
has been processed.
[0061] After successful processing of the payment information 376, or in a
permitted case
where no payment information is provided, the order processing system 362
processes the
order 372 and routes it for physical processing and fulfillment 364 at a
physical location 366
(see Figure 4). Typically, in the case where the provider 360 operates a
plurality of physical
locations 366, the order 372 will specify the physical location 366 where
physical processing
and fulfillment 364 should occur and hence from where the goods should be
collected.
-26-
CA 02839208 2014-01-15
[0062] In the exemplary arrangement shown in Figure 3A, the smartphone 310
will obtain an
initial arrival estimate (step 204 of the method 200/200A in Figure 2/Figure
2A) for when the
user is expected to arrive at the physical provider location 366 where the
order is to be
processed, using the GPS receiver 340 or other locating system. The smartphone
310 does not
transmit the order 372 immediately after the order is generated, but only when
the smartphone
310 determines that the arrival estimate for the user substantially coincides
with the order
completion estimate for the order 372 (i.e. step 208 of the method 200/200A in
Figure
2/Figure 2A). Thus, in the exemplary embodiment shown in Figure 3A,
transmission of the
order 372 is step 220 of the method 200 shown in Figure 2 and the method 200A
shown in
Figure 2A, and the smartphone 310 implements step 208 of the method 200/200A
in Figure
2/Figure 2A by using the GPS receiver 340 or other locating system to
determine when the
smartphone 310 is in an appropriate geographical location such that the
estimated remaining
travel time of the user 370 to the physical location 366 from which the goods
are to be
collected is approximately equal to the time required to complete the physical
processing and
fulfillment 364 of the goods. As such, the smartphone 310 will obtain periodic
updates of the
arrival estimate (step 210B of the method 200/200A in Figure 2/Figure 2A)
using the GPS
receiver 340 or other locating system, and may also obtain updates of the
order completion
estimate from the order processing system 362 (step 210A of the method
200/200A in Figure
2/Figure 2A; not shown in Figure 3A). Because transmission of the order 372 is
based on
the location of the user and his or her smartphone 310, the order 372 is part
of, and hence
associated with, a location-triggered communication from the smartphone 310,
and the
provider 360 processes the order 372 in response to that location-triggered
communication.
[0063] An alternate embodiment of the arrangement in Figure 3A is shown in
Figure 3B. In
this alternate embodiment, instead of waiting to transmit the order 372 until
the estimated
processing time for the order 372 is approximately equal to the estimated
remaining travel
time to the relevant provider location 366, the order 372 is transmitted by
the smartphone 310
in advance. In such an embodiment, while the payment information 376 may be
processed
and the order receipt 378 sent immediately, physical processing and
fulfillment 364 of the
order 372 will be held in abeyance until the smartphone 310 transmits a
separate
-27-
CA 02839208 2014-01-15
communication or signal 373 to the provider 360 signaling that processing
should begin (step
220 of the method 200 in Figure 2). Thus, the location-based communication may
be
associated with the order 372 by containing the order 372, as shown in Figure
3A, or may be a
separate communication 373 that is associated with the order 372, for example
by means of a
suitable order identifier, as shown in Figure 3B. The order completion
estimate may be
calculated by the smartphone 310, or may be sent to the smartphone 310 from
the order
processing system 362, which can use the order 372 to generate the order
completion estimate.
The arrangement shown in Figure 3B is otherwise similar to the arrangement
shown in Figure
3, and hence like reference numerals are used to refer to like features.
[0064] In embodiments such as the one shown in Figure 3B where the order 372
is
transmitted ahead of time, the provider 360 may carry out some initial
physical processing
steps upon receiving the order 372 while holding the final processing steps in
abeyance until
the order processing system 362 receives the signal 373. Typically, the
initial physical
processing steps would be those that are not critical to issues of freshness,
spoilage or
degradation and the final processing steps held in abeyance would be those
that will have an
effect on freshness, spoilage or degradation if not timed correctly. For
example, where the
order 373 is for a pizza, the provider 360 may prepare the pizza in response
to the order 372,
but not cause the pizza to be placed in the oven until the order processing
system 362 receives
the signal 373 indicating that the user's travel time is approximately equal
to the cook time for
the pizza. Thus, the signal 373 to commence processing the order 372 may be a
signal to
commence a final stage of processing.
[0065] Optionally, determination and monitoring of the arrival estimate may be
deferred for
some time after receiving the order 372 in the smartphone 310. In one
embodiment, the user
may enter the order 372 into the smartphone 310, but the smartphone 310 would
not transmit
the order 372 until the user selects an "I'm on my way" or similar button on
the smartphone
310. For example, the user may place a dinner order in the early afternoon
while still at work,
several hours before he or she plans to leave.
-28-
CA 02839208 2014-01-15
[0066] Optionally, the smartphone 310 provides a notification 371 (step 212 of
the method
200A in Figure 2A) before transmitting the order 372 (Figure 3A) or the signal
373 (Figure
3B) to the order processing system 362 signaling that processing should begin.
Also
optionally, the smartphone 310 allows the user to provide a delay instruction
375 to the
smartphone 310 to delay transmission of the order 372 (Figure 3) or the signal
373 (Figure
3B). This relates to steps 214, 216 and 218 of the method 200A in Figure 2A.
The delay
instruction 375 may be for a set period of time (e.g. 5 or 10 minutes), or the
user may specify
a time period 377 in the delay instruction 375. The sequence of notification
371 and delay
instruction 375 may operate recursively, i.e. following expiration of the time
period 377
specified by the previous delay instruction 375, the smartphone 310 may
provide a further
notification 371 providing the user with an opportunity to provide a further
delay instruction
375. The notification 371 may be an audible notification, a visual
notification or an audio-
visual notification, and the delay instruction 375 may be provided by voice
command or by
keyboard or touchscreen input. The delay instruction 375 may be provided in
response to the
notification 371, or independently, for example to cause the notification 371
or the signal 373
to be sent a set period of time after the time that the notification 371 or
the signal 373 would
ordinarily be sent based on the location of the smartphone 310. Also
optionally, the
smartphone 310 can receive a cancel delay command 379 to cancel a previously
received
delay instruction 375.
[0067] Reference is now made to Figure 3C, which shows another alternate
embodiment of a
method for processing an order. The embodiment shown in Figure 3C is similar
to the
embodiments shown in Figure 3A and 3B, with like reference numerals referring
to like
features, but in the embodiment shown in Figure 3C the method 200/200A from
Figure
2/Figure 2A is executed by the order processing system 362 rather than the
smartphone 310.
[0068] In the embodiment shown in Figure 3C, the smartphone 310 transmits the
order 372 to
the order processing system 362 (the identification 374 of the type and
quantity of goods
being ordered as well as payment information 376 are included in the order 372
and are
omitted from Figure 3C for simplicity of illustration only). In the embodiment
shown in
Figure 3C, receipt by the order processing system 362 of the order 372 is step
202 of the
-29-
CA 02839208 2014-01-15
method 200/200A in Figure 2/Figure 2A. The smartphone 310 also transmits
location
information 396, obtained from the GPS receiver 340 or other locating system,
to the order
processing system 362, either without prompting or in response to a query from
the order
processing system 362. In a preferred embodiment, the location information 396
comprises an
initial arrival estimate calculated by the GPS receiver 340 or other locating
system, in which
case receipt of the location information 396 at the order processing system is
step 204 of the
method 200/200A in Figure 2/Figure 2A. Alternatively, the location information
396 may
simply comprise a then-current location of the smartphone 310, in which case
step 204 of the
method 200 will comprise the order processing system 362 determining an
initial arrival
estimate based on the location information 396. The order processing system
362 will also
execute step 206 of the method 200/200A in Figure 2/Figure 2A, for example by
using a
predetermined order completion estimate or by calculating the order completion
estimate from
the order 372. In an alternate embodiment, the remote ordering application 350
on the
smartphone may embed an initial order completion estimate in the order 372 and
the order
processing system 362 may obtain the order completion estimate by extracting
it from the
order 372.
[0069] Similarly to the embodiment described in respect of Figure 3B,
determination and
monitoring of the arrival estimate may be deferred for some time after
receiving the order 372
in the smartphone 310, for example until the user selects an "I'm on my way"
or similar
button on the smartphone 310.
[0070] The order processing system 362 then executes step 208 of the method
200/200A in
Figure 2/Figure 2A. If the order processing system 362 determines that the
arrival estimate
and the order completion estimate substantially coincide, the order processing
system 362 will
execute step 220 of the method 200/200A in Figure 2/Figure 2A and send a
signal to
commence processing of the order, for example by sending instructions to a
particular
provider location. The signal sent at step 220 of the method 200/200A in
Figure 2/Figure 2A
may be internal to the order processing system 362.
-30-
CA 02839208 2014-01-15
[0071] If the order processing system 362 determines that the arrival estimate
and the order
completion estimate do not substantially coincide, then the order processing
system 362 will
update one or both of the order completion estimate (step 210 of the method
200/200A in
Figure 2/Figure 2A) and the arrival estimate and then again compare the
arrival estimate and
the order completion estimate (step 208 of the method 200/200A in Figure
2/Figure 2A),
continuing this cycle until the order processing system 362 determines that
the order
completion estimate and the arrival estimate do substantially coincide.
[0072] Updating the arrival estimate by the order processing system 362 may
comprise
receiving updated location information 396 from the smartphone 310, either in
response to a
query from the order processing system 362 or with the location information
396 being sent
automatically, such as periodically, from the smartphone 310. In such
embodiments, the
updated location information 396 may comprise an updated arrival estimate
calculated by the
GPS receiver 340 or other locating system, in which case step 210B of the
method 200/200A
in Figure 2/Figure 2A is fulfilled by receipt of the location information 396
at the order
processing system 362. If the location information 396 is an updated location
of the
smartphone 310, step 210B of the method 200/200A in Figure 2/Figure 2A will
comprise the
order processing system 362 determining an updated arrival estimate based on
the updated
location information 396. The order processing system 362 may also update the
order
completion estimate (step 210A of the method 200/200A in Figure 2/Figure 2A),
for example
based on updated information about queues and latency at the particular
provider location that
will process the order 372.
[0073] In one embodiment of the arrangement shown in Figure 3C, the arrival
estimate will
only be updated if the user deviates from an expected route or if the
smartphone 310 detects a
significant variance in the arrival estimate. A map (not shown) covering the
expected route
from the current location of the smartphone 310 to the provider location may
be sent to the
smartphone 310, for example in response to receipt of the order 372 or in
response to the user
selecting the "I'm on my way" button. The remote ordering application 350 can,
directly or in
cooperation with a navigation application (not shown) on the smartphone 310,
use the map to
monitor the user's location via GPS, without the use of data services and
calculate a dynamic
- 3 1 -
CA 02839208 2014-01-15
estimated time of arrival at the provider location. If the remote ordering
application 350
detects that the user has deviated from the planned route along the map, or
that the estimated
time of arrival at the provider location varies from the initial arrival
estimate by more than a
threshold amount, then an updated arrival estimate can be provided to the
order processing
system 362.
[0074] Optionally, in a manner similar to the embodiments shown in Figures 3A
and 3B, the
embodiment shown in Figure 3C may provide for the user to receive a
notification before
physical processing and fulfillment 364 of the order 372 begins and be given
an opportunity to
delay physical processing of the order 372. In the embodiment shown in Figure
3C, before
beginning physical processing and fulfillment 364 of the order 372, the order
processing
system 362 would send a notification signal 371A to the smartphone 310 (step
212 of the
method 200A of Figure 2A), and the smartphone 310 would, in response to the
notification
signal 371A, provide a notification 371B to the user and allow the user to
enter into the
smartphone 310 a delay instruction 375, which may be for a set period of time
(e.g. 5 or 10
minutes), or may specify a time period 377. The smartphone 310 would then send
a delay
signal 398 to the order processing system 362, in response to which the order
processing
system 362 would delay transmitting the signal to commence processing of the
order 372.
This relates to steps 214, 216, and 218 of the method 200A in Figure 2A.
Similarly to the
embodiments shown in Figures 3A and 3B, in the embodiment shown in Figure 3C
the
sequence of notification signal 371A, notification 371B, delay instruction 375
and delay
signal 398 may operate recursively, i.e. following expiration of the time
period 377 specified
by the previous delay instruction 375, the order processing system 362 may
provide a further
notification signal 371A and the smartphone 310 may then provide a further
notification
371B, thereby enabling the user to provide a further delay instruction 375. As
in the
embodiments shown in Figures 3A and 3B, in the embodiment shown in Figure 3C,
the
smartphone 310 can receive a cancel delay command 379 (step 218 of the method
200A
shown in Figure 2) to cancel a previously received delay instruction 375, in
which case the
smartphone 310 would send a delay cancellation signal (not shown) to the order
processing
system 362.
-32-
CA 02839208 2014-01-15
[0075] In certain other embodiments, the order 372 may be sent from a
different networked
computing device than the user's networked mobile wireless telecommunication
computing
device, such as a computer's home computer or office computer. In such
embodiments, the
user's networked mobile wireless telecommunication computing device would
still provide
either a signal 373 to commence processing, or location information 396 to
enable the order
processing system 362 to determine when to commence processing. For example, a
user
could use his or her office computer to submit the order 372 that he or she
intends to pick up
on the way home from work. In such embodiments, the order may be prepared and
sent using
a web page operated by the provider 360.
[0076] Figures 3D and 3E show arrangements similar to those in Figures 3B and
3C,
respectively, except that the order 372 is sent from another computing device,
in this case a
user's desktop computer 316, to the provider 360. The payment instructions can
be sent from
the desktop computer 316 with the order 372, or may be sent separately from
the smartphone
310, for example with the signal 373. Simply for ease of illustration, the
payment service 368,
payment instructions 368P and payment confirmation 368C are not shown in
Figures 3D and
3E although they may be present in practice. The order receipt 378 is sent to
the remote
ordering application 350 on the smartphone 310 to facilitate transmission of
the signal 373
(Figure 3D) or the location information 396 (Figure 3E) by the smartphone 310.
[0077] The arrangements shown in Figures 3D and 3E allow one individual to
enter an order
372 to be picked up by another individual through the use of a linking
feature. For example,
suppose Penny is in the office and her boss asks her to work late, disrupting
her plan to cook
dinner when she gets home. She telephones her husband and tells him to order
some food,
since she does not even have time to place an order. Her husband then places
an order, using
his computer or smartphone, and links the order to Penny's smartphone, which
may provide a
notification of the linked order and the pickup location. When she is ready to
leave work,
Penny could then open the remote ordering application, open the relevant
order, select the
"I'm on my way" button, and operation of the system will proceed as described
above.
Optionally, the remote ordering application could also provide navigation
support to guide
Penny to the pickup location. Also optionally, in some embodiments the system
could enable
-33-
CA 02839208 2014-01-15
the individual who placed the order to monitor both the estimated arrival time
of the second
individual at the pickup location as well as the estimated arrival time of the
second individual
at the ultimate destination (e.g. home).
[0078] Linking can also be used to provide for an approvals process, for
example by
providing a master account with one or more sub-accounts linked to the master
account.
Generally, the master account is associated with an individual who is paying
for the goods.
For example, a minor child who has a smartphone or other suitable device could
be given a
sub-account under his or her parents' master account. On her lunch break at
school, the minor
child may use the remote ordering application 350 to place an order at a quick
service
restaurant near her school. This would trigger an alert on one or both of her
parents'
smartphones, allowing them to see what she has ordered and approve or reject
it. The remote
ordering application 350 would not allow the order 372 or the signal 373 to be
sent so as to
initiate order processing unless the order was approved by a master account
holder. The
master account could include other features such as spend tracking and/or
tracking the
location of the minor child.
[0079] Reference is now made to Figure 4A, which shows schematically the
operation of a
communication process for the arrangement shown in Figure 3A. A user 370 has
generated an
order 372 using the remote ordering application 350 on his or her smartphone
310, and then
entered his or her vehicle 380 and started driving to the provider location
366 from which the
goods are to be collected. As the user 370 begins driving, the user 370, and
hence the
smartphone 310, are a first distance Di from the provider location 366, as
determined by the
GPS receiver 340 (Figure 3A) using the signals 344 from the satellites 342.
The distance D1
is such that the estimated remaining travel time for the user 370 and vehicle
380 to arrive at
the provider location 366 is greater than the estimated processing time for
the order 372. As
such, in the embodiment shown in Figures 3A and 4A, the order 372 is stored in
memory of
the smartphone 310 but has not yet been transmitted to the order processing
system 362
through the network 320.
-34-
CA 02839208 2014-01-15
[0080] As the user 370, vehicle 380 and smartphone 310 travel toward the
provider location
366, the estimated travel time is updated, continuously or periodically, and
compared to the
estimated processing time for the order 372 by the smartphone 310. When the
user 370,
vehicle 380 and smartphone 310 are a second distance D2 from the provider
location 366,
which is less than the distance DI, the estimated travel time remaining to
arrive at the provider
location 366 is approximately equal to the estimated processing time for the
order 372; that is,
the arrival estimate and the order completion estimate substantially coincide.
The remote
ordering application 350 then transmits the order 372 to the order processing
system 362, via
the network 320. The order processing system 362 then processes the payment
information
376 and sends the order receipt 378 and also causes physical processing and
fulfillment 364 of
the order 372 at the appropriate provider location 366 to commence.
[0081] Figure 4B shows schematically the operation of the location-triggered
communication
process for the arrangement shown in Figure 3B, and is identical to Figure 4A,
with like
reference numerals used to refer to like features, except that in Figure 4B
the order 372 is
transmitted, payment processed and the order receipt 378 returned shortly
after being entered
into the smartphone 310, with a separate signal 373 to commence processing to
be transmitted
later. In the embodiment shown in Figures 3B and 4C, the order 372 is
transmitted while the
user 370, and hence the smartphone 310, are a first distance DI from the
provider location
366, where the distance Di is such that the estimated remaining travel time
for the user 370
and vehicle 380 to arrive at the provider location 366 is greater than the
estimated processing
time for the order 372; that is, the arrival estimate and the order completion
estimate do not
substantially coincide. As such, the signal 373 to commence processing has not
yet been
transmitted to the order processing system 362. When the user 370, vehicle 380
and
smartphone 310 are at the second distance D2 from the provider location 366
where the arrival
estimate and the order completion estimate substantially coincide, the remote
ordering
application 350 then transmits the signal 373 to commence processing to the
order processing
system 362. For the arrangement shown in Figure 3D, the operation of the
location-triggered
communication process is the same as that shown in Figure 4B, except that the
order 372 is
-35-
CA 02839208 2014-01-15
transmitted by the user's desktop computer 316 instead of the user's
smartphone 310, as
shown in Figure 4D.
[0082] Figure 4C shows schematically the operation of the location-triggered
communication
process for the arrangement shown in Figure 3C, in which the method 200/200A
from Figure
2/Figure 2A is executed by the order processing system 362 rather than the
smartphone 310.
Figure 4C is similar to Figure 4B, with like reference numerals used to denote
like features,
except that instead of transmitting a signal 373 to commence processing to the
order
processing system 362, the smartphone 310 sends location information 396 to
the order
processing system 362. Initial location information 396 is transmitted with
the order 372,
which is sent when the user 370, and hence the smartphone 310, are a first
distance DI for
which the arrival estimate and the order completion estimate do not
substantially coincide,
and the smartphone 310 continues to send location information 396 as the user
370 and
smartphone 310 approach the provider location 366. When the location
information 396
enables the order processing system 362 to determine that the arrival estimate
and the order
completion estimate substantially coincide, i.e. at distance D2, the order
processing system
362 sends the signal for the provider location 366 to commence processing of
the order. For
the arrangement shown in Figure 4E, the operation of the location-triggered
communication
process is the same as that shown in Figure 4B, except that the order 372 is
transmitted by a
user's desktop computer 316 instead of the user's smartphone 310 and the
smartphone 310
only transmits location information 396, as shown in Figure 4E.
[0083] In one embodiment, handling of a situation where the smartphone 310
becomes unable
to determine its location, for example because of a failure of the GPS
receiver 340, may
depend on whether the order processing has commenced. If order processing has
not started
(or the signal to commence processing has not been transmitted), then an error
message is
generated, which may suspend or cancel the order, or give the user the option
to continue with
the order despite the fact that order completion may not coincide with his or
her arrival. If the
user chooses to proceed, then the smartphone 310 or order processing system
362 may use the
most recent arrival estimate and decrement from it as time elapses (e.g. if
the last arrival
estimate was seven minutes, the system will count down from seven minutes). On
the other
-36-
CA 02839208 2014-01-15
hand, if order processing has already commenced (or the signal to commence
processing has
been transmitted), then the smartphone 310 or order processing system 362 will
simply use
the most recent arrival estimate. Thus, decrementing may also be used as a
"fallback"
procedure for updating the arrival estimate in the case where dynamic
recalculation is the
primary procedure but such dynamic recalculation fails.
[0084] Because processing of the order 372 is delayed until receipt of a
location-triggered
communication sent when the estimated processing time for the order 372 is
approximately
equal to the estimated travel time to the provider location 366, the user 370
will generally
arrive at the provider location at about the same time as physical processing
and fulfillment
364 of the order 372 is completed. As a result, in most circumstances, when
the user 370
arrives at the provider location 366, physical processing and fulfillment 364
of the order 372
will either be about to be completed, or have just been completed, so that
there is very little
waiting by the user 370 for the goods or by the goods for the user 370. This
is particularly
important where the quality of the goods deteriorates quickly over time, such
as with
restaurant meals, and can also reduce the amount of time that a user waits in
line, as compared
to the case where the user places the order upon arrival at the provider
location. As such,
although these methods are not limited to these establishments, certain
systems, methods and
computer program products described herein have particular application in
respect of quick
service or "fast food" type restaurants and coffee and donut shops. For
example, a remote
order can be placed in advance as described above, specifying a drive through
pick-up, and the
user could simply drive up to the window, present the order receipt 378 and
pick up the order,
rather than having to drive up, stop to order, stop to pay and then stop and
wait for the order to
be assembled. Where the order identifier 3781 for the order receipt 378
comprises a bar code
or a QR code, the user could present the order receipt 378 by presenting the
bar code or QR
code on the display 312 of the smartphone 310, to be scanned by a suitable
scanning device at
the provider location 366. This enables the provider location 366 to ensure
that the right
orders go to the right users.
[0085] The provision of a notification 371 and the ability of a user to
provide a delay
instruction 375 allows for flexibility to adapt to unexpected events. For
example, a user may
-37-
CA 02839208 2014-01-15
find that he or she is in heavier than expected traffic such that the
estimated travel time to the
provider location 366 will be inaccurate, or may decide to do an errand on the
way to the
provider location, and can use the delay instruction 375.
[0086] In one exemplary embodiment, a user who regularly visits a coffee shop
for morning
coffee on the way to work would use the remote ordering application 350 to
generate their
order 372 before leaving home, and as the user gets close enough to the coffee
shop, the order
(or signal) would be sent and payment executed (or pre-approved) so that all
the user would
have to do is pick up the order, thereby circumventing the line. The remote
ordering
application 350, or a web site of the provider 360 accessed from a desktop
computer 316, can
enable creation of a "regular" order, such as the daily coffee order described
above, which
would be automatically initiated when the user gets close enough to the
relevant provider
unless cancelled by the user. For example, when the user first activates the
smartphone 310
on a given day, the remote ordering application 350 can remind the user of the
"regular" order
and present the user with the option to cancel it for that day. Such a
"regular" order can be set
to operate only on certain days, such as weekdays for the coffee shop example
described
above.
[0087] A "regular" order as described above can be created manually by a user,
or
automatically by a remote ordering application 350 based on tracking or
previous orders. For
example, where a user demonstrates a consistent pattern of ordering coffee
from a particular
location on weekday mornings for pickup around 8:00, for example over a period
of one or
two weeks, the remote ordering application 350 may automatically generate a
"regular" order
and provide a prompt at 6:30 such as "I have noticed you order coffee about
this time ¨ shall I
order it for you?"
[0088] In the restaurant context, the methods, systems and computer program
products
described herein are not limited to take-out orders, and in some embodiments a
"dine in"
feature may be provided. For example, where a group of friends are going to a
restaurant after
work, one of them can order drinks and/or appetizers, the preparation of which
could then be
scheduled so that they are ready when the group arrives. In addition, where
two or more
-38-
CA 02839208 2014-01-15
people who are going to a restaurant from different locations one of them
could place an order
using his or her smartphone and link it to the other smartphone(s), or each
could place his or
her own orders and the orders could then be linked. Arrival estimates would be
obtained and
updated for each person, and order processing would be scheduled to
substantially coincide
with arrival of the last of them to arrive. Another application of a "dine in"
feature is for
meals after organized children's sporting events. It is not uncommon for a
coach to take a
children's sports team to a quick service restaurant after a game, often
overwhelming the
establishment. As a result, the turnaround time can be quite long, whereas
with the methods,
systems and computer program products described herein, the order can be ready
when the
team arrives.
[0089] It is also contemplated that in certain embodiments, one "master"
networked mobile
wireless telecommunication computing device could aggregate orders entered
onto a plurality
of other networked devices into a "master" order. Such embodiments could be
used, for
example, to enable a single order to be placed in advance for the passengers
of a long-distance
coach bus.
[0090] The methods, systems and computer program products described herein are
not limited
to restaurant applications, and may also be used for other retailers, such as
a beer or liquor
retailer. Certain of the methods, systems and computer program products
described herein,
although not limited thereto, may have particular application in respect of a
grocery store,
where an order may contain certain items that require refrigeration and may
degrade or perish
if the order is left out for too long after being assembled, while also
containing other items
that could be degraded if placed in refrigeration. To facilitate such
applications, a dedicated
grocery pick up facility may be provided. By removing many of the aspects
associated with
conventional grocery shopping, such as wide aisles, large footprint product
placement, large
open produce sections, cash registers and the like, a condensed facility
dedicated to picking
and order pickup can be provided that is substantially smaller than a
conventional grocery
store carrying the same product range. Such dedicated facilities may be
provided as stand-
alone locations, or as adjuncts to existing grocery stores.
-39-
CA 02839208 2014-01-15
[0091] Figure 5A shows a schematic representation of another exemplary
arrangement for
implementing a method for processing an order. The arrangement shown in Figure
5A is
similar in many respects to the exemplary arrangement shown in Figure 3A, and
like reference
numerals are used to refer to corresponding features.
[0092] In the exemplary arrangement shown in Figure 5A, the remote ordering
application
350 is distributed by a provider aggregator 390 instead of by an individual
provider 360. The
provider aggregator 390 maintains relationships with a plurality of providers
360A,
360B...360n and aggregates the offerings of goods by those providers 360A,
360B...360n
through its own order processing system 392. Like the order processing system
362 of the
provider 360, the order processing system 392 of the provider aggregator 390
will typically be
a server-type data processing system, which may comprise one or more
individual computer
systems coupled to the network 320. Details of the providers 360A, 360B...360n
are omitted
from Figure 5A for clarity of illustration, but will generally comprise a
provider order
processing system, one or more provider locations, and facilities for physical
processing and
fulfillment of orders. The order processing system 392 of the provider
aggregator 390 will be
coupled, for example via the network 320, to the order processing systems of
the providers
360A, 360B...360n.
[0093] By aggregating a plurality of providers 360A, 360B...360n the provider
aggregator
390 can enable a user to place orders with one or more of a plurality of
providers 360A,
360B.. .360n using a single interface, such as a single web site accessed from
a desktop
computer 316 or a single remote ordering application 350, which will typically
include a
plurality of item lists 352A...352n, one for each provider 360A, 360B...360n.
For example,
where the providers 360A, 360B...360n are restaurants or restaurant chains,
the remote
ordering application 350 could present a list of restaurants or restaurant
locations within a
chain and, responsive to one of the restaurants being selected, then present
the item list
352A...352n, typically a form of menu, for that restaurant or location,
enabling a user to
generate the order 372. At the appropriate time, the order 372 is transmitted
through the
network 320 to the order processing system 392 of the provider aggregator 390
and the
payment information 376 processed, and the order 372, or at least the
identification 374 of the
-40 -
CA 02839208 2014-01-15
goods ordered, is routed to the appropriate provider 360A, 360B...360n for
physical
processing and fulfillment, typically via the order processing system of the
respective
provider.
[0094] Payment arrangements for the provider aggregator 390 are similar to
those for the case
of an individual provider 360, and may provide for processing of payments by
the provider
aggregator 390, either on an order-by-order basis or via a pre-established
user account, or via
an external payment service 368. In such embodiments, the provider aggregator
390 will
typically have an arrangement by which the providers 360A, 360B...360n receive
the
payments processed by the provider aggregator, possibly with a deduction of a
service charge
by the provider aggregator 390. Alternatively, a user may make payment
directly to the
provider 360, for example on an order-by-order basis, through a user account
established with
that provider, or when picking up the goods.
[0095] As with the embodiment illustrated in Figure 3A, in the embodiment
shown in Figure
5A the order 372 is not transmitted from the smartphone 310 until the order
completion
estimate for the order 372 and the arrival estimate for the user at the
relevant provider location
substantially coincide.
[0096] Figure 5B shows an alternate embodiment of the arrangement shown in
Figure 5A,
which is similar to the arrangement shown in Figure 3B except that a provider
aggregator 390
is interposed between the remote ordering application 350 and a plurality of
providers 360A,
360B...360n as shown in Figure 5A. Thus, in Figure 5B, the order 372 is
transmitted in
advance and physical processing and fulfillment of the order 372 is held in
abeyance until the
smartphone 310 transmits a separate signal 373 to the order processing system
392 of the
provider aggregator 390. In Figure 5B, like reference numerals are used to
refer to features
corresponding to those in Figures 2B and 5A.
[0097] Figure 5C shows another alternate embodiment of the arrangement shown
in Figure
5A. Figure 5C is similar to the arrangement shown in Figure 3C except that a
provider
aggregator 390 is interposed between the remote ordering application 350 and a
plurality of
-41-
CA 02839208 2014-01-15
providers 360A, 360B...360n as shown in Figure 5A. Thus, in Figure 5C, the
order 372 is
transmitted in advance and the smartphone 310 periodically transmits location
information
396 to the order processing system 392 of the provider aggregator 390, with
physical
processing and fulfillment of the order 372 being delayed until the order
processing system
392 of the provider aggregator 390 determines that the arrival estimate and
the order
completion estimate substantially coincide and (if applicable) there is no
outstanding delay
signal 398. In Figure 5C, like reference numerals are used to refer to
features corresponding
to those in Figures 3C and 5A.
[0098] Figures 5D and 5E show arrangements similar to those in Figures 5B and
5E,
respectively, except that the order 372 is sent from a user's desktop computer
316 to the
provider 360, in a manner similar to that shown in Figures 3D and 3E.
[0099] The arrangements shown in Figures 5A, 5B and 5C are substantially
identical to those
shown and described in respect of Figures 3A, 3B and 3C, respectively, except
that the order
372, the signal 373, if any (Figure 5B) and the location information 396, if
any (Figures 5C
and 5E) are sent to the order processing system 392 of the provider aggregator
390, which
then passes on the order 372 and/or sends an order commencement signal to the
relevant
provider 360. The order processing system 392 of the provider aggregator 390
may be
integrated with a central order processing system of a provider 360, or
directly with the point-
of-sale order processing systems of the relevant provider locations 366, or
the provider
locations 366 may be provided with a computer system or terminal linked to the
order
processing system 392 of the provider aggregator 390 to display incoming
orders.
[00100] Optionally, where the order 372 was sent ahead of time, instead of
automatically transmitting the signal 373 to commence processing based on a
detected
location, a user may manually trigger the signal 373. For example, a user who
has previously
submitted an order 372 could manually use his or her smartphone 310 or desktop
computer
316 to send the signal 373 just before he or she leaves to pick up the ordered
goods. This
arrangement would have particular application to situations where rapid
spoilage or
degradation of the goods being prepared is unlikely to be an issue, such as
general
-42 -
CA 02839208 2014-01-15
merchandise stores, video rental stores, jewelry stores, liquor and beer
stores, and grocery
stores (depending on the items ordered). Also optionally, a remote ordering
application may
permit a user to send an indication (not shown) that they are ready to pick up
a previously
submitted order. In response to such an indication, the order processing
system 362, 392 of
the provider 360 or provider aggregator 390 could determine and transmit an
order completion
estimate to the remote ordering application indicating when processing of the
order will be
complete. The order completion estimate may be based on current demand,
staffing and the
like at the provider location. The user could then use the remote ordering
application to either
confirm that he or she will attend at the provider location, or request that
the order processing
system 362, 392 send a notification either when the order processing is
complete or when the
location information from the user's networked mobile wireless
telecommunication
computing device indicates that the user's travel time is approximately equal
to the order
processing time.
[00101] Referring now to Figure 6, a flow chart illustrating a first
exemplary
implementation of the method 200 of Figure 2 is indicated generally at 600.
The method 600
may be executed by a networked mobile wireless telecommunication computing
device, such
as the smartphone 310. The method 600 may also be executed by the order
processing system
of either a provider or a provider aggregator, with the mobile wireless
telecommunication
computing device simply transmitting the order and then transmitting location
information.
[00102] At step 602, the method 600 receives a user selection comprising
at least one
item selected from a list of items; this is a particular embodiment of step
202 of the method
200 shown in Figure 2. Where the method 600 is executed by the mobile wireless
telecommunication computing device, step 602 will comprise receiving the
user's selection.
Where the method 600 is executed by the order processing system of either a
provider or a
provider aggregator, step 602 will typically comprise receiving an order from
a mobile
wireless telecommunication computing device.
[00103] At step 604, the method 600 determines an estimated processing
time for the
user selection; this is a particular embodiment of step 206 of the method 200
shown in Figure
-43 -
CA 02839208 2014-01-15
2. Where the method 600 is executed by a mobile wireless telecommunication
computing
device, the mobile wireless telecommunication computing device can calculate
the estimated
processing time itself (for example using the remote ordering application
350), or can send a
preliminary indication of the user selection to the order processing system,
which can return
the estimated processing time to the mobile wireless telecommunication
computing device.
Where the method 600 is executed by the order processing system of either a
provider or a
provider aggregator, step 604 may comprise estimating the processing time for
the order or
using a pre-determined fixed estimate. Physical processing and fulfillment
would not yet
commence.
[00104] At step 606, the method 600 obtains location information from a
locating
system for the mobile wireless telecommunication computing device. Where the
method 600
is executed by a mobile wireless telecommunication computing device, step 606
involves
communication between the remote ordering application 350 and the locating
system for the
mobile wireless telecommunication computing device, such as the GPS receiver
340 in the
case of the smartphone 310, possibly with the cooperation of a navigation
application. Where
the method 600 is executed by the order processing system of either a provider
or a provider
aggregator, the location information will typically be sent by the mobile
wireless
telecommunication computing device to the order processing system. The
location
information may comprise an identification of the user's location, which is
associated with the
order for goods, and may be obtained by the order processing system querying
the mobile
wireless telecommunication computing and receiving the identification of the
initial location
from the mobile wireless telecommunication computing device in response to the
query.
[00105] At step 608, the method 600 uses the location information to
determine the
estimated travel time for further travel to the selected provider location of
the provider
associated with the list of items from which the selection was received. The
algorithm may
incorporate information about a planned travel route to enhance the accuracy
of the estimated
travel time. Various algorithms for determining estimated travel time are
known in the field
of GPS navigation and hence are within the capability of one skilled in the
art, now informed
by the herein disclosure.
-44-
CA 02839208 2014-01-15
[00106] Steps 606 and 608 together comprise a particular embodiment of
step 204 of
the method 200 shown in Figure 2. Where the method 600 is executed by an order
processing
system of a provider or provider aggregator, the order processing system can
execute steps
606 and 608 either by querying the mobile wireless telecommunication device,
receiving an
identification of the user's location from the mobile wireless
telecommunication device (step
606) and using that location information to execute its own calculation of the
estimated travel
time (step 608) or by causing the mobile wireless telecommunication device to
obtain an
identification of the user's location (step 606) and then using that location
information to
determine an estimated travel time and send it to the order processing system
(step 608).
Thus, an order processing system of a provider or provider aggregator may
execute steps 606
and 608 by querying the user's mobile wireless telecommunicatioh computing
device and
receiving the estimated travel time from the mobile wireless telecommunication
computing
device in response to the query, both for the initial estimated travel time
and for updated
estimated travel times.
[00107] At step 610, the method 600 compares the estimated processing time
to the
estimated travel time, and determines whether the difference between the
estimated processing
time and the estimated travel time satisfies a threshold, generally indicating
that the estimated
processing time and the estimated travel time are at least approximately
equal. Step 610 is a
particular implementation of step 208 of the method 200 shown in Figure 2. The
threshold
used at step 610 is selected based on the exigencies of the particular
circumstances, and may
be set so that the threshold is satisfied when the estimated processing time
is slightly greater
than the estimated travel time, slightly less than the estimated travel time,
or equal to the
estimated travel time. Preferably, the threshold is deemed to be satisfied in
any case in which
the estimated processing time is greater than the estimated travel time, since
this would
indicate that the user is likely to arrive at the provider location before
processing of the order
is complete, so processing of the order should begin immediately to minimize
waiting by the
user.
[00108] If the method 600 determines that the difference between the
estimated
processing time and the estimated travel time does not satisfy the threshold
(a "no" at step
-45-
CA 02839208 2014-01-15
610), the method 600 returns to step 606 to obtain updated location
information. The return
from step 610 to step 606 to obtain new location information, and then using
the new location
information to determine a new estimated travel time at step 608, is a
particular embodiment
of step 210B of the method 200 shown in Figure 2. It will be noted that the
exemplary
method 600 does not implement step 210A of the method 200 shown in Figure 2;
i.e. the
method 600 does not update the estimated processing time for the user
selection. In an
alternate embodiment of the method 600 in which the estimated processing time
were also to
be updated, following a "no" determination at step 610 the method 600 would
return to step
604 to update the estimated processing time, and then proceed to step 606,
instead of returning
directly from step 610 to step 606.
[00109] If the method 600 determines that the difference between the
estimated
processing time and the estimated travel time satisfies the threshold (a "yes"
at step 610), the
method 600 proceeds to step 620. At step 620, in response to the determination
at step 610
that the difference between the estimated processing time and the estimated
travel time
satisfies the threshold, the method 600 transmits a communication to commence
processing of
an order comprising the user selection. Where the method 600 is executed by a
mobile
wireless telecommunication computing device such as the smartphone 310, step
620 may
comprise transmitting the order 372, including the payment information 354, to
the order
processing system 362, 392 of the provider 360 or provider aggregator 390, in
which case the
signal to commence processing is embodied in the order 372. Alternatively,
where order 372
was sent in advance, the signal to commence processing would be a signal 373
separate from
but associated with the order 372. Where the method 600 is executed by the
order processing
system of a provider aggregator, the signal to commence processing of the
order would be sent
to the order processing system of the relevant provider, or possibly directly
to the relevant
provider location, and where the method 600 is executed by the provider, the
signal would be
sent to the relevant provider location, or where the provider comprises a
single location, may
be a signal to alert the staff to begin processing the order. The signal may
comprise the order
372 itself or, if the order 372 was sent by the relevant processing system in
advance, a signal
-46 -
CA 02839208 2014-01-15
separate from but associated with the order 372 may be sent. Step 620
corresponds to step
220 of the method 200 shown in Figure 2.
[00110] Figure 6A is a flow chart illustrating a first exemplary
implementation 600A of
the method 200A shown in Figure 2A. The method 600A shown in Figure 6A is
similar to
the method 600 shown in Figure 6, with like reference numerals used to refer
to corresponding
steps, except that the method 600A shown in Figure 6A provides a notification
that the
communication to commence processing (step 620) is about to be sent, and
accommodates a
delay instruction.
[00111] Continuing to refer to Figure 6A, in response to the determination
at step 610
that the difference between the estimated processing time and the estimated
travel time
satisfies the threshold, at step 612 the method 600A sends a notification to
the user that the
communication to commence processing (step 620) is about to be sent. Step 612
of the
method 600A corresponds to step 212 of the method 200A shown in Figure 2A. At
step 614,
which corresponds to step 214 of the method 200A shown in Figure 2A, the
method 600A
checks whether a delay instruction has been received. Typically, step 614 will
occur after a
suitable pause following step 612, to provide the user with time to input a
delay instruction. If
the method 600A determines at step 614 that no delay instruction has been
received, the
method 600A proceeds to step 620 to send the communication to begin
processing. Step 620
of the method 600A corresponds to step 220 of the method 200A shown in Figure
2A. If the
method 600A determines at step 614 that a delay instruction has been received,
then at step
616, which corresponds to step 216 of the method 200A shown in Figure 2A, the
method
600A checks whether the delay period has elapsed, and if it has not elapsed,
continues to
monitor for whether the delay has elapsed. Once the method 600A determines at
step 616 that
the delay period has elapsed, the method 600A returns to step 612 to provide a
further
notification to the user and an opportunity to the user to enter a new delay
instruction. The
method 600A shown in Figure 6A is an implementation of the method 200A shown
in Figure
2A that does not permit a user to cancel a previously input delay instruction;
hence the method
600A does not include a step corresponding to step 218 of the method 200A
shown in Figure
2A.
-47-
CA 02839208 2014-01-15
[00112] Figure 6B is a flow chart illustrating a second exemplary
implementation 600B
of the method 200A shown in Figure 2A. The method 600B shown in Figure 6B is
identical
to the method 600A shown in Figure 6A, except that it allows a user to provide
a delay cancel
command to cancel a previous delay instruction. Again, like reference numerals
are used to
refer to corresponding steps. In the method 600B, after a determination (step
616) that the
delay period has not elapsed, the method 600B checks at step 618 whether a
delay cancel
command has been received and then returns to step 616 if no delay cancel
command was
received. Step 618 of the method 600B corresponds to step 218 of the method
200A shown in
Figure 2A.
[00113] Reference is now made to Figure 7, which shows a flow chart
illustrating a
second exemplary implementation 700 of the method 200 of Figure 2. While the
methods
600, 600A and 600B shown in Figures 6, 6A and 6B, respectively, determine
whether the
arrival estimate and the order completion estimate substantially coincide by
comparing an
estimated processing time for the order to the user's estimated travel time to
the relevant
provider location, the method 700 shown in Figure 7 compares an estimated
arrival time for
the user to an estimated processing completion time for the order (i.e. the
user's selection).
The method 700 is otherwise similar to the method 600 shown in Figure 6, and
may be
executed by a user's mobile wireless telecommunication computing device or by
the order
processing system of either a provider or a provider aggregator, and may be
provided as a
computer program product.
[00114] At step 702, which is a particular embodiment of step 202 of the
method 200
shown in Figure 2, the method 700 receives a user selection comprising at
least one item
selected from a list of items. In cases where a user's mobile wireless
telecommunication
computing device executes the method 700, step 602 will comprise receiving the
user's
selection, whereas for an order processing system of a provider or a provider
aggregator, step
602 will typically comprise receiving an order from a mobile wireless
telecommunication
computing device.
-48-
CA 02839208 2014-01-15
[00115] At step 704, in a particular embodiment of step 206 of the method
200 shown
in Figure 2, the method 700 determines an estimated processing completion time
(i.e. time of
day) for the user selection. A mobile wireless telecommunication computing
device executing
the method 700 can calculate the estimated processing time itself or receive
it from the order
processing system. An order processing system of a provider or a provider
aggregator can
execute step 704 by estimating the processing time for the order or using a
pre-determined
fixed estimate. In either case, physical processing and fulfillment of the
order comprising the
user selection would not yet commence.
[00116] At step 706, which is a particular embodiment of step 204 of the
method 200
shown in Figure 2, the method 700 obtains an estimated arrival time for when a
user is
expected to arrive at the provider location where the user selection is to be
processed.
[00117] An order processing system of a provider or provider aggregator
executing the
method 700 can execute step 706 either by querying the user's mobile wireless
telecommunication device to obtain an identification of the user's location
and using that
location information to execute its own calculation of the estimated arrival
time, by causing
the user's mobile wireless telecommunication device to determine an estimated
arrival time
and send it to the order processing system, or by causing the user's mobile
wireless
telecommunication device to determine and send to the order processing system
an estimated
travel time, which the order processing system can add to the current time to
obtain the
estimated arrival time.
[00118] At step 708, which is a particular implementation of step 208 of
the method
200 shown in Figure 2, the method 700 compares the estimated completion
processing time to
the estimated arrival time, and determines whether the difference between the
estimated
processing time and the estimated travel time satisfies a suitable threshold.
A "yes" result at
step 708 generally indicates that the estimated processing completion time and
the estimated
arrival time, both represented as a time of day, are close to one another. In
addition, it is
preferable that the threshold is set so that step 708 will produce a "yes"
result in cases where
the estimated processing completion time is later than the estimated arrival
time, as this result
-49-
CA 02839208 2014-01-15
suggests that processing of the order will not be completed until after the
user arrives at the
provider location. In such circumstances, processing of the order should begin
immediately so
that waiting by the user after he or she arrives is minimized.
[00119] In response to a "yes" at step 706, the method 700 proceeds to
step 720, at
which the method 700 transmits a communication to commence processing of an
order
comprising the user selection. Step 720 corresponds to step 220 of the method
200 shown in
Figure 2. Where a mobile wireless telecommunication computing device executes
the method
700, step 720 may comprise transmitting the order 372, including the payment
information
354, to the order processing system 362, 392 of the provider 360 or provider
aggregator 390
or, where the order 372 was sent in advance, the signal to commence processing
would be a
separate signal 373 associated with the order 372. In cases where the order
processing system
of a provider aggregator executes the method 700, the signal to commence
processing of the
order would be sent to the order processing system of the relevant provider or
to the relevant
provider location. Where the method 700 is executed by the order processing
system of a
provider, the signal would be sent to the relevant provider location, or where
the provider
comprises a single location, could be a signal to alert the staff to begin
processing the order.
The signal may comprise the order 372 itself or, if the order 372 was sent by
the relevant data
processing system in advance, a signal separate from but associated with the
order 372 may be
sent.
[00120] In response to a "no" determination at step 708, indicating that
the difference
between the estimated processing completion time and the estimated arrival
time does not
satisfy the threshold, the method 700 returns to step 706 to obtain an updated
estimated arrival
time; the return from step 708 to step 706 is a particular embodiment of step
210B of the
method 200 shown in Figure 2. Optionally, if the estimated processing
completion time were
also to be updated, step 210A of the method 200 shown in Figure 2 could be
implemented by
returning to step 704 rather than step 706 following a "no" determination at
step 708, and then
proceeding to step 706.
-50-
CA 02839208 2014-01-15
[00121] Figure 7A is a flow chart illustrating a third exemplary
implementation 700A
of the method 200A shown in Figure 2A. The method 700A shown in Figure 7A is
similar to
the method 700 shown in Figure 7, with identical steps being denoted by
identical reference
numerals. Like the method 600A in Figure 6A, the method 700A in Figure 7A
provides a
notification that the communication to commence processing is about to be sent
and
accommodates a delay instruction. Steps 712, 714 and 716 of the method 700A in
Figure 7A
correspond to steps 612, 614 and 616 of the method 600A shown in Figure 6.
[00122] Figure 7B is a flow chart showing a fourth exemplary
implementation 700B of
the method 200A shown in Figure 2A. The method 700B in Figure 7B is identical
to the
method 700A shown in Figure 7A, except that it allows a user to provide a
delay cancel
command to cancel a previous delay instruction. Again, like reference numerals
are used to
refer to corresponding steps, and step 718 of the method 700B in Figure 7B
corresponds to
step 618 of the method 600B shown in Figure 6B.
[00123] As the number of remote orders increases, it will become more
difficult to
match orders to arriving users if the sequence of arrival of the users is
unknown. The result is
that arriving users who have placed remote orders may have to wait while staff
attempt to
locate their order amongst all the other orders associated with other users.
If multiple users
arrive around the same time, the users may form a queue. This can lead to
frustration on the
user's part, and if the delay is considerable, can lead to a degradation in
the quality of the
goods in the order, defeating the purpose of scheduling processing so that
order completion
coincides with user arrival. Moreover, the greater the number of remote
orders, the worse the
problem gets, especially in a high volume context like a quick service
restaurant.
Accordingly, in addition to scheduling the processing of an order for goods so
that completion
of the order will substantially coincide with the arrival of the user, the
present disclosure also
describes systems, methods and computer program products for organizing the
presentation of
those orders to the users according to the sequence in which the users are
expected to arrive,
which is not necessarily the same order in which processing is triggered.
Knowing the
sequence in which the users are expected to arrive allows staff (or automated
systems) at the
-51-
CA 02839208 2014-01-15
provider location to have the orders sorted in a manner corresponding to that
sequence so that
they can be easily retrieved and presented as the users arrive.
[00124] Figure 11 shows at 1100 a first exemplary method for processing a
plurality of
orders for goods at a provider location. The method 1100 is similar to the
method 100
described above, but also includes steps for organizing the presentation of
the orders to the
users according to the sequence in which the users are expected to arrive.
Steps 1102, 1106
and 1130 will generally be implemented by a processor of a computer system,
while steps
1132 and 1134 may be implemented either by an automated processing system or
by human
individuals, or a combination thereof.
[00125] At step 1102, the method 1100 obtains arrival estimates for when
the users
associated with the orders are expected to arrive at the provider location,
and at step 1106, the
method 1100 uses the arrival estimate to schedule processing of the orders.
Physical
processing of the order at the provider location may then proceed according to
the scheduling
determined at step 1106, and at step 1130, the method 1100 processes the
orders according to
the schedule to produce completed orders. At step 1132 the method 1100 obtains
an arrival
sequence estimate for the users indicating a sequence in which the users are
expected to arrive
and, at step 1134 the method 1100 organizes the completed orders according to
the arrival
sequence estimate. Steps 1130 and 1132 may be performed in any order or
substantially
simultaneously. Preferably, the arrival sequence estimate is continuously
updated and step
1134 is repeated responsive to a change in the arrival sequence estimate. For
example, the
expected sequence of current users may change, or a new user may be added to
the arrival
sequence estimate. Thus, at optional step 1134, the method 1100 checks whether
there are
more completed orders that have not yet been transferred to a user and, as
long as some such
orders remain, the method 1100 returns to step 1132 to obtain an updated
arrival sequence
estimate. Where the arrival sequence estimate determined at step 1132 is
unchanged, step
1134 may be a trivial step of maintaining the previous organization; where the
arrival
sequence estimate determined at step 1132 has changed, step 1134 will comprise
organizing
the completed orders according to the new arrival sequence estimate.
-52-
CA 02839208 2014-01-15
[00126] Figure 11A shows a second exemplary method 1100A for processing a
plurality of orders for goods at a provider location. The method 1100A in
Figure 11A is a
particular implementation of the method 1100 in Figure 11, with the same
reference numerals
referring to corresponding steps. Similarly to the method 100A shown in Figure
1A, the
method 1100A uses an order completion estimate, in addition to the arrival
estimate, to
schedule processing of the order so that completion of processing of the order
is expected to
substantially coincide with arrival of the user at the provider location.
Thus, at step 1104 the
method 1100A obtains an order completion estimate for when processing of the
order is
expected to be completed, and at step 1106A the method 1100A uses both the
arrival estimate
and the order completion estimate to schedule processing of the order.
[00127] In one embodiment, the arrival sequence estimate may be derived
from the
arrival estimates for the individual users. For example, where the arrival
estimates are
estimated times of arrival, the arrival sequence estimate may be obtained by
ordering the
estimated times of arrival in time sequence. Similarly, where the arrival
estimates are
estimated time periods until arrival, the arrival sequence estimate may be
obtained by ranking
the estimated time periods from lowest to highest.
[00128] Although the arrival sequence estimate may be derived from the
arrival
estimates for the individual users, other approaches may produce a more
accurate arrival
sequence estimate, and this increased accuracy may be advantageous in certain
high volume
applications, such as quick service restaurants. Where an object (including a
human being) is
travelling through a constrained travel path network, calculating an estimated
time of arrival
or estimated time until arrival is usually based on predicting the object's
path through the
network. A constrained travel path network is one where travel is limited
(constrained) to
certain predefined path segments. A network of roads through a city is an
example of a
constrained path travel network, since automobiles are effectively confined to
the roads when
travelling between non-adjacent locations - the automobiles cannot (or at
least should not)
drive through houses or other structures to get from one location to another.
A location
tracking system that predicts an estimated time of arrival or estimated time
until arrival will
typically include one or more maps containing information about the layout of
the roads, that
-53-
CA 02839208 2014-01-15
is, the travel path segments, and expected speeds of travel on those travel
path segments. The
location tracking system will use that information, together with the
predicted path of the
target (and possibly information about its actual speed) to estimate how long
it will take for
the object to reach the goal location. While this approach can produce highly
accurate
estimates about when an object such as an automobile or other road vehicle
will arrive in the
general vicinity of the goal location, for example the street location in
front of a restaurant, the
predictive power is greatly diminished once the object leaves the constrained
travel path
network. For example, when a vehicle pulls off the road into the parking lot,
the vehicle's
path toward the goal location is no longer constrained. If the parking lot
near the restaurant is
empty, the vehicle may cut diagonally across the rows of parking spots,
whereas if the parking
lot is full, the vehicle may move parallel to those rows. Moreover, once the
driver exits the
vehicle, he or she may follow a virtually limitless number of paths toward the
goal location,
for example deviating from an otherwise direct path toward the goal location
to pet a small,
cute dog. Thus, during the final portion of the journey toward a goal
location, map-based
methodologies encounter significant limitations on accuracy because they
cannot effectively
predict the path the object will take.
[00129] Accordingly, in one preferred embodiment the arrival sequence
estimate may
be obtained by ordering the users according to their respective radial
distances from a target.
Figure 12A shows schematically an exemplary group of users 1202 consisting of
User 1, User
2 and User 3 each having a respective radial distance DI, D2, D3 from a target
1204. The
arrival sequence estimate 1208A comprises a list of orders ranked in order of
increasing radial
distance of the corresponding users 1202 from the target 1204. As explained
further below,
the target 1204 is preferably a specific point or position 1204 within the
provider location
1206, such as an order fulfillment station at the provider location. For
example, where the
provider location 1206 is a restaurant, the target 1204 may be a pick-up
counter or window, or
the entrance to a drive-through lane. In one preferred embodiment, the target
1204 may be the
location of another networked mobile wireless telecommunication computing
device, which
may be disposed at a pick-up position within the provider location.
-54-
CA 02839208 2014-01-15
[00130] The arrival sequence estimate may be based solely on the radial
distances of
the users from the target, as shown in Figure 12A, or may incorporate other
factors, such as
the current speed of the user. Figure 12B is similar to Figure 12A, with
corresponding
reference numerals referring to corresponding features, except that the
arrival sequence
estimate 1208A in Figure 12B comprises a list of orders 1210 ranked in order
of increasing
expected time until arrival of the users 1202 at the target 1204, calculated
by dividing the
radial distance of each user 1202 from the target 1204 by the respective
velocity VI, V2, V3 of
that user 1202. Although in Figure 12B the users 1202 each have the same
respective radial
distance DI, D2, D3 from the target 1204 as in Figure 12A, with User 2 further
away than User
1, User 2 is moving faster than User 1 and is expected to arrive at the target
1204 first. As
such, while in the arrival sequence estimate 1208A in Figure A, Order 1
associated with User
1 is ranked ahead of Order 2 associated with User 2 because User 1 is closer,
in the arrival
sequence estimate 1208B in Figure 2, Order 2 associated with User 2 is ranked
ahead of Order
1 associated with User 1.
[00131] The radial distances DI, D2, D3 may be obtained in known manner
using
location information received from networked mobile wireless telecommunication
computing
devices carried by the users. For example, a remote ordering application on a
networked
mobile wireless telecommunication computing device may use native
functionality of that
device to obtain the location information by interfacing with a location
module on the device
through the operating system of the device. The velocities VI, V2, V3 may
similarly be
determined in known manner, by computing the change in position over time. For
example,
in the embodiments shown in Figures 4C and 4E, the smartphone 310 of each user
370 may
continue to transmit location information 396 even after order processing has
commenced to
enable the arrival sequence estimate to be determined. In a case where a
user's networked
mobile wireless telecommunication computing device fails to transmit the
location
information required to rank the user in the arrival sequence estimate, that
user may be
marked in the arrival sequence estimate as an exception and removed from the
order ranking.
Orders associated with users marked as exceptions may be segregated from the
other orders.
-55-
CA 02839208 2014-01-15
If a user arrives who does not match the arrival sequence estimate, that user
can be checked
against the exceptions and then matched promptly with their order.
[00132] The location information may be obtained using known techniques,
and may
comprise, for example, global positioning system coordinates, cellular
repeater triangulation
coordinates, Wi-Fi triangulation coordinates, or coordinates derived from a
combination of
these. In particular, it is not intended that the present disclosure be
confined to presently
existing methods for determining location information, and the use of
technologies developed
subsequent to the filing hereof are expressly contemplated.
[00133] While a combination of radial distance from a target and velocity
may be used
to obtain a dynamic arrival estimate (either estimated time of arrival or
estimated time until
arrival), the predictive value will be relatively high only where travel is
relatively
unconstrained, for example through a parking lot. For travel through a
constrained travel path
network such as a road system, however, the predictive power of a dynamic
arrival estimate
based on radial distance and velocity will be poor because it is based on the
unrealistic
assumption of a direct travel path, rather than a travel path that is
constrained by the
requirement to traverse the travel path segments. In contrast, a map-based
dynamic arrival
estimate will provide a good prediction for travel through a constrained
travel path network
such as a road system, but is of limited value for travel that is
substantially unconstrained. An
improved dynamic travel estimate can be obtained by combining the two
techniques such that
a map-based approach is used for travel through a constrained travel path
network while an
approach based on radial distance is used for relatively unconstrained travel.
[00134] As noted above, map-based navigation technology may underestimate
a trip
duration because it generally assumes that a trip is complete when an object
has arrived at the
street address associated with the destination, and it is therefore preferable
for an arrival
estimate generated in this way to be adjusted to account for the final portion
of a trip, such as
parking and walking to the pick-up location. For example, if the provider
location is part of a
ten acre shopping mall, two users may arrive at the mall simultaneously but at
different
entrances that are a kilometer apart and are located at substantially
different distances from the
-56-
CA 02839208 2014-01-15
provider location. One exemplary method for generating an arrival estimate
that adjusts for
these types of factors will now be described.
[00135] Reference is now made to Figure 13, which shows an exemplary
computer-
implemented method 1300 for obtaining a dynamic arrival estimate for arrival
at a destination.
The destination may be, for example, an order fulfillment station within a
provider location.
[00136] At step 1302, during a first trip portion comprising travel within
a constrained
travel path network, the method 1300 calculates the arrival estimate based on
an expected
travel path of the object toward the destination through the constrained
travel path network.
At step 1304, the method 1300 checks for a transition from the first portion
of the trip to a
second portion of the trip; the second trip portion is subsequent to the first
trip portion.
Typically, the second portion of the trip is one in which travel is expected
to be substantially
unconstrained. In one embodiment, transition from the first trip portion to
the second trip
portion is determined by detecting a departure from the constrained travel
path network. For
example, a map-based tracking system may detect that a user has left the
roadway and entered
a parking lot. Alternatively, transition from the first trip portion to the
second trip portion
may be determined by the dynamic arrival estimate falling below a
predetermined threshold.
If the method determines at step 1304 that transition from the first trip
portion to the second
trip portion has not yet occurred, the method 1300 returns to step 1302 to
recalculate the
arrival estimate. Responsive to a determination at step 1304 that transition
from the first trip
portion to the second trip portion has occurred, the method 1300 proceeds to
step 1306.
[00137] At step 1306, during the second trip portion, the method 1300
calculates the
arrival estimate based on the radial distance of the object from the
destination. As noted
above, the calculation may be based solely on radial distance, or may
incorporate the velocity
of the object as well as other factors.
[00138] At step 1308, the method 1300 checks whether the object has
arrived at the
destination. This check may be carried out by comparing the detected location
of the object to
the location of the destination and, where the detected location of the object
matches the
-57-
CA 02839208 2014-01-15
location of the destination (possibly within a margin of error to account for
imprecision in the
detected location or other factors). Responsive to a determination at step
1308 that the object
has not arrived at the destination, the method 1300 returns to step 1306 to
recalculate the
arrival estimate based on the radial distance of the object from the location.
Responsive to a
determination at step 1308 that the object has arrived at the destination, the
method 1300
ends.
[00139] Since the arrival estimate is continuously or periodically
recalculated (at steps
1302 and 1306), the arrival estimate is a dynamic arrival estimate. Step 1306
adjusts the
arrival estimate generated at step 1302.
[00140] In the embodiment shown in Figure 13, a single calculation type is
used during
each trip portion, namely calculation based on an expected travel path of the
object toward the
destination through the constrained travel path network during the first trip
portion, and
calculation based on radial distance during the second trip portion. In other
embodiments,
both calculations may be carried out simultaneously. For example, the arrival
estimate may be
a weighted average of a calculation based on an expected travel path of the
object toward the
location through the constrained travel path network and a calculation based
on radial
distance. The weighting may be fixed, or may vary so that during the first
trip portion, the
arrival estimate is weighted more toward the calculation based on an expected
travel path of
the object toward the location through the constrained travel path network and
during the
second trip portion, the arrival estimate is weighted more toward the
calculation based on
radial distance. In other embodiments, the method may encompass a first trip
portion during
which the arrival estimate is based on an expected travel path of the object
toward the
destination through the constrained travel path network, a second trip portion
during which
the arrival estimate is based on radial distance from the destination, and an
intermediate trip
portion between the first trip portion and the second trip portion and during
which both
techniques are used.
[00141] Having an arrival sequence estimate for the sequence in which the
users are
expected to arrive allows the completed orders for goods to be organized for
easy
-58-
CA 02839208 2014-01-15
presentation. For example, the orders for goods may be arranged in a queue in
which the next
order in the queue corresponds to the user who is expected to arrive next.
This can provide
considerably improved efficiency.
[00142] It is also contemplated that in certain circumstances, it may be
advantageous to
schedule order processing based solely on an arrival sequence estimate,
without use of an
arrival estimate for when a user is expected to arrive. For example, toys are
generally non-
perishable and do not physically degrade when pulled from shelves to fill an
order. As such, it
would not be particularly disadvantageous if a remotely-placed order for toys
were ready well
before the user arrived to pick up that order. In such circumstances,
scheduling processing of
the order according to an arrival sequence estimate (e.g. the order for which
the user is
expected to arrive next is processed next) may be suitable.
[00143] Figure 14 shows an exemplary method 1400 for processing a
plurality of orders
for goods at a provider location. At step 1402, the method 1400 obtains an
initial arrival
sequence estimate for the users associated with the respective orders. As
before, the arrival
sequence estimate indicates the sequence in which the users are expected to
arrive, and may
be obtained as described above. At step 1404, the method 1400 uses the arrival
sequence
estimate to schedule processing of the orders, and at step 1406 the method
1400 processes the
orders according to the schedule to produce completed orders. At step 1408,
the method 1400
organizes the completed orders according to the arrival sequence estimate.
[00144] In a preferred embodiment, the arrival sequence estimate is
continuously
updated and step 1408 will be repeated if the arrival sequence estimate
changes. Accordingly,
at optional step 1410, the method 1400 checks whether there are more completed
orders that
have not yet been picked up or otherwise disposed of. Where step 1410
determines that there
are still some such orders, the method 1400 proceeds to optional step 1412 to
obtain an
updated arrival sequence estimate, and then returns to step 1408 to organize
the order
according to the updated arrival sequence estimate. If the updated arrival
sequence estimate is
the same as the initial arrival sequence estimate, step 1408 may consist of
merely maintaining
the previous organization; if the arrival sequence estimate changes, step 1408
comprises
-59-
CA 02839208 2014-01-15
organizing the completed orders according to the new arrival sequence
estimate. Optionally,
instead of returning to step 1408 after optional step 1412, the method 1400
may return to step
1404 update the scheduling of order processing.
[00145] Steps 1402, 1404, 1410 and 1412 will generally be implemented by a
processor
of a computer system, while steps 1406 and 1408 may be implemented either by
an automated
processing system or by one or more human individuals, or a combination
thereof.
[00146] In some instances, little or no physical processing is required in
order to fulfill
an order for goods. Picking up a parcel at the post office is an example of
this, as there is no
physical processing of the parcel itself¨ when a user arrives to collect a
parcel, it is merely a
matter of finding the parcel and handing it to the user (as well as having the
user present
identification, sign for the parcel, etc.). However, time may be consumed in
finding the right
parcel while the user waits at the counter, since the post office staff did
not know when the
user was coming. If the post office staff knew the sequence in which users
were coming to
collect parcels, the staff could organize those parcels according to that
sequence, simplifying
the process considerably. The same approach could be applied to the storage
and retrieval of
luggage by a hotel concierge, as well as a variety of other contexts.
[00147] Figure 14A shows an exemplary method 1400A for fulfilling a
plurality of
orders for goods at a provider location. The method 1400A is similar to the
method 1400 in
Figure 14, except that there is no physical processing of goods associated
with the orders, so
steps 1404 and 1406 are omitted. The method 1400A may be applied in situations
that do not
require physical processing of the goods associated with an order (other than
delivering them
to the user), such as the post office and hotel concierge examples noted
above.
[00148] Certain aspects of operation of an exemplary remote ordering
application, such
as the exemplary remote ordering application 350, will now be described by
reference to
Figures 15A through 15M, which show exemplary screen shots representing a
display of a
touchscreen networked mobile wireless telecommunication computing device
executing a
-60-
CA 02839208 2014-01-15
remote ordering application as described herein. Individual screen displays
are referred to as
"pages".
[00149] Figure 15A shows a main landing page for the exemplary remote
ordering
application, which includes a trademark position 1502 for displaying a
trademark, as well as a
plurality of icons, namely a "New Orders" icon 1504, a "Favourites" icon 1506,
an "All
Orders" icon 1508, an "Offers" icon 1510, a "Settings" icon 1512 and a
"Suggestions" icon
1514. The main landing page also includes a user identity display 1516 and a
"Log Out/Log
In" icon 1518. By selecting one of the icons 1504, 1506, 1508, 1510, 1512 or
1514, a user can
access various features of the remote ordering application.
[00150] Selecting the "New Orders" icon 1504, either on the main landing
page in
Figure 15A or in the navigation region 1538, will generate a page displaying
all providers
within a pre-defined search radius of the user's current location, that is,
the current location of
the networked mobile wireless telecommunication computing device. The
providers may be
displayed as a list 1520 displaying entries 1522 for the available providers,
as shown in Figure
15B, or as a map 1524 displaying the providers as icons 1526, as shown in
Figure 15C. A
"List" button 1528 and a "Map" button 1530 are provided for switching between
the list or
map views, and a "Home" button 1534 allows a user to return to the main
landing page shown
in Figure 15A. A "Refine Search" button 1536 allows users to access a page
(not shown) for
refining the search parameters to narrow or expand the list of providers.
Generation of the list
and map views of the available providers is within the capability of one
skilled in the art, now
informed by the present disclosure. For example, such a list may be generated
by interfacing
with the Google Maps system. Google Maps is offered by Google Inc., having an
address at
1600 Amphitheatre Parkway, Mountain View, CA 94043, United States. More
information
about interfacing with Google Maps is available at
https://developers.google.com/maps/.
[00151] A horizontal navigation region 1538 is provided at the bottom of
many of the
pages, as shown in Figures 15B to 15F and 15M, displaying a subset of the
icons 1504, 1506,
1508, 1510, 1512 or 1514; in those Figures the most frequently accessed icons,
the "New
Orders" icon 1504, "Favourites" icon 1506, "All Orders" icon 1508 and "Offers"
icon 1510
-61-
CA 02839208 2014-01-15
are displayed. Optionally, a user can scroll horizontally through the
navigation region 1538 to
access additional icons.
[00152] Selecting the "Favorites" icon 1506, either on the main landing
page in Figure
15A or in the navigation region 1538, will generate a page, as shown in Figure
15D,
displaying orders that a user or the remote ordering application has
designated as "favorites",
typically because the order frequently recurs. For example, an order for a
coffee and donut
that is placed every weekday morning, or an order for a family pizza night,
might be
designated as a "favorite". The "favorite" orders are displayed as a list 1540
displaying
entries 1542 showing an identification 1544 of the relevant provider as well
as a summary
1546 of the order. Selecting one of the entries 1542 would generate a page
showing more
detail about the order, as described further below. Optionally, a user can
also designate
certain providers as "favorite" providers, and an "Orders" button 1548 and a
"Merchants"
button 1550 are provided for switching between a list of favourite orders and
a list of
favourite providers.
[00153] Selecting the "All Orders" icon 1508, either on the main landing
page in Figure
15A or in the navigation region 1538, will generate a page displaying orders
in a manner
similar to the "Favourites" page, that is, as a list 1540 displaying entries
1542 showing an
identification 1544 of the relevant provider as well as a summary 1546 of the
order.
Respective buttons 1552, 1554 and 1556 are provided for allowing a user to
selectively
display "saved" or "favourite" orders, as shown in Figure 15E, "active" orders
that have been
placed and are awaiting fulfillment, as shown in Figure 15F and "recent"
orders (not shown).
The recent orders may be orders placed within a previous predefined period,
such as one week
or one month, or may be the X most recent orders, where X is a positive
integer. Optionally
(not shown) a button may be provided for displaying "favourite", "active" and
"recent" orders
simultaneously (possibly with vertical scrolling). As can be seen in Figure
15F, for the
"active" orders, the summary 1546 shows both the arrival estimate as well as
the time
remaining until a signal (e.g. signal 373) to commence processing is sent.
-62-
CA 02839208 2014-01-15
[00154] Figure 15G shows a menu page for placing an order after a provider
is selected,
for example from the page shown in Figure 15B. A "Breakfast" button 1558,
"Lunch" button
1560 and "Dinner" button 1562 are provided for selecting among various menu
categories. In
one embodiment, the remote ordering application will permit a user to place an
order
containing items within a menu category that is not presently available; for
example a user
could, during breakfast hours, generate a dinner order that could be saved,
although the remote
ordering application (or order processing system) would not permit the user to
activate that
order, for example by pressing the "I'm on my way" button 1583 (Figure 151),
until dinner
service at the relevant provider is available. For example, the "I'm on my
way" button 1583
could be grayed out on the "check out" page shown in Figure 151 if the order
is not yet able to
be acted upon. In one embodiment, the system (either the remote ordering
application or the
order processing system, or both in combination) will compare the arrival
estimate, the order
completion estimate and the availability time of the menu category to
determine whether an
order can be placed (as opposed to being saved for later action). For example,
suppose a user
wishes to place a lunch order at 10:45 a.m., the user is thirty minutes away
from the provider
location, lunch starts at 11:00 a.m. and the order will take ten minutes to
prepare. In this
scenario, since there is enough time between availability of the "lunch" menu
category (11:00
a.m.) and the user's expected arrival (11:15 a.m.) to prepare the order (which
takes ten
minutes), the system would allow the user to initiate that order using the
"I'm on my way"
button 1583. Similarly, the system could also compare the arrival estimate to
the hours of
operation of the provider location, for example preventing a user from
initiating an order if the
user will not arrive at the provider location until after it is closed.
[00155] In Figure 15G, a lunch menu has been selected and various menu
items are
presented in the form of a list 1564 of menu item entries 1566. A horizontal
menu navigation
region 1568 allows the user to navigate among various types of menu items, and
in the
embodiment shown in Figure 15G, allows for selection among "Salads", "Value
Meals",
"Sandwiches", "Side Orders", "Drinks" and "Deserts". The icon for "Side
Orders" is partially
obscured and the icons for "Drinks" and "Deserts" are not visible, these can
be accessed by
scrolling the menu navigation region 1568. A "Back" button 1570 allows a user
to return to
-63 -
CA 02839208 2014-01-15
the previous page, and a "Check Out" button 1572 allows a user to access a
"check out" page
(described further below).
[00156] By selecting one of the menu item entries 1566, a user can access
a menu item
detail page for that menu item, as shown in Figure 15H. The menu item detail
page shown in
Figure 151 includes a quantity specifier 1574 and one or more detail
specifiers 1576 for
specifying required details of the menu item, such as the size and type of an
accompanying
drink and/or side order. A note specifier 1578 can be used for making unusual
requests, such
as removing a condiment or adding an unexpected condiment. The menu item
detail page
also includes the "Back" button 1570 and "Check Out" button 1572.
[00157] Figure 151 shows an exemplary "check out" page reached by
selecting the
"Check Out" button 1572. It will be appreciated that the content of the page
shown in Figure
151 may be larger than the available screen real estate on a typical
smartphone; all of the
content can be accessed by vertical scrolling and the entire page is shown in
a single view for
simplicity of illustration. The "check out" page includes an order summary
1580, which in
turn includes item correction icons 1580A for returning to the menu item
detail page for that
menu item, and item deletion icons 1580B for deleting an item. The "check out"
page also
includes a payment specification 1582, for example for entering credit card
information or for
accessing a third party payment provider. Payment information may, for
example, be stored
locally, stored by an order processing system, provided by a third party
payment processor, or
may be entered each time and discarded after each use. In addition, the "check
out" page
includes an "I'm on my way" button 1583, a "Save" button 1584, and a "Link"
button 1585.
[00158] The "I'm on my way" button 1583 is used when the user who placed
the order
will be picking it up and will, depending on the configuration, cause the
remote ordering
application to perform one of a number of sets of actions. In one embodiment,
selecting the
"I'm on my way" button 1583 may cause the remote ordering application to store
the order
and begin monitoring the location of the networked mobile wireless
telecommunication
computing device so that the order can be transmitted to an associated order
processing
system at the appropriate time. In another embodiment, selecting the "I'm on
my way" button
-64-
CA 02839208 2014-01-15
1583 may cause the remote ordering application to transmit the order to an
associated order
processing system and begin monitoring the location of the networked mobile
wireless
telecommunication computing device so that a signal to commence processing
can, when
appropriate, be transmitted to the order processing system. In a further
embodiment, selecting
the "I'm on my way" button 1583 may cause the remote ordering application to
transmit the
order to an associated order processing system and begin monitoring the
location of the
networked mobile wireless telecommunication computing device for the purpose
of
transmitting the location information to the order processing system.
Typically, selecting the
"I'm on my way" button 1583 will trigger at least a payment pre-authorization
process.
[00159] Selecting the "Save" button 1584 will store the order, either
locally on the
networked mobile wireless telecommunication computing device or on an order
processing
system for later use, for example as "Favourite". Selecting the "Link" button
1585 will
associate the order with a different networked mobile wireless
telecommunication computing
device to facilitate pickup by a user different from the user who placed the
order.
[00160] Figure 15J shows a page generated responsive to selection of the
"Link" button
1585. This page displays a list 1586 of available users with whose networked
mobile wireless
telecommunication computing device the order may be associated. Selecting the
button 1587
for one of those users would, in one embodiment, transmit the order to the
relevant order
processing system and associate it with the networked mobile wireless
telecommunication
computing device of the selected user. For example, a signal may be sent,
either from the
networked mobile wireless telecommunication computing device on which the
order was
placed or from the order processing system, to the remote ordering application
on the
networked mobile wireless telecommunication computing device of the selected
user. This
signal could, for example, cause the remote ordering application on the
networked mobile
wireless telecommunication computing device of the selected user to display an
alert, provide
access to details of the order, and provide an "I'm on my way" button 1583 on
that networked
mobile wireless telecommunication computing device.
-65-
CA 02839208 2014-01-15
[00161] Establishing the list 1586 of available users with whose networked
mobile
wireless telecommunication computing device the order may be associated may be
done in a
number of ways. In one embodiment, a first user may identify the networked
mobile wireless
telecommunication computing device of a second user by entering a unique
identifier, such as
a telephone number, for that device. The remote ordering application may then
send an
invitation to the networked mobile wireless telecommunication computing device
of a second
user, and the second user would only be added to the list 1586 of available
users if the second
user indicated his or her assent. The invitation could be handled by a remote
ordering
application on the networked mobile wireless telecommunication computing
device of the
second user or, where a corresponding remote ordering application has not been
installed, on
that device, may include instructions for such installation. For example, an
invitation may
comprise a text message with a link for installation.
[00162] Once the user has selected the "I'm on my way" button 1583, the
remote
ordering application may present navigation information for travelling from
the present
location of the user's networked mobile wireless telecommunication computing
device to the
provider location. The navigation information may be presented either as a map
1588, as
shown in Figure 15K, or as a list 1589 of written directions, as shown in
Figure 15L. A
"Map" button 1590A and a "Directions" button 159013 for switching between the
map and
direction views. In each of the map view (Figure 15K) and the directions view
(Figure 15L), a
"Confirmation" button 1592 allows the user to display order confirmation
information, such
as a bar code or QR code, on the display of the networked mobile wireless
telecommunication
computing device to facilitate order pickup. The map view (Figure 15K) and the
directions
view (Figure 15L) also each include an arrival estimate display 1591A showing
the arrival
estimate and an order processing commencement display 1591B showing when order
processing is expected to commence. The order processing commencement display
1591B
may indicate how much time a user has before he or she is no longer able to
pause, change or
cancel an order.
[00163] Selecting the "Offers" icon 1510 causes the remote ordering
application to
present an "Offers" page, as shown in Figure 15M, showing various offers 1593
from
-66-
CA 02839208 2014-01-15
participating providers. The offers may include an "Order Item(s)" button 1594
allowing a
user to generate an order directly from the "Offers" page.
[00164] Regardless of whether orders are transmitted to the order
processing system
362 of a provider 360 or the order processing system 392 of a provider
aggregator 390, in a
preferred embodiment a point-of-sale (POS) system integrated with the relevant
order
processing system is used at the provider location(s). In one preferred
embodiment, the POS
system is provided as software which can be installed on a computer system at
the provider
location. The computer system may comprise a single computer or a plurality of
computers.
Any type of computer system may be used, although preferably a computer system
having a
location module enabling geolocation of the computer system is used. Tablet
computers
having geolocation modules, such as those offered under the trademark iPad by
Apple, having
an address at 1 Infinite Loop, Cupertino, CA 95014, are well-suited to this
function, although
other tablet computers may also be used. One particular advantage of using a
computer that
includes a location module is that the position of the computer, as determined
using its
location module, may be used as the target 1204 (Figures 12A and 12B) for
generating the
arrival sequence estimate. For example in a restaurant setting, a tablet
computer having a
location module enabling geolocation can be positioned at an order fulfillment
station, such as
a pick-up counter or drive-through window, and can communicate its location to
the order
processing system 362, 392. The physical placement of the tablet computer at
the order
fulfillment station effectively designates the position of the order
fulfillment station to use as
the target 1204 for generating the arrival sequence estimate.
[00165] Figures 16A to 16F show exemplary screen shots each representing a
display of
a touchscreen networked mobile telecommunication computing device executing an
exemplary provider order fulfillment support application in communication
with, or forming
part of, an order processing system, such as the order processing systems 362
or 392 described
above. Preferably the device communicates wirelessly although wired
communication is also
contemplated. Individual screen displays are referred to as "pages".
-67-
CA 02839208 2014-01-15
[00166] The exemplary provider order fulfillment support application is
intended for
use in an embodiment in which the order 372 is transmitted separately from,
and in advance
of, the signal 373 to commence processing, and has five primary functions,
each of which is
described below.
[00167] Figure 16A shows an exemplary page for a "Pending Orders"
function, which
displays a list 1602 having pending order entries 1604 for each of a plurality
of orders. The
orders displayed on the page for the "Pending Orders" function are those
orders that have been
confirmed but where the signal 373 to commence processing has not yet been
received. For
example, an order may be added to page shown in Figure 16A responsive to a
user selecting
the "I'm on my way" button 1583 in Figure 151. By selecting one of the pending
order entries
1604, order details 1606 can be displayed. The pending order entries 1604 each
include an
indicator 1608 of the arrival estimate for the associated user, in this case
the estimated time
until arrival at the provider location. The "Pending Orders" function permits
a provider
location to forecast demand. In many cases, a provider could be more efficient
in using their
existing order processing capacity if they knew the orders they would have to
fulfill in the
near future, and the "Pending Orders" function provides this information.
[00168] Figure 16B shows an exemplary page for a "New Orders" function,
which
displays a list 1610 having new order entries 1612 for each of a plurality of
orders. The orders
displayed on the page for the "New Orders" function are those orders for which
the signal 373
to commence processing has been received and therefore processing should
commence.
When the signal 373 to commence processing has been received and an order
transitions from
the page for a "Pending Orders" (Figure 16A) to the page for "New Orders"
(Figure 16B), an
audible alert is preferably generated, and the corresponding new order entry
1612 appears at
the top of the list 1610 and is presented in bold, as shown for the two
uppermost order entries
1612 in Figure 16B. The new order entries 1612 each include an indicator 1616
of the arrival
estimate for the associated user. Selecting one of the new order entries 1612
will display
order details 1614, which are similar to the order details 1606 for the
"Pending Orders"
function except that the order details 1614 for the "New Orders" function
include completion
indicators 1619 denoting whether a particular component of the order has been
completed.
-68 -
CA 02839208 2014-01-15
Preferably, in a case where a predetermined period of time elapses without a
newly added new
order entry 1612 having been selected and its order details 1614 viewed, the
provider order
fulfillment support application can transmit an alert to the order processing
system 362, 392.
[00169] In many cases, orders can be separated into components. For
example, in a
sandwich-type quick service restaurant, components may be beef sandwiches
(hamburgers),
chicken and fish items, side orders, and drinks, each of which is prepared at
a separate station.
In a grocery store context, components may be, for example, non-perishable
items, bakery
items, deli items, seafood items, butcher items and produce items. In a toy
store context,
components may be, for example, toys for boys, toys for girls, baby toys, and
electronics. One
aspect of the exemplary provider order fulfillment support application
facilitates separate,
simultaneous processing of various components of an order.
[00170] Preferably, a provider order fulfillment support application will
enable
different pages to be displayed for different components of an order. In one
embodiment,
touchscreen displays may be provided at each preparation station for a given
component, with
each display coupled to a central computer system. In another embodiment, a
networked
mobile telecommunication computing device executing a provider order
fulfillment support
application may be provided at each preparation station. Such arrangements
allow staff at
each preparation station to view a page showing only those items that are to
be processed at
that preparation station. For example, in a sandwich-type quick service
restaurant, a page
displaying only beef sandwiches may be displayed at the beef sandwich station,
a page
displaying only chicken and fish items may be displayed at the chicken and
fish station, and so
on. Presenting different pages for different component types may be achieved
in a number of
ways. In one presently preferred embodiment suitable for multi-station
restaurant
applications, each menu item is assigned a number designating the type of
component that the
menu item is. For example, "1" may designate a menu item as a "drink"
component, "2" may
designate a menu item as a "side order" component, "3" may designate a menu
item as a "beef
sandwich" component, "4" may designate a menu item as a "chicken/fish"
component, and so
on. Then, by selecting a number, menu items designated by that number, and
hence
corresponding to a particular component, may be isolated and displayed.
-69-
CA 02839208 2014-01-15
[00171] Figure 16C shows an exemplary page for a "Preparation" function of
a
provider order fulfillment support application for use in a quick service
restaurant. The page
shown in Figure 16C includes several numbered component designation buttons
1618. The
component designation button 1618 numbered "3" has been selected, and a list
1620 of menu
item entries 1622 is displayed; the menu item entries 1622 correspond to menu
items in orders
for which the signal 373 to commence processing has been received. The number
"3"
designates "beef sandwich" components, and as a result the list 1620 of menu
item entries
1622 only shows those menu item entries 1622 for which the menu item is
designated with a
"3", that is, as a "beef sandwich" component. By selecting a different
component designation
button 1618, menu items corresponding to a different component type could be
displayed, and
by selecting an "All" component designation button 1624, menu item entries
1622 for all
menu items could be displayed, for example for a manager. Each of the menu
item entries
1622 includes a completion indicator 1626, which can be selected by a staff
member to
indicate that the corresponding menu item is complete. Responsive to a menu
item entry 1622
being marked as complete, after a brief delay the provider order fulfillment
support
application would remove that menu item entry 1622 from the page shown in
Figure 16C and
update the corresponding completion indicator 1619 in the page shown in Figure
16B. This
process can also serve as a signal that an order is being addressed. The
"Preparation" function
whose page is shown in Figure 16C can also support component-based order
processing, so
that processing of the various components of an order can be triggered
separately based on the
processing time required for each component. In alternate embodiments, the
"Preparation"
function may have other types of visual display, for example a graphical
display showing how
many of each component type should be prepared (e.g. how many small, medium
and large
fries, how many Cowboy Burgers, etc.).
[00172] Figure 16D shows an exemplary page for an "Incoming Orders"
function of an
exemplary provider order fulfillment support application, which displays an
arrival sequence
estimate as a list 1630 having incoming order entries 1632 for each of a
plurality of orders,
ranked in order of expected arrival, with the uppermost incoming order entry
1632 being for
the order whose associated user is expected to arrive next. The incoming order
entries 1632
-70-
CA 02839208 2014-01-15
each also include an indicator 1634 of the arrival estimate for the associated
user, in this case
the estimated time until arrival at the provider location, and by selecting
one of the incoming
order entries 1632, order details 1614, including completion indicators 1619,
can be displayed.
The list 1630 allows a staff member to easily determine the order associated
with the next
user expected to arrive, so that the order can be prepared for presentation to
the user
substantially immediately upon their arrival. Depending on the configuration,
the list 1630
may include incoming order entries 1632 for all orders in the system, or only
for a subset of
orders. For example, the list 1630 may include incoming order entries 1632
only for those
orders for which the signal 373 to commence processing has been received, or
only for orders
for which the arrival estimate falls below a predetermined threshold, such as
one minute.
Optionally, a sub-threshold for the arrival estimate, such as thirty seconds,
may be provided,
and incoming order entries 1632 for orders whose arrival estimate is below the
sub-threshold
may be highlighted, as shown in Figure 16D. The arrival sequence estimate may
be
continuously updated for all orders, or, for orders for which the arrival
estimate is below a
threshold, the position of those orders in the arrival sequence estimate may
be fixed. In the
embodiment shown in Figure 16D, this would lead to the uppermost incoming
order entries
1632 in the list 1630 having a fixed position while incoming order entries
1632 below that
uppermost group were reshuffled. The list 1630 shown in Figure 16D is merely
one
exemplary embodiment of a visual representation of an arrival sequence
estimate, and other
embodiments may also be used. For example, and without limitation, the arrival
sequence
estimate may be presented as a "radar-type" map, similar to that shown in
Figures 12A and
12B, showing radial distance of the users from the target 1204, or may be a
list ordered in
some manner other than sequence of expected arrival, but with entries that
include a number
or symbol indicating expected order of arrival.
[00173] The exemplary page for the "Incoming Orders" function of the
exemplary
provider order fulfillment support application shown in Figure 16D also
includes a "Discard"
button 1636, a "Print" button 1638 and a "Complete" button 1640. Selecting the
"Discard"
button 1636 will cause the exemplary provider order fulfillment support
application to delete
the order associated with the highlighted order entry 1632 whose order details
1614 are
-71-
CA 02839208 2014-01-15
shown, for example if the associated user never arrives. The "Print" button
1638 can be used
to print a copy of the order details 1619 (the "Print" button 1638 also
appears on the page for
the "New Orders" function shown in Figure 16B). The "Complete" button 1640 is
used when
a user has collected their order, and causes the exemplary provider order
fulfillment support
application to mark the order as complete and trigger the appropriate payment
processing
steps, such as charging a credit card. Selecting the "Complete" button 1640
may also send a
signal that will cause the remote ordering application 350 to cease monitoring
location or
transmitting location information so to conserve battery life and data usage
on the networked
mobile wireless telecommunication computing device. Alternatively this may be
achieved by
scanning a bar code or QR code on the networked mobile wireless
telecommunication
computing device, through manual deactivation, location services, or
otherwise. In the
illustrated embodiment, selecting the "Complete" button 1640 generates a
confirmation button
1640A to confirm the order is to be completed, and a cancellation button 1640B
for use if the
"Complete" button 1640 was selected by mistake. A similar approach would be
used for the
"Discard" button 1636 to reduce the likelihood of accidentally discarding an
order.
[00174] Reference is now made to Figure 16E, which shows an exemplary page
for a
"Complete Orders" function of an exemplary provider order fulfillment support
application.
This page includes a list 1642 containing order entries 1644 for orders that
have been marked
as complete, and selecting one of the order entries 1644 will display order
details 1646 for that
order. A "Refund" button 1648 is provided, selection of which will cause the
exemplary
provider order fulfillment support application to initiate a refund process
where required.
[00175] Each of the pages shown in Figures 16A to 16E includes a vertical
navigation
region 1650 containing icons for navigating among the various pages, namely a
"Pending"
icon 1652 for navigating to the "Pending Orders" page in Figure 16A, a "New"
icon 1654 for
navigating to the "New Orders" page in Figure 16B, a "Prep" icon 1656 for
navigating to the
"Preparation" page in Figure 16C, an "Incoming" icon 1658 for navigating to
the "Incoming
Orders" page in Figure 16D and a "Complete" icon 1660 for navigating to the
"Complete
Orders" page in Figure 16E.
-72-
CA 02839208 2014-01-15
[00176] It is contemplated that a provider order fulfillment support
application of the
type described and illustrated in respect of Figures 16A to 16E could, in
conjunction with a
remote ordering application executing on one or more networked mobile wireless
telecommunication computing devices, supplement or replace existing POS
systems. In one
embodiment, users would use their networked mobile wireless telecommunication
computing
devices to place their orders instead of placing a verbal order. To facilitate
this approach, a
specialized remote ordering application without location-based features may be
implemented
as a browser-executed web application. Alternatively, cashiers or wait staff
could use a
networked mobile wireless telecommunication computing device executing the
remote
ordering application to enter orders and receive payment.
[00177] It is also contemplated that, where services are provided by a
provider
aggregator, pick-up of goods orders from multiple locations may be supported.
A user could
enter multiple orders for multiple providers, and the order processing system
can recommend
a sequence for pick-up based on the user's location as well as other factors
(e.g. perishable
food last). Alternatively, a user could manually set the sequence.
[00178] Optionally, the remote ordering application 350 may permit an
order, generated
by that user or linked by another user, to create an appointment to serve as a
reminder, for
example by synchronizing with a calendar application on the networked mobile
wireless
telecommunication computing device. In one exemplary application, one spouse
could send a
dinner order to the other and also generate a reminder appointment in the
latter spouse's
calendar so the latter spouse does not forget to pick up dinner.
[00179] It is further contemplated that a remote ordering application may
include
suitable recognition software and be integrated with a camera on the networked
mobile
wireless telecommunication computing device to generate orders by scanning bar
codes or QR
codes, or by capturing an image of the item. For example, a user could build a
grocery order
from a paper grocery store flyer, or by scanning the bar code on empty
containers.
-73-
CA 02839208 2014-01-15
[00180] In addition, a remote ordering application may incorporate a
"sharing" or social
media functions. For example, one user may use the remote ordering application
to
recommend a product or provider to another user, who could then generate an
order from the
recommendation. A first user may also grant selected other users access to his
or her prior
orders to see what he or she has purchased, without necessarily allowing the
other users to
place orders and link them to that first user.
[00181] A user may allow himself or herself to be openly solicited based
on location
information or based on a category of interest, or both. For example, a user
may be hungry
but not sure where he or she would like to eat, or may be in an unfamiliar
area and unsure of
what restaurant options are available. The user could open an application,
such as the remote
ordering application 350, on his or her networked mobile wireless
telecommunication
computing device, such as the smartphone 310, and choose to be solicited.
Individual
restaurants associated with a provider aggregator 390 may have submitted
commercial data to
the provider aggregator 390 in advance, such as daily specials, or may
determine that a user is
requesting such a commercial solicitation, for example by way of a request
from an order
processing system 392 of the provider aggregator 390, and submit the relevant
commercial
data in response. The provider aggregator 390 then generates the commercial
solicitations
based on the location information and/or the area of interest, and transmits
them to the remote
ordering application 350 on the user's networked mobile wireless
telecommunication
computing device. The commercial solicitations may be displayed, for example,
on an
"Offers" page like that shown in Figure 15M. The user can then choose the most
appealing
commercial solicitation, and place an order using the remote ordering
application 350 as
described above. The provider aggregator 390 can also provide directions to
the selected
provider, or interface with a navigation system on the user's networked mobile
wireless
telecommunication computing device to provide such directions.
[00182] In certain embodiments, a general search for commercial
solicitations can be
provided, without reference to the user's current or planned location, for
cases where a user
may wish to be made aware of the various commercial solicitations, such as
daily specials,
within a wider geographic area. For example, a user may be at home and be
hungry but not
-74-
CA 02839208 2014-01-15
sure where to eat, and can determine what daily specials are available from
restaurants
associated with the provider aggregator 390, or may be interested in acquiring
a particular
product such as a television, and can specify "electronics" as an area of
interest to see if there
are any relevant special offers among the providers 360A, 360B...360n
associated with the
provider aggregator 390. In such cases, the user may not wish to set
geographical limitations
in advance, because he or she may be willing to travel further depending on
how enticing the
offer is.
[00183] Reference is now made to Figure 8, which illustrates schematically
an
arrangement and method for communicating at least one commercial solicitation.
The
physical components of the arrangement are identical to those shown in Figures
5A to 5C, and
hence corresponding reference numerals are used to refer to corresponding
features.
[00184] A user of the smartphone 310 generates a query 802 using the
remote ordering
application 350, and the smartphone 310 then transmits the query 802 through
the network
320 to the order processing system 392 of a provider aggregator 390. The query
802 includes
location information 804 and a specification 806 indicating an area of
interest to the user. The
location information 804 may be the current location of the smartphone 310
(and hence the
user) derived from the GPS receiver 340, or may be manually entered by the
user. For
example, if the user is travelling, the user may wish to specify his or her
destination rather
than his or her present location. In another embodiment, the query may be sent
from a user's
desktop computer instead of from a networked mobile wireless telecommunication
device, in
which case the location information may be manually entered or obtained from
an ISP.
Optionally, the location information 804 may comprise a planned travel route,
so that
providers 360A, 360B...360n along the planned travel route can be identified.
This would
enable, for example, a user who is about to head home from work and wants to
pick up food
to receive commercial solicitations from providers located along his or her
planned route, and
then place an order in accordance with the methods described above.
[00185] The specification 806 indicating an area of interest to the user
is optional, and
is used in cases where the provider aggregator 390 coordinates the offerings
of providers
-75-
CA 02839208 2014-01-15
360A, 360B.. .360n in different areas of interest. For example, if the
provider aggregator 390
aggregates restaurants, the specification 806 could specify different types of
restaurant, and if
the provider aggregator 390 is the management of a shopping mall, it may
coordinate
providers 360A, 360B.. .360n in such diverse areas of interest as restaurants,
electronics,
furniture, jewellery, hairstyling, general merchandise, clothing (including
both men's and
women's clothing and various subcategories of clothing such as formal wear,
casual wear,
urban wear, swim wear and the like), pet stores, and so on. By providing for
the specification
806 indicating an area of interest to the user, the provider aggregator 390
can provide a more
useful response to the query 802.
[00186] The order processing system 392 of the provider aggregator 390
receives the
query 802, including the location information 804 and specification 806 of an
area of interest,
if any, and in response, determines at least one local provider 360A,
360B...360n having a
provider location within a predetermined proximity to the location specified
by the location
information 804. The order processing system 392 selects only local providers
360A,
360B.. .360n whose offerings correspond with the area of interest indicated by
the
specification 806. The determination and selection can be made in any order.
For example,
the providers 360A, 360B...360n corresponding to the area of interest can be
selected first,
and then those providers having a provider location within a predetermined
proximity to the
location specified by the location information 804 can be determined from that
subset.
Alternatively, the order processing system 392 may first determine those
providers having a
provider location within a predetermined proximity to the location specified
by the location
information 804, and then select the providers 360A, 360B...360n corresponding
to the area
of interest. Once the order processing system 392 has identified the local
providers 360A,
360B...360n having a provider location within a predetermined proximity to the
location
specified by the location information 804, and also corresponding to the area
of interest, if
applicable, the order processing system 392 will transmit at least one
commercial solicitation
808 associated with a respective one of the at least one local provider 360A,
360B...360n to
the smartphone 310 via the network 320.
-76-
CA 02839208 2014-01-15
[00187] In one alternative embodiment, such as where the provider
aggregator 390
coordinates the offerings of providers 360A, 360B.. .360n in only a single
area of interest, the
specification 806 indicating an area of interest, and the provision therefor,
may be omitted and
determination of providers may be based on the location information 804,
without reference to
area of interest. In another alternative embodiment, the location information
804 may be
omitted and the providers may be selected based on area of interest, without
reference to
location. This latter embodiment would be suitable for cases where the
provider aggregator
390 is the management of a shopping mall. Thus, a user who is planning to head
to the mall
to purchase jeans, for example, could select "jeans", either from a list or by
entering "jeans" as
a key word, and receive commercial solicitations from jean stores within the
shopping mall.
The user may also be provided with directions for navigation within the mall
to a selected one
of the jean stores.
[00188] The query 802 may also include additional criteria for identifying
providers,
such as hours of operation, price ranges, and other suitable factors.
[00189] The commercial solicitations 808 may be in the form of
advertisements, special
offers, and the like, and may be stored by the order processing system 392 and
updated
periodically, or alternatively, may be dynamically generated by the order
processing system
392 by requesting commercial data from the local providers 360A, 360B...360n
identified in
response to the query, and then using that commercial data to generate the
commercial
solicitation(s) 808.
[00190] The commercial solicitations 808 may be presented to the user via
the remote
ordering application 350 which, as noted above, may be a separate application
program
installed on the smartphone 310 or may be a page or pages within a web browser
application
on the smartphone 310 or on a desktop computer. The user can then select one
of the
commercial solicitations 808, and send a request 810 to the order processing
system 392
indicating the selection, and the order processing system 392 will then send a
response 812 to
the request. In one embodiment, the response 812 may comprise directions to
the relevant
provider location corresponding to the selection indicated by the request 810.
In another
-77-
CA 02839208 2014-01-15
embodiment, the response 812 may comprise an item list for the relevant
provider (or provider
location), such as item list 354, comprising a list of available items and
corresponding
processing times for each item in the list, so that the ordering methods
described above may
be implemented.
[00191] In some embodiments, the remote ordering application 350 may,
alone or in
combination with systems and software hosted by a provider aggregator 390,
include
functionality which allows it to "learn" certain user preferences and
automatically check for
commercial solicitations 808 corresponding to those user preferences. For
example, the
remote ordering application 350 and/or provider aggregator system may detect
that a user
frequently searches for a particular brand of shoes, and may automatically
begin to check
periodically (e.g. daily) with the relevant providers 360A, 360B...360n for
commercial
solicitations 808 relating to that brand of shoes. When a suitable commercial
solicitation 808
is detected, the remote ordering application 350 can notify the user. Users
can also be
provided with an option to set such periodic checks manually.
[00192] Aspects of the arrangement and method described in respect of
Figure 8 can be
suitably adapted for use with a single provider, rather than provider
aggregator 390.
[00193] Any suitable networked mobile wireless telecommunication computing
device,
such as a smartphone, tablet computer, laptop computer or the like may be used
in accordance
with the systems, methods and computer program products disclosed herein. The
locating
system for the networked mobile wireless telecommunication computing device
may be a
GPS-based locating system, or where appropriate may be a Wi-Fi locating system
or other
suitable locating system.
[00194] Figure 9 shows an exemplary networked mobile wireless
telecommunication
computing device in the form of a smartphone 900. The smartphone 900 includes
a display
902, an input device in the form of keyboard 904 and an onboard computer
system 906. The
display 902 may be a touchscreen display and thereby serve as an additional
input device, or
as an alternative to the keyboard 904. The onboard computer system 906
comprises a central
-78-
CA 02839208 2014-01-15
processing unit (CPU) 910 having one or more processors or microprocessors for
performing
arithmetic calculations and control functions to execute software stored in an
internal memory
912, preferably random access memory (RAM) and/or read only memory (ROM) is
coupled to
additional memory 914 which will typically comprise flash memory, which may be
integrated
into the smartphone 900 or may comprise a removable flash card, or both. The
smartphone
900 also includes a communications interface 916 which allows software and
data to be
transferred between the smartphone 900 and external systems and networks. The
communications interface 916 is coupled to one or more wireless communication
modules
924, which will typically comprise a wireless radio for connecting to one or
more of a cellular
network, a wireless digital network or a Wi-Fi network. The communications
interface 916
will also typically enable a wired connection of the smartphone 900 to an
external computer
system. A microphone 926 and speaker 928 are coupled to the onboard computer
system 906
to support the telephone functions managed by the onboard computer system 906,
and a
location module 922 including GPS receiver hardware is also coupled to the
communications
interface 916 to support navigation operations by the onboard computer system
906. An
imaging device 930 such as a camera is also coupled to the onboard computer
system 906.
Input and output to and from the onboard computer system 906 is administered
by the
input/output (I/O) interface 918, which administers control of the display
902, keyboard 904,
microphone 926 and speaker 928. The onboard computer system 906 may also
include a
separate graphical processing unit (GPU) 920. The various components are
coupled to one
another either directly or by coupling to suitable buses.
[00195] The
exemplary smartphone 900 is merely one example of a networked mobile
wireless telecommunication computing device, and is not intended to be
limiting. Other
examples of networked mobile wireless telecommunication computing devices
include tablet
computers, in-vehicle networked computing devices, among others. The term
"networked
mobile wireless telecommunication computing device" is intended to include
technology
developed subsequent to the filing hereof.
-79-
CA 02839208 2014-01-15
[00196] References to "buttons" herein, including in respect of Figures
15A to 15M and
16A to 16E, refer to touchscreen interface elements which resemble physical
buttons, rather
than to physical buttons.
[00197] The methods described herein may be implemented on any suitable
computer
or microprocessor-based system. An illustrative computer system in respect of
which the
methods herein described may be implemented is presented as a block diagram in
Figure 10.
The illustrative computer system is denoted generally by reference numeral
1000 and includes
a display 1002, input devices in the form of keyboard 1004A and pointing
device 1004B,
computer 1006 and external devices 1008. While pointing device 1004B is
depicted as a
mouse, it will be appreciated that other types of pointing device may also be
used.
[00198] The computer 1006 may contain one or more processors or
microprocessors,
such as a central processing unit (CPU) 1010. The CPU 1010 performs arithmetic
calculations
and control functions to execute software stored in an internal memory 1012,
preferably
random access memory (RAM) and/or read only memory (ROM), and possibly
additional
memory 1014. The additional memory 1014 may include, for example, mass memory
storage,
hard disk drives, optical disk drives (including CD and DVD drives), magnetic
disk drives,
magnetic tape drives (including LTO, DLT, DAT and DCC), flash drives, program
cartridges
and cartridge interfaces such as those found in video game devices, removable
memory chips
such as EPROM or PROM, emerging storage media, such as holographic storage, or
similar
storage media as known in the art. This additional memory 1014 may be
physically internal to
the computer 1006, or external as shown in Figure 20.
[00199] The computer system 1000 may also include other similar means for
allowing
computer programs or other instructions to be loaded. Such means can include,
for example, a
communications interface 1016 which allows software and data to be transferred
between the
computer system 1000 and external systems and networks. Examples of
communications
interface 1016 can include a modem, a network interface such as an Ethernet
card, a wireless
communication interface, or a serial or parallel communications port. Software
and data
transferred via communications interface 1016 are in the form of signals which
can be
-80-
CA 02839208 2014-01-15
electronic, acoustic, electromagnetic, optical or other signals capable of
being received by
communications interface 1016. Multiple interfaces, of course, can be provided
on a single
computer system 1000. The computer system 1000 may further include a location
module
1022 including GPS receiver hardware that is also coupled to the computer
1006.
[00200] Input and output to and from the computer 1006 is administered by
the
input/output (I/O) interface 1018. This I/O interface 1018 administers control
of the display
1002, keyboard 1004A, external devices 1008 and other such components of the
computer
system 1000. The computer 1006 also includes a graphical processing unit (GPU)
1020. The
latter may also be used for computational purposes as an adjunct to, or
instead of, the (CPU)
1010, for mathematical calculations.
[00201] The various components of the computer system 1000 are coupled to
one
another either directly or by coupling to suitable buses.
[00202] The methods described herein may be provided as a computer program
products comprising a tangible computer readable storage medium, such as non-
volatile
memory of the mobile wireless telecommunication computing device or of the
order
processing system of either a provider or a provider aggregator, having
computer readable
program code embodied therewith for executing the method. Thus, the non-
volatile memory
of the mobile wireless telecommunication computing device or order processing
system
would contain instructions which, when executed by the processor of the mobile
wireless
telecommunication computing device or order processing system, cause the
mobile wireless
telecommunication computing device or order processing system to execute the
relevant
method.
[00203] The above systems and methods may be implemented entirely in
hardware,
entirely in software, or by way of a combination of hardware and software. In
a preferred
embodiment, implementation is by way of software, which includes but is not
limited to
firmware, resident software, microcode, and the like. Furthermore, the above
systems and
methods may be implemented in the form of a computer program product
accessible from a
-81-
CA 02839208 2014-01-15
computer usable or computer readable medium providing program code for use by
or in
connection with a computer or any instruction execution system. In such
embodiments, the
computer program product may reside on a computer usable or computer readable
medium in
a computer such as the memory 912 of the onboard computer system 906 of the
smartphone
900 or the memory 1012 of the computer 1006, or on a computer usable or
computer readable
medium external to the onboard computer system 906 of the smartphone 900 or
the computer
1006, or on any combination thereof.
[00204] One
or more currently preferred embodiments have been described by way of
example. It will be apparent to persons skilled in the art that a number of
variations and
modifications can be made without departing from the scope of the claims. In
construing the
claims, it is to be understood that the use of a computer to implement the
embodiments
described herein is essential.
-82-
