[00:00:01] Speaker 00:
The United States Court of Appeals for the Federal Circuit is now open and in session.

[00:00:07] Speaker 00:
God save the United States and this honorable court.

[00:00:13] Speaker 02:
Good morning.

[00:00:14] Speaker 02:
We have four cases set for argument this morning.

[00:00:19] Speaker 02:
The first one is going to be the plus D panel, which I'm sure that everyone has been informed on as to the procedure.

[00:00:27] Speaker 02:
Uh, I'm going to call the first case for this morning.

[00:00:31] Speaker 02:
That's net fuel, Inc.

[00:00:32] Speaker 02:
Versus Hirschfield number 21 dash 1520.

[00:00:36] Speaker 02:
Mr. I understand you have reserved three minutes to rebuttal.

[00:00:42] Speaker 01:
Is that correct?

[00:00:44] Speaker 01:
Yes, your honor.

[00:00:44] Speaker 01:
That's correct.

[00:00:46] Speaker 02:
All right.

[00:00:46] Speaker 02:
You may proceed.

[00:00:47] Speaker 02:
We're ready to go.

[00:00:49] Speaker 01:
This is Enrique.

[00:00:50] Speaker 01:
Terralde for propellant net fuel and the decision below.

[00:00:54] Speaker 01:
or to sample the patchwork of the petitioner's contention and arrive at compulsory determinations without a properly articulated analysis and without the required findings of fact.

[00:01:07] Speaker 01:
Of the arguments presented on briefing, I would like to focus on the limitations monitoring operational parameters relating to the each thread, including a per thread utilization for each thread.

[00:01:24] Speaker 01:
The term thread does not appear in any way, shape, or form in the Linskog references.

[00:01:29] Speaker 01:
Rather, the board repeated petitioner's arguments mapping Linskog's network resources to the claims thread.

[00:01:37] Speaker 01:
Respectfully, this court should not endorse such an interpretation as it is not based in fact, and frankly, it is offensive to the computer arts.

[00:01:47] Speaker 01:
Additionally, the mapping of Linskog's network resource to the claims thread

[00:01:53] Speaker 01:
inconsistent with the board's adoption of the construction of a threat, which was construed to mean... Council, this is Judge Raito.

[00:02:03] Speaker 02:
But when you combine Tourette's multi-threaded system, and you combine that with Lynxon's hierarchical node structure, then the claim limitation that you're speaking about is satisfied, correct?

[00:02:19] Speaker 01:
Respectfully, Your Honor, we would disagree with that.

[00:02:22] Speaker 01:
And the reason for that is based in part on the board's adoption of the construction.

[00:02:35] Speaker 01:
And so the construction, or the term thread itself, was the execution of a section of code independently within a software program, rather than

[00:02:49] Speaker 01:
describe an execution of a section of code, Lintdog merely refers to a network resource.

[00:02:58] Speaker 01:
And this network resource is a logical resource or physical device.

[00:03:03] Speaker 01:
Logical resources are location areas or zones for network devices.

[00:03:10] Speaker 01:
Examples of physical devices are computers, routers, and servers.

[00:03:16] Speaker 01:
For example, in a network system, as you described, Your Honor, an anomaly can take place at a particular network router or server, or it can take place at a location area designated with some logical name for that network.

[00:03:32] Speaker 01:
In both examples, the resources are physical, not software.

[00:03:36] Speaker 04:
Mr. Carlton, this is Judge Ken speaking.

[00:03:41] Speaker 04:
As I understand it, the board saw that

[00:03:45] Speaker 04:
this particular reference, Lenscog was talking about logical resources, you know, and, and found that that was something different than hardware, because I believe it said something about logical resources and or hardware devices.

[00:04:00] Speaker 04:
And then it also, Lenscog also talked about checking for hardware faults or software faults.

[00:04:08] Speaker 04:
So therefore the board concluded that Lenscog reasonably read

[00:04:12] Speaker 04:
is talking about looking at resources that are software for software-based faults.

[00:04:20] Speaker 04:
So if we were to assume that is all a reasonable reading, then there's still the next question of making the leap from monitoring software network resources to monitoring threads.

[00:04:39] Speaker 04:
And my understanding is you

[00:04:42] Speaker 04:
You take issue with that, and I would like you to speak to that question.

[00:04:48] Speaker 01:
Yes, Your Honor.

[00:04:49] Speaker 01:
And that is correct.

[00:04:51] Speaker 01:
That is our position.

[00:04:52] Speaker 01:
And we would contend that simply monitoring resources is not enough to satisfy monitoring operational parameters that include per thread utilization.

[00:05:06] Speaker 01:
The board relied on a layering of implications to get from physical devices

[00:05:12] Speaker 01:
to the software, and then to the threads.

[00:05:16] Speaker 01:
And that's not sufficient evidence.

[00:05:18] Speaker 01:
When you're looking at the Linskog reference, there's no disclosure of threads at all.

[00:05:25] Speaker 01:
When you do look at, when you turn to the Turric reference, there is a disclosure of threads in the context of Java generally.

[00:05:37] Speaker 04:
And so if we look at- Is software as a general matter made up of threads?

[00:05:45] Speaker 01:
Not necessarily, Your Honor.

[00:05:46] Speaker 01:
And there needs to be threading.

[00:05:54] Speaker 01:
Threading has to be part of the architecture.

[00:05:56] Speaker 01:
It has to be part of the design.

[00:05:58] Speaker 01:
And so merely reciting software or some applet or a software agent

[00:06:07] Speaker 01:
doesn't necessarily mean that the software is designed in a threaded manner and is handled in a threaded manner.

[00:06:16] Speaker 04:
Well, I understand that, but my understanding of the board's decision is, assuming, excepting that Linscock is monitoring software resources and that software can be made up of threads, why wouldn't it be

[00:06:35] Speaker 04:
reasonable to conclude that LensCog, among other things, is monitoring software threads?

[00:06:47] Speaker 04:
Is there something about the context of what's going on in LensCog that makes it unreasonable to make that jump to conclude that LensCog is monitoring software threads?

[00:07:04] Speaker 01:
But there's simply no disclosure of monitoring threads or of monitoring portions of software.

[00:07:12] Speaker 01:
There's just generally the disclosure of an agent that looks at software or looks at logical resources, which themselves are not software.

[00:07:28] Speaker 01:
And so there's no underlying infrastructure or, you know,

[00:07:33] Speaker 01:
no underlying infrastructure to perform both monitoring of threads, but also the further limitations, such as the performing a corrective action for the detected abnormalities and additional subsequent limitations.

[00:08:01] Speaker 04:
I guess what I'm wondering is,

[00:08:03] Speaker 04:
Because Linscog is monitoring faults at a network-wide level, why would Linscog care about the status of individual threads and individual network resources inside individual nodes?

[00:08:24] Speaker 01:
I don't think that Linscog would care.

[00:08:25] Speaker 01:
I don't think that's a problem that Linscog was addressing.

[00:08:33] Speaker 01:
Because Lundsgaard doesn't mention threads at all, it's just not even a problem that they were addressing.

[00:08:39] Speaker 01:
That's sort of a granular level of monitoring software where it's a different invention.

[00:08:52] Speaker 01:
It wasn't envisioned during the writing or drafting of Lundsgaard reference.

[00:09:00] Speaker 04:
Can you explain what

[00:09:03] Speaker 04:
per-thread utilization means?

[00:09:09] Speaker 04:
Sure.

[00:09:10] Speaker 04:
Did the board understand it correctly at A68?

[00:09:13] Speaker 01:
Sorry, Your Honor, did you say A68?

[00:09:34] Speaker 01:
That's right.

[00:10:04] Speaker 01:
Do you see where I am?

[00:10:06] Speaker 01:
I'm trying to navigate there right now, page 68.

[00:10:10] Speaker 03:
Just so you're clear, this is appendix page 68, not the numeral eight.

[00:10:19] Speaker 03:
Oh, sorry.

[00:10:23] Speaker 01:
I thought you said 868.

[00:10:24] Speaker 03:
No, appendix page 68, the board's opinion.

[00:10:29] Speaker 01:
Yes, OK.

[00:10:36] Speaker 01:
Right, so per thread utilization with the monitoring the usage of threads and there's a disclosure within the 659 pattern and I will direct your honors to that in a minute.

[00:11:02] Speaker 04:
Can you just focus for me a second on

[00:11:05] Speaker 04:
JA-68, where the board is reporting out what the patent owner argued during the board hearing.

[00:11:14] Speaker 04:
That thread utilization is a fairly established concept, particularly when it comes to something like CPU utilization in the thread.

[00:11:22] Speaker 04:
How much of a CPU's time is being utilized by a thread, or how much of the physical resource is being utilized by that thread?

[00:11:31] Speaker 01:
Yes, Your Honor.

[00:11:34] Speaker 01:
Yes, Your Honor, I see that.

[00:11:35] Speaker 01:
And yes, that's a fair characterization of what we understand per thread utilization to mean.

[00:11:47] Speaker 01:
OK.

[00:11:51] Speaker 04:
So why is that missing from the references?

[00:11:56] Speaker 01:
So the per thread utilization, as I mentioned earlier,

[00:12:07] Speaker 01:
The closest that the board actually gets to explaining the per-thread utilization is based on an implication.

[00:12:15] Speaker 01:
If you look at Appendix 45, the board states, quote, in the context, Linscout's views of the generic term fault in conjunction with receiving alarm data and processing the data and other similar

[00:12:33] Speaker 01:
teachings discloses monitoring and determining hardware and software faults on a per-thread basis.

[00:12:40] Speaker 01:
In the context of LINSCOG, receiving alarm data from one or more monitored resources implies running software threads.

[00:12:51] Speaker 01:
LINSCOG itself, as I mentioned, does not disclose threads and not disclose portions of threads.

[00:13:01] Speaker 01:
or portions of software that it's monitoring and then taking corrective action on.

[00:13:07] Speaker 01:
Instead, Linskog is generally referring to what it calls false.

[00:13:16] Speaker 02:
Councilor, you're into your rebuttal time.

[00:13:18] Speaker 02:
Do you want to take a pause now, or do you want to go on?

[00:13:22] Speaker 01:
I will just, if you don't mind, Your Honor, I'll just state one last thing, and so finally after

[00:13:29] Speaker 01:
So it's undisputed that per-thread utilization is one of the monitored operational parameters, which is later subject to the detecting abnormality limitations and performing corrective action limitations of claimed inventions.

[00:13:44] Speaker 01:
The PCO failed to make any findings effective with respect to per-thread utilization for these later limitations.

[00:13:51] Speaker 01:
And now, Your Honor, I'll reserve my time for rebuttal.

[00:13:55] Speaker 02:
Okay, thank you.

[00:13:59] Speaker 02:
Councillor Craven.

[00:14:02] Speaker 00:
Yes, good morning, Your Honours, and may it please the Court.

[00:14:05] Speaker 00:
Netfield fails to show reversible error in the Board's obviousness decision.

[00:14:09] Speaker 00:
The claims here recite a broad method of monitoring and correcting faults in software resources in a distributed computer network, and the Board found that the prior art taught all the limitations of the claim

[00:14:21] Speaker 00:
as well as that a person of skill in the art would have been motivated to combine the references.

[00:14:25] Speaker 00:
And substantial evidence supports each of these findings.

[00:14:29] Speaker 00:
Starting where Netfield does with the limitation, monitoring operational parameters related to each thread, and then more specifically monitoring per thread utilization.

[00:14:39] Speaker 00:
The board found that Linskog or alternatively Linskog in combination with TURIC discloses this limitation.

[00:14:46] Speaker 00:
And NetFuel is arguing that LinSCOG system doesn't monitor software, just hardware, but that argument ignores the board's findings regarding monitoring logical resources and detecting software faults.

[00:15:00] Speaker 04:
So I guess this is where I'm having concerns with Judge Shen.

[00:15:07] Speaker 04:
Even if we were to accept the finding that the resources that are being monitored in LinSCOG in all these different nodes across the network

[00:15:15] Speaker 04:
are can be software resources, why is it fair to say that Linscog is contemplating looking at this more granular level of individual threads within each software program?

[00:15:34] Speaker 00:
Your Honor, Linscog

[00:15:36] Speaker 00:
Discloses is a board found that the monitoring of network resources happens at multiple levels.

[00:15:42] Speaker 00:
So the example it gives of hardware is not only does it monitor the entire base station, but a single circuit of a base station.

[00:15:50] Speaker 00:
And so for software at the more granular level, the board found that that would be monitoring software threads.

[00:15:59] Speaker 00:
And the board also found that the monitoring would be threads that are running independently, so software code that runs independently of the larger software program because the system can resolve faults at one network resource, one selected network resource versus other network resources, and that would show that the threads are running independently.

[00:16:27] Speaker 00:
And so that's the reasoning for why not only are you monitoring software resources at a broader level, but at the more granular level that you would be monitoring threats.

[00:16:38] Speaker 03:
This is Judge Toronto.

[00:16:40] Speaker 03:
So that there's one further level in that claim, which is that the monitoring specifically is monitoring

[00:16:49] Speaker 03:
per thread utilization, which I understand to be how much of certain kinds of or any kind of computer resources and individual running of an individual independently runnable set of instructions is consuming.

[00:17:07] Speaker 03:
Where is that in either Glenscog or the combination with the other reference?

[00:17:17] Speaker 00:
The board starts with the fact that the 659 patent is disclosing the monitoring per thread utilization by its disclosure of the R monitoring the software threads within it, running within that R as load balancing.

[00:17:35] Speaker 00:
So balancing the threads on that particular runtime and the idea of load balancing.

[00:17:40] Speaker 00:
And then the board relies on Lynn Scog's disclosure of load balancing as then being

[00:17:48] Speaker 00:
the disclosure of per-thread utilization.

[00:17:53] Speaker 00:
And so let me see if I can get some more per-thread.

[00:18:02] Speaker 03:
And if you can point to initially the pages of the board decision, that would be helpful.

[00:18:09] Speaker 03:
And then, of course, whatever those pages are referring to in Linscock and

[00:18:17] Speaker 00:
Right, so I think starting at JA-68 is, I mean, there's a lot of discussion.

[00:18:24] Speaker 00:
At 66, the board discusses the disclosure of load balancing in the patent and then goes on at JA-68, the idea that Linskog is disclosing

[00:18:44] Speaker 00:
monitoring these high traffic levels from network resources.

[00:18:48] Speaker 00:
So you have your network resources that are providing traffic levels.

[00:18:53] Speaker 00:
And that traffic level is actually the performance data that the agents are monitoring.

[00:18:58] Speaker 00:
But that traffic level is coming from each level of the network resources.

[00:19:02] Speaker 00:
So it's protecting various network resources from overload caused by this too high traffic level being offered.

[00:19:09] Speaker 00:
And the idea that that is then the

[00:19:12] Speaker 00:
the monitoring of the per thread utilization when you're monitoring that network resource down at the level of a thread.

[00:19:21] Speaker 00:
And so after the full complete paragraph on J68, the last sentence is that the petitioner's showing applies this well-known thread utilization techniques to the well-known threaded resources for the purpose of correcting these utilization

[00:19:39] Speaker 00:
related faults like overload.

[00:19:41] Speaker 00:
So Linskog's disclosure of these overload protection if you're monitoring the network traffic from the resources at the level of threads at that lower level that this is per thread utilization.

[00:19:56] Speaker 00:
And we could go to the Linskog's specifics.

[00:19:59] Speaker 04:
Ms.

[00:19:59] Speaker 04:
Craven, just so I understand, the newer and the board's theory of what you would get when you do

[00:20:10] Speaker 04:
the combination of the references.

[00:20:12] Speaker 04:
You wouldn't necessarily, you'd be doing something extra and beyond what the references are doing, because as I understand what the references are doing is maybe they're looking at traffic data across the entire network.

[00:20:29] Speaker 04:
And here, as I understand it, you're saying, well, in the combination of references, not only would you still be doing that, but you would be doing this other thing, which is

[00:20:41] Speaker 04:
looking into the individual threads that make up a particular software resource and making determinations and calculations of how much the individual threads in a program are consuming a CPU resource.

[00:21:02] Speaker 04:
Is that what you're saying?

[00:21:03] Speaker 00:
That's correct.

[00:21:04] Speaker 00:
The monitoring in LINSCOG of network resources occurs at multiple levels.

[00:21:09] Speaker 00:
So not only would you be monitoring a broader network resource, a base station or a larger resource, but you would also be monitoring at a lower level, the single circuit level, which in software would be the single thread level, and that protection of overload at that level of the system monitoring would be monitoring

[00:21:31] Speaker 00:
the utilization of the threads in the software to perform the load balancing in the same way that you're getting that disclosure in the 659 patent.

[00:21:45] Speaker 00:
And that relies on Lynn Skog's disclosure of getting the raw traffic from each network resource at the different levels.

[00:21:55] Speaker 00:
And the board also relies on Turek's disclosure of

[00:21:58] Speaker 00:
network usage monitoring and that usage at the lowest level at the circuit or thread level would be per thread utilization which NetFuel has conceded is a well-known concept in the art for how you understand threads to be used in the system and their load balancing to be monitored in the system.

[00:22:24] Speaker 03:
Can you just, this is Judge Duranto, just to check you, I think you said a couple of times that Linskov talks about monitoring hardware at different levels down to the

[00:22:38] Speaker 03:
I don't know, the circuit level, and by analogy, moving down in levels on the software side, which Liz also talked about, would be to go to the thread level.

[00:22:52] Speaker 03:
Is that your analogy, or does the board itself say that on the software side, as opposed to the hardware side, monitoring in LINDSOT goes down to

[00:23:06] Speaker 03:
the level of the independently operable instruction.

[00:23:12] Speaker 00:
So I think the best site for that, this is JA58 and the paragraph, the only full paragraph on that page is the board responding to NetFuel's argument that there isn't monitoring at the thread level because the resources are monitored as a whole.

[00:23:34] Speaker 00:
and talking about the monitoring of a base station then as the monitoring of a resource as a whole.

[00:23:40] Speaker 00:
And the second, I think it's the second sentence says, contrary to this testimony that Linskog only determines that the base station as a whole is malfunctioning, then Linskog discloses monitoring at much smaller, the smaller individual levels including single circuit, and then goes on to talk about how

[00:23:58] Speaker 00:
the testimony regarding abnormalities also then doesn't account for petitioners' persuasive showing that the Linskog and Turk together show the obviousness of running Linskog's resources as threads.

[00:24:11] Speaker 00:
And so I see that connection as you're monitoring at the single circuit level in a base station.

[00:24:16] Speaker 00:
And so when you're monitoring the software, you're monitoring it at the level of a thread.

[00:24:30] Speaker 04:
Just so I understand, the board's theory is not that through the combination you would be checking individual threads at different nodes.

[00:24:48] Speaker 04:
It's checking the threads of a single program that's located at a single node.

[00:24:55] Speaker 04:
Is that right?

[00:24:56] Speaker 04:
Because the concern I had was the board was saying, well, you're checking different resources at different nodes.

[00:25:03] Speaker 04:
And so you can just check thread one at node one and check thread one at node two.

[00:25:14] Speaker 04:
And that would be satisfying the claim.

[00:25:18] Speaker 04:
But those two threads would not be within the same program.

[00:25:23] Speaker 04:
Nor would they be using the same computer resources.

[00:25:27] Speaker 00:
Right, I think because the nodes are monitoring multiple resources, not just a single resource, that you would understand that as monitoring threads at a single node.

[00:25:38] Speaker 00:
So on the larger level, the entire software program may be the network resource, but it comprises threads.

[00:25:46] Speaker 00:
And at the lower, more granular level, at the smaller unit level, that you'd be monitoring threads

[00:25:53] Speaker 00:
as multiple network resources at a single node.

[00:25:55] Speaker 00:
And because you have multiple threads running there, that you would be able to do the load balancing because you have to compare the threads used on the CPU to each other to do per thread, monitoring per thread utilization.

[00:26:15] Speaker 04:
But at the same time, if a particular software program is located at a node and that software program is the resource

[00:26:23] Speaker 04:
that's being monitored and it's made up of multiple threads, you could map onto the claim by monitoring those particular threads, the parameters of those particular threads within that given software program resource, right?

[00:26:46] Speaker 00:
Correct, yes.

[00:26:48] Speaker 00:
I would agree with that.

[00:26:50] Speaker 04:
I'm trying to figure out what's the cleanest

[00:26:52] Speaker 04:
mapping onto the claim.

[00:26:57] Speaker 04:
In terms of... Rather than... I heard you say, well, you know, there can be multiple resources at a single node, and so you can just look at any threads that are located that node, even if those different threads are across different software programs, and then I don't

[00:27:17] Speaker 04:
that wouldn't make sense when it comes to per-thread utilization because as I understand per-thread utilization, you're trying to measure out the relative load of individual threads within a particular program that are operating independently.

[00:27:35] Speaker 00:
Right, and I don't think the threads that you monitor have to be in different software programs.

[00:27:40] Speaker 00:
The software program, the broader software program could be executing multiple

[00:27:46] Speaker 00:
threads of code independently within that program.

[00:27:51] Speaker 00:
And each of those threads within the same software program being monitored would be the monitoring the per thread utilization.

[00:27:59] Speaker 00:
I don't think it has to be threads in different software programs.

[00:28:09] Speaker 00:
Does that make sense?

[00:28:13] Speaker 04:
I understand your answer.

[00:28:16] Speaker 00:
Okay.

[00:28:21] Speaker 00:
And therefore, the board's finding of monitoring per thread and per thread utilization is supported by substantial evidence.

[00:28:33] Speaker 00:
And unless there is any other questions, ask this court to affirm the board's obviousness decision.

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

[00:28:42] Speaker 02:
Do we have any other questions?

[00:28:45] Speaker 02:
Hearing none, let's go on back to Mr. Piotrle.

[00:28:50] Speaker 02:
You have three minutes.

[00:28:53] Speaker 01:
Thank you, Your Honor.

[00:28:54] Speaker 01:
So the fundamental issue here is that there is no clear mapping from the board.

[00:29:00] Speaker 01:
The most granular level of resources that the board and the PTO identify is the monitoring circuits for high traffic levels.

[00:29:10] Speaker 01:
That is completely inconsistent with the board's adoption of the construction of a thread.

[00:29:15] Speaker 01:
to mean the execution of a section of code independently within a software program.

[00:29:21] Speaker 01:
We agree with Judge, that's a P test.

[00:29:23] Speaker 02:
Counselor, in listening to my colleagues questioning, the notion of substantial evidence came up again.

[00:29:33] Speaker 02:
Can you tell me, reflecting back to the conversations that my colleagues had with counsel,

[00:29:41] Speaker 02:
Where is it that the board lacks substantial evidence in its decision?

[00:29:48] Speaker 01:
Yes, Your Honor.

[00:29:49] Speaker 01:
The board lacks substantial evidence in finding per-thread utilization in either of the references, in combination or separately.

[00:30:02] Speaker 01:
There is just simply no, neither reference looks into software.

[00:30:08] Speaker 01:
either reference monitors threads of software, just generally at a high level reciting that the reference contains an agent and implying that there can be some threads is not substantial of this.

[00:30:27] Speaker 01:
And so we would submit that the PFAB is... How about if they found there could be some threads?

[00:30:36] Speaker 02:
Not implying, as you say,

[00:30:38] Speaker 02:
that made a finding that there were such threats.

[00:30:40] Speaker 01:
Is that substantial evidence?

[00:30:48] Speaker 01:
That would not be a finding based on substantial evidence.

[00:30:50] Speaker 01:
Respectfully, Your Honor, that would not be a finding based on substantial evidence, according to what we've reviewed in the Ford's analysis, which is mostly a regurgitation of the petitioner's arguments and not an actual analysis of the

[00:31:06] Speaker 01:
of the references themselves that the finding itself would not be based on substantial evidence.

[00:31:14] Speaker 01:
Okay.

[00:31:18] Speaker 01:
And so with that, we agree with Judge Chen's comment that it appears that the board and the PTO are adding or relying on something that is not actually recited in the references.

[00:31:32] Speaker 01:
The board appears to be relying on an implication or a set of implications as to what may be in software, but threads are just simply not recited in either of the references.

[00:31:47] Speaker 01:
And so we submit that there's no substantial evidence to support the board's final written decision, and we respectfully rest on the papers unless Your Honors have any further questions.

[00:32:02] Speaker 02:
Okay, thank you very much.

[00:32:04] Speaker 02:
Thanks to counsel for this argument.

[00:32:08] Speaker 02:
This court will now take a short recess.