CONSERVING POWER CONSUMPTION IN APPLICATIONS WITH NETWORK
`
`INITIATED DATA TRANSFER FUNCTIONALITY
`
`When WCDMA was specified, there was no or very little attention to requirements
`
`posed by applications whose functions are based on actions initiated by the network, in
`
`contrast to functions initiated by the user or by the device. Such applications include, for
`
`example, push email, instant messaging, visual voicemail and voice and video
`
`telephony, and others. Such applications typically require an always-on IP connection
`
`and frequent transmit of small bits of data. WCDMA networks are designed and
`
`optimized for high-throughput of large amounts of data, not for applications that
`
`require frequent, but low-throughput and/or small amounts of data. Each transaction
`
`puts radio in a high power mode for considerable length of time- typically between 15-
`
`30 seconds. As the high power mode can consume as much as lOOx the power as an idle
`
`mode, these network-initiated applications drain battery in WCDMA networks very fast.
`
`The issue has been exaggerated by the rapid increase of popularity of applications with
`
`network-initiated functionalities, such as push email.
`
`The obvious lack of proper support has prompted a number of vendors to provide
`
`documents to guide their operator partners and independent software vendors to
`
`configure their networks and applications to perform better in WCDMA networks. This
`
`guidance mainly focus on two things: configuring networks to go to stay on high-power
`
`radio mode as short as possible and making periodic keep alive messages that are used
`
`to maintain an always-on TCP/IP connection as infrequent as possible. Such solutions
`
`typically assume lack of coordination between the user, the application and the network,
`
`forcing the network to guess what the application might be doing, and application to act
`
`independently of whether user actually is available for taking action on any network(cid:173)
`
`initiated activity.
`
`Page 1 of 63
`
`GOOGLE EXHIBIT 1007
`
`

`

`Embodiments of the present invention utilize a device client that provides the front-line
`
`user interface to users for accessing various services, such as push email, instant
`
`messaging, visual voice mail etc. In context of battery conservation, the Device Client
`
`observes user activity (for example, by observing user keystrokes, backlight status etc)
`
`and alters its own behavior, as well as asks the Communications Server to alter its
`
`behavior based on user activity:
`
`(1) Cumulating/batching low priority transactions originating from the device and
`
`sending them only after user has been inactive for certain period of time. Such
`
`low priority transactions may include marking emails read or unread or deleting
`
`emails. The logic is that there is no value on sending these transactions while
`
`user is engaged with the mobile device.
`
`(2) Notifying the Communications Servers when user is inactive- a certain
`
`inactivity timeout has been exceeded. On receipt of such notification, the
`
`Communication Server may throttle down the frequency of push of new
`
`transactions to the device, thus resulting in having radio on high power less
`
`frequently. The notification will only be sent to network piggybacking on a
`
`receipt of new high importance data, such as new email, for two reasons: (a) as it
`
`is the activation of radio that drains battery, sending data to network separately
`
`would essentially consume as much battery as sending it as soon as incoming
`
`data is received (a) it ensures that user, whenever back with the device, does
`
`have the high importance data (such as new email) waiting in the inbox
`
`(3) Notifying the Communications Servers once user becomes active again,
`
`requesting immediate sending of any buffered data.
`
`Additionally, the Device Client, recognizing the time criticality of specific transactions,
`
`will interact directly with the radio interface on the device, requesting transmission on
`
`lower-power radio modes (where available) for non-critical data and high-power modes
`
`Page 2 of 63
`
`

`

`for critical data- typically where the data transfer is user-initiated and user is waiting
`
`for the response.
`
`Also, the Device Client, having the ability to control and cache data transmissions, will
`
`interact directly with the radio interface on the device, requesting radio to go idle
`
`directly after a transmission if it concludes that the probability of user-initiated time
`
`critical transmission is low. This happens, for example, in cases where Device Client has
`
`observed certain period of inactivity from the user.
`
`As a further component of the presently disclosed invention is a notification server that
`
`provides a Network Server the capability to wake up the Device Client when device
`
`client is not actively connected to the Network Server. This functionality, originally
`
`invented in a patent application referenced below has a side effect of significant power
`
`conservation, as the Device Client does not need to maintain an always-on TCP /IP
`
`connection to allow the Network Server to send updates and notifications to the Device
`
`Client. The highest significance of this is that always-on TCP /IP connection requires
`
`periodic keep alives that consume significant power. The notification server allows for
`
`the switching off of keep alives altogether, as always-on TCP/IP connection is not
`
`required, thus reducing need for frequent data transfer that drains battery in especially
`
`in WCDMA.
`
`The network server acts as the communication link between the Device Clients,
`
`Communications Servers and Notification Server.
`
`Communication server act as the Device Client's and user's agent in the network,
`
`providing connectivity to user's email inbox, instant messaging community, visual
`
`voicemail inbox, VoiP community etc. Separate Communication Servers may be used to
`
`connect to different services. In context of battery conservation, it performs two tasks.
`
`Page 3 of 63
`
`

`

`(1) When notified of user inactivity by Device Client, it sustains
`
`from sending any data to the Device Client. The sending may be
`
`resumed, for example, after a specified time, or by Device Client
`
`notifying user being active again
`
`(2) In cases where Communications Server can monitor user
`
`activity in their own data storage, such as email inbox, it will
`
`batch low priority changes (such as deletes or markings as
`
`read/unread) until inactivity is observed. The activity in the
`
`mailbox can be considered as a proxy that user is active on some
`
`other interface to their mailbox, such as their PC, and thus not
`
`actively expecting updates to their mobile device.
`
`Page 4 of 63
`
`

`

`APPENDIX A
`APPENDIX A
`
`Page 5 0f 63
`
`Page 5 of 63
`
`

`

`Batching of Low Priority Changes
`
`Current design of Cava assumes that the IP connection is always on and immediately
`sends any and all changes to the other end point. This leads to the 'real time' always up
`to date experience but also to large and undesirable battery drain. The battery drain
`comes from radio over-head introduced by the device when it sends data. Sending data
`turns out to be the expensive operation from a power consumption point of view not
`keeping a connection up. Any time the radio is used to send data- regardless the size of
`data packet being sent - the radio is left in a high power state for a number of seconds.
`This causes significant battery drain.
`
`This effect is especially strong in UMTS or 3G networks where a minimal radio on event
`seems to take as much at 2x that of an equivalent 2.5G or GPRS event.
`
`In order to minimize the negative battery drain effect we want a process for collecting
`low priority changes and sending them to the server in batches rather than individually.
`
`These proposed changes will affect all accounts/products and are fundamental changes
`to the 'always in sync' nature of our clients.
`
`Priority
`
`High
`Low
`Low
`Low
`High
`High
`
`Change
`(initiated on device)
`Send email
`Delete email
`(Un)read email
`Move message
`Read more
`Download
`attachment
`New Calendar event High
`Edit/change Calendar High
`event
`Add a contact
`Edit a contact
`Search contacts
`Change a setting
`Manual send/receive
`
`High
`High
`
`High
`
`Priority
`
`Change
`(initiated on server)
`Receive email
`Edit email
`
`High
`Often not
`possible to sync
`(Low if possible)
`New email in deleted Low
`items
`Low
`Delete an email
`Low
`(Un)Read an email
`Low
`Move messages
`Any calendar change High
`Any contact change
`High
`High
`Wipe/lock device
`Settings change
`High
`Any folder change
`High
`Connector restart
`High (if no
`changes nothing
`is sent)
`
`Page 6 of 63
`
`

`

`Manual sync- regardless of product should always cause a complete update of the
`inbox -high and low priority changes should be brought into sync and any data source
`reliant on a partial poll should complete a full poll and full sync in order to pick up all
`changes including folder changes, email deletes etc.
`
`1
`
`Client Changes (IP only and Hybrid IP & SMS)
`
`Batching Changes
`1.1
`Currently all changes are sent as soon as possible from the client to the server.
`
`4.
`
`Required changes
`1. The client will not automatically send low priority changes to the server.
`2. The client will always send any (all registered accounts) unsent low
`priority changes to the server with the any high priority change it sends
`or with or instead of any KA.
`3. The client will always immediately respond with any low priority
`changes if it receives data from the relay server (if a client receives data of
`any kind, including a ping from the OA admin UI, then the radio has
`been turned on and we should send low priority changes to the server
`while it is on)
`If low priority changes are still unsent after the user has been inactive on
`their device for 120 sees then any unsent changes should be sent to the
`server. The inactive time is brandable and defined by brand variable
`@client.inactivity _low _proirity _operation@ which is set to 120 sees by
`default. In other words once the inactive time has expired a batch of low
`priority changes is treated like a high priority change and is sent to the
`server.
`a. The inactively we want to track here is the user's interaction on
`the whole device where possible G2ME - will have to rely on
`activity within our client, other platforms we should use the
`device wide user activity timers).
`5. There needs to be a brandable parameter to turn this batching feature on
`and off. The default for this parameter should be on. Off may be needed
`for automated testing and load testing. Future requirements may need
`this on/off control to be visible in the client UI.
`
`Device Inactivity.
`1.1.1
`Our different platforms have to implement detection of device inactivity differently
`
`Initial cross code (C++) implementation of this feature sends a low priority change
`@client.inactivity _low _proirity _operation@ after the last low priority change has been
`received in the device. Although an improvement, this is not ideal as it does not delay a
`
`Page 7 of 63
`
`

`

`low priority change while the user reads an already 'read' emails or complete other non(cid:173)
`changing causing activities like writing an email.
`
`1.1.1.1 WinMo
`System SEVEN forms a plug-in to the base Operating System in this platform so we can
`not directly detect when a user is reading emails. The closest we can get to monitoring
`the user whole device activity is to request the device to notify us when the backlight
`turns off. The user idle logic for WinMo therefore needs to be:
`1. always send pending low priority changes with high priority changes
`2. when a low priority change comes in send it after the following wait:
`a. device screen goes idle and stays idle for
`@client.idle_delay _low _proirity _operation@ which should be set
`to 120 sees by default
`b. maximum wait= @client.max_delay _low _proirity _operation@ (set
`to 900 sees by default) from time any low priority change is
`received.
`
`If screen idle cannot be implemented then we will have to rely on a waiting@
`client.inactivity _low _proirity _operation@ after the last low priority change has been
`received in the device, as implemented in the initial coding noted above.
`
`1.1.1.2
`Symbian
`System SEVEN forms a plug-in to the base Operating System in this platform so we can
`not directly detect when a user is reading emails. The closest we can get to monitoring
`the user whole device activity is to use a device API that returns the 'time since last user
`activity' (usually a key press). The user idle logic for Symbian can then mirror that for
`WinMo.
`
`If screen idle cannot be implemented then we will have to rely on a waiting@
`client.inactivity _low _proirity _operation@ after the last low priority change has been
`received in the device, as implemented in the initial coding noted above.
`
`Brew
`
`1.1.1.3
`System SEVEN is the whole of the email application (and more) for BREW, so we have
`more options available for monitoring user activity. The closest we can get to monitoring
`the user whole device activity is to periodically poll the device to identify if the backlight
`is off. This is similar to our current polling for battery level. The user idle logic for Brew
`can then mirror that for WinMo.
`
`If screen idle cannot be implemented then we should watch the user for any interaction
`with our app (Is the Flash Engine up) and only sent low priority changes
`
`Page 8 of 63
`
`

`

`@client.inactivity _low _proirity _operation@ seconds after the user stops using us (exits
`the flash UI)
`
`Palm
`
`1.1.1.4
`System SEVEN is the whole of the email application for Palm, so we have more options
`available for monitoring user activity. The closest we can get to monitoring the user
`whole device activity is to watch for key press'. The user idle logic therefore needs to be:
`1. always send pending low priority changes with high priority changes
`2. when a low priority change comes in send it after the following wait:
`a. no device key presses are detected for
`@client.idle_delay _low _proirity _operation@ which should be set
`to 120 sees by default
`b. maximum wait= @client.max_delay _low _proirity _operation@ (set
`to 900 sees by default) from time any low priority change is
`received.
`
`If key press monitoring cannot be implemented then we should watch the user for any
`interaction with our app and only sent low priority changes
`@client.inactivity _low _proirity _operation@ seconds after the user stops using us.
`
`1.1.1.5
`]2ME
`System SEVEN is the whole of the email application but is limited to working within the
`J2ME 'sand box' on the device. Two 'styles' of J2ME exist on phones, one that supports a
`background mode and one that does not. J2ME can detect key strokes while we are in
`the foreground mode but not in background. We can also query the device screen and
`find out if the last screen load we sent is still being shown. The J2ME client also has to
`deal with the red key which acts as an immediate 'kill'. The user logic therefore needs to
`be:
`
`1. always send pending low priority changes with high priority changes
`2. add, a challenge screen, such that if a user selects 'exit' or minimizes
`(sends to background) then a screen is shown to the user Title: Pending
`Changes. Body: You have pending changes. Do you want to send them
`now? Buttons: Yes, No, If yes is pressed send them, if No then don't until
`user next opens the client, brings it into the foreground or a high priority
`event occurs (background sync). Even if the changes don't get send for a
`while the user is informed. The Application will exit without the 'pending
`changes screen when the red end key is pressed or a phone call/SMS
`interrupts our application, and the user says 'No' to a later 'Resume
`Application' prompt. In such cases changes will be sent on the next
`application start.
`3. The J2me app can only go into a background mode if either the user
`selects to minimize it which is covered in 2 above, or press' a direct
`
`Page 9 of 63
`
`

`

`suspend button. Because of the direct suspend button, we will need the
`client_max_delay. The main use case for J2ME is to open the app look at
`email and dose/minimize it again, in which case you will see the
`challenge screen covered in point 2 above. It will be rare for the app to sit
`with low priority changes so the added complexity of the
`client_idle_delay is not justified and is not needed.
`
`All connection errors and retries should apply in the same way that they currently do to
`any device data sends.
`
`The end result of these changes is that a user will be able to read and delete their entire
`inbox without causing the radio to be turned on until they have been inactive for a
`period of time. This inbox triage is one of the most common activities and currently
`causes significant battery drain.
`
`1.2
`
`Pruning Inbox
`
`While reviewing power logs it was noticed that we currently prune our inbox in 'real
`time'. In other words if the user has their preferences set to 'keep em ails 7 days old' then
`the moment that an email becomes 7 days and 1 sec old we initiate an email delete from
`the client side inbox. This requires a connection to the RS and causes a power event
`(even if a connection is present). Pruning the inbox is not time sensitive and does not
`justify additional power events. To minimize power usage we should 'piggy back'
`removal of old emails from our inbox window on other RS communications.
`
`Required changes
`6. The client will monitor for pruning events as per current behavior
`7. A 'pending' pruning event will never trigger a data transfer or connect
`8. Pending pruning event will be sent to the server with the next RS
`communication that takes place ..
`
`The result of this is that your inbox could become bloated with email that is out of your
`interest window but only if you have not received new email and have not used the
`client (sent and email, read/unread email, changed settings etc).
`
`2
`
`Server Changes- WE and EE connectors
`
`Currently the WE and EE connectors are aware of high and low priority changes and
`attempts to send all changes as soon as possible to the Relay Server(RS). The connector
`
`Page 10 of 63
`
`

`

`flags the priority of the changes in its message to the RS. If the client is connected the RS
`delivers the changes and tells the connector that the changes have been delivered. If the
`client is not connected the RS decides whether it will send an SMS to the client based
`upon whether the client can receive SMS's (is in Hybrid mode) and on the priority of the
`changes (SMS's are not sent for low priority changes). It then drops the actual changes
`and tells the Connector that they have not been delivered. When the client next connects
`(due to a KA or to the SMS arriving) then the RS tells the connector that the client has
`connected and the connector sends any undelivered changes to the RS for delivery to the
`client.
`
`Required changes
`1. The connector will not automatically send low priority changes to the
`client (the change here if to clients operating in IP only mode). (this could
`be implemented at the RS to mirror the SMS logic if that is easier)
`2. The connector will always send any unsent low priority changes to the
`server with the any high priority change it sends (confirm this is the case)
`3. The connector will always immediately respond with any low priority
`changes if it receives data from a client (if a connector receives data of any
`kind, including a settings updates, then the radio has been turned on and
`we should send low priority changes to the client while it is on). It would
`be nice to include KA' s here but currently they are handled by the RS and
`don't 'make it' to the connector.
`4. when a low priority change(s) are detected, send it/them after the
`following wait:
`a. no activity have been seen on their email for
`@server .inactivity_ WEEEconnector_delay _low _proirity _operation
`@which should be set to 900 sees (15 mins) by default
`b. maximum wait =
`@server.max_ WEEEconnector_delay _low _proirity _operation@
`(set to 1800 sees by default) from time any low priority change is
`received.
`5. The users inactivity period will be reset if the connector is restarted. The
`connector has to send a status packet so the radio price has to be paid
`anyway.
`
`All connection errors and retries should apply in the same way that they currently do to
`any connector data sends.
`
`The end result of these changes is that a user will be able to manage a full session from
`their rich client reading and deleting many emails before causing the radio on their
`phone to be turned on. This inbox triage is one of the most common activities and
`currently causes significant battery drain.
`
`Page 11 of 63
`
`

`

`3
`
`Server Changes- OWA& CE connector
`
`Currently the OW A & CE connectors have two ways to detect a change. Either they are
`notified by the data source or poll the data source and detect a change directly. OW A
`notifications and many ISP notification systems only notify us of high priority changes
`this is ideal as we then only send high priority changes to the client immediately. In
`order to pick up any other changes we complete a back ground poll periodically. The
`polling interval can be set for each ISP and defaults to 5 mins. Full details are available
`at: http://matrix.seven.com/disp1ay/Eng/Z7+Po11ing-t-and+Notifications
`The 5 minutes is for polling without notifications- if notifications are enabled, we only
`poll every 5*POLLING_INTERV AL minutes meaning mark-as-reads are discovered
`potentially 25 minutes they take place
`
`Required changes
`
`None
`
`CE always sends anything it finds in a poll to the client right away, but only high(cid:173)
`priority changes cause a trigger to be sent to the client. So marking emails as read results
`in a sync package being sent to the client, but if client is not online, the package will be
`nacked and CE knows changes weren't received, resending them in the next poll.
`
`If we receive a notification it will be for a high priority changes and so reacting to it by
`polling and sending data or an SMS is the correct thing to do.
`
`Items to consider for future improvements:
`1. The connector will always send any unsent low priority changes to the
`server with the any high priority change it sends but does not wait for
`high priority changes before sending the low priority changes, see
`description above.
`
`2. The connector will always immediately respond with any low priority
`changes if it receives data from a client (if a connector receives data of any
`kind, including a settings updates, then the radio has been turned on and
`we should send low priority changes to the client while it is on). It would
`be nice to include KA' s here but currently they are handled by the RS and
`don't 'make it' to the connector.
`CE doesn't start a poll every time it receives something from the client. It
`starts a poll based on a notification from ISP or based on the background
`poll timer
`
`Page 12 of 63
`
`

`

`3.
`
`If we find only low priority changes during a poll and they are still
`unsent after 3N mins (3 successive polls if account is not receiving
`notifications) then any unsent changes should be sent to the client. The
`number (3) should be a parameter that can be easily changed or
`optimized
`( @server.max_poll_repeats_low _proirity _operation@).
`This is not implemented as of now, and would be rather tricky to
`implement as we don't keep count on the changes that we find and send
`to the client. Paller finds the changes, but sync layer (who decides if a
`package is marked high priority or not) doesn't know the account history
`or context when deciding on sending the trigger- it simply checks if the
`package contains high priority changes.
`
`In other words if we have not found a high priority change in 3 polls we
`send the low priority changes and they would cause an SMS to be sent.
`If the account has received a notification and is in backup polling
`a.
`then the user may get low priority changes following every poll.
`In this scenario we should not wait 3N mins we should detect that
`3N<5N (our next poll) and send them immediately.
`
`All connection errors and retries should apply in the same way that they currently do to
`any connector data sends.
`
`Page 13 of 63
`
`

`

`APPENDIX B
`APPENDIXB
`
`Page 14 of 63
`
`Page 14 of 63
`
`

`

`Power Users Power Save Batching Emails
`
`Current design of Cava assumes that the IP connection is always on and immediately
`sends any and all changes to the other end point. This leads to the 'real time' always up
`to date experience but also to large and undesirable battery drain. The battery drain
`comes from radio over-head introduced by the device when it sends data. Sending data
`turns out to be the expensive operation from a power consumption point of view not
`keeping a connection up. Any time the radio is used to send data- regardless the size of
`data packet being sent- the radio is left in a high power state for a number of seconds.
`This causes significant battery drain.
`
`This effect is especially strong in UMTS or 3G networks where a minimal radio on event
`seems to take as much at 2x that of an equivalent 2.5G or GPRS event.
`
`In order to minimize the negative battery drain we want a process for collecting large
`numbers of new emails (or high priority changes) and syncing them in batches rather
`than individually. We are going to achieve this by introducing a 'power save' mode.
`This change is targeted at improving the power performance especially for users who
`receive a large number of emails during the day.
`
`These proposed changes will affect all accounts/products and are fundamental changes
`to the 'always in sync' nature of our clients.
`
`Power Save Mode (IP & hybrid SMS Mode)
`1
`The over view of this new mode is as follows:
`9. The client monitors user activity on the device (see section below). Each
`platform will do this in their own way but is it usually done with a
`backlight state API or monitoring keyboard clicks. If the user is active on
`the device, push behavior is as currently implemented. In IP only mode
`always-on-push is maintained in hybrid mode SMS triggers are
`immediately sent and responded too.
`10. After @client.inactivity _power_save_secs@ set to 1200 (20 mins) by
`default time has expired since the last end user device activity then the
`device goes into power saving mode.
`11. The client waits for the next new email to be delivered by the server
`(Connect to receive email etc) and responds with a power save RPC call
`to all the account end points it currently has registered. NOTE this
`
`Page 15 of 63
`
`

`

`requires a new Sync layer RPC. NOTE this may require multiple RPC
`calls (one per registered account) but they should be timed to use the
`same high power radio event, as each other and the reason for the power
`event in the first place (receiving an email), ie timed within milli-secs of
`each other..
`12. The power save RPC call will include a time (power save period)
`indicating to the connectors when the client next wants to receive any
`changes.
`13. The 1st, N power saving periods in a single power save event will be
`®client.push_batch_period_one_power_save_secs@ set to 900 (15 mins)
`by default long
`any additional consecutive power saving periods will be
`®client.push_batch_period_two_power_save_secs@ set to 3600 (1 hour)
`by default
`N = @server.push_batch_period_one_repeat_power_save_secs@ set to 4
`by default
`Any activity on the device takes the client out of power saving mode and
`end that particular power save event.
`If additional data is received before the end of any one power saving
`period, then the wait period communicated to the connectors will be the
`existing period - elapsed time since the power save RPC was sent.
`14. When a connector receives a power save notification from a device it
`stops sending changes (data or SMS' s) for the period of time requested
`(the wait period). At the end of the wait period any notifications received
`will be acted upon and changes sent to the device as a single event If no
`notifications come in then true push will resume with the data or an SMS
`being sent immediately to the device.
`15. The wait period must be able to be updated as the client may send
`additional power saving RPCs (with updated wait times) if multi
`accounts respond to the end of a wait period with different delays.
`16. Coordinating all connectors for a particular device (7TP) address to reach
`the end of a wait period together would be ideal but is not easily possible
`and will not be done at this time . We should maximize the chance that
`any change batches sent to the client from multiple accounts will arrive at
`the device at the same time and will only cause one power event by
`strictly adhering the to the wait periods send from the client unless the
`connector knows that it is 'running' slow or always takes x more sees to
`complete than our standard WE/EE backend. In this case the connector
`may start the poll or data collect event x sees early in order to increase the
`chance that the client will receive data at their specified time. NOTE this
`is at best going to increase our chances of hitting the powered up
`window. It is not fool proof and is an area for future optimization.
`
`Page 16 of 63
`
`

`

`17. Whenever new email comes into the client while it is in a power saving
`mode it responds with the power saving RPC to all end points currently
`registered. The next power save period will be communicated based on
`the logic in point 5 above.
`18. If the client needs to send aKA while it is in power saving mode then it
`sends the KA and reconnects if necessary.- optimizing the KA and
`reconnection logic during power saving mode is an area we will improve
`on in the future.
`19. Whenever the device detects user activity (key press' or backlight on)
`then it exits' power saving mode, if a power saving period is currently in
`progress then the client sends a power save cancel RPC to its backend
`connectors and immediately receives any changes associated with any
`pending notifications. This may require a poll to be run by the connector
`after receiving the power saving cancel RPC.If the latest power saving
`period has expired then no power save cancel RPC is required as the
`connectors will already be in normal true push operational mode.
`20. Devices should come out of and not go into power save mode if they are
`'plugged in' to charge.
`21. Quiet time hours should not affect the calculation of entering power save
`mode. However we should still respect the quiet time hours and
`disconnect during them. At the end of a quiet time the client should
`reconnect and receive any data waiting on the connector but should then
`immediately send another power save RPC if the device has not shown
`any end user activity. Note the timing here is critical so that the power
`event that receives the data should also cover the power save RPC.
`22. Power save RPCs should not be retried. We should just wait for the next
`new mail and send another power save RPC if appropriate.
`23. There needs to be a brandable parameter to turn support for power save
`mode on and off. The default for this parameter should be 'on'. Off may
`be needed for automated testing and load testing. Future requirements
`may need this on/off control to be visible in the client UI.
`24. Currently the CE server optimizes load by only polling a CE account once
`even if a user is accessing that account with two devices. We will poll the
`account any time either device/account require us too but will only send
`data to devices who want it (ie are not in power save mode).
`25. Calendar and contact changes will continue to be delivered as soon as
`they are discovered. They will also not trigger a power save response
`from the client. If we are sending calendar or contact data then we should
`send any pending email data also- if possible- this can be a future
`optimization.
`
`Page 17 of 63
`
`

`

`Note: Current load testing and automated testing environments do not allow for this
`type of delay to push delivery. The work to support this will need to be scheduled
`separately to the engineering work to initially implement the feature. It is also likely that
`this feature will increase test suite running times due to the delays being introduced -
`test builds/brands with shorter power saving periods are likely to be needed.
`
`The end result of these changes is that a user that receives multiple emails while not
`interacting with their phone will have a significantly prolonged battery life. The more
`emails a user receives the greate