Digital rights management and audience measurement systems and methods

Digital rights management and audience measurement systems and methods are disclosed. An example method includes receiving a request to upload media content to a content distributor, attempting to obtain a code associated with the media content, querying a program information database for program information associated with the media content using the code, and applying a business rule to the media content based on the program information.

FIELD OF THE DISCLOSURE

The present disclosure pertains to monitoring media content and, more particularly, to digital rights management and audience measurements systems and methods.

BACKGROUND

The shift from analog storage of media content to digital storage of media content has led to a rapid increase in the unauthorized distribution of media content. A consumer that purchases a single copy of media content can distribute the content to any number of other parties with little to no cost. In order to delay, discourage, and/or stop such distribution, media content producers and providers have searched for systems that will prevent unauthorized distribution without greatly affecting the ability of authorized holders of media content to enjoy that content. One method for preventing use or unauthorized distribution of media content is through technological access controls, which are often referred to as digital rights management (DRM).

User submitted content sites are websites (e.g., websites on the internet) that allow users to submit content that is made available to others via the website. For example, the website YouTube™ allows users to submit video content that is made available to the public via the website. User submitted content sites historically have not performed active monitoring of content uploaded to the website due to the difficulty in performing such monitoring and the amount of content submitted to the website. Rather, such websites typically only remove content that is not authorized for distribution when the content has been flagged by a user of the site or the site has received a letter from a content owner. Accordingly, user submitted content sites are often used for the distribution of media content that is not authorized for such distribution.

DETAILED DESCRIPTION

Internet-based distribution of content (e.g., audio, video and/or otherwise) offers media producers and distributors (e.g., studios, television stations, etc.) new opportunities to monetize their content by reaching new audiences and/or exploiting the benefits of so called “long tail economics.” The example methods and apparatus described herein facilitate the deployment of media identification and management solutions to ensure media content is legally used and/or the content owners are properly compensated for such use. In addition, the example methods and apparatus provide a mechanism to facilitate targeted advertisement by better understanding the content being viewed and the audience viewing it. At least some of the example methods and apparatus described herein:1) leverage the wide acceptance and/or usage of digital watermarking technology in the broadcast media industry (e.g., the insertion of audience measurement codes). For example, Nielsen, the assignee of this patent, currently cooperates with broadcasters to watermark significant percentages of nationally broadcast content and local content telecast in the U.S.;2) utilize active/passive monitoring (see, for example, Thomas, U.S. Pat. No. 5,481,294) which not only utilizes digital watermark technology, but also employs fingerprinting of content (e.g., collecting signatures and performing signature matching to identify content) which enables the identification of un-encoded content;3) allow content to be identified and/or managed across multiple platforms and across multiple distribution networks, while enabling content consumption to be accurately measured so that content providers and/or advertisers can be compensated appropriately and to provide for better targeting of audience advertisements to desired audiences in conjunction with desired media content;4) provide a formal and/or automated copyright labeling and/or electronic registration system;5) can automatically notify and/or request that operators of user generated content sites act in response to detection of copyright violations. For example, content can be filtered during content upload, and/or copyright management information can be displayed at time of ingestion so that appropriate business rules can be applied. Thus, copyright owners are enabled to shift the burden for take down notifications and/or filtering to the owners of user generated content sites;6) leverage third party detectors, that might be video-based in order to support the identification of copy-righted material that may have non-original audio or mash-up content; and/or7) leverage title search and lexicon related searches to supplement watermarking, fingerprinting (audio and video) detection.

FIG. 1illustrates an example digital rights management (DRM) and audience measurement system100. The example DRM and audience measurement (DRMAM) system100ofFIG. 1may be used to protect and/or to assist in the protection of any type(s) of copyrighted content and/or media such as, for example, audio files, video files, images, printed materials, songs, movies, web sites, advertisements, television (TV) shows and/or any combination thereof. In addition to performing and/or assisting in the performance of DRM, the example DRMAM system100ofFIG. 1may also collect audience measurement information and/or data useful to statistically determine and/or estimate the number and/or demographics of respondents, households and/or persons consuming and/or having an opportunity to consume (i.e., exposed to) any or all of the content managed by and/or within the example DRMAM system100.

As set forth in detail below, the copyright verification and/or audience measurement functions may be achieved in one or more different manners. Some example implementations make use of audience measurement codes which are embedded by broadcasters130(e.g., television and/or radio broadcasters) in broadcasted content to identify content and/or to cross-reference a database to determine if the content is copyrighted and/or authorized for distribution. Because such audience measurement codes may be corrupted and/or removed (intentionally or as part of an encoding/compression process), some examples described below provide for insertion of audience measurement codes at other points in the distribution chain (e.g., at a content distributor160such as YouTube, Google®, and/or Yahoo®, by a browser and/or encoder at a media device105, etc.) and/or for the collection of other content identifiers (e.g., metadata) associated with the content and/or for the collection of one or more signatures representative of such substantially unique characterization of the content.

Irrespective of the method of content identification employed, the collected identification information (e.g., codes, signatures, metadata, etc.) is used to cross-reference a database to determine whether the identified content is copyrighted and/or authorized for further distribution. This information provides a vehicle to enable content providers160such as, for example, YouTube™, Google® and/or Yahoo®, to determine whether to distribute the content (e.g., to decide not to distribute copyrighted material without authorization) and/or provide a vehicle to enable such content distributor160to request and/or obtain authority to distribute the content. The methods and apparatus described herein may also be used for monitoring and detection of media content in a person to person (P2P) network. As a further extension, it enables the content distributor160to pay for and/or facilitate payment for the distribution of copyrighted material.

To facilitate audience measurement, some example implementations discussed below insert one or more machine readable monitoring instructions into content. This can be done in response to an indication that content is authorized for distribution. The machine readable instructions can be written in any language (e.g., Java, JavaScript, etc.) and may be embedded in the content such that accessing the content requires and/or results in execution of the machine readable instructions (e.g., at the media device105). Execution of the instructions results in the collection of audience measurement information (e.g., operating system events at the media device105, user identification information, media device identifier, network address, time of day, time of exposure, fast forward information, number of accesses of content, etc.) and the transfer of the collected audience measurement information to an audience measurement collection site such as DRMAM server150. The monitoring instructions can be operated in accordance with the teachings of, for example, U.S. Pat. No. 6,108,637, entitled “Content Display Monitor,” and issued on Aug. 22, 2000, which is hereby incorporated by reference in its entirety.

The DRM functionality and the audience measurement functionality described herein can be provided by the same or different devices and/or entities.

The example DRMAM system100ofFIG. 1includes any number and/or type(s) of media devices105such as, but not limited to, personal computers, set-top boxes, digital video recorders, MP3 players, compression and/or digitizing equipment, web browsers, smart phones, cellular phones and/or personal digital assistants. The example media devices105ofFIG. 1can obtain, receive, and/or download content from any number and/or types of sources. For example, the media devices105may receive content from any number and/or types of content providers130and/or any number and/or types of content distributors160. The media devices105may receive content from the content providers130via any number and/or types of methods and/or devices including, but not limited to, a satellite communication signal110, a radio frequency signal115(e.g., a cable television signal, an over-the-air signal, etc.), a data communication network (e.g., the Internet120), and/or one or more media store(s)125(e.g., a compact disc (CD), a digital versatile disc (DVD), a video cassette, a hard disk drive (HDD), and/or a memory device).

The example media devices105ofFIG. 1can also upload and/or provide content to any or all of the example content distributors160. Such content may then be made available to other media devices105by the content distributor(s)160. For example, the uploaded content may be downloaded and/or obtained by another media device105. An example content distributor160is a website that allows subscribers to upload, download and/or share media (e.g., movies and/or music) via one or more web pages such as Google® and/or YouTube™. The content distributors160may also receive content from any or all of the content providers130.

To protect, for example, copyrighted materials, the example DRMAM system100ofFIG. 1utilizes and/or implements digital rights management technologies. For example, content of the example DRMAM system100may contain one or more embedded digital watermarks to (a) enable the identification of content owners and/or content creators, to (b) verify the authenticity of content, and/or (c) to determine whether permission to distribute the content has been granted and to whom. As used herein, a “content identifier” is any type of data and/or information associated with, inherent to, embedded with, inferable from and/or injected into a piece of content, and which may be used to identify that piece of content. Audience measurement codes (e.g., audio watermarks, video watermarks, vertical blanking interval (VBI) codes, image watermarks and/or any other watermarks), public or private identifiers in bit streams (e.g., program identification (PID) headers), closed captioning information, metadata or any other type(s) of data can serve as content identifiers. A content identifier, such as an audio and/or video watermark, is generally not noticeable to the audience during playback, but this is not necessarily so. An example data structure that may be used to represent and/or store content identifiers is described below in connection withFIG. 6.

In some examples, the example DRMAM system100ofFIG. 1implements methods and/or apparatus to preserve embedded content identifiers during the uploading of content from a media device105to a content distributor160. However, if content identifiers are not preserved (e.g., because a media device105does not implement the technologies described herein, due to corrupted and/or erroneous content, due to excessive compression, format conversion(s), due to user error, and/or due to malicious activity), the example DRMAM system100ofFIG. 1may identify such potentially corrupted and/or unauthorized content. In some examples, such unauthorized and/or corrupted content may be removed and/or restricted from being distributed, and/or may have content identification information (re-) inserted in order to restore content protection. Such (re-) insertions of content identification information may be performed and/or facilitated by the DRMAM system100, the content distributor106and/or the media device105.

The example DRMAM system100ofFIG. 1may also, in some examples, utilize signatures (e.g., audio signature(s), video signature(s), image signature(s) and/or otherwise) to identify content in the absence of a content identifier (e.g., an audio audience measurement code) and/or when the content has had one or more other content identifiers removed and/or disturbed by a media device105. Signatures may be created based on any portion(s) of a signal that substantially and/or uniquely identify the signal.

The example DRMAM system100ofFIG. 1may, additionally or alternatively, measure and/or estimate the size and/or demographics of an audience exposed to one or more pieces of content. For example, machine executable code (e.g., a JAVA applet, JavaScript, a common gateway interface (CGI) script, etc.) may be inserted into content such that, when a piece of content is downloaded, played, viewed and/or listened to at and/or by a media device105, the media device105executes the machine executable code thereby causing the media device105accessing the content to notify the DRMAM server150of the content consumption. For example, the media device105when executing the machine executable code may send to the DRMAM server150a message containing audience measurement information such as, for example, media device identifier, user identifier, content identifier, consumption time, consumption duration, network location, geographic location, content provider, etc. However, if such machine executable code is not present and/or was not preserved in a piece of content (e.g., due to a media device105not implementing the technologies described herein, due to corruption, due to user error and/or due to malicious activity), the example system100ofFIG. 1may insert and/or restore the machine readable code. For example, the content distributors160and/or the DRMAM server150can use extracted content identifiers (e.g., codes) and/or determined signatures to identify the content and, thus, identify, create, insert and/or re-insert the missing audience measurement machine executable instructions. Methods and apparatus to use machine executable code associated with content to perform audience measurement are described in U.S. Pat. No. 6,108,637, entitled “Content Display Monitor,” and issued on Aug. 22, 2000.

To locate, validate and/or catalog content being managed and/or made available for distribution, the example DRMAM system100ofFIG. 1may include a media crawler170. The example media crawler170ofFIG. 1locates and/or identifies content available to the example media devices105, and then verifies and/or enables another entity to verify that the content distributors160of the located content are authorized to distribute the content. The media crawler170may also compile a list of available content that may be searched (e.g., using a web-based search engine) by the media devices105and/or users of the media devices105. Data collected by the media crawler170may be stored, for example, on, by and/or within the example DRMAM server150. Additionally or alternatively, the example media crawler170may generate one or more reports of located and/or identified content, and/or provide any portion of the collected data to one or more of the content providers130and/or the content distributors160. An example manner of implementing the example media crawler170is described below in connection withFIG. 16.

FIG. 2illustrates an example manner of implementing the example DRMAM server150ofFIG. 1. To store information concerning content protected and/or measured by the example system100ofFIG. 1, the example DRMAM server150ofFIG. 2includes a content database205. An example data structure that may be used to implement the example content database205is described below in connection withFIG. 7. To store information regarding the consumption of and/or exposure to content, the example DRMAM server150ofFIG. 2includes a consumption database235. The example consumption database235records data representative of the consumption of and/or exposure to particular pieces of content at and/or by particular media devices105. Data stored in the consumption database235may be processed to develop meaningful content exposure and/or consumption statistics such as, for example, the overall effectiveness, reach, and/or audience demographics of content.

To interface with content providers (e.g., to receive new content and/or content identifiers, to store received content and/or content identifiers in the content database205, to receive a content check request, etc.), the example DRMAM server150ofFIG. 2includes a content provider interface210. To interface with content distributors (e.g., receive new content and/or content identifiers and/or to verify uploaded content), the example DRMAM server150ofFIG. 2includes a content distributor interface215. To interface with media devices105(e.g., to receive audience measurement information, to receive and/or send content verification/approval information, etc.), the example DRMAM server150ofFIG. 2includes a media device interface230. For example, the media device interface230may receive a ping from a media device105in order to refresh an access license (e.g., a time restricted license). To interface with the media crawler170(e.g., to perform content check requests, to receive information about located equipment and/or content, etc.), the example DRMAM server150ofFIG. 2includes a media crawler interface240. The example interfaces210,215,230and240may be implemented using any number and/or type(s) of protocols (e.g., Internet protocol (IP)) and/or messages.

To extract audience measurement codes (e.g., audio, video, image and/or otherwise) for the content data155, the example DRMAM server150ofFIG. 2includes any type of code engine220(e.g., an audio code engine). Using any type(s) of method(s), algorithm(s), circuit(s), device(s) and/or technique(s), the example code engine220searches, locates and/or decodes codes (e.g., audio codes) from the content data155. As described above, codes are commonly used in the audience measurement industry for the purposes of detecting the consumption of and/or exposure to content. Any methods and systems for insertion and detection of codes may be used such as, for example, Nielsen systems, systems from Thomson, etc. As also described above, codes can be inserted in or associated with content for audience measurement and/or DRM purposes and/or codes can be provided for other purposes (e.g., for timing such as PID headers). However, not all content is associated with codes.

To collect and/or generate signatures (e.g., audio, video, image and/or otherwise) for the content data155, the example DRMAM server150ofFIG. 2includes any type of signature engine225(e.g., an audio signature engine). Using any type(s) of method(s), algorithm(s), circuit(s), device(s) and/or technique(s), the example signature engine225ofFIG. 2processes the content data155to determine and/or generate one or more fingerprints and/or signatures that substantially identify and/or uniquely identify the content data155. Any methods and systems for collection and/or generation of signatures may be used such as, for example, Nielsen systems, systems from Thomson, etc. An example audio signature may be computed via data compression applied to an audio portion of the content data155.

To extract other types of content identifiers in addition to, or instead of, content identifiers extracted, collected and/or generated by the example code engine220and/or the example signature engine225(e.g., public and/or private identifiers contained in bit streams, closed captioning information, program guide information, and/or metadata) for the content data155, the example DRMAM server150ofFIG. 2includes any type of content identifier engine245. Using any type(s) of method(s), algorithm(s), circuit(s), device(s) and/or technique(s), the example content identifier engine245searches, locates and/or decodes content identifiers for the content data155. However, not all content has inserted content identifiers. The content identifier engine245and the code engine220may be combined and/or one or both of those structures may be eliminated to suit a particular implementation. Similarly, the signature engine225may be eliminated and/or combined with one or both of the content identifier engine245and/or the code engine220.

While an example manner of implementing a DRMAM server150has been illustrated inFIG. 2, one or more of the data structures, elements, processes and/or devices illustrated inFIG. 2may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any way. Further, the example databases205and235, the example interfaces210,215,230and240, the example engines220,225and245, and/or, more generally, the example DRMAM server150may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Further still, the example DRMAM server150may include data structures, elements, processes and/or devices instead of, or in addition to, those illustrated inFIG. 2and/or may include more than one of any or all of the illustrated data structures, elements, processes and/or devices.

FIG. 3illustrates an example manner of implementing any or all of the example content distributors160ofFIG. 1. To allow media device(s)105to download content from a content store305, the example content distributor160ofFIG. 1includes any type of content download interface310such as, for example, any type of Web-based interface (e.g., one or more web pages).

To allow media device(s)105to upload and/or provide content, the example content distributor160ofFIG. 3includes a content upload interface315such as, for example, any type of web-based interface (e.g., one or more web pages). The example content upload interface315ofFIG. 3provides uploaded and/or received content to a content authorizer320. The example content authorizer320verifies whether the content distributor160is authorized and/or allowed to distribute the uploaded content before the content is stored in the content stores305and/or made available to the media devices105. Additionally or alternatively, the content authorizer320can check the validity of the content (e.g., authorization to distribute the content) during download and/or when a request to download the content has been received at the content distributor160. In some examples, the example content authorizer320is provided and/or licensed by, for example, the owner and/or operator of the example DRMAM server150to, for example, the owner and/or operator of the example content distributor160ofFIG. 3. For example, the content authorizer320could be implemented by a standalone computing platform and/or one or more pieces of software and/or firmware to which other portions of the example content distributor160interface via, for example, a content authorization application programming interface (API). In some examples, the example content authorizer320sends an instruction(s) to the media device105via the content upload interface. The instruction(s) can, for example, instruct the media device105how to handle the media content (e.g., disable the media content, prevent access to the media content, destroy the media content, set an expiration date for the media content, reduce the quality for presentation of the media content, etc.). For example, the content authorizer320may send to the media device105an instruction to destroy media content when it is determined that the media content is not authorized for distribution and/or presentation.

FIG. 4Aillustrates an example manner of implementing the example content authorizer320ofFIG. 3. To extract and/or verify content identifiers present in uploaded content (e.g., an audience measurement code, metadata, public identifiers and/or private identifiers), the example content authorizer320ofFIG. 3includes a content identifier checker405. The example content identifier checker405ofFIG. 4Amay utilize one or more audience measurement codes (e.g., audio, video, image and/or otherwise) extracted by any type of code engine410, and/or may extract any other types of content identifier(s) from the content (e.g., identifiers within metadata and/or identifiers associated with or embedded within the audio, image and/or video data325). The example content authorizer320ofFIG. 4includes a signature engine415to extract, generate, and/or compute a signature (or any unique or semi-unique identification parameter) of the media content. The example signature engine415transmits extracted signatures and/or other identifications to the DRMAM server interface420. The example content authorizer320includes a metadata extractor418to extract metadata (i.e., any information associated with media content (e.g., embedded in, transmitted with, or otherwise associated with the media content)) from the media content and transmit the metadata to the DRMAM420. For example, the metadata extractor418may extract embedded metadata and/or may access a datastore that stores metadata associated with media content. For example, the metadata may be program information (e.g., titles, descriptions, authors, actors/actresses, genres, etc. The metadata may be used to identify media content. For example, media content may be identified using the title extracted from metadata.

In some examples, any or all of the content identifier checker405, the code engine410, the signature engine415(e.g., an audio signature engine), and/or the metadata extractor418are not implemented by the content authorizer320. In such examples, the extraction and/or determination of codes, signatures and/or other content identifiers may be performed at the DRMAM server150. Similarly, some or all of the content authorizer320may be located and/or implemented at another location. For example, the content authorizer320may be implemented by the DRMAM server150, and/or by and/or within a media device105used to download content from a content distributor160(e.g., it could be implemented as a permitted and/or licensed plug-in to and/or for programs developed and/or sold by, companies such as Macromedia, Microsoft, Real, etc.).

To verify whether the content distributor160is authorized and/or allowed to distribute the content325in question, the example content authorizer320ofFIG. 4Aincludes a DRMAM server interface420. The example DRMAM server interface420ofFIG. 4Aoutputs and/or provides content identifiers (e.g., metadata, signatures, audience measurement codes, and/or other identifiers) extracted and/or checked by the content identifier checker405, the code engine410and/or the signature engine415to a DRMAM server150. The DRMAM server150validates the information received from the content authorizer320and responds with information indicating whether the content distributor160is authorized to distribute the content. If the content distributor160is authorized to distribute the content, the content authorizer320may receive watermark data and/or machine readable audience measurement instructions to be embedded in and/or associated with the content. In some examples, the DRMAM server150and/or the content authorizer320notifies a content provider130when any of its content is detected at a content distributor160that implements and/or includes the content authorizer320.

To prepare authorized content for distribution, the example content authorizer320ofFIG. 4Aincludes any type of content identifier inserter425(e.g., an encoder that re-encodes the content after adding a digital content identifier and/or adds a content identifier directly to the already encoded content), any type of instruction inserter430(e.g., that inserts machine executable instruction(s) and/or a reference to any type of executable instruction(s) into any portion of the content (e.g., the metadata) to be executed when the content is accessed), and/or any type of packager435(e.g., that creates and/or stores the content in a data structure suitable for storage in the content stores305). To store and/or access the packaged content stored by and/or within the content stores305, the example content authorizer320ofFIG. 4Aincludes a content stores interface440.

To download and/or provide requested content, the example content authorizer320ofFIG. 4Aincludes the content store interface440and a downloader445. When content is requested by the example content download interface310, the content store interface440ofFIG. 4Aretrieves the requested content from the content stores305and provides the retrieved content to one or more of the content identifier checker405, the code engine410, the signature engine415, and/or the metadata extractor418. As described above, the content identifier checker405, the code engine410, the signature engine415, the signature engine415, and/or the DRMAM server interface420then verify that the requested content is authorized to be downloaded. However, authorization to download content need not be performed when the download is performed. For example, content distribution authorization may be checked and/or verified during upload thereby eliminating the need to perform distribution authorization during download, and/or content distribution authorization may be checked and/or verified on content already stored (but possibly not previously checked and/or verified) in the content stores305(e.g., in an offline processing model). However, the verification of authorization during download allows a content provider130and/or the DRMAM server150to change content distribution privileges over time, and/or to maintain and/or monitor the authenticity of content stored by and/or within the content stores305.

When the DRMAM server interface420receives an indication that the requested content is authorized to be downloaded, the example downloader445ofFIG. 4Aprovides the content retrieved by the example content store interface440to the example content download interface310. However, if the authorization of the content is not to be verified, the downloader445provides the retrieved content to the content download interface310without waiting for direction from the DRMAM server interface420. Moreover, if content identifiers and/or machine executable audience measurement instructions are to be inserted into or otherwise associated with the retrieved content, the retrieved content may be first processed by one or more of the content identifier inserter425, the instruction inserter430and/or the packager435.

FIG. 4Billustrates another example manner of implementing the example content authorizer320ofFIG. 3. To interact with a processing server (e.g., the example DRMAM server150and/or a Nielsen Back Office), the example content authorizer320ofFIG. 4Bincludes a back office interface450. The example back office interface450ofFIG. 4Bmay be used to send metadata codes and/or signatures for the content325to a processing server to obtain distributor and/or content owner information, and/or the date and/or time at which content325was broadcast.

To obtain television guide information, the example content authorizer320ofFIG. 4Bincludes a television guide database interface455. The example television guide database interface455may be used to query a television guide database server to obtain metadata, program name, program description, genre, etc. for the content325.

To obtain content consumption ratings, the example content authorizer320ofFIG. 4Bincludes a ratings database interface460. The example ratings database interface460ofFIG. 4Bmay be used to query a ratings database server (e.g., one or more Nielsen Company databases) to obtain historical and/or current ratings and/or demographics information and/or data for the content325.

To extract codes from the content325or a signal (e.g., a digital data stream) associated with the content, the example content authorizer320ofFIG. 4Bincludes a code extractor465. The example code extractor465ofFIG. 4Bsearches for, identifies and/or extracts one or more codes (e.g., audio, video, image, and/or otherwise) contained in or associated with the content325.

To identify a content owner and/or distributor, the example content authorizer320ofFIG. 4Bincludes a distributor and/or content owner identifier470. For example, based on one or more codes obtained by the example code extractor465, the example distributor and/or content owner identifier470ofFIG. 4Bdetermines a content owner and/or distributor for the content325by using the code(s) to index a database mapping codes to content owners and/or distributors. Additionally or alternatively, the example distributor and/or content owner identifier470may utilize the example back office interface450ofFIG. 4Bto obtain the content owner and/or distributor for the content325, for example, by passing obtained codes to the back office for code matching.

To determine (e.g., compute) signatures, the example content authorizer320ofFIG. 4Bincludes any type of signature engine475(e.g., an audio signature engine). Using any type(s) of method(s), algorithm(s), circuit(s), device(s) and/or technique(s), the example signature engine475ofFIG. 4Bprocesses the content data325to determine and/or generate one or more fingerprints and/or signatures that substantially identify and/or uniquely identify the content data325. An example signature may be computed via applying data compression to an audio portion of the content data325.

If the example code extractor465ofFIG. 4Bcannot identify suitable codes in or associated with the content325, signatures generated by the example signature engine475may be used by the example distributor and/or content owner identifier470and/or the example back office interface450to identify the content owner and/or distributor for the content325. Alternatively, codes and signatures can both be used to reduce the search space and/or for other purposes.

To implement business and/or copyright rules for uploaded content325, the example content authorizer320ofFIG. 4Bincludes a business rules agent480. The example business rules agent480ofFIG. 4Bautomatically applies one or more rules such as, for example, removing copyrighted content, paying a royalty to the content owner, negotiating a license for the content325with the content owner, adding the content325to an existing content owner contract, etc.

To associate advertisements with the content325, the example content authorizer320ofFIG. 4Bincludes an advertising agent485. The example advertising agent485ofFIG. 4Buses historical and/or current ratings data and/or information (e.g., obtained via the example ratings database interface460) and metadata (e.g., obtained via the television Guide database interface455) to identify (e.g., identify an advertisement that is related to the media content, identifying an advertisement or advertiser that desires to advertise with the media content, match the media content to criteria indicated by an advertiser, etc.) and/or negotiate (e.g., indicate a requested cost for displaying an advertisement) with advertisers that may be interested in having their advertisements associated with the content325. Such advertisements could be provided and/or displayed when the content325is downloaded by, for example, a user of the example content distributor160ofFIG. 3.

While an example manner of implementing any or all of the content distributors160ofFIG. 1has been illustrated inFIGS. 3,4A and/or4B, one or more of the data structures, elements, processes and/or devices illustrated inFIGS. 3,4A and/or4B may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example interfaces310,315,420,440,450,455and460, the example content stores305, the example content authorizer320, the example watermark checker405, the example engines410,415,418, the example watermark inserter425, the example instruction inserter430, the packager435, the example downloader445, the example code extractor465, the example distributor and/or content owner identifier470, the example signature engine475, the example business rules agent480, the example advertising agent485and/or, more generally, the example content distributor160ofFIGS. 3,4A and/or4B may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example interfaces310,315,420,440,450,455and460, the example content stores305, the example content authorizer320, the example watermark checker405, the example engines410,415,418, the example watermark inserter425, the example instruction inserter430, the packager435, the example downloader445, the example code extractor465, the example distributor and/or content owner identifier470, the example signature engine475, the example business rules agent480, the example advertising agent485and/or, more generally, the example content distributor160ofFIGS. 3,4A and/or4B could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. When any of the appended claims are read to cover a purely software implementation, at least one of the example interfaces310,315,420,440,450,455and460, the example content stores305, the example content authorizer320, the example watermark checker405, the example engines410,415,418, the example watermark inserter425, the example instruction inserter430, the packager435, the example downloader445, the example code extractor465, the example distributor and/or content owner identifier470, the example signature engine475, the example business rules agent480, the example advertising agent485and/or, more generally, the example content distributor160ofFIGS. 3,4A and/or4B are hereby expressly defined to include a tangible medium such as a memory, DVD, CD, etc. Further still, the example content distributor160may include data structures, elements, processes and/or devices instead of, or in addition to, those illustrated inFIGS. 3,4A and/or4B, and/or may include more than one of any or all of the illustrated data structures, elements, processes and/or devices.

FIG. 5illustrates an example manner of implementing any or all of the example media devices105ofFIG. 1. To control the overall operation, the example media device105ofFIG. 5includes any type of controller and/or processor505. The controller505may be implemented by one or more general purpose processors, processor cores, microcontrollers, etc.

To interface with any or all of the example content providers130, any or all of the example content distributors160, and/or the example DRMAM server150, the example media device105ofFIG. 5includes a content provider interface510, a content distributor interface515and an audience measurement interface520, respectively. The example interfaces510,515and520may be implemented using any protocol(s) (e.g., IP) and/or messages. To store content, the example media device105ofFIG. 5includes any number and/or types of storage device interface525that facilitates storage of content on any number and/or types of storage devices such as, for example, a hard disk drive (HDD), a compact disk (CD), a digital versatile disk (DVD), a memory and/or a memory device.

To play and/or view content, the example media device105ofFIG. 5includes any number and/or types of content decoders530(e.g., a JPEG decoder, an MP3 decoder and/or an MPEG decoder) and any number and/or types of content output devices535(e.g., a display, a screen and/or a speaker). To encode content (e.g., prior to transmission to a content distributor160), the example media device105ofFIG. 5includes an encoder540. In some examples, the encoder540preserves any content identifiers (e.g., watermarks, codes, metadata, etc.) and/or any audience measurement executable instructions present in the content by, for example, removing them and then re-inserting them after and/or during content encoding. For example, the decoder530and/or the encoder540transcode (e.g., decode and then encode in a different format) and/or converts content received via any of the example interfaces510,515and525between one or more formats thereby causing the content to be suitable for upload to, for example, a content distributor160. In particular, the encoder540can implement a content identifier engine (e.g. a code engine) to detect content identifiers contained in the content, and/or to re-insert and/or encode the content identifiers for a new content format. Methods and apparatus to transcode content and/or content identifiers are described in U.S. Patent Publication No. 2006/0242325, entitled “Methods and Apparatus for Transcoding Metadata,” and published on Oct. 26, 2006, which is hereby incorporated by reference in its entirety.

While the blocks ofFIG. 5are described as implementing the media device105, the same or substantially similar blocks may be used to implement a device at a content distributor (e.g., the content distributor160), at a content provider (e.g., the content provider130), or device or system. For example, the content distributor160may transcode media content using similar blocks to those described in conjunction withFIG. 5.

While an example manner of implementing any or all of the media devices105ofFIG. 1has been illustrated inFIG. 5, one or more of the data structures, elements, processes and/or devices illustrated inFIG. 5may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any way. Further, the example controller505, the example interfaces510,515,520and525, the example decoder530, the example playback device535, the example encoder540and/or, more generally, the example media device105may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example controller505, the example interfaces510,515,520and525, the example decoder530, the example playback device535, the example encoder540and/or, more generally, the example media device105could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. When any of the appended claims are read to cover a purely software implementation, at least one of the example controller505, the example interfaces510,515,520and525, the example decoder530, the example playback device535, the example encoder540and/or, more generally, the example media device105are hereby expressly defined to include a tangible medium such as a memory, DVD, CD, etc. Further still, the example media device105may include data structures, elements, processes and/or devices instead of, or in addition to, those illustrated inFIG. 5, and/or may include more than one of any or all of the illustrated data structures, elements, processes and/or devices. For example, the media device105may include some, all or any portion(s) of the example content authorizer320ofFIGS. 4Aand/or4B to determine an authorization to upload, distribute, download, consume, play and/or otherwise process content.

FIG. 6illustrates an example data structure that may be used to represent and/or store content. To represent information about content, the example data structure ofFIG. 6includes any amount and/or types of metadata605. For example, the metadata605may include information concerning content ownership, content creation date, encoding data rate, and/or may contain and/or link to machine executable instruction(s)610(e.g., a JAVA applet, JavaScript, etc.) that can be executed to collect and send audience measurement data at a media device105accessing content associated with instructions added to send the collected data to a DRMAM server150.

To store content data and any embedded watermark(s) (e.g., audience measurement codes), the example data structure ofFIG. 6includes data615. The example data615may be implemented in accordance with any past, present and/or future specification and/or standard (e.g., MP3, JPEG, MPEG-3, etc.).

FIG. 7illustrates an example data structure that may be used to implement the example content database205ofFIG. 2. The example data structure ofFIG. 7contains a plurality of entries705for respective ones of a plurality of content being managed by and/or for which audience measurement data is to be collected. To identify a piece of content, each of the example entries705ofFIG. 7includes a reference identifier field (e.g., containing an integer value) that uniquely identifies the piece of content. To identify a media type (e.g., Windows Media Video (WMV), QuickTime, Flash, Moving Picture Experts Group Layer 3 (MP3), Joint Photographic Experts Group (JPEG), portable document format (PDF), etc.), each of the example entries705ofFIG. 7includes a media type field712. To store metadata, each of the example entries705ofFIG. 7includes a metadata field715that stores the content's metadata (e.g., content provider, program name, performer(s), actor(s), parental guide information, audience ratings, content guidance rating, etc.). To store information representative of who is authorized to distribute the content, each of the example entries705ofFIG. 7includes an authorization information field720(e.g., containing a list of authorized content distributors160).

To store information concerning content identifiers (e.g., audience measurement codes, PID headers, other codes) and/or signatures, each of the example entries705ofFIG. 7includes a content identifier(s) field725, and a signature(s) field730. To store machine executable instruction(s) and/or a reference to the same that may be executed to provide audience measurement information concerning, for example, monitoring a media device105accessing the associated content, each of the example entries705ofFIG. 7includes an executable instruction(s) field735. To store information concerning media devices105that uploaded the content, each of the example entries705ofFIG. 7includes a device identifier(s) field740. The example device identifier(s) field740ofFIG. 7contains one or more values and/or strings that represent a sequence of characters identifying one or more media devices105and/or content distributors160that may have transcoded, transmitted, shared and/or uploaded the content. This identification information may include device serial number, IP address, a license number, an authentication parameter, and/or a combination thereof. Information in the example metadata field715and/or information in the example device identifier(s) field735may be used to track and/or determine who has modified and/or distributed the content. For example, the metadata field715can identify an originating content distributor130, and the device identifier(s) field704can identify the particular user (and/or media device105) that uploaded the content and/or identify the particular content distributor160who distributed the content.

While example data structures have been illustrated inFIGS. 6 and 7, the content database205and/or content may be implemented using any number of additional and/or alternative fields and/or entries.

FIGS. 8-13illustrate example manners of operating and/or implementing the example DRMAM system100ofFIG. 1. In the illustrated example ofFIG. 8, the media device105receives content from a content provider130(block802), and then encodes the received content (e.g., to apply additional compression and/or to format the content prior to upload to a particular content distributor160) (block804). When the media device105uploads the content to the content distributor160(block806), the content distributor160checks if the uploaded content contains a valid content identifier (ID) (e.g., a content identification code or any other type of code) (block808). In the example ofFIG. 8, the content contains a valid content identifier, and the content distributor160sends an authorization check request to the DRMAM server150(block810). The DRMAM server150then determines if the content distributor160is authorized to distribute the content (block812). In the illustrated example, the content distributor160is authorized to distribute the content and, thus, the DRMAM server150sends an authorized response to the content distributor160(block814). The content distributor160notifies the media device105of the authorized upload (block816), creates and/or associates machine readable instruction(s) with the content (block818) and then stores the content for distribution to media devices105(block820). The instruction(s) are associated with the content such that, when the content is accessed by a media device105, the media device105will execute the audience measurement instruction(s) to collect audience measurement data and forward the same to an audience measurement site such as the DRMAM server150.

The illustrated example ofFIG. 9is similar to the example described above in connection withFIG. 8but in this example, the content is not authorized for distribution. In the illustrated example ofFIG. 9, the media device105receives content from a content provider130(block902), and then encodes the received content (e.g., to apply additional compression and/or to format the content prior to upload to a particular content distributor160) (block904). When the media device105uploads the content to the content distributor160(block906), the content distributor160checks if the uploaded content contains a valid content identifier (ID) (e.g., a code) (block908). In the example ofFIG. 9, the content contains a valid content identifier, and the content distributor160sends an authorization check request to the DRMAM server150(block910). The DRMAM server150then determines if the content distributor160is authorized to distribute the content (block912). However, in the illustrated example ofFIG. 9, in contrast to the example ofFIG. 8, the content distributor160is not authorized to distribute the content. Accordingly, the DRMAM server150sends an authorization failed response to the content distributor160(block914) who, subsequently sends an upload rejected response (which may or may not identify the reason for the rejection as a copyright issue) to the media device105(block916). In addition, the content distributor160(e.g., the DRMAM server interface420, the content identifier checker405, etc.) and/or the DRMAM server150may send an instruction or indication to the media device105that instructs and/or forces the media device105to delete, disable, revoke a license, or prevent access to the media content. For example, if the DRMAM server150and/or the content distributor160determines that the media content is not authorized for presentation by the media device105, the DRMAM server150and/or the content distributor160sends an instruction to the media device105to erase the media content, establish an expiration date upon which the media content becomes unusable, display a warning message at the media device, etc. The media device105may then transmit an indication, notification, message, etc. to the content distributor160and/or the DRMAM server150indicating that the media content was or was not successfully deleted.

The illustrated example ofFIG. 10proceeds similar to that described above in connection withFIG. 8, but in this example, no content ID is present in the media content. In the illustrated example ofFIG. 10, the media device105receives content from a content provider130(block1002). At some later point in time (e.g., seconds, minutes, hours, days, weeks, months, and/or years), the media device105encodes the received content (e.g., to apply additional compression and/or to format the content prior to upload to a particular content distributor160) (block1004). When the media device105uploads the content to the content distributor160(block1006), the content distributor160checks if the uploaded content contains a valid content identifier (ID) (e.g., an audience measurement code) (block1008). However, in the illustrated example ofFIG. 10, the uploaded content received by the content distributor160does not contain a content identifier (block1008). The content distributor160generates one or more signatures (e.g., audio, video, image and/or otherwise) (block1010), and sends an authorization request to the DRMAM server150containing the generated signature(s) (block1012). The DRMAM server150then checks the signatures (block1014) and determines if the content distributor160is authorized to distribute the content (block1016). In the illustrated example, the content distributor160is authorized to distribute the content and, thus, the DRMAM server150sends an authorized response to the content distributor160(block1018). Moreover, because the content did not contain a content identifier, the DRMAM server150includes one or more content identifiers in its response (block1018). The content distributor160notifies the media device105of the authorized upload (block1020), adds the content identifier(s) to the content (block1022), creates and/or associates machine readable instruction(s) with the content (e.g., executable code to collect audience measurement information or enforce digital rights management rule) (block1024) and then stores the content for distribution to media devices105(block1024).

In the example ofFIG. 10, content identifiers may be, for example, an audience measurement code (e.g., audio, video, image and/or otherwise) inserted into or otherwise associated with the content by, for example, a content broadcaster130or a content distributor160to identify the content as is commonly done today in the audience measurement industry. Other types of codes and/or metadata could additionally or alternatively be employed. If such a content identifier is not present, the content distributor160can collect and/or compute one or more signatures of the content signal to facilitate identification of the content signal by comparison of the collected and/or computed signature(s) against a database of signature(s). The content distributor160may also collect such signatures when a content identifier is present (in whole or in part as might occur due to noise or compression), and/or may collect other codes such as program identification headers (PIDs) for digital program streams, metadata associated with the content, or any other available indicator to facilitate identification of the content. In some examples, when a content distributor160inserts content identifiers into content, they, among other things, identify that the content distributor160(e.g., local television station, YouTube, etc.) is distributing the content and also identify the originating content provider130(e.g., NBC®) of the content. Thus the content identifier(s) can be used to specify and/or identify either or both the source and the distributor(s) of the content.

The illustrated example ofFIG. 11proceeds similar to that described above in connection withFIG. 10, but no signature is created at the content distributor160. In the illustrated example ofFIG. 11, the media device105receives content from a content provider130(block1102), and, at some later time and/or date, encodes the received content (e.g., to apply additional compression and/or to format the content prior to upload to a particular content distributor160) (block1104). When the media device105uploads the content to the content distributor160(block1106), the content distributor160checks if the uploaded content contains a valid content identifier (ID) (e.g., an audience measurement code) (block1008). In the illustrated example ofFIG. 11, like the example ofFIG. 10, the uploaded content received by the content distributor160does not contain a content identifier. However, rather than generating a signature(s) in the illustrated example ofFIG. 11, the content distributor160transfers the content to the DRMAM150(block1110), and the DRMAM server150, rather than the content distributor160, collects and/or generates the signature(s) (e.g., audio, video, image and/or otherwise) (block1112). The DRMAM server150checks the signature(s) (block1114) and then determines if the content distributor160is authorized to distribute the content (block1116). In the illustrated example, the content distributor160is authorized to distribute the content and, thus, the DRMAM server150sends an authorized response to the content distributor160(block1118). Moreover, because the content did not contain a content identifier, the DRMAM server150includes one or more content identifiers in its response (block1118). The content distributor160notifies the media device105of the authorized upload (block1120), adds the content identifier(s) to the content (block1122), creates and/or associates machine readable (audience measurement and/or DRM) instruction(s) with the content (block1124) and then stores the content for distribution to media devices105(block1124).

In the illustrated examples ofFIGS. 8-11, the content distributor160and/or the DRMAM server150check and/or determine the authorization to upload, store and/or download content. However, the example media device105may, additionally or alternatively, attempt to detect content ID(s), compute signatures and/or use the same to determine whether the device is authorized to upload and/or download the content in question. For example, the media device105may contain, include and/or implement all or any portion of any or all of the example content authorizers320ofFIGS. 3,4A and/or4B, and/or include functionality and/or an interface so that the media device105may interact with the DRMAM server150(i.e., without going through the content distributor160) to authorize a content upload and/or download.

The examples ofFIGS. 12 and 13illustrate the operation of the media device105during the display and/or playback of content. Because the operations are similar,FIGS. 12 and 13are described together. The media device105receives content from the content provider130(FIG. 12) or a content distributor160(FIG. 13) (block1202/1302). The media device105decodes the content (block1204/1304). If the received content contains one or more machine executable (audience measurement and/or DRM) instructions (e.g., in the metadata of the content, as part of an HTML file, as a reference to retrieve such instructions from a network server, etc.) (block1206/1306), the media device105executes the instructions before, during or after it displays the content, performs the associated operation (e.g., sends a notification to the DRMAM server150, etc.) and sends audience measurement information such as a playback notification or user interaction information to the DRMAM server150(e.g., destroys the content after a set number of accesses, etc.) (block1208/1308).

FIG. 14is a flowchart representative of example machine accessible instructions which may be carried out to implement any or all of the example media devices105described herein. The flowchart ofFIG. 14begins when the example controller505of the example media device105extracts (or attempts to extract) one or more content ID(s) from the media content (block1405). The controller505then extracts and/or retrieves (or attempts to extract and/or retrieve) one or more executable instruction(s) from the media content (or from a networked location specified by an instruction associated with the content) (block1410). For example, the controller505may determine if the content includes one or more content ID(s) and/or one or more executable instruction(s) (or references to such instructions) such as a call to a JAVA applet) before attempting to perform extraction.

Next, the example content decoder530decodes the content (block1415) and the example content encoder540encodes the content1420(block1420). For example, the content may be decoded and encoded (i.e., transcoded) to convert the content from a first encoding format to a second encoding format (e.g., when media content is to be uploaded to a website that requires a format different than the original format of the media content). After the media content is transcoded, the example controller505determines if one or more content ID(s) were found in block1405(block1425). If one or more content ID(s) were not found (block1425), control proceeds to block1435, which is described below.

If one or more content ID(s) were found (block1425), the controller505inserts the content ID(s) into the transcoded media content or otherwise associating the content ID(s) with the transcoded media content (block1430). For example, decoding (block1415) and encoding (block1420) may remove the content ID(s) or cause the content ID(s) to be rendered unreadable. Therefore, the controller505re-associates the content ID(s) detected at block1405. Alternatively, if decoding (block1415) and encoding (block1420) does not affect the content ID(s), block1425and/or block1430may be skipped.

The example controller505then determines if one or more executable instruction(s) were found in block1410(block1435). If one or more executable instruction(s) were not found in block1410(block1435), control proceeds to block1445, which is described below. If one or more executable instruction(s) were found in block1410(block1435), the example controller505associates the executable instructions (or a link to the same) with the media content (block1445). For example, decoding (block1415) and encoding (block1420) may remove the executable instruction(s) (and/or the link to the same) or cause the executable instruction(s) (or the link/reference to the instructions) to be rendered unreadable. Therefore, the controller505reinserts the executable instruction(s) extracted in block1410. Alternatively, if decoding (block1415) and encoding (block1420) does not affect the executable instruction(s), block1435and/or block1440may be skipped.

The example controller505of the example media device105then stores the re-encoded media content and/or uploads the media content to a content distributor (block1445).

FIGS. 15A and 15Bare flowcharts representative of example machine accessible instructions that may be carried out to implement any or all of the example content distributors160described herein. For example, the example machine accessible instructions may process media content that is uploaded to a content distributor160(e.g., a content distributor website).

The flowchart ofFIG. 15Abegins when the content authorizer320of the content distributor160in question determines if a media content at the example content distributor160includes or is associated with one or more content ID(s) (block1504). If the content authorizer320determines that one or more content ID(s) were found (block1504), the counter authorizer320uses the content ID(s) to authorize the content (block1516). The content authorizer320may use any method for authorizing identified content such as, for example, reviewing authorization records for the content ID(s) available at the content distributor160(e.g., stored in the content stores305), requesting authorization for the content associated with the content ID(s) from the DRMAM server150, etc. In addition, the content authorizer320may verify the content ID(s) prior to authorizing the content. For example, the content authorizer320may verify a signature or metadata associated with the content containing the content ID(s) matches a signature or metadata associated with reference content associated with the content ID(s). Such a match limits or avoids the possibility of spoofing (e.g., associating false content ID(s) with unauthorized content to pass the content off as other content).

If the content authorizer320determines that one or more content ID(s) were not found (block1504), the content authorizer320generates one or more signature(s) for the media content (block1508). The content authorizer320then uses the signature(s) for authorizing the content (block1512). The content authorizer320then determines if the content was authorized for upload/use (block1520). If the content was not authorized for upload/use (block1520), the content authorizer320notifies the content owner and/or content distributor of the unauthorized content (block1524). The content authorizer320then rejects the upload request (block1528). The machine readable instructions ofFIG. 15Aare then complete. The operations of blocks1524and1528may differ in alternative implementations. For example, notifications may be sent out but the content upload may be allowed or the content upload may be allowed while notifications are not sent. Alternatively, any other desired operation may be performed such as, for example, labeling the content, assigning the content to a category, marking the content for human review, requesting further information from the person uploading the content (e.g., requesting credentials that establish authorization for uploading the content), etc.

If the example content authorizer320determines that the content is authorized for upload/use (block1520), the content authorizer320determines if the media content is associated with (e.g., includes or links to) machine executable instructions (block1532). If it is determined that the media content is associated with executable instructions (block1532), control proceeds to block1540, which is described below. If it is determined that the uploaded media content does not include executable instructions (block1532), the content authorizer320of the illustrated example identifies and/or creates executable instructions and associated executable instructions with the media content to be stored (block1536). For example, the content authorizer320may extract and/or generate identifying information based on the media content and may request suitable machine executable instructions (e.g., for audience measurement and/or DRM purposes) from the DRMAM server150.

The content authorizer320then determines if the uploaded media content includes one or more content ID(s) (block1540). If the media content includes one or more content ID(s), control proceeds to block1548, which is described below. If the media content does not include one or more content ID(s) (block1540), the content authorizer320creates and associated one or more content ID(s) with the media content (block1544). For example, the content authorizer320may use the next number in a list of consecutive content ID(s), may generate a content ID based on metadata associated with the media content, may retrieve a content ID from an external source (e.g., the DRMAM server150), etc. The created content ID(s) are stored in association with the identity of the content and/or its DRM authorization rules for later use.

After adding any machine executable instructions, if necessary, (blocks1532and1536) and/or adding any content ID(s), if necessary, (blocks1540and1544), the content authorizer320stores the media content in the content stores305. The machine readable instructions ofFIG. 15Aare then complete.

According to the illustrated example, the flowchart ofFIG. 15Bis performed after the flowchart ofFIG. 15Ahas been performed. Alternatively, the flowchart ofFIG. 15Bmay be performed at any other time with respect to the flowchart ofFIG. 15Aor may be performed exclusive of performance ofFIG. 15A.

The flowchart ofFIG. 15Bbegins when the code extractor465ofFIG. 4Bof the example content authorizer320ofFIG. 3attempts to extract one or more codes (e.g., codes) from media content stored at the content authorizer320(e.g., media content stored in the content stores305) (block1560). The code extractor465then determines if a code was found (block1564). If a code was found (block1564), control proceeds to block1580, which is described below.

If a code is not found (block1564), the example signature engine475computes, generates, and/or extracts a signature of the media content (block1568). Then, the signature engine475uses the back office interface450to query a back office to identify the content in question based on the signature (block1572). For example, the signature engine475may send a generated signature to the DRMAM server150, an audience measurement back office, etc, and request identification of media content associated with that signature. The example signature engine475then determines if a match was found based on the signature (block1576). For example, the signature engine475determines if an identification of the media content in question was received. If a match was not found (block1576), the machine readable instructions ofFIG. 15Bterminate. For example, if a match is not received, it may be determined that the media content is unidentifiable or is not being tracked. In such a case, the content may be considered public domain and freely distributed. Other DRM rules may alternatively be applied.

If a match for the media content is found (block1576), the television guide database interface455queries a television guide database for metadata associated with the identified media content (block1580). The television guide database may be any type of database that stores information about media content such as, for example, a database providing program scheduling and description information for a television service provider, a database provided by an audience measurement services company, etc. The ratings database interface460then queries a ratings database to obtain ratings information, audience demographic information etc. associated with the identified media content or with second media content with which the first media content may be displayed (block1584). Next, the business rules agent applies business rules for the content based on the television guide information and/or the ratings information (block1588). For example, the business rules may specify that copyrighted media content is to be removed, a royalty is to be paid to the content owner, a license is to be negotiated with the content owner, the content is to be added to a content owner contract, etc. Rules based on ratings or demographics may also be applied. For example, distribution of the content may only be permitted to media devices associated with certain demographics and/or media content may only be distributed if it has a rating above or below a threshold and/or within a range of ratings. Next, the advertisement agent485generates an advertisement model for the media content (block1592). For example, the advertisement agent485may generate an advertisement model, campaign, description, specification, proposal, etc. based on the television guide information and the ratings information. For example, a proposal for presenting an advertisement during a first show (e.g., the media content) with a high rating may include a higher cost than an advertisement proposal for presenting the advertisement during a second show (e.g., a second media content) with a lower rating. The machine readable instructions ofFIG. 15Bthen terminate.

The example machine accessible instructions ofFIGS. 14,15A and15B may also be carried out to implement the example operations described above in connection withFIGS. 8-13to monitor and control access to media content. In particular, the machine accessible instructions may be carried out to monitor and/or authorize media content that is uploaded to a media distributor (e.g., YouTube, etc.), to search and/or crawl a network (e.g., the internet) for media content to monitor and/or authorized, etc.

FIG. 16illustrates an example manner of implementing the example media crawler170ofFIG. 1. The media crawler170is designed to manually, automatically, and/or semi-automatically locate media content on a network and to monitor and/or authorize the media content. In the illustrated example, it is implemented by a server that locates servers and computers that are available on the internet and locates media content available at those servers and/or computers. To locate content distributors160(e.g., web sites from which media devices105may download content), the example media crawler170ofFIG. 16includes any number and/or types of site locators1605. For example, the site locator1605may receive an identified starting web page and/or web server and may visit all web pages and/or web servers identified on the starting web page and/or web server. Alternatively, any other crawling technique may be used. To locate content available on located sites, the example media crawler170ofFIG. 16includes any number and/or types of content locators1610. For example, the site locator1605and/or the content locator1610may implement a web spider and/or web robot that recursively and/or systematically identify content that is available to the media devices105on the Internet120.

To extract, locate, and/or verify content identifiers present in, associated with, and/or contained in an identified piece of content, the example media crawler170ofFIG. 16includes a content identifier checker1615. The example content identifier checker1615ofFIG. 16may attempt to obtain an audience measurement code and/or may extract other content identifier(s) (e.g., metadata, public identifiers, private identifiers, other content identifiers, etc.) from the content. The content identifiers may be any data associated with the content (e.g., within metadata and/or embedded within audio, image and/or video data). The media crawler170of the illustrated example includes a signature engine1025to generate, compute, and/or extract a signature or other identifying data (e.g., an identification unique to a particular media content) from the media content. In some examples, any or all of the content identifier checker1615and/or the signature engine1625(e.g., an audio signature engine) are not implemented by the media crawler170. In such examples, the media crawler170collects copies of content and the extraction, determination and/or validation of content identifiers may be performed at the DRMAM server150.

To verify whether a content provider160is authorized to distribute a located piece of content, the example media crawler170ofFIG. 16includes a content verifier1630and a DRMAM server interface1635. The example content verifier1630sends the content or a sample thereof (e.g., in the case where code and/or signature extraction is performed at the DRMAM server150) and/or sends the extracted and/or generated content identifier(s) (e.g., a code, signature and/or metadata) to the DRMAM server150via the DRMAM server interface1635. The server150validates the information received from the media crawler170. If the content is authorized, the DRMAM server150can catalog and/or record that the content is available at the particular content distributor160(e.g., website) from which the media crawler170retrieved the same. If the content is not authorized, the media crawler170and/or the DRMAM server150can notify the content distributor160(e.g., website operator) and/or the originating content provider130(e.g., television studio) that content is being illegally distributed at that content distributor160. Thus, the DRMAM system can serve a copyright policing function.

Data collected by the example media crawler170ofFIG. 16may be stored, for example, on, by and/or within the example DRMAM server150. Additionally or alternatively, the example media crawler170may generate one or more reports of located and/or identified content, and/or provide any portion of the collected data to one or more of the content providers130and/or the content distributors160.

While an example manner of implementing the example media crawler170ofFIG. 1has been illustrated inFIG. 16, one or more of the data structures, elements, processes and/or devices illustrated inFIG. 16may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any of a variety of ways. Further, the example locators1605and1610, the content identifier checker1615, the signature engine1625, the content verifier1630and/or the interface1635and/or, more generally, the example media crawler170may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example locators1605and1610, the content identifier checker1615, the signature engine1625, the content verifier1630and/or the interface1635and/or, more generally, the example media crawler170could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. When any of the appended claims are read to cover a purely software implementation, at least one of the example locators1605and1610, the content identifier checker1615, the signature engine1625, the content verifier1630and/or the interface1635and/or, more generally, the example media crawler170are hereby expressly defined to include a tangible medium such as a memory, DVD, CD, etc. Further still, the example media crawler170may include data structures, elements, processes and/or devices instead of, or in addition to, those illustrated inFIG. 16, and/or may include more than one of any or all of the illustrated data structures, elements, processes and/or devices.

FIG. 17is a flowchart illustrating machine readable instructions that may be carried out to implement the example media crawler170ofFIGS. 1 and 16. For example, the machine readable instructions may be carried out to process media content located by the media crawler170.

The flowchart ofFIG. 17begins when the content ID checker1615ofFIG. 16of the media crawler170determines if media content at a site includes one or more content ID(s) (block1705). For example, the site locator1605may locate a site that provides content and the content locator1610may locate first media content at that site. If the content ID checker1615determines that one or more content ID(s) were found (block1705), the content verifier1630uses the content ID(s) to authorize the content (e.g., verify a license for distribution, request a license for distribution, etc.) via the DRMAM server interface1635(block1710). The content verifier1630may additionally verify the content ID(s) prior to authorizing the content. For example, the content verifier1630may compare a signature or metadata associated with the content to a database to determine if it matches a signature or metadata associated with reference content associated with the content ID(s). If there is no match, the content ID(s) may be identified as a spoofing attempt.

If the content ID checker1615determines that one or more content ID(s) were not found (block1705), the signature engine1625generates one or more signature(s) for the media content (block1715). The content verifier1630then uses the signature(s) for authorizing the content (block1720). The content verifier1630then determines if the content was authorized for upload/use (block1725). If the content was not authorized for upload/use (block1725), the content verifier1630notifies the content owner and/or content distributor of the unauthorized content (block1730). Control then proceeds to block1740, which is described below.

If the content verifier1630determines that the media content was authorized (block1725), the content verifier1630sends the media content to the DRMAM server interface1635for addition to a content catalog (block1735). For example, the media content may be sent to the DRMAM150for storage in a content catalog at the DRMAM150, may be sent to a content catalog at one of the content distributors160, or may be sent to any other content catalog.

After adding media content to the content catalog (block1735) or notifying the content owner or content distributor (block1730), the content locator1610determines if there is additional content at the site to be crawled (block1740). If there is additional content available at the site (block1740), control returns to block1705to crawl that content. If there is not additional content available at the site (block1740), the site locator1605determines if there are further sites to crawl (block1745). If there are further sites to crawl (block1745), control returns to block1705to crawl the next site. If there are no further sites to crawl (block1745), the machine readable instructions ofFIG. 17terminate.

The example machine accessible instructions ofFIGS. 14,15A,15B and/or17may be carried out by a processor, a controller and/or any other suitable processing device. For example, the example machine accessible instructions ofFIGS. 14,15A,15B and/or17may be embodied in coded instructions stored on a tangible medium such as a flash memory, a read-only memory (ROM) and/or random-access memory (RAM) associated with a processor (e.g., the example processor2105discussed below in connection withFIG. 21). Alternatively, some or all of the example machine accessible instructions ofFIGS. 14,15A,15B and/or17may be implemented using any combination(s) of application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable logic device(s) (FPLD(s)), discrete logic, hardware, firmware, etc. Thus, for example, any of the example content distributors160or the example media crawlers170(e.g., the site locator1605, the content locator1610, the content ID checker1615, the signature engine1625, the content verifier1630, and/or the DRMAM server interface1635) and/or, more generally, the example audience measurement system100could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. When any of the appended claims are read to cover a purely software implementation, at least one of the example content distributors160or the example media crawlers170(e.g., the site locator1605, the content locator1610, the content ID checker1615, the signature engine1625, the content verifier1630, and/or the DRMAM server interface1635) and/or, more generally, the example audience measurement system100are hereby expressly defined to include a tangible medium such as a memory, DVD, CD, etc. Also, some or all of the example machine accessible instructions ofFIGS. 14,15A,15B and/or17may be implemented manually or as any combination of any of the foregoing techniques, for example, any combination of firmware, software, discrete logic and/or hardware. Further, although the example machine accessible instructions ofFIGS. 14,15A,15B and17are described with reference to the flowcharts ofFIGS. 14,15A,15B and17, many other methods of implementing the machine accessible instructions ofFIGS. 14,15A,15B and/or17may be employed. For example, the order of execution of the blocks may be changed, and/or one or more of the blocks described may be changed, eliminated, sub-divided, or combined. Additionally, any or all of the example machine accessible instructions ofFIGS. 14,15A,15B and/or17may be carried out sequentially and/or carried out in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc.

FIG. 18is a block diagram of an example implementation of a router1800that is capable of controlling the transmission of media content. The example router1800may be used to route communications in the internet120, the content provider(s)130, and/or the content distributor(s)160ofFIG. 1. For example, the router1800may process all media content that pass through the internet or a portion thereof (e.g., a part of the internet for an internet service provider, a backbone internet provider, etc.).FIG. 19is a flowchart of an example method for implementing the router1800ofFIG. 18.

The example router1800ofFIG. 18includes a packet receiver1802to receive communication packets from a packet sender1814(e.g., a user computer) via a network1816. For example, if the router1800is installed at a user generated content website160(e.g., YouTube), the packet receiver1802receives communication packets from users (e.g., a user uploading a video file). If the packet receiver1802is installed in a service provider's network, the packet receiver1802receives content from users of the service provider network (e.g., a website transmitting packets to a subscriber of a service provider network or a subscriber transmitting packets to a website).

The protection extractor1804receives the received packet from the packet receiver1802. The protection extractor1804determines if the received packet is identified as protected. To this end, the example protection extractor1804decodes the received packet to determine if a watermark (e.g., an identification code inserted in the content via the Nielsen Audio Encoding System (NAES) (see U.S. Pat. No. 6,968,564, which is hereby incorporated by reference in its entirety), any type of audio watermark code, any type of video watermark code, etc.) is present in the content included in the packet. The router1800may transmit the received packet to the standard router functionality1812in parallel with the decoding and analysis of the packet. In addition, the protection extractor1804may receive multiple packets (e.g., five time-consecutive packets) and decode and analyze the packets together to determine if a watermark is present. In addition to or as an alternative to determining if a watermark is present, the protection extractor1804may determine if the header of the packet includes a Protection field. In addition, the watermark and/or the packet header may indicate a source of the protected content. If the packet does not include a watermark and/or a Protection field, the packet is transmitted to standard router functionality1812for routing and distribution of the packet. In the illustrated example, the packet is routed to a server1818. Additionally or alternatively, the protection extractor1804may add an identification to the packet header (e.g., add or update a Protection field) indicating that the content is authorized for transmission so that network elements later in the network distribution path will not need to decode the packet again. For example, the protector extractor1804may add a wrapper to each packet that has been verified, may add a field to the packet header, may modify a field in the packet header, etc. to indicate that the packet, stream, media content, etc. has already been verified. A router or other network or media device that receives the modified media content can analyze the packet header to prior to extracting or otherwise analyzing the packet for verification. Accordingly, a verification of the contents of media content can be performed once for a particular packet, stream, and/or media content and the packet header can be analyzed at a later time.

If the packet includes a watermark and/or Protection field, the protection extractor1804extracts the watermark and/or the contents of the Protection field and transmits the extracted watermark and/or contents to a source verifier1806.

The source verifier1806receives the watermark and/or contents of the Protection field and determines if the received watermark and/or contents identifies a source. For example, the Protection field may include an identifier that indicates that the content should be blocked or should be allowed no matter who is sending the packet, or the Protection field may include one or more identifier(s) of a source that is allowed to transmit the content to the exclusion of other senders. For example, if an included watermark identifies iTunes™ Music Stores as the source, rules for the router1800may cause the packet to be allowed (e.g., transmitted to the standard router functionality1812).

If the watermark and/or Protection field do not identify a source (e.g., the Protection field indicates that all transmissions should be blocked), the packet is transmitted to the unauthorized packet handler1810. The unauthorized packet handler1810applies one or more rules for handling unauthorized packets. In the illustrated example, the unauthorized packet handler1810does not transmit the packet to the standard router functionality1812for routing. Alternatively, the unauthorized packet handler1810may mark the packet for low priority handling, delay transmission of the packet, etc. prior to transmitting the packet to the standard router functionality1812for routing. Additionally or alternatively, the unauthorized packet handler1810may cause subsequent packets associated with the same stream of media content to be treated as unauthorized packets (e.g., blocked, delayed, etc.). In other words, the unauthorized packet handler1810may process packets of a media content stream in parallel with the transmission of the packets through the network (e.g., via the router) and, once a packet of the stream has been determined to be unauthorized, may apply unauthorized transmission rules to all later packets (e.g., may block or delay all later packets) of the same or substantially the same stream. Additionally or alternatively, the unauthorized packet handler1810may add an identification to the packet header (e.g., add a Protection field if a Protection field is not present) that indicates that the media content is unauthorized media content so that network elements that received the packet later in the distribution path of the network can determine how to handle the media content without having to decode the packet.

If the watermark and/or Protection field identifies a source, the source verifier1806retrieves a record associated with the source from a source database1808. The source database1808stores records associating one or more IP addresses with a watermark and/or a Protection field identifier (e.g., IP addresses that have been authorized for transmitting packets identified by the watermark and/or Protection field). For example, the source database1808may include a record for the iTunes Music Store that identifies all IP addresses that the iTunes Music Store might use to transmit music to customers. Alternatively, the watermark, Protection field, and/or other field of the packet may include an authorized IP address and, thus, extraction of the source IP address from the source database1808may not be performed.

The source verifier1806extracts a source IP address from the source field of the received packet (e.g., the actual IP address that sent the packet). The source verifier1806determines if the IP address from the source field of the received packet matches any of the IP addresses associated with the source identified in the watermark and/or Protection field (e.g., one or more IP addresses retrieved from the source database1808or included in the watermark or Protection field). If the IP address from the source field does not match any of the IP addresses associated with the source, the unauthorized packet handler1810applies one or more rules for handling unauthorized packets. In other words, if the packet is transmitted by a source that is not associated with the source identified in the watermark and/or Protection field (i.e., an unauthorized source), the packet is treated as an unauthorized packet. If the IP address from the source field matches one of the IP addresses associated with the source, the packet is transmitted to the standard router functionality1812for routing to its destination. As previously described, in the illustrated example, the packet is routed to the server1818.

While the forgoing description references router1800, the router1800may alternatively be implemented by any type of network element such as, for example, a server, a network switch, a firewall, a gateway, a bridge, etc.

While the forgoing description describes decoding packets to determine if a single watermark is present, media content may alternatively include multiple watermarks that may be verified. The router1800may include rules for handling multiple watermarks. Also, rules for handling conflicting watermarks and/or Protection field contents may be defined. For example, if a first watermark indicates that media content is protected, but a second watermark indicates that media content protection should be ignored, the content would be determined to be authorized for transmission. More generally, media content having a first protection indicating watermark and a second protection releasing watermark may be allowed to transmit, may be delayed in transmission (as opposed to content that includes no watermark that is not delayed), may be blocked, etc.

While the forgoing description indicates that each packet of media content is examined, packets passing through the router1800may be spot checked. In other words, the router1800may randomly check packets or may periodically check packets. Further, packets may be analyzed prior to being allowed to pass through the router or packets may be buffered and analyzed in parallel with transmission (or offline). If packets are analyzed in parallel or offline and an unauthorized packet is detected, all later packets associated with the unauthorized packet may be controlled (e.g., may be blocked, delayed, modified, etc.).

In an example operation, the example packet sender1814sends a stream of packets corresponding to media content to the server1818via the network1816. The example router1800is interposed between the network1816and the server1816or is an intermediate in the network1816(e.g., packets transmitted from the packet sender1814enter the network1816, pass through the router1800and any other network elements, and exit the network1816wherein they are transmitted to the server1818). The router1800analyzes the packets as described in the forgoing and as described in conjunction withFIG. 19. If the router1800determines that the packets are associated with unauthorized media content, restricted media content, or any other specified type of media content, the router1800applies business rules (e.g., blocks the content, delays the progression of the media content, sends a notification to the server1818, sends a notification to the packet sender1814, marks the packet (e.g., inserts an identifier in a packet header), etc.). If the business rules allow and/or specify that the content is to be transmitted to the server1818, the router routes the packets to the server1818(e.g., via one or more other network elements).

FIG. 19is a flowchart illustrating example machine readable instructions that may be carried out to implement the example router1800ofFIG. 18.

The example flowchart ofFIG. 19begins when the example packet receiver1802receives communication packets from the packet sender1814(e.g., a user computer) via the network1816(block1902). Then, the protection extractor1804determines if the received packet is identified as protected (block1904). If the packet does not include a watermark and/or a Protection field (block1904), the packet is transmitted to the standard router functionality1812for routing and distribution of the packet (block1918).

If the packet includes a watermark and/or Protection field (block1904), the protection extractor1804extracts the watermark and/or the contents of the Protection field and transmits the extracted watermark and/or contents to a source verifier1806(block1906). The source verifier1806then receives the watermark and/or contents of the Protection field and determines if the received watermark and/or contents identifies a source (block1908). If the watermark and/or Protection field do not identify a source (e.g., the Protection field indicates that all transmissions should be blocked) (block1908), the packet is transmitted to the unauthorized packet handler1810, which applies one or more rules for handling unauthorized packets (block1910). Control then proceeds to block1902to process the next packet.

If the watermark and/or Protection field identifies a source, the source verifier1806retrieves a record associated with the source from a source database1808(block1912). The source verifier1806then extracts a source IP address from the source field of the received packet (i.e., the actual IP address that sent the packet) (block1914). The example source verifier1806determines if the IP address from the source field of the received packet matches any of the IP addresses associated with the source identified in the watermark and/or Protection field (e.g., one or more IP addresses retrieved from the source database1808or included in the watermark or Protection field) (block1916). If the IP address from the source field does not match any of the IP addresses associated with the source (block1916), the unauthorized packet handler1810applies one or more rules for handling unauthorized packets (block1910). In other words, if the packet is transmitted by a source that is not associated with the source identified in the watermark and/or Protection field (i.e., an unauthorized source), the packet is treated as an unauthorized packet. Control then returns to block1902to process the next packet.

If the IP address from the source field matches one of the IP addresses associated with the source (block1916), the packet is transmitted to the standard router functionality1812for routing to its destination (block1918). As previously described, in the illustrated example, the packet is routed to the server1818. Control then returns to block1902to process the next packet.

The example machine accessible instructions ofFIG. 19may be carried out by a processor, a controller and/or any other suitable processing device. For example, the example machine accessible instructions ofFIG. 19may be embodied in coded instructions stored on a tangible medium such as a flash memory, a read-only memory (ROM) and/or random-access memory (RAM) associated with a processor (e.g., the example processor2105discussed below in connection withFIG. 21). Alternatively, some or all of the example machine accessible instructions ofFIG. 19may be implemented using any combination(s) of application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable logic device(s) (FPLD(s)), discrete logic, hardware, firmware, etc. Thus, for example, the example router1800ofFIG. 18(e.g., any or all of the packet sender1814, the packet receiver1802, the protection extractor1804, the source verifier1806, the source database1808, the unauthorized packet handler1810, the standard router functionality1812, and/or the server1818) could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. When any of the appended claims are read to cover a purely software implementation, at least one of the example router1800, the packet sender1814, the packet receiver1802, the protection extractor1804, the source verifier1806, the source database1808, the unauthorized packet handler1810, the standard router functionality1812, and/or the server1818are hereby expressly defined to include a tangible medium such as a memory, DVD, CD, etc. Also, some or all of the example machine accessible instructions ofFIG. 19may be implemented manually or as any combination of any of the foregoing techniques, for example, any combination of firmware, software, discrete logic and/or hardware. Further, although the example machine accessible instructions ofFIG. 19are described with reference to the flowcharts ofFIG. 19, many other methods of implementing the machine accessible instructions ofFIG. 19may be employed. For example, the order of execution of the blocks may be changed, and/or one or more of the blocks described may be changed, eliminated, sub-divided, or combined. Additionally, any or all of the example machine accessible instructions ofFIG. 19may be carried out sequentially and/or carried out in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc.

FIG. 20is an illustration of an example packet that includes a Protection field. A packet header2002includes a source field, a destination field, a packet length, a number of packets, a sequence number of the packet, and a Protection field. The example Protection field includes a hexadecimal protection flag. The contents of the Protection field could indicate that the packet should be unconditionally blocked from transmission. Additionally, the contents of the Protection field could identify a source that is authorized to transmit the packet.

Alternatively, the packet could include a second Protection Source field. The Protection Source field could be used to indicate a source authorized to transmit a packet. In such an implementation, the Protection field would only indicate whether or not the packet is subject to restriction. If the packet included an identifier in the Protection field but the Protection Source field was empty, the packet would be subject to unconditional blocking. If the packet includes an identifier in the Protection field and the Protection Source field, the source of the packet would be analyzed to ensure that the packet is being transmitted by an authorized source.

FIG. 21is a schematic diagram of an example processor platform2100that may be used and/or programmed to implement any or all of the example media devices105, the example content providers130, the example DRMAM server150, the example content distributors160, the example media crawlers170ofFIG. 1, the example router1800ofFIG. 18, and/or any other component described herein. For example, the processor platform2100can be implemented by one or more general purpose processors, processor cores, microcontrollers, etc.

The processor platform2100of the example ofFIG. 21includes at least one general purpose programmable processor2105. The processor2105executes coded instructions2110and/or2112present in main memory of the processor2105(e.g., within a RAM2115and/or a ROM2120). The processor2105may be any type of processing unit, such as a processor core, a processor and/or a microcontroller. The processor2105may execute, among other things, the example machine accessible instructions ofFIGS. 14,15A,15B,17, and/or19, the example operations ofFIGS. 8-13and/or to implement any or all of the example DRMAM system100described herein. The processor2105is in communication with the main memory (including a ROM2120and/or the RAM2115) via a bus2125. The RAM2115may be implemented by DRAM, SDRAM, and/or any other type of RAM device, and ROM may be implemented by flash memory and/or any other desired type of memory device. Access to the memory2115and2120may be controlled by a memory controller (not shown). The RAM2115may be used to store and/or implement, for example, any or all of the example content database205, the example consumption database235and/or the example content stores305ofFIGS. 2 and 3.

The processor platform2100also includes an interface circuit2130. The interface circuit2130may be implemented by any type of interface standard, such as a USB interface, a Bluetooth interface, an external memory interface, serial port, general purpose input/output, etc. One or more input devices2135and one or more output devices2140are connected to the interface circuit2130. The input devices2135and/or output devices2140may be used to implement any or all of the example interfaces ofFIGS. 2,3,4A,4B,5and16.

The example system100ofFIG. 1implements a media content authorization system that allows content distributors (e.g., YouTube, Break.com, etc.), content providers, P2P distribution systems (e.g., P2P servers, P2P software, P2P network elements. etc.), and/or any other systems that handle media content to verify that media content is authorized for distribution before accepting media content and distributing the media content. The example system100utilizes various data sources (e.g., a audience ratings data source, a program information data source, etc.) to determine how media content should be handled. Accordingly, the example system100can make a better determination about whether media content should be distributed. In addition, the example system100is capable of using the same or different data stores for determining how to display media content. In particular, the example system100is capable of determining what type of commercials should be displayed in conjunction with media content and determining an amount that should be charged to an advertiser for displaying an advertisement with the media content. Accordingly, the example system100ofFIG. 1provides a more complete solution for handling media content in a network such as at a content distributor or at a media content provider.