throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`DISH NETWORK, LLC,
`Petitioner,
`
`v.
`
`TQ DELTA, LLC,
`Patent Owner.
`___________
`
`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`___________
`
`Record of Oral Hearing
`Held: November 8, 2017
`____________
`
`
`
`Before SALLY C. MEDLEY, TREVOR M. JEFFERSON, and MATTHEW
`R. CLEMENTS, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`
`
`
`APPEARANCES:
`
`ON BEHALF OF PETITIONER:
`
`
`HEIDI KEEFE, ESQUIRE
`JEN VOLK-FORTIER, ESQUIRE
`Cooley, LLP
`3175 Hanover Street
`Palo Alto, CA 94394
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`
`RAJENDRA A. CHIPLUNKAR, ESQUIRE
`PETER MCANDREWS, ESQUIRE
`McAndrews Held & Malloy, Ltd.
`500 West Madison Street
`34th Floor
`Chicago, Illinois 60661
`
`
`
`
`
`The above-entitled matter came on for hearing Wednesday, November
`8, 2017, commencing at 2:45 p.m., at the U.S. Patent and Trademark Office,
`600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`
`
`
`2
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE CLEMENTS: Good afternoon. This is the final hearing for
`
`IPR 2016 01469 and 01470 between petitioner DISH Network LLC and
`patent owner TQ Delta LLC.
`
`I'm Judge Clements, participating remotely from San Jose, and in the
`room with you are Judges Medley and Jefferson. At this time we'd like
`counsel to introduce yourselves, beginning with counsel for petitioner,
`please.
`
`MS. KEEFE: Good afternoon, Your Honor. Heidi Keefe on behalf of
`DISH Network. With me at counsel table is Jen Volk-Fortier. With me also
`from Cooley is Steven McBride, and I'm also pleased to introduce my clients
`Larry Katzen and Jim Hemps from DISH Network.
`
`JUDGE CLEMENTS: Welcome.
`
`And counsel for patent owner?
`
`MR. McANDREWS: Good afternoon, Your Honors. Peter
`McAndrews for patent owner TQ Delta, LLC. I have with me Rajendra
`Chiplunkar, who will be making the argument, Tom Wimbiscus, Chris
`Scharf, and from TQ Delta, Nabha Rege.
`
`JUDGE CLEMENTS: Okay. Thank you. Before we proceed, I have
`a couple reminders. Number one, each party will have 45 minutes total time
`to present arguments for the two cases. Petitioner will proceed first and may
`reserve rebuttal time. Thereafter, patent owner will respond to petitioner's
`presentation, and petitioner may then make use of any time it has reserved.
`
`Number two, with respect to demonstratives, please refer to the slide
`number so that it appears in the record and so that I can follow along
`
`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
`
`
`
`3
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`remotely. I have a copy of your demonstratives in front of me.
`
`Any questions, counsel for the petitioner?
`
`MS. KEEFE: No, Your Honor.
`
`JUDGE CLEMENTS: Okay. Any questions counsel for patent
`owner?
`
`MR. McANDREWS: No, Your Honor.
`
`JUDGE CLEMENTS: Very good.
`
`Ms. Keefe, would you like to reserve any rebuttal time?
`
`MS. KEEFE: Yes. I'd like to reserve 20 minutes, please.
`
`JUDGE CLEMENTS: I'll give you a heads up when we approach
`that; and otherwise, you may begin when ready.
`
`MS. KEEFE: Thank you, Your Honor.
`As Your Honor I'm sure is aware, many of the arguments will overlap
`
`with what you just heard, so I'll try to be brief as to those. The big
`difference, obviously, is the use of the secondary references, the other
`materials that we're using in combination with Bowie. Bowie, of course, is
`in common with all.
`
`For the '268 patent, just to reorient us, DISH has proposed Bowie in
`view of Morelli and the 1995 ADSL standard for claims 1, 2, 11, 12. And for
`claims 4, 14, 16, and 18, Bowie in view of Morelli.
`
`For the '470 patent, claims 6, 11, 16, and 20 are rendered obvious in
`view of Bowie, the 1995 ADSL standard, and I'm going to call it the "Van
`reference" -- I apologize -- but for the record to be clear, it is the
`Vanzieleghem, V-A-N-Z-I-E-L-E-G-H-E-M, reference. And I hope the
`Board understands if I simply call it "Van" because I'll never get this
`pronunciation 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
`25
`26
`
`
`
`4
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`Before I dive too much farther into the arguments, I wanted for us to
`
`take just a quick step back up to remember what these patents are all about.
`All of these patents and all of the references -- sorry. I should say the patent
`in question and all the references being used to invalidate them are looking
`at multi-carrier systems and ways of reducing power in those multi-carrier
`systems.
`
`One of the best reasons that all of these are easily combinable is that
`in fact even their titles tell us that that's exactly what they are. They are
`multi-carrier systems with low power modes or multi-carrier systems with a
`sleep mode. And so this is one of the few cases that I've had the pleasure of
`arguing where even the titles tell us that they are the proper obviousness
`combinations to make.
`
`With respect to the '268 patent, the first element that I'd like to point
`to is the element in claim 2, maintaining synchronization. Now, obviously,
`when you have two things that are trying to talk to each other, and one of
`them goes to sleep, there's a need for people to be able to make sure that the
`two things that are supposed to talk are on the same page, to use a terrible
`colloquialism, but to make sure that people are speaking the same way, that
`you're still talking about the same things even though one of those elements
`has perhaps gone to sleep and may not be in the same place.
`
`Patent owner is trying to argue a definition of synchronization that we
`think is too narrow. Patent owner's proposed construction of maintaining a
`timing relationship between two transceivers by correcting errors or
`differences in the timing of the timing reference of the transceiver and the
`timing reference of the second transceiver is simply not supported by the
`specification of the patent. Nothing about the last segment -- the by
`
`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
`
`
`
`5
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`correcting errors or differences in the timing of the timing reference of the
`transceiver and the timing reference of a second transceiver -- finds any
`support in the specification whatsoever. In fact, when asked, and you
`already heard this once before, but when asked, the expert for patent
`admitted that that definition came up in response to prior art, not in response
`to what one of ordinary skill in the art would understand having read the
`patent or the patent specification.
`
`Patent owner himself actually admits that there are multiple types of
`synchronization that occur between transceivers, timing being one, clock
`synchronizations, and frame -- frame synchronization being another.
`Nothing in the '268 patent talks about these corrections that have to happen.
`It just says we're going to synchronize it, however that may be. And
`synchronization as used in the claims is broad enough to cover either timing
`or frame synchronization.
`
`Petitioner is relying on the Morelli reference for its general teaching
`that transceivers can maintain synchronization while in low power. The
`Morelli reference specifically talks about the notion of having data packets
`being sent over that include synchronization bits. The primary point of this is
`in Morelli, starting at the very bottom of column 8, line 66, going on to the
`top of column 9, where Morelli describes these data packets that are being
`transported during low power mode for the purpose of synchronization. The
`format of the data packet 45 will typically be governed by the system
`protocol as is conventional. The data packet 45 includes, in order, a sink
`field 46, including synchronizing bits for synchronizing the receiver 16.
`
`Morelli -- the whole point of Morelli was to talk about how you could
`use the transceivers in low power mode. These data packets are transferred
`
`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
`
`
`
`6
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`in the Morelli system during low power. If it turns out that the information
`is interesting enough to warrant the transmitter being woken, the transmitter
`wakes up, reads the synchronization, synchronizes between the two and goes
`on. It would be obvious to combine the teachings of Bowie with Morelli,
`because Bowie also is trying to figure out a way to reduce the power
`between -- in a multi-carrier system between two transceivers that are
`talking to each other.
`
`The argument that patent owner seems to be making is that Bowie
`wouldn't have the exact same packet synchronization that Morelli has. But
`petitioner is not proposing importing the exact data packet synchronization
`scheme from Morelli into Bowie's ADSL scheme. Instead, petitioner's
`argument is, and always has been, that one of ordinary skill in the art using
`Bowie and understanding that Bowie's entire teaching is to take two
`transceivers talking to each other and use low power mode in order to
`conserve power would understand that syncing information is still very
`important, and they would look to Morelli to realize that Morelli already
`taught how to maintain synchronization in that low power mode.
`
`Patent owner's argument seems to be a bodily incorporation argument.
`In other words, if you were to take the exact synchronization packet at 16
`hertz of Morelli and stick it immediately into Bowie, there might be a
`problem because the kilohertz may be exactly the same and they might keep
`waking each other up. But that's never been the argument at all. In fact,
`Bowie specifically points out in itself that Bowie can operate at any number
`of kilohertz. That's in Bowie at column 2, lines 44 to 47.
`
`So the argument that somehow Bowie teaches away from using
`Morelli or vice versa simply doesn't make sense and isn't supported by 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
`26
`
`
`
`7
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`record.
`
`JUDGE JEFFERSON: Counsel, before you move on, in reference to
`patent owner's proposed construction of maintaining synchronization, sort of
`a two-layered question. One, is maintaining synchronization as used in this
`case in the '268 patent the same as the synchronization timing that's just been
`discussed in the related case in the '404 patent?
`
`The disclosures are clearly continuations of each other, so they're
`related. But should they be construed consistently, and if, would you be --
`and this is the second part of the question -- would you be okay with the
`construction that used maintaining a timing relationship between two
`transceivers as being the construction of that term in maintaining
`synchronization.
`
`MS. KEEFE: So I'll take that in two parts, Your Honor. The first part
`is I actually don't believe that even that definition -- I think that definition is
`also too narrow because you have to be able -- synchronization should
`account for frame and timing, and there shouldn't be a timing only for a
`synchronization signal or a synchronization there, because that's simply not
`how the patent is read. The experts all agree that there are multiple types of
`synchronization. The word synchronization or means maintaining
`synchronization by itself is not limited in any way, and it can be a
`synchronization of the frames as opposed to synchronization of timing. And
`so I don't believe it should be that narrow. However, that being said, if
`Your Honors were to adopt that construction, we don't think that anyone has
`shown that synchronization of timing is not disclosed by Morelli in this
`instance, as we've put it out. In fact, Morelli doesn't describe, one way or
`the other, what type of synchronization it's limited to. It says maintaining
`
`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
`
`
`
`8
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`synchronization full stop, and therefore can be any type of synchronization.
`
`So long -- very long answer to a very short question. I don't believe it
`needs to be that narrow, Your Honor, but if you were to find and adopt that
`definition, Morelli still covers it absolutely because it doesn't distinguish
`between the types of synchronization that it has.
`
`In fact, just to wrap up the bow on that, our expert stated in his
`declaration that -- at paragraph 172 -- Morelli discloses a wireless
`communication system that provides synchronization bits in the low power
`mode. Those synchronizing bits perform the same function as the
`synchronizing frame and pilot carrier in the ADSL technology, and so it
`would be obvious to one of skill in the art to simply use those packets for the
`same reason, that they could be received in a system working like Bowie.
`
`Moving on, the only other argument they seem to have is that
`maintaining needs to be something continuous. The first thing I'd like to do
`is step back and simply talk about normal real life in terms of maintaining.
`
`If I maintain a friendship with someone, I don't have to see them every
`single day. I don't have to talk to them every day. I can maintain a
`friendship by reaching out periodically and making sure that we are in
`communication.
`
`Similarly if you maintain your lawn in front of your yard, you don't
`have to cut it every day, but once it gets to a point where it's a little too big,
`you need to go ahead and mow it so that it looks good.
`
`Here, maintaining synchronization, I believe, in the full broadest
`reasonableness of its interpretation means just that. Making sure that
`synchronization keeps happening, not that at every infinitum second of every
`millisecond synchronization happens; but instead, as you go along, you
`
`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
`
`
`
`9
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`make sure, within a few milliseconds, do I need to check myself? Do I need
`to come back? Is there a check that I need to do? Do I need to adjust my
`frequencies?
`
`And so synchronization can be maintained in periodic transmissions.
`The ADSL standard, the ANSI standard from 1995, strongly supports this,
`and the ADSL standard specifically says that synchronization of the
`corresponding transmitter and receiver super frame counters is maintained
`using the sync symbol in the ADSL frame structure. And as Your Honors
`know, that sync symbol in that structure comes along only once every I think
`it's 68 frames. And so that is a periodic framing that maintains
`synchronization.
`
`And so we believe that any argument that patent owner will make that
`somehow it can only be maintained by something like a pilot tone or a
`carrier signal is simply not supported by the record or the claim an ordinary,
`reasonable, broad interpretation of maintaining.
`
`JUDGE JEFFERSON: Counsel, before you move on then --
`
`MS. KEEFE: Please.
`
`JUDGE JEFFERSON: My understanding of patent owner's argument
`is that in the low power mode there is no synchronization going on and that
`every term of the receiver in this case corresponding with the -- with our
`base is that they are -- in burst mode they are then reinitializing or restarting
`the sync so that that gap period where they are in low power mode, there is
`so synchronization during that period.
`
`What is your understanding of that?
`
`MS. KEEFE: So my understanding of that, first off, is that there's no
`evidence that that's how Morelli operates. It doesn't say I give you a burst
`
`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
`
`
`
`10
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`and everybody falls out, and then I come back and everybody falls out.
`That's not what Morelli says at all.
`
`What Morelli simply says is that in low power mode data is being
`received in low power mode. And during that low power we are going to
`send data packets which include sync symbols which will be used for
`synchronization. It's that clear. I don't think there's anything that says that
`it's going to fall out and then have to reinitialize itself and start all the way
`over. In fact, what the sync symbol may indicate is that everybody's fine,
`and you are continuing in synchronization. So I think it's taking a worse
`case scenario far too far, and that's simply not what Morelli discloses. And I
`would point Your Honors back to the language at column 9 that says that the
`a data packet includes, in order, a synchronization field, including
`synchronizing bits for synchronizing a receiver. That's the whole point is to
`maintain synchronization of that receiver.
`
`Moving on to the next element. Claim 14 of the '268 provides for
`storing during the low power mode at least one parameter associated with
`the full power mode. Patent owner's construction, I'm not a hundred percent
`sure, to be totally honestly, that I understand what exactly they're trying to
`do with this construction. Patent owner proposes that the parameter be
`associated with the reception of data during normal operation.
`
`If what patent owner is trying to do is say that the parameter has to be
`transmission in and of itself or it has to be the reception of data, I don't think
`that's supported even by the normal language that we see on the screen in
`slide 10. The screen in slide 10, the language they are proposing is a
`parameter associated with the transmission and/or reception of data during
`normal operation.
`
`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
`
`
`
`11
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`While I still think that their proposed construction is too narrow, and I
`
`think that the plain meaning of the words "parameter associated" is enough,
`even under their proposed construction parameter associated with the
`transmission and/or reception data during normal operation, that is disclosed
`by Bowie.
`
`Even if you take the absolute tiniest, tiniest lens to Bowie to try to
`figure out what it discloses, Bowie absolutely discloses that there's
`information being transmitted about loop characteristics. Loop and stored.
`
`Loop characteristics at its tiniest lens, according to patent owner,
`seems to be things like length of wire, the metal, something physically about
`the wire itself. Even if Bowie was limited to this, which it is not,
`specifically in the bottom of column 5, Bowie talks about loop transmission
`characteristics, not the loop itself.
`
`But even if Bowie were limited to physical characteristics, a physical
`characteristic, having information stored about the physical characteristic
`would still be a parameter associated with transmission and/or reception of
`data during normal operation because information about that physical
`structure is associated with information that becomes transmitted along it,
`because we then know something about how that information is going to go
`along the circuit, whether or not noise is going to affect it more, whether the
`attenuation is going to be affected by virtue of the physical characteristics of
`the loop itself.
`
`However, Bowie is not so limited. Bowie specifically talks, at the
`bottom of column 5, about loop transmission characteristics. So this would
`be characteristics of the information being passed along the loop. And
`Bowie says the whole reason that I want to store this information before I go
`
`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
`
`
`
`12
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`into low power mode is so that when I come back to wake up, I've already
`got that information here. So I don't have to reinvent the loop as it were. I
`don't have to go all the way back to square 1 every time because I have some
`of that information stored. And certainly that's information associated with
`the transmission and/or reception of data during normal operation.
`
`Morelli also discloses the fact that -- sorry -- in the next -- the next
`characterization is that the receiver portion remains in full power mode
`while the transmitter enters the low power mode. That's the next step of the
`claim itself.
`
`Morelli discloses: Nevertheless, it's equally the position to have either
`the transmitter or the receiver be designed to enter a sleep mode, as
`described herein, while the other is always in an active mode.
`
`Morelli specifically discusses in excruciating detail how to turn either
`the transmitter off and then wake it back up, turn the receiver off, wake it
`back up, and then says and there might be times where they are both off
`except that the receiver always receives at least the ability to receive
`information to say hello, I'd like to talk to you and then concludes all of that
`discussion with a very specific rendering that there may be times while you
`want the receiver portion to be in full mode while the transmitter is in low
`mode.
`
`This embodiment is fully disclosed by Morelli's disclosure, which,
`again, separately discloses how to work with each of the transmitter and the
`receiver separately. And we point that out in slide 11 in figure 6A through
`figure 9 for the transceiver, and figures 3 through 5 for the receiver. I think I
`said that backwards. Transmitter for 6A and 9, and receiver for 3 through 5.
`
`The argument that patent owner seemed to be making is that single
`
`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
`
`
`
`13
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`sentence saying you can turn one all the way off while leaving the other on
`as not enabled, but that's simply not true if you read the entirety of the
`specification.
`
`Patent owner also has an argument that Bowie teaches away from
`keeping the receiver active during low power because Bowie is somehow
`supposed to be achieving maximum power saving. That's simply not
`supported by the Bowie disclosure. Bowie talks about conserving power.
`Bowie talks about being able to use less power than before, not use the least
`of amount of power possible or make sure that we have maximum power
`savings.
`
`The methods and apparatus for conserving power are specifically
`described in the abstract of Bowie and in column 5, lines 45 through 47.
`
`Even if would one were to argue you have to get at least as close as
`you can, it's unrebutted that a transmitter uses a hundred times the power of
`a receiver. And so having a system where you can turn the transmitter off,
`even while you leave the receiver on, would certainly be a massive savings
`of power, and therefore would satisfy even the notion of trying to save as
`much power as possible even by leaving the receiver on.
`
`Bowie in view of Morelli and the ADSL standard discloses receiving
`data during that low power mode. Morelli's receiver 16 is on to receive
`incoming packets while the transmitter 12 is off. And we show this through
`the quotes that we have from column 16 -- sorry column 15, lines 46 through
`52, and column 16, lines 29 through 34, which is on slide 14.
`
`When this popped out for me that it was actually true was when I was
`reading the second quote on the right-hand side of the slide: In the event the
`MAC 30 determines in block 108 that the packet being received is of 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
`26
`
`
`
`14
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`type that requires a response. However, the MAC 30 proceeds to block 12
`[sic]. At such time as the MAC 30 reaches block 112, the MAC provides a
`control signal to switch the transmitter from sleep to active mode.
`
`And that tells us that the transmitter has been asleep. So the receiver
`received those packets while the transmitter was off, because otherwise how
`would it know to tell the transmitter it was time to wake up. And so that
`column and that quotation there really knocked that one home for me.
`
`Bowie in view of Morelli and the ADSL standard also disclosed
`storing during the low power mode at least one parameter associated with
`the full power mode.
`
`Patent owner's argument regarding the type of data stored in Bowie is
`not commensurate with the scope the claim. The scope of the claim says any
`information, any parameter, that's associated with that full power mode.
`And as we've already discussed definitely Bowie has that even at its
`narrowest reading.
`
`Bowie in view of Morelli also discloses that the loop characteristics
`are specifically stored from the full power mode. We've already discussed
`that. And petitioner's expert declaration makes very clear that the
`parameters in Bowie are acquired during that handshaking, so during that
`initialization. That's the thing that you're going to want to store.
`
`Now, going on to -- we're going to have to talk a little bit later about
`how -- what type of things are going to be stored. Not just loop
`characteristics, when you put the combination together, are stored. In fact,
`Bowie says I am ADSL. I have ADSL components. Therefore, one of
`ordinary skill in the art would look to the ANSI reference to figure out what
`those ADSL components would use, what communications would they have.
`
`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
`
`
`
`15
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`Bowie says I want to store information that happens during the
`
`handshaking -- and I'm sorry -- for the record, I keep shaking my hands
`together -- but Bowie says I want to store information that occurred during
`the handshake so that when I wake up again, I don't have to go all the way
`back through the handshake.
`
`One of ordinary skill in the art reading Bowie would say, maybe if
`there are ADSL compliant pieces, I should go to ANSI standards to see what
`ADSL requires in its handshake to see if there's other information that I
`might want to store, including, for example, fine gain parameters, fit
`parameters, things that are in the handshaking portion of the ADSL
`reference.
`
`And so in fact, the combination of Bowie and the ADSL standard
`absolutely store, at a minimum, parameters associated with full power mode
`in terms of the handshaking because if one, reading Bowie, realized the
`exchange for the handshaking happens during full power mode, and I'm
`going to store information associated with that handshake before I go into
`low power mode so I can use it later, it makes the most sense to store as
`much information as possible. I'll look to the ANSI standards and take in all
`of the things that they have for handshaking in order to speed this up even
`further. And that's supported in paragraph 136 of our expert's declaration
`and referenced in our reply at page 20.
`
`Bowie does not require reinitialization. We've already talked a little
`bit about that today. One of the things I'd like to do is give a somewhat silly
`example. Initialization to me means initial time something is happening. It's
`when you start something. Like the word implies. Initial, initialization.
`
`If you were to meet someone for the very first time that you'd never
`
`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
`
`
`
`16
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`met before, politely, you would walk up to that person, stick out your hand,
`shake it, and say, "My name is Heidi. I'm from California. I'm a patent
`attorney. I happen to be in D.C. today." The person on the other end would
`say, "My name is Joe. I live in D.C. I've never met a patent attorney. I
`don't know what you do." That's the initialization.
`
`The next time I -- and I store in my mind that Joe is from D.C. and he
`doesn't like patent attorneys. The next time I see Joe, I have stored
`information about our initialization. I don't have to walk up and shake his
`hand and tell him I'm from California or that my name is Heidi. I don't have
`to ask him where he's from. I've stored that. I can simply walk up and say,
`"Hi Joe. How are the Redskins?" and not talk about the patents at all.
`
`It sounds farfetched from the example in the patent itself and yet,
`Your Honors, it's actually not. Reinitialization means exactly what it says,
`to start all the way over from scratch. The abstract of the patent itself, of the
`patent at issue, the abstract, the last sentence says: The full transmissions
`and reception capabilities of the transceiver are quickly restored when
`needed without requiring the full (and time consuming) initialization
`commonly needed to restore such transceivers to operation after inactivity.
`
`Bowie specifically --
`
`JUDGE CLEMENTS: Ms. Keefe, just a housekeeping note -- sorry to
`break your cadence, but we've hit 25 minutes.
`
`MS. KEEFE: That's fine, Your Honor. Thank you so much.
`Bowie specifically talks about storing that information so that we can
`
`get to things faster so that we don't have to redo things. The may and
`permissive language about when handshaking may be required -- for
`example, when temperature has changed, maybe we have a new device in
`
`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
`
`
`
`17
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`line -- is exactly the same type of handshaking even the '268 and the '404
`patents specifically contemplate doing. They contemplate reinitializing if
`the signals say the temperature's changed too much, we probably need to
`start over.
`
`Moving on quickly to the simple limits that are left in the '404 that we
`haven't covered yet, the '404 also requires a parameter associated with full
`power mode operation. That's absolutely disclosed in Bowie. Patent
`owner's construction of a parameter associated with transmission and/or
`operation, again, I think is a little bit too narrow, but is still met. So I'm not
`sure what they were intending with that. No construction is needed, though,
`because the claim language goes on to explain what those parameters are,
`and they are a fine game parameter and a fine option parameter.
`
`Synchronization signal, here we used the Van reference. And the Van
`reference specifically talks about the synchronization signal in low power
`mode of ADSL. And so it is exactly the signal that we need. Again, I think
`that the definition here is too narrow, but even if it were the signal of the
`Van reference is exactly the same as the signal in Bowie, which is itself
`ADSL compliant and could be either a pilot tone specifically disclosed in the
`Van reference or the sync frame, also specifically disclosed in the Van
`reference.
`
`Combining Bowie and ADSL is not the result of any hindsight.
`Bowie says: I am ADSL compliant; therefore, one of ordinary skill in the art
`would look to ADSL standards in order to determine how Bowie was
`functioning. This is at paragraph SRS 523.
`
`Patent owner's argument that there would be no value in storing fine
`gain and bit allocation because Bowie always reinitializes, finds absolutely
`
`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
`
`
`
`18
`
`

`

`Case IPR2016-01469 (Patent 9,094,268)
`Case IPR2016-01470 (Patent 8,611,404)
`
`no support in the record. And in fact, quite the contrary, Bowie says the
`more I store -- essentially Bowie implies, I should say, the more I store, the
`faster I'll be able to get up to speed. And that's why the combination would
`have you storing as much as

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