(12) United States Patent
`US 7,159,233 B2
`(10) Patent N0.:
`Son et al.
`
`(45) Date of Patent:
`Jan. 2, 2007
`
`USOO7159233B2
`
`(54)
`
`75)
`
`METIIOD AND APPARATUS FOR
`PREPROCESSING AND POSTPROCESSING
`CONTENT IN AN INTERACTIVE
`INFORMATION DISTRIBUTION SYSTEM
`
`Inventors: Yong Ho Son, Palo Alto, CA (US);
`Christopher W. B. Goode. Menlo Park,
`CA (US)
`
`
`
`73)
`
`Assignee: Sedna Patent Services, LLC,
`Philadelphia, PA (US)
`
`*)
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 998 days.
`
`21)
`
`Appl. N0.: 09/772,288
`
`22)
`
`65)
`
`Filed:
`
`Jan. 29, 2001
`
`Prior Publication Data
`
`US 2002/0047899 A1
`
`Apr. 25, 2002
`
`Related U.S. Application Data
`
`(60)
`
`(51)
`
`(52)
`
`(58)
`
`(56)
`
`Provisional application No. 60/178,795, filed on Jan.
`28, 2000, provisional application No. 60/ 178,809,
`filed on Jan. 28, 2000, provisional application No.
`60/178,810, filed on Jan. 28, 2000, provisional appli-
`cation No. 60/178,857, filed on Jan. 28, 2000.
`
`Int. Cl.
`(2006.01)
`H04N 7/173
`(2006.01)
`G06F 15/16
`U.S. Cl.
`............................ 725/86; 725/88; 725/91;
`725/98; 709/218; 709/219; 709/231
`Field of Classification Search .................. 725/86,
`725/87, 88, 91, 98; 709/218, 219, 231
`See application file for complete search history.
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`1/1999 Thompson ..
`5,856,973 A
`4/1999 Wahl
`.................
`5,898,456 A *
`6/2000 Eleftheriadis et a1.
`6,079,566 A
`4/2003 Mimura et a1.
`6,557,031 B1*
`6,647,411 B1* 11/2003 "owell et a1.
`2001/0013068 A1*
`8/2001 Klemets et al.
`
`
`
`370/389
`725/91
`207/101
`709/218
`.. 709/213
`709/231
`
`FOREIGN PATENT DOCUMENTS
`
`W0
`W0
`
`WO 98/51080 A
`WO 99/21363 A
`
`11/1998
`4/1999
`
`OTHER PUBLlCAl'lON S
`
`U.S. Appl. No. 08/984,710, filed Dec. 3. 1997, entitled: System for
`Interactively Distributing Information Services.
`C.S.App1.No. 09/772,287, filed Jan. 29, 2001, entitled: Method and
`Apparatus for Content Distribution Via Non-Homogeneous Access
`Networks.
`Boniseh H et al: “Server side compresslets for Internet multimedia
`streams” Multimedia Computing and Systems, 1999, IEEE Inter-
`national Conference on Florence,
`Italy Jun. 7-11, 1999, Los
`Alamitos, CA, USA, IEEE Comput. Soc. US, v01. 2, Jun. 7, 1999
`(Jun. 7. 1999), pp. 82-86, XP010519360 ISBN: 0-7695-0253-9.
`
`* cited by examiner
`
`Primary Examiner%hris Kelley
`Assistant Examineriloseph G. Ustaris
`(74) Attorney, Agent, or FirmiPatterson & Sheridan, LLP
`
`(57)
`
`ABSTRACT
`
`A method and apparatus for preprocessing and preprocess-
`ing content in an interactive information distribution system.
`Content is retrieved from a storage medium and encapsu-
`lated in accordance to an Internet Protocol (IP) format. The
`encapsulated content is then uploaded for storage in a stream
`caching server and for future streaming of content to dif—
`ferent types of access networks.
`
`5,838,678 A
`
`11/1998 Davis et a1.
`
`................ 370/389
`
`27 Claims, 6 Drawing Sheets
`
`133
`(
`mmawsun 5-ercu»m
`mmmuam 5mm
` MANAGE" ‘140
`
`saws:
`
`new
`
`
` swrren
`
`"Emu”
`Luau
`146 /_\ swam:
`
`PROCESSOR ‘144
`
`
`
`
`
`
`142
`mm: HEADEND
`155
`swam DISIRIEUTION
`m\
`
`WWW...
`NEMUNK
`“mam.
`(
`
`
`
`
`) Esta,“
`
`
`M
`»
`150
`I__
`I
`
`
`mp5mm
`
`
`
`
`
`
`)9 magma magma 8113.:
`
`
`‘05 m% 105
`
`
`
`Mm” ”\114
`“W ”\119
`mamas“
`
`
`
`
`
`
`)
`
`
`116
`I
`COMPUTERTENMINAL
`
`XDSLManEM «120
`mmm m
`
`
`/
`I
`I
`-’\1551
`134
`132
`123
`w «154
`I
`I
`
`
`
`CIRCUIIS sronei
`summon
`
`I
`
`
`
`
`
`messmr‘“
`12mm )
`1‘;th mm M
`
`122
`124
`MEDlLlM
`
`152
`156
`
`133
`
`
`
`{
`
`
`
`
`
`
`DISH Ex-1006, p. 1
`DISH Ex-1006, p. 1
`DISH v. BBiTV
`DISH V. BBiTV
`IPR2020-01267
`IPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US. Patent
`
`Jan. 2, 2007
`
`Sheet 1 0f 6
`
`US 7,159,233 B2
`
`
`
`LOCAL HEAD END
`
`138
`
`SERVER
`
`
`
`STORAGE
`
`146
`
`164
`
`REMOTE HEADEND
`
`
`
`156
`
`
`
`CACHING SERVER
`
`d
`l-I 162
`160
`
`
`
`WWW
`LAYER 3
`PACKET
`SWITCH
`PROCESSOR
`
`
`
`104
`
`STREAM DISTRIBUTION
`NETWORK
`
`144
`
`126
`
`148
`
`DATA LINK
`CONVERTER
`
`1 12
`
`DATA LINK
`CONVERTER
`
`1 18
`
`DATA LINK
`CONVERTER
`
`135
`
`SERVER
`
`116
`
`106
`
`CARRIER
`NETWORK
`
`108
`
`CABLE
`NETWORK
`
`ROUTER
`
`110
`
`113
`
`1 14
`
`DSLAM
`
`1 19
`
`COMPUTER TERMINAL
`
`120
`
` 128
`
`El
`
`PROCESSOR
`
`STORAGE
`MEDIUM
`
`154
`158
`150
`
`SUPPORT
`
`CIRCUITS
`
`COMPUTER
`TERMINAL
`
`SETTOP
`TERMINAL
`
`122
`
`12
`
`4
`
`152
`
`156
`
`FIG. 1
`
`132
`
`134
`
`COMPUTER
`TERMINAL
`
`DVR
`
`DISH Ex-1006, p. 2
`DISH Ex-1006, p. 2
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`IPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US. Patent
`
`Jan. 2, 2007
`
`Sheet 2 0f 6
`
`US 7,159,233 B2
`
`200
`
`/
`
`IP HEADER
`
`
`
`IP PAYLOAD
`
`210
`
`T
`220
`
`UDP PACKET
`
`STREAM CHECK
`
`CRC
`
`221
`
`226
`
`228
`
`UDP HEADER
`
`
`
`UDP PAYLOAD
`
`222
`
`224
`
`RTP PACKET
`
`230
`
`FIG. 2A
`
`RTP HEADER
`
`
`
`RTP PAYLOAD
`
`240
`
`250
`
`
`
`MPEG-2 MPEG-2 MPEG-2 MPEG-2 MPEG-2
`
`PACKET
`
`PACKET
`
`PACKET
`
`PACKET
`
`PACKET
`
`252
`
`254
`
`256
`
`258
`
`260
`
`FIG. 28
`
`230
`
`’/
`
`
`
`DISH Ex-1006, p. 3
`DISH Ex-1006, p. 3
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`lPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US. Patent
`
`Jan. 2, 2007
`
`Sheet 3 0f 6
`
`US 7,159,233 B2
`
`
`
`STREAMCONTENT
`
`I--fi:
`
`III-IIIVAVA
`-I%V///4
`
`
`
`310
`
`320
`
`FIG.3
`
`
`
`SUBSTREAMCONTENT
`
`DISH Ex-1006, p. 4
`DISH Ex-1006, p. 4
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`lPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US. Patent
`
`Jan. 2, 2007
`
`Sheet 4 0f 6
`
`US 7,159,233 B2
`
`404
`
`EXECUTE APPLET TO INITIATE
`PREPROCESSING
`
`START
`
`402
`
`400
`
`408
`
`410
`
`416
`
`418
`
`420
`
`422
`
`406
`
`
`USER
`
`PURCHASED
`
`
`SHELF SPARE ?
`
`
`
`
`NO
`
`YES
`
`LOAD CONTENT FROM
`SUBSCRIBER TERMINAL
`
`CREATE METADATA FOR LOADED
`CONTENT
`
`414
`
`412
`
`
`TRANSCODE
`
`
` TRANSCODE CONTENT
`CONTENT ?
`
`
`INTO FORMAT FOR
`TARGET VIEWER
`
`
`
`ENCAPSULATE TRANSCODED
`
`CONTENT INTO IP PACKETS FOR STREAM CACHING SERVER
`
`UPLOAD CONTENT AND
`METADATA TO CACHE SERVER
`
`SET PERMISSION TO RESTRICT
`ACCESS TO STORED CONTENT
`
`FIG. 4
`
`CREATE HTML PAGE FOR
`ACCESSING CONTENT
`
`END
`
`424
`
`DISH Ex-1006, p. 5
`DISH Ex-1006, p. 5
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`lPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US. Patent
`
`Jan. 2,2007
`
`Sheet 5 of6
`
`US 7,159,233 B2
`
`USER SELECTS TO ACCESS
`
`HTML PAGE
`
`STORED CONTENT AT
`
`506
`
`
` CURRENT
`PASSWORD
`
`
`EMCODED?
`
`
`
`NO
`
`500
`
`504
`
`510
`
` DETECTED?
`
`
`
`DOWNLOAD PLAYER TO
`VIEW CONTENT
`
`512
`
`
`
`PLAYER
`
`
`NO
`SUPPORT FULL
`
`
`
`QUALITY
`
`PLAYBACK?
`
`
`
`514
`
`YES
`
`
`
`PAY FOR
`FULL QUALITY
`
`
`CONTENT?
`
`
`
`FIG. 5A
`
`DISH Ex-1006, p. 6
`DISH Ex-1006, p. 6
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`lPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US. Patent
`
`Jan. 2, 2007
`
`Sheet 6 0f 6
`
`US 7,159,233 B2
`
`RETRIEVE FULL
`IP FORMATTED
`
`CONTENT FROM
`
`SERVER SERVER
`
`IP STREAM
`
`516
`
`526
`
`RETRIEVE PORTION
`OF IP FORMATTED
`CONTENT FROM
`
`STREAM CONTENT
`OVER DISTRIBUTION
`NETWORK
`
`518
`
`528
`
`STREAM CONTENT
`OVER DISTRIBUTION
`NETWORK
`
`EXTRACT CONTENT
`FROM IP STREAM
`
`520
`
`530
`
`EXTRACT PORTION
`OF CONTENT FROM
`
`522
`
`532
`
`
`
`YES
`
`YES
`
`
`
`
`
`
`TRANSCODE
`
`
`TRANSCODE
`FOR ACCESS
`FOR ACCESS
`NETWORK AND
`NETWORK AND
`
`
`VIEWER?
`VIEWER?
` TRANSCODE
`
`TRANSCODE
`
`NO
`CONTENT AT
`CONTENT AT
`
`NORMAL
`LOW
`
`QUALITY
`
`
`QUALITY
`
`
`
`STREAM CONTENT OVER
`
`536
`
`ACCESS NETWORK
`
`500
`
`DISPLAY CONTENT ON
`VIEWER
`
`538
`
`0
`
`FIG. 53
`
`@540
`
`DISH Ex-1006, p. 7
`DISH Ex-1006, p. 7
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`lPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US 7,159,233 B2
`
`1
`METHOD AND APPARATUS FOR
`PREPROCESSING AND POSTPROCESSING
`CONTENT IN AN INTERACTIVE
`INFORMATION DISTRIBUTION SYSTEM
`
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`
`
`This invention claims benefit of U.S. Provisional Patent
`Apolication Ser. Nos. 60/178,795, 60/178,809, 60/178,810
`anc 60/178,857, all filed on Jan. 28, 2000, and such appli-
`cations are herein incorporated by reference in their entire-
`ties.
`
`This invention is related to simultaneously filed US.
`patent application Ser. No, 09/772,287, filed on the same
`date as this application, and such applications herein incor-
`porated by reference in entirety.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`The invention relates to electronic storage and transmis-
`sion of content. More particularly, the invention relates to a
`method and apparatus for preprocessing and postprocessing
`content in an interactive information distribution system.
`2. Description of the Background Art
`hifonnation systems such as video on demand (VOD)
`systems are capable of streaming program content to a great
`number of users or subscribers. To provide a requested
`program content to a subscriber, the VOD system retrieves
`the requested program content from a video server, streams
`the content over a stream distribution network, and converts
`the content
`to an access network that
`is coupled to a
`particular neighborhood of subscriber terminals. The user
`then views the requested program content at the subscriber
`terminal.
`
`10
`
`L4.) in
`
`40
`
`the different types of access networks have
`However,
`different limitations with respect to transmission latency,
`bandwidth, and the like. To service a wide subscriber base,
`the VOL) systems currently implement different solutions for
`each type of access network. For example, VOD systems
`that provide web-based video content must account for a
`public and private wide area networks that support content
`of a particular quality of service (QoS), typically medium
`latency, low bandwidth and poor quality video, e.g. high
`jitter. Additionally, VOD systems that provide cable—based
`video must account for cable networks that support
`low
`latency, high bandwidth and high quality video.
`One example of using different solutions involves the use _
`of separate video servers for each type of access network.
`Such a solution only increases the cost of providing program
`content at the head end. Therefore, there is a need in the art
`to provide a scalable VOD solution that is common for the
`different types of access networks. Additionally, there is a
`need to preprocess and postprocess content for such a VOD
`solution.
`
`SUMMARY OF THE INVENTION
`
`
`
`The invention provides a met 10d and system for prepro-
`cessing content for a stream caching server in an interactive
`information distribution system. In one embodiment, the
`method initially retrieves of content in a subscriber terminal.
`The retrieved content is encapsulated in accordance to an
`Internet Protocol (IP) format used for streaming content to
`various access networks. The encapsulated content is then
`
`60
`
`2
`uploaded for storage in a stream caching server and for
`future streaming of content
`to different
`types of access
`networks.
`The present invention preprocesses content into a com—
`mon format suitable for a stream caching server capable of
`transmitting content to different types of access networks. In
`one embodiment of the invention, a user executes an applet
`program to preprocess content stored in a computer termi-
`nal. Such a configuration enables a user to upload content
`over the Internet for storage in a stream caching server and
`subsequent streaming to other subscribers. The invention
`also postprocesses content into a format supported by a
`particular type of player and access network used to receive
`the content from the stream caching server.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The teachings of the present invention can be readily
`understood by considering the following detailed descrip-
`tion in conjunction with the accompanying drawings,
`in
`which:
`FIG. 1 depicts a high level block diagram of a first portion
`of an interactive information distribution system embodied
`in the present invention;
`FIG. 2A depicts one embodiment of an Intemet Protocol
`(IP) packet used in the information distribution system of
`FIG. 1;
`FIG. 2B depicts one embodiment of a Realtime Transport
`Packet (RTP) contained in a payload section of the IP packet
`of FIG. 2A;
`FIG. 3 depicts a data structure useful in understanding an
`embodiment of the present invention;
`FIG. 4 depicts a flow diagram of a method for imple-
`menting the preprocessing of program content in accordance
`to one embodiment of the present invention; and
`FIG. 5 depicts a flow diagram of a method for and
`postprocessing content in accordance to another embodi—
`ment of the present invention.
`To facilitate understanding, identical reference numerals
`have been used, where possible,
`to designate identical
`elements that are common to the figures.
`
`DETAILED DESCRIPTION
`
`FIG. 1 depicts a high level block diagram of an interactive
`information distribution system 100. One application of the
`distribution system 100 is as a video of demand (VOD)
`system, as described in US. Pat. No. 6,253,375 and incor-
`porated herein by reference. In such a VOD system 100, a
`user may request and receive a particular content selection,
`e.g., video, movie or programming content, from a service
`provider without any time restrictions associated with nor-
`mal cable programming.
`The information distribution system 100 comprises a
`stream caching server 102, a stream distribution network
`104, at least one access network and at least one subscriber
`terminal. The stream caching server 102 receives, stores and
`streams content in accordance to an Internet Protocol (IP).
`One example of such a stream caching server 102 is dis-
`closed in simultaneously filed US. application Ser. No.
`09/772,287, entitled “Method and Apparatus for Streaming
`Content in an Interactive Infonnation Distribution System,
`which is herein incorporated by reference. The content is
`configured within a payload portion of each IP packet
`received, stored and streamed by the stream caching server
`102. The use of this P formatted content enables a single
`stream caching server 102 to stream content via an inte-
`
`DISH Ex-1006, p. 8
`DISH Ex-1006, p. 8
`DISH v. BBiTV
`DISH V. BBiTV
`IPR2020-01267
`IPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US 7,159,233 B2
`
`3
`grated stream distribution network 104 to different types of
`access networks. As such,
`the system 100 is capable of
`streaming the same content to any cable service subscriber
`or any person using the Internet.
`In accordance to the present invention, the stream caching
`server 102 may receive content that is preprocessed at, for
`example, a remotely located subscriber temiinal. One such
`subscriber terminal is a computer terminal 116 comprising a
`processor 150, a storage medium 152, a random access
`memory (RAM) 154 and support circuits 156. The RAM
`154 stores an applet 154 that
`is downloaded from,
`for
`example, a HTTP server 148 coupled to an access network,
`for example, a private local area network @AN) or wide
`area network (WAN) 106. The processor 150 executes the
`applet 154 to initiate the preprocessing in the present inven—
`tion. The storage medium 152 stores the content to be
`preprocessed. The support circuits 156 provide an interface
`for receiving the applet 154 from the http server 148,
`receiving content from the streaming cache server 102, or
`uploading preprocessed content to the http server 148.
`Possible configurations of the applet 154 include a JAVA
`Applet Plug In for an lntemet browser, or a software
`program written in a particular programming language, e.g.,
`C++. Once the processor 150 executes the applet 154, the
`content
`is retrieved from the storage medium 152. The
`content may include standard multimedia files in a variety of
`formats, e.g., AVI (Audio Vldeo Interleaved), Moving JPEG,
`
`MPEG-1, MPEG-2, MPEG-4, MP3, Quicktime, and the
`like. Ifa need exists to convert the content into a particular
`format,
`the retrieved content may be transcoded into a
`format supported by a viewer or subscriber terminal that
`eventually receives the downstream content. The transcod—
`ing of content changes the format and rate of the retrieved
`content. One example of such transcoding is the conversion
`
`of MPEG—2 content into MPEG—4 content that can be played
`on a graphic processor in set
`top terminals or personal
`computer (PC) terminals. Other types of content may be
`transcoded into MPEG-2 content playable on conventional
`set top terminals. Some transcoding requires decoding to
`baseband followed by encoding according to the desired
`format. Some transcoding may be performed without base-
`band decoding.
`The contcnt, whether transcoded or not, is then encapsu-
`lated into a fomiat that is optimal for the stream caching
`server 102. In one embodiment, the content, as MPEG-2
`packets,
`is encapsulated in a payload of each Realtime
`Transfer Protocol (RTP) packet contained in the payload of
`an IP packet. The format of such encapsulated content is
`shown in FIGS. 2A 2B. However, the use of the RTP packet
`also supports non real time applications
`FIG. 2A depicts one embodiment of an lntemet Protocol
`(IP) packet 200 used in the present invention. The IP packet
`comprises an IP header 210 and an IP payload 320. The IP
`payload comprises a UDP (User Datagram Protocol) packet
`221 comprising a UDP header 222 and a UDP payload 224.
`A RTP packet 230, a stream integrity check 226 and a cyclic
`redundancy check (CRC) 228 is illustratively contained in
`the UDP payload 224. In one embodiment of the IP packet
`200, the IP header 210 is 20 bytes, the UDP header 222 is
`8 bytes, the stream integrity check field 226 is 4 bytes and
`the CRC field 228 is 4 bytes.
`FIG. 2B depicts one embodiment of a Realtime Transport
`Packet (RTP) 230 contained in a payload section 220 of the
`IP packet 300 of FIG. 2A. The RTP packet 230 comprises a
`RTP header 240 and a RTP payload 250. Five MPEG-2
`packets 352, 354, 356, 358 and 360 are illustratively con—
`tained in each RTP payload 250. The number of MPEG-2
`
`10
`
`30
`
`L4.) m
`
`40
`
`60
`
`4
`packets in the RP'I' payload 250 corresponds to the buffer
`space in the Fibre Channel controller in the packet processor
`144.
`the
`shown in FIGS. 2A 2B,
`the embodiment
`For
`transcoding may also include compression of the IP header
`310, the UDP header 322 and the RTP header 340. The
`compression of these headers 310, 322 and 340 optimizes
`the storage of content on the storage medium 146 of the
`stream caching server 102. Additionally, the transcoding
`may include encryption of the content.
`Compression of the IP header 310 may include compres-
`sion of non-address fields, and deletion of source and
`destination IP addresses. The IP source address is subse-
`quently decompressed (at the packet processor 144) as the IP
`address at the output interface of the stream caching server
`102. The IP destination address is assigned prior to stream-
`ing and is based upon the data link converter 112, 118 or 126
`or edge device for the target access network 106, 108 or 110.
`The compression of the UDP header 322 may delete
`source and destination port numbers in the storage medium
`146. New values are then assigned to the source and
`destination port numbers prior to streaming of content over
`the stream distribution network 104. The source port number
`is assigned a unique stream number with IP addresses. The
`destination port number is assigned a unique target stream
`number within the data link converter 112, 118 or 126 or the
`target edge device.
`Once encapsulated into the IP format, the content is their
`uploaded to the http server 148 via the modem 114 and the
`LAN/WAN 106. The HTTP server 148 provides a user
`interface, e. g., a {TML (HyperText Markup Language)
`page, for the user to upload the content to the stream caching
`server 102. The http server 148 also transmits the transcoded
`content upstream to the data link converter 112 via the
`LAN/WAN 106. T18 data link converter 112 modulates the
`encapsulated content for upstream transmission over the
`distribution network 104 for storage in the stream caching
`server 102.
`
`
`
`The preprocessing of the present invention is not limited
`to a computer terminal 116 uploading content over a LAN/
`WAN 106. For example, the encapsulation may also occur in
`the computer terminal 116 prior to uploading to content to
`the http server 148. Additionally, the preprocessing may be
`initiated from a computer terminal 122 or digital video
`recorder 124 over a carrier network 108, e.g., a T-l or T-3
`line. As such, a user of any computer terminal 116 and 122
`may author multimedia content over a network, e.g., In er-
`net, and store the content in a virtual video shelf at the
`stream caching server 102 for playback by other users. The
`preprocessing is also applicable to content from a content
`provider such as a movie manufacturer.
`The preprocessing may also include the creation of ineta—
`data once the processor 150 executes the applet 154, The
`metadata generally contains a variety of information about
`the content to be stored on the stream caching server 102 and
`streamed to a viewer or subscriber terminal. One embodi-
`ment of the metadata is in the form of a data structure that
`is prepended prior to a file associated with the content.
`The metadata may comprise many different
`types of
`information used by the stream caching server 102 in
`steaming the content
`to a viewer device or subscriber
`terminal. One type of metadata that identify the content
`include title, author, screenwriter, actors,
`length of play,
`timing information, play rate, e. g., constant bit rate (CBR) or
`variable bit rate (VBR), genre of content, size of content,
`and the like. Other forms of metadata indicate the type of
`content and the type of player used to play the content.
`
`
`
`DISH Ex-1006, p. 9
`DISH Ex-1006, p. 9
`DISH v. BBiTV
`DISH V. BBiTV
`IPR2020-01267
`IPR2020—01267
`AT&T EXHIBIT 1006
`
`AT&T EXHIBIT 1006
`
`

`

`US 7,159,233 B2
`
`5
`Illustrative types of content include AVI, MPEG—1, MPEG—
`2, MPEG-4, MP3, Quicktime, and Moving JPEG. The
`metadata may also include MPEG7 structure including
`scene descriptions and indices. Exemplary types of player
`devices include MPEG—l player, MPEG—2 player, MPEG—4
`player, Microsoft Media Player, Real Video/Real Audio
`Player, and QuickTime Player.
`The metadata may include pricing information and
`restrictions to view the content from the server 102. A user
`
`5
`
`10
`
`6
`This greatly reduces the hardware cost at the head end 138,
`as the prior art requires a streaming caching server 102 and
`a distribution network 104 for each type of access network
`106, 108 and 110.
`For example, the server 102 may stream content to a
`private Local Area Network (LAN) or Wide Area Network
`(WAN) 106. Specifically, the system 100 may stream con-
`tent through the stream distribution network 104 to a digital
`link converter 112, the LAN or WAN 106, a modem 114 and
`a display device coupled to a computer terminal 116. If a
`user decides to request content from the server 102 or uplink
`content, e.g., a home movie, to the server 102, that request
`or content would travel upstream in a path reverse to that of
`the downstreamed content. The digital link converter 112
`modulates the program content for transmission via the
`private LAN/WAN 106. Additionally, the data link converter
`
`112 extracts a MPEG formatted program content from the
`RIP formatted stream from the stream distribution network
`104 and transcodes the program content into a format that is
`supported by the LAN/WAN 106. One example of the data
`link converter 112 is a DIVA Digital Link (DDL 500) that
`performs quadrature amplitude modulation (QAM) on the
`downstream program content. The LAN or WAN 106 is a
`private network provided by a private party or an Internet
`Service Provider (ISP). The modem 114 demodulates video
`content for viewing on the computer terminal 116.
`The server 102 may also stream content via the stream
`distribution network 104 to a data link converter 118, a
`carrier network 108, a digital subscriber line access multi—
`plexer (DSLAM) 119, an x-DSL modem 120 to either a
`computer terminal 122 or a digital video recorder (DVR)
`124. A request for content or upload of content would travel
`in the reverse path taken by the downstream content. The
`carrier network 108 may include a T-l or T-3 transmission
`link. The data link converter 118 multiplexes the down—
`stream content for transmission via the carrier network 108.
`Additionally, the data link converter 118 may extract MPEG
`packets from the IP formatted stream from the stream
`distribution network 104. The DSLAM 119 demultiplexes
`the downstream content to a particular xDSL modem 120.
`The xDSL modem 120 demodulates the content for viewing
`on a computer terminal 122 or a display device (not shown)
`coupled to the DVR 124. The xDSL modem 120 may
`comprise a ADSL (asynchronous digital subscriber line)
`modem, a VDSL (very high data rate digital subscriber line),
`and the like.
`The server 100 may also stream content (or program
`content selection) via the stream distribution network 104 to
`a data link converter 126, the cable network 110 to either a
`set top terminal 128 or a cable modem that is coupled to a
`computer terminal 130 or a DVR 132. The data link con-
`verter 126 operates in a similar manner to the digital link
`converter 112 except to format the content for transmission
`in the cable network 110. The content is transmitted from the
`cable network 110 to a set top terminal 128 or a cable
`modem 130 that demodulates the program content for view-
`ing on a computer terminal 132 or a display device coupled
`to the DVR 134. A request from a cable subscriber or user
`is processed via the cable network 110, the OOB (out of
`band) router 136 and the modulator 126 that modulates the
`request back to the stream distribution network 104.
`Although the system 100 is illustratively shown to stream
`program content to the LAN/WAN 106, the PS'I'N 108 and
`the cable network 110, the system 100 may also stream
`content to other types of access networks. For example, the
`system 100 may also stream program content to satellite and
`terrestrial networks. Additionally, each system 100 actually
`
`DISH Ex-1006, p. 10
`DISH Ex-1006, p. 10
`DISH v. BBiTV
`DISH v. BBiTV
`IPR2020-01267
`lPR2020—01267
`AT&T EXHIBIT 1006
`
`or service provider may preset the price and access restric-
`tions that are required to view the preprocessed content from
`the server 102. Pricing information include a price to view
`the content, applicable discounts associated with viewing
`the content, and applicable package deals when ordering the
`preprocessed content with other content selections. Access
`restrictions include rating of content, viewing window infor-
`mation and sales window information. The viewing Window
`is a graphical interface that requires a subscriber to enter a
`correct password to receive the content from the server 102.
`The sales window is a graphical interface that requires a
`subscriber to pay for viewing a particular content selection.
`The metadata comprises indexing at IP packet boundaries,
`e.g., Group of Pictures (GOP) boundaries and frame bound—
`aries. This indexing enables the stream caching server 102 in
`responding to an interactive VCR like commands, e.g., fast
`forward (FF), rewind (REW), pause, stop, bookmark, and
`return to place. Specifically, the indexing information sup-
`ports random frame access at a content stream granularity,
`separate FF and REW tracks, random frame access of FF and
`REW tracks, pause/play, bookmarks for each active sub-
`scriber, and DVD scene selection. Additionally, the metadata
`may also include markers for changes in variable bit rate
`(VBR) and statistical multiplexing.
`The indexng enables the use of MPEG-7 based descrip-
`tors for indexed access of content. The indexing of content
`can be on a per frame basis or a per GOP basis. MPEG-7
`based descriptors include a length of descriptor, i.e., from a
`start frame to an end frame, and a schema for a database of
`indices. The database is a hierarchical based database that
`allows for hierarchical scene description. For example, a
`root index may represent a scene of Paris, while a branch
`index may represent a scene of the Eifiel Tower.
`The indexing is also used for stream creation. In one
`embodiment, the stream is created in realtime from a single
`MPEG-2 or MPEG-4 content stream, e.g., a start GOP to an
`end GOP, or a start frame to an end frame. In a second
`embodiment, the stream is created in non real time and the
`modified stream file is stored. In a third embodiment, the _
`stream is transcoded or re-encoded such that a reference
`frame or I-frame is forced to be the frame with information
`desired in an index, even if the frame arrived in the packet
`processor 144 as a predictive frame, e.g., B-frame or
`P-frame. Stream indexing will also be discussed below with
`respect to FIG. 3.
`Once the preprocessed content is uploaded, the stream
`caching server 102 may store and stream the preprocessed
`content, or alternatively stream the content in real time. The
`streaming of content encapsulated in IP format enables the
`stream caching server 102 to stream content to subscribers
`via different types of access networks 106, 108 and 110. As
`such, only one stream caching server 102 and one distribu—
`tion network 104 is required to provide scalable streaming.
`Namely, one stream caching server 102 may stream content
`to the LAN/WAN 106, the carrier network 108, the cable
`network 110 and any other access network that supports IP.
`
`L4.) m
`
`40
`
`60
`
`AT&T EXHIBIT 1006
`
`

`

`US 7,159,233 B2
`
`7
`streams content over many more access networks and sub—
`scriber terminals than the example shown in FIG. 1.
`The stream caching server 102 is located at the local head
`end 138 with an infrastructure system manager 140, a switch
`142 and a packet processor 144. The stream caching server
`102 comprises a storage medium 146 to store the content
`preprocessed in accordance to the present invention. One
`configuration of the storage medium 146 is a redundant set
`of disk arrays, e.g., Redundant Array of Inexpensive Disks
`(RAID).
`The infrastructure system manager 140 coordinates a
`(user) request from the subscriber terminal by passing the
`request to the stream caching server 102 and establishing a
`session between the subscriber terminal and the stream
`caching server 102. An exemplary infrastructure system
`manager 140 is the DIVA System Manager (DSM), as
`disclosed in US. application Ser. No. 09/772,287. The
`switch 142 routes the user request from the stream distri-
`bution network 104 to the system manager 140. Addition-
`ally, the switch 142 routes the retrieved content from the
`stream caching server 102 to the packet processor 144.
`The storage medium 148 stores the preprocessed content
`in an IP format. The content is configured as a plurality of
`
`MPEG, e.g., MPEG—2 or MPEG—4, packets contained in a
`payload of a RTP packet within an IP packet. For example,
`the payload of each RTP packet may contain five MPEG-2
`packets. The structure of the IP packet is shown to FIG. 2B.
`The RTP format (RFC 1889) minimizes the latency in
`streaming content from the server, by supporting the stream-
`ing of content in real time. Additionally, the content in the
`IP packet can be configured to have a minimal Quality of
`Service (QoS). e.g., data latency.
`The packet processor 144 postprocesses the content into
`a format supported by a particular type of player and access
`network 106, 108 and 110 used to receive the content from
`the stream caching server 102. Such a player is either a
`software module downloaded from a HTTP server 148 to a
`computer terminal 122, a hardware module coupled to a
`subscriber terminal, or a card inserted into a subscriber
`terminal. Exemplary players include a MPEG-1 player, a
`MPEG-2 player, a MPEG-4 player, a Microsoft Media
`Player, a Real Video/Real Audio Player,
`21 Quick'l'ime
`Player, a Wireless Device Video or Audio Player, and the
`like.
`
`10
`
`L4.) in
`
`40
`
`The packet processor 144 transcodes the content without
`disturbing the IP format. For example, the packet processor
`144 separates the content, e.g., MPEG-2 packets, and header
`information in the IP packet, transcodes the content packets
`into a desired format supported by the access network and _
`downstream player, and combines the transcoded packets
`with the header information to recreate the IP packet. Such
`transcoding is performed at an elementary packet level for
`transmitting at the transport packet level. Additional ftmc-
`tions performed by the packet processor 144 include jitter
`correction, creating of a PBS (packet elementary stream),
`stream splicing, and statistical multiplexing.
`More specifically, the transcoding includes the conversion
`content in the RTP payload into a format suitable for the
`access network 106, 108 and 110, but the transcoded content
`is still encapsulated in the IP packet stream. Such transcod-
`ing may change the format and rate of the content. For
`example, the transcoding may include the conversion of
`MPEG-2 formatted content into MPEG-1, MPEG-4, AVI,
`Moving JPEG, MP3, Quicktiine, Wireless Applications Pro-
`tocol content, and the like. The transcoding is performed in
`accordance to an extended Real Time Streaming Protocol
`
`60
`
`8
`(R'l'SP—RFC 2326) such that stream manipulations conform
`to Intemet standards and are applicable to any access
`networks that support IP.
`Additionally, the exact manner ofthe transcoding depends
`on the available bandwidth in the access netw