[00:00:02] Speaker 04:
The next case for argument is 18-1491, straight path versus apt.

[00:01:12] Speaker 00:
We're ready.

[00:01:14] Speaker 00:
Good morning.

[00:01:17] Speaker 00:
There are two key points that the district court missed that preclude summary judgment in this case.

[00:01:24] Speaker 00:
First, this court's construction of is connected in sit net and Samsung, which all parties agree governs here requires a query as to whether the colleague is connected at the time the query is transmitted to the server.

[00:01:38] Speaker 00:
The district court ignored clear direct expert testimony that the accused products in this case query for and determine whether the callee is connected at the time the query is transmitted exactly as required by the court's construction.

[00:01:57] Speaker 00:
At 6573, Mr. Cole, straight paths expert with over 40 years experience in software development,

[00:02:08] Speaker 00:
This is at 6573 at the bottom in paragraph five.

[00:02:13] Speaker 00:
He testifies that the invite message in Cisco's accused products is sent by a caller device, the first process, seeking to find out whether a callee device is online at the time the query is transmitted to the server and ready to connect.

[00:02:33] Speaker 00:
At 6577, paragraph 17,

[00:02:39] Speaker 00:
Mr. Cole testifies that because the Cisco server only sends the invite message to the callee if the callee has an active registration, the server determines, in response to the query, not only that the callee endpoint was online at the time the query was transmitted, required by the court's claim construction, but it actually determines that the callee endpoint was online throughout the period from the time of the last registration

[00:03:09] Speaker 00:
which is before the invite was transmitted until the call the endpoint receives the invite messages.

[00:03:16] Speaker 00:
We have clear... Can I interrupt you for a minute?

[00:03:19] Speaker 05:
Yes.

[00:03:20] Speaker 05:
I mean, I see these paragraphs that you're pointing to.

[00:03:25] Speaker 05:
One question is, why aren't they conclusory?

[00:03:28] Speaker 05:
And just because he says, this is what the invite message does.

[00:03:33] Speaker 05:
And he doesn't cite to any evidence at all.

[00:03:35] Speaker 05:
Everybody agrees that an invite message is sent.

[00:03:38] Speaker 05:
But how does he know the intent of the invite message?

[00:03:41] Speaker 05:
What evidence is he relying on?

[00:03:43] Speaker 00:
Sure.

[00:03:43] Speaker 00:
This is not conclusory at all.

[00:03:45] Speaker 00:
So first of all, there's this declaration, and it cites to the expert report, which is over 100 pages, and relies on the testimony, the documents, and the source code.

[00:03:56] Speaker 00:
And he attaches appendices attached to it.

[00:03:58] Speaker 05:
Point me to the particulars that tell me what the purpose of the invite message is.

[00:04:04] Speaker 05:
He can even point me to code and tell me where I can find that.

[00:04:08] Speaker 00:
Sure, so let's start with Cisco.

[00:04:10] Speaker 00:
Cisco and Apple both operate the same way.

[00:04:12] Speaker 00:
Let's start with paragraph 376 at 6611.

[00:04:23] Speaker 00:
So at paragraph 376 at 6611, he is explaining that the invite message is seeking to find out whether the callee is

[00:04:33] Speaker 00:
endpoint is online and ready.

[00:04:35] Speaker 04:
Can you tell me where on this page you are somewhere?

[00:04:37] Speaker 00:
Yes, paragraph 376.

[00:04:39] Speaker 00:
It's about... Oh, okay.

[00:04:41] Speaker 00:
I see.

[00:04:41] Speaker 00:
So the first line is, the invite is seeking.

[00:04:44] Speaker 00:
The invite is sent when a caller endpoint is seeking to create a real-time point-to-point call.

[00:04:50] Speaker 00:
Such connection cannot be made.

[00:04:51] Speaker 00:
The invite message is therefore a query as to whether a callee endpoint is connected

[00:04:57] Speaker 00:
to the computer network at the time the query is transmitted.

[00:05:01] Speaker 04:
Can you clarify for me, because I don't know where I'm getting this from.

[00:05:04] Speaker 04:
I think this was maybe in the district court's opinion who noted that your expert admitted in deposition that the accused server cannot determine whether or not the callee is actually connected to the computer network at the moment in time that the caller sends an invite message to the server.

[00:05:22] Speaker 00:
It is true that the server does not know already

[00:05:27] Speaker 00:
at the time that it receives the query, whether it's connected.

[00:05:32] Speaker 00:
Instead, what it does, according to Cole and even their experts, what it does is it checks to determine whether it's connected at that time.

[00:05:41] Speaker 05:
It tries to initiate a call.

[00:05:43] Speaker 00:
No.

[00:05:43] Speaker 05:
With the process, too.

[00:05:45] Speaker 00:
No.

[00:05:45] Speaker 00:
That is the critical difference that the district court absolutely missed, and I'll take you through that.

[00:05:51] Speaker 00:
So it does not try to initiate the call.

[00:05:57] Speaker 00:
is signaling connection.

[00:05:58] Speaker 00:
I can show you with respect to the figure if you'll allow me.

[00:06:02] Speaker 00:
So if you'll go to 655-88 with me.

[00:06:10] Speaker 00:
This check to determine, I'll show you, occurs before the IP address is provided and before the point-to-point line is attempted to be established.

[00:06:21] Speaker 00:
And that's the critical thing that the district court missed.

[00:06:25] Speaker 00:
On 6558, we have the figure that shows the Cisco flow diagram.

[00:06:31] Speaker 00:
There's a similar one for Apple.

[00:06:33] Speaker 03:
Is this confidential information?

[00:06:35] Speaker 03:
Yes.

[00:06:36] Speaker 03:
It's marked.

[00:06:37] Speaker 00:
It is not.

[00:06:39] Speaker 00:
No.

[00:06:40] Speaker 00:
There was a question as to whether it was.

[00:06:41] Speaker 00:
They withdrew their objection.

[00:06:43] Speaker 00:
It's in the appendix.

[00:06:46] Speaker 04:
Can we get some confirmation from Cisco on that?

[00:06:48] Speaker 04:
Is that correct?

[00:06:49] Speaker 04:
It's not confidential.

[00:06:50] Speaker 04:
Thank you.

[00:06:50] Speaker 04:
So it's not confidential.

[00:06:52] Speaker 00:
OK.

[00:06:54] Speaker 00:
On the left, phone 1000 is the caller.

[00:06:57] Speaker 00:
In the middle, CCM is the server.

[00:06:59] Speaker 00:
And on the right, phone 2000, that's the callee.

[00:07:03] Speaker 00:
At line 10, there's a message invite.

[00:07:07] Speaker 00:
It's message one.

[00:07:08] Speaker 00:
You see one in brackets at invite.

[00:07:11] Speaker 00:
That is the query from the caller to the server that Mr. Cole testified is the query as to whether it's connected at the time of the query.

[00:07:21] Speaker 00:
In response to that, the server sends messages to the callee.

[00:07:26] Speaker 00:
That is message 11 that you see around line 16.

[00:07:30] Speaker 00:
That causes the phone to ring.

[00:07:35] Speaker 00:
And if the callee answers, a 200 OK comes back.

[00:07:40] Speaker 00:
OK.

[00:07:41] Speaker 00:
So it's conditioning causes the phone to ring.

[00:07:43] Speaker 00:
No, it causes the phone to ring.

[00:07:45] Speaker 00:
But at this point in time, it is undisputed, Your Honor, and this is critical.

[00:07:49] Speaker 00:
that there is no point-to-point line established.

[00:07:53] Speaker 00:
When the callee picks up the phone and answers, the caller and callee are not connected.

[00:08:00] Speaker 00:
At this point... I understand.

[00:08:01] Speaker 05:
When the person answers, then it says, OK, you answered.

[00:08:04] Speaker 05:
That means you must be online.

[00:08:06] Speaker 00:
That's right.

[00:08:07] Speaker 00:
And the server determines that you're online at that point.

[00:08:10] Speaker 00:
And then and only then, in the message 17200 OK, does the server provide the IP address to the caller?

[00:08:20] Speaker 00:
which the caller then uses at line 22 to establish the media cut-through.

[00:08:25] Speaker 00:
That media cut-through is the point-to-point line that the caller is establishing with the callee.

[00:08:33] Speaker 00:
That's what carries the voice.

[00:08:34] Speaker 00:
That's the media line that's not mediated.

[00:08:37] Speaker 05:
Sorry to interrupt you.

[00:08:38] Speaker 05:
Where's the last step?

[00:08:40] Speaker 05:
I was with you at number 15, which is 200, OK?

[00:08:44] Speaker 05:
What was the next step that you were making?

[00:08:46] Speaker 05:
Because this is very helpful, so thank you.

[00:08:49] Speaker 00:
Thank you.

[00:08:51] Speaker 00:
Upon receiving the 200 OK message 15, the server determines that the callee is online, was online at the time of the query.

[00:09:00] Speaker 00:
Then and only then, the server sends message 17 at line 21.

[00:09:06] Speaker 00:
That's the 200 OK.

[00:09:09] Speaker 00:
That 200 OK is what contains the IP address for the callee.

[00:09:14] Speaker 00:
And only then can they connect directly, which carries the voice.

[00:09:18] Speaker 00:
All of this is absolutely transparent to the person, the caller and callee, but that's what's happening behind the scenes.

[00:09:25] Speaker 00:
So if you look at the page 6557, the triangle diagram, this shows caller A, caller B, and the server in the middle is the call.

[00:09:36] Speaker 00:
The two legs are signaling connections.

[00:09:38] Speaker 00:
Those are the setup signal.

[00:09:40] Speaker 00:
And the media line,

[00:09:42] Speaker 00:
is what happens between A and B. That's the media cut through.

[00:09:45] Speaker 00:
And so everything that occurs up to message 15 is set up signaling with the server.

[00:09:52] Speaker 00:
They're not connected yet.

[00:09:55] Speaker 00:
And then, and only then, does the server provide the IP address so that they provide the media cut through.

[00:10:01] Speaker 00:
This is the critical point that the district court just missed.

[00:10:06] Speaker 00:
He thought that the call was connected when the person picks up the phone.

[00:10:12] Speaker 00:
This is the difference between the prior ART and the accused products.

[00:10:20] Speaker 00:
In the prior ART, both systems have registration databases.

[00:10:24] Speaker 00:
But in the prior ART, when there was a query, is it registered, WINS and NetBIOS, which were the prior ART references, provided the IP address.

[00:10:33] Speaker 00:
They didn't do anything else.

[00:10:35] Speaker 00:
They didn't check online status.

[00:10:36] Speaker 00:
And so they didn't answer the question, is it connected at the time of the query?

[00:10:41] Speaker 00:
That's the difference.

[00:10:42] Speaker 00:
The accused products both check to determine that the callee is still online, that it was online at the time of the query, before providing the IP address.

[00:10:56] Speaker 00:
By calling the person.

[00:10:58] Speaker 00:
That's right.

[00:10:59] Speaker 00:
By ringing the phone, that's all signaling with the server only.

[00:11:04] Speaker 00:
And that's the whole point of this invention.

[00:11:07] Speaker 00:
This invention is to establish the point-to-point call where you have two

[00:11:12] Speaker 00:
endpoints with dynamic IP addressing.

[00:11:15] Speaker 00:
Dynamic IP addressing means every time you connect, you get a different IP address.

[00:11:19] Speaker 00:
So if I want to call you, Your Honor, I don't know your IP address.

[00:11:23] Speaker 00:
I need the server to tell me.

[00:11:25] Speaker 00:
But before the server gives me your IP address to call, the invention is to make sure that you're actually online.

[00:11:34] Speaker 04:
And this is all supposed to be happening at the same time.

[00:11:37] Speaker 04:
Time was the underpinning for the claim construction and for allowing your

[00:11:42] Speaker 04:
claims to be held.

[00:11:44] Speaker 00:
The time of what's determined, what is required.

[00:11:49] Speaker 00:
There is a temporal requirement, but the temporal requirement is determining that the callee was online at the time of the query.

[00:12:00] Speaker 00:
It's not determined.

[00:12:02] Speaker 00:
Is online at the time of the query.

[00:12:04] Speaker 00:
Is online at the time of the query.

[00:12:05] Speaker 00:
It's not requiring when that determination is made or how that determination is made.

[00:12:10] Speaker 00:
And the record is actually clear that how that determination is made, how the server determines it.

[00:12:16] Speaker 05:
You're saying it's okay if it's a retroactive determination, or the determination that occurs later so long as it's retroactively accurate?

[00:12:24] Speaker 00:
As long as it's retroactively determining the right thing that it was online at the time.

[00:12:30] Speaker 04:
You know, among other things, we said in our SIPnet case, the present tense is connected to the computer network.

[00:12:39] Speaker 04:
Plainly says that the query transmitted to the server seeks to determine whether the second unit is connected at that time, i.e.

[00:12:47] Speaker 04:
connected at the time the query is set.

[00:12:50] Speaker 00:
That's right.

[00:12:51] Speaker 04:
So the question is supposed to be answered at the time.

[00:12:57] Speaker 00:
What the query requires is

[00:12:59] Speaker 00:
Is it connected at the time of the query?

[00:13:03] Speaker 00:
And Mr. Cold explained that the system queries for that and determines not only that it is connected at the time of the query, but it actually has been connected from just before that to just after that.

[00:13:15] Speaker 00:
It is answering the right question.

[00:13:17] Speaker 00:
When the query is made, that's when the communication is sought.

[00:13:23] Speaker 05:
One of the things that I read, and I can't remember if it was in the patent or in your expert's testimony,

[00:13:29] Speaker 05:
is that the whole purpose of this invention is to make sure that there's no actual connection prior to an incurring of charges, for example.

[00:13:43] Speaker 05:
And that's why you want to go ahead and make sure that the callee is online.

[00:13:49] Speaker 05:
That's right.

[00:13:49] Speaker 05:
That's why you have this check.

[00:13:51] Speaker 00:
And this does that.

[00:13:52] Speaker 05:
When you're calling the callee in order to actually see if the callee is online, how is that purpose satisfied?

[00:14:00] Speaker 00:
The server is sending signaling messages, which are cheap and easy, to the callee.

[00:14:06] Speaker 00:
What is difficult and what is saved is trying to establish that media connection, that media cut through, that point to point connection.

[00:14:16] Speaker 00:
And while Apple says we have false registrations and there are billions of times that the server tries to connect to stale IP addresses,

[00:14:27] Speaker 00:
None of those stale IP addresses are provided to the caller device.

[00:14:30] Speaker 00:
My phone never tries to reach out, is never given a stale IP address and never tries to establish a connection, a point-to-point connection with the stale IP address.

[00:14:41] Speaker 05:
Mr. Cole explains- But it does try to establish an indirect connection.

[00:14:46] Speaker 00:
I mean, at least- No, the server does.

[00:14:47] Speaker 05:
It goes to the server and then the server establishes a connection.

[00:14:51] Speaker 05:
The server does, but this is critical because- Right?

[00:14:53] Speaker 05:
I'm sorry.

[00:14:54] Speaker 05:
The server establishes a connection.

[00:14:55] Speaker 05:
It calls.

[00:14:57] Speaker 00:
No, the whole point of this is to use a server to help the caller and callee establish an unmediated media connection.

[00:15:07] Speaker 00:
That's the point to point.

[00:15:09] Speaker 05:
Can you point to me in your specification where this is disclosed, all of this, and where the purpose of the invention is disclosed?

[00:15:16] Speaker 05:
Because I read your specification, and I see where you've got that database environment and embodiment that's disclosed.

[00:15:24] Speaker 05:
But I don't see a whole lot else about this

[00:15:27] Speaker 05:
claimed invention in the specification?

[00:15:37] Speaker 00:
What the specification is primarily aimed at is helping to establish a point-to-point connection where you have dynamic IP addresses.

[00:15:51] Speaker 00:
The is connected was not specifically drawn out as that

[00:15:56] Speaker 00:
the benefit of that.

[00:15:57] Speaker 00:
I don't think that's specifically disclosed here.

[00:16:00] Speaker 00:
That came out in the process of distinguishing the prior art in the IPRs and in the subsequent appeals.

[00:16:11] Speaker 00:
And the benefit, we have to look at the claim.

[00:16:14] Speaker 00:
And the claim is issuing a query for is it connected and doing that before providing the IP address.

[00:16:23] Speaker 05:
Do you have an embodiment disclosed in which the query is accomplished by doing something other than looking at a database?

[00:16:31] Speaker 00:
So there is the secondary protocol, Your Honor, and that secondary protocol is, it's described at column six, starting at lines 17, and if you look at line 55, this is the mail server.

[00:16:47] Speaker 05:
Should I look at a particular version?

[00:16:48] Speaker 05:
I know that you have multiple patents.

[00:16:49] Speaker 05:
Is the particular patent?

[00:16:51] Speaker 00:
I'm looking at the 704.

[00:16:53] Speaker 00:
The 704, column 6, line 55, the mail server then pulls the second processing unit, for example, every three to five seconds to deliver the email.

[00:17:02] Speaker 00:
So that embodiment was specifically discussed, acknowledged by the SIPNET court before finding plain and ordinary meaning.

[00:17:15] Speaker 00:
So there was no clear and unmistakable disclaimer of anything that didn't have a database.

[00:17:20] Speaker 00:
In fact, Mr. Wodarski, in

[00:17:23] Speaker 00:
Judge Prost's panel that issued the Samsung opinion specifically says not all embodiments describe the require checking a database.

[00:17:36] Speaker 03:
There's this colloquy with Judge Dyke in the SIPNAP case.

[00:17:39] Speaker 00:
I'm sorry?

[00:17:40] Speaker 03:
There's this colloquy with Judge Dyke and Consul and SIPNAP.

[00:17:44] Speaker 00:
Sure, but there's never... Always checking.

[00:17:47] Speaker 00:
Yes, but there's never...

[00:17:48] Speaker 00:
And in that case, they were discussing why the prior art, which only checked a database and didn't do anything more, was different than the embodiment in the specification, which has an accurate database.

[00:18:00] Speaker 00:
And they said, the difference there is, if you're only checking a database, it's got to be accurate.

[00:18:06] Speaker 00:
You have to check.

[00:18:07] Speaker 00:
You have to track.

[00:18:08] Speaker 00:
But then your honor's opinion and Samsung specifically embraced not only that the prior art, that the plain meaning is right,

[00:18:16] Speaker 00:
but specifically embrace that it includes tracking or checking to determine, right?

[00:18:25] Speaker 00:
So the Samsung opinion, it's in our appendix at 37073, Judge Pro's opinion is the board's determination is supported by substantial evidence, Strait Path argues, because quote, not only is the prior art not designed to keep track,

[00:18:46] Speaker 00:
of current online status.

[00:18:48] Speaker 00:
It is not designed to check online status when responding to a query for a user's IP address.

[00:18:55] Speaker 00:
We agree with Straight Path.

[00:18:58] Speaker 00:
There is no limitation in the claims for a database.

[00:19:02] Speaker 00:
The database is not even recited in any of the asserted claims.

[00:19:06] Speaker 00:
There is no limitation in the claims as to how the server makes the determination.

[00:19:11] Speaker 00:
What's required is that the query be to the server and when responding,

[00:19:16] Speaker 00:
the server check that it is online, that it was online at the time of the query, before providing the IP address so that the caller device is not trying to establish this expensive point-to-point media cut-through with the stale IP address.

[00:19:33] Speaker 04:
OK, we're way over time.

[00:19:34] Speaker 04:
Will we stir a summary battle?

[00:19:35] Speaker 04:
Let's hear from the other side.

[00:19:37] Speaker 04:
Thank you very much.

[00:19:39] Speaker 04:
Mrs. Stetson, you're up first.

[00:19:43] Speaker 01:
Thank you, Your Honors.

[00:19:44] Speaker 01:
May it please the Court.

[00:19:44] Speaker 01:
I'm Kate Stetson.

[00:19:45] Speaker 01:
I'm arguing for Apple today, and I'm splitting my time with Mr. Damaris.

[00:19:49] Speaker 01:
I want to start where my friend on the other side started, because I think there are a few words in the claim construction that this Court offered that have dropped out of the colloquy a little bit.

[00:20:00] Speaker 01:
The claim construction that this Court arrived at in Straight Path in the Cipnat case is a query as to whether the second process is connected to the computer network means

[00:20:10] Speaker 01:
is connected to the computer network at the time that the query is transmitted to the server.

[00:20:18] Speaker 01:
The temporal element of that, I think, has been what's been lost here.

[00:20:23] Speaker 01:
The new argument that you're hearing today is that despite the entire way that this case was framed the last two times it has come up to this court, now the argument is it's OK if a system doesn't track registrations

[00:20:40] Speaker 01:
as long as it can check something.

[00:20:43] Speaker 01:
And these two inventions, straight path contends, check something.

[00:20:47] Speaker 05:
Can you speak up just a little bit?

[00:20:49] Speaker 01:
Certainly.

[00:20:50] Speaker 01:
Thank you.

[00:20:50] Speaker 01:
They check something by calling the callee device, sending an invite push, and asking that callee device, this is the Apple system now, asking that callee device, would you like to take this call?

[00:21:04] Speaker 01:
Only if the answer to that question is yes,

[00:21:08] Speaker 01:
by the callee picking up the call, does the server, quote unquote, determine that the callee is online?

[00:21:15] Speaker 05:
So let's say the callee decides, hey, I just don't have time right now to take this call.

[00:21:20] Speaker 05:
Then the server would think that the person's offline?

[00:21:24] Speaker 01:
The server, nothing would come back to the server in that instance.

[00:21:28] Speaker 01:
And that's one of the problems here, is that the question that is being posed to that callee device is not, are you online?

[00:21:35] Speaker 01:
Just as you said, Judge Dole.

[00:21:36] Speaker 01:
There could be many circumstances.

[00:21:38] Speaker 05:
The server doesn't care if you're online or offline.

[00:21:40] Speaker 01:
It's just calling.

[00:21:40] Speaker 01:
The server does not care if you're online.

[00:21:42] Speaker 05:
And more importantly... Is there any evidence at all that, you know, in Apple's documents that was brought forward that said anything about that invite message being the purpose of it being to determine whether the callee is online?

[00:21:59] Speaker 01:
No.

[00:22:00] Speaker 01:
I mean, the invite message is an invitation to join a call.

[00:22:04] Speaker 01:
And you heard my friend on the other side actually said a couple things in his colloquy with you that goes right to this point.

[00:22:11] Speaker 01:
The server, when it makes that invite push in the Apple system, and this is a quote, the server does not know already whether that callee is online or not.

[00:22:22] Speaker 01:
When the callee answers and that message is transmitted back, that is the point, according to Straight Path, where the server determines that the callee is online.

[00:22:32] Speaker 01:
But I think, Judge Stoll, you also made the point that there's not a site in the expert's recitation at page 6611 for this idea that- It seems to be an inherency kind of argument, I guess, that, well, of course, if you call the person and they answer, then you must know their own line.

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

[00:22:52] Speaker 01:
And I think that's why I think the phrase the district court used to describe that was astonishingly overbroad.

[00:22:58] Speaker 01:
It's also the wrong question.

[00:23:00] Speaker 01:
The question is not, are you willing to accept my call?

[00:23:04] Speaker 01:
The question is, are you online?

[00:23:06] Speaker 01:
But the important thing here, I think, too, is at page 6611, what Straight Paths expert says is, because of this series of messages that we've been talking about, when that callee picks up that call and signals that she's online, then the server determines that the callee is online at the time the query is transmitted to the server.

[00:23:29] Speaker 01:
is completely unsupported by anything in the record.

[00:23:32] Speaker 05:
I think what your adversary's argument is that when the person picks up and the response is sent back to the server, then server is told, at the time of your query, I was online because I'm online now, several seconds later, even a minute later.

[00:23:50] Speaker 05:
So I must have been online before.

[00:23:52] Speaker 05:
I think that's what his argument is.

[00:23:54] Speaker 01:
I think that is.

[00:23:55] Speaker 01:
The problem is that that runs straight back into the claim construction that this court offered in CIPNET.

[00:24:03] Speaker 01:
The query has to be, and this is the phrase that the panel used, calling for present status information.

[00:24:09] Speaker 01:
At the time the query is transmitted to the server,

[00:24:12] Speaker 01:
What is the present status of this person?

[00:24:14] Speaker 01:
Not, is this person going to be online in a few seconds?

[00:24:17] Speaker 01:
Is this person going to pick up the phone in 30 seconds after it rings for a while?

[00:24:21] Speaker 01:
What is the present online status of this person?

[00:24:24] Speaker 01:
Now, this whole question about tracking versus checking, which has become now the focus of Straight Path's argument this third time up, I think is a red herring, precisely for the reasons we've been talking about.

[00:24:37] Speaker 01:
But more importantly, when we talk about tracking versus checking,

[00:24:42] Speaker 01:
There are a couple points, I think, on which we would agree with Straight Path.

[00:24:47] Speaker 01:
The checking the database, what Mr. Wodarski, Straight Path's counsel, said in the earlier argument is that you don't need perhaps a database.

[00:24:56] Speaker 01:
This is a Joint Appendix 7205.

[00:24:59] Speaker 01:
But you do need some way to constantly keep track of status.

[00:25:03] Speaker 01:
And what he said was constant pinging, constant checking.

[00:25:07] Speaker 01:
So you may not need a memory such as a database, which is the way the patent frames this.

[00:25:14] Speaker 01:
But the server has to have the capability to know at the time the query is transmitted to the server whether someone is or is not online, not whether someone chooses at some subsequent point in time, 20 seconds later, to pick up a call.

[00:25:29] Speaker 01:
Because that is the wrong question.

[00:25:31] Speaker 05:
Do you know how the prior art worked, the prior art that they were attempting to distinguish during the IPR?

[00:25:37] Speaker 05:
How did that work?

[00:25:37] Speaker 05:
I mean, it had a database that had, I guess, old data in it, not exactly current, relatively current data.

[00:25:47] Speaker 05:
So what did it do after that step?

[00:25:49] Speaker 05:
Do you know?

[00:25:50] Speaker 05:
Did it try to initiate a call?

[00:25:53] Speaker 01:
Yes, is the short answer.

[00:25:54] Speaker 01:
And you can actually find this in the Samsung opinion.

[00:25:57] Speaker 01:
So this is 696 Federal Appendix, page 1012.

[00:26:04] Speaker 01:
It discusses both the wins and net bios systems.

[00:26:09] Speaker 01:
And one of the points that the Samsung opinion makes is, in each system, once the registration database is checked, which is what happens in the Apple system as well, once the IP, and I'm quoting now, addresses have been found for a target name, a net bios session service begins.

[00:26:29] Speaker 01:
The net bios session service involves directed point-to-point communications.

[00:26:34] Speaker 01:
and so too with the WINS network.

[00:26:36] Speaker 01:
So this whole kind of fiction that NetBIOS and WINS were just about checking registration databases is not accurate.

[00:26:43] Speaker 01:
Those were recitations that this court drew from the PTAB proceedings that preceded that particular opinion.

[00:26:52] Speaker 01:
So the difference here, I think, is, and this is an observation a prior panel member made to Straight Paths Council, what Straight Paths Council was able to preserve

[00:27:04] Speaker 01:
is very, very narrow.

[00:27:06] Speaker 01:
What Straight Paths Council was able to preserve against a challenge of obviousness was this idea that when a caller asks a server, is the callee online at the time of my query, the server has to know the answer.

[00:27:23] Speaker 01:
The server can check a database.

[00:27:25] Speaker 01:
The server can constantly ping all of the registered devices.

[00:27:28] Speaker 01:
But the server has to know the answer, not at some point 30 seconds later.

[00:27:33] Speaker 03:
Thank you.

[00:27:35] Speaker 01:
Thank you.

[00:27:35] Speaker 02:
Thank you, Your Honors.

[00:27:44] Speaker 02:
May it please the Court, John Damaris for Cisco.

[00:27:47] Speaker 02:
With respect to the Cisco system, this case is very straightforward based on the admissions that Strait Paths expert Cole made.

[00:27:55] Speaker 02:
First, Cole admitted that Cisco's servers have stale IP addresses.

[00:28:01] Speaker 02:
There's no dispute about that, just like the NetBios and WinSystem.

[00:28:05] Speaker 02:
Second, Cole admitted that at the time of the query, which is the claim construction, which is the language, at the time of the query, Cisco servers do not know if the called phone is online.

[00:28:17] Speaker 02:
Lastly, Cole admitted that the 200 OK message that they rely on as a response to the query didn't even exist at the time of the query.

[00:28:28] Speaker 02:
The claim language requires an answer at the time of the query

[00:28:31] Speaker 02:
The 200 OK message didn't even exist at that time.

[00:28:34] Speaker 02:
And Cole admitted that that 200 OK message is not even created.

[00:28:39] Speaker 02:
It doesn't even come into existence until they answer the phone.

[00:28:42] Speaker 05:
How do you respond to your adversary's argument that at the time the query of the query language refers to when it's connected?

[00:28:53] Speaker 05:
In other words, that the answer to that question can be answered later, 30 seconds later,

[00:29:01] Speaker 05:
And you know from the fact that it's connected 30 seconds later that it must have been connected 30 seconds earlier at the time of the query.

[00:29:11] Speaker 02:
There's a couple answers to that.

[00:29:12] Speaker 02:
Number one, the language of the construction defeats that argument entirely because when you look at the construction, it says at the time that the query is transmitted to the server.

[00:29:24] Speaker 02:
So the query going from the server is from the calling phone to the server.

[00:29:28] Speaker 02:
That's the query time.

[00:29:29] Speaker 02:
And that happens, the claim construction requires you to have an answer at that time when that query gets to the server.

[00:29:36] Speaker 04:
So you can't figure it out and apply the answer retroactively, retrospectively?

[00:29:40] Speaker 02:
Well, no, it doesn't even work in this case retrospectively, because they have no proof that just because somebody answered the phone that they were online earlier.

[00:29:48] Speaker 02:
It happens all the time in these systems where people go offline and online.

[00:29:52] Speaker 02:
As long as they're online when the phone starts to ring, it doesn't mean they were online at the time the query went to the server.

[00:29:57] Speaker 02:
They have no proof of that.

[00:29:58] Speaker 02:
They're relying entirely on their expert's inference, which isn't based on anything.

[00:30:03] Speaker 02:
But if you think about just stepping out practically, think about what they're actually arguing here.

[00:30:08] Speaker 02:
He took you through the call flow in the appendix.

[00:30:11] Speaker 02:
What's happening there in the Cisco systems?

[00:30:14] Speaker 02:
These are telephones.

[00:30:15] Speaker 02:
These are regular handsets with numbers.

[00:30:18] Speaker 02:
They're arguing that because you dial that phone, because somebody on their other side hears the ring and picks it up,

[00:30:24] Speaker 02:
that that is somehow answering a query as to whether you're online.

[00:30:28] Speaker 02:
It doesn't even make any sense.

[00:30:30] Speaker 02:
What the invention was about is you're supposed to know before you make the call to the callee phone, as your honor said, so that you could save the resources.

[00:30:42] Speaker 05:
Where will I find that in the record?

[00:30:45] Speaker 05:
What you just said.

[00:30:46] Speaker 02:
That's in Dr. Cole's testimony, and it's also in the district court's opinion.

[00:30:52] Speaker 05:
I saw it in the district court's opinion, but I don't see it in the specification.

[00:30:56] Speaker 02:
Yeah, it's not in the PAT.

[00:30:59] Speaker 02:
They're experts at it.

[00:31:00] Speaker 02:
You won't find it in the PAT, but you'll find it.

[00:31:02] Speaker 05:
Do you have a site for Cole's testimony?

[00:31:04] Speaker 02:
I do.

[00:31:04] Speaker 02:
I do, yes, Your Honor.

[00:31:24] Speaker 02:
I did.

[00:31:26] Speaker 02:
Give me a moment and I'll come back to it because there's another point I want to make.

[00:31:28] Speaker 02:
I will get to the site.

[00:31:32] Speaker 02:
The reason why the Cisco system, the way the setup goes with your answering the phone cannot be a query.

[00:31:38] Speaker 02:
If you think about how that system works, a person who wants to make a call picks up the phone and dials the numbers.

[00:31:45] Speaker 02:
That then goes out and goes to the database and gets an old stale address and then tries to make the call.

[00:31:53] Speaker 02:
Four things can happen at that point.

[00:31:55] Speaker 02:
The address is wrong, and the call doesn't get made.

[00:31:58] Speaker 02:
The phone rings, but nobody's there to answer it.

[00:32:01] Speaker 02:
Or your home, and the phone's ringing, and you decide you don't want to pick it up.

[00:32:05] Speaker 02:
Or you pick it up and answer.

[00:32:07] Speaker 02:
It's only in that last option where you pick up the phone and answer that the 200 OK goes.

[00:32:14] Speaker 02:
So in all those other scenarios where if it's a stale address, or if the phone rings and nobody answered it, or somebody chooses not

[00:32:20] Speaker 02:
There's no 200 OK go back.

[00:32:22] Speaker 02:
That's not an answer to a query of whether you're online, because you are online in two of those scenarios where you don't answer the ringing phone, and you're offline when the address is wrong.

[00:32:33] Speaker 02:
But none of that information goes back to the server.

[00:32:36] Speaker 02:
This is not what the invention is about.

[00:32:38] Speaker 02:
This invention was about finding out if somebody is online at the time you make the call.

[00:32:44] Speaker 02:
And in particular, if you look at the things that

[00:32:48] Speaker 02:
the plaintiff said in the prior litigations here with respect to tracking.

[00:32:55] Speaker 02:
This is from the SIPNET briefing that went up to this court.

[00:33:02] Speaker 02:
They said, the claimed query to determine whether a process is currently connected to the computer network at the time of the query requires the connection server to perform at least a two-step protocol requires, they said.

[00:33:17] Speaker 02:
to track when the process connects to the computer and when the process disconnects to the computer.

[00:33:23] Speaker 02:
Without performing that second step, the connection server could not know whether a process had gone offline and could therefore only determine whether the process had at some point been connected to the network, not whether it was currently connected at the time of the query and thus available for the desired point-to-point communication.

[00:33:42] Speaker 02:
And they've said that over and over again.

[00:33:43] Speaker 02:
Their system tracks whether you're on or offline.

[00:33:46] Speaker 02:
prior to anyone trying to make a call.

[00:33:49] Speaker 05:
Would you read the requirement of having a database into the claim?

[00:33:53] Speaker 05:
Or would you say, it doesn't matter how you do it, but it has to be real time right now.

[00:33:58] Speaker 05:
It can't be performed through a call to the callee.

[00:34:04] Speaker 02:
That's a good question, Your Honor.

[00:34:05] Speaker 02:
I would not have read it into the claim as a matter of claim construction.

[00:34:09] Speaker 02:
But on the database, what they said to this court was crystal clear.

[00:34:14] Speaker 02:
They said in the SIPNET argument, at world argument,

[00:34:17] Speaker 02:
It's to confirm that it's online at the moment, and it's online at that address.

[00:34:22] Speaker 02:
So you see, it has to look at the database at that moment, and it has to be able to make a binary decision.

[00:34:29] Speaker 02:
This is what they said to this court.

[00:34:30] Speaker 02:
They said it has to have a paid database, and it has to make a binary decision.

[00:34:33] Speaker 05:
But that was in the context of a particular prior that was using a database.

[00:34:38] Speaker 05:
Isn't that right?

[00:34:39] Speaker 02:
No, they said it with respect to the patents.

[00:34:41] Speaker 02:
If you look, here's the next quote.

[00:34:42] Speaker 02:
The binary decision has to be made by the server then, because it takes the connection server under the patents, is required to do different things upon the decision and the determination at that time.

[00:34:58] Speaker 02:
They go on to say, to a question from this court, is the difference in your invention, not in your embodiment, in your invention, that the database has to be updated when somebody logs off?

[00:35:10] Speaker 02:
Answer, absolutely.

[00:35:12] Speaker 02:
And I say that for two simple reasons.

[00:35:15] Speaker 02:
One is it requires it.

[00:35:17] Speaker 02:
And that's the actual language used by the patentee.

[00:35:20] Speaker 02:
This is what they said.

[00:35:22] Speaker 02:
The next thing, the court then asks another question.

[00:35:24] Speaker 02:
So when you view the database, it must always be accurate.

[00:35:28] Speaker 02:
And that's the difference between your invention and the prior art.

[00:35:32] Speaker 02:
Correct answer.

[00:35:33] Speaker 02:
That is correct.

[00:35:34] Speaker 05:
But that's referring to the prior art, right?

[00:35:36] Speaker 05:
I mean, it is referring to the prior art.

[00:35:38] Speaker 05:
I mean, I think you could win under either theory.

[00:35:41] Speaker 05:
Right.

[00:35:41] Speaker 05:
Whether it's that it has to have a database in the claim or it's that it has to be, you know, something that is where it knows the status at the time of the query.

[00:35:52] Speaker 02:
Yes.

[00:35:53] Speaker 02:
I'm not necessarily saying that we should read database into the claim, but what I am saying is from those comments and from what the claim construction is, that server needs to know at the time the query comes in, whether the person it's going to then try to call is online or offline.

[00:36:09] Speaker 02:
When you look at the prior art, the wins and net bios, they operate exactly the way Cisco did.

[00:36:14] Speaker 02:
They have stale information in the database.

[00:36:17] Speaker 02:
And then when somebody calls into the database, they use that information to reach out to the caller.

[00:36:24] Speaker 02:
And then if they find the caller, just like the Cisco system, they connect the call.

[00:36:28] Speaker 02:
It's exactly what we do.

[00:36:29] Speaker 02:
OK, we're out of time.

[00:36:30] Speaker 03:
Do you have the citation?

[00:36:31] Speaker 02:
Yes, give me one second.

[00:36:36] Speaker 02:
Thank you for asking.

[00:36:37] Speaker 02:
It's appendix site.

[00:36:39] Speaker 02:
4694.

[00:36:41] Speaker 02:
Thank you.

[00:36:44] Speaker 04:
Thank you very much.

[00:37:01] Speaker 00:
Your honors, let's start with the claim language because there's been a lot said about whether the

[00:37:06] Speaker 00:
has to be made or whether it's a query as to whether it was connected at the time.

[00:37:11] Speaker 00:
The claim language says, this is 704 claim one, code for transmitting to the server a query as to whether the second process is connected to the computer network at the time the query was transmitted.

[00:37:29] Speaker 00:
What you're asking for is whether it was determined, whether the callee process was connected

[00:37:36] Speaker 00:
In your honors, I'll take you back to 6577.

[00:37:40] Speaker 00:
Cole testifies that the server determines not only that the callee endpoint was online at the time the query was transmitted, but it actually determines that the callee endpoint was online throughout that period.

[00:37:56] Speaker 00:
You have to credit that testimony.

[00:37:58] Speaker 00:
He explains it.

[00:37:59] Speaker 00:
If you look at paragraph 16, he explains that the reason you know that,

[00:38:04] Speaker 00:
is because I had a registration and I know it was online at the registration.

[00:38:10] Speaker 00:
When I send the invite, the check to determine, the server sends the check to determine, it can only receive it if it's still connected at that address.

[00:38:19] Speaker 00:
How do we know it's still connected at that address and has been throughout the time?

[00:38:23] Speaker 00:
Because these are dynamic IP addresses.

[00:38:26] Speaker 00:
If it had disconnected, it would now be at a different IP address.

[00:38:29] Speaker 00:
He explains that rationale.

[00:38:32] Speaker 00:
So he explains that the server determines that the callee process was online at the time of the query, which is exactly what this court's claim construction requires.

[00:38:45] Speaker 00:
And it does that before providing the IP address and before the caller attempts to establish the actual call, which is the unmediated point-to-point call.

[00:38:56] Speaker 00:
We have to be precise, Judge, about what the call is

[00:39:01] Speaker 00:
And you asked a question, Judge Stoll, about whether, but does the Winsnet BIOS attempt to place the call?

[00:39:08] Speaker 00:
Your Honor, I beg you, be precise about the language and use the claim construction, the claim language, which is talking about the point-to-point line that's being established.

[00:39:20] Speaker 05:
What is the answer to that question, though?

[00:39:21] Speaker 00:
I didn't answer that question.

[00:39:23] Speaker 00:
The answer to that is the key to this whole thing, which is in Winsnet BIOS, there's a query to the server

[00:39:29] Speaker 00:
and the server returns a stale IP address, and then the caller tries to use that stale IP address to connect to the callee.

[00:39:38] Speaker 00:
That's the prior art.

[00:39:39] Speaker 05:
It's not the server that tries to initiate the call.

[00:39:41] Speaker 05:
That's how you're distinguishing it.

[00:39:43] Speaker 00:
That's right.

[00:39:43] Speaker 00:
It's the caller.

[00:39:44] Speaker 00:
And the whole point of this, if you look at the last step of claim one, it's the program code responsive to the network protocol address for establishing the point-to-point communication link.

[00:39:55] Speaker 00:
That's the code in the caller process.

[00:39:58] Speaker 00:
connecting to the callee process.

[00:40:01] Speaker 00:
So the difference is that in the Winsnet BIOS prior art, it returned the IP address that was stale.

[00:40:09] Speaker 00:
And here, the server checks to determine that it's online and was online at the time of the query before providing the IP address.

[00:40:19] Speaker 00:
Whereas the prior art provided stale IP addresses for the caller to use to try to establish that call, the accused products never do.

[00:40:30] Speaker 03:
We're out of time.

[00:40:33] Speaker 03:
Thank you very much.