UNITED STATES DISTRICT COURT SOUTHERN DISTRICT OF NEW YORK
November 15, 2012
REALTIME DATA, LLC D/B/A IXO, PLAINTIFF,
MORGAN STANLEY ET AL., DEFENDANTS.
REALTIME DATA, LLC D/B/A IXO, PLAINTIFF,
CME GROUP INC., ET AL. DEFENDANTS.
REALTIME DATA, LLC D/B/A IXO, PLAINTIFF,
THOMSON REUTERS, ET AL. DEFENDANTS.
The opinion of the court was delivered by: Katherine B. Forrest, District Judge
AMENDED OPINION & ORDER
In 2009, plaintiff Realtime Data, LLC d/b/a IXO ("Realtime") sued a number of companies involved in some aspect of the financial services industry (including banks, exchanges, and information services) for infringing three of its patents: U.S. Patent No. 7,417,568 (the "'568 Patent"), U.S. Patent No. 7,714,747 (the "'747 Patent"), and U.S. Patent No. 7,777,651 (the "'651 Patent" and collectively with the '568 and '747 Patents, the "patents-in-suit").
This Court has already issued several decisions on various issues in this litigation, and refers to those decisions for additional facts. See, e.g., Realtime Data, LLC v. Morgan Stanley, 11 Civ. 6696, 2012 WL 3158196 (S.D.N.Y. Aug. 2, 2012); Realtime Data, LLC v. Morgan Stanley, 11 Civ. 6696, 2012 WL 2545096 (S.D.N.Y. June 27, 2012); Realtime Data, LLC v. Morgan Stanley, 11 Civ. 6696, 2012 WL 2434750 (S.D.N.Y. June 26, 2012); Realtime Data, LLC v. Morgan Stanley, 11 Civ. 6696, 2012 WL 2394433 (S.D.N.Y. June 22, 2012); Realtime Data, LLC v. Morgan Stanley, 11 Civ. 6696, 2012 WL 1711117 (S.D.N.Y. May 10, 2012).
Defendants have counterclaimed for non-infringement and invalidity. On July 19, 2012, the Court ordered that the trial as to the Exchange Defendants will proceed first.*fn1 (See 11 Civ. 6696, Dkt. No. 539.) That jury trial is scheduled to commence on November 26, 2012.
I. PROCEDURAL BACKGROUND
Defendants and plaintiff now have 19 separate, fully briefed motions for summary judgment (on the question of liability) pending before this Court.*fn2 The motions put forth a smorgasbord of separate arguments. Each motion asserts more than one basis for the proposition that as to one or more of the accused instrumentalities, Realtime cannot prove a required claim limitation. Accordingly, the 19 motions require the Court to evaluate the merits of far more than 19 arguments.*fn3
Buried in one of those motions are issues amenable to resolution on summary judgment; however, many are not. It is important that a jury not be burdened with arguments that are properly resolved by the Court now. It is even more important that this Court not usurp the role of the jury by making determinations of fact, weighing evidence, or making credibility determinations.
Finding a path evenly distributed between judicial efficiency and the merits has been challenging. To assist the Court in sheer organization of the volume of paper, this Court assigned a number to each motion, and requested that the parties submit their views as to the order in which the Court should resolve the motions.
Based upon the Court's review of the letters submitted pursuant to that request (see 11 Civ. 6697, Dkt. Nos. 834 & 835), as well as its own review of the motions and the likelihood that resolving certain motions might assist in more rational trial preparation, this Court resolves the following motions in this Opinion: International Securities Exchange's ("ISE's") Motion for Summary Judgment of Noninfringement (Motion No. 4); CME Group Inc.'s ("CME") Motion for Summary Judgment of Noninfringement Based on the Lack of Determining a Data Block of Field Type (Motion No. 5); NYSE and Options Price Reporting Authority, LLC ("OPRA")'s Motion for Summary Judgment of Noninfringement Due to the Absence of the Encoding, Data Block (or Field) Type, and Selecting Limitations (Motion No. 6); NYSE, et al.'s Motion for Summary Judgment of Non-Infringement Descriptor Limitation (Motion No. 8); and Credit Suisse's Motion for Summary Judgment of Noninfringement: Descriptor Limitation (Motion No. 9).*fn4 For ease of reference, the Court refers to the various motions by assigned number throughout this Opinion. When referring to all five motions collectively, the Court uses the term "Motions."*fn5
II. THE PATENTS-IN-SUIT
Each Motion delves deeply into claim limitations of the patents-in-suit. Resolution of the Motions requires some understanding of the inventions at issue read against the backdrop of this Court's prior ruling on claim construction. See generally Realtime Data, LLC, 2012 WL 2394433 (referred to herein as the "Markman opinion").
Both the '651 and '568 Patents are entitled "System and Method for Data Feed Acceleration and Encryption." (See '568 Patent at ; '651 Patent at .) The '568 Patent issued first and discloses a system and methods for providing accelerated transmission of broadcast data, such as financial data and news feeds, over a communication channel using data compression and decompression to increase bandwidth and reduce latency. (See '568 Patent col.5 ll.25-32) The claims of the '568 Patent relate generally to methods for compressing data through encoding applied to a data stream. Certain claims relate to the method and application of selected encoders.
In contrast, the '651 Patent relates to a method of decoding one or more encoded messages. The decoding method requires receiving an encoded message, determining which decoder to utilize, and performing the decoding.
The '747 Patent claims both methods for decompressing one or more compressed data packets using multiple decoders that apply lossless decompression techniques, as well as methods for using multiple encoders that apply lossless compression techniques.
Key aspects of the inventions relate to, inter alia, how and when encoders and decoders are selected, how and when they are applied, to what they are applied, and whether they are in fact lossless.
Defendants universally claim that they have adopted an industry protocol referred to a compression and decompression standard called "FAST," and that FAST does not infringe on plaintiff's patents. Further, the "FIX Protocol" was copyrighted in 2006. It has been utilized by defendants.
III. GENERAL BACKGROUND
In connection with the Motions, there are certain facts relating to the FAST standard that are not materially in dispute.
A basic and overriding contention in this litigation is that FAST infringes the patents-in-suit. FAST is described in the Abstract of the FIX Protocol as "a space and processing efficient encoding method for message oriented data streams. It defines the layout of a binary representation and the semantics of a control structure called a template . . . ." (See Decl. of James Storer In Support of NYSE and OPRA Defs.' Mot. for Summ. J. of Noninfringement Based on the Absence of Encoding, Data Block (Or Field Type), and Selecting ("Storer Decl. Mot. 6") Ex. 1 at NYSE00083123.) According to the FIX Protocol, the FAST encoding method reduces the size of a data stream on two levels.
First, a concept referred to as Field Operators allows the data affinities of a stream to be leveraged and redundant data to be removed. Second, serialization of the remaining data is accomplished through binary encoding which draws on self-describing field lengths and bit maps indicating the presence or absence of fields. (Id. at NYSE00083128.)
FAST uses a template, or table, that identifies for each field the data type expected to be present in that field, and a field operator*fn6 that will be applied to the field during the encoding process. (See Decl. of James Storer in Support of Defs.' Mot. for Summ. J. of Non-Infringement: Descriptor Limitation ("Storer Decl. Mot. 8.") ¶ 11.) The template is not attached to the data block that is compressed. Instead, it acts as a reference tool to identify the appropriate field operator. (See id. ¶ 19.) A template identifier (or "template ID") along with a presence map (or "PMAP") are used to reference the template and determine which field operator was used. (Id. ¶¶ 21-23.) The template ID does not itself state which field operator was used. (Id. ¶ 23.) The template is never transmitted with the compressed data from encoder to decoder. (Id. ¶ 21.)
IV. LEGAL STANDARD
Summary judgment is warranted if the pleadings, the discovery and disclosure materials, along with any (admissible) affidavits, demonstrate that there is no genuine issue of fact necessitating resolution at trial. Fed. R. Civ. P. 56(c); see also Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 247 (1986); Celotex Corp. v. Catrett, 477 U.S. 317, 322-323 (1986). A party moving for summary judgment bears the initial burden of demonstrating that no genuine issue of material fact exists; all reasonable inferences should be drawn in favor of the non-moving party. See Liberty Lobby, 477 U.S. at 255; Cont'l Can Co. USA, Inc. v. Monsanto Co., 948 F.2d 1264, 1265 (Fed. Cir. 1991). The burden then shifts to the non-moving party to come forward with "admissible evidence sufficient to raise a genuine issue of fact for trial in order to avoid summary judgment." Jaramillo v. Weyerhauser Co., 536 F.3d 140, 145 (2d Cir. 2008); see also Glaverbel Societe Anonyme v. Northlake Mktg. & Supply, Inc., 45 F.3d 1550, 1560-61 (Fed. Cir. 1995) ("When the movant's burden of establishing the lack of a genuine issue of material fact has been met 'in facial terms,' the non-movant must point to 'some evidence in the record sufficient to suggest that his view of the issue might be adopted by a reasonable factfinder.'" (quoting Resolution Trust Corp. v. Juergens, 965 F.2d 149, 151 (7th Cir. 1992))). Where the non-moving party would bear the ultimate burden of proof on an issue at trial, the moving party satisfies its burden on the motion by pointing to an absence of evidence to support an essential element of the non-movant's claim. See Intellicall, Inc. v. Phonometrics, Inc., 952 F.2d 1384, 1389 (Fed. Cir. 1992).
Where it is clear that no rational trier of fact could find in favor of the non-moving party, summary judgment is warranted. See Liberty Lobby, 477 U.S. at 248. However, the mere possibility that a dispute may exist, without more, is not sufficient to overcome a convincing presentation by the moving party. Id. at 247-48. Similarly, mere speculation or conjecture is insufficient to defeat a motion. W. World Ins. Co. v. Stack Oil, Inc., 922 F.2d 118, 121 (2d Cir. 1990).
In ruling on a motion for summary judgment, a court cannot, however, weigh the evidence or make credibility determinations: those are the functions of the jury. See Liberty Lobby, 477 U.S. at 255. Further, when there are dueling experts, both of whom have put forward opinions in contradiction with each other, and when those opinions are important to resolution of a material factual dispute, summary judgment may not be appropriate. See Hodosh v. Block Drug Co., Inc., 786 F.2d 1136, 1143 (Fed. Cir. 1986) ("The fact issues herein must be resolved by trial in which the conflicting views of the experts will be subject to the refining fire of cross examination.").
The question is whether, at this stage of the proceeding, the court can determine whether the expert is merely asserting his own ipse dixit, which would be insufficient to defeat summary judgment, or whether two experts in the field could have reasonable differences. If it is the latter, then the Court must leave credibility determinations and the weighing of the experts' opinions to the jury.
V. MOTION 4*fn7
ISE is accused of infringing both the '568 and '651 Patents, and has moved for summary judgment as to all claims of infringement asserted against it. It presents 11 arguments supported by an expert declaration from Dr. James A. Storer ("Storer Decl. Mot. 4") and a declaration from ISE's System and Product Strategy Officer, Gregory J. Maynard ("Maynard Decl.").
In opposition, Realtime offers multiple responses to each of the 11 arguments as well as what it believes is support for its position(s) from the declaration of its own expert, Dr. Michael Ian Shamos ("Shamos Decl.").
According to Realtime, three of ISE's encoding products and methods are infringing instrumentalities: (1) ISE.Fast Encoding; (2) MIDAS Encoding; and (3) ISE.FastProcessing Encoding (collectively, the "ISE Accused Encoding Instrumentalities"). Realtime also accuses four of ISE's decoding products or methods of being infringing instrumentalities: (1) ISE.FastProcessing decoding; (2) Exergy OPRA Decoding; (3) OPRA Decoding; and (4) ISE.FastSpec Greeks Decoding (collectively, the "Accused Decoding Instrumentalities" and with the ISE Accused Encoding Instrumentalities, the "Accused Instrumentalities").
In order for any of the accused instrumentalities to infringe, it must satisfy the limitations in each asserted claim.
A. Do ISE's FAST Applications "Analyze" or "Recognize" to Determine Data Type?
Each of the claims that ISE is accused of infringing require "analyzing" or "recognizing" to determine data type. ISE argues that Realtime relies on a "value check" performed by the instrumentality at issue to determine the data block type of data field type, and that this fails to comply with this Court's Markman opinion which requires "content categorization," not checking a value. (See Mem. of Law in Support of ISE's Mot. for Summ. J. of Noninfringement ("ISE Mem.") (11 Civ. 6697, Dkt. No. 685) at 3-4.)
According to ISE, checking the value of a particular field is not the same as "analyzing" it to determine data type. ISE refers to the following example: if the COPY operator is being applied to a particular field, and the previous message had a "5" associated with the same field, a program implementing FAST's COPY operator will check to see if the value of the current field is "5"--but it will not try to determine data type. (See ISE Mem. at 4.) ISE argues that the FAST data types are already known and are set forth in templates prior to compression.
Realtime responds that the encoder is not simply checking a value. According to Realtime, even in the example that ISE provides, ISE is checking the value against the value in a prior message. Realtime argues that this is sufficient to constitute an "analysis." (Realtime Data, LLC's Mem. in Opp'n to ISE's Mot. for Summ. J. of Non-Infringement ("Opp'n Mot. 4") at 5-6.)
There is no dispute that there is a comparison of values that occurs as part of ISE's encoding process. The issue is whether the two-step process constitutes an "analysis."*fn8
(Notably, as presented, that argument is not based on the type of content to which the "analysis" relates.) The parties have submitted dueling expert opinions on this question. The Court cannot resolve the question of fact as to whether ISE's two-step process constitutes an "analysis." Accordingly, the Court rejects this argument as a basis for a finding of summary judgment, and denies this aspect of Motion No. 4.
B. Are Fast Field Operators Encoders?
ISE argues that its Accused Instrumentalities do not employ encoders. ISE correctly notes that this Court has previously construed the term "encoder" to mean "hardware or software that compresses data by converting the contents of a data block (or data field) into a coded representation of those contents." See Realtime Data, 2012 WL 2394433, at *16. The Court's construction makes clear that a key distinction is that encoding must be more than simply "compression"--it must include some form of "coding" or changing of representation. See id. at *8-9. The Court also determined that throwing data "away" or "no change" does not constitute "encoding." Id. at *9.
Realtime has asserted that three of ISE's accused instrumentalities use or include encoders: COPY, DEFAULT and INCREMENT. According to ISE, none of those instrumentalities use or include encoders because none "code" data. (See ISE Mem. at 6.) Realtime asserts that in fact all three of the accused instrumentalities generate a coded representation. (See, e.g., Shamos Decl. ¶¶ 16, 17.) It relies upon the fact that ISE products all use FAST encoding techniques, as stated by Dr. Storer. (See Opp'n Mot. 4 (citing Storer Decl. Mot. 4 at 5-8).) According to Realtime, lossless encoding techniques can include "field encoding"--and field encoding includes copy, default and increment encoding. (Id. at 7-8.) Realtime also argues that such encoding techniques are content dependent--i.e., that default encoding is applied when the content of the data block or field has a data type "most common value"; "most common value" is determined based on prior knowledge of the data stream. (See id. at 7-8.)
Realtime asserts that all of ISE's accused products use copy encoding, citing Exhibit 2 of the Shamos Declaration. (Opp'n Mot. 4 at 8.) Exhibit 2 does not, however, provide this level of detail. (See Shamos Decl. Ex. 2.) Assuming some of the coding is copy encoding, that is when the content of a data block or field in the current message is analyzed by comparing the content with the content of the corresponding data block or field of a prior message. If two data types are the same, copy encoding is selected as the optimal encoding for the "redundant" data block type of the data block. (Shamos Decl. ¶¶ 17, 71, 73.) When copy encoding is utilized, the question is whether there has been any actual "encoding" at all. According to Dr. Shamos, there has been because a coded representation of the data block is sent with the message in a PMAP that is included with the message. (See id. ¶¶ 17, 71, 73.) Dr. Shamos also states that some of the accused instrumentalities use increment encoding but he does not explain how. (See id. ¶ 17.)
Finally, according to Realtime, each of ISE's accused instrumentalities use "stop bit encoding" (also called "transfer encoding" or "variable byte encoding"). (Opp'n Mot. 4 at 9.) Stop bit encoding is used by ISE's accused instrumentalities when the data is not suitable for copy, default, or increment encoding. (Shamos Decl. ¶¶ 30, 35.) According to Dr. Shamos, this renders stop bit encoding a content independent compression technique. (See id. ¶ 35.) In addition, Dr. Shamos supports the proposition that "with stop bit encoding, the data field (or block) is converted into a coded representation comprising only the information content bits of the field (or block), which is transmitted along with one or more stop bits that indicate the unused bits of the data field that would not be transmitted." (Opp'n Mot. 4 at 9-10 (citing Shamos Decl. ¶¶ 19, 30, 35).) Thus, according to Dr. Shamos, the "stop bits" along with the information content bits of the encoded data together comprise a coded representation of the data block. (See Shamos Decl. ¶¶ 30, 35.)
ISE argues that stop bit encoding is not, in fact, content independent. (ISE's Reply Br. in Support of its Mot. for Summ. J. of Noninfringement ("ISE Reply") (Dkt. No. 795) at 7-8.) ISE's System and Products Strategy Officer Maynard states, though, that stop bit encoding embeds intelligence into each byte in a field. (See Maynard Decl. ¶ 20.)
There is a material dispute of fact as to whether the Accused Instrumentalities employ encoders and if so, what type. Accordingly, summary judgment is denied on this basis.
C. Are ISE's Encoders 'Selected' During the Compression Process?
The third basis upon which ISE moves for summary judgment is that, according to ISE, all but two claims (claims 20 and 22 of the '568 Patent) require that an Accused Instrumentality "select" an encoder. (See ISE Mem. at 7.) According to ISE, none of its Accused Instrumentalities meet that requirement.
This Court has previously construed the phrase "selecting an encoder" as "choosing (or choose) an encoder (or lossless encoders) during the compression process based on analyses of content of the data blocks (or data fields)." See Realtime Data, 2012 WL 2394433, at *16. As the Court noted in its Markman opinion, the essential difference between the parties with respect to their proposed constructions has to do with the temporal moment when the encoder is selected. Id. at *12. The Court concluded that the selection occurs during the compression process and that this requires an analysis of the content of the data block. Id. at *13.
According to ISE, the selection of its encoders is preordained--i.e., the encoders are set forth in a template prior to the compression process. Thus, they cannot be selected during the compression process. (ISE Mem. at 8.) According to ISE's Maynard, the selection of the encoder could date back to March 2008 when the template was written. (Maynard Decl. ¶ 12; see also ISE Mem. at 8.)
Realtime disagrees. The essential difference between the parties is whether the encoder "selects" at the time of the creation of the template (which sets forth possible encoders), or whether the selection occurs when the data block is being analyzed during the compression process, when the template is referenced. According to Realtime, ISE's encoders are selected based on an analysis of the content of the data block. Part of that comparison involves an analysis of the data block against the template which sets forth possible encoders for certain data block types. (Opp'n Mot. 4 at 11.)
Realtime argues that "because ISE's section process occurs immediately after analysis, all of ISE's accused products contain the claim limitation." (Opp'n Mot. 4 at 12.) Realtime further argues that the fact that the template offers associations of data block types to optimal encoders does not replace the actual moment of selection of such encoder (even using the template reference) during the compression process. (Id.)
The debate over the temporal moment of "selection" must be distinguished from other aspects of the selection of the encoder that are not a part of this particular argument for summary judgment. This particular argument is exclusively focused on when selection occurs, not how or whether the descriptor meets required limitations. In terms of this narrow argument, there is a material dispute of fact as to when the selection of the encoder occurs. Therefore, summary judgment is denied on this basis.
D. Does ISE Use a "Descriptor"?
ISE argues that each of the asserted claims, with the exception of claims 20 and 22 of the '568 Patent, requires that the accused instrumentality contain one or more "descriptors," wherein the descriptors indicate which lossless encoder has been selected. (See ISE Mem. at 8.)*fn9 ISE asserts that none of its Accused Instrumentalities meet this limitation. (Id.)
This Court has previously construed "descriptor with the encoded data which identifies" [the selected encoder], as "recognizable data that is appended to the encoded data for specifying" the selected encoder. See Realtime Data, 2012 WL 2394433, at *16.
The facts relating to this descriptor issue are not in dispute; rather, their characterization is.
ISE argues that its accused instrumentalities do not have a descriptor. ISE contends to get around this issue Realtime tries to construct a "descriptor" through the combination of a PMAP and template ID or a message type. (See ISE Mem. at 9.) ISE argues that either combination does not identify the selected lossless encoders, as required. (Id.)
Dr. Shamos, however, argues that the combination of the PMAP and the template ID provide all of the information that is needed in order to determine which encoder was selected. (See Shamos Decl. ¶ 57.) Dr. Shamos does not, however, state that the information in the template ID or the PMAP in fact identify the selected encoder. Indeed, he could not because they do not.
The PMAP and template ID do not themselves identify the selected encoder; rather, they point to a fixed template which contains various encoder types. The PMAP and template ID then use that template to identify the encoder that would be used optimally to encode the data type at issue. There is no factual dispute that template is not "with" the encoded data; it is referenced by the PMAP and template ID. (See Storer Decl. Mot. 4 ¶ 151.) There is also no real "selection" of an encoder as part of this process; the encoder is simply referenced from the template.
The critical point of distinction between the parties is whether or not the template can be considered to be "with" or attached to the encoded data. ISE's Maynard argues that it is not--the template is provided to the customer before the compression process even begins and all that is accompanying the data block itself is the template ID and PMAP. (Maynard Decl. ¶¶ 12-17.) Maynard states that the template ID and the PMAP do not themselves provide any indication as to which type of transfer encoding might have been applied to a given piece of data. (Id.)
Realtime argues that ISE has taken a far too narrow view of what a descriptor is--or can be. Realtime does not dispute that the template ID and the PMAP reference back to the template. (Opp'n Mot. 4 at 14.) According to Realtime, the PMAP and template ID are utilized at the decoding end to reference the template which will then indicate which encoder was used. (Id.)
The question on this motion is whether the template, which in fact identifies the encoder that has been used, is "with" the data block as required by the language of the claim. The answer is "no." Although the PMAP and template ID are in fact with the data block, they do not contain information regarding the selected encoder. It takes another step--away from the data block--to determine which encoder has been selected. The "descriptor" therefore requires both information that is "with" the data block and information that is "not with" the data block. The claim requires that the descriptor be with the data block.
Accordingly, ISE is entitled to summary judgment on this basis.
E. Is ISE's Transfer Encoding Content Independent Data Compression?
ISE argues that claims 22, 25, 26, 29, 34 and 35 of the '651 Patent, claims 14 and 19 of the '747 Patent, and claim 22 of the '568 Patent all require that in order to be infringed, the accused instrumentality must utilize content independent data compression. (ISE Mem. at 10.) According to ISE, none of its Accused Instrumentalities meet this requirement.
This Court has previously construed "content independent data compression" to mean compression that is applied to input data that is not compressed with content dependent data compression, the compression applied using one or more encoders without regard to the encoder's (or encoders') ability to effectively encoded the data block type (or data field type).
Realtime Data, 2012 WL 2394433, at *16.
According to ISE, Realtime's infringement contentions (and Dr. Shamos) rely upon stop bit encoding to meet the content independent data compression requirement. (ISE Mem. at 11.)
ISE argues that stop bit encoding--or transfer encoding--is only used on certain data types and therefore must be content dependent. (Id.) According to ISE's Maynard, ISE chooses whether to apply transfer encoding based on the type of data in a field and whether it will be able effectively to encode that data. (Maynard Decl. ¶¶ 27-28.)
Realtime disagrees. According to Realtime, transfer encoding--which ISE concedes it uses--is used when three other types of encoders are not optimal (copy, incremental, and default encoders); that does not mean that the content of the data block is known. In fact, according to Realtime, the content of the data block can nonetheless be one of several different types including fields containing integer numbers, signed integers, unsigned integers, scaled numbers and ASCII strings. (Opp'n Mot. 4 at 16.) Transfer encoding may be applied to other types of data in addition to these but its application may not be optimal. (Id.)
Whether transfer encoding, which is used when other encoding techniques are not optimal, but when the content can be one of a number of different types, is content independent is a question of fact for the jury. Accordingly, the Court denies summary judgment on this basis.
F. Is Stop Bit Encoding "Lossless"?
ISE argues that all of the asserted claims of the '651 and '747 Patents require that the accused instrumentality use a lossless encoder or lossless decoder. (ISE Mem. at 11.)
This Court previously construed "lossless" to mean "technique, software or hardware that fully preserves the original unencoded data such that the decoded data is identical to the unencoded data." Realtime Data, 2012 WL 2394433, at *16.
ISE argues that Realtime has consistently cited ISE's stop bit encoding feature of FAST transfer encoding as meeting the lossless requirement. (ISE Mem. at 11-12.) As a factual matter, ISE argues that Realtime has never shown that any customers who decode ISE's encoded market data get data that is identical to that which was encoded. (Id. at 12.) According to ISE, that amounts to a failure of proof--i.e., that whether the stop bit encoding is lossless or not cannot be demonstrated on the current record and therefore summary judgment is warranted. (Id.)
ISE further argues that even if Realtime had undertaken to show that stop bit encoding was lossless, it could not have. (See ISE Mem. at 12.) ISE's Maynard states that when many feeds are FAST encoded in ISE's system, data is lost. (Maynard Decl. ¶¶ 22-26.) Moreover, when ISE decodes OPRA feeds, that decoding is not lossless because the encoding was not lossless. (ISE Mem. at 13.)
Realtime first argues that it has not limited itself to ISE's stop bit encoding, and that ISE's accused products, which include but are not limited to stop bit encoding, are lossless. Realtime points to an analysis of source code conducted by Dr. Shamos. (Opp'n Mot. 4 at 17.) According to Realtime, although there may be a lack of total identicality during the transmission process, once the data is encoded losslessly it can be decoded losslessly. (Id.)
Realtime points to ISE's transfer, copy, increment, and default encoding techniques as lossless. Realtime argues that the use of the PMAP and template ID allow for the reconstruction at the decoding end of identical data. Thus, while the data may be transmitted with less than all the data, the decoding process can achieve the required identicality. (Opp'n Mot. 4 at 17.) Realtime is correct that under the Court's construction, identicality is judged as the point of decoding. See Realtime Data, 2012 WL 2394433, at *16.
There is a material issue of fact, however, as to whether ISE's encoding techniques are lossless. Although it may be that there is no record of a before-and-after demonstration of encoding and decoding customer data, given Dr. Shamos' expertise in the field, he can opine as to his views, the jury can credit his testimony (or not) and weigh that testimony to whatever extent it believes it deserves in light of the analysis Dr. Shamos has (or has) not conducted.
The Court denies summary judgment on this basis.
G. Is there a Data Stream at the Point of Encoding?
ISE argues that all of the asserted claims in the '568 Patent require that the accused encoder must operate on a "data stream." (ISE Mem. at 13.) ISE argues that since none of its Accused Instrumentalities perform this step, none infringe. (Id.)
This Court previously construed "data stream" to mean "one or more blocks transmitted in sequence from an external source whose characteristics are not controlled by the data encoder or decoder." Realtime Data, 2012 WL 2394433, at *16.
ISE's Maynard states that for every ISE Accused Instrumentality, ISE generates its feed internally from stored data. (Maynard Decl. ¶¶ 41-43.) Thus, according to ISE, since the data feeds are "not external," they fail to meet one of the construed requirements for a data stream. (ISE Mem. at 13.) ISE points to statements by Dr. Shamos in which he appears to indicate that "ISE feeds" are internal (and therefore not external) to ISE. (Id. at 13-14 (citing Shamos Decl. ¶¶ 45-46).) ISE's Maynard states, however, that ISE's Accused Encoding Instrumentalities encode data that comes from within ISE's own systems, out of its own trading engines. (Maynard Decl. ¶ 41.) ISE's trading data is always under its own control. (Id.)
According to Realtime, ISE is simply wrong that the trading data is internal. Realtime argues that in fact trading data necessarily derives from external sources: the data from trades in markets or other institutions that are not part of ISE. ISE replies that Dr. Shamos admitted that he had no idea where ISE's trading data came from, and the only evidence in the record is from Maynard who states that it comes entirely from ISE's own internal trading engine.
According to Maynard, ISE's Accused Encoding Instrumentalities encode data that come from within ISE's own systems, and is passed from the trading engine to the server which performs the FAST encoding; that server stores the trading data in memory to create a duplicate set of trading data; the FAST encoder then uses this stored data in the memory of the server to, inter alia, form the FAST feeds. (Maynard Decl. ¶ 41.)
Realtime argues that ISE misconstrues the meaning of "external." (See Opp'n Mot. 4 at 20-21.) Realtime references certain prior art--"Sebastian" (cited in the reexamination proceeding for the '568 Patent)--to show a contrast between encoders that do and do not control change of sequence of data blocks. (Id. at 21.) In Sebastian, an encoder sorts incoming data blocks into buckets and compresses the data blocks in a particular order; thus, the data stream is not "external" to the encoder. (Id.) Realtime argues that ISE's Accused Instrumentalities do apply the FAST protocol to the data blocks as the data blocks are received and do not control or change the characteristics of the data blocks. (Id.)
The Court agrees that there is no material issue of fact with respect to whether the data is external. The evidentiary record is one sided on this point: the data comes from ISE's own trading engine. Although Realtime has asserted that this must mean that the trades reported in the data originated externally, that is an unsupported factual assertion. At the summary judgment stage, more is required. Thus, there is no material issue of fact that ISE's Encoding Instrumentalities do not infringe claims 15, 20, 22 and 32 of the '568 Patent. Summary judgment is granted on this issue.
H. Does ISE's ISE.FastProcessing Encoding Produce an Output Data Stream?
ISE argues that the encoding claims of both the '651 Patent (claims 13, 18, 19, 21, 22, 25, 26, 29, 34, 35, 43, 47 and 49) and the '747 Patent (claims 14, 19) all require that the result or output of encoding be a data stream. (ISE Mem. at 15.) ISE argues that the record is devoid of any evidence that this requirement is met with respect to the ISE.FastProcessing library. (See id.) According to ISE's Maynard, this library is used exclusively for encoding and decoding journal files, not for creating or decoding data streams. (See Maynard Decl. ¶¶ 35-37.) Journal records are maintained for audit purposes. (Id. ¶ 42.) ISE argues that its Journal Record Application cannot constitute the required "external source"--and that since the journal records are never sent to a third party they are not part of any output data stream. (ISE Mem. at 16.)
Realtime does not dispute that the ISE.FastProcessing Encoding creates journal files. However, according to Realtime, it is of no moment that those journal files are never sent to third parties--there is no requirement that they terminate with a third party. (Opp'n Mot. 4 at 22.) Again, Realtime relies upon its assertion, without record support and as contradicted by Maynard, that the information that forms the trading files must come from some external source. As stated, Maynard is clear that the trading files are generated from ISE's own trading engine and do not come from an external source. (See Maynard Decl. ¶ 41.) Realtime depends upon this assertion to make the following statement:
Because the activity in its trading engine must be related to information on trades, which are performed externally to ISE's Accused Encoders, ISE's journal records must contain data which was transmitted by an external source. Therefore, ISE's Accused ISE.FastProcessing encoding produces an output 'data stream.' (Opp'n Mot. 4 at 22.) Realtime does not support its assertion with any citation to any evidence--even an expert opinion. It is mere speculation.
Accordingly, the Court finds that there is no triable issue of fact that the accused ISE.FastProcessing encoding does not infringe the claims recited above. Summary judgment is granted in this regard.
I. Are There Data Packets At the Time of Encoding?
ISE argues that claims 1 (unasserted), 15, and 32 of the '568 Patent require that in order to be infringed, the encoder must operate on data in a "data packet." (ISE Mem. at 16.) ISE claims that it does not in fact encode data packets and therefore cannot infringe claims 1, 15, and 32 of the '568 Patent. (ISE Mem. at 10.)
The parties agree that the term "packet" means "information limited in type, format and content and able to be transmitted as a unit across a packet-switched network, the packet including control information that enables the packet to be delivered to an intended destination in the network." (ISE Mem. at 16.)
ISE asserts that its Encoding Instrumentalities, namely ISE.Fast Encoding, ISE.FastProcessing Encoding and MIDAS Encoding, do not FAST-encode data that is in a data packet. (ISE Mem. at 16.) According to ISE's Maynard, trading data may arrive in packets to the server, but they are stored in memory and are no longer "in packets" after that. (ISE Reply at 10; Maynard Decl. ¶ 41.) According to ISE, there is no evidence that ISE encodes data in packets at all--and indeed, Maynard states that it does not. (Maynard Decl. ¶ 41.)
Realtime argues that because the trading data is of a specific type (numerical) and format (a format acceptable to the server for which it was intended) and content (records of trades) is transmitted "over some kind of network from the trading engine to a server." (Opp'n Mot. 4 at 23.) Realtime extrapolates from those assertions that this must mean that the data meets the agreed definition of packets and travels in packets in the data stream. This is not supported by any facts. It is unclear that the format is limited in type--Realtime simply asserts without support that it is. In addition, there is nothing supportive of the proposition that the data is being transmitted as a unit, or over a packet-switched network (versus, as Realtime states, some kind of network from the trading engine). (Opp'n Mot. 4 at 23.)
Realtime's arguments do not raise a triable issue as to whether the data is in packets when it enters the data stream. Thus, ISE is entitled to summary judgment as to claims 15 and 32 of the '568 Patent.
J. Does ISE Infringe Decoder Claims If It Does Not Perform the Encoding Step?
ISE asserts that its Accused Decoding Instrumentalities, ISE's Exegy OPRA Decoding, OPRA Decoding and ISE.FastSpec Greeks Decoding cannot infringe claims 95, 97, 108, and 112 of the '651 Patent because they do not perform the required encoding step. (ISE Mem. at 17.)
Each of these decoding claims contains the following limitation: "wherein the lossless encoders are selected based on analyses of content of the data blocks [or fields]." (Id.) The parties have agreed that this phrase as used in these claims means "the system (or method) selects the lossless encoders based on analyses of content of the data blocks (or data fields)." (Id.)
According to ISE, Dr. Shamos concedes that these decoding claims require encoding. (ISE Mem. at 17 (citing Shamos Decl. ¶ 78).) The critical issue is whether to infringe these claims a single party--here, ISE--must itself perform (or directly control another who performs) both the encoding and decoding steps.
ISE argues that there is no evidentiary support--and no proffered opinion by Dr. Shamos--that ISE performs both the encoding and decoding steps for these claims. (ISE Mem. at 18.) Indeed, it cites to Maynard as stating the opposite. (Id.) According to Maynard, OPRA sends a feed to ISE, which OPRA itself encoded; ISE then uses its OPRA decoding software to decode that feed--but it had nothing to do with the original encoding. (See Maynard Decl. ¶ 44.) There is no argument that ISE controls OPRA.
With respect to the Greeks decoding function, the Volera Greeks feed comes from an unrelated third party company called Hanweek Associates LLC ("Hanweek"). ISE does own 20 percent of Hanweek.
Realtime does not dispute ISE's factual arguments. Instead, it simply asserts that ISE "was the mastermind" behind the performance of all of the steps of these asserted claims. (Opp'n Mot. 4 at 24.) Such an unsupported statement is insufficient at the summary judgment stage.
There is no material issue of fact with respect to whether ISE's OPRA decoder infringes--it does not; it does not perform an essential step of the claim. Accordingly, summary judgment is granted as to these claims.
K. Does ISE's MIDAS Encoding Infringe Claims 20 and 22? ISE argues that claims 20 and 22 of the '568 Patent require the step of "processing the description file with a data compression compiler, and outputting an executable file that is used to process a stream of data by recognizing data field types in the data stream and applying encoders associated with the recognized data field types to encode the data stream." (ISE Mem. at 19.)
According to ISE, its accused MIDAS Encoding is based on software obtained from a third party, OMX. (Id. at 19.) ISE's Maynard states that ISE has never possessed the source code for this software and has never compiled it. (See Maynard Decl. ¶¶ 33, 45.) Realtime does not contradict these statements.
Instead, Realtime argues that "ISE contracted with OMX for 'deliver[y] of a production-ready version of the Licensed Product.'" (Opp'n Mot. 4 at 23.) Realtime then relies upon the legal proposition that one cannot avoid infringement by having another perform one of the required steps. (See id. at 24.) That argument is applicable to situations in which another is contractually obligated to perform the claimed steps. See Akamai Techs., Inc. v. Limelight Networks, Inc., 629 F.3d 1311 (Fed. Cir. 2010). Critically, there is more to the claimed step than what can be read as a matter of law or assumed as a matter of fact into the delivery of a production-ready version of the software: the steps require processing the description file with a data compression compiler, and outputting an executable file that is used to process a stream of data by recognizing data field types. (See ISE Reply at 10; '568 Patent col.24 ll.56-67.)
Realtime has not proffered the opinion of an expert that delivery of the software requires compiling; or that any of these other steps are a necessary part of such delivery. Accordingly, there is no triable issue of fact on this issue and ISE is entitled to summary judgment with respect to claims 20 and 22 of the '568 Patent.
Conclusion: Motion No. 4
The above rulings complete the Court's decision on ISE's motion for summary judgment of noninfringement (Motion No. 4). ISE's motion for summary judgment is GRANTED IN PART and DENIED IN PART as set forth above.
VI. MOTION 5
Defendants CME Group, Inc., Board of Trade of the City of Chicago, Inc., and the New York Mercantile Exchange, Inc. (collectively the "CME Defendants") move for summary judgment on the basis that their encoding and decoding systems and methods do not analyze the content of a field or block to determine a data field type or data block type. (Mem. of Law in Support of CME Defs.' Mot. for Summ. J. of Noninfringement Based on Lack of Determining a Data Block or Field Type ("CME Mem.") (Dkt. No. 660) at 1.)*fn10
In its infringement contentions with respect to CME, Realtime asserted that the claim requirement of determining a data type was met because the encoder "checks" a current value of a data field. (CME Mem. at 2.) This Court previously construed data block type and data field type as "categorization of the data in the field (or block) as one of ASCII, image data, multimedia data, signed and unsigned integers, pointers or other data types." Realtime Data, 2012 WL 2394433, at *16.
The crux of the CME Defendants' arguments in support of their motion is that prior to the Markman opinion, and then in connection with its infringement contentions, Realtime has used the concept of "checking a value" rather than categorization of the data. According to the CME Defendants, Realtime has used this language relating to "checking a value" with respect to 7 of the 8 asserted independent claims, and has used similar language for the eighth: claims 13, 22, 29, 60 of the '651 Patent, claims 1 and 20 of the '568 Patent, and claims 14 and 19 of the '747 Patent. (CME Mem. at 6.)*fn11 They argue that Realtime is wrong in asserting that the requirement of analyzing the "content of the data block to determine data type" is met when the encoder checks for a relation between the current value of the message field and a value of the corresponding message field in a previous message in the data packet because the Court explicitly reject this construction of the claim in the Markman opinion. (Id. at 6-7.)
Realtime argues that the CME Defendants truncate the steps they are outlining and that they are undertaking a two-step, analytical process: checking a value and then comparing that value. (Realtime Data, LLC's Mem. in Opp'n to CME Defs.' Mot. for Summ. J. of Noninfringement Based on the Lack of Determining a Data Block or Field Type ("Opp'n No. 5") at 9-11.)*fn12 The CME Defendants respond that this may be the "analysis" step--but it does not answer whether the CME Defendants determine a data block type or data field type during the compression as required by the claim; and the CME Defendants argue that this determining step is more than checking a value. (See Reply in Support of Defs.' Mot. for Summ. J. of Noninfringement Based on Lack of Determining a Data Block or Field Type (11 Civ. 6697, Dkt. No. 800) at 3.)
Realtime grounds its response in the specification language of the patents-in-suit. According to Realtime, a "data type" may be a characteristic of the data block. (Opp'n Mot. 5 at 3.)
It is clear from Realtime's description of how it performs this step, that it is performing a value check. The question is whether there is an issue of fact as to where this value check can constitute content categorization. There is not. The Court resolved this issue in connection with its Markman opinion.
Realtime argues the CME Defendants' copy encoding technique determines whether the data block is redundant of the corresponding data block in the prior message and that they perform this step through a "content check." (Opp'n Mot. 5 at 4.) This is, as Dr. Storer states (uncontradicted by Dr. Shamos), really a value check--not a content categorization (e.g., determining whether the content is ASCII, multimedia, signed or unsigned integers, etc.).
With respect to its increment encoding technique, Realtime states that the CME Defendants determine the data field (or block) type by analyzing whether the data block has a sequential difference of one. (Id. at 4.) Realtime argues that this sequential difference is also a characteristic of the data block. This is a value check.
Finally, with respect to the CME Defendants' default encoding technique, Realtime asserts that the data field (block) type is also determined by identifying whether the data block has content that is the most common value for that data block or field that is expected for that data block based on a priori knowledge of the data stream. (Id. at 4.) This is also clearly a species of checking a value and not of content categorization.*fn13
The mere repetition of the word "content" throughout Realtime's argument cannot change what the experts opine is occurring: the CME Defendants' encoding techniques check values; they are not examining the content of the data block for its proper categorization.
The CME Defendants are entitled to summary judgment with respect to their Accused Encoding Instrumentalities. Their motion is GRANTED.
VII. MOTION 6
Defendants NYSE Euronext, NYSE ARCA, Inc., NYSE AMEX, LLC and Securities Industry Automation Corporation (collectively "NYSE"), and OPRA (collectively with NYSE, the "NYSE/OPRA Defendants") have moved for summary judgment of non-infringement as to all claims of the patents-in-suit.*fn14
According to the NYSE/OPRA Defendants, the encoding and data block type (or field) limitations, which are asserted in every claim they are accused of infringing, and the selecting limitation, which is asserted in all but two claims asserted against them (claims 20 and 22 of the '568 Patent), are absent from the accused systems. (See NYSE and OPRA Defs.' Mem. of Law in Support of Mot. for Summ. J. of Noninfringement Based on the Absence of Encoding, Data Block (or Field) Type, and Selecting Limitations ("NYSE/OPRA Mem.") at 1.)
The NYSE/OPRA Defendants make two arguments with regard to encoding: (1) that they do not encode since the NYSE and OPRA systems all throw data away and result in no change, which this Court rejected as constituting "encoding" in its Markman opinion; and (2) that the field operators do not generate a coded representation of the incoming data as this Court in its Markman opinion stated was required in order to encode.
As to the data type limitation, the NYSE/OPRA Defendants repeat the arguments made by the CME Defendants in Motion 5 above: that there is no analysis to determine the data type nor is there an analysis of data type in connection with the selection of the encoder. (NYSE/OPRA Mem. at 2.)
In terms of the selecting limitation, the NYSE/OPRA Defendants argue that this is made during the operation of the field operator identified by Realtime as a content dependent encoder. In contrast, the patent covers selection of the encoder itself, which necessarily has to begin before any encoder begins encoding. In addition, according to the NYSE/OPRA Defendants, the two encoders identified by Realtime are not alternatives--they are in fact applied one after the other. Finally, the NYSE/OPRA Defendants argue that the selection identified in the accused products is based on data value, not data type as the claims require. (Id. at 2.)
A. Analyzing the Content of the Data Block Type
The NYSE/OPRA Defendants make the same arguments as those made by the CME Defendants with respect to the data block (or field) type limitation. They argue that a value check is not the type of data categorization which must occur. Realtime argues that it is, because the "value" is a characteristic of the data, and constitutes "other data type" even under the Court's Markman ruling. Realtime also argues that the NYSE/OPRA Defendants undertake a two step process that does constitute the necessary analysis of the data block (or field) type.
The Court refers to its analysis of these same arguments with respect to Motion 5. The NYSE/OPRA Defendants are correct that there is no triable issue of fact with respect to their data block (or field) type arguments, and they are entitled to summary judgment on this basis as a matter of law.
B. The Encoding Limitation
According to Realtime, the NYSE/OPRA Defendants' field operators do, in fact, convert the contents of a data block (or data field) into a coded representation of those blocks. The NYSE/OPRA Defendants use copy, default, increment and transfer (or stop bit) encoding techniques. For the same reasons set forth in connection with ISE's motion for summary judgment on this issue (Motion No. 4), there are material issues of fact that preclude summary judgment.
Specifically, according to Realtime's expert, Dr. Shamos, in fact all three of these field operators generate a coded representation. (See Shamos Decl. ¶¶ 17, 40, Ex. 1.) Realtime asserts that these products all use FAST encoding techniques. (Realtime Data, LLC's Mem. in Opp'n to NYSE & OPRA Defs.' Mot. for Summ. J. of Noninfringement Based on the Absence of Encoding, Data Block (or Field) Type, and Selecting Limitations ("Opp'n Mot. 6") at 13.) According to Dr. Shamos, lossless encoding techniques can include "field encoding"--and field encoding includes copy, default, and increment encoding. (Shamos Decl. ¶¶ 17, 30.)
With respect to stop bit encoding, Drs. Shamos and Storer again disagree. According to Dr. Shamos, while data bits may be thrown away in stop bit encoding, and transmitted in that manner, they can be identically replicated at the decoding end. (Shamos Decl. ¶¶ 19, 30, 35.) Dr. Storer opines that what Realtime calls an encoder is not. (Storer Decl. Mot. 6 ¶ 43.)
For the reasons stated in connection with ISE's motion on this same issue, the Court finds there are triable issues of fact as to whether the encoders in fact "code." Accordingly, the motion is denied on these grounds.
C. The Selecting Limitation
The NYSE/OPRA Defendants claim that the selection limitation cannot be met because it occurs far earlier than "during the compression process" as required. According to Dr. Storer, the selection of an encoder occurs at the time the code for the template is written. (See NYSE/OPRA Mem. at 16 (citing Storer Decl. ¶¶ 21, 23, 29).)
As the Court noted in its Markman opinion, the essential difference between the parties with respect to their proposed constructions has to do with the temporal moment when the encoder is selected. Realtime Data, 2012 WL 2394433, at *12. The Court concluded that the selection occurs during the compression process and that this requires an analysis of the content of the data block. Id. at *13.
ISE made a somewhat similar argument to that being made by the NYSE/OPRA Defendants. In both instances, the question is whether the selection of the encoder occurs during or prior to the compression process. With respect to ISE, the presence of the PMAP and template ID raised a question of fact.
Here, the question of fact is based on Dr. Shamos' contention that the FAST copy encoding technique actually requires directly analyzing the content of each data block (or data field) to be transmitted; this occurs as the data blocks are present during the compression process, not when the code was written. The Court cannot therefore grant summary judgment on the basis of this argument.
Even if the selection occurs during the compression process, the NYSE/OPRA Defendants argue that the selection limitation is still not met because that selection is never based on data type. (See NYSE/OPRA Mem. at 16-17.) Realtime disagrees. (See Opp'n No. 6 at 20.) Realtime's response on this issue is, however, less than comprehensible. It appears that it is arguing that there is an analysis of data block/field to determine data type and to select an encoder; however, if this is the same type of analysis that is simply checking a value (it is unclear from Realtime's memorandum and supporting declaration), then this is not the type of data block analysis that is required.
The Court assumes that this is in fact what Realtime is arguing and therefore grants summary judgment based on this argument. If the Court has misconstrued Realtime's argument, then it should clarify its position promptly.
VIII. MOTION 8
A group of defendants (the "Motion 8 Defendants")*fn15 have moved for summary judgment on largely the same basis as set forth in Motion 4(D): that a descriptor is not "with" the data blocks. The Motion 8 Defendants argue that independent claims 14 and 19 of the '747 Patent, claims 13, 22, 29, 43, 91 and 108 of the '651 Patent, and claims 15 and 32 of the '568 Patent (and the claims that depend from these claims) all require descriptors.*fn16 (See Defs.' Mem. of Law in Support of Motion for Summ. J. of Non-Infringement: Descriptor Limitation ("Mot. 8 Mem.") at 1.)
Here, the Motion 8 Defendants do not argue that the "PMAP plus template ID, referring to an encoder" is not a "descriptor" as ISE does, but rather argue that this combination does not "specify" the encoder as the claims require, at most there is an indirect reference. Those semantic differences aside, the Motion 8 Defendants' arguments and ISE's (see Part V.D. supra) reduce to the same and thus, are resolved the same way.
This Court construed "descriptor[s] indicate" as the equivalent of "descriptor with . . .": both require that "recognizable data that is appended to the encoded data for specifying". See Realtime Data, 2012 WL 2394433, at *16. The Court specifically analyzed the question of whether the descriptor must be physically attached to the data or can be associated with the data. It determined that it must be attached in the sense of being "with." Thus, the Court rejected the construction that would allow the referenced template, which is associated with the data. The Court explained that its construction was consistent with multiple references in the specification itself which used language such as "with" or "appended". As this Court found, "[T]here is no support in the specification or claims for the descriptor to be completely detached from the data block." Realtime, 2012 WL 2394433, at *15. The requirement that the template ID and PMAP reference a detached template in order to determine which encoder has been used, does not meet the claim limitation.
Accordingly, the Motion 8 Defendants are entitled to summary judgment on this basis.
IX. MOTION 9
Defendants Credit Suisse Holdings (USA), Inc. and Credit Suisse Securities (USA) LLC (collectively, "Credit Suisse") have also moved for summary judgment based on the descriptor limitation.*fn17 Credit Suisse's description of the process is somewhat different from that described by in Motions 4 and 8, but nonetheless makes the same major points.
In Credit Suisse's motion, it is clear(er) that the template may be sent to the decoding system in advance. In Motions 4 and 8 it was unclear where the template physically resided, but it was clear that it did not reside with the data block which had the template ID and PMAP. Credit Suisse states that "the decoding system receives the Template in advance, and stores a copy of it. Subsequently, upon receipt of an encoded FAST message, this copy of the Template is used to determine which encoders were used to encode the message." (See Credit Suisse's Mem. in Support of Mot. for Summ. J. of Noninfringement: Descriptor Limitation ("CS Mem.") at 3.) As a matter of undisputed fact, the template is not "with" or appended to the data block.
It is still a reference tool that is separate and apart from the data block that has been encoded. Accordingly, this process does not meet the required limitations of the claims requiring a descriptor, and summary judgment is therefore granted.
The Court's rulings on Motions 4, 5, 6, 8 and 9 are as set forth above.
Motion No. 4 is GRANTED IN PART and DENIED IN PART. Motion No. 5 is GRANTED. Motion No. 6 is GRANTED IN PART and DENIED IN PART. Motion No. 8 is GRANTED. Motion No. 9 is GRANTED.
The parties are directed to submit to the Court a letter within four business days of the issuance of this order setting forth (1) whether and how these rulings affect the upcoming trial in the Exchange Action; and (2) the order that the Court should proceed to resolve the remaining motions for summary judgment.
The Clerk of the Court is directed to terminate the following motions:
11 Civ. 6696: Dkt. No. 523
11 Civ. 6697: Dkt. Nos. 684, 659, 680, 687
11 Civ. 6699: Dkt. Nos. 92, 109, 112
11 Civ. 6701: Dkt. No. 111
11 Civ. 6702: Dkt. Nos. 132, 149, 152
11 Civ. 6704: Dkt. Nos. 114