HK1196737B - Monitoring streaming media content - Google Patents

Abstract

Methods, apparatus and articles of manufacture to monitor streaming media content are disclosed. An example method disclosed herein to monitor streaming media content comprises extracting metering data having a first format from media content to be provided to a content presentation device via a transport stream, the extracted metering data identifying at least one of the media content or a source of the media content, the extracted metering data not being decodable by a meter associated with the content presentation device, transcoding the extracted metering data to form transcoded metering data having a second format decodable by the meter associated with the content presentation device, and encoding the transcoded metering data into a metadata channel to send the transcoded metering data to the content presentation device, the metadata channel being associated with the transport stream.

Description

Monitoring streaming media content

RELATED APPLICATIONS

This patent claims the priority of united states patent application No. 13/341,646 entitled "Monitoring Streaming Media Content" filed on 30.12.2011, and also claims the priority of united states provisional application No. 61/499,520 entitled "Monitoring Streaming Media Content" filed on 21.6.2011 and united states provisional application No. 61/568,631 entitled "Monitoring Streaming Media Content" filed on 8.12.2011. This patent also claims priority from us application No. 13/341,661 entitled "monitoring streaming Media Content" filed on 30.12.2011, which also claims priority from us provisional application No. 61/499,520 and us provisional application No. 61/568,631. U.S. application nos. 13/341,646 and 13/341,661 and U.S. provisional application nos. 61/499,520 and 61/568,631, respectively, are hereby incorporated by reference in their entireties.

Technical Field

The present disclosure relates generally to content monitoring and, more particularly, to monitoring streaming media content.

Background

Streaming enables media content to be transmitted to and presented by a variety of content presentation devices, such as desktop computers, laptop computers, tablet computers, personal digital assistants, smart phones, and the like. Since a large portion of the media content is provided to these devices by streaming, monitoring of streaming media content, e.g., monitoring of broadcast media content, can provide valuable information to advertisers and content providers, among others.

Drawings

FIG. 1 is a block diagram of a first exemplary system for monitoring streaming media content.

FIG. 2 is a block diagram of a first example server meter to implement the example system of FIG. 1.

FIG. 3 is a block diagram of a first example device meter to implement the example system of FIG. 1.

FIG. 4 is a block diagram of a first example media monitoring device to implement the example system of FIG. 1.

FIG. 5 is a block diagram of a second exemplary system for monitoring streaming media content.

Fig. 6 is a block diagram of a second example server meter to implement the example system of fig. 5.

FIG. 7 is a block diagram of a second example device meter to implement the example system of FIG. 5.

FIG. 8 is a block diagram of a second exemplary media monitoring device to implement the exemplary system of FIG. 5.

FIG. 9 is a block diagram of a third exemplary system for monitoring streaming media content.

Fig. 10 is a block diagram of a third example server meter to implement the example system of fig. 9.

FIG. 11 is a block diagram of a third example media monitoring device to implement the example system of FIG. 5.

FIG. 12 is a block diagram of a fourth exemplary system for monitoring streaming media content.

FIG. 13 is a flow diagram representing example machine readable instructions that may be executed to implement the first example server meter of FIG. 2.

FIG. 14 is a flow diagram representing example machine readable instructions that may be executed to implement the first example device meter of FIG. 3.

FIG. 15 is a flow diagram representing example machine readable instructions that may be executed to implement the first example media monitoring device of FIG. 4.

Fig. 16 is a flow diagram representing example machine readable instructions that may be executed to implement the second example server meter of fig. 6.

FIG. 17 is a flow diagram representing example machine readable instructions that may be executed to implement the second example device meter of FIG. 7.

FIG. 18 is a flow diagram representing example machine readable instructions that may be executed to implement the second example media monitoring device of FIG. 8.

FIG. 19 is a flow diagram representing example machine readable instructions that may be executed to implement the third example server meter of FIG. 10.

FIG. 20 is a flowchart representative of example machine readable instructions that may be executed to implement the third example media monitoring device of FIG. 11.

FIG. 21 is a flow diagram representing exemplary machine readable instructions that may be executed to implement an exemplary metadata interpolator included in the exemplary system of FIG. 12.

Fig. 22 is a flow diagram representing example machine readable instructions that may be executed to implement an example transcoder included in the example system of fig. 12.

FIG. 23 is a block diagram of an exemplary system incorporating metering data that describes streaming media content.

Fig. 24 is a block diagram of a fourth example server meter to implement the example system of fig. 23.

Fig. 25 is a flow diagram representing example machine readable instructions that may be executed to implement the fourth example server meter of fig. 24.

FIG. 26 illustrates exemplary metadata generated by the server meter of FIG. 24.

FIG. 27 illustrates second exemplary metadata generated by the server meter of FIG. 24.

FIG. 28 is a block diagram of a fifth exemplary system for monitoring streaming media content.

FIG. 29 is a flow diagram representing example machine readable instructions that may be executed to implement the example media monitoring device included in the example system of FIG. 28.

FIG. 30 is a flow diagram representing example machine readable instructions that may be executed to implement the example device meter and secondary content presenter of FIG. 28.

Fig. 31 is a block diagram of an example processing system that may execute the example machine readable instructions of fig. 13-22, 25, 29, and/or 30 to implement one or more of the example systems of fig. 1, 5, 9, 12, 23, and/or 28, one or more of the example server meters of fig. 2, 6, 10, and/or 24, one or more of the example device meters of fig. 3 and/or 7, and/or one or more of the example media monitoring devices of fig. 4, 8, and/or 11.

Detailed Description

Methods, apparatus, and products to monitor production of streaming media content are disclosed herein. An exemplary method of monitoring streaming media content disclosed herein includes decoding a transport stream carrying media content to be streamed to a content presentation device to obtain the media content. The exemplary method also includes extracting metering data having a first format from the media content, the metering data identifying at least one of the media content or a source of the media content. The example method also includes transcoding the extracted metering data to form metering data (e.g., metering metadata) having a second format that is decodable by a meter operated by the content presentation device.

In some examples, the method further includes combining the extracted metering data or otherwise collected metering data that is dependent on (e.g., accompanies) the streaming media content (e.g., metering data from a media content provider) with metering data that is related to the streaming media content but is provided independently of the streaming media content (e.g., metering data from an independent metering data source). In some such examples, the extracted metering data is combined with metering data from an independent metering data source, and then transcoded to form metering metadata. In some examples, an independent metering data source determines a timestamp from a clock source and determines an identifier (e.g., a configuration file) for streaming media content from a data source communicatively coupled with the independent metering data source. In some examples, the metering data and the extracted metering data from separate metering data sources are redundant, the same, or similar. In some examples, the method includes inserting, by an independent metering data source, a tag or other identifying indicia into the extracted metering data to identify the independently provided metering data. In some examples, a delimiter (e.g., a text character, e.g., "i" character, or some other symbol or indicator) is inserted between the extracted metering data and the metering data from the independent metering data source.

In some examples, the method further includes encoding the transcoded metering data (e.g., extracted metering data or transcoded combined metering data) into a metadata channel associated with (e.g., accompanying or streaming with) the transport stream, and sending the transport stream and the metadata channel to the content presentation device. In some examples, the method further includes receiving the transport stream and the metadata channel at the content presentation device, detecting, with a meter executed by the content presentation device, metering data in the metadata channel, and reporting the metering data to the media monitoring device.

In some examples, the metadata channel corresponds to at least one of: an external metadata channel outside of the transport stream carrying the media content; or an internal metadata channel comprising one or more data fields of a transport stream carrying media content. Examples of external metadata channels include an M3U file or other data file encoded to include metering metadata and associated with a transport stream to be sent to a content presentation device.

In some examples, the transport stream corresponds to a Moving Picture Experts Group (MPEG)2 transport stream transmitted according to the hypertext transfer protocol (HTTP) real-time streaming media protocol. In some examples, metering data having a first format (which is extracted from media content decoded from a transport stream) may include an audio watermark embedded in an audio portion of the media content. Additionally or alternatively, the metering data having the first format (which is extracted from the media content decoded from the transport stream) may include a video (e.g., image) watermark embedded into a video portion of the media content. In some examples, the metering metadata in the second format to which the extracted metering data is transcoded corresponds to metadata represented in a text format (e.g., a text format for inclusion in an M3U file).

Another exemplary method of monitoring streaming media content disclosed herein includes decoding a transport stream carrying media content streamed to a content presentation device to obtain the media content. The example method also includes extracting metering data from the media content and/or receiving metering data from a separate metering data source, the metering data identifying at least one of the media content or the media content source. Additionally, the exemplary method includes decoding content identification metadata (e.g., electronic guide data, playlist data, etc.) that has been accompanied by the transport stream carrying the media content. The exemplary method also includes verifying the content identification metadata using metering data extracted from the media content.

In some examples, the method further includes reporting results of verifying the content identification metadata using metering data extracted from the media content to the media monitoring device to validate the content identification metadata separately reported by the meter executed by the content presentation device. For example, a meter executed by the content presentation device also detects content identification metadata accompanying a transport stream that provides the streaming media content to the content presentation device. The meter then reports the content identification metadata to the media monitoring device, which confirms the accuracy of the content identification metadata based on the reported results of prior verifications of the content identification metadata using metering data extracted from the media content. As described above, in some examples, the metering data extracted from the media content decoded from the transport stream may include an audio watermark embedded in the audio portion of the media content. Additionally or alternatively, the metering data extracted from the media content decoded from the transport stream may include a video (e.g., image) watermark embedded into a video portion of the media content. Additionally or alternatively, the method may include reporting metering data received from a separate metering data source.

Another exemplary method of monitoring streaming media content disclosed herein includes storing media content (to be streamed to a content presentation device) in a temporary memory prior to streaming the media content to the content presentation device. The exemplary method also includes retrieving the media content from the temporary storage and extracting metering data (e.g., audio/video watermark(s) embedded in the media content) from the media content, the metering data identifying at least one of the media content or a source of the media content. The method also includes combining the extracted metrology data with metrology data from a separate metrology data source. The example method also includes reporting the metering data to a media monitoring device.

Prior techniques for monitoring broadcast media content may include extracting metering data, such as audio and/or video watermarks, from a monitored presentation of the media content. In the context of streaming media content, digital rights management may prevent access to streamed media content through an application (e.g., a device meter, rather than the media content player(s) used by the content presentation device). According to examples described herein, monitoring streaming media content enables a device meter executing by a content presentation device to detect metering metadata identifying streaming media content that is transcoded from a first format that is not decodable by the device meter (e.g., the first format corresponds to an audio watermark or a video watermark embedded in the media content that is not accessible to the device meter due to digital rights management) to a second format that is decodable by the device meter (e.g., the second format corresponds to a text format included in a file sent over a metadata channel accompanying the streaming media content). Additionally or alternatively, monitoring of streaming media content according to examples described herein enables verification of content identification metadata that has already been accompanied with the streaming media content and that can be decoded by a device meter without transcoding by using metering data (e.g., audio and/or video watermarks) extracted from the media content. Although the examples disclosed herein are described in the context of monitoring streaming media content, the example methods and apparatus disclosed herein may also be applied to monitoring non-streaming media content.

Turning to the drawings, FIG. 1 illustrates a block diagram of a first exemplary system 100 for monitoring streaming media content. The example system 100 includes a first example server meter 105, a first example device meter 110, and a first example media monitoring device 115 to monitor media content streamed to an example presentation device 120. In the illustrated example, the system 100 includes an exemplary compression apparatus 130, an exemplary segmenter and packager 135, an exemplary digital rights manager 140, and an exemplary content streamer 145 to provide streaming media content provided by the exemplary content provider(s) 125 to the content presentation device 120. The example system 100 also includes an example network 150 over which the content streamer 145 streams media content to the content presentation device 120, and over which the device meters 110 may report metering data to the media monitoring devices 115.

The content provider(s) 125 of the illustrated example correspond to any of one or more content providers capable of providing media content for streaming to the content presentation device 120. The media content provided by the content provider(s) 125 may be any type of media content, such as audio content, video content, multimedia content, and so forth. Further, the media content may correspond to live (e.g., broadcast) media content, stored media content (e.g., on-demand content), and so forth.

Compression device 130 compresses and/or otherwise processes the received media content into a format suitable for streaming using any suitable technique(s). The compression device 130 also compresses the media content according to MPEG4 audio/video compression, for example. The segmentor & packager 135 uses any suitable technique(s) to segment and package the compressed media content into a format suitable for streaming. For example, the segmentor and packager 135 may segment and package the compressed media content into one or more MPEG2 transport streams for transmission to the content presentation device 120 over the network 150 using HTTP Live Streaming (HLS) or any other past, current, and/or future streaming media protocol. The digital rights manager 140 encrypts and/or otherwise protects media content to be streamed according to any suitable digital rights management technique and/or protocol. The content streamer 145 selects media content using any suitable technique(s) and streams to the requesting device (e.g., content presentation device 120). For example, content streamer 145 may select media content that has been compressed by MPEG4, split and packaged into one or more MPEG2 transport streams, and encrypted for digital rights management, and then stream the content over network 150 to content presentation device 120 using HLS or any other streaming media protocol.

In some examples, the compression apparatus 130, the segmenter and packager 135, and/or the digital rights manager 140 prepare the streamed content regardless of whether (e.g., prior to) the request was received from the content presentation device 120. In this example, the content streamer 145 prepares a transport stream to stream the already prepared content to the content presentation device 120 upon receiving a request from the content presentation device 120. In other examples, the compression apparatus 130, the segmenter and packager 135, and/or the digital rights manager 140 prepare the content to be streamed in response to a request received from the content presentation device 120.

The content presentation device 120 of the illustrated example is a computing device capable of presenting streaming media content provided by a content streamer 145 over a network 150. The content presentation device 120 may be, for example, a desktop computer, a laptop computer, a mobile computing device, a television, a smart phone, a mobile phone, a television, a,Android (TM) driven computing device,A computing device, etc. In some examples, the content presentation device 120 includes one or more executable media players that present streaming media content provided by the content streamer 145. For example, the media player(s) that may be used by the content presentation device 120 may be implemented as(e.g., as provided in SWF files), can be implemented as HyperText markup language (HTML) version 5(HTML5), can be implemented asMay be implemented according to the Open Source Media Framework (OSMF), may be implemented according to a media player Application Program Interface (API) of a device or operating system providerImplementation, can be on the media player architecture of the device or operating system provider (e.g.,mpmovielayer software), etc., or any combination thereof. Although a single content presentation device 120 is shown, any number and/or type(s) of content presentation devices may be included in the system 100.

The network 150 of the illustrated example is the internet. Additionally or alternatively, any other network(s) may be used to connect the content streamer 145, the content presentation device 120, the device meter 110, and/or the media monitoring device 115. Network 150 may include any number of public and/or private networks using any type(s) of network protocol(s).

As described above, the media content provided by the content provider(s) 125 may include metering data, such as embedded audio and/or video watermarks, that identify and/or are otherwise related to the media content. However, such metering data is not accessible to, and therefore cannot be decoded by, the device meter of the content presentation device 120. For example, due to the digital rights management techniques used by the digital rights manager 140, the media content and, by extension, the audio and/or video watermarks embedded therein may only be accessible to the appropriate media player and not to the device meter or other application. To enable the device meter 120 to access and decode metering data identifying and/or relating to streaming media content provided to the content presentation device 120, the system 100 of the illustrated example includes a server meter 105. In some examples, the server meters 105 are implemented as plug-ins or other applications/devices associated with or executed by one or more of the compression apparatus 130, the segmenter and packager 135, the digital rights manager 140, and/or the content streamer 145. In some examples, the server meters 105 are implemented by devices separate from the compression device 130, the segmenter and packager 135, the digital rights manager 140, and the content streamer 145.

In the illustrated example, the server meter 105 obtains metering data in a first format from media content. In some examples, the server meters 105 also collect metering data from one or more independent metering data sources. The metering data obtained from the independent metering data source may be in the first format or any other format(s). The server meter 105 then transcodes the obtained metering data (e.g., the extracted metering data and/or metering data from an independent metering data source) to form metering metadata in a second format that can be accessed and decoded by the device meters 110. The metering data identifies the media content, identifies the source of the media content, and/or is otherwise described and/or associated with the media content. For example, the server meter 105 may obtain an embedded audio/video watermark corresponding to the metering data having the first format, and/or the server meter 105 may obtain the metering data from a separate metering data source. The server meter 105 then transcodes the metering data into text data, binary data, etc. corresponding to the metering data in the second format. The server meter 105 then encodes the transcoded metering metadata, which is in a second format capable of being executed by or associated with the content presentation device 120 and capable of being decoded by device meter 0, into a metadata channel associated with the transport stream(s) that carry the streaming media content to the presentation device 120. In some examples, the server meters 105 are implemented as plug-ins based on Software Development Kits (SDKs) provided by entities embedded in audio/video watermarks in the media content. In such an example, the server meter 105 may use the functionality provided by the SDK to extract and decode the audio/video watermark(s) embedded in the media content to obtain the payload data carried by the watermark(s). In some examples, the server meter 105 then inserts the payload data obtained from the watermark(s) as ID3 tag metadata and/or other metadata into the transport stream(s) that stream the media content according to HLS or other suitable streaming media protocol in accordance with one or more versions of the ID3 tag standard. Another exemplary embodiment of a server meter 105 is shown in FIG. 2 and will be described in greater detail below.

The server meter 105 may also use the functionality provided by the SDK to collect metering data from an independent metering data source (e.g., by receiving data from an internal clock, receiving content identifying information from a user input, receiving content identifying information from a file, or other source independent of the media content provider). An example of implementing a server meter 105 that includes independent metering data sources is described in connection with FIG. 24.

The system 100 also includes a device meter 110 that monitors streaming media content provided to and/or presented by the content presentation device 120. In the illustrated example, the device meter 110 is executed by the content presentation device 120. In some examples, the device meter 110 may be implemented as a plug-in that interfaces with a plug-in of a media player executed by the content presentation device 120. In some examples, the device meter 0 may be implemented as one or more instructions incorporated into a media player executed by the content presentation device 120. In some examples, the device meter 110 is implemented as a download (e.g., as an App slave)AppStore downloads) to an executable application of the content presentation device 120. In some examples, the device meter 110 is implemented by a device that is separate from the content presentation device 120, but has access (e.g., through one or more digital interfaces, data ports, etc. of the content presentation device 120) to metadata related to the streaming media content received by the content presentation device 120.

The device meters 110 of the illustrated example (e.g., provided previously or concurrently and transmitted together) decode metered metadata included in a metadata channel (or channels) associated with the transmission channel(s) providing the streaming media content to the content presentation device 120. For example, the metadata channel decoded by the device meter 110 may correspond to an external metadata channel outside of the transport stream carrying the media content, or to an internal metadata channel comprising one or more data fields of the transport stream carrying the media content. An example of an external metadata channel includes an M3U file or other text file associated with a transport stream that carries streaming media content and includes metering metadata transcoded into text or other suitable data format by the server meters 105. In some examples, for example, using the example of the HLS protocol, the device meter 110 extracts and decodes the ID3 tag(s) that include metering metadata. The device meter 110 of the illustrated example stores the decoded metering metadata (as well as any other metering information acquired by the device meter, timestamps added to the decoded metering metadata by the device meter 110, and/or other metering information, etc.) for reporting to the media monitoring device 115. In the illustrated example, the device meter 110 reports its stored metering metadata (as well as any other metering information, timestamps, etc.) using HTTP requests sent to the HTTP interface of the media monitoring device 115. One exemplary embodiment of a device meter 110 is shown in FIG. 3, which will be described in greater detail below.

The media monitoring device 115 includes an interface to receive reported metering information (e.g., metering metadata) received from the device meters 110 over the network 150. In the illustrated example, the media monitoring device 5 includes an HTTP interface to receive HTTP requests including metering information. Alternatively, any other method(s) may be used to receive the metering information. In the illustrated example, the media monitoring device 115 stores and analyzes metering information received from a plurality of different content presentation devices 120. For example, the media monitoring device 115 may group metering information (e.g., group all metering data related to a particular content provider 125) by the content provider 125. The media monitoring device 115 also analyzes the metering information to eliminate error information. For example, the media monitoring device 115 may compare two types of identifying information received for the same media content (e.g., by comparing content identifying metadata that has been transmitted with the streaming media content to metering data and/or metadata determined by the device meters 110 and/or the server meters 105) to identify differences, may eliminate metering information that includes differences, and/or may mark certain identifying information as erroneous to exclude it from later received metering information. Any other processing of the metering information may additionally or alternatively be performed.

In some examples, the reported metering information includes metering data acquired by a dependent metering data source and an independent metering data source. A secondary source of metering data includes, for example, a source of metering data derived from, related to, or otherwise dependent upon, media content and/or the transport stream(s) providing the media content. For example, the dependent metering data source may include metering data extracted from a watermark payload of the streaming media content. Conversely, an independent source of metering data includes, for example, a source of metering data that is independently obtained from the media content and/or the transport stream(s) providing the media content, but which may still be a description of the media content. For example, the independent metering data source may include redundant metering data, e.g., the same metering data as acquired from the slave metering data source, metering data similar to the metering data acquired from the slave metering data source, etc., but acquired from the independent metering data source (e.g., a source identifier stored in a configuration file of the server meter 105). In this example, the media monitoring device 115 may use the redundant metering data to verify metering data from the slave metering data source. An example of metadata with redundant metering data obtained from independent metering data sources is described with reference to FIG. 26. In some examples, the media monitoring device 115 may store and analyze both redundant metering data and metering data from dependent metering data sources. In some examples, the media monitoring device 115 may store and/or analyze redundant metering data when metering data from a slave metering data source cannot be read by the media monitoring device 115. For example, when the server meter 105 is unable to extract an audio/video watermark from the streaming media content (e.g., in a silent portion of the streaming media content, the audio watermark may be unusable), metering data from the dependent metering data source may be unable to be error detected, may be blank, or may be invalid. An example of metadata with unreadable metering data from a dependent metering data source is described with reference to fig. 27.

The media monitoring device 115 of the illustrated example also analyzes received metering information reported by the content presentation device(s) 120 to generate reports regarding media content presentation. For example, the media monitoring device 115 may generate reports indicating the number of times the media content was accessed, the number of users accessing the media content, the user's interactions with the media content (e.g., fast forward, pause, etc.), the duration of access of the media content, and so forth. The media monitoring device 115 may, for example, provide a web interface through which a person of interest can generate customized reports or otherwise access metering information (e.g., for a fee or part of a subscription service). For example, the media monitoring device 115 may generate reports for particular content providers 125, for advertisers who distribute advertisements through the content provider(s) 125, for competitors of the content provider(s) 125, and so forth. An exemplary embodiment of the media monitoring device 115 is shown in FIG. 4, which is described in more detail below.

A block diagram of an exemplary embodiment of the exemplary server meter 105 of FIG. 1 is shown in FIG. 2. The example server meter 105 of fig. 2 includes an example transport stream decoder 205 to decode the transport stream(s) carrying the streaming media content to obtain the media content being streamed to the content presentation device 120. For example, the transport stream decoder 205 can decode MPEG2 transport 2, which encapsulates MPEG4 compressed media content, to obtain encapsulated MPEG4 content, and then perform MPEG4 decompression to obtain uncompressed audio/video content.

The example server meter 105 of fig. 2 also includes an example metering data extractor 210 to extract metering data having a first format from the uncompressed media content obtained by the transport stream decoder 205. For example, the media content extractor 210 may implement functionality provided by the SDK to extract one or more audio watermarks, one or more video (e.g., image) watermarks, etc., embedded in uncompressed audio/video content obtained from the transport stream decoder 205. (e.g., uncompressed audio/video content may correspond to uncompressed Pulse Code Modulation (PCM) audio data or other types of audio data, uncompressed video/image data, etc.). To transcode the metering data in the first format obtained from the metering data extractor 210 into a second format that may be decoded by the device meters 110, the example server meters 105 of fig. 2 also include an example metering data transcoder 215. For example, metering data transcoder 215 may determine (e.g., decode) metering information (e.g., watermark payload data, e.g., content identification information, source identification information, etc.) carried by the watermark extracted by metering data extractor 210 and convert the metering information (also referred to as watermark payload information) into a textual or binary format for inclusion in an M3U8 file or other data file data (e.g., textual, binary, etc.) file for transmission as metadata (e.g., with a playlist or electronic program guide) accompanying the streaming media content. Additionally or alternatively, metering data transcoder 215 may convert the extracted metering information (i.e., watermark payload data) into a binary or other suitable format so as to be capable of being included in one or more data fields capable of carrying metadata in the transport stream(s) that provide the streaming media content to content presentation device 120. For example, the metering data transcoder 215 may convert watermark payload data corresponding to the metering information into ID3 tag metadata for insertion into the transport stream(s) that stream the media content according to HLS or other suitable streaming media protocols. Other additional or alternative examples of TRANSCODING that may be used by the metering data transcoder 215 TO transcode the metering data into a format that may be decoded by the device meter 110 are described in, FOR example, U.S. patent No. 7,827,312 (ramanswamy et al, "METHODS AND APPARATUS FOR transporting METADATA") published on day 2, 2010 AND U.S. provisional application No. 61/442,758 (Deliyannis et al, "METHODS AND APPARATUS TO monitor contact AT a CONTENT DISPLAY SITE") filed on day 14, 2, 2011. U.S. patent No. 7,827,312 and U.S. provisional application No. 61/442,758 are hereby incorporated by reference in their entirety. In certain examples, the metering data extractor 210 may be replaced by or included in one or more of the components of fig. 24 to enable the server meter 505 to operate in accordance with the system described in connection with fig. 23.

Further, in some examples, the server meters 105 in fig. 2 include an example metering metadata encryptor 220 that encrypts the metering metadata determined by the metering data transcoder 215 using any suitable encryption scheme. For example, the metering metadata encryptor 220 can encrypt the metering metadata using a public key or a private key such that the decryption key(s) are known and protected by the media monitoring device 115. The inclusion of the metering metadata encryptor 220 can prevent unauthorized eavesdroppers from accessing transcoded metering metadata that identifies or is otherwise associated with streaming media content and thus protects the privacy of users using streaming media content.

In the example illustrated in fig. 2, the server meter 105 includes an example transport stream encoder 225 for re-encoding the transport stream(s) carrying the streaming media content to include the metering metadata determined by the metering data transcoder 215 (and encrypted by the metering metadata encryptor 220 as appropriate). For example, transport stream encoder 225 may encode the metering metadata into an external metadata channel, e.g., by encoding M3U8 or other data file to include the metering metadata and to relate to the transport stream(s) that provide the streaming media content to content presentation device 120 (e.g., included in the transport stream(s) that provide the streaming media content to content presentation device 120, added to the transport stream(s) that provide the streaming media content to content presentation device 120, transmitted prior to providing the streaming media content to content presentation device 120, etc.). Additionally or alternatively, the transport stream encoder 225 may encode metering metadata into an internal metadata channel, for example, by encoding metering metadata in a binary or other suitable data format into one or more data fields of the transport stream(s) capable of carrying the metadata. For example, the transport stream encoder 225 may insert ID3 tag metadata corresponding to the metering metadata into the transport stream(s) that stream the media content according to HLS or other suitable streaming media protocol.

A block diagram of an exemplary implementation of the exemplary device meter 110 of FIG. 1 is shown in FIG. 3. The example device meter 110 of fig. 3 includes an example metering metadata extractor 305 to extract metering metadata from an external and/or internal metadata channel associated with the transport stream(s) that provide the streaming media content to the content presentation device 120. For example, metering metadata extractor 305 may extract metering metadata from an external metadata channel (or more than one external metadata channel), e.g., by decoding a data file that includes M3U8 or other data file that includes metering metadata and that is related to (e.g., included in, added to, transmitted prior to, etc.) the transport stream(s) that provided the streaming media content to content presentation device 120 that provides the streaming media content to content presentation device 120 to the transport stream(s) that provided the streaming media content to content presentation device 120. Additionally or alternatively, the metric metadata extractor 305 may extract the metric metadata from the internal metadata channel (or more than one internal metadata channel), e.g., by decoding the metric metadata from one or more data fields of the transport stream(s) capable of carrying the metadata. In some examples, for example, using the example of the HLS protocol, the metric metadata extractor 305 extracts and decodes the ID3 tag(s) that comprise the metric metadata.

The example device meter 110 of FIG. 3 also includes an example metering metadata reporter 310 to report the metering metadata obtained by the metering metadata extractor 305 to the media monitoring device 115. For example, metering metadata reporter 310 may generate a GET or POST request that includes metering metadata as a request parameter. Alternatively, any other method of transmitting metering metadata to the media monitoring device 115 may be used. The metering metadata may be transmitted at arbitrary intervals. For example, metering metadata may be transmitted as it is collected (e.g., streamed), may be transmitted when a certain amount of metering metadata is collected, when available storage space is filled or reaches a certain threshold capacity (e.g., 90% or some other percentage of full), when a particular event is detected (e.g., when presentation of media content ends, when new media content is presented, etc.), whenever new metering metadata is obtained, and so forth. The metadata reporter 310 may transmit metering metadata once per media content (e.g., each time an event occurs, each time the identification information changes) or may transmit metering metadata multiple times (e.g., when the media content includes metering data that is changing throughout the media content, etc.).

In some examples, the device meters 110 may determine metering information other than metering metadata extracted from the metering metadata extractor 305. For example, the device meters 110 may collect other metadata (e.g., other content identification metadata) that has been accompanied by the transport stream(s) that provide the streaming media content. Additionally or alternatively, in some examples, the device meter 110 may collect information describing usage of a media player presenting the media content while the media content is being presented, other usage of the content presentation device 120, or the like, or combinations thereof. In such examples, metering metadata reporter 310 may use one or more of the above-described example mechanisms to report this additional metering information to media monitoring device 115, either together with or independently of the metering metadata extracted by metering metadata extractor 305.

FIG. 4 illustrates a block diagram of an exemplary implementation of the exemplary media monitoring device 115 of FIG. 1. The example media monitoring device 115 of FIG. 2 includes an example metering metadata collector 405 to collect metering metadata (and other metering information) reported by the device meters 110. As described above, the metering metadata collector 405 of the illustrated example includes an HTTP interface to receive HTTP requests including metering information. Additionally or alternatively, any other method(s) of receiving metering information may be used. The metering metadata collector 405 also stores (e.g., collects) and analyzes the received metering information as described above with reference to fig. 1. As described above with reference to fig. 1, the example media monitoring device 115 of fig. 2 also includes an example report generator 410 to generate a report based on the reported metering information.

A block diagram of a second exemplary system 500 for monitoring streaming media content is shown in fig. 5. This second exemplary system 500 includes many of the same components as the first exemplary system 100 of fig. 1. As such, like elements in FIGS. 1 and 5 are labeled with the same reference numerals. For simplicity and clarity, a detailed description of these similar elements discussed above with reference to FIG. 1 is not repeated in the discussion of FIG. 5.

Turning to fig. 5, an exemplary system 500 is shown that includes a compression apparatus 130, a segmenter and packager 135, a digital rights manager 140, and a content streamer 145 to provide streaming media content to a content presentation device 120 over a network 150. To provide media content to the system 500, the example shown in fig. 5 includes the content provider(s) 125. To monitor media content streamed to the content presentation device 120, the illustrated example of the system 500 also includes a second example server meter 505, a second example device meter 510, and a second example media monitoring device 515. In some examples, the server meter 505 may be implemented as a plug-in or other application/device associated with or executed by one or more of the compression apparatus 130, the segmenter and packager 135, the digital rights manager 140, and/or the content streamer 145. In some examples, the server meter 505 may be implemented by a device separate from the compression device 130, the segmenter and packager 135, the digital rights manager 140, and the content streamer 145. In some examples, the device meters 510 may be implemented as plug-ins that connect to a plug-in interface of a media player executed by the content presentation device 120. In some examples, a device meter510 may be implemented as one or more instructions provided that are incorporated into a media player executed by the content presentation device 120. In some examples, the device meter 510 may be implemented as an executable application that is downloaded into the content presentation device 120 (e.g., from a web server)App Store downloaded App). In some examples, the device meter 510 is implemented by a device that is separate from the content presentation device 120, but that is capable of accessing (e.g., through one or more digital interfaces, data ports, etc. of the content presentation device 120) metadata related to the streaming media content received by the content presentation device 120.

The server meter 505 of the illustrated example decodes the transport stream(s) carrying the media content to be streamed to the content presentation device 120 and extracts metering data from the decoded media content. The metering data identifies the media content, identifies the source of the media content, and/or otherwise describes and/or correlates with the media content. For example, the server meter 505 may extract an audio watermark and/or a video watermark embedded in the media content. Further, the server meter 505 decodes the content identification metadata (e.g., electronic navigation data, playlists, etc.) that has been accompanied with the transport stream(s) carrying the media content to be streamed to the content presentation device 120. In some examples, the server meter 505 uses metering data extracted from the media content to verify content identification metadata that has been accompanied with the transport stream(s) carrying the media content. E.g., electronic navigation data, playlist data, etc., may be erroneous or outdated. Using metering data extracted from the media content to verify the content identification metadata enables the media monitoring device 515 to know whether the content identification metadata that has been accompanied with the transport stream(s) carrying the media content is accurate and, therefore, for media monitoring purposes. An exemplary embodiment of a server meter 505 is shown in FIG. 6 and described in more detail below.

The system 500 includes a device meter 510 to monitor the streaming media content presented by the content presentation device 120. The device meter 510 of the illustrated example decodes content identification metadata (e.g., electronic navigation data, playlist data, etc.) that has been accompanied by a transport stream(s) carrying media content that is streamed to the content presentation device 120. The device meter 510 stores content identification metadata (as well as any other metering information obtained by the device meter) for reporting to the media monitoring device 515. In the illustrated example, the device meter 510 reports its stored content identification metadata (as well as any other metering information) using HTTP requests sent to the HTTP interface of the media monitoring device 515. An exemplary embodiment of a device meter 510 is shown in FIG. 7 and will be described in greater detail below.

The media monitoring device 515 includes an interface to receive content identification metadata received from the device meter 510 over the network 150. The media monitoring device 515 also includes an interface to receive verification results from the server meter 505 indicating whether the metering metadata reported by the device meter 510 is valid (e.g., whether the content identification metadata is accurate). Assuming the content identification metadata is valid, the media monitoring device 515 may process the reported metering metadata based on the reported metering metadata using techniques similar to those used by the media monitoring device 115 to store, analyze, and generate reports. An exemplary embodiment of the media monitoring device 515 is shown in FIG. 8, which is described in more detail below.

A block diagram of an exemplary embodiment of the exemplary server meter 505 of FIG. 5 is shown in FIG. 6. Similar to the example server meter 105 of FIG. 2, the example server meter 505 of FIG. 6 includes a transport stream decoder 205 to decode the transport stream(s) carrying the streaming media content to obtain the media content to be streamed to the content presentation device 120. Similar to the example server meter 105 of fig. 2, the example server meter 505 of fig. 6 also includes a metering data extractor 210 to extract metering data, e.g., one or more audio watermarks, one or more video (e.g., image) watermarks, etc., embedded in the media content obtained from the transport stream decoder 205. Moreover, a description of these elements has been given above in the description with reference to fig. 2, and for the sake of brevity is not repeated in the discussion of fig. 6.

The example server meter 505 of fig. 5 also includes an example content metadata extractor 605 to extract content identification metadata (and/or other content description information) that has been accompanied with the transport stream(s) carrying the streaming media content. For example, content metadata extractor 605 can extract content identification metadata from a playlist, electronic program guide, data file, or the like that has been accompanied (e.g., has been included in, appended to, sent prior to, etc.) the transport stream(s) that are to provide the streaming media content to content presentation device 120. The example server meter 505 of fig. 5 also includes an example metadata verifier 610 to compare the content identification metadata obtained by the content metadata extractor 605 with the metering data obtained from the metering data extractor 210 to determine whether the content identification metadata is valid (e.g., correct, accurate, up-to-date, etc.). The metadata verifier 610 also reports verification results to the media monitoring device 515 (e.g., using one or more HTTP requests) over the network 150.

A block diagram of an exemplary implementation of the exemplary device meter 510 of FIG. 5 is shown in FIG. 7. The example device meter 510 of fig. 7 includes an example content metadata extractor 705 to extract content identification metadata (and/or other content description information) that has been accompanied with the transport stream(s) that provide the streaming media content to the content presentation device 130. For example, similar to content metadata extractor 605 of fig. 6, content metadata extractor 705 may be capable of extracting from a playlist, electronic program guide, data file, or the like, content identification metadata that has been accompanied (e.g., included in, appended to, sent prior to, etc.) the transport stream(s) that provided the streaming media content to content presentation device 120.

The example device meter 510 of FIG. 7 also includes an example content metadata reporter 710 to report content identification metadata obtained by the content metadata extractor 705 to the media monitoring device 515. For example, the content metadata reporter 710 may generate a GET or POST request that includes content identification metadata as a request parameter. Alternatively, any other method of transmitting the content identification metadata to the media monitoring device 515 may be used. The content identification metadata may be transmitted at arbitrary intervals. For example, content identification metadata may be transmitted (e.g., streamed) as it is collected, may be transmitted as a certain amount of content identification metadata is collected, may be transmitted when available storage space is filled or reaches a threshold capacity (e.g., 90% or other percentage of full), may be transmitted when a particular event is detected (e.g., when a media content presentation ends, when new media content is presented, etc.), may be transmitted whenever new content identification metadata is obtained, etc. The content metadata reporter 710 may transmit the content identification metadata once per media content or may transmit the content identification metadata multiple times (e.g., each time an event occurs, each time the identification information changes, etc.).

In some examples, the device meter 510 may determine metering information other than the content identification metadata extracted by the content metadata extractor 705. For example, the device meters 510 may collect information describing usage of a media player on which the media content is presented, other usage of the content presentation device 120 while the media content is presented, and the like, or any combination thereof. In such examples, the content metadata reporter 710 may use one or more of the above-described exemplary mechanisms to report this additional metering information to the media content device 515, either together with or independently of the content identifying metadata extracted by the content metadata extractor 705.

FIG. 8 illustrates a block diagram of an exemplary embodiment of the exemplary media monitoring device 515 of FIG. 5. The example monitoring device 515 of FIG. 8 includes an example content metadata collector 805 to collect metering metadata (and other metering information) reported by the device meters 510. As described above, the content metadata collector 805 of the illustrated example includes an HTTP interface to receive HTTP requests containing metering information. Additionally or alternatively, any other method(s) of receiving metering information may be used. As described above with reference to fig. 5, the content metadata collector 805 also stores (e.g., collects) and analyzes the received metering information (e.g., based on the verification results received from the content metadata verifier 810).

The example media monitoring device 515 of fig. 8 also includes an example content metadata verifier 810 to receive verification results related to the validity of the content identification information received by the content metadata collector 805. For example, the content metadata verifier 810 includes an HTTP interface to receive HTTP requests containing verification results reported by the server meter 505. The content metadata collector 805 may use the verification results received by the content metadata verifier 810 to determine whether the content identification metadata is valid (e.g., correct, accurate, up-to-date, etc.). As described above with reference to fig. 5, the example media monitoring device 515 of fig. 8 also includes the example report generator 815 to generate a report based on the reported metering information.

Fig. 9 illustrates a block diagram of a third exemplary system 900 for monitoring streaming media content. This third exemplary system 900 includes the same elements as the first exemplary system 100 of fig. 1. Thus, like elements in fig. 1 and 9 are labeled with the same reference numerals. These similar elements have already been described in detail with reference to fig. 1 and, for the sake of brevity, are not repeated in the discussion of fig. 9.

Turning to fig. 9, an exemplary system 900 is shown that includes a compression apparatus 130, a segmenter and packager 135, a digital rights manager 140, and a content streamer 145 to provide streaming media content to a content presentation device 120 over a network 150. To provide media content to the system 900, the example shown in fig. 9 includes the content provider(s) 125. To monitor media content streamed to the content presentation device 120, the illustrated example of the system 900 further includes a third example server meter 905 and a third example media monitoring device 915. In some examples, server meters 905 may be implemented as plug-ins or other applications/devices associated with or executed by one or more of compression apparatus 130, segmenter and packager 135, digital rights manager 140, and/or content streamer 145. In some examples, the server meter 905 may be implemented by a device separate from the compression device 130, the segmenter and packager 135, the digital rights manager 140, and the content streamer 145.

In the system 900 of the illustrated example, a copy of the media content streamed to the content presentation device 120 is stored in the temporary content storage 920 for subsequent processing. The temporary content storage 920 may be implemented by any memory or storage device, such as one or more of the mass storage device 3130 and/or the volatile memory 3118 shown in fig. 31, which will be described in more detail below. The media content may be stored in temporary content storage 920 in any suitable data format.

The server meter 905 of the illustrated example extracts metering data from the media content stored in the temporary memory 920. The metering data identifies the media content, identifies the source of the media content, and/or otherwise describes and/or is related to the media content. For example, the server meter 905 may extract audio and/or video watermarks embedded in the media content. In the illustrated example, the server meter 905 reports the extracted metering data (as well as any other metering information) using HTTP requests sent to the HTTP interface of the media monitoring device 915. An exemplary embodiment of a server meter 905 is shown in FIG. 10 and will be described in more detail below.

The media monitoring device 915 includes an interface to receive reported metering metadata received from the device meter 905 over the network 150. The media monitoring device 515 may process the reported metering metadata based on the reported metering metadata using techniques similar to those used in the media monitoring device 115 to store, analyze, and generate reports. An exemplary embodiment of a media monitoring device 915 is shown in FIG. 11, which is described in more detail below.

A block diagram of an example embodiment of the example server meter 905 of FIG. 9 is shown in FIG. 10. The example server meter 905 of FIG. 10 includes a media content retriever 1005 to retrieve a copy of media content to be streamed to the content presentation device 120 from the temporary content store 920. Similar to the example server meter 105 of fig. 2, the example server meter 905 of fig. 10 also includes a metering data extractor 210 to extract metering data, e.g., one or more audio watermarks, one or more video (e.g., image) watermarks, etc., embedded in the media content obtained from the media content restorer 1005. Further, the description of the metering data extractor 210 has been given above in the description with reference to fig. 2, and, for the sake of brevity, is not repeated in the discussion of fig. 6. In certain examples, the metering data extractor 210 is replaced by or included with one or more units of fig. 24, such that the server meter 905 is capable of operating in accordance with the system described with reference to fig. 23.

The example server meter 905 of FIG. 10 also includes an example metering data reporter 1010 to report metering data obtained by the metering data extractor 210 to the media monitoring device 915. For example, the metering data reporter 1010 may generate a GET or POST that includes metering data as a request parameter. Alternatively, any other method of transmitting metering data to the media monitoring device 915 may be used. The metering data may be transmitted at arbitrary intervals. For example, metering metadata may be transmitted as it is collected (e.g., streamed), may be transmitted when a certain amount of metering metadata is collected, when available storage space is filled or reaches a certain threshold capacity (e.g., 90% or some other percentage of full), when a particular event is detected (e.g., when presentation of media content ends, when new media content is presented, etc.), whenever new metering metadata is obtained, and so forth. The metering data reporter 1010 may transmit metering data once per media content or may transmit metering data multiple times (e.g., each time an event occurs, each time identification information changes, etc.).

FIG. 11 illustrates a block diagram of an exemplary embodiment of the exemplary media monitoring device 915 of FIG. 9. The example monitoring device 915 of FIG. 9 includes an example metering data collector 1105 to collect metering data reported by the server meter 905. As described above, the metering data collector 1105 of the illustrated example includes an HTTP interface to receive HTTP requests containing metering information. Additionally or alternatively, any other method(s) of receiving metering information may be used. As described above with reference to fig. 9, the metering data collector 1105 also stores (e.g., collects) and analyzes the received metering information. As described above with reference to FIG. 9, the example media monitoring device 915 shown in FIG. 11 also includes the example report generator 1110 to generate a report based on the reported metering information.

While exemplary manners of implementing the server meters 105, 505, and 905, the device meters 110 and 510, and the media monitoring devices 115, 515, and 915 of fig. 1, 5, and 9 have been illustrated in fig. 2-4, 6-8, and 10-11, one or more of the components, processes, and/or devices illustrated in fig. 2-4, 6-8, and 10-11 may be combined, divided, rearranged, omitted, eliminated, and/or implemented in any other manner. Furthermore, the example transport stream decoder 205, metering data extractor 210, example metering data transcoder 215, example metering metadata encryptor 220, example transport stream encoder 225, example metering metadata extractor 305, example metering metadata reporter 310, example metering metadata collector 405, example report generator 410, example content metadata extractor 605, example metadata verifier 610, example content metadata extractor 705, example content metadata reporter 710, example content metadata collector 805, example content metadata verifier 810, example report generator 815, example media content receiver 1005, 805, and/or any combination of hardware, software, firmware, and/or any combination of hardware, software, and/or firmware, Example metering data reporter 1010, example metering data collector 1105, example report generator 1110, and/or, more particularly, one or more example server meters 105, 505, and/or 905, one or more example device meters 110 and/or 510, and/or one or more example media monitoring devices 5, 515, and/or 915. Thus, for example, the example transport stream decoder 205, the metering data extractor 210, the example metering data transcoder 215, the example metering metadata encryptor 220, the example transport stream encoder 225, the example metering metadata extractor 305, the example metering metadata reporter 310, the example metering metadata collector 405, the example report generator 410, the example content metadata extractor 605, the example metadata verifier 610, the example content metadata extractor 705, the example content metadata reporter 710, the example content metadata collector 805, the example content metadata verifier 810, the example report generator 815, the example metadata verifier 610, and/or the like may be implemented by one or more of a circuit, a programmable processor, an Application Specific Integrated Circuit (ASIC), a Programmable Logic Device (PLD), and/or a Field Programmable Logic Device (FPLD), among others, The example media content retriever 1005, the example metering data reporter 1010, the example metering data collector 1005, the example report generator 1110, and/or, more particularly, any of the one or more example server meters 105, 505, and/or 905, the one or more example device meters 110 and/or 510, and/or the one or more example media monitoring devices 115, 515, and/or 915. While the apparatus or system claims of this patent are understood to cover only software and/or firmware implementations, the example server meters 105, 505, and/or 905, the example device meters 110 and/or 510, the example media monitoring devices 115, 515, and/or 915, the example transport stream decoder 205, the metering data extractor 210, the example metering data transcoder 215, the example metering metadata encryptor 220, the example metering transport stream media encoder 225, the example metering metadata extractor 305, the example metering metadata reporter 310, the example metering metadata collector 405, the example report generator 410, the example content metadata extractor 605, the example metadata verifier 610, the example content metadata extractor 705, the example content metadata reporter 710, the example content metadata collector 805, the example content metadata collector 805, and/or the example media data encryptor, At least one of the example content metadata verifier 810, the example report generator 815, the example media content restorer 1005, the example metering data reporter 1010, the example metering data collector 1105, and/or the example report generator 1110 is thus specifically defined to include a tangible computer-readable medium, e.g., memory, Digital Versatile Disk (DVD), Compact Disk (CD), etc., that stores such software and/or firmware. Further, the example server meters 105, 505, and/or 905, the example device meters 110 and/or 510, and the example media monitoring devices 115, 515, and/or 915 of fig. 2-4, 6-8, and 10-11 may include more than one of all or any of the illustrated units, processes, and devices in addition to, or in place of, the one or more units, processes, and/or devices illustrated in fig. 2-4, 6-8, and 10-11.

A block diagram of a fourth exemplary system 1200 for monitoring streaming media content is shown in fig. 12. The fourth exemplary system 1200 includes many of the same elements as the first exemplary system 100 of fig. 1. Thus, like elements in FIGS. 1 and 12 are labeled with the same reference numerals. These similar elements are described in detail above with reference to fig. 1 and, for the sake of brevity, are not repeated in the description of fig. 12.

Turning to fig. 12, the system 1200 includes the content provider(s) 125 and an exemplary content delivery network 1215 to provide streaming media content to the content presentation device 120 over the network 150. In the illustrated example, the content provider(s) 125 include an exemplary television source 1205, which may correspond to any broadcast and/or video-on-demand source such as, for example, any terrestrial, cable, satellite, internet protocol, etc. The content provider(s) 125 of the illustrated example also include an exemplary integrated receiver/decoder (IRD)1210 to receive and decode television signals provided by a television source 1205 to obtain, for example, a television transport stream capable of being processed by a content transport network 1215. Any type of IRD1210 may be used in exemplary system 1200. In the illustrated example, the content delivery network 1215 may include, for example, the compression device 130, the segmenter and packager 135, the digital rights manager 140, and the content streamer 145 described above.

To enable monitoring of media content streamed to the content presentation device 120, the illustrated example system 1200 includes, in addition to the device meter 110 and the media monitoring device 115 previously described, an example metadata inserter 1220 and one or more example transcoders 1225 and/or 1230. Metadata inserter 1220 may be implemented, for example, as a stand-alone device, or as a plug-in or other application/device associated with or executed by IRDs 210. The transcoders 1225 and/or 1230 may be implemented, for example, as separate devices or plug-ins or other applications/devices associated with or executed by one or more components of the content delivery network 1215 (e.g., one or more of the compression apparatus 130, the splitter and packager 135, the digital rights manager 140, and/or the content streamer 145). In some examples, metadata inserter 1220 and one or more transcoders 1225 and/or 1230 are integrated into a separate device or plug-in, while in other examples, metadata inserter 1220 is independent of transcoders 1225 and 1230.

In the illustrated example, the metadata inserter 1220 is coupled to an interface (e.g., a Serial Digital Interface (SDI) or an Internet Protocol (IP) interface) of the IRD1210 and decodes a television transport stream provided by the IRD 1210. The metadata inserter 1220 then extracts and decodes the audio watermark(s) from the audio portion(s) of the television transport stream to obtain audio watermark payload data, which in the illustrated example provides metering information. Additionally or alternatively, in certain examples, the metadata inserter 1220 extracts and decodes video (e.g., image) watermark(s) from the video portion(s) of the television transport stream to obtain video watermark payload data corresponding to the metering information. In some examples, metadata inserter 1220 additionally or alternatively obtains metering data from a separate metering data source, such as the one described with reference to fig. 23 and 24. The metadata inserter 1220 then inserts the watermark payload data corresponding to the metering information into one or more existing portions of the television transport stream capable of carrying the metadata. For example, the metadata inserter 1220 inserts watermark payload data corresponding to metering information (and/or metering data obtained from an independent source) as Vertical Blanking Interval (VBI) data in accordance with the cable telecommunications engineers (SCTE) american national standard ANSI/SCTE127, or as Advanced Television Systems Committee (ATSC) proprietary information descriptors of one or more transport streams, or the like. In some examples, the operation of metadata inserter 1220 causes little to no change in the program clock reference and/or audio/video timing of the television transport stream.

In the example shown, system 1200 includes one or more of a transcoder 1225 or a transcoder 1230. Transcoders 1225 and 1230 are each capable of adding the metering metadata inserted by metadata inserter 1220 to the television transport stream and converting the metadata to a format that matches transmission streamed over content delivery network 1215. Each of transcoders 1225 and 1230 then inserts this reformatted metadata into the particular portion(s) of the transport stream(s) capable of carrying the metadata for the streaming content. For example, transcoder 1225/1230 can decode metering metadata inserted as VBI payload data or as ATSC private information descriptor(s) and convert the metering metadata into ID3 tag metadata for insertion into transport stream(s) that stream media content according to HLS or other suitable streaming media protocol. In some examples, transcoder 1225/1230 encrypts transcoded metering metadata (e.g., to protect privacy) prior to insertion into the transport stream(s) that stream the media content. Such encryption can prevent metering metadata from being visible to applications at the content presentation device 120 other than the device meter 110. Additionally or alternatively, such encryption may be used to prevent the device meter 110 from extracting and/or decoding metering metadata unless the device meter 110 has been permitted (e.g., enabled) by the media monitoring device 115.

In the example shown, the differences between transcoder 1225 and transcoder 1230 relate to location and integration into system 1200. For example, transcoder 1225 performs its transcoding functions for input to content transport network 1215, and thus may be implemented as a device separate from CDN1215 and/or integrated with or separate from metadata inserter 1220. Conversely, transcoder 1230 operates on transport stream(s) within CDN1215 (e.g., similar to server meter 105), and thus may be implemented as a plug-in and/or an application/device associated with or executed by one or more components included in CDN 1215.

A potential advantage of exemplary system 1200 is that different vendors may provide metadata inserter 1220 and transcoder 1225/1230 with interfaces defined by established industry standards (e.g., established SCTE or ATSC standards).

Although an exemplary manner of embodiment of the system 1200 has been illustrated in fig. 12, one or more of the units, processes and/or devices illustrated in fig. 12 may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the example television source 1205, the example IRD1210, the example content delivery network 1215, the example metadata inserter 1220, the example transcoder 1225 and/or 1230, and/or more specifically the example system 1200 of fig. 12, may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, the example television source 1205, the example IRD1210, the example content delivery network 1215, the example metadata inserter 1220, the example transcoders 1225 and/or 1230, and/or more specifically the example system 1200 may be implemented by one or more of circuitry, a programmable processor, an ASIC, a PLD and/or FPLD, among others. While any apparatus or system claims of this patent are understood to cover only software and/or firmware embodiments, at least one of the example system 1200, the example television source 1205, the example IRD1210, the example content delivery network 1215, the example metadata inserter 1220 and/or the example transcoders 1225 and/or 1230 are thus specifically defined to include a tangible computer-readable medium, e.g., memory, DVD, CD, etc., to store such software and/or firmware. Still further, the example system 1200 of fig. 12 may include one or more of the components, processes and/or devices illustrated in addition to or in place of those illustrated in fig. 12, and/or may include more than one of any or all of the illustrated components, processes and devices.

13-22, 25, 20, and/or 30 illustrate flows representative of example machine readable instructions that may be executed to implement example systems 100, 500, 900, 1200, 2300, and/or 2800, example server meters 105, 505, and/or 905, example device meters 110 and/or 510, example media monitoring devices 115, 515, 915, and/or 2815, example transport stream decoders 205, metering data extractors 210, example metering data transcoders 215, example metering metadata encryptors 220, example transport stream encoders 225, example metering metadata extractors 305, example metering metadata reporters 310, example metering metadata collectors 405, example report generators 410, example content metadata extractors 605, example metadata verifiers 610, example content metadata extractors 705, data streams, An example content metadata reporter 710, an example content metadata collector 805, an example content metadata verifier 810, an example report generator 815, an example media content restorer 1005, an example metering data reporter 1010, an example metering data collector 1105, an example report generator 1110, an example metadata inserter 1220, an example transcoder 1225 and/or 1230, an example independent metering data source 2320, an example combiner 2330, an example clock 2410, example data source(s) 2420, and/or a secondary content presenter 2825. In these examples, the machine readable instructions represented by each flow may include one or more programs for execution by a processor, such as the processor 3112 in the exemplary processing system 3100 described below with reference to fig. 31. Alternatively, a complete program or programs and/or portions of programs implementing one or more of the processes represented by the flows of fig. 13-22, 25, 29, and/or 30 may be executed by a device other than the processor 3112 (e.g., a controller and/or any other suitable device) and/or embedded in firmware or dedicated hardware (e.g., ASICs, PLDs, FPLDs, discrete logic circuitry, etc.). Likewise, one or more of the machine readable instructions represented by the flows of fig. 13-22, 25, 29, and/or 30 may be implemented manually. Further, although the example machine readable instructions are described with reference to the flowcharts illustrated in fig. 13-22, 25, 29, and/or 30, many other techniques for implementing the example methods and apparatus described again may be used. For example, by referring to fig. 13-22, 25, 29, and/or 30, the order of modules performed may be changed, and/or some of the modules described may be changed, eliminated, combined, and/or split into multiple modules.

As described above, the example processes of fig. 13-22, 25, 29, and/or 30 are implemented using code instructions (e.g., computer readable instructions) stored on a tangible computer readable medium, such as a hard disk drive, a flash memory, a Read Only Memory (ROM), a CD, a DVD, a cache, a Random Access Memory (RAM), and/or any other storage medium in which information is stored for any time (e.g., for extended periods of time, permanently, brief instances of time, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable medium is defined specifically to include any type of computer readable memory and to exclude propagating signals. Additionally or alternatively, the example processes of fig. 13-22, 25, 29, and/or 30 are implemented using code instructions (e.g., computer readable instructions) stored on a non-transitory computer readable medium, such as a flash memory, a ROM, a CD, a DVD, a cache, a Random Access Memory (RAM), and/or any other storage medium in which information is stored for any time (e.g., for extended periods of time, permanently, brief instances of time, for temporarily buffering, and/or for caching of the information). The term non-transitory computer readable medium, as used herein, is defined specifically to include any type of computer readable memory and to exclude propagating signals. Also, as used herein, the terms "computer-readable" and "machine-readable" are considered to be the same unless specifically stated otherwise. Also, as used herein, the phrase "at least," when used as a transitional term in the preamble of a claim, is open-ended, as is the phrase "comprising," which is open-ended. Thus, the claims using "at least" as their preamble transitional term are intended to cover elements other than those specifically recited in the claims.

The example machine readable instructions 1300 may be executed to implement the first example server meter 105 of fig. 1-2 shown in fig. 13. Referring to the previous figures, the example machine readable instructions 1300 of FIG. 13 begin execution at block 1305, where the server meter 105 receives a transport stream carrying media content to be streamed to the content presentation device 120. At block 1310, the transport stream decoder 205 of the server meter 105 decodes the transport stream to obtain media content (e.g., uncompressed) for streaming to the content presentation device 120. At block 1315, the metering data extractor 210 of the server meter 105 extracts metering data having a first format (e.g., one or more embedded audio/video watermarks) from the decoded (e.g., uncompressed) media content obtained at block 1310. At block 1320, the metering data transcoder 215 of the server meter 105 transcodes the metering data in the first format obtained at block 1315 to form metering metadata in a second format (e.g., text, binary, or other data format) that can be decoded by the device meters 110. At block 1325, the transport stream encoder 225 of the server meter 105 re-encodes the transport stream to be loaded with the streaming media content to include the metering metadata in a metadata channel associated with the transport stream. At block 1330, the server meter 105 sends the re-encoded transport stream (and the metadata channel carrying the transcoded metering metadata) to any other downstream processing component for streaming to the content presentation device 120. Execution of the example machine readable instructions 1300 is then terminated.

As will be described below with reference to fig. 25, in some examples, module 1315 may be modified and/or replaced with one or more modules to use metering data from an independent metering data source.

Illustrated in fig. 14 are example machine readable instructions 1400 that may be executed to implement the first example device meter 110 of fig. 1 and 3. Referring to the previous figures, the example computer readable instructions 1400 of fig. 14 begin execution at block 1405, where the metering metadata extractor 305 of the device meter 110 detects metering metadata included in a metadata channel accompanying a transport stream that provides streaming media content to the content presentation device 120 (e.g., metadata obtained from metering data included in an audio/video watermark, metadata obtained from metering data obtained from a separate metering data source, etc.). At block 1410, the metering metadata extractor 305 stores the metering metadata for subsequent reporting. At block 1415, the metering metadata reporter 310 of the device meter 110 reports the metering metadata to the media monitoring device 115. Execution of the example machine readable instructions 1400 is then terminated.

Fig. 15 illustrates example machine readable instructions 1500 that may be executed to implement the first example media monitoring device 115 of fig. 1 and 4. Referring to the previous figures, the example machine readable instructions 1500 of fig. 15 begin execution at block 1505 where the metering metadata collector 405 of the media monitoring device 115 gathers metering metadata (e.g., metadata obtained from metering data included in an audio/video watermark, metadata obtained from metering data obtained from a separate metering data source, etc.) and other metering information reported by the device meter 110. At block 1510, the report generator 410 of the media monitoring device 115 generates one or more reports based on the reported metering information. Execution of the example machine readable instructions 1500 then ends.

Fig. 16 illustrates example machine readable instructions 1600 that may be executed to implement the second example server meter 505 of fig. 5-6. Referring to the previous figures, the example machine readable instructions 1600 of FIG. 16 begin execution at block 1605, where the server meter 505 receives a transport stream carrying media content to be streamed to the content presentation device 120. At block 1610, the transport stream decoder 205 of the server meter 505 decodes the transport stream to obtain the (e.g., uncompressed) media content that is streamed to the content presentation device 120. In block 1615, the metering data extractor 210 of the server meter 505 extracts metering data (e.g., one or more embedded audio/video watermarks) from the decoded (e.g., uncompressed) media content obtained in block 1610. At block 1620, the content metadata extractor 605 extracts content identification metadata (e.g., playlist data, electronic program guide data, etc.) that has been accompanied with a transport stream carrying the streaming media content. At block 1625, the metadata verifier 610 of the server meter 505 may compare the metering data extracted at block 1615 to the content identification metadata extracted at block 1620 to verify the content identification metadata. At block 1630, the metadata verifier 610 reports the verification result to the media monitoring device 515. Execution of the example machine readable instructions 1600 is then terminated.

As described with reference to fig. 25, in some examples, the module 1615 may be modified and/or replaced with one or more modules to utilize metering data from an independent metering data source.

Fig. 17 illustrates example machine readable instructions 1700 that may be executed to implement the second example device meter 510 of fig. 5 and 7. Referring to the previous figures, the example machine readable instructions 1700 of fig. 17 begin execution at block 1705, where the content metadata extractor 705 of the device meter 510 extracts content identification metadata (e.g., playlist data, electronic program guide data, etc.) that has been accompanied by a transport stream that provides streaming media content to the content presentation device 120. At block 1710, the content metadata extractor 705 stores the content identification metadata for subsequent reporting. At block 1715, the content metadata reporter 710 of the device meter 510 reports the metering metadata to the media monitoring device 515. Execution of the example machine readable instructions 1700 is then complete.

FIG. 18 illustrates example machine readable instructions 1800 that may be executed to implement the second example media monitoring device 515 of FIGS. 5 and 8. Referring to the previous figures, the example machine readable instructions 1800 of fig. 18 begin execution at block 1805, where the content metadata collector 805 of the media monitoring device 515 collects content identification metadata (e.g., metadata accompanying transport streams, metadata extracted from metering data included in audio/video watermarks, metadata derived from metering data obtained from a separate metering data source, etc.) and/or other metering information reported by the device meters 510. At block 1810, the content metadata verifier 810 of the media monitoring device 515 receives a verification result related to the validity of the content identification information received at block 1805. At block 1815, the content metadata collector 805 verifies the collected content identification metadata using the verification results received at block 1810. Further, at block 1815, the report generator 815 of the media monitoring device 515 generates one or more reports based on the reported metering information. Execution of the example machine readable instructions 1800 then ends.

Fig. 19 illustrates exemplary machine readable instructions 1900 that may be executed to implement the third exemplary server meter 905 of fig. 9-10. Referring to the previous figures, the example machine readable instructions 1900 of FIG. 19 begin at block 1905, where the media content restorer 1005 of the server meter 905 restores the copy of the media content streamed to the content presentation device 120 from the temporary content store 920. At block 1910, the media content restorer 1005 decodes the restored media content (e.g., unpacked, combined, uncompressed, etc.) at block 1905 as needed. At block 1915, the metering data extractor 210 of the server meter 905 extracts metering data (e.g., one or more embedded audio/video watermarks) from the (e.g., uncompressed) media content obtained at block 1910. At block 1920, the metering data reporter 1010 of the server meter 905 reports the metering data obtained at the block 1915 to the media monitoring device 915. Execution of the example machine readable instructions 1900 is then terminated.

As described in detail below with reference to fig. 25, in some examples, the module 1915 may be modified and/or replaced with one or more modules to use metering data from an independent metering data source.

FIG. 20 illustrates example machine readable instructions 2000 that may be executed to implement the third example media monitoring device 915 of FIGS. 9 and 11. Referring to the previous figures, the example machine readable instructions 2000 of fig. 20 begin execution at block 2005 where the metering data collector 1105 of the media monitoring device 915 collects metering data reported by the server meter 905 (e.g., metadata that has been accompanied by a transport stream, metadata obtained from metering data included in an audio/video watermark, metadata derived from metering data obtained from a separate metering data source, etc.). At block 2010, the report generator 1110 of the media monitoring device 915 generates one or more reports based on the reported metering information. Execution of the example machine-readable instructions 2000 is then terminated.

Fig. 21 illustrates exemplary machine readable instructions 2100 that may be executed to implement the exemplary metadata inserter 1220 of fig. 12. Referring to the previous figures, the example machine readable instructions 2100 of fig. 21 begin execution at module 2105 where the metadata inserter 1220 obtains a decoded media content signal (e.g., a decoded television transport stream) from the IRDs 1210. At block 2110, the metadata inserter 1220 extracts watermark(s) (e.g., audio and/or video watermark (s)) from the media content signal. At block 2115, the metadata inserter 1220 decodes the watermark(s) to obtain the watermark payload data and, thus, the metering information provided by the watermark payload data. At block 2120, the metadata inserter 1220 inserts the watermark payload data into an existing portion of the media content signal capable of carrying metadata. For example, at block 2120, metadata inserter 1220 may insert the watermark payload data as VBI data according to SCTE127 standard, or as an ATSC proprietary information descriptor of one or more television transport streams, or the like. Execution of the example machine-readable instructions 2100 is then terminated.

In some examples, module 2115 may be modified and/or replaced with one or more modules to use metering data from an independent metering data source. This example is described with reference to fig. 25.

Fig. 22 illustrates example machine readable instructions 2200 that may be executed to implement the example transcoders 1225 and/or 1230 of fig. 12. For convenience, and without loss of generality, machine-readable instructions 2200 are described from the perspective of execution by transcoder 1225. Referring to the previous figures, the example machine readable instructions 2200 of fig. 22 begin execution at block 2205, where the transcoder 1225 extracts payload data inserted by the metadata inserter 1220 into metadata carrying the portion(s) of the media content signal. For example, at block 2205, the transcoder 1225 can extract the payload data as VBI data, as one or more ATSC specific information descriptors, and/or the like. At block 2210, transcoder 1225 transcodes the payload metadata obtained at block 2205 into a format compatible with the media stream in correspondence with the metering information. For example, at block 2210, transcoder 1225 may transcode the payload metadata into ID3 tag metadata. At block 2215, transcoder 1225 inserts the transcoded metadata into the portion(s) of the transport stream capable of carrying the streamed content(s) of the metadata. For example, at block 2215, transcoder 1225 may insert an ID3 tag corresponding to the metering metadata into the appropriate portion of the transport stream(s) that stream the media content according to the HLS or other suitable streaming media protocol. The execution of the example machine readable instructions 2200 is then terminated.

Fig. 23 is a block diagram of an exemplary system 2300 that obtains metering data for streaming media content. The exemplary system 2300 includes a slave metering data source 2310, an independent metering data source 2320, and a combiner 2330 for generating output metering data 2340.

The slave metering data source 2310 of the illustrated example receives media content and extracts metering data from the media content. In other words, the metering data collected by the metering data source 2310 is provided by the media content, and the metering data collected by the metering data source 2310 is related to the media content or otherwise dependent on the media content itself. For example, the dependent metering data source 2310 may extract metering data from audio and/or video watermarks included in the media content, may obtain metering data from signatures generated by the media content, and so on.

The example independent metering data source 2320 obtains metering data from a source that is independent of the content of the media content. For example, the independent metering data source 2320 may obtain a timestamp from a clock, identification information provided by user input, identification information stored in a file, and so forth. In some examples, the metering data obtained by the independent metering data source 2320 may be redundant, similar or identical in content and/or data type to the data extracted from the dependent metering data source 2310. For example, metering data from the slave metering data source 2310 and metering data from the independent metering data source 2320 may include the same source identifier.

The combiner 2330 of the illustrated example receives first metering data from a slave metering data source 2310 and second metering data from an independent metering data source 2320 and combines the first and second metering data to produce combined metering data 2340. As described with reference to fig. 26, in some examples, combined metering data 2340 includes redundant or partially redundant information. As described with reference to fig. 27, in some examples, metering data extracted by the slave metering data source 2310 is not available, and thus, only the metering data provided by the independent metering data source 2320 is included in the combined metering data 2340.

FIG. 24 illustrates a block diagram of an example server meter 2405 implemented in accordance with the system 2300 of FIG. 23. The server meter 2405 of fig. 24 includes a dependent metering data source 2310, an independent metering data source 2320, a clock 2410, a data source(s) 2420, a combiner 2330, a metering data transcoder 215, a metering metadata encryptor 220, and a transport stream encoder 225, which are described in detail above. The server meters 2405 of the illustrated example may be used to implement any of the server meters 105, 505, and/or 905 described above.

The exemplary slave metering data source 2310 of fig. 24 is implemented by the transport stream decoder 205 and metering data extractor 210 described with reference to fig. 2. The metering data extractor 210 of the example slave metering data source 2310 extracts metering data having a first format from the media content obtained by the transport stream decoder 205. Additionally or alternatively, the subordinate metering data source 2310 may be implemented by any other component to obtain metering data in any other manner depending on the content of the media content.

The independent metering data source 2320 of the illustrated example obtains metering data from the clock 2410 and the data source(s) 2420. Additionally or alternatively, the independent metering data source 2320 may obtain metering data from any other internal or external source that is independent (e.g., separate) from the media content and/or the transport stream(s) that provide the media content.

The clock 2410 of the illustrated example is an internal system clock of the server meter 2405, and when requested, the clock 2410 provides one or more timestamps to the independent metering data source 2320. The clock 2410 may alternatively be any type of internal clock, external clock, etc. For example, clock 2410 may be a clock located at the content provider and/or clock 2410 may be an internal clock that is synchronized with the content provider's clock.

The data source(s) 2420 of the illustrated example provide metering data to a separate metering data source 2320. The data source(s) 2420 provide metering data that is independent of (e.g., not extracted from) the media content. According to the illustrated example, the data source(s) 2420 include a profile that stores information identifying the source (e.g., content provider) of the streaming media content. The configuration file is established during setup of the server meters 2405. Additionally or alternatively, the data source(s) 2420 can include any one or more of locally stored data, externally stored data, data available through a network connection, data entered by a user of the server meter 2405, and the like.

In some examples, the independent metering data source 2320 inserts a tag or other form of identification into the obtained metering data to indicate that the metering data was collected by the independent metering data source 2420. For example, the independent metering data source 2320 of fig. 24 identifies the collected metering data as "non-audio" to indicate that the metering data was not extracted from the audio of the streaming media content. Additionally or alternatively, one or more other tags or identification information may be added.

The combiner 2330 of the illustrated example combines metering data from a slave metering data source 2310 with metering data from an independent data provider 2320. For example, the combiner 2330 concatenates the metering data extracted by the slave metering data source 2310 with the metering data obtained by the independent metering data source 2320 to produce a data string. The combiner inserts delimiters (e.g., "|") or any other symbol or indicator between the metering data extracted by the slave metering data source 2310 and the metering data obtained by the independent metering data source 2320. Additionally or alternatively, combiner 2330 may combine the metering data in any other manner.

To transcode the combined metering data obtained from the slave metering data source 2310 and the independent metering data source 2320 from a first format to a second format that can be decoded by the device meter, the example server meter 2405 of fig. 24 also includes a metering data transcoder. In addition, the server meter 2405 of fig. 24 includes a metering metadata encryptor 220, the metering metadata encryptor 220 encrypting the transcoded metering metadata determined by the metering data transcoder 215 using any suitable encryption method. In the example shown in fig. 24, the server meter 2405 includes a transport stream encoder 225 to re-encode the transport stream(s) carrying the streaming media content to include transcoded metering metadata determined by metering data transcoder 215 (and encrypted by metering metadata encryptor 220 as appropriate). Examples of generated metering data output by the server meter 2405 shown in fig. 24 are described with reference to fig. 26 and 27.

Although an exemplary manner of the system 2300 is described with reference to fig. 23 and 24, one or more of the components, processes and/or devices illustrated in fig. 23 and 24 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the dependent metering data source 2310, independent metering data source 2320, and one or more of the combiner 2330 and server meter 2405 of fig. 23, transport stream decoder 205, metering data extractor 210, independent metering data extractor 2320, combiner 2330, clock 2410, data source 2420, metering data transcoder 215, metering data encryptor 220, and transport stream encoder 225 of fig. 24 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or accessories. Thus, for example, the dependent metering data source 2310, independent metering data source 2320, and one or more of the combiner 2330 and server meter 2405 of fig. 23, transport stream decoder 205, metering data extractor 210, independent metering data extractor 2320, combiner 2330, clock 2410, data source 2420, metering data transcoder 215, metering data encryptor 220, and transport stream encoder 225 of fig. 24 may be implemented by one or more of a circuit, a programmable processor, an Application Specific Integrated Circuit (ASIC), a Programmable Logic Device (PLD), and/or a Field Programmable Logic Device (FPLD), among others. When any device claim or system claim of this patent is read to cover only a software and/or firmware implementation, the dependent metering data source 2310, independent metering data source 2320, and at least one of the combiner 2330 and server meter 2405 of fig. 23, transport stream decoder 205, metering data extractor 210, independent metering data extractor 2320, combiner 2330, clock 2410, data source 2420, metering data transcoder 215, metering data encryptor 220, and transport stream encoder 225 of fig. 24 are specifically defined to include tangible computer readable media, e.g., memory, Digital Versatile Disk (DVD), Compact Disk (CD), etc., storing such software and/or firmware. Further, the system 2300 of fig. 23 and the server meter 105 of fig. 24 may include one or more components, processes and/or devices in addition to, or instead of, those components, processes and devices illustrated in fig. 23 and 24, and/or may include more than one of any or all of the illustrated components, processes and devices.

Illustrated in fig. 25 are example machine readable instructions 2500 that may be executed to implement the example server meter 2405 of fig. 24. Referring to fig. 23 and 24, the example machine readable instructions 2500 of fig. 25 begin execution at block 2505, where the server meter 2405 receives a transport stream carrying media content to be streamed to the content presentation device 120 (block 2505). The transport stream decoder 205 of the slave metering data source 2310 decodes the transport stream to obtain the media content that is streamed to the content presentation device 120 (block 2510). The metering data extractor 210 of the slave metering data source 2310 extracts metering data (e.g., one or more embedded audio/video watermarks) having a first format from the decoded (e.g., uncompressed) media content obtained at block 2510 (block 2515). The independent metering data source 2320 collects metering data in either the first format or the second format from a source of content independent of the media content (block 2520). The combiner 2330 then combines the metering data collected by the metering data extractor 210 with the metering data collected by the independent metering data source 2320 (block 2525).

The metering data transcoder 215 of the server meter 2405 transcodes the metering data in the first format and/or the second format obtained at block 2515 and block 2520 and combined at block 2525 to form transcoded metering metadata having a third format (e.g., text, binary, or other data format) that can be decoded by the device meter 110 (block 2530). The transport stream encoder 225 of the server meter 105 re-encodes the transport stream carrying the streaming media content to include the transcoded metering metadata in a metadata channel associated with the transport stream (block 2535). The server meter 2405 sends the re-encoded transport stream (and the metadata channel carrying the transcoded metered metadata) to any downstream processing component for streaming to the content presentation device 120 (block 2540). Execution of the example machine readable instructions 2500 is then terminated.

Fig. 26 illustrates exemplary metadata 2600 obtained from combined metering data 2340 after being extracted, obtained, combined, and transcoded by a server meter 2405 as shown in fig. 24. Metadata 2600 includes a module 2610, module 2610 being part of metadata 2600 extracted from media content by metering data extractor 210. The timestamp 2612 is timestamp data extracted from the media content by the metering data extractor 210. The source identification 2614 is source identification data extracted from the media content by the metering data extractor 210. Metadata 2600 also includes a module 2620, module 2620 being a portion of metadata 2600 collected by independent metering data source 2320. The timestamp 2622 is timestamp data that is acquired by the independent metering data source 2320 from the clock 2410. The source identification 2624 is source identification data that is acquired by the independent metering data source 2320 from the data source(s) 2420. Tag 2626 is a tag on metadata 2620 that identifies metadata 2620 as being obtained by a separate metering data source 2320. Metadata 2340 illustrated in fig. 26 is an example in which metadata 2610 is readable and metadata 2620 is redundant or similar metadata.

Fig. 27 shows exemplary metadata 2700 obtained from metering data 2340 after being extracted, obtained, combined, and transcoded by the server meter 105 shown in fig. 25. Metadata 2700 illustrates an example in which a portion of metadata 2700, module 2710, is unreadable or unavailable, and a portion of metadata 2700, module 2720 associated with a separate metering data source, as a backup source for the source data, can be used to replace the unreadable or unavailable metadata. Module 2710 is part of metadata 2700 extracted from metering data extractor 210. Module 2720 is part of metadata 2700 obtained from a separate metering data source 2320. The timestamp 2722 is timestamp data obtained by a separate metering data source 2320 from a clock 2410. The source identification 2724 is source identification data that the independent metering data source 2320 obtained from the data source(s) 2420. The tag 2726 is a tag on the metadata 2720 that is used to identify the metadata 2720 as being obtained by a separate metering data source 2320.

Fig. 28 illustrates a block diagram of a fifth exemplary system 2800 that monitors streaming media content. The fifth exemplary system 2800 includes many of the same components as the first exemplary system 100 of fig. 1. As such, like elements in fig. 1 and 28 are labeled with the same reference numerals. These similar elements have been described in detail above with reference to fig. 1 and, therefore, for the sake of brevity, are not repeated in the discussion of fig. 28.

Turning to fig. 28, an exemplary system 2800 is shown including a compression apparatus 130, a segmenter and packager 135, a digital rights manager 140, and a content streamer 145 to provide streaming media content to a second exemplary content presentation device 2820 via a network 150. To provide media content to the system 2800, the example shown in fig. 28 includes content provider(s) 125. To monitor media content streamed to the content presentation device 2820 and optionally provide secondary content based on the results of the media monitoring, the illustrated example system 2800 also includes a server meter 105, a device meter 110, a fourth example media monitoring device 2815, and an example secondary content presenter 2825.

Media monitoring device 2815 includes an interface to receive reported metering information (e.g., metering metadata) received from device meters 110 over network 150. In the example shown, media monitoring device 2815 includes an HTTP interface to receive HTTP requests including metering information. Additionally or alternatively, any other method(s) of receiving metering information may be used. In the illustrated example, the media monitoring device 2815 receives metering information from the device meter 110, selects secondary content using the received metering information, and sends the selected secondary content to the secondary content presenter 2825. In some examples, the media monitoring device may select the secondary content from an internal content database. In some examples, media monitoring device 2815 may select secondary content from one or more external databases and/or third party databases. In such an example, media monitoring device 2815 may access external and/or third party databases over a network (e.g., the internet, a Local Area Network (LAN), a Wide Area Network (WAN), etc.). Other additional or alternative examples OF secondary MEDIA CONTENT that PROVIDEs a correlation TO primary MEDIA CONTENT used by the MEDIA monitoring device 2815 are described, for example, in U.S. patent publication No. 2010/0280641 ("METHOD, APPARATUS ANS ARTICLES OF manual TO PROVIDE security association notification WITH PRIMARY BROADCAST MEDIA CONTENT", Harkness, etc.), filed 4, 30/2012, which is hereby incorporated by reference in its entirety.

The content presentation device 2820 of the illustrated example is a computing device capable of presenting streaming media content provided by the content streamer 145 over the network 150. The content presentation device 2820 may be, for example, a desktop computer, a laptop computer, a mobile computing device, a television, a smart phone, a mobile phone, a television,in some examples, the content presentation device 2820 includes one or more executable media players to present streaming media content provided by the content streamer 145(e.g., provided in a SWF file), may be implemented as HyperText markup language (HTML) version 5(HTML5), may be implemented inMay be implemented according to an Open Source Media Framework (OSMF), may be implemented according to a media player Application Program Interface (API) of a device or operating system provider, may be implemented on a media player framework of a device or operating system provider (e.g.,mpmovielayer software), and the like, or any combination thereof. Although a single content presentation device 120 is shown, any number and/or type(s) of content presentation devices may be included in the system 100.

In the illustrated example, the content presenter 2820 implements a secondary content presenter 2825. the secondary content presenter 2820 can be an executable media presenter stored on a computing device that is capable of presenting secondary content provided by the media monitoring device 2815 through the network 150. in some examples, the secondary content presenter 2825 can be implemented as a plug-in that interfaces with a plug-in of a media player executed by the content presenter 2820. in some examples, the secondary content presenter 2825 can be implemented as provided instructions that are incorporated into a media player executed by the content presenter 2820. in some examples, the secondary content presenter 2825 can be implemented as an executable application that is downloaded onto the content presenter 2820 (e.g., as an App downloaded from an App ⑧ App Store.) for example, the secondary content presenter 2825 can be implemented as an executable application that is downloaded onto the content presenter 2820(e.g., provided in a SWF file), may be implemented as HyperText markup language (HTML) version 5(HTML5), may be implemented inIn (1), the method can be based on Open Source Media Framework (OSMF)) The implementation may be in accordance with a media player Application Program Interface (API) implementation of the device or operating system provider, may be implemented on a media player framework of the device or operating system provider (e.g.,mpmovielayer software), and the like, or any combination thereof. Although a single secondary content presenter 2825 is illustrated, any number and/or type(s) of secondary content presenters associated with content presentation device 2820 can be included in system 2800.

FIG. 29 illustrates example machine readable instructions 2900 that may be executed to implement the second example media monitoring device 2815 of FIG. 28. Referring to the previous figures, the example machine readable instructions 2900 of fig. 29 begin execution at block 2905, where the media monitoring device 2815 collects metering metadata (e.g., metadata obtained from metering data included in an audio/video watermark, metadata obtained from metering data obtained from a separate metering data source, etc.) and/or other metering information reported by the device meter 110 (block 2905). The media monitoring device 2915 then uses the metering metadata received at block 2905 to select secondary content (block 2910). The media monitoring device 2815 then sends the secondary content selected at block 2910 to the secondary content presenter 2825 (block 2915). Execution of the example machine-readable instructions 2900 then terminates.

Illustrated in fig. 30 are exemplary machine readable instructions 3000 that may be executed to implement the device meter 110 and the secondary content presenter in the content presentation device 2820 of fig. 28. Referring to the previous figures, the example machine readable instructions 3000 of FIG. 30 begin execution at block 3005, where the device meter 110 detects and reports metering metadata to the media monitoring device 2815 (block 3005). Subsequently, the secondary content presenter 2825 receives secondary content associated with the metered metadata reported to the media monitoring device 2815 at block 3005 (block 3010). Subsequently, the secondary content presenter 2825 presents the secondary content received at block 3010 (block 3015). Execution of the example machine readable instructions 3000 then ends.

Fig. 31 is a block diagram of an exemplary processing system 3100 in which apparatus and methods described herein can be implemented. The processing system 3100 may be, for example, a desktop computer, notebook/laptop computer, Personal Digital Assistant (PDA), server, internet appliance, DVD player, CD player, digital video recorder, personal video recorder, set-top box, or any other type of computing device.

The present exemplary system 3100 includes a processor 3112, e.g., a general purpose programmable processor. The processor 3112 includes a local memory 3114 and executes coded instructions 3116 that reside in the local memory 3114 and/or in other memory devices. The processor 3, 2 may execute, among other things, machine readable instructions shown in fig. 13-22, 25, 29, and/or 30. The processor 3112 may be any type of processing unit, e.g., one or more fromA series of,Series and/orOf the seriesA microprocessor, one or more processing cores (e.g., one or more)A serial processing core), one or more microcontrollers (e.g., one or more)A series of microcontrollers), etc. Of course, processors from other families are also suitable.

The processor 3112 communicates with a main memory including a volatile memory 3118 and a non-volatile memory 3120 over a bus 3122. Volatile memory 3118 may be implemented by Static Random Access Memory (SRAM), Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM), and/or other types of random access memory devices. The non-volatile memory 3120 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 3118, 3120 is typically controlled through a memory controller (not shown).

Processing system 3100 also includes interface circuit 3124. The interface circuit 3124 may be implemented by any type of interface standard, such as an ethernet interface, a Universal Serial Bus (USB), and/or a third generation input/output (3GIO) interface.

One or more input devices 3126 are connected to the interface circuit 3124. The input device(s) 3126 allow a user to enter data and instructions to the processor 3112. The input device(s) may be implemented by, for example, a keyboard, a mouse, a touch screen, a track pad, a track ball, an isopoint, and/or a voice recognition system.

One or more output devices 3128 are also connected to the interface circuit 3124. The output devices 3128 can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT)), by a printer and/or speakers. The interface circuit 3124 thus typically includes a graphics driver card.

The interface circuit 3124 also includes a communication device (e.g., a modem or network interface card) to facilitate interaction of data with external computers via a network (e.g., an ethernet connection, a Digital Subscriber Line (DSL), a telephone line, a coaxial line, a cellular telephone system, etc.).

The processing system 3100 also includes one or more mass memory devices 3130 for storing machine-readable instructions and data. Examples of such mass storage devices 3130 include floppy disk drives, hard disk drives, optical disk drives, and Digital Versatile Disk (DVD) drives. In some examples, the mass storage 3130 may implement the temporary content storage 920. Additionally or alternatively, in some examples, volatile memory 3118 may implement temporary content storage 920.

The code instructions 3132 of fig. 13-22, 25, 29, and 30 may be stored in the mass storage device 3130, in the volatile memory 3118, in the non-volatile line memory 3120, in the local memory 3114, and/or in a removable storage medium, such as a CD or DVD 3132.

As an alternative to the methods and/or apparatus described herein being implemented in a system such as the processing system of fig. 31, the methods and/or apparatus described herein may be embedded in the structure of, for example, a processor and/or an ASIC (application specific integrated circuit).

Finally, although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the disclosure or the equivalents thereof.

Claims (11)

1. A method of monitoring streaming media, the method comprising:

extracting, using a processor, metering data having a first format from media to be provided to a media presentation device via a transport stream, the extracted metering data identifying at least one of the media or a source of the media, the extracted metering data being undecodable by a meter associated with the media presentation device;

transcoding, using the processor, the extracted metering data to form transcoded metering data having a second format that is decodable by the meter associated with the media presentation device; and

encoding, using the processor, the transcoded metering data into an external metadata channel to send the transcoded metering data to the media presentation device, the external metadata channel comprising a file to be sent to the media presentation device separately from and prior to communication of the transport stream to the media presentation device, the external metadata channel being related to the transport stream.

2. The method of claim 1, wherein the file corresponds to an M3U file, transcoding the extracted metering data to form the transcoded metering data having the second format comprises: transcoding the extracted metering data to form text data corresponding to the metering data, and encoding the transcoded metering data to the external metadata channel comprises: the text data is inserted into an M3U file that implements the external metadata channel.

3. The method of claim 1, wherein extracting the metering data having the first format from the media comprises: extracting watermark data from the media and transcoding the extracted metering data to form the transcoded metering data having the second format comprises: the extracted watermark data is transcoded to form text data included in an M3U file.

4. The method of claim 1, further comprising sending secondary data to the media presentation device, the secondary data selected based on the transcoded metering data monitored at the media presentation device.

5. A system for monitoring streaming media, the system comprising:

means for extracting metering data having a first format from media to be provided to a media presentation device via a transport stream, the extracted metering data identifying at least one of the media or a source of the media, the extracted metering data being undecodable by a meter associated with the media presentation device;

means for transcoding the extracted metering data to form transcoded metering data having a second format that is decodable by the meter associated with the media presentation device; and

means for encoding the transcoded metering data into an external metadata channel to send the transcoded metering data to the media presentation device, the external metadata channel comprising a file to be sent to the media presentation device separately from and prior to communication of the transport stream to the media presentation device, the external metadata channel being associated with the transport stream.

6. The system of claim 5, wherein the file corresponds to an M3U file, the means for transcoding comprises means for transcoding the extracted metering data to form text data corresponding to the metering data, and the means for encoding comprises means for inserting the text data into an M3U file that implements the external metadata channel.

7. A system as defined in claim 5, wherein the means for extracting comprises means for extracting watermark data from the media, and the means for transcoding comprises means for transcoding the extracted watermark data to form text data for inclusion in an M3U file.

8. A system as recited in claim 5, further comprising means for sending secondary data to the media presentation device, the secondary data being selected based on the transcoded metering data monitored at the media presentation device.

9. A meter to monitor media, the meter comprising:

an extractor to extract metering data having a first format from media to be provided to a media presentation device via a transport stream, the extracted metering data identifying at least one of the media or a source of the media, the extracted metering data being undecodable by a meter associated with the media presentation device;

a transcoder that transcodes the extracted metering data to form transcoded metering data having a second format that is decodable by the meter associated with the media presentation device; and

an encoder to encode the transcoded metering data into an external metadata channel to send the transcoded metering data to the media presentation device, the external metadata channel comprising a file to be sent to the media presentation device separately from and prior to communication of the transport stream to the media presentation device, the external metadata channel being associated with the transport stream.

10. A meter as defined in claim 9 wherein the file corresponds to an M3U file, the transcoder is to transcode the extracted metering data to form the transcoded metering data having the second format by transcoding the extracted metering data to form text data corresponding to the metering data, and the encoder is to encode the transcoded metering data into the external metadata channel by inserting the text data into an M3U file that implements the external metadata channel.

11. A meter as defined in claim 9 wherein the extractor is to extract the metering data having the first format from the media by extracting watermark data from the media, and the transcoder is to transcode the extracted metering data to form transcoded metering data having the second format by transcoding the extracted watermark data to form text data for inclusion in an M3U file.