US20140335911A1 - Predictive Caching of IP Data on Mobile Device - Google Patents

Abstract

Disclosed is a technique for caching IP content data for a mobile device. In the mobile device, a content request is sent to a server over an IP network, the content request indicative of IP content data of interest to the mobile device. The server retrieves the requested IP content data from content servers and queues the requested IP content data in a buffer associated with the mobile device. A notification message is sent to the mobile device indicating that the requested IP content is queued. The mobile device determines whether it is connected to a non-cellular IP network access point and automatically downloads the queued IP content data from the server when connected to a non-cellular IP network. The IP content data is stored in a cache memory in the mobile device. Other embodiments are disclosed.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. application Ser. No. 14/024,780, filed Sep. 12, 2013 entitled “Predictive Caching of IP Data”. The patent application identified above is incorporated here by reference in its entirety.
BACKGROUND
• Mobile devices such as smartphones and some tablet style computers are often equipped with multiple RF transceivers that are capable of wirelessly connecting with different networks. For example, a mobile device may employ a cellular transceiver to allow a user to make and receive telephone calls, send text messages, and exchange Internet Protocol (IP) data over a cellular access network. That same mobile device may also employ a second RF transceiver that operates on a non-cellular network such as, for instance, one that operates over the 802.11 family of protocols that are commonly known as WiFi. In addition, the mobile device may also employ another RF transceiver such as, for instance, one that operates over the 802.16 family of protocols that are commonly known as WiMax. The WiFi or WiMax transceiver(s) may be used for IP network access (e.g., Internet access) anytime the mobile device is within range of a WiFi or WiMax IP network access point.
• In terms of user convenience and cost, it is preferable to utilize a non-cellular network transceiver such as the WiFi or WiMax transceivers over the cellular transceiver whenever possible. Non-cellular (e.g., WiFi or WiMax) access is generally free whereas cellular access to IP networks comes at a price. Moreover, the cost can escalate the more IP data is consumed.
• As mobile devices such as smartphones become ubiquitous, the demand for ‘mobile’ IP data access continues to grow. Limiting such IP network access to cellular network access points only drives costs up for consumers and tax or stress the cellular carrier's IP data network. The end result may lead to higher costs and less than expected quality of service in terms of network access speeds or even the ability to establish and maintain an IP network connection in areas of high congestion. The ability to use non-cellular (e.g. WiFi or WiMax) IP connectivity greatly alleviates the aforementioned problems.
• However, one of the greatest attributes of a mobile device is its mobility. This means that the user will often find herself without non-cellular connectivity at times but with a need or desire to consume IP data from sources external to the mobile device. The mobile device may do so utilizing the cellular access network for IP data services. Doing so, however, invokes the costs of using the network as previously mentioned. Thus, the user may desire to minimize to the greatest extent possible any dependence on the cellular network for IP data consumption.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates an exemplary networked environment for implementing certain exemplary embodiments described herein.
• FIG. 2 is a block diagram illustrating some of the functions of a mobile device according to one or more embodiments described herein.
• FIG. 3 is a logic flow diagram according to one or more embodiments described herein.
• FIG. 4 is a logic flow diagram according to one or more embodiments described herein.
• FIG. 5 illustrates an exemplary networked environment for implementing certain exemplary embodiments described herein.
• FIG. 6 is a logic flow diagram according to one or more embodiments described herein.
• FIG. 7 is a logic flow diagram according to one or more embodiments described herein.
DETAILED DESCRIPTION
• Embodiments described herein disclose methods and techniques to cache IP data locally on the mobile device while the device has non-cellular (e.g., WiFi or WiMax) IP network connectivity. The IP data that is cached may be pre-determined ahead of time based on user usage patterns and/or user instruction. The terms IP data, content, or IP content data may be used interchangeably throughout this disclosure and refer to data of interest to a user of a mobile device wherein the data is remotely stored but is accessible to the mobile device over an IP network connection. The IP network connection may be facilitated by a WiFi transceiver, a cellular transceiver, or an alternate transceiver (e.g., WiMax) housed within the mobile device. The IP data may be representative in whole or in part of textual data, graphical data, audio data, video data, or combinations thereof. The underlying data may be stored or represented in a variety of file formats or protocols and may or may not be encrypted. For example, text data may be stored in a file such as a Microsoft™ Word file, a pdf file, or http text data. Graphical data may be in the form of images stored as bitmap, JPEG, GIF, or other image file formats. Audio data may be stored in an MP3 or .wav format while video data may be stored as MPEG, .avi, etc. The underlying data, regardless of its actual format, is considered IP data when it is packaged and transported to the mobile device over an IP connection. The embodiments are not limited to these examples.
• For example, if the user typically accesses the same specific web-sites from the mobile browser most days, the mobile device may be instructed to fetch and cache the IP content from the specific web-site while the mobile device has non-cellular (e.g., WiFi or WiMax) IP network connectivity. In some cases, the mobile device may even include wired IP network connectivity such as, for instance, an Ethernet connection. In this manner, the user may access the web site IP data at a later time through cache memory without having to access a cellular network. The mobile device may also acquire intelligent data as to non-cellular IP network connectivity patterns such that the background caching may be performed at certain times. The caching may also be performed or updated anytime the mobile device has non-cellular IP network connectivity to keep the mobile device as up to date as possible for content that may be refreshed periodically. In addition, the caching may be performed in such a manner that allows the user to access the IP data from the native mobile device application that they normally would. For instance, web browsing data may be accessed using a mobile browser while content specific applications (e.g., Fox News™, CNN™, USA Today™, etc.) that operate on the mobile device in their own applications may be accessed using the native application. In this manner, the user experience does not change when accessing cached IP data. The user may still access the data from the native application she would normally use.
• In one embodiment, the mobile device may monitor usage and behavior patterns to create items of content (e.g., IP data) to download and locally store on the mobile device. The mobile device may then pull the content from the content providers over the Internet at a time when the mobile device is typically connected to the Internet via WiFi, WiMax, or another non-cellular IP network access point. The mobile device may collect IP data consumption and usage information associated with a mobile device. The mobile device may predict, based on the collected IP data consumption usage information, IP data the mobile device can be expected to consume at a future time. The mobile device may then automatically download the predicted IP data to the mobile device over a non-cellular connection and store the downloaded predicted IP data in cache memory on the mobile device.
• To facilitate the process and help ensure that the cellular data network is not used, the mobile device may also collect non-cellular network connectivity information associated with the mobile device and predict, based on the collected non-cellular network connectivity information, when the mobile device can be expected to be connected to a non-cellular network. The mobile device may then attempt to perform the automatic downloading of the predicted IP data at a time when the mobile device can be expected to be connected to a non-cellular network. If the mobile device is not connected to a non-cellular network it may wait until the mobile device is connected to a non-cellular network before automatically downloading the predicted IP data.
• The mobile device may also store the downloaded predicted IP data in cache memory on the mobile device that is associated with the application on the mobile device that would have downloaded the predicted IP data if the download had been manually initiated by a user. This ensures that the user experience when accessing the cached IP data is the same in so far as the same user interface(s) and/or native applications are used as when the user is using a real-time IP network connection to consume IP data. Thus, when there is no non-cellular connection available to the mobile device, the user may still consume the cached IP data by bypassing a cellular network connection and accessing the stored predicted IP data from cache memory using an application on the mobile device associated with the stored predicted IP data in response to a request for the IP data.
• In another embodiment, the mobile device may register with a content service provider directly to indicate a desire to receive content (e.g., IP data) from that content provider. The content service provider may then initiate a download to the mobile device in accordance with the request previously made by the user. The content server would push the requested content to the mobile device over the Internet at a time when the mobile device is typically connected to the Internet via WiFi, WiMax, or another non-cellular IP network access point.
• For example, the mobile device may send a content request to a content server over an IP network in which the content request is indicative of recurring IP data of interest to the user of the mobile device. The content server may queue the requested IP content data in a buffer associated with the mobile device and send a notification message to the mobile device indicating that the requested IP content data is queued. The mobile device may determine whether it is connected to a non-cellular network and automatically download the queued IP content data from the content server when it is connected to a non-cellular network. The mobile device may then store the downloaded IP content data in cache memory.
• The mobile device may also collect non-cellular network connectivity information associated with the mobile device and predict, based on the collected non-cellular network connectivity information, when the mobile device can be expected to be connected to a non-cellular network. The mobile device may then attempt to perform the automatic downloading of the queued IP content data at a time when the mobile device can be expected to be connected to a non-cellular network. If the mobile device is not connected to a non-cellular network it may wait until the mobile device is connected to a non-cellular network before automatically downloading the queued IP content data.
• The mobile device may also store the downloaded queued IP content data in cache memory on the mobile device that is associated with the application on the mobile device that would have downloaded the queued IP content data if the download had been manually initiated by a user. This ensures that the user experience when accessing the cached IP data is the same in so far as the same user interface(s) and/or native applications are used as when the user is using a real-time IP network connection to consume IP content data. Thus, when there is no non-cellular connection available to the mobile device, the user may still consume the cached IP content data by bypassing a cellular network connection and accessing the stored queued IP content data from cache memory using an application on the mobile device associated with the stored queued IP content data in response to a request for the IP content data.
• In yet another embodiment, the mobile device may monitor usage and behavior patterns to create items of content (e.g., IP data) to download and locally store on the mobile device. The mobile device may then forward the items of content to be stored on the mobile device to an intelligent cache server resident within the Internet. The intelligent cache server may then pull the IP content data from the content providers and push it to the mobile device over the Internet at a time when the mobile device is typically connected to the Internet via WiFi, WiMax, or another non-cellular IP network access point.
• For example, the mobile device may send a content request to an intelligent cache server over an IP network in which the content request is indicative of recurring IP data of interest to the user of the mobile device. The intelligent cache server may retrieve the requested IP content data from content servers and queue the requested IP content data in a buffer associated with the mobile device and send a notification message to the mobile device indicating that the requested IP content data is queued. The mobile device may determine whether it is connected to a non-cellular network and automatically download or receive the queued IP content data from the intelligent cache server when it is connected to a non-cellular network. The mobile device may then store the downloaded or received IP content data in cache memory.
• The mobile device may also collect non-cellular network connectivity information associated with the mobile device and predict, based on the collected non-cellular network connectivity information, when the mobile device can be expected to be connected to a non-cellular network. The mobile device may then attempt to perform the automatic downloading of the queued IP content data at a time when the mobile device can be expected to be connected to a non-cellular network. If the mobile device is not connected to a non-cellular network it may wait until the mobile device is connected to a non-cellular network before automatically downloading or receiving the queued IP content data.
• The mobile device may also store the downloaded queued IP content data in cache memory on the mobile device that is associated with the application on the mobile device that would have downloaded the queued IP content data if the download had been manually initiated by a user. This ensures that the user experience when accessing the cached IP data is the same in so far as the same user interface(s) and/or native applications are used as when the user is using a real-time IP network connection to consume IP content data. Thus, when there is no non-cellular connection available to the mobile device, the user may still consume the cached IP content data by bypassing a cellular network connection and accessing the stored queued IP content data from cache memory using an application on the mobile device associated with the stored queued IP content data in response to a request for the IP content data.
• In each of the aforementioned embodiments, the content may then be stored by the mobile device in cache memory such that when the user went to access the content, no Internet connection would be required. Moreover, the user may consume desired content without having to utilize a cellular data connection. In addition, the content download (pull or push) may be timed to repeat at specified intervals or whenever a non-cellular IP network connection is available. The content caching scheme may run as a background process to keep the content as fresh and updated as possible.
• Referring now toFIG. 1, an exemplarynetworked environment100 for implementing certain exemplary embodiments is described. Acontent server105 is representative of an entity that creates and/or distributes content over an IP based network such as, for instance, theInternet115. Thecontent server105 may represent a web site or a streaming audio or video service. The content itself may be textual, graphical, audio, video, or some combination thereof. Thenetworked environment100 also illustrates amobile device110, an IP based local area network (LAN)120, acellular network125, and analternative network130.
• In a typical scenario, the mobile device may connect to the Internet using any of theaforementioned networks120,125,130 via an appropriate access point (not shown). The user of the mobile device may prefer to use one network rather than another given the opportunity. For instance, the user may prefer to connect the mobile device to theInternet115 using an 802.11 WiFi connection over an IP network likeLAN120. WiFi connectivity may represent the highest quality and lowest cost means ofInternet115 access. However, WiFi connectivity may not always be available to the mobile device. In such cases, one of the other networks may be used to gainInternet115 access.Internet115 access via acellular network125 is another common means of connectivity. Using thecellular network125 for IP data services, however, can be costly. Cellular service providers typically charge for the use of thecellular network125 based on the amount of IP data that is consumed (e.g., uploaded or downloaded). Moreover, the costs increase the more IP data is consumed. Thus, it is often desirable to minimize the use of thecellular network125 for IP data services.
• There may also be one or morealternative networks130 that may provide access to theInternet115 for amobile device110. One such non-cellularalternative network130 may be characterized as a WiMax network operable over the 802.16 wireless protocol standard. Another suchalternative network130 may be characterized as a whitespace network. A whitespace network may utilize RF spectrum that is shared with television broadcasters. The television broadcasters do not necessarily need to utilize all the spectrum allocated to them to broadcast their video signals. The unused spectrum may be tapped into to provide an alternative RF access point to a network that can interface with theInternet115.
• FIG. 2 is a block diagram illustrating some of the functions of amobile device110 according to one or more embodiments described herein. A mobile device may include, for instance, a smartphone, a personal digital assistant (PDA) device, a tablet style computer, a laptop or notebook style computer, etc. Themobile device110 may include a processor orprocessors205 for controlling the various components and functions of themobile device110. Themobile device110 may also include multiple RF transceivers such as, for instance, aWiFi transceiver210, acellular transceiver215, and analternate transceiver220. Thealternate transceiver220 may also be characterized as a non-cellular transceiver in that it may connect with a network access point to provide access to theInternet115 without the use or assistance of acellular network125.
• TheWiFi transceiver210 may be operable to communicate with an IP network access point using one or more of the 802.11 wireless transmission protocols. Upon connection with an IP network access point, themobile device110 may exchange IP data with servers or other computers that are connected with or communicable with theInternet115. This may includecontent servers105 shown inFIG. 1.
• Thecellular transceiver215 may be operable to communicate with acellular network125 for both voice and IP data communications. On the voice side, thecellular network125 may be based on GSM, CDMA, or other communications protocols while on the IP data side, thecellular network125 may be based on, for example, GPRS, EDGE, EV-DO, HSPA-D, HSPA-U, LTE, UMTS-WCDMA, UMTS-TDD, etc. As pointed out above, use of the cellular network for IP data services can be costly and therefore to be avoided whenever a viable alternative is available to themobile device110.
• In one embodiment, thealternate transceiver220 may be a WiMax transceiver that is operable to communicate with an IP network access point using one or more of the 802.16 wireless transmission protocols. Upon connection with an IP network access point, themobile device110 may exchange IP data with servers or other computers that are connected with or communicable with theInternet115. This may includecontent servers105 shown inFIG. 1. In another embodiment, thealternate transceiver220 may be a whitespace transceiver that is operable to communicate with a whitespace network access point. The whitespace network, in turn, may be communicable with theInternet115 to allow IP data communications between themobile device110 and servers or other computers that are connected with or communicable with theInternet115. This may includecontent servers105 shown inFIG. 1.
• Themobile device110 may further includedata storage225,software applications230, various user interface(s)235 apredictive caching application240. Thedata storage225 may include, for example, one or more types of memory devices including, but not limited to, flash memory usable for ROM, RAM, PROM, EEPROM, and cache. Thesoftware applications230 may include, for example, one or more software applications executable on or by the processor(s)205 including, but not limited to, web browsers, email applications, application specific data and/or audio/video applications, etc. For instance, examples of application specific software video applications could be YouTube™ or Netflix™ while an examples of application specific software audio applications could be Spotify™ or Pandora™. Examples of application specific graphical/text/multimedia software applications may include those for news delivery services like Fox News™, CNN™, The New York Times™, USA Today™, etc. The user interface(s)235 may include, for example, a display, a touchscreen for soft-key input, speaker(s), microphone(s), a keyboard for hard-key input, and one or more buttons.
• Thepredictive caching application240 may be operable to determine content of interest to the user of themobile device110. The content of interest may then be scheduled for download (e.g., pulled) or forwarded to a web based server for management such that the content of interest may be pushed to themobile device110 at appropriate times over a WiFi or WiMax connection and stored in cache memory. Thepredictive caching application240 is described further below.
• Included herein is a set of flow charts representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.
• FIG. 3 illustrates one embodiment of a logic flow300. The logic flow300 may be representative of some or all of the operations executed by one or more embodiments described herein. In this embodiment, steps are disclosed that allow amobile device110 to gather browsing and usage data of themobile device110 along with WiFi connectivity patterns to determine content of interest to a user of themobile device110. At specified times, this content may be downloaded or pulled from content servers using a WiFi or WiMax connection and stored in cache memory for subsequent consumption by the user.
• In the illustrated embodiment shown inFIG. 3, the logic flow300 may observe the browsing history and software application interaction history of themobile device110 with respect to IP data consumption atblock305. For example, the user of themobile device110 may regularly visit one or more web sites which may be reflected by the browsing history or some other means of tracking. The user may browse the USA Today™ sports section on a regular basis as well as the NY Times™ web site. Similarly, the user may access locally storedsoftware applications230 that are used to access the Internet for IP data consumption purposes. Many news outlets have created custom applications that may run on themobile device110 and access the IP data stored on their own content servers. This model does not need a standard we browser but rather uses the native application interface designed by the content provider and executing on the mobile device. Thus, the user may consume IP data from the USA Today™ using a USA Today™ app on the mobile device. This native application has its own user interface and data presentation construct that the user may prefer. Collecting this browsing and application interaction data over a period of time may yield activity that the user of the mobile device regularly engages. The patterns may then yield a predictable model of future IP data consumption.
• The logic flow300 may observe WiFi and/or alternative network connectivity patterns atblock310. For example, themobile device110 may typically have a WiFi connection or an alternative network (e.g., WiMax) connection everyday between the hours of midnight-7:00 AM, 8:00 AM-12:00 PM, 1:00 PM-5:00 PM, and again from 9:00 PM-midnight. This schedule is more or less reflective of a typical workday in which themobile device110 has access to WiFi or WiMax at home from 9:00 PM-7:00 AM, loses access while commuting to a workplace, regains access while at work, and loses access again while commuting home. Similar patterns could be established for students or others. Thepredictive caching application240 can, over time, determine a fairly reliable time frame for expected WiFi or WiMax connectivity.
• In the illustrated embodiment shown inFIG. 3, the logic flow300 may update the browsing history and software application interaction history of themobile device110 with respect to IP data consumption atblock315. For example, the user of themobile device110 may collect and forward additional browsing history or software application interaction history data to thepredictive caching application240. This helps keep thepredictive caching application240 current with respect to the user's most recent usage patterns.
• The logic flow300 may determine IP data content to download based on IP data content usage observations or explicit user instruction atblock320. For example, thepredictive caching application240 may analyze the observed browsing history and application interaction history to determine that the mobile device regularly visits the same web site(s) and typically accesses the same software applications that retrieve IP data content from a content provider over theInternet115. Using this data, thepredictive caching application240 may create a script, background process, or other mechanism that identifies the content provider and the content that the mobile device will most likely want to access throughout the day.
• The logic flow300 may determine whether themobile device110 has a current WiFi connection atblock325. For example, thepredictive caching application240 may query theWiFi transceiver210 to determine whether theWiFi transceiver210 is active and connected to an IP network access point and therefore capable of exchanging IP data over theInternet115. If theWiFi transceiver210 does not currently have a connection with an IP network access point, the logic flow300 may wait until themobile device110 has established a WiFi connection atblock330. For example, thepredictive caching application240 may attempt to invoke the WiFi transceiver and its associated intelligence to scan for and connect with an available WiFi network. Thepredictive caching application240 may continuously or periodically monitor the WiFi connection status of theWiFi transceiver240 and only pull IP content data it has determined to be of interest to the user or that the user has specifically requested when a WiFi connection exists. By running thepredictive caching application240 in the background, it can be ready to download as soon as a WiFi connection is established.
• The logic flow300 may download and cache IP content data over WiFi or an alternative network atblock335. For example, if thepredictive caching application240 determines that themobile device110 does have WiFi connectivity, thepredictive caching application240 can download IP content data it has determined to be of interest to the user or that the user has specifically requested. The downloaded IP content data may then be stored in local cache memory. The downloading and caching step ofblock335 may be optimized using the WiFi connectivity pattern data observed inblock310. Using this information, thepredictive caching application240 may attempt to download IP content data during time frames that themobile device110 is typically connected to a WiFi network. For example, the mobile device may typically be coupled with a WiFi network at 5:00 AM each morning. This may be because the user of themobile device110 is either at home in a WiFi environment or perhaps at a hotel that also includes a WiFi environment. Thepredictive caching application240 may attempt to download desired IP data at 5:00 AM each day so that themobile device110 can cache the IP data for later access by the user even if no WiFi connection exists. In addition, thepredictive caching application240 may run in the background and periodically re-fresh the cached data with new IP content data anytime a WiFi connection exists. Each successful refresh helps keep the cached data as up to date as possible.
• FIG. 4 illustrates one embodiment of a logic flow400. The logic flow400 may be representative of some or all of the operations executed by one or more embodiments described herein. In this embodiment, steps are disclosed that allow amobile device110 to establish a service relationship with a content provider. The service relationship represents IP content desired by the user that is to be pushed or pulled from the content service provider to themobile device110 using a WiFi or WiMax connection. The IP content may then be stored in cache memory for subsequent consumption by the user.
• In the illustrated embodiment shown inFIG. 4, the logic flow400 may send a content request to a content service provider atblock405. For example, thepredictive caching application240 may initiate a communication session with a content service provider over theInternet115. Alternatively, a communication session may be established between the content service provider and themobile device110 using a mobile web browser application. In another embodiment, a communication session may be established between the content service provider and a computer device that is not themobile device110 using a browser application. The other computer device may be a computer, a tablet computer, an IP network enabled television, or other IP network connectable device. In this embodiment, the separate computer device may interact with the content service provider for purposes of registering themobile device110 with the content service provider.
• The registration process may include creating an account that uniquely identifies themobile device110 as the intended recipient of IP content data. The user may specify what IP content it desires during registration. For example, the user may register with a web site such as MLB.com™ and indicate that all top stories, or all stories pertaining to a favorite team be queued for download. The user may further specify that recent scores, standings, and schedules also be queued for download. In another example, the user may register with a web site such as CNN.com™ and indicate that all top stories, all stories mentioning the word “President”, the weather section of the web site, and various stock quotes be queued for download. There may also be a catch-all default that would queue the entire web site for download. In still another example, the user may register with a web site such as Netflix™ and indicate that certain movies or television shows be queued for download. The user may also specify that it would like Netflix™ to choose 2 movies and 3 television shows on its own based on prior viewing history to be queued for download. As is evident, there can be a wide variety of content selection options between the user and the content service provider. The examples above are illustrative and not limiting to the embodiments described herein.
• The logic flow400 may queue the requested content in a buffer associated with themobile device110 atblock410. For example, the content service provider may aggregate the requested content and place it within a buffer uniquely associated with themobile device110 as per the registration process. The logic flow400 may then notify themobile device110 that the requested content has been queued for download atblock415. This may be accomplished, for example, via text message, a pushed alert, email, etc. In an automated system, the notification does not necessarily need to be made known to the user as described above. Rather, thepredictive caching application240 may receive the notification and act on its own to retrieve the desired content. When the notification is received by themobile device110, thepredictive caching application240 may determine if themobile device110 is currently connected to a WiFi network atblock420. If not, thepredictive caching application240 will not attempt to retrieve the content from the content service provider. Rather, thepredictive caching application240 will wait until a WiFi connection exists before downloading the queued content from the content service provider atblock430. If themobile device110 happens to lose the WiFi connection during the download process, thepredictive caching application240 can automatically terminate the download until a WiFi connection for themobile device110 is reestablished. This ensures that acellular network125 is not utilized to download any content and therefore avoids incurring any wireless cellular data usage fees.
• The logic flow400 may store the requested content in cache memory on themobile device110 atblock435. For example, the content downloaded from the content service provider over a WiFi connection may be locally stored indata storage component225 on themobile device110. The user may then access the stored data without needing any type of network connection whatsoever.
• FIG. 5 illustrates an exemplary networked environment for implementing certain exemplary embodiments described herein.FIG. 5 is a duplication ofFIG. 1 with an additional component added. Thus, to the extent thatFIG. 5 duplicatesFIG. 1, the disclosure ofFIG. 1 applies equally toFIG. 5 and is not repeated here.
• The additional component inFIG. 5 may be characterized as anintelligent caching server135. Theintelligent caching server135 resides in the cloud (e.g., accessible via the Internet115). Theintelligent caching server135 may have a relationship with themobile device110 such that data is communicated and exchanged between themobile device110 and theintelligent caching server135. For example, themobile device110 may provide historical browsing data as well as software application interaction data to theintelligent caching server135. Theintelligent caching server135 may then analyze this data to determine or predict the type of IP content data the user ofmobile device110 will likely attempt to access at a later time. Theintelligent caching server135 may then go out and aggregate the IP content data and store it on behalf of themobile device110. Theintelligent caching server135 may then notify themobile device110 of the stored IP content data so that themobile device110 may, at a time when it is connected to a WiFi network, download and locally store the IP content data.
• FIG. 6 illustrates one embodiment of a logic flow600. The logic flow600 may be representative of some or all of the operations executed by one or more embodiments described herein. In this embodiment, steps are disclosed that allow amobile device110 to gather browsing and usage data of themobile device110 along with WiFi connectivity patterns to determine content of interest to a user of themobile device110. This information may then be sent to anintelligent caching server135 that will pull the content from the various content service providers and store it so that themobile device110 may, at specified times using a WiFi or WiMax connection, download it. The incoming content to themobile device110 may then be stored in cache memory for subsequent consumption by the user.
• In the illustrated embodiment shown inFIG. 6, the logic flow600 may observe the browsing history and software application interaction history of themobile device110 with respect to IP data consumption atblock605. For example, the user of themobile device110 may regularly visit one or more web sites which may be reflected by the browsing history or some other means of tracking. The user may browse the USA Today™ sports section on a regular basis as well as the NY Times™ web site. The logic flow600 may then upload the browsing and software application interaction history of themobile device110 with respect to IP data consumption history to anintelligent caching server135 atblock610.
• The logic flow600 may update the browsing history and software application interaction history of themobile device110 with respect to IP data consumption atblock615. For example, the user of themobile device110 may periodically collect and forward additional browsing history or software application interaction history data to thepredictive caching application240. The updated history may then be uploaded to theintelligent caching server135 as described inblock610. This helps keep thepredictive caching application240 current with respect to the user's most recent usage patterns.
• The logic flow600 may determine and obtain IP data content based on IP data content usage observations or explicit user instruction atblock620. For example, theintelligent caching server135 may analyze the uploaded browsing history and application interaction history to determine that the mobile device regularly visits the same web site(s) and typically accesses the same software applications that retrieve IP data content from a content provider over theInternet115. Using this data, theintelligent caching server135 may then connect to the content provider(s) and download the content deemed to be of interest to themobile device110.
• The logic flow600 may queue the content obtained from content providers atblock625. For example, theintelligent caching server135 may store the downloaded content deemed to be of interest to themobile device110 in a local buffer that is associated or linked with themobile device110. Theintelligent caching server135 may then push a notification to themobile device110 informing themobile device110 of the queued content waiting on theintelligent caching server135 atblock630.
• Upon receipt of the content notification from theintelligent caching server135, the logic flow may determine if themobile device110 currently has a WiFi connection atblock635. For example, thepredictive caching application240 may query theWiFi transceiver210 to determine whether theWiFi transceiver210 is active and connected to an IP network access point and therefore capable of exchanging IP data over theInternet115. If theWiFi transceiver210 does not currently have a connection with an IP network access point, the logic flow600 may wait until themobile device110 has established a WiFi connection atblock640. For example, thepredictive caching application240 may attempt to invoke the WiFi transceiver and its associated intelligence to scan for and connect with an available WiFi network. Thepredictive caching application240 may continuously or periodically monitor the WiFi connection status of theWiFi transceiver240 and notify theintelligent caching server135 of WiFi connectivity when it exists atblock645. By running thepredictive caching application240 in the background, it can be ready to notify theintelligent caching server135 as soon as a WiFi connection is established.
• The logic flow600 may push IP content data over WiFi or an alternative network to themobile device110 atblock650. For example, when the preintelligent caching server135 receives notification that themobile device110 does have WiFi connectivity, theintelligent caching server135 can push IP content data it has determined to be of interest to the user or that the user has specifically requested to the mobile device. The downloading and caching step ofblock335 may be optimized using observed WiFi connectivity pattern data. Using this information, theintelligent caching server135 may attempt to push IP content data during time frames that themobile device110 is typically connected to a WiFi network. For example, the mobile device may typically be coupled with a WiFi network at 5:00 AM each morning. This may be because the user of themobile device110 is either at home in a WiFi environment or perhaps at a hotel that also includes a WiFi environment. Theintelligent caching server135 may attempt to push desired IP data at 5:00 AM each day so that themobile device110 can cache the IP data for later access by the user even if no WiFi connection exists.
• Alternatively, the logic flow600 may download and cache IP content data over WiFi or an alternative network. For example, if thepredictive caching application240 determines that themobile device110 does have WiFi connectivity, thepredictive caching application240 can download IP content data it has determined to be of interest to the user or that the user has specifically requested from theintelligent caching server135. The downloading and caching step may be optimized using the WiFi connectivity pattern data observed inblock310. Using this information, thepredictive caching application240 may attempt to download IP content data during time frames that themobile device110 is typically connected to a WiFi network. In addition, thepredictive caching application240 may run in the background and periodically re-fresh the cached data with new IP content data anytime a WiFi connection exists and new content data is available on the intelligent caching server. Each successful refresh helps keep the cached data as up to date as possible.
• The logic flow600 may store pushed or pulled IP content data in cache memory of themobile device110 atblock655. For example, thepredictive caching application240 may analyze the received pushed IP content data and store it appropriately in local mobile device cache memory. For instance, IP content data associated with a web site may be stored in web browser cache memory. If the IP content data is associated with aparticular software application230 rather than a generic web browser, thepredictive caching application240 may store the data in a cache buffer associated with thatsoftware application230. This storage mechanism allows the user to access the IP content data using the same user interface(s) and/or native application (e.g, web browser, Weather Channel™ app, ESPN™ app, CNN™ app, etc.) as always. The end result is a data consumption experience for the user that is no different than if the user had just requested and downloaded the IP content data.
• FIG. 7 illustrates one embodiment of a logic flow700. The logic flow700 may be representative of some or all of the operations executed by one or more embodiments described herein. In this embodiment, steps are disclosed that allow amobile device110 to consume, on themobile device110, cached IP content data.
• In the illustrated embodiment shown inFIG. 7, the logic flow700 may receive a request to fetch IP data atblock705. For example, the user of themobile device110 may be executing a web browser and request access to a particular URL. In another example, the user may be running aparticular software application230 on themobile device110. Thesoftware application230 may receive input from the user that causes it to fetch IP data from a content provider outside themobile device110. The content provider may be accessible via theInternet115.
• The logic flow700 may then determine if themobile device110 has a Wifi or alternate network connection atblock710. Alternate network connection excludes a cellular network connection since an object is to minimize access to and use of a cellular network for non-voice (e.g., IP data) purposes. When themobile device110 does have a WiFi or alternate network connection as determined atblock710, thepredictive caching application240 may run in the background to receive and/or refresh cached IP data atblock715.Block715 may be implemented using one or more of the embodiments described inFIG. 3,4, or6. In addition, when themobile device110 does have a WiFi or alternate network connection, themobile device110 may execute any requests or instructions to fetch IP data via a connection with the Internet over WiFi or an alternate network. The downloaded IP data may then be presented to the user from within the native application used to make the request over one or more of the user interface(s)235 of themobile device110 atblock730.
• When themobile device110 does not have a WiFi or alternate network connection as determined atblock710, the logic flow700 determines if the request for IP data is for data already stored in local cache memory atblock735. If the IP data is not already stored in local cache memory, the mobile device may use thecellular data network125 to download the requested IP data. Use of thecellular data network125 may be automatic or allowed only upon an affirmative user response to a prompt. If the IP data is already stored in local cache memory, the mobile device may prompt the user to use the cached data atblock740. If the user responds negatively, the request may be processed live using a connection to thecellular network125. Otherwise, thecellular network125 may be bypassed atblock745 and the IP data may be accessed via the cache memory atblock750. The IP data may then be presented to the user from within the native application used to make the request over one or more of the user interface(s)235 of themobile device110 atblock730.
• It should be noted that the use of WiFi with respect to the description ofFIGS. 3-7 may be substituted with an alternative non-cellular IP network protocol or standard such as, but not limited to, WiMax or a whitespace network. In addition, a wired IP network connection such as Ethernet, if available to themobile device110, may be considered analternative network130.

Claims (15)

1. A mobile device comprising:

a cellular transceiver;

at least one other RF transceiver communicable with at least one non-cellular IP network access point;

a data storage component; and

at least one processor operable with one or more software applications configured to:

receive an Internet Protocol (IP) data request for IP data;

automatically bypass any cellular network connection and download the IP data to the mobile device using the at least one other RF transceiver over the at least one non-cellular IP network access point such that the stored IP data is not transported over a cellular network;

store the downloaded IP data in the data storage component; and

in response to a subsequent request for the IP data and when no non-cellular IP network access point connection is available to the mobile device:

bypass an available cellular network connection; and

access the stored IP data from cache memory using an application on the mobile device associated with the stored IP data.

2. The mobile device ofclaim 1, the at least one processor operable with one or more software applications further configured to:

collect non-cellular IP network connectivity information associated with the mobile device;

predict, based on the collected non-cellular IP network connectivity information, when the mobile device can be expected to be connected to the at least one non-cellular IP network access point; and

attempt to perform the automatically downloading the IP data step at a time when the mobile device is predicted to be connected to the at least one non-cellular IP network access point.

3. The mobile device ofclaim 1, the at least one processor operable with one or more software applications further configured to:

wait until the mobile device is connected to the at least one non-cellular IP network access point before automatically downloading the IP data.

4. The mobile device ofclaim 1, the at least one processor operable with one or more software applications further configured to:

store the downloaded IP data in cache memory on the mobile device wherein the cache memory is associated with an application on the mobile device that would have downloaded the IP data if the download had been manually initiated by a user.

5. The mobile device ofclaim 1, wherein the at least one non-cellular IP network access point is one of a WiFi IP network access point, a WiMax IP network access point, and a whitespace IP network access point.

6. At least one non-transitory machine-readable medium comprising a set of instructions that in response to being executed on a mobile computing device cause the mobile computing device to:

receive an Internet Protocol (IP) data request for IP data;

automatically bypass any cellular network connection and download the IP data to the mobile device using the at least one other RF transceiver over the at least one non-cellular IP network access point such that the stored IP data is not transported over a cellular network;

store the downloaded IP data in the data storage component; and

in response to a subsequent request for the IP data and when no non-cellular IP network access point connection is available to the mobile device:

bypass an available cellular network connection; and

access the stored IP data from cache memory using an application on the mobile device associated with the stored IP data.

7. The at least one non-transitory machine-readable medium ofclaim 6, comprising instructions that in response to being executed on the mobile computing device cause the computing device to:

collect non-cellular IP network connectivity information associated with the mobile device;

predict, based on the collected non-cellular IP network connectivity information, when the mobile device can be expected to be connected to the at least one non-cellular IP network access point; and

attempt to perform the automatically downloading the IP data step at a time when the mobile device is predicted to be connected to the at least one non-cellular IP network access point.

8. The at least one non-transitory machine-readable medium ofclaim 6, comprising instructions that in response to being executed on the mobile computing device cause the computing device to:

wait until the mobile device is connected to the at least one non-cellular IP network access point before automatically downloading the IP data.

9. The at least one non-transitory machine-readable medium ofclaim 6, comprising instructions that in response to being executed on the mobile computing device cause the computing device to:

store the downloaded IP data in cache memory on the mobile device wherein the cache memory is associated with an application on the mobile device that would have downloaded the IP data if the download had been manually initiated by a user.

10. The at least one non-transitory machine-readable medium ofclaim 6, wherein the at least one non-cellular IP network access point is one of a WiFi IP network access point, a WiMax IP network access point, and a whitespace IP network access point.

11. A method comprising:

in a mobile device having both a cellular transceiver and at least one other RF transceiver communicable with at least one non-cellular IP network access point:

receiving an Internet Protocol (IP) data request for IP data;

automatically bypassing any cellular network connection and downloading the IP data to the mobile device using the at least one other RF transceiver over the at least one non-cellular IP network access point such that the stored IP data is not transported over a cellular network;

storing the downloaded IP data in the data storage component; and

in response to a subsequent request for the IP data and when no non-cellular IP network access point connection is available to the mobile device:

bypassing an available cellular network connection; and

accessing the stored IP data from cache memory using an application on the mobile device associated with the stored IP data.

12. The method ofclaim 11 further comprising:

collecting non-cellular IP network connectivity information associated with the mobile device;

predicting, based on the collected non-cellular IP network connectivity information, when the mobile device can be expected to be connected to the at least one non-cellular IP network access point; and

attempting to perform the automatically downloading the IP data step at a time when the mobile device is predicted to be connected to the at least one non-cellular IP network access point.

13. The method ofclaim 11 further comprising waiting until the mobile device is connected to the at least one non-cellular IP network access point before automatically downloading the IP data.

14. The method ofclaim 11 further comprising storing the downloaded IP data in cache memory on the mobile device wherein the cache memory is associated with an application on the mobile device that would have downloaded the IP data if the download had been manually initiated by a user.

15. The method ofclaim 11 wherein the at least one non-cellular IP network access point is one of a WiFi IP network access point, a WiMax IP network access point, and a whitespace IP network access point.

Images