A mobile computing device and method for maintaining application continuity

IS 2 440 331 T3

DESCRIPTION

Mobile computing device and method of maintaining application continuity

Cross reference to related cases

This application is related to the Applicant's provisional patent applications entitled: Mobile computing device and method with improved interrogation management (File number CML07453), filed May 21, 2009, which has US serial number 61 / 180,301; and Mobile computing device and method with intelligent push management (File number CS37274), filed on November 30, 2009, which has US serial number 61 / 265,211.

Field of the invention

The field of the invention relates to a mobile computing device and a method for maintaining application continuity.

Background of the invention

When operating a mobile device in synchronous communication with an application server, there is a trade-off between the smooth running of the application that requires more frequent data exchanges, for example a short sync interval, and the good battery life that it requires. less frequent data exchanges, for example a long sync interval.

The problem faced in this patent application is that, after a certain threshold period of communication inactivity between a server and a mobile computing device, the server will terminate the application, which can lead to data loss. desired. It would be an improvement in technique if, prior to the threshold period, a method of maintaining application could be devised.

Mobile computing devices, such as mobile or wireless stations, cell phones, radios, portable computers, wireless communication devices, and the like, operate with a power storage device with a limited power supply, such as a battery, fuel cell or the like. A mobile computing device needs a source of power, and in many cases this source of power is a battery. For example, cell phones use various types of batteries to operate. The amount of time a mobile station can typically operate before battery power is consumed (often referred to as "battery life"), is often an important criterion consumers use when choosing a brand or brand. one type of mobile computing device rather than another. The terms battery, energy storage device and power storage device are used interchangeably herein.

Although the power storage device is generally rechargeable, it may not be convenient or even possible for the user to recharge it. Accordingly, the useful operating time of a wireless computing device must be maximized.

Additionally, different operating environments can produce user surprise and / or frustration when the battery drains much faster than the user would ordinarily expect. Thus, unexpected short battery life or variation is highly undesirable from the user's perspective.

This is an especially relevant problem in mobile computing devices that run applications supported by an application server because of the power drain due to the wireless exchange of data between the mobile device and the server, since each upload or download consumes energy in the device. mobile device and server. The problem is especially acute in the mobile device, which is usually battery powered and has a finite amount of power. For example, a mobile device may employ an email server to upload and download email in support of an email application, a contact server to upload and download contact status in support of a social networking application, a information server for downloading movies, news, music, etc., in support of a media player application, and a copy / store server for uploading mobile device data in support of a data copy application. Typically, the mobile device and the application server synchronize regularly or periodically, that is, communicate, upload, download or exchange information at essentially regular or fixed time intervals, and herein, the data exchange between a mobile device running a application and an application server is called "sync", and the amount of time between data exchanges is called the "sync interval" or "sync interval", for a given application and an application server. Thus, it is necessary to increase the length of the synchronization interval, in order to save energy in a power storage device of a wireless computing device, such as a mobile station, in order to prolong the life of the storage device of power or battery.

IS 2 440 331 T3

In general, there is a trade-off between good application performance requiring more frequent data exchanges, i.e. a short sync interval, and good battery life requiring less frequent data exchanges, i.e. an interval of long sync. For example, the performance of an email application can be determined by the amount of time it takes to receive an email, and the performance of a social networking application can be determined by the delay in receiving a change in a state of social contact.

The data exchange with an application server can be initiated by the server, ie a "push" data service, or by the mobile, ie a "pull" data service. In the case of a "pull" data service, the mobile device typically provides a timer that can operate to trigger the expiration of the synchronization interval, at which time the mobile device can interrogate the application about the availability of new data from app. Thus, with a "pull" data service, the mobile device controls the synchronization interval, also known as the download or polling interval. Conversely, in the case of a "push" data service, the mobile device responds to synchronization requests from the server, which may or may not be periodic.

It is known to vary the synchronization interval according to the application, since the operation of some applications may be more sensitive to the synchronization frequency than others. The requirement for timely synchronization is also known to vary with the state of the application. Synchronization can also be initiated aperiodic by the application running on the mobile device, or by the user. Thus, when multiple applications are running, each application is likely to require different timing intervals, which may or may not be controlled by the mobile device.

Synchronizing an application with an application server involves uploading or downloading of application data between the mobile device and the application server over the communication infrastructure. Before the application data is exchanged with the application server, some startup activities have to be performed, such as powering the communication circuits, and establishing a data communication session with the communication infrastructure. Likewise, after the data is exchanged with the application server, some end activities have to be performed, such as terminating the data communication session with the communication infrastructure and cutting power to the data communication circuits. These start and end activities drain the mobile device's power. Thus, there is a tendency for uncoordinated synchronization that produces power drain due to the stop and start activities associated with each data exchange. Thus, start and stop activities must be minimized by coordinating synchronization times for multiple applications.

When operating a mobile device in synchronous communication with an application server, there is a trade-off between good application performance that requires more frequent data exchanges, i.e. a short synchronization interval, and good battery life that requires exchanges. less frequent data, that is, a long sync interval

It is known to vary the synchronization interval according to a schedule, such that the period between downloads increases when some applications are less likely to require frequent downloads. However, since the use of an application is human behavior, the optimal download period cannot always be foreseen and scheduled. Also, the power drain due to wireless data exchange with the application server can be unpredictable. Available wireless networks may be such that only data transmission methods requiring high power consumption are available. Therefore, the optimal synchronization interval cannot always be foreseen and programmed. Thus, a longer download synchronization interval or period must be provided to reduce energy consumption in some "latent times", while also providing shorter download synchronization intervals in "active times", when an application requires timely information.

In addition, a longer discharge synchronization interval or period must be provided to decrease power consumption when the energy required for synchronization is higher, while also providing a shorter discharge synchronization interval when the energy required for synchronization is lower, thereby taking advantage of favorable network conditions that may be temporary.

In connection with push applications, data is sent at a regular interval from an application server, and the requester is not aware of a method available in any mobile client to regulate the sending interval. An improvement in the technique would be considered if a mobile device could autonomously regulate the rate at which it would accept sent data. Furthermore, it would also be considered an improvement in the art that a mobile device could control applications in which data is sent from an application server to the mobile device.

Brief description of the drawings

Figure 1 is a block diagram of a system with improved interrogation management to reduce drain

ES 2 440 331 T3 of energy, according to the present invention.

Figure 2 is a flow chart of an example of an approach to improve interrogation management to reduce power drain, in accordance with the present invention.

Figure 3 is a series of timing diagrams illustrating the interrogation operation of a mobile computing device according to a first embodiment of the present invention.

Figure 4 is a series of timing diagrams illustrating the interrogation operation of a mobile computing device according to a second embodiment of the present invention.

Figure 5 is a block diagram of a mobile computing device providing increased battery life in accordance with the present invention.

Figure 6 is a flow chart of a mobile computing device running an application in synchronous communication with an application server according to an embodiment of the present invention.

Figure 7 is a simplified block diagram of a method of saving power in a mobile device running an application in synchronous communication with an application server, to reduce power drain, according to an embodiment of the present invention.

Figure 8 is a simplified block diagram of a method of saving power in a mobile device running an application in synchronous communication with an application server, to reduce power drain, according to an embodiment of the present invention.

Figure 9 is a simplified block diagram of a method of saving power in a mobile device running an application in synchronous communication with an application server, to maintain application continuity, according to an embodiment of the present invention.

Those of skill will appreciate that elements in the figures are illustrated for the sake of simplicity and clarity and are not necessarily represented to scale. For example, the dimensions and / or relative placement of some elements in the figures may have been exaggerated relative to other elements to help improve understanding of various embodiments of the present invention. Furthermore, common, but known elements that are useful or necessary in a commercially feasible embodiment are often not illustrated in order to facilitate a less obstructed view of these various embodiments of the present invention. It will also be appreciated that some actions and / or steps may be described or illustrated in a particular order of appearance although those skilled in the art will understand that such sequence specificity is not actually necessary. It will also be understood that the terms and expressions used herein have the ordinary meaning given to such terms and expressions with respect to their respective scopes of consultation and corresponding study, except when different specific meanings are set forth herein.

Detailed description of the preferred embodiments

A system and method is described that controls the length of the synchronization interval associated with a mobile computing device (or mobile station, wireless communication device, wireless computing device, mobile or wireless station, cell phone, radio, laptop, and the like; said terms are used interchangeably herein) that runs an application in periodic or synchronous communication with an application server, in order to conserve and improve the life of an energy storage device in connection with a mobile computing device. The approaches described herein allow a mobile computing device to operate under various conditions and provide various bandwidth intensive services without substantially compromising the energy storage device associated with the mobile station.

Coordination of the synchronization interval of the periodic or synchronous communication between the mobile computing device running multiple applications with respective application servers can be done in several different ways. In one example, the mobile device is equipped with an interrogation manager that: receives for each application an ideal interrogation interval and a tolerance window; monitors the communication activity of the mobile computing device; determines the elapsed time since the previous synchronization for each application; and synchronizes the application if the elapsed time since the previous synchronization is substantially equal to the ideal polling interval for the application, or communication activity is detected and the elapsed time since the previous synchronization is within the tolerance window for the application.

In another example, the polling manager: receives for each application an ideal polling interval and tolerance window; monitors the communication activity of the mobile computing device; determines the elapsed time since the previous synchronization for each application; selects a preferred sync interval between the elapsed time since the previous sync and a future sync interval, and syncs the app if the elapsed time since the previous sync is substantially equal to the interval of

ES 2 440 331 T3 ideal interrogation for the application, or communication activity is detected, the time elapsed since the previous synchronization is within the tolerance window for the application and is the preferred synchronization interval. The length of the synchronization interval can be dynamically decreased or increased from the ideal interval, depending on the monitored communication activity and the determined preference.

You can also make more adjustments. For example, the tolerance window for a first application can be adjusted depending on the ideal timing interval of a second application, as discussed in detail below.

Thus, methods are described whereby the power storage device of the mobile computing device is improved even under less than ideal operating conditions and different modes of operation, such as multiple applications running in synchronous communication with an application server. Consequently, the mobile computing device can operate under various operating conditions.

With reference to Figure 1, an example of a system with improved interrogation management for increasing the battery life of a mobile computing device is described. The system includes a first mobile computing device 102 that is coupled to a first radio access network (RAN) 104. The first RAN 104 is coupled to a communication infrastructure 106. The infrastructure may include a plurality of application servers, to run various applications, as discussed in detail below. A second mobile computing device 110 is coupled to a second RAN 108. The second RAN 108 is also coupled to infrastructure 106. The principles described here can be applied to a variety of wide area network systems, such as long-term evolution systems (LTE), ultra-wide mobile band (UMB), 802.16e and m, high-rate packet data (HRPD). ), or systems such as the Universal Mobile Communications System (UMTS), as well as wireless local area networks, personal area networks, and cable networks.

Mobile computing devices 102 and 110 can be any type of mobile wireless device. Mobile computing devices 102 and 110 include an interrogation management module 112 for coordinating synchronous communications between application server interrogation applications, as discussed in detail below. For example, mobile computing devices 102 and 110 can be cell phones, personal pagers, radios, mobile stations, personal computers, or personal digital assistants. As those skilled in the art should understand, other examples of mobile computing devices are possible.

RANs 104 and 108 can be any device or combination of devices that allows mobile computing devices 102 and 110 to access communication infrastructure 106. For example, RANs 104 and 108 can include access points, base stations, controllers base station, antennas, and other types of devices that facilitate such communications.

The communication infrastructure 106 preferably includes devices and / or networks that allow communication between mobile stations. For example, infrastructure 106 may include switches, servers, storage devices, and networks (eg, wireless networks, the Internet, land line telephone networks) that facilitate communications between mobile computing devices 102 and 110.

Referring now to FIG. 2, an exemplary method of improving interrogation management to extend the life of an energy storage device in a mobile computing device is shown. Method 150 is configured to help extend the battery life of a mobile computing device running a plurality of applications in synchronous or asynchronous data communication with an application server. Method 150 includes the steps of: providing 155 an interrogation manager configured to receive for each of the plurality of applications a predetermined interrogation interval and tolerance window; monitoring 160 the data communication activity of the mobile computing device; determining 165, for each of the plurality of running applications, the time elapsed since the previous synchronization; and synchronizing 170 the application if at least one of the following conditions occurs: the elapsed time since the previous synchronization is substantially equal to the predetermined polling interval for the application; and communication activity is detected, and the time elapsed since the previous synchronization is within the tolerance window for the application.

Advantageously, this method can provide substantial energy savings in an energy storage device in mobile computing device applications, for example by synchronizing and running multiple applications together, which saves battery or storage device energy by turning on the circuitry of the device. transceiver when necessary and minimizing or eliminating unnecessary or redundant synchronization, by using dynamic and intelligent interrogation management techniques, as discussed in detail here. This can be done by providing an interrogation interval for each application that is within its tolerance window, for example.

In one arrangement, synchronization step 170 is triggered by detecting synchronization activity initiated by at least one of: an application; an application server; and a user. This provides each application with the opportunity to synchronize with its respective application server in coordination with the activity of

ES 2 440 331 T3 communication detected. In more detail, the synchronization step 170 can be triggered substantially immediately after the termination of the detected synchronization activity, thus avoiding stopping and restarting of the communication circuits, and thereby saving energy.

With reference to Figure 3, four timings are depicted from top to bottom of the figure, at times zero, six, twelve and eighteen, respectively. App 1 has a sync interval of 24 units and a tolerance window of 11 units. Units can be in milliseconds. App 2 has a sync interval of 21 units and a tolerance window of 6 units. App 3 has a sync interval of 8 units and a tolerance window of 3 units. App 4 has a sync interval of 6 units and a tolerance window of 2 units. Referring to Figure 3a, at time 0, sync occurs for applications 1, 2, 3, and 4. At time 6, a synchronization takes place, triggered by the amount of time that elapses since the previous synchronization equal to the synchronization interval for application 4. Applications 3 and 4 are synchronized because they are the applications for which the tolerance window includes time 6. Referring now to Figure 3b, the tolerance window has been shifted from Figure 3a for applications 3 and 4, to account for the time of the previous synchronization that has changed from time 0 to time 6. In the time 12, a synchronization takes place, triggered by the amount of time that passes from the previous synchronization equal to the synchronization interval for application 4. Applications 3 and 4 are synchronized again because they are the applications for which the tolerance window includes time 12. Referring now to Figure 3c, the tolerance window has been moved from Figure 3b for applications 3 and 4 , to account for the time of the previous sync that has changed from time 6 to time 12. At time 18, a synchronization takes place, so applications 1, 2, 3 and 4 are synchronized because they are the applications for which the tolerance window includes time 18. Thus, the synchronization of the four applications is coordinated thereby reducing the power drain on the data communications device.

By utilizing intelligent interrogation management techniques, as discussed in detail herein, synchronizing and running multiple applications together can provide substantial energy savings. For example, the transceiver circuitry turns on at times 0, 6, 12, and 18, when needed to obtain a shock, etc. Referring again to Figure 3a, no unnecessary or redundant timings take place, as would occur at time 8, for example, if the timing for application 3 did not advance from time 8 to time 6.

In one embodiment, method 150 may include advancing the predetermined polling interval of a second application further within the tolerance window, to synchronize substantially immediately after a first application, as depicted at times 6, 12, and 18. in Figure 3, for example. This is beneficial since it can provide coordinated synchronization activity within the tolerance window for both applications.

In another embodiment, synchronization step 170 may be advanced or timed from its ideal or predetermined polling interval in the event that synchronization activity is detected within the tolerance window. This allows an application to synchronize immediately after communication operations that are not necessary for application server interrogation operations, such as an application server initiated synchronization, ie a "push" synchronization, or other communications. asynchronous such as triggered by a high priority application event or by the user.

In one embodiment, the predetermined polling interval is a maximum polling interval.

In one embodiment, method 150 may include increasing the predetermined polling interval when a connection to a certain network or application server is not available, thereby avoiding unnecessary or unsuccessful polling attempts, which saves energy.

In another embodiment, the method 150 includes regulating the predetermined polling interval outside the tolerance window based on a network condition, thereby reducing unnecessary timings when communication is especially costly from the standpoint of power consumption.

In more detail, in one embodiment, the network condition may include at least one of transmit power level, received signal level, received signal quality, modulation type, encoding level, and communication data rate. . These conditions can affect the power drain associated with each communication. For example, if the network requires a higher mobile device power level, it may be preferable to delay the synchronization outside the tolerance window.

In another embodiment, method 150 may include setting the predetermined polling interval outside of the tolerance window when a certain mode of communication is available. For example, in a cellular network providing third-generation service, for example broadband CDMA, as well as second-generation service, for example TDMA, the interrogation interval can be regulated outside the tolerance window if one of the services not available. For example, if the application typically uploads or downloads large files,

ES 2 440 331 T3 and higher bandwidth 3G service is not available, synchronization may be postponed. This feature provides flexibility to change the timing interval depending on the anticipated power drain which is a function of service availability and operating conditions.

In another embodiment, the communication mode may be at least one of a wired network communication mode, a wireless local area network communication mode, a wireless network communication mode, and an optical network communication mode. . Thus, the synchronization can be advanced, within or outside the tolerance window, if the communication mode is energy-intensive at an especially reasonable cost, such as a wired local area network (LAN) communication mode, or a wireless LAN.

Advantageously, these features allow the mobile computing device to load application data in coordination with other communication for other applications. For example, a first application could be a social network application such as facebook or twitter, and a second could be a data copy application. Social network applications, which include real-time communication of personal messages, status, and other personal data, are the highest priority application requiring periodic or synchronous server communications with a synchronization period or interval on the order of 10 minutes. . The data copy application is the lowest priority application requiring a sync interval on the order of 12 hours. The tolerance window for the data copy application is typically well over 10 minutes, the ideal polling interval for the social network application. Thus, the data copy synchronization takes place immediately after the synchronization of the social network application, after opening the tolerance window for the data copy application, for example. This is an opportune time from a power drain point of view, since unnecessary stopping and starting of communication circuits is avoided.

Referring again in more detail to Figure 3, where a first series of timing diagrams is depicted corresponding to an exemplary device running four applications in synchronous communication with an application server. Each time diagram illustrates the increasing time on the horizontal axis with a grid interval of 1 to 26. Thus, for a 30 minute grid interval, the 26 intervals on the horizontal axis represent 13 hours of operation. For each application there is a corresponding default sync interval and a default sync interval tolerance window. The first application has a default sync interval of 24 graticule intervals (for example 12 hours) and a tolerance window of 11. The second application has a default interval of 21 graticule intervals (for example 10.5 hours) and a tolerance window 6. The third application has a default interval of 8 grid intervals (for example 4 hours) and a tolerance window of 3. And, the fourth application has a default interval of 6 grid intervals (for example 3 hours) and a window of tolerance of 2. For each application, the tolerance window is defined that has a maximum time determined by the previous synchronization time plus the predetermined interval, and a minimum time determined by the maximum time minus the tolerance window. Referring now to time diagram 3a, startup takes place with the synchronization of the four applications at the lattice time T = 0. Thus, after synchronization to T = 0, the first application has a maximum time of 24 and a minimum time of 13, the second application has a maximum time of 21 and a minimum time of 15, the third application has a maximum time of 8 and a minimum time of 5, and the fourth application has a maximum time of 6 and a minimum time of 4. In the grid interval = 6 (for example 3 hours), the time reaches the predetermined interval for the fourth application, which triggers the data synchronization. Then each application is checked to determine if the time is between the minimum and maximum time, or, in other words, if the tolerance window is open. In this example, it is determined that the tolerance window is open for applications 3 and 4, and therefore applications 3 and 4 are synchronized with their respective application servers at time T = 6.

Referring now to diagram 3b, the tolerance windows have been redrawn for applications 3 and 4, taking into account the previous synchronization at time T = 6. In the grid interval = 12 (for example 6 hours), the time it reaches the predetermined interval for the fourth application, which triggers data synchronization, and each application is checked to determine if the tolerance window is open. The tolerance window is determined to be open for applications 3 and 4, and therefore applications 3 and 4 are synchronized with their respective application servers at time T = 12.

Referring now to diagram 3c, the tolerance windows have been redrawn for applications 3 and 4, taking into account the previous synchronization at time T = 12. In the grid interval = 18 (for example 9 hours), the time it reaches the predetermined interval for the fourth application, which triggers data synchronization, and each application is checked to determine if the tolerance window is open. The tolerance window is determined to be open for applications 1, 2, 3, and 4, and therefore applications 1, 2, 3, and 4 are synchronized with their respective application servers at time T = 18. Thus, the synchronization times of four applications are grouped together in such a way that the number of synchronization occurrences is minimized to 3 times in 18 lattice intervals, while in uncoordinated cases the number of synchronization occurrences could be up to 9.

In another arrangement, method 150 may include reducing the tolerance window for a first application when the predetermined polling interval for a second application is below a threshold. In the first

In the example above, the data copy application may have a tolerance window on the order of 2 hours. The synchronization for the data copy application is triggered by the communication activity of the social network application, which takes place every 10 minutes. Therefore, the synchronization of the data copy application takes place within the first 10 minutes of the opening of its tolerance window, thereby reducing the synchronization interval for the data copy application by an amount almost equal to the tolerance window. In situations like this, it is advantageous to reduce the tolerance window for the lower priority application to an amount in the order of the ideal timing interval of the higher priority applications.

In more detail, the reduction step may include providing a tolerance window for the second application, reduced from a predetermined tolerance window, when a predetermined polling interval received from the first application is below a threshold. In the example above, the tolerance window for the data copy application can be reduced from 2 hours to 10 or 20 minutes, which is once or twice the ideal 10 minute interval for the social network application. In more detail, the threshold can be proportional to the tolerance window received from the second application. For example, the threshold can be a fraction, such as 3/4, of the second application's default tolerance window. Thus, if the interrogation manager receives a tolerance window of two hours from the second application, and the ideal synchronization interval is less than 3/4 * 2 hours, or 1.5 hours, then the tolerance window for the second application can be reduced to one to two times the ideal interval for the first application, or 10 to 20 minutes.

In an alternative embodiment, method 150 for extending the battery life of a mobile computing device running a plurality of applications in synchronous data communication with an application server includes the steps of: providing a dispatch manager that has, for each application, a predetermined delivery interval and tolerance window; monitor the data communication activity of the mobile computing device; determining, for each application, the time elapsed since the previous synchronization; selecting a preferred synchronization interval, from at least the time elapsed since the previous synchronization and a future synchronization interval; and synchronizing the application if at least one of the following conditions occurs: a) the time elapsed since the previous synchronization is substantially equal to the predetermined polling interval for the application; and b) communication activity is detected, the time elapsed since the previous synchronization is within the tolerance window for the application and is the preferred synchronization interval. Thus, for a lower priority application that has a longer predetermined or ideal interval, synchronization can take place immediately after data communication for a higher priority application, or it can be postponed to a later time within the window. tolerance, thereby selecting a sync interval that is closer to the predetermined or ideal sync interval. The preferred sync interval may be the time that is closest to the predetermined download interval. It is noted that, in this embodiment, the tolerance window may be a two-sided window, whereby a selected sync interval for the lower priority application may be less or greater than the predetermined sync interval. In this case, the predetermined interval may be an ideal interval, and the synchronization may take place before or after the predetermined interval. Alternatively, the tolerance window can be one-sided and the predetermined interval is a maximum interval, in which case the synchronization interval is always advanced from the predetermined interval. Alternatively, the tolerance window can be one-sided and the synchronization interval is a minimum interval, in which case the synchronization is always delayed from the predetermined interval.

For an alternative embodiment of the second example, reference is made to Figure 4, where a first series of time diagrams corresponding to an exemplary device running four applications in synchronous communication with an application server is represented. Each of the applications has the same default interval and tolerance window as detailed in Figure 3, and the maximum and minimum synchronization times are calculated in the same way.

With reference to time diagram 4a, startup takes place with the synchronization of the four applications at the grid time T = 0. In the grid interval = 6 (for example 3 hours) the time reaches the predetermined interval for the fourth application. , which triggers data synchronization. Each application is then checked to determine if the tolerance window is open. Unlike the example of Figure 3, if the window is open, a preferred synchronization time is chosen from the present time or the next anticipated synchronization, which is the present time plus the predetermined minimum interval. In this example, the tolerance window is determined to be open for applications 3 and 4, and for both applications, the present time (T = 6) is preferred to the next anticipated synchronization time (T = 12) because the present time is closer to the predetermined time. Therefore, applications 3 and 4 are synchronized with their respective application servers at time T = 6.

With reference to diagram 4b, the tolerance windows have been redrawn for applications 3 and 4, taking into account the previous synchronization at time T = 6. In the grid interval = 12 (for example 6 hours) the time reaches the default interval for the fourth application, which triggers data synchronization, and each application is checked to determine if the tolerance window is open. In this example, the tolerance window is determined to be open for applications 3 and 4, and for both applications, the present time (T = 12) is preferred to the next anticipated synchronization time (T = 18) because the present time is closer to time

ES 2 440 331 T3 default. Therefore, applications 3 and 4 are synchronized with their respective application servers at time T = 12.

Referring now to diagram 4c, the tolerance windows have been redrawn for applications 3 and 4, taking into account the previous synchronization at time T = 12. In the grid interval = 18 (for example 9 hours), the time it reaches the predetermined interval for the fourth application, which triggers data synchronization, and each application is checked to determine if the tolerance window is open. The tolerance window is determined to be open for applications 1, 2, 3, and 4, and for applications 2, 3, and 4, the present time (T = 18) is preferred to the next anticipated synchronization time (T = 24) because the present time is closer to the predetermined time. For application 1, the present time (T = 18) is not preferred because the next anticipated synchronization time (T = 24) is closer to the predetermined time. Therefore, applications 2, 3 and 4 are synchronized with their respective application servers at time T = 18.

Referring now to diagram 4d, at the grid interval = 24 (for example 12 hours) the time reaches the predetermined interval for the fourth application, which triggers data synchronization, and each application is checked to determine if the tolerance is open. The tolerance window is determined to be open for applications 1, 3, and 4, and for applications 1, 3 and 4, the present time (T = 24) is preferred to the next anticipated synchronization time (T = 30) because the present time is closer to the predetermined time. Therefore applications 1, 3 and 4 are synchronized with their respective application servers at time T = 24. Thus, analogously to the example in figure 3, the synchronization times of four applications are grouped together in such a way that the number of synchronization occurrences is minimized, and in this example for applications that have large tolerance windows and intervals Longer presets, synchronization takes place closer to the predetermined interval, reducing the frequency of synchronization for that application, and thus reduces energy drain.

In one embodiment, the synchronization interval includes an interval for which the number of applications having overlapping tolerance windows is a local maximum. In this way, the timing can be determined simply. This involves counting the number of applications for which the time is within the tolerance window, not triggering the synchronization when the count is increasing or is constant, and firing the synchronization when the count is reduced, as will happen when the time exceeds a tolerance window for an application. Referring again to the examples in Figure 3 and Figure 4, the number of overlapping windows is represented as a series of numbers above each time diagram, and the synchronization takes place in the lattice interval where the series is maximum.

In more detail, the future synchronization interval can be determined by adding the shortest predetermined polling interval of each of the running applications to the time elapsed since the previous application. Thus, in one arrangement, the polling manager may also be configured to receive for each of the plurality of applications an ideal polling interval, and the step of selecting may further include selecting the interval that is closest to the ideal polling interval. , for the reasons detailed above.

Also, in one arrangement, the predetermined polling interval is a maximum polling interval, as detailed above. In an alternative embodiment, the step of selecting a preferred sync interval includes querying the application as to which sync interval is the preferred interval. In this case, the application can simply select the range that is closest to the default or ideal range, or it can select the preferred range based on other criteria. This provides an advantage because the selection criteria can change depending on the state or context of the application.

In one embodiment, the optimal synchronization interval includes an interval for which the number of applications having overlapping tolerance windows is a local maximum.

The term application, as used herein, can include at least one email, instant messaging, social media, news, gaming, media upload (for example photo upload), media download (for example for example, music downloading), and data copying, or any other application that requires data synchronization or otherwise has regular communication with an application server.

In another embodiment, the method 150 may include providing a mobile computing device in synchronous application server communication for a first application in a first synchronous communication interval, and in synchronous application server communication for a second lower priority application in a second nominal interval of synchronous communication, equal to the first interval of synchronous communication by a nominal integer, where the nominal integer is the integer part of a predetermined interval for the second application divided by the predetermined interval for the first application.

In more detail, synchronization step 170 may include synchronous communication including at least one of uploading application data from a mobile computing device to an application server and downloading application data to the mobile computing device from an application server.

IS 2 440 331 T3

Advantageously, these features allow the mobile computing device to upload application data to a server, when network conditions or other power determining factors are favorable. For example, the first application could be a social network application such as facebook or twitter and the second could be a data copy application. Social network applications, which include real-time communication of personal messages, status and other personal data, is the highest priority application that requires periodic or synchronous communications from the server with a synchronization period or interval on the order of 10 minutes . The data copy application is the lowest priority application requiring a sync interval on the order of 12 hours. In this example, over the course of 12 hours while the social network application syncs on the order of 72 times, network conditions can vary significantly. For example, the RF power level of the wide area network may vary due to the variation in path loss between the mobile device and the network base station, or due to network traffic, or due to switching to a network with different capabilities, such as to a different wide area network, or a local area network. Thus the data copy synchronization can take place at the most opportune times from the point of view of power drain, tolerance windows, communication network conditions and other conditions vary.

Referring now to FIG. 5, an exemplary block diagram of a mobile computing device 200, such as mobile computing devices 102 or 110, is depicted in accordance with one embodiment. Mobile computing device 200 may include a housing 210, an energy storage device 215, a controller 220 coupled to housing 210, audio input and output circuitry 230 coupled to housing 210, a display 240 coupled to housing 210, one or more transceivers 250 coupled to housing 210, a user interface 260 coupled to housing 210, a memory 270 coupled to housing 210, an antenna 280 coupled to housing 210, and a removable Subscriber Identity Module (SIM) 285 coupled to controller 220. Mobile computing device 200 employs controller 220 and memory 270 to run applications in synchronous communication with an application server via transceiver 250. Mobile computing device 200 further includes an interrogation manager 290, coupled to controller 220. In more detail, the interrogation manager 290 may reside within controller 220, it may reside within memory 270, it may be a standalone module, it may be an application, it may be software, it may be hardware, or it may be in any other format. Useful for a module in a 200 wireless communications device. In one embodiment, polling manager 290 may be defined as a controller for coordinating application server communication, based on polling intervals and nominal tolerances for each application.

The display 240 may be a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, or any other means for presenting information. Transceiver 250 may include a transmitter and / or a receiver. The audio input and output circuitry 230 may include a microphone, a speaker, a transducer, or any other audio input and output circuitry. User interface 260 may include a keyboard, buttons, a touch pad, a joystick, an additional screen, or any other device useful for providing an interface between a user and an electronic device. Memory 270 may include random access memory, read-only memory, optical memory, or any other memory that may be coupled to a wireless communications device.

In more detail, in one embodiment, the mobile computing device 200 with an energy storage device of Figure 5 includes: a housing 210; a controller 220 coupled to housing 210, controller 220 being configured for applications in synchronous communication from one or more application servers; memory 270 coupled to controller 220; a wireless transceiver 250 coupled to the controller 220 to synchronize application data between the mobile computing device 200 and the one or more application servers (which could reside in the infrastructure 106 of FIG. 1); and an interrogation management module 290, the interrogation management module being configured to: receive for each of the plurality of applications a predetermined interrogation interval and a tolerance window; monitor the data communication activity of the mobile computing device; determining, for each of the plurality of running applications, the time elapsed since the previous synchronization; and synchronizing the application if at least one of the following conditions occurs: the time elapsed since the previous synchronization is substantially equal to the predetermined polling interval for the application, and communication activity is detected, and the time elapsed since the previous synchronization is within the tolerance window for the application. Advantageously, the interrogation management module 290 can allow the mobile computing device 200 to dynamically manage communication with running applications. This arrangement can provide a longer lifespan for mobile computing devices before a user power storage device 215 has to be recharged. It is beneficial that the interrogation management module 290 can serve to coordinate communication activity and thereby reduce unnecessary starting and stopping of communication circuits, such as transceiver 250, thereby prolonging the life of the storage device. of energy in applications of mobile computing devices.

In one embodiment, the polling management module 290 includes: a processor configured to poll and synchronize applications; and a throttle module configured to advance or delay the predetermined polling interval of a second application within the tolerance window, to synchronize substantially immediately after a first application, for further power savings.

IS 2 440 331 T3

In one embodiment, the polling management module 290 is further configured to: receive with respect to each of the plurality of applications an ideal polling interval; and selecting an interval that is closer to the ideal polling interval, for greater power savings.

In one embodiment, the present invention is incorporated into the communication infrastructure, and in another, it can be incorporated into a wireless communication device. More specifically, the interrogation management module 290 can be incorporated into a mobile computing device 200 or alternatively to the infrastructure 106. Other arrangements are possible, such as the inclusion of both.

In more detail, controller 220 includes an application processor for executing application programs. Application programs can be stand-alone programs or programs that run in communication with an application service, in which case the application program is called an application service daemon. Each application that runs in synchronous communication with an application server can have a corresponding application service daemon that runs on controller 220. Alternatively, the application service daemon may run on any component of the mobile device 200 that has application processing capability including display 240 which may include an intelligent display controller, transceiver 250, memory 270, SIM 285, or memory module. interrogation management 290.

In another embodiment, the polling management module 290 provides a stand-alone push management function, to regulate the rate at which the mobile device receives "sent" data from an application server. In a preferred embodiment, the communications of an application service are interrupted during latency periods. More specifically, module 290 may further be configured to provide a scheduler (not shown) to provide, set, or determine latency periods. Synchronous communications that are normally "sent" by the application server to the mobile device can be suspended during scheduled latency periods, thereby reducing the power drain by idling the transceiver 250 during these periods. Power drain can be further reduced by application service daemon idling during these periods.

Accordingly, the mobile computing device can utilize various power consumption applications and services with different timing requirements, while maintaining and improving the life of an energy storage device of a mobile computing device. Due to the method, structure and methods described and detailed here, the user experience can be significantly improved.

Referring to FIG. 6, a flow chart 600 of a preferred embodiment according to the present invention is depicted. The process starts at node 605 from which the process branches to the simultaneously running applications 610. At 610 four running applications are illustrated: email, news communication, photo upload, and data copy, which have the application number A = 4, 3, 2 and 1, respectively. Each application writes a predetermined interval, Int (A) in a 615 interrogation interval register, and a predetermined tolerance window Win (A) in the 620 tolerance windows register. These defaults can be changed by the application depending on the application status. For example, the email application can reduce the interval during business hours, or the news communication application can increase its interval when the user is actively reading the news. The start node also branches to the interrogation management process (in slide) 625, beginning with initialization 635 which is set the following counters for each application:

Tprevious (A) = 0

Tm¡ „(A) = Int (A) - Win (A)

Tideal (A) = Int (A)

T = 0.

The process follows decision diamond 640 where it is determined whether the communication is currently active. If in the decision diamond 640 the communication is not active, or "No", then the process continues to set the application counter 645 to A equal to the number of applications running, Appcount, which in this example is equal to 4. From there, the process goes to decision diamond 650 where it is determined whether for application A the present time T is equal to Tideal (A). If in the decision diamond 650 it is determined that T = Tideal (A), it is determined that synchronization should take place and the process proceeds to set the second application counter 655 to A 'equal to the number of applications running, Appcount. Also, at decision diamond 640, if it is determined that communication is active, or "Yes," the process continues to set the second application counter 655 to A '= Appcount. The process continues to decision diamond 660 where it is determined whether T> Tmy (A '). If it is decided that T> TMin (A '), or “Yes”, the process continues to synchronize application A' 665 and then to reset 670 of the timers for application A ':

IS 2 440 331 T3

Tprevious (A ') - T

T_Min (A ') = T + lnt (A') - Win (A ')

You_FROMTO^?) -T + Int (A ')

The process continues to decrement the counter A '675, followed by the decision diamond 680 in which it is determined if A' = 0. If in the decision diamond 680 it is determined that A '= 0, or "Yes", the process continues to decrement A '685, followed by decision diamond 690 where it is determined if A = 0. If in 690 it is determined that A = 0, or "Yes", the process continues to delay box 695. From box 695, the process continues to increase T in box 697, and from there the process returns to decision diamond 640. If in 640 it is determined that the communication is active, or “Yes”, the process jumps to put the second application counter in box 655 to A '= the number of running applications, Appcount. If in decision diamond 660 it is determined that T ^ TMin (A '), or "No", the process jumps to decrement box A' 675. If in decision diamond 680 it is determined that A '^ 0, or "No", the process returns to decision diamond 660. If in decision diamond 690 it is determined that A ^ 0, the process continues to decision diamond 650. Flow control for alternative embodiments can be demonstrated in a similar way.

Referring to FIG. 7, an embodiment of a method 700 of saving power in a mobile device running an application in synchronous communication with an application server is depicted. In its simplest form, it includes the steps of: 710 operating an application in synchronous communication with an application server through a persistent Internet Protocol (IP) session, defining an active mode, where synchronous communication is automatically enabled by establishing an IP session persistent according to a pre-configured schedule; and providing 720 a dormant mode where synchronous communication is automatically disabled in the mobile device by closing the persistent IP session according to the previously configured schedule. In an alternate embodiment, method 700 includes the step of programming 730 a user programmable latent mode scheduler to program the latent mode period. Advantageously, a user can provide off-peak or quiet times (latent mode) and / or peak or active times (active mode) using a programmable scheduler.

Referring back to FIG. 1, infrastructure 106 typically employs firewall techniques to disable the establishment of TCP / IP connections to mobile devices from the Internet. This helps prevent or minimize mobile devices receiving spurious Internet traffic that would cause an unwanted power drain. Thus, no application server can generally establish an IP session with the application server. It must be set from the mobile device. Mobile devices 102 and 110 can initiate an IP session by communicating with an Internet gateway (not shown) in wireless infrastructure 106. In a preferred embodiment, an IP session, including a Transfer Control Protocol / Internet Protocol (TCP / IP) connection, may be initiated by a mobile device 102 or 110 by activating a Packet Data Protocol (PDP) context. with Internet gateway in the wireless infrastructure 106. The PDP context defines a single IP address by which the application server can communicate with the mobile device.

After establishing a TCP / IP session, the session remains active for an amount of time determined by a session timer on the application server or the Internet gateway on the wireless infrastructure 106. If there is no more communication from the mobile device , the session remains open until the session timer expires, and then the TCP / IP connection is closed. This advantageously allows the server to stop sending application data if the client goes out of service, without gracefully closing the TCP / IP connection, as is often the case with mobile device clients for various reasons including weak signal conditions, and sudden loss of power. battery.

Each communication from the client mobile device with the application server causes the session timer to be reset. The mobile device can maintain a persistent IP session by sending stay alive messages to the application server at intervals less than the session expiration time period. The session expiration period is determined by the server or gateway, and is typically 30 minutes. Thus, the application server is able to send, or "push", application data to the mobile device while the IP session remains active.

Sometimes when application data is "not needed", the mobile device can prevent data from being "sent" by changing the PDP context. In more detail, the mobile device can close the TCP / IP session by sending a TCP / IP connection header including the connection token 'close'. This closes the TCP / IP session, depriving the application server of a connection over which it can send application data.

Advantageously, energy can be saved in the mobile computing device, thereby prolonging the life of an energy storage device or a battery. Through the use of intelligent push management,

ES 2 440 331 T3 can achieve substantial energy savings by using pre-programming of the latent and active modes.

Thus, PDP protocols and TCP / IP or UDP persistent session protocols are adapted to reduce power drain on the mobile device. For a more detailed definition of persistent TCP / IP operations, see the Hypertext Transfer Protocol (HTTP) 1.1 specification document published under the RFC2616 specification, by the Internet Society.

In a preferred embodiment, step 710 includes receiving push notifications from the application server during the persistent IP session. In another arrangement, operation step 710 may include keeping the persistent IP session active by periodic stay-alive messages from the mobile device to the application server.

Provisioning step 720 may include closing the persistent IP session, thereby terminating additional push notifications. Advantageously, this feature allows the mobile device to schedule latent or quiet times and active times, independently of the application server. In another embodiment, provisioning step 720 may include closing the persistent IP session allowing the session to expire, not sending a stay alive message from the mobile device to the application server.

In more detail and in a preferred embodiment, method 700 may include a stand-alone push management function in module 290, for example. It can be considered when data communication is “needed” or “not needed”, and specifies the triggers to enter an active mode, where an application program is running in communication with the application server, and to enter a quiet or latent in which synchronous communication is stopped or interrupted.

In a preferred embodiment, a PDP context is necessary when operating in a peak period. Thus, special attention is given to the always-on user experience, and the PDP context is maintained, and as long as there is at least one active TCP or UDP session. On the other hand, the PDP context is not necessary when operating in an off-peak or latent period, when the application can be sacrificed in favor of reduced power drain. In this case, the pDp context is released, unless some user activity is detected. For example, when the user has an active application (either in the background or in the background) that maintains a persistent TCP socket, the PDP context will be required.

In more detail, a preferred PDP context management strategy may include the following:

1. When the mobile device connects to a power supply, the PDP context will always remain active. A power supply could be a battery charger, or an AC power adapter, or a host device such as a personal computer that provides power through a connection, such as a universal serial bus (USB) connection.

two. When the mobile device draws its power from an internal battery during a peak period (active mode):

If the PDP context is set, it will remain set as long as there is at least one active TCP or UDP session.

If the PDP context is set and all TCP and UDP sessions are disabled, the PDP context will be released.

If the PDP context is not established and an application makes a request for a new TCP or UDP session, the PDP context will be established. If the PDP context is not established, it will remain unset as long as there is no active TCP or UDP session.

3. When UE is battery operated and during off-peak period:

When the screen turns off (no user activity), the PDP context will be released and will remain released as long as no user activity is detected and the off-peak period does not end. When the screen is turned on (user activity is detected), the PDP context will be set and will remain set until the screen is turned off again.

Alternatively, the PDP context can be maintained or reset in off-peak hours if an active user discovery state is detected.

Examples of active user detection are detecting an active user interface such as a screen, touch screen, keyboard, or backlight; detecting movement of or near the device, such as movement or acceleration of the device itself, or of an object near the device; and detecting a wireless connection to the device such as a wireless headset activation.

In a preferred embodiment, the method 700 may further include maintaining other communications between the mobile and other communication entities in the active and latent modes. Advantageously, this feature makes it possible to turn off

ES 2 440 331 T3 certain communications, such as social network applications, while other application servers are turned on. For example, method 700 may further include maintaining other communications between the mobile and other communication entities, while in the dormant mode, the other communications including at least one of voice communications, short message service communications, and communications. data, using a different IP session from the persistent IP session with the application server.

With reference to FIG. 8, a system 800 with intelligent push management for increasing the battery life of a mobile computing device is described and depicted. System 800 may include mobile computing devices 810 and 812 that are coupled to a wireless communication infrastructure 820. The wireless infrastructure includes a packet data switched connection 822, such as a subscriber gateway service node (SGSN) found in a general packet radio service (GPRS) infrastructure. The wireless infrastructure 820 may also include a loopback 822 for connecting voice applications as well as connecting legacy data applications such as short message services (SMS). The 810 and 812 mobile devices can be configured to connect, via an 822 Internet gateway on the 820 wireless infrastructure, to a front end 832 of 830 application service aggregation servers, and a stand-alone 840 application server over the Internet . The application service back end 836 of the aggregation server 830 connects via the Internet to stand-alone application servers 850 and 860. The application aggregation server 830 includes a data cache 834 for storing application data to and from the application servers 850 through the back end 836, for eventual transmission through the front end 832 and the wireless infrastructure 820 to and from mobile clients 810, 812. Mobile devices 810 and 812 can also be configured to communicate over wireless infrastructure 820 using a circuit-switched infrastructure 824. Circuit switched infrastructure is used for legacy communication services such as voice calling, short message services (SMS), and circuit switched data services. The principles described here can be applied to various broad area network systems, such as long-term evolution (LTE), ultra-wide mobile band (U MB), 802.16e and m, high-rate packet data (HRPD) systems. ), or systems such as the Universal Mobile Communications System (UMTS), as well as wireless local area networks, personal area networks, and cable networks.

Mobile computing devices 810 and 812 can be any type of mobile wireless device. Mobile computing devices 810 and 812 include an intelligent push management module 112 or 290 for coordinating synchronous communications between application server polling applications, as discussed in detail below. For example, mobile computing devices 810 and 812 can be cell phones, personal pagers, radios, mobile stations, personal computers, or personal digital assistants. As those skilled in the art will understand, other examples of mobile computing devices are possible.

The 810 and 812 mobile devices can connect to the 820 wireless infrastructure using radio access networks (RANs), as depicted in Figure 1. RANs can be any device or combination of devices that allows the 810 and 810 mobile computing devices 812 have access to the communication infrastructure 820. For example, RANs can include access points, base stations, base station controllers, antennas, and other types of devices that facilitate such communications.

The communication infrastructure 820 preferably includes devices and / or networks that allow communication between mobile stations. For example, infrastructure 106 may include switches, servers, storage devices, and networks (eg, wireless networks, the Internet, land-line telephone networks) that facilitate communications between mobile computing devices 810 and 812 and Internet devices such as such as 830 and 840 application servers.

The application service aggregation server 830 performs the function of the periodic polling application servers 850 and 860 for new data, and then provides the application data to the mobile devices 810 and 812 through the packet data switch 822 in wireless infrastructure 820. For example, application servers 850 and 860 may be conventional social network applications, such as Facebook, Twitter, and the like. The aggregation server 830 may request status notifications to social contacts on the Facebook service, and new messages on the Twitter service. It saves the new data in memory and makes it available to the mobile device via wireless infrastructure with push or pull methods, as detailed here.

Mobile devices 810 and 812 can be configured to simultaneously connect to multiple data servers and the methods described herein include maintaining communications between a mobile device and a first application server, while in a dormant or quiet mode with a second data server. app. For example, mobile devices 810 and 812 can connect via an Internet gateway 822 on the wireless infrastructure 820, to a service aggregation server 830, and can also connect to a standalone application server (s) 840 , bypassing the application service aggregation server 830. The standalone application server may be an email application such as Gmail, for example.

The methods described here can include maintaining communications between the mobile and the autonomous server of

ES 2 440 331 T3 e-mail application, while in the dormant mode of suspension of communications with the aggregation server 830, for example. This can be done by establishing different PDP contexts between the mobile device and the wireless infrastructure to connect to the different services, and applying the latency triggers differently to the different PDP contexts. For example, connections to standalone application server 840 may remain active during off-peak or quiet hours when connections to aggregation server 830 are closed.

Conversely, for simplicity and user convenience, a single policy and latency scheduler can be applied to different application services with different PDP contexts. Thus, in a latent mode communication, communications with all data servers may be suspended, even though different PDP contexts are used. In this way, a latent mode that is very effective in reducing power drain can be conveniently programmed.

In a preferred embodiment, voice communications and short message service communications are not affected by the closure of PDP contexts, since these may employ the circuit-switched infrastructure 824 in the wireless infrastructure 820, not requiring a PDP context.

In a preferred embodiment, an automatic mode controller may be provided, where the mobile device switches to active mode when user activity is detected. Advantageously, this feature provides a user override function to allow the user to instantly enter the active mode, when desirable.

In more detail and as an example, the detected user activity may include at least one of: detecting movement near the mobile device; detect a key press; detect the touch of a touch screen; detect that a screen is active; and detect an incoming communication. Advantageously, this allows the user to use an application during a preprogrammed quiet or off-peak time, without having to reprogram quiet times.

In another example, method 700 may include providing an automatic mode controller where the device is switched to active mode when the device is connected to a load device. A charging device can include at least one of an AC adapter, a battery charger, and a host device. A host device can include a PC, or any device that provides a DC power supply through a data connector such as a USB connector. A battery charger can be a wired or wireless power source.

In another example, method 700 may include providing an automatic mode controller where the device is switched to active mode when a communication is received. The communication can be an incoming communication from the cellular network, a local area network, or from a personal area network device such as a wireless headset.

In another example, method 700 may include providing an automatic mode controller where the device is connected to an accessory device. For example, the accessory device could be a wired or wireless charger, a power supply, an AC adapter, a battery charger, a user interface device such as an external mouse, touch controller, an audio or acoustic device, a data cable, or an external memory device.

In one embodiment, method 700 may include operation step 710 including operating an application processor on the mobile device, and suspending operation of the application processor. Similarly, in another arrangement, operation step 710 may include operating an application service daemon in an application processor on the mobile device, and suspending the operation of the application service daemon. Advantageously, this provides reductions in power drain due to disabling, idling, or reduced application processor operations.

In another embodiment, method 700 may include the steps of: operating 710 an application in synchronous communication with an application server via a persistent IP session, defining an active mode; providing 720 a latent mode where synchronous communication is disabled on the mobile device; and programming 730 a user programmable latent mode scheduler for programming the latent mode period. Advantageously, a user can provide quiet times (latent mode) and / or active times (active mode) using a programmable scheduler. This allows a mobile device to operate in a personalized way, based on various user preferences, personalities and programs.

In a preferred embodiment, as depicted in FIG. 5, a mobile computing device 200 is shown. It may include: a housing 210; a controller 220 coupled to housing 210, controller 220 being configured to execute applications in synchronous communication from one or more application servers; memory 270 coupled to controller 220; a wireless transceiver 250 coupled to controller 220 to synchronize application data between mobile computing device 200 and the one or more application servers; Y

ES 2 440 331 T3 a push management module 290 configured to: operate an application in synchronous communication with an application server through a persistent IP session, defining an active mode, where synchronous communication is automatically enabled by establishing a persistent IP session according to a previously configured program; and providing a latent mode where synchronous communication is automatically disabled in the mobile device by closing the persistent IP session according to the previously configured schedule. Advantageously, the mobile computing device 200 provides energy savings and longer battery life, resulting in a better user experience. Advantageously, energy can be saved in the mobile computing device, thereby prolonging the life of an energy storage device or a battery. Through the use of intelligent push management, substantial energy savings can be achieved, using pre-programming of the latent and active modes.

In Figure 5, block 290 says "Interrogation Management Module"; however, in the above embodiment, the module is in the form of a "push management module".

In one embodiment, the push management module 290 includes a user programmable latency timer for programming the latency period, which helps extend battery life as previously detailed.

In one embodiment, the push management module 290 is further configured to maintain other communications between the mobile computing device 200 and other communication entities such as voice services or data services to entities with different PDP contexts, as previously detailed. In this way, the user can individually select or set applications to be dormant during off-peak or quiet hours.

In one embodiment, the push management module 290 is configured to switch to active mode when certain user activity is detected. This override feature allows the user to instantly switch to active mode, if desired.

In one embodiment, the push management module 290 may include one or more of the features previously detailed with respect to method 700, for a better user experience.

A potential problem arises if the amount of time in latent mode exceeds a limit on the application server to run the application in the absence of communication, ie in zero communication, with the client mobile device. Referring now to FIG. 9, a method of saving power is depicted in a mobile device running an application in synchronous communication with an application server 900. The application has a null threshold communication period to maintain application continuity. Method 900 may include the steps of: operating 910 the application in synchronous communication with an application server, defining an active mode, where synchronous communication is automatically enabled; providing 920 a dormant mode where synchronous communication is automatically disabled on the mobile device for a predetermined duration; and interrupt 930 dormant mode by momentarily communicating with the application server prior to the threshold communication null period, to maintain application continuity.

Advantageously, before a threshold period of communication inactivity, the latent mode is interrupted, to maintain the connectivity of the application, thus the server will not stop the application and no data will be lost.

For example, referring to FIG. 8, the mobile client device 810 is running applications in synchronous communication with a front end 832 of the application service aggregation server 830. Meanwhile, a rear end 836 of the application service aggregation server application 830 is in communication over the Internet with one or more application servers 850 and 860. For example, application server 850 is the Twitter service. When the client mobile device 810 is dormant to save power, it stops communicating with the front end of the application service aggregation server 830. Meanwhile, the back end of the aggregation server service 830 continues to accept new data or information, from the application servers 850 and 860, and storing the data in a data cache 834, for eventual forwarding to the client mobile device 810 through the end Forward 832 of Application Service Aggregation Server 830.

The problem is that the application service aggregation server 830 may suspend the service after a period of time in which there is no communication with the mobile client device 810. This may be necessary in order not to waste memory, processing and communication resources for customers who have stopped using the service. Advantageously, before a threshold period of communication inactivity, the dormant mode can be interrupted, to maintain the connectivity of the application, thus the application service aggregation server 830 will not stop the application and no data will be lost.

For example, the back end 836 of the application service aggregation server 830 can continue IP communication with a Twitter service from the application server 850, for example, and store incoming messages, or Twitter 'tweets', in the cache. 834 data for a period T after stopping communication

ES 2 440 331 T3 with the customer's device. For example, T can be 2 to 4 hours. In this case, the application service aggregation server 830 stops storing new messages, and can also delete existing messages. Thus, a latency period greater than T results in data loss.

Thus, in this example, it may be beneficial to provide, before a communication inactivity threshold period, that the latent mode is interrupted, to maintain application connectivity, so that the application service aggregation server 830 will not stop the application. and avoid data loss.

The method is applicable to various applications. In another example, application server 860 is a news communication service. When the client mobile device 810 is dormant to conserve power, it stops communicating with the front end 832 of the application service aggregation server 830. Meanwhile, the back end 836 of the service aggregation server 830 continues to accept news from the application servers 860, and cache data 834, for eventual forwarding to the mobile client device 810 via the front end 832 of the server. application service aggregation 830. The application service aggregation server 830 may suspend service after a period of time when there is no communication with the mobile client device 810. It may stop storing news data, delete stored news data, or it may continue to store new data while deleting older data. In either case, data will be undesirably lost. Advantageously, before a threshold period of communication inactivity, the dormant mode can be interrupted, to maintain the connectivity of the application, thus the application service aggregation server 830 will not stop the application and no data will be lost.

For example, the back end 836 of the application service aggregation server 830 can continue IP communication with the news communication service from the application server 860, for example, and store incoming news stories in the data cache 834. , for a period T after stopping communication with the client device. For example, T can be 10 hours. In this case, the application service aggregation server 830 stops storing new messages, and can also delete existing messages. Thus, a latency period greater than T results in data loss.

Thus, in this example, it may be beneficial to provide, before a communication inactivity threshold period, that the latent mode is interrupted, to maintain application connectivity, so that the application service aggregation server 830 will not stop the application. and avoid data loss.

Stated differently, in the example above, it may be advantageous to prevent server 830 from exiting applications due to long periods of suspended communications with client mobile device 810, by briefly resuming communication with server 830 at a periodic interval less than time expiration date T of the application.

For example, if the mobile client device 810 starts a latency period of 8 hours, and if the expiration period T of the application is 3 hours, the mobile client device 810 would send a "stay alive message" to the server 830. in an interval of less than 3 hours. The stay alive message can be similar to the existing message used to keep the TCP / IP session active in non-latent mode. The stay alive message can be a request to reset or increase the value of an application inactivity timer. It can be a request to control idle timers for all currently running applications, or to continue the operation of one or more operations. Alternatively, the message can be a message requesting the continuity of one or more specific applications, and it can specify an amount of time that the application should remain active during an idle period, such as zero communication. In addition, a time limit of other controls may be useful, such as a data storage limit, a processing resource utilization limit, a channel bandwidth limit, and so on. As such, the stay-alive message may contain data fields to identify applications or groups of applications, and to bring a limit below which the application must remain active, such as an amount of time, or an amount of data that a application can store, an amount of storage capacity, processor resources for example microprocessor cycles or MIPs, or channel bandwidth that an application can use during an idle period, such as zero communication. For example, there may be a limit to the amount of data stored in cache 834.

Advantageously, in a preferred embodiment, mobile client device 810 may autonomously implement latency mode to reduce power drain in latent mode. In addition, the mobile client device 810 can send a stay alive message in a period less than the application expiration time period, thereby maintaining application continuity during latency periods greater than the application time period. application expiration.

In one embodiment, operation step 910 may include establishing a persistent IP session with the application server and receiving push notifications from the application server on the persistent IP session, the provisioning step includes closing the persistent IP session and thereby terminating further. push notifications, and the break step includes establishing and closing a persistent IP session. In this way, the mobile client device 810 can notify the application server 830 that it is still present and needs application services, despite an outage.

ES 2 440 331 T3 in communications that could otherwise be interpreted as a power failure of the mobile device 810 or as an exit from the network.

In one scenario, in provisioning step 920 and interrupt step 930, the persistent IP session can be closed by sending a TCP / IP connection header including a close connection token according to the HTTP 1.1 standard. Advantageously, this feature can provide conformance to a standard. Thus, the mobile client device 810 can gracefully close the TCP / IP session while maintaining application continuity on the server 830 for immediate resumption of service after a long period of communication inactivity in order to save power.

In one arrangement, the IP session has a threshold null communication period to maintain the persistence of the IP session, and in operation step 910, the persistent IP session is kept active by momentarily communicating with the application server prior to the null period of threshold communication, to maintain the desired IP session.

In another embodiment, operation step 910 includes receiving push notification over a non-IP channel and provisioning step 920 includes sending a control message to the application server, whereby the push notification can be stopped. Advantageously, this feature anticipates application services that do not depend on the persistent IP session being kept active by the client mobile device. For example, if USSD were used to send data, it would be appropriate to open an IP session only to request data (eg download) from the server, and to close the IP session after each download operation. In this case, the client mobile device would initiate a dormant mode by sending a control message 'stop sending data indefinitely' or 'stop sending data until a designated time'. Other limitations are possible in addition to time limitations, such as processor, memory, or bandwidth limits on the 830 server.

In one embodiment, the mobile device runs a first and second application in synchronous communication with the application server. Each application can have a zero threshold communication period to maintain application continuity. In this case, the interrupt step 930 would occur at the expiration of a latency timer set at a value less than the threshold null communication period to maintain application continuity for the first and second applications.

In another arrangement, method 900 may include maintaining other communications between the mobile and other communication entities in the active and latent modes, to enhance the user experience.

In another arrangement, method 900 may provide an automatic mode controller where the device is switched to active mode when user activity is detected, for a better user experience.

In one embodiment, method 900 may include programming a user programmable latent mode timer, to allow the user to program a desired latent mode period.

In a preferred arrangement, as depicted in FIG. 5, mobile computing device 200 may include: a housing 210; a controller 220 coupled to the housing, the controller 220 being configured to execute applications in synchronous communication from one or more application servers, each application having a zero threshold communication period to maintain application continuity; memory attached to the controller; a wireless transceiver 250 coupled to the controller 220 to synchronize application data between the mobile computing device and the one or more application servers; and a push management module 290 configured to: operate an application in synchronous communication with an application server, defining an active mode; provide a latent mode where synchronous communication is automatically disabled on the mobile device according to the previously configured schedule; and interrupt dormant mode by momentarily communicating with the application server before a threshold null communication period, to maintain application continuity. Advantageously, before a threshold period of communication inactivity, the latent mode is interrupted, to maintain the connectivity of the application, so the server will not stop the application and no data will be lost.

In a preferred embodiment, mobile computing device 200 may include: push management module 290 including a user programmable latent mode scheduler to schedule the latent mode period; the push management module being further configured to maintain other communications between the mobile and other communication entities in the active and latent modes; the push management module being configured to switch to active mode when certain user activity is detected; and the push management module includes a latency timer programmed to a value less than the shortest maximum null communication period to maintain application continuity for each application, and the interrupt step occurs at the expiration of the latency timer , for better functionality, as previously detailed.

Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above-described embodiments without departing from the broad scope of the invention, and that such modifications, alterations, and combinations are to be considered included within the scope of the invention.