Attorney Docket No.: 028482-003700
`
`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
`
`

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.

We are unable to display this document.

PTO Denying Access

Refresh this Document
Go to the Docket