`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`APPLE, INC. and
`SAMSUNG ELECTRONICS AMERICA, INC.,
`Petitioners,
`
`v.
`
`UNILOC LUXEMBOURG, S.A.,
`Patent Owner.
`
`__________
`
`Case IPR2018-002891
`Patent 8,872,646 B2
`__________
`
`Record of Oral Hearing
`Held: January 24, 2019
`__________
`
`
`Before JENNIFER S. BISK, CHARLES J. BOUDREAU, and
`GARTH D. BAER, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`1 Samsung Electronics America, Inc., which filed a petition in IPR2018-
`01383, has been joined as a party to this proceeding.
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`APPEARANCES:
`
`ON BEHALF OF PETITIONER APPLE, INC.:
`
`
`ANDREW S. EHMKE, ESQUIRE
`CALMANN J. CLEMENTS, ESQUIRE
`Haynes and Boone, LLP
`2323 Victory Avenue, Suite 700
`Dallas, Texas 75219
`
`
`--and--
`
`MARC M. BREVERMAN, ESQUIRE
`Apple Inc.
`One Apple Park Way, MS 169-2NYJ
`Cupertino, California 95014
`
`
`ON BEHALF OF PETITIONER SAMSUNG ELECTRONICS AMERICA,
`INC.:
`
`
`MICHAEL A. WOLFE, ESQUIRE
`Paul Hastings, LLP
`875 15th Street, NW
`Washington, D.C. 20005
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`BRETT MANGRUM, ESQUIRE
`Etheridge Law Group
`2600 East Southlake Boulevard
`Suite 120-324
`Southlake, Texas 76092
`
`
`
`
`The above-entitled matter came on for hearing on Thursday, January
`
`24, 2019, commencing at 2:00 p.m. at the U.S. Patent and Trademark Office,
`600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`P R O C E E D I N G S
`- - - - -
`
`
`(Proceedings begin at 2:00 p.m.)
`JUDGE BAER: Okay, good afternoon, everyone. We've got this
`afternoon our final hearing in IPR2018-00289. This is between Petitioner
`Apple and Patent Owner Uniloc. And we also join Samsung Electronics
`America in from IPR2018-01383 to this IPR.
`The patent number at issue in this case is 8872646. I'm Judge Baer,
`this is Judge Bisk. And joining us from California, remotely, is Judge
`Boudreau.
`Okay, with that, let's go ahead and get the parties' appearances, please.
`Who do we have from Petitioner Apple?
`MR. EHMKE: Your Honor, my name is Andy Ehmke with me is
`Calmann Clements and as representative of Apple is Marc Breverman.
`JUDGE BAER: Great, good afternoon, Counsel, thank you. And
`from Petitioner Samsung, do we have somebody here?
`MR. WOLFE: Michael Wolfe from Paul Hastings.
`JUDGE BAER: Thank you, Mr. Wolfe. Give me just a second
`here. And from Patent Owner Uniloc.
`MR. MANGRUM: Good afternoon, Your Honors, Brett Mangrum
`with the Etheridge Law Group, representing Uniloc 2018 -- 2017 LLC, the
`patent owner. And I will be presenting on behalf of the patent owner today.
`
`3
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`25
`
`JUDGE BAER: Great, thank you, Mr. Mangrum. Welcome,
`everybody, it's good to have you all here. And we certainly appreciate you
`making the effort to be here.
`We set forth the procedure for today's hearing in our trial order, but
`just to remind everybody of the way this will work, Apple and Uniloc will
`each have 20 minutes of total time to present their arguments.
`As we specified in our order granting joinder, as long as Apple
`remains in the case, Samsung will not be playing an active role. So we
`won't be hearing from Samsung during argument today.
`Please keep in mind that whatever's projected up on the screen there
`will not be viewable by Judge Boudreau, but he does have a copy of the
`material.
`So when you refer to an exhibit or a slide on the screen, please state
`for the record the exhibit number and the page number or the slide number
`to which you are referring. This will also be important so that our transcript
`is clear.
`Please remember also that if you step away from the microphone at
`the podium, Judge Boudreau might not be able to hear you. So if you
`would, when you speak, please stay close to the microphone.
`We'd like to remind each party that under no circumstances are they
`to interrupt the other party while they are presenting, while that other party
`is presenting its arguments and demonstratives.
`If a party believes that a demonstrative or an argument presented by
`the other party is objectionable for any reason at all, that objection may be
`raised only during the objecting party's argument time.
`
`4
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`25
`
`If a party wishes to raise an objection to a demonstrative or an
`argument presented by the final party to speak, it may request the
`opportunity to do so before we adjourn.
`All right with that, does Counsel for Petitioner have any question or
`concerns? Petitioner, sorry, Petitioner Apple have any questions or
`concerns?
`MR. EHMKE: No, Your Honor. Just we wanted to reserve five
`minutes of time when we speak.
`JUDGE BAER: Great, we'll do that. Counsel for Petitioner
`Samsung, any questions at this time?
`MR. WOLFE: No questions, Your Honor.
`JUDGE BAER: Great, and for Counsel for Patent Owner, any
`questions at this time?
`MR. MANGRUM: No questions.
`JUDGE BAER: Great. With that, we are ready to begin.
`Petitioner has the burden of proof, so you will go first. Mr. Ehmke, you
`said you wanted to reserve five minutes of rebuttal?
`MR. EHMKE: That is correct, Your Honor.
`JUDGE BAER: Great. And with that, you may begin.
`MR. EHMKE: Thank Your Honors.
`As mentioned, again, my name is Andy Ehmke of Haynes Boone
`here on behalf of Apple. We've gone through all the particulars of the
`decision already, so we'll just right into it.
`So we'll move to slide 2 of our slide deck. We played out the top
`three issues we think we want to discuss today. We'll focus almost entirely
`
`5
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`though on issues 2 and 3. We think those are the remaining issues to truly
`decide in this case.
`The issue of the claimed term glitch, its proper construction, and
`how the command prior reference teaches that limitation. And then that the
`McMahan reference would be probably combinable, with the references
`Pasolini and Goldman forming the basis of the primary rejection.
`So with that in hand, we'll actually skip through a number of the
`slides. They're there for reference in case we need them. We're going to
`move ahead straight to slide 10, where we'll deal directly with the glitch
`limitation. And then moving to slide 11, where we actually have the glitch
`limitation for review.
`We have highlighted there at the top verifying that the motion data
`includes one or more glitches, and removing the one or more glitches from
`the motion data.
`I'd like to highlight two aspects with respect to the claim overall.
`One is that we're going to be removing the glitches. And then there's a
`number of other steps that happened with respect to this.
`We've got determining an idle sample value and average
`decelerations, registering motions, waking up the devices, a number of other
`actions that happen with respect to this claim, above and beyond simply
`discerning that there is a glitch. So keep that in mind as we look at the
`claim and try to assess what the proper construction of the glitch would be.
`So the next step would be after we look at the claim would be look at
`the specification. Moving to slide 12 of the slide deck, we have some
`quotes here from the specification that we think are directly on point. With
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`6
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`respect to the claim construction of glitch, we've got this example here at the
`top, the first quote. A glitch is a datum that indicates a motion outside of an
`acceptable range.
`We've got another quote there in the middle. Data outside of the
`predetermined range of acceptable data. That is why we proposed in our
`petition that very straightforward proposed construction of a glitch includes
`a datum that is outside the acceptable range.
`JUDGE BAER: So the issue that's come up here obviously is
`whether it's outside of an acceptable range because the movement, the
`motion is outside an acceptable range, or it's outside an acceptable range
`because it's not really movement, it's some sort of error, right.
`And I'd like to talk to you a little bit about the top example you have
`there. That second sentence that says, For example, it's extremely unlikely
`that a device will go from idle to moving at acceleration of 64 feet per
`second squared, equivalent to 2gs.
`Why is that extremely unlikely?
`MR. EHMKE: It's extremely unlikely, Your Honor, because when
`we have, and we talk about this notion of motion data with respect to the
`glitch.
`
`And what we need to be looking at here is we're dealing with an
`accelerometer, which is just spitting out data, and data based on whatever it
`happens to be sensing. So it's sensing and pushing out this data.
`In this particular example, it's 64 feet per second squared, which
`doing the math is about 40 miles per hour. If we're going 64 feet per
`second, we've got this acceleration value.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`7
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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 so it's deemed unlikely because it's too much from the two
`periods of going from idle to extremely fast in terms of this acceleration.
`So it's extremely unlikely because it's too much motion.
`JUDGE BAER: Why is it too much, because humans don't move
`things at that speed? Or is it because a motion like that is unlikely to be
`somebody picking up a phone or doing something that would indicate a
`motion to wake up this device?
`MR. EHMKE: Well, and I think that's why the issue of glitch
`becomes relevant, because it's just about an acceptable range. And so as
`we're thinking about what a glitch would be, we've got this concept of an
`acceptable range.
`So it might be, if our device is a phone that's being picked up,
`perhaps 64 feet per second squared is too fast to be a legitimate actual
`motion that we would perceive as the human on the outside. It's still going
`to be a piece of data being spit out by the accelerometer as a motion data,
`because that's what it's setting out.
`But now we have the glitch-correcting logic disclosed in the
`specification that's assessing whether or not the output that data from the
`sensor is in fact something that we want to registering and then analyzing
`and passing along to rest of the system as motion data to assess what we
`should do with it.
`Again, that's the rest of the claim language, dealing with is it an idle
`sample value, are we going to accelerate it, should we weight the device
`based off that motion value.
`
`8
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`25
`
`So that's why we think, as we think about the glitch, I guess the other
`aspect to it here is these are some examples from the specification of what
`glitch would be. And we think that these examples would fall within the
`scope of glitch. There could be other things in terms of setting what the
`acceptable range might be, but we've got this notion of this should be within
`the scope of the construction of glitch.
`JUDGE BAER: Just to be clear what your position is, the patent
`describes two kinds of things we're going to filter out, right. One is a glitch,
`an error if you will, and two is a jostle or bump. Real movement, but
`movement that is outside the sort of movement that you want to use to wake
`up a device.
`Do I have that part correct?
`MR. EHMKE: I believe that's correct.
`I think the only thing that I might adjust on that is the notion of filter.
`I think in some certain circumstances, the jostle and bump is used and
`analyzed to assess whether to weight the device. It's not being removed
`from the data set.
`JUDGE BAER: But it's your position that the patent describes
`those two separate things separately, is that correct?
`MR. EHMKE: Yes.
`JUDGE BAER: And it's your position that a glitch is the first one
`of those things.
`It's the kind of thing you want to filter out because it's not real
`movement, it's some sort of error, some sort of problem. Is that correct?
`MR. EHMKE: We think that's one example of glitch, yes.
`
`9
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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 BAER: Would you call the other kind of filtering, in other
`words, the filtering from a jostle or bump, would you also call that a glitch?
`MR. EHMKE: I don't think I would necessarily call it a glitch. I'm
`not saying that it would be necessarily excluded, Your Honor. We think the
`specification would point to perhaps that the jostle and bump doesn't fit
`within the definition of glitch. But we're not saying here today that we
`think we need to definitely need to assess whether or not a glitch necessarily
`includes the jostles or bumps.
`What we are taking a position is that a glitch would include this
`anomalous data, something that's extremely unlikely with the other examples
`in the slide deck you've seen as well, of the malfunctioning problematic data.
`We think that would be within the scope of glitch, and that we don't need to
`fully assess whether or not the jostle or bump is the glitch.
`And the corollary to that, we don't think the jostle/bump analysis
`necessarily requires that the extremely unlikely type of data must fall outside
`the scope of glitch. I want to make sure that we're on our understanding on
`that, that the jostle/bump analysis doesn't require that extremely unlikely
`malfunctioning data must fall outside the scope of glitch. That the spec
`indicates that those should be within the scope of glitch.
`Does that answer your question, Your Honor?
`JUDGE BAER: That does, thank you.
`MR. EHMKE: Yes. So moving forward, and you've already
`touched on this already, Your Honor, to slide 13 are some of Patent Owner's
`arguments with respect to glitch that we've got here.
`
`10
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`25
`
`And the quote at the top, that the glitch is dealing with a range of
`motion that's accurately determined. That's the first sort of additional
`limitation being brought in here, accurately determined. And then doesn't
`warrant waking the device.
`And the support for that is the statement of every example deals with
`actual motion in the specification. When we look at the specification with
`respect to Patent Owner's arguments, we see that it doesn't comport with this
`and actually is the opposite of it. We've got these examples on slide 14.
`JUDGE BAER: I hear you on the examples that are contrary.
`What about the example that, from column 3, line 23 of the specification.
`Doesn't that comport with Patent Owner's construction?
`That's the one that says, talks about, for example, if the device is not
`being used but is in a moving vehicle, in one embodiment, the vehicle's
`motion can be discarded as not fitting the signature of human motion. And
`that's under the discussion of glitch-correcting logic.
`MR. EHMKE: We still -- you still have data that's outside and
`acceptable range with that example, Your Honor.
`JUDGE BAER: But it is actual real motion data in that case, right?
`It's a car moving.
`MR. EHMKE: Sure.
`JUDGE BAER: So is it your position that a glitch includes actual
`motion data?
`MR. EHMKE: Again, where our position is, is that the -- you can
`go back a slide. Our position is that with this accurately determined
`limitation being added, it's excluding all of the disclosures in the
`
`11
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`specification with respect to glitches being malfunctions and abnormal,
`extremely unlikely data. And we're saying that it shouldn't be so limited to
`exclude those embodiments.
`We aren't requiring, as part of our construction of the data outside an
`acceptable range, to necessarily exclude motions that would fit within
`whatever would happen to be an acceptable range that could be actual data
`detected by the accelerometer, and then further processing happened.
`We're not saying that that's necessarily excluded. What we want to
`make sure is that those embodiments don't exclude the other embodiments
`disclosed specifically with respect to glitch of extremely unlikely
`malfunction.
`All right, so it's not a problem that you have actual motion that's too
`much and it's being excluded. We think that still fits within the definition
`that we're proposing of motion outside of acceptable range. But we think
`it's improper isn't necessarily a requirement that in order to be a glitch, all
`data must be accurately determined. This spec is very on point that that's
`not the true extent of glitch.
`JUDGE BOUDREAU: So do you have an actual construction then
`for glitch? Or are you just saying that glitch should be defined in terms of
`something that it includes, it doesn't necessarily exclude something else?
`MR. EHMKE: You have that correct, Your Honor. We're not
`proposing a full expanse of metes and bounds definition of glitch. We're
`only seeking to construe it as necessary to resolve a dispute following the
`case law set forth by the Fed. Circuit. You don't have to necessarily hit 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
`
`12
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`metes and bounds. You just need to, quote, only to the extent necessary to
`resolve the controversy.
`And we think this proposed definition of glitch including a data
`outside an acceptable range is sufficient to resolve this controversy.
`JUDGE BOUDREAU: Thank you.
`MR. EHMKE: So continuing on the point that we don't think the
`accurately determined is a proper limitation to be applied to the glitch, we
`have our examples here, where we see in each of these scenarios it's the
`exact opposite of accurately determined.
`We see its data that's extremely unlikely. We see its data that's
`malfunctioning. It's abnormal data that we need to remove before we pass
`it to the long average logic.
`And I'm sorry, Judge Boudreau, we're on slide 14 and the examples
`we have on slide 14.
`We're also looking at removing items that are possible problems.
`Again, these are not actual accurate motions, these are error values,
`anomalous values coming in within the scope of glitch and being
`subsequently removed so they don't foul up the rest of the analysis and logic.
`That is why we don't think the accurately determined limitation is
`appropriate, because it would remove all of these examples that are
`specifically delineated as being embodiments of the glitch claim term.
`Contrast, we've discussed the jostle and bump. We've got this slide
`here. We see from the specification, we're on slide 15, Your Honor, that the
`jostle/bump analysis doesn't reference glitch here at all. It's much farther in
`the process.
`
`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
`
`13
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`
`Here, we actually now have data and we're going to assess what to
`do with the data. As opposed to all the other examples of glitch, which deal
`with the malfunctioning problematic data that's being removed and taken out
`of the equation.
`Going to slide 16, just repeating this issue here. Glitches are
`removed, there's an example from the specification here on slide 16. And
`we're looking for excessive number of glitches, even giving alert if we have
`too many glitches. Again, the whole point of this is that we have the glitch-
`correcting logic that discards this unacceptable motion data. And we want
`it out of the system before we pass it along and use it to do with further
`analysis.
`JUDGE BAER: And just to make sure I have it clear, your position
`is it's unacceptable motion data not because it's unacceptable motion,
`because it's not really a motion.
`Isn't that the point? It's some sort of error that's not really a motion.
`Do I have your position correct?
`MR. EHMKE: And I would keep -- yes, you have the position
`correct. But we're not saying that that's the necessarily finite scope of
`glitch.
`
`JUDGE BAER: But it would certainly -- a glitch would include
`something that is an error that's not real motion. It doesn't reflect real
`motion, it reflects an error. That's why, for example, you might think that
`there's a malfunctioning accelerometer, because it's giving you a number that
`doesn't reflect real motion.
`
`14
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`25
`
`MR. EHMKE: Right. But I would still say, just to make sure we
`clarify on that point, I would still say that even though from an omniscient
`viewpoint of looking at the device that contains the accelerometer, we might
`assess that it didn't move, and therefore it's bad data, within the confines of
`the device and accelerometer, it is spitting out motion data.
`Even though there's not, again, from the omniscient viewpoint of
`actual motion occurring, there is still motion data that the glitch-correcting
`logic looks at and says hmm, I don't that's accurate, I think that's unlikely to
`probably to malfunction. It's still motion data, it's just being discarded
`because it's erroneous when you apply the glitch-correcting logic to it.
`So we'll go to slide 17, where we sort of summarize our point on
`this, Your Honor. We have the claim language, which was very clear about
`verifying and removing the glitches. We got the corresponding
`specification, which talks about the acceptable range. And then again, the
`proposed construction of glitch of data that's outside an acceptable range.
`And with that construction in hand as we look at the McMahan prior
`reference, we see it teaches precisely that.
`On slide 18, we've got the example from McMahan where it's
`receiving data from a sensor. It's checking to see if the data is within our
`range that's expected. And if not, it's being removed by modifying it,
`replacing it with a new value.
`On the right-hand side, we've got highlighted the corresponding
`language that Froley (phonetic) discusses. This technique of we're looking
`for anomalous output, it's not within an expected range. It's presumed to be
`an error, it's not an accurate reflection of the stimulus, and so we want to
`
`15
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`replace it and remove and then insert a new value that is within the range.
`The glitch is identified and removed.
`We think McMahan teaches the claim language, and it's the exact
`same disclosure as the glitch removal process disclosed in the specification
`of the patent itself.
`JUDGE BAER: Okay, you're through your 15 minutes. Would you
`like to reserve the rest of your time?
`MR. EHMKE: Yes.
`JUDGE BAER: We'll go ahead and hear from Patent Owner. Mr.
`Mangrum, you have 20 minutes. Whenever you're ready.
`MR. MANGRUM: For the sake of efficiency given the time, I
`think I'm just going to refer to the slides by number and not try to sync up
`the display, if that's fine with Your Honors.
`JUDGE BAER: Sure.
`MR. MANGRUM: All right. I'm going to start on slide 2, which
`shows Independent Claim 1. Exercise 2, 3, and 4 reproduce the claims.
`And just want to emphasize a couple points as an overview.
`The glitch's claim term is a construct of the patent and must be
`understood in light of the specification. And as Uniloc explained in its
`briefing and summarized in these demonstratives, the 646 patent is directed
`to measuring a device's motion data over time to determine when to wake up
`the device from an idle state to an active state. That's the point.
`And to that end, the device samples motion data over time while it is
`in an idle state. A change in measured motion is compared to rolling
`averages to determine whether the change fits the signature of human motion
`
`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
`
`16
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`indicative of a user preparing to interface with the device, such as a device
`that's at rest on a table gets lifted up to the user's face.
`That type of motion that the system could detect and analyze with
`respect to historical data, that must be motion-indicative of somebody who's
`going to use the device.
`JUDGE BAER: Well, I certainly don't disagree with you that this
`patent, that the specification discloses that. But the specification also
`discloses, does it not, errors, and errors of the type that are from the device
`malfunctioning? In other words, errors that are not real motion.
`So, I'm looking, for example, the Petitioner Apple points to the
`example column 3, line 35 to 37. The glitches are generally indicative that
`the accelerometer or sensor is malfunctioning.
`What do you do with that example? Doesn't that indicate that a
`glitch isn't actually just limited to real motion? It may be the accelerometer
`malfunctioning, not a jostle or a bump?
`MR. MANGRUM: We think if you read that disclosure and related
`disclosures in their full context actually supports our construction, and here's
`why.
`
`Now, there is, I want to emphasize, in your question there was, you
`mentioned error and my opposing counsel mentioned accuracy. Those
`terms don't appear in the patent. Accuracy in any form of the word does not
`appear in the patent. It's not a concern of the patent, nor is error.
`When this is -- when it talks about malfunctioning, you have to read
`the full context of that paragraph. And what it's talking about is you get
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`17
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`values where over time the system's registering and removing an excessive
`number of glitches.
`So this determination can't be made on a single, solitary piece of
`information. It's not, nowhere in the specification does it say you could
`take a value, oh, and it's outside the operational range of the sensor, and
`therefore that value must be in error. That does not appear in the patent.
`There is no statement, and not on the record at any point did
`Petitioner point to any statement in the patent that says you look at one piece
`of information, and I know now looking at that information, because it's
`outside the operational range of the sensor, it must be in error. Doesn't
`exist. There is no description glitch in the patent that fits that description.
`What we do have in this example that you quoted and in a related
`example that talks about an excessive number glitches, so in these instances
`what you need is a collection of data. You need to keep over time, and in a
`specific time frame, how many glitches are you reading.
`So that does not necessarily mean that the device is malfunctioning.
`That's why it says potential. It doesn't say the device is malfunctioning.
`What you could have, for example, someone's traveling in a Jeep, right, and
`their phone is in a Jeep and a purse in Jeep or just happens to be
`experiencing an abnormal amount of jostling, right.
`Those could be pretty significant g-forces because the device is
`moving a short distance, but very rapidly, right. But those are -- the system
`is smart enough to say based off historical data, when I see this little blip,
`I'm not going to add that into the rolling average.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`18
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`
`I'm going to remove that from the data and keep assuming the device
`is at a constant state. And this is how the device behaves, this is the motion
`that's the baseline.
`JUDGE BAER: But the device isn't malfunctioning in that
`example, it's just in a Jeep, as you said. Why would we characterize, why
`would the patent, why would the specification characterize that as the device
`malfunctioning?
`So, for example, you've got a device, like you said, in a Jeep. And
`it's bouncing up and down, so we've got a large number of what you would
`call glitches. And it says, well, if we've got too many of those, the glitches
`are generally indicative that the accelerometer or sensor is malfunctioning.
`Why is it malfunctioning there? Isn't it functioning exactly like it's
`supposed to?
`MR. MANGRUM: Well, the system doesn't know, right. It doesn't
`have the context of where the device is at. So that's why there is a way, it's
`like, it's a failsafe. It's a way for the system to check itself.
`I want to point Your Honors to a related passage that I think helps
`clarify here. It's also cited only in Petitioner's reply. Both these passages,
`by the way, we didn't have a chance to address and address our argument
`because these were cited for the first time in the reply.
`But citing column 6, line 61 and 62, it says, an excessive number of
`glitches may indicate a problem with the accelerometer. So here, again,
`what we have is a disclosure that when you have an excessive number of
`glitches over a short time period, it may indicate a problem. If it is a
`
`19
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 B2
`
`problem, if it necessarily is a problem, you wouldn't have this qualifying
`language.
`So when you read the patent as a whole, when it talks about counting
`glitches over time and checking this, and maybe that might indicate a
`problem, that's very different than what you have in McMahan. Where in
`McMahan, you know immediately that a device is in error because it
`provides a value that the sensor's not even configured to measure. It knows
`immediately that is an error.
`And actually, Judge Baer, you asked about the 2g example in the
`specification and asked whether or not that was a malfunctioning. It doesn't
`say 2gs in error, it just says given the historical data, it measured 2gs. It's
`called a measurement. But given the historical data, it's unlikely the device
`went from its resting state to 2g. So it doesn't say that that is an error or a
`malfunction. It just says it's unlikely that were to happen.
`Now, if you apply the McMahan scheme, that would not be a glitch,
`right, because it's within the operational range of the sensor. So McMahan
`would say no glitch, keep it in. But the patent says it is a glitch and
`therefore remove it.
`JUDGE BISK: I'm confused because wouldn't the patent also
`include errors, though, as a glitch?
`I'm not saying that everything out of range is an error. But wouldn't
`-- if the -- in the patent, if it got a number that happened to be an error, that
`would be counted as a glitch. Because as you said, it doesn't know whether
`it's actually a glitch or not.
`MR. MANGRUM: Right, that's why --
`
`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
`
`20
`
`
`
`Case IPR2018-00289
`Patent 8,872,646 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
`25
`
`JUDGE BISK: So it includes errors, so why wouldn't it include the
`errors of McMahan?
`MR. MANGRUM: Well, because there is no instance, and again,
`this is an important point, there is no instance where the patent says this is a
`value that's outside of the operational range of the sensor. It doesn't say 2g
`can't be measured, it just says 2g's not likely. There's an assumption that 2g
`is the measurement, but it's just not likely given the circumstances.
`So the, my point is what you don't have in the spec and what you
`don't have anywhere in the record is a pinpoint in the patent that says this
`value cannot be measured by the sensor and therefore is a glitch.
`JUDGE BAER: But it does say that if you get repeated glitches, it's
`an indication that the device, the accelerometer, is malfunctioning, c
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
