System and method for precaching information on a mobile device

Abstract

A system and method for precaching information on a mobile device. A precaching strategy is built for a mobile device The strategy defines a forecast of data types a user is predicted to request after the occurrence of one or more data refresh conditions. The precaching strategy is built by recognizing data usage patterns in data requested by the user or a group of users over a time period. The data usage pattern comprises data types and events that are correlated to the usage of the data. The events are used to define at least one refresh condition within the precaching strategy. The precaching strategy is executed. When the occurrence of the data refresh condition is detected, data is then retrieved from a data source, wherein the data is retrieved according to the precaching strategy. The retrieved data is transmitted to a user device cache.

Description

This application includes material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The present invention relates to systems and methods for information search, retrieval and presentation and, more particularly, to systems and methods for precaching information on user devices.

BACKGROUND OF THE INVENTION

Users of mobile devices can access a rich array of content over the Internet including spatial, temporal, social and topical data relating to an almost unlimited number of entities and objects. Accessing such data can, however, consume a significant amount of computing and network resources. Device and network performance can be enhanced by precaching information a user is likely to request on the user's device or elsewhere on the network.

SUMMARY OF THE INVENTION

In one embodiment, the invention is a method. A precaching strategy is built, using at least one computing device, for a mobile device, wherein the precaching strategy defines a forecast of at least one data type a user is predicted to request after the occurrence of at least one data refresh condition. The precaching strategy is built by recognizing, using the at least one computing device, at least one data usage pattern in data requested by the user using the user device over a time period. The data usage pattern comprises the data type and at least one event that is correlated to the usage of the data. The event is used to define at least one refresh condition within the precaching strategy. The precaching strategy is executed using the computing device. The occurrence of the data refresh condition is detected. Data is then retrieved, over a network, from the data source, wherein the retrieved data is retrieved according to the precaching strategy. The retrieved data is transmitted, over the network, to a user device cache accessible to at least one application program running on the user device.

In another embodiment, the invention is a method. A precaching strategy is built, using at least one computing device, for a mobile device, wherein the precaching strategy defines a forecast of at least one data type a user is predicted to request after the occurrence of at least one data refresh condition. The precaching strategy is built by recognizing, using the computing device, at least one data usage pattern in data requested by a plurality of users over a time period, wherein the data usage pattern comprises the data types. The precaching strategy is executed using the computing device. The occurrence of the data refresh condition is detected. Data is then retrieved, over a network, from the data source, wherein the retrieved data is retrieved according to the precaching strategy. The retrieved data is transmitted, over the network, to a user device cache accessible to at least one application program running on the user device.

In another embodiment, the invention is a system. The system comprises a set of modules, wherein each of the modules comprise one or more processors programmed to execute software code retrieved from a computer readable storage medium storing software for various functions. The modules include: a precaching strategy creation module for building precaching strategies for mobile devices, wherein the precaching strategy defines a forecast of at least one data type a user is predicted to request after the occurrence of at least one data refresh condition, wherein the precaching strategy is built by recognizing at least one data usage pattern in data requested by a plurality of users over a time period, wherein the data usage pattern comprises the data types; a precaching strategy execution module for executing precaching strategies built by the precaching strategy creation module; a refresh condition detection module for detecting that data refresh conditions have occurred relating to precaching strategies executed by the precaching strategy execution module; a data retrieval module for retrieving data, over a network, from at least one data source, wherein the retrieved data is retrieved according to precaching strategies for data where the refresh condition detection module has detected that data refresh conditions have occurred; and a data transmission module for transmitting data retrieved by the data retrieval module the retrieved data, over the network, to user device caches accessible to application programs running on the user devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features, and advantages of the invention will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings, in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating principles of the invention.

FIG. 1 illustrates one embodiment of how precaching could be utilized on for mobile devices to improve device performance.

FIG. 2 illustrates one embodiment of a hardware and network configuration that is capable of supporting various embodiment of the current invention.

FIG. 3 illustrates one embodiment of a computer implementation of a process implementing at least one embodiment of the current invention.

FIG. 4 illustrates one embodiment of a precaching services engine capable of supporting of at least one embodiment of the process shown in FIG. 3.

DETAILED DESCRIPTION

The present invention is described below with reference to block diagrams and operational illustrations of methods and devices to select and present media related to a specific topic. It is understood that each block of the block diagrams or operational illustrations, and combinations of blocks in the block diagrams or operational illustrations, can be implemented by means of analog or digital hardware and computer program instructions.

These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, ASIC, or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implements the functions/acts specified in the block diagrams or operational block or blocks.

In some alternate implementations, the functions/acts noted in the blocks can occur out of the order noted in the operational illustrations. For example, two blocks shown in succession can in fact be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality/acts involved.

For the purposes of this disclosure, a computer readable medium stores computer data in machine readable form. By way of example, and not limitation, a computer readable medium can comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other mass storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer.

For the purposes of this disclosure a module is a software, hardware, or firmware (or combinations thereof) system, process or functionality, or component thereof, that performs or facilitates the processes, features, and/or functions described herein (with or without human interaction or augmentation). A module can include sub-modules. Software components of a module may be stored on a computer readable medium. Modules may be integral to one or more servers, or be loaded and executed by one or more servers. One or more modules may grouped into an engine or an application.

For the purposes of this disclosure the term “server” should be understood to refer to a service point which provides processing, database, and communication facilities. By way of example, and not limitation, the term “server” can refer to a single, physical processor with associated communications and/or data storage and/or database facilities, or it can refer to a networked or clustered complex of processors and associated network and/or storage devices, as well as operating software and one or more database systems and/or applications software systems (which can be implemented as modules and/or engines) which support the services provided by the server.

For the purposes of this disclosure the term “end user” or “user” should be understood to refer to a consumer of data supplied by a data provider. By way of example, and not limitation, the term “end user” can refer to a person who receives data provided by the data provider over the Internet in a browser session, or can refer to an automated software application which receives the data and stores or processes the data.

In one embodiment, the present invention is directed to a improvements in precaching information a user of a mobile device is likely to request on the user's mobile device or elsewhere on a network accessible to the mobile device.

Mobile device's such as Blackberry and iPhone devices provide rich graphical interfaces that are capable of displaying a broad variety of information retrieved from the Internet and/or other networks accessible to the device. Such information can be broadly categorized as temporal, spatial, topical and social information. Spatial information includes information relating to the physical location of persons or objects. Spatial information can include the past, present and future location of the user of the mobile device or the location of other persons, such as the user's friends. Spatial information could also be specific place, such as a country, a state, a city, a neighborhood. Spatial information could be the location of an event, such as a concert or some other newsworthy occurrence.

Temporal information includes dates and times of interest to the user. Temporal information could include the current date and time. Temporal information could also be a specific date and time in the past or the future, or a range of dates and times in the past or the future. Temporal information could be an offset from a specific date, for example, ten days in the past. Temporal information could be an event on a calendar, such as a birthday, a season or a holiday.

Topical information includes any type of information on topics of interest to the user. Topical information could include the current weather or weather forecast, current headlines, or current scores for a favorite sports team. Topics could be broad, such as “rock music” or narrow such as a specific musical artist. Topics could relate to specific types of media, for example, new songs released by a musical artist, or text news articles about the same musical artist.

Social information includes any type of information relating to persons or groups of persons of interest to the user. Such information could include information relating to friends or contacts the user has identified on one or more social networks. Such information could include contact information for the user's friends. Such information could also include friends current location, activities or latest posts to friend's MySpace or Twitter accounts.

Much of the information displayed on a user's mobile device is typically retrieved from various data sources available over the Internet, such as websites and various types of data feeds such as RSS feeds. A small amount of relatively static information can be permanently stored on the mobile device, such as profile information, but any potentially volatile information must be at least periodically retrieved from one or more data sources over the network. In one embodiment, such information is cached on a computer readable medium within or physically connected to the user's mobile device such as, for example, random access memory within the mobile device.

Data in cache is readily accessible for display, whereas, if data is retrieved over the network only when requested by the user, network delays or processing limitations at data sources can cause response time to be impaired. In one embodiment, the performance of a mobile device can be improved by precaching information the user is likely to request, either on the user's mobile device, or elsewhere on a network to which the mobile device is connected.

FIG. 1 illustrates one embodiment of how precaching could be utilized on for mobile devices to improve device performance.

User's mobile devices 100 host one or more mobile applications 140 that utilize data from one or more data source services 240, such as weather, news or social networking websites or data feeds. Such applications 140 could include a conventional web browser, or could include custom applications. The mobile application typically looks for data that is displayed by the application in one or more caches 120 on the device. Such a cache could be stored on, for example, a computer readable media such as random access memory that is a component of the mobile device 100.

If the data needed by the mobile application 120 is not stored in the device's cache 140, the mobile application will request the needed data, over a network, from the appropriate network data source 240 implemented one or more network data source servers 200 which retrieve the requested information from one or more data sources such as, for example, databases 280 or sensors 260. The data retrieval service 240 will, in turn, transmit the data back to the requesting mobile device 200 which will typically store the information in its cache 120 before displaying the data to the user.

Performance of the mobile applications 140 could be improved if the user's data needs could be anticipated before the user requests display of the data. If the user's data needs could be anticipated, data sufficient to satisfy the user's needs could be retrieved from the appropriate source 200 and transmitted and stored in the mobile device's cache 120. For any given network data source 200, the user's data needs could be anticipated by the mobile application, and the mobile application could request the needed data before the user actually requests display of the data. For any given network data source 200, the user's data needs could be anticipated by the network data source and the network data source could transmit the needed data to the users mobile device 100 before the user actually requests display of the data.

A third alternative, a data precaching service 440 could be set up on one or more data precaching servers 400. The data precaching service 440 could anticipate the user's data needs and request data from the appropriate data source 200. In one embodiment, the data caching service 440 can direct the data source 200 to transmit the requested data directly to the mobile device 100, which then stores the data in its cache for future use. Alternatively, the requested data could be transmitted to the data caching service server 400.

In one such embodiment, the data caching service 440 could then simply forward the data to the user's mobile device 100. Alternatively, the data precaching service 440 could store the requested data in a server cache 420 implemented on computer readable media accessible to the data precaching server 400, such as, for example, the server's RAM. In one such embodiment, the mobile device 100 could request all data required by the mobile applications 140 from the data precaching service 440, which in turn retrieves the data from the server cache 420, if the data is present there, or directly from the appropriate data source 200 if not. The data caching service 440 could also transmit the requested data to the mobile device 100 periodically, or based on a trigger, such as the occurrence of an event or the lapse of a period of time.

One benefit of caching data at the level of the data caching server 400 is that it may be possible to cache one copy of a particular type of data for multiple users. For example, many users may be interested in the tomorrow's weather forecast for a specific zip code. Thus one copy of such weather data could be maintained on the caching server 400 for user by hundreds of users. At a higher level of abstraction, users, based on their pattern of data usage or on the basis of the their self defined data needs, could be assigned to one or more user types. Such a user type could be associated with one or more sets of data which the data caching service 440 maintains in server cache 420.

The central element in any of the embodiments discussed above is anticipating a user's future data needs. If a user's future data needs can be determined, or at least forecast with a reasonable degree of accuracy, a data caching strategy could be constructed for a mobile device user. In one embodiment, a data precaching strategy could be schematically represented as follows.

<user> or <user type>
<device ID> or <device type>
<data type >
<data source>
<request parameters>
<refresh condition 1>
<refresh condition 2>
. . .
<data type >
. . .
<data type >
. . .

A data precaching strategy could be set up for a specific user. If a user has multiple devices, a precaching strategy could be set up for each of the user's devices, since the user may use different devices for distinctly different purposes. A data caching strategy could also be set up for a type of user. Such user types could reflect typical usage patterns for general types of users, e.g. “NY Commuter”, or even more abstractly “User Type n” for an empirically recognized usage pattern (e.g. user is a frequent user of data types A, B and C).

A data precaching strategy can contain one or more data types. As used herein, “data type” should be understood to refer to an abstract user defined data type that could refer to spatial, temporal, social or topical data. Examples of spatial data types could include the user's current location, the user's friends locations, the location of the user's favorite sports team. Examples of temporal data types could include the current time, the next event on the user's calendar, or the time of the next classical music concert in town. Examples of social data could be a list of the user's friends, posts by the user's friends on social networking sites, a list of the last concert the user's friends attended and so forth. Examples of topical data could include general news, news on specific topics, weather forecasts, current traffic, sports scores and so forth.

For a given data type, there could be one or more data sources, which could include websites, RSS feeds, FTP sites or any other type of data source. The data strategy could include request parameters required for requesting the desired information from the data source (e.g. URL parameters).

Each data type could provide for one or more refresh conditions. Refresh conditions represent conditions under which precached data is refreshed from the data source. In one embodiment, refresh conditions can reflect temporal, spatial, social or topical events or conditions. Spatial events could include any events where there is a change in spatial data associated with the user or an entity of interest to the user. For example, a spatial event a change in the user's physical location of a particular magnitude (e.g. 1 mile, or entering another city), or the user coming within a defined proximity of a location (e.g. a specific coffee shop, or the user's work location) or within a defined proximity of a person (e.g. a friend).

Temporal events could include any events associated with the passage of time. For example, temporal events could include, for example, the lapse of a specific time interval (e.g. five minutes or a recurring, absolute time, such as 12:00 PM every day), or a specific calendared event (e.g. a birthday, or dates and times that a favorite sports team is playing). Social events could include could include any events associated with the user's social network. For example, social events could include emails sent by friends or new posts, including text or images, by friends on social networking sites. Topical events could include any events associated with a topic such news flashes, updated sports scores, weather alerts, or new songs available from a favorite musical artist.

Refresh conditions could reflect compound conditions including multiple events or conditions of different types. For example, sports scores might be refreshed every one minute, but only during the times a favorite sports tem is scheduled to play. Traffic conditions may only be refreshed during rush hours or if there is a reported accident. Data relating to friends, such as recent posts, messages and/or images may only be refreshed off business hours

Note that the data caching strategy as discussed above is exemplary, and is not intended to be limiting. The strategy could include other elements not discussed above, and/or could be represented in different formats. All such embodiments are intended to be within the scope of this disclosure.

Data caching strategies similar to those discussed above could be implemented by a data precaching service running on a data precaching server. The precaching strategies could be stored on a computer-readable medium accessible to the data precaching server. The strategies could be stored in any suitable format such as human readable formats such as XML, or could be stored in a proprietary binary format.

There are a number of methods for defining data precaching strategies, which could, in some embodiments, be used alone or in combination with one another. In one embodiment, a user could explicitly define the types of data to precache on the user's device. For example, a user, using a mobile application, could explicitly specify they wish to have football scores derived from a sports website updated every one minute on Sundays during football season. Users could specify they wish to have traffic conditions updated every five minutes during rush hour.

In one embodiment, a user could implicitly define the types of data to precache on the user's device. For example, if a user customizes their homepage for their mobile device, they may select a variety of spatial, temporal, topical or social data to display on the page. The act of selecting a specific type of data for display on the page could automatically add one or more associated data types to the precaching strategy. Refresh conditions could initially be based on global default refresh conditions, such as, for example, a rule to refresh the data every five minutes. Default refresh conditions could also be established for different data types, for example, weather forecasts may be refreshed hourly, whereas news headlines may be refreshed every five minutes.

On the opposite end of the spectrum, data caching strategies could be defined entirely on usage. For example, data retrieved by mobile applications on a user's device could be analyzed over a period of time, for example, a day, a week or a month. Data types and their corresponding sources could be identified. More complex analysis could be conducted, and various patterns of data usage could be identified. Patterns could reflect spatial, temporal, social or topical correlations. For example, spatial patterns could indicate a user retrieves traffic information when located on a specific highway. Temporal patterns could indicate that a user retrieves football scores between 12:00 PM and 8:00 PM on Sundays. Social patterns could indicate that user retrieves data from relating to specific individuals. Topical patterns may indicate a user retrieves headline news or sports scores. In one embodiment, such patterns could involve multiple variables and complex patterns.

In particular, data relating to data usage patterns could be obtained from a user's social networks. In one embodiment, the user's global social graph can be determined by analyzing every known social network in which the user participates. Instead of, or in addition to, analyzing a user's usage data, all or a portion of usage data relating to a user's global social graph could be analyzed as well. In one embodiment, usage data relating to all persons on a user's social graph could be analyzed for usage patterns, or a fraction of the user's social graph, for example persons the user defined as friends could be analyzed. The most important persons within a user's social network could be analyzed. The most important persons could be identified by, for example, the frequency of contacts between the user and the person.

User defined and empirical data based generation of user data caching strategies could be utilized. For example, a data caching strategy could be implicitly defined when a user sets up a home page for mobile device, and the strategy could be dynamically altered based on data usage patterns. In one embodiment, data usage patterns in a user's data usage are identified. For example, data usage patterns may indicate a user checks headline news every 10 minutes every day between 8:00 AM and 9:00 AM. Thus, if a user places news headlines on his or her homepage, a default caching strategy could be to refresh the cache for headline news every hour, usage patterns could indicate the cache should be refreshed more frequently between 8:00 and 9:00 AM.

If a cache refresh rate is based on usage, the refresh rate can be optimized such that statistically it is likely that the data the user is likely to be interested in will be in cache some fixed percentage of the time. For example, the cache can be refreshed such that it is 90% likely that when a use requests information, the information will be available in cache.

There are other, additional, methodologies that could be used to determine data precaching strategies. One methodology that could be used is to define usage patterns for data types. In one embodiment, data types could be defined in a hierarchy of types and an unlimited hierarchy of sub-types. Such a hierarchy could be conceptually represented as:

<data type>
<sub-type>
<sub-sub-type>
. . .
<sub-type>
. . .
<data type>
. . .

One example could be, for example:

<sports>
<team scores>
<yankees-scores>
. . .
<red sox scores>
. . .

At each level of the data hierarchy, there could be specific usage patterns. Users interested in sports data may, in general, exhibit specific data usage patterns, such as checking sports news daily every hour. Yankees fans may check scores every 10 minutes on dates and time that Yankees games are taking place. Usage patterns could be used to developed caching strategies for each type, sub-type and so forth. Alternatively or additionally, an administrator or other user could set up data types and set up caching strategies. Caching strategies could be dynamically determined for each type and sub type based on usage patterns on a periodic basis, for example, weekly or monthly.

In one embodiment, usage patterns for a specific data type could be determined for a specific user (as discussed above), a specific social circle defined by a group of users who include one another in their social circle or could be all users or a subset of known users having one or more specific properties (e.g. Yankees fans). Usage patterns could be determined by analyzing actual usage patterns for a defined set of users over a defined period, such as a day, a month or a year. Such usage patterns could be used to develop data precaching strategies.

Data type hierarchies could be defined by an administrator, and default caching strategies could be, initially, defined manually. Such caching strategies could be dynamically altered using data usage patterns from all users or some subset of all users. Alternatively or additionally, data usage patterns for data types could be empirically identified by analyzing data usage patterns from all users or some subset of all users. Identified data types could be manually organized or placed in an existing data hierarchy. Alternatively or additionally, data hierarchies could be empirically identified by matching similar patterns of data usage.

If precaching strategies are determined for specific data types, such precaching strategies can be used to determine precaching strategies using other methodologies discussed herein. For example, if a user explicitly or implicitly adds a data type to his or her precaching strategy, rather than using the user's actual data usage patterns over some arbitrary period of time, data precaching strategies that have already been developed for data types the user is interested in could be used in the user's precaching strategy. For example, in the case of a user interested in Yankees scores, a precaching strategy for Yankees scores could be developed based on data from all users interested in Yankees scores. Such a strategy could be, in turn, incorporated into the profile of an individual user interested in Yankees scores.

User types could be defined that include precaching strategies for user types. User types can be broadly defined as a group of users that have a specific pattern of data usage. One definition of a user type could be a group of users that use data relating to a specific pattern of data types. Such patterns could be empirically identified, such as, for example, observing that there is a specific correlation between interest in one data type and another data type. Such patterns could be identified by an administrator, for example, an administrator could define a user type such as a football fan, where such a user is interested in data types including football news items and football scores.

User types could simply incorporate data types and inherit usage patterns and caching strategies from incorporated data types. Alternatively, data usage patterns could be analyzed for users identified as belonging to specific user types, and data usage patterns could be determined for the user type as a whole or for data types within the user type. Alternatively, data usage patterns and data precaching strategies could be initially taken from predefined user types and data types and refined by the user's actual usage patterns or the actual usage patterns of a defined group of users such as all users, the users social circle or the user alone.

A user could be assigned to a user type explicitly, implicitly or empirically. A user may self define himself or herself as, for example, a Packer's fan. Alternative, a user could identify himself or herself as a football fan by selecting football news and football scores for inclusion on his or her home page. A user could be empirically assigned to a user type by identifying a pattern of data types and usage frequencies and correlating such patterns to an explicitly or empirically defined user type. In one embodiment, data usage patterns relating to users who are explicitly defined to be of a particular type can be used to train classifiers, such as SVMs to assign new users to particular user types.

In one embodiment, a user can be assigned to more than one user type. Thus, for example, a user may be a “NY Commuter” and a “Yankee Fan”. Each type exhibits specific types and data usage patterns. In one embodiment, where user types comprise different data types, user types could be seamlessly combined. Where data types overlap, data usage patterns and precaching strategies could be selected from one user type or be averaged (if they differ).

In one embodiment precaching strategies could be restricted to a specific set of content a user typically accesses. For example, precaching strategies could be limited to elements present on the user homepage for a mobile device. Precaching strategies could be used to personally to model information needs, habits and designate predictive models for the type, frequency and timing of users actual content load and display requests. Such strategies could be used to create an individuated caching profile and thus cache for that user according to that model. Such individuated profiles could be maintained for individual users or types of users.

Thus, precaching can be optimized in at least two ways. First by collaborative filtering of patterns across all known users with the same or similar content and/or habits to establish a set of standard types or classes” of users, or second, individually based exclusively on the actual behaviors of that user or device.

For example, assume a user's calendar has a daily alarm clock at 6 AM regularly on a Monday through Friday basis. A user's profile could include delivery of a refreshed homepage the user's device at 5:59 AM. Individual patterns for every user requires could require significant space and processing, so it is a user's profile could include a one or more types that are close enough to each of user's actual usage data sets. Thus, in one embodiment, a limited number of caching models could be utilized for easier implementation and then match each user could be matched to the to closest possible match.

Thus, each user helps to establish the norms for the configuration choices of types of users. Depending on the content, there can be are different types of users on entities web site with varying concerns. A soft expiration of cached data based upon the aggregate patterns of the users and the actual needs and context of a specific user can be established. Individual caching can provide better user experience and can change over time to grow and improve as more actual usage data is accumulated.

FIG. 2 illustrates one embodiment of a hardware and network configuration that is capable of supporting various embodiment of the current invention.

One or more users 1100 and 1200 periodically access information using their mobile devices 1120 and 1220 over a network 1900 such as, for example, the Internet. Such information originates with one or more network data providers, such as servers hosting websites 1400, data feeds 1600 or other services that provide information in any conventional format known in the art.

The mobile device users could obtain information, at least in part, via a data precaching service residing on a precaching service server 1800. The data precaching service could predict users likely data needs in any manner, such as the techniques described above. The service could maintain data precaching strategies on a computer readable medium 1820 and transmit data to users mobile devices 1120 and 1220 in anticipation of the users data needs. The service could analyze, among other things, the users 1100 and 1200 data usage patterns and use such patterns to determine precaching strategies. As described above, precaching strategies could be determined using data from all users or a subset of all users

FIG. 3 illustrates one embodiment of a computer implementation of a process 3000 implementing at least one embodiment of the current invention.

A precaching strategy is built 2100, using at least one computing device, for a mobile device, wherein the precaching strategy defines a forecast of at least one data type a user is predicted to request after the occurrence of at least one data refresh condition. In one embodiment, data refresh conditions comprise one or more events, wherein when the events occur, the refresh condition is satisfied. Data types can comprise any kind of spatial, temporal, social or topical data, such as, for example, current location, a calendar event, a friend's latest Facebook posting, news relating to a topic or scores for a favorite sports team. The events within a refresh condition can be any type of spatial, temporal, social or topical event, such as, for example, the user enters a new city, a fixed time interval elapses, a friend makes a new Facebook post or a new news item relating to a topic appears on a newswire. In one embodiment, the precaching strategy is stored on a computer readable medium 2120.

In one embodiment, the precaching strategy is built by recognizing, using the computing device, at least one data usage pattern in data requested by the user using the user device over a time period The data usage pattern can comprises a data type, and can additionally include at least one event that is correlated to the usage of the data. The correlated event can be used is used to define at least one refresh condition within the precaching strategy for that data type.

Such usage data could be obtained from any available source, such as, for example, query logs, data server logs or logs residing on the user device. Usage data could be prospective tracked by a data precaching service for the express purpose of building a precaching strategy.

In addition to analyzing usage data for individual users or user devices, data usage patterns could be recognized in usage data for a group of users. Such groups could include all users, or a selected subset of users. In one embodiment, a group could comprise one or more users selected from a user's social graph.

Data types within a precaching strategy could be determined purely empirically by recognizing data usage patterns within data usage data. Alternatively, or additionally, data types could be predefined. In one embodiment, a hierarchy of data types could be defined manually by an administrator or through the analysis of data usage by one or more users, such as, for example, sports news->scores->baseball scores->Yankees scores. Precaching strategies could then be built for such predefined data types. In one embodiment, precaching strategies for individual data types could built by analyzing large amounts of data for a large number of users. Spatial, temporal, social and topical patterns of data usage and correlated events could be recognized and used to build strategies at every level of a data hierarchy.

Predefined data types could then be used to build precaching strategies for individual users. In one embodiment, if a given data type is recognized in a user's data usage pattern, the predefine caching strategy for that data type could be used in place of using the user's actual usage patterns. Precaching strategies for data types could be selected for a specific data type identified in a user's data usage patterns (e.g. Yankee's scores) or for a more generic data type that encompasses the identified data type (e.g. baseball scores).

Precaching strategies could be built for user types. A specific group of users could be identified using one or more user properties. Such properties could include, without limitation, demographics (e.g. student, 18-22 years old) or a self identified category (e.g. Yankee's fan). In one embodiment, data usage patterns are recognized in data usage data for all or a subset of all users in the identified group. Such patterns could be used to empirically develop data precaching strategies, or could be used to select predefined precaching strategies for predefined data types.

One a precaching strategy is built, it is then executed 2200 by the computing device. In one embodiment, a user's precaching strategy is executed whenever the user's mobile device is connected to the network and continues to execute as long as the user is connected to the network. In one embodiment, the precaching strategy only executes when the user is actively interacting with the mobile device.

Under the control of the precaching strategy, the computing device detects 1300 when data refresh conditions have occurred. When a data refresh condition occurs, the computing device then retrieves 2400 the data associated with the refresh condition from the appropriate data source and transmits the data 2500, over the network, to a user device cache accessible to at least one application program running on the user device.

FIG. 4 illustrates one embodiment of a precaching services engine 3000 capable of supporting of at least one embodiment of the process shown in FIG. 3. The engine comprises a precaching strategy creation module 3100, a precaching strategy execution module 3200, a refresh condition detection module 3300, a data retrieval module 3400 and data transmission module 3500.

In one embodiment, each of the modules comprises one or more processors programmed to execute software code retrieved from a computer readable storage medium storing software for functions as described below. In one embodiment, each of the modules could be implemented on servers such as servers 400 and 1800 shown in FIGS. 1 and 2 respectively. Such an embodiment is purely exemplary, and all of the modules shown could be implemented in any combination on any number servers, as will be readily apparent to those skilled in the art.

The precaching strategy creation module 3100 is configured to build precaching strategies for mobile devices. Each of the precaching strategies define a forecast of at least one data type a user is predicted to request after the occurrence of at least one data refresh condition. A precaching strategy is built by recognizing at least one data usage pattern in data requested by a single user or a plurality of users over a time period. At a minimum, the data usage patterns comprise at least one data type. The plurality of users could be any identifiable group of users, such as all users or users on a social graph.

In one embodiment, at least some data usage patterns each additionally comprises at least one event that is correlated to the usage of the data, wherein the at least one event is used by the precaching strategy creation module 3100 to define at least one refresh condition within the respective precaching strategy. Such events can comprise spatial, temporal, social or topical events.

In one embodiment, data types in at least some data usage patterns are used by the precaching strategy creation module 3100 to select a predefined precaching strategy for the data types. In one embodiment predefined precaching strategy for data types are determined by the precaching strategy creation module by recognizing at least one data usage pattern in data requested by a second plurality of users, wherein the data usage pattern comprises the data types. In one embodiment, the data type in the data usage pattern can be used to select a predefined precaching strategy for a data type which represents a generic data type that encompasses the data type.

The precaching strategy execution module 3200 is configured to execute precaching strategies built by the precaching strategy creation module 3100. In one embodiment, a user's precaching strategy is executed whenever the user's mobile device is connected to the network and continues to execute as long as the user is connected to the network. In one embodiment, the precaching strategy only executes when the user is actively interacting with his or her mobile device.

The refresh condition detection module 3300 is configured to detect when data refresh conditions have occurred relating to precaching strategies executed by the precaching strategy execution module 3200.

The data retrieval module 3400 is configured to retrieving data, over a network, from at least one data source, wherein the retrieved data is retrieved according to precaching strategies for where the refresh condition detection module 3300 has detected that data refresh conditions have occurred.

The data transmission module 3500 is configured to transmit data retrieved by the data retrieval module the retrieved data, over the network, to user device caches accessible to at application programs running on the user devices.

Those skilled in the art will recognize that the methods and systems of the present disclosure may be implemented in many manners and as such are not to be limited by the foregoing exemplary embodiments and examples. In other words, functional elements being performed by single or multiple components, in various combinations of hardware and software or firmware, and individual functions, may be distributed among software applications at either the client level or server level or both. In this regard, any number of the features of the different embodiments described herein may be combined into single or multiple embodiments, and alternate embodiments having fewer than, or more than, all of the features described herein are possible. Functionality may also be, in whole or in part, distributed among multiple components, in manners now known or to become known. Thus, myriad software/hardware/firmware combinations are possible in achieving the functions, features, interfaces and preferences described herein. Moreover, the scope of the present disclosure covers conventionally known manners for carrying out the described features and functions and interfaces, as well as those variations and modifications that may be made to the hardware or software or firmware components described herein as would be understood by those skilled in the art now and hereafter.

Furthermore, the embodiments of methods presented and described as flowcharts in this disclosure are provided by way of example in order to provide a more complete understanding of the technology. The disclosed methods are not limited to the operations and logical flow presented herein. Alternative embodiments are contemplated in which the order of the various operations is altered and in which sub-operations described as being part of a larger operation are performed independently.

While various embodiments have been described for purposes of this disclosure, such embodiments should not be deemed to limit the teaching of this disclosure to those embodiments. Various changes and modifications may be made to the elements and operations described above to obtain a result that remains within the scope of the systems and processes described in this disclosure.

Claims

1. A method comprising the steps of: building a precaching strategy, using a computing device, for a mobile device, such that the precaching strategy defines a forecast of a data type a user is predicted to request after the occurrence of a data refresh condition,such that the precaching strategy is built by recognizing, using the computing device, a data usage pattern in data requested by the user using the mobile device over a time period, wherein the data usage pattern comprises the data type and an event that is correlated to the usage of the data, wherein the event is used to define the refresh condition within the precaching strategy, the data type being one of: spatial data, temporal data, social data or topical data and the event being one of: a spatial event, a temporal event, a social event or a topical event, the event further being an event external to the computing device and the mobile device;executing the precaching strategy, using the computing device;detecting, using the computing device, that the data refresh condition has occurred;retrieving data, over a network, from a data source, such that the retrieved data is retrieved according to the precaching strategy;transmitting the retrieved data, over the network, to a mobile device cache accessible to an application program running on the mobile device.

2. The method of claim 1 wherein the data type is determined empirically by recognizing data usage patterns within data usage data.

3. The method of claim 1 wherein the data type is determined by a user type of the user.

4. The method of claim 3 wherein the user type is defined by the user.

5. The method of claim 3 wherein user type is assigned, using the computing device, to the user by identifying a pattern of data types and usage frequencies and correlating such patterns to the user type.

6. The method of claim 1 wherein the data type comprises a hierarchy of a plurality of data types and subtypes, wherein the plurality of data types and subtypes are organized in a plurality of levels.

7. The method of claim 6 wherein spatial, temporal, social and topical patterns of data usage and correlated events are recognized, using the computing device, and used to build strategies at every level of the plurality of levels of the data hierarchy.

8. A method comprising the steps of: building a precaching strategy, using a computing device, for a mobile device, such that the precaching strategy defines a forecast of a data type a user is predicted to request after the occurrence of a data refresh condition,such that the precaching strategy is built by recognizing, using the computing device, a data usage pattern in data requested by a plurality of users over a time period, such that the data usage pattern comprises the data type and an event that is correlated to the usage of the data, wherein the event is used to define the data refresh condition within the precaching strategy, the data type being one of: spatial data, temporal data, social data or topical data and the event being one of: a spatial event, a temporal event, a social event or a topical event, the event further being an event external to the computing device and the mobile device;executing the precaching strategy, using the computing device;detecting, using the computing device, that the data refresh condition has occurred;retrieving data, over a network, from a data source, such that the retrieved data is retrieved according to the precaching strategy;transmitting the retrieved data, over the network, to a mobile device cache accessible to an application program running on the mobile device.

9. The method of claim 8 wherein the plurality of users are selected from the user's social network.

10. The method of claim 8 wherein the data type in the data usage pattern is used to select a predefined precaching strategy for the data type.

11. The method of claim 10 wherein the predefined precaching strategy for the data type was determined by recognizing, using the computing device, a data usage pattern in data requested by a second plurality of users, wherein the data usage pattern comprises the data type.

12. The method of claim 10 wherein the data type in the data usage pattern is used to select a predefined precaching strategy for a data type which represents a generic data type that encompasses the data type.

13. A system comprising: a processor;a storage medium for tangibly storing thereon program logic for execution by the processor, the program logic comprising: logic executed by the processor for building a precaching strategy for a mobile device, such that the precaching strategy defines a forecast of a data type a user is predicted to request after the occurrence of a data refresh condition, such that the precaching strategy is built by recognizing a data usage pattern in data requested by a plurality of users over a time period, such that the data usage pattern comprises the data type and an event that is correlated to the usage of the data, wherein the event is used to define the data refresh condition within the precaching strategy, the data type being one of: spatial data, temporal data, social data or topical data and the event being one of: a spatial event, a temporal event, a social event or a topical event, the event further being an event external to the computing device and the system;logic executed by the processor for executing the precaching strategy;logic executed by the processor for detecting that the data refresh condition has occurred;logic executed by the processor for retrieving data, over a network, such that the retrieved data is retrieved according to the precaching strategy;logic executed by the processor for transmitting the retrieved data, over the network, to a mobile device cache accessible to an application program running on the mobile device.

14. The system of claim 13 wherein the plurality of users are selected from the user's social network.

15. The system of claim 13 wherein the data type in the usage patterns is used to select a predefined precaching strategy for the data type.

16. The system of claim 15 wherein the predefined precaching strategy for the data type was determined by the precaching strategy creation module by recognizing data usage pattern in data requested by a second plurality of users, wherein the data usage pattern comprises the data type.

17. The system of claim 15 wherein the data type in the data usage pattern is used to select a predefined precaching strategy for a data type which represents a generic data type that encompasses the data type.

18. A non-transitory computer-readable medium having computer-executable instructions for a method comprising the steps of: building a precaching strategy for a mobile device, such that the precaching strategy defines a forecast of a data type a user is predicted to request after the occurrence of a data refresh condition,such that the precaching strategy is built by recognizing a data usage pattern in data requested by a plurality of users over a time period, such that the data usage pattern comprises the data type and an event that is correlated to the usage of the data, wherein the event is used to define the data refresh condition within the precaching strategy, the data type being one of: spatial data, temporal data, social data or topical data and the event being one of: a spatial event, a temporal event, a social event or a topical event, the event further being an event external to the mobile device;executing the precaching strategy;detecting that the data refresh condition has occurred;retrieving data, over a network, from data source, such that the retrieved data is retrieved according to the precaching strategy;transmitting the retrieved data, over the network, to a mobile device cache accessible to an application program running on the mobile device.

19. The non-transitory computer-readable medium of claim 18 wherein the plurality of users are selected from the user's social network.

20. The non-transitory computer-readable medium of claim 18 wherein the data type in the data usage pattern is used to select a predefined precaching strategy for the data type.

21. The non-transitory computer-readable medium of claim 20 wherein the predefined precaching strategy for the data type was determined by recognizing a data usage pattern in data requested by a second plurality of users, wherein the data usage pattern comprises the data type.

22. The non-transitory computer-readable medium of claim 20 wherein the data type in the data usage pattern is used to select a predefined precaching strategy for a data type which represents a generic data type that encompasses the data type.