REGISTER  |  SIGN IN
United States Patent5666293
Metz , ; et al.September 9, 1997
Title
Downloading operating system software through a broadcast channel
Abstract
Set-top terminals utilized in broadband broadcast networks are becoming increasingly intelligent. Upgrading the operation of such terminals periodically requires upgrading the software, particularly the operating system, of the programmable processor which controls the terminal operation. To facilitate frequent upgrades, the network will carry a cyclic broadcast of a packetized data file containing the operating system. Periodically, a terminal will capture and store the broadcast operating system. In the preferred embodiment, the broadcast includes operating system files for a number of different terminal types and data identifying the current broadcast version of the operating system for each type of terminal. The terminal will check the broadcast version number for its terminal type operating system. If the broadcast version number differs from the version number for the operating system the terminal currently is running, then the terminal will capture only the file containing the operating system for the corresponding terminal type.
Inventors:Metz; Erik C. (Bowie, MD), Hudson, Jr.; Henry G.  (Annapolis, MD), Darr, Jr.; John W.  (Great Falls, VA)
Assignee:Bell Atlantic Network Services, Inc. (Arlington, VA)
Appl. No.:498265
Filed:July 3, 1995
Current U.S. Class:709/220 725/132 725/138 725/140 725/152 
Field of Search:364/514C 380/10,20 370/112,118 348/7,10,12 455/3.1,4.1,4.2,5.1,6.1
U.S. Patent Documents
4506387March 1985Walter
4527194July 1985Sirazi
4623905November 1986Ichihashi et al.
4623920November 1986Dufresne et al.
4677685June 1987Kurisu
4700386October 1987Kohn
4706121November 1987Young
4709418November 1987Fox et al.
4712239December 1987Frezza et al.
4816905March 1989Tweedy et al.
4829372May 1989McCalley et al.
4894714January 1990Christis
4912552March 1990Allison, III et al.
4920432April 1990Eggers et al.
4947244August 1990Fenwick et al.
4949187August 1990Cohen
4963995October 1990Lang
4982430January 1991Frezza et al.
5003591March 1991Kauffman et al.
5010499April 1991Yee
5027400June 1991Baji et al.
5051822September 1991Rhoades
5057932October 1991Lang
5058160October 1991Banker et al.
5104125April 1992Pocock et al.
5105268April 1992Yamanouchi et al.
5119188June 1992McCalley et al.
5121476June 1992Yee
5130792July 1992Tindell et al.
5132992July 1992Yurt et al.
5133079July 1992Ballantyne et al.
5136411August 1992Paik et al.
5140417August 1992Tanaka et al.
5142680August 1992Ottman et al.
5166886November 1992Molnar et al.
5168353December 1992Walker et al.
5172413December 1992Bradley et al.
5181107January 1993Rhoades
5189673February 1993Burton et al.
5192999March 1993Graczyk et al.
5223924June 1993Strubbe et al.
5231494July 1993Wachob
5239540August 1993Rovira et al.
5247347September 1993Litteral et al.
5247364September 1993Banker et al.
5249044September 1993Von Kohorn
5253275October 1993Yurt et al.
5282028January 1994Johnson et al.
5315392May 1994Ishikawa et al.
5317391May 1994Banker et al.
5335277August 1994Harvey et al.
5341425August 1994Wasilewski
5341474August 1994Gelman et al.
5373288December 1994Blahut
5379421January 1995Palazzi, III et al.
5400401March 1995Wasilewski
5410326April 1995Goldstein
5418782May 1995Wasilewski
5421017May 1995Scholz et al.
5440632August 1995Bacon et al.
5441389August 1995Blahut et al.
5448568September 1995Delpuch et al.
5548532August 1996Menand et al.
5553311September 1996McLaughlin et al.
5563648October 1996Menand et al.
Re34611May 1994Fenwick et al.
Foreign Patent Documents
01-288421Sep., 1991JP
3149992Jun., 1991JP
94/23537Oct., 1994WO
Other References
Hambley, Allan R., "Communication Systems", pp. 8-10 1990. .
Gelman et al., A Store-and-Forward Architecture for Video-on-Demand Service, International Conference on Communications, Denver, Jun. 23, 1991; Communications: Rising to the Heights; vol. 2 of 3; pp. 842-846..~
Primary Examiner: Ramirez; Ellis B.
Assistant Examiner: Assouad; Patrick
Attorney, Agent or Firm:Lowe, Price, LeBlanc & Becker
Parent Case Text


CROSS REFERENCE TO RELATED APPLICATION

This application is a Continuation-In-Part of U.S. patent application Ser. No. 08/380,755 filed Jan. 31, 1995 which is a Continuation-In-Part of U.S. patent application Ser. No. 08/250,791 filed May 27, 1994, the disclosures of both of which are incorporated herein entirely by reference.
Claims

We claim:
1. A set-top terminal device comprising:
a network interface module adapted to couple the terminal to a communication network for receiving at least selected ones of a plurality of broadcast digital broadband channels at least one of which carries audio/video program information in compressed, digital form in packets of a standardized format and at least one of which carries cyclically repetitive transmissions of operating system software in packets of the standardized format, wherein said network interface module receives an Asynchronous Transfer Mode (ATM) cell stream and extracts packets of the standardized format from payloads of ATM cells; and
a digital entertainment terminal comprising:
(a) an audio/video processor responsive to at least some of the packets extracted by the network interface module for processing the compressed, digital audio/video program information;
(b) a memory;
(c) means for receiving inputs from a user; and
(d) a control processor controlling operations of the set-top terminal;
wherein said control processor captures said operating system software from at least some of the packets extracted by the network interface module for one of the selected digital broadband channels within a transmission cycle, loads the captured operating system software into the memory and begins operation in accord with the operating system software loaded into the memory, said control processor controlling the network interface module and the audio/video processor in response to the user inputs in accord with the operating system software loaded in said memory.

2. A device as recited in claim 1, wherein said memory comprises a non-volatile random access memory.

3. A device as recited in claim 2, wherein said non-volatile random access memory comprises a flash memory.

4. A device as recited in claim 1, wherein said digital entertainment terminal further comprises a random access memory storing applications software for use by said control processor while running the operating system software.

5. A device as recited in claim 1, wherein said audio/video processor comprises:
an audio decoder for decoding compressed, digital audio information;
a video decoder for decoding compressed, digital video information; and
a packet demultiplexer for analyzing packet identifiers contained in the packets of the standardized format to identify packets containing compressed, digital audio information and to route information from those packets to the audio decoder, to identify packets containing compressed, digital video information and to route information from those packets to the video decoder, and to identify packets containing operating system software and route software from those packets to the control processor.

6. A device as recited in claim 5, wherein:
the audio decoder comprises an MPEG audio decoder;
the video decoder comprises an MPEG video decoder; and
the packet demultiplexer is an MPEG demultiplexer.

7. A device as recited in claim 5, wherein said network interface module supplies the extracted packets to the packet demultiplexer.

8. A device as recited in claim 1, wherein said digital entertainment terminal further comprises a memory storing a routine which the control processor executes to control capturing of the operating system software.

9. A communication system comprising:
a source system comprising:
(a) a program source supplying a broadband program signal,
(b) a software server cyclically outputting a data file containing an operating system, and
(c) an encoder system for packetizing the broadband program signal and the data file in digital packets of a standard format, wherein said encoder system comprises an encoder for digitizing and compressing the broadband program signal into program data and encapsulating the program data in a sequence of packets of the standard format, a data module for encapsulating the data file containing an operating system in a sequence of packets of the standard format, and an Asynchronous Transfer Mode (ATM) multiplexer for combining the packets containing the broadband program information and the packets containing the data file into a single stream for broadcast through the network on a single one of the channels;
a digital network broadcasting a plurality of digital broadband channels, said digital network receiving and broadcasting the digital packets from the encoder system on at least one of the channels; and
a plurality of set-top terminal devices, each set-top terminal device comprising:
(1) an interface coupled to the digital network for receiving at least a selected one of the channels, selectively including at least one channel carrying packets containing the broadband program information, and at least one channel carrying packets containing the operating system data file;
(2) a program signal processor for processing the packets containing the broadband program information;
(3) a memory;
(4) means for receiving inputs from a user; and
(5) a control processor controlling operations of the set-top terminal;
wherein said control processor captures said operating system data file from a selected one of the digital broadband channels, loads the captured operating system into the memory and begins operation in accord with the operating system loaded into the memory, said control processor controlling the interface and the program signal processor in response to the user inputs in accord with the operating system loaded in said memory.

10. A communication system as recited in claim 9, wherein said encoder for digitizing and compressing the broadband program signal comprises a real time encoder for digitizing and compressing an audio/video program signal.

11. A communication system as recited in claim 10, wherein said real time encoder comprises an MPEG encoder.

12. A communication system as recited in claim 9, wherein said digital network comprises:
a first optical fiber receiving the digital packets from the encoder system;
a second optical fiber receiving packets containing broadband program information from another source system;
a system of optical fibers for broadcasting the digital packets from the encoder system on at least a first one of the channels and for broadcasting the packets containing the broadband program information from another source on at least a second one of the channels; and
a plurality of host digital terminals each coupled between the system of optical fibers and a group of the set-top terminals for routing selected ones of the channels to set-top terminals in each group.

13. In a digital network broadcasting packetized audio/video program information through a plurality of digital broadband channels to a plurality of digital terminals connected to the network, a method comprising the steps of:
cyclically broadcasting an operating system together with predetermined identification data relating to the operating system on one digital broadband channel;
selectively receiving the one digital broadband channel and capturing the predetermined identification data;
comparing the captured predetermined identification data to identification data stored in one of the digital terminals;
based on the results of the comparison, capturing a copy of the operating system from the cyclical broadcast;
initiating operating of the one digital terminal in accord with the captured copy of the operating system;
receiving and storing application software in the one digital terminal via a digital communication link through the network; and
executing the application software under control of the captured copy of the operating system.

14. A method as recited in claim 13, wherein the predetermined identification data identifies a terminal type, and the operating system is stored if the terminal type identified by the predetermined identification data matches terminal type identification data stored in the one terminal.

15. A method as recited in claim 13, wherein the predetermined identification data identifies a version number of the operating system being broadcast, and the operating system is stored if the version number identified by the predetermined identification data is different from a version number of an operating system previously stored in the one terminal.

16. A method as recited in claim 13, wherein the operating system comprises:
a microprocessor operating system;
at least one driver routine used by a microprocessor to control components of a terminal; and
a resident application controlling at least selection of channels through the network in response to user inputs.

17. A method as recited in claim 13, wherein the digital communication link comprises one of the digital broadband channels.

18. A method as recited in claim 13, wherein the digital communication link comprises a broadband point-to-point link.

19. A method comprising:
encoding a plurality of broadband program information signals as digitized, compressed data in packet streams of a standard format;
cyclically generating a first data file containing an operating system comprising code executable by a first type of terminal and a data file containing an operating system comprising code executable by a second type of terminal different in type from the first type of terminal;
forming a sequence of packets in the standard format including: packets containing the first data file and a first identifier, packets containing the second data file and a second identifier, and at least one packet containing data associating the first and second identifiers with the first and second types of terminal, respectively;
broadcasting the packet streams and the sequence of packets on a plurality of multiplexed channels;
in a receiving terminal of a predetermined type:
(a) selectively receiving a channel carrying the sequence of packets;
(b) capturing said at least one packet;
(c) identifying the first type of terminal or the second type of terminal as corresponding to the predetermined type of the receiving terminal;
(d) recognizing the first or second identifier as associated with the identified terminal type;
(e) using the recognized identifier to capture a copy of the operating system for the identified terminal type from the sequence of packets; and
(f) executing at least a portion of the code from the captured copy of the operating system for the identified terminal type to initiate operation of the receiving terminal, the operation of the receiving terminal including reception of a user selected channel carrying a packet stream and processing digitized, compressed data from that packet stream to present broadband program information to a user in humanly perceptible form.

20. A method as recited in claim 19, wherein:
the step of using the recognized identifier to capture a copy of the operating system comprises storing payload data from packets containing the recognized identifier in random access memory; and
the step of initiating operation comprises transferring the payload data from the random access memory to a non-volatile memory, and booting up the receiving terminal from the payload data in the nonvolatile memory.

21. A method as recited in claim 19, further comprising encoding another broadband program information signal as digitized, compressed data in another packet stream of a standard format,
wherein the step of broadcasting comprises:
multiplexing the sequence of packets and said another packet stream into one channel stream, and
broadcasting the one channel stream through one of the multiplexed channels.

22. A method comprising:
encoding a plurality of broadband program information signals as digitized, compressed data in packet streams of a standard format;
cyclically generating a first data file containing an operating system for a first type of terminal and a data file containing an operating system for a second type of terminal;
forming a sequence of packets in the standard format including: packets containing the first data file and a first identifier, packets containing the second data file and a second identifier, and at least one packet containing data associating the first and second identifiers with the first and second types of terminal, respectively;
broadcasting the packet streams and the sequence of packets on a plurality of multiplexed channels,
wherein the multiplexed channels comprise Asynchronous Transfer Mode (ATM) virtual circuits, each virtual circuit being identified by a different virtual path identifier/virtual circuit identifier (VPI/VCI) value;
in a receiving terminal of a predetermined type:
(a) selectively receiving a channel carrying the sequence of packets;
(b) capturing said at least one packet;
(c) identifying the first type of terminal or the second type of terminal as corresponding to the predetermined type of receiving terminal;
(d) recognizing the first or second identifier as associated with the identified terminal type;
(e) using the recognized identifier to capture a copy of the operating system for the identified terminal type from the sequence of packets; and
(f) initiating operation of the receiving terminal in accord with the captured copy of the operating system for the identified terminal type, operation of the receiving terminal including reception of a user selected channel carrying a packet stream and processing digitized, compressed data from that packet stream to present broadband program information to a user in humanly perceptible form.

23. A method as recited in claim 22, wherein the step of selectively receiving a channel comprises receiving and processing ATM cells containing a VPI/VCI value assigned to the selectively received channel.

24. A method comprising:
encoding a plurality of broadband program information signals as digitized, compressed data in packet streams of a standard format;
cyclically generating a first data file containing an operating system comprising code executable by a first type of terminal and a data file containing an operating system comprising code executable by a second type of terminal different in type from the first type of terminal;
forming a sequence of packets in the standard format including: packets containing the first data file and a first identifier, packets containing the second data file and a second identifier, and at least one packet containing data associating the first and second identifiers with the first and second type of terminal and first and second operating system version numbers, respectively;
broadcasting the packet streams and the sequence of packets on a plurality of multiplexed channels;
in a receiving terminal of a predetermined type:
selectively receiving a channel carrying the sequence of packets;
capturing said at least one packet;
from the data in said at least one packet, identifying the first type of terminal or the second type of terminal as corresponding to the predetermined type of the receiving terminal;
from the data in said at least one packet, identifying the version number for the identified terminal type;
if the identified version number differs from a version number of an operating system previously stored in the receiving terminal, recognizing the first or second identifier as associated with the identified terminal type and using the recognized identifier to capture a copy of the operating system for the identified terminal type from the sequence of packets; and
executing at least a portion of the code from the captured copy of the operating system for the identified terminal type to initiate operation of the receiving terminal, the operation of the receiving terminal including reception of a user selected channel carrying a packet stream and processing digitized, compressed data from that packet stream to present broadband program information to a user in humanly perceptible form.

25. A method as recited in claim 24, wherein:
the step of using the recognized identifier to capture a copy of the operating system comprises storing payload data from packets containing the recognized identifier in random access memory; and
the step of initiating operation comprises transferring the payload data from the random access memory to a non-volatile memory, and booting up the receiving terminal from the payload data in the non-volatile memory.

26. A method as recited in claim 24, further comprising encoding another broadband program information signal as digitized, compressed data in another packet stream of a standard format,
wherein the step of broadcasting comprises:
multiplexing the sequence of packets and said another packet stream into one channel stream, and
broadcasting the one channel stream through one of the multiplexed channels.

27. A method comprising:
encoding a plurality of broadband program information signals as digitized, compressed data in packet streams of a standard format;
cyclically generating a first data file containing an operating system for a first type of terminal and a data file containing an operating system for a second type of terminal;
forming a sequence of packets in the standard format including: packets containing the first data file and a first identifier, packets containing the second data file and a second identifier, and at least one packet containing data associating the first and second identifiers with the first and second type of terminal and first and second operating system version numbers, respectively;
broadcasting the packet streams and the sequence of packets on a plurality of multiplexed channels,
wherein the multiplexed channels comprise Asynchronous Transfer Mode (ATM) virtual circuits, each virtual circuit being identified by a different virtual path identifier/virtual circuit identifier (VPI/VCI) value;
in a receiving terminal of a predetermined type:
selectively receiving a channel carrying the sequence of packets;
capturing said at least one packet;
from the data in said at least one packet, identifying the first type of terminal or the second type of terminal as corresponding to the predetermined type of receiving terminal;
from the data in said at least one packet, identifying the version number for the identified terminal type;
if the identified version number differs from a version number of an operating system previously stored in the receiving terminal, recognizing the first or second identifier as associated with the identified terminal type and using the recognized identifier to capture a copy of the operating system for the identified terminal type from the sequence of packets; and
initiating operation of the receiving terminal in accord with the captured copy of the operating system for the identified terminal type, operation of the receiving terminal including reception of a user selected channel carrying a packet stream and processing digitized, compressed data from that packet stream to present broadband program information to a user in humanly perceptible form.

28. A method as recited in claim 27, wherein the step of selectively receiving a channel comprises receiving and processing ATM cells containing a VPI/VCI value assigned to the selectively received channel.

29. A method comprising:
selectively receiving in a terminal an Asynchronous Transfer Mode (ATM) digital broadcast channel identified by a virtual path identifier/virtual circuit identifier (VPI/VCI) value and carrying a digital transport stream of packets;
capturing at least one packet of data from the digital transport stream;
from the data in said at least one packet, identifying a version number for an operating system carried in the digital transport stream;
if the identified version number differs from a version number of an operating system previously stored in the terminal, capturing the operating system from the transport stream; and
initiating operation of the terminal in accord with the captured copy of the operating system, operation of the terminal including reception of a user selected ATM channel and processing digitized, compressed data from the user selected ATM channel to present broadband program information to a user in humanly perceptible form.

30. A method as recited in claim 29 further comprising the step of initiating the method in response to a predetermined user input.

31. A method as recited in claim 29, further comprising the step of automatically initiating the method in response to a predetermined event.

32. A method as received, in claim 31, wherein the predetermined event is passage of a specified time period.

33. A method as received in claim 31, wherein the predetermined event comprises turn-off of the terminal.

34. A method as recited in claim 29, further comprising the steps of:
counting each occurrence of an `off` instruction input to the terminal from a user; and
when the count reaches a predetermined value, initiating the method.

35. A communication system comprising:
a source system supplying a broadband program signal, and a cyclically repeating data file containing an operating system, said broadband program signal and the data file being encoded in digital packets of a standard format;
an Asynchronous Transfer Mode (ATM) digital network broadcasting a plurality of digital broadband channels in virtual circuits, each virtual circuit being identified by a different virtual path identifier/virtual circuit identifier (VPI/VCI) value, said digital network receiving and broadcasting the digital packets from the source system on at least one of the channels; and
a plurality of set-top terminal devices, each set-top terminal device comprising:
(1) an interface coupled to the digital network for receiving at least a selected one of the channels, selectively including at least one channel carrying packets containing the broadband program information, and at least one channel carrying packets containing the operating system data file;
(2) a program signal processor for processing the packets containing the broadband program information;
(3) a memory;
(4) means for receiving inputs from a user; and
(5) a control processor controlling operations of the set-top terminal;
wherein said control processor captures said operating system data file from a selected one of the digital broadband channels, loads the captured operating system into the memory and begins operation in accord with the operating system loaded into the memory, said control processor controlling the interface and the program signal processor in response to the user inputs in accord with the operating system loaded in said memory.

36. A communication system as recited in claim 35, wherein said source system comprises:
an encoder for digitizing and compressing the broadband program signal into program data and encapsulating the program data in a sequence of packets of the standard format; and
a data module for encapsulating the data file containing an operating system in a sequence of packets of the standard format.

37. A communication system as recited in claim 36, wherein said source system further comprises a multiplexer for combining the packets containing the broadband program information and the packets containing the data file into a single stream for broadcast through the network on a single one of the channels.

38. A set-top terminal device comprising:
a network interface module adapted to couple the terminal to a communication network for receiving at least selected ones of a plurality of broadcast digital broadband channels at least one of which carries audio/video program information in compressed, digital form in packets of a standardized format and at least one of which carries cyclically repetitive transmissions of operating system software in packets of the standardized format; and
a digital entertainment terminal comprising:
(a) an audio/video processor for processing the compressed, digital audio/video program information;
(b) an operating system memory;
(c) a random access memory;
(d) means for receiving inputs from a user; and
(e) a control processor controlling operations of the set-top terminal, wherein
said control processor captures said operating system software from one of the selected digital broadband channels within a transmission cycle, loads the captured operating system software into the operating system memory and begins operation in accord with the operating system software loaded into the operating system memory,
said control processor captures application software received through the network interface module, stores captured application software in the random access memory and executes the stored application software under control of the captured copy of the operating system, and
said control processor controls the network interface module and the audio/video processor in accord with the operating system software loaded in said operating system memory, and controls at least some responses to the user inputs with the application software.

39. A device as recited in claim 38 wherein said audio/video processor comprises:
an audio decoder for decoding compressed, digital audio information;
a video decoder for decoding compressed, digital video information; and
a packet demultiplexer for analyzing packet identifiers contained in the packets of the standardized format to identify packets containing compressed, digital audio information and to route information from those packets to the audio decoder, to identify packets containing compressed, digital video information and to route information from those packets to the video decoder, and to identify packets containing operating system software and application software and route software from those packets to the control processor.

40. A device as recited in claim 39, wherein:
the audio decoder comprises an MPEG audio decoder;
the video decoder comprises an MPEG video decoder; and
the packet demultiplexer is an MPEG demultiplexer.

41. A device as recited in claim 39, wherein said network interface module receives an Asynchronous Transfer Mode (ATM) cell stream, extracts packets of the standardized format from payloads of ATM cells and supplies the extracted packets to the packet demultiplexer.

42. A communication system comprising:
a source'system comprising:
(a) a program source supplying a broadband program signal,
(b) a software server cyclically outputting a data file containing an operating system, and
(c) an encoder system for packetizing the broadband program signal and the data file in digital packets of a standard format;
a digital network broadcasting a plurality of digital broadband channels, said digital network receiving and broadcasting the digital packets from the encoder system on at least one of the channels and transporting an application program through at least one digital broadband channel; and
a plurality of set-top terminal devices, each set-top terminal device comprising:
(1) an interface coupled to the digital network for receiving at least a selected one of the channels,
(2) a program signal processor for processing packets containing the broadband program information received through the interface,
(3) an operating system memory,
(4) a random access memory for storing the application program when received through the interface,
(5) means for receiving inputs from a user, and
(5) a control processor controlling operations of the set-top terminal,
wherein said control processor captures said operating system data file from a selected one of the digital broadband channels, loads the captured operating system into the memory and begins operation in accord with the operating system loaded into the memory, said control processor executing the application program from the random access memory and controlling the interface and the program signal processor in accord with the operating system loaded in said memory and controlling at least some responses to user inputs in accord with the application program.

43. A communication system as recited in claim 42, wherein said encoder system further comprises a multiplexer for combining the packets containing the broadband program information and the packets containing the data file into a single stream for broadcast through the network on a single one of the channels.

44. A communication system as recited in claim 43, wherein said multiplexer is an Asynchronous Transfer Mode (ATM) multiplexer.

45. A communication system as recited in claim 44, wherein said digital network comprises:
a first optical fiber receiving the digital packets from the encoder system;
a second optical fiber receiving packets containing broadband program information from another source system;
a system of optical fibers for broadcasting the digital packets from the encoder system on at least a first one of the channels and for broadcasting the packets containing the broadband program information from another source on at least a second one of the channels; and
a plurality of host digital terminals each coupled between the system of optical fibers and a group of the set-top terminals for routing selected ones of the channels to set-top terminals in each group.
Description
TECHNICAL FIELD

The present invention relates to a programmable set-top terminal, typically comprising a network interface module (NIM) and a digital entertainment terminal (DET), for use in digital video program distribution networks and to systems and methods for dynamically downloading operations system software to such a terminal.

Background Art

Set top terminal devices commonly in use in cable television systems today have a number of limitations. First, the devices are limited to processing of analog television signals. Also, cable television terminal devices are generally "dumb" devices having a limited set of functionalities constrained by the hard wired programming of the internal micro-processor controlled device. Essentially all cable television terminal devices respond to a selection input from the subscriber, tune to a selected channel available on the cable television network, decode the video program material if scrambled, and provide output signals compatible with a standard television receiver.

Enhanced cable television terminals provide some additional features, such as graphics overlay capability and two way communication of control signalling to and from headend terminal devices. Although such improved terminals facilitate some enhanced services, such as home shopping and purchasing, the performance of these cable television set-top terminals is still limited to analog decoding. Also the range of services is still limited by the hard wired capabilities of the microprocessor within the set-top terminal devices.

Proposals have been made to download computer executable code over cable television networks. In particular, U.S. Pat. Nos. 5,051,822 and 5,181,107 both to Rhoades disclose a terminal device connectable to a cable television network and a telephone line. A subscriber requests a video game or other software stored in a remotely located software storage center by operating the terminal to establish a bi-directional telephone link with the remote storage center. The center transmits the encoded software program together with the terminal identification code as a digital bit stream over a television broadcast channel. The terminal requesting the software monitors all digital bit streams on the broadcast channel but receives only the software program addressed to it, i.e. only after identification code validation occurs. Once reception of all the software data is complete, the terminal acknowledges receipt to the remote storage center and drops the telephone line. The encoded software program is decoded, and the terminal provides a display informing the subscriber that the game or other program is ready for use. The terminal also offers the subscriber the means to interact with the software, e.g. play the game, using contemporary gaming control or input devices. While the Rhoades terminal structure does provide enhanced capabilities, such as video games and home shopping, the display functionality controlled by the downloaded software is limited to computer displays generated in response to the software, there is no direct interaction of the received software with any video program carried on the cable network. The downloaded software does not control further interactions with the storage center. Also, the video transmissions on the cable system are analog, and a separate telephone connection is required for selection inputs to the central storage facility. Furthermore, the terminal device apparently can receive software from the storage center of only one service provider.

Some prior art systems do permit downloading into the cable television decoder itself, however, it is believed that this downloading of information into the decoder has been limited to information controlling the decoding of the television program signals, e.g. a key word used in a descrambling algorithm. Dufresne et al., in U.S. Pat. No. 4,623,920 teach a specific scheme for addressing data transmissions over a cable television network to groups of terminals or to individual terminals. The addressed data sent from the head end can include an option table of signals for controlling descrambling of available television programs, data to enable operation of a cable TV converter, or software for operating a peripheral microcomputer separate from the cable television terminal device. The Dufresne et al. terminal is limited to reception of data from only one service provider, i.e. the provider operating the cable TV network. Also, the services provided through the terminal are limited in that the downloaded data apparently does not alter or control the terminal functionality for further interactions with the provider through the network.

Recently, several different wideband digital distribution networks have been proposed for offering subscribers an array of video services, such as Video On Demand. The following U.S. Pat. Nos. disclose representative examples of such digital video distributions networks: 5,253,275 to Yurt et al., 5,132,992 to Yurt et al., 5,133,079 to Ballantyne et al., 5,130,792 to Tindell et al., 5,057,932 to Lang, 4,963,995 to Lang, 4,949,187 to Cohen, 5,027,400 to Baji et al., and 4,506,387 to Walter. The terminal devices in these digital networks are still limited functionality devices. In these networks, the digital terminal devices still only receive selection inputs, transmit selection signals upstream to the source of the video materials, receive downstream video transmissions, decompress the digitized video materials and convert to analog form, and provide appropriate signals to a television receiver. One example of such a digital video distribution network and the terminal device for such a network, disclosed in Litteral et al. Pat. No. 5,247,347, will be described in more detail below.

U.S. Pat. No. 5,247,347 to Litteral et al. discloses an enhanced public switched telephone network which also provides a video on demand service to subscribers over the public switched telephone network. A menu of video programming information is displayed at the subscriber's premises by a set-top terminal and a TV set. The subscriber may transmit ordering information via the public switched telephone network to the independent video information providers. Video programming may be accessed and transmitted to the subscriber directly from a video information provider (VIP) or through a video buffer located at a central office (CO) serving the subscriber.

Connectivity between the central office and the subscriber for transmission of video data is provided by an asymmetrical digital subscriber line (ADSL) system. ADSL interface units at the central office multiplex digital video information with voice information to be transmitted to the subscriber and support two-way transmission between the subscriber's line and the X.25 packet data network of one or more control channels. A complimentary ADSL interface unit at the subscriber's premises separates downstream video control signals and voice telephone signals from the line and multiplexes upstream control signals and voice telephone signals onto the line. The ADSL interface on the subscriber premises supplies the broadband digital data stream recovered from the transmission over the subscriber loop to a decoder unit in the set-top terminal. The decoder unit decompresses the audio and video data, and converts the digital audio and video to corresponding analog signals. The decoder can supply baseband analog audio and video signals to a television receiver, or these analog signals can be modulated to a standard television channel frequency for use by the television receiver.

The above detailed discussion of the Litteral et al. system shows that prior art digital distribution networks offer enhanced video services, but the terminal device functionality is still limited to program selection, decoding and display.

A number of suggestions have been made in the press regarding arrays of different services which will become available through broadband digital networks now popularly referred to as the "Information Super Highway". If a different VIP were to offer a different service, the VIP can limit the service to an interactivity with the subscriber essentially corresponding to the functionality available in the terminal device. This approach, however, limits the functional capabilities the new VIP may choose for the different service. Alternatively, the subscriber must buy another terminal device programmed or wired to function in accord with the VIP's new service. This second approach, however, forces the subscriber to purchase and connect up a different terminal device for each different service subscribed to.

From the above discussion it becomes clear that a need exists in the art for set-top terminal devices which process compressed, broadband digital audio/video information and are readily adaptable to perform a variety of related functionalities, as needed to facilitate a range of audio/video and interactive services offered by a large number of information providers.

In the 08/250,791 grandparent application cited above, it was suggested that software could be downloaded into the digital set-top terminal through a point-to-point connection through a digital broadband network, e.g. similar to that of Litteral et al. As disclosed therein, the software included at least customized applications programs for controlling terminal operation in a manner specified by an individual information provider. It was also suggested that at least one party would operate a server to download operations system upgrades through a point-to-point connection. Point-to-point connections through broadband digital networks are relatively expensive, and some digital networks under development will have broadcast channels, but at least initially, will not offer point-to-point connections. The disclosure in the 08/250,791 application did not address problems of downloading software to terminals through digital broadcast networks.

In the 08/380,755 parent application cited above, it was suggested that software, specifically software related to channel mapping functionalities and navigation through broadcast services, could be downloaded into the digital set-top terminal through a data carousel type cyclical broadcast. Such downloaded software consisted of one or more applications intended for wide general availability. The digital type set-top devices receiving such software were intended as open interface devices to which any provider offering such a download service could download the relevant data and executable code.

An operating system includes programming to control internal operations of the control processor, such as those necessary to execute specific types of communications over the network, graphics drivers, etc. The operating system typically allows the set-top to run a variety of downloaded applications programs, preferably made available by a number of service providers. It is desirable to periodically update the operating system software, as improvements are developed, without having a technician manually service each terminal. The downloading of an operating system program for running the terminal device raises a more complicated set of problems relating to who can download such software to which types of terminals.

Access to the ability to modify the operating system must be carefully controlled. If access were open, an unscrupulous party could write a destructive operating system, e.g. that would allow the terminal to access only one provider's services or that might cause the terminal to begin upstream transmissions in some manner which would disrupt upstream transmissions of other terminals. The downloaded operating system would need to correspond to the particular type of set-top terminal to insure compatibility. Also, the downloading of the operating system must be particularly error free to insure that errant reception and overwriting of operation system software does not in some corrupt or disable terminal operation.

A need therefore still exists to reliably and securely download operating system software to the digital set-top terminal through a widely accessible broadcast channel.

DISCLOSURE OF THE INVENTION

The present invention addresses the above noted needs by providing methods, systems and terminal device structures for downloading operating system software to programmable set-top terminal devices through digital broadcast channels.

In one aspect, the invention contemplates a set-top terminal device to which new operating system software can be downloaded through one of the broadcast channels. The terminal device includes a network interface module. This module couples the terminal to a communication network. From the network, the interface module receives at least selected ones of a plurality of broadcast digital broadband channels. One or more of the broadcast channels carries audio/video program information in compressed, digital form in packets of a standardized format. Also, one of the broadcast channels carries cyclically repetitive transmissions of the operating system software in packets of the standardized format.

The set-top terminal also includes a digital entertainment terminal. The digital entertainment terminal includes an audio/video processor for processing the compressed, digital audio/video program information from a selected broadcast channel. The digital entertainment terminal also includes a memory and a remote control or the like for supplying inputs from a user to the digital entertainment terminal. A control processor captures the operating system software from one of the selected digital broadband channels. The control processor loads the captured operating system software into the memory and begins operation in accord with the operating system software. For example, using the operating system software in the memory, the control processor controls the network interface module and the audio/video processor in response to the user inputs.

Another aspect of the invention relates to a communication system including a network for broadcasting the channels to a plurality of terminals, similar to the set-top terminal discussed above. This system includes a source system supplying program material and software for broadcast through a digital network. The source system comprises a program source supplying a broadband program signal and a software server cyclically outputting a data file containing an operating system. An encoder system packetizes the broadband program signal and the data file in digital packets of the standard format.

In the preferred implementation, the encoder processes analog audio/video signals to digitize, compress and packetize the program information in accord with the moving pictures expert group (MPEG) standard. The preferred network utilizes Asynchronous Transfer Mode (ATM) transport. The encoder system therefore includes an ATM multiplexer for adapting the MPEG packets into ATM cells and combining ATM cells from one or more programs together with ATM cells containing the operating system into a stream for transport through the ATM broadcast network.

As digital networks develop and remain in wide use over a period of time, the set-top terminal device will essentially become a piece of consumer electronics equipment. At such a time, different end users will obtain set-top terminals of different types from a number of different providers and will connect different types of set-top terminals to the same digital network. Different types of set-top terminals will utilize different operating systems. A further aspect of the invention therefore relates to broadcasting a plurality of different operating systems for correspondingly different types of set-top terminals. Each type of set-top terminal will identify the correct operating system from among the plurality broadcast and capture only that operating system.

Another feature of the invention relates to identification of the need for a particular set-top terminal to upgrade its operating system. Specifically, each operating system for a particular type of set-top terminal has a version number. The set-top terminal stores a version number for the operating system that it currently is running, and the broadcast data stream will include data identifying the version number of the operating system being broadcast for the particular type of terminal. The set-top terminal actually captures an operating system from the broadcast if the broadcast version number is different (e.g. higher or lower) than the number of the version that terminal is currently running.

In accord with the present invention, the operating system upgrade process can begin automatically, or a user can manually trigger the upgrade process. For automatic activation, a processor in the set-top terminal will monitor some periodic occurrence, such as the passage of some time interval or cycles of turn-off by a user. For manual activation, the user may call up a menu display by the set-top terminal and select the operating system upgrade from the menu.

Applications software can be downloaded to the set-top via the network. The set-top may capture a desired application from a digital broadcast channel in a manner similar to that used to acquire the new operating system. Alternatively, the user may establish a point-to-point broadband call to an interactive service provider's system, in which case, the service provider's system downloads an application to control further interactivity via the point-to-point link.

The present invention may be utilized on a variety of different types of broadcast networks, particularly those carrying digitized and compressed broadcast programming. Several networks are cited, and a preferred network is disclosed in detail. The preferred digital network includes a system of optical fibers for broadcasting the digital packets from the encoder system to a plurality of host digital terminals. Each host digital terminal routes selected digital broadcast channels to a group set-top terminals connected thereto.

Additional objects, advantages and novel features of the invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The objects and advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates a digital broadcast system utilizing the operating system download of the present invention.

FIG. 2 shows a software server, program sources and an encoder system used in the network of FIG. 1.

FIG. 3 illustrates an exemplary structure of an MPEG II type data packet.

FIG. 4 shows an exemplary structure of an ATM cell.

FIG. 5A illustrates a five-cell adaptation for mapping an MPEG II packet into ATM cells.

FIG. 5B illustrates an eight-cell adaptation for mapping two MPEG II packets into ATM cells.

FIG. 6 illustrates a digital set-top terminal device in accord with the present invention.

FIG. 7 shows a memory layout for the digital entertainment terminal and an associated diagram of functions involved in memory management and software downloading in accord with the present invention.

FIGS. 8A and 8B together depict a block diagram of a full service digital broadband network in accord with a preferred embodiment of the present invention.

FIG. 9 is a flow chart illustrating an exemplary procedure for upgrading the operating system of the set-top terminal device using software downloaded through a broadcast channel.

BEST MODE FOR CARRYING OUT THE INVENTION

In the digital broadband networks of type under consideration here, each user has a set-top terminal device 100 (FIG. 1). The set-top device 100 includes a digital entertainment terminal (DET) 102 and a network interface module (NIM) 101.

With the present invention the set-top terminal 100 (preferably the DET portion 102 thereof) receives and stores downloaded operating system software and application software. The terminal 100 can establish a point to point link to interactive equipment operated by a video information provider (VIP) and receive interactive applications software through the point to point link, as disclosed in the above incorporated 08/250,791 application. The key features of the present invention, however, relate to downloading an operating system through a broadcast channel, therefore the following description concentrates on a broadcast type network implementation and downloading of the operating system through a broadcast channel.

FIG. 1 is a high level functional diagram of a network providing digital broadcast services, preferably using ATM cell transport. The preferred embodiment illustrated in FIGS. 8A and 8B and discussed later utilizes end-to-end ATM transport, i.e. with ATM cells for at least the downstream broadband transmissions going all the way to the set-top terminal devices 100. Other networks which may carry the operating system download in accord with the present invention, such as the hybrid-fiber-coax network shown in FIG. 4 of U.S. patent application Ser. No. 08/304,174, utilize ATM transport in a backbone portion of the network only and use some other transport technology for local loop distribution to the subscriber's terminal device. The software downloading techniques of the present invention can be applied to other such digital broadcast networks.

FIG. 1 therefore provides a generic illustration of the broadcast network 15. As shown, the network 15 receives digitized data streams, preferably in ATM cell format, from one or more sources 11 operated by one or more information providers. In the later discussed preferred embodiment, local loop distribution utilizes switching nodes referred to as host digital terminals (HDT's) which transport ATM cell streams through to the relevant subscribers' set-top terminals 100. In some forms of the network 15, local loop distribution nodes may strip off the ATM cell headers and convert the payload data to some other format for actual transmission to the subscriber terminals. In the preferred embodiment, the local loop distribution network supplies the ATM cells from each broadcast to each set-top terminal 100 from which a subscriber requested the particular broadcast service.

Material intended for broadcast through the network is encoded and packetized in accord with a specified protocol or standard, such as DIGICIPHER.TM.. The preferred embodiments utilize MPEG (moving pictures expert group) encoding. The source system 11 includes one or more program sources 14 and an encoder system 13 for encoding the program material in the desired standard format. Where the network utilizes another transport protocol such as ATM, the encoder also adapts the encoded information to the format utilized on the network 15. In accord with the present invention, the source system 11 also includes a software server which supplies data to the encoder 14.

As shown, a number of source systems 11, 11' supply digitized material to the digital network 15 for broadcast. One service provider may operate a number of the source systems to provide a desired number of broadcast programs or channels. Also, the network may offer a `video dial tone` type service whereby a plurality of video information providers (VIPs) separately supply their own programming from one or more such sources. In the simplified example shown in FIG. 1, source system 11 offers a plurality of broadcast programs from sources 13 and broadcasts software for the downloading service. Other source systems such as system 11' may be identical to system 11 and offer both broadcast programming and software downloading, but most of the other systems 11' will offer only broadcast programming. Source systems offering broadcast programs only will be similar in structure and operation to the system 11 discussed below in more detail with regard to FIG. 2, but those systems 11' will not include the software server and the associated element(s) of the encoder for processing the software.

In normal operation, the broadcast network supplies at least a selected program channel to the set-top terminal 100. The set-top terminal processes information from the selected channel to produce signals capable of presenting information from that channel to a user in humanly perceptible form, e.g. to drive a standard television set 103 to display selected video programming. The NIM 101 provides the actual physical connection to the network and the transport protocol processing (e.g. ATM). The DET 102 performs the actual decoding to produce the output signals from the information. The DET 102 also includes the primary intelligent control processor for overall control of the operation of the set-top terminal 100.

The DET portion of the set-top device 100 includes a non-volatile random access memory (shown in detail in FIG. 6), for example consisting of electrically erasable programmable read only memory (EEPROM) or flash memory. The non-volatile RAM stores the operating system for the set-top device 100. The operating system defines the basic functionality of the set-top 100. For example, the operating system controls how the microprocessor of the DET 102 interprets application programs. The operating system includes the various driver routines permitting the microprocessor to operate the other elements of the set-top 100. The operating system also includes the basic or `resident` application under which the DET operates when not running a downloaded application. The resident application preferably emulates a cable television type program reception type user interface for the particular network to which the set-top 100 connects.

One item stored in the non-volatile memory is a channel identifier for a network program channel that will carry the operating system software, for example channel 0. Typically, an installer will program this value in the DET memory as part of the initial installation procedure, using the keypad on the DET or the remote controller (not shown).

A party providing the operating system upgrade service operates a data carousel application. With this type of application, a digital data stream cyclically repeats, and in accord with the present invention, the network carries the repeating data stream on a broadcast channel. The data stream may include video, audio, data and executable code. For an operating system download, the repeating data consists of a data file containing new operating system code.

The party selling the set-tops to the video information users (VIUs) will provide the operating system updates for those set-top terminal devices. For example, if one of the VIPs sells set-top devices, then that VIP would offer the operating system update service for those set-top devices. If the video dial tone network operator sells the set-top devices, then that operator would offer operating system updates. If the network operator does not operate its own encoder system 11 for other purposes, the operator can make arrangements with one of the VIPs to supply the operating system data carousel through that VIP's encoder system.

To provide the broadcast downloading, a VIP operates a software server, such as server 12. Typically, the server 12 is a personal computer or the like which compiles the code and/or data for transmission. For applications, such as for controlling navigation through the VIP's program services, the computer compiles application software and data to be processed by that application software. For the operating system upgrade service, the computer compiles a data file containing the instructions which form the various modules of the operating system. The computer cyclically outputs the relevant data in sequence. For the operating system download, the computer repeatedly sequentially outputs the contents of the data file.

The server outputs the data file to the encoder system 14. The encoder system processes the data and supplies the processed data to the network 15 for broadcast along with the encoded program information offered by the VIP from the source system
11. When necessary, the set-top selects the appropriate channel, e.g. channel 0, decodes the data from the broadcast through the network and recaptures the operating system data file. In the preferred embodiment, the NIM 101 performs the channel selection and conversion back to a data transport stream (e.g. MPEG packets) from the physical layer protocol utilized on the network (e.g. ATM). The DET 102 in turn processes the transport stream to capture the data file. The DET 102 then utilizes the data file to upgrade its stored operating system software.

In the preferred implementation, the channel 0 that carries the operating system upgrade files also carries network program guide information. The network offers 6 Mbits/s channels. In one example, channel 0 will carry the operating system data file at 1.5 Mbits and carry the video and audio packetized elementary streams for the program guide service at a combined rate of 4.5 Mbits/s in a time division multiplexed transport stream at a combined rate of 6 Mbits/s.

The DET operating system upgrade of the present invention can be initiated either automatically or manually. The DET 102 may automatically check the time or number of power-off cycles since the last upgrade, to trigger an operating system upgrade routine. Alternatively, the user may execute a specified sequence of keystrokes on the remote control to call up a menu. One option on the menu is operating system upgrade. Manual selection of the operating system upgrade feature from the menu would trigger execution of the software upgrade routine.

Once initiated, the only difference in the two procedures is whether the DET 102 provides on screen displays during the upgrade procedure. During a manually initiated procedure, the DET 102 will output some form of `Please Wait` message for display on the screen of the associated television set 103. During an upgrade procedure automatically initiated, e.g. after a power-off input by the user, the DET will not generate any messages.

When initiated, the DET 102 executes a normal channel selection appropriate to the particular network to receive the channel carrying the software broadcasts. In the present example, the DET 102 instructs the NIM 101 to select channel 0, and the NIM alone or through interaction with network elements selects that broadcast channel, captures the transport stream therefrom and passes that stream to the digital signal processing circuitry within the DET 102.

One of the non-writable sections of the memory within the DET stores an operating system upgrade routine. This routine may be stored in ROM or in a sector (e.g. sector 0) of a flash memory. Once the DET has selected and is receiving channel 0, the DET microprocessor calls and executes the upgrade routine from memory. The upgrade routine includes information and instructions necessary to extract the operating system information from the MPEG data stream.

The microprocessor of the DET 102 will check the operating system version number carried on the network for the particular type set-top terminal, by comparing data contained in one of the packets from the received transport stream to data stored in memory. If the version number for the operating system broadcast on the network is the same as the version number of the operating system currently running in the DET 102, then the DET terminates the upgrade process.

However, if the version number for the operating system broadcast on the network differs from the version number of the operating system currently running in the DET 102, then the DET proceeds with the upgrade process. Specifically, the DET extracts the broadcast operating system from the transport stream from the selected channel and stores that new version in RAM. When extraction is complete, the microprocessor checks and confirms that the extracted and stored version is error free. If no errors are found, the microprocessor transfers the version of the operating system from RAM to non-volatile memory, effectively writing the new version over the old version in the non-volatile memory. The microprocessor checks for errors in the version now loaded to non-volatile memory, and if error free, the microprocessor reboots to begin running under the new operating system.

FIG. 2 shows the elements of the source system 11 in more detail. As shown, the source system includes six sources (13.sub.1 to 13.sub.6) of baseband audio/video information, e.g. in NTSC signal format. The encoder system 14 includes a corresponding number of real time encoders (RTEs) 25.sub.1 to 25.sub.6. Each RTE converts one baseband program signal into digitized and compressed form in accord with the selected protocol. The RTEs supply encoded information to an ATM multiplexer 29, either directly as shown for live or other real-time type broadcast services or through some form of storage device or server (not shown) for other types of broadcast and IMTV services.

The encoder system also includes a data module 27. The data module 27 receives the cyclic data output from the software server 12 via an appropriate data interface, e.g. via an Ethernet. The data module 27 formats the data in the same type of packets as produced by the real time encoders 25.sub.1 to 25.sub.6. Preferably, the data module 27 also constructs and inserts certain packets carrying information that the set-tops 100 need in order to find and decode copies of operating systems carried in the packet stream. Because the output from the software server 12 cyclically repeats, the resulting sequence of packets output from the data module 27 also repeats. In an alternate embodiment, the server and data module could be combined, so that the operating system software is stored in memory in MPEG packet form and cyclically, repeatedly output. The data module 27 supplies the packets to another input of the ATM mux 29. The ATM mux adapts the packets from module 27 into ATM cells in the same manner as for packets from the real time encoders 25.sub.1 to 25.sub.6 and multiplexes the resultant cells into the output stream together with the cells carrying the encoded program information.

In the preferred embodiments, the program material represents a television type program or the like in NTSC format. The video information, accompanying audio information and certain related data are encoded using a standardized digitization and compression technique, such as DIGICIPHER.TM. or preferably MPEG (moving pictures expert group). Typically, these digital compression protocols also specify a standard packet data format.

In the preferred implementation, the RTEs 25.sub.1 to 25.sub.6 and the data module 27 operate in accord with MPEG II. A detailed discussion of the standard may be found in International Organisation for Standardization Organisation Interationale de Normalisation, "Coding of Moving Pictures and Associated Audio", ISO/IEC JTC/SC29WG11, CD ISO/IEC 1-13818, February 1994, and a brief summary of MPEG II processing follows.

MPEG is a bi-directional predictive coding compression system, utilizing discrete cosine transformation (DCT) processing to digitize and compress video information. For video information, the encoder will develop reference (I) frames, predictive (P) frames and delta (B) frames.

The number of frames to be coded for each I frame is set in the standardized MPEG syntax, e.g. one reference frame for each group of fifteen frames, or every half second. A prediction is made of the composition of a video frame, termed a P frame, to be located a specific number of frames forward and before the next reference (I) frame, this specific number also is set in the MPEG syntax. Information from previous video frames as well as later video frames is used in formulating the prediction. "Delta" or "B frame" information is developed for coding the video frames between the actual and predicted frames, also by looking at frames in both directions. Rather than updating a whole frame, only the changed (or delta) information is provided for the delta video frames. Typically, between I frames, the frame sequence consists of a repetitive succession of two B frames followed by one P frame.

MPEG II also specifies digitizing and compressing techniques for accompanying audio information. The MPEG II standard provides a standardized format for packetizing the compressed audio and video information and for other data. Under the MPEG II standard, incoming individual video signals and related audio signals are encoded and packetized into respective Video and Audio Packetized Elementary Streams (PES). The video and audio PES's from one or more sources of video programming may be combined with similarly packetized data into a transport stream for transmission or storage.

Each frame of compressed audio or video program information is broken down into a series of transport packets. Data, e.g. in Ethernet protocol form, is also repacketized into MPEG II transport packets. Although the frames can vary in length, e.g. between a full reference I-frame and a delta B-frame, the transport packets have a fixed 188 byte size. Thus, different frames are broken down into different numbers of MPEG transport packets. For example, in a 6 Mbits/s encoding system, a group of frames consisting of a total of 15 frames for one-half second of video (one I frame and a number of P and B frames), breaks down into approximately 4000 transport packets.

The MPEG II standard also permits transport of private or user data as payload information in the 188 byte packets. As discussed in more detail below, each packet includes a packet identifier (PID) value, and the encoder or data module inserts the assigned PID into the packet as part of the packet formatting process. Different PID values are assigned to different programs and content. For example, one program may have a first PID for video, a second PID for audio and a third PID for related data (e.g. closed captioning). The same stream may also contain private data not directly related to the program, e.g. application or operating system software, and a different PID is assigned to packets transporting that data.

As shown in FIG. 3, each 188 byte transport stream packet consists of two or three sections, a 4 byte packet header section, a payload section and/or an optional adaptation field. The header information includes, inter alia, a synchronization byte, a variety of different flags used in reconstruction of the frames, and a thirteen bit program identification (PID) number. PID value 0 is reserved as an indication that the packet includes program association table data (mapping program numbers (PNs) for individual programs into PID values for program maps for those programs). PID value 1 is reserved for identification of packets containing conditional access data, such as encryption information. Other program identification numbers are utilized to identify transport packets with the program source from which they originate.

Periodically, the transport packet for each audio/video program will also include a program reference clock (PRC) value within the optional adaptation field. In a typical 6 Mbits/s MPEG II encoding system, the PRC is present in approximately 10
out of every 4000 video transport packets.

When included, the optional adaptation field includes a section for miscellaneous flags, such as discontinuity counter, private data flag, etc. One of the possible flags carried in this portion of the adaptation field is a program clock reference (PCR) flag. The adaptation field (AF) also includes a section designated for AF options. One of the options this section may carry is the PCR value.

On decompression, the decoder in the DET 102 in sequence reconstructs the frames for a particular program from packets bearing the appropriate PID values, uses the reference frame to form the prediction frames, and then uses the prediction frames and delta information to construct full frames from the delta frames. As discussed in more detail below, circuitry within the DET 102 routes the private data, such as the software download data, to the microprocessor of the DET for further processing.

Returning to FIG. 2, the data module 27 receives a data stream, e.g. RS-232 or Ethernet, from the software server 12 and converts the data stream to an MPEG II transport stream consisting of packets of the type shown in FIG. 3. Essentially, the data module 27 subdivides the input data into units which will fit in the payload of MPEG II packets and combines those units with appropriate MPEG II headers to form the MPEG II packets. The information in the added headers identifies the packets containing the software and identifies the payload information as private data.

The data module 27 also inserts one or more appropriate PID values into the packet headers. For example, one PID value would identify the operating system for a first model of DET, another PID value would identify the operating system for a second model of DET, etc. Separate PID values would identify any application software to be broadcast on the same channel.

The data module 27 also constructs a number of packets used to find and decode desired sequences of packets in the stream, for example a program association map (PID 0), one or more program map tables and a network table. The information contained in the map and tables are discussed in more detail below.

The preferred network embodiments utilize ATM transport, therefore the encoder system 14 includes an ATM multiplexer (mux) 29. The data module 27 receives a repeating or cyclical sequence of one or more data files from the server 12 and supplies a repeating sequence of MPEG II packets to the ATM multiplexer 29.

In ATM, transfer is asynchronous in the sense that the recurrence of cells that contain information from any particular sender is not necessarily periodic. Each device using an ATM network submits a cell for transfer when they have a cell to send, not when they have an assigned or available transmission time slot. However, the ATM cells may ride in synchronous slots on a high-speed time division multiplexed media, such as a SONET optical fiber. ATM allows any arbitrary information transfer rate up to the maximum supported by the ATM network, simply by transmitting cells more often as more bandwidth is needed.

In ATM, information is organized into cells having a fixed length and format. Each cell includes a header, primarily for identifying cells relating to the same virtual connection, and an information field or "payload". Under presently existing ATM standards, a 53 byte ATM cell includes a cell header consisting of 5 bytes and a payload consisting of 48 bytes of payload data (see FIG. 4). The ATM cell header information includes a virtual path identifier (VPI) and a virtual circuit identifier (VCI) to identify the particular communication to which each cell relates. The specific format of the ATM cell is described, for example, in the ATM User Network Interface Specification, Version 3.0, published by The ATM Forum, Mountain View, Calif., also published by Prentice Hall, the disclosure of which is incorporated in its entirety by reference.

FIG. 4 depicts a typical ATM cell format. The ATM cell includes a header section and a payload section. The first 8-bit byte of the header section includes a 4-bit GFC word which provides access control. The first byte of the header section also includes the lower four bits of an 8-bit virtual-path identifier (VPI). The second byte of the header section includes the upper four bits of the VPI and the first four bits of a 16-bit virtual circuit identifier (VCI). The third byte includes the next eight bits of the VCI. The fourth byte of the header section includes the last four bits of the VCI; a 3-bit payload type indicator (PT); and a cell loss priority bit (CLP). The fifth byte of the header section includes an 8-bit header error check (HEC) word. Bytes 6 to 53 carry information and form the ATM cell payload section.

As used here, the ATM multiplexer 29 performs an ATM adaptation function which converts the input information (in MPEG II transport packets) into ATM cells. The ATM multiplexer 29 also performs a multiplexing function to combine cells streams carrying payload data from a number of sources into one higher rate bit stream.

In ATM based networks of the type under consideration here, the MPEG II bit streams are converted into cellular payload data, and cell headers are added. A number of techniques can be used to adapt the transport packets into ATM cells, and certain preferred techniques are described below by way of example.

As noted above, each MPEG packet consists of 188 bytes, whereas each ATM cell includes 48 bytes of payload data. The ATM multiplexer which map the MPEG packets into ATM cells preferably uses two different adaptations to encapsulate MPEG II packets in ATM cells. The first adaptation maps one 188 byte MPEG packet into five ATM 48 byte cell payloads (FIG. 5A). The second adaptation maps two 188 byte MPEG packets into eight ATE 48 byte cells payloads (FIG. 5B).

MPEG packets of 188 bytes map efficiently into ATM cells if pairs of packets are mapped into 8 cells. However, a delay is imposed on mapping of a first cell while waiting for the second cell in the pair. To minimize jitter at the decoder, the packets carrying the PCR values need to be encoded and transported quickly. To avoid delaying first packets containing a PCR while processing a second packet, the present system maps first packets containing a PCR immediately, using the five cell adaptation procedure. In a typical video transmission, the PCR is present in approximately 10 out of every 4000 MPEG II packets. Also, at least some of those 10 packets will arrive as the second packet of a pair. Consequently, only a very small number of packets are mapped using the less efficient 5-cell adaptation.

As shown in the simplified block diagram of FIG. 2, each MPEG type real time encoder RTE 25 supplies a stream of MPEG II packets to the ATM multiplexer 29. The ATM multiplexer 29 checks the flags in the adaption field (if any) in the first packet to determine if that packet includes a program clock reference (PCR) value. The ATM multiplexer applies the 5 cell adaptation to first packets containing a program clock reference (PCR) value. The ATM multiplexer applies the 8 cell adaptation to pairs of cells wherein the first packet does not contain a program clock reference (PCR) value. Packets containing private data, such as applications and operating system software, will not contain a PRC flag.

For each type of adaptation, the ATM multiplexer 53 will first convert the source packet or pair of packets into a single ATM adaptation layer 5 (AAL5) packet. As part of this conversion, the mux will add an AAL5 trailer, either at the end of the single packet or at the end of the pair of packets. The actual trailer consists of 8 bytes of data, including 4 bytes of cyclic redundancy check (CRC) data, user information (e.g. length), etc.

For a 5 cell adaptation (FIG. 5A), the AAL5 packet consists of a single MPEG packet of 188 bytes and an 8 byte AAL5 trailer, for a total of 196 bytes. To map this packet into ATM cells, the AAL5 packet is also padded with 44 bytes after the trailer, for a total of 240 bytes of payload data. The ATM mux 53 breaks the AAL5 packet (240 bytes) down into five 48-byte payloads (SAR-PDU) and attaches appropriate 5 byte headers to each payload to thereby form five 53-byte ATM cells.

The header of all five of the ATM cells will contain the VPI/VCI value assigned to the particular communication. For example, for the broadcast service combined with the software downloading, the assigned VPI and VCI value would correspond to network logical channel 0. For the video and audio portion of the program guide service, the packets would periodically contain a PCR value and periodically would go through the 5 cell adaptation in the normal manner. The header of the first of the five cells also has a bit designated "AAU" which has a value of "0" to identify that cell as the first cell. The header of the fifth cell will have an AAU bit value of "1" to identify that cell as the last cell.

For an 8 cell adaptation, the AAL5 packet consists of two MPEG packets of 188 bytes and an 8 byte AAL5 trailer, for a total of 384 bytes. The ATM mux 53 breaks the AAL5 packet (384 bytes) down into eight 48-byte payloads and attaches appropriate
5 byte headers to each payload to thereby form eight 53-byte ATM cells. The AAL5 layer is omitted from FIG. 5B for simplicity. That drawing shows the mapping of two MPEG packets into eight ATM cells with the inclusion of the AAL5 trailer in the last cell.

The header of all eight of the ATM cells will contain the VPI/VCI value assigned to the particular communication. Continuing the above example, if the MPEG data relates to the program guide or the operating system downloading service, the assigned VPI and VCI values would identify logical network channel 0 as in the above discussed example of the five-cell adaptation. The header of the first of the eight cells will have an AAU bit value of "0" to identify that cell as the first cell. The header of the eighth cell will have an AAU bit value of "1" to identify that cell as the last cell.

As noted above, each cell of a particular stream will have a header which contains a virtual path identifier/virtual circuit identifier (VPI/VCI) to identify the virtual circuit that the cells pertain to. All MPEG packets for a given program, whether video, audio or data, will be mapped into ATM cells having the same VPI/VCI. Conversely, cells having a given VPI/VCI will contain data corresponding to only one identified program. Thus, in the above broadcast example, the cells from the one broadcast program all contain the same VPI/VCI value whether the five-cell adaptation was used or the eight-cell adaptation was used.

In the presently preferred embodiment, the ATM mux 29 processes MPEG II packet streams for a combined program or transport stream capacity of approximately 36 Mbits/s. For simplicity, it is assumed that normal video programs utilize a 6 Mbits/s encoding. The program guide service, however, includes relatively little motion and can be efficiently encoded at a 4.5 Mbits/s rate. The data module therefore can cyclically output the software at 1.5 Mbits/s. The ATM mux 29 therefore receives packet streams from up to six real time encoders (RTEs) 25 and one data module. In a source system 11 offering no software downloading service there would be no server 12 or data module 27, and the mux 29 would receive six 6 Mbits/s MPEG II streams from the six RTEs. The ATM mux 29 performs the AAL5 adaptations of FIGS. 5A and 5B on all of the inputs from the real time encoders 25.sub.1 to 25.sub.6 and the data module 27 (if included). The ATM mux 29 forms the actual ATM cells with assigned VPI/VCI values in the cell headers and combines the ATM cells from all of the programs and the software transmission into a single DS3 bit stream.

In mapping cells from multiple programs to ATM cells and combining cell streams into a signal bit stream, it is necessary for the mux 29 to map the PID value from each MPEG II packet into the correct VPI/VCI value for the corresponding program. The ATM mux 29 therefore is programmed to recognize the PID values of packets for each program and apply the adaptation techniques discussed above relative to FIGS. 5A and 5B and to map the PID values into the assigned VPI/VCI values.

At the network node which terminates the ATM cell transport, a receiver captures each ATM cell having a specified VPI/VCI. In the preferred embodiment, the network 15 transports ATM cells through to the set-top terminals 100, therefore the receiving node would be the subscriber's terminal or set-top 100.

The element of the network terminating ATM transport will include an ATM demultiplexer (not shown). In the preferred embodiment utilizing ATM cell transport to the set-top terminal devices 100, the ATM demultiplexer is an element of the NIM 101. In other network implementations, the ATM demultiplexer may simply reconstruct the MPEG transport streams and supply those streams to some other mechanism for broadcasting the MPEG streams to the set-top devices 100.

Wherever implemented, the ATM demultiplexer receives a multiplexed ATM cell stream carrying ATM cells relating to a number of programs or sessions. The ATM demultiplexer performs two functions, demultiplexing the combined stream to recover cells relating to at least one communication and ATM to MPEG reverse adaptation to strip off the ATM cell headers and reconstruct the MPEG packets. In the preferred embodiment wherein the ATM demultiplexer is an element of the NIM 101, as part of the demultiplexing function, the demultiplexer captures all MPEG II packets carried in cells having a single specified VPI/VCI value and provides those packets to a decoder in the DET 102.

Other demultiplexing functions are possible depending on where the demultiplexer fits into the overall network architecture. For example, the demultiplexer could provide multiple outputs to multiple decoders. For example, the hybrid fiber coax based system disclosed in FIG. 4 of the above-cited 08/304,174 application, an ATM packet handler performs the ATM demultiplexer function. That packet handler provides multiple output rails each of which carries a combined MPEG II packet stream for 4
programs for broadcast in one 6 MHz RF channel. The NIM captures a combined stream from an RF channel, and an MPEG decoder in the DET processes packets for one of the 4 programs based on PID value recognition.

As part of the reverse adaptation functionality, the demultiplexer buffers cells until it finds a cell having an AAU value of "0" in its header (first cell) and another cell having an AAU value of "1" in its header (last cell). The demultiplexer counts the number of cells from first to last to determine the type of adaptation used to map cells.

If the demultiplexer has captured five cells, the demultiplexer pulls out the payload data and uses the CRC data do check for errors. If there are no errors, the original MPEG packet is reconstructed from the appropriate bytes of payload data from the first four cells. Similarly, if the demultiplexer has captured eight cells, the demultiplexer pulls out the payload data, does the CRC based error check, and if there are no errors, the original pair of MPEG packets is reconstructed from the appropriate bytes of payload data from the eight cells.

The DET 102 processes the MPEG II packets in the resultant stream based on their respective PID values. Packets having PID values assigned to audio or video are processed by corresponding decoders and associated driver circuits to produce signals for driving the television set 103 to display the program information to the user. Downloaded software, however, is transferred as private data to the microprocessor of the DET. Of particular note for purposes of the present invention, if the software relates to an operating system, the microprocessor executes the upgrade routine to replace the existing operating system stored in non-volatile RAM with the newly received operating system software.

To facilitate an understanding of the operating system download feature it is useful to consider the structure of the set-top terminal 100 in more detail. A preferred network implementation is discussed below with regard to FIGS. 8A and 8B, and a preferred procedure for operating system upgrades executed by the DET 102 is discussed below with regard to the flow chart of FIG. 9.

The set-top terminal 100 shown in FIG. 6 will connect to a number of different types of digital networks, offering broadcast and point-to-point type services, such as disclosed in commonly assigned application serial no. 08/413,810 filed Mar.
28, 1995 entitled "Access Subnetwork Controller for Video Dial Tone Networks" (attorney docket no. 680-093B), the disclosure of which is incorporated herein entirely by reference. A specific preferred network embodiment is discussed in detail below with regard to FIGS. 8A and 8B.

For each different type of network, the terminal 100 includes a network interface module 101 providing the actual physical connection to the particular type of network. For example, in a fiber to the home network, the module 101 would include means for two-way conversion between electrical and optical signals and connections to one or more optical fibers for the necessary two-way transmission. However, the network interface module might be modified for a non-physical communication link, for example, via satellite-to-antenna, especially in rural areas. In the preferred network discussed below, the NIM 101 provides the connection to the coaxial cable type drop.

The network interface module 101 will also perform any format conversion necessary between signal formats utilized by the network and signal formats used within the DET 100. For example, in the switched digital video type network disclosed below with regard to FIGS. 8A and 8B, the network interface module 101 will include means to receive and process a baseband 180 Mbits/s broadband data stream, select a DS-3 from that stream, and process and convert a selected ATM cell stream into MPEG II bit stream for further processing by the DET 102.

The network interface module also provides two-way signal conversion and formatting for control signalling between the DET and NIM and for a control signaling channel through the particular network. For example, the network interface module would include means to multiplex and demultiplex signals for transmission/reception over a coaxial cable or optical fiber.

In the illustrated embodiment, the network interface module 101 presents two connections to the DET 102, a high bit rate broadband connection and a low bit rate signaling connection. The broadband connection is a one-way downstream only connection, but the low-bit rate signaling connection is a two-way connection.

The network interface module 101 takes the form of a plug in module. In one embodiment, the module 101 would be similar to a daughter board or option card which can be plugged into a back plane of a personal computer (PC). In such an embodiment, typically a technician could replace the module in either the field or the shop, to modify a set-top device 100 to connect to and communicate over a different network, and the technician would modify associated communications control software in the system memory. Alternative implementations may use a user replaceable cartridge type network interface module, similar to a video game cartridge, which may include memory in the module for storage of the communications control. As a further alternative, the network interface module could include a digital signal processor controlled by the CPU of the DET 102 and input/output connections compatible with all of the digital broadband networks currently available. The downloaded operating system software stored in the system memory of the DET would control operations of the digital signal processor to send and receive signals in accord with the particular network to which the subscriber chooses to connect the set-top device 100.

The DET 102 includes a CPU 105, comprising a 386, 486 PENTIUM.TM., or Motorola 6800 Series microprocessor 110 and associated system memory 120. The system memory 120 includes at least 2 mbytes of volatile dynamic random access memory (RAM) 122
and 1 mbyte of non-volatile random access memory (NVRAM) 121. In the preferred embodiment, the NVRAM 121 is a flash memory device. The CPU 105 also includes a read only memory (ROM) 115, either as a separate element connected to the microprocessor 110
as shown or as an element within the microprocessor 110. The ROM 115 stores "loader" programming needed to control wake-up. The non-volatile RAM 121 stores the operating system for the microprocessor 110. In operation, the volatile RAM 122 temporarily stores applications programs for execution by the microprocessor 110 as well as related data files, and during operating system download operations, the RAM 122 temporarily stores the new operating system.

In the preferred embodiment, the operating system for the DET 102 includes a version of a PC type operating system, e.g. OS-9. In addition, the operating system for the DET 102 includes the various drivers necessary for the DET microprocessor
110 to operate the associated peripherals, e.g. the Digital Audio/Video Processor 125, the Personal Computer Memory Card Industry Association (PCMCIA) port 155, the RS-232 transceiver 151, etc. The set-top operating system also includes the resident cable television emulation software, i.e. as needed to facilitate reception of broadcast programs through the particular network. This operating system is stored in a portion of the non-volatile RAM 121 having a relatively low level of protection. When a new operating system is installed, as discussed more fully below, the new operating system replaces the entire operating system previously stored in the non-volatile RAM. The level of protection here provided enables rewriting the operating system using a broadcast channel download procedure, however, there is sufficient protection to limit storage to only acceptable software from an authorized provider.

A digital audio/video (A/V) signal processor 125, controlled by the CPU 105, produces digital uncompressed audio and video signals from the audio and video MPEG encoded packets received from the network through the interface module 101. The audio/video processor 125 includes an MPEG system demultiplexer 127, an MPEG video decoder 129, an MPEG audio decoder 131, a graphics overlay controller 133 and at least two frames of video RAM 135.

The MPEG system demultiplexer circuitry 127 recognizes packets in the MPEG data stream received over the broadband channel through the network interface module 101 and routes the packets to the appropriate components of the DET 102 based on the PID values of the respective packets. For example, the MPEG system demultiplexer 127 circuitry recognizes audio and video packets in the MPEG II data stream and routes those packets to the decoders 129, 131, respectively. The MPEG system demultiplexer
127 routes private data, such as downloaded software, to the microprocessor 110.

The MPEG video decoder 129 decompresses received video packet signals to produce a digital video signal, and the MPEG audio decoder 131 decompresses received audio packets to produce left and right digitized stereo signals. For at least some functions, the MPEG decoders 129, 131 may be controlled in response to signals from the microprocessor 110. The MPEG video decoder 129 will internally include at least two frames (e.g. 8 mbytes) of RAM (not separately shown) for use as a frame reorder buffer during the MPEG video decoding process, and the MPEG audio decoder 131 also may include some buffer memory.

The video RAM 135 is not a specialized "video RAM" as that term is sometimes used in the television art. The RAM 135 is actually a standard digital data RAM, of appropriate size, which is used in the DET to store digitized frames of video data. The RAM within the MPEG video decoder 129 likewise consists of standard digital data RAM.

The graphics display generator produces displays of text and graphics data, such as a selection menu received over the signaling channel, in response to instructions from the CPU 105. The video RAM 135 sequentially receives each frame of digitized, uncompressed video information, as output from the MPEG video decoder 129. The video RAM 135 also receives digital information and read/write control signals from the graphics overlay controller 133 representing the several planes of text and graphics information and combines that information with the frames of decompressed video to produce composite video frames.

The graphics overlay controller 133 and the video RAM 135 actually cooperate to manipulate five different planes of video information, four of which can be active at any one time, to produce the composite video frame output signals. The individual planes comprise the decoded MPEG video frames, a cursor, two graphics/text image planes manipulated by the microprocessor 110 and a backdrop plane. The backdrop plane would be switched in to replace the plane representing the decoded MPEG video frames, e.g. to present a blue background instead of the MPEG video background.

When there are no graphics or text, the composite frames would correspond entirely to the uncompressed received video frames output by the MPEG video decoder 129. When no received video frames are to be output, either when none are received or when they are to be entirely replaced, the information from the graphics overlay generator 133 would specify a background and the active planes of text or graphic information. When received video frames are combined with text and/or graphics, the composite video frames include the uncompressed received video frames with selected pixels thereof replaced with graphics or textual data display pixels specified by the graphics overly controller 133. In this last situation, the graphics overlay controller would deactivate the backdrop plane.

Under certain circumstances, the video RAM 135 also serves to freeze video frames. For example, when a video transmission ends for some reason, the RAM 135 will contain the video and associated graphics information for the frame last received and displayed. The DET 102 can continue to output this frame as a still video output signal for some period of time.

The DET 102 also includes audio and video digital to analog converters and appropriate drivers to produce output signals compatible with a conventional television set. Specifically, the converter and driver circuitry of the DET 100 includes audio digital to analog converters (DAC's) 134.sub.L, 134.sub.R, an audio mixer 136, an NTSC encoder 137, and an RF modulator 139.

The DAC's 134.sub.L and 134.sub.R receive the uncompressed left and right digitized audio signals output by the MPEG audio decoder 131. In response, the DAC's 134.sub.L and 134.sub.R produce baseband analog audio signals for output to individual baseband output terminals. The audio mixer 136 also receives the baseband audio signals from the DAC's 134.sub.L and 134.sub.R. The mixer 136 combines the left and right analog audio signals to produce a monaural audio signal as the audio input to RF modulator 139.

The NTSC encoder 137 also performs a digital to analog converter (DAC) function. In response to the digitized video output signals from the video RAM 135, the NTSC encoder 137 produces a baseband analog video signal in standard NTSC format. The baseband NTSC video signal is supplied to an output terminal of the DET 102. The baseband NTSC video signal is also supplied to the RF modulator 139. The RF modulator 139 responds to the mono audio signal, the NTSC video signal and an RF signal from a local RF oscillator 141, to produce a selected standard RF television signal on an available TV channel, typically channel 3 or channel 4.

The type of connection of the DET 102 to the television set depends on the capabilities of the user's television set. If the user has a monitor type television capable of receiving baseband video and stereo audio inputs, the appropriate terminals of the television would connect directly to the video and audio output terminals of the DET 102. If the subscriber does not have such a television monitor, then the RF output of the modulator 139 would be connected to the cable or antenna input connection of the television, e.g. by coaxial cable. Alternatively, the digitized video and audio may go to separate output terminals (not shown) for connection to inputs of digital display devices, for example, for high definition television (HDTV) sets.

Each DET 102 also includes means to receive selection signals from a user, and under at least some circumstances, transmit appropriate data signals over a narrowband channel through the particular video network. For example, the DET 102 may send and receive control data through a signaling channel on the subscriber's loop or drop cable. In the preferred embodiment, a switching element of the network routes selected broadcast channels to the set-top 100. The DET 102 provides selection signals to the NIM 101 for upstream transmission over the signaling channel to that switching element to identify a requested channel. In a similar fashion, the set-top terminal may transmit upstream signaling information through the signaling channel for transport through the network to a video information provider offering interactive services.

In the embodiment illustrated in FIG. 6, the DET 102 includes an infrared (IR) receiver 145. The (IR) receiver 145 responds to inputs signals from a user operated IR remote control device (not shown) similar to that used today for controlling televisions and video cassette recorders. In response to the IR signals, the receiver 145 produces corresponding digital data output signals. The microprocessor 110 interprets the digital data signals by the IR receiver 145 as input commands. The precise interpretation of specific command signals can vary based on the downloaded applications programming and/or the operating system software currently stored in the system memory 120. For example, in response to certain input commands, the microprocessor 110 controls cursor position and alphanumeric information displayed as graphics and text on the associated television set. The microprocessor 110 will also respond to an appropriate input command from the user to formulate a message for upstream transmission though the network interface module 101 and the signaling channel of the particular connected network, e.g. to select a broadcast channel.

The set-top terminal device 100 of the present invention is an open interface device in that it interacts with equipment of a large number of service providers (often referred to as "VIPs") to offer users a wide array of video and interactive multi-media services. In the preferred embodiments, the digital entertainment terminal (DET) 102 is a programmable device to which different individual video information providers (VIPs) can download applications software, and at least one VIP or the network operator (the party selling the set-top device to the end user) can download the operating system software.

In the ROM 155 and/or a relatively high-level write protected portion of the NVRAM 121 (e.g. sector 0 of flash memory), the DET will store a loader program similar to the bios of a PC. The NVRAM 121 will also store an operating system. The loader program and operating system in the ROM and the non-volatile RAM will include sufficient programming to control initial communications and define interfaces and drivers, e.g. for graphics to define the base line functionality of the DET for all service applications the DET will run. This stored software also includes the resident application, which in the preferred embodiment is a CATV-like broadcast program reception routine appropriate for the particular network connected to the set-top terminal 100. The ROM or the most write-protected portion of the NVRAM also stores an operating system upgrade routine for controlling the DET process of upgrading the operating system through a broadcast channel download operation.

The DET 102 of the present invention may also include a number of additional interface devices. In the example illustrated in FIG. 6, the DET 102 includes an IR transmitter 147. The transmitter 147 responds to digital data signals from the microprocessor 110 and outputs corresponding IR signals for wireless transmission. The IR transmitter 147 and IR receiver 145 may operate together to provide a two-way wireless data communication link to some