HK1238449B - Method, apparatus and system to monitor media - Google Patents

Description

Media monitoring method, device and system

Technical Field

The present disclosure relates generally to media monitoring, and more particularly to performing media monitoring for mobile platforms using messages associated with adaptive bitrate streaming.

Background Art

The use of mobile platforms, such as smartphones, tablet computers, laptop computers, and the like, for presenting media, such as media content, media advertisements, and the like, has become commonplace. Therefore, enhancing audience measurement activities that include monitoring media impressions on mobile platforms (such as impressions related to the presentation of media content, media advertisements, and the like) may be valuable to content providers, advertisers, and the like. To increase the value of the ratings data obtained from such audience measurement activities, audience measurement entities strive to enhance the media impression data with demographic information related to the audience of the media impressions. Existing audience measurement techniques typically rely on monitoring a specialized panel of statistically selected audience members to obtain demographic information for inclusion in the audience ratings data.

Summary of the Invention

According to one aspect of the present invention, a method for monitoring media on a mobile platform is proposed, the method comprising: utilizing a processor of a first server to access a first adaptive bitrate streaming uniform resource locator (URL) collected by a meter running on the mobile platform from a first message to be sent by the mobile platform to a second server to stream first media according to an adaptive bitrate streaming protocol, the first adaptive bitrate streaming URL being received by the first server in a report sent from the meter running on the mobile platform, the first server being different from the second server, the mobile platform sending the first message including the first adaptive bitrate streaming URL to the second server to stream the first media; utilizing the processor to request network log information corresponding to the first adaptive bitrate streaming URL from a service provider providing network access to the mobile platform; and utilizing the processor to monitor the presentation of the first media on the mobile platform using the network log information.

According to one aspect of the present invention, a system for monitoring media on a mobile platform is proposed, the system comprising: a device for using a processor of a first server to access a first adaptive bitrate streaming uniform resource locator (URL) collected by a meter running on the mobile platform from a first message to be sent by the mobile platform to a second server, so as to stream the first media according to an adaptive bitrate streaming protocol, the first adaptive bitrate streaming URL being received by the first server in a report sent from the meter running on the mobile platform, the first server being different from the second server, and the mobile platform sending the first message including the first adaptive bitrate streaming URL to the second server to stream the first media; a device for using the processor to request network log information corresponding to the first adaptive bitrate streaming URL from a service provider providing network access to the mobile platform; and a device for using the processor to monitor the presentation of the first media on the mobile platform using the network log information.

According to one aspect of the present invention, a device for monitoring media on a mobile platform is proposed, the device comprising: a uniform resource locator (URL) collector, which accesses a first uniform resource locator (URL) included in a first message initiated by the mobile platform to stream first media according to an adaptive bitrate streaming protocol; a provider data requester, which requests network log information corresponding to the first URL from a service provider providing network access to the mobile platform; and a ratings monitor, which uses the network log information to monitor the presentation of the first media on the mobile platform.

BRIEF DESCRIPTION OF THE DRAWINGS

1 is a block diagram of a first exemplary use environment including a first exemplary audience measurement system for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming as described herein.

2A-2C illustrate an exemplary process for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming in the first exemplary use context of FIG. 1 .

3 is a block diagram of a second exemplary use environment including a second exemplary audience measurement system for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming as described herein.

4 is a block diagram of an example implementation of the meter of FIG. 1 that monitors an example mobile platform to detect message data associated with adaptive bitrate streaming of media and reports the data to the mobile platform.

5 is a block diagram of an exemplary implementation of the proxy server of FIG. 3 that detects message data associated with adaptive bitrate streaming of media and reports the data to a mobile platform.

6 is a block diagram of an exemplary implementation of the audience measurement entity server of FIG. 1 and/or FIG. 3 that collects message data associated with adaptive bitrate streaming and uses the message data to monitor media on a mobile platform.

Figure 7 is a block diagram of an exemplary implementation of the operations support system of Figures 1 and/or 3, which retrieves service provider data corresponding to message data associated with adaptive bitrate streaming and returns such provider data to an audience measurement entity for use in monitoring media on a mobile platform.

8 is a flow diagram representative of example machine readable instructions that may be executed to implement the example meter of FIG. 4 .

9 is a flow diagram representative of example machine readable instructions that may be executed to implement the example proxy server of FIG. 5 .

10 is a flow diagram representative of example machine readable instructions that may be executed to implement the example audience measurement entity server of FIG. 6 .

11 is a flow diagram representative of example machine readable instructions that may be executed to implement the example operations support system of FIG. 7 .

Figure 12 is a block diagram of an exemplary processor platform that can execute exemplary machine-readable instructions of Figures 8 to 10 and/or Figure 11 to implement the exemplary meter of Figure 4, the exemplary proxy server of Figure 5, the exemplary audience measurement entity server of Figure 6, the exemplary operation support system of Figure 7 and/or the exemplary system of Figures 1 and/or 3.

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

DETAILED DESCRIPTION

Disclosed herein are methods, devices, systems, storage media, and the like for performing media monitoring on a mobile platform using messages associated with adaptive bitrate streaming. The disclosed exemplary method for monitoring media on a mobile platform includes accessing a first uniform resource locator (URL) included in a first message initiated by the mobile platform to stream first media according to an adaptive bitrate streaming protocol. The disclosed exemplary method also includes requesting network log information corresponding to the first URL from a service provider providing network access to the mobile platform. The disclosed exemplary method also includes monitoring the presentation of the first media on the mobile platform using the network log information.

In some such disclosed exemplary methods, the weblog information includes: (1) a timestamp corresponding to a time when a first message including a first URL was logged by the network, and/or (2) location information specifying a location of the mobile platform at the time when the first message including the first URL was logged by the network. Additionally or alternatively, some such disclosed exemplary methods further include: obtaining demographic information in addition to the weblog information in response to providing the first URL to the service provider. In some such examples, the weblog information and demographic information omit personal information associated with a subscriber associated with the mobile platform.

Additionally or alternatively, in some such disclosed exemplary methods, requesting web log information includes sending a request to a service provider including the first URL and a time range associated with a time when the first URL was detected.

Additionally or alternatively, in some such disclosed exemplary methods, monitoring presentation of the first media on the mobile platform includes combining web log information with media identification information associated with the first URL.

Additionally or alternatively, certain disclosed example methods further include requesting web log information corresponding to other URLs included in subsequent messages initiated by the mobile platform from a service provider for streaming the first media according to an adaptive bitrate streaming protocol. Certain such example methods further include determining, using the web log information corresponding to the first URL and the web log information corresponding to the other URLs, viewership data associated with presentation of the first media on the mobile platform, the viewership data having a temporal granularity corresponding to time intervals between media segments of the first media identified by the first message and the subsequent message.

Additionally or alternatively, some of these example methods disclosed herein further include: detecting the first message using at least one of an application executing on the mobile platform or a proxy server in communication with the mobile platform. In some such examples, detecting the first message includes: accessing the first message; and processing a first URL in the first message to detect information indicating that the first URL complies with an adaptive bitrate streaming protocol. In some examples disclosed herein, the adaptive bitrate streaming protocol corresponds to at least one of Hypertext Transfer Protocol (HTTP) Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), Smooth Streaming, and the like.

Certain example methods disclosed herein for monitoring media on a mobile platform include: accessing a request for web log information corresponding to a first URL received from an audience measurement entity (AME). In this example, the first URL is associated with a first message initiated by the mobile platform to stream first media according to an adaptive bitrate streaming protocol. The adaptive bitrate streaming protocol can correspond to, for example, HLS, DASH, Smooth Streaming, etc. Certain example methods disclosed herein also include: retrieving the web log information corresponding to the first URL, and returning the web log information to the AME in response to the request.

In some such disclosed exemplary methods, the weblog information includes: (1) a timestamp corresponding to a time when the first message including the first URL was logged by the network, and/or (2) location information specifying a location of the mobile platform at the time when the first message including the first URL was logged by the network. Additionally or alternatively, some such disclosed exemplary methods further include omitting personal information related to a subscriber associated with the mobile platform from the weblog information before returning the weblog information to the AME.

Additionally or alternatively, in some such disclosed exemplary methods, the request received from the AME includes a first URL and a time range associated with a time when the first URL was detected by the AME. In some such disclosed exemplary methods, retrieving the network log information includes querying network log storage using the first URL and the time range. Some such disclosed exemplary methods further include, in response to the query, receiving a timestamp corresponding to a time when a first message including the first URL was logged by the network. Some such disclosed exemplary methods further include, in response to the query, receiving location information specifying a location of the mobile platform at the time when the first message including the first URL was logged by the network.

Additionally or alternatively, some of these disclosed exemplary methods further include querying a database to obtain demographic information corresponding to the first URL in addition to the weblog information, and returning the demographic information in addition to the weblog information to AME in response to the request. Some of these disclosed exemplary methods further include omitting personal information related to a subscriber associated with the mobile platform from the demographic information before returning the demographic information to AME.

These and other exemplary methods, apparatus, systems, storage media, etc., for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming are disclosed in greater detail below.

As described above, existing audience measurement techniques typically rely on statistically selected panels of audience members to obtain demographic information to be included in audience ratings data and/or to be used to otherwise enhance audience ratings data. However, such panel-based audience measurement techniques may not be able to perform accurate media monitoring for mobile platforms. For example, given the number and types of media sources accessible via modern mobile platforms, the size of a statistically selected panel may be too small to capture the large number of different media impressions caused by a population of mobile platform users in a statistically meaningful manner. For example, many online streaming services provide access to thousands or even millions of different media programs that can be viewed on demand at any time. A typical audience measurement panel may only include hundreds or thousands of panelists and, therefore, may not accurately reflect the different media impressions that arise among a large population of mobile users who have access to this plethora of different media options.

The exemplary mobile platform media monitoring scheme disclosed herein (which uses messages associated with adaptive bitrate streaming to perform media monitoring on a mobile platform) can solve technical problems associated with obtaining accurate demographic data for use when monitoring media impressions on a mobile platform. For example, certain exemplary mobile platform media monitoring schemes disclosed herein solve such problems by obtaining detailed demographic information from a wireless service provider that provides network access to the mobile platform using a URL associated with the media streamed to the mobile platform. Wireless service providers typically maintain a database that includes subscriber data that provides demographic information about their subscribers. In addition, wireless service providers typically collect network logs that record network traffic associated with mobile platforms that communicate with their respective networks. Such network logs may include demographic-related information such as the location of the mobile platform in the network when a particular traffic occurred, and the specific time when such traffic occurred in the network. In addition, for the monitored media impressions, the timing data available from the network logs may be more accurate or have a finer granularity than the timing data that can be otherwise determined by existing audience measurement systems. As disclosed in more detail below, the exemplary mobile platform media monitoring scheme disclosed herein enables an audience measurement entity to receive provider data from a wireless provider that includes such demographic information (e.g., location information, subscriber information, etc.) and temporal information, which provider data can be associated with media impressions monitored on one or more mobile platforms.

1 shows a block diagram of an example usage environment 100 including an example audience measurement system 102 for performing media monitoring for mobile platforms using messages associated with adaptive bitrate streaming, as described herein. The example usage environment 100 of FIG1 includes one or more mobile platforms, such as an example mobile platform 105, operating in an example access network 110 implemented by a service provider. In the example usage environment 100 of FIG1 , the access network 110 provides the mobile platforms 105 with access to the Internet 115 and/or any other network, such as a content delivery network (CDN), a private network, etc. Via the example access network 110 and the Internet 115, the mobile platform 105 of the illustrated example is able to access one or more data sources, including one or more media streaming servers, such as an example streaming server 120. For example, the mobile platform 105 is able to access the streaming server 120 and/or other servers (e.g., advertising servers, etc.) via the access network 110 and the Internet 115, and receive and present media including media content such as movies, television programs, etc. and/or media advertisements streamed from the streaming server 120 and/or other servers.

The exemplary mobile platform 105 of FIG1 may correspond to any mobile device, apparatus, system, or the like, such as a cell phone or smartphone, a tablet computer (e.g., an Apple iPad ^™ ), a laptop computer, a game console (e.g., a Ninendo 3DS ^™ ), a personal digital assistant (PDA), or the like. The exemplary access network 110 of FIG1 may correspond to any type, number, and/or combination of access networks, such as a mobile cellular network, a wireless local area network (WLAN) such as a WiFi network, a proprietary wireless network, or the like. The exemplary streaming media server 120 of FIG1 may correspond to a streaming media service, such as Netflix, Hulu, Amazon, or the like, accessible from the mobile platform 105. Thus, the streaming media server 120 may be implemented by any type, number, and/or combination of physical and/or virtual servers and/or platforms (such as the exemplary processing platform 1200 of FIG12 ) capable of transmitting media streams to a media device, such as the mobile platform 105, over a network.

The example audience measurement system 102 included in the example usage environment 100 of FIG1 includes an example meter 125 and an example AME server 130 for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming, as disclosed herein. In the example shown in FIG1 , the AME server 130 can be implemented by any type, number, and/or combination of physical and/or virtual servers and/or platforms, such as the example processing platform 1200 of FIG12 . In the example shown in FIG1 , the meter 125 can be implemented by any type, number, and/or combination of applications (e.g., apps) executing on the mobile platform 105, and/or monitoring devices electrically coupled (e.g., via an electrical data port), optically coupled (e.g., via an electrical-optical port), and/or otherwise in communication with the mobile platform 105, capable of detecting messages initiated by the mobile platform 105 to stream media from the streaming server 120 according to an adaptive bitrate streaming protocol. For example, the meter 125 of the illustrated example detects an adaptive bitrate streaming URL included in a message originated by the mobile platform 105 and to be sent to the streaming server 120 to request and stream the media segment addressed by the adaptive bitrate streaming URL.

In some examples, the meter 125 is an application that the service provider automatically installs on the mobile platform 105 and/or causes to be automatically downloaded to the mobile platform 105 via the access network 110. In some examples, the streaming server 120 or another server causes the meter 125 to be downloaded to the mobile platform 105 as a condition for accessing streaming media. Such a meter may be referred to as a non-panelist meter to distinguish it from a panelist meter, such as an on-device meter, which is provided to panelists statistically selected by AME to be included in an audience measurement panel (and which may include a wider range of media monitoring capabilities than a non-panelist meter). However, in some examples, the meter 125 may correspond to a panelist meter provided by AME. Thus, the mobile platform media monitoring scheme disclosed herein can be used to monitor a mobile platform regardless of whether the mobile platform is associated with an AME panelist.

In adaptive bitrate streaming, the media to be streamed is encoded into two or more alternative media streams with different data rates (and therefore different qualities). Each alternative media stream is then segmented into short segments, such as 10-second segments or segments of some other duration. To receive streaming media from the streaming server 120 according to the adaptive bitrate streaming protocol, the mobile platform 105 requests consecutive media segments (e.g., consecutive 10-second segments) using an adaptive bitrate streaming URL that identifies the segment. Each time the next segment is requested, the mobile platform 105 can select from different next segments corresponding to different alternative streams, allowing the mobile platform 105 to adapt the media quality to the available data rate. In the example shown in FIG1 , the meter 125 detects the adaptive bitrate streaming URL accessed by the mobile platform 105 and provides the detected adaptive bitrate streaming URL to the AME server 130 for further processing.

For example, the AME server 130 of the illustrated example receives an adaptive bitrate streaming URL and identifies media to be streamed to and presented by the mobile platform 105 at a resolution corresponding to the segment duration (e.g., such as a 10-second resolution). In some examples, the AME server 130 maintains a database and/or other repository capable of linking resource identifier information (e.g., domain name and path information) in the URL to different source media. For example, the AME server 130 can determine resource identifier information for different source media accessible from the streaming server 120 via information reported and updated by an operator of the streaming server 120 (and other streaming servers), such as Netflix, Hulu, Amazon, etc. Additionally or alternatively, the AME server 130 can determine specific source media linked to resource identifier information included in an adaptive bitrate streaming URL reported by a meter, such as the meter 125, by accessing the source media addressed by the specific resource identifier and identifying the media using any appropriate media identification technique (e.g., watermark/encoding matching, signature matching, etc.).

For example, the AME server 130 may use one or more media identification techniques employing watermarks and/or signatures to identify media accessed using a resource identifier included in a URL. In the case of media monitoring, a watermark may be transmitted within a media signal and/or may be transmitted using a media signal. For example, a watermark may be used to transmit data (e.g., such as an identification code, an auxiliary code, etc.) through the media (e.g., inserted into an audio, video, or metadata stream of the media) to uniquely identify the broadcaster and/or the media (e.g., content or advertisements), and/or to convey other information. A decoding operation is typically used to extract the watermark.

In contrast, a signature is a representation of certain characteristics of a media signal (e.g., characteristics of the signal's spectrum). A signature can be thought of as a fingerprint. Signatures generally do not rely on the insertion of an identification code (e.g., a watermark) into the media, but instead preferably reflect inherent characteristics of the media and/or the signal transmitting the media. Systems for media surveillance utilizing codes (e.g., watermarks) and/or signatures have long been known. See, for example, U.S. Patent No. 5,481,294 to Thomas, which is incorporated herein by reference in its entirety.

Returning to the exemplary use environment 100 of FIG1 , the AME server 130 provides the adaptive bitrate streaming URLs detected for one or more mobile platforms, such as the mobile platform 105, and any timing data associated therewith, to a service provider operating the access network 110 to request provider information, such as network log information, subscriber information, etc., to be used to enhance viewership data determined by the AME. In the illustrated example, the AME server 130 provides (e.g., in real time, at reporting intervals, etc.) the adaptive bitrate streaming URLs detected for one or more mobile platforms, such as the mobile platform 105, to an exemplary operations support system (OSS) 135 used by the service provider to manage the exemplary access network 110. In the illustrated example of FIG1 , the OSS 135 includes an exemplary network log server 140 to store network logs documenting network traffic associated with mobile platforms, such as the mobile platform 105, operating in and/or communicating with the provider's access network 110. The exemplary OSS 135 of FIG1 also includes an exemplary subscriber database server 145 to store subscriber data, including demographic information about the provider's subscribers. The web log server 140 and/or subscriber database server 145 may be implemented by any type, number, and/or combination of physical and/or virtual servers and/or platforms, such as the exemplary processing platform 1200 of FIG12.

In some examples, in response to receiving the adaptive bitrate streaming URL in the request for provider information, the OSS 135 compares the adaptive bitrate streaming URL with the web logs stored in the web log server 140 to, for example, identify the mobile platform, such as the mobile platform 105, that accessed the adaptive bitrate streaming URL, identify the time when the adaptive bitrate streaming URL was accessed/recorded, determine location information of the mobile platform, such as the mobile platform 105, at the time when the adaptive bitrate streaming URL was accessed/recorded, etc. In some examples, the OSS 135 uses the mobile platform identification information obtained from the web logs to further retrieve subscriber data associated with the identified mobile platform, such as the mobile platform 105, from the subscriber database server 145. Such subscriber data may include, for example, demographic-related data such as the subscriber's address, the subscriber's age, the subscriber's gender, the subscriber's race, the subscriber's income, the subscriber's education level, the service level to which the subscriber subscribes, and/or any other subscriber data stored in the subscriber database server 145. Since the adaptive bitrate streaming URL included in the request from the AME server 130 may be associated with any customer/subscriber, not just AME's panel members, the OSS 135 may retrieve web log information and/or subscriber data associated with any customer/subscriber, not just AME's panel members.

In some examples, the AME server 130 includes one or more time ranges corresponding to the times at which the adaptive bitrate streaming URLs were detected/recorded by the meter 125 in a request for vendor information sent to the OSS 135. In such examples, the time ranges can help the OSS 135 narrow its search of the web logs stored by the web log server 140 and/or the subscriber data stored in the subscriber database server 145 when determining the vendor information to report in response to the request. For example, if the request for vendor information includes adaptive bitrate streaming URLs for multiple different mobile platforms and/or corresponds to a sufficiently long interval (e.g., tens of minutes, hours, etc.), the timing data provided by the AME server 130 in the request can help the OSS 135 narrow its search to the times/time ranges. In some examples, the timing data available to the AME server 130 is less accurate than the timing data maintained by the web log server 140 or, more generally, the OSS 135, and as such, the AME server 130 can use timing data (e.g., timestamps) retrieved from the web log server 140 to improve monitoring accuracy.

In some examples, the OSS 135 processes the retrieved web log information and/or subscriber data corresponding to the adaptive bitrate streaming URL to determine provider information including the web log information and/or subscriber data. In some examples, such data is aggregated or otherwise anonymized to protect the privacy of subscribers of the service provider (e.g., users of mobile platforms such as mobile platform 105 operating in and/or communicating with access network 110). For example, the resulting web log information returned by the OSS 135 to the AME server 130 for the adaptive bitrate streaming URL included in the request may include, but is not limited to, a timestamp indicating the time the adaptive bitrate streaming URL was accessed/recorded, location data indicating the location of the mobile platform such as mobile platform 105 when the adaptive bitrate streaming URL was accessed/recorded (e.g., location information generalized to a cell identifier level, a ZIP+4 data level, etc.), but omitting any personally identifiable information. Similarly, the resulting subscriber data returned by the OSS 135 to the AME server 130 for the adaptive bitrate streaming URL included in the request may include, but is not limited to, demographic data such as age, race, income, education, etc., but omits any personally identifying information.

In the exemplary usage environment 100 of FIG1 , the AME server 130 receives service provider information (e.g., web log information, subscriber data, etc.) determined to correspond to an adaptive bitrate streaming URL provided in a previous request sent by the AME server 130 to the OSS 135. In some examples, the AME server 130 combines media identification information identifying the media accessed using the adaptive bitrate streaming URL with service provider information (e.g., timestamp, location information, and/or other demographic data, etc.) returned by the OSS 135 to determine audience ratings data for monitoring media impressions on mobile platforms. As described above, the AME server 130 can use the previously determined mapping of URL resource identifier information to specific media sources to determine specific media accessed via the adaptive bitrate streaming URL by detecting identification information embedded in or otherwise accompanying the streaming media. By combining the media identification information available to the AME server 130 with provider information provided by the service provider (e.g., via the OSS 135), the resulting viewership data determined by the AME server 130 can not only identify the media corresponding to the media impression monitored on the mobile platform 105, but can also indicate, for example, the time and location of the mobile platform 105 when the media impression occurred, as well as other demographic information characterizing the users exposed to the media impression.

Figures 2A to 2C illustrate an exemplary process for performing media monitoring on a mobile platform using messages associated with adaptive bitrate streaming in the exemplary usage environment 100 of Figure 1. The exemplary process begins in Figure 2A, where the exemplary mobile platform 105 initiates an exemplary message 205 including an adaptive bitrate streaming URL, which is sent to the exemplary streaming server 120 to request delivery of streaming media. In response, the streaming server 120 streams a series of exemplary segments 210 of the requested media to the mobile platform 105. As described above, in adaptive bitrate streaming, the media to be streamed is segmented into segments of a specified duration, such as 10 seconds or some other duration. Thus, a series of adaptive bitrate streaming URLs identifies a series of segments that form a media stream at a resolution corresponding to the duration of the segments (e.g., 10 seconds). In the illustrated examples of Figures 2A-2C, the exemplary OSS 135 also records the content of the messages 205 (represented by the directional line 215 in Figure 2A), such as the adaptive bitrate streaming URL, and other network information such as a timestamp indicating the time when the respective message 205 was recorded, the location of the mobile platform 105 at the time when the message 205 was recorded, etc.

In some examples, the messages 205 correspond to a series of Hypertext Transfer Protocol (HTTP) GET request messages that include respective adaptive bitrate streaming URLs identifying successive message segments forming a media stream to be delivered to the mobile platform 105. Tables 1 and 2 illustrate two exemplary series of adaptive bitrate streaming URLs that may be included in respective series of messages 205 to request different streaming media.

Table 1

Table 2

2B , the example meter 125 detects a message 205 initiated by the mobile platform 105 and including an adaptive bitrate streaming URL. The meter 125 records the adaptive bitrate streaming URL included in the detected message 205 and reports the adaptive bitrate streaming URL (e.g., in real time, at reporting intervals, etc.) to the example AME server 130 represented by the directional line 220 in FIG2B . In some examples, the meter 125 also includes a time or time range associated with each individual adaptive bitrate streaming URL or each group of adaptive bitrate streaming URLs, for example, to indicate a time window during which the adaptive bitrate streaming URLs are collected by the meter 125.

In some examples, the meter 125 is configured to detect the message 205 by (1) filtering or otherwise detecting HTTP GET request messages and/or other messages capable of carrying an adaptive bitrate streaming URL, and (2) detecting the adaptive bitrate streaming URL included in the filtered message. In some examples, the meter 125 is configured to detect the adaptive bitrate streaming URL by parsing or otherwise searching the content of the detected HTTP GET request message for keywords, text strings, etc. that indicate a URL format used by an adaptive bitrate streaming protocol such as HLS, DASH, Smooth Streaming, etc. For example, referring to Tables 1 and 2, the meter 125 can be configured to search for keywords and/or text strings such as "segmentN.ts" (where "N" is an integer), ".ts.prdy", etc. in the URL included in the detected HTTP GET request message to determine a URL corresponding to the adaptive bitrate streaming URL. Additionally or alternatively, the meter 125 may be configured to detect adaptive bitrate streaming URLs by searching for a pattern of URLs in consecutive detection messages that indicates a pattern associated with adaptive bitrate streaming. For example, if the URLs point to a common domain name, share similar path data, and are separated in time by a duration consistent with the adaptive bitrate streaming protocol, the meter 125 may determine that a series of URLs included in a corresponding series of detected messages corresponds to adaptive bitrate streaming URLs.

2C , the example AME server 130 sends a request 225 to the example OSS 135 to request provider information, such as web log information, subscriber demographic data, and the like, corresponding to the adaptive bitrate streaming URL included in the request 225. The adaptive bitrate streaming URL included in the request 225 may correspond to a series of URLs collected for a mobile platform, such as the mobile platform 105, or multiple series of URLs collected for a group of mobile platforms. The OSS 135 uses the adaptive bitrate streaming URL included in the request 225 and any timing data provided by the AME server 130 to query the web log server 140 for web log information corresponding to the adaptive bitrate streaming URL, such as a timestamp (which may be more accurate than any timing data provided by the AME server in the request 225), location information, and the like. In some examples, in response to the query, the OSS 135 also uses the adaptive bitrate streaming URL included in the request 225 and/or the web log information retrieved from the web log server 140 to query the subscriber database server 145 for subscriber demographic data corresponding to the adaptive bitrate streaming URL. The OSS 135 then sends a request 230 to the AME server 130 that includes provider data, such as retrieved web log information (e.g., timestamp, location data, etc.) and/or subscriber demographic data, corresponding to the adaptive bitrate streaming URL included in the request 225. In some examples, the OSS 135 processes the web log information retrieved from the web log server 140 and/or the subscriber demographic data retrieved from the subscriber database server 145 to omit personally identifiable data before including the web log information and/or subscriber demographic data in the response 230 that is sent to the AME server 130. The AME server 130 then uses the provider information included in the response 230 to monitor media impressions on the mobile platform 105 and determine relevant audience ratings data.

FIG3 illustrates a block diagram of a second exemplary use environment 300 that includes a second exemplary audience measurement system 302 for performing media monitoring on a mobile platform using messages associated with adaptive bitrate streaming as described herein. The second exemplary use environment 300 includes many of the same elements as the use environment 100 of FIG1 and FIG2A through FIG2C . Likewise, identical elements in FIG1 and FIG3 are labeled with the same reference numerals. Detailed descriptions of these identical elements are provided above in conjunction with the discussion of FIG1 and FIG2A through FIG2C and, for the sake of brevity, are not repeated in the discussion of FIG3 .

3 , an exemplary usage environment 300 includes the exemplary mobile platform 105 of FIG. 1 , the exemplary access network 110, the Internet 115, the exemplary media streaming server 120, the exemplary OSS 135, the exemplary weblog server 140, and the exemplary subscriber database server 145. An exemplary audience measurement system 302 included in the exemplary usage environment 300 of FIG. 3 also includes the exemplary AME server 130 of FIG. These elements are described above in conjunction with the descriptions of FIG. 1 and FIG. 2A through FIG. 2C . However, instead of including a meter 125 for monitoring the mobile platform 105, the exemplary audience measurement system 302 included in the exemplary usage environment 300 of FIG. 3 includes an exemplary proxy server 325 to detect the message 205 initiated by the mobile platform 105 and including an adaptive bitrate streaming URL to be used for media monitoring. In the example shown in FIG. 3 , the mobile platform 105 is configured to access the Internet 115 (or other network) via the proxy server 325. Certain exemplary techniques for configuring a mobile platform 105 to access the Internet 115 (or other network) via a proxy server 325 are described in U.S. Patent Publication No. 2012/0042005, U.S. Patent Publication No. 2012/0042367, and U.S. Patent No. 8,594,617, which are hereby incorporated by reference in their entireties. The proxy server 325 detects messages 205 from the mobile platform 105 and/or other mobile platforms configured to access the Internet 115 (or other network) via the proxy server 325, logs the detected messages 205, and reports the adaptive bitrate streaming URLs to the exemplary AME server 130 (e.g., in real time, at a reporting interval, etc.). In some examples, the proxy server 325 also includes a time or time range associated with an individual adaptive bitrate streaming URL or a group of adaptive bitrate streaming URLs to, for example, indicate a time window during which the proxy server 325 collects the adaptive bitrate streaming URLs.

In some examples, the proxy server 325 is configured to detect the message 205 by (1) filtering or otherwise detecting HTTP GET request messages and/or other messages capable of carrying an adaptive bitrate streaming URL, and (2) detecting the adaptive bitrate streaming URL included in the filtered message. Similar to the exemplary meter 125, in some examples, the proxy server 325 is configured to detect the adaptive bitrate streaming URL by parsing or otherwise searching the content of the detected HTTP GET request message for keywords, text strings, etc. that indicate a URL format used by an adaptive bitrate streaming protocol such as HLS, DASH, Smooth Streaming, etc. For example, referring to Tables 1 and 2, the proxy server 325 can be configured to search for keywords and/or text strings such as "segmentN.ts" (where "N" is an integer), ".ts.prdy", etc. in the URL included in the detected HTTP GET request message to determine a URL corresponding to the adaptive bitrate streaming URL. Additionally or alternatively, similar to the meter 125, the proxy server 325 can be configured to detect adaptive bitrate streaming URLs by searching for patterns of URLs in consecutive detection messages that indicate a pattern associated with adaptive bitrate streaming. For example, if the URLs point to a common domain name, share similar path data, and/or are separated in time by a duration consistent with the adaptive bitrate streaming protocol, the proxy server 325 can determine that a series of URLs included in a corresponding series of detected messages corresponds to adaptive bitrate streaming URLs.

While exemplary mobile platform media monitoring schemes have been disclosed herein in the context of exemplary usage environments 100 and 300, these schemes are not limited thereto. For example, a system for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming, as disclosed herein, may include any number and/or type of mobile platforms 105, access networks 110, the Internet and/or other networks 115, media streaming servers 120, OSSs 135, network log servers 140, and/or subscriber database servers 145. Additionally or alternatively, a system for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming, as disclosed herein, may include multiple AME servers, such as different servers configured to monitor different access networks 110 and, thereby, to connect to different OSSs 135. Additionally or alternatively, the system for performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming as disclosed herein may include: one or more meters 125, one or more proxy servers 325, and/or any combination thereof to collect adaptive bitrate streaming URLs corresponding to different media streamed to different mobile platforms. Furthermore, performing media monitoring for a mobile platform using messages associated with adaptive bitrate streaming as disclosed herein is not limited to using wireless access networks, but can utilize any type of access network that maintains network log information and/or subscriber demographic data.

FIG4 illustrates a block diagram of an exemplary implementation of a meter 125 included in the exemplary usage environment 100 of FIG1 and FIG2A through FIG2C. For convenience and without loss of generality, the meter 125 of FIG4 is described in the context of monitoring an exemplary mobile platform 105 in the exemplary usage environment 100 of FIG1 and FIG2A through FIG2C. The exemplary meter 125 of FIG4 includes an exemplary message detector 405 to detect messages including an adaptive bitrate streaming URL, such as the exemplary message 205 initiated by the mobile platform 105. In some examples, the message detector 405 detects the message 205 by initially filtering messages originated at the mobile platform 105 (e.g., messages prepared to be sent by the mobile platform 105) to identify those candidate messages, such as HTTP GET messages, that may include an adaptive bitrate streaming URL. For example, the message detector 405 can be configured to monitor a protocol call stack implemented on the mobile platform 105, such as a Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack, and/or monitor one or more network interfaces of the mobile platform 105, etc., to capture and filter (e.g., identify) candidate messages prepared for transmission by the mobile platform 105, such as HTTP GET messages.

In some examples, the message detector 405 then processes the filtered candidate messages to detect adaptive bitrate streaming URLs included in the messages. For example, as described above, the message detector 405 can be configured to detect adaptive bitrate streaming URLs by parsing or otherwise searching the content of candidate messages, such as HTTP GET messages, initiated by the mobile platform 105 for keywords, text strings, etc., that indicate a URL format used by an adaptive bitrate streaming protocol, such as HLS, DASH, Smooth Streaming, etc. Additionally or alternatively, the message detector 405 can be configured to detect adaptive bitrate streaming URLs by searching for a pattern of URLs in consecutive candidate messages that indicates a pattern associated with adaptive bitrate streaming. For example, as described above, if the URLs point to a common domain name, share similar path data, and/or are separated in time by a duration consistent with an adaptive bitrate streaming protocol, the message detector 405 can determine that a series of URLs included in a corresponding series of candidate messages, such as HTTP GET messages, initiated by the mobile platform 105 correspond to adaptive bitrate streaming URLs.

The example meter 125 of FIG4 also includes an example URL reporter 410 to record the adaptive bitrate streaming URLs detected by the message detector 405. For example, the URL reporter 410 can store the detected adaptive bitrate streaming URLs in volatile and/or non-volatile memory, storage, etc., such as the example volatile memory 1214, the example non-volatile memory 1216, and/or the example mass storage device 1228, included in the example processor platform 1200 of FIG12. The URL reporter 410 of the illustrated example also reports the recorded adaptive bitrate streaming URLs to, for example, the AME server 130. For example, the URL reporter 410 can report the recorded adaptive bitrate streaming URLs in real time, at a reporting interval, when a storage threshold is met, or via any combination of these techniques. In some examples, the URL reporter 410 also includes a time or time range associated with the respective individual adaptive bitrate streaming URL or the respective group of adaptive bitrate streaming URLs in the information reported to the AME server 130 to indicate, for example, a time window during which different adaptive bitrate streaming URLs or groups of URLs were collected by the meter 125.

FIG5 illustrates a block diagram of an exemplary implementation of a proxy server 325 included in the exemplary usage environment 300 of FIG3. For convenience and without loss of generality, the proxy server 325 of FIG5 is described in the context of collecting and reporting adaptive bitrate streaming URLs included in messages sent by a mobile platform, such as the exemplary mobile platform 105, in the exemplary usage environment 300 of FIG3. The exemplary proxy server 325 of FIG5 includes an exemplary message detector 505 to detect messages, such as the exemplary message 205, that are originated by a mobile platform, such as the mobile platform 105, and that include an adaptive bitrate streaming URL. In some examples, the message detector 505 detects the message 205 by initially filtering messages originated by and received from a mobile platform, such as the mobile platform 105, to identify candidate messages, such as HTTP GET messages, that may include an adaptive bitrate streaming URL.

In some examples, the message detector 505 then processes the filtered candidate messages to detect adaptive bitrate streaming URLs included in the messages. For example, as described above, the message detector 505 can be configured to detect adaptive bitrate streaming URLs by parsing or otherwise searching the content of candidate messages, such as HTTP GET messages, initiated by and received from a mobile platform, such as mobile platform 105, for keywords, text strings, or the like that indicate a URL format used by adaptive bitrate streaming protocols, such as HLS, DASH, Smooth Streaming, and the like. Additionally or alternatively, the message detector 505 can be configured to detect adaptive bitrate streaming URLs by searching for patterns of URLs in consecutive candidate messages that indicate a pattern associated with adaptive bitrate streaming. For example, as described above, if the URLs point to a common domain name, share similar path data, and/or are separated in time by a duration consistent with an adaptive bitrate streaming protocol, the message detector 505 can determine that a series of URLs included in a corresponding series of candidate messages, such as HTTP GET messages, initiated by and received from a mobile platform, such as mobile platform 105, correspond to adaptive bitrate streaming URLs.

The example proxy server 325 of FIG4 also includes an example URL reporter 510 to record the adaptive bitrate streaming URLs detected by the message detector 505. For example, the URL reporter 510 can include the detected adaptive bitrate streaming URLs in volatile and/or non-volatile memory, storage, etc., such as the example volatile memory 1214, the example non-volatile memory 1216, and/or the example mass storage device 1228, in the example processor platform 1200 of FIG12. The URL reporter 510 of the illustrated example also reports the recorded adaptive bitrate streaming URLs to, for example, the AME server 130. For example, the URL reporter 510 can report the recorded adaptive bitrate streaming URLs in real time, at a reporting interval, when a storage threshold is met, or any combination thereof. In some examples, the URL reporter 510 also includes a time or time range associated with the respective individual adaptive bitrate streaming URL or the respective group of adaptive bitrate streaming URLs in the information reported to the AME server 130, e.g., to indicate a time window for collecting different adaptive bitrate streaming URLs or groups of URLs by the proxy server 325.

FIG6 illustrates a block diagram of an example implementation of the AME server 130 included in the example usage environments 100 and/or 300 of FIG1 and FIG3, respectively. The example AME server 130 of FIG6 includes an example URL collector 605 to collect (e.g., receive and store) adaptive bitrate streaming URLs reported by meters such as the example meter 125 and/or proxy servers such as the example proxy server 325 operating in the example usage environments 100 and/or 300. For example, the URL collector 605 can store the reported adaptive bitrate streaming URLs, along with any time and/or time range reported with the URL, in volatile and/or non-volatile memory, storage, etc., such as the example volatile memory 1214, the example non-volatile memory 1216, and/or the example mass storage device 1228, included in the example processor platform 1200 of FIG12.

The example AME server 130 of FIG6 also includes an example provider data requester 610 for requesting information, such as web log information, subscriber demographic data, etc., corresponding to the adaptive bitrate streaming URLs collected by the URL collector 605 from one or more service providers. In some examples, the provider data requester 610 sends a request, such as the example request 225, to an OSS of a service provider, such as the example OSS 135, that includes the adaptive bitrate streaming URLs for which provider information is requested. The adaptive bitrate streaming URLs can correspond to one or more URLs (e.g., a series of URLs) collected for a mobile platform, such as the mobile platform 105, or for multiple mobile platforms monitored by the AME server 130. In some examples, the request 225 sent by the provider data requester 610 also includes time and/or time range information associated with the adaptive bitrate streaming URLs for which provider information is requested. In response to the request 225, the provider data requester 610 receives a response, such as the exemplary response 230, that includes provider information, such as retrieved web log information (e.g., timestamps, location data, etc.), and/or subscriber demographic data corresponding to the adaptive bitrate streaming URL included in the request 225. In some examples, the provider information included in the response 230 received by the provider data requester 610 omits personally identifying information to protect the privacy of the service provider's customers.

The exemplary AME server 130 of FIG6 also includes an exemplary media identifier 615 to identify specific media associated with the adaptive bitrate streaming URLs collected by the URL collector 605. In some examples, as described above, the media identifier 615 maintains a database and/or other storage mechanism capable of linking resource identifier information (e.g., domain name and path information) in the URL to different source media. For example, the media identifier 615 can determine resource identifier information for different source media accessible from the streaming server 120 (and/or other streaming servers) via information reported and updated by the operator of the streaming server 120 (and/or other streaming servers), such as Netflix, Hulu, Amazon, etc. Additionally or alternatively, the AME server 130 can determine the specific source media linked to the adaptive bitrate streaming URLs collected by the URL collector 605 by accessing the source media addressed by the specific resource identifier and identifying the media using any appropriate media identification technology (such as one or more watermark-based technologies, signature-based technologies, etc.).

6 includes an example ratings monitor 620 to combine the vendor data obtained by the vendor data requester 610 and the media identification data obtained by the media identifier 615 to determine ratings data characterizing media impressions on, for example, a mobile platform, such as the mobile platform 105. In some examples, the ratings monitor 620 combines the media identification information determined by the media identifier 615 for one or a group of adaptive bitrate streaming URLs collected by the URL collector 605 with the vendor information (e.g., timestamps, location data, subscriber demographic data, etc.) obtained by the vendor data requester 610 for the same adaptive bitrate streaming URL or group of URLs to monitor media impressions associated with the mobile platform, such as the mobile platform 105. In some examples, the ratings monitor 620 determines ratings data for each collected adaptive bitrate streaming URL, such that the ratings data has a temporal resolution corresponding to the duration of the media segments associated with each URL (e.g., such as 10 seconds or some other duration).

For example, for an adaptive bitrate streaming URL or a set of URLs collected by URL collector 605 for mobile platform 105, ratings monitor 620 may use the media identification information obtained by media identifier 615 to identify the media associated with the adaptive bitrate streaming URL. In this example, ratings monitor 620 may use a timestamp included in the vendor information obtained by vendor data requester 610 to determine a time (or time range) corresponding to when a particular segment of the identified media was provided to and/or rendered by mobile platform 105. Additionally or alternatively, ratings monitor 620 may use location data included in the vendor information obtained by vendor data requester 610 to determine the location of mobile platform 105 at the time when the particular segment of the identified media was provided to and/or rendered by mobile platform 105. Additionally or alternatively, ratings monitor 620 may use subscriber demographic data included in the vendor information obtained by vendor data requester 610 to determine demographic data of users exposed to the identified media rendered by mobile platform 105. In some examples, the ratings monitor 620 also combines ratings data determined for an individual mobile platform, such as mobile platform 105, with other mobile platforms and/or other media presentation devices (e.g., such as televisions, desktop computers, gaming consoles, etc.) to determine aggregate ratings data for one or more audience measurement campaigns.

FIG7 illustrates a block diagram of an exemplary implementation of an OSS 135 included in the exemplary usage environments 100 and/or 300 of FIG1 and FIG3 , respectively. The exemplary OSS 135 of FIG7 includes the exemplary network server 140 and the exemplary subscriber database server 145 described above in conjunction with the description of FIG1 through FIG3 . The exemplary OSS 135 of FIG7 also includes an exemplary AME request interface 705 for receiving a request from an AME server, such as the exemplary AME server 130, for provider information (e.g., web log information, subscriber demographic data, etc.) corresponding to an adaptive bitrate streaming URL specified in a request, such as the exemplary request 225. As described above, the adaptive bitrate streaming URL specified in the request may be associated with one or more different mobile platforms. The AME request interface 705 also returns a response, such as the exemplary response 230, including the requested provider information to the requesting AME server. The AME request interface 705 may be implemented via a suitable type and/or number of network and/or data interfaces, such as the exemplary interface circuit 1220 of FIG12 .

The example OSS 135 of FIG7 also includes an example server queryer 710 for querying vendor servers, such as the network server 140 and the subscriber database server 145, to retrieve vendor information corresponding to the adaptive bitrate streaming URL included in a request received via the AME request interface 705. In some examples, the server queryer 710 uses the content of the adaptive bitrate streaming URL to query the web log server 140 to retrieve web log information stored in the web log server 140 and associated with the provided URL content. For example, in response to receiving the adaptive bitrate streaming URL in a query from the server queryer 710, the web log server 140 may discover stored web log records that include a matching adaptive bitrate streaming URL. The web log server 140 may then return other network information in response to the query, such as a timestamp for a matching log entry, a mobile platform identifier identifying a specific mobile platform associated with the matching log entry, and mobile platform location data included in the matching log entry.

In some examples, the server query 710 may additionally or alternatively query the subscriber database server 145 using the content of the adaptive bitrate streaming URL and/or the web log information obtained from the web log server 140 for the adaptive bitrate streaming URL to retrieve subscriber data stored in the subscriber database server 145 and associated with the URL. For example, in response to receiving a query from the server query 710 that includes a mobile platform identifier indicated by the web log information associated with the adaptive bitrate streaming URL, the subscriber database server 145 may find a subscriber database entry that includes a matching mobile platform identifier. The subscriber database server 145 may then return other subscriber demographic data, such as the subscriber's address, the subscriber's age, the subscriber's gender, the subscriber's race, the subscriber's income, the subscriber's education level, the subscriber's subscribed service level, etc., in response to the query.

The example OSS 135 of FIG7 includes an example provider data reporter 715 to process provider information, such as web log information, and/or subscriber demographic data retrieved by the server query 710, in response to a query received by the AME request interface 705 before returning the provider information to an AME server, such as the AME server 130. In some examples, the provider data reporter 715 processes the web log information and/or subscriber demographic data retrieved by the server query 710 to omit any personally identifiable information, such as the subscriber's name, the subscriber's address, the subscriber's customer/subscriber identification number, etc., thereby protecting the privacy of the service provider's customers/subscribers. The provider data reporter 715 then includes the processed provider information in one or more responses, such as the response 230, to be returned to the requesting AME server via the AME request interface 705.

Although Figures 1-7 illustrate example ways of implementing example audience measurement systems 102 and 302, one or more elements, processes, and/or devices shown in Figures 1-7 may be combined, divided, rearranged, omitted, deleted, and/or implemented in any other manner. Furthermore, the exemplary mobile platform 105, the exemplary access network 110, the Internet 115, the exemplary streaming server 120, the exemplary meter 125, the exemplary AME server 130, the exemplary OSS 135, the exemplary web log server 140, the exemplary subscriber database server 145, the exemplary proxy server 325, the exemplary message detector 405, the exemplary URL reporter 410, the exemplary message detector 505, the exemplary URL reporter 510, the exemplary URL collector 605, the exemplary vendor data requester 610, the exemplary media identifier 615, the exemplary ratings monitor 620, the exemplary AME request interface 705, the exemplary server queryer 710, the exemplary vendor data reporter 715, and/or more generally the exemplary system 102 and/or the exemplary system 302 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the exemplary mobile platform 105, the exemplary access network 110, the Internet 115, the exemplary streaming server 120, the exemplary meter 125, the exemplary AME server 130, the exemplary OSS 135, the exemplary web log server 140, the exemplary subscriber database server 145, the exemplary proxy server 325, the exemplary message detector 405, the exemplary URL reporter 410, the exemplary message detector 505, the exemplary URL reporter 510, the exemplary URL collector 605, the exemplary vendor data requester 610, the exemplary media identifier 615, the exemplary ratings monitor 620, the exemplary AME request interface 705, the exemplary server queryer 710, the exemplary vendor data reporter 715, and/or, more generally, the exemplary system 102 and/or the exemplary system 302 can be implemented by one or more analog or digital circuits, logic circuits, programmable processors, application specific integrated circuits (ASICs), programmable logic devices (PLDs), and/or field programmable logic devices (FPLDs). When reading any apparatus or system claim of this patent covering a purely software and/or firmware implementation, it is expressly defined that at least one of the following items: the exemplary system 102, the exemplary system 302, the exemplary mobile platform 105, the exemplary access network 110, the Internet 115, the exemplary streaming server 120, the exemplary meter 125, the exemplary AME server 130, the exemplary OSS 135, the exemplary web log server 140, the exemplary subscriber database server 145, the exemplary proxy server 325, the exemplary message detector 405, the exemplary URL reporter 410, the exemplary message detector 505, the exemplary URL reporter 510, the exemplary URL collector 605, the exemplary vendor data requester 610, the exemplary media identifier 615, the exemplary ratings monitor 620, the exemplary AME request interface 705, the exemplary server queryer 710 and/or the exemplary vendor data reporter 715 include a tangible computer-readable storage device or storage disk storing software and/or firmware, such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. Furthermore, exemplary systems 102 and/or 302 may include one or more elements, processes, and/or devices in addition to or in place of those shown in Figures 1-7, and/or may include more than one of any or all of the shown elements, processes, and devices.

8-11 illustrate flow diagrams representing example machine-readable instructions for implementing the example system 102, the example system 302, the example mobile platform 105, the example access network 110, the Internet 115, the example streaming server 120, the example meter 125, the example AME server 130, the example OSS 135, the example web log server 140, the example subscriber database server 145, the example proxy server 325, the example message detector 405, the example URL reporter 410, the example message detector 505, the example URL reporter 510, the example URL collector 605, the example vendor data requester 610, the example media identifier 615, the example ratings monitor 620, the example AME request interface 705, the example server queryer 710, and/or the example vendor data reporter 715. In these examples, the machine-readable instructions comprise one or more programs executed by a processor, such as the processor 1212, shown in the example processor platform 1200 described below in conjunction with FIG. One or more programs or portions thereof may be embodied in software stored on a tangible computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), Blu-ray Disc ^™ , or on a memory associated with processor 1212, but the entire program or programs and/or portions thereof may alternatively be executed by a device other than processor 1212 and/or embodied in firmware or dedicated hardware (e.g., implemented by an ASIC, PLD, FPLD, discrete logic, etc.). In addition, one or more machine-readable instructions represented by the flowcharts of Figures 8 to 11 may be implemented manually. 8-11 , various other methods of implementing the exemplary system 102, the exemplary system 302, the exemplary mobile platform 105, the exemplary access network 110, the Internet 115, the exemplary streaming server 120, the exemplary meter 125, the exemplary AME server 130, the exemplary OSS 135, the exemplary web log server 140, the exemplary subscriber database server 145, the exemplary proxy server 325, the exemplary message detector 405, the exemplary URL reporter 410, the exemplary message detector 505, the exemplary URL reporter 510, the exemplary URL collector 605, the exemplary vendor data requester 610, the exemplary media identifier 615, the exemplary ratings monitor 620, the exemplary AME request interface 705, the exemplary server queryer 710, and/or the exemplary vendor data reporter 715 may alternatively be used. For example, with reference to the flowcharts shown in FIG8-11 , the order of execution of the blocks may be changed, and/or some of the blocks may be changed, deleted, combined, and/or divided into multiple blocks.

As described above, the exemplary processes of Figures 8 to 11 can be implemented using encoded instructions (e.g., computer and/or machine-readable instructions) stored on a tangible computer-readable storage medium such as a hard drive, flash memory, read-only memory (ROM), compact disk (CD), digital versatile disk (DVD), cache, random access memory (RAM), and/or any other storage device or storage disk that stores information for any duration (e.g., for an extended period of time, permanently, simply for temporary buffering and/or for caching of information). As used herein, the term "tangible computer-readable storage medium" is expressly defined to include any type of computer-readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, "tangible computer-readable storage medium" and "tangible machine-readable storage medium" are used interchangeably. Additionally or alternatively, the exemplary processes of Figures 8 to 11 may be implemented using encoded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard drive, flash memory, ROM, CD, DVD, cache, RAM, and/or a storage device or storage disk that stores information for any duration (e.g., an extended period of time, permanently, briefly, for temporary buffering and/or for caching of information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk, and excludes propagating signals and excludes transmission media. As used herein, when the phrase "at least" is used as a transition term in the preamble of a claim, it is also open ended in the same manner as the term "comprising" is open ended. Furthermore, as used herein, the terms "computer readable" and "machine readable" are considered equivalent unless otherwise indicated.

An example program 800 including example machine-readable instructions that can be executed to implement the example meter 125 of Figures 1, 2A-2C, and/or 4 is illustrated by the flowchart shown in Figure 8. For convenience and without loss of generality, execution of the example program 800 is described in the context of the example meter 125 of Figure 4 monitoring the example mobile platform 105 in the example usage environment 100 of Figures 1 and 2A-2C. With reference to the aforementioned figures and associated text, the example program 800 of Figure 8 begins execution at block 805. As described above, at block 805, the example message detector 405 of the meter 125 monitors messages, such as HTTP messages, that are initiated by and to be sent from the mobile platform 105. At block 810, as described above, the message detector 405 detects one or more messages associated with adaptive bitrate streaming, such as HTTP GET messages, that include an adaptive bitrate streaming URL. At block 815, as described above, the example URL reporter 410 included in the meter 125 records the adaptive bitrate streaming URL included in the message detected at block 810. At block 820, the URL reporter 410 reports the adaptive bitrate streaming URL recorded at block 815 to an AME server, such as the AME server 130. If the mobile platform 105 is to continue monitoring (block 825), the processing at blocks 805-820 is repeated. Otherwise, execution of the example program 800 ends.

The flowchart shown in FIG9 illustrates an example program 900 including example machine-readable instructions that can be executed to implement the example proxy server 325 of FIG3 and/or FIG5 . For convenience and without loss of generality, execution of the example program 900 is described in the context of the example proxy server 325 of FIG5 operating within the example usage environment 300 of FIG3 . Referring to the aforementioned figures and associated text, the example program 900 of FIG9 begins execution at block 905 (as described above, the example message detector 505 of the proxy server 325 monitors messages, such as HTTP messages, received from a mobile platform, such as the mobile platform 105 ). At block 910, as described above, the message detector 505 detects one or more messages associated with adaptive bitrate streaming, such as an HTTP GET message including an adaptive bitrate streaming URL. At block 915, as described above, the example URL reporter 510 included in the proxy server 325 records the adaptive bitrate streaming URL included in the message detected at block 910 . At block 920, URL reporter 510 reports the adaptive bitrate streaming URL recorded at block 915 to an AME server, such as AME server 130. If monitoring of messages is to continue (block 925), the processing at blocks 905-920 is repeated. Otherwise, execution of exemplary program 900 ends.

FIG10 is a flowchart illustrating an exemplary program 1000 including exemplary machine-readable instructions that may be executed to implement the exemplary AME server 130 of FIG1 through FIG3 and/or FIG6. For convenience and without loss of generality, execution of the exemplary program 1000 is described in the context of the exemplary AME server 130 of FIG6 operating within the exemplary usage environments 100 and/or 300 of FIG1 through FIG3. Referring to the aforementioned figures and associated text, the exemplary program 1000 of FIG10 begins execution at block 1005 (as described above, the exemplary URL collector 605 of the AME server 130 collects monitored adaptive bitrate streaming URLs reported by a meter, such as the exemplary meter 125, and/or a proxy server, such as the exemplary proxy server 325, operating within the exemplary usage environments 100 and/or 300). At block 1010, the URL collector 605 accesses one or more collected adaptive bitrate streaming URLs and provides the URLs to the exemplary vendor data requester 610 of the AME server 130, which includes the adaptive bitrate streaming URLs or their contents in one or more requests for vendor information sent to an OSS of a service provider, such as the exemplary OSS 135, as described above. At block 1015, the vendor data requester 610 receives one or more responses from the OSS of the service provider, such as the exemplary OSS 135, that include vendor data (such as web log information, subscriber demographic data) corresponding to the adaptive bitrate streaming URLs (which were the subject of the request sent at block 1010). At block 1020, the exemplary ratings monitor 620 of the AME server 130 determines ratings data (as described above) to monitor the presentation of media (e.g., media impressions) on a mobile platform, such as the mobile platform 105, in the usage environment 100 and/or 300 using the vendor data received at block 1015. For example, as described in more detail above, the ratings monitor 620 may combine the provider data received at block 1015 with the media identification data determined by the example media identifier 615 included in the AME server 130 to determine the ratings data at block 1020. If monitoring is to continue (block 1025), the processing at blocks 1005-1020 is repeated. Otherwise, execution of the example program 1000 ends.

FIG11 is a flowchart illustrating an example program 1100 including example machine-readable instructions that may be executed to implement the example OSS 135 of FIG1 through FIG3 and/or FIG7. For convenience and without loss of generality, execution of the example program 1100 is described with the example OSS 135 of FIG7 operating within the example usage environments 100 and/or 300 of FIG1 through FIG3. With reference to the aforementioned figures and associated text, the example program 1100 of FIG11 begins execution at block 1105 (as described above, the example AME request interface 705 of the OSS 135 receives one or more requests from an AME server, such as the AME server 130, for service provider data corresponding to the adaptive bitrate streaming URL specified in the request). At block 1110, as described above, the example server queryer 710 of the OSS 135 queries the example web log server 140 of the OSS 135 for network information corresponding to the adaptive bitrate streaming URL specified in the request received at block 1105). At block 1115, as described above, the server queryer 710 queries the example subscriber database server 145 of the OSS 135 for subscriber demographic data corresponding to the adaptive bitrate streaming URL specified in the request received at block 1105. As described above, the request received at block 1105 may include a time and/or time range associated with the specified adaptive bitrate streaming URL, which can be used to focus the query of the weblog server 140 and/or user database server 145. At block 1120, the example provider data reporter 715 processes the weblog information retrieved at block 1110 and/or the subscriber demographic data retrieved at block 1115 to omit personal information, thereby protecting the privacy of the service provider's customers/subscribers. At block 1125, the provider data reporter 715 returns the resulting service provider information determined at block 1120 to the requesting AME server in one or more responses sent via the AME request interface 705. Execution of the example process 1100 then ends.

Figure 12 is a block diagram of an exemplary processor platform 1200, which is capable of executing instructions of Figures 8 to 11 to implement the system 102 of Figures 1 to 7, the exemplary system 302, the exemplary mobile platform 105, the exemplary access network 110, the Internet 115, the exemplary streaming server 120, the exemplary meter 125, the exemplary AME server 130, the exemplary OSS 135, the exemplary web log server 140, the exemplary subscriber database server 145, the exemplary proxy server 325, the exemplary message detector 405, the exemplary URL reporter 410, the exemplary message detector 505, the exemplary URL reporter 510, the exemplary URL collector 605, the exemplary vendor data requester 610, the exemplary media identifier 615, the exemplary ratings monitor 620, the exemplary AME request interface 705, the exemplary server queryer 710 and/or the exemplary vendor data reporter 715. Processor platform 1200 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad ^™ ), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, a digital camera, or any other type of computing device.

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

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

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

In the example shown, one or more input devices 1222 are connected to the interface circuit 1220. The input devices 1222 allow a user to input data and commands to the processor 1212. The input devices can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a track pad, a track ball, a track bar (such as isopoint), a voice recognition system, and/or any other human-computer interface. In addition, various systems such as the processor platform 1200 can allow a user to control a computer system and provide data to a computer using physical gestures such as, but not limited to, hand or body movements, facial expressions, and face recognition.

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

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

The processor platform 1200 of the illustrated example also includes one or more mass storage devices 1228 for storing software and/or data. Examples of such mass storage devices 1228 include floppy disk drives, hard drive disks, optical disk drives, Blu-ray disk drives, RAID (Redundant Array of Independent Disks) systems, and Digital Versatile Disk (DVD) drives.

The encoded instructions 1232 corresponding to the instructions of Figures 8 to 11 can be stored in mass storage 1228, in volatile memory 1214, in non-volatile memory 1216, in local memory 1213 and/or on a removable tangible computer-readable storage medium such as a CD or DVD 1236.

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

Claims (24)

1. A method for monitoring media on a mobile platform, the method comprising: The processor of a first server accesses a first adaptive bitrate streaming Uniform Resource Locator URL (URL) collected by a meter running on the mobile platform from a first message to be sent by the mobile platform to a second server, in order to stream the first media according to an adaptive bitrate streaming protocol. The first adaptive bitrate streaming URL is received by the first server in a report sent from the meter running on the mobile platform. The first server is different from the second server. The mobile platform sends the first message including the first adaptive bitrate streaming URL to the second server to stream the first media. The processor requests network log information corresponding to the first adaptive bitrate streaming URL from the service provider providing network access to the mobile platform; and The processor uses the network log information to monitor the presentation of the first media on the mobile platform. 2. The method according to claim 1, wherein the network log information includes at least one of the following: a timestamp corresponding to the time when the first message including the first adaptive bitrate streaming URL was recorded by the service provider, or location information specifying the location of the mobile platform at the time when the first message including the first adaptive bitrate streaming URL was recorded by the service provider. 3. The method according to claim 1 or 2, further comprising: in response to providing the service provider with the first adaptive bit rate streaming URL, obtaining demographic information in addition to the network log information. 4. The method of claim 3, wherein the network log information and the demographic information omit subscriber-related personal information associated with the mobile platform. 5. The method of claim 1 or 2, wherein the step of requesting the network log information comprises: sending a request including the first adaptive bitrate streaming URL and a time range associated with the time when the first adaptive bitrate streaming URL was detected to the service provider. 6. The method of claim 1 or 2, wherein the step of monitoring the presentation of the first media on the mobile platform comprises: combining the network log information with media identification information associated with the first adaptive bitrate streaming URL. 7. The method according to claim 1 or 2, further comprising: Request network log information from the service provider corresponding to other adaptive bitrate streaming URLs included in subsequent messages initiated by the mobile platform, in order to stream the first media according to the adaptive bitrate streaming protocol; and Using the network log information corresponding to the first adaptive bitrate streaming URL and the network log information corresponding to the other adaptive bitrate streaming URLs, viewership data associated with the presentation of the first media on the mobile platform is determined, the viewership data having a time granularity corresponding to the time interval between media segments of the first media identified by the first message and the subsequent message. 8. The method according to claim 1 or 2, wherein the adaptive bit rate streaming protocol corresponds to at least one of Hypertext Transfer Protocol Real-Time Streaming (HTTP), Dynamic Adaptive Streaming (DASH) based on HTTP, or smooth streaming. 9. A system for monitoring media on a mobile platform, the system comprising: A means for using the processor of a first server to access a first adaptive bitrate streaming Uniform Resource Locator URL collected by a meter running on the mobile platform from a first message to be sent by the mobile platform to a second server, in order to stream a first media according to an adaptive bitrate streaming protocol, wherein the first adaptive bitrate streaming URL is received by the first server in a report sent from the meter running on the mobile platform, the first server being different from the second server, and the mobile platform sending the first message including the first adaptive bitrate streaming URL to the second server to stream the first media; A means for using the processor to request network log information corresponding to the first adaptive bitrate streaming URL from a service provider offering network access to the mobile platform; and A means for using the processor to monitor the presentation of the first media on the mobile platform using the network log information. 10. The system of claim 9, wherein the network log information includes at least one of the following: a timestamp corresponding to the time when the first message including the first adaptive bitrate streaming URL was recorded by the service provider, or location information specifying the location of the mobile platform at the time when the first message including the first adaptive bitrate streaming URL was recorded by the service provider. 11. The system of claim 9 or 10, further comprising: means for obtaining demographic information in addition to the network log information in response to providing the first adaptive bit rate streaming URL to the service provider. 12. The system of claim 11, wherein the network log information and the demographic information omit subscriber-related personal information associated with the mobile platform. 13. The system of claim 9 or 10, wherein the means for requesting the network log information comprises: means for sending a request including the first adaptive bitrate streaming URL and a time range associated with the time when the first adaptive bitrate streaming URL was detected to the service provider. 14. The system of claim 9 or 10, wherein the means for monitoring the presentation of the first media comprises: means for combining the network log information and media identification information associated with the first adaptive bitrate streaming URL. 15. The system according to claim 9 or 10, further comprising: A means for requesting network log information from the service provider corresponding to other adaptive bitrate streaming URLs included in subsequent messages initiated by the mobile platform, in order to stream the first media according to the adaptive bitrate streaming protocol; and A means for determining viewership data associated with the presentation of the first media on the mobile platform using network log information corresponding to the first adaptive bitrate streaming URL and network log information corresponding to the other adaptive bitrate streaming URL, the viewership data having a time granularity corresponding to a time interval between media segments of the first media identified by the first message and the subsequent message. 16. The system according to claim 9 or 10, wherein the adaptive bit rate streaming protocol corresponds to at least one of Hypertext Transfer Protocol Real-Time Streaming (HTTP), Dynamic Adaptive Streaming (DASH) based on HTTP, or smooth streaming. 17. An apparatus for monitoring media on a mobile platform, the apparatus comprising: A Uniform Resource Locator (URL) collector, wherein the URL collector accesses a first server and collects a first adaptive bitrate streaming Uniform Resource Locator URL from a first message to be sent by the mobile platform to a second server, by a meter running on the mobile platform, to stream first media according to an adaptive bitrate streaming protocol, the first adaptive bitrate streaming URL being received by the first server in a report sent from the meter running on the mobile platform, the first server being different from the second server, the mobile platform sending the first message including the first adaptive bitrate streaming URL to the second server to stream the first media; A supplier data requester requests network log information corresponding to the first adaptive bitrate streaming URL from a service provider offering network access to the mobile platform; and A viewership monitor that uses the web log information to monitor the presentation of the first media on the mobile platform. 18. The apparatus of claim 17, wherein the network log information includes at least one of the following: a timestamp corresponding to the time when the first message including the first adaptive bitrate streaming URL was recorded by the service provider, or location information specifying the location of the mobile platform at the time when the first message including the first adaptive bitrate streaming URL was recorded by the service provider. 19. The apparatus of claim 17 or 18, wherein, in response to providing the first adaptive bitrate streaming URL to the service provider, the provider data requester obtains demographic information in addition to the network log information. 20. The apparatus of claim 19, wherein the network log information and the demographic information omit subscriber-related personal information associated with the mobile platform. 21. The apparatus of claim 17 or 18, wherein, in order to request the network log information, the provider data requester further sends a request to the service provider including the first adaptive bitrate streaming URL and a time range associated with the time when the first adaptive bitrate streaming URL was detected. 22. The apparatus of claim 17 or 18, wherein, in order to monitor the presentation of the first media on the mobile platform, the viewership monitor also combines the network log information with media identification information associated with the first adaptive bitrate streaming URL. 23. The apparatus according to claim 17 or 18, wherein: The supplier data requester also requests network log information from the service provider corresponding to other adaptive bitrate streaming URLs included in subsequent messages initiated by the mobile platform, in order to stream the first media according to the adaptive bitrate streaming protocol; and The viewership monitor also uses the network log information corresponding to the first adaptive bitrate streaming URL and the network log information corresponding to the other adaptive bitrate streaming URLs to determine viewership data associated with the presentation of the first media on the mobile platform, the viewership data having a time granularity corresponding to the time interval between media segments of the first media identified by the first message and the subsequent message. 24. The apparatus of claim 17 or 18, wherein the adaptive bit rate streaming protocol corresponds to at least one of Hypertext Transfer Protocol Real-Time Streaming (HTTP), Dynamic Adaptive Streaming (DASH) based on HTTP, or smooth streaming.