Declaration of Robert Scheffler
`
`1, Robert Scheftler, declare as follows:
`
`1.
`
`I have personal knowledge regarding all the facts set forth in this
`
`declaration.
`
`I am not being and have not been compensated for my time in
`
`preparing this declaration.
`
`2.
`
`I am currently employed at PRICOM. Inc. (“PRICOM”) as the
`
`President.
`
`I have held this position since September 2018.
`
`3.
`
`From 1999 to 2006,, I was employed by Broadbus Technologies as its
`
`Co-Founder, Chief Technology Officer, and Chief Architect.
`
`4.
`
`Leading up to 2003, I was developing Broadbus‘s next generation of
`
`video-on-demand (VOD) servers, including the Broadbus B-l server family, a
`
`high-density, highly scalable DRAM—based server for VOD, subscription video-
`
`on—demand (SVOD), and next-generation Television-on-Demand (TOD) services.
`
`5.
`
`The Internet and Television Association (formerly the National Cable
`
`and Telecommunications Association) ("NCTA”) Annual Conventional and
`
`International Exposition (“National Show”) is one of the two largest trade shows
`
`held annually for cable industry operators. The NCTA trade show attracts 20,000
`
`to 50,000 individuals and members. The show is advertised to its membership and
`
`is well known to and well attended by individuals associated with the cable
`
`industry.
`
`DISH Ex. 1008, p. 1
`DISH-Ex. 1008, p. 1
`DISH v. BBiTV
` DISH v. BBiTV
`|PR2020-01280
` IPR2020-01280
`
`

`

`6.
`
`7.
`
`I attended the National Show every year from 1999 to 2018.
`
`Based on my observations while in attendance, the National Show
`
`was attended every year by thousands of individuals. Among the attendees were
`
`both engineers and architects working for large cable companies, or other vendors
`
`and industry affiliates. Cable industry architects work on the development of next
`
`generation cable products. Engineers are tasked with eft‘ectuating and maintaining
`
`the products developed by the architects.
`
`In the years I attended the National Show
`
`on behalf of Broadbus, including in 2003, I personally met many cable industry
`
`architects and engineers. These meetings occurred either at Broadbus‘ show booth,
`
`or in a private meeting room Broadbus reserved.
`
`8.
`
`In advance of the National Show, the NCTA would call for authors
`
`from the cable industry to submit technical papers. This occurred every year that I
`
`attended the National Show. If an author’s paper was selected by the NCTA, the
`
`paper was included in a set of Proceedings associated with that year’s show and the
`
`author was asked to present the highlights of their paper at the National Show.
`
`9.
`
`I authored, submitted, and later presented a paper at the 2003 National
`
`Show. This National Show occurred in Chicago, Illinois in June of 2003.
`
`10.
`
`The paper I authored, submitted, and presented at the 2003 National
`
`Show was entitled “Ingest & Metadata Partitioning: Requirements for Television
`
`On Demand." Exhibit A is a true and correct copy of that paper.
`
`is)
`
`DISH Ex. 1008, p. 2
`DISH Ex. 1008, p. 2
`DISH v. BBiTV
` DISH v. BBiTV
`|PR2020-01280
` IPR2020-01280
`
`

`

`l 1.
`
`The paper was provided to the NCTA several months in advance of
`
`the June 2003 National Show.
`
`12.
`
`Companies like Broadbus, and authors like myself, found it desirable
`
`to submit papers to the NCTA. As the NCTA had a large membership, all of
`
`which would receive copies of the papers, authoring papers was a good way to get
`
`the attention of cable industry experts and decision-makers.
`
`13.
`
`Every year I attended the National Show, the NC‘TA would provide
`
`copies of the Proceedings to both its membership and any non—member paper
`
`authors a month or two in advance of the show. 2003 was no exception.
`
`I received
`
`a complete copy of that year‘s Proceedings, which included my “Ingest &
`
`Metadata Partitioning: Requirements for Television On Demand,” in advance of
`
`the show in June 2003. Exhibit B is a true and correct copy ot‘the 2003 NCTA
`
`Proceedings that included my paper.
`
`14.
`
`I recall that the NCTA Proceedings were at one point distributed to
`
`the NCTA members and authors in paper format. At some point, the NCTA began
`
`distributing CDs including a PDF of the Proceedings. Later, the NCTA distributed
`
`the Proceedings in advance ofa National Show by emailing a download link to the
`
`NCTA members and paper authors.
`
`I do not specifically recall which of these
`
`distribution methods was used in connection with the 2003 NCTA Proceedings.
`
`However, I have attended the NC‘TA national shows for nearly 20 years, and every
`
`DISH Ex. 1008, p. 3
`-D|SH Ex. 1008, p. 3
`DISH v. BBiTV
` DISH v. BBiTV
`|PR2020-01280
` IPR2020-01280
`
`

`

`year either myself or a NCTA member that I was working with received the
`
`Proceedings in advance in paper form, on a CD, or Via a download link.
`
`15. While at the 2003 National Show, I participated on a panel with three
`
`or four other panelists where 1 presented my paper. The panel was led by a
`
`moderator. My panel was attended by somewhere on the order of 150 or 200
`
`attendees.
`
`16.
`
`During the panel, audience members had the opportunity to ask
`
`questions that the panelists would answer.
`
`It is my understanding that this is why
`
`the NCTA membership is provided with a copy of that year’s Proceedings in
`
`advance ofthe National Show: providing copies of the Proceedings allows
`
`attendees to be prepared to ask questions.
`
`17.
`
`I declare that all statements made herein of my own knowledge are
`
`true. and that all statements made on information and belief are believed to be true,
`
`and that these statements are made with the knowledge that willful false statements
`
`and the like so made are punishable by fine or imprisonment, or both, under
`
`Section 1001 of Title 18 of the United States Code.
`
`
`Executed in Peyton, CO, on the Eday of WNE’ZO20.
`
`Robert Scheffler
`
`DISH Ex. 1008, p. 4
`DISH Ex. 1008, p. 4
`DISH v. BBiTV
` DISH v. BBiTV
`|PR2020-01280
` IPR2020-01280
`
`

`

`Exhibit A
`
`Exhibit A
`
`DISH Ex. 1008, p. 5
`DISH Ex. 1008, p. 5
`DISH v. BBiTV
` DISH v. BBiTV
`|PR2020-01280
` IPR2020-01280
`
`

`

`INGEST & METADATA PARTITIONING: REQUIREMENTS FOR
`TELEVISION ON DEMANDTM
`
`Robert G. Scheffler, Chief Architect
`Broadbus Technologies, Inc.
`
`ABSTRACT
`
` On demand video services, such as
`today’s Video on Demand (VOD),
`Subscription Video on Demand (SVOD), and
`the fast-approaching Television on
`DemandTM (TOD®) are enhancing the
`consumer television experience and creating
`new, exciting revenue opportunities and
`increased cash flow for cable operators and
`content owners alike. However, the
`technical requirements to support these
`services are becoming more demanding and
`complex. In VOD, cable operators are
`seeing solid buy-in rates, repeat purchase
`patterns, and concurrency rates of 3%-10%
`with limited marketing and promotional
`support. With recent trials of SVOD and an
`increased number of popular titles,
`concurrency rates have ‘smoothed’ the peak
`usage rates throughout the week to numbers
`that often approach 10%-20%. However,
`with Television on Demand (TOD) services,
`consumers will have considerably more
`programming choices including movies,
`subscription-based content, and the most
`popular broadcast content. It is anticipated
`that concurrency rates of TOD may steadily
`climb to levels that approach 30%-65% --
`rates that mirror the total concurrent U.S.
`television viewing audience as measured by
`rating services such as Nielson.
`
` Increased service usage, additional
`content, and new business models are
`challenging MSOs to conduct unprecedented
`network architecture preparation and
`planning. In addition, decisions related to
`
`asset distribution, content propagation,
`network loading, metadata and rules issues
`need to be addressed to make Television on
`Demand a commercial reality.
`
` This paper will address the issues and
`requirements associated with server ingest
`of broadcast content and content
`propagation. It will also discuss the
`architectural implications for the VOD
`server and propose a new class of server to
`support TOD requirements. The paper will
`also discuss how TOD content is managed
`through the creation and distribution of
`enhanced metadata formats in an
`environment that is controlled by studios,
`distributors, and cable operators.
`
` New video server architectures and
`rules-based content control and propagation
`systems become integral contributors to the
`success of future on-demand services.
`
`VOD/TOD CONTENT INGEST
`
` The issue of the ingest of broadcast
`television content is one that will become
`more and more important for advanced
`video services such as Television on
`Demand to become a reality. As more
`content is made available and concurrency
`rates increase, architectural decisions will
`have to be made to support these increased
`demands on the network. A new architecture
`comprised of higher density VOD/TOD
`servers with the capability to ingest
`
`DISH Ex. 1008, p. 6
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`processing capacity to focus on the ingest
`nctlons. T 1s was very a0r1ntens1ve
`ith a single operator feeding tapes and
`ntermg ru es to instruct t e STB gu1ue
`:pSa:("D 8‘oE (-P:r("D
`asE.O H.a
`ean 9)<9:ET5‘_.r.(-PK<
`or:
`| ew titles (see Figure 2—1). Keeping up wit
`ontent mgest was quite manageau e ort e
`perator and the conventional VOD server.
`
`OO'0(D
`
`o H,
`5‘
`
`upport ever 1ncreas1ng content 1urar1es anu
`tream counts. However it is important to
`00 at t e evo ution o VOD arc 1tectures
`
`o understand how those requirements will
`hange in the fiJture.
`
`OD in the Past
`
`In the early days of VOD, movies were
`u istributed on tapes. These tapes were
`5 1ppeu to eac s1te t at requ1reu a spec1 c
`.
`.
`'
`.
`.
`'
`
`5
`
`rups anu an average mov1e engt o 100
`I mutes, t e tota Size 0 eac mov1e was
`
`.nd was capable of streaming to less than
`,000 suuuscr1ers s1mu taneous y.
`
`
`
`
`
`
`OD Toda
`
`C7
`
`As an 1nuustry, VOD as mature
`eyond the simplistic example described
`uove. VOD 1nsta ations now enau e 1,00
`
`-
`
`II {:T‘OgD :, U}(D ,_.I.” H0 Cf(D QEH(D m o{:7a:E800(D OOE.(DDt
`8D U3c-r ._I
`
`arr1ve on tapes anu1s caug t y
`catchers along with trailers, posters, and
`I
`est at are requ1reu to put it a toget er.
`
`igure 2-] Content Ingestfor VOD in the
`
`In early VOD deployments, metadata or
`
`ow stream counts,
`' eauu-en contro . Wit
`I ov1e t1t es cou u ue oauue uur1ng o —pea
`' ours w ent e VOD server
`au more
`
`
`atc er
`
`W
`
`
`
`ape O FIVe
`
`igure 2-2 Content Ingestfor VOD today
`
`ontent aggregation companies ave
`I isen to the challenge by offering services to
`eu1t, auJust, anu compi et ese u1verse
`
`0 3,000 customers to access a 1urary o 150
`o 300 mov1es. As a resu t, s 1ppmg tapes to
`OD enau eu
`eauu—ens as prove to ue a
`ogistical challenge and has evolved to a
`| ewer moue ca eu p1tc -anu—catc , w ere
`content is distributed by private broadcast to
`go(-F(D 2,,E:o5U1 ga QsE‘0§_0s
`
`*das(D"iU1 S9}
`ate 1te (see Figure 2-2). Wit
`increaseu
`._.
`ibrary sizes, increased stream counts and
`ore u1verse supp 1ers senu1ng auta,t e
`1stribution and propagation of content has
`
`ormats anu meta ata mto a nice uunu eu
`
`

`

`large amounts of content propagation. To
`9:
`e t e mgest o a Signi 1cant
`mount 0 content, a conventiona VOD
`typica y ose some, or muc o
`ts streaming performance.
`
`éaH.
`
`r-nl
`
`—9309302S(Dbe
`
`package to be pitched and caught. However,
`.
`ncamenta pro em is t at w 1e qulte
`dept at low-volume streaming,
`onventiona VOD servers usua y ac<1n
`heir ability to simultaneously ingest large
`cuantities of content. The situation
`(D m - -
`t—c(D U} :1 m(D
`U1,_,H(Dg“U1 m(Dr-c<t—co(D “U1
`C Cf’13
`mU}
`torage, and begin to distribute more
`arcwaret oug outt e networ .
`
`I
`
`ombinin_ SVOD with VOD
`
`Subscription VOD (SVOD) increases the
`Xistlng VOD content 1crary y ac cing 50—
`100 mov1es anc ot er content anc ma ing
`hem available to an increased number of
`uccscriers. Even Wit a imitec amount 0
`
`ontent o erec, tria s o SVOD to cate ave
`| esu tec in mcreasec concurrency rates t at
`l ay be as high as lO%—20% or 3,000 to
`,000 streams in a typical system.
`
`u
`
`_m
`
`B’13 00(D m(—P
`
`o ce e1t er oca y storec or remote y
`ccessic 6. One way to ma 6 t 6 content
`.ccessible is to add an ingest server or
`ropagation server at the point where th-
`ontent 1s caug tor oacec com tape. T is
`server cou c t en oca y storet e
`ontent, ma ing it avai ac e tot 6 rest 0 t e
`ervers. Alternatively the ingest server could
`e use . to propagate or cc1striutet e
`ontent to t e streamlng servers, w et er
`ocal or remote (see Figure 23).
`' ememering t at t e streaming servers are
`rimarily intended for streaming, there is a
`xe amount 0 cccanw1t
`ava1 a e or
`
`hese concurrency rates place
`remenc ous cemancs ont e streaming
`apacity of the network. Also as stream
`ounts increase, so does the problem of
`ontent ingest. To increase t e stream count
`. dditional streaming servers are required.
`ese ac c 1t1ona servers neec access to t e
`gure 2-3 Content Ingest 0r VOD in t e
`m!
`icrary o ingestec content. I a given piece
`uture
`c f content is to be made available to every
`
`e ev1s1on on Demanc usmg Conventlona
`ustomer ont e networ , t 6 content nee s
`
`’13
`
`'\<
`
`ocay’s VOD server systems a equate
`ccommodate the demands of low-
`concurrency VOD SVOD cep oyments.
`owever, adding the task of ingesting
`umerous c anne s o roa cast content to
`onventiona VOD servers creates a mass1ve
`
`ll
`
`' ar ware anc so ware 1n astructure t at
`a es up a 0t 0 space, consumes a 0t 0
`ower, anc is in erent y ess re lace.
`
`
`
`_i
`
`ow let’s look at an example where we
`Xpanc t e VOD SVOD serVice o erings to
`BO0 c . a: a(D a:SBo s os U3SD9
`TOD . TOD
`enables cable operators to provide on
`
`cceman '6 1very 0 we or pre-recorcce
`C7
`roadcast television seWiceS as well as the
`n ov1e anc succcscriptlon—ase contentt at
`OD/SVOD offers. TOD 13 espec1ally
`attractive to te ev1s10n content owners
`cecause It a OWSt e v1ew1ng anc 53 e 0
`older programming that is out Of
`yncication. TOD enac est e consumer to
`ave PVR functionality during broadcast
`
`

`

`elevision viewing without requiring a hard-
`rive in t e STB. At a minimum a TOD
`
`ystem should be capable of storing 1,000
`ov1es or VOD SVOD customers, p us
`0,000 hours of captured broadcast
`e eVision.
`
`With Television on Demand, ingestion,
`propagation, an streaming 0 content nee s
`0 occur suc t att 6 customer sti
`ee s
`
`ike they are watching broadcast television.
`11 a
`ition to t e p et ora 0 content,
`
`railers, posters, and rules that VOD/SVOD
`equires, t ere is now a rea —time
`equirement or ow atency content
`ngestion. Current VOD SVOD systems,
`omp ete w1t catc ers, tape rives, an
`ontent ingest propagation now have to
`upportt e ingestion o
`roa cast te ev1Sion
`feeds (see Figure 2—4). The path of the
`broadcast feed to the broadcast ingest server
`0 t e ingest an propagation server to t 6
`OD server an t en tot e customers is an
`
`ta e many secon s an
`perationt at W1
`ust occur at the same time as the
`
`propagation of VOD content to the VOD
`
`Broadum Feed
`
`Broadcast Feed
`
`igure 2-4 Content Ingest 0r TOD using
`OD servers
`
`onsumer concurrency rates or TOD
`ill require a much higher stream count than
`6 current growt
`pI‘O_]€Ct10nS or VOD
`
`.p-
`
`offerings. When VOD, SVOD, and TOD are
`com me a typica system may require
`0,000 to 40,000 Simu taneous streams. For
`
`examp e, usmg conventiona VOD servers
`capable of 500 streams each would require
`0 servers to satisfy the stream requirement.
`owever, as more conventiona VOD
`
`ervers are added, the problem of
`propagating t e content to a t e servers
`increases exponentially and creates the need
`for more ingest servers to propagate the
`content so t at eventua yt ere is a
`
`ierarchy of ingest servers to streaming
`ervers. A conventiona VOD server is
`
`or streammg to customers, not or
`esigne
`ovmg, propagating an ingestmg
`
`e ev151on content. T ere ore to ay’s VOD
`evers are not the optimum solution for this
`compe ing, new app ication.
`
`e 10 in TOD with TOD servers
`
`e critica issuest at must
`
`e a
`
`resse
`
`o a equate y support TOD are content
`ingest and stream count. A new class of
`TOD server is required that can ingest
`ozens o c anne s o
`roa cast te ev1s1on
`
`hile simultaneously redistributing
`ousan s o streams Wit zero- atency. T e
`assoc1ate
`e ays can e remove
`y
`
`nning the broadcast feeds for ingest
`1rect y into a TOD server w ere t ey can
`6 1rect y streame to customers w1t out
`equiring an externa
`ierarc y o
`
`propagation servers. This solves the content
`ingest and propagation problem presented
`yTOD. However, a ierarc ica approac
`0 storage is a so require
`or o - ine
`OD SVOD TOD content access. W at is
`
`eeded is a distributed storage strategy with
`are
`oca storage as we as s are remote
`torage t at ecoup es t e streaming
`functions fiom the storage functions. By
`ecoup ingt ese
`nctions, stream-count
`
`and storage—size can be scaled independently
`hile storage can be placed in the network
`
`I HEx.
`
`I H v. BBiTV
`
`PR
`
`

`

`pecific applications with unique
`C:3:aBaE 5’1
`E
`
`ummar 0 Content Streams anu In est
`
`0:33g0 8HH(D5O
`
`I
`
`As needs grow and new business models
`re introuuuce, t e capaCIty anu sca mg 0
`OD streaming servers are being tested.
`ontent 1urar1es are mcreasmg anu greater
`‘< 5' 5‘mE‘.B
`00 (-PO E.00{27‘('DH a:5Q. E.00{27‘('DH
`tream counts (see Figure 2-6). With the
`au1 1ty to
`
`onventlona VOD servers are ueing
`axed to the limit with only a modest library
`. As content 1urar1es
`
`row, to prevent libraries fiom becoming
`‘sta e’ Wit 0 u content, an 1ncreaseu
`eumuan 1s ueing p aceu on o - 1ne ingest.
`
`
`
`eauu—en contammg
`- ective way. A master
`. pooled storage library would allow a group
`u
`servers to access esser-useu programs
`ithout requiring local copies. By using this
`u istributed storage architecture, each type of
`ontent can actua y ue move anu
`ositioned in the network for the perfect
`ua ance uetween ar ware anu transport
`osts. As the needs of the network change,
`he placement of system components can
`ange as we .
`
`
`
`Cementsmge
`
`| igure 2-5 Content Ingest for TOD using
`TOD servers
`
`A eX1u e arc 1tecturet at can anu e
`
`ow- atency 1ve-1ngest as we as p1tc er-
`
`treaming positioneu in one p ace anu
`torage distributed throughout the network
`
`ven the most demanding TOD applications
`see Figure 2-5). The future of VOD,
`VOD, anu TOD are uepenuent on a new
`rc 1tecture w ere sca e can ue contro eu
`.nu eac env1ronment can ue ta1 oreu or
`
`
`
`——UGOt—‘D—IV-‘nb—t0GUIDE9:9,89pm:O5$00.—0093559.,-50Bruce00H:”gt-{gH»a.505a:85930Hon:‘3:"3:5000H0093r-dH:(D59!»BBHHH('00Q
`:10Q91U:5$306H":ng.“D05$.”BHOO(0359:):30.HHS'(‘Dr—h.mfio:5-5’—0’000%gagEd:“5
`
`
`
`ven now, conventiona VOD servers are
`ueing an e to eep up
`ith SVOD and VOD applications.
`egardless of how much streaming
`I equ1rements increase as TOD uegins to
`roliferate, the cable operator will be forced
`o au u au u1tiona servers Just to anu e
`ngesttas<s. Event en, t e resu ting system
`ill not adequately address the problem of
`uroaucast mgest to streaming atency. T e
`__fl
`ear y superior so ution is to use a new
`ass 0 spec1a izeu TOD server capau e o
`ingesting and directly streaming with no
`—
`Greek/able delay-
`
`II H v. BBiTV
`
`m 1
`
`__
`
`

`

`Application Movie
`Library
`150-300
`200-400
`1,000
`
`VOD
`SVOD/VOD
`TOD/SVOD
`VOD
`
`Library
`Change
` 15/month
` 40/month
`100/month
`
`Concurrency
`Real-Time
`Rate
`TV Ingest
` 0 streams 5%-10%
` 0 streams 10%-20%
`100 streams 30%-65%
`
`Stream
`Count
`1,000-3,000
`3,000-6,000
`20,000-40,000
`
`Figure 2-6 System Capacities for VOD, SVOD, and TOD
`
`METADATA AND CONTROL
`
`Rules are needed
`
` The business of broadcast television
`today is very complex. The participants are
`numerous -- content owners, content
`aggregators, content distributors, broadcast
`and cable networks, MSOs -- and the
`relationships between the players are
`dynamic. What keeps content flowing from
`creators to consumers is the execution and
`enforcement of detailed contracts. These
`contracts determine the rules of “how”,
`“when”, and “by whom” content may be
`viewed. Whether it’s a re-run episode of
`“Friends” that airs in syndication on TBS or
`a live broadcast of the New York Knicks on
`ESPN 2, there are specific contract-based
`rules that govern the manner in which
`content is handled. Therefore, it should be
`no surprise that a system of contract-based
`rules will continue to govern (and perhaps
`with greater emphasis) in a business that
`combines broadcast television content with
`on-demand content.
`
` When VOD was initially deployed, the
`rules were relatively simple. MSOs would
`license a window of time when a movie
`would be made available to its subscribers.
`During the licensing window, the movie
`would be placed on the VOD Server and be
`available to subscribers. After the window
`
`was over, the movie would be deleted from
`the server. A set of rules, or metadata,
`capturing the pre-negotiated License
`Window Start and End Times would be read
`and enforced by the VOD server.
`
` As the industry moves towards SVOD
`and ultimately TOD, the same set of
`complex rules and attributes must be applied
`to each piece of content. Examples of
`additional rules for handling television
`content could include:
`• Specific days of week when content
`is available
`• One or more timeslots during the day
`• Time range that the program is
`available on a particular day
`• Specific commercials that must be
`carried with the program
`• Trick-mode rules and attributes
`(specific speeds, enabled/disabled
`functions)
`• Specific customer groups by
`demographic or geographic regions
`
` Rules should be entered and applied as
`early in the process as possible. There are
`rules from many levels. Examples include:
`• Content owner or studio
`• Studio distribution arm
`• Content aggregator
`• Television network
`• Local television station
`
`DISH Ex. 1008, p. 11
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`• Cable MSO
`• Cable local unit
`Some of the rules apply to VOD, some to
`SVOD, and some only to TOD. The key is
`that there are many rules that can come from
`any number of places. While it can seem
`daunting, it is quite easy to create and
`manage these rules.
`
`title, rating, description, time, actors,
`directors and crew, category, trailer file
`names, poster file names, etc. This type of
`metadata does not change, no matter who,
`what, when, or where it is distributed. This
`metadata could clearly be embedded in the
`actual content file and would stay with the
`file no matter where it goes.
`
`Partitioning Metadata
`
`2. Rules-specific Metadata
`
` The Video-on-Demand Content
`Specification as published by CableLabs has
`become the de-facto standard of how
`metadata is created and how it can
`incorporate many of the rules necessary to
`describe how on-demand content is to be
`handled. Initially written to support VOD
`(movies), it has been expanded to support
`SVOD. Moving forward, it is likely that the
`specification will need to be expanded to
`support all forms of on-demand content,
`including broadcast television.
`
` Some metadata rules pertain to the
`specific content itself, while others apply to
`how that content is distributed and sold. One
`piece of content from a studio can be sent to
`many cable systems across the country. If
`the studio had to regenerate the content
`metadata each time, it would become a
`painful process that nobody would want to
`use. However, if the content specific
`metadata were attached or imbedded in the
`content itself, and the distribution specific
`metadata was separate, then the same
`content with metadata attached could be sent
`to many locations, with a different version
`of the distribution metadata. Thus, the
`content metadata and the rules-specific
`metadata has been partitioned.
`
`1. Content Metadata
`
` Content metadata includes program
`specific things such as a unique identifier,
`
` The rules-specific metadata starts at the
`content creation studio. The studio decides if
`there are any specific restrictions on the
`distribution and sale of this content and
`passes those rules along to the content
`distributors. For example, there may be a
`requirement to restrict a specific category of
`commercial - A “Friends” episode may
`require Coke commercials, but not Pepsi.
`From there, the studio distribution arm may
`require more specific rules. “Friends” may
`be allowed from Monday through Friday
`anytime, but not Thursday from 8-9 pm, to
`prevent intruding on first-run episodes.
`Further downstream, the television network
`may decide to allow viewing anytime on
`Tuesday and Wednesday because those are
`non-peak days. The local television station
`may want to restrict viewing from 10-11pm
`during the local news hour.
`
`Figure 3-1 Rules-specific Metadata Flow
`
`DISH Ex. 1008, p. 12
` DISH v. BBiTV
` IPR2020-01280
`
`

`

` At each step along the way, the rules can
`become more restricted, but cannot be less
`restricted. In this manner, the content rules
`become more and more defined as they
`propagate downstream to the network
`operator and eventually the consumer (see
`Figure 3-1). Each system along the path is
`responsible for obeying the rules imposed
`upstream, and can expect each system
`downstream to obey the rules it passes on.
`When they reach the cable system, the TOD
`menu or EPG is built using these rules for
`the content received. By using this approach,
`the menus for the STB can be automatically
`and dynamically constructed.
`
`Figure 3-2 Metadata Flow to Multiple
`Downstream Paths
`
` At each step in the process, there can be
`multiple downstream paths (see Figure 3-2)
`to both multiple distributors and cable
`systems. For example, the studio could sell a
`“Seinfeld” episode to the WB for certain
`nights in a specific week, and TBS on other
`nights. From each step facing down, the
`metadata can fragment, meaning there is a
`one-to-many relationship at each step of the
`way. This is important because at each level,
`a seller can sell to multiple customers.
`However, it would be inconvenient to have
`to re-record and re-master content each time
`
`it was sold. An improved solution would be
`to ship the exact same content to each
`downstream customer, but each would be
`supplied with unique rules-specific metadata
`which can be changed or updated at any
`time without requiring the entire piece of
`content to be resent.
`
`Creating Metadata
`
` With the two distinct types of metadata,
`appropriate software will be required to
`author and control its creation. A key
`ingredient is a unique identifier used to tie
`the asset together with both forms of
`metadata.
`
`1. Content Metadata
`
` The content specific metadata is created
`at the earliest possible point in the
`production and distribution chain. The best
`place for this is at the studio or encoding
`provider. In cases where the content is
`broadcast television, the content metadata
`could originate from the television network,
`or other production company supplying the
`network feed.
`
`2. Rules-specific metadata
`
` The rules-specific metadata can be
`created and adjusted at any point in the
`production and distribution chain, but would
`typically be originated at the same point the
`content is generated. For live television
`events, the rules could and should precede
`the actual content transmission. By sending
`the rules ahead first, the STB EPG can be
`populated, or other similar guide related
`decisions can be made.
`
`Propagating Metadata
`
` Both forms of metadata need to be sent
`along the same path as the actual content.
`
`DISH Ex. 1008, p. 13
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`When any piece of content is sold or
`distributed downstream, the content
`metadata is included with the actual content
`along with an edited copy of the rules-
`specific metadata. Every copy of
`downstream content could have a unique set
`of rules-specific metadata, but the content
`metadata would stay the same. This allows
`each downstream provider to receive
`different rules, and allows them to be
`changed at a later time. When the rules
`change only the rules-specific metadata need
`be resent, not the content metadata or the
`entire program content. With this approach,
`any distributor in the chain can revise and
`update their rules-specific metadata as
`necessary.
`
`Enforcing Rules-specific metadata
`
`1. Asset Distribution
`
` To make this system viable, each video
`server or file server along the asset
`distribution path must receive and obey rules
`encoded in the metadata. Typically in the
`role of asset distribution, all that is required
`is to pass-on the rules given to us. At any
`point in the path, the rules can be edited to
`become more restricted, but never less
`restricted. As assets are moved downstream
`to the cable plant, appropriate TOD software
`will pick-up the rules-specific metadata. The
`TOD software will use this rules-based data
`to build the availability matrix of programs,
`and associate a local time-slot for the
`consumer. The TOD server software is then
`responsible for ensuring that the
`studio/distribution/network rules and
`permissions are obeyed.
`
`2. Content Propagation
`
` When propagating content throughout the
`cable system, there can exist specific rules
`related to perishable content, or content that
`
`has a limited availability window. When this
`type of rule is implemented, it is important
`that the system remove such content and
`make the storage and streaming space
`available as quickly as possible. Another
`situation where the propagation of content is
`important is when a known high-
`concurrency program arrives and needs to be
`propagated to many places in a large
`network to facilitate the expected high
`demand.
`
`CONCLUSION
`
` In this paper, we have examined how
`conventional VOD servers are limited in
`their ability to ingest content and support the
`increasing stream requirements of TOD.
`There is a considerable impact in the output
`stream count as a VOD server is asked to
`ingest more content. With most existing
`systems, there is a non-linear loss of
`streaming capability while ingesting content.
`Specifically, many output streams may be
`lost for each single stream ingested. As the
`number of titles increases in VOD libraries
`the problem becomes more and more
`apparent. To reduce the impact on a VOD
`server, ingest of new content can occur
`after-hours. However this is just a temporary
`solution and won’t scale as ingestion
`requirements continue to increase. With the
`upcoming everything on demand revolution,
`including Television on Demand, the ingest
`limitation of existing VOD server
`architectures becomes catastrophic. The
`more bandwidth consumed by ingest, the
`less bandwidth is available for streaming
`functions. Therefore more servers are
`required to keep the same stream count. As
`more servers are added, ingest and
`propagation becomes more and more
`complex. Elaborate ingest servers with
`content propagation services are a short-
`term solution but problematic longer term as
`
`DISH Ex. 1008, p. 14
` DISH v. BBiTV
` IPR2020-01280
`
`

`

`unacceptable latencies are introduced to the
`distribution of broadcast television.
`
` A new breed of servers designed
`specifically for Television on Demand is
`required. These servers need to handle over
`100 streams of live ingest while
`simultaneously redistributing the ingested
`content to over 20,000 output streams. The
`server must not suffer any performance
`degradation in output streams while
`ingesting live or non-live content. The
`latency through such systems must be low
`enough to enable live television with trick-
`mode functionality similar to that of DVD.
`The streaming elements and the storage
`elements must be separately scalable and
`movable within the network.
`
` With the plethora of ingested content
`from VOD, SVOD, and TOD, new means
`for authoring and propagating metadata
`must be implemented. In addition to content
`metadata, a new class of rules-based
`metadata will be required to protect revenue
`streams by allowing a rules-based
`distribution and STB presentation of
`content. The metadata must be partitioned
`
`and carried separately from the actual
`content to allow updating as well as
`customization depending on the MSO and
`region that the content is destined for.
`
` A new breed of specialized, high
`performance TOD server with low-latency
`and live content ingest capabilities, plus a
`new metadata methodology, is a requirement
`to realize the potential of Television on
`Demand for cable operators.
`
`About the Author
`
`Robert Scheffler is Chief Architect at
`Broadbus Technologies, a provider of next-
`generation server systems that enable cable
`operators to effectively