WO2000016552A1

WO2000016552A1 - Audience monitoring and reporting system

Info

Publication number: WO2000016552A1
Application number: PCT/US1999/021056
Authority: WO
Inventors: Hamid M. Qayyum; Stephen W. Lehner
Original assignee: Millennium Networks, Inc.
Priority date: 1998-09-15
Filing date: 1999-09-14
Publication date: 2000-03-23
Also published as: CA2343989A1; AU1091600A; EP1142325A1

Abstract

An apparatus and method are disclosed for monitoring and reporting TV habits of TV viewers. In accordance with the invention, information representative of TV habits is monitored and stored within a TV (12) or set top box (16), controlled from a remote location such as a cable service provider location. Control signals may be communicated to the set top box (16) or TV (12) via RF or electrical connections, such as CATV wire (10). The information may be reported through the remote location by the same or alternate means, such as in an unused portion of the video signal bandwidth or, telephone line (11), or video frequency modem (30).

Description

AUDIENCE MONITORING AND REPORTING SYSTEM

Field of the Invention

The present invention relates generally to methods for monitoring the television viewing habits of television viewers and more particularly to a method for ^~~ monitoring television viewing habits which comprises storing information representative of television viewing habits in either a television or a set top box and subsequently transmitting the stored information to a remote location.

Background of the Invention Monitoring the television viewing habits of television viewers provides information which is valuable to cable service providers, television programmers, advertisers, and the like. Cable service providers and television programmers use information regarding television viewing habits to define programming. Thus, television programs which are widely viewed may be rescheduled for better viewing times, while television programs that are less well viewed may be rescheduled for periods of time when fewer viewers are watching television, or may be removed.

Advertisers need to know how many people are viewing different television programs, to determine how their advertising money is best spent. Of course, an advertiser will be willing to pay more for advertising time during a very popular television program, than for the same amount of time during less well watched television programs.

As such, it is well accepted that information relating to the viewing habits of television viewers is valuable and should be collected. One prior art attempt to collect such information regarding the viewing habits of television viewers has been to provide an electronic device, which typically sits atop a television, to record which channel is being watched and at what time the channel is being watched. Such electronic devices may be wired either directly into a television set, or may work in cooperation with a cable service provider set top box.

As those skilled in the art will appreciate, the cable service provider set top box is used to receive a plurality of channels provided by the cable service provider to be viewed at any given time. Thus, it is a comparatively simple matter to provide electrical communication between the set top box and recording device which records the time and the channel selected by the set top box.

However, one deficiency associated with such prior art recording devices is that it is typically necessary for a representative of the data collecting entity to actually visit each house wherein such data is being recorded, so as to download the data collected by the recording device.

According to one prior art attempt to mitigate the problems associated with such manual collection of data, a modem is used to transmit the recorded data via telephone to the intended recipient.

According to another prior art attempt to mitigate the problems associated with such manual data collection, a radio transmitter is used to transmit the recorded data.

Another problem associated with the collection of data regarding the television viewing habits of television viewers is the requirement for a separate electronic device for collecting and storing the time and channel data. Not only does the use of such an additional device require delivery and labor intensive installation, but it is also frequently considered undesirable to have another device sitting atop or near their television. Typically, the television set and/or the surrounding area will already be cluttered with various electronic devices such as a VCR, a DVD player, stereo equipment, as well as many other electronic devices which are frequently used so as to provide entertainment and/or enhance viewing. Thus, the addition of another electronic device, particularly one which does not provide any direct enhancement of television viewing, is frequently undesirable. —

In view of the forgoing, it is desirable to provide a method for monitoring the television viewing habits of television viewers which does not require installation of an additional electronic device on or near television viewers television, and which does not require the collection of data recorded thereby by a person visiting the home of the viewer.

Summary of the Invention

The present invention specifically addresses and alleviates the above-mentioned deficiencies associated with the prior art. More particularly, the present invention comprises a method and apparatus for monitoring television viewing habits of a television viewer. In accordance with the present invention information representative of television viewing habits is stored within either a television or a set top box, such as those provided by cable television service providers for selecting the channel to be viewed. The information representative of the television viewing habits is systematically transmitted to a remote location, such as to a cable service provider, for processing and distribution thereof. As those skilled in the art will appreciate, both contemporary set top boxes and televisions utilize microprocessor control . Such contemporary set top boxes and televisions comprise a memory which stores instructions for the microprocessor. It will further be appreciated that such memories are typically selected so as to have excess capacity in order to facilitate future changes and upgrades in the instruction set. According to the preferred embodiment of the present invention, instructions for monitoring viewing habits and for storing the results may be added to the existing instruction set stored within the set top box microprocessor memory, or in memory space within the television. —

Those skilled in the art will further appreciate that such memories frequently comprise flash memories, that may be changed or updated easily. According to the preferred embodiment of the present invention, such flash memories are configured such that they may be remotely updated, via an unused portion of the video signal which the cable service provider uses to bring cable service to the television viewer. Alternatively, such flash memories may be changed or upgraded via telephone connection. In this manner, instructions as required to monitor and record television viewing habits may be stored in the flash memory, and updated merely by transmitting instruction set up from the cable service provider, or other remote location.

As those skilled in the art will further appreciate, some cable television service providers provide bidirectional service, wherein bi-directional communication may be utilized by the television viewer for various different transactions, such as buying food or other products, transferring funds, and/or Internet access. Where cable Internet access is provided, instructions necessary to monitor and record television viewing information may be communicated to the desired set top box and/or television via the Internet, from any convenient location.

Further, when such Internet service is provided, the results of television viewer habit monitoring may be similarly downloaded via the Internet to any convenient location. Thus, the results of such television viewer habit monitoring may be transferred to a web page, if desired. Information representative of television viewing habits typically comprise code, time, channel, and channel source information. Identification codes identify the particular television viewer whose habits are being monitored. That is, the identification code which is associated with the set top box or television, — for a particular television viewer. Time information is typically indicative of the time at which channel is changed, so as to facilitate generation of a report which shows times at which particular channels are being viewed. The channel information identifies that channel which is being viewed by the television viewer. The channel source code is representative of where the television signal originates from, e.g., broadcast, cable, etc.

According to one embodiment of the present invention, information representative of television viewing habits may be stored in volatile memory. However, in another embodiment the information may be stored in non-volatile memory. In this manner, the information is maintained in the event of a power outage or if the set top box or television is unplugged.

According to one preferred embodiment of the present invention, only channel information for channels which are watched for a predetermined length of time is recorded. Thus, when the television viewer is rapidly changing channels, this information is not stored. The information regarding channels being viewed is preferably only stored when the channel has remained constant for a predetermined length of time, e.g., one minute.

The stored information is preferably transmitted periodically to a remote location. Transmission may be preformed at a predetermined time each day, or after a predetermined interval of time. Thus, for example, the stored information may be transmitted at 2:00 A.M. each day. Alternatively, the information may be transmitted after each 24 hours of television viewing. In one embodiment, the stored information is downloaded when the memory in which the stored information resides nears its storage capacity. In this manner, the memory is transmitted and cleaned prior to becoming full, so as to prevent any loss of data due to memory overload. In another embodiment, stored — information is transmitted to the remote location only when requested by a remote host . The remote host may perform a polling procedure so as to request data from a plurality of such memories, sequentially, or in some other ordered manner.

According to the preferred embodiment of the present invention, the stored information is downloaded to a remote location via bi-directional cable television cable. Alternatively, the stored information may be transferred via telephone. A radio modem may be utilized to transmit the stored information to the remote location, such as a centrally located cell site which receives information from a plurality of home radio modems.

Thus, according to the present invention, set top box is provided for facilitating cable television service and for monitoring the television viewing habits of television viewers. The set top box comprises an input port for receiving a plurality of cable television channels; and output port for communicating at least one television channel to television; a non-volatile memory for storing instructions for monitoring of television viewing; a volatile memory for storing information representative of television viewing; and monitoring software configured to monitor which channel is being viewed according to instruction stored in the nonvolatile memory and for storing information representative of which channel is being viewed and at which time, in the volatile memory.

A data output circuit of the set top box transmits stored data representative of television viewing habits to the remote location via the cable television cable. Of course, this embodiment of the present invention requires that the television cable be configured for bidirectional communications. Alternatively, particularly in the event that the cable television cable is not configured for bi- — directional communications, a telephone data output circuit transmits the stored data to the remote location via telephone. In a further option, viewer data may be transmitted to the remote location via a radio, such as a radio modem.

Non-volatile memory preferably comprises a flash memory, such that it may be changed and/or upgraded easily. Such a flash memory may be changed and/or upgraded via the television cable. The volatile memory preferably comprises RAM (Random Access Memory) .

According to a second embodiment of the present invention the monitoring and storage of the viewer data is performed within the television, rather than within a set top box. The circuitry and methodology of the second embodiment is similar to that of the first embodiment. Rather than sensing selection of channels at the set top box, the sensing is performed within the television itself. The television comprises an input port for receiving a plurality of television signals (cable and/or analog or digital broadcast) . The second embodiment of the present is particularly useful when cable ready televisions are utilized. As those skilled in the art will appreciate, such cable ready televisions do not require a set top box. As in the first embodiment, nonvolatile memory is utilized for storing instructions for performing monitoring of television viewing and volatile memory is utilized for storing information representative of television viewing habits. Again, software is used to monitor which channel is being viewed according to the instructions stored in the non-volatile memory and volatile memory stores information representative of which channel is being viewed and at what time.

As in the first embodiment of the present invention, stored data representative of television viewing habits is transmitted to the remote location via either a cable television cable, a television data output circuit, or — via radio, e.g., a radio modem.

Thus, according to the present invention, need for a separate, stand alone electronic device, as well as the disadvantages associated therewith, are voided. Viewer monitoring takes place in either the set top box or the television and may be performed merely by loading the instruction set into a memory of the television or the set top box and causing the instructions to execute so as to facilitate such monitoring, storing and down-loading. Instruction sets may be loaded into the television or the set top box via the cable television cable, telephone line, or via a radio modem, if desired.

These, as well as other advantages of the present invention will be more apparent from the following description and the drawings. Note that changes in the specific structure shown and described may be made within the scope of the claims without departing from the spirit of the invention.

Brief Description of the Drawings Figure 1 is a block diagram of a first embodiment of the present invention wherein the television viewing habits are monitored via the set top box, such as those commonly used by cable service providers;

Figure 2 is a block diagram of the set top box of Figure 1, showing use of the cable television cable for transmitting monitoring results to a remote location;

Figure 3 is a block diagram of the set top box of Figure 1, showing use of the telephone line for transmitting monitoring results to a remote location;

Figure 4 is a block diagram of the set top box of Figure 1, showing use of the radio modem for transmitting monitoring results to a remote location;

Figure 5 is a block diagram of the second embodiment of the present invention wherein monitoring of viewing habits is performed within the television;

Figure 6 is a block diagram of the television of ^~" Figure 5, showing use of the cable television cable for transmitting monitoring results to a remote location;

Figure 7 is a block diagram of the television of Figure 5, showing use of the telephone line for transmitting monitoring results to a remote location;

Figure 8 is a block diagram of the television of Figure 5, showing use of the radio modem for transmitting monitoring results to a remote location; Figure 9 is a block diagram illustrating the basic structure of a system for generating, receiving and processing audience viewing information; and,

Figure 10 is an illustration of a redundant system such as that shown at Figure 9. Figure 11 is an illustration of another system level embodiment of the invention wherein control signals, video signals, and audience viewing information is communicated via the direct connection with the cable service provider.

Detailed Description of the Preferred Invention

The detailed description set forth below in connection with the appended drawings is intended as a description of presently preferred embodiments of the invention, and is not intended to represent the only forms in which the present invention may be constructed or utilized. The invention sets forth the functions and the sequence of steps for constructing and operating the invention in connection with the illustrated embodiments. It is to be understood, however, that the same or equivalent functions may be accomplished by different embodiments that are also intended to be encompassed within the spirit and scope of the invention.

The audience engine of the present invention is illustrated in Figures 1-8 which depict two presently preferred embodiments thereof.

Referring now to Figure 1, according to the first — embodiment of the preferred invention cable 10 from the cable television provider provides a plurality of channels to set top box 16 via an input port 14 thereof. The set top box 16 operates according to well known principles to facilitate the selection by the television viewer, of a desired channel which is then provided via output port 15 though television 12.

According to the first embodiment of the present invention, the monitoring of television viewing habits is performed within the set top box 16 and facilitates such monitoring and communicating back to the cable television provider, or any other desired remote location (remote from the location of the television viewer) . The set top box 16 may be implemented as a programmable cable controller, such as the CFT 2200 or DCT series controller marketed by General Instruments . When programmed in accordance with the present invention the monitored results may be communicated to the remote location via various means such as via the cable television cable 10, via a telephone line 11 (Figure 3), and/or via a radio modem 30 (Figure 4) , as discussed in detail below. Cable 10 may be implemented as a bidirectional cable such that commands to the set top box may be communicated in a first unused portion of the video signal, and data downloads may proceed in the same or a separate unused portion of the video signal bandwidth. Use of telephone lines or modems may similarly proceed in a bidirectional manner, or may proceed in a single direction with the cable 10 providing the second communication path.

Referring now to Figure 2, the set top box 16 comprises a channel selector 18 which is utilized according to well known principles to facilitate the selection of a desired one of the plurality of channels provided by the cable television cable 10 to the television 12. According to the present invention a programmable monitoring circuit 20 is disposed in communication with — the channel selector 18 such that the monitoring circuit 20 recognizes changes in the channel selected by the channel selector 18. The monitoring circuit 20 also stores such channel changes into memory 22, along with the time of such channel changes.

Cable data output 24 transmits data representative of the viewer monitoring information stored in memory 22 to a desired remote location, via cable television cable 10.

Referring now to Figure 3, alternatively, telephone data output 26 is in communication with memory 22 so as to facilitate the communication of viewing data to a desired remote location via telephone line 11. Those skilled in the art will appreciate, some set top boxes may be manufactured so as to facilitate communication via telephone, thereby providing a return path for television viewers who wish to perform transactions for paying pay-per-view services via the telephone. Referring now to Figure 4, the radio modem output 28 is alternatively in communication with memory 22 so as to facilitate the communication of viewing habit data to a desired remote location via radio modem 30.

Referring now to Figure 5, according to a second embodiment of the preferred invention cable 10 from the cable television provider provides a plurality of channels to television 12 via an input port 13 thereof. The television 12 operates according to well known principles to facilitate the selection by the television viewer, of a desired channel.

According to the second embodiment of the present invention, the monitoring of television viewing habits is performed within the television 12 and facilitates such monitoring and communicating back to the cable television provider, or any other desired remote location (remote from the location of the television viewer) . The monitoring results may be communicated to the remote location via various means such as via the cable __ television cable 10, via a telephone line 11 (Figure 7), and/or via a radio modem 30 (Figure 8) , as discussed above . Referring now to Figure 6, television 12 comprises a channel selector 19 which is utilized according to well known principles to facilitate the selection of a desired one of the plurality of channels provided by the cable television cable 10 to the television 12. According to the present invention a programmable monitoring circuit 21 is disposed in communication with the channel selector 19 such that the monitoring circuit 21 recognizes changes in the channel selected by the channel selector 19. The monitoring circuit 21 also stores such channel changes into memory 23, along with the time of such channel changes. The monitoring circuit may be programmed in accordance with the present invention, a the time the television is constructed. Alternatively the television may be constructed to select programmable access to internal microprocessors via cable, telephone line and/or radio modem. In the presently preferred embodiment of the invention depicted at Figures 5-8, programming is located in unused memory space at the time the television is manufactured. Cable data output 25 transmits data representative of the viewer monitoring information stored in memory 23 to a desired remote location, via bi-directional cable television cable 10.

Referring now to Figure 7, alternatively, telephone data output 27 is in communication with memory 23 so as to facilitate the communication of viewing data to a desired remote location via telephone line 11. Those skilled in the art will appreciate, some televisions may be manufactured so as to facilitate communication via telephone, thereby providing a return path for television viewers who wish to perform transactions for paying pay- per-view services via the telephone.

Referring now to Figure 8, the radio modem output 29 — is alternatively in communication with memory 23 so as to facilitate the communication of viewing habit data to a desired remote location via radio modem 30. Figure 9 is a block diagram illustrating the basic structure of the system for generating, receiving, and processing the audience viewing information according to the present invention.

Figure 10 is an illustration of a redundant system in conformance with that set forth at Figure 9. It should be understood that the embodiment set forth at Figure 9 and 10 are premised upon a radio modem embodiment of the invention, such as that set forth in connection with Figures 4 and 8. As one of skill in the art will recognize, alternate embodiments of the systems set forth at Figures 9 and 10 that may be similarly implemented to support the embodiments of the invention set forth at Figures 2 , 3 , 6 and 7.

Referring to Figure 9, a system is shown wherein inbound cable information, e.g., conventional programs and command instructions are communicated to set top box 16, which may be implemented as Model CFT 2200 Cable Box marketed by General Instruments. Resident within the set top box 16 is programming information as described above, and as exemplified in the programming information set forth below. The set top box 16 functions to send data that reported viewing information data to the in-home radio modem 30, which may function to receive and transmit data by radio frequency protocol . The base station server 31 may be implemented as a personal computer running software, such as that Sockeye set forth in our co-pending application Serial Number 09/069,609 for data communication system, assigned to the common assignee. Base station server 31 functions to collect data from the in-home modem 30 and to communicate that data to a primary application server 33. The primary application server 33 may also be implemented as a personal computer that functions to collect data from a — plurality of base station servers 31, and compile that data. The primary application server 33 may be implemented as a web server to allow users to view the data compiled by the primary application server 33.

Figure 10 illustrates a plurality of systems, such as that disclosed at Figure 9, coordinated to common primary application server 33, via a plurality of base station servers 31, interconnected to a public network 35, which may be implemented at the internet.

Figure 11 illustrates another system level embodiment of the invention, wherein signals to and from the set top box 16 or implemented through cable 10, rather than partially through radio modem 30 as illustrated at Figure 10. As such, the system level instrumentation of Figure 11 corresponds more to a system level implementation of the construction set forth at Figures 2 and 6.

According to Figure 11, signals to and from the set top box 16 are implemented by cable links 10a and 10b, which may be implemented as a single cable, but are shown as separate for purposes of distinguishing upstream and downstream signals. The downstream signals communicated on cable 10a include control signals as well as scrambled, modulated video signals. The upstream signals, communicated on cable 10b, include viewer generated viewing information, collected in accordance with the present invention. Cables 10a and 10b are communicated to head end 37, typically a facility operated by the cable television provider. Signals from the head end 37 are communicated to head end server 31 via eithernet connection 39 and controller 32. As will be apparent to one of ordinary skill in the art, the implementation shown at Figure 10 and 11 are representative of various constructions that may be implemented within the broader aspects of the invention. In each case the implementation permits remote control over the operation of the audience monitoring device, and __ downloading of audience viewing data without the need to physically be present at the audience viewing location. Accordingly various enhancements and modifications of the invention may be implemented without departing from the broader aspects of the invention.

Set forth below is an instruction set, known as the audience engine, for implementing the present invention. The Audience Engine is an application that runs within a set-top cable converter, or a television e.g., General Instrument (GI) Corporation CFT-2200. This application will monitor the channel watching characteristics of individuals watching television and report the information on a return line e.g., an upstream cable (FSK) channel. This information will be reported on a repeated basis and is intended to interface a server database such as that set forth in co-pending application serial number 09/069,609 for Data Communication System, assigned to the common assignee, designated as Sockeye . The substance of that disclosure is incorporated by reference herein. Set-top Information

This section describes how to prepare the audience engine application for the General Instruments CFT2200 set-top box .

Programming the Production CFT2200

To program a production CFT2200 execute the following steps :

The sockeye. c, sockeye. abs, soc3100.det, 3100SOC7.dat, and 3100SOC?.dsc files (where "?" is the revision). Put the . dat and .dsc files on a blank floppy. Connect the CFT to be programmed to the OLL PC . Power on the OLL PC.

Insert the floppy in the OLL PC.

Select command 3, load files from floppy, in the OLL program. Select command 2, off- line loader, in the OLL program.

This will convert the new files into a downloadable set __ of files.

Set the active file to the 3100soc? file. If this is not the active file, you need to deselect the current active and select the new file using the commands in the monolithic file menu.

Program the CFT2200 by executing command 1, send monolithic .

Audience Engine Disk Contents The Audience Engine disk contains the following:

Sockeye. c, the source code.

Sockeye. abs, output from linker.

3100SOC4.dat, actual downloaded data file.

3100SOC4. dsc , description of downloaded file. Sock3100. det , specifies objects to download.

Known Problems

The following problems were found during testing:

Must use b6-0(7) ROMs or above.

Head End Information This is the Catalog.dat file for the ACC4000. The highlighted lines are lines we changed.

This is the data file for the IR Blaster quick implementation. In Phase II, this info will be maintained in the database. The data begins in the 5th line of the file. This is the general catalog information.

1 [005] Number of minutes for next download (0 = no downloading)

05 [006] Catalog sequence number Just increment the number every time you change the file.

01 [007] Catalog revision number 1994 [008 ] Year for catalog implementation

10 [ 009 ] Month for catalog implementation

31 [ 010 ] Day for catalog implementation

12 [ Oil ] Hour for catalog implementation

3 0 [ 012 ] Minute for catalog implementation

14 [ 013 ] Number of catalog entries —

DS_CATL1 [100] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters) 1 [101] Catalog entry - number of catalog records for this catalog entry

1 [102] Catalog entry - preferred catalog record for this catalog entry

16 [ 110 ] Catalog record - device 0 000 [ [111111]] Catalog record - device details

00 [ 112 ] Catalog record - data use

00 [ 113 ] Catalog record - data use details

00 [ 114 ] Catalog record - application id

00 [115] Catalog record - channel 0 011 [ [111166]] Catalog record - channel type

DL_SYSL1 [200] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters)

1 [201] Catalog entry - number of catalog records for this catalog entry

1 [202] Catalog entry - preferred catalog record for this catalog entry

16 [210 ] Catalog record - device

00 [211 ] Catalog record - device details 0 000 [ [221122]] Catalog record - data use

00 [213 ] Catalog record - data use details

01 [214] Catalog record - application id

00 [215 ] Catalog record - channel

01 [216] Catalog record - channel type DL_PLAT1 [300] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters) 1 [301] Catalog entry - number of catalog records for this catalog entry

1 [302] Catalog entry - preferred catalog record for this catalog entry

16 [ 310 ] Catalog record - device

00 [ 311 ] Catalog record - device details

00 [ 312 ] Catalog record - data use

00 [ 313 ] Catalog record - data use details

02 [314 ] Catalog record - application id

0000 [[331155]] Catalog record - channel

01 [316 ] Catalog record - channel type

DL_APPL1 [400] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters) 1 [401] Catalog entry - number of catalog records for this catalog entry

1 [402] Catalog entry - preferred catalog record for this catalog entry

16 [410] Catalog record - device 0 000 [ [441111]] Catalog record - device details

00 [412 ] Catalog record - data use

00 [413 ] Catalog record - data use details

03 [414 ] Catalog record - application id

00 [415 ] Catalog record - channel 0 011 [ [441166]] Catalog record - channel type

DL_CTRL1 [500] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters)

1 [501] Catalog entry - number of catalog records for this catalog entry

1 [502] Catalog entry - preferred catalog record for this catalog entry

16 [510 ] Catalog record - device

00 [511] Catalog record - device details 0 000 [ [551122]] Catalog record - data use

00 [513 ] Catalog record - data use details

04 [514 ] Catalog record - application id 00 [515] Catalog record - channel

01 [516] Catalog record - channel type DEF-IPG [600] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than 8 characters)

1 [601] Catalog entry - number of catalog records — for this catalog entry

1 [602] Catalog entry - preferred catalog record for this catalog entry

1166 [[661100]] Catalog record - device

00 [ 611 ] Catalog record - device details

00 [ 612 ] Catalog record - data use

00 [ 613 ] Catalog record - data use details

256 [ 614 ] Catalog record - application id

0000 [[661155]] Catalog record - channel

01 [616 ] Catalog record - channel type

OSD [ 700 ] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than 8 characters) 1 [701] Catalog entry - number of catalog records for this catalog entry

1 [702] Catalog entry - preferred catalog record for this catalog entry

00 [ 710 ] Catalog record - device 1 166 [ [771111]] Catalog record - device details

02 [ 712 ] Catalog record - data use

02 [ 713 ] Catalog record - data use details

00 [714] Catalog record - application id

00 [715 ] Catalog record - channel 0 011 [ [771166]] Catalog record - channel type

DCRCHNAM [800] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than 8 characters)

1 [801] Catalog entry - number of catalog records for this catalog entry

1 [802] Catalog entry - preferred catalog record for this catalog entry 16 [ 810 ] Catalog record - device

00 [ 811 ] Catalog record - device details

00 [ 812 ] Catalog record - data use

00 [ 813 ] Catalog record - data use details

10 [ 814 ] Catalog record - application id

00 [ 815 ] Catalog record - channel —

01 [ 816 ] Catalog record - channel type

IrbVendr [900] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than 8 characters)

1 [901] Catalog entry - number of catalog records for this catalog entry

1 [902] Catalog entry - preferred catalog record for this catalog entry 0 000 [ [991100]] Catalog record - device

16 [ 911 ] Catalog record - device details

00 [ 912] Catalog record - data use

00 [ 913 ] Catalog record - data use details

09 [ 914 ] Catalog record - application id 3 311 [ [991155]] Catalog record - channel

01 [ 916 ] Catalog record - channel type

IrbXRefr [A00] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters) 1 [A01] Catalog entry - number of catalog records for this catalog entry

1 [A02] Catalog entry - preferred catalog record for this catalog entry

00 [A10] Catalog record - device 1 166 [ [AAllll]] Catalog record - device details

00 [A12 ] Catalog record - data use

00 [A13 ] Catalog record - data use details

09 [A14 ] Catalog record - application id

31 [A15 ] Catalog record - channel 0 011 [ [AA1166]] Catalog record - channel type IrbDevDt [BOO] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than

8 characters)

1 [B01] Catalog entry - number of catalog records for this catalog entry

1 [B02] Catalog entry - preferred catalog record __ for this catalog entry

00 [BI O ] Catalog record - device

16 [Bl l ] Catalog record - device details

0000 [[BB1122]] Catalog record - data use

00 [B13 ] Catalog record - data use details

09 [B14 ] Catalog record - application id

3 7 [B15 ] Catalog record - channel

01 [B16 ] Catalog record - channel type MenuLogo [C00] Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than 8 characters)

1 [C01] Catalog entry - number of catalog records for this catalog entry 1 [C02] Catalog entry - preferred catalog record for this catalog entry

16 [CIO ] Catalog record - device

00 [Cll] Catalog record - device details

00 [C12 ] Catalog record - data use 0 000 [ [CC1133]] Catalog record - data use details

11 [C14 ] Catalog record - application id

00 [C15 ] Catalog record - channel

01 [C16 ] Catalog record - channel type FEM_CNFG[D00] - Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than 8 characters)

01 [D01] - Catalog entry - number of catalog records for this catalog entry

01 [D02] - Catalog entry - preferred catalog record 16 [D10] - Catalog entry - device

00 [Dll] - Catalog entry - device details 00 [D12] - Catalog entry - data use 00 [D13] - Catalog entry - data use details

13 [D14] - Catalog entry - application id

00 [D15] - Catalog entry - channel

01 [D16] - Catalog entry - channel type Sockeye [E00] - Catalog entry - source id (up to but not longer than 8 characters. Fill with blanks if less than— 8 characters)

01 [E01] - Catalog entry - number of catalog records for this catalog entry 01 [E02] - Catalog entry - preferred catalog record 240 [E10] - Catalog entry - device 00 [Ell] - Catalog entry - device details 00 [E12] - Catalog entry - data use

00 [E13] - Catalog entry - data use details 00 [E14] - Catalog entry - application id

70 [E15] - Catalog entry - channel 7.0 Mhz

01 [E16] - Catalog entry - channel type

This is Sockeye specific info. After entering data save file & type "irbcfg" at the UNIX prompt.

NO PART OF THIS CODE MAY BE COPIED OR MODIFIED WITHOUT THE WRITTEN CONSENT OF Millennium Networks Inc.

* DESCRIPTION: Source file for the Sockeye application on the

CFT-2200.

* * REVISION HISTORY:

* Date Name Description

* 03/08/98 C. Michael Creation

*

**************#******»*********♦***********#**********************/

#include <string.h> #include "jctype.h" #include "api.h"

#include "osapi.h" #ιnclude "tuner. h" #ιnclude "downstrm h" #ιnclude "upstream. h" #ιnclude "giutil.h" #ιnclude "system. h" #ιnclude "srvrmesg.h"

/* Version used by the object module converter, see section 5.1 of the

* "CFT-2200 Downloadable Firmware Programmer's Guide" */

GLOBAL const PCHAR objectVersion = "01 .04";

/* macro for converting seconds into ticks */ #defιne SECS(secs) (sees * TICKS_PER_SEC)

/* The following constant defines the periodic interval of the audience

* engine The audience engine will get the channel status information

* each time this timer expires and it will send it upstream. */ #defιne SOCKEYE_WAKEUPJNTERVAL 1 5

/* the following constant defines how long the application will delay

* when it fails to get a message buffer before retrying. */ #defιne GET_MSG_DELAY SECS( 1 )

/* Events used by the audience engine task */ #defιne SOCKEYE_WAKEUP_EVENT 0x00000001 /* definitions used by ReceiveMessageO function */

#defιne NO_QUEUE 0

#defιne NO_REQUEST (API_VERSION_REQUEST - 1 )

#defιne QWAIT JIMEOUT SECS(5) /* the following constants define the valid types of cable */

#defιne CABLE TYPE_A 0 #defιne CABLE TYPE B 1

/* define the structure containing the upstream data */ typedef struct

{

UCHAR hour;

UCHAR minute;

UCHAR second;

UCHAR ucReserved :7;

UCHAR CableType : 1 ; /* 0:cable A, 1 :cable B */

UWORD TunerNum; } SockeyeData;

/* define the message queue name */ const QueueNames SockeyeQname = QNAME('S','0','C','Q' /* The following variables contain the ID's of the resources * used by the sockeye application. */

GLOBAL LONG SockeyeTaskld;

GLOBAL LONG SockeyeQueueld;

GLOBAL LONG TunerQueueld;

GLOBAL LONG UpstreamQueueld;

GLOBAL LONG DownstreamQueueld;

GLOBAL LONG SystemQueueld;

GLOBAL LONG UpstreamOpenld; ~~

I* The following variable indicates whether the constructor has been

* called yet. */

GLOBAL BOOL Constructed;

/* statistics used for debugging the sockeye application */ GLOBAL LONG SockeyeUpstreamSendFailed; GLOBAL LONG SockeyeUpstreamCloseFailed; /* local prototypes */ extern LONG SockeyeConstructor(VOID); extern LONG SockeyeDestructor(BOOL bContextSave); VOID SockeyeTeardown(VOID); BOOL Sockeyelnιt(VOID); BOOL ReceιveMessage(QueueNames qName, UWORD uwRequest, PCHAR *pResp); BOOL SockeyeGetTunerlnfofSockeyeData *pSockeyeMsg); BOOL SockeyeOpenUpstream(VOID),

BOOL SockeyeSendUpstreamfSockeyeData *pSockeyeData); BOOL SockeyeCloseUpstream(VOID); VOID SockeyeTaskfPVOID pv);

BOOL SockeyeGetDownstreamCatalog(VOID);

/♦♦a*************************************************************** * * FUNCTION. SockeyeConstructor

*

* DESCRIPTION: Constructor for the sockeye application. This

* function is called by the CFT application. It spawns the sockeye

* task.

«******♦*****♦*****#***********************************#**********/ extern LONG SockeyeConstructor(VOID)

{

LONG RetCode;

/* initialize the IDs of all the objects to NULL */ SockeyeTaskld = NULLJD; SockeyeQueueld = NULLJD; TunerQueueld = NULLJD; UpstreamQueueld = NULLJD;

DownstreamQueueld = NULLJD; SystemQueueld = NULLJD; UpstreamOpenld = NULLJD; /* set the flag indicating the constructor has been called */ Constructed = TRUE;

/* start the sockeye applications task */ RetCode = OScreateUserTask((VOID(*)(PVOID))SockeyeTask,

PRIJMORMALJJSER, START_RUN + NO TIME SLICE + INTRPT ENABLE,

0, NULL,

0, &SockeyeTaskld); return RetCode; }

#

* FUNCTION: SockeyeDestructor

*

* DESCRIPTION: Destructor for the sockeye application. This

* function is called by the CFT application. It destructs the sockeye

* task and frees all of the resources allocated to the task. *

extern LONG SockeyeDestructor(BOOL bContextSave)

{

LONG RetCode = 0; /* eliminate unused variable warning */ ιf(bContextSave) RetCode = 0;

/* check if the constructor has been called yet */ if (Constructed)

{

/* free any resources used by the audience engine task */ SockeyeTeardownO; /* delete the task */

RetCode = OSdeleteTask(SockeyeTaskld);

} return RetCode;

}

* FUNCTION: SockeyeTeardown

* * DESCRIPTION: This function frees any resources used by the sockeye

* task. It is called when the task is deleted and also if initialization

* fails to complete successfully.

*

♦a****************************************************************/ VOID SockeyeTeardown(VOID) PCHAR pResp;

BOOL bDone = FALSE; /* close the upstream device if its open */ ιf(UpstreamOpenld '= NULLJD)

{ whιle(lbDone) bDone = SockeyeCloseUpstreamO; } if(SockeyeQueueld '= NULLJD)

{

/* Flush the queue and delete it */ ReceιveMessage(NO αUEUE, NO REQUEST, δφResp);

OSdeleteQueuefSockeyeQueueld, FORCE DELETE); }

********************************************************

FUNCTION. Sockeyelnit

DESCRIPTION: This function performs the initialization of the sockeye task. It creates the tasks message queue, event group, and starts the periodic timer of the sockeye application. It also opens the upstream device. This function returns the ID associated with the upstream device open.

********_**************_*****_*************_*****_*******_***_****_******_*/

BOOL Sockeyelnιt(VOID)

{

LONG RetCode; BOOL bDone;

/* set all IDs to NULL */ SockeyeQueueld = NULLJD; TunerQueueld = NULLJD; UpstreamQueueld = NULLJD; DownstreamQueueld = NULLJD;

SystemQueueld = NULLJD; UpstreamOpenld = NULLJD;

/* Initialize the statistics */ SockeyeUpstreamSendFailed = 0;

SockeyeUpstreamCloseFailed = 0;

/* Create the sockeye tasks message queue */

RetCode = OScreateQueuefSockeyeQname, 20, PEND PRIORITY, δiSockeyeQueueld); ιf(RetCode = = OS_RETURN_OK)

{

/* identify the TUNER queue */ RetCode = OSιdentιfyQueue(TUNER, &TunerQueueld); } ιf(RetCode = = 0S_RETURN DK)

{ /* identify the SYSTEM queue */

RetCode = OSιdentιfyQueue(SYSTEM, &SystemQueueld); } ιf(RetCode = = OS_RETURN_OK) ~ {

/* identify the UPSTREAM queue */

RetCode = OSidentιfyQueue(UPSTREAM, &UpstreamQueueld);

} if(RetCode = = 0S_RETURNJDK)

{

/* identify the DOWNSTREAM queue */

RetCode = OSιdentιfyQueue(DOWNSTREAM, &DownstreamQueueld);

}

/* read the upstream catalog entry from the downstream server */ bDone = FALSE; whileUbDone)

{ bDone = SockeyeGetDownstreamCatalogO; if(IbDone)

OSwakeAfterTιmer(GETJvlSG DELAY);

} /* open the upstream device */ bDone = FALSE; while(lbDone)

{ bDone = SockeyeOpenUpstreamO; ιf(lbDone)

OSwakeAfterTιmer(GET_MSG_DELAY); } ιf(RetCode = = OS_RETURN_OK) return TRUE; else return FALSE;

******************************************************************

FUNCTION: ReceiveMessage

* DESCRIPTION: This function receives a message from the sockeye * queue. It returns a BOOLEAN which indicates whether the specified

* message was received.

If the message on the queue isn't the expected message this routine discards the message and gets the next message from the sockeye queue. ♦♦it**************************************************************/

BOOL ReceιveMessage( QueueNames qName, UWORD uwRequest, PCHAR *pResp)

{

ApiResponseHeader *pHeader;

LONG RetCode; __

BOOL bDone = FALSE; BOOL bReturn = FALSE; whιle('bDone)

{

RetCode = OSreceιveMessage(SockeyeQueueld, QWAIT TIMEOUT, pResp); pHeader = (ApiResponseHeader *)(*pResp); ιf(RetCode = = OS_RETURN_OK) { ιf((pHeader->queueName == qName) && (pHeader-> uwRequest == uwRequest))

{ bDone = TRUE; bReturn = TRUE;

} else

{

/* Not the message we wanted, discard it and get the next * message on the queue.

*/ OSfreeMessage(*pResp);

}

} else

{ bDone = TRUE;

}

} return bReturn;

/****************************************************************** * * FUNCTION: SockeyeGetTunerlnfo

*

* DESCRIPTION: This function determines the channel the CFT is currently

* tuned to. If this function is unable to determine the channel the CFT

* is tuned to this function returns FALSE and sets the returned channel * number to 0, otherwise it returns TRUE along with the channel the unit

* is tuned to.

*

******************************************************************/

BOOL SockeyeGetTunerlnfo(SockeyeData *pSockeyeMsg) { TunerResponseMessage *pTunerRespMsg; SysResponseMessage *pSystemRespMsg; Timespec Time;

BOOL bDone; BOOL bReturn = FALSE;

/* SendRequestChannelStatusO [should do what I'm trying to do here] */ SendRequestChannelStatus ( &TunerQueueld, 1, SockeyeQueueld, 0); __ /* wait for the response */ bDone = ReceiveMessagefTUNER, USER_CHANNEL_STATUS, (PCHAR *)&pTunerRespMsg); if(bDone)

{ if(pTunerRespMsg-> header. error == OS_RETURN_OK)

{ p S o c k e y e M s g - > T u n e r N u m = pTunerRespMsg->data.tunerStatus.uwUserChannel; p S o c k e y e M s g - > C a b l e T y p e = pTunerRespMsg->data.tunerStatus.ibbType.ucCable; bReturn = TRUE;

}

OSfreeMessage((PCHAR)pTunerRespMsg); } if(bReturn = = FALSE)

{ pSockeyeMsg->TunerNum = 1; pSockeyeMsg->CableType = CABLE _TYPE_A;

}

/* zero out the reserved field */ pSockeyeMsg->ucReserved = 0;

/* wait for the response */ if(bReturn)

{

/* get the ON/OFF status information */ SendSysRequestStatusf δiSystemQueueld, 1, SockeyeQueueld); bDone = ReceiveMessage(SYSTEM, SYS REQUEST STATUS, (PCHAR *)&pSystemRespMsg); if(bDone) { if(pSystemRespMsg->header.error == OS_RETURN_OK)

{ if(!pSystemRespMsg->data.sysStatus.bAcRelayOn) pSockeyeMsg->TunerNum = 0; bReturn = TRUE;

}

OSfreeMessage((PCHAR)pSystemRespMsg);

} }

/* fill in the timestamp */ if(OSgetClock(&Tιme) = = OS_RETURN_OK) { pSockeyeMsg->hour = Time.ucHour; pSockeyeMsg-> minute = Time.ucMinute; pSockeyeMsg-> second = Time.ucSecond;

} else

{ pSockeyeMsg->hour = 24; pSockeyeMsg-> minute = 60; pSockeyeMsg-> second = 60; } return bReturn;

******************************************************************

FUNCTION: SockeyeGetDownstreamCatalog

* DESCRIPTION: This function sends the downstream catalog read command to the * DOWNSTREAM application. If an entry for the sockeye application can't be

* found the function returns FALSE, otherwise TRUE is returned.

*

******************************************************************/

BOOL SockeyeGetDownstreamCatalog(VOID) {

LONG RetCode;

DownstreamRequestMessage *pDownstreamReqMsg; DownstreamResponseMessage *pDownstreamRespMsg; BOOL bDone; BOOL bReturn = FALSE;

/* get a buffer to send the messages to the upstream application */ while(OSallocateMessage(100, (PCHAR *)&pDownstreamReqMsg) ι = OS RETURNJDK) OSwakeAfterTιmer(GETJv1SG_DELAY);

/* fill in the request */ pDownstreamReqMsg->header.queueName = DOWNSTREAM; pDownstreamReqMsg-> header. uwRequest = DOWNSTREAMJZATALOGJ^EAD; pDownstreamReqMsg-> header. IRequestNumber = 1; pDownstreamReqMsg-> header. response. IQid = SockeyeQueueld; memcpy(pDownstreamReqMsg-> data. catalogRead. destination, "Sockeye ", SOURCEJD LENGTH); /* send the request to the upstream server */

RetCode = OSsendMessagefDownstreamQueueld, (PCHAR)pDownstreamReqMsg); if(RetCode = = 0S_RETURNJDK)

{

/* wait for the response */ bDone = ReceιveMessage(DOWNSTREAM, DOWNSTREAM_CATALOG_READ, (PCHAR *)&pDownstreamRespMsg); if(bDone)

{ ιf(pDownstreamRespMsg-> header, error == NOJΞRROR)

{ bReturn = TRUE;

}

OSfreeMessage((PCHAR)pDownstreamRespMsg); }

} return bReturn;

} /** _{****************************************************************}

* FUNCTION: SockeyeOpenUpstream

*

* DESCRIPTION: This function sends the direct upstream open command to the * UPSTREAM application.

*

******************************************************************, BOOL SockeyeOpenUpstream(VOID)

{ LONG RetCode;

UpstreamRequestMessage *pUpstreamReqMsg; UpstreamResponseMessage *pUpstreamRespMsg; BOOL bDone; BOOL bReturn = FALSE;

/* get a buffer to send the messages to the upstream application */ whιle(OSallocateMessage(100, (PCHAR *)&pUpstreamReqMsg) ι = OS_RETURN_OK) OSwakeAfterTιmer(GET_MSG_DELAY); /* fill in the request */ pUpstreamReqMsg->header.queueName = UPSTREAM; pUpstreamReqMsg-> header. uwRequest = DIRECT JJPSTREAMJDPEN; pUpstreamReqMsg-> header. IRequestNumber = 1; pUpstreamReqMsg-> header. response. IQid = SockeyeQueueld; memcpy(pUpstreamReqMsg->data.dιrectOpen. destination, "Sockeye

SOURCEJDJ-ENGTH); pUpstreamReqMsg->data.dιrectOpen.ucldleTime = MAXJDLEJTIMEOUT; pUpstreamReqMsg- > data.dιrectOpen.ucTransmιtLevel = SYSTEM_TRANSMIT_LEVEL;

/* send the request to the upstream server */

RetCode = OSsendMessage(UpstreamQueueld, (PCHAR)pUpstreamReqMsg); ιf(RetCode = = OS_RETURN_OK)

{ /* wait for the response */ bDone = ReceιveMessage(UPSTREAM,

DIRECT JJPSTREAMJDPEN, (PCHAR *)&pUpstreamRespMsg); if(bDone) { if(pUpstreamRespMsg-> header. error == NOJΞRROR)

{ bReturn = TRUE;

UpstreamOpenld = pUpstreamRespMsg->data.directOρen.lOpenld; }

OSfreeMessage((PCHAR)pUpstreamRespMsg);

} } return bReturn; }

/****************************************************************** *

* FUNCTION: SockeyeSendUpstream

* DESCRIPTION: This function sends the upstream message to the UPSTREAM

* application for transmission.

*

******************************************************************/ BOOL SockeyeSendUpstreamfSockeyeData *pSockeyeData)

{

LONG RetCode;

UpstreamRequestMessage *pUpstreamReqMsg;

UpstreamResponseMessage *pUpstreamRespMsg; BOOL bDone;

BOOL bReturn = FALSE;

BOOL bMsgSent = FALSE; while(lbMsgSent) {

/* get a buffer to send the messages to the upstream application */ while(OSallocateMessage(100, (PCHAR *)&pUpstreamReqMsg) ! = OS_RETURN_OK)

OSwakeAfterTimer(GET_MSG_DELAY);

/* fill in the request */ pUpstreamReqMsg-> header. queueName = UPSTREAM; pUpstreamReqMsg-> header. uwRequest = DIRECTJJPSTREAMJΛ/RITE; pUpstreamReqMsg-> header. IRequestNumber = 1; pUpstreamReqMsg-> header. response. IQid = SockeyeQueueld;

/* Fill in the sizeof the application data and the data. The size of

* the application data is hardcoded because the compiler thinks the

* sizeof the application data is 8 not 6. I think this occurs because * of padding, but I don't know how to disable it.

*/ pUpstreamReqMsg->data.directWrite.lOpenld = UpstreamOpenld; pUpstreamReqMsg->data.directWrite.uwSize = 6; pUpstreamReqMsg->data.directWrite.pcBuffer = (PCHAR)pSockeyeData;

/* send the request to the upstream server */

RetCode = OSsendMessagefUpstreamQueueld, (PCHAR)pUpstreamReqMsg); iffRetCode = = OS RETURN OK)

{ /* wait for the response */ bDone = ReceiveMessagefUPSTREAM,

DIRECT_UPSTREAM_WRITE,

(PCHAR *)&pUpstreamRespMsg); if(bDone) { if(pUpstreamRespMsg-> header. error == NO ERROR)

{ bMsgSent = TRUE; _ bReturn = TRUE; } else if ((pUpstreamRespMsg-> header. error == DEVICE_NOT_RESERVED)

(pUpstreamRespMsg-> header, error == NOT AVAILABLE) j j (pUpstreamRespMsg-> header, error == INVALIDJD)) {

/* open the upstream device */ bDone = FALSE; while(IbDone) bDone = SockeyeOpenUpstreamf); }

OSfreeMessage((PCHAR)pUpstreamRespMsg);

}

} } return bReturn;

}

I****_**************************_***********_*************************

* FUNCTION: SockeyeCloseUpstream

* DESCRIPTION: This function sends the direct upstream close command to the

* UPSTREAM application.

_*

_*****_***_********_****_***_****_*****_*****_****_**_*****_**_***_***_****_***_***/

BOOL SockeyeCloseUpstream(VOID)

{

LONG RetCode; UpstreamRequestMessage *pUpstreamReqMsg;

UpstreamResponseMessage *pUpstreamRespMsg;

BOOL bDone;

BOOL bReturn = FALSE; /* get a buffer to send the messages to the upstream application */ while(OSallocateMessage(100, (PCHAR *)&pUpstreamReqMsg) != OS_RETURNJOK) OSwakeAfterTimer(GET_MSG_DELAY);

/* fill in the request */ pUpstreamReqMsg-> header. queueName = UPSTREAM; pUpstreamReqMsg-> header. uwRequest = DIRECT_UPSTREAM_CLOSE; pUpstreamReqMsg-> header. IRequestNumber = 1; pUpstreamReqMsg-> header. response. IQid = SockeyeQueueld; pUpstreamReqMsg->data.directClose.lOpenld = UpstreamOpenld; /* send the request to the upstream server */

RetCode = OSsendMessage(UpstreamQueueld, (PCHAR)pUpstreamReqMsg); iffRetCode = = OS RETURN OK)

{ /* wait for the response */ bDone = ReceiveMessagefUPSTREAM,

DIRECT UPSTREAM CLOSE,

(PCHAR *)&pUpstreamRespMsg); __ if(bDone) { ιf(pUpstreamRespMsg-> header. error == NOJΞRROR) bReturn = TRUE;

OSfreeMessage((PCHAR)pUpstreamRespMsg); }

} return bReturn;

******************************************************************

FUNCTION: SockeyeTask

* DESCRIPTION: Mam function for the sockeye application. This * task initializes the resources it needs and then goes into an infinite

* loop waiting for the 15 second timer to expire. Every 15 seconds this

* task wakes up, gets the current channel status, creates an upstream

* message containing the data, and sends the data upstream. It then goes

* back to sleep waiting for the 15 second timer to expire.

******************************************************************_/

VOID SockeyeTas PVOID pv)

{

SockeyeData SockeyeMsg; BOOL bDone = FALSE;

BOOL bTunerDataOk;

/* eliminate unused variable warning */ ιf(pv) bDone = FALSE;

/* loop until initialization completes */ whιle(lbDone)

{ bDone = SockeyelnitO; if(!bDone)

{

/* If initialization fails undo everything, wait, and try again */ SockeyeTeardownO; OSwakeAfterTimerdOL);

} } for(;;) { /* wait for the periodic timer to expire */ OSwakeAfterTimer(SECS(SOCKEYE_WAKEUPJNTERVAD);

/* get the current channel status information */ bTunerDataOk = SockeyeGetTunerlnfof&SockeyeMsg) ; if(bTunerDataOk)

{

/* create the upstream message and send it */ if(!SockeyeSendUpstream(&SockeyeMsg))

SockeyeUpstreamSendFailed + + ;

}

GI Requested Information

SOFTWARE RELEASE NOTES

PRODUCT: MN_GI_CFT (22DB3200 with Millennium Networks

Audience Engine) Software Version: 22DJ3606 (Millennium - Version

1.0)

Upgraded from Previous Release : None

Release Date: 7/7/98

Reset Qualifier: 169 Definition: This note defines changes to the

DOWNLOADABLE FILE which is downloaded to the

Settop Feature Expansion Module by the ACC4000 controller, or the Off-Line Loader.

Description of Changes and New Features: <Supply information here>

Major problems fixed in this release:

This release is the first release of this product.

Warnings / known problems / bugs / special instructions pertinent to this release: <Supply information here>

Installation issues:

FORMTEXT Compatibility : This software release can be installed on the following hardware:

FORMTEXT This software release is compatible with the following equipment / other software / systems components : FORMTEXT

Release Package Checklist The following components are included in this release: rdj3606d.doc —

Sockeye . abs v. 1.0 code that is included in the monolithic file that is downloaded to UPM flash memory

3100SOC0.DAT 3100SOC0.DSC

Sock3100.det

Claims

WHAT IS CLAIMED IS:

1. A method for monitoring television viewing habits of a television viewer, the method comprising the steps of : a) storing information representative of television viewing habits in one of a television andΓÇö a set top box; and b) transmitting the stored information to a remote location.

2. The method as recited in Claim 1, wherein the step of storing information representative of television viewing habits comprises storing information representative of television viewing habits in the television.

3. The method as recited in Claim 1, wherein the step of storing information representative of television viewing habits comprises storing information representative of television viewing habits in the set top box.

4. The method as recited in Claim 1, wherein the step of storing information representative of television viewing habits comprises storing an identification code, time, channel, and channel source.

5. The method as recited in Claim 1, wherein the step of storing information representative of television viewing habits comprises storing the information in a non-volatile memory.

6. The method as recited in Claim 1, wherein the step of storing information representative of television viewing habits comprising storing only channel information for channels which are watched for a predetermined length of time.

7. The method as recited in Claim 1, wherein the step of transmitting the stored information comprises transmitting the stored information periodically.

8. The method as recited in Claim 1, wherein the step of transmitting the stored information comprises transmitting the stored information periodically at a predetermined time.

9. The method as recited in Claim 1, wherein the step of transmitting the stored information comprises transmitting the stored information when requested to do so by a remote host . ΓÇö

10. The method as recited in Claim 1, wherein the step of transmitting the stored information comprises transmitting the stored information via a bi-directional cable television cable.

11. The method as recited in Claim 1, wherein the step of transmitting the stored information comprises transmitting the stored information via telephone.

12. The method as recited in Claim 1, wherein the step of transmitting the stored information comprises transmitting the stored information via a radio modem.

13. The method as recited in Claim 1, wherein the step of transmitting the stored information to a remote location comprises transmitting the stored information to an Internet web site.

14. A set top box for providing cable television service and for monitoring television viewing habits of television viewers, the set top box comprising: a) an input port for receiving a plurality of cable television channels; b) an output port for communicating at least one cable television channel to a television; c) a non-volatile memory for storing instructions for performing monitoring of television viewing habits; d) a volatile memory for storing information representative of television viewing habits; e) monitoring software configured to monitor which channel is being viewed according to instructions stored in the non-volatile memory and for storing information representative of which channel is being viewed and at what time in the volatile memory.

15. The set top box as recited in Claim 14, further comprising a cable data output circuit for transmitting stored data representative of television viewing habits to a remote location via a cable television cable. ΓÇö

16. The set top box as recited in Claim 14, further comprising a telephone data output circuit for transmitting stored data representative of television viewing habits to a remote location via telephone.

17. The set top box as recited in Claim 14, further comprising a radio modem for transmitting stored data representative of television viewing habits to a remote location via radio.

18. The set top box as recited in Claim 14, wherein the first memory comprises a flash memory.

19. The set top box as recited in Claim 14, wherein the second memory comprises a non-volatile memory.

20. A television monitoring and reporting system, disposed within a television, which monitors and reports viewing habits of television viewers, the system comprising: a) a television input port for receiving a plurality of cable television channels; b) a first memory disposed in the television for storing instructions for performing monitoring of television viewing habits; c) a second memory disposed in the television for storing information representative of television viewing habits. d) a monitoring circuit disposed in the television and configured to monitor which channel is being viewed according to instructions stored in the first memory and for storing information representative of which channel is being viewed and at what time in the second memory.

21. The system as recited in Claim 20, further comprising a cable data output circuit for transmitting stored data representative of television viewing habits to a remote location via a cable television cable.

22. The system as recited in Claim 20, further comprising a telephone data output circuit for ΓÇö transmitting stored data representative of television viewing habits to a remote location via telephone.

23. The system as recited in Claim 20, further comprising a radio modem in electrical communication with the television for transmitting stored data representative of television viewing habits to a remote location via radio.

24. The system as recited in Claim 20, wherein the first memory comprises a flash memory.

25. The system as recited in Claim 20, wherein the second memory comprises a non-volatile memory.

26. A method for monitoring and reporting television viewing habits of the television user comprising: communicating set of instructions in a television monitoring instructions to a television set top box by imbedding the instructions in an unused portion of a video signal communicated to the set top box by a cable television connector from a cable service connector remote from the set top box; generating television viewing data in response to the instructions; storing the television viewing data in a memory disposed within the set top box; and uploading the stored data to the cable service location via the cable television connector.

27. The method as recited in Claim 26 further comprising the step of communicating an upload control signal to the cable set top box via the cable television connector, the upload control signals being operative to cause the stored viewing data to be uploaded to the cable service location.

28. The method as recited in Claim 27 wherein the control signals are communicated to the cable set top box in a first unused portion of a video signal band width provided for a video signal communicated from the cable ΓÇö service location to the set top box.

29. The method as recited in Claim 28 wherein the stored data is communicated from the cable set top box in a second unused portion of the video signal bandwidth.

30. The method as recited in Claim 28 wherein the stored data is communicated from the cable set top box in the first unused portion of the video signal bandwidth, when no control signals are being communicated to the set top box.