Declaration of Robert Scheffler
`
`I, Robert Scheffler, declare as follows:
`
`Ie
`
`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.
`
`Be
`
`Iam currently employed at PRICOM,Inc. (“PRICOM”) as the
`
`President.
`
`I have held this position since September 2018.
`
`a
`
`From 1999 to 2006, I was employed by Broadbus Technologiesasits
`
`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-1 server family, a
`
`high-density, highly scalable DRAM-basedserver for VOD,subscription video-
`
`on-demand (SVOD), and next-generation Television-on-Demand (TOD) services.
`
`a
`
`The Internet and Television Association (formerly the National Cable
`
`and Telecommunications Association) (“NCTA”) Annual Conventional and
`
`International Exposition (“National Show”) is one ofthe two largest trade shows
`
`held annually for cable industry operators. The NCTA trade showattracts 20,000
`
`to 50,000 individuals and members. The showis advertised to its membership and
`
`is well known to and well attended by individuals associated with the cable
`
`industry.
`
`1
`
`DISH Ex. 1061, p. 1
`DISH v. BBiTV
`
`IPR2020-01267
`
`DISH Ex. 1061, p. 1
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`6.
`
`t
`
`I attended the National Showevery year from 1999 to 2018.
`
`Based on my observations while in attendance, the National Show
`
`wasattended every year by thousandsof 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 effectuating and maintaining
`
`the products developed bythe 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 wasincludedinaset of Proceedings associated with that year’s show and the
`
`author was asked to present the highlights of their paperat the National Show.
`
`9.
`
`I authored, submitted, and later presented a paperat 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 wasentitled “Ingest & Metadata Partitioning: Requirements for Television
`
`On Demand.” Exhibit A is a true and correct copy ofthat paper.
`
`tJ
`
`DISH Ex. 1061, p. 2
`DISH v. BBiTV
`
`IPR2020-01267
`
`DISH Ex. 1061, p. 2
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`11.
`
`The paper was provided to the NCTAseveral 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 hadalarge membership,all of
`
`which would receive copies of the papers, authoring papers was a good wayto get
`
`the attention of cable industry experts and decision-makers.
`
`13.
`
`Every year I attended the National Show, the NCTA would provide
`
`copies of the Proceedings to both its membership and any non-memberpaper
`
`authors a month or two in advance of the show. 2003 was no exception.
`
`I received
`
`a complete copyof 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 of the 2003 NCTA
`
`Proceedings that included my paper.
`
`14.
`
`T recall that the NCTA Proceedings were at one point distributed to
`
`the NCTA membersand authors in paper format. At some point, the NCTA began
`
`distributing CDs including a PDFofthe Proceedings. Later, the NCTA distributed
`
`the Proceedings in advance ofa National Show by emailing a download linkto the
`
`NCTA members and paperauthors.
`
`I do not specifically recall which of these
`
`distribution methods was used in connection with the 2003 NCTA Proceedings.
`
`However, I have attended the NCTA national showsfor nearly 20 years, and every
`
`DISH Ex. 1061, p. 3
`DISH v. BBiTV
`
`IPR2020-01267
`
`DISH Ex. 1061, p. 3
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`year either myself or a NCTA memberthat I was working with received the
`
`Proceedings in advance in paper form, on a CD, or via a downloadlink.
`
`15. While at the 2003 National Show, I participated on a panel with three
`
`or four other panelists where I presented my paper. The panel wasled by a
`
`moderator. My panel was attended by somewhere onthe 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 understandingthat this is why
`
`the NCTA membership is provided with a copy of that year’s Proceedings in
`
`advance of the 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 knowledgeare
`
`true, and that all statements made on information andbelief 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 |day of “5020.
`
`Robert Scheffler
`
`4
`
`DISH Ex. 1061, p. 4
`DISH v. BBiTV
`IPR2020-01267
`
`DISH Ex. 1061, p. 4
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`Exhibit A
`Exhibit A
`
`DISH Ex. 1061, p. 5
`DISH v. BBiTV
`
`IPR2020-01267
`
`DISH Ex. 1061, p. 5
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`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. 1061, p. 6
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`broadcast television will be required to
`
`
`
`processing capacity to focus on the ingest
`
`
`
`
`
`
`support ever increasing content libraries and
`
`functions. This was very labor intensive
`
`
`
`
`stream counts. However it is important to
`
`
`
`with a single operator feeding tapes and
`
`
`look at the evolution ofVOD architectures
`
`
`entering rules to instruct the STB guide
`
`
`to understand how those requirements will
`
`
`
`software about the pricing and availability of
`
`
`
`new titles (see Figure 2-1). Keeping up with
`change in the future.
`
`
`
`content ingest was quite manageable for the
`
`
`operator and the conventional VOD server.
`
`VOD in the Past
`
`VOD Today
`
`In the early days of VOD, movies were
`
`
`
`distributed on tapes. These tapes were
`
`
`a specific shipped to each site that required
`As an industry, VOD has matured
`
`
`
`movie title. Using an encoding rate of 3.375
`
`
`beyond the simplistic example described
`
`
`Mbps and an average movie length of 100
`
`
`
`above. VOD installations now enable 1,000
`
`
`
`to 3,000 customers to access a library of 150
`
`minutes, the total size of each movie was
`
`
`
`to 300 movies. As a result, shipping tapes to
`
`
`
`roughly 2.4 GBytes. A typical installation
`
`
`VOD enabled head-ends has proved to be a
`
`
`might contain a library of under 100 movies
`
`
`and was capable of streaming to less than
`
`
`
`logistical challenge and has evolved to a
`
`1,000 subscribers simultaneously.
`
`
`newer model called pitch-and-catch, where
`
`
`
`content is distributed by private broadcast to
`via
`
`
`remote stations and syndication partners
`
`
`satellite (see Figure 2-2). With increased
`
`
`
`
`library sizes, increased stream counts
`and
`
`
`
`more diverse suppliers sending data, the
`
`
`
`distribution and propagation of content has
`
`
`shown itself to be quite a challenge. Content
`
`
`
`can still arrive on tapes and is caught by
`VOD Server
`
`
`
`catchers along with trailers, posters, and
`
`rules that are required to put it all together.
`
`@:Q]
`@:Q]
`
`�□
`�□ =
`= ===
`
`
`
`Content Person
`
`Figure 2-1 Content Ingest for VOD in the
`
`
`
`
`past
`
`Content Person
`
`In early VOD deployments, metadata or
`
`
`
`
`
`other business rules weren't typically
`
`
`supplied with the content. The operators
`
`themselves were responsible for deciding
`
`
`
`
`what rules applied to particular content and
`
`
`for entering the appropriate rules into the
`
`
`
`VOD server or control system. This
`
`
`relatively simple model meant that most of
`
`the attention was focused on the billing
`Content aggregation companies have
`
`
`
`
`
`interfaces, set top box (STB) client, and
`to
`
`
`risen to the challenge by offering services
`
`
`
`head-end control. With low stream counts,
`
`
`edit, adjust, and compile these diverse
`
`
`
`movie titles could be loaded during off-peak
`
`formats and metadata into a nice bundled
`
`hours when the VOD server had more
`
`
`
`
`
`Figure 2-2 Content Ingest for VOD today
`
`
`
`DISH Ex. 1061, p. 7
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`package to be pitched and caught. However,
`
`
`
`large amounts of content propagation. To
`
`
`
`
`
`now handle the ingest of a significant
`
`
`a fundamental problem is that while quite
`
`adept at low-volume streaming,
`
`
`amount of content, a conventional VOD
`
`
`
`conventional VOD servers usually lack in
`
`
`server will typically lose some, or much of
`
`its streaming performance.
`
`
`
`their ability to simultaneously ingest large
`
`
`quantities of content. The situation
`Today's VOD server systems adequately
`
`
`
`
`
`
`multiplies itself as we add streams, services,
`
`
`storage, and begin to distribute more
`
`
`accommodate the demands of low­
`
`
`hardware throughout the network.
`
`concurrency VOD/SVOD deployments.
`
`
`However, adding the task of ingesting
`
`
`
`
`numerous channels of broadcast content to
`
`
`
`conventional VOD servers creates a massive
`Subscription VOD (SVOD) increases the hardware
`
`
`
`
`
`and software infrastructure that
`
`
`
`
`existing VOD content library by adding 50-
`
`
`takes up a lot of space, consumes a lot of
`
`power, and is inherently less reliable.
`
`100 movies and other content and making
`
`
`them available to an increased number of
`
`
`subscribers. Even with a limited amount of
`
`
`
`content offered, trials of SVOD to date have
`
`
`
`resulted in increased concurrency rates that
`may be as high as 10%-20% or 3,000 to
`
`
`5,000 streams in a typical system.
`
`
`
`Combining SVOD with VOD
`
`
`
`Content Person
`
`VOD Servers
`
`These concurrency rates place
`
`
`
`tremendous demands on the streaming
`
`
`capacity of the network. Also as stream
`
`
`
`counts increase, so does the problem of
`
`
`
`
`content ingest. To increase the stream count,
`
`
`
`additional streaming servers are required.
`
`
`
`
`These additional servers need access to the
`future
`
`
`
`library of ingested content. If a given piece
`
`
`of content is to be made available to every
`Television on Demand using Conventional
`
`
`
`
`customer on the network, the content needs
`VOD Servers
`
`
`
`to be either locally stored or remotely
`
`accessible. One way to make the content
`Now let's look at an example where we
`
`
`
`
`accessible is to add an ingest server or
`
`
`expand the VOD/SVOD service offerings to
`
`
`propagation server at the point where the
`
`
`include Television on Demand (TOD). TOD
`
`
`
`content is caught or loaded from tape. This
`
`
`
`enables cable operators to provide on
`
`
`
`ingest server could then locally store the
`
`demand delivery of live or pre-recorded
`
`
`content, making it available to the rest of the
`
`
`
`broadcast television services as well as the
`
`
`
`
`servers. Alternatively the ingest server could
`
`
`movie and subscription-based content that
`
`
`be used to propagate or distribute the
`
`VOD/SVOD offers. TOD is especially
`
`
`
`content to the streaming servers, whether
`
`
`
`attractive to television content owners
`local or remote (see Figur e 2-3).
`
`
`
`because it allows the viewing and sale of
`
`
`
`Remembering that the streaming servers are
`
`older programming that is out of
`
`
`
`primarily intended for streaming, there is a
`syndication. TOD enables the consumer to
`
`
`
`
`
`fixed amount of bandwidth available for
`
`
`have PVR functionality during broadcast
`
`Figure 2-3 Content Ingest for VOD in the
`
`DISH Ex. 1008, p. 8
`
`DISH v. BBiTV
`
`IPR2020-01280
`
`DISH Ex. 1061, p. 8
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`

`

`

`

`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
`
`DISH Ex. 1061, p. 11
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`• 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
`
`DISH Ex. 1061, p. 12
` DISH v. BBiTV
` IPR2020-01267
`
`

`

` 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
`
`DISH Ex. 1061, p. 13
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`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
`
`DISH Ex. 1061, p. 14
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`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 scale and migrate
`their networks from Video on Demand to
`Television on DemandTM – (TOD®)
`
`Robert can be reached at:
`
`(978) 264.7900
`Robert.Scheffler@broadbus.com
`http://www.broadbus.com
`
`TOD and the Broadbus logo are registered trademarks of Broadbus Technologies, Inc. All rights
`reserved. Other trademarks used herein are property of the respected companies.
`
`DISH Ex. 1008, p. 15
` DISH v. BBiTV
` IPR2020-01280
`
`DISH Ex. 1061, p. 15
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`Exhibit B
`Exhibit B
`
`DISH Ex. 1061, p. 16
`DISH v. BBiITV
`
`IPR2020-01267
`
`DISH Ex. 1008, p. 16
` DISH v. BBiTV
` IPR2020-01280
`
`DISH Ex. 1061, p. 16
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`THE COMPLETE
`
`TECHNICAL PAPER PROCEEDINGS
`
`FROM:
`FROM:
`
`NCTA
`
`Technical
`Papers
`
`DISH Ex. 1061, p. 17
`DISH v. BBiITV
`
`IPR2020-01267
`
`DISH Ex. 1008, p. 17
` DISH v. BBiTV
` IPR2020-01280
`
`DISH Ex. 1061, p. 17
` DISH v. BBiTV
` IPR2020-01267
`
`

`

`A METHOD OF ANALYZING MPEG DATA IN ENCAPSULATED STREAMS
`
`F. Eugene Rohling
`DVA Group, Inc.
`
`Abstract
`
`This paper describes a method of analyzing
`encapsulated binary data streams for the
`purposes of performing detailed message
`analysis. This method evolved from a general
`purpose analysis tool used to analyze radar
`data. It is now being applied to the analysis
`of MPEG-2 content and access control data
`delivered both in-band and out-of-band. It is
`particularly useful for compartmentalizing the
`details of sensitive control and encryption
`information within the MPEG data strea of an
`access control system..
`
` The method allows users to describe
`encapsulated framed data, parsing a binary
`data stream, and generating human readable
`output that can be used to analyze and resolve
`problems. The template files can be tailored
`and customized to reveal varying levels of
`proprietary and confidential data within the
`binary stream.
`
`INTRODUCTION
`
` This paper identifies a solution that helps
`test and field engineers analyze complex
`MPEG data streams. It uses the familiar NAS
`access control service as an example of data
`that has been encapsulated four times when it
`is received within a headend system. Finally,
`it discusses the need for these tools as new
`technologies emerge.
`
` This paper specifically discusses access
`control data. Many off-the-shelf tools exist
`for analyzing standard MPEG-2 video and
`DOCSIS services. However, access control
`systems are by their nature proprietary, and
`
`tools for looking at stream usage of Motorola
`Broadband DigiCipher, Scientific Atlanta
` Power Key, and other access control
`streams are usually held close. This makes it
`difficult for an MSO to find problems in his
`local
`system,
`especially when he
`is
`responsible for operating it.
`
`Encapsulated MPEG Data
`
` The National Access Control Service
`(NAS) owned by Motorola Broadband and
`operated by AT&T (now Comcast) is an
`excellent example of MPEG encapsulated
`data. Figure 1 shows the various layers of
`MPEG data. First, the DigiCipher OOB data
`is encapsulated
`into MPEG private data
`message packets. When it arrives in the
`headend, data is then sent from the satellite
`receiving device (IRT) across Ethernet to the
`out of band modulator (OM). That is, the
`OOB data is carried as an encapsulated MPEG
`data stream within a HITS multiplex through
`the satellite system. [1]
`
`Level 2
`Encapsulation
`
`Level 1
`Encapsulation
`
`Visible Layer
`
`Digicipher AC Messages
`MPEG Messages
`
`Digicipher OOB Traffic
`MPEG Packets
`
`HITS Transport Stream
`MPEG Packets
`
`Figure 1 - NAS Encapsulation
`
` A standard MPEG