METHOD OF SAVING ENERGY IN A MOBILE DEVICE AND MOBILE COMPUTING DEVICE

专利摘要:
mobile computing device and method to maintain application continuity. A method of maintaining continuity of the application (900) and mobile computing device (200) are described. the method involves a mobile device running an application in synchronous communication with the application server. the application has a zero communication period limit to maintain application continuity. the method (900) may include the steps of: operating (910) the application in synchronous communication with an application server, setting an active mode, in which synchronous communication is automatically activated; providing (920) a sleep mode in which synchronous communication is automatically disabled on the mobile device for a predetermined duration; and interrupting (930) the sleep mode by momentarily communicating with the application server before the zero communication period threshold, to maintain application continuity. as an advantage, before a timeout period of communication inactivity, sleep mode can be stopped to maintain application connectivity so that the server will not stop the application and data will not be lost.
公开号:BR112012018632B1
申请号:R112012018632-9
申请日:2010-12-30
公开日:2021-06-01
发明作者:Gregory R. Black；John P. Boos
申请人:Google Technology Holdings LLC；
IPC主号:

专利说明:

CROSS REFERENCE TO RELATED CASES
This application is related to the applicant's provisional patent applications, entitled “A Mobile Computing Device and Method With Enhanced Poling Management (Application Number CML07453), filed May 21, 2009, having US serial number 61/180301 , and A Mobile Computing Device and Method With Intelligent Pushing Management (application number CS37274), filed November 30, 2009, having US serial number 61/265,211. FIELD OF THE INVENTION
The field of the invention relates to a mobile computing device and method for maintaining application continuity. HISTORY OF THE INVENTION
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 exchange, for example, a short synchronization interval, and good battery life that requires exchanges of less frequent data, for example, a long synchronization interval.
The problem being addressed in this patent application is that after a certain timeout period of communication inactivity between the server and the mobile computing device, the server will terminate the application, which can result in the loss of desired data. It would be an improvement in technology if, before the time limit, a method could be devised to maintain the application.
Mobile computing devices, such as mobile or wireless stations, cell phones, radios, laptops, wireless communication devices, and the like, operate with an energy storage device with a limited power supply, such as a battery, fuel cell, or the like . The mobile computing device needs a power source, and in many cases this power source is a battery. For example, cell phones use various types of batteries to operate. The amount of time the mobile station can typically operate before battery power is consumed (which is often referred to as “battery life”) is often an important criterion consumers use when choosing a brand or type of mobile computing device about another brand. The terms battery, battery storage device, and power storage device are used interchangeably herein.
Although the energy storage device is generally rechargeable, it may not be convenient or even possible for the user to recharge. Thus, there is a need to maximize the useful uptime of a wireless computing device.
Additionally, different operating environments can cause the user to be surprised and/or frustrated when the battery wears out much more quickly than would typically be expected by the user. Thus, the variation or unexpectedly short battery life is very undesirable from a user perspective.
This is a particularly relevant issue for mobile computing devices running applications supported by an application server because of the power drain due to wireless data exchange between the mobile device and the server, as each up or down causes power consumption on the mobile device and on the server. The problem is especially acute in the mobile device, which is typically battery powered and has finite energy available. For example, the mobile device may employ an electronic mail server to upload and download contact status in support of a social networking application, and an information server to download movies, news, music, etc., in support of a social networking application. media playback, and a support/storage server to upload5 data from the mobile device in support of a data carrier application. Typically, the mobile device and the application server synchronize on a regular or periodic basis, that is, they communicate, upload, download, or exchange information at essentially regular or fixed time intervals, and in this document the data exchange between and mobile device that runs on an application and an application server is referred to as "sync", and the amount of time between data exchanges is referred to as the "sync interval" or "sync interval" for a given application and the server of application. Thus, there is a need to increase the length of the synchronization interval, to conserve energy in an energy storage device of a wireless computing device, such as a mobile station, to extend the useful energy storage device or service life of the drums.
There is often a trade-off between good application performance that requires more frequent data exchanges, that is, a shorter synchronization interval, and good battery life that requires less frequent data exchanges, that is, a longer synchronization interval. synchronization. For example, the performance of an electronic mailing application might be determined by the amount of time it takes to receive an electronic mailing, and the performance of a social networking application might be determined by the delay in receiving a change in the state of the social contact. .
Data exchange with an application server may be initiated by the server, i.e. a “pull” data service, or by the mobile device, i.e. a “pull” data service. In the case of a “pull” data service, the mobile device typically provides a timer operated to trigger the expiration of the sync interval at which time the mobile device can pull the application for availability of new application data. Thus, with a “pull” data service the mobile device is in control of the synchronization interval, also known as the pull or polling interval. Conversely, in the case of a “push” data service, the mobile device responds to server sync requests that may or may not be periodic. It is known to vary the sync interval by application as the performance of certain applications may be more sensitive to the sync frequency than others. It is also known that the requirement for timely synchronization varies with the state of the application. Synchronization can also be started a- periodically by the application processing on the mobile device, or by the user. Thus, when multiple applications are running, each application will likely require different sync intervals, which may or may not be controlled by the mobile device.
Synchronizing an application with an application server involves uploading or downloading application data between the mobile device and the application server over the communication infrastructure. Before application data is exchanged with the application server there is a need to perform certain initial activities, such as powering up the communication circuits, and establishing a data communication session with the communication infrastructure. Similarly, after data is exchanged with the application server there is a need to perform certain final activities, such as ending the data communication session with the communication infrastructure and turning off the data communication circuits. These initial and final activities cause power drain on the mobile device. Thus, there is a tendency for uncoordinated synchronization which causes energy drain due to the stopping and starting of activities associated with each data exchange. Thus, there is a need to minimize start and stop activities by coordinating synchronization times for multiple applications.
When operating the mobile device in synchronous communication with an application server, there is a trade-off between good application performance that requires more frequent data exchanges, that is, a short synchronization interval, and good battery life that requires exchanges of less frequent data, this is a long synchronization interval.
It is known to vary the synchronization interval according to a schedule, such that the period between downloads increases when certain applications are less likely to require frequent downloads. However, with application usage it is human behavior, the optimal downtime cannot always be predicted and scheduled. Furthermore, the energy drain due to wireless data exchange with the application server can be unpredictable. The wireless networks available may be such that only power-intensive data transmission methods are available. Thus, the optimal synchronization interval cannot always be predicted and scheduled. Thus, there is a need to provide a low but long sync interval or period to pull less power consumption at certain “sleep times”, while also providing shorter down sync intervals at “active times” when an application requires timely information.
Also, there is a need to provide a longer bass sync interval or period to pull less power consumption when the power required for sync is higher, while also providing shorter bass sync intervals when the power needed for sync is higher. synchronization is lower, thus taking advantage of favorable network conditions, which may be temporary.
In connection with thrust applications, data is pushed at regular interval from the application server, and the applicant is not aware of the method available in any mobile client to adjust the thrust interval. It would be considered an improvement in technology if the mobile device could autonomously adjust the speed at which it accepts pushed data. Furthermore, it would also be considered an improvement in technology if the mobile device could control applications where data is pushed from an application server to the mobile device. BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram of a system with improved polling management to reduce energy drain, in accordance with the present invention.
Figure 2 is a flowchart of an example of an approach to improve polling management to reduce energy drain, in accordance with the present invention.
Figure 3 is a series of timing diagrams representing the polling operation of a mobile computing device in accordance with the first version of the present invention.
Figure 4 is a series of timing diagrams representing the polling operation of a mobile computing device in accordance with a second version of the present invention.
Figure 5 is a block diagram of a mobile computing device that provides improved battery life in accordance with the present invention.
Figure 6 is a flow diagram of a mobile computing device processing an application in synchronous communication with an application server in accordance with an embodiment of the present invention.
Figure 7 is a simplified block diagram of a method of saving energy in a mobile device that processes an application in synchronous communication with an application server to reduce energy drain, in accordance with an embodiment of the present invention.
Figure 8 is a simplified block diagram of a method of saving energy in a mobile device that processes an application in synchronous communication with an application server to reduce energy drain, in accordance with an embodiment of the present invention.
Figure 9 is a simplified block diagram of a method of saving energy in a mobile device that processes an application in synchronous communication with an application server to maintain application continuity, in accordance with an embodiment of the present invention. Skilled artisans will appreciate that the elements in the Figures are illustrated simply and clearly and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the Figures may be exaggerated relative to other elements to help improve understanding of various versions of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially viable version are often not represented to facilitate a less obstructed view of these various versions of the present invention. It will further be appreciated that certain actions and/or steps may be described or represented in a particular order of occurrence, while those skilled in the technology will understand that this sequence-specificity is not effectively mandatory. It will also be understood that the terms and expressions used herein have the ordinary meanings as are accorded to those terms and expressions with respect to their respective corresponding areas of inquiry and study except where specific meanings have otherwise been made explicit herein. DETAILED DESCRIPTION OF PREFERRED VERSIONS
A system and method are described which 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, those terms used interchangeably herein) process an application in synchronous or periodic communication with an application server, to conserve and improve the life of an energy storage device in connection with a mobile computing device. The approaches described here allow the mobile computing device to operate under a variety of conditions and provide a variety of bandwidth intensive services without substantially compromising the energy storage device in association with the mobile station.
Coordinating the synchronization interval of periodic or synchronous communication between mobile computing device processing multiple applications with respective application servers could be done in a variety of different ways. In one example, the mobile device is equipped with a polling manager, who receives for each application an optimal polling interval and tolerance window; determines the elapsed time since the previous synchronization for each application; and syncs the application if the elapsed time since the previous sync is substantially equal to the optimal polling interval for the application, or communication activity is detected and the elapsed time since the previous sync is within the tolerance window for the application.
In another example, the polling manager: receives for each application an optimal 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 application if the elapsed time since the previous sync is substantially equal to the optimal polling interval for the application, or communication activity is detected, the time elapsed since the previous sync is within the tolerance window for the application and is the preferred sync interval. The length of the sync interval can be dynamically shortened or increased from the optimal interval, depending on whether the monitored communication activity is within the tolerance window for the application.
In another example, the polling manager: receives for each application an optimal polling interval and tolerance window; monitors communication activity on the mobile computing device; determines the elapsed time since the last 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 application if the elapsed time since the previous sync is substantially equal to the optimal polling interval for the application, or communication activity is detected, the time elapsed since the last sync is within the tolerance window for the application and is the preferred sync interval. The length of the synchronization interval can be dynamically decreased or increased from the optimal interval, depending on the monitored communication activity and the determined preference.
Other adjustments can also be made. For example, the tolerance window for a first application may be adjusted depending on the optimal timing interval for a second application, as detailed below.
Thus, approaches are described whereby the energy storage device of the mobile computing device is improved even under less than ideal operating conditions and different operating modes, such as multiple applications processing in synchronous communication with an application server. Consequently, the mobile computing device can operate under a variety of operating conditions.
Referring to Figure 1, an example of a system with improved polling 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 RAN ( Radio Access Network) 104. The first RAN 104 is coupled to a communication infrastructure 106. The infrastructure may include a plurality of application servers, for processing various applications, as detailed below. A second mobile computing device 110 is coupled to a second RAM 108. The second RAN 108 is also coupled to the infrastructure 106. The principles described herein may be applied to a variety of wide area network systems, such as evolving systems. Long Term (LTE), Ultra Mobile Broadband System (UMB), 802.16E&M, High Speed Packet Data (HRPD) systems, or systems such as Universal Mobile Telecommunication System (UMTS) as well as area networks wireless location, personal area networks, and wired networks.
Mobile computing devices 102 and 110 may be any type of mobile wireless device. Mobile computing devices 102 and 110 each include a polling management module 112 to coordinate synchronous communication between application server polling applications, as detailed below. For example, mobile computing devices 102 and 110 may be cellular phones, radio calling devices, radios, mobile stations, personal computers, or personal digital assistants. As should be understood by those skilled in the technology, other examples of mobile computing devices are possible.
RANs 104 and 108 may be any device or combination of devices that allow mobile computing devices 102 and 110 to access communication infrastructure 106. For example, RANs 104 and 108 may include access points, base stations , base station controllers, antennas, and other types of devices that facilitate these communications.
The communication infrastructure 106 preferably includes devices and/or networks that allow communication to be made between mobile stations. For example, infrastructure 106 may include switches, servers, storage devices, and networks (e.g., wireless networks, the Internet, land-line telephone networks) that facilitate communication between mobile computing devices 102 and 110.
Referring now to Figure 2, an exemplary method of enhancing polling 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 that processes a plurality of applications in synchronous or asynchronous data communication with an application server. Method 150 includes the steps of: providing 155 a polling manager configured to receive for each of the plurality of applications a predetermined polling interval and tolerance window; monitor 160 the data communication activity of the mobile computing device; determining 165, for each of the plurality of applications being processed, the time elapsed since the previous sync; and synchronizing 170 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 method can provide substantial energy savings in an energy storage device in mobile computing device applications; for example, by synchronizing and processing multiple applications together, which saves the energy storage device or battery life by turning on the transceiver circuit when necessary and minimizing or eliminating unnecessary or redundant synchronization by using polling management techniques dynamic and intelligent, as detailed here. This can be accomplished by providing a polling interval for each application that is within its tolerance window, for example.
In one arrangement, synchronization step 170 is triggered upon detecting synchronization activity initiated by at least one of: an application, an application server; and a user. This gives each application the opportunity to synchronize with the respective application server in coordination with the detected communication activity. In more detail, the synchronization step 170 can be triggered substantially immediately after the completion of the detected synchronization activity, thus avoiding stopping and restarting the communication circuits, and thereby saving energy.
With reference to Figure 3, four syncs are shown moving from the top to the bottom of the Figure, at time zero, six, twelve and eighteen, respectively. Application 1 has a sync interval of 24 units and a tolerance window of 11 units. Units can be in milliseconds. Application 2 has a sync interval of 21 units and a tolerance window of 6 units. Application 3 has a sync interval of 8 units and a tolerance window of 3 units. Application 4 has a synchronization interval of 6 units and a tolerance window of 2 units. Referring to Figure 3a, at time 0, a sync occurs for applications 1, 2, 3, and 4. At time 6, sync occurs, triggered by the amount that has passed since the previous sync being equal to the sync interval for the application 4. Applications 3 and 4 are synchronized because these are the applications for which the tolerance window includes time 6. Referring now to Figure 3b, the tolerance window is moved from Figure 3a to applications 3 and 4, to account for the time the previous sync has changed from time 0 to time 6. At time 12, a sync occurs, triggered by the amount of time that passes since the previous sync equals the sync interval for application 4. applications 3 and 4 are again synchronized, as these are the applications for which the tolerance window includes the time 12. Referring now to Figure 3c, the tolerance window is shifted from Figure 3b to the applications 3 and 4, to account for the time the previous synchronization has changed from time 6 to time 12. At time 18, synchronization occurs, whereby applications 1. 2. 3 and 4 are synchronized, as these are the applications for which the tolerance window includes time 18. This is how the synchronization of the four applications is coordinated, thereby reducing the energy drain on the data communication device.
By using intelligent polling management techniques, as detailed here, synchronizing and processing multiple applications together can provide substantial energy savings. For example, the transceiver circuit is turned on at times 0, 6, 12, and 18 as needed to obtain the low, etc. Referring again to Figure 3a, unnecessary or redundant synchronizations do not occur, as they would at time 8, for example, if the synchronization for application 3 had not advanced from time 8 to time 6.
In one version, method 150 may further include advancing the predetermined polling interval of a second application within the tolerance window, to synchronize substantially immediately after a first application, as shown at times 6, 12 and 18 in Figure 3, for example. This is beneficial as it can provide coordinated synchronization activity within the tolerance window for both applications.
In another version, sync step 170 may be advanced or adjusted from its predetermined or optimal polling interval in the event that sync activity is detected within the tolerance window. This allows an application to sync immediately after communication operations that are not necessarily for application server polling operations, such as application server-initiated synchronization, i.e., a “buoyancy” sync or other asynchronous communication such as one that is triggered by a high-priority application event or by the user.
In one version, the default polling interval is the maximum polling interval.
In one version, method 150 may include increasing the predetermined polling interval when a connection to a certain application server or network is unavailable, thus preventing unsuccessful or unnecessary polling attempts, which saves energy.
In another version, method 150 includes setting the predetermined polling interval outside of the tolerance window based on a network condition, thus reducing unnecessary synchronizations when communication is especially costly from a power-spending point of view.
In more detail, in one version, the network condition may include at least one of transmit power level, received signal level, received signal quality, modulation type, coding level, and communication data rate. These conditions can affect the energy drain associated with each communication. For example, if the network requires a higher mobile device power level, it may be preferable to delay synchronization outside of the tolerance window.
In another version, method 150 may include setting the predetermined polling interval outside the tolerance window when a certain mode of communication is available. For example, in a cellular network that provides third-generation service, for example, a broadband CDMA, as well as second-generation service, for example, TDMA, the polling interval may be adjusted outside the tolerance window if one of the services is unavailable. For example, if the application typically uploads or downloads large files and the highest bandwidth 3G service is unavailable, synchronization may be delayed. This feature provides the flexibility to change the synchronization interval depending on anticipated power drain which is a function of service availability and operating conditions.
In another version, the communication mode can be at least one of a wired network communication mode, a wireless local area network communication mode, a wireless mesh network communication mode, and a communication mode. of optical network. Thus, synchronization can be advanced, inside or outside the tolerance window, if the communication mode is particularly energy efficient, such as a wired local area network (LAN) communication mode, or a wireless LAN. Advantageously, these features allow the mobile computing device to carry application data in coordination with other communication for other applications. For example, a first application could be a social networking application like facebook or twitter, and a second could be a data carrier application. Social networking applications, which include real-time communication of personal messages, status and other personal data, and the highest priority application requiring periodic or synchronous server communication with a synchronization interval period on the order of 10 minutes. The media application is the lowest priority application requiring a synchronization interval on the order of 12 hours. Typically, the grace window for the media application is well over 10 minutes, the ideal polling interval for the social networking application. Thus, media synchronization takes place immediately after synchronization of the social networking application, after the grace window is opened for the media application, for example. This is an opportune time from an energy drain point of view, as unnecessary stopping and starting of communication circuits is avoided.
Referring again in greater detail to Figure 3, where a first series of timing diagrams corresponding to an exemplary device processing four applications in synchronous communication with an application server is shown. Each time diagram represents increasing time on the horizontal axis with a grid interval from 1 to 26. So for a grid interval of 30 minutes, the 26 intervals on the horizontal axis represent 13 hours of operation. For each application there is a corresponding predetermined burst interval and a predetermined burst interval tolerance window. The first application has a predetermined timing interval of 24 grid intervals (eg 12 hours) and a tolerance window of 11. The second application has a predetermined timing interval of 21 grid intervals (eg 10.5 hours) and a tolerance window of 6. The third application has a predetermined range of 8 grid intervals (eg 4 hours) and a tolerance window of 3. And, the fourth application has a predetermined range of 8 grid intervals ( eg 3 hours) and a tolerance window of 2. For each application the tolerance window is defined as having a maximum time determined by the previous sync time plus the predetermined interval, and the minimum time determined by the maximum time minus the tolerance. With reference now to time diagram 3a, the start takes place with the synchronization of the four applications in the grid time T=0. Thus, after synchronization at 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. At the grid interval =6 (eg 3 hours), the time reaches the predetermined range for the fourth application, which triggers data synchronization. In this opportunity 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. At the grid interval = 12 (eg 6 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 window is open. 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=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. At the grid interval = 18 (eg 9 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 window is open. It is determined that the tolerance window is 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 sync times of four applications are grouped together such that the number of sync occurrences is minimized to 3 times in 18 grid intervals, while in uncoordinated cases the number of sync occurrences could be as many as 9.
In another arrangement, method 150 may include reducing a first application's tolerance window when the predetermined polling interval for the second application is below a threshold. In the first example above, the data carrier application might have a tolerance window of the order of 2 hours. Synchronization for the data carrier application is triggered by the communication activity of the social networking application, which occurs every 10 minutes. Therefore, synchronization of the data carrier application takes place within the first 10 minutes of opening its tolerance window, thus reducing the synchronization interval for the carrier application by an amount almost equal to the tolerance window. In situations like this, it is advantageous to reduce the tolerance window for the lowest priority application to an amount in the order of the optimal sync interval of the highest priority applications.
In more detail, the step of reducing may comprise providing a tolerance window to the second application, reduced from a predetermined tolerance window, when the predetermined polling interval received from the first application is below a threshold. In the previous example, the media application's grace window might be reduced from 2 hours to 10 or 20 minutes, which is once or twice the optimal 10-minute interval for the social networking application. In more detail, the limit can be proportional to the tolerance window received from the second application. For example, the threshold might be a fraction, such as M, of the second application's default tolerance window. Thus, if the polling manager receives a two-hour tolerance window from the second application, and the optimal sync interval is less than M*2 hours, or 1.5 hours, then the tolerance window for the second application can be reduced to once or twice the ideal interval for the first application, or 10 to 20 minutes.
In an alternative version, method 150 for increasing the battery life of a mobile computing device that processes a plurality of applications in synchronous data communication with an application server, comprises the steps of: providing a polling manager having, for each application, a predetermined polling interval and a tolerance window; monitor the data communication activity of the mobile computing device; determine, for each application, the time elapsed since the previous synchronization; selecting a preferred sync interval from at least the elapsed time since the previous sync and a future sync interval; and synchronizing the application if at least one of the following conditions occurs: a) the elapsed time 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 sync is within the tolerance window for the application and is the preferred sync interval. Thus, for a lower priority application having a longer predetermined or ideal interval, synchronization can take place immediately after data communication to a higher priority application, or it can be postponed to a later time within the tolerance window. , thus selecting a sync interval that is closest to the predetermined, or optimal, sync interval. The preferred sync interval may be the time that is closest to the predetermined polling interval. It is worth noting that in this version the tolerance window might be a two-sided window, whereby a sync interval selected for the lowest priority application might be less or greater than the predetermined sync interval. In this case, the predetermined interval could be an ideal interval, and synchronization could take place either before or after the predetermined interval. Alternatively, the tolerance window may be one-sided and the predetermined interval is the maximum interval, in which case the synchronization interval is always advanced from the predetermined interval. Alternatively, the tolerance window may be one-sided and the synchronization interval is a minimum interval, in which case synchronization is always delayed by the predetermined interval.
For an alternative version of the second example, see Figure 4, where a first series of timing diagrams corresponding to an exemplary device processing four applications in synchronous communication with an application server is shown. Each of the applications has the same predetermined range and tolerance window as detailed in Figure 3, and the maximum and minimum synchronization times are calculated in a similar way.
With reference to time diagram 4a, the start takes place with the synchronization of the four applications in the grid time T=0. At grid interval =6 (eg 3 hours) the time reaches the predetermined interval for the fourth application, which triggers data synchronization. At this time, each application is checked to determine if the tolerance window is open. Unlike the example in Figure 3, if the window is open, a preferred sync time is chosen from either the current time or the next predicted sync, which is the current time plus the minimum predetermined interval. In this example, it is determined that the tolerance window is open for applications 3 and 4, and for both applications, the present time (T=6) is preferred over the anticipated next sync time (T=12) because the time present 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 were redrawn for applications 3 and 4, taking into account the previous synchronization at time T=6. At the grid interval =12 (eg 6 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 window is open. In this example, it is determined that the tolerance window is open for applications 3 and 4, and for both applications, the present time (T=12) is preferred over the predicted next sync time (T=18) because the time current is closer to the predetermined time. Therefore, applications 3 and 4 are synchronized with their respective application servers at time T=12.
Referring now to diagram 4c, the tolerance window has been redrawn for applications 3 and 4, taking into account the previous synchronization at time T=12. At the grid interval =18 (eg 9 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 window is open. It is determined that the tolerance window is open for applications 1, 2, 3, and 4, and for applications 2, 3, and 4, the current time (T=18) is preferred over the predicted next synchronization time (T =24) because the current time is closer to the predetermined time. For application 1 the current time (T=18) is not preferred because the next predicted 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 the 4d diagram, at the grid interval = 24 (eg 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 window of tolerance is open. It is determined that the tolerance window is open for applications 1, 3, and 4, and for applications 1, 3, and 4 the current time (T=24) is preferred over the predicted next synchronization time (T=30 ) because the current 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, as in the example in Figure 3, the synchronization times of the four applications are grouped together such that the number of synchronization occurrences is minimized, and in this example for applications having large tolerance windows and longer predetermined intervals, synchronization occurs. closer to the predetermined range, which reduces the synchronization frequency for that application, and thus reduces the energy drain.
In one version, the synchronization interval comprises an interval for which the number of applications having overlapping tolerance windows is the local maximum. In this way the synchronization can simply be determined. This involves counting the number of the application for which the time is within the tolerance window, failing to trigger synchronization when the count is increasing or a series of numbers above each time diagram, and synchronization occurs in the grid interval where the series is at its maximum.
In more detail, the future sync interval can be determined by adding the shortest predetermined polling interval of each of the applications being processed to the time elapsed since the previous application. Thus, in one arrangement, the polling manager can be further configured to receive for each of the plurality of applications an ideal polling interval, and the step of selecting can further comprise selecting the interval which is closest to the ideal polling interval, for the reasons detailed above.
Likewise, in an array, the default polling interval is a maximum polling interval, as detailed above. In an alternative version the step of selecting a preferred sync interval comprises consulting the application on which sync interval is the preferred interval. In this case the application can simply select the range that is closest to the predetermined or ideal range, or it can select the preferred range based on some other criterion. This provides an advantage as selection criteria may change depending on the state or context of the application.
In one version, the optimal synchronization interval comprises an interval for which the number of applications having overlapping tolerance windows is a local maximum. The term application, as used herein, may include at least one of electronic mail, instant messaging, social networking, news feed, games, media upload (eg, photo upload), media download (eg, download music) and data carrier, or any other application that requires data synchronization or otherwise having regular communication with an application server.
In another version, method 150 may include providing a mobile computing device in synchronous application server communication to a first application in a first synchronous communication slot, and in synchronous application server communication to a second, higher priority application. low in a second nominal synchronous communication interval equal to the first synchronous communication interval times a nominal integral number, where the nominal integral is the integral part of a predetermined interval for the second application divided by the predetermined interval for the first application.
In more detail, the 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. .
Advantageously, the features here allow the mobile computing device to upload application data to a server when network conditions or other power determining factors are favourable. For example, the first application could be a social networking application like facebook or twitter and the second could be a data carrier application. Social networking applications, which include real-time communication of personal messages, status, and other personal data, is the highest priority application requiring synchronous or periodic server communication with a synchronization period or interval of the order of 10 minutes . The media application is the lowest priority application that requires a synchronization interval on the order of 12 hours. In this example, over the course of 12 hours while the social networking application syncs on the order of 72 times, the network conditions could vary significantly. For example, the RF energy level of the wide area network may vary due to variation in track loss between the mobile device and the network base station, or due to network traffic, or due to shifting to a network with different capacities , such as for a different wide area network, or a local area network. Thus, data carrier synchronization can occur 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 Figure 5, there is shown an exemplary block diagram of a mobile computing device 200, such as mobile computing devices 102 or 110, according to one version. Mobile computing device 200 may include a frame 210, an energy storage device 215, a controller 220 coupled to the frame 210, a memory 270 coupled to the frame 210, an antenna 280 coupled to the frame 210, and a data identity module. removable subscriber (SIM) 285 coupled to controller 220. Mobile computing device 200 employs controller 220 and memory 270 to process applications in synchronous communication with and an application server through transceiver 250. Mobile computing device 200 further includes a polling manager 290, coupled to the 220 controller. In more detail, the polling manager 290 may reside within the 220 controller, it may reside within the memory 270, it may be a standalone module, it may be an application, it may be software, it may be hardware, or it can be in any other format useful for a module in a wireless communication device 200. In one version, polling manager 290 can be defined as m a controller to coordinate communication with the application server, based on nominal polling intervals and tolerances for each application.
The screen 240 may be a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, or any other means for displaying information. Transceiver 250 may include a transmitter and/or a receiver. Audio input and output circuit 230 may include a microphone, speaker, transducer, or any other audio input and output circuit. User interface 260 may include a keyboard, buttons, a touch pad, a joystick, an additional screen, or any other device useful to provide an interface between the user and the electronic device. Memory 270 may include random access memory, read-only memory, optical memory, or any other memory that can be coupled to a wireless communication device.
In more detail, in one version, the mobile computing device 200 with the energy storage device in Figure 5 includes: a frame 210, a controller 220 coupled to a frame 210, the controller 220 configured for applications in synchronous communication of a or more application servers; memory 270 coupled to controller 220, a wireless transceiver 250 coupled to controller 220 for synchronizing application data between mobile computing device 200 and the one or more application servers (which could reside in infrastructure 106 in Figure 1) ; and a polling management module 290, the polling management module configured to: receive for each of the plurality of applications a predetermined polling interval and a tolerance window; monitor data communication activity of the mobile computing device; determining, for each of the plurality of applications being processed, the time elapsed since the previous synchronization; and synchronizing the application if at least one of the following conditions occurs: the elapsed time since the previous sync is substantially equal to the predetermined polling interval for the application, and communication activity is detected, and the elapsed time since the previous sync is within of the tolerance window for the application. As an advantage, polling management module 290 can allow mobile computing device 200 to dynamically manage communication with applications in process. This arrangement can provide a longer lifetime for mobile computing devices before needing to recharge the user's energy storage device 215. Beneficially, the polling management module 290 can serve to coordinate communication activity and thereby reduce the unnecessary starting and stopping of communication circuits, such as the transceiver 250, thereby extending the life of the energy storage device in mobile computing device applications.
In one version, the polling management module 290 includes: a processor configured to poll and synchronize applications; and an adjustment module configured to advance or delay a second application's predetermined polling interval within the tolerance window, synchronizing substantially immediately after a first application, for improved energy savings.
In one version, the polling management module 290 is further configured to receive, for each of the plurality of applications, an optimal polling interval, and select an interval that is closer to the optimal polling interval, for improved energy savings .
In one version, the instant invention is incorporated within the communication infrastructure and in another it may be incorporated within a wireless communication device. More specifically, the polling management module 290 could be incorporated within a mobile computing device 200 or alternatively within the infrastructure 106. Other placements are possible, such as including being in both.
In more detail, control 220 comprises an application processor for processing application programs. Application programs may be individual programs or programs that process in communication with an application service, in which case the application program is referred to as an application service daemon. Each application that processes in synchronous communication with an application server may have a corresponding application service daemon processing at the controller 220. Each application that processes in synchronous communication with an application server may have a corresponding application service daemon processing at the controller 220. Alternatively, the application service daemon may render on any component of the mobile device 200 having application processing capability including display 240 which may comprise a smart display controller, transceiver 250, memory 270, SIM 285, or management module of polling 290.
In another version, the polling management module 290 provides an autonomous push management function to adjust the speed at which the mobile device receives “push” data from an application server. In a preferred version, communication from an application service is interrupted during dormancy periods. More specifically, module 290 can be further configured to provide a scheduler (not shown) for providing, establishing or determining dormancy periods. Synchronous communication that is normally “pushed” by the application server to the mobile device may be suspended during scheduled dormancy periods, thus reducing the energy drain when vacating transceiver 250 during these periods. The energy drain can be further reduced by vacating the application service daemon during these periods. Consequently, the mobile computing device can utilize a variety of energy consuming applications and services with different synchronization requirements, while maintaining and improving the life of an energy storage device of a mobile computing device. Because of the method, structure and approaches revealed in detail here, the user experience can be significantly improved. Referring to Figure 6, a flow diagram 600 of a preferred version according to the invention is shown screened. The process starts at node 605 from which the process branches to applications that concurrently process 610. Represented at 610 are four applications in processing: electronic mail, news feed, photo upload, and data carrier, having the application number , A = 4, 3, 2 and 1, respectively. Each application writes a given interval, Int(A) polling an interval register 615, and a default tolerance window, Win(A) into the tolerance window register 620. These default values can be modified by the application according to the state of the application. For example, the email application might reduce the break during business hours, or the news feed application might increase its break when the user is actively reading the news. The home node also branches to the polling management process (in phantom) 625, starting with initialization 635 where, for each application, the following counters are fixed: TPREVIOUS(A)=0 TMin(A)=Int(A )-Win(A) TIDEAL(A)=Int(A) T=0.
The process continues to decision diamond 640 where it is determined whether communication is currently active. If decision diamond 640 decides that communication is not active, or “No”, then the process continues to set application counter 645 to A equal to the number of applications being processed, Appcount, which in this example is equal to 4. From there, the process flows to decision diamond 650 where it is determined whether, for application A, the current time T is equal to TIDEAL(A). If at decision diamond 650 it is determined that T=TIDEAL(A) then it is determined that synchronization must occur and the process continues to set the second application counter 655 to A’ equal to the number of applications being processed, Appcount. Also, at decision diamond 640, if it is determined that communication is active, or “Yes”. then 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 > Tmin(A’). If it is decided that T > TMin(A'), or “Yes”, then the process continues to synchronize application A' 665 and then to reset 670 the timers for application A': TPREVIOUS(A')=T TMin (A')=T+Int(A')-Win(A') TIDEAL (A')=T+Int(A')
The process continues to decrement counter A’ 675, followed by decision diamond 680 where it is determined whether A’=0. If decision diamond 680 is determined to be A’/0, or “Yes”, then the process continues to decrement A’ 685 followed by decision diamond 690 where it is determined whether A=0. If in 690 it is determined to be A=0, or “Yes”, then the process continues to delay box 695. DA box 695, the process continues to increment T in box 697, and from there the process continues back to the diamond of decision 640. If at 640 it is determined that communication is active, or “yes”, then the process jumps to set the second application counter in box 655 to A'=the number of applications being processed, Appcount. If decision diamond 660 is determined to be T^TMin(A'), or "not", then the process jumps to decrement box A' 675. If decision diamond 680 is determined to be A'/0, or " no", then the process returns to decision diamond 660. If at decision diamond 690 it is determined that A^0, then the process continues to decision diamond 650. Flow control for alternative versions can be demonstrated in a manner. similar.
Referring to Figure 7, there is shown a version of a method 700 of saving energy on a mobile device processing an application in synchronous communication with an application server. 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, setting an active mode, in which synchronous communication is automatically enabled by establishing a persistent IP session according to a pre-arranged schedule; and providing 720 a sleep mode in which synchronous communication is automatically disabled on the mobile device when closing the persistent IP session with a predisposed schedule. In an alternative version, method 700 includes the step of scheduling 730 a user-programmable sleep mode scheduler to schedule the sleep mode period. As an advantage, user can provide off-peak times or quiet times (sleeping mode) and/or active and peak times (active mode) AP using a programmable scheduler.
Referring again to Figure 1, infrastructure 106 typically employs firewall techniques to disable the establishment of TCP/IP connections to mobile Internet devices. This helps to prevent or minimize mobile devices from receiving spurious Internet traffic that would cause unwanted power drain. Thus, an IP session with the application server cannot normally be established by any application server. It needs to be established from the mobile device. Mobile devices 102 and 110 will be able to initiate an IP session by communicating with an Internet gateway (not shown) on the wireless infrastructure 106. In a preferred version, an IP session, comprising a control protocol internet protocol connection (TCP/IP) may be initiated by a mobile device 102 or 110 activating a packet data protocol (PDP) context with the Internet gateway in the wireless infrastructure 106. The PDP context defines a unique IP address by which the application server can communicate with the mobile device.
After the TCP/IP session is established, the session remains active for an amount of time determined by a session timer on the application server or Internet portal on the wireless infrastructure 106. If there is no other mobile device communication , the session remains open until the session timer expires, and then the TCP/IP connection is closed. Advantageously, this allows the server to stop sending application data if the client is removed from service, without gently closing the TCP/IP connection, as tends to happen with mobile device clients for a number of reasons, including weak signal conditions. , and sudden loss of battery power.
Each communication from the mobile device client to the application server causes the session timer to be reset. The mobile device can maintain a persistent IP session by sending keep-alive messages to the application server at intervals less than the session timeout period. The session timeout period is determined by the server or portal, and is typically 30 minutes. Thus, if the application server is able to send, or “push” application data to the mobile device while the IP session is kept active.
On occasions when application data is “not needed”, the mobile device can prevent the data from being “pushed” to it 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 “close” connection token. The TCP/IP session is thus closed. preventing the application server from making a connection through which it can send application data.
As an advantage, energy can be saved in the mobile computing device, thus extending the life of an energy storage device or a battery. By utilizing smart push management, substantial energy savings can be gained by utilizing predisposed scheduling of dormant or active modes.
Thus, PDP and TCP/IP protocols or UDP session protocols are adapted to reduce the energy 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 specification RFC2616, by the Internet Society.
In a preferred version, operation step 710 includes receiving push notifications from the application server during the persistent IP session. In another arrangement, operating step 710 may include the persistent IP session being kept alive by periodic keep-alive messages from the mobile device to the application server.
The step of providing 720 may include closing the persistent IP session, thus ending more push notifications. As an advantage, this feature allows the mobile device to schedule dormant or quiet times and active times independently of the application server. In another version, the step of providing 720 may include the persistent IP session being closed by allowing the session to run out of time by failing to send a keep-alive message from the mobile device to the application server.
In greater detail and in a preferred version, method 700 may include an autonomous push management function, in module 290, for example. It can consider when data communication is "necessary" or "unnecessary", and specifies triggers to enter active mode, in which an application program processing in communication with the application server, and to enter quiet or dormant mode in that synchronous communication is stopped or interrupted.
In a preferred version, PDP context is required when operating in peak period. Thus, a particular focus is given to the always-on user experience, and the PDP context is maintained as long as there is at least one TCP or UDP session active. On the other hand, the PDP context is not needed when operating in an off-peak or dormant period, when application timeliness may be sacrificed in favor of reduced power drain. In this case, the PDP context is released unless there is some user activity detected. For example, when the user has an active application (either in the foreground or in the background) that maintains a persistent TCP socket, then PDP context would be needed.
In more detail, a preferred PDP context management strategy might include the following: 1. When the mobile device is connected to a power source, the PDP context should always remain active. The power source can be a battery charger, or AC power adapter, or a host device such as a personal computer that supplies power through a connection such as the universal serial bus (USB) connection. 2. When the mobile device draws its power from an internal battery during a peak period (active mode):
If the PDP context is established, it must remain established as long as there is at least one active TCP or UDP session.
If the PDP context is established and all TCP and UDP sessions are disabled, the PDP context must 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 must be established.
If the PDP context is not established, it should remain unestablished as long as there are no active TCP or UDP sessions. 3. When the UE operates on battery and during the off-peak period:
When the screen turns off (no user activity), the PDP context should 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 turns on (user activity detected), the PDP context should be established and should remain established until the screen turns off again.
Alternatively, the PDP context can be kept or reset at off-peak hours if active user detection state is detected.
Examples of active user detection are detecting an active user interface such as a screen, touch screen, keyboard, or background lighting; detecting movement from or in proximity to the device, such as movement or acceleration of the device itself, or of an object near the device; and detect a wireless connection to the device such as activating wireless headsets.
In a preferred version, method 700 may further include maintaining other communications between the mobile device and other communication entities in active and dormant mode. As an advantage, this feature allows certain communications, such as social networking applications, to be turned off while other application servers are turned on. For example, method 700 may further include maintaining other communication between the mobile device and other communication entities while in sleep mode, the other communications comprising at least one of voice communication, short message service communication, and data communication. , employ an IP session other than the persistent IP session with the application server.
Referring to Figure 8, an 800 system with intelligent thrust management for increasing the battery life of a mobile computing device is described and shown. 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 switching connection 822, such as the gateway service node (SGSN) found in a general packet radio service infrastructure (GPRS). The wireless infrastructure 820 may also include an 822 circuit connection for connecting voice applications as well as connecting legacy data applications such as short message services (SMS). Mobile devices 810 and 812 are configured to connect via the internet portal 822 in the wireless infrastructure 820, to a front end 832 of application service aggregation servers 830, and to the individualized application server 840 via the internet . The rear end of application service 836 of aggregation server 830 connects via the Internet to individualized application servers 850 and 860. Application aggregation server 830 comprises data cache 834 for storing application data to and from application servers 850 through the rear end 836, for eventual transmission through the front end 832 and the wireless infrastructure 820 to and from mobile clients 810, 812. The mobile devices 810 and 812 are also configured to communicate over the wireless infrastructure 820 via a circuit switched infrastructure 824. Circuit switched infrastructure is used for legacy communication services such as voice calls, short message services (SMS) and circuit switched data services. The principles described here can be applied to a variety of wide area network systems such as long term evolution (LTE), ultra mobile broadband (UMB), 802.16e & m, High Speed Packet Data (HRPD) systems ), or systems such as the Universal Mobile Telecommunications System (UMTS), as well as wireless local area networks, personal area networks, and wired networks.
The 810 and 812 mobile computing devices may be any type of mobile wireless device. Mobile computing devices 810 and 812 each include an intelligent push management module 112 or 290 to coordinate synchronous communication between application server polling applications, as detailed below. For example, mobile computing devices 810 and 812 may be cellular phones, radio paging devices, radios, mobile stations, personal computers, or personal digital assistants. As should be understood by those skilled in the technology, other examples of mobile computing devices are possible.
The 810 and 812 mobile devices will be able to connect to the 820 wireless infrastructure through radio access networks (RANs), as shown in Figure 1. The RANs can be any device or combination of devices that allow the devices to mobile computing 810 and 812 have access to the communication infrastructure 820. For example, RANs may include access points, base stations, base station controllers, antennas, and other types of devices that facilitate such communications.
Communication infrastructure 820 preferably includes devices and/or networks that allow communication to be made between mobile stations. For example, infrastructure 106 may include switches, servers, storage devices, and networks (e.g., wireless networks, the Internet, land-line telephone networks) that facilitate communication between mobile computing devices 810 and 812 and Internet devices such as 830 and 840 application servers.
The application service aggregation server 830 provides the function of periodically polling application servers 850 and 860 for new data, and then providing the application data to mobile devices 810 and 812 through packet data switching 822 on the 820 wireless infrastructure. For example, the 850 and 860 application servers could be conventional social networking applications such as Face book, Twitter, etc. The aggregation server 830 will be able to poll for status notifications from social contacts on the Facebook service, and for new messages on the Twitter service. It stores the new data in memory and makes it available to the mobile device through the wireless infrastructure by push or pull methods, as detailed here.
Mobile devices 810 and 812 are configured to simultaneously connect to multiple data servers and the methods described herein include maintaining communication between a mobile device and a first application server while in sleep or quiet mode with a second application server. For example, mobile devices 810 and 812 can connect through the internet portal 822 on the wireless infrastructure 820, to a service aggregation server 830, and can also connect to an individualized application server 840, bypassing the 830 application service aggregation server. The individualized application server could be an electronic mail application such as Gmail, for example.
The methods described herein may include maintaining communication between the mobile device and the individualized electronic mail application server, while in sleep mode suspending communication to the aggregation server 830, for example. This can be accomplished by establishing different PDP contexts between the mobile device and the wireless infrastructure to connect the different services, and applying the dormancy triggers to the different PDP contexts. Connections to individualized aggregation server 840 may, for example, remain active during off-peak or off-peak hours when connections to aggregation server 830 are closed. Conversely, for simplicity and user convenience, a single dormancy scheduler and policy can be applied to different application services with different PDP contexts. Thus, in sleep mode communication communication to all data servers can be suspended, even if they are different, with different PDP contexts used. In this way the sleeper mode that is most effective in reducing energy drain can be conveniently scheduled.
In a preferred version, voice communication and short message service communication are not affected by the closure of PDP contexts, as these can employ the 824 circuit-switched infrastructure in the 820 wireless infrastructure, not requiring a context. PDP.
In a preferred version, an automatic mode controller can be provided, where the mobile device is switched to active mode when user activity is detected. As an advantage, this feature provides the user with a user unmanage function to allow the user to instantly enter active mode when this is desirable.
In greater detail and as an example, the detected user activity can include at least one of: detecting movement in the proximity of the mobile device; detect a keystroke; detect touch screen press; detect that the screen is active; and detect an incoming communication. As an advantage, this allows the user to use an application during the pre-arranged quiet or off-peak time, without having to reprogram the quiet hours.
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 an electrical load device. The electrical charging device can include at least one of an AC adapter, a battery charger, and a host device. The host device can include a PC, or any device that provides a DC power source through a data connector such as a USB connector. The battery charger can be wired or a 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 may 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 source, an AC adapter, battery charger, a user interface device such as an external mouse, exchange controller, an audio or acoustic device, a data cable, or an external memory device.
In one embodiment, method 700 may include operational step 710 of including operating an application processor on the mobile device, and suspending operation of the application processor. Similarly, in another arrangement, operational step 710 may include operating an application service daemon on an application processor on the mobile device, and suspending operation of the application service daemon. Advantageously, these provide a reduction in energy drain due to deactivation, idle or reduced application processor operations.
In another version, method 700 may include the steps of: operating 710 an application in synchronous communication with an application server through a persistent IP session, setting an active mode; provide 720 sleep mode in which synchronous communication is disabled on the mobile device; and schedule 730 the programmable sleep mode scheduler to schedule the sleep mode period. As an advantage, the user can provide quiet times (sleeping mode) and/or active times (active mode) by using a programmable scheduler. This allows the mobile device to be operated in a personalized way based on various user preferences, personalities and timelines.
In a preferred version, as shown in Figure 5, mobile computing device 200 is shown. It may include: a frame 210, a controller 220 coupled to a frame 210, the controller 220 configured to process applications in synchronous one or more application servers; memory 270 coupled to controller 220; a wireless transceiver 250 coupled to controller 220 for synchronizing application data between mobile computing device 200 and one or more application servers; and a thrust management module 289 configured to: operate an application in synchronous communication with a server of application through a persistent IP session, define an active mode, in which synchronous communication is automatically activated when establishing a persistent IP session according to a pre-arranged schedule; and provide a sleep mode where synchronous communication is automatically disabled on the mobile device when closing the persistent IP session according to the pre-arranged schedule. Advantageously, the mobile computing device 200 provides energy savings and long battery life, resulting in an improved user experience. Advantageously, energy can be saved in the mobile computing device, thus extending the life of the energy storage device or battery. By utilizing intelligent thrust management, substantial energy savings can be gained by utilizing the pre-arranged schedule of dormant and active modes. In Figure 5, block 290 declares “Poilling Management Module” however, in the above version, the module is in the form of a “thrust management module”.
In one release, the thrust management module 290 includes a programmable sleep mode scheduler to schedule the sleep mode period, which helps extend battery life as detailed above.
In one version, the thrust 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 for entities with different PDP contexts, as detailed above. This way the user can individually select or set applications to be dormant during off-peak or calm hours.
In one release, the thrust management module 290 is configured to switch to active mode when certain user activity is detected. This overlay feature allows the user to instantly go into active mode if desired.
In one release, the thrust management module 290 can include one or more of the features detailed above with respect to method 700, for an improved user experience.
A potential problem arises if the amount of time in sleep mode exceeds a limit on the application server to process the application in the absence of communication, that is, in a null communication, with the mobile device client. Referring now to Figure 9, a method of saving energy on a mobile device by processing an application in synchronous communication with an application server 900 is shown. The application has a zero communication period limit to maintain application continuity. Method 900 may include the steps of operating 910 the application in synchronous communication with an application server, setting an active mode, in which synchronous communication is automatically enabled, providing 920 a sleep mode in which synchronous communication is automatically disabled in the device mobile for a predetermined duration; and 930 interrupting sleep mode by momentarily communicating with the application server before the limit of the null communication period to maintain application continuity.
Advantageously, before the communication inactivity timeout period, sleep mode is stopped to maintain application connectivity so that the server will not stop the application and data will not be lost. For example, referring to Figure 8, the mobile device client 810 is processing 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 830 is in Internet communication with one or more application servers 850 and 860. For example, application server 850 is at the service of Twitter. When the mobile device client 810 goes to sleep to save power, it stops communicating with the front end of the application service aggregation server 830. Meanwhile, the rear end of the service aggregation server 830 continues to accept new data or information , from the application servers 850 and 860, and store the data in a data cache 834, for eventual push to the mobile device client 810 through the front end 832 of the application service aggregation server 830.
The problem is that the 830 application service aggregation server may suspend service after a period of time when there is no communication with the 810 mobile device client. This may be necessary to avoid wasting memory, processing resources, and communication features for customers who have stopped using the service. As an advantage, before a communication inactivity timeout period, sleep mode can be stopped to maintain application connectivity so that the 830 application service aggregation server will not stop the application and data will not be lost . For example, the rear end 836 of application service aggregation server 830 may continue IP communication with the Twitter service of application server 850, for example, and cache incoming messages, or Twitter “tweets”, in the cache. of data 834 for a period T after communication with the client device is stopped. For example, T could be 2 to 4 hours. In this case, the application service aggregation server 830 stops storing new messages, and may also delete existing messages. Thus, a dormancy period in excess of T results in data loss.
Thus, in this example, it may be beneficial to provide before the communication inactivity timeout period, that the sleep mode is stopped, to maintain application connectivity, so that the application service aggregation server 830 will not stop the application and will prevent data loss.
The method is applicable to a variety of applications. In another example, application server 860 is a news feed service. When the mobile device client 810 goes to sleep to save power, it stops communicating with the front end 832 of the application service aggregation server 830. Meanwhile, the rear end 836 of the service aggregation server 830 continues to accept news from the application servers 860, and stores them in a data cache 834, for eventual push to the mobile device client 810 through the front end 832 of the application service aggregation server 830. The application service aggregation server 830 may suspend the service after a period of time in which there is no communication with the 710 mobile device client. It may stop storing news data, erase stored news data, or it could continue to store new data while erasing older data . In any case, undesirably, data will be lost.
Advantageously, before a communication inactivity timeout period, sleep mode can be stopped to maintain application connectivity so that the application service aggregation server 830 will not stop the application and data will not be lost. For example, the rear end 836 of application service aggregation server 830 may continue IP communication with the news feed service of application server 860, for example, and store incoming news stories in data cache 834, by a period T after communication with the client device has stopped. For example, T might be 10 hours. In this case the application service aggregation server 830 stops storing new messages, and may also delete existing messages. Thus, a dormancy period in excess of T results in data loss.
Thus, in this example, it may be beneficial to provide before a communication inactivity timeout period, that the sleep mode is stopped, to maintain application connectivity, so that the application service aggregation server 830 will not stop the application. and will prevent data loss.
Stated differently, in the example above, it may be advantageous to prevent server 830 from disconnecting from applications due to long periods of suspended communication with the client of mobile device 810 by succinctly summarizing communication with server 830 at lower periodic intervals to the application timeout, T. For example, if the mobile device client 810 starts a dormancy period of 8 hours, and if the application timeout period T is 3 hours, then the mobile device client 810 would send a “keep alive message” to the 830 server at an interval of less than 3 hours. The keep alive message can be similar to the existing message used to keep the TCP/IP session active in non-sleeping mode. The keep alive message could be a request to reset or increment the value of an application inactivity timer. It can be a request to control idle timers for all applications currently in process, or to continue operation of one or more operations. Alternatively, the message could be a message to request the continuation of one or more specific applications, and could specify the amount of time for which the application should remain active through an idle period, such as a null in communication. In addition to the time limit, other controls can be useful, such as the data storage limit, a limit on the use of processing resources, a limit on channel bandwidth, etc. As such, the keep alive message may contain data fields to identify applications or groups of applications, and to convey a threshold below which the application must remain active, such as an amount of time, or the amount of data an application can store , the amount of storage capacity, processor resources, for example, microprocessor cycles or MIPs, or channel bandwidth that the application can use during an idle period, such as zero communication. For example, there may be a limit on the amount of data stored in memory cache 834.
Advantageously, in a preferred version, the 810 mobile device client can autonomously implement a sleep mode to reduce the power drain in sleep mode. In addition, the 810 mobile device client can send a keep alive message in a period less than the application timeout period, and thus maintain application continuity for periods of time longer than the application timeout period .
In one version, operational 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 step of providing includes closing the persistent IP session and thereby terminating further notifications of push, and the break step includes establishing and closing a persistent IP session. In this way the client of mobile device 810 can notify application server 830 that it is still present and in need of application services despite an interruption in communications that could otherwise be interpreted as mobile device 810 hanging up or being removed from the device. network.
In one scenario, in provision step 920 and interrupt step 930, the persistent IP session can be closed by sending a TCP/IP connection header including a connection token closure according to an HTTP1.1 standard. As an advantage, this feature provides framing with the standard. Thus, the mobile device client 810 will be able to gracefully close the TCP/IP session while maintaining application continuity on the server 830 for the immediate restart of service after a long period of communication inactivity, for the purpose of saving energy.
In one arrangement, the IP session has a null communication timeout period to maintain the IP session persistence, and in operation step 910, the persistent IP session is kept active by momentarily communicating with the application server before the timeout period of null communication, to maintain the desired IP session.
In another version, the operating step 910 includes receiving push notification over a non-IP channel and the step of providing 920 includes sending a control message to the application server, whereby the push notification can be stopped. As an advantage, this feature provides application services that do not depend on the persistent IP session being kept active by the mobile device client. For example, if USSD were used to push data, then it would be appropriate to open an IP session just to request data (eg pull) from the server, and close the IP session after each pull operation. In this case, sleep mode would be initiated by the mobile device client by sending a control message “stop pulling data indefinitely” or “stop pulling data until a designated time”. Other limitations, in addition to time limitations, are possible, such as processor, memory, or bandwidth limits on the 830 server.
In one version, the mobile device is processing a first and second application in synchronous communication with the application server. Each application can have a zero communication timeout period to maintain application continuity. In this case, interrupt step 930 would occur upon expiration of a dormancy timer programmed to a value lower than the zero communication threshold period to maintain application continuity for the first and second applications.
In another arrangement, method 900 may include maintaining other communications between the mobile device and other communication entities in active mode and in sleep mode to enhance the user experience.
In yet another arrangement, method 900 can provide an automatic mode controller in which the device is switched to active mode when user activity is detected, for an improved user experience.
In one version, method 900 may include scheduling the user-programmable sleep mode scheduler to allow the user to schedule a desired sleep mode period.
In a preferred arrangement, as shown in Figure 5, mobile computing device 200 may include: a frame, 210; a controller 220 coupled to the frame, the controller 220 configured to process applications in synchronous communication from one or more application servers, each application having a zero communication timeout period to maintain application continuity; memory attached to the controller; a wireless transceiver 250 coupled to controller 220 for synchronizing application data between the mobile computing device and one or more of the application servers; and a thrust management module 290 configured to operate an application in synchronous communication with the application server, setting an active mode; provide sleep mode where synchronous communication is automatically disabled on mobile device according to pre-arranged schedule; and interrupting sleep mode by momentarily communicating with the application server before a zero communication threshold period, to maintain application continuity. Advantageously, before the communication inactivity timeout period, the sleep mode is stopped, to maintain application connectivity, so that the server will not stop the application and data will not be lost.
In a preferred version, the mobile computing device 200 may include: the thrust management module 290 which includes the user-programmable sleep mode scheduler to schedule the sleep mode period, the thrust management module being further configured to maintain other communications between the mobile device and other communication entities in active and dormant modes; the thrust management module being configured to switch to active mode when certain user activity is detected; and the thrust management module includes a dormancy timer programmed to a value less than the shortest maximum zero communication period to maintain application continuity for each application, and the stop step occurs upon expiration of the dormancy timer, to better functionality, as detailed above. Those skilled in the technology will recognize that a wide variety of modifications, alterations and combinations can be made with respect to the versions described above without departing from the broad scope of the invention, and that such modifications, alterations, and combinations are to be seen as being within the scope of the invention.

权利要求:
Claims (18)
[0001]
1. Method of saving energy on a mobile device (200, 810, 812) that processes an application in synchronous communication with an application server (840, 850, 860), the application having a zero communication timeout to maintain continuity of the application, the method comprising the steps of: operating (910) the application in synchronous communication with an application server, setting an active mode, the step of operating includes establishing a persistent IP session with the application server and in which communication synchronous is automatically activated; providing (920) a sleep mode in which synchronous communication is automatically disabled on the mobile device for a predetermined duration by closing the persistent IP session; the method being characterized by: interrupting (930) the sleep mode by momentarily communicating with the application server before the zero communication threshold period, the interrupting step includes establishing and closing a persistent IP session, to maintain application continuity.
[0002]
2. Method according to claim 1, characterized in that the step of operating includes receiving push notifications from the application server in the persistent IP section, the step of providing includes closing the persistent IP session and thus terminating other push notifications.
[0003]
3. Method according to claim 1 or 2, characterized in that in the step of providing and in the step of interrupting, the persistent IP session is closed by sending a TCP/IP connection header including a closing connection token. according to the HTTP1.1 standard.
[0004]
4. Method according to claim 1 or 2, characterized in that the IP session has a zero communication limit period to maintain the persistence of the IP session, and in the operating step, the persistent IP session is kept active momentarily communicate with the application server before a null communication timeout period to maintain the IP session.
[0005]
5. Method according to claim 1, characterized in that the step of operating includes receiving push notification over a non-IP channel, the step of providing includes sending a control message to the application server by which the notification thrust is stopped.
[0006]
6. Method according to claim 1, characterized in that the mobile device is processing a first and second application in synchronous communication with the application server, each application having a zero communication limit period to maintain application continuity, and the interrupt step occurs upon expiration of a dormancy timer programmed to a value lower than the zero communication threshold period to maintain application continuity for the first and second applications.
[0007]
7. Method according to claim 1, characterized in that it further comprises maintaining other communications between the mobile device and other communication entities both in active mode and in sleep mode.
[0008]
8. Method according to claim 1, characterized in that it further comprises providing an automatic mode controller in which the device is switched to active mode when user activity is detected.
[0009]
9. Method according to claim 1, characterized in that it further comprises providing an automatic mode controller in which the device is switched to active mode when a user activity is detected, including at least one of: detecting movement in proximity to the mobile device; detect a keystroke; detect the touch screen press; detect that a screen is active; and detect an incoming communication.
[0010]
10. Method according to claim 1, characterized in that it further comprises providing an automatic mode controller in which the device is switched to active mode when the device is connected to a load device.
[0011]
11. Method according to claim 10, characterized in that the charging device is at least one of an AC adapter, a battery charger, and a host device.
[0012]
12. Method according to claim 1, characterized in that the step of operating includes operating an application processor on the mobile device, and the step of providing includes suspending the operation of the application processor.
[0013]
13. Method according to claim 1, characterized in that the step of operating includes operating an application service daemon in an application processor on the mobile device, and the step of providing includes suspending the operation of the service daemon of the mobile device. application.
[0014]
14. Mobile computing device (200), comprising: a frame (210); a controller (220) coupled to the frame (210), the controller (220) configured to process applications in synchronous communication from one or more application servers, each application having a zero communication timeout period to maintain application continuity; a memory (270) coupled to the controller (220); a wireless transceiver (250) coupled to the controller (220) for synchronizing application data between the mobile computing device and the one or more application servers; and a thrust management module (290) configured to: operate an application in synchronous communication with an application server including establishing a persistent IP session with the application server, setting an active mode, in which synchronous communication is automatically activated from according to a pre-arranged schedule; provide a sleep mode in which synchronous communication is automatically disabled on the mobile device according to the pre-arranged schedule by closing the persistent IP session, the mobile computing device being characterized by the fact that the thrust management module (290) is configured to interrupt dormant mode by momentarily communicating with the application server before a null communication timeout period, to maintain application continuity, outage including establishing and closing a persistent IP session.
[0015]
15. The mobile computing device of claim 14, wherein the thrust management module (290) includes a user-programmable sleep mode scheduler to schedule the sleep mode period.
[0016]
16. Mobile computing device according to claim 14, characterized in that the thrust management module (290) is further configured to maintain other communications between the mobile device and other communication entities in active and dormant modes.
[0017]
17. Mobile computing device according to claim 14, characterized in that the thrust management module (290) is configured to switch to active mode when certain user activity is detected.
[0018]
18. Mobile computing device according to claim 14, characterized in that the thrust management module (290) includes a dormancy scheduler programmed to a value less than the shortest maximum zero communication period to maintain continuity of application for each application, and the interrupt step occurs when the dormancy timer expires.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012018632B1|2021-06-01|METHOD OF SAVING ENERGY IN A MOBILE DEVICE AND MOBILE COMPUTING DEVICE

---

KR101508045B1|2015-04-07|A mobile computing device and method with intelligent pushing management

---

KR20120011877A|2012-02-08|A mobile computing device and method with enhanced poling management

---

KR101604561B1|2016-03-17|Proxy-based push service

---

JP5648670B2|2015-01-07|Wireless device for saving power and method for saving power of a wireless device

---

Dogar et al.2010|Catnap: exploiting high bandwidth wireless interfaces to save energy for mobile devices

---

US9247495B2|2016-01-26|Power saving Wi-Fi tethering

---

US9516116B2|2016-12-06|Managing notification service connections

---

KR101557843B1|2015-10-06|Management of network access requests

---

US20100250986A1|2010-09-30|Method and Device for Improving Battery Life of a Mobile Computing Device

---

US20130301504A1|2013-11-14|Method and device with dynamic dormancy

---

WO2020030175A1|2020-02-13|Reception configuration method and apparatus, reception control method and apparatus, terminal, base station, and storage medium

---

Sharma et al.2014|Designing an energy-efficient cloud messaging service for smartphones

---

CN110928586B|2021-02-26|APP background keep-alive method and device

同族专利:

---

公开号 | 公开日

---

BR112012018632A8|2018-10-30|

---

CA2786270A1|2011-08-04|

---

US20110185202A1|2011-07-28|

---

EP2529582B1|2013-12-11|

---

ES2440331T3|2014-01-28|

---

WO2011093982A1|2011-08-04|

---

US8904206B2|2014-12-02|

---

CN102726104A|2012-10-10|

---

CA2786270C|2016-05-03|

---

CN102726104B|2016-01-20|

---

EP2529582A1|2012-12-05|

---

KR20120123477A|2012-11-08|

---

KR101377376B1|2014-03-25|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US6268546B1|1989-07-19|2001-07-31|Calgene Llc|Ovary-tissue transcriptional factors|

---

US20010015977A1|1999-10-08|2001-08-23|Stefan Johansson|Selective reception|

---

US6865683B2|2001-05-21|2005-03-08|Microsoft Corporation|System and method for powering down a mobile device|

---

US7516135B2|2003-05-30|2009-04-07|Sap Aktiengesellschaft|Dynamically managing data conveyance between computing devices|

---

US8085741B2|2004-03-10|2011-12-27|Core Wireless Licensing S.A.R.L.|System and method for pushing content to a terminal utilizing a network-initiated data service technique|

---

US20080242370A1|2006-03-31|2008-10-02|Ixi Mobile Ltd.|Efficient server polling system and method|

---

US7778269B2|2005-10-07|2010-08-17|Research In Motion Limited|Methods and systems for customized multi-application channel control|

---

EP2247146B1|2005-12-14|2011-11-16|Research In Motion Limited|Method and apparatus for user equipment directed radio resource control in a UMTS network|

---

US8077657B2|2007-03-19|2011-12-13|Intel Corporation|Keep-alive handling in a wireless network|

---

US8135392B2|2008-06-06|2012-03-13|Apple Inc.|Managing notification service connections and displaying icon badges|

---

TWI379577B|2008-08-12|2012-12-11|Acer Inc|

---

US20100250986A1|2009-03-27|2010-09-30|Motorola, Inc.|Method and Device for Improving Battery Life of a Mobile Computing Device|

---

US8780775B2|2010-05-28|2014-07-15|Intel Corporation|Method and device for reducing power drain while camped on a wireless local area network|

---

US8504002B2|2010-06-23|2013-08-06|Motorola Mobility Llc|Method and device with dynamic dormancy|

---

US8239698B2|2011-07-01|2012-08-07|Intel Corporation|System and method for maintaining connectivity to remote application servers|US7400878B2|2004-02-26|2008-07-15|Research In Motion Limited|Computing device with environment aware features|

---

US9270559B2|2009-01-28|2016-02-23|Headwater Partners I Llc|Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow|

---

US10841839B2|2009-01-28|2020-11-17|Headwater Research Llc|Security, fraud detection, and fraud mitigation in device-assisted services systems|

---

US9565707B2|2009-01-28|2017-02-07|Headwater Partners I Llc|Wireless end-user device with wireless data attribution to multiple personas|

---

US11218854B2|2009-01-28|2022-01-04|Headwater Research Llc|Service plan design, user interfaces, application programming interfaces, and device management|

---

US8346225B2|2009-01-28|2013-01-01|Headwater Partners I, Llc|Quality of service for device assisted services|

---

US8589541B2|2009-01-28|2013-11-19|Headwater Partners I Llc|Device-assisted services for protecting network capacity|

---

US10264138B2|2009-01-28|2019-04-16|Headwater Research Llc|Mobile device and service management|

---

US8406748B2|2009-01-28|2013-03-26|Headwater Partners I Llc|Adaptive ambient services|

---

US11134102B2|2009-01-28|2021-09-28|Headwater Research Llc|Verifiable device assisted service usage monitoring with reporting, synchronization, and notification|

---

US8275830B2|2009-01-28|2012-09-25|Headwater Partners I Llc|Device assisted CDR creation, aggregation, mediation and billing|

---

US10326800B2|2009-01-28|2019-06-18|Headwater Research Llc|Wireless network service interfaces|

---

US8228832B2|2010-01-25|2012-07-24|Motorola Mobility, Inc.|USSD transport method and device|

---

US8831658B2|2010-11-05|2014-09-09|Qualcomm Incorporated|Controlling application access to a network|

---

US9603085B2|2010-02-16|2017-03-21|Qualcomm Incorporated|Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications|

---

US9152650B1|2010-03-31|2015-10-06|Emc Corporation|Mobile device data recovery|

---

US8655966B1|2010-03-31|2014-02-18|Emc Corporation|Mobile device data protection|

---

US8694597B1|2010-03-31|2014-04-08|Emc Corporation|Mobile device group-based data sharing|

---

US8694744B1|2010-03-31|2014-04-08|Emc Corporation|Mobile device snapshot backup|

---

US8683005B1|2010-03-31|2014-03-25|Emc Corporation|Cache-based mobile device network resource optimization|

---

US9514089B1|2010-03-31|2016-12-06|EMC IP Holding Company LLC|Mobile device network data synchronization|

---

US8473743B2|2010-04-07|2013-06-25|Apple Inc.|Mobile device management|

---

US20110314048A1|2010-06-22|2011-12-22|Microsoft Corporation|Social network user list detection and searching|

---

EP3367252B1|2010-07-26|2019-10-16|Seven Networks, LLC|Context aware traffic management for resource conservation in a wireless network|

---

WO2013015835A1|2011-07-22|2013-01-31|Seven Networks, Inc.|Mobile application traffic optimization|

---

CA2806557C|2010-07-26|2014-10-07|Michael Luna|Mobile application traffic optimization|

---

JP5620578B2|2010-07-26|2014-11-05|セブン ネットワークス インコーポレイテッド|Mobile network traffic regulation across multiple applications|

---

US8626906B1|2010-08-10|2014-01-07|Google Inc.|Scheduling data pushes to a mobile device based on usage and applications thereof|

---

CA2811839C|2010-09-24|2017-09-05|Research In Motion Limited|Method and apparatus for differentiated access control|

---

US9378394B2|2010-09-24|2016-06-28|Blackberry Limited|Method and apparatus for differentiated access control|

---

CN102076065B|2010-11-19|2013-04-24|华为终端有限公司|Method and device of data interaction|

---

CA2798523C|2010-11-22|2015-02-24|Seven Networks, Inc.|Aligning data transfer to optimize connections established for transmission over a wireless network|

---

GB2499747B|2010-11-22|2014-04-09|Seven Networks Inc|Aligning data transfer to optimize connections established for transmission over a wireless network|

---

US20120130886A1|2010-11-22|2012-05-24|Bundle Corporation|System and method for monitoring and tracking user activities|

---

US8571487B2|2010-12-10|2013-10-29|Apple Inc.|Network status|

---

US9264868B2|2011-01-19|2016-02-16|Qualcomm Incorporated|Management of network access requests|

---

US8407776B2|2011-02-11|2013-03-26|Good Technology Corporation|Method, apparatus and system for provisioning a push notification session|

---

WO2012126018A1|2011-03-17|2012-09-20|Qualcomm Incorporated|Power optimization for smart phone applications|

---

US9178965B2|2011-03-18|2015-11-03|Qualcomm Incorporated|Systems and methods for synchronization of application communications|

---

US20120246580A1|2011-03-22|2012-09-27|Gether, LLC|Social polling|

---

US9571952B2|2011-04-22|2017-02-14|Qualcomm Incorporatd|Offloading of data to wireless local area network|

---

WO2013019225A1|2011-08-03|2013-02-07|Draeger Medical Systems, Inc.|Throughput-based active mode trigger|

---

US8548475B2|2011-08-17|2013-10-01|Apple Inc.|Method for optimizing power consumption in wireless devices using data rate efficiency factor|

---

US8838086B2|2011-08-29|2014-09-16|Qualcomm Incorporated|Systems and methods for management of background application events|

---

KR101488650B1|2011-10-05|2015-01-30|퀄컴 인코포레이티드|Systems and methods for management of background application events|

---

US9913163B2|2011-11-16|2018-03-06|Telefonaktiebolaget Lm Ericsson |UE control of downlink data|

---

US9014085B2|2011-11-28|2015-04-21|At&T Intellectual Property I, L.P.|Internet protocol session persistence for mobile communications|

---

TW201324362A|2011-12-06|2013-06-16|Askey Technology Jiangsu Ltd|Method for starting application smartly and power-efficiently|

---

KR20130071723A|2011-12-21|2013-07-01|삼성전자주식회사|Method and apparatus for processing message|

---

US8812884B2|2011-12-23|2014-08-19|Broadcom Corporation|System and method for user driven configuration sets for energy efficient networks|

---

US9529884B2|2012-01-19|2016-12-27|Microsoft Technology Licensing, Llc|Usage based synchronization of note-taking application features|

---

US9820016B2|2012-02-13|2017-11-14|Sony Mobile Communications Inc.|Methods of communicating identification information and a responsive command via short-range communications, and related devices|

---

WO2013121238A1|2012-02-13|2013-08-22|Sony Ericsson Mobile Communications Ab|Electronic devices, methods, and computer program products for detecting a tag having a sensor associated therewith and receiving sensor information therefrom|

---

US8897762B2|2012-02-28|2014-11-25|Qualcomm Incorporated|Optimizing signaling load overhead and battery consumption for background applications|

---

KR20130131959A|2012-05-25|2013-12-04|삼성전자주식회사|Method and apparatus for controlling dormancy mode in portable terminal|

---

US9104896B2|2012-06-04|2015-08-11|Apple Inc.|System and method for remotely initiating lost mode on a computing device|

---

EP3296868A1|2012-06-06|2018-03-21|Huawei DeviceCo., Ltd.|Application management method and terminal|

---

US8972762B2|2012-07-11|2015-03-03|Blackberry Limited|Computing devices and methods for resetting inactivity timers on computing devices|

---

US9596328B2|2012-08-09|2017-03-14|Oracle International Corporation|Hierarchical criteria-based timeout protocols|

---

US9203818B1|2012-08-23|2015-12-01|Amazon Technologies, Inc.|Adaptive timeouts for security credentials|

---

KR20150084017A|2012-10-22|2015-07-21|인터디지탈 패튼 홀딩스, 인크|Method and apparatus for negotiating "keep-alive" message frequencies of applications running on a mobile station|

---

CN102932760A|2012-10-29|2013-02-13|北京小米科技有限责任公司|Method, device and equipment for establishing conversation|

---

CN102984312B|2012-11-22|2016-08-17|广东欧珀移动通信有限公司|Mobile terminal of mobile telephone|

---

US9489440B2|2012-12-13|2016-11-08|Microsoft Technology Licensing Llc|Opportunistic, priority-based object synchronization|

---

US9292077B2|2013-01-04|2016-03-22|Qualcomm Incorporated|Methods and apparatus for efficient service layer assistance for modem sleep operations|

---

EP2763372B1|2013-02-01|2017-05-10|HTC Corporation|Electronic apparatus, computer-readable medium and data synchronization method|

---

US9519490B2|2013-03-07|2016-12-13|Microsoft Technology Licensing, Llc|Adaptive data synchronization|

---

KR102020358B1|2013-03-14|2019-11-05|삼성전자 주식회사|Terminal and method for synchronizing application thereof|

---

US20140289428A1|2013-03-20|2014-09-25|Microsoft Corporation|Dynamic Intervals for Synchronizing Data|

---

US9516127B2|2013-03-25|2016-12-06|Seven Networks, Llc|Intelligent alarm manipulator and resource tracker|

---

US20140359735A1|2013-05-29|2014-12-04|Sap Portals Israel Ltd|Maintaining application session continuity across devices|

---

WO2014197521A1|2013-06-03|2014-12-11|Seven Networks, Inc.|Blocking/unblocking algorithms for signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols|

---

CN108400946B|2013-06-11|2019-09-17|杭州硕文软件有限公司|It is a kind of for reducing the method, apparatus, system and medium of Internet traffic|

---

US10216549B2|2013-06-17|2019-02-26|Seven Networks, Llc|Methods and systems for providing application programming interfaces and application programming interface extensions to third party applications for optimizing and minimizing application traffic|

---

CN103327110B|2013-06-28|2016-05-25|腾讯科技（深圳）有限公司|A kind of information-pushing method and system|

---

US20150023161A1|2013-07-22|2015-01-22|Seven Networks, Inc.|Modifying system timers for optimizing mobile traffic management|

---

US9351254B2|2014-01-22|2016-05-24|Seven Networks, Llc|Method for power saving in mobile devices by optimizing wakelocks|

---

US9465711B2|2014-01-31|2016-10-11|Verizon Patent And Licensing Inc.|Providing power utilization information for operational states of an application across different operating systems|

---

US10743255B2|2014-07-25|2020-08-11|Apple Inc.|Power optimization modes for communication between device and server|

---

US20160036923A1|2014-08-03|2016-02-04|Microsoft Corporation|Efficient Migration of Application State Information|

---

US9762585B2|2015-03-19|2017-09-12|Microsoft Technology Licensing, Llc|Tenant lockbox|

---

US9414298B1|2015-05-29|2016-08-09|Apple Inc.|Dynamic aggression management of cellular connectivity|

---

US10331321B2|2015-06-07|2019-06-25|Apple Inc.|Multiple device configuration application|

---

US10931682B2|2015-06-30|2021-02-23|Microsoft Technology Licensing, Llc|Privileged identity management|

---

JP2017034307A|2015-07-28|2017-02-09|株式会社東芝|Information collection management apparatus and method, and information collection system|

---

US20180279225A1|2015-10-01|2018-09-27|Jack William Harrison|Communications device control system|

---

WO2017125143A1|2016-01-20|2017-07-27|Nokia Solutions And Networks Oy|Methods, apparatuses and computer program product for improved service continuity with mobile edge computing|

---

US10540239B2|2016-05-25|2020-01-21|International Business Machines Corporation|Back-up of information stored in mobile computing devices|

---

CN106230709B|2016-09-14|2020-02-14|Oppo广东移动通信有限公司|Method and device for distinguishing and synchronizing chat information|

---

US10812894B2|2016-12-23|2020-10-20|Motorola Solutions, Inc.|Portable communication device and method of operating the same in covert operation mode|

---

US10146288B2|2017-02-15|2018-12-04|Vigyanlabs Innovations Private Limited|Adaptive power consumption management in smart devices|

---

CN109992309B|2017-12-29|2021-03-12|Oppo广东移动通信有限公司|Application program processing method and device, electronic equipment and computer readable storage medium|

---

US11096232B2|2018-09-07|2021-08-17|Apple Inc.|Enhancements to connection rejection procedures|

法律状态:
2018-11-13| B25F| Entry of change of name and/or headquarter and transfer of application, patent and certif. of addition of invention: change of name on requirement|Owner name: MOTOROLA MOBILITY, INC (US) Free format text: A FIM DE ATENDER AS ALTERACOES DE NOME E DE ENDERECO REQUERIDAS ATRAVES DA PETICAO NO 860140193431, DE 19/11/2014, E NECESSARIO APRESENTAR A TRADUCAO JURAMENTADA DO DOCUMENTO, ALEM DA GUIA DE CUMPRIMENTO DE EXIGENCIA. |

---

2019-01-02| B25L| Entry of change of name and/or headquarter and transfer of application, patent and certificate of addition of invention: publication cancelled|Owner name: MOTOROLA MOBILITY, INC (US) Free format text: ANULADA A PUBLICACAO CODIGO 25.6 NA RPI NO 2497 DE 13/11/2018 POR TER SIDO INDEVIDA. |

---

2019-01-08| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-01-15| B25D| Requested change of name of applicant approved|Owner name: MOTOROLA MOBILITY LLC (US) |

---

2019-02-26| B25A| Requested transfer of rights approved|Owner name: GOOGLE TECHNOLOGY HOLDINGS LLC (US) |

---

2020-02-04| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-02-27| B15K| Others concerning applications: alteration of classification|Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04W 52/02 , H04L 29/08 Ipc: H04L 29/08 (2006.01), H04W 52/02 (2009.01), H04L 2 |

---

2021-04-20| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-06-01| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 30/12/2010, OBSERVADAS AS CONDICOES LEGAIS. PATENTE CONCEDIDA CONFORME ADI 5.529/DF |

优先权:

---

申请号 | 申请日 | 专利标题

---

US12/694,244|US8904206B2|2010-01-26|2010-01-26|Mobile computing device and method for maintaining application continuity|

---

US12/694,244|2010-01-26|

---

PCT/US2010/062512|WO2011093982A1|2010-01-26|2010-12-30|A mobile computing device and method for maintaining application continuity|

---