`
`PROVISIONAL PATENT APPLICATION
`
`ONE WAY INTELLIGENT HEARTBEAT
`
`Inventor:
`
`Mikko Tervahauta, a citizen of Finland, residing at San Francisco,
`
`CA, 94131
`
`Assignee:
`
`Seven Networks
`
`Entity:
`
`Small
`
`TOWNSEND and TOWNSENDand CREW LLP
`Two Embarcadero Center, Eighth Floor
`San Francisco, CA 94111-3834
`Tel: 415-576-0200
`
`
`
`ONE WAY INTELLIGENT HEARTBEAT
`
`In the art today there are performance enhancing proxies and general standardsfor
`
`improvements of TCP performance in wired and wireless networks. Some of these techniques
`
`use clients and someare clientless. Some can look at network performance to enhance the
`
`optimization they provide. As noted, some mayutilize a client and some may operateclientless.
`
`Almostall, if not all, are focused on optimization based on only a one-sided view of the
`
`networks connected to such a platform — either outbound wired, inbound/outboundwireless, or
`
`based solely on the cooperation withaclient.
`
`The present invention is directed to enabling a client device to detect the health of a
`
`server side component(and vice versa) when attempting to limit or eliminate IP signaling
`
`betweenthe client and server.
`
`Heartbeat and someother forms of connection keep-alive mechanisms are known and
`
`used in the communications industry. A periodic message can be sent, or implied from messages
`
`sent between two entities. As long as these messagesarrive on-time, each entity can assumethat
`
`the other is properly functional(i.e., healthy, operative,etc.).
`
`However, when attempting to limit the use of a radio channel in mobile networks(e.g., to
`
`increase mobile device battery life, reduce congestion or signaling, etc.) simple heartbeat
`
`messages can have the opposite effect on the system — thatis, if they are sent too often the radio
`
`channel will be activated too often, or if they are sent using alternative channels such as SMS
`
`they could result in too many expensive (to either the operator or the user) messagesthat are
`
`system overhead. Therefore, as recognized by the inventor(s), an effective means of generating
`
`and exchanging a heartbeat, indicating a functional/operational state of a component, or
`
`otherwise causing a network connection to be maintained between the functional components,is
`
`needed.
`
`
`
`Description of One or More Embodiments of the Invention
`
`Embodiments ofthe present invention provide a system that optimizes multiple aspects of
`
`the connection with wired and wireless networks and devices through a complete view of activity
`
`including: loading, current application needs on a client, controlling the type of access (pushvs.
`
`pull or hybrid), location, concentration of users in a single area, time of day, how often the user
`
`interacts with the application, content or device, and using this information to shapetraffic to a
`
`cooperative client/server or simultaneously mobile devices without a cooperative client. Because
`
`the inventive serveris nottied to any specific network providerit has visibility into the network
`
`performanceacrossall service providers. This enables optimizations to be applied to devices
`
`regardless of the operator or service provider, thereby enhancing the user experience and
`
`managing network utilization while roaming. Bandwidth has been considered the majorissue in
`
`wireless networks today. More and moreresearch has been donerelated to the need for
`
`additional bandwidth to solve access problems — manyof the performance enhancingsolutions
`
`and next generation standards, such as LTE and WiMAXare focused on providing increased
`
`bandwidth. However, history has shown that this simply doesn’t solve all the problems. A key
`
`problem is lack of bandwidth on the signaling channel more so than the data channel.
`
`Embodiments of the present invention align requests from multiple applications to
`
`minimize the need for several polling requests; leverage specific content types to determine how
`
`to proxy/manage a connection/content; and apply specific heuristics associated with device, user
`
`behavioral patterns (how often they interact with the device/application) and network parameters.
`
`Embodiments of the present invention move recurring http polls done by various widgets,
`
`RSSreadersetc. to a fixed internet (NOC), thus considerably lowering device battery/power
`
`consumption, radio channel signaling, and bandwidth usage. Additionally, embodiments of the
`
`present invention do this transparently so that existing applications do not need to be changed.In
`
`some embodiments, this can be done by implementing a local proxy on the device which
`
`automatically detects recurring requests for the same content (RSS feed, Widget dataset) that
`
`matchesa specific rule (e.g. happens every 15 minutes) and automatically caches the content on
`
`3
`
`
`
`the client while delegating the polling to the server(e.g., to a proxy or virtual proxy operated as
`
`an element of a communications network). The server would then notify the mobile/client proxy
`
`_if the content changes, and if content has not changed(or not changedsufficiently, or in an
`
`identified manner or amount) the mobile proxy provides the latest version in its cache to the user
`
`(without needto utilize the radio at all). This way the mobile device (e.g., a handset) does not
`need to open up or use a data connectionif the request is for content that is monitored andthat
`
`has been not flagged as new/changed.
`
`The logic for automatically adding URLs/content to be monitored can check for various
`
`factors like how often the content is the same, how often the same request is made(is there a
`
`fixed interval/pattern?), which application is requesting the data, etc. Similar rules to skip using
`
`the cache and request the data from the original source may also be used. For example, when the
`
`request comes at an unscheduled/unexpected time (user initiated check), or after every (n)
`
`consecutive times the response has been provided from the cache,etc., or if the application is
`
`running in the backgroundvs. in a more interactive mode of the foreground. As more and more
`
`mobile applications base their features on resources available in the network, this becomes
`
`increasingly important. Embodiments ofthe present invention also remove unnecessary chatter
`
`from the network, benefitting the operators trying to optimize the wireless spectrum usage.
`
`In some embodiments, the present invention includesadistributed proxy for network
`traffic optimization, as shown in Figure 1. The main components include a proxyclient running
`
`on a device [105], a proxy server running in the network [102], and an internal protocol between
`
`the proxy client and the proxy server [109, 110]. Typically, the proxy client and proxy server
`
`would be implementedas a set of instructions executed by a (micro) processor, although other
`
`implementationsare possible (firmware, etc.). The proxy client, shown in Figure 2, includes
`
`connection managementfunctionality [206], application protocol logic modules [213], a local
`
`cache [203], and an interface to retrieve information on device properties(e.g., information on
`
`device battery level, whether the device is being actively used or not, and the registered network)
`
`[210]. The proxy server, shown in Figure 3, includes connection managementfunctionality
`
`[302], application protocol logic modules [310], a connection and content metadata database
`
`[303], and a device information database [304].
`
`
`
`In general operation, the proxy client [202] is an application independent proxythat
`
`mobile applications [200] can use to open any TCP connection to any host. The proxyclient will
`
`detect the type of traffic and utilize an appropriate application protocol module [213] to process
`
`the traffic. With the chosen protocol/logic module, the proxy client may process the data locally
`
`and generate necessary talkback communication using its local cache, communicate the
`
`processed data along with device properties to the proxy server using the internal protocol [110],
`
`modify or delay any data before sendingit to the proxy server, detect usage patterns between
`
`similar connections and provide this to the proxy server as connection metadata, or any
`
`combination of the above.
`
`If the proxy server is contacted regarding processing the original connection, the proxy
`
`server will utilize an appropriate application protocol module [310] to processthe traffic. With
`
`the chosen protocol/logic module, the proxy server may contact the intendedtarget of the
`
`connection and route the data from the proxyclientto the target, generate talkback
`
`communication using its local cache, modify or delay any talkback communication data based on
`
`the device properties, and based on the connection metadata, start background processing to
`gather data for later use with similar connections, as well as any combination of the above.
`
`Both the proxy client and the proxy server will, where applicable continue to observe and
`
`processthe data using the application protocol modules for the entire duration of the connection.
`
`After the original connection no longer exists, the proxy client and proxy server maystill share
`
`information about the ceased connection andits properties for later use with similar connections.
`
`In this mode of operation, the proxy server maysignal the proxy client that some data in its local
`
`cacheis no longer up to date (and henceis stale), or alternatively pre-load the client cache with
`
`the fresh data. This can be donein bulk to avoid multiple radio requests, or on an application by
`
`application basis.
`
`From a mobile application’s [200] point of view, the proxy is transparent and no
`
`modifications are needed in the way the application uses the connections. Proxy-aware mobile
`
`applications [212] may also be implemented, and can provide additional information about the
`
`connection characteristics to the proxyclient.
`
`
`
`In some embodiments, the present invention offers benefits with respect to network
`
`usage, in that by serving requests from the local cache, the proxy client reduces the number of
`
`requests that are done over the wireless network. Further, the proxy client and the proxy server
`
`mayfilter irrelevant data from the communicated data. The proxy client and the proxy server
`
`may also accumulate low priority data and sendit in batches to avoid the protocol overhead of
`
`sending individual data fragments. The proxy client and the proxy server may compress or
`
`transcodethetraffic, reducing the amount of data sent over a wireless network. The signaling
`
`traffic in a wireless network is reduced, as the wireless network is used less often by optimizing
`
`small bursts away and the networktraffic can be synchronized among individual applications.
`
`With respect to the battery life of a mobile device, by serving requests from the local
`
`cache, the proxy client reduces the numberof times the radio module is powered up. The proxy
`
`client and the proxy server may accumulate low priority data and sendit in batches to reduce the
`
`numberof times and/or amountof time whenthe radio is powered up. The proxy client may
`
`synchronize the network usage by performing the batched data transfer for all connections
`
`simultaneously.
`
`In some embodiments,the present invention may be used in the case of home screen
`
`widget polling for data using HTTP,as shown in Figure 4. In the normal flow of operation, the
`
`widget performs a HTTP requestto the data provider server [405, 406]. If the data has been
`
`updated, the widget refreshes itself. The widget waits for a small period of time and starts overat
`
`the initial step. With respect to using a distributed proxy, the widget performs a HTTP request
`
`via the proxy client [407, 408]. The proxyclient detects the connection type to be a HTTP GET
`
`request. The proxyclient checks the local cache for any previous information about the request.
`
`If the locally stored responseis not available, the client updates all information about the
`
`request and the time it was madefor later use. The client sends the request to the proxy server
`
`and the server performs the request and returnsthe results. The client stores information about
`
`the result and returnsthe result to the requestor. If the same request has occurred multiple times
`
`(within a certain time period) and it has often yielded sameresults, the client notifies the proxy
`
`
`
`server that the request should be monitored for result changes [409]. If the request was marked
`
`for monitoring, the client will store the results into its local cache.If the locally stored response
`
`is available, the client will return the response from the local cache without performing
`
`communication over the wireless network [413].
`
`Independently of the widget or client operation, the server proxy will perform the
`
`requests marked for monitoring to see whether the response has changed [410]. Whenever an
`
`unexpected response is received for some request, the server will notify the client that the
`
`response has changedandthat the locally stored response on the client should be erased or
`
`replaced with a new response [416]. A subsequent data request by the client results in the data
`
`being returned from the proxy server [417, 418]. A benefit of using the distributed proxy in this
`
`case is that the wireless network is only used whenever the content for the widget has actually
`
`changed; the traffic required to check for the changesis not done over the wireless network. This
`
`reduces the amount of generated networktraffic and shortensthe total time and the number of
`
`times the radio module is powered up on the mobile device, thus reducing battery consumption.
`
`With respect to polling for changes in a mailbox, in the normalflow of operation, the
`
`mail client opens a connectionto the mail server, the mail client authenticates with the server and
`
`queries for new email, and if new mailhasarrived, a notification is shown. The mailclient then
`
`closes the connection. The mail client waits for a period of time and starts over. A variation is to
`
`leave the connection open andstart over at the second step after a predetermined period oftime.
`
`In the context of a distributed proxy, the mail client opens a connection to the mail server
`via the proxyclient, the proxyclient detects the traffic type and the chosen application logic
`
`module simulates a mail server authentication, and the proxy client looks up from the local
`
`database whether information aboutthe particular mail connectionis available. If the information
`
`is not available, the connection is routed to the proxy server, the proxy server establishes a
`
`connection to the mail server and performsauthentication using the data from the mail client, the
`
`data between the mail client and the mail serveris directly routed through the proxy connection,
`
`and when the mail client closes the connection, the proxy client may chooseto leave the actual
`
`connection to the backend open and store information about the connection into the local
`
`
`
`database for later use if the same mail connection has been used frequently. If the informationis
`
`available, the client proxy will continue to simulate mail server responses for the mail client for
`
`all queries for whichit has the data available. If the mail client performs an operation that cannot
`
`be simulated by the proxy client, the proxy client will route the data to the proxy server and the
`
`proxy server will pass the data to the mail server and route the data between the two. The proxy
`
`server may need to re-establish the connection to the mail server at this point. When the mail
`
`client closes the connection, the proxy client may choose to continue to store information about
`
`the connection for later use or it may request the proxy server to terminate the mail server
`
`connection and removeany information about the connection from the database.
`
`Independently of the mail client or the proxy client, the proxy server will query the mail
`
`server for any changesthat the mail client has previously queried. If any information in the mail
`
`server has changed,the proxyserver will notify the proxy client to stop simulating any responses
`
`based on locally cached data in order to let the mail client receive the changed data from the mail
`
`server.
`
`Embodiments of the present invention mitigate application protocol keep-alive traffic.
`
`Existing application protocols may provide long lived connections that allow servers to push
`
`updated data to the client without the need ofthe client to periodically re-establish the
`
`connection or to periodically query for changes. However,the client needs to be sure that the
`
`connection remains usable by periodically sending somedata, often called a keep-alive message,
`
`to the server and making sure the server is receiving this data. While the amount of data sent for
`
`a single keep alive messageis not significant and the keep-alive interval for an individual
`
`application is not too short, the cumulative effect of multiple applications performingthis
`
`operation individually will amount to small pieces of data being sent very frequently. Frequently
`
`sending bursts of data in a wireless network results in high battery consumption by a mobile
`
`device due to the constant need of powering the radio module. Each burst will also require a
`
`significant amount of signaling traffic in a wireless network comparedto the actual data being
`
`sent. By using the inventive distributed proxy model, the proxy client can prevent the keep-alive
`
`messages(or at least many of them) from being sent over the network and the proxy server can
`
`independently generate the required keep-alive messages to maintain the actual backend
`
`connection.
`
`
`
`In alternative embodiments, the proxy client can be implementeddirectly into the TCP/IP
`
`stack of the device operating system. The proxy client can be bundled into a wireless modem to
`
`provide transparent use for the device operating system. The proxy client can also be bundled
`
`into a firewall or a router to provide transparent use for the device operating system.
`
`Alternative embodiments apply similar techniques for a variety of protocols including
`
`HTTP, HTTPS, IMAP, POP, SMTPand ActiveSync. Use of application specific protocol
`
`handlers allows for optimization of any protocol that can be port mappedto a handerin the
`
`distributed proxy.
`
`One WayIntelligent Heartbeat
`
`As recognized by the inventor(s), by understandingthe rate of client-side requests and the
`
`rate of change in the source data that is being monitored bythe virtual proxyit is possible (on the
`
`server-side) to develop a variable value for a time interval used to control the generation of a
`
`heartbeat (or similar signaling or keep alive message), where the time interval of the invention is
`
`proportional to the average rate of change of the content that is being monitored. The interval
`
`may be adjusted dynamically, for example, being initially based on the criticality and polling rate
`
`of the specific set of URI’s (e.g., links, web-sites, content locations) being monitored, but later
`
`being based on the rate of changes in the data being monitored.
`
`Asfurther recognized by the inventor(s), using a local proxy to managesignaling and
`
`other network congestion in mobile networks can be very effective but may create a potential
`
`problem of blocking all IP traffic and disabling any access to contentif both the client side and
`
`the server side of the virtual proxy are not operational and properly functional(i.e., healthy,
`
`operative,etc.).
`
`In some embodiments, the heartbeat interval may be communicated with every heartbeat
`
`message and every cache update message. During radio access quiet time (whentheradio is
`
`dormant) if an alternative channel is available (such as SMS,or a form ofsignaling or control
`
`
`
`channel) the heartbeat can be delivered using the alternative channel. This has the beneficial
`
`impact of increasing device battery life and reducing network congestion by limiting the need to
`
`bring the radio channelinto an active mode to communicate system overhead messages(such as
`
`the heartbeat messageor interval).
`
`Initially, the heartbeat interval may be based on a polling rate. For example, assume there
`
`are multiple resources being polled on the server side with different polling intervals. Thefirst
`
`heartbeat interval may be based on the smallest (shortest) polling interval and is communicated
`
`to the client in the acknowledgementto the last polling request. In some embodiments,the
`
`interval can be configured so that it is 0.5, 1 or 2 (or N) times the smallest polling interval.
`
`In addition to the average communication(e.g., polling) rate, determining when to
`
`generate a heartbeat may also need to consider the average deviation of the communicationrate.
`
`Preferably, this should happen as soonasthe server starts communicating content changesto the
`client side. Assumethetimeinterval between two communication events from serverto client is
`
`identified as (t), with tayg being the average value of such interval. The average deviation of the
`
`actual intervals from tayg 18 dave.
`
`In this scenario, using the conceptof“trust” or reliance on the server’s health and proper
`
`operation and functioning:
`
`e The client should have full trust of the server until the time from previous communication
`
`reachestayg.
`
`e The client should have adequate trust of the server until the time reaches tays + davg.
`
`In some embodiments, beyondthis point the delay from a previous communication becomes
`
`exceptionally (or at least unacceptably) long, and the server should send a heartbeat message (or
`
`similar form of communication) to maintain the client’s trust in the server’s health (e.g., its
`
`proper functional and/or operational status).
`
`In practice, once the client receives a heartbeat from the server, it shouldsetits
`
`expectation for the next communication event based on the timestamp in the heartbeat message,
`
`10
`
`
`
`not onthe historical rate of changes which were driven by the actual data sources. The fact that a
`
`heartbeat gets sent meansthat there was a sufficient change in the rate of changes and the server
`is sending the heartbeat message(s) to bridge the gap.
`
`As mentioned,typically the interval between a last data communication andafirst
`
`heartbeat message should be basedonstatistics of the communication intervals in the past. But in
`
`some embodimentsof the invention, immediately after sendinga first heartbeat message the
`
`server shouldstart increasing that interval relatively aggressively. This may be because:
`
`(1) If there has really been a dramatic change in the average rate of communication from
`server to client, then theserver should adapt to the new level with as few heartbeat messagesas
`possible; and
`
`(2) If there hasn’t been a real change in the rate of communication and the heartbeat was
`
`sent out due to a random spikein theinterval value, then the algorithm shouldreset the interval
`
`with thefirst data package going out.
`
`In some embodiments, an aggressive increase in the heartbeat interval means multiplying
`the current heartbeat interval with a constant, not adding a constant value ontop ofit. This
`
`makes the growth exponential instead oflinear andis a fast yet predictable way of bridging the
`
`gap. Delivering the heartbeat is preferably done in a mannerthat causes minimal impact on the
`
`device’s battery life and on the signaling/data load of the mobile network. Whenthe device radio
`
`is dormant andthere is no existing data channel betweentheserverandtheclient, the heartbeat
`
`maybedelivered using an alternative channel such as SMSora signaling or control channel.
`
`11
`
`