[00:00:00] Speaker 02:
We will hear argument next in case number 251132, VL Collective versus Netflix.

[00:00:09] Speaker 01:
Thank you, and may it please the Court. Brian Barron for the Appellant Video Labs. The Board's decision should be reversed because it rests on two related misunderstandings of what the 559 patent claims require. The limitation at issue here is at the heart of the invention. The patent's core advance over the prior art is introducing a content flow manager, which is a network entity that sits as an intermediary between content provider servers that have multimedia content on them, like a movie or a TV episode, and end users whose devices are called terminals in the patent.

[00:00:43] Speaker 01:
The content flow manager's job in this invention is to control the flow of content. And the way it does that is it gets content status messages from the terminals And then it uses that information to issue instructions in a response to those content status messages to the terminals, telling them to take particular actions. Download this file, delete that file. Those instructions are how the content flow manager controls the flow.

[00:01:14] Speaker 01:
And that's what the limitation at issue here describes. It requires a response to the content... Let me ask you one question.

[00:01:20] Speaker 04:
How would those instructions be manifested in this sort of computer world? Your position is there has to be a command, a direction, an order, something along those lines. How would that be manifested or indicated?

[00:01:35] Speaker 01:
I think the delete command in Houston is actually a good example. It's...

[00:01:40] Speaker 01:
It's a computer instruction to do a particular thing. It's saying, delete this file. And that is what the board failed to require when it was analyzing Kassen. There's no, here I'm telling you what to do with any piece of content. It's just, the Kassen server is just sending the stuff and then the client decides what to do with it. That is...

[00:02:08] Speaker 01:
the opposite of an instruction as to what the client... Only in the sense that the board thought, which is mere causation. The server sends something and the client, as a result of having received it, takes some action. I don't think that's an instruction in the sense that instructs is used in ordinary English, which is what both sides agree applies here, and it's not, and I think that's consistent with the context of the whole patent from beginning to end.

[00:02:39] Speaker 01:
It's talking about this content flow manager as something that controls the flow of content.

[00:02:44] Speaker 01:
It's controlling what the terminal is downloading what files it's deleting, and it does that by issuing instructions.

[00:02:52] Speaker 03:
So just looking at Kasten, it discloses two different protocols. It goes back and forth between the server and the client.

[00:03:02] Speaker 03:
And then in the second protocol, eventually the client sends what's called a second list back to the server that lists items the client doesn't have. And then the server, I don't know, queries its database or does something, and then so long as the client is approved of getting those items, it sends those items down to the client where it gets downloaded So for you, you're saying what's missing from the claim is that that delivery of those items listed on the second list doesn't also have associated with it some express command to do the downloading?

[00:03:50] Speaker 03:
Even though the net result is exactly the same, you have a client with downloading all of those items that it receives.

[00:04:02] Speaker 01:
I think there are two independent problems with the second protocols instruction. The steps are actually the other way around from how your owner just described. The server first checks what can you get, and then the second list, the client pairs down the list of what is available to the client. to what it's requesting. And then all the server does in response to the request from the client, which is the second list, is it sends everything on that list.

[00:04:32] Speaker 01:
And sure, as a result of that, the client is going to download the files, but that is describing exactly the prior art pull method that this patent says it's improving over by introducing a content flow manager that can actually... tell the client which files it should download. The cast-in-second protocol is the client telling the server which files it wants, getting those files, and then saving them in its storage. That is exactly the prior article method.

[00:05:06] Speaker 03:
Your view is that there was an implicit claim construction here when Strux...

[00:05:14] Speaker 03:
And, you know, sometimes it's hard to tell when there – where's the line for a so-called implicit claim construction versus a straight-row application of a reference to the claim language.

[00:05:33] Speaker 03:
It's unclear. I didn't really see anything in the board decision where the board – sort of playing around with the language of instructs to give us some kind of information of the board suggesting there's some particular conception as to the meaning of instructs compared to what happened in Google versus Echo back then.

[00:05:56] Speaker 03:
the board clearly was talking about all these different distinct items and components, and because the claim lists five different components, there should be, therefore, five components independent of each other. And then the board went inside the case log to support the view of the claim there. And I didn't quite see any...

[00:06:20] Speaker 03:
Sure. I think I have three points on that.

[00:06:29] Speaker 01:
The first is that Netflix doesn't dispute that it's claim construction. If you look in the red brief at 40, its heading is talking about the board properly understanding the meaning of the claims. And I think that's correct. The second point is that I think what the takeaway from EcoFactor is, is the board figuring out what the claims require? And I get that the board's decision doesn't spell that out in the language of... It doesn't spell out the boundaries of the claim term instructs.

[00:06:57] Speaker 03:
And I think that was one of the key questions in Google versus EcoFactor.

[00:07:05] Speaker 01:
I think the board, though, to get to what it said, and most of the board's conclusion is just embedded in the word thus or therefore. It doesn't really go through much analysis at all of why these are instructions. To get there, I think looking at what happened at the oral argument before the board helped show that the board was thinking about this as claim construction, and then that carries through to the conclusion it reaches. The excerpt on, I believe it's 1734 to 1744, That whole section of the transcript is the board asking Video Labs Council about what response that instructs means in the context of this patent.

[00:07:47] Speaker 01:
What is the ordinary meaning of that term?

[00:07:51] Speaker 01:
And my understanding, and I'm sorry there's not a written record of the pre-hearing phone calls as I understand it, but my understanding from my colleague, and it appears later in the transcript. It's pages 53 to 54 of the transcript. They're not in the JA because Netflix didn't raise this issue. The board is referencing this pre-hearing call where the board raised on that call, hey, be prepared to address what we think is a claim construction dispute here about what the word instructs means.

[00:08:24] Speaker 01:
That dispute plays out at the oral argument, and I think that is the the best way to understand the reasoning behind the board's thuses and therefores that connect up its findings of fact about CASA, which are just describing what these protocols do, and its conclusion that there are responses that instruct in those protocols.

[00:08:47] Speaker 03:
Your appeal seems to have two issues. One is, what is the meaning of instructs in the context of casting? And then what is the meaning of response to the content status in light of Houston?

[00:09:04] Speaker 03:
If we were to affirm the Houston issue, would we even need to get to the casting issue? Because my understanding is affirming the Houston issue would, in fact, resulted in the firmance of the Houston-only 103 unpatentability finding for all the claims. Is that right?

[00:09:25] Speaker 01:
That's correct. I do need to run the table today, unfortunately.

[00:09:27] Speaker 03:
All right. Well, let's hear about Houston.

[00:09:30] Speaker 01:
Sure. And I think the problem with Houston is that the board enforced the based-upon part of the limitation, and it read out a response to entirely. The reason the board thought that there was a response to the content status in Houston is because the decision to delete, the deletion command in Houston is sent based on a comparison. We agree with that, that it is based on a comparison that uses a listing of content from the traffic server.

[00:10:04] Speaker 01:
We're accepting that the board's finding it, and we've thought about that below.

[00:10:09] Speaker 01:
The instruction that results from that, the board said, was a response to the content status because it's based on information it got from the traffic server and it happens after. But it's undisputed that what actually prompts the comparison is new information on the origin server. So it is just this considers the information and happens after, but it's not triggered by, and I don't think there's any argument that it's actually triggered by the message from the traffic server as opposed to something happening on the origin server.

[00:10:43] Speaker 03:
It's clear that the delete command from the differencing engine to the traffic server can't happen without...

[00:10:58] Speaker 03:
the traffic server first sending the content status to the differencing engine, right? That's true, and I think you would get to the same result as the... And the differencing engine isn't going to send that delete command without comparing that content status information from the traffic server to whatever server information there is on the origin server, right?

[00:11:23] Speaker 01:
That's right, but I don't think there's any argument that the traffic server's message prompts the comparison and then tells the differencing engine to go ask the origin server. What I think the board found and what everybody agrees about how Houston works is that the origin server gets new content. That prompts the version comparison.

[00:11:42] Speaker 01:
And that comparison considers information that has been gathered from the traffic server, but the question is whether it's a response to. And you could get to exactly what the board did here if you strike the words a response to the content status that, and you just say, actually you could strike to send to the terminal a response to the content status that, and say the processor is configured to instruct the terminal to perform one or more actions based upon. And the reason there's a distinction between based upon and and response to is that all the claims require that the response be to the content status, but they differ in what that response has to be based upon.

[00:12:20] Speaker 01:
It always includes the terminal status information, but some of the claims require that it also be based upon the server status information. So there's a distinction between process, which the response to part of this language address is, and the substance or the content of what the instruction has to consider that the based-upon address is. I see I'm into my rebuttal time. Unless there are further questions, I'll reserve the remainder. Thank you.

[00:12:58] Speaker 00:
May it please the Court, I'm Elisa George Carano of Wilkie, Farr, and Gallagher, here on behalf of Netflix.

[00:13:04] Speaker 00:
Now, I'm happy to address any topic, but I think I'd like to start with ground three, which was where the other side left off. And on ground three, Video Labs doesn't dispute that the board correctly found that Houston teaches a response to unstructs. What's disputed is whether Houston teaches response to content status. And I think for both of the issues, This isn't a matter of claim construction, and the board didn't implicitly construe the claims. The board did not decide what were the meets and bounds of the claims.

[00:13:36] Speaker 00:
What it did is it applied the plain and ordinary meaning of the claims and then determined whether Kasson or Houston taught those specific limitations. And so with Houston, as an initial matter, the arguments that Video Labs now raises on appeal were not presented before the board. Video labs never analyzed the correct embodiment of Houston that Netflix actually relied on, which is the embodiment depicted in Figure 2A of Houston. The board even recognized this and said at Appendix 44, patent owner has not addressed Houston's embodiment of a differencing engine located apart from the origin servers and traffic servers as shown in Figure 2A.

[00:14:19] Speaker 00:
Now on appeal for the first time, Video Labs addresses the correct embodiment of Houston, but these arguments that now advance on the correct embodiment were not before the board, and they should have raised these below, as this was clearly articulated in Netflix's petition, and they didn't, so we believe that they should be forfeited. But even going to the substance, their arguments on Houston fare no better either. So what you heard from the other side is that they're trying to read this limitation into the plain and ordinary meaning of response to content status to mean a response triggered by the content status.

[00:14:57] Speaker 00:
And there's just no support for that understanding of the claim language. And this argument also was not raised below. This is also a new argument raised on appeal. But if you look at what they're arguing now, there's no basis for that either. The claims clearly say it's a response to content status. If the patentee wanted the claim to be drafted to require this triggering requirement, it could have easily been drafted to be a response triggered by the content status. But the claims don't include the word triggered.

[00:15:28] Speaker 00:
The specification doesn't even use the word trigger. And so this belated claim construction argument that they're trying to make now in appeal, it fails both on substance and by forfeiture.

[00:15:41] Speaker 02:
Help me understand, what do you mean or what do you think the other side means about the difference between response to and trigger?

[00:15:52] Speaker 00:
What I think the other side is trying to argue here is that there's this requirement that the response has to be triggered by the content status. So what's causing the instruction to either delete or download content has to come from the terminal, the client, or in Houston, the traffic servers. And there's no temporal requirement in the claim. The claim simply calls for a response to the content status that instructs the terminal to perform one or more actions to thereby control the flow of content to the terminal based upon the terminal status information and in some claims the server status information.

[00:16:34] Speaker 00:
So there is no triggering required in the claim as long as

[00:16:40] Speaker 02:
I'm sorry, so when I read the words response to X, I pretty much automatically understand X must occur before the response, and X causes the response, perhaps not without Y helping, but nevertheless there is a, causal connection between X and the response. Are you denying that?

[00:17:09] Speaker 00:
I think that's fair. And Houston does that because in order for Houston to issue a delete command, it has to get information from both the traffic server and from the origin server to do a comparison. And so in response to the information it receives from Houston's traffic server, it then issues a delete command based on the information, the comparison between both the information received from the origin server and the traffic server.

[00:17:40] Speaker 00:
So Houston meets this limitation by virtue of the fact that information must be sent from the traffic server to the differencing engine in order for a delete command to be issued. So there is a response to the contents desk. The response is to the fact that the traffic server provided information as to what its previous contents were in order to determine whether there should be a delete command issued.

[00:18:06] Speaker 04:
Ms. Conner, you're talking about the requirements of Houston. Is that what, is it column 6, basically lines 42 to 51 in Houston? I believe so. That seems to be it.

[00:18:33] Speaker 00:
Yes, this talks about the comparing versions. I just wanted to confirm that was right. But yes, this is where this comparison takes place of information between the origin server and the traffic server for the differencing engine to then issue a delete command.

[00:18:48] Speaker 03:
The other side was making an argument that this understanding of response to content status...

[00:19:01] Speaker 03:
It's very broad understanding. It makes the based upon laws redundant because we already know about based upon criminal status information and service status information claims. So what left is there to do for response to the content status?

[00:19:24] Speaker 00:
So this argument that Video Labs has raised in its gray brief was not raised earlier. This was its first time raised in the reply brief, so we believe there's an issue with this belated argument. But taking it on, how the board interpreted the claims doesn't render that part of the claim limitation superfluous, because it necessarily requires in Houston that the delete instruction is based on that comparison.

[00:19:54] Speaker 00:
So even though the delete command comes from this It's responding to information coming from the traffic server and from the origin server. The delete command is based on that comparison of those two. So it still needs that information, and the delete is based on the information it received from the traffic server.

[00:20:21] Speaker 00:
So with respect to Houston, our position is that the board – There's substantial evidence to support the board's finding that Houston renders all the claims of the 559 patent invalid. I can move over to the instructs, response that instructs argument. And again, here, the board doesn't implicitly construe the claims. What the board did was it applied the plain and ordinary meaning. And what the dispute is, you know, listening to what the other side has raised is that is whether Kassen teaches just mere causation or an instruction.

[00:21:00] Speaker 00:
The board found that Kassen teaches an instruction, and there's substantial evidence to support that. And the question of whether or not something in the prior art is within the scope of the claims, that raises a question of fact that falls under substantial evidence review. And so they've raised a couple things here, and it seems like what they're asking is for the plain and ordinary meaning of a response that instructs to be limited to an express computer instruction.

[00:21:33] Speaker 00:
And that's just not required in the claims. If the claims required some express computer instructions, it could have been drafted to be, instead of a response that instructs, an instruction. So that way you're going more towards a computer programming instruction or command.

[00:21:50] Speaker 00:
But it's a response that instructs. And the claims don't require an instruction. there's no special meaning from the specification that would require there to be some explicit construction that the other side is proposing. And if you look at the specification, the specification broadly encompasses both direct instructions and indirect instructions. And VideoLabs can seize this point. You know, it's page six of its grade brief.

[00:22:22] Speaker 00:
It says, Netflix suggests that the patent's use of instruct reaches both direct and indirect instructions. It sure does.

[00:22:31] Speaker 02:
So the scope of... What is a direct instruction and what is an indirect instruction and how are they different?

[00:22:39] Speaker 00:
Well, I think a direct instruction would be someone saying, here, take this piece of content. And I think what they may have tried to argue before, and I think even the board acknowledged that casting instructs But this choice to either accept or reject content could be seen as an indirect instruction because there's a choice. What's being instructed is to make a choice whether to accept or to reject content.

[00:23:07] Speaker 02:
But either way, the board found that there was a clear instruction because... And that instruction is pay attention and make a choice. You must make a choice.

[00:23:18] Speaker 00:
You must make a choice. The protocol in CASN is very specific, and there's no deviating from it.

[00:23:24] Speaker 02:
Is that what the board said? This is an instruction because it tells the recipient of the instruction to do something. It's not specifying what something is. It's specifying you may do either A or B, but you have to choose.

[00:23:42] Speaker 00:
That's correct. That's what the board found as one of the instructions. And so for both of Kasten's protocol, the board found that there were response to instructions. So for the first protocol, when, and the whole purpose of Kasten is for content delivery, for the server to deliver content. So when it's trying to send content to the client, it's with the purpose for the client to download the content and store it. The only way the client can reject the content is if and only if it has that piece of content.

[00:24:14] Speaker 00:
So when the server is attempting to send content, the client tees, do I have the content or do I don't? And that's where the board said this could be considered an indirect instruction. But then if the client does not have that piece of content, then it has no other choice but to accept the piece of content. And so that is an instruction for the client to download, and then the client will download the piece of content and store it locally. So it is taking action.

[00:24:42] Speaker 02:
I'm getting really simple-minded here. So that's not an unconstrained choice between A and B. There's a kind of if-then, if one thing or else than the other, and the if constrains the choice of A versus B.

[00:25:02] Speaker 00:
I think so, if I'm following you correctly. Yes, I believe so. If it doesn't have the content, it will download the content.

[00:25:12] Speaker 00:
So that is necessarily an instruction. For protocol, the second protocol, that's even more of an instruction because what the, I think the other side said that the second protocol is like a pull method, which was what the 559 patent was trying to improve upon and create a better system where it wasn't the client pulling the content. But in a pull system, the client is what is pulling and deciding what content to pull. The server is static and it's waiting, it's sitting idle waiting for a request from the client.

[00:25:47] Speaker 00:
That's not the second protocol in Kassen. In Kassen, The client sends a request for content, but it's just a request. It's not a request for specific content. And then the server takes that request, queries the database, pulls and controls what content is going to be sent to the client. And then it sends a list of the available pieces of content to the client. The client then sends back a list of what content pieces it doesn't have. And then the server then instructs the client to then download those pieces of content that it doesn't have.

[00:26:20] Speaker 00:
And so what both of these protocols do it's what is actually depicted in the bottom half of figure six of the 559 patent. If there's a new piece of content, and that's in the flow chart of figure six, if there's a new piece of content, it will download and store locally. And that's what Kasson ends up doing under both protocols. When there's a new piece of content, the server directs the client to download that piece of content, that new piece of content, and store it locally. So it's our position that Under substantial evidence, the board properly found that Kasten renders many of these claims anticipated and obvious underground, too.

[00:27:05] Speaker 00:
And we believe that, you know, that because this is under substantial evidence, that – that the board's favor of one conclusion or the other must be sustained upon review. So we submit to the court that this panel affirms the board's decision. If there is no other questions, thank you very much. Thank you.

[00:27:43] Speaker 01:
I'd like to start where we just left off on whether this is claim construction or substantial evidence. I'm hearing for the first time today that Netflix's position is that it's not claim construction. I addressed Kasson before, but on the Houston point, in the red brief at page 4, Netflix says the claims require nothing more. Pages 49 to 52, Netflix is doing a claim construction analysis, admittedly of the wrong term, not the term we argued about, they're talking about based upon, and we were talking about a response to. but they're doing claim construction.

[00:28:14] Speaker 01:
The time to tell us that they thought that this was just substantial evidence and not implicit claim construction was in the red brief. That didn't happen. But even if, despite what Netflix effectively agreed to in the red brief, despite Netflix forfeiting this argument, the court wants to look at it under substantial evidence, I think you can apply all the same things we're saying about the claim construction, and those are also problems under substantial evidence review, because the board doesn't have anything other than its assertions about whether these things are instructions, whether these things are responses, to back up what it's talking about.

[00:28:56] Speaker 01:
And I'd like to go back also to Judge Toronto, your line of questioning about the make-a-choice alleged instruction in Tassin, and I think the The key problem with that is even if you assume that there is instruction to make a choice there, even if you assume that the server is instructing a choice, it doesn't specify the action to be performed, and it's not an instruction through which the content flow manager controls the flow of content because the choice puts the control with the client, and the need to control...

[00:29:38] Speaker 02:
not perhaps on choice, but on the underlying condition that will drive the choice. So why is that still not an instruction? Download it unless asked.

[00:29:52] Speaker 01:
I think the choice is download it or not. And what Cassidy is describing is just kind of sending all the stuff and the client decides what to do with it. And that is the fundamental control problem that the 559 patent is designed to solve. It's instead meant to gather information about what should you get. And if you look in the second paragraph, this wherein paragraph about multimedia content, it talks about the processor is configured to control the flow. So it's got to be the processor, which is the content flow manager. That's what claim one calls it. is configured to control the flow, it has to do the controlling.

[00:30:26] Speaker 01:
If there are no further questions, we'd ask this court to reverse.

[00:30:29] Speaker 02:
Thank you, counsel. Casey, submit it.