Patent Description:
Couriers retrieve and deliver items from a source to a destination. As large courier management systems allow a much greater number of orders and on-demand courier services, often from novice couriers, courier management systems may need to determine and verify when a courier for an order has reached the source of the item to complete pick up of the item. Couriers at the source point may report the pickup to the courier management system, but this can be unreliable. <CIT> proposes systems and methods for delivery confirmation using wireless beacons. A merchant may include a wireless beacon, such as a small token or device, inside of a package for delivery. The beacon may communicate with a user device for a user when the package is delivered to the user. The beacon may include recipient information of eligible recipients for the package. The beacon may receive identification information for the user when the user device connects to the beacon. A delivery person in possession of the package may then determine if the user is an eligible recipient for the package using the recipient information and the identification information. After delivery of the package, the user may reuse the beacon by erasing the recipient information from the beacon and storing new recipient information on the beacon. The user may then place the beacon in another package for delivery. <CIT> proposes the use of Bluetooth beacons for enhancing delivery tracking. A Bluetooth beacon may be carried by a delivery agent. An ID of the beacon may be detected by one or more sensors. Tracking of the delivery agent may be performed by determining where the ID is detected.

According to a first aspect of the present invention, there is provided a computerimplemented method as set out in claim <NUM>. According to a second aspect of the present invention, there is provided a computer readable storage medium as set out in claim <NUM>. According to a third aspect of the present invention, there is provided a computer program product as set out in claim <NUM>. A network system (e.g., a courier or delivery management system) coordinates the delivery of requested items from a source location to a delivery location. A requesting user of the courier management system, such as a customer placing an order for a product or merchandise to be delivered, may submit an order request by providing input on a requesting device. The requesting user selects one or more items to request of a plurality of items presented by the courier management system and may optionally input a delivery location. The courier management system is configured to receive order requests from a requesting device. The request includes an identifier associated with an item provider of the requested item(s), a list of identifiers/tags associated with the requested item(s), and/or a delivery location for the requested items. The courier management system creates an order entry by selecting a source location that can provide the requested items (e.g., based on the identifier associated with the item provider) and selecting a service provider (e.g., a courier, a driver) that can retrieve the requested items from the source location and deliver the requested items to the delivery location. The order entry includes identifiers (IDs) corresponding to devices, individuals, or entities associated with the selected source location and/or the selected courier.

An example of a courier management system is a food delivery system that coordinates drivers to deliver food from third party restaurants to requesting users. In this example system, a requesting user, Bob, might order a pizza from Joe's Pizza Palace using his smartphone, the requesting device. In this example, the food delivery system would transmit data to a source device associated with and located at Joe's Pizza Palace to notify Joe's Pizza Palace to begin preparing the requested pizza. The food delivery system can select a driver that is located in the vicinity of Joe's Pizza Palace (e.g., having a current location within a predetermined distance of the location of Joe's Pizza Palace) to pick up the pizza ordered by Bob from Joe's Pizza Palace. The food delivery system provides the location of the requesting user to the driver so that the pizza can be delivered to Bob.

According to some examples, a service provider device (e.g., courier device) receives order information from the courier management system including at least a source ID and an order ID for the order. The courier device can enter into a beacon detection mode to detect a short range radio frequency beacon broadcasted by the source device. The source beacon includes the source ID of the source and the order ID corresponding to the order entry. Upon detecting the source beacon, the courier device compares the source ID and/or the order ID from the detected beacon to the source ID and/or order ID included in the order information received from the courier management system. If the source IDs and/or the order IDs match, the courier device reports to the courier management system that it is in proximity to the source device.

In some embodiments, the courier device may begin broadcasting its own beacon signal including a courier ID and the order ID (e.g., in a beacon broadcasting mode). The source device may then detect the courier beacon and match the courier ID to a courier ID from the order information received from the courier management system. If a match is detected, the source device sends data (e.g., data corresponding to a report) confirming the presence of the courier device in proximity to the source device to the courier management system. The courier management system may utilize the presence verification and timing of the received data to improved estimated completion or delivery times for requesting users, compensate couriers for waiting times, and/or improve pick up efficiency at source locations by obviating manual confirmation of a pick up by the courier.

One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

<FIG> shows an example environment for verifying courier proximity to an order pickup location, according to some embodiments. According to an example, there are typically three types of users of a courier management system <NUM>: requesting users, source users, and courier users.

A requesting user may request items available for ordering from the courier management system <NUM> using the requesting device <NUM>. In some embodiments, a client application of the courier management system <NUM> on the requesting device <NUM> displays a graphical user interface (GUI) for requesting items. For example, the GUI may display icons representing a variety of food establishments and, upon receiving a user selection of one of the icons, the GUI may display various food items available at the selected establishment. The courier management system <NUM> receives data corresponding to the requested items from the requesting device <NUM> and generates an order entry comprising the data (e.g., IDs) of the requested items. Referring to the example above, requesting user, Bob, my select a pepperoni pizza from Joe's Pizza Palace. In this case, the requesting device <NUM> would send data corresponding to the selected pepperoni pizza from Joe's Pizza Palace to the courier management system <NUM>. The courier management system would then create an order entry representing the requested pepperoni pizza.

Source users use source devices <NUM> to receive orders, and information associated with the order entries (e.g., which items, quantity, special requests, requested time, etc.), from the courier management system <NUM>. Each source device <NUM> is registered with the courier management system <NUM> and each source device <NUM> is associated with a particular source location capable of providing particular items that are available to requesting users. The source data (e.g., source device and source location, as well as other source related information) can be stored in a database accessible by the courier management system <NUM>. After receiving data for an order from the courier management system <NUM> via the source device <NUM>, a source user may prepare the items requested in the order at the corresponding source location.

Referring to the previous example, Joe's Pizza Palace has a source device <NUM> for an employee to use in order to interact with the courier management system <NUM>. The source device <NUM> may receive the order for the pepperoni pizza from the courier management system <NUM> and may then display the order and any additional information associated with the order, such as identifying information of a courier that will be picking up the order. Employees at Joe's Pizza Palace may then prepare the order based on the displayed information on the source device.

Courier users can be assigned to pick up and deliver items for orders for requesting users and receive information associated with the orders from the courier management system <NUM> via the courier device <NUM> (e.g., such as information indicating the items that must be picked up and delivered to the requesting user, the locations for pick-up and delivery, the time to go to the pick-up location, etc.). In some embodiments, couriers may not be strictly couriers and may instead be service providers who may provide any number of different services.

Referring again to the previous example, the courier management system <NUM> may select a courier to deliver the pepperoni pizza from Joe's Pizza Palace to the location of the requesting user. The courier management system <NUM> may send the location of the Joe's Pizza Palace, a list of items to be delivered, and a location of the requesting user the a courier device <NUM> associated with the user so that the delivery can be made.

In an example embodiment, the courier management system <NUM> is a system for arranging the delivery of food orders. In this case, the requesting user can submit a request for a food item from a restaurant in the area, for example, by generating the request using inputs to select one or more items on a dedicated application on a requesting device <NUM>. The courier management system <NUM>, remote from both the restaurant and the requesting user, can create an order (e.g., a record or entry corresponding to the order) for the food item, store the record in a database (e.g., along with data associated with the requested item, the restaurant, the requesting user identifier, etc.), and send order information to a source device <NUM> located at the restaurant. The courier management system <NUM> can also select, from a pool of service providers, a service provider to provide the delivery service (e.g., pick up the order and deliver it to the requesting user) and transmit information about the order to a courier device <NUM> of the selected service provider or courier. In some examples, each source location is associated with a source device <NUM> with which to communicate with the courier management system <NUM> over one or more networks. The source user at the restaurant can prepare the food items corresponding to the order (e.g., the pizza) per the received order instructions and wait for the courier to pick up the pizza upon its completion. The courier can confirm pick up of the food item and deliver, using navigation instructions, to the requesting device <NUM> or a delivery location specified by the requesting user to deliver the food item.

In addition to communicating with source users, courier users, and requesting users to arrange for the delivery of items from the source locations to the requesting users, according to some examples, the courier management system <NUM> uses short range radio transmissions between the devices to verify the position, location, and/or movement of a courier device <NUM> and determine additional data, which may be used to improve estimated times of arrival, provide incentives for couriers, and/or improve courier adherence to instructions provided by the courier management system <NUM>.

The requesting device <NUM> provides an interface, via a client application for example, for an end user to request items made available by the courier management system <NUM> via an order request module <NUM>. The requesting device <NUM> may be any suitable computing device that can display items available for request and an interface for the end user to select those items (e.g., via an input mechanism, such as a touch sensitive display). The client application can receive data from the courier management system <NUM> about the various sources and/or items that a requesting user can order (e.g., based on a time, the delivery location or current location of the requesting user, and/or the source locations), and the request module <NUM> can generate and present (for example, in conjunction with a user interface module, not illustrated in <FIG> for purposes of simplicity) a user interface that includes a set of selectable features or graphic images representing sources (e.g., restaurants, stores, etc.) and/or a set of selectable features representing items that a requesting user can order. The request module <NUM> determines, via an input detected or received from the user, data indicating one or more requested items and sends a set of identifiers of the requested items (and/or an identifier of the source that provides the requested items) to the courier management system <NUM> over one or more networks <NUM> as a request to the courier management system <NUM>. The location of the requesting device <NUM> may be sent as part of the request to the courier management system <NUM> and may also be used as a delivery location for the order. Additionally or alternatively, the user may also provide a delivery address.

The courier management system <NUM> receives requests for items from a requesting device <NUM> and coordinates preparation of the order by a source location, as well as pickup and delivery of the contents of the order by a courier operating the courier device <NUM>. In one example, the courier management system <NUM> includes an order creation module <NUM>, a courier selection module <NUM>, and a courier order verification module <NUM>. In addition, the courier management system <NUM> has one or more data stores, such as an order data store <NUM>, a source location data store <NUM>, and a courier data store <NUM>, for example. The courier management system <NUM> may arrange courier services for many different types of orders depending on its configuration. Referring back to the pizza example, the source would be a restaurant and the order would specify the particular pizza from the menu of the restaurant which a courier would then retrieve and deliver. Another example is the delivery of items such as store-bought products by a user, or items that are to be delivered from one location to another, such as packages, court documents, etc. The courier management system <NUM> thus may include many additional components, which for purposes of simplicity are not illustrated in <FIG>, that assist in the order process. For example, the courier management system <NUM> may also perform a selection of a specific courier for delivery of a particular order (e.g., based on the status of the courier and/or the location of the courier, the location of the restaurant or store, the location of the destination, etc.), and may provide payment, order selection, and other services for the users associated with the requesting device <NUM>, the source device <NUM>, and/or the courier device <NUM>.

Upon receiving a request for one or more items from requesting device <NUM>, the courier management system <NUM> creates an order entry corresponding the requested items using the order creation module <NUM>. For example, the order creation module <NUM> can create and store an entry in the order data table or store <NUM>. The order creation module <NUM> generates a unique order ID for the new order (e.g., random string for the ID) and lists the items (e.g., as identifiers or text) corresponding to the order along with a delivery location, which may be an address or GPS location provided in the request.

In one example, the order creation module <NUM> then selects a source and/or source location for the order. For systems where the source location for the requested items is included in the request, the order creation module <NUM> looks up the corresponding source ID from the source location data store <NUM> and adds the source ID to the order entry. As an addition or an alternative, in some examples, the request can include the source ID along with the IDs or names of the items. In such an example, the order creation module <NUM> can identify the source and the source location using the source ID. In systems where the source location or source ID is not included in the request, the order creation module <NUM> uses the source location data <NUM> to determine which source locations can provide the requested items.

After determining the source ID for the order entry, the order creation module <NUM> provides request data including the source location and delivery location to the courier selection module <NUM> to cause the courier selection module <NUM> to select a courier associated with a courier device <NUM> to deliver the requested items from the source location to the delivery location. Depending on the embodiment, the courier selection module <NUM> may select a courier based on a number of factors, including the address or GPS location of the source location (e.g., the GPS location), the GPS location of requesting device or the specified delivery location, and the location of the courier device; the current location or route of the courier; the distance of the courier to the source location; and/or the estimated travel time from the location of the courier device to the source location and then to the location of the requesting device. The courier management system <NUM> monitors the above listed factors by periodically communicating with and/or receiving updates of the courier data to reflect changes in courier positions, routes, states, etc. In some embodiments, the courier selection module <NUM> may select a courier for the order entry and then send data corresponding to an invitation to provide the delivery service to the courier device <NUM>. The courier may then choose to confirm or deny the invitation, e.g., by providing user input. If the invitation is denied, the courier selection module <NUM> selects a different courier to complete the order. If the invitation is accepted, the courier selection module <NUM> updates the order entry with the selected courier ID and/or stores other information or associates the order entry with other information, such as the location of the courier when accepted, the route the courier is taking, etc. In addition, once the courier selection module <NUM> has successfully arranged a delivery for the order, information about the selected courier is provided to the requesting device <NUM> and/or the source device <NUM>.

Accordingly, in some examples, the completed order entry includes a unique order ID, a source ID, a courier ID, a requesting user ID, a set of data corresponding to the requested item(s), and/or a delivery location. The order entry can also include or be associated with other information, such as time of request, time of order preparation completion, time of pick up, estimated time of arrival to delivery, route driven or taken by the courier, duration of time from pick up to delivery, etc. An order entry may also include an indication of the status of the order (e.g. whether the order is "being processed," "being prepared," "being picked-up," "en route," "delivered," etc.).

After the order creation module <NUM> creates the order entry for the requested items, the courier order verification module <NUM> sends data corresponding to the order entry (e.g., information or identifiers of the items requested by the user of the requesting device <NUM>) to the source device <NUM> and/or the courier device <NUM>. Each order entry sent to source devices <NUM> and/or courier devices <NUM> may be synchronized (e.g. periodically and/or responsive to a change to the order entry in the order data store <NUM>) with the order entry stored at the order data store <NUM>. The source devices <NUM> and courier devices <NUM> may maintain order entry data for "active orders. " An active order is an order that has been placed on the courier management system <NUM> that has not yet been delivered to the delivery location. In some embodiments, an order entry may remain stored in the order data store <NUM> after it has been delivered (e.g. to record feedback on the order in association with the order entry). In some embodiments, data associated with inactive orders are cleared from courier devices <NUM> and source devices <NUM>. Each source device <NUM> and each courier device <NUM> may manage more than one active order at a particular time. When the status of an order changes the source devices <NUM> and courier devices <NUM> may be updated with the new status of the order. Additionally, the status of the order may cause changes in behavior of the source devices <NUM> and courier devices <NUM>, as explained below.

According to one example, after order data is sent to a source device <NUM> and/or a courier device <NUM>, each device receiving the order information creates an active order corresponding to the order information. The source device <NUM> may then broadcast (e.g., based on the status of the order etc.) a beacon <NUM> including an identifier for the order and/or an identifier of the source device <NUM>. As described herein, a beacon refers to a short-range wireless radio frequency signal that may be used to determine the proximity of one device to another as well as send identifying or other data from one device to another. In some embodiments, proximity may be calculated by detecting the signal strength of the beacon (e.g. signal-to-noise ratio). By broadcasting a source beacon <NUM>, the source device <NUM> enables courier devices <NUM> to determine their relative location to the source device <NUM>. This may aid in the pickup and delivery process of satisfying an order from a requesting user and provide, through event reporting processes described below, useful positioning and performance data to the courier management system <NUM>.

The source device <NUM> may broadcast a source beacon <NUM> for a particular order when the status of that order indicates that the requested items have not yet been obtained, by the courier, from the source location. For example, the source device <NUM> may be instructed to broadcast a source beacon <NUM> for a particular order when the status of that order indicates that the requested items of the order are "ready for pickup. " In this manner, the source device <NUM> can be instructed to broadcast a source beacon <NUM> during any identified stage in the order process. By selectively broadcasting the source beacon <NUM>, the source device <NUM> may reduce the number of beacons being broadcasted at a given time while still providing location information to nearby courier devices <NUM> that have been designated to retrieve requested items.

When a courier device <NUM> comes within range of the source device <NUM>, the courier device <NUM> can detect the source beacon <NUM> and the identifier(s) included in the source beacon <NUM>. The courier device <NUM> may then determine whether the order ID included in the source beacon <NUM> matches an order ID associated with any active orders of the courier (e.g., associated with the courier's account or the courier device <NUM>). If the order ID included in the source beacon matches any order IDs associated with the courier device's active orders the courier device <NUM> reports the event of detecting the source beacon <NUM> (e.g., transmits data about the event) to the courier management system <NUM>. In some embodiments, upon receiving the reported event, the courier management system <NUM> may change the status of the order or may record the timing of the event for later processing.

In one example, the courier device <NUM> may also broadcast a courier beacon <NUM> in return to the source device <NUM> after receiving the source beacon <NUM> (e.g., as a confirmation of detecting the source beacon <NUM>). In one example, the source device <NUM> reports receipt of the courier beacon <NUM> to the courier management system <NUM>. As an alternative example, the courier device <NUM> can broadcast the source beacon <NUM> and the source device <NUM> can detect or receive the source beacon <NUM>. For example, the courier device <NUM> can be triggered to broadcast the source beacon <NUM> in response to the courier device <NUM> and/or the courier management system <NUM> determining that the courier device <NUM> is within a predetermined distance of the location of the source device <NUM> or the source location. The courier device <NUM> and/or the courier management system <NUM> can periodically determine the current location of the courier device <NUM> using the location-based resource(s) of the courier device (e.g., a global positioning system (GPS) receiver, Wi-Fi transceiver, etc.) and compare it with the location of the source device <NUM> (or the address of the store, restaurant, venue, etc. where the source device <NUM> is located).

According to some examples, by having each device report receipt of specific beacons, the courier management system <NUM> can verify that the courier device <NUM> was actually in range of the source device <NUM> or vice versa (e.g., to prevent fraud or spoofing of the respective beacons). As an additional benefit, the courier device <NUM> may wait to broadcast its courier beacon until after receiving the source beacon <NUM>, as the energy cost of detecting beacons may be much lower than the cost of broadcasting a beacon. As the courier device <NUM> may typically be moving and less reliably connected to a power source, this conserves power on the courier device <NUM> until the broadcast is expected to be received by the appropriate source device (e.g., until after the courier device <NUM> receives the desired source beacon <NUM> and is therefore in range of the source device <NUM>). In addition, the transmission of a beacon may be limited to broadcasting a single message or identifier on the channel at once. To handle more than one active order, the appropriate beacon for each order may be added to a list of active orders and each active order may be sequentially transmitted for a brief time, such that the currently broadcast order rotates through the active orders. For example, if there are three different orders, the source device <NUM> can transmit a first beacon for the first order, a second beacon for the second order, a third beacon for the third order, and continue to repeat the transmission sequence periodically until one of the beacons is detected by the courier device <NUM> or until the source device <NUM> receives a confirmation beacon for the respective beacon from the courier device <NUM>.

The courier order verification module <NUM> receives data about beacon detection events (e.g., including time information and/or locations of the devices when the beacon detection event occurred) from the source device <NUM> and/or the courier device <NUM> and determines whether the courier device <NUM> and the source device <NUM> were proximate to one another. This data may be used, for example, to verify that the order was picked up by the correct courier, or that the courier picked the item up in a way that brought the two devices in near proximity to one another. As a further example, couriers may be required by a policy of the courier management system <NUM> to enter the source location to retrieve the order. If the order is picked up (e.g., the respective user of the source device <NUM> and/or the courier device <NUM> provides input indicating pick up was completed), but the courier did not enter the source location (e.g., did not enter the building), the courier order verification module <NUM> may be able to determine that the courier did not follow the policy because no event was received indicating the devices were in proximity to one another. In another example, the beacon detection events can be used to determine how long the courier had to wait at the source location once he/she entered in order to receive the physical order from the source location and/or determine the delay by the source in preparing the order for pick up (e.g., based on an estimated time of preparation).

In some examples, the courier order verification module <NUM> provides the order information to each of the courier device <NUM> and source device <NUM>. As discussed below, in some examples, the source device <NUM> may broadcast a source beacon <NUM> that is received by the courier device <NUM>. The courier device <NUM> reports the receipt of the source beacon <NUM> via a beacon detection event. The courier device <NUM> may also broadcast a courier beacon <NUM>, which when received by the source device <NUM>, is reported in another beacon detection event. When the courier order verification module <NUM> receives data about the detection events, the courier order verification module <NUM> can determine that the two devices were actually proximate to one another and verify that the order was picked up. This may also permit the courier order verification module <NUM> to limit interactions on the source device <NUM> or on the courier device <NUM>, for example, by obviating manual confirmation that an order was picked up by either the source user or the courier using the source device <NUM> or the courier device <NUM>, respectively.

According to an example, the courier order verification module <NUM> sends the source ID and/or courier ID to the source device <NUM> and the courier device <NUM> for broadcasting the source beacon <NUM> and courier beacon <NUM>, respectively. In some embodiments, the courier order verification module <NUM> may also instruct the source device <NUM> and the courier device <NUM> to start and/or stop broadcasting a beacon for the order. For example, when the courier device <NUM> broadcasts a courier beacon <NUM> in response to detecting the source beacon <NUM>, the courier order verification module <NUM> may instruct the courier device <NUM> to stop broadcasting the courier beacon <NUM> when the courier management system <NUM> receives the associated beacon verification event from the source device <NUM>. This can result in power savings on one or both devices.

In one variation, the courier order verification module <NUM> may also use data about detection events to determine how long a courier waits at the source location, and thus may be used to determine wait times of the courier, for example, to provide compensation to the courier for the delay, or to better estimate the delay of a pick up at the source location (e.g., based on an average of a plurality of wait times by a plurality of couriers at the source location). Additionally, the expected wait time at the source location may be used to automatically determine how long a courier is expected to wait and better predict and/or schedule the time of selecting a courier and/or the arrival of a courier at the destination of the order. The courier management system <NUM> may also provide mapping and navigation services, in which case the amount of time that a courier <NUM> is delayed at the order pickup location may be used to better predict courier routing, provide an estimated delay, and further improve courier routing, travel coordination, and other features provided by the courier management system <NUM>. In this example, the length of time that couriers are at the source location may be determined by receiving events when the nearby beacons received at the courier device <NUM> change, such that the courier device <NUM> reports when it exits the range of the source device <NUM>. The wait time for one order may be combined with the wait times of other orders to determine the average wait, a distribution of wait times, and/or other characteristics of the wait times for a particular source for use in determining routing, travel estimates, and/or delivery times to the arrival as noted above.

Updates for the order may also be provided to the order request module <NUM> of the requesting device <NUM> associated with the order. For example, when an order is verified as picked up by the courier order verification module <NUM>, the courier verification module <NUM> may provide a notification to the order request module <NUM> to update the user interface, e.g., via the client application, and indicate that the order has been picked up by the selected courier, and may update estimated travel and delivery times based on the average wait time of a courier at the source location, or may update the delivery time when the courier device <NUM> no longer receives (or receives at a lower strength) beacons broadcast by the source device <NUM>.

The source device <NUM> provides an interface (e.g., via a client application or web page on a browser) to an operator at the source to interact with the courier management system <NUM>, and broadcasts a beacon for the courier device <NUM>. The source device <NUM> may be any suitable computing device, such as a desktop or laptop computer, a point-of-sale terminal with suitable features, a mobile device, a smartphone, a tablet computer, and so forth. In one example, the source device <NUM> can be a tablet device that is coupled to or communicates with the merchant's point-of-sale terminal, while in another example, the source device <NUM> can correspond to the point-of-sale terminal. The source device <NUM> includes order data <NUM> including order data of orders provided by the source, as well as an order pickup module <NUM>. The source device <NUM> also includes a short range transceiver <NUM> for broadcasting and receiving beacons. The short range transceiver <NUM> transmits a source beacon <NUM> according to instructions from the order pickup module <NUM> and may receive a courier beacon <NUM> from the courier device <NUM>.

The short range transceiver <NUM> may take various forms according to different embodiments. In general, the short range transceiver <NUM> emits a low-power, low-range signal that may be detected by other nearby devices, such as, for example, the courier device <NUM>. In one embodiment, the short range transceiver is a radio transceiver, and the beacon source <NUM> is transmitted via a Bluetooth broadcast or Bluetooth Low Energy (BLE) broadcast. In a particular embodiment, the beacon may be transmitted using Bluetooth technologies and/or protocols that provide received signal strength ranging and/or identification information, which identifies the broadcasting device may be used. In an embodiment, the beacon broadcast includes a unique identifier associated with the broadcaster, and may specify a major and a minor value. The unique identifier (e.g., a UUID) can be associated with the courier management system <NUM> and may be common among all source and courier devices interacting with the courier management system <NUM>. In this example, the major value represents the individual broadcasting device, such as the source device ID or the courier device ID, while the minor value is an identifier of the order. The courier order verification system <NUM> may provide these identifiers for an order to the source device <NUM> and the courier device <NUM>. The minor value for broadcasting of the order may represent a hash value or other means of converting an order to a range of possible values for the broadcast. For example, the major and minor values each have a range between <NUM> and <NUM>, and the courier management system <NUM> determines near-unique values for an expected interaction between courier device <NUM> and source device <NUM>. For example, the major value may be adjusted such that each source and courier device in a nearby location has a distinct major value.

A similar transceiver is also provided on the courier device <NUM> as a short range transceiver <NUM>. The transceiver may also use different amounts of power when broadcasting compared to when transmitting. As discussed below, in one example, the transceiver on the courier device <NUM> may maintain operation as a receiver only (to detect a source beacon <NUM>). Additionally, the courier device <NUM> may broadcast a courier beacon <NUM> to the source device <NUM> upon receiving a source beacon <NUM> from the source device <NUM>.

When receiving or detecting a beacon, both the source device <NUM> and the courier device <NUM> may parse the broadcast beacon to identify the order identifier or the source or courier identifier (e.g., the major value and minor value). In addition, the transceiver of either the courier device <NUM> or the source device <NUM> (or in conjunction with other device resources of the courier device <NUM> or the source device <NUM>) may determine the signal strength of the beacon, and use the received signal strength to an estimated proximity or distance of the sending device (e.g., converting the received signal strength). In some implementations, the estimated proximity is reported directly as a distance measurement. In other embodiments, the estimated proximity may be reported qualitatively as a proximity classification, for example, as "far," "near," or "immediate" to the receiving device. Each proximity classification may correspond to a range of estimated distances depending on the implementation of the short range transceiver <NUM>. For example, a proximity of <NUM> meters or more may be reported as "far", between <NUM> and <NUM> meters as "near", and within <NUM> meter as "immediate". Therefore, the received signal strength of the broadcast signal may be converted to an estimated distance before being assigned a proximity classification as a proximity estimate and reported to the courier management system.

The short range transceiver <NUM> may also be capable of transmitting a single beacon at any given time. The order pickup module <NUM> receives orders from the courier management system <NUM> and instructs the short range transceiver <NUM> in the broadcast and detection of beacons. When the order pickup module <NUM> receives an order from the courier management system <NUM>, the order pickup module <NUM> may provide the new order on a user interface for display, for example, for an operator at the source to begin preparing the items in the order for pickup. The order pickup module <NUM> may also add the order to a data store of order data <NUM>. In one example, the order data <NUM> maintains a list of currently active orders. As referred to herein, the active orders are the orders which have not been picked up by a courier, and which the source device <NUM> will broadcast for a courier device <NUM> to identify.

To identify the source device <NUM>, the order pickup module <NUM> controls the short range transceiver <NUM> to broadcast active orders with a source beacon <NUM>. In one example, the source beacon includes a source identifier and an order identifier. In such an implementation, these may correspond to the major and minor values of the beacon, respectively. The order pickup module <NUM> identifies the active orders in the order data <NUM> and broadcasts the active orders via the short range transceiver <NUM> to provide the source beacon <NUM> to devices that are near to the source device <NUM>. When a device is near to the source device, such as the courier device <NUM> assigned to one of the active orders, the device may receive and detect the broadcast source beacon <NUM> and identify the values within the source beacon <NUM>. In embodiments where the short range transceiver is capable of transmitting a single source beacon <NUM>, the order pickup module <NUM> may modify the default behavior of the short range transceiver <NUM> to cycle the broadcast of active orders. That is, among the set of active orders, each active order may be broadcast for a limited amount of time and then another order from the set of active orders is selected for broadcast, until each of the active orders has been broadcast, and then the first order may be broadcast again. As active orders are added or removed to the list of active orders, the orders cycled by the order pickup module <NUM> for broadcast (and the associated beacons) may also change. In this way, a given source device <NUM> may broadcast a consistent source ID (e.g., as a major value) and may modify the broadcast order ID as the active orders are cycled. Each active order may be broadcast for a specified amount of time, such as one tenth of a second (or a complete second, or other specified time), or the amount of time for cycling the orders may vary, such as according to the number of active orders. For example, the entire set of active orders may be set to cycle within a specified amount of cycle time, such as thirty or sixty seconds. Each order may receive a proportional amount of that cycle time, for example when there are six active orders, each may be broadcast for ten seconds of a sixty-second cycle time. In this way, according to an example, the courier device <NUM> that receives any broadcast having an expected source ID may wait for the predetermined full cycle time to verify whether the source device <NUM> is transmitting an active order desired by the courier device <NUM>.

The order pickup module <NUM> may also monitor received courier beacons <NUM> from the short-range transceiver <NUM>. When a courier beacon <NUM> is received, the order pickup module <NUM> identifies whether the received courier beacon <NUM> matches an active order of the source device <NUM> and identifies a match in the order data <NUM>. When there is a match, the order pickup module <NUM> may send a notification to the courier management system <NUM> to indicate the receipt of a courier beacon <NUM> and verify the courier is nearby. In some embodiments, the order pickup module <NUM> sends updates to the courier management system <NUM> as the estimated proximity of the courier device changes. For example, when the proximity of a device matching an order changes to "near" from "far" or from "near" to "immediate. " In some examples, the source device <NUM> does not send the event until the received courier beacon <NUM> that matches an active order is closer to the source device <NUM> than a threshold, for example by not notifying the courier management system <NUM> until the courier beacon is an estimated "near" proximity. After receiving the courier beacon <NUM> (or receiving it at a given estimated proximity), the source device <NUM> may remove the related order from the list of active orders. Alternatively, the source device <NUM> may report the received courier beacon <NUM> but maintain the order in its list of broadcast active orders until receiving a message from the courier management system <NUM> to stop broadcasting.

The courier device <NUM> also receives order data from the courier management system <NUM> and receives and/or broadcasts beacons to verify proximity of the source device <NUM> with the courier device <NUM>. Like the source device <NUM>, the courier device <NUM> can be any suitable computing system, such as a mobile device. As with the source device <NUM>, the courier device <NUM> receives and stores order data <NUM>, and a courier order module <NUM> may receive and coordinate orders from the courier management system <NUM>. The short range transceiver <NUM> is also capable of receiving the source beacon <NUM> and may also be used to broadcast a courier beacon <NUM>.

When the courier device <NUM> has one or more active orders, the courier order module <NUM> instructs the short range transceiver <NUM> to listen for any source beacons <NUM> having a source identifier and order identifier associated with any active orders. In this example, the courier order module <NUM> may instruct the short range transceiver <NUM> to operate in a beacon detection mode to detect beacons, and does not broadcast a courier beacon <NUM> until an appropriate source beacon <NUM> for an active order is received. In this example, the courier order module <NUM> may reduce the power consumption of the short range transceiver by avoiding broadcast until the courier device <NUM> detects the relevant source device <NUM>. As an addition or an alternative, in some embodiments, the courier order module <NUM> does not detect beacons using the short range transceiver <NUM> until other data (e.g., GPS data) indicates that the courier device <NUM> is close to the source device <NUM>. For example, the location of the courier device <NUM> may be otherwise monitored, and the courier order module <NUM> may not activate the short range transceiver <NUM> to detect source beacons until the location of the courier device is within a threshold distance from the source location, or a geofence or other location area of the expected location of the source device <NUM>. The location area and determination thereof may be performed by the courier management system <NUM> or may be performed by the courier device <NUM>. In a particular embodiment, the courier device <NUM> is equipped with a GPS receiver and reports its GPS location to the courier management system <NUM>. The courier management system <NUM> may then notify the courier device <NUM> that it is currently located within a geofence associated with a source corresponding to one of the active orders in the order date <NUM> of the courier device <NUM>.

When the courier order module <NUM> receives a source beacon <NUM> matching order data <NUM>, the courier order module <NUM> determines the received signal strength of the received source beacon and calculates a proximity estimate based on the received signal strength. The courier order module <NUM> reports the match to the courier management system <NUM> and optionally includes the calculated proximity estimate. As with the source device <NUM>, the courier order module <NUM> may continuously detect (e.g., periodically sample at a predetermined rate) the source beacon <NUM> and recalculate the proximity estimate based on changes in the received signal strength of the beacon. If the proximity estimate changes between samples, the courier order module <NUM> may send an update of the estimated proximity of the source device <NUM> to the courier management system <NUM> as a beacon detection event. In some embodiments, a change in the proximity estimate is reported to the courier management system only when the proximity estimate changes from one proximity classification to another.

In addition, in one example, when the courier device <NUM> receives a beacon having a source identifier and/or an order identifier matching the order data <NUM>, the courier device <NUM> may begin to broadcast a courier beacon <NUM> for the courier. The courier beacon <NUM> may include the courier identifier as well as the order identifier for receipt by the source device <NUM>. The courier beacon <NUM> may be broadcast when the source device <NUM> is identified, or may be broadcast when the estimated proximity of the source beacon is relatively closer to the courier device <NUM> (e.g., "near" or "immediate"). In this way, broadcast of the courier beacon <NUM> may be limited to circumstances when the source device <NUM> is expected to receive it and reduce the comparatively energy expensive broadcasting of the courier beacon <NUM>.

The various devices may also communicate with one another using a network <NUM>, which may represent the public Internet, or another type of communication channel. In general, each device may connect to the network using various means, such as a wired or wireless connection (cellular, LAN, WAN, etc.). Though the source device <NUM> and courier device <NUM> may communicate via the network <NUM> to the courier management system <NUM>, and potentially with each other, via the network <NUM>, these systems typically are not configured to permit estimated proximity information as may be provided by the beacons as described herein.

<FIG> shows example interactions between the requesting device <NUM>, the courier management system <NUM>, the source device <NUM>, and the courier device <NUM>, according to some embodiments. The requesting device <NUM> receives <NUM> input from the requesting user regarding requested items and optionally an input indicating a desired delivery location. The requesting device then sends <NUM> the list of requested items and a delivery location to the courier management system <NUM>. In some embodiments, the delivery location is reported automatically as the GPS location of the requesting device <NUM>. The courier management system <NUM> generates <NUM> a new order entry. To generate <NUM> the order entry, the courier management system <NUM> may satisfy the received request by selecting a particular source location that can provide the requested item. For example, if the user requests a pizza from a particular restaurant the courier management system <NUM> would generate the order such that the requested restaurant is selected as the source location. The source device <NUM> would already be located at the pizza restaurant and associated in the courier management system <NUM> with the source location. Upon selecting the source location and corresponding source device <NUM> the courier management system <NUM> may select a courier with courier device <NUM> that is available to pick up the requested item. Upon selection of a source location and courier a new order is generated 203at the courier management system <NUM>, and the courier management system <NUM> sends <NUM> the new order information to the courier device <NUM> and the source device <NUM>. The order information includes the identifiers associated with the order including the order ID, the courier ID, and/or the source ID. Order information may be sent to the courier device <NUM> and the source device <NUM> over network <NUM> In courier systems where the courier immediately delivers the retrieved item to a requesting user, the order information may also include identifying information for the requesting user. The order information may also include additional details associated with the order such as the order instructions (e.g. order description, order instructions, a pick-up time for the order, etc.), courier descriptive information (e.g. a picture identifying the courier, the courier's name, courier vehicle, etc.), and pickup instructions for the courier (e.g. steps for picking up the order at the source location, parking regulations outside of the source location, etc.). Alternatively, these details may be retrieved from the courier management system <NUM> by either source device <NUM> and/or courier device <NUM> as needed using the order ID, source ID, or the courier ID.

After receiving the order information including the order ID and source ID, courier device <NUM> begins to operate in beacon detection mode <NUM> to listen for a source beacon <NUM> that includes an order ID and a source ID that matches the received order information stored in order data <NUM>. In parallel, the source device <NUM> adds <NUM> the received order to the broadcast of the source device <NUM>. The source device <NUM> broadcasts its source ID and the order IDs corresponding to the active orders in order data <NUM> using source beacons <NUM>. When added, the newly-received order may be added to the broadcast beacons. The broadcast source beacons thus may include the newly-received order, and may include broadcasting additional active orders and including the new order as one of the orders in a broadcast cycle of orders.

Initially, the courier device <NUM> is typically not within range of the source device <NUM> to receive a beacon (e.g., the courier operating the courier device <NUM> may be in a different geographic region and traveling to the merchant or location of the source device <NUM>). As the courier approaches the source or merchant, the courier device <NUM> detects/receives beacons that are broadcasted from the source device <NUM> and checks the orders against active orders at the courier device <NUM> to determine whether there is a match. When the source ID and the order ID of a received beacon matches <NUM> an active order, the courier device <NUM> sends <NUM> a courier verification to the courier management system <NUM> to verify that the courier device <NUM> has come within range or has entered the vicinity (e.g., has come within a predetermined distance) of the source device <NUM>. This verification may be sent as a beacon detection event by the courier device <NUM>. In some embodiments, the process may end here, such that the courier verified its proximity to the source to the courier management system <NUM>. The courier device <NUM> may continue to monitor its proximity to the source device via the broadcast beacons from the source device, and report changes to the courier management system <NUM>. By continuing to report the proximity of the courier device <NUM> to the source device, the courier management system <NUM> may update the estimated time of delivery for the order based on the amount of time spent waiting for pickup of the order or the time at which the courier device <NUM> reported leaving the proximity of the source device. If the courier device <NUM> continues to report its proximity until it leaves the range of the beacon, the proximity information may be used to automatically collect information about how long the courier device <NUM> was near the source to pick up the order. This may reflect delays or other problems with the pickup or preparation by the source of the order, or to notify the courier management system <NUM> when the courier device <NUM> leaves the range or vicinity of the source device <NUM>.

As an addition or an alternative, in some embodiments, the courier device <NUM> can also broadcast <NUM> its courier beacon in response to sending <NUM> the courier verification. In this alternative embodiment, the courier device <NUM> begins broadcasting <NUM> a courier beacon with the order ID and the courier ID corresponding to the order. Upon receiving the courier broadcast <NUM>, the source device <NUM> identifies <NUM> a match between the courier and an active order, and sends a source verification <NUM> to the courier management system <NUM>. The source verification may be a beacon detection event sent from the source device <NUM>. When the courier management system <NUM> receives the courier verification, and optionally when it also receives the source verification, the courier management system <NUM> may automatically verify <NUM> that the order was picked up by the courier, as the devices reported proximity to one another for specifically designated broadcast parameters by the other device. In some embodiments, when the order is verified <NUM> as picked up, the courier management system <NUM> may indicate to the courier device and source device to stop broadcasting <NUM>, <NUM>. In some embodiments, the courier management system <NUM> instructs the courier device to stop broadcasting <NUM> prior to instructing the source device <NUM> to stop broadcasting <NUM>. For example, though the proximity of the devices has been verified, the order may not in fact be ready to pick up, or there may be other problems with the courier device <NUM> leaving the source location. In this case, by allowing the source device <NUM> to continue to include the order in its broadcast, the courier device may continue to report the estimated proximity of the source device <NUM> to the courier management system <NUM>. Thus, the courier management system <NUM> may delay stopping broadcast of the source device <NUM> until after the courier device <NUM> reports a change in proximity of the courier device <NUM> from the source device <NUM> (e.g., from near to far). In other examples, the courier device <NUM> continues to report any change in proximity to the source device <NUM> by monitoring the "source identifier" of broadcast beacons, rather than the specific order. In that case, the actively-broadcasted orders on the source device may remove the verified <NUM> order, but events may still be received and provided by the courier device <NUM> representing the proximity of the courier device <NUM> to the source device <NUM>.

By providing the receipt of a source beacon and matching source and order identifiers, the courier management system <NUM> can more effectively determine whether couriers are properly approaching the location of the source device to complete an order pick up. In addition, in events where the courier beacon is broadcast, because each device is reporting receipt of a proper beacon, the location of a beacon cannot be easily spoofed because proper verification may use receipt of both the courier verification and the source verification.

According to some examples, an entity that provides a platform for enabling delivery services and/or arranges courier services via the courier management system <NUM> can use the verification data to determine how long individual couriers are at an order provider's locale or venue (e.g., within a restaurant or a store, or a delivery location, etc.) generally or for each particular order. The entity can offer financial incentives, for example, to reduce dissatisfaction for couriers having to wait an extended amount of time for orders to be ready by the order provider or merchant. For example, a courier can be instructed to get to a restaurant to pick up a food order at noon. If the courier has arrived at <NUM><NUM>:58am and had to wait until <NUM>:25pm for the food order to be ready for delivery, the courier management system <NUM> can determine a financial incentive amount based on an extra duration of time that the courier had to wait (e.g., excluding a five-minute buffer from noon to <NUM>:05pm, the financial incentive amount can be based on the courier having to have waited for an extra twenty minutes).

Still further, in some examples, based on the data collected for individual order providers (e.g., from historically obtained verification data for orders in general and/or for specific items of orders), the courier management system <NUM> can predict when a received order for a particular order provider will be ready for pick up. By using the predicted estimated time of order completion, the courier management system <NUM> can time when a courier needs to be selected from a pool of available couriers and drivers to head to that order provider. As an additional example, the courier management system <NUM> can also use determined information about actual wait times or order completion time for an order provider to provide more accurate estimated time of arrival (ETA) information to requesters/consumers of the order.

The verification data can also provide information to inform the entity whether a courier has followed particular instructions for picking up an order. As an example, for a particular restaurant, any food order pickups may require a courier using the platform to go inside the restaurant to pick up the food order (e.g., as opposed to asking someone at the restaurant to come to the courier's vehicle to hand off the food order). The courier can be instructed, via a client application running on the courier device <NUM>, to go into the restaurant. The courier management system <NUM> can use proximity information determined from the beacons to determine whether a courier has complied with the instructions and provide feedback to the courier, e.g., via the client application, to modify or improve behavior (or provide positive feedback for following the instructions).

According to another example, by using beacons, the source device <NUM> can automatically detect whether a courier was present to pick up an order. An operator at the source and/or the courier may not have to press a button or a soft feature on a respective device to confirm that an order was picked up, thereby minimizing manual hand off and confirmation between the parties. In additional configurations, the received beacons may also be used to modify the interaction and display by each device. As one example, when a courier beacon is received by the source device <NUM>, the source device <NUM> may retrieve a picture of the courier associated with the device to display the picture and order for delivery to the operator of the source device <NUM>, permitting easy identification and hand-off to the courier and reducing the risk of improperly giving an order to an unauthorized user. This may also enable an operator at the source to make it easier to find the correct courier (if there are multiple couriers or a crowd of people at the venue). Alternatively, or additionally, upon detecting a source beacon <NUM> the courier device <NUM> may retrieve the contents of the order for pickup and instructions for picking up the order. This process allows the courier to verify whether they have received to correct order for pickup and whether they are satisfying the requirements of the venue operating the source device.

In another example, a similar beacon process may be performed during the delivery process, such that the courier may use beacons to identify proximity to the desired delivery location of the requesting device <NUM>.

Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof.

Embodiments of the invention may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

<FIG> illustrates a courier with a courier device approaching a source location in accordance with some embodiments. <FIG> illustrates a bird's eye view of a building of the source location <NUM> and the surrounding streets. Within the source location <NUM>, the source device <NUM> is located on a counter top. As previously described, the source device <NUM> is broadcasting a source beacon <NUM>. <FIG> illustrates the beacon signal as having a source beacon detection range <NUM> and a beacon pickup proximity <NUM>. In this example illustration, the source beacon detection range <NUM> is the range at which a courier device <NUM> is able to detect the source beacon <NUM> and the beacon pickup proximity <NUM> indicates the proximity to which the courier device <NUM> must be in order to be confirmed as having picked-up the requested items of an order. In <FIG>, the courier device <NUM> is located outside of the source beacon detection range <NUM> and is travelling in a courier vehicle <NUM>, which may be any kind of vehicle.

Because the courier device <NUM> is located outside of the source beacon detection range <NUM>, the courier device <NUM> cannot detect the source beacon and so does not transmit a beacon detection event to the courier management system <NUM>.

<FIG> illustrates a situation where the courier device <NUM> has moved inside the source beacon detection range <NUM> in accordance with one embodiment. In this case, the courier has parked the courier vehicle <NUM> outside the source location <NUM> and has moved inside the source location <NUM> with the courier device <NUM>. The courier device <NUM> is now within the source beacon detection range <NUM>. Thus, the courier device <NUM> can detect the source beacon <NUM> and proceed to match <NUM> the source identifier and order identifier included in the source beacon <NUM>. If a match is detected, the courier device <NUM> would then transmit a beacon detection event to the courier management system <NUM> indicating that the courier device <NUM> is within the source location <NUM>. The beacon detection event may also include an estimate of the proximity of the source device <NUM> to the courier device <NUM>.

<FIG> illustrates the courier device <NUM> broadcasting a courier beacon <NUM> in accordance with one embodiment. In some embodiments, the courier device <NUM> may verify its position by broadcasting a courier beacon <NUM> in response to detecting a source beacon <NUM>. Because the courier device <NUM> is already within courier beacon detection range <NUM>, the source device <NUM> may detect the courier beacon <NUM> and transmit a second beacon detection event to the courier management system <NUM>.

<FIG> illustrates the courier device <NUM> coming in close proximity to the source device <NUM> so that the courier may pick up the request items in an order in accordance with one embodiment. In order to pick up the order at the source location <NUM> the courier and courier device <NUM> must move within a threshold distance (e.g., the beacon pickup proximity <NUM>). In some embodiments, the courier device <NUM> (or alternatively the source device <NUM> if the courier device <NUM> is still broadcasting the courier beacon <NUM>) may continue to detect the source beacon <NUM> and estimate the distance between the two devices. Once the distance is less than the beacon pickup proximity <NUM>, the courier device <NUM> may transmit a beacon detection event to the content management system <NUM> indicating that the two devices are close together. In some embodiments, the courier management system <NUM> will automatically indicate that the pickup has been completed as a result of receiving this beacon detection event as described in previous sections.

Claim 1:
A method of verifying that a computing device (<NUM>) of a service provider is in proximity of a source device (<NUM>), the method performed by a network system (<NUM>) and comprising:
receiving (<NUM>), from a requesting device over one or more networks, an order request for an item; and
generating (<NUM>) an order based on the order request, the order including an order identifier associated with the order and a source device identifier of the source device;
transmitting (<NUM>), over the one or more networks, the order to the source device (<NUM>) and to the computing device (<NUM>); and
receiving (<NUM>, <NUM>) at least one of:
a verification from the computing device (<NUM>) over the one or more networks that the computing device (<NUM>) is within a range of the source device (<NUM>), the verification based on (i) a match between the source device identifier and a major identifier included in a source beacon signal broadcasted by the source device (<NUM>), wherein the major identifier included in the source beacon signal represents the source device ID, and (ii) a match between the order identifier and a minor identifier included in the source beacon signal, wherein the minor identifier included in the source beacon signal is an identifier of the order; or
a verification from the source device (<NUM>) over the one or more networks that the computing device (<NUM>) is within a range of the source device (<NUM>), the verification from the source device based on (i) a match between a computing device identifier associated with the computing device (<NUM>) and a major identifier included in a computing beacon signal broadcasted by the computing device (<NUM>), the computing device identifier being comprised as part of the order, wherein the major identifier included in the computing beacon signal represents the computing device ID, and (ii) a match between the order identifier and a minor identifier included in the computing beacon signal, wherein the minor identifier included in the computing beacon signal is an identifier of the order.