[00:00:00] Speaker 03:
241406, Centripetal Networks versus Keysight.

[00:00:05] Speaker 03:
Mr. Wall, nice to see you again.

[00:00:08] Speaker 01:
Judge Prost, good to see you too.

[00:00:09] Speaker 01:
May it please the court?

[00:00:11] Speaker 01:
The board began in the wrong place, so it ended in the wrong place.

[00:00:16] Speaker 01:
It began by construing a term packet flow entry that the parties were not disputing.

[00:00:21] Speaker 01:
Centripetal would have explained that based on the claim language, a packet flow is a single computing session between two endpoints or hosts

[00:00:29] Speaker 01:
but a packet flow entry can be broader and can cover multiple flows.

[00:00:34] Speaker 01:
Question for you, counsel.

[00:00:36] Speaker 04:
At the board's hearing, Judge McNamara said the claim defines packet flow entry.

[00:00:44] Speaker 04:
I'm quoting.

[00:00:44] Speaker 04:
There's an oasis there.

[00:00:46] Speaker 04:
as an entry that consolidates a plurality of packet log entries corresponding to a common thread identifier.

[00:00:53] Speaker 04:
How can you argue that packet flow was undefined or unconstrued if packet flow entry was defined?

[00:01:00] Speaker 01:
So Judge Wallach, it's really important to understand the way this proceeded.

[00:01:05] Speaker 01:
The parties in their briefs before the board were disputing packet flow.

[00:01:10] Speaker 01:
And then in their reply, Keysight pointed to flow log entry.

[00:01:16] Speaker 01:
And we filed a cert reply to address that.

[00:01:19] Speaker 01:
And the board got that part right.

[00:01:20] Speaker 01:
It said at page 16 in the appendix, no, not flow log entry.

[00:01:24] Speaker 01:
Keysight's wrong about that.

[00:01:25] Speaker 01:
That's not part of the claims.

[00:01:27] Speaker 01:
At the hearing, you were right.

[00:01:28] Speaker 01:
At the hearing, the focus became on packet flow entry.

[00:01:32] Speaker 01:
But what the board went on to do in its decision that was not a subject of discussion at the hearing

[00:01:36] Speaker 01:
was to focus on figure six, the threat dashboard, the user interface in the spec, and to say, ah, that's the packet flow entry, that's organized, this is the language you're reading, that's information that's organized with respect to a common thread identifier.

[00:01:52] Speaker 01:
Each of those entries in the user interface can cover multiple flows, so that means a flow isn't just a session between two endpoints, it's just data with some common characteristic, like common thread identifier.

[00:02:04] Speaker 01:
And that piece of it, relying on the user interface, never briefed or argued.

[00:02:09] Speaker 01:
If you read that entire passage, Judge Wallach, there is no discussion of the use of the user interface.

[00:02:15] Speaker 04:
In your blue brief, you say if the board had informed the parties it might construe PAC flow entry, you would have addressed that.

[00:02:27] Speaker 04:
But didn't you address it in your server apply?

[00:02:31] Speaker 01:
In our surreply, we were focused on Keysight's argument, which was flow log entry.

[00:02:36] Speaker 01:
There are some references to packet flow entry, but that wasn't the focus of the party's dispute.

[00:02:43] Speaker 01:
Nobody was calling for it to be construed.

[00:02:44] Speaker 04:
And the critical point is... But you said that the red box in 5G was a further consolidation of packet flow entries made up by packet flow entries corresponding

[00:02:57] Speaker 04:
to traffic from threat host C and so on.

[00:03:00] Speaker 01:
So that was really a separate argument, Judge Wallach.

[00:03:03] Speaker 01:
And the board rejected it.

[00:03:04] Speaker 01:
And the board rejected that.

[00:03:05] Speaker 01:
It absolutely did.

[00:03:05] Speaker 01:
I think it's footnote 16 of its decision, but it did.

[00:03:08] Speaker 01:
It rejected that argument.

[00:03:09] Speaker 01:
But that's really separate from what we're talking about here.

[00:03:12] Speaker 01:
The argument here is

[00:03:14] Speaker 01:
What the board said is, if you look at the user interface, the thing that the person ultimately sees in Figure 6, the dashboard, those are packet flow entries.

[00:03:23] Speaker 01:
And you can reason backwards, and those show you what a flow is.

[00:03:27] Speaker 01:
And no one had briefed or argued that, and it never came up at the hearing.

[00:03:30] Speaker 01:
There's no discussion of the user interface at Figure 6.

[00:03:33] Speaker 04:
What you're saying, as I get it, is that the board should have directly addressed packet flow.

[00:03:38] Speaker 04:
that that was the issue.

[00:03:40] Speaker 04:
But where does packet flow appear by itself in the 917?

[00:03:46] Speaker 01:
Oh, it doesn't.

[00:03:47] Speaker 01:
I think we all agree on that.

[00:03:50] Speaker 01:
OK.

[00:03:50] Speaker 01:
Why should the board have considered something that's not in the packet?

[00:03:52] Speaker 01:
Because in order to understand the terms that are in the claim, like packet flow analysis data or packet flow entry,

[00:04:01] Speaker 01:
You need to understand first what a packet flow is in order to build on that.

[00:04:06] Speaker 01:
Now, if the board had jumped straight to packet flow entry and gotten it right, I guess you could say, well, they never needed to understand the building block in order to understand the building.

[00:04:16] Speaker 01:
But the problem was by not starting with the building block and by jumping straight to the second story, they got it wrong.

[00:04:23] Speaker 04:
But you say that packet flow, just flow level data, is special, right?

[00:04:32] Speaker 04:
What's so different about that data as opposed to other data?

[00:04:35] Speaker 01:
So I'm not a computer network.

[00:04:36] Speaker 04:
Why is this night different?

[00:04:37] Speaker 01:
Can I give you an analogy?

[00:04:38] Speaker 01:
Because I'm not a computer network security guy.

[00:04:41] Speaker 01:
But this is the way I think about it, because I'm a sports person.

[00:04:43] Speaker 01:
I think about it like baseball, because that is something I know pretty well.

[00:04:46] Speaker 01:
The packets are like pitches coming across the plate.

[00:04:51] Speaker 01:
The flows are the at-bats.

[00:04:53] Speaker 01:
They're grouping the pitches by a particular session between the pitcher and the hitter.

[00:04:58] Speaker 01:
And as anybody who follows baseball knows, there is a world of difference between a database of just the pitches in a game or a season and the pitches organized by at-bat that you can see by the hitter and over time.

[00:05:11] Speaker 01:
It's true for baseball, and it's true for computer network security.

[00:05:14] Speaker 01:
But you need the first before you can do the second.

[00:05:16] Speaker 01:
You do.

[00:05:17] Speaker 01:
But that's the first part of the claim.

[00:05:19] Speaker 01:
Everybody agrees that in claim one, the first step of our claim one is you generate the packet log data.

[00:05:23] Speaker 01:
Everybody's doing that.

[00:05:25] Speaker 01:
Sourcefire is doing that, too.

[00:05:26] Speaker 01:
It's that in our claim one, there is then an updating part where you are pulling data, the packet flow analysis data, and you are updating these packet flow entries.

[00:05:37] Speaker 01:
That's the grouping by at-bat and hitter.

[00:05:40] Speaker 01:
And none of that's going on in source fire.

[00:05:42] Speaker 01:
So if the board had started with packet float and done the claim construction properly, the anticipation of the obvious analysis would have fallen out pretty easily.

[00:05:52] Speaker 01:
What specifically, then, is float in the context of the pet?

[00:05:58] Speaker 01:
It's exactly what it is.

[00:06:00] Speaker 01:
The ordinary meaning of a flow is the data exchange as part of a given connection or session between two endpoints.

[00:06:09] Speaker 01:
And the board accepted Judge Wallach at page 16 of the appendix that that was the ordinary meaning.

[00:06:15] Speaker 01:
We had testimony on that.

[00:06:16] Speaker 01:
It's at page 72, 94 of the appendix from an expert.

[00:06:19] Speaker 01:
It wasn't disputed.

[00:06:20] Speaker 01:
No one disagreed with it.

[00:06:21] Speaker 01:
So it wasn't like the board said, oh, this isn't the ordinary meaning.

[00:06:25] Speaker 01:
You've done your own lexography.

[00:06:27] Speaker 01:
What the board did was it said, OK, look, maybe that's the ordinary meaning.

[00:06:31] Speaker 01:
But we think if we look at packet flow entry,

[00:06:34] Speaker 01:
we can see that you must be using flow in a different way.

[00:06:39] Speaker 01:
And by jumping to packet flow entry on the basis of orders.

[00:06:42] Speaker 04:
But how does that?

[00:06:43] Speaker 04:
You say that renders packet flow entirely meaningless.

[00:06:47] Speaker 01:
No, I don't think it renders packet flow meaningless.

[00:06:50] Speaker 01:
I was agreeing with you.

[00:06:51] Speaker 01:
Packet flow is not a separate term in the claims.

[00:06:54] Speaker 04:
But in your opening brief, you say, I'm quoting, that board's construction of packet flow entry renders the term packet flow analysis data entirely meaningless.

[00:07:03] Speaker 01:
Well, yes, if you understand that in context, which is to say, if you think that this patent is no different from Sourcefire, Sourcefire is just packet log data.

[00:07:13] Speaker 01:
It's just the pitches.

[00:07:14] Speaker 01:
It's just every packet coming across the network.

[00:07:16] Speaker 04:
But I have a real problem with your brief on that point.

[00:07:20] Speaker 04:
Where do you squarely engage with the term?

[00:07:25] Speaker 01:
Which term does log?

[00:07:28] Speaker 04:
The term packet flow analysis data is entirely meaningless.

[00:07:33] Speaker 04:
and the term packet flow entry rendering that, I thought you never engaged with it squarely.

[00:07:42] Speaker 01:
So I'm sorry if we weren't clear there, Judge Wallach, but here's what we were trying to say, which is sourcefire has this packet log data, just the packet information.

[00:07:51] Speaker 01:
And then the user can query that.

[00:07:53] Speaker 01:
If that's all the 917 patent is in the eyes of the board, then that updating limitation in claim one, where you take the packet flow analysis data and you use it to update packet flow entries, it essentially is read out of the packet.

[00:08:07] Speaker 01:
Because whatever that's doing, and we can debate whatever it's doing, there's no longer any role for it.

[00:08:14] Speaker 01:
Because if all we're doing in the eyes of the board is what Sourcefire does, packet log data, and then user can query, you can pull the pitches,

[00:08:23] Speaker 01:
You can ask particular questions about what those pitches are.

[00:08:25] Speaker 01:
Then all of that stuff in our patent about packet flow analysis data and packet flow entry, it can't be doing any work.

[00:08:32] Speaker 01:
It can't mean anything anymore.

[00:08:34] Speaker 01:
Because all you needed was a packet log data and a user interface that allows them to query it.

[00:08:39] Speaker 01:
And everything in between doesn't mean anything anymore.

[00:08:42] Speaker 01:
And I'm sorry if we didn't make that clear in the brief, but that's what we were trying to get at.

[00:08:45] Speaker 04:
OK, I'm not going to hog you anymore.

[00:08:46] Speaker 04:
I like the dialogue.

[00:08:48] Speaker 01:
I think this has been exactly what I wanted to say.

[00:08:52] Speaker 01:
I think my point is just, if you read claim one,

[00:08:58] Speaker 01:
You see the packet log data, and you see the user interface at the end.

[00:09:02] Speaker 01:
But if all we're talking about is just a database of packet log data that the user can play around with, all of the stuff in the middle of claim one, the updating limitation, I don't know what it's doing anymore.

[00:09:13] Speaker 01:
And I think the board missed that because it started in the wrong place.

[00:09:17] Speaker 01:
I don't ultimately need you to agree with those arguments, though, because under Axonics, all I need you to say is,

[00:09:23] Speaker 01:
The board rested this on something, figure six in the spec and the user interface, that nobody ever briefed and wasn't even argued at the hearing.

[00:09:31] Speaker 01:
And so just send it back to the board, and we can have these arguments in front of the board.

[00:09:35] Speaker 01:
And then if we need to, we'll come back up to this court.

[00:09:37] Speaker 02:
I think that's the- Let's put aside that procedural argument for just a second.

[00:09:40] Speaker 02:
What is your response to, on the merits, what the board said about 5G?

[00:09:45] Speaker 02:
in 6G.

[00:09:46] Speaker 02:
If I understand your baseball analogy, and hopefully baseball season, it's just around the corner.

[00:09:53] Speaker 02:
It looks like multiple batters and their at-bats are being listed in 5G and 6G.

[00:09:59] Speaker 02:
If I understand that correctly, how do you reconcile that with your reading?

[00:10:03] Speaker 01:
So the board got 5G right.

[00:10:05] Speaker 01:
The board said, look, he cites saying this about flow log entries.

[00:10:09] Speaker 01:
Flow log's not in claim one.

[00:10:11] Speaker 01:
And so we're not going to focus on that.

[00:10:14] Speaker 01:
The problem was then it jumped to figure six, which is the user interface.

[00:10:18] Speaker 01:
Those are not the packet flow entries.

[00:10:20] Speaker 01:
If you look at claim one, it says take the packet flow data, pull the packet flow analysis data out of the log data, use it to update the packet flow entries, then cause that to be displayed to the user in an interface.

[00:10:35] Speaker 01:
The packet flow entries are separate from and before you start displaying to the user interface.

[00:10:42] Speaker 02:
So implicit in what you're saying, if I'm following, is if one read, say, 6G as packet flow entries, then you must be wrong about what packet flow entries and packet flows are.

[00:10:55] Speaker 01:
No, we would lose on claim construction then.

[00:10:59] Speaker 01:
But we would still have the arguments on obviousness that there are elements of this patent that are not disclosed by source fire.

[00:11:07] Speaker 01:
Because you've still got the time data, which is important in both cases.

[00:11:11] Speaker 01:
You can't use the time data in source fire the way that you can use the time data in the way this claim requires.

[00:11:18] Speaker 01:
You still have the fact that you're not

[00:11:19] Speaker 01:
the packet filtering device isn't updating the packet log entries.

[00:11:24] Speaker 01:
It all has to be done by the user in Sourcefire.

[00:11:26] Speaker 01:
So I think you're right, Judge Stark.

[00:11:28] Speaker 01:
If you thought the board got the

[00:11:31] Speaker 01:
oh, those are packet flow entries, even though not even Keysight argued that below.

[00:11:35] Speaker 01:
I think they would acknowledge that.

[00:11:37] Speaker 01:
They've grabbed onto it now, but they didn't argue it below.

[00:11:39] Speaker 01:
I think we'd be wrong on claim construction, but we still ought to win on obviousness.

[00:11:43] Speaker 01:
Because there are at least two big things, right?

[00:11:45] Speaker 01:
There's the time data, and there's the fact that this is a system that is updating itself using the packet filtering device.

[00:11:51] Speaker 01:
At Sourcefire, it's all user queries.

[00:11:53] Speaker 01:
There's no sort of system updating going on.

[00:11:57] Speaker 01:
And I think we can all agree there's a world of difference between a system where you the user have to go try to filter the data to try to find the threats and the system is itself trying to detect the threats and updating the network security.

[00:12:09] Speaker 04:
Sourcefire can be used in a fashion that does update on its own.

[00:12:14] Speaker 01:
Well, you can query it in order to get the data by a common thread identifier.

[00:12:19] Speaker 01:
So the user can query it to create the kind of entries or data that Judge Stark was talking about.

[00:12:26] Speaker 01:
So in that one way, you're right, Judge Wallach.

[00:12:28] Speaker 01:
You can use Sourcefire in that way.

[00:12:29] Speaker 01:
It has other problems, which is the user has to do the querying.

[00:12:33] Speaker 01:
The time data is a real problem.

[00:12:36] Speaker 01:
And then that setting aside, the deep-ended claims that have things like time ranges,

[00:12:41] Speaker 01:
which aren't even possible in Sourcefire because it's just time for each particular packet.

[00:12:46] Speaker 01:
You can't create a range.

[00:12:48] Speaker 01:
And then, of course, we obviously have the cross appeal because there are the additional elements on 4 and 14.

[00:12:54] Speaker 01:
So there are additional problems, but you'd be right.

[00:12:56] Speaker 01:
The user can use Sourcefire to create one particular kind of data.

[00:13:01] Speaker 01:
It's just that alone is not enough for them on obviousness.

[00:13:18] Speaker 00:
Good morning, your honor.

[00:13:19] Speaker 00:
So may it please the court, Gerard Donovan, on behalf of Keysight.

[00:13:22] Speaker 00:
Centripetal's appeal comes down to what the 917 patent actually says, what Sourcefire actually discloses, and what the board actually found and why.

[00:13:30] Speaker 00:
When you consider the actual record, you end up exactly where the board did.

[00:13:33] Speaker 00:
And Centripetal wants a do-over on appeal, and the controlling standard review provides no path to reversal.

[00:13:39] Speaker 00:
Starting with the 917 patent,

[00:13:41] Speaker 00:
Centripetal bases its arguments on a construction of packet flow that's contrary to what the patent discloses and doesn't address the specific claim elements at issue.

[00:13:50] Speaker 00:
The board rejected Centripetal's proposed construction because it can't be squared with patent.

[00:13:54] Speaker 03:
And what say you to the process arguments your friend has raised?

[00:13:58] Speaker 00:
The APA argues that it wasn't raised initially.

[00:14:00] Speaker 00:
It was raised repeatedly throughout the process.

[00:14:05] Speaker 00:
In centripetal's initial response before the board, it argued for a construction of packet flow entry.

[00:14:13] Speaker 00:
But then it incorporated that argument regarding the construction of packet flow entry into its construction of packet flow.

[00:14:21] Speaker 00:
And then it incorporated that construction into its interpretation of packet flow entry to compare it to the source file reference.

[00:14:27] Speaker 00:
And that was at appendix H2.

[00:14:30] Speaker 00:
I'm sorry.

[00:14:35] Speaker 00:
7245 in their centripetal response before the board.

[00:14:41] Speaker 03:
And you put forward no claim construction.

[00:14:43] Speaker 03:
But is that a fair interpretation to say because you didn't think they needed to be endpoints, so it didn't have this limitation?

[00:14:51] Speaker 00:
I am our position was construction wasn't required because source are meets the claims even under that construction.

[00:14:58] Speaker 00:
But also the board needed to resolve the claim construction dispute to the extent necessary to resolve the dispute between the parties and the reference itself.

[00:15:06] Speaker 00:
Sorry.

[00:15:06] Speaker 00:
The patent itself, the 907 patent, teaches that both the flow log entries are updated based on log entries.

[00:15:13] Speaker 00:
That's expressed in the specification.

[00:15:16] Speaker 00:
And it explains within the claim that the flow log entry is based, let me make sure I get the language right.

[00:15:31] Speaker 00:
where in each packet flow, entry consolidates a plurality of packet log entries corresponding to common thread identifier.

[00:15:38] Speaker 00:
And because that's expressed in the claim, that means that it's not consolidating

[00:15:42] Speaker 00:
packet flow, any other information.

[00:15:44] Speaker 00:
So what packet flow might mean or flow might mean outside of the context of the claims isn't the issue here.

[00:15:51] Speaker 00:
The claims don't recite packet flow standing alone.

[00:15:55] Speaker 00:
And the specification, as you mentioned, never recites a packet flow.

[00:15:59] Speaker 00:
Instead, we're analyzing what packet flow entry and packet flow analysis data mean in the context of the claims.

[00:16:06] Speaker 00:
And on that front, the claims are expressed.

[00:16:09] Speaker 00:
It's also consistent with the specification, which to go to the baseball analogy, what the specification discloses is analyzing and logging specific packets as they come in.

[00:16:21] Speaker 00:
So you create log entries for each packet, and there's information with that, such as the thread ID and the time for each packet.

[00:16:28] Speaker 00:
It then takes the packets related to common thread IDs and it uses that information to generate these flow log entries.

[00:16:36] Speaker 00:
The flow log entries are based on thread ID, but those consolidate packets across communication sessions, across different endpoints, and when those packet flow log entries are updated,

[00:16:49] Speaker 00:
They're then updated to reflect additional packets, independent of the connection or the endpoints, just based on the thread ID.

[00:16:56] Speaker 00:
That's the same information that's then later used to update the interface.

[00:17:00] Speaker 00:
And this is in the patent on appendix 92, the bottom of column 15, where at step 67, it's referring to updating the flow log entry based on the packet log information.

[00:17:12] Speaker 00:
And then at step 68, it's using that information to update the interface.

[00:17:16] Speaker 00:
So when the claims are read in the context of the specification, it's clear what packet flow entry means in the context of the patent.

[00:17:26] Speaker 04:
Before you sit down, I have a couple of questions for you about your cross appeal.

[00:17:34] Speaker 04:
Yes.

[00:17:38] Speaker 03:
But before, could you just touch briefly on the second portion of Mr. Wall's argument, which is even accepting the claim construction of the board, there still was no substantial evidence to support the obviousness?

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

[00:17:52] Speaker 00:
So even accepting the claim, well, whether you accept the claim construction of the board or not, I would say even under Mr. Wall's construction, what the board's fact finding was, was that Sourcefire discloses logging individual packets and information associated with those packets.

[00:18:06] Speaker 00:
And then consolidating that information into flow log entries.

[00:18:10] Speaker 00:
And this is disclosed in Sourcefire by disclosing, first, you can see in the log where you have the packets, the rule with the rule ID that identifies the threat that's corresponding to it, the various timing data for the packets, the IP address that it comes from and to.

[00:18:26] Speaker 00:
And then it generates the packet flow entry, which is going to be a consolidated view of that.

[00:18:30] Speaker 00:
It has the counts of packets that correspond to the different threats.

[00:18:47] Speaker 00:
That's a pages appendix 953 and 954.

[00:18:51] Speaker 00:
And that count in 954 is showing the packet flow entry as the board found, because that's consolidating the packets from the packet log that are associated with the thread.

[00:19:01] Speaker 00:
And so whether we adopt, under the board's construction, it's just straightforward that that's meeting the packet flow entry requirement.

[00:19:09] Speaker 00:
But even under centripetal's construction, that would require that the packet flows be connections between endpoints.

[00:19:16] Speaker 00:
the board's findings still establishes that that packet flow entry is consolidating packet flows between endpoints into the packet flow entry because the nature of packet communications, every one of these logs, sorry, log entries is a packet that's within a communication session.

[00:19:34] Speaker 00:
And so the entire session will be logged in this process and that will all be incorporated into this count that's updated.

[00:19:42] Speaker 00:
Does that answer the question?

[00:19:43] Speaker 00:
I'm sorry, just to touch on one related point from my counsel, just to complete the baseball analogy.

[00:19:51] Speaker 00:
It's going right from pitches to the final product.

[00:19:54] Speaker 00:
There is no at bat type of data here.

[00:19:56] Speaker 00:
The patent discloses only the concept of

[00:20:00] Speaker 00:
it being inconvenient to review logs and so you want to consolidate logs into these flow log and packet flow entries to make it easier to review the data.

[00:20:08] Speaker 00:
Also on the refresh point, council said that Sourcefire only refreshes when there's a user selection and that's not correct and the board found otherwise.

[00:20:16] Speaker 00:
It's true that to navigate to a screen a user needs to select where they navigate When you configure a refresh interval then it will refresh according to that refresh interval and in order for it to update a packet flow entry There needs to be additional packets that come in and cause that that refresh to update the entry so if you have a one-minute refresh

[00:20:37] Speaker 00:
and no additional packets come in associated with a specific threat, there won't be an update or a modification of that entry because you don't have additional packets coming in.

[00:20:45] Speaker 00:
But if you have five more packets coming in corresponding to threat one, then at that refresh, the system will automatically refresh that entry to show the additional five packets.

[00:20:55] Speaker 00:
So you have the system performing the refresh, not the user doing it.

[00:20:59] Speaker 02:
I have one more on the appeals.

[00:21:01] Speaker 02:
Yeah, sure.

[00:21:03] Speaker 02:
I just didn't want to lose it.

[00:21:04] Speaker 02:
Yeah, got it.

[00:21:05] Speaker 02:
And you've sort of touched on it, and there may not be more to say.

[00:21:09] Speaker 02:
But they argue, for instance, at the Bluebrief at page 59, that you've not addressed centripetal's argument that the device itself had to update the packet flow entry.

[00:21:20] Speaker 02:
And you've never suggested that the limitation could be satisfied by a user entering manual queries in the interface.

[00:21:27] Speaker 02:
Could you just address those arguments?

[00:21:29] Speaker 00:
Sure, and so our petition put forward that the refresh interval shows the device performing the update, and so whether a user needs to configure whether there's a refresh interval is orthogonal to the issue of whether or not the device itself is doing the update.

[00:21:46] Speaker 00:
So I think they're correct that a user can configure what the refresh interval is.

[00:21:50] Speaker 00:
Sourcefire also disclosed that a user can pause the window so that you don't see the refreshes anymore.

[00:21:57] Speaker 00:
But the petition explained that it's the refresh itself, which is the device performing the update.

[00:22:03] Speaker 00:
And when you go to one of these screens in Sourcefire, you will see it refresh.

[00:22:08] Speaker 00:
And the system will be, the Sourcefire IDS will be performing the analysis, updating the packet flow entry, causing that to be displayed.

[00:22:17] Speaker 00:
And you will see the updated display based on the refresh interval.

[00:22:20] Speaker 00:
And that's because the system is detecting the packets that trigger the rules, logging those, creating the flow entry, the consolidated entry with the count, and then causing that to be displayed.

[00:22:30] Speaker 04:
Thank you.

[00:22:32] Speaker 04:
Sure.

[00:22:35] Speaker 04:
In your cross-appeal opening brief, the red brief, you argue that drill-down pages are populated with a subset of columns available in the database.

[00:22:45] Speaker 04:
Thus an existing column in the database includes the count, and therefore the packet flow log entry that is used to update the packet flow entry in the interface.

[00:22:55] Speaker 04:
Did you argue that specific point, that drill down page's point about containing a subset of columns that are available in the database before the board?

[00:23:12] Speaker 00:
I believe it was in petitioners' reply.

[00:24:03] Speaker 00:
I'm not seeing that specifically in our apply.

[00:24:05] Speaker 00:
I'll look further and see if I can find specifically.

[00:24:07] Speaker 00:
I will say that the board's finding, I think even absent the database disclosure, which Sourcefire clearly includes, the board's finding did recognize in its final written decision that Sourcefire discloses updating the packet flow log entry in response to additional packets satisfying the rules.

[00:24:27] Speaker 00:
And this was in the board's decision at- I know they did.

[00:24:30] Speaker 00:
OK, appendix 30.

[00:24:31] Speaker 00:
And I'll say that I think under the correct construction of responsive to, even without the underlying database disclosure, sourcefire still meets that.

[00:24:40] Speaker 00:
Because what you see in the user interface, and this was in the petition itself, is that there is the entry.

[00:24:45] Speaker 00:
And in order to update or modify that entry, you have to modify the data that provides that entry.

[00:24:50] Speaker 00:
So even without the database disclosure, you still get to sourcefire disclosing what's required by claims 4 and 14.

[00:24:58] Speaker 03:
And there was no official claim construction, right?

[00:25:00] Speaker 03:
So where in the board did you come up with a claim construction for responsive to?

[00:25:06] Speaker 00:
Hi.

[00:25:07] Speaker 00:
So the board's decision distinguished between the based on language in claim one and the responsive to language in claims four and 14 by asserting that responsive to required something else in claims four and 14 and finding that centripetal's arguments that you get to it from either a user triggering it or the refresh interval, that that wasn't responsive to the packet coming in.

[00:25:30] Speaker 00:
And that construction, or that implicit construction, is saying that it must be solely or exclusively responsive to the packet because you won't have an update to the count unless the differential packet's triggered a rule.

[00:25:43] Speaker 00:
And so by finding that having to have a refresh interval was not enough, that was implicitly construing to say having a refresh interval as well is required.

[00:25:52] Speaker 00:
And this court has held that the plain meaning of responsive to does not exclude additional steps.

[00:25:59] Speaker 00:
This was addressed recently in this board's decision in the centripetal versus Palo Alto case.

[00:26:05] Speaker 03:
Even if we accept your argument, is a remand not necessary?

[00:26:09] Speaker 03:
Yeah, that was my question.

[00:26:10] Speaker 00:
I think it depends.

[00:26:11] Speaker 00:
If there's a factual question about the database disclosure or the evidence that needs to be resolved by the board, then a remand would be necessary.

[00:26:18] Speaker 03:
But what's your best argument?

[00:26:20] Speaker 00:
I think the argument is that the board's own finding in context of the independent claims that Sourcefire discloses updating this entry based on the additional packets coming in establishes under the correct construction that the claims are invalid.

[00:26:32] Speaker 00:
The other part of this Claims 4 and 14 is that this data must indicate whether the packets are allowed or blocked, and it must indicate

[00:26:39] Speaker 00:
The rule that goes with them and again the board's independent claim analysis Looking at another interface but interface that shows the same information Found that the left-hand column and source fire that has the arrows indicating whether or not you dropped it

[00:26:53] Speaker 00:
indicates this information whether packets are allowed or dropped and the central column that has the message which includes the rule indicates the rule and The data itself that's updating the count by updating that count you are indicating which packets are allowed or blocked based on that so if a packet is

[00:27:11] Speaker 00:
You know, it goes from 30 to 31 for a row that is blocked associated with rule and threat one.

[00:27:18] Speaker 00:
And updating that 30 to 31 indicates both whether it was blocked or allowed in the rule.

[00:27:25] Speaker 00:
And with that, I'll reserve the rest of my time.

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

[00:27:35] Speaker 04:
OK, you're in the fourth quarter on the 10 yard line.

[00:27:40] Speaker 01:
I'm going to have three quick running plays, and we'll see if I score.

[00:27:43] Speaker 01:
So the first is on claim construction.

[00:27:46] Speaker 01:
On the procedural point, counsel points to page 7245 of the appendix.

[00:27:51] Speaker 01:
That's the section of our response where we're talking about packet flow.

[00:27:55] Speaker 01:
We refer at one point to packet flow entry

[00:28:00] Speaker 01:
and we just define the language from the pattern that's packet flow entry.

[00:28:05] Speaker 01:
The idea that that sort of made this all about packet flow entry isn't right, but in any event, it's not the critical point.

[00:28:10] Speaker 01:
Critical point is, it's not what the board set.

[00:28:12] Speaker 01:
The board turned to figure six and the user interface

[00:28:15] Speaker 01:
So that's the packet flow entry, and that tells you what the packet's about.

[00:28:19] Speaker 01:
And figure six was never on the table, not in the briefs, not at the hearing.

[00:28:22] Speaker 01:
There is no mention of it.

[00:28:24] Speaker 01:
And Axonic says that's not fair or right under the APA.

[00:28:27] Speaker 01:
We ought to be able to go back to the board and address that, so it's a simple remand.

[00:28:32] Speaker 01:
On the obviousness analysis, I think there are three elements of the claim that aren't tracked.

[00:28:37] Speaker 01:
But the easiest one to see is the time data.

[00:28:39] Speaker 01:
There is no way to manipulate or play with time data from multiple packets in Sourcefire.

[00:28:44] Speaker 01:
You can't do it.

[00:28:45] Speaker 01:
And the easiest way to see that is for some of the deepinit claims 3 and 13.

[00:28:50] Speaker 01:
They have a time range.

[00:28:52] Speaker 01:
You cannot generate the time range in Sourcefire.

[00:28:55] Speaker 01:
So I think that alone gives them a problem on obviousness.

[00:28:58] Speaker 01:
On the cross appeal, I think they're really overcomplicating what the board did.

[00:29:04] Speaker 01:
The board didn't do claim construction.

[00:29:06] Speaker 01:
It said, OK, responsive to, what is this in response to?

[00:29:11] Speaker 01:
Well, if the user doesn't click anything and doesn't set a refresh interval, nothing happens.

[00:29:17] Speaker 01:
This packet requires that the updating occur responsive to a determination by the packet filtering device.

[00:29:24] Speaker 01:
And the court board said not as a matter of claim structure, but as a matter of fact, that is not in fact what happens with Sourcefire.

[00:29:31] Speaker 01:
This packet requires that the packet filtering device make a determination that causes the updating.

[00:29:38] Speaker 01:
And that doesn't happen in Sourcefire.

[00:29:40] Speaker 01:
And I don't think anybody disputes as a matter of fact that doesn't happen in Sourcefire.

[00:29:44] Speaker 01:
The board also correctly said it pays $38 of the appendix.

[00:29:47] Speaker 01:
And those claims 4 and 14 require existing packet flow log entries

[00:29:54] Speaker 01:
And there are no existing entries in Sourcefire because there's nothing until the user himself clicks or sets a refresh interval based on some parameters and then creates the entries

[00:30:05] Speaker 01:
him or herself using the source fire system.

[00:30:09] Speaker 01:
There's nothing existing, and the updating isn't being done responsive to a determination by the packet filtering device.

[00:30:16] Speaker 01:
I think the board got that all completely right.

[00:30:19] Speaker 01:
And so whatever the court does with respect to the main appeal, though we'd urge the court to send it back to the board, it ought to affirm with respect to claims four and 14.

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

[00:30:29] Speaker 01:
Thank you.

[00:30:39] Speaker 03:
and only on the cross field.

[00:30:42] Speaker 00:
Yes, so just for claims four and 14, I just want to make the point that under the proper construction of these claims, I think the board's findings themselves show that what Sourcefire is disclosing is refreshing the entry that's shown on screen when additional packets satisfy the rules.

[00:31:04] Speaker 00:
The refresh interval takes you to that.

[00:31:07] Speaker 00:
even if a user must navigate to the screen, and that's what causes it to be displayed in the first instance, once the user does, you have that number on screen, and that number will update, the system will cause that number to be updated based on the additional packets satisfying the rules.

[00:31:21] Speaker 00:
That will cause this entire process of, well, the system on its own will be logging the packets, the associated thread IDs, consolidating that information, and then when that's being displayed by the user, it will be updated if there's a refresh interval or it's not paused,

[00:31:35] Speaker 00:
Based on the additional packets and so the the source fire itself discloses that the board found that in the context of the independent claims when properly construed that supports Reversal on splints for 14.

[00:31:47] Speaker 00:
Thank you