[00:00:00] Speaker 00:
Our next case is Apple versus MPH Technologies, 2021, 1355.

[00:00:07] Speaker 00:
Good morning, Mr. Matsui.

[00:00:15] Speaker 00:
We're ready when you are.

[00:00:19] Speaker 02:
May it please the court, Brian Matsui for Apple.

[00:00:22] Speaker 02:
I would like to address two issues.

[00:00:23] Speaker 02:
First, I would like to address the board's claim construction that a request message being encrypted requires the outer header of the message, including the source and destination addresses, to be encrypted.

[00:00:36] Speaker 02:
Second, I would like to address the board's misreading of this court's precedent when it refused to address Apple's grounds with respect to claims 6 to 8 of the 581 patent.

[00:00:47] Speaker 02:
So turning first to the request message being encrypted, the board made a straightforward claim construction error.

[00:00:55] Speaker 02:
A request message being encrypted by IPSEC protocols always has an outer header that is always unencrypted.

[00:01:02] Speaker 02:
with source and destination addresses that are always sent in the clear.

[00:01:07] Speaker 03:
Is the term request message a term of art?

[00:01:10] Speaker 03:
No, Your Honor, it's not.

[00:01:12] Speaker 03:
So I spent hours on this case, and I kind of understand your arguments.

[00:01:17] Speaker 03:
I kind of understand the other side of the argument.

[00:01:19] Speaker 03:
But it seems like the dispute between you all is not really on what part of this transmission has to be

[00:01:32] Speaker 03:
encrypted or not, it's what message actually means in this context.

[00:01:39] Speaker 03:
I don't understand the technology fully here, and so both sides can correct me if I'm wrong.

[00:01:45] Speaker 03:
But I understand your argument to be that any type of transmission is going to have to have at least some address information to get it to the right place, and that that's not going to be encrypted.

[00:01:56] Speaker 03:
The message that this is referring to could be something different than that, though, right?

[00:02:02] Speaker 02:
So Your Honor, just to sort of unpack that a little bit, yes, any sort of message that is sent through IPSEC protocols is going to have an unencrypted outer header that has source and destination addresses that are in the clear.

[00:02:17] Speaker 02:
That's undisputed.

[00:02:18] Speaker 02:
That's common ground between the parties.

[00:02:20] Speaker 02:
It's clear on the patents, and both experts agree on that.

[00:02:24] Speaker 02:
As far as what the request message requires.

[00:02:25] Speaker 03:
So can I just stop you there?

[00:02:27] Speaker 03:
Is it possible that the board saw

[00:02:30] Speaker 03:
The those those outside, I know you want to keep referring them to us as headers.

[00:02:35] Speaker 03:
Maybe that's because it's term of art.

[00:02:37] Speaker 03:
I want to call it address because that's easier for me to understand.

[00:02:40] Speaker 03:
And I think part of the problem is that maybe some of the information that's typically in a header could also be part of a message, which seems to me part of the dispute here.

[00:02:51] Speaker 03:
But is it possible that the board understood this to be a distinction between what the message is and those outer address issues?

[00:02:59] Speaker 03:
I don't think so, Your Honor.

[00:03:00] Speaker 03:
Let me give you an example.

[00:03:02] Speaker 03:
I hate to be so analog about this, but this is how it helped me to think about it.

[00:03:07] Speaker 03:
Think about a letter and the message.

[00:03:10] Speaker 03:
Think about the message being

[00:03:11] Speaker 03:
the letter inside the envelope.

[00:03:14] Speaker 03:
And if you want to get it to the right person, you have to put an address on it.

[00:03:18] Speaker 03:
And if you want to send something to this person and say, I've moved, here's my new address, there's two ways of doing it.

[00:03:24] Speaker 03:
You could just put the return address on the outside of the envelope.

[00:03:28] Speaker 03:
Or you could not put the return address on the outside of an envelope, because you don't want the whole world to know where you live, and only put it on the inside of the envelope.

[00:03:37] Speaker 03:
And in that case,

[00:03:39] Speaker 03:
The message includes the instructions here's where I am now which I think is what the cell phones trying to do right it but it's not part of the what seems to me the address or the headers.

[00:03:53] Speaker 03:
Tell me why that's not.

[00:03:55] Speaker 03:
What essentially what the board was doing here which was saying the internal message that has the information of that this Tower needs to know where the cell phone is is all encrypted even if there's some Unencrypted outside part that has to get that message to the tower so so one problem with that hypothetical your honor Which I think is which sort of hits on the point is that when you're talking about ipsec protocols You're always going to have on that

[00:04:23] Speaker 02:
outer envelope, the return address.

[00:04:26] Speaker 02:
It's always going to be there.

[00:04:27] Speaker 02:
You're going to have both the address where it's supposed to go, and you're going to have the return address that are always there.

[00:04:34] Speaker 02:
And so in that sense, whenever you're talking about a request message being encrypted, it's always going to have that source and destination address that are sent in the clear.

[00:04:44] Speaker 02:
And so the board's claim construction, which was basically saying a request message can't be a portion that's encrypted and a portion that's unencrypted, is always going to be that way when you're talking about IDSEC protocols.

[00:05:00] Speaker 03:
Doesn't that depend on how you define message?

[00:05:06] Speaker 03:
I don't think it does, Your Honor.

[00:05:07] Speaker 03:
First of all, request message is just... I'm not sure this actually works against you, by the way.

[00:05:12] Speaker 03:
It seems to me that part of the problem I'm having in this case is I don't understand what the board meant when it was using the term message in looking at the prior art.

[00:05:25] Speaker 03:
So it's hard for me to determine whether there's substantial evidence to support.

[00:05:29] Speaker 03:
the board's conclusion that the prior art does it because I don't understand what it meant to refer to as a message, whether it's this internal thing without the headers or it's the whole thing.

[00:05:39] Speaker 02:
I think the board clearly found as a matter of fact that Ishiyama discloses a request message.

[00:05:47] Speaker 02:
It found that it discloses a request message using IPsec protocols.

[00:05:51] Speaker 02:
It said that, and there's substantial evidence that supports that finding.

[00:05:55] Speaker 02:
And that supports us.

[00:05:57] Speaker 02:
That was an issue that Apple won before the board.

[00:06:00] Speaker 03:
And it was only because... One last question, and I'll let you go on.

[00:06:09] Speaker 03:
What I'm struggling with is I get your argument that under IPSEC protocols, you have to have this editor that has this information.

[00:06:17] Speaker 03:
for it to be transmitted.

[00:06:19] Speaker 03:
That's just the way it won't work without that.

[00:06:21] Speaker 03:
And if the board's construction is that that entire thing has to be encrypted, is that even possible?

[00:06:28] Speaker 03:
I think your position is it's not possible.

[00:06:31] Speaker 02:
And yes, it's not possible.

[00:06:32] Speaker 02:
Because you're always going to have an outer header that's unencrypted.

[00:06:35] Speaker 03:
I mean, would we presume that the board, who presumably at least some of those APJs were more technically sophisticated than I am, would come up with a meaning that just didn't work?

[00:06:46] Speaker 02:
I think that in the context of this case, yes, that's exactly what happened here.

[00:06:51] Speaker 02:
Because when you look at... Well, if that's the construction, then nobody does it, do they?

[00:06:57] Speaker 03:
No, that's the problem.

[00:07:00] Speaker 03:
Even if the patent is valid, nobody can possibly infringe it because it doesn't work.

[00:07:07] Speaker 03:
I know you want to get rid of it now and not have to deal with it in litigation.

[00:07:11] Speaker 03:
But if the board's claim construction really means that the entire thing, including the headers, have to be encrypted, then who cares?

[00:07:20] Speaker 03:
Because nobody can actually infringe something that's not going to work in the real world.

[00:07:24] Speaker 02:
I mean, I think that, yes, Your Honor, I understand your point.

[00:07:28] Speaker 02:
But I still think that we're talking about here whether or not these claims are patentable.

[00:07:32] Speaker 00:
Counsel, you said you had two issues to raise.

[00:07:35] Speaker 00:
Do you want to get to the second one?

[00:07:37] Speaker 02:
Well, if I could just spend a couple more seconds on this issue, if you didn't mind, Your Honor, just because I wanted to make clear that when we're talking about these claims, they make very clear that they're talking about IPSEC protocols.

[00:07:49] Speaker 02:
You know, claim one specifically recites in it that it's IPSEC protocols.

[00:07:53] Speaker 01:
Is this part of your support really in column three and the board really relies on column 10?

[00:07:57] Speaker 01:
Isn't that?

[00:07:58] Speaker 01:
what helps support of your construction in particular?

[00:08:01] Speaker 02:
Yes, Your Honor.

[00:08:02] Speaker 02:
I think that column three discusses IPsec protocols, and MPH's expert also discussed column three.

[00:08:10] Speaker 02:
And when you're talking about, say, line 55, it's talking about an IPsec tunnel mode.

[00:08:18] Speaker 02:
It says this packet, which would be the message, is now routed to other hosts firewall with intermediate routers examining only the IP

[00:08:26] Speaker 02:
the outer IP header and so these intermediate routers are of course examining the letter, the address that it's addressed to and then the return address and so that is always going to be unencrypted.

[00:08:39] Speaker 02:
You're always going to have an unencrypted outer header and that's made clear by the specification.

[00:08:44] Speaker 02:
I'd also just point the core to appendix 2258 to 2259 where MPH's expert said you're always going to have this outer header

[00:08:54] Speaker 02:
In both tunnel mode and transport mode, where it's sent in the clear.

[00:08:59] Speaker 01:
Can your construction all be supported just by the intrinsic evidence?

[00:09:03] Speaker 01:
Do we need any extrinsic evidence?

[00:09:06] Speaker 02:
I think that it can purely be supported by column three right there, what you're talking about, because it's talking about

[00:09:13] Speaker 02:
You know, these intermediate routers that are examining the source and the destination address.

[00:09:18] Speaker 02:
And so any message that's sent through the security association is going to be only a portion of it's going to be encrypted under the board's construction, which it just shows why the board's construction is erroneous.

[00:09:30] Speaker 02:
But I think that persons of ordinary skill and regard, I mean, this was

[00:09:33] Speaker 02:
common ground among the parties and the experts where they basically put forth detailed declarations talking about IP sec protocol that made clear that you're going to have this unencrypted outer header and it's unfortunate the board just just didn't get it and I think that that's why this claim construction

[00:09:50] Speaker 02:
Ended up being dispositive, even though the board found that Ishiyama discloses a request message that has an inner packet that matters because that has the source of the home address that allows the other host to know, hey, this is actually the mobile computer that moved, and to update then the security association.

[00:10:10] Speaker 02:
Now, Judge Laurie, I'd be happy to turn to the second issue that I wanted to reach.

[00:10:15] Speaker 02:
with respect to the 581 patent and claims six to eight.

[00:10:19] Speaker 02:
I think the board's decision here should at least be vacated so that it can decide the issue that Apple actually raised in its petition.

[00:10:28] Speaker 00:
The problem is clients pleading.

[00:10:33] Speaker 02:
No, Your Honor.

[00:10:34] Speaker 02:
I think that, first of all, the board misread this court's precedent in the Connington case to basically say that you have to repeat everything that goes to the dependent claim, that went to the parent claims when you're making a challenge to the dependent claims.

[00:10:52] Speaker 02:
Nothing in the Patent Act requires you to do that.

[00:10:55] Speaker 02:
Section 312 of the Patent Act just states the requirements for the petition itself.

[00:11:00] Speaker 02:
It doesn't state the requirements

[00:11:02] Speaker 02:
for grounds to be decided.

[00:11:04] Speaker 02:
It's just saying the requirements for a petition to be instituted.

[00:11:07] Speaker 01:
But with the way that the grounds were written, are you essentially avoiding some of the motivation to combine arguments by the way that it was written?

[00:11:14] Speaker 02:
No, Your Honor.

[00:11:15] Speaker 02:
We're not at all.

[00:11:16] Speaker 02:
I think that when you look at the structure of the petition, any time that there's a new reference that's put in, if you talk about claim five, for example, in the 581 patent, there's a discussion of motivation to combine with respect to those three references.

[00:11:32] Speaker 02:
And with respect to claims 6-8, it's discussing the motivation to combine with respect to the two references that are talking about that unique limitation.

[00:11:41] Speaker 03:
Wait, are you saying that in the discussion of claims 6-8, it talks about the motivation to combine the additional references with the Ohonan reference?

[00:11:51] Speaker 02:
No, Your Honor.

[00:11:52] Speaker 03:
With respect to claim 5... Well, that would sure help you, because then it would make clear that you intended all references.

[00:11:57] Speaker 03:
I mean, it seems pretty pr... I mean,

[00:12:01] Speaker 03:
I know the board's being overly technical here, but

[00:12:04] Speaker 03:
You're supposed to lay out your grounds for obviousness for each claim separately, or at least in groupings.

[00:12:10] Speaker 03:
And for claims six through eight, you didn't include a hone in.

[00:12:13] Speaker 02:
So there's nothing in the requirements of the statute that say that you have to do that.

[00:12:18] Speaker 02:
The ground here is attacking the unique limitation of claims.

[00:12:22] Speaker 03:
So you at least have to tell the board that you're relying on a hone in in some sense.

[00:12:26] Speaker 03:
I mean, if you had had a table and just added in these two references, at least in the text you had said,

[00:12:33] Speaker 03:
For the dependent claims, everything for five plus these two.

[00:12:38] Speaker 03:
But none of that's in the text.

[00:12:39] Speaker 03:
All you do is talk about those two references and why they show the claims.

[00:12:44] Speaker 03:
Yes, when you look at the structure of the petition.

[00:12:46] Speaker 03:
Let me just ask one more question.

[00:12:47] Speaker 03:
No, you weren't interrupting, but I just want to make clear.

[00:12:50] Speaker 03:
If you just take your petition on its face,

[00:12:53] Speaker 03:
for the parts that address six through eight, your discussion and your references don't disclose all the elements.

[00:12:59] Speaker 03:
Is that right?

[00:13:00] Speaker 02:
If we just talk about the specific part of six to eight, yes.

[00:13:02] Speaker 02:
It's only addressing the unique limitation, which is what this court's precedent, like Ormco and Max Linear, are basically saying you're supposed to do.

[00:13:11] Speaker 02:
Once you have a parent claim that's been held unpatentable or invalid, then it has to be the unique limitation of the dependent claim in order to uphold its patentability.

[00:13:21] Speaker 02:
And that's precisely what we did with respect to claim six.

[00:13:26] Speaker 02:
If there are no further questions.

[00:13:28] Speaker 01:
We do have one question.

[00:13:29] Speaker 01:
Do we need to find an APA violation?

[00:13:31] Speaker 01:
There was some.

[00:13:32] Speaker 01:
Discussion of that in the briefing, I just want you to address that.

[00:13:35] Speaker 02:
This is on the first issue, the claim.

[00:13:38] Speaker 02:
No, Your Honor, I mean, I think that the court can reverse outright given the fact that once you set aside the ornate's claim construction it's basically

[00:13:45] Speaker 02:
undisputed given the fact that the board found that Ishiyama disclosed the request message.

[00:13:50] Speaker 02:
So there doesn't need to be a finding of an APA violation.

[00:13:53] Speaker 02:
I think that what it shows, what our brief show though, is that this claim construction issue basically came up at the oral hearing because the parties were completely disputing something different, whether or not Ishiyama disclosed a request message, whether or not it was just the outer header or whether or not it was the entire transmission as the board found, as Apple asked it to.

[00:14:14] Speaker 00:
Thank you, Mr. Matsui.

[00:14:17] Speaker 00:
We'll give you two minutes for a bottle.

[00:14:18] Speaker 00:
Thank you, Your Honor.

[00:14:20] Speaker 00:
Mr. Hahn.

[00:14:24] Speaker 04:
May it please the Court, Brian Hahn for Appellee, Patent Owner, MPH Technologies.

[00:14:28] Speaker 04:
Here with me is Jim Carmichael, Co-Counsel for MPH.

[00:14:34] Speaker 04:
During Apple's argument, we touched on a very important issue here, and that's the encrypted request message.

[00:14:40] Speaker 04:
And I think Judge Hughes made a very good point

[00:14:43] Speaker 04:
And our request message is not a term of art here.

[00:14:46] Speaker 04:
So I think what's important is we look very closely at the claims and what the claims say.

[00:14:52] Speaker 03:
If it's not a term of art, why didn't you all ask the board to specifically construe it?

[00:14:57] Speaker 03:
I mean, it's really problematic to me that we don't have a definition of what it is to determine whether it's disclosed in the prior art or not and determine whether there's substantial evidence for that.

[00:15:09] Speaker 03:
And it does seem to me that now,

[00:15:11] Speaker 03:
the two of you are arguing over what it means?

[00:15:18] Speaker 04:
Well, I think there's a very good reason that the parties did not ask for claim construction on this.

[00:15:22] Speaker 04:
And that's because we think that the plain language of the claims actually answers this question.

[00:15:27] Speaker 04:
And I'll tell you why.

[00:15:28] Speaker 04:
If we look at the 810 patent in column 10, let's first look, before we get to the real element in question, the first time a request message appears is in element C. Can you give me a page number?

[00:15:39] Speaker 04:
Sure.

[00:15:40] Speaker 04:
This is appendix 138.

[00:15:52] Speaker 04:
And at line 60, it states.

[00:15:57] Speaker 04:
mobile terminal sending a request message to the address of the security gateway to request the security gateway to change the secure connection to be defined between the second address and the address of the security gateway.

[00:16:10] Speaker 04:
So before we get to the encrypted part here, this is where the request message first appears.

[00:16:14] Speaker 04:
And what's important here is that you can see from the plain language of the claim that what is a request message is something that actually requests a change of an address.

[00:16:24] Speaker 04:
So there's really only two requirements for a request message that are important to this appeal.

[00:16:29] Speaker 04:
The first one, which is very important, is this one.

[00:16:32] Speaker 04:
The request actually requests the change.

[00:16:34] Speaker 04:
It has to change the address definition.

[00:16:37] Speaker 04:
So then we get to the last element of the claim on Appendix Page 139.

[00:16:42] Speaker 04:
And it says the request message is encrypted.

[00:16:46] Speaker 04:
That was Apple's assertion.

[00:16:47] Speaker 04:
There's actually various alternatives here.

[00:16:50] Speaker 04:
A request message could be encrypted or authenticated.

[00:16:53] Speaker 04:
You could have a reply message.

[00:16:54] Speaker 04:
But they chose to assert only or rely only on an encrypted request message, supposedly in the Ishiyama reference.

[00:17:02] Speaker 04:
So you start with, well, the request message actually has to request the change.

[00:17:06] Speaker 04:
And whatever that structure is that actually requests the change, that structure must be encrypted.

[00:17:12] Speaker 01:
Does the language go on to say encrypted by using the same essay already established?

[00:17:17] Speaker 01:
And then previously there it says essay using IPSEC protocols.

[00:17:21] Speaker 01:
I just want to make sure you're in the full context.

[00:17:23] Speaker 04:
That's correct.

[00:17:25] Speaker 01:
And so does that also then take us to that column three that I was discussing with opposing counsel?

[00:17:31] Speaker 04:
Well, yes your honor column 3 certainly discusses the background of ipsec and generally what those protocols are so it describes You know some of what we talked about that many times in IP communications you have unencrypted outer headers, but you have an encrypted portions packets encrypted portion of the packet

[00:17:49] Speaker 04:
But there are two key admissions here from Apple that really cut through all of this.

[00:17:55] Speaker 04:
The first one is that the outer packet, the outer header of Ishiyama's packet is what actually requests the change.

[00:18:01] Speaker 04:
That's that first element I was talking about in the claims.

[00:18:04] Speaker 04:
This is at the hearing twice they admitted this, appendix page 747, lines 11 through 12, and appendix page 781 through 782.

[00:18:16] Speaker 04:
So they admitted that that outer header, that's actually what requests the change.

[00:18:22] Speaker 04:
So that's that first element in the claim.

[00:18:24] Speaker 04:
And the second key admission from Apple is that that outer header is not encrypted.

[00:18:29] Speaker 04:
And this is at appendix page 740 and appendix page 742.

[00:18:33] Speaker 04:
And these two admissions alone are fatal to Apple's entire appeal on the encrypted request message claims.

[00:18:40] Speaker 04:
Because what actually requests the change in the address must be encrypted according to the claims.

[00:18:45] Speaker 03:
And what's... So I understand what you're saying.

[00:18:47] Speaker 03:
And that seems to be a reasonable construction of the patent.

[00:18:52] Speaker 03:
But I'm not sure that that was the definition the board was using.

[00:18:55] Speaker 03:
That the request message was the information

[00:18:58] Speaker 03:
required to request the change in location.

[00:19:02] Speaker 03:
Can you point to me anywhere in the board's decision that it's clear that's the definition they were using?

[00:19:07] Speaker 03:
Because it sure seemed to me like they were using a much broader definition, which was the entire thing had to be encrypted.

[00:19:16] Speaker 04:
No.

[00:19:17] Speaker 04:
And I think that's what Apple is asserting.

[00:19:18] Speaker 04:
And in fact, Apple is asserting that the board construed the claim.

[00:19:21] Speaker 03:
Well, that's what also the questions from the APJ that asked them seems to suggest to me.

[00:19:28] Speaker 03:
You know, that's what's problematic here.

[00:19:30] Speaker 03:
And again, I'm not blaming you all for not requesting a claim construction at the outset.

[00:19:35] Speaker 03:
But when it became clear that the board seemed to have a different understanding of it from both of you, why you all didn't ask for a claim construction is beyond me.

[00:19:47] Speaker 03:
I mean, your definition seems like it could potentially be right.

[00:19:51] Speaker 03:
I'm sure we're going to hear from Apple on rebuttal why it's not.

[00:19:57] Speaker 03:
I don't know that that's the definition that the board applied here.

[00:20:01] Speaker 03:
What's evidence in their decision?

[00:20:04] Speaker 03:
Does it suggest that that's the definition they applied?

[00:20:08] Speaker 04:
I think if we look at the board's decision, appendix page 20, the board recognized that the plain words of the claim state that the request message is encrypted.

[00:20:21] Speaker 03:
And I think the board... That's not good enough, though, because the problem is not whether it has to be encrypted or not.

[00:20:27] Speaker 03:
It's what it is.

[00:20:30] Speaker 03:
You've come up here, and I think given me at least a logical definition, I don't know if it's correct or not, because of how it intersects with IPSEC protocols, which adds a technological complication on top.

[00:20:43] Speaker 03:
But to the extent you're saying the request message is the information needed to

[00:20:49] Speaker 03:
Request the change in location and that all of that has to be encrypted.

[00:20:53] Speaker 03:
That's fine But where did the board say anything remotely similar to that?

[00:20:58] Speaker 04:
They just keep repeating that the request message has to be encrypted without defining what request message is Well, I think I mean the board the parties didn't ask them to and I think they aptly noted if you asked where did they Discuss this and I think at appendix page 22 in the 810 decision the board says

[00:21:21] Speaker 04:
Well they're responding to petitioner to Apple's argument that you know the outer header can't be encrypted and they say well even if we consider this argument petitioner conflates a request message that includes its own encrypted outer packet as part of their quest which is what Apple has asserted here with a request message that does not.

[00:21:39] Speaker 04:
i.e.

[00:21:39] Speaker 04:
a request message that's contained wholly within the encrypted packet.

[00:21:44] Speaker 04:
And if you look at the patent, that's what's actually taught here.

[00:21:47] Speaker 04:
There's something called a registration request.

[00:21:49] Speaker 04:
The specification refers to it as an abbreviated form, the RREQ.

[00:21:57] Speaker 04:
The spec repeatedly talks about the request message being protected.

[00:22:01] Speaker 01:
And so... Would you concede that a packet with unencrypted address information could not infringe the claims?

[00:22:11] Speaker 04:
with an unencrypted outer packet?

[00:22:16] Speaker 04:
Would we concede that?

[00:22:18] Speaker 01:
Yes.

[00:22:20] Speaker 04:
No, Your Honor.

[00:22:22] Speaker 04:
I mean, indeed,

[00:22:24] Speaker 04:
I think as we recognize, I don't think it's an evidence that necessarily every IP communication has unencrypted outer headers, but I think many times they do.

[00:22:32] Speaker 04:
But what we're talking about here is the request message being encrypted.

[00:22:37] Speaker 04:
And the specification talks specifically about that being a registration request.

[00:22:42] Speaker 04:
That is a return of ART that's known in mobile IP, although the claims are not limited to that.

[00:22:48] Speaker 04:
But I think a person still understands that this goes in the encrypted portion of the packet.

[00:22:53] Speaker 03:
And so the claim doesn't speak... You're saying that the request message is a registration request?

[00:23:00] Speaker 04:
That's one embodiment that's talked about in the specification.

[00:23:04] Speaker 03:
What is a registration request contained?

[00:23:08] Speaker 04:
I mean, it's described in the specification.

[00:23:11] Speaker 04:
I mean, it's not limited specifically, but if I could direct the court's attention here to

[00:23:19] Speaker 04:
Column 7, line 43, the signaling mechanism is preferably similar to the one in mobile IP registration request, RREQ.

[00:23:30] Speaker 04:
And it goes on from there.

[00:23:32] Speaker 04:
And if, you know, we look at the top of column seven, it starts this discussion by saying that the request and a reply message can be protected, i.e.

[00:23:42] Speaker 04:
by IPsec encryption and or authentication.

[00:23:45] Speaker 04:
So again, it's clear that the request itself is actually protected.

[00:23:50] Speaker 04:
And it's clear that Ishiyama's request, which focuses primarily on the outer header because that's actually what changes the address definition, this is unencrypted.

[00:24:00] Speaker 00:
Council, do you want to get to the pleading issue?

[00:24:02] Speaker 04:
Yes, Your Honor.

[00:24:06] Speaker 00:
And do you think the Board was unduly technical?

[00:24:11] Speaker 04:
I do, Your Honor.

[00:24:13] Speaker 04:
I think the both I'm sorry was the board technical no your honor your answer surprised me sorry I misspoke Apple's appeal fails on claims six or eight because the board correctly found that the grounds Apple raised failed to address intervening claim five and this is not a mere technicality and

[00:24:33] Speaker 04:
This is not form over substance this is a statutory requirement and the requirement is very clear that under section 312 that you have to identify the claims you have to identify each ground for each claim and you have to identify each piece of evidence for those claims and we talked a little bit during Apple's opening argument about the actual substance of their briefing and if I could

[00:25:02] Speaker 04:
direct your attention to appendix pages 3273 and 3274.

[00:25:11] Speaker 04:
This is Apple's petition and it starts its analysis for ground one.

[00:25:17] Speaker 04:
It asserts that Ishiyama discloses each and every limitation for claims six through seven, except for the security gateway limitation on which it relies for Murakawa.

[00:25:28] Speaker 04:
So it's clear that Apple was only relying on

[00:25:31] Speaker 04:
Ishiyama and Murakawa for those claims.

[00:25:34] Speaker 04:
It was not, this was no mistake in just a heading or something.

[00:25:37] Speaker 04:
This was actually the actual substance of the brief.

[00:25:40] Speaker 03:
Well what happens when you get down to claim five though?

[00:25:43] Speaker 03:
Don't those claims depend on claim five?

[00:25:46] Speaker 04:
Those claims do depend from claim five.

[00:25:48] Speaker 03:
Well, what did they say about claim five?

[00:25:49] Speaker 04:
Ironically, claim five in the petition actually follows claims six through seven.

[00:25:54] Speaker 04:
So Apple hadn't even gotten to claim five yet by the time that it had made all of its argument and stopped.

[00:25:59] Speaker 03:
I mean, they wrote a bad petition.

[00:26:01] Speaker 03:
There is no doubt about that and whether we saved them or not is a different question.

[00:26:06] Speaker 03:
But I'm just curious, what did the board say?

[00:26:09] Speaker 03:
Did the board say anything specifically about any of this when it instituted the IPR?

[00:26:15] Speaker 03:
I guess what I'm asking is, if the board looked at this and said, well, they didn't say it explicitly, but we understand because they proposed a hone-in under Claim 5 and 6 through 8 are dependent on that, they must have meant to include a hone-in.

[00:26:31] Speaker 03:
Could they have done that and read it as sufficiently proposing that as a ground?

[00:26:38] Speaker 04:
I don't believe that was the dependent claims, including these claims, my recollection, Your Honor, were discussed extremely briefly in the institution.

[00:26:46] Speaker 03:
Right.

[00:26:47] Speaker 03:
I assume if they had evidence that showed the board understood that they included Ahona, they would be telling us that.

[00:26:53] Speaker 03:
Do you think if that had happened that that would be legal error on the board's part?

[00:26:58] Speaker 04:
For purposes of institution, I mean, they're looking at things from a high level and they say there's enough arguments raised here that

[00:27:05] Speaker 04:
you know, that we can institute the claims.

[00:27:08] Speaker 03:
No, but I mean more specifically, if they'd looked at this faulty pleading and said, even though Apple didn't repeat Ahonan for six to eight, it's clear because it's dependent that they must have meant to include that.

[00:27:21] Speaker 03:
And therefore, we institute under Ahonan and the other references.

[00:27:25] Speaker 03:
Would that have been legal error?

[00:27:27] Speaker 03:
Or because you would have been given notice that they would have looked at this combination, it would have been a proper institute?

[00:27:35] Speaker 04:
I think that would have been legal error.

[00:27:36] Speaker 04:
I mean, we cited cases like the Conoclia Phillips and Serona Dental case in the briefing.

[00:27:42] Speaker 04:
And they're very clear that the board may not institute or decide grounds that aren't raised, specifically raised.

[00:27:50] Speaker 03:
But that's assuming they're not raised.

[00:27:52] Speaker 03:
If the board reads this petition and says the inference here is that they are raised, can they do that?

[00:27:59] Speaker 03:
It's OK.

[00:28:00] Speaker 03:
They didn't really do that here.

[00:28:01] Speaker 03:
So it's not a question you have to answer.

[00:28:05] Speaker 04:
I think it's telling, Your Honor, that the board went on to actually analyze the grounds that were raised because Apple argued as an alternative that even without Tihon in reference and Claim 5, well, Ishiyama and Murakawa together have this reply message in Claim 5.

[00:28:24] Speaker 04:
We really don't need it, judges.

[00:28:26] Speaker 04:
And so the EPJs actually went ahead and analyzed those

[00:28:31] Speaker 04:
Those pieces of prior are for those claims and found that they were insufficient.

[00:28:37] Speaker 04:
And tellingly, Apple is not challenging those analyses for claims six, seven, or eight.

[00:28:42] Speaker 04:
They're only challenging this so-called error with respect to intervening claim five.

[00:28:47] Speaker 01:
Council, do you agree that if a registration request had unencrypted address information, that cannot meet an encrypted request message?

[00:28:57] Speaker 01:
Do you agree with that statement?

[00:28:58] Speaker 04:
No, Your Honor, because I think the encrypted request message, as the Board even noted, that Apple failed to account for where the request message, what's actually requesting the change is in the encrypted part of the packet.

[00:29:10] Speaker 04:
And that, and so thus it could then have unencrypted outer headers.

[00:29:17] Speaker 04:
And this is true either for transport mode or tunnel mode.

[00:29:23] Speaker 04:
I see that I'm out of time.

[00:29:25] Speaker 04:
If there's no other questions, I'll take a seat.

[00:29:27] Speaker 00:
Thank you, Counsel.

[00:29:28] Speaker 04:
Thank you.

[00:29:29] Speaker 00:
Mr. Matsuo, you have two minutes for a bottle.

[00:29:32] Speaker 00:
Maybe even 202.

[00:29:55] Speaker 02:
Thank you, Your Honor.

[00:29:57] Speaker 02:
I'd like to turn briefly to the first claim construction issue.

[00:30:00] Speaker 02:
On request message, there are only three things that are at all clear that a request message requires from this patent.

[00:30:06] Speaker 02:
One, that it basically has to, after the request message goes through, that there has to then be a change in the address of the security association.

[00:30:15] Speaker 02:
It has to be encrypted and it has to be encrypted by IP sick protocols.

[00:30:20] Speaker 02:
That's all that we know about this very generic term I call them Three seven line ten they basically say request is used in a generic sense when you're looking at

[00:30:32] Speaker 02:
What we said at oral argument before the board at appendix 747 we made clear that the bottom line is that the entire package is the request message and that's clear clearly what the board held at appendix 18 as well at Column 7 which my friend referenced if you look there at line 56 it's saying that this request message appears to come from the wrong address and

[00:30:56] Speaker 02:
which is showing that basically it's coming from the outer header is basically saying it's coming from the wrong address.

[00:31:02] Speaker 02:
It has unexpected address information.

[00:31:06] Speaker 02:
And then it uses the request message to update it.

[00:31:09] Speaker 02:
And Ishiyama appendix at appendix 1259 at column 6 explains what this encapsulated packet does, the encrypted part.

[00:31:18] Speaker 02:
It has the original home address of the mobile computer.

[00:31:22] Speaker 02:
And so that was basically what tells.

[00:31:23] Speaker 02:
And that's encrypted.

[00:31:25] Speaker 02:
And that basically tells.

[00:31:26] Speaker 02:
the other computer, hey, you can update the address here because this is the trusted computer that was moving.

[00:31:35] Speaker 02:
So given all that, you basically have claims that require IPsec protocols.

[00:31:40] Speaker 02:
And that's exactly what Ishiyama discloses.

[00:31:43] Speaker 02:
And then just lastly on claims six to eight, it's very clear from the institution what our petition was arguing here.

[00:31:51] Speaker 02:
And the only way to read the petition is that each of these arguments went to the individual limitations that we had.

[00:31:58] Speaker 02:
If there are no further questions, we would ask the court to reverse.

[00:32:01] Speaker 00:
Thank you, counsel.

[00:32:02] Speaker 00:
The case is submitted.