HK40020329A

HK40020329A - Methods and apparatus to identify media using hash keys

Info

Publication number: HK40020329A
Application number: HK42020010381.0A
Authority: HK
Inventors: 丹尼尔·纳尔逊
Original assignee: 尼尔森（美国）有限公司
Priority date: 2014-04-07
Filing date: 2020-07-03
Publication date: 2020-10-23

Description

Method and apparatus for identifying media using hash keys

The application is a divisional application of a chinese patent application having an application date of 2014, 12/1, an application number of 201480077840.6 and an invention name of "method and apparatus for identifying media using hash keys".

Technical Field

The present invention relates generally to audience measurement and, more particularly, to a method and apparatus for identifying media using hash keys.

Background

Audience measurement of media (such as television, music, movies, radio, internet websites, streaming media, video games, etc.) is typically conducted by monitoring media exposure of panelists who are selected to represent a particular demographic group. The captured media exposure data is processed using various statistical methods to determine audience size and demographic makeup for the programs of interest. Audience size and demographic information may be valuable to advertisers, broadcasters, and/or other entities. For example, audience size and demographic information may be used as factors in selecting ad impressions, and may be used as factors in evaluating the value of commercial breaks during a particular program.

Drawings

FIG. 1 illustrates an exemplary system constructed in accordance with the teachings of the present invention having a media meter in communication with an audience measurement entity to monitor a media presentation.

FIG. 2 illustrates an exemplary implementation of the reference database of FIG. 1 that may be used to store reference metadata associated with reference hash keys of corresponding media.

Fig. 3 illustrates an example data structure that may be used to store an impression record generated by the example hash key manager of fig. 1.

Fig. 4 illustrates an exemplary implementation of the exemplary reference hash key generator of fig. 1 that may be used to generate the exemplary reference record of fig. 2.

Fig. 5 illustrates an example implementation of the example hash key manager of fig. 1 that may be used to compare metered hash keys to reference hash keys to generate monitoring reports and/or store impressions in a monitoring database.

Fig. 6A and 6B illustrate an example configuration of the example hash key analyzer of fig. 5 to compare a metered hash key to a reference hash key and/or to detect errors in the metered hash key.

FIG. 7 illustrates an exemplary implementation of the exemplary error processor of FIG. 5 for correcting errors in a metered hash key.

FIG. 8 illustrates an example data structure that may be used to store metered hash keys generated by the media meter of FIG. 1 to detect unexpected hash keys.

Fig. 9 is a flow diagram representing example machine readable instructions that may be executed to implement the hash key manager of fig. 1 and/or 5 to compare a metered hash key to a reference hash key.

Fig. 10 is a flow diagram representing example machine readable instructions that may be executed to implement the hash key analyzer of fig. 6A and 6B that compares a metered hash key to a reference hash key.

FIG. 11 is a flowchart representative of example machine readable instructions that may be executed to implement the error handler to recover invalid hash keys of FIG. 7.

Fig. 12A and 12B are flowcharts representative of example machine readable instructions that may be executed to implement the hash key analyzer, error handler, and/or contact creditor of fig. 5, 6A, 6B, and/or 7 comparing metered hash keys to reference hash keys.

Fig. 13 is a flow diagram representing example machine readable instructions that may be executed to implement the reference hash key generator of fig. 1 and/or 4 to generate the reference record of fig. 2.

Fig. 14 is a flow diagram representing example machine readable instructions that may be executed to implement the hash key manager of fig. 1 and 5 to detect and/or correct unexpected hash keys.

Fig. 15 is a block diagram of an example processor system that may execute any of the machine readable instructions represented by fig. 9, 10, 11, 12A, 12B, 13, and/or 14 to implement the apparatus of fig. 1, 4, 5, 6A, 6B, and/or 7.

Detailed Description

Examples disclosed herein may be used to identify media (e.g., movies, music, television programs, radio programs, television advertisements, radio advertisements, video games, etc.) using hash keys associated with the media. Additional exemplary techniques FOR identifying MEDIA using hash keys that may be employed in connection with the examples provided herein are disclosed in U.S. patent application serial No. 14/469,245 entitled "SIGNATURE RETRIEVAL AND MATCHING FOR MEDIA MONITORING," filed on 8/26 2014, which is incorporated herein by reference in its entirety.

To create an indexable identifier for portions of media of interest, in examples disclosed herein, the media is sampled at a particular frequency (e.g., 15Hz, 30Hz, 64Hz, etc.). Hash keys are generated based on samples of media using one or more fingerprinting techniques, such as robust audio hashing. In some robust audio hashing examples, the binary value represents the energy difference between the frequency bands of the sample. In some such examples, the bit length of the hash key corresponds to the number of bands used to create the hash key (e.g., a 64-bit long hash key corresponds to the difference between 65 bands). For example, samples of media may be hashed according to the technique described by Haitsma et al in the article entitled "Robust Audio Hashing for Content Identification". Through the hash key generation process, successive samples of media do not produce successive hash keys. For example, the hash key generated by a first sample of media may be 0x712F, and the hash key generated by the next sample of the media after the first sample (and corresponding to an adjacent segment of the media) may be 0x 003A. In the prior art, the hash key from the previous sample (e.g., temporally prior to the current sample) and the hash key from the next sample (e.g., temporally subsequent to the current sample) cannot be distinguished based on the hash key to which the current sample corresponds.

To generate the reference hash key, the reference version of the media is sampled at a sampling frequency (e.g., 15Hz, 30Hz, 64Hz, etc.). In some examples, the reference media is media of the same or higher quality than the media typically obtained by and/or presented to the user (e.g., songs, television programs, radio programs, video and/or audio spots or clips, advertisements, streaming media, etc.). In some examples, the reference media is free of noise (e.g., white noise, pink noise, brown noise, etc.) and/or uses lossless formats (e.g., Free Lossless Audio Codec (FLAC), waveform audio file format (WAV); video streaming, audio streaming, etc.),Lossless Audio Codec (ALAC), etc.) for storage and/or decoding. For example, a reference version of audio (or reference media) (e.g., collected in a controlled environment such as a recording studio) may be a high-quality, lossless digital copy of a song, whereas a streaming version of the same audio (e.g., measured media) may be due to environmental noise, transmission loss, etcWill generally exhibit lower quality and less accuracy in its reproduction and playback.

In examples disclosed herein, a reference record is constructed by generating a reference hash key for a sample of reference media. Metadata related to the sample (e.g., the name of the corresponding media, the time and/or offset in the media to which the sample corresponds, etc.) is stored in the reference record associated with the reference hash key. In some examples, the hash key corresponding to an adjacent previous (e.g., in time) reference sample and the hash key corresponding to an adjacent subsequent (e.g., in time) sample are also stored in the same reference record associated with the reference hash key and the metadata. Thus, in some examples disclosed herein, a reference record has three reference hash keys stored therein, namely a current hash key (which is the subject or focus of the reference record), an adjacent previous hash key (which corresponds to a sample occurring before (in time) the sample of the current hash key), and an adjacent subsequent hash key (which corresponds to a sample occurring after (in time) the sample of the current hash key).

Although referred to as "adjacent previous reference hash key" and/or "adjacent subsequent reference hash key," in some examples disclosed herein, samples corresponding to adjacent previous reference hash keys and adjacent subsequent reference hash keys need not be contiguous in time with the sample corresponding to the current reference hash key. For example, there may be non-sampled portions of the media between samples corresponding to adjacent previous and current hash keys and/or between a current reference hash key and an adjacent subsequent reference hash key. In some examples, the previous reference hash key and the subsequent reference hash key stored in the reference record associated with the current reference hash key do not correspond to samples immediately adjacent to the sample of the current reference hash key. That is, the samples corresponding to the previous reference hash key and the current reference hash key may have one or more intervening samples in between. Additionally or alternatively, there may be one or more intervening samples between the samples corresponding to the current reference hash key and the subsequent reference hash key. In other examples, there are no intervening samples, and the hash key corresponds to samples that are contiguous in time.

In some examples, an Audience Measurement Entity (AME) contacts and/or recruits panelists using any desired methodology (e.g., random selection, statistical selection, phone call collection, internet advertising, surveys, advertising in shopping centers, product packaging, etc.). When a panelist joins (i.e., registers with) the panel, demographic information (e.g., gender, occupation, salary, ethnicity and/or ethnicity, marital status, highest completed scholarship, current employment status, etc.) is obtained from the panelist. Additionally or alternatively, demographic information may be obtained by other methods during the registration process (e.g., via a telephone meeting, by having a panelist complete an online survey, etc.). In some examples, the AME provides media meters (e.g., set-top box meters, Personal Portable Meters (PPMs), on-device meters, portable media player meters, etc.) to the panelist after the panelist registers in the panelist.

In some examples, a media meter collects metering samples by sampling media from a media source that is within sufficiently close sensing proximity of the meter. For example, a set-top box meter may sample audio from a movie being presented via a media presentation device, such as a television located in the same room as the set-top box meter, or a portable media player meter may sample audio being presented via a media presentation device, such as a portable media player (e.g., an MP3 player, a dvd player, a video recorder, a computer or any combination thereof,Etc.). In some examples, the sample is captured using a microphone of a media meter. In some examples, the media meter obtains metering samples over a wired connection (e.g., to an audio output jack) via a splitter or coaxial configuration by which the media meter intercepts portions of the media as they are communicated between the media source and headphones or the like. In some casesIn an example, a media meter samples media samples at the same frequency as a sampling reference sample. In some examples, the metering samples are sent to a central office of the AME, where metering hash keys are generated based on the metering samples. In some examples, the media meter is provided with a hash key generator to locally generate metered hash keys. In some such examples, the media meter sends the metered hash key to the central office.

In some examples, an error occurs in the media presentation before the media meter samples the media presentation. For example, media is encoded from a lossless format (e.g., Free Lossless Audio Codec (FLAC), waveform audio file format (WAV)),Lossless Audio Codec (ALAC), etc.) to a lossy format (e.g., MPEG audio player III (MP3), Advanced Audio Coding (AAC), Ogg Vorbis, etc.) may change the media sufficiently that a metered hash key generated based on a portion (e.g., a segment) of the media in the lossy format is different from a reference hash key corresponding to a lossless format of the same portion (e.g., the same segment) of the media. Additionally or alternatively, ambient noise and/or attenuation may also introduce errors into the samples of the measured media. The transmission error may also be a source of error in the metered hash key. These sources of noise, loss, and/or error may cause one or more bits of a metered hash key to be different relative to a corresponding reference hash key.

In examples disclosed herein, the AME receives metered hash keys from a media meter and compares the metered hash keys to reference hash keys in a reference hash table. When a metered hash key matches a reference hash key, an impression corresponding to the corresponding media (e.g., the reference media corresponding to the matching reference hash key) is recorded. In some examples, metadata corresponding to the reference hash key is retrieved from the corresponding reference record and stored in association with the impression of the record. In some examples, information associated with one or more panelists (e.g., demographics, panelist Identifiers (IDs), etc.) and/or timestamps indicating times at which metered media was presented are additionally or alternatively stored in association with logged impressions. In some examples, when a metered hash key does not match a reference hash key, the error handler determines whether the metered hash key sufficiently matches (e.g., within a threshold tolerance, such as 90% of the bits of the metered hash key match) a previous reference hash key or a subsequent reference hash key. The error manager of some such examples corrects one or more errors if the metered hash key sufficiently matches the previous reference hash key or the subsequent reference hash key. In some examples, impressions of corresponding portions of the recording media presentation are corrected based on such errors. Otherwise, the metered hash key is discarded.

In some examples, the AME verifies a batch of metered hash keys to correct valid but unexpected hash keys. An unexpected hash key may occur when an error changes a metered hash key to another valid hash key (e.g., the wrong metered hash key is in the reference database, but is associated with a different media presentation that is not meant to correspond to a metered hash key, etc.). Thus, as used herein, an unexpected hash key is a hash key that exists in a reference database, but whose reference metadata does not match a sequence of reference metadata of adjacent metered hash keys (e.g., previous hash keys and/or subsequent hash keys). For example, if the reference metadata for the previous metered hash key is the 245 th sample of a song named "Clarity," it is expected that the hash key will have reference metadata corresponding to the 246 th sample of the song named "Clarity. In this example, if the reference metadata for the current hash key corresponds to the 9681 th sample of the song named "Spectrum," the current hash key will be designated as unexpected. To determine whether the current hash key is unexpected, the current hash key is compared to a reference hash key in the database. If a matching reference hash key is found, the reference metadata stored in association with the matching reference hash key is compared with reference metadata corresponding to an adjacent metered hash key. If the reference metadata corresponding to the current hash key is unexpected (e.g., the corresponding media titles do not match and/or the sample locations are not adjacent), the potential hash key is retrieved from the adjacent metered hash key. An error level is calculated between the current metered hash key and the potential hash key. If the error level satisfies a threshold (e.g., the error level is less than or equal to the threshold), the potential hash key replaces the current metered hash key. In some such examples, this example of unexpected hash keys occurs during a post-processing step (e.g., after the metered hash key has been initially processed).

FIG. 1 illustrates an exemplary media meter 100 (e.g., a set-top box meter, a personal meter, an on-device meter, a portable media player meter, etc.) constructed in accordance with the teachings of the present invention, the exemplary media meter 100 being used to sample exemplary media 102 being output by an exemplary media presentation device 103. The example media meter 100 of fig. 1 generates the example metered hash keys 104. In the illustrated example of FIG. 1, the metered hash keys 104 include a series of metered hash keys (e.g., metered hash keys 104a-104 c). As used herein, a "current metered hash key" refers to a metered hash key in a series of hash keys that is currently being processed. As used herein, a "previous metered hash key" refers to a previous metered hash key that is prior to or adjacent to the current metered hash key. As used herein, a "subsequent metered hash key" refers to a subsequent metered hash key that is subsequent or adjacent to the current metered hash key. Fig. 1 illustrates an example current metered hash key 104a, an example previous metered hash key 104b, and an example next metered hash key 104 c. The current metered hash key 104a, the previous metered hash key 104b, and the subsequent metered hash key 104c are collectively referred to herein as a series of metered hash keys 104.

In the illustrated example, the media meter 100 sends metered hash keys 104 to an Audience Measurement Entity (AME) 106. In some examples, the media meter 100 sends a meter ID 108 (e.g., an alphanumeric value (preferably uniquely) identifying the media meter 100) along with the metered hash key 104. In some examples, a people meter 109 is associated with the media meter 100 to identify people in the audience when collecting the metered hash keys 104. In some examples, people identification data collected by the people meter 109 is returned with the metered hash keys 104 and/or with the meter ID 108. The example media meter 100 communicates with the example AME106 via a wired connection and/or a wireless connection (e.g., a cable/DSL/satellite modem, cell tower, etc.) over an example network 114 (e.g., the internet, a local area network, a wide area network, etc.).

In the illustrated example of fig. 1, the AME106 processes the metered hash keys 104 and, in some examples, the personnel identification information to generate the monitoring report 110. In some examples, the monitoring report 110 includes identity information (e.g., panelist identifiers, demographic information, etc.) corresponding to one or more persons associated with the meter ID 108. In some such examples, the people meter 109 that generates the people recognition information is not employed. In other examples, the identity information is based on people identification information collected by the people meter 109. In some examples, the AME106 maintains a monitoring database 112, the monitoring database 112 including monitoring reports 110 corresponding to one or more meters (e.g., media meters 100).

The AME106 of the illustrated example of fig. 1 includes a hash key manager 116, the hash key manager 116 to process the metered hash keys 104 to correct erroneous metered hash keys and/or to generate the monitoring report 110. The example AME106 also includes a reference database 118 and a reference hash key generator 120. In the illustrated example, the reference hash key generator 120 samples reference media 122 (e.g., media of the same or higher quality than the media obtained by and/or presented to the user) to generate and maintain the reference database 118. In some examples, the reference database 118 is implemented as a hash table that stores the reference hash keys generated by the reference hash key generator 120 as indices of reference records in the hash table. The example AME106 of fig. 1 maintains the example reference database 118 by adding, removing, and/or updating reference hash keys. The hash key manager 116 of the illustrated example of fig. 1 queries the reference database 118 with a metered hash key (e.g., the current metered hash key 104a) to compare the metered hash key to one or more reference hash keys. In addition, the example hash key manager 116 processes and corrects errors in the example metered hash keys 104.

FIG. 2 illustrates an example data structure 200, which example data structure 200 may be generated and/or maintained by the example AME106 (FIG. 1) and stored in the example reference database 118 (FIG. 1). In the illustrated example of fig. 2, the data structure 200 includes a plurality of rows, each row corresponding to a respective reference record 202. The example reference record 202 associates a reference hash key 204 with corresponding reference metadata 206. The reference hash key generator 120 of fig. 1 uses the example reference media 122 (fig. 1) to generate the example reference record 202 of the example of fig. 2. The reference database 118 (fig. 1) stores reference hash keys for a number of media titles. The reference hash key is stored as an in-order numbered value or key in the reference database 118. However, because consecutive samples of a particular reference media typically do not form consecutively numbered reference hash keys in the illustrated example, the reference hash keys to which the consecutive samples correspond are stored in the reference database 118 at locations separated by one or more non-relevant hash keys (e.g., hash keys to which other media correspond). The example reference metadata 206 of fig. 2 contains information related to the identity of the reference media 122 (e.g., title, media identifier, timestamp, sample number, etc.).

In the example shown in fig. 2, the reference record 202 also associates a previous reference hash key 208 and a subsequent reference hash key 210 with the corresponding reference hash key 204. In the illustrated example of fig. 2, the previous reference hash key 206 refers to a previous reference hash key or an adjacent previous reference hash key that corresponds to a sample of the same media 124 that is a previous or adjacent previous sample prior to the sample to which the reference hash key 204 corresponds. In the illustrated example of fig. 2, the subsequent reference hash key 206 refers to a subsequent reference hash key or an adjacent subsequent reference hash key that corresponds to a sample of the same media 124 that is subsequent or adjacent subsequent to the sample to which the reference hash key 204 corresponds. For example, if the reference hash key 204 corresponds to the 2496 th sample of the reference media 122 (e.g., a sample corresponding to playback time 0:39.0000 seconds and collected at a sampling frequency of 64 Hz), the previous reference hash key 208 may correspond to the 2495 th sample (e.g., a sample corresponding to playback time 0:38.9844 seconds and collected at a sampling frequency of 64 Hz), and the subsequent reference hash key 210 may correspond to the 2497 th sample (e.g., a sample collected at a sampling frequency of 64Hz that begins at playback time 0:39.0156 seconds).

FIG. 3 illustrates an example data structure 300 that may be generated by the hash key manager 116 (FIG. 1), the example data structure 300 to be included on the example monitoring report 110 (FIG. 1) and/or stored in the example monitoring database 112 (FIG. 1). The example data structure 300 of fig. 3 includes a plurality of rows, each row corresponding to a different example impression record 302. When the metered hash key 104 (fig. 1) matches the reference hash key 204 (fig. 2) in the reference database 118 (fig. 1), the example hash key manager 116 generates an example impression record 302 that illustrates an example. In the example shown in FIG. 3, the impression record 302 includes the meter ID 108 associated with the media meter 100 (FIG. 1), the panelist ID 304, the baseline metadata 206 (FIG. 2), and a timestamp 306. The example reference metadata 206 is obtained from an example reference record 202 (e.g., a row in fig. 2) corresponding to the reference hash key 204 that matches the metered hash key 104. In some examples, the meter ID 108, panelist ID 304, and timestamp 306 are sent by the media meter 100 to the AME106 (FIG. 1) along with one or more metered hash keys 104. For example, the media meter 100 may send metered hash keys 104 to the AME106 one at a time in real time or near real time, or may send multiple hash keys 104 in batches from time to time. In the illustrated example, the timestamp 306 represents the time that a panelist (e.g., the panelist associated with the panelist ID 304) contacted the portion of the media 102 (fig. 1) corresponding to the metered hash key 104.

Fig. 4 illustrates an exemplary implementation of the reference hash key generator 120 of fig. 1. The example reference hash key generator 120 of fig. 4 generates a reference record 202 (fig. 2) for the example reference database 118. In the illustrated example of fig. 4, the reference hash key generator 120 includes an example hash key generator 400 and an example reference generator 402. The example hash key generator 400 samples the reference media 122 (fig. 1 and 4) at a sampling frequency (e.g., 16Hz, 32Hz, 64Hz, etc.). In the illustrated example, the hash key generator 400 generates a reference hash key (e.g., the reference hash key 204 of fig. 2) based on the collected samples. The example reference generator 402 receives or retrieves the reference hash key 204 and generates the reference record 202 (fig. 2) to store the reference hash key. For example, the reference generator 402 stores the reference hash key 204 in association with the reference metadata 206 (fig. 2), the previous reference hash key 208, and the subsequent reference hash key 210 as shown in the example reference record 202. In some examples, the reference media metadata 206 is embedded in the reference media 122 or linked to the reference media 122. In some examples, the reference metadata 206 is entered separately for each reference media 122. The example reference generator 402 stores the example reference record 202 in the reference database 118. In some examples, the reference records 202 are added to the reference database 118 separately after the reference records 202 are created. In some examples, after all of the reference records 202 are created for the reference media 122, the reference records 202 for the entire reference media 122 are added to the reference database 118 in batches.

Although an example manner of implementing the reference hash key generator 120 of fig. 1 is shown in fig. 4, one or more of the elements, processes and/or devices shown in fig. 4 may be combined, divided, reordered, omitted, eliminated and/or implemented in any other way. Additionally, the example hash key generator 400, the example reference generator 402, and/or, more generally, the example reference hash key generator 120 of fig. 1 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the example hash key generator 400, the example reference generator 402, and/or, more generally, the example reference hash key generator 120 of fig. 1, may be implemented by one or more analog or digital circuits, logic circuits, one or more programmable processors, one or more Application Specific Integrated Circuits (ASICs), one or more Programmable Logic Devices (PLDs), and/or one or more Field Programmable Logic Devices (FPLDs). When reading any of the apparatus or system claims of this patent covering a pure software and/or firmware implementation, at least one of the example hash key generator 400, the example reference generator 402, and/or the example reference hash key generator 120 of fig. 1 is hereby expressly defined to include a tangible computer-readable storage device or storage disk, such as a memory storing software and/or firmware, a Digital Versatile Disk (DVD), a Compact Disk (CD), a blu-ray disc, and so forth. Additionally, the example reference hash key generator 120 of fig. 1 may include one or more elements, processes and/or devices in addition to or instead of those shown in fig. 4, and/or may include more than one of any or all of the illustrated elements, processes and devices.

FIG. 5 illustrates an exemplary implementation of the hash key manager 116 of FIG. 1. The example hash key manager 116 of fig. 5 processes the metered hash keys 104 to measure impressions, generate monitoring reports (e.g., the example monitoring report 110), and/or store impression logs (e.g., the example impression log 302 of fig. 3) in a monitoring database (e.g., the example monitoring database 112). In the illustrated example of fig. 5, the hash key manager 116 includes an example hash key analyzer 500, an example error handler 502, and an example impression logger 504. The purpose of the hash key analyzer 500 of the example shown in fig. 5 is to determine whether a metered hash key is valid or invalid. The example hash key analyzer 500 of fig. 5 receives or retrieves metered hash keys 104 from a media meter 100. In some examples, the hash key analyzer 500 also receives or retrieves the meter ID 108 and/or other identifying information (e.g., demographics, panelist Identifier (ID), etc.) about one or more panelists exposed to the media 102 and/or information identifying people in the audience (e.g., the people meter 109 from fig. 1) from the media meter 100. The example hash key analyzer 500 of the illustrated example retrieves the example media reference hash key 204 (fig. 2) from the example reference database 118 (fig. 1) for comparison with the example metered hash key 104.

In the example shown in fig. 5, when the hash key analyzer 500 detects a match between one of the metered hash keys 104 and the reference hash key 204 (fig. 2), the hash key analyzer 500 designates the matching metered hash key 104 as a valid hash key 506. The example hash key analyzer 500 of fig. 5 provides an example valid hash key 506 to the example impression logger 504. In the example shown in fig. 5, when the hash key analyzer 500 does not detect a match between one of the metered hash keys 104 and the reference hash key 204 (fig. 2), the hash key analyzer 500 designates the unmatched metered hash key 104 as an invalid hash key 508. The example hash key analyzer 500 provides the example invalid hash key 508 to the example error handler 502.

To recover an invalid hash key (e.g., determine what the invalid hash key should be), the hash key analyzer 500 of the illustrated example selects a potential hash key based on a previous metered hash key or an adjacent previous metered hash key (e.g., the previous metered hash key 104b of fig. 1) and/or a subsequent metered hash key or an adjacent subsequent metered hash key (e.g., the subsequent metered hash key 104c of fig. 1). Determining whether the potential hash key and the invalid hash key are sufficiently close is discussed in further detail below in conjunction with fig. 7. Additionally or alternatively, to reduce search time and to advance comparisons to find matches with reference hash keys, the hash key analyzer 500 of the illustrated example operates to predict a next matching reference hash key based on a current match. For example, in determining a valid match (e.g., a valid hash key 506), the hash key analyzer 500 references a subsequent reference hash key to determine whether the subsequent metered hash key is valid rather than querying the reference database 118 with an entirely new search. In this way, knowledge gained from efficient matching is leveraged to advantageously reduce search time.

In the example shown in fig. 5, the hash key analyzer 500 determines potential hash keys 510. In some examples, the potential hash key 510 is based on the previous metered hash key 104b (fig. 1). In such examples, the hash key analyzer 500 retrieves the reference record 202 for the reference hash key 204 corresponding to the previous metered hash key 104 b. In such examples, the hash key analyzer 500 designates a subsequent reference hash key 210 (fig. 2) of the retrieved reference record 202 as the potential hash key 510. In some examples, the potential hash key 510 is based on the subsequent metered hash key 104c (fig. 1). In such examples, the hash key analyzer 500 retrieves the reference record 202 for the reference hash key 204 corresponding to the subsequent metered hash key 104 c. In such examples, the hash key analyzer 500 designates the previous reference hash key 208 (fig. 2) of the retrieved reference record 202 as the potential hash key 510. In some examples, the potential hash key 510 corresponding to the previous metered hash key 104b cannot be retrieved (e.g., the previous metered hash key 104b is invalid, etc.), and the hash key analyzer 500 attempts to retrieve the potential hash key 510 corresponding to the subsequent metered hash key 104 c. The example hash key analyzer 500 provides the example potential hash key 510 to the example error handler 502.

In the example shown in fig. 5, the error handler 502 processes the invalid hash key 508 and the potential hash key 510 to determine whether the potential hash key 510 sufficiently matches the invalid hash key 508 (e.g., is within an allowable threshold of the invalid hash key 508). The example error handler 502 of fig. 5 receives or retrieves an example invalid hash key 508 and one or more example potential hash keys 510 from the example hash key analyzer 500. The example error handler 502 compares the example invalid hash key 508 and the example potential hash key 510. If the difference between the example invalid hash key 508 and the example potential hash key 510 satisfies an example threshold (e.g., the difference is less than or equal to the threshold), the example error handler 502 designates the example potential hash key 510 as the example valid hash key 506. Satisfying the threshold is discussed in more detail below in conjunction with fig. 7. In the example shown in fig. 5, the error handler provides a valid hash key 506 to the impression logger 504. In some examples, the error handler 502 discards the invalid hash key 508 if the difference between the invalid hash key 508 and the potential hash key 510 is greater than a threshold (e.g., the hash keys are too different from each other). In some examples, if the hash key analyzer 500 used a previous metered hash key 104b and the error handler 502 discarded an invalid hash key 508, the hash key analyzer 500 selects an additional potential hash key 510 using a subsequent metered hash key 104 c. In such examples, the error handler 502 processes the additional potential hash keys 510 as described above.

In the example shown in fig. 5, the impression logger 504 receives or retrieves a valid hash key 506 from the hash key analyzer 500 and/or the error handler 502. In the illustrated example, the impression logger 504 retrieves the reference metadata 206 (fig. 2) corresponding to the valid hash key 506 from the reference database 118. The example impression logger 504 of fig. 5 associates the example base metadata 204 with the example impression log 302. In some examples, the impression logger 504 stores the meter ID 106 associated with the impression log 302. In the illustrated example of fig. 5, the impression logger 504 adds the impression log 302 to the monitoring report 110 (fig. 1) and/or stores the impression log 302 in the monitoring database 112 (fig. 1).

Although an example manner of implementing the hash key manager 116 of fig. 1 is shown in fig. 5, one or more of the elements, processes and/or devices shown in fig. 5 may be combined, divided, reordered, omitted, eliminated and/or implemented in any other way. Additionally, the example hash key analyzer 500, the example error handler 502, the example impression logger 504, and/or, more generally, the example hash key manager 116 of fig. 1 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the example hash key analyzer 500, the example error handler 502, the example impression logger 504, and/or, more generally, the example hash key manager 116 of fig. 1 may be implemented by one or more analog or digital circuits, logic circuits, one or more programmable processors, one or more Application Specific Integrated Circuits (ASICs), one or more Programmable Logic Devices (PLDs), and/or one or more Field Programmable Logic Devices (FPLDs). When reading any of the apparatus or system claims of this patent covering a pure software and/or firmware implementation, at least one of the example hash key analyzer 500, the example error handler 502, the example impression logger 504, and/or the example hash key manager 116 of fig. 1 is hereby expressly defined to include a tangible computer-readable storage device or storage disk, such as a memory storing software and/or firmware, a Digital Versatile Disk (DVD), a Compact Disk (CD), a blu-ray disk, and/or the like. Additionally, the example hash key manager 116 of fig. 1 may include one or more elements, processes and/or devices in addition to or instead of those shown in fig. 5, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Fig. 6A and 6B illustrate different exemplary configurations of the exemplary hash key analyzer 500 of fig. 5. The configuration of the example hash key analyzer 500 shown in fig. 6A and 6B determines whether a metered hash key is valid and selects a potential hash key for recovering the metered hash key when the metered hash key is invalid. In the example shown in fig. 6A, the example hash key analyzer 500 uses an adjacent previous metered hash key as a potential hash key. In the example shown in fig. 6B, the example hash key analyzer 500 uses the next, subsequent metered hash key to select the potential hash key. In the illustrated example, the hash key analyzer 500 is provided with an example hash key comparator 600 and an example potential hash key retriever 602.

The example hash key comparator 600 of fig. 6A and 6B receives or retrieves the current metered hash key 104a to be processed. In the illustrated example, the hash key comparator 600 queries the reference database 118 (fig. 1) for the reference hash key 204 to compare with the current metered hash key 104 a. In the illustrated example, the query submitted by the hash key comparator 600 performs a comparison operation that retrieves the reference hash key 204 that matches the current metered hash key 104a by using the current metered hash key 104a as a query parameter. If the example hash key comparator 600 determines, based on the query, that the current metered hash key 104a matches the reference hash key 204 associated with the reference record 202 in the reference database 118, the hash key comparator 600 designates the current metered hash key 104a as a valid hash key 506 (fig. 5). In the illustrated example of fig. 6A and 6B, the hash key comparator 600 determines that the current metered hash key 104a does not match the reference hash key 204 if the query submitted to the reference database 118 returns no value (e.g., the reference database returns a NULL value, etc.) and/or if the query otherwise indicates that the current metered hash key 104a is not found in the reference database 118. In such examples, the hash key comparator 600 designates the current metered hash key as the invalid hash key 508 (fig. 5).

In the example shown in fig. 6A, the potential hash key retriever 602 determines whether the previous metered hash key 104b is in the reference database 118. In some examples, the potential hash key retriever 602 stores information indicating whether the previous metered hash key 104b is valid (e.g., whether the reference hash key 204 was identified for the previous metered hash key 104b in a previous iteration of the metered hash key comparison). If the example previous metered hash key 104b is valid, the example potential hash key retriever 602 retrieves the example reference record 202 to which the example previous metered hash key 104b corresponds. The example potential hash key retriever 602 designates a subsequent reference hash key 210 (fig. 2) stored in association with the retrieved reference record 202 as the potential hash key 510.

In the example shown in fig. 6B, the potential hash key retriever 602 determines whether the subsequent metered hash key 104c matches the reference hash key 202 in the reference database 118. If the subsequent metered hash key 104c matches the reference hash key 204, the potential hash key retriever 602 retrieves the reference record 202 to which the subsequent metered hash key 104c corresponds. The example potential hash key retriever 602 designates the previous reference hash key 208 stored in association with the retrieved reference record 202 as the potential hash key 510. In the example shown in fig. 6A and 6B, if the potential hash key retriever 602 does not designate the current metered hash key 104a as valid or does not designate the potential hash key 510, the current hash key 104a is discarded.

Although an exemplary manner of implementing the hash key analyzer 500 of fig. 5 is shown in fig. 6A and 6B, one or more of the elements, processes and/or devices shown in fig. 6A and 6B may be combined, divided, reordered, omitted, eliminated and/or implemented in any other way. Additionally, the example hash key comparator 600, the example potential hash key retriever 602, and/or, more generally, the example hash key analyzer 500 of fig. 5 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the example hash key comparator 600, the example potential hash key retriever 602, and/or, more generally, the example hash key analyzer 500 of fig. 5 may be implemented by one or more analog or digital circuits, logic circuits, one or more programmable processors, one or more Application Specific Integrated Circuits (ASICs), one or more Programmable Logic Devices (PLDs), and/or one or more Field Programmable Logic Devices (FPLDs). When reading any of the apparatus or system claims of this patent covering a pure software and/or firmware implementation, at least one of the example hash key comparator 600, the example potential hash key retriever 602, and/or the example hash key analyzer 500 of fig. 5 is thus expressly defined to include a tangible computer-readable storage device or storage disk, such as a memory storing software and/or firmware, a Digital Versatile Disk (DVD), a Compact Disk (CD), a blu-ray disk, and/or the like. Additionally, the example hash key analyzer 500 of fig. 5 may include one or more elements, processes, and/or devices in addition to, or instead of, those shown in fig. 6A and 6B, and/or may include more than one of any or all of the illustrated elements, processes, and devices.

FIG. 7 illustrates an exemplary implementation of the exemplary error handler 502 of FIG. 5. The example error handler 502 determines whether the invalid hash key is recoverable (e.g., whether the potential hash key sufficiently matches the invalid hash key). The example error handler 502 shown in FIG. 7 is provided with an example bitwise comparator 700, an example threshold comparator 702, and an example hash key designator 704. In the illustrated example, the bitwise comparator 700 receives or retrieves the invalid hash key 508 (fig. 5) and the potential hash keys 510 (fig. 5) from the hash key analyzer 500 (fig. 5, 6A, and 6B). The example bitwise comparator 700 of this example calculates an error level 706 (e.g., an error value) by comparing corresponding bits in the example invalid hash key 508 to bits in the example potential hash key 510. The example error level 706 indicates a number of bits that are not the same between the invalid hash key 508 and the potential hash key 510. In some examples, the example bitwise comparator 700 performs a bitwise operation (e.g., a bitwise exclusive or (XOR) operation, a bitwise exclusive nor (XNOR) operation, etc.) on the example invalid hash key 508 and the example potential hash key 510. In some examples, the error level 706 is determined using equation (1) below.

In the above equation (1), HK_ITo invalidate hash key 508, HK_PThe number of 1's in the binary number is returned for the potential hash key 510, and the BitCount () function. In the example shown in the drawings,using a bitwise XOR operation, a 1 in a particular bit position indicates that the corresponding bits of the invalid hash key 508 and the potential hash key 510 in the same bit position are not matching bits (e.g., the bit in the invalid hash key 508 is set to 1 and the corresponding bit in the potential hash key 510 is set to 0). For example, as shown below in table (1), for an invalid hash key 508 having a hexadecimal value of 0x1074 and a potential hash key 510 having a hexadecimal value of 0x1264, the error level 706 is 2(BitCount (0x1074 ≦ 0x1264) ═ 2) because the two bit positions have values that do not match.

Watch (1)

In the example shown in fig. 7, the threshold comparator 702 compares the error level 706 to an error threshold 708. In some examples, the example error threshold 708 is set by the example AME106 (fig. 1) to identify a number of errors that may be in the example metered hash key 104 (fig. 1) while still being considered a match. In some examples, the error threshold 706 may be set to 10% of the bit length of the metered hash key 104 (e.g., an error threshold of 6 would be selected for a 64-bit metered hash key 104). If the example error level 706 is less than or equal to the error threshold 708 (e.g., the error level 706 satisfies the error threshold 708), the hash key designator 704 designates the potential hash key 510 as the valid hash key 506 (FIG. 4). If the example error level 706 is greater than the error threshold 708 (e.g., the error level 706 does not satisfy the error threshold 708), then the match is sufficient and the hash key designator 704 does not designate the potential hash key 510. In some examples, the hash key designator 704 sets the potential hash key 510 to a NULL value when the error threshold 708 is not satisfied.

Although an example manner of implementing the error processor 502 of fig. 5 is shown in fig. 7, one or more of the elements, processes and/or devices shown in fig. 7 may be combined, divided, reordered, omitted, eliminated and/or implemented in any other way. Additionally, the example bitwise comparator 700, the example threshold comparator 702, the example hash key designator 704, and/or, more generally, the example error handler 502 of fig. 5 may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the example bitwise comparator 700, the example threshold comparator 702, the example hash key designator 704, and/or, more generally, the example error processor 502 of fig. 5, may be implemented by one or more analog or digital circuits, logic circuits, one or more programmable processors, one or more Application Specific Integrated Circuits (ASICs), one or more Programmable Logic Devices (PLDs), and/or one or more Field Programmable Logic Devices (FPLDs). When reading any of the apparatus or system claims of this patent covering a pure software and/or firmware implementation, at least one of the example bitwise comparator 700, the example threshold comparator 702, the example hash key designator 704, and/or the example error handler 502 of fig. 5 is hereby expressly defined to include a tangible computer-readable storage device or storage disk, such as a memory storing software and/or firmware, a Digital Versatile Disk (DVD), a Compact Disk (CD), a blu-ray disk, and/or the like. Additionally, the example error processor 502 of fig. 5 may include one or more elements, processes, and/or devices in addition to or instead of those shown in fig. 7, and/or may include more than one of any or all of the illustrated elements, processes, and devices.

Fig. 8 illustrates an example data structure 800 that may be used to store metered hash keys generated by the media meter 100 of fig. 1 (e.g., the metered hash keys 104 of fig. 1) to detect unexpected hash keys. In the illustrated example of FIG. 8, the data structure 800 includes the meter ID 108, the panelist ID 304, the metered hash key 104, and the timestamp 306. In some examples, the data structure 800 may include the reference metadata 206 retrieved from the reference database 118 (fig. 1) when an unexpected hash key is detected and/or corrected in post-processing (e.g., the metered hash key 104 has been processed by the hash key manager 116 of fig. 1). In some examples, the reference metadata 206 is retrieved from the reference database 118 when an unexpected hash key is detected and/or corrected while processing the metered hash key 104.

In the example shown in fig. 8, the unexpected hash key 802 is a metered hash key 104 associated with the reference metadata 206, the reference metadata 206 being unexpectedly different from the reference metadata 206 of the previous hash key 804 and/or the subsequent hash key 806 (e.g., different media IDs, non-sequential sample numbers, etc.). For example, if the reference metadata 206 of the previous hash key 804 is [ title: clarity, media ID: 27328MU, sample number: 1602], the expected value of the reference metadata 206 associated with the next metered hash key 104 will be [ title: clarity, media ID: 27328MU, sample number: 1603] (e.g., the next sequential sample of the media presentation 100 of fig. 1). In this example, if the reference metadata 206 for the next metered hash key 104 is [ title: spectrum, media ID: 29117MU, sample number: 12761], the metered hash key will be determined to be the unintended hash key 802. In some examples, the unexpected hash key 802 occurs because an error is introduced into the metered hash key 104. In some examples, the hash key 802 is not expected to occur because different metered presentations 100 are metered (e.g., a panelist changes the media presentation 100, etc.).

In some examples, the hash key manager 116 (fig. 1) determines whether the unexpected hash key 802 is the result of an error by calculating an error level (e.g., the error level 706 of fig. 7) between the unexpected hash key 802 and a potential reference hash key (e.g., the potential reference hash key 510 of fig. 5) retrieved from a previous hash key 804 and/or a subsequent hash key 806. If the error level satisfies an error threshold (e.g., error threshold 708 of FIG. 7) (e.g., the error level is less than or equal to the error threshold), the potential hash key replaces the unintended hash key 802. Otherwise, a channel change event or the like is deemed to have been identified and the unintended hash key 802 is not replaced.

A flowchart representative of example machine readable instructions for implementing the example hash key manager 116 of fig. 1 and 5 is shown in fig. 9. A flowchart representative of example machine readable instructions for implementing the example hash key analyzer 500 of fig. 6A and 6B is shown in fig. 10. A flowchart representative of example machine readable instructions for implementing the example error handler 502 of fig. 5 and 7 is shown in fig. 11. A flowchart representative of example machine readable instructions to implement the example hash key analyzer 500 of fig. 5, 6A, and 6B, the example error handler 502 of fig. 5 and 7, and/or the example impression logger 504 of fig. 5 is shown in fig. 12A and 12B. A flowchart representative of example machine readable instructions for implementing the example reference hash key generator 120 of fig. 1 and 4 is shown in fig. 13. A flowchart representative of machine readable instructions for implementing the example hash key manager 116 of fig. 1 and 5 is shown in fig. 14. In these examples, the machine readable instructions comprise one or more programs that are executed by a processor, such as processor 1512 shown in exemplary processor platform 1500 discussed below in connection with fig. 15. The program may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a Digital Versatile Disk (DVD), a blu-ray disc, or a memory associated with the processor 1512, although the entire program and/or parts thereof could alternatively be executed by a device other than the processor 1512 and/or embodied in firmware or dedicated hardware. Additionally, although the example programs are described with reference to the flowcharts shown in fig. 9, 10, 11, 12A, 12B, 13, and 14, many other methods of implementing the example hash key manager 116 and the example reference hash key generator 120 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

As described above, the example processes of fig. 9, 10, 11, 12A, 12B, 13, and 14 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a Read Only Memory (ROM), a Compact Disc (CD), a Digital Versatile Disc (DVD), a cache, a Random Access Memory (RAM), and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended periods of time, permanently, brief instances of time, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer-readable storage medium is expressly defined to include any type of computer-readable storage device and/or storage disk and to exclude propagating signals, to exclude transitory 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 example processes of fig. 9, 10, 11, 12A, 12B, 13, and 14 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, an optical disk, a digital versatile disk, a cache, a random access memory, and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended periods of time, permanently, for brief instances, for temporarily buffering, and/or for caching of the 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 to exclude propagating signals, to exclude transitory signals, and to exclude transmission media. As used herein, the phrase "at least" is open-ended when used as a transitional term in the preamble of a claim, as is the term "comprising".

The example program 900 of fig. 9 is executed to implement the example hash key manager 116 of fig. 1 and 5, the example hash key manager 116 to generate an impression record (e.g., the impression record 302 of fig. 3) based on one or more metered hash keys 104 (fig. 1) retrieved from the media meter 100 (fig. 1). The impression record 302 is used to generate the monitoring report 110 (fig. 1) and/or maintain the monitoring database 112 (fig. 1). Initially, at block 902, the example hash key analyzer 500 (fig. 5) selects the metered hash key 104 as the current metered hash key 104a (fig. 1). At block 904, the example hash key analyzer 500 determines whether the current metered hash key 104a is a valid hash key (e.g., the valid hash key 506 of fig. 5). An exemplary process that may be used to implement block 904 to determine whether the current metered hash key 104a is valid is described below in connection with fig. 10.

At block 906, if the current metered hash key 104a is not a valid hash key 506, program control proceeds to block 908. Otherwise, if the current metered hash key 104a is a valid hash key 506, program control proceeds to block 914. At block 908, the example error handler 502 determines whether a valid hash key 506 is recoverable from the invalid current metered hash key 104 a. An exemplary process that may be used to implement block 908 to determine whether a valid hash key 506 is recoverable from an invalid current metered hash key 104a is described below in connection with fig. 11. At block 910, if the valid hash key 506 is recoverable (block 908), program control proceeds to block 914. If the valid hash key 506 is unrecoverable (block 908), program control proceeds to block 912 where the example error handler 502 discards the current metered hash key 104a at block 912. The example routine 900 then ends.

At block 914, the example impression logger 504 retrieves from the reference database 118 (fig. 1) reference metadata (e.g., the reference metadata 206 of fig. 2) corresponding to the valid hash key 506 detected at block 904 or block 908. At block 916, the example impression logger 504 generates an impression log (e.g., the impression log 302 of fig. 3) based on the base metadata 206 retrieved at block 914. For example, the hash key manager 116 may store the meter ID 108 (fig. 1), panelist ID 304 (fig. 3), audience identification information (e.g., people meters 109 from fig. 1), and/or a timestamp 306 (fig. 3) associated with the benchmark metadata 206 in the impression record 302. The example routine 900 then ends.

The example program 1000 of fig. 10 is executed to implement the example hash key analyzer 500 of fig. 5, 6A, and/or 6B to determine whether a metered hash key 104 (e.g., the current metered hash key 104a of fig. 1) received from the media meter 100 (fig. 1) is a valid hash key (e.g., the valid hash key 506 of fig. 5). Initially, at block 1002, the example hash key comparator 600 (fig. 6A and 6B) determines whether the current metered hash key 104a matches a reference hash key (e.g., the reference hash key 204 of fig. 2) from the reference database 118 (fig. 1). If the current hash key 104a matches the reference hash key 204, program control proceeds to block 1004 where the example hash key comparator 600 designates the current hash key 104a as valid (e.g., as the valid hash key 506 of FIG. 5) at block 1004. The example program 1000 then ends and/or control returns to a calling function or process, such as the example process of FIG. 9.

If the current metered hash key 104a does not match the reference hash key 204 (at block 1002), program control proceeds to block 1006. At block 1006, the example potential hash key retriever 602 verifies whether an adjacent metered hash key, such as the previous metered hash key 104b (fig. 1) and/or the subsequent metered hash key 104c (fig. 1), is valid. For example, when verifying the previous metered hash key 104b, the hash key analyzer 500 may track whether the previous metered hash key 104b matches the reference hash key 204 during a previous iteration of matching the metered hash key 104 to the reference hash key 204. For example, when verifying the subsequent metered hash key 104c, the hash key manager 116 may suspend the current iteration of reference hash key matching for the current metered hash key 104a, perform the iteration of reference hash key matching for the subsequent metered hash key 104c, and then resume the reference hash key matching for the current metered hash key 104 a. If the adjacent metered hash key is not valid, program control proceeds to block 1008 where the example hash key comparator 600 designates the current hash key 104a as the invalid hash key 508 (FIG. 5) at block 1008. The example process 1000 then ends.

If at block 1006 the adjacent metered hash key is verified as valid, program control proceeds to block 1010. At block 1010, the example potential hash key retriever 602 retrieves a potential hash key (e.g., the potential hash key 510 of fig. 5) from a valid adjacent hash key. For example, when the previous metered hash key 104b is used, the potential hash key retriever 602 retrieves the reference record 202 (fig. 2) for the reference hash key 204 to which the previous metered hash key 104b corresponds. In such examples, the potential hash key retriever 602 designates a subsequent reference hash key 210 (fig. 2) of the retrieved reference record 202 as the potential hash key 510. For example, when the subsequent metered hash key 104c is used, the potential hash key retriever 602 retrieves the reference record 202 for the reference hash key 204 to which the subsequent metered hash key 104c corresponds. In such examples, the potential hash key retriever 602 designates the previous reference hash key 208 of the retrieved reference record 202 as the potential hash key 510. The example program 1000 then ends and/or control returns to a calling function or process, such as the example process of FIG. 9.

The example program 1100 represented by fig. 11 is executed to implement the error handler 502 of fig. 5 and 7 to recover (if possible) a valid hash key (e.g., the valid hash key 506 of fig. 5) based on, for example, the invalid hash key (e.g., the invalid hash key 508 of fig. 5) and the potential hash key (e.g., the potential hash key 510 of fig. 5) received from the hash key analyzer 500 of fig. 5. Initially, at block 1102, the example bitwise comparator 700 (fig. 7) computes an error level (e.g., the error level 706 of fig. 7) between the invalid hash key 508 and the potential hash key 510. In some examples, bitwise comparator 700 performs a bitwise comparison (e.g., a bitwise exclusive-or, etc.) to calculate an error level. At block 1104, the example threshold comparator 702 (fig. 7) determines whether the error level 706 calculated at block 1102 satisfies an error threshold (e.g., the error threshold 708 of fig. 7). Calculating the error level 706 and determining whether the error level 706 satisfies the error threshold 708 are discussed above in connection with fig. 7. If the error level 706 meets the error threshold 708 (e.g., the error level 706 is less than or equal to the error threshold 708), program control proceeds to block 1106, where the example hash key designator 704 (FIG. 7) designates the potential hash key 510 as the valid hash key 506 at block 1106. The example routine 1100 then ends and/or control returns to a calling function or process, such as FIG. 9. If the error level 706 does not satisfy the error threshold (e.g., the error level 706 is greater than the error threshold 708), program control proceeds to block 1108 where the example hash key designator 704 sets the valid hash key 506 to a NULL value. The example routine 1100 then ends and/or control returns to a calling function or process, such as FIG. 9.

The example routine 1200 represented by fig. 12A and 12B is executed to implement the example hash key manager 116 of fig. 1 and 5 to facilitate comparing and matching metered hash keys 104 (fig. 1) received from the media meter 100 (fig. 1) by using a subsequent reference hash key (e.g., the subsequent reference hash key 510 of fig. 5) to which a valid metered hash key corresponds. Initially, at block 1202 (fig. 12A), the example hash key analyzer 500 (fig. 5) sets the metered hash key 104 as the current metered hash key 104a (fig. 1). At block 1204, the example hash key analyzer 500 determines whether the current metered hash key 104a is a valid hash key (e.g., the valid hash key 506 of fig. 5). An exemplary process that may be used to implement block 1204 to determine whether the current metered hash key 104a is valid is described above in connection with fig. 10.

At block 1206, the example hash key analyzer 500 determines whether the current metered hash key 104a is valid. If the current metered hash key 104a is valid, program control proceeds to block 1212 (FIG. 12B). Otherwise, if the current metered hash key 104a is not valid, program control proceeds to block 1208. At block 1208, the example error handler 502 (fig. 5) determines whether a valid hash key 506 is recoverable from the invalid current metered hash key 104 a. An exemplary process that may be used to implement block 1208 to determine whether a valid hash key 506 is recoverable from an invalid current metered hash key 104a is described above in connection with fig. 11. If the valid hash key 506 is recoverable (block 1210), program control proceeds to block 1212 (FIG. 12B). If the valid hash key 506 is unrecoverable (block 1210), the example process 1100 ends.

At block 1212, the impression logger 504 (fig. 5) generates an impression log (e.g., the impression log 302 of fig. 3) based on the valid hash key 506 from block 1206 or block 1210. At block 1214, the hash key analyzer 500 accesses the next reference hash key 510 (fig. 5) corresponding to the valid hash key 506 from either block 1206 or block 1210. For example, the hash key analyzer 500 accesses the reference record 202 (fig. 2) associated with the reference hash key 204 that matches the valid hash key 506. In such examples, the hash key manager 116 selects a subsequent reference hash key 210 (fig. 2) stored in association with the retrieved reference record 202. To begin the comparison process with another metered hash key, at block 1216, the hash key analyzer 500 selects the next available metered hash key 104 (e.g., the next metered hash key 104c of fig. 1) as the current metered hash key 104 a. At block 1218, the example hash key analyzer 500 determines whether the subsequent reference hash key 210 accessed at block 1214 matches the current metered hash key 104a selected at block 1216. If the subsequent reference hash key 210 accessed at block 1214 matches the current metered hash key 104a selected at block 1216, program control proceeds to block 1220. Otherwise, if the subsequent reference hash key 210 accessed at block 1214 does not match the current metered hash key 104a selected at block 1216, program control proceeds to block 1222.

At block 1220, the example hash key analyzer 500 designates the current metered hash key 104a selected at block 116 as the valid hash key 506. Program control then returns to block 1212 to continue iterating through the metered hash keys. At block 1222, the example error handler 502 determines whether a valid hash key 506 is recoverable from the invalid current metered hash key 104 a. An exemplary process that may be used to implement block 1222 to determine whether a valid hash key 506 is recoverable from an invalid current metered hash key 104a is described above in connection with fig. 11. At block 1224, if the valid hash key 506 is recoverable (block 1222), program control returns to block 1212 to continue iterating through the metered hash key. If the valid hash key 506 is unrecoverable (block 1222), the example process returns to block 1204 (FIG. 12A).

The example program 1300 of fig. 13 is executed to implement the example reference hash key generator 130 of fig. 1 and 4 to generate a reference record (e.g., the reference record 202 of fig. 2) based on the reference media 122 (fig. 1). Initially, at block 1302, the example hash key generator 400 (fig. 4) generates a reference hash key based on the reference media 122. At block 1304, the example reference generator 402 (FIG. 4) selects one of the reference hash keys generated at block 1302. At block 1306, the example reference generator 402 generates a new reference record 202. At block 1308, the example reference generator 402 stores the reference hash key selected at block 1304 as the reference hash key 204 (fig. 2) of the reference record 202 generated at block 1306, stores the adjacent previous reference hash key as the previous reference hash key 208 (fig. 2) of the reference record 202 generated at block 1306, and stores the adjacent subsequent reference hash key as the subsequent reference hash key 210 (fig. 2) of the reference record 202 generated at block 1306.

At block 1310, the example reference generator 402 stores the reference metadata 206 in the reference record 202 generated at block 1306, as described above in connection with FIG. 4. At block 1312, the example reference generator 402 determines whether additional reference records are to be generated. For example, the reference generator 402 determines whether the reference record 202 has been generated for all of the reference hash keys generated at block 1302. If another reference record 202 is to be generated, program control returns to block 1304. If another reference record is not to be generated, program control proceeds to block 1314. At block 1314, the example reference generator 402 adds one or more reference records 202 to the reference database 118 (fig. 1). The example routine 1300 then ends.

Fig. 14 is a flow diagram representing example machine readable instructions 1400 that may be executed to implement the hash key manager 116 of fig. 1 and 5 to detect and/or correct an unexpected hash key (e.g., the unexpected hash key 802 of fig. 8). Initially at block 1402, the example hash key analyzer 500 (fig. 5) retrieves reference metadata (e.g., the reference metadata 206 of fig. 2) for the current metered hash key 104a (fig. 1) from the reference database 118 (fig. 1). At block 1404, the example hash key analyzer 500 retrieves reference metadata 206 for neighboring metered hash keys (e.g., the previous metered hash key 804, the next metered hash key 806, etc. of fig. 8) from the reference database 118. At block 1406, the example hash key analyzer 500 determines whether the current metered hash key 104a is unexpected. In some examples, the current metered hash key 104a is unexpected if the title and/or media ID included in the reference metadata 206 retrieved at blocks 1402 and 1404 do not match. If the current metered hash key 104a is not expected (block 1406), program control proceeds to block 1408. Otherwise, if the current metered hash key 104a is not unexpected (1406), program control proceeds to block 1418.

At block 1408, the example hash key analyzer 500 retrieves a potential hash key (e.g., the potential hash key 510 of fig. 5) from an adjacent metered hash key. At block 1410, the example error handler 502 (fig. 5) calculates an error level (e.g., the error level 706 of fig. 7) between the unexpected hash key 802 (fig. 8) and the potential hash key retrieved at block 1408. At block 1412, the example error processor 502 determines whether the error level satisfies an error threshold (e.g., the error threshold 710 of fig. 7). If the error level satisfies the error threshold (block 1412), program control proceeds to block 1416. Otherwise, if the error level does not satisfy the error threshold (block 1412), program control proceeds to block 1414. At block 1414, the example error handler 502 designates the unexpected hash key 802 as a valid hash key (e.g., the valid hash key 506 of FIG. 5). At block 1416, the example error handler 502 replaces the unexpected hash key 802 with the potential hash key. At block 1418, the example hash key analyzer 500 determines whether there is another hash key to check. If there is another hash key to check, program control returns to block 1402. Otherwise, if there is no other hash key to check, the example process 1400 ends.

Fig. 15 is a block diagram of an example processor platform 1500, the example processor platform 1500 being capable of executing the instructions of fig. 9, 10, 11, 12A, 12B, 13, and/or 14 to implement the example hash key manager 116 of fig. 5, the example hash key analyzer 500 of fig. 6A and 6B, the example error processor of fig. 7, and/or the example reference hash key generator 120 of fig. 4. For example, processor platform 1500 may be a server, a personal computer, a workstation, or any other type of computing device.

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

The processor 1512 of the illustrated example includes local memory 1513 (e.g., a cache). The processor 1512 of the illustrated example communicates with main memory, including volatile memory 1514 and non-volatile memory 1516, via bus 1518. The volatile memory 1514 may 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 1516 may be implemented by flash memory and/or any other desired type of storage device. Access to the main memory 1514, 1516 is controlled by a memory controller.

The processor platform 1500 of the illustrated example also includes interface circuitry 1520. The interface circuit 1520 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 illustrated example, one or more input devices 1522 are connected to the interface circuit 1520. One or more input devices 1522 allow a user to enter data and commands into the processor 1512. One or more input devices may be implemented by, for example, an audio sensor, microphone, camera (still or video), keyboard, button, mouse, touch screen, track pad, trackball, etc., and/or a voice recognition system.

One or more output devices 1524 are also connected to the interface circuit 1520 of the illustrated example. The output devices 1524 can be implemented, for example, by display devices (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 touch output device, a printer, and/or speakers). The interface circuit 1520 of the illustrated example thus typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

The interface circuit 1520 of the illustrated example also includes communication devices such as a transmitter, receiver, transceiver, modem, and/or a network interface card to facilitate exchange of data with external machines (e.g., any type of computing device) via a network 1526 (e.g., an ethernet connection, a Digital Subscriber Line (DSL), a telephone line, coaxial cable, a mobile telephone system, etc.).

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

The encoded instructions 1532 of fig. 9, 10, 11, 12A, 12B, 13, and/or 14 may be stored in the mass storage device 1528, the volatile memory 1514, the non-volatile memory 1516, and/or a removable tangible computer-readable storage medium (such as a CD or DVD).

From the above, it will be appreciated that examples have been disclosed that allow recovery of metered hash keys generated from a media source that introduces noise into the metered hash keys. In addition, an example of generating a reference record including information on reference hash keys for a continuous portion of a medium has been disclosed. Examples have been disclosed that improve the accuracy of impression data and reduce the processing required to perform matching and/or adjust for erroneous and/or missing impression data (e.g., reduce the burden on semiconductor-based processors). Furthermore, since the wrong hash key can be effectively adjusted, the search time for identifying media in the database is reduced. Reducing the search time saves processing resources and reduces the energy consumption required to perform media monitoring.

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

Claims

1. A method of identifying media using hash keys, comprising:

accessing, with a processor, a first metered hash key and first reference metadata associated with the first metered hash key;

accessing, with the processor, second reference metadata associated with a second hash key adjacent to the first metered hash key;

determining, with the processor, whether the first metered hash key is unexpected by comparing the first reference metadata to the second reference metadata;

generating, with the processor, an error level using a first bitwise comparison of the first metered hash key and the second hash key when the first metered hash key is unexpected;

determining, with the processor, whether the error level satisfies a threshold; and

when the processor determines that the error level satisfies the threshold:

storing, with the processor, the second hash key as the first metered hash key.

2. The method of claim 1, wherein the first metered hash key is unexpected when at least one of a title and a media identification associated with the first reference metadata does not match at least one of a title and a media identification associated with the second reference metadata.

3. The method of claim 1, wherein the threshold is set to a percentage of a bit length of the first metered hash key.

4. The method of claim 1, further comprising:

when the processor determines that the error level does not satisfy the threshold:

storing, with the processor, the first metered hash key as a valid hash key.

5. The method of claim 1, wherein the first bitwise comparison comprises an exclusive or function.

6. A method as defined in claim 1, wherein the error level indicates a number of bits that are not identical between the first metered hash key and the second hash key.

7. The method of claim 1, wherein the threshold is satisfied when the error level is less than or equal to the threshold.

8. An apparatus for identifying media using hash keys, comprising:

an error processor to:

accessing a first metered hash key and first reference metadata associated with the first metered hash key;

accessing second reference metadata associated with a second hash key adjacent to the first metered hash key;

determining whether the first metered hash key is unexpected by comparing the first reference metadata to the second reference metadata;

generating an error level using a first bitwise comparison of the first metered hash key and the second hash key when the first metered hash key is unexpected;

determining whether the error level satisfies a threshold; and

when the error level satisfies the threshold:

storing the second hash key as the first metered hash key.

9. The apparatus of claim 8, wherein the first metered hash key is unexpected when at least one of a title and a media identification associated with the first reference metadata does not match at least one of a title and a media identification associated with the second reference metadata.

10. The apparatus of claim 8, wherein the threshold is set to a percentage of a bit length of the first metered hash key.

11. The apparatus of claim 8, wherein the error processor is further to:

storing the first metered hash key as a valid hash key when the error level does not satisfy the threshold.

12. The apparatus of claim 8, wherein the first bitwise comparison comprises an exclusive or function.

13. An apparatus as defined in claim 8, wherein the error level indicates a number of bits that are not identical between the first metered hash key and the second hash key.

14. The apparatus of claim 8, wherein the threshold is satisfied when the error level is less than or equal to the threshold.

15. A computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to at least:

determining whether the error level satisfies a threshold; and

when the error level satisfies the threshold:

storing the second hash key as the first metered hash key.

16. The computer-readable storage medium of claim 15, wherein the first metered hash key is unexpected when at least one of a title and a media identification associated with the first reference metadata does not match at least one of a title and a media identification associated with the second reference metadata.

17. The computer-readable storage medium of claim 15, wherein the threshold is set to a percentage of a bit length of the first metered hash key.

18. The computer readable storage medium of claim 15, wherein the instructions, when executed by the processor, further cause the processor to:

19. The computer-readable storage medium of claim 15, wherein the error level indicates a number of bits that are not the same between the first metered hash key and the second hash key.

20. The computer-readable storage medium of claim 15, wherein the threshold is satisfied when the error level is less than or equal to the threshold.