Patent Description:
The present technology pertains to systems and methods for providing accurate arrival alerts, and more specifically pertains to adjustment in the frequency with which tracking devices send location updates to servers used in providing accurate arrival alerts.

Current services that provide arrival alerts often rely on receiving continuous location updates from a moving target (e.g., a vehicle) in order to determine, as accurately as possible, a timing of alerting the destination (e.g., a store) of the moving target's arrival at the destination. For example, when a user is driving to a location of a store to pick up an ordered item, the system's objective is to provide an accurate advance alert (arrival alert) to the operator of the store so that the operator can ensure the user's order is ready for pick when the user arrives.

The requirement for such continuous transmission of location updates from a tracking device (e.g., a mobile device) associated with the moving target to the server, results in large signaling overheads, network resource consumption and consumption of computation capacity at the server. In addition, these continuous transmissions also increase the battery and data usage of the tracking device. For example, given that mobile devices use data and relatively large amount of battery charge to communicate with nearby cell towers or access points, a mobile device that is configured to send location updates to the server via the cell tower or over a WiFi connection, every second or so, can rapidly deplete its battery and increase its data usage.

<CIT> describes apparatus, method and system for contextually aware monitoring of a supply chain. In some implementations, contextually aware monitoring can include monitoring of the supply chain tradelane with tracking devices including sensors for determining location, velocity, heading, vibration, acceleration (e.g., 3D acceleration), or any other sensor that can monitor the environment of the shipping container to provide contextual awareness. The contextual awareness can be enabled by geofencing and recursive algorithms, which allow dynamic modification of the tracking device behavior.

<CIT> describes a mobile computing device comprising a wireless transceiver and a processing circuit. The processing circuit is configured to store a data set for a predetermined location, the data set comprising location data and a location name. The processing circuit is further configured to compare a current location to the location data, to compare an updated location to the location data at a time calculated based on heuristic data, and to generate a notification message based on the mobile computing device arriving at or near the predetermined location.

<CIT> describes methods, apparatuses, and systems receiving an indication that an order associated with a user account is ready for pickup. One or more messages to a user device associated with the user account are transmitted in response to the received indication that the order is ready. The one or more messages include identification of the order as being ready for pickup, a pickup location for the order, and a threshold distance from the pickup location for the order. Location data is received at a limited interval from a user device while the user device is outside of the threshold distance from the pickup location. Location data is received at a more frequent interval than the limited interval while the user device is within the threshold distance. The location data is transmitted to a local pickup device to trigger an alert when the user device is approaching the pickup location.

<CIT> describes methods and systems for providing a notification relating to a geographical boundary based on monitored sensor data collected by networked devices. The disclosed embodiments include, for example, a method for receiving, by one or more processors, a request to establish a first boundary around a first location. The method may also include monitoring, by the one or more processors, one or more triggering devices. The method may also include calculating, by the one or more processors, a first boundary extent delimiting the geographical area of the first boundary based on one or more boundary extent parameters. The method may also include detecting, by the one or more processors, whether at least one of the one or more triggering devices is located within the first boundary extent. The method may also include, when the at least one of the one or more triggering devices is detected within the first boundary extent, sending, by the one or more processors, a notification to a client device based on the determining.

<CIT> describes the integration of a courier service with a customer application. To integrate a courier service with a customer application, a system may receive a plurality of orders that are to be fulfilled by delivery along with a plurality of locations associated with a plurality of courier devices. The system can then generate a proposal for an order that is based on the plurality of orders and the plurality of locations. In some instances, the system generates the proposal to include one or more options for fulfilling the order, such as delivery by a courier, pickup by a customer, or dine-in by the customer. In some instances, the system further determines a cost associated with each of the options and generates the proposal to include the respective costs.

Example embodiments are provided for smart signaling of location update for arrival estimation, which provides for adjustment in the frequency with which tracking devices send location updates to servers used in providing accurate arrival alerts of associated users at a location of interest such as a merchant location.

The above problem is solved by the subject matter of the independent claims. Examples and technical descriptions of apparatuses, products and/or methods in the description and/or drawings which are not covered by the claims are presented not as embodiments of the invention but as background art or examples useful for understanding the invention. In one example, a computer-implemented method for providing arrival alerts, includes receiving a first location update from a tracking device; determining a remaining time for the tracking device to reach a destination location; determining whether the remaining time is within a threshold time of a timing of an arrival alert to be sent to a device associated with the destination location; based on whether the remaining time is within the threshold time or not, configuring the tracking device to send location updates to a server in one of a continuous reporting mode or a significant reporting mode, wherein the tracking device is configured to send the location updates to the server less frequently in the significant reporting mode compared to the continuous reporting mode; and determining when to send the arrival alert to the device associated with the destination location based on one or more of the location updates received from the tracking device.

In one aspect, device includes memory having computer-readable instructions stored therein and one or more processors. The one or more processors are configured to execute the computer readable instructions to receive a first location update from a tracking device; determine a remaining time for the tracking device to reach a destination location; determine whether the remaining time is within a threshold time of a timing of an arrival alert to be sent to a device associated with the destination location; configure the tracking device to report subsequent location updates in a continuous reporting mode if the remaining time within the threshold time or in a significant reporting mode if the remaining time is not within the threshold time; and send the arrival determine to a device associated with the destination location when a most recent location update received from the tracking device in the continuous reporting mode indicates that the remaining time is the same as the timing of the arrival alert.

In one aspect, one or more non-transitory computer-readable medium have computer-readable instructions stored thereon, which when executed by one or more processors, cause the one or more processors to receive a first location update from a tracking device; determine a remaining time for the tracking device to reach a destination location; determine whether the remaining time is within a threshold time of a timing of an arrival alert to be sent to a device associated with the destination location; and based on whether the remaining time is within the threshold time or not, configure the tracking device to send location updates to a server in one of a continuous reporting mode or a significant reporting mode, wherein the tracking device is configured to send the location updates to the server less frequently in the significant reporting mode compared to the continuous reporting mode.

The above-recited and other advantages and features of the present technology will become apparent by reference to specific implementations illustrated in the appended drawings. A person of ordinary skill in the art will understand that these drawings only show some examples of the present technology and would not limit the scope of the present technology to these examples. Furthermore, the skilled artisan will appreciate the principles of the present technology as described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

Various examples of the present technology are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the present technology.

The disclosed technology addresses the need in the art to reduce the amount of unnecessary signaling and communication between tracking devices and servers, over a cellular or WiFi connection, for tracking devices to provide servers with location updates. At the same time such reduction in unnecessary signaling should be balanced against the need to obtain enough location updates from the tracking devices in order to determine, as accurately as possible, the timing of sending an arrival alert to a destination informing the destination of the arrival of a corresponding user. This balancing requires a "smart" signaling strategy according to which the frequency of signaling used for conveying location updates from a tracking device to a server is dynamically adjusted depending on, among other factors, time and distance of the tracking device from a point in time at which the arrival alert is to be provided to the destination.

The disclosure begins with a description of several example systems in which the concepts described herein can be implemented.

<FIG> illustrates an example system in accordance with one aspect of the present disclosure. As illustrated in <FIG>, system <NUM> includes a user <NUM> associated with a tracking device <NUM> (user device <NUM> or customer device <NUM>). While not shown in <FIG>, user <NUM> and tracking device <NUM> can be associated with a moving object including, but not limited to, a car, a bus, a bike, a public transportation vehicle, etc. The tracking device <NUM> can be any known or to be developed electronic device capable of tracking a movement of the user <NUM> (and the associated moving object) and communication the same with a server <NUM> over a wired and/or wireless communication platform such as over a cellular network or a WiFi connection. Examples of tracking device <NUM> include, but are not limited to, a cellular phone, a personal digital assistant (PDA), a laptop, a tablet, a wristband tracking object, etc. In one example, tracking device <NUM> has location service <NUM>. Location service <NUM> can be any known or to be developed built-in sensor, device and/or location determining component such as a global positioning system (GPS) device capable of recording geographical coordinates (e.g., latitude and longitude) of tracking device <NUM> at any given point in time.

While not shown in <FIG>, tracking device <NUM>, server <NUM> and any other component of system <NUM> have other components for enabling communication with other components such as transceivers.

The system <NUM> further includes a destination <NUM>. Destination <NUM> can be a target location that is to receive arrival alerts from server <NUM> informing an operator thereof of the timing of user <NUM>'s arrival at destination <NUM>. For example, destination <NUM> can be a brick-and-mortar store, from which user <NUM> has ordered item(s) for purchase and is en route to pick up the order. Other examples of destination <NUM> include, but are not limited to, a restaurant, a department store, other types of service providers such as dry cleaning services, a library, etc. Therefore, it is important for server <NUM> to provide an arrival alert to destination <NUM> at a threshold time ahead of the arrival of user <NUM> (e.g., <NUM> minutes prior to user's arrival at destination <NUM>) to ensure that the ordered item(s) are ready when user <NUM> arrives at destination <NUM>. Therefore, the arrival alert needs to be as accurate as possible to avoid or reduce inconveniences (e.g., waiting for the ordered item(s) to be prepared for a period of time after arrival) experienced by user <NUM> and/or an operator at destination <NUM>.

Destination <NUM> can have an operator <NUM> associated therewith such as an employee. Furthermore, destination <NUM> can have a computing device <NUM> with which operator <NUM> interacts to receive arrival alerts, send and receive identifying information to server <NUM> and/or track device <NUM>, confirm/cancel/adjust orders, etc. Computing device <NUM> can be any known or to be developed device that is used by destination <NUM> and is capable of communicating with server <NUM> over a wired and/or wireless connection such as a WiFi connection. Examples of computing device <NUM> include, but are not limited to, a tablet, a stationary computer device, a mobile device, any other known or to be developed Point of Sale (POS) devices, etc..

System <NUM> also includes server <NUM>. Server <NUM> can have one or more processors such as processor <NUM> capable of implementing one or more sets of computer-readable instructions stored in one or more memories such as memory <NUM>. Execution of any one or more of these sets of instructions enable server <NUM> to implement functionalities of methods described below with reference to <FIG>. These functionalities include, but are not limited to, building destination specific models using machine learning, which can then be used to provide arrival prediction services, determining smart signaling for location receiving location updates, etc..

As shown in <FIG>, server <NUM> can also have database <NUM> (can also be referred to as past trips database <NUM>). Data stored in database <NUM>, as will be described below, will be used by machine learning algorithms implemented by server <NUM> to build destination specific models and perform arrival prediction services.

System <NUM> can also include routing engine <NUM>. Routing engine <NUM> can be any conventional routing engine such as those commonly associated with mapping applications. Such routing engines may take into account distance to a destination and speed limits and in some cases current traffic, weather and time of day conditions in providing preliminary arrival times to server <NUM>, which will be used by server <NUM> and logics implemented thereon to refine, revise and provide arrival alerts to destination <NUM>. Furthermore, routing engine <NUM> does not account for other location specific factors such as most likely routes to the destination, likely stops along the way and any other learned factors for generating destination specific models for destinations at server <NUM>.

Server <NUM> and routine engine <NUM> can be co-located physically or be configured to communicate over wired and/or wireless networks. Furthermore, each identified component of system <NUM> can communicate with other components of system <NUM> and/or any other external component using currently known or to be developed cellular and/or wireless communication technologies and platforms.

<FIG> illustrates an example system in accordance with one aspect of the present disclosure. System <NUM> of <FIG> is the same as system <NUM> of <FIG> except that instead of having user <NUM> travel to destination <NUM> to pick up item(s)/service(s) ordered as shown in <FIG>, a destination such as destination <NUM> utilizes a delivery service (e.g. that of a driver) to deliver user <NUM>'s order(s) to user <NUM>. Therefore, components of system <NUM> that have the same numerical reference as those in <FIG> will not be further described for sake of brevity.

In system <NUM> shown in <FIG>, instead of destination <NUM> and its corresponding components, a driver <NUM> having an associated tracking device <NUM> is illustrated. In the context of <FIG>, driver <NUM> and associated tracking device <NUM> is moving toward user <NUM> (similar to user <NUM> and tracking device <NUM> in <FIG>) while user <NUM> is stationary (similar to destination <NUM> in <FIG>). Accordingly, in the context of <FIG>, an arrival alert is provided to user <NUM> informing user <NUM> of arrival of driver <NUM>. Therefore, various types of calculations for location determination as described in this application, are performed for determining location of tracking device <NUM> and estimating its arrival at user <NUM>.

Driver <NUM> and tracking device <NUM> can be associated with a moving object such as a vehicle operated by driver <NUM>. Tracking device <NUM> can be any known or to be developed electronic device capable of tracking a movement of the driver <NUM> (and the associated moving object) and communicate the same with server <NUM> over a wired and/or wireless communication platform such as over a cellular network or a WiFi connection. Examples of tracking device <NUM> include, but are not limited to, a cellular phone, a personal digital assistant (PDA), a laptop, a tablet, a wristband tracking object, etc. Location service <NUM> of tracking device <NUM> can be the same as location service <NUM> of tracking device <NUM> (identified as customer device <NUM> in <FIG>) described above with reference to <FIG>.

While in <FIG> and <FIG> various components are illustrated and described, inventive concepts are not limited thereto. For example, the number of users, devices, destinations, servers, etc., are not limited to those described and can be more or less. Furthermore, both systems <NUM> and <NUM> can have additional components, architecture and/or functionalities associated therewith that are ordinary and/or necessary for proper operations thereof and thus are within the scope of the present disclosure.

As briefly mentioned above, server <NUM> is tasked with tracking a moving object associated with user <NUM> in order to provide an alert to destination <NUM> at a threshold time ahead of user <NUM>'s arrival at destination <NUM>, so that operator <NUM> at destination <NUM> can prepare and ready order(s) for user <NUM> to pick up when he or she arrives at destination <NUM>. Such threshold time can be a configurable parameter determined based on various factors such as operator <NUM> feedback, user <NUM> feedback, automatic system determination based on prior trips to destination <NUM>, etc. For example, operator <NUM> can request that server <NUM> provide operator <NUM> with an alert when user <NUM> is <NUM> minutes away from arriving at destination <NUM> for picking up his or her order(s). Therefore, server <NUM> needs to have precise information on user's location in order to provide, as accurately as possible, an arrival alert to operator <NUM> at destination <NUM> when user <NUM> is <NUM> minutes away from reaching destination <NUM>.

Server <NUM> implements various techniques to improve the accuracy of the arrival alert provided to destination <NUM>. For example, server <NUM> applies machine learning to various statistical data to create destination specific model(s) for destination <NUM>. Various statistic data can include, but is not limited to, past completed trips of users to destination <NUM>, past completed trips of user <NUM>, traffic conditions, modes of transportation, types of moving objects associated with user <NUM> (and/or driver <NUM> in <FIG>), weather conditions, times of days, events taking place en route to destination <NUM> or at destination <NUM>, speed of the moving object, any construction, road closures and improvement, etc. The statistical data can be stored in database <NUM>.

For example, a particular brick-and-mortar store maybe located in a downtown area where traffic conditions vary greatly depending on time of day. Server <NUM> takes this information into consideration to build a destination specific model for the brick-and-mortar store located in the downtown area. During prediction of arrival of user <NUM> at the downtown location of the brick-and-mortar store and depending on the time of day, server <NUM> can augment its prediction and improve its arrival prediction using the corresponding destination specific model.

<FIG> illustrates an example of method for creating destination specific models in accordance with one aspect of the present disclosure. <FIG> will be described with reference to <FIG>. However, the concepts described are equally applicable to the system of <FIG> as well. The method illustrated in <FIG> begins after one or more notifications have been provided to destination computing device <NUM> regarding an arrival prediction of user <NUM> at destination <NUM> to pick up order(s) (or one or more trips to destination <NUM> have been completed). Server <NUM> can store a collection of data in database <NUM>. The data can be any one or more of statistical data examples provided above. In addition, server <NUM> can store information regarding the quality of past notifications and an identifier of the past notifications. For example, every time server <NUM> has provided an arrival alert to destination <NUM> indicating that user <NUM> will arrive in <NUM> minutes, server <NUM> compares this estimated arrival time to an actual time it took user <NUM> to arrive at destination <NUM>. For example, while server <NUM> predicted, at time T0, that user <NUM> will arrive at destination <NUM> in <NUM> minutes, in reality, it may take user <NUM><NUM> minutes from T0 to arrive at destination <NUM>. This indicates a prediction error of <NUM>%. Server <NUM> stores this prediction error in database <NUM>. During the next round of prediction and in providing the arrival alert, server <NUM> adjusts its prediction by <NUM>% before providing the arrival alert (e.g., in the particular example described above, instead of providing the arrival alert at T0, server <NUM> now provides the arrival alert at T1 which is <NUM> minutes earlier than T0).

At S302, server <NUM> queries computing device <NUM> of destination <NUM> for rating a quality of a recently provided arrival alert. Operator <NUM> operating destination computing device <NUM> can respond to the query. Upon receiving the response, server <NUM> stores the rating at S306. In addition to, simultaneous with or instead of querying computing device <NUM> for rating, at S304, server <NUM> can calculate a rating or prediction error regarding the arrival alert, as described above. Similarly, the calculated rating is received at S306.

At S308, server <NUM> can record the received rating(s), per S302 and <NUM>, in database <NUM> in association with an identification (ID) of the notification. The ID can be an identification of a particular transaction between user <NUM> and a merchant at destination <NUM>, can be an identification associated with user <NUM>, can be an identification associated with destination <NUM> or any combination thereof.

Server <NUM> can also store in database <NUM>, information regarding a route taken by user <NUM> in connection with a recently completed trip to destination <NUM>, and any other data pertinent to the trip that resulted in the notification. The route taken by user <NUM> can be learned from data reported by location service <NUM> to server <NUM> while user <NUM> and associated computing device <NUM> were traveling to destination <NUM>. In some examples, from this route information, server <NUM> can determine if user <NUM> made any stops while in route to destination <NUM>. Server <NUM> can also record a time of day, day of week, and date associated with the notification in database <NUM>. Server <NUM> can aggregate the above data for trips by many users.

At S310, server <NUM> applies machine learning algorithm(s) to the historical data specific to destination <NUM> stored in database <NUM>. At S312, server <NUM> generates destination specific model for destination <NUM> based on the machine learning algorithm(s) applied to stored data at <NUM>. In one example, destination specific model may be created or trained by analyzing factors associated with notifications that were considered of good quality and factors associated with notifications that were considered of poor quality. Since the destination specific model is generated through machine learning, some dimensions of destination specific model may not have any semantic meaning while some dimensions may have a semantic significance. For example, those dimensions having a semantic meaning can include likelihood that a user will make other stops along the route, likelihood that a user will encounter traffic along the route, the most likely routes to the destination, etc..

In some examples, machine learning may initially be trained on all data in database <NUM> regardless of destination to result in a location non-specific model. In such examples, destination specific model may be the result of tuning the location non-specific model for factors relevant to the specific destination <NUM>.

As can be seen from the above description, server <NUM> relies on location updates received from tracking device <NUM> in order to determine current location of user <NUM>, which is then used for determining/estimate the timing of sending the arrival alert to computing device <NUM> of destination <NUM>. Depending on the distance and time of user <NUM> from destination <NUM>, it may or may not be critical for server <NUM> to receive continuous location updates from tracking device <NUM>. For example, when the most recent location update received from tracking device <NUM> indicates that user <NUM> is one hour and <NUM> miles away from destination <NUM>, it is not critical for server <NUM> to receive updated location information from tracking device <NUM> in the next <NUM> seconds indicating that the user <NUM> is <NUM> minutes and <NUM> miles away from destination <NUM>. Therefore, the frequency of location updates provided by tracking device <NUM> can be reduced (e.g., next update can be provide when user is <NUM> miles or <NUM> minutes away from destination <NUM>).

However, as the user's location along the route approaches closer to the threshold time for providing the arrival alert (e.g., the <NUM> minute mark in the example described above), it is important that tracking device <NUM> provides server <NUM> with more frequent updates (e.g., every <NUM> seconds) about its location.

Furthermore, tracking devices such as mobile devices have various built-in functionalities that allow them to switch modes for reporting location updates (for example, to nearby cell towers). Example modes include a continuous reporting mode, where a device reports its location to nearby cell towers and the server frequently (e.g., every <NUM> seconds, <NUM> seconds, <NUM> second, etc.) and significant mode, where a device is to sends location updates to nearby cell towers and the server relatively infrequently (e.g., after a target reporting time is lapsed or a target distance traveled, where the target reporting time and the target distance can vary from one reporting instance to the next).

Hereinafter, examples will be described according to which server <NUM> determines, based on various conditions, whether the device is to send location updates using continuous or significant mode as well as thresholds of reporting (e.g., target reporting time and target distance mentioned above) in the significant mode.

<FIG> is an example method of smart signaling of location updates in accordance with one aspect of the present disclosure. <FIG> will be described with reference to system <NUM> of <FIG>. However, <FIG> is equally applicable to system <NUM> of <FIG>. Furthermore, <FIG> will be described from the perspective of server <NUM>. However, it is understood by those skill in the art that one or more processors such as processor <NUM> of server <NUM> executes computer readable instructions stored on or more memories such as memory <NUM> to implement the functionalities described below.

At <NUM>, server <NUM> sets a threshold time for providing destination <NUM> with an arrival alert. As indicated above, the threshold time can be set based on a requested time by operator <NUM> of destination <NUM>. However, the threshold time can also be set based on a requested time by a particular user such as user <NUM>, based on an average of requested times for various users or can be set automatically by server <NUM> based on past arrival times and accuracies thereof for destination <NUM> and/or across multiple destinations. For example, based on one or more requested times from destination <NUM>, user <NUM> and or automatic determination by server <NUM> itself, server <NUM> sets the threshold time for sending an arrival alert to destination <NUM> to <NUM> minutes. Hereinafter, the threshold time is also referred to timing of arrival alert.

In one example, prior to or simultaneous with the setting the timing of arrival alert, server <NUM> receives an indication that user <NUM> has placed an order for item(s), service(s), etc., with destination <NUM> (e.g., a merchant, a restaurant, a service provider, etc.) for pick up.

At S402, server <NUM> receives a location update (first location update) via, for example, a global positioning system (GPS) signal from tracking device <NUM> associated with user <NUM>. In one example, server <NUM> receives the location update via one or more cell towers (e.g., eNode-Bs, base stations) and/or WiFi access points that is/are communicating with tracking device <NUM>. The location update may also be referred to as location update data or updated location data.

At S404 and based on the last location update received from tracking device <NUM>, an amount of time and a distance of user <NUM> to destination <NUM>, which may be referred to as remaining time and remaining distance of user <NUM> from destination <NUM>, respectively. In one example, the remaining time and distance are determined based on the updated location data received at S402, destination specific model for destination <NUM> as well as other factors associated with the route taken by user <NUM> to reach destination <NUM> including but not limited to time of day, traffic conditions, weather conditions, events along the route, etc. as provided by, for example, routing engine <NUM>.

At S406, server <NUM> determines if the remaining time derived at S404 is within a predetermined threshold of the arrival alert timing set at <NUM>. The predetermined threshold can be a configurable parameter determined based on various factors and empirical studies, such as but not limited to, ratings and accuracies of previously provided arrival alerts, etc. For example, the predetermined threshold can be <NUM> minutes. In other words, at S406, server <NUM> determines if the remaining time is less than or equal to <NUM> minutes from the <NUM> minute mark in the example described above (e.g., if the remaining time to destination <NUM> is equal to or less than <NUM> minutes).

If at S406, server <NUM> determines that the remaining time is not within the predetermined threshold of the arrival alert timing (e.g., tracking device <NUM> is relatively far from destination <NUM>), then at S408, server <NUM> sends a command to tracking device <NUM> to switch tracking device <NUM> to send location updates in the significant mode described above.

Next, at S410, server <NUM> determines a target reporting time and/or a target reporting distance at which tracking device <NUM> is to report its next location to server <NUM> while operating in the significant mode. For example, at S404, server <NUM> may have determined that tracking device <NUM> is <NUM> minutes and <NUM> miles away from destination <NUM>, which is not within the predetermined threshold of the arrival alert timing of <NUM> minutes. Therefore, server <NUM> determines that in the significant reporting mode, tracking device <NUM> should report its next location after <NUM> minutes has elapsed or a distance of <NUM> miles has been traveled by user <NUM>. The determination of specific target time and/or target distance by server <NUM> can be based on many factors including, but not limited to, destination specific model for destination <NUM>, traffic conditions, etc..

Upon determining the next target time/distance for reporting, at S412, server <NUM> sends the target time and target distance for reporting back to tracking device <NUM>.

Thereafter, the process reverts back to S402 and server <NUM> repeats S402-S424, as appropriate.

Referring back to S406, if at S406, server <NUM> determines that the remaining time of tracking device <NUM> to destination <NUM> (based on the latest reported position of tracking device <NUM> at S402) is within the predetermined threshold of the arrival alert timing (e.g., less than <NUM> minutes in the example described above), then at S414, server <NUM> sends a command to tracking device <NUM> to put the device in continuous reporting mode described above. As mentioned in the continuous reporting mode, tracking device <NUM> sends location updates to server <NUM> more frequently compared to when tracking device <NUM> is reporting in the significant mode and at set intervals (e.g., every <NUM> seconds, <NUM> seconds, <NUM> second, etc.). This in turn increases the battery and data usage of tracking device <NUM> compared to the significant reporting mode where locations updates are transmitted less frequently as per S406- S414 described above.

Next, at S416, server <NUM> determines a target reporting time and/or a target reporting distance at which tracking device <NUM> is to report its next location to server <NUM> while operating in the continuous mode. For example, server <NUM> may have determined that tracking device <NUM> is <NUM> minutes and <NUM> miles away from destination <NUM>, which is within the predetermined threshold of the arrival alert timing of <NUM> minutes. Therefore, server <NUM> determines that in the continuous reporting mode, tracking device <NUM> should report its next location after <NUM> seconds has elapsed or a distance of <NUM> mile has been traveled by user <NUM>. The determination of specific target time and/or target distance by server <NUM> can be based on many factors including, but not limited to, destination specific model for destination <NUM>, traffic conditions, etc..

Upon determining the next target time/distance for reporting, at S418, server <NUM> sends the target time and target distance of S416 back to tracking device <NUM>. At S420, server <NUM> receives updated location data of tracking device <NUM> according to the continuous reporting mode. Thereafter, at S422, server <NUM> determines if arrival alert should be sent to destination <NUM> or not. In one example, server <NUM> makes the determination of S422 by determining if the remaining time of tracking device <NUM> is equal to the arrival alert timing (e.g., if the remaining time of the tracking device <NUM> to destination <NUM> is equal to <NUM> minutes). This determination can be based on the updated location information received at S418 as well as destination specific model for destination <NUM>, ratings of past arrival alerts, average accuracy error of past arrival alerts, etc..

If at S422, server <NUM> determines that the arrival alert should not be sent, the process reverts back to S420 and server <NUM> repeats S420 and S422 until server <NUM> determines at S422 that the arrival alert should be sent.

However, if at S422, server <NUM> determines that the arrival alert should be sent to destination <NUM>, then at S424, sends the arrival alert to destination <NUM>. Thereafter, the process reverts back to S402 and server <NUM> repeats S402 to S424, as appropriate.

As can be appreciated, the method of <FIG> results in a smart selection of a reporting mode for tracking device <NUM> to report back to server <NUM> with location updates. This results in a dynamic change in frequency and number of reporting and signaling between tracking device <NUM> and server <NUM>. This in turn reduces the number of unnecessary location reporting by tracking device <NUM>, which in turn reduces battery and data usage of tracking device <NUM> as well as the amount of signaling and network resource consumption. Furthermore, dynamic change in frequency of location reporting by tracking device <NUM> also provides the advantage that server <NUM> has to perform less calculations related to remaining time and distance of tracking device <NUM> to destination <NUM>.

<FIG> is an example method of smart signaling of location updates in accordance with one aspect of the present disclosure. Many steps of <FIG> are the same as their corresponding steps in <FIG>. These same steps will be identified below and their descriptions will be omitted for sake of brevity.

<FIG> will be described with reference to system <NUM> of <FIG>. However, <FIG> is equally applicable to system <NUM> of <FIG>. Furthermore, <FIG> will be described from the perspective of server <NUM>. However, it is understood by those skill in the art that one or more processors such as processor <NUM> of server <NUM> executes computer readable instructions stored on or more memories such as memory <NUM> to implement the functions described below.

S500 is the same as S400 at which server <NUM> sets a timing for providing the arrival alert to destination <NUM>. At S502, server <NUM> receives an indication that user <NUM> has placed an order with destination <NUM>. In one example, S500 and S502 take place simultaneously. As part of this indication at S502, server <NUM> receives a timestamp for when the order is placed and a scheduled/desired pick up time at destination <NUM>. For example, user <NUM> places, using an application executed on tracking device <NUM> or a separate mobile device associated with user <NUM>, an order with destination <NUM> at <NUM> AM with a scheduled pick up time of <NUM> PM.

At S504 and based on the order placement time and scheduled pick up time at S502, server <NUM> determines a target reporting time for tracking device <NUM> to send a location update to server <NUM>. For example, given that the order was placed at 7AM and the pickup time is not until 6PM, server <NUM> determines that next location update should be transmitted by tracking device <NUM> at 5PM.

Therefore, at S506, server <NUM> sends a command to tracking device <NUM> to put it in a significant reporting mode, as described above, with the target reporting time specified per S502.

At S508, and at the target reporting time, server <NUM> determines if the target reporting time has passed and a location update is received from tracking device <NUM>. If the reporting time has passed without tracking device <NUM> providing location updates as instructed, at S510, server <NUM> sends a wake up signal to tracking device <NUM> including but not limited to, a text message, a push notification, etc. The process then reverts back to S508.

Upon determining that the target reporting time has passed and location update data received at S508, at S512, the process reverts back to S402, where server <NUM> performs S402 to S424 in the same manner as described above with reference to <FIG>.

According to <FIG>, in addition to the reduction in battery and data usage as well as computational and network resource consumptions achieved by the method of <FIG>, further reductions can also be achieved by taking into consideration the time at which order(s) for item(s) are placed and their scheduled pick up.

<FIG> shows an example of a system for implementing the present technology in accordance one aspect of the present disclosure. <FIG> shows an example of computing system <NUM> in which the components of the system are in communication with each other using connection <NUM>. Connection <NUM> can be a physical connection via a bus, or a direct connection into processor <NUM>, such as in a chipset architecture. Connection <NUM> can also be a virtual connection, networked connection, or logical connection.

In some embodiments computing system <NUM> is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple datacenters, a peer network, etc. In some embodiments, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some embodiments, the components can be physical or virtual devices.

Example system <NUM> includes at least one processing unit (CPU or processor) <NUM> and connection <NUM> that couples various system components including system memory <NUM>, such as read only memory (ROM) and random access memory (RAM) to processor <NUM>. Computing system <NUM> can include a cache <NUM> of high-speed memory connected directly with, in close proximity to, or integrated as part of processor <NUM>.

Processor <NUM> can include any general purpose processor and a hardware service or software service, such as services <NUM>, <NUM>, and <NUM> stored in storage device <NUM>, configured to control processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor <NUM> may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction, computing system <NUM> includes an input device <NUM>, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system <NUM> can also include output device <NUM>, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input/output to communicate with computing system <NUM>. Computing system <NUM> can include communications interface <NUM>, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

Storage device <NUM> can be a non-volatile memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read only memory (ROM), and/or some combination of these devices.

The storage device <NUM> can include software services, servers, services, etc., that when the code that defines such software is executed by the processor <NUM>, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor <NUM> , connection <NUM> , output device <NUM>, etc., to carry out the function.

Any of the steps, operations, functions, or processes described herein may be performed or implemented by a combination of hardware and software services or services, alone or in combination with other devices. In some embodiments, a service can be software that resides in memory of a client device and/or one or more servers of a content management system and perform one or more functions when a processor executes the software associated with the service. In some embodiments, a service is a program, or a collection of programs that carry out a specific function. In some embodiments, a service can be considered a server. The memory can be a non-transitory computer-readable medium.

Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, solid state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

Typical examples of such form factors include servers, laptops, smart phones, small form factor personal computers, personal digital assistants, and so on.

Claim 1:
A computer-implemented method for providing arrival alerts, the method comprising:
receiving a first location update from a tracking device of a user (<NUM>) picking up an item or a driver delivering an item;
determining a remaining time for the tracking device to reach a destination location of an operator (<NUM>) providing the item to be picked up or a user (<NUM>) receiving the item to be delivered;
determining whether the remaining time is within a threshold time of a timing of an arrival alert to be sent to a device associated with the destination location; the threshold time being determined based on operator (<NUM>) and/or user feedback, and/or automatic system determination based on prior trips to the destination,
based on whether the remaining time is within the threshold time or not, configuring the tracking device to send location updates to a server (<NUM>) in one of a continuous reporting mode or a significant reporting mode, wherein the tracking device is configured to send the location updates to the server (<NUM>) less frequently in the significant reporting mode compared to the continuous reporting mode; and
determining when to send the arrival alert to the device associated with the destination location based on one or more of the location updates received from the tracking device.