Trials@uspto.gov
`571-272-7822
`
`
`Paper No. 36
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`____________
`
`Record of Oral Hearing
`Held: June 25, 2020
`____________
`
`Before KAMRAN JIVANI, JOHN D. HAMANN, and
`STACY B. MARGOLIES, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`Paper No. 36
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`MPH TECHNOLOGIES OY,
`Patent Owner.
`____________
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`____________
`
`Record of Oral Hearing
`Held: June 25, 2020
`____________
`
`Before KAMRAN JIVANI, JOHN D. HAMANN, and
`STACY B. MARGOLIES, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`MICHAEL D. SPECHT, ESQUIRE
`DANIEL S. BLOCK, ESQUIRE
`TIMOTHY L. TANG, ESQUIRE
`Sterne Kessler Goldstein Fox
`1100 New York Avenue, NW.
`Washington, D.C. 20005
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`JAMES T. CARMICHAEL, ESQUIRE
`STEPHEN T. SCHREINER, ESQUIRE
`Carmichael IP Law, PLLC
`8000 Towers Crescent Drive, 13th Floor
`Tysons Corner, Virginia 22182
`
`
`
`The above-entitled matter came on for hearing on Thursday, June 25, 2020,
`commencing at 9:30 a.m. EDT, by video/by telephone.
`
`
`
`
`
`
`
`2
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE HAMANN: Good morning. I’m Judge Hamann. On the panel
`today also are Judges Jivani and Margolies. This is a consolidated oral
`hearing for Apple, Inc. v. MPH Technologies Oy, IPR 2019-00819 and IPR
`2019-00820.
`I’d like to begin by having Petitioner introduce who is here today on
`his behalf.
`MR. BLOCK: May it please the Board, my name is Daniel Block
`from the law firm of Sterne Kessler Goldstein and Fox speaking today on
`behalf of Petitioner Apple. With me today is lead counsel Michael Specht
`and co-counsel Tim Tang, also both from Sterne Kessler.
`JUDGE HAMANN: Counsel, I think you cut out at the end. If you
`could, I heard Mr. Specht. Mr. Block?
`Mr. Block? It seems we’re having some technical difficulties.
`Let’s --
`MR. ROGERS: No, he’s still on, Judge. It looks like you muted his
`microphone.
`JUDGE HAMANN: Okay, thank you. Well, then if we could, let’s --
`if Patent Owner could please introduce who is on the line today on its behalf.
`I think you may need to --
`MR. ROGERS: Yeah, his mic is also muted. Hold on. Let me send
`them an email.
`MR. BLOCK: Your Honor, is this -- this is Mr. Block. Can you hear
`
`me?
`
`
`
`3
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`JUDGE HAMANN: Yes, let’s start this back with you, Mr. Block.
`Forgive me. I heard Mr. -- yourself and Mr. Specht, and then the last
`statement I did not hear.
`MR. BLOCK: Yes. Apologies. I’m not sure what happened there.
`Yes, so lead counsel Mr. Specht. Also with me today is Tim Tang, also
`from Sterne Kessler.
`JUDGE HAMANN: Okay.
`MR. BLOCK: I will be doing the bulk of the argument today and
`then Mr. Tang will be doing a portion of the argument.
`JUDGE HAMANN: Okay, thank you. And for Patent Owner, if
`Patent Owner could please introduce who is on the for its behalf today.
`MR. SCHREINER: Good morning, Your Honor. My name’s
`Stephen Schreiner. I’m here on behalf of Patent Owner, MPH Technologies.
`And I’m joined in person by my colleague Jim Carmichael.
`JUDGE HAMANN: Good morning to everyone. Let me start off
`since we’ve already had some technical challenges, if we could all endeavor
`to try to mute ourselves when we are not speaking, and then, of course, make
`certain that we unmute ourselves when we begin to speak again.
`Also, we need to, to the extent, demonstratives being referred to, you
`should certainly each time identify it by number, so that will help the record
`as well as us follow it along today.
`Now, per the oral hearing order, each side has 75 minutes in total for
`their arguments and any rebuttal or sur-rebuttal. In addition, Petitioner,
`Mr. Tang is a LEAP practitioner and 15 additional minutes have been
`allotted for 90 minutes to Petitioner.
`
`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
`
`
`
`4
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`I also want to let you know that there were requests for the public to
`participate via a dial-in number, so they may also be listening in.
`So, with that, let me begin. Petitioner bears the burden on
`patentability, so Petitioner will begin his arguments. Patent Owner will then
`respond. To the extent that Petitioner has reserved time for rebuttal, that
`rebuttal would occur. And then Patent Owner will conclude with a
`surrebuttal.
`So, with that being said, let’s begin with Petitioner, please.
`MR. BLOCK: Thank you, Your Honor. Good morning.
`JUDGE HAMANN: Good morning.
`MR. BLOCK: May it please the Board --
`JUDGE HAMANN: Yes. And if you could identify, I’m sorry, how
`much rebuttal time you want to reserve.
`MR. BLOCK: Absolutely, Your Honor. I was just getting to that.
`So, first of all, may it please the Board, what I’d like to reserve is 30 minutes
`for rebuttal time.
`JUDGE HAMANN: Thank you.
`MR. BLOCK: So, as I mentioned --
`JUDGE HAMANN: Okay, we’ll --
`MR. BLOCK: Go ahead.
`JUDGE HAMANN: Yeah, we’ll try to, you know, give you a
`warning before the end of your 60 minutes during your initial presentation,
`but, you know, please, to the extent you can track your time yourself, that
`would be helpful.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`5
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`MR. BLOCK: Absolutely, Your Honor. So, first of all, as I
`mentioned earlier, my name is Daniel Block. I’m speaking today on behalf
`of Petitioner, Apple.
`And, Your Honors, the Board should find unpatentable all claims of
`the 810 and 581 patents. As I will --
`JUDGE JIVANI: Mr. Block, I’m sorry to pause you for just a
`moment before you begin into the substance, but I did hear you mention that
`your lead co-counsel, Mr. Tang, will take a portion of the argument? We are
`interested to know approximately how much. As you know, our LEAP
`program is intended to allow substantive and meaningful engagement in oral
`argument.
`MR. BLOCK: Yes, Your Honor. And so the argument that Mr. Tang
`is going to be handling is the argument related to the security flaw new
`argument. And so I would expect that Mr. Tang’s argument will take -- you
`know, opening argument will take maybe around 10 minutes or so and then I
`(inaudible; audio disruption) on rebuttal, but (inaudible; audio disruption). I
`just -- you know, just on the outset, I know we have quite a bit of time today
`and I think our plan is to, hopefully, not use all of it, but I would imagine if
`Mr. Tang needs more time, he’ll be able to use some of the 75 minutes that
`were originally slotted.
`JUDGE JIVANI: Very good. Please proceed.
`MR. BLOCK: So, Your Honors, as I was saying, the Board should
`find unpatentable all claims of the 810 and 581 patents. As I will explain in
`more detail today, the core alleged that the concept of these claims, which is
`plainly disclosed by the primary reference Ishiyama, and the remaining
`
`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
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`elements of the claims, they’re just conventional elements and conventional
`arrangements of devices that were well-known to persons of ordinary skill in
`the art long before extensions of or alleged extensions of the 810 and 518
`patents.
`What MPH does here today, with the exception of a brand-new
`argument raised in the sur-reply that I just referred to, they really just raise
`the same arguments that they raised in their preliminary Patent Owner
`response. What MPH does is they argue against the reference Ishiyama
`individually instead of the combinations. But, Your Honors, as recognized
`in the institution decision, this is a case of obviousness. And what MPH
`should have done is argued against the combination, which is not what they
`did.
`
`So, Your Honors, just what you did in the institution decision, we
`would ask that you reject MPH’s argument and find all claims of the 581
`and 810 patents unpatentable.
`So, with that, what I’d like to do is turn to slide 3 of Petitioner’s
`slides. And here we have a quick agenda of what we’re going to go over
`today. And so, first, what I’ll talk about is just briefly what the 810 patent
`and 581 patent are about. Then we’ll talk about the combination of
`Ishiyama and Murakawa. And then we’ll get into the disputed issues
`between the parties. And as I mentioned earlier, Mr. Tang will handle that
`last argument about MPH’s new security flaw argument being improper.
`So, if we can turn to slide 5, and that shows the claim of the 810
`patent, which, of course, is a good place to start with the claims. And what
`we have on this slide is we’ve broken claim 1 of the 810 into elements. And
`
`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
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`on the left-hand side we have a figure from the 810 patent showing the
`general architecture. And the important thing to see here with respect to the
`claims is that there’s three devices that are talked about in the claims, three
`devices in this figure: a mobile terminal, a security gateway, and another
`terminal. The mobile terminal is in communication with the security
`gateway via what’s called an IPSec tunnel.
`An IPSec tunnel is -- it’s most commonly implemented in VPNs. It’s
`an encrypted communications channel. And if Your Honors have used
`VPNs, especially 5 or 10 years ago, it’s almost certain that they’ve used
`IPSec technology. And precisely, that’s the architecture that’s shown here.
`It’s a VPN architecture, which is the mobile terminal communicates with the
`security gateway via this IPSec tunnel. It protects (phonetic) packets over
`that tunnel, which will ultimately end up with the other terminal that allows
`the mobile terminal to communicate with internal networks just like a VPN.
`If we turn to slide 6, here we have the same claim, but we’ve done is
`we’ve broken down the steps in more simple wording on the left-hand side.
`I’m just going to briefly go through what the claim requires and then I’ll talk
`about what the differences are between the 581 and the 810 patent.
`As you can see, on the left-hand side, the first step corresponds to
`element 1A. All you’re doing there is you’re creating a secure connection
`between the mobile terminal and the security gateway, which, again, is what
`we just showed you in that previous figure.
`In step 2, what’s going to happen here is the mobile computer is going
`to change addresses. And so, this is really what the 810 and 581 patents are
`primarily concerned with. When the mobile computer changes addresses,
`
`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
`
`
`
`8
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`according to these patents, that causes some issues with IPSec and that’s
`what the alleged problem is that they’re trying to solve. The issue with that,
`of course, is that that problem was a well-known problem at the time. And
`that was solved in the exact same way by Ishiyama. And so, again, step 2,
`the mobile computer changes addresses.
`In step 3, what’s going to happen is when the mobile computer
`changes addresses it’s got to send a request message to the security gateway,
`notifying it of this new address. Step 4, security gateway is going to see that
`new address and it’s going to update what’s referred to as a security
`definition -- I’m sorry, a definition of the secure connection. That will, in
`step 5, allow the mobile computer to now communicate over that same
`connection using the new address.
`Step 6 isn’t so much a step as much as it is a limitation. What that
`says is that the secure connection needs to be IPSec and that the request
`and/or reply message need to be encrypted and/or authenticated. So, that’s
`the 810 patent in a nutshell.
`If we turn to slide 8, here we have the comparison between the claims
`of the 810 and the 581 patents. I think the important thing to know here is
`that the claims are very similar between these patents. It’s Apple’s position
`that if Your Honors find all the claims of the 810 patent unpatentable, that
`would necessarily mean that the claims of the 581 patent are unpatentable.
`The reason for that is shown here in on this demonstrative slide 8. There’s
`very little differences between the claims. As you can see, there’s some
`minor differences in element 1A. There’s just different words, but they
`mean the same thing.
`
`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
`
`
`
`9
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`And the only other difference is that in -- there is no 1F element in
`581, so there’s no requirement that the secure connection be IPSec or that
`the requester reply messages are encrypted or authenticated. So, the 581
`patent is slightly broader, which is why I said earlier that it’s our position
`that if the 810 patent claims are unpatentable so, too, are the 581 patent
`claims.
`So, that is the 810 and 581 patents in a nutshell. Unless Your Honors
`have any other questions, I’m going to move on to discuss the combination
`of Ishiyama and Murakawa.
`JUDGE JIVANI: Mr. Block, I do have a question. It’s Judge Jivani.
`And a moment ago, you said the claims are materially similar, I’m
`paraphrasing, materially similar and very little difference between them, but
`for the language of what you call element 1A and element 1F. Is element 1F
`not the point of novelty that the Examiner cited in original prosecution of
`this patent?
`MR. BLOCK: When you say “this patent,” are you talking about
`
`the --
`
`JUDGE JIVANI: The 810 patent.
`MR. BLOCK: The 810 patent? So, the short answer to that is I think
`it’s more of -- as I understood it, ultimately, that is correct, that is what the
`Examiner said was the point of novelty in the 810 patent. But I think that
`has more to do with what happened during prosecution. Before that, there
`was quite a number of fights related to security gateways. And then,
`ultimately, I think that element that -- which basically required the 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
`
`
`
`10
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`gateway to act using IPSec was what, you know, put it over the edge at the
`end of the day.
`So, I think that is what the Examiner cited, but that’s probably more
`of a -- related to how the prosecution developed up to that point, not
`necessarily what the alleged point of novelty is in the claims, ultimately.
`JUDGE JIVANI: Your response touches on sort of security gateway
`and the meaning of that. And I see in your agenda that that’s where we’re
`headed, so I’ll reserve those questions till we get there and defer to my
`colleagues if they have anything else.
`MR. BLOCK: So, before we get to -- just quickly, before we get to
`the Murakawa and -- I’m sorry, moving on to Ishiyama, if we turn to slide
`10, so, what we have here is a figure from Ishiyama, and on the right-hand
`side we have Figure 2. And as you can see from that figure, Ishiyama has a
`mobile computer. The mobile computer is communicating with something
`called the correspondent host. There is an IPSec tunnel between the mobile
`computer and the correspondent host. And on the left-hand side, there we
`have Ishiyama saying at column 7, 29 through 39, said that mobile computer
`moves between networks. Again, just like what’s happening in the 810 and
`581 patents.
`If we turn to slide 12, we have a different figure from Ishiyama. And
`we have on the left-hand side a description of what happens when the mobile
`computer moves between these networks. And the first paragraph, again,
`this is column 8:55 through 9:4, and the first paragraph there says that the
`mobile computer, when it moves networks, changes addresses. Again, just
`like the 810 and 581 patents.
`
`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
`
`
`
`11
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`The next paragraph on the left shows that when the mobile computer
`changes addresses, it sends a message to the correspondent host indicating
`the fact that it has changed networks and that it has a new address. And then
`the last paragraph there says, well, when the correspondent host sees that
`message, again, just like the 810 and 581 patents, it’s going to update what it
`refers to as an IPSec security association database with that new address. In
`other words, it’s going to update a definition, just like the 810 and 581
`patents. So, that’s Ishiyama in a nutshell.
`And if we turn to slide 15, we have a high-level summary of Ishiyama
`discloses relative to the 810 and 581 patents. Again, it discloses establishing
`a secure connection between mobile computer and what it calls a
`correspondent node. More on that in a moment. It also discloses a mobile
`computer changing addresses, again, just like the 810 and 581 patents.
`When that happens, the mobile computer sends a message to the
`correspondent node notifying it of that new address. And we’ll talk later
`about why that message is encrypted. So, again, that is very similar to what
`the 518 and 810 patents disclose and claim.
`JUDGE HAMANN: Mr. Block?
`MR. BLOCK: Yes.
`JUDGE HAMANN: There’s no -- is there any dispute that Ishiyama
`fails to disclose the other terminal?
`MR. BLOCK: So, the dispute about the -- about Ishiyama disclosing
`the other terminal, I really think boils down to the security gateway
`argument. If you read MPH’s briefing on this topic, in effect, what MPH
`says is that the other terminal doesn’t exist because there’s no 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
`
`
`
`12
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`gateway. There’s no dispute in this case that, in fact, when there is a
`security gateway that there would be another terminal. And so, the real
`dispute boils down to whether or not there’s a security gateway here.
`JUDGE HAMANN: Well, Mr. Block, let me ask it this way, if I
`could, Mr. Block. You know, in the petition, obviously, there’s reference to
`other terminal with Murakawa, as I recall. I’m just trying to understand
`whether the petition cites to Ishiyama and a particular portion of Ishiyama
`for disclosing the other terminal. I recognize it doesn’t (phonetic) say about
`security gateway, I’m just trying to see if it’s broader than that.
`MR. BLOCK: Understood, Your Honor. Thank you for clarifying
`
`that.
`
`So, the petition -- there is no explicit description of another terminal
`in Ishiyama. So, just to answer that directly, that is true.
`What the petition does cite to, and I’ll get to this later on, is it cites to
`Ishiyama’s disclosure of tunnel mode, and then explains why that would be
`obvious that the mere -- the disclosure of tunnel mode would mean that there
`would be another terminal. But, again, that really relates to the security
`gateway argument, as well.
`JUDGE HAMANN: Thank you.
`MR. BLOCK: So, anyway, getting back to the summary slide 10 --
`I’m sorry, 15 rather, as I mentioned, it also discloses updating the
`correspondent node with the new address and that the mobile computer uses
`that updated connection when the address changes. And, of course, the
`connection is undisputedly IPSec.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`13
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`So, that’s Ishiyama. The question then becomes how does Murakawa
`fit into this? Well, as I mentioned earlier, Ishiyama describes the
`correspondent node. It doesn’t describe explicitly a security gateway, so
`Murakawa is relied on for that, as well as the other terminal limitation that
`Your Honor had just mentioned.
`So, why don’t we take a look at Murakawa? And we can turn to slide
`21. There we have the figure from Murakawa. As we can see here,
`Murakawa describes what I think is a very common architecture or what is a
`common architecture of IPSec. It is the VPN architecture, which is the
`mobile terminal connected to a security gateway and then communicating
`with other terminals. So, Murakawa describes this very common
`architecture. It explains on the left-hand side at column 4, 13 to 16, that the
`mobile terminal is in communication with the other terminals through the
`security gateway.
`That’s what Murakawa discloses, but I guess why is it that a person of
`ordinary skill in the art would have combined Ishiyama and Murakawa?
`Well, as I just mentioned, the first reason is that Murakawa describes a very,
`very common architecture in IPSec, and so a person would be motivated to
`modify Ishiyama to be able to support what is a very common architecture
`disclosed in Murakawa. That would allow Ishiyama’s techniques to apply to
`a broader number of architectures. So, that’s the first reason.
`If we turn to slide 40 of Petitioner’s slides, here we have another
`reason why a person of ordinary skill in the art would combine Ishiyama and
`Murakawa, and that is that in the specification for IPSec there are only ever
`two endpoints that are available to be used in an IPSec connection. There
`
`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
`
`
`
`14
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`are only hosts and there are only security gateways. And so if Ishiyama only
`discloses hosts, a person of ordinary skill in the art would understand that
`there only is one other option for endpoint. And so, similar to the common
`architecture point, a person of ordinary skill in the art would adapt
`Ishiyama’s teachings to be able to support the other 50 percent of endpoints
`that are available in IPSec. So, that’s the second reason why a person of
`ordinary skill --
`JUDGE HAMANN: Mr. Block?
`MR. BLOCK: Yes.
`JUDGE HAMANN: This second reason, obviously, on the slide the
`Petitioner’s reply is referred to. Is this argument made in the petition itself
`or is it somehow responsive to Patent Owner’s response?
`MR. BLOCK: Well, Your Honor, we’ve always stated from the
`beginning of this case that the reasons why a person of ordinary skill in the
`art would combine Ishiyama and Murakawa is because of the common
`architecture described in Murakawa and, you know, some of the other
`disclosures in Ishiyama, as well, about tunneling mode, which I’ll get to in a
`second. And so, this is just further evidence related to those exact some
`concepts in terms of why a person of ordinary skill in the art would combine
`Ishiyama with Murakawa. In other words, this explains why Murakawa’s
`architecture is so common.
`JUDGE HAMANN: Okay. I guess I need to try to rephrase my
`question, if I could. I understand, I think, the argument itself. I’m just
`trying to understand whether, you know, this argument was made in 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
`
`
`
`15
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`petition. And if you say it’s a further argument, you know, is it responsive
`to something in particular in the response?
`MR. BLOCK: So, Your Honor, certainly in the response MPH -- in
`the Patent Owner response, MPH argued that a person of ordinary skill in
`the art would not have combined Ishiyama and Murakawa, so this argument
`is responsive to the fact as to why a person of ordinary skill in the art would
`not have combined Ishiyama and Murakawa.
`But I guess my original point, and I apologize if I wasn’t clear, was
`that this argument is just the same -- it’s the same thrust of the argument
`that’s always been in the petition. While it is true that this was -- you know,
`this citation to the RFC was additionally cited in the Petitioner Reply, it’s
`the same argument we’ve been making all along. So, I wouldn’t
`characterize it as a new argument, just further evidence as to the argument
`we’ve already stated.
`JUDGE HAMANN: Thank you.
`MR. BLOCK: So, if we turn to slide 33, if it’s not enough that
`Ishiyama -- that it’s a very common architecture in Murakawa and it’s a very
`common endpoint as to why a person of ordinary skill in the art would have
`combined Ishiyama and Murakawa, slide 33 shows that Ishiyama explicitly
`refers to its correspondent node and the gateway. It’s talking about that
`update request that I talked about earlier, which is when the mobile node
`sends the request, including the new address, to the correspondent node.
`And it explicitly refers to that procedure as an SA Gateway Update. Again,
`what’s being updated? The address at the correspondent node. And so, here
`we have the correspondent node explicitly being referred to as a gateway.
`
`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
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`Finally, Your Honors, as I alluded to earlier, Ishiyama describes that
`its IPSec connection is in IPSec tunnel mode. So, the connection for IPSec
`is IPSec tunnel mode. There are only two different types of connections that
`are IPSec; tunnel mode is one of them. And the important part to understand
`about that is the most common configuration of IPSec tunnel mode is when
`one of the endpoints is a security gateway. That’s a further reason why a
`person of ordinary skill in the art would have combined Ishiyama and
`Murakawa.
`And you don’t have to just take my word for it. If we turn to slide 16,
`here we have the 810 and 581 patents themselves recognizing that tunnel
`mode -- that the most common figuration of tunnel mode is where one of the
`endpoints is a security gateway. It says, “Tunnel mode is often used when
`one or both ends of a security association is a security gateway.” And that
`goes on to explain how that’s IPSec.
`So, again, the most common configuration of IPSec tunnel mode is a
`security gateway and Ishiyama uses IPSec tunnel modes. That’s a further
`reason why a person of ordinary skill in the art would have been motivated
`to combine Ishiyama and Murakawa.
`So, unless Your Honors have --
`JUDGE HAMANN: Mr. Block, you agree that even this statement
`includes the word “often,” so that would imply that tunnel mode could also
`be used when neither end of the SA is a security gateway, isn’t that correct?
`MR. BLOCK: That is correct, Your Honor. But I think this is the
`part that’s lost -- that’s a little bit lost in the briefing on this point. It is true
`that it is technically possible that IPSec tunnel mode can be used in host-to-
`
`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
`
`
`
`17
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`host communications, but it is the vast -- the evidence in this case will show
`us that the vast, vast, vast majority of the case where tunnel mode is used is
`where one of the ends is a security gateway.
`And if we turn to slide 39, here we have an excerpt from Dr. Rouskas’
`deposition. And what it says is that Dr. Rouskas, again, who contends he’s
`an expert in IPSec and has researched and used IPSec extensively for over
`20 years, not once in that entire 20-year timeframe has he ever used IPSec
`tunnel mode with anything other than one of the endpoints being a security
`gateway. So, again, the most common configuration by a long shot is when
`one of the endpoints is a security gateway.
`JUDGE HAMANN: Thank you.
`MR. BLOCK: So, unless Your Honors have any questions about that,
`what I would like to do is turn to the first dispute between the parties, which
`is the construction of security gateway.
`So, again, slide 26 of Petitioner’s slides, here we’ve laid out what the
`constructions are between the parties. Apple contends that the security
`gateway should just be given its plain and ordinary meaning. And more
`importantly, contends that this issue is just not dispositive at all in this case
`with respect to the claim construction, and I’ll get to that in a moment.
`MPH has a complex definition that requires two definitions, but, in
`effect, their definition of security gateway requires it to first provide security
`functionality; second, it has to be an intermediary system; it then needs to
`have two more communication interfaces; it needs to interconnection
`different networks; and it needs forward packets it receives from one of
`
`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
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`those networks on to another network. That’s MPH’s construction. But let
`me explain why this issue isn’t dispositive at all.
`If we turn to slide 21, which, again, is a slide that have with
`Murakawa on it, here we have a figure of Murakawa on that slide, Figure 5.
`And it’s plain as day that this architecture has all of the limitations in MPH’s
`construction. Right? We have a security gateway. It’s connected to a first
`network, 102, via a first interface. It’s connected to another network, 104,
`through another interface. And it’s forwarding -- the entire point of
`Murakawa is that packets are getting forwarded between mobile terminals
`and other terminals. So, again, they’re just not -- this issue’s just not
`dispositive because Murakawa plainly discloses all of the limitations of
`Patent Owner’s construction here.
`So, unless Your Honors have any particular questions about the
`construction, what I would like to do is turn to the primary dispute between
`the parties, which is whether or not the combination discloses Ishiyama and
`Murakawa.
`JUDGE JIVANI: I do want to explore the construction a little bit,
`Mr. Block, because I am troubled by your statement of plain and ordinary
`meaning. And I’d like you to refer to your slide 40, please.
`So, I believe here you’ve reproduced the Request for Comment, RFC
`2401, in which you point us to a highlighted sentence describing the
`elements between IPSec. Right? And a moment ago, we heard you argue
`about the possibility of a security gateway and a host. So, you direct us to
`this statement.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`19
`
`
`
`IPR2019-00819 (Patent 7,620,810 B2)
`IPR2019-00820 (Patent 7,937,581 B2)
`
`
`
`
`And immediately after that sentence is a parenthetical. The
`parenthetical reads, “The term ‘security gateway’ is used throughout the
`IPSec documents to refer to an intermediate system that implement IPSec
`protocols. For example, a router or a firewall implementing IPSec is a
`security gateway. ” End parenthetical.
`So, Mr. Block, it seems that you’ve sort of selectively pointed us to
`disclosure in RFC and I wonder why that is. In particular, I wonder why we
`should -- or rather how we should understand this parenthetical as it relates
`to security gateway as recited in the claim language of both patents.
`And also, I’d like you to address, please, and I realize my question is
`long, but I’d also like you to address, please, why this issue hasn’t been
`raised before. You continue to assert that we should apply plain and
`ordinary meaning without giving us a lot of color on what that is and
`ignoring this explicit statement of scope in the RFC that you put before us.
`MR. BLOCK: Thank you, Your Honor. Well, again, we think the --
`as I just mentioned, whether the security gateway is an intermediate system,
`whether it has two interfaces, all of the limitations of MPH’s definition, it’s
`just not dispositive because Murakawa plainly discloses that. But with
`respect to the RFC disclosure her
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
