Trials@uspto.gov
`571-272-7822
`
`
`Paper 67
` Entered: December 13, 2021
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`NETFLIX, INC. and HULU, LLC,
`Petitioners,
`
`v.
`
`DIVX, LLC,
`Patent Owner.
`__________
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`__________
`
`Record of Oral Hearing
`Held: November 10, 2021
`__________
`
`Before BART A. GERSTENBLITH, MONICA S. ULLAGADDI, and
`IFTIKHAR AHMED, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`Paper 67
` Entered: December 13, 2021
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`NETFLIX, INC. and HULU, LLC,
`Petitioners,
`
`v.
`
`DIVX, LLC,
`Patent Owner.
`__________
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`__________
`
`Record of Oral Hearing
`Held: November 10, 2021
`__________
`
`Before BART A. GERSTENBLITH, MONICA S. ULLAGADDI, and
`IFTIKHAR AHMED, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`IPR2020 00614
`Patent 7,295,673 B2
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONERS:
`
`
`HARPER BATTS, ESQ.
`JEFFREY LIANG, ESQ.
`Sheppard, Mullin, Richter & Hampton, LLP
`Four Embarcadero Center
`Seventeenth Floor
`San Francisco, California 94111
`650-815-2673 (Batts)
`650-815-2685 (Liang)
`hbatts@sheppardmullin.com
`jliang@sheppardmullin.com
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`Kenneth Weatherwax, ESQ.
`PARHAM HENDIFAR, ESQ.
`Nathan Lowenstein, ESQ.
`Colette Woo, ESQ.
`Lowenstein & Weatherwax LLP
`1880 Century Park East
`Suite 815
`Los Angeles, California 90067
`310-307-4510
`hendifar@lowensteinweatherwax.com
`
`
`
`
`
`The above-titled matter came on for hearing on Wednesday,
`
`November 10, 2021, commencing at 1:00 p.m. EST, via Video-
`Teleconference.
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`P-R-O-C-E-E-D-I-N-G-S
`
`
`
`1:00 p.m.
`JUDGE ULLAGADDI: Good afternoon. We are here
`today for oral argument in Inter Partes Review Matter No. 2020-
`00614, a case in which Netflix and Hulu constitute petitioner and
`DivX is the patent owner.
`At issue is US Patent No. 7,295,673. Your panel for the
`hearing today is includes Judges Gerstenblith, Ullagaddi, and Ahmed.
`I would like to start by getting appearances of counsel for
`petitioner.
`MR. BATTS: Hello, Your Honor. This is Harper Batts on
`behalf of petitioner, and with me is Jeff Liang.
`JUDGE ULLAGADDI: Thank you. And who do we have
`on behalf of patent owner?
`MR. HENDIFAR: Good afternoon, Your Honor. Parham
`Hendifar for patent owner, DivX.
`Here also with me, Mr. Kenneth Weatherwax, lead counsel.
`Also present in the room, backup counsel, Nathan Lowenstein and
`Ms. Colette Woo.
`JUDGE ULLAGADDI: Okay. Thank you. And before
`we get further underway, I don't think hearings received any
`notification that confidential information or potentially sealable
`exhibits will be discussed or secondary considerations. Can you
`confirm that that is true, Mr. Hendifar?
`
`
`
`3
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`MR. HENDIFAR: It is true. And none of the slides contain
`any confidential information.
`JUDGE ULLAGADDI: Mr. Batts, petitioner?
`MR. BATTS: And as far as we are aware, we don't expect to
`discuss the confidential details of those confidential exhibits at this
`hearing.
`JUDGE ULLAGADDI: Okay. So it's all right if we have a
`public audio line connecting to this hearing?
`MR. HENDIFAR: Yes, and we, in fact, requested a public
`hearing line. And I believe DivX representatives are present on the
`line.
`
`JUDGE ULLAGADDI: Okay. Thank you. As you are
`aware, this hearing is being held remotely through a video conference.
`Our primary concern is everyone's right to be heard. If at any
`time during the hearing you do encounter technical or other
`difficulties that you feel may affect or undermine your ability to
`adequately represent your client, please let us know immediately by
`contacting the team member who provided you with the connection
`information.
`We will try to address any issues that may arise. If
`necessary, we can also adjust your time to account for any technical
`issues.
`
`The judges have the parties' demonstratives. Please
`remember when referring to the demonstratives to identify what slide
`
`
`
`4
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`number you're on so that we can all follow along and also to make the
`record clear.
`And for the record, please identify yourself when speaking
`and try to pause a little bit after each slide in case we have questions.
`Also, I'd like to remind everyone that recording of this
`proceeding, either by audio or video, is prohibited.
`As set forth in our oral hearing order, each party will have 60
`minutes to argue.
`Petitioner who bears the burden to show unpatentability of the
`challenged claims by a preponderance of the evidence will begin by
`presenting its case in chief.
`We'll take a short break after that. Patent owner will then
`respond to petitioner's arguments.
`We'll take a short break after that. And then thereafter,
`petitioner may use any time that it has reserved for rebuttal to respond
`to patent owner's arguments.
`And patent owner may thereafter use any time that it has
`reserved for surrebuttal to respond to petitioner's rebuttal.
`Mr. Hendifar, would you like to reserve any time for rebuttal
`
`today?
`
`please.
`
`MR. HENDIFAR: Yes, we will be reserving 20 minutes,
`
`JUDGE ULLAGADDI: Okay. You'll have 40 minute for
`your primary case.
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`5
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`And when you are ready, we invite you to present your
`remarks.
`MR. HENDIFAR: Your Honor, actually we are the patent
`owner. I believe Mr. Batts will be presenting first.
`JUDGE ULLAGADDI: Oh, sorry. Oh, dear. Let's go
`back to -- let's go to Mr. Batts. Ooh, thank you very much for
`clarifying.
`MR. BATTS: No problem, Your Honor. The answer is the
`same, 40 minutes for my opening.
`Just to clarify, I will be presenting with Mr. Liang today.
`And I will be covering the frame encryption function and
`synchronized decryption screen arguments.
`And he will be covering the motivation to combine arguments.
`JUDGE ULLAGADDI: Okay, great. When you're ready,
`you can start.
`MR. BATTS: Thank you, Your Honor. I'd like to actually
`start on slide 72 because I do want to touch on one point before we get
`into the instituted ground here. And that's on the issue of patent
`owner's arguments about products for licensees.
`Even in the first page, the patent owner responds. And again,
`the slide, we see these arguments by patent owner about over a billion
`devices using the alleged invention.
`
`
`
`6
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`But patent owner has made no effort to even attempt to show
`nexus between this patent to any devices that are used in the
`marketplace.
`And therefore, any sort of discussion or these statements
`should be entirely ignored because they're without any evidentiary
`basis.
`
`And I'd like to then turn to slide 4 because I believe this is --
`despite 120 slides that patent owner has provided, I do actually think
`this is a pretty straightforward dispute in case where we have two
`issues remaining to claim 1.
`The first issue is whether petitioner has satisfied for its ground
`the frame encryption function limitation and secondarily whether
`petitioner has satisfied the last element, the synchronized frame
`decryption stream element.
`And it's a straightforward case because patent owner's
`arguments on both of these terms are based upon requirements that
`aren't in the claims, that are not in the Board's construction, and are
`inconsistent with patent owner's admissions, their district court
`positions, and their own expert's testimony.
`So please turn to slide 6. Slide 6 just lays out the Board's
`construction from the institution decision on frame encryption
`function.
`And that construction includes stating if the function requires
`specifying the location by layout or offset.
`
`
`
`7
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`So it's clear that the construction requires a location, and that
`location can be established by layout our offset.
`And if we go to slide 7, the petition set forth an explanation of
`how frame encryption function satisfies.
`In our petition, we explain that the Demos reference teaches
`selecting which frames to encrypt.
`And then we provided two separate bases for how parts of
`those frames are encrypted.
`We pointed to the Fetkovich reference to teach that slices and
`macroblocks are encrypted based on encryption parameters.
`And separately, we explain that the Demos reference teaches
`the use of DC and AC coefficients.
`So if we go to slide 15, what we see in the briefing by patent
`owner is that patent owner is seeking to limit the Board's construction
`of frame encryption function to require a byte location of a byte
`offset.
`
`So that's permeated their briefing, both in their patent owner
`response as well as in their surrebuttal.
`Turning to slide 16, the patent owner has argued that the
`embodiments are teaching offset, that all the embodiments require a
`location by offset.
`But it's clear that the patent is not limited to offset but also to
`include layouts.
`
`
`
`8
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`And it gives two different examples of layouts that we've set
`forth in the middle of that slide.
`And at the bottom of the slide, we note that patent owner's
`expert conceded and admitted that layouts are not limited to those two
`sample layouts that are set forth in the middle of the slide and that
`layouts are different than offset. It's not a synonymous term.
`JUDGE ULLAGADDI: Counsel, can I ask is it petitioner's
`position that identifying a slice or a macroblock would meet the
`layout portion of the construction?
`MR. BATTS: Yes, Your Honor.
`JUDGE ULLAGADDI: Okay.
`MR. BATTS: It satisfies both location aspects of the
`construction.
`JUDGE ULLAGADDI: Okay. Thank you.
`(Simultaneous speaking.)
`JUDGE ULLAGADDI: Please continue.
`MR. BATTS: So I think the next slide is actually relevant to
`that question because if you look at slide 17 of petitioner's slides,
`layout is actually -- it sets forth testimony from Dr. Nielson there on
`the bottom.
`And I want to read that testimony because we actually asked
`him about, can you give us an example of where an encrypted portion
`is specified in terms of layout and its location base but not offset?
`
`
`
`9
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`And he showed that layout is a broad concept. He said, one
`example would be just going 50 percent of the way into a frame.
`And if we turn to patent owner's slides, patent owner slide 17,
`they include a graphic there that I think that -- I think the parties
`actually agree on the graphic which was consistent actually with
`figure 5 of the patent as well, that frames do vary in size.
`I don't think there's a dispute that frames vary in size. And
`what Dr. Nielson is saying is that you can have an offset that is simply
`set for going 50 percent of the way on a particular frame.
`So we turn back to petitioner's slide 18, what you see is a very
`stark difference between the declaration of patent owner on the top of
`the slide where it says the patent leaves no ambiguity that offset refers
`to a byte offset.
`But in his deposition, patent owner's expert walked away from
`this opinion and conceded that it's not limited to bytes.
`So despite their briefing of bytes, bytes, bytes, their own
`expert conceded that even for offset, offset is not limited to bytes for
`these claims.
`So now I'd like to turn to slide 27. And I think this set of
`slides is extremely important because what we see here, this is a slide
`of patent owner's infringement contentions from the district court.
`And if we go into the specific language, this is the chart for
`this claim limitation about frame encryption function.
`
`
`
`10
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`And if you look at the language at the bottom of the slide that
`we've highlighted, patent owner stated that you look at a sample and
`they went specifically to subsample 8.
`And they identified it as a slice, an IDR slice, comma, a NAL
`unit containing video information.
`So for this claim limitation, this claim element, they pointed to
`
`a slide.
`
`And they pointed to saying a NAL unit is a slice and here's the
`NAL unit.
`And in this slice, there is a determined, a set number of bytes.
`And they pointed to 80 encrypted bytes and 11 unencrypted bytes.
`JUDGE ULLAGADDI: Counsel, a question --
`MR. BATTS: If we go to the next slide --
`JUDGE ULLAGADDI: -- about slices and frames and all
`these substructures, is there a minimum or maximum number of slices
`that are in a frame?
`MR. BATTS: I'm not aware, no. I don't believe so.
`JUDGE ULLAGADDI: Okay. And any typical number?
`Would it typically know that it has to be more than one slice in a
`frame?
`
`MR. BATTS: I believe it's typically one slice per row of a
`
`frame.
`
`So you have a frame. And then within a frame, you have
`substructures.
`
`
`
`11
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`In a substructure, like, for example, Dr. McDaniel explained
`that you would have a substructure that would be, for example, a slice.
`And then slices are made up of macroblocks. And then
`macroblocks are made up of specific byte ranges -- specific sets of
`bytes.
`
`And that's what's notable here, and that's what I'm trying to
`show actually.
`And if we go to the next slide which is again their contentions,
`if you have -- if you look at the -- you have to kind of zoom in, but I
`want to go very carefully here.
`Immediately below the language where they identify a slice
`for this claim limitation, this is their red box.
`And in their red box, they're pointing a NAL, which they
`identified as a slice, which is consistent with the language there where
`in the box, it's identifying it as a slice.
`And then they are showing that that slice is made up of a
`defined number of bytes.
`And that's shown in the next box below where you see that the
`slice number 8, you go down and eight rows down you have the
`number of bytes that are in the clear 11 and the number of bytes that
`are encrypted 8.
`So patent owner has taken directly contradictory positions in
`this proceeding about whether a substructure such as a slice can
`satisfy this claim limitation.
`
`
`
`12
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`And that is clearly evident from this evidence that we're
`showing here.
`And if we go to slide 29, just to further put the nail in the
`coffin, it again goes back to this is their language and their
`contentions at the bottom there.
`They're saying the IDR slice and TRAIL_R slices discussed
`above are NAL units and carry the frame information.
`So you have a frame. There's no dispute that there's frames
`in the video screen.
`Then you have substructures which can be the slices. Then
`you have macroblocks which are the next unit down from a
`substructure from slices.
`And those macroblocks are made up of definitive groups of
`
`bytes.
`
`And if we turn to slide 30, this is really the core of their
`argument on this claim chart because if you go to slide 30 and we're
`going to talk about figure 5 here.
`But throughout their briefing -- and we'll see a shift from their
`briefing to the slides today.
`But throughout their briefing, patent owner insistent the frame
`encryption function requires a specific byte offset.
`And I'm just going to put some cites for you for the record.
`Patent owner responded to 5, 11, 28, 59, the surreply at 3 and 6.
`
`
`
`13
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`That has been their repeated argument about specific byte
`range offset.
`But we'll see from the slides they walked away from that.
`Their slides now talk about -- different frames --
`(Simultaneous speaking.)
`JUDGE ULLAGADDI: Sorry, counsel. I think you
`dropped out for a couple minutes.
`MR. BATTS: Where did you lose me, Your Honor?
`JUDGE ULLAGADDI: Patent owner walked back their
`original position. And counsel, it looks like your video is not
`working. Let's pause.
`MR. BATTS: So I can restart, if you can let me know, I
`guess, Your Honors. Had I moved on to slide 30, or was I still on
`slide 29?
`JUDGE ULLAGADDI: You were on slide 30, and your time
`was paused at 10 minutes, 42 seconds.
`MR. BATTS: Okay. I will restart my discussion to slide
`30. And if I'm repeating myself, I apologize.
`JUDGE ULLAGADDI: So I think what's clear is that
`throughout the briefing, patent owner has insisted that frame
`encryption function require a specific byte range.
`And I cited to, for the record, patent owner response to 5, 11,
`28, 29, the surreply at 3 and 6.
`
`
`
`14
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`If you look at their slides now, they moved away from that
`argument.
`Their slides now appear to be arguing that it's about location,
`not specific byte range but a specific byte range offset at that location.
`But that argument is still premised on bytes. So they're now
`saying that you can't predict the exact byte position of the encrypted
`portion between frames because frames have different sizes.
`But that doesn't matter. Why does that not matter? Because
`this claim looks at the location within a frame.
`And if both parties agree, frames and their substructures do
`come in varying sizes.
`They come in differing sizes, and that's shown in figure 5
`
`here.
`
`And Dr. McDaniel explained that per within each frame, you
`have the size and locations of substructures in that frame that's known
`and that the slices contain macroblocks.
`And those macroblocks refer to specific byte portions in the
`
`frame.
`
`And one example where he talked about that was in Exhibit
`2009 around pages 112-113.
`And similarly, Dr. Nielson explained that slices are numbers
`of blocks strung together. And that was in his deposition at around
`pages 133 to 134.
`
`
`
`15
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`And he also explained that frames are divided into
`macroblocks. So we have consistency there.
`But what Dr. Nielson said -- and I want to be careful about
`what Dr. Nielson said versus what patent owner's attorneys are
`arguing -- is that slices -- the size of slices varies between frames and
`that slice boundaries do not have fixed byte positions across frames.
`But within a frame, there is no dispute that each slice is a
`definitive set if bytes.
`And how do we know that? Well, we just go back to exactly
`what patent owner pointed to in their infringement contentions.
`They pointed to a specific slice and specific bytes within that
`
`slice.
`
`So it doesn't matter if the byte position of slices vary between
`frames because the claims do not require a fixed byte position
`between frames.
`And I want to point out that that's entirely consistent with
`patent in figure five that I have showing on slide 30 because as you
`see in slide 30, yes, frames are varying in size.
`But even in figure 5 of the '673 patent shows that you have the
`bytes that are being encrypted in different locations but different
`locations of specific bytes or specific locations of the frame.
`So they can vary in the exactly location of a particular frame.
`But you know what you're encrypting in that frame.
`
`
`
`16
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`So I think the analogy that I would give is that it's similar to
`having -- you can go down one street of houses or a different street of
`houses.
`If you say, I want to know what the offset is from the
`beginning of the street to the third house, houses do vary. Streets are
`going to vary.
`But for any particular street, you're going to know the offset
`for the third house. You're going to know that location.
`So if we go to 31, I do want to -- if we move on to slide 31, I
`do want to point out that patent owner has conceded that they didn't
`invent partial encryption in the '673 patent.
`But if we go to slide 32, what we see here is a difference
`between the patent and the patent owner's arguments.
`So in the patent owner's arguments on the top of the slide, they
`try to claim that, oh, the '673 patent was about this unique approach
`and it was because it wasn't using substructures.
`The problem with that attorney argument is that it's
`manufactured out of thin air.
`If you look at the '673 patent, it doesn't even refer to
`substructures -- frame substructures.
`There's no reference of we're not going to use frame
`substructures.
`There's just nothing in the patent that matches this alleged
`invention that their attorneys have included in the POR.
`
`
`
`17
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`JUDGE ULLAGADDI: Counsel, you're welcome to proceed
`however you like.
`But I think the panel is somewhat more interested in the
`synchronized frame decryption stream.
`MR. BATTS: Sure. So I can turn right now then to the
`synchronized frame decryption stream.
`So if we go to slide 45, synchronized frame decryption stream,
`we set forth -- petitioners have satisfied this claim limitation by
`showing that there's decryption information provided in the stream for
`each encrypted frame. And therefore, this limitation is obvious.
`If we turn to slide 46, what we see is that there's been a shift in
`patent owner's position.
`And patent owner has now argued that we have to show that
`the frame encryption information is sent and I think they now use the
`language, one-to-one correspondence.
`You have to send it with each frame or correspondence with
`each frame rather than simply providing the encryption information
`for each frame within a screen.
`But we have satisfied -- the Ueno teachings indisputably show
`-- I don't think there's any dispute that Ueno's teachings show that
`even under patent owner's new argument for this claim term, that
`Ueno teaches sending frame decryption information with each frame.
`So I do think -- I guess I want to clarify. Patent owner -- and
`it's not a construction because they haven't asked for a construction.
`
`
`
`18
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`But I guess their interpretation that they've raised from
`surreply is improperly narrow.
`There's nothing in the claim that supports this. They haven't
`proposed construction.
`But there's nothing in the claim that supports this improper
`limiting of the claim.
`But even if we were to limit it to that, we still satisfy if with
`the Ueno teachings.
`JUDGE ULLAGADDI: So is that ---
`(Simultaneous speaking.)
`JUDGE ULLAGADDI: -- petitioner's backup position? So
`the initial position is that you do not need to provide frame decryption
`information for one-to-one correspondence if you provide it once.
`And it addresses encrypted frames, a number of them. That's
`
`fine.
`
`And the backup position is that it indeed has a one-to-one
`correspondence.
`MR. BATTS: I would say yes. The only reason that I
`would -- the reason I waver on backup position is because, to be clear,
`our petition -- and I'm going to go through that in the next couple of
`slides -- our petition set forth both alternatives.
`So we addressed both, whether you send it periodically or you
`send it in one-to-one correspondence that Ueno teaches.
`
`
`
`19
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`But our position on the claim term itself is that the claim term
`is not limiting as the patent owner has now raised and certified for a
`one-to-one correspondence. There's no support for that.
`And so if we turn to slide 47, similar to the first claim term
`that we were discussing, here patent owner has taken inconsistent
`positions on this claim term in the litigation and in this proceeding.
`So in the patent owner response, they said interleaving isn't
`enough to satisfy the frame decryption information. You can't just
`interleave.
`But if you looked at the language in the district court
`complaint -- and I'm going to read it here because I think it's very
`important.
`Netflix's frame decryption information is synchronized with
`said set of encrypted frames into a synchronized frame decryption
`screen when Netflix synchronized the frame decryption information
`by interleaving.
`So patent owner wants to argue here, oh, interleaving isn't
`enough.
`But in district court, they said the exact opposite, that
`interleaving does satisfy this.
`And in the briefing in this case, patent owner has never
`addressed this.
`We raised it, and they never addressed it in the patent owner
`response of the surreply.
`
`
`
`20
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`They simply just did not want to address the inconsistency
`between the two.
`And if we go to slide 48, we have clear teachings, both from
`Ueno and Fetkovich, about the interleaving and multiplexing of the
`information. And I don't believe patent owner has disputed that.
`So if we go to slide 49, patent owner has argued -- or actually,
`I'll just go to slide 50 to save time.
`So if we go to slide 50, we set forth and explain how the
`decryption information can be provided for each frame.
`And we explain how Fetkovich does this, and there's a
`frequency -- if you look at the highlighted on the left, I has a
`frequency of one out of 16.
`So include it in our opening declaration and opening materials
`that you can send it in this periodic fashion.
`And then we go to slide 51, what we see is that initially both
`experts agree that you simply provide the decryption information for
`each frame. And they matched on that originally.
`But if we go to slide 52, what we see that then in surreply and
`now in their slides, patent owner is arguing -- oh, actually, I guess
`arguing two issues.
`One is they're saying it does require a specific one-to-one
`correspondence.
`
`
`
`21
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`And two, the petition never addressed a one-to-one
`correspondence, and that's somehow a new argument by petitioner
`rather than patent owner in its surreply.
`And on both of those counts, they're wrong and I'll like to
`explain why.
`So patent owner clearly has changed its position on
`synchronized frame decryption stream as shown on slide 43 -- 53.
`They originally said it was for each encrypted frame. And
`now they're saying it has to be a one-to-one correspondence.
`In slide 54, we explain both alternatives in our petition. And
`I want to be sure that we address this very carefully.
`So our petition starts on page 46 of our petition. We have
`claim limitation 1G.
`And at the begging of that explanation, I think it's the second
`sentence, we talk about the combination teaches or suggests -- I think
`that's the language on the slide -- it teaches or suggests multiplexing
`including key number and partial encryption and talks about periodic
`information.
`So we set forth an explanation of periodically sending it as
`taught by Fetkovich.
`And then I believe it continues. The section continues. The
`section continues.
`
`
`
`22
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`But on pages 50 and 51, we talk about -- like, for example, the
`bottom paragraph of 50 talks about Ueno teaches sending the key
`number with each frame.
`So patent owner is simply wrong that we did not address both.
`They're different in both positions.
`We said there's two different alternatives. And that's
`especially clear on page 48 of our position on the top where we talk
`about the key number is multiplexed in a synchronized manner with
`encrypted data.
`And I'm not going to quote it all exactly here, but with key
`numbers transmitted at regular intervals or with each frame. So --
`(Simultaneous speaking.)
`JUDGE ULLAGADDI: Counsel, a question about that. So
`you've been talking about key numbers and sending -- and whether
`this claim limitations requires a one-to-one correspondence between
`key numbers and frames.
`But slide 54 says that periodic frame decryption information
`includes key numbers and partial encryption parameters.
`I've noticed neither petitioner nor patent owner's briefing ever
`discusses the partial encryption parameters.
`Everything is centered around the key numbers. Could you
`explain that?
`
`
`
`23
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`MR. BATTS: I actually think we're hitting the part of the
`proceeding where I was going to turn it over to my colleague. So I
`think he will be addressing that.
`But I do want to make sure if there are any other questions on
`the two claim terms before we move on with his discussion of what I
`think of this as his portion for motivation to combine and the
`explanation there.
`JUDGE AHMED: Okay. Mr. Batts, let me follow up on
`what you are trying to explain.
`In the petition, even the slide that you have over there, 54, if
`you read the sentence that's up there, it ends by saying, before the data
`of the corresponding video frame.
`So to me that seems to suggest with every frame. So what
`else is there in the petition where I think you were trying to point us to
`that says where it alleged that it could be sent periodically instead of
`with every frame? Or maybe I'm understanding that sentence wrong.
`MR. BATTS: I think you're misunderstanding that sentence
`because this is the aspect of synchronizing the frame decryption
`information.
`You have to -- I don't think anybody disputes you have to send
`the information to decrypt the frame before that frame is received by
`the decoder because otherwise the decoder can't decode it. So it
`simply has to be received before.
`JUDGE AHMED: Got it.
`
`
`
`24
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`MR. BATTS: Whether you send it every 16th frame like
`Fetkovich teaches or you send it every frame like Ueno teaches, our
`position is that both of those satisfy this claim limitation. But it still
`has to be before. You can't send it after.
`JUDGE AHMED: Okay. Thank you.
`MR. BATTS: And I think that's also made clear in page 48
`as well.
`But I do want to switch over to have that question answered
`by our colleague. So I'm going to switch positions here. Thank
`you, Your Honors.
`MR. LIANG: Good afternoon, Your Honors. Thank you.
`Let me just add to some of the two questions that were just posed.
`So yeah, in answer to the question about where else is there a
`mention of -- is there an explanation that the key numbers, the frame
`decryption information, doesn't have to be sent with every single
`frame?
`
`That's in page 48 of the petition which is on the section 1G for
`synchronized frame decryption stream at the top of page 48.
`The petition says that the key numbers multiplex in a
`synchronized manner with key numbers transmitted at regular
`intervals or with each of frames. So that's towards the top of page 48
`in petition.
`And I think there's also a question about the key numbers and
`the frame decryption information.
`
`
`
`25
`
`
`
`IPR2020-00614
`Patent 7,295,673 B2
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`So in the petition that Dr. McDaniel explained early on the
`motivation that Ueno is sending key -- it teaches sending key
`numbers, multiplexing them into the stream.
`And Fetkovich also teaches multiplexing encryption
`parameters into the stream.
`That's, fo
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
