`
`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––
`
`NETFLIX, INC.,
`
`Petitioner,
`
`v.
`
`REALTIME ADAPTIVE STREAMING, LLC,
`
`Patent Owner.
`
`––––––––––
`
`Case No. 2018-01187
`
`U.S. Patent 9,769,477
`
`––––––––––
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`
`

`

`TABLE OF CONTENTS
`
`IPR2018-01187 Reply
`
`
`Page
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Limitation 1[b] is rendered obvious by Imai and Pauls. ................................. 2
`
`A.
`
`B.
`
`C.
`
`Imai and Pauls teach systems designed to include multiple
`encoders having different data compression rates. ............................... 3
`
`Realtime’s argument that the term “configured to” requires
`showing an “intentional design choice” is not supported. .................... 7
`
`The difference in the encoders’ data compression rates do not
`arise “by happenstance” nor “as a side effect.”..................................... 8
`
`1.
`
`2.
`
`3.
`
`The prior art teaches intentionally using two encoders
`having different data compression rates. .................................... 9
`
`The prior art teaches that choosing between encoders that
`have different data compression rates allows a system to
`better match an incoming data stream to the rate of a
`communications channel. .......................................................... 11
`
`A POSITA would have understood that different
`encoders (such as those described in Imai) would have
`different data compression rates. .............................................. 13
`
`III. A POSITA would have been motivated to combine Imai and Pauls. ........... 16
`
`IV. The additional limitations of claim 20 are rendered obvious by Imai
`and Pauls. ....................................................................................................... 20
`
`A.
`
`B.
`
`Imai teaches intentionally including two encoders that have
`different compression ratios, in addition to encoders that have
`varying compression rates. .................................................................. 20
`
`A POSITA would have known how to use JPEG to encode
`video. ................................................................................................... 22
`
`V. A POSITA would have been motivated to combine Chao with Imai
`and Pauls. ....................................................................................................... 23
`
`VI. Conclusion ..................................................................................................... 24
`
`
`
`
`
`
`i
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`I.
`
`Introduction
`
`Realtime’s POR in this proceeding and the related IPR2018-01630
`
`proceeding raise substantially the same arguments. Realtime’s expert admitted that
`
`Imai teaches switching compression encoders based on the throughput of a
`
`communications channel, that it teaches including multiple encoders in a system,
`
`and that each encoder should use a different coding method. Ex. 1029 at 129:11-
`
`19, 130:22-131:3, 131:4-17. In addition, Realtime does not dispute the correctness
`
`of any of Netflix’s claim constructions.
`
`Realtime primarily disputes whether a POSITA would have found it obvious
`
`to include in a video/image compression system two different compression
`
`encoders that have different data compression rates (for independent claim 1), or
`
`two different compression encoders that have different data compression ratios (for
`
`independent claim 20). But as Realtime’s own expert conceded, encoders (even
`
`those implementing the same algorithm) inevitably have different compression
`
`rates and ratios. Id. at 68:24-70:21, 71:23-72:24. The Board should also reject this
`
`argument because at least paragraphs 67-68 of Imai teach arranging five different
`
`encoders in a system where two of the encoders vary in their data compression
`
`rates and another two encoders vary in their data compression ratios.
`
`Realtime also argues that the Petition does not adequately describe how to
`
`combine the references, and does not adequately account for alleged disadvantages
`
`
`
`
`
`
`1
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`of making the combinations. But, Realtime cannot seriously contend that a
`
`POSITA would not know how to select or implement video or image compressor
`
`encoders that vary in their data compression rates or compression ratios because
`
`the ’477 Patent is devoid of any explanation of how to implement any video or
`
`image compression encoder, let alone how to vary their data compression rates or
`
`compression ratios. See Ex. 1003 ¶¶77-80. Finally, there is no merit to Realtime’s
`
`argument that a POSITA would not have been motivated to make the combinations
`
`suggested in the Petition due to the existence of alleged disadvantages because
`
`such an analysis is inconsistent with KSR and none of the cases cited by Realtime
`
`undermine the Petition’s showing of motivations.
`
`II. Limitation 1[b] is rendered obvious by Imai and Pauls.
`
`Realtime reprises its argument from the POPR that the Petition does not
`
`sufficiently demonstrate that a first asymmetric data compression encoder “is
`
`configured to compress data…at a higher data compression rate” than a second
`
`asymmetric data compression encoder because “configured to” requires showing
`
`that the difference between the encoders’ data compression rates must arise by “an
`
`intentional design choice” as opposed to arising by “a side effect of some other
`
`design choice, or by chance.” Compare POR 17-19 with POPR 11-15 (emphasis
`
`added). The Board should again reject Realtime’s arguments because (1) Imai and
`
`Pauls teach systems designed to include multiple encoders having different data
`
`
`
`
`
`
`2
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`compression rates; (2) the cases cited by Realtime do not support its proposed
`
`“intentional design choice” requirement; and, in any event, (3) it would have been
`
`obvious to a POSITA to intentionally choose a specific first encoder and a specific
`
`second encoder that have different data compression rates.
`
`A.
`
`Imai and Pauls teach systems designed to include multiple
`encoders having different data compression rates.
`
`Realtime cannot demand that the data compression rate limitations (1[b]) be
`
`shown in haec verba because its expert admits that “data compression rate” is not a
`
`commonly-used term (Ex. 1029 at 51:4-52:8), and he was unaware of any
`
`commonly-used term that captures the ’477 Patent’s manner of measuring data
`
`compression rate (id. at 62:6-63:25). Nevertheless, it would have been obvious to
`
`a POSITA to build a system having at least two encoders where one encoder has a
`
`faster data compression rate than the other.
`
`Imai indisputably teaches a system having a plurality of asymmetric data
`
`compression encoders. Pet. 16, 20-23; Ex. 1005 at [0067]-[0068]. Imai expressly
`
`teaches that the encoders included in a system should vary in a number of ways,
`
`such as compression ratio, execution speed, and suitability for compressing
`
`particular data-types. Ex. 1005 at [0067]. With respect to execution speed, Imai
`
`teaches that the plurality should include a computationally slower encoder and a
`
`computationally faster encoder:
`
`
`
`
`
`
`3
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`a method which requires a larger amount of computation for decoding
`
`(such a method usually also requires a larger amount of computation
`
`for coding), [and] a method which requires a not so large amount of
`
`computation for decoding….
`
`Id. at [0067]. Dr. Storer testified that this teaching of “coding methods that differ
`
`in the amount of computation required…is directly related to execution speed or
`
`data compression rate.” Ex. 1003 ¶136. ATRAC is given as an example of a faster
`
`compression rate encoder: “[o]ne example of the coding method, which requires a
`
`not so large amount of computation for decoding, is ATRAC.” Ex. 1005 at [0068];
`
`Ex. 1003 ¶138. Realtime cannot dispute that this evidence teaches using encoders
`
`with different execution speeds because Dr. Zeger admitted that the plain and
`
`ordinary meaning of execution speed of a compression algorithm relates to
`
`measuring the amount of computation: “Ultimately, it’s a measure of something,
`
`whether it be data process—how much data is processed, how many seconds it
`
`takes for something to happen, how many CPU cycles are used, something of that
`
`nature.” Ex. 1029 at 65:5-66:22.
`
`Further evidence that a POSITA would have found it obvious to implement
`
`the data compression rate limitations is Imai’s suggestion of using several
`
`ATRAC2 encoders that operate at different bit rates. Ex. 1005 at [0069]. Dr.
`
`Storer provided several paragraphs of explanation for why a POSITA would have
`
`understood that this teaches encoders with different data compression rates.
`
`
`
`
`
`
`4
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`Ex. 1003 ¶¶139-42. Realtime’s response is that the specific numbers used to
`
`quantify the ATRAC 2 encoders (e.g., 64, 32, or 24 kbps) are measurements of
`
`output data rates and are not measurements of data compression rates. POR 28-30.
`
`However, this argument misses the mark because a POSITA would have
`
`understood Imai’s differing rates indicate that the different encoders are operating
`
`at different data compression rates. For example, Dr. Storer explained how
`
`modifying an encoder to operate at a different execution speed produces the
`
`different output rates. Ex. 1003 ¶141. Moreover, Realtime’s expert admitted that
`
`the general relationship between data compression rate (as used in the ’477 Patent)
`
`and the output rate is that an increase in the data compression rate increases the
`
`output rate of the encoder:
`
`Q. So if you use a faster data compression rate, you achieve a higher
`
`output rate?
`
`A. Well, if you use a faster data compression rate — if you go back to
`
`the definition of data compression rate as measuring the amount of
`
`input data that can compress per unit of time at a given compression
`
`ratio, so if you increase the data compression rate, you’re pulling in
`
`more input data per unit time at a given compression ratio. So that
`
`would — in general, that would increase the output rate of the
`
`encoder, so you’d be having to send more data across the channel.
`
`Ex. 1029 at 148:13-24. Realtime’s expert admitted that the reverse is true: a lower
`
`data compression rate generally reduces the output bit rate of an encoder. Id. at
`
`
`
`
`
`
`5
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`149:13-23. Given these general understandings of the relationship between data
`
`compression rate and output bit rate, a POSITA would have understood that Imai’s
`
`description of encoders having different bit rates suggests encoders having
`
`different data compression rates.
`
`A POSITA would have also found the data compression rate limitations
`
`(1[b]) obvious in view of Pauls’ teachings. Similar to Imai, Pauls teaches a system
`
`that has multiple, different encoders, which include H.263, MPEG, and MPEG2
`
`encoders. Pet. 39; Ex. 1007 at [0010], FIG. 5. Dr. Storer explained that a POSITA
`
`would have understood that the H.263, MPEG, and MPEG2 encoders have
`
`different data compression rates based upon Pauls’ teaching that each of the
`
`encoders “have associated different levels or percentages of compression,” Pauls’
`
`teaching that each of the encoders have different bit rates, and a POSITA’s own
`
`knowledge of the performance of these well-known standardized encoders.
`
`Ex. 1003 ¶¶176-78.
`
`Realtime states that this evidence does not teach the data compression rate
`
`limitations based on its arguments that a compression ratio or an output bit rate
`
`does not demonstrate different data compression rates. The Board should reject
`
`Realtime’s argument for at least the reason that Dr. Zeger admitted that there is a
`
`relationship between an encoder’s output bit rate and its data compression rate,
`
`which supports Dr. Storer’s opinion. See Ex. 1029 at 148:13-24, 149:13-23. In
`
`
`
`
`
`
`6
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`addition, the POR does not respond to Dr. Storer’s opinion that a POSITA would
`
`have understood that the data compression rate limitations are present in light of a
`
`POSITA’s own knowledge concerning the performance of the well-known H.263,
`
`MPEG, and MPEG2 encoders. Ex. 1003 ¶¶176-78. The Board credited Dr.
`
`Storer’s testimony “regarding the compression rates of the asymmetric algorithms
`
`of MPEG, MPEG2, and H.263 and the impact of such rates” (ID 27-28), and the
`
`POR provides no principled reason for the Board to change its finding.
`
`B. Realtime’s argument that the term “configured to” requires
`showing an “intentional design choice” is not supported.
`
`The Board should reject Realtime’s invitation to interpret the claim language
`
`“configured to” to require a nebulous “intentional design choice.” Realtime’s
`
`argument is particularly problematic because it does not provide any objective
`
`standard by which to judge whether a particular design choice is within the scope
`
`of the claims. For example, Realtime states that its interpretation of “configured
`
`to” limitation “cannot be met by…a difference in compression rates arising as a
`
`side effect of some other design choice.” POR 20.
`
`Moreover, the cases cited by Realtime do not support its narrow
`
`interpretation of “configured to.” In Aspex, the plaintiff challenged the district
`
`court’s construction of the term “adapted to,” arguing that the court construed the
`
`phrase “adapted to” too narrowly; [and] that phrase, should be interpreted to mean
`
`“suitable for” rather than “made to.” The court disagreed and stated “in this case,
`
`
`
`
`
`
`7
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`we conclude that the narrower meaning is correct,” explaining that while it could
`
`have a broader meaning, “[t]he way the phrase is used in [the claim] supports the
`
`districts court’s conclusion that a narrower definition, such as ‘configured to,’
`
`applies here.” Aspex Eyewear, Inc. v. Marchon Eyewear, Inc., 672 F.3d 1335,
`
`1349 (Fed. Cir. 2012). Aspex does not support the intent requirement suggested by
`
`Realtime because the Federal Circuit was construing the term “adapted to” and not
`
`“configured to.” Id. The Court also stated that its construction was specific to the
`
`facts of the case and that patent. Id.
`
`Realtime also advocates for a limitation absent from the claims – that a
`
`system must switch from an encoder with a relatively slow compression rate to an
`
`encoder having a faster rate of compression, otherwise “[t]he invention would not
`
`function if the relationship were reversed.” POR 20-21. Instead, the claims
`
`require selecting an encoder based upon other parameters other than compression
`
`rate, such as the “throughput of a communications channel.” Ex. 1001, cls. 1, 20.
`
`Realtime’s argument also fails as a matter of logic: If it were beneficial to only
`
`switch from a slower compression rate to a faster compression rate, why would
`
`anyone ever use the slower compression rate encoder?
`
`C. The difference in the encoders’ data compression rates do not
`arise “by happenstance” nor “as a side effect.”
`
`The Board should find that a POSITA would have found it obvious to
`
`intentionally include a first asymmetric data encoder that has a faster data
`
`
`
`
`
`
`8
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`compression rate than a second asymmetric data encoder because (1) Imai teaches
`
`combining encoders in that way, (2) Imai teaches that it is beneficial to combine
`
`encoders in that way, and (3) a POSITA would have understood Imai’s teaching to
`
`use different encoders means that the encoders would have different data
`
`compression rates.
`
`1.
`
`The prior art teaches intentionally using two encoders
`having different data compression rates.
`
`A POSITA would have found it obvious to intentionally choose to include
`
`two different encoders that have different data compression rates in a system built
`
`according to the principles taught by the prior art. As explained above in Section
`
`II.A, a POSITA would have understood that Imai’s description of an encoder that
`
`uses a larger amount of computation and an encoder that uses “a not so large
`
`amount” of computation teaches encoders that have different data compression
`
`rates. Moreover, those same portions of Imai teach that including two encoders
`
`having different data compression rates is an intentional design choice:
`
`[T]he encoders 531 to 53N are prepared by using encoders which
`
`perform encoding … with various coding methods, including a
`
`method which provides a relatively large (high) bit rate of the
`
`resulting coded data…, a method which can provides a relatively
`
`small (low) bit rate of the resulting coded data…, a method which
`
`requires a larger amount of computation for decoding (such a
`
`method usually also requires a larger amount of computation for
`
`coding), a method which requires a not so large amount of
`
`
`
`
`
`
`9
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`computation for decoding, and a method particularly suitable for
`
`coding a voice….
`
`Ex. 1005 at [0067]. In addition, Section II.A above also explains how Imai’s
`
`description of multiple ATRAC2 encoders with different bit rates teaches using
`
`encoders with different data compression rates. Paragraph 69 describes that
`
`arrangement, and it thus teaches a POSITA to build a system that has encoders that
`
`differ in their data compression rates. Id. at [0069]. Finally, the Petition explains
`
`that a POSITA would have also found it obvious to select among different
`
`encoders having higher and lower data compression rates in order to better match
`
`the incoming data stream to the throughput of the communication channel. Pet. 22.
`
`The Board considered and credited this evidence in the Institution Decision
`
`where it rejected the same argument that Realtime is now raising, finding that “the
`
`Petition’s citations to these encoders and Imai’s teachings regarding the function of
`
`encoders 531 to 53N that would render one of them a ‘first encoder’ and another
`
`one a ‘second encoder’ [as] required by the claim.” ID 19. The Board also found
`
`that “Imai specifically discloses that the encoders are constructed to encode the
`
`audio signal with different coding methods from each other, thus, the different
`
`rates of encoding would not be happenstance.” Id. The POR does not identify a
`
`specific flaw in either finding, and the Board should again reject Realtime’s
`
`arguments.
`
`
`
`
`
`
`10
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`2.
`
`The prior art teaches that choosing between encoders that
`have different data compression rates allows a system to
`better match an incoming data stream to the rate of a
`communications channel.
`
`Choosing between encoders that have different data compression algorithms
`
`is an intentional design choice that achieves the goal of better matching an
`
`incoming data stream to the rate of the communications channel. The Petition
`
`explains that a POSITA would have found it obvious to select among different
`
`encoders having higher and lower data compression rates to better match the
`
`incoming data stream to the throughput of the communication channel.” Pet. 22.
`
`The Board credited that rationale at institution. ID 20 (“Petitioner’s rationale for
`
`selecting different encoders in Imai with higher and lower data compression rates
`
`to better match the transmission rate of the communication channel [is] adequate
`
`for institution.”) (citation omitted).
`
`In addition to the evidence submitted with the Petition, Dr. Storer explained
`
`at his deposition how Imai works and why it teaches choosing between encoders
`
`having different data compression rates in order to achieve real-time encoding of a
`
`data, transmission to a client, and decoding at the client:
`
`Imai actually describes an end-to-end system…[that] has to take into
`
`consideration both speed and compression ratio and other factors in
`
`order to actually ensure a real time system…. And so Imai actually
`
`shows and describes having multiple encoders and choosing an
`
`encoder in order to achieve this goal of throughput…[W]hat affects
`
`
`
`
`
`
`11
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`throughput is both the speed of the encoder and the compression ratio
`
`…you need to encode in such a way that you both have speed that’s
`
`appropriate and a compression ratio that is appropriate.
`
`See Ex. 2003 at 62:22-66:3.
`
`Dr. Storer goes on to explain why Imai’s system needs encoders with
`
`different data compression rates in order to achieve real-time encoding and
`
`decoding:
`
`Really fast doesn’t help you if the compression ratio is not enough
`
`because it won’t go over the channel, and really good compression
`
`doesn’t help you if you don’t do it fast enough…So Imai has
`
`multiple…encoders that have different properties in terms of
`
`speed and compression ratio and, of course, data type…Imai talks
`
`specifically how a different encoder may do a better job with one
`
`data type than the other…. It’s actually taking into
`
`account…several considerations, including both speed and
`
`compression ratio, because they are related…in fact, Imai even goes
`
`further to talk about measuring the speed of the decoder because
`
`that’s also necessary as part of the chain in order to guarantee the
`
`end-to-end throughput.
`
`Id. at 65:2-65:19.
`
`Lastly, Realtime argues that Dr. Storer suggests lowering an encoder’s
`
`compression speed to reduce an output bitrate to better match the needs of real-
`
`time reproduction. POR 32-33. But, the opinions Realtime points to describe one
`
`way of modifying the compression rate of an encoder, not Dr. Storer’s opinion for
`
`
`
`
`
`
`12
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`how Imai teaches switching between encoders based upon the throughput of a
`
`communications channel (see Ex. 1003 ¶154).
`
`3.
`
`A POSITA would have understood that different encoders
`(such as those described in Imai) would have different data
`compression rates.
`
`Trying to distract the Board, Realtime suggests that the prior art only teaches
`
`or suggests data compression encoders with different data compression rates by
`
`“mere happenstance.” POR 22. Thus, Realtime portrays Imai as having
`
`speculative teachings regarding the use of various encoders, leaving a reader to
`
`guess how the system operates. Id. at 16 (“[Imai] discloses encoders by referring
`
`to their encoding standards and output rates, and does not permit any finding than
`
`any one of Imai’s encoders would be ‘configured’ to be faster than any other on a
`
`systematic and predictable basis”); id. at 24 ( “the mere possibility that Imai might
`
`sometimes operate [as recited in Claim 1]”) (emphasis in original).
`
`But the Petition does not rely on the mere possibility that two of Imai’s
`
`encoders will have different data compression rates to establish unpatentability.
`
`Rather, the Petition observes that a POSITA would have understood that it is
`
`exceedingly unlikely that any two different encoders have the same data
`
`compression rate. Pet. 40. That fact is just one additional piece of evidence that a
`
`POSITA would have understood from Imai’s description of different encoders that
`
`
`
`
`
`
`13
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`vary in relative computational intensity and bit rate (explained above in §II.A)
`
`teaches using encoders that have different data compression rates. Pet. 22.
`
`Imai teaches a system specifically designed to have encoders with varying
`
`characteristics and capabilities (including data compression rate), in order to allow
`
`the system to select a particular encoder. See §II.A; Ex. 1003 ¶¶136, 142-43. Dr.
`
`Storer explained that a POSITA would have understood that any two different
`
`encoders in Imai would have different data compression rates because “it is only a
`
`remote possibility (i.e., exceedingly unlikely) that two different implementations of
`
`even the same compression algorithm would have the same execution speed or
`
`data compression rate.” Id. at ¶137. He explained that it is well-known in
`
`computer science that “the structure and ordering of computation steps of a
`
`program” (such as an implementation of a compression algorithm) “has an impact
`
`on speed.” Id. Thus, factors such as a particular programmer’s style affects
`
`execution speed. Id. He further explains that the potential for creating a better
`
`implementation of even a well-known algorithm explains why companies spend
`
`money developing their own implementations. Id.
`
`Dr. Zeger supported Dr. Storer’s opinion when he conceded that separately-
`
`written encoders implementing the same compression algorithm are not certain to
`
`have the same execution speed:
`
`
`
`
`
`
`14
`
`
`
`
`
`

`

`Q. If two persons of ordinary skill in the art wrote their own
`
`implementations of a compression algorithm, will they have the same
`
`IPR2018-01187 Reply
`
`
`execution speed?
`
`A. They could.
`
`Q. Are they certain to have the same execution speed?
`
`A. No.
`
`Q. Why are they not certain to have the same execution speed?
`
`A. You’re giving me a hypothetical without knowing the details, but,
`
`you know, conceivably they have different processors. Depends how
`
`you define “execution speed” also. They might have written a
`
`program in a different way. There is many reasons.
`
`Ex. 1029 at 68:24-69:12. He also admitted that a programmer may write an
`
`implementation of a compression algorithm that is “very efficient software” while
`
`another programmer may write an implementation that is inefficient. Id. at 69:13-
`
`70:15. Dr. Zeger noted that there are a number of factors that impact the efficiency
`
`of software code, such as the ability of the programmer, or different ways of
`
`writing software code.
`
`Q. Okay. How is it possible that a person of ordinary skill in the art
`
`implementing a compression algorithm can write it more efficiently
`
`versus less efficiently?
`
`A. Well, a person could use good programming skills or poor
`
`programming skills.
`
`Id. at 70:16-21; see also id. at 72:7-24. More incredibly, he could not say whether
`
`well-known compression algorithms are typically asymmetric, even though he
`
`
`
`
`
`
`15
`
`
`
`
`
`

`

`considers himself a person of “beyond ordinary” skill. Ex. 1028; Ex. 1029 at 37:5-
`
`IPR2018-01187 Reply
`
`
`38:25, 48:16-21.
`
`Thus, contrary to Realtime’s suggestion that two of Imai’s different encoders
`
`will have different data compression rates “by happenstance,” a POSITA would
`
`have instead understood that two different encoders are extremely unlikely to have
`
`the same data compression rate and therefore are most likely to have different data
`
`compression rates.
`
`III. A POSITA would have been motivated to combine Imai and Pauls.
`
`Realtime concedes that “the motivation to combine inquiry is necessarily
`
`fact-specific” and that a “simpler combination entails a lower hurdle than a more
`
`complex one.” POR 2. Realtime proceeds to ignore both axioms and argues the
`
`Petition does not establish an adequate motivation to combine based on strict legal
`
`tests proposed by Realtime. The Board should reject Realtime’s arguments
`
`because the Petition describes why a POSITA would be motivated to combine the
`
`teachings of Imai and Pauls, and Realtime’s arguments are not supported by law.
`
`Imai teaches a system with encoders 531 to 53N that can include asymmetric
`
`encoders. Pet. 11. It includes a broad teaching of using various encoders in its
`
`system to allow for selection between encoders with different characteristics and
`
`functionality, and explains that while examples in the specification address audio
`
`coding, its teachings are equally applicable to video. Ex. 1005 at [0172]. Pauls,
`
`
`
`
`
`
`16
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`another reference that like Imai teaches a system containing a multitude of
`
`encoders that can be selected from, is used to provide specific examples of video
`
`encoders that existed at the time that could be used with the teachings of Imai.
`
`Pet. 13, 53. A POSITA would thus have been motivated to combine the systems of
`
`Imai and Pauls to utilize the numerous video and image data compression encoders
`
`of Pauls to enable video compression in Imai’s system. Id. at 53 (citing Ex. 1003
`
`¶¶211-14).
`
`The Petition’s stated motivation to combine supports a finding of
`
`obviousness. “It is well-established that a determination of obviousness based on
`
`teachings from multiple references does not require an actual, physical substitution
`
`of elements.” In re Mouttet, 686 F.3d 1322, 1332 (Fed. Cir. 2012) (collecting
`
`cases). “Rather, the test for obviousness is what the combined teachings of the
`
`references would have suggested to those having ordinary skill in the art.” Id. at
`
`1333. As the Petition shows, the combination of Imai’s and Pauls’ teachings
`
`would have predictable results and a reasonable expectation of success given the
`
`similarities in the systems, and given that audio and video compression
`
`technologies were well-known and related at the time of the alleged invention.
`
`Pet. 53 (citing Ex. 1003 at 213).
`
`Contrary to Realtime’s assertions in its POR, none of the cited cases
`
`undermine the Petition’s stated motivation to combine. First, Realtime errs in its
`
`
`
`
`
`
`17
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`reliance on Winner International Royalty Corp. v. Wang, 202 F.3d 1340 (Fed. Cir.
`
`2000) to create a new requirement of showing that “the benefits justify the costs”
`
`of making the combination. POR 54. But, Winner was decided under the TSM
`
`test of yore, 202 F.3d at 1348 (looking for “[e]vidence of a suggestion, teaching, or
`
`motivation to combine prior art references”) and its analysis pertains to an obsolete
`
`approach to the obviousness inquiry. To the extent Winner imposes a benefits-cost
`
`test, it is the same sort of “rigid rule” that improperly limits the question of
`
`obviousness that the Supreme Court rejected in KSR. See KSR International Co. v.
`
`Teleflex Inc., 550 U.S. 398, 419 (2007).
`
`In any event, Realtime distorts the case. In Winner, while the court accepted
`
`the trial court’s finding of a teaching away, it made sure to caution that “[t]he fact
`
`that the motivating benefit comes at the expense of another benefit, however,
`
`should not nullify its use as a basis to modify the disclosure of one reference with
`
`the teachings of another.” 202 F.3d at 1349 n.8; see also Medichem, S.A. v.
`
`Rolabo, S.L., 437 F.3d 1157, 1165, (Fed. Cir. 2006) (explaining Winner as
`
`“disadvantages … do[] not necessarily obviate motivation to combine,” just as a
`
`single reference teaching away does not mandate a finding of non-obviousness).
`
`Thus, the Winner court’s call for “benefits, both lost and gained, should be
`
`weighed against one another” is a caution to not ignore the benefits of making a
`
`combination rather than dictating a rigid balancing test.
`
`
`
`
`
`
`18
`
`
`
`
`
`

`

`IPR2018-01187 Reply
`
`
`Second, the Board’s decision in Apple, Inc. v. Realtime Data LLC does not
`
`apply to the facts of this proceeding. In Apple, the patent owner provided evidence
`
`that DRAM was more expensive than (or at least as expensive as) Flash memory,
`
`which contradicted the petitioner’s rationale for combination—that DRAM would
`
`be a more cost effective solution. IPR 2016-01737, Paper 57 at 58. Here,
`
`Realtime does not introduce evidence contradicting the motivation to improve
`
`compression quality, it merely alleges there would be “decreased speed” and
`
`reduced “compatibility.” POR 57. In fact, Realtime does not even claim that the
`
`costs outweigh the benefits. Instead, Realtime asserts in a conclusory manner that
`
`it is “fatal” that the Petition did not “consider” whether the benefits of arithmetic
`
`encoding “justify” the alleged costs based on an imaginative but incorrect legal
`
`theory. Id.
`
`Another false analogy is drawn to PersonalWeb Techs., LLC v. Apple, Inc.,
`
`848 F.3d 987 (Fed. Cir. 2017), where the prior art taught disparate solutions
`
`directed toward different problems. In PersonalWeb, one reference was directed to
`
`a system for backing up or restoring data, while the other was directed to a system
`
`for managing rights to access data. Id. at 989. Here, the combination simply
`
`substitutes one element from a similar technology functioning in a similar manner
`
`(Paul’s video encoders for the audio encoders in Imai). This is not the kind of
`
`“complexity or obscurity … mak[ing] more detailed explanations necessary,” id. at
`
`