HK1156712A - Data collection and targeted advertising systems and methods - Google Patents

Description

Data collection and targeted advertising system and method

Copyright authorization

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever.

Cross Reference to Related Applications

This application claims U.S. provisional application No. 61/049,030 filed on 30/4/2008; 61/074,995 filed on 23/6/2008; and 61/075,304 as submitted 24.6.2008; each of which is also incorporated herein by reference.

Background

Mobile service providers typically use server-side technology to collect usage information. One technique is to track downloads from a WAP portal/web server as the user accesses a website optimized for viewing on a mobile phone. A drawback of this technique is that it does not provide fine-grained information about how the user actually consumes the content. Such information would be useful to better adapt service provisioning to user needs. Another technique for collecting usage information is by tracking delivery of SMS (short message service) messages. A disadvantage of this technique is that it typically assumes that the recipient views each SMS message that is delivered. However, this assumption can be very inaccurate because many users delete spam email (spam) SMS messages without viewing them.

In the absence of reliable usage information, the general form of mobile advertising is via SMS spam email. In many locations where incoming SMS messages are free, advertisers purchase the entire SMS delivery volume and send spam e-mail to users with SMS advertisements. Users often delete these advertisements without viewing them. Some evidence indicates that some consumers do not want to pay for content, but will be willing to view advertisements in exchange for not paying for content. Some consumers even enjoy watching advertisements.

Disclosure of Invention

The following is a non-limiting summary of certain inventive aspects of certain embodiments of the systems and methods described herein:

in one embodiment, a mobile telecommunications device includes: a display for displaying content to a user; one or more input devices for collecting input from a user; and one or more processors adapted and programmed to communicate with the server system and present targeted advertisements to the user, the advertisements being targeted based at least in part on usage statistics stored on the server system and previously collected from the mobile telecommunications device.

In another embodiment, a server system for collecting usage statistics and recommending targeted advertisements includes one or more processors adapted and programmed to receive usage statistics from a plurality of mobile telecommunications devices, analyze the usage statistics and thereby generate recommendations for advertisements targeted to users of the mobile devices, wherein the one or more processors make inferences about the interrelationships of the users by tracking the applications and/or content transfer behavior of the users, and recommend products and/or services to the users based at least in part on the interrelationships of the users.

In another embodiment, a method for presenting targeted advertisements to a user of a mobile telecommunications device includes collecting usage statistics from the mobile telecommunications device; transmitting the usage statistics to a server system; receiving from the server system a recommended targeted advertisement, the advertisement recommended by the server system based at least in part on the collected usage statistics; and presenting one or more of the recommended targeted advertisements to a user via the mobile device.

In another embodiment, a method for recommending targeted advertisements to a user of a mobile telecommunications device includes receiving usage statistics collected from the mobile telecommunications device; reasoning about the user's interrelationships by tracking the user's application and/or content transfer behavior; generating a recommendation regarding an advertisement targeted to a user of the mobile device based in part on the correlation of the users; and transmitting the recommendation to one or more of the mobile telecommunications devices.

In another embodiment, a method for identifying a mobile telecommunications device for the purpose of collecting usage statistics and recommending targeted advertising includes collecting usage statistics from the mobile telecommunications device; receiving a mobile device identifier from a server system; transmit the usage statistics to the server system such that the server system can associate the usage statistics with the mobile device, and receive a recommended targeted advertisement from the server system, wherein the advertisement is targeted to an advertisement based at least in part on the transmitted usage statistics.

In another embodiment, a server system for collecting usage statistics from a mobile telecommunications device includes one or more processors adapted and programmed to transmit a mobile device identifier to a mobile telecommunications device, receive usage statistics from the mobile device, and verify that the received usage statistics originate from the mobile telecommunications device based at least in part on an association of the mobile device identifier and the received usage statistics.

The term "mobile telephone" or "mobile device" as used herein generally refers to any electronic device for mobile voice or data communications, and includes, without limitation, devices known by other names, such as cellular telephones, handsets, cellular telephones, cells, mobile devices, wireless telephones, mobile telephones, smart phones, gaming devices, personal digital assistants, and the like.

Other inventive aspects of the systems and methods described herein are described below. It should be recognized that in some embodiments, only some of the above-described inventive aspects may be included. It should be appreciated that these systems and methods are novel in nature as to their application and the many components, systems, and methods employed therein. It should be appreciated that embodiments of the foregoing inventive working body can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, a computer readable medium, and/or a combination thereof. A number of illustrative embodiments are described below.

Drawings

The working body of the invention will be readily understood by reference to the following detailed description, taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram illustrating various elements of a system for data collection and usage statistics measurement in the context of targeted mobile advertising;

FIG. 2 shows an example of a user interface for a branded application (branded application) associated with a particular television program, according to one embodiment;

FIG. 3 shows an example of a deck-based mobile phone user interface;

FIG. 4 illustrates an example of a piece of content and an associated advertisement;

FIG. 5 illustrates the primary entities and their relationships in an illustrative database schema, in accordance with certain embodiments;

FIG. 6 illustrates 'user' entities and related entities in accordance with certain embodiments;

FIG. 7 illustrates 'content' entities and related entities representing content items, in accordance with certain embodiments;

FIG. 8 illustrates entities used in content organization, in accordance with certain embodiments;

FIG. 9 illustrates entities 'advertisers', 'advertisements' and 'purchase orders' according to some embodiments;

FIG. 10 illustrates entities involved in order fulfillment in certain embodiments;

FIG. 11 illustrates entities involved in coupons and location sensitive advertisements in certain embodiments;

FIG. 12 illustrates how raw chart data is collected, in accordance with certain embodiments;

FIG. 13 illustrates a basic three-layer layout used in one embodiment;

FIG. 14 shows an illustrative interface for performing user management in accordance with certain embodiments;

15, 16, and 17 show illustrative interfaces for advertisers, advertisements, and advertisement purchase orders, respectively, in accordance with certain embodiments;

FIG. 18 illustrates a content provider interface according to some embodiments;

FIG. 19 illustrates a channel interface screen according to some embodiments;

FIG. 20 illustrates a feed interface screen according to some embodiments;

FIG. 21 illustrates a reservation interface screen according to some embodiments;

FIG. 22 illustrates a dispense interface screen according to some embodiments;

FIG. 23 illustrates a Modify-assign interface screen, according to some embodiments;

FIG. 24 illustrates a coupon interface screen according to some embodiments;

FIG. 25 illustrates a location advertisement interface screen in accordance with certain embodiments;

26a and 26b are flow diagrams illustrating steps for mobile content services to provide mobile identity and protect/verify usage data, according to some embodiments;

FIG. 27 is another flow chart showing steps for mobile content services to provide mobile identity and protect/verify usage data, in accordance with certain embodiments;

FIG. 28 illustrates a layout of a system for tracking behavior of mobile consumers, in accordance with certain embodiments;

FIG. 29 is a diagram illustrating locations corresponding to location-sensitive advertisements for targeted users at times of a particular day, in accordance with certain embodiments;

FIG. 30 is a diagram showing inference relationships between users; and

FIG. 31 is a diagram illustrating SMS message routing for sharing or recommending applications or content between users according to some embodiments.

Detailed Description

The following provides a detailed description of the working subject of the present invention. While multiple embodiments have been described, it should be understood that the inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. For example, without limitation, while the illustrative embodiments described below are in the context of targeted mobile advertising, it should be appreciated that the systems and methods described herein may be readily adapted to other contexts as well, including but not limited to non-mobile contexts, contexts involving targeting content other than advertising (e.g., entertainment content, news and informational content, etc.). In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the working subject of the invention, certain embodiments may be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the operation of the subject invention.

Targeting advertisements and other content to users based on relevance is a more effective way to attract the attention of users than sending spam email. Systems and methods are presented for facilitating the collection of usage information and/or other data, and/or for facilitating targeted advertising and/or other content. Systems and methods are described herein which, in certain embodiments, may be used to attract mobile phone users and/or provide a platform for targeted advertising and/or audience measurement using digital rights management ("DRM") techniques such as those described in commonly assigned, co-pending U.S. patent application No. 11/583,693 (publication No. 2007/0180519 a 1) ("the '693 application") filed on 18.10.2006, and/or DRM techniques and/or service coordination (orchestration) techniques described in commonly assigned U.S. patent application No. 10/863,551 (publication No. 2005/0027871) ("the' 551 application"), the entire contents of the '693 and' 551 applications are incorporated herein by reference. It should be appreciated that these systems and methods are novel, as are the many components, systems, and methods employed therein.

The collection of usage information is one application that greatly benefits from the use of trusted computing. Systems that collect usage statistics typically need to ensure that data is collected accurately and can be trusted. For example, advertisers will typically require assurance that the collected information is integrity protected (e.g., it is not modified or tampered with) after collection. A mobile user may want their privacy protected and/or regulations in certain venues may require protection of the user's privacy.

Many of the embodiments described herein overcome some or all of the problems of current techniques used in mobile usage data collection by enabling the collection of trusted and accurate client usage data. The collected data may be analyzed by the back-end system and used to provide targeted advertising, promotional offers, etc. to users who may be interested in receiving them, thereby increasing system efficiency and contributing to a more satisfying user experience.

In one embodiment, a system is provided that includes a client application on a PC and/or mobile platform and a corresponding service backend infrastructure. The client application measures user information and relays this information to the service backend. The collected data is correlated with other information, such as demographic data, and used to deliver targeted advertisements or other information to the user. The client reports the collected usage information using an appropriate backhaul channel, such as SMS or web-based protocols. The targeted advertisement may be delivered separately or with the associated piece of content.

In some embodiments, the measurement and collection of usage statistics is enabled even when the user is mobile or offline. A DRM engine may be used to enable applications to record such usage statistics. Encoding and compression techniques may be used on the collected usage statistics and/or the usage statistics may be sent in a multi-part message if they exceed any applicable size limit. Alternatively, or in addition, in some embodiments, usage statistics may be collected and analyzed at the service backend.

Some advantages of certain preferred embodiments of the systems and methods described herein include, for example:

(1) the service provider may use the usage statistics to determine the effectiveness of the content service and customize its offerings (referrings) based on this feedback. For example, the service provider may collect fees determined by analyzing usage statistics for advertisements displayed with the general content.

(2) The consumer will have more relevant content and provide items. The consumer will be shown the advertisements that they will be interested in, which will improve their user experience. The consumer may also be provided with the option of a free advertising content service.

(3) Advertisers can realize savings by delivering advertisements to targeted users instead of broadcasting advertisements via spam email. In some embodiments, the advertiser will be able to see from the collected usage information whether the advertisement was actually viewed.

(4) Content providers can track the popularity of their offered items within a rapidly growing pool of mobile users, which is currently not being tracked efficiently.

Illustrative implementation details

Content encryption

In some embodiments, no content encryption is used. In other embodiments, the content may be encrypted using any suitable technique, such as those described in the '693 and' 510 applications. Possible reasons for not encrypting the content include:

(1) encryption is often ineffective at protecting content. Clear text versions of encrypted content often become available to consumers, whether or not encryption was initially used.

(2) Currently, consumer devices are used to freely transfer unencrypted content between devices and play the content on different devices without any restrictions. Thus, using unencrypted content may help avoid creating a user experience that would be perceived as worse than what consumers are currently accustomed to.

(3) Mobile phone manufacturers have built barriers into their platforms that make it difficult for third party application developers to generate applications with codec hooks. Traditional deployment routes via device manufacturers or system integrators can be difficult. By not requiring encryption, third party applications can be deployed via direct download by subscribers using non-traditional paths without having to go through the device manufacturer or carrier.

(4) In embodiments where the content pushed to the user has a relatively short-lived value (e.g., a clip from a network TV program), encryption is less required.

In one embodiment, the consumer's mobile device will include a DRM engine such as described in the' 551 application and/or the '693 application, and will take care of control information related to metering and ad insertion (e.g., including obligations and/or returned licenses (licenses) of the type described in the' 693 application). The mobile device will use the appropriate backhaul channel to report the collected statistics, such as SMS and/or the web service protocol described in the' 551 application.

In one embodiment, applications are provided for a PC and/or mobile platform. Web tv programs characterized by questioning or disputes have acquired enormous advocates and viewers (viewship) and have generated a great deal of user feedback on voting. In one embodiment, the application will enable the user to download content clips with embedded advertisements from a network television program and transfer these clips to his or her cell phone (or tethered phone) or download the clips directly to the phone (e.g., to a 3G phone).

While interest in web TV programming may be one of the factors that may initially motivate a user to download an application to his or her PC and/or mobile phone in order to attract and maintain the user's attention, the application will preferably provide the user with some value in making certain activities easier. In one embodiment, the features set for the application may include capabilities such as some or all of the following: (1) enabling a user to automatically download snippets and/or clips from new episodes of a program; (2) enabling a consumer to consume content offline or on the move; (3) providing a free ring tone corresponding to the clip and making it easy to set the ring tone on the phone; (4) enabling the consumer to send a ring tone from the program to another mobile phone (e.g., to a friend); (5) facilitating voting for a particular competitor on a program from within the application; and/or (6) provide trivia, joke, and background information about the program.

In one illustrative embodiment, a system is provided that includes some or all of the following components:

(1) PC-based player applications and RSS feed listeners for downloading program extracts, clips, advertisements, licenses, etc. and for providing a mechanism to transfer content and ring tones to tethered devices (e.g., mobile phones). For example, the application may send the ring tone to the mobile phone using SMS.

(2) A mobile phone application, or a suite of mobile phone applications, customized for low, mid, and high end phones, respectively.

Alternatively, in some embodiments, for a single low-end phone that can only receive ring tones, no dedicated mobile application is used. In such embodiments, SMS delivery reports obtained from the SMS gateway may be used to track, for example, which ring tones a particular user receives. The advertisement may be inserted into the ring tone SMS.

For mid-range and mid-range phones that have more capabilities than low-end phones, but may have slow network connections, different applications may be provided for different platforms (e.g., for Java-enabled phones and Symbian phones). In the case of a Java enabled phone, a mobile version of the PC application may be provided, with content (e.g., audio and ring tone content) side-loaded thereon. The application may start with a pre-personalized DRM engine and may store metering data in a secure memory. An SMS adapter may be used to read this data and periodically upload it to the service backend via SMS. A Symbian version of the mobile phone application may also be provided which provides similar functionality.

For high-end phones, such as 3G smart phones with fast network connections, a full-function, mobile version of the PC application with a built-in DRM engine and service coordination stack may be used. Such applications may be functionally equivalent to PC applications, but preferably have a user interface customized to the phone screen form factor.

(3) Back end infrastructure. In a preferred embodiment, the backend infrastructure may include some or all of the following functions: generating a feed; ad insertion for static and/or dynamic advertising; generation of a ringtone from the audio clip (e.g., a ringtone of Truetone for the nokia platform); packaging tools for packaging content and related licenses that require metering and/or ad insertion (e.g., via obligation and/or recovery mechanisms described in the' 693 application); an SMS gateway and a web-based front end/web service interface to enable a PC-based application to send a ring tone to a phone via SMS; a mechanism to collect and organize metering data sent via SMS in a database for analysis; and offline tools for analyzing and correlating received metering and usage information with other data to more efficiently make inferences about user behavior. For example, usage data indicating advertisement viewing preferences may be associated with demographic data (such as, for example, age and income) to help identify target segments for the population of a particular product.

A more detailed exemplary embodiment is described below in conjunction with fig. 1, which is a diagram of various elements of an illustrative system for data collection and measurement of viewer usage statistics for use, for example, in targeted mobile advertising. The service backend 110 includes a report generator 118, a database 116, a packager 120, an SMS gateway 122, and an HTTP server/RSS feed generator 112. In one example, a PC application running at the service backend 110 targets a user having a PC 114 and a mobile phone to which content is copied over a data cable, for example, by installing the mobile phone in USB mass storage mode on the PC.

Many web television programs currently have official websites, but they are often relatively slow to load relative to the web. This makes it less useful, especially in view of the fact that some households have slow dial-up links and/or relatively slow shared internet connections. Thus, in certain preferred embodiments, the PC application may be installed locally on the user's PC 114 (e.g., Microsoft WINDOWS-based PC), and network bandwidth may be used to download content/metadata via RSS and provide a better user experience, particularly in a disconnected fashion.

In a preferred embodiment, the DRM client is included on a PC and/or mobile phone and may be pre-personalized, for example with a personality and/or fixed user node of the type described in the' 693 application.

Fig. 2 shows an example of a user interface 210 for a brand promotion application (e.g., a "Sa Re Ga Ma Pa" application) associated with a particular television program, according to one embodiment. For example, the application may be running on a user's PC, such as PC 114 in FIG. 1.

Content/metadata download

In one embodiment, a PC application running on a PC, such as PC 114 of FIG. 1, has a user interface, such as user interface 210 of FIG. 2, and an RSS feed listener for providing a content download URL and metadata for the content. In one embodiment, the application periodically listens to the feed and downloads the content and metadata, for example, automatically from the database 116 of FIG. 1. In some embodiments, the PC application may also include buttons/menu items to perform such operations "on demand". This may be useful for consumers who do not have an "always on" internet connection.

In some embodiments, the PC application may support some or all of the following:

(1) new items and trivia related to the program are automatically downloaded to encourage the user to use the system more.

(2) Simple searches for content are supported, for example, using basic search schemes (e.g., words, word lists, wildcards using' ″, etc.).

(3) Supporting the transfer of content to tethered devices. Alternatively, or in addition, the user may directly mount the mobile phone as a USB mass storage device and copy the files using only the file manager (file explorer). The convenience provided by enabling the transfer as a tethered device is that the content and metadata will be copied to the phone at the correct location and that it has the correct directory structure (e.g., the location and directory structure that the mobile application expects to see).

(4) Enabling sending a ring tone to the phone. In one embodiment, the application includes an interface for enabling the user to send a ring tone to the phone (possibly along with some protection against automated mud-plugging). The user selects the phone type (e.g., brand/model), enters the phone number, and sends the ringtone with the personalized message. In one embodiment, static advertisement text/graphics may also be inserted automatically by the backend.

Mobile application program

In a preferred embodiment, at least two categories of mobile applications are supported:

1) a limited feature set application for tethered devices; and

2) a fully functional mobile application (e.g., an application functionally equivalent to the PC application described above).

In some embodiments, the user interface of the mobile application may be "deck-based," with buttons on the bottom to navigate to menus and sub-menus.

Fig. 3 shows an example of a deck-based mobile phone user interface. As shown in fig. 3, the interface on the mobile phone 310 provides left and right arrow buttons 312 and 314, respectively, which are used to navigate between content items, the 'play' button 316 and the 'vote' button 318 are self-explanatory, and the 'bell' icon 320 is used to set the ring tone corresponding to the currently selected content item.

In one embodiment, the limited feature set mobile application has the following special features: (1) a DRM engine pre-personalized and pre-registered to a given user; (2) an SMS adapter to upload metering data; and (3) a media player application that plays the plaintext content and that is capable of parsing the DCF/PDCF file, evaluating the license, and supporting DRM functions such as obligation and recovery.

In one embodiment, the fully functional application has all of the features of the limited feature set application, plus a complete service coordination stack (e.g., NEMO stack) such as described in the' 551 application, and the ability to participate entirely as a client in a system such as the Marlin Broadband ecosystem.

Backend infrastructure

In one embodiment, the functionality of the backend infrastructure 110 of fig. 1 includes feed generation, ad insertion, content packaging, SMS gateway, metering and usage data upload, and data analysis and correlation.

Feed generation. An RSS feed is generated that the client will consume. In one embodiment, the feed may contain information that enables the client to automatically download the content.

Advertisement insertion. In one embodiment, there are two points for ad insertion: (1) insertion into content (e.g., statically and/or dynamically); and (2) out-of-band delivery (e.g., via SMS). Examples of out-of-band delivery include delivery as part of a ringtone, and delivery as a plain advertisement.

Content packaging. In some embodiments, a relatively simple license is used. In other embodiments, Dynamic ad insertion may be enabled, for example, using a relatively rich license such as described in U.S. patent application No. 12/178,543, "Dynamic Media Zones Systems and Methods" (publication No. 2009/0031431 a 1), filed in the' 693 application and/or on 28.7.2008, the contents of which are incorporated herein by reference. In one embodiment, DCF/PDCF may be used as a container format.

Metering/usage data upload. In one embodiment, SMS is used asA backhaul channel (RC) for uploading usage data to a backend infrastructure. In some embodiments, the data may be encoded and compressed for efficiency.

Data analysis and correlation. The uploaded data is extracted from the SMS gateway, decompressed, decoded, and then loaded into a database for further analysis. The correlation of the upload data with other data sources, such as demographic data, may be strong. Examples are provided below:

analysis of collected metering/usage data. Fig. 4 shows an example of a content piece 412 and an associated advertisement 410 (e.g., an advertisement for a car). For purposes of illustration, assume that data analysis shows the following: (1) the user plays advertisement 410 multiple times; (2) the user rewinds and plays back some segments of advertisement 410 multiple times; and (3) the user replays the advertisement 410 a few days after initially viewing the content 412. In this example, the user's behavior indicates that the user finds this advertisement interesting. The fact that the user returns to the content item and plays the advertisement again may mean that it is not a brief interest. A portion of the advertisement that may be played back indicates something of particular interest. These types of analysis may help identify users who are interested in a particular product.

Correlation with demographic and/or other data. Correlating the above data with data such as demographic data or previously collected data about the user may provide further confirmation of the analysis of the metrology data. For example, if the demographic data in the example discussed above shows that the user is someone from a family with a moderate income of children, a family that does not own their car or one of their cars, it may be a strong indication that the user is interested in purchasing a car. In such a case, targeted advertising by other means, such as selling a phone, may produce beneficial results for the merchant. Perhaps, the auto loan company may be interested in sending its advertising material to the user. Or perhaps, the auto dealer may propose to discount the user's old car. Collected numberFrom which valuable information can be generated that can be sold to potential consumers of this information after analysis and correlation.

License generation tool. In one embodiment, the downloaded content is associated with a license, although the content itself may not be encrypted. In embodiments where a license such as those described in the' 693 application is used, the application evaluates the license to obtain the ESB (if any) containing the metering obligation. In one embodiment, a fixed license may be inserted with only a metering obligation. In other embodiments, more complex controls may be used. A large amount of information can be obtained entirely through metering data and complex advertising support is additional. For example, a timestamp in the metering data may be used to determine whether the user viewed the advertisement, how many times the user viewed the content item, and so on.

Tamper-resistant. In some embodiments, there may be no strong stimulus to attack the system's software and/or hardware, as the content will not be encrypted. As a result, in some embodiments, complex tamper resistance may not be necessary. In some embodiments, it may be sufficient to apply any suitable form of code obfuscation to PC applications (e.g., using thermida) and/or mobile applications.

Ring format and conversion. The type of ring tone required by a mobile phone, such as mono, polyphonic, or true ring tone (Truetone), is typically dependent on the mobile setup hardware. The ring tone may be delivered to the phone via a data cable (if the user has a PC), or more commonly via SMS. The SMS encoding format for ring tones varies across phone manufacturers and is known to those skilled in the art.

SMS adapter. The only backhaul channel available on some mobile phones is the SMS channel. On mid-range phones (e.g., Java enabled phones with slow network connections), an SMS adapter may be provided to pull metering data from DRM clients and send it via SMSUp to the back end.

SMS gateway selection. In a preferred embodiment, the selected SMS gateway application/service provider is scalable to large SMS loads.

Charging for SMS. In some cases, using SMS as a backhaul channel has a cost associated with it (e.g., in some locations, incoming SMS is free, while outgoing calls carry a fee). Thus, in these cases, it may be better to upload data less frequently or via a different mechanism.

Advertisement distribution

In some embodiments, an auction-based mechanism may be used to populate the advertisement slots. In one embodiment, the advertising slots are sold via Dutch auctions (Dutch auctions). Auction-based mechanisms enable services to obtain better prices for advertising real estate, such as mobile advertising, that is otherwise difficult to determine prices in new emerging advertising delivery channels, or for advertisements associated with new content channels in established delivery channels, for which pricing models are not well developed. In a preferred embodiment, the system also utilizes standby/backup advertisements. The alternate advertisement is an advertisement that sells ad slots at a large discount, but it only occasionally starts running if any ad slot is otherwise not fulfilled via one or more primary allocation mechanisms.

Constraints on ad slot allocation include targeting constraints and adjacency constraints. The adjacency constraint may be broken down into (a) a distance constraint (e.g., a maximum or minimum allowable distance between advertisements), and (b) a mutual exclusion constraint (e.g., an advertisement of a particular type or for a particular product, manufacturer, or advertiser may not appear with another advertisement of a particular type, product, manufacturer, or advertiser).

According to some embodiments, a simple tagging mechanism allows for specifying mutually exclusive constraints using simple wildcards. A mutually exclusive constraint may be a constraint that an advertiser may wish to exclude advertisements for competing products while their advertisements are being displayed. For example, a soft drink manufacturer may want to exclude banner advertisements for products of its competitors while advertisements for their soft drinks are being played.

The advertisement distribution problem may be modeled using a mathematical programming language such as AMPL according to an objective function (e.g., generated revenue) and a number of constraints. The advertisement distribution problem is typically a non-linear discrete optimization problem that currently does not have a good numerical approach to solving the problem. The nonlinear discrete optimization problem can be decomposed into a series of linear discrete optimization problems by converting certain variables into parameters and solving the problem for a range of values for those parameters. The linear discrete optimization problem can be solved using standard algorithms such as those from the classes of branch cuts and branch delimitations. Finally, the local maxima for each sub-problem may be compared to reach the global maximum for the objective function.

Backend for advertising-enabled content delivery platform。

According to some embodiments, the systems and methods described herein are used in a backend system for a content delivery platform that supports advertising. In some embodiments, some or all of the following functions may be supported: (1) uploading the content; (2) packaging the content; (3) uploading the advertisement; (4) advertiser registration; (5) a purchase order placement for an ad unit (e.g., ad slot); (6) order fulfillment (e.g., including reservation of advertisement slots for advertisers and assignment of individual advertisements to particular slots); (7) RSS feed generation; (8) sales promotion and coupon management; (9) survey-based advertising; and/or (10) report generation.

Embodiments of the systems and methods described herein may be used to provide an infrastructure for managing advertisement placement, performing audience measurement, and targeting advertisements.

In the following discussion, the following terms will have the following meanings:

advertisement magazine	Advertisement collection tied to content item
		Advertising unit (bullet)	Partially rented time slots representing advertising real estate (e.g., banner real estate 1/5 for any single content item for a week)
MAP	Minimum advertisement unit price
		RP	Retail price (direct purchase price)
CPM	Click every thousand (for 1000 views cost of advertisement)
		CTR	Click rate

Embodiments of the systems and methods described herein are directed to developing advertisement-enabled content delivery systems for mobile users, and may be used to process transient content, such as content produced by popular network programming (e.g., singing games, dance games, quiz shows, TV live show games, etc.).

Due to the time dependency of these programs, television viewers have a significant "flash crowding problem". Traditional models for advertising, such as CPM or CTR, tend to fall into these event types. The bursty nature of viewer responses (such as votes sent by fans) has a substantial impact and needs to be accounted for by the architecture of the system in order to handle the bursty load.

There are a large number of viewers interested in these programs and the consumption pattern of content is changing dramatically due to the dramatic increase in the number of mobile phone users. This shift in consumer behavior presents many challenges and provides unique opportunities for content delivery, audience measurement, and targeted advertising. Embodiments of the systems and methods described herein attempt to address these current and evolving needs of consumers.

Advertising. Referring again to FIG. 3, a screen layout of an illustrative client application is shown. The button bar 340 at the bottom has buttons for navigating through the content (left and right buttons 312 and 314, respectively) and a voting button 318 for voting on the content display screen or for recording user clicks (e.g., as described below in the discussion of survey-based advertising). Also included in the illustrative embodiment shown in fig. 3 are logo icons (logo icon) 330, ticker advertising fields 332, video/content icons 334, information tickers 336, and animated GIF advertising banners 338.

In some embodiments, the client is capable of displaying the following types of marketing messages: (1) a text-based advertisement; (2) graphical, animated GIF banner advertisements; (3) survey-based advertising; (4) market research investigation; (5) location sensitive advertising; and (6) OOB (send via SMS) advertisements.

Text-based advertising. Examples include a simple textual scroll bar, such as a top scroll bar. The top scroll bar is an example of an animated scroll bar, which is generally more effective than ordinary static textual advertisements.

Graphic and cartoon GIF banner advertisement. These are similar to familiar internet banner advertisements.

Basic survey advertising. These are advertisements that are occasionally placed between content items (e.g., these may be displayed when the user presses the next button 314 to go to the next content item). Since the survey questions may be annoying, in a preferred embodiment they should not be used frequently. Also, in one embodiment, the user will have the option to not respond to survey questions by not pressing the middle button and instead pressing "next" to go to the next content item. Survey-based advertising can be useful because it provides a means to achieve higher value click-through (CT) advertising.

The survey ad may contain queries such as: (1) a question about a visual advertisement in a previous content item (e.g., "are you interested in knowing more about product X; (2) rating the product in the previous advertisement by a ratio of 1-5 "(radio button selection followed by middle button click); or (3) "do you like product X? Yes/no "question. The survey screen may also be independent of the previous screen and is a pure market research survey.

Location sensitive advertising. Location sensitive advertisements may be delivered to the user based on where the user is located at the point in time. Such as advertisements for nearby stores, coupons for nearby restaurants that contain promotional codes, and so forth. These context-sensitive advertisements may be user-configurable (e.g., a user may indicate a preference to opt-in or opt-out at the time of their registration, or as part of ongoing account management).

Advertisement delivery/download. In some embodiments, the advertisement will be delivered along with the content. The tethered model is probably the most practical model for content and advertisement delivery at present because wireless networks internet are relatively slow. In some markets where the 3G spectrum is not yet open (e.g., urban areas)Such as india) in particular. Also, wireless internet access is typically relatively expensive, and some users do not have wireless internet access as part of their mobile phone plans. To this end, the following may be useful: (1) an internet cafe where users can download music and/or other content; and (2) to special mobile phone kiosks that synchronize content (e.g., mobile phone charging stations in locations such as bus stops, suburban train stations, and airports). Kiosks may be set up at these locations to enable users to download content to their mobile phones. Kiosks may also be located at strategic locations in major cities (e.g., coffee shops, outside college campuses, STD-ISD centers (i.e., manned kiosks), etc.) by independent operators.

Virus application distribution. To facilitate widespread distribution of mobile phone applications, virus distribution may be encouraged, for example, as follows: (1) the user presses the 'send' button while he is running the application; (2) displaying a text box to the user to enter the mobile phone numbers of his friends at the bottom of the screen; (3) the user inputs the number and presses OK; (4) the application program sends the SMS together with the numbers of the friends to the back end; (5) the backend creates and sends an SMS containing a link to download the application to the friend; (5) the friend clicks on the link to download and install the application; and (6) the downloaded application may contain "teaser" content and advertisements (e.g., very small clips of content and advertisements) so that the user will get a request, e.g., through the internet or the nearest internet caf é or kiosk, what the application is doing, and to synchronize the phone with the latest content.

In one embodiment, the back-end will track forwarding requests for applications, learning information about relationships between users, which it can store in its database. This information may be used, for example, for friend and family targeting (described in more detail below).

AdvertisingThrow in. In a preferred embodiment, the mobile application has real estate for displaying advertising real estate that would be wasted if the advertisers were not ranked. Measurement and advertising targeting are value added services that can be used to obtain a better rate of advertising.

Now, due to the bursty nature of dialing, a significant portion of the SMS message is lost. If these messages can be delivered, it would be valuable to the carrier. In one embodiment, the request may be time stamped and if the network is busy, store-and-forward may be used to defer transmission.

Advertisement pricing

Minimum Advertisement Price (MAP). In one embodiment, the system attempts to ensure that ad real estate is not wasted (i.e., there is someone who is ranked to place an ad in a given time slot). The system accomplishes this by having a minimum price for a single ad unit. The operator of the system approaches potential advertisers and asks them on the list of unexpected events. If the advertiser commits to purchase X number of ad units at a discounted price, it may be on the list. The advertiser's advertisement will be placed only if there are points available. The minimum price may be a market price based on similar services, to which a discount is applied. In some embodiments, a certain portion of the ad units may be reserved for free public service announcements.

Retail Price (RP). This is the regular listing price that the customer pays if they wish to purchase the point immediately. The retail price may be a fixed price set for the advertising unit. The actual selling price may be more or less than the retail price depending on factors such as demand for advertising units, promotions and discounts, price reductions (e.g., for public service advertising), and the like.

Dutch auction. In one embodiment, if any of the ad units did not sell at a predefined time prior to an event (e.g.,the first two weeks of the public of popular television shows) these ad units may be sold through dutch auctions. In one embodiment, the initial price range may be RP-MAP. The bid is accepted before all unsold advertising units are sold. In one embodiment, each individual pays the price of the lowest bidder (the lowest bid to win). The actual selling price may exceed the retail price if the advertising unit is in high demand.

Targeted advertising. In one embodiment, targeted advertisements (e.g., advertisements targeted to a particular demographic) have a higher buy-now price. If they are purchased, they are removed from those that are sold later-the rest are auctioned off or sold at the lowest price.

Demographic targeting. In one embodiment, the system will enable advertisers to determine audience targets (e.g., young professionals; families without children; working adults 40-60 years old; adults greater than 60 years old, etc.) through demographic groups.

Geographic targeting. In one embodiment, the system will enable advertisers to determine audience targets (e.g., west coast, northwest, midwest, south, east coast, northeast, southeast, etc.) through a geographic region.

Local target determination. Local targeting may be performed as follows: (1) the mobile phone application periodically records the user's location; (2) the mobile phone application sends this information to the back end (e.g., when uploading the usage data); (3) when the backend receives data containing the area in which the user is traveling, it will use the advertisements from the local target repository and will send them to the user the next time the user synchronizes; (4) when a user is within X miles of a location, he will pop up a corresponding local advertisement (e.g., an advertisement for a pizza shop with a coupon; in one embodiment, it will show upA line of messages illustrating that coupons are available for local restaurants; pop-up content is preferably relatively unobtrusive); (5) the user will have the option to click on the advertisement (e.g., if the user clicks on a coupon, the application will record the click and this information can be used to bill the advertiser); (6) if the user disregards the pop-up advertisement, it will leave (time out) within some well defined time frame (e.g., after 20 seconds).

To address the subscriber problem that the gathered data will be shared with a third party, in some embodiments the service may provide assurance in terms of privacy policies, i.e., the service will not disclose identifiable user information to the third party beyond that required by the laws.

Friend and family targeting. In some embodiments, advertisers may be given the option to "demographic +" target, which targets a particular demographic, and, for example, friends of people in that demographic (e.g., to two degrees of separation, or any suitable number of degrees).

Usage management

In a preferred embodiment, usage data is collected by the mobile phone client application about some or all of the following: (1) how many times a content item is viewed (e.g., which can be used to reason about the number of advertisement views for a banner, text advertisement, video advertisement, etc.); (2) users click on local advertisements, survey advertisements, and the like; (3) user location data; (4) advertisement viewing data with respect to the dynamically inserted data.

Content identification

Watermarking. In some embodiments, content may be identified using a content watermarking scheme. For example, the watermark may be 32 bits wide, with 8 bits reserved for the content version and 24 bits reserved for the ID. Watermarking is preferably computationally easy to use mobile client applicationsThe program is read, hidden, and difficult for the user to remove and/or change.

Content ID. GIF banner advertisements and textual ticker data can be packaged with their associated content because they are typically quite small (e.g., 5-6 kilobytes for animated GIF banners). For example, if an MPEG-4 based format such as 3gp is used, a simple advertisement can be placed into the udta atom. This will make it easier to deliver and manage the advertisement and make it somewhat difficult for the user to remove the advertisement. The udta atom may have a byte to indicate the first advertisement to the display and a counter (which may be updated by the player) to indicate the next advertisement to the display.

In one embodiment, different versions of the same content are created already with different starting ad numbers. This is done to ensure fair treatment of all banner/text advertisements.

According to some embodiments, the video advertisement is also part of the content, although in some embodiments the size of the advertisement should be relatively small, since in some content items the advertisement will be repeated. In one embodiment, one video ad would be statically encoded into a video track, while any other items would be included in a separate top-level atom.

Counting rotary advertisement. In one embodiment, the advertisements are rotated (e.g., different advertisements are displayed when the user changes pages, or different advertisements are displayed based on a timer). The mobile phone application counts the number of times the user views the content item and reports this information to the back end. The back end then uses the content version and the counter to deduce how many times each advertisement was displayed.

System architecture

User management. In one embodiment, a system is provided that supports three tiers of membership: (1) anonymous users, (2) signed-up users, and (3) paid subscribers.

Anonymous users. When a user downloads content from an internet coffee shop or kiosk, he or she has (1) if he or she is signed, use the username and password; or (2) use a fixed username and password (e.g., a separate one may be created for each coffee shop location). This makes it easy for people to download content without signing (e.g. if someone does not want to go through the trouble of signing). In one embodiment, the anonymous user does not obtain some of the additional items obtained by the signed user, but is able to download the content and advertisements. In another embodiment, all users-anonymous or signed-can be measured and sent to the backend via SMS. For example, the user may be identified using the user's number (e.g., TON, NPI, and number tuple).

Signing a user. In one embodiment, the user will be able to enter an entry for the service, for example, by email and mobile phone number. This can be done, for example, as follows: (1) the user enters details (e.g., first name, second name, email address, location, gender, age, marital status, number of children, mobile phone number, etc.). The username can be a mobile phone number and a separate password can be created for each mobile phone number; (2) the user gets an email confirmation containing the link, he or she clicks on the link to confirm the email address, which results in the SMS being sent to his mobile phone; and (3) the user has the SMS message complete registration. In some embodiments, a limit may be set on the signature (e.g., a maximum of 10 mobile phones registered with a given email address each day (e.g., to prevent bot attacks)). According to one embodiment, the signing user obtains certain additional items, such as the ability to send ring tones from the program to their mobile phone, or the ability to receive background information, trivia, ocean, etc.

Paying subscribers. According to some embodiments, some subscribers pay for premium content. In this case, DRM protection may also be usedAnd a PC client.

Advertising space marketing

In one embodiment, the system provides a mechanism to enter bids for ad space (e.g., untargeted ads in one embodiment). In one embodiment, the system picks the top bid and notifies the bidder whether it wins or fails and publishes the price (open to all to see).

Advertisement selection

Targetless advertising. In one embodiment, once a winning bid is selected, those advertisements, as well as any additional advertisements sold at the lowest price, will be placed in the library (e.g., one advertisement for each of text, banner, and video). In one embodiment, advertisements are to be randomly selected and placed into an ad magazine (e.g., one for each content item). The selected advertisement will be removed from the library. This process continues until all advertisements are assigned to magazines.

Targeted advertising. In one embodiment, for targeted advertisements (e.g., advertisements targeted to a particular group of users), if the ad space is partially sold, the rest of the advertisements will be scheduled using bid prices to order the advertisements in a prioritized order. In one embodiment, the remaining space to fill for the target user is equal to the total (for the target group), minus the sold ads, minus the public service ads. These filled ads will be placed using bid prices so that the ads are prioritized (lowest priced ads are ranked last).

Content packaging. In one embodiment, once an ad magazine is associated with a content item, different versions of the content will be packaged with different start numbers for text, banner, and video ads. The targeted users form different ratings for content and advertising.

Advertising and content delivery. In one embodiment, different versions of each content item will be distributed in a round robin fashion to distribute advertisements evenly.

System design

In a preferred embodiment, the backend seeks to guarantee maximum use of real estate available for ad placement. A benefit of certain embodiments of the systems and methods described herein is information about content consumption and television viewers that can be collected from users. This data is valuable in itself and can also be used to develop inferences about user behavior and preferences over a period of time. These inferences can then be used to better tune or target advertisements.

In certain embodiments, some or all of the following design considerations may be applicable:

1. the operator is the main user of the back-end. Certain portions of the system may be exposed to outside parties (e.g., content management functions may be exposed to content providers and advertising management and delivery functions may be exposed to advertisers). However, it cannot be assumed that external parties will learn how to use the system, since the system is the only one of many channels through which their content and/or advertisements are distributed. These external parties would typically be expected to contact the service by conventional means. For example: (1) content providers will typically expect simple FTP failure (drop) for content in a generic format (possibly full screen resolution) as well as metadata. The intended service acquires this content and formats it and any metadata to make it suitable for the mobile platform; (2) advertisers will typically send a purchase order for the advertising space by telephone or by facsimile; and (3) an operator or some other type of user would typically want to be able to manually check each content item and advertisement to ensure that there is editorial control over the content and advertisement.

2. The advertising television viewer is closer to the television model than to the internet model: book (I)The preferred embodiments of the systems and methods described herein handle transient time-sensitive content, such as content related to video game programming. The user's interest in such content is high at the time the program is being broadcast publicly, but diminishes almost completely at some time after the program. The content itself is not very valuable after the event. The user interests and corresponding advertising television viewers for such content on mobile applications are expected to closely follow the television viewer. In contrast, internet advertisement viewing for well-known websites occurs at a more or less uniform rate. Internet advertising may follow a cost per impression model. In the case of television, the advertising space is sold in its entirety without directly counting the number of impressions. The billing system for television from Nielsen is an indirect measure of the audience used by advertisers to determine the price of an advertising slot.

3. Content items may not be available at advertisement sale time: content for certain programs is recorded very close to the date the program is publicly broadcast. The advertiser does not know in advance what exact content will exist. They only know the genre of the program and the type of content that was publicly played in the past.

4. Advertisements may not be available at advertisement sale time: once the advertiser has confirmed the ad space, it will typically upload/submit the ad. Advertisers may also choose to have a set of alternate advertisements uploaded to the system for use in various content feeds.

5. Constraints for ad space are available when ordering an ad space sequence: while the ad may be submitted at a later, very late time, in one embodiment, any constraints that the advertiser needs to impose on the ad placement need be made available at the time of ad space registration.

6. Back office system at back end: the back-end system is used to record and process orders for ad space. The end result of the order process is a set of RSS feeds and the packaged content and advertisements to which these feeds refer. Once generatedFeeds, packaged content, and advertisements, these may be hosted at a data center on an HTTP server and distributed to edge servers. The download statistics from the data center will be periodically recovered and uploaded into the backend system for analysis and reporting.

System user. The system user will typically include the following: (1) operator-feeds content and advertisements into the system; (2) system administrator-configure and maintain servers; advertiser-generally inaccessible system; a purchase order for the advertisement slot is typically issued via telephone or facsimile (alternatively, in some embodiments, some system interfaces may be exposed for use by these remote users); (3) content providers-typically content providers require a very simple interface for submitting content (e.g., an ftp mechanism for uploading content). The system operator takes this uploaded content and packages the content using the system after appropriate inspection; and (4) end users (e.g., consumers of content) -typically download content and RSS feeds from the public internet infrastructure.

FIG. 5 illustrates entities and their relationships in an illustrative database schema, in accordance with certain embodiments. The main entities in the system are as follows: (1) a user (e.g., a consumer/end user); (2) content (including content, tags and content types, channels, channel categories, feeds, and content providers); (3) advertisers (e.g., including advertisers and ad purchase orders); (4) order fulfillment entities (e.g., including advertisements, ad spot reservations, and advertisement distribution); (5) group and location advertising; and (6) raw statistics.

The following discussion focuses on each of the major entities in the system and provides details about their interrelationships, and uses scenarios that affect these entities.

User' s

FIG. 6 illustrates 'users' and related information according to some embodiments. In one embodiment, user entities are tracked by the following attributes:

user name

Password

Name

First name

Last name

Telephone number

· GUID

The user may optionally provide additional demographic and geographic information (e.g., via a form filled in at the time of signing), such as

Age

Sex

Marital status

Number of children

Income level-household income range

Occupation of

E-mail

Mailing address

Geographic location-then can be inferred from the address, however, geographic location refers to the regional category of the address.

Many optional tracking attributes may not be initially available to anonymous users of the system. However, this information may be populated over time (e.g., via information collected through surveys) or through other channels (e.g., external sources of demographic data, such as operator-provided customer data containing demographic information).

Tracking users. In one embodiment, the user may be logged into the system in at least two ways: (1) signing user-in this use case, userEntering all or some of its details in a form and submitting the form upon signing; and (2) anonymous users-these are users who download mobile clients directly or get clients when friends forward applications to them. It then comes to an internet cafe and synchronizes its mobile phone with the content "anonymously". The PC application generates a GUID and places it on the mobile phone. The phone then sends a "call home message" to the backend, which associates the GUID with the mobile phone number.

Updating a user. In one embodiment, the operator can update the user data (e.g., to manage lost/stolen passwords, and/or otherwise update user records).

Importing demographic data. In one embodiment, the demographic data (if made available from an external source) is formatted and entered into the system, for example, through a database update script.

Dynamic category. In one embodiment, user behavior and preference data is continuously collected and analyzed. Over a period of time, this data may help classify the user into dynamically defined categories. These categories may be used to more effectively target advertisements. Some examples of dynamic categories are frequent consumers of sports content, frequent responders to surveys, frequent consumers of promotions/coupons, frequent purchasers of items, and so forth.

In one embodiment, users may be classified as belonging to these dynamic categories based on inferences from the analyzed data. The categories themselves may be dynamic and may be dynamically added, modified, and/or deleted. There is a certain amount of fine-tuning done as the system collects data, similar to opening a store and getting well aware of your customer over time. When you know about the customer, the store may recommend or target the customer with products that they believe the customer may like.

Content providing method and apparatus

Content, tag, and content type. Figure 7 illustrates 'content' entities representing content items and related items, according to some embodiments. In one embodiment, the content items are associated with 0 to N tags that may be used to search for the content items. The content item is of a special dummy-type (e.g. audio/mp 3, video/3 gp, etc.). In one embodiment, the content item may have the following attributes:

id-unique id

Content _ provider _ id-id of the content provider submitting this content

Provider _ generated _ id-id used by the provider to identify this content item

Name-user-friendly name for content item

Description-redundant description

Duration of time

Content type

Image _ url-graphics for content items

Mobile _ image _ url-graphics created for the Mobile Phone platform

In one embodiment, the back-end operator will test/verify and enter/update the content item data at the content entry time (e.g., add content uploaded by the content provider to, for example, an ftp site). As described in more detail below, the operator may also organize content into channels, feeds, and the like.

Channels, feeds, items, and categories. FIG. 8 illustrates entities for content organization, according to some embodiments. In the example shown in fig. 8, the entities are: channel 810, feed 812, feed item 814, and channel category 816. In one embodiment, the content items may appear in zero or more feeds, and a channel may have associated with itFor example, the channel may be a 'dance contest' and the feeds associated with the channel may be 'Week 1', 'Week 2', 'WeekN', etc. In one embodiment, the channel may belong to zero or more channel categories, and the channel categories are used to search for channels using the PC application.

Advertiser

Advertisers, advertisements, and purchase orders. FIG. 9 illustrates entities 'advertiser', 'advertisement' and 'purchase order' in the context of certain embodiments. In the example shown in FIG. 9, a 'purchase order' is associated with the advertiser, even though it is typically the operator that will enter the purchase order (e.g., as a sales order for the system). In other embodiments, other relationships between the entities shown in FIGS. 5-12 may be used.

In some embodiments, information about the advertiser is typically entered into the system by the operator. In some embodiments, an interface may be exposed for a remote advertiser to register the remote advertiser in the system. The advertiser may place a purchase order for N advertising slots (of various types) for a particular feed. Note that when an advertiser places an order for an ad slot, the actual content item is typically unknown (e.g., ad slots are often sold prior to recording of the program). Advertisers typically decide to advertise on a particular channel based on the popularity, ranking, or general type of content served by the channel. In one embodiment, the selling price for the advertising slot is initially set to NULL and filled when order fulfillment occurs.

Referring to FIG. 9, in one embodiment, the advertiser has the following attributes: (1) ID (e.g., unique ED); (2) a name; (3) an address; (4) a billing address; and/or (5) contact information for one or more contacts. The advertising entities represent different types of advertisements (e.g., with some de-normalization for efficiency reasons). Advertisements are typically uploaded after the sell and reserve step of order fulfillment has occurred (e.g., if specifically advertised for a particular program/event); however, the advertiser may choose to pre-upload alternate advertisements. Thus, in one embodiment, the process of uploading advertisements may be unlinked from the order publishing and reservation steps during order fulfillment. The entered advertisements are input to the advertisement distribution step of the order fulfillment process. Thus, the advertisement distribution step uses the existing inventory of advertisements for each advertiser.

In one embodiment, advertisement 914 has the following attributes: (1) ID (e.g., unique ED); (2) advertisement _ id-id of the advertiser submitting this advertisement; (3) ad _ type _ i-type of advertisement (e.g., text, video + survey, banner, survey only, etc.); (4) ad details- (e.g., text, banner file URL, or video ad file URL); and (5) information about whether the advertisement is a backup advertisement (e.g., an advertisement that was placed if there was available space).

Order fulfillment entity

Advertisement reservation and advertisement distribution (assignment). FIG. 10 illustrates entities involved in order fulfillment in one embodiment. Each feed item is associated with a fixed number (e.g., up to 5) of ad slots 1010 that include an ad magazine for feed items of a particular type of advertisement. For example, the feed items 'Artist XYZ, Song # 2' may be associated with a text ad magazine, a banner ad magazine, and a video ad magazine. In this exemplary embodiment, each ad magazine will have five slots for five advertisements. The advertisement slots represent units of advertisement real estate for each feed item. The advertisements in each ad magazine are rotated, and the first advertisement is rotated in a cyclical manner in the feed so as to avoid favoring any particular advertisement in the ad magazine. The ad slots fill up with ads via an order fulfillment process. In one embodiment, order fulfillment occurs in two steps: (1) Reserve-Ads for advertisersReserving an advertising time slot; and (2) assigning (dispatching) -the actual mapping of advertisements to reserved advertisement slots.

In one embodiment, the ad purchase order begins in the 'new' state and undergoes 'reserve', 'allocate', and 'confirm' or 'cancel' states. In one embodiment, the purchase order may be cancelled at any time until the sale is confirmed, at which point it goes to a 'confirmed' state. In one embodiment, this function may be invoked manually (e.g., to confirm a purchase manually) or automatically (e.g., an order is confirmed automatically after an expiration date before becoming active through an expiration date, such as a feed, which may be enclosed in the system based on business rules).

Advertisement slot reservation

Order selection. During the reservation phase, advertisement slots are reserved. One or more purchase orders may be selected for order fulfillment. Multiple orders are typically selected at the end of the bidding process-in this case, the order fulfillment process sorts the bids by price (from high to low) and then continues to fulfill orders from top to bottom until all available slots are reserved. A single order may also be selected for order fulfillment-this use case is where the advertiser directly purchases advertising space at a full retail price.

Advertisement slot reservation. A very simple scheme for reservation may be to allocate time slots to all advertisers eligible for a particular feed in a round robin fashion until their orders are fulfilled (the unreserved time slots will later be filled from the standby ad library). When there are more constraints on reservations, the problem becomes one of the optimizations — the overall goal of the optimization is to maximize advertising revenue (e.g., leaving as few slots as possible unreserved).

Reservation constraints. In one embodiment, constraints on reservations fall into two categories: those related to the user and those related to the advertisement itself. In this documentIn (3), the first class of constraints is considered as 'target constraints' and the second class of constraints is referred to as 'adjacency constraints'.

Some examples of target constraints may include: (1) reserving advertising space targeted to a certain geographical, demographic, or dynamic user group rather than the general population; and (2) reserve advertising space targeted to certain age groups or income levels rather than the general population.

The adjacency constraint may include conditions such as: (1) requiring that advertisements for a particular advertiser appear at least X content items apart (e.g., to avoid user fatigue); (2) requiring that advertisements for advertisers occur no more than X content items apart (to ensure that the impression of the advertisement is not diluted in the user's mind); (3) requiring that banner advertisements for one advertiser never appear along with video advertisements for another advertiser (e.g., for a competitor); and (4) require that a certain banner and text advertisement appear together to reinforce each other. Note that the particular advertisement itself may be uploaded at a later date; however, in one embodiment, the constraint may be specified first at the reserved time, as it cannot be easily taken into account at the advertisement allocation time.

Specifying constraints. The user should be able to specify constraints in an unambiguous and easy manner to use the system efficiently. Constraints can be specified using a simple tagging mechanism that allows simple wildcards. For example, let us assume that an advertisement is tagged with some unique tag.

For example, V-ABC-XYZ-Ad23-Video Ad #23 is for advertiser XYZ from Advertising company ABC; and B-EFG-JKL-Ad35-Banner Ad #35 was used for advertiser JKL from the Advertising company EFG. When placing an ad space order line for an ABC-XYZ video ad, the constraint may be designated as 'a-JKL-a' to mean that the banner ad magazine for the content item may not contain ads from the advertiser JKL.

User library. End user, to theThe end-user system has made available alternative information fall into a certain library or target group. All other users are considered part of the non-target user pool. When an advertiser purchases non-targeted ad space, it attempts to reach the non-targeted repository. If advertising space is left in the target repository, then certain of those users (which are typically found later) may also be served non-targeted advertising, but this is not guaranteed. On the other hand, the target advertising space is specifically intended to reach the target audience that it seeks to reach. In a preferred embodiment, targeted advertisements are guaranteed to be served to users in the targeted group.

Advertisement time slot allocation. Advertisement slot allocation refers to the mapping of a particular advertisement from an advertiser to a slot reserved for the advertiser. In a preferred embodiment, the system should allow the following way to allocate advertisement slots: (1) automatic advertisement slot allocation: the system should be able to automatically generate the allocation; (2) manual editing of the allocation table should be allowed-this would allow the operator to manually adjust or fine tune the allocation; and (3) should allow import of allocation tables: this would allow the allocation schedule to be performed using external tools (e.g., a math library designed for this purpose) and the results can be imported into the system.

Advertisement selection. The advertiser may choose to select certain advertisements in the library for certain channels rather than for other channels. This is expected to affect a relatively small number of advertisements. For example, some advertisements are intended to be used only for special points or endings in a program and not for regular segmentations.

Coupons and location sensitive advertisements

FIG. 11 illustrates entities involved in coupons and location sensitive advertisements. Coupons 1110 may be categorized by type (e.g., 'food', 'sports', 'footwear', 'gift', etc.). A coupon-providing local advertisement can be created for a particular geographic location by providing coordinates and an effective radius. Descriptive attributes for location-sensitive advertisements refer to text that is displayed to a user in a pop-up window to display a location-sensitive advertisement while being served. If the user confirms that he or she wants to see the advertisement, the corresponding coupon is displayed by the application. Otherwise, the location sensitive ad pop-up window is eliminated.

Raw statistical data

FIG. 12 illustrates how raw statistics are collected according to some embodiments. Event records 1210 for different event types (e.g., play, stop, skip, vote, survey, advertisement rotation) and related event data (e.g., items selected in a survey submission event) are recorded as part of the event data. Content download events are also recorded and this data is collected and uploaded to a database. The raw statistics are analyzed and correlated with demographics to derive inferences about user behavior and preferences. Currently, content services typically measure ad impressions only by counting the number of downloads from the server side. Embodiments of the systems and methods described herein may provide better metrics by measuring the actual viewing of advertisements by clients. For example, if an advertisement for a feed item starts with Ad #3 in an Ad magazine with 5 advertisements, and the advertisement rotation event counts 6 rotations, we can conclude that Ad #3 is displayed twice and all other advertisements are displayed once.

Illustrative user interface screen

Basic screen layout. FIG. 13 illustrates a basic three-layer layout in accordance with one embodiment. The left (tree) panel 1310 provides access to the primary function. Each tree node opens to display a separate item in the category. Selecting a function group/item changes the contents of the search panel and the detail panel. The content of the search panel 1320 changes based on what is currently being displayed on the detail panel. The detail panel 1330 displays a form for executing the selected function item/function group.

User management. FIG. 14 is an illustrative interface 1410 for performing user management, in accordance with some embodiments.

Advertisement management

Advertisement management sub-item. Fig. 15, 16, and 18 show illustrative interfaces for advertisers, advertisements, and advertisement purchase orders, respectively, according to some embodiments. In one embodiment, the 'advertising management' node in the tree panel in FIG. 13 has the following child nodes: an advertiser (see, e.g., interface 1510 in FIG. 15); advertisements (see, e.g., interface 1610 in FIG. 16); and an ad purchase order (see, e.g., interface 1710 in fig. 17).

Advertising. Referring to the illustrative embodiment shown in FIG. 16, the advertisement details block 1620 content is a function of radio button selections for advertisement types. If there are still any advertisement slots that are unfilled (e.g., advertisements that will be billed at the lowest advertising space price), then when an advertisement is to be used for order fulfillment, a 'standby advertisement' block 1630 is checked; (3) the 'tag' box 1640 is a user-provided unique ID for the ad (e.g., mandatory if it is a survey ad) or for use in performing constraints on ad space reservation/allocation; (4) when the 'text advertisement' radio button is selected, the box displays a text area to enter a text advertisement; (5) for video advertisements, the box displays the following: a text box that will enter the video URL, a file selection button next to it (e.g., a button that displays a file selection dialog), and a drop-down box that will select the survey ad to associate with this video ad; (6) for banner advertisements, the box displays the following: a text box to which the URL is to be input, and a file selection button next to it (e.g., a button to display a file selection dialog); (7) for a survey ad, the box displays the following: a text box where survey questions are to be entered, a radio button with an option to select a survey type (e.g., radio button based or check box based), and a grid where survey items are to be entered.

Advertisement purchase order sheet. Referring to FIG. 17, a purchase order screen 1710 allows an advertiser(s) ((R))Or an operator who enters data for an advertiser) enters a purchase order for an advertisement slot. A purchase order may be placed for one or more feeds in a single channel or multiple channels. Targeting block 1720 allows the user to select the type of targeting. The adjacency constraint block 1730 may be used to specify an adjacency constraint (e.g., how far apart the advertiser wants its advertisements to be spaced). The purchase order list grid 1740 enables a purchaser to place an order having a plurality of items. The adj. Tag column in the purchase order list 1740 may be used to specify a constraint for holding two advertisements together (e.g., a text advertisement and a banner advertisement will be displayed together — they are at the same location in an ad magazine). In one embodiment, text and banner advertisements, for example, may rotate faster than video advertisements, and thus linking a video advertisement to a text advertisement will only guarantee that it goes to the same feed item; however, the advertisements may not always be displayed together.

Content management

Content management sub-item. In one embodiment, the 'content management' node in the tree panel of FIG. 13 has the following child nodes: (1) a content provider; (2) content; (3) a channel; and (4) feeding.

Content provider. Fig. 18 shows an illustrative content provider screen 1810.

FIG. 19 illustrates a channel interface screen 1910 according to some embodiments.

FIG. 20 illustrates a feed interface screen 2010 in accordance with some embodiments.

Order fulfillment

FIG. 21 illustrates a reservation interface screen 2110 in accordance with some embodiments. Note that one or more purchase orders may be selected for reservation. In one embodiment, if more than one purchase order is selected, the orders are sorted by bid price and fulfilled in this sequence.

Fig. 22 illustrates an assignment interface screen 2210, in accordance with some embodiments. Ad exclusion panel 2212 allows exclusion of certain ads for allocation (e.g., exclusion of ads that will only be used for special spots or the end of the season). If the requirement is to select an advertisement rather than excluding an advertisement for distribution, screen layout 2210 may be changed. The allocation may be made in one or more passes (e.g., one pass for each advertiser, one pass for each purchase order, etc.). As long as there is a reservation, it can be filled in many passes. When the last pass is being performed (e.g., if the check box indicating that it was last assigned is checked), then any remaining slots should be filled with the alternate advertisements.

FIG. 23 illustrates a modify assignment interface screen 2310 according to some embodiments. Screen 2310 allows a user to manually adjust advertisement distribution. The user will be allowed to override the allocation. If the user's selection violates the constraints used in the reservation, a warning will be displayed to him, but the option to proceed and save the change will still be given.

According to some embodiments, the ad space allocation may be calculated using an external math library, and the results of the allocation may then be imported directly into the system.

Fig. 24 illustrates a coupon interface screen 2410 according to some embodiments.

FIG. 25 illustrates a location advertisement interface screen 2510 according to some embodiments.

Reporting and analysis

Reports for advertisers. According to some embodiments, the following are examples of report types for advertisers: (1) impressions for the advertisement (e.g., number of views) (e.g., how many times the advertisement is actually displayed to the user). Graphs may be broken down by age, gender, input, geographic location, marital status, etc.; (2) download times-how many times an advertisement is actually downloaded; (3) number of survey responses per 1000 views of advertisement-how many viewsThe viewer responds to the survey; (4) survey response frequency histogram-how responders respond to survey question X; and (5) location sensitive advertising viewing-location sensitive advertising television viewer data (e.g., with numbers broken down by gender, income level, age, etc.).

Data analysis report. According to some embodiments, the following are examples of data analysis report types: (1) user activity-in one embodiment, this will provide a chart of active users broken down by age, gender, income level, location, or dynamic cohort. User activity is measured as a percentage of the feed viewed by the user. For example, in one embodiment, a 50% active user is a user who sees half of the feed downloaded to their mobile phone. Examples include activities by age, gender, income level, region, and dynamic cohort; (2) television audience measurement-the number of users viewing a particular channel, feed, or content item. Examples include viewers per channel, feed, content item, and content tag; and (3) viewing habits-e.g., what the user is currently watching. Examples include percentage share per channel by user, region, age, and gender.

Advertisement reservation example

To further illustrate certain embodiments, examples are given of using an external math library for the reservation of advertisement slots for a given slot. In this example, the reservation problem for a typical hop for a channel is described. An explanation is given of using AMPL to build a mathematical model for this problem. The use of a suitable solver to solve the problem and a brief explanation of the results is given.

Description of the problems. Assume that a feed for a particular channel (weekly episode) has 10 content items. Each content item is associated with five advertisements of each type (e.g., text advertisements, banner advertisements, and video advertisements), thereby creating space for 50 text advertisements, 50 banner advertisements, and 50 video advertisements。

Tables 2-4 show data for non-targeted advertising. The orders are sorted by price.

The mechanism for describing and solving is substantially similar for targeted ad space orders. In the case of a target order, the order will first be sorted into a list containing orders with the same target group. The allocation process is still the same thereafter.

Let us assume that the alternate advertising costs for video, banner, and text advertisements are $1000, $200, and $100 per slot, respectively.

Table 2: video advertisement

As shown in Table 2, ABC corporation has issued bids for five slots for ABC-ZZZ video advertisements and only wants to have a slot if an advertisement for TUV corporation will not appear with it; ABC corporation has another bid for 3 slots for ABC-F advertisements; the constraint is that the advertisement is not paired with a text or banner advertisement for company T; EFG has a bid for 20 slots with a minimum ad distance of 2; EFG has another bid for 10 slots with no constraints; and XYZ and QRS have issued unlimited bids for 7 and 15 slots, respectively.

Banner advertisement

Table 3: banner advertisement

As shown in table 3: ABC corporation has issued bids for the 20 slots for ABC-TUV banner advertisements and wants to ensure that these never pair with the video advertisements for ZZZ corporation; EFG corporation has issued bids for 10 slots for TM corporation banner advertisements that are not constrained; and EFG, XYZ, and QRS have other bids for unconstrained banner advertisements.

Table 4: text advertisement

As shown in table 4: ABC corporation has issued bids for 30 slots for PEP text advertisements and 10 TM text advertisements; and (2) EFG, XYZ, and QRS have bids for unconstrained text advertisements.

The goal of the allocation is to maximize the total advertising revenue from all three types of advertisements.

And (5) constructing a model. The following is an illustrative description of the problem and its expression in a modeling language called "modeling language for mathematical programming" (AMPL). In modeling this illustrative ad space reservation example, the description includes expression sets, parameters, variables, objective functions, and constraints.

And (4) collecting. There are two sets in the ad space: (1) a set of content items with which an ad magazine (of a particular type) is associated; and (2) a set of n slots in an ad magazine. This can be written as AMPL notation as follows:

parameter(s). The parameters participating in the problem are:

# - - -parameters for advertisement space reservation- -

Variables of. The ad space allocation for each video/banner/text ad may be modeled using a 10 x 5 matrix as the binary number of the allocation map. If the value of the element is 1, a time slot is allocated for the video/banner/text advertisement. Otherwise, no time slot is allocated for the advertisement. There are variables in the allocation problem.

Another set of variables is the selling price for the time slot determined as a result of the allocation. However, this variable can only take a fixed set of values (e.g., selling price is the tender price for the lowest price bid accepted).

The problem is easier to solve if these variables are converted into parameters. The question may then be broken down into a simpler set of questions, and a global maximum may be obtained by selecting the question whose combination of parameters provides the highest advertising revenue.

# price per time slot (assessed as a result of evaluating bids for time slots)

The number of unsold slots for video/banner/text advertisements is another variable in the problem. These may be constraints on it (e.g., a certain number of slots must be kept free for public service advertising). In this example, assume that the number of unsold slots is a parameter, having a value of zero.

Objective function. The goal of the process is to maximize the sum of advertising revenue from all three types of advertising space offerings. This is our objective function. This can be expressed as follows:

constraining. The solution is constrained by the following constraints:

1. a slot in the ad magazine may be reserved for only one order.

2. Constraints on mutual exclusion for advertisements.

3. Distance constraint-distance constraints are similarly specified using an allocation map for distance to the applied advertisements.

4. Subscription volume-a limit is imposed on the allocation by the volume subscribed for each type of ad space. These constraints are modeled as follows:

solving a problem. Available tools-numerical methods in the "branch and bound" category are most effective for problems involving integer variables similar to those described above. It is important to formulate the objective function and constraints as linear constraints, since the numerical method for the integer problem of the nonlinear constraint/nonlinear objective function is not very well developed. Numerical techniques for linearity problems are well developed and these algorithms converge fairly quickly.

For the non-linearity problem, most of the techniques used consist of variations of the basic newton method. Since these methods use derivatives, the solver should relax the integrity of the variables during the calculation. The result obtained is therefore in real space and may require some post-processing (rounding, etc.) for interpretation. Post-processing can move the solution very far from the calculated optimal value. Therefore, sensitivity analysis should be performed on the solution. Because of all these difficulties, it is useful to formulate the problem using linear constraints.

Selection of solver-the solver for this exemplary problem is the CBC solver available under CPL (http:// www.coin-or. org/Cbc/CBC user guide. html). The CBC solver was manipulated by NEOS (http:// neos.mcs.anl.gov/NEOS/solvents/mil: Cbc/ampl.html). This solver is used to solve the exemplary problem.

Results. Tables 5-7 below summarize the results for video advertisements, banner advertisements and text advertisements in this example.

Table 5: video advertisement reservation table

The following results for video advertisements are obtained: (ABC 1) ═ 5; sum (ABC 2) ═ 3; and sum (EFG 1) ═ 4, only 4 are reserved points due to distance constraints; sum (EFG 2) ═ 10; sum (XYZ 1) ═ 7; and sum (QRS 1) ═ 15. Note that some slots are unfilled because all purchase orders have been filled (constrained). In the preferred embodiment, these will be filled with "spare" video advertisements.

Table 6: banner just works out reservation table

The exclusivity of the TUV banner with ZZZ video advertisement can be seen from the above table. In this example, no constraint is imposed that favors higher price bids over lower price bids. Thus, ABC1 is not given more time slots than other banner advertisements. This can be fixed by adding more stringent constraints in the model.

Table 7: text advertisement reservation table

Model identification system and method

Mobile content services that support advertising will typically identify mobile devices while uploading usage statistics to backend services. One way is for the mobile application to probe the mobile device itself for identifying properties. However, the mobile device identifier is not uniformly available to applications on all mobile devices, and in many cases, the number (if available) may not be unique.

For example, on a mobile phone, there are identifying properties such as IMEI (international mobile equipment identity) or MEID (mobile equipment identifier) for the mobile phone. However, these properties are not uniformly available across all mobile devices. Furthermore, different IMEI numbers may be burned into the mobile device. Since the IMEI was originally designed to identify and blacklist stolen equipment, equipment thieves typically involved cloning the IMEI of a legitimate phone into the stolen equipment. According to some industry estimates, about 10% of the IMEI number is not unique. In the case of mobile phones, IMSI (international mobile subscriber identity) is a more "sticky" identifier for mobile consumers, since it follows the subscriber even when the subscriber changes/upgrades his mobile equipment. However, IMSIs are generally not available for mobile applications and do not exist for other mobile devices.

Therefore, there is a need to provide a mobile identity for a mobile device. In the case of mobile phones, it is preferable if the mobile identity can be associated with the IMSI number for the mobile phone, since the IMSI is more tightly tethered to the mobile consumer. However, there should preferably be a balance between the need for mobile identity and the need to protect the privacy of the consumer. To some extent, the requirements for mobile identity are determined by the cultural customs of the venue. For example, in certain cultures, it may be acceptable to assign a unique identifier to a mobile device as long as the unique identifier is not directly identified with a natural person (e.g., an anonymous identifier of a person cannot be tracked). In some cases, it may be acceptable for the back-end service to personally identify the consumer, as long as the service has to make the data anonymous (e.g., aggregated reports of usage statistics, statistics broken down by category of user, etc.) as it exposes any aggregated or non-aggregated information to external third parties for its business. In some other locations, it may not be acceptable to assign a unique identifier to a mobile device. The identifier may need to be some kind of group identifier (e.g., an identifier that identifies the user as belonging to a geographic area, user category, age group, etc.). The classification of the user may be made using actual data (e.g., inferring a geographic area from an IP address) or using user-provided information (e.g., answering survey questions provided by the user, information voluntarily provided by the user during signing, etc.). The classification of the user may be dynamic and may potentially change over time based on the user's response to the survey questions.

In one embodiment, the back-end service provides its consumers (advertisers, content providers, content aggregators) with a trusted and accurate assurance that the usage data they collect and report. This may be achieved, for example, by using a secret key to sign the usage data. A simple mechanism to provide a mobile client with a secret key is to have the secret baked in (e.g., permanently or semi-permanently installed at the application manufacturer or downloaded/installed). However, the roast-in secret will not necessarily be unique, as users often copy mobile applications from one device to another. Also, it is preferable that the backend service and the mobile device agree on the secret key rather than trust in the roast-in secret, since over time even the best tamper resistance can be destroyed and the secret key will become known. In this context, diversification will provide some help. Diversification of client applications is valuable, independent of any other factors; however, practical considerations often limit the total number of different mobile application binaries.

A constraint on many mobile devices is that they are only intermittently connected to a public network. If no network connection exists, conventional protocols such as TLS that rely on network connections for devices to obtain unique personalities/identities from the backend cannot be used.

Embodiments of the systems and methods described herein address some or all of these issues.

Figures 26a and 26b are flow diagrams illustrating steps for a mobile content service to provide an appropriate mobile identity and protect/verify usage data, according to some embodiments. The mobile client is only intermittently connected to the network. In step 2610, the mobile client may be tethered to a PC in USB mass storage mode or may be connected directly to the network when it is connected. In step 2614, if the mobile device is tethered to a PC in mass storage mode, the mobile application cannot talk directly to the server over the network. In this case, the mobile application will store the authored message at a well-known location in the mobile device file system. In step 2616, a message is delivered to the backend service on behalf of the mobile device by the PC synchronization application running on the tethered PC the next time a PC synchronization operation occurs. The server's response will similarly be stored in the mobile device's file system. The next time the mobile device runs it will read the server response and will author the message and store it in the file system for the server (to be delivered by the PC synchronization application when it next happens). Thus, the file system location on the mobile device functions like a drop-down box. In step 2612, protocol messages may be exchanged directly between the mobile client and the server if the mobile device is capable of and directly connected to the network. In step 2618, the mobile client generates a new key Ks for signing/encrypting the usage data and stores it locally in encrypted form using Ks sharing as a bake-in shared key. Tamper resistance is used to protect the roast-in secret in the mobile device. In step 2620, the mobile client selects p, g and selects the random number 'a'. It remembers 'a' by storing it in its own secure storage in encrypted form. In step 2622, the client computes a ═ g ^ a mod p; and author a first message M1 (client- > server) containing:

M1＝Enc（Ks-share、nonce| p | g | A | Ks-share-ID |“m1.dat”）

Ks-share-ID (ID for Ks sharing)

32-bit random number

p-public key of personality node baked into mobile client

g-is usually chosen to be 5

a is at least 100 bits long random number

In step 2624, if the mobile client is connected to the network using the USB mass storage mode, it may not be able to send a message by itself. In this case it will store the authored message at a well known location on the file system of the mobile device. If the mobile client is connected directly to the network, it may send this message directly to the backend service. In step 2626, when the mobile device is connected to the network, M1 is sent to the server side (either by the device itself or by the tethered PC). In step 2630, the server side selects the secret integer B and computes B ═ g ^ B mod p. It computes Diffie Hellman ("DH") secret keys using Kdh = a ^ b mod p = (g ^ a mod p) ^ b mod p = g ^ ab mod p. It generates a mobile identifier mobile id as a unique identifier or group identifier, and it then calculates the following response S2 sent to the client in step 2631:

the server will also store locally (mobile identifier Kdh, random number) for future use. Usage data (if any) is also uploaded at this time-the data is signed and/or encrypted with Ks usage. At this point, the Ks usage is unknown to the server, but it will only store the data as having originated from the mobile identifier.

In step 2632, if the mobile application has directly connected to the server, it may respond to the message with M2. In step 2624, if the mobile device is not directly connected to the network, but simply does so by being tethered to a connected PC in mass storage mode, it may not be able to respond to the server immediately, but will do so the next time the mobile application is running. Here, it can calculate Kdh and check the data in S2. If the data is not validated, it aborts the transaction and the process begins anew. If the data validates, it knows it has agreed with the server side pair Kdh. It will author the third and last message M3 with the following data.

In step 2636, when it receives M3, the server side may re-check M1, S2 (if it is an tethered device) and check if the stored values (mobile identifier, Kdh, random number) match. Next, it uses Kdh to decrypt M3 and obtain the Ks usage. In step 2638, it will store Ks locally in the tuple using:

here, a transaction for providing a mobile identity is completed. In step 2640, if the process fails at any point, either side may abort the transaction. The transaction may be resumed the next time the mobile client connects. In step 2642, if the mobile client aborts the transaction: it deletes the file (if the message is stored as a file-as in the case of tethered mobile devices) and restarts the process. In step 2644, if the server-side abandons the transaction: it deletes the file (if the message is stored as a file-as in the case of a tethered mobile device or indicating that it has relinquished the transaction to provide the client with a mobile identity if the client is directly connected to it) and skips/relinquishes the data upload. The mobile client then begins the process when it next gets a chance to do so.

The backend server may choose to use the group identifier instead of the unique identifier based on local cultural requirements. This group identifier may be selected based on actual data (e.g., a group of geographical areas selected based on the IP address of the sync PC/mobile client), or may be user-selected (directly or indirectly based on the user's response to survey questions or data provided by the user at the time of signing).

The group identifier of a user may change over time based on their survey response that they send back to the service. The server may "drop" from the unique identifier to the group identifier after sampling the user's response for a period of time to infer the user's classification group. Another solution is a periodic process of "updating" of the mobile identity to obtain assurance that the mobile device continues to be a valid client of the service. In these cases, the server may force the client to do a transaction again for obtaining the new mobile identifier. The mobile client will report back to the server the old and new mobile identifiers as part of the usage data to associate the old identifier with the new identifier. If the mobile device is a mobile phone, it may also send a return old/new identifier to the service backend via an SMS channel, which, in addition to correlating these two identifiers, enables the backend service to associate the IMSI number with the mobile identifier if appropriate for that location.

Thus, a protocol such as that described above may operate within the constraints of an intermittently connected mobile device, even when the mobile client application is not directly connected to the backend service.

The client generates a secret key for signing the usage data. In one embodiment, this secret key is never stored explicitly, but in encrypted form using the bake-in secret key. The mobile application has tamper resistance applied to it to protect the roast-in secret key.

The client and the backend service perform a Diffie-Hellman key exchange to agree on a key to use to communicate a secret key that signs usage data from the mobile client to the backend service. The secret key agreed upon using DH is used to encrypt the secret key while it is transmitted to the backend service. In one embodiment, this key is never reused.

The server provides the mobile device identifier on the mobile device as part of the protocol. The identifier provided by the server is signed with a PKI signature using the private key of the back-end service.

The mobile client checks the PKI signature on the identifier provided by the server to ensure that it has obtained the identifier from a trusted service.

The server provides the mobile identity while it is participating in the Diffie Hellman key exchange. This allows the mobile identity to be acquired by exchanging three message steps. (Mobile- > Server [ M1], Server- > Mobile [ S2], Mobile- > Server [ M3]).

Methods for identity/personalization of mobile clients are described herein. In the context of systems and methods such as those described above, it may be desirable to personalize a mobile client and provide it with a unique identity by the server side. The mobile client may use this identifier to submit usage statistics to the server. For example, advertising-enabled mobile content services may need to provide guarantees to their consumers (advertisers, content providers, and aggregators) that their provided usage statistics are accurate and reliable, and content services may need to use the appropriate mobile identifier to collect usage data and the data may need to be signed (and optionally encrypted) by the mobile client application. The mobile identifier may be a unique identifier or a group identifier based on cultural habits and local requirements. Embodiments of the systems and methods described herein enable mobile content services to provide appropriate mobile identities and protect/verify usage data in order to achieve these goals.

The following description is organized as follows: (1) mobile client identity-this section describes attributes that can be used for mobile client identities; (2) personalization requirements and constraints-this section deals with personalization requirements and constraints that appear on mobile handsets in various embodiments; and (3) methods of personalization-this section describes methods for personalization in certain embodiments.

Table 8 shows various abbreviations used in this detailed description

Table 8: abbreviations

As used in this detailed description, the term "personalization" refers to the process of assigning a unique identifier to a mobile handset, and the term "personalization" refers to the process of assigning a unique DRM personality to a device in a DRM system such as that described in the' 693 application.

Mobile client identity

In a preferred embodiment, the server side needs to uniquely identify the mobile handset in order to record usage statistics for each unique handset. In one embodiment, the requirement is simply that each handset be uniquely identifiable by the server side. This unique identifier may be obtained by probing the client. Identities can also be assigned to the handset by the server side or generated using input from the client and server. It is also contemplated that the identifier may be associated with an IMSI number (as described below).

IMEI

The first place to look for a unique identifier would be the mobile phone itself. This section describes attributes that can be detected from the environment available on the mobile client and can be used to identify the handset.

In GSM and UMTS networks, the IMEI or its latest variant IMEI/SV is used to uniquely identify the handset hardware. As shown in table 9, the IMEI consists of a 14 digit number followed by a one-digit Luhn check digit code.

Table 9: luhn check bit code

In addition to the 14 digit IMEI, the IMEI/SV also uses a two digit software version. The original purpose of having an IMEI is to track and blacklist stolen handsets. However, a different IMEI number may be burned into a stolen handset. According to some estimates, as a result of doing so, about 10% of the IMEI number is not unique.

MEID

CDMA networks use an identifier called MEID similar to a 14-digit IMEI (except that the digits are hexadecimal). The MEID is created to replace the 32-bit FCC ESN code that is close to being used up.

IMEI/MEID probing via J2ME

IMEI/ME can be probed on a mobile phone using system propertiesIAnd D number. Unfortunately, not all phones support this property, and the name of the property changes on handsets manufactured by different manufacturers. An example is shown in table 10.

Table 10: system Properties for IMEI

The support of this property by nokia has been slow. This property is only available when the application is signed by the manufacturer/operator on the S40 platform. At S60, no special signature is required, but this property is only supported on the S60 third edition device. See, for example, http:// wiki. forum. nokia. com/index. php/How _ to _ get _ IMEI _ in _ Java _ ME.

Finally, the IMEI/MEID is not uniformly available and is not guaranteed to be unique. Thus, the mobile phone client cannot rely on the use of IMEI/MEID for the mobile client identity, although it may be part of the "obfuscation identifier".

IMSI

IMSI can be used for identity because it most closely identifies mobile consumers. The IMSI is represented by: (1) mobile Country Code (MCC); (2) a Mobile Network Code (MNC); and (3) a Mobile Subscriber Identification Number (MSIN).

In GSM networks, the IMSI is linked to the SIM card and follows the subscriber even when the handset is changed. With mobile phone number portability, the IMSI number has become a more "sticky" identifier that identifies mobile consumers very closely.

The opposite example is the use of a prepaid SIM card. Users of these SIM cards tend to discard the SIM card and activate a new SIM card once the minutes are exhausted. In this usage scenario, the user does not mind the inconvenience of changing the telephone number. Such use is considered far less frequent and the IMSI is in principle a very good identifier for mobile consumers.

Personalized requirements and constraints

More details of mobile client personalization and certain constraints that may be encountered on a mobile phone platform will now be provided.

Limited/unreliable network connection

By definition, CLDC means a restricted connection. In practice, network connectivity is even more challenging. Currently, internet connections for mobile phones are limited, slow, unreliable, and very expensive.

Data connection via a radio network of a bearer

The data connection through the radio network of the bearer is often slow (typically 56Kbps for GPRS) and this reaches 236.8 Kbps for EDGE (although fewer handsets support EDGE).

Data connections over the radio network of the bearer are expensive. Many consumers do not have data plans for this reason. The price does not drop so much in a less competitive market, and subscriber flow (subscriber churn) is limited due to service contracts. Another factor is that access to the internet is via a WAP gateway that effectively makes it the bearer of the walled garden.

High speed 3G networks currently differ in markets like india by at least one or two years. For these reasons, it cannot be assumed that a data connection via the bearer's radio network is present for the mobile device. Where present, it can be very slow and somewhat carrier controlled.

WLAN connection

WLAN connectivity via Wi-Fi or Wi-Fi with WiMAX interconnection between wireless hotspots may be another option for wireless devices. The problem with having a WLAN connection for mobile phones is that it is not available everywhere and not all handsets have radios that support WLAN connections. Using a WLAN connection typically requires the user to enter a passkey/password, and this can be difficult on a typical telephone keypad, although many phones allow you to store connection information so that one does not need to repeatedly enter it. However, if a person is mobile and moves between many hotspots, this can be cumbersome to use unless there is a city Wi-Fi network that covers the entire region anywhere with the same master key.

Impact on personalization/personalization

In summary, given the current technology, personalization of the mobile client preferably needs to occur when the mobile client is tethered to a PC, since mobile network connectivity is very limited/unreliable.

In some DRM systems, the client is pre-personalizedHuman beingIs customized/pre-registered because it may never be directly connected to the network. This is typically done using a personality node (P) + serving user node (U) + P + baked into the client application>U link. The DRM license will be bound and directed to the service user node. After the client application is installed, it needs to be personalized.

Limited secure storage

Secure storage is typically one of the requirements of the DRM client. DRM clients often require secure storage to store secrets.

The storage is secured by encrypting it (especially if it is stored in a public location). Having a private storage location that is only accessible to the application is more preferable because it cannot be obtained by running code in a debugger or in a virtual machine. This is a fairly secure solution if the private location cannot be accessed without physically tampering with the device and debugging on the device is not possible.

Two possibilities for secure storage of the J2ME application client are:

1. private location in the file system: each MIDP application can access a private location in the file system indicated by the system property, "file. However, this property is not uniformly supported across all devices. For example, the S60 device supports this property, but the S40 device does not support it. Vendor support for this property needs to be identified by the manufacturer/model number. Also, on some phones (e.g., sony ericsson), the file system location is not "private," but can be seen by the USB host when the mobile phone is installed in USB mass storage mode. This may therefore not be a very viable option for mobile phones.

2. Using a private record library of RMS (record management system): RMS is currently considered to be supported on all MIDP phones. The records are stored in a binary format specific to each manufacturer. The J2ME applications are signed and they are identified by a (signature) hash that is unique to each application. The J2ME JVM only allows the J2ME application to access the library of records that it creates and marks as private. To encroach on the RMS, an attacker would need to circumvent JVM security and/or locate and decode binary RMS data. Thus, the use of a private record repository should be fairly secure. RMS is widely available and may be suitable for use as secure storage. However, according to the MIDP specification, embodiments are only required to provide a minimum of 8 kbytes of RMS storage. Therefore, RMS storage is very limited on some devices.

Diverse (non-globally unique) clients

One way to handle personalization may be to assign a unique personality node to each application binary that has been installed. However, this may not be practical in many cases, as it typically requires the server side to edit a very large number of client application binaries. Also, users often copy binaries from one cell phone to another, and relying on the baked-in personality for the unique identifier may not be sufficient. Thus, in some preferred embodiments, the client application is diverse rather than globally unique.

SMS is secure but short

The SMS backhaul channel is a secure path with guaranteed delivery (within certain limits). However, the payload size for an SMS PDU is very short (140 8-bit bytes). Multi-part messages are possible, but SMS incurs costs to the user and should preferably be used relatively sparingly.

Client synchronization or application execution may occur first

The mobile client may run before or after the first PC synchronization operation. This means that the personalization protocol should work no matter what event happens first. The sequence may be:

1）

mobile client operation

First PC synchronization

Mobile client operation

…

Or

2）

First PC synchronization

Mobile client operation

-second PC synchronization

…

Usage data reporting requirements

The client application will typically need to ensure that the usage data reported back to the server is reliable and accurate. In one embodiment, the client is pre-personalized. However, in a preferred embodiment, these bake-in personalities are not used separately to encrypt or sign usage data.

Personalization method

In some embodiments, each client begins by burning in a shared personalized secret. This shared personalized secret is used to bootstrap the client into a personalized client. Once personalization occurs, the client obtains a unique personality. Each client then obtains the node, link, and license. The license is bound and/or directed to the acquired personality/user node.

The personalization protocol obtains the secret key using the session key and encrypting the session key using only the secret key to minimize plain text and cipher text attacks. Random numbers are also used to prevent message change attacks. The shared secret is diversified, so reverse engineering of clients will not prevent all clients from being personalized (only one set of clients will be affected due to the "blacklist"). However, in practice, detecting that a particular shared secret is compromised due to reverse engineering of the client will typically be difficult to determine, and blacklisting certain un-personalized clients will be difficult.

The preferred embodiment of the client application described above will typically need to be pre-personalized with a fixed (but diverse) set of personalization nodes and a single common user node (serving node). Licenses in content are typically bound and directed to a service node. The controller in the DRM license is signed by the license server using PKI. The client application verifies this signature and uses the metering obligation in the license to meter the usage. PKI signatures ensure that a client meters items that a server requires it to meter.

Client applications also typically need to ensure that their reported back usage data is reliable and accurate. For example, in a preferred embodiment, it requires signing/encrypting the data using a different key than the bake-in secret similar in location to the shared secret in traditional personalization.

In a preferred embodiment, the method for personalizing a protocol is: (1) no bake-in secrets are used for signing/encryption of usage data; (2) generating and storing a signing key on the client in a secure memory (running an application outside the device will not access the secret key); (3) using the DH key exchange with server authentication to agree on a secret DH key that is used to send a signing key to the server; and (4) the server generates and places a GUID on the client as part of the DH exchange.

DH key exchange with server authentication

The client application and server side will be able to agree on a shared secret key via a Diffie Hellman key exchange.

The mobile client runs first

Figure 27 is a flow chart illustrating steps for a mobile content service to provide an appropriate mobile identity and protect/verify usage data, according to some embodiments. In particular, fig. 27 shows the steps in the case where the mobile client is running before the first synchronization occurs. In step 2710, the mobile client generates a new key Ks usage for signing/encrypting usage data and stores in secure memory:

wherein Enc means encryption using AES CBC mode

Ks-share is a Scuba shared symmetric key for 8pus personality nodes

random-length is the length of the random byte (between 0 and 16 bytes)

random-bytes are random byte arrays of random length

Note that in some cases it may be useful to store the fuzzy fingerprint parameters here. According to one embodiment, the hash (FP parameter) is transmitted to the server and included in the signature computation for the usage data. This serves to provide some assurance that the same client involved in personalization is the client that generated the usage data.

In step 2712, the mobile client selects p, g and selects secret a. In step 2714, the mobile client computes a ═ g ^ a mod p; and stores p, g and a at fixed locations in a file system (m 1. dat) containing:

Ks-share-ID-ID for Ks sharing

Nonce is 32-bit random number

It will also store the same value in secure memory. In step 2716, the PC client transmits m1.dat to the server side upon PC synchronization. In step 2718, the server side selects the secret integer B and computes B ═ g ^ B mod p. It calculates a DH secret key using Kdh ^ a ^ b mod p ^ g ^ ab mod p. In step 2720, the server side generates a GUID, and it then calculates in step 2721 the following items that are sent to the client as S2:

and stores the following items in s2.dat

The server will also store (guid, Kdh, nonce) for future use. At step 2722, the usage data (if any) is uploaded-the data is signed and/or encrypted with Ks usage. At this point, the Ks usage is unknown to the server, but it will only store data for the guid. The next time the mobile application runs, it can calculate Kdh and check the data in s2. dat. If the data is not confirmed, it deletes ml.dat, s2.dat and the process restarts completely. If the data validates, it knows it has agreed with the server side pair Kdh. It stores m3.dat together with the following data:

at the next PC synchronization, the server side may re-check ml.dat, s2.dat and check if the stored values (guid, Kdh, nonce) match at step 2724. Next, at step 2726, it may use Kdh to decrypt m2.dat and obtain Ks for use. It will then store the Ks usage in a tuple (Ks-usage, guid, Kdh, nonce).

Here, the personalization process is completed. If the process fails at any point, the following happens: (1) if the mobile client aborts the transaction: it deletes the file and restarts the process; and (2) if the server side abandons the transaction: it deletes the file and skips the data upload. The mobile client starts the process on its next run.

PC synchronization occurs first

If PC synchronization occurs first, there is no usage data to upload and nothing happens. The process begins when the mobile application is first run.

Using data signing/encryption

The usage data will be signed with the Ks-usage and the signature will be encrypted using the Ks-share in each data payload. During synchronization, PC clients post (ml.dat, s2.dat, m2.dat and usage data). The data may be verified and accepted after verification (offline asynchronously during data upload). In some embodiments, the usage data may be encrypted.

Updating

The server may force re-personalization to be performed only as part of the standard operating procedure by deleting cookies (m 1.dat, s2.dat, m3. dat) if Kdh or Ks-use are compromised for any reason or periodically.

In some embodiments, the call home message may be forced at update time. In other embodiments, we may skip the call home message if the old guid is linked with the new guid and the update is a periodic update (not because the key is compromised).

Reverse engineering of clients

Reverse engineering of the client and disclosure of the secret key can be quite difficult to detect.

Clients that submit spam to the server side can be cloned using compromised clients. To protect against this possibility, a sanity check may be performed on the uploaded data and the compromised client may be forced to update and/or the data may be disregarded. Compromised clients may also be avoided (e.g., content updates are not provided to compromised clients).

IMSI and GUID correlation (Call Home message)

After the personalization procedure is completed, the client application may send an SMS message (call home message) containing the GUID to the server side, possibly obfuscating the hash of the fingerprint parameters. The IMSI number may be associated with the GUID using envelope information of the SMS message.

If we obtain demographic or other data about the subscriber from other sources where the IMSI might be used to identify the subscriber, we can use the correlation between the IMSI and the GUID to correlate the usage data with the demographic data and better reason around/better target the advertisement.

Management model。

An example for a management model will now be described. The content item contains a DRM license that includes usage rules that specify what usage data is to be collected. For example, usage rules may include: (1) what events must be logged; (2) whether to display a survey to the user; and (3) how often the return data must be sent.

The client follows a management model-which takes into account the rights and obligations specified in the DRM license. The mobile client signs the collected usage data and protects the integrity of this data. The return data is sent at the earliest opportunity. This can occur in two ways: (1) when the PC is synchronized: when the user synchronizes his mobile phone with the PC, this usage data is transmitted back to the service backend. Data may optionally be encrypted for privacy; and (2) alternatively, the return data may be sent over the SMS channel (if the user remains offline for a longer period than specified in the obligation to return usage data for the report). The SMS channel may be considered a private channel and may not require encryption.

FIG. 28 illustrates a layout of a system for tracking behavior of mobile consumers, according to some embodiments. Unlike WAP portal-based data collection, the system tracks the behavior of mobile consumers because they consume content on the fly. Unlike SMS-sent spam, accurate and reliable usage data is provided that is actually measured on the client.

The system records events that capture the user's interaction with the content item. The metering system measures play/stop events to meter the user's content consumption data. A conventional application of metering is a service that charges a user based on metered content usage. In another aspect, the present system relates to not only measuring and tracking content consumption, but also user interest in content items. User interaction with a content item is one of the best indications of user interest.

To track the user's interests and behavior, higher levels of player events are recorded by the mobile client. Some examples of these events are: (1) clicking the banner advertisement by the user; (2) the user fast forwards/backwards a portion of the content/advertisement; (3) a user voting on a content item; (4) the user responds to/skips the survey associated with the content item or advertisement with answer X; (5) the media ends (the user looks at the entire content item).

ESB structure. The present system uses an obligation framework such as that described in the' 693 application to specify what events the client must record. The client receives these obligations as part of the ESB (extended status Block) as it evaluates the license 2830 embedded in the content item 2832. Example of ESB in pseudo code:

TABLE 11

Data collection and delivery framework

HTTP channelReferring to fig. 28, the mobile client 2812 records the usage data to a local file system on the mobile handset. This data is cryptographically signed (integrity protected) by the mobile client. Upon content download to the mobile client via PC synchronization or via direct OTA (over the air) download, this data is transferred to the service backend 2820 via HTTP POST. The mobile client 2812 (or a PC functioning on behalf of the mobile client) may optionally encrypt this data to protect the privacy of the data during transit.

SMS channelAlternatively, the data may be sent to the service backend 2820 via SMS. SMS is ubiquitous and mobile clients 2812 can always use SMS, however there is often a cost associated with sending SMS messages. Thus, the mobile user attempts to use HTTP whenever possible, but will use SMS if the client remains offline (not connected to the wireless internet and not synchronized with the PC) for a period longer than the reporting interval specified in the data collection obligation specified in the license 2830. SMS has a limit on message size-SMS PDUs cannot exceed 140 bytes. If it exceeds the limit, the usage data may be segmented. Data is compressed before being sent over the SMS channel to reduce SMS usage.

Using a service backend to target advertisements. Statistical data mining and analysis techniques are used to analyze the usage data collected by the system offline. Analysis may be used to classify mobile users into categories. Users may belong to more than one category and may have varying degrees of affinity for each category to which they belong. The user may also submit demographic data to the system to be included in a certain category of choice. Demographic data (from public sources or from collaborating companies) may also be submitted to the services backend 2820 in order to better target advertisements to users who may be interested in the advertised products and services. The service backend 2820 utilizes the inferred category and demographic data to service advertisements targeted to the category or demographic group.

Location-sensitive/time-sensitive targeted local advertisement delivery. The system enables advertisers to place location sensitive advertisements. FIG. 29 is a diagram illustrating locations corresponding to location-sensitive advertisements for targeted users at particular times, according to some embodiments. Location sensitive advertisements such as L4 are attached to the geographic location (GPS coordinates) and activation region (radius from GPS coordinates, e.g., R4). When the mobile user is within the activation zone, e.g., 2930 for L4 with radius R4, the advertisement is servedPresented to the mobile user 2910. Arrow 2920 represents the path of the mobile user 2910. In the example shown in fig. 29, there are also activation regions associated with location sensitive advertisements L1, L2, L3, and L5 having radii R1, R2, R3, and R5, respectively.

Presenting location sensitive advertisements to a user while the user is in an activation area is very timely and efficient because the user can utilize this information in his immediate vicinity when it is presented.

As an example of location sensitive advertising, consider an advertiser who wishes to have promotional advertising (such as coupons) placed with the system. The system enables advertisers to submit promotional advertising material and associate it with one or more geographic locations (which may be storage locations). According to some embodiments, the system also allows advertisements to be associated with a time window for presentation (time). The advertisements may also be targeted to specific target groups, as is the case for all advertisements in the system.

When a user in the target group (who may be interested in the promotional advertisement) is within the activation zone during the time window, the promotional advertisement is presented to the user as a pop-up window. The timeliness of the advertisements, along with their location sensitivity, and the correlation of the promotional messages with the targeted users, produce an increase in the effectiveness of the advertisements.

The advertisement in the example may be a coupon for a pizza shop to be displayed around lunch time tied to the GPS coordinates of the pizza shop location near the user. When the target user is within the activation zone, a promotional advertisement is displayed to him that is likely to be relevant to the user and may result in a better sales opportunity (better advertisement sales achievement rate for advertisements that make it a valuable mechanism for advertising).

Different mobile phone platforms provide an Application Programming Interface (API) for the application to enable the system to recall the application when the mobile device is within a certain radius of the location. For example, the J2ME platform provides Java bindings for APIs. An example of the use of an API is given in the following code:

1. specifying additional information for each advertisement attached to a location;

2. adding location listeners to listen to user location events for each location;

3. when a location event occurs, the application displays a location-sensitive advertisement:

tracking mobile user's relevance. The mobile client application enables the user to share the mobile client application with his friends by transferring the application while he is using the application via SMS. Users may also use this mechanism to share and recommend content items that they like. The ability to share and enjoy content items with friends and peers makes the user experience more interactive and enjoyable for the user.

Virus distribution of content from one user to another is an attractive mechanism for content providers who wish to achieve widespread dissemination of their content. This distribution format is also useful to advertisers because they can potentially reach a wider audience of their marketing messages via this mechanism.

While the user utilizes this feature, the system tracks the transfer behavior and infers the user's interrelationships based on their application/content transfer behavior. These inferences are used to recommend content items that may be of interest to the user and to target advertisements to users sharing similar interests and preferences regarding the content consumed by the user.

The inferred relationships between users may be further categorized and defined by the categories of content items that the users share and recommend. The system reduces the inferred relationships to a metric called "user affinity," which is a numerical metric that quantifies the strength of the inferred relationships. Affinity becomes stronger as users forward more and more content of the same type to the same recipient. As more time passes between forwarding events, the affinity between users becomes weaker.

For example, a simple measure of affinity is calculated as follows: raw affinity value is the number of items x the validity index/(average time elapsed between transfer events in each day).

According to some embodiments, the raw affinity values are normalized to a range between 0 and 100 for easy comparison based on the range of values for a particular content category. According to some other embodiments, the affinity measure is further refined by taking into account more variables, such as the distribution of time elapsed between forwarding events, the time used for forwarding behavior, etc.

The effectiveness index is a measure of how effective the inferred relationship is in targeting advertisements (measured indirectly from statistical data analysis of the user's responses to similar advertisements). Statistical data analysis techniques may be used on data collected over a longer period of time to develop a better measure of affinity.

FIG. 30 is a diagram illustrating inferred relationships between users. Users, such as users 3010, 3012, and 3014, are indicated with circles. Inferred relationships between users are represented by connecting lines. The thickness of the connecting line indicates the affinity of the relationship. For example, the affinity of the relationship between users 3010 and 3014 is relatively strong, and the affinity of the relationship between users 3012 and 3014 is relatively weak.

Tracking application and content transfer behavior is useful because it enables the system to better understand the tastes and preferences of the user base. Which enables the system to better target advertisements and recommendations by correlating user preferences with user interrelationships.

FIG. 31 is a diagram illustrating SMS message routing for sharing or recommending applications or content between users according to some embodiments. The user 3110 shares/recommends the application and/or content with the mobile client application via SMS with one of its friends, user 3112. The SMS message is sent by the application along with the context information (application version, client properties probed from the handset, buddy phone number, content id, etc.) to the short code for the service backend.

The SMS message is routed by SMS data network 3116 and SMS gateway 3118 to service backend 3114. The backend 3114 records who has forwarded the content to whom and composes the SMS message and sends it to the intended recipient to inform him of contextual information before his friends have recommended the application/content item to him. The SMS message proceeds to the receiving user 3112 via the SMS gateway 3118 and the SMS data network 3116.

According to some embodiments, the SMS message also contains a URL for OTA (over the air) download of the mobile client. The recipient can click on this URL and download the mobile client to his handset. The application may also contain a break-in (teaser) or reduced version of the recommended content item.

Although the foregoing has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing the processes and apparatuses described herein. The present embodiments are, therefore, to be considered as illustrative and not restrictive, and the subject matter of the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (40)

1. A mobile telecommunications device comprising:

a display for displaying content to a user;

one or more input devices for collecting input from a user; and

one or more processors adapted and programmed to communicate with the server system and present targeted advertisements to the user, the advertisements being targeted based at least in part on usage statistics stored on the server system and previously collected from the mobile telecommunications device.

2. The device of claim 1, wherein the mobile telecommunications device is only intermittently in communication with the server system, and the one or more processors are programmed to collect usage statistics at times including when the mobile telecommunications device is not in communication with the server system.

3. The device of claim 1, wherein the advertisement i is targeted based on one or more criteria selected from the group consisting of: the geographic location of the device, the time, and demographic information of the user.

4. The device of claim 1, wherein the processor is further adapted and programmed to transmit the usage statistics collected from the mobile telecommunications device to the server system using SMS technology.

5. The apparatus of claim 1, wherein the usage statistics include one or more events selected from the group consisting of: how many times an advertisement is played, a play/stop event, a user clicking on an advertisement, a user fast forwarding and/or rewinding a content item or a portion of an advertisement, a user voting for a content item, a user responding to a survey associated with a content item or advertisement with a response, a user skipping a survey altogether, a presentation of a content item in its entirety, and a user's application and/or content forwarding behavior.

6. The device of claim 1, wherein the one or more processors are further adapted and programmed to communicate with a server system, such that a mobile device identifier can be received from the server system, and the collected usage statistics associated with the identifier can be transmitted to the server system.

7. A server system for collecting usage statistics and recommending targeted advertisements, the system comprising one or more processors adapted and programmed to receive usage statistics from a plurality of mobile telecommunications devices, analyze the usage statistics and thereby generate recommendations for advertisements targeted to users of the mobile telecommunications devices, wherein the one or more processors automatically make inferences about user preferences by tracking the user's application and/or content usage behavior and recommending products and/or services to the user based in part on the user's preferences.

8. The system of claim 7, wherein the advertisement is targeted based in part on one or more criteria selected from the group consisting of: the geographic location of the device, the time, and demographic information of the user.

9. The system of claim 7, wherein the usage statistics include one or more events selected from the group consisting of: how many times an advertisement is played, a play/stop event, a user clicking on an advertisement, a user fast forwarding and/or rewinding a content item or a portion of an advertisement, a user voting for a content item, a user responding to a survey associated with a content item or advertisement with a response, a user skipping a survey altogether, a presentation of a content item in its entirety, and a user's application and/or content forwarding behavior.

10. The system of claim 7, wherein the one or more processors are further adapted and programmed to transmit a mobile device identifier to the first mobile telecommunications device and to verify that the received usage statistics originate from the first mobile telecommunications device based at least in part on an association of the mobile device identifier and the received usage statistics.

11. The system of claim 7, wherein the mobile telecommunications device is only intermittently in communication with the server system.

12. A method for presenting targeted advertisements to a user of a mobile telecommunications device, comprising:

collecting usage statistics from the mobile telecommunications device;

transmitting the usage statistics to a server system;

receiving a recommended targeted advertisement from a server system, the advertisement recommended by the server system based at least in part on the collected usage statistics; and

one or more of the recommended targeted advertisements are presented to the user via the mobile telecommunications device.

13. The method of claim 12, wherein the mobile telecommunications device is only intermittently in communication with the server system and the usage statistics are collected at times including when the mobile telecommunications device is not in communication with the server system.

14. The method of claim 12, wherein the advertisement i is targeted based on one or more criteria selected from the group consisting of: geographic location of the mobile telecommunications device, time, and demographic information of the user.

15. The method of claim 12, wherein the usage statistics are transmitted to the server system using SMS technology.

16. The method of claim 12, wherein the usage statistics include one or more events selected from the group consisting of: how many times an advertisement is played, a play/stop event, a user clicking on an advertisement, a user fast forwarding and/or rewinding a content item or a portion of an advertisement, a user voting for a content item, a user responding to a survey associated with a content item or advertisement with a response, a user skipping a survey altogether, a presentation of a content item in its entirety, and a user's application and/or content forwarding behavior.

17. The method of claim 12, further comprising receiving a mobile device identifier from a server system, wherein the usage statistics are transmitted to the server system such that the server system can associate the usage statistics with the mobile telecommunications device.

18. A method for recommending targeted advertising to a user of a mobile telecommunications device, comprising:

receiving usage statistics collected from the mobile telecommunications device;

making inferences about user preferences by tracking user application and/or content usage behavior;

generating recommendations for advertisements targeted to a user of the mobile telecommunications device based in part on the user's preferences; and

transmitting a recommendation to one or more of the mobile telecommunication devices.

19. The method of claim 18, wherein the recommendation is further based in part on one or more criteria selected from the group consisting of: the geographic location of the device, the time, and demographic information of the user.

20. The method of claim 18, wherein the usage statistics include one or more events selected from the group consisting of: how many times an advertisement is played, a play/stop event, a user clicking on an advertisement, a user fast forwarding and/or rewinding a content item or a portion of an advertisement, a user voting for a content item, a user responding to a survey associated with a content item or advertisement with a response, a user skipping a survey altogether, a presentation of a content item in its entirety, and a user's application and/or content forwarding behavior.

21. The method of claim 18, further comprising:

communicating a mobile device identifier to the first mobile telecommunications device; and

verifying that certain received usage statistics originate from the first mobile telecommunications device based at least in part on the association of the mobile device identifier with certain received usage statistics.

22. The method of claim 18, wherein the mobile telecommunications device communicates with the server system only intermittently.

23. A method for identifying a mobile telecommunications device for the purpose of collecting usage statistics and recommending targeted advertising, comprising:

collecting usage statistics from the mobile telecommunications device;

receiving a mobile device identifier from a server system;

transmitting the usage statistics to a server system, such that the server system can associate the usage statistics with the mobile telecommunications device; and

receiving a recommended targeted advertisement from the server system, wherein the advertisement is targeted based at least in part on the communicated usage statistics.

24. The method of claim 23, wherein the mobile telecommunications device communicates with the server system only intermittently.

25. The method of claim 23, further comprising signing the usage statistics with a secret key.

26. The method of claim 23, further comprising negotiating with the server system regarding the delivery of the usage statistics.

27. The method of claim 23, further comprising verifying that the mobile device identifier is received from a trusted source.

28. The method of claim 23, wherein the mobile device identifier is obtained using three or fewer exchange steps between the mobile telecommunications device and the server system.

29. A method for identifying a mobile telecommunications device for the purpose of collecting usage statistics and recommending targeted advertising, comprising:

transmitting a mobile device identifier from the server system to the mobile telecommunications device;

receiving usage statistics from the mobile telecommunications device; and

verifying that the received usage statistics originate from the mobile telecommunications device based at least in part on an association of the mobile device identifier with the received usage statistics.

30. The method of claim 29, wherein the mobile telecommunications device communicates with the server system only intermittently.

31. The method of claim 29, further comprising:

making inferences about interrelationships of a plurality of mobile telecommunications devices by tracking application and/or content usage behaviors of users;

generating recommendations for advertisements targeted to users of the mobile telecommunications devices based in part on the interrelationships of the users; and

transmitting a recommendation to one or more of the mobile telecommunication devices.

32. The method of claim 29, wherein the mobile device identifier is obtained by the mobile telecommunications device using three or fewer exchange steps between the mobile telecommunications device and the server system.

33. A mobile telecommunications device comprising:

a display for displaying content to a user;

one or more input devices for collecting input from a user; and

one or more processors adapted and programmed to communicate with the server system, enable receipt of a mobile device identifier from the server system, and enable transmission of the collected usage statistics associated with the mobile device identifier to the server system.

34. The device of claim 33, wherein the mobile telecommunications device is only intermittently in communication with the server system.

35. The apparatus of claim 33, wherein the one or more processors are further adapted and programmed to sign the usage statistics with a secret key.

36. The apparatus of claim 33, wherein the one or more processors are further adapted and programmed to negotiate with the server system regarding the transmission of the usage statistics.

37. A server system for collecting usage statistics from a mobile telecommunications device, comprising one or more processors adapted and programmed to transmit a mobile device identifier to the mobile telecommunications device, receive the usage statistics from the mobile telecommunications device, and verify that the received usage statistics originate from the mobile telecommunications device based at least in part on an association of the mobile device identifier and the received usage statistics.

38. The system of claim 37, wherein the one or more processors are further adapted and programmed to make inferences about the interrelationships of multiple mobile telecommunications device users by tracking user applications and/or content usage behavior, generate recommendations for advertisements targeted to users of mobile telecommunications devices based in part on the user interrelationships, and transmit the recommendations to one or more of the mobile telecommunications devices.

39. The system of claim 38, wherein the advertisement is targeted based in part on one or more criteria selected from the group consisting of: the geographic location of the device, the time, and demographic information of the user.

40. The system of claim 37, wherein the mobile device identifier is obtained by the mobile telecommunications device using three or fewer exchange steps between the mobile telecommunications device and the server system.