UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE … · 2017-03-09 · broadband network providers began to upgrade their distribution infrastructures accordingly. 10. In conjunction

1

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

SONOS, INC. Petitioner

v.

D&M HOLDINGS US INC. Patent Owner

DECLARATION OF ANTHONY WECHSELBERGER IN SUPPORT OF THE INTER PARTES REVIEWS OF U.S. PATENT NO. 6,473,441

SONOS 1018 - Page 1

1

I, Anthony Wechselberger, declare and state as follows:

I. INTRODUCTION

1. I have been retained as an expert witness for the Inter Partes Review

(“IPR”) of U.S. Patent No. 6,473,441 (“the ‘441 Patent”) filed by Sonos, Inc.

(“Sonos”) against D&M Holdings US Inc. (“Patent Owner” or “D&M”). More

specifically, I have been asked to render opinions for this IPR as to the

patentability of Claims 1-4 of the ‘441 Patent.

II. BACKGROUND AND QUALIFICATIONS

2. A copy of my Curriculum Vitae (“CV”) is attached to this declaration

as Appendix A.

3. I received a Bachelor of Science degree in Electrical Engineering

from the University of Arizona in 1974 and a Master of Science degree in

Electrical Engineering from San Diego State University in 1979. In addition, in

1984, I completed the Executive Program for Scientists and Engineers at the

University of California at San Diego.

4. I am currently the President of Entropy Management Solutions

(“EMS”), a position I have held since I founded the company in 1999. In this

capacity, I perform consulting services related to technology and business

development, content management, distribution and merchandizing, systems

engineering, and product design in the areas of industrial and consumer broadband

SONOS 1018 - Page 2

2

and multimedia technologies and associated commercial systems. As a result of

my twenty-five years of extensive technology experience in corporate life, and

continuing as President of EMS, I have worked with various aspects of cable,

broadcast and satellite television programming distribution, including systems and

equipment that included and supported on-demand content access such as pay-per-

view (PPV) and video on demand (VOD).

5. I have over forty years of experience working with high technology

systems related to military, commercial, and consumer communication systems,

networks, and appliances. I have held various design, leadership, and executive

positions in, for example, engineering, operations, sales and marketing, and

product management at leading companies, such as TV/COM International, Inc.

(TV/COM) and Oak Communications, Inc. (Oak), in those fields.

6. As Vice President at Oak Communications (in the 1980s), Chief

Technology Officer at TV/COM (in the 1990s), and a consulting systems engineer

(1999 to the present), I have specialized in the areas of digital communications

technologies, systems and networks, including infrastructures, communications

equipment and associated signal processing, network management and command-

and-control, and information security as used for content management,

merchandizing, and delivery to the receivers/consumers of information/content.

Consumer appliances are often the receivers/consumers of the communications

SONOS 1018 - Page 3

3

systems I’ve worked with, and I’ve been involved, for example, in the design,

manufacturing, sales, and servicing of consumer appliances, such as set top boxes

(STB), since the early 1980s.

7. My experience includes the development of terrestrial broadcast,

satellite uplink, and cable head-end commercial equipment for television

transmissions, as well as consumer appliance equipment, such as STBs and other

home based or home networked devices. These architectures included computer

control systems for network and associated network device command and control,

and for management of content distribution and consumer appliance functions. For

example, these systems are addressable. “Addressability” enables the system

operator to control the delivery of content and network services, network sourcing

and receiving devices (e.g., servers and transmission equipment, and PC or STB

receivers), and the consumer experience. Examples are delivery of software or

data files, for which purchased or subscription services or content is available,

electronic program guides, and a la carte functions such as pay-per-view (PPV) and

video-on-demand (VOD).

8. I have been a participant in the development and evolution of modern

consumer digital audio and digital video communications systems and

technologies. In 1980, Oak was developing and demonstrating high fidelity digital

audio transmission systems for broadcast applications. At the same time,

SONOS 1018 - Page 4

4

consumer electronics companies, such as Philips, Toshiba, Sony and others, were

doing research that eventually led to the audio compact disc. As a member of the

research group at Oak, we shared ideas and information about sampling rates,

analog-to-digital and digital-to-analog conversion, and compatibility between

consumer storage/playback and broadcast applications. In 1991, my employer,

TV/COM, and I began to participate in the newly formed International

Organization for Standardization (ISO) MPEG-2 digital television standards

initiatives, and in the following year, we participated in both the European Digital

Video Broadcast (DVB) and U.S. Advanced Television Systems Committee

(ATSC) forums (which were based upon MPEG-2).

9. In the mid-1990s, as the technologies and standards in support of

digital television (DTV) moved towards implementation, the dawn of the Internet

age also arrived. This had a dramatic impact on the way broadband systems

engineers like myself began to plan for the future. This is because the concept of

convergence—the melding of traditional broadband communications systems and

equipment, computers, and computer networks, with that of the

telecommunications worlds—was changing the communications infrastructure and

technology landscape. When television distribution went all-digital, the

information of television became simply “data”—and it became possible for the

technologies of digital television, computers and computer networks, and the

SONOS 1018 - Page 5

5

telephony industry (which was in the midst of its transition to digital infrastructure

that began in the 1970s) to coalesce. Support for on-line and Internet services

demanded a high performance two-way data transmission capability, and so

broadband network providers began to upgrade their distribution infrastructures

accordingly.

10. In conjunction with this convergence, as TV/COM’s Chief

Technology Officer, I directed the expansion of our network products into

broadband data communications generally, from its initial focus on digital

television. Networks became more advanced in order to support real-time

interaction between consumers and various information sources, and interactive

and on-line applications led to rapid adoption of client-server information access

architectures. The ubiquitous set top box began to evolve from a minimalist

appliance towards its current status as a communications hub of the consumer’s

media room. This was supported by the exponential increase in the capabilities of

powerful yet inexpensive integrated circuits, such as microprocessors, and memory

that allowed STBs to become more software driven and support advanced digital

signal processing (DSP) needs.

11. This increase in processing and computing horsepower has been

instrumental in supporting the desire for new features and services offered by

consumer appliances, such as personal computers, set top boxes (STB), digital

SONOS 1018 - Page 6

6

video recorders (DVR), and smart TVs, which since the mid-1990s have steadily

become more and more interactive. Interactivity takes place between both the

consumer and the appliance as well as between the consumer and the information

sources, such as cable head ends and/or networked databases by way of the

appliance—typically referred to as a client-server relationship. For example,

interacting with electronic program guides (EPG) and on screen displays (OSD)

enables the consumer to navigate around literally hundreds of channels and

program offerings which would otherwise be a nightmare to manage. The same

guides and displays support interactive-dependent services, such as pay-per-view

(PPV) and video-on-demand (VOD).

12. As vice president of engineering at Oak and chief technology officer

TV/Com, I was directly involved in developing cable head end (CHE) equipment

for analog and digital television delivery. Of particular importance to the matters of

this case, at TV/Com we designed compression, multiplexing and transmission

systems for digital television (DTV) applications, and with our partner companies

(Nokia, Hyundai, Tee-Comm Electronics and Samsung) we developed consumer

set top box (STB) receivers—all based on the digital video broadcast (DVB) and

ISO MPEG-2 international standards. While these products did not include VOD

content storage and video “pumps” as in the asserted ‘441 patent, they did include

the same types of underlying DTV technology elements such as MPEG-2

SONOS 1018 - Page 7

7

compression and packetized transport stream (TS) generation and multiplexing,

and buffering challenges including real-time streaming and PCR (and PMT/PAT,

PTS, adaptation fields, etc.) elements.

13. In my consulting work I have continued to work with technologies,

equipment and network infrastructures for content generation, distribution, and

consumption. My current work involves both traditional and newly developing

architectures and distribution channels. As an example of the latter, I am the chief

security systems architect on behalf of the six major Hollywood studios for their

“Digital Cinema Initiatives” (DCI) consortium. DCI has developed and evolved

the requirements and specifications for transitioning first run theatrical movie

releases from film to digital files for distribution and exhibition display. I am

responsible for all elements of command and control and digital rights

management (DRM) for the digital cinema system design and implementation. I

also represent DCI at the Society of Motion Picture and Television Engineers

(SMPTE), which has/is developed/ing a set of internationally recognized standards

for global adoption of digital cinema. The migration to all-digital distribution

impacts other content distribution channels, such as early window release for

hospitality, airplane, and cable/satellite video-on-demand (VOD), as well as newer

so called “over-the-top” distribution channels based on Internet distribution. I

SONOS 1018 - Page 8

8

have also been a strategy and technology consultant to content management and

distribution entities in these areas.

14. My consulting practice today includes a balance of technology and

systems engineering services and assistance to the legal community as a

technology consultant and/or expert witness. I have been accepted to provide, and

have provided, expert testimony in the areas of multimedia technologies such as

digital television and appliances, and associated networks as used for content

management and delivery on many occasions. A case list of my assistance to the

legal community over the past five years is attached as Appendix B.

15. I am currently a member of the Society of Cable &

Telecommunications Engineers (SCTE), the Society of Motion Picture and

Television Engineers (SMPTE) and the Institute of Electrical and Electronic

Engineers (IEEE). I have previously been a member of the International

Organization for Standardization (ISO), Motion Picture Experts Group (MPEG),

the Digital Video Broadcast (DVB) group and as chief technology officer of

TV/Com International, a voting member of the Advanced Television Systems

Committee (ATSC).

16. I am an inventor on U.S. Patent No. 4,531,020, issued July 23, 1985

and entitled “Multi-layer Encryption System for the Broadcast of Encrypted

Information” and U.S. Patent No. 5,113,440, issued May 12, 1992 and entitled

SONOS 1018 - Page 9

9

“Universal Decoder.” I have participated in U.S. patent prosecution, and have a

general understanding of the process, and of the novelty and non-obviousness

requirements for patentability.

17. Over many years I have published and/or presented a number of

articles and papers related to content/information creation,

transmission/distribution, and reception/consumption in various media sectors,

including cable, satellite, broadcast/wireless, Internet, and digital cinema.

Attached as Appendix C is a list of my publications.

III. COMPENSATION

18. I am being compensated for the time that I spend consulting on this IPR

at a rate of $350 per hour. My compensation is not dependent upon the outcome of

this IPR.

IV. MATERIALS CONSIDERED

19. In developing my opinions for this IPR, I reviewed, among other things,

the ‘441 Patent, its prosecution history, and numerous prior art references in the

relevant field of technology.

V. LEGAL STANDARDS

20. I am not an attorney, and I will offer no opinions on the law.

However, I have an understanding of several principles concerning invalidity (and

other legal issues). I understand that a patent claim can be invalid under the United

SONOS 1018 - Page 10

10

States patent laws for various reasons, including, for example, anticipation or

obviousness in light of the prior art. In arriving at my opinions, I have applied the

following legal standards and analyses:

A. Anticipation

21. Regarding the legal doctrine of anticipation, my understanding is as

follows.

22. A claim is anticipated if the claimed invention was known or used by

others in the United States, or patented or described in a printed publication in the

United States or a foreign country, before the patentee invented the claimed

invention.

23. Also, a claim is anticipated if the claimed invention was patented or

described in a printed publication in the United States or a foreign country or in

public use or on sale in the United States, more than one year prior to the date that

the patentee filed an application for patent directed to the claimed invention.

24. Additionally, a claim is anticipated if the claimed invention was

described in either (1) a published patent application filed by another in the United

States before the patentee invented the claimed invention or (2) a patent granted on

an application for patent by another filed in the United States before the patentee

invented the claimed invention.

25. Anticipation must be found in a single reference, device, or process.


11

26. For a prior art reference to anticipate, each claim limitation, as

properly construed, must be disclosed, either expressly or inherently, in the prior

art reference, and the claimed arrangement or combination of those limitations

must also be disclosed, either expressly or inherently, in the prior art reference.

27. Although anticipation cannot be established through a combination of

references, additional references may be used to interpret an allegedly anticipating

reference by, for example, indicating what the allegedly anticipating reference

would have meant to one of ordinary skill in the art. For the claim to be

anticipated, however, the additional references must make clear that the missing

descriptive matter is inherent to the features described in the prior art references.

In other words, the missing feature is necessarily or implicitly present in the

allegedly anticipating reference.

28. For a prior art device to anticipate, each claim limitation, as properly

construed, must be embodied in the prior art device.

29. If a prior art device, in its normal and usual operation, would

necessarily perform the method claimed, then the method claimed is anticipated by

the prior art device. When the prior art device is the same as a device described in

the specification for carrying out the claimed method, it can be assumed the device

will inherently perform the claimed process.


12

B. Obviousness

30. Regarding the legal doctrine of obviousness, my understanding is as

follows.

31. A claim may be invalid even if each and every claim limitation is not

present or disclosed in a single prior art reference or device.

32. Under the doctrine of obviousness, a claim may be invalid if the

differences between the invention and the prior art are such that the subject matter

as a whole would have been obvious at the time the invention was made to a

person having ordinary skill in the art to which the subject matter pertains.

33. A person of ordinary skill in the art is presumed to have knowledge of

the relevant prior art at the time of the claimed invention.

34. Obviousness is based on the scope and content of the prior art, the

differences between the prior art and the claim, the level of ordinary sill in the art

and secondary indicia of obviousness and non-obviousness to the extent such

indicia exist.

35. The scope of the prior art comprises any prior art that was reasonably

pertinent to the particular problems the inventor faced.

36. The determination of whether patent claims would have been obvious

to a person of ordinary skill in the art and, therefore, invalid, is not governed by

any rigid test or formula. Instead, a determination that a claim is obvious is based


13

on a common sense determination that the claimed invention is merely a

combination of known limitations to achieve predictable results.

37. Any of the following rationales are acceptable justifications to

conclude that a claim would have been obvious:

A. the claimed invention is a combination of known prior art methods to

yield predictable results;

B. the claimed invention is a substitution of one known element for

another to obtain predictable results;

C. the claimed invention uses known techniques to improve similar

devices (methods, or products) in the same way;

D. the claimed invention applies a known technique to a known device

(method, or product) ready for improvement to yield predictable

results;

E. the claimed invention was “obvious to try” – choosing from a finite

number of identified, predictable solutions, with a reasonable

expectation of success;

F. there is known work in one field of endeavor that may prompt

variations of it for use in either the same field or a different one based

on design incentives or other market forces if the variations would

have been predictable to one of ordinary skill in the art; or


14

G. there is some teaching, suggestion, or motivation in the prior art that

would have led one of ordinary skill in the art to modify the prior art

reference to combine prior art teachings to arrive at the claimed

inventions.

38. In addition, a claim can be obvious in light of a single reference,

without the need to combine references, if the claim is obvious in view of the

common sense or knowledge of one of ordinary skill in the art.

39. An analysis of whether a claimed invention is obvious must not rely

on a hindsight combination of prior art. Instead, the analysis must proceed in the

context of the time of the invention or claimed priority date and consider whether

the invention as a whole would have been obvious to a person of ordinary skill in

the art, taking into consideration any interrelated teachings of the prior art, the

effects of demands known to the design community or present in the marketplace,

and the background knowledge possessed by a person having ordinary skill in the

art, all in order to determine whether there was an apparent reason to combine any

known elements in the fashion claimed by the patent at issue.

40. Secondary indicia of non-obviousness may include, for example:

A. a long felt but unmet need in the prior art that was satisfied by the

invention of the patent;

B. commercial success of a product or process covered by the patent;


15

C. unexpected results achieved by the invention;

D. praise of the invention by others skilled in the art;

E. taking of licenses under the patent by others; and

F. deliberate copying of the invention.

41. I also understand that these secondary considerations are only relevant

to obviousness if there is a connection, or nexus, between them and the invention

covered by the patent claims. For example, commercial success is relevant to

obviousness only if the success of the product is related to a feature of the patent

claims. If commercial success is due to advertising, promotion, salesmanship or

the like, or is due to features of the product other than those claimed in the patent-

in-suit, then any commercial success should not be considered an indication of

non-obviousness.

42. In forming my opinions on obviousness, I have not seen any evidence

that supports any secondary considerations.

C. Priority Date and Date of Invention

43. I understand that multiple dates may be relevant to a claimed

invention and the prior art that may be asserted against a claim.

44. The ‘441 Patent was filed as U.S. Patent Application No. 09/226,169

(“the ‘169 Application”) on January 7, 1999, and issued on October 29, 2002. The

‘169 Application claims the benefit of Provisional Application No. 60/112,866


16

filed on December 18, 1998. Thus, I understand that the earliest effective filing

date for Claims 1-4 of the ‘441 Patent is December 18, 1998.

45. I am informed that in the underlying litigation, D&M has not

indicated a priority date or date of invention prior to December 18, 1998.

Therefore, it is my understanding that for purposes of these IPRs, the priority date

and date of invention for the ‘441 Patent is December 18, 1998, and I have

analyzed Claims 1-4 of the ‘441 Patent using this December 18, 1998 priority date

and date of invention.

VI. CLAIM CONSTRUCTION

46. My opinions related to the issue of patentability of the ‘441 Patent are

based upon the claim constructions set forth in Sonos’s Petition for Inter Partes

Review of the ‘441 Patent (“the Petition”), which are also set forth below:

• “buffers”: “buffers” are a set of storage elements (or regions within a

single memory) that serve as intermediate repositories for data. See,

e.g., SONOS 1010, p. 3 (defining a “buffer” to mean “[a] region of

memory reserved for use as an intermediate repository in which data

is temporarily held while waiting to be transferred between two

locations or devices.”); SONOS 1011, p. 3-4 (defining a “buffer” to

mean “[a] storage area in a computer for data that is used

to compensate for a speed difference when transferring data


17

from one device to another.”). This construction is consistent with the

ordinary meaning of “buffers” disclosed in the ‘441 Patent. See, e.g.,

SONOS 1001, 5:48-49 (“DRAM buffers 38 may be provided by a

conventional DRAM chip of, e.g., 64 megabytes.”).

• “a control unit”: a component, such as a controller or processor, that

performs an arbitrating or regulating function. See, e.g., SONOS

1010, p. 4 (“A device or circuit that performs an arbitrating or

regulating function.”); SONOS 1011, p. 5 (“That section of an

automatic digital computer that directs the sequence of operations,

interprets coded instructions, and sends the proper signals to the other

computer circuits to carry out the instructions.”). This construction

is consistent with the ordinary meaning of “control unit,” referred to

as “control & status logic” and a “processor,” disclosed in the ‘441

Patent. See, e.g., ‘441 Patent, 5:23-28 (“Control & status logic 32

provides the interface to the ‘outside world,’ receiving commands and

passing status to other elements within digital media retrieval system

10. Control & status logic 32 processes these system level commands,

generating local commands as required to the other functional

elements of video pump 12.”); id. at 5:53-55 (“Processor 42 controls

the operation of video pump 12 . . . .”).


18

• “coupled to”: the ordinary meaning and broadest reasonable

interpretation of “coupled to” encompasses both direct and indirect

connection. See, e.g., Bradford Co. v. Conteyor N. Am., Inc., 603

F.3d 1262, 1270-71 (Fed.Cir.2010) (construing “coupled to” to allow

for both direct and indirect attachments); Oceaneering Int'l, Inc. v.

Trendsetter Eng'g, Inc., No. CV H-16-2797, 2016 WL 7388390, at *7

(S.D. Tex. Dec. 20, 2016) (holding that “‘coupled to’ should be given

its ordinary meaning, which would include both direct and indirect

connection.”). Moreover, the ‘441 Patent does not require any direct

coupling.

• “a real-time pump … to detect the one of the bit rates used to encode

the stored signals on each of the multiple recordings and to output

transport stream packets”: a component that detects the encoded bit

rates of the stored signals and outputs transport stream packets. See,

e.g., ‘441 Patent, 1:10-2:15, 2:47-53, 2:61-3:11, 3:36-5:2, 5:19-20,

5:29-52, 6:6-56, 8:56-67.

• “output over the network multiplexed packet isochronous signals”:

transmitting over the network a plurality of separate signals as a single

combined signal, the separate signals each having a respective

constant bit rate. See, e.g., id. at 1:10-2:15 (“. . . a constant bit rate (or


19

isochronous) . . . constant bit rate delivery is generally termed

Isochronous Streaming . . .”), 2:47-53, 2:61-4:26, 4:40-46, 4:51-5:18,

5:42-52, 5:66-8:55, and 9:1-3; see also SONOS 1012, p. 3 (defining

“multiplexing” to mean “simultaneous transmission of two or more

signals along a common path”); SONOS 1011, p. 5 (“A technique

used in communications and input/output operations for transmitting a

number of separate signals simultaneously over a single channel or

line.”).

• “each stream of the packet isochronous signals on the network

having an average bit rate of the one of the bit rates used to encode

the stored signals corresponding thereto”: the average bit rate of

each (packet isochronous) signal stream on the network being equal to

the corresponding stored stream’s encoded bit rate. See, e.g., ‘441

Patent, 1:18-22 (“When video that has been compressed using one of

the standards of the Moving Pictures Expert Group (MPEG) and

stored . . . a constant bit rate (or isochronous) stream is created.”);

1:34-38 (“The MPEG compression standards are used worldwide for

constant bit rate digital video encoding. . . . This constant bit rate

delivery is generally termed Isochronous Streaming.”).


20

• “a channel timing module, coupled to said real-time pump, to

control timing of output of the transport stream packets”: a module

that generates the timing information required for outputting transport

stream packets from the video pump. See, e.g., id. at 5:66-6:1

(“Channel timing module 40 generates the timing required for

maintaining data rates for each channel output from video pump 12.”).

Under the broadest reasonable construction standard, no specific

structure/architecture for the “channel timing module” is required by

any of the Challenged Claims.

47. To the extent that a claim construction is not provided in the Petition

for a particular claim term or element, I used the ordinary and customary meaning

of the word(s), as would be understood by one of ordinary skill in the art in the

context of the field of the invention at the time of the invention, to construe such a

claim term or element.

VII. LEVEL OF ORDINARY SKILL IN THE ART

48. Based upon my personal knowledge and experience in the fields of

video-on-demand and digital television distribution systems (inclusive of media

encoding and the technical standards used therewith), in my opinion, a person of

ordinary skill in the art relevant to the ‘441 Patent at the time of the alleged

inventions, would have the equivalent of a four-year degree from an accredited


21

institution (usually denoted as a B.S. degree) in computer science, computer

engineering, electrical engineering, or the equivalent, and approximately 2-4 years

of professional experience in the fields of video-on-demand and digital television

distribution systems (inclusive of media encoding and the technical standards used

therewith), or an equivalent level of skill and knowledge.

49. In forming the opinions set forth in this declaration, I applied this

level of ordinary skill in the art.

VIII. THE ‘441 PATENT

50. The ‘441 Patent is directed to video servers with specialized

components for retrieving encoded (digitally compressed) video data from storage

devices and outputting that data to a high speed delivery network for transport to

receivers (e.g., a set top box). See, e.g., ‘441 Patent, Abstract, 1:11-15, 2:47-3:11.

51. More specifically, Claim 1 of the ‘441 Patent is directed to an

apparatus (i.e., video pump) that simultaneously streams multiple recordings

transmitted from storage devices over a network. See, e.g., id. at 2:64-3:2 (“[The]

purpose [of the apparatus] is to retrieve MPEG audio/video streams from various

storage devices . . . and place this data into the high speed digital network 18 for

distribution to set top devices 20 at the specific rate required for each stream.”).

52. Specifically, Claim 1 recites:


22

1. An apparatus for simultaneously reproducing multiple recordings from storage devices for transport on a network, comprising: buffers to receive stored signals from the multiple recordings, each recording containing stored signals encoded at one of a plurality of bit rates; a control unit, coupled to said storage devices, to receive requests to reproduce the multiple recordings and to control playback of the stored signals by the storage devices; a real-time pump, coupled to said buffers and said control unit, to detect the one of the bit rates used to encode the stored signals on each of the multiple recordings and to output transport stream packets, each transport stream packet based on the stored signals from one of the multiple recordings; and a network interface, coupled to said control unit and said real-time pump, to receive the transport stream packets in corresponding queues and to output over the network multiplexed packet isochronous signals corresponding to the stored signals on the multiple recordings requested to be reproduced, each stream of the packet isochronous signals on the network having an average bit rate of the one of the bit rates used to encode the stored signals corresponding thereto.

53. A functional block diagram of the video pump is shown in Figure 2:


23

54. As shown in FIG. 2, the apparatus has “four main functional

components: RAID streaming logic 30, video pump control and status 32, real-time

pump 34, and ATM adapter 36.” Id. at 4:28-30. As further described in the

specification, the “video pump control and status 32” processes “system level

commands, [and] generate[s] local commands as required to the other functional

elements of video pump 12.” Id. at 5:26-28. The “RAID streaming logic 30”

receives “start and stop commands, as well data addresses from video pump

control and status 32.” Id. at 4:38-40. Further, the “RAID streaming logic 30

fetches data from [storage devices, such as] RAID array 14 [in Figure 1].” Id. at

4:36-38. The “data” is then “placed in a DRAM buffer 38 where it is read by real-


24

time pump 34,” id. at 4:37-38, and passed to “buffers in ATM adapter module 36 .

. .” Id. at 4:54-56. The “ATM adapter module 36 . . . packetizes this data into

ATM packets, and passes this data stream on to [the network] for distribution to set

top devices 20.” Id. at 4:62-65. As defined by the specification, the stored data is

“isochronous data [which] includ[es] both audio and video” is generally referred to

as either “video” or “data” throughout the specification for “simplicity’s sake.” Id.

at 3:9-11.

55. In addition, the ‘441 Patent discloses that “[t]he encode rate is the rate

at which the set top device decoder will use the data, and it is therefore the rate at

which video pump 12 must send the data to the decoder.” Id. at 4:43-46. As

recited in Claim 1, the ‘441 Patent ensures that the encode and decode rates are the

same by requiring that each video stream “output over the network” has an

“average bit rate” that is “isochronous [constant]” and the same as “the bit rate[]

used to encode the stored signals corresponding thereto.” Id. at Claim 1.

56. Claim 2 of the ‘441 Patent is directed to the video pump, wherein the

“networking interface outputs each stream of the packet isochronous signals with

the average bit rate within one bit per second of the one of the bit rates used to

encode the stored signals corresponding thereto.” Id. at Claim 2.


25

57. Claim 3 of the ‘441 Patent is directed to the video pump, wherein the

“network interface outputs each stream of the packet isochronous signals with a

jitter of less than two milliseconds.” Id. at Claim 3.

58. The video pump can “operate on blocks of data as small as 2 MPEG

Transport Packets (376 bytes) to minimize jitter imposed by the distribution of

video within the system and to comply with ATM Forum requirements for MPEG2

transmission.” Id. at 4:22-26.

59. Claim 4 of the ‘441 Patent requires “a channel timing module . . . to

control timing of output of the transport stream packets.” Id. at Claim 4.

60. According the ‘441 Patent’s specification, the “[c]hannel timing

module 40 generates the timing required for maintaining data rates for each

channel output from the video pump 12.” Id. at 5:66-6:1. The channel timing

module includes “primary and secondary counters 60, 62, and status logic 64

[which] are replicated for each of the 80 channels supported by [the] video pump

[].” Id. at 6:6-9. Conceptually, the “primary and secondary counters 60, 62 [are]

timers [that] generate a timing mark for [the] video pump [].” Id. at 6:14-16.

Based on the timing mark, the video pump “determine[s] when to ‘pump’ [ ] data

by reading it from the DRAM buffer and passing it to ATM adapter module 36.”

Id. at 6:23-25.


26

61. Claim 4 of the ‘441 Patent does not require any of this

structure/architecture, or any other structure/architecture, for the channel timing

module.

62. The extensive prior art, as shown and described in the references

discussed herein, illustrates that Claims 1-4 of the ‘441 Patent were anticipated

and/or rendered obvious at the time of the purported invention of the ‘441 Patent,

i.e., December 18, 1998.

IX. THE MPEG-2 STANDARD

63. The “Information Technology – Generic Coding of Moving Pictures

and Associated Audio: Systems,” ISO/IEC 13818-1, April 1995 (“MPEG-2

Standard”), was well known prior to the filing of the ‘441 Patent. I understand that

the MPEG-2 Standard is prior art to the ‘441 Patent because the MPEG-2 Standard

was published in 1995, more than one year prior to the ‘441 Patent’s earliest

effective filing date of December 18, 1998.1

64. The MPEG-2 Standard is used to encode “one or more elementary

streams of video and audio, as well as other data, into single or multiple streams

which are suitable for storage or transmission.” MPEG-2 Standard, p. x. As 1 ISO/IEC 13818-1 is the so-called MPEG-2 “Systems” standard, and as of the date of publication was accompanied by two other standards: 13818-2 and 13818-3 for video and audio encoding respectively. These formed the basis of digital television as used throughout the world today. I (and my employer TV/Com) was a contributing member of the ISO MPEG-2 committee from 1991 through 1998.


27

explained below, the MPEG-2 Standard teaches the claimed aspects of Claims 1-4

of the ‘441 Patent.

65. In MPEG-2, a program (e.g., TV show, movie, etc.) is represented by

a “Program Stream” (“PS”), which is typically comprised of compressed video and

audio bit streams called “elementary streams.” Id. at Introduction, p. x-xi; see also

id. at Section 0.1, p. xi-xiii; Section 0.2, p. xiii-xiv; Section 2.1.41, p. 5; Section

C.5, p. 97. MPEG-2 systems usually transmit a plurality of PSs, by multiplexing

the PSs into a “Transport Stream” (“TS”), referred to as a multi-program

multiplex. Id; see also Section 0.8.2, p. xvi (“Synchronization among multiple

elementary streams is accomplished with Presentation Time Stamps (PTS) in the

Program Stream and Transport streams.”). The respective PSs can be transmitted

independent of each other having independent timing and time references with

different encoded bit rates as well. Id. at Section D.15, p. 113; Section 0.1, p. xi.

As such, the recipient of an MPEG-2 TS will receive the entire plurality of PSs,

and the so-called “System Target Decoder” will parse the TS to identify and

capture the components of the desired selected PS. Id. at Section D.8, p. 106.

66. The MPEG-2 Standard provides all the timing ingredients necessary

for the System Target Decoder to process the selected program:

In the Program Stream, the clock reference field is called the System Clock Reference or SCR. In the Transport Stream, the clock reference field is called the Program Clock Reference or PCR. In general, the


28

SCR and PCR definitions may be considered to be equivalent, although there are distinctions. The remainder of this sub-section uses the term SCR for clarity; the same statements apply to the PCR except where otherwise noted. The PCR in Transport Streams provides the clock reference for one program, where a program is a set of elementary streams that have a common time base and are intended for synchronized decoding and presentation. There may be multiple programs in one Transport Stream, and each may have an independent time base and a separate set of PCRs.

Id. at Section D.9, p. 107 (emphasis added). Thus, the MPEG-2 Standard teaches

the output of “transport streams” that are “multiplexed,” with each stream having

its own “encod[ing] at one of a plurality of bit rates,” as recited in Claim 1 of the

‘441 Patent.

67. Annex D of the MPEG-2 Standard addresses the end-to-end MPEG-2

timing model. The MPEG-2 Standard teaches “constant end to end delay” with

average bit rates that are “the same at the decoder as they are at the encoder”:

ISO/IEC 13818-1 Systems embodies a timing model in which all digitized pictures and audio samples that enter the encoder are presented exactly once each, after a constant end to end delay, at the output of the decoder. As such, the sample rates, i.e. the video frame rate and the audio sample rate, are precisely the same at the decoder as they are at the encoder. This timing model is diagrammed in the following figure:


29

Figure D-1 – Constant delay model

As indicated in the figure, the delay from the input to the encoder to the output or presentation from the decoder is constant in this model, while the delay through each of the encoder and decoder buffers is variable.

Id. at Section D.7, p. 104 (emphasis added) (footnote omitted).

68. These references to sample and frame “rates” means information (e.g.,

digitized and compressed audio and video) production and consumption rates—

i.e., data rates. As explained above, the MPEG-2 Standard states that such rates

are “precisely” the same at each end.

69. To realize the constant delay and synchronize the presentation of

video and audio, the MPEG-2 Standard provides several time references and

stamps:

There is a single, common system clock in the encoder, and this clock is used to create time stamps that indicate the correct presentation and decoding timing of audio and video, as well as to create time stamps that indicate the instantaneous values of the system clock itself at sampled intervals. The time stamps that indicate the presentation time of audio and video are called Presentation Time Stamps (PTS); those that indicate the decoding time are called

Video In

Audio In

Encoder

Encoder

Buffer

Buffer

System Coder and Multi- plex

Storage or Trans- mission

System decoder and de- multi- plex

Buffer

Buffer

Decoder

Decoder

Constant delay

Video

Out

Audio

Out

Variable Delay

Variable Delay

Constant delay


30

Decoding Time Stamps (DTS); and those that indicate the value of the system clock are called the System Clock Reference (SCR) in Program Streams and the Program Clock Reference (PCR) in Transport Streams. It is the presence of this common system clock in the encoder, the time stamps that are created from it, and the recreation of the clock in the decoder and the correct use of the time stamps that provide the facility to synchronize properly the operation of the decoder.

Id. at Section D.7, p. 105 (emphasis added).

70. The system clock of the MPEG-2 encoder provides the basis for

“channel timing module . . . to control timing” of the generation of time stamps

and output of transport stream packets, as recited in Claim 4 of the ‘441 Patent.

71. According to the MPEG-2 Standard, the decoder locally recreates the

encoder system clock, and then uses this equal (albeit delayed) clock along with

the time stamps and clock references to control the decoder’s signal processing and

ultimately the presentation:

Since the end-to-end delay through the entire system is constant, the audio and video presentations are precisely synchronized. The construction of System bit streams is constrained such that when they are decoded by a decoder that follows this model with the appropriately sized decoder buffers those buffers are guaranteed never to overflow nor underflow, with specific exceptions allowing intentional underflow. In order for the decoder system to incur the precise amount of delay that causes the entire end-to-end delay to be constant, it is necessary for the decoder to have a system clock whose frequency of operation and absolute instantaneous value match those of the encoder. The information necessary to convey the encoder’s system clock is encoded in the SCR or PCR; this function is explained below.


31

Id. (emphasis added).

72. Using the timing references and the locally recreated system clock

described in the MPEG-2 Standard, an MPEG-2 decoder can precisely perform the

decoding and presentation processes:

If the decoder’s clock frequency matches exactly that of the encoder, then the decoding and presentation of video and audio will automatically have the same rate as those at the encoder, and the end to end delay will be constant. With matched encoder and decoder clock frequencies, any correct SCR value can be used to set the instantaneous value of the decoder’s STC, and from that time on the decoder’s STC will match that of the encoder without the need for further adjustment. This condition remains true until there is a discontinuity of timing, such as the end of a Program Stream or the presence of a discontinuity indicator in a Transport Stream.


73. Accordingly, under the MPEG-2 Standard, the rate of compressed

video data generation by the encoder (i.e., the encoded rate) must be precisely

matched by the transmission channel, on average, in order for the decoder to be

able to precisely decode as required (i.e., at the same rate as the encoded rate).

More specifically, the transmission channel, which provides the bridge between the

encoder and decoder, implements a transfer bit rate. Of course, the transfer bit rate

cannot be any faster, on average, than the encoded bit rate, because the encoder

only produces data at the encoded rate. Likewise, the transfer bit rate cannot be


32

slower, on average, than the encoded bit rate, because the decoder buffer would

underflow—something that the MPEG-2 Standard says is not allowed to happen

(or else the system is broken). Thus, the only possible result is that for any given

MPEG-2 data stream, the average transfer rate for the transmission channel

between the encoder and decoder must be equal to the encode rate (which also

equals the decode rate).

74. It is important to understand how “on average” relates to the

transmission channel’s total capacity to carry information, and the channel’s

“instantaneous data rate.” MPEG-2 encoding rates are established by the user for a

given application. For example, the ‘441 Patent states: “… examples are streams

that are 3.282, 3.420, 6.144 and 6.000 megabits per second.” ‘441 Patent at 1:48-

49. In real world situations, a transmission channel’s capacity to carry data is

typically fixed, and does not change to follow the encoding rate. Rather, the

needed portion of the transmission channel’s total capacity will be appropriated to

the transmission of the encoded data, and any extra capacity can be used for other

purposes—for example to carry additional encoded streams. The actual

transmission bit rate or “instantaneous data rate” used by the transmission channel

is another factor. For example, the ‘441’s exemplary “OC-3” ATM transmission

rate is 155 megabits/second, which is obviously much greater than required for

carriage of any MPEG-2 data stream. So, the references herein to “on average”


33

refer to that part of transmission channel usage by a single MPEG-2 encoded

stream averaged over time.

75. The ‘441 Patent discloses “[t]he MPEG compression standards are

used worldwide for constant bit rate digital video encoding. Decoding of MPEG

video relies on the ability to deliver each bit from the encoder to the decoder with a

constant delay.”2 ‘441 Patent, 1:34-37. The MPEG-2 Standard teaches the ‘441

Patent’s disclosure that “[t]he encode rate is the rate at which the set top device

decoder will use the data, and it is therefore the rate at which video pump 12 must

send the data to the decoder.” ‘441 Patent, 4:43-46. The person of ordinary skill

in the art would of course recognize that the ‘441 Patent is not disclosing “video

pump novelty,” but merely echoing well-known MPEG-2 doctrine. In particular,

the MPEG-2 standard was directed to the transmission of both linear (live) and

recorded (stored) encoded content:

Many applications require storage and retrieval of ITU-T Rec. H.222.0†|†ISO/IEC 13818 bitstreams on various digital storage media (DSM). A Digital Storage Media Command and Control (DSM CC) protocol is specified in Annex A and part 6 of this Recommendation †|†International Standard in order to facilitate the control of such media.

2 The ‘441 patent references “MPEG,” and does not distinguish, for example, between MPEG-1 and MPEG-2 – both of which were internationally adopted standards as of the ‘441 Patent’s priority date. But MPEG-1 was not designed for broadcast or multi-channel / multi-stream applications, which is clearly the focus of the ‘441 Patent. Therefore, the person of ordinary skill would understand that all references to MPEG in the ‘441 Patent would be referring to MPEG-2.


34

MPEG-2 Standard, Section 0.10, p. xvii.

76. Moreover, because the bit rates of the encoder/transmitter and

receiver/decoder must be the same, and the encoder and decoder operate under a

constant delay, the MPEG-2 Standard teaches that video transport streams are

transferred from the encoder/transmitter to the receiver/decoder at a constant

average bit rate that is the same as the encoded bit rate. In other words, the

MPEG-2 Standard teaches that the encode, transfer, and decode rates must all

average out to be the same in order to have constant delay. In fact, if these rates

were not equal on average, the delay would vary and the decoder buffers would

over/under flow—which the MPEG-2 Standard discloses should not happen.

77. Thus, this disclosure in the MPEG-2 Standard reads directly on the

requirement in Claim 1 of ‘441 Patent for “isochronous signals on the network

having an average bit rate of the one of the bit rates used to encode the stored

signals.”

78. While Claim 2 of the ‘441 Patent relaxes the average bit rate to

“within one bit per second of the one of the bit rates,” this element is also met by

the MPEG-2 Standard that discloses rate averages that are equal—which is plainly

within one bit per second.


35

79. With respect to Claim 3 of the ‘441 Patent, the MPEG-2 Standard

teaches that real-world systems can create non-ideal situations, such as the

presence of jitter:

If a network or a Transport Stream re-multiplexor varies the delay in delivering the data stream from the encoder or storage system to the decoder, such variations tend to cause a difference between the values of the SCRs (or PCRs) and the values that they should have when they are actually received. This is referred to as SCR or PCR jitter . . . . The presence of SCR or PCR jitter may be caused for example by network transmission which incorporates packet or cell multiplexing or variable delay of packets through the network, as may be caused by queuing delays or by variable network access time in shared-media systems.

MPEG-2 Standard, Section D.10, p. 109 (emphasis added).

80. In particular, the above “cell multiplexing” and “variable delay” in

“shared-media systems” is the specific environment that the ‘441 Patent describes

for ATM transmission, and the MPEG-2 Standard clearly discloses both the causes

and effects of jitter in such an environment:

Multiplexing or re-multiplexing of Transport or Program Streams changes the order and relative temporal location of data packets and therefore also of SCRs or PCRs. The change in temporal location of SCRs causes the value of previously correct SCRs to become incorrect, since in general the time at which they are delivered via a constant delay network is not correctly represented by their values. Similarly, a Program Stream or Transport Stream with correct SCRs or PCRs may be delivered over a network which imposes a variable delay on the data stream, without correcting the SCR or PCR values. The effect is once again SCR or PCR jitter, with attendant effects on the decoder design and performance. The worst case amount of jitter


36

which is imposed by a network on the SCRs or PCRs received at a decoder depends on a number of factors which are beyond the scope of this International Standard, including the depth of queues implemented in each of the network switches and the total number of network switches or re-multiplexing operations which operate in cascade on the data stream.

Id. at Section D.10, p. 109-10 (emphasis added).

81. MPEG-2 further teaches that the impact of jitter can be reduced by the

addition of a “mechanism”:

In some applications it may be possible to introduce a mechanism between a network and a decoder in order to reduce the degree of jitter which is introduced by a network. Whether such an approach is feasible depends on the type of streams received and the amount and type of jitter which is expected.

Id. at 113 (emphasis added).

82. Like Annex D, Annex K also reinforces MPEG-2’s in-depth teachings

on the reduction and/or elimination of jitter and varying transmission bit rates. For

example, in Annex K, MPEG-2 discloses that jitter in ATM networks is of

particular interest:

. . . If a compliant system stream is transmitted over a jitter-inducing network, the true byte delivery schedule may differ significantly from the intended byte delivery schedule. In such cases it may not be possible to decode the system stream on such an idealized decoder, because jitter may cause buffer overflows or underflows and may make it difficult to recover the time base. An important example of such a jitter-inducing network is ATM.

Id. at Section K.0, p. 127 (emphasis added).


37

83. Annex K also provides an introduction to five different methods of

addressing network-induced jitter. The first three are directed to jitter smoothing

via adaptors within the network:

Three examples of network encoding to enable the building of jitter-smoothing network adapters are discussed in K.3. In the first example a constant bitrate system stream is assumed and a FIFO is used for jitter smoothing. In the second example the network adaptation layer includes timestamps to facilitate jitter smoothing. In the final example a common network clock is assumed to be available end-to-end, and is exploited to achieve jitter smoothing.


84. The last two are examples of changes to the decoder to better

accommodate jitter:

K.4 presents two examples of decoder implementations in which network-induced jitter can be accommodated. In the first example, a jitter-smoothing network adapter is inserted between a network’s output and an MPEG-2 decoder. The MPEG-2 decoder is assumed to conform to a real-time MPEG-2 interface specification. This interface requires an MPEG-2 decoder with more jitter tolerance than the idealized decoder of the STD.


85. In addition, the MPEG-2 Standard clearly indicates that less-is-best

for jitter, and it provides practical guidance on how much jitter is tolerable:

The amount of multiplex jitter allowed is not normatively bounded in this standard. However, 4 ms is intended to be the maximum amount of jitter in a well behaved system.



38

86. Thus, the MPEG-2 Standard’s disclosure of four milliseconds of jitter

or less reads on the “jitter of less than two milliseconds” recited in Claim 3.

87. Accordingly, the MPEG-2 Standard shows the timing characteristics,

necessary performance, and functionality recited in Claims 1-4 of the ‘441 Patent.

The ‘441 Patent is directed to normalizing the transmitted average bit rate to be

equal to (Claim 1) or close to (Claim 2) the encoded rate, minimizing jitter induced

by an ATM transmission network (Claim 3), and controlling the timing of the

output of transport stream packets (Claim 4). The MPEG-2 Standard disclosed all

of the functions in 1995, and a person of ordinary skill in the art would know all

about the MPEG-2 Standard as basic background to digital video technology as of

the ‘441 Patent’s earliest possible priority date in 1998.

88. Therefore, the MPEG-2 Standard’s basic teachings regarding

encoders, decoders, and system timing can be combined with any prior art

reference that implements MPEG-2 video processing.

X. SUMMARY OF OPINIONS REGARDING THE ‘441 PATENT 89. My opinions regarding the ‘441 Patent are summarized below and

explained in more detail in the sections that follow. In summary, Claims 1-4 of the

‘441 Patent are invalid, as either anticipated or rendered obvious, in view of:


39

A. U.S. Patent No. 5,892,535 to Allen et al. (“Allen”);3

B. U.S. Patent No. 5,737,747 (“Vishlitzky”) in view of the MPEG-2 Standard;4 and

C. “A Scalable Architecture for Video on Demand Servers,” Wu et al.,

IEEE Transactions on Consumer Electronics, Vol. 42, No. 4, November 1996 (“the Wu Article”) in view of the MPEG-2 Standard.5

90. Moreover, to the extent that the above references do not disclose the

“jitter of less than two milliseconds” recited in Claim 3 of the ‘441 Patent, it would

have been obvious to modify each of these references to add such a limitation, as

disclosed by U.S. Patent No. 6,181,711 (“Zhang”).

A. Claims 1-4 of the ‘441 Patent are Anticipated by Allen

91. I have been informed that Allen is prior art to the ‘441 Patent for at

least the reason that the filing date of Allen is December 13, 1996, which is before

the alleged December 18, 1998 invention date of the ‘441 Patent.

92. Having studied the ‘441 Patent and its file history, as well as Allen, it

is my opinion that Allen anticipates Claims 1-4 of the ‘441 Patent.

3 I understand that since Allen expressly incorporates the MPEG-2 Standard by reference, Allen therefore includes the disclosure of the MPEG-2 Standard. 4 By expressly disclosing the use of the MPEG-2 Standard, Vishlitzky provides express motivation for one of ordinary skill in the art to combine the teachings of the MPEG-2 Standard with the teachings of Vishlitzky. 5 By expressly disclosing the use of the MPEG-2 Standard, the Wu Article provides express motivation for one of ordinary skill in the art to combine the teachings of the MPEG-2 Standard with the teachings of the Wu Article.


40

Claim 1, ‘441 Patent

An apparatus for simultaneously reproducing multiple recordings from storage devices for transport on a network, comprising:

93. As an initial matter, I note that this language is the preamble for

Claim 1, and thus, is presumptively not a limitation. Accordingly, I understand

that the preamble of Claim 1 is not a limitation that needs to be found in the prior

art for purposes of invalidity.

94. Nevertheless, Allen discloses “an apparatus for simultaneously

reproducing multiple recordings from storage devices for transport on a network.”

95. For example, Allen is directed to a “hierarchical system” for

simultaneously “providing compressed and/or non-compressed digital and/or

analog video signals to be broadcast, multicast, or transmitted point-to-point, to

remotely located subscribers.” Allen at 1:14-17; see also id. at Abstract, 2:20-28,

3:52-54, 4:43-59, 5:7-6:10, 7:16-31, 9:53-10:15, 10:17-31, 10:65-11:12, 48:38-66,

FIGS. 2 and 27.

96. Accordingly, Allen discloses “an apparatus for simultaneously


buffers to receive stored signals from the multiple recordings, each recording containing stored signals encoded at one of a plurality of bit rates;

97. Allen discloses “buffers to receive stored signals from the multiple

recordings, each recording containing stored signals encoded at one of a plurality


41

of bit rates.” For instance, as explained below, Allen discloses “buffer memory

614,” to receive stored “transport streams” that are “provided at 1.5 to 9 Mbps.”

SONOS 1014, 36:26-29, 16:38-44, 21:25-38, 51:42-45, 52:20-34, FIGS. 6 and 35.

98. According to Allen, the “server interface unit(s) 204,” shown in FIGS.

6 and 35, includes a “buffer memory 614” that may “be divided into 16 or more

virtual queues [or buffers].” Id. at 21:3-8; see also 52:26-34. Specifically, Allen

discloses that the “[b]uffer memory 614 serves as intermediate storage, in that the

incoming transport stream is held in 2 Mbyte queues until the data is required by

the distribution network interface units 206. Accordingly, the buffer memory 614

serves to receive and divide the interleaved transport stream of incoming MPEG-2

data for delivery to the distribution network interface units 206.” Id. at 36:26-29.

99. Moreover, Allen also discloses that the number of blocks or queues

within the buffer memory 614 may vary depending on the architecture of the

disclosed invention. See id. at 21:25-38 (“. . . One skilled in the art can appreciate

that the number of queues (and perhaps the physical size of the buffer memory

614) can vary if the server interface unit 204 communicates with more or less than

eight (8) distribution network interface units 206 or if the server interface unit 204

is used for more or less than eight (8) channels.”).

100. FIG. 35 of Allen illustrates an example operation of the buffer

memory:


42

Id. at FIG. 35.

101. With respect to FIG. 35, Allen discloses that the buffer memory 614

receives, via the “video pump process 1174,” transport streams from the “media

database 1008c.” Id. at 52:20-34. In particular, the “video pump process 1174 . . .

provides a transport stream (at a controlled rate[ ]) to the server interface 204.” Id.

In turn, the transport stream is stored “in an appropriate queue of the buffer

memory 614.” Id. According to Allen, “storage devices of the media server,” such

as media database 1008c, “store files of media data which has been encoded in

accordance with a compression standard and which includes audio packets and


43

video packets.” Id. at 11:2-5. Furthermore, “each transports stream [is] provided

at 1.5 to 9 Mbps (i.e., up to 72 Mbps).” Id. at 51:42-45.

102. As explained above, the MPEG-2 Standard, which Allen incorporates

by reference, and which is therefore included in the disclosure of Allen, also

discloses the use of “buffers” for encoded video signals. See Section IX.

103. Thus, Allen directly reads on the “buffers” arranged “to receive

stored signals from the multiple recordings” that are “encoded at one of a plurality

of bit rates” recited in Claim 1 of the ‘441 Patent.

a control unit, coupled to said storage devices, to receive requests to reproduce the multiple recordings and to control playback of the stored signals by the storage devices;

104. Allen discloses “a control unit, coupled to said storage devices, to

receive requests to reproduce the multiple recordings and to control playback of

the stored signals by the storage devices.” For instance, as explained below, Allen

discloses “processor(s) 1006,” coupled to “media storage devices 1008” that

includes “media database 1008c,” to receive requests to reproduce transport

streams from the “media database 1008c” and control playback of the transport

streams. See, e.g., Allen at 4:43-59, 8:62-9:5, 9:23-38, 29:16-33, 47:40-48:13,

FIGS. 10 and 11B.

105. In one embodiment, Allen discloses that the “local media server 202”

includes “processor(s) 1006.” Id. at 29:16-19. According to Allen, the


44

“processor(s) 1006 should have adequate processing speed to process packets of

MPEG-2 data, perform timing and control functions, perform rate adjustment

functions, respond to control signals, and perform administrative and maintenance

functions.” Id. at 29:23-27. As shown in FIG. 10, the “processor(s) 1006” is

coupled to the media storage devices 1008, which includes the media database

1008c (shown in FIG. 11B):

Id. at FIG. 10B; see also id. at 11:2-5 (“storage devices of the media server [202],”

which includes “media database 1008c,” “store files of media data which has been

encoded in accordance with a compression standard and which includes audio

packets and video packets”) and 29:29-33 (“The local media server 202 should


45

also include an adequate amount of memory to store audio, video, and private

application data files and to store instruction sets for execution by the processor(s)

1006.”).

106. As further illustrated in FIG. 11B below, one example function of the

processor(s) 1006 includes the “local request processing process 1330,” which

receives requests to reproduce streams from the media database 1008c of the local

media server 202 and control playback of the streams:

Id. at FIG. 11B.


46

107. With respect to FIG. 11B, Allen discloses that the “request interface

process 1328, carried out on one of the input/output ports 1012 of the local media

server 202, receives the subscriber request and routes it, via path 1332, to a local

request processing process 1330 . . . The local request processing process 1330 . . .

checks the media database 1008c to determine whether files of compressed media

data corresponding to the requested and/or scheduled programming are available at

the local media server 202.” Id. at 47:40-48:13.

108. This disclosure in Allen directly reads on the “control unit” arranged

“to receive requests to reproduce the multiple recordings and to control playback

of the stored signals by the storage devices” recited in Claim 1.

a real-time pump, coupled to said buffers and said control unit, to detect the one of the bit rates used to encode the stored signals on each of the multiple recordings and to output transport stream packets, each transport stream packet based on the stored signals from one of the multiple recordings; and

109. Allen discloses a “real-time pump, coupled to said buffers and said

control unit, to detect the one of the bit rates used to encode the stored signals on

each of the multiple recordings and to output transport stream packets, each

transport stream packet based on the stored signals from one of the multiple

recordings.” For instance, Allen discloses a “video pump process,” coupled to the

“buffer memory 619” and the “processor(s) 1006,” to (1) detect the one of the bit

rates, i.e. “1.5 to 9 Mbps,” used to encode the stored “transport streams,” and (2)


47

output the stored transport streams to the “distribution network interface unit.”

See, e.g., SONOS 1014, 11:46-12:6, 48:15-22, 51:42-45, 52:20-30, FIGS. 11B and

35.

110. According to Allen, a video pump process (1) “receives a request for

media data from a subscriber and/or an associated distribution network interface

unit” and (2) “generates, in response to the received request for media data, a query

for a scheduled media file and receives the scheduled media file in response to its

query.” Id. at 11:46-59. In turn, “the video pump process streams the media file to

the associated distribution network interface unit via the first communications path,

a server interface unit, and the second communications path.” Id.

111. In operation, Allen discloses that “video pump process 1174,” shown

in FIG. 11B above, “reads the appropriate media file [that has been encoded] from

the media database 1008c, and provides a transport stream (at a controlled rate [])

to the server interface 204 via one of the server interface unit interface processes

1164 and path 1113 . . .” Id at 52:20-30. In order to output the transport stream at

the encoded rate, the “video pump process 1174” must “detect” the encoded rate

when it “reads the appropriate media file from the media database 1008c.” As

shown in FIGS. 10, 11B, and 35 above, the “video pump process 1174” is also

coupled to the “buffer 614” and the “processor(s) 1006.”


48

112. Thus, the “video pump process” disclosed in Allen reads directly on

the “real-time pump” recited in Claim 1 of the ‘441 Patent.

a network interface, coupled to said control unit and said real-time pump, to receive the transport stream packets in corresponding queues and to output over the network multiplexed packet isochronous signals corresponding to the stored signals on the multiple recordings requested to be reproduced,

113. Allen discloses “a network interface, coupled to said control unit and

said real-time pump, to receive the transport stream packets in corresponding

queues and to output over the network multiplexed packet isochronous signals

corresponding to the stored signals on the multiple recordings requested to be

reproduced.” For instance, Allen discloses a “digital streamer 3100,” coupled to

the “video pump process” and the “processor(s) 1006,” to (1) receive “up to eight

(8) single program transport streams 2112” in “(8) different channels” or queues

(corresponding to the transport streams that were stored in “media database 1008c”

explained above), and (2) “multiplex” the “program transport streams 2112” onto

an isochronous, “single multi-program transport stream” that is output over the

“digital distribution network.” See, e.g., id. at 7:43-49, 49:7-40, 49:65-50:2, 50:64-

67, 51:41-62, 52:6-19, FIGS. 31 and 35.

114. According to Allen, “digital distribution network interface unit (or

digital streamer) 3100 may be used to interface the system . . . with a digital

distribution network.” Id. at 49:7-10. As shown in FIG. 35 above, the digital


49

streamer 3100 is coupled to the local media server 202, which includes the video

pump process 1174 and the processor(s) 1006 (shown in FIG. 10 above).

115. According to Allen, “the digital streamer 3100 operates as a

concentrator to multiplex up to eight (8) single program transport streams 2112

corresponding to (8) different channels onto a single multi-program transport

stream (or ‘MPTS’).” Id. at 49:20-32; see also id at 49:65-50:2. In turn, the

“digital distribution network [ ] may carry the multiplexed transport streams to

further distribution networks or directly to subscribers [ ].” Id. at 51:56-62.

116. This disclosure reads directly on the “network interface,” which is

configured to “receive the transport stream packets in corresponding queues” and

“output over the network multiplexed packet isochronous signals corresponding to

the stored signals on the multiple recordings requested to be reproduced,” as

recited in Claim 1 of the ‘441 Patent.

each stream of the packet isochronous signals on the network having an average bit rate of the one of the bit rates used to encode the stored signals corresponding thereto.

117. Allen discloses “each stream of the packet isochronous signals on the

network having an average bit rate of the one of the bit rates used to encode the

stored signals corresponding thereto.” For instance, Allen discloses that the

“digital streamer 3100 can stuff [isochronous] transport stream packets” having a

“constant” bit rate of one of the bit rates, i.e. “1.5 to 9 Mbps,” used to encode the


50

stored transport streams. See, e.g., id. at 7:43-49, 49:7-40, 50:64-67, 51:41-62,

52:6-19, FIGS. 31 and 35.

118. FIG. 31 of Allen illustrates an example digital streamer 3100 in more

detail:

Id. at FIG. 31.

119. With respect to FIG. 31, Allen discloses that “the digital streamer

3100 includes an input parser 3102, an array of (e.g., eight (8)) field stores 3104,

an output multiplexer 3118, an output FIFO 3120, a streamer input/output card

3122, a microprocessor 3106, a dual port RAM 3178, static RAMs 3174, a


51

programmable RAM 3176, rate generators 3112, a program specific information

(or ‘PSI’) FIFO 3112, a data bus 3110, an address bus 3108, a clock distribution

circuit 3124, an optional DS3/ATM daughter card 3128, and an optional streamer

ATM input/output card 3130.” Id. at 49:20-32. The “DS3/ATM daughter card

3128” includes an “ATM segmentation and reassembly (or SAR) chip 3162,”

which “segments the MPEG-2 transport stream packets into ATM packets.” Id. at

50:43-50.

120. In operation, “a parse incoming transport stream process 3504, carried

out by input parser 3102, (i) separates the transport streams based on their PIDs,

(ii) stores the transport streams in an appropriate one of the frame buffers of the

field store array 3104, and (iii) makes rate data and PSI data available to the

microprocessor 3106.” Id. at 51:41-47.

121. Allen also discloses that “the digital streamer 3100 can stuff MPEG-2

transport stream packets onto the transport stream if downstream devices, such as a

QAM64 modulator for example, require a constant input of transport stream

packets.” Id. at 49:33-40 (emphasis added). One of ordinary skill in the art would

appreciate that a “constant” bit rate, i.e., a bit rate that is always the same and does

not change, is naturally also an “average” of that bit rate. Moreover, as noted

above, Allen expressly incorporates by reference the MPEG-2 Standard. Id. at 5:7-

56. As explained above, the MPEG-2 Standard teaches that video transport


52

streams are transferred from the encoder/transmitter to the receiver/decoder at a

constant average bit rate that is the same as the encoded bit rate. See Section IX.

122. Accordingly, the disclosure in Allen reads directly on “isochronous

signals on the network having an average bit rate of the one of the bit rates used to

encode the stored signals,” as recited in Claim 1 of the ‘441 Patent.


The apparatus as recited in claim 1, wherein said network interface outputs each stream of the packet isochronous signals with the average bit rate within one bit per second of the one of the bit rates used to encode the stored signals corresponding thereto.

123. As explained above, Allen discloses the apparatus as recited in Claim

1. Moreover, as noted above, while Claim 2 of the ‘441 Patent relaxes the average

bit rate to “within one bit per second of the one of the bit rates,” this element is

also met by Allen and the MPEG-2 Standard that discloses rate averages that are

constant and equal—which is plainly within one bit per second. See Section IX.;

see also Allen at 49:37-40 (“Finally, the digital streamer 3100 can stuff MPEG-2

transport stream packets onto the transport stream if downstream devices . . .

require a constant input of transport stream packets.”).


53


The apparatus as recited in claim 1, wherein said network interface outputs each stream of the packet isochronous signals with a jitter of less than two milliseconds.


1. Moreover, Allen expressly discloses avoiding any jitter via the output

multiplexer 3118 of the digital streamer 3100 described above:

Finally, the output multiplexer 3118 performs a PCR correction function to avoid the generation of jitter. More specifically, if the rate generators 3112 request the output of two (2) or more transport streams at the same time, only one transport stream is output and the other transport stream(s) is delayed. The output multiplexer 3118 tracks the delay of the output of the other transport stream(s) and updates the PCR(s) of the delayed transport stream(s) based on the delay, thereby canceling out any jitter that would otherwise be introduced by the delay.

Id. at 50:19-28 (emphasis added); see also id. at 49:33-36 (“digital streamer 3100

also adjusts the rates of each of the up to eight (8) transport streams such that jitter

(i.e., random variations in the transmission speed in the transport stream) is

reduced.”).

125. Accordingly, Allen discloses a system without any jitter, i.e., “zero”

jitter.

126. Furthermore, as noted above, the MPEG-2 Standard’s disclosure of

four milliseconds of jitter or less reads on the “jitter of less than two milliseconds”

recited in Claim 3. Thus, Allen and the MPEG-2 Standard (which Allen


54

incorporates by reference) discloses the elements recited in Claim 3 of the ‘441

Patent.


The apparatus as recited in claim 1, further comprising a channel timing module, coupled to said real-time pump, to control timing of output of the transport stream packets.


1. Moreover, Allen discloses “a channel timing module, coupled to said real-time

pump, to control timing of output of the transport stream packets.” See, e.g., id. at

52:48-59, FIGS. 31, and 35.

128. For instance, Allen discloses a “rate determination and generation

process 3508” to control timing of output of transport stream packets. See id. at

FIG. 35. According to Allen, the “multiplex buffered transport streams process

3512” of the digital streamer 3100, shown in FIG. 35, “receives timing signals, via

path 3514, from the rate determination and generation process 3508 . . .” Id. at

52:48-59. As further shown in FIG. 35, the “rate determination and generation

process 3508” within the digital streamer 3100 is coupled to the local media server

202, which includes the video pump process 1174. Id. at FIG. 35. Thus, the “rate

determination and generation process 3508” of Allen directly reads on the “channel

timing module . . . to control timing” of the encoder’s output of transport stream

packets, as recited in Claim 4 of the ‘441 Patent.


55

129. Moreover, as explained above, the system clock of the encoder

disclosed in the MPEG-2 Standard, and therefore disclosed in Allen, provides the

“channel timing module . . . to control timing” of the encoder’s output of transport

stream packets, as recited in Claim 4 of the ‘441 Patent.

B. Claims 1-4 of the ‘441 Patent Are Obvious Over Vishlitzky in View of the MPEG-2 Standard

130. I have been informed that Vishlitzky is prior art to the ‘441 Patent for

at least the reason that the filing date of Vishlitzky is June 10, 1996, which is

before the alleged December 18, 1998 invention date of the ‘441 Patent.

131. As previously noted, by expressly disclosing the use of the MPEG-2

Standard, Vishlitzky provides express motivation for one of ordinary skill in the art

to combine the teachings of the MPEG-2 Standard with the teachings of

Vishlitzky.

132. Having studied the ‘441 Patent and its file history, as well as

Vishlitzky, it is my opinion that Vishlitzky, in combination with the MPEG-2

Standard, renders obvious Claims 1-4 of the ‘441 Patent.






56



134. Nevertheless, Vishlitzky discloses “an apparatus for simultaneously


135. For example, Vishlitzky is directed to a “video file server” that is

“based on specialized hardware . . . designed to pull [encoded] video data out of

the disk storage and transmit the data downstream at the required data rate.”

Vishlitzky at 2:23-27. In Vishlitzky, “[t]he encoded audio and video data from

disk or RAM are combined into single isochronous streams.” Id. at 1:61-66; see

also id. at Abstract, 1:26-27, 1:50-56, 4:24-41, 27:11-15, FIG. 2.

136. Accordingly, Vishlitzky discloses “an apparatus for simultaneously



137. Vishlitzky discloses “buffers to receive stored signals from the

multiple recordings, each recording containing stored signals encoded at one of a

plurality of bit rates.” For instance, Vishlitzky discloses “buffers” (e.g., “buffer

91”) to receive video signals (e.g., “movies”) that have been encoded at different

bit rates (depending on “the method by which the video data are encoded (such as


57

MPEG I or MPEG II)”) and stored on one or more “integrated cached disk array[s]

23.” See, e.g., Vishlitzky at 2:42-43, 6:9-7:14, 17:36-42, 22:36-46, FIGS. 2 and 9.

138. For instance, FIGS. 2 and 9 of Vishlitzky illustrates an example

“video file server 20” that includes a “buffer 91” within the “integrated cached disk

array 23” to receive encoded video data:

Id. at FIGS. 2 and 9.

139. As shown in FIG. 2, “the video file server 20” includes “the integrated

cached disk array 23, the optional tape silo 24, the controller servers 28, 29, and

the stream servers 21.” Id. at 6:9-13. The “integrated cached disk array 23”

includes “cache memory 41” that is composed of “dynamic RAM cards,” which

stores video data, i.e., “encoded movie[s].” Id. at 6:55-7:14, 22:36-46 (“. . . The

amount of RAM memory for storing a movie depends on the length of the movie


58

(such as 90 minutes to 120 minutes) and the bit-rate (megabits per second) at

which the encoded movie has been delivered; this rate is typically a function of the

method by which the video data are encoded (such as MPEG I or MPEG II).”).

140. According to Vishlitzky, “[i]n FIG. 9, video data are transmitted

isochronously to a first network client from a buffer 91 in random access memory

(RAM) in a first one of the stream servers (21 in FIG. 2).” Id. at 17:36-39.

Vishlitzky discloses that “[t]he buffer 91 is filled by data fetched from the cache 41

of the integrated cached disk array (23 in FIG. 2),” and that “[t]he cache 41 is filled

by data prefetched from the disk array 47.” Id. at 17:39-42. In addition, Vishlitzky

states that a “buffer cache 62 composed of part of the random-access memory of

the stream servers 21 is used as a buffer for this data transfer.” Id. at 7:54-56.

141. Moreover, as explained above, the MPEG-2 Standard, which

Vishlitzky references, also discloses the use of “buffers” for encoded video signals.

Thus, the “buffers” disclosed in Vishlitzky, alone and/or in combination with the

MPEG-2 Standard, directly reads on the “buffers” arranged “to receive stored

signals from the multiple recordings” that are “encoded at one of a plurality of bit

rates” recited in Claim 1 of the ‘441 Patent.


59


142. Vishlitzky discloses “a control unit, coupled to said storage devices, to

receive requests to reproduce the multiple recordings and to control playback of

the stored signals by the storage devices.” For instance, Vishlitzky discloses

“processors” of the “stream servers 21” that are coupled to one or more “integrated

cached disk array[s] 23,” that receive “client request[s]” for “video data stream[s]”

stored on such arrays, and that control the transmission of the video data

“downstream at the required data rate” to the “network client 54.” See, e.g., id. at

2:63-66, 4:63-65, 5:22-61; 7:32-59, 23:5-8, FIGS. 2 and 4-5.

143. For instance, Vishlitzky discloses that “each of the stream servers 21 .

. . includes an Intel processor,” and that “software 60” is “executed by the

processors of the stream servers 21” and provides “a real-time processing

environment in the video file server (20 of FIGS. 1 and 2).” Id. at 4:63-65, 7:32-

35. According to Vishlitzky, the “software 60” includes a “kernel program 63 for

providing a real-time scheduler and an access control program for arbitrating

among conflicting service requests.” Id. at 7:52-59. In Vishlitzky, the “scheduler

[is] responsive to a client request for a video data stream from a data set such as a

data set encoding a movie.” Id. at 2:63-66. Moreover, to receive requests to

reproduce recordings and control playback of the recordings, Vishlitzky discloses


60

that “one of the controller servers 28, 29,” shown in FIG. 2 above, “assigns one of

the stream servers 21 to the network client 54 requesting multi-media service.” Id.

at 5:55-57. As further shown in FIGS. 2 and 9, the “stream servers 21” is coupled

to the “integrated cached disk array 23,” which includes the “buffer memory 91.”

In turn, the “video server based on specialized hardware,” i.e. “the stream servers

21,” “pull[s] video data out of the [integrated cached disk array 23] and transmit[s]

the data downstream at the required data rate” to the network client 54. Id. at 2:23-

27.

144. This disclosure in Vishlitzky directly reads on the “control unit”

arranged “to receive requests to reproduce the multiple recordings and to control

playback of the stored signals by the storage devices,” as recited in Claim 1 of the

‘441 Patent.


145. Vishlitzky discloses a “real-time pump, coupled to said buffers and

said control unit, to detect the one of the bit rates used to encode the stored signals

on each of the multiple recordings and to output transport stream packets, each

transport stream packet based on the stored signals from one of the multiple

recordings.” For instance, Vishlitzky discloses a “stream server 21” that is a


61

“real-time pump,” coupled to “processors” (control unit) and “buffer memory 91,”

to detect the “required data rate” used to encode the “video data” stored on “the

integrated cached disk array 23” and to output such data. See, e.g., id. at 5:8-21,

22:36-46, 27:11-15, FIGS. 2 and 9.

146. Vishlitzky discloses that the “stream servers 21” includes “one or

more outbound network attachments,” such as an “ATM” network attachment,

connected to a “network (25 in FIG. 2).” Id. at 5:12-21. In this configuration, the

“stream servers 21” may output video data “from the integrated cached disk array

[23] . . . to the network client” at “the required data rate.” Id. at 27:11-15, 2:23-27

(“A video server based on specialized hardware [i.e., stream server] . . . is designed

to pull [compressed] video data out of the disk storage and transmit the data

downstream at the required data rate.”). In order to output the transport stream at

the “required data rate,” the “stream servers 21” must “detect” such a rate when

they “pull video data out of the disk storage.” According to Vishlitzky, “controller

servers 28, 29 can conduct service protocols . . . [that] support[ ] isochronous real-

time multi-media data transmission from the stream servers 21 to the network (25

in FIG. 2).”). Id. at 5:27-35. Vishlitzky discloses pumping according to each

stream’s encoded bit rate: “[t]he steady state operation of the video file server

consists of servicing n streams at the rate of Ri bytes/second for each stream (i.e.,


62

Ri is the ith stream’s playback rate).” Id. at 13:42-45. As noted above, the video

data may be encoded in accordance with the MPEG II Standard. Id. at 22:36-46.

147. Thus, the “stream servers 21” disclosed in Vishlitzky reads directly on

the “real-time pump” recited in Claim 1 of the ‘441 Patent.


148. Vishlitzky discloses “a network interface, coupled to said control unit

and said real-time pump, to receive the transport stream packets in corresponding

queues and to output over the network multiplexed packet isochronous signals

corresponding to the stored signals on the multiple recordings requested to be

reproduced.” For instance, Vishlitzky discloses a network interface (“ATM switch

53”), coupled to a control unit (“processors”) and a real-time pump (“stream

servers 21”), to receive encoded video data from “integrated cached disk array 23”

and combine such data “into single isochronous streams” for “output” on “network

25.” See, e.g., id. at 1:44-47, 2:23-27, 4:24-47, 5:55-61, 6:55-7:14, 7:32-59, 10:49-

50, 11:51-62, 13:42-52, 15:61-65, 17:36-39.

149. As set forth in Vishlitzky:

The video server is designed to ensure that video data are delivered at a constant rate. Encoded audio and video data from disk or RAM are combined into single isochronous streams. A number of such streams


63

are switched to appropriate output interfaces and transmitted to the users.

Id. at 1:61-66.

150. As explained above, the “integrated cached disk array[s] 23” provide

the video data storage in Vishlitzky. Id. at 6:55-7:14. Moreover, Vishlitzky

discloses a “network 25,” shown in FIG. 2 above, which “has conventional

switching mechanisms, such as an ATM switch 53 or arrays of cross-bar switches,

that permit any one of the clients 54 to communicate with any one of the stream

servers 21.” Id. at 5:55-61. As further shown in FIG. 2, the “ATM switch 53” is

coupled to “the stream servers 21,” which includes the “processors” described

above. Id. at FIG. 2. In this configuration, Vishlitzky discloses that “video data

are transmitted isochronously.” Id. at 17:36-39. Additionally, as one of ordinary

skill in the art would appreciate, an ATM switch, such as “ATM switch 53,” uses a

plurality of queues to multiplex signals onto a single transmission channel.

151. This disclosure of the “ATM Switch 53” and “network 25” reads

directly on the “network interface,” which is configured to “receive the transport

stream packets in corresponding queues” and “output over the network multiplexed

packet isochronous signals corresponding to the stored signals on the multiple

recordings requested to be reproduced,” as recited in Claim 1 of the ‘441 Patent.


64


152. Vishlitzky, alone and/or in combination with the MPEG-2 Standard,

discloses “each stream of the packet isochronous signals on the network having an

average bit rate of the one of the bit rates used to encode the stored signals

corresponding thereto.” See, e.g., id. at 1:44-47, 2:23-27, 4:24-47, 5:55-61, 7:32-

59, 10:49-50, 11:51-62, 13:42-52, 15:61-65, 17:36-39.

153. For instance, Vishlitzky states that “[r]eal-time video is ‘isochronous’;

i.e., it must be delivered at a constant data rate,” and that “[video server file 20]

provides specialized support for isochronous data streams used in live, as well as

store-and forward, audio-visual applications.” Id. at 1:46-47, 4:39-41. Vishlitzky

also discloses a “simple case” in which “the playback of each stream occurs at a

constant bit-rate.” Id. at 15:61-65. According to Vishlitzky, “[t]his situation arises

when the video is recorded in its original uncompressed form (frame sizes are

constant) or when the video is compressed at a constant bit-rate (MPEG I, for

example).” Id.

154. In example operations, Vishlitzky discloses:

[T]he video file server consists of servicing n streams at the rate of Ri bytes/second for each stream (i.e., Ri is the ith stream's playback rate). For each stream the video file server maintains two buffers: a disk buffer and a network buffer. In steady state, a network task empties the network buffer and a disk task fills up the disk buffer. The two


65

operations are performed in parallel. The rate at which the network buffer is emptied needs to be equal to the rate at which the disk buffer is filled up; the goal is that both rates are the same as the stream’s playback rate.

Id. at 13:42-52 (emphasis added). One of ordinary skill in the art would appreciate

that a “constant” bit rate, i.e., a bit rate that is always the same and does not

change, is naturally also an “average” of that bit rate.

155. Likewise, the MPEG-2 Standard teaches that video transport streams

are transferred from the encoder/transmitter to the receiver/decoder at a constant

average bit rate that is the same as the encoded bit rate. See Section IX.

156. Accordingly, the above disclosure in Vishlitzky, alone and/or in

combination with the MPEG-2 Standard, reads directly on “isochronous signals on

the network having an average bit rate of the one of the bit rates used to encode the

stored signals,” as recited in Claim 1 of the ‘441 Patent.



157. As explained above, Vishlitzky, alone and/or in combination with the

MPEG-2 Standard, discloses the apparatus as recited in Claim 1. Moreover, as

noted above, while Claim 2 of the ‘441 Patent relaxes the average bit rate to



66

Vishlitzky and the MPEG-2 Standard that discloses rate averages that are constant

and equal—which is plainly within one bit per second. See Section IX.; see also

Vishlitzky at 1:44-47, 2:23-27, 4:24-47, 5:55-61, 7:32-59, 10:49-50, 11:51-62,

13:42-52, 15:61-65, 17:36-39.




MPEG-2 Standard, discloses the apparatus as recited in Claim 1. Moreover,

Vishlitzky, alone and/or in combination with the MPEG-2 Standard, discloses the

output of “each stream of the packet isochronous signals with a jitter of less than

two milliseconds.” See, e.g., Vishlitzky at 10:49-51, 11:41-56; Section IX.

159. For instance, Vishlitzky discloses that “[t]hree classes of schedulable

tasks are supported: general-purpose, real-time, and isochronous tasks.” Id. at

10:49-50. According to Vishlitzky, “[t]hese classes correspond to different kinds

of requests that are likely to exist in a video-on-demand system.” Id. at 10:50-51.

In Vishlitzky, “[t]he isochronous class supports real-time periodic tasks that

require performance guarantees for throughput, bounded latency, and lower jitter.”

Id. at 11:41-43. Vishlitzky states that “[l]ow jitter reduces the amount of buffering


67

needed at the client, which in turn improves the response time of interactive video

applications. Id. at 11:43-45.

160. Additionally, as noted above, the MPEG-2 Standard’s disclosure of

four milliseconds of jitter or less reads on the “jitter of less than two milliseconds”

recited in this claim. Thus, Vishlitzky, alone and/or in combination with the

MPEG-2 Standard, discloses the elements recited in Claim 3 of the ‘441 Patent.




MPEG-2 Standard, discloses the apparatus as recited in Claim 1. Moreover,

Vishlitzky, alone and/or in combination with the MPEG-2 Standard, discloses “a

channel timing module, coupled to said real-time pump, to control timing of output

of the transport stream packets.” See, e.g., Vishlitzky at 2:28-39, 11:57-65, 15:51-

55, 18:13-21; Section IX.

162. For instance, Vishlitzky discloses a “scheduler” that “execute

isochronous tasks from a ‘Ready’ queue 84,” with each isochronous task “inserted

in its appropriate place on the ‘Ready’ queue 84 upon arrival.” Vishlitzky at

11:57-62. According to Vishlitzky, “[t]he arrival of isochronous tasks is generated

by period timers,” and “[a] unique periodic timer exists in the system for each


68

distinct period among all the admitted isochronous tasks.” Id. at 11:62-65.

Vishlitzky also discloses that “[t]he disk scheduling and admission control

procedures . . . ensure that the playback rates of ‘real time’ streams are satisfied.”

Id. at 15:51-53.

163. Moreover, Vishlitzky discloses a “fetch task” that issues a “video

fetch command.” Id. at 18:13-21. In Vishlitzky, “[t]he time for the next fetch

command is established by the requirement of isochronous video data delivery to

the network client having requested the video data,” and “data are fetched

sufficiently in advance of the required time for isochronous video delivery to the

network client.” Id.

164. Furthermore, as explained above, the system clock of the encoder

disclosed in the MPEG-2 Standard provides the “channel timing module . . . to

control timing” of the encoder’s output of transport stream packets, as recited in

Claim 4 of the ‘441 Patent. Thus, the combination of Vishlitzky and the MPEG-2

Standard meet this limitation.

C. Claims 1-4 of the ‘441 Patent Are Obvious Over the Wu Article in View of the MPEG-2 Standard

165. I understand that the Wu Article is prior art to the ‘441 Patent because

the Wu Article was published in 1996, more than one year prior to the ‘441

Patent’s earliest effective filing date of December 18, 1998.


69

166. As previously noted, by expressly disclosing the use of the MPEG-2

Standard, the Wu Article provides express motivation for one of ordinary skill in

the art to combine the teachings of the MPEG-2 Standard with the teachings of the

Wu Article.

167. Having studied the ‘441 Patent and its file history, as well as the Wu

Article, it is my opinion that the Wu Article, in combination with the MPEG-2

Standard, renders obvious Claims 1-4 of the ‘441 Patent.







169. Nevertheless, the Wu Article discloses “an apparatus for

simultaneously reproducing multiple recordings from storage devices for transport

on a network.”

170. For example, the Wu Article is directed to a “video server” that

includes components to retrieve “video files from its connected hard disks,”


70

“transform the files into ATM cells,” and simultaneously output the video files for

“interactive video-on-demand services.” The Wu Article at p. 1029-1031.

171. Accordingly, the Wu Article discloses “an apparatus for

simultaneously reproducing multiple recordings from storage devices for transport

on a network.”


172. The Wu Article discloses “buffers to receive stored signals from the

multiple recordings, each recording containing stored signals encoded at one of a

plurality of bit rates.” For example, the Wu Article discloses a “buffer” for

“caching [ ] video file[s]” encoded at one of a plurality of “bit rates” (e.g., “the

Constant Bit Rate (CBR) services for MPEG-2 stream and the Variable Bit Rate

(VBR) services for MPEG-1”) and stored on “distributed storage devices.” See,

e.g., The Wu Article at p. 1029-31, Figure 1.

173. The Wu Article discloses an ATM-based scalable video server system

with the following “four major components”: a “Server Headend Control (SHC)

unit,” a “stream router,” a “Video Pumping Unit (VPU),” and “distributed storage

devices.” Id. at Abstract. The proposed architecture for this system is shown in

Figure 1:


71

174. The Wu Article explains the important requirements of the video

server:

One of the important requirement in designing a video server is the ability to support a large number of simultaneous video clients watching the movies stored in the server. To achieve this goal, parallel retrieving of the video storage has been introduced and the switch-based delivery networks were used, for example, the use of RAID (Redundant Array of Inexpensive Disks) systems and the ATM (Asynchronous Transfer Mode) networks.

Id. at p. 1029.

175. The Wu Article also discloses that the system is for “video stream[s]

[that] may be . . . constant bit rate like MPEG-2 streams.” Id. at p. 1030. As

previously noted, MPEG-2 streams are encoded video signals.

176. The Wu Article further states that “[s]ince the function of each VPU is

to pump the [encoded] video files in the connected storage device into the stream


72

router, a temporary buffer is required for caching the [encoded] video file before it

is segmented into ATM cells.” Id. at p. 1031. As explained above, the MPEG-2

Standard, which the Wu Article references, also discloses the use of “buffers” for

encoded video signals.

177. Thus, the Wu Article, alone and/or in combination with the MPEG-2

Standard, reads on the “buffers” arranged “to receive stored signals from the

multiple recordings” that are “encoded at one of a plurality of bit rates” recited in

Claim 1 of the ‘441 Patent.


178. The Wu Article discloses “a control unit, coupled to said storage

devices, to receive requests to reproduce the multiple recordings and to control

playback of the stored signals by the storage devices.” For instance, the Wu

Article discloses a “Sever Headend Control (SHC) unit” that receives client

requests to play movies and controls the playback of such movies. See, e.g., id. at

p. 1029-31, Figure 2.

179. The Wu Article discloses that the SHC unit “is the interface between

the ATM networks and the video servers” and the function of the SHC unit

“includes the admission control of a new movie request, interactive control of the

VCR functions, system maintenance, and signaling interface control to the ATM


73

networks.” Id. at p˙. 1029-30; see also id. at p. 1030 (“The server headend control

unit primarily handles the following functions. 1. The signaling interface with

networks. 2. Admission control for the requests from clients. 3. Session control for

video operation via the reverse channel. 4. Video server management.”). The

major components of the SHC unit are shown in Figure 2:

180. The Wu Article also discloses that “[t]he procedures of playing a

movie from the server include the following steps: 1. The client sends a request to

the server headend control unit . . . 4. Initiate a video stream from the storage to the

server headend control unit via the stream router (downstream) … 6. Play the

move.” Id. at p. 1030-31.


74

181. This disclosure of the SHC unit in the Wu Article directly reads on the

“control unit” arranged “to receive requests to reproduce the multiple recordings

and to control playback of the stored signals by the storage devices” recited in

Claim 1 of the ‘441 Patent.


182. The Wu Article discloses a “real-time pump, coupled to said buffers

and said control unit, to detect the one of the bit rates used to encode the stored

signals on each of the multiple recordings and to output transport stream packets,

each transport stream packet based on the stored signals from one of the multiple

recordings.” See, e.g., The Wu Article at p. 1029-1032, Figures 1 and 3.

183. For example, the Wu Article discloses that:

The major part of the system consists of a group of video pumping units (VPU) and an internal ATM-based video stream routing network which make the proposed system scalable. There are distributed storage devices controlled by a set of VPUs. Each VPU reads the video files from its connected hard disks into the local buffer, transform the files into ATM cells, and pump the cells into the stream router. The stream router accepts a large dimension of ATM cells and switches them into their designated channels.

Id. at p. 1029; see also id. at p. 1030 (“There are many storage devices for storing

video files and each device can be a RAID system or simply a hard disk. Each


75

RAID or hard disk is connected to one VPU which pumps the files into the

networks.”).

184. The Wu Article further discloses that “the function of each VPU is to

pump the video files in the connected storage device into the stream router” and

that “[t]he VPU reads a block of video data from its connected hard disk first,

segments the data into ATM cells, and then puts the cells into the stream router at

a required service rate.” Id. at p. 1030 (emphasis added). In order to output video

data at the “required service rate,” each “VPU” must “detect” such a rate when it

“reads a block of [such] video data from its connected hard disk.”

185. Thus, the “video pump unit (VPU)” disclosed in the Wu Article reads

directly on the “real-time pump” recited in Claim 1 of the ‘441 Patent.


186. The Wu Article discloses “a network interface, coupled to said control

unit and said real-time pump, to receive the transport stream packets in

corresponding queues and to output over the network multiplexed packet

isochronous signals corresponding to the stored signals on the multiple recordings

requested to be reproduced.” For instance, the Wu Article discloses a “stream

router” that provides a “network interface,” coupled to the control unit (“SHC


76

unit”) and the “video pump units,” to receive video streams in corresponding

queues from the “distributed storage devices,” to “multiplex” such streams, and to

output them isochronously (i.e., at a “constant bit rate”) over the network. See,

e.g., The Wu Article at p. 1029-1030, 1033, and 1035, Figure 7.

187. According to the Wu Article, “[t]he responsibility of the stream router

is to multiplex the video streams into the server headend control unit” and

“guarantee the quality of services (QoS) of each multiplexed CBR or VBR

stream.” Id. at p. 1030. These video streams “may be variable bit rate like MPEG-

1 streams or constant bit rate like MPEG-2 streams,” and “the proposed

architecture of the stream router is based on ATM technology.” Id. As a result of

the stream router, “[t]he performance consideration for each stream would be a

guaranteed throughput and a bounded delay variance.” Id. at 1030.

188. In addition, the Wu Article discloses that “[t]he stream router consists

of two stages, namely the stream demultiplexer and the stream multiplexer,” and

that “[e]ach output port is associated with a stream multiplexer for multiplexing a

set of CBR and VBR sources into this output port.” Id. at p. 1033. The

architecture for the stream router is shown in Figure 7:


77

189. This disclosure reads directly on the “network interface,” which is

configured to “receive the transport stream packets in corresponding queues” and

“output over the network multiplexed packet isochronous signals corresponding to

the stored signals on the multiple recordings requested to be reproduced,” as

recited in Claim 1 of the ‘441 Patent.


190. The Wu Article, alone and/or in combination with the MPEG-2

Standard, discloses “each stream of the packet isochronous signals on the network


78

having an average bit rate of the one of the bit rates used to encode the stored

signals corresponding thereto.” See, e.g., The Wu Article at p. 1029-1030, 1033,

and 1035, Figure 7; see also Section IX.

191. As explained above, the stream router in the Wu Article outputs

constant bit rate MPEG-2 streams with “a guaranteed throughput and a bounded

delay variance.” See The Wu Article 16 at p. 1030. One of ordinary skill in the

art would appreciate that a “constant” bit rate, i.e., a bit rate that is always the same

and does not change, is naturally also an “average” of that bit rate. Likewise, the

MPEG-2 Standard teaches that video transport streams are transferred from the

encoder/transmitter to the receiver/decoder at a constant average bit rate that is the

same as the encoded bit rate. See Section IX.

192. Accordingly, the disclosure in the Wu Article, alone and/or in

combination with the MPEG-2 Standard, reads directly on “isochronous signals on

the network having an average bit rate of the one of the bit rates used to encode the

stored signals,” as recited in Claim 1 of the ‘441 Patent.


79



193. As explained above, the Wu Article, alone and/or in combination with

the MPEG-2 Standard, discloses the apparatus as recited in Claim 1. Moreover, as

noted above, while Claim 2 of the ‘441 Patent relaxes the average bit rate to


the Wu Article and the MPEG-2 Standard that discloses rate averages that are

constant and equal—which is plainly within one bit per second. See Section XI.;

see also The Wu Article at p. 1029-1030, 1033, and 1035, Figure 7.




the MPEG-2 Standard, discloses the apparatus as recited in Claim 1. Moreover,

the Wu Article, alone and/or in combination with the MPEG-2 Standard, discloses

the output of “each stream of the packet isochronous signals with a jitter of less

than two milliseconds.” See, e.g., The Wu Article at p. 1032; Section IX.


80

195. For instance, the Wu Article discloses that “[t]he stream router should

be designed in such a way that an unexpected jitter or delay would not be happened

for a video stream being switched over the router.” The Wu Article at p. 1032.

Additionally, as noted above, the MPEG-2 Standard’s disclosure of four

milliseconds of jitter or less reads on the “jitter of less than two milliseconds”

recited in this claim. Thus, the Wu Article, alone and/or in combination with the

MPEG-2 Standard, discloses the elements recited in Claim 3 of the ‘441 Patent.




the MPEG-2 Standard, discloses the apparatus as recited in Claim 1. Moreover,

the Wu Article, alone and/or in combination with the MPEG-2 Standard, discloses

“a channel timing module, coupled to said real-time pump, to control timing of

output of the transport stream packets.” See, e.g., The Wu Article at p. 1030;

Section IX.

197. For instance, the Wu Article states that:

The responsibility of the stream router is to multiplex the video streams into the server headend control unit. The major challenge is that the video stream may be variable bit rate like MPEG-1 streams or constant bit rate like MPEG-2 streams. The performance consideration for each stream would be a guaranteed throughput and a


81

bounded delay variance. In order to guarantee the performance of each stream, some intelligent scheduling among the streams is needed as well as the switching and multiplexing. The proposed architecture of the stream router is based on ATM technology.

The Wu Article at p. 1030 (emphasis added).

198. Moreover, as explained above, the system clock of the encoder

disclosed in the MPEG-2 Standard provides the “channel timing module . . . to

control timing” of the encoder’s output of transport stream packets, as recited in

Claim 4 of the ‘441 Patent. Thus, the combination of the Wu Article and the

MPEG-2 Standard meet this limitation.

D. To the Extent That Claim Element Is Missing from Any of the Above Prior Art, It Would Have Been Obvious to Add It

199. To the extent that D&M argues that a particular prior art reference

or combination of prior art references does not disclose a limitation of one of

Claims 1-4 of the ‘441 Patent, it would have been obvious to modify that particular

prior art reference to include the allegedly missing limitation.

200. A person of ordinary skill would have been motivated to combine the

prior art identified in this declaration based on the nature of the problem to be

solved, the teachings of the prior art, and the knowledge of persons of ordinary

skill in the relevant art. Design incentives and other market forces would have

prompted those combinations and modifications.


82

201. In addition, because there were a finite number of predictable

solutions in the relevant art at the time of the claimed inventions, it would have

been obvious to a person of ordinary skill in the art to pursue the known

options. A person of ordinary skill in the art would have been familiar with all the

claim limitations that the applicants for the ‘441 Patent used to distinguish the prior

art during prosecution. The identified prior art references merely use those

familiar elements for their primary or well-known purposes and in a manner well

within the ordinary level of skill in the art. Accordingly, common sense and/or the

knowledge of one of ordinary skill in the art as evidenced by the prior art identified

herein renders Claims 1-4 of the ‘441 Patent unpatentable as well.

202. Moreover, certain pieces of prior art refer to or discuss other pieces of

prior art, illustrating the close technical relationship and interconnectivity existing

in this field. As stated above, to the extent any piece of prior art refers to or

discusses other pieces of prior art, either expressly or inherently, it would have

been obvious to combine those prior art references for that reason. The

combinations and modifications of the prior art needed to invalidate the claims of

the ‘441 Patent would have arisen from, at most, ordinary innovation, ordinary

skill, or common sense. Such combinations would have been obvious to try and

predictable.


83

203. As one example, to the extent that Claim 3 of the ‘441 Patent is not

disclosed by the references/combinations set forth above, it would have been

obvious to combine the teachings of any of these references/combinations with the

teachings of Zhang under 35 U.S.C. § 103.

204. Allen, the combination of Vishlitzsky and the MPEG-2 Standard, and

the combination of the Wu Article and the MPEG-2 Standard each disclose the

apparatus as recited in Claim 1 of the ‘441 Patent. Claim 3 of the ‘441 Patent,

which depends from Claim 1, adds the additional limitation of “each stream of the

packet isochronous signals with a jitter of less than two milliseconds.” Zhang,

which is in the field of digital and multiplex communications, discloses that it was

well known in the art to provide a network, i.e. an ATM network, used to transport

MPEG-2 transport streams with an end-to-end jitter of less than one millisecond,

which is less than the two milliseconds required by Claim 3 of the ‘441 Patent.

Zhang at 3:37-58 (“. . . [W]hen ATM networks are used to transport MPEG-2

transport stream, the end-to-end jitter typically shall not be more than 1

millisecond . . .”).

205. One of ordinary skill in the art would have been motivated to modify

Allen, the combination of Vishlitzsky and the MPEG-2 Standard, or the

combination of the Wu Article and the MPEG-2 Standard with this disclosure in

Zhang.


84

206. Allen, Vishlitzsky, the Wu Article, and the MPEG-2 Standard are all

in the same field of digital and multiplex communications disclosed in Zhang.

Like the ‘441 Patent, all these references are directed to video servers with

specialized components for retrieving encoded video data from storage devices and

outputting that data downstream to subscribers via a high-speed network. See, e.g.,

‘441 Patent at Abstract, 1:11-15, 2:47-3:11; Allen at 1:14-17, 3:52-54, 4:43-59,

10:17-31, 10:65-11:12; Vishlitzky at 1:61-66, 2:23-27, 27:11-15; The Wu Article

at p. 1029-30; Section XI.; Zhang at 1:11-42, 3:38-4:17. Moreover, as noted

above, these references all disclose the MPEG-2 Standard and expressly discuss

techniques to reduce the amount of jitter or delay in transporting MPEG-2 video

data.

207. Accordingly, it would have been obvious to modify Allen, the

combination of Vishlitzsky and the MPEG-2 Standard, or the combination of the

Wu Article and the MPEG-2 Standard with an end-to-end jitter of less than one

millisecond, as disclosed in Zhang, so as to keep the amount of jitter at less than

two milliseconds or less, as required by Claim 3 of the ‘441 Patent.


XI. CONCLUSION

208. As set forth above, Claims 1-4 of the '441Patent are unpatentable.

209. I reserve the right to revise or supplement my analysis to the extent

new information becomes available, the applicable law changes, or as otherwise

permiffed by the Patent Trial and Appeal Board or the applicablerules.

I declare under penalty of pe{ury that the foregoing is true and correct, to the best

of my knowledge and belief.

Executed this 7th day of March2017, in Escondido, California.

85


Appendix A


Anthony J. Wechselberger 3447 Bernardo Lane Office: 760-740-0013 Escondido, CA 92029 Mobile: 619-823-3009

[email protected] www.entropymgmt.com

BROADBAND & MULTIMEDIA STRATEGY & TECHNOLOGY Executive leadership in industrial and consumer communications systems/networks: Business development, technology/R&D management, technical and strategic marketing, domestic and international markets. Focus on broadband/multimedia system and networking solutions for content management, distribution, consumption. Specialist in content security and digital rights management as applied in distribution, storage and rendering.

Extensive experience as a technology and business management consultant and testifying expert to the legal community (case listings and references available). Federal and International Trade Commission experience.

ACCOMPLISHMENTS • Developed successful consulting business offering a variety of technical, strategic, management, business

development, intellectual property and expert witness services.• Lead security expert to the six major Hollywood studios for specification of security for Digital Cinema.• Led strategic planning and technical marketing campaign resulting in TV/COM emerging as the first US

supplier of end to end digital television compression systems for major operators in Europe.• Directed numerous large development programs employing leading edge technology, and successfully executed

make vs. buy and partnership programs to meet requirements.• Developed, patented and applied fundamental symmetric-key encryption technology now employed throughout

the broadband/broadcast world.

EXPERIENCE

Entropy Management Solutions, President (Current) Broadband and multimedia consulting services. Specializing in technology strategy and management (identification and development of core technologies, IPR leveraging, positioning, make/buy/partner), business and strategic planning, value creation and market development. Satisfied clients in content security, content delivery networks and systems, intellectual property management, digital rights management, technology management and planning.

- Active in Digital Cinema security standards development: Consultant to “6 Majors” DCI studio consortium,former chairman of SMPTE DC28 Security and Key Management Ad Hoc.

- Consultant to major SI Valley entity sponsoring the development of an IPR-free DRM solution.- Security infrastructure planning for theatrical and post-theatrical digital content distributors.- Security review and enhancement plan for digital high definition hospitality video on demand network.- Windows Media DRM compliance evaluation for wireless phone Music on Demand service- Perform set top box evaluations of logical and physical security robustness & copy protection compliance.- Architectural and system security/DRM design for wireless media player.- Corporate advisor to supplier of cable audience measurement data (business and technical development).- Assisted broadband conditional access supplier in evolving security technology into the IP & multicast space.- IPR assertion project manager for European conditional access technology company (8 actions pursued/settled).- Provided numerous technical expert & consulting services for legal community.- Numerous technology evaluations for various entities for purposes of market expansion, partnership evaluation.

____________________________________________________________________________________________

TV/COM International Inc., Subsidiary of Hyundai Electronics America

Vice President of Product Management 1997-1999 Business management for company’s product and system solutions: Competitiveness of product mix, contract compliance, margin definition/maintenance, product marketing, customer support/field service. Cross-functional direction of third party customer relations, contract administration, product life cycle processes, IPR licensing.


General Manager, Conditional Access Business Unit 1995- 1997 Business head for the “Control and Conditional Access Systems” group, a P&L unit to develop, market, and support computerized network control and encryption-based broadband security systems for international cable, satellite and wireless/broadcast applications (“AlphaStar Television Network” and German “DF1” BetaCrypt DBS networks).

OCI Communications Inc./ TV/COM International 1990-1995 Vice President and Chief Technical Officer

Defined technical strategies and core technologies, rebuilt technical operations group (50 to 150), established cross functional team organization and formal project management disciplines. Formulated roadmap into digital television, and participated in realizing strategic partnering objectives (Nokia, C-Cube, Fuba, BetaTechnik, Irdeto). Participated in international standards and establishment of European and North American beachhead accounts.

OAK Communications, Inc., Division of OAK Industries, Inc. Senior Vice President, Domestic Operations 1988-1990

Managed US operations for OAK Communications: Technical operations, marketing and sales (revenue capture, account management). As part of three member executive team, executed OCI’s divestiture from OAK Industries.

Director Engineering, VP Engineering, VP Tech Ops 1982-1988 Managed engineering, technical marketing and sales, field operations, factory liaison (Taiwan). Developed the industry’s first widely deployed consumer systems employing encryption security for satellite, cable and broadcast.

OAK Industries, Inc. 1980-1982 Member, Corporate Advanced Technology Group

Research, simulation and prototyping of technologies in support of OAK’s broadcasting businesses. Explored advanced control and digital coding systems for scrambling, compression and transmission of audio and video, and developed/patented the industry’s first hard encryption key management and control methodologies for broadcast.

General Dynamics, Electronics Division 1974-1980 Senior Engineer/Project Engineer

Aerospace Engineering: communications, embedded processing, digital signal processing for portable man/aircraft wargame instrumentation, moving target indicator (MTI) digital radar, Global Positioning System receivers.

EDUCATION Executive Program for Scientists and Engineers University of California, San Diego 1984 Master of Science, Electrical Engineering San Diego State University 1979 Bachelor of Science, Electrical Engineering University of Arizona 1974

OTHER Publications/Presentations: Numerous technical and marketing presentations, publications and panels in the fields of cable and satellite broadcasting, standards development, broadband, Internet and digital cinema security.

Patents/Applications: “Storage & Delivery of Electronic Media with Advertising” US Pat App 10/028,013, and provisional following App 60/38,008, both Dec 2001. “Anonymous Transactions Over a System of Networked Computers” US Pat App 09/654,662. “Multilayer Encryption System for the Broadcast of Encrypted Information”, U.S. Pat. No. 4,531,020, July 1985. “Universal Decoder”, U.S. Pat. No. 5,113,440, May 1992.

Memberships (past/present): Society of Cable & Telecommunications Engineers, Society of Motion Picture and Television Engineers, Advanced Television Systems Committee, Organization for International Standardization, Institute of Electronic & Electrical Engineers.


Appendix B


1

ANTHONY WECHSELBERGER TRIAL AND DEPOSITION TESTIMONY (FIVE YEARS)

CASE NO. CASE, FIRM, DESCRIPTION DELIVERABLES

MAY 2010 – APRIL 2013

HITACHI CONSUMER ELECTRONICS CO. LTD V. TOP VICTORY ELECTRONICS CO. LTD ET AL. CASE NO. 2:10-CV-260-JRG U.S. DIST COURT, EASTERN DISTRICT OF TEXAS LEGAL FIRM: O’MELVENY & MEYERS LLP

TECHNICAL EXPERT SUPPORTING TOP VICTORY ELECTRONICS IN PRIOR ART RESEARCH AND NON-INFRINGEMENT ISSUES (VARIOUS DIGITAL TV AND BROADCAST TECHNOLOGY PATENTS).

INVALIDITY & NON-INFRINGEMENT REPORTS WRITTEN AND DEFENDED. TESTIFIED AT TRIAL (JUDGE GILSTRAP).

DEC 2010 – JUNE 2011

MONDIS TECHNOLOGY LTD. V. TOP VICTORY ELECTRONICS CO. LTD. ET AL. CASE NO. 2:08-CV-00748. U.S. DISTRICT COURT, EASTERN DISTRICT OF TEXAS. LEGAL FIRM: O’MELVENY & MEYERS LLP

TESTIFYING EXPERT SUPPORTING TOP VICTORY ELECTRONICS IN PRIOR ART RESEARCH AND NON-INFRINGEMENT (DIGITAL TV AND DISPLAY TECHNOLOGY).

PREPARED & DEFENDED EXPERT REPORT & PREPARED FOR TRIAL (CASE SETTLED).

MAR 2011 – MAY 2015

PERSONALIZED MEDIA CORP. (PMC) V. DISH NETWORK ET AL. CASE NO. 08-CV---70. U.S. DISTRICT COURT, EASTERN DISTRICT OF TEXAS. LEGAL FIRM: MORRISON AND FOERSTER

TESTIFYING EXPERT ASSISTING DEFENDANT IN MULTIPLE PATENT ASSERTIONS. (“JOHN HARVEY” PMC PATENTS)

PREPARED & DEFENDED EXPERT REPORT. PREPARED FOR TRIAL (CASE SETTLED)

SEPT – DEC 2011

JOHN MARKEY V. VERIMATRIX, INC. SAN DIEGO SUPERIOR COURT CASE NO. 37-20074402-CU-WT-CTL. CONS. WITH 37-2008-00099311-CU-IP-CTL. LEGAL FIRM: Manning & Kass Ellrod, Ramirez, Trester LLP

EXPERT FOR DEFENDANT VERIMATRIX IN DISPUTE OVER ALLEDGED MISAPPROPRIATION OF TRADE SECRETS AND WRONGFUL TERMINATION.

REVIEWED ALL CASE DOCUMENTS AND TESTIFIED AT TRIAL.

OCT 2011 – AUG 2012

KULAKOWSKI V. VERIMATRIX, INC. SAN DIEGO SUPERIOR COURT CASE NO. 37-2011-000885770CU-MC-CTL. LEGAL FIRM: COOLEY, LLP

EXPERT ON BEHALF OF DEFENDANT VERIMATRIX IN DISPUTE OVER INTELLECTUAL PROPERTY ORIGINATION AND OWNERSHIP.

REVIEWED ALL CASE DOCUMENTS AND TESTIFIED AT TRIAL.

MAR – DEC 2012

ITC INVESTIGATION # 337-TA-824. WALKER DIGITAL LLC V. FUNAI CORP., “CERTAIN BLU-RAY DISC PLAYERS, COMPONENTS THEREOF AND PRODUCTS CONTAINING SAME” LEGAL FIRM: SHAW KELLER LLP

EXPERT FOR JOINT DEFENSE GROUP IN PRIOR ART RESEARCH (SUPPLEMENTARY INFORMATION ACCESS FOR INTERACTIVE TV).

INVALIDITY REPORT WRITTEN AND DEFENDED (CASE SETTLED).

NOV 2012 – JAN 2014

* BRITISH TELECOM V. COX COMMUNICATIONS, INC. ET AL. U.S. DIST.COURT, DISTRICT OF DELAWARE. CASE NO. 1:10-CV-00658.* COMCAST CABLE COMMUNICATIONS, LLC ET AL V. BRITISHTELECOMMUNICATIONS. CASE NO. 11-843-SLR (D. DEL)LEGAL FIRMS: KILPATRICK TOWNSEND AND KEKER & VAN NEST LLP

INVALIDITY AND NON-INFRINGEMENT REPORTS WRITTEN AND DEFENDED (MSJ FOR NON-


2

TESTIFYING EXPERT SUPPORTING DEFENDANTS COX CABLE AND COMCAST CABLE IN PRIOR ART RESEARCH & NON-INFRINGEMENT (SEPARABLE SECURITY FOR DIGITAL TV).

INFRINGEMENT ALLOWED)

OCT 2013 – SEPT. 2015

SMARTFLASH LLC, ET AL V. APPLE INC., ET AL. CASE NO. 6:13-CV-00447 (E.D. TX) LEGAL FIRM: ROPES & GRAY, LLP TESTIFYING EXPERT FOR DEFENDANT APPLE IN PRIOR ART RESEARCH AND NON-INFRINGEMENT (CONTENT DISTRIBUTION TO PORTABLE DEVICES WITH DRM).

WROTE & DEFENDED MULTIPLE CBM DECLARATIONS, NON-INFRINGEMENT AND INVALIDITY REPORTS. TESTIFIED AT TRIAL (JUDGE GILSTRAP).

MAR 2014 – AUG 2016

COMCAST CABLE COMM, LLC V. SPRINT COMMUNICATIONS CO. L.P.; CIVIL ACTION NO. 12-CV-00859-JD; E.D. PA., LEGAL FIRM: BAKER HOSTETLER, LLP TECHNICAL EXPERT SUPPORTING COMCAST IN PRIOR ART RESEARCH AND NON-INFRINGEMENT ANALYSIS (INTERACTIVE CABLE TV AND MOBILE VOD OVER INTERNET SERVICES)

INVALIDITY & NON-INFRINGEMENT REPORTS WRITTEN AND DEFENDED. MSJ FOR NON-INFRINGEMENT GRANTED

JUNE 2014 – NOV 2015

PERSONALIZED MEDIA COMMUNICATIONS, LLC V. AMAZON.COM, INC. CIVIL ACTION NO. 1:13-CV-1608-RGA. U.S. DISTRICT COURT OF DELAWARE LEGAL FIRM: KNOBBE, MARTENS, OLSON & BEAR, LLP TECHNICAL EXPERT SUPPORTING DEFENDANT AMAZON IN PRIOR ART RESEARCH (“JOHN HARVEY” PMC PATENTS).

THREE IPR DECLARATIONS WRITTEN AND DEFENDED.

SEPT. 2014 – SEPT. 2015

BROADBAND ITV, INC. V. HAWAIIAN TELECOM, INC. ET AL. CASE NO. 14-CV-00169. UNITED STATES DISTRICT COURT OF HAWAII. LEGAL FIRM: MAYNARD COOPER & GALE, LLP TECHNICAL EXPERT SUPPORTING DEFENDANT HAWAIIAN TELECOM IN PRIOR ART RESEARCH (CABLE VOD INGEST, STORAGE AND STAGING).

INVALIDITY REPORT SUBMITTED & DEFENDED. MSJ GRANTED UNDER 101.

DEC. 2014 – NOV 2015

DRAGON INTELLECTUAL PROPERTY, LLC V. DISH NETWORK LLC. CASE NO. 1:13-CV-02066-RGA. U.S. DISTRICT OF COLUMBIA. LEGAL FIRM: BAKER BOTTS, LLP TECHNICAL EXPERT ASSISTING DEFENDANT DISH IN PRIOR ART REVIEW AND IPR PETITION (DVR/PVR SET TOP BOX TECHNOLOGY).

IPR DECLARATION WRITTEN AND DEFENDED.

NOV – 2015 PRESENT

PERSONALIZED MEDIA COMMUNICATIONS, LLC V. APPLE INC., CASE NO. 2:15-CV-1366-JRG-RSP; EASTERN DISTRICT OF TEXAS LEGAL FIRM: KIRKLAND & ELLIS LLP TECHNICAL EXPERT ASSISTING IN PRIOR ART RESEARCH AND INVALIDITY (INTERACTIVE TELEVISION SYSTEMS JOHN HARVEY PMC PATENTS)

EXPERT REPORT SUBMITTED AND DEFENDED.


Appendix C


PUBLICATIONS AND PRESENTATIONS ANTHONY J. WECHSELBERGER

PUBLICATION/VENUE TITLE DATE CED MAGAZINE HEADEND ENCRYPTION AND SIGNAL SECURITY OCT 1983 OAK WHITE PAPER ENCRYPTION: A CABLE TV PRIMER DEC 1983 COMMUNICATIONS TECH ENCRYPTION APPLICATIONS IN THE CABLE TV ARENA JULY 1984 IEEE MILITARY COMM CONF. COMMERCIAL APPLICATIONS OF ENCRYPTED SIGNALS OCT 1994 NTCA TECH PAPERS ENCRYPTION-BASED SECURITY SYSTEMS 1987 DBS ROUND TABLE SATELLITE BROADCASTING – CHANGES & INDICATORS IN THE 90’S JUNE 1991 CABLELABS ROUNDTABLE CONDITIONAL ACCESS & REPLACEABLE SECURITY CARDS NOV 1992 SD CONNECT PROGRAM THE NEXT REVOLUTION IN DIGITAL COMMUNICATIONS 1993 NTCA TECH PAPERS CA & ENCRYPTION OPTIONS FOR DIGITAL COMPRESSION SYSTEMS 1993 NTCA TECH PAPERS MULTI-RATE ALL-DIGITAL MODEM FOR SUPPORT OF UNIVERSAL

MULTIPLEX TRANSPORT LAYER FOR DIGITAL COMPRESSION 1993

COMMUNICATIONS TECH CONDITIONAL ACCESS & ENCRYPTION OPTIONS FOR DIGITAL SYS. NOV 1993 TV/COM WHITE PAPER DIGITAL COMPRESSION: OPEN ARCHITECTURES, INTEROPERABILITY &

MULTIPLE SOURCING FOR CANADA MAR 1994

COMMUNICATIONS TECH METHODOLOGIES FOR MULTIPLE CONDITIONAL ACCESS TECHNOLOGIES IN DIGITAL DELIVERY SYSTEMS

JUNE 1994

DBS DIGEST SUMMIT DIGITAL DBS – THE NEXT WAVE DEC 1994 NCTA TECH PAPERS DIGITAL COMPRESSION – INTEROPERABILITY ISSUES FOR CABLE 1995 WORLD BROADCAST NEWS COMPRESSION REVISITED PART 2: MORE QUESTIONS ON MPEG2 APRIL 1996 DBS DIGEST SUMMIT SECURING FOR DIGITAL BROADCAST JUNE 1996 SAN DIEGO ELECTRONICS ELECTRONIC COMMERCE IN BROADBAND NETWORKS 1997 EUROPEAN CABLE SUMMIT CHALLENGES & OPPORTUNITIES FOR DIGITAL TV RECEIVERS JULY 1997 CHINA DIGITAL TV SUMMIT DIGITAL COMPRESSION OPPORTUNITIES FOR CHINA AUG 1998 DIGITAL CINEMA MAGAZINE DESIGNING FOR SECURITY AND OPEN ARCHITECTURES OCT 2001 SOCIETY OF MOTION PICT. & TELEVISION ENGR’S

REQUIREMENTS FOR “KEY MANAGEMENT” FOR DIGITAL CINEMA (SMPTE REQUEST FOR TECHNOLOGY)

JAN 2002

SMPTE DIGITAL CINEMA SECURITY FOR DCINEMA : STATUS OF STANDARDIZATION JAN 2003 ON*VECTOR PHOTONICS WORKSHOP (UCSD)

CONTENT OWNERSHIP RIGHTS: DISTRIBUTION & SECURITY ISSUES MAR 2004

DCCJ DIGITAL CINEMA SUMMIT

INVITED PAPER TO “DIGITAL CINEMA CONSORTIUM OF JAPAN”: STANDARDS AND STATUS OF USA DIGITAL CINEMA SECURITY

JUNE 2004

OPEN MEDIA COMMONS DREAM-CAS WORKSHOP

IPR INVESTIGATION PROCESS: DREAM-CAS MAR 2006

SAN DIEGO COMMNEXUS INVITED PAPER: DIGITAL CINEMA – BIRTH DATE 2006 NOV 2006 SMPTE: DIGITAL CINEMA FEDERAL INFORMATION PROCESSING STANDARD (FIPS) 140-2 -

TRANSITION TO 140-3 AND NIST CRYPTOGRAPHIC EVOLUTION JAN 2009


Documents

UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE … · 2017-03-09 · broadband network providers began to upgrade their distribution infrastructures accordingly. 10. In conjunction