Patent Description:
Content providers, broadcasters, studios, advertisers, publishers, etc. are interested in measuring and/or statistically analyzing the viewing and/or exposure of portions of media to demographic groups. For example, advertisers are interested in verifying overall effectiveness, reach and/or audience demographics for particular advertisements placed in particular videos, shows, movies, audio streams, commercials, audio files, etc. Likewise, broadcasters are interested in being able to demonstrate the effectiveness, reach and/or audience demographics of media viewed via their networks and/or content delivery systems in order to, for example, establish an appropriate advertisement rate. <CIT> pertains to an information monitoring system for the collection of all real-time information activity between a user and a variety of information services. <CIT> pertains to intercepting function calls directed to one programming module and redirecting the function call to another programming module.

Although the example apparatus and methods described herein include, among other components, software executed on hardware, such apparatus and methods are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of the disclosed hardware and software components could be embodied exclusively in dedicated hardware, exclusively in software, exclusively in firmware or in some combination of hardware, firmware, and/or software.

In addition, while the following disclosure is made with respect to an example personal computer (PC) based video display system, it should be understood that the disclosed apparatus is readily applicable to many other computer-based and/or electronic media display systems and/or devices such as, but not limited to, handheld computing devices (e.g., iPods, personal digital assistants (PDAs), MP3 players, multimedia players, Playstation portables (PSPs), smart phones, etc.) or cellular telephones. Accordingly, while the following describes example apparatus, methods, and articles of manufacture, persons of ordinary skill in the art will readily appreciate that the disclosed examples are not the only way to implement such systems. For instance, a television (TV) may have an embedded, attached and/or coupled electronic device, electronic system, computing device, computing system, and/or PC configured to receive and/or decode a video signal, display a video signal, and meter viewing statistics and/or program consumption. For example, a digital video recorder attached to a TV, a TV with an integrated digital video recorder and/or digital versatile disc (DVD) player, etc..

While example apparatus and methods to meter computer-based display of video are described herein, persons of ordinary skill in the art will readily appreciate that the disclosed apparatus and methods may be used, additionally or alternatively, to meter the presentation of any of a variety of additional and/or alternative types of media including, for example, audio, audio streams, commercials, mixed audio and/ video, images, text, data file, file, etc..

In general, the example apparatus, methods, and articles of manufacture described herein may be used to determine video viewership statistics and/or program consumption characteristics. In the particular examples described herein, data is collected that characterizes the viewing, consumption and/or display of video from, for example, a DVD, a compact disc (CD), an Internet site and/or a hard drive, and television (TV) programs from, for example, a terrestrial broadcast, a cable broadcast, a satellite broadcast, and/or an Internet broadcast.

<FIG> illustrates an example system for metering the display of PC based video constructed in accordance with the teachings of the invention to monitor and log video viewing and/or program consumption by one or more viewers of PC based video. Although an embodiment of the system discussed herein relates to metering the viewing of TV programs on a PC, it will be readily apparent to persons of ordinary skill in the art that the metering system of <FIG> can be applied to other forms of video display by a PC. For example, Internet based streaming video, DVD, CD, hard disk drive, etc. Further, it is known that TV programs may be provided to a PC via terrestrial broadcast, cable broadcast, satellite broadcast, Internet based streaming video, DVD, CD, etc..

To interact with a user (i.e., viewer of the PC based video) and to receive and display video programs, the example system of <FIG> includes hardware <NUM>, an application programming interface (API) <NUM>, and a media presentation application (e.g., a PC video application) <NUM> that emits any of a variety of types of media (e.g., video). In the illustrated example of <FIG>, the hardware <NUM> is implemented using any suitable well-known personal computer, computing platform, computer server, etc. capable of receiving TV signals, receiving user inputs, and presenting (e.g., displaying signals on) a display device 105B. The hardware <NUM> is configured to operate (i.e., execute) any one of a variety of operating systems such as, for instance, Windows XP™, Windows NT™, Mac OS X™, Linux, Unix, etc..

In the illustrated example of <FIG>, the hardware <NUM> includes, among other things, circuitry to tune and receive TV signals from an antenna, satellite receiver, cable, cable set-top box, etc. (e.g., a TV tuner device contained on a peripheral component interconnect (PCI) card 105C), circuitry to receive and decode streaming video, decode video from DVD or compact disc (CD) discs, etc. Alternatively, or additionally, the hardware <NUM> includes a connection to a TV tuner device 105C, a DVD drive, a CD drive, etc. The hardware <NUM> also includes, and/or provides a suitable connection to, a display device 105B (e.g., computer display, video display, terminal, television, etc.) capable of displaying TV programs for a viewer of the PC based video. The hardware <NUM> further includes, and/or provides a suitable connection to, at least one input device (e.g., a keyboard, a mouse 105A, a remote control, a People Meter 105D, etc.) configured to allow the user to select a video source, select a TV station or program, control volume, identify the user, etc. The hardware <NUM> may optionally include a disk drive, or other suitable storage medium, for recording and replaying recorded TV programs. The People Meter 105D may, additionally or alternatively, be implemented as machine accessible instructions executing, for example, on the PC Hardware <NUM>. Example methods and apparatus to implement the example People Meter 105D are described in International Patent Application Serial Number <CIT> which is published as International Publication No. <CIT>.

In the example of <FIG>, the API <NUM> provides an interface between the PC based video application <NUM> and the hardware <NUM>. For example, the API <NUM> could provide a generic interface to receive channel selections from the user via an input device without the PC based video application <NUM> specifically knowing the technical details, brand, etc. of the input device. By including the API <NUM> in the example of <FIG>, the PC based video application <NUM> may be implemented wholly, or at least partially, without specific knowledge of the underlying devices, circuits, PCI cards, etc. comprising the hardware <NUM>. In one embodiment, the API <NUM> is provided by an operating system and implements a standardized interface between software (e.g., applications) executing on the hardware <NUM> (e.g., executing on a processor included in the hardware <NUM>) and other portions of the hardware <NUM>. For example, in a Windows XP based operating system a portion of the API <NUM> is implemented by the dynamic link library (DLL) USER32. DLL which is part of the Windows XP based operating system, that provides functions such as DrawWindow(), DrawText(), MousePress(), KeyPress(), etc. to enable applications to display information on a display device, receive user inputs, interact with the hardware, etc. Alternatively, a portion of the API <NUM> may be implemented by another program, device driver, etc. executing under the operating system.

Using any of a variety of techniques, the PC based video application <NUM> via the API <NUM> receives input signals and selections (e.g., channel selections, volume, user identification, etc.) from the user via the at least one input device, controls a TV tuning device, receives tuned TV signals from the TV tuning device, creates signals suitable for display on a display device, and sends the display signals to the display device. For example, the PC video application <NUM> interacts with the hardware <NUM> by making software API calls to functions provided by the operating system (i.e., the API <NUM>) such as, for instance, DrawText() to display TV channel numbers, KeyPress() to receive TV channel selections, etc. The example PC video application <NUM> of <FIG> may be implemented as machine readable instructions executing on a processor associated with the hardware <NUM>. However, the PC video application <NUM> may also be implemented as hardware or a combination of hardware and software.

In the example of <FIG>, the PC based video application <NUM> has access via the API <NUM> and the hardware <NUM> to an electronic program guide that, for example, specifies which TV programs are available on each TV station for each time period of each day of the week. It will be understood by persons of ordinary skill in the art that the electronic program guide may, for example, be provided as part of TV signals received and decoded by the hardware <NUM> (e.g., a TV tuning device). Using any of a variety of techniques, the PC based video application <NUM> provides to the user via a display device <NUM> at least a portion of the electronic program guide to facilitate selection of TV programs by the user. The PC based video application <NUM> may also use the electronic program guide to determine and display on the display device the name of the current TV program being viewed by the user.

To monitor and record viewing of TV programs viewed or consumed by the user, the example system of <FIG> includes a handler <NUM> and a meter <NUM>. The handler <NUM> processes (i.e., handles) all, or a subset of, the function calls, signals, instructions, values, etc. exchanged between the PC based video application <NUM> and the API <NUM>. For example, the handler <NUM> could process instructions sent from the PC video application <NUM> to a TV tuner device (e.g., the TV Tuner device 105C) specifying which TV station to receive; the handler <NUM> could process portions of the signals sent from the PC video application <NUM> to a display device (e.g., Video Display 105B) to display for the viewer the current TV program or TV station being viewed; the handler <NUM> could process signals sent by the PC video application <NUM> to a disk drive (e.g., contained within the hardware <NUM>) to open a new file into which a TV program is to be recorded, etc..

In one embodiment, the handler <NUM> is implemented as a metering DLL <NUM> and uses function call re-direction to process all, or a subset of, software API calls made by the PC video application <NUM> to the API <NUM>. The metering DLL <NUM> is programmed and loaded by the operating system such that all, or a subset of, calls made to the API <NUM> by the PC video application <NUM> are re-directed to the metering DLL <NUM>. It will be readily apparent to persons of ordinary skill in the art that for a Windows XP based operating system this can be accomplished using standard Windows API calls, for example, VirtualAllocEx(), WriteProcessMemory(), LoadLibrary() and CreateRemoteThread(). It will also be readily apparent that the loading of the metering DLL <NUM> by the operating system causes the metering DLL <NUM> to execute its own startup routine.

The startup routine for the metering DLL <NUM>, using well-known techniques, modifies and/or replaces at least one entry of the PC video application's <NUM> IMPORT TABLE (e.g., for DrawText()) with an address pointing to a replacement function provided by the metering DLL <NUM>. Using this technique, an example software call made to DrawText() by the PC video application <NUM> will instead be automatically re-directed to the metering DLL <NUM> to execute the replacement function provided by the metering DLL <NUM>. The replacement function provided by the metering DLL <NUM> may, in turn, make a corresponding software call to the standard DrawText() function provided by the API <NUM> using the address contained in the original PC video application's <NUM> IMPORT TABLE. The replacement function provided by the metering DLL <NUM> also passes, using standard operating system messaging techniques and/or function calls, information regarding the received re-directed API software call to the meter <NUM>. It will be well understood that by configuring the number, type, operation, etc. of the replacement functions provided by the metering DLL <NUM>, the standard API calls re-directed to the metering DLL <NUM> can be adjusted.

To allow proper video display in the example of <FIG>, the handler <NUM> passes (i.e., forwards) re-directed function calls, signals, instructions, values, etc. to the API <NUM>. To facilitate monitoring of TV viewing by the user, the handler <NUM> also passes a copy of appropriate re-directed function calls, signals, instructions, values, etc. (e.g., video source selections, TV channel selections, display mode, user identification, etc.) to the meter <NUM>. In the example of <FIG>, the handler <NUM> only re-directs those function calls, signals, instructions, values, etc. useful for monitoring TV viewing by the user (e.g., video source, TV channel selections, user identification, mode, volume muting, etc.). Other function calls, signals, instructions, values, etc. (e.g., volume, etc.) may be directly exchanged or configured between the PC based video application <NUM> and the API <NUM>. Alternatively, the handler <NUM> could re-direct all function calls, signals, instructions, values, etc. and pass all or a portion of them to the meter <NUM>.

<FIG> illustrates an example IMPORT TABLE <NUM> containing an entry for DrawText() that points to an address X1 corresponding to the DrawTextQ function provided by the API <NUM>. <FIG> illustrates an example IMPORT TABLE <NUM> modified by the metering DLL <NUM> such that calls to the DrawText() function made by the PC based video application <NUM> are re-directed to the metering DLL <NUM>. In particular, the entry for DrawText() in the IMPORT TABLE <NUM> is modified with a new address Y1 corresponding to a replacement function provided by the metering DLL <NUM>. Further, the metering DLL <NUM> uses the original address X1 to call the original function in the API <NUM>.

<FIG> is a schematic illustration of an example manner of implementing the handler <NUM> of <FIG>. To modify the IMPORT TABLE of the PC based video application <NUM>, the example of <FIG> includes a modifier <NUM>. As discussed above, the modifier <NUM> replaces one or more addresses in the IMPORT TABLE of the PC based video application <NUM> with addresses corresponding to replacement functions in the metering DLL <NUM>. The modifier <NUM> also creates entries in a table <NUM> that allow a redirector <NUM> to correctly forward received re-directed API calls made by the PC based video application <NUM> to the API <NUM>. To forward re-directed API calls to the API <NUM> and to pass re-directed API calls to the meter <NUM>, the example handler <NUM> of <FIG> includes the redirector <NUM>. Because the example redirector <NUM> of <FIG> forwards re-directed API calls to the API <NUM>, the correct and/or intended operation(s) of the example PC video application <NUM> is not interrupted and/or impaired even while video consumption metering is occurring. The example handler <NUM> of <FIG> may be implemented by a DLL as discussed herein, as machine readable instructions executing on a processing element associated with the hardware <NUM>, as dedicated hardware or circuitry, or as a combination of hardware and software,.

Returning to <FIG>, the meter <NUM> uses information contained in function calls, signals, instructions, values, etc. re-directed to the handler <NUM> and provided to the meter <NUM> to monitor and record TV viewing by the user. The meter <NUM> creates log entries that contain time-of-day, TV station and user identification. The log entries also contain TV program information (e.g., name of a viewed program, name of a TV station, a channel name, etc.) if that information is displayed on the display device and if the displaying uses a technique that can be re-directed to the handler <NUM>. In the example of <FIG>, the meter <NUM> creates a log entry each time a change in TV viewing occurs (e.g., video source change, a TV station change, a volume muting, a program break, an on/off event, a change in user, etc.). The meter <NUM> may also create log entries periodically or aperiodically during time intervals without changes in TV viewing parameters (e.g., every <NUM> minutes).

The example system of <FIG> periodically or aperiodically provides the recorded (i.e., logged) TV viewing information to a processing server (not shown) that combines the recorded TV viewing information with recorded TV viewing information from other TV metering systems (PC TV or otherwise) to develop meaningful viewership and/or program consumption statistics. For instance, the processing server of the illustrated example uses the combined recorded TV viewing information to determine overall TV viewership ratings and/or rankings for each time period of each day of the week, each TV program, etc. It will be understood by persons of ordinary skill in the art that the meter <NUM> could provide the recorded TV viewing information to the processing server using any of a variety of techniques. For instance, by periodically or aperiodically recording the information on a non-volatile storage medium (e.g., recordable compact disc (CD-R)) that can be transported (e.g., picked up, mailed, etc.) and then loaded onto the processing server; by uploading (e.g., via an Internet connection, dedicated network or public switched network accessible via the API <NUM> and the hardware <NUM>) the recorded information to the processing server; etc..

The meter <NUM> examines the API calls made by the PC video application <NUM> as re-directed to the metering DLL <NUM> for information necessary to monitor and log TV viewing by the user. For example, the meter <NUM> could examine the parameters contained in a call to DrawText() to identify if the PC video application <NUM> is displaying a TV station number and/or TV program name on the display device. As an example, the meter <NUM> could examine the parameters contained in a FileOpen() call to obtain the file name and, thus, the time and TV station information associated with a previously recorded TV program, etc. The example meter <NUM> utilizes standard API calls to obtain current time-of-day or day-of-the-week information. The meter <NUM> can be coupled to a People Meter to allow audience members (i.e., viewer) to identify themselves. Alternatively or additionally, the meter <NUM> could determine a viewer's identity based on who is logged into the operating system. As discussed above, the meter <NUM> creates a log of TV viewing and periodically or aperiodically provides the log to a processing server.

In the example of <FIG>, the meter <NUM>, upon startup, causes the metering DLL <NUM> to be loaded by the operating system (using techniques discussed above) such that at least one PC video application <NUM> IMPORT TABLE entry is modified. Upon normal termination of the operation of the meter <NUM>, the meter <NUM> causes the metering DLL <NUM> to be unloaded by the operating system such that replaced PC video application <NUM> IMPORT TABLE entries are restored to their original values so that future API calls are made directly to the API <NUM> and the PC video application <NUM> can continue operating.

The example meter <NUM> of <FIG> is implemented as machine readable instructions executing on a processor associated with the hardware <NUM>. However, the meter <NUM> may also be implemented as hardware or a combination of hardware and software.

The methods and apparatus described in this disclosure support a PC video application <NUM> that uses either standard operating system window controls or well-known "skins. " Skins based applications utilize standard API calls (e.g., DrawText()) to display textual information and, thus, are amenable to indirect data detection via API function call re-direction as described herein. Further, while the examples discussed herein and in connection with <FIG> are related to a Windows XP based operating system, it will be readily apparent to persons of ordinary skill in the art that similar techniques could be used for other operating systems (e.g., Windows NT, Windows ME™, Mac OS X, Unix, Linux, etc.).

It will be readily apparent to persons of ordinary skill in the art that the metering DLL <NUM> could additionally examine the parameters of re-directed API calls made by the PC video application <NUM> for information related to TV viewing by the user(s) (e.g., viewer(s)) and only pass parameters of interest to the meter <NUM>. It will also be readily apparent that the metering DLL <NUM> could process re-directed non-operating system based API calls made by the PC video application <NUM>. For example, the PC video application <NUM> may use customized or proprietary functions to interact with the hardware <NUM> (e.g., an external TV receiver device), for instance, to select a TV station. To the extent that the metering DLL <NUM> can access and/or decipher any customized or proprietary functions used by the PC video application <NUM> to interact with the hardware <NUM> and/or the API <NUM>, the methods described herein can be readily extended to re-direct such customized or proprietary functions.

<FIG> illustrate flowcharts representative of example machine readable instructions that may be executed by a processor (e.g., the processor <NUM> of <FIG>) to implement the example handler or metering DLL <NUM> and the example meter <NUM> of <FIG>. The machine readable instructions of <FIG> and/or <NUM>, the example API <NUM>, the example PC video application <NUM>, the example metering DLL <NUM>, the example meter <NUM> and/or, more generally, the example metering system of <FIG> may be executed by a processor: a controller and/or any other suitable processing device. For example, the machine readable instructions represented in <FIG> and/or <NUM>, the example API <NUM>, the example PC video application <NUM>, the example metering DLL <NUM>, the example meter <NUM> and/or, more generally, the example metering system of <FIG> may be embodied in coded instructions stored on a tangible medium such as a flash memory, a read-only memory (ROM) and/or a random-access memory (RAM) associated with the processor <NUM> shown in the example processor platform <NUM> and discussed below in conjunction with <FIG>. Alternatively, some or all of the example machine readable instructions of <FIG> and/or <NUM>, the example API <NUM>, the example PC video application <NUM>, the example metering DLL <NUM>, the example meter <NUM> and/or the metering system of <FIG> may be implemented using any variety of application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), field programmable logic device(s) (FPLD(s)), discrete logic, hardware, etc. Also, some or all of the machine readable instructions of <FIG> and/or <NUM>, the example API <NUM>, the example PC video application <NUM>, the example metering DLL <NUM>, the example meter <NUM> and/or the metering system of <FIG> may be implemented manually or as any combination of any of the foregoing techniques. Further, although the example machine readable instructions of <FIG> are described with reference to the flowcharts of <FIG>, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example metering DLL <NUM> and the example meter <NUM> may be employed. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, sub-divided, or combined. Additionally, persons of ordinary skill in the art will readily appreciate that the example machine accessible instructions of <FIG> and/or <NUM> may be carried out sequentially and/or carried out in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc..

The example machine readable instructions of <FIG> begin when the meter <NUM> is started. Using standard API calls (e.g., VirtualAllocEx(), WriteProcessMemory(), LoadLibrary(), CreateRemoteThread()), the meter <NUM> causes the operating system (e.g., Windows XP) to load the metering DLL <NUM> (block <NUM>). The loading of the metering DLL <NUM> (block <NUM>) by the operating system starts the execution of the example machine readable instructions of <FIG> in a processing thread separate from that executing the example machine readable instructions of <FIG> (i.e., the meter <NUM>). As discussed above in connection with <FIG> and below in connection with <FIG>, the meter <NUM> (e.g., the machine readable instructions of <FIG>) and the metering DLL <NUM> (e.g., the machine readable instructions of <FIG>) interact to determine video and/or program viewing, display and/or consumption by a person.

The meter <NUM> then waits for the metering DLL <NUM> to receive a new re-directed API call and to provide the parameters of the re-directed API call to the meter <NUM> (i.e., an event) (block <NUM>). If a new event has not occurred (block <NUM>), the meter <NUM> continues waiting (block <NUM>). If a new event has occurred and information has been received (block <NUM>), the meter <NUM> determines if the re-directed API call is an event of interest (e.g., DrawText(), or more generally, an event associated with an interaction between the PC video application <NUM> and the metering DLL <NUM>) (block <NUM>). If the re-directed API call is not an event of interest (block <NUM>), the meter <NUM> returns to block <NUM> to await another event.

If the re-directed API call is an event of interest (block <NUM>), the meter <NUM> decodes the information re-directed to and received from the metering DLL <NUM> (e.g., TV channel selection, video source, etc.) (block <NUM>). The meter <NUM> then acquires time-of-day, day-of-week, user identification, etc. information (block <NUM>), and creates a log entry based on the decoded and acquired information and data (block <NUM>). The meter <NUM> then returns to block <NUM> to await another event.

The example machine readable instructions of <FIG> begin when the metering DLL <NUM> is loaded by the operating system (e.g., Windows XP). As discussed above and in connection with <FIG>, the metering DLL <NUM> modifies the IMPORT TABLE of the PC video application <NUM> so that calls to API functions replaced by the metering DLL <NUM> are re-directed to the metering DLL <NUM> (block <NUM>). The metering DLL <NUM> also saves the original IMPORT TABLE entries so that these original entries can be restored when the metering DLL <NUM> is unloaded by the operating system and so that the metering DLL <NUM> calls the proper function in the API <NUM> when API calls are re-directed (block <NUM>).

The metering DLL <NUM> then waits for one of the replacement functions provided by the metering DLL <NUM> to be called by the PC video application <NUM> (i.e., an API call re-direction has occurred) (block <NUM>). If an API call has been re-directed to the metering DLL <NUM> (block <NUM>), the metering DLL <NUM> calls the corresponding API function in the API <NUM> (block <NUM>). By calling the corresponding API function in the API <NUM>, the metering DLL <NUM> ensures that the PC video application <NUM> is not interrupted, impaired and/or prevented from correctly presenting video. The metering DLL <NUM> then determines if the re-directed API call is an event of interest (block <NUM>). For example, by comparing the parameters of a DrawText() API call with a character string corresponding to a channel name, channel number, or TV program name (block <NUM>). If the re-directed API call is not an event of interest (block <NUM>), the metering DLL <NUM> returns to block <NUM> to await another API call re-direction. If the re-directed API call is an event of interest (block <NUM>), the metering DLL <NUM> pass the parameters of the re-directed API call to the meter <NUM> (block <NUM>) and returns to block <NUM> to await another API call re-direction.

<FIG> is a schematic diagram of an example processor platform <NUM> capable of executing the example machine readable instructions represented in <FIG>, and/or implementing the example API <NUM>, the example PC video application <NUM>, the example metering DLL <NUM>, the example meter <NUM> and/or, more generally, the metering system of <FIG>. For example, the processor platform <NUM> can be implemented by one or more general purpose microprocessors, microcontrollers, etc..

The processor platform <NUM> of the example of <FIG> includes a general purpose programmable processor <NUM>. The processor <NUM> executes coded instructions <NUM> and/or <NUM> present in main memory of the processor <NUM> (e.g., within a RAM <NUM> and/or a ROM <NUM>). The processor <NUM> may be any type of processing unit, such as a microprocessor from the Intel®, AMD®, IBM®, or SUN® families of microprocessors. The processor <NUM> may implement, among other things, the example machine readable instructions of <FIG>, the example API <NUM>, the example PC video application <NUM>, the example metering DLL <NUM>, the example meter <NUM> and/or metering system of <FIG>.

The processor <NUM> is in communication with the main memory (including a read only memory (ROM) <NUM> and the RAM <NUM>) via a bus <NUM>. The RAM <NUM> may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic DRAM, and/or any other type of RAM device. The ROM <NUM> may be implemented by flash memory and/or any other desired type of memory device. Access to the memory <NUM> and <NUM> is typically controlled by a memory controller (not shown).

The processor platform <NUM> also includes an interface circuit <NUM>. The interface circuit <NUM> may be implemented by any type of well-known interface standard, such as an external memory interface, serial port, general purpose input/output, etc..

One or more input devices <NUM> and one or more output devices <NUM> are connected to the interface circuit <NUM>. The input devices <NUM> and output devices <NUM> may be used to implement interfaces between a user and the example metering system of <FIG>.

Of course, persons of ordinary skill in the art will recognize that the order, size, and proportions of the memory illustrated in the example systems may vary. Additionally, although this patent discloses example systems including, among other components, software or firmware executed on hardware, it will be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware or in some combination of hardware, firmware and/or software. Accordingly, persons of ordinary skill in the art will readily appreciate that the above described examples are not the only way to implement such systems.

At least some of the above described example methods and/or apparatus are implemented by one or more software and/or firmware programs running on a computer processor. However, dedicated hardware implementations including, but not limited to, an ASIC, programmable logic arrays and other hardware devices can likewise be constructed to implement some or all of the example methods and/or apparatus described herein, either in whole or in part. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the example methods and/or apparatus described herein.

It should also be noted that the example software and/or firmware implementations described herein are optionally stored on a tangible storage medium, such as: a magnetic medium (e.g., a disk or tape); a magneto-optical or optical medium such as a disk; or a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; or a signal containing computer instructions. A digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the example software and/or firmware described herein can be stored on a tangible storage medium or distribution medium such as those described above or equivalents and successor media.

Claim 1:
A method performed by a processor (<NUM>) that is to execute an operating system, a personal computer video application (<NUM>), an application programming interface (<NUM>), a handler (<NUM>), and a meter (<NUM>), the method comprising:
re-directing, by the handler, a subset of function calls made by the personal computer video application to the application programming interface, wherein the handler only re-directs function calls useful for monitoring TV viewing by the user, and wherein other function calls are directly exchanged between the personal computer video application and the application programming interface;
forwarding, by the handler, the re-directed function calls to the application programming interface and passing, to the meter, corresponding copies of the re-directed function calls;
determining, by the handler and by the meter, which of the re-directed function calls are an event of interest, wherein re-directed function calls which correspond to a command to display textual information on a display are determined to be an event of interest by comparing the parameters of the respective re-directed function call with a character string corresponding to at least one of a channel name, a channel number, or a television program name;
for re-directed function calls which are an event of interest:
passing, by the handler, parameters of the particular re-directed function call to the meter; and
decoding, by the meter, information corresponding to the particular re-directed function call re-directed to the meter by the handler and creating a log entry based on the decoded information and at least one of time-of-day, day-of-week, and user identification data.