[00:00:41] Speaker 03:
Okay, our next case this morning is number 16-2335, GoDaddy.com, LLC versus Harpost Communications Limited.

[00:00:51] Speaker 03:
Mr. Hugdall.

[00:00:55] Speaker 02:
Good morning, Your Honor.

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

[00:01:10] Speaker 02:
My name is Louis Hudnell, and I represent the R. Post Appellants in this matter.

[00:01:15] Speaker 02:
And we are asking the court to vacate the district court's order granting summary judgment because the district court committed multiple errors in determining that the six patents in suit were ineligible under section 101.

[00:01:28] Speaker 02:
At step one of the Supreme Court two-part test, the district court applied a heart of the claims test, which was rejected by the sixth Supreme Court nearly 60 years ago

[00:01:40] Speaker 02:
and oversimplified the claims to conclude that they recite nothing more than collecting and providing data regarding the delivery of an email.

[00:01:50] Speaker 02:
This error caused the court to fail to recognize that the claims recite features that render them patent eligible.

[00:01:58] Speaker 02:
Specifically, with respect to each of the five TomCow patents in suit, they claim a technical solution to the technical problem of providing verifiable evidence of email delivery.

[00:02:12] Speaker 02:
That solution fits what this court has deemed patent eligible in DDR, BASCOM, and Andox.

[00:02:22] Speaker 02:
The problem addressed by the Tomcow patents can be seen in the appendix A5740.

[00:02:34] Speaker 02:
And for reference, since the patents used the Tomcow patents have the same specification, I'll use the

[00:02:40] Speaker 02:
the 913 patent for reference.

[00:02:43] Speaker 02:
But beginning in column two around line 17, the TomCow patents describe the problem of the prior art proof of email delivery systems.

[00:02:55] Speaker 02:
First, there were systems that required special software at the sender and the recipient in order to prove delivery of an email.

[00:03:06] Speaker 02:
Second, there were systems that required the sender

[00:03:09] Speaker 02:
send an email to a third party and then the recipient would have to contact the third party to retrieve the email in order to get it.

[00:03:21] Speaker 02:
The TomCow patents solved this problem in the prior art two ways.

[00:03:27] Speaker 02:
First, they tasked the intermediate server between the sender and the recipient with the task of performing the act that would prove delivery of the email.

[00:03:40] Speaker 02:
In the first group of TomCow patents, the 913, 389, and 199, they all recite the same limitation of recording a portion of the transport protocol dialogue between the intermediate server and the recipient.

[00:03:56] Speaker 02:
By recording that dialogue and then providing that dialogue back to the sender, you've achieved proof of delivery of that email.

[00:04:07] Speaker 02:
The second group of TomCow patents also

[00:04:10] Speaker 02:
solve the problem in a different way, which incidentally shows that there's not a preemptive, that these solutions are not preemptive because there are multiple ways to do it.

[00:04:21] Speaker 02:
The second group of Tom Powell patents, the 104198 patents, provide for the intermediate server adding a configurable link to the email, such that when the recipient receives the email and opens the email, that link will

[00:04:39] Speaker 02:
caused the server to provide an indication that the message either had been opened or delivered.

[00:04:43] Speaker 01:
Now, that was in the prior art, I take it.

[00:04:47] Speaker 01:
The link that proves delivery.

[00:04:52] Speaker 01:
Or at least in the case.

[00:04:52] Speaker 01:
Links were in the prior art.

[00:04:54] Speaker 01:
An indication of delivery or failure to deliver.

[00:04:57] Speaker 01:
I gather that was also in the prior art.

[00:04:59] Speaker 01:
I'm sorry?

[00:05:00] Speaker 01:
That was also in the prior art, the indication of delivery

[00:05:07] Speaker 02:
There were different ways to do it, Your Honor.

[00:05:10] Speaker 02:
So for example, in column one of the reference patent here at A5740 around line 43, it talks about a solution where the sender could actually request a notification and receive an email back from the recipient saying that he actually got the message.

[00:05:31] Speaker 02:
The problem with that solution was that that email notification could be forged or altered.

[00:05:37] Speaker 02:
So by providing the link, Your Honor, that eliminated one that solved that solution, because now you're relying on the intermediate server to do that.

[00:05:51] Speaker 02:
But secondly, it eliminated the cooperation of the recipient in needing to confirm that they actually received the email.

[00:06:05] Speaker 02:
Both of these solutions,

[00:06:07] Speaker 02:
described in the ComCal patents were non-conventional.

[00:06:11] Speaker 02:
And we know this for two reasons.

[00:06:13] Speaker 02:
First, as discussed at A5745 of the reference patent, in column 11, beginning around line 41, the patent talks about the typical transmission of an email, which is transmitted email from MTA, mail transfer agent, to mail transfer agent on its way to the recipient.

[00:06:37] Speaker 02:
What this column of the patent discusses is, in order to prove delivery, what one of the embodiments disclosed in the patent tries to do is to establish a direct connection with the mail server of the recipient.

[00:06:50] Speaker 02:
That is different than the routine transmission of the email.

[00:06:53] Speaker 02:
By establishing that direct connection with the MTA of the recipient, you see at the top of in column 12, at the top, it says that every successful delivery direct to a recipient mail server will always generate

[00:07:06] Speaker 02:
SMTP record.

[00:07:08] Speaker 02:
So once you have that record, once you record that record and provide that record back to the recipient, you now have proof that that email got you.

[00:07:17] Speaker 01:
Can you give me the reference that you were just citing, the appendix page?

[00:07:21] Speaker 02:
Sure.

[00:07:22] Speaker 02:
A5745, column 12, beginning around line 70.

[00:07:29] Speaker 03:
But this record wasn't something new, right?

[00:07:38] Speaker 04:
Are we talking about the protocol dialogue?

[00:07:40] Speaker 02:
Yes, the protocol dialogue was not new.

[00:07:43] Speaker 02:
Recording it was not conventional.

[00:07:47] Speaker 02:
So in the typical transmission of an email from... So the record existed, but the idea was that you recorded it in the intermediate server?

[00:07:56] Speaker 02:
Well, I don't know if it's fair to characterize it as a record.

[00:07:58] Speaker 02:
So the way SMTP works is that there's command... Information.

[00:08:02] Speaker 02:
The information exists.

[00:08:05] Speaker 02:
When an email is transferred, there's a data transmission step.

[00:08:08] Speaker 02:
The server will say, I'm transmitting data.

[00:08:11] Speaker 02:
There's a code for that.

[00:08:13] Speaker 02:
When that data, that email is transmitted, what was returned back is an OK that says, I've received the email.

[00:08:20] Speaker 02:
And that's the dialogue.

[00:08:22] Speaker 02:
That's the dialogue.

[00:08:23] Speaker 01:
Yes, the command saying.

[00:08:24] Speaker 01:
All components of that constitute the dialogue.

[00:08:26] Speaker 01:
I take it.

[00:08:27] Speaker 02:
I'm sorry?

[00:08:27] Speaker 01:
All components of that constitute the dialogue.

[00:08:29] Speaker 01:
So what you're saying is you take a piece of that entire dialogue

[00:08:34] Speaker 01:
you shoot it back to the intermediate, and that's your proof of delivery.

[00:08:39] Speaker 02:
Correct.

[00:08:40] Speaker 02:
And just to be clear, the dialogue could have many other steps.

[00:08:44] Speaker 02:
Understood.

[00:08:45] Speaker 02:
It's just the step where the email is actually transmitted.

[00:08:48] Speaker 02:
There's a command that sends the data.

[00:08:50] Speaker 02:
There's a command that says, OK, I got the data.

[00:08:52] Speaker 04:
For preexisting systems of proof of delivery of emails or proof that the email did not go through,

[00:09:03] Speaker 04:
Were those priority systems using the protocol dialogue?

[00:09:08] Speaker 02:
There actually is one system that's discussed in the patent.

[00:09:12] Speaker 02:
Actually, it's discussed a little bit in the column I was just referencing.

[00:09:18] Speaker 02:
There's an ESMTP dialogue that could be used to provide proof of delivery.

[00:09:24] Speaker 02:
But what that did is that actually provided a notice, an email back to the intermediate server saying,

[00:09:32] Speaker 02:
saying that the email was delivered.

[00:09:34] Speaker 02:
The problem with that solution is, one, not all MTAs used ESMTP at the time.

[00:09:42] Speaker 02:
And two, if they did use it, that feature was optional.

[00:09:45] Speaker 02:
And so it wasn't always passed back.

[00:09:47] Speaker 02:
So as this part of the patent discusses, the only surefire way to ensure that you could get proof of delivery, which was the recognition of the inventors by recording that data transmission step from the SMTP file.

[00:10:01] Speaker 01:
The invention then, the novelty is converting what was optional into what is mandatory?

[00:10:07] Speaker 01:
I wouldn't say that, Your Honor.

[00:10:09] Speaker 02:
I would say it was one, recognizing that the intermediate server was the focus point, was the device that needed to be tasked with doing this.

[00:10:22] Speaker 01:
But I thought you said a moment ago that the prior art used an intermediate server for the optional return of the dialogue.

[00:10:32] Speaker 02:
there would be intermediate service involved in that.

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

[00:10:36] Speaker 04:
So I guess what I'm trying to figure out is what is the inventive concept?

[00:10:40] Speaker 04:
I mean, one could argue that the alleged inventive concept here is the idea of taking this pre-existing information that was existing in the email dialogue and

[00:10:56] Speaker 04:
introducing a intermediate third party into the network and notarizing that information when it got sent back to the sender.

[00:11:08] Speaker 04:
That's, to me, one way of understanding how all these claims operate and what your novelty was in reading through the disclosures of the patents.

[00:11:26] Speaker 02:
I think we need to be clear on whether we're talking about novelty or eligibility.

[00:11:30] Speaker 02:
And we're talking about eligibility.

[00:11:32] Speaker 04:
But I guess what I'm trying to figure out is what is the inventive contribution?

[00:11:36] Speaker 04:
Maybe that's another way of putting it, right?

[00:11:39] Speaker 04:
What is the twist in these patents that the inventors tried to come up with and then claim?

[00:11:51] Speaker 04:
And obviously, the point was to

[00:11:55] Speaker 04:
create some system that verifies this information that's floating back and forth between servers.

[00:12:02] Speaker 04:
And so the invention was let's put an intermediate server in there that's going to handle and interrupt this information flow back and forth and put some kind of notarization on top of it so that it would have some legal effect in courts.

[00:12:24] Speaker 04:
Kind of how I read the claims, so I'm trying to figure out, okay, does that count, though, under Alice, step two, as an inventive concept?

[00:12:38] Speaker 02:
I think it does count as an inventive concept, Your Honor, and I think the... Is that description correct?

[00:12:43] Speaker 03:
We're talking about recording pre-existing information.

[00:12:53] Speaker 02:
No dispute that the mail servers communicate with each other to transfer the information.

[00:12:58] Speaker 03:
I'm trying to understand whether you're agreeing with Judge Chin's description of this and my description of it.

[00:13:07] Speaker 03:
The information was pre-existing.

[00:13:10] Speaker 03:
The dialogue information was pre-existing.

[00:13:12] Speaker 03:
And the invention is recording it at an intermediate server?

[00:13:17] Speaker 02:
The dialogue information was pre-existing to communicate the email.

[00:13:23] Speaker 02:
The twist is recording it, which was non-conventional, so that it could be used to prove delivery of that email.

[00:13:33] Speaker 02:
The use of the communication dialogue is simply used to communicate the email back and forth between the intermediate server and the recipient.

[00:13:41] Speaker 02:
The twist is then recognizing that if I record a piece of that, which was not a conventional step, recording that and sending that back to the sender, as evidence

[00:13:53] Speaker 02:
that it was a non-conventional step.

[00:13:55] Speaker 02:
The second piece of evidence that shows that this was a non-conventional step comes from GoDaddy's expert himself.

[00:14:03] Speaker 02:
In a related case involving the parent application to the TomCow patents in this case, the 372 patent, which has the same limitation of recording a transport dialogue, I asked him, what is your understanding of the 372 patent?

[00:14:19] Speaker 02:
This is on A6472.

[00:14:24] Speaker 02:
beginning of line 17.

[00:14:25] Speaker 02:
I asked him, what is your understanding of the claimed invention of the 372 patent?

[00:14:29] Speaker 02:
And then I asked him, did you find any references that teach the claimed invention of the 372 patent under your understanding?

[00:14:36] Speaker 02:
And then he said, under my understanding, again, I didn't look because I knew the accused products don't keep track of the mail dialogue.

[00:14:43] Speaker 02:
In fact, nobody reasonably would audit that in a product because you generate so much data.

[00:14:48] Speaker 02:
It's not really practical to do that.

[00:14:51] Speaker 02:
Next question.

[00:14:52] Speaker 02:
Why is that not practical?

[00:14:53] Speaker 02:
Because you generate so much audit data, it's not going to help you.

[00:14:56] Speaker 02:
When you're providing a mail notary service, the details of the protocol dialogue are not necessarily important, not nearly so as digitally signing and timestamping appropriately.

[00:15:07] Speaker 03:
You're into your rebuttal time.

[00:15:09] Speaker 03:
Do you want to say that?

[00:15:10] Speaker 03:
Yes, I do.

[00:15:10] Speaker 03:
Thank you.

[00:15:11] Speaker 03:
We'll give you two minutes.

[00:15:22] Speaker 00:
Good morning.

[00:15:26] Speaker 00:
May it please the court?

[00:15:28] Speaker 00:
I'm Brian La Cour, joined by John Talcott.

[00:15:30] Speaker 00:
We represent Goat to Addie.

[00:15:35] Speaker 00:
I'll address the fundamental issue in this appeal, the Section 101 ineligibility of the Assertive Court.

[00:15:41] Speaker 03:
Why don't you address the last argument that was made, that the recording of this dialogue is an inventive concept?

[00:15:50] Speaker 00:
I will.

[00:15:51] Speaker 00:
The recording of pre-existing dialogue, storing it, retrieving it, reporting it, is not an inventive concept.

[00:15:59] Speaker 00:
It is precisely, essentially what the post office does with registered mail.

[00:16:04] Speaker 00:
It is taking pre-existing standard public protocol that was available since 1982 and simply selecting a vaguely defined portion of it to store it and then utilize

[00:16:18] Speaker 00:
the indications it provides, such as an email being delivered or bounced.

[00:16:23] Speaker 04:
Is that a 103 argument?

[00:16:27] Speaker 00:
So there is, you know, a concern about obviousness and novelty leaking into the 101 eligibility.

[00:16:33] Speaker 00:
And I agree with opposing counsel that this is about 101 eligibility and not novelty.

[00:16:39] Speaker 00:
But what is known and conventional in any email infrastructure is SMTP protocol.

[00:16:46] Speaker 00:
Email servers are by nature intermediary.

[00:16:50] Speaker 00:
They are displaced from the email client.

[00:16:53] Speaker 00:
They contain dialogue that records or logs of dialogue that clearly show the transmission trail of an email.

[00:17:03] Speaker 00:
When an email bounces, there is a code and there is an indication that it was not delivered.

[00:17:09] Speaker 00:
And the email client receives from the email server that information, which of course is stored.

[00:17:15] Speaker 00:
and indicates to the end user what happened.

[00:17:18] Speaker 00:
This is pre-existing you're talking about.

[00:17:21] Speaker 00:
Yes.

[00:17:22] Speaker 00:
This is a decades old available protocol that by its nature and design is to indicate and or authenticate what happened in email transmission.

[00:17:34] Speaker 03:
So the protocol told the sender whether the message had been received.

[00:17:41] Speaker 00:
Well, the protocol certainly

[00:17:43] Speaker 00:
tells the sender when the message bounced and the protocol is available in the email server architecture to show the transmission from point A to point B. The inventive concept at issue with our post-contentions is that storing that or retrieving it is somehow an inventive concept that saves the patent under step two from an eligibility.

[00:18:08] Speaker 00:
Pre-computer, certainly information was stored about the transmission status of a message and post SMTP, that information of course is stored in some fashion as part of the logs that are part of the mail transportation.

[00:18:23] Speaker 03:
Is the point here that they're saying that what's unique is storing it on the intermediate computer?

[00:18:29] Speaker 00:
Well, that's their argument, and I would simply respond, Your Honor, that that is not an inventive concept.

[00:18:36] Speaker 03:
An intermediary is as basic and noninventive as a... So the argument is that it's storing it on the intermediate computer instead of having it come back to the sender and having it available on the sender's computer.

[00:18:55] Speaker 03:
understanding correctly.

[00:18:56] Speaker 00:
I believe that's our post position and that inventive concept of simply or alleged inventive concept of simply storing pre-existing data that is designed to indicate what our post says it indicates does not.

[00:19:10] Speaker 04:
At least there's some claims that go further than that concept.

[00:19:18] Speaker 04:
They basically interrupt the dialogue, intercept a relevant portion

[00:19:25] Speaker 04:
and then not only store it there at the intermediate server, but then they package it with perhaps something called an indication or authenticable information and then sends that onto the sender.

[00:19:40] Speaker 04:
And now we have this intermediary, as you put it, that can guarantee and verify the

[00:19:49] Speaker 04:
the actual transmission, the actual transaction that had occurred in sending of the email from the sender to the recipient?

[00:19:57] Speaker 00:
Well, to be clear, Your Honor, on that particular point, in looking at the claims language of the 913 patent, rather than the lawyer argument about this intermediary server in the TomCal patents that does not require the cooperation of the sender or the recipient, the claims language of the 913 patent does not

[00:20:19] Speaker 00:
precisely mention an intermediary server that avoids the cooperation of the email recipient.

[00:20:26] Speaker 00:
So looking at the claims of 913, I would suggest to you, Your Honor, that they're broader than what you just described.

[00:20:32] Speaker 04:
I guess I was referring to other claims.

[00:20:36] Speaker 04:
Well, there's some... We're dealing with lots and lots of claims.

[00:20:38] Speaker 00:
Yeah, there is some question about what the representative claims here would be, but certainly in the representative claims of all five of the TomCal patents,

[00:20:48] Speaker 00:
There is no particular reference in the district court's thoughtful analysis of this issue is certainly helpful in this framework.

[00:20:57] Speaker 00:
There is no particular reference to this intermediary server that avoids the cooperation of the email recipient.

[00:21:05] Speaker 00:
And what the claims do recite in terms of their limitations are vague notions of pulling some portion of SMTP protocol that would indicate something.

[00:21:18] Speaker 00:
And that is what SMT protocol does.

[00:21:21] Speaker 00:
That's what servers do, whether it's an email server or an intermediary server on top of an email server.

[00:21:28] Speaker 00:
And simply recording that information because it's useful is akin to the 101 ineligibility data gathering categorization cases that this court has decided in numerous instances, including one similar to this, an IVV semantic.

[00:21:46] Speaker 00:
There, there was a server that does what servers do.

[00:21:49] Speaker 00:
It was, in essence, an electronic post office.

[00:21:52] Speaker 00:
The court analogized the email functionality of the claims as essentially a corporate mail room.

[00:21:59] Speaker 00:
It grabbed tags and codes and information and reported when there was an email filtering issue or a potential virus.

[00:22:08] Speaker 00:
And the court laid out in detail in IV semantic how that is, under step one and two, patent ineligible.

[00:22:15] Speaker 00:
is very similar to the basic functional claims as to SMTP protocol in the TomCow patents.

[00:22:22] Speaker 01:
If you turn to a specific patent, the 104, I'm interested in your reaction to why it is.

[00:22:34] Speaker 01:
I'll summarize that patent, the claim one.

[00:22:38] Speaker 01:
Let's take it.

[00:22:39] Speaker 01:
That's one of the claims at issue saying

[00:22:43] Speaker 01:
effectively that you add a link to the message at the server.

[00:22:49] Speaker 01:
And then you transmit the message with the link.

[00:22:53] Speaker 01:
And the link is what tells you that the message was opened.

[00:22:57] Speaker 01:
Now, that sounds like that may be invalid based on the prior art.

[00:23:04] Speaker 01:
But why is that abstract?

[00:23:07] Speaker 01:
Why is that 101 as opposed to 102 or 103?

[00:23:11] Speaker 00:
Fair question, your honor.

[00:23:13] Speaker 00:
First of all, of course, links are ubiquitous in the internet, modern internet world.

[00:23:19] Speaker 00:
Adding a link to content, whether it's a message or a website to allow someone to navigate and access content is ubiquitous.

[00:23:27] Speaker 00:
In internet patents, this court analogized a link as allowing an icon to be clicked and an online form to be populated or at least presented.

[00:23:41] Speaker 00:
as an example of generally claiming a link for what it does.

[00:23:46] Speaker 00:
And in the 104 patent, that is what claim one, for example, does.

[00:23:51] Speaker 00:
It simply is the addition of a link to a server as part of the email transmission that is configured to download or be active so that when the link is accessed, it indicates the link was accessed.

[00:24:09] Speaker 00:
without anything more in the claims.

[00:24:11] Speaker 00:
And so in an abstract step one analysis, it is simply calling out, as the district court analyzed, the function of a link for what the link does without more.

[00:24:24] Speaker 01:
And certainly the concept of a link is- But suppose there had never been links before.

[00:24:30] Speaker 01:
And this was the first time anybody thought of using a link.

[00:24:34] Speaker 01:
This wouldn't be a 101 problem, would it?

[00:24:37] Speaker 01:
Well, in this case, it is because it is a... I understand, but take my hypothetical that the idea of a link was brand new.

[00:24:45] Speaker 01:
The 104 claim one that you just described, it seemed to me you were lying on the fact that this is all very conventional, as opposed to that it's just abstract.

[00:25:00] Speaker 00:
Well, I would call it abstract in this context, even assuming that

[00:25:03] Speaker 00:
this patent considers links for the first time for its intended purpose.

[00:25:10] Speaker 00:
The 104 patent and the common specification for TomCal calls out tags and flagging as a pre or non-link fashion of identifying something about the email being accessed.

[00:25:27] Speaker 00:
So, for example, a read receipt in Microsoft Outlook as referenced in the specification.

[00:25:33] Speaker 00:
tags and flags to indicate someone has accessed content in an email or electronic environment is well established and conventional.

[00:25:43] Speaker 00:
And if the link is simply a generic internet protocol addition to, in effect, bring to email, and I'm not suggesting this is the case because links were used before this, but to bring to email some type of indication from accessing web content, that's abstract.

[00:26:02] Speaker 01:
I would have thought you would have focused on the limitation that is in the claim one of the 104, providing an authenticatable information relating to the message, including the indication of the opening as being where this became abstract.

[00:26:22] Speaker 00:
Well, and I may have focused on the hypothetical of the links being... So, Your Honor, a link does what it does.

[00:26:33] Speaker 00:
It provides some indication that may be authenticatable, that someone accessed the link.

[00:26:40] Speaker 00:
And that's why I mentioned the internet patents case, because it seems to be the court's same concern in that case, that simply using a link to do what it does

[00:26:52] Speaker 00:
And its very function would indicate or authenticate exactly what the patentee Tom Cow is claiming and claim one that does what it does.

[00:27:02] Speaker 00:
So to simply use internet hyperlink protocols, which indicate something when a link is accessed as either inventive concept or non-abstract material is incorrect.

[00:27:18] Speaker 00:
The problem with the Tom Cow patents is this broad

[00:27:22] Speaker 00:
functional reference of indications that result from certain things that happen within internet infrastructure or email infrastructure is not patentable subject matter.

[00:27:34] Speaker 00:
And so to simply recite the functional steps of how email works and its underlying protocols and what is indicated by those protocols occurring is the 101

[00:27:48] Speaker 00:
fatality for the TomCal patents.

[00:27:51] Speaker 00:
There is nothing inventive in there.

[00:27:53] Speaker 00:
The 104 patent, the executing the link step.

[00:27:58] Speaker 04:
Who or what is executing the link when the message is open?

[00:28:01] Speaker 04:
Is that the individual that receives the email or is it the recipient's server that's automatically executing the link?

[00:28:14] Speaker 00:
At least in the record, the district court construed the term link in its plain and ordinary meaning and in the fashion that this appears to be configurable or configured to execute.

[00:28:28] Speaker 00:
It is either automatically when it is received by the email recipient's email server or accessed or clicked by the actual recipient.

[00:28:42] Speaker 04:
It says when the message is open.

[00:28:44] Speaker 04:
So it can't just simply be when the email arrives at the server.

[00:28:50] Speaker 00:
Well, there was some debate below about what is opened, and does that mean that it is accessed and viewed by a human being or landing at the server?

[00:28:58] Speaker 00:
And the plain and ordinary meaning of the claim language, I would agree, Your Honor, would be someone has to either activate the link or has a setting on their email client that allows automatic downloading.

[00:29:13] Speaker 00:
at least under the claim terms, the link is activated at the recipient server by some function, typically the recipient.

[00:29:26] Speaker 00:
And again, just returning to the lack of inventive concept, any time someone accesses a link and related web content,

[00:29:39] Speaker 00:
and navigates to a web page, there are footprints, there are indications that result from that.

[00:29:43] Speaker 00:
That is the sort of generic result of hyperlink protocols.

[00:29:49] Speaker 00:
And to simply collect that and use it for its indication is neither inventive nor patentable subject matter.

[00:29:56] Speaker 00:
I have only 30 seconds left.

[00:29:58] Speaker 00:
I would like to address one last item with regard to the patents.

[00:30:05] Speaker 00:
Routinely in the claims language, it's generic.

[00:30:07] Speaker 00:
computer technology.

[00:30:09] Speaker 00:
And time and again, this court has said simply taking the notion, as we have here, of a well-established conventional concept or abstract idea and saying apply it to an email technological platform, which is what the patents do, is not enough.

[00:30:27] Speaker 00:
There has to be something more.

[00:30:29] Speaker 00:
And adding a link to an email or using protocols is not inventive or enough.

[00:30:36] Speaker 00:
Thank you, Your Honor.

[00:30:39] Speaker 03:
Mr. Hudnell, you have two minutes here.

[00:30:53] Speaker 02:
Thank you, Your Honors.

[00:30:54] Speaker 02:
Just to pick up where my colleague left off, we completely disagree that this is simply adding a computer to perform these functions.

[00:31:05] Speaker 03:
I'm still confused as to what's new here.

[00:31:08] Speaker 03:
As I understand it before, it was known to use an intermediate computer.

[00:31:13] Speaker 03:
That was conventional, right?

[00:31:17] Speaker 02:
Intermediate servers existed, yes.

[00:31:19] Speaker 03:
And as I understand it, the authentication of the delivery or opening of the email was something that was available to people before.

[00:31:28] Speaker 02:
No, and we dispute that.

[00:31:31] Speaker 03:
When a server... I thought you said earlier that there was a way of doing this, that people... Oh, there were other ways, yes.

[00:31:38] Speaker 03:
I mean, there were other ways, not the way that... What I'm trying to get at is how do those other ways differ from this way?

[00:31:46] Speaker 02:
There's other ways either require the cooperation of the recipient, they require special software at the clients, or they did not always provide evidence of proof of delivery.

[00:32:00] Speaker 03:
What do you mean they didn't always provide that?

[00:32:02] Speaker 02:
So in the ESMTP example that I discussed earlier, in the prior art, there were servers that could do ESMTP and send an email back to the sender indicating that the message was delivered.

[00:32:15] Speaker 02:
But ESMTP was not used by all the servers for an email on its way from the sender to the recipient.

[00:32:20] Speaker 02:
So there was no surefire way that you would actually get that proof.

[00:32:25] Speaker 03:
Well, I mean, surefire because some of the systems didn't have it.

[00:32:28] Speaker 03:
Either they didn't have it.

[00:32:29] Speaker 03:
Well, that doesn't.

[00:32:30] Speaker 03:
I mean, it can be conventional, even though it wasn't universal.

[00:32:35] Speaker 02:
If they didn't have it, or if they had the feature, it wasn't turned on.

[00:32:39] Speaker 01:
But if the only thing you need to do is to switch and turn it on, it's not much of a contribution to say, well, the switch should stay on all the time.

[00:32:50] Speaker 02:
The recognition here, Your Honor, or the twist, was recognizing that instead of using that system,

[00:32:57] Speaker 02:
We're going to use a system where we record a portion of the SMTPP dialogue and provide that back to the sender to protect the sender in the situation where the recipient says, I didn't get your email.

[00:33:11] Speaker 03:
OK.

[00:33:12] Speaker 03:
All right.

[00:33:12] Speaker 03:
Thank you, Mr. Hudnall.

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