Harmonic Inc.v.Avid Technology, Inc.

Patent Trial and Appeal Board

Jul 10, 2014

08278761 (P.T.A.B. Jul. 10, 2014)

Trials@uspto.gov Paper 27
571-272-7822 Entered: July 10, 2014
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

HARMONIC, INC.,
Petitioner,

v.

AVID TECHNOLOGY, INC.,
Patent Owner.
____________

Case IPR2013-00252
Patent 5,495,291
____________

Before JONI Y. CHANG, KRISTEN L. DROESCH,
MICHAEL R. ZECHER, and GEORGIANNA W. BRADEN,
Administrative Patent Judges.

DROESCH, Administrative Patent Judge

FINAL WRITTEN DECISION
35 U.S.C. § 318 and 37 C.F.R. § 42.73

IPR2013-00252
Patent 5,495,291
2
I. INTRODUCTION
Harmonic, Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”)
requesting inter partes review of claims 1–20 of U.S. Patent No. 5,495,291
(“the ’291 Patent”) pursuant to 35 U.S.C. §§ 311–319. Avid Technology,
Inc. (“Patent Owner”) timely filed a Patent Owner Preliminary Response.
Paper 10 (“Prelim. Resp.”). Taking into account Patent Owner’s
Preliminary Response, on September 25, 2013 we instituted inter partes
review only as to claims 1–16 on one ground of unpatentability. Paper 12
(“Dec. on Institution”).
Following institution, Patent Owner filed a Response (Paper 16, “PO
Resp.”), and Petitioner filed a Reply to Patent Owner’s Response (Paper 17,
“Pet. Reply”). An oral hearing was held on May 20, 2014. A transcript of
the oral hearing has been entered into the record. Paper 26.
We have jurisdiction under 35 U.S.C. § 6(c). This final written
decision is entered pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
For the reasons that follow, we determine that Petitioner has shown by
a preponderance of the evidence that claims 1–10 of the ’291 Patent are
unpatentable. However, we determine that Petitioner has not shown by a
preponderance of the evidence that claims 11–16 of the ’291 Patent are
unpatentable.
IPR2013-00252
Patent 5,495,291
3
A. The ’291 Patent (Ex. 1001)
The ’291 Patent relates to decompressing compressed video data.
Ex. 1001, col. 1, ll. 9–12.
Figure 3 of the ’291 Patent is reproduced below:

Figure 3 depicts decompression system 100, including input switch 105, first
and second decompression circuits 120 and 130 (shown in Figure 3 as “30”),
output switch 115, and microcontroller 110. Id. at col. 3, l. 67–col. 4, l. 6.
First and second decompression circuits 120 and 130 include, respectively,
compressed video data buffers 121 and 131, first and second decoders 123
and 133, and decompressed video data buffers 125 and 135. Id. Stream
scheduler 150 is coupled to microcontroller 110. Id. at col. 4, l. 6.
Two compressed video data steams enter input switch 105. Id. at
col. 4, ll. 38–39. Under command of microcontroller 110, video data flows
into one of the decompression circuits at a first rate, and flows into the other
decompression circuit at a second rate. Id. at col. 4, ll. 39–41. For example,
IPR2013-00252
Patent 5,495,291
4
video data initially flows into decompression circuit 120 at a high rate and
into decompression circuit 130 at a lower rate. Id. at col. 4, ll. 41–45. As
compressed video data buffer 121 begins to fill with video data that it is
receiving at a high rate, decoder 123 begins decompressing that video data.
Id. at col. 4, ll. 53–55. The decompressed frames of the video data are then
stored in decompressed video data buffer 125. Id. at col. 4, ll. 55–57.
Decompressed video data frames are removed from decompressed video
data buffer 125 in the proper order under direction of microcontroller 110
and sent through output switch 115 to an output bus. Id. at col. 4, ll. 60–63.
When the first video data stream nearly is finished, the decompression
process begins in decompression circuit 130. Id. at col. 4, ll. 64–66.
Microcontroller 110 instructs input switch 105 to begin directing the second
compressed video data stream into decompression circuit 130, at the second
lower rate. Id. at col. 4, l. 66–col. 5, l. 2. Output switch 115 is instructed by
microcontroller 110 to switch the output to decompression circuit 130 as the
output from decompression circuit 120 ends, insuring a continuous
generation of decompressed video data without any blank frames between
video streams. Id. at col. 5, ll. 15–19.
IPR2013-00252
Patent 5,495,291
5
Figure 4 of the ’291 Patent is reproduced below:

Figure 4 illustrates the timing and relative rates of video data transmission
through decompression circuits 120, 130 during typical use. Id. at col. 3,
ll. 60–62; col. 5, ll. 31–33. At time T1, decompression circuit 120 is
receiving and decompressing a first video data stream at a high rate, and
decompression circuit 130 is not receiving data. Id. at col. 5, ll. 33–35. At
time T2, input switch 105 is instructed by microcontroller 110 to begin
directing a second video data stream into decompression circuit 130 at a low
rate. Id. at col. 5, ll. 35–39. At time T3, the first video data stream being
processed by decompression circuit 120 ends and decompression circuit 130
immediately begins receiving a second video data stream at a high rate,
while simultaneously sending its stored decompressed video data frames to
the output bus. Id. at col. 5, ll. 39–43. At time T4, input switch 105 is
instructed by microcontroller 110 to begin directing the next video data
steam into decompression circuit 120 at a low rate. Id. at col. 5, ll. 43–46.
At time T5, buffers 121, 125 of decompression circuit 120 are full, and video
data flow to decompression circuit 120 ceases. Id. at col. 5, ll. 46–48. At
IPR2013-00252
Patent 5,495,291
6
time T6, the second video data stream being processed by decompression
circuit 130 ends and decompression circuit 120 immediately begins
receiving its next video data stream at a high rate, while simultaneously
sending its stored decompressed video data frames to the output bus. Id. at
col. 5, ll. 48–52.
B. Illustrative Claims
Claims 1 and 9 are independent claims. Claims 2–8 directly or
indirectly depend from independent claim 1, and claims 10–16 directly or
indirectly depend from independent claim 9. Claims 1 and 9 are illustrative
of the claims at issue and are reproduced below:
1. A system for decompressing video data streams and for
providing continuous video data output, the system comprising:
an input switch coupled to a plurality of compressed video
data input lines, the switch capable of selecting input
lines and capable of controlling the video data flow rate
of the selected input lines;
a plurality of decompression modules coupled to the input
switch for decompressing compressed video data
received from the input switch and storing decompressed
video data;
an output switch coupled to the decompression modules, the
output switch coupling only one of the decompression
modules to an output bus at any time; and
a controller coupled to the input switch, the decompression
modules, and the output switch for selecting which
decompression module will receive video data at a first
predefined rate, the decompression module receiving
video data at the first predefined rate also being coupled
to the output bus by the output switch.
Ex. 1001, col. 6, ll. 25–45 (emphases added).
IPR2013-00252
Patent 5,495,291
7
9. A video decompression system comprising:
a first switch coupled to at least two video data input lines,
the first switch controlling the direction and rate of video
data flow from the video data input lines;
at least two video data decompression arrays coupled to the
first switch, the video data decompression arrays storing
compressed video data, decompressing the stored
compressed video data, and storing the decompressed
video data;
a second switch coupled to the video data decompression
arrays and to an output bus, the second switch directing
output from the at least two video data decompression
arrays to the output bus; and
a controller coupled to the first switch, the video data
decompression arrays, and to the second switch for
controlling the flow of video data through the system.
Id. at col. 7, ll. 4–20 (emphases added).
C. Prior Art Relied Upon
Haskell US 5,159,447 Oct. 27, 1992 Ex. 1008
Rossmere US 5,508,940 Apr. 16, 1996 (filed Feb. 14, 1994) Ex. 1009

D. Ground of Unpatentability
We instituted inter partes review on the ground challenging claims 1–
16 as unpatentable under 35 U.S.C. § 103(a) over Haskell and Rossmere.
See Dec. on Institution 18–31, 37.
II. ANALYSIS
A. Claim Construction
Consistent with the statute and legislative history of the Leahy-Smith
America Invents Act, Pub. L. No. 112-29, 125 Stat. 284, 329 (2011), the
Board construes claims by applying the broadest reasonable interpretation in
IPR2013-00252
Patent 5,495,291
8
light of the specification. 37 C.F.R. § 42.100(b); see also Office Patent Trial
Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012). There is a
“heavy presumption” that a claim term carries its ordinary and customary
meaning. CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366
(Fed. Cir. 2002). However, a “claim term will not receive its ordinary
meaning if the patentee acted as his own lexicographer and clearly set forth a
definition of the disputed claim term in either the specification or
prosecution history.” Id. “Although an inventor is indeed free to define the
specific terms used to describe his or her invention, this must be done with
reasonable clarity, deliberateness, and precision.” In re Paulsen, 30 F.3d
1475, 1480 (Fed. Cir. 1994).
1. “Input Switch . . . Capable of Controlling the Video Data Flow Rate”
(Claim 1)
In our Decision on Institution, we adopted Petitioner’s proposed
construction for the claim phrase “input switch . . . capable of controlling the
video data flow rate” as “controlling the time, duration, and rate at which
video data flows into the selected input lines, and includes some level of
control beyond simply turning flow on or off.” Dec. on Institution 11; see
Pet. 12. Patent Owner does not dispute the claim construction of the
aforementioned claim phrase. See PO Resp. 5, 15, 17, 18, 20.
Upon further review of the ’291 Patent Specification, the inclusion of
“into the selected input lines” is not consistent with the ’291 Patent
Specification. Instead of disclosing control of the video data flow into the
selected input lines, the ’291 Patent Specification discloses that input switch
105, via microcontroller 110, controls video data flow of the selected input
IPR2013-00252
Patent 5,495,291
9
lines into decompression circuits 120, 130. For example, the ’291 Patent
Specification provides the following disclosures: (1) “[m]icrocontroller 110
instructs input switch 105 to begin flowing the second compressed video
data stream into decompression circuit 130 [] at the second, lower rate”
(Ex. 1001, col. 4, l. 66–col. 5, l. 1 (emphasis added)); (2) “[m]icrocontroller
110 will . . . instruct input switch 105 to stop the flow of video data into
decompression circuit 130” (id. at col. 5, ll. 9–11 (emphasis added));
(3) “[i]nput switch 105 also begins to flow the second video data stream into
decompression circuit 130 at the higher, first rate of video flow” (id. at
col. 5, ll. 19–21 (emphasis added)); (4) “[m]icrocontroller 110 has instructed
input switch 105 to begin flowing the second video data stream into
decompression circuit 130 at the second, lower rate” (id. at col. 5, ll. 36–39
(emphasis added)); (5) “[m]icrocontroller 110 instructs input switch 105 to
begin flowing the next video data stream into first decompression circuit 120
at the second, lower rate” (id. at col. 5, ll. 43–46 (emphasis added)); and
(6) “[m]icrocontroller 110 [] instructs input switch 105 to begin flowing the
next video data stream into decompression circuit 130 at the second, lower
rate” (id. at col. 5, ll. 52–56 (emphasis added)).
Accordingly, applying the broadest reasonable construction standard,
we now construe “input switch . . . capable of controlling the video data flow
rate” as “controlling the time, duration, and rate at which video data flows,
and includes some level of control beyond simply turning flow on or off.”
2. “Switch” (Claims 1, 4, 9, 15, and 16)
In our Decision on Institution, we adopted Petitioner’s proposed
construction for the term “switch” as “a device or assembly for routing or
IPR2013-00252
Patent 5,495,291
10
selecting a data stream,” because this construction is consistent with the
ordinary and customary meaning of a “switch” as it would be understood by
one with ordinary skill in the art in the context of the ’291 Patent. Dec. on
Institution 13–14; see Pet. 13. Patent Owner does not dispute the claim
construction of “switch.” PO Resp. 6.
3. “A Predefined Period of Time” (Claim 11)
Dependent claim 11 recites “the controller commands the first
switch . . . to provide video data to the remaining video decompression
arrays at a second rate a predefined period of time after the first video data
array begins receiving the video data at the first rate.” Neither Patent Owner
nor Petitioner provides a construction for “a predefined period of time.” We
did not construe “a predefined period of time” in the Decision on Institution.
Turning to the ’291 Patent Specification, we do not identify a
reasonably clear, deliberate, and precise definition for “a predefined period
of time.” Therefore, we resort to the ordinary and customary meaning of the
term “predefined” in order to construe the phrase “a predefined period of
time.” The ordinary and customary meaning of the prefix “pre” is:
“before,” “in front of,” “prior to,” “in advance of,” “surpassing.” RANDOM
HOUSE WEBSTER’S COLLEGE DICTIONARY 1060 (1992) (Ex. 3001). When
“pre” is used in conjunction with the term “defined,” the ordinary and
customary meaning of “predefined” is “prior defined.” In accordance with
the ordinary and customary meaning, we construe “a predefined period of
time” as “a prior defined period of time.” Our construction is consistent
with the ’291 Patent Specification. See Ex. 1001, Fig. 4; col. 5, ll. 31–56;
col. 7, ll. 27–32.
IPR2013-00252
Patent 5,495,291
11
4. “Lines” (Claims 1 and 9)
In our Decision on Institution, we adopted Petitioner’s proposed
construction for the term “lines” as “any means for conducting the claimed
‘data streams,’ including physical lines (e.g. conductive wires) or
otherwise,” because this construction is consistent with the ordinary and
customary meaning of “lines” as it would be understood by one with
ordinary skill in the art in the context of the ’291 Patent. Dec. on Institution
12; see Pet. 12. Patent Owner does not dispute the claim construction of
“lines.” PO Resp. 6.
5. “Controller” (Claims 1, 4, 9, 11, 15, and 16)
In our Decision on Institution, we adopted Petitioner’s proposed
construction for the term “controller” as “a component or subsystem that
cause[s], directly or indirectly, aspects of operation of a device,” because
this construction is consistent with the ’291 Patent Specification. Dec. on
Institution 14–15; see Pet. 13–14 (citing Ex. 1001 col. 4, ll. 6–92). Patent
Owner does not dispute the claim construction of “controller.” PO Resp. 6.
6. “Output Bus” (Clams 1, 9, and 16)
In our Decision on Institution, we adopted Petitioner’s proposed
construction for the term “output bus” as “a video output or output path in a
prior art known manner, consistent with the disclosure provided, e.g., in
Figure 2 and 3 of the ’291 patent,” because this construction is consistent
with the ’291 Patent Specification. Dec. on Institution 15; see Pet. 14 (citing
Ex. 1001, Figs. 2–3; Ex. 1002 ¶ 46). Patent Owner does not dispute the
claim construction of “output bus.” PO Resp. 6.
IPR2013-00252
Patent 5,495,291
12
7. “Predefined Rate” (Clams 1, 9, and 16)
In our Decision on Institution, we adopted Petitioner’s proposed
construction for the term “predefined rate” as “a rate determined at any time
prior to the step presently being performed,” because this construction is
consistent with the ’291 Patent Specification. Dec. on Institution 15–16; see
Pet. 14 (citing Ex. 1002 ¶ 47). Patent Owner does not dispute the claim
construction of “predefined rate.” PO Resp. 6.
8. “A Plurality of Compressed Video Data Input Lines” (Claim 1) and
“At Least Two Compressed Video Data Input Lines” (Claim 9)
In our Decision on Institution, we rejected Petitioner’s proposed
narrow construction, and construed the phrases “a plurality of compressed
video data input lines” and “at least two compressed video data input lines”
as “each including a portion of a single video program,” because this is the
broadest reasonable construction consistent with the ’291 Patent
Specification. Dec. on Institution 16–17. Patent Owner does not dispute the
construction of these claim phrases. PO Resp. 6.
9. “Buffer” (Claims 2 and 3)
In our Decision on Institution, we modified Petitioner’s proposed
claim construction, and construed the term “buffer” as “a temporary means
for data storage” based on the ’291 Patent Specification and the ordinary and
customary meaning of “buffer.” Dec. on Institution 12–13 (citing
MICROSOFT COMPUTER DICTIONARY 76 (5th ed. 2002) (Ex. 3002)); see Pet.
13 (citing Ex. 1001, col. 4, ll. 31–37). Patent Owner does not dispute the
claim construction of “buffer.” PO Resp. 6.
IPR2013-00252
Patent 5,495,291
13
B. Obviousness of Claims 1–10
With respect to the assertions of unpatentability of claims 1–10, we
have reviewed the Petition, Patent Owner Response, and Petitioner’s Reply,
as well as the evidence discussed in each of those papers. We are persuaded
by a preponderance of the evidence that claims 1–10 are unpatentable under
35 U.S.C. § 103(a) over Haskell and Rossmere. See Pet. 43–51.
1. Haskell (Ex. 1008)
Haskell’s disclosed invention relates to avoiding encoder and decoder
buffer overflow and underflow when transmitting an image over variable or
effectively variable bit-rate channels. Ex. 1008, col. 1, l. 65–col. 2, l. 9.
Figure 2 of Haskell is reproduced below:

IPR2013-00252
Patent 5,495,291
14
Figure 2 illustrates encoding system 100, which includes multiplex system
controller 105, encoders 101-1 through 101-N, encoder buffers 106-1
through 106-N, multiplexer 108, and multiplex buffer 109. Id. at col. 2,
ll. 56–59. Individual unencoded bit-streams 111-1 through 111-N are
encoded by encoders 101, and multiplexed by multiplexer 108 into a single
bit-stream 112 for transmission. Id. at col. 2, ll. 56–59; col. 11, ll. 6–10, 33–
34; col. 11, l. 67–col. 12, l. 1; col. 12, ll. 10–19. Each of the individual
unencoded bit streams 111 may be derived from a different source. Id. at
col. 11, ll. 21–22. For example, unencoded bit stream 111-1 is designated as
a video signal and unencoded bit stream 111-2 is designated as an audio
signal. Id. at col. 12, ll. 1–4. However, Haskell further discloses that any
signals capable of being divided into units and encoded may be employed
within the scope of the invention. Id. at col. 20, ll. 30–32.
Figure 3 of Haskell is reproduced below:

Figure 3 of Haskell illustrates decoder system 200, which includes switch
controller 202, demultiplexer 203, decoder buffers 205-1 through 205-N,
IPR2013-00252
Patent 5,495,291
15
and decoders 208-1 through 208-N. Id. at col. 2, ll. 60–61; col. 11, ll. 49–
55; col. 13, ll. 35–48. Switch controller 202 identifies the packets of stream
112 that are incoming from the channel, and demultiplexer 203 switches the
packets to one of the corresponding decoder buffers 205-1 through 205-N.
Id. at col. 13, ll. 35–41. Haskell discloses that an advantage of such a
system is that it permits easy intermixing of any number of video, audio, and
other types of decoders into flexible configurations. Id. at col. 11, ll. 61–64.
Haskell further discloses that because decoder buffers 205 only have a finite
capacity, it is the responsibility of encoder 100 to ensure that the buffers do
not overflow or underflow. Id. at col. 14, ll. 12–15.
2. Rossmere (Ex. 1009)
Rossmere discloses a multimedia random access audio/video editing
system that allows users to configure the editing system to suit their needs.
Ex. 1009, col. 1, ll. 34–37. Rossmere’s system includes triple transfer
buffers, i.e., a present buffer, a past buffer, and a future buffer, which ensure
there is sufficient video and audio material in the present buffers to play,
such that a prospective user will not perceive discontinuities in either the
audio or video channel outputs. Id. at col. 2, ll. 40–46.
IPR2013-00252
Patent 5,495,291
16
Figure 3a of Rossmere is reproduced below:

Figure 3a illustrates analog video back panel 150 of main control unit (60
illustrated in Figure 1), analog I/O board 155, video processing board 158,
and effects board 160. Id. at col. 3, ll. 46–47; col. 6, l. 62–col. 7, l. 1.
Source video tape recorders (“VTRs”) 10 and 12 provide analog signals to
analog video back panel 150. Id. at col. 7, ll. 15–17. As shown in Figure 3a,
Rossmere provides the ability to bypass main control unit 60 by routing
signals selectively from VTR 10 and VTR 12 directly through switches 200
and 202 to video outputs A (67 illustrated in Figure 1) and B (66 illustrated
IPR2013-00252
Patent 5,495,291
17
in Figure 1). Id. at col. 7, ll. 7–21. Switches 200 and 202 are coupled,
respectively, to the video outputs provided over lines 684 and 686. Id. at
col. 11, ll. 26–28. The selection of switches 200 and 202 provide output
along lines 684 and 686, or direct output from the video inputs provided by
VTR 10 and VTR 12. Id. at col. 11, ll. 28–32.
3. Claim 1
a. “Input Switch . . . Capable of Controlling the Video Data Flow Rate”
Patent Owner argues that Petitioner’s proposed combination of
Haskell and Rossmere does not teach an input switch capable of controlling
the video data flow rate of the selected input lines, as recited in claim 1. PO
Resp. 15. Patent Owner contends that the Petition only points to Haskell’s
demultiplexer switch 203 as teaching or suggesting the input switch of
claim 1, and that demultiplexer switch 203, alone or in combination with
controller 202, does not perform the function of controlling the video flow
rate (i.e., controlling the time, duration, and rate at which video data flows,
and including some level of control beyond simply turning flow on or off).
Id. at 16, 20. Patent Owner further argues that Haskell’s demultiplexer
switch 203 turns on the flow of data to a particular decoder when a packet is
received for that decoder, and does not provide control of time, duration, or
rate at which video data flows. Id. at 17–18 (citing Ex. 1008, col. 3, ll. 35–
46), 20. Patent Owner also contends that in Haskell all data flow is
controlled on the encoder 100 side of the channel. Id. at 18–20 (citing Ex.
1008, Fig. 2; col. 2, ll. 5–12; col. 14, ll. 12–14; col. 15, ll. 32–38; col. 16, ll.
7–9; Ex. 1002 ¶ 264; Dec. on Institution 22).
IPR2013-00252
Patent 5,495,291
18
We are persuaded by Petitioner’s assertion that Patent Owner’s
arguments are predicated incorrectly on demultiplexer switch 203 alone as
teaching or suggesting the claimed input switch, and disregard the claim
construction of “switch” as including “a device or assembly for routing or
selecting a data stream.” Pet. Reply 3–5. As set forth in the Petition (Pet.
44), Haskell’s demultiplexer switch 203 of decoder 200 (illustrated in Fig. 3)
is coupled to compressed data streams via multiplexer switch 108 of encoder
100 (illustrated in Fig. 2). Thus, Petitioner’s position is that demultiplexer
switch 203 of decoder 200 together with multiplexer switch 108 of encoder
100 teaches or suggests the claimed input switch. Petitioner also asserts that
Haskell’s encoder 100 controls the flow of data through decoder 200. Pet.
44.
As pointed out by Petitioner, Patent Owner fails to address the
relevant components and functionality provided in the encoding system 100,
which includes multiplexer switch 108 communicatively coupled with
demultiplexer switch 203 of decoder 200. Pet. Reply 4–5. Patent Owner’s
arguments narrowly focus on demultiplexer switch 203, and do not address
sufficiently multiplexer switch 108 of encoder 100 together with
demultiplexer switch 203 of decoder 200 as capable of controlling the video
flow rate of the selected input lines (i.e., controlling the time, duration, and
rate at which video data flows, and including some level of control beyond
simply turning flow on or off).
Because Petitioner asserts that Haskell’s encoder 100 controls the
flow of data through decoder 200, and identifies Haskell’s demultiplexer 203
(part of encoder 200) and multiplexer 108 (part of encoder 100), as teaching
IPR2013-00252
Patent 5,495,291
19
or suggesting the claimed input switch capable of controlling the video flow
rate of the selected input lines (Pet. 44; see Pet. Reply 4–5), we are
persuaded by a preponderance of the evidence that Haskell in view of
Rossmere teaches or suggests an “input switch . . . capable of controlling the
video data flow rate of the selected input lines,” as recited in claim 1.
b. “A Controller Coupled to the Input Switch,
the Decompression Modules, and the Output Switch”
Patent Owner argues that Haskell does not disclose an output switch,
and therefore, Haskell’s controller 202 does not teach or suggest a controller
coupled to the output switch. PO Resp. 21–23 (citing Ex. 1008, col. 4,
ll. 26–28); see id. at 28. Patent Owner further argues that an output switch is
not necessarily disclosed in Haskell, as asserted in the Petition. Id. at 23.
Patent Owner’s arguments are not persuasive, because Petitioner does
not assert that Haskell explicitly or necessarily discloses an output switch.
See Pet. 45–46. Rather, Petitioner asserts that an output switch, “while not
explicitly recited in Haskell, would [have] be[en] obvious, with exemplary
suitable output switches provided in Haskell and at the fingertips of one with
ordinary skill.” Id. at 46 (citing Ex. 1002 ¶ 267). The Petitioner further
asserts that an output switch is a component readily found in prior art
decompression systems as being employed for selecting among data output
streams, and provides as an example Rossmere’s decompression system
using an output switch. Id. at 46–47 (citing Ex. 1002 ¶ 268; Ex. 1009,
Fig. 3(a); col. 10, l. 54–col. 11, l. 31).
Patent Owner argues that, even if it would have been obvious to
connect the output switch disclosed in Rossmere to the outputs of Figure 3
IPR2013-00252
Patent 5,495,291
20
of Haskell, there would be no reason for one of ordinary skill in the art to
couple Haskell’s switch controller 202 to the hypothetically included output
switch. PO Resp. 22. Similarly, Patent Owner argues that, even if a switch
was attached to the streams a, b, . . . , N of Haskell’s Figure 3, it would not
be obvious to couple Haskell’s switch controller 202 to that hypothetical
output switch, based on the disclosed functionality of Haskell’s switch
controller 202. PO Resp. 24–26 (citing Ex. 1008, col. 13, ll. 35–65). Patent
Owner contends that Haskell’s switch controller 202 only provides
command signal 204 to demultiplexer switch 203, and is not coupled to the
downstream components and any hypothetical downstream output switch
that would be positioned after decoders 208-1, 208-2, 208-3. Id. at 26.
Patent Owner further asserts that because no signal from Haskell’s switch
controller 202 could be a useful input to the hypothetical output switch, one
of ordinary skill in the art would not be inclined to couple switch controller
to such a hypothetical output switch. Id. at 26–27.
Patent Owner’s arguments, which narrowly focus on the disclosed
function of controller 202 in Haskell for sending control signals to
demultiplexer 203, are unpersuasive. Patent Owner’s arguments fail to
consider sufficiently the teachings of Haskell as a whole, or as combined
with the teachings of Rossmere (see Pet. Reply 9), from the perspective of
one with ordinary skill in the art. A prior art reference must be considered
for everything it teaches by way of technology, and is not limited to the
particular invention it is describing and attempting to protect. EWP Corp. v.
Reliance Universal Inc., 755 F.2d 898, 907 (Fed. Cir. 1985). Other than
mere attorney argument, Patent Owner does not provide sufficient or
IPR2013-00252
Patent 5,495,291
21
credible evidence that Petitioner’s proposed modification to Haskell’s
system—namely coupling an output switch to Haskell’s system—would
change the functionality or intended purpose of Haskell’s switch controller
202. Rather, “familiar items may have obvious uses beyond their primary
purposes, and in many cases a person of ordinary skill will be able to fit the
teachings of multiple patents together like pieces of a puzzle.” KSR Int’l Co.
v. Teleflex, Inc., 550 US 398, 420 (2007). We also are not persuaded by
Patent Owner’s arguments regarding obviousness and the reasoning and
inclination of one with ordinary skill in the art, because these arguments are
unsupported by objective evidence, such as, for example, testimony by one
with ordinary skill in the art. See Pet. Reply 8.
For these reasons, we are persuaded by a preponderance of the
evidence that Haskell in view of Rossmere would have rendered obvious “a
controller coupled to the input switch, the decompression modules, and the
output switch,” as recited in claim 1.
c. Haskell Teaches Away From the Combination with Rossmere
Patent Owner asserts that a person of ordinary skill in the art would
not be inclined to combine Haskell and Rossmere due to an explicit teaching
away from the combination in Haskell. PO Resp. 27. Patent Owner asserts
that the inclusion of output switches 200, 202 in Rossmere makes sense
because Rossmere’s Video Output A and Video Output B can only handle a
single video input. Id. at 28–29 (citing Ex. 1009, Fig. 3; col. 7, ll. 16–20,
col. 11, ll. 25–31). Patent Owner contends that Haskell’s disclosure is
different from Rossmere, and directs attention to the following disclosure in
Haskell:
IPR2013-00252
Patent 5,495,291
22
it is presumed that each of the parts of the individual encoded
bit-streams 111 are associated together by virtue of having been
generated during the same real time period. For example,
unencoded bit-stream 111-1 could be a series of frames that
show a person speaking, and unencoded bit-stream 111-2 could
be a series of audio frames containing a digitized representation
of what was spoken.
PO Resp. 30 (citing Ex. 1008, col. 11, ll. 25–34). On this basis, Patent
Owner asserts that the entire purpose of Haskell is to recreate the same
signals (e.g., video, audio) at the output of its system in order to compensate
for the variable bit-rate transmission channel. Id. Patent Owner further
asserts that including an output switch in Haskell’s system for selecting
between streams that include video on stream a and corresponding audio on
stream b would defeat the purpose of dividing those streams into time
correlated components by demultiplexer switch 203. Id. Patent Owner
argues that utilizing an output switch, as disclosed in Rossmere, for selecting
between video stream a and corresponding audio stream b would require
serial processing of those streams and mismatching of video and audio,
thereby destroying the desired functionality of Haskell’s preferred
embodiment of Haskell. Id. Patent Owner further argues that, because
adding Rossmere’s output switch to Haskell would destroy the desired
functionality of Haskell’s preferred embodiment, Haskell would teach one of
ordinary skill in the art away from trying such a combination. Id. at 32.
We are not persuaded by Patent Owner’s arguments. As pointed out
by Petitioner, Patent Owner does not identify any explicit teaching away
from the combination in Haskell. Pet. Reply 9–10. “Under the proper legal
standard, a reference will teach away when it suggests that the developments
IPR2013-00252
Patent 5,495,291
23
flowing from its disclosures are unlikely to produce the objective of the
[patented] invention.” Syntex (U.S.A.) v. Apotex, Inc., 407 F.3d 1371, 1380
(Fed. Cir. 2005) (citing In re Gurley, 27 F.3d 551, 553 (Fed. Cir. 1994)).
Patent Owner does not explain sufficiently how Haskell suggests that any
developments flowing from its disclosures are unlikely to produce a
decompression system including an output switch. Rather, as noted by
Petitioner, Patent Owner’s arguments focus on a portion of Haskell’s
disclosure that is exemplary and not limiting. Pet. Reply 10–11 (citing
Ex. 1008, col. 11, ll. 25–41). Petitioner correctly points out that Haskell is
not limited to operating on related input types (i.e., video and audio streams
generated during the same time period), but that Haskell discloses that
“[a]ny signals capable of being divided into units and encoded may be
employed within the scope of the invention.” Id. at 11 (citing Ex. 1008,
col. 20, ll. 30–32).
Patent Owner’s arguments regarding the addition of an output switch
are predicated incorrectly on preserving the function and intended purposed
of Haskell’s system operating on the exemplary video and audio signals that
were generated during the same time period. Instead, Haskell must be
considered for everything it teaches. EWP Corp., 755 F.2d at 907. As set
forth in the Petition, “[i]t would [have] be[en] obvious to a person of
ordinary skill in the art to combine the system disclosed in Haskell with an
input and output switch, which were well-known in the art[,] including in
Rossmere, in order to select separate decoded video signals.” Pet. 47.
Petitioner further asserts that
IPR2013-00252
Patent 5,495,291
24
doing so would be making use of a known component for a
known use, and . . . would allow one to make use of the video
output of Haskell in a manner ‘such that the user will not
perceive any discontinuities in either the audio or the video
channel outputs’ as specifically recited in Rossmere.
Id. (citing Ex. 1002 ¶ 269).
For these reasons, we are not persuaded by Patent Owner’s arguments
that Haskell provides an explicit teaching away from the combination with
Rossmere.
We also are not persuaded by Patent Owner’s repeated argument that
there is no reason, absent hindsight reliance on the teachings of the ’291
Patent, for a person of ordinary skill to contemplate adding an output switch
to generate a single continuous output stream from the outputs of Haskell’s
system. PO Resp. 30; see Prelim. Resp. 36. Patent Owner’s arguments
presented in the Response are identical substantially to the arguments
presented in the Preliminary Response, and Patent Owner does not offer any
additional evidence in its Response to support its arguments. Compare PO
Resp. 30, with Prelim. Resp. 36. As explained in our Decision on
Institution, Patent Owner does not provide sufficient evidence to support this
assertion, or sufficient evidence or argument addressing the technological
difficulties that may prevent one with ordinary skill in the art from
combining the teachings of Haskell and Rossmere to arrive at the invention
embodied in claim 1. See Dec. on Institution 29.
For these reasons, we are persuaded by a preponderance of the
evidence that Haskell in view of Rossmere would have rendered obvious the
invention of claim 1.
IPR2013-00252
Patent 5,495,291
25
4. Claims 2–10
Patent Owner asserts that independent claim 9 recites a similar input
switch (i.e., first switch), a similar controller coupled to an output switch
(i.e., second switch), and a similar second switch that directs output from the
at least two video data decompression arrays, as claim 1. PO Resp. 21, 27,
32. On this basis, Patent Owner argues that the ground of unpatentability of
claim 9 is insufficient for the same reasons that the ground of unpatentability
of claim 1 is insufficient. Id. Additionally, Patent Owner does not present
arguments addressing specifically the limitations of claims 2–8, dependent
from claim 1, and claim 10, dependent from claim 9. See id. For the same
reasons as discussed above with respect to claim 1, we are persuaded by a
preponderance of the evidence that Haskell in view of Rossmere would have
rendered obvious the invention of claims 2–10.
C. Obviousness of Claims 11–16
With respect to the assertions of unpatentability of dependent claims
11–16, we have reviewed the Petition, Patent Owner Response, and
Petitioner’s Reply, as well as the evidence discussed in each of those papers.
We are not persuaded by a preponderance of the evidence that claims 11–16
are unpatentable under 35 U.S.C. § 103(a) over Haskell and Rossmere. See
Pet. 51–52.
Claim 11 depends from independent claim 9, and further recites:
the controller commands the first switch to provide video data
to the first video data decompression array at a first rate and to
provide video data to the remaining video data decompression
arrays at a second rate a predefined period of time after the first
video data array begins receiving the video data at the first rate.
IPR2013-00252
Patent 5,495,291
26
Ex. 1001, col. 7, ll. 26–31.
We agree with Patent Owner’s argument that the Petition does not
account for the “predefined period of time” language of claim 11. PO Resp.
34 (citing Pet. 51; Ex. 1002 ¶ 282). The Petition does not address the
claim 11 recitation of “the controller commands the first switch . . . to
provide video data to the remaining video data decompression arrays at a
second rate a predefined period of time after the first video data array begins
receiving the video data at the first rate.” See Pet. 51 (emphasis added).
In the Reply, Petitioner asserts for the first time that Haskell teaches
or suggests “provid[ing] video data to the remaining video decompression
arrays . . . a predefined period of time after the first video data array begins
receiving the video data at the first rate,” because Haskell discloses the use
of a predetermined system timing with regard to providing video data to
decoder buffers (205-1, 205-2, 205-N). Pet. Reply 13 (citing Ex. 1008,
col. 13, ll. 7–54). Petitioner’s arguments in the Reply are improper because
they are not responsive to arguments raised in the Patent Owner Response.
See 37 C.F.R. § 42.23. Patent Owner’s Response does not direct attention to
Haskell’s disclosure of using a predetermined system timing for providing
video data to the decoder buffers. See PO Resp. 33–35. Petitioner’s
improper argument raised for the first time in the Reply will not be
considered, because it is not accompanied by a showing of good cause
explaining why it could not have been presented in the Petition. In any
event, even if Petitioner’s arguments were to be considered, Petitioner does
not explain sufficiently how Haskell’s use of predetermined system timing
for providing video data to decoder buffers (205-1, 205-2, 205-N), teaches
IPR2013-00252
Patent 5,495,291
27
or suggests a controller that commands the first switch to provide video data
to the remaining video decompression arrays at a second rate a predefined
period of time (i.e., a prior defined period of time) after the first video data
array begins receiving the video data at the first rate.
Accordingly, Petitioner has not demonstrated by a preponderance of
the evidence that Haskell in view of Rossmere would have rendered obvious
the invention of dependent claim 11, and claims 12–16 dependent therefrom,
because Petitioner has not demonstrated by a preponderance of the evidence
that Haskell in view of Rossmere teaches or suggests “the controller
commands the first switch . . . to provide video data to the remaining video
decompression arrays at a second rate a predefined period of time after the
first video data array begins receiving the video data at the first rate,” as
recited in claim 11.
III. CONCLUSION
Petitioner has demonstrated by a preponderance of the evidence that
claims 1–10 are unpatentable under 35 U.S.C. § 103(a) over Haskell and
Rossmere. Petitioner has not demonstrated by a preponderance of the
evidence that claims 11–16 are unpatentable under 35 U.S.C. § 103(a) over
Haskell and Rossmere.
IV. ORDER
Accordingly, it is:
ORDERED that Petitioner has demonstrated by a preponderance of
the evidence that claims 1–10 of the ’291 Patent are unpatentable;
IPR2013-00252
Patent 5,495,291
28
FURTHER ORDERED that Petitioner has not demonstrated by a
preponderance of the evidence that claims 11–16 of the ’291 Patent are
unpatentable; and
FURTHER ORDERED that because this is a final decision, parties to
the proceeding seeking judicial review of the decision must comply with the
notice and service requirements of 37 C.F.R. § 90.2.

IPR2013-00252
Patent 5,495,291
29

For PETITIONER:

Michael Rosato
James Yoon
WILSON SONSINI GOODRICH & ROSATI
mrosato@wsgr.com
jyoon@wsgr.com

For PATENT OWNER:
David B. Cochran
Joseph M. Sauer
JONES DAY
dcochran@jonesday.com
jmsauer@jonesday.com

Tod M. Melger
Jacob Martinez
Neal McLaughlin
CHADBOURNE & PARKE LLP
tmelgar@chadbourne.com
jmartinez@chadbourne.com
nmclaughlin@chadbourne.com