WO2005059676A2

WO2005059676A2 - A method and system for personalized request/subscription based advertising and content services

Info

Publication number: WO2005059676A2
Application number: PCT/IN2004/000388
Authority: WO
Inventors: Sunil Goyal
Original assignee: Sunil Goyal
Priority date: 2003-12-16
Filing date: 2004-12-13
Publication date: 2005-06-30
Also published as: WO2005059676A3

Abstract

The invention relates to a method and system of receiving personalized request/subscription based advertising and content services on mobile communication devices (102), wherein advertisement information and/or content information is aggregated at remote servers (114) from various providers and wherein a user (100) can configure the information to be received and wherein the requested information is either immediately sent to the mobile communication device (102) of the user (100) or at a desired time and/or at predetermined time intervals. The user (100) has also the option to configure how to view/listen to the received information which may comprise text and/or audio and/or visual advertisement information and to set appropriate alert levels for different types of information requested/subscribed by the user (100). The received information may e.g. be displayed on the idle screen of the mobile communication device (102). There is also a push-type information transmission methodology for sending contextual advertisements disclosed wherein said contextual advertisements are selected based on the user request/subscription and the user request history data which is gathered in the user history database (234).

Description

A METHOD AND SYSTEM FOR PERSONALIZED REQUEST/SUBSCRIPTION BASED ADVERTISING AND CONTENT SERVICES

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefits of provisional patent application "A method and apparatus for personalized and unobtrusive request/subscription based advertising" Appl. No. 60/530,305 filed Dec 16, 2003 in the United States of America. The above-mentioned provisional patent application is incorporated herein by reference.

FIELD OF THE INVENTION

This invention relates to a schema for providing request/subscription-based content and advertising services on mobile devices, wherein a user has substantial control over information he/she receives on his/her device.

BACKGROUND OF THE INVENTION

The use of mobile communication devices like mobile phones and PDAs (personal digital assistants) has been growing exponentially. Almost 50% of the US population today owns a mobile phone. Since these devices are personal and stay with the user most of the time, they provide a great medium for advertisers to reach out to their target customers.

Today, advertisers and content providers have increasingly targeted mobile phone users by sending advertisements and content through SMS (short messaging service) or MMS (multimedia messaging service) messages. Advertising by means of SMS or MMS without the mobile phone user's consent is often termed as "spamming" and is a cause of concern for mobile phone users, especially since these generate alerts on mobile phones. For example, sending an SMS advertisement while a person is in a board meeting is intrusive and can be disturbing to the user. Excessive advertising by SMS or MMS resulting in bombardment of the user's mobile phone with messages can result in further disturbance for its user, since he/she cannot control the time and number of such messages received. Similarly, even the subscription to useful content such as stocks, news, etc. is highly limited, for instance, a news service might produce alert every few minutes which would be highly distracting to the user.

Content and advertising on mobile communication devices is also done via WAP (wireless access protocol) enabled websites, which allow a user to view content (HTML, WML, cHTML, XHTML or other related formats) on his/her mobile communication device. However, unlike SMS where information travels to the user, with WAP a user has to go and search for information just like on a PC or laptop, however, mobile devices do not provide as rich an experience. Content pages viewed on mobile devices often contain advertisements too. Viewing content with advertisements on the small screens of these devices poses a significant problem, especially when the advertisements are not in context with what user wants, resulting in bad user experience.

As such, there is a need for a methodology that gives a user control over what information he/she receives, when he/she receives it and how he/she receives it. A user should be able to receive personalized content services along with contextual advertising of relevance in a user-friendly manner.

SUMMARY OF THE INVENTION

The present invention provides a request/subscription based system of advertising and content services where a user is in substantial control over the Information that he/she receives. The embodiments of invention further ensure that the availability of advertisements and content is in an unobtrusive and user-friendly manner where a user is further able to specify when and how he/she wants to receive the desired Information.

First embodiment of the present invention is a method and system of subscribing to a special class of advertisement that a user can specifically request for. This class of advertisement is referred as Ad-data in the subsequent discussion. Ad-data from one or more sources is aggregated and stored at one or multiple server(s). A user sends his/her request for an Ad- data from a communication device. The user's request is matched with the aggregated Ad- data and the relevant Ad-data so found is sent to the desired receiving device at one or multiple times as specified by the user in his/her request. The steps of aggregation, receiving user's request, matching user's request with aggregated Ad-data and sending selected Ad- data can be performed on same or different servers.

Second embodiment of the present invention is a method and system of subscribing to Information (Content and/or Ad-data) on a mobile communication device (e.g. mobile phones) and displaying the Information received either immediately or upon user access via an application or on the screen when the device turns idle. Information is aggregated from one or more sources and is stored at the server(s). A user sends request for the Information from the mobile communication device to remote server(s). Next a computer program finds the relevant Information for the user from the stored aggregated Information. The relevant Information is then sent to the mobile device and is either displayed immediately on the screen or stored in the local memory. The user can then either access this stored Information at his/her convenience or a program on the mobile device picks up the Information stored in the local memory and displays it on the screen when the device turns into idle state (e.g. screen saver is turned on). The steps of aggregation, receiving user's request, matching user's request with aggregated Information and sending selected Information can be performed on same or different servers.

Third embodiment of the present invention is a method and system to track user's request and find related advertisements (termed as Contextual Advertisement in the subsequent discussion) not specifically requested by the user but related to the requests made. For e.g. if a user requests for stock quotes then a Contextual Advertisement could be a promotion for Charles Schwab or if a user requests for a laptop computer then the Contextual Advertisement could be some offer from an electronics store such as Best Buy or CompUSA. This Contextual Advertisement is then delivered to the user's mobile communication device. The user can then either access this Contextual Advertisement at his/her convenience or a program on the device picks up the Contextual Advertisement stored in the local memory, may couple it with the Information and displays it on the screen when the device turns into idle state. Contextual Advertisements are also coupled with the Content on the web page when the user is browsing Internet on the device.

Fourth embodiment of the invention provides a new channel (referred to as Mmodule later in the document) for content delivery and advertising on the mobile communication device, which addresses the limitations of existing channels like SMS, MMS and WAP. This channel can be configured to receive Information as per user preferences. For example, a user can configure to receive BBC news in a non-intrusive fashion, unlike SMS or MMS, and will thus receive the requested Information without any form of alert (audio or visual or vibration alert). The user will then be able to look at the Information so received freely at his/her leisure. He/She will be able to get Information and advertisements based on his/her interest/preferences and will also be able to execute operations like delete, forward etc. on the received Information and/or Contextual Advertisement. This new channel will not cause the user to interrupt his other tasks, as he has to do today to view an SMS or MMS message. The user will be able to configure the time, the frequency and the kind of Content and Ad-data he/she wants to view on his mobile communication device through this new channel.

The invention allows users to specify their interests, or get additional personalization parameters or categories of Ad-data and/or Content from the server, so that a user can receive a rich personalized experience. Detailed features and advantages of the invention as well as the structure and operation of the invention are described below with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of one illustration of the invention showing of the entire advertising and content delivery infrastructure, the client device, the server device and the network that connects them.

FIG. 2 describes one illustration of the server device.

FIG. 3 describes one illustration of the client device.

FIG. 4 describes an illustration of Mmodule that is responsible for creating the new channel of advertising and content delivery on the client device. FIG. 5 shows sample sets of Ad and Content parameters based on which the client device can query for Ad-data or Content.

FIG. 6 shows some sample screenshots of how to enter the Ad parameters or Content parameters through a user interface component on client device.

FIG. 7 shows a sample set of operations that a user can perform on the Ad-data or Content or Contextual Advertisements it receives from the server device(s).

Fig. 8 describes a few sample illustrative formats using which a user 100 can request for Ad- data using SMS requests via the client device.

FIG. 9 is a flow chart showing one illustrative implementation of how the server device 114 processes Ad requests. FIG. 10 is a flow chart describing one illustrative implementation of how the server device(s) tracks as users access Ad-data or Content or Contextual Advertisements.

FIG. 11 is a flow chart describing one illustrative implementation of the Request scheduler in the server device that keeps track of when to send Ad-data and/or Content to users that have subscribed to receive it at a particular frequency. FIG. 12 is a flow chart describing one illustrative implementation of ModuleA of Mmodule on the client device.

FIG. 13 is a flow chart describing one illustrative implementation of ModuleB of Mmodule on the client device.

FIG. 14 is a flow chart describing one illustrative implementation of ModuleC of Mmodule on the client device. FIG. 15 is a flow chart describing one illustrative implementation of ModuleD of Mmodule on the client device when a user tries to access Ad-data or Content or Contextual Advertisements.

FIG. 16 is a flow chart describing one illustrative implementation of ModuleE of Mmodule on the client device.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention are directed to a method and system of providing advertising and content services where a user can request for them, control when to receive them and control how to receive them. A user is empowered with the capability to not only request for advertisements/Content but also subscribe to a category of advertisements/Content of user interest. Along with gaining access to the necessary advertisements and Content, a user will also be able to place ads, e.g., classifieds ads that will reach out to the interested audience. The invention also proposes an unobtrusive way of receiving advertisements and a methodology for coupling Content with advertisement data. We clarify a few terminologies used throughout the document.

Product: The term product is used in this document to signify without any loss of generality at least one of the following: a good, a service, an experience, a place, an idea, people or an organization.

Communication Device: Any electronic device that is capable of sending and receiving data, for example, computers, laptops, mobile phones, PDA (Personal Digital Assistants), telephones, watches (capable of send and receiving signals), TV set top box etc.

Mobile Communication Device: Any portable electronic device capable of sending and receiving data, for example, mobile phones, PDAs (Personal Digital Assistants), watches (capable of sending and receiving signals), cordless telephones, etc.

Ad-data: This refers to any form of advertisement of a Product that a user might specifically request for. This may be classifieds, discounts, special offers, deals, coupons etc. in the form of text, pictures (e.g., jpeg format, png format etc.), audio (e.g., wav format, mp3 format etc.), video (e.g., mpg format etc.) or other document formats like WML, HTML, SMIL etc. using which a company would get its message across to its audience who are specifically interested in their advertisements. For example, if a user wants to receive coupons about a particular Product, those coupons are a form of Ad-data. If a user wants to know about the various shoe categories of a particular brand that have an advertisement / coupon associated with them, the list of all such shoe categories is also a form of Ad-data. Classifieds is another common example of Ad-data.

Ad parameters: This refers to a set of parameters that a user can specify to describe the kind of Ad-data that the user is looking for. This will include parameters like brand name of the Product, category of Product etc. for which a user wants advertisements. The Ad parameters can also include the brand name or Product code or other parameters that help user to request for advertisements. FIG. 5 shows a sample set of Ad parameters. For example, if a user is looking for advertisements or deals on shoes, then he/she can set the parameter "category of Product" to the value "shoes" to receive the required Ad-data. Another example is in a classified of a car, the user can specify Ad parameters as "Model", "Year" etc.

Ad request: This is a request that a user will send to request for Ad-data from his/her device that he/she needs. This would typically be a list of Ad parameters with specific values that describe the Ad-data that the user is looking for. For example, if a user wants to get advertisements regarding Products at retail store "Wal-Mart", then the user can set the Ad parameter "retail store" with value "Wal-Mart" and send this Ad request.

Content: This refers to a non-advertisement data that might be of use to an individual such as news, sports, financial information, multiplayer games, travel, event, personal reminder, reviews, blogs, discussion groups, translator, dictionary, weather, traffic, music, ring-tones etc. This would be in the form of text, pictures (e.g., jpeg format, png format etc.), audio (e.g., wav format, mp3 format etc.), video (e.g., mpg format etc.) or other document formats like WML, HTML, SMIL etc.

Information: This refers to any form of data that can be requested or subscribed by the user.

Specifically, this is either Content or Ad-data that a user would be specifically interested in. Information is interchangeably used in this document where both Content and Ad-data are relevant.

Contextual Advertisement: This refers to a form of advertisement that is not specifically requested by the user but is based on the request profile of the user. The request profile is generated by (i) Tracking the http, https or wap request made by said user via a browser interface on the mobile device and/or (ii) Tracking the user's current requests for Ad-data and/or Content (iii) Tracking the user's previous requests for Ad-data and/or Content (iv) Tracking the history of interaction of the user with the Content or Ad-data, Contextual Advertisements etc. For example, a user requests for "Wimbledon score" then the Contextual Advertisement could be of a retail store selling tennis equipments or a tennis equipment manufacturer. This would be in the form of text, pictures (e.g., jpeg format, png format etc.), audio (e.g., wav fomiat, mp3 format etc.), video (e.g., mpg format, avi format etc.) or other document foraiats like WML, HTML, SMIL etc.

Note that this document uses three distinct terms Content, Ad-data and Contextual Advertisements. Content and Ad-data (also collectively known as Information) are specifically requested by the user, on the other hand the Contextual Advertisements are not specifically requested by the user but are provided to the user on the basis of their request profile.

Also note that the term "Content parameters" is analogous to the term "Ad parameters" and "Content request" to the tenn "Ad request" wherein the former are used when discussing Content and the latter for Ad-data.

The term "Ad/Content" used in this document should be interpreted as Ad and/or Content without loss of generality. Thus, the term Ad/Content request would mean a request for either Ad-data or Content or both. FIG. 1 depicts a schematic representation of one illustrative system of the present invention. As shown in the figure, client devices 102, which in this case are wireless communication devices, are connected to each other using wireless network 104. This wireless network 104 is in turn connected to gateway 106 that connects wireless network 104 to the Internet 110. Another gateway 108 connects wireless network 104 to the public switched telephone network (PSTN) 112. Also the PSTN 112 is connected to the Internet 110 via gateway 116. FIG. 1 also shows server devices 114 where all the Ad-data and Content is aggregated. The server device also stores the advertisements database 252, which is used to generate Contextual Advertisements on a per user basis.

Note that users 100 as shown in FIG. 1 use client devices 102 to request for Ad-data or Content. In this illustration, client devices 102 are wireless communication devices that are mobile and capable of sending and receiving data. These devices 102 would typically be personal to a user 100 and would be with the user 100 most of the time. These devices 102 will generally be accessible anywhere e.g. in a pocket, bag or vehicle and can be easily carried by the user 100. These devices 102 may be a handheld computer (PalmPilot), a personal digital assistant (PDA), a cellular phone, 2-way pager etc. A user 100 will use the client device 102 to request Ad-data or Content from pre-determined server device(s) 114.

FIG. 2 and FIG. 3 give one illustration of the server device 114 and the client device 102, respectively. The server device 114 supports at least one of the 4 protocols (212, 214, 216 and 218) via which it can receive an Ad/Content request from the client device 102. It also supports method 211 so that it can indirectly receive Ad/Content requests from user 100 through phone calls 222.

Mmodule 302 as shown in FIG. 3, is a software program running on the client device 102 that makes an Ad/Content request 212 to the server device 114 requesting for Ad- data/Content. Mmodule 302 provides the new channel for advertising and information services on the wireless devices (Summary of the Invention, page 4, line 6). The Mmodule request handler 202 on the server device 114 handles the Ad/Content request 212.

The server device 114 may receive an Ad/Content request via SMS 214 sent by a user 100 using client device 102. The SMS request handler 204 processes such a request 214. The server device 114 may also receive an Ad/Content request via MMS 216 sent by a user 100. The MMS request handler 206 processes such a request 216. For example, a person 100 will be passing by a store on his way home and wants to immediately know about any deals available on that store; he could simply send an SMS Ad request 214 to the server device 114, requesting for such advertisements.

A browser module 308 as shown in FIG. 3 capable of browsing web pages on the client device 102 may also send an Ad/Content request 218 to the server device 114 when the user 100 is browsing any Content (HTML, WML, cHTML, XHTML or other formats) on the client device 102. The browser module 308 can be any browser, for example WAP Browser, I-Mode browser, HTML browser etc. that is capable of viewing Content (HTML, WML, cHTML, XHTML etc.) on the client device 102.

The client device 102 makes a request 218 using browser module 308 to the server device 114 requesting for Ad-data or Content that it can use to fill up space for advertisements on a web page. Since the server device 114 is aware of user 100 preferences, it will fill up the web page with Ad-data requested by the user 100. The handler of browser requests 208 on the server device 114 processes the request 218.

The server device 114 may also receive an Ad/Content request via a phone call 222 made by user 100 using the client device 102 to request Ad-data or Content. Operators or an automatic voice gateway 220 will answer these phone calls 222 and subsequently make an Ad/Content request 211 to the server device 114 on behalf of user 100. The handler of Ad/Content requests from operators 210, on the server device 114, processes such requests 222. For example, a user 100 want to know about deals available in a restaurant; he could simply call a pre-specified number and request 222 for such Ad-data. The above Ad/Content requests handlers 202, 204, 206, 208 and 210 after receiving requests 212, 214, 216, 218 and 211 respectively send the Ad/Content request (212, 214, 216, 218, 211) to the Request-processing engine 236 in a pre-defined format. This engine 236 computes the relevant Ad-data or Content depending on what the user requested from the Ad/Content database 232 based on the Ad/Content parameters in the Ad/Content request and user preferences in the user history database 234. Note that the http (or https or wap) request made by the user 100 from the browser module 308 are also stored in the user history database 234. The Aggregating engine 231 receives Ad-data and Content 223 from various sources of Ad-data and Content providers and stores it periodically in the Ad/Content database 232. This ensures the supply of new Ad-data/Content to the Ad/Content database 232. The Request-processing engine 236 also stores this request (212, 214, 216, 218, 211) in the user history database 234 for the user 100. This way it 114 keeps track of Ad-data and Content sent to various users 100. Note that tracking of requests made by the user can be done either at the client device 102 or the server device 114. In this illustration, we illustrate the case where the tracking of user requests is made at the server device 114 via the user history database 234.

Depending on the user's Ad/Content request, the Request-processing engine 236 may send the desired Ad-data or Content to the user's client device 102 either via Mmodule 238, via SMS 240, via MMS 242, via a simple phone call 246 using an operator/automatic voice gateway 220 that can tell the user 100 about the Ad-data/Content or via the browser module 244.

Apart from an immediate request response for an Ad-data or Content request, a user 100 may also send a subscription based Ad/Content request to the server device 114, for example, it may request for Ad-data pertaining to a specific Product once every day. In such a case the Request-processing engine 236 will validate the subscription based Ad/Content request and send it 238 to Mmodule 302 of the client device 102 so that it can keep track or alternatively store in its request scheduler database 248 in which case it will keep track of the request on its own.

Mmodule 302 on receiving such a subscription based Ad/Content request 238, will store it and send the corresponding Ad/Content request to the server device 114 based on the frequency set by the user 100. In the previous example, Mmodule 302 will receive the validated Ad request 238 and send a request once every day in response to which the server device 114 will send Ad-data.

The server device 114 is also capable of storing this subscription based Ad/Content request in its request scheduler 250. The request scheduler 250 will then continuously keep track of the these requests and would send the corresponding requests at the indicated times to the request processing engine 236 which in turn would send the corresponding Ad-data or Content to the user's client device via any of 238, 240, 244, 246 or 220 based on user request and the availability of information.

Note that a user through his/her client device 102 is also capable of placing Ad-data, for example, classified advertisements for renting a house which will be accessible on other client devices 102. The user 102 would place the Ad-data via 212, 214, 216, 218 or 222; that would send the Ad-data to the server device 114. The Request-processing engine 236 would check the validity of the Ad-data and then store it in its Ad/Content database 232 allowing other interested users to access or request the Ad-data or send them the Ad-data if they have subscribed.

The server device 114 is also capable of processing tracking requests 224 that are sent by Mmodule 302 installed on client devices 102. Mmodule 302 keeps track of Ad-data, Content and Contextual Advertisements as the user 100 accesses it and then sends a tracking request 224 to the server device 114 that is processed by the handler of tracking requests 226. It forwards the tracking request to the tracking request processing engine 230. This engine is responsible for storing the tracking request in the user tracking database 228. This way the server device 114 is able to keep track of Ad-data, Content and Contextual Advertisements as the user 100 accesses it. This information can be used for billing as users 100 access their Ad-data, Content or Contextual Advertisements or figuring out user preferences, computing Contextual Advertisements etc. Note that this tracking capability is activated only upon user 100 consent so that user privacy is not hampered.

In this illustration the server device 114 also sends Context Advertisements along with the information to be sent to the user in response to the user's Ad/Content request. The Contextual Advertisement processing engine 254 generates a user request profile by collecting user information from user history database 234 (that also includes the requests made by the user 100 via the browser module 308 on the client device) and the user-tracking database 228. The Contextual Advertisement processing engine 254 then finds an advertisement from the advertisement database 252 on the basis of the user request profile so generated. This Contextual Advertisement is then sent (256) to Mmodule 302 on the client device. It may also be sent (258) to the Browser module 308 on the client device to fill up the advertisement space.

FIG. 3 describes the client device 102. For the client device 102 to be used as a gadget to access Ad-data or Content it must support at least any one of the 5 constituent modules: the Mmodule 302, the SMS module 304, the MMS module 306, the browser module 308 or the phone call module 310. The following paragraphs describe each of these 5 modules (302, 304, 306, 308 and 310) in more detail.

A user 100 of the client device 102 can use the phone call module 310 to place Ad/Content requests and receive Ad-data/Content. The user 100 may place a call 222 to a pre-specified phone number requesting for Ad-data Content, which results in a request 222 being received by the operator 220. For example, a user standing inside the retail store sees a Product of his/her interest inside a store, but would like to wait until the Product is on sale; he/she will be able to make an Ad request via a phone call and even subscribe for the deals on that particular Product or a related Product. The user will receive the Ad-data whenever the Product is on sale. The user 100 may request to receive this Ad-data on the client device 102 via a phone call 246, via Mmodule 238, via SMS 240 or via MMS 242.

A user 100 of the client device 102 can have the browser module 308, which helps a user 100 to browse Content such as web pages (for example WML, cHTML, HTML, XHTML pages or any other wireless Content format). The user 100 may send an Ad/Content request 218 via browser module 308 to the server device 114 requesting for Ad-data/Content. The Ad-data so requested may be placed on the web page to fill up the available advertisement space on the web page. Since the server device 114 is aware of user preferences of the user 100 it would send Ad-data 244 to fill up the space with Ad-data that would be most relevant to the user 100. The Contextual Advertisement processing engine 254 can also send Contextual Advertisement 258 for web content which would be placed on the web page in a similar fashion to fill up the advertising space on the web page

The SMS Module 304 and MMS Module 306 in the client device 102 are capable of sending and receiving SMS and MMS messages respectively. The user 100 may send an SMS request 214 or MMS request 216 using the SMS Module 304 or MMS Module 306 respectively to a pre-specified number requesting for Ad-data/ Content. The user 100 may receive the Ad-data or Content via Mmodule 238, SMS 240 or MMS 242 from the server device 114 for the Ad/Content request sent by the client device 102 via 214 and 216.

Mmodule 302 is software running on the client device 102 that is capable of sending Ad/Content requests 212 and receiving Ad-data or Content 238 just like other modules (304, 306, 308). The Mmodule 302 is software downloadable on the client device 102 or comes preinstalled on the client device 102. This module 302 enables users 100 to place Ad/Content requests which request a particular category of Ad-data or Content at a certain frequency, for example, a user 100 might request to receive one advertisement daily informing him/her about deals on his/her favorite store.

This Mmodule 302 also enables users 100 to access Ad-data or Content in an unobtrusive manner unlike SMS or MMS that are alerts via user interface 314. For each Ad/Content request made by the user, he/she will be able to specify whether he wants the Ad-data or Content received to be an alert or not. For example, if a user is looking for a camera, as soon as such an offer is available he would receive the Ad-data on his mobile device via Mmodule 302 and the user can browse tlirough the Ad-data received at his/her. leisure. The mobile device may or may not alert the user when such Ad-data is received, depending on the user Ad request. Moreover the user will have an option to set the alert levels as visual alerts where the Ad-data or Content is displayed on the screen but it does not beep the user's phone or audio visual alerts where as the Ad-data or Content arrives on the phone it generates an alert and displays the Ad-data or Content on the screen.

A user will also be given the option of making Mmodule 302 the idle screen of his/her mobile device and this Ad-data or Content or Contextual Advertisements or any combination of these would start showing up on the screen as soon as the client device 102 turns idle and would disappear as soon as the user 100 starts using the device. For example, Ad-data would show up on the mobile device display just after the user 100 finished reading an SMS or right after ending a phone call. Note that the idle state of the client device 102 is defined as the state when the user may not need the visual function of the device for any other application, for example, when a user is making a call then he may not use the screen of the phone and hence that would be an idle state. Also start of the wireless device, during an entire voice call, termination of a voice call, receiving a message (text/ picture/audio), finished reading the message, activation of a screen saver, etc. are the other examples of idle state of the client device 102.

Ad-data or Content accessed by the user 100 via Mmodule 302 will not alert the user unless the user wants to be alerted. Therefore, a user will not be interrupted from his other tasks due to unimportant Ad-data or some Content such as news which may have the frequency of once every few minutes. Mmodule 302 also tracks as the user 100 accesses Ad- data/Content/Contextual Advertisement and sends tracking requests 224 to the server device 114 informing the server device 114 about user accesses for the Ad-data. Note that a user through his/her client device 102 is also capable of placing Ad-data, for example, classified advertisements for home rents that will be accessible on other client devices 102. The user 102 would place the Ad-data via 212, 214, 216, 218 or 222; that would send the Ad-data to the server device 114. The server device upon validation will allow other interested users to access or request the Ad-data or send them the Ad-data if they have subscribed to receive such Ad-data.

FIG. 4 describes an illustration of Mmodule 302. Mmodule 302 in this illustration is broadly divided into 5 sub-modules ModuleA 402, ModuleB 404, ModuleC 408, ModuleD 406 and ModuleE 424. Mmodule 302 would also consist of 2 persistent data storage repositories called the Ad/Content request repository 412 and the Ad/Content/Contextual Advertisement repository 410.

ModuleA 402 provides the user interface for the user to place Ad-data or make an Ad/Content request. The user 100 will be able to place Ad-data 414 via this module 402. This module 402 will then send the Ad-data 420 to the server device 114. The Ad placed by the user 100 will be accessible via other client devices 102 owned by other users 100 interested in the Ad-data upon request or subscription from the server device 114.

Similarly, for an Ad/Content request 414 made by user 100, ModuleA 402 will send it 420 to the server device 114 where it will get validated. If the user 100 had immediately requested to receive Ad-data or Content, via SMS or MMS, it will be delivered to the user 100, via the client device 102 either via SMS, MMS or ModuleC 408, immediately upon validation of the Ad/Content request. However, if the user 100 had requested to receive Ad-data or Content at a paiticular frequency, say 2 times daily, then the server device 114 might simply store the request in the request scheduler database 248 or send the Ad/Content parameters of the Ad/Content request back to the client device 102 upon validation where ModuleA 402 would store these in its Ad/Content request repository 412. In the former case the server device 114 keeps track of the request and sends information to the client device periodically. In the latter case, the client device keeps track and send the request for information periodically. ModuleB 404 is responsible for continuously polling the Ad/Content request repository 412 and figuring out if it is time to request the server device 114 for Ad-data or Content. If yes, then it would send an Ad/Content request 422 to the server device 114 after collecting the Ad/Content parameters from the Ad/Content request repository 412. The server device 114 in turn would deliver the Ad-data or Content to the user's client device 102 via SMS 240, MMS 242 or ModuleC 408.

ModuleC 408 is responsible for receiving all Ad-data or Content 418 and Contextual Advertisements 256 from the server device 114 and storing it in the Ad/Content/Contextual Advertisement repository 410. This module 408 is also responsible for clearing up any old Ad-data or Content or Contextual Advertisements in the Ad/Content/Contextual Advertisement repository 410 as it fills it up with new Ad-data Content/Contextual Advertisement. It will also alert the user 100 if the user 100 had requested it to do so.

ModuleD 406 provides a user interface to access all the Ad-data/Content that the user had requested for or subscribed to and also to the Contextual Advertisements stored in the Ad/Content/Contextual Advertisement repository 410. ModuleD is responsible for fetching Ad-data/Content/Contextual Advertisement from the Ad/Content/Contextual Advertisement repository 410 and allowing the user 100 to access the Ad-data/Content/Contextual Advertisements via output interface 432. The user will be able to browse through the received Ad-data Content/Contextual Advertisement and will be able to execute operations like delete, forward etc. If the Ad-data or Content or Contextual Advertisement is of particular interest, user will also be able to get further details of the same.

ModuleD 406 also tracks as the user 100 accesses Ad-data or Content or Contextual Advertisement and sends tracking requests 434 to the server device 114 infonning the server device 114 about user 100 accesses. Keeping track of user accesses can provide a billing model by which advertisers can be charged and users 100 be given better services and remuneration. Also this would help in forming the user request profile, which is user by the Contextual Advertisement processing engine 254 to find relevant Contextual Advertisement from the advertisement database 252. Tracking request 434 will be sent to the server device 114 only if the user 100 has opted in for that.

A user 100 will also be given the option of making Mmodule 302 the default idle screen of his/her mobile device, which becomes activated as soon as the device turns idle. For example, Ad-data would show up on the mobile device display just after the user 100 finished reading an SMS or right after ending a phone call. ModuleE 424 caters to this requirement. This module will be triggered as soon as the user's mobile device becomes idle. It will fetch Ad-data or Content or Contextual Advertisement or any combination of these from the Ad/Content/Contextual Advertisement repository 410 and display that to the user (426) in a pre-determined order. As it displays Ad-data/Content/Contextual Advertisement in the repository 410 a predetermined number of times, it will send Ad/Content request 428 to the server device 114 to fetch more Ad-data/Content/Contextual Advertisements. The ModuleC will then receive this Ad-data or Content 418 and/or Contextual Advertisements 256 from the server device and store it in the Ad/Content/Contextual Advertisement repository 410. ModuleE 424 will then output (display/play) this Ad-data/Content/Contextual Advertisement in any combination on the user's mobile device. Note that ModuleE 424 is also capable of sending tracking requests 430 to the server device 114. ModuleE will display information and contextual advertisements on a pre-determined fraction of the screen and will also have the auto-scrolling capability. The module will abort itself as soon as the client device 102 is starting to be used by its user 100.

FIG. 5 shows sample sets of Ad and Content parameters based on which the client device 102 can request for Ad-data (501a) or Content (502a). These service parameters (501a) or (502a) will determine the kind of Ad-data or Content respectively a user 100 wants to receive on his client device 102. A user 100 can set the above parameters (501 a) or (502a) and send an Ad or Content request by using any of the 5 modules 302, 304, 306, 308 and 310 shown in FIG. 3. Note that the parameters (501a) and (502b) listed in FIG. 5 just provide an example and can include more parameters relevant for Ad-data or Content requests. Given the set of parameters as stated in FIG 5., a user 100 can set the time and frequency for the Ad-data and Content; a user 100 can also set a particular category or a particular brand (in case of Ad- data) he is interested in. In the sample in FIG.5 (501a and 501b) the user 100 has requested to receive Ad-data i.e. Ads, coupons or deals (in this case) on Reebok shoes and T-shirts in particular the model "Road Lite" from the SportMart store located in Sunnyvale, CA, 94089 from Jul 10 to Jul 18 2003. He/she can request these advertisements to be delivered via SMS, MMS, Web browser or Mmodule 302 and can opt to receive 2 such advertisements daily. A user 100 needs to specify at least one or more parameters in column 501a for requesting advertisements in which he is interested. The values specified in column 501b correspond to values for parameters in column 501a. The possible values specified in column 501b are the values which a user can input on his mobile device or can select from a user interface on his mobile device to subscribe or request Ad-data. In FIG.5 (502a and 502b) the user 100 has requested to receive the City Events in Sunnyvale, CA 94089 from a website Craigslist.com The user 100 has also specified that he/she is interested in only Dance, Jazz and Garage Sales. The user has not chosen to subscribe for this Content but it's a one-time request as indicated by the time of delivery of "Now". Also note that the user can configure the Alert levels of the Content that he has requested.

The Ad parameter values could be as simple as a Product code. For example, a user sees a "Canon S400" camera inside a "Best Buy" store but would like to wait until the Product is on sale; he/she will be able to send an SMS having the Product code, for example "BB canon s400", and will be notified whenever the store offers a discount on that Product.

FIG. 6 shows some sample screenshots (601,602,603 and 604) of ModuleA (FIG. 4, 402), where a user 100 will key in his/her Ad request. A user 100 can make Ad parameters (FIG. 5) take default values and fill in only the few Ad parameters (FIG. 5) that are of most concern to him/her. For example, ModuleA 402 in FIG. 4 would first make the user 100 select the Ad parameters such as brand name (601), then the time (602) and then the zip code (603) as shown in Fig 6. The rest of the Ad parameters (FIG. 5) take default values or no values. The screenshots (601, 602, 603, 604) can be in any number or any order and can be combined to take input for Ad parameters (FIG. 5) within even a single screenshot. Figure 6 only provides an illustration for a user interface component. Depending on type of Ad request, an interface will be built by the ModuleA 402, using which a user can input the necessary Ad parameters. Note that an analogous procedure would be valid for enabling the user 100 to key in his/her Content request.

FIG. 7 describes the level of customization that a user 100 can do to enhance his/her experience after the user 100 receives Ad-data or Content or Contextual Advertisements from the server device 114. The column 701a of FIG 7 describes some of the parameters. The user 100 can set a number of viewing options, e.g., priority of the Contextual Advertisements, a user 100 might prefer healthcare advertisements over clothing advertisements. Mmodule 302 would then accordingly show the user 100 more of healthcare advertisements as compared to clothing advertisements. A user 100 can also set the maximum number of times he would want to see an advertisement. Also, Mmodule 302 would offer the user 100 the capability to forward Ad-data or Content or Advertisement, just like SMS or MMS to his friends. A user 100 will also be given the capability to delete Ad-data/Content/ Advertisements upon viewing. The user 100 will also be able to set a maximum number of Ad- data Content/Contextual Advertisements the user 100 wants to store on the client device 102. This and many other customization options can be made available to the user 100 via Mmodule 302 on the client device 102.

FIG. 8 describes a few illustrative formats using which a user 100 can request for Ad-data using SMS requests from client device 102. The column 801a describes some of the possible SMS request formats and column 801b describes the possible results when the server device 114 receives these Ad requests from the client device 102. For example, if a user sends SMS

Store=Walmart time^Jun - Jul] N=5

to a pre-specified number it finally reaches the server device 114. The server device 114 will subscribe the user 100 for client device 102 for Ad-data such as deals on Products on sale at Walmart. The user 100 will receive 5 Ad-data daily from the server device 114 between months June and July of the current year. FIG. 8 describes some of the possible SMS formats, in which requests can be made to the server device 114 from the client device 102 to receive Ad-data. Similarly other formats allow the user 102 to remove him/her from subscription or perform other operations.

The server device has 4 main processes, aggregating engine 231 that aggregates information from various sources, one that processes the Ad-data sent by the user 100 and Ad/Content requests (FIG. 9) of the client device 102 and also computes Contextual Advertisements, another that processes the tracking requests (FIG. 10) of the client device 102 and the third that schedules user Ad/Content requests (FIG. 11), from users who have subscribed for information. We describe the latter three.

FIG. 9 is a flowchart showing one illustrative implementation of how the server device 114 processes Ad requests. Note that the server 114 will perform an analogous sequence of steps to process Content requests. The first task is to check the validity of the Ad-data (906) or Ad request (910) which ever is received. If the server device gets Ad-data (904), for example placing an advertisement for house rent, it would check its validity and store it in the

Ad/Content database (906). If the server device 114 gets Ad request (902) it would check for its validity (910). This includes functions like checking if the user has specified certain parameters correctly and the parameters and the values specified are understandable to the server device. In case the specified Ad request is invalid, the server device 114 would send a warning message (908) back to the user 100 of the client device 102 stating that it could not recognize the Ad request and will send the user a closest match for his request. The message would be sent via the medium, by which the Ad request arrived, e.g., if the user had sent an

SMS message, the message would be sent via SMS. On the other hand, if the Ad request is valid, then sending a warning message is not required.

Subsequently, the server device 114 would check the frequency parameter (914) from the list of Ad parameters of the Ad request. If this parameter demands that the server device 114 send Ad-data immediately, it would first save this Ad request in the user history database (912) to keep track of user preferences. Based on preferences stored in the user history database (912) and based on the Ad parameters of the Ad request it would find out the appropriate Ad-data from the Ad/Content database 232.

If no Ad-data is found (918), it would send the closest matching Ad-data (920) to the user 100. If Ad-data is found (918) it would send it to the user (924). The delivery mechanism of Ad-data would be as stated (926) in the Ad request. If nothing is mentioned the Ad-data or the message will be sent (934) to the user will be via the same medium by which the Ad request arrived, else it will be delivered (930) using the specified method, i.e., SMS, MMS, for web content or for Mmodule 302. Contextual advertisements may also append to the Ad- data depending on the user profile and availability of the corresponding advertisements.

If, however, the Ad request requires the server device to send Ad-data at specified times/frequency then the client 102 - server 114 system needs to keep track so that Ad-data reaches the user 100 at the specified times/frequency. This tracking can either be done by the server device 114 or by the client device 102 if it has Mmodule 302 installed. The server device 114 would save the Ad request so received in the user history database 234 and then send it back to Mmodule (916) of the client device so that Mmodule 302 keeps track and is able to send an Ad request to the server device based on the set frequency. If the server device is not able to send the Ad request (922) the user might not have Mmodule 302 installed on his client device. In such a case the tracking will be done at the server device

114, the Ad request will be stored (928) in the user request scheduler database 248. The

Request scheduler 250 would continuously keep track of the Ad requests and would send the Ad-data to the user's client device based on the user-configured frequency.

FIG. 10 is a flowchart describing one illustrative implementation of how the server device

114 tracks as users access the Ad-data or Content or Contextual Advertisement via Mmodule

302. Mmodule 302 sends a tracking request to the server device 114 when a user 100 accesses Ad-data/Content/Contextual Advertisement. Upon receiving such a tracking request (1002), the server device 114 checks for its validity (1004). If it is invalid, the server device 114 just discards it (1006), else it just stores it in the user-tracking database (1008). Note that Mmodule 302 would send such a tracking request only on user consent.

FIG. 11 is a flowchart describing one illustrative implementation of the Request scheduler 250 that keeps track of when to send Ad-data/Content to users 100 that have subscribed to receive Ad-data/Content at a particular frequency. The Request scheduler 250 is responsible for continuously querying (1102) the user request scheduler database 248 and figuring out if it is time (1104) to send Ad-data/Content. If yes, then it would send the Ad/Content request (1106) to the Request processing engine 236 after collecting the Ad/Content parameters FIG. 5 and FIG. 6 from the user request scheduler database 248. The Request processing engine 236 in turn would deliver the Ad-data or Content to the user's client device 102.

FIG. 12 describes one illustrative implementation of ModuleA 402 of Mmodule 302. ModuleA 402 is responsible for interacting with the user 100. It receives any Ad/Content requests made by the user 100 via Mmodule 302 and is also responsible for receiving any Ad-data, e.g., classified ads, placed by the user 100. If it receives an Ad-data (1202) placed by the user, it sends it to the server device 114 for storing (1204) in its Ad/Content database. If it gets Ad/Content parameters (1206), for making an Ad/Content request it checks whether the server device (1210) or the user sent those. If sent by the user, it sends the Ad/Content parameters to the server device 114 for validation (1208). If on the hand, if the server device sent these, it checks if the server device validated or invalidated the Ad/Content request associated with these parameters (1212). If the server device validated the Ad/Content request, it stores the request in its Ad/Content request repository (1214). However, it is communicated to the user (1216) if the server device says that the Ad/Content request is not valid.

FIG. 13 is a flowchart describing one illustrative implementation of ModuleB 404 of

Mmodule 302. ModuleB 404 is responsible for continuously querying the Ad/Content request repository (1302) and figure out if it is time to request the server device 114 for Ad- data Content (1304). If yes, then it would send an Ad/Content request to the server device 114 after collecting the Ad/Content parameters from the Ad/Content request repository (1306). The server device 114 in turn would deliver the Ad-data/Content to the user's client device 102 via SMS 240, MMS 242 or Mmodule 238.

FIG. 14 is a flowchart describing one illustrative implementation of ModuleC 408 of Mmodule 302. ModuleC 408 is responsible for receiving all Ad-data/Content/Contextual Advertisements sent by the server device 114 and storing it in the Ad/Content/Contextual Advertisement repository 410. On receiving Ad-data/Content/Contextual Advertisement it first checks if there is enough space (1406) in the Ad/Content/Contextual Advertisement repository 410 on the client device 102. If not, it makes some space by deleting (1404) some existing Ad-data or Content or Contextual Advertisements in the Ad/Content/Contextual Advertisement repository. Once there is enough space, it stores (1408) the Ad- data Content/Contextual Advertisement just received into the Ad/Content/Contextual Advertisement repository 410. It then checks (1410) whether the user has asked for an alert message or not. If the user has asked for an alert, then it makes an alert (1412) on the mobile device.

FIG. 15 describes one illustrative implementation of ModuleD 406 of Mmodule 302. ModuleD 406 is the interface to access all the Ad-data or Content or Contextual Advertisement that the user received on his/her client device 102 based on his/her request or subscription. That Ad-data/Content/Contextual Advertisements are received by ModuleC 408 and resides in the Ad/Content/Contextual Advertisement repository 410. When a user makes a request (1502) for viewing such Ad-data and/or Content received by client device 102, ModuleD fetches (1506) Ad-data and/or Content from the Ad/Content/Contextual Advertisement repository 410 and presents the user a list, the size of the list displayed will depend on screen size, allowing the user 100 to access the Ad-data/Content via output interface 432. Module D may also send a tracking request if permitted by the user. The user will be able to browse through the received Ad-data/Content and will be able to execute operations like show, delete, forward etc. (1508 and 1510). Intermittently, ModuleD would also show the user Contextual Advertisements allowing user to perform operations similar to Ad-data/Content. If the Ad-data/Content/Contextual Advertisement is of particular interest, user will also be able to request for further details of the same.

After the user has performed operations on the list, he can move on to the next screen, get the Ad-data/Content list (1512) and then perform operations on the Ad-data/Content as previously stated.-Once the user is done browsing though all the Ad-data/Content by browsing through all the screens the user can exit ModuleD. If a user does not want to go through all the screens, the user will be able to exit anytime.

FIG. 16 describes one illustrative implementation of ModuleE 424 of Mmodule 302. ModuleE will be on the lookout for when the client device 102 turns idle (1601). As soon as it finds the device is in idle state, it will fetch Ad-data or Content or Contextual Advertisement or any combination of the from the Ad/Content/Contextual Advertisement repository (1602). It will check if this Ad-data/Content/Contextual Advertisement has been shown enough times (1604), if yes, it will send a request (1606) to the server device requesting for more Ad-data/Content/Contextual Advertisement and mark this Ad- data/Content/Contextual Advertisement for deletion. It will present this Ad-data/Contextual Advertisement (1608) to the user and send (1608) a tracking request to the server device if permitted by the user. If the user shows (1610) no interest in the Ad-data/Content/Contextual Advertisement, after displaying it, it will try to fetch different Ad-data Content/Contextual Advertisement from the repository. If the user is interested (1610), it will show (1612) the user Ad-data/Content/Contextual Advertisement details and also send (1614) a tracking request to the server device 114 if permitted by the user. Note that as soon as the user starts using the mobile device this ModuleE 424 will get aborted.

The Mmodule 302 to server device 114 communication protocol consists of an Ad request or content request which contains the values of the appropriate parameters in response to which the server may indicate that the request was bad if need be or a tracking request consisting of the unique identifier of information that was accessed by the user and the type of operation performed or Ad-data when the user wishes to publish that Ad-data and make it available to other users. Communication from the server device 114 to Mmodule 302 would consist of information (Ad-data and/or Content) coupled with Contextual Advertisements or a validated Ad request / Content request for the Mmodule 302 to keep track. Above mentioned communication between Mmodule 302 and the server device 114 can occur over any of the standard existing technologies that enable mobile communication devices to exchange information on the Internet like HTTP, HTTPS, TCP, Binary Messages, XML Messages over HTTP and/or HTTPS etc.

Contextual advertisements can also be embedded within the content, for example, content can be any standard format like text, SMS, MMS, SMIL, XHTML, WML or these formats with extensions. For example the multimedia content on mobiles in SMIL can have additional tags. <ADData length ="50" width="40"/>.

This tag when embedded in SMIL content will be interpreted by the Mmodule 302 and it can then embed Ads in an area defined by width and length of the AdData tag. In this specific case an area, with a length of 50 pixels and a width of 40 pixels will be reserved. More extensions can be added to standard content formats (SMIL, MMS, text, XHTML, WML etc.), which can then be interpreted by the Mmodule 302 to perform specific operations for coupling content with advertisements. Default tags can be added to content such as adding an <AD> tag at the end of content, which will imply to show a full screen Ad-data at the end of content, when the user accesses the content. More such tags can be added, which will then be interpreted by the Mmodule 302.

Along with general Ad/Content requests, resulting in an immediate response for Ad- data/Content or a subscription of Ad-data/Content, the client device 102 can also send Ad/Content request through any of the 5 modules (304, 306, 308, 310, 312) asking for categories of Ad-data/Content or parameters or premium services available related to Ad- data Content. For example a user 100 can ask from the server device 114 about specific categories of Ad-data available in "Electronics" category. This will result in a response, where the server device 114 will send the client device 102 a response giving some or all of the electronic categories available at the server device 114, such as (Computer, Household, Music etc.).

A user 100 can also send an Ad/Content request to the server device 114, specifying whether he liked or disliked the Ad-data/Content by saying simple yes/ no or giving some form of rating (For example Rating between 1 to 5 where 1 means low and 5 means high). A user 100 will be even able to send reviews for the Ad-data/Content through these Ad/Content requests. Note that a user would be able to review the Contextual Advertisements in a similar fashion.

The present invention provides a method for advertisements and Content to be made available on mobile devices where a user is in control of what kind of data he receives, when he wants to receive it and how he wants to receive it, giving him a flexible configurable simple and powerful way to request or subscribe for such services.

While the embodiments discussed herein are directed to particular implementations of the present invention, it will be apparent that the sub-sets and variations to these embodiments are within the scope of the invention. For instance some of the functionality provided by Mmodule 302 can be combined with the browser module 308 or other derivations can be derived to provide the same functionality.

Thus the legal scope of the invention should be determined by the appended claims and their legal equivalents, rather than by the examples given. The examples only provide one illustrative implementation of the invention.

Claims

CLAIMSWhat is claimed is:

1. A method of subscribing to text and/or audio and/or visual advertisement information, termed as ad-data, from a communication device comprising steps of: (a) aggregating ad-data at a remote server(s) from various providers; (b) requesting ad-data using said communication device; (c) receiving the ad-data request from said communication device at said remote server(s); (d) selecting relevant ad-data from said aggregated ad-data according to the received request at said remote server(s) and; (e) sending said selected ad-data from said remote server(s) to one or more desired receiving device(s) at a desired time(s) and/or time interval(s).

2. The method as recited in claim 1, wherein said communication device is any communication device selected from the group consisting of telephone, cellular phone, Personal Digital Assistants (PDAs), watches, computers and/or laptops connected to a network having at least an input mechanism for requesting ad-data.

3. The method as recited in claim 1, wherein step of ad-data aggregation is done using XML- RPC and/or Web Services using SOAP and/or SMTP and/or HTTP/HTTPS and/or XML feeds such as RSS and ATOM.

4. The method as recited in claim 1, wherein said step of aggregating ad-data from providers includes aggregating from sources such as websites and/or WAP pages and/or advertisers and/or ad-agencies.

5. The method as recited in claim 1, wherein step of requesting ad-data is done using Short Messaging Service (SMS) and/or Multimedia Messaging Service (MMS) and/or WAP and/or SOAP and/or SIP and/or HTTP and/or HTTPS and/or TCP and/or Binary Messages and/or XML Messages over HTTP and/or HTTPS.

6. The method as recited in claim 1, wherein step of requesting ad-data of a product includes providing at least one parameter related to said product such as desired geographical location where said product can be availed, and/or category of product and/or brand of product and/or model of product and/or price of product and/or percentage of discount on product.

7. The method as recited in claim 6, wherein said step of requesting ad-data is done via SMS using an SMS grammar for selecting and specifying said parameters.

8. The method as recited in claim 6, wherein said request is made by a unique code associated with at least one of said parameters.

9. The method as recited in claim 1, wherein step of requesting ad-data includes steps of: (a) optionally selecting an audio and/or visual or and/or vibrating alert and/or no alert mode for indicating receipt of the desired ad-data; (b) optionally providing delivery time(s) and/or time interval(s) and/or period(s) of subscription for receiving said ad-data, and; (c) optionally selecting desirable receiving device(s) for receiving said ad-data such as a mobile communication device with a user input mechanism, a PSTN telephone, a computer connected to a network or a TV Set top box.

10. The method as recited in claim 1, wherein said request for the ad-data of a product is made by the user of said communication device while viewing and/or listening about the product when said user is inside a store that is displaying and/or demonstrating said product and/or a similar product.

11. The method as recited in claim 1, wherein said request for the ad-data of a product is made by the user of said communication device while viewing and/or listening about the product when said user is outside the store (such as while window shopping) that is displaying and/or demonstrating said product and/or a similar product.

12. The method as recited in claim 1, wherein said request for the ad-data of a product is made by the user of said communication device while viewing said product and/or a similar product in a product catalogue.

13. The method as recited in claim 1, wherein said request for the ad-data of a product, is made by the user of said communication device while viewing and/or listening to the commercials of said product on TV and/or computer and/or audio device and/or wireless device and/or radio and/or telephone and/or cellular phone and/or billboard(s).

14. The method as recited in claim 1, further comprising of storing said request at said communication device and/or at said remote server(s).

15. The method as recited in claim 6, wherein step of requesting ad-data includes identifying geographical location that is either explicitly specified by the user of the communication device or is communicated by said communication device or is computed and communicated externally (using technologies such as TDOA).

16. The method as recited in claim 1, wherein said receiving device is a communication device selected from the group consisting of telephone, cellular phone, Personal Digital Assistants (PDAs), watch, computer connected to a network, TV set top box having at least a mechanism to receive and play/display data.

17. A method of subscribing and accessing ad-data and/or content, termed as information, on a mobile communication device having a user input mechanism, a display unit and a memory for storage, comprising steps of: (a) aggregating information at a remote server(s) from various information providers; (b) requesting information using said device; (c) receiving said information request from said device at said remote server(s); (d) selecting relevant information from said aggregated information according to the received request at said remote server(s); (e) sending said selected information from said remote server(s) to said device at a desired time(s) and/or time interval(s); (f) accessing received information on said device either immediately after said information is received and/or storing said information in said memory and accessing it later and/or storing said information in said memory allowing the information to be displayed (and/or played) when said device turns idle.

18. The method as recited in claim 17, wherein step of information aggregation is done using XML-RPC and/or Web Services using SOAP and/or SMTP and/or HTTP/HTTPS and/or XML feeds such as RSS and ATOM.

19. The method as recited in claim 17, further comprising of storing said request at said device and/ or at said remote server(s).

20. The method as recited in claim 17, wherein said step of requesting includes selecting different alert levels, to indicate receipt of different information, from amongst audio and/or visual and/or vibration alerts or no alert options.

21. The method as recited in claiml7, wherein step of requesting information includes identifying geographical location that is either explicitly specified by said user or is communicated by said requesting device or is computed and communicated externally (using technologies such as TDOA).

22. The method as recited in claim 17, wherein said step of accessing information includes displaying and/or playing said information on a predetermined fraction of the display unit.

23. The method as recited in claim 17, wherein said step of accessing information includes displaying and/or playing stored information sequentially and/or in parallel in a predetermined or a random order on said device as its screen turns idle.

24. The method as recited in claim 17, wherein said device is termed idle during the occurrence of at least one event from the group consisting of when said device is started and/or during an voice call and/or termination of a voice call and/or holding a voice call and/or receiving a SMS and/or receiving an MMS message and/or finishing reading the message (text/picture/audio) and/or activation of a screen saver and/or when the display of said device displays its default screen.

25. The method as recited in claim 17, comprising the further steps of (a) invoking yet another computer program for computing contextual advertisement(s); (b) sending said contextual advertisement(s) to said device; (c) accessing received contextual advertisement(s) on said device either immediately after said contextual advertisement(s) is received and/or storing said contextual advertisement(s) in said non volatile memory and access it later and/or storing said contextual advertisement(s) in said memory allowing the contextual advertisement(s) to be displayed (and/or played) when said device turns idle.

26. The method as recited in claim 25, wherein said step computing contextual advertisement(s) is based on tracking current and previous request(s) made via the device and/or WAP request made via a browser interface through the device and/or a http/https request made by the device and/or responses registered from the device as user accesses the sent information and/or responses registered from the device as user accesses the contextual advertisement(s) on said device and/or by identifying geographical location that is either explicitly specified by said user or is communicated by said requesting device or is computed and communicated externally (using technologies such as TDOA).

27. The method as recited in claim 26, wherein said step of request tracking is performed on the device and/or the remote server(s).

28. The method as recited in claim 25, further comprises a step of providing a computer program on said device for picking and displaying and/or playing said information and/or said contextual advertisement(s) stored in said memory of said device when said device turns idle.

29. The method as recited in claim 25, wherein said stored information and/or contextual advertisement(s) is displayed and/or played sequentially and/or in parallel in a predetermined order or a random order on said device as its screen turns idle.

30. The method as recited in claim 25, wherein said information and/or contextual advertisement(s) is displayed and/or played on a predetermined fraction of the display unit of said device.

31. The method as recited in claim 25, wherein said contextual advertisement(s) is displayed and/or played with content on the web page while browsing through the Internet using said device.

32. A method of subscribing a text and/or audio and/or visual ad-data from a communication device as herein described with reference to accompanying drawings.

33 A method of subscribing and accessing information on a communication device as herein described with reference to accompanying drawings.

34. A system for subscribing to text and/or audio and/or visual advertisement information, termed as ad-data, said system comprising: (a) a communication device for requesting ad-data; (b) a remote server(s) for aggregating ad-data from various providers, for receiving the ad-data request from said communication device, for selecting relevant ad- data from said aggregated ad-data according to the received request and for sending said selected ad-data to one or more desired receiving device(s) at a desired time(s) and/or time interval(s).

35. The system as recited in claim 34, wherein said communication device is any communication device selected from the group consisting of telephone, cellular phone, Personal Digital Assistants (PDAs), watches, computers and/or laptops connected to a network having at least an input mechanism for requesting ad-data.

36. The system as recited in claim 34, wherein the remote server(s) uses XML-RPC and/or Web Services using SOAP and/or SMTP and/or HTTP/HTTPS^' and/or XML feeds such as RSS and ATOM for aggregating ad-data.

37. The system as recited in claim 34, wherein the remote server(s) aggregates ad-data from sources such as websites and/or WAP pages and/or advertisers and/or ad-agencies.

38. The system as recited in claim 34, wherein the communication device requests ad-data using Short Messaging Service (SMS) and/or Multimedia Messaging Service (MMS) and/or WAP and/or SOAP and/or SIP and/or HTTP and/or HTTPS and/or TCP and/or Binary Messages and/or XML Messages over HTTP and/or HTTPS.

39. The system as recited in claim 34, wherein the request for ad-data, of a product, made from the communication device comprises of at least one parameter related to said product such as desired geographical location where said product can be availed and/or category of product and/or brand of product and/or model of product and/or price of product and/or percentage of discount on product.

40. The system as recited in claim 39, wherein the communication device requests for ad- data via SMS using an SMS grammar for selecting and specifying said parameters.

41. The system as recited in claim 39, wherein the request for ad-data made from the communication device consists of a unique code associated with the at least one of said parameters.

42. The system as recited in claim 34, wherein the request for ad-data made by the communication device consists of: (a) optional parameter to specify audio and/or visual or and/or vibrating alert and/or no alert to indicate receipt of the desired ad-data; (b) optional parameter to specify the delivery time(s) and/or time interval(s) and/or period(s) of subscription for said ad-data, and; (c) optional parameter to specify desirable receiving device(s) for receiving said ad-data such as a mobile communication device with a user input mechanism, a PSTN telephone, a computer connected to a network or a TV Set top box.

43. The system as recited in claim 34, wherein said request for the ad-data of a product is made by the user of said communication device while viewing and/or listening about the product when said user is inside a store that is displaying and/or demonstrating said product and/or a similar product.

44. The system as recited in claim 34, wherein said request for the ad-data of a product is made by the user of said communication device while viewing and/or listening about the product when said user is outside the store (such as while window shopping) that is displaying and/or demonstrating said product and/or a similar product.

45. The system as recited in claim 34, wherein said request for the ad-data of a product is made by the user of said communication device while viewing said product and/or a similar product in a product catalogue.

46. The system as recited in claim 34, wherein said request for the ad-data of a product, is made by the user of said communication device while viewing and/or listening to the commercials of said product on TV and/or computer and/or audio device and/or wireless device and/or radio and/or telephone and/or cellular phone and/or billboard(s).

47. The system as recited in claim 34, wherein said request is stored at said communication 5 device and/or at said remote server(s).

48. The system as recited in claim 39, wherein the request for ad-data made by the communication device consists of the geographical location that is either explicitly specified by the user of the communication device or is communicated by said communication device0 or is computed and communicated externally (using technologies such as TDOA).

49. The system as recited in claim 34, wherein said receiving device is a communication device selected from the group consisting of telephone, cellular phone, Personal Digital Assistants (PDAs), watch, computer connected to a network, TV set top box having at least a 5 mechanism to receive and play and/or display data.

50. A system for subscribing and accessing ad-data and/or content, termed as information, consisting of: (a) a mobile communication device having a user input mechanism, a display unit and aO memory for i. requesting said information; ii. accessing received information either immediately and/or storing said information in said memory and accessing it later and/or storing said information in said memory allowing the information to be displayed (and/or5 played) when said device turns idle; (b) a remote server(s) for aggregating information from various information providers, for receiving said information request from said device, for selecting relevant information from said aggregated information according to the received request and for sending said selected information to said device at a desired time(s) and/or time0 interval(s).

51. The system as recited in claim 50, wherein the remote server(s) uses XML-RPC and/or Web Services using SOAP and/or SMTP and/or HTTP and/or XML feeds such as RSS and ATOM for information aggregation.

52. The system as recited in claim 50, wherein said request made is stored at said device and/or at said remote server(s).

53. The system as recited in claim 50, wherein said request made by said device includes selecting different alert levels, to indicate receipt of different information, from amongst audio and/or visual and/or vibration alerts or no alert options.

54. The system as recited in claim 50, wherein said request made by said device includes identifying geographical location that is either explicitly specified by said user or is communicated by said requesting device or is computed and communicated externally (using technologies such as TDOA).

55. The system as recited in claim 50, wherein said device displays information on a predetermined fraction of the display unit.

56. The system as recited in claim 50, wherein said device displays and/or plays stored information sequentially and/or in parallel in a predetermined or a random order on said device as its screen turns idle.

57. The system as recited in claim 50, wherein said device is termed idle during the occurrence of at least one event from the group consisting of when said device is started and/or during an voice call and/or termination of a voice call and/or holding a voice call and/or receiving a SMS and/or receiving an MMS message and/or finishing reading the message (text/picture/audio) and/or activation of a screen saver and/or when the display of said device displays its default screen.

58. The system as recited in claim 50, wherein (a) said remote server(s) further computes contextual advertisement(s) and sends said contextual advertisement(s) to said device; (b) said mobile communication device further enables user access to received contextual advertisement(s) either immediately and/or stores said contextual advertisement(s) in said memory for the user to access it later and/or stores said information in said memory allowing the information to be displayed (and/or played) when said device turns idle.

59. The system as recited in claim 58, wherein said remote server(s) computes contextual advertisement(s) by tracking current and previous request(s) made via the device and/or WAP request made via a browser interface tlirough the device and/or a http/https request made by the device and/or responses registered from the device as user accesses the sent information and/or responses registered from the device as user accesses the contextual advertisement(s) on said device and/or by identifying geographical location that is either explicitly specified by said user or is communicated by said requesting device or is computed and communicated externally (using technologies such as TDOA).

60. The system as recited in claim 59, wherein request tracking is performed on said device and/or said remote server(s).

61. The system as recited in claim 58, wherein said device picks and displays and/or plays said information and/or said contextual advertisement(s) stored in said memory of said device when said device turns idle.

62. The system as recited in claim 58, wherein said device displays and/or plays stored information and/or contextual advertisement(s) sequentially and/or in parallel in a predetermined order or a random order as its screen turns idle.

63. The system as recited in claim 58, wherein said device displays and/or plays said information and/or contextual advertisement(s) on a predetermined fraction of the display unit.

64. The system as recited in claim 58, wherein said device displays and/or plays said contextual advertisement(s) with content on the web page while browsing the Internet using said device.

65. A system of subscribing a text and/or audio and/or visual ad-data from a communication device as herein described with reference to accompanying drawings.

66 A system of subscribing and accessing information on a communication device as herein described with reference to accompanying drawings.