[00:00:54] Speaker 05:
Okay, our final case this morning is number 17-1272, Stambler v. MasterCard International, Inc.

[00:01:02] Speaker 05:
Mr. Bumgardner.

[00:01:07] Speaker 02:
Thank you, Your Honor.

[00:01:09] Speaker 02:
May it please the Court.

[00:01:11] Speaker 02:
Mr. Stambler's brief raised four issues for appeal, and today I want to focus on issues one and three, but I'm of course happy to answer questions that you have on any of the issues.

[00:01:22] Speaker 02:
So let me first start with issues.

[00:01:23] Speaker 05:
Let me see if I can understand this a little bit better.

[00:01:27] Speaker 05:
If I understand Davies, what Davies shows, or at least what the board found that Davies shows, is that the token has information in it, has received information which is in it about the user and the user's account.

[00:01:46] Speaker 05:
And that then information is entered into the terminal

[00:01:51] Speaker 05:
about the payee and the amount and that the token sends the information about the user to the terminal which creates the check and sends it back for a signature to the token and the token then forwards it to the terminal and the terminal sends it on.

[00:02:14] Speaker 05:
If that is the correct understanding of what Davies shows, do you lose?

[00:02:22] Speaker 02:
On that particular point, if it is true, this is issue two your honor, it is true that the customer identity field is stored in the blank check on the Davies token.

[00:02:35] Speaker 02:
If this field is read by the terminal, assembled into a check, and then returned to the token, then

[00:02:46] Speaker 02:
under MasterCard's theory that was apparently adopted by the board, it's not entirely clear, then that is what they say is the act of receiving information for identifying the accountant.

[00:02:59] Speaker 05:
Try to answer my question.

[00:03:01] Speaker 05:
I gave you a description of what my understanding is of what the board said about Davies.

[00:03:08] Speaker 05:
And if my description is correct, do you lose?

[00:03:12] Speaker 02:
If your description is correct, then we would lose on issue two.

[00:03:16] Speaker 02:
What issue would remain?

[00:03:18] Speaker 02:
Issue one, the single-party construction.

[00:03:21] Speaker 02:
And issue three, the fact that Davies does not disclose information for identifying the account of the payee.

[00:03:29] Speaker 02:
Those are separate issues.

[00:03:32] Speaker 02:
OK.

[00:03:32] Speaker 02:
So Your Honor, if you would take a look on this point at the red brief on page 34, this is the part of MasterCard's brief where they talk about the Davies system

[00:03:45] Speaker 02:
And there's no question that they say the receiving act of the account information for the first party takes place when a completed check comes from the terminal back to the token for signing.

[00:04:01] Speaker 02:
So they point to four statements.

[00:04:03] Speaker 05:
But the token has to have received, quite apart from that theory, the token has to have received information about the user, right?

[00:04:12] Speaker 02:
Because it has the information in the token.

[00:04:14] Speaker 02:
That's correct.

[00:04:15] Speaker 02:
And the problem, but that's not the end of the story.

[00:04:19] Speaker 02:
Because the claim itself has very strict sequencing requirements.

[00:04:23] Speaker 02:
For example, the claim steps must be performed in order.

[00:04:28] Speaker 02:
And furthermore, there must be a credential issued, we would say, before any of these steps occur.

[00:04:33] Speaker 02:
And so the pre-programming of the token with the customer identity field takes place by the card issuer's bank.

[00:04:42] Speaker 02:
And then that token is given to the customer.

[00:04:45] Speaker 02:
If that is what they also say is the previously issued credential limitation.

[00:04:53] Speaker 02:
So if you just say that the customer identity field being stored on the token is the act of receiving, then you trip up on what we say is a proper reading of the credential being previously issued.

[00:05:05] Speaker 02:
Because the field would be a position which the board rejected, right?

[00:05:09] Speaker 02:
The board rejected our construction of a credential being previously issued.

[00:05:15] Speaker 02:
And I would point out that is not MasterCard's theory.

[00:05:18] Speaker 05:
No, I understand.

[00:05:21] Speaker 02:
I understand.

[00:05:22] Speaker 02:
So what they're saying is the token receives this information when the customer identity field ping-pongs back and forth.

[00:05:29] Speaker 02:
If you look at what's on page 34, these are the four statements of Davies that they point to.

[00:05:35] Speaker 02:
And I would like to focus on the third point that they make, where it says the customer's request, i.e.

[00:05:41] Speaker 02:
an electronic check,

[00:05:43] Speaker 02:
is formed into a message and presented to the token.

[00:05:46] Speaker 02:
Davies does not equate a request with the electronic check.

[00:05:51] Speaker 02:
The request that the user could form at the terminal could only contain the variable information which is sent to the token.

[00:06:00] Speaker 02:
And at the token, the electronic check is assembled.

[00:06:04] Speaker 05:
But the point is... But the board interpreted, as I understand it, as saying that the terminal has the user information which it uses to prepare the electronic check, which is then sent back to the token for authorization.

[00:06:22] Speaker 02:
Your Honor, the board's decision on this point is two sentences long.

[00:06:26] Speaker 02:
And so they really don't make any factual findings about what Davies discloses.

[00:06:31] Speaker 02:
They simply say, let's look at the reply brief.

[00:06:33] Speaker 02:
And they do cite some points from Davies.

[00:06:36] Speaker 02:
But it's really this fourth point that drives the point home that Davies does not disclose a completed electronic check coming back from the terminal to the token.

[00:06:49] Speaker 02:
If you focus on point number four, it says the check enters the card, not the token.

[00:06:55] Speaker 05:
But the terminal has to have the user information, doesn't it?

[00:06:59] Speaker 05:
The terminal, in order to prepare the check, has to have the user information.

[00:07:06] Speaker 02:
Davies doesn't disclose that the terminal is the one that actually assembles the check.

[00:07:11] Speaker 02:
The blank check information, which includes the customer identity field, is stored on the token.

[00:07:16] Speaker 02:
Davies does not say, contrary to what MasterCard's position is,

[00:07:21] Speaker 02:
There's nothing in Davies that says this assembling process of a completed check in the token embodiment takes place at the terminal.

[00:07:28] Speaker 02:
It's not in there.

[00:07:29] Speaker 02:
And I would like to direct the board to this point in Davies.

[00:07:35] Speaker 05:
So your theory is that the terminal doesn't prepare the electronic check, but that the electronic check is prepared by the token, whereas the board found that the token just adds the signature?

[00:07:50] Speaker 02:
If you would take a look at page 41... But tell me... Yes, so our position is that Davies does not disclose the electronic check being fully completed at the token and then sent, I'm sorry, at the terminal and then sent back to the token for signing.

[00:08:07] Speaker 05:
The part of Davies that talks about that happening, which is shown... So your theory is the token prepares the electronic check based on limited information supplied by the terminal?

[00:08:18] Speaker 02:
The token has a blank check, so to speak, that includes customer information and bank information.

[00:08:24] Speaker 02:
All the token needs is the variable information.

[00:08:27] Speaker 02:
And one can speculate about how this happens in Davies, but the most logical thing to assume is that this variable information is input in the terminal and sent to the token where it's assembled and signed and then deposited into the system of Davies.

[00:08:43] Speaker 02:
If you look at Davies on page 41 of our blue brief,

[00:08:47] Speaker 05:
It sounds to me as though we're arguing about what Davies discloses, the board's interpretation of what Davies discloses, rather than some claim construction issue.

[00:08:58] Speaker 02:
Well, I would say it's a little bit deeper than on this particular point, Your Honor.

[00:09:01] Speaker 02:
On page 41 of the brief, this is the section of Davies.

[00:09:04] Speaker 03:
41 of your brief?

[00:09:07] Speaker 02:
Yes, Your Honor.

[00:09:07] Speaker 02:
I'm sorry, the blue brief.

[00:09:08] Speaker 02:
That's right.

[00:09:09] Speaker 02:
On page 41 of our blue brief, at the bottom of the page that we've indented, this is the section of Davies

[00:09:16] Speaker 02:
where MasterCard gets the position, the check enters the card from the terminal.

[00:09:22] Speaker 02:
And you'll see that this part of Davies says the smart card in its current form depends on a separate terminal for input and output.

[00:09:30] Speaker 02:
And this is a security risk in several ways.

[00:09:33] Speaker 02:
So what we're talking about here is a smart card system that Davies is saying is flawed and that Davies wants to improve upon by use of this token.

[00:09:44] Speaker 02:
Now, you get down to the check enters the card from the terminal, the part that I've underlined.

[00:09:49] Speaker 02:
MasterCard never, ever goes beyond that part of the sentence.

[00:09:54] Speaker 02:
They just put an ellipsis.

[00:09:55] Speaker 02:
But if you read the whole thing, it says the check enters the card from the terminal, and the card owner cannot be entirely sure what is being signed.

[00:10:03] Speaker 02:
So this is talking about a smart card embodiment that Davies is trying to improve upon through use of the token.

[00:10:11] Speaker 02:
If you go further down, it says, to avoid these serious risks, almost the whole signature operation should be under control of the owner of the secret key.

[00:10:21] Speaker 02:
The pin and keyboard should be part of the token.

[00:10:24] Speaker 02:
So the point here, your honor.

[00:10:26] Speaker 02:
I don't see that that contradicts the board's interpretation.

[00:10:29] Speaker 02:
Well, the point of this, your honor, is that you have a smart card system that Davies says, I want to make it better with a token.

[00:10:37] Speaker 02:
And the only disclosure Davies says,

[00:10:40] Speaker 02:
In the smart card, the completed check enters the smart card from the terminal, but it says that's a security risk.

[00:10:47] Speaker 02:
You don't want this information leaving the smart card or the terminal and being sent up to the token because then it leaves the possession of the secret key holder and you don't know what's being signed.

[00:10:59] Speaker 02:
So what Davey says is we're going to improve that with this token system where it's got a keyboard and a display so you can see what you're signing.

[00:11:07] Speaker 02:
The point of this is that MasterCard's theory is anticipation.

[00:11:11] Speaker 02:
And as this court is well aware, you have to show a single embodiment with all the limitations of the claim.

[00:11:18] Speaker 02:
And MasterCard's relying on part of a smart card embodiment that's being discredited by Davies for one part of the claim limitations.

[00:11:26] Speaker 02:
And for the other part, it's relying upon the token embodiment, two separate embodiments.

[00:11:31] Speaker 02:
And so that's a problem for MasterCard.

[00:11:36] Speaker 02:
Your Honor, if I could turn to the first issue, unless you had any further questions on that.

[00:11:42] Speaker 02:
Go ahead.

[00:11:43] Speaker 02:
So the first issue concerns Claim 51's four steps, and it's our position that all of these steps must be performed by the party that is authenticating the funds transfer information.

[00:11:57] Speaker 02:
There's an embodiment in the specification which shows otherwise, go ahead.

[00:12:00] Speaker 02:
Well, let's talk about that embodiment because the claim language of claim 51 expressly excludes that embodiment.

[00:12:07] Speaker 02:
And I can tell you why.

[00:12:09] Speaker 02:
In claim 51, the first step is receiving funds transfer information.

[00:12:14] Speaker 02:
And then each subsequent step acts on the received funds transfer information.

[00:12:20] Speaker 02:
So we're talking about claim 51 is dealing with the same set of information.

[00:12:26] Speaker 02:
Claim 51's third step is determining the authenticity of this information.

[00:12:31] Speaker 02:
So the information at issue may or may not be authentic.

[00:12:34] Speaker 02:
That's the point of the claim is you need this authenticating party to figure out if this information is authentic so it can transfer funds.

[00:12:43] Speaker 02:
In the patent, that authenticating party is the originator's bank who's shown in Figure 8B.

[00:12:49] Speaker 02:
And it's undisputed.

[00:12:50] Speaker 02:
MasterCard does not dispute that the claim steps read on the alternative embodiment where all these steps are performed by the originator's bank.

[00:13:00] Speaker 02:
Now, the fact that this information in Claim 51 may or may not be authentic excludes Figure 7 from consideration.

[00:13:08] Speaker 02:
Because as we said in our reply brief, the information that is input in Figure 7 is the gold standard information.

[00:13:15] Speaker 02:
That's the information you know is authentic.

[00:13:18] Speaker 02:
And what you're trying to figure out in this process is after it leaves the check originator in Figure 7, passes to a check recipient, then goes through a network and finally reaching the originator's bank.

[00:13:30] Speaker 02:
You want to know if someone's changed this information.

[00:13:33] Speaker 02:
And so when the originator's bank gets this information in Figure 8B, it says, is this information authentic?

[00:13:40] Speaker 02:
Is it the same as what was entered way back in Figure 7?

[00:13:44] Speaker 02:
And so Figure 7 is the gold standard.

[00:13:47] Speaker 02:
The information that is received in Claim 51 has to be the information received at the originator's bank, because it may or may not be authentic.

[00:13:56] Speaker 02:
And one other point on this.

[00:13:59] Speaker 02:
The claim step is receiving funds transfer information.

[00:14:03] Speaker 02:
That's the first step.

[00:14:04] Speaker 02:
And the third step is determining authenticity of the received funds transfer information.

[00:14:11] Speaker 02:
So the party that does the determination of the received funds transfer information is determining authenticity of what it received back in the first step.

[00:14:20] Speaker 02:
Not some information that a different party received at a far earlier point in time.

[00:14:26] Speaker 02:
Indeed, the originator's bank, it has no access to the information that was originally created in Figure 7.

[00:14:33] Speaker 02:
It only has access to the information it receives.

[00:14:36] Speaker 02:
And it's critical that the originator's bank determine authenticity of that information because that's the information it's being asked to pay upon.

[00:14:45] Speaker 02:
And so the information back in Figure 7 is the original information.

[00:14:50] Speaker 02:
The information in Figure 8B is the information that needs to be authenticated.

[00:14:54] Speaker 02:
And that's why Figure 7

[00:14:56] Speaker 02:
There's no receiving step that can apply to claim 51, because we know that information is the gold standard.

[00:15:03] Speaker 02:
It's not a disputed authenticity.

[00:15:06] Speaker 02:
And I see I'm running low on time.

[00:15:08] Speaker 02:
So unless you have any questions, I'll reserve the rest for rebuttal.

[00:15:17] Speaker 05:
OK.

[00:15:18] Speaker 01:
Mr. Williams?

[00:15:27] Speaker 01:
Thank you, Your Honor.

[00:15:28] Speaker 01:
It may please the court.

[00:15:28] Speaker 01:
Elliot Williams for MasterCard.

[00:15:33] Speaker 01:
I'll go in the same order that my opposing counsel did, which is to begin with the issue relating to Davies' disclosure.

[00:15:39] Speaker 01:
As to whether the board found that in Davies, the terminal prepares the check, sends it into the token, the token signs the check, and returns it to the terminal, there's no doubt the board made that finding.

[00:15:52] Speaker 01:
It's a finding that's supported by the text of Davies, as well as the testimony of our expert

[00:15:56] Speaker 01:
with Diffie, who the board explicitly relied on in its final written decision.

[00:16:01] Speaker 01:
So if you look, for instance, at A56, that's the final written decision.

[00:16:06] Speaker 01:
Excuse me, Appendix Page 56, that's the final written decision.

[00:16:11] Speaker 01:
Page 21 of the final written decision.

[00:16:13] Speaker 01:
The bottom of that page, there's a paragraph, the last full paragraph on the page, the last sentence of that says, Furthermore, Davies discloses that a terminal can be used to generate a check

[00:16:26] Speaker 01:
sign it with the aid of the token and send it to the beneficiary.

[00:16:29] Speaker 01:
That's a finding of fact that the board made in reaching its conclusion subsequently that Davies anticipates.

[00:16:36] Speaker 03:
And what in Davies supports that conclusion?

[00:16:42] Speaker 01:
Multiple things.

[00:16:47] Speaker 01:
So most of them are

[00:16:56] Speaker 01:
around pages 831 and 832 of the record.

[00:17:08] Speaker 03:
Well, I guess that question plus, I mean, what in the Davies reference discloses that the check comes back from the terminal?

[00:17:23] Speaker 01:
From the terminal or from the token?

[00:17:25] Speaker 01:
I'm sorry.

[00:17:25] Speaker 03:
Well, the check goes, if I understand it, from the terminal to the token for signature, right?

[00:17:32] Speaker 03:
Correct.

[00:17:33] Speaker 03:
Right.

[00:17:33] Speaker 03:
So what is it that?

[00:17:36] Speaker 03:
Give me Davies.

[00:17:37] Speaker 03:
Let's go at a level of generality that's farther back.

[00:17:40] Speaker 01:
OK, let's back up.

[00:17:42] Speaker 03:
What is the sequence of events that Davies describes with respect to where the check goes and where it doesn't go?

[00:17:48] Speaker 01:
Sure.

[00:17:48] Speaker 01:
So that's easiest to explain with respect to the figure on page 833 of the record.

[00:17:54] Speaker 04:
Yeah.

[00:17:55] Speaker 01:
which is figure 10.23 of Davies.

[00:17:57] Speaker 01:
And here he's depicting how the system would be used to do an ATM transaction.

[00:18:03] Speaker 01:
So you're withdrawing money.

[00:18:05] Speaker 01:
What he shows in figure 10.23, the bottom left side of that figure shows the token.

[00:18:11] Speaker 01:
This is the intelligent token.

[00:18:12] Speaker 03:
And the terminal is right above it.

[00:18:14] Speaker 01:
The terminal is above it.

[00:18:14] Speaker 03:
Along with the keyboard where you make the request.

[00:18:17] Speaker 01:
Correct.

[00:18:17] Speaker 01:
And so there's an arrow from that keyboard going into the token.

[00:18:21] Speaker 01:
That's the beginning of this process.

[00:18:23] Speaker 01:
So you go up.

[00:18:23] Speaker 01:
You say, I want to make a withdrawal.

[00:18:25] Speaker 01:
type in whatever you need to type in to start that process.

[00:18:29] Speaker 01:
That terminal then creates a check message, assembles the message appropriately for the request.

[00:18:34] Speaker 03:
When you say that the terminal then responds to the request, you key in the request.

[00:18:40] Speaker 03:
The terminal prepares, call it a check, call it a message.

[00:18:43] Speaker 03:
It's data that pertains to the transfer.

[00:18:47] Speaker 01:
Correct.

[00:18:47] Speaker 01:
And that data is shown in figure 10.22.

[00:18:50] Speaker 03:
And that goes to the token.

[00:18:51] Speaker 01:
to the token.

[00:18:52] Speaker 01:
And one of those things, for instance, would be the withdrawal amount.

[00:18:54] Speaker 01:
How much do you want to withdraw?

[00:18:55] Speaker 01:
You type that in.

[00:18:56] Speaker 01:
Otherwise, the machine has no idea.

[00:18:58] Speaker 01:
That goes into the token.

[00:19:00] Speaker 01:
The token then, the last thing that token needs to do to make that a check that can then be used to sign it.

[00:19:06] Speaker 01:
That's right.

[00:19:08] Speaker 03:
Whatever electronic devices used to do that.

[00:19:12] Speaker 01:
It makes a cryptographic calculation to do that.

[00:19:15] Speaker 01:
That's right.

[00:19:16] Speaker 01:
That is the signed message.

[00:19:17] Speaker 01:
Now, because it needs that data, or you're not going to get your money, you've got to sign that transaction using this token.

[00:19:23] Speaker 01:
It then goes back, and that's the arrow shown going up into the ATM.

[00:19:28] Speaker 01:
To the C. I'm sorry?

[00:19:29] Speaker 01:
To the C. Yeah, C crap.

[00:19:31] Speaker 01:
And then from there, that ATM, because in this particular example, it's not your bank.

[00:19:35] Speaker 01:
You're using someone else's bank to withdraw the money.

[00:19:37] Speaker 01:
The message has to go to your bank to verify that, yeah, you signed the message and that you have enough money to complete this withdrawal.

[00:19:43] Speaker 01:
So that's how Davies works in that show.

[00:19:46] Speaker 01:
For the details as to where the discussion of how the check is assembled appears, as I said, going back to appendix 831, the middle paragraph in that page that begins, a corporate customer, if you skip down about halfway through, there's a line that says, a terminal is needed in order to generate a check, sign it with the aid of the token, and send it to the beneficiary.

[00:20:12] Speaker 01:
And that's one clear place.

[00:20:15] Speaker 01:
This gets repeated again, for instance, on 832, the last two lines on that page, describing figure 1023.

[00:20:27] Speaker 01:
The customer's request is formed into a message and presented to the token.

[00:20:30] Speaker 01:
Here it is signed, et cetera.

[00:20:34] Speaker 01:
And then there's further description on 833 as well.

[00:20:42] Speaker 01:
So in any event, I think that more than sufficient evidence for the board to have concluded that in fact that's what happens in Davies, which is what they did conclude in the final written decision.

[00:20:53] Speaker 01:
Unless there's any questions about that issue, I'd like to return then to the claim construction issue.

[00:20:58] Speaker 01:
This one I think is fairly easy, although certainly appellant, is presented some creative arguments to make it look more difficult than it really is.

[00:21:10] Speaker 01:
Here we have a method claim

[00:21:12] Speaker 01:
It includes four steps.

[00:21:13] Speaker 01:
The method's not limited to any particular entity performing those steps.

[00:21:17] Speaker 01:
It doesn't say what entity has to perform the steps.

[00:21:20] Speaker 01:
It doesn't say that a single entity does have to perform all of these steps.

[00:21:24] Speaker 01:
And this court's law is clear that the inventor is entitled to the full scope of his claim.

[00:21:29] Speaker 01:
And you're not going to limit it to these embodiments from the specification, especially not ones that are not depicted in the figures and are described as alternative embodiments.

[00:21:40] Speaker 01:
Here, there's nothing in the claim that says a single entity has to perform these steps.

[00:21:44] Speaker 01:
If you read carefully the arguments that Appellant has made about their claim construction, you'll notice none of them actually require there'll be a single entity performing these steps.

[00:21:53] Speaker 01:
They make arguments about what individual words within these claim steps might mean and how the individual steps might have to operate on data together, but there's been

[00:22:03] Speaker 01:
No, claim construction has been proposed for any of those things.

[00:22:05] Speaker 01:
So for instance, you heard them talk about the gold standard and that some data here has to be the gold standard.

[00:22:11] Speaker 01:
That's not in the claim.

[00:22:12] Speaker 01:
Are they seeking a construction that would require that the data was, that the providence of the data was uncertain at some particular time in the claim?

[00:22:19] Speaker 01:
I mean, if that's their argument and they want to put that into the claim, they can argue for such a construction, but they haven't.

[00:22:25] Speaker 01:
All they've argued for is a construction that a single entity has to perform these four steps.

[00:22:30] Speaker 01:
Nothing in the claim language supports that.

[00:22:32] Speaker 01:
Nothing in the specification supports that, in fact, as we pointed out.

[00:22:36] Speaker 01:
As the board noted, the specification is inconsistent with such a reading, because there are two embodiments.

[00:22:41] Speaker 01:
And the specification makes clear that both of them are supposed to be within the scope of its transaction authentication scheme.

[00:22:54] Speaker 00:
So when you say that counsel make creative arguments, so I was listening to that.

[00:23:01] Speaker 00:
Let's just go back a little bit to the ATM example.

[00:23:07] Speaker 00:
How many entities are involved in that?

[00:23:12] Speaker 00:
You do acknowledge that there's at least one entity, right?

[00:23:15] Speaker 00:
Does someone make it?

[00:23:18] Speaker 01:
Yeah, I think in terms of if you look at Davies and look at where those four steps are performed in connection with that ATM example, then we argue that you could

[00:23:29] Speaker 01:
put all four of those steps as being performed by the originator's bank.

[00:23:33] Speaker 01:
So the person who's holding that card, the person who's throwing the money, actually it's their bank that's arguably doing all four of those steps because at least two of them are done in this token, in this intelligent smart card.

[00:23:46] Speaker 01:
That's not what the board found, right?

[00:23:48] Speaker 01:
Well, no, the board didn't because the board concluded, as it should have, that you don't need to show that all these steps are performed by the same entity.

[00:23:54] Speaker 01:
The board just said, no, the claim says there's four steps and Davies has four steps.

[00:23:58] Speaker 01:
They didn't need to go further.

[00:24:00] Speaker 01:
You only have to reach this question if you were to agree with Mr. Stambler's counsel that all four steps have to be performed by one entity.

[00:24:07] Speaker 01:
And then we had the alternative theory argued to the board that wasn't reached, that all four steps are performed by a single entity, meaning the originator's bank.

[00:24:16] Speaker 01:
Because that's the entity that programmed the smart card and put the key on there and designed the smart card to work in a certain way, and that receives the data on the back end and does the

[00:24:27] Speaker 01:
verification of the signature in order to authorize the funds transfer.

[00:24:30] Speaker 01:
So a single entity, so in other words, even if you would accept their construction, the board certainly could have found that all these entities, all these steps are performed by a single entity.

[00:24:39] Speaker 03:
You alluded to this point a moment ago, but I wanted you to expand on it if you would.

[00:24:42] Speaker 03:
The question that is raised by your opposing counsel about why it is that you would need to determine authenticity of

[00:24:53] Speaker 03:
received funds transfer information if that information is being provided at the first step when the user inputs that information, presumably authentic at that point.

[00:25:05] Speaker 01:
Well, I mean, the point of this whole system is to verify that the funds transfer information that ultimately shows up for redemption is valid.

[00:25:13] Speaker 03:
So what you're saying, I take it from that, is that when you refer to funds transfer information, you're referring to that funds transfer information in all of its iterations throughout the entire path that it follows.

[00:25:24] Speaker 01:
I am, and that is how the specification seems to be using the term as well, where it uses that same identification info in various places as this past has followed.

[00:25:33] Speaker 03:
So you would say, I take it, correct me if this is a misconstruction of your argument, but I understand you to be saying that the funds transfer information when it finally reaches a point at which there may have been some tampering, had better be the same as the funds transfer information that started out

[00:25:53] Speaker 03:
And that's the authentication process?

[00:25:56] Speaker 01:
That's right.

[00:25:57] Speaker 01:
I mean, keep in mind, this claim covers just the scenario where it does match.

[00:26:01] Speaker 01:
This is the claim that talks about you verified that it matches, and therefore you authorize the transaction.

[00:26:06] Speaker 01:
So in the case that the claim cares about, it wouldn't have changed.

[00:26:09] Speaker 01:
But obviously, the specification is trying to protect against the possibility that it might.

[00:26:13] Speaker 01:
So yes, that's right.

[00:26:14] Speaker 01:
I mean, I'll point out another thing about their argument, which is I think it goes too far.

[00:26:19] Speaker 01:
If you take the logic of their argument, then this claim wouldn't read on the other embodiment either, because the last element of claim 51 has you checking the van to determine if it's authentic.

[00:26:30] Speaker 01:
So this transferring a fun step in claim 51, the last piece of it, that's based on whether or not the van is authentic.

[00:26:37] Speaker 01:
Under their reading, the van would have been created immediately prior to the step being performed by the same entity that's doing the checking.

[00:26:43] Speaker 01:
So it would make no sense.

[00:26:44] Speaker 01:
The way they're reading this claim is so narrow that this claim would no longer make any sense at all.

[00:26:49] Speaker 01:
There's no reason to adopt that construction.

[00:26:51] Speaker 01:
The board certainly didn't.

[00:26:52] Speaker 01:
I think the more natural reading is just to say, yeah, what they mean here is these four steps in the way that the specification describes them, the two different ways the specification describes them.

[00:27:02] Speaker 01:
It's clear in the specification.

[00:27:04] Speaker 01:
Column two, for instance, talks about both ways in the summary of the invention and says they're both part of a transaction document processing, which avoids these prior art systems.

[00:27:18] Speaker 01:
There's no dispute that the way of doing this that's actually shown in the figures is one that involves multiple entities performing these steps.

[00:27:27] Speaker 01:
So the board's conclusion was imminently reasonable.

[00:27:31] Speaker 01:
And again, this is not a case where the broadest reasonable interpretation applies.

[00:27:35] Speaker 01:
The Phillips standard applies.

[00:27:36] Speaker 01:
But under any of this court's jurisprudence, the way the board construed this claim is very reasonable.

[00:27:44] Speaker 01:
And I would also point out, actually, in reaching, it is noteworthy, although we didn't address it in the briefs, which I concede.

[00:27:50] Speaker 01:
But the board did, in its claim construction, appear to rely on the testimony, on expert testimony, which would give further reasons to defer to what the board's construction was here.

[00:28:00] Speaker 01:
And you'll see that in the final written decision at appendix page 50, where in construing the claims, there was reference made to the Mr. Dibby's deposition testimony.

[00:28:14] Speaker 01:
So those are the two issues that were argued.

[00:28:16] Speaker 01:
If there's any other, unless there's any other questions, I can yield back the remainder of my time.

[00:28:21] Speaker 05:
No, thank you.

[00:28:21] Speaker 05:
Thank you, Mr. Williams.

[00:28:23] Speaker 05:
Mr. Ongarden, I think you have a little over two minutes here.

[00:28:26] Speaker 02:
Thank you, Your Honor.

[00:28:30] Speaker 02:
So there is no question, MasterCard agrees in the red brief and in the CBM, that this claim covers the situation where the originator's bank receives information, generates a new van,

[00:28:43] Speaker 02:
authenticates the information by comparing the van it regenerated in figure 8B to the original van in figure 7.

[00:28:51] Speaker 02:
And if those things check out, it transfers funds.

[00:28:54] Speaker 02:
Those four steps, it is agreed to by MasterCard and the board, are within the scope of claim 51.

[00:29:01] Speaker 02:
That is the alternative embodiment in our brief.

[00:29:04] Speaker 02:
Now, the preamble of this claim is a method for authenticating the transfer of funds.

[00:29:10] Speaker 02:
And notably, figure 8b and the alternative embodiment are described in the patents as the authentication process.

[00:29:17] Speaker 02:
If you look at figure 7, figure 7 is described as describing the check issuance process.

[00:29:24] Speaker 02:
And there are other claims, like claim 89, which is directed to a method for originating a check or payment instrument.

[00:29:33] Speaker 02:
So the preamble of these claims tells you that Mr. Stambler

[00:29:38] Speaker 02:
was familiar with his workflow, and he was claiming different parts of his invention with different claims.

[00:29:43] Speaker 02:
That's completely normal.

[00:29:45] Speaker 02:
Now, there was a suggestion that this info that flows through the system is always the same info.

[00:29:51] Speaker 02:
That could not be further from the truth.

[00:29:54] Speaker 02:
Consider the negative situation where the information is input by the originator, checked for $100.

[00:30:00] Speaker 02:
That goes to the recipient.

[00:30:02] Speaker 02:
He decides to add a few zeros.

[00:30:04] Speaker 02:
It's that fraudulent information that makes it

[00:30:07] Speaker 02:
to the originator's bank for authentication.

[00:30:10] Speaker 02:
And so when the originator's bank gets that, the patent absolutely considers this to be two separate sets of information.

[00:30:19] Speaker 02:
Look no further than block 60 in figure 8B, where you have two pieces of information that are put into a comparator to determine whether they're the same.

[00:30:31] Speaker 02:
So the patent absolutely considers the set of information received in 8B

[00:30:36] Speaker 02:
which is of disputed authenticity, to be different than the set of information input at the very beginning of this process, which is the gold standard.

[00:30:46] Speaker 02:
And so it's completely erroneous for MasterCard to say that it's the same information that flows through the patent.

[00:30:54] Speaker 03:
That is not... It's all funds transfer information.

[00:30:58] Speaker 03:
It may, at some point, as you suggest, be

[00:31:02] Speaker 03:
rendered fraudulent, but it still funds transfer information, right?

[00:31:09] Speaker 03:
Because if you say that the task here and the determining step is to determine whether at least a portion of the received funds transfer information is authentic, that contemplates that the information may be exactly the same as was initially input, or it may not, but it still funds transfer information, right?

[00:31:27] Speaker 02:
It still funds transfer information, but the point is that Claim 51

[00:31:31] Speaker 02:
doesn't talk about just funds transfer information, it talks about received funds transfer information that needs to be authenticated.

[00:31:39] Speaker 02:
And that information is received in the claims first step.

[00:31:43] Speaker 02:
So the party that does the authenticating in the claims third step is authenticating received funds transfer information

[00:31:50] Speaker 02:
that it got in the first step.

[00:31:52] Speaker 03:
But aren't you saying in effect that it needs to be authenticated under your construction at the initial stage as opposed to at some point during its travel through this sequence of transactions?

[00:32:02] Speaker 02:
Absolutely not.

[00:32:03] Speaker 02:
It must be authenticated when it reaches the originator's bank and they're asked to pay money on it.

[00:32:09] Speaker 02:
At the beginning of the transaction, when you issue a check that floats through this system and is passed from party to party,

[00:32:15] Speaker 02:
That information doesn't ever get authenticated until you get to the very end process where the originator's bank gets these instructions it receives and says, I have to authenticate this.

[00:32:26] Speaker 02:
But why is that a problem?

[00:32:28] Speaker 02:
That's determining authenticity.

[00:32:30] Speaker 02:
Correct.

[00:32:31] Speaker 02:
That's a problem for MasterCard and the board's construction because the claim is contemplating that this received funds transfer information may be fraudulent.

[00:32:40] Speaker 03:
Right, at the point at which it ultimately arrives at its destination.

[00:32:44] Speaker 02:
Correct.

[00:32:45] Speaker 03:
But why isn't that exactly what Davies does?

[00:32:48] Speaker 02:
That is not what... Well, that is why this claim has to be construed as requiring one party who authenticates the funds transfer information to perform all steps.

[00:33:00] Speaker 02:
And the problem with Davies is that the board relied on two different parties, the customer using its token and the customer's bank

[00:33:08] Speaker 05:
as each performing two of those steps.