Oral argument — REALTIME DATA, LLC v. MORGAN STANLEY

You probably have a significant portion of the gross national product of the United States represented here this morning. As everyone knows, we have nine cases, and we have, in Mr. Thomas will be utilizing 30 minutes, and he wants to break it up into 15 and 15, representing real-time. And then the first group of appellees, I think referred to as exchanges, represented by CME, will be appellees, and that group of cases is 2013, 1093, 1097, and 1100. The second group, and that will be represented by Mr. Hawes, Mr. Lee, representing the banks, led by Morgan Stanley, that's 1092, 1099, and 1103. This is, of course, all for the record. And the third group representing Mr. Schellack, I think the designation that's been used is 1098, and 1101. So, if we can begin with Mr. Thomas. Excuse me, Your Honor. Actually, we represent the exchanges to grow the argument. You're Mr. Schellack? Yes, I am. All right. Well, we will hear your arguments and know who you are, and perhaps the designation was not clear and that's not controllable. Please proceed, Mr. Thomas. Good morning, Your Honors. Dirk Thomas on behalf of Real-Time Data and the inventors of the patents in suit in this case, and may it please the Court. We have, to start out, Your Honors, we have a copy of Claim 22 of the 651 patent that I've handed out to defendants, and I've also given Exemplar 1 of the claims that are asserted in this case, and I've highlighted the three claim terms here for which we dispute the construction. So, with Your Honors' permission, if the Courtroom Deputy could hand up, I think it would help in following my argument if we had this claim. And to be clear, this claim is not asserted against all of the defendants, but it does include each of the terms that we're challenging. We have them here. Is there any objection from colleagues? No objection. All right. Then please hand it up to the Deputy. I see more than three copies. Are they more than one? No, it's the same case. Multiple copies of the same thing, Your Honor. Please proceed. Real-time challenges the construction of three claim terms in this case, Your Honor. They're highlighted in Claim 22 here. But in addition to just challenging the construction of those claim terms as the Court found them in its Markman order… Mr. Thomas, let me ask you a preliminary question. I'm looking at your summary chart on page 63, Yes, Your Honor. and I see that the descriptor indicates limitation is never the sole basis for summary judgment identified in the chart. There's always something else. If the Court affirmed the summary judgment of the non-defendant based on the data field slash block types limitation, where would that leave the descriptor indicates term? The data block, data field claim term, Your Honor, applies to all the defendants in this case, as does the descriptor claim term. So they're independent bases for summary judgment. So if you were to affirm summary judgment on either one of those claim terms, you needn't reach the other. Thank you. I sort of thought that, but… I understand, Your Honor. Where I was going, Your Honor, with this is we have challenged the Court's claim construction as Judge Forrest reached in her Markman order. But we're also challenging the additional claim construction that Judge Forrest applied in reaching her summary judgment determinations, because there is an additional limitation on each of those claim terms, and I will go through and explain exactly where, in reaching her summary judgment conclusions, she read in this additional claim limitation in order to avoid what we believe were material disputed facts, as presented by our expert and by additional evidence in the record, which we could have gotten to trial on with the claim constructions as presented in the Markman order. So to start with, in looking at Claim 22, the first claim term is data stream. Now, in her Markman order, the Court construed data stream to be a sequence of blocks coming from an external source whose characteristics are not controlled by the encoder or decoder. Well, you don't see those words anywhere in Claim 22 or any of the other asserted claims. As a matter of fact, taking Claim 22 by way of example, it's an encoding system. And the data stream is made up of encoded data packets. So the data stream in Claim 22 is a compressed data stream going out from the encoder. So to construe data stream there as if it had to have a metro PCS litigation. The metro PCS litigation, Your Honor, we proposed the exact same construction that we proposed here, and that is one or more data blocks transmitted in sequence. The Court asked whether or not does that data stream have to come from an external source, and in the metro PCS litigation we said, indeed. When you're looking at the logical entity that is the encoder, the compression algorithm, the compression algorithm does not make up its own data. The compression algorithm compresses data created elsewhere. So when the Court asked us in the metro PCS, does it matter if the data stream is construed to have arisen or be coming from an external source, we said that's implied in any data stream that's arriving at an encoding algorithm or a decoding algorithm. So we accepted that, but we never urged anywhere that the term data stream standing alone required this external characteristics not controlled by the encoder or decoder. And we only accepted the external source limitation in the metro PCS litigation because it's impliedly there anyway. In other words, Your Honor, if you've got just the logical entity that's doing the encoding, it's not creating its own data stream. It's compressing a data stream that's been created somewhere else because it's a module. It can come off. You don't have to compress a data stream in order to transmit it. If you choose to compress the data stream, you plug it in, you compress it, and then you send it out. But that data stream coming in is coming from somewhere other than the logical entity that is the encoder. Now, here what the court did in arriving at her summary judgment ruling was to require that the data stream, and I'm reading as JA 190 to 191, the court's summary judgment opinion, where she said, and I quote, since the data feeds are not external, they fail to meet one of the construed requirements for a data stream. Then she went on to say that the ISE feeds, certain ISE, one of the defendants, are quote internal and therefore not external to ISE. So while the construction at the markman stage didn't require this external source be a third party, a different entity than the entity that's doing the compressing, at the summary judgment stage, that's exactly how the court applied the claim. Tell us why the district court was in error with respect to the 112 issues. 112 issues, Your Honor, the district court... She said that some of the language was insolubly, insolubly ambiguous. On its face, that's just not true, Your Honor, and here's why. The claim terms at issue are content-dependent data decompression and content-independent data decompression. Now those are the inverses of content-dependent compression and content-independent compression. These are coin terms. All they refer to is applying the inverse of whatever the compression algorithm was, be it content-dependent or content-independent. It's the inverse of that particular compression algorithm, and we believe, Your Honor, that that's a very easily understood meaning for the terms content-dependent data decompression or content-independent data decompression, and it's established by this. During the re-exams of these same patents, when the defendants went to read those claim terms on the prior art, they had no problem whatsoever identifying exactly where they thought they found a content-dependent data decompression and a content-independent data decompression. They never said to the examiner at the patent office during these re-exams, we can't tell what those claim terms mean. They made a straightforward reading on specific pieces of prior art, and they did that before any of the contentions were leveled in the litigation. So they were using their own constructions of the claims. So we think, Your Honor, that this 112 first paragraph and second paragraph issue is really a red herring. A very straightforward reading of those terms is a simple reading of those terms. What about the written description? The written description, Your Honor, is, in fact, I can point you to exactly where the written description exists, Your Honor, for content-independent and content-dependent. Are you talking about the 747 patent? The 747 patent is at Joint Appendix page 479. Is that column 15? Part of it is at column 1, lines 19 to 22, and again at column 5, lines 45 to 47. At column 1, 19 to 22, it says, the present invention relates generally to a data compression and decompression and more particularly to systems and methods for data compression using content-independent and content-dependent data compression and decompression. That is that, along with the discussion on JA481, column 5, lines 45 to 47, content-independent data decompression system, according to one embodiment of the invention as shown in figure 11. Again, in the 651, figure 6 shows a content-independent data decompression system, and that is a description of figure 6 appearing in column 5, lines 66 to 67. But moving back to the same terms, Your Honor, as I mentioned, what the court did in arriving at the summary judgment ruling was layered on an additional limitation to this data stream. We don't believe the data stream has any of these requirements for absence of control or arriving from an external source. While external source may be implied because the compression algorithm doesn't generate its own data, there's certainly no requirement that the external source does or does not exercise any control. And all of the claims ensued in this case merely use the term data stream. In any of these, there's no qualification on that term data stream except in some of the other decompression claims, which I'll get to in a minute. Because when we wanted to qualify that data stream, we knew how to do it. And we didn't qualify it in any of these asserted claims. Now, moving on then, the data stream, and I'm going to jump to that last claim term, which is descriptive, because the data stream must have a descriptor appended to it or attached to it. And it's a descriptor that, as the claim says, indicates the one or more lossless encoders that were selected. Now, what the court did here at the markman stage that was erroneous is she failed to apply an express definition of descriptor that the inventors included in the patent specification in each one of the asserted patents. And specifically, for example, in the 651 patent at JA 515, column 16, line 23 to 26, the inventors said, I quote, a data compression type descriptor is defined as any recognizable data token or descriptor that indicates which data encoding technique has been applied to the data. The court did not apply that express definition. We believe that was error. But then moving from there, at the summary judgment stage, what the court did was she read an additional limitation even into that definition of descriptor that she did apply, one that says it has to be appended to for specifying. Those are the extra words she added. But then she went further because, for example, at the summary judgment opinion appearing at joint appendix page 184, the court wrote in applying the descriptor term, the PMAP, that's the PMAP and the template ID, which are the pieces that Dr. Seamus identified as constituting the descriptor, which nobody contests is appended to and transmitted with each data packet. The PMAP and the template ID. She said, the judge said, do not themselves identify the selected encoder. Rather, they point to a fixed template, which contains various encoder types. In other words, what the court did in applying that claim term at the summary judgment stage was read into that claim term the requirement that the descriptor by itself has to be available and have everything that's necessary to decompress the data stream. But her claims instruction at the markman stage merely says that the descriptor has to be appended to the data and it has to specify what the selected lossless encoder was. It's for specifying. And as Dr. Seamus explained in his summary judgment declaration occurring at joint appendix page 1756 in paragraph 28, he said, and I quote, each message contains a mandatory presence map and a template identifier. The combination acts as a descriptor because the presence of a field indicated by the presence map and the template identified by the template identifier indicate how the field is encoded. Thus, the descriptor included in the message is included in the message and is available for use by the decompressing algorithm to undo whatever the compression algorithm is. Dr. Seamus, let's just touch on doctrine of equivalent. Yes, Your Honor. The district court felt that since a limitation by limitation analysis wasn't provided as required by the local patent laws, that it was proper to exclude the testimony relating to that. And this is the point we'd like to make on that, Your Honor, is that we're not urging and never tried to urge a doctrine of equivalence argument under the claim constructions that Dr. Seamus in real time proposed initially. It was only after Dr. Seamus learned of the claim constructions that were being proposed by the defendants and at the time that his expert report was due that he then proposed that if those claim constructions were adopted, as they ended up being adopted by the district court, because the district court adopted wholesale every one of the proposed claim constructions that the defendants provided and rejected every one that we provided. But what Dr. Seamus did is simply said, now that I've seen what those claim constructions are, if the district court adopts them, then there are, I believe, three that he said he believes would still be met, if not literally, then under the doctrine of equivalence. So from a timing standpoint, Your Honor, we believe it was an abuse of discretion to require that Dr. Seamus guess what those claim constructions were and we were waiting and hoping that the Markman ruling were to come down before his expert report was due, but it ended up coming down about a week later. So at the time he submitted his expert report, he identified what he thought were the appropriate DOE arguments if the defendants' constructions were adopted. And the district court said that was too little, too late. We believe that was an abuse of discretion. Now, so anyway, with the descriptor, Your Honor, we believe it was improper, first, to ignore the express definition in the patent, and second, to then layer on a further definition saying that the descriptor has to have everything that's necessary to do the decompression, where her claim construction merely said it only needs to have enough for specifying, Because at the decompression end, there is a template, what we call a state machine, that is referred to by the template ID that's transmitted. In other words, you don't send the same template with every compressed data packet. It's a compression algorithm. You don't send something that you don't need to send, it's not changing, that you can use when the data arrives at the receiving end, and then it's accessed for purposes of doing the decompression. I mean, that's what a compression algorithm would necessarily do. It wouldn't send things multiple times that don't change. It sends it once, and then it sends a pointer, a template identifier that says, go use that template when you're decoding this particular packet. And it's that template that identifies what particular lossless encoder was applied for that particular message type. Finally, Your Honor, moving on to the last of the three claim terms that we dispute, that is the data block type. What we believe the court did here is, again, did not give the full scope to that claim term that the patent specifications identify. For example, Your Honor, taking a look at Joint Appendix page 489 to 90, it's the 747 patent at column 22, line 63 to column 23, line 2. The inventor said that a content-dependent data recognition module 1700 is utilized to analyze the incoming data stream for recognition of data types, data structures, data block formats, file substructures, file types, or any other parameters that may be indicative of the appropriate data compression algorithm. Again, in the 747 patent, which is incorporated by reference wholly, and both of the other two patents ensued, the inventor said that the step of performing, and this is at column 4, line 28 to 32, the step of performing content-dependent data compression on a data block comprises the steps of using one or more encoder types based on characteristics of the data block. Now, what the court did at a remarkable ruling was say, no, that means that you've gotten to a category, and that category has to be of a certain data type. It can be any data type. There's got to be some data type. Well, when she went to apply that construction in the summary judgment stage, what she ended up doing was layering still another limitation onto that construction, because Dr. Seamus had identified exactly what data types, logical data types, that the accused instrumentality used to determine what the selected lossless encoding algorithm had been that was applied. Let me say that again. In other words, Dr. Seamus said, and it's in his declaration at JA 1752, paragraph 17, that he says, a data type is a characteristic of data that enables it to be distinguished from other data. For example, the data is redundant, or sequentially different, or most common value. And those were the kinds of data compression algorithms that he identified in every one of the accused instrumentalities. And he said, the characteristic that was sought was the relationship between the value in the data block and some other value to see if it met one of those three logical data types. But the court, when she was addressing this testimony from Dr. Seamus in the summary judgment context, said that no, all the accused products are doing is checking the content, or checking a value. So what she's done is she's, in a sense, excluded from the interpretation that she gave at the Markman stage for data block, so as to exclude anything that checks a value of the data in the data block. Well, we propose, Your Honor, that in order to do any analysis of data in a data block, one has to check what the value of that is, particularly if it's a numerical number. In other words, a data type can be an integer. It can be an unsigned integer, a signed integer. It can be a number. You've got to check that value before you can do any analysis to then, as the claim requires, after they analyze the content of the data block, all that analysis does is is then use so that the next step, selecting one or more lossless encoders, can be performed. And that's all that's necessary. And Dr. Seamus explained how a logical data type, the logical relationship, doesn't meet a true-false test. Is the data in the data block of a characteristic or type such that it fits this relationship to some other piece of data? If yes, do something. If no, do something else. Mr. Thomas, you wanted to say 15 minutes is down to 10. You can use it. Your Honor, just briefly, I'll address the data decompression claims. There, what the court did is read an encoding step into every decoding data claim. It said that the same entity that has to do the encoding must do the decoding. We would direct Your Honor's attention to Figure 1 of the 568 patent and Figure 1, if they're the same, of the 651 patent, which shows the entity that's generating the content is doing the compressing and then transmitting it to its subscribers. In fact, it's creating a ticker plan, as Figure 1 describes. So it's got a content creation module, 11, within System 10, and then a data compression server, 12. But they're being operated, as it says in Column 8, with a description of that patent by the same entity. So we suggest, Your Honor, that applying those decompression claims to require that the same entity that does the encoding does the decoding is inconsistent with the preferred environment. So with that, Your Honor, I'll reserve the remainder of my time. That would be fine. Just as we've compressed nine arguments into one propellant, we will now decompress and have three from Kelly. And first, we'll hear from Mr. Hawes. Thank you, Your Honor. May it please the Court, my name is Michael Hawes, and I represent CME Group, the New York Mercantile Exchange, and the Chicago Board of Trade. I'll be addressing the issues in the brief filed by those parties. Those issues were the summary judgment by Judge Forrest that none of the products accused infringe, because none of the products analyzed the data incoming to be compressed to determine a data type of that data. I'll also address the doctrine of equivalence ruling by Judge Forrest. And actually, I'd like to start with that, since that was a nice, clean little piece that was discussed earlier. I'd like to respond to what Mr. Thomas said with regard to the timing. And I would point the Court to, there's a great timeline of those events that's in the record at page 6776. That timeline shows that the plaintiffs received the defendant's claim constructions over three months before the end of fact discovery. What happened was they received those claim constructions, they waited until fact discovery closed, and then they told us, based on our claim constructions, what they felt were the doctrine of equivalence arguments. By failing to give the defendants any chance to take fact discovery concerning those equivalence arguments, they prejudiced the defendants, as Judge Forrest found. And of course, this Court has a very high standard of review for a decision like this. It's only for an abuse of discretion. And based on the timing, I think that there was clearly discretion and an appropriate decision made by Judge Forrest. Now, with respect to the summary judgments of non-infringement on the data type terms, the key issue for the Court to understand is why the defendant's accused systems don't need to determine the data type. They don't need to, because the defendant's accused systems do not make that decision on the fly. Instead, those systems use what's called a template. And that is sent long before any data that's going to be compressed. And essentially, that template says, here's the data you're going to receive, here are the types of that data, and here are the encoding techniques you're to use. So when the defendant's systems receive data, they have no need to determine its type. They've been told what that type is. And they take the encoding technique that they've been told to apply, and they look to see, is this value the single value I care about? And if so, I encode it appropriately. But there's no need to look for a type, because that type has already been determined and was determined long before any data was received. In looking specifically at some of the arguments that Mr. Thomas raised, I would first want to point out to the Court that it's important to note, despite the illustration of the claim language here, I would point the Court to page 1404 of the record, because the parties have an agreed construction that informs this language. And on that page, you'll see that the parties agreed that the data type terms were of a type of the data. Now, Mr. Thomas talks about how, well, there's parameters, there are attributes. But what's important is that the parties actually agreed that it was the type of the data that was relevant to the construction of this term. In fact, that agreed construction, which, again, is the very first construction on page 1404 of the record, says that it's the data block or data field type of that data. So the problem with the plaintiff's construction, first of all, is that it contradicts the very agreed construction that they agreed to, that this was about the data, not about the block, not about the field, but about the data. Once we get past the fact that this is about the data, we get to the intrinsic evidence that tells us what data types there are. The intrinsic evidence suggests a number of data types, the ASCII data type, numerical data types. But what they all have in common is that they line up with the ordinary meaning of type, which is that it's a class with members. A type is a number of different things, all of which comprise a type. The difficulty with the infringement theory that the plaintiffs put forward is their expert has admitted that never do the accused systems of defendants look for more than one value. They never look for a class with members. They never look for a type. They're looking for one value, and that is not determining a data type, according to the claim construction. Now, looking specifically at the intrinsic evidence, Mr. Thomas read to you from the 747 summary, and it's very important to note what he didn't read. This is looking at lines 35, I believe he read lines 31 through, let's see, let me make sure I get the exact right one. Yeah, so this is in lines 31 through 34, and he told you that you perform data compression on the block, comprise it to steps up. What he missed, what he didn't read and actually skipped over was the language, if the data type of the data block is identified. In other words, the language he read you about characteristics only occurs after the language that's described in the claim language at issue. And what's even more important, Your Honors, is to look at the paragraph above that paragraph. That paragraph says, if the data type of the data block is not identified, you can estimate the desirability of using an encoder based on the characteristics. If the characteristics are part of the data type, why would they ever be used when the data type is not identified? That paragraph, which is in column 4 on page 480 of the record, starting at line 21 and ending at line 26, shows that there is a contradiction between the plaintiff's construction and the actual language of the claim and the intrinsic evidence. So the intrinsic evidence actually the intrinsic evidence clearly show the data type was about a class or category of data, not a single value. Having understood that the situation with the judge's construction was actually in accordance with the intrinsic evidence, we can now move to the other citation that Mr. Thomas pointed us to, which was at page 489. And again, what this citation shows us is that the plaintiffs chose to claim their invention in a way that did not include the broad reading that they now want to impose. This is at the bottom of column 22, where it talks about you can use data types and then talks about other parameters. Well, what's important to note here is that- Do you want to give us a line? Oh, sure, Your Honor. It's at column 22, and that starts at line 65. And that says that you can analyze the incoming data stream for recognition of data types and then give some other options as well. What's important to note is that the three patents that are in front of this court had prosecution histories of from 7 to 12 years. These were not patents where we had an initial application that became a patent. There was a lot of back and forth, continuations, new claims, new ideas. In order to get these patents out of the patent office The list of prior artists, 4, 5, 6, 7, 8 pages long. Yeah, I think for the 651, it's pages and pages. It's hard to even get to the figures, Your Honor. And that long prosecution, both in terms of years and in terms of the amount of prior art that was introduced with IDSs, resulted in claims that chose a particular way of implementing the invention. And this court has found that when the plaintiff chooses a particular way of implementing the invention and puts that in their claims, they're bound by it. And that's all we're pointing out here is the defendants. They chose one of these options. They implemented that in their claims. Those are the claims they've asserted against us. They should be held to that. In view of the fact that the judge was correct to say that data type requires a category of data, we now move to the second part of the infringement analysis, which is applying that claim construction. And here, the court should keep in mind that what's important is not is there a disputed fact with regard to the terminology used. It's is there a disputed fact regarding the system's operation. That's what this court looks to in determining whether summary judgment's appropriate. And there is no question about what the defendants' accused systems do. They look for a single value. How they calculate that value differs. If it's copy, they just take the previous value and use it that way. If it's increment, they take the previous value, add one. But the end of the game is, what are they looking for? They're looking for a single value. And what Judge Forrest did is appropriate. She compared the claim construction, which said a category, a classification, the ordinary meaning, a group of values, and said, is that a single value? And she said, no, it's not. The plaintiff's position that this is somehow an extra interpretation would mean that you would never be able to do your comparison without having an extra interpretation. You're always going to be looking at the claim construction and the accused products and saying, do they match? The fact that you say, no, they don't match, is not an extra interpretation. It's just an outcome of the step of infringement analysis that this court has set up. We identified in our brief how their expert agreed in his deposition that none of the accused systems ever look for anything more than one value. I think it's important to realize that when Mr. Thomas talked about how you look at the data to determine whether it meets one of the three logical data types, that does not occur. And that is clear in the record. And I'll point, Your Honor, to that portion of the record because it is very important to realize, and this is in the record on page 529, that the templates preset all the encoders. You never make a choice. That encoder is already set. It's on page 529. And it says, the message templates describe the layout of each message type and define which field encoding technique is to be used on each field. Because the defendants use a preset approach and real-time claimed and on-the-fly approach, there's no infringement. And I ask the court to affirm Judge Forrest's determination thereof. Thank you. Mr. Hawes is to leave. Thank you, Your Honor. My name is Bill Wade, and I represent Credit Suisse. I'm going to respond to three issues that Mr. Thomas responded to and which were addressed in our brief. I'll call them the descriptor issue, the section 112 issue, and then, if time permits, the lossless encoder issue that he addressed briefly at the end. So let me start with the descriptor issue. I'm actually the one who asked Mr. Thomas to make it clear that Claim 22 was not asserted against the banks and the data providers. And that's for an important reason. The claims that have the descriptor language in them that are, in fact, asserted against us are Claims 108 of the 651 patent and Claim 1 of the 747 patent. Both of those claims make it clear that the claim interpretation that this court adopted was, in fact, correct. So let me address the problems or the claim problems that Mr. Thomas identified. First, he suggested that there is an express definition of the term descriptor. Now, the argument they made below was the express definition is it requires no more than a data token. And they relied upon this claims express definition. If the court considers the sentence that Mr. Thomas identified, which is Claims 23 to 26, but then considers the preceding sentence, both of which are describing Figure 5 of a particular disclosed embodiment, those two sentences are entirely consistent with what the district court adopted as a claim interpretation. The sentences require that the descriptor be appended to the data block. The sentences require that they indicate the type of encoding that was done. That's precisely what she has said. Mr. Lee, do you want to respond on the 112 issues, respond to Mr. Thomas' statements? I will. Let me respond on the 112 issues, and I'll come back to the descriptor if I could. On the 112 issues, Your Honor, the focus is content-independent data decompression, content-dependent data compression. Those terms were added to the claims 10 years after prosecution began. Those terms have no meaning in the context of the patent. They actually make no common sense. And the simplest way to understand why they arise is that it's not inconsistent with the failure of written description. What you're, in effect, saying is they're there. They just don't make sense. Well, actually, Your Honor, the term content-dependent data decompression is not anywhere other than the claims. The portions that Mr. Thomas referred you to were in the summary were actually content-independent and content-dependent are describing compression, which is completely accurate. And then there's the word decompression. And there's decompression that occurs in some of the claims and in some of the systems described for sure. None of them describe content data decompression because if the court considers Figures 11, 13A, and 13B, all of the decompression is content-independent when you get to the other side. Content-dependent data compression and content-independent data compression are ways you pick the encoder. And the most significant thing about the specification says this. If you look at Figures 13A and 13B, it says if you're content-dependent, you go to the top half of the figure. If you're content-independent, you go to the bottom half of the figure. And whether you go to the top half or the bottom half, you may end up with precisely the same encoder. One example is the Huffman encoder. You could go content-dependent and end up with a Huffman encoder. You could go to the bottom and end up with a Huffman encoder. When you get to the decompression side, which is Figure 11, all the system cares about is that the encoder was Huffman. And therefore, it knows how to decode. It doesn't care how the selection was made. So when I say respectfully that it doesn't make sense, it's because content-independent and content-dependent are mechanisms described in the patent to choose an encoding method. When you get to the other side, you don't care how the choice was made. All you care is what the choice was. And that's why those claim terms actually both, Your Honor, don't make sense and therefore indefinite and also don't have written description support. It's actually more than not having written description support. The interpretation that's been given contradicts the specification. It doesn't make any sense in the context of what was alleged. And I don't know if I had it precisely correctly. I thought I did. I thought Mr. Thomas said content-independent data decompression or content-dependent data decompression would identify the encoders. They don't. And these claims require a descriptor that would say, you know, CIDD or CDD. They don't. And that's why it makes no sense. If I could come back quickly to the descriptor, and there are three points I'd like to make in the remaining time on this issue. The first is on claim construction, it's important to focus on what real time says are the issues before the court. One, they claim that the interpretation that requires that the descriptor be with the data block is incorrect. It's correct for the reasons we described in our brief, but I would refer to the court's JA5732, which is their PowerPoint slide in the Markman hearing where they said that the descriptor has to exist along with the encoded data somewhere in the data packet. The district court actually did what they said was accurate. The second point is this, and the reason I asked the court to focus on claims 108 and claim of the 651 patent and claim one of the 747 patent, they each require the analysis of the encoded data packet to identify a descriptor. It would make no sense if they were not together. And the third point is every single embodiment, from the summary of the invention to the figures to the written description, describe a descriptor that is with the data packet. Second argument that Mr. Thomas makes is, well, if the claim interpretation was correct, that with and specifies was correct, and we suggest it is, then there still was a factual issue for the jury to decide. That's incorrect for two reasons. And I'll do it in reverse order. I'll go to the doctrine of equivalence first, as well as what you raised. Importantly for this claim limitation, no one ever claimed that having a pointer would be equivalent. The court did interpret the requirement that it specify the encoder to be that the descriptor tells you what the encoder is. So you're going from point A to point B. There was never a suggestion that by going from point A to point B to point C could be equivalent. So it's a different equivalence argument than Mr. Hawes argued. There never was an equivalence argument, so we only have a literal infringement argument. And there is no literal infringement for this reason. The presence map and the template ID do not tell you what the encoder was. And Mr. Seamus says that at GAA 4304, page 116, lines 9 to 21. No dispute. He agrees that it doesn't tell you. You need to have the presence map, the template ID, and the template, which Mr. Hawes has described, as sent previously, hard-coded, fixed, and there. That template ID and the presence map, which do travel with the packet, everybody agrees, does not identify the encoder. The template ID, the template, which working with those two can identify the encoder, doesn't travel with the packet. Now, there's a reason for this. And the reason is this. Real-time's invention, by its own description, is intended to deal with dynamically identifying and encoding information when you don't know what the information is going to be. That's why you have to go one route if you know what it is, one route if you don't. It's dynamically dealing with unpredictable information. The FAST system is a system which is dealing with very predictable information. It is financial information that's being repetitively and iteratively communicated time after time again. And you know that it's going to be the same type of information, the same type of price information, the same type of increment and decrement information. And that's the reason that the template can be used. And only by using the presence map, which tells you whether a field exists or not, the template ID, which will point you to the right template, and the template together with the last message that was sent, can this system do the decoding. It can afford to do it that way because things are so predictable. Now, on the last issue, which is this question of lawful encoders, let me just say this. The parties agreed upon a claim interpretation. The court adopted the claim interpretation. That claim interpretation, which speaks in the present tense on its face, is not infringed as you found. There's no error in the claim interpretation because we agreed to it and the court adopted it, and there's no error in the summary judgment determination based upon that because you merely took the undisputed facts and applied it to the parties that agreed upon the claim interpretation. Thank you. Thank you, Mr. Lee. We'll hear from Mr. Shalek. Good morning, Your Honor. My name is James Shalek, and I represent NYSC Euronext, NYSC ARCA, NYSC Market LLC, SIAC, and OPERA. And I will be addressing the issue of data stream on behalf of ISC as well as my own clients. Defendants made an unrebutted factual showing that in all the accused systems, the same server that performs compression retrieves the data that is to be compressed from its own internal memory. That is precisely what Realtime's experts said could not be a data stream in every one of the nine declarations that they filed during reexamination. Mr. Shalek, I've been waiting for one of you to address Mr. Thomas' discussion of Metro PCS. I'm assuming you're going to. I am. Realtime's counsel in Metro PCS described the disavowal of an internal memory fetch as clear and unmistakable at JA-6480. Realtime's counsel also described as a unmistakable disavowal the notion that any claim that data whose sequence had been altered by the system performing compression could be a data stream. And NYSC, the three entities, SIAC and OPERA, also made factual showings that the sequence of data is, in fact, altered in their systems, which the district court credited as well. We submit that Realtime should be held to its positions under the spring windows fashion case where this court held that it was entirely proper to hold an examination during prosecution, which the examiner chose not to adopt as the broadest possible reasonable construction. We are noticed to the public as well served by doing so. As we submit, it is here by virtue of sheer force of repetition. In this regard, in the spring windows fashion case, the court was influenced by the fact that the statements that had been made were detailed, consistent, and consistent with what they are here. Realtime argues that the district court changed the construction that had been given data stream in the Packetier case, but that is untrue. In Packetier, the court had construed data stream as one or more blocks transmitted in sequence, and Realtime's experts during reexamination did not disavow the Packetier construction. They simply explained what it meant to transmit data in sequence. And in that regard, all the Ligler declarations acknowledge the Packetier construction and state that retrieval from internal memory is not a transmission and therefore not a data stream. And all the Modestino declarations similarly state that a data stream must be understood to exclude retrieval of data from internal memory. And they also say that a data stream is something that comes from an external source. So Realtime's experts only claimed to make explicit what was already implicit in the Packetier definition. And when the district court below chose to adopt Realtime's experts' conclusions, it did not take a position inconsistent with Packetier, but rather one that was entirely consistent with Realtime's experts' explanation of it. Now, Realtime took the same position in Metro PCS just months after summary judgment was granted here. And the Metro PCS Markman decision, in fact, comments, Realtime states, and defendants apparently agree, that the patents in suit are directed to co-oppression systems that receive data from an external source. That's at JA6299. And the critical distinction in Metro PCS was not received. It was data stream. And the Metro PCS brief at JA6321 characterized Dr. Modestino as not arguing a distinction between active and passive receipt that was important, but rather the critical distinction between an internal memory fetch and the claimed element of a data stream. And even here in a summary judgment briefing below at the JA6267 and 6283 Realtime didn't really try to argue that its experts hadn't said what it had said or that there were disavowals. Rather, they argued that the accused systems, even though they didn't have internal memory fetches and even though they controlled the sequence of transmission of data, could still be found to infringe because under the FAS standard, somewhere, at some place at some time, there should be a data stream. Well, this argument fails because, first of all, the FAS standard is optional. And more importantly, neither the FAS standard nor Dr. Shain will say anything about what happens to a data stream when it hits the input edge of the compression systems, how it's sorted, processed, stored when it arrives at the compression systems. And the dispositive point is that the claims of the 568 patent upon which the district court granted summary judgment for all the defendants is that the claims require the presence of a data stream at the point of encoding. Claim one is directed to applying encoding to a data stream, and by doing so by recognizing the data field type in the data stream. And claim 20 is directed to outputting an executable file to process a stream by recognizing data field type in the data stream and applying associated encoders. So under the 568 patent, the encoding has to be applied directly to the data stream. And Dr. Modestino made this very same point in the reexamination of the 568 patent. There he noted that the XML data stream that came in in the XML prior art had been sorted into containers and only after that had happened had there been a compression. And Dr. Modestino said that the very same language that's now present in the 568 patent requires the presence of a data stream at the point of a compression. So real-time principal failure here is that they failed to provide evidence that a data stream is actually present at the point of encoding. And the district court recognized that this was the dispositive point. In relation to IFC, JA190, she has a heading in her opinion that asks whether there is a data point, a data stream at the point of encoding, and she found the evidence one-sided, nothing material having been provided by real-time. In relation to NYFC, she also found the declarations had been basically unrobotic. In relation to the other two patents, the 651 and the 747, the issue there is very simple. Summary judgment was only granted in relation to one product of IFC, its fast processing, because that product sends its output directly into memory and it doesn't serve as a stream at all. It's never input to anybody. So before concluding, I'd just like to address a couple of the points that real-time made in its reply brief. One in particular is that they claim that the district court read figures one and two as a preferred embodiment out of the patent. And that is not true. Figures one and two in the associated text do not say anything about input data streams. The only data stream that's described in those figures in the associated text is the data stream that's compressed and sent to the decoder. On the input side, there's a very general reference to content 11, which is input into a server 12. And there are very general claims in the 568 patent that claim that kind of arrangement. They are not directed to a data stream, but they're directed to a financial data feed. Claims 53 through 67 are all directed to a financial data feed and cover that embodiment. Figures shown in the 747 patent, which are incorporated by reference into the 568 patent, are directed to an input data stream. And they are the embodiments that are covered by the claims at issue on this appeal. In fact, Dr. Modestino, in the reexamination, cite those very figures as evidence of the fact that data stream can only be construed as the district court in fact construed it here. So we have real-time taking a position on appeal that is entirely inconsistent with Dr. Modestino's position during reexamination. I'd also point out that even the data stream claims can cover some kinds of market feeds created by the exchange. In the Jacob Declaration, there's a diagram at JA 6670 reproduced at page 19 of our red brief that shows uncompressed data streams coming into OPERA, and had OPERA compressed those data streams, then perhaps the claim element would have been met. Our declarations were directed to showing how that input stream was dismantled, sorted, stored, the sequence of data altered, so that no data stream existed at the point of compression. Thank you. Thank you, Mr. Sherwood. Thomas has about eight and a half minutes for rebuttal. Thank you, Your Honor. Taking him in turn, Your Honor, with respect to data type, the suggestion that a logical relationship, which is exactly what Dr. Seamus identified was looked for during the analysis of the data content, cannot and does not constitute a data type, is contrary to the evidence in the record. Specifically, we presented an IEEE dictionary to the court that defined data type as including logical data types. So the suggestion that when Dr. Seamus identified that the data that was residing in the block that was being analyzed was then compared to data somewhere else to see if it met a redundant test, or if it met an increment test, or if it met a most common value test. It was whether or not that relationship exists that led to the next step in the claim process, that is, selecting the content-dependent compression algorithm. All the analysis has to do, according to Claim 22 and all the claims, is be able to permit the selection of at least one content-dependent compression algorithm. And Dr. Seamus' declaration establishes that there's more than a sufficient basis to believe that that relationship check, not a value check, a relationship check, is a logical data type. I would also point out, Your Honor, that with respect to data type, what we claimed was a data block type. Let's not forget that they always want to compress the claim language here, and they say, oh, they're just analyzing the content of the data to determine a data type. No, it's to determine a data block type. And we use that term because we wanted to capture any and all data types, because there are numerous data types that weren't even known at the time of filing this application, and we certainly weren't trying to exclude the usefulness of looking for specific new data types that might arise. So those data types could be any logical relationship or characteristic or attribute. So when we said data block type or data field type, that's what we were trying to capture. We weren't trying to exclude anything or claim more narrowly. I'd also point the Court's attention to Joint Appendix page 4228. That's actually a declaration submitted by one of the defendant's experts, Dr. Brogioli. Dr. Brogioli read Claim 1 of the 568 patent, and it's analyzing the content of the data block or recognizing the content of the data block, to read on analyzing the value that existed in that particular data block. And he did that because he was trying to make a 102B on sale bar allegation. So he was trying to establish that what we had demonstrated by way of our prototype well earlier in our development efforts, because there was a prototype that was demonstrated to at least two of the defendants by the inventors of the patents in suit and by real time. And they were trying to make out a 102B on sale bar, so they had their expert go in and try to reclaim one of the 568 patents on what we had done. And he said, oh, analyzing the value in there, that counts as analyzing the content of the data block. And indeed it does, because it's not just a value check. We're not just looking for one number. We're not looking to see if a number is even there. We're looking for a relationship. Is it the same as the number in the immediately preceding message? Because that number changes. So you're looking for the redundancy, or you're looking for the increment. So you're not looking for a single number, nor are you looking for one number. You're looking for a relationship, and that's exactly what Dr. Chambliss expressed and how he showed that even under the court's construction of data type or data block type as being one of any other kind of data type, we could have proven infringement if we'd have been given the chance, and we should have been given the chance. Turning to the descriptor claim language, what the court did there, and I had specified it, and I don't believe it was actually addressed directly by Mr. Lee, is the court said the descriptor for specifying. That's not part of the definition that the inventors included in the patent specifications in all three of the patents. For specifying, though, doesn't necessarily mean that you have to have everything that's necessary for doing the decompression. For specifying, as Dr. Chambliss explained, merely means that all you have to have in the descriptor is sufficient information that can tell you how to go about doing the decompression at the receiving end. So even under the court's construction where there is a descriptor appended to the data packet for specifying what the selected lossless encoder was, Dr. Chambliss explained how the PMAP and the template ID, along with that state machine that exists, that template that exists at the receiving end, are more than actually exactly what's necessary to specify where to go to figure out what the lossless encoding technique was that was applied for any particular data flock. And that's all that claim construction required, yet what the court did in the summary judgment motion is say, no, no, no, it's not just for specifying. It's got to be alone for specifying, or by itself must be able to specify. And that's not what the claim construction required, and it's certainly not a fair reading of what our patent definition of a descriptor says. With respect to content-dependent data compression and content-independent data compression, I would ask the court to think about it like this. That construction requires that the same party that's compressing something decompress it. So that construction requires that you compress something and send it to yourself, and then you decompress it. Now think about that. Why would you compress something you already have if all you're going to do is send it to yourself so you can decompress it? It's nonsensical in the context of a compression algorithm and a data compression system. Because remember, the claims here, the ones that require the content-dependent data decompression and content-independent data decompression claim a decoding system, not just a system and not a system for encoding and decoding, a decoding system. And these content-independent and content-dependent data compression Why is it clear that you're sending it to yourself? I'm sorry. Well, because with respect to the construction of the I'm talking actually now about the encoding-decoding claims here, Your Honor, the ones where the court said that the wearing clauses require that the same party that is doing the decoding have done the encoding. And so in those content-dependent, content-independent claims, the ones where the court said, okay, if the data stream, which those claims simply do define to have certain characteristics, and those characteristics define how the data was compressed in that data stream that's arriving at the decoding system. The court construed that to say, ah, well, the same party that's getting the compressed data stream and decoding it must be the same party that encoded it because that's how she read the wearing clauses. We believe the wearing clauses in those claims are simply giving you the environment in which the decoding system operates. And so from that purposes, Your Honor, we don't believe it makes any sense for the court to have construed those decoding claims to require that the same party that does the encoding have to do the decoding. And that's inconsistent with the embodiments that I explained before and pointed to, Your Honor, in Figure 1. Last, with respect to data stream, Your Honor, key there is that the court ruled that the data stream required that it be coming from a third party. And that's an unnecessary limitation. And that's how she overcame the testimony and evidence that we presented from Dr. Seamus under which we could have met that claim construction if given the chance of trial. Because there's no requirement anywhere in the term data stream or receiving a data stream that says that the third party has to be, that that data stream has to be coming from a different entity. But that's what the court did. And, Your Honor, I'm out of time. Thank you for your time. Just a moment. Mr. Thomas, I was arguing before Court of Appeals, and as Mr. Hawes did, my opposing counsel said that I had skipped over certain important language in Column 4 of the patent. I'd address it directly rather than in general terms. Absolutely I can, Your Honor, because I think what the suggestion was there that there was a, as I recall, Your Honor, the language that was alleged to be skipped over was the language dealing with descriptor or data type and the data block. And I think what we were saying, what Mr. Hawes was saying there, was that we were somehow claiming just one of a string of possible characteristics or parameters. Well, I don't think he was saying he left out relevant language. And I would want to address that directly myself. Well, I pointed, Your Honor, to JA 48990 at Column 22, Line 63, as well as Column 480. And I said the step of performing content-dependent data compression if the data type of the data block is identified, because that's where you, when you recognize the relationship, Your Honor, as one that you're searching for, that's when the content-dependent compression algorithm is applied. If the relationship doesn't exist, then the content-dependent compression is not applied. Something else is done. So all this says is the step of performing content-dependent data compression on the data block, if the data type of the data block is identified, if the data type of the data block is not identified, comprises the steps of identifying it. And that's where you'd have a content-independent data compression. In other words, Your Honor, if there is a lack of a relationship that one is looking for, then you wouldn't go about using content-dependent data compression. Am I addressing Your Honor's question? Well, that's up to you. Thank you, Mr. Thomas. We'll take the case and revise it. All rise. Thank you.