Trials@uspto.gov
`571-272-7822
`
`Paper 25
`Entered: January 24, 2024
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______
`AMAZON.COM, INC., AMAZON WEB SERVICES, INC., and
`AMAZON.COM SERVICES LLC,
` Petitioner
`v.
`WAG ACQUISITION, L.L.C.,
`Patent Owner.
`__________
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`__________
`Record of Oral Hearing
`Held: December 12, 2023
`__________
`Before HUBERT C. LORIN, JOHN A. HUDALLA, and STEVEN M.
`AMUNDSON, Administrative Patent Judges.
`
`
`
`

`

`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`BRIAN HOFFMAN, ESQ.
`Fenwick & West LLP
`555 California Street
`San Francisco, CA 94104
`(415) 875-2484
`bhoffman@fenwick.com
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`RONALD ABRAMSON, ESQ.
`MICHAEL LEWIS, ESQ.
`Liston Abramson LLP
`The Chrysler Building
`405 Lexington Avenue, 46th Floor
`New York, NY 10174
`(212) 257-1643 (Abramson)
`(212) 257-1639 (Lewis)
`Ron.abramson@listonabramson.com
`Michael.lewis@listonabramson.com
`
`
`
`The above-entitled matter came on for hearing Tuesday December
`
`12, 2023, commencing at 10:00 a.m. EST.
`
`
`
`
`
`
`2
`
`

`

`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`
`P-R-O-C-E-E-D-I-N-G-S
`10:00 a.m.
`
`
`
`
`
`
`
`
`
`JUDGE LORIN: This is an oral hearing covering two cases,
`IPR2022-01430 and 01433. IPR2022-01430 concerns U.S. Patent
`9,742,824. And the 1433 case concerns U.S. Patent 9,762,636. In both
`cases, Petitioner is Amazon.com, Inc. et al., and Patent Owner is WAG
`Acquisition, LLC. I'm Judge Lorin. I'm accompanied by Judge Hudalla and
`Judge Amundson. And Judge Amundson will appear remotely by video.
`Let's begin with counsel. Petitioners, please introduce yourself.
`MR. HOFFMAN: Hi, I'm Brian Hoffman for Amazon. With me is
`Kevin McGann and Johnathan Chai.
`JUDGE LORIN: Mr. Hoffman, will you be arguing for Petitioner?
`MR. HOFFMAN: Yes.
`JUDGE LORIN: Very good. Patent Owner?
`MR. ABRAMSON: I'm Ronald Abramson for the Patent Owner,
`WAG Acquisition, LLC. And with me is Michael Lewis.
`JUDGE LORIN: Mr. Abramson, will you be -- will you be arguing
`for Patent Owner?
`MR. ABRAMSON: Yes, I will.
`JUDGE LORIN: All right, very good. Thank you so much.
`Welcome to the Board.
`MR. ABRAMSON: Thank you.
`JUDGE LORIN: All right, let's go through some preliminaries. We
`stated in our hearing order of November 1st that each party would be given a
`total of 60 minutes to present their argument. Petitioner will proceed first.
`Patent owner will respond. Using any reserved rebuttal time, Petitioner may
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`respond to Patent Owner's case. And finally, using any reserved surrebuttal
`time, Patent Owner may respond to Petitioner's rebuttal argument. We
`received demonstratives from both parties. We noticed that Petitioner
`objected to slides 13 and 19 of Patent Owner's demonstratives. We will not
`be ruling on them today, but we take the objections under advisement.
`The panel reminds the parties that demonstratives will be considered
`only to the extent they are helpful to the Board, that they articulate positions
`taken during the hearing and reflect arguments and evidence that was made
`of record during the trial. We ask that each presenter identify clearly and
`specifically each demonstrative exhibit by slide or screen number to ensure
`clarity in the transcript. As you speak, please bear in mind that Judge
`Amundson is attending the hearing by video. And also, remember that this
`hearing is open to the public and a full transcript of the hearing will become
`part of the record. Okay. Let's begin. Counsel for the Petitioner, you may
`begin. Would you like to reserve any rebuttal time?
`MR. HOFFMAN: Yes. 20 minutes, please.
`JUDGE LORIN: All right, thank you so much. You may proceed.
`MR. HOFFMAN: All right. Slide 2, please. Good morning, Your
`Honors. As you noted, we're here to discuss two patents, the 824 patent and
`the 636 patent. There are the same issues and arguments for both patents.
`I'm going to show you today that the Carmel reference stores the slices that
`makeup the stream in separate files. That the experts agree that the most
`common way for a client to request separate files is by using separate GET
`requests. And then the challenged patents are invalid as a result.
`So slide 3, please. So the challenged patents relate to streaming media
`from a server to a user system, which I often refer to as a client. The media
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`is divided into a sequence of elements having unique identifiers. And the
`user systems request the elements using the identifiers. This is called a
`client pull system because the clients request the elements from the servers
`using the identifier. And then the server sends the elements in response to
`the request. So that's a pull system.
`The challenged patents also have what we call the rate limitation
`which is shown at the bottom of slide 3, which says that the data connection
`between the server and the user system has a data rate more rapid than the
`playback rate. Meaning that the server can send data to the client in less
`time than it takes the client to play back that data. So slide 4, please. Both
`petitioners challenge all claims of both patents using a combination of three
`references, Carmel, Willebeek, and Feig. And we'll be talking about Carmel
`and Feig today. Willebeek doesn't come up in any of the disputed issues.
`Slide 5, please. So we have three limitations in dispute today. The
`first limitation, H, is the rate limitation that we just discussed. The next
`limitation is J, which says the media data elements sent are selected without
`depending on the server system maintaining a record of the last media data
`element sent. And limitation K says all of the media data elements sent by
`the server are sent in response to requests. So, elements -- limitations J and
`K describe the pull aspect of the claims. J is saying that the server doesn't
`need to track the elements that are sent to the client because the -- it's only
`responding to client requests. Element K says that the server only sends a
`request to elements. That reflects the pull nature of the claims.
`Slide 6, please. So, what we're going to discuss today is that a
`POSITA would have understood that both the Carmel and Feig references
`disclose the pull system. POSITA would have been motivated to combine
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`the references. And once you have that combination, the three disputed
`limitations are obvious. So slide 7, please. Briefly, on claim construction.
`Petitioner asserts plain and ordinary meeting for all terms. This is the same
`construction that the Patent Owner used in the parallel litigation. And it's
`also the same construction used by the Board.
`Slide 8. The Patent Owner's response has over ten pages of claim
`construction discussing the preamble and numerous limitations, including
`some of the ones at dispute today. But the constructions don't affect the
`disputed limitations. They don't affect any of the issues today. And, in fact,
`Patent Owner didn't even discuss the constructions in their sur-reply. So I
`will not return to those issues today unless you have any questions.
`All right. Slide 9 discloses a Carmel reference. Describes it. All
`right. Carmel, like the challenged patents, relates to -- multimedia streaming
`from server to a client using HTTP. Like the challenged patents, it divides
`the stream into a sequence of segments and then the clients download the
`data stream, the segments in the data stream, using HTTP. And as shown at
`the bottom quote on the slide, Carmel says that each segment or slice is
`preferably contained in a separate file, that's by the server. So we'll explain
`why that's important.
`Slide 10, please. The Patent Owner's main argument is that Carmel
`only discloses a push system, in which the server pushes the data to the
`clients. But their argument relies on a different embodiment than the one in
`the petition. Slide 11. The petition -- well, actually Carmel itself, not the
`petition. Carmel discloses two embodiments. There's a single quality level
`embodiment which is represented in the patent by data stream 40 and figure
`3A, and also by the flowchart in figure 6A which describes the operation
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`between the server and the client in a single quality level embodiment.
`And then on slide 12 -- slide 12, you see the multiple quality level
`embodiment that's also disclosed in Carmel. And this one has data stream
`41 which is represented by a different figure, 3D, and also a different
`flowchart, 6B, that describes the operation when there are multiple quality
`levels. Slide 13, please. The petition relies on Carmel's single quality level
`embodiment. If you look at the petition, and you look particularly at the
`portions that analyze the claims and explain why the claims are invalid,
`you'll see that it cites to figure 3A and 6A, and it walks through Carmel's
`disclosure related to the single quality level embodiment. And as shown on
`slide 14, Carmel's single quality level embodiment is a pull system.
`The description in the specification associated with 6A shows you that
`the client opens multiple HTTP links with the server. It downloads separate
`slice files, which you'll recall are stored by -- preferably stored as separate
`files at the server, over these multiple HTTP links in successive alternation
`over the links. And POSITA would recognize that in this scenario, where
`you have separate files downloaded over multiple links, that this would be
`accomplished using multiple GET requests. This is a pull system, just like
`in the challenged patents.
`Now, slide 15, please. The institution decision noted that Carmel does
`not explain details about HTTP. But the experts agree that using HTTP
`GET requests to retrieve separate files was known. And this, Your Honor, is
`what -- distinguishes the 141 reexamination decision that was added to the
`record late. That decision was based on anticipation and inherency, and it
`did not have the benefit of the expert opinion that is brought forth in the
`obviousness analysis in the current petitions, in the current IPRs. So, the
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`141 reexamination was under different standards.
`JUDGE AMUNDSON: This is Judge Amundson. On the -- on the --
`I had a question on the reexam.
`MR. HOFFMAN: Yes.
`JUDGE AMUNDSON: It's a decision by the Board, and I think it's in
`Amazon's latest brief. But as I understand the situation there, according to
`Amazon's position, WAG did not submit in the reexamination either Dr.
`Houh's declarations from the Disney IPRs or Dr. Jeffay's declarations from
`the Amazon IPRs. Do I have that right?
`MR. HOFFMAN: Yes, that's correct as far as we can see from the
`record. So the Board in that reexamination decision was looking at
`anticipation primarily, and it did not have the benefit of any of the expert
`testimony from these IPRs --
`JUDGE AMUNDSON: All right, thank you.
`MR. HOFFMAN: -- or the Disney IPRs.
`JUDGE AMUNDSON: Okay. Thank you.
`MR. HOFFMAN: All right. So on slide 15, as we discussed, the
`experts agree that using GET requests, using separate files, was known. And
`if you turn to slide 16, you'll see this is a paragraph from our -- from our
`expert, Dr. Jeffay, that recognizes that POSITA would have known that you
`can make separate GET requests for separate files in a scenario like
`disclosed in Carmel. And if you turn to slide 17, you'll see that Patent
`Owner's expert, Mr. Hoarty, also agrees that using GET requests in this
`manner was obvious. He says that GET requests were the most common
`request in HTTP. And as you see on the right side, he says a GET request
`can request any particular file.
`
`
`
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`
`So slide 18, please. This slide needs a little bit of explanation. The
`WAG's argument based on push is based primarily on misinterpretation of a
`portion of Carmel. Within Carmel, there's one paragraph in column two of
`the document that describes how the data are stored at the server. And it
`starts, as you can see, by saying, preferably, each segment or slice is
`contained in a separate, respective file. And then it provides an alternative
`embodiment where the stream is contained in a single indexed file. And
`then it says that single file can be streamed to the client as a series of
`packets, and it says HTTP version 1.1 supports this sort of file streaming.
`But it's clear from the context that this sort of file streaming is referring to
`the previous sentence which is talking about streaming a single file
`containing the entire -- all of the segments. And our experts tell us this type
`of streaming is called chunked transfer encoding. It was new to HTTP
`version 1.1.
`But as shown at the bottom of the slide, it's important to note that
`Carmel specifically says that the single quality level embodiment stores the
`segments as separate files, and even the paragraph above says that preferably
`each segment or slice is contained in a separate file. And the single file
`embodiment on which Patent Owner's push arguments are made is based on
`this alternative embodiment in which there's only one file.
`And slide 19. Briefly, Patent Owner's expert also recognized that the
`chunked transfer encoding is suited to large files, i.e., the single file
`embodiment. Slide 20, please. But I do want to be clear, Your Honor, that
`our expert, Dr. Jeffay, testified that Carmel's single quality level
`embodiment is a pull system. But he also testified that this multiple quality
`level embodiment in Carmel is best described as a push scenario.
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`
`So slide 21 please, and I'll explain why that's the case. Carmel uses
`different language to describe the two embodiments, the 6A and 6B
`embodiments. Under 6A, as shown here and as I mentioned earlier, the
`client opens one or two HTTP links with the server over which files are
`downloaded in successive alternation. This is a pull system because the
`client needs to request the files over the links in order for the server to know
`what to send over the links. So that's why the single quality level is a pull.
`Carmel uses different language for 6B. The client only opens a single link
`with the server and the flowchart is different. And the -- so the multiple
`quality level has a different operation than the one that we're using in the
`petition.
`Slide 22, please. Now, Dr. Jeffay testified about Carmel in an ITC
`proceeding involving different parties. And in there, he answered one
`question in a way that the Patent Owner interprets to mean he thought
`Carmel's single quality level embodiment was a push system. But he was
`speaking to anticipation and inherency in Carmel.
`And also, which I'll show in slide 23, in his IPR deposition, Dr. Jeffay
`explained that his comments in the ITC were about a hypothetical
`combination of Carmel's two embodiments, the single and multiple quality
`level embodiments. He wasn't referring to Carmel's single quality level
`embodiment alone. And if you look at the ITC questioning, which is on the
`right side of this slide, you can see he was actually being asked about
`combinations of 6A and 6B, which are the two different embodiments in
`Carmel. So, the ITC questioning matches up with the answer he gave in his
`IPR deposition.
`All right. So slide 24, please. This is wrapping up on Carmel. So as I
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`discussed, Carmel discloses storing the segments in separate files on the
`server. And the experts agree that it would have been obvious that these
`slices could be requested using a series of GET requests. And that is a pull
`system. So Carmel discloses a pull system. All right, let's turn to slide 25,
`please. This is the Feig reference, the other reference that we're going to talk
`about. So Feig also relates to media streaming, like Carmel and like the
`challenged patents. It describes a web browser that makes URL requests.
`And according to Feig, it causes a non-streaming server to simulate a
`streaming server. So we'll go to slide 26, and I'll explain how Feig works.
`So I'll give you a little intro, and then we'll walk down the left side of the
`flow chart with the highlighted boxes.
`So Feig partitions the media stream into these elements or these
`chunks of data it calls segments. And then within each segment, there are
`separate chunks of data. It calls them URLs or something. It's a very
`confusing name. But within each segment, there are separate addressable
`units of data that would be stored in separate files by the server, because
`each of those is addressable by a separate URL. So the client can request the
`sub-segment information using separate URLs. So you have these segments,
`each segment having sub-pieces of data within it. The way it works in Feig
`is that the client browser allocates two buffers. Each buffer is large enough
`to store a segment.
`And then if you walk through Figure 4 shown on the slide, the first
`highlighted box, Fetch Segment, what Feig does is it issues a series of URL
`requests which we would understand to be HTTP GET requests, to retrieve
`the data at the URLs of the segment. And it loads the segment into a buffer.
`And recall it's got two buffers. So the first buffer, it loads the segment into.
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`And then once the segment is fully loaded into the buffer, it begins playback
`from that buffer. And then while it's playing back from that buffer, it loads
`the data for the next segment into the next buffer.
`There's two buffers so it plays from one, it loads from the other. And
`then when the second segment is loaded into the second buffer, it stops
`requesting any data while it's still playing back the first buffer. That's the
`wait auto module that's shown in the figure. And then eventually it's going
`to finish playing back from the first buffer. It's going to start playing back
`from the second buffer, and then it's going to reload data into the first buffer.
`So it just alternates between the buffers.
`So the takeaway that we're going to come back to for this is Feig
`provides a technique for managing data loaded into buffers. It doesn't
`overflow the buffers because it stops requesting data once it's got a full
`segment in the buffer. Then it just stops with the request. It plays back --
`and then only plays back when it needs to load a new buffer.
`So slide 27, please. So there's no dispute that Feig discloses a pull
`system. The Patent Owner in their response refers to Feig as a pull system.
`And then the Board in the institution decision used language discussing the
`individual URL requests in Feig which are consistent with treating Feig as a
`pull system as well.
`So slide 28, please. All right. This is the motivation to combine of
`these two references. The petition provides multiple motivations to combine
`these references. At the top level, I think it's important to remember that
`both references relate to streaming over the Internet. And both references
`relate -- I'm sorry, both references break the media stream into separate files.
`And both references disclosed using HTTP to retrieve the data from the files
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`-- from those separate files to the client. So at that level, the references are
`extremely similar. And the POSITA would have been motivated -- the
`POSITA in possession of Carmel would have been motivated to look to Feig
`to the extent it was necessary.
`The petition provides multiple individual motivations, some of which
`are listed here. Number two, in particular, is that the combination of Carmel
`and Feig allows the client to precisely control and select which segments it
`receives. So that's just Feig's buffer management technique within the --
`within Carmel. That would avoid buffer overflow and these sorts of
`problems along those lines because Feig teaches exactly how to load data
`into buffers and not retrieve any data that you don't have room for. So slide
`29. I just want to point out that the Patent Owner's arguments against the
`motivation to combine the references improperly assume that Carmel only
`discloses the push system. That's not right as we just talked about earlier.
`Slide 30, please. But I do want to be clear that even if the Board were
`to find that Carmel discloses only a push system, there's still motivation to
`combine the references because the principle of operation between the two
`references remains the same. You're still sending content from a server to a
`client using HTTP GET requests. So really, even if Carmel were a push, it's
`still similar and there would be motivation to combine.
`All right. Next is slide 31, which is -- now we actually get to the
`dispute of limitations. So we're going to start with limitation H, which is
`that the data rate is more rapid than the playback rate. Carmel provides an
`example -- well, Carmel provides a statement where it says that the data rate
`between the client -- I'm sorry, the server and the client should generally --
`should be generally equal to or faster than the rate at which the data are
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`generated at the transmitting computer, which one would understand is the
`playback rate. The Board noted in the institution decision that Carmel's
`disclosure of equal to or faster teaches a faster data rate.
`And slide 32, the Patent Owner does not dispute that basic finding that
`Carmel teaches a faster data rate. Their primary argument in the response is
`that Carmel doesn't say to what data rate it's referring. And they say that
`Carmel may be referring to a later embodiment in which it's the data rate of
`an aggregated connection, a connection formed of the aggregate of multiple
`links. But the Board in the 141 IPR on remand, not to be confused with the
`141 reexamination, the 141 IPR on remand already found that this passage is
`describing the sufficient rate during normal streaming operation and not
`referring to aggregate links. So, Patent Owner already made this argument.
`The Board already decided it was incorrect. And Patent Owner should be
`precluded from making that same argument here because the issue has
`already been decided and they did not appeal it in that case.
`All right. Slide 33 then. Now the other reference, Feig, has an
`explicit example showing the rapid data rate. Feig gives an example in
`which one minute of video is sent over a channel in 30 seconds. So in other
`words, a video that takes one minute to play back at the client is sent over
`the network in 30 seconds. That meets limitation H because the network
`connection has a data rate more rapid than the playback rate. And there's no
`dispute that that disclosure meets limitation H.
`If you turn to slide 34, what Patent Owner argues is that Carmel
`doesn't disclose that the client system has buffers. And if Carmel were used
`with a very fast network, then the server would send the data to the client
`faster than the client can consume the data through playback and ultimately,
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`the client would be overloaded with data and the whole system would just
`break down. But to the extent that's actually a problem, a POSITA would
`have been motivated to combine and use Feig's solution that solves that
`problem by precisely controlling and selecting the segments that the client
`receives and stores in the buffers. So to the extent, that's a problem. A
`POSITA would have -- in possession of Carmel would have looked at Feig,
`which discloses the solution to that problem.
`All right. So next slide please, 35. This is limitation J. This one,
`you'll recall, is that the server does not maintain a record of the last element
`sent to the client, so it's part of the pull nature. The Board and the institution
`decision made a preliminary finding that Carmel alone, and in combination
`with Feig, teaches this element. Slide 36. I want to briefly talk about
`Carmel again. The way Carmel works is that the client downloads an index
`file that -- that identifies the slices, it identifies the identifiers for the slices
`or segments, and it has -- it identifies the order in which they appear.
`So the client downloads the index file, and then the client shows this
`graphical slider shown in the slide to the user. The user can use that slider to
`pick a starting location, and then once you hit play from that starting
`location, the client requests the segment at that starting location using the
`index. And then, the client -- as we've discussed, a POSITA would
`recognize that the client would then be able to request subsequent slices
`using the index file and continue playback by requesting subsequent slices.
`So that -- for that reason, the server doesn't need to maintain a record of the
`last element sent to the client. It merely reacts to the request from the client
`and sends the requested segment.
`Slide 37, please. I just want to reiterate that Patent Owner's expert
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`admits that this sort of operation where the client is making successive
`requests for the next segment or slice is the way to do it. It would have been
`obvious. All right. Now, slide 38. This operation of Carmel I've just
`described is consistent with the Board's description of Carmel in the 141
`IPR. There the Board found that Carmel has client-side control, it lacks
`special server software for tracking elements sent, and it lacks protocols
`involved in tracking the last element sent. So what I'm -- how I'm describing
`Carmel today is consistent with how the Board analyzed Carmel in the past.
`Now, slide 39. Patent Owner does not dispute that Feig discloses
`limitation J. Feig is a pull system as we discussed and that meets limitation
`J. If you look in the Patent Owner's response, they discuss Carmel and then
`they move straight to an argument involving the combination of Carmel and
`Feig. They don't discuss Feig separately. And the argument they provide
`assumes that Carmel is a push system, and is only a push system, which is
`incorrect for the reasons I've already described.
`All right. So slide 40 please. This is the last of the three disputed
`limitations. This is limitation K. All of the elements are sent by -- all of the
`elements that are sent by the server to the client are sent in response to the
`requests, i.e. the server doesn't send anything that wasn't requested. All
`right. In the institution decision, the Board made the preliminary finding
`that Carmel and Feig each disclosed this limitation.
`And go to slide 41, we'll see how Carmel does it.
`All right. And as we've already discussed in Carmel, the slices are
`preferably stored as separate files. It would have been obvious for the client
`to request each file, or each slice individually using a GET request. And as
`shown as the -- on the quote from our expert on the bottom right of this
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`slide, the server only sends what is requested and no other slices. So the
`client is making the request, the server is responding to the request, and the
`server only -- only sends what is requested. That meets limitation J -- I'm
`sorry, K.
`All right. Slide 42. Feig reference. Patent Owner does not dispute
`that Feig discloses this limitation. As we've discussed, Feig fills the client
`buffer by making requests to the URLs for the constituent portions of the
`segment, and then it stops making requests once it's got the entire segment in
`the buffer. And we know that the server is not sending any more data than is
`requested because if it did, it would overload the buffer, and that doesn't
`happen. So, Feig meets this as well. Slide 43. Patent Owner argues against
`the combination of Carmel and Feig, but their argument is based on a
`purported modification of the data rate in Carmel. And then they also
`assume that Carmel only teaches a push system, but both of these premises
`are incorrect. And when viewed through the correct lens, their arguments
`don't work.
`So slide 44, which is the conclusion, Your Honor. Each of the
`references, Carmel and Feig, demonstrate that it was obvious to request, you
`know, use HTTP GET requests to request separate files from the server. It
`was -- it was obvious to combine these two references because they're very
`similar. And the limitations of the dispute are plainly disclosed by the
`combination. So, Your Honors, that's why the challenged patents are
`invalid. And so, do you have any questions?
`JUDGE LORIN: No, counsel. Thank you so much.
`MR. HOFFMAN: All right, thank you. I'll reserve the rest of the
`
`time.
`
`
`
`
`
`
`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
`
`IPR2022-01430 (Patent 9,742,824)
`IPR2022-01433 (Patent 9,762,636)
`
`
`
`JUDGE LORIN: Counsel, would you like to reserve rebuttal time?
`MR. ABRAMSON: I'll reserve 20 minutes.
`JUDGE LORIN: You may proceed.
`MR. ABRAMSON: I'm sorry, did you hear what he said?
`JUDGE LORIN: You may proceed.
`MR. ABRAMSON: Thank you. So as we've just heard, Amazon's
`principal reference in this case is Carmel. And the arguments that Amazon
`is making on Carmel, particularly, it really goes to all the limitations. The
`rate limitations as well as the -- as well as the request limitations, are based
`on the hypothesis that the way Carmel works, at least the embodiment they
`want to focus on is 6A single-level embodiment, is by doing streaming by
`way of successive individual HTTP GET requests for slices. That's at the
`root of it. Without that, their entire argument as to J and K -- limitations J
`and K in Carmel just have no basis. And so it's premised on that reading of
`the reference.
`And that reading of the reference, I will submit to you, is untenable,
`particularly in light of the testimony of their own expert. So, first of all,
`with regard to Carmel itself, where does this -- where, you know, where's the
`genesis of t