HK1227592B - Method and apparatus to measure and monitor exposure to streaming media - Google Patents

Description

Method and apparatus for measuring and monitoring exposure to streaming media

Related applications

This application claims the benefit of U.S. Provisional Patent Application Serial No. 61/889,505, filed October 10, 2013, U.S. Provisional Patent Application Serial No. 61/890,176, filed October 11, 2013, and U.S. Patent Application Serial No. 14/144,352, filed December 30, 2013. U.S. Provisional Patent Application Serial No. 61/889,505, U.S. Provisional Patent Application Serial No. 61/890,176, and U.S. Patent Application Serial No. 14/144,352 are hereby incorporated by reference in their entireties.

Technical Field

The present disclosure relates generally to measuring media exposure and, more particularly, to methods and apparatus for measuring exposure to streaming media.

Background Art

In recent years, media devices with internet connectivity and the ability to retrieve media from the internet have been provided. Likewise, media exposure has shifted away from traditional presentation methods (such as broadcast television) toward presentation via consumer devices that access the internet to retrieve media for display.

Media providers and/or other entities (such as, for example, advertising agencies, broadcast networks, etc.) are often interested in the viewing, listening, and/or media behavior of audience members and/or the general public. Media usage and/or exposure habits of audience members and demographic data about audience members are collected and used to statistically determine the size and demographics of an audience of interest.

Traditionally, audience measurement entities determine audience engagement with media programs and/or advertisements based on registered panelists. That is, the audience measurement entity registers individuals who have consented to be monitored into a panel. The audience measurement entity then monitors those panelists to determine the media (e.g., television programs, radio programs, movies, DVDs, etc.) presented to those panelists. In this way, the audience measurement entity can determine exposure metrics for different media (e.g., content and/or advertisements) based on the collected media measurement data.

Summary of the Invention

A first aspect of the present invention provides a method for measuring exposure to streaming media, the method comprising:

detecting, with a processor, an ID3 tag associated with streaming media presented at a client device;

sending a first request from the client device to a first Internet domain in response to the ID3 tag, the first request identifying the streaming media;

receiving a redirect message from the first Internet domain; and

In response to the redirect message, a second request is sent to a second Internet domain specified by the redirect message, the second request including a cookie identifying the client device.

A second aspect of the present invention provides a device for measuring exposure to streaming media, the device comprising:

a metadata retriever for retrieving metadata associated with media presented at a client device, the metadata being located in an ID3 tag;

a metadata transmission position determiner, the metadata transmission position determiner being used to determine a position for transmitting the metadata, the position being determined based on the metadata of the ID3 tag; and

A sender is configured to send a request to the location, the request including the metadata and user identification data, the user identification data being accessible at the location.

A third aspect of the present invention provides a method for monitoring exposure to streaming media, the method comprising:

instructing a content provider, using an audience measurement server, to embed an ID3 tag in media to be streamed, the ID3 tag causing a client device to contact the audience measurement server;

receiving, at the audience measurement server, a first request generated by a client device accessing the tag, the first request identifying the streaming media;

sending a redirect message from the audience measurement server to the client device; and

Identification information of a user of the client device is received from a social media provider specified in the redirect message.

A fourth aspect of the present invention provides a device for monitoring exposure to streaming media, the device comprising:

a metadata indicator for instructing a content provider to embed an ID3 tag in the media to be streamed, the tag causing the client device to send a message to an audience measurement server;

a server that sends a redirect message to the client device in response to a first request generated by the client device accessing the tag, the first request identifying the streaming media; and

A data receiver is configured to receive identification information of the client device from the social media provider specified in the redirect message.

A fifth aspect of the present invention provides a method for measuring exposure to streaming media, the method comprising:

extracting media identification information from media obtained from a media provider;

generating metadata for identifying the media based on the media identification information;

determining an address of a database owner to which the metadata is to be sent;

embedding the database owner's address and the metadata into an ID3 tag; and

The media and the ID3 tag are sent to a client device.

A sixth aspect of the present invention provides a device for monitoring exposure to streaming media, the device comprising:

a media identifier configured to extract media identification information from media obtained from a media provider, and to generate metadata identifying the media based on the media identification information;

a metadata embedder for determining an address of a database owner to which the metadata is to be sent, the metadata embedder embedding the address of the database owner and the metadata into an ID3 tag; and

A media transmitter is configured to transmit the media and the ID3 tag to a client device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system that may be used to determine exposure to streaming media.

FIG. 2 illustrates an alternative example system that may be used to determine exposure to streaming media.

FIG. 2A illustrates an alternative example system that may be used to determine exposure to streaming media.

3 is a block diagram of an example implementation of the browser of FIG. 1 .

4 is a block diagram of an example implementation of the database owner of FIG. 1 .

4A is a block diagram of an example implementation of the central facility of FIG. 1 .

5 is a block diagram of an example implementation of an example HLS stream that may be displayed by the example browser of FIG. 1 , FIG. 2 , and/or FIG. 3 .

6 is a flow diagram representative of example machine-readable instructions that may be executed to implement the example service provider of FIG. 1 and/or FIG. 2 .

7 and 8 are flow diagrams representing example machine-readable instructions that may be executed to implement the example browsers of FIG. 1 , FIG. 2 , and/or FIG. 3 .

9 and 10 are flow diagrams representative of example machine-readable instructions that may be executed to implement the example database owner of FIG. 1 , FIG. 2 , FIG. 2A , and/or FIG. 4 .

FIG10A is a table representing impression data recorded by an example database owner.

FIG. 10B is a table representing demographic information stored by the database owner.

FIG. 10C is a table representing aggregated media presentation information sent by data owners to the central facility.

11 is a flow diagram representative of example machine-readable instructions that may be executed to implement the example central facility of FIG. 1 , FIG. 2 , FIG. 2A , and/or FIG. 4A .

Figure 12 is a block diagram of an example processor platform capable of executing the example machine-readable instructions of Figures 6, 7, 8, 9, 10 and/or 11 to implement the example service provider of Figures 1 and/or 2, the example browser of Figures 1, 2, 2A and 3, the example database owner of Figures 1, 2, 2A and/or 4, and/or the example central facility of Figures 1, 2, 2A and/or 4A.

Wherever possible, the same reference numbers will be used throughout the drawings and the accompanying written description to refer to the same or like parts.

DETAILED DESCRIPTION

Monitoring companies desire to gain knowledge about how users interact with media devices (such as smartphones, tablets, laptops, smart TVs, etc.). In particular, media monitoring companies want to monitor media presentations at media devices to, among other things, monitor exposure to advertisements, determine advertising effectiveness, determine user behavior, identify purchasing behavior associated with various demographics, determine popularity for content, and the like. Monitoring companies recruit specialized panels and collect demographic information about the specialized panels. Media presentation information is then collected in conjunction with the specialized panels. However, it is difficult for monitoring companies to collect detailed demographic information from every user to whom media is presented (e.g., a non-specialized panel). In the examples disclosed herein, monitoring companies collaborate with database owners (e.g., Faceook, Twitter, Experian, etc.) that have large databases of demographic information to extend media monitoring capabilities to non-specialized panels.

In an example disclosed herein, a transcoded watermark is used to identify the presented media. The transcoded watermark is sent as metadata (e.g., an ID3 tag), which is sent in association with and/or as part of the media. A media presentation device (e.g., an iPad, a smart TV, etc.) extracts the metadata and sends it to a database owner, along with information identifying the media device and/or the user of the media device. If the database owner cannot identify the media device and/or the user of the media device, the database owner redirects the media device to a different database owner and/or an audience measurement entity so that the media device and/or the user of the media device can be identified. If the database owner can identify the media device and/or the user of the media device, the database owner reports demographic information associated with the media device and/or the user of the media device to the audience measurement entity for association with the media and/or the metadata identifying the media. In some examples, the metadata is not sent to the database owner to prevent the database owner from identifying the media accessed by the media device and/or the user.

Traditionally, audience measurement entities (also referred to herein as "rating entities") determine demographic searches for advertisements and/or media programs based on registered panelists. That is, the audience measurement entity enrolls individuals who consent to being monitored into a panel. During enrollment, the audience measurement entity receives demographic information from the enrolled individuals, enabling subsequent associations to be made between media exposure to those panelists and different demographic markets. The audience measurement entity then sets and/or obtains user and/or device identifiers, enabling subsequent associations between impressions associated with the panelist and/or the panelist's demographics. In some examples, the user and/or device identifier is cookie data or another identifier used by a media device (e.g., an iPad) when communicating with the audience measurement entity. Based on the user and/or device identifier, the audience measurement entity identifies the demographic information provided by the panelist. Instead of providing detailed demographic information, the panelist is sometimes offered incentives (e.g., apps, gift cards, cash, raffle and/or sweepstakes entries, etc.). Consequently, maintaining large panels can sometimes be cost-prohibitive.

To reduce the cost of constructing and/or maintaining large panels, audience measurement entities collaborate with other entities to obtain demographic information associated with media presentations. Example methods, devices, and/or articles disclosed herein enable audience measurement entities to request demographic information from other entities operating based on a user registration model. Collaboration with other entities operating based on a user registration model enables audience measurement entities to effectively increase the size of user panels.

As used herein, a user registration model is one in which users subscribe to the services of those entities by creating an account and providing demographically relevant information about themselves. Sharing demographic information associated with registered users of a database owner enables audience measurement entities to receive audience measurement information from external sources (e.g., the database owner), thereby expanding the coverage, accuracy, and/or completeness of their demographically based audience measurements. Such access also enables audience measurement entities to monitor people who would not otherwise be included in the audience measurement panel.

Any entity that has a database that identifies the demographics of a collection of individuals can collaborate with an audience measurement entity. Such entities may be referred to as "database owners" and include entities such as wireless service operators, mobile software/service providers, social networking sites (e.g., Facebook, Twitter, LinkedIn, Google, etc.), online retailer websites (e.g., Amazon.com, Buy.com, etc.), and/or any other Internet website that maintains user registration records (e.g., Yahoo!, MSN, Apple iTunes, Experian, etc.). There are many database owners operating on the Internet. Database owners provide services to a large number of subscribers. Instead of providing this service, subscribers register with the database owner. As part of this registration, subscribers provide detailed demographic information. As part of using the provided services (e.g., social networking services, shopping services, news services, etc.), database owners have the right to set and/or collect cookies and/or other identifiers stored by the browser.

The database owner reports media presentation information and demographic information associated with the media presentation to the audience measurement entity. In traditional panel-based systems, the panelists are aware that they are sharing their demographic information with the audience measurement entity. However, in the examples disclosed herein, demographic information is retrieved from the database owner, which therefore raises data privacy issues (because users may not be aware that their demographic information is being shared). To this end, users may consent to or block the sharing of demographic information on the part of the database owner. For example, when creating an account with the database owner, the user may be asked to allow demographic information to be shared with other entities (e.g., the audience measurement entity).

Furthermore, the demographic information collected by the database owner may not be as detailed as the demographic information collected by the audience measurement entity, as compared to the demographic information received when registering a panel (where the panel is requested to provide very detailed demographic information to the audience measurement entity). For example, the database owner may not request demographic information about a user's income, a user's interests, a user's ethnicity, etc. Furthermore, different database owners may request and/or store different information about a user. For example, a social media database owner may store demographic information about a user's ethnicity, interests, location, etc., while a credit report database owner may store demographic information about a user's financial information (e.g., input, credit score, etc.).

In examples disclosed herein, a database owner provides demographic information about users to an audience measurement entity (e.g., Nielsen Company, Schaumburg, Illinois, USA) in conjunction with a particular segment of media. In some examples, the demographic information is provided in aggregate. In some examples, the database owner sends the demographic information on an aggregate basis when a threshold number of users are presented to a particular segment of media. For example, aggregated demographic information may be provided only when there are more than one hundred users associated with the media. However, any other threshold number of users may be used in addition or alternatively. In contrast, when a single user is identified in conjunction with the demographic information, the demographic information may be provided to the rating entity on an individual basis. Whether the demographic information is provided to the rating entity in aggregate or individually may be determined by the database owner for any reason (such as, for example, privacy laws, business considerations, technical limitations, etc., within the database owner's jurisdiction).

In some examples, to more accurately associate media presentations with the correct demographics, the example methods, devices, and/or articles disclosed herein utilize user information located in the records of an audience measurement entity (e.g., panel information) and user information at one or more database owners that maintain records or profiles of users with accounts. In some examples, multiple database owners can report demographic information to a media monitoring entity associated with the same media. Multiple sources (e.g., demographic information for panels from an audience measurement company and/or registered user data from a network service provider) can be useful because the additional data improves the accuracy of demographic metrics for content and/or advertising campaigns. The example techniques disclosed herein use online registration data to identify the demographics of users in order to track the number of impressions attributable to the demographics associated with those users. As used herein, an impression refers to an exposure to media (e.g., content and/or advertising). In internet advertising, the number of impressions or impression count is the total number of times an ad or advertising campaign is viewed by a group. Impressions do not take into account multiple exposures to the same individual (i.e., two exposures to the same person are counted as two impressions). In contrast, unique impression counting eliminates duplicate exposures and thus counts only one exposure for each person, regardless of how many times that person might actually have experienced the exposure.

As used herein, the term "media" includes any type of content and/or advertisement delivered via any type of distribution media. Therefore, media includes television programs or television commercials, radio programs or radio advertisements, movies, websites, streaming media, etc. The example methods, devices, and articles disclosed herein monitor media presentations at media devices. Such media devices may include, for example, internet televisions, personal computers, internet mobile phones (e.g., smartphones such as Apple Samsung Galaxy 4, etc.), video game consoles (e.g., 3), tablet computers (e.g., ), digital media players (e.g., media players, etc.), etc. In some examples, media monitoring information is aggregated to determine ownership and/or usage statistics of media devices, relative ratings of usage and/or ownership of media devices, usage types of media devices (e.g., whether the device is used to browse the internet, streaming media from the internet, etc.), and/or other types of media device information. In the examples disclosed herein, the monitoring information includes, but is not limited to, media identification information (e.g., media identification metadata, codes, signatures, watermarks, and/or other information that can be used to identify the presented media), application usage information (e.g., an identifier of the application, the time and/or duration of use of the application, a rating of the application, etc.), and/or device and/or user identification information (e.g., a user name, a media access control (MAC) address, an Internet Protocol (IP) address, an Apple ID, a panel identifier, a Google ID, any other type of identifier, etc.).

Media devices such as tablet computers (e.g., Apple, Asus Transformer ^™ , etc.) use apps and/or browsers to access, retrieve, request, and/or present media (e.g., Internet media) to present media. There are many different browsers such as, for example, Google, Mozilla Firefox, and Apple Dolphin. Apps and/or browsers can be downloaded by users through app stores (such as, for example, Apple, Google, etc.).

The operating system of a media device and/or the browser operated by the media device are typically closed platforms. That is, the operating system and/or browser provide a limited set of accessible functionality. In some examples, the browser may utilize a limited set of functionality for sharing data external to the media device. For example, the browser may utilize a limited set of user information (e.g., cookies) and/or may not allow programmatic access to the audio and/or video of the media presented by the device. Cookies can be used to store information about the user of the media device in association with the domain being visited (e.g., Facebook.com, twitter.com, Nielsen.com, etc.). For example, a username can be stored in association with a specific domain, display settings can be stored in association with that domain, etc. Traditionally, cookies have limited use in identifying users across domains. For example, a browser is only allowed to send cookies when visiting a website whose domain name matches the cookie. For example, when visiting the domain "abc.com", the browser is not allowed to send cookies associated with the domain "xyz.com".

While cookies and/or other identifiers can be used to identify a media device and/or a user of a media device to an audience measurement entity and/or database owner, it is equally important to properly identify the media presented via the media device. Traditionally, codes, signatures, watermarks, etc. embedded in the audio and/or video of the media are used to identify the media. However, there are difficulties in identifying audio and/or video watermarks at the media device. For example, some media devices do not allow programmatic access to the audio and/or video of the media, processing audio and/or video watermarks may quickly drain the battery of the media device, etc. The examples disclosed herein address this problem through transcoding. In some such examples, a service provider (e.g., a streaming provider) transcodes the watermark into a format that is easily determined by the media device.

In some examples, media identification metadata having a first format is extracted from the presented media. The media identification metadata may indicate, for example, a watermark associated with the media, a uniform resource locator (URL) indicating a notification of the location where the media presentation is sent (e.g., a URL of a database owner, etc.). In some such examples, the transport stream corresponds to a Moving Picture Experts Group (MPEG) 2 transport stream sent according to a Hypertext Transfer Protocol (HTTP) Live Streaming (HLS) protocol. In some examples, the watermark is an audio watermark embedded in an audio portion of the media using the first metadata format. In some examples, the watermark having the first format is transcoded into media identification metadata having a second format. The media identification metadata having the second format may correspond to, for example, a text representation of the watermark (such as a base 64 hexadecimal string). In some examples, the media identification metadata is sent in a metadata transmission stream associated with the media.

In some disclosed examples, HTTP Live Streaming (HLS) is used to deliver streaming media to a media device. However, any other past, present, and/or future method of processing a media stream to a media device (such as, for example, the HTTP Secure (HTTPS) protocol) may be used in addition or alternatively. An HLS transport stream allows metadata to be included in and/or associated with, for example, a media stream, a timed text track, etc. In some disclosed examples, a media device uses a browser to display media received via HLS. Additionally or alternatively, in some disclosed examples, a media device uses a media renderer (e.g., a browser plug-in, an app, a framework, an application programming interface (API), etc.) to display media received via HLS.

Some example methods disclosed herein include decoding an HLS transport stream carrying media identification metadata that is streamed to a media device to obtain the media. Some such example methods also include extracting metering data from the media and/or receiving metering data from an independent metering data source (e.g., a timing text track file, a manifest file, etc. sent in association with the media). In some examples, in addition to identifying the media, the media identification metadata may additionally or alternatively identify the source of the media. In addition, some such example methods also include decoding media identification metadata (e.g., such as electronic guide (EPG) data, playlist data, etc.) that has accompanied the transport stream carrying the media. Some such example methods also include verifying the media identification metadata using metering data extracted from the media (e.g., a transcoded watermark).

In examples disclosed herein, media exposure metrics are monitored by retrieving metadata embedded in or otherwise transmitted with media presented by a media renderer of a media device. In some examples, the metadata is stored in a Document Object Model (DOM) object. The DOM is a cross-platform and language-independent naming convention for presenting and interacting with objects in Hypertext Markup Language (HTML). In some examples, a media renderer (e.g., a media plug-in) such as, for example, QuickTime Player expresses DOM events that can be captured via JavaScript. By capturing DOM events triggered by the media renderer, metadata can be extracted via the DOM. Once extracted, the metadata can be combined with other information (such as, for example, cookies or other user identification data associated with the user of the device) and sent to, for example, a database owner and/or an audience measurement entity for analyzing and/or calculating data collected from other devices.

In some examples, metadata is stored in the ID3 tag format, but any other past, present, and/or future metadata format may be used in addition or alternatively. An ID3 tag is a metadata container that can be attached to media and/or sent in association with the media. In the examples disclosed herein, the ID3v2 format is used. In particular, media identification metadata is stored in a private frame of the ID3 tag. However, any other past, present, and/or future method of storing media identification metadata may be used in addition or alternatively.

In examples disclosed herein, a software development kit (SDK) is provided to website developers, for example, from an audience measurement entity or other entity. The SDK helps instrument and/or otherwise enable websites (e.g., media websites (such as streaming video websites), news websites, image websites, social media websites, online gaming websites, etc.) with monitoring functionality that collects monitoring information (e.g., cookies and/or other user or device identifiers, media identifiers (ID3 tags), etc.) and sends the monitoring information to a database owner and/or an audience measurement entity. In particular, website developers use the SDK to create websites that include media monitoring instructions. Thus, rather than relying on a dedicated monitoring application installed on a computer (e.g., a tablet, laptop, smartphone, etc.), the website disclosed herein is instrumented with monitoring instructions, causing the browser to send the monitoring information to the database owner and/or monitoring entity (e.g., an audience measurement entity). In some examples, the monitoring instructions provided by the SDK are implemented using JavaScript instructions. However, any other language or type of script or instruction may be used in addition or alternatively. The monitoring instructions enable the browser to notify the database owner and/or monitoring entity (e.g., an audience measurement entity) when the website and/or media associated with the website is being presented, notify the database owner and/or monitoring entity (e.g., an audience measurement entity) what media and/or website is being presented, notify the database owner and/or monitoring entity (e.g., an audience measurement entity) how the website and/or media are being presented (e.g., via a flat-panel display, via a television, etc.), notify the database owner and/or monitoring entity (e.g., an audience measurement entity) the duration of exposure to the website and/or media associated with the website, etc. In some examples, the media monitoring instructions may be triggered by, for example, the presentation of a media element (such as, for example, video, audio, image, etc.).

Example methods, apparatus, and/or articles disclosed herein can report media impressions and corresponding demographics from a database owner to a ratings entity, also referred to herein as an Audience Measurement Entity (AME). In this way, the AME can track media impressions on media devices and/or create reports of media impressions broken down by different demographics.

The example methods, devices, and articles disclosed herein can be used to determine media impressions, content impressions, ad impressions, content exposure, and/or ad exposure using user information distributed across different databases on the Internet (e.g., different website owners, service providers, etc.). The example methods, devices, and articles disclosed herein not only enable more accurate correlation of Internet media exposure with user (e.g., demographic) information, but also effectively expand the size of the panel and expand the membership beyond the panel of people participating in the monitoring entity (e.g., audience measurement entity and/or rating entity) to people registered in Internet databases (e.g., wireless service operators, mobile software/service providers, social media websites (e.g., Facebook, Twitter, Google, etc.), and/or any other Internet website such as Yahoo!, MSN, Apple iTunes, Experian, etc.). Such expansion effectively leverages the media exposure tracking capabilities of the monitoring entity (e.g., audience measurement entity) and the databases of non-AME entities (e.g., social media and/or other websites) to create a large, demographically accurate panel that enables accurate and reliable measurement of exposure to media (e.g., ads and/or content (e.g., programs)).

FIG1 is a diagram of an example system 100 constructed in accordance with the teachings of the present disclosure for measuring exposure to streaming media. The example system 100 of FIG1 monitors media provided by an example media provider 110 for presentation on an example client device 160 via an example network 150. The example system 100 includes an example service provider 120, an example browser 165, a first database owner 180, a second database owner 182, and an example central facility 170 of an audience measurement entity. Although the illustrated example of FIG. 1 discloses an example implementation of the service provider 120, other example implementations of the service provider 120 may additionally or alternatively be used, such as the example implementations disclosed in U.S. patent application serial number 13/341,646, U.S. patent application serial number 13/443,596, U.S. patent application serial number 13/793,991, U.S. patent application serial number 13/445,961, U.S. patent application serial number 13/472,170, U.S. patent application serial number 13/793,983, U.S. patent application serial number 13/767,548, U.S. patent application serial number 13/793,959, U.S. patent application serial number 13/778,108, U.S. patent application serial number 61/813,019, and/or U.S. patent application serial number 13/963,737, all of which are incorporated herein by reference in their entireties.

1 represents any one or more media providers capable of providing media for presentation on a client device 160. The media provided by the media provider 110 may be any type of media, such as audio, video, multimedia, web pages, etc. Additionally, the media may correspond to live (e.g., broadcast) media, stored media (e.g., on-demand content), etc.

1 provides media services to client devices 160 via, for example, a web page that includes links (e.g., hyperlinks, embedded media, etc.) to media provided by media provider 110. In the illustrated example, service provider 120 modifies the media provided by media provider 110 before sending the media to client devices 160. In the illustrated example, service provider 120 includes an example media identifier 125, an example transcoder 130, an example metadata embedder 135, and an example media sender 140.

The media identifier 125 of the illustrated example of FIG1 is implemented by logic circuitry (such as a processor that executes instructions), but it may additionally or alternatively be implemented by an application-specific integrated circuit (ASIC), a programmable logic device (PLD) and/or a field-programmable logic device (FPLD), analog circuitry, and/or other circuitry. The media identifier 125 of FIG1 extracts metering data (e.g., signatures, watermarks, etc.) from the media obtained by the media provider 110. For example, the media identifier 125 may implement functionality provided by a software development kit (SDK) to extract one or more audio watermarks, one or more video (e.g., image) watermarks, etc., embedded in the audio and/or video of the media obtained from the media provider 110. (For example, the media may include pulse code modulated (PCM) audio data or other types of audio data, uncompressed video/image data, etc.)

The example media identifier 125 of FIG. 1 determines (e.g., derives, decodes, converts, etc.) metering data (e.g., media identification information, source identification information, etc.) included in or identified by a watermark embedded in the media and converts the metering data and/or the watermark itself into a text and/or binary format for inclusion in an ID3 tag and/or other data types (e.g., text, binary, etc.) for transmission as metadata accompanying streaming media (e.g., such as with a playlist or electronic program guide). For example, the code/watermark itself can be extracted and inserted as metadata in a text or binary format, such as within an ID3 tag. Thus, the metadata and/or media identification metadata included in the ID3 tag can be a text or binary representation of the code, watermark, and/or metadata or data identified by the code and/or watermark. Additionally or alternatively, the watermark can be used to retrieve metering data from a local or remote database. In some examples, the media identification metadata is stored in a private frame of the ID3 tag. In some other examples, the ID3 tag includes the location of the database owner to which the monitoring information should be sent.

The example transcoder 130 of the illustrated example of FIG1 is implemented by logic circuitry (such as a processor that executes instructions), but may additionally or alternatively be implemented by analog circuitry, ASICs, DSPs, FPGAs, and/or other circuitry. In some examples, the transcoder 130 and the media identifier 125 are implemented by the same physical processor. In the illustrated example, the transcoder 130 transcodes and/or otherwise processes the received media into a form suitable for streaming (e.g., a streaming format) using any suitable technique. For example, the transcoder 130 of the illustrated example transcodes the media according to MPEG4 audio/video compression used by the HLS protocol.

The metadata embedder 135 of the illustrated example of FIG1 is implemented by logic circuitry (such as a processor executing instructions), but may additionally or alternatively be implemented by analog circuitry, ASICs, DSPs, FPGAs, and/or other circuitry. In some examples, the transcoder 130, media identifier 125, and metadata embedder 135 are implemented by the same physical processor.

In the example shown, the metadata embedder 135 embeds the metadata determined by the media identifier 125 into the transport stream carrying the streaming media. In the example shown, the metadata embedder 135 embeds the metadata into an internal metadata channel, such as by encoding the metadata in binary and/or other suitable data formats into one or more data fields of the transport stream capable of carrying the metadata. For example, the metadata embedder 135 may insert ID3 tag metadata corresponding to metering metadata into a transport stream that is to stream the media according to HLS or other suitable streaming protocols. Additionally or alternatively, the metadata embedder 135 may embed the metadata into an external metadata channel, such as by encoding the metadata into an M3U8 or other data file that is associated with (e.g., included in, attached to, sent before, etc.) the transport stream that provides the streaming media to the client device 160.

1 is implemented by logic circuitry (e.g., a processor that executes instructions), but may additionally or alternatively be implemented by analog circuitry, ASICs, DSPs, FPGAs, and/or other circuitry. In some examples, transcoder 130, media identifier 125, metadata embedder 135, and media transmitter 140 are implemented by the same physical processor.

The media sender 140 of the illustrated example employs any suitable technique to select media and/or stream the media to a requesting device, such as the client device 160. For example, the media sender 140 of the illustrated example selects media that has been identified by the media identifier 125, transcoded by the transcoder 130, and subjected to metadata embedding by the metadata embedder 135. The media sender 140 then streams the media to the client device 160 using HLS or any other streaming protocol.

In some examples, media identifier 125, transcoder 130, and/or metadata embedder 135 prepare media for streaming regardless of whether a request is received from client device 160 (e.g., before a request is received from client device 160). In such examples, the prepared media is stored in a data repository (e.g., such as flash memory, magnetic media, optical media, etc.) of service provider 120. In such examples, upon receiving a request from client device 160, media transmitter 140 prepares a transport stream for streaming the prepared media to client device 160. In other examples, media identifier 125, transcoder 130, and/or metadata embedder 135 prepares media for streaming in response to a request received from client device 160.

The example network 150 of the illustrated example is the Internet. Additionally or alternatively, any other network that communicatively links the service provider 120 and the client devices may be used, such as, for example, a private network, a local area network (LAN), a virtual private network, etc. The network 150 may include any number of public and/or private networks using any type of network protocol.

The client device 160 of the illustrated example in FIG1 is a computing device capable of presenting streaming media provided by the media transmitter 140 via the network 150. The example client device 160 of the illustrated example is capable of presenting media directly (e.g., via a display), while in other examples, the client device 160 presents media on a separate media presentation device (e.g., speakers, a display, etc.). Therefore, as used herein, a "client device" may or may not present media without the assistance of a second device. The client device is typically a consumer electronic device. For example, the client device 160 of the illustrated example is a tablet such as an Apple tablet, and thus is capable of presenting media directly (e.g., via an integrated display and speakers). While a tablet is shown in the illustrated example, any other type and/or number of client devices may be used in addition or alternatively. For example, an internet-enabled mobile phone (e.g., a smartphone, etc.), a video game console (e.g., any generation, etc.), a tablet computer (e.g., a Motorola ^™ Xoom ^™ , etc.), a digital media player (e.g., a media player, a, etc.), a smart television, etc. may also be used in addition or alternatively.

A client device (such as client device 160 in FIG. 1 ) traditionally includes a browser 165 for displaying media. A browser is an application used to retrieve and display websites and media associated with the websites. When retrieving and displaying a website, browser 165 may execute scripts, such as JavaScript. The scripts are provided as part of the website and/or referenced by the website. In some examples, the scripts executed by browser 165 cause the browser to store information associated with the website's domain. For example, the scripts may cause browser 165 to store information as cookies. In some such examples, each time the browser retrieves a website, cookies are sent to the location from which the website was requested. However, only cookies associated with the domain of the requested website are sent. For example, when requesting "abc.com," cookies for the domain "xyz.com" are not sent. Sometimes, when requesting an internet resource (e.g., a URL) at a first location, the browser may receive a response from the server at the first location indicating that the browser should redirect the request to a second location. In the examples disclosed herein, the response is implemented using a Hypertext Transfer Protocol (HTTP) redirect message. However, any other means of redirecting the browser to the second location may additionally or alternatively be used.

The example database owners 180 and 182 of the illustrated example of FIG1 are implemented by servers hosted by an entity that maintains a database that identifies demographic information about a set of individuals. The server collaborates with an audience measurement entity to collect and return media presentation information and associated demographic information. Example database owners 180 and 182 include entities such as wireless service providers, mobile software/service providers, social networking sites (e.g., Facebook, Twitter, LinkedIn, Google, etc.), online retailer websites (e.g., Amazon.com, Buy.com, etc.), and/or any other internet website that maintains user registration records (e.g., Yahoo!, MSN, Apple iTunes, Experian, etc.). While there are two database owners in the illustrated example of FIG1 , any number of database owners may exist. Database owners 180 and 182 provide services to a large number of users. Instead of providing services, users register with the owner. As part of this registration, users provide detailed demographic information (such as, for example, their home mailing address, their credit score, their ethnicity and/or race, their age, their annual income, etc.). As part of using the services offered (e.g., social networking services, shopping services, news services, etc.), the database owner has the right to set and/or collect cookies that are stored by browsers accessing their domain (e.g., the Facebook.com domain) so that users of the services can be identified when the user sends a request to the database owner 180, 182 by retrieving the cookies from the user's device. Although this example discusses cookies, any other type of user identifier can be used.

1 includes an interface for receiving reported metering information (e.g., metadata) from the browser 165 of the client device 160 and/or the database owners 180, 182 via the network 150. In the illustrated example, the central facility 170 includes an HTTP interface for receiving HTTP requests including metering information. Additionally or alternatively, any other method of receiving metering information may be used, such as, for example, HTTP Secure (HTTPS), File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), etc.

In the example shown, central facility 170 instructs metadata embedder 135 and/or (more generally) service provider 120 to embed tags into the media to be streamed. In the example shown, the tags are formatted as ID3 tags. For example, the tags can be formatted as JavaScript instructions. However, any other format of tags and/or instructions can be used in addition or alternatively. In some examples, metadata embedder 135 is provided to service provider 120 by an audience measurement entity.

In the example shown, the central facility 170 stores and analyzes metering information received from a plurality of different client devices and/or from database owners 180, 182. For example, the central facility 170 may categorize and/or group metering information by media provider 110 (e.g., by grouping all metering data associated with a particular media provider 110). Any other processing of the metering information may additionally or alternatively be performed. In the example shown, the central facility 170 is associated with an audience measurement company and is not involved in delivering media to client devices.

Although the following examples refer to an audience measurement entity, any monitoring entity can serve in this role. Figure 1 is a block diagram of an example system constructed in accordance with the teachings of the present disclosure for monitoring media presentations. In the example shown in Figure 1, in order to track media impressions on a client device 160, an audience measurement entity (AME) cooperates or collaborates with a service provider to create a website that includes monitoring instructions. In the example shown, the AME provides a software development kit (SDK) to the service provider 120. The SDK of the example of Figure 1 is a collection of development tools (e.g., libraries (e.g., dynamic link libraries (DLLs), application programming interfaces (APIs), instructions, JavaScript files, etc.) that enable the service provider 120 to incorporate monitoring instructions into a website sent to the client device 160. In the examples disclosed herein, the monitoring instructions enable identification of media presented at the client device 160, and identification of the user device and/or demographics of the corresponding user via interaction with a database provider.

As disclosed herein, media monitoring instructions include instructions (e.g., Java, JavaScript, or any other computer language or script) that, when executed by the browser 165 and/or (more generally) the client device 160, cause the client device 160 to collect and/or otherwise identify media presented by the browser 165 and/or the client device 160, and to collect one or more user identifiers 166A, 166B (e.g., cookies). The user identifiers 166A, 166B of the illustrated example include identifiers that can be used by respective ones of the partner database owners 180, 182 to identify one or more users of the client device 160 and locate user information corresponding to the users. For example, user identifiers 166A, 166B may include hardware identifiers (e.g., International Mobile Equipment Identity (IMEI)), mobile equipment identifiers (MEID), media access control (MAC) addresses, etc.), app store identifiers (e.g., Google Android ID, Apple ID, Amazon ID, etc.), open source unique device identifiers (OpenUDID), open device identification numbers (ODIN), login identifiers (e.g., usernames), email addresses, user agent data (e.g., application type, operating system, software provider, software revision, etc.), third-party service identifiers (e.g., advertising service identifiers, device usage analysis service identifiers, demographic collection service identifiers), cookies, etc. In some examples, fewer or more user identifiers 166A, 166B may be used. The user identifiers 166A, 166B and media identification metadata are sent to the database owners 180, 182 in a request. This request is referred to as a virtual request because it is not actually a request for information (e.g., a web page), but rather a means for transmitting monitoring information (e.g., user identifiers 166A, 166B, media identification metadata, etc.). 1 and/or 2 , AME may collaborate with any number (e.g., 1, 2, 3, 4, etc.) of partner database owners to collect distributed media monitoring information. In the examples disclosed herein, when, for example, a user of a client device 160 uses services provided by the database owners 180, 182, the database owners 180, 182 collect and/or establish user identifiers 166A, 166B.

In the illustrated example, client device 160 requests media from service provider 120 (line 185). The media can be advertisements, video, audio, text, graphics, web pages, news, educational media, entertainment media, or any other type of media. In the illustrated example, service provider 120 responds to the request with the media (line 186). The response from service provider 120 (e.g., the media) includes monitoring instructions that cause the browser to identify the media, for example, from a third party. Browser 165 then displays and identifies the media by accessing a media ID stored in and/or associated with the media. In the example disclosed herein, the media ID is an ID3 tag that includes media identifying metadata, source identifying metadata, a watermark, etc. Following the monitoring instructions, browser 165 then sends a virtual request to database owner 180 (line 187). In the illustrated example, user identifier 166A (e.g., a cookie associated with database owner 180) has been previously stored by browser 165. The request to database owner 180 (line 187) includes user identifier 166A and the media identifier. In some examples, the media identifier is encrypted to prevent the database owners 180, 182 from identifying the media. The encrypted media identifier can then be decrypted by the central facility 170. The database owner 180 then determines that it can identify the user based on the user identifier 166A, stores the record of the media presentation, and sends a confirmation to the client device 160 (line 188). At a later time, the database owner 180 sends the record of the media presentation to the central facility 170 (line 194) and, in turn, receives a confirmation message (line 195). The record of the media presentation includes media identification metadata (which may be encrypted). In some examples, the recorded media identification metadata is formatted as an ID3 tag. Based on the received record, the central facility 170 and/or (more generally) the AME can report presentation metrics for different media.

FIG2 illustrates an alternative example system that can be used to determine exposure to streaming media. In the example shown in FIG2 , a browser 165 and/or (more generally) a client device 160 requests media from a service provider 120 (line 185). The media is returned to the browser 165 (line 186). Following monitoring instructions, the browser then sends the request and the accompanying user identifier 166A to the first database owner 180 (line 187). In the example shown in FIG2 , the database owner is unable to identify the user associated with user identifier 166A (and/or no user identifier is included in the request). In response, database owner 180 sends an HTTP redirect message to the browser 165. The browser 165 complies with the redirect message and sends a request to identify the media, along with the user identifier 166B stored in association with the second database owner 182, to the second database owner 182. The second database owner examines the user identifier 166B, stores it in association with the media identifier, and is able to identify the user associated with user identifier 166B, sending a confirmation to the browser 165 (line 193). The second database owner 182 then sends the media monitoring information and demographic information associated with the user to the central facility (line 194) and receives confirmation from the central facility 170 (line 195).

Figure 2A shows an alternative example system that can be used to determine exposure to streaming media. In the example shown in Figure 2A, instead of sending the first virtual request to database owner 180 (e.g., as shown by line 187 of Figure 2), the first virtual request of Figure 2A is sent to central facility 170 (e.g., as shown by line 197 of Figure 2A).

In the example shown in FIG2A , a first requesting browser 165 and/or (more generally) client device 160 requests media from service provider 120 (line 185). The media is returned to browser 165 (line 186). Acting upon monitoring instructions (e.g., instructions located by or carried in an ID3 tag sent with the media), the browser then sends the request and the attached user identifier 166A to central facility 170 (line 197). In the example shown in FIG2 , central facility 170 is unable to identify the user associated with user identifier 166A (and/or no user identifier is included in the request). In response, central facility 170 sends an HTTP redirect message to browser 165 (line 198).

Like the example database owner 180 of FIG2 , the example central facility 170 of FIG2A receives the virtual request from the browser 165 and, in some examples, responds to the browser 165 with a redirect message. The browser 165 complies with the redirect message and sends a request to the database owner 182 to identify the media and the user identifier 166B stored in association with the database owner 182. The database owner examines the user identifier 166B, stores the user identifier in association with the media identifier, and is able to identify the user associated with the user identifier 166B, sending a confirmation to the browser 165 (line 193). The database owner 182 then sends the media monitoring information and demographic information associated with the user to the central facility 170 (line 194) and receives a confirmation from the central facility 170 (line 195).

While only two database owners are shown in the examples shown in FIG1 , FIG2 , and/or FIG2A , any number of database owners may additionally or alternatively be used. Furthermore, while a single database owner records monitoring information in the examples shown, multiple database owners may record such information. Recording media identification information and/or demographic information associated with the presentation of media related to media identification information at multiple locations may increase the accuracy of demographic information associated with the presentation of media, enable recording of monitoring information that would not otherwise be recorded, and the like.

FIG3 is a block diagram of an example implementation of the browser 165 of FIG1. The example browser 165 of FIG3 includes an example media renderer 310, an example event listener 320, an example metadata retriever 330, an example metadata converter 340, an example metadata sending location determiner 345, an example sender 350, and an example user identification information repository 335.

The media renderer 310 of the illustrated example of FIG3 is implemented by a processor that executes instructions, but it can be implemented additionally or alternatively by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In the illustrated example, the media renderer 310 interacts with an application programming interface (API) to display media via the client device 160. Although the API is used in the illustrated example, any other media presentation framework can be used additionally or alternatively. For example, the example media renderer 310 can interact with a media presentation framework.

The example event listener 320 of the illustrated example of Figure 3 is implemented by a logic circuit (such as a processor that executes instructions), but it can be implemented additionally or alternatively by an analog circuit, an ASIC, a DSP, an FPGA and/or other circuit. In some examples, the media presenter 310 and the event listener 320 are implemented by the same physical processor. In the illustrated example, the example event listener 320 interacts with a JavaScript function to be able to receive and/or listen for event notifications. An event notification is any notification of an activity within a browser and/or application. When, for example, a new web page is loaded, media is presented, user input is detected, etc., an event notification can be triggered. Although JavaScript is used to listen for event notifications in the illustrated example, any other framework (such as, for example, ActiveX, Microsoft Silverlight, etc.) can be used to listen for event notifications.

The metadata retriever 330 of the illustrated example of FIG3 is implemented by logic circuitry (such as a processor executing instructions), but may also or alternatively be implemented by analog circuitry, an ASIC, a DSP, an FPGA, and/or other circuitry. In some examples, the media renderer 310, the event listener 320, and the metadata retriever 330 are implemented by the same physical processor. In the illustrated example, upon detecting an event notification by the event listener 320, the metadata retriever 330 retrieves metadata from the media renderer 310. In the illustrated example, the metadata retriever 330 retrieves metadata by inspecting the Document Object Model (DOM) object of the media renderer 310 using JavaScript. While JavaScript is used to retrieve the DOM object in the illustrated example, any other framework (such as, for example, ActiveX, Microsoft Silverlight, etc.) may be used to retrieve the DOM object. In some examples, the metadata retriever 330 retrieves information about the operation of the media renderer 310 and/or (more generally) the browser 165. The retrieved operational information may include, for example, information regarding whether the media presenter 310 is fully visible or partially visible (e.g., media presenter 310 is fully visible, media presenter 310 is 50% visible, media presenter 310 is not visible, etc.), information regarding whether the media presenter 310 is in the foreground or background, etc. In some examples, the operational information is sent to an audience measurement entity to enable calculation of additional media presentation metrics (e.g., whether a user is listening to streaming audio with the media presenter 310 in the background, etc.).

The metadata converter 340 of the illustrated example of FIG3 is implemented by logic circuitry (such as a processor executing instructions), but may also or alternatively be implemented by analog circuitry, an ASIC, a DSP, an FPGA, and/or other circuitry. In some examples, the media renderer 310, the event listener 320, the metadata retriever 330, and the metadata converter 340 are implemented by the same physical processor. In the illustrated example, the metadata converter 340 converts the metadata retrieved by the metadata retriever 330 into a format for transmission to the database owners 180, 182. For example, the metadata converter 340 may encrypt, decrypt, compress, modify, or otherwise modify the metadata and/or portions of the metadata to, for example, reduce the amount of data to be transmitted to the database owners 180, 182. In some examples, the metadata converter 340 encrypts media identification metadata to prevent the database owners 180, 182 from identifying the media. In such examples, the database owners 180, 182 transmit demographic information to the central facility 170 in conjunction with the encrypted media identification metadata. The central facility 170 (eg, an audience measurement entity) decrypts the encrypted media identification metadata to identify the presented media.

The metadata transmission location determiner 345 of the illustrated example of FIG3 is implemented by logic circuitry (such as a processor executing instructions), but it may also or alternatively be implemented by analog circuitry, an ASIC, a DSP, an FPGA, and/or other circuitry. In some examples, the media presenter 310, the event listener 320, the metadata retriever 330, the metadata converter 340, and the metadata transmission location determiner 345 are implemented by the same physical processor. In the illustrated example, the metadata transmission location determiner 345 examines the metadata and/or information transmitted using the metadata to determine where to send a virtual request carrying the metadata and any associated user identification information (e.g., user identifiers 166A, 166B). In the illustrated example, the metadata is transmitted as an ID3 tag. In some such examples, the ID3 tag includes a destination to which the virtual request should be sent. In the illustrated example, the destination is a uniform resource locator (URL) that includes media identification information and an internet domain specifying the URL to which the URL should be sent (e.g., databaseproprietor.com/<media-identifying information>). However, in some examples, the destination and media identification information are sent separately. In such an example, the metadata transmission location determiner 345 determines the URL based on the destination and the media identification information.

In some examples, different service providers implement monitoring instructions to specify a destination (e.g., a specific database owner) to which media identification information will be sent. Different service providers can therefore be associated with different database owners. Association with different database owners may enable more efficient and/or more accurate recording of media impressions and association of these impressions with demographic information. For example, a user viewing media at a financial website may be more easily identified by a database owner associated with financial services (e.g., a stock broker, credit bureau, Experian, etc.) than by a database owner associated with social media (e.g., Facebook, Twitter, etc.). Thus, a service provider can create monitoring instructions to cause a client device to send a virtual request to a specific database owner (e.g., Experian) that matches the media to be annotated.

In the illustrated example, the destination field of the ID3 tag that conveys media identification metadata includes a destination field that, when interpreted by the monitoring instruction, causes the monitoring instruction to send a virtual request to a specified destination (e.g., a URL). In such an example, the client device, in response to the monitoring instruction, determines the location to send the virtual request based on the destination field of the ID3 tag. Such an example of determining the location to send the virtual request based on the destination field of the ID3 tag is disclosed in conjunction with blocks 810 and 815 of FIG. 8 . Alternatively, the monitoring instruction for a given service provider can direct the client device to send the virtual request to a predetermined location. That is, rather than determining the location based on the destination field of the ID3 tag, the location is based on the instructions of the monitoring instruction. In some examples, the instruction is a JavaScript instruction implemented by the metadata transmission location determiner 345. An example of determining the location to send the virtual request based on the instructions of the monitoring instruction is disclosed in conjunction with blocks 820 and 825 of FIG. 8 .

The transmitter 350 of the illustrated example of FIG3 is implemented by logic circuitry (such as a processor executing instructions), but it may also or alternatively be implemented by analog circuitry, an ASIC, a DSP, an FPGA, and/or other circuitry. In some examples, the media presenter 310, the event listener 320, the metadata retriever 330, the metadata converter 340, the metadata send location determiner 345, and the transmitter 350 are implemented by the same physical processor. In the illustrated example, the transmitter 350 transmits media identification information and/or user identification information (e.g., user identifiers 166A, 166B) to the database owners 180, 182 via, for example, the Internet. While the media identification information is transmitted substantially in real time in the illustrated example, in some examples, the media identification information is stored, cached, and/or buffered before being transmitted to the database owners 180, 182. Furthermore, while the media identification information is transmitted to the database owners 180, 182 in the illustrated example, in some examples, the media identification information is transmitted to a different destination (such as, for example, the central facility 170). Additionally or alternatively, the sender 350 can send the user identifier 166A, 166B of the browser 165 and/or client device 160 to enable the database owner 180, 182 to associate the media presentation with a user, demographic, etc. In some examples, the media identification information is encrypted before being sent by the sender 350. Encrypting the media identification information prevents the database owner 180, 182 from accessing information about what media is identified. In some examples, the sender 350 sends the operational information retrieved by the metadata retriever 330 along with the media identification information.

The user identification information repository 355 of the illustrated example is implemented by a memory for storing information (e.g., user identification information, cookies, etc.). The example user identification information repository 355 of the illustrated example of FIG. 3 can be any device for storing data (such as, for example, flash memory, magnetic media, optical media, etc.). In the illustrated example, the user identification information repository 355 is implemented by random access memory of the client device 160. Furthermore, the data stored in the user identification information repository 355 can be in any data format (such as, for example, binary data, comma-delimited data, tab-delimited data, Structured Query Language (SQL) structures, etc.). Although the user identification information repository 355 is shown as a single database in the illustrated example, the user identification information repository 355 can be implemented by multiple databases and/or stored in multiple memory locations of a media device. In the illustrated example, each piece of user identification information is stored in association with a domain. When a request is sent (e.g., the virtual request of line 187 of FIG. 1 ), only the user identification information associated with the destination domain is sent.

FIG4 is a block diagram of an example implementation of the database owners 180, 182 of FIG1 , FIG2 , and/or FIG2A . The database owners 180, 182 of the illustrated example of FIG4 include an HTTP server 410, a user registration data receiver 420, a demographic information database 430, a user ID comparator 440, a metadata processor 450, a metadata database 460, and a metadata transmitter 470.

The example HTTP server 410 of FIG4 is implemented by a processor that executes instructions, but it can also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In the example shown, the example HTTP server 410 receives a request from the browser 165, which includes, for example, user identifiers 166A, 166B and/or media identification information (which can be encrypted) recognized by the browser 165. The example HTTP server 410 of FIG4 responds to the request from the browser 165 using an HTTP confirmation message and/or an HTTP redirect message. Although in the example shown, the HTTP server 410 uses the HTTP protocol for communication, any other protocol (such as, for example, the HTTP protocol, the FTP protocol, etc.) can also or alternatively be used.

The user registration data receiver 420 of the illustrated example of FIG4 is implemented by a processor that executes instructions, but it may also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the user registration data receiver 420 and the HTTP server 410 are implemented by the same physical processor. In the illustrated example, the example user registration data receiver 420 receives registration data from a user of the client device 160. The registration data may include, for example, demographic information, user name, geographic information, and/or any other information associated with the user. In the illustrated example, the user registration data receiver 420 receives the registration information from the user via the HTTP server 410. In other words, the registration information is received via a network (such as, for example, the Internet). However, the user information may be received in any other manner. For example, the user registration data may be received via a telephone call, fax transmission, manual input, etc., and the user registration data receiver 420 of the illustrated example of FIG4 stores the user registration data in the demographic information database 430.

The demographic information database 430 of the illustrated example is implemented by a memory for storing user registration data (e.g., demographic information associated with a user). The example demographic information database 430 of the illustrated example of FIG. 4 can be any device for storing data (such as, for example, flash memory, magnetic media, optical media, etc.). In the illustrated example, the demographic information database 430 is implemented by random access memory of the database owner 180, 182. Furthermore, the data stored in the demographic information database 430 can be in any data format (such as, for example, binary data, comma-delimited data, tab-delimited data, Structured Query Language (SQL) structures, etc.). Although the demographic information database 430 is shown as a single database in the illustrated example, the demographic information database 430 can be implemented by multiple databases and/or stored in multiple memory locations of the database owner 180, 182.

The user ID comparator 440 of the illustrated example of FIG4 is implemented by a processor that executes instructions, but it can also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the example user ID comparator 440, the example HTTP server 410, and the example user registration data receiver 420 are implemented by the same physical processor. In the illustrated example, the user ID comparator 440 receives a virtual request (e.g., the virtual request of line 187 of FIG1 ) from the browser 165 via the HTTP server 410. The virtual request may include user identifiers 168A and 166B. Therefore, the user ID comparator 440 checks the request to determine whether the user identifier is present, and/or, if present, whether the user identifier can be used to determine the user ID. If the user cannot be identified (e.g., the user identifier is unknown or does not exist), the user ID comparator 440 signals the HTTP server 410 that the browser 165 should be redirected to a different location (e.g., database owner 182, central facility 170). If the user can be identified, the user ID comparator 440 transmits the media identification metadata (which may be encrypted) and the user ID to the metadata database 460 .

The metadata processor 450 of the illustrated example of FIG4 is implemented by a processor that executes instructions, but it may also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the metadata processor 450, the example HTTP server 410, the example user registration data receiver 420, and the example user ID comparator 440 are implemented by the same physical processor. In the illustrated example, the metadata processor 450 stores the user ID identified by the user ID comparator 440 in a metadata database 460 in association with the media identification metadata (which may be encrypted).

Metadata database 460 is implemented by a memory for storing media identification metadata received from a browser via a virtual request (e.g., the request represented by line 187 in FIG. 1 ). The example metadata database 460 of the illustrated example of FIG. 4 can be implemented by any device for storing data, such as, for example, flash memory, magnetic media, optical media, etc. In the illustrated example, metadata database 460 is implemented by random access memory of database owners 180, 182. Furthermore, the data stored in metadata database 460 can be in any data format, such as, for example, binary data, comma-delimited data, tab-delimited data, Structured Query Language (SQL) structures, etc. Although metadata database 460 is shown as a single database in the illustrated example, metadata database 460 can be implemented by multiple databases and/or stored in multiple memory locations of database owners 180, 182. Furthermore, although metadata database 460 and demographic information database 430 are implemented as separate databases in the illustrated example, example metadata database 460 and example demographic information database 430 can be implemented using a single (i.e., identical) database.

The example metadata transmitter 470 of FIG. 4 is implemented by a processor executing instructions, but it may also or alternatively be implemented by analog circuitry, an ASIC, a DSP, an FPGA, and/or other circuitry. In some examples, the example metadata transmitter 470, the example HTTP server 410, the example user registration data receiver 420, the example user ID comparator 440, and the example metadata processor 450 are implemented by the same physical processor. In the example shown, the metadata transmitter 470 transmits demographic information associated with the user to whom the media was presented (identified by the media identification metadata) to the central facility 170. In the example shown, when the media has been presented to a threshold number of users, the metadata transmitter 470 transmits the demographic information and the associated media identification metadata (which may be encrypted). Similarly, the demographic information is aggregated across the multiple users to whom the media was presented. However, in some examples, the demographic information is transmitted on an individual basis. In the example shown, the metadata transmitter 470 transmits data to the central facility 170 regardless of whether the central facility 170 has requested the data. However, in some examples, the central facility 170 may request the metadata transmitter 470 to transmit the data.

FIG4A is a block diagram of an example implementation of the central facility 170 of FIG1 , FIG2 , and/or FIG2A . The central facility 170 of the illustrated example of FIG4A includes an HTTP server 171, a user registration data receiver 421, a demographic information database 431, a user ID comparator 441, a metadata processor 451, a metadata database 461, a metadata indicator 480, and a data receiver 481.

The example HTTP server 171 of FIG4A is implemented by a processor that executes instructions, but it can also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In the example shown, the example HTTP server 171 receives a request from the browser 165, which includes, for example, user identifiers 166A, 166B and/or media identification information (which can be encrypted) recognized by the browser 165. The example HTTP server 171 of FIG4A responds to the request from the browser 165 using an HTTP confirmation message and/or an HTTP redirect message. Although in the example shown, the HTTP server 171 uses the HTTP protocol for communication, any other protocol (such as, for example, the HTTP protocol, the FTP protocol, etc.) can also or alternatively be used.

The user registration data receiver 421 of the illustrated example of FIG4A is implemented by a processor that executes instructions, but it can also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the user registration data receiver 421 and the HTTP server 171 are implemented by the same physical processor. In the illustrated example, the example user registration data receiver 421 receives registration data from a user of the client device 160. The registration data may include, for example, demographic information, user name, geographic information, and/or any other information associated with the user. In the illustrated example, the user registration data receiver 420 receives the registration information from the user via the HTTP server 171. In other words, the registration information is received via a network (such as, for example, the Internet). However, the user information can be received in any other manner. For example, the user registration data can be received via a telephone call, fax transmission, manual input, etc., and the user registration data receiver 421 of the illustrated example of FIG4A stores the user registration data in the demographic information database 431.

The demographic information database 430 of the illustrated example is implemented by a memory for storing user registration data (e.g., demographic information associated with a user). The example demographic information database 431 of the illustrated example of FIG. 4A can be any device for storing data (such as, for example, flash memory, magnetic media, optical media, etc.). In the illustrated example, the demographic information database 431 is implemented by random access memory of the central facility 170. Furthermore, the data stored in the demographic information database 431 can be in any data format (such as, for example, binary data, comma-delimited data, tab-delimited data, Structured Query Language (SQL) structures, etc.). Although the demographic information database 431 is shown as a single database in the illustrated example, the demographic information database 431 can be implemented by multiple databases and/or stored in multiple memory locations of the central facility 170.

The user ID comparator 441 of the illustrated example of FIG4A is implemented by a processor that executes instructions, but it may alternatively or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the example user ID comparator 441, the example HTTP server 171, and the example user registration data receiver 421 are implemented by the same physical processor. In the illustrated example, the user ID comparator 441 receives a virtual request (e.g., the virtual request of line 197 of FIG2A ) from the browser 165 via the HTTP server 411. The virtual request may include user identifiers 168A and 166B. Therefore, the user ID comparator 441 examines the request to determine whether the user identifier is present, and/or, if present, determines whether the user identifier can be used to determine the user ID. If the user cannot be identified (e.g., the user identifier is unknown or not present in the request), the user ID comparator 441 signals the HTTP server 171 that the browser 165 should be redirected to a different location (e.g., database owner 182, central facility 170). If the user can be identified, the user ID comparator 441 transmits the media identification metadata (which may be encrypted) and the user ID to the metadata database 461 .

The metadata processor 451 of the illustrated example of FIG4A is implemented by a processor that executes instructions, but it may also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the metadata processor 451, the example HTTP server 171, the example user registration data receiver 421, and the example user ID comparator 441 are implemented by the same physical processor. In the illustrated example, the metadata processor 451 stores the user ID identified by the user ID comparator 441 in a metadata database 461 in association with the media identification metadata (which may be encrypted).

Metadata database 461 is implemented by memory for storing media identification metadata received from a browser via a virtual request (e.g., the request represented by line 197 in FIG. 2A ). Furthermore, example metadata database 461 stores demographic information and metadata received from database owners 180 , 182 via data receiver 481 . The example metadata database 461 of the illustrated example of FIG. 4A can be implemented by any device for storing data, such as, for example, flash memory, magnetic media, optical media, etc. In the illustrated example, metadata database 461 is implemented by random access memory of central facility 170 . Furthermore, the data stored in metadata database 461 can be in any data format, such as, for example, binary data, comma-delimited data, tab-delimited data, Structured Query Language (SQL) structures, etc. Although metadata database 461 is shown as a single database in the illustrated example, metadata database 461 can be implemented by multiple databases and/or stored in multiple memory locations of central facility 170 . Furthermore, although in the illustrated example, the metadata database 461 and the demographic information database 431 are implemented as separate databases, the example metadata database 461 and the example demographic information database 431 may be implemented using a single (ie, the same) database.

The example metadata indicator 480 of FIG4A is implemented by a processor executing instructions, but it may also or alternatively be implemented by analog circuitry, an ASIC, a DSP, an FPGA, and/or other circuitry. In some examples, the metadata indicator 480, the example metadata processor 451, the example HTTP server 171, the example user registration data receiver 421, and the example user ID comparator 441 are implemented by the same physical processor. In the example shown, the example metadata indicator 480 of the example central facility 170 instructs the metadata embedder 135 and/or (more generally) the service provider 120 to embed a tag in the media to be streamed. In the example shown, the metadata embedder 135 instructs the metadata embedder 135 to format the tag as an ID3 tag. The tag will cause a client device (e.g., browser 165 and/or (client device 160)) to send a message to the central facility 170.

The data receiver 481 of the example shown in FIG4A is implemented by a processor that executes instructions, but it can also or alternatively be implemented by analog circuits, ASICs, DSPs, FPGAs, and/or other circuits. In some examples, the data receiver 481, the example metadata processor 451, the example HTTP server 171, the example user registration data receiver 421, and the example user ID comparator 441 are implemented by the same physical processor. The example data receiver 481 of the example shown in FIG4A receives metadata and demographic information from the database owners 180, 182. FIG5 is a block diagram of an example implementation of an example HLS stream 500 that can be displayed by the example media renderer 310 of FIG3. In the example shown in FIG5, the HLS stream 500 includes a manifest 510 and three transport streams. In the example shown, the manifest 510 is a .m3u8 file that describes the available transport streams to the client device. However, any other past, present, and/or future file formats may be used in addition or alternatively. In the example shown, the client device retrieves the manifest 510 in response to an instruction to display the HLS element.

HLS is an adaptive format because, although multiple devices retrieve the same manifest 510, different transport streams may be displayed depending on one or more factors. For example, devices with different bandwidth availability (e.g., high-speed Internet connection, low-speed Internet connection, etc.) and/or different display capabilities (e.g., small screens such as mobile phones, medium-sized screens such as tablets and/or laptops, large screens such as televisions) select an appropriate transport stream for their display and/or bandwidth capabilities. In some examples, a mobile phone with a small screen and limited bandwidth uses a low-resolution transport stream. Alternatively, in some examples, a television with a large screen and a high-speed Internet connection uses a high-resolution transport stream. As the capabilities of a device change (e.g., a device moves from a high-speed Internet connection to a low-speed Internet connection), the device can switch to a different transport stream.

In the example shown in FIG5 , a high-resolution transport stream 520, a medium-resolution transport stream 530, and a low-resolution transport stream 540 are shown. In the example shown, each transport stream 520, 530, and/or 540 represents a portion of the associated media (e.g., 5 seconds, 10 seconds, 30 seconds, 1 minute, etc.). Thus, the high-resolution transport stream 520 corresponds to the first portion of the media, the second high-resolution transport stream 521 corresponds to the second portion of the media, and the third high-resolution transport stream 522 corresponds to the third portion of the media. Similarly, the medium-resolution transport stream 530 corresponds to the first portion of the media, the second medium-resolution transport stream 531 corresponds to the second portion of the media, and the third medium-resolution transport stream 532 corresponds to the third portion of the media. Furthermore, the low-resolution transport stream 540 corresponds to the first portion of the media, the second low-resolution transport stream 541 corresponds to the second portion of the media, and the third low-resolution transport stream 542 corresponds to the third portion of the media. Although three transport streams are shown for each resolution in the example shown in FIG5 , any number of transport streams representing any number of corresponding portions of the media may additionally or alternatively be used.

In the example shown, each transport stream 520, 521, 522, 530, 531, 532, 540, 541, and/or 542 includes a video stream 550, 551, 552, an audio stream 555, 556, 552, and a metadata stream 560, 561, 562. The video stream 550, 551, and/or 552 includes video associated with the media at different resolutions depending on the resolution of the transport stream associated with the video stream. The audio stream 555, 556, and/or 557 includes audio associated with the media. The metadata stream 560, 561, and/or 562 includes metadata (such as, for example, an ID3 tag associated with the media).

In the examples disclosed herein, the ID3 tag is formatted as an ID3v2 tag. However, metadata and/or metadata containers of any other type and/or format may be used in addition or alternatively. In the example shown, media identification information is stored in a private frame of the ID3 tag. However, media identification information may be stored in any other location. The media identification information of the example shown includes a destination domain name and a text version of an audio watermark identified by the media identifier 125 of Figures 1 and/or 2. In the example shown, the audio watermark is stored in a 64-base encrypted format. However, the watermark may be stored in any other manner. Furthermore, although in the example shown, the ID3 tag includes a destination domain name and an audio watermark, any other information (such as, for example, an identifier of the media provider 110, an identifier of the service provider 120, an identifier of the central facility 170, etc.) may be included in addition or alternatively in the ID3 tag.

Although example manners of implementing the example service provider 120 of Figures 1, 2, and/or 2A, the example browser 165 of Figures 1, 2, and/or 3, the example central facility 170 of Figures 1, 2, 2A, and/or 4A, and/or the example database owners 180, 182 of Figures 1, 2, 2A, and/or 4 are shown in Figures 1, 2, 2A, 3, 4, and/or 4A, one or more of the elements, processes, and/or devices shown in Figures 1, 2, 2A, 3, 4, and/or 4A may be combined, divided, rearranged, omitted, eliminated, and/or implemented in any other manner. 1 , 2 , and/or 2A , the example media identifier 125, the example transcoder 130, the example metadata embedder 135, the example media sender 140, and/or (more generally) the example service provider 120; the example media renderer 310, the example event listener 320, the example metadata retriever 330, the example metadata converter 340, the example metadata sending location determiner 345, the example sender 350, the example user identification information repository 355, and/or (more generally) the example browser 165 of FIG. 1 , 2 , 2A , and/or 3 ; the example HTTP server 171, the example user registration data receiver 421, the example demographic information data The library 431, the example user ID comparator 441, the example metadata processor 451, the example metadata database 461, the example metadata indicator 480 and the example data receiver 481 and/or (more generally) the example central facility 170; and/or the example HTTP server 410, the example user registration data receiver 420, the example demographic information database 430, the example user ID comparator 440, the example metadata processor 450, the example metadata database 460, the example metadata transmitter 470 and/or (more generally) the example database owners 180, 182 of Figures 1, 2, 2A and/or 4 can be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, the example media identifier 125 of Figures 1, 2, and/or 2A, the example transcoder 130, the example metadata embedder 135, the example media sender 140, and/or (more generally) the example service provider 120; the example media renderer 310 of Figures 1, 2, 2A, and/or 3, the example event listener 320, the example metadata retriever 330, the example metadata converter 340, the example metadata sending location determiner 345, the example sender 350, the example user identification information repository 355, and/or (more generally) the example browser 165; the example HTTP server 171 of Figures 1, 2, 2A, and/or 4A, the example user registration data receiver 421, the example demographic information database 431, the example user ID comparator 441, the example metadata The processor 451, the example metadata database 461, the example metadata indicator 480, the example data receiver 481 and/or (more generally) the example central facility 170; and/or any of the example HTTP server 410, the example user registration data receiver 420, the example demographic information database 430, the example user ID comparator 440, the example metadata processor 450, the example metadata database 460, the example metadata transmitter 470 and/or (more generally) the example database owners 180, 182 of Figures 1, 2, 2A and/or 4 can be implemented by one or more analog or digital circuits, logic circuits, programmable processors, application specific integrated circuits (ASICs), programmable logic devices (PLDs) and/or field programmable logic devices (FPLDs). When reading any of the device or system claims of this patent covering pure software and/or firmware implementations, the example media identifier 125, example transcoder 130, example metadata embedder 135, example media sender 140 and/or (more generally) example service provider 120 of Figures 1, 2, 2A and/or 3; the example media renderer 310, example event listener 320, example metadata retriever 330, example metadata converter 340, example metadata sending location determiner 345, example sender 350, example user identification information warehouse 355 and/or (more generally) example browser 165 of Figures 1, 2, 2A and/or 3; the example HTTP server 171, example user registration data receiver 421, example demographic information database of Figures 1, 2, 2A and/or 4A 431, the example user ID comparator 441, the example metadata processor 451, the example metadata database 461, the example metadata indicator 480 and the example data receiver 481 and/or (more generally) the example central facility 170; and/or the example HTTP server 410, the example user registration data receiver 420, the example demographic information database 430, the example user ID comparator 440, the example metadata processor 450, the example metadata database 460, the example metadata transmitter 470 and/or (more generally) the example database owners 180, 182 of Figures 1, 2, 2A and/or 4 are expressly defined herein as including a tangible computer-readable storage device or storage disk (such as, a memory, a digital video disk (DVD), a compact disk (CD), a Blu-ray disk, etc.) that stores software and/or firmware. In addition, in addition to or in place of those shown in Figures 1, 2, 2A, 3, 4 and/or 4A, the example service provider 120 of Figures 1, 2 and/or 2A, the example browser 165 of Figures 1, 2, 2A and/or 3, the example central facility 170 of Figures 1, 2, 2A and/or 4A, and/or the example database owners 180, 182 of Figures 1, 2, 2A and/or 4 may include one or more elements, processes and/or devices, and/or may include more than one of any or all of the elements, processes and devices shown.

Flowcharts representing example machine-readable instructions for implementing the example service provider 120 of FIG. 1 , FIG. 2 , and/or FIG. 2A , the example browser 165 of FIG. 1 , FIG. 2 , FIG. 2A , and/or FIG. 3 , the example central facility 170 of FIG. 1 , FIG. 2 , FIG. 2A , and/or FIG. 4A , and/or the example database owners 180 , 182 of FIG. 1 , FIG. 2 , FIG. 2A , and/or FIG. 4 are shown in FIG. 6 , FIG. 7 , FIG. 8 , FIG. 9 , FIG. 10 , and/or FIG. 11 . In these examples, the machine-readable instructions comprise a program for execution by a processor (e.g., the processor 1212 shown in the example processor platform 1200 discussed below in conjunction with FIG. 12 ). The program may be embodied in software stored on a tangible computer-readable storage medium (e.g., a CD-ROM, floppy disk, hard drive, digital video disk (DVD), Blu-ray disk, or memory associated with the processor 212), but the entire program and/or portions thereof may alternatively be executed by a device other than the processor 1212 and/or embodied in firmware or dedicated hardware. 6, 7, 8, 9, 10, and/or 11, many other methods of implementing the example service provider 120 of FIG. 1, 2, and/or 2A, the example browser 165 of FIG. 1, 2, 2A, and/or 3, the example central facility 170 of FIG. 1, 2, 2A, and/or 4A, and/or the example database owners 180, 182 of FIG. 1, 2, 2A, and/or 4 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the described blocks may be changed, eliminated, or combined.

As described above, the example processes of Figures 6, 7, 8, 9, 10, and/or 11 can be implemented using coded instructions (e.g., computer and/or machine-readable instructions) stored on a tangible computer-readable storage medium (such as a hard drive, flash memory, read-only memory (ROM), compact disk (CD), digital video disk (DVD), cache, random access memory (RAM), and/or any other storage device or storage disk that stores information for any duration (e.g., for an extended period of time, permanently, for a brief instance, temporarily buffered, and/or cached information). As used herein, the term tangible computer-readable storage medium is expressly defined to include any type of computer-readable storage device and/or storage disk and excludes propagating signals and transmission media. As used herein, "tangible computer-readable storage medium" and "tangible machine-readable storage medium" are used interchangeably. Additionally or alternatively, the example processes of Figures 6, 7, 8, 9, 10, and/or 11 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium (such as a hard drive, flash memory, read-only memory, optical disc, digital video disc, cache, random access memory, and/or any other storage device or storage disk that stores information for any duration (e.g., for an extended period of time, permanently, for a brief instance, temporarily buffered, and/or cached information). As used herein, the term non-transitory computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and excludes propagating signals and transmission media. As used herein, when the phrase "at least" is used as a transition term in the preamble of a claim, it is open ended in the same manner as the term "comprising" is open ended.

FIG6 is a flow diagram representing example machine-readable instructions 600 that can be executed to implement the example service provider 120 of FIG1 and/or FIG2. Execution of the example machine-readable instructions 600 of FIG6 begins with the media identifier 125 of the service provider 120 receiving media from the media provider 110 (block 610). In the example shown, the media is received as it is being broadcast (e.g., live). However, in some examples, the media is stored and/or cached by the media identifier 215.

The media identifier 215 of the illustrated example then identifies the media (block 620). The media identifier 215 identifies the media by extracting metering data (e.g., signatures, watermarks, etc.) from the media. Based on the extracted metering data, the media identifier 215 generates metadata (block 630). In the illustrated example, the metadata is generated in the ID3 format. However, any other metadata format may additionally or alternatively be used. Furthermore, in the illustrated example, the metadata is generated based on the extracted metering data. However, in some examples, the metadata may be generated by querying an external source using some or all of the extracted metering data.

The media is then transcoded by the transcoder 130 of the service provider 120 (block 640). In the example shown, the media is transcoded into an MPEG2 transport stream that can be sent via HTTP Live Streaming (HLS). The metadata embedder 135 of the service provider 120 embeds the metadata in the media (block 650). In some examples, the metadata is encrypted before being embedded in the media. In the example shown, the metadata is embedded in a metadata channel of the media. However, in some examples, the metadata may be embedded in an auxiliary data document, file, etc. that may be associated with the media. For example, the metadata may be embedded in a manifest file (e.g., an M3U8 file), a text track associated with the media, etc.

The media is then sent by the media sender 140 of the service provider 120 (block 660). In the example shown, the media is sent using HTTP Live Streaming (HLS). However, any other format and/or protocol for sending (e.g., broadcast, unicast, multicast, etc.) media may additionally or alternatively be used.

FIG7 is a flow diagram representing example machine-readable instructions 700 that can be executed to implement the example browser 165 of FIG1 , FIG2 , and/or FIG3 . Execution of the example machine-readable instructions 700 of FIG7 begins when the browser 165 is instantiated (e.g., by being loaded by a client device 160). The media renderer 310 of the browser 165 then begins rendering media by, for example, loading a display object for presentation via the client device 160 (block 710). In the example shown, the display object is an object. However, any other type of display object may additionally or alternatively be used.

The event listener 320 of the browser 165 begins listening for events (block 720). In the example shown, the event listener 320 listens for JavaScript events triggered by the media renderer 210. However, in some examples, the event listener 320 listens for any other events, such as, for example, media change events, user interaction events (e.g., when a user clicks on an object), display events (e.g., page load), etc. If the event listener 320 does not detect an event, the event listener 320 continues to listen for events until, for example, the browser 165 is closed, a different web page is loaded, etc.

If the event listener 320 detects an event, the metadata retriever 330 of the browser 165 retrieves the metadata (block 730). In the example shown, the event listener 320 passes the event object to the metadata retriever 330, which examines the event object to retrieve the metadata. However, in some examples, the event listener 320 passes an identifier of an object (e.g., a media renderer 310 display object) that indicates the object from which the metadata retriever 330 retrieves metadata. In the example shown, the metadata retriever 330 examines a document object module (DOM) object to retrieve metadata. However, in some examples, the metadata retriever 330 examines, for example, a timed text track, a metadata stream of HLS media, etc. to retrieve metadata. In the example shown, the metadata is formatted as an ID3 tag. However, any other format of metadata may be used in addition or alternatively. In some examples, the metadata retriever 330 retrieves information about the operation of the media renderer 310 and/or (more generally) the browser 165. The retrieved operation information may include, for example, information about whether the media presenter 310 is fully visible or partially visible (for example, the media presenter 310 is fully visible, the media presenter 310 is 50% visible, the media presenter 310 is not visible, etc.), information about whether the media presenter 310 is in the foreground or the background, etc.

The metadata converter 340 of the browser 165 then converts the metadata into a format for use by the sender 330 of the browser 165 (block 740). In the illustrated example, the metadata is converted from a binary data format to a text format. In some examples, the metadata is parsed to identify interesting portions (e.g., fields, segments, etc.) of the metadata (e.g., genre, artist, song title, album title, shipping station/service station, etc.). In some examples, the metadata converter 340 encrypts the metadata. Encrypting the metadata prevents third parties (e.g., database owners) from identifying the media while still allowing the recording of impressions for correlation with manual statistics. In the illustrated example, the metadata converter 340 adds a timestamp to the metadata before sending it to the database owners 180, 182. Adding a timestamp (e.g., recording the time at which an event occurred) enables accurate identification and/or correlation of the presented media and/or the time at which the media was presented to the user of the presentation device.

In some examples, the metadata may not undergo conversion before being sent by the sender (e.g., the metadata may be sent in a format in which it is retrieved by metadata retriever 330). In such examples, database owner 180, 182 and/or central facility 170 converts the metadata by, for example, converting the metadata to a different format, parsing the metadata to identify interesting portions of the metadata, decrypting the metadata, etc. Converting the metadata by database owner 180, 182 and/or central facility 170 facilitates associating the presented media with an identifier that identifies the person to whom the media will be presented. In some examples, database owner 180, 182 and/or central facility 170 timestamps the metadata upon receipt. Timestamping the metadata enables accurate identification and/or association of the presented media and/or the time it was presented to a user of a presentation device.

The metadata transmission location determiner 345 of the browser 165 then determines the location to which the metadata should be transmitted (block 750). In the illustrated example, the location is determined based on the domain name included in the ID3 tag. However, any other means of determining the location to which the metadata should be transmitted may additionally or alternatively be used. An example process for determining the location to transmit metadata is disclosed below in conjunction with FIG8 .

The sender 350 then sends the metadata to the location identified by the metadata send location determiner 345 (block 750). In the illustrated example, the metadata is sent using an HTTP Post request. However, any other method of sending data and/or metadata may additionally or alternatively be used. For example, the metadata may be sent using File Transfer Protocol (FTP) instructions, HTTP Get requests, Asynchronous JavaScript and Extensible Markup Language (XML) (AJAX) messages, etc. In some examples, the metadata is not sent to the database owners 180, 182 and/or the central facility 170. For example, the metadata may be sent to a display object on the client device 160 for display to the user. In the illustrated example, the metadata is sent in real time (e.g., streamed) to the database owners 180, 182. However, in some examples, the metadata may be stored (e.g., cached, buffered, etc.) for a period of time before being sent to the database owners 180, 182. In some examples, the sender 350 sends operational data retrieved from the media renderer 310 by the metadata retriever 330. Sending the operational information enables the audience measurement entity to calculate additional media presentation metrics (eg, whether the user is listening to streaming audio in the background using the media presenter 310, etc.).

FIG8 is a flow diagram representing example machine-readable instructions 800 that can be executed to implement the example browser 165 of FIG1 , FIG2 , and/or FIG3 . The example flow diagram of FIG8 illustrates the process by which the metadata send location determiner 345 of FIG3 determines a destination for sending metadata and/or user identifier data, for example, via a virtual request (e.g., line 187 of FIG1 ). Execution of the example machine-readable instructions 800 of FIG8 begins with the metadata send location determiner 345 determining whether metadata included in an ID3 tag identified by the metadata retriever 330 of FIG3 identifies a location to send metadata (block 810). In some examples, the ID3 tag includes a URL specifying a location to which the metadata should be sent. The URL can identify, for example, a preferred database owner 180, 182. If the ID3 tag includes a URL specifying a location to which the metadata should be sent (block 810), the metadata send location determiner 345 uses the location (e.g., URL) identified by the metadata (block 815) to determine the destination for the virtual request.

However, in some examples, the ID3 tag does not identify a location to send metadata. If the ID3 tag does not identify a location to send metadata (block 810), the example metadata send location determiner 345 determines whether the service provider identifies a location to send metadata (block 820). In some examples, the service provider 120, when implementing an SDK associated with monitoring instructions implemented by the browser 165, specifies a database owner to which the metadata should be sent. In such examples, the metadata send location determiner 345 uses the location identified by the service provider (block 825) to determine the destination of the virtual request.

In some examples, neither the metadata nor the service provider can identify the location to which the metadata should be sent (blocks 810, 820). In such examples, the metadata send location determiner 345 uses a default location to send the metadata (block 830) to determine the destination of the virtual request. The default location can be, for example, a preferred database owner such as, for example, Facebook, Twitter, Experian, etc. In some examples, the default location can be the central facility 170. The example machine-readable instructions 800 of FIG. 8 then terminate, and the sender 350 of FIG. 3 continues to send the metadata and user identifier associated with the destination via the virtual request (block 760 of FIG. 7).

FIG9 is a flow diagram representing example machine-readable instructions 900 that can be executed to implement the example database owners 180, 182 of FIG1 , FIG2 , FIG2A , and/or FIG4 . In some examples, the example instructions 900 of the illustrated example of FIG9 can be executed to implement the example central facility 170 of FIG1 , FIG2 , FIG2A , and/or FIG4 . Execution of the example machine-readable instructions 900 of FIG9 begins when the HTTP server 410 of the database owner 180 of FIG4 receives a virtual request (e.g., virtual request 187 of FIG1 ) from a browser (block 910). The virtual request includes media identification metadata and may additionally include user identification data (such as, for example, user identifiers 166A, 166B). Based on the received user identifiers and/or the absence of a user identifier, the user ID comparator 440 determines whether the user identifiers 166A, 166B identify a user known to the database owner 180 (block 920). To make such a determination, user ID comparator 440 may query demographic information database 430 to determine whether the user identifier and/or any other information associated with cookies 166A, 166B can be used to identify the user. If the cookie data cannot be used to identify the user (block 920), user ID comparator 440 determines the next hop location to which browser 165 should be directed (block 930). The next hop location may be, for example, a different database owner 182, a central facility 170, or the like. For example, in the example shown in FIG2 , database owner A 180 cannot identify the user and therefore identifies database owner B 182 as the next hop location. Using the next hop location, HTTP server 410 sends a redirect message to browser 165 to identify the next hop location (block 940). Referring again to FIG2 , the redirect message is represented by line 191. In some examples, browser 165 may be directed to multiple database owners (e.g., a first database owner redirects the browser to a second database owner, the second database owner redirects the browser to a third database owner, and so on).

If the user identifier data can be used to identify the user (block 920), user ID comparator 440 determines the user identifier (block 950). Metadata processor 450 then stores the received metadata and the associated user identifier in metadata database 460 (block 960). In the example shown, metadata processor 450 stores media identification metadata (e.g., ID3 tags) and the user identifier. When storing metadata and user identifiers, metadata processor 450 may store impression records in a manner similar to, for example, table 1070 of FIG. 10A. In some examples, metadata processor 450 stores a timestamp to help identify the time the media was presented.

HTTP server 410 then sends a confirmation message to the requesting client (block 970). Sending the confirmation message notifies the requesting client (e.g., browser 165) that no further action is required regarding the virtual request. In some examples, even if database owner 180 is able to identify the user, database owner 180 sends a redirect message instructing browser 165 to contact second database owner 182. Such redirection can enable different database owners, which may store different types of demographic data (e.g., financial data, geographic data, etc.), to collect a larger set of demographic data that could be collected by a single database owner.

FIG10 is a flow diagram representing example machine-readable instructions 1000 that may be executed to implement the example database owners 180, 182 of FIG1 , FIG2 , FIG2A , and/or FIG4 . Execution of the example machine-readable instructions 1000 of FIG10 begins with the metadata processor 450 selecting metadata stored in the metadata database 460 associated with a threshold number of users (e.g., 20 users, 100 users, etc.) (block 1010). The impression data may be formatted in a manner similar to the impression record shown, for example, in the example table 1070 of FIG10A . The metadata processor 450 then determines a user identifier associated with the selected metadata (block 1020). Based on the identified user identifier, the metadata processor 450 aggregates demographic information associated with the identified user identifier (block 1030). The demographic information may be stored in a manner similar to the demographic information shown, for example, in the example table 1080 of FIG10B . The aggregated demographic information is sent to the central facility 170 by the metadata transmitter 470 in association with the selected metadata (e.g., ID3 tags) (block 1040). The aggregated demographic information and media identifiers may be sent to the central facility in a format similar to, for example, the example table 1089 of FIG. 10C . The metadata processor 450 then determines whether additional metadata that meets the threshold requirements for transmission to the central facility 170 is stored in the metadata database (block 1050). If additional metadata exists, the metadata processor selects the metadata (block 1010). If no additional metadata exists, the process terminates. Although in the illustrated example of FIG. 10 , the demographic information is sent to the central facility 170 independently of a request from the central facility 170, in some examples, the central facility 170 may request demographic information associated with specific metadata from the database owner 180.

10A is a table 1070 representing impression data recorded by an example database owner 180. The example table 1070 includes a first column 1071 for storing a media identifier (e.g., an ID3 tag), a second column 1072 for storing a user identifier, and a third column 1073 for storing a timestamp. Although three columns are shown in the illustrated example, any other columns for storing any other information may additionally or alternatively be used (such as, for example, a column for storing an Internet Protocol address of a client device, a column for storing a service provider identifier, etc.).

In the example shown in FIG10A , example table 1070 includes a first row 1074 of impression data, a second row 1075 of impression data, a third row 1076 of impression data, a fourth row 1077 of impression data, and a fifth row 1078 of impression data. However, any other number of records may be stored additionally or alternatively. For example, the example table may include ten thousand rows of data corresponding to ten thousand recorded impressions. In the example shown in FIG10A , first example row 1074 identifies that a first piece of media was presented to a first user (e.g., media 0001 was presented to user A). Second example row 1075 identifies that the first piece of media was presented to a second user. Third example row 1076 identifies that the first piece of media was presented to a third user. Fourth example row 1077 identifies that a second piece of media was presented to the first user. Fifth example row 1078 identifies that the second piece of media was presented to a fourth user. In some examples, media identifiers (e.g., media 0001) are encrypted, allowing a database owner to determine that the media identifiers correspond to the same piece of media, but not the identity of the media.

FIG10B is a table 1080 representing demographic information stored by the database owner 180. The example table 1080 includes a first column 1082 storing a user identifier (e.g., the user identifier of the first column 1072 of FIG10A ), a second column 1083 storing first demographic information (e.g., age), and a third column 1085 storing second demographic information (e.g., income). Although in the example shown in FIG10B , there are two columns storing demographic information, any other number of columns storing any other information may additionally or alternatively be used. For example, additional columns storing other demographic information (e.g., race, mailing address, gender, etc.) may be used. Additionally or alternatively, columns storing user information (e.g., user account creation date, "last visited" date, user preferences, etc.) may be used.

In the example shown, four user records are shown. A first user record 1085 represents user A. A second user record 1086 represents user B. A third user record 1087 represents user C. A fourth record 1088 represents user D. Although four user records are shown in the example shown in FIG10B , any other number of records may additionally or alternatively be used. For example, a database owner may store 50,000 records each associated with 50,000 users.

FIG10C is a table 1089 representing aggregated media presentation information sent by database owner 180 to central facility 170. As described in conjunction with FIG10 , the database owner aggregates demographic information (e.g., the demographic information of example table 1080 of FIG10B associated with the media impression data of example table 1070 of FIG10A ). Example table 1089 represents aggregated demographic data showing multiple impressions associated with various demographics and different media identifiers.

The example table 1089 of FIG10C includes a first column 1090 representing media identifiers. The example table 1089 includes a second column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in the first column 1090 who are under the age of 20. The example table 1089 includes a third column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in the first column 1090 who are between the ages of 20 and 40. The example table 1089 includes a fourth column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in the first column 1090 who are between the ages of 40 and 60. The example table 1089 includes a fifth column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in the first column 1090 who are over the age of 60. Although age is divided into 20-year ranges in the example shown, any other ranges (e.g., 1, 2, 5, 10, etc.) can be used.

In the example shown in FIG10C , example table 1089 includes a sixth column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in first column 1090 whose annual income is less than $40,000. Example table 1089 includes a seventh column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in first column 1090 whose annual income is between $40,000 and $80,000. Example table 1089 includes an eighth column representing a count (e.g., a sum) of the number of users exposed to media identified by the media identifiers in first column 1090 whose annual income is greater than $80,000. Although in the example shown, income is divided into a range of $40,000, any other ranges and/or divisions may be used in addition or alternatively. Furthermore, although in the example shown in FIG10C , demographic information for age and income is aggregated, any other demographic information may be aggregated in addition or alternatively. Additionally, although age and income are shown separately, other combinations are possible (eg, people aged 40-60 with an annual income of 40,000-60,000).

FIG11 is a flow diagram representing example machine-readable instructions 1100 that can be executed to implement the example central facility 170 of FIG1 and/or FIG2. Execution of the example machine-readable instructions 1100 of FIG11 begins with the central facility 170 receiving metadata (which may be encrypted and/or formatted as an ID3 tag) and demographic information associated with the metadata from database owners 180, 182 (block 1110). In the illustrated example, the data receiver 481 of the example central facility 170 receives the metadata from the database owners 180, 182 without first requesting such data from the database owners. That is, the database owners 180, 182 send the associated demographic information to the central facility 170 on their own initiative. The metadata processor 451 of the example central facility 170 then determines whether data from additional database owners should be received before continuing (block 1120). For example, while the data receiver 481 of the example central facility 170 may have received data from a single database owner, receiving metadata and demographic information from multiple database owners may result in a more accurate report of the demographic exposure associated with the presented media. In some examples, the media identification metadata received in association with the demographic information may be encrypted. In such an example, the metadata processor 451 decrypts the encrypted media identification metadata to enable identification of the media.

If data has been received from a sufficient number of database owners (block 1120), the metadata processor 451 aggregates demographic data from the database owners (block 1130). The metadata processor 451 then generates a media presentation report based on the metadata and the aggregated demographic information (block 1140).

12 is a block diagram of an example processor platform 1000 capable of executing instructions of FIG6, FIG7, FIG8, FIG9, FIG10, and/or FIG11 to implement the example service provider 120 of FIG1 and/or FIG2, the example browser 165 of FIG1, FIG2, FIG2A, and/or FIG3, and/or the example database owners 180, 182 of FIG1, FIG2, and/or FIG4. The processor platform 1200 may be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smartphone, a tablet such as an iPad ^™ ), a personal digital assistant (PDA), an internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, or any other type of computing device.

The processor platform 1200 of the illustrated example includes a processor 1212. The processor 1212 of the illustrated example is hardware. For example, the processor 1212 may be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family or manufacturer.

The processor 1212 of the illustrated example includes a local memory 1213 (e.g., a cache). The processor 1212 of the illustrated example communicates with a main memory including a volatile memory 1214 and a non-volatile memory 1216 via a bus 1218. The volatile memory 1214 can be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and/or any other type of random access memory device. The non-volatile memory 1216 can be implemented by flash memory and/or any other desired type of memory device. Access to the main memories 1214 and 1216 is controlled by a memory controller.

The processor platform 1200 of the illustrated example also includes an interface circuit 1220. The interface circuit 1220 may be implemented by any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), and/or a PCI Express interface.

In the example shown, one or more input devices 1222 are connected to the interface circuit 1220. The input devices 1222 allow a user to enter data and commands into the processor 1212. The input devices may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a trackpad, a trackball, an isochronous point, and/or a voice recognition system.

One or more output devices 1224 are also connected to the interface circuit 1220 of the illustrated example. Output device 1224 can be implemented, for example, by a display device (e.g., a light emitting diode (LED)), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube (CRT), a touch screen, a tactile output device, a light emitting diode (LED), a printer, and/or a speaker. Therefore, the interface circuit 1220 of the illustrated example typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

The interface circuitry 1220 of the illustrated example also includes communication devices (such as transmitters, receivers, transceivers, modems, and/or network interface cards) to facilitate data exchange with an external machine (e.g., any type of computing device) via a network 1226 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular telephone system, etc.).

The processor platform 1200 of the illustrated example also includes one or more mass storage devices 128 for storing software and/or data. Examples of such mass storage devices 1228 include floppy disk drives, hard disk drives, optical disk drives, Blu-ray disk drives, RAID systems, and digital video disk (DVD) drives.

The encoded instructions 1232 of Figures 6, 7, 8, 9, 10 and/or 11 may be stored in the mass storage device 1228, in the volatile memory 1214, in the non-volatile memory 1216, and/or on a removable tangible computer-readable storage medium such as a CD or DVD.

Based on the above, it should be understood that the methods, devices, and articles disclosed above are capable of monitoring media presentations and associating demographic information provided by one or more database owners with the media presentations. Specifically, in response to detecting a media presentation, media identification metadata (which may be encrypted and/or formatted as an ID3 tag) and user identification information are sent by a client device to the database owner. The database owner aggregates demographic information associated with the presented media (based on the user identification information) and reports the demographic information and media identification information to an audio measurement entity.

Although certain example methods, apparatus, and articles have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus, and articles fairly falling within the scope of the claims of this patent.

Claims (28)

1. A method for measuring the exposure of a streaming media, the method comprising: The processor detects the ID3 tags associated with the streaming media presented on the client device; In response to the ID3 tag, a first request is sent from the client device to a first Internet domain, the first request identifying the streaming media; Receive redirection messages from the first Internet domain; and In response to the redirection message, a second request is sent to a second Internet domain specified by the redirection message, the second request including a cookie identifying the client device. 2. The method according to claim 1, wherein the first Internet domain is determined based on the fields of the ID3 tag. 3. The method of claim 1, wherein the media is received from a service provider, and the first Internet domain is determined based on information provided by the service provider. 4. The method of claim 1, wherein the first Internet domain is specified by a Uniform Resource Locator. 5. The method according to claim 1, further comprising: extracting the ID3 tag from the metadata stream of the streaming media. 6. The method of claim 1, wherein the ID3 tag causes the client device to send a request for a monitoring instruction, the monitoring instruction causing the client device to send the first request. 7. The method according to claim 1, further comprising: collecting operation information of the media presenter of the streaming media, wherein the first request includes the operation information. 8. An apparatus for measuring the exposure of a streaming media, the apparatus comprising: Metadata retriever, the metadata retriever being used to retrieve metadata associated with media presented at a client device, the metadata being located in an ID3 tag; A metadata transmission location determiner, the metadata transmission location determiner being used to determine the location for transmitting the metadata, the location being determined based on the metadata of the ID3 tag; and A transmitter for sending a request to the location, the request including the metadata and user identification data, the user identification data being accessible at the location. 9. The apparatus of claim 8, further comprising: a media presenter for presenting the media at the client device. 10. The device of claim 9, further comprising: an event listener for listening to an event triggered by the media presenter, the metadata retriever retrieving the metadata in response to the detection of the event. 11. The device of claim 10, wherein the event is a media presentation event. 12. The apparatus of claim 8, further comprising: a metadata converter for converting the metadata in the ID3 tag into a request payload. 13. The device according to claim 8, further comprising: a user identification information warehouse for storing the user identification data. 14. The device according to claim 13, wherein the user identification data is cookie data. 15. A method for monitoring the exposure of a streaming media, the method comprising: The audience measurement server instructs the content provider to embed ID3 tags into the media to be streamed, and the ID3 tags enable the client device to contact the audience measurement server. The audience measurement server receives a first request generated by a client device accessing the tag, the first request identifying the streaming media; Sending a redirection message from the audience measurement server to the client device; and The client device receives user identification information from the social media provider specified in the redirect message. 16. The method of claim 15, wherein the identification information of the streaming media is encrypted. 17. The method of claim 15, further comprising: sending a request to the social media provider to provide demographic information associated with the streaming media. 18. The method of claim 15, wherein the redirection message is a Hypertext Transfer Protocol redirection message. 19. A device for monitoring the exposure of a streaming media, the device comprising: Metadata indicator, which instructs content providers to embed ID3 tags into the media to be streamed, the tags causing client devices to send messages to an audience measurement server; A server, in response to a first request generated by a client device accessing the tag, sends a redirection message to the client device, the first request identifying the streaming media; and A data receiver, configured to receive identification information of the client device from the social media provider specified in the redirect message. 20. The device of claim 19, wherein the data receiver sends a request to the social media provider to provide demographic information associated with the streaming media. 21. The device of claim 19, wherein the redirection message is a Hypertext Transfer Protocol redirection message. 22. A method for measuring the exposure of a streaming media, the method comprising: Extract media identification information from media obtained by media providers; Metadata identifying the media is generated based on the media identification information; Determine the address of the database owner to which the metadata will be sent; Embed the database owner's address and the metadata in an ID3 tag; and The media and the ID3 tag are sent to the client device. 23. The method of claim 22, further comprising: sending an instruction to the client device, the instruction causing the client device to send the metadata to the address of the database owner. 24. The method of claim 23, wherein the instruction is located in the ID3 tag. 25. The method according to claim 22, further comprising: encrypting the media identification information. 26. A device for monitoring the exposure of a streaming media, the device comprising: A media identifier, wherein the media identifier is used to extract media identification information from media obtained by a media provider, and the media identifier generates metadata that identifies the media based on the media identification information; A metadata embedder, used to determine the address of the database owner to whom the metadata will be sent, embedding the database owner's address and the metadata in an ID3 tag; and A media transmitter for sending the media and the ID3 tag to a client device. 27. The device of claim 26, wherein the metadata embedder determines the address based on instructions received from the audience measurement server. 28. The device of claim 26, wherein the metadata embedder encrypts the metadata before embedding the metadata into the ID3 tag.