Patent Application
20080098420
The present invention is directed to a system and associated apparatus and methods for the efficient distribution of advertisements to, and control of the display of those advertisements on a device operating in a network. Although the invention is intended for use in a broadcast environment and will be discussed with reference to that mode of data transfer, it is to be understood that some of its methods and techniques may be used in other environments as well.
In order to make the following discussion of the embodiments and benefits of the present invention better and more fully understood, it is useful to introduce certain terms and definitions that will be used. It is to be understood that these terms and definitions are introduced for purposes of clarity and not to place restrictions or constraints upon the described embodiments of the invention or the claimed invention.
In the discussion of the present invention, the following terms will be understood to have the following general meanings:
Ad Bundle: An ad bundle contains multiple presentations or modes of the same ad. For example, it can contain a presentation for text only display, another presentation for static image display, and another presentation for full-screen video display. The ad bundle also may contain a description of the ad that can be used by the ad policy to determine whether or not to choose that ad for display. This description may include keywords, context descriptions for desired display, rules, and other metadata.
Ad Display Policy: The ad display policy is a policy or set of rules or heuristics executed on a device when an application on the device requests an ad for presentation to the user. The policy may be active (e.g., notifying an application that an ad is to be displayed) or may be passive and respond to a request from an executing application. The policy is controlled by the service provider and may be distributed to all devices in the network in a real-time or pseudo real-time manner.
Ad Cache: A data storage area on a local device where received ad content may be placed for future access.
Ad Cache Refinement: A mechanism for managing the local storage of ad content, for example by determining whether new ads that are received should be stored in whole, in part, or discarded. As will be discussed, one possible method is to compare new ad content to ads already present in the cache and determine whether the new ad content is of greater relevance to the user of the device. If so, the new ad may be used to replace a less relevant ad currently in the cache. This determination/comparison can be made by scoring the ads such that higher scores indicate a higher level of expected interest to the user of the device.
Ad Module: A secure and trusted client process executing on one or more devices in the network. The process may be implemented as a set of executable instructions capable of execution by a processing element, a state machine, or other form of instructions capable of controlling the selection and presentation of ad content. The process provides a set of APIs (application programming interfaces) to applications executing on those devices that may be used to access and control the selection and display of ad content. Among other functions, ad cache management, ad policy execution, and reporting metrics are managed by the ad module.
Note that in the following discussion and description of the figures, certain elements may be represented by the same numbers with those numbers appearing in different figures. In such a case, the element referred to is intended to represent the same or equivalent element in both figures and, where applicable, with regards to the accompanying description for those figures.
In broad terms, Ad Server 102 is responsible for distributing ad content and ad display policies, and for collecting usage metrics from each recipient device in the network. As noted, some or all devices in the network contain Ad Module 104 that is broadly responsible for retrieving and caching the ad content transferred over the network, obtaining and executing the ad display policies, providing applications (e.g., element 110) on the device a common API for obtaining and displaying ads, and collecting statistics on the ads displayed and if desired, follow up actions by a user to report back to the Ad Server.
As shown in the figure, Ad Server 102 includes one or more modules that implement the inventive methods and processes. These modules include Ad Server Ad Manager Module 120, Ad Server Policy Manager Module 122, and Ad Server Report Manager Module 124.
In broad terms, Ad Manager Module 120 is responsible for collecting ads from various possible sources of ad content and controlling the distribution of those ads to client devices capable of communication with network 106. These sources could include, for example, ad networks, which aggregate ads from a number of sources, an ad content feed provided over a network (such as the Internet), or individual advertisers.
When distributing ads for transfer over network 106, ad manager module 120 is capable of filtering ad content based on a number of attributes, including, but not limited to:
In accordance with the present invention, ad content can be distributed over the network to the client devices in a number of ways. For example, ad content can be continuously broadcast over one or more channels which are monitored by devices in the network. Alternatively, ad content can be broadcast at only certain times of the day, such as overnight or during non-peak hours, as a way of more optimally utilizing the network resources (with the client devices made aware of this practice and configured to “tune in” to the broadcast of the ad content). Another possible method is to have some or all of the client devices initiate a point-to-point connection with the ad manager at regular intervals to obtain ad content (note that this method would likely be optimal only for a network that could support relatively large numbers of simultaneous requests for connections from the receiving client devices).
When broadcasting ad content, there are several mechanisms by which the ads and their corresponding metadata can be delivered (where the metadata may include information such as descriptive keywords, ad characteristics (size, modality, etc.), selection criteria, etc.). One method is to have the ad relevant metadata contained within the ad itself. In this situation, a client device would be configured to read the entire ad and its metadata, and then determine whether the ad should be cached or not. Another possible mechanism is to broadcast an ad catalogue which contains a list of the ads, their associated metadata, and where they can be found. A client device would then access the entire catalogue, apply an appropriate filter to each item to determine which ads are to be retrieved to fill the cache, and then retrieve the desired ads. Retrieving the ads may be implemented by listening to a particular broadcast channel that contains all the ads and pulling those ads that are desired, for example. In a non-broadcast data transfer environment, the device may contact the ad manager and request the ads that are to be retrieved and cached locally in the client device. Further, in an implementation where a service guide is made available to the subscriber population, the ad catalogue can be included with the service guide and then acted upon by the client device to identify the desired content.
Ad sever policy manager module 122 is responsible for creating, managing, and ensuring proper distribution of the policies that are to be implemented by the client devices to control the selection and display of ad content. This may include the real-time, pseudo real-time or other desired distribution of policy changes to all appropriate devices in the network. In this regard, note that the network operator (in accordance with policy desires of the providers of ad content and/or as part of the operators' own content policy decisions) can create or modify content display policies and have them delivered immediately, or schedule to have them delivered at a future time.
As with ad content, ad selection and display policies can be distributed to devices within the network using a variety of methods. For example, devices in the network can be instructed to listen to or regularly monitor a broadcast channel that contains new ad policy information when it is available. In this way, when policy manager module 122 has a new or revised ad policy to distribute, it can place the policy data on the broadcast channel to be received and implemented by client devices. To increase the likelihood of reception by the desired recipient devices, the current policy can be rebroadcast at regular intervals so that devices which may not have been listening or capable of connectivity when the policy was first broadcast are able to receive the update.
In the case of using a non-broadcast data transfer mechanism, devices in the network can poll policy manager module 122 to ask if a new policy is available (or to obtain the current policy if they do not have it available). The new or current policy can be sent in the response to the poll, or the device can make a subsequent request to obtain the new policy if one is available. Another possible mechanism is for policy manager module 122 to issue a notification to devices in the network to indicate that a new policy is available. Devices can then contact the policy manager to obtain the new policy at a time appropriate for that device (or in accordance with a schedule communicated by the policy manager). Note that some of these methods depend on the availability of point-to-point communications between devices in the network and policy manager module 122. Since ad policies are typically relatively small amounts of data compared to the ad content itself, this may be an acceptable solution. However, note that in certain types of networks such as some mobile phone networks, such methods may still be undesirable due to network bandwidth limitations, congestion, or device limitations.
Report manager module 124 is responsible for performing certain of the ad content usage and tracking operations of the present invention. Specifically, report manager module 124 obtains ad usage data or reports from client devices in the network, processes that data, and makes the processed data available for use by the network operator and advertisers. The processed data can be used, among other things, to determine the effectiveness of specific ads in generating desired user actions, calculating pricing models for ads and placement of ads, or as inputs to determine the revenue generated for the operator by charging the advertiser for distribution of the ad. Since reporting statistics typically requires a client initiated point-to-point connection, the reporting activity may need to be controlled to prevent network congestion. In this regard, the server may control the frequency of reporting by telling the client devices when to report next, or by requiring that the device receive a report request from the server either via broadcast or point-to-point communications before reporting statistics. Further, a broadcast report request that may be received by all devices in the network may indicate that only a portion of those devices receiving the request report their usage statistics so as to minimize the impact of those reports on the network.
As noted, ad usage statistics can be used by the network operator for billing and pricing purposes. However, they can also be used to further refine the content stored locally in the ad cache on a client device or the policies distributed to the client population. Further, the statistics can also be used to support a bidding system for advertisers who desire to have their ad content featured more prominently. This is because without needing to repopulate the ad content cache, and using a minor policy change that can be quickly distributed throughout the network, one advertiser can outbid another to increase the number of ad displays their products get and have that result communicated to and implemented by devices in the network.
On the client side of system 100, ad module 104 is generally responsible for retrieving ad content and ad policy data from the network and implementing that policy (alone or in accordance with information provided by sources such as the application executing on the client device and/or user profile data) to control selection and display of the content. Ad module 104 is also responsible for certain aspects of the cache management functions implemented as part of the inventive system.
As noted, ad module 104 may monitor the network for ad content being delivered over the network. This can be done by listening at predetermined times to a broadcast stream, or by being addressed directly by ad server 102. Ad server 102 may send a cache purge event to the client, the result of which is to cause ad module 104 to delete all ads in the ad cache. This may be used when the network operator wants to send a fresh set of ads to all devices in the network.
The cache management functions performed by ad module 104 are primarily intended for the purpose of optimizing the use of the limited data storage space available on client device 108 without sacrificing potentially relevant ad content. Because of the limited storage space available on some devices, it is important to maximize (where possible) the relevance and effectiveness of the content stored in the cache. Further, because some previously distributed ad content may have greater relevance for a user or set of users than newer ad content, it is desirable that the cache management functions be capable of implementing a decision process that takes this into account (as opposed to simply flushing a cache and replacing it with new content, or removing content having a date older than a certain date, etc.). An example of such a decision process suitable for use with the present invention will be described with reference to
In addition to retrieving ad content, ad module 104 also is responsible for retrieving and controlling the implementation of the policies that control the selection and display of ad content. As with the ad content, ad module 104 may monitor the network for ad display policies delivered over the network. As with the ad content itself, this can be done by listening at predetermined times to a broadcast stream, or by being addressed directly by the server. Note that an ad display policy that is received may be effective immediately, not be effective until a future point in time, or not be effective until a triggering event occurs.
When an application 110 (such as a stock quote display, search engine, sportscast, newscast, game, etc.) executing on client device 108 requests an ad for display to the user, the ad display policy is executed to determine which ad to deliver to the requesting application. The display policy may utilize current local device conditions, user location, user profile information, and/or additional information supplied by the requesting application in executing the policy. Note that display policies can be active in the sense of requiring applications to rotate ads periodically. In this case, applications may be notified when a new ad should be displayed. The application will then ask for a new ad when it is ready to display the new content.
As discussed with reference to ad server report manager module 124, the collection and processing of ad usage statistics is an important function of the inventive system. In this regard, ad module 104 is capable of providing detailed ad usage and reporting services to the network operator, service provider, or ad content provider. The ad usage data can be used to further refine the contents of the ad cache (by supplying data used to make decisions whether to remove or retain ad content in the cache), or to refine the policy used to select and display the ad content. Example statistics that may be collected include, but are not limited to:
Note that the statistics can be collected over a period of time and provided to the network operator, etc. on a scheduled basis, or upon request. Note further that ad module 104 may rely upon the application executing on the client device for certain data or statistics. For example, the length of time an ad is displayed to the user may be controlled and tracked by the application. In this scenario ad module 104 knows that the ad was asked for and delivered, but not necessarily how long it was on the application's screen, or if it was displayed at all. Note that not all applications may be counted on to provide reliable information concerning the use of an ad. For this reason, ad module 104 may distinguish between trusted applications and non-trusted applications. The statistics stored will reflect or may depend upon the type of application that did the reporting. Alternatively, ad module 104 can provide an API that allows the ad module itself to take over part of the screen for displaying an ad. This requires that the client device provide a mechanism to hand a portion of the screen over from the current application to the ad module. If available, this ensures the gathering of reliable ad statistics regardless of the level of trust an application has been granted.
Ad policy creator 208 may receive usage data and/or ad content usage reports from Report Manager module 124 of
An important aspect of the present invention is that it does not require, and in most circumstances anticipates that ad content data and ad policy data are not bundled together, and instead may be created, modified, refined, and distributed independently of each other. This is a result of having the ad content and ad policy distributed to network 106 by Ad Distributor 206 and Ad Policy Broadcaster 212, respectively, where ad content or ad policy may be broadcast over network 106 at different times and in whatever manner is most cost-effective and efficient.
Note that as shown in the figure, Content Providers 220 may provide content in the form of video, text, or audio data to be broadcast over network 106. This data may include, for example, ad content, the selection and display of which is controlled by the ad policy.
Continuing with the description of
Ad Module 104 includes an ad Cache 240 that is used to locally store ad content received over network 106 (as suggested by the boxes labeled “ad” in the figure). Although Ad Cache 240 is shown as being an element of Ad Module 104, note that it may also be implemented as part of another data storage element that is part of client device 108, such as the device's own local data storage element. Ad Module 104 may also contain a local ad filter 250 that may be used to filter received ad content prior to it being selected for storage in Ad Cache 240 based on user preferences, user location, user profile, user behavior, etc. Note that local filter 250 may remove ad content from data that is to be stored in ad cache 240, or “tag” such data before it is stored, thereby controlling whether it is displayed currently (but not later), not currently but instead later, or not at all, for example.
Ad cache 240 is an important component of the inventive system. In operation, the cache will typically contain a variety of user targeted ads that can be used in the selection process defined by the ad policy. There are a number of environments and use cases where real-time delivery of ads to many users in a large population is not realistic or practical. This can be due to bandwidth limitations, device limitations, network traffic management, or other provisioning issues.
In such cases and in general, maintaining an ad cache provides several distinct advantages. For example, it provides flexibility in the delivery of ads to the user population. The cache can be populated slowly over time, or more quickly during off-peak periods of network usage. Content stored in the cache can be filtered locally based on physical device characteristics such as display size or audio-visual capabilities, environmental device characteristics such as signal strength or GPS location, user preferences such as hobbies or services subscribed to, user profile such as age or gender, or usage history such as which applications have been run recently or which ads were clicked on recently. One or more of these filters can be used to build a collection of ads of specific interest to the user of the device. A locally resident cache also allows multiple applications to have access to the same set of ads through a common ad module or interface. For example, the inventive ad module uses the cache to provide access to a variety of ads that, while of special interest to the user, might only be appropriate at certain times or in certain contexts for particular applications.
Note that rules, heuristics, or algorithms used to filter ad content locally can be preloaded onto the device, or updated by the service provider or network operator and distributed to the users on a periodic or predetermined basis. For example, when the device periodically contacts the service provider to authenticate continued access to a particular service or channel, the service provider has an opportunity to update the local filters that particular device uses when populating the ad cache.
Although the ad cache is initially populated in a manner so as to have ads available to most, if not all, applications, in accordance with the present invention, over time as more ads are received, the cache's contents are refined to better suit the user of the device. This means that once the cache is full or nearly full, items currently in the cache may be removed to make room for ads that are more appropriate or relevant to the user. As will be described with reference to
Further, even when initially filling the cache, it may be desirable to not store certain ads even if that means there might be no ads to provide for a particular application. For example, a child's device would not store beer ads, even if there is room in the cache. This may be accomplished by using two filters, one for when the cache is full, and one for when the cache is not full. The cache scoring mechanism to be described would then be in effect when the cache is full or nearly full. When the cache is not full, a weak filter may be used, where such filter, instead of scoring the ads, determines if an ad is inappropriate for the user, and if so, refrains from caching that ad.
As recognized by the inventors, it may be desirable to override the cache scoring mechanism at times. For example, the ad aggregator, network operator, etc. may desire to push the same ad to all devices in the network, regardless of how well they score on each individual device. This can be accomplished by providing an override filter with the ad itself, such as “always cache”, or something more complex, such as “only cache on devices with a screen size of 320 by 160 or greater”.
The service provider, network operator, etc. may wish to exert additional control over the cache population by specifying an expiration time for the entire cache, or for a particular ad or ads in the cache, or by maintaining the ability to send a cache flush event that would empty the cache and cause each device to start populating the cache again. This might be useful if a complete new set of ads have been provisioned and are intended to replace any existing ads that were previously delivered, regardless of score.
Note that the service provider, network operator, etc. has control over the timing of ad cache population and refinement processes. For example, a service provider may want to distribute ads during off peak periods of network usage at a high rate, and then suspend distribution during peak hours. Alternatively, the service provider may send ads at higher rates during off peak hours and lower rates during peak hours. Further, the service provider may choose to distribute ads at a constant rate throughout the day, but increase the volume in real-time if a significant number of new advertisers are acquired.
Ad Module 104 also includes one or more application programming interfaces (APIs) 260 that provide a way for applications executing on client device 108 to interact with Ad Module 104 and implement the ad content selection, display, and tracking functions of the present invention. The APIs 260 typically include a process to enable Ad Module 104 to notify (shown as “notify” in the figure) an application that ad content is to be displayed to a user of a registered application. This is an example of an active ad policy whereby the policy informs the application that it is the proper time, client device location or state of the application for an ad to be displayed. As shown in the figure, in such an example, the Ad Policy data 270 stored in Ad Module 104 triggers the notification process in accordance with its rules or heuristics. As will be described, an application may also request ad content in accordance with its own state of execution, rather than as a result of receiving a notification.
In general terms, when an executing application is in a state where it has an opportunity or is otherwise instructed to display an ad, it will call an API in the ad module to obtain an ad to display. In response, the ad module will execute the current ad policy to determine which ad from the cache to return to the application. Note that the application may provide keywords, context information, or supported display characteristics to be used in the selection of the ad.
The ad module may also support integration with a built-in web, WAP (wireless application protocol), or other type of browser. This provides web or WAP compliant pages being hosted outside, but viewed on the client device the ability to make calls to the ad module in order to insert locally cached ads into the web or WAP page. This can be accomplished, for example, by using the localhost URL notation, such as:
Ad policies can be active, as opposed to only being executed when an application requests an ad. For example, active policies may notify applications when specific ads are to be displayed. In an ad rotation scheme, the policy may notify applications when a new ad is to be rotated in. This eliminates the need for each application to implement its own rotation algorithm or process, and ensures that the policy is defined by the operator.
As discussed, to support real-time notification to applications that an ad should be displayed, or that an on screen ad should be rotated out and replaced with a different ad, the ad module provides several APIs. When an application begins execution, or enters a state where ads can be displayed, the application calls the ad module's register API to inform the ad module that the application can receive ad notifications. The application will provide the register API with a callback function that the ad module can call. The callback function will be called by the ad module when a new ad needs to be displayed. When an application ends, or enters a state where it can not display ads, the application will call a deregister API that informs the ad module that the application will no longer respond to display requests. Note that multiple applications can be registered with the ad module at the same time. This is typical in multitasking environments where multiple applications share the screen.
Whether as a result of receiving a notification or as a result of making a request for ad content, an application may acquire ad content using a getAd( ) process API. This process represents an API that enables an application to access ad content data stored in Ad Cache 240. In addition, Ad Module 104 includes a report( ) API that represents a process that enables an application to provide usage data, metrics, or other forms of reporting data regarding ad content. This data may be stored in a usage metrics element 290 that is configured to provide such data in either raw or processed form to network 106 for transfer to Ad Server 102.
As noted, ad content can be multi-modal, meaning that one ad bundle can have a number of display modes or formats for the ad content. For example, where only text is allowed or feasible for a client device or application, the ad will be rendered using only text. Static images or movie clips of the same ad can be made available for use when the application supports those formats. Typically, the application specifies what format is supported, and the local ad module makes the decision as to what to provide to the application, based on the current policy in effect.
Since multi-modal ads generally have multiple levels of detail, if a user expresses interest in a particular ad, additional information concerning the ad can be displayed to the user directly from the ad cache. For example, if a user selects a static ad image, a short video further explaining the ad can be shown to the user directly from the cache without needing to retrieve additional information over the network.
As discussed, to support multi-modal ads, ads are sent as bundles, where two or more levels of ad information may be provided: general information about all ad formats in the bundle; and specific information for each ad format included in the bundle. For example, general information might include keywords about the company sponsoring the ad or product or service mentioned in the ad. Specific information for a particular format might include additional keywords, display characteristics, and/or what action to take when the user selects the ad for more information.
In any case, a change in ad policy is desired, and is communicated to Ad Policy Manager 122 by the issuance of a command or execution of a specified instruction or process (stage 410 in the figure). For the example shown, the desired change in policy is to display an ad for a sneaker or other specified product (now or contemporaneously with another indicated event). The command is received by Ad Policy Manager 122 which interprets the command as requesting a change in the existing (i.e., currently implemented) ad policy. Ad Policy Manager 122 creates a policy override to implement the desired change in policy. This “override policy” may be in the form of policy override data that is intended to override existing policy for a period until it is implemented, a modified ad policy that incorporates the desired change(s), or a partial ad policy that incorporates the desired new policy features and is intended to temporarily replace the presently implemented policy. The policy override, revised policy, or partial ad policy is provided to Ad Policy Broadcaster 212 which is the element responsible for providing the policy to the broadcast network 106 (as shown at stage 430 in the figure). The network 106 distributes the policy override via broadcasting to a set of recipient client devices.
The revised or override policy is received by a client device and provided to Ad Policy Module which stores Ad Policy data 270, and which is typically an element of Ad Module 104. In accordance with the operation of the present invention, when new or revised ad policy data is received, the new or revised policy instructions are implemented as required by the policy. In the present example of a policy override to cause the display of a particular ad at a particular time, the currently executing application (element 110 in the figure) is notified via the relevant API 260 that the application should display the desired sneaker ad (stage 440 in the figure). The notify process triggered by the API in turn causes application 110 to request the desired ad content using the getAd( ) API (as shown at stage 450 in the figure). Application 110 receives the requested ad content from Ad Cache 240 as a result of the getAd( ) API call, and presents the Ad to the user of the client device.
The above description of the creation and implementation of a policy override is an example of how the present invention is capable of altering the execution of an existing ad policy in a cost-effective and network resource-efficient manner. As a result of the ad content and ad policy being communicated separately to client devices, changes to policy may be implemented quickly (real-time or pseudo real-time) with minimal use of network resources. This is an important feature because it permits network operators, ad managers, or other creators of ad policy to implement changes in policy designed to take advantage of current events, sporting event results, the end of a concert or other event, etc., by using that event as the basis for displaying a highly relevant ad.
Device characteristics or operating conditions such as:
Continuing with the description of the cache management processes, as shown in the figure, when ad content (shown as Ad Bundle 300 in the figure) is received by Ad Module 104 which is executed on client device 108, it is first determined if Ad cache 240 is full or cannot otherwise store the ad content (stage 510 in the figure). If Ad cache 240 is not full, then a “weak” filtering process may be applied (as will be described with reference to “Weak” Filter 520 in the figure).
If present, Weak Filter process 520 is intended to determine if there are reasons not to cache the ad content, even though data storage space may be available. For example, Weak Filter 520 may determine that the ad content is not appropriate for the user of the device (based on user profile data or other filtering characteristics), is not appropriate for the device itself (as a result of characteristics of the device itself), etc. Note that the ad content may itself include data or meta-data that overrides the Weak Filter process.
The output of Weak Filter process 520 is a determination that the ad content in question is either appropriate or not appropriate for the user. If the determination is that it is not appropriate, then the ad content is not cached and is instead deleted or otherwise disposed of (as suggested by the trash icon 530 in the figure). If the determination is that the ad content is appropriate, then the ad content is stored in Ad cache 240 (as suggested by the “Store New Ad” stage 540 in the figure).
As noted, upon receipt of ad content, it is first determined if Ad cache 240 is full or cannot otherwise store the ad content (stage 510 in the figure). If Ad cache 240 is full, then Local Filter 250 implements an intelligent process to determine if the new ad content has sufficient relevance to the user of the client device to justify storing the new ad content in the cache (and delete currently cached items to make room for the new item). This intelligent process may be implemented by Ad Scorer 550. Ad Scorer 550 represents a set of executable instructions, heuristics, algorithms, etc. that implement a process or processes to evaluate whether the new ad content that is proposed for storage in Ad Cache 240 is sufficiently relevant to the user of client device 108 to justify its storage. Although an example of such an evaluation process will be described, it is to be understood that other processes, heuristics, algorithms, etc. may be used to accomplish a similar function and that such other processes and methods are intended to be within the concept of the present invention.
In one form or another, Ad Scorer 550 may compute a relevancy score for the new ad content. The relevancy score may be determined by application of rules, heuristics, or algorithms to the keywords and/or other meta-data provided with the ad content. The user profile, present location, present activities, and/or device characteristics may also be used as part of the scoring process. The intention is to develop a value for a metric that may be used to determine whether to store the ad content based on comparison with the relevancy metric for other currently stored content. In this way an intelligent decision may be made as to whether the new ad content is more or less relevant or potentially relevant to the device user than other current currently stored in the cache.
As an example, a process defined in whole or part by the following steps may be used to determine whether to cache new ad content and evaluate the relevancy score for ad content when such content is received from the network:
1. If there is sufficient free space in the cache to store the new ad:
2. If there is insufficient free space in the cache to store the ad:
As indicated, Ad Scorer 550 implements a process to determine the relevancy of the new ad content and also determines which, if any, currently cached ad content should be deleted to make room for the new ad content. Note that if the relevancy score for the new content is less than that for the currently stored content and a “must cache” instruction is not operative, the new content may not end up being cached. In this regard, if the operator, carrier, or other relevant party has issued a “must cache” instruction, the new content will be cached even if that means removing from the cache content with an equal or higher relevancy than the new content. As a result, if a “must cache” instruction is operative or if the relevancy score for the new ad content is greater than that of relevancy score for the ad content having the lowest relevancy score that is currently cached, then the new ad content may be selected for caching (as indicated by stage 560 in the figure). If this is not the case, then the new ad content will not be selected for caching (as suggested by the trash icon 530 in the figure).
If the new ad content has been selected for storage in Ad cache 240, then an item or items of content currently stored in Ad cache 240 may need to be deleted (as indicated by stage 570 in the figure) to provide sufficient room for storage of the new content. The item or items deleted may be selected by identifying the currently stored content having a lower relevancy score than the new content, or by application of one or more “tie-breaking” heuristics or rules, examples of which are given in the following discussion. Note that it may be possible for an ad that scores higher than certain ads in the ad cache to not be cached in cases where the lower scored ads in the cache, if deleted, do not free up enough space in the cache to store the new ad. Based on the algorithm specified above, the new ad would be discarded in such cases.
The following are examples of “tie-breaker” rules, heuristics, or algorithms that may be applied when comparing ad scores that are equal to one another or to determine which content to remove from a cache:
As an example of how an ad scoring process could be implemented, the following describes certain stages in a process that determines which ad content to cache and present to a number of different client devices.
As an example of an ad filtering and scoring process, assume a population of 40 users, split evenly between a football stadium and a shopping mall. The users consist of an equal number of males, females, those aged 40 years or more, and those aged under 40. The advertiser has ad content they wish to deliver and have presented for sneakers, beer, coffee, sports memorabilia, vitamins, minivans, sports cars, gaming systems, the upcoming hockey season, and clothing. Note that the service provider filter (implemented as part of Ad Server 102) may choose to send ads for beer and the upcoming hockey season only to the football stadium, send the coffee and vitamins ads only to the shopping center, and the remaining ads to both locations. The local device filters may score the ads based on the users in the following manner:
Assuming that the caches size for all devices is 3 ads, and based on the filtering and scoring system shown in the table above, the ads would be placed in the following way:
The results of service provider and local device filtering show that each individual in the network would then be the recipient of specifically targeted ads. The example can also be used to show how items in the cache are further refined as part of the cache management process as new ads come in. For example, to accomplish the goal of always having something to show the user, the first three ads received by the device are added to the cache regardless of score, since the cache has empty slots to store those ads. When a fourth ad is received, the score of that ad is compared to the scores of the ads already contained in the now full cache to see if it scores higher than any ad contained therein.
Assume the ads are distributed in the following order, with the scores shown for the female under 40 at the football stadium: sneakers (70), beer (80), sports memorabilia (50), minivans (80), sports cars (30), gaming systems (50), the upcoming hockey season (30), and clothing (100). The first three ads are cached since there is room in the cache to hold those ads regardless of score.
The next three ads received, sports cars (30), gaming systems (50), and the upcoming hockey season (30), do not score high enough to replace any of the existing ads, and are discarded. When the final ad, clothing (100), is received, it does score high enough to replace sneakers (70). This leaves the final cache as follows:
Note that the process, heuristic, rules, or algorithm used to score and manage replacement of ads in the cache may be more complex than the example discussed. For example, it is likely that ads will be of different sizes, and take up more or less of the ad cache. When a new ad is being considered for addition to a full cache, more than one ad may need to be removed to make room for the new ad. Thus, the scores of all ads affected need to be taken into consideration. One method of accomplishing this would be to compare the average scores of the ads that would need to be discarded to make room for the new ad, and if the new ad scored higher than that average, the collection of existing ads would be discarded to make room for the new ad.
Upon receipt of the notification, the relevant application (in this case the baseball application), generates a call to the getAd( ) API 260 (as indicated by stage 690 in the figure). In response, Ad selector module 692 interfaces with Ad Cache 240 to access the cache and retrieve the desired ad content. The selected ad content is then provided to the application for display to the user. As an example, for the baseball application, the application may have a dedicated banner area where ads can be rotated into and out of at any time. Thus, when an ad notification is received, the new ad can be placed immediately into the specified region for display to the user.
Similarly, in the case of a video game or other application, the application may embed ad content into the play area at the end of a specific task or at each level. In this case, when an ad notification is received, the game or application may wait for the appropriate time or event to place ad content.
As a further description of the possible manner in which an ad policy may interact with one or more applications executing on a client device, the following describes the interaction between an active display policy and a baseball application in additional detail:
Similarly, the following describes the interaction between an active display policy and an arcade/video game application in greater detail:
As shown in
As suggested by the different sets of ad content 780 (as indicated by boxes 1, 3, and 6 provided to Location 1 of Network 1, boxes 1, 4, and 5 provided to location 2 of Network 1, etc.) provided to the different networks (elements 710 and 720 in the figure), the filtering process is able to select a set of ad content most appropriate for a particular network, location, or expected user population, among other criteria.
A system and associated apparatus and methods to enable the resource-efficient and cost-effective delivery, selection, and display of ad content to devices has been described. The inventive system, apparatus, and methods include the ability to distribute ad content and ad selection policy independently of each other, thereby enabling the update or revision of ad policy in real-time or pseudo real-time to implement changes to the policy in view of current events, emergencies, sporting events, and/or other events.
The inventive system utilizes a broadcast mode of data transfer to provide cost-effective and network resource and infrastructure efficient delivery of data. The inventive system also includes intelligent cache management processes for the determination of what ad content to retain in a local device cache in the event that the cache is not able to store all ad content available to it. Further, the inventive system is capable of collecting and processing tracking data to indicate how ad content was used by the local device, and how a user responded to that ad content. Such content usage data may be utilized in modifying ad policy, determining cache contents, or in determining ad revenue streams or other business models.
The combination of a flexible and real-time updatable ad selection policy and intelligent cache management process provides many benefits in terms of the effective delivery of ad content. For example, the delivery of ad content can be controlled to provide highly relevant ad content to a group of users based on multiple parameters, and the delivery model can be altered on a relatively short timescale.
In this regard, the following examples are intended to suggest how the inventive ad cache management processes and ad display policies may work together to provide a powerful and flexible way to target ads to individual users in a large population:
1. Proposed strategy for fast food restaurants
2. Proposed strategy for television show trailers
As discussed, the ad module executing on each client device may be responsible for ad cache management. This eliminates the need for each application running on the device to perform such management functions itself, and provides predictable, secure control of the cache to the service provider or network operator.
As recognized by the inventors, once targeted ads are present in the cache, applications need a method by which to obtain ads to display to the user. The service provider, network operator, etc. needs to be able to control the mechanism by which those ads are selected and displayed to a user. The service provider, etc. can not be involved each time an application needs to display an ad over the entire population of users in the network. This is because doing so would congest the network, delay delivering ads to the applications, and reduce the benefits of having an ad cache. In addition, real-time control over the selection and display of ads can be of value to the service provider, etc. This problem can be solved by implementing an ad policy delivery system that enables the policy or policy updates to be distributed in real-time to the entire network population or relevant portion thereof.
The ad policy can contain complex instructions, which may be effective for long periods of time, and require infrequent updates. In this case the ad policy can specify different algorithms for different days, or even different times of the day. For example, if the ad policy is generally broadcast once a week, the policy may have certain rules for weekdays and other rules for weekends. If the policy is generally provided once a day, the policy may contain a set of rules for the morning, a different set of rules for the afternoon, and another set of rules for the evening. The ad policy used to select which ad to present to the user from the ad cache can specify an ad rotation scheme or indicate which ads are relevant for particular times of day. The policy can also take into account device dependent data such as user profile, the capabilities of the device, and location of the device. Applications may optionally choose to provide additional context information to the ad module which can be used to supplement the selection process for the ads.
As mentioned, ad policies can be overridden or supplemented during periods or at times when a new, short-term policy is required. For example, at the half-time of a football game, the ad aggregator, etc. may want to show one set of ads instead of another based on the score of the game. Since the score of the game is not known when the ads are cached, or when the primary display policy is distributed, an override policy can be distributed at half time that takes into account the score of the game. Once the short-term period is over, the regular policy may go back into effect.
Further, there may be multiple relationships and interactions between the ad cache and ad policy. The ad cache may be relatively fixed, and a changing ad policy may cause different ads to be selected over time. Similarly, the ad policy may remain fixed while the ad cache changes over time. In addition, both the ad policy and cache may change over time to provide a greater range of functions. Note that changes in the policy do not necessitate refreshing or reloading the ad cache, which can be slow, expensive or network resource intensive.
The ad display and usage statistics can be collected and provided to the service provider on a scheduled basis, or upon request. As noted, ad usage statistics can be used by the service provider for billing and pricing purposes, but may also be used to further refine the ad cache management process or the policies distributed to the user population. The statistics may also be used to support a bidding system for advertisers. In this situation and without needing to repopulate the cache, a policy change may be quickly distributed throughout the network so that an advertiser that outbid another can increase the number of ad displays that their products receive, or the prominence or circumstances under which the ads are displayed.
Among other advantages of the present invention, ad content distribution occurs without the need for devices in the network to initiate a point-to-point communication with an ad server. This is important in a mobile broadcast environment, but also may be applicable and of value in an environment where the server and/or network can not easily handle requests from all devices (or a sufficiently large number) in the network. Though the server may perform a filtering process to choose which ads to distribute, the local devices filter ads to select those that are most relevant for the user of the device. Additionally, the ad cache has a refinement mechanism so that when the cache is full or nearly full, it may replace ads currently in the cache if a new ad is better suited to the user. Another benefit of the cache management and refinement mechanism is that there is a better chance one or more ads will be available for display when the ad cache is being populated since the cache will generally take ads that are not blocked while the cache has room to store them. Thus, if there is room in the cache, an ad will be stored even if it doesn't score high on the specific user's relevance metrics, as long as that ad isn't inappropriate for that user.
As noted, an important aspect of the present invention is that a server maintains and controls the distribution of an ad display policy which controls which ads get displayed at each device. The policy can be distributed real-time to the devices when the policy changes. The ad policy itself is considerably smaller in size than most ads that have previously been cached, making it easier and more resource conserving to distribute to the device population. This is particularly useful in a mobile broadcast environment where the ad policy can be broadcast over the network with little expense and received by all devices listening on that network.
Other advantages of the invention include that it provides an ad module that serves multiple applications on the local client device. This reduces the amount of logic each application needs to implement, since ad cache management, ad policy execution, and reporting metrics are handled by the ad module. This also gives the service provider or other party a trusted mechanism to ensure ads are displayed according to the provider's specifications.
It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software
Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
While certain exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not intended to be restrictive of the broad invention, and that this invention is not to be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those with ordinary skill in the art.
As used herein, the use of “a”, “an” or “the” is intended to mean “at least one”, unless specifically indicated to the contrary.
This application is related to and claims the benefit of U.S. provisional patent application No. 60/862,117, entitled “Distribution And Display Of Advertising”, filed Oct. 19, 2006, the contents of which is incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60862117 | Oct 2006 | US |
