throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SAMSUNG ELECTRONICS CO., LTD.,
`Petitioner,
`
`v.
`
`HUAWEI TECHNOLOGIES CO., LTD.,
`Patent Owner.
`____________
`
`Case IPR2017-01487
`Patent 8,812,848 B2
`____________
`
`Record of Oral Hearing
`Held: September 26, 2018
`____________
`
`
`
`
`
`
`
`
`
`
`
`Before TREVOR M. JEFFERSON, MICHELLE N. WORMMEESTER, and
`JOHN F. HORVATH, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2017-01487
`Patent 8,812,848 B2
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`JARED W. NEWTON, ESQ.
`DEEPAR ACHARYA, ESQ.
`MARISSA DUCCA, ESQ.
`Quinn Emanuel Urquhart & Sullivan LLP
`1300 I Street, N.W., Suite 900
`Washington, D.C. 20005
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`
`MICHAEL R. FRANZINGER, ESQ.
`JEFFREY P. KUSHAN, ESQ.
`MATTHEW HOPKINS, ESQ.
`Sidley Austin
`One South Dearborn
`Chicago, Illinois 60603
`
`
`
`
`The above-entitled matter came on for hearing on Wednesday,
`
`September 26, 2018, commencing at 10 a.m., at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`2
`
`

`

`Case IPR2017-01487
`Patent 8,812,848 B2
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE JEFFERSON: Good morning. You can be seated. This is
`a trial in case Number IPR2017-01487. The patent is 8,812,848, and the
`Patent Owner is Huawei Technologies and the Petitioner in this case is
`Samsung. I'm Judge Jefferson, again, and with me are Judge Wormmeester
`and Judge Horvath remotely.
`At this time, counsel, let's introduce yourselves, please, at the
`lectern, with the Petitioner.
`MR. NEWTON: Good morning, Your Honors. Jared Newton
`from Quinn Emanuel Urquhart and Sullivan. With me today is Marissa
`Ducca from Quinn Emanuel, Deepa Acharya from Quinn Emanuel and
`Christopher Burrell from Samsung.
`JUDGE JEFFERSON: Thank you.
`And for the Patent Owner?
`MR. KUSHAN: Good morning, Your Honors. Jeff Kushan from
`Sidley Austin for the Patent Owner. With me is Mike Franzinger and Matt
`Hopkins. Mr. Franzinger will be doing the argument today.
`JUDGE JEFFERSON: Thank you, and welcome. Before we
`begin, we'll obviously remind the parties, this hearing is open to the public
`and a full transcript will be made part of the record. The trial order has
`informed everyone that you have 45 minutes per side. You may reserve
`rebuttal time for those issues for which you bear the burden.
`For the clarity of the transcript, as usual, both counsel in this case
`have done a good job of it, please refer to exhibit numbers and slide
`numbers. It makes the record cleaner and helps us follow along when we are
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`3
`
`

`

`Case IPR2017-01487
`Patent 8,812,848 B2
`
`reading later and more importantly helps Judge Horvath know exactly where
`you are, because he cannot see specifically the screen here.
`Demonstratives are clearly not evidence, so when it's clearly
`marked well at the bottom of the slides, it's always nice to see it. So let's
`keep -- let's go ahead and get started. We'll start with the Petitioner, and you
`can tell me how much time you want to reserve for rebuttal.
`MR. NEWTON: Your Honor, I'll use 30 minutes for my opening
`and I'll save 15 for rebuttal.
`JUDGE JEFFERSON: We'll set it up for 30, but you can
`obviously roll over a little bit and we'll let you know how much time you
`have left.
`MR. NEWTON: Okay, thank you.
`JUDGE JEFFERSON: Judge Horvath, can you hear us okay?
`JUDGE HORVATH: Yes, thank you.
`JUDGE JEFFERSON: All right, let's get started.
`MR. NEWTON: All right. So if we could go to slide 17 to start.
`So, Your Honors, today we're talking about the '848 patent, and yesterday
`we talked about the '166 patent where the mobile device is moving from an
`LTE network to a 3G network. Now for the '848 patent, we're going in the
`other direction. The mobile device is moving from a 3G network to an LTE
`network, and the '848 patent is about a security negotiation procedure that
`the mobile device performs when it accesses that LTE network from a 3G
`network.
`So here on slide 17, we have Claim 9 of the '848 patent, which is
`representative of the challenged claims, and this is an independent claim, it's
`a method claim, and this lays out the basics of the claimed invention. 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
`
`4
`
`

`

`Case IPR2017-01487
`Patent 8,812,848 B2
`
`first clause of Claim 9 explains that the -- the method is directed to a method
`for security capability negotiation, specifically in the context of where the
`mobile device is moving in idle mode from a non-LTE network, so, for
`example, a 3G network, to an LTE network.
`And then the bottom four classes, which we have kind of grouped
`together, that talks about the step-by-step procedure for negotiating that
`security capability. So we'll get into those steps in more detail.
`And as we mentioned in our reply brief, there really -- we don't
`think there's very much in dispute for the '848 patent. The security
`negotiation procedure and the steps in those bottom four classes, they are
`known in the prior art, they're taught in this TR 33.821 reference, and that's
`not in dispute.
`In this first clause, at the top, the idea of the mobile device moving
`in idle mode from a 3G network to an LTE network, that was known in the
`art, it's taught in the TS 23.401 reference, and that's not disputed either. The
`only real issue is whether a person of ordinary skill in the art would look to
`the initial attachment procedure and the TR 33.821 reference when -- to
`perform security authentication when the mobile device moves in idle mode
`from 3G to LTE, as taught in the 401 reference. And the evidence shows
`that a person of ordinary skill in the art absolutely would have looked to the
`initial attachment procedure, and there's a number of very good reasons for
`that.
`
`First, both of these references are talking about a situation where
`the mobile device is accessing an LTE network, and in that situation, it
`doesn't necessarily have a pre-existing relationship with the LTE network, so
`what it has to do is it has to establish new security. So the TS 23.401
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`reference recognizes that that security establishment is required, and TR
`33.821 teaches a very specific, very predictable procedure for establishing
`that security when accessing an LTE network for the first time.
`So with that as an overview, why don't we go to slide 6. Slide 6
`we have here, this is the background of the '848 patent, Exhibit 1001, at
`column 1, lines 55 through 61. And this is talking about what's in the art at
`the time, and as it mentions, within an LTE network, there is this established
`security negotiation procedure, and what that includes is this negotiation of
`NAS confidentiality protection algorithms and NAS integrity protect
`algorithms. And that's the -- in short, that's describing the exchange between
`the mobile device and the network when it's in an LTE network and when
`it's establishing this security capability negotiation.
`If we go to the next slide, this is slide 7, and this is now turning to
`how the patentee characterized the invention of the '848 patent, and what it
`says is that the inventor found that there's no similar negotiating security
`capability procedure in the specific context of heterogenous networks, and
`what that means is, the inventor found that, well, nobody has come up with
`or nobody has put together a security negotiation procedure for the specific
`scenario of the mobile device moving from 3G to LTE, even though it was
`already known in the context of LTE to LTE.
`We can go to slide 8. Slide 8 is Figure 1 of the patent, and this
`lays out the basic procedure for how the security negotiation works. At the
`top of Figure 1, there's three entities. You've got the UE, that's the mobile
`device; the MME, which we talked about a lot yesterday, that's the core
`network node of the LTE network; and then the SGSN, which is the core
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`network node of an old 3G network that the mobile device is coming from,
`so the 3G network.
`And in step 100, what happens is the UE kicks off this process by
`sending a TAU request, a tracking area update request or a TAU request, and
`part of what's included in that request is what the patent calls the UE security
`capabilities, and that's going to be a term that the parties have been -- that's
`in dispute, whether it would make sense for the UE to send those security
`capabilities as opposed to the MME getting them from the SGSN, but in step
`100, that's what the patent says, in at least this embodiment, is that the UE
`sends the security capabilities in the TAU request.
`I'll jump down to step 103, what the MME does, or the LTE
`network does is it looks at those capabilities and it selects a specific NAS
`security algorithm for the UE and the mobile device to use, sends it back to
`the UE in step 104, and then based on this algorithm that the network has
`preselected, the UE goes through these key derivation steps and it derives
`KASME, that's also referred to as a root key in the claims, and then a NAS
`protection key, which is also referred to in the claims. So these kind of two
`levels of these hierarchy of keys that the mobile device derives based on the
`algorithm that the network preselected.
`So now why don't we jump to slide 14. Briefly, these are the
`challenged claims. As I mentioned, there's method claims, there's also
`apparatus claims. This is claims 1 through 5. I'm sorry, yes, 1 through 5,
`and 7 and 8. If we go to the next slide, we have claims 9, 11 through 13, 15
`and 16, and then why don't we go to slide 17 again.
`And this is, as I mentioned at the start, this is method Claim 9, this
`is the one that we think is representative and we'll use to frame the parties'
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`dispute. And this slide provides an overview of how we are applying the
`prior art to the challenged claims. These two references, the TR reference
`and the TS reference, are in each of our proposed grounds, and this is the
`real issue here -- is whether there would have been a motivation to combine
`these references to get to the claimed invention.
`So why don't we talk about the TR reference, and we can go to
`slide 20. So the TR reference, as I mentioned, has all of these step-by-step
`security negotiations and key derivation steps that are required by the
`claims, and this is the key disclosure of the TR reference that we're relying
`on -- TR stands for technical report, as you can see in the title of the slide.
`And this is the key figure of the reference that we're relying on, it's
`at page 70 of the TR reference, and what this is showing is the procedure
`between the mobile device and the LTE network during initial attachment,
`and that's an important thing to remember is that this is describing the initial
`attachment procedure that's going to tie into the parties' disputes, but what it
`teaches is the exact same security negotiation procedure that's in the claims
`in this context of initial attachment to an LTE network.
`So why don't we go to the next slide, and I want to --
`JUDGE HORVATH: Counsel?
`MR. NEWTON: Yes?
`JUDGE HORVATH: During the initial attachment, does the LTE
`network know anything about what the UE's capabilities are?
`MR. NEWTON: No, it doesn't, in most cases. So initial
`attachment can be a situation where you are, for example, coming off an
`airplane, you turn your phone back on. In that case, there's not going to be
`that pre-existing relationship. There's at the very back end of the LTE
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`network, there is obviously, you know, kind of user information that the
`network is going to know about, but in terms of security negotiation, that
`starts from scratch.
`JUDGE HORVATH: Okay.
`MR. NEWTON: And so in this step 1 of the signaling diagram for
`initial attachment, we see that the UE sends this initial NAS or layer 3, L3
`here in the callout, message to the eNB, so to the base station of the LTE
`network. And the callout explains that the initial layer 3 message includes
`all UE security capabilities.
`So that is, Judge Horvath, to your question, that is a requirement
`for initial attachment that the UE sends its security capabilities, because
`we're establishing this relationship, this security between the mobile device
`and the LTE network. And going a little bit further, maybe reading into
`your question, there's two ways that the LTE network can get the security
`capabilities for the UE, it can get it from the UE itself or it can get it from
`some prior association.
`For example, if the mobile device was previously connected to
`another part of the LTE network and it's just moving from one part of the
`LTE network to another, but it's maintaining its connection, it still has a
`connection to the network. In that case, because we're not starting from
`scratch, it's possible that the LTE network could reach back to another MME
`and try to get those capabilities.
`Here in the initial attachment procedure, the UE, as we see in step
`1, transmits its security capabilities to the LTE network, and then in step 2,
`that initial NAS message, the initial layer 3 message, with the security
`capabilities, goes to the MME of the LTE network.
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`
`And go to the next slide, which is 22, and I'll just touch on these
`briefly. As I mentioned, you see the same step-by-step security negotiation
`procedure as is recited in the challenged claims. The MME, based on the
`UE security capabilities, selects the NAS algorithms for the mobile device.
`In step 4 it transmits those algorithms back to the mobile device.
`And then if we go to the next slide, 23, and actually why don't we
`just jump to 26, then the mobile device goes through this key derivation
`process, and it derives in the middle of this diagram, this is Exhibit 1004 at
`pages 52 through 53, in the middle of the diagram, you see the phone is
`deriving KASME, that's the root key, and then the two keys that are
`highlighted, the KNAS encryption key and the KNAS integrity key, and
`those are the NAS protection keys that are recited in the last clause of the
`claims.
`
`JUDGE HORVATH: I have a question. It seems to me, and
`maybe I'm wrong, but do the parties dispute what keys are derived from
`the -- what's called an AKA run? And I don't remember what AKA stands
`for, authentication and something, but was there a dispute between the
`parties as to whether or not certain keys were or were not derived in an AKA
`run, and if so, you know, what is your position as to what keys are derived
`and what is your best evidence for those keys being derived in an AKA run?
`MR. NEWTON: So I don't understand -- so an AKA run is
`authentication and key agreement. I don't understand there to be a dispute
`about specifically which keys are derived, at least in the initial attachment
`procedure. And if we can go back to slide 22, you see the AKA has that
`dashed line, and, you know, what that represents is that the following steps
`are going to be part of that AKA. And the keys that are derived, our best
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`evidence for which keys are derived, if we go to the next slide, this is -- go
`one more, if we --
`JUDGE HORVATH: If you could identify the slide number.
`MR. NEWTON: Right, so this is slide 24, and it's Exhibit 1004 at
`pages 52 through 53 and also this is discussed in the petition at pages 45
`through 48. And I'll also reference the petition at pages 13 through 16,
`which is where we have just a technical background discussion of the AKA
`procedure that establishes -- it's kind of step by step. So our best evidence
`are in those pages, also in this diagram and at these pages of Exhibit 1004,
`but that establishes this whole key hierarchy that is derived during the AKA
`run.
`
`Does that answer your question?
`JUDGE HORVATH: Yes.
`MR. NEWTON: So if we can go to slide 26, this is the same
`diagram, and as I mentioned, these last two highlighted keys are the claimed
`NAS protection keys that are recited in the last clause of the independent
`claims, and again, this just shows the hierarchy that's happening on the UE,
`and on the LTE network, that is doing these key derivation steps in parallel
`so that they have matching keys, and this hierarchy establishes that the --
`after the mobile device gets the preselected algorithms from the LTE
`network, it goes through this hierarchy and derives each of the keys that are
`recited in the claims.
`And then if we can go to slide 27, so just one point, and this goes
`to one of the parties' disputes. The TR reference talks about how that entire
`process is known in initial attachment, and it establishes it for initial
`attachment to the LTE network, and then in this section at page 75 of Exhibit
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`1004, Section 7.4.13.4.2, it says, "Idle mode mobility results in a location
`update procedure. The security algorithm selection upon location updates
`shall be performed in the same way as on initial attachment."
`So what this is teaching us is that we have this known security
`negotiation procedure in the context of initial attachment to the LTE
`network, and the same procedure should be used during idle mode mobility.
`And I mention --
`JUDGE HORVATH: What do you make of -- I mean, you know,
`Patent Owner argues and takes a different position on what this is teaching,
`right? And Patent Owner points to the fact that there actually is a TAU
`procedure in the LTE network. So when an MME moves from, you know,
`one, I guess, base station to another, or maybe even within a base station, I'm
`not sure, but it sends a tracking area update to let the base station know that
`it's moved. As part of that, it might get switched to a different MME. And
`so there is this procedure right in place in the LTE network where the TAU
`procedure can be run, and Patent Owner's, as I understand it, argument is all
`this is telling us is that when you're doing this TAU procedure, you shouldn't
`get the keys -- it doesn't tell you where to get the keys, it tells you how to
`select the algorithm to use. You know, why is that -- why is that argument
`wrong?
`
`MR. NEWTON: So why don't we go to slide 44 and I'll explain
`why that argument is wrong, and slide 44, just for context, this is the Patent
`Owner response at page 25, and this is where they lay out that argument that
`you just mentioned, Judge Horvath, and as you mention, they say that the
`context of the TR reference makes clear that the statement I just pointed to
`about initial attachment, the initial attachment procedure also being used 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
`
`12
`
`

`

`Case IPR2017-01487
`Patent 8,812,848 B2
`
`idle mode, refers only to the process of choosing the security algorithm, not
`to the manner in which UE's security capabilities are obtained. That's
`wrong.
`
`And if we go to the next slide, slide 45, we see that the way that
`TR uses the term "algorithm selection," it's talking not just about that one act
`of the MME selecting the algorithm, it's talking about the entire process,
`including the mobile device sending its UE security capabilities. And so
`what we've got here on slide 45 is a callout for algorithm selection at initial
`attachment, and then below that, algorithm selection on idle mode mobility.
`And then the first callout is very clear that part of that algorithm
`selection, that term, that phrase that the reference is using, is addressing how
`should the MME get the security capabilities. And at that highlighted
`passage at the bottom of the first callout, it says, "as a consequence, we've
`determined it seems most natural to assume that UE sends its capabilities to
`the MME in an initial layer 3 message."
`So that's the UE providing its security capabilities to the MME as
`part of this algorithm selection process. And then it uses, in the second
`callout, it uses the same language of algorithm selection when it's talking
`about idle mode mobility, and it says do it in the same way as on initial
`attachment.
`So we think Patent Owner is taking a very narrow view of the
`teaching of TR 33.821, but when you read this entire section in context, it's
`clear that it's talking about algorithm selection includes the first step of the
`UE transmitting its security capabilities to the MME.
`JUDGE HORVATH: I do have sort of an unrelated question, but
`just sort of to set a baseline. You know, we've been talking about these NAS
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`encryption algorithms and these keys, KNAS encryption and KNAS
`integrity keys. Were these keys used in a non-LTE network?
`MR. NEWTON: Yes. So I would refer you back to the petition at
`pages 13 through 16, because I think there may have been some differences
`in terminology, but this same basic hierarchy was used, and then when they
`updated it for the LTE network, as we see in the TR reference, that the
`terminology may have changed. So it's very similar, but I don't want to say
`it's identical. I can't answer that question just standing right here, but I
`believe we address that at pages 13 through 16 of our petition.
`Why don't we go to page 28 of the presentation. Just briefly to
`touch on the second reference that we're relying on, the TS 23.401 reference,
`we can go to -- why don't we go to slide 30.
`So slide 30, this has a callout from the TS 23.401 reference,
`Exhibit 1005, at pages 30 through 31, and this is talking about the tracking
`area update procedure that the mobile device uses when it's going from 3G
`to LTE. I just want to point out the bottom highlight here, this procedure is
`initiated by an idle state UE. So this is the same context as the challenged
`claims are talking about, idle state mobility from 3G to LTE.
`If we go to the next slide, slide 31, this is a signaling diagram that
`shows a little bit more about that procedure, and I just want to point out here
`that the UE changes from a 3G routing area RA to an LTE tracking area. It
`sends a tracking area update request, which is a NAS layer 3 message, and
`that goes to the MME.
`And then if we go to the next slide, 32, one thing that the TS
`23.401 reference makes clear is that after this tracking area update
`procedure, there is an authentication step, and if you look at step 5, 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 IPR2017-01487
`Patent 8,812,848 B2
`
`callout, it says that authentication functions and ciphering procedures are
`defined in this clause security function, and security functions may be
`executed.
`So this is recognizing that in this context, when the mobile device
`is moving in idle mode from 3G to LTE, there needs to be security
`authentication.
`JUDGE HORVATH: Is there any evidence in either this document
`or related documents as to what this security function is?
`MR. NEWTON: Not that we were able to find, Your Honor.
`So if we go to slide 33, I'll talk about what we see as the key
`dispute, which is why would a person of ordinary skill in the art, when
`they're in this context taught in the TS reference of a mobile device moving
`in idle mode from 3G to LTE, why would they look to the initial attachment
`procedure?
`So let's go to slide 34. This is testimony from our expert,
`Dr. Williams, paragraph 140 of Exhibit 1014, and what Dr. Williams is
`saying here is that both references are talking about we're accessing an LTE
`network, we're not starting out within an LTE network, but we're accessing it
`for the first time. And in the context of the TR reference, you're accessing it
`on initial attachment. In the context of the TS 23.401 reference, you're
`accessing it when you're coming from 3G, so coming from a different
`network.
`So when a person of skill in the art is faced with this question, you
`know, recognizing that the TS reference says we need to do security
`authentication, what are they going to look to? Well, they're going to look to
`established procedures, like the TR reference, that established security
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`authentication, security negotiation, when a mobile device is accessing LTE
`for the first time.
`So as a result, a person of ordinary skill in the art wouldn't have
`had to start from scratch. They can use this procedure that's already
`established for accessing an LTE network, and simply apply it when you're
`accessing the LTE network coming from 3G in idle mode.
`And, Judge Horvath, what you touched on as the parties' dispute is
`why would a person of skill in the art look at the initial attachment
`procedure as opposed to the LTE-to-LTE tracking area update procedure,
`and the answer is that, well, as TS 23.401 recognizes, you have to start from
`scratch. You're not necessarily when you're moving from 3G to LTE, you're
`not necessarily going to have this prior association with the network where
`the network can simply get UE security capabilities from the 3G network.
`So in that situation, you're going to look at procedures like the
`initial attachment where you're starting from scratch and you're going to
`follow those procedures.
`And if we can go to slide 39, this is Patent Owner's argument that
`these two procedures are significantly different and they rely extensively on
`testimony from their expert, Dr. Mandayam, to support that argument, but
`when Dr. Mandayam had his deposition taken -- we can go to the next slide,
`slide 40. Actually, why don't we go to 41.
`This is Exhibit 1029, Dr. Mandayam's deposition testimony. He
`supported the very argument we're making, which is the context of initial
`attachment and the context of idle mode mobility from 3G to LTE are very
`similar, and in both cases, you need to establish security. So we first asked
`them about initial attachment and we said, it has to establish security
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`association with the network, correct; the way that initial attachment
`procedure works, yes.
`And if we go to the next slide, then we pressed him on this issue,
`we said, so, is it your testimony that there are no situations in idle mode
`where security has not been established? And he said, no, that's not what I'm
`saying. And I'll paraphrase here, but you can see in the second highlight --
`or I'm sorry, the third highlight, he says, when you're in this specific
`situation of idle mode mobility from 3G to LTE, that's where you need to
`renegotiate security. So that's where you need to start from scratch.
`So this is testimony that directly supports our argument that when
`you're in this context of the claims, idle mode mobility from 3G to LTE,
`you're starting from scratch and you're going to look to similar context,
`which is exactly what the initial attachment procedure is.
`If we can go back to slide 35. I see I'm about at 30 minutes, so I'll
`just touch on a couple more points on motivation to combine.
`Slide 35, we have further testimony from our expert, Dr. Williams,
`this is paragraph 137, and he is explaining how this combination would be
`actually implemented, and it's a very predictable fit of putting the security
`negotiation procedure of TR 33.821 in the context of idle mode mobility
`from 3G to LTE.
`What he says is a person of skill in the art would have
`implemented this combination by using the TAU request message in TS
`23.401 to transport the UE security capabilities to the MME. This would
`have been a logical use of the TAU request message, because the UE must
`re-authenticate itself when it's leaving one tracking area and entering
`another.
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`
`And then down at the bottom, there would be nothing surprising or
`unexpected about this combination, because both the TAU procedure and TS
`23.401 and the security negotiation and key derivation procedures in TR
`33.821 are intended to be used in the context of idle mode mobility. That
`goes back to the earlier point that TR 33.821 specifically says, here's this
`procedure and initial attachment, and additionally, it should be used in idle
`mode mobility as well. So no surprising or unexpected results.
`And if we go to the next slide, Dr. Williams further explained, this
`is slide 36, paragraph 138 of Exhibit 1014, he said, in my opinion, a person
`of ordinary skill in the art would have recognized that in these same
`procedures, you're kicking them off in the same way by sending this initial
`NAS message from the mobile device to the LTE network.
`So that's another example of why they fit together and why, when
`you put them together, there's not going to be anything surprising or
`unexpected. You just, as TR -- as the TR reference teaches, you transmit the
`security capabilities to the LTE network in a NAS message, when you adapt
`that to idle mode mobility from 3G to LTE, you're using the exact same type
`of message.
`So in summary, there's very specific reasons why a person of
`ordinary skill in the art, when they're looking at this context of 3G to LTE
`mobility in idle mode, why they would look to the initial attachment
`procedure specifically, and use that exact same procedure to negotiate
`security.
`So unless there are any questions, I'll save the rest of my time for
`rebuttal.
`JUDGE HORVATH: I have no questions.
`
`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 IPR2017-01487
`Patent 8,812,848 B2
`
`
`JUDGE JEFFERSON: Thank you. You have 16 minutes in
`rebuttal time.
`MR. FRANZINGER: Good morning, Your Honors.
`JUDGE JEFFERSON: You may begin.
`MR. FRANZINGER: Thank you. As a preliminary matter, I
`noticed there was no discussion of the secondary considerations evidence in
`Petitioner's initial presentation. That's consistent with it being, I believe, our
`burden, so I would like to reserve 10 minutes to address that in rebuttal, if I
`may.
`
`JUDGE JEFFERSON: You may.
`MR. FRANZINGER: Thank you. When the Board had to decide
`whether to institute review of these claims, it did not have before it the
`evidence that the inventor proceeded contrary to the accepted wisdom in the
`field. That evidence is now in the record, and it shows that the claims are
`not obvious.
`The two main references both describe procedures for transitioning
`between one network and another in idle state. It is not correct, as Petitioner
`claimed, that the UE is staying within the same network when it transitions
`from LTE to LTE. It is transitioning between two networks there, and that's
`clear from Exhibit 1004, page 61, where it is introducing the procedure on
`an LTE-to-LTE idle mode transition. The first sentence says, "Idle mode
`mobility between different SAE/LTE networks results in a[n] MME
`change."
`So that's a two-network transition procedure, just like the
`3G-to-LTE procedure in the 23.401 reference.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11

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