EP2952037A1

EP2952037A1 - Scheduling data in background services on mobile devices

Info

Publication number: EP2952037A1
Application number: EP13873292.0A
Authority: EP
Inventors: Eduardo Alberto Cuervo LAFFAYE; Kyu Han Kim
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2013-01-31
Filing date: 2013-01-31
Publication date: 2015-12-09
Anticipated expiration: 2033-01-31
Also published as: US20160007282A1; WO2014120173A1; EP2952037B1; US9854517B2; EP2952037A4; CN105009629B; CN105009629A

Abstract

Systems and methods of scheduling data in background services on mobile devices are disciosed. An example method includes identifying data consumption patterns on a mobiie device. The method aiso includes determining sensitivity of data arriving at the mobiie device based on the data consumption patterns. The method aiso includes aggregating network access by background services on the mobile device according to a schedule based on the sensitivity of the data arriving at the mobile device.

Description

SCHEDULING DATA IN BACKGROUND SERVICES ON MOBILE DEVICES

BACKGROUND

[00011 Mobile device usage continues to increase, In 2011, for example, mobile device traffic accounted for almost 7 percent of the tola! network traffic in the United States. Some of the biggest challenges facing mobile device users are imposed by energy constraints.

[0OO2J Energy constraints in mobile devices include, but are not limited to, slow improvements in battery capacity in view of the increasing power demands of modem mobile devices. For example, improvements in electronics (e.g., larger screens, increased number of sensors) and the processing povver to execute more sophisticated software applications, account for some of the increased energy consumption by mobile devices. Data communications aiso contributes to the increased energy consumption by mobile devices. While just 10 years ago, mobile phones could last several days on a single battery charge, now it is common for users to have to recharge the battery in their mobile devices at least once a day, and often even more frequently, !t is expected that battery capacity will struggle to keep up with energy consumption in mobile devices.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 is a high-level illustration of an example networked computer system which may be implemented for scheduling data in background services. 0004| Figure 2 illustrates an example information flow in a mobile device.

[00051 Figure 3 shows an example data proxy architecture,

[00061 Figure 4 shows an example latency sensitivity classifier,

[0007] Figure 5 illustrates an example sequence of events for an application without prefetching,

[00081 Figure 6 illustrates an example sequence of events for an application with prefetching. |0009| Figure 7 illustrates an example sequence of events for instant messaging.

[00103 Figures 8a-c are flowcharts illustrating example operations which may implement scheduling data in background services.

DETAILED DESCRIPTION

[0011j Data usage consumes a significant amount of energy in mobile devices, and impacts battery recharge cycles. A portion of the energy used by mobile devices is not used for the actual transfer of data, but rather is consumed before and/or after the data transfer occurs. For example, mobile devices may incur a "ramp cost" (consuming energy prior to commencement of a data transfer) while associating with a wireless access point (WAP) to establish a wireless local area network or "WsFi" connection. Likewise, mobile devices may incur a "tail cost" (e.g., by continuing to power the communications radio and thus consuming "tail energy") by remaining in a high power state even after a data transfer is completed. In addition, mobile applications or "apps" may continue to access data services in the background. For example, apps may enable social network updates, deploy software updates, and fetc e-mail, even when the user is not actively using the mobile device.

[00123 Example systems and methods of scheduling data in background services on mobile devices are disclosed, in an example, data consumption patterns are identified on a mobile device. Sensitivity of data arriving at the mobile device is determined based on the data consumption patterns. A schedule is used to aggregate network access by background services on the mobile device based on the sensitivity of the data arriving at the mobile device.

[00133 The systems and methods described herein can be used to reduce power consumptio associated with data traffic by determining tolerance of a user to delaying some data, and then intercepting and aggregating data traffic in background services. Aggregation may be based on the user's tolerance for delayed data. Delay-tolerant data can be aggregated, while more sensitive data can be immediately pushed. In an example, data consumed by the mobile device may be more delay-tolerant than data consumed by a user. Other examples are also contemplated. In addition, analysis of incoming traffic ca be used to pre-fetch associated data and bundle the pre-fetched data with the delay-tolerant data to further reduce energy consumption associated with data use.

[001 ] Traffic classification, including simple approaches such as port-based classification , may be used to attempt to infer the application type, and in consequence the behavior, to reduce background data use. But these approaches can be inaccurate, causing user frustration when data the user is expecting does not arrive on the mobile device in a timely manner. Likewise, misciassification can give higher priority than desired, resulting in wasted power. More sophisticated approaches, such as payioad based classification may also be used, relying on packet data to reconstruct application information, in addition to basic semantics of transport protocol and port usage. But payioad inspection can add significant overhead by increasing complexity of the identification process.

[00153 Tri systems and methods described are not restricted to using protocol information, information payioad, or statistical inference of traffic properties, instead, the systems and methods are based on information flow through the mobile device itself. Nevertheless, the sysiems and methods described herein may be utilized independently or be orthogonally applied to other approaches to further reduce power consumption {e.g., ramp and tail costs) associated with data usage in mobile devices, In addition, data transfers can be deferred until a more power efficient radio is available if the priority allows to. For example, low priority traffic can be downloaded only when on a Wi-Fi connection which is more power efficient than 3G.

[0016] Before continuing, it is noted that as used herein, the terms Includes" and "including" mean, but are not limited to, "includes" or "including" and "includes at least" or "including at least." The term "based on" means "based on" and "based at least in part on."

[00173 Figure 1 is a high-level illustration of an example networked computer system which may be implemented for scheduling data in background services. System 100 may be implemented with any of a wide variety of computing devices, such as, but not limited to, mobile device(s) 110 (e.g., tablets 110a and mobile phones 11 Ob), network server(s) 120, and proxy server(s) 130, to name only a few examples. Each of the computing devices may include memory, storage, and a degree of data processing capability at least sufficient to manage a communications connection either directly with one another or indirectly (e.g., via a network 140). At least one of the computing devices is also configured with sufficient processing capability to execute the program code 150 described herein.

[0018] in an example, the system 100 may include a network host(s) 160 providing one or more services (e.g., Services A-D . . . n), which can be accessed by user(s) 101 via the mobiie devices 110. For purposes of illustration, the service may be an online data processing service executing on the network host 180 configured as a server computer. Example services may include genera! purpose computing services (e.g., email), application engines (e.g., social media applications), and hosted business services (e g. , online banking systems, and online retailers), hosted on the Internet or as dynamic data endpoints for any number of client applications or mobile "apps." The services ma also include interfaces to application programming interfaces (APIs) and related support infrastructure. It is noted that these network hosts do not have to be owned or managed by the same entity that manages the proxy, nor the same one that manages the notification server.

[0019] The services may include at ieast one remote source of data. In an example, the data is dynamic (i.e., changing over time). In order to provide the user 101 with up-to-date content, the network: host 160 may be operable to communicate with the notification server 120, For example, when data changes for a user account maintained by the service (e.g., a new email arrives for the user 101 ), the network host 160 may issue a notification (e.g., a "push" notification) to the notification server 120.

[0020] it is noted that there may be limits to the type or amount of data that may be provided by the service. For example, the owner of the notification platform, which is generally the party that makes the operating system of the mobile device, may impose a limit. For example, notifications may be limited to 4 kilobytes of data. The mobile device has to fetch the rest of the content upon receiving the notification. It is also noted that, the data may include unprocessed or "raw" data, or the data may undergo at least some !evei of processi g.

|0021| It is noted that although shown separately in Figure i , the notification server 120 may be part of the service, and/or the notification server 120 may be physically distributed in the network and operatively associated with the service. In any implementation, the notification may be issued to the mobile device 110 via the proxy 130, as illustrated by arrow 72. It is also noted that the computing devices described herein are not limited in function. The computing devices may also provide other services in the system 100. For example, host 160 may also process other transactions.

[0022] The proxy 130 may be any suitable computer or computing device 132 capable of processing notifications from the notification server 120. In an example, the proxy 130 receives data consumption patterns from the mobile devices 110, as illustrated by arrow 174, and determines sensitivity of data from the service for the mobile device based on the data consumption patterns. The proxy aggregates network access to the data by background services (e.g., apps) executing on the mobile devices 1 0 according to a schedule based on the sensitivity of the data being provided by the services. For example, the proxy 130 may aggregate notifications from the notification server 120 and issue bundles of notifications to the mobile devices 110 ail at the same {or substantially the same) time, as illustrated by arrow 176.

[00233 It is noted thai in response to the receiving the notification, the user 101 may request additional information from the service, as illustrated by arrow 178. For example, the user 101 may receive a notification for a new email that has arrived. Upon reading the email, the user 101 may click on the attachment. The attachment may not have been sent through to the mobile device 110 with the email, and so the mobile device 110 may fetch the attachment in response to the user clicking on the attachment in the email

[0024] By way of illustration, an example is notification being too long, if the notification is oversized, the rest of the message may be down loaded when the user clicks on the message, or in the background after the notification is received, In addition, attachments may not be downloaded until the user clicks on them. For example, a 10 KB email may have a 100KB attachment. The first 4KB of the email may be sent to the mobile device. The user receives the email, and dicks on the "click here to see the full email" link io download the remaining 6KB of the email The user finishes reading the email and clicks on the "download attachment link" to download the remainder of the email.

[00253 ^{in an} example described in more detail below, the program code 150 may be executed to pre-fetch data associated with a notification from the network host 160, As an illustration, if the user 101 always reads attachments to email, the proxy 130 may pre-fetch any attachments that come through in an email and aggregate the email with the attachment so that the user does not have to make a separate request from the service to access the attachment.

[0026] The operations described herein for processing the notification may be executed by program code 150. The program code 150 may reside on or be associated with the proxy 130. It is noted, however, that the program code 150 may also reside, at least in part on the mobile device 110 (e.g., as an app). In an example, the program code 150 has access to both the mobile devices 110 and the proxy 30 in the networked computer system 100, It is also noted that the program code 150 may be executed by a server computer or plurality of server computers.

[00273 It is noted that aggregating network traffic by the mobile devices 1 0 can significantly reduce the ramp and tail energy costs of data communications. While the delay being introduced can be acceptable for many applications, it may be unreasonable for other applications. Determining whether this delay is acceptable or unacceptable depends at least in part on how sensitive each application and/or the user is to a delay. By way of illustration, a user may be less sensitive to delays in receiving social media updates than to emails. At an eve finer granularity, a user may be less sensitive to delays i receiving email advertisements, than to delays in receiving emaiis from an important client or an employee's supervisor. By way of further illustration, an application may be less sensitive to a general software update than to a security update. [0Q28J Sensitivity to delay may depend on any of a wide variety of considerations. While, sensitivity to delay may depend at least in part on the protoco! being used, sensitivit to delay may depend on data consumption patterns and context. Fo example, a given user may check e-mail more often than usual when waiting for an important e-mail, or a user may answer more quickly to instant messages received from specific people. While taking into account the sensitivity to latency of different applications at a coarse grain based on features such as protocol, port, and transmission rate, the program code 150 described herein may implement an even finer grain of estimating data consumption patterns, e.g., using the user's and/or application behavior and context as additional features,

[0029] In an example, characterizing data consumption behavior (e.g., how eager a user 101 is to consume a given piece of information) may include measuring the time between particular data being received by the mobile device 110, and that data being consumed. Sn an example, time measurement may be implemented using an information flow technique referred to herein as "tainting" or "taint tracking," Tainting, or taint tracking, allows the program code 150 to track flow of given data through the mobile device 110, e.g., up to final delivery to the user 101.

[0030] As used herein, the term "time of delivery" means when the data interacts with an application and/or the user 101 , including for example, any derivative(s) reaching a destination. For example, data may be considered to reach a destination at a mobile device 110 when the data (or derivative of the data) is output to the user 101 through one of the output interfaces on the mobile device 110, These output interfaces include, but are not limited to, the display screen and other user interface elements, the network, and the speakers.

[0031] By "tainting" or marking incoming data as the data is received at the mobile device 110, and monitoring the time it takes for the data to be consumed by the user, it is possible to assign different sensitivities to different data. This time to consumption can be used as an indicator that allows differentiation between pieces of information that are consumed quicker (e.g., immediately received and thus having a higher priority), and that data which is buffered in the mobile device 110. but not actuai!y consumed by the user until some later time when he or she decides to consume the data. Having an accurate understanding of this time, even when the time is an estimate based on prior data consumption patterns, ai!ows the program code 150 to assign sensitivity to incoming data and/or notifications of that data being available, and enables the program code 150 to provide a schedule for efficient information delivery that increases energy savings while providing a good user experience.

[0032] Figure 2 illustrates an example information flow in a mobile device 200. As mentioned above, the program code may be executed by any suitable computing device to identify access patterns for data received from a remote source, !n addition, the program code may be implemented via a proxy that serves more than one mobile device. For purposes of illustration, however, the following examples are described as the program code may be implemented on a so-called "smartphone" 200 running the Android® operating system 210 and using a taint-tracking infrastructure.

[00333 in an example, the taint-tracking infrastructure includes a taint module 220 that resides in a virtual machine component 230 of the operating system 210. The taint module 220 can taint incoming data 240 as soon as the network stack at the virtual machine level receives the incoming data 240. The network stack may be as "low" as the bare hardware, on up and including the application passing through the driver layer of the operating system and the virtual machine itself. Once tainted, it is possible to follow the flow of data 240 until the data 240 (or data derived from the incoming data 240} is utilized. For example, the data may be transferred to the network via a network interface 280a, delivered via output device 260b such as the speakers, and/or utilized (or "consumed") by an application 250 and/or outputting the data (or derivation of the data) to the user through a user interface (Ul) element 260c, as illustrated by arrows 245a-c respectively.

[00343 The taint module 220 is also able to track data (and/or derived data) that is written to internal storage 260d in the mobile device 200. For example, the taint module 220 may taint a target file or a target folder (or other target), so that the taint propagates even if the information is buffered in internal storage for later consumption and/or otherwise processed internal to the mobile device 200 before being consumed, as illustrated by arrow 245d.

[0035] The taint-tracking infrastructure is shown as an example and is not intended to be limiting. St is noted that other implementations for tracking data in the mobile device are also contemplated as being within the scope of the disclosed systems and methods.

[0036] In any event, data tracking may be used to identify data consumption patterns. As introduced above, these patterns may be used to determine a sensitivity of various types of data that may be received at the mobile device 200. Program code may be executed to generate a calendar to aggregate access to the notifications of data and/or the data itseif,

[00373 A example point of control for background services is in the push notification infrastructure found in the most common mobile operating systems. The push notification infrastructure provides a unified receiver responsible of handling incoming data from many different third-party service providers. In an example, a proxy for the notification infrastructure is implemented in the cloud. The proxy contacts the server side push infrastructure on behalf of the mobile device and enforces the generated schedule.

[0038] Figure 3 shows an example architecture of machine readable instructions implemented by a data proxy. The proxy 300 may be operatively associated (e.g., via a network) with mobile device(s) 310 and service(s) 320.

[0039] in an example, the program code discussed above with reference to Figure 1 ma he implemented in in the proxy 300 as machine-readable instructions (such as but not limited to, software or firmware). The machine- readable instructions may be stored on a non-transient computer readable medium and are executable by one or more processor to perform the operations described herein. It is noted, however, that the components are shown only for purposes of illustration of an example operating environment, and are not intended to limit implementation to any particular system and/or program code.

[0040] The program code may execute the functions described herein as self-contained modules. These modules can be integrated within a self-standing too!, or may be implemented as agents that run on top of an existing program code, in an example, the architecture of machine readable instructions may include a connectivity agent 330, which monitors connectivity of the mobile devices 310 and services 320. The machine readable instructions may a!so include a classifier 340, and push ciient 350.

[0041] During operation, the classifier executes with information provided by the mobile device(s) 310 to identify data consumption patterns on a particular mobile device. The classifier further determines sensitivity of data arriving at the mobile device based on the data consumption patterns. The push ciient 350 uses information provided by the classifier 340 to aggregate network access by background services executing on the mobile device 310 according to a schedule based on the sensitivity of the data arriving at the mobile device.

[0042] Accordingly, the proxy 300 may be used to reduce or altogether minimize the energy consumed by the mobile device 310 for data transfers, while still maintaining user-specified tolerances for delays in receiving data. That is, the approach aggregates data to reduce the energy spent in ramp up and tail energy by automatically classifying applications using the user's own tolerance of delay based on information flow control. For example, the protocol uses a scheduling algorithm that minimizes wakeup time and eliminates redundant retransmissions. While the approach delegates a portion of data retrieving to the cloud, instead of saving power only by performing the execution remotely, the systems and methods further save power by reducing the energy spent by the wireless radios.

[0043] it is noted that the design of program code allows existing applications to realize the benefits described herein with little to no modification. That is, by running a proxy over the mobile device platform, existing applications only redirect their associatio from the service push notification infrastructure to the proxy. This example design choice then provides functionality for interception, as opposed to modification, in addition, the approach described above can be implemented in an application agnostic manner. That is, the approach is not dependent o any type of application executing o the mobile device. The approach can also be tailored to the specific behavior of the user without explicit instructions from the user.

[00443 The proxy 300 may also implement pre-fetchsng. In an example of pre~feiching, the proxy 300 analyzes subsequent requests of data following an initial push notification. By analyzing this data, the proxy 300 can identify opportunities to pre-fetch data. For example, on an incoming e-mail notification, the proxy 300 may a!so run a clone 350a-d of an application, such as an email application to fetch the emails (or attachments to the emails) i advance of notifying the user, !n another illustration, the proxy 300 may scan for URLs in an email, and fetch the associated data from the Internet in advance of notifying the user. If the proxy 300 is associated with a personal {or enterprise) server in the cloud with knowledge about the user's connectivity, the proxy 300 can also intelligently push data from the user's server when the mobile device has a suitable connection (e.g., a Wi-Fi connection to the user's server).

[00453 ^!t is ^noteci that the proxy 300 is capable of pre-fetching data that is not necessarily rooted at the browser. That is, the proxy 300 does not start prefetching by analyzing browsing behavior, but rather by analyzing tolerance to latency of data from background services,

[0046] The proxy 300 analyzes information flow through the mobile device 310, and does not have to rely on protocol information, information payload, or statistical inference of traffic properties. In an xam le_: the proxy 300 may implement a sensitivity classifier to identify consumption patterns and determine sensitivity of data arriving on a mobile device. The proxy 300 can detect priority of each application without explicit feedback from the user, by learning from the actual consumptio patterns. For example, feedback that the system receives implicitly from the user can include, but is not limited to, whe the user disables audible or vibration alerts about certain elements, the notification consumption time and the content consumption time both increase organically because the device will not output any sound or vibration upon content being received, and the user will take longer to consume the notification. The system may also be used to infer the best user notification settings (when to use a sound alert, and when not to) depending on the latency sensitivity of the content. [0Q473 Nevertheless, this approach may be implemented orthogonal to other approaches, and may benefit from suc additional information,

[0048] Figure 4 shows an example latency sensitivity classifier 400. The classifier 400 may be implemented in program code and consider a number of data usage factors on the mobile device. For example, the classifier 400 may consider the identification of an application {or application ID 410) consuming the data. The classifier may also consider a protocol fingerprint 412, time 414, notification data 416 (e.g., content of the notification ), location 418 and/or any of a variety of other factors 420 related to arrival of the data, content of the data, and/or consumption of the data.

[0049] It is noted that the factors described above may be further delimited. For example, timing information that is considered may include a time when the data is consumed by the user and/or time when the data is consumed by the device (e.g., an application), making a clear distinction between the two times.

[00503 The classifier may automatically classify data using tolerance to delay by using information flow control. This approach may be implemented in an application agnostic manner, and tailored to the specific behavior of the user without explicit instructions,

[0051] The classifier may be used to determine sensitivity of data arriving at the mobile device, which can be used to generate a schedule 430. The schedule ma be used to aggregate data, for example, to reduce the energy consumed in ramp up and tasi energy. While delegating a portion of data retrieval to the cloud, the primary power savings is not by performing the execution remotely, but rather by aggregating data and thus reducing energy that would otherwise be spent using the wireless radios repeatedly (e.g., for retrieving each notification).

[0052] Identifying consumption patterns and determining sensitivity of data arriving on a mobile device can be better understood with reference to the following discussion of various example scenarios illustrated in Figures 5-7. The following examples illustrate use with a service that uses push notifications to notify a mobile application (or app) on the mobile device that new data is avaiiable. |0053| Figure 5 illustrates an example sequence of events 500 for an application without prefetching. When the service issues a push notification, the proxy 510 acts as an intermediary arid issues the push notification 511 to the mobile device 520. Upon receiving the notification at the mobiie device 520, the application notifies the user via interface 530 that the new data is available by issuing a push notification 521 (referred to as a "toast" or "toast notification"). Program code on the mobile device 520 measures a response time 531 until the notification is consumed by the user. The mobiie device 520 returns the response time 522 to the proxy 510.

[00543 Some applications include their entire pay!oad within the notification, while some request additional data from the application server after receiving the notification. The user may also send a follo up request 532 for more data related to the notification, which the mobile device 520 issues 523, either via the proxy 510 or directly to the service. For example, the user may request a status update on a social media site, or an attachment to an email message. The foiiow-up data 512 is returned to the mobiie device 520, and the follow-up data 524 is consumed by the user. Program code on the mobile device 520 measures a response time 533 until the follow-up data is consumed by the user. The mobile device 520 returns the response time 524 to the proxy 510.

[0055] These measurements can be used as a indicator of the user's sensitivity to the data of that particular notification. In an example, the proxy 5 0 can generate a schedule for issuing future push notifications to the mobile device based at least in part on sensitivity of the data. For example, a user may reply faster to email messages from a work email account during working hours, and not at all (or only infrequently) to email messages from a personal email account. But during non-work hours, the user may respond faster to email messages received on their personal email account Accordingly the schedule may hold push notifications from the user's personal email account during working hours, only allowing these push notifications to issue to the mobile device during designated times (e.g., the user's lunch break).

[0O56J These measurements may also be used to identify opportunities to bundle notifications and associated data, in addition to tracking the tolerance of delay for both the notification and the associated data. For example, a user may always open attachments associated with emaiis from co-workers (e.g., having the same email domain), but rarely open attachments associated with emaiis from outsiders (e.g., having a different email domain). Accordingiy, the schedule may automatically request attachments from the email service upon receiving a pus notification that a new email has arrived from a co-worker, and then bundle the push notification, the email and the attachment for sending to the user aii at the same time.

[00573 Figure 6 illustrates an example sequence of events 600 for an application with prefetching. This example shows a notification with the associated data fetched before user's reaction. That is, when the service issues a push notification, the proxy 610 acts as an intermediary and issues the push notification 811 to the mobile device 820. Upon receiving the notification at the mobile device 820, the application notifies the user via interface 630, that the new data is available by issuing a toast notification 621. The user sends a follow up request 831 for more data related to the notification, which the mobile device 620 issues 622, either via the proxy 510 or directly to the service. The follow-up data 812 Is returned to the mobile device 620, and the follow-u data 623 is consumed by the user. Program code on the mobile device 620 measures a response time 632 until the follow-up data is consumed by the user. The mobile device 620 returns the response time 624 to the proxy 810,

[0058] Again, these measurements can be used as an indicator of the user's sensitivity to the data of that particular notification. It is noted that in this example, however, that the time to consumption is given when the user consumes the associated data (not just the push notification). However, the program code is able to distinguish whether the user consumed the data of the notification or the follow up data. This allows the program code to distinguish between the user's reaction time to a notification {e.g., identifying that there are five new emails), and the consumption of a particular actual e-mail (e.g., from the user's supervisor).

[0059] Figure 7 illustrates an example sequence of events for instant messaging. It is understood that this example can also apply to other forms of instant (or substantially instant) consumption of notifications, and instant messaging is used only for purposes of illustration.

[ΟΟ8Ο3 Figure 7 illustrates the scenario where the notification includes the entire application payload, and so no further data requests are received. When the service issues a push notification, the proxy 710 acts as an intermediary and issues the push notificatio 711 to the mobile device 720. Upo receiving the notification at the mobile device 720, the application notifies the user via interface 730, that the new data is available by issuing a toast notification 721. Program code on the mobile device 720 measures a response time 731 until the notification is consumed by the user. The mobile device 720 returns the response time 722 to the proxy 710.

[00613 In this illustration, the response is not followed by incoming data. This is an example case of an application that may never exceed the notification size limit. A message has to have more than a predetermined number (e.g., 4000} of characters to go beyond the Sim it. For example, the response may have been the user sending a reply instant message. But these measurements can aiso be used as an indicator of the user's sensitivity to the data of that particular notification. For example, a user may reply faster to instant messages from work colleagues during working hours, and not at a!i (or only infrequently) to instant messages from friends. But during non-work hours, the user may respond faster to instant messages from friends,

[0062] in this scenario, the only consumption time tracked is consumption of the notification. However, it is still possible to track requests derived from the notification payload (e.g., embedded links) and apply prefetching techniques such as those discussed above.

[0063] Before continuing, it should be noted that the examples described above are provided for purposes of illustration, and are not intended to be limiting. Other devices and/or device configurations may be utilized to carry out the operations described herein.

[006 3 Figures 8a-c are flowcharts illustrating example operations which may implement scheduling data in background services. Operations 800 (Figure 8a), 801 (Figure 8b), and 802 (Figure 8c) may be embodied as logic instructions on one or more computer-readable medium. When executed on a processor, the logic instructions cause a genera! purpose computing device to be programmed as a special-purpose machine that implements the described operations, in an example, the components and connections depicted in the figures may be used.

[0065] An example of scheduling data in background services on mobile devices includes at operation 810 identifying data consumption patterns on a mobile device. In an example illustration by operation 812, identifying data consumption pattems may include distinguishing between a reaction time of the user to a notification of the data arriving at the mobile device, and reaction time of the user to actual data.

[0066] Operation 820 includes determining sensitivity of data arriving at the mobile device based on the data consumption patterns, in an example illustrated by operation 822, determining sensitivity of the data arriving at the mobile device is based at least in part on context of the data. In operation 824, the context of the data includes identifying at least a location of the mobile device, application consuming the data, and time. In another example illustrated by operation 828, determining sensitivity of the data arriving at the mobile device is by measuring the time after the data arrives on the mobile device until time of consumption. In operation 828, the time of consumption is determined based on when the data or a derivative of the data reaches a user via a output interface on the mobile device. It is noted that any of these operations may be used in combination with one another and/or in combination with other operations.

[0067] Operation 830 includes aggregating network access by background services on the mobile device according to a schedule based on the sensitivity of the data arriving at the mobile device. Operation 832 may include holding notifications of data available from the background services according to the schedule (e.g., those notifications whic are latency-tolerant}. As such, aggregating network access retrieves all held notifications at a predetermined time. As such, the mobile device does not have to retrieve notifications separately, and does not incur costs associated with separate retrieval (e.g., separate bandwidth and energy costs).

[0088] The operations shown and described herein are provided to illustrate example implementations, it is noted that the operations are not iimiied to the ordering shown. Still other operations may also be implemented.

[0069] In an example shown in Figure 8b, operation 840a may include tainting the data arriving at the mobile device, and 840b tracking the tainted data until the tainted data is deiivered to the user for determining the sensitivity of the data. In another example, operation 842a may include tainting the data arriving at the mobile device, and 842b tracking the tainted data until a derivation of the tainted data is delivered to the user for determining the sensitivity of the data. In yet another example, operation 844a may include tainting a target of the data arriving at the mobile device, and 844b tainting a derivative data propagating from the target. Again, it is noted that any of these operations may be used in combination with one another and/or in combination with other operations.

[0070] in another example shown in Figure 8c, operation 850 may include pre-fetching associated data based on scanning the data arriving at the mobile device. Operation 852 may include bundling the data arriving at the mobile device with the associated data for delivery to the user. Accordingly, the mobile device does not have to separately fetch the associated data when later requested by the user.

[0071] It is noted that various of the operations described herein may be automated or partially automated. For example, the operations may be implemented at least in part by using an end-user interface {e.g., web-based or "app" interface on the mobile device and/or via the proxy). In this example, the end-user is able to make predetermined selections, and the operations described above are implemented by one or more processor executing program code to present results to a user. The user can then make further selections.

[0072] The examples shown and described are provided for purposes of illustration and are not intended to be limiting. Still other examples are also contemplated.

Claims

1. A method of scheduling data in background services on mobile devices, comprising:

identifying data consumption patterns on a mobile device;

determining sensitivity of data arriving at the mobile device based on the data consumption patterns; and

aggregating network access by background services on the mobile device according to a schedule based on the sensitivity of the data arriving at the mobile device.

2. The method of claim 1 , further comprising distinguishing between a reaction time of the user to a notification of the data arriving at the mobile device, and reaction time of the user to actual data, for identifying data consumption patterns.

3. The method of claim 1 , further comprising holding notifications of data available from the background services according to the schedule, and wherein aggregating network access retrieves ail held notifications at predetermined times.

4. The method of claim 1 , wherein determining sensitivity of the data arriving at the mobile device is based at least in part on context of the data.

5, The method of claim 4, wherein the context of the data includes at least location of the mobile device, application consuming the data, and time.

8. The method of claim 1, further comprising measuring time after the data arrives on the mobile device until time of consumption for determining the sensitivity of the data.

7. The method of claim 6, wherein time of consumption is when the data or a derivative of the data reaches a user via an output interface on the mobile device.

8. The method of claim 1 , further comprising tainting the data arriving at the mobile device, and tracking the tainted data until the tainted data is delivered to the user for determining the sensitivity of the data,

9. The method of claim 1, further comprising tainting data arriving at the mobile device, and tracking the tainted data until a derivation of the tainted data is delivered to the user for determining the sensitivity of the data.

10. The method of claim 1, further comprising tainting a target of the data arriving at the mobile device, and tainting of derivative data propagating from the target.

11. The method of claim 1, further comprising pre-fetching associated data based on scanning the data arriving at the mobile device, and bundling the data arriving at the mobiie device with the associated data for delivery to the user, without having to separately fetch the associated data whe later requested by the user,

12. A system of scheduling data in background services on mobile devices, the system comprising machine readabie instructions stored on non-transient computef-readabie media and executable by a processor to;

determine sensitivity of data arriving at the mobile device based on data consumption patterns; and

aggregate network access by background services on the mobile device according to a schedule based on the sensitivity of the data arriving at the mobile device. 13, The system of claim 12, wherein the schedule balances energy savings and user experienc by reducing ramp energy and tail energy consumption by the mobile device for data transfer.

14, The system of claim 12, wherein the machine readable instructions are further executable by the processor to taint the data arriving at the mobile device to identify the data consumption patterns.

15, The system of claim 12, wherein the machine readable instructions are further executable by the processor to taint a destination of the data amving at the mobile device to identify the data consumption patterns.