Oral argument — Trustees of Columbia v. Symantec Corporation

Good morning. I'd like to address several errors that we believe are of claim construction from the decision of the Board. The first one I'd like to address deals with the construction of the term application community. Now that was actually construed by the Board as members of a community running the same program or a selected portion of the program. We thought it was pretty clear that program refers to the program in the body of the claim, which is used throughout the body of the claim because that's what is being modeled and monitored. The PTAB, though, very narrowly construed the claim when applying it and actually took the word program to mean a worm. Well, we run into this problem, this issue a lot in claim construction cases and sometimes called the O2 micro issue. So you got the construction you wanted or I don't know that there was no dispute about the construction. I think that's right. So now you're here and we've got to figure out whether this is even a claim construction question because it's in a little different box, right? Right. And I think it is. And I think you can tell that it is in the following way, which is there's no dispute about the scope or the content of the prior art. We're not arguing about that issue at all. It's literally a question of what's the program? What does that mean in the claim construction? Is it satisfied? And how does your view of program, how does it walk me through the steps about why that then dislodges the obviousness conclusion or is it the anticipation? It dislodges an anticipation or an obviousness conclusion. And all the claims implicated? The claims that are implicated by this case, by this issue, are all in the 115 patent and there are claims 1, 3 through 8, 11, 13 to 18, and 21, which were found obvious over a combination of Kazan and Arnold, except for claims 3 and 13, which added Agrawal. But this would be, I believe, dispositive of the issue if the term program is understood to mean, as in the body of the claim, the program that is being monitored. Claim 1, I think, is representative. It's a method of detecting anomalous program executions, comprises a number of steps, executing at least a part of the program, comparing a function call made in an emulator to a model of function calls for a part of the program, and then upon identifying an anomalous function call, you notify an application community of the anomalous function call. And it's in that context that you have the definition of an application community, members of the community running the same program or a selected portion of the program. It seems to me that that part of the spec that defines it, that you point to as defining application community, it defines more community as opposed to application. I think it does both. I believe the path that you're referring to is at column 7, excuse me, at lines 31 to 47. And if you look at the language, I think it pretty clearly demonstrates that the application that's in the application community is essentially the program that's being referred to in the body of the claims. So let's look at that language. It says in column 6 of that passage, models are shared among many members of a community running the same application, referred to as an application community. For example, instead of running a particular application for days at a single site, according to various embodiments, thousands of replicated applications can be run for short periods of time, and the models created based on the distributed data can be shared. That is exactly talking about the use of a community that engages in this process of creating models and of using models to look for anomalous function calls. And then it goes on to say, while only a portion of each application instance may be monitored, for example, the entire software body can be monitored across the entire community. This is talking about the concept of monitoring and modeling and using an application community to solve a problem in the prior art, which was there's a lot of computing power that's required to create these models. But what if we in fact use an application community to monitor the program or parts of a program? It completely makes the claim almost incomprehensible if the word program in the claim can be a worm, because then you would have a claim that would read on detecting anomalous executions of a worm. And then the claims would be directed at monitoring when a group of computers, all of which are already infected with a worm, act in a way that differs from how an already infected computer acts. That's just strange and bizarre. There are a number of issues in this case. What's number two? Because there's one I want to get to. I don't know if it's the same one you want to get to. Well, I'm happy to get to one that you'd like to get to. Maybe it's not top to your list, because I think it only affects two claims, but it's the model that reflects the task. That question. Are you referring to the anticipation argument after claims 29 and 39? Right. Let me briefly attack that. So this deals with whether Kazan anticipates. And what is very unusual about the analysis here is that there's no argument about what the Kazan invention is. Kazan basically looks at a model created using a static picture of the program code. And it is doing what's called anomaly detection. It's trying to determine what's different from the normal execution of the program. What's different from the Columbia patent is that it's not using actual execution or usage. It's talking about a static model. But it's anomaly detection. What was unusual, and I think incorrect, about the board's decision is that it took a passage from the background section on a prior art method called misuse detection. Misuse detection is much different. That's just a matter of you have essentially a collection in a database of applications of worms. So just to cut to the chase, is it your argument that they shouldn't have looked at paragraph 9 at all, either because it's misuse detection or because it deals with the prior item, wasn't the invention? Or is it your argument tied to sort of your claim construction point about it should have done known, and therefore we should not go paragraph 9 on that basis? No, it's independent of that. In other words, separate and apart from any claim construction issue, they're actually looking at something which is completely irrelevant and different than the invention, which is disclosed and claimed. On the basis of the board's big saying, I mean, what was their rationale for, I think I agree with you, and we'll see if your friend disagrees, but that they did combine what was in the prior, what was that paragraph 9, and then what was in the invention? It's absolutely the case. Paragraph 9 is part of the background, and it's described, it's talking about the existing systems, and it has a disclosure that under the prior art misuse detection systems may miss, for example, slight variations of known MC malicious code that knew previously, and knew previously unseen instances of MC. Which means, so there could be stuff, it could be unknowing. That's where the board got its unknowing? That's correct. Well, here, the board took this as, I'll read exactly what it says. Are you on page 22? I am on page 22. Kazan explicitly states to one of ordinary skill in the art that malicious code may be included in the model. And that's not Kazan's model. That is a prior art misuse detection model, which Well, what if, let's assume, I know we're going to say that that's different because it dealt with malicious and non-anomaly, but let's say it didn't. I mean, can't you, can you do anticipation based on the prior art included in, can you, well, I don't know, maybe it's obviousness, but could you do an obviousness thing by combination of the prior art disclosed in the patent, and then what's in the patent, and then you combine the two? Conceivably if there's a linkage, but there's no linkage here. In other words, one is a prior art misuse detection system, which is different than the invention in the patent. They don't operate in anything like the same way. And there is no But do you think, was that what the board was saying, though, that we're going to take these two pieces as if they were part of the, you know, and then, and then under that analysis there's anticipation? I don't think the board's analysis really went that deep. It just took the two passages. It found that in paragraph 9 you had this, quote, explicit disclosure that malicious code may be included in the model, but it's not Kazan's model. It's a prior art model. And there's no suggestion or linkage between that prior art misuse detection system and the Kazan anomaly detection. There's no passage in the Kazan reference disclosing the use of a program code unknowingly infected with malicious code to build Kazan's static model that is used to determine normal activity. It's just not there. And so that's why you have this bizarre combination of some language, short language from inscription of the prior art misuse system with the Kazan model. It is a, because there's no linkage, I think there is error as a matter of law, but even if you applied a substantial evidence test, I don't think this would stand up, because there's literally no connection. It is apples and hardwood floor. It's not even apples and oranges. Do you want to continue rebuttal or is there some other issue you want to raise? I will save the rest for rebuttal. Good morning, Your Honors. Michael Saxtetter, Fenwick & West, on behalf of Symantec. I'll take the issues that Mr. Gendler discussed just now and I'll start with the most recent one, the model reflecting attacks. And there are actually two issues there. First is what is purported to be a claim construction issue that relates to more of the claims. And it's pretty clear that it wasn't a claim construction issue, that it was not raised after the institution decision and we think that there is just no reason for that to be an issue on appeal. The second issue is what happens in Kazan and how the board handled the disclosures of Kazan and how the board handled other evidence that was submitted to it as well. Kazan, as has been mentioned, discusses in its background section that models sometimes get attack data into them. You know the technology, but there are two separate distinct detection systems, right? One is misuse and one is anomaly, is that right? That's correct. And Kazan, nobody is disputing, that's the anomaly one and that's what the patent issue is about, right? Kazan does anomaly detection, correct. So the board then went into this prior reference in the paragraph which clearly deals with misuse detection, which isn't part and parcel of the Kazan invention. I mean, I think that's what your friend said. Is that right? Do you dispute any of the kind of fact statements that your friend made? I don't dispute what you have just said, Your Honor. What I think is important, though, is that Kazan does misuse detection. And it discloses that there are circumstances where attack data inadvertently gets into the model. And that happens. And then Symantec's expert, Dr. Goodrich, said the same thing. And he said, this just happens. And so you are going to have situations where attack data is inadvertently included in the model. And there's not much way to avoid it. But we don't know that for a fact, correct? I mean, it could be included. I'm sorry? I said we don't know that for a fact. The attack data could be included, but we don't know whether it is or not. It can be. And it often is. Is that enough for a disappointment? That's what our expert said, is that it could be included in the model and that happens. But it discloses there's this problem in the Kazan invention. It doesn't have anything to do with that. There isn't any mention of it in the section that discusses the anomaly detection technique. It's a sort of theoretical matter. What framework has the board used? They've said, okay, Kazan does one thing. What it's invented is not anticipatory by itself of the claims at issue. So we're going to have to figure out how we're going to add to that an unrelated piece. I mean, even if there was obviousness, you'd have to have a motivation to combine the two. This is anticipation, right? But exactly. This is anticipation, which is disclosure in one reference. And the inclusion of, inadvertent inclusion of attack data in a model is disclosed in the single reference and then Dr. Goodrich specified it. But not what to do with it, then. I mean, it's disclosed in the model, but then doesn't, don't the claims at issue do a lot more than that? The claims at issue don't talk about how the attack data got into the model. They say, it's dependent claims that say wherein the model includes attack data. That's it. And there may be other discussion in the specification, but that hasn't been read into the claims. It's in claim construction before the board or any other place. And so the claims just say that the issue is that, that what needs to be disclosed in a prior art reference is that attack data is included in the model and that's what is disclosed. My question was whether it's actually disclosed in, in the, in the prior art or not. It just, it seems to me, and you were using the word also, that malicious code could be included, but we don't know that. I was referring to. Is that, is that sufficient participation? I was referring to the evidence from Dr. Goodrich when I said that. I believe his words were that it could be included. And it is something that, that the board determined would be expected to be included based on the disclosure of Kazan and based on Dr. Goodrich's testimony. And that, that was the board's finding that we contend is supported by substantial evidence. I was looking at the board's language where they cited the language of Kazan that discloses the idea that the attack models may contain errors as a result of unforeseen attack information. And I'm just wondering whether that's just too much of an illusion. Whether it. There's certainty that, that, that the model can contain the, the same attack models. Can also flip the normal models. Well, most of the challenge patents don't address whether there is attack data included in the model. It is a, you know, there's a reference that says sometimes this happens in the patent, and that's what the, the board relied on. The board may have chosen its words poorly when it said may. But I think when it happens sometimes, that that is disclosed by the reference. Move on to application. Application community. Sure. So, this is another issue, and, and Your Honor recognized it, that they got the construction they wanted. This was an agreed construction, and now what we're doing, and we actually do it on a couple of terms here, is construing the construction. And trying to determine what the, the, the term in the construction that was agreed, the same program means. Now, Columbia appears to be asserting that that was narrowly construed to mean only a worm. That is not what the board did when the board applied the agreed construction to the disclosures that were. So what is the, what is the patent owner supposed to do in these circumstances? Okay, they thought everybody was on the same page in terms of what program meant, and then the board goes ahead and applies it, and clearly their thinking is different. I mean, this happens a lot in district court proceedings. Sometimes the district court goes back and says, okay, I need to construe this. The board didn't do that here, right? The board did not do that, but, but there was no attempt to do that after the institution decision in this case. Is that, yeah, I don't think there was, there was ever any, any attempt to say, wait a minute, they're making this other argument, and they're applying as a factual question the construction in a way that we didn't anticipate it. I don't think that was raised before the board. You know, you, you can do that, as, as your honor said, in the district court, if you have a, a situation where that's happened, you go back and say, wait a minute, I think we're not on the same page. That didn't happen. We had a situation where the claim term was construed by agreement. The board read that claim term on the arguments that had been made, and the attempt to construe the construction now is to say that the same program has to be only the sort of untouched program that was the one that was being monitored. That's taking the same program, a, the construction was member, yeah, the members of a community running the same program or a selection, selected portion of the program. So, so what Columbia's trying to do is reconstruct the same program from the construction to mean only the application that is being monitored. But what, what the reference does is that it says that, that you notify the application community, basically. You notify other computers that are running whatever thing happened on your computer. So if it's, for instance, the, the kill signal that gets sent out includes, for instance, the name of the virus and the signature of the virus that has attacked the program that was running. Or if there's a worm, then the worm gets sent, that's what a worm does, it gets replicated and sent to other computers, and then it is a program that is running on all those computers. And there's no dispute that a worm is a program. So what happens is you're, you're trying to, you're doing exactly the same thing. And you are causing the same benefit by going out and notifying other computers to say, hey, something happened to me that was a problem. I need to tell you about it too. And that's what happens. And that is, that satisfies the construction of application community in this case. Your view is that, that the application community has to be running on the same application. Is that correct? That is, well, that's the construction. Members of a community running the same program or a selected portion of the program. I'm reading out of the appellant's brief and they're, they're citing to the patent and the definition of application community. They say that despite this clear definition, the PTAB held that an application community exists as long as the members are infected with the same worm, regardless of whether they're running on the same application. And you dispute that part regardless of whether they're running on the same application. I think our point was that the worm itself is an application. The worm is a program. But there are also, in the Arnold reference, there are, you know, they don't just talk about worms. They talk about programs that you're running that are then infected with a virus. And when you send a kill signal for those, what you do is you send out something that identifies the virus and a signature of the virus. So then you really are talking about the same application potentially. That it is a program that's running on your computer that is also having an issue on the other computers or potentially is. And so you say, hey, stop your programs because you're going to get infected. So two basic ways that the program that is referenced in the claim construction can be running on the other computers. And that was a question of fact that the board resolved and is subject to substantial evidence. I have about one minute for our cross-appeal. Actually, I have zero minutes for our cross-appeal. Well, you can spend a minute and a half and then save a minute for rebuttal. I don't know. It's up to you. Or we can rest on the briefs. Actually, I think the briefs are clear. If I come back first to the issue of claims 29 and 39 of the 115 patent, I think what you heard counsel argue is a reliance upon their expert and not relying upon the disclosure in paragraph 9. And their expert does say, and I'll just quote the language, it is sometimes difficult to find clean, attack-free training sets for training an intrusion detection model. Well, that's not talking about paragraph 9. This is an expert talking about how he would, as a person of skill in the art, think about training sets. But the key word here, of course, is sometimes. Because it would have to be all the time in order to say that the Kazan reference necessarily discloses it. It would have to be an inherency argument. And I think it's pretty difficult to get to inherency land from this statement by Symantec's expert. Does the disclosure have to cover all of the time, really? I mean, it covers 80% of the time it does this and 20% of the time it does that, even if the anticipatory reference is to that 20%. Right. But that's really a different question. Because what he's talking about is not the disclosure. See, he's not referring to paragraph 9, which talks about the prior art misused detection systems, because that has nothing to do with training sets. Training sets are only used for anomaly detection. Here he's just making a statement about how one of skill in the art would think about an anomaly detection system that uses training sets. What the board says is Kazan explicitly states to one of ordinary skill in the art that malicious code may be included in the model. I presume that's a reference to paragraph 9. Exactly. Isn't that not a correct statement? So it's a correct statement of what takes place in a prior art misuse system, which has absolutely nothing to do of any kind whatsoever with the Kazan model of anomaly detection. Kazan's model of anomaly detection is building a model of normal computer activity by looking at computer code. But what do we require in anticipation? This is simplistic, but a claim includes two different things. And you've got a piece of prior art, and its invention is one of those things, and the other thing is included in other prior art that's cited in the second patent. Why isn't that sufficient for anticipation? Because for anticipation, the prior art has to arrange the disclosure. The disclosures have to be arranged as in the claim. It's not just enough that the words appear here and there. That's the key issue. You have to have the disclosures arranged as in the claim. This isn't even close to being arranged as in the claim because Kazan's model is a model of normal computer usage. It's not doing what the prior art misused detection systems did, which was just look up if there is an example of malicious code and see if it matches. But what if the claim just took prior art and what's in Kazan and combined them into one system? If they were arranged as in the claim, that would work. The problem isn't so much limited to the fact that it's prior art, but that it's completely unlinked prior art, which has nothing to do at all with Kazan's disclosed invention. But isn't it an obviousness inquiry then? Well, these claims were not invalidated based upon an obviousness inquiry. I understand that. Well, that would then be a single reference obvious analysis, which was never raised below and I don't think would work in this instance. Thank you. Thank you very much. Thank you both sides and the cases. The next case for argument is 17-1347, CPC Broadband versus Corning Optical.