throbber
Trials@uspto.gov
`571-272-7822
`
`
`
`
`Paper No. 38
`Entered: December 21, 2021
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______________
`
`DISH NETWORK L.L.C., DISH TECHNOLOGIES L.L.C., and
`SLING TV L.L.C.,
`Petitioner,
`
`v.
`
`SOUND VIEW INNOVATIONS, LLC,
`Patent Owner.
`_______________
`
`IPR2020-01276
`Patent 6,757,796 B1
`_______________
`
`Record of Oral Hearing
`Held: November 18, 2021
`_______________
`
`
`
`
`Before JAMESON LEE, DEBRA K. STEPHENS, and
`JOHN A. HUDALLA, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`ELIOT WILLIAMS, ESQ.
`Baker Botts LLP
`1001 Page Mill Road
`Building One, Suite 200
`Palo Alto, California 94304
`650-739-7511
`eliot.williams@bakerbotts.com
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`PARHAM HENDIFAR, ESQ.
`Lowenstein & Weatherwax LLP
`1880 Century Park East
`Suite 815
`Los Angeles, California 90067
`310-307-4510
`hendifar@lowensteinweatherwax.com
`
`
`
`
`The above-entitled matter came on for hearing on Thursday,
`
`November 18, 2021, commencing at 10:00 a.m. EST, via Video-
`Teleconference.
`
`
`
`
`
`
`
`
`
`
`
`2
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`
`P R O C E E D I N G S
`- - - - -
`
`10:00 a.m.
`JUDGE HUDALLA: Good morning, everyone. This is the oral
`hearing in IPR2020-01276. This is Judge Hudalla. I have with me Judges
`Lee and Stephens.
`I'd like to start first with appearances, starting with Petitioner first,
`
`please.
`
`MR. WILLIAMS: All right. Good morning, Your Honor. This is
`Eliot Williams for Petitioner.
`JUDGE HUDALLA: Good morning, Mr. Williams. Are you by
`yourself this morning?
`MR. WILLIAMS: I will be presenting by myself, although I think I
`have some backup counsel and perhaps the client on the public line.
`JUDGE HUDALLA: Okay. Thank you.
`And for Patent Owners?
`MR. HENDIFAR: Good morning, Your Honor. Parham Hendifar
`for Patent Owner. I'm here with the lead counsel, Mr. Kenneth Weatherwax.
`And we believe we also have Patent Owners as participants on the public
`line.
`
`JUDGE HUDALLA: Thank you very much. Good morning to you.
`Okay. So, per our trial hearing order, each side is going to have one
`hour to argue. Petitioner has the burden of proof and will go first, and may
`reserve some rebuttal time. Patent Owner will go second, and may reserve a
`brief sur-rebuttal.
`
`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
`
`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`I want to remind you, as you've already alluded to, that there's a
`public line, so this is a hearing open to the public and a full transcript of it
`will be made part of the record.
`And it goes without saying that you shouldn't discuss any
`confidential information, although I don't know there could be anything
`under seal in this case.
`So, we have your slides. And we can go ahead and refer to them by
`slide number. I think that would probably be the easiest way to do it. We'd
`prefer to see you on the video if we could. But, please do be careful to
`remind us along the way what slide you're talking about.
`And, also, if you could occasionally give us a moment to interject
`with questions, we would appreciate that as well.
`The video operations folks have also reminded us to ask you to
`identify yourself so that there's a clear transcript after the fact.
`So, with that, Mr. Williams, I think we can start with you. Would
`you like to reserve some rebuttal time?
`MR. WILLIAMS: Yes, Your Honor. If you can let me know when I
`have 20 minutes left, that would be great.
`JUDGE HUDALLA: That sounds fine. You can begin then.
`MR. WILLIAMS: All right, terrific. Thank you, Your Honor.
`Again, this is Eliot Williams for the Petitioner. Let me, I guess we
`can just first begin by turning to Claim 1, which is on Slide 4 of Petitioner's
`demonstratives, just to remind everyone about what the scope of the claim is
`that we're dealing with.
`I'll note that in essence this invention is relatively simple. We are
`here -- what's claimed on Claim 1 is essentially serving a request from a
`
`4
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`proxy where data has been pre-stored, or at least some of the data has been
`pre-stored in a buffer so that it can be provided to the end user, you know,
`faster, without, without essentially they're decreasing latency by transmitting
`at a higher data speed than it would be if it wasn't pre-stored in a buffer.
`JUDGE HUDALLA: Mr. Williams.
`MR. WILLIAMS: I apologize for --
`JUDGE HUDALLA: Yeah, I think we have a problem with
`somebody's audio. Go ahead. I mean, go ahead to the video operation, our
`court reporter.
`Okay. Sorry about that, Mr. Williams, if you could please just start,
`I mean briefly start over, that would be great.
`MR. WILLIAMS: Sure. Yeah. Yeah, yeah, we'll start over.
`Okay. Everyone can hear me now. Is that right? Yeah, okay.
`Thank you, Your Honor. Again, Eliot Williams for Petitioner.
`Just beginning with Slide 4 which is the claim language. The
`invention here is essentially serving a request for live media content from a
`proxy server where at least some of the content that's being served has been
`pre-stored on a proxy server in a buffer, and then served to the end user such
`that the end user gets it faster than they would if it hadn't been pre-stored.
`That idea is well-known in (audio interference) -- which there are
`many in the prior art. In this case we present Geagan as sort of the typical
`example of that type of architecture.
`Now, one of the claim terms here which we'll get to, has been
`construed by at least one of the court to require what is, in essence, that the
`buffer on that proxy be a circular buffer, although that's not exactly the claim
`
`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
`
`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`language, and that's not exactly the construction, but more or less a circular
`buffer is going to fit into that construction.
`Those types of circular buffers are also well-known to server audio-
`video content. As it happens, Geagan doesn't specifically describe his buffer
`as being circular. He just calls it a buffer. And so, therefore, we've turned to
`Vishlitzky to help fill in the details there as to how you would implement the
`buffer of Geagan. And one obvious way to implement that buffer is with a
`circular buffer.
`And so, more or less that is the ground 1 that we're presenting in this
`case. And so, with that overview, perhaps I should just step into the claim
`limitations. And I'll talk through what I think are the issues in the case.
`JUDGE HUDALLA: Mr. Williams.
`MR. WILLIAMS: And then, of course -- Yes?
`JUDGE HUDALLA: Sorry. This is Judge Hudalla. I just wanted to
`ask you, you're talking about ground 1. Would you agree that Petitioner has
`effectively abandoned ground 2?
`MR. WILLIAMS: I don't think we've abandoned ground 2. And
`ground 2 is certainly still relevant. The only -- I mean, Patent Owner made
`an argument about ground 2 in their Patent Owner response that I didn't -- I
`thought was a bit of a non-sequitur. So, we didn't really respond to it in the
`reply because Petitioner has already addressed the question that they raised,
`which is the use of ATM networks to establish the connection between the
`client and the proxy.
`But, so I can certainly get to that and I can talk about that ground in
`particular. I haven't, haven't abandoned it. The only real relevance of that
`ground, which involves Zheng, is for the notion that when you have data at a
`
`6
`
`

`

`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`proxy that you want to send down to the client, you can send that data from
`your essentially a buffer data proxy, you can send that buffer data down to
`the client at a maximum data rate, essentially changing the instantaneous
`data rates as fast as the bandwidth allows, and then slow to a rate that's more
`consistent with the bit rate of the video. That's an idea that's in Zheng and
`we point out in ground 2, but that applies to any proxy. We could apply it
`just as easily to Geagan.
`So --
`JUDGE HUDALLA: Mr. Williams.
`MR. WILLIAMS: -- it's not abandoned.
`Yes?
`JUDGE HUDALLA: I was going to say, though, you certainly didn't
`respond to our findings in the institution decision where we rejected your
`construction. And I believe ground 2 is contingent on that construction.
`So, I'm wondering what might be left after that, given that you
`haven't made any argument?
`MR. WILLIAMS: Yeah, well, I believe that's right. I mean, Your
`Honors, we noted that in the institution decision. And if the Board continues
`to stick with the construction in the institution decision, I agree, I don't think
`Zheng would be relevant to this case.
`JUDGE HUDALLA: Okay. Thank you.
`MR. WILLIAMS: We'll see how the argument progresses here. But,
`you know, as between those two different data rates if, if in fact there is no
`need for the instantaneous data rate to change, then, you know, Geagan and
`Vishlitzky by themselves certainly practice that element and there's no need
`to turn to Zheng.
`
`7
`
`

`

`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`Okay. Okay, now back into the preamble.
`So, okay, again just looking at the -- we can turn to Slide, I guess, 7,
`where we start talking about the preamble. You know, there's a couple
`things in this preamble that I don't think are disputed that are present in the
`combination, including a network with a content server and a plurality of,
`you know, live streaming media broadcast objects. Those are essentially the
`live videos that are going to be transmitted by Geagan and via Vishlitzky.
`There's also a plurality of helper servers that connect to a plurality of
`clients. And those are all shown, again, in Slide 7, which is an overview of
`the Geagan system.
`The proxy servers there are, sort of, diagram P in the middle of that
`cloud. And as Geagan explains, those helper servers or proxy servers can all
`talk to each other and communicate between each other when necessary,
`which is part of the construction of helper servers that we apply in this case,
`which comes from, I think, some earlier decisions at the Board as well as
`district courts.
`So, I don't, I don't think there's any real controversy about most --
`about any of those elements essentially that Geagan teaches, the architecture
`of what is Claim 1.
`So, then moving to perhaps the next part of the preamble, or perhaps
`the first element, depending on how you look at it, we can turn to Slide 7.
`Slide 7 requires a method of reducing start-up latency associated
`with distribution of these objects. And, you know, here we have pointed to a
`couple things.
`One is just that the structure of Geagan itself, the fact that it's got
`these proxies that are close to the client, or as close to the client as you can
`
`8
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`reasonably get. That will have the effect of reducing start-up latency
`because of especially where the data has been precast on those helper servers
`in the case of the preconfigured buffers in this combination. You will avoid,
`these will avoid the need to have this round-trip time of it's, you know,
`request going all the way to the back end server, and then getting this data
`from the server and then coming back to the client.
`So, it's that savings in time that we point to primarily as being the
`reduction of start-up latency when you have a preconfigured buffer there,
`i.e., you know, when you have the data already stored on that local proxy
`server in some way.
`And the Board, in its institution decision, essentially agreed to that
`part of the analysis. And, you know, we continue to stand by that decision.
`Obviously, we agree with it, think it's correct, and continues to show why
`Geagan would meet this element of reducing start-up latency.
`Now, we have a second argument in the petition about how Geagan
`meets this element under sort of an alternative mapping, which has to do
`with seaming itself. So, as you recall, in Geagan he teaches the ability to
`seam multiple streams of content together ––which would protect against
`packet loss.
`So if, for instance, the Crosby server's connection to the back-end
`content source is noisy such that a packet or some packets get lost in the
`transmission, then Geagan tells you you can open up alternative connections
`to that server to try to, you know, get, get that data through a different
`channel. And the channels will be less noisy or where the noise wouldn't
`affect the particular packet that was sent.
`
`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
`
`9
`
`

`

`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`And when you, when you do that it's, of course, possible in Geagan
`then that some users, some early-on users for whom the data wasn't seamed
`yet would get missing packets, and some later users would get those packets,
`later users meaning someone who sent request a few milliseconds after the
`first user, would have been able to take advantage of that seaming and,
`therefore, would get essentially more data in the same amount of time that
`the fist user did. So that's a second reason why we say --
`JUDGE HUDALLA: Mr. Williams.
`MR. WILLIAMS: Yes?
`JUDGE HUDALLA: Judge Hudalla again. Could you address
`Patent Owner's argument on this? They argue that the whole seaming
`method that's disclosed in Geagan would actually result in a longer start-up
`latency because it takes time for there to be multiple streams received at the
`proxy server.
`Why? Why would that reduce start-up latency?
`MR. WILLIAMS: So, thank you, Your Honor, for that question.
`Again, a couple responses. First of all, there's no requirement in
`Geagan that you do seaming. It's clear that that's something that happens
`after a certain threshold amount of packet loss occurs. So, but by no means
`does the petition depend on seaming. So, just to be clear about that.
`JUDGE HUDALLA: Wait a minute though. You rely expressly on
`seaming, though, in your petition, don't you?
`MR. WILLIAMS: We relied on that as the second argument, yes, the
`faster seaming. So, I just made two arguments that are articulated in the
`petition. One is the fact that it's proxied at the edge and will, obviously,
`have a huge savings in round-trip time.
`
`10
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`And the second is that because of seaming there would be additional
`data that a second user could get that the first user doesn't. So, we do rely on
`it, but it's not necessary for our mapping.
`JUDGE HUDALLA: It is -- it either is or is not your position. I
`mean, I, you know, I hope you don't expect us to go through and pick and
`choose amongst your positions. Are you relying on seaming or are you not?
`MR. WILLIAMS: Well, Your Honor, the combination teaches the
`patent under two theories that are articulated in the petition, both of which
`work. So, we are relying on it, but it is not necessary to our position because
`we have a second position that doesn't depend on seaming.
`JUDGE HUDALLA: Okay. Well, I want you to know that we will
`consider it to be part of your position because we're not going to go ahead
`and, you know, we're basically not going to be in a position to pick and
`choose amongst your arguments to find the best one. I don't think that that's
`fair to ask of us.
`MR. WILLIAMS: Well, no, I'm not asking you to pick and choose
`the best one. I mean, we make two, both of them -- I mean, prior art, you
`know, the prior art can involve with the claim in multiple ways. There's
`certainly nothing wrong with that. And the petition presents two ways. But
`if you want to just focus on the seaming one, I'm happy to talk about, about
`that.
`
`I mean, even if you assume Geagan always says seaming, which is,
`of course, not what we say in the petition, but let's assume that that's how the
`Board wanted to interpret the petition, it still would, it still would practice
`the claim for the reasons we set forth in the petition. Because, you know,
`
`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
`
`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`the additional latency that's incurred by seaming would only, only apply in
`the worst case to the first user.
`So, the first user who sends this request to get the packet, where
`Geagan determines that there is a lost packet and, therefore, decides to start
`performing its seaming technique, that first user might experience a slight
`additional delay while the proxy of Geagan reorders the seamed packets to
`send them out.
`But, of course, Geagan doesn't, doesn't hold on to those packets
`forever waiting for it to come. It specifically points out that there would still
`be gaps in the seamed stream, and that some users may have less and some
`users may have more, just depending on whether they're able to take
`advantage of additional seamed streams or not.
`And our expert Dr. Negus analyzes this issue in his declaration at
`great length, and concludes that even in the case where there is some
`additional delay due -- due to the seamed streaming, that delay would be
`dwarfed by the advantage you get from having pre-stored content on the
`proxy server, so that certainly, the data rates would increase.
`And, moreover, it's not just Dr. Negus who says that, Patent Owner
`has essentially admitted as much as well. Slide 29 shows that section from
`their Sur-reply. What they say is "Geagan might at best, under certain
`conditions, happen to reduce start-up latency." So, they essentially concede
`that Dr. Negus' analysis is right, at least under, you know, "certain
`conditions."
`And on Slide 28 you will see Patent Owner's expert on cross-
`examination says, yes, in this case where they're seaming, when the second
`user can take advantage of a seamed stream that's already present on the
`
`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`proxy server that at least could reduce start-up latency. Even he was willing
`to admit that that's certainly a possibility.
`So, therefore, so I think the answer of the seaming, the seaming
`question is sort of irrelevant to the data rate or the -- sorry, to the increase in
`lat -- decrease in latency because any cost of that seaming would be more
`than dwarfed by the advantage you get from having pre-stored content there,
`at least for subsequent users to that, to that stream.
`JUDGE HUDALLA: And just to be clear, there's no analysis in the
`petition where Petitioner attempts to show how the reduction of start-up
`latency may be affected by seaming vis-a-vis the closeness of the proxies?
`MR. WILLIAMS: I'm not sure I agree with that, Your Honor. Let
`me just look at the petition for one second.
`(Pause.)
`MR. WILLIAMS: I mean -- let me make sure I'm in the right section
`first of all.
`I'm looking at -- so, this is analyzed really more in detail in the data
`rate section than it is in the latency section, although the technical principles
`are essentially the same. The question is do you get data faster at one end in
`one circumstance than the other?
`So, but in terms of the preamble analysis, yeah, the preamble tends
`to -- so, the preamble analysis in the proxy of this element certainly focuses
`on the delay between the proxy and the client. And, you know, our analysis
`there is based on Kevin Negus' conclusion at paragraph 264 that Geagan's
`disclosure that you are streaming close to the client would teach that the
`delay between the proxy and the client is substantially less than the delay
`between the content source and the client's, thus reducing latency.
`
`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`So, I'd say that analysis does subsume everything Geagan's doing
`with seaming. But perhaps the more detailed analysis happens when we get
`to Element 1C that talks about the different data rates that could happen
`under the two scenarios: one where you've got content pre-stored, and one
`where you don't. And that's where the difference in seaming is more
`nuanced. And so, he does explain that in more detail.
`Oh, I should say, yeah, I think he also teaches -- sorry, give me one
`more second on the first point, Your Honor.
`I think in the petition, yeah, so let me turn to 1C. So, here on that
`one when we're analyzing on 1C, for instance, on page 45 after talking about
`the difference between the seaming rates, the different seaming scenarios,
`you know, we, we point out that either one of them understood that the
`higher retrieval speed that serves to reduce latency perceived by users is a
`fundamental advantage of proxy caching, such as Geagan.
`So, again, that subsumes everything Geagan's doing about seaming.
`The fact that you've got this thing at a proxy close to the serv -- close to the
`edge is itself, you know, fundamentally the purpose of proxying, and would,
`you know, certainly reduce latency. Otherwise you would never do this,
`there's no reason to introduce additional latency.
`I think going back to analyzing the different --
`JUDGE HUDALLA: Actually, --
`MR. WILLIAMS: Sorry. I was just pointing out element 1C before
`that. Yeah.
`JUDGE HUDALLA: Okay. I was just going to say thank you. I
`think we understand your position. But I just want to make sure you have
`enough time to get into some of your other arguments.
`
`14
`
`

`

`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`MR. WILLIAMS: Oh no, yeah, that's fine. This is obviously a large
`one. So, we might as well get to it now in terms of element 1C where the --
`how the seaming works. Then I can come back to element 1B in a moment.
`So, the only other thing I was going to, was going to point out in
`terms of our analysis here, again, is that, you know, their expert has
`conceded the analysis is true, that there's at least cases where this would
`reduce latency despite the seaming. And if you read the petition from pages
`43 to, you know, 46, we have a fairly detailed analysis of the seaming
`scenarios and the different ways that could play out, and showing that in,
`you know, all those cases discussed there that you would have higher data
`rates for the pre-stored data than you would for the non-pre-stored data even
`when seaming is applied.
`Okay. I can do -- let's just move on, I think, to the other element 1A,
`which receiving the first request. I don't think there is a dispute about that
`element. But to the extent there is, our analysis there is at page 27 and 28,
`showing that, you know, in this combination what would happen is the
`request is going to come through the proxy server. Right? It's going to come
`through Geagan. We make that explicit.
`Patent Owner had made an earlier argument in their Patent Owner
`response that somehow in the combination there would need to be a central
`server where these requests came in. And, you know, I think it's clear in our
`combination that's not the combination we're envisioning.
`JUDGE HUDALLA: Could I ask you about that, Mr. Williams?
`This is Judge Hudalla again.
`Do you, well, could you address the fact that Petitioner relies on
`"stream servers controlled by controller servers" and the fact that Petitioner
`
`15
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`also relies on the admission control program of Vishlitzky? Doesn't that
`support the notion that there has to be central control?
`MR. WILLIAMS: Well, I don't know what -- again, this is the whole
`problem with central control. I don't know where that context, what that
`context actually means.
`Within the proxy server of Geagan, yes, there is a central controller
`that's going to do these things. And that's our combination sharing.
`So, the point is the request comes into a proxy which needs to figure
`out what to do with it. And so that's why when we talk about Vishlitzky's
`use of the central controller where we kind of combine together the
`controller server and the stream server in that green circle, which you can
`see on, for instance, on Slide 8, the point is that, you know, Vishlitzky
`teaches functionality about how to allocate and send client requests to the
`preconfigured buffers. And, yeah, you would need that kind of functionality
`in the Geagan proxy servers. So, that's the combination.
`JUDGE HUDALLA: So, you --
`MR. WILLIAMS: Central control. That's what, that's what we were
`talking about.
`JUDGE HUDALLA: Why don't I just start with a few basic
`questions.
`You do agree that --
`MR. WILLIAMS: Okay.
`JUDGE HUDALLA: -- Petitioner relies on stream servers controlled
`by controller servers from Vishlitzky; right?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`MR. WILLIAMS: We, yes, well, we agree that that functionality
`from Vishlitzky would be put into the Geagan architecture. That's the
`combin -- Yes.
`JUDGE HUDALLA: Okay. And you agree that Petitioner relies on
`the admission control program which is shown in Figure 17 of Vishlitzky?
`MR. WILLIAMS: Yeah, the logic of that Figure 17 would be part of
`assigning requests that came into the individual proxies to, to buffers in
`those proxies. That's right.
`JUDGE HUDALLA: Okay. So, that being the case, doesn't that
`basically support Patent Owner's argument that there has to be some sort of
`central control aspect, i.e., the admission control program which sends out
`the video streams, or sends out requested video streams to various stream
`servers?
`MR. WILLIAMS: Yes. In the individual proxies there would be a,
`you know, central control.
`I mean, every, every server, the Geagan proxy servers included,
`needs a processor controlling what it does, yes. But it's not central in the
`sense that there is some overarching, there's some super central controller
`that's controlling all the proxy servers. So that, I think, is where the
`difference in the positions is.
`Patent Owner's argument seems to be that, therefore, there must be
`some super central controller controlling all of these proxies. And that's
`where we, we disagree. And that's certainly not the combination we
`proposed in the petition.
`JUDGE HUDALLA: Okay. So, I guess that's the problem the panel
`is having here, which is: Where in the petition does it tell us how to import,
`
`17
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`as you're suggesting, the functionality of these stream servers controlled by
`controller servers and admission control program into individual helper
`servers? Because I think that almost kind of cuts against the way that
`Vishlitzky operates.
`MR. WILLIAMS: Well, again, Vishlitzky is a server. Right? He
`doesn't have -- there's not an edge server in Vishlitzky. This is just a content
`server that's got data stored thereon.
`Our point is that what Vishlitzky teaches you is two things: it teaches
`you that you can have this notion of popular and unpopular movies, and then
`you might serve those requests differently. And in the case of Vishlitzky,
`you would pre-populate buffers for popular movies, and you wouldn't pre-
`populate those buffers if it was unpopular.And it teaches you that those
`buffers can be circular buffers.
`So, those are the two teachings of Vishlitzky that are relevant to our
`combination. And those are applicable to the proxy servers updating.
`JUDGE HUDALLA: Well, here's my question. You just, you just
`said that you serve popular and unpopular movies differently. You're taking
`that functionality from Vishlitzky, right? So, how would that apply? How
`could I, at multiple different helper servers, try to serve, you know, an
`unpopular versus a popular movie at multiple different helper servers? I
`mean, that seems to be like a central control aspect that Patent Owner is
`talking about.
`MR. WILLIAMS: So, that's not a part of central control. That, okay,
`so in our, in our combination and in Vishlitzky, the decision to make a
`movie popular or not, that's an annual decision that you make to set up the
`
`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
`
`18
`
`

`

`IPR2020-01276
`Patent 6,757,796 B1
`
`buffers. So, yes, in that sense there would be an administrator of the system
`who would make that decision. That's discussed in our petition.
`Is that what, is that the question?
`JUDGE HUDALLA: Sure. I'd love to see where you're referring to,
`
`please.
`
`MR. WILLIAMS: Yeah, okay. Let me take you there. One second.
`Looking for that.
`(Pause.)
`MR. WILLIAMS: All right. So, first would be on petition page 34.
`So, on that page we say, a POSITA would find it obvious to
`implement the buffer of Geagan as a preconfigured buffer because
`Vishlitzky teaches it is advantageous to preconfigure a player buffer, et
`cetera, to serve as a popular stream such as Geagan's popular live serving
`content. For example, a POSITA would have understood that establishing a
`preconfigured player history buffer for popular live events would be
`advantageous because those events are likely to draw many viewers.
`Geagan, therefore, discloses a buffer that is manually configured before the
`live event is requested and permanently maintained as memories thereafter.
`So, that's one example.
`And then on page 36 they explain again, however -- this is about four
`lines down -- however, if a request is for a less popular live event than with
`Geagan, in view of the disclosure of Vishlitzky, would either do other
`processes such as allocate non-preconfigured player history buffer to service
`the request, as will be discussed.
`So, that's an example of that.
`
`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
`
`19
`
`

`

`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
`
`IPR2020-01276
`Patent 6,757,796 B1
`
`JUDGE HUDALLA: But in that case nothing is orchestrating that
`choice between what you're calling preconfigured and non-preconfigured
`buffers?
`MR. WILLIAMS: I'm not sure I understand the question, Your
`Honor. What do you mean nothing is orchestrating the choice between?
`JUDGE HUDALLA: So, there must be, first, a decision as to
`whether, whether a certain movie is going to be a preconfigured or certain,
`in this case a livestream program is going to be preconfigured or not.
`MR. WILLIAMS: Right. So, there does need to be a manual
`decision about that by, by the system administrator, yes.
`JUDGE HUDALLA: And that choice can't be done by the individual
`helper servers or proxies in the case of Geagan?
`MR. WILLIAMS: I mean, that's not how -- right, that's not the
`argument we've made in the petition though, that it's not an automated
`process of deciding whether something is popular or not. It is, that is a
`manual decision, obviously, for an administrator.
`JUDGE HUDALLA: Okay. So the once, once the system starts
`running, then what is making that choice as to whether you're serving the
`live content from a preconfigured buffer versus a non-preconfigured buffer?
`MR. WILLIAMS: So that, that is what -- so that is where the logic
`from I guess Figure 17. You see the figure, for instance, on page 35 of the
`petition. So this is that step 171 of Vishlitzky. Where you can request and
`you're asking is that a request for a popular movie or not.
`So that's, that's where that decision is made. But that is a step that's
`being practiced in the, in the proxy server of Geagan of which there are,
`obviously, many. I think three are shown, but obviously there could be
`
`20
`
`

`

`1
`2
`3
`4
`5
`6
`7
`8
`9
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket