`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