CN102165818B - Coordinating data delivery using time suggestions - Google Patents

Abstract

Coordinating delivery of data to a first computing device from a plurality of second computing devices based on known power times for a resource associated with the first computing device. One of the second computing devices requests a time interval for data delivery. The first computing device compares the requested time interval to the known power times to determine a delivery time. For example, the requested time interval is compared against activation times for recurrent schedules that use the resource, and against previously determined delivery times. The second computing device delivers data at the determined delivery time to preserve the resource. In some embodiments, the delivery time is adjusted for processing delays and network latency.

Description

Use time proposals to coordinate data delivery

background

In recent years, mobile computing devices, such as mobile phones and personal digital assistants (PDAs), have become increasingly popular. As devices continue to get smaller, there are growing constraints on resources such as memory, storage, bandwidth, and battery power. Additionally, more applications are now consuming these resources at increasing levels. For example, many applications perform recurring tasks such as synchronizing with servers that require heavy use of the radio. After the radio on the mobile computing device is powered on to transmit data, it takes a few seconds for the radio to power off (eg, about 3 seconds on a 2.5G network and about 20 seconds on a 3G network). This radio "tail" absorbs power and reduces battery life on mobile computing devices. Additionally, there are other energy inefficiencies in spinning the radio and turning it off.

Mobile users are widely adopting connected applications with real-time data push or updates. These applications include e-mail, personal information management, presence information and other web applications. Servers push data in an uncoordinated manner, thereby degrading battery life on mobile computing devices and negatively impacting user experience.

overview

Embodiments of the invention coordinate the transfer of data from multiple second computing devices to at least one first computing device. A time interval for data transfer is requested by one of the second computing devices. The first computing device compares the requested time interval to a plurality of known power-on times for communication resources associated with the first computing device. A delivery time is determined and provided to the second computing device. Coordinated data transfer preserves communication resources on the first computing device. In some embodiments, the determined delivery time is adjusted for processing latency and network latency.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Brief description of the drawings

1 is an exemplary block diagram illustrating a first computing device receiving data from a plurality of second computing devices.

2 is an exemplary block diagram illustrating a computing device for storing known power-on times of resources and computer-executable components for implementing aspects of the invention.

FIG. 3 is an exemplary flowchart illustrating comparing a requested time interval with an activation time of a recurring schedule and previously suggested delivery times to determine a delivery time to make a recommendation to a server.

4 is an exemplary flowchart illustrating determining data delivery times and adjusting the determined delivery times based on processing delays and network latencies.

5 is an exemplary flow diagram illustrating determining data transfer times based on known power-on times of communication resources associated with a mobile computing device.

6 is an exemplary sequence diagram illustrating the scheduling of data delivery from two servers to a mobile computing device.

Corresponding reference numerals indicate corresponding parts throughout the drawings.

A detailed description

Referring to the figures, embodiments of the invention coordinate data transfer from multiple second computing devices 104 to at least one first computing device 102 to reduce consumption of communication resources on the first computing device 102 . In some embodiments, the first computing device 102 provides prompts, suggestions, recommendations, or assignments of delivery times (e.g., optimal delivery times) to the second computing devices 104 such that multiple second computing devices 104 can be delivered at the same time or Data is sent to first computing device 102 at about the same time. In the example where the first computing device 102 is a mobile computing device 602, the coordinated data transfer takes advantage of the known power-on times (e.g., radio spins) of one or more cellular radios to conserve battery on the mobile computing device 602 life. In other examples, however, aspects of the invention may be used to conserve, reduce consumption, extend life, or optimize any resource on first computing device 102 .

In some embodiments, the mobile computing device 602 utilizes known scheduling data to identify the next scheduled radio time, reserves the network latency 214, and then publishes this time to interested applications or servers. In one example, the published time is slightly ahead of the next scheduled radio time so that both server communications and device schedules can take advantage of the same radio spin. For example, a device schedule activated at 9:00 AM will publish a time of 8:59:45 AM. Subsequent server communication to evoke the radio occurred at 8:59:45 AM.

In embodiments where there is a "fuzz" or tolerance factor associated with each of the schedules 208, the tolerance factor provides a larger window of time to the target and coordinates when the second computing device 104 contacts the first computing device 102 . In an example with a ten-minute interval schedule with a tolerance factor of 50%, second computing device 104 may contact first computing device 102 at any time between time 5 and time 10 to fully utilize the radio spin. The margin factor increases the likelihood of fully utilizing the radio spin.

Referring again to FIG. 1 , an exemplary block diagram shows a first computing device 102 receiving data from a plurality of second computing devices 104, such as second computing device #1 through second computing device #N, where N is a positive integer. The second computing device 104 is connected to the first computing device 102 via a network 106 such as, for example, the Internet. In some embodiments, the scheduler 108 or other component, instruction or logic performs operations such as those shown in FIGS. 3 , 4 and 5 on the first computing device 102 .

The second computing device 104 executes the service to periodically (eg, periodically or intermittently) send data to the first computing device. In some embodiments, the second computing device 104 provides real-time content updates (eg, push mail, calendar, contacts, instant messaging, and social networking data) to the first computing device 102. The second computing device 104 may also send or receive heartbeat pings to keep the connection between the second computing device 104 and the first computing device 102 open.

The second computing device 104 includes, but is not limited to, a server, proxy server, enterprise server, or any other device that sends data to the first computing device 102 . Additionally, while described in certain embodiments with reference to a first computing device 102 including a mobile computing device 602, aspects of the invention may be used with other devices such as laptop computers, game consoles, handheld navigation devices, etc. , or any other device in communication with the second computing device 104 . Additionally, while embodiments of the invention are described with reference to a server sending data to mobile computing device 602 , aspects of the invention may be implemented in, for example, a peer-to-peer connection between first computing device 102 and second computing device 104 operate in other environments.

Referring next to FIG. 2, an exemplary block diagram illustrates a computing device 202, such as the first computing device 102, for storing known power-on times of resources and computer-executable components for implementing aspects of the present invention. . Computing device 202 includes a processor 204 and a memory area 206 or other computer-readable media. The memory area 206 stores a plurality of schedules 208, such as schedule #1 to schedule #M, where M is a positive integer. Schedule 208 is associated with second computing device 104 and provided by second computing device 104 to send data to computing device 202 . The application executes a corresponding schedule 208 to send data to or receive data from a device, such as the associated second computing device 104 , which causes the communication interface, such as a cellular radio on the computing device 202 , to be powered on. For example, an application program is hosted by computing device 202 . Each of schedules 208 has an activation time 210 , and each schedule 208 is associated with at least one of second computing devices 104 . In some embodiments, schedule 208 has recurring activation times 210 .

Execution of schedule 208 includes completing or performing one or more actions associated with schedule 208 at activation time 210 . For example, activation time 210 represents the time at which associated second computing device 104 is to send data to computing device 202 as an absolute value or offset. Transmission of data uses power-consuming resources on computing device 202 (eg, communication resources or radio resources such as one or more cellular radios). While schedule 208 represents known future times during which the communication resource is to be used, memory region 206 may alternatively or additionally explicitly store one or more known power-on times for the communication resource.

In some embodiments, the schedules 208 stored in the memory area 206 include conditional schedules 208, unconditional schedules 208, schedules 208 that consume communication resources, and schedules that do not consume communication resources (or other resources to be optimized). Schedule 208. In these embodiments, computing device 202 filters, searches, or otherwise generates a subset of schedule 208 when determining delivery times. For example, unconditional schedule 208 has a greater likelihood of being executed (e.g., a maximum likelihood of execution) than conditional schedule 208, and thus, when determining delivery time, the activation associated with unconditional schedule 208 Time 210 is given a higher priority or preference than activation time 210 associated with conditional schedule 208 .

In other embodiments, the schedule 208 is pre-sorted, pre-filtered, or otherwise grouped. For example, the memory area may store separate sets of conditional, unconditional, resource consumption, and no resource consumption schedules 208 to expedite delivery time determination.

Memory area 206 also stores processing latency 212 and network latency 214 . Processing latency 212 represents a delay due to processing on computing device 202 . Network latency 214 represents delays due to network 106 transmission of data to computing device 202 . In some embodiments, either or both of processing latency 212 and network latency 214 are expressed as offsets. Computing device 202 uses processing delay 212 and network latency 214 to provide a more accurate delivery time. In some embodiments, processing latency 212 and network latency 214 are determined by computing device 202 (eg, measuring time differences during processing or network transmission). In other embodiments, network latency 214 is provided to computing device 202 (eg, by sending data to computing device 202 with the device).

Memory area 206 also stores one or more previously determined delivery times 216 . The previously determined transfer time 216 represents a prompt or suggested time for transferring data to the computing device 202 . A previously determined delivery time 216 represents a time occurring in the future. In the example where the current time is 12:30 PM, computing device 202 determines that the delivery time is 12:40 PM and provides the delivery time to the first application. After receiving a request to deliver a time from the second application, computing device 202 knows that the previously determined delivery time is 12:40 PM and can consider providing that time to second computing device 104 to coordinate communication resources on computing device 202 The use of , as described in more detail below with reference to FIG. 3 .

Memory area 206 also stores one or more computer-executable components, such as interface component 218 , cache component 220 , prompt component 222 , and publish component 224 . The operation of these components is described below with reference to FIG. 5 .

Referring next to FIG. 3 , an exemplary flowchart illustrates comparing the requested time interval with the activation time 210 of the schedule 208 and a previously suggested delivery time 216 to determine a delivery time to make a recommendation to the server. At 302 , a computing device, such as first computing device 102 , receives a requested time value from another computing device, such as a server or second computing device 104 . In some embodiments, the time value includes a time interval or range specifying a minimum time value and a maximum time value. The time value may be an absolute time or an offset from the current time (eg, the time received by the first computing device 102). An example means for specifying time intervals is shown in Appendix A.

After receiving the requested time value, the first computing device 102 identifies one or more upcoming activation times 210 associated with the schedule 208 at 304 . For example, first computing device 102 identifies activation time 210 associated with schedule 208 for consuming communication resources (or other resources to be optimized). The first computing device 102 then identifies those activation times 210 that are associated with the unconditional schedule 208 . If no such schedule 208 is available, first computing device 102 identifies those activation times 210 that are associated with conditional schedule 208 .

Also at 304 , the first computing device 102 identifies one or more previously determined delivery times 216 . For example, first computing device 102 accesses previously determined delivery time 216 stored in memory area 206 . At 306 , the requested time value is compared to the identified activation time 210 and the previously determined delivery time 216 . Also at 306, based on the comparison, the first computing device 102 determines a delivery time. In the example where the requested time value is an interval, the determined delivery time represents time within the interval. Alternatively or additionally, the determined delivery time represents a time corresponding to one of the upcoming activation times 210 or to one of the previously determined delivery times 216 . In these embodiments, the use of the communication resource is optimized because multiple servers will use the communication resource while the communication resource is powered on.

At 308, the determined delivery time is provided to the server. The server sends the data to the first computing device 102 at the provided delivery time. In some embodiments, the requested time value is received from an application program executing on the first computing device 102 but associated with the server. In these embodiments, the determined delivery time is provided to the application. The application communicates the determined delivery time to the server, and the server sends the data to the first computing device 102 at the determined delivery time.

In embodiments where multiple servers attempt to send data to first computing device 102, each of the multiple servers has a priority associated therewith. The assigned priority is used by the first computing device 102 in determining the delivery time. For example, if a communication resource is available at a certain time interval, a server with a high priority requesting a delivery time will receive the determined delivery time at an earlier moment in the certain time interval. Servers with lower priority will receive the determined delivery time later in the specified time interval.

Referring next to FIG. 4 , an exemplary flowchart illustrates determining a data delivery time and adjusting the determined delivery time based on processing delay 212 and network latency 214 . At 402, a time interval requested by a server or other second computing device 104 (eg, by the first computing device 102) is accessed. The requested time interval represents a time range during which the server wants to send data to the first computing device 102 . At 404, the activation times 210 are searched (in some embodiments, along with the previously determined delivery times 216) to identify a subset of the activation times 210 within the requested time interval. At 406, a delivery time is determined based on the identified subset of activation times 210 to coordinate consumption of communication resources. At 408 , the determined delivery time is adjusted based on an offset corresponding to processing delay 212 and/or network latency 214 . At 410, the determined delivery time is published to the server.

Exemplary instructions or operations for determining delivery times are described in Appendix B.

Referring next to FIG. 5 , an exemplary flowchart illustrates determining a data transfer time based on known power-on times of communication resources associated with the mobile computing device 602 . In the example of FIG. 5 , interface component 218 , cache component 220 , prompt component 222 , or publish component 224 execute on mobile computing device 602 . At 502, the interface component 218 receives or accesses the requested time interval or value. This time interval is associated with expected data transfers from the server to the mobile computing device 602 . At 504 , cache component 220 identifies one or more expected power-on times for communication resources on mobile computing device 602 . The expected power-on time represents, for example, an upcoming activation time 210 or a previously determined delivery time 216 of a schedule 208 executing on the mobile computing device 602 that consumes communication resources.

At 506 , the prompt component 222 determines a delivery time based on a comparison of the requested time interval received by the interface component 218 and the expected power-on time identified by the cache component 220 . For example, the prompt component 222 sets the delivery time as the start of a time interval corresponding to one of the expected power-on times. In some embodiments, the request received by the interface component 218 includes a payload value representing the expected size of the data transfer. In these embodiments, prompting component 222 determines delivery times based on received payload values to manage bandwidth on mobile computing device 602 (eg, to avoid thrashing communication resources). For example, packets with small payloads are prioritized to be sent first, followed by packets with large payloads. Instead of or in addition to payload size, payloads traversing certain interfaces are given priority and sent in descending order of priority.

At 508, publishing component 224 provides the delivery time determined by prompting component 222 to the server. The server sends the data to the mobile computing device 602 at the provided delivery time.

In some embodiments, mobile computing device 602 has multiple cellular radios. In these embodiments, the request received by interface component 218 includes an identification of one of the plurality of cellular radios. In other embodiments, the mobile computing device 602 assigns the request to one of the cellular radios. In other embodiments, the radios used by each of the schedules 208 that have a persistent connection are tracked. The identified cellular radio becomes another variable used by prompting component 222 to determine delivery time. In these embodiments, each of the previously determined delivery times 216 stored in the memory area 206 includes an identification of the associated cellular radio. The prompt component 222 prioritizes the schedule 208 with the same identified cellular radio when determining delivery times.

Referring next to FIG. 6 , an exemplary sequence diagram illustrates the scheduling of data delivery from two servers to the mobile computing device 602 . Two applications 604 , 606 executing on the mobile device request prompts for data transfer to the mobile computing device 602 . After receiving the hint from the scheduler 108, the application 604, 606 provides the hint to the associated server 610, 612. The servers 610, 612 then attempt to send the data to the mobile computing device 602 at the prompted time.

In the example of FIG. 6 , the list of known power-on times (eg, upcoming activation times 210 or previously determined delivery times 216 ) is referred to as the ServerSendTime (server send time) list. The ServerSendTime list is created during startup of the scheduler 108 or other service and cleared when the scheduler 108 finishes processing. The ServerSendTime list is treated as a cache such that if a cache entry falls between the requested time intervals, that cache entry is considered a candidate when determining another delivery time. In some embodiments, the cache is represented as a hash map with <key, value>=<ServerSendTime, frequency> (<key, value>=<server send time, frequency>). The mapping of <ServerSendTime, frequency> is sorted by key (ServerSendTime). In this example, the mapping expedites the identification of the ServerSendTime closest to the end time.

In some embodiments, the activation time 210 for each of the schedules 208 is stored as a cache sorted by activation time 210 (eg, in ascending order). The cache stores the activation times 210 of all active schedules 208 . The cache is created or updated with each request received from the server to deliver data. In some embodiments, the scheduler 108 simply provides or publishes this cache to enable the server to choose an appropriate delivery time.

In the example of FIG. 6, after receiving the requested time interval, the scheduler 108 iterates through the cache and deletes all entries that have expired (eg, have an activation time 210 earlier than the current time). The scheduler 108 iterates through the schedule 208 to identify active and recurring subsets of the schedule 208 that use the communication resources on the mobile computing device 602 . A next activation time 210 for each schedule 208 in the subset of schedules 208 is calculated. From this subset of schedule 208, scheduler 108 identifies activation times 210 that fall within the time interval requested by the server. The scheduler 108 assigns a preference to activation times 210 associated with schedules 208 with high execution certainty. For example, schedule 208 with unconditional execution has high execution certainty. The scheduler 108 updates the cache of activation times 210 based on the identified subset of schedules 208 .

The scheduler 108 determines delivery times or other hint times based on the cache of activation times 210 and the ServerSendTime list. If one of the activation times 210 falls within the requested time interval, that activation time 210 is added to the ServerSendTime list and the frequency is set to one. If no active time 210 is satisfied in the cache of active times 210, the scheduler 108 scans the ServerSendTime list. If one of the ServerSendTimes falls within the requested time interval, that ServerSendTime is given to the requesting server and the frequency of that ServerSendTime is incremented in the list. If more than one ServerSendTime falls within the interval, the ServerSendTime with the highest frequency is chosen. If none of the ServerSendTimes falls within the requested time interval, the closest ServerSendTime is chosen (eg, based on a defined tolerance or delta region). Sets the delivery time to the closest ServerSendTime to the start. If no ServerSendTime falls within the interval, set the end time of the requested interval to ServerSendTime. The end time is then entered into the ServerSendTime list with a frequency of one (1).

While the example of FIG. 6 shows an exemplary delivery time determination, other selection methods are within the scope of aspects of the invention. Furthermore, the selection method can be changed dynamically.

In some embodiments, the minimum time value is the current time and the maximum time value represents the maximum heartbeat interval (e.g., the longest period of time that the mobile computing device 602 and the server can last without transmitting data but still remain connected) .

In one embodiment (not shown), the server is a proxy server that aggregates data from one or more servers. The proxy server aggregates the data before sending the data to the mobile computing device 602 . Proxy servers assign priorities to packets (or to servers). The priority level represents the urgency with which to send the data packet to mobile computing device 602 (eg, as opposed to tolerance for delaying the packet). The proxy server quantifies priority in terms of willingness to wait (eg, in minutes) before sending data. On mobile computing device 602, the application provides a minimum time (eg, the current time) and a maximum time equal to the period of time that the server sending the data packet is willing to delay data delivery. When the mobile computing device 602 application sends the heartbeat ping to the server, it includes the determined delivery time or a hint for the optimal future time for the server to send the data.

ServerSendTime indicates the start time for the server to send data. In embodiments where resources are known to be available for a certain period of time after ServerSendTime (eg, a cellular radio tail), the scheduler 108 takes that period of time into account. For example, a margin or delta region is set based on known cellular radio tails.

example

In one example, the mail server asks for a prompt and provides 12:00 and 12:20 as minimum and maximum times. The scheduler 108 has an active schedule with active connections scheduled for 10 minute intervals at 12:20. Scheduler 108 identifies the active schedule, adjusts the delivery time to account for network latency 214 and/or processing delay 212 (e.g., thirty seconds), determines the delivery time to be 12:19:30, and provides the determined delivery time to the server.

In a variation on the above example, no activation time 210 falls within the requested time interval. In this example, scheduler 108 sets a maximum time of 12:20 as the determined delivery time (eg, ServerSendTime).

In a continuation of the above example, another server provides 12:15 and 12:30 as minimum and maximum times. ServerSendTime equals 12:20, which falls within the requested interval. After adjusting the network latency 214, the scheduler 108 provides 12:19:30 as the determined delivery time.

Exemplary Operating Environment

By way of example, and not limitation, computer-readable media comprise computer storage media and communication media. Computer storage media store information such as computer readable instructions, data structures, program modules or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of computer readable media.

Although described in connection with an exemplary computing system environment, embodiments of the invention are applicable to numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations suitable for use with aspects of the invention include, but are not limited to: mobile computing devices, personal computers, server computers, handheld or laptop devices, multiprocessor systems, game consoles desktops, microprocessor-based systems, set-top boxes, programmable consumer electronics, mobile phones, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the foregoing systems or devices, and the like.

Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers or other devices. Computer-executable instructions may be organized into one or more computer-executable components or modules. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the invention may be implemented using any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules shown in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than shown and described herein.

Embodiments shown and described herein, as well as embodiments not specifically described herein, but falling within the scope of aspects of the invention, constitute a method for determining the radio resources based on the known radio resources within the requested time interval. Exemplary means for determining delivery time based on power-on time, and example means for adjusting delivery time based on processing delay 212 and latency.

No order of execution or implementation is required for the operations in the various embodiments of the invention shown and described herein, unless otherwise specified. That is, unless otherwise specified, the operations may be performed in any order, and embodiments of the invention may include more or fewer operations than disclosed herein. For example, it is contemplated that performing one operation before, concurrently with, or after another operation is within the scope of aspects of the invention.

When introducing elements of aspects of the invention or embodiments thereof, the articles "a", "an", "the", "said" are intended to mean that there are one or more of the elements. The terms "comprising", "comprising" and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements.

Having described the aspects of the invention in detail, it will be apparent that various modifications and changes can be made without departing from the scope of the aspects of the invention as defined in the appended claims. Various changes could be made in the above constructions, products and methods without departing from the scope of the aspects of the invention, and all matter contained in the above description and shown in the various drawings should be construed as illustrative sexual, not restrictive.

Appendix A

The Application Programming Interface (API) shown below enables applications to provide minimum time and maximum time intervals. A scheduler executing on the first computing device returns a reminder (eg, in a uniform timecode format) that falls between two intervals. The API signature is as follows.

//prerequisites:-

// startTime<=endTime(start time<=end time)

// CurrentTime<=endTime(current time<=end time)

// Postconditions: -

// startTime<=serverSendTime and serverSendTime<=endTime(start time<=server send time and server send time<=end time)

HRESULT TaskSchedulerGetBestNetworkTimeInRange(__in const FILETIME*startTime, __in const FILETIME*endTime, __out FILETIME*serverSendTime);

This API gets the prompt time for the server to send data to the device between startTime (start time) and endTime (end time).

parameter

startTime

[input] The start time of the interval.

endTime

[input] The end time of the interval.

serverSendTime

[Output] The prompt time when the server needs to send data to the device.

return value

S_OK

The value to return if successful.

E_INVALIDARG

The value to return if any precondition fails or for an invalid argument.

E_FAIL

The value to return if unsuccessful.

An exemplary API for canceling a hint previously returned by TaskSchedulerGetBestNetworkTimeInRange() is shown below. This API is used by any requester who ends up not using hints. This API improves the accuracy and effectiveness of aspects of the present invention at least because the time suggested at the time of publication has a higher weight. With this API function call, the scheduler closely tracks the use of hint time values and refines the heuristics used internally by the scheduler when distributing hint times at a later time. In the following example, the caller (account) who cancels an existing prompt using TaskSchedulerCancelBestNetworkTime (TaskSchedulerCancelBestNetworkTime) and the caller (account) who gets a prompt using TaskSchedulerGetBestNetworkTimeInRange ( account) are the same.

HRESULT TaskSchedulerCancelBestNetworkTime(__in const FILETIME*serverSendTime);

parameter

serverSendTime

[in] The prompt time previously returned by TaskSchedulerGetBestNetworkTimeInRange.

return value

S_OK

Publishing of reminder times has been tracked.

S_FALSE

Prompt time not recognized (value has "expired" or value was not previously returned by TaskSchedulerGetBestNetworkTimeInRange).

E_*

Encountered another failure while processing the request.

Appendix B

Exemplary instructions or operations for determining delivery times are shown below.

The ServerSendTime list is created during service startup and cleared when the service stops. The list is treated as a cache so that if a cache entry falls between intervals, that cache entry can be considered a candidate for ServerSendTime without having to iterate through all timetables and calculate ServerSendTime again. A cache can be represented internally as a hash map with <key, value>=<ServerSendTime, mapAcctIdtoFreq> (<key, value>=<server send time, mapping of accountId to frequency>), where mapAcctIdtoFreq is A hash map of owner account ids to frequencies, and can be defined as:

map<ACCTID, DWORD> mapAcctIdtoFreq;

The map of <ServerSendTime mapAcctIdtoFreq> is sorted by key (ServerSendTime).

A <NRT> list sorted by NRT (Next Runtime) is also maintained. The list is created every time the API is called. This list stores the NRTs of all active schedules.

An exemplary algorithm for determining delivery time is described next.

1. Iterate through the cache and delete all entries that have expired (eg, those for which NRT < CurrentTime (Next Runtime < Current Time)).

2. If starttime==endTime (start time==end time), if this value does not exist in cache <ServerSendTime, mapAcctIdtoFreq>, then add this value to this cache, otherwise if ServerSendTime already exists in cache, Then add/increment the frequency in mapAcctIdtoFreq.

3. If a ShrinkFactor (shrink factor) is defined in the registry, the (starttime-endTime) interval is reduced based on the shrink factor. Push Starttime to newStartTime (new start time) and interval becomes (newStartTime-endTime).

If undefined, newStartTime = starttime.

This is done so that the hinttime is always close to the end time.

4. Iterate over the group collection.

5. Iterate over all schedules in each group.

6. Only schedules that meet the following conditions are considered.

a) Recurrence! = BOOTUP(loop != bootup)

b) Network Connectivity = TRUE (Schedules without Network Connectivity are not considered SendServerTime as they may or may not help reduce radio spin)

c) If IsCellularPreferred = 1, only consider schedules with CELLULAR = ON. If IsCellularPreferred = 0 (cellular preferred = 0), then the CELLULAR condition is not considered.

d) Active=TRUE (active=true). The schedules considered include those that are currently active and will remain active in the future given the newStartTime-endtime and the MaxRuncounts (maximum run count) condition is met.

7. Create a ServerSendTime from the list created in step 6 as described next.

For each schedule selected in the list (e.g., created in step 6), calculate the Nth runtime. Use the formula to calculate the Nth runtime.

For cycle average

NRT(N)=NRT(N-1)+CurrentIntervalDuration (current interval duration)

for cycle interval

NRT(N)=NRT(N-1)+CurrentIntervalDuration (current interval duration)

where NRT(0) = the next runtime of the group activity schedule.

Only schedules that fall into the following two categories are considered.

a) Unconditional and is the only timetable in the group

b) An unconditional schedule and all other schedules in the group are also unconditional.

If at least one schedule with certain conditions exists in the group, the group is not considered as ServerSendTime.

8. This gets a list of <NRT>s and a cache of <ServerSendTimes, mapAcctIdtoFreq>. Next, the "best" reminder time in the interval <newStartTime, endTime> is selected. Based on the registry setting IsPreferredCache (cache is preferred), at least two permutations are possible

a) If IsPreferredCache=1 (advanced cache is preferred=1), then first in the high

Find in the cache <ServerSendTimes, mapAcctIdtoFreq>

ServerSendTime.

If only one ServerSendTime is found, go to step 10.

If multiple ServerSendTime values are found, look for the one with the largest frequency

ServerSendTime and go to step 10.

If multiple ServerSendTime values are found and two or more ServerSendTime

With the same maximum value, the selection is based on UseEndtime (use end time)

The value of the registry value.

If UseEndTime=1

The value close to the end interval is chosen

If UseEndTime=1

then select a value close to the start interval

Else, if not found in cache, look in list <NRT>

b) If IsPreferredCache = 0 (cache is preferred = 0), then first in column

Look up ServerSendTime in table <NRT>. If ServerSendTime is found,

Then go to step 10.

If multiple NRTs are found, the one based on the UseEndTime registry value is selected

value

If UseEndTime=1

The value close to the end interval is chosen

If UseEndTime=1

then select a value close to the start interval

Else, if not found in list <NRT>, look in cache

<ServerSendTime, mapAcctIdToFreq>

9. If ServerSendTime is not found from step 8, then

If ShrinkFactor=0

Compute the delta region and read from the cache in the delta region

<ServerSendTime, mapAcctIdtoFreq> lookup

ServerSendTime. Incremental regions can be thought of as

Starttime - Increment to Starttime

  If ServerSendTime is not found in the delta zone either, then based on

Use the UsedEndTime registry value to assign ServerSendTime

If UseEndTime=1

Then ServerSendTime＝Endtime

If UsedEndTime=0

  then ServerSendTime＝StartTime

If ShrinkFactor=1

Because the starttime has been pushed as the new value, in this case

Unable to check delta region.

  Assign ServerSendTime as EndTime.

ServerSendTime＝Endtime

10. If ServerSendTime is found from step 8, then

a. Use NetworkLatencyAdjustment (network latency adjustment) to adjust

ServerSendTime

ServerSendTime＝ServerSendTime-NetworkLatencyAdjustment

Check if new ServerSendTime > StartTime. (No ShrinkFactor applied

StartTime)

If not, assign ServersendTime=StartTime. (No ShrinkFactor applied

StartTime)

11. Now calculate the ServerSendTime, look up the ServerSendTime value in the cache <ServerSendTimes, mapAcctIdtoFreq>.

a. If not found in cache, add this value along with the value of the owner account id and frequency = 1

b. If found in the cache, look up the account id. Increment the frequency if the account id also exists. If AccountId does not exist, add the AccountId and Frequency = 1.

12. If TaskSchedulerCancelBestNetworkTime is called with a time value, the cache <ServerSendTimes, mapAcctIdtoFreq> will be searched for that value. If the value is found in the cache, the corresponding mapAcctIdtoFreq is searched for the owner account id. If a value is found in mapAcctIdtoFreq, decrement the frequency.

When frequency = 0, the entry is removed from mapAcctIdtoFreq.

Likewise, if mapAcctIdtoFreq is empty, the ServerSendTime value is removed from the cache <ServerSendTimes, mapAcctIdtoFreq>.

Notice:

1) NetworkLatencyAdjustment is a value determined using network latency and processing delay. This is a configurable registry entry to account for network latency. Every time ServerSendTime is returned, the offset should be set with NetworkLatencyAdjustment.

2) If the absolute time of the device changes, the time value in the cache <ServerSendTime, frequency> needs to be adjusted based on the time change. This can be done by registering with notifications for time-changed events.

3) There may be a scenario where the API is called with a start/end time that is too far in the future (for example, the interval is 10 years later). In this case, bounds checks are performed in the API (for example, the interval is within 24 hours from the current time) instead of calculating NRT<N>.

4) Registry values including StarttimePreferred/EndtimePreferred (preferred start time/preferred end time) and FrequencyPreferred (preferred frequency) are configurable registry entries. Based on these registry values, the selection algorithm can be changed dynamically.

Claims (20)

1., for advising the system of the time sending the data to mobile computing device via network from server, described system comprises:

For accessing the device in the time interval for sending the data to described mobile computing device that described server is asked;

For searching for the device that the multiple activationary times be stored in memory area identify the subset of described multiple activationary time based on the asked time interval, described activationary time is associated with multiple timetable, the activation of wherein said multiple timetable consumes the radio resource on described mobile computing device, and described memory area also stores the side-play amount of stand-by period representing process time delay on described mobile computing device and be associated with described network;

For determining the device of passing time based on the subset of identified described multiple activationary time;

For adjusting the device of determined passing time based on the side-play amount be stored in described memory area; And

For issuing the device of the passing time through adjustment, wherein said server sends the data to described mobile computing device based on the issued passing time through adjustment.

2. the system as claimed in claim 1, is characterized in that, determined passing time comprises the side-play amount from current time.

3. the system as claimed in claim 1, is characterized in that, also comprise for from perform at described mobile computing device, the application program that is associated with server receives the device in the described time interval.

4. the system as claimed in claim 1, is characterized in that, described server sends the data to described mobile computing device at issued activationary time.

5. the system as claimed in claim 1, is characterized in that, the device of in described subset selected by the timetable also comprised for being had maximum execution possibility by mark.

6. the system as claimed in claim 1, it is characterized in that, described mobile computing device comprises multiple radio, described system comprises the device for receiving from described server the request in the described time interval, described request identifies one in described radio, and for searching for the device of stored multiple activationary times based on the asked time interval and the radio identified.

7. the system as claimed in claim 1, is characterized in that, also comprises:

For determining the device of described passing time based on the known power source opening time of the described radio resource in the asked time interval; And

For adjusting the device of described passing time based on described process time delay and stand-by period.

8., for the method to server suggestion passing time, comprising:

First computing equipment receives the time value of asking from the second computing equipment;

Identify the multiple activationary times be associated with multiple timetable, the activation of wherein said multiple timetable consumes the resource on described first computing equipment,

Identify one or more passing time previously determined;

Asked time value and the multiple activationary time identified and the described passing time previously determined identified are compared;

Relatively passing time is determined based on described; And

Determined passing time is supplied to described second computing equipment, and wherein said second computing equipment sends the data to described first computing equipment at provided determined passing time.

9. method as claimed in claim 8, is characterized in that, receives the time value of asking and comprises reception minimum time value and maximum time value.

10. method as claimed in claim 8, it is characterized in that, the application program that the time value that reception is asked comprises from being associated with described second computing equipment receives the time value of asking, the execution of application program described in described first computing equipment main memory, and comprise determined passing time is supplied to described application program to be sent to the second computing equipment.

11. methods as claimed in claim 8, it is characterized in that, described second computing equipment is one in multiple computing equipment, each in wherein said multiple computing equipment has priority associated with it, and determines that the priority that described passing time comprises based on being associated with described second computing equipment determines described passing time.

12. methods as claimed in claim 8, is characterized in that, identify described multiple activationary time and comprise the multiple activationary times identifying and be associated with unconditional timetable.

13. methods as claimed in claim 8, it is characterized in that, described time value comprises the time interval, and determines that described passing time comprises and determine in the described time interval and and the corresponding passing time of in the described passing time previously determined one.

14. methods as claimed in claim 8, it is characterized in that, described time value comprises the time interval, and determines that described passing time comprises and determine in the described time interval and and the corresponding passing time of in described multiple activationary time one.

15. methods as claimed in claim 8, it is characterized in that, described time value comprises the time interval, and determines that described passing time comprises the passing time determined in the described time interval, wherein a little earlier in described multiple activationary time one of determined passing time.

16. methods as claimed in claim 8, is characterized in that, also comprise:

Determine and the processing delay that described first computing equipment is associated; And

Determined passing time is adjusted based on determined processing delay.

17. 1 kinds of systems transmitted for the data managing the first computing equipment, described system comprises:

For receiving the interface module in the asked time interval, described the asked time interval is associated with transmitting from the second computing equipment to the anticipatory data of described first computing equipment;

For identifying the cache module of the multiple expection power-on time be associated with the communication resource on described first computing equipment,

For comparing based on the time interval received by described interface module and the multiple expection power-on time identified by described cache module the reminding module determining passing time; And

For the passing time determined by described reminding module being supplied to the release module of described second computing equipment, wherein said second computing equipment sends the data to described first computing equipment at provided passing time.

18. systems as claimed in claim 17, it is characterized in that, described interface module, cache module, reminding module and release module perform on described first computing equipment.

19. systems as claimed in claim 17, it is characterized in that, the described communication resource comprises cellular radio, and wherein said reminding module determines described passing time by the starting point of be set to by described passing time in the described expection power-on time of described cellular radio in the asked time interval.

20. systems as claimed in claim 17, it is characterized in that, described interface module also receives the pay(useful) load value of the expection size representing the transmission of described anticipatory data, and based on received pay(useful) load value, wherein said reminding module determines that described passing time is to manage the bandwidth on described first computing equipment.