Source: http://www.google.co.uk/patents/US20120151044
Timestamp: 2017-10-19 02:07:02
Document Index: 283658017

Matched Legal Cases: ['Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61', 'Application No. 61']

Patent US20120151044 - Distributed caching for resource and mobile network traffic management - Google Patents
Systems and methods for distributed caching for resource and mobile network traffic management are disclosed. In one aspect, embodiments of the present disclosure include a distributed proxy and cache system, including, means for, detecting a first data request made by a first mobile application on a...http://www.google.co.uk/patents/US20120151044?utm_source=gb-gplus-sharePatent US20120151044 - Distributed caching for resource and mobile network traffic management
Publication number US20120151044 A1
Application number US 13/176,537
Also published as CA2806550A1, CA2806550C, EP2599346A2, EP2599346A4, US8838783, WO2012018479A2, WO2012018479A3
Publication number 13176537, 176537, US 2012/0151044 A1, US 2012/151044 A1, US 20120151044 A1, US 20120151044A1, US 2012151044 A1, US 2012151044A1, US-A1-20120151044, US-A1-2012151044, US2012/0151044A1, US2012/151044A1, US20120151044 A1, US20120151044A1, US2012151044 A1, US2012151044A1
Inventors Michael Luna, John Haines
Original Assignee Michael Luna, John Haines
Patent Citations (23), Referenced by (93), Classifications (8), Legal Events (3)
US 20120151044 A1
Systems and methods for distributed caching for resource and mobile network traffic management are disclosed. In one aspect, embodiments of the present disclosure include a distributed proxy and cache system, including, means for, detecting a first data request made by a first mobile application on a mobile device; means for, retrieving cached elements stored in a local cache on the mobile device to respond to the first data request; means for, detecting a second data request made by a second mobile application on the mobile device, and/or means for, establishing connectivity of the mobile device to the wireless network to satisfy the second data request made.
detecting a content source, with which the mobile device interacts, as having content suitable for caching;
Storing content received from the content source as cache elements in a local cache on the mobile device;
identifying the content source to a proxy server remote from and in wireless communication with the mobile device such that the proxy server monitors the content source for new or changed data;
invaliding the cache elements in the local cache when the proxy server detects new or changed data.
2. The method of claim 1, wherein, the proxy server monitors the content source for new or changed data at a frequency that is based on polling frequency of the content source at the mobile device.
3. The method of claim 1, further comprising, monitoring polling requests directed to the content source from the mobile device to determine an interval between the polling requests.
4. The method of claim 3, wherein, a polling schedule is generated based on the interval between the polling requests directed to the content source from the mobile device.
5. The method of claim 4, wherein, the polling schedule is sent to the proxy server and used by the proxy server in monitoring the content source.
6. The method of claim 4, wherein, the polling schedule specifies a polling interval to be employed by the proxy server in monitoring the content source.
7. The method of claim 1, wherein, the proxy server transmits a message to the mobile device notifying it to invalidate the cache elements in the local cache when new or changed data is detected.
8. The method of claim 1, wherein, the content is determined to be suitable for caching based on a set of criteria.
9. The method of claim 8, wherein, the set of criteria indicates time criticality of the content requested from the content source.
10. A method of resource management in a network by caching content on a mobile device, the method, comprising:
in response to receiving polling request to contact the content server, retrieving the cached elements from the local cache to respond to the polling request made at the mobile device such that a radio of the mobile device is not activated to service the polling request.
invalidating the cache elements in the local cache when new or changed data is detected at the content server.
12. The method of claim 11, further comprising, enabling use of the radio on the mobile device to satisfy the polling request when the cache elements have been invalidated.
13. The method of claim 10, wherein, storage of the cached elements in the local cache is managed by a local proxy on the mobile device, the local proxy being able to identify the content server for which content is cached to a proxy server remote from the mobile device, wherein, the proxy server is able to establish wireless connectivity to the mobile device and communicate with the content server.
14. The method of claim 13, wherein, the proxy server monitors the content server for new or changed data, and notifies the local proxy to invalidate some or all of the cached elements.
15. The method of claim 10, wherein, a set of criteria is used to determine whether the content from the content server is stored in the local cache as cached elements.
16. The method of claim 9, wherein, the set of criteria includes, state of the mobile device indicating whether the mobile device is active or inactive.
17. The method of claim 16, wherein, the set of criteria includes, network conditions.
18. The method of claim 16, wherein, the set of criteria includes, radio coverage statistics.
19. The method of claim 16, wherein, the set of criteria includes, time-criticality of the content received from the content server.
20. The method of claim 10, further comprising, determining whether the polling request is made in response to user interaction or programmatic refresh of an application.
21. The method of claim 16, wherein, the set of criteria includes, a rate of polling requests to the content server.
22. The method of claim 10, wherein, the polling request is made by a mobile application installed on the mobile device.
a local proxy on a mobile device, which stores content from a host server as cached elements in a local cache;
wherein, the local proxy intercepts a polling request, made by a mobile application on the mobile device, to contact the host server for which received content is stored as cached elements,
wherein, the local proxy retrieves the cached elements from the local cache to provide a response to the mobile application which made the polling request such that a radio of the mobile device is not activated to provide the response to the mobile application.
the local proxy invalidates the cache elements in the local cache when new or changed data is detected at the content server.
26. The system of claim 23, further comprising,
wherein, the proxy server is able to communicate with the local proxy via a protocol,
27. The system of claim 26, wherein, the local proxy identifies to the proxy server that content received from the host server is being stored as cached elements in the local cache.
28. The system of claim 23, wherein, the local proxy applies a selection criteria to store the content from the host server which is requested by an application as cached elements in a local cache on the mobile device to satisfy subsequent requests made by the application.
29. The system of claim 28, wherein, the selection criteria includes how frequently content from the host server changes.
30. The system of claim 28, wherein, the selection criteria includes time-criticality of the content received from the host server.
31. A system for managing resources in a wireless network by caching content on a mobile device, the method, comprising:
means for, detecting a first data request made by a first mobile application on a mobile device;
means for, retrieving cached elements stored in a local cache on the mobile device to respond to the first data request;
means for, detecting a second data request made by a second mobile application on the mobile device,
means for, establishing connectivity of the mobile device to the wireless network to satisfy the second data request made.
32. The system of claim 31, wherein, the second mobile application is a time-critical application requesting time-critical data in the second data request.
33. The system of claim 31, wherein, the second mobile application is running in a foreground.
34. The system of claim 31, wherein, the first mobile application is running in a background.
35. The system of claim 31, wherein, the first data request is made when the mobile device is inactive.
means for detecting backlight status of the mobile device,
wherein, the backlight status is used in determining that the first data request is made when the mobile device is inactive.
means for, detecting another data request made by the first mobile application on the mobile device;
wherein, the another data request is made in response to user interaction with the first mobile application;
means for, enabling radio to be used on the mobile device to satisfy the other data request.
38. A machine-readable storage medium having stored thereon instructions which when executed by a processor causes the processor to perform a method of resource management in a network by caching content on a mobile device, the method, comprising:
storing content from a content source as cached elements in a local cache on the mobile device;
in response to receiving polling request to contact the content source, retrieving the cached elements from the local cache to respond to the polling request made at the mobile device such that a radio of the mobile device is not activated to service the polling request;
invalidating the cache elements in the local cache when new or changed data is detected at the content source;
enabling use of the radio on the mobile device to satisfy the polling request when the cache elements have been invalidated.
39. A method of resource management in a wireless network by caching content on a mobile device, the method, comprising:
wherein, the proxy server monitors the content source for new or changed data at a frequency that is based on polling frequency of the content source at the mobile device;
when the proxy server detects new or changed data, determining whether the cached elements in the local cache are valid based in part on detected or inferred user behavior at the mobile device.
40. A method of resource management in a wireless network by caching content on a mobile device, the method, comprising:
monitoring polling requests directed to the content source from the mobile device to identify patterns in the polling requests;
when the proxy server detects new or changed data, determining whether the cached elements in the local cache are valid based in part on the patterns in the polling requests.
This application claims the benefit of U.S. Provisional Patent Application No. 61/367,871 entitled “CONSERVING POWER CONSUMPTION IN APPLICATIONS WITH NETWORK INITIATED DATA TRANSFER FUNCTIONALITY”, which was filed on Jul. 26, 2010, U.S. Provisional Patent Application No. 61/367,870 entitled “MANAGING AND IMPROVING NETWORK RESOURCE UTILIZATION, PERFORMANCE AND OPTIMIZING TRAFFIC IN WIRE LINE AND WIRELESS NETWORKS WITH MOBILE CLIENTS”, which was filed on Jul. 26, 2010, U.S. Provisional Patent Application No. 61/408,858 entitled “CROSS APPLICATION TRAFFIC COORDINATION”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/408,839 entitled “ACTIVITY SESSION AS METHOD OF OPTIMIZING NETWORK RESOURCE USE”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/408,829 entitled “DISTRIBUTED POLICY MANAGEMENT”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/408,846 entitled “INTELLIGENT CACHE MANAGEMENT IN CONGESTED WIRELESS NETWORKS”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/408,854 entitled “INTELLIGENT MANAGEMENT OF NON-CACHEABLE CONTENT IN WIRELESS NETWORKS”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/408,826 entitled “ONE WAY INTELLIGENT HEARTBEAT”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/408,820 entitled “TRAFFIC CATEGORIZATION AND POLICY DRIVING RADIO STATE”, which was filed on Nov. 1, 2010, U.S. Provisional Patent Application No. 61/416,020 entitled “ALIGNING BURSTS FROM SERVER TO CLIENT”, which was filed on Nov. 22, 2010, U.S. Provisional Patent Application No. 61/416,033 entitled “POLLING INTERVAL FUNCTIONS”, which was filed on Nov. 22, 2010, U.S. Provisional Patent Application No. 61/430,828 entitled “DOMAIN NAME SYSTEM WITH NETWORK TRAFFIC HARMONIZATION”, which was filed on Jan. 7, 2011, the contents of which are all incorporated by reference herein.
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 focuses on: configuring networks 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.
FIG. 4B depicts an interaction diagram showing how application polls having data requests from a mobile device to an application server/content provider in a wireless network can be can be cached on the local proxy and managed by the distributed caching system.
FIG. 6 depicts a flow chart illustrating an example process for content caching on a mobile device and distributed management of content caching.
FIG. 7 depicts a flow chart illustrating an example process for distributed cache management using a polling schedule.
FIG. 8 depicts a flow chart illustrating example processes performed by the distributed cache system to determine content or content source suitability for caching.
FIG. 9 depicts a flow chart illustrating an example process for satisfying polling requests when cached elements have been invalidated.
Embodiments of the present disclosure include systems and methods for distributed caching for resource and mobile network traffic management.
By detecting the rate and type of requests to a content source or application server (which may be identified by a URI or URL), combined with determining the state information of the mobile device (e.g., whether the backlight is on or off) or the user, the distributed proxy system (e.g., the local proxy and/or the proxy server) can, for example, determine the difference between content that is programmatically refreshed and content that is requested by the user in the foreground. Using this information, along with the network conditions such as the TCP connection delay and/or RTT, current radio coverage statistics, the disclosed proxy system can determine whether to when to cache content locally on the mobile device, to satisfy future content requests. If content is already cached, then the cached version can be presented to the user. If not, the request is passed through over the mobile network to the content server and the retrieved content can be presented.
To preserve user experience, the disclosed distributed proxy system can determine and utilize the “criticality of an application” as a factor. For example, financial applications may be considered time critical so that these application requests are not cached but instead allowed to go over the mobile network to retrieve current data. An application, by name or type, can be considered critical at the time of provisioning or determined by programmatic observation of user interaction over time. That is, the sever-side component of the distributed proxy system can be provisioned with “profiles” which indicate the criticality of the application. This profile can be communicated to the device side component of the proxy system during initialization or subsequent establishment of polling requests.
Cache entries stored on the mobile device can be aged out automatically by the client-side component of the distributed proxy as determined, for example, by configurable parameters (e.g., by the user, based on application-need, network service provider requirements, OS requirements, etc.). Additionally, cache elements may be removed to remain in compliance with disk usage or entry count restrictions. In some instances, the client-side component can invalidate the entire cache storage should the server-side proxy become unavailable. In one embodiment, the client-side component of the distributed proxy system can encrypt cached content.
Functions and techniques disclosed for context aware traffic management for resource conservation in networks (e.g., network 106 and/or 108) and devices 102, reside in a distributed proxy and cache system. The proxy and cache system can be distributed between, and reside on, a given client device 102 in part or in whole and/or host server 100 in part or in whole. The distributed proxy and cache system are illustrated with further reference to the example diagram shown in FIG. 18. Functions and techniques performed by the proxy and cache components in the client device 102, the host server 100, and the related components therein are described, respectively, in detail with further reference to the examples of FIG. 2-3.
In addition, communications can be achieved via one or more networks, such as, but are not limited to, one or more of WiMax, a Local Area Network (LAN), Wireless Local Area Network (WLAN), a Personal area network (PAN), a Campus area network (CAN), a Metropolitan area network (MAN), a Wide area network (WAN), a Wireless wide area network (WWAN), enabled with technologies such as, by way of example, Global System for Mobile Communications (GSM), Personal Communications Service (PCS), Bluetooth, Wi-Fi, Fixed Wireless Data, 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, LTE Advanced, mobile WiMax, WiMax 2, WirelessMAN-Advanced networks, enhanced data rates for GSM evolution (EDGE), General packet radio service (GPRS), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA, UMTS-TDD, 1xRTT, EV-DO, messaging protocols such as, TCP/IP, SMS, MMS, extensible messaging and presence protocol (XMPP), real time messaging protocol (RTMP), instant messaging and presence protocol (IMPP), instant messaging, USSD, IRC, or any other wireless data networks or messaging protocols.
The network interface 202 can be a networking module that enables the device 250 to mediate data in a network with an entity that is external to the host server 250, through any known and/or convenient communications protocol supported by the host and the external entity. The network interface 208 can include one or more of a network adaptor card, a wireless network interface card (e.g., SMS interface, WiFi interface, interfaces for various generations of mobile communication standards including but not limited to 2G, 3G, 3.5G, 4G, LTE, etc.,), Bluetooth, or whether or not the connection is via a router, an access point, a wireless router, a switch, a multilayer switch, a protocol converter, a gateway, a bridge, bridge router, a hub, a digital media receiver, and/or a repeater.
The proxy 275 is generally application independent and can be used by applications (e.g., both proxy aware and proxy-unaware mobile applications 210 and 220) to open TCP connections to a remote server (e.g., the server 100 in the examples of FIG. 1A-1B and/or server proxy 125/325 shown in the examples of FIG. 1B and FIG. 3A). In some instances, the local proxy 275 includes a proxy API 225 which can be optionally used to interface with proxy-aware applications 220 (or mobile applications on a mobile device).
In one embodiment, characteristics of the user activity on device 250 can also be used to cause another device (e.g., other computers, a mobile device, or a non-portable device) or server (e.g., host server 100 and 300 in the examples of FIG. 1A-B and FIG. 3A) which can communicate (e.g., via a cellular or other network) with the device 250 to modify its communication frequency with the device 250. The local proxy 275 can use the characteristics information of user behavior determined by the user activity module 215 to instruct the remote device as to how to modulate its communication frequency (e.g., decreasing communication frequency, such as data push frequency if the user is idle, requesting that the remote device notify the device 250 if new data, changed, data, or data of a certain level of importance becomes available, etc.).
In general, the priorities can be set by default, for example, based on device platform, device manufacturer, operating system, etc. Priorities can alternatively or in additionally be set by the particular application; for example, the Facebook mobile application can set its own priorities for various transactions (e.g., a status update can be of higher priority than an add friend request or a poke request, a message send request can be of higher priority than a message delete request, for example), an email client or IM chat client may have its own configurations for priority. The prioritization engine 241 may include set of rules for assigning priority.
If a valid cache response is not available, or if cache responses are unavailable for the intercepted data request, the local proxy 275, for example, the caching policy manager 245, can send the data request to a remote proxy (e.g., server proxy 325 of FIG. 3A) which forwards the data request to a content source (e.g., application server/content provider 110 of FIG. 1A) and a response from the content source can be provided through the remote proxy, as will be further described in the description associated with the example host server 300 of FIG. 3A. The cache policy manager 245 can manage or process requests that use a variety of protocols, including but not limited to HTTP, HTTPS, IMAP, POP, SMTP and/or ActiveSync. The caching policy manager 245 can locally store responses for data requests in the local database 285 as cache entries, for subsequent use in satisfying same or similar data requests.
The manager 245 can request that the remote proxy monitor responses for the data request, and the remote proxy can notify the device 250 when an unexpected response to the data request is detected. In such an event, the cache policy manager 245 can erase or replace the locally stored response(s) on the device 250 when notified of the unexpected response (e.g., new data, changed data, additional data, etc.) to the data request. In one embodiment, the caching policy manager 245 is able to detect or identify the protocol used for a specific request, including but not limited to HTTP, HTTPS, IMAP, POP, SMTP and/or ActiveSync. In one embodiment, application specific handlers (e.g., via the application protocol module 246 of the manager 245) on the local proxy 275 allows for optimization of any protocol that can be port mapped to a handler in the distributed proxy (e.g., port mapped on the proxy server 325 in the example of FIG. 3A).
Such recurrences can be used by traffic shaping engine 255 to offload polling of content from a content source (e.g., from an application server/content provider 110 of FIG. 1A) that would result from the application requests that would be performed at the mobile device 250 to be performed instead, by a proxy server (e.g., proxy server 125 of FIG. 1B or proxy server 325 of FIG. 3A) remote from the device 250. Traffic engine 255 can decide to offload the polling when the recurrences match a rule. For example, there are multiple occurrences or requests for the same resource that have exactly the same content, or returned value, or based on detection of repeatable time periods between requests and responses such as a resource that is requested at specific times during the day. The offloading of the polling can decrease the amount of bandwidth consumption needed by the mobile device 250 to establish a wireless (cellular) connection with the content source for repetitive content polls.
The heartbeat manager 267 can prevent any or all of these heartbeat messages from being sent over the cellular, or other network, and instead rely on the server component of the distributed proxy system (e.g., shown in FIG. 1B) to generate the and send the heartbeat messages to maintain a connection with the backend (e.g., app server/provider 110 in the example of FIG. 1A).
FIG. 2B depicts a block diagram illustrating another example of components in the application behavior detector 236 and the caching policy manager 245 in the local proxy 275 on the client-side of the distributed proxy system shown in the example of FIG. 2A.
In one embodiment, the caching policy manager 245 includes a cache appropriateness decision engine 246, a poll schedule generator 247, an application protocol module 248, a cache or connect selection engine 249, and/or a local cache invalidator. In one embodiment, the application behavior detector 236 includes a pattern detector 237, a poll interval detector 238, an application profile generator 239, and/or a priority engine 241. The pattern detector 237, application profile generator 239, and the priority engine 241 have been described in association with the description of the pattern detector shown in the example of FIG. 2A.
The cache appropriateness decision engine 246 can detect, assess, or determine, whether content from a content source (e.g., app server/content provider 110 in the example of FIG. 1B) with which a mobile device 250 interacts, has content that may be suitable for caching. In some instances, content from a given application server/content provider (e.g., the server/provider 110 of FIG. 1B) is determined to be suitable for caching based on a set of criteria, for example, criteria specifying time criticality of the content that is being requested from the content source. In one embodiment, the local proxy (e.g., the local proxy 175 or 275 of FIG. 1B and FIG. 2A) applies a selection criteria to store the content from the host server which is requested by an application as cached elements in a local cache on the mobile device to satisfy subsequent requests made by the application.
The selection criteria can also include, by way of example, but not limitation, state of the mobile device indicating whether the mobile device is active or inactive, network conditions, and/or radio coverage statistics, as further illustrated in the flow chart in the example of FIG. 8. The cache appropriateness decision engine 246 can any one or any combination of the criteria, and in any order, in identifying sources for which caching may be suitable.
Once content has been locally cached, the cache policy manager 245 can, upon receiving future polling requests to contact the content server, can retrieve the cached elements from the local cache to respond to the polling request made at the mobile device 250 such that a radio of the mobile device is not activated to service the polling request. Such servicing and fulfilling mobile application requests locally via a local cache entries allow for more efficient resource and mobile network traffic utilization and management since network bandwidth and other resources need not be used to request/receive poll responses which may have not changed from a response that has already been received at the mobile device 250.
In one embodiment, the cache policy manager 245 sends the polling schedule is sent to the proxy server (e.g., proxy server 125 or 325 shown in the examples of FIG. 1B and FIG. 3A) and can be used by the proxy server in monitoring the content source, for example, for changed or new content. The local cache invalidator 244 of the caching policy manager 245 can invalidate cache elements in the local cache (e.g., cache 185 or 285) when new or changed data is detected from the application server/content source for a given request. The new or changed data can be, for example, detected by the proxy server. When a cache entry for a given request/poll has been invalidated, the use of the radio on the mobile device 250 can be enabled (e.g., by the local proxy or the cache policy manager 245) to satisfy the subsequent polling requests, as further described with reference to the interaction diagram of FIG. 4B.
One embodiment of the cache policy manager 245 includes a cache or connect selection engine 249 which can decide whether to use a locally cached entry to satisfy a poll/content request generated at the mobile device 250 by an application or widget. For example, the local proxy 275 or the cache policy manger 245 can intercept a polling request, made by a mobile application on the mobile device, to contact the application server/content provider. The selection engine 249 can determine whether the content received for the intercepted request has been locally stored as cache elements for deciding whether the a radio of the mobile device needs to be activated to satisfy the request made by the mobile application. In one embodiment, the local proxy 275, in response to determining that relevant cached content exists and is still valid, can retrieve the cached elements from the local cache to provide a response to the mobile application which made the polling request such that a radio of the mobile device is not activated to provide the response to the mobile application.
For example, in the distributed proxy system, local cache on the device 350 can prevent any or all heartbeat messages needed to maintain TCP/IP connections required for applications, from being sent over the cellular, or other network, and instead rely on the proxy server 325 on the host server 300 to generate and/or send the heartbeat messages to maintain a connection with the backend (e.g., app server/provider 110 in the example of FIG. 1A). The proxy server can generate the keep-alive (heartbeat) messages independent of the operations of the local proxy on the mobile device.
FIG. 3B depicts a block diagram illustrating another example of components in the caching policy manager 355 in the proxy server 325 on the server-side of the distributed proxy system shown in the example of FIG. 3A.
The caching policy manager 355, in one embodiment, can further include a content source monitoring engine 357 having a poll schedule manager 358, and/or an updated or new content detector 359.
In one embodiment, the proxy server (e.g., the proxy server 125 or 325 of the examples of FIG. 1B and FIG. 3A) can monitor a content source for new or changed data, for example, via the monitoring engine 357. The content source (e.g., application server/content provider 110 of FIG. 1B) can be one that has been identified to the proxy server (e.g., by the local proxy) as having content that is being locally cached on a mobile device (e.g., mobile device 150 or 250). The content source can be monitored, for example, by the monitoring engine 357 at a frequency that is based on polling frequency of the content source at the mobile device. The poll schedule can be, for example, generated by the local proxy and sent to the proxy server. The poll frequency can be tracked and/or managed by the poll schedule manager 358.
The proxy server can detect new or changed data at a monitored content source and transmits a message to the mobile device notifying it of such a change such that the mobile device (or the local proxy on the mobile device) can take appropriate action (e.g., to invalidate the cache elements in the local cache. In some instances, the proxy server (e.g., the caching policy manager 355) upon detecting new or changed data, can also store the new or changed data in its cache (e.g., the server cache 135 or 335 of the examples of FIG. 1B and FIG. 3A, respectively). The updated/new data stored in the server cache can in some instances, be used to satisfy content requests at the mobile device, for example, after the proxy server has notified the mobile device of the new/changed content and that the locally cached content has been invalidated.
FIG. 4B depicts an interaction diagram showing how application polls having data requests made by a mobile application/widget 455 on a mobile device to an application server/content provider 495 in a wireless network can be cached on the local proxy 465 and managed by the distributed caching system (including local proxy 465 and the host server 485 (having server cache 435 or caching proxy server 475).
In one example, when the mobile application/widget 455 polls an application server/provider 432, the poll can locally be intercepted 434 on the mobile device by local proxy 465. The local proxy 465 can detect that the cached content is available for the polled content in the request and can thus retrieve a response from the local cache to satisfy the intercepted poll 436, without requiring use of wireless network bandwidth or other wireless network resources. The mobile application/widget 455 can subsequently receive a response to the poll from a cache entry 438.
In another example, the mobile application widget 45 polls the application server/provider 440. The poll is intercepted 442 by the local proxy 465 and detects that cache content is unavailable in the local cache and decides to setup the polled source for caching 444. To satisfy the request, the poll is forwarded to the content source 446. The application server/provider 495 receives the poll request from the application and provides a response to satisfy the current request 448. In 450, the mobile application/widget 455 receives the response from the application server/provider to satisfy the request.
In conjunction, in order to setup content caching, the local proxy 465 tracks the polling frequency of the application and can setup a polling schedule to be sent to the host server 452. The local proxy sends the cache setup to the host server 454. The host server 485 can use the cache setup which includes, for example, an identification of the application server/provider to be polled and optionally a polling schedule 456. The host server 485 can now poll the application server/provider 495 to monitor responses to the request 458, on behalf of the mobile device. The application server receives the poll from the host server and responds 460. The host server 485 determines that the same response has been received and polls the application server 495, for example, according to the specified polling schedule 462. The application server/content provider 495 receives the poll and responds accordingly 464.
The host server 485 detects changed or new responses, and notifies the local proxy 466. The host server 485 can additional store the changed or new response in the server cache or caching proxy 468. The local proxy 465 receives notification from the host server 485 that new or changed data is now available and can invalidate the affected cache entries 470. The next time the mobile application/widget generates the same request for the same server/content provider 472, the local proxy determines that no valid cache entry is available and instead retrieves a response from the server cache 474, for example, through an HTTP connection. The host server 485 receives the request for the new response and sends the response back to the local proxy 475. The request is thus satisfied from the server cache or caching proxy 478 without the need for the mobile device to utilize its radio or to consume mobile network bandwidth thus conserving network resources.
Alternatively, when the mobile application generates the same request, the local proxy 465, in response to determining that no valid cache entry is available, forwards the poll to the application server provider 482 over the mobile network. The application server/provider 495 receives the poll and sends the response back to the mobile device 484 over the mobile network. The request is thus satisfied from the server/provider using the mobile network 486.
In process 602, a content source, with which the mobile device interacts, is detected as having content suitable for caching is detected. The content can be determined to be suitable for caching based on a set of criteria which indicate, for example, time criticality of the content requested from the content source. In process 604, content received from the content source is stored as cache elements in a local cache on the mobile device. In process 606, the content source is identified to a proxy server which is remote from and in wireless communication with the mobile device.
In process 608, the proxy server monitors the content source for new or changed data. In process 610, the cache elements are invalidated in the local cache when the proxy server detects new or changed data. The proxy server can monitor the content source for new or changed data at a frequency that is based on polling frequency of the content source at the mobile device. For example, polling requests directed to the content source from the mobile device can be monitored to determine an interval between the polling requests. In one embodiment, a polling schedule is generated based on the interval between the polling requests directed to the content source from the mobile device and can be sent to the proxy server and used by the proxy server in monitoring the content source.
In process 702, polling requests directed to the content source from the mobile device are monitored to determine an interval between the polling requests. In process 704, a polling schedule is generated based on the interval between the polling requests directed to the content source from the mobile device. In process 706, the polling schedule is sent to the proxy server for use by the proxy server in monitoring the content source. In process 708, using the polling schedule, the proxy server monitors the content source for new or changed data at a frequency that is based on polling frequency of the content source at the mobile device. In process 710, the proxy server transmits a message to the mobile device notifying it to invalidate the cache elements in the local cache when new or changed data is detected.
In process 802, time criticality of the content requested from the content source is determined. In process 804, state of the mobile device is determined (e.g., using backlight status). In process 806, network conditions can be determined. In process 808, radio coverage statistics can be determined. In process 810, a rate of polling requests to the content server can be determined. In process 812, it can be determined whether the polling request is made in response to user interaction or due to programmatic refresh of an application. These factors, alone or in combination, or applied in any order, can used to determine suitability of content for caching, in step 814.
In process 902, content from a content server is stored as cached elements in a local cache on the mobile device. In process 904, polling request to contact the content server is received by the mobile device.
In process 906, the cached elements are retrieved from the local cache to respond to the polling request made at the mobile device such that a radio of the mobile device is not activated to service the polling request. In process 908, the cache elements are invalided in the local cache when new or changed data is detected at the content server. For example, the proxy server can monitor the content server for new or changed data, and can notify the local proxy to invalidate some or all of the cached elements. In process 910, use of the radio on the mobile device is enabled to satisfy the polling request when the cache elements have been invalidated.
US7177912 * 24 Dec 2001 13 Feb 2007 Datacore Software Corporation SCSI transport protocol via TCP/IP using existing network hardware and software
US20040153537 * 16 Sep 2003 5 Aug 2004 Xanboo, Inc. Adaptive method for polling
US20040230739 * 21 Jun 2004 18 Nov 2004 Tsern Ely K. Memory controller with power management logic
US20100174861 * 6 Jan 2009 8 Jul 2010 Disney Enterprises, Inc. System And Method For Refreshing Cached Data Based On Content Update Frequency
US20100250695 * 11 Jun 2010 30 Sep 2010 Michael Shenfield System and method for providing asynchronous notifications using synchronous data sources
US20100332513 * 26 Jun 2009 30 Dec 2010 Microsoft Corporation Cache and index refreshing strategies for variably dynamic items and accesses
US20110040872 * 28 Oct 2010 17 Feb 2011 At&T Intellectual Property I, L.P. System and method for managing network traffic
US20110119444 * 18 Nov 2009 19 May 2011 International Business Machines Corporation Adaptive caching of data
US8755271 * 28 Jan 2011 17 Jun 2014 Broadcom Corporation Dynamic memory bandwidth allocation
US9680894 * 20 Feb 2014 13 Jun 2017 Bally Gaming, Inc. Multiple virtual machine memory usage reduction system and method
US20120195192 * 28 Jan 2011 2 Aug 2012 Broadcom Corporation Dynamic memory bandwidth allocation
US20120265842 * 13 Apr 2011 18 Oct 2012 Martin Moser Creating operating system internet connections for mobile applications
US20140172964 * 20 Feb 2014 19 Jun 2014 Bally Gaming, Inc. Multiple virtual machine memory usage reduction system and method
US20170005966 * 15 Jan 2015 5 Jan 2017 Beijing Zhigu Rui Tuo Tech Co., Ltd Information sending method and information sending apparatus
WO2014183171A1 * 19 May 2014 20 Nov 2014 National Ict Australia Limited System for efficient mobile data distribution
WO2015073826A1 * 14 Nov 2014 21 May 2015 Qualcomm Incorporated Prioritized one-shot browsing to reduce http page download delay
WO2015085321A1 * 8 Dec 2014 11 Jun 2015 Mobile Iron, Inc. Mobile device traffic management
WO2017052935A1 * 24 Aug 2016 30 Mar 2017 Intel Corporation Out-of-band platform tuning and configuration
Cooperative Classification H04L67/2842, H04L67/289, H04L67/2852, H04W4/18
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LUNA, MICHAEL;REEL/FRAME:027814/0940
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HAINES, JOHN;REEL/FRAME:035980/0814