CLIAMS:
We claim:
A method of updating application data running in background whenever a network activity being detected in foreground application in a communication device, the method comprising:
identifying one or more requests for pre-fetching data packets from the one or more applications by a prefetch manger;
analyzing the data packets based on a pre-defined instruction by a packet data analyzer module, on event of detection of a foreground data application traffic;
classifying data packets of foreground network activity and respective prefetch time slot by a classifying module; and
pre-fetching the data packets of the one or more applications to the server by a prefetch manager.

The method as claimed in claim 1, wherein the request for pre-fetching is received for one or more data packets from the one or more applications running in background of the communication device.

The method as claimed in claim 1, wherein pre-fetching the data packets of one or more applications running in the background during a time slot in which foreground application is performing one or more activities.

The method as claimed in claim 1, wherein the step of pre-fetching the data packets of the one or more applications is performed in such a way that time period for wireless radio communication transmission is reduced.

The method as claimed in claim 1, wherein the step of pre-fetching the data packets of the one or more applications is performed in such a way to reduce frequency of radio communication wake-ups.

The method as claimed in claim 1, wherein analyzing the data packets based on a pre-defined instruction comprises:
identifying length of data activity; and
classifying the data activity in small to medium length data activity.

The method as claimed in claim 1, wherein identifying one or more data packets to be pre-fetched comprises prioritizing the data activity based on the length of data activity.

The method as claimed in claim 1, wherein pre-fetching the one or more data packets based on learning consistent with data transmission pattern.

The method as claimed in claim 1, wherein pre-fetching the one or more data packets based on user initiated data transmission patterns in consolidation with default wireless radio communication time.

The method as claimed in claim 1 further comprising pre-scheduling periodic requests in order to sync one or more applications by initiating requests with precise and shorter time slots prior to actual sync schedule.

The method as claimed in claim 1 further comprising predicting device idle state patterns based on user device usage history.

The method as claimed in claim 1 further comprising prefetching one or more data packets of the one or more applications when there is an opportunity of radio wakeup due to keep alive traffic and GCM push message.

A system for updating application data running in background whenever a network activity being detected in foreground application in a communication device, the system comprising:
a packet data analyzer module for identifying length of data activity and classifying the data activity in small to medium length data activity;
one or more pre-fetch predictor modules connected to the packet data analyzer module and one or more applications for notifying pre-fetch time slot to pre-fetch the one or more data packets; and
a sync manager connected to the packet data analyzer module and the one or more applications for synchronizing one or more applications with one or more server on a wireless network.

The system as claimed in claim 13, wherein the packet data analyzer module comprises
a preprocessor for collecting meta-data information in the form of URL, IP-port, Application ID, time stamp, and response time;
a classifying module connected with the preprocessor for classifying the each data packet as one of a small, medium and large by examining data pattern and packet content; and
a prediction engine connected to the preprocessor for calculating pre-fetch time slot based on network usage.

The system as claimed in claim 13, wherein the one or more pre-fetch predictor modules comprises
a network packet sniffing module for analyzing foreground application originated data packet and predicting lifetime of the ongoing data traffic;
the network packet sniffing module analyzes the device terminated packets such as GCM packets and push messages;
a pre-fetch request module associated with the one or more applications for analyzing the requests to be pre-fetched;
a ranking module for prioritizing the data packet to be pre-fetched based on length of request; and
a device state module for predicting state of device, the state includes idle state and active state.

The system as claimed in claim 15, wherein the network packet sniffing module notifies the expected lifetime of the ongoing foreground data transmission to the prefetch request module associated to each of application,
the ranking module decides the prefetch URL request and trigger network request to server based on received prefetch time slot.

Dated this the 3rd day of July 2015

Signature

KEERTHI J S
Patent Agent
Agent for the Applicant ,TagSPECI:
FORM 2
THE PATENTS ACT, 1970
[39 of 1970]
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(Section 10; Rule 13)

METHOD AND SYSTEM FOR PREFETCHING USER PREFERRED APPLICATION DATA TO ENHANCE USER EXPERIENCE AND POWER SAVING

SAMSUNG R&D INSTITUTE INDIA – BANGALORE Pvt. Ltd.
# 2870, Phoenix Building, Bagmane Constellation Business Park,
Outer Ring Road, Doddanakundi Circle,
Marathahalli Post,
Bangalore -560037, Karnataka, India
Indian Company

The following Specification particularly describes the invention and the manner in which it is to be performed
FIELD OF THE INVENTION

The present invention generally relates to communication device and more particularly relates to method and system for pre-fetching background application’s updates with current ongoing foreground data transmission. It also involves of opportunistic prepone of synchronization of one or more applications running in a communication device.

BACKGROUND OF THE INVENTION

Communication devices, such as smart phones, run various applications such as for example, but not limited to Instant Messaging (IM) applications, emails, Social Network Services (SNSs). These applications running in the communication devices are capable of synchronizing application data through a network. Since the communication device has a plurality of applications, the application data traffic is frequently generated which results in rapid consumption of battery power.

The nature of applications running on the mobile device is such that one application is always on the foreground which has the user attention. However, there are several background applications running which is not immediate user interest but user might be using those applications frequently.

Every background application that running is of reasonable importance to the user in terms of usability. Based on the access patterns of these applications, the user would reuse the application. Some applications fetch server update during application start up on user attention to application.

The application update in the conventional communication system has following limitations:
Periodic radio wakeup which causes battery drain tremendously.
Network data fetching delay to display updated data on application start up.

Therefore, there is a need of a method and system for performing predictive prefetching of one or more data packets of one or more applications running in a communication device.

SUMMARY

An embodiment of the present invention describes a method of updating application data running in background whenever a network activity being detected in foreground application in a communication device. The method comprises identifying one or more requests for pre-fetching data packets from the one or more applications by a prefetch manger, analyzing the data packets based on a pre-defined instruction by a packet data analyzer module, on event of detection of a foreground data application traffic, classifying data packets of foreground network activity and respective prefetch time slot by classifying module, and pre-fetching the data packets of the one or more applications to the server by a prefetch manager.
In one embodiment, analyzing the data packets based on a pre-defined instruction comprises identifying length of data activity, and classifying the data activity in small to medium length data activity. The pre-defined instruction includes but not limited to analyzing the data packets based on length of data activity.
Another embodiment of the present invention describes a system for updating application data running in background whenever a network activity being detected in foreground application in a communication device. The system comprises a packet data analyzer module for identifying length of data activity and classifying the data activity in small to medium length data activity, one or more pre-fetch predictor modules connected to the packet data analyzer module and one or more applications for determining pre-fetch time slot to pre-fetch the data packets, and a sync manager connected to the packet data analyzer module and the one or more applications for synchronizing one or more applications with one or more server on a wireless network.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The aforementioned aspects and other features of the present invention will be explained in the following description, taken in conjunction with the accompanying drawings, wherein:

Figure 1 illustrates a block diagram of a system for prefetching application data in a communication device, according to an embodiment of the present invention.

Figure 2 illustrates a scenario where multiple small to medium traffic generating applications exist with persistent TCP connections, according to an exemplary embodiment of the present invention.

Figure 3 illustrates a block diagram of pre-fetch packet data analyzer module, according to an embodiment of the present invention.

Figure 4 illustrates a flow diagram of a method of predicting pre-fetch request list from one or more applications running in a communication device, according to an embodiment of the present invention.

Figure 5 illustrates a method initiating pre-fetch request by one or more applications running in the background in a communication device, according to an embodiment of the present invention.

Figure 6 illustrates a flow diagram of a method of delivering prefetch data to the application running in a communication device, according to an embodiment of the present invention.

Figure 7 illustrates a flow diagram of a method of whitelisting of pre-fetchable applications, according to an embodiment of the present invention.

Figure 8 illustrates a block diagram of a pre-fetch application data sync module, according to an embodiment of the present invention.

Figure 9 illustrates a flowchart of a method of synching prefetch data, according to an embodiment of the present invention.
Figure 10 illustrates a flow diagram of a method of determining state of the device according to an embodiment of the present invention. a flowchart of a method of synching prefetch data, according to an embodiment of the present invention.
Figure 11 depicts the ON and OFF period of the device screen for 3 days to determinate of device inactive period according to an embodiment of the present invention.
Figure 12 illustrates a flowchart of a method of synching prefetch data, according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The embodiments of the present invention will now be described in detail with reference to the accompanying drawings. However, the present invention is not limited to the embodiments. The present invention can be modified in various forms. Thus, the embodiments of the present invention are only provided to explain more clearly the present invention to the ordinarily skilled in the art of the present invention. In the accompanying drawings, like reference numerals are used to indicate like components.

The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Figure 1 illustrates a block diagram of a system 100 (application data prefetch architecture) for prefetching application data, in a communication device according to an embodiment of the present invention. The system 100 comprises one or more applications 101, one or more prefetch predictor modules 102, a packet data analyzer module 103, and a sync manager 104. Additionally, the system 100 comprises a socket library 105 (which provides functional API’s to communicate to the end server using transport layer protocol to fetch networks data) and a kernel 106 which manages I/O (input/output) requests from software, and translates them into data processing instructions. The person ordinary skill in the art knows the kernel, so description of kernel is not required. All application data update requests goes through a HTTP library which includes the pre-fetch predictor module 102. The pre-fetch predictor module 102 does a request interception and builds a pre-fetchable URL Database and registers to pre-fetch time slot notifications with the packet data analyzer module 103 to get prefetch start notification.

The system 100 analyses URL for all the running applications and prepares database of pre-fetch URL list and data transmit-receive completion time. On receipt of pre fetch time slot notification, the prefetch predictor module 102 prefetch a desired URL fitting to time length criteria.

Exemplary URLs and data transmit-receive time are given in below table

Pre fetch URL Data transmit-receive time (seconds)
https://graph.facebook.com
1
https://android.clients.google.com 2

The Packet data analyzer module 103 decides the length of ongoing network data activity with the help of real-time packet inspection from the socket library 105 and selectively broadcasts the pre fetch time slot to all the registered modules (which includes all the applications that intend to prefetch data packets and store it in cache)

An exemplary format of Broadcasted data is given below:

e.g. <> , << file, large ,20, 12.30.05>>

The Sync Manager 104 registers for pre-fetch time slot notification to update the application sync data packets (e.g contact sync, gallery sync).

In one embodiment the present invention, the one or more pre-fetch predictor modules comprises a network packet sniffing module for analyzing foreground application originated data packet and predicting lifetime of the ongoing data traffic. The network packet sniffing module also analyzes the device terminated packets such as GCM packets and push messages. Additionally, the network packet sniffing module notifies the expected lifetime of the ongoing foreground data transmission to the prefetch request module associated to each of application. The pre-fetch request module is associated with the one or more applications for analyzing the requests to be pre-fetched. The ranking module prioritizes the data packet to be pre-fetched based on length of request. The ranking module also decides the prefetch URL request and trigger network request to server based on received prefetch time slot. The device state module predicts state of device, which includes idle state and active state.

Figure 2 illustrates a scenario where multiple small to medium traffic generating applications (e.g. Whatsapp, Facebook etc) exist with persistent TCP connections (e.g. Play Store), according to an exemplary embodiment of the present invention. In this exemplary embodiment, there are multiple radio wake ups at different instances of time which is due to both controlled (Apps) and uncontrolled Traffic (Keep alive, GCM etc). There exists an evident opportunity to utilize available radio resource of uncontrolled traffic efficiently by pre-fetching the necessary app data. The uncontrolled traffic means urgent data communication initiated by application (such as keep alive) and/or on user interaction (such as Chat) and asynchronous Push/Cloud notifications. The controlled traffic means periodic application synchronization and application data updates on user attention which can be controlled (prepone/postpone) without affecting user behavior.
Network requests by applications in a communication device (such as Smartphone) have high impact on a battery power. Some of the data requests are small in nature but have to be served on priority as it is user initiated. Typically, Instant Messenger services involve user’s active interaction followed by a possible waiting time due to the social context of wanting a reply back or a mutual chatting rhythm. During the active chat time, the cellular radio is in the active state but for probably small amount of time. Using this opportunity supported by predicting of a small to medium length of radio-active state, the background applications can send pre-fetch data request within the length of radioactive state of foreground data activity.

In another scenario, using the opportunity of short or medium lived uncontrolled traffic, the application data can be pre-fetched and cached in application context. Later point of time when application is launched updated data would be provided to user instantly.

Figure 2 shows the radio wake ups and data update comparison for conventional method and the present method wherein the data is prefetched for the applications based on opportunity available during uncontrolled traffic such as chatting, keep-alive message and push notification etc.

In the conventional method, a total of 10 radio wake ups occurs due to 6 uncontrolled traffic and 4 controlled traffic (as shown in figure 2(a)). Using a pre-fetching mechanism for controllable traffic with current ongoing foreground data transmission, the number of radio wake up reduces to 6 (as shown in figure 2(b)). Additionally, the most frequent usage application data can be pre-requested with utmost minimal effect on the reduction of power due to explicit radio wakeup.

Further, the present invention solves explicit utilization of network and system resources for a background activity, where applications do network data syncing in background based on a pre-defined periodicity.
Figure 3 illustrates a block diagram of a packet data analyzer module, according to an embodiment of the present invention. The packet data analyzer module 103 analyses the data to perform traffic classification and predict pre-fetch time slot. Here the packet data analyzer module 103 intercepts socket requests from the socket library and passes through following modules such as a preprocessor module 301, classifying module 302, and a prediction module 303. The preprocessor module 301 collects the meta-data information in the form of URL, IP-port, application ID, time stamp, response time etc.. The Classifying module 302 classifies the packet type as Small to Medium (chat message, GCM) and Large (voice, streaming, file transfer) by examining data pattern and packet content. The prediction module/engine 303 calculates prefetch time slot based on network usage and notifies to all registered modules.
Figure 4 illustrates a flow diagram of a method of determining prefetch request list from one or more applications running in a communication device, according to an embodiment of the present invention. At step 401, one or more URL requests are received at the prefetch predictor module 102. The prefetch predictor module 102 classifies the URLs into pre-fetch able URLs and non-prefetch able URLs and stores the pre fetch able URLs into Database. At step 402, a check is performed whether the request can be pre-fetched. If the request cannot be pre-fetched, the request is forwarded to the socket library. If the request can be pre-fetched, URL request information is updated (which includes pre-fetch URL list, and network usage time). At step 404, the updated URL request information is forwarded to the socket library.

Figure 5 illustrates a method of initiating prefetch request by one or more applications running in the background in a communication device, according to an embodiment of the present invention.

Figure 5a illustrates a block diagram of a system for prefetching application data, according to an embodiment of the present invention. The system comprises an application (App1) 101, a prefetch predictor module 102, and a packet data analyzer module 103. Additionally, the system 100, by default, comprises kernel 106 which manages I/O (input/output) requests from software, and translates them into data processing instructions. The prefetch predictor module 102 comprises a prefetch manager 501, a prefetch URL database 502, and a prefetch response cache 503. The prefetch manager 501 manages the prefetch requests and their corresponding responses. The prefetch URL database 502 stores the list of prefetch request received from the applications. The prefetch response caches 503 stores the response for each prefetch request received from a server on a wireless network.

Figure 5b illustrates a method of initiating a pre-fetch request according to an embodiment of the present invention. In one embodiment, the prefetch predictor module 102 has registered for time slot notifications. At step 501, the pre-fetch time slot notification (pre-fetch time length of data activity) is received from the Packet Data analyzer. On receiving the pre-fetch notification and time slot, at step 502, the prefetch predictor module 102 selects the URLs to be pre-fetched and trigger the corresponding network requests. The pre-fetch URL is selected from a pre-fetch URL database 502 or based on timestamp base pre-fetch URL (i.e. start-end time). At step 503, the request to pre-fetch is initiated and sent to the server through the socket library.

Figure 6 illustrates a flow diagram of a method of delivering prefetch data to the application running in a communication device, according to an embodiment of the present invention. At step 601, an application (App3) 101 is opened by the user and simultaneously an URL requested is initiated and sent to a request handler 607 by the application. At step 602, a check is performed with the prefetch URL database 502 to determine whether the URL request matches with a prefetch URL list in the prefetch URL database 502. If yes, at step 603, the URL request is sent to prefetch manager 501. At step 604, the prefetch manager 501 receives the prefetch response from the prefetch response cache 503. At step 605, the prefetch manager 501 also initiates a request with a server through the kernel 106 for remaining update of data, if any. At step 606, the prefetch manger 501 delivers response to the application (App3) 101.

Figure 7 illustrates a flow diagram of a method of whitelisting of pre-fetchable applications, according to an embodiment of the present invention. The applications such as Facebook®, Twitter®, email etc. register for periodic updates (i.e. contact sync, gallery sync) with an alarm manager 701 to perform periodic sync activities. The Whitelist is populated on every alarm registration with an alarm monitoring unit 702 from the one or more applications 101. The whitelist entry is removed on deletion of the alarm from the alarm manager (i.e. application is uninstalled or alarm is removed). The Whitelist provides meta-data information (i.e. alarm, application name) to the packet data analyzer module 103.
Figure 8 illustrates a block diagram of a pre-fetch application data sync module 800, according to an embodiment of the present invention. The pre-fetch application data sync module 800 comprises one or more applications 101, an alarm manager 701, an application sync manager 104 and a packet data analyzer module 103. The application sync manager comprises a scheduler module 801, a sync controller 802, and a notification receiver 803. The alarm manager 701 registers the alarm with the scheduler module 801 for synchronizing the one or more applications with the server. The alarm manager 701 controls the registered alarms by scheduling them along with foreground data activity or GCM /keep alive messages. The application list in the scheduler module 801 is updated based on alarm deletion or change in sync interval. The packet data analyzer module 103 analyses the data packet and provides input to the notification receiver 803. The Sync controller 803 receives the prefetch time slot notification from the packet data analyzer module 103 and takes the decision of sending the sync adjustment to the scheduler module 801.

Figure 9 illustrates a flowchart of a method of synching prefetch data, according to an embodiment of the present invention. At step 901, prefetch sync request is received. At step 902, alarm list is received from a scheduler. At step 903, sync period of each alarm is determined. At step 904, the last sync time of each alarm is received. At step 905, a check is performed whether pre-fetch sync decision of the alarm is required. If no, stop the process. If yes, at step 906, alarm sync notification is sent. At step 907, the last sync time is saved and the next expiry time is adjusted.

Figure 10 illustrates a flow diagram of a method of determining state of the device according to an embodiment of the present invention. The monitoring and policy module 1001 monitors screen on/off notification to determine time periods during which the communication device is inactive. The determined inactive time period of the communication device is stored in the storage unit 1002 which is subsequently provided to the alarm scheduler 801. When the alarm manager 701 receives a request to register alarm, the request is processed and included in the alarm list so that the alarm should not fall during the device inactive time period. In case the alarm has expired, the alarm expiry notification is provided to the application.

Figure 11 depicts the ON and OFF period of the device screen for 3 days to determinate of device inactive period according to an embodiment of the present invention. The device inactive period and idle time are used in the specification interchangeable. The determination of device inactive period includes two stages as mentioned below:
Tracking Screen Lock duration

At the first stage, the statistics data are monitored and stored for at least 3 days based on screen OFF event and screen ON event. The screen OFF duration is checked and compared. If the screen OFF duration is greater than threshold idle time, the time duration is placed in device inactive period queue or idle time slot (ITS) queue.

For example, last 3 days data
1st day Queue ? ITS1( 00.00, 07.00), ITS2(14.00, 17.30), ITS3(20.00,23.00)
2nd day Queue ? ITS1(23.00, 06.00), ITS2(14.30, 17.50)
3rd day Queue ? ITS1(00.20, 08.00), ITS2(14.30,17.20), ITS3(20.00,23.00)

Device inactive time period (Idle time slot) decision:

At the second stage, a check is performed to determine overlapping time period of different time slots. If common idle time period exists for 3 different days and it’s greater than threshold idle time, the common time period is stored as the device inactive period or idle common time slot in Idle time slot queue.

For example:
ITS QUEUE ? ITS1(00.20 ,06.00) , ITS2(14.30-17.20)

Figure 12 illustrates a flowchart of a method of synching prefetch data, according to an embodiment of the present invention. In an embodiment, the screen off notification is received and the current time falls during device inactive period. At step 1201, frequency of update is decided. If frequency is 2, intermediate sync time is decided. If frequency is 1, final sync time is decided. At step 1202, a check is performed whether update frequency is greater than 1. If no, at step 1203, the alarm to final sync queue is added. At step 1204, the alarm intermediate sync queue is added. At step 1205, background data is monitored in sync window. In another embodiment, intermediate time/final sync time is received at step 1206. At step 1207, a check is performed whether radio wakeup happened in sync window. If yes, at step 1208, the time for radio wakeup and synchronization is noted and the alarm expiry time is adjusted at step 1209. At step 1210, scheduled alarm list is updated. At step 1211, alarm notification is sent to application.

In another embodiment, screen ON event notification is received and current time falls in device inactive period. At step 1212, a list of postponed alarms is checked and notification is sent to the applications for alarm expiry.

There is opportunity to save radio activity by streamlining data sync activity along with non-periodic background data e.g. GCM push notification etc. Also in device idle condition, if user is not using the device for long duration (2-3 hrs) then Application data sync in intermediate times is not much benefit for user (sleeping time, school time, match time). This can be optimized by monitoring the device idle time slot pattern and maintaining a list of idle-time slots and thus reducing the application network data synchronization during these idle periods.

Calculation of Final SYNC TIME

Final Sync Time=ITS-ITS*0.05
Here, ITS = Idle Time Slot

Calculation of Intermediate SYNC Time

At first the highest repeating alarm is determined, (i.e. smallest repeated interval)
Then, the Sync points before the Final Sync are given by,
i.e. Intermediate SYNC Time = Smallest Interval × Floor (Log [ (2^NE-1)/2])
Where NE= Number of expiry of smallest Interval Alarm in ITS,
Number of Expiry NE= (Idle Time Slot)/(Smallest Alarm Interval)
And it is valid if and only if |(Intermediate SYNC Time)-Final SYNC Time|