`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SLING TV L.L.C., SLING MEDIA, L.L.C.,
`DISH NETWORK L.L.C., DISH TECHNOLOGIES L.L.C.,
`Petitioners,
`
`v.
`
`REALTIME ADAPTIVE STREAMING, LLC,
`Patent Owner.
`____________
`
`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`____________
`
`Record of Oral Hearing
`Held: December 5, 2019
`____________
`
`
`
`Before KEVIN W. CHERRY, GARTH D. BAER, and
`NABEEL U. KHAN, Administrative Patent Judges.
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`
`
`
`
`RUFFIN B. CORDELL, ESQUIRE
`ADAM R. SCHARTZER, ESQUIRE
`Fish & Richardson P.C.
`60 South Sixth Street
`Minneapolis, MN 55402
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`
`
`
`
`
`
`The above-entitled matter came on for hearing on Thursday,
`
`December 5, 2019, commencing at 1:00 p.m., at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`
`PHILIP X. WANG, ESQUIRE
`Russ August & Kabat
`12424 Wilshire Boulevard
`12th Floor
`Los Angeles, California 90025
`
`
`
`2
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE CHERRY: Please be seated. So, good afternoon. This is the
`
`hearing in IPR2018-01331 and IPR2018-01342, Sling et al. v. Realtime
`Adaptive Streaming. Will the parties please make their appearances?
`
`MR. CORDELL: Good afternoon, Ruffin Cordell from Fish &
`Richardson; and with me is my partner Adam Schartzer; and our clients
`Larry Katzen and Jim Hanft from DISH.
`
`JUDGE CHERRY: Welcome.
`
`MR. WANG: Good afternoon, Your Honors; Philip Wang for
`Plaintiff (did he misspeak or say Patent Owner?), Realtime Adaptive
`Streaming; and with me is myself.
`
`JUDGE CHERRY: Thank you. Mr. Cordell, as the Petitioner you
`have the burden of proof. We've allowed 45 minutes. How much time do
`you want to reserve for rebuttal?
`
`MR. CORDELL: Twenty minutes.
`
`JUDGE CHERRY: I think we talked about the -- the panel talked
`about this -- if you want to focus your presentation on the 1342 case, we
`think that would be particularly helpful.
`
`MR. CORDELL: That has been our plan. So, if that works for the
`Board then, may it please the Board, Ruffin Cordell from Fish &
`Richardson, I will handle the 1342 appeal; Mr. Schartzer will deal with the
`'610 issues to the extent that we haven't already covered them as part of the
`1342.
`
`
`
`JUDGE CHERRY: Great; all right.
`MR. CORDELL: So we have slides. May I distribute those?
`3
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`JUDGE CHERRY: Thank you.
`
`MR. CORDELL: So, we have both the luxury and the burden in this
`
`case of the Board having heard some of this before in some of the related
`IPRs. But, so, I'll do a bit of background and then go right into the issues.
`
`JUDGE CHERRY: Sure.
`
`MR. CORDELL: So, we have three grounds for consideration.
`(OFF THE RECORD)
`MR. CORDELL: So, three grounds for consideration: anticipation by
`
`Dvir; obviousness over Dvir; and then obviousness over Dvir and Ishii. So,
`I'll do a little background on the patents, talk about the issues; and then we'll
`get into each of them in some detail.
`
`So, the '535 Patent, this Board is very familiar with having considered
`it before, so I won't spend a ton of time on it; but the one thing that struck
`me when I first approached the '535 Patent is the level of abstraction of the
`patent, it's a very high level patent. There's some detail in the specification,
`but it's never claimed; and what is actually claimed is a very high level
`process where data is examined; a parameter is ascertained, that is used then
`to pick a compression algorithm; and it's devoid of any context. We don't
`know if it's a memory system, a transmission system, a toaster, we don't
`know what it is. It just has to have those few elements.
`
`We see it in the specification that it uses access profiles to link a data
`type with a compression algorithm; and we're going to talk about that quite a
`bit during the claim construction.
`
`JUDGE CHERRY: And just for your reference, Judge Khan can't see
`what's on the screen; so, if you just, well, say what slide you're on so that he
`can follow along?
`
`
`
`4
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`MR. CORDELL: Thank you, Your Honor; that's always helpful. So,
`
`I'm now looking at slide 5, and going to slide 6, we see the claim itself; and
`the claim itself, again, is very simple: determine a parameter; select an
`access profile; and compress using that profile. Pretty much just an a-b-c
`kind of claim.
`
`The prior art we're going to spend most of our time with on slide 7 is
`Dvir. It's a system for streaming compressed video data but, again, these
`claims are agnostic as to the application. It really is just all about
`compression. And it turns out the Dvir system has exactly that same three-
`step process where a parameter is determined here at slide 8. That parameter
`is matched to a compression profile at slide 9; and then at slide 10, that
`compression profile is used to compress the data. That same three-step
`approach that the claims talk about is exactly what Dvir talks about. And
`we'll take you through that in a lot of details when we get to the substantive
`issues.
`
`So, at slide 12, I've got a summary of the issues that I hope to cover
`today; and, actually though, these are the proposed constructions of access
`profile and the other terms that are at issue. I'll deal with these substantively
`as we get to the issues; so, let me dive in.
`
`So, at slide 12, or 13, we have the summary of the issues that we'll
`cover today. I'm going to talk a little bit about the construction of access
`profile. The Board invited the parties to exchange views on that; and we,
`obviously, have. I'll talk about the invalidity grounds themselves, 1 and 2,
`over Dvir, both from an anticipation and obviousness perspective; and then
`the parties' disputes have been pretty much focused on these four issues:
`whether a single disclosure demonstrates anticipation; the meaning of access
`5
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`profile compressors using a symmetric data compression data block; and
`then ground three is the combination of Dvir and Ishii; and, really, the only
`issue is motivation to combine. So, let's jump in.
`
`So, let's start with access profile. The proposed construction I have at
`slide 14 from DISH is information that enables a controller to determine a
`compression routine that is associated with a data type of the data to be
`compressed. So, we start with, you know, is access profile something that
`those in the art recognize? And the answer is, overwhelmingly, no. We
`have a slide at 15 from Dr. Zeger who's Realtime's expert -- and I have to
`apologize to Dr. Zeger about this picture. He's not here, but this came off
`his website; so, it's his picture. But he candidly admits the word access
`profile is not typical terminology that a person of skill in this art would use.
`
`So, we looked at the extrinsic record for a definition, and we find it in
`the specification; and at slide 16, I've got quotes from column 8, lines 4 thru
`12; and 11, 31 thru 40 where it explicitly associates an access profile with a
`data type. It does it over, and over, and over again. We see that the access
`profile operatively assembled by the controller enables the controller to
`determine a compression routine that is associated with a data type of the
`data to be compressed. And that same thought is expressed several times
`throughout the specification.
`
`We've had a lot of exchange about the chart from column 12, that I
`have at slide 17; and the parties seem to have a different view of how to read
`this chart, but I don't think it's all that difficult. The specification tells us --
`as I just showed you -- the data types are associated with this access profile
`concept. The chart at column 12, slide 17 gives us three columns -- well, a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`6
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`number of columns, but the important ones are access profile, example data
`types, and then compression algorithm.
`
`Now, Realtime reads this and they say, well, ha-ha, look it says access
`profile. That's something different from example data types; but I don't
`think that's right at all. I think here we have an explicit association and the
`specification above and around this chart, at column 12, tell us that's what's
`going on here. They use access profile write few, read many as a title -- it is
`a title of the profile; but then they associate it with data types. And that's the
`important part of the disclosure; and that linkage is carried all through the
`specification. It's not a one-off kind of thing.
`
`And Realtime says well, you know, that may be but, you know, that's
`just an example; these are just examples where access profiles are associated
`with data types; and they say it actually at slide 18 -- I've got a piece of their
`brief here -- and they say, you know, that's just a preferred embodiment;
`that's just one example; but they never show us a single example where
`access profile is not associated with data type; and there're many more at
`column 14, lines 36 thru 42. And Mr. Mosteller I don't know how -- maybe
`we shouldn't pull that out. It might be too -- can you do it easily?
`
`MR. MOSTELLER: Yes, I can. You say 36?
`
`MR. CORDELL: Yes; 36 thru 42; column 14, 36 thru 42. There're
`many other examples of a direct association between access profile and data
`type. And to the extent that there are multiple embodiments in the '535
`Patent, whenever the access profile nomenclature is used, it is associated
`with that data type. That is an absolute fact and one that we really can't
`retreat from -- 36 thru 42.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`7
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`Alternatively, the system can detect the type of data being installed or
`
`stored to disk, via file extensions, etc., and automatically select an
`appropriate algorithm using the access profile information as described
`above; again, data type, even file extension, associated with an access
`profile.
`
`So, if I could go back to the slides. Let's now consider Realtime's
`proposal. That's slide 19. So, Realtime tells us that it's information that
`enables the controller to select a suitable compression algorithm that
`provides a desired balance between execution speed, rate of compression,
`and efficiency or compression ratio. What Realtime has done, they've taken
`a step higher. They've gotten further away from the disclosure, and we're
`now talking about aspirations. We're not talking about goals. Realtime,
`essentially, says information that allows the controller to do something good;
`and that they suggest should be a definition of the term. It is true that both
`DISH and Realtime are proposing somewhat functional definitions of the
`term, but here we've gone to a higher level. So, we know nothing about the
`balance between execution speed and efficiency. We are at c, we are now
`going to be guessing what those terms mean to one of ordinary skill in the
`art; and it's a desired balance. We don't know if it has to be 10 percent, 20
`percent, 80 percent; we have no idea what the desire is.
`
`And so, we asked Dr. Zeger, their expert. At slide 21, I've got his
`deposition; and we asked him what that means. And he said well, you know,
`it means, it's going to be judged in the eyes of the practitioner. It's going to
`be in the eye of the beholder as to what desired means; and if I go back to
`slide 20, we both kind of point to the same part of the specification. But,
`maybe the distinction here is that DISH points to, you know, a half a dozen
`8
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`different places around the specification where access profile and data type
`are associated.
`
`This is the sentence that I have on slide 20 from column 8, lines 4 thru
`12. This is the singular sentence that Realtime relies on; and it is a true
`statement that the access profiles result in this; they comprise information
`that enable a controller to select a suitable compression algorithm that
`provides a desired balance. That is the ultimate goal; that is the aspiration of
`the patent.
`
`But what does that tell us about the information? Do we know that it's
`any particular kind of information; or is there any source of information; or
`are we just told that the practitioner must do well? They must do something
`that achieves a goal. It harkens back to the old example I was taught at the
`PEIT that a fabric that wears rough rather than smooth is not a definition of a
`claim term. You can't have that; and that's exactly what we have here.
`
`JUDGE BAER: Mr. Cordell, why can't you have that? I assume what
`you're say is it's indefinite, right? This doesn't work because it's indefinite;
`and I think you have the same issue going on in the 1331 case as well with
`desirable or suitable, one of those terms. My question to you is why does
`that matter? I understand your position that it would be indefinite and,
`perhaps, maybe in the district court there's a presumption against construing
`a claim to be invalid; but I don't think we have that same presumption here.
`So, what is your response if Mr. Wang were to stand up and say fine, it's
`indefinite; that's not our problem because you don't determine indefiniteness
`here. Why does that matter to claim construction?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`9
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`MR. CORDELL: Because Nautilus tells us -- indefiniteness aside --
`
`that it has to be meaningful. We have to give those of ordinary skill in the
`art meaningful boundaries as to what the claim term is.
`
`JUDGE BAER: Sure, we would have to for the purpose of
`definiteness, but not for the purpose of determining under 103 whether the
`prior art reads on the claim.
`
`MR. CORDELL: So, I guess the way I would view that is that the
`sanction for violating Nautilus or Section 112, paragraph 2, is indefiniteness;
`but that doesn't change what the statute tells us to do. The statute says that
`at the end of every patent application are to be a set of claims that definitely
`point out and claim the distinct -- I can't remember the exact words --
`distinctively claim the invention that the inventor came up with. That's what
`they're supposed to be doing here. So, when we inject terms like this doing
`claim construction, we're going backward. And whether or not it results in
`invalidity, I agree with you. It is not before the Board; that's not your issue;
`but the statute still tells us that we are supposed to have claims that are
`definite, and we can't just violate them. So, it is true that the claims are
`construed to preserve validity. I understand that. It's not exactly, as I think
`you pointed out in one of the earlier IPRs a maxim of interpretation that we
`use every day these days; but, nevertheless, the statute remains; and the
`statute tells us we are to have definite claims; and we can't simply disregard
`that.
`JUDGE BAER: Are you aware of any case that holds that we
`
`construe claims to preserve validity at the Board?
`
`MR. CORDELL: Not as I stand here; but that is a very long-standing
`principle. It has been used many, many times over the years. But, again, as
`10
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`a matter of PTAB precedent, I can't name one; but I'd be surprised if we
`could find a case with the opposite proposition.
`
`JUDGE CHERRY: I guess the one thing that concerns me is that it
`does have a ring of a definition though because it does use the word
`comprise and so it seems to be saying that this is what they have to be. So,
`why isn't that sentence in green a definition -- why shouldn't we take that as
`their definition in the spec for this term?
`
`MR. CORDELL: Because it is no, certainly no more a definition than
`the sentence in yellow, number one; and number two, when it uses the word
`comprise, again, as patent lawyers, we know that means including but not
`limited to. And so, that tells us some information about what an access
`profile is, but it's not definitional. It's not a sentence that says an access
`profile consists of the following three things. It simply says that the access
`profile must be usable to select something that gives us a desired balance.
`Very aspirational, very high level and less detailed than the DISH proposal
`in yellow. Okay. So, I probably need to move a little more quickly. We
`would cite the data --
`
`JUDGE KHAN: Counsel, before you move on, let me just ask one
`specific question about your construction. Taking a look at Netflix's
`proposed construction from the 1169 case, does your claim construction
`exclude or preclude that information being, for example, the number or
`frequency of reads or writes?
`
`MR. CORDELL: So, our construction, I believe, would include it
`because I think that the patent makes it very clear that -- for example, if you
`turn to my slide 27 -- the example data types are associated with access
`profiles that also have the attribute of write few, read many, etc.; and so, I
`11
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`would say that the access profile frequency -- if you want to call it that -- is
`part of the data type that we have in our construction. I don't think the
`opposite proposition is true; I don't think the data type is necessarily
`included within the Netflix construction. And the big flaw with the Netflix
`construction is that it just doesn't cover all the disclosed embodiments; and
`so, that's a bit problem.
`
`JUDGE KHAN: So, you're saying the number or frequencies of reads
`and writes is somehow associated with a data type?
`
`MR. CORDELL: It is. It is explicitly associated with a data type over
`and over in the specification, for example here in column 12; and we've got
`both of the charts at slide 27 reproduced that show exactly that; that access
`profile and data type is associated with frequency.
`
`JUDGE KHAN: Okay; thank you.
`
`MR. CORDELL: So, if I can quickly jump to my grounds of
`anticipation. So, the primary argument with respect to Dvir has to do with
`Realtime's proposition that somehow there are multiple embodiments of
`Dvir, and we can't put one foot in each embodiment in order to make out
`anticipation; and it's categorically not true. So, the operative part of Dvir is
`a single embodiment; there is just no debate about that. So, we asked Dr.
`Zeger if he could tell us whether there were multiple embodiments in Dvir,
`at slide 30; and he says no.
`
`So, you look at the actual disclosure of Dvir -- I have at slide 31 -- and
`the operative part of Dvir, the part that talks about the compression
`algorithms in columns 4 thru 6, and it is a single method. At one point, they
`rename the steps, but it's a single method. There's no dispute about that.
`What happens in figures 2 and 3a, 3b, and 3c are different hardware
`12
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`implementations downstream of the compression method. So, it can be used
`in different context; but the operative part of Dvir is that single method, and
`there's just no question about that.
`
`So, at slide 32, I take you through figure 2, and then slide 33 is 3a, 3b,
`and 3c. Again, these are embodiments where they use the compression
`method in different context, but the compression method is always the same;
`and the compression method is what is operative here.
`
`Let me jump to slide 35 because there we see the comparison of the
`method steps of Dvir. It's a single method analyzing, associating, receiving,
`and selecting. Those are exactly the steps that are disclosed; those are the
`ones that are claimed in Dvir; and those are the ones that we are relying on
`for purposes of anticipation; and there's really no dispute that this fits exactly
`what it is that the '535 Patent tells us about.
`
`So, let me now jump ahead to -- let me address quickly whether the
`Dvir method invalidates under the Realtime construction. So, jumping to
`slide 41 -- again, what we have to show here is a desired balance between
`execution speed and efficiency. And at slide 42, we find the Dvir
`compression profiles are used for exactly this purpose; they're used for
`optimal compression of the video display data. It tells us right here at slide
`42, from Dvir at column 5, 14 thru 22; and 10, 21 thru 24. Our expert, Dr.
`Acton, addressed this and said, where Dvir talks about using MPEG
`compression, it's doing exactly this, it's balancing compression speed and
`compression ratio. That evidence is unrebutted.
`
`Okay; and then finally, let me address Dvir under the Netflix
`construction, beginning at slide 45. So -- I touched on this earlier -- that the
`'535 Patent acknowledges the different data types, also implied different
`13
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`read/write frequencies; and so, we have that in slide 46, that association
`between the data types and the read/write frequencies. And our expert, Dr.
`Acton, at slide 47, tells us that a person of ordinary skill in the art would
`have known that different types of data are read from and written to more or
`less frequently; and as I previously discussed, MPEG was specifically
`designed to take this known disparity in read/write frequency into account;
`and that's an explicit disclosure in Dvir.
`
`So, before I use all of Mr. Schartzer's time, let me get to the
`significantly issue.
`
`JUDGE CHERRY: Actually, could you spend some time on ground
`3?
`MR. CORDELL: Absolutely. So, jumping to ground 3, which begins
`
`at slide 60, the real issue here with ground 3 is motivation to combine. So,
`as we confront the prior art here, Ishii has been before this Board -- again, I
`don't need to spend a lot of time on it -- but, essentially what it is, is it's a file
`compression and decompression manager for a memory system; it's very
`straightforward. And the claims that we are applying ground 3 to -- the
`dependent claims -- really talk about three fairly trivial ideas. One that
`you're going to store things into and retrieve from memory, files; one is
`compression based on access frequency -- which we've already talked about
`-- and then you're going compress portions of files; but really the additional
`limitation, if you will that we haven't talked about yet -- is the notion that
`we're going to store and retrieve files or portions of files. That alone is a
`fairly trivial leap; so, we're not talking about the biggest obviousness gap
`we've ever seen.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`14
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`What Dvir tells us is that you store files into memory and you retrieve
`
`them from memory using systems that are not disclosed. So, Dvir talks
`about compressing and decompressing data for transmission to a remote
`terminal; and it tells us right in the text of the patent that they come from a
`computer that's not shown, is the actual language. We see that from slide 32
`-- I'm not going to go back to it; but the idea is that Dvir readily
`acknowledges that there is another entity, there is a computer that is
`producing this data and handing it off to be compressed, and then sent off to
`a remote terminal. It is that interaction between Dvir and Ishii that really
`provides motivation to combine. It is the fact that you have -- so at slide 66,
`we have Realtime's argument saying wait a minute, these things are
`completely different; and Realtime says Ishii is about storing and retrieving;
`and Dvir is about processing and transmitting. But that's the reason why
`they go together because you have to have a system to store and retrieve in
`order to then compress and transmit.
`
`It is that interaction between the two, the fact that the two fit together
`in such a complementary way that led our expert to talk about over and over
`again, here at slides 67 and 68, that Dvir's focus on transmission fits
`perfectly with the Ishii disclosure of storage and retrieval; and the
`specification cites and the support that he has for that at slides 67 and 68 are
`manifest. He says it over and over again that anyone of ordinary skill in the
`art would immediately turn to a reference like Ishii because it tells you how
`to store and retrieve data, which is the one piece that's missing from Dvir.
`
`If I can, now, just comment briefly, at 69, that frequency? So, we
`have claim 6 that adds the additional limitation that we have to do
`compression or decompression based on frequency. We've already covered
`15
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`that a bit when we talked about the Netflix construction; and so, what
`happens here with respect to claim 6 is, again, just a reiteration of that; but,
`importantly, tracking the frequency -- the argument that Realtime makes is
`that it somehow complicates it and it's too much work for a computer to do
`that. Well, that's absurd; I mean that's what computers do is they count
`things; and so, counting the number of reads or writes is just another way to
`choose the compression; and it certainly is where there's no evidence that is
`an even difficult task much less an insurmountable one. So, with that I'll
`pass the podium to Mr. Schartzer to make a few comments about the '610,
`unless there are further questions.
`
`JUDGE CHERRY: Sure; thank you.
`
`MR. SCHARTZER: So, why don't we go and start with slide 111?
`Your Honor, I skip to this slide -- the Board is familiar with the prosecution
`history that went on through here, but what happened during prosecution is
`Vishwanath was the primary reference and all claims were rejected and
`based in view of Vishwanath. So, what Realtime chose to do with the '610
`is to bring in the dependent limitation that the algorithms to be chosen are
`asymmetric. What Realtime did not tell the Examiner -- and I'm here on
`slide 113 -- is that the '610 Patent describes asymmetrical compression
`algorithms and that those algorithms include Lempel-Ziv; and Vishwanath
`clearly disclosed Lempel-Ziv. I would respectfully submit to you that had
`this been disclosed to the Examiner, the Examiner would have just issued
`another rejection against all the claims again, and had Realtime go back and
`try a little harder for something that was patentable.
`
`I want to skip ahead to slide 137, please. I want to address the issues
`with respect to claims 6 and 16. The parties have taken the position that
`16
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`those require that all of the algorithms that are being chosen be asymmetric,
`and Realtime argues that that is novel. There are two grounds against claims
`6 and 16. One is an anticipation ground and one is an obviousness ground;
`and I want to focus on the obviousness ground because when we're talking
`about obviousness, we look to what the reference discloses, and this
`reference, obviously, discloses asymmetric algorithms.
`
`At figure 7 of this particular reference -- its Exhibit 1004, and it's slide
`122 -- figure 7 is there in the top -- and it gives us some options. And what
`the reference tells us is that figure 7 shows ways to select the compression
`algorithms based on the input data type and the computation power of the
`client because a decoder might need to decompress the adapted output, 183.
`It doesn't tell us that we're limited to always using symmetric and
`asymmetric together; and it's no more or less obvious that this reference uses
`both. What Vishwanath is trying to do here is give a person of ordinary skill
`in the art ways in which they could design a system. So, if you were
`designing a system for video using clients that had medium and high
`computation capabilities, you would be looking at a subset of only using
`asymmetric compression algorithms.
`
`And KSR is clear on this point -- asymmetric v. symmetric. We have
`a defined limited number of set of options. You can use asymmetric only;
`you could use symmetric only; or you could blend the two; but that's just
`three options that the person of ordinary skill in the art has; and KSR is clear
`that when you have a finite, predictable number of solutions, that tends to
`lead to an obvious result here; and Realtime has not proffered any evidence
`into the record that there is an unpredictable result from using only
`asymmetric algorithms as the options. And can you take me to slide 139,
`17
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`
`

`

`Case IPR2018-01331 (Patent 8,867,610 B2)
`Case IPR2018-01342 (Patent 8,934,535 B2)
`
`
`please? So, this is our expert, Dr. Acton, and he opined that Vishwanath
`discloses using both but it does not make it any less obvious just to use
`asymmetric algorithms alone, and that evidence has gone unrebutted on this
`record. So, I will go ahead and take a seat and turn it over to Mr. Wang
`(inaudible) --
`
`JUDGE BAER: Can I ask you one question before you sit down, Mr.
`Schartzer?
`
`MR. SCHARTZER: Yes.
`
`JUDGE BAER: We have a lot of cases involving related patents, and
`there are a lot of claim constructions. Are you all -- one of the things we're
`trying to avoid is contrary claim constructions in one case versus another
`case that we're not aware of -- are you all tracking in some way all of the
`petitioners' claim constructions such that you're making sure we're getting
`briefed when we need to on what might be contrary claim constructions
`from petitioners, or making sure those things are going to be consistent?
`Are you doing any of that tracking?
`
`MR. SCHARTZER: So, for the '535, we've attempted to do that.
`Now, the way the papers have come in in the '535, there've been claim
`constructions that have come in from other courts and other bodies that
`could not have been accounted for, for instance, when the petition was filed.
`With the '610 Patent, as I understand, we're the only Petitioner pursing an
`IPR against that; and so, we try to remain true to that record as well.
`
`JUDGE BAER: Just for your information, if there is a claim
`construction that comes in, say, from a district court, that's something that
`we would like to know and like to be aware of; and we would certainly
`invite additional briefing on that; and if that does come up, that would be a
`18
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`1