System and method for providing an interactive content portal on a mobile device

A portal application is provided that can be used on a mobile device to display relevant advertising content to the user at convenient times. The portal application can utilize a portal browser that is launched when appropriate, which displays the advertising content in an interactive way and enables the user to follow up with tasks requiring a data connection that is currently unavailable, by keeping track of a user queue. The advertising content may be filtered from a base of advertising content provided by the advertising content providers in advanced and is pre-fetched and stored in an advertising content cache for convenient access when appropriate. The portal application can be used with a location estimator to narrow and categorize the advertising content at least in part based on location, either physical location or preferred location or both based on a hierarchy of relevant data.

TECHNICAL FIELD

The following relates generally to mobile telecommunications, and more particularly, to systems and methods for providing an interactive content portal on a mobile device.

DESCRIPTION OF THE RELATED ART

Advertising, both direct advertising and that which is associated with a provided service (e.g. brought to you by Company X) may be used as a way to offset the cost of providing such a service, e.g. wherein the advertiser pays for all or part of the service in exchange for a venue to present advertising content to one or more users. Advertising may only be effective if the user is interested in the content and can become a nuisance if the user is overwhelmed with too much content, or content that may be deemed inappropriate or irrelevant.

Accordingly, the way in which advertising content is gathered and distributed is generally done with the end user in mind. When advertising through television, radio and the Internet, advertising content is traditionally directed to what the likely audience would be for the delivered content. This can be a useful way for advertisers to be confident that they are advertising in the most appropriate venue, at least in a general sense, but may only work when broadcasting according to a schedule or associating the advertising content with a particular medium such as a website that has a specific purpose or target audience.

On a mobile device, although the user may have access to such broadcasted content and may be able to access particular media, various other uses of the mobile device may command the user's attention at various times during a given day. As such, advertising on a mobile device can be more challenging than simply associating generic advertising content with a given medium.

DETAILED DESCRIPTION

It has been recognized that various instances where one or more channels on a mobile device are idle or inactive can provide an appropriate venue and an appropriate time for directing advertising content to the mobile device user. As will be discussed herein, a portal application is provided that can be used on a mobile device, either at predetermined or event driven times or by sensing a user initiation, to display relevant advertising content to the user at convenient times. The portal application thus provides an interactive content portal on the mobile device. In this way, advertising content providers can be more confident that the advertising space they are purchasing is being directed to the appropriate users and the users can be confident that they are unlikely to be overwhelmed with advertising content at inappropriate times with inappropriate content. The portal application can be launched when appropriate to display the advertising content in an interactive way, which may also enable the user to follow up with tasks requiring a currently unavailable data or voice connection, by keeping track of a queue of user-initiated tasks. The advertising content may be filtered from the base of advertising content provided by the advertising content providers in advance and can be pre-fetched and stored in an advertising content cache for convenient access when appropriate. Screen control of the portal application also allows the user to get more out of their browsing experience during the idle event, e.g. for the duration of a phone call which may require minimal user activity other than voice.

It has also been recognized that the location of a mobile device and its user, both physically and according to user preferences, can be more intelligently estimated using a multi-level hierarchy that includes not only available device-tracking mechanisms but also user input. As will also be described, the portal application and any other location based service (LBS) can be used with a location estimator to narrow and categorize the advertising content at least in part based on location, either physical location or preferred location or both. The location estimator can therefore improve the filtering of the advertising content and the portal application illustrates one example of an application making use of an LBS. The different configurations described herein are for illustrative purposes only and it will be appreciated that variations of these configurations can be made while utilizing the principles discussed herein.

Examples of applicable communication devices include without limitation pagers, cellular phones, satellite phones, smart-phones, wireless organizers, personal digital assistants, computers, laptops, handheld wireless communication devices, wirelessly enabled notebook computers, wireless media players, wireless navigation devices, wireless heart or exercise monitors, and the like. Such devices will hereinafter be commonly referred to as “mobile devices” for ease of illustration.

An exemplary mobile device generally comprises a two-way communication device with advanced data communication capabilities including the capability to communicate with other mobile devices or computer systems through a network of transceiver stations. The mobile device may also have the capability to allow voice communication. Depending on the functionality provided by the mobile device, it may be referred to as a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance, or a data communication device (with or without telephony capabilities).

The mobile device may be one that is used in a system that is configured for continuously routing all forms of pushed information from a host system to the mobile device. One example of such a system will now be described.

Referring now to the drawings,FIG. 1is a block diagram showing an exemplary system for the redirection of user data items (such as message A or C) from a corporate enterprise computer system (host system)250to the user's mobile device100via a wireless router26. The wireless router26provides the wireless connectivity functionality as it acts to both abstract most of the wireless network's200complexities, and it also implements features to support pushing data to the mobile device100. Although not shown, a plurality of mobile devices may access data from the host system250. In this example, message A inFIG. 1represents an internal message sent from, e.g. a desktop computer262within the host system250(seeFIG. 11), to any number of server computers in the corporate network260(e.g. LAN), which may, in general, comprise a database server, a calendar server, an E-mail server or a voice-mail server. More detail concerning the host system250will be provided below and is shown inFIG. 11.

Message C inFIG. 1represents an external message from a sender that is not directly connected to the host system250, such as the user's mobile device100, some other user's mobile device (not shown), or any user device connected to the public or private network224(e.g. the Internet). Message C could be e-mail, voice-mail, calendar information, database updates, web-page updates or could even represent a command message from the user's mobile device100to the host system250. The host system250may comprise, along with the typical communication links, hardware and software associated with a corporate enterprise computer network system, one or more wireless mobility agents, a TCP/IP connection, a collection of datastores, (for example a data store for e-mail could be an off-the-shelf mail server like Microsoft Exchange® Server or Lotus Notes® Server), all within and behind a corporate firewall as will be explained further below.

The mobile device100may be adapted for communication within wireless network200via wireless links, as required by each wireless network200being used. As an illustrative example of the operation for a wireless router26shown inFIG. 1, consider a data item A, repackaged in outer envelope B (the packaged data item A now referred to as “data item (A)”) and sent to the mobile device100from an Application Service Provider (ASP) in the host system250. Within the ASP is a computer program, similar to a wireless mobility agent, running on any computer in the ASP's environment that is sending requested data items from a data store to a mobile device100. The mobile-destined data item (A) is routed through the network224, and through the wireless router's26firewall27protecting the wireless router26(see alsoFIG. 8).

Although the above describes the host system250as being used within a corporate enterprise network environment, this is just one embodiment of one type of host service that offers push-based messages for a handheld wireless device that is capable of notifying and presenting the data to the user in real-time at the mobile device when data arrives at the host system.

By offering a wireless router26, there may be a number of advantages to both the host system250and the wireless network200in accordance with various embodiments. The host system250in general runs a host service that is considered to be any computer program that is running on one or more computer systems. The host service is said to be running on a host system250, and one host system250can support any number of host services. A host service may or may not be aware of the fact that information is being channeled to mobile devices100. For example an e-mail or message program138(seeFIG. 4) might be receiving and processing e-mail while an associated program (e.g. an e-mail wireless mobility agent) is also monitoring the mailbox for the user and forwarding or pushing the same e-mail to a wireless device100. A host service might also be modified to prepare and exchange information with mobile devices100via the wireless router26, like customer relationship management software. In a third example, there might be a common access to a range of host services. For example a mobility agent might offer a Wireless Access Protocol (WAP) connection to several databases.

As discussed above, a mobile device100may be a handheld two-way wireless paging computer as exemplified inFIGS. 2-3, a wirelessly enabled palm-top computer, a mobile telephone with data messaging capabilities, a PDA with mobile phone capabilities, a wirelessly enabled laptop computer, a vending machine with an associated OEM radio modem, a wirelessly-enabled heart-monitoring system or, alternatively, it could be other types of mobile data communication devices capable of sending and receiving messages via a network connection. Although the system is exemplified as operating in a two-way communications mode, certain aspects of the system could be used in a “one and one-half” or acknowledgment paging environment, or even with a one-way paging system. In such limited data messaging environments, the wireless router26still could abstract the mobile device100and wireless network200, offer push services to standard web-based server systems and allow a host service in a host system250to reach the mobile device100in many countries.

The host system250shown herein has many methods when establishing a communication link to the wireless router26. For one skilled in the art of data communications the host system250could use connection protocols like TCP/IP, X.25, Frame Relay, ISDN, ATM or many other protocols to establish a point-to-point connection. Over this connection there are several tunneling methods available to package and send the data, some of these include: HTTP/HTML, HTTP/XML, HTTP/Proprietary, FTP, SMTP or some other proprietary data exchange protocol. The type of host systems250that might employ the wireless router26to perform push could include: field service applications, e-mail services, stock quote services, banking services, stock trading services, field sales applications, advertising messages and many others. This wireless network200abstraction is made possible by the wireless router26, which implements this routing and push functionality. The type of user-selected data items being exchanged by the host could include: E-mail messages, calendar events, meeting notifications, address entries, journal entries, personal alerts, alarms, warnings, stock quotes, news bulletins, bank account transactions, field service updates, stock trades, heart-monitoring information, vending machine stock levels, meter reading data, GPS data, etc., but could, alternatively, include any other type of message that is transmitted to the host system250, or that the host system250acquires through the use of intelligent agents, such as data that is received after the host system250initiates a search of a database or a website or a bulletin board.

The wireless router26provides a range of services to make creating a push-based host service possible. These networks may comprise: CDMA (Code Division Multiple Access) networks, GSM (Groupe Special Mobile or the Global System for Mobile Communications) networks, GPRS (General Packet Radio Service) networks, and third-generation (3G) and fourth-generation (4G) networks including without limitation EDGE (Enhanced Data rates for GSM Evolution), UMTS (Universal Mobile Telecommunications System), HSDPA (High-Speed Downlink Packet Access), LTE (Long Term Evolution), WiMAX (Worldwide Interoperability for Microwave Access), etc. Some older examples of data-centric networks include, but are not limited to: the Mobitex Radio Network (“Mobitex”) and the DataTAC Radio Network (“DataTAC”).

To be effective in providing push services for host systems250, the wireless router26may implement a set of defined functions. It can be appreciated that one could select many different hardware configurations for the wireless router26, however, many of the same or similar set of features would likely be present in the different configurations. The wireless router26may offer any one or more of the following features for host services: 1) An addressing method so that mobile device100traffic can be addressed to a host system250without the need for the wireless network200to assign an identity to each host system250; 2) An efficient and authenticated method for the host system250to initiate a communication connection to the wireless router26for the purposes of opening a communication tunnel to the one or more mobile devices100that the host system250wishes to communicate with; 3) A reliable method for exchanging data between the host system250and the mobile device100, in a manner consistent with the abilities of the wireless network200; 4) Providing feedback to the host system250when data is delivered, which allows the host system to clean up any wireless delivery queues if necessary, or inform the original sender (user or program) that the data has been delivered to the mobile device100; 5) Implementation of a wireless network200initiated push of services or data to a mobile device100, from a wireless router26; and 6) Connecting to a wide range of wireless networks200and provide a way of tracking the user's location so that a “follow you anywhere” solution can be provided.

To aid the reader in understanding the structure of the mobile device100and how it communicates with the wireless network200, reference will now be made toFIGS. 2 and 3.

Referring first toFIG. 2, shown therein is a block diagram of an exemplary embodiment of a mobile device100. The mobile device100comprises a number of components such as a main processor102that controls the overall operation of the mobile device100. Communication functions, including data and voice communications, are performed through a communication subsystem104. The communication subsystem104receives messages from and sends messages to a wireless network200. In this exemplary embodiment of the mobile device100, the communication subsystem104is configured in accordance with the Global System for Mobile Communication (GSM) and General Packet Radio Services (GPRS) standards, which is used worldwide. Other communication configurations that are equally applicable are the 3G and 4G networks such as EDGE, UMTS and HSDPA, LTE, Wi-Max etc. New standards are still being defined, but it is believed that they will have similarities to the network behaviour described herein, and it will also be understood by persons skilled in the art that the embodiments described herein are intended to use any other suitable standards that are developed in the future. The wireless link connecting the communication subsystem104with the wireless network200represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for GSM/GPRS communications.

The main processor102also interacts with additional subsystems such as a Random Access Memory (RAM)106, a flash memory108, a display110, an auxiliary input/output (I/O) subsystem112, a data port114, a keyboard116, a speaker118, a microphone120, a GPS receiver121, short-range communications122, and other device subsystems124.

Some of the subsystems of the mobile device100perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. By way of example, the display110and the keyboard116may be used for both communication-related functions, such as entering a text message for transmission over the network200, and device-resident functions such as a calculator or task list.

The mobile device100can send and receive communication signals over the wireless network200after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of the mobile device100. To identify a subscriber, the mobile device100may use a subscriber module component or “smart card”126, such as a Subscriber Identity Module (SIM), a Removable User Identity Module (RUIM) and a Universal Subscriber Identity Module (USIM). In the example shown, a SIM/RUIM/USIM126is to be inserted into a SIM/RUIM/USIM interface128in order to communicate with a network. Without the component126, the mobile device100is not fully operational for communication with the wireless network200. Once the SIM/RUIM/USIM126is inserted into the SIM/RUIM/USIM interface128, it is coupled to the main processor102.

The mobile device100is a battery-powered device and includes a battery interface132for receiving one or more rechargeable batteries130. In at least some embodiments, the battery130can be a smart battery with an embedded microprocessor. The battery interface132is coupled to a regulator (not shown), which assists the battery130in providing power V+ to the mobile device100. Although current technology makes use of a battery, future technologies such as micro fuel cells may provide the power to the mobile device100.

The mobile device100also includes an operating system134and software components136to146which are described in more detail below. The operating system134and the software components136to146that are executed by the main processor102are typically stored in a persistent store such as the flash memory108, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that portions of the operating system134and the software components136to146, such as specific device applications, or parts thereof, may be temporarily loaded into a volatile store such as the RAM106. Other software components can also be included, as is well known to those skilled in the art.

The subset of software applications136that control basic device operations, including data and voice communication applications, may be installed on the mobile device100during its manufacture. Software applications may include a message application138, a device state module140, a Personal Information Manager (PIM)142, a connect module144and an IT policy module146. A message application138can be any suitable software program that allows a user of the mobile device100to send and receive electronic messages, wherein messages are typically stored in the flash memory108of the mobile device100. A device state module140provides persistence, i.e. the device state module140ensures that important device data is stored in persistent memory, such as the flash memory108, so that the data is not lost when the mobile device100is turned off or loses power. A PIM142includes functionality for organizing and managing data items of interest to the user, such as, but not limited to, e-mail, text messages, instant messages, contacts, calendar events, and voice mails, and may interact with the wireless network200. A connect module144implements the communication protocols that are required for the mobile device100to communicate with the wireless infrastructure and any host system250, such as an enterprise system, that the mobile device100is authorized to interface with. An IT policy module146receives IT policy data that encodes the IT policy, and may be responsible for organizing and securing rules such as the “Set Maximum Password Attempts” IT policy.

Other types of software applications or components139can also be installed on the mobile device100. These software applications139can be pre-installed applications (i.e. other than message application138) or third party applications, which are added after the manufacture of the mobile device100. Examples of third party applications include games, calculators, utilities, etc.

The additional applications139can be loaded onto the mobile device100through at least one of the wireless network200, the auxiliary I/O subsystem112, the data port114, the short-range communications subsystem122, or any other suitable device subsystem124.

The data port114can be any suitable port that enables data communication between the mobile device100and another computing device. The data port114can be a serial or a parallel port. In some instances, the data port114can be a USB port that includes data lines for data transfer and a supply line that can provide a charging current to charge the battery130of the mobile device100.

For voice communications, received signals are output to the speaker118, and signals for transmission are generated by the microphone120. Although voice or audio signal output is accomplished primarily through the speaker118, the display110can also be used to provide additional information such as the identity of a calling party, duration of a voice call, or other voice call related information.

For composing data items, such as e-mail messages, for example, a user or subscriber could use a the touch-sensitive overlay34on the display32that are part of the touch screen display28, in addition to possibly the auxiliary I/O subsystem122. The auxiliary I/O subsystem112may include devices such as: a mouse, track ball, infrared fingerprint detector, or a roller wheel with dynamic button pressing capability. A composed item may be transmitted over the wireless network200through the communication subsystem104.

FIG. 3shows an example of some of the other software applications and components139that may be stored and used on the mobile device100. Only a few representative examples are shown inFIG. 3for illustrative purposes and such examples are not to be considered exhaustive. In this example, the mobile device100includes, stores and operates a location estimator54for gathering and determining location data pertaining to the mobile device100, the GPS application56for obtaining GPS coordinates from the GPS receiver121for use with an LBS or on-device mapping functions etc and a calendar application58for storing appointments and contacts etc. The other applications139also include, in this example, a portal application60, which, as will be described in greater detail below, provides an advertising and multimedia content portal on the mobile device display12during idle periods such as when the user is on a phone call or when an otherwise “idle” period is detected. The portal application60utilizes a portal queue data store61, which maintains a queue of actions that require a data communications link which is currently being used by the main application (e.g. phone) and thus otherwise unavailable to the portal application60. An example would be a click-through to an advertiser's website. In other words, the contents of the portal queue61are associated with user interactions with the portal application60that cannot be executed until the currently running application (e.g. phone) is cancelled and provides a set of instructions to execute when the data communications link becomes available. The portal application60also has access to an advertising content cache63, which stores one or more sets of cached advertising and multimedia content that is displayed to the user through the portal application60. As shown, the advertising content cache63may itself store a legacy or log338that can track previous advertising content and user interactions with the portal application60to minimize repetition and to allow users to access old content if desired.

Also shown inFIG. 3is a user portal profile62and a user location profile64. The portal profile62, which will be shown and explained in greater detail with reference toFIG. 10, contains user selected information to assist the portal application60in determining what content should be provided to the user and when. As will be explained below, the portal profile62contains information such as demographic and user-specified requests for certain content, and can be linked to the location profile62. The portal profile62can be used to filter advertising content either before it enters the cache63(i.e. at some intermediary) or on the mobile device100before it is displayed through the portal application60. As such, the advertising content cache63can include pre-filtered content or user-specific content depending on whether the advertising content is processed for the user at such an intermediary or on the mobile device100. Examples are provided below illustrating variations in such filtering. The location profile64contains user-specified information to assist in making location-based decisions for matching advertising content to a particular user, i.e. to provide context. As will be discussed below and as shown inFIG. 9, the location profile64contains a user's location-based preferences that relate to both physical location (of the mobile device100) and preferred location, i.e. locations that may be different than the actual location of the mobile device100.

Location based services (LBS)298for the mobile device100are naturally dependent on knowledge of the location of the mobile device100in order to determine appropriate, location-based content for the user of the mobile device100, in particular where the content is location dependent or would otherwise be more relevant if filtered based on physical location or user location-based preferences or both.

Turning now toFIGS. 4 to 6, various configurations are shown for providing location data300to an LBS298in order to obtain or receive user-specific content, herein referred to as LBS content302. The systems shown inFIGS. 4 to 6are utilized to localize information such as weather, news, local events, etc. according to a location hierarchy of: 1) GPS location; 2) Current cell tower location; 3) User Input or Preferences; and 4) Data available from the SIM/RUIM/USIM card126(e.g. area code or postal code). This hierarchy can be used alone to provide location data that relates only to the physical location of the mobile device100or along with user-input related location data. Such user-input related location data can be used for filtering certain LBS content302such as advertisements for a user based on locations specified by user preferences (e.g. as specified in the user location profile64) rather than or in addition to the physical location of the mobile device100. In this way, for example, a user can receive news from their home city even when travelling. Although the systems shown inFIGS. 4 to 6include simplified block diagrams showing only certain ones of the components involved in generating location data300and LBS content302, it will be appreciated that these configurations can be implemented with the systems and operations thereof as described above as well as other similar systems.

Referring now toFIG. 4, one configuration comprises having the location estimator54reside solely on the mobile device100with the LBS298at an intermediate node or intermediary such as the host system250or router26described above. It will be appreciated that the host system250and router26are shown only for illustrative purposes and for ease of explanation and other intermediaries such as ISPs, third party web servers and the like may also perform this role. This configuration divides the processing tasks associated with the location estimation and filtering processes between the mobile device100and the host system250or router26. In this way, the mobile device100runs the location estimator54to provide to the LBS298the location data300available to the mobile device100and, in return, the LBS298filters and provides location-specific LBS content302to the mobile device100. The LBS content302can be used in many different applications on the mobile device100such as for providing user-specific advertising content to the user as will be exemplified below.

FIG. 5shows another configuration that divides the processing requirements between the mobile device100and the intermediary—i.e. the host system250or router26in this example. In this configuration, portion A of the location data300is determined or otherwise acquired at the mobile device100by a mobile location estimator54aand sent to a central location estimator54bat the intermediary. Portion A is combined with portion B of the location data300to generate the complete set of location data300, which is processed by the LBS298as in the above configuration to generate the LBS content302. This configuration is most suitable where certain location information is more conveniently accessed by the mobile device100whereas other location information is more conveniently or efficiently accessed at the intermediary. For example, the GPS location may be acquired on the mobile device100and sent to the host system250or router26which stores and updates the user location profile64.

Referring now toFIG. 6, one example is shown where all of the location estimation tasks are handled by one entity, in this example the mobile device100. It will be appreciated that a similar configuration wherein all components reside at the intermediary may also be used. It can be seen inFIG. 6that the location estimator54generates the location data300in a manner similar to the configuration ofFIG. 4, however, in this configuration, the LBS298resides on the mobile device100and thus the LBS content302can be generated locally and used in connection with a program or application without relying on a connection with the intermediary at all times. In the example shown, the LBS content302is provided to the display110component of the mobile device100that operates the physical display12.

FIG. 7illustrates an example of the flow of data to the location estimator54for generating the location data300. In this example, the location estimator54utilizes GPS location303, cell tower location304, location-related SIM data305and user input data306according to a hierarchy as described in greater detail below (see alsoFIG. 8). The GPS location303, depending on whether this data is acquired by the mobile device100or the intermediary (host system250or router26in this embodiment), is acquired from either the GPS receiver121(on the mobile device100) or directly from an associated GPS system307(at the intermediary) if available. The cell tower location304can be obtained directly from an HLR212of the wireless network200, in particular from a specific node202(details provided above) or any other network component that is capable of determining or having access to the location of the mobile device100with respect to a certain one or ones of the cell towers in the wireless network200. It will be appreciated that other techniques for obtaining location may be used in various embodiments such as without limitation, obtaining information from the VLR214, or triangulation using at least three tower stations, or other suitable techniques. The location-related subscriber data305is obtained from the SIM/RUIM/USIM card126through the SIM/RUIM/USIM interface128and may include any location-specific information stored in the SIM/RUIM/USIM card126. This may include the area code of the mobile device's phone number, a postal code or other address information or even calendar appointments that are sometimes stored temporarily on the SIM/RUIM/USIM card126.

As can be seen inFIG. 7, the user input data306can come from various different locations and processes. The examples shown inFIG. 7include the user location profile64, a prompt308through the display12and display component110, the calendar application58, map favorites309and other user data310. The prompt308can be an optional mechanism for obtaining user input when other relevant data cannot be found or if the user chooses to actively participate in specifying their location. The prompt308can include a dialog box with an entry portion to enable the user to enter their current location if prompted. The calendar application58can provide appointment details such as location of a meeting. The map favorites309illustrates one way of obtaining relevant user data indirectly. For example, users often use a map application (not shown) on their mobile device100to find directions to a specific location. Depending on how long it has been since the map application has been used, the map data that was last accessed or as shown inFIG. 7, map data that is included as a favorite may be useful in determining a relevant location. The other user data310can be from any application or service for the mobile device100that can provide an indication, however insignificant, of where the user may be, may wish to be, has been etc.

The user location profile64is shown in greater detail inFIG. 9. As noted above, the user location profile64enables a user to specify location-based preferences so that LBS content302such as advertisements, weather, news, etc. can be tailored to their lifestyle. Since a user's physical location may not necessarily correspond to the relevant location for the user, the user location profile64allows the user to customize content for relevance. For example, although the user's physical location is typically relevant for weather information, a user may prefer to receive news articles that are local to where they live or work, regardless of their physical location. Another example pertains to language. A user travelling in Europe may presently be in France but live in Germany and thus wish to receive only German-language advertisements, news and other content even when currently in France. Turning now toFIG. 9, several examples of suitable user preference options are shown. In this example, the user can select and distinguish between a default location311and an override location314. The default location311can be used to specify a location to be associated with the user if no other information is available. The override location can be used to override other mechanisms for estimating physical location and other preferences. An example of a use for the default location311would be for the user to specify their home city or where they work, i.e. a place where they spend a significant amount of time and thus sporting events, concert tickets and other promotions would likely be of interest to them. An example of a use for the override location314would enable a user to override more relevant information and direct it to the specified city. In this way, a user that is travelling may wish to only receive weather reports for their home city even though they are experiencing different weather in their physical location. Any other motivation can form the basis for specifying an override or default at the user's discretion. As can be seen, when displayed in a user interface (UI), the location profile64can include ON/OFF toggle buttons312to enable the user to turn the associated feature on or off as well as input boxes313to specify the desired location. As also shown inFIG. 9, the user can specify whether or not they may be prompted to provide their location by turning a user input prompt option301to be “ON” or “OFF”.

The user location profile64can also allow the user to specify a location316for a number of different categories315. The examples given inFIG. 9include entertainment, weather, sports, news and language categories315and illustrates several input mechanisms to allow the user to conveniently set and modify their preferences. These include input boxes317, multi-choice buttons318with different regional preferences, and multi-choice buttons319showing available languages. It will be appreciated that the categories315and selection mechanisms312,313,317,318,319shown inFIG. 9are for illustrative purposes only and that any suitable UI components can also be used in addition to or rather than those shown. In general, the location profile64allows the LBS298to filter the available content to provide a more relevant set of LBS content302to a specific user. It can be seen that user selected preferences can be used to improve the relevance of the LBS content302for that user.

Having access to location-based information such as the GPS location303, cell tower location304, user input data306and location related subscriber data305, the location estimator54can use a hierarchical approach for generating the location data300. In one embodiment, the location estimator54applies a hierarchy to estimate a physical location (PL) for the mobile device100so that the LBS298can associate relevant content with that particular mobile device100. In another embodiment, the location estimator54applies the hierarchy to estimate the PL while in parallel using the user input data306to provide additional context for the LBS298. This allows the LBS298to associate some content with physical location and other content with user-specified locations. For example, the LBS298may provide weather data that is relevant to the user's surroundings and sports scores relevant to home teams, preferred leagues etc. As noted above and shown inFIGS. 4-6, the location estimator54can operate in the mobile device100, in an intermediary or both. The LBS298can also operate in the mobile device100, in an intermediary or both. The following examples apply to any one of these configurations.

FIG. 8illustrates one example of a series of computer readable instructions performed by the location estimator54to generate the location data300. This example applies the following hierarchy for estimating the PL: 1) GPS location; 2) Cell tower location; 3) User input data and other user related information; and 4) Subscriber location-based data. Following this hierarchy, if the GPS location is not available, the cell tower location can be used. If the cell tower location is also unavailable, the user input and other information can be used, e.g. without limitation a calendar appointment, location profile, geotagging data associated with a web site, blog, RSS feed, or photograph, etc., (e.g., data uploaded by the mobile device100to a web site such as Twitter™, Facebook™, or Flickr™, etc.). If no relevant user data can be found, data on the SIM/RUIM/USIM card126can be used. At500, the location estimator54checks the GPS receiver121or GPS system307for any available GPS coordinates. Tolerances can be specified such as how current are the coordinates. At502, if the GPS coordinates are available and relevant, the location estimator54sets the PL to be equal to the GPS location at504. If the GPS coordinates are not available or are out-of-date, the next level in the hierarchy, namely the cell tower location304is investigated at506. At508, if the cell tower location304is available, e.g. from the HLR212, then the PL is set to be a region or area associated with or close to the specified cell tower at510. If the cell tower location304is not available or otherwise not relevant, the next level in the hierarchy is examined, namely the user input data306at512. If relevant user input data306is deemed to be available at514, the most relevant of such available user input data306is used by the location estimator54to provide an approximate PL at516. Further details of such an approximation are explained in greater detail below making reference toFIG. 11. If the user input data306is not available or cannot be deemed acceptable or relevant, the location estimator54instructs the processor102to access data from the SIM/RUIM/USIM card126through the SIM/RUIM/USIM interface128at518. Since the SIM/RUIM/USIM card126stores at least the phone number for the mobile device100, it will have at the very least an area code that can be used to specify the PL. It can be appreciated that by virtue of the mobile device100being “mobile”, the area code is typically not as relevant as, e.g. the GPS coordinates; however does ensure that a location can be specified. The SIM/RUIM/USIM card126may also store other information such as an address and postal code, recent calendar appointments and other data that can provide evidence of a relevant location. Therefore it may be appreciated that the location-based subscriber data305may comprise any available data and should not be limited to area code only. If the hierarchy proceeds to this level, then the most relevant location-based subscriber data305is used to set the PL at520.

As can be seen inFIG. 8, in addition to determining PL, the location estimator may, in parallel to applying the hierarchy, determine user location-based preferences at522and prepare a user location rule set at524. This rule set and the PL determined above are combined at526to prepare a data300packet or other data structure suitable for providing the location data528to the LBS298. The user location-based preferences522are determined from the user input data512, namely in this example as taken from the user location profile64. The rule set prepared at524can specify locations for certain categories and rules for overriding or defaulting certain content to the specified locations. As explained below, the user location-based preferences can also be estimated from other user input data306such as appointments extracted from the calendar application58and location data extracted from map favourites309.

As noted above, the location estimator54can at one level of the hierarchy, approximate PL according to user input data306, i.e. when determining if the user input data306is available at514.FIG. 11illustrates one example for performing such an approximation, using the exemplary user input data306shown inFIG. 15. At530-536, the location estimator54first gathers the relevant data, e.g. by having the processor102access the calendar application58, the map program and any other user data. At this time, the location estimator54can access the user location profile64to determine if any overrides or defaults exist that would assist in performing the location approximation. Then, at538, the location estimator first determines if there is an override location314specified by the user. As discussed above, this can be used to ignore actual PL in favour of a user-specified location. If it is determined at540that an override location314has been specified (i.e. toggle button312is set to “ON” and a location entered at input box313), the PL is set to the override location314at542. If the user has turned off the override location314or this information is otherwise not available, the location estimator54may then compare the calendar data to the map data. This may be done to determine if there is any correlation between an appointment and a recently accessed map location. For example, a user when reminded of a meeting may use their map program to find directions. If the calendar and map data are deemed to be similar at546, the PL is set to be the common location data at548. If such data is not similar, this may indicate that the most recent location in the map program has nothing to do with a current or recent appointment. It may be noted that if no recent calendar appointments even exist,544-548may simply be skipped. If the calendar and map data are not similar, this data may then be compared to the other user data at550. For example, the other user data310may include a memo or note that provides context for an appointment or for a map. If the other data310is deemed to be similar or relevant at552, the similar location is used as the PL at554. It will be appreciated that in some embodiments, only the calendar data may be referenced without any correlation with other data performed. For example, if an appointment in the user's calendar comprises a location field, which is populated, such location field can be used to determine the mobile device's location, in particular where the meeting is hosted by or has been accepted by the user.

If the calendar, map and other data do not correlate in any way, the location estimator may then use any available location information in the calendar appointment at556. If a location can be found in the calendar appointment, the PL is then set to be the location specified in the calendar appointment at558. An example would be a meeting appointment that gives an address for a client or customer site, which can indicate to the location estimator54where the user is at that time. It may be noted that the other user data310may include an indication as to whether or not the user accepted the appointment in the calendar since appointments that are scheduled but not necessarily accepted may still be posted in the calendar application58. If the calendar application58does not provide any relevant location-based information, the location estimator54may then check for a user default location311at560. In this way, the user can specify a default so that if no relevant and current information is available, the location estimator54can choose the default location311as the PL at564to ensure the LBS content302is at least directed to an associated and familiar geographical area. If the user default location311is not turned “ON” or is not relevant (e.g. misspelled location in input box313), the location estimator54then determines if the user has permitted a prompt308to be used at566, i.e. set the prompt option301to “YES”. If a prompt308is permitted, the prompt308is displayed to the user at568. The prompt308may expire after a specified amount of time so as to not disrupt the PL approximation process in case a user response is not received at572. If the prompt308is not permitted or a response to the prompt308is not received in a predetermined amount of time, the PL approximation routine ends at570. If a response to the prompt308is received at572, the user input acquired from the prompt308is used to approximate the PL at574.

It can be seen fromFIGS. 8 and 11that if the user input data306is irrelevant or otherwise not available at514, the location-based subscriber data305is instead used as the PL. As such, the hierarchy enables the location estimator54to step through data available to the mobile device100(and/or intermediary if applicable) and at any given time give the best estimate possible for ensuring the LBS content302is relevant to the user of the mobile device100.

Referring now toFIGS. 10 and 12to17, operation of the location estimator54will be exemplified as used with the portal application60discussed above.FIGS. 12 and 13illustrate configurations where the LBS298is a portal advertising server298arunning on the intermediary (e.g. host system250or router26) and the mobile device100(as298b) respectively. Turning first toFIG. 12, it can be seen that the portal application60in this example resides on the mobile device100along with the location estimator54, similar to the configuration shown inFIG. 12. For the sake of convenience, other relevant mobile device components are shown inFIG. 12such as the location profile64, portal profile62, advertising content cache63, user portal queue61, input devices (e.g. any one or more of112,114,116,120,121,122) and the display component110. In this example, the mobile device100provides the location data300using the location estimator54, as described above and shown inFIGS. 4-9and11; and provides profile data325as specified in the portal profile62. It will be appreciated that data from the portal profile62may also be transported with the location data300and is shown as a separate data packet only for the sake of clarity. The mobile device100receives from the host system250or router26, the advertising content302athat is deemed to be relevant to the user of the mobile device100, which is stored in the advertising content cache63for use by the portal application60during idle periods, which are determined by detecting “idle events”. In general, idle events can be associated with the way in which the mobile device100is being used, e.g. while certain applications are being used, or can be associated with certain time periods such as typical time periods when the user's attention may be more obtainable.

The portal advertising server298arepresents an exemplary implementation of the LBS298shown inFIGS. 4-6and thus it will be appreciated that the advertising server298may operate according to the principles discussed above. The portal advertising server298ahas access to an advertising content data store326, which typically contains all available LBS content302, including that which is relevant to the user of the mobile device100shown inFIG. 12as well as other users of other mobile devices100that are not shown. In other words, the advertising content326at the intermediary contains the unfiltered content that is filtered per-user by the portal advertising server298awhen generating the advertising content302athat is sent to the mobile device100. As can also be seen inFIG. 12, the intermediary obtains advertising content327and advertiser data328from advertising content providers329through the network200or any other suitable communication method. It may be noted that “advertising content” (both filtered and original) and “advertiser data” collectively refer to content and details respectively of and from providers of any content that is used by the portal application60, including content that is considered to be an advertisement in the traditional sense as well as other content that may be, e.g., “brought to you by” an advertiser, such content including weather and news content (i.e. not an advertisement in and of itself). The term “advertiser” and “advertisement” are thus used only for illustrative purposes in describing the mechanisms for operating the portal application60as described in detail below.

FIG. 13illustrates a configuration where the mobile device100runs a local version of the portal advertising server298a. In this configuration, the advertising content327originating from the content provider329is sent directly to the portal advertising server298bon the mobile device100, which is then filtered for relevance, and the advertising content302bis then stored in the advertising content cache63. It will be appreciated that the advertising content cache63can be used to store both unfiltered and filtered advertising content327and302brespectively and the data flow shown inFIG. 13is merely provided for clarity and ease of understanding. The advertising content327can be pushed to the portal advertising server298bby the advertising content provider329(which according to the above would utilize the router26) or can be downloaded (i.e. pulled) by the mobile device100at periodic intervals. It will be appreciated that portal application60may operate on the mobile device100as exemplified below and shown inFIGS. 14-17regardless of which configuration is used for obtaining the filtered advertising content302aor302b.

Turning now toFIGS. 14(a) and14(b) a generic screen shot is shown which illustrates a UI for the portal application60, in this example referred to as a portal browser331. The portal browser331is launched by the portal application60during specified “idle” periods when the mobile device100detects “idle events”, to provide the advertising content302to the user and thus take advantage of the idle period. In many instances, the idle period coincides with a busy data communication link and therefore the advertising data cache63can be advantageously populated with advertising content302by pre-fetching the advertising content302with up to data content on a regular basis. As illustrated inFIG. 14(a), the portal browser331is given a portion of the mobile device display12, which it shares with a currently running application, referred to as the “current application330” inFIG. 14(a). The intention for the portal browser331is to provide content to the user at appropriate times when their attention is most conveniently captured. By providing content which is appropriate to the user (and their location if applicable), the user can benefit from being provided with the opportunity to fill idle periods by browsing advertising and media content while also providing a mechanism for generating revenue that can offset some cost of operating the intermediary, in particular when a host system250or router26is required. It may be noted that the portal browser331may also be launched on its own, i.e. without any other application currently running, for example if the idle event is a time-based event such as when a user is expected to be commuting on the subway or waiting for a flight etc. It will be appreciated that in various embodiments, calendar data can be used to determine idle time, e.g. 1 hour before a flight, moving at a high velocity (e.g. determined using GPS), etc. Also, the portal application60can utilize other cues in determining whether to launch the browser331such as detection of movement of the mobile device100using an accelerometer or an altimeter (e.g. if on a plane). A device such as an accelerometer can thus be used to determine when a mobile device100is stationary, being held, or moving to assist in determining when the user's attention is likely to be captured at that moment. Similarly, the mobile device100can detect when it has been docked or placed in a holster or other carrying case when determining if an idle event is appropriate. In addition, the mobile device100can use photosensor data, touch-sensitive input data and other data to determine if an idle event is appropriate. For example, the mobile device100can detect whether it is sheathed in a pocket or held against a user's cheek or face and therefore determine that the display is not being viewed by the user. Furthermore, the mobile device100can detect whether user input, such as keystrokes, touch-sensitive inputs, trackball actuation, positioning wheel actuation, etc., has not been received after a certain threshold time period, when determining if an idle event is appropriate.

The portal application60may operate in this example with the main processor102to instruct the main processor102to intelligently detect an idle event according to predetermined criteria. Such criteria may include detecting when the current application330is one of a list of appropriate applications such as the phone application where the user may be listening to a phone call but is also able to browse the portal browser331at the same time. Other applications that include similar idle events include web browsing, playing a game or rendering a particular type of content such as a news story. Another criterion may include the detection of certain system states such as when a data connection is lost, e.g. when on the subway and reading email but unable to send email or based on cues such as movement, whether the mobile device100has been docked or holstered etc. As such, the portal application60detects certain conditions and, when detected, launches the portal browser331and populates the portal browser331with content that is not only appropriate to the user, but also displayed to the user at a time which is perceived to be beneficial or otherwise appropriate. This allows advertisers to be more confident that the content is being displayed to the right users at the right times and is not seen as a nuisance.

As noted above, the content which populates the portal browser331can be pre-fetched at periodic intervals or when a data communication link is available so that the advertising content302acan be displayed at any time, regardless of which application or program is the current application330. For example, as will be exemplified below, the use of the portal browser331is particularly suitable when the current application330is a phone application330a. However, in 2G and 2.5G wireless networks, the user is limited to either data service (GPRS in 2.5G) or voice service but not both at the same time. Thus, when using these types of networks, when the current application330is the phone application330a, the data service link is suspended for the duration of the call. The pre-fetched advertising content302aupdates the advertising content cache63whenever possible (i.e. when a data link is available and according to predefined intervals) and can populate the portal browser331as if the portal browser331had a data connection. Of course, it will be appreciated that in various networks that allow simultaneous voice and data communications (e.g. 3G or 4G networks such as EDGE, UMTS and HSDPA, LTE, Wi-MAX etc.—described above), the portal browser331can be configured to use any available data connection, e.g. if the phone application330ais being used, to fetch content in real time or to redirect users to websites in response to a “click-through”. Therefore, it can be appreciated that the portal browser331may comprise an interactive application that is intelligently launched at specific times and offers content to the user in various forms from various sources. Examples of the portal browser331and the nature of such content will be explained in greater detail below.

When the current application330does not require any significant or constant user interaction, the portal browser33la may be enlarged as shown inFIG. 14(b) to enable more content to be displayed and to allow the user more freedom in browsing. When the enlarged portal browser331atakes over the display12as shown inFIG. 14(b), a status bar332for the current application is inserted, e.g. at the bottom of the display12to ensure that the user is reminded that the current application330is running in the background.

An example showing a use of the portal browser331during use of the phone application330ais shown inFIG. 15(a). As noted above, it is sometimes the case where a user is participating in a conference call which does not require their full attention and does not require use of the entire display12. This creates an idle event for the display12, i.e. a portion or all of the display12is not being fully utilized and it is an appropriate time to launch the portal browser331. In other words, during a phone call, the minimal user interactions needed other than voice creates an opportune time to take over part of the screen12with the portal browser331.

The portal browser331can take over a portion of the display12as shown inFIG. 15(a) and may include various media content, including advertisements and the like. In this example, the portal browser331includes a content window333that can be considered the main browsing window and can be updated by selecting different items from a navigator334. The navigator334shows a list of pre-fetched advertising content302a, which can be selected by the user and consequently displayed in the content window333. Also shown inFIG. 15(a) is an advertisement337. The advertisement337is shown for illustrative purposes only and to exemplify a case where the content window333displays content that is not an advertisement itself but is provided by a certain advertising content provider329. An example would be latest news stories, weather updates, sports scores, etc. The content window333can also be used to show only an advertisement337either for a predetermined amount of time or where the advertisement337is deemed to be of interest to the user. An example would be top selling games, movie advertisements etc.

Also shown inFIG. 15(a) is a user queue335which can be optionally displayed within the portal browser331. The user queue335is a mechanism that allows a user to queue up tasks that require a connection to the wireless network200but where such a connection is unavailable while the user is browsing. Once the data connection is available, e.g. when the phone application330ais terminated, the user queue335can launch an appropriate application such as an Internet browser to direct the user to a web site etc. It may be noted that the user queue335can be used to queue up other tasks such as phone calls. For example, if the current application330is one that consumes the data connection and the user wishes to call a phone number included in the content window, this number can be queued up and called when the voice link is again available. It can be seen that more than one task may be queued in the user queue335.FIG. 15(b) illustrates an example according toFIG. 14(b) where a phone status bar332ais displayed upon resizing the portal browser331using one of the size control buttons336.

Although the portal browser331is shown inFIGS. 14 and 15and described above as being launched at specific idle events, e.g. when the phone application is running, it will be appreciated that the portal browser331can also be launched at the user's discretion, either during use of a current application330(e.g. by providing a menu option), by providing an icon42on the home screen40, or using any other mechanism. In this way, the user can go back to the pre-fetched advertising content302aat a later time to look at content again or to continue browsing at their leisure. As will be described below, since the advertising content302ais pre-fetched and updated on a periodic basis, the portal application60may include a legacy archive or log338of previous advertising content302a, e.g. by storing such archive or log in the advertising content cache63, so that the user can “go back” to content they may have seen on previous days and is no longer current in the portal browser's navigator334. The log338can also be used to track what content has been provided and what content the user has viewed or interacted with to allow the portal application60to intelligently update the navigator334so that the user is not faced with repetitive content or content that is irrelevant or outdated.

FIG. 16shows an example of a series of computer executable operations that can be performed by the portal application60to pre-fetch advertising content302a. It will be noted that the algorithm shown inFIG. 16is for illustrative purposes only and as will be explained below, certain ones of the operations may be executed in a different order or may be done in advance or in parallel. The example shown inFIG. 16is most suitable for the configuration shown inFIG. 13where the mobile device100hosts the portal advertising server298b. Turning now toFIG. 16, at576a pre-fetch routine is initiated, e.g. by the portal application60. In this example, the location estimator54is utilized to filter the advertising content327for relevance to the user. At578, the portal application60runs the location estimator54to generate location data300. The portal application60then accesses the location profile64and portal profile62at580, whereby the location profile64can be used by the location estimator54to generate the location data300. The portal profile62is then used with the location data300to filter the advertising content327at582.

In order to understand the filtering performed at584in this example, reference will now be made toFIG. 10, which includes an example user portal profile62. The user portal profile62allows the user to assist the portal application60in filtering the advertising content327so that the filtered advertising content302ais more relevant to that user. The user portal profile62can include any suitable information and can be constructed using any suitable data structure and populated using any suitable UI or input mechanism. InFIG. 10, it can be seen that demographic data320is maintained that includes data such as age and gender, and any other data that the user is willing to provide. The portal profile62also includes a linking option321, which allows the portal profile62to utilize the location profile64for location-based user data. If the user wants to specify different location-based options for the portal browser content, they may select a Custom button322and enter such data manually. The user portal profile62also includes a content log323which may be similar to the data stored in log338and indicates what the user has already viewed or would not likely be interested in. For example, advertisements for a particular game may be overlooked because the content log323indicates that the user has already obtained that game for their mobile device100. As such, the content log323can combine both user input and can gather, track and record usage data as desired. The portal profile62may also include user request data324that specifies certain content that the user wishes to see or any other requests or preferences that the user wishes to specify. The portal profile62may also include a mechanism for determining appropriate time periods for providing advertising content to a user, e.g. during a commute or waiting for a flight. It can be seen that the portal profile62provides a mechanism to enable the user to contribute to the content filtering process as well as the detection of idle events, which benefits the advertising content providers329since they can be more confident in the advertising content327that is provided.

Turning back toFIG. 16, the filtering at582thus takes the unfiltered advertising content327at584and uses the location data300(if provided), and the location and portal profiles64,62to choose the appropriate advertising content302a. Once the filtering at582is completed (or during the filtering), the archive or log338or content log323or both can be checked at586to determine if certain items in the filtered advertising content302aare duplicates or otherwise inappropriate or redundant. If necessary, such additional filtering is performed. The filtered data302acan be stored in the advertising content cache63as a bulk set at590or, as shown, can first be arranged in content queues at588that indicate which items will be displayed in the navigator334at the same time and in what order. This enables the portal application60to simply grab content in groups and does not require any intelligence at the time of launching the portal browser331. The advertising content302athus filtered, is then stored in the advertising content cache63at590for later retrieval.

As noted above, the method illustrated inFIG. 16would be different if performed in the configuration shown inFIG. 12. For example, running the location estimator54at578would be done ahead of time on the mobile device100or at least in part (seeFIGS. 4-6). Also, the advertising content process at584would likely be done in advance since a central portal advertising server298awould likely be more frequently in communication with the advertising content providers329and this would be done independent of a pre-fetch routine. Also, initiation of the pre-fetch at576in this configuration would require a connection to the host system250or router26at an appropriate time. It can however be seen that the principles in pre-fetching the advertising content302so that it is available to the portal application60at the appropriate times is consistent in any configuration that utilizes these components.

Turning now toFIG. 17, operation of the portal application60will now be exemplified. At592, an idle event such as use of the phone application330ais detected. If in a 3G, 4G or other system that enables both voice and data simultaneously, the pre-fetch routine shown inFIG. 16could be run in real time to obtain the most current advertising content302. Otherwise, the advertising content cache63is then accessed at594to obtain the content for the portal browser331. The portal browser331is then launched at596and populated at598. The following operations are then performed as necessary while the idle event subsists (e.g. duration of phone call). At600, the portal browser331detects a user interaction that requires any one or more of the content window333, navigator334and user queue335to be updated. For example, the portal browser331may detect, through sensing a selection operation initiated by the user, that a new item in the navigator334has been selected. If so, at602, the portal browser331loads the corresponding content (that would be stored in a specific location in the advertising content cache63) into the content window333. If the user interaction at600or subsequent to updating at602is deemed to require a data connection (or voice connection) that is currently not available at604, a task is added to the user queue335at606. It may be noted that the user queue335does not necessarily need to always be displayed and may instead only pop-up as shown inFIG. 15when the queue is updated and when the queue is to be implemented.

If the update at602does not require an unavailable connection, or following the addition of a task to the user queue335at606, the portal application60then determines at608if the idle event is done or has been terminated. This operation is used to ensure that the portal application60does not launch or keep the portal browser331running on the display12at inappropriate or undesired times. For example, after the phone call ends, the user may then open their message application138which requires many user interactions and inputs and a data connection. It may, at this time be inappropriate for the portal browser331to be consuming screen space and thus the portal session would end at610. If however the idle event is still ongoing at this time, the portal browser331would remain open and wait until another user interaction is detected at600. It will be appreciated that transitional operations may be utilized to indicate what is done when the idle event ends and the portal browser331is still in the process of updating or being used. In this case, the portal application60may remain on the display, e.g. along with the home screen40or a next application only until the operation is complete. Such transitional operations can be default steps taken by the portal application60or can be part of the user portal profile62so that the user can, e.g. tell the portal application60to keep the portal browser331on the display until they actively close it.

It can therefore be seen that the portal application60can be used on the mobile device100, either at predetermined or event driven times or by user initiation, to display relevant advertising content302to the user at convenient times. In this way, the advertising content providers329can be more confident that the advertising space they are purchasing is being directed to the appropriate users and the user can be confident that they will not be overwhelmed with advertising content at inappropriate times with inappropriate content. The portal application60can utilize a portal browser331that is launched when appropriate, which displays the advertising content302in an interactive way and enables the user to follow up by keeping track of the user queue335. The advertising content302may be filtered from the base of advertising content327provided by the advertising content providers329in advance and is pre-fetched and stored in the advertising content cache63for convenient access when appropriate. Screen control of the portal browser331also allows the user to get more out of their browsing experience during the idle event, such as for the duration of a phone call that requires minimal if any user interactions other than voice. The portal application60can be used with the location estimator54to narrow and categorize the advertising content302at least in part based on location, either physical location or preferred location or both. The location estimator54can therefore improve the filtering of the advertising content327and the portal application60illustrates one example of an application making use of an LBS298. The different configurations described herein are for illustrative purposes only and it will be appreciated that variations of these configurations can be made while utilizing the principles discussed herein.

It will also be appreciated that the particular options, outcomes, applications, screen shots and icons shown in the figures and described above are for illustrative purposes only and many other variations can be used according to the principles described.

Although the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art as outlined in the appended claims.