(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2002/004998.0 A1
`Hoang
`(43) Pub. Date:
`Apr. 25, 2002
`
`US 2002004998OA1
`
`(54) CONTROLLING DATA-ON-DEMAND
`CLIENT ACCESS
`(76) Inventor: Khoi Nhu Hoang, Pleasanton, CA (US)
`Correspondence Address:
`OPPENHEIMER WOLFF & DONNELLY
`P. O. BOX 10356
`PALO ALTO, CA 94.303 (US)
`(21) Appl. No.:
`09/902,503
`(22) Filed:
`Jul. 9, 2001
`Related U.S. Application Data
`(63) Continuation-in-part of application No. 09/584,832,
`filed on May 31, 2000. Continuation-in-part of appli
`cation No. 09/709,948, filed on Nov. 10, 2000. Con
`tinuation-in-part of application No. 09/841,792, filed
`on Apr. 24, 2001. Continuation-in-part of application
`No. 09/870,879, filed on May 30, 2001. Continuation
`in-part of application No. 09/892,015, filed on Jun.
`25, 2001.
`
`Publication Classification
`
`... H04N 7/173
`(51) Int. CI.7.
`(52) U.S. Cl. ................................................................ 725/91
`
`(57)
`
`ABSTRACT
`
`The present invention teaches a method for controlling client
`access to DOD Services, comprising: receiving a Subscrip
`tion data packet including at least one associated client
`identification code, at least one associated Subscription level
`code, and at least one associated Service level code; and
`Storing at least a portion of the at least one associated
`Subscription level code in a memory location; Storing the at
`least one associated Service level code in a memory location;
`receiving a first Service having a Subscription level; and
`wherein the Subscription level code corresponds to the
`Subscription level, accessing the first Service. The method
`further includes: receiving a Second Service having at least
`one associated Service level; and wherein the at least one
`asSociated Service level code corresponds to the at least one
`asSociated Service level, accessing at least a portion of the
`Second Service.
`
`604
`CENTRAL
`PROCESSING
`UNIT
`
`608
`
`
`
`BUFFER
`MEMORY Y 610
`
`OUTPUT
`DEVICE
`
`FAST
`DATA
`BUS
`
`
`
`
`
`
`
`
`
`62O
`COMMLINK
`ETHERNET,
`USB, FIREWIRE
`MODEM
`
`USER
`INTERFACE
`
`GRAPHICS
`OVERLAY
`
`
`
`
`
`600
`
`DISH, Exh.1008, p.0001
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 1 of 15
`
`US 2002/004998.0 A1
`
`
`
`
`
`| __| | | | | | | E™E
`
`E?&E
`
`
`
`(THW HO|Hd)
`
`DISH, Exh.1008, p.0002
`
`

`

`Patent Application Publication
`
`Apr. 25, 2002. Sheet 2 of 15
`
`US 2002/0049980 A1
`
`
`
`DISH, Exh.1008, p.0003
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 3 of 15
`
`US 2002/004998.0 A1
`
`s
`
`
`
`s
`
`3 y
`
`DISH, Exh.1008, p.0004
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 4 of 15
`
`US 2002/004998.0 A1
`
`WZ?
`
`
`
`778
`
`Z ?NH|TO
`
`U
`
`| = |
`
`W43 = M8 GEHInOBHTW101
`
`
`
`(IHW HOR?d)
`
`
`
`
`
`
`
`
`
`
`
`
`ZZ$
`
`DISH, Exh.1008, p.0005
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 5 of 15
`
`US 2002/0049980 A1
`
`340 -1
`
`CSARD
`IDENTFYTHEAVAILABLE
`SLOTS WITHIN THE
`AVAILABLE BANDWIDTH
`
`PROVIDE EACHCLIENTA
`SUTABLEEPG
`
`342
`
`344
`
`RECEIVE DEMAND FORSPECIFICDATA
`FROMAPARTICULARCLIENT, THE
`DEMAND INCLUDING INFORMATION
`IDENTIFYING THE CLIENT
`
`IDENTIFY THE SPECIFICCIENT FROM
`NFORMATION INCLUDED WITH THE
`DEMAND
`
`346
`
`348
`
`
`
`
`
`CLIENTAUTHORIZED
`TO RECEIVE SPECIFIED
`DATA
`
`
`
`350
`
`NO
`
`TRANSMIT
`REFUSAL
`MESSAGE
`
`356
`
`ASSIGNSLOTTO
`AUTHORIZEDCLIENT
`
`
`
`PREPARE THE REQUESTED
`CLIENTSPECIFICDATAFOR
`TRANSMISSION
`
`TRANSMIT CLIENTSPECIFIC
`DATAVATHEAPPROPRIATE
`ALLOCATEDBANDWDTH
`
`
`
`FIG. 5
`(PRIORART)
`
`DISH, Exh.1008, p.0006
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 6 of 15
`
`US 2002/004998.0 A1
`
`360
`
`-1
`
`362
`
`364
`
`366
`
`368
`
`370
`
`372
`
`374
`
`TUNE INTO APPROPRIATE
`CHANNEL FORRECEIVING
`EPG
`
`RECEIVEEPG
`
`PROVIDEEPG INFO
`TODODUSER
`
`RECEIVEREQUEST FOR
`SPECIFICDATA
`FROM USER
`
`DEMAND THAT SERVER
`PROVIDEREQUESTED
`CLIENTSPECIFICDATA
`
`TUNE INTO ALLOCATED
`BANDWIDTH
`
`RECEIVECLIENTSPECIFIC
`DATAAND PROVIDE
`TO CLIENT
`
`FIG. 6
`(PRIORART)
`
`DISH, Exh.1008, p.0007
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 7 of 15
`
`US 2002/004998.0 A1
`
`
`
`097
`
`DISH, Exh.1008, p.0008
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 8 of 15
`
`US 2002/004998.0 A1
`
`
`
`009
`
`DISH, Exh.1008, p.0009
`
`

`

`Patent Application Publication Apr. 25, 2002. Sheet 9 of 15
`
`US 2002/0049980 A1
`
`630
`
`SUBSCRIPTIONDATAPACKETVERSION
`STBD,
`SUBLEVELCODE
`SER LEW CODE
`STBD.
`SUB.LEVELCODE
`SER LEV. CODE
`
`STBD.
`STBD.
`STBD.
`
`SUBLEVELCODE
`SUBLEVELCODE
`SUB, LEVELCODE
`
`SER LEV. CODE
`SER LEV. CODE
`SER LEV. CODE
`
`
`
`
`
`
`
`WARNING CODE
`WARNING CODE
`
`WARNING CODE
`WARNING CODE
`WARNING CODE
`
`
`
`
`
`634
`
`
`
`636
`
`638
`
`640
`
`FIG. 9
`
`DISH, Exh.1008, p.0010
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 10 of 15 US 2002/004998.0 A1
`
`648
`
`1
`
`650
`
`
`
`RECEIVESUBSCRIPTION DATAPACKET
`CONTAINING SUBSCRIPTION INFORMATION FOR
`REGISTEREDCLIENTS
`
`
`
`652
`
`STBID
`MATCHANY
`CLEND OF DATA
`PACKET
`
`
`
`654
`
`PACKETMORE
`RECENTTHANLAST
`RECEIVED?
`
`656
`
`
`
`
`
`658
`
`
`
`RETRIEVE SUBSCRIPTIONLEVEL
`SUBSCRIPTION SERVICE AND
`WARNING CODES
`
`UPDATESUBSCRIPTIONLEVEL
`SUBSCRIPTION SERVICE AND
`WARNINGLEVEL OF STB
`
`FIG. 10
`
`DISH, Exh.1008, p.0011
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 11 of 15
`
`US 2002/004998.0 A1
`
`700
`
`DISPLAY
`REFUSAL
`MESSAGE
`
`
`
`
`
`702
`
`
`
`703
`
`
`
`
`
`SELECTDESIRED DOD
`SERVICE TO ACCESS
`
`RETRIEVE SELECTED
`DOD SERVICE
`SUBSCRIPTIONLEVEL
`FROMEPGPROGRAM
`
`
`
`704
`
`
`
`STB
`SUBSCRIPTION
`LEVEL
`SUFFICENT
`
`
`
`
`
`
`
`
`
`706
`
`ACCESS
`SELECTEDDOD
`SERVICE
`
`
`
`708
`
`DISPLAYSELECTED
`DOD SERVICE
`
`
`
`DISH, Exh.1008, p.0012
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 12 of 15 US 2002/004998.0 A1
`
`852
`FIG. 12A
`
`s 5 O
`
`860
`
`-1
`
`862
`FIG. 12B
`
`8 7 O
`-1
`1 || 0 || 1 || 0 || 0 || 0
`
`FIG. 12C
`
`882
`
`12,33,44,56,222
`882
`FIG. 13A
`
`- 8 O
`
`o| 1 ||
`-/-, -/
`872 -1 874
`
`
`
`f
`
`892 -1 894
`
`FIG. 13B
`
`DISH, Exh.1008, p.0013
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 13 of 15
`
`US 2002/004998.0 A1
`
`
`
`900
`
`902
`
`
`
`
`
`SELECTDESIRED DOD
`SERVICE TO ACCESS
`
`
`
`903
`
`
`
`
`
`904
`
`
`
`RETRIEVE SELECTED
`DOD SERVICES
`SERVICELEVEL
`FROMEPGPROGRAM
`
`STBSERVICE
`CODE INCLUDE
`REQUIRED
`WALUE
`
`
`
`
`
`906
`
`ACCESS
`SELECTED DOD
`SERVICE
`
`908
`
`DISPLAYSELECTED
`DOD SERVICE
`
`
`
`DISPLAY
`REFUSAL
`MESSAGE
`
`
`
`DISH, Exh.1008, p.0014
`
`

`

`Patent Application Pu
`blication Apr. 25, 2002 Sheet 14 of 15 US 2002/004998.0 A1
`
`920
`
`922
`
`FIG. 15
`
`DISH, Exh.1008, p.0015
`
`

`

`Patent Application Publication Apr. 25, 2002 Sheet 15 of 15 US 2002/0049980 A1
`
`950
`
`1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`RETRIEVE WARNING CODE
`FROMWARNINGLEVEL
`DATABLOCK
`
`952
`
`WARNING
`LEVEL = 0
`
`BLOCK
`ALLDOD
`PROGRAM
`VIEWING
`
`
`
`
`
`
`
`DISPLAY
`WARNING
`MESSAGE FOR 5
`SECONDS
`
`958
`
`F.G. 16
`
`DISH, Exh.1008, p.0016
`
`

`

`US 2002/0049980 A1
`
`Apr. 25, 2002
`
`CONTROLLING DATA-ON-DEMAND CLIENT
`ACCESS
`
`RELATED APPLICATIONS
`0001. This application is a continuation-in-part claiming
`priority to Khoi Nhu Hoang's patent applications entitled
`COUNTERFEIT STB PROTECTION THROUGH PRO
`TOCOLSWITCHING filed on Jun. 25, 2001, UNIVERSAL
`STB ARCHITECTURES AND CONTROL METHODS
`filed on May 30, 2001, SYSTEMS AND METHODS FOR
`PROVIDING VIDEO ON DEMAND SERVICES FOR
`BROADCASTING SYSTEMS filed on May 31, 2000,
`bearing application Ser. No. 09/584,832, METHODS FOR
`PROVIDING VIDEO ON DEMAND SERVICES FOR
`BROADCASTING SYSTEMS filed Nov. 10, 2000, bearing
`application Ser. No. 09/709,948 and UNIVERSAL DIGI
`TAL BROADCAST SYSTEM AND METHODS filed on
`Apr. 24, 2001, bearing application Ser. No. 09/841,792, all
`three being incorporated herein by reference.
`BACKGROUND OF THE INVENTION
`0002) 1. Field of the Invention
`0003. The present invention relates to data-on-demand
`(DOD) and digital broadcast technology. In particular, the
`present invention teaches a method and apparatus for con
`trolling client access to DOD services.
`0004 2. Description of the Prior Art
`0005) A variety of mechanisms are available for control
`ling the access of data-on-demand (DOD) clients to DOD
`services through set top boxes (STB) for receiving DOD
`programs for display on a television or other Video display
`device. One problem faced in the video-on-demand (VOD)
`and DOD industry is controlling the access of a client’s STB
`to DOD programs without using bi-directional communica
`tions. Traditional uni-directional communications, Such as
`cable, have had many problems in controlling what Services
`Selected clients could access. The advent of the STB allowed
`a mixed Signal to be sent with Some programs being
`scrambled in order to allow only clients with special STBs
`to receive these programs. However, this allowed clients
`who were delinquent in their payments to continue to
`receive Service and made it difficult to change levels of
`Service without eXchanging STBs. Using bi-directional com
`munications allowed for DOD programs to be sent to
`individual clients, however this would use Significant pro
`cessing and bandwidth resources and will not work in
`unidirectional Systems.
`0006 The following is a general discussion of widely
`used digital broadcast Systems. Generally in digital broad
`cast Systems, a bit Stream, multiplexed in accordance with
`the MPEG-2 standard, is a “transport stream” constructed
`from “packetized elementary stream” (or PES) packets and
`packets containing other necessary information. A "pack
`etized elementary stream” (or PES) packet is a data structure
`used to carry "elementary Stream data.” An "elementary
`Stream” is a generic term for one of (a) coded video, (b)
`coded audio, or (c) other coded bit streams carried in a
`sequence of PES packets with one stream ID. Transport
`Streams Support multiplexing of Video and audio compressed
`Streams from one program with a common time base.
`0007 PRIOR ART FIG. 1 illustrates the packetizing of
`compressed video data 106 of a video sequence 102 into a
`
`stream of PES packets 108, and then, into a stream of
`transport Stream packets 112. Specifically, a Video Sequence
`102 includes various headers 104 and associated compressed
`video data 106. The video sequence 102 is parsed into
`variable length Segments, each having an associated PES
`packet header 110 to form a PES packet stream 108. The
`PES packet stream 108 is then parsed into segments, each of
`which is provided with a transport stream header 114 to form
`a transport Stream 112.
`0008 PRIOR ART FIG. 2 is a block schematic showing
`a digital broadcast System 200 including a digital broadcast
`server 202 and a set-top-box 204 Suitable for processing
`digital broadcast data. At the digital broadcast Server 202,
`video data is provided to a video encoder 206 which encodes
`the video data in accordance with the MPEG-2 standard. The
`video encoder 206 provides encoded video 208 to a pack
`etizer 210 which packetizes the encoded video 208. The
`packetized encoded Video 212 provided by the packetizer
`210 is then provided to a transport stream multiplexer 214.
`0009 Similarly, at the digital broadcast server 202, audio
`data is provided to an audio encoder 214 which encodes the
`audio data. The audio encoder 214 provides encoded audio
`218 to a packetizer 220 which packetizes the encoded audio
`218. The packetized encoded audio 222 provided by the
`packetizer 220 is then provided to the transport Stream
`multiplexer 214.
`0010. The transport stream multiplexer 214 multiplexes
`the encoded audio and Video packets and transmits the
`resulting multiplexed Stream to a Set-top-box 204 Via dis
`tribution infrastructure 224. This distribution infrastructure
`224 may be, for example, a telephone network and/or a cable
`TV (CATV) system, employing optical fiber and implement
`ing asynchronous transfer mode (ATM) transmission proto
`cols. At the set-top-box 204, on a remote end of the
`distribution infrastructure 224, a transport Stream demulti
`plexer 230 receives the multiplexed transport stream. Based
`on the packet identification number of a particular packet,
`the transport stream demultiplexer 230 separates the
`encoded audio and Video packets and provides the Video
`packets to a video decoder 232 via link 238 and the audio
`packets to an audio decoder 236 via link 240.
`0011. The transport stream demultiplexer 230 also pro
`vides timing information to a clock control unit 236. The
`clock control unit 236 provides timing outputs to the both
`the video decoder 232 and the audio decoder 236 based on
`the timing information provided by the transport Stream
`demultiplexer 230 (e.g., based on the values of PCR fields).
`The video decoder 232 provides video data which corre
`sponds to the Video data originally provided to the Video
`encoder 206. Similarly, the audio decoder 236 provides
`audio data which corresponds to the audio data originally
`provided to the audio encoder 216.
`0012 PRIOR ART FIG.3 shows a simplified functional
`block diagram of a VOD system 300. At the heart of the
`VOD system 300 is the video server 310 which routes the
`digital movies, resident in the movie Storage System 312, to
`the distribution infrastructure 314. This distribution infra
`Structure 314 may be, for example, a telephone network
`and/or a cable TV (CATV) system, employing optical fiber
`and implementing asynchronous transfer mode (ATM)
`transmission protocols. The distribution infrastructure 314
`deliverS movies to individual homes based on the routing
`information supplied by the video server 310.
`
`DISH, Exh.1008, p.0017
`
`

`

`US 2002/0049980 A1
`
`Apr. 25, 2002
`
`0013 The VOD system 300 also includes a plurality of
`VOD STBs 304 suitable for processing VOD in the VOD
`system 300. Each STB 304 receives and decodes a digital
`movie and converts it to a signal for display on a TV Set or
`A/V monitor.
`0.014. The typical model for digital broadcast and DOD
`systems described above adheres to what is termed a “bi
`directional client-server model.” In order to point out defects
`inherent to this prior art System, the typical hardware archi
`tecture generic to such a DOD system will be described
`below with reference to FIG. 4. Further, a pair of methods
`for controlling the prior art DOD server and the prior art
`DOD client will be described below with reference to FIG.
`5 and FIG. 6, respectively.
`0015 PRIOR ART FIG. 4 illustrates a general diagram of
`a DOD system 320 having a bi-directional client-server
`architecture. The DOD system 322 includes a DOD server
`322 bi-directionally coupled with a plurality of DOD clients
`324 via communication link326. As will be appreciated, the
`VOD system 300 of FIG. 3 is a somewhat specific example
`of the DOD system 320.
`0016 Broadly speaking, the DOD system 320 operation
`adheres to the well known client-server model as follows. In
`Some manner, typically through transmission of an Elec
`tronic Program Guide (EPG) by the DOD server 322, the
`clients 324 are informed of available on-demand data. Using
`the EPG for reference, a requesting DOD client 324 requests
`specific data from the DOD server 322 via the communica
`tion link 326. The DOD server 322 interprets the client
`request, and then prepares the client Specific data in a format
`suitable for use by the requesting client 324.
`0.017. Once the client specific data is prepared, the server
`322 transmits the client Specific data to the requesting client
`324. The requesting client 324 receives, via a specifically
`allocated portion of the communication link 326, the
`requested client specific data in a readably usable format.
`The requested client Specific data is provided in a format
`ready for presentation by the DOD client to the end user.
`These client-Server processes are described below in more
`detail with reference to FIGS. 5-6.
`0018) Under the client-server model of FIG. 4, the avail
`able bandwidth of communication link 326 must be divided
`up into allocated portions 328, each allocated portion being
`dedicated to a particular client. Hence the bandwidth
`required for prior art DOD systems is directly proportional
`to the number of clients being Served.
`0.019 Although communication link 326 may be a true
`bi-directional communications medium, Such infrastructure
`is uncommon. Instead, typical implementations today
`cobble together existing infrastructure Such as fiber optic
`cabling and telephone lines to implement the necessary
`bi-directional communications. For example, the fiber optic
`cable may be used for Server transmission of client specific
`data while an existing telephone line may be used for client
`transmission of requests.
`0020 Turning next to PRIOR ART FIG. 5, a bi-direc
`tional DOD server method 340 in accordance with the prior
`art will now be described. In a first step 342, the DOD server
`identifies the available slots within the available transmis
`sion bandwidth. In a next step 344 the DOD server prepares
`and transmits a Suitable EPG to each client. It will be
`
`appreciated that different EPGs may be transmitted for
`different clients depending upon factorS Such as Subscription
`levels, available Services, personalized Settings, payment
`history, etc. In any event, in a next step 346, the DOD server
`receives a demand for Specific data from a specific client.
`The demand includes information indicating the identity of
`the client. Then in a step 348, the DOD server identifies the
`Specific client from information included with the demand.
`0021. At a step 350, a determination is made whether the
`client is authorized to receive the requested data. This
`determination is made at the DOD server 322 (FIG. 4),
`where each DOD Service has an assigned Subscription level
`requirement. The DOD server compares a client's subscrip
`tion level Stored in the clients data file to the requested
`Service's Subscription level requirement. This determination
`generally requires many complex independent operations,
`and is described here in only in a very simplified manner.
`0022. If the client's Subscription level corresponds with
`the Subscription level of the requested data, then the client
`is authorized to receive the data. If the client is authorized
`to receive the data requested, the process proceeds to Step
`351. In step 351, the DOD server assigns an available slot to
`the authentic client. In step 352, the DOD server prepares the
`requested client specific data for transmission in a format
`suitable for the requesting client. Step 348 may include such
`actions as retrieving the client Specific data from a persistent
`Storage mechanism and preparing an appropriate channel
`server for data transmission. Continuing with a step 354, the
`DOD server transmits the client specific data via the band
`width allocated to the requesting client.
`0023) If the client is not authorized to receive the
`requested data, the proceSS proceeds to Step 356, where the
`DOD Server transmits a generic message Stating that the
`Service is unavailable. Other appropriate data may also be
`transmitted.
`0024 Turning next to FIG. 6, a client method 360 for
`retrieving on-demand data will now be described. In a tuning
`step 362, the DOD client will tune into the appropriate
`channel program and in a receiving step 364 the DOD client
`will receive the EPG transmitted by the DOD server. In a
`next step 366, the DOD client provides the EPG information
`to a DOD user and in a step 368, receives a request for
`specific data from the DOD user. Then in a step 370, the
`DOD client demands that the DOD server provide the
`requested client Specific data. In a step 372, in anticipation
`of the requested client specific data, the DOD client tunes
`into the allocated bandwidth. Then in a step 374, the DOD
`client receives via allocated bandwidth the requested client
`Specific data in a readably usable format and provides it to
`the DOD user.
`0025. As the above discussion reflects, none of the prior
`art Systems provide a method for easily controlling a client's
`access to DOD services without bi-directional communica
`tion. Therefore, it is desirable to provide a method for
`preventing delinquent clients from accessing data from a
`DOD system without relying on bi-directional communica
`tion. Furthermore, it is desirable to provide a method for
`altering a DOD clients subscription level without bi-direc
`tional communication or altering the clients STB. What is
`also needed is a method for communicating a client's DOD
`account Status to a client using unidirectional communica
`tions.
`
`DISH, Exh.1008, p.0018
`
`

`

`US 2002/0049980 A1
`
`Apr. 25, 2002
`
`SUMMARY
`0026. The present invention teaches methods and sys
`tems for preventing delinquent clients from accessing data
`from a DOD system without relying on bi-directional com
`munication. The present invention also teaches methods and
`systems for altering a DOD clients subscription level with
`out bi-directional communication or altering the clients
`STB. Additionally, the present invention teaches methods
`and Systems for communicating a client's DOD account
`Status to a client using unidirectional communications.
`These include a universal digital data System, a universal
`STB, and a variety of methods for handling these digital
`services and controlling the universal STB.
`0.027 A first embodiment of the present invention teaches
`a method for controlling client access to DOD Services using
`only unidirectional communication, comprising the acts of:
`receiving at least one Subscription data packet including at
`least one associated client identification code, at least one
`asSociated Subscription level code, and at least one associ
`ated Service level code; and Storing at least a portion of the
`at least one associated Subscription level code in a memory
`location; Storing at least a portion of the at least one
`asSociated Service level code in a memory location; receiv
`ing at least one first Service having at least one associated
`Subscription level; and wherein the at least one associated
`Subscription level code corresponds to the at least one
`asSociated Subscription level, accessing at least a portion of
`the first service. The method further includes: receiving at
`least one Second Service having at least one associated
`Service level; and wherein the at least one associated Service
`level code corresponds to the at least one associated Service
`level, accessing at least a portion of the Second Service.
`Wherein the Subscription data packet includes at least one
`asSociated warning level code, displaying a warning mes
`Sage associated with the warning level code.
`0028. It is important to remark that as types of set-top
`boxes become more ubiquitous, they are often built-in to a
`unit, Such as a TV or computer, rather than actually Set on
`top or beside. One of ordinary skill in the art would
`recognize that all references to STBS would apply equally to
`built-in version, and thus the two become Synonymous.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0029 PRIOR ART FIG. 1 illustrates pictorially the pack
`etizing of compressed Video data into a Stream of packets
`and a stream of transport packets,
`0030 PRIOR ART FIG. 2 illustrates by block diagram a
`system according to the MPEG-2 standard;
`0031 PRIOR ART FIG. 3 illustrates a simplified func
`tional block diagram of a VOD system;
`0032. PRIOR ART FIG. 4 illustrates a DOD system
`adhering to a prior art bi-directional client-server architec
`ture,
`0033 PRIOR ART FIG. 5 illustrates a DOD server
`method for controlling the receipt of DOD services by
`clients using a bi-directional, client specific data transmis
`Sion mechanism;
`0034 PRIOR ART FIG. 6 illustrates a DOD client
`method for receiving and processing client Specific data via
`a bi-directional transmission mechanism;
`
`0035 FIG. 7 is a block diagram of a digital broadcast
`Server in accordance with one embodiment of the present
`invention;
`0036 FIG. 8 is a block diagram showing the hardware
`architecture of a universal STB in accordance with yet
`another embodiment of the present invention;
`0037 FIG. 9 is a schematic block diagram illustrating a
`Subscription level data block in accordance with one
`embodiment of the present invention;
`0038 FIG. 10 is a flow chart illustrating a computer
`implemented method for controlling the Subscription level
`of an STB in accordance with the present invention;
`0039 FIG. 11 is a flow chart illustrating a computer
`executable method for accessing selected DOD services
`having an associated Subscription level in accordance with
`the present invention;
`0040 FIG. 12A is schematic block diagram illustrating a
`Subscription level data block in accordance with one
`embodiment of the present invention;
`0041
`FIG. 12B is schematic block diagram illustrating a
`Subscription level data block in accordance with an alterna
`tive embodiment of the present invention;
`0042 FIG. 12C is schematic block diagram illustrating a
`Subscription level data block in accordance with another
`alternative embodiment of the present invention;
`0043 FIG. 13A is schematic block diagram illustrating a
`service level data block in accordance with one embodiment
`of the present invention;
`0044 FIG. 13B is schematic block diagram illustrating a
`Service level data block in accordance with an alternative
`embodiment of the present invention;
`004.5
`FIG. 14 is a flow chart illustrating a computer
`executable method for accessing selected DOD services
`having an associated Service level in accordance with the
`present invention;
`0046 FIG. 15 is schematic block diagram illustrating a
`warning level data block in accordance with one embodi
`ment of the present invention; and
`0047 FIG. 16 is a flow chart illustrating a computer
`implemented method for displaying a warning message in
`accordance with the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`0048. In the following detailed description of the embodi
`ments, reference is made to the drawings that accompany
`and that are a part of the embodiments. The drawings show,
`by way of illustration, specific embodiments in which the
`invention may be practiced. Those embodiments are
`described in Sufficient detail to enable those skilled in the art
`to practice the invention and it is to be understood that other
`embodiments may be utilized and that Structural, logical,
`and electrical changes as well as other modifications may be
`made without departing from the Spirit and Scope of the
`present invention.
`0049. The present invention teaches methods and sys
`tems for preventing delinquent clients from Viewing data
`
`DISH, Exh.1008, p.0019
`
`

`

`US 2002/0049980 A1
`
`Apr. 25, 2002
`
`from a unidirectional DOD System by displaying a warning
`message over displayed DOD data. The present invention
`also teaches methods and Systems for altering a DOD clients
`Subscription level without bi-directional communication or
`altering the clients STB. A client's subscription level indi
`cates the number of DOD services a client has access to.
`Generally the client must pay a higher monthly fee for a
`higher Subscription level, which would allow access to more
`DOD services. Additionally, the present invention teaches
`methods and Systems for communicating a client's DOD
`account Status to a client using uni-directional communica
`tions. These include a universal digital data System, a
`universal STB, and a variety of methods for handling these
`digital services and controlling the universal STB. However,
`those skilled in the art will recognize that all aspects of the
`present invention can be implemented within the bi-direc
`tional communication paradigm, the only difference being
`that even more features can be provided to the digital
`broadcast and DOD user when a bi-directional communica
`tion link is available.
`0050 FIG. 7 illustrates the architecture for a DOD server
`450 in accordance with one embodiment of the present
`invention. The DOD server 450 includes a plurality of
`channel Servers 411, a plurality of up converters 412 each
`corresponding to a channel Server 411, a combiner amplifier
`414, a central controlling Server 502, and a central Storage
`504, coupled as illustrated through a data bus 506. As will
`be described below, the central controlling server 502 con
`trols off-line operation of the channel servers 411, as well as
`initiating real-time transmission once the channel servers
`411 are ready. The central storage 504 typically stores data
`files in a digital format. However, any Suitable mass persis
`tent data Storage device may be used.
`0051. In an exemplary embodiment, data files stored in
`the central storage 504 are accessible via a standard network
`interface (e.g., Ethernet connection) by any authorized com
`puter, Such as the central controlling Server 502, connected
`to the network. The channel servers 411 provide data files
`that are retrieved from the central storage 504 in accordance
`with instructions from the central controlling server 502.
`The retrieval of digital data and the Scheduling of transmis
`sion of the digital data for DOD is performed “off-line” to
`fully prepare each channel Server 411 for real-time data
`transmission. Each channel Server 411 informs the central
`controlling server 502 when ready to provide DOD, at which
`point the central controlling server 502 can control the
`channel servers 411 to begin DOD transmission.
`0.052
`In a preferred embodiment, the central controlling
`Server 502 includes a graphics user interface (not shown) to
`enable a Service provider to Schedule data delivery by a
`drag-and-drop operation. Further, the central controlling
`server 502 authenticates and controls the channel servers
`410 to start or Stop according to delivery matrices. Systems
`and methods for providing uni-directional DOD broadcast
`matrices are taught in Khoi Hoang's patent application
`entitled SYSTEMS AND METHODS FOR PROVIDING
`VIDEO ON DEMAND SERVICES FOR BROADCAST
`ING SYSTEMS filed on May 31, 2000, bearing application
`Ser. No. 09/584,832, which is incorporated herein by refer
`CCC.
`Each channel server 411 is assigned to a channel
`0.053
`and is coupled to an up-converter 412. The output of each
`
`channel Server 411 is a quadrature amplitude modulation
`(QAM) modulated intermediate frequency (IF) signal hav
`ing a Suitable frequency for the corresponding up-converter
`412. The QAM-modulated IF signals are dependent upon
`adopted Standards. The current adopted Standard in the
`United States is the data-Over-cable-systems-interface
`specification (DOCSIS) standard, which requires an
`approximately 43.75 MHz IF frequency. A preferred channel
`server 411 is described below in more detail with reference
`to FIG. 10.
`0054 The up-converters 412 convert IF signals received
`from the channel servers 104 to radio frequency signals (RF
`Signals). The RF signals, which include frequency and
`bandwidth, are dependent on a desired channel and adopted
`Standards. For example, under the current Standard in the
`United States for a cable television channel 80, the RF signal
`has a frequency of approximately 559.25 MHz and a band
`width of approximately 6 MHz.
`0055. The outputs of the up-converters 412 are applied to
`the combiner/amplifier 414. The combiner/amplifier 414
`amplifies, conditions and combines the received RF signals
`then outputs the Signals out to a transmission medium.
`0056 FIG. 8 illustrates a universal STB 600 in accor
`dance with one embodiment of the invention. The STB 600
`comprises a QAM demodulator 602, a CPU 604, a local
`memory 608, a buffer memory 610, a decoder 612 having
`Video and audio decoding capabilities, a graphics overlay
`module 614, a user interface 618, a communications link
`620, and a fast data buS 622 coupling these devices as
`illustrated. The CPU 602 controls overall operation of the
`universal STB 600 in order to select data in response to a
`client's request, decode Selected data, decompress decoded
`data, re-assemble decoded data, Store decoded data in the
`local memory 608 or the buffer memory 610, and deliver
`stored data to the decoder 612. In an exemplary embodi
`ment, the local memory 608 comprises both non-volatile
`memory (e.g., a hard drive) and Secure memory (e.g., a
`ROM chip), and the buffer memory 610 comprises volatile
`memory. A hardware identification code (not shown) is
`stored in a secure memory location of the local memory 608,
`this code is unique to the STB 600 and cannot be readily
`altered. An STB subscription level code is stored in a
`non-volatile memory location of the local memory 608, and
`is needed to access DOD programs.
`0057. In one embodiment, the QAM demodulator 602
`comprises transmitter and