[00:00:02] Speaker 03: We have three argued cases this morning. [00:00:05] Speaker 03: The first of these is number 162515, Microsoft Corporation versus Parallel Networks. [00:00:11] Speaker 03: Mr. Trela. [00:00:17] Speaker 02: Thank you, Your Honor, and may it please the Court. [00:00:20] Speaker 02: The Parallel patents claim a method for dealing with website congestion by spreading the processing of requests for web pages among multiple servers. [00:00:29] Speaker 02: Because others had already come up with that solution, Parallel tried to distinguish its claims by focusing on the term dynamic web page generation request to a web server and arguing that its system required that there be only one such request, while the prior art systems, in particular this web reference, required multiple requests. [00:00:49] Speaker 02: But request has a broad meaning, a message that asks for a web page. [00:00:54] Speaker 02: And with that broad meaning, it was clear that the web server in this web system [00:00:58] Speaker 02: received one request, and then the SWEB system processed that same request. [00:01:04] Speaker 02: So before the board, Parallel argued that things like the router request takes, the package it's in, how it's processed. [00:01:13] Speaker 01: Suppose I disagreed with you about your characterization of what was being built into the board's view of where one request stops and another one starts. [00:01:26] Speaker 01: All the board said was when the client, the client computer that is, has to re-initiate a message for whatever it is seeking, there is a new request. [00:01:45] Speaker 01: We don't care what the router is. [00:01:46] Speaker 01: We don't care what the URL is. [00:01:49] Speaker 01: I think you had a third thing. [00:01:50] Speaker 01: I'm not sure what the? [00:01:51] Speaker 02: The package, whether it's an HTTP request. [00:01:56] Speaker 01: Right. [00:01:56] Speaker 01: Why is that not a sensible and maybe even, I guess we have to say, in the Phillips sense, the most reasonable construction of what this patent uses as the boundaries of a request? [00:02:14] Speaker 02: Here's why, Your Honor. [00:02:16] Speaker 02: To reach the conclusion that the fact that the client computer was involved again makes it a new request, [00:02:25] Speaker 02: The board must have been thinking either that a request has to go directly from the web server to the page server, or that somehow the client computer, if it doesn't and it does touch other things, one of those things cannot be the client computer. [00:02:40] Speaker 02: But none of that is in the claims or in the patents. [00:02:43] Speaker 03: Well, did you ask the board to clarify the claim construction in this respect? [00:02:48] Speaker 03: You seem to be saying, if I understand it, that you agree that there is a one request [00:02:55] Speaker 03: limitation in here, but that that means that the user can only make one request, not that the computer can't redirect, not to use the confusing word, the computer can't make a second request if the first request doesn't work out. [00:03:16] Speaker 02: We did not ask for a clarification because it didn't seem like we needed one. [00:03:21] Speaker 02: The construction was a message that asked for a web page. [00:03:24] Speaker 03: And of course, the board didn't. [00:03:26] Speaker 03: Well, given the fact that there was no clarification, why isn't it? [00:03:30] Speaker 03: I mean, this is sort of like the Hewlett-Packard thing where we have instructions to the jury and there's an effort later on to come up with a new claim construction. [00:03:39] Speaker 03: It seems to me that's a bit what you're doing here, that if you accept the board's claim construction, it's reasonable to think that under these circumstances that there is a second request here. [00:03:53] Speaker 02: No, I don't think that's correct, Your Honor, and here's why. [00:03:58] Speaker 02: Because the patent makes clear that none of this routing or packaging or anything makes any difference. [00:04:06] Speaker 02: And we know that because in column four, for example, the patent says that a web client makes a URL request. [00:04:15] Speaker 02: This URL request is examined by the web browser to determine [00:04:20] Speaker 02: the appropriate web server to route the request to. [00:04:22] Speaker 02: A little further down in column four it says basically the same thing. [00:04:25] Speaker 02: The web client issues a URL request that is processed to determine proper routing. [00:04:30] Speaker 02: Now what that means is that obviously the request exists independent of its routing. [00:04:35] Speaker 02: It also exists independent of its packaging. [00:04:38] Speaker 03: That's the point I'm trying to make is that sounds like a claim construction argument. [00:04:42] Speaker 03: You're looking at the specification. [00:04:45] Speaker 03: You're saying it should properly be interpreted so that this second [00:04:50] Speaker 03: effort by the computer doesn't count as a second request. [00:04:57] Speaker 03: But you really didn't make that argument before the board and it seems to me that under their claim construction it's reasonable to think that the computer's second request is a second request. [00:05:10] Speaker 02: No, I don't think so and we did argue before the board that the subsequent involvement of the client computer didn't make any difference and we did argue [00:05:19] Speaker 02: that the routing doesn't make any difference, the packaging doesn't make any difference. [00:05:23] Speaker 02: So certainly in that sense, we made the argument. [00:05:26] Speaker 02: And the point is that... Can I ask you this? [00:05:30] Speaker 02: Sure. [00:05:32] Speaker 01: If, as I understand your view of the request, the request is simply the substance of the message, the substance of contact, the semantic content of it. [00:05:46] Speaker 01: If I had a [00:05:48] Speaker 01: bank of a million computers. [00:05:51] Speaker 01: And I set them, each one, simultaneously to send to a web server, give me the stock price of Microsoft right now. [00:06:02] Speaker 01: Is that a million requests or one request? [00:06:04] Speaker 01: Because they all say exactly the same thing. [00:06:07] Speaker 02: I think if they are all going to the, and this raises another important point, and it's a point where the board went astray. [00:06:14] Speaker 02: If they're all going to the web server, I think they're separate requests. [00:06:18] Speaker 02: The point where the board got confused, I think, and this is, I think, appendix A. But why is that? [00:06:25] Speaker 01: They all say exactly the same thing. [00:06:27] Speaker 02: They do, but they're separate initiations. [00:06:29] Speaker 02: And they're going to the web server. [00:06:31] Speaker 02: And this is the point I was getting to. [00:06:34] Speaker 02: The way that the invention supposedly reduces website congestion. [00:06:39] Speaker 01: But now if you're distinguishing identical substantive content by the address C, [00:06:47] Speaker 01: Why is that not equally true of the rerouted S1 in SWEB? [00:06:56] Speaker 02: It's going different address C. Well, it's going to the page server. [00:06:59] Speaker 02: It's not going to the web server. [00:07:01] Speaker 02: And what you're trying to avoid is congestion at the web server. [00:07:04] Speaker 02: That's the whole point of this. [00:07:05] Speaker 02: And that was one of the reasons the board said, well, the redirected request has to be a new request, because it's creating the congestion that the patents were designed [00:07:14] Speaker 02: to avoid, but it's not. [00:07:15] Speaker 02: It's doing exactly the same thing as the patents. [00:07:18] Speaker 02: You have one request going to the web server, and then the web server is distributing that request to the appropriate page server. [00:07:25] Speaker 02: In the invention, in the patents, it does it through request forwarding. [00:07:29] Speaker 02: In SWEB, it does it through URL redirection. [00:07:32] Speaker 02: So it bounces it back off the client computer, but it never goes to that web server again. [00:07:37] Speaker 02: It's going to the appropriate page server. [00:07:39] Speaker 02: And that's a fundamental misunderstanding that the board had. [00:07:44] Speaker 02: What you're describing is more like the other place where they want to stray, which was thinking that hitting a refresh, refreshing a request is the same thing that SWEB is doing. [00:07:55] Speaker 02: But it's not. [00:07:56] Speaker 02: It's making a new request to a web server. [00:07:58] Speaker 02: And our expert explained that, but they just dismissed that distinction. [00:08:02] Speaker 02: But that distinction is at the heart of what the supposed innovation of these patents is. [00:08:08] Speaker 02: It's reducing congestion at the web server. [00:08:10] Speaker 01: Can I switch topics on? [00:08:13] Speaker 01: obviousness component of, and then I'm also interested in, let's call it the IBM argument, the Unix socket thing, but it had struck me when I was reading SWEB that SWEB does say something about a teensy-weensy little bit of excess overhead relative to about a thousandth of a, one or four milliseconds in a process that took four or five seconds. [00:08:40] Speaker 01: And therefore, [00:08:43] Speaker 01: And I guess my question is, except as to one or maybe a few of the dependent claims, I did not see your expert relying on that as a motivation to modify SWEB on the assumption that SWEB wasn't anticipatory. [00:09:04] Speaker 02: It was not that the calculation they go through that comes up with that millisecond. [00:09:09] Speaker 02: It's the earlier statement in SWEB where it talks about, [00:09:13] Speaker 02: URL redirection has certain disadvantages, the additional pass request cycle, and all of that. [00:09:18] Speaker 02: It's talking about the extra work, basically, that the client computer. [00:09:22] Speaker 01: But just putting aside the magnitude of that, I don't think your expert cited that in the main portion of his declaration, saying here's why it would be obvious to change. [00:09:35] Speaker 02: He didn't cite [00:09:38] Speaker 02: what you were referring to. [00:09:39] Speaker 02: But what you're referring to is different. [00:09:41] Speaker 02: The computation that they were doing in SWEB was not a comparison between URL direction and request forwarding. [00:09:48] Speaker 02: It was between their system and a system that doesn't use the distributed servers. [00:09:53] Speaker 02: So there are two different respects in which there's a disadvantage. [00:10:00] Speaker 02: And you're right. [00:10:02] Speaker 02: The processing difference that they calculate [00:10:05] Speaker 02: is minuscule there. [00:10:06] Speaker 02: But what they're talking about earlier on, which is what our expert was talking about, was the additional overhead of having to go back to the client computer and then back to the page server. [00:10:17] Speaker 03: I'm not sure that I understand this. [00:10:19] Speaker 03: As I understand what the board said on the obviousness issue, is that the board said that it wouldn't have been obvious to substitute request forwarding for URL [00:10:33] Speaker 03: Redirection because it hasn't shown that that would have been better. [00:10:38] Speaker 03: Is that a fair statement? [00:10:39] Speaker 03: I think that's what the board said right and is your position that there can be a motivation to Modify even if it isn't shown to be better Absolutely, and I think that's what KSR says these are they're known two different. [00:10:56] Speaker 02: They're more than two but [00:10:58] Speaker 02: In this case, two different alternatives for accomplishing the same thing, moving a request from one server to another. [00:11:04] Speaker 02: SWEB used URL redirection, but request forwarding, it's undisputed, was known in the art, was within the ability of one of ordinary skill, and it had certain advantages. [00:11:14] Speaker 02: And so we think that, I mean, the case. [00:11:17] Speaker 01: What were the advantages? [00:11:20] Speaker 02: It was more efficient, and when you do it. [00:11:23] Speaker 01: I guess let me ask more precisely. [00:11:25] Speaker 01: What did your expert identify as the advantages? [00:11:28] Speaker 01: Because I read the board to say, never mind whether it was better or not, you just haven't said why somebody would do it. [00:11:36] Speaker 01: Maybe it's an alternative, but why would somebody do it? [00:11:38] Speaker 02: Well, Sweb explained some of them, that you don't have the additional need. [00:11:44] Speaker 01: But your expert didn't rely on that excess overhead. [00:11:49] Speaker 02: I think he did, Your Honor. [00:11:50] Speaker 02: He pointed to that passage in Sweb. [00:11:52] Speaker 01: Where? [00:11:53] Speaker 02: I think it's in paragraph 214. [00:11:55] Speaker 02: of his declaration. [00:11:59] Speaker 02: I want to try to find that. [00:12:09] Speaker 01: 11449. [00:12:11] Speaker 00: That sounds familiar. [00:12:23] Speaker 03: He talks about how request forwarding was known, and he talks about advantages of request forwarding, right? [00:12:33] Speaker 02: Right. [00:12:33] Speaker 02: And then on 11.450, he talks about, and this is about two-thirds of the way down the page, a person of ordinary skill would have been motivated to employ such a technique in the scheme of SWEB, which is expressly concerned with efficient use. [00:12:45] Speaker 02: And then it quotes from SWEB about the resource constraints [00:12:50] Speaker 02: Network latency and that sort of thing and it goes on on to the next page So I think that's what he is talking about. [00:12:58] Speaker 03: But he's not saying it's better than the URL redirection, right? [00:13:03] Speaker 02: He's he is saying that You are that request forwarding is an alternative and it has certain advantages Over URL redirection, I believe. [00:13:14] Speaker 03: Well, that's what I'm not sure about. [00:13:16] Speaker 03: Where does he say it has advantages over the URL redirection? [00:13:20] Speaker 03: He certainly says it has advantages over the prior art, I guess, or whatever. [00:13:28] Speaker 02: Right, right. [00:13:31] Speaker 02: Well, I think what he is saying, by referring to SWEB and the resource constraints that SWEB is talking about, I think that he's saying that request forwarding is potentially a better way of dealing with those resource constraints. [00:13:46] Speaker 02: But entirely apart from that, even if it's not, even if the board's right [00:13:50] Speaker 02: about that, I think under KSR, it's basically a simple substitution of one known method of doing something for another known method of doing it. [00:13:59] Speaker 03: It doesn't have to be shown to be better. [00:14:01] Speaker 02: Clearly, it doesn't have to be shown to be better. [00:14:03] Speaker 02: Exactly. [00:14:04] Speaker 02: I see my time's running out. [00:14:07] Speaker 02: You mentioned the UNIX sockets argument, Your Honor, in the IBM brief. [00:14:12] Speaker 02: Did you have a question about that? [00:14:14] Speaker 02: I maybe will save my question for the other side. [00:14:17] Speaker 02: OK, well, and I would just on that, [00:14:20] Speaker 02: on that subject just very quickly. [00:14:23] Speaker 02: That's clearly disclosed in SWEB as another possible way of moving requests from one server to another. [00:14:29] Speaker 03: They seem to admit that now. [00:14:30] Speaker 03: It seems as though it boils down to enablement. [00:14:34] Speaker 02: Right. [00:14:34] Speaker 02: And on enablement, well, first of all, the board didn't address it at all. [00:14:39] Speaker 02: Enablement obviously is a legal question, requires factual findings. [00:14:42] Speaker 02: The board didn't address it. [00:14:43] Speaker 02: So I think just by raising enablement, I think that shows that it needs to go back so the board can look at that. [00:14:49] Speaker 02: And they're clearly, what their experts said, they cite their expert. [00:14:53] Speaker 02: Their expert only said, Sweb doesn't explain how to do it. [00:14:56] Speaker 02: He doesn't even suggest that it was beyond the ability of one of ordinary skill would have required undue experimentation or that sort of thing. [00:15:03] Speaker 02: So I will reserve. [00:15:05] Speaker 03: We will give you two minutes for the final. [00:15:07] Speaker 02: Thank you, Your Honor. [00:15:08] Speaker 03: Mr. Bovenkamp? [00:15:19] Speaker 04: The police court, counsel. [00:15:22] Speaker 04: I think I'll start where Mr. Trellis started with regards to the claim construction issue on request. [00:15:28] Speaker 04: And I think it's very clear when you look at what the board did is that he applied the agreed construction of the parties. [00:15:35] Speaker 04: He took into consideration both Microsoft's arguments and our arguments. [00:15:40] Speaker 01: By he, you mean the three-member board? [00:15:42] Speaker 04: The panel, yes. [00:15:43] Speaker 04: Yes, your honor. [00:15:45] Speaker 04: And came to the conclusion that based upon the [00:15:49] Speaker 04: client computer having to perform another action that was exactly the same as what started the entire process, there was a second request. [00:15:59] Speaker 04: And I think that the key piece of evidence that he cited to and that he considered was the admission of Microsoft's expert. [00:16:05] Speaker 01: I'm sorry, do you mind talking about the panel? [00:16:07] Speaker 01: I get extremely confused. [00:16:09] Speaker 04: I apologize. [00:16:09] Speaker 04: Yes, Your Honor. [00:16:10] Speaker 04: The panel, the evidence that the panel considered [00:16:16] Speaker 04: What Anne pointed to that was most important, I think, was the admission of Microsoft's expert, Mr. Mitzenmacher, who at his deposition testified that there was two distinct initiation actions in SWEB 95 that took place necessarily. [00:16:35] Speaker 04: And based upon that finding, that fact, coupled with the panel's analysis of the rest of the prior art, [00:16:46] Speaker 04: They concluded that the second request that is generated took it outside of the scope of the 335 and 554 patent claims. [00:17:02] Speaker 04: Now, there's arguments that were made by Microsoft regarding these additions that the panel added, allegedly. [00:17:10] Speaker 01: Can I just ask, just as a matter of describing the process, [00:17:17] Speaker 01: Was you generally familiar with O2 micro? [00:17:22] Speaker 04: Yes. [00:17:22] Speaker 01: OK. [00:17:23] Speaker 01: So in district court world, sometimes what happens is as the proceeding goes along in your past claim construction, it turns out that the parties have a dispute. [00:17:33] Speaker 01: Let's call it the scope of the claim. [00:17:36] Speaker 01: And there is some law growing out of O2 micro that says sometimes when a party says, [00:17:45] Speaker 01: Judge, we need a new claim construction. [00:17:48] Speaker 01: There's clearly a dispute about this, and sometimes the judge is required to do that. [00:17:54] Speaker 01: Did anything like that happen? [00:17:56] Speaker 01: Could it have happened in the oral hearing before the board? [00:18:02] Speaker 01: Because part of your dispute is, did the board really do a claim construction? [00:18:07] Speaker 01: And in district court land, sometimes we resolve that by looking at the opportunity to say, [00:18:13] Speaker 01: do this as a claim construction rather than as an application? [00:18:17] Speaker 04: Yes, Your Honor, and I think the board certainly had an opportunity and did do a claim construction. [00:18:23] Speaker 04: The way the case was postured was that when Microsoft filed its... Claim construction that resolved this issue? [00:18:29] Speaker 03: I don't see that. [00:18:30] Speaker 03: I don't recall, and correct me if I'm wrong, I don't recall that the parties really [00:18:37] Speaker 03: had a dispute about what a request was or that anybody asked for a claim construction about that. [00:18:47] Speaker 03: It seemed to be there was an agreed claim construction. [00:18:50] Speaker 03: Am I mistaken about that? [00:18:52] Speaker 04: There was an agreed claim construction in the district court proceedings between the parties. [00:18:57] Speaker 04: Microsoft's petition did not request, as it could have, a construction of requests. [00:19:03] Speaker 04: It did request construction of other terms. [00:19:08] Speaker 04: When the patent owner filed its responsive brief after institution, we requested that the board construe request as agreed by the parties. [00:19:18] Speaker 03: So there was no dispute, really, about it? [00:19:20] Speaker 04: Microsoft then, in its reply, did not propose formally any response. [00:19:26] Speaker 04: And so I don't think there is a dispute, Your Honor, as far as what the construction of request was. [00:19:31] Speaker 00: So you're saying the parties effectively agreed to the construction that had been adopted in the district court proceedings? [00:19:37] Speaker 00: Yes, Your Honor. [00:19:39] Speaker 01: Can I ask you to turn, if it's OK with my colleagues, to the Misenmacher Declaration 11449 of the appendix? [00:19:54] Speaker 01: Why is it not right to read that paragraph, which I guess a two-page paragraph, as saying not just [00:20:05] Speaker 01: that there are advantages to splitting up into multiple servers, the service of tasks, but that there are reasons to do so by forwarding as opposed to sending it back to the client and getting the client to do another thing. [00:20:26] Speaker 04: And I think to answer your question, if I understand what your honor is asking, [00:20:31] Speaker 04: As I read paragraph 214, which is on appendix 11449 and crossing all the way to appendix 11451, what I read Mr. Mitzermacher saying there is there is a generic benefit known in the art to request forwarding. [00:20:50] Speaker 01: What do you understand or what do you think he meant by request forwarding? [00:20:56] Speaker 01: I think what he meant by request for me this as well as this or just this I think all he meant was that something comes to a computer and it gets sent on to another computer but that's all I think that without regard to whether that sending on is direct or back through the client that's how I initially read this but I think the argument is [00:21:25] Speaker 01: That is, and that's one of the reasons maybe that the SWEB overhead material is not cited here. [00:21:33] Speaker 01: And the freeing up of CPU cycles and memory resources is independent of how it gets to the second server. [00:21:42] Speaker 01: I sort of read this in a way that this was not really addressing the dispute between the [00:21:52] Speaker 01: you know, back up to the apex of the triangle or directly to the other vertex. [00:21:59] Speaker 04: If by back up to the apex of the triangle, you mean the URL re-erection, Your Honor? [00:22:03] Speaker 01: Yes. [00:22:04] Speaker 04: So I think he was addressing that here. [00:22:08] Speaker 04: Because I think that if you look at the beginning of paragraph 214, he's talking about the alternative argument that if patent owner makes that if routing is not disclosed [00:22:22] Speaker 01: Okay, so if he's talking about that, why is that not enough of either to come within KSR, which may not quite require a motivation to choose among certain kinds of known substitutes, or in any event enough of a motivation to meet, to be the standard? [00:22:47] Speaker 01: And the board simply said he hasn't identified a motivation. [00:22:50] Speaker 04: Right, and I think the reason why it's not enough as to what's said in this paragraph 214 from his declaration is that he doesn't engage as KSR instructed on why a person of skill in the art being put in the position that he or she would be here. [00:23:07] Speaker 04: Why is a change going to be made? [00:23:09] Speaker 03: Microsoft... But in other words, I mean, what he's doing, would you agree that what he's doing is he's saying that request forwarding has advantages, right? [00:23:17] Speaker 04: I agree. [00:23:18] Speaker 03: Okay. [00:23:18] Speaker 03: And what you want him to say [00:23:20] Speaker 03: apparently is it's better than URL redirection. [00:23:25] Speaker 04: Either better or there is some other advantage that's given to the system by taking URL redirection away and putting request forwarding in. [00:23:35] Speaker 04: I wouldn't go so far as to say it's absolutely mandatory that it be strictly better than URL redirection, but there's got to be some reason why a person, and it may be because it's better, [00:23:47] Speaker 04: But there may be some other reason a person's skill in the art looking at this problem, looking at this particular reference, would have said, you know what? [00:23:53] Speaker 04: I would rather do this, or this is something that we should try to do, rather than URL redirection. [00:24:00] Speaker 04: And Mr. Mitzmacher didn't do that in a declaration. [00:24:02] Speaker 03: So do you agree that we don't really have any cases which address that question? [00:24:11] Speaker 04: I think there's lots of cases in which there's instruction that you have to [00:24:17] Speaker 04: provide, you have to find a reason for whether or not the person of skill in the art is going to make the modification or make the change to the prior art reference. [00:24:26] Speaker 03: Are there any cases that say the motivation has to be that it would be better, right? [00:24:32] Speaker 04: I think if you read the cases that were cited here, I think that those words may not exactly be in the cases, so I'll agree with your honor in that respect, but if you look at the [00:24:45] Speaker 04: the train of thought and what KSR taught us. [00:24:48] Speaker 04: I think KSR taught us that there has to be this common sense that's looked at to see you don't just do it to do it. [00:24:57] Speaker 04: That's where hindsight's going to come in. [00:24:58] Speaker 04: You don't just make the change because, well, it's out there. [00:25:02] Speaker 03: It seems to me kind of odd in a way that you're saying that he has to show that [00:25:15] Speaker 03: request forwarding is better than URL redirection, whereas the theory of the patent is that it's inherently better, right? [00:25:25] Speaker 04: I don't think the patent makes a claim that it's inherently better. [00:25:29] Speaker 04: I think part of the invention, part of the novelty of the claims... It's just that it's different, it's not better? [00:25:37] Speaker 04: I think in the architecture it's better. [00:25:41] Speaker 04: I mean, I think that that was proven by history and that URL redirection isn't used, whereas this request forwarding system was. [00:25:48] Speaker 04: But I think at the time, I don't think that was something that a person of skill in the art would have known or accepted or believed. [00:25:57] Speaker 04: I think that still had to be played out in the art. [00:26:00] Speaker 04: And I know it was a long time ago, so it's hard to put ourselves in the place of a person of skill in the art back in that point in time. [00:26:07] Speaker 04: But I don't think it was just accepted that in that particular architecture, one would be better than the other. [00:26:15] Speaker 03: Could we talk for a minute about the Unix thing? [00:26:17] Speaker 03: Do you agree that the only issue here is enablement? [00:26:23] Speaker 04: I don't agree with that, Your Honor. [00:26:24] Speaker 04: I mean, I think that is an issue. [00:26:26] Speaker 04: But I think that the primary issue is that Microsoft and IBM didn't raise this. [00:26:32] Speaker 03: OK, suppose we reject that. [00:26:33] Speaker 03: Yes, Your Honor. [00:26:34] Speaker 03: The only issue then is enablement. [00:26:36] Speaker 04: I think that's fair, yes. [00:26:38] Speaker 03: So, but as I read the experts here, neither one of them really addressed enablement. [00:26:44] Speaker 03: Is that fair? [00:26:46] Speaker 04: I don't think that's fair. [00:26:48] Speaker 04: I think that what Dr. Jones, parallel networks expert said, and what SWEB itself says, is that it would be difficult for a person of skill in the art to change the UNIX kernel, which according to the authors of SWEB, [00:27:05] Speaker 03: But something can be enabled and to be difficult at the same time, can it? [00:27:10] Speaker 04: I think the way that it's phrased, the way it's referred to, is that they're basically saying, look, this is something that a person of skill in the art may know how to do, but we don't know. [00:27:21] Speaker 04: And they certainly, in the reference, did not describe anything about it beyond just saying it would be difficult, you have to change the kernel. [00:27:31] Speaker 03: So the board didn't address this enablement question, right? [00:27:34] Speaker 04: I think they did not address it in the anticipation section of the brief. [00:27:39] Speaker 04: I agree with that. [00:27:40] Speaker 04: In the obviousness section, I apologize. [00:27:44] Speaker 04: The panel did not address it in the anticipation section of the final written decision. [00:27:49] Speaker 04: However, in the obviousness section of the final written decision, they listed our argument. [00:27:55] Speaker 03: They didn't address it there as an enablement question either, right? [00:27:58] Speaker 03: Because it wouldn't be an enablement question. [00:28:00] Speaker 04: Well, and what they referred to was the merit that there was this difficult issue of the colonel, UNIX colonel, and acknowledged that that argument had merit. [00:28:12] Speaker 04: Now, did they refer to enablement specifically? [00:28:14] Speaker 04: No, Your Honor. [00:28:16] Speaker 03: Assuming that we conclude that it was properly raised, don't we have to send it back for them to address this question? [00:28:24] Speaker 04: I don't think it needs to be sent back to address this question, because I think that [00:28:32] Speaker 04: The question assumes that it was raised. [00:28:38] Speaker 04: Is that what, Your Honor? [00:28:39] Speaker 04: Yes. [00:28:40] Speaker 04: In that case, I think the statement by the board that the difficulty. [00:28:45] Speaker 01: I'm sorry. [00:28:46] Speaker 01: That's at page 22. [00:28:47] Speaker 01: And all that is is a description of your contention. [00:28:51] Speaker 01: It's not a finding, but. [00:28:53] Speaker 04: We'll make sure we're on the same page, Your Honor. [00:28:57] Speaker 01: Page 22, appendix 22. [00:28:59] Speaker 02: Yes, appendix 22. [00:29:00] Speaker 02: Happily. [00:29:00] Speaker 02: That's your honor. [00:29:04] Speaker 01: While Parallel admits that SWEB discusses the possibility of a UNIX socket package, it notes that this alternative was dismissed as difficult. [00:29:13] Speaker 01: According to Parallel, this signifies that the modification was non-trivial and beyond ordinary skilled artisan. [00:29:20] Speaker 01: But that's, as I take it, just a description of your argument. [00:29:24] Speaker 04: That's correct. [00:29:25] Speaker 04: But if you look at the next sentence, [00:29:29] Speaker 04: Panel states that although we believe parallel arguments have merit, referring to the listing of what those arguments were preceding. [00:29:36] Speaker 04: It's a bit different than saying it's correct, right? [00:29:40] Speaker 01: Well, I think that the- And then it goes on to say it's relying not on that, but on the motivation. [00:29:46] Speaker 04: It rests primarily on the fact that it then discusses, Your Honor. [00:29:50] Speaker 03: So why don't we have to send it back? [00:29:52] Speaker 03: Assume it's properly raised. [00:29:55] Speaker 04: Because I believe that that [00:29:57] Speaker 04: that section that we've just read in court provides sufficient basis to conclude that to want a skill in the yard, it wouldn't have been enabled and was beyond a person of skill in the yard. [00:30:12] Speaker 03: Anything else? [00:30:14] Speaker 03: No. [00:30:14] Speaker 03: Thank you, Your Honor. [00:30:15] Speaker 03: OK. [00:30:15] Speaker 03: Thank you. [00:30:19] Speaker 03: Mr. Crowley, you have two minutes. [00:30:26] Speaker 02: Thank you, Your Honor. [00:30:27] Speaker 02: To go back to the paragraph 214 of the Experts Declaration and all that, and Judge Toronto, I apologize. [00:30:34] Speaker 02: I didn't fully understand the question you were asking. [00:30:39] Speaker 02: I think it is particularly right in context. [00:30:41] Speaker 02: I think it's clear that he's not talking about request forwarding in the URL redirection sense. [00:30:47] Speaker 02: I think he's talking about put URL redirection to one side. [00:30:51] Speaker 02: Request forwarding is another way that has advantages of doing this. [00:30:55] Speaker 02: I think it's clear from the context, because the paragraph before that, he's talking about URL redirection. [00:31:00] Speaker 02: Then also paragraph 42 of his reply declaration, which is at appendix 15946, he makes it very explicit that what he was talking about in 214 and what he's talking about in his reply is request forwarding as separate and distinct from URL redirection. [00:31:16] Speaker 01: And just as it happens, I mean, I just haven't looked at this yet, but after those [00:31:22] Speaker 01: sentences about request forwarding. [00:31:24] Speaker 01: He cites Burson, which is exhibit 1036, which we have, I guess, a piece of. [00:31:30] Speaker 01: Yes. [00:31:31] Speaker 01: Do the things that he's, and Pfister. [00:31:33] Speaker 02: And those are traditional request forwarding, not URL redirection. [00:31:38] Speaker 02: So I think the context makes it clear. [00:31:40] Speaker 02: And I think it's very clear under KSRA, it does not have to be better. [00:31:44] Speaker 02: It's a known technique for doing the same thing. [00:31:46] Speaker 02: It was within this level of skill of ordinary skill in the art. [00:31:50] Speaker 02: And the last point I want to make is Mr. Bovenkamp started with a reference to our experts talking about distinct initiation actions. [00:32:02] Speaker 02: What our expert was talking about, and his testimony is at appendix 20801 and 02, was a refreshed request, which is a new action by a user, sends a new request to the web server that then has to go through the whole process again of having [00:32:19] Speaker 02: dispatcher decide which page server is best to handle it and all of that. [00:32:23] Speaker 02: So it's a completely different situation than URL redirection. [00:32:26] Speaker 03: Could I ask a question? [00:32:27] Speaker 03: Does the specification of the patent here or of the patents here talk about a comparison between URL redirection and request forwarding? [00:32:38] Speaker 02: No. [00:32:39] Speaker 02: It doesn't mention URL redirection. [00:32:42] Speaker 02: And it doesn't use the term request forwarding. [00:32:44] Speaker 02: It just says dispatch from the web server [00:32:47] Speaker 02: to a page server doesn't talk about how. [00:32:50] Speaker 02: And so we say it doesn't exclude URL redirection. [00:32:53] Speaker 02: It just says, get it from one to the other somehow. [00:32:57] Speaker 01: One other question. [00:32:58] Speaker 01: I don't think you made this argument. [00:33:00] Speaker 01: Maybe you can just clarify. [00:33:02] Speaker 01: Sometimes in this web system, the recipient, the initial web server, will say, I've got lots of free time. [00:33:12] Speaker 01: I'll just keep it. [00:33:13] Speaker 01: Why would that not come within the claims? [00:33:15] Speaker 01: Why would that not come within the claims? [00:33:17] Speaker 01: Yeah, do the claims actually require sending it to a different place? [00:33:21] Speaker 02: Well, actually, they don't require sending it to a different machine because the constructions of web server and page server both refer to software. [00:33:30] Speaker 02: So I think it actually could be two units of software on the same machine. [00:33:35] Speaker 02: And the receiving piece of software says, OK, this machine can handle it and hands it off to the [00:33:42] Speaker 02: Processing, you know the page server software. [00:33:44] Speaker 02: So in theory it could all be on the same machine We've been talking about it as different machines, but but it could all be on the same machine Thank you. [00:33:52] Speaker 03: Okay. [00:33:52] Speaker 03: Thank you. [00:33:53] Speaker 03: Thank both counsel the case is submitted